Book Review: The Book of PF

The Book of PFThe Book of PF: A No-Nonsense Guide to the OpenBSD Firewall (2nd Edition)
Author: Peter N.M. Hansteen
Publisher: No Starch Press
Publishing Date: November 19, 2010 (2nd Edition)
216 pages (paperback edition)

Book Review

In all my years in IT, I have read a number of computer books, but relatively few of these books I would count as indispensible. For C/C++, there was the elegantly written C Programming Language book written by Kernighan and Ritchie. When I learned Windows programming, Programming Windows® by Charles Petzold proved to be an invaluable resource. Around 1995-96 when I became interested in Java, I used one of the O’Reilly books as my tutorial. Some of the O’Reilly books (as well as ones produced by Sams Publishing) were invaluable in providing some of my initial education in Linux in the 1990s. So when I came across The Book of PF: A No-Nonsense Guide to the OpenBSD Firewall by Peter N.M. Hansteen (2nd Edition, No Starch Press, 2010), I was curious to see how it would measure up.

As it turned out, The Book of PF is a worthwhile read, and for those seeking a more detailed understanding of PF, it should prove quite useful. The book is not a cookbook, as the author states fairly explicitly in the introduction. Thus it does not contain a series of how-to instruction sets; nonetheless, those with little knowledge of pf need not fear, as Hansteen starts with simple concepts and builds on these concepts in subsequent chapters. In this way, he is able to progress from very simple PF rule sets (e.g. block all outside traffic except the ports that need to be open, and only the protocols that are needed) sets to somewhat more involved rule sets (ones for networks that run SSH, FTP, and e-mail services), to even more complex rule sets that start to approximate real world scenarios. It also stresses the importance of making rule sets that are as granular as possible so as to allow only the traffic you really want. I like Hansteen’s attitude as well: he challenges readers not to cut and paste rule sets, but to think for themselves, and he also seems to disdain what he considers overly prophylactic policies such as blocking ping and traceroute. The book will also be a good guide for those who want to effectively protect their networks using such services as synproxy, relayd (for expiring nonfunctional hosts from a load balancing pool), and spamd (for blocking spam).

For those techies who only want to learn about pfSense, there are other books. If you just want to know the basics about how to configure your pfSense box, there’s the pfSense 2 Cookbook by Matt Williamson. If you want a more comprehensive explanation of pfSense’s features, pfSense: The Definitive Guide by Christopher M. Buechler (one of the co-founders of pfSense), Jim Pingle and Michael W. Lucas is likely the book for you. But for the network tech or admin who does not mind working primarily at the command line and editing rule sets manually, “The Book of PF” is a potentially valuable guide. Whether or not its worth your time to understand the nuances of pf is a cost-benefit analysis you will have to make yourself. But you will gain a greater degree of control you could ever hope to have working with the pfSense user interface alone. For example, take the problem of SSH brute force attacks. pfSense allows you to set a maximum number of connections per second, and you can block an IP address or a range of IP addresses. But as far as I know, pfSense does not enable you to set a maximum connection rate and add an IP address to a table of blocked IP addresses if it exceeds the rate. pf makes this possible, and this book shows you how. And this is just one example of how this book demonstrates how you can fine-tune your firewall’s settings; there are many other such instances.

For those really wanting to acquire an in-depth knowledge of pf, BSD and networking in general, Hansteen has included a list of resources as the first appendix to the book. Needless to say, it is chock full of helpful links and contains a bibliography which should provide a good starting point for anyone whose interest in BSD has been piqued.

In conclusion, The Book of PF is not for everyone, but if you are serious about network security, it can potentially be a useful guide. Not only will you be able to customize your firewall rules to meet your requirements, a working knowledge of pf is arguably even more valuable in the long term than a working knowledge of pfSense. pfSense superseded m0n0wall as the firewall/router of choice among many network security experts and will likely be superseded itself someday. pf may or may not be replaced as the primary packet filter for BSD users, but even if it is, my guess is that the structure of the rules will likely be similar, so if you have a good knowledge of pf, the learning curve should not be that steep. As the only in-depth book on pf, The Book of PF is recommended for anyone who wants to gain a better understanding of OpenBSD’s packet filtering engine.

