When the TCP transport is used, static packet filtering can use the flag field in the TCP header when making traffic control decisions. Figure 5.1 shows a packet decode of a TCP/IP packet. The Control Bits field identifies which flags have been set. Flags can be either turned on (binary value of 1) or turned off (binary value of 0).
Figure 5.1: A TCP/IP packet decode
So what does the flag field tell us? You may remember from our discussion of the TCP three-packet handshake in Chapter 3 that different flag values are used to identify different aspects of a communication session. The flag
field gives the recipient hosts some additional information regarding the data the packet is carrying. Table 5.2 lists the valid flags and their uses.
Table 5.2: Valid TCP/IP Flags
TCP Flag Flag Description
ACK (Acknowledgement) Indicates that this data is a response to a data request and that there is useful information within the Acknowledgment Number field.
FIN (Final) Indicates that the transmitting system wishes to terminate the current session. Typically, each system in a
communication session issues a FIN before the connection is actually closed.
PSH (Push) Prevents the transmitting system from queuing data prior to transmission. In many cases it is more efficient to let a transmitting system queue small chunks of data prior to transmission so that fewer packets are created. On the receiving side, Push tells the remote system not to queue the data, but to immediately push the information to the upper protocol levels.
RST (Reset) Resets the state of a current communication session. Reset is used when a non-recoverable transmission failure occurs. It is a transmitting system’s way of stating, “Were you listening to me? Do I have to say it again?” This is typically caused by a non-responsive host or by a spouse enthralled by an afternoon sporting event.
SYN (Synchronize) Used while initializing a communication session. This flag should not be set during any other portion of the
communication process.
URG (Urgent) Indicates that the transmitting system has some high- priority information to pass along and that there is useful information within the Urgent Pointer field. When a system receives a packet with the Urgent flag set, it processes the information before any other data that may be waiting in queue. This is referred to as processing the data out-of- band.
The flag field plays an important part in helping a static packet filter regulate traffic. This is because a firewall is rarely told to block all traffic originating off of a specific port or going to a particular host.
For example, you may have an access control policy that states, “Our internal users can access any service out on the Internet, but all Internet traffic headed to the internal network should be blocked.” While this sounds like the ACL should be blocking all traffic coming from the Internet, this is in fact not the case.
Remember that all communications represent a two-step process. When you access a Web site, you make a data request (step 1) to which the Web site replies by returning the data you requested (step 2). This means that during step 2 you are expecting data to be returned from the Internet-based host to the internal system. If the second half of our statement were taken verbatim (“…all Internet traffic headed to the internal network should be blocked.”), our replies would never make it back to the requesting host. We are back to the “wire cutters as an effective security device” model: our firewall would not allow a complete communication session.
This is where our flag field comes into play. Remember that during the TCP three-packet handshake, the
originating system issues a packet with SYN=1 and all other flags equal to 0. The only time this sequence is true is when one system wishes to establish a connection to another. A packet filter will use this unique flag setting in order to control TCP sessions. By blocking the initial connection request, a data session between the two systems cannot be established.
This is clearly not the most secure method of locking down your network perimeter. By playing with the flag values, a would-be attacker can fool a static packet filter into allowing malicious traffic through. In this way, these predators stay one step ahead of these security devices.
FIN Scanners
Because a simple packet filter is capable of blocking port scans, some people decided to become creative. The simple port scanner eventually evolved into the FIN scanner. A FIN scanner operates under a similar principle to the port scanner, except that the transmitted packets have FIN=1, ACK=1 and all other flags set to 0.
Now, since our packet filter is only looking to block packets which have SYN=1 and all other flags set to 0, these packets are happily passed along. The result is that an attacker can analyze the returning data stream to determine which hosts are offering what services. If the destination host returns an ACK=1, RST=1 (a generic system response for nonexistent services), the software knows that this is an unused port. If, however, the destination host returns an ACK=1, FIN=1 (the service’s agreeing to close the connect), the FIN scanner knows that there is a service monitoring that port. This means that our packet filter is unable to deter these scanning probes.
For example, there are software programs called port scanners that can probe a destination host to see if any service ports are open. The port scanner sends a connection request (SYN=1) to all the service ports within a specified range. If any of these connection requests causes the destination host to return a connection request acknowledgment (SYN=1, ACK=1), the software knows that there is a service monitoring that port.