Distributed Denial of Service (DDoS) Attacks

distributed denial of serviceIn the previous article, we discussed denial of service (DoS) attacks. These attacks involve the use of a single client to launch an attack on a system or service. Distributed denial of service (DDoS) attacks use the same basic attack methodologies as outlined in the previous article, with the exception that the attacks are initiated from multiple client systems.

The way this typically works is that malicious parties will use viruses to subtly gain control over large numbers of computers (typically poorly-defended home computers connected to broadband Internet connections). Unbeknownst to the owner of the computer (which generally continues to function as normal) the system is essentially a zombie waiting to be given instructions. Once the malicious party has gathered an army of zombie computers they are instructed to participate in massive distributed denial of service attacks on unsuspecting victims. A large enough volume of zombie systems can, and indeed have been known to bring down even the largest and most scalable enterprise infrastructure, and even bring parts of the Internet itself to a grinding halt. Merely purchasing more incoming bandwidth than the current volume of attack might not help, because the attacker might be able to simply add more attack machines.

Distributed Denial of Service Attacks: Advantages and Types

There are several advantages to launching a distributed denial of service attack:

  1. Multiple machines can generate more attack traffic than one machine.
  2. Multiple machines are harder to turn off than one attack machine.
  3. The behavior of each attack machine can be stealthier, making it harder to track and shut down.

Distributed denial of service can take several forms. Malware can carry distributed denial of service attack mechanisms. One of the better-known examples of this was MyDoom. Its DoS mechanism was triggered on a specific date and time. this type of distributed denial of service involved hardcoding the target IP address prior to the release of the malware. No further interaction was necessary to launch the attack.


A system may also be compromised with a trojan, allowing the attacker to download a zombie agent, or the trojan may contain one. Attackers can also break into systems using automated tools that exploit flaws in programs that listen for connections from remote hosts. A compromised system becomes known as a bot, and they are controlled by handlers run by the attacker, known as botnets. Many of these tools use classic DoS attack methods centered on IP spoofing and amplification like smurf and fraggle attacks, as well as SYN floods.

A distributed denial of service attack may involve sending forged requests to a very large number of computers that will reply to the requests. Using Internet Protocol address spoofing, the source address is set to that of the targeted victim, which means that all the replies will go to and flood the target.

The primary line of defense for blocking distributed denial of service attacks, as with DoS attacks, is the firewall. Firewalls can be set up to have simple rules to allow or deny protocols, ports or IP addresses. In the case of a simple attack coming from a small number of unusual IP addresses for instance, one could put up a simple rule to drop all incoming traffic from those attackers. But most complex attacks will be hard to block with simple rules. Additionally, firewalls may be too deep in the network hierarchy, although they can prevent users from launching simple flooding type attacks from machines behind the firewall.

Some stateful firewalls, like OpenBSD’s pf (and pfSense, since it’s based on pf), can act as a proxy for connections. Normally when a client initiates a TCP connection to a server, PF will pass the handshake packets between the two endpoints as they arrive. pf can proxy the handshake: pf itself will complete the handshake with the client, initiate a handshake with the server, and then pass packets between the two. In the case of a TCP SYN flood attack, the attacker never completes the three-way handshake, so the attacker’s packets never reach the protected server, but legitimate clients will complete the handshake and get passed. this minimizes te impact of spoofed TCP SYN floods on the protected service, handling it in pf instead.

Most switched also have some automatic and system-wide rate limiting, traffic shaping, delayed binding, deep packet inspection and Bogon (bogus IP) filtering to detect and block denial of service attacks. This will work as long as the distributed denial of service attack is something that can be prevented by using them. SYN floods can be prevented using delayed binding. Content-based DoS or DDoS may be prevented using deep packet inspection. And attacks originating from dark addresses can be prevented using Bogon filtering.


External Links:

Denial of service attack on Wikipedia

PF: Packet Filtering at www.openbsd.org

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 cisco.com

pfctl options at gsp.com

© 2013 David Zientara. All rights reserved. Privacy Policy