External Links:

The Book of PF: A No-Nonsense Guide to the OpenBSD Firewall at Amazon

Advanced Miscellaneous Options in pfSense: Part Two

In the previous article, I covered the proxy support, load balancing, and power saving options in the advanced pfSense settings. In this article, I will cover the remaining options found by navigating to System -> Advanced and clicking on the “Miscellaneous” tab.

Crypto Acceleration

Advanced Miscellaneous

Other advanced miscellaneous options in pfSense.

The first option that will be covered is found under the “glxsb Crypto Acceleration” heading. Check on the “Use glxsb” check box if you want to enable AMD Geode’s glxsb acceleration. Cryptographic acceleration is available on several platforms, typically on embedded boards such as ALIX and Soekris, but also with add-on cards such as those from Hifn are also supported. Any crypto accelerator supported by FreeBSD will work. Boards utilizing the AMD Geode platform typically have the “AMD Geode LX Security Block” which supports certain encryption types. The AMD Geode LX Security Block will accelerate some cryptographic functions on systems which have the chip. If you have a cryptographic acceleration card with the Geode LX processor, you can check this box. If you have a Hifn cryptographic card, however, do not use this option, as it will take precedence and the Hifn card will not be used. If you do not have a glxsb chip in your system, this option will have no effect. To unload the module, uncheck this option and then reboot.

IPsec Options

Under the “IP Security” heading, there are several settings pertaining to IPsec VPN tunnels. The first setting is the “Prefer older IPsec SAs” check box. In an IPSec VPN tunnel, IPsec secured links are defined in terms of security associations (SAs). Each SA is defined for a single unidirectional flow of data, and usually from one single point to another, covering traffic distinguishable by some unique selector. All traffic flowing over a single SA is treated the same. By default, if several security associations match, the newest one is preferred if it is at least 30 seconds old. Selecting this option causes pfSense to always prefer old SAs over newer ones.

The next option is the “Start racoon in debug mode” check box. Racoon is an Internet Key Exchange (IKE) daemon for automatically keying IPsec connections, to establish security associations with other hosts. Checking this box launches racoon in debug mode so that more verbose logs will be generated to aid in troubleshooting. Changing this setting will restart racoon, which could interrupt VPN connections. The last setting under this heading is “Enable MSS clamping on VPN traffic“. Checking this box allows you to adjust the maximum segment size (MSS) on TCP flows over VPN by typing a different segment size into the edit box below the check box. This helps overcome problems with PMTUD on IPsec VPN links and therefore is sometimes advantageous. If left blank, the MSS remains at the default value of 1400 bytes.

Other Options

The next heading is “Schedules” and the only option is the “Schedule States” check box. By default, schedules clear the states of existing connections when the expiry time has come. Checking this box overrides that behavior by not clearing states for existing connections. The final heading on this page is “Gateway Monitoring”, and has one option: the “States” check box. By default, the monitoring processs will flush states for a gateway that goes down. Checking this box overrides this behavior by not clearing states for existing connections.

Other articles in this series:

webConfigurator options in pfSense

Admin Access Options in pfSense

Firewall Advanced Options in pfSense

NAT and Firewall Options in pfSense

Advanced Networking Options in pfSense

Advanced Miscellaneous Options in pfSense

External Links:

Are cryptographic accelerators supported at

IPsec for Dummies at

The Racoon man page

Advanced Miscellaneous Settings in pfSense

In this article, I will cover some of the Advanced Miscellaneous settings for pfSense. These settings can be found by navigating to System -> Advanced and clicking on the “Miscellaneous” tab.

Advanced Miscellaneous Settings: Proxy Support, Load Balancing, and Power Savings

Advanced Miscellaneous

Some of the Advanced Miscellaneous settings in pfSense.

