I've used Nmap for years, and I continue to discover new things about it. For example, recently I was teaching someone to scan a remote host for open TCP ports and then changed the default SSH port to one not detected during a default Nmap scan. To my surprise, after we changed the port, a typical, quick hacker-style scan readily revealed my attempt at security by obscurity. The problem is that I changed the default SSH port to 2222, and the change was detected. A quick Nmap probe scans the 1,000 most popular ports, which I assumed were the ones between 1 and 1024, with the 1,000 number being the computer 1,000 (1,024).

Surprise! I was wrong.

The fact is that Nmap does indeed use 1,000 ports for a quick scan, but the operative word in the description above is that it uses the 1,000 most popular ports for scans. The 1,000 most popular ports are not bound by the first 1,024 consecutive ports. The 1,000 ports are all over the place—ranging from one to 65389.

To view these one-thousand ports, use the following command:

$ sudo nmap -sT --top-ports 1000 -v -oG -

# Nmap 7.70 scan initiated Mon Feb  3 12:12:04 2020 as: nmap -sT --top-ports 1000 -v -oG -
# Ports scanned: TCP(1000;1,3-4,6-7,9,13,17,19-26,30,32-33,37,42-43,49,53,70,79-85,88-90...

These are only the top 1,000 TCP ports. If you want to see the corresponding 1,000 UDP ports, use this command:

$ sudo nmap -sU --top-ports 1000 -v -oG -

# Nmap 7.70 scan initiated Mon Feb  3 12:51:41 2020 as: nmap -sU --top-ports 1000 -v -oG -
# Ports scanned: TCP(0;) UDP(1000;2-3,7,9,13,17,19-23,37-38,42,49,53,67-69,80,88,111-113,120,123,135-139,158,161-162,177,192,199,207...

Now, you might notice from your own command responses that these ports are in numerical order. That's fine for those who want to see all of the ports in numeric form (and in numerical order), but unless you're a port number savant, you might want a better guide—one that's more human-readable, at least. If so, try the following command:

$ sudo sort -r -k3 /usr/share/nmap/nmap-services

***information***
http	80/tcp	0.484143	# World Wide Web HTTP
ipp	631/udp	0.450281	# Internet Printing Protocol
snmp	161/udp	0.433467	# Simple Net Mgmt Proto
netbios-ns	137/udp	0.365163	# NETBIOS Name Service
ntp	123/udp	0.330879	# Network Time Protocol
netbios-dgm	138/udp	0.297830	# NETBIOS Datagram Service
ms-sql-m	1434/udp	0.293184	# Microsoft-SQL-Monitor
microsoft-ds	445/udp	0.253118
...

Hopefully, you're not surprised by the fact that HTTP (TCP port 80) is the top-listed (most popular) port. I don't know how often the nmap-services file changes. I performed a diff on my old version against my updated version and they're the same, between 7.70-4 and 7.70-5.

The point of showing you this information is so that you can place your configurable daemons outside of the standard scan range for Nmap. The reason for this is simple: If an attacker decides to scan your systems, they will likely have only one chance to perform the scan because of your internal monitoring and alerting (right?) of such probes. The attacker will take a chance on you either leaving your ports at their factory defaults or changing them to one of the 1,000 ports that show up in quick scans.

I know security by obscurity doesn't work for very long, but you can slow an attacker's chances of compromising a system by placing your systems just out of visible range. For example, by using a port such as 3022 for SSH rather than 2222, your system remains hidden for a little while longer, which might be enough to take it off of the low-hanging fruit list. A more serious or intense scan that takes a long time (hours possibly) is generally not on an attacker's radar. It's too likely that their cover will be blown by such an intrusive probe. Even a stealth scan that requires more than a few minutes to run increases the chances of being detected.

Remember that it's often negligence and ignoring the easy-to-do things that make your systems an easy target. Doing something is better than doing nothing. And having access to Nmap's inner workings can help you do a better job of securing your systems.

Want more on networking topics? Check out the Linux networking cheat sheet.


About the author

Ken has used Red Hat Linux since 1996 and has written ebooks, whitepapers, actual books, thousands of exam review questions, and hundreds of articles on open source and other topics. Ken also has 20+ years of experience as an enterprise sysadmin with Unix, Linux, Windows, and Virtualization.

Follow him on Twitter: @kenhess for a continuous feed of Sysadmin topics, film, and random rants.

In the evening after Ken replaces his red hat with his foil hat, he writes and makes films with varying degrees of success and acceptance. He is an award-winning filmmaker who constantly tries to convince everyone of his Renaissance Man status, also with varying degrees of success and acceptance.

UI_Icon-Red_Hat-Close-A-Black-RGB

Browse by channel

automation icon

Automation

The latest on IT automation for tech, teams, and environments

AI icon

Artificial intelligence

Updates on the platforms that free customers to run AI workloads anywhere

open hybrid cloud icon

Open hybrid cloud

Explore how we build a more flexible future with hybrid cloud

security icon

Security

The latest on how we reduce risks across environments and technologies

edge icon

Edge computing

Updates on the platforms that simplify operations at the edge

Infrastructure icon

Infrastructure

The latest on the world’s leading enterprise Linux platform

application development icon

Applications

Inside our solutions to the toughest application challenges

Virtualization icon

Virtualization

The future of enterprise virtualization for your workloads on-premise or across clouds