Is a “packet filter” a firewall?

TLDR; Yes, it is. However it’s limited to OSI Layer 3 and quite limited in functionality. Typically the only information it cares about is port/protocol, IP addresses, direction, and action. It’s not good at determining if the content of the connection looks like it should. For that, we look towards Application Layer Firewalls (aka “next gen”).

My first ever “real” cybersecurity job was in 2011 at Boeing as an intern in the packet filter/firewall engineering teams, and that was my first true introduction to the concept of packet filters, how they work, what their limitations were, how rules were written, and what tools help with the process. According to Rountree (2010), “packet-filtering firewalls operate at the network layer (Layer 3) of the OSI model. Packet-filtering firewalls make processing decisions based on network addresses, ports, or protocols.” He goes on to say that they can operate quickly because they utilize simple logic to make decisions. In my opinion, this is one of the benefits they have over application firewalls. Application firewalls operate at the application layer of the OSI model and typically are much “smarter” than their Layer 3 counterparts. From my experience with vendors like Palo Alto Networks, these types of firewalls (sometimes referred to by the marketing term “next-gen firewalls”) can detect malicious activity and patterns within traffic, identify applications by the traffic they send and receive, and even determine if a malicious user is using an application over a different port/protocol than standard.

Simple testing methods for firewall rules

In my experience, I have tested firewalls (including host-based firewalls and configuration options like “IP tables,” which function similarly at the host level to packet filters) utilizing some basic but well-known network utilities. One that is extremely useful and open source is called “Netcat” (Netcat, 2004). This utility is great at initiating connections per port/IP or hostname and testing to see if an application will respond. I often use it to send very simple HTTP methods like “GET” at an IP address or hostname over port 80 to see if it will return data. If there’s a firewall in the way, Netcat will error out/time out. Because most host-based firewalls like Linux’s IP Tables or “UFW” (super common on Ubuntu flavors) are very basic and similar to packet filters in that they don’t perform analysis on packet content, it’s easy to utilize a tool like Netcat because it’s less likely to be detected and blocked by overloading logs and being too “noisy” (I’m looking at you NMAP…).

Another basic way to test a rule would be to use the intended application to see if it’s blocked or operates as expected. This testing method can be valuable, especially for large enterprise applications. Still, I’d only recommend doing this if you’ve already consulted software documentation resources to ensure all documented ports and protocols are entered into a packet filter’s Access Control Lists (ACLs). One tool that can help augment this process is a prevalent and powerful open-source tool I’m sure many readers will be familiar with called “Wireshark” (Wireshark, 2021). Wireshark is a network analyzer sometimes referred to as a “packet sniffer” thought it can sniff other types of traffic and is not limited to packets. When you’re testing an application to make sure that it works through a particular set of ACL’s you’ve written for a packet filter, you can run Wireshark on a network tap/mirrored port and see if there are any issues within the TCP handshake, dropped packets, etc. which can help you determine if something is wrong. As part of one of my former jobs, I was the product engineer for that particular company’s proxy server/filter, and one of the ways I would address issues with applications being blocked by the proxy server was to utilize Wireshark captures to look for any problems. I have also used Wireshark to do the same thing for packet filters and application layer firewalls.

Writing firewall rules…

To write rules for any type of firewall, I utilize many proven successful methods I’ve used as described above, but to put in more detail, it depends on the type of firewall you’ll be writing the rule for. In a packet filter, the components you typically need are IP address/network range, port, protocol, and sometimes direction (source/destination and vice versa if your rules are explicitly defined to block all incoming/outgoing traffic between zones). For an application-layer firewall, there is much of the same information needed. Still, it will usually require a particular application specified, which is determined by the vendor and options provided. With something like a Palo Alto Firewall, they have many different options and be as specific as “Facebook Messenger” for an application.

What tools do you find useful in this process? Is there anything I missed? Send me an email if there is! I’d love to hear more!

References:

Rountree, D. (2010). Security for Microsoft Windows System Administrators: Introduction to Key Information Security Concepts (1st ed.) [E-book]. Syngress.

Netcat (0.7.1). (2004). [Computer software]. GNU Netcat. http://netcat.sourceforge.net/

Wireshark (3.4.8). (2021). [Computer software]. Wireshark Foundation. https://www.wireshark.org