Last week, my SPA112 was suddenly unable to receive incoming calls. The LAN traffic light was flashing continuously and SIP stats were showing over 1 GB data received per day.
My VOIP provider, CallCentric, ran through several troubleshooting steps over the course of a day but was unable to resolve the issue.
I discovered that the SPA112 device was the victim of a SIP brute force attack.
I initially assigned the device to a new IP address, which restored my ability to receive calls, but the attack on the original IP address continued. The UDP traffic was flooding my DSL connection.
I was able to reconfigure my router to drop the incoming traffic, but as an experiment, I reassigned the attacked IP address to a PC and used Wireshark to discover what the packets were and where they were coming from. In the following trace, I have replaced the attacker's IP address with <ATTACKER-IP> and the SPA112's IP address (attacked address) with <SPA112-IP>.
No. Time Source Destination Protocol Length Info
34002 222.535423 <ATTACKER-IP> <SPA112-IP> SIP 401 Request: REGISTER sip:<SPA112-IP>
Frame 34002: 401 bytes on wire (3208 bits), 401 bytes captured (3208 bits)
Ethernet II, Src: Motorola_fc:d5:10 (00:1c:fb:fc:d5:10), Dst: HewlettP_b9:da:59 (18:a9:05:b9:da:59)
Internet Protocol Version 4, Src: <ATTACKER-IP> (<ATTACKER-IP>), Dst: <SPA112-IP> (<SPA112-IP>)
User Datagram Protocol, Src Port: alesquery (5074), Dst Port: sip (5060)
Session Initiation Protocol
Request-Line: REGISTER sip:<SPA112-IP> SIP/2.0
Method: REGISTER
Request-URI: sip:<SPA112-IP>
[Resent Packet: False]
Message Header
Via: SIP/2.0/UDP 127.0.0.1:5074;branch=z9hG4bK-3910607681;rport
Content-Length: 0
From: "3775708062" <sip:3775708062@<SPA112-IP>>
SIP Display info: "3775708062"
SIP from address: sip:3775708062@<SPA112-IP>
SIP from address User Part: 3775708062
SIP from address Host Part: <SPA112-IP>
Accept: application/sdp
User-Agent: friendly-scanner
To: "3775708062" <sip:3775708062@<SPA112-IP>>
SIP Display info: "3775708062"
SIP to address: sip:3775708062@<SPA112-IP>
SIP to address User Part: 3775708062
SIP to address Host Part: <SPA112-IP>
Contact: sip:123@1.1.1.1
Contact-URI: sip:123@1.1.1.1
CSeq: 1 REGISTER
Call-ID: 211458778
Max-Forwards: 70
I googled the packet contents and discovered the attacker was likely using "SIPvicious" (as evidenced by "friendly-scanner").
I was able to use the Ruby script on the following web site to stop the SIP brute force attack.
http://jcs.org/notaweblog/2010/04/11/properly_stopping_a_sip_flood/
I replaced
s.bind(nil, 5061)
with
s.bind("<SPA112-IP>",5060)
and ran the script with
ruby stopsip.rb
Sure enough, the traffic stopped, and has not returned.
Here's the entire script. Replace <SPA112-IP> with the attacked IP address.
[stopsip.rb]
require "socket"
s = UDPSocket.new
s.bind("<SPA112-IP>",5060)
while true
packet = s.recvfrom(1024)
via = packet[0].match(/Via: (.+);rport/)[1]
from = packet[0].match(/From: (.+)/)[1]
to = packet[0].match(/To: (.+)/)[1]
call_id = packet[0].match(/Call-ID: (.+)/)[1]
cseq = packet[0].match(/CSeq: (\d+) REGISTER/)[1]
remote_ip = packet[1][3]
remote_port = packet[1][1].to_i
puts packet.inspect
if packet[0].match(/^REGISTER /)
ret = "SIP/2.0 200 OK\r\n" +
"Via: #{via};received=#{remote_ip}\r\n" +
"From: #{from}\r\n" +
"To: #{to}\r\n" +
"Call-ID: #{call_id}\r\n" +
"CSeq: #{cseq.to_i + 1} REGISTER\r\n" +
"\r\n"
puts "sending to #{remote_ip}:#{remote_port}:\n#{ret}"
s.send(ret, 0, remote_ip, remote_port)
end
end
I have since discovered an option on the SPA112, under Voice, Line 1, called Restrict Source IP. It was set to No (default), and I have changed it to Yes. We'll see if this option helps avoid future attacks. At least I know what to do next time.
