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

[John Lange]

This discussion about SIP INVITE floods reminds me a lot of the
discussion in the late 90s about SYN floods. Here is a description of
SYN floods I found:

"The recipient will be left with multiple half-open connections that are
occupying limited resources. Usually, these connection requests have
forged source addresses that specify nonexistent or unreachable hosts
that cannot be contacted. Thus, there is also no way to trace the
connections back."

Sounds a lot like SIP INVITE flooding no?

The problem of SYN floods was solved using SYN Cookies and I'm wondering
if there isn't a similar solution that could be employed here? I'm not a
SIP expert but I've noticed that SIP uses a "nonce" number during the
authentication phase which seems to keep state.

If this number was changed to be a computed value based on the source IP
of the host and some other values such as username, password and time
then Asterisk would not have to keep a state table for authentication
requests. A reverse of the formula on the returned "nonce" value would
tell you if it was indeed a valid authentication.

A more detailed description of how syn cookie values are calculated is
here:

http://cr.yp.to/syncookies.html

Not being a TCP or SIP expert I might be way off here but comments?

John

On Tue, 2006-07-18 at 13:31 -0700, John Todd wrote:
> 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
> _______________________________________________
> --Bandwidth and Colocation provided by Easynews.com --
> 
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev
>