It Should Apply Rules Separately to Incoming and Outgoing Packets, on a Per-Interface Basis

For maximum flexibility, capability, and performance, you want to be able to specify a separate rule set for incoming and outgoing packets on each interface. In this section, we'll show an example that demonstrates the problems you can run into with routers that aren't that flexible.

A limitation unfortunately shared by many packet filtering systems is that they let you examine packets only as they are leaving the system. This limitation leads to three problems:

•

The system is always "outside" its own filters.

•

Detecting forged packets is difficult or impossible.

•

Configuring such systems is extremely difficult if they have more than two interfaces.

Let's look at the first problem. If a router lets you look only at outgoing packets, then packets directed to the router itself are never subjected to packet filtering. The result is that the filtering doesn't protect the router itself. This is usually not too serious a problem because there are typically few services on the router that could be attacked, and there are other ways to protect those services. Telnet is an example of a service that can be attacked in this way, but you can usually get around the routing problem by disabling the Telnet server, or by controlling from where it will accept incoming connections. SNMP is another commonly available and vulnerable service.

Now consider the second problem. If a router can filter only outgoing packets, it's difficult or impossible to detect forged packets being injected from the outside (that is, packets coming in from the outside but that claim to have internal source addresses), as is illustrated in Figure 8.1. Forgery detection is most easily done when the packet enters the router, on the inbound interface. Detecting forgeries on the outbound interface is complicated by packets generated by the router itself (which will have internal source addresses if the router itself has an internal address) and by legitimate internal packets mistakenly directed to the router (packets that should have been sent directly from their internal source to their internal destinations but were instead sent to the filtering router, for instance, by systems following a default route that leads to the filtering router).

The third problem with outbound-only filtering is that it can be difficult to configure packet filtering on such a router when it has more than two interfaces. If it has only two interfaces, then being able to do only outbound filtering on each interface is no big deal. There are only two paths through the router (from the first interface to the second, and vice versa). Packets going one way can be filtered as outgoing packets on one interface, while packets going the other way can be filtered as outgoing packets on the other interface. Consider, on the other hand, a router with four interfaces: one for the site's Internet connection, one for a finance network, and two for engineering networks. In such an environment, it wouldn't be unreasonable to impose the following policy:

•

The two engineering networks can communicate with each other without restrictions.

•

The two engineering networks and the Internet can communicate with each other with certain restrictions.

•

The two engineering networks and the finance network can communicate with each other with certain restrictions - restrictions that are different from those between the engineering nets and the Internet.

Figure 8.4 illustrates this environment.

Figure 8.4. Packet filtering restrictions on different interfaces

There are 12 paths through this router, from each of four interfaces to each of three other interfaces (in general, there are N * (N-1) paths through an N-interface router). With an outbound-only filtering system, you would have to establish the following filtering on each interface:

Engineering Net A

Internet filters, finance net filters, engineering net B filters

Engineering Net B

Internet filters, finance net filters, engineering net A filters

Finance Net

Internet filters, engineering net A filters, engineering net B filters

Internet

Engineering net A filters, engineering net B filters, finance net filters

Merging multiple filtering requirements in a single interface like this can be very tricky. Depending on the complexity of the filters and the flexibility of the filtering system, it may actually be impossible in some situations.

A more subtle problem with such a setup is that it imposes packet filtering overhead between the two

engineering networks (which may result in a significant performance problem). With this setup, the router has to examine all the packets flowing between the two engineering nets, even though it will never decide to drop any of those packets.

Now look at the same scenario, assuming that the packet filtering system has both inbound and outbound filters. In this case, you could put:

•

All the filters related to the Internet (regardless of whether they apply to the engineering nets or the finance net) on the Internet interface

•

All the filters related to the finance net (regardless of whether they apply to the engineering nets or the Internet) on the finance interface

What if a packet filtering system had inbound-only filters, rather than outbound-only filters? A system of this kind would address the first and second problems we described in this section: a router with inbound-only filters can

be protected by its own filters and can detect forged packets. However, such a system would not address the third and most serious problem; you still have problems merging filtering rules on routers with more than two interfaces.

What if the packet filtering system had both kinds of filters but didn't allow you to specify individual interfaces? This kind of system has all the problems of an outbound-only system (you have to merge all of the rules into a single set and incur packet filtering overhead even on unfiltered connections). In addition, it becomes very difficult to detect forged source addresses. Most such systems have special configurations to deal with forged source addresses, but these are less flexible than the controls you can get by directly specifying rules. In particular, they may protect you from external forgeries without detecting internal forgeries.

In document Building Internet Firewalls, 2nd Ed pdf (Page 136-138)