May the source be with you, but remember the KISS principle ;-)
Home Switchboard Unix Administration Red Hat TCP/IP Networks Neoliberalism Toxic Managers
(slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and  bastardization of classic Unix

Usage of Nmap for Network Worm Detection

News See Also Recommended Books Recommended Links Examples Reference

(os fingeprinting)

Verbose mode
Version detection
-oN <logfilename>
(writing to log)
-sO IP protocol scans -sU UDP scans
Target Specification History Humor Etc

Nmap is a one of the best generic network scanners. It is a standard package on RHEL and Suse. You just need to install it from the repository. It supports

Most options are not that useful for a regular network of sysadmin and represents esoteric "art for the sake of art" exploration of the limits of TCP/IP protocol ;-). But a few capabilities are very practical.

The simplest way to use nmap is with a single IP and no parameters. In this case list of open ports will be returned for the particular host. It is very useful in case for example you can't connect to the host. You well instantly see if the port is open or not.   For a single host probably the following set of options makes sense:

nmap -v

Another very useful feature is version detection (-sV) and OS fingerprinting (-O):

nmap -v -sV -O

The most typical usage of nmap for subnets is to scan subnet to find out what types of machines are present. You need to be very careful with specifying subnet or you might get into trouble. Here is example where range is specified explicitly as 10-254

nmap -v -O -oN static_segment '10.194.153-154.100-254'

you can also use -sV option like in case of a single target but this will make the process much slower (the option takes a lot of time):

nmap -v -O -sV -oN static_segment '10.194.153-154.100-254'

Nmap also supports the mask notation, for example: ''.

For determining the infected by network worm hosts on the network you need to supply the ports that the worm is listening to. For example, for Zotob worm you can scan ports (445,8888, and 33333). For example :

nmap -p 445,8888,33333

Here port 445 is used to identify Windows PC but that can be done separately as preprocessing option (in this case the first scan is scan for Windows computers and the second more in-depth scan for the interesting ports on those; that trick can save some time especially on large subnets.

Nmap also has notation which lets you specify an IP address using lists/ranges for each element. Thus you can scan the whole class 'B' network 128.210.*.* by specifying '128.210.*.*' or '128.210.0-255.0-255'

If you need to use asterisks ('*'), remember that most shells require you to escape them with back slashes

Rather than focus on a specific IP range, it is sometimes interesting to scan a small sample from each slice. In this case you need first to generate the subset of addresses and then feed the list to nmap in the file via option -iL:

-iL inputfilename Reads target specifications from the file specified RATHER than from the command line. The file should contain a list of host or network expressions separated by spaces, tabs, or newlines. Use a hyphen (-) as inputfilename if you want nmap to read host expressions from stdin (like at the end of a pipe). See the section target specification for more information on the expressions you fill the file with.

If you need to scan large subnet in a pretty complex way the first useful step is to cut number of hosts that you will subject to full interrogation. The first step in cutting the number of hosts is to generate list of hosts that are up. It can be done with -PA [portlist] option

Instead of sending ICMP echo request packets and waiting for a response, we spew out TCP ACK packets throughout the target network (or to a single machine) and then wait for responses to trickle back. Hosts that are up should respond with a RST. This option preserves the efficiency of only scanning hosts that are up while still allowing you to scan networks/hosts that block ping pack- ets. For non root UNIX users, we use connect() and thus a SYN is actually being sent. To set the destination ports of the probe packets use -PA<port1>[,port2][...]. The default port is 80, since this port is often not filtered out. Note that this option now accepts multiple, comma-separated port numbers.

Another useful option provides random sampling of the segment:

Selection and syntax of options is pretty unusual and it is difficult to memorize  Nmap uses  both one letter options and two letter options with s and o as escape characters (actually, this is not a bad idea if you think about it).

 Important options include


  1. nmap -v

    This option scans all reserved TCP ports on the machine . The -v means turn on verbose mode. You can add this option to other examples too.
  2. nmap -O

    Launches a scan against each machine that is up out of the 255 machines on class 'C' where resides. It also tries to determine what operating system is running on each host that is up and running.
  3. nmap -sX -p 22,53,110,143,4564 128.210.*.1-127

    Sends an Xmas tree scan to the first half of each of the 255 possible 8 bit subnets in the 128.210 class 'B' address space. We are testing whether the systems run sshd, DNS, pop3d, imapd, or port 4564. Note that Xmas scan doesn't work on Microsoft boxes due to their deficient TCP stack. Same goes with CISCO, IRIX, HP/UX, and BSDI boxes.
  4. Get info about remote host ports and OS detection
    nmap -sS -P0 -sV -O <target>

    Where < target > may be a single IP, a hostname or a subnet

    • -sS TCP SYN scanning (also known as half-open, or stealth scanning)
    • -P0 option allows you to switch off ICMP pings.
    • -sV option enables version detection
    • -O flag attempt to identify the remote operating system

    Other option:

    • -A option enables both OS fingerprinting and version detection
    • -v use -v twice for more verbosity.
    nmap -sS -P0 -A -v < target >
  5. Get list of servers with a specific port open

    nmap -sT -p 80 -oG - 192.168.1.* | grep open

    Change the -p argument for the port number. See "man nmap" for different ways to specify address ranges.

  6. Find all active IP addresses in a network

    nmap -sP 192.168.0.*

    There are several other options. This one is plain and simple. Another option is:

    nmap -sP

    for specific  subnets

  7. Ping a range of IP addresses

    nmap -sP

    nmap accepts a wide variety of addressing notation, multiple targets/ranges, etc.

    5) Find unused IPs on a given subnet

    nmap -T4 -sP && egrep "00:00:00:00:00:00" /proc/net/arp

    6) Scan for the Conficker virus on your LAN ect.

    nmap -PN -T4 -p139,445 -n -v -script=smb-check-vulns -script-args safe=1

    replace with the IP’s you want to check.

    7) Scan Network for Rogue APs.

    nmap -A -p1-85,113,443,8080-8100 -T4 -min-hostgroup 50 -max-rtt-timeout 2000 -initial-rtt-timeout 300 -max-retries 3 -host-timeout 20m -max-scan-delay 1000 -oA wapscan

    I’ve used this scan to successfully find many rogue APs on a very, very large network.

  8. Use a decoy while scanning ports to avoid getting caught by the sys admin

    sudo nmap -sS -D

    Scan for open ports on the target device/computer ( while setting up a decoy address ( This will show the decoy ip address instead of your ip in targets security logs. Decoy address needs to be alive. Check the targets security log at /var/log/secure to make sure it worked.

  9. List of reverse DNS records for a subnet

    nmap -R -sL | awk '{if($3=="not")print"("$2") no PTR";else print$3" is "$2}' | grep '('

    This command uses nmap to perform reverse DNS lookups on a subnet. It produces a list of IP addresses with the corresponding PTR record for a given subnet. You can enter the subnet in CDIR notation (i.e. /24 for a Class C)). You could add "-dns-servers x.x.x.x" after the "-sL" if you need the lookups to be performed on a specific DNS server. On some installations nmap needs sudo I believe. Also I hope awk is standard on most distros.
  10. How Many Linux And Windows Devices Are On Your Network?
    sudo nmap -F -O | grep "Running: " > /tmp/os; echo "$(cat /tmp/os | grep Linux | wc -l) Linux device(s)"; echo "$(cat /tmp/os | grep Windows | wc -l) Window(s) devices"

Top Visited
Past week
Past month


Old News ;-)

[Feb 01, 2020] Basic network troubleshooting in Linux with nmap Enable Sysadmin

Feb 01, 2020 |

Determine this host's OS with the -O switch:

$ sudo nmap -O <Your-IP>

The results look like this:


[ You might also like: Six practical use cases for Nmap ]

Then, run the following to check the common 2000 ports, which handle the common TCP and UDP services. Here, -Pn is used to skip the ping scan after assuming that the host is up:

$ sudo nmap -sS -sU -PN <Your-IP>

The results look like this:


Note: The -Pn combo is also useful for checking if the host firewall is blocking ICMP requests or not.

Also, as an extension to the above command, if you need to scan all ports instead of only the 2000 ports, you can use the following to scan ports from 1-66535:

$ sudo nmap -sS -sU -PN -p 1-65535 <Your-IP>

The results look like this:


You can also scan only for TCP ports (default 1000) by using the following:

$ sudo nmap -sT <Your-IP>

The results look like this:


