How to interpret nmap result, host up but no ports open

nmap

I have used nmap to map a network, scanning using the following command 

nmap -v -sS --no-stylesheet -T3 -sU -sV -O -oX <filename.xml> 192.168.69.0/24

Some of the hosts come back with a strange result. Nmap reckons they are up due to syn-ack. I assumed this meant that a tcp connection was made to a certain port and the 3-way handshake process was completed. However, there are no ports listed as open. (there are however open|filtered, filtered and closed ports). Can anyone explain how I should interpret this? Does negotiating a tcp connection to a host not mean that there must be at least one port open?

The XML output for that host from the scan is below:

<host starttime="1435615239" endtime="1435901758">
  <status state="up" reason="syn-ack" reason_ttl="115"/>
  <address addr="192.168.69.23" addrtype="ipv4"/>
  <hostnames>
    <hostname name="example.com" type="PTR"/>
  </hostnames>
  <ports>
    <extraports state="open|filtered" count="1000">
    <extrareasons reason="no-responses" count="1000"/>
    </extraports>
    <extraports state="filtered" count="996">
    <extrareasons reason="no-responses" count="996"/>
    </extraports>
    <port protocol="tcp" portid="111">
    <state state="closed" reason="reset" reason_ttl="115"/>
    <service name="rpcbind" method="table" conf="3"/>
    </port>
    <!-- more closed ports -->
  </ports>
  <os><!-- ... --></os>
  <times srtt="3165" rttvar="109" to="100000"/>
</host>

Best Answer

Nmap reckons they are up due to syn-ack. I assumed this meant that a tcp connection was made to a certain port and the 3-way handshake process was completed.

Actually, Nmap does not complete a 3-way handshake for host discovery (nor for TCP SYN scanning with -sS). It sends a raw TCP SYN packet to port 443 (among other probes), and considers the host up if it receives any of a number of different responses. In your case, the target sent a SYN-ACK response, indicating an open port. Nmap then leaves it up to your scanning host's OS to send a RST packet in reply, since the OS doesn't know about the outgoing SYN and isn't expecting the SYN-ACK reply. If you have your firewall configured to DROP invalid or unexpected packets, then the RST will never be sent.

Some TCP stacks, especially on embedded devices, don't handle TCP abnormalities very well. Your target could be sitting with a half-open TCP connection on port 443, waiting for a RST or ACK packet that never arrives, which would cause the subsequent SYN probe during the port scan phase to fail to get a response.

This is all guesswork, though. It's just as likely that the target has some sort of adaptive host firewall that detected the port scan and started dropping Nmap's traffic before it got to the open port 443.

Related Topic