From: robert@dyadsecurity.com
Date: Wed Feb 09 2005 - 13:14:49 EST
> I am about to do a penetration testing on a ?Class A
> network? and wondering how I can map the network
> without pinging 17 million IPs.(nmap -Sp 10.0.0.0/8)
Because a network of that size will take some time to map, no matter
what method/tool you're using, it's important to note exactly what
information you're hoping to retrieve. Since you're not clearly saying
what information you want, I'm assuming it's a list of live/interesting
systems. You're also not saying if that network is local or remote to
you, IE do you get routed to that network, or are they in the same
broadcast domain as you.
There are dnsscanners out there that will let you specify a range of
IP's to do in-addr.arpa lookups against. They can also take domain
names and append host names from a word list to do a dictionary attack
on host names. You could also do a true brute force for say, 1-4
characters in the host name. We wrote our own DNS scanning tool, but as
long as you can find those features, you'll get what you want. We may
be releasing our DNS scanner soon anyway. Remember to also do AXFR
attempts for the SOA and other DNS servers listed. Also, you'll find
additional DNS servers with the UDP Unicornscan command (below). Be
sure to query those servers too.
As far as enumerating live systems, you may want to check out
Unicornscan (http://www.unicornscan.org). Even though the current
public release is pretty ghetto when compared to what will be the next
release, I think it has enough functionality to provide you with a lot
of help for systems enumeration. The website has an "accurate"
description of the tool... but you can think about it as kind of like
nmap (or scanrand), with some other features they don't have yet
(nmap/scanrand also have features Unicornscan doesn't have, yet).
For a network of that size, you'll want to store the response data into
a database. For the 0.4.2 version of Unicornscan, you could install
Postgres SQL database (http://www.postgresql.org/). You'll also want to
compile Unicornscan with the database output module. In the 0.4.2
(current public) release, you can see how to do that in the
README.database file. You can find the SQL schema in
unicornscan-0.4.2/src/output_modules/database/pgsql_schema.sql
Using Unicornscan on the most common ports may help you find the live
ranges to narrow in on. Here is a sample command:
unicornscan -mU 10.0.0.0/8:7,19,53,69,111,123,137,161,500,1604,1812,2049 -pvr500 -edatabase
The -p is for impatient people who want to see the results as they come
back. The -v is for slightly more verbose. The -r is to specify the
packets per second rate to ask for. The -edatabase tells it to output
to the database output module, which will use the host, username, and
password that was configured prior to being compiled. (Yes, the new
version allows for configuration files to handle database profiles. The
new version also allows for mysql support.)
unicornscan -mT 10.0.0.0/8:7,19,21,22,23,25,53,79,80,110,111,113,139,179,443,3128,8080 -pvr500 -edatabase,p0f
The basic math to determine time (T) is to take the total number of
payloads being sent (P), multiplying that by the number of IP's in the
range (I), and dividing that by the requested packets per second (S), or
PI/S=T.
In the 1st example there, you see that we're using the UDP (-mU) mode.
This will read the payloads.conf file which may have multiple payloads
per port. The UDP port 53 has 2 payloads in the payload.conf, and has an
additional payload module, for a total of 3 payloads. Port 111 UDP has
two payloads (one is commented out in the default payloads.conf file).
Port 161 UDP has 4 payloads (3 are commented out in the default
payloads.conf file). Port 500 UDP has two payloads. All other UDP
ports listed have only 1 payload. This accounts for a total of 17
payloads in 12 ports for the UDP section. There are 2^24 (16,777,216)
IP's in the range, requiring a minimum total of 2^24 * 17 (285,212,672)
stimulus packets sent. -R will let you specify multiple attempts.
At 300 packets per second, this would take approximately 12 days to
complete. At 500 packets per second it would take approximately 7 days
to complete. At 1000 packets per second it would take approximately 3.6
days to complete. At 3000 packets per second it would take a little
over a day to complete. At 5000 packets per second, it would take ~16
hours to complete. The faster you go, the less accurate the information
will be as you have done no logistical testing of the varied networks in
the target range. Be careful to test your network's ability to send and
receive data at a high packet per second rate. Although 5000 packets
isn't a lot of bandwidth (~2.3 mb/s if we were sending 60 byte packets),
it's a high enough number of packets to cause a lot of networking gear
to have a head ache.
There are 16 payloads (TCP Syn) in 16 ports for the TCP section. At 300
packets per second, this would take ~11 days. 5000 PPS would take ~16
hours.
Having the database back end will allow for lots of data mining fun.
Combining that with our DNS scanning and web crawling will be fun (if
you really need the DNS/web crawling tools, let us know and we might be
able to send you a beta copy to play with).
> I did some research and the best information I got is
> from one of the earlier post on this
> list(http://seclists.org/lists/pen-test/2004/Jul/0067.html)
> . It was to use broadcast IPs for pings. But it may miss some subnets.
Because we record the TTL of the response packet, you can quickly map
out the relative "distance" of the machines. The next version of
Unicornscan will also allow for a TCP trace route, where you can tell it
which TTL value to start with, so you only have to TCP traceroute the
parts of the routing information that is unique to their networks (IE,
skip your local ISP hops).
> Is that the best way to it? If not, please advise
The "best" way is the way that gets you the information you want the way
that you want it. Be more specific in your request, and I'll be more
specific in my response =).
Robert
-- Robert E. Lee CTO, Dyad Security, Inc. W - http://www.dyadsecurity.com E - robert@dyadsecurity.com M - (949) 394-2033
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:54:16 EDT