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
