Proper rules for proper separation for LANs
-
I did read all over the forum for advice how to properly isolate LAN,DMZ,etc, from each other. I did set my DMZ base on what @johnpoz recommend.
Now the the DMZ can talk to internet and can't touch anything on the local networks which is what I wanted. But I haven't touch the LAN rules so LAN can access anything including DMZ , just not the other way around.
Now, I am assuming this is not good/secure design since bad things from lan can jump to DMZ zone. So I wonder how He would set his LAN rules ? What is the proper design ?
Thanks in advance for any input.
-
…since bad things from lan can jump to DMZ zone...
Nothing's "jumping" from here to there, except for kangaroos and frogs maybe.
And IF something is not clean then by definition it's within your DMZ. That's why you separate it from LAN.
LAN should be considered clean… -
SO would you leave it the way it's no the picture. Giving LAN acces to DMZ, WIFI, GUEST, TEST or any other lan type segment including MNGT (management lan for IPME server access) ?
Can you elaborate on what your opinion is for how should be set up ?
-
I know I am in the minority but please block to destination RFC1918 then pass to destination any. Blocking traffic with a pass rule is bad juju.
-
Have you read this? https://doc.pfsense.org/index.php/Example_basic_configuration#DMZ_Configuration
-
Have you read this? https://doc.pfsense.org/index.php/Example_basic_configuration#DMZ_Configuration
Read it, thanks.
-
I know I am in the minority but please block to destination RFC1918 then pass to destination any. Blocking traffic with a pass rule is bad juju.
Very good idea. I was considering it , but since I am no expert didn't trust myself of doing it. I'll change it right away.
What about the rules on a LAN side ?(my concern that LAN can still access DMZ ?)
-
I know I am in the minority but please block to destination RFC1918 then pass to destination any. Blocking traffic with a pass rule is bad juju.
This is what you meat , right ?
-
Yes. I like that a lot more than passing to ! RFC1918
-
Me too. :)
It looks more clean, easy to read and less prone to miss-configure.
Thanks for the suggestion.
P.S. You haven't suggest anything about the LAN side security.I can easily add the rule block RFC1918 to the LAN, but I am trying to understand the security concept : Is it how is done for the LAN side or is left unrestricted to any ?
-
What do you mean? If you want to block DMZ from LAN, block it on LAN.
Some want to be able to connect from LAN to DMZ to manage the hosts there but block from DMZ to LAN to protect the LAN hosts from compromises in the DMZ. That's generally the point of it all.
Depends on what you want.
-
That's what I have now:
DMZ is block to access LAN
LAN can access DMZ (to manage hosts like you said)What I want is SECURITY so I was wondering if I should leave it like that or I shoul block LAN from access DMZ and make them isolate from each other in case a LAN side has something bad , it won't crawl to DMZ or WIFI or anywhere local. Is that a good idea ?
-
The general "best practices" is to block any-any, then specifically allow only that which you really need.
The DMZ should not be able to establish connections in to the LAN in general. The DMZ is dirty'ish. The LAN can make no connection to the DMZ except that which you have a business case for.
You seem to be generalizing even more "the LAN can access the DMZ" - why? What about "the LAN can access specific services on specific machines contained within the DMZ that I really need". No one on the LAN needs to talk to port 43210 on the NTP server, right? And should they be making TCP connections to NTP at all? We need to open UDP 123, not TCP 43210!
If we look at my office, for example:
Some machines within the DMZ need to make a connection to a single load balancer on the inside - a database server cluster. Only one web cluster needs to make that connection. (It's not "really" on the inside, it's further segregated from true internal traffic which is broken up again, and the database servers are in their own VLAN, but let's not complicate this)
I sit down with paper and pencil before I ever touch the firewall.
People on the LAN need to be able to see our web servers, so traffic explicitly to those web servers is allowed on web ports by proxy (80, 8080, 443). People need to hit the mail server on secure imap, so traffic from the LAN to the mail server [DMZ] is allowed on 993, but no traffic is allowed to 993 on the web server, for example (which isn't listening there anyway). People on the LAN need to talk to the MTA on the DMZ at 25 and 587 (over proxy). The same MTA needs to talk to the WAN on the same ports.
The best way to accomplish this is to deny ALL traffic, then poke little holes only where you need them to specific machines on specific ports over specific protocols.
Always ask yourself: "do I really need this?" and "if I do this, what risks does it expose?"
It's always best to have a couple/few people sit down and you defend each and every rule to them while they try to pick it apart - it's amazing even after all these years what I can overlook! The whiteboard is your friend. If you can't defend it, you don't need it. Document all the decisions as they're made, and preserve the documentation - next year you'll thank the past you for such foresight. ;)
But, ultimately, if you start with denying any-any, the amount of "oops" damage you can do will be dramatically limited (that's not to say that you won't tick everyone off for a couple weeks, and spend a lot of time in the log files looking for why they're getting denied something that "ZOMG I GET FIRED IF I CAN'T DO THIS" ( ;) ), but eventually it calms down.
-
Thank you for the input. This was very helpfully and I appreciated it.
Just to clear something out, I am not saying LAN to any is good. I am saying by default that;s what you have when you install pfsense and you need to go from there and my question was where ?
I try to expanding another way what I am looking for :
Let say one already read from the pfsense book how set rules. What I am looking for I typologies - How to set and segregate the things for max security. Assuming one will have: WAN, LAN, DMZ, Phone, Cameras, Severs, WIFI and etc.
-
If that description was not enough you should probably go to something like this hangout:
Otherwise you appear to be asking for a complete firewall design in a forum post. It is unlikely you will receive that here.
-
"Blocking traffic with a pass rule is bad juju."
I don't see why you think its blocking any traffic.. Its just an allow rule.. The default deny is what is blocking..
Why should he create an extra block when the default deny is there to use? Its a specific allow rule with a specific dest, anything BUT whats in the alias..
Thats my take on it - we seem to butt heads on this point ;) hehehe
-
Because it is a pass rule, not a block rule.
Strange things can happen there.
I am not opposed to using pass rules and relying on the default deny. You are actually passing desired traffic there.
I am opposed to using pass to ! Alias when you really want to BLOCK to Alias. If you want to block traffic, block it. Reject is probably more suitable in that case, anyway.
But yeah, this will come around again, and we will disagree again. I guess https://redmine.pfsense.org/issues/6799 isn't enough to prove that the rule order principles I adhere to are sound.
-
If that description was not enough you should probably go to something like this hangout:
Otherwise you appear to be asking for a complete firewall design in a forum post. It is unlikely you will receive that here.
This is very good suggestion. These "hangouts" are so great i don't know how i missed them. Actually I know how - I dissregard them without checking what are they cause my brain related google hangouts and just shut them down, but that besides the point. The are great sorce of information that I needed so thatnks a lot for point8ng them out.
To bad they are not downloadable (at least i dont seee it) so I have to listen them only when I am home.(comcast 1TB data cap vs verizon mobile 5GB).
-
I do like the 2 separate rules idea, even if it's just for the cleaner easy to read reasons. Prone to human mistake is a major security issue, and just by using "!" and making a diference from let everything local in or block it, it's not worth the risk compared to the convenience it bring. Just my 2 cents. :)
-
I have a specific question that should be very narrow one and I hope I could get help here:
Let's say you have a file server (freenas) that you would like to be on you LAN net (of course) but also you would like to be on WIFI net , so you can stream to yoy mobile devices at home.
Now I know some people after put one leg (nic interface) on LAN and another leg in WIFI and will work, but I always worried that if fileserver is compromised on WIFI leg will have then acces to LAN and the whole separation of LAN and WIFI will be useless. After I heard Jim Pingle on the hangouts pointing exactly that , I won't even consider doig it that way.
So how this could be done then ?! (with security as most important priority in mind)