Packet Filtering

Packet Filtering
Overview
Packet filters were the original firewalls. The first attempts to make TCP/IP secure were based on
the idea that it's pretty easy for a router to inspect the header of TCP/IP packets and simply drop
packets that don't conform to the specifications you want to accept.
Packet filters have problems that make them insufficient to provide total security for an internal
network. They are now combined with proxy servers and Network Address Translators to solve
those problems.
Proxy servers were originally designed to make the World Wide Web faster. Network Address
Translators were originally designed to increase the address space available to private
organizations and to solve IP address numbering problems associated with attaching existing
private TCP/IP networks to the Internet. The serendipitous security benefits of both of these
functions were integrated with packet filtering and encryption technology to create the modern
effective firewalls in use today.
Neither proxy servers nor Network Address Translators can be properly secured without a packet
filter, and a packet filter cannot provide total security without the services of a proxy server or a
Network Address Translator. Because these services must be combined into a single coherent
security function to be effective, you should use firewalls that make effective use of all three
methods to truly secure your network.
There are two primary types of packet filtering:
• Original, or "stateless" packet filtering, often used by routers and operating systems.
• Stateful inspection packet filtering, used in all modern firewalls.
This chapter discusses "pure" packet filtering: packet filtering not combined with proxy or Network
Address Translation functions. Pure packet filters are still in use all over the place, so this
discussion remains very current.
How Stateless Packet Filters Work
Packet filters are border routers that increase security by determining whether or not to forward a
packet based on information contained in the header of every individual packet. Filters can
theoretically be configured to determine this based on any part of the protocol header, but most
filters can be configured only to filter on the most useful data fields:
• Protocol type

• IP address
• TCP/UDP port
• Fragment number
• Source routing information
The following sections detail each of these fields.
117
Protocol Filtering
Protocol filtering filters packets based on the content of the IP protocol field. The protocol field can
be used to discriminate against entire suites of services, such as:
• UDP
• TCP
• ICMP
• IGMP
For example, if you have a single purpose server serving a TCP based service like HTTP, you− −
could filter out all UDP services. Unfortunately, the protocol field is so general (only four common
protocols are available to filter on) that most servers and routers will have to leave all of them open.
IP Address Filtering
IP address filtering allows you to limit connections to (or from) specific hosts and networks based on
their IP address. Most filters allow you to either deny access to all hosts except an accepted list or
allow access to all hosts except a denied list.
Specific denial of certain hosts is almost worthless, since you'd have to keep track of every hacker
that had ever attacked your network and assume that they have no way to gain information from a
different IP address, which they always will. Relying on specific denial is not a strong security policy.
Specific acceptance of certain host addresses provides particularly strong security, however; it is
the strongest form of security that a stateless packet filter can provide. By denying access to all
hosts except a list of known IP addresses, you can ensure that your routers can only be reached by
the IP addresses of machines or networks you know about. This list could be other networks in your
organization, the networks of your customers, or the networks of work at home users. By denying− −
access to all other IP addresses, you make it nearly impossible for a hacker to exploit your network.
To hack into your network, a hacker would have to have access to your list of allowed IP addresses.

It is possible for hackers to use source routing, (explained in detail in the next section), to "spoof" IP
addresses. Source routing would allow a hacker to put an allowed address into a packet and then
capture the return by specifying that responses be routed back to his computer. For this reason,
packet filters should always be configured to drop sourcerouted packets.
Good packet filters will allow you to specify hosts on a per protocol basis, so (for example) you−
could allow all hosts to access TCP port 80 for HTTP service but only hosts from your company
network to access TCP port 23 (Telnet). Most simple filters don't have allowed lists per protocol, so
you can only assign a single list of hosts allowed for all protocols.
It's important to remember that a filter can only limit addresses based on the IP address field's
contents, which could be different than the actual source host. It's easy for hackers to forge the IP
address field of a packet, so it's certainly possible for them to get a packet past a packet filter if they
know an address that the filter will pass. This would be useful in instances where a round trip is not−
necessary, such as in a denial of service attack or where the return address for the protocol is− −
contained in the payload of the packet as well as the header (as in FTP).
118
TCP/UDP Ports
TCP or UDP port information is the most commonly used information to filter on because this data
field indicates most specifically what the packet is for. Port filtering is also commonly referred to as
protocol filtering because the TCP or UDP port number identifies higher level protocols. Figure 6.1−
shows how a stateless packet filter discriminates based on TCP or UDP port number.
Figure 6.1: A packet filter rejects undesired traffic.
Common protocols that can be filtered based on the TCP or UDP port field are:
•
Daytime DNS NetBIOS Session
Echo HTTP IMAP
Quote Gopher NFS
FTP POP Whois
Telnet SNMP RSH
SMTP NNTP
As with IP addresses, most packet filters allow you to either pass all protocols except a denied list

