how to best limit "rate of rejects"

how to best limit "rate of rejects"

[Christoph Anton Mitterer]

Hi.

Using the same setup as described here  
(http://thread.gmane.org/gmane.comp.security.firewalls.netfilter.general/40849) I have one  
problem:

At least ping (if not limiting with -c), and possibly other service,  
just goes crazy and massively sends ECHO request when the packets are  
rejected (because no IPsec handling would be done).
This really eats up my CPU ;)


Is there some smart way to just limit the rate on those rejects? e.g.  
something like a "wait with sending the reject for a second" target?
And would that even make sense?

I've tried it using the limit match and following rules (see the other  
rules in the link above):
-A ipsec-only-in        ! --protocol esp  -m limit --limit 10/second    
  -j REJEC
T  --reject-with icmp-admin-prohibited
-A ipsec-only-in        ! --protocol esp                                
  -j DROP
-A ipsec-only-out       ! --protocol esp  -m limit --limit 10/second    
  -j REJECT  --reject-with icmp-admin-prohibited
-A ipsec-only-out       ! --protocol esp                                
  -j DROP

The intention was that if the limit is reached, no REJECTS are no  
longer produced but the packages are dropped (and the client then  
hopefully waits some time before sending again).
But this is obviously rather ugly and doesn't work very well.


Are there any other possibilities?


Thanks,
Chris.

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

Re: how to best limit "rate of rejects"

[Jan Engelhardt]

On Wednesday 2010-10-06 14:21, Christoph Anton Mitterer wrote:

> Hi.
>
> Using the same setup as described here
> (http://thread.gmane.org/gmane.comp.security.firewalls.netfilter.general/40849)
> I have one problem:
>
> At least ping (if not limiting with -c), and possibly other service, just goes
> crazy and massively sends ECHO request when the packets are rejected (because
> no IPsec handling would be done).
> This really eats up my CPU ;)
>
>
> Is there some smart way to just limit the rate on those rejects? e.g. something
> like a "wait with sending the reject for a second" target?

-m hashlimit --hashlimit 1/second

> And would that even make sense?

Yes, applications for hashlimiting have been found 
http://jengelh.medozas.de/documents/Chaostables.pdf

Re: how to best limit "rate of rejects"

[Christoph Anton Mitterer]

Hi Jan.

On Wed, 2010-10-06 at 14:45 +0200, Jan Engelhardt wrote:
> > Is there some smart way to just limit the rate on those rejects? e.g. something
> > like a "wait with sending the reject for a second" target?
> 
> -m hashlimit --hashlimit 1/second

Which one do you mean (just --hashlimit seem to not exist).

And as far as I understand the documentation, this is the same as limit,
and it's just for matching,... so if the rate is exceeded the rule would
simply no longer match and I'd have again such a packet burst?


Cheers,
Chris.

Re: how to best limit "rate of rejects"

[Jan Engelhardt]

On Thursday 2010-10-07 20:30, Christoph Anton Mitterer wrote:

>Hi Jan.
>
>On Wed, 2010-10-06 at 14:45 +0200, Jan Engelhardt wrote:
>> > Is there some smart way to just limit the rate on those rejects? e.g. something
>> > like a "wait with sending the reject for a second" target?
>> 
>> -m hashlimit --hashlimit 1/second
>
>Which one do you mean (just --hashlimit seem to not exist).

--hashlimit is a backwards-compatible alias for --hashlimit-upto.

>And as far as I understand the documentation, this is the same as limit,
>and it's just for matching,...

hashlimit offers more possibilities (at the cost of a bit of computing 
of course), such that there is only one hashlimit configuration of many 
that mirrors limit's behavior, which is when using --hashlimit-mask 0 
--hashlimit-mode whateverpickone.

>so if the rate is exceeded the rule would
>simply no longer match and I'd have again such a packet burst?

You asked for reply rate reduction. So

 -p tcp --dport 23 -m hashlimit --hashlimit 1/s --hashlimit-mode srcip 
	--hashlimit-mask 24 -j REJECT
 -p tcp --dport 23 -j DROP

will cause no more than one ICMP unreachable to be emitted per second 
for all the telnet attempts coming from an exemplary /24 netblock.