Re: Discovering Live Hosts

From: Sat Jagat Singh (flyingdervish@yahoo.com)
Date: Wed Aug 08 2007 - 15:12:03 EDT


In particular, I have seen Symantec Raptor firewalls
respond that way on several occassions. I have rarely
seen it with some others, depending on something in
the configuration that I did not have the opportunity
to examine and I don't know which models. But the
Symantec Raptors, definitely. I am presently scanning
a network where I see responses from each and every
single IP address with port 139 closed. I presume
that not every single IP has a Windows machine behind
it blocking file & print services. This appears to be
a spurious result.

I'm painfully aware of how long it takes to scan a
large range for even a limited set of ports, but only
wanted to point out a problem with the question. One
approach might be to ask the client if they know what
IP addresses are active or assigned and then see
whether you can reach them through a variety of
methods. Or does the customer even know what
addresses are in use?

Yes, arp spoofing, and port monitoring as well, will
only show you traffic on your current network, but it
may reveal traffic to/from hosts within your target
range in communication with hosts on your LAN;
assuming you're even on a customer LAN and not looking
across the internet. I mention it because that is the
perspective from which I am usually working and
because Nikhil did not specify how he would be
connecting to the target network. It end up a useless
suggestion, but another possibility for some cases.

How you connect to the target networks would be
helpful information.
--- rajat swarup <rajats@gmail.com> wrote:

> On 8/8/07, Sat Jagat Singh <flyingdervish@yahoo.com>
> wrote:
> >
> > 1)You hint that your targets may be behind a
> firewall.
> > I wonder if this is known. If so, a tool called
> > firewalk may assist you. See also
> > http://www.packetfactory.net/Projects/firewalk/
> >
> > 2) A syn scan (nmap switch -sS) will have false
> > positives in some cases. I often find that some
> > firewalls respond as if every port is open for
> every
> > single IP address. A full TCP connect is the only
> way
> > to identify if the host is truly live (nmap switch
> > -sT). It takes longer, but you can't be sure the
> host
> > is up or down if the firewall is masking all
> responses
> > until you actually connect to each and every port.
> >
> > 3) Yes, I said "each and every port." Some hosts
> > don't respond to ICMP. Some may be behind a
> firewall
> > that masks the responses. Some services may have
> been
> > remapped to unusual ports. Some hosts support no
> > typical services, but do have something listening
> on
> > an unusual port.
> >
> >
> > I'll offer one other thing to try, though, which
> might
> > help. Capture network traffic to see who is
> talking
> > on the network. Filter on the target network IDs.
> > Will they let you have a monitor port on the local
> > switch? Can you arp spoof to gain the ability to
> > capture packets? If you get a packet capture, you
> may
> > often see communications with systems that you may
> not
> > be otherwise able to reach at all.
> >
>
> Sat..are you sure it was a firewall or was it
> something like a
> portsentry that actively throws off scans by showing
> spurious open
> ports? For my knowledge could you elaborate which
> firewall parameters
> (and which firewalls) do that?
> Nmap has a firewall detection capability as it can
> fingerprint but
> that is at the cost of time. Also, we're looking at
> a class A & B
> here. Connecting to "each and every port" would be
> possible if you
> have the budget for many months. Most pen tests
> wouldn't have the
> time / budget for the same.
> Realistically, you can't find all hosts on such
> large network. Let's
> not forget DHCP and DNS timeouts working.
> One tip: if you are not too concerned abt DNS
> resolutions (at the cost
> of loosing hosts that would only resolve on a DNS
> but don't respond to
> anything) try using -n option on nmap to avoid DNS
> resolutions, I've
> seen it saves a lot of time. Also, don't forget to
> use the
> --max-rtt-timeout for enhanced timing.
>
> Arp spoofing would only help in sniffing the
> traffic...it's still not
> an effective way to enumerate as you will only know
> the frequently
> used servers + Arp spoofing is applicable if the
> client is on the same
> network as the tester. No kind of sniffing can be
> as effective as
> scans but sniffing could be used in *conjuction*
> with other stuff
> already talked about.
>
> HTH,
> --
> Rajat Swarup
>
> http://rajatswarup.blogspot.com/
>

       
____________________________________________________________________________________
Yahoo! oneSearch: Finally, mobile search
that gives answers, not web links.
http://mobile.yahoo.com/mobileweb/onesearch?refer=1ONXIC

------------------------------------------------------------------------
This list is sponsored by: Cenzic

Need to secure your web apps NOW?
Cenzic finds more, "real" vulnerabilities fast.
Click to try it, buy it or download a solution FREE today!

http://www.cenzic.com/downloads
------------------------------------------------------------------------



This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:58:00 EDT