Don't you hate it when someone starts messing with your stuff? I do. When someone complains their VOIP phone system is being attacked, I simply say the same things over and over, so now it's time to blog it and help myself from repeating "what they should have and why they should have it". I definitely like the pfSense firewall to sit in front of my customers sipXecs PBX systems. I use them in-house as well.
One thing that has been too prevalent lately is the scripts (i.e. sipvicious) that seem start using the registrar and proxy resources in systems if left unattended.
If your business uses SIP and uses the standard layout for it, it means SIP runs on port 5060 to the outside world, so that also means people can "mess with it". At the same time, if you want to receive a sip call from anyone in the world, it is needed to be there. It's like having a telephone and not being able to control who can ring (call you). That's the standard idea in telephony is to let all calls come in.
Sipvicious and variants are different, in that they do not typically to to make calls to you. They try to use well known usernames and passwords to determine if your system will legitimately allow them to make calls. This is also known as toll fraud. There are some good protective measures you can take with toll fraud, but I want to concentrate on just mitigating the attack, how and why you should (if you can). So make sure you always use strong passwords for your SIP user accounts, because it tries a dictionary attack against the system.
What can happen is your phones can start to have problems registering (or re-registering) their line(s) with your system. As a result you do silly stuff like reboot the box. One hint here: stop thinking its a darn windows PC. I know sometimes a reboot makes sense, but a lot of people just do that to see their problem "go away" for a while, then come back. So they always think there is something wrong with the phone system software. Think again.
If you support remote users you need to understand "how many" lines are associated with those remote users. If you have 5 remote users, with two lines each, that's a total of ten lines. So with the right firewall this is easy to address.
Example: In pfSense, go to--Firewall>Rules>EDIT the rules for 5060/udp and 5060/tcp and in ADVANCED limit the connections to 10 connections every 30 seconds.
What you will find is that when a sipvicious script is run again against your system, it has very little effect on your system.
NOW if you have an attack, look at your sip logs and determine where the attack came from. Here is a real world example:
---BEGIN LOG SNIPPET--- 010-10-09T01:40:37.228840Z":925117:INCOMING:INFO:sip.sipdomain.com:SipClientUdp-8:41C52940:SipXProxy:"Read
010-10-09T01:40:37.228840Z":925117:INCOMING:INFO:sip.sipdomain.com:SipClientUdp-8:41C52940:SipXProxy:"ReadSIP message:\n----Local Host:XXX.XXX.XXX.XXX---- Port:5060----\n----Remote Host:220.127.116.11---- Port: 5085----\nOPTIONSsip:100@XXX.XXX.XXX.XXX SIP/2.0\r\nVia: SIP/2.0/UDP18.104.22.168:5085;branch=z9hG4bK-4251521253;rport\r\nContent-Length:0\r\nFrom: \"sipvicious\"<sip:firstname.lastname@example.org>;tag=3438643631646633313363340133363635323839363731\r\nAccept:application/sdp\r\nUser-Agent: friendly-scanner\r\nTo:\"sipvicious\"<sip:email@example.com>\r\nContact:sip:firstname.lastname@example.org:5085\r\nCSeq: 1 OPTIONS\r\nCall-ID:247763875582352644695379\r\nMax-Forwards:70\r\n\r\n====================END====================""2010-10-09T01:40:37.232191Z":925118:AUTH:INFO:XXX.XXXXXXXX.com:SipRouter-11:41E54940:SipXProxy:"EnforceAuthRules[400_authrules]::authorizeAndModify no permission required for call 247763875582352644695379"
---END LOG SNIPPET---
In this case the attack came from a GoDaddy hosting account (based on the origination IP address) and it simply called the system auto attendant, which is a waste of proxy and media system resources. Sometimes the attacks come in a large blocks from certain countries. If you don't mind not getting SIP based calls directly from that country then I suggest you add the "CountryBlock" package (if you use pfSense, that is) and choose the country the attack came from to block it entirely. You can of course, block the IP it came from entirely or its netblock, and setup scripts to autodetect and protect against these types of issues, but what I find is if you do some basics when you deploy, and have the right stuff deployed, you will typically be "fine".
Also, if you don't support remote users, and use sipXecs, you don;t need port 5060 open, or can micromanage when and if you need it open at all.
Next - Automatically fighting back...