This technique is used to attack the host in such a way that the host won't be able to serve any further requests to the user. Finally, the server crashes, resulting in a server unavailable condition.
There are various attack techniques used in this topic. We will cover SYN flood and ICMP flood detection with the help of Wireshark.
We learned about the TCP handshake process in Chapter 3, Analyzing the TCP Network. In this handshake process, a connection is established with SYN, SYN-ACK, and ACK between the client and server.
In the SYN flood attack scenario, what is happening is that:
- The client is sending very fast SYN; it has received the SYN-ACK but doesn't respond with the final ACK
- Alternatively, the client is sending very fast SYN and blocking the SYN-ACK from the server, or the client is sending very fast SYN from a spoofed IP address so the SYN-ACK is sent to an unknown host that virtually doesn't exist
In all these scenarios, the TCP/IP stack file descriptors are consumed, causing the server to slow down and finally crash.
Open the SYN_FLOOD.pcap packet capture file in Wireshark and perform the following steps:
- Click on Statistics | IO Graph.
- The IO Graph dialog box will appear.
- Generate four graphs for the TCP handshake message SYN, ACK, FIN, and PUSH.
The IO graph statistics show the following summary:
- The TCP connection never closes as there is no count for
tcp.flags.fin - The TCP connection never exchanges any data as there is no count for
tcp.flags.push - The count of SYN packets is very high
- The count of ACK is half of that of the SYN packets
In real scenarios, this data will be mixed up with actual packet flows, but the analysis technique will remain the same. The moment you see an unexpected growth in SYN packets or a spike in SYN packets, it's a SYN flood from DoS or from the multiple-source DDoS.
SYN attacks can be mitigated. The following are a few mitigation plans:
- TCP/IP stack hardening: The operating system decides how many times SYN, SYN-ACK, ACK will be repeated; lowering the SYN,ACK retries will help the server mitigate SYN flood attacks. A SYN cookie is used to resist SYN flood attacks. To perform all these on Linux systems, edit the
/etc/sysctl.conffile and make changes to these entries:#Prevent SYN attack, enable SYNcookies (they will kick-in when the max_syn_backlog reached) net.ipv4.tcp_syncookies = 1 net.ipv4.tcp_syn_retries = 2 net.ipv4.tcp_synack_retries = 2 net.ipv4.tcp_max_syn_backlog = 4096 # Increase the tcp-time-wait buckets pool size to prevent simple DOS attacks net.ipv4.tcp_max_tw_buckets = 1440000
- Restart
sycltlto apply the changes:bash#sysctl -p - IPtables firewalls can be set to deny the IPs that are causing the problem. To generate the firewall rules, use the Wireshark feature generating Firewall rules to drop the traffic that is causing DoS.
- For example, blocking the traffic causing the DoS:
# Netfilter (iptables) iptables -A INPUT -i eth0 -d 10.0.0.3/32 -j DROP ! Cisco IOS (standard) access-list NUMBER deny host 10.0.0.3 # IPFirewall (ipfw) add deny ip from 10.0.0.3 to any in # Windows Firewall (netsh) add portopening tcp 443 Wireshark DISABLE 10.0.0.3
- Ports opened to the external world should be audited.
- Monitoring by creating alerts on the spikes that show unhealthy trends on the network which can result in the DoS scenario; generate the firewall rule dynamically and apply it on the targeted VM.
- Network ACLs block the traffic at the router level; introduce the IDS/IPS system to the network.
- Use the loadbalancer as the connection off-loader. In this case, if an attack happens, it will happen on the loadbalancer. The VM will remain protected. Most of the commercially available loadbalancers have the ability to defend themselves from this type of attack.
- Rate-limiting the SYN per second per IP.
- Put DoS/DDoS protection on the data center edge router (L2).
- Apply multiple levels of detection and knowing the signatures and attributes of suspected traffic locations.
- Prepare mitigation plans.
Internet Control Message Protocol (ICMP) flood is also categorized as a Layer 3 DoS attack or a DDoS attack. It works as follows: an attacker is trying to flood the echo request (ping) packet with a spoofed IP address or the server is flooded with echo requests (ping packets) and not able to process the echo response for each ICMP echo request, resulting in host slowness and denial of service.
Open the ICMP_Flood_01.pcap packet capture file in Wireshark and perform the following steps:
- Click on Statistics | IO Graph.
- The IO Graph dialog box will appear.
- Generate graphs for ICMP and ICMPv6.
As shown in the screenshot, ICMP flood has the following characteristics:
The following are a few mitigation plans for the ICMP flood attack:
- OS hardening: On the host machine (production environment) disable the ICMP and ICMPv6 protocol through the iptables firewall:
bash# iptables -I INPUT -p icmp --icmp-type 8 -j DROP bash# iptables -A OUTPUT -p icmp -o eth0 -j ACCEPT bash# iptables -A INPUT -p icmp --icmp-type echo-reply -s 0/0 -i eth0 -j ACCEPT bash# iptables -A INPUT -p icmp --icmp-type destination-unreachable -s 0/0 -i eth0 -j ACCEPT bash# iptables -A INPUT -p icmp --icmp-type time-exceeded -s 0/0 -i eth0 -j ACCEPT bash# iptables -A INPUT -p icmp -i eth0 -j DROP bash# ip6tables -I INPUT -p icmpv6 –icmpv6-type 8 -j DROP bash# ip6tables -I INPUT -p icmpv6 -i eth0 -j DROP
- TCP/IP stack hardening: by editing the
sysctl.conffile and adding the following entry in this file:net.ipv4.icmp_echo_ignore_all = 1
- Restart
sycltlto apply the changes:bash#sysctl -p - Rate-limiting on the Router level if ICMP/ICMPv6 traffic is allowed
- The firewall should block the ICMP/ICPMv6 traffic on the router
This kind of attack happens on Layer 7 and it is difficult to detect in the sense that it resembles legitimate website traffic. In Analyzing SSL/TLS, we learned about SSL and the handshake process. The attacker can use the handshake against the system to create a DoS/DDoS attack. As handshake involves larger exchange of message between client and the server, for example, in case of one way auth total number of packet exchanges to established a connection is approximate 12 (that is, 3 packets TCP handshake + 9 packets SSL handshake = 12 packets exchanged).
The attacker can flood the SSL connection and make the server busy, to just establish the connection and try to create the DoS/DDoS scenario.
Wireshark can help in identifying from which IP maximum number of packet has arrived. This feature is called Wireshark Conversations, and can be used in any kind of flood scenario (DoS attack).
Open the ICMP_Flood_01.pcap packet capture file in Wireshark and perform the following steps:
Other categories of Layer 7 attacks are HTTP/HTTPS POST flood and HTTP/HTTPS GET flood.