SIP Flood Protection

Revision as of 17:44, 8 November 2012

This page describes the SIP protection against flood attacks.

Introduction

Starting with Yate 4.2 or SVN revision 5234, Yate provides a protection mechanism against several types of SIP flood attacks. The aim of this document is to provide information about this protection and how can it be used.

Functionality

The aim of this mechanism was to provide a way of protecting a running system against a flood attack.

The most severe problem when dealing with flood attacks is that they create SIP transactions which can take up system resources to the point where the system becomes unresponsive.
The problem to be solved was providing a way of dealing with flood messages, while not disturbing traffic for already established transactions.

The mechanism implemented in Yate acts as a filter which silently drops the following SIP methods:

• INVITE
• REGISTER
• SUBSCRIBE
• OPTIONS

when a flood is detected and thus not allowing the creation of a transaction. Other SIP methods, as well as SIP reINVITES, are still allowed to pass through the filter.

Configuration

This protection is on by default in Yate and is triggered when the SIP processing engine detects that it handled a configured number of SIP events in a row.

The interesting parameters in regards to this mechanism are the floodevents and floodprotection parameters in the general section of ysipchan.conf:

• floodprotection - this parameter explicitly enables or disables the filter mechanism. This setting is on by default. This value is applicable on reload.

; floodevents: int: How many SIP events retrieved in a row trigger a flood warning and the drop mechanism
;  for INVITE/REGISTER/SUBSCRIBE/OPTIONS messages if the flood protection is on.
; NOTE! The drop mechanism is separately activated by the floodprotection setting which is on by default. Also,
;  setting this parameter to 0 will disable the flood warning and protection.
;floodevents=100

• floodevents - this parameter specifies at which number of handled events in a row a flood warning should be displayed. If the filter mechanism was enabled, this is also the value at which the SIP messages mentioned above are dropped. Note that setting this parameter to 0 will disable the display of flood warning and the filter mechanism, even if floodprotection is set to true. This value is applicable on reload.

; floodprotection: bool: Activate the drop mechanism for INVITE/REGISTER/SUBSCRIBE/OPTIONS messages when
;  the number of SIP events retrieved in a row exceeds the number set for floodevents setting.
; Other messages, as well as reINVITEs, will be allowed.
; NOTE! This mechanism is activated by default, to disable it configure this parameter to false.
;floodprotection=on

Notes

• Setting the value for the number of events which trigger the drop mechanism must take into account the machine on which Yate is running. A value of 100 events handled in a row might be to low on a powerful machine for starting to drop SIP messages, as it could handle so much more without having problems. Load tests should be conducted in order to find a suitable value.

• In case of flood attacks using INVITE messages, it is also useful to limit the allowed number of simultaneous calls using the maxchans configuration parameter in the general section of ysipchan.conf. It can be an added protection for the case when lots of INVITEs pass through the filter while the number of handled events has not yet reached the triggering threshold. The maxchans value is applicable on reload. If not configured, it defaults to the value set in yate.conf in the telephony section for the same parameter. The value from yate.conf is not applicable on reload.