Hello! I have been thinking about measures that can mitigate DOS attacks in SIPXBRIDGE.
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. 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. 4. One can also flood a user's voice mail box (possibly with obscene language) and do other nasty things. 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). 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 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? Thanks Ranga P.S. I need to do some reading of references. Anybody have a subscription to IEEE Explore? There is a 2005 issue devoted to SIP DOS attacks. http://ieeexplore.ieee.org/Xplore/login.jsp?url=/stamp/stamp.jsp?arnumber=1638123&isnumber=34342 Any IEEE members around? _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
