2

SIP has a practical need to be widely available, but its services are prone to being spoofed as reflectors used in DDoS attacks.

A freeswitch server I manage has seen heaps of registration requests on UDP (~300/second), each one generating a 401 unauthorized response. We only caught these when performance issues led me to do a dump on the wire and investigate the traffic.

Being UDP traffic, blocking it in iptables has a limited effect. The incoming traffic still wastes bandwidth, but the SIP server doesn't have to respond to it and the reply traffic isn't generated.

Because it's UDP, it's probably being spoofed. The real victim is probably the "source", which is being bombarded with my 401 messages.

This kind of problem must be very common. Is there a current best practice for hosting SIP services so that they aren't valuable to attackers as sources for reflection attacks?

Thanks for any insights.

Update: 24 hours after blocking the inbound SIP traffic, it stopped.

mgjk
  • 7,535
  • 2
  • 20
  • 34

2 Answers2

3

Most SIP daemons (e.g. Asterisk) have an option for whitelisting IP addresses that can be used to access the server, so if possible I'd use that and ban all others. Keep in mind that's it's usually possible to allow incoming calls from any IP address but whitelist authentication requests to a set of IPs.

I'd probably also look into something like fail2ban, which is a service that monitors logs for failed login attempts and adds iptables rules based on various rules. Automatically banning IPs for incrementing time periods after a number of failed attempts will quickly discourage attackers, because even reflected attacks require a pool of proxy machines. If you're identified as a target that doesn't quickly block malicious attempts, it'll only encourage attackers to continue.

One thing to watch out for with fail2ban is that attackers may spoof the UDP source address and ban various addresses. Thankfully you can use jail.conf in the fail2ban config to set a whitelist of IP addresses that will never be banned. As long as the attacker never discovers one of these IPs, their attacks will be mitigated pretty successfully.

You could also use a script to add and remove iptables rules to block all traffic outside office hours, or change the SIP port to avoid automated drive-by attacks. Both of these are a little bit of an inconvenience, but can be useful when avoiding attacks that scan across the internet for open SIP instances.

Further reading:

Polynomial
  • 132,208
  • 43
  • 298
  • 379
  • So there is no way for an attacker to know ban list ip? If he does won't he get a GREEN card / license to kill – Saladin Feb 27 '13 at 19:40
  • @asadz Nope, there's no way for them to tell. Even if they send a packet whose source IP address is spoofed to that of a whitelisted address, they won't receive the response because the network will respond to the spoofed IP. As such, there's no way to enumerate the whitelist. – Polynomial Feb 27 '13 at 19:47
  • We've got fail2ban, but fail2ban depends on the logs. The traffic we're seeing isn't logged by default. I'm going to have a closer look at our network traces and see if there might be a way to restrict the IPs of known good peers or maybe set up stateful firewall rules. I was afraid of this answer. :-( – mgjk Feb 27 '13 at 19:47
  • @mgjk You could set up a Python script and [pipe tcpdump into it](http://unix.stackexchange.com/questions/15989/how-to-process-pipe-tcpdumps-output-in-realtime) for realtime processing, using a filter so that you only have to process SIP registration requests with the script. From there you could identify high-volume requests and automatically maintain `iptables` rules based on that. Essentially your own version of fail2ban for your specific case. – Polynomial Feb 27 '13 at 19:50
  • @Polynomial Hhmm i was thinking in the lines of somehow eavesdropping the connection or some kind of network recon as don;t think that there exist an covert / out of band channel for these whitelist sources to communicate. And one more thing, its a a DoS attack should the attacker be ever worried about the response.? – Saladin Feb 27 '13 at 19:52
  • @asadz If I understand the attack properly, it's not a DoS really. It's a password-guessing attack with such ferocity that it ends up causing a DoS condition. – Polynomial Feb 27 '13 at 19:56
  • @Polynomial could be but not how the writer explained it. Without logs its hard to tell anyways. But there is much docs about the type as described in this question here is the link. Read page http://keithcroxford.wordpress.com/2012/01/08/sip-registerdos-attacks/. If this is the attack nature the author of this site have anti-script that is used to stop the attacker. – Saladin Feb 27 '13 at 20:02
  • even better reference is this http://www.iptel.org/~dor/papers/Sisalem1204_DoS.pdf – Saladin Feb 27 '13 at 20:09
  • There are lots of documents which describe the problem, but not a lot which discuss stratgies to mitigate. @Polynomial, I suspect that this wasn't a password guessing attempt. I suspect they were spoofing the source of the UDP packet to flood the true victim with errors from my server. Which is why I say reflection... I don't think I'm the target of this attack, just a reflector. It's troublign that if they throttled their attack, I never would have noticed. – mgjk Feb 27 '13 at 20:15
  • @mgjk did you check the pdf version it has lot of mitigation approaches but you first exactly need to identify the type of DoS attack as to my knowledge it just not one type. Did you tried this book one of my fav on the topic. http://www.hackingvoip.com/ – Saladin Feb 27 '13 at 20:17
  • @mgjk did you consider writing iptables or tcpdump which blocks 404 https status code sent from the server to the victim? – Saladin Feb 27 '13 at 20:20
  • @asadz, it's a great PDF, I read it before posting :-) I'll certainly have a look at the book. In the question I mentioned that I blocked inbound SIP from the alleged source. It's not a 404, but a 401. Blocking all outbound 401 codes might be a problem. Rate limiting might be a method around this, but this can't be an unusual problem. I'd rather see Freeswitch incorporate that kind of functionality by default than to homebrew. – mgjk Mar 01 '13 at 18:16
  • I'm glad you like the pdf;Rate limiting looks cools if it done on ISP end other wise for clients like big companies DDoS prevention solution e.g www.arbornetworks.com/ – Saladin Mar 01 '13 at 18:25
  • @Saladin - do you still have a copy of this PDF? I've been looking around for it, but I can't find a copy anywhere. Thanks! – Andrew White May 23 '18 at 04:23
  • @AndrewWhite https://www.aeonprime.net/pdf-attacking-information-overload-in-software-development.html – Saladin May 24 '18 at 18:31
  • @Saladin thanks, I found that link, but the download of the PDF does not work, just downloads HTML. – Andrew White Jun 10 '18 at 10:22
1

What you need is perhaps perimeter defense (e.g firewall) to block such traffic. What you can do is to define a whitelist of users or network range who can find ur servers If its in public domain then its whole other ball game then you need something as rate limiting on your isp end.

Saladin
  • 1,547
  • 3
  • 14
  • 23
  • This doesn't really answer the question. OP is already blocking it with iptables, which is equivalent to a perimeter firewall in this case. The question is more aimed at making the SIP service much less attractive to attackers, to avoid becoming a target in the first place. – Polynomial Feb 27 '13 at 19:10
  • Host based firewall is never the same as network based firewall it won't be his server that would be busy wasting away those dos packets other filtering device would be doing it for him. – Saladin Feb 27 '13 at 19:20
  • In this case, the host based is the same as the network based.... if the packets reach my perimiter, they're still filling my pipes. The rate limiting on the ISP end is reasonable, but I'm sure our ISP won't do it and rate-limiting on SIP is asking for performance issues. – mgjk Feb 27 '13 at 19:24
  • @mgjk My point was to choose lesser of two evils. Anyhow, you can always go for honeypot or move the server address to a new one. As for performance issues there is different way of avoiding it one is not to log rate limit bad for law enforcement agencies but good for performance. Beside no good isp can escape from the legal authority of protecting their customers / client from dos attack. One other reason rate limiting is used is to capture attack footprint. – Saladin Feb 27 '13 at 19:37