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:
sip_method
sip_stat_code
sip_header
sip_body
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.