Examining TCP Control Bits
The second approach is to examine transport layer information about the connection to determine whether it is part of an existing connection and, if so, allow the returning traffic back to 200.1.1.1. With TCP, this can be done by examining the control flags in the TCP segment header. These are shown in Table 2-4 and are defined in RFC 793. Note that multiple codes, commonly calleflags, can be sent in the same segment header, such as SYN and ACK (SYN/ACK), or FIN and ACK (FIN/ACK).
|
rable 2-4. TCP Control Information |
|
|
TCP Message |
Explanation |
|
ACK |
Acknowledges receipt of data |
|
FIN |
Terminates a connection |
|
PS H |
Acts as the push function |
|
TCP Message |
Explanation |
|
RST |
Resets the connection |
|
SYN |
Initiates a connection and synchronizes sequence numbers |
|
URG |
Points to urgent data in the segment payload |
In this situation, the packet-filtering firewall examines not only the source and destination addresses and port numbers, but, for TCP connections, it also examines the code bits to determine whether this is traffic being initiated from a device or traffic being sent in response to a request. For example, when the internal user (200.1.1.10) sends a TCP SYN, you know that the 170.1.1.1 will respond with a SYN and ACK in the TCP segment header. Therefore, if you know what kind of response control flags TCP uses, you could configure your packet-filtering firewall to allow this traffic, as shown in Figure 2-11.
Figure 2-11. Packet-Filtering Firewall Example—Examining Transport Control Codes
[View full size image!
Figure 2-11. Packet-Filtering Firewall Example—Examining Transport Control Codes
[View full size image!
Two problems exist with examining control codes at the transport layer:
Not all transport layer protocols support control codes.
Control codes can be manipulated manually to allow a hacker to slip packets through a packet-filtering firewall.
One of the biggest problems of having the packet-filtering firewall examine the control codes is that, in the TCP/IP protocol suite, TCP has control codes, but UDP doesn't. Therefore, for a UDP connection, you do not know whether this is the beginning, middle, or end of a
This document was created by an unregistered ChmMagic, please go to http://www.bisenter.com to register it. Thanks connection unless you examine the data encapsulated in the UDP segment.
The other problem is that, even for transport-layer protocols that support control codes, such as TCP, these control codes can be manipulated manually. For example, the packet-filtering router in Figure 2-11 allows traffic to 200.1.1.10 if certain control codes, such as SYN and ACK, are set in the TCP header. The assumption here—and it is a big assumption—is that the data is a response to information that 200.1.1.10 requested from an external device, such as 170.1.1.10. However, the packet-filtering firewall cannot distinguish between a valid response and a fake response. With a fake response, a hacker generates TCP segments with certain code flags set, trying to gain access through your firewall. A packet-filtering firewall, cannot distinguish between the two types of traffic.
Continue reading here: Figure 212 Stateful Firewall Filtering Example Part
Was this article helpful?