Hi,
On 15/07/2019 11:29, Michael Tremer wrote:
Hi,
On 14 Jul 2019, at 15:56, Peter Müller peter.mueller@ipfire.org wrote:
Hello *,
currently, the iptables configuration used in IPFire 2.x does not log _every_ packet if logging is enabled for whatever reason, but enforces a rate-limit:
iptables -A LOG_DROP -m limit --limit 10/minute -j LOG
(snip taken from /etc/init.d/firewall)
For several reasons, I consider this a bad idea. (Forgive me for bringing up firewall issues in IPFire 2.x again. :-) )
IPFire 2 is still being actively maintained, so feel free to do so.
First, this rate-limit is never mentioned in the firewall WebUI or our documentation, thus being unintentional for most users including me.
Second, it makes debugging very hard - I recently spent several unpleasant days trying to fix a VoIP related network problem, until I got not every packet dropped by IPFire was actually logged. Especially for corner cases or non-deterministic issues, this behaviour makes this more difficult.
Third, it is not compliant. Especially when it comes to post mortem forensics, firewall logs are important. If you cannot trust them since there is no way of telling whether a packet was dropped and not logged, or never seen by the firewall machine, its best to stop logging anything at all.
I therefore propose to drop iptables logging rate-limit in our firewall configurations (which goes for IPFire 3.x as well). Since my systems to not run on problematic hardware (ARM SoCs with SD cards, crappy flash storage, etc.), I have no idea if this will cause issues on some systems/platforms.
@All: Thoughts, please. Is anyone aware of potential trouble?
I generally agree with your points. I am not sure where the number is even coming from. We have carried this over from the beginning of IPFire without thinking about it again.
The motivation why this is there is probably that logging is an expensive operation and that you can use this as a DoS vector and fill up somebody’s hard drive just by sending packets. Logs will grow a lot faster after making this change and maybe we want to have a backstop for this?
-Michael
I think there probably needs to be some sort of limit to prevent the DoS scenario, but 10/minute seems very small for modern hardware. Perhaps something could be done using hashlimit to prevent any one source IP causing a DoS while still allowing dropped packets from other sources to be logged.
Tim
If not, I will send in a patch within this week.
Thanks, and best regards, Peter Müller -- The road to Hades is easy to travel. -- Bion of Borysthenes