The first heading in Advanced Miscellaneous settings  is “Proxy Support”. These settings allow you to configure an external web proxy, rather than add a web proxy such as Squid to pfSense. The first option is “Proxy URL“. In this edit box, specify the URL or IP address of the proxy. Next is “Proxy Port“, which specifies the port to use to connect to the proxy (the default is 8080 for HTTP, or 443 for SSL). Then there is “Proxy Username” and “Proxy Pass“, the username and password for the proxy server.

The next heading in Advanced Miscellaneous settings is “Load Balancing”. I already covered load balancing in a series of previous articles (part one part two part three), so I will keep this brief, but I will note that there are two important settings pertaining to load balancing here. The first is the “Use sticky connections” check box. This setting applies in cases where you have a pool with multiple servers with load balancing enabled. Typically, when load balancing is invoked, successive connections are redirected to the servers in a round-robin fashion, and we don’t care if successive connections from the same source are redirected to different servers. Sometimes we do care, however, and in those cases we can check this check box. If this box is checked, successive connections from the same source will be sent to the same web server. This is referred to as a “sticky connection”, and it will exist as long as there are states in the state table that refer to the connection. Once the states expire, so will the sticky connection, and further connections from that host will be redirected to the next server in the round robin pool.

The second check box is “Allow default gateway switching“. If this box is checked, then if the default gateway fails, it will be switched to another available one. This is useful if you have a multi-WAN setup. If the default gateway fails, outbound traffic will be directed to another gateway (e.g. WAN2), and you will still be able to access the internet. If you do not have this box checked, however, even if you have a multi-WAN setup, if the default gateway fails you will lose internet.

The next heading in Advanced Miscellaneous settings is “Power savings”. Here you will find the “Use PowerD” check box. Checking this box invokes the powerd utility, which monitors the system state and sets various power control options accordingly. There are three modes for powerd: maximum, minimum, and adaptive. Maximum mode chooses the highest performance values; minimum mode selects the lowest performance values (which in turns yields the greatest power savings). Adaptive mode attempts to strike a balance between these two settings by degrading performance when the system appears idle and increasing it when the system is busy. Checking this box will invoke powerd in adaptive mode, if nothing else is changed. There is no way to change the mode to min or max from the GUI (yet). If you want to change the mode, however, you can always edit /etc/inc/ manually. In order to do so, log into your pfSense box via SSH, open up in vi like so:

vi /etc/inc/

and look for the function activate_powerd(). You shouldn’t have to scroll down very far. Look for the following line to edit:

exec(“/usr/sbin/powerd -b adp -a adp”);

the “-b” parameter is for battery and “-a” is for A/C. “adp”, of course, is short for “adaptive”. Chnage these parameters to either “min” for minimum mode or “max” for maximum mode as you see fit; then hit the ESCAPE key and type :wq to save the modified file.

In a future article, I will cover more Advanced Miscellaneous settings, including glxsb crypto acceleration and IP settings.

Other articles in this series:

webConfigurator options in pfSense

Admin Access Options in pfSense

Firewall Advanced Options in pfSense

NAT and Firewall Options in pfSense

Advanced Networking Options in pfSense

External links:

Default gateway switching discussion on

powerd options discussion on

Advanced Networking Options in pfSense

This article covers advanced networking options in pfSense, which can be altered by navigating to System -> Advanced Options and clicking on the “Networking” tab.

Advanced Networking Options: IPv6

Advanced networking

Advanced networking options in pfSense.

Under the “IPv6 Options” heading, the first option is the “Allow IPv6” check box. Checking this box allows pfSense to use Internet Protocol version 6, the latest revision of the Internet Protocol, which uses a 128-bit address and thus solves the problem of IPv4 (32-bit) address exhaustion. [IPv6 also adds a number of features not present in IPv4, such as stateless address autoconfiguration, network renumbering, and router announcements when changing network connectivity providers.] Next is the “Enable IPv4 NAT encapsulation of IPv6 packets” check box. Checking this box provides an RFC 2893 compatibility mechanism that can be used to tunneling IPv6 packets over IPv4 infrastructures. If enabled, you need to add a firewall rule to permit IPv6 packets.

