.

Planning a NMAP Scan

<<

blueaxis

Newbie
Newbie

Posts: 44

Joined: Fri Sep 09, 2011 9:20 am

Post Wed Oct 26, 2011 9:47 pm

Planning a NMAP Scan

Hey All - Looks like I need some inputs in planning my nmap scan. Say I have 100 hosts to scan, what's the best way to go about it. I mean I would like to comprehensively scan for all 65000 odd ports both TCP and UDP. Appreciate any tips, tricks, suggestions...
<<

Grendel

User avatar

Full Member
Full Member

Posts: 246

Joined: Thu Aug 28, 2008 8:48 am

Location: Colorado Springs, CO

Post Wed Oct 26, 2011 11:27 pm

Re: Planning a NMAP Scan

Out of curiosity, why do you want to scan all the ports? I understand trying to be thorough, but there are only so many exploits out there, and when you boil it down, there aren't that many "interesting" ports. Chances are, you'll hit a vulnerability on the well known ports long before you find some hidden application running on some high-end port... plus you might get false positives anyway as different apps use different high numbered ports for dedicated communication.
- Thomas Wilhelm, MSCS MSM
ISSMP CISSP SCSECA SCNA IEM

Web Site:
  • http://HackingDojo.com
Author:
  • Professional Penetration Testing
  • Ninja Hacking
  • Penetration Tester's Open Source Toolkit
  • Metasploit Toolkit for Penetration Testing
  • Netcat Power Tools
<<

hell_razor

User avatar

Jr. Member
Jr. Member

Posts: 90

Joined: Wed Jul 14, 2010 10:44 am

Post Thu Oct 27, 2011 8:20 am

Re: Planning a NMAP Scan

Hey may be trying to establish a baseline or inventory scan rather than building a list of vulnerabilities.  That being said, if it is the case, it may be better to run netstat, mbsa, etc. instead, using psexec if needed.

If you are seriously going to try to scan 65k UDP ports, that scan is gonna take a good while.
A+, Network+, Server+, CISSP, GSEC, GCIH, GPEN, GCIA, GISP, GCFW
<<

cd1zz

User avatar

Recruiters
Recruiters

Posts: 566

Joined: Sun Oct 03, 2010 9:01 pm

Post Thu Oct 27, 2011 8:43 am

Re: Planning a NMAP Scan

It's not uncommon for people to run network services on non-standard ports. People still practice security by obscurity so scanning the full range is fine.

Look at the timing and perf options for nmap and let that sucker run all night. If you're trying to evade an IDS, go on a vacation while you wait!
http://nmap.org/book/man-performance.html
<<

blueaxis

Newbie
Newbie

Posts: 44

Joined: Fri Sep 09, 2011 9:20 am

Post Thu Oct 27, 2011 10:01 am

Re: Planning a NMAP Scan

Thanks members! Guess will have to do some reading on nmap performance.

Would you prefer to do the scans in little pieces and store the output in database? OR would you prefer greppable output format in text files like say per IP or something...
Last edited by blueaxis on Thu Oct 27, 2011 12:06 pm, edited 1 time in total.
<<

MaXe

User avatar

Hero Member
Hero Member

Posts: 671

Joined: Tue Aug 17, 2010 9:49 am

Post Thu Oct 27, 2011 3:35 pm

Re: Planning a NMAP Scan

blueaxis wrote:Hey All - Looks like I need some inputs in planning my nmap scan. Say I have 100 hosts to scan, what's the best way to go about it. I mean I would like to comprehensively scan for all 65000 odd ports both TCP and UDP. Appreciate any tips, tricks, suggestions...


If you're going to do a scan like this, you HAVE to use Linux due to you can use true raw sockets on this. You can even set some custom firewall rules (if possible at the target host) to speed up the scanning process, and if you use the throttling flag, your scans will be even faster.

If you're doing a scan over the Internet, use a -T4 setting but if you're on an internal lan, you can actually set it to -T5 if you don't have to be stealthy at all.

Besides that, use the Syn Scan (-sS), NOT the OS Connect() (3-way handshake scan), and if you're scanning UDP ports, I suggest you do that in a separate scan as scanning UDP ports can often take a longer time, especially if packets are dropped. (Timeout is 1 second I think.)

Scanning a host that sends RST packets when you're doing a Syn Scan, instead of just dropping the packets will increase the scanning speed drastically. (This has to be configured on the remote hosts of course.)

Almost the same with UDP, except that it's not RST packets being sent back.

So, how can you speed up your scan too? By using a scanner that has separate sending and receiving modules. Randscan has this feature, which makes it a very fast port scanner, faster than nmap.

When you're doing large scans like this, I also suggest you keep usage of flags to a minimum, so avoid using -A, and perhaps -O as the last is just guessing / probability. You can use -sV, but this will take A LOT more time to complete, so I'd rather suggest you only use it on hosts that some interesting ports open that might be exploitable.


However before you continue with nmap, test out randscan. There's some info about how it works here including how to detect it: http://www.sans.org/security-resources/ ... anrand.php
I'm an InterN0T'er
<<

blueaxis

Newbie
Newbie

Posts: 44

Joined: Fri Sep 09, 2011 9:20 am

Post Thu Oct 27, 2011 3:56 pm

Re: Planning a NMAP Scan

MeXe - Thank you very much for your inputs. So it appears the following strategy would be a good start.

1. Pick a host, scan for all TCP ports. Of course with timing options enabled.
2. Repeat step 1 for all the remaining hosts.
3. Pick a host, scan for all UDP ports.
4. Repeat step 3 for all the remaining hosts.
5. Selectively run -sV after analyzing results from step 1 through 4.

Does that sound correct?

