[asterisk-dev] Rate limiting traffic to address potential DoS issues?

[Rich Adamson]

Andrew Kohlsmith wrote:
> On Saturday 07 October 2006 11:28, Rich Adamson wrote:
>> I'd suggest making two important tunable parameters accessible from some
>> conf file though;
>>   1. number of improper/bogus signaling packet threshold
>>   2. amount of time before clearing the able
>> Something like... after 10 bogus attempts, add the IP address in the
>> table and stop responding. Then after 60 seconds, clear that IP address
>> from the table (and start over).
> 
> I'd add one more tunable parameter: improper/bogus signaling packet count 
> expire time.  i.e. if you have the limit set to 10 bogus packets in 30s, it 
> would trip off, but if 9 were received in 30 seconds and at the 32nd second a 
> 10th would come in, the 1st of the 9 would have "aged out", and thus you'd 
> still be at 9 packets.
> 
> I thought of %age too, but you'd still need to keep track of the time the 
> bogus packet came in so it'd be *additional* code.
> 
> I'm thinking specifically about "sort of" broken clients being improperly (and 
> regularly) ignored due to too simplistic an algorithm.  SIP's an enormous 
> protocol and Asterisk needs to deal with half-assed peers *all* the time.

Really had not thought to much about the source of the "improper/bogus" 
packets, but since I'm heavily involved with I/T security assessments, 
my comments were more oriented towards what might reduce the load on an 
asterisk box when a hacker (or otherwise tosses packets at asterisk. 
Wasn't thinking at all in terms of broken clients and such.

If were talking about hacking attempts, then xxx number of attempts 
within yyy number of seconds should cause an account lockout (and log 
entry generated. Fairly simply logic to dump that traffic.

But if that's expanded to include sip packet anomalies from half-backed 
clients, it would seem that would add a significant amount of coding 
(and thus processing cycles).

Is this thread oriented towards one or both of those?