Advanced Networking Options: Network Interfaces

Under the “Network Interfaces” heading, the first check box is “Enable device polling“. Device polling lets the system poll network devices for new devices instead of relying on interrupts, which prevents services from becoming inaccessible due to interrupt floods. However, not all network cards support polling, so if you check this box, make sure that your hardware supports device polling.

Next is the “Disable hardware checksum offload“. Checksums are used to ensure the integrity of data portions when frames are transmitted. A network card that receives a frame will calculate the checksum and compare it to the checksum received. If the checksums do not match, a transmission error has occurred and the frame will be re-sent. Checksum offloading, however, is broken with some cards, particularly Realtek ones. Check this box if checksum offloading is a problem. The next check box is “Disable hardware TCP segmentation offload“. The TVP offload engine is a technology used in some network cards to offload processing of the entire TCP/IP stack to the network controlling, thus freeing up the CPU and potentially reducing traffic on whatever interface the network card is on (e.g. PCI or PCI-express). As with checksum offloading, TCP segmentation is broken in some hardware drivers, so checking this box may solve problems with such hardware. The next option is the “Disable hardware receive offload” check box. Large receive offload (LRO) is a technique for increasing inbound throughput of high-bandwidth network connections by aggregating multiple incoming packets into a large buffer before these packets are passed up the networking stack. This has the effect of reducing the number of packets that have to be processed and thus it reduces CPU overhead. Again, LRO is broken in some hardware drivers and checking this option may solve problems with these drivers.

The last of the advanced networking options is “Suppress ARP messages“. This option was discussed in my article on ARP configuration in pfSense. In some cases you may have two network cards on the same physical network, but on different subnets. Everything works, but you get a whole bunch of error messages in the system log whenever a node replies to an ARP request from an interface on the same broadcast domain but a different subnet. These error messages may hide some of the more important error messages. In such cases, you may want to check this option and suppress these ARP log messages.

Other articles in this series:

webConfigurator options in pfSense

Admin Access Options in pfSense

Firewall Advanced Options in pfSense

NAT and Firewall Options in pfSense

External Links:

IPv6 at Wikipedia


TCP offload engine at Wikipedia

Large receiver offload at Wikipedia

NAT and Firewall Advanced Options in pfSense

In this article, I will cover some additional advanced settings available for firewall and NAT, which you can find by navigating to System -> Advanced and clicking on the “Firewall/NAT” tab.

Firewall Advanced Options


Advanced firewall and NAT options in pfSense.

Under “Firewall Advanced”, you will find the “Bypass firewall rules for traffic on the same interface” check box. This option applies only if you have defined one or more static routes (and presumably, at least one gateway; I covered configuring static routes in a previous article). If multiple subnets are connected to the same interface (e.g., if you divide the LAN into two or more separate subnets), using this option may be advantageous.

Next is the “Disable all auto-added VPN rules” check box. Checking this will disable any rules automatically added when a VPN was created. Next is the “Disable reply-to on WAN rules” check box. With Multi-WAN, you generally want to ensure traffic leaves the same interface it arrives on. Hence, reply-to is added automatically by default. When using bridging (or 1:1 NAT port forwarding with multiple interfaces), you must disable this behavior (by checking this box) if the WAN gateway IP is different from the gateway IP of the hosts behind the bridged interface. Finally, there is the “Disable Negate rule on policy routing rules” check box. With Multi-WAN, you generally want to ensure traffic reaches directly connected networks and VPN networks when using policy routing. You can disable this for special purposes (by checking this box), but it requires manually creating rules for this network.

NAT Advanced Options

The next section is “Network Address Translation”. The first option is the “Disable NAT Reflection for port forwards” check box. With NAT reflection, packets from internal networks that are addressed to the network’s public IP address will be treated as if they are coming from from the WAN interface. The router’s port forwarding rules will then determine where the packets go. Checking this box disables the automatic creation of additional NAT redirect rules for access to port forwards on your external IP addresses from within your internal networks.

