Because the root cause of IP spoofing is weakness in the underlying protocol, you can’t apply any patches to make the problem go away. One of your first strategies would be to reduce or eliminate services known to be vulnerable to IP spoofing, such as rsh, or unauthenticated versions of syslog.

You can also reduce the scope of the problem by applying ingress and egress filters at your routers that validate network traffic. Because systems vary, you need to consult your router documentation to determine the steps you need to take. In general, you need rules that drop packets originating from the outside that claim to originate from the inside. Next, you need to drop packets from the inside claiming to originate from external networks. If possible, log an alert on spoofed packets originating from your network, as shown in Figure 20-1, because the machine is either compromised or belongs to a mischievous user.

Figure 20-1. Egress filters protecting outside servers from attack.

Several problems are immediately apparent with this approach. First, you need to know all your internal networks. Unless you have a really simple network, knowing all the IP ranges assigned behind your outermost routers might be difficult, and if your network is very large, the internal network ranges could change often and your router rules will have to reflect the changes. The second problem is one of performance—the more traffic you have moving through a router, the fewer rules you will want in place, or you’ll end up buying more (or larger) routers to handle the load. The best way to overcome these issues is to simplify configuration by applying your rules at as low a level as possible. Not only does ingress and egress filtering help secure your network, it also helps prevent your network from being used to attack others.

Filtering cannot help when packets do not cross routers. The only way to mitigate this problem is by implementing IPSec on your network so that all network traffic between your managed systems is authenticated. Strong authentication relies on being able to see the replies a system makes, so IPSec can nearly completely eliminate IP spoofing threats.

On an internal network, you can make spoofing e-mail more difficult by requiring outgoing e-mail to be authenticated. Requiring authentication for internal mail can be done fairly easily by using Microsoft Exchange Server; many other mail servers will support some form of authentication as well. Unless your internal network is fairly complicated, you can also perform ingress filtering on SMTP messages—any mail that claims to originate from your internal network but arrives at your external gateway from the outside is almost certainly spoofed.

The most certain way to mitigate the risk of e-mail spoofing is to digitally sign all your messages. However, signed e-mail can be cumbersome and increases the amount of storage you need for your users.

Various companies and organizations are coming up with a number of plans to reduce (and we hope eliminate) spam by authenticating e-mail. With any luck, this section of the book will be obsolete in the near future.

The only way to validate where an e-mail truly originates from is by looking at the SMTP headers. The problem is made worse by bugs in some SMTP servers that end up truncating the information in the "Received: from" portions of the header. Unfortunately, once you do trace the e-mail back, you’re likely to find that it actually originates from a compromised system. For additional information, CERT has a summary at http://www.cert.org/tech_tips/email_spoofing.html.

One attack target is the client. This occurs when a client resolves a DNS name to an IP address, binds to either port 53 or a random high port, and sends a packet to the DNS server. The packet has a sequence number to help ensure that different applications get the right responses. For an attacker to corrupt the result, the attacker needs to do only a few things.

First, the attacker needs to guess the source port. This isn’t as hard as it seems because it normally ranges from 1024 through 5000 (depending on the operating system). Also, ports typically start at the bottom and work up. If there is some way to provoke the client into sending you a packet, the attacker can target a small range of ports (it takes only one to match, and you have a winner). There’s no penalty for wrong guesses unless the victim is running an intrusion detection system. If the client is an older system that always sends requests from port 53, no guessing is involved.

Second, the attacker must guess the sequence number. Some older operating systems make that easy by not using a random number for the sequence number, which is only 16 bits. If the system is using a random high port, and the sequence number is random, this can be a difficult attack to pull off. The attacker also needs to provoke the client into sending a request.

A much more direct variant of this attack is launched locally, as shown in Figure 20-2. Many switches can be tricked into diverting another system’s traffic, and if the attacker can see another system’s requests, the attack becomes a race condition—one the attacker often wins because he’ll get the packets first.

Figure 20-2. A local DNS spoofing attack.

In practice, you rarely need to resort to such complicated attacks. Most networks have a lot of targets. As an administrator, your major concern is updating older operating systems that make this attack easy.

Another approach is to attack the DNS server itself. A DNS server acting as a forwarder is then a client to other DNS servers, and the same attack explained earlier can be launched. An alternate way to attack the DNS server is enabled because the DNS specification allows more than one response to be placed into a reply.

First, you set up an attacking DNS server on a system you control. As you might imagine, this requires having a DNS name that can be resolved, so there’s considerable setup work before you can begin this attack. You then send to the DNS server you’re attacking a resolution request for the domain served by your evil DNS server. The corrupted DNS server replies with not only the record that was requested, but also another record for the system you want to spoof that claims to be authoritative. Unless the DNS server being attacked is configured properly, it accepts both records, and all clients being served are sent to the wrong system.

Unlike a good penetration tester, the real attackers out there are not going to worry about operational concerns and will find a DNS server somewhere on the Internet that they can compromise and cause to deliver corrupted responses. If you want to test this attack, getting your DNS admins to assist by sending requests directly to your attack server can make the setup less complicated. Fortunately, most recent versions of BIND and Microsoft’s DNS server since at least Windows 2000 do deny piggybacked responses by default (Figure 20-3).

Figure 20-3. Piggybacked DNS response attack.

A third attack approach targets when a server allows updates. To work properly with DHCP, DNS servers need to know when new clients are registered. Servers can be configured to allow only secure updates, to accept secure and insecure updates, and to not allow updates at all. Updating behavior can be set at the zone level, so you need to check every zone. Unlike other attacks, you can test for this fairly easily by sending an update for a zone that the DNS server is authoritative for. For example, add an alias to your own system and then try to resolve the alias. If the resolution works, you found a vulnerable server. Insecure updates can be a serious problem because the specification also allows records to be removed.

A final attack on DNS is to convince your name registering company that they should accept updates from you as an attacker. One large name registry allows three methods to secure updates. In the least secure scenario, updating mail must come from a certain e-mail address. As previously discussed, this obstacle isn’t terribly difficult to overcome. The next most secure scenario is to send a clear-text password in the e-mail requesting the update. As you might well imagine, this is only a slight improvement over the least secure option. Lastly, the name registry can require a certain PGP key to sign the e-mail. Name registries have been known to enter false records based on faxes as well. Because of the potential for great disruption, it’s best to verify this attack through talking with the name registry. Hopefully, better methods will be available by the time you read this.

One of the first issues to consider is whether you have anti-spoofing rules set on your routers. If you do, packet reply spoofing will be restricted to local systems. If you want to protect against purely local network attacks, take the same countermeasures you would to protect against IP spoofing, and if you have a high security environment, securing your network switches can help. Second, run newer versions of the operating systems. The problem with non-random sequence numbers has been known for some time, and Windows 2000 and later also use dynamically allocated ports to send requests.

To prevent overloaded reply attacks, run a recent version of your DNS server. If you’re running Microsoft’s DNS server, verify that the Secure Cache Against Pollution setting is enabled, as shown in Figure 20-4.

Figure 20-4. Securing against cache pollution attacks.

To protect against update attacks, you can configure updates zone by zone on a Windows DNS server by right-clicking a zone, choosing Properties, and then choosing the General tab, as shown in Figure 20-5.

Figure 20-5. Securing DNS against insecure updates.

Note that you should check the update configuration for every zone, and consider that some zones should not allow any updates. For example, Internet-facing systems should probably be updated manually, and Internet-facing DNS servers should not allow updates at all.

You can help prevent name registry attacks by working with your registry company to determine the most secure methods of updating your information, and also by using the highest security possible. It is up to you to ensure that the most secure mechanism is chosen.