Monday, September 26, 2011

Snort 2.9.1: SIP preprocessor

The Session Initiation Protocol (SIP) is widely used in Internet telephone calls and for multimedia distribution. It is an application layer control (signaling) protocol, and is actually very similar to the HTTP protocol in terms of syntax. But because of its increasing popularity and vulnerabilities found, we designed the SIP preprocessor to tackle these challenges. In this article, I will show you how to effectively use several key features of the preprocessor in detail.

In summary, there are three key features in this preprocessor:

1) Built-in alerts on most found common vulnerabilities
2) Writing your own rule using rule options provided by SIP preprocessor
3) Ignore the call channel

Built-in alerts

When I wrote this preprocessor, I collected all the SIP related vulnerabilities found in recent years. I was actually very surprised with how much those vulnerabilities were in common. You can get the full list from the snort manual or the README.reputation file. The majority of vulnerabilities are related with the format of the SIP message, either a field missing or a field is too long. Let's look at an example:

URI field

1) This field is required, and shouldn't be empty. I provide one alert for empty field (show below). If you don't want this alert, you can simply delete it from the preprocessor.rules. If you want to change to other action, you can replace "alert" with that action (drop, pass, etc).

alert ( msg: "SIP_EVENT_EMPTY_REQUEST_URI"; sid: 2; gid: 140; rev: 1; metadata: rule-type preproc ; classtype:bad-unknown; reference:cve,2007-1306; )

2) In general, the length of this field should be limited to some number, such as 512. When the length exceeds the normal range, either the packet is bad or it is exploring a potential vulnerability through an extra long field. If you want to enforce a particular length in your system, you can change the length through the SIP preprocessor configuration max_uri_len.

alert ( msg: "SIP_EVENT_BAD_URI"; sid: 3; gid: 140; rev: 1; metadata: rule-type preproc ; classtype:bad-unknown; )

Apart from inspecting format, the SIP preprocessor also inspects call sequence. The "InviteReplay" billing attack and "FakeBusy" billing attack are alerted. These attacks are difficult to detect simply only by using rules. The SIP preprocessor provides a simple and quick way to detect them.

SIP preprocessor rule options

In you want to expand your inspection beyond built-in alerts, you may write your own rule or simply use our rule pack. SIP preprocessor provides four new rule options to help you:


Those options are similar to the rule options used in HTTP inspector, but they are not content modifiers. I will not go the details of every keyword, as you can find the details in the snort manual and README.reputation.

However, I want to emphasize two features here:

One powerful feature of sip_method/sip_stat_code is: you can specify several methods/status codes together. This will make rule writing easy. For example:
If you want to apply a rule to invite message and cancel message, you can use:

alert udp any any -> any 5060 (sip_method:invite, cancel; sid:1000000)

Another feature is that you can use pcre option H and P for SIP message:

H: Match SIP request or SIP response header, Similar to sip_header.
P: Match SIP request or SIP response body, Similar to sip_body

Ignore call channel

Similar to the FTP preprocessor, the SIP preprocessor also provides ability to ignore the call channel. It can be enabled through the SIP preprocessor configuration: ignore_call_channel. After a media session is created, the media data is transmitted in the call channel. If a user is not interested with that data, Snort can focus on other traffic by totally ignoring the data channel. When the media session is terminated using SIP, the ignored channel will be reinspected again. If there is not a termination signal received, Snort uses a timeout to reinspect the channel again.