Next is “Reflection Timeout“. This edit box allows you to set a NAT reflection timeout in seconds. The next option is the “NAT Reflection for 1:1 check box“. Checking this disables the automatic creation of additional NAT 1:1 mappings for access to 1:1 mappings of your external IP addresses from within your internal networks. The next check box is “Automatically create outbound NAT rules which assist inbound NAT rules that direct traffic back out to the same subnet it originated from.” This only applies to 1:1 NAT rules, and is helpful when NAT reflection is enabled.

The last option is “TFTP Proxy“. You can click on an interface listed (hold down SHIFT to select multiple interfaces) to enable TFTP proxy on the interface. Since TFTP is considered to be a security risk (no security or authentication is provided by the protocol specification), this option should only be enabled if absolutely necessary. Finally, click on “Save” to save the changes.

Other articles in this series:

webConfigurator options in pfSense

Admin Access Options in pfSense

Firewall Advanced Options in pfSense

External Links:

Network Address Translation at Wikipedia

Firewall Advanced Options in pfSense

Previously, I covered the advanced admin access options in pfSense (Web Configurator Options, Admin Access Options). In this article, I will cover the advanced firewall options. These you can find by navigating to System -> Advanced and click on the “Firewall/NAT” tab.

Firewall Advanced Options


Advanced firewall options in pfSense.

Under the “Firewall Advanced” heading, you will find several options. First is the “Clear invalid DF bits instead of dropping the packets” check box. This will allow communication with hosts the generate fragmented packets with the don’t fragment bit set (DF), such as Linux NFS. This will cause the filter to not drop such packets; it will instead clear the DF bit. Next is the “Insert a stronger id into IP header of packets passing through the filter” check box. This will replace the IP identification field of packets with random values to compensate for operating systems that use predictable values. It only applies to packets that are not fragmented after the optional packet reassembly.

The next option is “Firewall Optimization Options“. There are four options for state table optimization in the dropdown box:

  1. normal – this is the normal optimization algorithm.
  2. high-latency – this is used for high latency links, such as satellite links (where there is a large delay between frames). When invoked, it expires idle connections later than the default.
  3. aggressive – this expires idle connections more quickly. It makes more efficient use of CPU and memory but can drop legitimate connections. This is best used with low-latency connections.
  4. conservative – this will cause pfSense to try to avoid dropping any legitimate connections at the expense of increased memory usage and CPU utilization.

Next is the “Disable all packet filtering” check box. Checking this check box will convert pfSense into a routing-only platform and also turn off NAT. You probably should only use this option if you know what you’re doing. The next check box is “Disables the PF scrubbing option which can sometimes interfere with NFS and PPTP traffic“. The scrubbing process will cause PF to drop any incoming packets with illegal TCP flag combinations (such as SYN and RST) and to normalize potentially ambiguous combinations (such as SYN and FIN). There may be certain situations where you want to allow illegal/ambiguous TCP flag settings, so check this box if such a situation arises.

Next is “Firewall Maximum States“, which is the maximum number of connections to hold in the firewall state table. “Firewall Maximum Tables” allows you to set the maximum number of tables for systems such as aliases, sshlockout, snort, etc. After this is “Firewall Maximum Table Entries“, the maximum number of table entries, where lists of IPs are held. In all three of these edit boxes, you can leave them blank to retain the default setting. It should be noted that for these settings, the default values are determined based on the amount of RAM available in the system. More RAM means a larger default. The default is designed to be reasonable for most cases, but in some cases, it would need to be increased. You can set these numbers as high as you can handle in terms of RAM. For example, 1 state equals 1K of RAM, so 1 million states = 1K * 1 million, or 1 GB of RAM. Thus you will need 1 GB plus whatever you need for the firewall tables which contain IP addresses.

In the next article in this series, we will continue our look at advanced firewall and NAT options.

External Links:

How to solve connectivity issues with dropped RA and PA packets at

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