Re: scan shows open ports as tcpwrapped

["Fahad A. Saeed" <fneyaz () gmail com>]

Greetings Dan,
This is what we ended with. A mixed feeling between love and hate toward
Load Balancers.
Thanks again for your inputs.

Fahad

On Sun, Nov 4, 2012 at 1:21 AM, Daniel Miller <bonsaiviking () gmail com>wrote:

> -sT wouldn't help in this case, since "tcpwrapped" is a result from
> version detection, which does a full TCP connection anyway.
>
> Fahad, there is nothing to bypass here. It's a load balancer doing its
> job. If you find out how to bypass it, you should report it as a major
> vulnerability in the load balancer. Not everything can be bypassed,
> thankfully.
>
> Dan
>
> On Fri, Nov 2, 2012 at 2:46 AM, Fahad A. Saeed <fneyaz () gmail com> wrote:
> > Dear David,
> > Thank you for your response and suggestion.
> >
> > I tried both -sT and -sA. In -sA I got the same result (tcpwrapped) and
> for
> > -sA I got unfiltered.
> > Also, I tried to -S to spoof my IP address. I used multiple IPs (e.g.
> Other
> > system in the same subnet, Firewall, and Main Router). But Unfortunately
> I
> > got the same result (tcpwrapped).
> > When I tried --packet-trace it shows that I'm getting RST ACK from the
> > target (here it's Windows with MS Exchange) and nmap gives me suggested
> OS
> > as F5 Big-IP.
> > When I use different tools for port scan (i.e Nessus) it gives me all
> ports
> > OPEN, ALL PORTS !!
> >
> > Thanks again David.
> >
> > On Fri, Nov 2, 2012 at 2:03 AM, David Fifield <david () bamsoftware com>
> wrote:
> > > On Wed, Oct 31, 2012 at 05:28:35AM +0300, Fahad A. Saeed wrote:
> > > > I'd a scan task and I faced following result (appro. for all ports
> except
> > > > for really used ones i.e. ssl and smtp):
> > > >
> > > > 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:
> > > >
> > > > 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 and to
> identify
> > > >    real services behind open ports?
> > > >    - on another hand, Do you know how to do that on firewall policy(on
> > > any
> > > >    firewall)?
> > >
> > > My suggestion is to use -sT or --unprivileged. There appears to be
> > > something spoofing the first part of the three-way handshake, but -sT
> > > will require a full handshake to be completed before the port is
> > > considered open.
> > >
> > > David Fifield
> > _______________________________________________
> > Sent through the nmap-dev mailing list
> > http://cgi.insecure.org/mailman/listinfo/nmap-dev
> > Archived at http://seclists.org/nmap-dev/
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/