On Wed, 2009-02-11 at 15:25 -0500, M. Ranganathan wrote: > Hello! > > I have been thinking about measures that can mitigate DOS attacks in > SIPXBRIDGE.
You're thinking of "DoS" == "Denial of Service". "DOS" is an old operating system :-) > Problem Statement > ============== > > Sipxbridge is a Session Border Controller. It sits on the edge between > the public network and the private network and as such is a good place > to add DOS mitigation features. Because of the nature of the service ( > i.e. being able to take calls from any provider ) and the nature of SIP > and the function being provided by sipxbridge. 100% DOS attack > prevention is impossible unless we constrain inbound calls to only be > from trusted sources. This is clearly too restrictive for most > purposes. Clearly how? I don't think that's clear at all... > The purpose of this thread is to explore what can be done and > how to approach the problem. > > Here then are *some* vulnerabilities in SipXbridge : > > 1. SipXbridge will accept calls from any IP address just like your phone > will accept a call from anywhere. SipX will not authenticate calls > originating from a foreign domain. Hence anybody can call into your > network (just like anybody can call your phone number). This is fine if > that is the way you want it but unlike a PSTN network which is > regulated, there is no control over inbound calls. So you can have DOS > attacks from sources that simply flood sipx with INVITEs, or even worse, > INVITEs with various errors and unresolvable host names etc. and > SipXbridge currently will not be able to do anything about it. > > 2, RTP relay can be subject to DOS attack by simply calling in, > transferring to the park server and never hanging up. > > 3. Take over of sipx services such as call park etc. can be easily > accomplished if one knows what extensions Park Orbits are assigned to > for example, and an AA is configured ( a common configuration ), one can > call the AA, issue DTMF for the park extension and fill up the park orbit. Question for Woof - does the AA allow that? It probably shouldn't. > 4. One can also flood a user's voice mail box (possibly with obscene > language) and do other nasty things. Yes, but that's possible even from legitimate sources using reasonable calling patterns. > Some possible starting points : > > 1. Accept calls only from configured ITSP accounts. > > Not a very good solution. The problem of course is you have no control > over the ITSPs that your callers will pick. You will effectively > restrict inbound calls to only those ITSPs you know about and have > accounts with. Unfortunately we cannot authenticate inbound requests > from foreign domains ( defeats the whole purpose of unrestricted inbound > calling). I don't understand why you think that's unreasonable. If I get my phone service from BT, I wouldn't expect that interface to get calls from NTT. Remember: it is NOT the job of sipXbridge to be a general purpose Internet Calling interface - it is the job of sipXbridge to be the interface to an ITSP. Why would I ever get a call from an ITSP that I had no relationship with? If I allow direct SIP calls from the internet (to sip:[email protected]), then those do not need to go through sipXbridge. > 2. Black list of bad IP addresses for inbound INVITE from foreign domain. > > However, a "good ITSP" can have "bad subscribers". Can filter by > domain. > > 3. Rate limit INVITE from IP addresses. > -- How to select rate? > > 4. Observe the activity pattern from an IP address/user name and ban on > that basis. > -- What pattern to observe? > > It is a pity that ITSP providers do not provide signed > P-Asserted-Identity header for calls headed to the PBX. Otherwise we > could do some level of filtering on that basis. Perhaps that is > something we need to push to SIPCONNECT 1.1 Better - all SIP should be over mutually-authenticated TLS. > Please respond to this thread with ideas so we can discuss 1. Is this is > a problem worth looking at or is this all moot because it can be handled > at as firewall rules distinct from sipxbridge. Do we need SIP Specific > support in SipXbridge ? and 2. Assuming the answer to 1 is YES, what > can be reasonably accomplished in the near term? What guarantees or > assurances can be provided to our customers? Bear in mind that you've not touched on the most basic of DoS attacks - ones that happen at the IP level and just hammer your interface (or the router in front of it) so badly that the SIP can't get through. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
