How To Build Your Own DDoS Protection With Linux & IPtables: https://t.co/Wi4p9HwkMz
— JavaPipe (@JavaPipe) December 19, 2017
Tweet from JavaPipe's Twitter
JavaPipe
web hosting
Tuesday 19 December 2017
How To Build Your Own DDoS Protection With Linux & IPtables: https://t.co/Wi4p9HwkMz
Tweet from JavaPipe's Twitter
Saturday 9 December 2017
DDoS Protection With IPtables: The Ultimate Guide
There are different ways of building your own anti-DDoS rules for iptables. We will be discussing the most effective iptables DDoS protection methods in this comprehensive tutorial.
This guide will teach you how to:
- Select the best iptables table and chain to stop DDoS attacks
- Tweak your kernel settings to mitigate the effects of DDoS attacks
- Use iptables to block most TCP-based DDoS attacks
- Use iptables SYNPROXY to block SYN floods
Please note that this article is written for professionals who deal with Linux servers on a daily basis.
If you just want to protect your online application from DDoS attacks, you can use our remote protection, a VPS with DDoS protection or a DDoS protected bare metal server.
While one can do a lot with iptables to block DDoS attacks, there isn’t a way around actual hardware firewalls (we recently reviewed RioRey DDoS mitigation hardware) to detect and stop large DDoS floods.
However, it isn’t impossible to filter most bad traffic at line rate using iptables!
We’ll only cover protection from TCP-based attacks. Most UDP-based attacks are amplified reflection attacks that will exhaust the network interface card of any common server.
The only mitigation approach that makes sense against these types of attacks is to block them at the edge or core network or even at the carrier already.
Did you know we now offer VPS with unmetered bandwidth and DDoS protection in Chicago, Illinois and Bucharest, Romania?
If they are able to reach your server, there isn’t much you can do against those multi-Gbit/s attacks except to move to a DDoS protected network.
What Is IPtables?
netfilter iptables (soon to be replaced by nftables) is a user-space command line utility to configure kernel packet filtering rules developed by netfilter.
It’s the default firewall management utility on Linux systems – everyone working with Linux systems should be familiar with it or have at least heard of it.
iptables can be used to filter certain packets, block source or destination ports and IP addresses, forward packets via NAT and a lot of other things.
Most commonly it’s used to block destination ports and source IP addresses.
Why Your IPtables Anti-DDoS Rules Suck
To understand why your current iptables rules to prevent DDoS attacks suck, we first have to dig into how iptables works.
iptables is a command line tool used to set up and control the tables of IP packet filter rules. There are different tables for different purposes.
IPtables Tables
Filter: The filter table is the default and most commonly used table that rules go to if you don’t use the -t (–table) option.
Nat: This table is used for Network Address Translation (NAT). If a packet creates a new connection, the nat table gets checked for rules.
Mangle: The mangle table is used to modify or mark packets and their header information.
Raw: This table’s purpose is mainly to exclude certain packets from connection tracking using the NOTRACK target.
As you can see there are four different tables on an average Linux system that doesn’t have non-standard kernel modules loaded. Each of these tables supports a different set of iptables chains.
IPtables Chains
PREROUTING: raw, nat, mangle
- Applies to packets that enter the network interface card (NIC)
INPUT: filter, mangle
- Applies to packets destined to a local socket
FORWARD: filter, mangle
- Applies to packets that are being routed through the server
OUTPUT: raw, filter, nat, mangle
- Applies to packets that the server sends (locally generated)
POSTROUTING: nat, mangle
- Applies to packets that leave the server
Depending on what kind of packets you want to block or modify, you select a certain iptables table and a chain that the selected table supports.
Of course, we’re still missing an explanation of iptables targets (ACCEPT, DROP, REJECT, etc.), but we’re assuming that if you’re reading this article, you already know how to deal with iptables.
We’re going to explain why your iptables rules suck to stop DDoS and not teach you how to use iptables. Let’s get back to that.
If you want to block a DDoS attack with iptables, performance of the iptables rules is extremely important. Most TCP-based DDoS attack types use a high packet rate, meaning the sheer number of packets per second is what causes the server to go down.
That’s why you want to make sure that you can process and block as many packets per second as possible.
You’ll find that most if not all guides on how to block DDoS attacks using iptables use the filter table and the INPUT chain for anti-DDoS rules.
The issue with this approach is that the INPUT chain is only processed after the PREROUTING and FORWARD chains and therefore only applies if the packet doesn’t match any of these two chains.
This causes a delay in the filtering of the packet which consumes resources. In conclusion, to make our rules as effective as possible, we need to move our anti-DDoS rules as far up the chains as possible.
The first chain that can apply to a packet is the PREROUTING chain, so ideally we’ll want to filter the bad packets in this chain already.
However, the filter table doesn’t support the PREROUTING chain. To get around this problem, we can simply use the mangle table instead of the filter table for our anti-DDoS iptables rules.
It supports most if not all rules that the filter table supports while also supporting all iptables chains.
So you want to know why your iptables DDoS protection rules suck? It’s because you use the filter table and the INPUT chain to block the bad packets!
The best solution to dramatically increase the performance of your iptables rules and therefore the amount of (TCP) DDoS attack traffic they can filter is to use the mangle table and the PREROUTING chain!
The Best Linux Kernel Settings to Mitigate DDoS
Another common mistake is that people don’t use optimized kernel settings to better mitigate the effects of DDoS attacks.
Note that this guide focuses on CentOS 7 as the operating system of choice. CentOS 7 includes a recent version of iptables and support of the new SYNPROXY target.
We won’t cover every single kernel setting that you need to adjust in order to better mitigate DDoS with iptables.
Instead, we provide a set of CentOS 7 kernel settings that we would use. Just put the below in your /etc/sysctl.conf file and apply the settings with sysctl -p.
Anti-DDoS Kernel Settings (sysctl.conf)
kernel.printk = 4 4 1 7 kernel.panic = 10 kernel.sysrq = 0 kernel.shmmax = 4294967296 kernel.shmall = 4194304 kernel.core_uses_pid = 1 kernel.msgmnb = 65536 kernel.msgmax = 65536 vm.swappiness = 20 vm.dirty_ratio = 80 vm.dirty_background_ratio = 5 fs.file-max = 2097152 net.core.netdev_max_backlog = 262144 net.core.rmem_default = 31457280 net.core.rmem_max = 67108864 net.core.wmem_default = 31457280 net.core.wmem_max = 67108864 net.core.somaxconn = 65535 net.core.optmem_max = 25165824 net.ipv4.neigh.default.gc_thresh1 = 4096 net.ipv4.neigh.default.gc_thresh2 = 8192 net.ipv4.neigh.default.gc_thresh3 = 16384 net.ipv4.neigh.default.gc_interval = 5 net.ipv4.neigh.default.gc_stale_time = 120 net.netfilter.nf_conntrack_max = 10000000 net.netfilter.nf_conntrack_tcp_loose = 0 net.netfilter.nf_conntrack_tcp_timeout_established = 1800 net.netfilter.nf_conntrack_tcp_timeout_close = 10 net.netfilter.nf_conntrack_tcp_timeout_close_wait = 10 net.netfilter.nf_conntrack_tcp_timeout_fin_wait = 20 net.netfilter.nf_conntrack_tcp_timeout_last_ack = 20 net.netfilter.nf_conntrack_tcp_timeout_syn_recv = 20 net.netfilter.nf_conntrack_tcp_timeout_syn_sent = 20 net.netfilter.nf_conntrack_tcp_timeout_time_wait = 10 net.ipv4.tcp_slow_start_after_idle = 0 net.ipv4.ip_local_port_range = 1024 65000 net.ipv4.ip_no_pmtu_disc = 1 net.ipv4.route.flush = 1 net.ipv4.route.max_size = 8048576 net.ipv4.icmp_echo_ignore_broadcasts = 1 net.ipv4.icmp_ignore_bogus_error_responses = 1 net.ipv4.tcp_congestion_control = htcp net.ipv4.tcp_mem = 65536 131072 262144 net.ipv4.udp_mem = 65536 131072 262144 net.ipv4.tcp_rmem = 4096 87380 33554432 net.ipv4.udp_rmem_min = 16384 net.ipv4.tcp_wmem = 4096 87380 33554432 net.ipv4.udp_wmem_min = 16384 net.ipv4.tcp_max_tw_buckets = 1440000 net.ipv4.tcp_tw_recycle = 0 net.ipv4.tcp_tw_reuse = 1 net.ipv4.tcp_max_orphans = 400000 net.ipv4.tcp_window_scaling = 1 net.ipv4.tcp_rfc1337 = 1 net.ipv4.tcp_syncookies = 1 net.ipv4.tcp_synack_retries = 1 net.ipv4.tcp_syn_retries = 2 net.ipv4.tcp_max_syn_backlog = 16384 net.ipv4.tcp_timestamps = 1 net.ipv4.tcp_sack = 1 net.ipv4.tcp_fack = 1 net.ipv4.tcp_ecn = 2 net.ipv4.tcp_fin_timeout = 10 net.ipv4.tcp_keepalive_time = 600 net.ipv4.tcp_keepalive_intvl = 60 net.ipv4.tcp_keepalive_probes = 10 net.ipv4.tcp_no_metrics_save = 1 net.ipv4.ip_forward = 0 net.ipv4.conf.all.accept_redirects = 0 net.ipv4.conf.all.send_redirects = 0 net.ipv4.conf.all.accept_source_route = 0 net.ipv4.conf.all.rp_filter = 1
These sysctl.conf settings help to maximize the performance of your server under DDoS as well as the effectiveness of the iptables rules that we’re going to provide in this guide.
Do you want REAL DDoS protection?
The Actual IPtables Anti-DDoS Rules
Considering you now know that you need to use the mangle table and the PREROUTING chain as well as optimized kernel settings to mitigate the effects of DDoS attacks, we’ll now move on to a couple of example rules to mitigate most TCP DDoS attacks.
DDoS attacks are complex.
There are many different types of DDoS and it’s close to impossible to maintain signature-based rules against all of them.
But luckily there is something called connection tracking (nf_conntrack kernel module), which can help us to mitigate almost any TCP-based DDoS attack that doesn’t use SYN packets that seem legitimate.
This includes all types of ACK and SYN-ACK DDoS attacks as well as DDoS attacks that use bogus TCP flags.
We’ll start with just five simple iptables rules that will already drop many TCP-based DDoS attacks.
Block Invalid Packets
iptables -t mangle -A PREROUTING -m conntrack --ctstate INVALID -j DROP
This rule blocks all packets that are not a SYN packet and don’t belong to an established TCP connection.
Block New Packets That Are Not SYN
iptables -t mangle -A PREROUTING -p tcp ! --syn -m conntrack --ctstate NEW -j DROP
This blocks all packets that are new (don’t belong to an established connection) and don’t use the SYN flag. This rule is similar to the “Block Invalid Packets” one, but we found that it catches some packets that the other one doesn’t.
Block Uncommon MSS Values
iptables -t mangle -A PREROUTING -p tcp -m conntrack --ctstate NEW -m tcpmss ! --mss 536:65535 -j DROP
The above iptables rule blocks new packets (only SYN packets can be new packets as per the two previous rules) that use a TCP MSS value that is not common. This helps to block dumb SYN floods.
Block Packets With Bogus TCP Flags
iptables -t mangle -A PREROUTING -p tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j DROP iptables -t mangle -A PREROUTING -p tcp --tcp-flags FIN,SYN FIN,SYN -j DROP iptables -t mangle -A PREROUTING -p tcp --tcp-flags SYN,RST SYN,RST -j DROP iptables -t mangle -A PREROUTING -p tcp --tcp-flags FIN,RST FIN,RST -j DROP iptables -t mangle -A PREROUTING -p tcp --tcp-flags FIN,ACK FIN -j DROP iptables -t mangle -A PREROUTING -p tcp --tcp-flags ACK,URG URG -j DROP iptables -t mangle -A PREROUTING -p tcp --tcp-flags ACK,FIN FIN -j DROP iptables -t mangle -A PREROUTING -p tcp --tcp-flags ACK,PSH PSH -j DROP iptables -t mangle -A PREROUTING -p tcp --tcp-flags ALL ALL -j DROP iptables -t mangle -A PREROUTING -p tcp --tcp-flags ALL NONE -j DROP iptables -t mangle -A PREROUTING -p tcp --tcp-flags ALL FIN,PSH,URG -j DROP iptables -t mangle -A PREROUTING -p tcp --tcp-flags ALL SYN,FIN,PSH,URG -j DROP iptables -t mangle -A PREROUTING -p tcp --tcp-flags ALL SYN,RST,ACK,FIN,URG -j DROP
The above ruleset blocks packets that use bogus TCP flags, ie. TCP flags that legitimate packets wouldn’t use.
Block Packets From Private Subnets (Spoofing)
iptables -t mangle -A PREROUTING -s 224.0.0.0/3 -j DROP iptables -t mangle -A PREROUTING -s 169.254.0.0/16 -j DROP iptables -t mangle -A PREROUTING -s 172.16.0.0/12 -j DROP iptables -t mangle -A PREROUTING -s 192.0.2.0/24 -j DROP iptables -t mangle -A PREROUTING -s 192.168.0.0/16 -j DROP iptables -t mangle -A PREROUTING -s 10.0.0.0/8 -j DROP iptables -t mangle -A PREROUTING -s 0.0.0.0/8 -j DROP iptables -t mangle -A PREROUTING -s 240.0.0.0/5 -j DROP iptables -t mangle -A PREROUTING -s 127.0.0.0/8 ! -i lo -j DROP
These rules block spoofed packets originating from private (local) subnets. On your public network interface you usually don’t want to receive packets from private source IPs.
These rules assume that your loopback interface uses the 127.0.0.0/8 IP space.
These five sets of rules alone already block many TCP-based DDoS attacks at very high packet rates.
With the kernel settings and rules mentioned above, you’ll be able to filter ACK and SYN-ACK attacks at line rate.
Additional Rules
iptables -t mangle -A PREROUTING -p icmp -j DROP
This drops all ICMP packets. ICMP is only used to ping a host to find out if it’s still alive. Because it’s usually not needed and only represents another vulnerability that attackers can exploit, we block all ICMP packets to mitigate Ping of Death (ping flood), ICMP flood and ICMP fragmentation flood.
iptables -A INPUT -p tcp -m connlimit --connlimit-above 80 -j REJECT --reject-with tcp-reset
This iptables rule helps against connection attacks. It rejects connections from hosts that have more than 80 established connections. If you face any issues you should raise the limit as this could cause troubles with legitimate clients that establish a large number of TCP connections.
iptables -A INPUT -p tcp -m conntrack --ctstate NEW -m limit --limit 60/s --limit-burst 20 -j ACCEPT iptables -A INPUT -p tcp -m conntrack --ctstate NEW -j DROP
Limits the new TCP connections that a client can establish per second. This can be useful against connection attacks, but not so much against SYN floods because the usually use an endless amount of different spoofed source IPs.
iptables -t mangle -A PREROUTING -f -j DROP
This rule blocks fragmented packets. Normally you don’t need those and blocking fragments will mitigate UDP fragmentation flood. But most of the time UDP fragmentation floods use a high amount of bandwidth that is likely to exhaust the capacity of your network card, which makes this rule optional and probably not the most useful one.
iptables -A INPUT -p tcp --tcp-flags RST RST -m limit --limit 2/s --limit-burst 2 -j ACCEPT iptables -A INPUT -p tcp --tcp-flags RST RST -j DROP
This limits incoming TCP RST packets to mitigate TCP RST floods. Effectiveness of this rule is questionable.
Mitigating SYN Floods With SYNPROXY
SYNPROXY is a new target of iptables that has been added in Linux kernel version 3.12 and iptables 1.4.21. CentOS 7 backported the feature and it’s available in its 3.10 default kernel.
The purpose of SYNPROXY is to check whether the host that sent the SYN packet actually establishes a full TCP connection or just does nothing after it sent the SYN packet.
If it does nothing, it discards the packet with minimal performance impact.
While the iptables rules that we provided above already block most TCP-based attacks, the attack type that can still slip through them if sophisticated enough is a SYN flood.
It’s important to note that the performance of the rules will always be better if we find a certain pattern or signature to block, such as packet length (-m length), TOS (-m tos), TTL (-m ttl) or strings and hex values (-m string and -m u32 for the more advanced users).
But in some rare cases that’s not possible or at least not easy to achieve. So, in these cases, you can make use of SYNPROXY.
Here are iptables SYNPROXY rules that help mitigate SYN floods that bypass our other rules:
These rules apply to all ports. If you want to use SYNPROXY only on certain TCP ports that are active (recommended – also you should block all TCP ports that are not in use using the mangle table and PREROUTING chain), you can just add –dport 80 to each of the rules if you want to use SYNPROXY on port 80 only.
To verify that SYNPROXY is working, you can do watch -n1 cat /proc/net/stat/synproxy. If the values change when you establish a new TCP connection to the port you use SYNPROXY on, it works.
The Complete IPtables Anti-DDoS Rules
If you don’t want to copy & paste each single rule we discussed in this article, you can use the below ruleset for basic DDoS protection of your Linux server.
### 1: Drop invalid packets ### /sbin/iptables -t mangle -A PREROUTING -m conntrack --ctstate INVALID -j DROP ### 2: Drop TCP packets that are new and are not SYN ### /sbin/iptables -t mangle -A PREROUTING -p tcp ! --syn -m conntrack --ctstate NEW -j DROP ### 3: Drop SYN packets with suspicious MSS value ### /sbin/iptables -t mangle -A PREROUTING -p tcp -m conntrack --ctstate NEW -m tcpmss ! --mss 536:65535 -j DROP ### 4: Block packets with bogus TCP flags ### /sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j DROP /sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags FIN,SYN FIN,SYN -j DROP /sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags SYN,RST SYN,RST -j DROP /sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags FIN,RST FIN,RST -j DROP /sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags FIN,ACK FIN -j DROP /sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags ACK,URG URG -j DROP /sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags ACK,FIN FIN -j DROP /sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags ACK,PSH PSH -j DROP /sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags ALL ALL -j DROP /sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags ALL NONE -j DROP /sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags ALL FIN,PSH,URG -j DROP /sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags ALL SYN,FIN,PSH,URG -j DROP /sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags ALL SYN,RST,ACK,FIN,URG -j DROP ### 5: Block spoofed packets ### /sbin/iptables -t mangle -A PREROUTING -s 224.0.0.0/3 -j DROP /sbin/iptables -t mangle -A PREROUTING -s 169.254.0.0/16 -j DROP /sbin/iptables -t mangle -A PREROUTING -s 172.16.0.0/12 -j DROP /sbin/iptables -t mangle -A PREROUTING -s 192.0.2.0/24 -j DROP /sbin/iptables -t mangle -A PREROUTING -s 192.168.0.0/16 -j DROP /sbin/iptables -t mangle -A PREROUTING -s 10.0.0.0/8 -j DROP /sbin/iptables -t mangle -A PREROUTING -s 0.0.0.0/8 -j DROP /sbin/iptables -t mangle -A PREROUTING -s 240.0.0.0/5 -j DROP /sbin/iptables -t mangle -A PREROUTING -s 127.0.0.0/8 ! -i lo -j DROP ### 6: Drop ICMP (you usually don't need this protocol) ### /sbin/iptables -t mangle -A PREROUTING -p icmp -j DROP ### 7: Drop fragments in all chains ### /sbin/iptables -t mangle -A PREROUTING -f -j DROP ### 8: Limit connections per source IP ### /sbin/iptables -A INPUT -p tcp -m connlimit --connlimit-above 111 -j REJECT --reject-with tcp-reset ### 9: Limit RST packets ### /sbin/iptables -A INPUT -p tcp --tcp-flags RST RST -m limit --limit 2/s --limit-burst 2 -j ACCEPT /sbin/iptables -A INPUT -p tcp --tcp-flags RST RST -j DROP ### 10: Limit new TCP connections per second per source IP ### /sbin/iptables -A INPUT -p tcp -m conntrack --ctstate NEW -m limit --limit 60/s --limit-burst 20 -j ACCEPT /sbin/iptables -A INPUT -p tcp -m conntrack --ctstate NEW -j DROP ### 11: Use SYNPROXY on all ports (disables connection limiting rule) ### # Hidden - unlock content above in "Mitigating SYN Floods With SYNPROXY" section
Bonus Rules
Here are some more iptables rules that are useful to increase the overall security of a Linux server:
### SSH brute-force protection ### /sbin/iptables -A INPUT -p tcp --dport ssh -m conntrack --ctstate NEW -m recent --set /sbin/iptables -A INPUT -p tcp --dport ssh -m conntrack --ctstate NEW -m recent --update --seconds 60 --hitcount 10 -j DROP ### Protection against port scanning ### /sbin/iptables -N port-scanning /sbin/iptables -A port-scanning -p tcp --tcp-flags SYN,ACK,FIN,RST RST -m limit --limit 1/s --limit-burst 2 -j RETURN /sbin/iptables -A port-scanning -j DROP
Conclusion
This tutorial demonstrates some of the most powerful and effective methods to stop DDoS attacks using iptables.
We’ve successfully mitigated DDoS attacks that peaked at multiple million packets per second using these iptables rules.
Every single guide on the same topic that we had researched provided inefficient methods to stop DDoS traffic or only a very limited number of iptables rules.
If used correctly, iptables is an extremely powerful tool that’s able to block different types of DDoS attacks at line-rate of 1GigE NICs and close to line-rate of 10GigE NICs.
Don’t underestimate the power of iptables!
DDoS Protection With IPtables: The Ultimate Guide appeared on JavaPipe
35 Types of DDoS Attacks Explained
DDoS attacks are a major concern for online businesses. According to the Q3 2015 Security Report by Akamai, there’s a 179.66% increase in the total number of DDoS attacks!
This figure suggests that, in the last two years, an alarming number of businesses have been targeted by criminals, activists, and hackers for nefarious reasons. It can not only deny service to the business’ users but also result in expensive bills. Some DDoS attacks can even be financially devastating for a business!
From trying to flood a target with ping command based ICMP echo request to multi-vector attacks, DDoS attacks have grown bigger and sophisticated over the years. In this post, we will take a look at the different types of DDoS attacks. Here’s a list of the different DDoS attack types.
Do you want REAL DDoS protection?
Application Level Attacks
DDoS attacks can target a specific application or a badly coded website to exploit its weakness and take down the entire server as a result. WordPress and Joomla are two examples of applications that can be targeted to exhaust a server’s resources – RAM, CPU, etc. Databases can also be targeted with SQL injections designed to exploit these loopholes.
The exhausted server is then unavailable to process legitimate requests due to exhausted resources. Websites and applications with security loopholes are also susceptible to hackers looking to steal information.
Zero Day (0day) DDoS
This is a standard term (like John Doe) used to describe an attack that is exploiting new vulnerabilities. These ZERO Day DDoS vulnerabilities do not have patches or effective defensive mechanisms.
Ping Flood
An evolved version of ICMP flood, this DDoS attack is also application specific. When a server receives a lot of spoofed Ping packets from a very large set of source IP it is being targeted by a Ping Flood attack. Such an attack’s goal is to flood the target with ping packets until it goes offline.
It is designed to consume all available bandwidth and resources in the network until it is completely drained out and shuts down. This type of DDoS attack is also not easy to detect as it can easily resemble legitimate traffic.
IP Null Attack
Packets contain IPv4 headers which carry information about which Transport Protocol is being used. When attackers set the value of this field to zero, these packets can bypass security measures designed to scan TCP, IP, and ICMP. When the target server tries to put process these packets, it will eventually exhaust its resources and reboot.
CharGEN Flood
It is a very old protocol which can be exploited to execute amplified attacks. A CharGEN amplification attack is carried out by sending small packets carrying a spoofed IP of the target to internet enabled devices running CharGEN. These spoofed requests to such devices are then used to send UDP floods as responses from these devices to the target.
Most internet-enabled printers, copiers etc., have this protocol enabled by default and can be used to execute a CharGEN attack. This can be used to flood a target with UDP packets on port 19. When the target tries to make sense of these requests, it will fail to do so. The server will eventually exhaust its resources and go offline or reboot.
SNMP Flood
Like a CharGEN attack, SNMP can also be used for amplification attacks. SNMP is mainly used on network devices. SNMP amplification attack is carried out by sending small packets carrying a spoofed IP of the target to the internet enabled devices running SNMP.
These spoofed requests to such devices are then used to send UDP floods as responses from these devices to the target. However, amplification effect in SNMP can be greater when compared with CHARGEN and DNS attacks. When the target tries to make sense of this flood of requests, it will end up exhausting its resources and go offline or reboot.
NTP Flood
The NTP protocol is another publicly accessible network protocol. The NTP amplification attack is also carried out by sending small packets carrying a spoofed IP of the target to internet enabled devices running NTP.
These spoofed requests to such devices are then used to send UDP floods as responses from these devices to the target. When the target tries to make sense of this flood of requests, it will end up exhausting its resources and go offline or reboot.
SSDP Flood
SSDP enabled network devices that are also accessible to UPnP from the internet are an easy source for generating SSDP amplification floods. The SSDP amplification attack is also carried out by sending small packets carrying a spoofed IP of the target to devices.
These spoofed requests to such devices are used to send UDP floods as responses from these devices to the target. When the target tries to make sense of this flood of requests, it will end up exhausting its resources and go offline or reboot.
Other Amplified DDoS Attacks
All amplified attacks use the same strategy described above for CHARGEN, NTP, etc. Other UDP protocols that have been identified as possible tools for carring out amplification flood attacks U.S. CERT are:
- SNMPv2
- NetBIOS
- QOTD
- BitTorrent
- Kad
- Quake Network Protocol
- Steam Protocol
Fragmented HTTP Flood
In this example of a sophisticated attack on a known loophole, BOTs with a valid IP are used to establish a valid HTTP connection with a web server. Then, HTTP packets are split by the bot into tiny fragments and sent to the target as slowly as it allows before it times out. This method allows the attackers to keep a connection active for a long time without alerting any defense mechanisms.
An attacker can use one BOT to initiate several undetected, extended and resource consuming sessions. Popular web servers like Apache do not have effective timeout mechanisms. This is a DDoS security loophole that can be exploited with a few BOTs to stop web services.
HTTP Flood
The real IP of the BOTs is used to avoid suspicion. The number of BOTs used to execute the attack is same as the source IP range for this attack. Since the IP addresses of the BOTs are not spoofed, there is no reason for defense mechanisms to flag these valid HTTP requests.
One BOT can be used to send a large number of GET, POST or other HTTP requests to execute an attack. Several bots can be combined in an HTTP DDoS attack to completely cripple the target server.
Single Session HTTP Flood
An attacker can exploit a loophole in HTTP 1.1 to send several requests from a single HTTP session. This allows attackers to send a large number of requests from a handful of sessions. In other words, attackers can bypass the limitations imposed by DDoS defense mechanisms on the number of sessions allowed.
Single Session HTTP Flood also targets a server’s resources to trigger a complete system shutdown or poor performance.
Single Request HTTP Flood
When defense mechanisms evolved to block many incoming packets, attacks like Single Packet HTTP Flood were designed with workarounds to dodge these defenses. This evolution of an HTTP flood exploits another loophole in the HTTP technology. Several HTTP requests can be made by a single HTTP session by masking these requests within one HTTP packet.
This technique allows an attack to stay invisible while exhausting a server’s resources by keeping packet rates within the allowed limits.
Recursive HTTP GET Flood
For an attack to be highly successful, it must remain undetected for as long as possible. The best method to go undetected is to appear as a legitimate request by staying within all the limitations while another attack is being executed. Recursive GET achieves this on its own by collecting a list of pages or images and appearing to be going through these pages or images.
This attack can be combined with an HTTP flood attack for maximum impact.
Random Recursive GET Flood
This attack is a purpose built variation of Recursive GET attack. It is designed for forums, blogs and other websites that have pages in a sequence. Like Recursive GET it also appears to be going through pages. Since page names are in a sequence, to keep up appearance as a legitimate user, it uses random numbers from a valid page range to send a new GET request each time.
Random Recursive GET also aims to deflate its target’s performance with a large number of GET requests and deny access to real users.
Multi-Vector Attacks
We talked about attackers combining Recursive GET attacks with HTTP flood attacks to amplify the effects of an attack. That’s just one example of an attacker using two types of DDoS attacks at the same time to target a server. Attacks can also combine several methods to keep the engineers dealing with the DDoS attack confused.
These attacks are the toughest to deal with and are capable of taking down some of the best-protected servers and networks.
SYN Flood
This attack exploits the design of the three-way TCP communication process between a client, host, and a server. In this process, a client initiates a new session by generating a SYN packet. The host assigns and checks these sessions until they are closed by the client. To carry out a SYN Flood attack, an attacker sends a lot of SYN packets to the target server from spoofed IP addresses.
This attack goes on until it exhausts a server’s connection table memory –stores and processes these incoming SYN packets. The result is a server unavailable to process legitimate requests due to exhausted resources until the attack lasts.
SYN-ACK Flood
The second step of the three-way TCP communication process is exploited by this DDoS attack. In this step, a SYN-ACK packet is generated by the listening host to acknowledge an incoming SYN packet. A large amount of spoofed SYN-ACK packets is sent to a target server in a SYN-ACK Flood attack. The attack tries to exhaust a server’s resources – its RAM, CPU, etc. as the server tries to process this flood of requests.
The result is a server unavailable to process legitimate requests due to exhausted resources until the attack lasts.
ACK & PUSH ACK Flood
During an active TCP-SYN session, ACK or PUSH ACK packets carry information to and from the host and client machines till the session lasts. During an ACK & PUSH ACK flood attack, a large amount of spoofed ACK packets is sent to the target server to deflate it.
Since these packets are not linked with any session on the server’s connection list, the server spends more resources on processing these requests. The result is a server unavailable to process legitimate requests due to exhausted resources until the attack lasts.
ACK Fragmentation Flood
Fragmented ACK packets are used in this bandwidth consuming version of the ACK & PUSH ACK Flood attack. To execute this attack, fragmented packets of 1500 bytes are sent to the target server. It is easier for these packets to reach their target undetected as they are not normally reassembled by routers at the IP level.
This allows an attacker to send few packets with irrelevant data through routing devices to consume large amounts of bandwidth. This attack affects all servers within the target network by trying to consume all available bandwidth in the network.
RST/FIN Flood
After a successful three or four-way TCP-SYN session, RST or FIN packets are exchanged by servers to close the TCP-SYN session between a host and a client machine. In an RST or FIN Flood attack, a target server receives a large number of spoofed RST or FIN packets that do not belong to any session on the target server.
The attack tries to exhaust a server’s resources – its RAM, CPU, etc. as the server tries to process these invalid requests. The result is a server unavailable to process legitimate requests due to exhausted resources.
Synonymous IP Attack
To take a server down, a large number of TCP-SYN packets carrying the target server’s Source IP and Destination IP are sent to the target server. Even though the packets are carrying the target server’s source and destination IP information, this data is not important.
The goal of the Synonymous IP attack is to exhaust a server’s resources – RAM, CPU, etc. as it tries to compute this anomaly. The exhausted server is then unavailable to process legitimate requests due to exhausted resources.
Spoofed Session Flood
Some of the above DDoS attacks are unable to fool most modern defense mechanisms but DDoS attacks are also evolving to bypass these defenses. Fake Session attacks try to bypass security under the disguise of a valid TCP session by carrying a SYN, multiple ACK and one or more RST or FIN packets.
This attack can bypass defense mechanisms that are only monitoring incoming traffic on the network. These DDoS attacks can also exhaust the target’s resources and result in a complete system shutdown or unacceptable system performance.
Multiple SYN-ACK Spoofed Session Flood
This version of a fake session attack contains multiple SYN and multiple ACK packets along with one or more RST or FIN packets. A Multiple SYN-ACK Fake Session is another example of an evolved DDoS attack. They are changed up to bypass defense mechanisms which rely on very specific rules to prevent such attacks.
Like the Fake Session attack, this attack can also exhaust a target’s resources and result in a complete system shutdown or unacceptable system performance.
Multiple ACK Spoofed Session Flood
SYN is completely skipped in this version of Fake Session. Multiple ACK packets are used to begin and carry an attack. These ACK packets are followed by one or more RST or FIN packets to complete the disguise of a TCP session.
These attacks tend to be more successful at staying under the radar as they generate low TCP-SYN traffic compared to the original SYN-Flood attacks. Like its source, the Multiple ACK Fake Session attack can also exhaust a target’s resources and result in a complete system shutdown or unacceptable system performance.
Session Attack
To bypass defenses, instead of using spoofed IPs, this attack uses the real IP address of the BOTs being used to carry out an attack. The number of BOTs used to execute the attack is same as the source IP range for this attack. This attack is executed by creating a TCP-SYN session between a BOT and the target server.
This session is then stretched out until it times out by delaying the ACK packets. Session attacks try to exhaust a server’s resources through these empty sessions. That, in turn, results in a complete system shutdown or unacceptable system performance.
Misused Application Attack
The attackers first hack client machines that host high traffic apps like P2P services. The traffic from these client machines is then redirected to the target server. The target server exhausts its resources as it tries to accept and negotiate the excessive traffic. Defensive mechanisms aren’t triggered in this case as the hacked client machines are actually trying to make a valid connection to the target server.
After successfully redirecting the traffic to the target, as the attack is going on, the attacker drops off the network and becomes untraceable. Misused Application Attack targets a server’s resources and tries to take it down or destroy its performance.
UDP Flood
As the name suggests, in this type of DDoS attack a server is flooded with UDP packets. Unlike TCP, there isn’t an end to end process of communication between client and host. This makes it harder for defensive mechanisms to identify a UDP Flood attack. A large number of spoofed UDP packets are sent to a target server from a massive set of source IP to take it down.
UDP flood attacks can target random servers or a specific server within a network by including the target server’s port and IP address in the attacking packets. The goal of such an attack is to consume the bandwidth in a network until all available bandwidth has been exhausted.
UDP Fragmentation Flood
It is another one of those cleverly masked DDoS attacks that are not easily detected. The activity generated by this attack resembles valid traffic and all of it is kept within limits. This version of the UDP Flood attack sends larger yet fragmented packets to exhaust more bandwidth by sending fewer fragmented UDP packets.
When a target server tries to put these unrelated and forged fragmented UDP packets together, it will fail to do so. Eventually, all available resources are exhausted and the server may reboot.
DNS Flood
One of the most well-known DDoS attacks, this version of UDP flood attack is application specific – DNS servers in this case. It is also one of the toughest DDoS attacks to detect and prevent. To execute, an attacker sends a large amount of spoofed DNS request packets that look no different from real requests from a very large set of source IP.
This makes it impossible for the target server to differentiate between legitimate DNS requests and DNS requests that appear to be legitimate. In trying to serve all the requests, the server exhausts its resources. The attack consumes all available bandwidth in the network until it is completely drained out.
VoIP Flood
This version of application specific UDP flood targets VoIP servers. An attacker sends a large number of spoofed VoIP request packets from a very large set of source IP. When a VoIP server is flooded with spoofed requests, it exhausts all available resources while trying to serve the valid and invalid requests.
This reboots the server or takes a toll on the server’s performance and exhausts the available bandwidth. VoIP floods can contain fixed or random source IP. Fixed source IP address attack is not easy to detect as it masks itself and looks no different from legitimate traffic.
Media Data Flood
Like VoIP flood, a server can also be attacked with media data such as audio and video. A large number of spoofed media data packets are sent by an attacker from a very large set of source IP. When a server is flooded with spoofed media data requests, it exhausts all available resources and network bandwidth to process these requests.
This attack is similar to VoIP floods in every way other than using spoofed media data packets to attacks the server. It can also be hard to detect these attacks when they are using fixed source IP as this gives them a legitimate appearance. The attack is designed to consume all available server resources and bandwidth in the network until it is completely drained out.
Direct UDP Flood
The target server is attacked with a large number of Non-Spoofed UDP packets. To mask the attack, the attacker does not spoof the BOTs actual IP address. The number of BOTs used to execute the attack is same as the source IP range for this attack. The attack is designed to consume all available bandwidth and resources in the network until it is completely drained out and shuts down. This type of DDoS attack is also not easy to detect as it resembles legitimate traffic.
ICMP Flood
Like UDP, the ICMP stack also does not have an end to end process for data exchange. This makes it harder to detect an ICMP Flood attack. An attacker sends a large number of spoofed ICMP packets from a very large set of source IP. When a server is flooded with massive amounts of spoofed ICMP packets, its resources are exhausted in trying to process these requests. This overload reboots the server or has a massive impact on its performance.
ICMP flood attacks can target random servers or a specific server within a network by including the target server’s port and IP address in the packets. The goal of such an attack is to consume bandwidth in the network until it has exhausted the available bandwidth.
ICMP Fragmentation Flood
This version of ICMP Flood attack sends larger packets to exhaust more bandwidth by sending fewer fragmented ICMP packets. When the target server tries to put these forged fragmented ICMP packets with no correlation together, it will fail to do so. The server eventually exhausts its resources and reboots.
35 Types of DDoS Attacks Explained appeared on JavaPipe
Subscribe to:
Posts (Atom)