Now, after all of these checks, you can also perform the "all" aggressive scans with the -A option, which tells Nmap to perform OS and version checking using -T4 as a timing template that tells Nmap how fast to perform this scan (see the Nmap man page for more information on timing templates):

$ sudo nmap -A -T4 <Your-IP>

The results look like this, and are shown here in two parts:


There you go. These are the most common and useful Nmap commands. Together, they provide sufficient network, OS, and open port information, which is helpful in troubleshooting. Feel free to comment with your preferred Nmap commands as well.

[ Readers also liked: My 5 favorite Linux sysadmin tools ]

Related Stories:

[Dec 20, 2015] Nmap Command For Network Admins by

Dec 15, 2015 | kali linux tutorial

Read list of hosts/networks from a file (IPv4)

The -iL option allows you to read the list of target systems using a text file. This is useful to scan a large number of hosts/networks. Create a text file as follows: Your Text file should look like this ( /tmp/test.txt )

nmap -iL /tmp/test.txt

Display the reason a port is in a particular state:

nmap --reason  

Check if a host/network is protected by a firewall

nmap -sA  

Scan a network and find out which servers and devices are up and running This is known as host discovery or ping scan:

nmap -sP

Show host interfaces and routes

This is useful for debugging (ip command or route command or netstat command like output using nmap)

nmap --iflist

[Dec 09, 2015] 10 Practical Examples Of Linux 'nmap' Command


Fast Scan

You can use this scan to check the the most common 100 ports.
$ nmap -T4 -F
Starting Nmap 6.01 ( ) at 2015-06-23 10:49 EST
Nmap scan report for
Host is up (0.00047s latency).
Not shown: 96 closed ports
88/tcp open kerberos-sec
139/tcp open netbios-ssn
445/tcp open microsoft-ds
631/tcp open ipp

[Dec 09, 2015] 29 Practical Examples of NMAP Commands for Linux System-Network Administrators

Scan Multiple Servers using last octet of IP address

You can perform scans on multiple IP address by simple specifying last octet of IP address. For example, here I performing a scan on IP addresses, and

 [root@server1 ~]# nmap,102,103 
... ... ...

Scan list of Hosts from a File

If you have more hosts to scan and all host details are written in a file , you can directly ask nmap to read that file and perform scans. Let's see how to do that. Create a text file called "nmaptest.txt" and define all the IP addresses or hostname of the server that you want to do a scan.

[root@server1 ~]# cat > nmaptest.txt
Next, run the following command with "iL" option with nmap command to scan all listed IP address in the file. [root@server1 ~]#
nmap -iL nmaptest.txt

Scan an IP Address Range

You can specify an IP range while performing scan with Nmap.

[root@server1 ~]# nmap
Scan OS information and Traceroute

With Nmap, you can detect which OS and version is running on the remote host. To enable OS & version detection, script scanning and traceroute, we can use "-A" option with NMAP.

[root@server1 ~]# nmap -A
Perform a Fast Scan

You can perform a fast scan with "-F" option to scans for the ports listed in the nmap-services files and leaves all other ports.

[root@server1 ~]# nmap -F
Print Host interfaces and Routes

You can find out host interface and route information with nmap by using "–iflist" option.

[root@server1 ~]# nmap --iflist

[May 29, 2012] Nmap 6 Release Notes

May 21, 2012 | Nmap

The Nmap Project is pleased to announce the immediate, free availability of the Nmap Security Scanner version 6.00 from It is the product of almost three years of work, 3,924 code commits, and more than a dozen point releases since the big Nmap 5 release in July 2009. Nmap 6 includes a more powerful Nmap Scripting Engine, 289 new scripts, better web scanning, full IPv6 support, the Nping packet prober, faster scans, and much more!

We recommend that all current users upgrade.


  1. About Nmap
  2. Top 6 Improvements in Nmap 6
  3. Press
  4. Screen Shots
  5. Detailed Improvements
  6. Moving Forward (Future Plans)
  7. Acknowledgments
  8. Download and updates
About Nmap

Nmap ("Network Mapper") is a free and open source (license) utility for network discovery and security auditing. Many systems and network administrators also find it useful for network inventory, managing service upgrade schedules, monitoring host or service uptime, and many other tasks. Nmap uses raw IP packets in novel ways to determine what hosts are available on the network, what services (application name and version) those hosts are offering, what operating systems (and OS versions) they are running, what type of packet filters/firewalls are in use, and dozens of other characteristics. It was designed to rapidly scan large networks, but works fine against single hosts. Nmap runs on all major computer operating systems, and official binary packages are available for Linux, Windows, and Mac OS X. In addition to the classic command-line Nmap executable, the Nmap suite includes an advanced GUI and results viewer (Zenmap), a flexible data transfer, redirection, and debugging tool (Ncat), a utility for comparing scan results (Ndiff), and a packet generation and response analysis tool (Nping).

Nmap was named "Security Product of the Year" by Linux Journal, Info World, LinuxQuestions.Org, and Codetalker Digest. It was even featured in a dozen movies, including The Matrix Reloaded, The Bourne Ultimatum. Girl with the Dragon Tattoo, and Die Hard 4. Nmap was released to the public in 1997 and has earned the trust of millions of users.

As free software, we don't have any sort of advertising budget. So please spread the word that Nmap 6 is now available!

Top 6 Improvements in Nmap 6

Before we go into the detailed changes, here are the top 6 improvements in Nmap 6:

1. NSE Enhanced
The Nmap Scripting Engine (NSE) has exploded in popularity and capabilities. This modular system allows users to automate a wide variety of networking tasks, from querying network applications for configuration information to vulnerability detection and advanced host discovery. The script count has grown from 59 in Nmap 5 to 348 in Nmap 6, and all of them are documented and categorized in our NSE Documentation Portal. The underlying NSE infrastructure has improved dramatically as well. [More details]
2. Better Web Scanning
As the Internet has grown more web-centric, Nmap has developed web scanning capabilities to keep pace. When Nmap was first released in 1997, most of the network services offered by a server listened on individual TCP or UDP ports and could be found with a simple port scan. Now, applications are just as commonly accessed via URL path instead, all sharing a web server listening on a single port. Nmap now includes many techniques for enumerating those applications, as well as performing a wide variety of other HTTP tasks, from web site spidering to brute force authentication cracking. Technologies such as SSL encryption, HTTP pipelining, and caching mechanisms are well supported. [More details]
3. Full IPv6 Support
Given the exhaustion of available IPv4 addresses, the Internet community is trying to move to IPv6. Nmap has been a leader in the transition, offering basic IPv6 support since 2002. But basic support isn't enough, so we spent many months ensuring that Nmap version 6 contains full support for IP version 6. And we released it just in time for the World IPv6 Launch.

We've created a new IPv6 OS detection system, advanced host discovery, raw-packet IPv6 port scanning, and many NSE scripts for IPv6-related protocols. It's easy to use too-just specify the -6 argument along with IPv6 target IP addresses or DNS records. In addition, all of our web sites are now accessible via IPv6. For example, can be found at 2600:3c01::f03c:91ff:fe96:967c. [More details]

4. New Nping Tool
The newest member of the Nmap suite of networking and security tools is Nping, an open source tool for network packet generation, response analysis and response time measurement. Nping can generate network packets for a wide range of protocols, allowing full control over protocol headers. While Nping can be used as a simple ping utility to detect active hosts, it can also be used as a raw packet generator for network stack stress testing, ARP poisoning, Denial of Service attacks, route tracing, etc. Nping's novel echo mode lets users see how packets change in transit between the source and destination hosts. That's a great way to understand firewall rules, detect packet corruption, and more. [More details]
5. Better Zenmap GUI & results viewer
While Nmap started out as a command-line tool and many (possibly most) users still use it that way, we've also developed an enhanced GUI and results viewer named Zenmap. One addition since Nmap 5 is a "filter hosts" feature which allows you to see only the hosts which match your criteria (e.g. Linux boxes, hosts running Apache, etc.) We've also localized the GUI to support five languages besides English. A new script selection interface helps you find and execute Nmap NSE scripts. It even tells you what arguments each script supports. [More details]
6. Faster scans
In Nmap's 15-year history, performance has always been a top priority. Whether scanning one target or a million, users want scans to run as fast as possible without sacrificing accuracy. Since Nmap 5 we've rewritten the traceroute system for higher performance and increased the allowed parallelism of the Nmap Scripting Engine and version detection subsystems. We also performed an intense memory audit which reduced peak consumption during our benchmark scan by 90%. We made many improvements to Zenmap data structures and algorithms as well so that it can now handle large enterprise scans with ease. [More details]

