55

I ran a scan with

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

With the following result:

Host is up (0.032s latency). Scanned at 2012-10-25 16:06:38 AST for 856s PORT STATE SERVICE VERSION 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

I'm sure that this is a firewall's or load balancer's game. I tried many ways, 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 in a firewall policy (on any firewall)?
Improve this question

7 Answers 7

Reset to default
187

"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 SecWiki.org) was also written by me. This Security.StackExchange answer (October 31, 2013) predates that page (November 12, 2013) by nearly two weeks.

Improve this answer
1
  • 79
    lmao I wish I could +2 this. +1 for a great answer and +1 for being accused of plagiarising yourself... Commented Oct 6, 2016 at 0:05
12

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.
Improve this answer
0
4

I was struggling with this issue for a week and the only answer that I got was this: There's nothing to bypass there! Now I realized that it nothing really to bypass. A TCP handshake is completed when you scan but the connection will be closed by the application behind that port. So just try to connect to the port with nc:

nc -v <IP> <port>

You will see that you can connect with port.

Improve this answer
4

One of the ways that I was able to bypass a Baracuda firewall that was TCPwrapping all ports and finishing the 3-way handshake on their behalf was to scan using one port only such the most famous TCP80, TCP443, UDP53 on the range, if the range of IPs addresses is big I'd choose the first few to test them. There are a few techniques on the nmap site such as the fragmentation, decoy, idle port, and etc. but those for some reason don't give good results in the case of TCP wrapping by a firewall or IPS.

methods tested

nmap -PS80 TARGET nmap -PS443 TARGET nmap -PU53 TARGET nmap -PU161 TARGET nmap -PS3389 TARGET

the -PU161 showed fewer open ports than the other methods.

Although this was asked many years back, I'll just leave some hints for future nmap testers

-A is very noisy and will get caught by IDS and blocked by a firewall or an IPS -sV same thing as it runs several scripts to know the services running -O will also get flagged

in the worst-case scenario, if everything gets blacked then do it manually, searching for the most common ports one by one, -p80 on one and -p443 on another and so on. You can slow down things significantly by using -T0 but the scan will take forever to finish as it will probe once every few minutes, 5 if I'm not mistaken.

-vv is no problem -n is also useful if you are not worried about DNS resolution

I'd also remove the min-parallelism or lower it to a very low number.

Improve this answer
3

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.

Improve this answer
5
  • 1
    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 :) Commented Oct 31, 2012 at 0:48
  • @KING SABRI so then grep though the results Commented Oct 31, 2012 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. Commented Oct 31, 2012 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. Commented Oct 31, 2012 at 18:19
  • 1
    @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! Commented Oct 31, 2012 at 18:39
0

https://www.enisa.europa.eu/activities/cert/support/chiht/tools/tcpd-tcpwrapper is a good quick article about tcpwrapped. It's probably a firewall that doesn't like your IP so ita just dropping your connection.

Unless you can figure out what IPs it likes or trick it into thinking your a LAN IP (I don't 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 the 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

Please make sure you are authorized to access this network before you attempt to.

Improve this answer
1
  • 1
    If you spoof an authorised ip address, it's unlikely that you'll receive any response. Commented Dec 4, 2015 at 18:18
0

Run nmap as a root user. It seems you have run nmap as an unprivileged user (i.e., not as a root user).

When nmap runs as a non-root user, it performs a TCP scan by default.

TCPwrapper is software at host machine which closes the TCP connection after three way handshake when the client has no access to a particular port. So run nmap as a root user which uses SYN stealth scan for port scanning.

Improve this answer
1
  • 1
    While it is true that non-root nmap runs TCP scans by default because you need root/admin-level privileges to run SYN scans, the core idea is not just simply to run as root, but to run the SYN scan because, as the top answer explains, a protected port will respond differently to a TCP scan. Commented Aug 31, 2020 at 12:07

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.