Defend Against SIP Flood Attacks with OpenSIPS Pike Module

Dealing with traffic from the open Internet comes all the time with the risk of external attacks, of Denial of Service Attacks (DoS). The most common kind of DoS attack is the flood – the service is over-saturated and clogged with massive amounts of dummy SIP traffic, preventing the service to properly perform.

A simple and efficient way to fight against such DoS (and DDoS) SIP flood attacks, is by monitoring the sources of the SIP traffic (as amount per source IP).

How it works

OpenSIPS comes with the pike module, which serves this purpose. It is a module designed to keep track of the sources of SIP traffic and to detect the ones potentially doing SIP floods. The module does not perform any traffic blocking / discarding, but offers hooks for interfacing with external IP level tools.

The module keeps counting the SIP traffic density – as SIP messages in a certain time sliding window – and reports whenever a certain source IP exceeded a configured threshold. This means that IP is found as a flood source. The module allows the customization of these values, for the size of the time window and for the threshold – so you can tune how “sensitive” the module may be upon detecting the floods.

Manual monitoring

The pike module may be used in manual or automatic monitoring mode – the difference is how the module knows which IP addresses to monitor.

In the manual mode, you explicitly indicate at script level, which IP addresses are to be monitored. This is done via the pike_check_req()function. So you have full flexibility when comes to deciding which source IPs are to be monitored or not.

This is the original monitoring mode of the module, but it has some limitations:

• it is not able to monitor SIP replies
• it cannot take into consideration malformed SIP requests (as they do not reach the script due to parsing errors)
• doesn’t fit well with the Back-2-Back support, as it consumes B2B SIP traffic before reaching the request route.

Automatic monitoring

In order to deal with the above limitations, the module had been enhanced with automatic monitoring mode. In this mode, the module hooks itself directly into the internal SIP stack of OpenSIPS core, being able to monitor ALL incoming SIP traffic, requests or replies, valid or malformed, hitting the script or not.

So that we still have control over what IP addresses are monitored or not, the module provides a checking route – this is a script route so you can check the IP address and decide if it should be monitored or not. In such route, for example, you can discard the checking of trusted IP addresses, like your media servers, gateways, customer trunks or so.

By simply defining this check route, the automatic monitoring is enabled.

modparam("pike", "sampling_time_unit", 10)
modparam("pike", "reqs_density_per_unit", 50)
modparam("pike", "check_route", "pike_filter")


route [pike_filter] {
	if ( check_source_address(1)   # whitelisted IPs
	|| ds_is_in_list( $si, $sp, 10)   # our media servers
	|| is_from_gw()   # our gateways
	)
		# do not monitor/check for flood
		drop;

	# check the rest of the messages
}

Alerting on flood detection

How do we know when a flood was detected?

In manual mode, the pike_check_req()function has a negative return code if the currently checked source IP is detected as flood. The “-2” value is returned for a new detection and “-1” value for an ongoing flood from that source IP. If you want to report the newly detected IPs, just check for the “-2” return code here.

A mode versatile way of getting notified on the flood detection, is by using the E_PIKE_BLOCKED event – the pike module will raise this event each time a new IP was detected as a source of flood. The event will expose the culprit IP address, so you can integrate it further with external IP blocking tools (like iptables, fail2ban, etc).

event_route [E_PIKE_BLOCKED] {
	xlog("IP $param(ip) detected by pike as flooder\n");
	db_query_one("insert into blocked_ips values ('$param(ip)',now())");
	# you may also use exec() to call external scripts
}

For operational purposes, the pike module also exposes the “pike” Status/Report group, holding only one “main”/default SR identifier. This identifier will hold reports/logs about the history of the detected flooding IPs:

IP 11.22.33.44 detected as flooding 

Conclusions

The pike module provides a relatively simple functionality – tracking possible sources of floods. Nevertheless, the malicious of accidental floods are number one as DoS attacks, so the pike module is a great tool to fight against such floods and protect your services.