How many bytes occupy a simple nmap to a host?

Question

Today the IT manager got angry because I used nmap on the 3 servers I manage to see what ports they had open. I know I could have used netstat inside the host' shell.

He told me that "If the network goes down because of nmap I would be punished". I would like to know technically how many network bandwith / bytes would take a nmap 192.168.1.x which outputs:

Starting Nmap 6.40 ( http://nmap.org ) at 2015-05-11 13:33 ART
Nmap scan report for 192.168.x.53
Host is up (0.0043s latency).
Not shown: 983 closed ports
PORT      STATE SERVICE
1/tcp     open  tcpmux
22/tcp    open  ssh
79/tcp    open  finger
80/tcp    open  http
111/tcp   open  rpcbind
119/tcp   open  nntp
143/tcp   open  imap
1080/tcp  open  socks
1524/tcp  open  ingreslock
2000/tcp  open  cisco-sccp
6667/tcp  open  irc
12345/tcp open  netbus
31337/tcp open  Elite
32771/tcp open  sometimes-rpc5
32772/tcp open  sometimes-rpc7
32773/tcp open  sometimes-rpc9
32774/tcp open  sometimes-rpc11

Nmap done: 1 IP address (1 host up) scanned in 3.28 seconds

Answer 1

This is easy enough to measure, at least if you nmap a host your machine is not otherwise communicating with. Just use tcpdump or wireshark to capture the traffic, limited to that IP address. You could also use iptables counters, etc.

I did so (using wireshark), the machine I tested on has fewer open TCP ports (5), but the totals were 2009 packets, 118,474 bytes. That took 1.4 seconds, so 1435 pps or 677 kbps. Neither should take down a reasonably-configured network.

Doing additional targets could potentially overwhelm a stateful firewall's connection tracking, if the scan went through a firewall. And of course running nmap is likely to cause any intrusion detection system to alarm—potentially wasting someone's time investigating.

Finally, nmap (by default) doesn't check all ports and host-based IDSs may detect and respond to the scan—both mean you don't necessarily get accurate answers.

Answer 2

I've seen (broken) smart switches going down due to nmap activity, but that was when nmapping a subnet (so ARP traffic for a lot of different endpoints). That may be the kind of problem he's thinking of.

Now Intrusion Detection Systems do try and detect port scanning activity and may be configured to block the IP address of the host doing the scanning.

If there's a SNATing router in between you and the target host, and an IDS between that router and the target host, then the masquerading IP address of that router may end up being blocked as it would be the one appearing as the source of those scans. That could affect connectivity to all the networks beyond that IDS.

Other than that, nmapping a single host on the same subnet is not going to generate a lot of traffic or cause any disruption (other than on the sending and receiving host).

Answer 3

Are you a network administrator? If you aren't, I think that your IT manager was not concerned by the overuse of bandwidth but rather with the fact that 1) you were tinkering with the network and 2) nmap scanning could crash applications:

It should also be noted that Nmap has been known to crash certain poorly written applications, TCP/IP stacks, and even operating systems. Nmap should never be run against mission critical systems unless you are prepared to suffer downtime. We acknowledge here that Nmap may crash your systems or networks and we disclaim all liability for any damage or problems Nmap could cause. Because of the slight risk of crashes and because a few black hats like to use Nmap for reconnaissance prior to attacking systems, there are administrators who become upset and may complain when their system is scanned. Thus, it is often advisable to request permission before doing even a light scan of a network.

Note that should nmap crash an application, it's because the application is poorly written, not nmap's fault. Nmap is a well-recognized and useful tool that should be widely used by network admins when managing their own network.