Ethical Hacking Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package. | Computer Forensics Training at InfoSec Institute Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors. |

| Subject: | RE: Mapping Class A network ( any easy trick?) |
|---|---|
| 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
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | RE: Mapping Class A network ( any easy trick?), Moonen, Ralph |
|---|---|
| Next by Date: | RE: Mapping Class A network ( any easy trick?), Jeff Gercken |
| Previous by Thread: | Re: Mapping Class A network ( any easy trick?), Tim |
| Next by Thread: | RE: Mapping Class A network ( any easy trick?), Jeff Gercken |
| Indexes: | [Date] [Thread] [Top] [All Lists] |