SIP Flood Protection
(→Functionality) |
|||
| Line 1: | Line 1: | ||
| − | This page describes SIP protection against flood attacks. | + | This page describes the SIP protection against flood attacks. |
===Introduction=== | ===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 | + | 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=== | === Functionality=== | ||
Revision as of 17:08, 8 November 2012
This page describes the SIP protection against flood attacks.
Contents |
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 - 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.
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.
