> > 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.
On Wed, Feb 11, 2009 at 4:42 PM, Scott Lawrence <[email protected]> wrote: > > 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. We can restrict it that way. However, the following call would not go through : Currently, if I know your public IP address, I can simply send an INVITE to num...@sipxbridge-public-ip-address and right now (i.e. in sipxbridge today), that call will go through. You would not need to have an account with any ITSP or even be calling from a phone to make a call to sipxbridge. We will need to disallow this case as you state. We are, however, missing some configuration soupport. We would need to add some additional support in sipxconfig for cases that do not require registration but which do send INVITE from an Inbound Proxy ( not the same as the ITSP Registrar field that we have today). I have come across ITSPs that support redundancy where the IB proxy can be one of a list of addresses (an example of such a setup would be AT&T) which would require you to know all inbound proxy server addresses so this would imply we need to support a list of such addresses in the configuration field (AT&T does not support DNS SRV - they directly use IP addresses for configuration). > >> 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. Correct. That would need to be solved at a different level. We cant do anything about that in sipxbridge. > > > > -- M. Ranganathan _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
