«
»

Suspicious SIP Traffic

Lots of traffic & high CPU load

We have a traffic warning system set up to warn us, if traffic levels should rise abruptly on any of our systems.

This has happened with our VoIP Server VZ. Suspicious traffic levels were reached during the last two months. Additionally YATE, the telephony engine we are using, was running at very high CPU load (89% and higher) and had degraded performance in conversations.

To get to the core of the problem I started logging the traffic hitting this server.

Logging traffic

tcpdump -s 65535 -w /tmp/capture.cap

This simple command starts logging traffic, until you hit Ctrl + C. Note, that after terminating the SSH session inadvertently (timeout), the logging does seem to continue.

After capturing for some time, download the capture files from your server, and analyse them with Wireshark.

For large capture files (300MB for instance) Wireshark may take some time for analysis. I've used statistics->conversations to identify the IPs most of the traffic seems to be coming from.

It seems there's just one IP responsible for all the traffic.

119.62.128.109

Here's the traceroute to this IP:

4 65 ms 52 ms 69 ms so-0-3-0-0.cr01.fra.de.hansenet.net [213.191.66.65]
5 47 ms 40 ms 36 ms ae1-0.pr50.fra.de.hansenet.net [213.191.66.118]
6 53 ms 41 ms 40 ms ae0-0-grtfraix4.red.telefonica-wholesale.net.7.16.84.in-addr.arpa [84.16.7.185]
7 96 ms 54 ms 93 ms Xe-0-0-2-0-grtlontl3.red.telefonica-wholesale.net.121.142.94.in-addr.arpa [94.142.121.74]
8 185 ms 178 ms 167 ms xe3-2-0-0-grtnycpt2.red.telefonica-wholesale.net [84.16.12.22]
9 189 ms 230 ms 191 ms Xe0-1-0-0-grtpaopx2.red.telefonica-wholesale.net.125.142.94.in-addr.arpa [94.142.125.81]
10 192 ms 198 ms 195 ms ChinaNetCom11-0-0-0-grtpaopx2.red.telefonica-wholesale.net [213.140.55.14]
11 377 ms 377 ms 376 ms 219.158.30.225
12 405 ms 380 ms 379 ms 219.158.11.29
13 404 ms 407 ms 404 ms 219.158.6.150
14 455 ms 460 ms 458 ms 221.3.128.242
15 467 ms 464 ms 463 ms 221.3.139.150
16 447 ms 452 ms 451 ms 221.3.253.18
17 * * * Request timed out.
18 * * * Request timed out.
19 * * * Request timed out.
20 * * * Request timed out.
21 * * * Request timed out.
22 * * * Request timed out.
23 * * * Request timed out.
24 * * * Request timed out.
25 * * * Request timed out.
26 *

The IP seems to be from Bejing, China.

The traffic is caused by the remote computer basically trying to register with my VoIP server and being rejected by my server.

REGISTER sip:(ip removed) SIP/2.0
Via: SIP/2.0/UDP 10.86.43.24:5066;branch=z9hG4bK-1983026950;rport
Content-Length: 0
From: "1031025643" <sip:1031025643@(ip removed)>
Accept: application/sdp
User-Agent: friendly-scanner
To: "1031025643" <sip:1031025643@(ip removed)>
Contact: sip:123@1.1.1.1
CSeq: 1 REGISTER
Call-ID: 1582787073
Max-Forwards: 70

This message above has been sent out thousands of times just varying the branch and the Call-ID. Apparently a software used for security audit has been abused. It identifies itself as "friendly-scanner" and is from SipVicious.

My solution to the problem was to drop the requests. You can do this via:

iptables -A INPUT -s 119.62.128.109 -j DROP
iptables -A OUTPUT -s 119.62.128.109 -j DROP

replacing the IP with the one which is offending your network. The commands state that all packets with matching destination or origin will be dropped, the other server never gets a reply.

This immediately solved the CPU load problem, also the traffic should be less (no replys from YATE).

Please note, if you run a virtualized environment and want to block the traffic on the hardware node, you should use this on it (thanks, Florian!):

iptables -A FORWARD -s 119.62.128.109 -j DROP

The hardware node is forwarding the traffic to the VEs, thus a rule stating INPUT / OUTPUT will not match, and the traffic will pass on to the VE you're running your VoIP software on.

With iptables -F you can empty the filter list, with iptables -L you can see the current configuration. Please note, that you probably would have to add these statements to a startup script or do it manually every time you reboot.

Here's a couple of further related resources:

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

This entry was posted on Wednesday, November 10th, 2010 at 4:52 pm and is filed under English, tech. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.