[SR-Users] loose_route security

[Alex Balashov]

Eric,

On 04/10/2011 08:09 PM, Eric Hiller wrote:

> As I look and play with loose_route functionality it seems that by
> simply placing a route: proxyip;lr header in my invite I can bypass any
> and all security otherwise built into the configuration. Is this the way
> everyone has it? I have been unable to find any configuration examples
> online that show how to secure/restrict access to loose_route?

You are quite correct, but this concern is overplayed because ultimate 
security responsibility is incumbent upon the UAS;  you have to 
remember, Kamailio's still a proxy, and proxies just pass messages.  The 
loose-routed sequential request does not somehow gain ipso facto 
authenticity simply by virtue of having been relayed by a proxy.  A 
spoofed request will be invalidated by the UAS the same way as any 
request sent to it directly.

You could digest-challenge sequential requests (with proxy_authorize() 
and proxy_challenge()), and some people choose to do that as a matter of 
security policy.  There is, however, often conceptual reluctance to 
challenge requests such as BYE;  it seems like there could be some 
drawbacks to not passing along a call hangup just because digest 
authentication fails.  This is a contested matter.

Another approach is to check if the message belongs to a known (tracked) 
dialog, if you are using the dialog module:

 
http://www.kamailio.org/docs/modules/3.1.x/modules_k/dialog.html#id2966270

I actually submitted the patch that implemented is_known_dlg() out of 
the very same concerns that you have.

In practical terms, however, to spoof a sequential message successfully, 
the sender would have to provide the right Call-ID, To tag, and branch 
ID at least.  Failure to provide any of these correctly down to the 
letter should result in the UAS rejecting the request.

So, the only big deal that I can see with having a proxy relay these 
messages willingly is that it could become a vector for some sort of 
DDoS attack, but to work, the attack is reliant on the coincidence of an 
awful lot of factors.  In practice, it's not that big of a deal for most 
installations.

-- 
Alex Balashov - Principal
Evariste Systems LLC
260 Peachtree Street NW
Suite 2200
Atlanta, GA 30303
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/