> -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of Theo > Zourzouvillys > Sent: Sunday, February 22, 2009 2:33 AM > > While we've all known about the issue forever, i've never sat down to > work out how bad it really is. > The results are pretty scary: "best" case scenario is a 1:10 > amplification, and "worst" i can easily get a 1:350 amplification by > writing a quick script. > > Additionally, out of every single vendor's implementation i looked at, > i've not yet found 1 that isn't vulnerable to being used in an attack: > phones, proxies, and SBCs can all be made to participate.
I'm not debating your draft's premise, but that last statement is highly dependent on the system and deployment's configuration. For the remainder of this I'll use the term "SBC", but as far as I know proxies can do this too. SBCs can be and almost always are configured to only accept requests from registered UA's. So let's say you guessed one or many of them correctly; both their AoR's and guessed their full contact URI's (including username) and Via/Layer-3 IP:ports as well. In typical deployments the request will be challenged, so the amplification is the 100 and 401/407 challenges, not a full call's worth of 18x/200 and RTP. (And in practice there are some tricks the SBC can do to reduce actual amplification to 1:1, but it's rare to enable it - if amplification attacks are actually encountered, then this may change) So the next issue is attack volume, and again it depends. SBCs can and often do throttle the number of requests they'll accept in any time period from any given UA. So they won't flood the target UA with bogus responses, because they won't accept that many spoofed requests from it to begin with - for some vendors they have hardware that will silently drop the excess. What will sometimes happen is the SBC will dynamically black-list a flooding UA, so that if you successfully spoof one you can knock it out of service anyway, for a period of time. Of course this triggers traps to notify the admins to look into it, but at least temporarily the damage is done. But that's by design - if you're successfully spoofing another UA, then the best an SBC can do is limit the impact of that to affect only the spoofed UA and not impact other users. The harder problem is SIP trunks, a la IP-PBX's. If they aren't a registering type of PBX, then their addresses are usually provisioned in the SBC's in terms of ACLs; both layer-3 ACLs and layer-7, such that you'd still have to spoof more than just IP:port. But it's a harder problem because it's easier to guess that stuff for an Enterprise than from a subscriber, and because they often aren't challenge-able. They're still usually throttled; and in theory potentially blacklisted, though that's less common to enable for PBX connections. The only good side of it is the bigger the Enterprise, the more likely the SIP trunk is over a VPN of some type, where the spoofed requests would have to come in on that VPN to be processed. BTW, we do recommend to providers that they employ uRPF on their edge routers, and some can and do. Others don't have that ability or don't own the whole network, or don't want to take the performance impact of doing it on their routers. (because many routers take a hit for uRPF) -hadriel _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [email protected] for questions on current sip Use [email protected] for new developments on the application of sip
