Re: Limit rule for ICMP not working properly?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

IMHO, you shouldn't try to limit the packets only with a single ACCEPT
rule (this doesn't work in most cases).
Your "icmp limit" rule isn't limiting anything - only indicates which
icmp-echo frequency will be authorized. So, when authorized by limit
rule, the following icmp-echo sequences will be considered
established.

To set packet limits, make this in a new chain.

iptables -N icmplimit
iptables -A icmplimit -m limit --limit 8/s -j ACCEPT
iptables -A icmplimit -j DROP

iptables -A INPUT -p icmp --icmp-type echo-request -j icmplimit

And it will be best if you use hashlimit.


2013/9/5 podo <podo@xxxxxxx>:
> Hi Phil,
> Yes, I ment the 3th rule (Established accept).
>
> Please what do you mean by "same ID" ? And is this not exactly the problem ?
> nf_conntrack is even not needed, when only the first rule is present:
> -A INPUT -p icmp -m icmp --icmp-type 8 -m limit --limit 1/sec -j ACCEPT
>
> ICMP should not be tracked as established...
> In my opinion the behaviour is not correct.
>
> Podo
>
> -----Original Message-----
> From: Phil Oester [mailto:kernel@xxxxxxxxxxxx]
> Sent: 05 September, 2013 17:12
> To: podo
> Cc: 'netfilter'
> Subject: Re: Limit rule for ICMP not working properly?
>
> On Thu, Sep 05, 2013 at 04:58:27PM +0200, podo wrote:
>> Hi,
>>
>> the default is DROP:
>>
>> iptables -L -n -v
>> Chain INPUT (policy DROP 314 packets, 98684 bytes)
>> pkts bytes target     prot opt in     out     source
>> destination
>>   963 66540 ACCEPT     tcp  --  *      *       0.0.0.0/0
>> 0.0.0.0/0
>>    29  1740 ACCEPT     icmp --  *      *       0.0.0.0/0
>> 0.0.0.0/0            icmptype 8 limit: avg 1/sec burst 5
>>    39  2836 ACCEPT     all  --  *      *       0.0.0.0/0
>> 0.0.0.0/0            state ESTABLISHED
>>
>> Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
>> pkts bytes target     prot opt in     out     source
>> destination
>>
>> Chain OUTPUT (policy ACCEPT 5384 packets, 387K bytes)
>> pkts bytes target     prot opt in     out     source
>> destination
>>
>> The problem is, that the second rule gets hit, even if it shoud not (my
>> opinion). ICMP can not be "established". Or ?
>
> I think you mean _third_ rule in the above example.  When you successfully
> ping the box, an entry is added to /proc/net/nf_conntrack.  Until that
> entry expires (30 seconds by default for icmp), then any additional icmp
> packet with the same ID will match that conntrack entry and be considered
> "established".
>
> Wait > 30 seconds between (single) pings and you should not see the
> established
> rule hitcount increasing.
>
> Phil
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux