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.

Improve this question

2 Answers 2

Reset to default
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:

Improve this answer
16
  • 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, 2013 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, 2013 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, 2013 at 19:47
  • @mgjk You could set up a Python script and pipe tcpdump into it 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, 2013 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, 2013 at 19:52
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.

Improve this answer
4
  • 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, 2013 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, 2013 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, 2013 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, 2013 at 19:37

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .