Security – How to stop SipVicious (‘friendly-scanner’) from flooding the SIP server

Securitysip

I run an SIP server which listens on UDP port 5060, and needs to accept authenticated requests from the public Internet.

The problem is that occasionally it gets picked up by people scanning for SIP servers to exploit, who then sit there all day trying to brute force the server. I use credentials that are long enough that this attack will never feasibly work, but it is annoying because it uses up a lot of bandwidth.

I have tried setting up fail2ban to read the Asterisk log and ban IPs that do this with iptables, which stops Asterisk from seeing the incoming SIP REGISTER attempts after 10 failed attempts (which happens in well under a second at the rate of attacks I'm seeing). However, SipVicious derived scripts do not immediately stop sending after getting an ICMP Destination Host Unreachable – they keep hammering the connection with packets. The time until they stop is configurable, but unfortunately it seems that the attackers doing these types of brute force attacks generally set the timeout to be very high (attacks continue at a high rate for hours after fail2ban has stopped them from getting any SIP response back once they have seen initial confirmation of an SIP server).

Is there a way to make it stop sending packets at my connection?

Best Answer

The publicly available SipVicious script that many of these attackers use stops the attack instantly if it receives an invalid SIP response with no From: line. You can identify SipVicious because it sets its User-Agent in the SIP requests to friendly-scanner.

Using this technique against a real-world attacker, I have been able to immediately stop the flood of packets. You can send such a packet with a simple script. For example:

cat >UnfriendlyScannerStopper.scala <<END
import java.net._

object UnfriendlyScannerStopper {
  def main(args : Array[String]) : Unit = {
    if (args.length < 2) {
      System.out.println("Usage: FriendlyScannerStopper ipAddr port")
      return
    }

    val udpSocket : DatagramSocket = new DatagramSocket();
    val packetContents : String = "SIP/2.0 400 Go Away!!!\r\n\r\n"
    udpSocket.send(new DatagramPacket(packetContents.getBytes("utf-8"), packetContents.size,
      InetAddress.getByName(args(0)), Integer.parseInt(args(1))))
  }
}
END
scala UnfriendlyScannerStopper.scala 188.138.107.179 5102

You will need to substitute 188.138.107.179 and 5102 for the address and port in the Via header of the SIP packets you are being sent in the attack.

Related Solutions

Security – Is It Worth Blocking Failed Login Attempts?

Rate limiting login attempts is an easy way to prevent some of the high speed password guessing attacks. However, it's hard to limit distributed attacks and many run at a low pace over weeks or months. I personally prefer to avoid using automated response tools like fail2ban. And this is for two reasons:

Legitimate users sometimes forget their passwords. I don't want to ban legitimate users from my server, forcing me to manually enable their accounts again (or worse, try to figure out which of the 100/1000 banned IP addresses is theirs).
An IP address is not a good identifier for a user. If you have multiple users behind a single IP (for example, a school that runs NAT on 500 student machines) a single user making a few bad guesses can land you in a world of pain. At the same time the majority of the password guessing attempts I see are distributed.

Therefore I don't consider fail2ban (and similar automated response tools) a very good approach to securing a server against brute force attacks. A simple IPTables rules set to cut down on the log spam (which I have on most of my linux servers) is something like this:

iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --set
iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 -j DROP

It prevents more than 4 connection attempts from a single IP to ssh in any 60 second period. The rest can be handled by ensuring passwords are reasonably strong. On high security servers forcing the users to use public key authentication is another way to stop guessing.

Asterisk SIP digest authentication username mismatch

This is a workaround that I found that is OK for my situation, but I'd generally consider it a gross hack. I found this gem in chan_sip.c:

/* Always OK if no secret */
if (ast_strlen_zero(secret) && ast_strlen_zero(md5secret))
  return AUTH_SUCCESSFUL;

So, my workaround is to put:

secret=

In the config for each extension. This is OK for me because I'm not worried about someone on my network trying to register for an extension that isn't theirs. In general, however, it's totally insecure because it bypasses any further authentication (including my issue with the username mismatch).

Best Answer

Related Solutions

Security – Is It Worth Blocking Failed Login Attempts?

Asterisk SIP digest authentication username mismatch

Related Topic