On a fundamental level, the purpose of a network firewall is to act as a packet filter. A firewall is placed on the boundary between trusted (internal) networks and untrusted (external) networks. When packets coming from the external network to the internal network do not match the packet filter’s set of rules (ruleset), the packets are either silently discarded (in other words, dropped) or an Internet Control Message Protocol (ICMP) message is returned to the sender (in which case we say the packet was rejected). If the packets match the ruleset, they are allowed through the firewall (in which case we say the packet passes through).

As you might have deduced, a good default firewall policy is to block all traffic not explicitly allowed. This is generally the policy that pfSense follows. In addition, the following two rules are in place when pfSense is initially installed and configured:

• On the WAN interface, the RFC 1918 (private) and bogon (currently unassigned) networks are blocked by default, which makes sense, because we don't want private addresses to be the source or destination of packets sent over the public internet. It is not allowed, and routers on the public internet wouldn't know what to do with them anyway. The same goes for currently unassigned networks. Bogon networks cannot be the source of legitimate traffic; they may very well be the source of an attack, and we can eliminate the possibility of such an attack by blocking them.
• On the LAN interface, there are two default rules: an Allow LAN to any rule for IPv4 traffic, and an Allow LAN to any rule for IPv6. These rules exist to make pfSense as plug-and-play as possible; without them, the LAN network would be blocked from accessing the WAN side of the network (thus, it would likely be blocked from accessing the internet). Note that these default rules are only automatically created on the LAN interface; if we add other interfaces in order to create more private networks, we will have to generate these rules ourselves, or create floating rules that apply to multiple interfaces.

While stateful firewalls greatly reduce the amount of work a firewall must do, they come with a downside. These connections, or states, have to be kept track of, which is done by creating entries in a table called a state table. In pfSense, each table entry uses up about 1 K of RAM. We can set the firewall’s maximum number of connections and maximum number of state table entries by navigating to System | Advanced and clicking on the Firewall and NAT tab. The Firewall Maximum States and Firewall Maximum Table Entries parameters are the relevant settings. The former parameter controls the maximum number of connections, whereas the latter controls the maximum number of entries, which can be greater than the number of connections–the use of a proxy server, for example, will not create an additional connection, but it will take up another entry in the table. You will want to make sure that Firewall Maximum Table Entries is set low enough that the state table does not use up all available memory.

The fact that the state table has a finite maximum size sets up a potential attack vector. If the number of connections reaches the number specified in Firewall Maximum States, unpredictable things may happen if any additional connections are attempted. Connections may be dropped in order to ensure that the number of connections does not exceed the allowed maximum, or new connections may not be possible. Attackers, realizing this, may flood your firewall with fake connection attempts, thereby preventing legitimate traffic from reaching your site. This is called a denial-of-service (DoS) attack:

One particular form of a DoS attack is known as a SYN flood attack. A SYN flood attack exploits a weakness in the TCP three-way handshake. The TCP three-way handshake entails the following:

1. The client sends a SYN (synchronization) packet, along with a randomly-chosen initial sequence number.
2. The server sends back an acknowledgment that it received the SYN packet (a SYN-ACK packet), along with the client's sequence number plus 1, and its own randomly-chosen initial sequence number.

3. The client sends back an acknowledgment that it received the SYN-ACK packet (an ACK packet), along with the server's sequence number plus 1.

Note that the client and server have their own sequence numbers, and when data is sent to either the client or the server, the other side will increment this number by 1 and send it. This ensures the proper ordering of the packets. The SYN, SYN-ACK, ACK sequence ensures that each side is ready to send and receive data. All three steps must be completed before a connection is established.

With the SYN flood attack, the attacker sends out SYN packets, but never ACK packets, even if the SYN-ACK packet is received. If the firewall creates an entry in the state table as soon as the SYN packet is received, that is one less entry that could be used by a legitimate connection. Enough SYN packets could cause all state table entries to be used up and prevent legitimate traffic from getting through.

