Recently, I posted about using Kamailio’s PIKE module to help block excessive SIP traffic. This is a great tool for helping your system handle high traffic SIP, such as floods.

But, what can you do when someone sends garbage or non-SIP traffic to your system?

Kamailio’s SIP parser is handled in the core and was recently upgraded in v5.5 with logging improvements, as well as simplified implementation, static map for header name, and type for parsing. When combined with the SANITY module, Kamailio becomes an effective tool in weeding out requests that are not valid SIP messages.

SIP Parser

When a request comes in to Kamailio, the SIP parser checks for the name and body of the message, and although it doesn’t parse the content, it does place some of the parsed items into memory values for handling. When Kamailio receives a message that cannot be parsed, an error is generated.

Kamailio provides a special event route (event_route[core:receive-parse-error]) that gives you access to the source and local socket addresses (ip, port, proto, af) as well as the whole message buffer and its size. An example of using this event route:

event_route[core:receive-parse-error] {
  xlog("got an parsing error from $si:$sp, message $mb\n");
}

You could also take actions in this route, such as adding the source address to an HTABLE key. If you’re using iptables-api, you can even send an http_client_query to block the address in iptables or ip6tables.

Example:

event_route[core:receive-parse-error] {
  xlog("L_ALERT","ALERT: blocking $si for parse error. message $mb\n");
  $sht(ipban=>$si) = 1;
  http_client_query("http://localhost:8082/addip/$si", "$var(apinfo)");
  exit;
}

Sanity Module

For messages that pass the initial SIP Parser check, you can perform a sanity check on the message to handle some basic validity checks on the message values (such as request URI format, required headers, and more).

The sanity_check module returns false (-1) if one of these checks failed.

Example:

if (!sanity_check()) {
  xlog("L_ALERT","ALERT: blocking $si - sanity checks failed\n");
  $sht(ipban=>$si) = 1;
  http_client_query("http://localhost:8082/addip/$si", "$var(apinfo)");
  exit;
}

iptables

Combining iptables/ip6tables with the efficiency of Kamailio can help protect your systems. Now, one must be very realistic about what one node can handle in terms of DDoS, etc. Kamailio can handle a tremendous amount of SIP traffic, but software is software and SIP would be handled in the application layer (for you OSI geeks).

iptables/ip6tables blocks traffic at the network layer. When looking at the performance improvements of blocking sustained SIP flood attacks (>2000cps), using iptables did cause a significant reduction in CPU.

Questions? Comments?

Contact me through qxork.com. I’m also on twitter and Matrix.