Thursday, 2 February 2012

The Awkward Sophomore Blog Post - The (first) NMAP Post


I'm back, the other nut from this ballsy pair (that'll be the last time I make those jokes I promise). So where were we? (We were here if you missed the previous post) We had a network range, 10.10.10.0/24 and we'd split the range down into a list of IP addresses for the awkward tools that don't like CIDR notation, that and we've dumped the file into the beginnings of our data file structure. Recap over and on we go.

So what's next? We have a number of set and forget operations that need to run, the kind of data that takes a long time to collect but we need to get anyway, you all know what I'm talking about, the good old full 65535 ports tcp/udp/version/OS scan.

First things first let's set up some variables, it'll make life easier in the long run and sets a good precident for when we come to script these things up. First lets set the range, nice and simple in bash, at the prompt type:

root@bt:~# range=10.10.10.0/24

Next we need to set our own IP address so that we can get rid of it, if you're cabled into a subnet the last thing you want to do is panic about a BT5 box on their network when it turns out to be your own. Once again nice and simple at the prompt type:

root@bt:~# myip=`ifconfig eth1 | grep "inet addr:" | cut -d : -f 2 | cut -d " " -f 1`

We can now use both of these going forward. Does anyone here like screen? I like screen, it's a good way of compartmentalising your work and more importantly if you're working on a remote box you can keep your sessions active without using nohup, big bonus.

First lets bang out the pingsweeps, if we're local it's good to have an idea of what's actually responding. There's no point in scanning devices we know from the arp cache don't exist, of course if this is remote then skip ahead. The ARP sweep in NMap allows us to do this quite easily:

nmap -sP -PA -vv -n -oA pingsweeps/pingsweep.arp $range --exclude $myip > /dev/null 2>&1 && cat pingsweep.arp.gnmap | grep Up | cut -f 2 -d " " > targets/targets.txt

For completeness (don't we all love piles of data) lets cover all the ping sweeps, they don't take long.

nmap -sP --send-ip -PE -vv -n -oA pingsweep.icmpecho -i targets.txt > /dev/null 2>&1
nmap -sP --send-ip -PP -vv -n -oA pingsweep.icmptstamp -i targets.txt > /dev/null 2>&1
nmap -sP --send-ip -PM -vv -n -oA pingsweep.icmpmask -i targets.txt > /dev/null 2>&1

Right now onto the actual scans. Although they take forever and we don't get tangeable, workable results from them straight away (watch this space for that) they need to be done.  Your scan preferences may differ but I find these acceptable for most engagements.

screen -S "full-tcp" -d -m nmap -sSVC -p- -n -vv -oA port_scans/portscan.tcp.full -i targets.txt --max-retries 1

screen -S "full-udp" -d -m nmap -sU --max-scan-delay 0 --max-retries 1 -n -vv -oA port_scans/portscan.udp.services -i targets.txt

The joy of screen is that these truly are set and forget and at any time you can type screen -r <scan_name> to check their progress (if you feel so inclined) it beats the usual ps -ef | grep nmap that we're all used to or heaven forbid tailing the nohup.out file.

Sidenote: So the big issue with NMap is that if it gets stuck on a host a ctrl-c usually means losing all the results you've gained so far. Seeing as we have a targets file we can write a wrapper that scans each ip address individually, that way if NMap hangs on a host you can ctrl-c and just carry on with the next host. It'll look something like this:

while read line; do `nmap -sSVC -p- -n -vv -oA $line.tcp.full $line --max-retries 1`; done < targets.txt

Of course you then have to bring all of the results back together again, there are a few scripts out there that achieve this, if I can dig one out I'll link it.

Back to the main event. While these scans are completing we need something to be getting along with, how many hosts are running web servers? how many snmp? mail servers? etc etc. A quick scan alongside the full ones allows us to start getting this data and passing it onto other software quick sharp. Of course you could always use the --top-ports=<1-4000ish> flag, but I prefer to write my own list, this does the job for me: 

screen -S "hot-targets" -d -m nmap -sSV -p80,443,25,3389,23,22,21,53,135,139,445,389,3306,1352,1433,1434,1157,U:53,U:161 n -vv -oA port_scans/hot-targets.tcp.services -i targets.txt

The greppable output from here can then be thrown directly into tools like nikto, onesixtyone, skipfish etc.

Last bit I want to cover off is non-standard web ports. There are a few ways we can cover them off, firstly we can wait for the full scan to complete and grep for www or http, that would be the most sensible thing to do, and should probably be done no matter what. In the mean time we can search for some:

screen -S "webhosts" -d -m nmap -sSV -p 80,443,81,82,8080,8081,8443,8118,3128,280,591,593 -n -vv -oA port_scans/webhosts.tcp.services -i targets.txt

By no means a conclusive list (please add more in the comments/twitter and I'll update) but it's a good starting point.

That'll probably do for now, before you're all NMaped out, next time we'll go through what we can do with this data now we have it.


Edit for Steve:


After a brief chat with @stevelord on twitter I came to agree that I'd been lazy and left out RTT optimisation for the scanning, it was on my to-do list but I thought I'd wait and do a clean up post at some point, well that point is now, to get an idea of the RTTs for the network you're on you're going to need to do some pinging, and seeing as we have nping why not sure it, what I came up with was this bad boy:


INITRTT=`nping --icmp $(head -5 targets) | grep "Avg rtt" | cut -f 13 -d " " | sort | uniq | awk 'sub("..$", "")' | awk 'NR == 1 { sum=0 }{ sum+=$1;} END {printf "%f\n", sum/NR}' | cut -f 1 -d "."` && MAXRTT=$[INITRTT*4]


This pings the top five hosts in the targets file, averages their RTTs and then multiplies it by 4. This creates the variables INITRTT and MAXRTT and these can then be used in the nmap scans with the flags:


initial-rtt-timeout $[INITRTT]ms & max-rtt-timeout $[MAXRTT]ms


I hope that helps and that your scans end up a bit faster.

No comments:

Post a Comment