PFSense talking out with all rules set to block
-
When I say outgoing traffic I am talking about the box talking out to external IP address's on it's own. No client on the LAN initiated any communications. This is what this box is all about right?
The logs show outgoing (out arrow) on the "WAN" interface not LAN, as the box itself is doing this. It seems any package on the box has free reign to do as it pleases with no ability to block them. You will not see these log's even unless you enable view default pass rules. Even if you have set all your rules to logging.
Turning off features isn't the problem, it's the various packages. I have seen it now accessing everything from google to websites in the UK. This box is in a secure environment and cannot be updating itself unannounced.
Is there not a way to set a rule to block WAN out?
-
If you need to block outbound, you should be able to setup floating rule to block outbound on any interface.
https://doc.pfsense.org/index.php/What_are_Floating_Rules
Floating Rules are advanced Firewall Rules which can apply in any direction and to any or multiple interfaces. Floating Rules are defined under Firewall > Rules on the Floating tab.
Many firewalls do not need any Floating Rules, or may only have them for the traffic shaper. For those choosing to use them, they can make some complex filtering scenarios easier, at the cost of being a little harder to follow logically in the GUI.
More advanced/low-level options are available on Floating Rules than can be found on normal per-interface rules.
Floating Rules can:
Filter traffic from the firewall itself
Filter traffic in the outbound direction (all other tabs are Inbound processing only)
Apply rules to multiple interfaces
Apply filtering in a "last match wins" way rather than "first match wins" (quick)
Apply traffic shaping to match traffic but not affect it's pass/block action
Much more.Floating Rules are parsed before rules on other interfaces. Thus, if a packet matches a floating rule and the Quick option is active on that rule, pfSense will not attempt to filter that packet against any rule on any other group or interface tab.
Rules using the Queue action do not work with quick checked.
edit: In a perfect scenario, all packages would list what traffic they might do, and in a perfect world be able to turn off or edit that functionality - but as we all know, no such thing as perfect anything ;)
-
I had experimented earlier with the floating rules just to pass and log. I Did not see any log entries from these outgoing wan packets. So I don't expect it would have blocked it either.
-
Ok as quick test, I went in and created a floating rule to block icmp out wan. Since I know for sure that firewall sends those out like every second. And there is widget showing if gateway is online, etc..
So sure seems to be blocking to me. See the floating rule, set to log and in the logs, and widget shows gateway is offline.
Now I did have to reset the state that was there for icmp on the wan. Once I cleared that state then blocking was instant.
-
Hmmm, I completely forgot about resetting states!! Probably why I didn't see results….
So I will give it shot! Thanks,
If you ask me, blocking wan (outgoing) is the first thing everybody should be doing, and then giving permission only to what you see and know is supposed to be there.
-
If I didn't trust pfsense - why would I be running it in the first place?? Same goes for the packages..
Not all of us have our tin foil hats on so tight, some of us wear them fashionably cocked to the side, etc..
-
My tinfoil is wrapped so tight my eyes are bulging out….
And I still trust pfsense.
-
If you ask me, blocking wan (outgoing) is the first thing everybody should be doing
Block WAN access from your LANs all you want. Blocking WAN traffic from the firewall itself it a sure way to screw up things badly. As an example, notice the nifty "offline" gateway pic above. How cool is that?
-
Some people get bored with the all-green motif that is typical with pfsense. Some people just like a dash of red.
-
I get paid to wear a tin hat, and a pfsense box is for tinhats. The reason I am even asking these questions is because this is in a high security area, and I was contacted that this box was busy with traffic when it was supposed to be offline. The only reason anybody caught it is because they inserted another router in between it and watched the logs on that.
this box had a new user. And an extra cron job in there. After comparing the folder structure, somebody had uploaded a package and it was busy talking from the WAN out. Neither looking at the firewall logs or blocking all the rules revealed or stopped it. In fact the "only" way to tell anything was amiss was the enabling of the "log pass rules".
So all it takes is for somebody to get access to the shell and load in a package and that's all it takes. They don't even have to bypass any rules.
Whether it was hacked in-house or not. It would have been caught and prevented if the box didn't automatically pass and hide. Because we would have seen the rules altered. (Which is usually what happens when they hack in)
-
Well - Lets say you have a well known IP that people want into. And lets say its connected and set up with WAN connected. And lets say the default username/pass wasn't changed for even an hour. And lets say SSH was turned on for that hour…
Then yes - even without fingers on the keyboard, someone could co-opt the entire system.
Even easier if they have hands on the keyboard. It needs physical security.
-
So all it takes is for somebody to get access to the shell and load in a package and that's all it takes. They don't even have to bypass any rules.
If someone gains shell access and has privs to install a package, then they can easily change anything else they want, including first turning off rule logging, clearing any local logs,…
Once someone unauthorised has gained root access, then anything can happen.There are a few things that pfSense will "phone home" for - checking for firmware updates, version status of packages, updating bogons come to mind. Maybe it would be useful to have an Advanced config button "Do not phone home" that disabled all these things. Then people who want it to be that quiet on WAN can check the box. (And uncheck the box when they want to do an auto firmware upgrade or a package install)
-
"this box had a new user" - Sounds compromised….
-
Yes the box was compromised, and that's the point. Can be hacked from the outside or from within the company, doesn't matter. It still should have been visible to the multitude of built-in tools to monitor the traffic, "EXCEPT" when it goes "out" the wan interface.
At a minimum wan out needs to default block, and the packages should be forced to register their ip's in a whitelist that you can see and control. (just like the rest of the box) Any new unexpected traffic will be forced to add to this white list. or will be blocked. No free ride for packages, or even pfsense itself.
-
And after several days, my other posts about solicited/unsolicited traffic still has not been answered definitively, nor can I find documentation on exactly how this works.
I ask because the way I think the box was compromised was through a proxy server the box was using. The user did his normal thing with the proxy out a certain port. PFSense opens a rule on wan to allow this proxies ip to talk. Doing what it is supposed to, but then this same proxy switched to a different port later on, and had free reign to access the shell. Since this proxy has seen everything the user does remotely, it knows everything.
Normally it would have been blocked by incoming wan rules, but it became trusted when the user did some outgoing. Now nobody has answered definitively about whether PFSense simply creates a pass wan rule restricting it to just the port it was outoing on. Or whether it's set to 'any' as far as I can determine from the logs it appears pfsense let's a solicited ip address through on any port it want's afterwards.
And I don't see pfsense closing these rules after a TCP session is ended either. Nor do I see how it can understand (follow) UDP transactions anyway. It seems to me it just opens them up and leaves them forever.
-
Dude. What do you want to document? The firewall itself will
- use DNS (duh!)
- use NTP
- use HTTPS (FW updates, packages updates, bogons updates, etc.)
- use ICMP/ICMPv6 for GW monitoring
- use more of ICMPv6 as required for IPv6
- …
Your box most certainly was NOT compromised because of firewall-initiated traffic going out via WAN. Sigh. By disabling the above, you only breaks things, without any security improvement whatsoever.
Also, if you want outbound traffic filtering/logging, then you need to configure outbound rules yourself and enable logging for those. Most people want outgoing traffic to flow, not to babysit the firewall for weeks monitoring what legitimate traffic is still being blocked for no good reason.
packages should be forced to register their ip's in a whitelist that you can see and control. (just like the rest of the box) Any new unexpected traffic will be forced to add to this white list. or will be blocked. No free ride for packages, or even pfsense itself.
Yeah, that would ultimately rock. Say with pfBlockerNG blocklists, snort/suricata rules, etc. Sigh again.
-
The pfSense default "background/unseen" ruleset is to block all ingress packets from all interfaces. Then you get a pass all rule on LAN for free in the default config that allows all incoming from LAN clients.
The firewall can talk to itself internally (e.g. firewall processes that want to lookup a DNS name can "loopback" to the firewall's own DNS to ask for that…).
Anything that can be originated internally can egress out wherever the routing table thinks it should go. There are no egress blocking rules.For most users, that is fine. But yes, some users have stricter requirements to ONLY emit packets that are white-listed somewhere. For that, you have the option to put floating rules outbound on your WANs - first to permit the things you want/need to make the firewall work, then to block all other.
So if you require such extra checks/filtering you can put them in place as required.
As long as that is understood, then "high-security/privacy" users can get the result they want.Edit: added the word "no" in italics above - I missed that important little word there about "no egress blocking rules" !
-
Can be hacked from the outside or from within the company, doesn't matter.
Still shaking my head… How on earth this does NOT matter? :o
So, you're gonna plumb your "phone home" WAN and call it a day, only to find out that someone attached a keyboard and monitor and compromised it again? Or compromised it again because he sniffed your password on LAN because you don't use HTTPS, or have it written on the yellow sticker on your monitor, or have a keylogger on the computer you are using? Or just because you created some user account and gave it some privileges without thoroughly understanding what are they able to do with those?
What measures have you taken to secure the administration access to the box? From inside, from outside, physically... ???
-
Yes the box was compromised, and that's the point. Can be hacked from the outside or from within the company, doesn't matter. It still should have been visible to the multitude of built-in tools to monitor the traffic, "EXCEPT" when it goes "out" the wan interface.
At a minimum wan out needs to default block, and the packages should be forced to register their ip's in a whitelist that you can see and control. (just like the rest of the box) Any new unexpected traffic will be forced to add to this white list. or will be blocked. No free ride for packages, or even pfsense itself.
The firewall is meant to manage traffic moving through it. If you don't trust the packages on the firewall, then don't install them on the firewall, install them somewhere else. And as before, you block traffic coming in, not going out. If you ever configure a managed switch, don't EVER use ACLs on egress, it'll kill your switch's CPU, only do ingress ACLs. Same idea, it's faster to do ingress ACLs.