1

Using nmap to do a protocol discovery (nmap myhost -sO) identifies the following on my target. Note reason switch is also used.

 PROTOCOL STATE SERVICE REASON
1        open  icmp    echo-reply ttl 255
6        open  tcp     proto-response ttl 255

If I then add the -f to fragment the packets to evade ids / firewall (nmap myhost -sO -f)

the scan no longer reports TCP as a protocol and only reports ICMP

PROTOCOL STATE SERVICE REASON
1        open  icmp    echo-reply ttl 255

Why does fragmenting the packets stop detection of TCP, is the firewall actively dropping these or does it not understand them?

Update:

I tried manually setting mtu in increments of 8 until I discovered TCP again and this occurs at mtu 24 . So nmap myhost -sO -mtu 24

and it's back to

PROTOCOL STATE SERVICE
1        open  icmp
6        open  tcp
  • can you sniff on the target side to see if they are being dropped? We can't tell you what the firewall or the host is doing without more data – schroeder Mar 8 '17 at 15:08
  • No, i'm not able to do that. I was hoping to get an idea of what this type of response might indicate as this doesn't appear to be a regular case. I have added further info to the original post – iainpb Mar 8 '17 at 15:21
1

Most likely you have a firewall somewhere that is dropping packets for which it cannot make a determination of policy. A MTU of 24 is enough for the full IP header plus the source and destination ports of the TCP header. The next lowest valid MTU is 16, which is not enough to include the destination IP address. The firewall probably does not reassemble packets, so without enough to make a determination it drops the inbound packet. For ICMP, on the other hand, all that is needed may be the protocol number.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.