or pass no protocols except an allowed list, and as with IP addresses, passing no protocols except
an allowed list is more secure. Unlike IP address filtering, blocking only certain ports is still useful
because most hacking exploits target only a few specific protocols. The most important protocols to
block are listed here:
• Telnet Leaving this port open on a host will allow hackers to open a command prompt with a
large amount of access to your machine.
• NetBIOS session Leaving this port open to the Internet on Windows or SMB serving hosts
will allow hackers to attach to your file servers as if they were local clients.
• POP You should implement a VPN connection for remote clients who need to check their
mail because POP uses plaintext passwords to allow access, which will allow hackers to
sniff user's passwords off the network.
• NFS Unix clients should not leave open access to NFS ports for the same reason Windows
clients should not leave open access to the NetBIOS ports.
119
• X Windows Running X client software (the terms "client" and "server" in X environments
have the opposite of their usual meanings) will leave your server vulnerable to attack.
• Windows Terminal Services Exposing Windows Terminal Services to the Internet means
your terminal server is protected by just a username and password. There are numerous
ways to extract that information from clients on your network.
These ports are especially sensitive to attack because of the high level of functional control they
give the attacker. Other ports, like DNS, could be used to damage some specific information, but
the service itself is not rich enough to control the machine directly and are therefore of less value to
attackers (of course, all listening services are potentially vulnerable to buffer overrun and related
exploits).
Other ports you should block include any sort of remote access or remote control software such as
pcAnywhere or VNC.
Filtering on Other Information
In addition to the standard fields, headers contain other information that can be used to determine
whether or not a packet should be passed.
Source routing and fragmentation are two techniques supported by the IP protocol that are largely

obsolete and frequently exploited by hackers. Most packet filters will allow you to simply drop any
packets that are source routed or fragmented.
Source Routing
Source routing is the process of defining the exact route a packet must take between hosts in an IP
connection. Source routing was originally used for debugging and testing purposes, but it is now
frequently used by hackers who can put any address in the source field and still ensure the packet
will return by specifying her own machine in the source route.
Two types of source routing exist:
• Loose source routing, which indicates one or more hosts the packet must flow through, but
not a complete list.
• Strict source routing, which indicates the exact route a packet must follow between hosts.
Of the two types, loose source routing is most often used by hackers because the he can simply
plug in the IP address of his machine to make sure the packet comes back to him by any means.
Unless you use source routing in your network, configure your filters to drop any source routed−
packets. No protocol or ISP requires source routing.
Fragmentation
Fragmentation was developed to support the passage of large IP packets through routers that could
not forward them due to the frame size constraints encountered in some early networks.
Fragmentation gave any router in the path between two hosts the ability to chop up an inbound IP
packet into multiple smaller packets and then forward them on size constrained networks. The−
receiving system simply waited for all fragments of the packet to reassemble it to its original form.
The problem with fragmentation comes from the fact that the most useful filter data, the TCP or
120
UDP port number, is only provided in the beginning of an IP packet, so it will only be contained in
fragment 0. Fragments 1 and higher cannot be filtered based on port information because they don't
contain any port information. So most early filters simply forward all subsequent fragments with the
assumption that if the 0th fragment had been dropped, the subsequent fragments would be
worthless.
But that's not always the case. Many flawed versions of TCP/IP running on internal hosts might
reassemble the packet anyway, and if the 1 through n packets contained a valid TCP packet, they'd

go ahead and use it. This meant that a hacker could modify his IP stack to start all fragment
numbers at 1 and effectively bypass the filter altogether.
Problems with Stateless Packet Filters
Packet filters suffer from two problems that prevent them from being completely effective:
• They cannot check the payload of packets.
• They do not retain the state of connections.
These problems make packet filters alone insufficient to secure your network.
No Service−Specific Security
Packet filters make pass/drop decisions based solely on header information; they do not inspect
content for the presence of dangerous or malformed data to determine whether or not that data
should be passed. For this reason, packet filters alone do not constitute effective security.
For example, HTTP content flowing back into your network could contain Trojan horses embedded
in ActiveX controls. Your packet filter cannot determine this, so it simply passes the content through.
Or you may allow SMTP port 25 through to your mail server to receive e mail, but the filter can't−
determine that a malformed e mail passing through it will crash your e mail server.− −
Service specific security can only be implemented by the service specific filters used by proxy− −
servers and true firewalls.
No Connection State Security
Most packet filters are stateless—that is, they do not retain information about connections in
use—they simply make pass/drop determinations packet by packet and based only on the
information contained within that packet. Stateless packet filters cannot determine whether or not to
drop fragments because they retain no information about the fragment's service port. Stateless
packet filters also cannot determine when a return socket connection applies to a connection
established from inside the network, so they must be configured to simply pass all TCP ports in the
range of a normal return socket. For this reason, many early packet filters simply pass all TCP ports
above 1024.
Modern port filters and all modern firewalls use state information to keep track of connection status
and thereby more positively control the routing of packets through your network.
If you can't use proxy servers to eliminate routing at your border, use state based packet filtering−
and Network Address Translation.

121