SIP Register/DOS Attacks

Since implementing new monitoring tools I’ve noticed a lot of failed REGISTER events on our network.  Our SBC would issue a 4XX back to the originating UA, however the attempts continue. At one point I saw 200 register messages per second from a single IP.

I started to look a bit deeper into the REGISTER packet and found that the User-Agent is always “friendly-scanner”.

REGISTER sip:x.x.x.x SIP/2.0
Via: SIP/2.0/UDP 127.0.0.1:5060;branch=z9hG4bK-226458594;rport
Content-Length: 0
From: "100" 
Accept: application/sdp
User-Agent: friendly-scanner
To: "100"  
Contact: sip:123@1.1.1.1
CSeq: 1 REGISTER
Call-ID: 3348663663
Max-Forwards: 70

After a quick search I found that this is related to a script called SipVicious.

The author of SipVicious has included a tool called svcrash.py to shutdown the script on the attacking server.  This is the easiest route to shut down an attacker on a manual basis (You must assume that the attacker has not modified the python script, otherwise the below data is void).

Run svcrash.py on the server being attacked with the “-d” option set.

keith@lab1:~/Documents/sipvicious> ./svcrash.py -d 192.168.34.134
Attacking back 192.168.34.134:5060

Once the above is executed, the attacker should see the following on their server.

kcroxford@attacker:~/Desktop/sipvicious$ ./svcrack.py  -u10000 192.168.34.139
CRITICAL:root:Unhandled exception - please run same command with the -R option to send me an automated report
ERROR:root:Exception
Traceback (most recent call last):
File "./svcrack.py", line 460, in
sipvicious.start()
File "./svcrack.py", line 229, in start
self.getResponse()
File "./svcrack.py", line 175, in getResponse
crackeduser,crackedpasswd = _tmp
ValueError: need more than 1 value to unpack
WARNING:root:found nothing

If you have an Acme Packet SBC  you can request a copy of BCP 520-0052-00 from their Support Engineers. This is the Acme Packet Best Current Practices  on how to handle SIPVicious traffic. I believe that there is another way to handle this (which will exploit the weakness in svcrash.py) with a Header Manipulation Rule.  If I can confirm this as an option, I will update this blog entry.

If you are running an OpenSips proxy I found that Advantia Voip Systems has a write up on dropping traffic with  “friendly-scanner” within the User-Agent header.

All other SBCs :

This is the packet that svcrash.py generates :

SIP/2.0 200 OK
Via: SIP/2.0/UDP 8.7.6.5:5061;branch=z9hG4bK-573841574;rport

Content-length: 0
From: "100"; tag=676f6f643a6279653a61747461636b65723a
User-agent: Telkom Box 2.4
To: "100"
Cseq: 1 REGISTER
Call-id: 469585712
Max-forwards: 70

If your SBC can automatically generate a similar response to the attacker, you should be able to stop the attack.

Adtran – Multiple VRFs with Internet Access

I recently had to create a configuration that contained multiple VRFs that all NAT/PAT out the same ISP connection. There is also a managed circuit that connects back to the Managed Service Provider (MSP) for management. All dynamic routing configs will need to be placed in the global routing table (default vrf). For this example, assume that the MSP is in the GRT. 

To begin, we need to define our vrfs. For this example I will use the following :

ip vrf TENANT1 route-distinguisher 100:1
ip vrf TENANT2 route-distinguisher 100:2
ip vrf INTERNET route-distinguisher 100:100

 

We also need to enable the firewall for all of the VRFs that need Internet access:

ip firewall vrf TENANT1
ip firewall vrf TENANT2
ip firewall vrf INTERNET

Now we can configure our interfaces: 

interface vlan 1
  ip vrf forwarding TENANT1
  description TENANT1 – LAN
  ip address 172.25.0.1 255.255.255.0

interface vlan 2
  ip vrf forwarding TENANT2
  description TENANT2 – LAN
  ip address 172.25.0.1 255.255.255.0

interface vlan 100
  ip vrf forwarding INTERNET
  description Cox Communications – INTERNET
  ip address 66.1.1.2 255.255.255.248

 

We need to set a default route for the TENANT VRFs. We need an egress interface or IP address for this. As traffic is going to the same physical device, we must first configure a few loopback interfaces.

interface loopback 1
  ip vrf forwarding TENANT1
  description TENANT1 – Internet Route
  ip address 1.1.1.1 255.255.255.255

interface loopback 2
  ip vrf forwarding TENANT2
  description TENANT2 – Internet Route
  ip address 1.1.1.1 255.255.255.255

Then add the routes – Notice that the TENANTS both route to 1.1.1.1 as it is contain in both VRFs. 

ip route vrf TENANT1 0.0.0.0 0.0.0.0 1.1.1.1
ip route vrf TENANT2 0.0.0.0 0.0.0.0 1.1.1.1
ip route vrf INTERNET 0.0.0.0 0.0.0.0 66.1.1.1

 

We can now configure an ACL to specify source traffic  to NAT overload (PAT). Again, both VRFs have the same IP space.

ip access-list extended NAT
  permit ip 172.25.0.0 0.0.0.255 any

Now confgure a policy-class to map to the above ACL :

ip policy-class TENANT1_NAT_OUT
  nat source list NAT interface vlan 100 overload

ip policy-class TENANT2_NAT_OUT
  nat source list NAT interface vlan 100 overload

Next we need to add an “access-class” to the source interfaces. This will map the interface to the policy-class.

interface vlan 1
  access-class TENANT1_NAT_OUT

interface vlan 2
  access-class TENANT2_NAT_OUT

 

Clear the policy-sessions, then attempt to access the internet from a device in VLAN 1, or 2.  I’ll add another section to this later than explains how to configure DHCP pools per VLAN.

 

SUMMARY (Please excuse the diagram.. it was made in Dia and not Visio)

ip firewall vrf TENANT1
ip firewall vrf TENANT2
ip firewall vrf INTERNET

ip vrf TENANT1 route-distinguisher 100:1
ip vrf TENANT2 route-distinguisher 100:2
ip vrf INTERNET route-distinguisher 100:100

interface vlan 1
  ip vrf forwarding TENANT1
  description TENANT1 – LAN
  access-class TENANT1_NAT_OUT
  ip address 172.25.0.1 255.255.255.0

interface vlan 2
  ip vrf forwarding TENANT2
  description TENANT2 – LAN
  access-class TENANT2_NAT_OUT
  ip address 172.25.0.1 255.255.255.0

interface vlan 100
  ip vrf forwarding INTERNET
  description Cox Communications – INTERNET
  ip address 66.1.1.2 255.255.255.248

interface loopback 1
  ip vrf forwarding TENANT1
  description TENANT1 – Internet Route
  ip address 1.1.1.1 255.255.255.255

interface loopback 2
  ip vrf forwarding TENANT2
  description TENANT2 – Internet Route
  ip address 1.1.1.1 255.255.255.255

ip route vrf TENANT1 0.0.0.0 0.0.0.0 1.1.1.1
ip route vrf TENANT2 0.0.0.0 0.0.0.0 1.1.1.1
ip route vrf INTERNET 0.0.0.0 0.0.0.0 66.1.1.1

ip access-list extended NAT
  permit ip 172.25.0.0 0.0.0.255 any

ip policy-class TENANT1_NAT_OUT
  nat source list NAT interface vlan 100 overload

ip policy-class TENANT2_NAT_OUT
  nat source list NAT interface vlan 100 overload

 

 

 

 

 

 

 

 

 

Completed the CCNP track on 9/2/2011

I completed the final test of the CCNP track last Friday. This should provide me with more time for content.