Filtering dos and don’ts

Filters can permit or deny virtually any kind of traffic – up to a point. Here are some basic dos and don’ts for filter usage.

Filters can permit or deny virtually any kind of traffic – up to a point. Here are some basic dos and don’ts for filter usage:

•  Do prevent address spoofing at the edge of a company’s network. At minimum, routers at the edge of a company should block inbound traffic with source IP addresses claiming to be from internal networks. Similarly, the source IP address of any outbound packet should only be from an internal network.

•  Do prevent bogus routes. Some IP addresses should never be seen on the Internet. These include not only the private addresses specified in RFC 1918 but also those networks designated as reserved by the Internet Assigned Numbers Authority (IANA) (see here and here). IANA-reserved routes, known as bogons, change over time, so it’s a good idea to keep current on which networks to block. One good source is the bogon-announce mailing list. Details, a filtering FAQ and links to other filtering information are available on the Web (see here).

•  Do block unwanted applications. An easy method for stopping unwanted traffic is simply to filter on the well-known protocol and/or port numbers that a given application uses. For example, a router could block outbound telnet sessions by dropping any packet with destination TCP Port 23. The major caveat with this technique is that it does not protect against rogue applications that change port numbers, for example by sending peer-to-peer traffic over Port 80 (which is reserved for Web traffic).

•  Do track usage: How many times did users visit a given network? How much bandwidth did a given application consume? Most routers’ filters can be set to answer these questions by logging the number of times a filter was invoked. In the case of Cisco’s access lists, enabling logging is simple: Just append the word “log” at the end of the filtering conditions. Some other devices, such as those from Enterasys Networks and Tasman, automatically log by default.

•  Do lighten the load. Our test results and Cisco documentation agree: Packet filtering can impose several performance penalties on Cisco routers. One strategy that considerably reduces CPU utilization is to use routing instead of filtering. For example, it’s possible to route traffic to or from unwanted addresses to the null0 interface.

•  Do pay attention to order. Routers process filters in order. For every packet that comes in, a router checks the packet against its first filter, its second filter and so on until it finds a match. If the first rule in an access control list (ACL) is to deny all traffic, the router won’t forward any packets. It’s a good practice to end an ACL with a deny-all filter, but be sure it’s preceded by filters that explicitly allow traffic that should be permitted.

•  Don’t forget about routing. As soon as a single filter is invoked, many routers automatically will block traffic unless it is expressly permitted. A common error when configuring ACLs is to omit filters that permit routing traffic to pass.

•  Don’t use routers in place of firewalls. Packet filters block access, but that’s where the similarities to firewalls end. As a network-layer device, a router can’t track state on transport- or application-layer sessions, both critical requirements of a firewall. Packet filtering offers some security (and it’s certainly better than nothing), but it won’t prevent an attacker from mounting many attacks a firewall could stop.

Back to main review: “Filters on routers: The price of performance”