What might the reason be NMAP is giving a different result when scanning:

  1. bulk domains?
  2. service detection enabled?

First question

When scanning bulk, where domain X is part of, this is the result I get:

21/tcp   open     ftp
22/tcp   open     ssh
25/tcp   filtered     smtp
80/tcp   open     http

When scanning the same domain X individually:

21/tcp   open     ftp
22/tcp   open     ssh
25/tcp   open     smtp
80/tcp   open     http

So why does it show filtered as State when scanning bulk - and when scanning individually, it shows the state as open?

Second question:

When I enable service detection (-sV), this is what I get of domain X scanning individually:

21/tcp   open     tcpwrapped
22/tcp   open     tcpwrapped
25/tcp   open     smtp         Postfix smtpd
80/tcp   open     http         Apache httpd

Why is the service of port 21 and 22 of the same domain out of the sudden now tcpwrapped?

The same behavior exists when scanning yet again bulk, with service detection.

This makes on sense!

Has anyone got an idea how I can scan bulk, without getting a "tcpwrapped" or a "filtered" as result?

Thank you!

  • I think your scan is getting blocked by an IPS or similar device
    – paj28
    Jul 17, 2017 at 20:44

1 Answer 1


Your "bulk" scan of many IPs has probably triggered a firewall or IPS to drop your probes instead of letting them through. The pattern of "try to connect to lots of different IPs on the same port" is easy to detect. This is most likely the cause of the filtered port state. Slow down your scan until you do not cross the threshold that the IPS considers as "lots."

In the first scan, Nmap did not try to probe the services, but only to determine the state of the ports. Because it did not try to probe the service, it lists the commonly-used service name for that port number, found by looking it up in the nmap-services file. This is the source of the "ftp" and "ssh" labels.

In the second scan, the -sV option tells Nmap to go ahead and try to get a response from the service in order to classify it. It may be that someone is using port 21 to run a web server and not an FTP server. When it tried to do this, the target immediately closed the connection. This behavior is commonly evidence of a program called TCP Wrapper, which hangs up connections like this if the remote IP (yours) is not on an approved list. Other network devices may cause similar results, but the tcpwrapped string will still be shown. Nmap no longer uses "ftp" or "ssh" for these ports because a simple FTP or SSH server would not behave this way.

I recommend slowing down your scan a bit to try to avoid detection, and adding the -v --reason options to see the reason and received TTL field value for each port. Comparing these can give an idea of where the response (or no response) is coming from--the target or something between you and the target.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .