Bug 2181406

# nft add rule inet firewalld filter_IN_public_log ip saddr 192.168.1.131/24 \
   tcp dport 22 ct state { new, untracked } log prefix "IN_BOUND_XXXX " level info limit rate 2/day

FWIW, if we also add a reject like so:

# nft add rule inet firewalld filter_IN_public_log ip saddr 192.168.1.131/24 \
   tcp dport 22 ct state { new, untracked } log level warn prefix "IN_BOUND_BLOCK " limit rate over 2/day burst 1 packets reject

..then we see that also here the logged messages are not limited.
The reject makes it easier to see whether the limit gets applied at all,
and that seems to be the case: with above rule we see that SYN/new packets
get limited to 2/day.
The rate limits seems to be not applied to the log messages, though.

I wondered about this as potential workaround:

- create a new chain EXAMPLE
- create a nft rule which is rate limiting, and only for 2/day requests
  per day jumping into the new chain EXAMPLE
- inside chain EXAMPLE, one would
  have everything logged which passes by (effectively 2 requests per day)

Working towards that, I noticed that jumps to other chains are also not rate limited:

# create a new chain
nft add chain inet firewalld MYLOG

# from the chain we always run through, I was expecting just for 2 new packets/day we would jump to MYLOG:
nft add rule inet firewalld filter_IN_public_log ip saddr 192.168.4.0/24 tcp dport 22 ct state { new, untracked } limit rate over 2/day burst 1 packets jump MYLOG

# Then generate one log entry, to get notified every time the new chain is entered
nft add rule inet firewalld MYLOG log level warn prefix "MYLOG_IS_ENTERED "

=> When I try to then initiate 5 new connections to tcp/22
   after each other, I get 5 entries logged.
   So seems like the jump MYLOG is not rate limited, as it should per my
   understanding.

This is rate limited:
- rejects
This seems not rate limited:
- jump to another chain
- log directive

Hi!

There are several things going on here:

1) Statements in nftables rules are evaluated in order from left to right

The rule from comment 0:

| ip saddr 192.168.1.131/24 tcp dport 22 ct state { new, untracked } log prefix "IN_BOUND_XXXX " level info limit rate 2/day

will (if all previous matches match) always evaluate the log statement before the limit one. If logging for only the first two matching packets per day is desired, you have to swap the statements like so:

| ip saddr 192.168.1.131/24 tcp dport 22 ct state { new, untracked } limit rate 2/day log prefix "IN_BOUND_XXXX " level info

If the limit is reached, log statement won't be evaluated anymore.


2) Limit's "over" key inverts the match

While the above 'limit rate 2/day' will stop matching after the second packet
(on average), the 'limit rate over 2/day burst 1 packets' from comment 2 will
start matching after the second packet (also on average).

Matching here means "continue with the next rule statement", i.e. the jump is
then executed.


3) Burst value may lead to odd results when testing

A typical test of "limit to X packets, send X+1 packets" usually yields
unexpected results since it doesn't account for the burst value.


I'll close this ticket for now as I don't see a problematic behaviour. If you still experience problems with limit && log (not log && limit ;), please reopen.

Cheers, Phil

>>  1) Statements in nftables rules are evaluated in order from left to right

It looks like there rules are from firewalld. And indeed firewalld creates the rule in the wrong order, i.e. log then limit.

Should this should be reassigned to firewalld? A quick look shows this is a trivial fix on the firewalld side.

Upstream firewalld PR:

  https://github.com/firewalld/firewalld/pull/1103