Re: Proposal: Drop iptables logging rate-limit

[Tim FitzGeorge <ipfr@tfitzgeorge.me.uk>]

[-- Attachment #1: Type: text/plain, Size: 2811 bytes --]

Hi,

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