What Is Packet Filtering?


Packet filtering is just comparing packets to a list of rules and accepting or rejecting the packets on the basis of those rules. As network administrator, you decide which packets are naughty and which are nice. When you filter packets for a single host, you could legitimately call that host hardened. (The word "hardened" means almost exactly what "firewall" means — i.e., nothing.) When you force all packets on your network through a single host that filters packets, you have a basic firewall.

A basic packet filter may only allow you to filter based upon TCP or UDP protocol number. Some don't even allow you to filter by ICMP type or cannot cope with nonstandard protocols. PF can cope with almost anything you throw at it. If some client wants a host behind your firewall to speak IP protocol number 184 to their development server, PF will let you do that. Many commercial firewalls won't let you pass such traffic or claim that they will but throw a tantrum if you actually try to do it.

Basic Packet Filtering Concepts

In Chapter 8, we mentioned that TCP connections can be in a variety of states. (If you don't remember that, go back and reread that chapter.) A TCP connection that is just opening goes through a three-way handshake process. A client first requests a connection by sending a special "connection synchronization request" or SYN packet to the server. The server responds by sending the client a "synchronization acknowledgment" or SYN+ACK packet, which contains some basic information about how to connect this particular TCP session. Finally the client responds with an "acknowledgment" or ACK packet, which tells the server that the client understands and accepts the connection requirements. Every part of this three-way handshake must be completed for any actual data to be transferred between the two machines. Your packet filtering rules must permit each part of the three-way handshake and the data transmission itself to complete. Allowing your server to receive incoming messages is useless if your packet filter rules do not permit it to send back an acknowledgment.

In the early 1990s, packet filters compared each packet to a list of static rules. If a packet matched a rule, it was allowed to pass. The system did not record what came before and had no idea if a packet was part of a legitimate transaction or not. For example, if a packet arrived marked SYN+ACK and addressed to a machine in the middle of the network, the packet filter would let it pass. Such packets had to pass for internal systems to successfully establish outbound TCP connections. Because the packet filter didn't know who had sent a SYN packet, it couldn't reject such illegitimate packets. As a result, intruders could forge SYN+ACK packets and use them to circumvent seemingly secure devices. Once intruders got packets into the network they could usually trigger a response from some device and then start to worm their way in. This is just one example of a whole host of problems caused by such simple packet filtering. PF can do this sort of packet filtering, but you really don't want to bother with it.

Stateful inspection counteracts this problem. Packet filters that use state inspection maintain a table of every connection running through the firewall. When a client sends out a SYN packet, it records that packet in a table and waits for a corresponding SYN+ACK packet. If a SYN+ACK packet arrives at the packet filter, but no matching SYN packet was sent requesting such a response, the SYN+ACK packet is rejected. This also had the pleasant result of simplifying packet-filtering rulesets considerably. PF performs excellent stateful packet inspection, and it's much easier to manage, so we're going to spend most of our time focusing on that.

UDP is technically stateless, but some applications expect a certain amount of state. When your system transmits a UDP packet, the application might well expect a UDP packet or ten to flow back in response, or no packets, depending on the application. DNS queries are a popular example of UDP packets flowing back and forth; while UDP has no state, DNS certainly does. ICMP behaves similarly. You can tell PF to expect and accept ICMP replies, or to disallow them, as you choose. While UDP and ICMP have no state, telling PF to certain types of replies with these protocols is also called stateful inspection.

Packets can be mangled during transit, usually by fragmentation. Part of a packet filter's job is to reassemble those packets in a sensible manner. PF can reassemble and rationalize packets in a variety of ways, depending upon your needs, by using the scrub function.

One of the essential concepts in packet filtering is the question of default accept versus default deny. A default accept stance means that you allow any type of connection except for what you specifically disallow. A default deny stance means that you only allow connections from specific parts of the Internet; all other connection attempts are refused. Once you have chosen your default, you can adjust your rules to hide or reveal network services as you desire. This choice is really between whether you are offering services to the world or only to a select few. If your system is a corporate web server, you might want to make it only visible to the company network. If so, you've adopted a default deny security stance. This is especially appropriate when building firewalls to protect a company network — users should not be able to run web servers on their desktops! On the other hand, if you have a sitting out on the Internet, and only want to block a few certain services from a select handful of locations, you're using a default accept stance.

In addition to packet filtering and packet reassembly, PF has several other important features: network address translation, connection redirection, bandwidth management, and authentication. We will consider each separately, although they are all configured in /etc/pf.conf and managed with pfctl(8).




Absolute Openbsd(c) Unix for the Practical Paranoid
Absolute OpenBSD: Unix for the Practical Paranoid
ISBN: 1886411999
EAN: 2147483647
Year: 2005
Pages: 298

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net