Bug in the wiki

Bug in the wiki

[Nuno Gonçalves]

https://wiki.nftables.org/wiki-nftables/index.php/Simple_ruleset_for_a_server

I believe in this example ct will accept echo-request regardless of
the rate limit.

To fix it, the line

> icmp type echo-request limit rate 5/second accept

Must be followed by

> icmp type echo-request drop

Also the same for icmpv6.

And ct must be moved to the end of the chain.

I suggest this is changed in the wiki.

Thanks,
Nuno

Re: Bug in the wiki

[Frank Myhr]

On 2022/07/06 05:36, Nuno Gonçalves wrote:
> https://wiki.nftables.org/wiki-nftables/index.php/Simple_ruleset_for_a_server
> 
> I believe in this example ct will accept echo-request regardless of
> the rate limit.
> 
> To fix it, the line
> 
>> icmp type echo-request limit rate 5/second accept
> 
> Must be followed by
> 
>> icmp type echo-request drop
> 
> Also the same for icmpv6.
> 
> And ct must be moved to the end of the chain.
> 
> I suggest this is changed in the wiki.
> 
> Thanks,
> Nuno


Hi Nuno,

The icmp and icmpv6 rules you refer to are in regular chains, both 
called by base chain "inbound" that has policy drop and no other icmp / 
icmp6 rules. Therefore there is no need for the additional "drop" rules 
that you suggest; packets arriving faster than the limit rates will be 
dropped by the calling base chain's default policy.

Best regards,
Frank

Re: Bug in the wiki

[Nuno Gonçalves]

On Wed, Jul 6, 2022 at 10:59 AM Frank Myhr <fmyhr@fhmtech.com> wrote:
> Hi Nuno,
>
> The icmp and icmpv6 rules you refer to are in regular chains, both
> called by base chain "inbound" that has policy drop and no other icmp /
> icmp6 rules. Therefore there is no need for the additional "drop" rules
> that you suggest; packets arriving faster than the limit rates will be
> dropped by the calling base chain's default policy.
>
> Best regards,
> Frank

I think ct (conntrack) will track it after the first accept and so the
rate limit becomes ignored.

