The pf(4) firewall originated with the OpenBSD project and has been integrated into the base installs of FreeBSD and NetBSD. pf is kernel-based, meaning it is very fast; it is also a feature-rich, stateful firewall that rivals commercial firewalls in speed and functionality. The pf FAQ (http://www.openbsd.org/faq/pf/) details the many features and provides configuration examples. We describe some of these features next.
An administrator can use the pfctl(8) utility to interact directly with pf. In addition to stopping and starting the firewall, viewing the currently loaded ruleset as well as the state and NAT tables, and adding rules on the fly, pfctl allows direct interaction with the state table.
For example, to delete all state entries from an attacking host immediately, simply specify the host's IP address with pfctl -k ip address
CARP(4) and pfsync(4)
Redundancy (sometimes called high availability) is always a tricky matter. If an important network device such as a router becomes unavailable, the goal is to have another device automatically take over, without losing any existing network connections. Things are even trickier for stateful firewalls as the new firewall needs to have the most recent copy of the state table so it is aware of the state of all current connections.
As a result, providing redundancy for commercial firewall solutions usually requires expensive licensing, difficult configuration, and much testing. The OpenBSD project developed Common Address Resolution Protocol (CARP) to be an open, free, and securely designed replacement to the patented alternatives of Hot Standby Router Protocol (HSRP) and Virtual Router Redundancy Protocol (VRRP).
pfsync(4) uses CARP to provide automatic failover between a pair of pf firewalls. Should one firewall become unavailable, the second firewall takes over automatically without losing any state. It should be noted that although pfsync keeps the state tables synchronized, it does so by sending clear-text multicast packets. For this reason, the two firewalls either should be connected using a crossover cable or updates should be sent over an IPsec tunnel.
ALTernate Queuing (ALTQ) is used to provide quality of service (QoS) and is integrated into the pf firewall. With ALTQ you can create bandwidth policies that limit the amount of bandwidth available to specified services or users.
ALTQ supports several different queuing algorithms including Class Bases Queuing (CBQ), Random Early Detection (RED), Red In/Out (RIO), Hierarchical Fair Service Curve (HSFC), and PRIority Queuing (PRIQ).
Stateful Tracking Options pf includes many options that you can add to TCP rules to limit the effects of port scans, automated rootkits, and password guessing attempts. These stateful tracking options can also reduce the amount of logged events, making logs easier to read. Some of these options include
• max # Limits the number of state entries a rule can add to the state table; this can reduce the risk of a SYN flood attack exhausting system resources.
• max-src-nodes # Limits the number of source IP addresses that can simultaneously create state; this can reduce the risk of a DDoS attack.
• max-src-states # Limits the number of simultaneous state entries that can be created per source IP address; this can reduce the risk of a password guessing program.
• max-src-conn # Limits the maximum number of simultaneous TCP connections that have completed the three-way handshake that a single host can make.
• max-src-conn-rate # / interval Limits the rate of new connections per time interval.
When these options are used in a TCP rule, adding overload <tablename> flush global will prompt pf to flush the offending source IP from the state table and to add that IP address to a table of banned hosts; any future attempts from that IP address will be rejected. This is often enough to stop an attack; should the attacker change IP addresses in order to continue the attack, those IPs will also be flushed once they match one of these rules.
This feature randomizes the Initial Sequence Number (ISN) for TCP packets. This protects operating systems that implement poor ISNs against ISN prediction exploits such as a man-in-the-middle attack. To activate this feature, use the modulate state keywords in your rules.
By using the synproxy state keywords in a TCP rule you can easily take advantage of pf's SYN Proxy feature for either all or specified TCP services. pf's implementation of SYN Proxy intercepts SYN-1 packets. This means that your servers are only aware of completed TCP connections and are thus protected against SYN flood attacks. The firewall itself can be protected against SYN floods by using the stateful tracking options described in the previous section.
Packet Normalization pf provides the scrub keyword, which provides packet normalization. This can protect against certain types of attacks. For example, some attacks use fragments that can't be properly reassembled; scrub rejects these packets. Scrubbing can also reduce the effectiveness of an Nmap scan as it drops TCP packets containing invalid flag combinations. Packet normalization can also enforce a minimum TTL, a random IP ID, and randomize the TCP timestamp (which prevents Nmap from guessing the host's uptime).
OS FingerPrinting (OSFP) uses the /etc/pf.os database to passively detect the type of remote operating system. This means that TCP rules can be designed to pass or block traffic from specific operating systems. This example rule would block packets from hosts running Windows 2000:
block in on $ext if from any os "Windows 2000"
It's important to remember that new service packs and patch levels may change an operating system's fingerprint; additionally, this type of rule probably won't catch handcrafted packets.
authpf(8) requires users to first authenticate to their gateway before allowing their traffic to pass through. To activate this feature, set the user's shell to /usr/sbin/authpf and instruct the user to ssh to the gateway when he or she requires network connectivity. Once the user successfully authenticates, authpf will insert that user's custom rules into the pf ruleset. In other words, authpf makes it possible to both authenticate users and enforce rules on a per-user basis; these features are usually only available on expensive commercial firewall products.
User rules are automatically deleted by authpf once the user logs out or their SSH session disconnects. The username and IP address as well as the connection time is logged for every successful authentication, making it easier to determine who was logged in when. authpf can provide additional security measures on a wireless network and an example configuration can be found in the pf FAQ.
Was this article helpful?
Read how to maintain and repair any desktop and laptop computer. This Ebook has articles with photos and videos that show detailed step by step pc repair and maintenance procedures. There are many links to online videos that explain how you can build, maintain, speed up, clean, and repair your computer yourself. Put the money that you were going to pay the PC Tech in your own pocket.