Denial of Service (DoS) Attacks

denial of serviceDenial of Service (DoS) attacks are undertaken with the express purpose of preventing users from accessing and using a service they should otherwise be able to access. such attacks make malicious use of a variety of different standard protocols and tools. There is no single denial of service attack method, and the term has come to encompass a variety of different forms of attack. Some of the different types of denial of service attacks will be outlined here.

Types of Denial of Service (DoS) Attacks

  • Ping flood: This attack uses the Internet Message Protocol (ICMP) ping request to a server as a denial of service method. The strategy either involves sending ping requests in such vast quantities that the receiving system is unable to respond to valid user requests, or sending ping messages which are so large (known as the ping of death) that the system is unable to handle the request.
  • Smurfing: As with ping flood attacks, smurfing makes use of the TCP Internet Message Protocol (ICMP) ping request to mount DoS attacks. In a typical smurfing attack, the attacker sends a ping request to the broadcast address of the network containing the IP address of the victim, rather than to a specific machine. The network then acts as a smurf amplifier. The ping request is sent to all computers on the broadcast network, which in turn all reply to the IP address of the victim system, thereby overloading the victim with ping responses. The primary method for preventing smurf attacks is to block ICMP traffic through routers so that the ping responses are blocked from reaching internal servers. In addition, services like the Smurf Amplifier registry have given network service providers the ability to identify misconfigured networks and to take appropriate action.
  • TCP SYN Flood: We have already discussed SYN flood attacks as a means of achieving denial of service on this website, but I’ll mention it here again. This attack begins with a client attempting to establish a TCP connection with the victim server. The client sends a request to the server, which in turn returns an ACK package to acknowledge the connection. At this point in the communication, the client should respond with a message accepting the connection. Instead, the client sends another ACK which is respnded to by the server with yet another ACK. The client continues to send ACKs to the server with the effect of causing the server to hold sessions open in anticipation of the client sending the final packet required to complete the connection. As a result the server uses up all available sessions serving the malicious client, thereby prevneting access to other users. One possible countermeasure is to limit the number of connections from any one client (which can easily be done in pfSense), but if the SYN flood is coming from several different clients, it is hardly the ideal solution. Moreover, if the attacker may be using a spoofed IP address, so limiting the number of connections from that IP address may not help at all. Another possibility is to set up a SYN proxy, so that clients do not connect to a server until the SYN/SYN-ACK/ACK handshake is complete.

  • Fraggle: A fraggle attack is similar to a smurfing attack with the exception that the User Datagram Protocol (UDP) is used instead of using ICMP.
  • Land: Under a land attack, the attacker creates a fake SYN packet containing the same source and destination IP addresses and ports and sends it to the victim, causing the system to become confused when trying to respond to the packet.
  • Teardrop: A teardrop type of denial of service attack exploits a weakness in the TCP/IP implementation on some operating systems. The attack works by sending messages fragmented into multiple UDP packages. Ordinarily the operating system is able to reassemble the packets into a complete message by referencing data in each UDB packet. The teardrop attack works by corrupting the offset data in the UDP packets, making it impossible for the system to rebuild the original packets. On systems that are unable to handle this corruption, a crash is the most likely outcome of a teardrop attack.
  • Bonk: An effective attack on some Windows systems involving the transmission corrupted UDP packets to the DNS port (port 53) resulting in a system crash.
  • Boink: This is similar to the Bonk attack except that the corrupted UDP packets are sent to multiple ports, not just port 53.

These are the most common forms of denial of service attacks. In the next article, we will look at distributed denial of service (DDoS) attacks.

External Links:

Denial-of-service attack on Wikipedia

SYN Flood Prevention in pfSense

SYN Flood Attacks Explained

A SYN flood is a denial-of-service attack in which an attacker sends a succession of SYN requests to a target’s system in an attempt to consume enough server resources to make the system unresponsive to legitimate traffic. It takes advantage of a weakness in the TCP protocol: the three-way handshake. When a client attempts to start a TCP connection to a server, the client and server exchange a series of messages, like this:

  1. The client requests a connection by sending a SYN (synchronize) message to the server.
  2. The server acknowledges this request by sending SYN-ACK back to the client.
  3. The client responds with an ACK, and the connection is established.

A SYN flood works by not responding to the server with the expected ACK code. The malicious code can go about this in one of several ways:

  1. The client can simply not send the expected ACK.
  2. The client can spoof the source IP address in the SYN, causing the server to send the SYN-ACK to a falsified IP address, which will not send an ACK because it knows that it never sent a SYN.
  3. Both these attacks involve a single attacker, and as a result, if the attack is traced back to its true source, it can easily be shut down. An attack has a much greater chance of success if the attacker takes advantage of numerous drone machines throughout the internet, and is much more difficult to stop. If the drones use multiple spoofed addresses, the attack will likely be even more effective.
  4. If the attacker has some knowledge of the listener’s operating system, they can fine-tune the attack. For example, if they know the size of the backlog that is used and how long it keeps TCBs in SYN-RECEIVED before timing out and reaping them, they can send a number of SYNs equal to the backlog, and repeat this process periodically as TCBs are reclaimed in order to keep a listener unavailable perpetually.

