Penetration Testing mailing list archives
RE: Mapping Class A network ( any easy trick?)
From: robert () dyadsecurity com
Date: Wed, 9 Feb 2005 10:14:49 -0800
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
Current thread:
- Re: Mapping Class A network ( any easy trick?), (continued)
- Re: Mapping Class A network ( any easy trick?) Jordan Wiens (Feb 08)
- Re: Mapping Class A network ( any easy trick?) Ismael Gonzalez (Feb 11)
- RE: Mapping Class A network ( any easy trick?) Moonen, Ralph (Feb 08)
- Re: Mapping Class A network ( any easy trick?) Tim (Feb 09)
- RE: FW: Mapping Class A network ( any easy trick?) Navin Johnson (Feb 08)
- Fw: Re: Mapping Class A network ( any easy trick?) Volker Tanger (Feb 09)
- RE: Mapping Class A network ( any easy trick?) Henderson, Dennis K. (Feb 09)
- RE: Mapping Class A network ( any easy trick?) Brass, Phil (ISS Atlanta) (Feb 09)
- RE: Mapping Class A network ( any easy trick?) Moonen, Ralph (Feb 09)
- Re: Mapping Class A network ( any easy trick?) Tim (Feb 11)
- RE: Mapping Class A network ( any easy trick?) robert (Feb 09)
- RE: Mapping Class A network ( any easy trick?) Jeff Gercken (Feb 09)
- Re: Mapping Class A network ( any easy trick?) John Thomas (Feb 11)