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

Be Sociable, Share!

Speak Your Mind

*

© 2013 David Zientara. All rights reserved. Privacy Policy