How can I stop SipVicious ('friendly-scanner') from flooding my SIP server?

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?

Solution 1:

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.

Solution 2:

Talk to your upstream provider. Mine has a blacklist with a REST API that I can feed IP addresses to. I set up fail2ban to call this webservice and packets are stopped somewhere in my provider's network before they reach my firewalls.

Solution 3:

No one directly answered your question, so: NO

You cannot prevent someone from sending packets to your perimeter gateway. The best you can do is stop them upstream (as longneck mentioned above), or stop them at your firewall.

Fail2ban will trigger based on a count of failed attacks (as you already noted above), so an alternative (or combination) is to block based on the geographic location of the source ip. Products like SecAst or some hardware firewalls can block based on Geographic location which will further reduce the number of packets arriving at your server (See www.telium.io).

Back to your original question: NO

Solution 4:

Have you tried setting up a SIP proxy?

If you haven't, you can do so by setting up Kamaillio or OpenSIPS in front of your "sip server". These packages are SIP message routers that can be configured as a SIP proxy.

Within OpenSIPS or Kamaillio, you can add a line to your routing script as simple as the following to resolve this issue:

if ($ua=~"friendly-scanner") { drop(); }

Now I realize this doesn't stop the inbound attempts, but it will ensure that the attempts will never go anywhere, and that the "sip server" will never see them. Even 500 REGISTERs a second is nothing to worry about with OpenSIPS or Kamaillio, even on very VERY modest hardware.

Securing VoIP infrastructure is a large part of what OpenSIPS and Kamaillio are designed to do -- they do this by proxying incoming SIP requests, normalizing them, droping malformed requests (and those from user-agents that have no business talking to your network), and proxying authentication (REGISTERs).

They also hide the topology behind them from the Internet, thus adding an even higher level of security to your media server (perhaps this is the function that your "sip server" is actually doing for you)

If you're running asterisk, integrating OpenSIPS/Kamaillio/SER is a common practice in carrier ITSP deployments.

And as far as your statement about bandwidth: I would be a little surprised to hear that these attacks are using a lot of bandwidth; I suppose "a lot" is a relative term... But exactly how much traffic are you seeing from this?

I hope this is helpful. If you need help, Im a consultant and can help you take care of configuring this for your specific environment.

Jeremy D. Ward, CWNE

PS: To find me, Google the following: jeremy ward wireless. My LinkedIn profile is the first result.

Solution 5:

these iptables rules work fine for me. They keep the CPU load under 2% during such attacks.

http://txlab.wordpress.com/2013/06/29/protecting-a-vpbx-from-dos-attacks/