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

[Kristian Kielhofner]

Steven wrote:
> 
> 
> No, apache won't die. Apache will stop answering new requests till a
> child process is able to process the request. From the outside it might
> look like apache has died as it is possible that the DOS is continually
> eating the children's time, but apache is trying it's best to keep above
> water by not answering anymore than it was configured to. 
> 
> So I guess if you want to use apache as an example, should we set up the
> VoIP channels to have a max possible channels in use? Doesn't seem like
> it would be wise with non call related messaging still being attackable.
> Even with an external app making sure no one host is sending too many
> packets, how many hosts would it take to generate enough packets to
> still get the same effect? 

Steven,

	On all of my boxes I add EVERY incoming call into a group with 
SetGroup/CheckGroup and set a max calls global variable for that system. 
  If total number of incoming calls exceeds MAXCALLS, hangup on new 
calls coming in.  It keeps me from running a Soekris into the ground 
with too many calls...  :)  I never thought about using it for DOS 
mitigation until now.  It would be nice to have more fined gained 
control (like SER), but I guess that's why we are having this discussion!

	I'm pretty sure that we are probably talking about (or should be 
talking about) two different issues here:

1)  Preserving system resources (and to some extent all user's services) 
by limiting the call capacity of an Asterisk server with a specific 
configuration (just like apache).  I feel that this can already be done 
pretty well, but it could be better.

2)  Dealing with what I assume to be mostly protocol-specific issues 
such as malformed SIP headers - whether intentional as part of an attack 
or perhaps just a poorly implemented device.  Obviously Asterisk already 
does this - I have sent SIP INVITEs with really, really messed up 
headers and SDPs.  Asterisk does what it can, but it isn't always 
pretty...  How much checking should it do?  How should these checks 
relate to #1?

--
Kristian Kielhofner