Finding hosts with nmap
nmap is a mature open source project for network exploration and security auditing. nmap has an enormous number of features, of which this article will use only one: the ability to discover hosts on the network. All the examples are from the author's home LAN; your network is probably much more complex.
To begin with, you'll need to know something about how your network is set up. It likely has a DHCP server that issues IP addresses in a certain range, like 192.168 with some digits following. There are three of these "private networks" that may not be used for public internet addresses, and which are used for local networks:
10.0.0.0 – 10.255.255.255 (16,777,216 addresses) 172.16.0.0 – 172.31.255.255 (1,048,576 addresses) 192.168.0.0 – 192.168.255.255 (65,536 addresses)
While it is possible to scan for all possible addresses on your particular network, you will likely want to limit your nmap search. On my LAN, I only want to see some low numbers so I tell nmap
nmap -v sP 192.168.0-5.1-254
where "-sP" means "-sP: Ping Scan - go no further than determining if host is online". This is a very simple scan, but even so it yields some interesting and complex results. I am running nmap from the Zenmap controller, which gives me a graphical display of my local network topography as well as a high-level analysis of the host activity on my LAN. Many other kinds of scans are possible with nmap, but all I want is a list of hosts in order to check them for security vulnerabilities using Nessus.
Scan for vulnerabilities with Nessus
Nessus is a proprietary tool, so please read the license before deciding how to use it. There is an open source port of an earlier version of Nessus known as OpenVAS.
After setting up Nessus, I need to do a couple of things in order to scan for security issues on my LAN. First, I need to set a Policy, where I have accepted most of the default values. Then I need to add a Scan that uses the Policy. nmap found these hosts on my LAN and told me what ports they had open:
192.168.2.104 192.168.2.1 192.168.2.100 192.168.2.101 192.168.2.102
now I'll put that list into my nessus Scan and click "Launch Scan".
Nessus has a large library of known security exploits. When I launch my scan, Nessus will look for open ports on each of the hosts in the lists, and upon finding an open port, attempt to discover if whatever is listening on that port has any known security flaws. The process takes some time.
Of the six machines Nessus scanned on my LAN, nessus found a couple of high risk security problems. One is on an old Mac laptop I had not even powered up in some time. Here is some of the quoted text:
The remote host is affected by a vulnerability in its WMV decoder.
The remote Mac OS X host is running a version of Flip4Mac that contains an unspecified vulnerability in its decoder.
Flip4Mac is an extension that lets users read '.wmv' movie files. By enticing a user on the remote host to read a malformed '.wmv' file, an attacker may be able to execute arbitrary commands on the remote system.
Upgrade to Flip4Mac Version 2.2.1 or later.
I'd better fix that!
Here's a high risk vulnerability on my old Windows XP machine that Nessus found:
An account on the remote Windows host uses a default password.
The 'db2admin' account on the remote Windows host uses a known password. This account may have been created during installation of DB2, for use managing the application, and likely belongs to the Local Administrators group.
Note that while the DB2 installation no longer uses a default password for this account, the upgrade process does not force a password change if the 'db2admin' account exists from a previous install.
Assign a different password to this account as soon as possible.
Nessus was able to gain access using the following credentials :
Login : db2admin Password : db2admin
This is something that would likely happen on an Enterprise desktop machine.
Nessus found a medium-level vulnerability in my wife's Linux laptop:
It is possible to obtain information about the remote host.
The remote service understands the Bonjour (also known as ZeroConf or mDNS) protocol, which allows anyone to uncover information from the remote host such as its operating system type and exact version, its hostname, and the list of services it is running.
Filter incoming traffic to UDP port 5353 if desired.
Nessus was able to extract the following information :
- Computer name : uptowngardener-laptop.local.
- Ethernet addr : 00:19:d2:90:d2:65
- Computer Type : I686
- Operating System : LINUX
Getting deep with Netcat The vast majority of networks in the world (including the Internet) run on a protocol called TCP/IP. netcat is a tool that lets the user manipulate traffic on TCP/IP networks at a very low level but with some fairly intuitive commands. Like all the tools in this article, netcat can be used for many things, but in the context of network security testing and analysis, there are a few areas to examine.
For one thing, as a port scanner it is a lot faster than nmap or nessus if you know the host IP address:
$ nc -z 192.168.2.100 1-1000 Connection to 192.168.2.100 80 port [tcp/http] succeeded! Connection to 192.168.2.100 139 port [tcp/netbios-ssn] succeeded! Connection to 192.168.2.100 443 port [tcp/https] succeeded! Connection to 192.168.2.100 515 port [tcp/printer] succeeded!
For another thing, netcat can send unexpected input to any given server. Once you know what each port is doing thanks to nmap and nessus, you can craft your own input for your own servers:
$ nc -v -n 192.168.2.100 80 Connection to 192.168.2.100 80 port [tcp/*] succeeded! GET http://192.168.2.100/totally_bogus_hack_url https://192.168.2.100/totally_bogus_hack_url Content-Type: text/html Content-Length: 112
Finally, netcat can transfer files to and from hosts. The security implications should be clear:
nc -l -p 1234 >hack.txt
There are dozens or hundreds of tools available for network analysis and security testing, of which these three are just really great and useful examples. Happy hacking!
About the author: Chris McMahon is a software tester and former professional bass player. His background in software testing is both deep and wide, having tested systems from mainframes to web apps, from the deepest telecom layers and life-critical software to the frothiest eye candy. Chris has been part of the greater public software testing community since about 2004, both writing about the industry and contributing to open source projects like Watir, Selenium, and FreeBSD. His recent work has been to start the process of prying software development from the cold, dead hands of manufacturing and engineering into the warm light of artistic performance. A dedicated agile telecommuter on distributed teams, Chris lives deep in the remote Four Corners area of the U.S. Luckily, he has email: firstname.lastname@example.org.
This was first published in March 2010