The server will wait for the acknowledgement for some time, as network congestion could be the cause of the missing ACK, but in an attack increasingly large numbers of half-open connections will bind resources on the server until no new connections can be mad, resulting in a denial of service to legitimate traffic.
The SYN flooding attack became well-known in 1996, when the magazines 2600 and Phrack¬†published descriptions of the attack along with source code to perform it. Attacks on ISPs soon followed, and CERT released an advisory on the attack technique. The protocol flaw in TCP that makes SYN flooding effective is that for the small cost of sending a packet, a client causes a relatively greater expense to the listener by forcing the listener to reserve state in a TCB. A better technique is to make the listener operate statelessly until the initiator can demonstrate its legitimacy. One example of this is the Stream Control Transmission Protocol (SCTP), which has a 4-way handshake, with listener TCB state being created only after the initiator echoes back some “cookie” bytes sent to it by the listener.
Nevertheless, TCP is here to stay, and thus we are forced to resort to other countermeasures. Some well-known countermeasures (listed in RFC 4987) include:

  1. Filtering
  2. Increasing backlog
  3. Reducing SYN-RECEIVED timer
  4. Recycling the Oldest Half-Open TCB
  5. SYN cache
  6. SYN cookies
  7. Hybrid approaches
  8. Firewalls and proxies

Preventing SYN Flood Attacks in pfSense

SYN flood

Limiting the number of connections per second in a firewall rule.

There are several common methods of preventing a SYN flood attack under pfSense. They all have their advantages and disadvantages, and your mileage may vary based on your own security concerns.

The first method is modifying the WAN rule for whichever rule allows traffic to pass to the server you wish to protect. Navigate to Firewall -> Rules and click on the “WAN” tab. Click on the “e” (for edit) to the right of the rule which allows traffic to the server (we are assuming the rule was already created). On the settings page for this rule, scroll down to “Advanced features” and press the “Advanced” button to the right of “Advanced Options“. At “Maximum new connections / per seconds“, set these parameters to 10 and 1, a maximum of 10 connections per second. This will blacklist the IP if it tries to make more than 10 connections per second. You may need to tweak this number; depending on what servers are listening, it may be too low. Press the “Save” button to save the settings, and, if necessary, press “Apply changes“.

Once you have changed the rule, you can run pfctl from a shell to inspect the blocked table:

pfctl -t virusprot -Ts

To delete an item in the blacklist, use this command from the shell:

pfctl -t virusprot -T delete $IPADDRESS

or pfctl -t virusprot -Td $IPADDRESS

where $IPADDRESS is the address to be deleted.

SYN flood

Changing the state type to synproxy in a firewall rule.

Another way of hardening your network against a SYN flood attack is to change the state type of a firewall rule to synproxy. In order to do this, edit this rule, and under “Advanced options“, press the “Advanced” button to the right of “State Type“. In the dropdown box, change the state type to “synproxy state” and press the “Save” button to save the settings, and, if necessary, press “Apply changes“. SYN Proxy stops SYN flood attacks by having the firewall act as a proxy for the target server in performing the three-way handshake. When SYN-Proxy is enabled, the firewall responds with a SYN-ACK packet instead of the server. If the client does not respond with an ACK packet, the handshake is not completed. If an ACK is received, then the handshake is completed and the firewall allows a connection to the server. If it is a SYN-flood attack where the attacker never responds with an ACK, the server never receives any packets from the attacking client and is oblivious to the attack.

One problem with synproxy is in load-balancing setups where a SYN-proxying pfSense could accept connections that the back end is not ready to accept, thereby short-circuiting the intended load-balancing redundancy by establishing connections other than what the load-balancing logic would have selected. When considering adding synproxy to your configuration, you should also consider the impact of services that use load-balancing.

A third method of protecting against SYN flood attacks is to use SYN cookies. This is a method of preventing the SYN queue from filling up by sending back a SYN-ACK packet in response to a SYN packet, but discarding the SYN queue entry. If the server receives a subsequent ACK response from the client, it can reconstruct the SYN queue entry using information encoded in the TCP sequence number. SYN cookies do not break any protocol specifications and thus should be compatible with all TCP implementations. SYN cookies are enabled by default in pfSense; if you need to enable them, navigate to System -> Advanced and click on the “System Tunables” tab. Click on the “e” to the right of “net.inet.tcp.syncookies” in the table, and change the value of this parameter to 1. Then press “Save” to save the changes and “Apply changes” to apply the changes if necessary.

These are some of the more obvious solutions to the problem of SYN flood attacks and are relatively easy to implement, but there are other methods (e.g., increasing the size of the SYN queue might work, or expiring the oldest half-open connections) that might be more effective in protecting your network. If you have alternate suggestions, I would love to hear them, so feel free to comment.

External Links:

SYN flood at Wikipedia

SYN cookies at Wikipedia

Defenses Against TCP SYN Flooding Attacks at

pfctl options at

© 2013 David Zientara. All rights reserved. Privacy Policy