There are a number of different ways to mitigate such attacks. One is to try to block the source of the attack from connecting to your network. This might work, but the attacker might spoof its IP address, thwarting your attempts to block them. Another way is to set up the state table so that entries are not created until the final ACK packet is received.

Another security problem with stateful firewalls is that an attacker might establish a legitimate connection and then trick a host behind the firewall into doing its bidding and establishing connections. In this case, the return traffic is the security vulnerability. The only way to defeat these exploits is to audit software running on your network. Also, protocol dissectors in stateful firewalls have had known security issues, highlighting the importance of keeping your firewall software up to date.

There are essentially two types of filtering with firewalls. Ingress filtering involves filtering traffic coming into our networks, while egress filtering involves filtering traffic going either from our internal networks to the public internet, or from one network segment to another internal network segment. Ingress filtering is by far the more common form of firewall filtering, and it is easy to see why. We would tend to assume that most attacks would be coming from public, untrusted networks, and would thus want to filter traffic accordingly.

There are, however, several reasons why egress filtering is also a good idea. One reason is that in the case of a network operated by a company for business reasons, egress filtering can help cut down on network abuse by employees. Egress filtering can limit access to non-work-related applications. Egress filtering combined with content filtering can be used to block employee access to non-work-related websites, thereby cutting down on net abuse and improving worker productivity.

Along with network abuse, there is the issue of bandwidth abuse, which can be costly to a company. Assume that one-third of bandwidth is used by employees for non-business-related purposes. By employing egress filtering, you can potentially cut bandwidth usage by a third and possibly even downgrade to a lower tier of service while still having the same amount of bandwidth you had for business-related purposes before you employed egress filtering.

Another reason for egress filtering is to eliminate liability to third parties should our networks become compromised. Despite our best efforts, it is possible that malware may find its way onto our local networks. If you do not employ egress filtering, it will be possible for this malware to either phone home or to attack external networks. The goal of malware could be to send data back to a network controlled by the attacker; it may also want to turn your computers into bots that then launch attacks on other networks. In either case, a lack of egress filtering will allow the malware to achieve its objectives and potentially leave you liable for damage done to external networks. Harm can come to other networks in the form of distributed denial-of-service (DDoS) attacks, or spam or phishing campaigns. This can become especially problematic if you have several connections to the internet. If you are running a DNS server on your network, someone might use it to host the zone data for a malicious domain. In short, you could unwittingly be an accomplice to criminal activities, which is definitely something we want to avoid doing.

Once a network is compromised, usually all egress filtering will do is minimize damage. Sometimes, however, egress filtering can prevent a network from being compromised. And in some cases, it can stop malware in its tracks. Often, malware needs outbound network access to work at all. Consider the case of the Code Red worm. This worm exploited a vulnerability in Microsoft's Internet Information Services (IIS) web server, whereby a string overflowing a buffer could contain arbitrary code that would then be executed by IIS. The worm placed its payload in the overflow. Code Red was set up to look for other IIS servers during the first 19 days of the month; if it found other IIS servers, it would spread itself to them (assuming they hadn't already patched the vulnerability). On the 20th day of the month, the worm would launch DoS attacks on certain IP addresses; these attacks would continue for a week. The worm would remain dormant for the rest of the month, and every month the cycle would repeat.

By using egress filtering, we would block Code Red, even if it had already infected our system. Without outbound access, it would be unable to infect other IIS servers, and it would be unable to use our network as a springboard for launching DoS attacks (and so we would not be implicated in such attacks). While we may not always be this fortunate, this example illustrates that egress filtering can be a valuable tool.

Finally, egress filtering can help detect misconfigured network devices. A good example is an SNMP-enabled device trying to connect to a non-existent SNMP server. The traffic is unnecessary, and egress filtering can help us detect it so that we can configure these devices correctly.