Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I'm trying to find a free IP address on a network that doesn't use DHCP. I decided to run an intense scan using Nmap from 10.0.5.0 to 10.0.5.255. (I know this isn't the best way to find an unused IP address, but it's good enough for this scenario. I am open to suggestions though.) I'm on a different subnet, and I'm not 100% sure what my scan is going through (firewalls, NAT, etc).

Every single IP address is showing me port 113/tcp is closed, including unused IPs/dead hosts. This is making my results ugly and a pain to pick through.

  • Is there a way to skip scanning this port in Nmap?
  • Why is this shown even on dead hosts?
share|improve this question

2 Answers 2

up vote 2 down vote accepted

Is there a way to skip scanning this port in Nmap?

Yes. See here (reposted here for convenience):

You can use comma as a separator to separate two different ranges of port. For ex. in your case you can give the following

$ nmap 24.0.0.0/24 -p 1-79,81-65535

Hence this way we omitted port scanning on port 80.

Why is this shown even on dead hosts?

Somewhere in your routing chain you may have a router/forced proxy/stateful firewall that does some kind of packet inspection and returns an actual response to your host trying to tell you that the port is blocked. It may not even check the IP before sending this response.

In short, you can't assume that any response you receive from the network actually originated from the endpoint you asked to reach, unless you use strong encryption. Any "man in the middle" can send back a fake request, whether it's to tell you "you aren't allowed to do that!" or just some misconfiguration. The actual case of why this is happening would be extremely specific to your hardware/software configuration, as well as your ISP, etc. -- basically everything related to your network setup.

share|improve this answer

113/tcp is the port for the ident service, which was used once upon a time to identify the user behind a particular TCP connection. Because ident runs as a server, it's not accessible behind a NAT device. Without any further configuration, an ident request coming to a client behind a NAT device would drop, and the request would time out. This can result in long connection delays while a remote server tries to identify a client behind a NAT device that cannot be reached.

Rather than waste all that time with timed-out ident requests, many NAT devices, firewalls, and other network devices simply return a TCP RST for all incoming connections to port 113. This allows ident requests to terminate quickly, and everyone can get on with their life.

For skipping a particular port, you can provide a range of valid ports, omitting that one port. In this case: -p 1-112,114-1024 would scan all ports from 1 to 1024, omitting 113. For now, you can specify more ports than you want, and then limit them to the X most frequently open ports with --top-ports X. This interaction between --top-ports and -p is ambiguously documented and may change in the future.

share|improve this answer
    
Very informative details categorizing why "many" NAT devices do send a RST when trying to access ident. Certainly this answer adds information and should be upvoted... the combination of our answers taken together is the best story here. –  allquixotic Dec 19 '12 at 18:00

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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