Reading Output from nmap
|
| The reliability of data from nmap depends on the type of scanning being used and the types of systems you're scanning. Just remember, you can get false positives! If you're not sure, scan things more than once. Personally, we favor TCP and SYN scanning; FIN and UDP scanning are unreliable when dealing with slow networks. Especially in the case of Microsoft-based systems, FIN scans are next to useless. UDP scanning is by nature very unreliable and time consuming. In general you'll find that doing full 65K port scans are not going to be fast unless you are on a very fast network. Let's look at some example firewall output: TCP scan against the first 1024 ports (nmap -sT -P0 -p 1-1024 Host-B) to a DMZ web server from the outside. The firewall policy is flawed, so it's not really blocking things as it should. Port State Service 21/tcp open ftp 22/tcp open ssh 25/tcp open smtp 53/tcp open domain 80/tcp open http 106/tcp open pop3pw 110/tcp open pop-3 143/tcp open imap2 443/tcp open https 465/tcp open smtps 466/tcp open digital-vrc 505/tcp open mailbox-lm 993/tcp open imaps 995/tcp open pop3s Now what's interesting about this output is that the targeted system is actually running one more service, RPC Bind (portmapper, port 111), but is using local iptables/netfilter firewall rules to disallow access to that port (using REJECT, which returns an ICMP message). Let's see that output again, but using a SYN scan (nmap -sS -P0 -p 1-1024 Host-B): Port State Service 21/tcp open ftp 22/tcp open ssh 25/tcp open smtp 53/tcp open domain 80/tcp open http 106/tcp open pop3pw 110/tcp open pop-3 111/tcp filtered sunrpc 143/tcp open imap2 443/tcp open https 465/tcp open smtps 466/tcp open digital-vrc 505/tcp open mailbox-lm 993/tcp open imaps 995/tcp open pop3s Note that this time the SYN scan picked up the filtered port. This demonstrates the value of varying your scanning methods. TCP scans are by far the most accurate in terms of "can you get to the service," but SYN scans can show you more information. A FIN scan returns similar results (nmap -sF -P0 -p 1-1024 Host-B): Port State Service 21/tcp open ftp 22/tcp open ssh 25/tcp open smtp 53/tcp open domain 80/tcp open http 106/tcp open pop3pw 110/tcp open pop-3 111/tcp filtered sunrpc 143/tcp open imap2 443/tcp open https 465/tcp open smtps 466/tcp open digital-vrc 505/tcp open mailbox-lm 993/tcp open imaps 995/tcp open pop3s However, let's try these same scans on a Windows PC, Host-C, first using a TCP scan(nmap -sS -P0 -p 1-1024 Host-C). PORT STATE SERVICE 135/tcp open msrpc 139/tcp open netbios-ssn 445/tcp open microsoft-ds SYN scan (nmap -sS -P0 1-1024 Host-C): PORT STATE SERVICE 135/tcp open msrpc 139/tcp open netbios-ssn 445/tcp open microsoft-ds And finally a FIN scan (nmap -sF -P0 1-1024 Host-C) PORT STATE SERVICE As you can see, this scan returns no data on a Microsoft OS. We also have seen FIN scans return all ports as being open or sometimes just a few random ones. If you doubt the results, scan things multiple times. This doesn't mean that FIN scans are useless in terms of testingquite the opposite. You might have configured your firewall to test for impossible TCP combinations, a FIN packet coming before a SYN packet for example. The iplog/nmap method is a very fast, reusable diagnostic procedure for testing all sorts of rules (the last thing you want to do is keep writing custom tools for custom rules!). For the most accurate results, it's best if you can get on the systems and see what services those systems are running, first-hand, using the netstat command or a local nmap scan (we recommend both). Here is the output of the same system, Host-B just described, using netstat: [root@Host-B root]# netstat -an tcp 0 0 0.0.0.0:21 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:106 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:110 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:143 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:465 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:466 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:505 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:993 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:995 0.0.0.0:* LISTEN Note A useful addition to this is the netstat -pan command, which will show you the process name associated with each port. |
|
