From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tim FitzGeorge To: development@lists.ipfire.org Subject: Re: Proposal: Drop iptables logging rate-limit Date: Thu, 18 Jul 2019 19:23:24 +0100 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1919961220534232743==" List-Id: --===============1919961220534232743== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, On 15/07/2019 11:29, Michael Tremer wrote: > Hi, > >> On 14 Jul 2019, at 15:56, Peter M=C3=BCller w= rote: >> >> 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 t= hinking about it again. > > The motivation why this is there is probably that logging is an expensive o= peration and that you can use this as a DoS vector and fill up somebody=E2=80= =99s hard drive just by sending packets. Logs will grow a lot faster after ma= king 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.=C2=A0 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=C3=BCller >> --=20 >> The road to Hades is easy to travel. >> -- Bion of Borysthenes > --===============1919961220534232743==--