The method of detection and dynamic protection from DDoS type SYN-flood
Hi, Habrasoobschestvo.
About the relevance of DDoS attacks in our time will not tell. Just look at the statistics . I encounter attacks by the nature of my activity quite often, the idea of dynamic protection from a SYN-flood DDoS on the Linux and FreeBSD severs arose. Also proposed implementation of monitoring SYN-flood on SNMP.
About this all under the cut.
')
Operating systems provide the ability to fine-tune the settings for working in a network using TCP. On UNIX, this is done by changing the values of the kernel parameters. The parameters that affect the processing of the SYN queue are described below. 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, not new. But is it worth it to do statically at boot time? Today, the number of mobile Internet subscribers is rapidly increasing, but in the CIS countries, most of them have access via EDGE (and even GPRS). Therefore, for such site visitors, you should not set hard values in the core - they can only be denied service because of this, even in the absence of an attack. The ideal option is when the values are close to default when there is no attack (they contribute to the successful establishment of the connection), and when they are reduced (except for the queue length) under attack conditions.
Once I was visited by the mentioned idea with the dynamic change of parameters. There are doubts whether this is really useful and whether statically it is not possible to expose the values at the stage of system loading. I described this problem in a blog . I will be glad to hear the views of readers on this issue.
The value of queue 128 by default is very small for a loaded system, especially if it is attackable, so naturally it should be increased. But there is a limit that limits this increase.
First, each entry into the queue takes 600 bytes of RAM.
Secondly, a separate queue with a net.core.somaxconn length is assigned to each service that listens to 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 - current free RAM
MEMres - memory that we reserve for system operation and other programs.
600 bytes - takes every entry in the queue
N is the number of services listening to TCP ports
This idea is implemented in the form of a script. A configuration file is also attached to it, in which you can customize the work for your system until you add / remove 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 you can by crown?
Answer: this allows you not only to change the kernel parameters on the fly, but also to integrate with any monitoring system that works via SNMP — to configure alerts and so on. Personally, I use the front-end for RRD Cacti and get the SYN queue loading graphs. Templates for Cacti are available for download on the site. This question is not critical, the functions of protection and SNMP extensions can be posted to different scripts.
The system was tested on the desktop and laptop, connected to the same 100Mb L2 switch. Tested with hping.
Results on a real-time Cacti chart:
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 seen on the graph, you can manually set the forced protection, when the kernel parameters are set to hard values and do not change depending on the queue length. On the graph we see that the queue value is close to almost 0.
1. On loaded servers, the value of the queue 0 is almost non-existent. It ranges from 0 to ~ 40 in the normal mode, so the threshold must be selected.
2. The queue of SYN-requests will certainly increase with the HTTP flood, so detecting an attack on the threshold value of the queue is not entirely correct. Although the interference is not even useful.
For ease of reference and setting up a site synflood-defender.net . It presents existing and planned features, a download link, step-by-step instructions for setting up, and a blog in which useful DDoS entries will periodically appear.
Recently, the script helped to protect the server of one friend from Brazil. In a token of gratitude, he published a Portuguese translation of the page How to use . So those harabrachiteli who are more comfortable to read in Portuguese, will not feel discomfort;)
About the relevance of DDoS attacks in our time will not tell. Just look at the statistics . I encounter attacks by the nature of my activity quite often, the idea of dynamic protection from a SYN-flood DDoS on the Linux and FreeBSD severs arose. Also proposed implementation of monitoring SYN-flood on SNMP.
About this all under the cut.
')
TCP options
Operating systems provide the ability to fine-tune the settings for working in a network using TCP. On UNIX, this is done by changing the values of the kernel parameters. The parameters that affect the processing of the SYN queue are described below. In parentheses are the default values:
- net.core.somaxconn - maximum value of the connection queue (128)
- tcp_syn_retries - the number of attempts to transmit a SYN to successfully establish a connection (5)
- tcp_synack_retries - the number of attempts to send a SYN, ACK response to a SYN request (5)
- tcp_keepalive_intvl - how long to wait for the answer of each sample keepalive (75 seconds)
- tcp_keepalive_probes - the number of TCP keepalive samples that must be passed before deciding that a connection is lost (9)
- tcp_keepalive_time - frequency with which TCP keepalive packets need to be sent to keep the connection active 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, not new. But is it worth it to do statically at boot time? Today, the number of mobile Internet subscribers is rapidly increasing, but in the CIS countries, most of them have access via EDGE (and even GPRS). Therefore, for such site visitors, you should not set hard values in the core - they can only be denied service because of this, even in the absence of an attack. The ideal option is when the values are close to default when there is no attack (they contribute to the successful establishment of the connection), and when they are reduced (except for the queue length) under attack conditions.
Once I was visited by the mentioned idea with the dynamic change of parameters. There are doubts whether this is really useful and whether statically it is not possible to expose the values at the stage of system loading. I described this problem in a blog . I will be glad to hear the views of readers on this issue.
Separately about the queue of SYN requests
The value of queue 128 by default is very small for a loaded system, especially if it is attackable, so naturally it should be increased. But there is a limit that limits this increase.
First, each entry into the queue takes 600 bytes of RAM.
Secondly, a separate queue with a net.core.somaxconn length is assigned to each service that listens to 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 - current free RAM
MEMres - memory that we reserve for system operation and other programs.
600 bytes - takes every entry in the queue
N is the number of services listening to TCP ports
Implementation as an extension for SNMP
This idea is implemented in the form of a script. A configuration file is also attached to it, in which you can customize the work for your system until you add / remove 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 you can by crown?
Answer: this allows you not only to change the kernel parameters on the fly, but also to integrate with any monitoring system that works via SNMP — to configure alerts and so on. Personally, I use the front-end for RRD Cacti and get the SYN queue loading graphs. Templates for Cacti are available for download on the site. This question is not critical, the functions of protection and SNMP extensions can be posted to different scripts.
Security testing
The system was tested on the desktop and laptop, connected to the same 100Mb L2 switch. Tested with hping.
Results on a real-time Cacti chart:
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 seen on the graph, you can manually set the forced protection, when the kernel parameters are set to hard values and do not change depending on the queue length. On the graph we see that the queue value is close to almost 0.
Remarks
1. On loaded servers, the value of the queue 0 is almost non-existent. It ranges from 0 to ~ 40 in the normal mode, so the threshold must be selected.
2. The queue of SYN-requests will certainly increase with the HTTP flood, so detecting an attack on the threshold value of the queue is not entirely correct. Although the interference is not even useful.
Site
For ease of reference and setting up a site synflood-defender.net . It presents existing and planned features, a download link, step-by-step instructions for setting up, and a blog in which useful DDoS entries will periodically appear.
Recently, the script helped to protect the server of one friend from Brazil. In a token of gratitude, he published a Portuguese translation of the page How to use . So those harabrachiteli who are more comfortable to read in Portuguese, will not feel discomfort;)
Source: https://habr.com/ru/post/131469/
All Articles