Why does an nmap -sT scan show ports filtered but -sS shows ports closed

Question

What are possible reasons why an nmap -sT scan would show "ports filtered" but an identical nmap -sS scan shows "ports closed"? I understand that -sT is a full TCP Connect, which is easier to detect (and to filter) than the -sS half open scan. But why?

Both types of scans send a SYN packet; both types of scans should expect back a SYN|ACK or a RST. The only difference that I see is that the half open scan will send a RST instead of finishing the connection handshake.

Also, I ran the command nmap -sT -P0 which tells nmap not to send a ping first (I think it typically does both a TCP ping and an ICMP ping). Doing that command causes it to respond with "ports closed" which is identical to the -sS scan response. Is that because -sT is normally being blocked due to pinging first?

That's my assumption, but I want some more experienced opinions about what I am seeing and what types of scans I can do to investigate further. Btw, I am of course allowed to be doing these scans (class work).

Answer 1

If you saved Nmap's XML output, there is an attribute of the <state> tag called reason, which will give you the reason Nmap chose to label a port closed, open, or filtered. This is usually something like "reset", "conn-refused", "syn-ack", or "port-unreach", depending on the kind of scan and the state of the port. This information can also be viewed in "normal" output by using the --reason flag or setting -d for debugging.

A common misconception is that the SYN scan (-sS) is "more stealthy" than the TCP Connect scan (-sT). At one time, and from one point of view, this was true: that is, from the perspective of the application running on the host. Back in the day, before IDS and stateful firewalls, your best indication of a port scan was application logs showing connections that were opened and immediately closed. The SYN scan, because it tears down the connection before it leaves the kernel, never crosses into the application, so these logs are not written. From the point of view of the network, however, the behavior of a half-open SYN scan (SYN, SYN-ACK, RST) is quite unusual, and can be a significant indicator of a port scan, even if only one, open port is scanned. In this case (scanning a small number of ports likely to be open, protected by IDS), the TCP Connect scan may actually be "stealthier."

-Pn (formerly known as -P0 and -PN) instructs Nmap to skip the host discovery phase, and instead assume that all hosts are up. The details of host discovery are well-documented, but it is possible that this behavior is triggering an adaptive firewall on the host. Adaptive firewalls can be tricky, since you get a variety of responses depending on your behavior and the speed of the scan. I would recommend slowing the scan with any of the timing options and reducing the number of ports scanned to a handful, until you get consistent results.

Answer 2

If you want to investigate this further, enable the --packet-trace flag. This will allow you to trace the packets nmap sent and received in order to determine the exact state of the port.

There can be a variety of factors that lead to the difference in results. It is difficult to determine the exact cause without more information.

Answer 3

This is almost certainly due to packet loss. The timings work a bit differently between connect and SYN scan. Try scanning a smaller number of ports with less intense timings. Also, if you're not on the latest nmap, try upgrading, as they're continually tweaking the timing algorithms.