[Jun 07, 2011] sock_raw by ithilgore

20 September 2010

Abusing Network Protocols

In my presentation "Abusing Network Protocols" that I gave at athcon, I demonstrated a new stealthy port scanning attack that is made possible by abusing XMPP. The technique uses a "zombie" host (that can be anyone in your [most probably fake] friend/contact list) and some timing calculations in order to conduct a portscan through that proxy to any target. The IP address is never revealed to the scanned victim, the same way the famous idle/zombie scan, discovered by antirez, works. I just uploaded the whitepaper on Abusing Network Protocls and the relevant presentation slides on this site.

-- ithilgore, 9 June 2010

Athcon 2010

I recently gave a presentation on "Abusing Network Protocols" at athcon, a new security conference taking place in Athens, Greece. The presentation subjects ranged from BNF/general fuzzing, context-keyed payload encoding, SIP/VoIP exploitation to less technical ones like Mobile Privacy with Tor and CyberWar. A variety of security related subjects for a variety of audiences. I have been to various conferences these past few years but never got to comment on the experiences. This time, since this is also a conference in which I participated as a speaker, I will make an exception.

Athcon's presentation schedule went like this:

[Jun 07, 2011] Port knocking module & nmap payload patch

I 've added some new material to the site:

1) pknf - pknf is a loadable kernel module for linux, which implements a port knocking mechanism using netfilter hooks. Nf hooks was a choice over other methods since, although lower level and thus less portable, it is a stealthier and perhaps more rootkit-friendly way.

2) Nmap payload patch - this patch introduces a new option for the latest version of Nmap (4.68 as of now), which lets you define your own payload for Nmap's probes. Until now, you could only insert random data by defining the --data-length option. I wrote it, after some user on nmap-dev asked for such functionality. Of course, as I noted there and as Michael Pattrick later mentioned here, payload handling is something NSE is more suitable for. Nevertheless, it provides a nifty solution for someone who needs a quic potocol-agnostic way to manipulate extra payloads, since it uses the existing build_<protocol>_raw (where <protocol> = tcp,udp,icmp etc) functions defined in of Nmap source code. You can find the patch here.

There were some discussions lately about the daunting task of scanning the whole internet. Fyodor presented at Black Hat and Defcon 2008 some interesting results based on his own findings from scanning most part of the internet range -

Another thought-provoking article comes from thc - Port Scanning the Internet.

-- ithilgore, 25 August 2008

[Jul 22, 2009] SECURITY: Nmap 5.00 Released

Jul 22, 2009 |

"Insecure.Org is pleased to announce the immediate, free availability of the Nmap Security Scanner version 5.00 from . This is the first stable release since 4.76 (last September), and the first major release since the 4.50 release in 2007. Dozens of development releases led up to this."

Hosting Reviews at - Blog

