In my last article on How to Prevent Threats and Attacks on Your Cisco Network I explained in detail the various reconnaissance techniques that an attacker can exploit.
Today I will focus on what is known as Denial-of-Service (DoS) Attacks.
I’m very disappointed to admit that in our days this type of attack is one of the most common attacks found in the network community. The intention of the attacker in this case is to stress the victim with a tremendous amount of spurious traffic so that the network has no more free resources to process normal legitimate traffic.
Learning about these types of network attacks — learning your enemy — will help you be prepared for the worst. Once you understand your enemy’s behavior and the different types of network threats we’ll move on to specific solutions and how to protect your network.
Denial of Service Attacks can take many forms. The most important ones are:
All these attacks have one thing in common which is nothing else than making their victim unable to serve legitimate traffic by filling up its session table with malicious connection attempts.
Let’s see in more detail how these attacks are utilized.
Then SYN flag of a TCP segment is activated when a host is initiating a new TCP connection. The connection establishment is successfully completed when the 3-way handshake method is performed as seen below:
An attacker could deliberately flood the server with TCP SYN segments without acknowledging back the server’s SYN response. As a consequence the server’s session table is filled up with ongoing Session requests driving its resources to the edge making it unable to accept legitimate connection requests until its TCP inactivity timer is reached where it would start dropping incomplete sessions.
This kind of attack is usually originated by a spoofed source IP address making it harder to track down the attacker. A schematic explanation of the TCP SYN attack is presented below:
Similar to the SYN Flood attack, an ICMP flood takes place when an attacker overloads its victim with a huge number of ICMP echo requests with spoofed source IP addresses.
This type of attack has caused a lot of headaches to network administrators in the past therefore it is the first attack that has been “fought and killed” nowadays, using various methods. The simplest one was to completely disable ICMP from untrusted interfaces and the more complicated one was to policy the rate of transmission of ICMP requests and limit down this rate in case of aggression.
The following diagram shows how this type of attack is performed:
UDP flooding doesn’t differ from ICMP flooding. The idea behind these attacks is the same and we have already talked about it. The only difference in this case is the fact that the IP packets that the attacker uses against its victim contain UDP datagrams of different sizes.
The following picture illustrates the “concept” of this attack:
When the attacker initiates a SYN Flood attack using the IP address of the victim as source and destination IP address, then it is said that the attacker has launched a “land attack”.
If the victim has not taken any precautions for this type of attack, it could end up trying to establish a connection with itself falling into a dead-end loop that exists until the idle timeout value is reached.
The following diagram shows clearly the sequence flow of this attack:
This type of attack deals with fragmentation and reassembly of IP packets. The IP header contains the necessary fields to handle fragmentation issues. Basically there are three fields within an IP datagram related to fragmentation and reassembly; these area:
The Fragment Offset field, which is the crucial field in our case, is used to indicate the starting position of each fragment relative to the original unfragmented packet. An attacker could start transmitting fragmented IP packets containing overlapped Fragment Offsets making the victim unable to reassemble them exhausting the victim’s resources and possibly crashing it.
The following diagram will help you understand how this attack is utilized:
Finally, to close the discussion, I would like to say a few things about the PING of Death attack.
There is a specific ICMP echo variation that could cause a system crash. The difference of the echo request from the normal ones is the large size of IP packet it contains. RFC 791 specifies that the maximum size of an IP packet is 65,535 bytes. An ICMP echo request with more than 65,507 (65,535-20-8) bytes of data could cause a remote system to crash while reassembling the packet fragments.
The Ping of Death Datagram is presented below:
You should have “learned your enemies” by now. The information in this and my previous article will prepare you for any kind of network threat.
Equipped with the appropriate knowledge and with the will and strength to defeat all potential attackers, you are ready for the “battle”. It won’t be easy — you will have to continuously monitor and adjust your configuration to be able to handle possible new discovered attacks.
Please Note:
It was not my intention to discuss possible solutions for each specific attack type, I will cover this in my upcoming articles.
For the time being, keep in mind that there is no single solution to any problem. There are good, bad, cheap, expensive, upgradeable and fast-fix solutions. Finding the appropriate one is not an easy task. You will always have to adjust your protection measures according to your network. This is very important and you should not forget this.
No one can tell you the “correct” values for you to configure. YOU have to find those values by performing tests within your infrastructure in terms of connectivity and application.
Stelios Antoniou (CCNA, NET+, MOUS) holds a BSc in Electronic Engineering and an MSc in Communication Networks. He has over three years of experience in teaching MS Office applications, networking courses and GCE courses in Information Technology. Stelios is currently working as a VoIP Engineer in a Telecom company, where he uses his knowledge in practice. He has successfully completed training on CCNP topics, Linux and IMS. His enthusiasm, ambition and knowledge motivate him to offer his best. Stelios has written many articles covering Cisco CCENT, CCNA, and CCNP.