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.
À propos de l'auteur
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.
Plus de résultats similaires
Friday Five — January 9, 2026 | Red Hat
Smarter troubleshooting with the new MCP server for Red Hat Enterprise Linux (now in developer preview)
Technically Speaking | Build a production-ready AI toolbox
AI Is Changing The Threat Landscape | Compiler
Parcourir par canal
Automatisation
Les dernières nouveautés en matière d'automatisation informatique pour les technologies, les équipes et les environnements
Intelligence artificielle
Actualité sur les plateformes qui permettent aux clients d'exécuter des charges de travail d'IA sur tout type d'environnement
Cloud hybride ouvert
Découvrez comment créer un avenir flexible grâce au cloud hybride
Sécurité
Les dernières actualités sur la façon dont nous réduisons les risques dans tous les environnements et technologies
Edge computing
Actualité sur les plateformes qui simplifient les opérations en périphérie
Infrastructure
Les dernières nouveautés sur la plateforme Linux d'entreprise leader au monde
Applications
À l’intérieur de nos solutions aux défis d’application les plus difficiles
Virtualisation
L'avenir de la virtualisation d'entreprise pour vos charges de travail sur site ou sur le cloud