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

[Tim Panton]

On 27 Sep 2006, at 00:06, Steven wrote:

> On Tue, 2006-09-26 at 17:02 -0500, Jason Parker wrote:
>> ----- Kevin P. Fleming <kpfleming at digium.com> wrote:
>>> A community member has communicated to me a couple of issues  
>>> where if
>>> he sends large volumes of correctly-formatted (but otherwise  
>>> invalid)
>>> packets at Asterisk channel drivers, Asterisk behaves quite  
>>> poorly. In
>>> general it does not crash, but it will lose calls, respond very
>>> slowly, etc.
>>>
>>> I have been loath to start trying to build remediation for this into
>>> Asterisk itself, since that's a very slippery slope and we could end
>>> up spending the next six months trying to come up with new attack
>>> vectors and then coding to deal with them. In addition, at least  
>>> in my
>>> opinion, there are good, free tools already to do this sort of thing
>>> (rate limiting of incoming traffic), as well as solid commercial
>>> products.
>>>
>>> However, I'd like to get the opinions of our developer  
>>> community... do
>>> you think this is something we should attempt to address within
>>> Asterisk itself, or we are better off to post some 'best practices'
>>> documents that demonstrate ways that existing tools can be used to
>>> combat these attacks?
>>>
>>
>> Let's look at other apps (say, apache) for an example of something
>> similar.  What happens if you throw thousands of requests at apache
>> per second?  It's going to die.  And why shouldn't it?  Stuff like
>> this, in my opinion, is best handled at the firewall level, or  
>> perhaps
>> with a load balancer of sorts.  Sure, we can (and definitely should)
>> continue to improve, so that we can *PROPERLY* handle higher call
>> volumes, but in this case, what happens if they just resort to a good
>> old packet flood?
>
> 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 <critch at basesys.com>


What's more apache has an optional module
(mod_dos ?) which applies some extra defensive strategies
when it thinks it is being dos'd. We had to enable this on
a server for a customer a while back.

In general I think these things should be handled at the
layer that has the most ability to deal with that class of attack.

So routers and firewalls should deal with spoofed and malformed
packets. Gateway devices should deal with filtering
'untrusted/unpermitted' (but otherwise valid) requests and
core systems should deal with fine-grain permission/resource
allocation.

Asterisk is a 'core system' but some of us also use it as a gateway
device too.
I'd guess that means that we could/should look at adding some
(optional) defensive code to do request filtering.


Tim Panton

www.mexuar.com