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

[John Lange]

On Fri, 2006-10-06 at 11:50 -0500, Kevin P. Fleming wrote:
> ----- John Lange <j.lange at epic.ca> wrote:
> > This particular suggestion was in response to one specific type of
> > attack. At the moment Asterisk has a limit on the number of
> > authentication requests it can handle at one time. An attacker
> simply
> > has to flood the server with a number of 1/2 open authentication
> > requests and Asterisk's authentication table will fill and stop
> > responding.
> 
> There is no 'authentication table'. There is a linked list of
> structures for open calls, and that list can grow very large and cause
> SIP channel processing to get very slow, but it can never get full
> (except for a server getting to completely memory starved).

Sorry, I admit I have no idea what the actual impact on Asterisk was
only that it was bad.

> In IAX2 there is a hard limit on the number of outstanding
> connections, so when this issue was raised we added a 'maxauthreq'
> parameter to IAX2 users to limit the number of half-open connections a
> single user could have. It would certainly make some sense to add the
> same sort of limiting for SIP users.

The problem with this approach is it makes it it trivial DOS an account.
The server itself is protected but individual accounts can be blocked
with a small number of 1/2 open authentication requests.

Granted you could argue that discovering what account names are in use
on the server might not be easy by unfortunately in most cases it is
easy. For example, many providers use account names based in some way on
the DIDs assigned (because it makes the dial plan easy). So if you new a
provider had DIDs in the range 555-1000 to 555-6999 you could DOS all
the accounts in a matter of a few seconds.

Still seems to me that the syn-cookie approach is the best all-around
solution.

But again I want to reiterate that I'm not a SIP expert nor have I
looked closely at the SIP authentication code in Asterisk so I have no
idea how significant this change would be.

-- 
John Lange