CentOS 7 Review. Part 4: Mitigate TCP SYN Flood DDoS attacks. Test in the cloud for free
In the first part of the CentOS 7 review, we talked about Linux container support in Cent OS 7. In the second part, we talked about identity management . In the third part of the review we touched the network file system NFS and its environment . In this article we will talk about mitigating DDoS attacks TCP SYN Flood. At the end of the post link to the free testing of CentOS 7 in the cloud VPS from Infobox.
DDoS (Distributed Denial of Service) attacks are becoming more frequent, due to the fact that the business is becoming increasingly dependent on the Internet. One of the most common types of DDoS is the SYN Flood. This main attack of end hosts puts your server to its knees. As a result, your server cannot correctly handle incoming requests.
')
It is important to note that the described protection mechanisms are available in CentOS 7, but are not enabled by default.
The main problem of TCP scalability for the Linux kernel is related to how many new connections can be created in a second. This refers to blocking on a socket in the "listen" state. Estabilished (Installed) connections scale very well. The “listen” state lock is encountered not only with SYN – packets, but also with other packets for the initial connection of “SYN-ACK” and “ACK” (triple handshake packets in TCP). In a flood attack scenario, we need a filtering mechanism for fake connection attempts before the socket enters the “listen” state and blocks new incoming connections.
Using Netfilter's connection tracking system (conntrack), we can start filtering spurious SYN-ACK and ACK packets before they cause a blocking “listen” state. This was possible for a long time, but was not enabled by default.
The following two commands will help you:
The rule for iptables will catch packets that the connection tracking system has classified as “INVALID” and not part of known connection states.
Configuring sysctl will make the connection tracking system more stringent in categorization and help avoid, including ACK-flood attacks.
As a result, we will reduce the effect of attacks based on SYN – ACK and ACK 20 times.
Conntrack in Netfilter has a bad reputation for low speed, but it was the first time after the advent of technology. It now offers superior scalability and runs very fast. Conntrack works without locks, using RCU (update via copy) for existing connections.
In essence, this will prevent problems from all flooding TCP packets except SYN.
In conntrack there is a scalability problem (similar to the “listen” blocking) that occurs when it comes to creating (or deleting) connections that SYN flood causes.
Even after configuring the contrack SYN packets will be sent to the socket causing a “listen” blocking. The method of mitigating this attack is to send a SYN – cookie and prevent the creation of any status until the SYN – ACK is visible.
Unfortunately, SYN – cookies are sent under the same “listen” blocking, so this mitigation will not solve the scalability problem. We will discuss how to get around this restriction a bit later.
At Netfilter Workshop 2013 , the idea of ​​“network countermeasures” was proposed. This gave birth to the iptables SYNPROXY module and the corresponding changes in the Netfilter core. Now this functionality is available in CentOS 7.
The SYNPROXY module is designed to solve two problems with scalability. Firstly, it works with SYN – cookies in parallel. Secondly, it does not create a conntrack until it receives a SYN – ACK packet, which allows conntrack not to block new connections.
SYNPROXY can be used on the local host or can protect other hosts behind the firewall. As soon as the initial connection is established, conntrack will take over all necessary translations (by reusing parts of the NAT code).
Testing on connections to localhost showed a 10-fold increase in productivity to mitigate SYN – attacks.
Setting up SYNPROXY can be quite complicated without a manual. This article covers the necessary steps, but you can use the 0 and script to simplify the configuration.
This example can be used to protect a web server on port 80.
Make sure that the connections we protect do not create a conntrack for SYN packets.
We include a stricter conntrack. This is necessary in order to have INVALID status for bad ACK packets.
Now we need to process these packets and transfer them directly to the SYNPROXY module. To do this, use the UNTRACKED SYN and INVALID processing rule for packets that contain ACKs from the triple handshake (and others, but they will simply pass through this rule):
Catch the packages with the state of INVALID, which fell into SYNPROXY and destroy them. This will prevent flood SYN – ACK.
Remember to include TCP timestamps. SYN – cookies use this TCP field.
If you have a busy site, it is recommended to configure conntrack to increase the limit of 64 thousand connections. Also increase the size of the conntrack hash. This is very important for performance.
You must set a limit value that is relevant to your site and calculate the memory usage for it. For example, 2,000,000 entries at a time of 288 bytes = maximum of 576 MB of potential memory usage. For the hash, each head of the hash table only takes 8 bytes per million records = 8 MB of fixed allocated memory (remember the size of your L3 cache on the CPU when you select the cache value). You can find out which processor is used on the host with the command:
The inclusion of SYNPROXY may not pass unnoticed. Connection setup will be slower due to the advanced connection setup required by the end host. When the end host is local, everything happens very quickly and hardly adds delays.
The SYNPROXY module parameters must match the TCP options and must be supported by the end host for which the TCP connection is proxied. The detection and configuration is done manually based on the rules (the useful tool “nfsynproxy” is part of the iptables 1.4.21 release). Unfortunately, this means that the module cannot simply be deployed firewalls on DHCP.
In the future, there are plans to auto-detect the TCP options for end hosts. Vote for the feature in the Red Hat bug tracker.
Sources used in the preparation of the article:
Mitigate TCP SYN Flood Attacks
RedHat official blog
RedHat Knowledge Base
CentOS Official Blog
Especially for our readers, we provided the opportunity to try CentOS 7 on a cloud-based VPS from Infobox in Amsterdam. Register the trial version for 15 days via this link . If you need more resources for testing than in the trial version - write to trukhinyuri@infoboxcloud.com
DDoS (Distributed Denial of Service) attacks are becoming more frequent, due to the fact that the business is becoming increasingly dependent on the Internet. One of the most common types of DDoS is the SYN Flood. This main attack of end hosts puts your server to its knees. As a result, your server cannot correctly handle incoming requests.
')
It is important to note that the described protection mechanisms are available in CentOS 7, but are not enabled by default.
Why SYN-flood - pain for the core
The main problem of TCP scalability for the Linux kernel is related to how many new connections can be created in a second. This refers to blocking on a socket in the "listen" state. Estabilished (Installed) connections scale very well. The “listen” state lock is encountered not only with SYN – packets, but also with other packets for the initial connection of “SYN-ACK” and “ACK” (triple handshake packets in TCP). In a flood attack scenario, we need a filtering mechanism for fake connection attempts before the socket enters the “listen” state and blocks new incoming connections.
Basics of filtering conntrack
Using Netfilter's connection tracking system (conntrack), we can start filtering spurious SYN-ACK and ACK packets before they cause a blocking “listen” state. This was possible for a long time, but was not enabled by default.
The following two commands will help you:
iptables -A INPUT -m state --state INVALID -j DROP /sbin/sysctl -w net/netfilter/nf_conntrack_tcp_loose=0 The rule for iptables will catch packets that the connection tracking system has classified as “INVALID” and not part of known connection states.
Configuring sysctl will make the connection tracking system more stringent in categorization and help avoid, including ACK-flood attacks.
What about performance?
As a result, we will reduce the effect of attacks based on SYN – ACK and ACK 20 times.
Conntrack in Netfilter has a bad reputation for low speed, but it was the first time after the advent of technology. It now offers superior scalability and runs very fast. Conntrack works without locks, using RCU (update via copy) for existing connections.
In essence, this will prevent problems from all flooding TCP packets except SYN.
Why it does not work with SYN-flood?
In conntrack there is a scalability problem (similar to the “listen” blocking) that occurs when it comes to creating (or deleting) connections that SYN flood causes.
Even after configuring the contrack SYN packets will be sent to the socket causing a “listen” blocking. The method of mitigating this attack is to send a SYN – cookie and prevent the creation of any status until the SYN – ACK is visible.
Unfortunately, SYN – cookies are sent under the same “listen” blocking, so this mitigation will not solve the scalability problem. We will discuss how to get around this restriction a bit later.
What's new in CentOS 7
At Netfilter Workshop 2013 , the idea of ​​“network countermeasures” was proposed. This gave birth to the iptables SYNPROXY module and the corresponding changes in the Netfilter core. Now this functionality is available in CentOS 7.
The SYNPROXY module is designed to solve two problems with scalability. Firstly, it works with SYN – cookies in parallel. Secondly, it does not create a conntrack until it receives a SYN – ACK packet, which allows conntrack not to block new connections.
SYNPROXY can be used on the local host or can protect other hosts behind the firewall. As soon as the initial connection is established, conntrack will take over all necessary translations (by reusing parts of the NAT code).
Testing on connections to localhost showed a 10-fold increase in productivity to mitigate SYN – attacks.
SYNPROXY setting
Setting up SYNPROXY can be quite complicated without a manual. This article covers the necessary steps, but you can use the 0 and script to simplify the configuration.
This example can be used to protect a web server on port 80.
Step 1
Make sure that the connections we protect do not create a conntrack for SYN packets.
iptables -t raw -I PREROUTING -i $DEV -p tcp -m tcp --syn --dport $PORT -j CT --notrack Step 2
We include a stricter conntrack. This is necessary in order to have INVALID status for bad ACK packets.
/sbin/sysctl -w net/netfilter/nf_conntrack_tcp_loose=0 Step 3
Now we need to process these packets and transfer them directly to the SYNPROXY module. To do this, use the UNTRACKED SYN and INVALID processing rule for packets that contain ACKs from the triple handshake (and others, but they will simply pass through this rule):
iptables -A INPUT -i $DEV -p tcp -m tcp --dport $PORT -m state --state INVALID,UNTRACKED -j SYNPROXY --sack-perm --timestamp --wscale 7 --mss 1460 Step 4
Catch the packages with the state of INVALID, which fell into SYNPROXY and destroy them. This will prevent flood SYN – ACK.
iptables -A INPUT -m state --state INVALID -j DROP Step 5
Remember to include TCP timestamps. SYN – cookies use this TCP field.
/sbin/sysctl -w net/ipv4/tcp_timestamps=1 Step 6
If you have a busy site, it is recommended to configure conntrack to increase the limit of 64 thousand connections. Also increase the size of the conntrack hash. This is very important for performance.
echo 1000000 > /sys/module/nf_conntrack/parameters/hashsize /sbin/sysctl -w net/netfilter/nf_conntrack_max=2000000 You must set a limit value that is relevant to your site and calculate the memory usage for it. For example, 2,000,000 entries at a time of 288 bytes = maximum of 576 MB of potential memory usage. For the hash, each head of the hash table only takes 8 bytes per million records = 8 MB of fixed allocated memory (remember the size of your L3 cache on the CPU when you select the cache value). You can find out which processor is used on the host with the command:
cat /proc/cpuinfo SYNPROXY Considerations
The inclusion of SYNPROXY may not pass unnoticed. Connection setup will be slower due to the advanced connection setup required by the end host. When the end host is local, everything happens very quickly and hardly adds delays.
The SYNPROXY module parameters must match the TCP options and must be supported by the end host for which the TCP connection is proxied. The detection and configuration is done manually based on the rules (the useful tool “nfsynproxy” is part of the iptables 1.4.21 release). Unfortunately, this means that the module cannot simply be deployed firewalls on DHCP.
In the future, there are plans to auto-detect the TCP options for end hosts. Vote for the feature in the Red Hat bug tracker.
Sources used in the preparation of the article:
Mitigate TCP SYN Flood Attacks
RedHat official blog
RedHat Knowledge Base
CentOS Official Blog
Try CentOS 7 in the cloud
Especially for our readers, we provided the opportunity to try CentOS 7 on a cloud-based VPS from Infobox in Amsterdam. Register the trial version for 15 days via this link . If you need more resources for testing than in the trial version - write to trukhinyuri@infoboxcloud.com
Source: https://habr.com/ru/post/232227/
All Articles