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 OS Packet Filtering Most modern operating systems, Unix and Windows included, include packet filtering as part of the TCP/IP stack. This means that you can configure unique packet filtering rules for each server based on its individual function. This is called end system packet filtering because the final computer in− the route, the host to which the packet is actually addressed, performs the filtration. Intermediate systems like packet filtering routers and firewalls can be configured to drop or pass packets based on the ultimate address, so end system packet filtering may seem unnecessary. But− no border system can protect your server from an internal attack or from an attack that somehow sidesteps your border security by exploiting an improperly secured VPN or dial up connection.− By including backup packet filtering directly on servers, you can provide an extra level of security that will still be in place if your border security fails or if the attack comes from inside your network. You should use the packet filtering functionality of your server's operating systems to guarantee that you are only serving those protocols you intend to serve publicly. Hostbased packet filtering allows you to ensure that each server exposes only those services you intend. How Stateful Inspection Packet Filters Work Standard packet filters have a number of flaws, all of which stem from the fact that a single packet in a communication does not contain enough information to determine whether or not it should be dropped, because it is part of a larger communication. Stateful inspection packet filters solve this problem by retaining the state of all the communication flowing through the firewall in memory, and using that remembered state to determine whether or not individual packets should be dropped. Stateful inspectors filter entire communication streams, not just packets. Stateful packet filters remember the state of connections at the network and session layers by recording the session establishment information that passes through the filter gateway. The filters then use that information to discriminate valid return packets from invalid connection attempts or hacking. Most stateless packet filters simply allow all ports above 1024 to pass through the firewall because those ports are used for the return sockets of connections initiated inside the firewall. This is extremely poor security—nothing prevents Trojan horses from waiting inside your network on a service port above 1024, so stateless packet filters cannot prevent this sort of intrusion. Stateful packet filters, on the other hand, do not allow any services through the firewall except those services they're programmed to allow and connections that they already maintain in their state tables. When a trusted internal host connects to a TCP socket on an external untrusted host, it transmits with the connection synchronization packet the socket (IP address and port) on which it expects to receive a response. When that SYN packet is routed through the stateful inspection filter, the filter makes an entry in its state table containing the destination socket and the response socket, and then forwards the packet onto the untrusted network. When the response comes back, the filter can simply look up the packet's source and destination sockets in its state table, see that they match an expected response, and pass the packet. If no table entry exists, the packet is dropped because it 122 was not requested from inside the network. Figure 6.2 shows the establishment phase of a stateful filter. Figure 6.2: A stateful inspection packet filter allows return data. The filter removes state table entries when the TCP close session negotiation packets are routed through, or after some period of delay, usually a few minutes. This ensures that dropped connections don't leave state table "holes" open. Figure 6.3 shows a filter removing the table entry that allows return data from a connection. 123 Figure 6.3: A stateful inspection filter leaves "holes" open only as long as they're necessary. Stateful filters are then programmed with rules (usually called policies) that modify that basic behavior. Policies usually include rules for packets that are always dropped, packets that are never dropped, services that are allowed to pass from the outside to specific hosts inside, and so forth. On multi function firewalls, the policies also control network address translation and proxying, and− usually abstract IP addresses, networks, and ports into objects, areas, and services so that rather than blocking port 80 from network 192.168.12.0, you're blocking "web service" from "accounting." Because stateful filters can filter on all the same information that stateless filters can, and can additionally filter fragments, which side of the firewall a connection is initiated from, and other more complex information, stateful filters are considerably more secure. Stateless packet filters still don't solve the problem of internal protocol analysis for higher level− protocols like HTTP and FTP, but higher end firewalls like Firewall 1 do provide a "proxy like"− − higher layer filtration service for common protocols like HTTP, FTP, and SMTP. While far more− secure than not having higher level inspection at all, the packets are still not regenerated the way they are on a proxy server, so there's still a chance that malformed original data could pass through the filter to a target inside your network. Hacking through Packet Filters Hackers use a number of well known methods to bypass packet filters and get inside your network.− They exploit the following security problems with packet filters: 124 • TCP can only be filtered in the 0th fragments. • Older packet filters pass all ports above 1024. • Public Services must be forwarded through the filter. • Trojan horses can defeat packet filters using NAT. These hacks are detailed in the following sections. TCP Can Only Be Filtered in 0th Fragments Stateless packet filters inspect each packet on its own merits without retaining information about previous packets. For this reason, when a fragmented packet comes through, the TCP header will only be available in the 0th fragment, which means that although the packet filter will drop the 0th fragment, it won't drop fragments past 0. Because many operating system TCP/IP stacks don't actually pay attention to fragment ordering, these operating systems will reassemble a fragmented packet until they get a packet with the final fragment flag set. If the data in their IP buffer constitutes a valid packet, they'll pass it along to the operating system. Hackers exploit this to pass data right through a packet filter to a specific host inside your network. By transmitting all packets with the fragment number set to 1, but containing the entire TCP packet, the filter will ignore the TCP payload allowing it to pass to the internal network. The addressed end system sees that the final fragment message is set and passes the TCP packet along to the operating system. In this way, hackers can connect directly to hosts inside your network as if the packet filter didn't even exist. The two solutions to this problem are to use only hardened TCP/IP stacks on your internal hosts and to use state based packet filters like true firewalls. Windows NT 4 Service Pack 3 hardens the− TCP/IP stack against this vulnerability, but earlier editions of NT are vulnerable. Many Unix implementations are hardened against this attack, but many are not—even some firewalls are vulnerable to this attack. Search the Web for your specific version and variation to determine if this exploit will work against your operating system. Low Pass Blocking Filters Don't Catch High Port Connections Stateless packet filters and the packet filtering services provided by ISPs usually open ports above 1024 so that the return socket of a connection can be established back to a host. This means that any protocol running with a TCP port higher than 1024 cannot be protected by these packet filters. Make sure your packet filter is state based and blocks all inbound connection attempts except− those you want to allow and those connections that were initiated from inside your network. Public Services Must Be Forwarded These days, hackers don't usually bother with TCP level exploits because they know you've got to open your web and e mail servers up to the public anyway. They just use protocol exploits to− exploit these servers, and then try to initiate connections to the interior of your network from those servers. If you've set up additional rules in your firewall to allow connections to and from your web server, for example to publish changes to the website, then hackers can then use that access to gain access to the interior of the network. 125 Internal NATs Can Defeat Filtering If a user inside your network sets up a Network Address Translator on a machine (a Linux computer, for example), then that machine can be used to perform port and address translation to change a protocol inbound on a high, unfiltered port (say 8080) back down to a protocol on a filtered port (80) and then pass it to an internal server. Internal proxy servers could also be used to cause this vulnerability. This would allow uncontrolled access to your internal services. Trojan horses perform exactly this sort of protocol translation for the purpose of allowing hackers to access your internal network directly. Unsuspecting users might get e mail from your e mail− − address with instructions to click the setup file of the attached program, which would then install the Trojan horse. Hackers could then exploit the network address translator in the Trojan horse to bypass your filter. Best Packet Filtering Practices Pure packet filters are subject to a few glaring security problems. Use these recommendations to keep your packet filtering secure: • Use at least a stateful filter if you can't use a proxy. • Disable all ports by default. • Secure the base operating system. These practices are detailed in the following sections. Use a Real Firewall First and foremost, use a strong firewall. Examine the firewall comparisons that constitute the second half of this book for firewalls that perform correct state based packet filtering in combination− with service specific, proxy based filtering and Network Address Translation.− − Do not rely upon simple packet filters or the packet filtering functionality of your operating system to keep your network secure. Pure packet filters cannot adequately secure a network. Disable All Ports By Default Do not pass all protocols by default and then block those you consider dangerous. Although this is convenient, it opens you up for attack by Trojan horses and unintended user mode services like pcAnywhere. Block all ports by default, and pass only the ports you intend to serve and the return channels from connections initiated from inside your network. Secure the Base OS Make sure the base operating system is secure. As with all security software, the security of a packet filter is based on the security of the device upon which it's run. Most packet filter appliances (routers) can be configured via Telnet. This means that a hacker could telnet into your packet filter and reconfigure it to allow more useful ports to be opened. 126 [...]...Case Study: Leaky Filters When a customer of mine attached their network to the Internet in 1994, we put a "firewall" in place on the routed connection In those days, a firewall was a router with a packet filter We used Telnet to block all inbound ports below 1024 except ports 80 (they ran a web server on a SPARC machine), 21 (FTP), and 25 (SMTP) We felt perfectly secure Then a scientist downloaded... explain how the firewall had failed It hadn't, I explained; it just wasn't designed to prevent that sort of intrusion because this specific firewall could only block ports below 1024, like many early packet filters The budget for security went up considerably, and we used it to install a Firewall−1−based stateful inspection gateway We also bought portscanning tools to search for other instances of . of packet filtering: • Original, or "stateless" packet filtering, often used by routers and operating systems. • Stateful inspection packet filtering, . discusses "pure" packet filtering: packet filtering not combined with proxy or Network Address Translation functions. Pure packet filters are still