What is the limitation of iptables's limit option?

Hi all,

I had added a rule to my linux box to prevent "Ping flooding".
Actually, i limit ICMP packet to be accepted 253 times at maximum
within a second by the limit extension option. The rule looks like
this
"ipatbles -t nat -A PREROUTING -p icmp --limit 253/s -j ACCEPT"
But when i use packet generator with sniffer to test this fucntion, it
doesn't always work. If i send each icmp packets with 10 millisecond
delay, it works fine, but when i doing this with each packet 3
millisecond delay, it seems crash(the rule doesn't match, only few
packets match this rule, other goes to next rules). It seems packets
are too fast to process by iptables and iptables can just handle
packets with time interval greater than 3 millisecond. Does this a
kernel timer issue or any ideas?


thanks for your comments.

Nick Wu

Nick Wu wrote:

> Hi all,
>
> I had added a rule to my linux box to prevent "Ping flooding".
> Actually, i limit ICMP packet to be accepted 253 times at maximum
> within a second by the limit extension option. The rule looks like
> this
> "ipatbles -t nat -A PREROUTING -p icmp --limit 253/s -j ACCEPT"
> But when i use packet generator with sniffer to test this fucntion, it
> doesn't always work. If i send each icmp packets with 10 millisecond
> delay, it works fine, but when i doing this with each packet 3
> millisecond delay, it seems crash(the rule doesn't match, only few
> packets match this rule, other goes to next rules).

And it works like it should work. "Limit" modulue allows to define how many
packets can hit the 'target' (after -j), if limit is exceeded the rule will
be passed over. The solution is easy: add one more rule (after yours) that
blocks all ICMP packets.
BTW why are you doing filtering in 'nat' table? This should be done in
'filter' table (INPUT or FORWARD chain).

--
Greets
adeon

Nick Wu <(E-Mail Removed)> wrote:

> I had added a rule to my linux box to prevent "Ping flooding".
> Actually, i limit ICMP packet to be accepted 253 times at maximum
> within a second by the limit extension option. The rule looks like
> this
> "ipatbles -t nat -A PREROUTING -p icmp --limit 253/s -j ACCEPT"

Avoid filtering in "-t nat PREROUITNG" chain, use "-t filter
FORWARD and INPUT" instead.


> But when i use packet generator with sniffer to test this fucntion, it
> doesn't always work. If i send each icmp packets with 10 millisecond
> delay, it works fine, but when i doing this with each packet 3
> millisecond delay, it seems crash(the rule doesn't match, only few
> packets match this rule, other goes to next rules).

Your rule above means explicitly written:

.... -p icmp --limit 253/s --limit-burst 5 -j ACCEPT

I explain the limit extension always with a leaky bucket
analogy. In your case, the bucket can hold up to 5 packets
(--limit-burst) and the buckets leaks out 253 packets per
second (--limit).

So, if you send one packet each 10 ms the bucket does not fill
up because the packets leak out at a quicker rate (100 pkts
per second in vs. 253 pkts per second out). So the rule matches
for *each* incoming packet.

However if you send each 3 ms a packet the packets come in
quicker (333 pkts per second) than they leak out (253 pkts
per second). So the bucket fills up and overflows for the
first time after 60 ms. In this time 20 packets come in and
match the rule, but only 15 leak out.

So you get the following sequence:
20 packets match, 1 packet doesn't match, 3 packets match,
1 packet doesn't match, 3 packets match, etc

See also following link
http://www.netfilter.org/documentati...g-HOWTO-7.html


Note that if a limit rule does not match, the packet is
*not* automatically rejected; iptables just inspects the
next rule as usual. Thus, if you want to rate limit you
need something like

iptables -N ICMP_FLOOD_CHECK
iptables -A ICMP_FLOOD_CHECK --limit 253/s -j ACCEPT
iptables -A ICMP_FLOOD_CHECK -j DROP

iptables -A INPUT -p icmp -j ICMP_FLOOD_CHECK
iptables -A FORWARD -p icmp -j ICMP_FLOOD_CHECK


HTH

Ciao, Horst
--
»When pings go wrong (It hurts me too)« E.Clapton/E.James/P.Tscharn