8.6. Filtering by AddressThe simplest, although not the most common, form of packet filtering is filtering by address. Filtering in this way lets you restrict the flow of packets based on the source and/or destination addresses of the packets without having to consider what protocols are involved. Such filtering can be used to allow certain external hosts to talk to certain internal hosts, for example, or to prevent an attacker from injecting forged packets (packets handcrafted so they appear to come from somewhere other than their true source) into your network.
For example, let's say that you want to block incoming packets with forged source addresses; you would specify the following rule.
Note that Direction is relative to your internal network. In the router between your internal network and the Internet, you could apply an inbound rule either to incoming packets on the Internet interface or to outgoing packets on the internal interface; either way, you will achieve the same results for the protected hosts. The difference is in what the router itself sees. If you filter outgoing packets, the router is not protecting itself.
8.6.1. Risks of Filtering by Source AddressIt's not necessarily safe to trust source addresses because source addresses can be forged. Unless you use some kind of cryptographic authentication between you and the host you want to talk to, you won't know if you're really talking to that host, or to some other machine that is pretending to be that host. The filters we've discussed previously will help you if an external host is claiming to be an internal host, but they won't do anything about an external host claiming to be a different external host.
There are two kinds of attacks that rely on forgery: source address and man in the middle.
In a basic source address forgery attack (shown earlier in Figure 8-1), an attacker sends you packets that claim to be from someone you trust in some way, hoping to get you to take some action based on that trust, without expecting to get any packets back from you. If the attacker doesn't care about getting packets back from you, it doesn't matter where the attacker is. In fact, your responses will go to whomever the attacker is pretending to be, not to the attacker. However, if the attacker can predict your responses, it doesn't matter that they're going somewhere else. Many (if not most) protocols are predictable enough for a skilled attacker to be successful at this. Plenty of attacks can be carried out without the attacker's needing to see the results directly. For example, suppose an attacker issues a command to your system that causes it to mail back your password file; if your system is going to send the attacker the password file in the mail, there is no need to see it during the attack itself.
In many circumstances -- particularly those involving TCP connections -- the real machine (that the attacker is pretending to be) will react to your packets (packets that are attempting to carry on a conversation it knows nothing about) by trying to reset the bogus connection. Obviously, the attacker doesn't want this to happen. Therefore, the attack must complete before the real machine gets the packets you're sending, or before you get the reset packets from the real machine. There are a number of ways to ensure this -- for example:
In general, it's not a good idea to dismiss theoretical attacks completely because they eventually become actual attacks. This kind of attack was known as a theoretical possibility for many years before it actually occurred, yet many people didn't bother to protect against it.The man in the middle forgery attack depends on being able to carry out a complete conversation while claiming to be the trusted host. In order to do this, the attacking machine needs to be able to not only send you packets, but also intercept the packets you reply with. To do this, the attacker needs to do one of the following:
So, who can you trust? At the extreme, nobody, unless you trust the machines involved at both ends and the path between them. If you trust the machines but not the path, you can use encryption and integrity protection to give you a secure connection over an insecure path.
Copyright © 2002 O'Reilly & Associates. All rights reserved.