Inverse TCP scanning, encompassing techniques like FIN, NULL, and XMAS scans, is designed to probe a target's TCP ports by sending packets with unusual or no TCP flags set. This method leverages the behavior of TCP/IP stacks to infer the status of ports based on the responses from the target system.
How Inverse TCP Scanning Works?
In inverse TCP scanning, the scanner sends TCP packets with specific flags:
-
FIN scan: Sends packets with only the FIN flag set.
-
NULL scan: Sends packets with no flags set.
-
XMAS scan: Sends packets with FIN, PSH, and URG flags set.
According to the TCP specification (RFC 793), when a closed port receives such a packet, it should respond with a RST (Reset) packet. Conversely, if the port is open, it is expected to ignore the unsolicited packet, resulting in no response.
Detecting Firewalled Ports
Firewalls, particularly those configured to drop unsolicited packets, can interfere with the expected responses:
-
No Response: If a firewall silently drops the probing packet, the scanner receives no response. This behavior is indistinguishable from that of an open port, leading to ambiguity.
-
ICMP Error Messages: Some firewalls may send back ICMP error messages (e.g., "Destination Unreachable") when a packet is blocked. These messages can indicate that a firewall is present and actively filtering traffic.
Therefore, when using inverse TCP scanning, the absence of a response could signify either an open port or a filtered port, depending on the firewall's configuration. This ambiguity necessitates caution in interpreting scan results.
Practical Example
Consider a scenario where a scanner sends a FIN packet to a target port:
-
Closed Port: The target responds with a RST packet, indicating the port is closed.
-
Open Port: No response is received, suggesting the port is open.
-
Filtered Port: No response is received because a firewall has dropped the packet, making it appear similar to an open port.
This example illustrates the challenge in distinguishing between open and filtered ports using inverse TCP scanning.
Limitations and Considerations
-
Operating System Variability: Not all operating systems adhere strictly to RFC 793. For instance, Windows systems may respond differently to these scans, affecting the accuracy of the results.
-
Firewall Behavior: Modern firewalls may be configured to detect and block such scanning techniques, further complicating interpretation.
-
Ambiguity in Results: The inability to definitively distinguish between open and filtered ports can limit the utility of inverse TCP scanning in certain environments.
