October 29, 2011 at 15:21SYN-flood type detection and dynamic protection against DDoS
Hi, Habrasociety.
Nowadays I will not talk about the relevance of DDoS attacks. Just look at the statistics . I encounter attacks by type of activity quite often, the idea of dynamic protection against DDoS such as SYN-flood on the Linux and FreeBSD servers arose. An implementation of SYN-flood monitoring via SNMP is also proposed.
That's all under the cut.
Operating systems provide the ability to fine-tune the parameters for working on a network using the TCP protocol. On UNIX, this is done by changing the kernel parameter values. The following are the parameters that affect the processing of the SYN request queue. In parentheses are the default values:
We see that the values of retransmission attempts and the intervals between them are very large. The idea is to reduce them, is not new. But is it worth doing statically at the system boot stage? Today, the number of mobile Internet subscribers is growing rapidly, but in the CIS countries, most of them access via EDGE (or even GPRS). Therefore, for such site visitors, it is not necessary to set hard values in the kernel - they can only receive a denial of service because of this even in the absence of an attack. The ideal option is when the values are close to default in the absence of an attack (they contribute to the successful establishment of the connection), and when they are reduced (except for the length of the queue) under attack conditions.
Once I was visited by the mentioned idea with a dynamic change of parameters. There are doubts whether this is really useful and whether to set values at the system boot stage statically. I described this problem in the blog . I will be glad to hear the opinions of readers on this issue.
The default value of queue 128 is very small for a loaded system, especially if it lends itself to attack, so it should naturally be increased. But there is a limit that limits this increase.
Firstly, each entry in the queue takes 600 bytes of RAM.
Secondly, a separate queue of net.core.somaxconn length is allocated for each service listening on the TCP port.
Based on these considerations, the value of net.core.somaxconn can be calculated by the formula:
somaxconn = (MEMfree - MEMres) / 600 * N, where
MEMfree is the current free RAM
MEMres is the memory that is reserved for the system and other programs to use
600 bytes - it takes each entry in the
N queue is the number of services that listen on TCP ports
This idea is implemented as a script. It also comes with a configuration file in which you can configure the work for your system up to the addition / removal of changing kernel parameters at your discretion. I use this script as an extension for SNMP. There are versions for Linux and FreeBSD.
Question: why pull the script via SNMP, if possible by the crown?
Answer: this allows not only to change the kernel parameters on the fly, but also to integrate with any monitoring system that works via SNMP - configure alerts, etc. Personally, I use the front end for Cacti RRD and get SYN queue load schedules. Templates for Cacti are available for download on the site. This issue is not fundamental, the protection and SNMP extension functions can be spread out according to different scripts.
The system was tested on a desktop and laptop connected to one 100Mb L2 switch. Tested with hping.
Results on a Cacti real-time graph:
In dynamic protection mode, characteristic peaks are observed. They arise due to the fact that the attack is monitored by a threshold value - threshold. In the future I plan to monitor the frequency of filling and reduce these peaks.
When peaks are noticed on the graph, you can manually set up forced protection when the kernel parameters are set to hard values and do not change depending on the length of the queue. On the graph we see that the value of the queue is close to almost 0.
1. On busy servers, the value of the queue 0 practically does not exist. It ranges from 0 to ~ 40 in normal mode, so the threshold must be selected.
2. The queue of SYN requests will certainly increase during HTTP flood, so detecting an attack by the threshold value of the queue is not entirely correct. Although the interference is not and even useful.
For ease of familiarization and configuration, I created the site synflood-defender.net . It features existing and planned features, a download link, step-by-step setup instructions and a blog in which useful DDoS entries will periodically appear.
Recently, the script helped protect the server of one friend from Brazil. In gratitude, he published a Portuguese translation of the How to use page . So those habrachitateli who are more comfortable reading in Portuguese will not feel any discomfort;)
Nowadays I will not talk about the relevance of DDoS attacks. Just look at the statistics . I encounter attacks by type of activity quite often, the idea of dynamic protection against DDoS such as SYN-flood on the Linux and FreeBSD servers arose. An implementation of SYN-flood monitoring via SNMP is also proposed.
That's all under the cut.
TCP options
Operating systems provide the ability to fine-tune the parameters for working on a network using the TCP protocol. On UNIX, this is done by changing the kernel parameter values. The following are the parameters that affect the processing of the SYN request queue. In parentheses are the default values:
- net.core.somaxconn - maximum value of the connection queue (128)
- tcp_syn_retries - number of attempts to pass SYN for successful connection establishment (5)
- tcp_synack_retries - number of attempts to send a SYN, ACK response to a SYN request (5)
- tcp_keepalive_intvl - how long to wait for each keepalive probe response (75 seconds)
- tcp_keepalive_probes - the number of TCP keepalive samples that must be transmitted before deciding that the connection is lost (9)
- tcp_keepalive_time - frequency with which TCP keepalive packets must be transmitted to maintain connection activity if it is not currently in use (7200 seconds)
We see that the values of retransmission attempts and the intervals between them are very large. The idea is to reduce them, is not new. But is it worth doing statically at the system boot stage? Today, the number of mobile Internet subscribers is growing rapidly, but in the CIS countries, most of them access via EDGE (or even GPRS). Therefore, for such site visitors, it is not necessary to set hard values in the kernel - they can only receive a denial of service because of this even in the absence of an attack. The ideal option is when the values are close to default in the absence of an attack (they contribute to the successful establishment of the connection), and when they are reduced (except for the length of the queue) under attack conditions.
Once I was visited by the mentioned idea with a dynamic change of parameters. There are doubts whether this is really useful and whether to set values at the system boot stage statically. I described this problem in the blog . I will be glad to hear the opinions of readers on this issue.
Separately, about the queue of SYN requests
The default value of queue 128 is very small for a loaded system, especially if it lends itself to attack, so it should naturally be increased. But there is a limit that limits this increase.
Firstly, each entry in the queue takes 600 bytes of RAM.
Secondly, a separate queue of net.core.somaxconn length is allocated for each service listening on the TCP port.
Based on these considerations, the value of net.core.somaxconn can be calculated by the formula:
somaxconn = (MEMfree - MEMres) / 600 * N, where
MEMfree is the current free RAM
MEMres is the memory that is reserved for the system and other programs to use
600 bytes - it takes each entry in the
N queue is the number of services that listen on TCP ports
Extension implementation for SNMP
This idea is implemented as a script. It also comes with a configuration file in which you can configure the work for your system up to the addition / removal of changing kernel parameters at your discretion. I use this script as an extension for SNMP. There are versions for Linux and FreeBSD.
Question: why pull the script via SNMP, if possible by the crown?
Answer: this allows not only to change the kernel parameters on the fly, but also to integrate with any monitoring system that works via SNMP - configure alerts, etc. Personally, I use the front end for Cacti RRD and get SYN queue load schedules. Templates for Cacti are available for download on the site. This issue is not fundamental, the protection and SNMP extension functions can be spread out according to different scripts.
Protection testing
The system was tested on a desktop and laptop connected to one 100Mb L2 switch. Tested with hping.
Results on a Cacti real-time graph:
In dynamic protection mode, characteristic peaks are observed. They arise due to the fact that the attack is monitored by a threshold value - threshold. In the future I plan to monitor the frequency of filling and reduce these peaks.
When peaks are noticed on the graph, you can manually set up forced protection when the kernel parameters are set to hard values and do not change depending on the length of the queue. On the graph we see that the value of the queue is close to almost 0.
Remarks
1. On busy servers, the value of the queue 0 practically does not exist. It ranges from 0 to ~ 40 in normal mode, so the threshold must be selected.
2. The queue of SYN requests will certainly increase during HTTP flood, so detecting an attack by the threshold value of the queue is not entirely correct. Although the interference is not and even useful.
Website
For ease of familiarization and configuration, I created the site synflood-defender.net . It features existing and planned features, a download link, step-by-step setup instructions and a blog in which useful DDoS entries will periodically appear.
Recently, the script helped protect the server of one friend from Brazil. In gratitude, he published a Portuguese translation of the How to use page . So those habrachitateli who are more comfortable reading in Portuguese will not feel any discomfort;)