The Geeks Corner

8.9.2 ipfilter
ipfilter is another packet filtering system for Unix. It works on the free BSD implementations (FreeBSD, OpenBSD, and NetBSD) and has also been ported to and tested on other Unix operating systems including Solaris and previous versions of SunOS, IRIX, and Linux.
ipfilter uses a list of rules contained in a single configuration file. Unlike ipchains, ipfilter checks all rules in sequence, and the last rule that successfully matches determines the fate of a packet. This can be a great source of confusion. Imagine a filtering configuration file containing only the following rules:
block in all pass in all
This will pass all packets because the second rule is the last rule that matches. Fortunately an ipfilter rule can specify the “quick” keyword, which if the rule matches, will terminate the rule checking at that point. The following rules would block all traffic:
block in quick all pass in all
Rules may be arranged into groups, which allows you to make more complicated configurations quite easily. A group has a head rule, which is checked to determine whether the rest of the rules in the group are executed. If the group is executed, the rules in it are handled in the normal way. At the end of the group, processing continues at the next line.
The conditions in a rule can be based on any of the following:
• The IP protocol number (for example TCP, UDP, ICMP, or IGMP). • The IP options that are set. • The source and destination IP addresses. Addresses can be specified as a variable-length subnet (for example 192.168.8.0/22) or a network address with a mask, and negation is allowed (you can specify “all addresses except those that match this address and mask”). • The source and destination TCP and UDP port numbers. Port numbers can be specified with ranges or masks, and negation is allowed. • The ICMP type and code. • Whether the packet is an IP fragment. Fragments that are too short to contain port numbers, and thus could prevent port rules from being applied, can be explicitly handled. • The TCP flags that are set (for instance, the ACK and SYN bits that let you identify a start of connection packet). • The network interface the packet came in on.
Building Internet Firewalls
page 137
The actions ipfilter can take are:
• Drop the packet without generating a response. • Don’t process the packet, but return an ICMP response (you can specify what ICMP response to return). • Don’t process the packet, but return a TCP reset. • Process the packet. • Process the packet, keeping state information to make sure that all TCP packets are part of a valid TCP conversation, with appropriate settings of SYN and ACK and appropriate sequence numbers. • Change IP address and/or port number information in the packet using a static mapping (this is a simple form of network address translation). • Send the packet or a copy of it to a specified network interface or address for logging purposes. • Log information about the packet via syslog.
ipfilter also has the ability to do some more complicated packet rewriting to support protocols that cannot be handled by straightforward network address translation. However, there are relatively few supported protocols. The rewriting system in ipfilter is not dynamically extensible; rewriting capabilities are set at compile time and cannot be added on the fly.
8.9.3 Comparing ipfilter and ipchains
ipfilter and ipchains provide roughly the same functionality; in many cases, people choose between them based on the operating system they’re using, using ipchains on Linux and ipfilter on other operating systems. On the other hand, they do have distinct strengths and weaknesses.
ipchains is much stronger as a network address translation system. The network address translation functionality provided by ipfilter is minimal and is not dynamically updatable. ipchains is also provided as part of Linux, so that it doesn’t require separate integration.
ipfilter provides filtering capabilities that ipchains does not (allowing you to filter on IP options and providing more flexible handling of TCP options, for instance), and it is more flexible about the responses it gives to blocked packets. Its packet duplication features are useful for feeding packets to intrusion detection systems.
The architecture of ipchains makes it much easier to extend than ipfilter, so it’s likely that the extra ipfilter features will eventually show up in ipchains. However, ipchains is relatively tightly integrated with the Linux kernel, which will slow down its spread to other operating systems.
8.9.4 Linux netfilter
At this writing, the Linux packet filtering and network address translation systems are being rewritten. The new filtering system is called netfilter, and it has several goals. One is to reduce the number of points in the Linux kernel where filtering occurs. Another is to have a clean separation of filtering from network address translation. As a result of this separation, netfilter is no longer capable of modifying packets. Some of the concepts from ipchains still exist in netfilter; in particular, lists of filtering rules are built into named chains. The significant features that have been added to netfilter are:
• The ability to filter on both the input and output interface in the forward chain • The ability to pass packets to user-level processes for handling
If you are using ipchains only for packet filtering, you can use netfilter with the same filtering rules. However, if you use the masquerading chain, you will need to convert to using the new network address translation tools in order to use netfilter.
Building Internet Firewalls
page 138
8.9.5 Windows NT Packet Filtering
Windows NT 4 comes with a very limited ability to do packet filtering, suitable only for protecting the machine itself, and that only in some circumstances. From the Network control panel, when you are configuring TCP/IP properties, you can go to the IP address tab and select Advanced. You have two different ways of doing filtering:
• The Enable PPTP Filtering button will restrict the interface to only using PPTP.19 • The Configure button under Enable Security will let you configure filtering by TCP port, UDP port, or IP protocol.
Windows 2000 provides the latter filtering also, as part of the Advanced TCP/IP Settings; it is under the Options tab and is called TCP/IP filtering. You may specify that you wish to allow everything, or you may provide a list of what you will allow, by individual port number (that is, if you wish to allow ports above 1023, you will have to enter each number from 1024 to 65536 separately).
This packet filtering is extremely minimal, and there are very few situations where it’s possible to use it. It is useful for machines that are using PPTP, or that are bastion hosts providing single services like HTTP. Some of the problems with it are not immediately obvious and are frequently unpleasant surprises to people trying to use this packet filtering:
• It controls only incoming packets without ACK set; it will not limit outbound connections. • The “IP protocol” entries do not control UDP and TCP; if you wish to deny UDP and TCP, you must set the TCP and UDP entries to allow only specified ports and then avoid specifying any ports. • It will not deny ICMP, even if you set the IP protocol to allow only specified ports and avoid including ICMP.
If you install the Routing and Remote Access Service for Windows NT 4 or Windows 2000, which is a no-cost option, you get much more flexible packet filtering, allowing both inbound and outbound filters by protocol, source and destination address, and source and destination port. This filtering still doesn’t compete with full- fledged packet filtering implementations; it doesn’t allow specifications of port ranges, it doesn’t give you any control over what’s done with denied packets, and it doesn’t allow you to combine allow and deny rules.
Windows 2000 provides packet filtering in a third place as part of its implementation of IPsec (IPsec is discussed further in Chapter 14). This packet filtering is comparable to the Routing and Remote Access Service filtering for Windows NT 4, except that it is possible to combine filters into sets (allowing you to mix allow and deny rules), and a rule can apply four possible actions:
• Permit all packets that match, regardless of their IPsec status. • Block all packets that match, regardless of their IPsec status. • Request IPsec protections on all packets that match, but accept them if IPsec is not available. • Require IPsec protections on all packets that match, and reject them if IPsec is not available.
If you are using packet filtering as part of IPsec, we strongly recommend that you avoid configuring any of the other possible sorts of packet filtering. Use only one packet filtering package at a time; otherwise, you risk configuring conflicting filtering rules. Whether or not the computer gets confused, its maintainers certainly will.
Ironically, the most powerful packet filtering package that Microsoft makes available for Windows NT is actually part of Microsoft’s Proxy Server. While it still does not provide all of the features that a packet filtering router would provide, it does include alerting and logging options, specification of port ranges, and filtering of fragments. As of this writing, a new version of Proxy Server is due out shortly, and it is expected to have still more packet filtering features.
19 See Section 14.1, for more information about PPTP.
Building Internet Firewalls
page 139
8.10 Where to Do Packet Filtering
If you look at the various firewall architectures outlined in Chapter 6, you see that you might perform packet filtering in a variety of places. Where should you do it? The answer is simple: anywhere you can.
Many of the architectures (e.g., the screened host architecture or the single-router screened subnet architecture) involve only one router. In those cases, that one router is the only place where you could do packet filtering, so there’s not much of a decision to be made.
However, other architectures, such as the two-router screened subnet architecture, and some of the architectural variations, involve multiple routers. You might do packet filtering on any or all of these routers.
Our recommendation is to do whatever packet filtering you can wherever you can. This is an application of the principle of least privilege (described in Chapter 3). For each router that is part of your firewall, figure out what types of packets should legitimately be flowing through it, and set up filters to allow only those packets and no more. You may also want to put packet filters on destination hosts, using a host-based packet filtering system like the ones discussed previously, or using special-purpose software designed for filtering on destination hosts.This is highly advisable for bastion hosts, and destination host filtering packages are discussed further in the chapters about bastion hosts (Chapter 10, Chapter 11, Chapter 12).
This may lead to duplication of some filters on multiple routers; in other words, you may filter out the same thing in more than one place. That’s good; it’s redundancy, and it may save you some day if you ever have a problem with one of your routers – for example, if something was supposed to be done but wasn’t (because of improper configuration, bugs, enemy action, or whatever). It provides defense in depth and gives you the opportunity to fail safely – other strategies we outlined in Chapter 3.
If filtering is such a good idea, why not filter on all routers, not just those that are part of the firewall? Basically, because of performance and maintenance issues. Earlier in this chapter, we discussed what “fast enough” means for a packet filtering system on the perimeter of your network. However, what’s fast enough at the edge of your network (where the real bottleneck is probably the speed of the line connecting you to the Internet) is probably not fast enough within your network (where you’ve probably got many busy local area networks of Ethernet, FDDI, or perhaps something even faster). Further, if you put filters on all your routers, you’re going to have to maintain all those filter lists. Maintaining filter lists is a manageable problem if you’re talking about one or a handful of routers that are part of a firewall, but it gets out of hand in a hurry as the number of routers increases. This problem is worsened if some of the routers are purely internal.
Why? Because you probably want to allow more services within your network than you allow between your network and the Internet. This is going to either make your filter sets longer (and thus harder to maintain), or make you switch from a “default deny” stance to a “default permit” stance on those internal filters (which is going to seriously undermine the security they provide anyway). You reach a point of diminishing returns fairly quickly when you try to apply filtering widely within a local area network, rather than just at its perimeter.
You may still have internal packet filtering routers at boundaries within the local area network (between networks with different security policies, or networks that belong to different organizations). As long as they’re at clearly defined boundaries, and they’re up to the performance requirements, that’s not a problem. Whether or not you duplicate the external rules on these internal packet filters is going to depend on how much you trust the external packet filters, and how much complexity and overhead the external rules are going to add.
In some cases, you may also be able to run packet filtering packages on bastion hosts. If this is not a performance problem, it can provide additional security in the event that a packet filtering router is compromised or misconfigured.
Some people argue against putting packet filters on routers when you also have a firewall inside the router, on the grounds that allowing packets to reach the firewall system gives you a single logging point, making it easier to detect attacks. If an attack involves some packets that are filtered out at the router, and others that are rejected at an internal firewall, the internal firewall may not be successful at detecting the attack. This is not a convincing argument; the internal firewall will still be successful at detecting any attack that has any chance of succeeding against it, and any reasonable logging configuration will let you correlate the logs from the packet filters with the logs from the internal firewall and do intrusion detection on the union of them in any case. The increased detection benefit from allowing the packets is more than outweighed by the decrease in security.20
20 We have also heard the argument that “the firewall is more secure than the packet filter, so you should use it instead.” This is relevant only if you can’t use both at the same time. Clearly, the firewall is not more secure than the combination of the firewall and the packet filter!
Building Internet Firewalls
page 140
8.11 What Rules Should You Use?
Clearly, most of the rules that you will put into your packet filtering system will be determined by the kinds of traffic you want to accept. There are certain rules you will almost always want to use, however.
We’ve already discussed these rules in various places, but here’s a summary list of some standard protections that you should automatically apply unless you have a strong reason to do otherwise:
• Set up an explicit default deny (with logging) so that you are sure that the default behavior is to reject packets. • Deny inbound traffic that appears to come from internal addresses (this is an indication of forged traffic or bad network configurations). • Deny outbound traffic that does not appear to come from internal addresses (again, such traffic is either forged or symptomatic of network misconfigurations). • Deny all traffic with invalid source addresses (including broadcast and multicast source addresses; see Chapter 4, for more information about broadcast, multicast, and source addresses). • Deny all traffic with source routes or IP options set. • Deny ICMP traffic over a reasonable size (a few kilobytes). ICMP filtering rules are discussed further in Chapter 22. • Reassemble fragments into entire packets.

---

Published @ September 29, 2021 2:01 pm