UNIX System Administration Handbook - Evi Nemeth [179]
13.9 SECURITY ISSUES
We address the topic of security in a chapter of its own (Chapter 21), but several security issues relevant to IP networking merit discussion here. In this section, we briefly look at a few networking features that have acquired a reputation for causing security problems and recommend ways to minimize their impact. The details of our example vendors’ default behavior on these issues (and appropriate methods for changing them) are covered later in this chapter.
IP forwarding
If a UNIX box has IP forwarding enabled, it can act as a router. Unless your system has multiple network interfaces and is actually supposed to function as a router, it’s advisable to turn this feature off. Hosts that forward packets can sometimes be coerced into compromising security by making external packets appear to have come from inside your network. This subterfuge can help naughty packets evade network scanners and packet filters.
ICMP redirects
ICMP redirects can be used maliciously to reroute traffic and mess with your routing tables. Most operating systems listen to them and follow their instructions by default. It would be bad if all your traffic were rerouted to a competitor’s network for few hours, especially while backups were running! We recommend that you configure your routers (and hosts acting as routers) to ignore and perhaps log ICMP redirects.
Source routing
IP’s source routing mechanism lets you specify an explicit series of gateways for a packet to transit on the way to its destination. Source routing bypasses the next-hop routing algorithm that’s normally run at each gateway to determine how a packet should be forwarded.
Source routing was part of the original IP specification; it was intended primarily to facilitate testing. It can create security problems because packets are often filtered according to their origin. If someone can cleverly route a packet so as to make it appear to have originated within your own network instead of the Internet, it might slip through your firewall. We recommend that you neither accept nor forward source-routed packets.
Broadcast pings and other forms of directed broadcast
Ping packets addressed to a network’s broadcast address (instead of to a particular host address) will typically be delivered to every host on the network. Such packets have been used in denial of service attacks; for example, the so-called smurf attacks. Most hosts have a way to disable broadcast pings—that is, they can be configured not to respond to or forward them. Your Internet router can also filter out broadcast pings before they reach your internal network. It’s a good idea to use both host and firewall-level security measures if you can.
Broadcast pings are a form of “directed broadcast,” in that they are packets sent to the broadcast address of a distant network. The default handling of such packets has been gradually changing. For example, versions of Cisco’s IOS through 11.x forwarded directed broadcast packets by default, but IOS releases since 12.0 do not. It is usually possible to convince your TCP/IP stack to ignore broadcast packets that come from afar, but since this behavior must be set on each interface, this can be a nontrivial task at a large site.
UNIX-based firewalls
Red Hat and FreeBSD include packet filtering (aka “firewall”) software in their kernels and basic software distributions. Although we describe this software in the vendor-specific sections for each OS (pages 326 and 333), we don’t really recommend using a workstation as a firewall. The security of UNIX hosts (especially as shipped by our friendly vendors) is weak, and NT’s security is even worse. We suggest that you buy a dedicated hardware solution to use as a firewall. Even a sophisticated software solution such as Checkpoint’s Firewall-1 product (which runs on a Solaris host) is not as good as a piece of dedicated hardware such as Cisco’s PIX—and it