How to - Block and Filter Egress Traffic
-
@johnpoz Could you please help with the following:
I would like to block/reject and filter egress traffic.
- Is the best practice to block all then selectively pass traffic to needed ports (e.g. 443, 80, 25 etc)
Then use logging to see if other ports need to have pass rules.
Or is it better to have open/any egress, then block specific ports (e.g. IRC) and use logging?
- I have read a few of your past posts and searched a lot, some speak of using floating rules for egress filtering others placing rules on the LAN interface.
I have many VLANS with LAN as the parent interface. Would you recommend filtering egress on a VLAN or gateway specific basis (though may not be proper interface(s) at all) or an overall basis? This considering certain systems may need to use ports that all others do not.
If overall where do the rules belong? Floating, on the WAN and VPN gateways or LAN?
- Would you mind posting a screen shot of an example?
Hope all is well. Thank you very much for your time!
- Is the best practice to block all then selectively pass traffic to needed ports (e.g. 443, 80, 25 etc)
-
@rennit the only place to do "egress" from an interface is floating.
Not really a fan, unless you have some special use case.
If you don't want lan or some vlan or specific devices on these networks to go to IP or network X, or port Y anywhere, etc. Then block that at the ingress into the firewall, ie on the interface the device your wanting to block is connected to pfsense.
Why would you want any traffic to transverse the firewall at all, if your just wanting to block it. So its better to stop it from even being processed by the firewall where it enters the firewall.
What would you like a screenshot of? Example of what - what are you trying to block exactly and sure will put up a example blocking that.
Here is one example where egress blocking might be useful.. Trying to be a good netizen, and keep noise like rfc1918 traffic leaving my network into the isp network..
So with any any rules on multiple interfaces on my lan side interfaces. If some device, say a typo or whatever (work machine trying to talk to some server on its rfc1918 because it doesn't know the vpn isn't connected or something.
If some devices tried to go to rfc1918 address that was no being used on any of my local networks - then router would send it out the default route, ie your isp.. So this sort of rule would stop that
This is egress/outbound rule on my wan interface that says if the destination is rfc1918 then block it.
-
@johnpoz quick as ever, thank you!
I am looking to block certain things from calling home, as well as preemptively against malware (i.e. bots that like to use IRC etc.).
Also as a bit of a diagnostic and educational study, since IDS cannot see a lot due to encryption, and may not use it on pfSense for a multitude of reasons, thought could possibly use the logs to see if anything was trying to communicate outbound, that may already be on any number of devices/systems.Edit: Seeing screenshot now: Due to my lack of complete understanding - that is blocking WAN or inter-RFC or how does that block outbound to internet? I am guessing it does not or port pass rules would be needed, correct?
Well we all need good citizens on shared cables... :)
-
@rennit see my edit for one example.
But sure ok if you had say some device, that might float around to your different networks, and you want to make sure it can not talk to network xyz at all, or make sure it can not talk outbound on port 456, and you have different networks that would allow that, and or you have so many networks that you don't want to put the specific blocks in on each interface.. Then sure you could use a floating rule to put it as inbound on all your interfaces, or block it outbound/egress out your wan so you know such traffic can not go out to the internet/wan
See my edited example above where blocking rfc1918 from exiting my pfsense.
In my above example I can not use that as ingress on each local lan side interface, because I want them to talk to my local rfc1918 network. So it best to put it from leaving pfsense into the wild.
edit: The rfc1918 alias is all the rfc1918 networks.
Its outbound wan says hey hold on there champ - why are you trying to go to a rfc1918 out this interface - nope! Blocked.. But yes I want to allow internal vlans to talk to each other via 1918..
-
@johnpoz Now I get it. So because/if a prior connection (e.g. port 80) does not exist then 'random' local traffic originating from rfc address would the be blocked.... Is that correct?
-
@johnpoz In my case some of the internet only connections you helped me with previously say, stop right there champ, you cannot go inter lan to rfc addresses either. So would this effectively balance that, then preventing the out to the internet as well? With the goal in-mind of studying if anything is trying to legit or not or spyware or not, as well as preemptive on future possibles.
-
@rennit huh.. Not sure where an existing state would come into play..
I use
192.168.9/24
192.168.2/24
192.168.3/24
etc.Internally.. So if one of my 192.168.9 boxes wants to talk to a 192.168.2 box no problem... But say I typo something and trying to go to 192.168.22.53 -- this does not exist on my network. Pfsense as a firewall/router would say hey I see a syn trying to go to 192.168.22.53 - where is that, I have no route for such a network.. send it to my default gateway (isp) he will know where it is - just like when trying to talk to say 8.8.8.8
This rule would stop that "noise" from entering my isp network. Now if I didn't block my isp would block it anyway - unless maybe he had a 192.168.22.53 device somewhere on his network.. But such a rule is just playing nice, trying to keep obvious noise from the internet.
edit: there is no rule for an egress rule on your wan, unless there is traffic you allow internally but for some reason don't want that to be able to go out to the internet, if that is were it could route to, since its allowed on the ingress of your lan side interfaces.
-
@johnpoz makes sense. Understood, but what about in the case of malware or anything else just trying to reach back on port 663x or IRC?
Edit: There is this whole section in the Netgate documentation on egress filtering and the why, but nothing explaining the how...
-
@rennit said in How to - Block and Filter Egress Traffic:
reach back on port 663x or IRC?
Well if your not using those internally - then just block them from even entering pfsense as ingress rules on your local side interfaces.
If you want to create an alias with such stuff like ports you want to block.. Then you could put them in an alias to block all the bad ports you do not want to go outbound, but you might want to use internally.. You could put those on an outbound rule for your wan interface.
edit: More likely than not "malware" these days would be using 80 or 443 ;) since those are almost always open ;) So trying to hide the bad traffic along side normal traffic. While sure there might be some crappy written piece of bad code using those ports.. Any real threat would use normal ports that are always open, and to be honest these days in the age of https certs on the fly, be inside an encrypted https tunnel ;) using some acme cert..
-
@johnpoz Got it. Okay. So nothing like building a dam then poking a few holes through, more like some sandbags in particular doorways?
Edit: To your edit - agreed, figured I would try to worry about what I could actually effect.
I'm learning some SO and spanning etc. to try and educate myself more on those current day realities... -
@rennit I am not really a fan of blocking all and only allowing xyz.. Its too much work, since there is always going to be something you forgot about or something new that might use some new port. And your rules being very restrictive you prob cause yourself more grief than any added security.
if the code is executing on your box - the battle has already be lost anyway ;) heheh And like I said its prob going to use known allowed ports to talk to the mothership anyway.
Now if you want to block known bad IP ranges - that is different story, and easy enough to do with pfblocker, or some aliases from pfblocker in your own rules.. Those would be best to block ingress into pfsense, since you sure not going to be using those bad networks internally..
-
@johnpoz Okay, all makes sense as always from you. Thank you.
And yes, pfblocker is definitely on the list to learn and setup.
Also: I just setup a new switch and it has brought me to one last issue I'm having trouble with regarding management and isolated LAN. Seems to be of interest from the posts I've read, but no real answers I've seen, so I am going to start another thread, easier to find related topic for others, with last questions for you. Hope you do not mind...