GoDaddy Suspends Domains on Request
  • Posted by DavidJ on Friday January 26, 2007
  • In what is widely being touted as a massive over-reaction, GoDaddy suspended one of their client's domains earlier this week - Fyodor Vaskovich awoke on Wednesday with his domain suspended entirely without warning. Fyodor, creator of the popular NMAP security scanner was surprised to find his site completely down as a result of the suspension.

    The domain in question - - is a popular mailing list archive site that hosts over 250,000 pages of content. GoDaddy received demands from MySpace to remove the content due to several of the pages containing user account details for MySpace.

    GoDaddy promptly complied - and removed access to the domain.

    Fyodor posted a lengthy statement regarding the situation on the site after it returned to service:

    "I called GoDaddy several times, and all three support people I spoke with said that the abuse department doesn't take calls.

    They said I had email [email protected] (which I had already done 3 times) and that I could then expect a response "within 1 or two business days". Given that tens of thousands of people use SecLists.Org every day, I didn't take that well."

    GoDaddy which claims to have more than 17.3 million domains under it's management, states that it holds it's self-proclaimed #1 spot by "delivering the highest quality customer service, and by always appreciating and listening to its customers!" ... (!).

    Tests of Tiny Private Firewall 2

    Key criteria in choosing a personnal firewall are :

    How did we test firewall/intrusion detection effectiveness?

    1. Ping and accessing shares to and from the test host.
    2. A powerful, well known "remote control" Trojan (Netbus Pro v2.1 [2]) was installed on the system on a nonstandard port (to make detection more difficult), the Netbus server started and attempts made to connect from a remote system.
    3. An nmap [1] scan was run, to check that incoming ports were effectively blocked. With another local PC launching nmaps againts the test PC and the following options (nmap -v -sT -P0 -O ip_address ).
    4. An nmap [1] scan was run, to check that incoming ports were effectively blocked. With another local PC launching nmaps againts the test PC and the following options (nmap -v -sP -P0 -O ip_address ).
    5. A test using Leaktest [4] was done.
    6. We checked the system ressource usage of the firewall during the tests (just in case).
    7. We tried to launch a modified (by us) release of IEXPLORE.EXE (C:\Program Files\Internet Explorer\IEXPLORE.EXE ) to check if the firewall detects the problem.

    NB : These tests do not pretend to be exhaustives. By the way the aim is to be sure that the tested software offers at least expected security (or not) for a personnal use (do not compare this to professional use).

    Jump to the test results.

    B - Overview

    The Tiny Personnal Firewall 2.0.12 [3] is full of interesting features :

    C - Prices

    Free for personnal (home) use.

    D - Security Effectiveness

    1. Ping: Impossible , unless you authorize it by yourself. This is a good result.
    2. The Netbus server: Tiny Personnal Firewall 2 does not detect the Netbus server when started, but unless you authorize it, it's impossible to connect through it. The result of this test is good.
    3. An nmap scan without Tiny Personnal Firewall 2 (on Win 2000 OS SP1 with a "standard" installation, it means NetBios active and so on) :

      $ nmap -v -sT -P0 -O ip_address ess

      Starting nmap V. 2.53 by [email protected] ( )
      Initiating TCP connect() scan against (ip_address )
      Adding TCP port 445 (state open).
      Adding TCP port 135 (state open).
      Adding TCP port 1025 (state open).
      Adding TCP port 913 (state open).
      Adding TCP port 139 (state open).

      The TCP connect scan took 0 seconds to scan 1523 ports.

      For OSScan assuming that port 135 is open and port 1 is closed and neither are firewalled

      Interesting ports on (ip_address ):
      (The 1518 ports scanned but not shown below are in state: closed)
      Port State Service
      135/tcp open loc-srv
      139/tcp open netbios-ssn
      445/tcp open microsoft-ds
      913/tcp open unknown
      1025/tcp open listen

      TCP Sequence Prediction: Class=random positive increments
      Difficulty=6634 (Worthy challenge)

      Sequence numbers: 747E9CE8 747F63FC 74800BF5 7480E3FE 7481BC4F 7482B3B2

      Remote operating system guess: Windows 2000 RC1 through final release

      Nmap run completed -- 1 IP address (1 host up) scanned in 10 seconds

      Gloups : you'd better have a firewall installed :+) !!!

      An nmap TCP scan with Tiny Personnal Firewall 2 (on Win 2000 SP1 OS with a "standard" installation, it means NetBios active and so on) with options set to "Ask me first" or "Don't bother me" do give some events registered in the log (unless you specify it) but blocks the traffic, which is finally a good result :

      $ nmap -v -sT -P0 -O ip_address

      Starting nmap V. 2.53 by [email protected] ( )
      Initiating TCP connect() scan against (ip_address )
      The TCP connect scan took 2334 seconds to scan 1523 ports.
      Warning: No TCP ports found open on this machine, OS detection will be MUCH less reliable
      Interesting ports on (ip_address ):
      (The 1522 ports scanned but not shown below are in state: filtered)
      Port State Service
      1032/tcp closed iad3

      Too many fingerprints match this host for me to give an accurate OS guess
      TCP/IP fingerprint:

      Nmap run completed -- 1 IP address (1 host up) scanned in 2652 seconds

      This means that with Tiny Personnal Firewall active ports looks unexistant and access attempts are logged. This is a good result.

      Here I don't understand why they let the 1032 port seemed existant . This scan is logged in the Firewall Log as NMAP blocked attempt ... strange because not any rules talks about NMAP. So there's an internal rule built in that does this. I don't think it's a good idea to hide rules...

    4. An nmap UDP scan with Tiny Personnal Firewall 2 (on Win 2000 SP1 OS with a "standard" installation, it means NetBios active and so on) doesn't give events registered in the log but blocks the attempts which is a good result :

      $ nmap -v -sU -P0 ip_address

      Starting nmap V. 2.53 by [email protected] ( )
      Initiating FIN,NULL, UDP, or Xmas stealth scan against (ip_address )
      The UDP or stealth FIN/NULL/XMAS scan took 90 seconds to scan 1448 ports.
      (no udp responses received -- assuming all ports filtered)
      All 1448 scanned ports on (ip_address ) are: filtered

      Nmap run completed -- 1 IP address (1 host up) scanned in 1755 seconds

      This means that the security seems efficient for UDP.

    5. The Leaktest : Tiny Personnal Firewall 2 doesn't detect the launch of Leaktest and as for netbus , if you don't allow it it won't be able to connect. The result of this test is good.
    6. Tiny Personnal Firewall 2 , in normal operations uses up to 1 % max. Memory usage is 5 MB, up to 5.6 MB peek.
    7. The substitution test : (you can do it by yourself for example : you replace Iexplorer.exe with leaktest.exe - yes this one - by renaming the last one and launch it). The result is Tiny Personnal Firewall 2 allow the trojan horse to connect... the result of this test is bad. I feel surprise about the result of this test because even with MD5 checksum activated, Tiny Personnal Firewall 2 didn't block it... very strange... I hope MD5 is not done on the application name !
    E - Advantages
    1. Tiny Personnal Firewall can be configured to block all traffic.
    2. You can specified ports associated to an allowed application (it won't stop the substitution test, but it's nice).
    3. Allows to warn through email.
    F - Disadvantages
    1. Tiny Personnal Firewall does not provided description for standard services such as DHCP for example.
    2. MD5 checksum does not work properly
    3. Not enough events logged.
    G - Suggested improvements H - Summary

    A very good firewall with a very simple GUI but really efficient.

    Evaluation :

    Total : 13.25 / 20

    Note : the result may be modified with the release , and when adding new criteria or re-evaluating their weight or their content.

    I - References

    1. Nmap - Network mapper, a really efficient tool to check networks
    2. Netbus Pro - Remote control program often used as an attack tool to control remote PCs.
    3. Tiny Personnal Firewall 2
    4. Leaktest - Small testing software written by Steve Gibson to check firewalls. It makes a simple TCP (ftp) connexion that simulate sennding of personnal content, which can also be used to take remote controle in reverse mode (arg).

    [ Sep 20, 2003] Nmap 3.45 includes an advanced version detection system.

    Now instead of using a simple nmap-services table lookup to determine a port's likely purpose, Nmap will (if asked) interrogate that TCP or UDP port to determine what service is really listening.

    In many cases it can determine the application name and version number as well. Obstacles like SSL encryption and Sun RPC are no threat, as Nmap can connect using OpenSSL (if available) as well as utilizing Nmap's RPC bruteforcer. IPv6 is also supported.

    You can read our new version detection paper for the details and examples, or just download the latest version and try it out here.

    Simply add "-sV" to your normal scan command-line options.

    Nmap Development Nmap usage stats

    [Feb 18, 2003] NmapScanner version 0.5 now available

    Nmap::Scanner is a perl module set that captures nmap output as a set of perl objects.
    Nmap::Scanner is a perl module set that captures nmap output as a set of perl objects.

    Version 0.5 should be significantly more stable than the previous two versions as I am now parsing the XML output from nmap instead of the "normal" output.

    I had to make some fairly major object model changes in order to use the XML format. The scripts in the examples/ directory show pretty clearly the changes that were made as do the perldocs in each object module.

    In previous releases I was attempting to translate all nmap switches into method calls. This was both tedious and maintenance unfriendly as new features are frequently added to nmap. The current
    version provides a much easier way to start a scan:

    use Nmap::Scanner;
    my $scanner = Nmap::Scanner->new();
    my $results = $scanner->scan('-sS -p 1-1024 -0 -P80 localhost');

    The next release will most likely not have the option methods .. e.g.

    for -sS .. $scan->tcp_syn_scan()

    As it means developers need to learn my translation of the short options which is neither fair nor useful ;).

    Additionally, I moved all of the Util classes into the examples/ directory except for as they are not core to the parsing functionality. Only Nmap::Scanner::Util::BannerScanner remains as a base class which can be used to create banner scanners easily.

    Also, in order to get the most out of this release you should use nmap version 3.10ALPHA4 or newer as I had to contribute a few small XML output patches to nmap itself in order to be able to capture port found events using the XML output of nmap.

    Older versions (as far back as 2.54BETA32) should work with this module, but the port found events will not not be seen.

    The latest distribution can be found here:

    I hope those of you that found the previous releases useful will also find this one useful, and more stable.

    As always, comments/feedback/criticisms are welcome.


    nmap -at- webwizarddesign -dot- com

    For help using this (nmap-dev) mailing list, send a blank email to . List run by ezmlm-idx (
    Received on Feb 18 2003

    Recommended Links

    Google matched content

    Softpanorama Recommended

    Top articles


    Recommended Articles

    Nmap addon tool -- nlog

    Alternate Download:

    Nlog is a set of perl scripts that allow you to search through your Nmap 2.x scan logs. Included is a conversion script and a complete CGI interface with 4 extensions and support for more. From your web browser you can search for all hosts with any given port open, operating system, sequence index, or IP address and query common services through the extension scripts.


    You can also run nmap -h for a quick reference page listing all the options.


    -sS TCP SYN scan

    This technique is often referred to as "half-open" scanning, because you don’t open a full TCP connection. You send a SYN packet, as if you are going to open a real connection and you wait for a response. A SYN|ACK indicates the port is listen- ing. A RST is indicative of a non-listener. If a SYN|ACK is received, a RST is immediately sent to tear down the connection (actually our OS kernel does this for us). The primary advantage to this scanning technique is that fewer sites will log it. Unfortunately you need root privileges to build these custom SYN packets. This is the default scan type for privileged users.

    -sT TCP connect() scan

    This is the most basic form of TCP scanning. The connect() system call provided by your operating system is used to open a connection to every interesting port on the machine. If the port is listening, connect() will succeed, oth- erwise the port isn’t reachable. One strong advantage to this technique is that you don’t need any special privileges. Any user on most UNIX boxes is free to use this call.

    This sort of scan is easily detectable as target host logs will show a bunch of connection and error messages for the services which accept() the connection just to have it immediately shut- down. This is the default scan type for unprivileged users.

    -sF -sX -sN Stealth FIN, Xmas Tree, or Null scan modes

    There are times when even SYN scanning isn’t clandestine enough. Some firewalls and packet filters watch for SYNs to restricted ports, and programs like Synlogger and Courtney are available to detect these scans. These advanced scans, on the other hand, may be able to pass through unmolested.

    The idea is that closed ports are required to reply to your probe packet with an RST, while open ports must ignore the pack- ets in question (see RFC 793 pp 64). The FIN scan uses a bare (surprise) FIN packet as the probe, while the Xmas tree scan turns on the FIN, URG, and PUSH flags. The Null scan turns off all flags. Unfortunately Microsoft (like usual) decided to com- pletely ignore the standard and do things their own way. Thus this scan type will not work against systems running Win- dows95/NT. On the positive side, this is a good way to distin- guish between the two platforms. If the scan finds open ports, you know the machine is not a Windows box. If a -sF,-sX,or -sN scan shows all ports closed, yet a SYN (-sS) scan shows ports being opened, you are probably looking at a Windows box. This is less useful now that nmap has proper OS detection built in. There are also a few other systems that are broken in the same way Windows is. They include Cisco, BSDI, HP/UX, MVS, and IRIX. All of the above send resets from the open ports when they should just drop the packet.

    -sP Ping scanning

    Sometimes you only want to know which hosts on a network are up. Nmap can do this by sending ICMP echo request packets to every IP address on the networks you specify. Hosts that respond are up. Unfortunately, some sites such as block echo request packets. Thus nmap can also send a TCP ack packet to (by default) port 80. If we get an RST back, that machine is up. A third technique involves sending a SYN packet and waiting for a RST or a SYN/ACK. For non-root users, a connect() method is used.

    By default (for root users), nmap uses both the ICMP and ACK techniques in parallel. You can change the -P option described later.

    Note that pinging is done by default anyway, and only hosts that respond are scanned. Only use this option if you wish to ping sweep without doing any actual port scans.

    -sV Version detection

    Afer TCP and/or UDP ports are discovered using one of the other scan methods, version detection communi- cates with those ports to try and determine more about what is actually running.

    A file called nmap-service-probes is used to determine the best probes for detecting various services and the match strings to expect. Nmap tries to determine the service protocol (e.g. ftp, ssh, telnet, http), the application name (e.g. ISC Bind, Apache httpd, Solaris telnetd), the version num- ber, and sometimes miscellaneous details like whether an X server is open to connections or the SSH protocol version).

    If Nmap was compiled with OpenSSL support, it will connect to SSL servers to deduce the service listening behind the encryption.

    When RPC services are discovered, the Nmap RPC grinder is used to determine the RPC program and version numbers. Some UDP ports are left in the "open|filtered" state after a UDP scan is unable to determine whether the port is open or filtered. Ver- sion detection will try to elicit a response from these ports (just as it does with open ports), and change the state to open if it succeeds.

    Note that the Nmap -A option also enables this feature. For a much more detailed description of Nmap service detection, read our paper at .

    There is a related --version_trace option which causes Nmap to print out extensive debugging info about what version scanning is doing (this is a subset of what you would get with --packet_trace).

    -sU UDP scans

    This method is used to determine which UDP (User Datagram Protocol, RFC 768) ports are open on a host. The tech- nique is to send 0 byte UDP packets to each port on the target machine. If we receive an ICMP port unreachable message, then the port is closed. If a UDP response is received to the probe (unusual), the port is open. If we get no response at all, the state is "open|filtered", meaning that the port is either open or packet filters are blocking the communication. Versions scan (-sV) can be used to help differentiate the truly open ports from the filtered ones.

    Some people think UDP scanning is pointless. I usually remind them of the Solaris rpcbind hole. Rpcbind can be found hiding on an undocumented UDP port somewhere above 32770. So it doesn’t matter that 111 is blocked by the firewall. But can you find which of the more than 30,000 high ports it is listening on? With a UDP scanner you can! There is also the cDc Back Orifice backdoor program which hides on a configurable UDP port on Win- dows machines. Not to mention the many commonly vulnerable ser- vices that utilize UDP such as snmp, tftp, NFS, etc.

    Unfortunately UDP scanning is sometimes painfully slow since most hosts implement a suggestion in RFC 1812 (section of limiting the ICMP error message rate. For example, the Linux kernel (in net/ipv4/icmp.h) limits destination unreachable mes- sage generation to 80 per 4 seconds, with a 1/4 second penalty if that is exceeded. Solaris has much more strict limits (about 2 messages per second) and thus takes even longer to scan. nmap detects this rate limiting and slows down accordingly, rather than flood the network with useless packets that will be ignored by the target machine.

    As is typical, Microsoft ignored the suggestion of the RFC and does not seem to do any rate limiting at all on Win95 and NT machines. Thus we can scan all 65K ports of a Windows machine very quickly. Whoop!

    -sO IP protocol scans

    This method is used to determine which IP protocols are supported on a host. The technique is to send raw IP packets without any further protocol header to each specified protocol on the target machine. If we receive an ICMP protocol unreachable message, then the protocol is not in use. Otherwise we assume it is open. Note that some hosts (AIX, HP-UX, Digital UNIX) and firewalls may not send protocol unreachable messages. This causes all of the protocols to appear "open".

    Because the implemented technique is very similar to UDP port scanning, ICMP rate limit might apply too. But the IP protocol field has only 8 bits, so at most 256 protocols can be probed which should be possible in reasonable time anyway.

    -sI <zombie host[:probeport]> Idlescan

    This advanced scan method allows for a truly blind TCP port scan of the target (meaning no packets are sent to the tar- get from your real IP address). Instead, a unique side-channel attack exploits predictable "IP fragmentation ID" sequence gen- eration on the zombie host to glean information about the open ports on the target. IDS systems will display the scan as com- ing from the zombie machine you specify (which must be up and meet certain criteria). I wrote an informal paper about this technique at .

    Besides being extraordinarily stealthy (due to its blind nature), this scan type permits mapping out IP-based trust rela- tionships between machines. The port listing shows open ports from the perspective of the zombie host. So you can try scan- ning a target using various zombies that you think might be trusted (via router/packet filter rules). Obviously this is crucial information when prioritizing attack targets. Other- wise, you penetration testers might have to expend considerable resources "owning" an intermediate system, only to find out that its IP isn’t even trusted by the target host/network you are ultimately after.

    You can add a colon followed by a port number if you wish to probe a particular port on the zombie host for IPID changes. Otherwise Nmap will use the port it uses by default for "tcp pings".

    -sA ACK scan

    This advanced method is usually used to map out fire- wall rulesets. In particular, it can help determine whether a firewall is stateful or just a simple packet filter that blocks incoming SYN packets.

    This scan type sends an ACK packet (with random looking acknowledgment/sequence numbers) to the ports specified. If a RST comes back, the ports is classified as "unfiltered". If nothing comes back (or if an ICMP unreachable is returned), the port is classified as "filtered". Note that nmap usually doesn't print "unfiltered" ports, so getting no ports shown in the output is usually a sign that all the probes got through (and returned RSTs). This scan will obviously never show ports in the "open" state.

    -sW Window scan

    This advanced scan is very similar to the ACK scan, except that it can sometimes detect open ports as well as fil- tered/unfiltered due to an anomaly in the TCP window size reporting by some operating systems. Systems vulnerable to this include at least some versions of AIX, Amiga, BeOS, BSDI, Cray, Tru64 UNIX, DG/UX, OpenVMS, Digital UNIX, FreeBSD, HP-UX, OS/2, IRIX, MacOS, NetBSD, OpenBSD, OpenStep, QNX, Rhapsody, SunOS 4.X, Ultrix, VAX, and VxWorks. See the nmap-hackers mailing list archive for a full list.

    -sR RPC scan

    This method works in combination with the various port scan methods of Nmap. It takes all the TCP/UDP ports found open and then floods them with SunRPC program NULL commands in an attempt to determine whether they are RPC ports, and if so, what program and version number they serve up. Thus you can effectively obtain the same info as "rpcinfo -p" even if the target's portmapper is behind a firewall (or protected by TCP wrappers). Decoys do not currently work with RPC scan, at some point I may add decoy support for UDP RPC scans.

    -sL List scan

    This method simply generates and prints a list of IP addresses or hostnames without actually pinging or port scanning them. DNS name resolution will be performed unless you use -n.

    -b <ftp relay host> FTP bounce attack

    An interesting "feature" of the ftp protocol (RFC 959) is support for "proxy" ftp connections. In other words, I should be able to connect from to the FTP server of and request that the server send a file ANYWHERE on the Internet!

    Now this may have worked well in 1985 when the RFC was written. But in today’s Internet, we can’t have people hijacking ftp servers and requesting that data be spit out to arbitrary points on the Internet.

    As *Hobbit* wrote back in 1995, this protocol flaw "can be used to post virtually untraceable mail and news, hammer on servers at various sites, fill up disks, try to hop firewalls, and generally be annoying and hard to track down at the same time."

    What we will exploit this for is to (surprise, surprise) scan TCP ports from a "proxy" ftp server. Thus you could connect to an ftp server behind a firewall, and then scan ports that are more likely to be blocked (139 is a good one). If the ftp server allows reading from and writing to some directory (such as /incoming), you can send arbitrary data to ports that you do find open (nmap doesn’t do this for you though).

    The argument passed to the "b" option is the host you want to use as a proxy, in standard URL notation. The format is: user- name:password@server:port. Everything but server is optional. To determine what servers are vulnerable to this attack, you can see my article in Phrack 51. An updated version is available at the nmap URL (


    None of these are required but some can be quite useful. Note that the -P options can now be combined -- you can increase your odds of penetrating strict firewalls by sending many probe types using different TCP ports/flags and ICMP codes.

    -P0 Do not try to ping hosts at all before scanning them

    This allows the scanning of networks that don't allow ICMP echo requests (or responses) through their firewall. is an example of such a network, and thus you should always use -P0 or -PS80 when port scanning Note that "ping" in this context may involve more than the traditional ICMP echo request packet. Nmap supports many such probes, including arbi- trary combinations of TCP, UDP, and ICMP probes. By default, Nmap sends an ICMP echo request and a TCP ACK packet to port 80.

    -PA [portlist] Use TCP ACK "ping" to determine what hosts are up

    Instead of sending ICMP echo request packets and waiting for a response, we spew out TCP ACK packets throughout the target network (or to a single machine) and then wait for responses to trickle back. Hosts that are up should respond with a RST. This option preserves the efficiency of only scanning hosts that are up while still allowing you to scan networks/hosts that block ping pack- ets. For non root UNIX users, we use connect() and thus a SYN is actually being sent. To set the destination ports of the probe packets use -PA<port1>[,port2][...]. The default port is 80, since this port is often not filtered out. Note that this option now accepts multiple, comma-separated port numbers.

    -PS [portlist]

    This option uses SYN (connection request) packets instead of ACK packets for root users

    Hosts that are up should respond with a RST (or, rarely, a SYN|ACK). You can set the destination ports in the same manner as -PA above.

    -PU [portlist]

    This option sends UDP probes to the specified hosts, expecting an ICMP port unreachable packet (or possibly a UDP response if the port is open) if the host is up.

    Since many UDP services won’t reply to an empty packet, your best bet might be to send this to expected-closed ports rather than open ones. -PE This option uses a true ping (ICMP echo request) packet.

    It finds hosts that are up and also looks for subnet-directed broadcast addresses on your network.

    These are IP addresses which are externally reachable and translate to a broadcast of incoming IP packets to a subnet of computers. These should be eliminated if found as they allow for numerous denial of service attacks (Smurf is the most common).

    -PP Uses an ICMP timestamp request (type 13) packet to find listen- ing hosts.

    -PM Same as -PE and -PP except uses a netmask request (ICMP type 17).

    -PB This is the default ping type.

    It uses both the ACK ( -PA ) and ICMP echo request ( -PE ) sweeps in parallel. This way you can get firewalls that filter either one (but not both). The TCP probe destination port can be set in the same manner as with -PA above. Note that this flag is now deprecated as pingtype flags can now be used in combination. So you should use both "PE" and "PA" (or rely on the default behavior) to achieve this same effect.

    -O This option activates remote host identification via TCP/IP fingerprinting

    In other words, it uses a bunch of techniques to detect subtleties in the underlying operating system network stack of the computers you are scanning. It uses this informa- tion to create a "fingerprint" which it compares with its database of known OS fingerprints (the nmap-os-fingerprints file) to decide what type of system you are scanning.

    If Nmap is unable to guess the OS of a machine, and conditions are good (e.g. at least one open port), Nmap will provide a URL you can use to submit the fingerprint if you know (for sure) the OS running on the machine. By doing this you contribute to the pool of operating systems known to nmap and thus it will be more accurate for everyone. Note that if you leave an IP address on the form, the machine may be scanned when we add the fingerprint (to validate that it works).

    The -O option also enables several other tests. One is the "Uptime" measurement, which uses the TCP timestamp option (RFC 1323) to guess when a machine was last rebooted. This is only reported for machines which provide this information.

    Another test enabled by -O is TCP Sequence Predictability Clas- sification. This is a measure that describes approximately how hard it is to establish a forged TCP connection against the remote host. This is useful for exploiting source-IP based trust relationships (rlogin, firewall filters, etc) or for hid- ing the source of an attack. The actual difficulty number is based on statistical sampling and may fluctuate. It is gener- ally better to use the English classification such as "worthy challenge" or "trivial joke". This is only reported in normal output with -v.

    When verbose mode (-v) is on with -O, IPID Sequence Generation is also reported. Most machines are in the "incremental" class, which means that they increment the "ID" field in the IP header for each packet they send. This makes them vulnerable to sev- eral advanced information gathering and spoofing attacks.

    --osscan_limit OS detection is far more effective if at least one open and one closed TCP port are found. Set this option and Nmap will not even try OS detection against hosts that do not meet this criteria. This can save substantial time, particularly on -P0 scans against many hosts. It only matters when OS detection is requested (-O or -A options).

    -A This option enables _a_dditional _a_dvanced and _a_ggressive options. I haven’t decided exactly which it stands for yet :). Presently this enables OS Detection (-O) and version scanning (-sV). More features may be added in the future. The point is to enable a comprehensive set of scan options without people having to remember a large set of flags. This option only enables features, and not timing options (such as -T4) or ver- bosity options (-v) that you might wan’t as well.

    -6 This options enables IPv6 support. All targets must be IPv6 if this option is used, and they can be specified via normal DNS name (AAAA record) or as a literal IP address such as 3ffe:501:4819:2000:210:f3ff:fe03:4d0 . Currently, connect() TCP scan and TCP connect() Ping scan are supported. If you need UDP or other scan types, have a look at http://nmap6.source- .

    -f This option causes the requested SYN, FIN, XMAS, or NULL scan to use tiny fragmented IP packets. The idea is to split up the TCP header over several packets to make it harder for packet fil- ters, intrusion detection systems, and other annoyances to detect what you are doing. Be careful with this! Some programs have trouble handling these tiny packets. My favorite sniffer segmentation faulted immediately upon receiving the first 36-byte fragment. After that comes a 24 byte one! While this method won’t get by packet filters and firewalls that queue all IP fragments (like the CONFIG_IP_ALWAYS_DEFRAG option in the Linux kernel), some networks can’t afford the performance hit this causes and thus leave it disabled.

    Note that I do not yet have this option working on all systems. It works fine for my Linux, FreeBSD, and OpenBSD boxes and some people have reported success with other *NIX variants.

    -v Verbose mode

    This is a highly recommended option and it gives out more information about what is going on. You can use it twice for greater effect. You can also use -d a few times if you really want to get crazy with scrolling the screen!

    -h This handy option display a quick reference screen of nmap usage options. As you may have noticed, this man page is not exactly a "quick reference" :)

    -oN <logfilename> This logs the results of your scans in a normal human readable form into the file you specify as an argument.

    -oX <logfilename> This logs the results of your scans in XML form into the file you specify as an argument. This allows programs to easily cap- ture and interpret Nmap results. You can give the argument "-" (without quotes) to shoot output into stdout (for shell pipelines, etc). In this case normal output will be suppressed. Watch out for error messages if you use this (they will still go to stderr). Also note that "-v" may cause some extra informa- tion to be printed. The Document Type Definition (DTD) defining the XML output structure is available at http://www.inse- .

    -oG <logfilename> This logs the results of your scans in a grepable form into the file you specify as an argument. This simple format provides all the information on one line (so you can easily grep for port or OS information and see all the IPs. This used to be the pre- ferred mechanism for programs to interact with Nmap, but now we recommend XML output (-oX instead). This simple format may not contain as much information as the other formats. You can give the argument "-" (without quotes) to shoot output into stdout (for shell pipelines, etc). In this case normal output will be suppressed. Watch out for error messages if you use this (they will still go to stderr). Also note that "-v" will cause some extra information to be printed.

    -oA <basefilename> This tells Nmap to log in ALL the major formats (normal, grepable, and XML). You give a base for the filename, and the output files will be base.nmap, base.gnmap, and base.xml.

    -oS <logfilename> thIs l0gz th3 r3suLtS of YouR ScanZ iN a s|<ipT kiDd|3 f0rM iNto THe fiL3 U sPecfy 4s an arGuMEnT! U kAn gIv3 the 4rgument "-" (wItHOUt qUOteZ) to sh00t output iNT0 stDouT!@!!

    --resume <logfilename> A network scan that is canceled due to control-C, network out- age, etc. can be resumed using this option. The logfilename must be either a normal (-oN) or grepable (-oG) log from the aborted scan. No other options can be given (they will be the same as the aborted scan). Nmap will start on the machine after the last one successfully scanned in the log file.

    --exclude <host1 [,host2][,host3],..."> Specifies a list of targets (hosts, ranges, netblocks) that should be excluded from a scan. Useful to keep from scanning yourself, your ISP, particularly sensitive hosts, etc.

    --excludefile <exclude_file> Same functionality as the --exclude option, only the excluded targets are provided in an newline-delimited exclude_file rather than on the command line.

    --append_output Tells Nmap to append scan results to any output files you have specified rather than overwriting those files.

    -iL <inputfilename> Reads target specifications from the file specified RATHER than from the command line. The file should contain a list of host or network expressions separated by spaces, tabs, or newlines. Use a hyphen (-) as inputfilename if you want nmap to read host expressions from stdin (like at the end of a pipe). See the section target specification for more information on the expres- sions you fill the file with.

    -iR <num hosts> This option tells Nmap to generate its own hosts to scan by simply picking random numbers :). It will never end after the given number of IPs has been scanned -- use 0 for a never-ending scan. This option can be useful for statistical sampling of the Internet to estimate various things. If you are ever really bored, try nmap -sS -PS80 -iR 0 -p 80 to find some web servers to look at.

    -p <port ranges> This option specifies what ports you want to specify. For example "-p 23" will only try port 23 of the target host(s). "-p 20-30,139,60000-" scans ports between 20 and 30, port 139, and all ports greater than 60000. The default is to scan all ports between 1 and 1024 as well as any ports listed in the services file which comes with nmap. For IP protocol scanning (-sO), this specifies the protocol number you wish to scan for (0-255).

    When scanning both TCP and UDP ports, you can specify a particu- lar protocol by preceding the port numbers by "T:" or "U:". The qualifier lasts until you specify another qualifier. For exam- ple, the argument "-p U:53,111,137,T:21-25,80,139,8080" would scan UDP ports 53,111,and 137, as well as the listed TCP ports. Note that to scan both UDP & TCP, you have to specify -sU and at least one TCP scan type (such as -sS, -sF, or -sT). If no pro- tocol qualifier is given, the port numbers are added to all pro- tocol lists.

    -F Fast scan mode. Specifies that you only wish to scan for ports listed in the services file which comes with nmap (or the protocols file for -sO). This is obviously much faster than scanning all 65535 ports on a host.

    -D <decoy1 [,decoy2][,ME],...> Causes a decoy scan to be performed which makes it appear to the remote host that the host(s) you specify as decoys are scanning the target network too. Thus their IDS might report 5-10 port scans from unique IP addresses, but they won’t know which IP was scanning them and which were innocent decoys. While this can be defeated through router path tracing, response-dropping, and other "active" mechanisms, it is generally an extremely effec- tive technique for hiding your IP address.

    Separate each decoy host with commas, and you can optionally use "ME" as one of the decoys to represent the position you want your IP address to be used. If you put "ME" in the 6th position or later, some common port scan detectors (such as Solar Designer’s excellent scanlogd) are unlikely to show your IP address at all. If you don’t use "ME", nmap will put you in a random position.

    Note that the hosts you use as decoys should be up or you might accidentally SYN flood your targets. Also it will be pretty easy to determine which host is scanning if only one is actually up on the network. You might want to use IP addresses instead of names (so the decoy networks don’t see you in their name- server logs).

    Also note that some "port scan detectors" will firewall/deny routing to hosts that attempt port scans. The problem is that many scan types can be forged (as this option demonstrates). So attackers can cause such a machine to sever connectivity with important hosts such as its internet gateway, DNS TLD servers, sites like Windows Update, etc. Most such software offers whitelist capabilities, but you are unlikely to enumerate all of the critical machines. For this reason we never recommend tak- ing action against port scans that can be forged, including SYN scans, UDP scans, etc. The machine you block could just be a decoy.

    Decoys are used both in the initial ping scan (using ICMP, SYN, ACK, or whatever) and during the actual port scanning phase. Decoys are also used during remote OS detection ( -O ).

    It is worth noting that using too many decoys may slow your scan and potentially even make it less accurate. Also, some ISPs will filter out your spoofed packets, although many (currently most) do not restrict spoofed IP packets at all.

    -S <ip_address ess> In some circumstances, nmap may not be able to determine your source address ( nmap will tell you if this is the case). In this situation, use -S with your IP address (of the interface you wish to send packets through).

    Another possible use of this flag is to spoof the scan to make the targets think that someone else is scanning them. Imagine a company being repeatedly port scanned by a competitor! This is not a supported usage (or the main purpose) of this flag. I just think it raises an interesting possibility that people should be aware of before they go accusing others of port scan- ning them. -e would generally be required for this sort of usage.

    -e <interface> Tells nmap what interface to send and receive packets on. Nmap should be able to detect this but it will tell you if it cannot.

    --source_port <portnumber> Sets the source port number used in scans. Many naive firewall and packet filter installations make an exception in their rule- set to allow DNS (53) or FTP-DATA (20) packets to come through and establish a connection. Obviously this completely subverts the security advantages of the firewall since intruders can just masquerade as FTP or DNS by modifying their source port. Obvi- ously for a UDP scan you should try 53 first and TCP scans should try 20 before 53. Note that this is only a request -- nmap will honor it only if and when it is able to. For example, you can’t do TCP ISN sampling all from one host:port to one host:port, so nmap changes the source port even if you used this option. This is an alias for the shorter, but harder to remem- ber, -g option.

    Be aware that there is a small performance penalty on some scans for using this option, because I sometimes store useful informa- tion in the source port number.

    --data_length <number> Normally Nmap sends minimalistic packets that only contain a header. So its TCP packets are generally 40 bytes and ICMP echo requests are just 28. This option tells Nmap to append the given number of random bytes to most of the packets it sends. OS detection (-O) packets are not affected, but most pinging and portscan packets are. This slows things down, but can be slightly less conspicuous.

    -n Tells Nmap to NEVER do reverse DNS resolution on the active IP addresses it finds. Since DNS is often slow, this can help speed things up.

    -R Tells Nmap to ALWAYS do reverse DNS resolution on the target IP addresses. Normally this is only done when a machine is found to be alive.

    -r Tells Nmap NOT to randomize the order in which ports are scanned.

    --ttl <value> Sets the IPv4 time to live field in sent packets to the given value.

    --randomize_hosts Tells Nmap to shuffle each group of up to 2048 hosts before it scans them. This can make the scans less obvious to various network monitoring systems, especially when you combine it with slow timing options (see below).

    -M <max sockets> Sets the maximum number of sockets that will be used in parallel for a TCP connect() scan (the default). This is useful to slow down the scan a little bit and avoid crashing remote machines. Another approach is to use -sS, which is generally easier for machines to handle.

    --packet_trace Tells Nmap to show all the packets it sends and receives in a tcpdump-like format. This can be tremendously useful for debug- ging, and is also a good learning tool.

    --datadir [directoryname] Nmap obtains some special data at runtime in files named nmap- services, nmap-protocols, nmap-rpc, and nmap-os-fingerprints. Nmap first searches these files in the directory option to --nmapdir. Any files not found there, are searched for in the directory specified by the NMAPDIR environmental variable. Next comes ~/nmap, and then a compiled-in location such as /usr/share/nmap . As a last resort, Nmap will look in the cur- rent directory.

    TIMING OPTIONS Generally Nmap does a good job at adjusting for Network charac- teristics at runtime and scanning as fast as possible while min- imizing that chances of hosts/ports going undetected. However, there are same cases where Nmap’s default timing policy may not meet your objectives. The following options provide a fine level of control over the scan timing:

    -T <Paranoid|Sneaky|Polite|Normal|Aggressive|Insane> These are canned timing policies for conveniently expressing your priorities to Nmap. Paranoid mode scans very slowly in the hopes of avoiding detection by IDS systems. It serializes all scans (no parallel scanning) and generally waits at least 5 min- utes between sending packets. Sneaky is similar, except it only waits 15 seconds between sending packets. Polite is meant to ease load on the network and reduce the chances of crashing machines. It serializes the probes and waits at least 0.4 sec- onds between them. Note that this is generally at least an order of magnitude slower than default scans, so only use it when you need to. Normal is the default Nmap behavior, which tries to run as quickly as possible without overloading the net- work or missing hosts/ports. Aggressive This option can make certain scans (especially SYN scans against heavily filtered hosts) much faster. It is recommended for impatient folks with a fast net connection. Insane is only suitable for very fast networks or where you don’t mind losing some information. It times out hosts in 15 minutes and won’t wait more than 0.3 sec- onds for individual probes. It does allow for very quick net- work sweeps though :).

    You can also reference these by number (0-5). For example, "-T0" gives you Paranoid mode and "-T5" is Insane mode.

    --host_timeout <milliseconds> Specifies the amount of time Nmap is allowed to spend scanning a single host before giving up on that IP. The default timing mode has no host timeout.

    --max_rtt_timeout <milliseconds> Specifies the maximum amount of time Nmap is allowed to wait for a probe response before retransmitting or timing out that par- ticular probe. The default mode sets this to about 9000.

    --min_rtt_timeout <milliseconds> When the target hosts start to establish a pattern of responding very quickly, Nmap will shrink the amount of time given per probe. This speeds up the scan, but can lead to missed packets when a response takes longer than usual. With this parameter you can guarantee that Nmap will wait at least the given amount of time before giving up on a probe.

    --initial_rtt_timeout <milliseconds> Specifies the initial probe timeout. This is generally only useful when scanning firewalled hosts with -P0. Normally Nmap can obtain good RTT estimates from the ping and the first few probes. The default mode uses 6000.

    --max_hostgroup <numhosts> Specifies the maximum number of hosts that Nmap is allowed to scan in parallel. Most of the port scan techniques support multi-host operation, which makes them much quicker. Spreading the load among multiple target hosts makes the scans gentler. The downside is increast results latency. You need to wait for all hosts in a group to finish, rather than having them pop up one by one. Specify an argument of one for old-style (one host at a time) Nmap behavior. Note that the ping scanner handles its own grouping, and ignores this value.

    --min_hostgroup <milliseconds> Specifies the minimum host group size (see previous entry). Large values (such as 50) are often beneficial for unattended scans, though they do take up more memory. Nmap may override this preference when it needs to, because a group must all use the same network interface, and some scan types can only handle one host at a time.

    --max_parallelism <number> Specifies the maximum number of scans Nmap is allowed to perform in parallel. Setting this to one means Nmap will never try to scan more than 1 port at a time. It also effects other parallel scans such as ping sweep, RPC scan, etc.

    --min_parallelism <number> Tells Nmap to scan at least the given number of ports in paral- lel. This can speed up scans against certain firewalled hosts by an order of magnitude. But be careful -- results will become unreliable if you push it too far.

    --scan_delay <milliseconds> Specifies the minimum amount of time Nmap must wait between probes. This is mostly useful to reduce network load or to slow the scan way down to sneak under IDS thresholds.


    Everything that isn't an option (or option argument) in nmap is treated as a target host specification. The simplest case is listing single hostnames or IP addresses on the command line. If you want to scan a subnet of IP addresses, you can append /mask to the hostname or IP address. mask must be between 0 (scan the whole Internet) and 32 (scan the single host specified). Use /24 to scan a class "C" address and /16 for a class "B".

    Nmap also has a more powerful notation which lets you specify an IP address using lists/ranges for each element. Thus you can scan the whole class "B" network 192.168.*.* by specifying "192.168.*.*" or "192.168.0-255.0-255" or even "192.168.1-50,51-255.1,2,3,4,5-255".

    And of course you can use the mask notation: "". These are all equivalent. If you use asterisks ("*"), remember that most shells require you to escape them with back slashes or protect them with quotes.

    Another interesting thing to do is slice the Internet the other way. Instead of scanning all the hosts in a class "B", scan "*.*.5.6-7" to scan every IP address that ends in .5.6 or .5.7 Pick your own numbers. For more information on specifying hosts to scan, see the examples section.



    Of course to thanks Fyodor for being so kind to make some time in his busy life to fill in the questions and also RainForestPuppy for making the introduction below:

    "Quite honestly, I own a lot of my professional success to Fyodor; nmap has proven to not be just a 'nice' tool, but rather a literal requirement that I have built many tools and techniques upon. But of course, there is more to Fyodor beyond nmap--and I hope this interview will demonstrate that. I've had the fortune of hanging out with Fyodor on a couple of occasions, and beyond being a severely sharp dude, he is definitely someone worthy of knowing."

    > How did you come up with the name Fyodor?
    > Possibly from: Fyodor Mikhailovich Dostoevsky (1821-1881) ?

    Exactly. When I picked the handle I had recently read and enjoyed "Notes from Underground". Sometimes people assume I must be some sort of Dostoevsky expert, and this is not the case. He's not even my favorite author. So I feel a little bad when people send me long emails expounding on some interpretation they have about "The Brothers Karamazov" and asking my opinion. I have to tell them "sorry, I hardly remember the plot". Even worse, is when people assume from the handle that I am Russian, and they send me email that my mail reader cannot even render.

    > Have you had any other nicks before Fyodor?

    Maybe :).

    > Have you been in "hacking" groups back in the days ? and what where you doing before nmap became such an success ?

    Before Nmap, I worked on several other security resources. Such as "exploit world" (which is still around, but way too dated). My previous site was called "Fyodor's Playhouse". Before that, I was mostly active in local (602) BBS's.

    > How many computers do you have home at this moment?

    Well, in order to develop network exploration tools such as Nmap, it is important that I have a decent network at home. At least that is the excuse I use to continue buying new boxes :). Lets see, the computers I have at the moment are:

    5 Linux boxes (amy; db; hopelessly; playground; zardoz)
    1 FreeBSD 3.0-Release box (freedom)
    1 OpenBSD 2.5 box (vectra)
    4 Solaris boxes (an IPC, SLC, ELC, and Sparc2)
    2 HP Envizex X-terms
    1 HP 382 workstations (not working at the moment)

    With this network going, I don't need a heater for my apartment :).

    > What operating systems do you work with and what is your favorite?

    As the list above shows, I'm kind of partial to Linux :). But I think *BSD are great too. And even Solaris has its good points. I have never really liked IRIX, HP-UX, Windows, or VMS.

    > What are some of your interests outside the computer world?

    I like rock climbing, hiking, target shooting, and jogging. I enjoy travelling and exploring unfamiliar cities.

    In addition, I spend a lot of time reading books (Sci-Fi;Computer crime), newspapers (New York Times; WSJ), magazines (Scientific American, Barrons), etc.

    > How has the success of nmap affected your life?

    Well, it hasn't led to fortune. Not much fame either. And I have found that it does NOT impress girls! So I guess the main effect is that I have to spend a lot of time answering support mails.

    Just kidding :). It has actually been a wonderful experience. I have met hundreds of incredible people through the project and I think writing and (especially) maintaining a (somewhat) large program like this has made me a better programmer. Also, I feel like I have contributed something useful to the security community which has provided me so much in the way of free tools.

    > What would you consider to be the second best port scanner available?

    I've always thought the classic scanner strobe [1] is a good piece of software. Another great (newer) scanner is hping2 by Antirez [2]. [1]

    > Do you spend time on irc?

    No. I mostly use personal email and email lists. If all I want to do is chat, I would rather just call up some hacker friends here in the Valley and go out for a drink.

    > What is your highest level of education?

    I have a degree in Computer Science. A lot of hackers sneer at formal education, but I thought college was a very valuable experience.

    > How did you learn to program?

    I started with BASIC on an Apple IIe. But on UNIX it was mostly from reading other people's code. This is one reason I'm such a strong open source advocate.

    > How much time do you spend online daily?

    It various a lot with what I am working on. When I am very focused on a cool project, I sometimes spend days at the computer without even leaving my apartment. But generally I try to strike a balance between
    hacking and having a somewhat-decent social life.

    > Are there other projects that you are working on?

    Right now I'm working on several. Besides nmap improvements, I am working on an important addition to my web site which will be announced soon. I am also working on several other projects: nsock,
    ncrack, and sd. I'm not a fan of vaporware so I'll save the details until they are ready.

    > What is your number one bookmark and would you like to share your bookmarks?

    I have a lot of different interests on the web, but here are my favorite sites: [ Security ] of course :).;
    Technotronic.Com; Tons of mailing lists.

    [News] ;;;;; mailing lists


    > Did you help eeye with the nmap port ? what if it's faster ;) ?

    I helped a little in terms of understanding nmap internal structure. But I didn't help with the porting to Windows, per se. And don't worry, its not faster than the UNIX version :). If NmapNT ever becomes competitive in that respect, I'll head straight for my profiler and start optimizing :)

    For more information about Fyodor make sure you visit his site !



    Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy


    War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotesSomerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose BierceBernard Shaw : Mark Twain Quotes


    Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law


    Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOSProgramming Languages History : PL/1 : Simula 67 : C : History of GCC developmentScripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

    Classic books:

    The Peter Principle : Parkinson Law : 1984 : The Mythical Man-MonthHow to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

    Most popular humor pages:

    Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

    The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

    Copyright © 1996-2021 by Softpanorama Society. was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

    FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.

    This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...

    You can use PayPal to to buy a cup of coffee for authors of this site


    The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

    Last modified: February 03, 2020