Protection Against DoS Flooding attacks

Denial-of-service attacks send offending traffic to a server to deplete various server resources and incapacitate it. The ABC-SBC offers several traffic limits that help to restrain offending traffic: limit of parallel calls, bandwidth limit and limit of call-rate. The limits can be global, or tied to some traffic key such as source IP address of SIP From address. We show how to configure an ABC-SBC to use the call-rate limit to restrain call-attempts coming from an insecure source.

In this use-case, the cloud formation will start a dictionary password attack against a SIP server protected by an SBC. You will be able to see the password-guessing attempts in the Monitor, and introduce an SBC traffic-throttling rule that will reduce the attempts. The reduction will be observable in the Monitor again.

How to Use it

To start the cloud formation process visit the following link:

Once the cloud formation process completes, wait few more minutes to see how a simulated attack develops. In the Cloud Formation Outputs, there is a link to the Monitor and SBC. If you open the Monitor link, you will find a series of failing authentication attempts in the Security Dashboard, one event every second.

In the next step, you will enable a call-rate throttle. To do so, open the Outputs link to the SBC administrative interface in Cloud Formation template, log in using the password in Outputs, and follow the link “insert rule” under “Public” realm in “Overview”. Add Limit CAPS without any condition, and set the the CAPS limit to 1 per minute. Also turn on the “Report Abuse” Checklist.

Don’t forget to activate the changes.

After the activation the effect should be seen in the Monitor almost immediately. The one-per-second attempt rate on the left-hand side hit the limit (the violet limit event in the end of the initial burst) which reduced the rate on incoming INVITEs to one minute period.

If the limit option Report Abuse was turned on, the IP address would be also blacklisted. That can be found in the next Monitor diagram. In the initial stage, there is no limit and we observe one attempt per second. The violet limit event shows the rate has been reduced to one attempt per minute. After we activate the Report Abuse option, a blacklisting event shows the source IP address is blocked and no more events appear.

 

What Is Orchestrated

There are four machines running: a Session Border Controller (m3.medium), a machine simulating a dictionary attack (t2.micro), a Monitor to display the network situation (t2.medium), and a machine representing the protected infrastructure (t2.micro). The protected machine is a kamailio server that sends a 401 authentication challenge to all requests. The attacking machine is implemented using sipsak CLI and tries out a dictionary to find a password at the speed of one guess per second. When the SBC is applying a CPS rate, it forwards only the permitted rate, all other requests are declined using a 403 response. With the Report Abuse option on, the requests are blocked already at IP layer.

 

What Else You Should Know

In our simple example, we didn’t set any limit key: that means that the limit on number of incoming SIP requests is applied to all incoming traffic. We could have had keyed the limit by IP address: then the limit would apply to traffic on a by-IP-address basis. That’s particularly effective to limit attacks from a specific source. In case of orchestrated distributed DoS, traffic from individual sources may be actually very thin and thus hard to identify as an attack. A security policy resilient against DDoS should be therefore also using greylisting, as shown in another use case. Contact Frafos professional services, should you be devising more complex VoIP security policies.