PFSense talking out with all rules set to block
-
Been trying to track down some traffic going out even though I have totally set the rules to block everything temporarily.
In desperation I enabled "Log packets matched from the default pass rules put in the ruleset" in the firewall log settings and got my answer after seeing several autorules in the firewall logs..
"let out anything from firewall host itself" And it shows it's on the WAN INTERFACE e with an arrow indicating outgoing.
I didn't know it can use WAN in the opposite direction (as outgoing). It is sending out UDP to various places, some timeserver, some dns, and also looking for updates. But also some packages are also firing off various ip's of their choosing as they please. This is fine and dandy except the role of this particular box is not to talk out on it's own.
I can see from the log it must be using some hidden floating rules. Does anybody know how to stop this with a ruleset? Yes, I can kill the timeserver and dns. But I want all this to work again with just passing/blocking a rule.
-
The firewall only blocks on ingress when a new state is created. If the state is not new or the packet is not received as ingress, then it is not blocked. What this means is packages running in PFSense do not honor.
PFSense doesn't block outgoing data, it blocks incoming data. If you decide to run software on PFSense, then there is no interface for the packet to be received on, meaning it does not get blocked.
I'm sure there are some exceptions.
-
And what packages are you installing? On a box that is not suppose to generate any traffic?
"the role of this particular box is not to talk out on it's own."
So is this box static on its wan - if not it would have to generate atleast renewal of its dhcp IP? Its going to generate ARP traffic for sure.. I think you idea that you can put something like a firewall distro with packages of other applications, etc. etc. and not expect it to put traffic on the wire is unrealistic at best.. If you don't want it checking for updates, turn that off, if you don't want it doing dns - turn that off, etc..
-
If you want absolutely ZERO traffic on the WAN, unplug the cat5.
-
the role of this particular box is not to talk out on it's own.
I can fix it easily for you:
-
What kind of traffic are you seeing? You might be able to get most of the traffic stopped by disabling features in PFSense. Most of PFSense's traffic has to do with checking if the link is alive and looking for new versions.
johnpoz hit most of these points. There is going to be come traffic that you can almost never get rid of, like ARP, or DHCP if you have that. You also have that PFSense is a stateful firewall, so if dup packets are received, PFSense is going to respond with a DUP ACK, which is pretty much built right into the network stack.
Show us some examples of what traffic you want to get rid of, but it is unrealistic to think you can get rid of all traffic.
-
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.