Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'd a scan task and I faced following result

Host is up (0.032s latency).
Scanned at 2012-10-25 16:06:38 AST for 856s
1/tcp     open  tcpwrapped
3/tcp     open  tcpwrapped
4/tcp     open  tcpwrapped
19/tcp    open  tcpwrapped
20/tcp    open  tcpwrapped
21/tcp    open  tcpwrapped
22/tcp    open  tcpwrapped
23/tcp    open  tcpwrapped
64623/tcp open  tcpwrapped
64680/tcp open  tcpwrapped
65000/tcp open  tcpwrapped
65129/tcp open  tcpwrapped
65389/tcp open  tcpwrapped

Scan methodology was

nmap -n -vv -A x.x.x.x --min-parallelism=50 --max-parallelism=150 -PN -T2 -oA x.x.x.x

I'm sure that this is a firewall's or loadbalancer's game. I tried many way such as change source port, source IP , fragmentation, etc..

  • Do you have any idea/suggestion to bypass this case?
  • on another hand, Do you know how to do that on firewall policy(on any firewall)? Thanks
share|improve this question

"tcpwrapped" refers to tcpwrapper, a host-based network access control program on Unix and Linux. When Nmap labels something tcpwrapped, it means that the behavior of the port is consistent with one that is protected by tcpwrapper. Specifically, it means that a full TCP handshake was completed, but the remote host closed the connection without receiving any data.

It is important to note that tcpwrapper protects programs, not ports. This means that a valid (not false-positive) tcpwrapped response indicates a real network service is available, but you are not on the list of hosts allowed to talk with it. When such a large number of ports are shown as tcpwrapped, it is unlikely that they represent real services, so the behavior probably means something else.

What you are probably seeing is a network security device like a firewall or IPS. Many of these are configured to respond to TCP portscans, even for IP addresses which are not assigned to them. This behavior can slow down a port scan and cloud the results with false positives.

EDIT: Since this post was flagged as plagiarism and deleted, I would like to point out that the assumed source (this page on was also written my me. This Security.StackExchange answer (October 31, 2013) predates that page (November 12, 2013) by nearly two weeks. I saw that this answer was receiving upvotes, and as a core Nmap developer I decided that the text would serve as a good addition to our Frequently Asked Questions documentation. It is entirely within my rights, not only as the content creator, but under the Creative Commons Share Alike license stipulated in the StackExchange Terms of Service to redistribute this content in this manner. I recognize that I should have attributed that other content properly, but that is not a reason to remove this post.

share|improve this answer
bonsaiviking - thanks for clarifying. – Rory Alsop Oct 22 '14 at 7:57

You are looking at trying to map out the firewall rules. 'Firewalking' tools might help with this, but I don't have high hopes.

  • Try slowing your speed. You are using T2, which is very fast and you might be getting odd results.
  • Try not using -A, but specify the -sV switch directly
  • Try looking for 'port knocking' opportunities
  • Try using a packet crafter, such as scapy or hping3 to really drill down into the traffic you send and try to map out what can get through.
share|improve this answer
a good answer and a strategy how to solve the "issue" – JSmyth Dec 5 '15 at 8:41

You could try using nmap -sV which will grab the header and version information. All TCP ports will still be open (obviously there is nothing you can do about that), but you could grep though and find interesting banners and go from there.

share|improve this answer
Thanks Rook but -sV is already included in -A. another thing I as you may know that this case shows whole ports are open so it more than though to guess which one is interesting ,, it's black box scan :) – KING SABRI Oct 31 '12 at 0:48
@KING SABRI so then grep though the results – rook Oct 31 '12 at 1:20
There are no real result because its not real open ports ,, as you know there is not host have all ports open. – KING SABRI Oct 31 '12 at 11:20
I think what @KINGSABRI is saying is that there is no real data to grep for due to the FW. The OP is about finding a way to get relevant data. – schroeder Oct 31 '12 at 18:19
@schroeder and grepping though the response is that way. If there is a real service it will have a header and -sV or -A will display that header. But if all the ports are actually closed then obviously a waste of time! – rook Oct 31 '12 at 18:39

This post describes tcpwrapped as something common with Windows hosts. Beyond that I'm not quite sure.

share|improve this answer
yes sir, I sow this post but it doesn't help – KING SABRI Oct 31 '12 at 11:21 is a good quick article about tcpwrapped. Its probably a firewall that doesn't like your IP so ita just dropping your conection. Unless you can figure out what IPs it likes or trick it into thinking your a LAN IP (I dont know if that is possible tbh) then I don't think you can find out what those ports are. You could also try ncat to connect directly to tye ports and see if they respond to any protocols (make a couple of text files that have typical "hello" requests for each proto, like "GET / HTTP/1.0" or whatever) and then ncat x.x.x.x port < httpget.txt


share|improve this answer
If you spoof an authorised ip address, it's unlikely that you'll receive any response. – tjt263 Dec 4 '15 at 18:18

Your Answer


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.