Block out-of-state or invalid traffic silently
-
Hi,
I understand pfSense blocks out-of-state traffic or invalid packets by default. That's good and I don't want to change that, but I do wonder if I can safely silence most of that log chatter coming from out-of-state packages.
I already enabled the options "IP Do-Not-Fragment compatibility" and "IP Random id generation" in the Advanced Firewall configuration, as this reduces the amount of dropped packets especially from two specific clients. Nethertheless, I still see a lot of block messages from LAN which looks like out-of-state traffic, mostly TCP FIN-ACK packets.
Is there safe and easy way to block these harmless packets without creating log entries for each? I know I could change the default policy to not log any blocked pacakges. But I would prefer, if I could simply not log the harmless out-of-state traffic, but still get messages for other blocked traffic that might be interesting. I also see, for example, IPv6 multicast traffic being blocked by default on the LAN interface as well as Link-Local traffic such as this. This kind of traffic I'd still like to see logged, but not the numerous FIN-ACK packets and the like.
Is there a safe way to achiev this or a set of rules, that could be used for this? I'm asking this first here, for two reasons. First, I'd like to be sure I do not block anything by accident that would not normally have been blocked. Second, while I know that blocking FIN-ACK packets is harmless, I'm not so sure about other possible flag combinations that are invalid or safe to block.
Thanks,
Timo
-
I would be more curious to why you are seeing so many fin-acks that are being logged.. that should close up the state and be the end of it - are you seeing duplicates of these and your logging the dupe as out of state?
How I keep my block logs clean is turn off default logging and only create logging block rules for the stuff I am curious to see.. For example syn traffic.. This prevents any sort of out of state traffic that is blocked by the default log to not be logged.
But I see for example all the attempted probes to my wan IP for 23, 22, 3389, etc. And every other port - this gives you a sense of the amount of noise.. I don't have any desire to log the noise of UDP traffic out there, etc.
-
I don't really know why these packets are happening or whether they can be considered many. E.g. the last 50 blocked LAN packets are from within 90 minutes. Is that much?
What does strike me, though, is that the majority of these packets seems to be coming from wireless devices (connected via a seperate AP). These are running either MacOS, iOS or Android. The only wired client that seems to generate such packets as well is an Amazon FireTV box, so Android-based, too. I also notice that none of these packets seem to come from my Windows or Debian machines (all wired). In terms of destinations, most of the traffic seems to be https (port 443) and some http (port 80).
What would be a good starting point or tool for further investigating this?
P.S.: I should mention, too, that while I see these packets being blocked, I don't encounter any issues on the clients. E.g. when I noticed a sequence (something like 30) of such logged packets last night, they all came from my wife's MacBook. She was just reading a few web pages while listening to a YouTube clip in the background. I asked her whether she noticed any delays or issues while surfing and she said no, everything worked fine. Her browser is Google Chrome and the MacBook uses a wireless connection. As there were no issues, I didn't question this further until now.
-
What I would do if your seeing it happen from a specific IP… to dest say 443 is log this traffic via packet capture under diag, set it for unlimited vs the default 100 packets. And then after you see it log a block in or 2 in firewall log download the sniff and look in wireshark... Is the fin, ack a dupe... Do you see lots of dupe packets?
So firewall should close the state when it sees the fin, ack
Is the client initiating the closure or the server, etc. Keep in mind that wireless devices especially phones can be odd as they try and re use sessions and such when they switch from cell to wifi, etc..
Wifi maybe your loosing packets and so are doing retrans.. But since shouldn't be waiting for answer to the fin,ack - sounds like a software issue where vs actually closing the session after sending its waiting for a timeout of something and then resending the fin,ack again. Maybe wifi is just causing dupe packets - sniff would show this on all the other packets, etc.
Once you have a sniff that shows the full session and who started the close and and sent the first fin, and then how much later the other fin ack comes in, etc. Could lead to understanding of what is the actual cause..
-
So, I did a packet capture of my FireTV box as suggested. It seems these are duplicate packages that are being filtered and I have a feeling that it might be related to the sleep/energy saving behaviour of the device. The reason I think so is that when I actually use the box, I don't get any dropped packets. But when it is not in use, I can see that the traffic pauses for some time (sometimes 5minutes sometimes even an hour) and then resumes. I haven't really confirmed this by actively putting the device to sleep and bringing it up again, etc. But at least I can be sure that the firewall does it's job correctly and discards only irrelevant traffic.
-
So if the device goes to sleep and doesn't send any traffic.. Then sure the state would time out on its own.. You can adjust these timers if you so desire in pfsense, but wouldn't recommend that.
Then if the device tries to reuse its old session where no state exists because it timed out then sure you would get a log - then when it fails the device should just connect with a new session, sending a syn which if allowed by your rules would open a new state and all would be good..
If you do not want to log that - you could turn off the default rule log and just create a log to log stuff blocked by syn only if you want, if your blocking stuff outbound on the lan etc and want to see attempts. If not then your rules that hit lan that would be blocked by out of state and logged by the default rule would still be blocked, just not fill your log.
