Hi, On 15/07/2019 11:29, Michael Tremer wrote: > Hi, > >> On 14 Jul 2019, at 15:56, Peter Müller 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 >