This is what happens in reality. My understanding is that it's a bug
in this configuration. If the configuration is correct then it would
be bug (I'm on 5.18.9).

Can you give me a hint why you think ct wouldn't accept it forever
after the first accept?

Thanks!

Re: Bug in the wiki

[Frank Myhr]

On 2022/07/06 06:09, Nuno Gonçalves wrote:
> On Wed, Jul 6, 2022 at 10:59 AM Frank Myhr <fmyhr@fhmtech.com> wrote:
>> Hi Nuno,
>>
>> The icmp and icmpv6 rules you refer to are in regular chains, both
>> called by base chain "inbound" that has policy drop and no other icmp /
>> icmp6 rules. Therefore there is no need for the additional "drop" rules
>> that you suggest; packets arriving faster than the limit rates will be
>> dropped by the calling base chain's default policy.
>>
>> Best regards,
>> Frank
> 
> I think ct (conntrack) will track it after the first accept and so the
> rate limit becomes ignored.
> 
> This is what happens in reality. My understanding is that it's a bug
> in this configuration. If the configuration is correct then it would
> be bug (I'm on 5.18.9).

To be clear: you're testing this example ruleset and seeing unlimited 
echo requests being allowed in despite the limit rule?


> Can you give me a hint why you think ct wouldn't accept it forever
> after the first accept?

I'm going to have to defer to others with in-depth knowledge of ct. I 
suspect that if all of your echo requests come from the same source ip 
address, *maybe* the limit is ineffective as you suggest. I'd be very 
surprised if echo requests from multiple ip addresses are also immune to 
the limit.

Best regards,
Frank

Re: Bug in the wiki

[Nuno Gonçalves]

On Wed, Jul 6, 2022 at 11:22 AM Frank Myhr <fmyhr@fhmtech.com> wrote:
> To be clear: you're testing this example ruleset and seeing unlimited
> echo requests being allowed in despite the limit rule?
>
>
> > Can you give me a hint why you think ct wouldn't accept it forever
> > after the first accept?
>
> I'm going to have to defer to others with in-depth knowledge of ct. I
> suspect that if all of your echo requests come from the same source ip
> address, *maybe* the limit is ineffective as you suggest. I'd be very
> surprised if echo requests from multiple ip addresses are also immune to
> the limit.

Yes. I am testing and always and the bug is exposed with a flood ping,
for example, so from the same IP.

Yes, I agree that this should accept 5 new sources per second, but
each can then do unlimited requests.

That is why I suggest the wiki to be updated.

Thanks

Re: Bug in the wiki

[Frank Myhr]

On 2022/07/06 06:27, Nuno Gonçalves wrote:

> Yes. I am testing and always and the bug is exposed with a flood ping,
> for example, so from the same IP.
> 
> Yes, I agree that this should accept 5 new sources per second, but
> each can then do unlimited requests.
> 
> That is why I suggest the wiki to be updated.

Thanks for clarifying. Now I understand your need to also move the ct 
accept rule to the end of the "inbound" base chain to counter the ping 
flood from a single ip address.

I'm not going to update the wiki page just yet, for several reasons:

* I'm not the author of the example ruleset.

* In general I prefer to have ct accept rules near the top of base 
chains, as in the existing example. That way existing connections get 
matched and accepted as quickly as possible without having to first 
evaluate all the other rules in the chain.

* I agree that your modifications will counter a single-ip ping flood 
attack. Whether that attack is significant compared with, say, DDoS ping 
floods or attacks against other services, will depend on the particulars 
of your installation. If the single-ip ping flood *is* a big concern, it 
may be better to use a different ruleset construction with icmp in a 
dedicated chain.

* Most significantly: To me the behavior you describe smells like a bug 
in ICMP connection tracking, better fixed in ct than with nftables 
ruleset work-arounds. I expect a big part of the difficulty is caused by 
trying to track "state" of stateless ICMP. Even so, why does ct consider 
additional incoming echo requests to be part of the "connection"? 
Naively, it seems to me that ct should count only outgoing echo replies 
as part of the established connection, and that all incoming echo 
requests should be considered "new connections". Maybe that wasn't done 
because in practice it leads to too many conntrack entries. Hopefully 
someone more familiar with ct implementation will comment.

Best regards,
Frank

Re: Bug in the wiki

[Frank Myhr]

Thinking about it some more, maybe a better solution to single-ip ping 
flood is to accept them all as in current ruleset, but limit outgoing 
icmp rate per destination ip address.

Re: Bug in the wiki

[Nuno Gonçalves]

On Wed, Jul 6, 2022 at 12:26 PM Frank Myhr <fmyhr@fhmtech.com> wrote:
> * I agree that your modifications will counter a single-ip ping flood
> attack. Whether that attack is significant compared with, say, DDoS ping
> floods or attacks against other services, will depend on the particulars
> of your installation. If the single-ip ping flood *is* a big concern, it
> may be better to use a different ruleset construction with icmp in a
> dedicated chain.

The discussion about netfilter/conntrack approach is really not at my
level, but regarding the attack scenario, It's more of a total packets
issue.

If each source is allowed to send unlimited (let's say 100) packets,
then the attack could ramp at 100*5 packets per second, so after 60
minute could be at 1.8M packets/s.

This limits the reach of my knowledge about any of this :D I just
tried to get this configuration working for me.

Thanks

Re: Bug in the wiki

[B. Ohnsorg]

Am 06.07.22 um 13:26 schrieb Frank Myhr:
> On 2022/07/06 06:27, Nuno Gonçalves wrote:
> 
>> Yes. I am testing and always and the bug is exposed with a flood ping,
>> for example, so from the same IP.
>>
>> Yes, I agree that this should accept 5 new sources per second, but
>> each can then do unlimited requests.
>>
>> That is why I suggest the wiki to be updated.
> 
> Thanks for clarifying. Now I understand your need to also move the ct 
> accept rule to the end of the "inbound" base chain to counter the ping 
> flood from a single ip address.
> 
> I'm not going to update the wiki page just yet, for several reasons:
> 
> * I'm not the author of the example ruleset.
> 
> […]
> 
> Best regards,
> Frank

Add the suggested rule and add explanations to existing and new instead 
of replacing existing content? Let the reader choose who presumably 
knows best whether throughput or security is more important.