CentOS 7. Overview. Part 4: Mitigating DDoS TCP SYN Flood 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 on the NFS network file system and its environment . This article will talk about mitigating DDoS TCP SYN Flood attacks. At the end of the post, a link to the free CentOS 7 testing in the Infobox cloud VPS .



    DDoS (Distributed Denial of Service) attacks are becoming more frequent because the business is becoming more and more dependent on the Internet. One of the most common types of DDoS is SYN Flood. This is the main attack on end hosts, knocking your server down. As a result, your server cannot handle incoming requests correctly.

    It is important to note that the described security mechanisms are available in CentOS 7, but are not enabled by default.

    Why SYN-flood is a pain for the core


    The main problem with TCP scalability for the Linux kernel is how many new connections can be created in a second. This refers to locking on a socket in the “listen” state. Estabilished (Installed) connections scale very well. The “listen” status 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 the flood attack scenario, we need a mechanism for filtering fake connection attempts before the socket enters the “listen” state and blocks new incoming connections.

    Conntrack filtering basics


    Using the connection tracking system in Netfilter (conntrack), we can begin to filter out false SYN-ACK and ACK packets before they trigger a blocking listen state. This has been 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 which are not part of the known connection states.

    Configuring sysctl will make the connection tracking system more stringent in categorization and will help to avoid ACK – flood attacks.

    What about performance?


    As a result, we will reduce the impact of attacks based on SYN – ACK and ACK by 20 times.

    Conntrack at Netfilter has a poor reputation for its low speed, but this was the first time since the advent of technology. Now it offers superior scalability and is very fast. Conntrack works without locks, using RCU (update via copy) for existing connections.

    In essence, this will prevent problems from all flood TCP packets except SYN.

    Why does this not work with SYN-flood?


    Conntrack has a scalability problem (similar to a “listen” lock) that occurs when it comes to creating (or deleting) connections caused by the SYN flood.

    Even after contrack SYN is configured, packets will be sent to the socket causing a “listen” lock. The mitigation technique for this attack is to send SYN cookies and prevent the creation of any status until the SYN – ACK is visible.

    Unfortunately, SYN cookies are sent under the same “listen” lock, so this mitigation will not solve the scalability problem. Later we will discuss how to get around this limitation.

    What's New in CentOS 7


    At Netfilter Workshop 2013 , the idea of ​​“network countermeasures” was proposed. This gave birth to the SYNPROXY iptables module and related changes to the Netfilter core. This functionality is now available in CentOS 7.

    The SYNPROXY module is designed to solve two scalability issues. Firstly, it works with SYN cookies in parallel. Secondly, it does not create conntrack until the SYN – ACK packet is received, which allows conntrack not to block new connections.

    SYNPROXY can be used on a local host or can protect other hosts behind a firewall. Once the initial connection is established, conntrack will take care of all the necessary translations (reusing parts of the NAT code).

    Testing on connections to localhost showed a 10-fold increase in performance to mitigate SYN attacks.

    SYNPROXY Setup


    Configuring SYNPROXY can be quite complicated without a guide. This article covers the necessary steps, however you can use 0 and a script to simplify the configuration.

    This example can be used to secure a web server on port 80.

    Step 1

    Make sure that the connections we protect do not create conntrack for SYN packets.
    iptables -t raw -I PREROUTING -i $DEV -p tcp -m tcp --syn --dport $PORT -j CT --notrack
    

    Step 2

    Turn on the stricter conntrack. It is necessary 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 pass them directly to the SYNPROXY module. To do this, use the UNTRACKED SYN and INVALID processing rule for packets that contain the ACK from a 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 packets with an INVALID state that are in SYNPROXY and destroy them. This will prevent the SYN – ACK flood.
    iptables -A INPUT -m state --state INVALID -j DROP
    

    Step 5

    Remember to enable 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 need to set the limits that are relevant for your site and calculate the memory usage for it. For example, 2,000,000 records at a time of 288 bytes = a maximum of 576 MB of potential memory usage. For a hash, each head of the hash table occupies only 8 bytes per million records = 8 MB of fixed allocated memory (remember the size of your CPU cache L3 when choosing a cache value). To find out which processor is used on the host, use the command:
    cat /proc/cpuinfo
    


    SYNPROXY Considerations


    Turning on SYNPROXY may not go unnoticed. Connection setup will be slower due to additional configuration of the connection required by the end host. When the end host is local, everything happens very quickly and practically does not add delays.

    The parameters of the SYNPROXY module must correspond to the TCP options and must be supported by the end host for which the TCP connection is proxied. Detection and configuration is done manually based on rules (a useful tool is “nfsynproxy” - part of iptables 1.4.21 release). Unfortunately, this means that the module cannot simply be deployed to DHCP firewalls.

    In the future, there are plans to auto-detect 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
    Official RedHat Blog RedHat
    Knowledge Base
    Official CentOS Blog

    Try CentOS 7 in the Cloud

    Especially for our readers, we provided the opportunity to try CentOS 7 on the Infobox cloud VPS in Amsterdam. Register a trial version for 15 days at this link . If you need more resources for testing than in the trial version - write to trukhinyuri@infoboxcloud.com

    Also popular now: