From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: Proposal: Drop iptables logging rate-limit Date: Mon, 15 Jul 2019 11:29:23 +0100 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0830372642993850781==" List-Id: --===============0830372642993850781== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, > On 14 Jul 2019, at 15:56, Peter M=C3=BCller wr= ote: >=20 > Hello *, >=20 > 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: >=20 >> iptables -A LOG_DROP -m limit --limit 10/minute -j LOG > (snip taken from /etc/init.d/firewall) >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > @All: Thoughts, please. Is anyone aware of potential trouble? I generally agree with your points. I am not sure where the number is even co= ming from. We have carried this over from the beginning of IPFire without thi= nking about it again. The motivation why this is there is probably that logging is an expensive ope= ration 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 > If not, I will send in a patch within this week. >=20 > Thanks, and best regards, > Peter M=C3=BCller > --=20 > The road to Hades is easy to travel. > -- Bion of Borysthenes --===============0830372642993850781==--