1 What is nmap?
Nmap, short for Network Mapper, is a free, open-source tool for vulnerability scanning and network discovery. Network administrators use Nmap to identify what devices are running on their systems, discovering hosts that are available and the services they offer, finding open ports and detecting security risks.
2 environment
I used two virtual machines on VMware Workstation 16 Player.
The OS version of the virtual machine for both client and server is as follows. OS version
[root @ client ~] # cat / etc / redhat-release
CentOS Linux release 7.4.1708 (Core)
[root @ client ~] # uname -r 3.10.0-693.el7.x86_64
Network configuration
192.168.3.0/24
client ---------------------- server
.20 .50
The hosts file has the following contents for both client and server. Client hosts file
[root @ client ~] # cat / etc / hosts
192.168.3.50 server
192.168.3.20 client
3 Installation method
Install nmap on the client.
[root @ client ~] # yum -y install nmap
[root @ client ~] # nmap -V
Nmap version 6.40 (http://nmap.org)
Platform: x86_64-redhat-linux-gnu
Compiled with: nmap-liblua-5.2.2 openssl-1.0.2k libpcre-8.32 libpcap-1.5.3 nmap-libdnet-1.12 ipv6
Compiled without:
Available nsock engines: epoll poll select
4 Option list
[root @ client ~] # nmap --help
Nmap 6.40 (http://nmap.org)
Usage: nmap [Scan Type (s)] [Options] {target specification}
TARGET SPECIFICATION:
Can pass hostnames, IP addresses, networks, etc.
Ex: scanme.nmap.org, microsoft.com/24, 192.168.0.1; 10.0.0-255.1-254
-iL <inputfilename>: Input from list of hosts / networks
-iR <num hosts>: Choose random targets
--exclude <host1 [, host2] [, host3], ...>: Exclude hosts / networks
--excludefile <exclude_file>: Exclude list from file
HOST DISCOVERY:
-sL: List Scan --simply list targets to scan
-sn: Ping Scan --disable port scan
-Pn: Treat all hosts as online --skip host discovery
-PS / PA / PU / PY [portlist]: TCP SYN / ACK, UDP or SCTP discovery to given ports
-PE / PP / PM: ICMP echo, timestamp, and netmask request discovery probes
-PO [protocol list]: IP Protocol Ping
-n / -R: Never do DNS resolution / Always resolve [default: sometimes]
--dns-servers <serv1 [, serv2], ...>: Specify custom DNS servers
--system-dns: Use OS's DNS resolver
--traceroute: Trace hop path to each host
SCAN TECHNIQUES:
-sS / sT / sA / sW / sM: TCP SYN / Connect () / ACK / Window / Maimon scans
-sU: UDP Scan
-sN / sF / sX: TCP Null, FIN, and Xmas scans
--scanflags <flags>: Customize TCP scan flags
-sI <zombie host [: probeport]>: Idle scan
-sY / sZ: SCTP INIT / COOKIE-ECHO scans
-sO: IP protocol scan
-b <FTP relay host>: FTP bounce scan
PORT SPECIFICATION AND SCAN ORDER:
-p <port ranges>: Only scan specified ports
Ex: -p22; -p1-65535; -p U: 53,111,137, T: 21-25,80,139,8080, S: 9
-F: Fast mode --Scan fewer ports than the default scan
-r: Scan ports consecutively --don't randomize
--top-ports <number>: Scan <number> most common ports
--port-ratio <ratio>: Scan ports more common than <ratio>
SERVICE / VERSION DETECTION:
-sV: Probe open ports to determine service / version info
--version-intensity <level>: Set from 0 (light) to 9 (try all probes)
--version-light: Limit to most likely probes (intensity 2)
--version-all: Try every single probe (intensity 9)
--version-trace: Show detailed version scan activity (for debugging)
SCRIPT SCAN:
-sC: equivalent to --script = default
--script = <Lua scripts>: <Lua scripts> is a comma separated list of
directories, script-files or script-categories
--script-args = <n1 = v1, [n2 = v2, ...]>: provide arguments to scripts
--script-args-file = filename: provide NSE script args in a file
--script-trace: Show all data sent and received
--script-updatedb: Update the script database.
--script-help = <Lua scripts>: Show help about scripts.
<Lua scripts> is a comma separted list of script-files or
script-categories.
OS DETECTION:
-O: Enable OS detection
--osscan-limit: Limit OS detection to promising targets
--osscan-guess: Guess OS more aggressively
TIMING AND PERFORMANCE:
Options which take <time> are in seconds, or append'ms' (milliseconds),
's' (seconds),'m' (minutes), or'h' (hours) to the value (eg 30m).
-T <0-5>: Set timing template (higher is faster)
--min-hostgroup / max-hostgroup <size>: Parallel host scan group sizes
--min-parallelism / max-parallelism <numprobes>: Probe parallelization
--min-rtt-timeout / max-rtt-timeout / initial-rtt-timeout <time>: Specifies
probe round trip time.
--max-retries <tries>: Caps number of port scan probe retransmissions.
--host-timeout <time>: Give up on target after this long
--scan-delay / --max-scan-delay <time>: Adjust delay between probes
--min-rate <number>: Send packets no slower than <number> per second
--max-rate <number>: Send packets no faster than <number> per second
FIREWALL / IDS EVASION AND SPOOFING:
-f; --mtu <val>: fragment packets (optionally w / given MTU)
-D <decoy1, decoy2 [, ME], ...>: Cloak a scan with decoys
-S <IP_Address>: Spoof source address
-e <iface>: Use specified interface
-g /-source-port <portnum>: Use given port number
--data-length <num>: Append random data to sent packets
--ip-options <options>: Send packets with specified ip options
--ttl <val>: Set IP time-to-live field
--spoof-mac <mac address / prefix / vendor name>: Spoof your MAC address
--badsum: Send packets with a bogus TCP / UDP / SCTP checksum
OUTPUT:
-oN / -oX / -oS / -oG <file>: Output scan in normal, XML, s | <rIpt kIddi3,
and Grepable format, respectively, to the given filename.
-oA <basename>: Output in the three major formats at once
-v: Increase verbosity level (use -vv or more for greater effect)
-d: Increase debugging level (use -dd or more for greater effect)
--reason: Display the reason a port is in a particular state
--open: Only show open (or possibly open) ports
--packet-trace: Show all packets sent and received
--iflist: Print host interfaces and routes (for debugging)
--log-errors: Log errors / warnings to the normal-format output file
--append-output: Append to rather than clobber specified output files
--resume <filename>: Resume an aborted scan
--stylesheet <path / URL>: XSL stylesheet to transform XML output to HTML
--webxml: Reference stylesheet from Nmap.Org for more portable XML
--no-stylesheet: Prevent associating of XSL stylesheet w / XML output
MISC:
-6: Enable IPv6 scanning
-A: Enable OS detection, version detection, script scanning, and traceroute
--datadir <dirname>: Specify custom Nmap data file location
--send-eth / --send-ip: Send using raw ethernet frames or IP packets
--privileged: Assume that the user is fully privileged
--unprivileged: Assume the user lacks raw socket privileges
-V: Print version number
-h: Print this help summary page.
Excited:
nmap -v -A scanme.nmap.org
nmap -v -sn 192.168.0.0/16 10.0.0.0/8
nmap -v -iR 10000 -Pn -p 80
SEE THE MAN PAGE (http://nmap.org/book/man.html) FOR MORE OPTIONS AND accurately
5 Basic usage
5.1 How to check open port numbers
“Open” means that port scan packets reach the TCP / UDP layer.
This means that the packet filters (iptables) that pass earlier will not drop the packet. server
Check the open port number (numerical value).
[root @ server ~] # firewall-cmd --list-ports
Check the open port number (service name). You can see that only ssh (22) is open.
[root @ server ~] # firewall-cmd --list-services
ssh
From the above execution result, you can see that only the ssh (port 22) port is open.
For how to use the firewall-cmd command, refer to here (How to use the firewall-cmd command) .
Then run nmap on the client. client
[root @ client ~] # nmap server
Starting Nmap 6.40 (http://nmap.org) at 2018-11-01 19:57 JST
Nmap scan report for server (192.168.3.50)
Host is up (0.00059s latency).
Not shown: 999 filtered ports ★
PORT STATE SERVICE
22 / tcp open ssh
MAC Address: xx: xx: xx: xx: xx: xx (VMware)
Nmap done: 1 IP address (1 host up) scanned in 5.03 seconds
When you check the execution result, “Not shown: 999 filtered ports” is displayed (marked with a star).
This means that port scan packets are dropped by packet filters (iptables) and
999 ports are closed.
And if there are many closed ports, the display seems to be omitted.
Also, a port scan packet has arrived at ssh (port 20).
This means that by default you are doing a port scan on 1000 ports.
5.2 Experiment 1
Try opening port 11111 on the server side.
At this time, let’s check what the execution result of nmap will be. Server side
Open port 11111.
[root @ server ~] # firewall-cmd --add-port = 11111 / tcp
success
Check the open port number (numerical value). You can see that port 11111 is open.
[root @ server ~] # firewall-cmd --list-ports
11111 / tcp
Check the open port number (service name). You can see that ssh (22) is open.
[root @ server ~] # firewall-cmd --list-services
ssh
Then run nmap on the client. client
[root @ client ~] # nmap server
Starting Nmap 6.40 (http://nmap.org) at 2018-11-01 20:07 JST
Nmap scan report for server (192.168.3.50)
Host is up (0.00065s latency).
Not shown: 998 filtered ports
PORT STATE SERVICE
22 / tcp open ssh
11111 / tcp ★ closed vce
MAC Address: xx: xx: xx: xx: xx: xx (VMware)
Nmap done: 1 IP address (1 host up) scanned in 5.04 seconds
You can see that port 11111 has changed from filtered to closed (marked with a star).
This means that the port scan packet has reached port 11111,
but no process is listening on that port number.
To be more precise, the TCP layer
replied a RST packet (★ below) to the SYN packet for port 11111 .
client server (11111)
| |
| ----------------- SYN ----------------> |
| <---------------- RST ------------------ | ★
| |
Also, from the display “Not shown: 998 filtered ports”,
you can see that the number of port scan packets that reached the TCP layer has been reduced to 998.
5.3 Experiment 2
In the state of Experiment 1, try executing the nc command on the server.
The nc command is executed so that the nc process listens on port 11111.
Please refer to the following for how to use each command.
nc command =>Using the nc command
lsof command => use of lsof command server
Execute the nc command. Listen on port 11111.
[root @ server ~] # nc -kl 11111 &
[1] 1464
11 Check the status of port 1111. You can see that the nc process is in the Listen state on port 11111.
[root @ server ~] # lsof -i : 11111
COMMAND PID USER FD TYPE DEVICE SIZE / OFF NODE NAME
nc 1464 root 3u IPv6 15360 0t0 TCP *: vce (LISTEN)
nc 1464 root 4u IPv4 28673 0t0 TCP *: vce (LISTEN)
Then run nmap on the client. client
[root @ client ~] # nmap server
Starting Nmap 6.40 (http://nmap.org) at 2018-11-01 20:12 JST
Nmap scan report for server (192.168.3.50)
Host is up (0.00064s latency).
Not shown: 998 filtered ports
PORT STATE SERVICE
22 / tcp open ssh
11111 / tcp open vce
MAC Address: xx: xx: xx: xx: xx: xx (VMware)
Nmap done: 1 IP address (1 host up) scanned in 5.00 seconds
This time, port 11111 is now open.
This means that the port scan packet has reached port 11111 and
a response has been returned.
To be more precise, the TCP layer
replied a SYN + ACK packet to the SYN packet for port 11111 (★ below).
This means that there is a process (nc) listening on port 11111.
When the client receives SYN + ACK, it sends RST to the server.
client server (11111)
| |
| ----------------- SYN ----------------> |
| <----------- ----- SYN + ACK ------------ | ★
| ----------------- RST --------- -------> |
| |
6 How to scan TCP ports
6.1 How to specify a specific port number (-p)
Check the open port number on the server side.
From the execution result of firewall-cmd, you can see that only the ssh (22) port is open on the server side. server
[root @ server ~] # firewall-cmd --list-ports
[root @ server ~] # firewall-cmd --list-services ssh
Run nmap on the client.
Try performing a port scan on port 11111.
On port 11111, you can see that the packet is being dropped by the packet filter (iptables). client
[root @ client ~] # nmap -p11111 server
Starting Nmap 6.40 (http://nmap.org) at 2018-11-02 21:29 JST
Nmap scan report for server (192.168.3.50)
Host is up (0.00079s latency).
PORT STATE SERVICE
11111 / tcp filtered vce
MAC Address: xx: xx: xx: xx: xx: xx (VMware)
Nmap done: 1 IP address (1 host up) scanned in 0.16 seconds
Now let’s do a port scan on port 22.
You can see that port 22 is open (ssh process is listening). client
[root @ client ~] # nmap -p22 server
Starting Nmap 6.40 (http://nmap.org) at 2018-11-03 17:30 JST
Nmap scan report for server (192.168.3.50)
Host is up (0.00058s latency).
PORT STATE SERVICE
22 / tcp open ssh
MAC Address: xx: xx: xx: xx: xx: xx (VMware)
Nmap done: 1 IP address (1 host up) scanned in 0.32 seconds
6.2 How to specify a range (-p)
Check the open port number on the server side.
From the execution result of firewall-cmd, you can see that only the ssh (22) port is open on the server side. server
[root @ server ~] # firewall-cmd --list-ports
[root @ server ~] # firewall-cmd --list-services ssh
Run nmap on the client.
Try performing a port scan on ports 20-30. client
[root @ client ~] # nmap -p20-30 server
Starting Nmap 6.40 (http://nmap.org) at 2018-11-02 21:34 JST
Nmap scan report for server (192.168.3.50)
Host is up (0.00043s latency).
PORT STATE SERVICE
20 / tcp filtered ftp-data
21 / tcp filtered ftp
22 / tcp open ssh ★
23 / tcp filtered telnet
24 / tcp filtered priv-mail
25 / tcp filtered smtp
26 / tcp filtered rsftp
27 / tcp filtered nsw-fe
28 / tcp filtered unknown
29/tcp filtered msg-icp
30 / tcp filtered unknown
MAC Address: xx: xx: xx: xx: xx: xx (VMware)
Nmap done: 1 IP address (1 host up) scanned in 1.34 seconds
You can see that ssh is listening on port 22 (★).
On the other ports, you can see that the packet filter (iptables) has dropped the packet.
By the way, service names such as ssh are registered in / etc / services.
7 How to scan UDP ports (-sU)
7.1 How to specify a specific port number (-p)
Check the open port number on the server side.
You can see that the server side only opens the TCP ssh (22) port.
UDP port numbers have not been released. server
[root @ server ~] # firewall-cmd --list-ports
[root @ server ~] # firewall-cmd --list-services ssh
Next, try performing a port scan on UDP port 11111. You can see that
the packet destined for port 11111
has been filtered by the packet filter (iptables) . client
[root @ client ~] # nmap -sU -p11111 server
Starting Nmap 6.40 (http://nmap.org) at 2018-11-03 20:53 JST
Nmap scan report for server (192.168.3.50)
Host is up (0.00072s latency).
PORT STATE SERVICE
11111 / udp filtered unknown
MAC Address: xx: xx: xx: xx: xx: xx (VMware)
Nmap done: 1 IP address (1 host up) scanned in 0.16 seconds
The result of tcpdump confirmed at this time is shown below. You can see that
the
server is returning an “admin prohibited” ICMP packet because the packet filter prohibits access to port 11111 . Results of tcpdump
client server (11111 / UDP)
| |
| ------------------------- UDP packet ----------------------- -> |
| <---- ICMP host 192.168.3.50 unreachable admin prohibited ---- |
7.2 Experiment 1
Try freeing UDP port 11111.
Let’s see how the nmap execution result changes from 7.1. server
Allow access to UDP port 11111.
[root @ server ~] # firewall-cmd --add-port = 11111 / udp
success
Check the open port number (numerical value). You can see that UDP port 11111 is open.
[root @ server ~] # firewall-cmd --list-ports
11111 / udp
Check the open port number (service name). You can see that ssh (22) is open.
[root @ server ~] # firewall-cmd --list-services
ssh
Try performing a port scan on UDP port 11111.
This time, the port state changed from filtered to closed.
You can see that the port scan packets did not get dropped by the packet filter and reached the UDP layer. client
[root @ client ~] # nmap -sU -p11111 server
Starting Nmap 6.40 (http://nmap.org) at 2018-11-03 21:12 JST
Nmap scan report for server (192.168.3.50)
Host is up (0.00045s latency).
PORT STATE SERVICE
11111 / udp closed unknown
MAC Address: xx: xx: xx: xx: xx: xx (VMware)
Nmap done: 1 IP address (1 host up) scanned in 0.12 seconds
The result of tcpdump confirmed at this time is shown below.
The
server is sending an ICMP port unreachable to the client because no process is listening on UDP port 11111 . Results of tcpdump
client server (11111 / UDP)
| |
| ------------------------- UDP packet ----------------------- -> |
| <-------- ICMP 192.168.3.50 udp port 11111 unreachable ------- |
7.3 Experiment 2
Try starting the nc process on UDP port 11111. server
[root @ server ~] # firewall-cmd --list-ports
11111 / udp
[root @ server ~] # firewall-cmd --list-services
ssh
Start the nc process. It listens on UDP port 11111.
[root @ server ~] # nc -ul 11111 &
[1] 1610
Check the status of port 11111. You can see that the nc process is waiting.
[root @ server ~] # lsof -i : 11111
COMMAND PID USER FD TYPE DEVICE SIZE / OFF NODE NAME
nc 1610 root 3u IPv6 21076 0t0 UDP *: vce
nc 1610 root 4u IPv4 21077 0t0 UDP *: vce
The
port status is open because there is a process listening on UDP port 11111 .
However, it may be open or it may remain closed.
I’m not sure why. Is it a bug? Or is it used incorrectly ??? client
[root @ client ~] # nmap -sU -p11111 server
Starting Nmap 6.40 (http://nmap.org) at 2018-11-04 17:52 JST
Nmap scan report for server (192.168.3.50)
Host is up (0.00049s latency).
PORT STATE SERVICE
11111 / udp open unknown
MAC Address: xx: xx: xx: xx: xx: xx (VMware)
Nmap done: 1 IP address (1 host up) scanned in 0.13 seconds
8 How to display a list of hosts in the network
8.1 How to use ARP (-sn)
Use ARP to check for hosts that exist at 192.168.3.0/24.
Sends an ARP request to all hosts in the network.
The host that sent the ARP reply is displayed as “Host is up.”
You can see that there are a total of 6 hosts. client
[root @ client ~] # nmap -sn 192.168.3.0/24
Starting Nmap 6.40 (http://nmap.org) at 2018-11-03 23:09 JST
Nmap scan report for local.gateway (192.168.3.1)
Host is up (0.0014s latency).
MAC Address: xx: xx: xx: xx: xx: xx (Hon Hai Precision Ind. Co.)
Nmap scan report for 192.168.3.2
Host is up (0.0010s latency).
MAC Address: xx: xx: xx: xx: xx: xx (NEC Access Technica)
Nmap scan report for 192.168.3.3
Host is up (0.00051s latency).
MAC Address: xx: xx: xx: xx: xx: xx (Unknown)
Nmap scan report for server (192.168.3.50)
Host is up (0.00036s latency).
MAC Address: xx: xx: xx: xx: xx: xx (VMware)
Nmap scan report for 192.168.3.4
Host is up.
Nmap scan report for client (192.168.3.20)
Host is up.
Nmap done: 256 IP addresses (6 hosts up) scanned in 2.09 seconds
Next, let’s check the state when nmap is executed using tcpdump.
The client (192.168.3.20) is sending an ARP request to the server (192.168.3.50).
Then, the server is returning an ARP response.
When there is an ARP response like this, “Host is up.” Is displayed. tcpdump execution result
[root @ server ~] # tcpdump -i eth0 arp -nn
10: 14: 51.583118 ARP, Request who-has 192.168.3.50 (ff: ff: ff: ff: ff: ff) tell 192.168.3.20, length 46
10: 14: 51.583125 ARP, Reply 192.168.3.50 is-at xx: xx: xx: xx: xx: xx: 66, length 28
(Others omitted)
In addition, -sn: Ping Scan - disable port scan
since it is described in man,
I thought that I was using ICMP packets clearly, but it was not so.
8.2 How to find hosts by hosts file and reverse DNS lookup (-sL)
Let’s display the hosts that exist in the network of 192.168.3.0/24.
You can see that there are three machines: router (192.168.3.1), server, and client. client
[root @ client ~] # nmap -sL 192.168.3.0/24
Starting Nmap 6.40 (http://nmap.org) at 2018-11-03 18:07 JST
Nmap scan report for 192.168.3.0
Nmap scan report for local.gateway (192.168.3.1)
::
Nmap scan report for client (192.168.3.20)
::
Nmap scan report for server (192.168.3.50)
::
Nmap scan report for 192.168.3.255
Nmap done: 256 IP addresses (0 hosts up) scanned in 15.54 seconds
8.3 How to exclude a specific host from a port scan (–exclude)
Try excluding 192.168.3.1 and 192.168.3.50 from port scanning. When using the -sL option
[root @ client ~] # nmap --exclude 192.168.3.50, 192.168.3.1 -sL 192.168.3.0/24
Starting Nmap 6.40 (http://nmap.org) at 2018-11-04 19:51 JST
Nmap scan report for 192.168.3.0
Nmap scan report for 192.168.3.2
(Hereafter omitted)
Nmap scan report for 192.168.3.51
Nmap scan report for 192.168.3.52
(Hereafter omitted)
When using the -sn option
[root @ client ~] # nmap --exclude 192.168.3.50, 192.168.3.1 -sn 192.168.3.0/24
Starting Nmap 6.40 (http://nmap.org) at 2018-11-04 19:53 JST
Nmap scan report for 192.168.3.2
Host is up (0.00049s latency).
MAC Address: xx: xx: xx: xx: xx: xx (NEC Access Technica)
Nmap scan report for 192.168.3.3
Host is up (0.00025s latency).
MAC Address: xx: xx: xx: xx: xx: xx (Unknown)
Nmap scan report for 192.168.3.4
Host is up.
Nmap scan report for client (192.168.3.20)
Host is up.
Nmap done: 254 IP addresses (4 hosts up) scanned in 2.09 seconds
9 How to do packet tracing (–packet-trace)
--packet-trace
By using the option, you can see the interaction between the server and the client.
In the example below, we first use ARP to get the MAC address of the server (xx: xx: xx: xx: xx: xx).
Next, the client is sending a SYN packet to port 11111 on the server.
After that, the server sends a SYN + ACK packet back to the client.
[root @ client ~] # nmap --packet-trace -p11111 server
Starting Nmap 6.40 (http://nmap.org) at 2018-11-04 19:04 JST
SENT (0.0767s) ARP who-has 192.168.3.50 tell 192.168.3.20
RCVD (0.0771s) ARP reply 192.168.3.50 is-at xx: xx: xx: xx: xx: xx
SENT (0.1018s) TCP 192.168.3.20:48451> 192.168.3.50:11111 S ttl = 53 id = 33701 iplen = 44 seq = 3113298251 win = 1024 <mss 1460>
RCVD (0.1021s) TCP 192.168.3.50:11111> 192.168.3.20:48451 SA ttl = 64 id = 0 iplen = 44 seq = 4075689197 win = 29200 <mss 1460>
Nmap scan report for server (192.168.3.50)
Host is up (0.00036s latency).
PORT STATE SERVICE
11111 / tcp open vce
MAC Address: xx: xx: xx: xx: xx: xx (VMware)
Nmap done: 1 IP address (1 host up) scanned in 0.13 seconds
10 How to fix the source port number (-g)
-g
If you specify, you can fix the source port number of the port scan.-g
If you do not specify, the source port number changes each time you send a port scan packet.
In the example below, the source port number is fixed at 22222.
[root @ client ~] # nmap --packet-trace -g 22222 -p11111 server
Starting Nmap 6.40 (http://nmap.org) at 2018-11-04 19:22 JST
SENT (0.0729s) ARP who-has 192.168.3.50 tell 192.168.3.20
RCVD (0.0733s) ARP reply 192.168.3.50 is-at 00: 00C: 29: A8: BF: 66
SENT (0.0979s) TCP 192.168.3.20:22222> 192.168.3.50:11111 Sttl = 38 id = 39553 iplen = 44 seq = 2791699799 win = 1024 <mss 1460>
RCVD (0.0982s) TCP 192.168.3.50:11111> 192.168.3.20:22222 SA ttl = 64 id = 0 iplen = 44 seq = 916547350 win = 29200 <mss 1460>
Nmap scan report for server (192.168.3.50)
Host is up (0.00034s latency).
PORT STATE SERVICE
11111 / tcp open vce
MAC Address: xx: xx: xx: xx: xx: xx (VMware)
Nmap done: 1 IP address (1 host up) scanned in 0.12 seconds
12 How to check the service version
12.1 How to check the version (-sV)
server
Check the version of httpd.
[root @ server ~] # httpd -v
Server version: Apache / 2.4.6 (CentOS)
Server built: Apr 20 2018 18:10:38
client
Let's check the version of httpd running on the server.
[root @ client ~] # nmap -sV -p80 server
Starting Nmap 6.40 (http://nmap.org) at 2018-11-04 21:46 JST
Nmap scan report for server (192.168.3.50)
Host is up (0.00044s latency).
PORT STATE SERVICE VERSION
80 / tcp open http Apache httpd 2.4.6 ((CentOS))
(Hereafter omitted)
12.2 Experiment
Try starting the nc process on port 80. When a service other than httpd is operated on port 80
Let's run the nc process on port 80.
[root @ server ~] # nc -kl 80 &
[1] 2796
You can see that the nc process is listening on port 80.
[root @ server ~] # lsof -i: 80
COMMAND PID USER FD TYPE DEVICE SIZE / OFF NODE NAME
nc 2796 root 4u IPv6 52764 0t0 TCP *: http (LISTEN)
nc 2796 root 5u IPv4 52765 0t0 TCP *: http (LISTEN)
You can see that the version cannot be determined and http? Is displayed.
[root @ client ~] # nmap -sV -p80 server
Starting Nmap 6.40 (http://nmap.org) at 2018-11-04 21:53 JST
Nmap scan report for server (192.168.3.50)
Host is up (0.00046s latency).
PORT STATE SERVICE VERSION
80 / tcp open http?
13 How to check the result of port scan (–reason)
13.1 Port is not released
server
Check the open port number (numerical value). You can see that nothing has been released.
[root @ server ~] # firewall-cmd --list-ports
Check the open port number (service name). You can see that ssh (22) is open.
[root @ server ~] # firewall-cmd --list-services
ssh
Try performing a port scan on port 11111.
If you check the REASON of the execution result, you can see that it is “host-prohibited”.
In other words, you can see that the packet filter is dropping the port scan packets. client
[root @ client ~] # nmap --reason -p11111 server
Starting Nmap 6.40 (http://nmap.org) at 2018-11-04 22:26 JST
Nmap scan report for server (192.168.3.50)
Host is up, received arp-response (0.00051s latency).
PORT STATE SERVICE REASON
11111 / tcp filtered vce host-prohibited
(Hereafter omitted)
13.2 You released a port, but there is no service to listen on the released port
server
Allows access to TCP port 11111.
[root @ server ~] # firewall-cmd --add-port = 11111 / tcp
success
Check the open port number (numerical value). You can see that port 11111 is open.
[root @ server ~] # firewall-cmd --list-ports
11111 / tcp
Check the open port number (service name). You can see that ssh (22) is open.
[root @ server ~] # firewall-cmd --list-services
ssh
Try performing a port scan on port 11111.
If you check the REASON of the execution result, you can see that it is “reset”.
In other words,
you can see that the port scan packet has reached TCP, but there is no process to listen to. client
[root @ client ~] # nmap --reason -p11111 server
Starting Nmap 6.40 (http://nmap.org) at 2018-11-04 22:27 JST
Nmap scan report for server (192.168.3.50)
Host is up, received arp-response (0.00054s latency).
PORT STATE SERVICE REASON
11111 / tcp closed vce reset
13.3 If there is a process listening on an open port
server
Start the nc process on port 11111.
[root @ server ~] # nc -kl 11111 &
[2] 3113
Check the status of port 11111. You can see that the nc process is listening.
[root @ server ~] # lsof -i : 11111
COMMAND PID USER FD TYPE DEVICE SIZE / OFF NODE NAME
nc 3113 root 4u IPv6 53031 0t0 TCP *: vce (LISTEN)
nc 3113 root 5u IPv4 53032 0t0 TCP *: vce (LISTEN)
Check the open port number (numerical value). You can see that port 11111 is open.
[root @ server ~] # firewall-cmd --list-ports
11111 / tcp
Check the open port number (service name). You can see that ssh (22) is open.
[root @ server ~] # firewall-cmd --list-services
ssh
Try performing a port scan on port 11111.
If you check the REASON of the execution result, you can see that it is “syn-ack”.
In other words, you can see that TCP replied syn-ack because there is a process to listen. client
[root @ client ~] # nmap --reason -p11111 server
Starting Nmap 6.40 (http://nmap.org) at 2018-11-04 22:31 JST
Nmap scan report for server (192.168.3.50)
Host is up, received arp-response (0.00047s latency).
PORT STATE SERVICE REASON
11111 / tcp open vce syn-ack
(Hereafter omitted)
14 Advanced Usage
List hosts that are online
$ nmap -sP <IP Range>
This command communicates with the host as follows.
- ICMP echo request
- SYN to port 443
- ACK to port 80
- ICMP timestamp request
Host search
Check the OS of the corresponding host
$ nmap -O <IP>
Look up the host name
$ nmap -sL <IP>
Scan to basic TCP / UDP ports
$ nmap -sS -sU -Pn <IP>
Scans to general TCP / UDP ports (about 2000 ports).
In nmap, communication is confirmed by ping before scanning, but if ICMP is stopped by a firewall etc., scanning is not possible, so an -Pn
option is added to skip the preliminary Ping scan.
Fast scan
$ nmap -T4 -F <IP>
Scan only frequently used ports
Find out more about running services
$ nmap -T4 -A <IP>
Investigate all detailed information
$ nmap -T4 -A -v <IP>
Check the protocol version of the target port
$ nmap -sV -p <Port> <IP>
Check if it is protected by a firewall
nmap -sA <IP>
If the output is filtered, it is protected.