DOCENTES 1 Ambiente social.

Dynamic filtering takes static packet filtering one step further by maintaining a connection table in order to monitor the state of a communication session. It does not simply rely on the flag settings. This is a powerful feature that can be used to better control traffic flow.

For example, let’s assume that an attacker sends your system a packet of data with a payload designed to crash your system. The attacker may perform some packet trickery in order to make this packet look like a reply to information requested by the internal system. A regular packet filter would analyze this packet, see that the ACK bit is set, and be fooled into thinking that this was a reply to a data request. It would then happily pass the information along to the internal system.

A dynamic packet filter would not be so easily fooled, however. When the information was received, the dynamic packet filter would reference its connection table (sometimes referred to as a state table). When reviewing the table entries, the dynamic packet filter would realize that the internal system never actually connected to this external system to place a data request. Since this information had not been explicitly requested, the dynamic packet filter would throw the packet in the bit bucket.

Dynamic Packet Filtering in Action

Let’s take a look at how dynamic packet filtering works, in order to get a better idea of the increased security it can provide. In Figure 5.5, you can see two separate network configurations: one where the internal host is protected by a static packet filter and one where a dynamic packet filter is used.

Figure 5.5: The differences between static and dynamic packet filtering

Now, let’s look at some access rules to see how each of these two firewall devices would handle traffic control. The ACL on both firewalls may look something like this:

ƒ Allow the protected host to establish any service sessions with the remote server. ƒ Allow any session that has already been established to pass.

ƒ Drop all other traffic.

The first rule allows the protected host to establish connections to the remote server. This means that the only time a packet with the SYN bit set is allowed to pass is if the source address is from the protected host and the

destination is the remote server. When this is true, any service on the remote server may be accessed. The second rule is a catchall. Basically it says, “If the traffic appears to be part of a previously established

connection, let it pass.” In other words, all traffic is OK—provided that the SYN bit is not set and all other bits are off.

The third rule states that if any traffic does not fit neatly into one of the first two rules, drop it just to be safe. Both our firewall devices use the same ACL. The difference is in the amount of information each has available in order to control traffic. Let’s transmit some traffic to see what happens.

In Figure 5.6, the internal system tries to set up a communication session with the remote server. Since all passing traffic passes the criteria set up in the access control lists, both firewalls allow this traffic to pass.

Once the handshake is complete, our protected host makes a data request. This packet will have the ACK bit set, and possibly the PSH bit. When the remote server receives this request, it will also respond with the ACK bit set and possibly the PSH bit, as well. Once the data transfer is complete, the session will be closed, each system transmitting a packet with the FIN bit set.

Figure 5.7 shows this established session passing data. Note that we have no problems passing our firewall devices because of our second rule: “Allow any session that has already been established to pass.” Each firewall is making this determination in a slightly different way, however.

Figure 5.7: An established session between the two hosts

Our static packet filter is simply looking at the flag field to see if the SYN bit is the only bit set. Since this is not true, the static packet filter assumes that this data is part of an established session and lets it pass through. Our dynamic packet filter is doing the same check, but it also created a state table entry when the connection was first established. Every time the remote server tries to respond to the protected host, the state table is referenced to insure the following:

ƒ The protected host actually made a data request. ƒ The source port information matches the data request. ƒ The destination port information matches the data request.

In addition, the dynamic packet filter may even verify that the sequence and acknowledgment numbers all match. If all this data is correct, the dynamic packet filter also allows the packets to pass. Once the FIN packets are sent by each system, the state table entry will be removed. Additionally, if no reply is received for a period of time (anywhere from one minute to one hour, depending on the configuration), the firewall will assume that the remote server is no longer responding and will again delete the state table entry. This keeps the state table current.

Now let’s say that Woolly Attacker notices this data stream and decides to attack the protected host. The first thing he tries is a port scan on the protected system to see if it has any listening services. As you can see in Figure 5.8, this scan is blocked by both firewall devices, because the initial scanning packets have the SYN bit set and all other bits turned off.

Figure 5.8: Both filtering methods can block a port scan.

Not to be put off, Woolly Attacker attempts to perform a FIN scan by transmitting packets with the ACK and FIN bits set to 1. Now the results are a bit different. Since the packet filter is simply looking for the SYN bit being set to 1, it happily passes this traffic along, as this condition has not been met.

Our dynamic packet filter, however, is a bit more fussy. It recognizes that the SYN bit is not set and proceeds to compare this traffic to the state table. At this point, it realizes that our protected host has never set up a

communication session with Woolly Attacker. There is no legitimate reason that Woolly Attacker should be trying to end a session if our protected host never created one in the first place. For this reason, the traffic would be blocked. This is shown in Figure 5.9.

Figure 5.9: The effects of performing a FIN scan

So what if Woolly Attacker tries to spoof the firewall by pretending to be the remote server? In order for him to perform this attack successfully, a number of conditions would have to be met:

ƒ Woolly Attacker would have to spoof or assume the IP address of the remote server. ƒ If the address has been assumed, Woolly Attacker might have to take further measures

to insure that the remote server cannot respond to requests on its own.

ƒ If the address has been spoofed, Woolly Attacker would need some method of reading replies off the wire.

ƒ Woolly Attacker would need to know the source and destination service ports being used so that his traffic will match the entries in the state table.

ƒ Woolly Attacker would have to manipulate the communication session fast enough to avoid timeouts, both on the firewall and on the protected host.

So while it is possible to launch this type of attack, it is not very easy to succeed. Clearly, Woolly Attacker would have to be very knowledgeable and feel that he has much to gain by going to all this effort.

Keep in mind that this discussion is theory only. Your actual mileage with a specific firewall product may vary. For example, at the time of this writing, Check Point’s FireWall-1 product (which is a dynamic packet filter) has a touted feature that allows the state table to be maintained even after a rule set change. Unfortunately, this feature also means that state is not always maintained as effectively as it should be. In the FIN scan attack just described, Check Point’s FireWall-1 would have passed along the scan packets, as well.