Hmm...as I am writing this a question pops.

How do I manage the output? database? text file? greppable format?

Thanks in advance!
<<

MaXe

User avatar

Hero Member
Hero Member

Posts: 671

Joined: Tue Aug 17, 2010 9:49 am

Post Thu Oct 27, 2011 4:12 pm

Re: Planning a NMAP Scan

Update: I was going through some notes for a certification I once took, and just remembered that a NMAP UDP scan, is limited to sending 1 packet per second on Linux, which is also why you should separate your TCP and UDP on large networks.

If you configure the firewall on the target device to send ICMP Port Unreachable the UDP scan will of course be faster.

If you can use fewer ports to scan, it's a good idea too, and if possible, use several scanning machines. If you're on a wireless network, move closer to the router as this will also increase the scanning speed. (On a wired network, be close to the high-bandwidth backbone.)


That's pretty much some of the best advice I can give at the moment  :)

blueaxis wrote:MeXe - Thank you very much for your inputs. So it appears the following strategy would be a good start.

1. Pick a host, scan for all TCP ports. Of course with timing options enabled.
2. Repeat step 1 for all the remaining hosts.
3. Pick a host, scan for all UDP ports.
4. Repeat step 3 for all the remaining hosts.
5. Selectively run -sV after analyzing results from step 1 through 4.

Does that sound correct?

Hmm...as I am writing this a question pops.

How do I manage the output? database? text file? greppable format?

Thanks in advance!




No problem, however, you do NOT use step 1 and 3, because different computers, has different ports open. So either you scan for the most commonly used ports or services you want to find, such as telnet, snmp, etc., or you scan all ports on all hosts.

Scanning one host and then applying this to all other hosts, will not give you a realistic picture, as a Windows machine may have port 135, and 445 open, while Linux will not unless Samba is installed. On a lot of linux equipment on the other hand, you may find port 22 and 80 open, while on Windows equipment, often but not always 3389 (RDP). Therefore you cannot just scan one host and repeat the same process for all hosts  ;)

You can run -sV selectively, for example on targets that appears to be servers as they're often more critical to the business than clients containing no valuable data, e.g. they may not pose a huge risk compared to a full database full of classified information stored on a server. During each pentest, you should always try to identify where the highest risk is for the company, and attack that. If you were the company, would you loose money if one regular and low privileged client is compromised, compared to a highly-privileged client or a server?  :) Therefore you must prioritize if you're doing this all by yourself and you don't have infinite time.

If you're just doing an assessment and you're not going to exploit  any services (aka pentest the network), then you should scan all hosts to identify the blacksheeps. The scanning will of course take a lot longer time, but since your goal is not to get 100 shells most likely, then you'll be fine. However, wherever you're planning this scan, find out whether you're going to break into the services, or just map the network and its services for e.g. a vulnerability assessment.

You can output it into various formats, including grepable format, xml format, normal output and even a few more. There are a few tools that will create reports for you as well, that you may feel trying out.

If you're going to scan the open services later on, find out which formats e.g. Nessus or Nexpose supports, so you can export the results from NMAP into that, and import it directly into those vulnerability scanners.

You can also go through it manually, which I've done on networks between ~30-60 hosts. The more hosts, the longer time, even though you'll quickly be able to spot anomalies that shouldn't be there, but if you're good with regex and grep, use that  ;D
Last edited by MaXe on Thu Oct 27, 2011 4:17 pm, edited 1 time in total.
I'm an InterN0T'er
<<

T_Bone

Full Member
Full Member

Posts: 199

Joined: Sat Feb 21, 2009 7:11 am

Post Thu Oct 27, 2011 4:17 pm

Re: Planning a NMAP Scan

Dependant upon whether you need to know the DNS name for each host, I would also use the -n flag which performs the scan without resolving the IP address to hostname. This can often speed up a scanning :)
<<

MaXe

User avatar

Hero Member
Hero Member

Posts: 671

Joined: Tue Aug 17, 2010 9:49 am

Post Thu Oct 27, 2011 4:19 pm

Re: Planning a NMAP Scan

T_Bone wrote:Dependant upon whether you need to know the DNS name for each host, I would also use the -n flag which performs the scan without resolving the IP address to hostname. This can often speed up a scanning :)


Valuable addition  ;D I didn't think about that immediately, but you're right, a non- or slow responsive nameserver will definitely slow most scans down if you're doing reverse IP lookups. (Which you can afterward anyway.) Thanks for reminding me  ;D
I'm an InterN0T'er
<<

ev0wpnz

Newbie
Newbie

Posts: 5

Joined: Tue Nov 08, 2011 10:05 am

Post Tue Nov 08, 2011 9:55 pm

Re: Planning a NMAP Scan

Just a couple more tidbits of information here.

Scanning all 65k ports on 100 hosts is likely to cause some network congestion. Make sure this is not something you do during peak hours.

Although the timing options for nmap are very configurable at the end of the day it's not a fast scanner. (Not saying it's a slow scanner) Make sure you are specific about what you want.

Something like this would work

#nmap -sS -T4 -n 192.168.10-20.0-254 -oA NetworkAudit.

-sS = Syn-Scan
-T4 = Template of timing options (I don't like -T5 as you have a good chance of missing something)
-n = no name resolution. (Important)
-oA = Save in all formats.

I would look into FastNMAP is this is supposed to be good for large scans. (Never personally used it)

http://sourceforge.net/projects/npwn/

Also scanrand might be a good options.

I think there is a lot of good advice here and you should defiantly be able to run this scan effectively. 

Return to Network Pen Testing

Who is online

Users browsing this forum: No registered users and 2 guests

cron
.
Powered by phpBB® Forum Software © phpBB Group.
Designed by ST Software