[asterisk-dev] Re: [Asterisk-Security] Day early and a dollar short? (IAX2 and SIP problems)

[John Todd]

At 11:34 AM -0500 7/18/06, Kevin P. Fleming wrote:
>
>----- John Todd <jtodd at loligo.com> wrote:
>>  Are we just as vulnerable with SIP from a
>>  similar threat?
>
>In a way, yes. The real problem with IAX2 is the inherent limit in 
>the number of calls that a single IAX2 implementation can be 
>involved in (due to the 15-bit call number limit). However, a SIP 
>server is vulnerable as well; if a peer sends INVITEs for a username 
>that requires authentication but never responds to the 401/407 
>messages that are returned, the server will have to hold the dialog 
>info state for those INVITEs in memory until the session timers 
>expire. Even without a built-in limitation in the protocol, it's 
>still ridiculously easy to consume large amounts of memory/CPU on 
>the target server.
>
>--
>Kevin P. Fleming
>Senior Software Engineer
>Digium, Inc.

OK.

[moving to -dev from -security, since this seems more like a -dev 
issue with the following suggestions.]

While not completely trivial, I can think of some reasonably easy 
ways to at least diminish this threat of un-ack'ed INVITE DoS floods:

  - For each user/peer, there could exist a user-specifiable (in 
sip.conf) counter that allows a certain number of pending un-finished 
INVITE (or any other authentication-based transaction?) exchanges. 
Let's call this value "X".  If  the number of pending INVITEs is 
larger than X, then reject any further INVITEs with an error message 
immediately.  This will not cure a DoS attack, but can narrow the 
focus of the problem.  It seems that this would not take a 
significant amount of memory to keep state, and in fact, I expect 
that the basic framework for this is already sort-of in place just by 
keeping track of pending INVITEs.  I would certainly make it 
per-peer, as some sites have large volumes of calls coming from 
specific, slow systems on the other side of the Internet and it would 
be best to give control of this number to the customer.  However, I 
would also install a default of 10, or some number that is higher 
than the count of INVITEs sent on a non-responsive host to eliminate 
confusion, as per the RFC suggestions.

  - Make such a counter for the entire system, including all possible 
SIP peers/users.  This would be specified in [general].

Implementing those two dampening methods would not eliminate the 
threat.  However, it would require the attacker to know a large 
number of valid usernames, because the number of pending INVITEs 
would then be a multiplication of ((valid usernames) * (number of 
permitted attempts on those username)) before Asterisk would switch 
into "fast-refuse" mode, which hopefully would consume less memory 
and have a service consumption profile similar to just sending bogus 
usernames.

  - As a last-ditch protective element, it may even be the case that 
after some higher value (let's call it "Y") then Asterisk quietly 
discards packets from that IP address OR username.  This would reduce 
the amplifier attack vector problem, and would also eliminate as much 
network and processor overhead as possible.

So, if all three methods are used, it should be the case that no 
"valid" SIP peers get error messages, attackers get [4xx, 5xx, 6xx] 
messages after a flood, and that very aggressive attackers get no 
replies at all after the first part of their flood.  As the timers 
expire on the first X INVITEs, then new replies are sent out to 
subsequent INVITEs until X queued INVITEs are reached again.

JT