|
Chapter 6 Packet Filtering |
|
|
|
Chapter 6 Packet Filtering |
|
The 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 this rule:
| Rule | Direction | Source Address | Destination Address | Action |
|---|---|---|---|---|
| A | Inbound | Internal | Any | Deny |
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.
It'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 above 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 in Figure 6.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, he doesn't need to be on the path between you and whoever he is pretending to be; he can be anywhere.
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, he doesn't need to see them. Many (if not most) protocols are predictable enough for a skilled attacker to be successful at this. There are plenty of attacks that can be carried out without the attacker needing to see the results directly. For example, suppose an attacker issues a command to your system that causes it to email your password file to him; if your system is going to send the attacker the password file in the mail, there is no need for him 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. He has to ensure the attack completes 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:
Carrying out the attack while the real machine is down
Crashing the real machine so the attack can be carried out
Flooding the real machine while the attack is carried out
Confusing the routing between the real machine and the target
Using an attack where only the first response packet is required, so that the reset doesn't matter
Attacks of this kind used to be considered a theoretical problem with little real-world effect, but they are now common enough to be considered a serious threat. (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, and 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:
Insinuate his attacking machine into the path between you and the real machine. This is easiest to do near the ends of the path, and most difficult to do somewhere in the middle, because given the nature of modern IP networks, the path through "the middle" can change at any second.
Alter the path between the machines so it leads through his attacking machine. This may be very easy or very difficult, depending on the network topology and routing system used by your network, the remote network, and the Internet service providers between those networks.
Although this kind of attack is called "man in the middle," it's relatively rare for it to actually be carried out in the middle, external to the sites at each end, because nobody but a network provider is in a position to carry it out in that way, and network providers are rarely compromised to that extent. (People who compromise network providers tend to be working on quantity. Packet sniffing will give them many hosts rapidly, but man in the middle attacks give them only one site at a time.) These attacks tend to be problems only if one of the involved sites has hostile users who have physical access to the network (for example, this might be the case if one site is a university.)
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 to give you a secure connection over an insecure path. Unfortunately, as we discuss in Chapter 10, Authentication and Inbound Services , there are no widespread and commonly available tools to do that yet, but a number of sites are experimenting with ad hoc solutions, and commercial solutions are beginning to appear.
|
|
|
|
| 6.5 Conventions for Packet Filtering Rules |
|
6.7 Filtering by Service |