Mi az Nmap? A hálózati felderítés eszköze, amit minden fejlesztőnek ismernie kell

Van egy VPS-ed. Fut rajta a weboldal, egy adatbázis, talán egy admin felület. Meg tudnád mondani fejből, hogy pontosan mely portok érhetők el kívülről? A legtöbb fejlesztő és cégvezető nem tudja, és pont ebben a résben szoktak megtörténni a kellemetlen meglepetések: egy elfelejtett teszt-szolgáltatás, egy Docker-konténer, ami magának nyitott portot, vagy egy adatbázis, ami nem csak a localhoston figyel.

Az Nmap pontosan erre a kérdésre ad választ. Ebben a cikkben végigvesszük, mi az Nmap, hogyan működik technikailag, milyen parancsokkal auditálhatod vele a saját infrastruktúrádat, és, ami legalább ilyen fontos, hol húzódnak a jogi határok Magyarországon.

Fontos előljáróban: az Nmap legális eszköz, de csak a saját, vagy írásban engedélyezett rendszereden használd. A cikk végén részletesen kitérünk arra, miért.

Mi az Nmap? A rövid válasz

Az Nmap (Network Mapper) ingyenes, nyílt forráskódú hálózatfelderítő és biztonsági auditáló eszköz. A működése egyszerű elven alapul: csomagokat küld a megadott célpontnak, majd a beérkező válaszokból (vagy azok hiányából) következtet arra, milyen eszközök, szolgáltatások és operációs rendszerek vannak a hálózaton.

Néhány tény, ami elhelyezi a képet:

• Készítője: Gordon Lyon, ismertebb nevén Fyodor.
• Első kiadás: 1997. szeptember, a Phrack magazin 51. számában, „The Art of Port Scanning" címmel. Az első verzió kb. 2000 sor kód volt, és csak Linuxon futott.
• Jelenlegi stabil verzió: 7.99 (2026. március 26.).
• Licenc: 2020 óta NPSL (Nmap Public Source License), GPLv2-alapú, de a proprietary szoftverbe építéshez külön OEM-licenc kell.
• Kiegészítők: Zenmap (grafikus felület), Ncat, Ndiff, Nping.

Ami miatt 25+ év után is az iparági sztenderd: a pontossága. Sok eszköz gyorsabb nála, de kevés ad ilyen részletes képet a szolgáltatásverziókról, az operációs rendszerről és a tűzfal viselkedéséről.

Mire jó valójában? 5 legitim felhasználás

Az Nmap-et sokan „hacker-eszközként" könyvelik el. A valóságban a mindennapi üzemeltetés eszköze, nagyjából úgy, ahogy egy feszültségmérő a villanyszerelőé.

1. Hálózati inventár. Mi van egyáltalán a hálózaton? Egy irodai vagy szerverhálózaton meglepően gyakran találni olyan eszközt, amiről senki nem tudott: egy régi nyomtatót, egy elfelejtett IoT-eszközt, egy kolléga tesztgépét.

2. Támadási felület felmérése. Mely portok érhetők el kívülről a szervereiden? Ez a legfontosabb kérdés, amire egy KKV-nak választ kell tudnia adni.

3. Tűzfal-ellenőrzés. Tényleg azt csinálja a tűzfalad, amit gondolsz? Egy szkennelés kívülről azonnal megmutatja, hogy a szabályaid működnek-e a gyakorlatban is.

4. Verzió-audit. Milyen szolgáltatásverziók futnak? Egy elavult OpenSSH, nginx vagy adatbáziskiszolgáló ismert sebezhetőségeket hordozhat.

5. Hibakeresés. „Nem érem el a szolgáltatást." Nyitva van egyáltalán a port? Szűri valami? Az Nmap sokszor másodpercek alatt megválaszolja azt, amit különben fél óra találgatás lenne.

Hogyan működik? A szkennelés fázisai

Az Nmap egy szkennelés során több lépcsőn megy végig:

1. Célpont-felsorolás, feldolgozza, amit megadtál (hostnév, IP-cím, CIDR-tartomány).
2. Hoszt-felderítés (host discovery), megnézi, mely gépek élnek egyáltalán. Ez a „ping sweep", bár nem csak ICMP pinget használ.
3. Fordított DNS-feloldás, megpróbálja kideríteni a hosztneveket.
4. Portszkennelés, a tényleges vizsgálat.
5. Verziófelismerés (-sV), mi fut a nyitott portokon.
6. OS-detektálás (-O), milyen operációs rendszer.
7. Traceroute, az útvonal a célpontig.
8. NSE-szkriptek, mélyebb vizsgálatok.

Az egész a TCP kapcsolatfelépítés logikájára épül. A háromutas kézfogás (three-way handshake) így néz ki normál esetben:

Kliens  →  SYN      →  Szerver     (kapcsolatot kezdeményezek)
Kliens  ←  SYN/ACK  ←  Szerver     (rendben, én is)
Kliens  →  ACK      →  Szerver     (megerősítve)

Ha a port zárva van, a szerver nem SYN/ACK-kal, hanem RST (reset) csomaggal válaszol. Ha pedig egy tűzfal blokkol, jellemzően semmilyen válasz nem érkezik. Ez a három eset, SYN/ACK, RST, csend, adja az Nmap alapvető információját.

A hat portállapot, a legfontosabb, amit meg kell értened

Ha csak egyetlen dolgot viszel el ebből a cikkből, ez legyen az. Az Nmap nem „nyitva/zárva" bontásban gondolkodik, hanem hat állapotot különböztet meg:

A gyakorlati fordítás: ha egy külső szkennelés sok filtered portot mutat és csak néhány open-t, a tűzfalad jól van beállítva. Ha viszont váratlanul sok open portot látsz, ott van dolgod.

Egy tipikus, egészséges webszerver kívülről nagyjából így néz ki: 22 (SSH, ideális esetben szűrve vagy IP-korlátozva), 80 és 443 (HTTP/HTTPS) nyitva, minden más filtered. Ha ebben a képben megjelenik egy 3306 (MySQL), 5432 (PostgreSQL), 6379 (Redis) vagy 27017 (MongoDB) open állapotban, azt azonnal orvosolni kell.

Szkennelési típusok: SYN, connect, UDP, ACK

TCP SYN scan (-sS), az alapértelmezett, ha van root jogosultságod. Küld egy SYN-t, és ha SYN/ACK-ot kap, RST-tel azonnal lezárja a kapcsolatot ahelyett, hogy befejezné a kézfogást. Innen a „half-open" elnevezés. Gyors, és megbízhatóan elkülöníti az open/closed/filtered állapotot.

TCP connect scan (-sT), ha nincs root jog, az Nmap az operációs rendszer connect() hívását használja, vagyis teljes kapcsolatot épít fel. Lassabb, több csomagot generál, és a célgép nagyobb eséllyel naplózza.

UDP scan (-sU), az UDP-portokat vizsgálja. Sokkal lassabb, mint a TCP-szkennelés, két okból: a nyitott UDP-portok gyakran egyáltalán nem válaszolnak (ezért lesz sok open|filtered), a zárt portok pedig ICMP-hibaüzenettel felelnek, amit a legtöbb rendszer sebességkorlátoz. Egy teljes UDP-szkennelés simán eltarthat órákig, de a DNS, SNMP vagy NTP szolgáltatásokat csak így látod.

ACK scan (-sA), nem azt deríti ki, nyitva van-e a port, hanem hogy szűri-e valami. Tűzfalszabályok feltérképezésére való.

Időzítés: a -T kapcsoló

Az Nmap hat időzítési sablont kínál -T0-tól -T5-ig:

A kompromisszum egyszerű: minél gyorsabb a szkennelés, annál nagyobb a terhelés a célrendszeren, és annál nagyobb az esélye, hogy csomagvesztés miatt pontatlan lesz az eredmény.

Verzió- és operációsrendszer-felismerés

Verziófelismerés (-sV). A nyitott portokra szondákat küld, majd a válaszokat összeveti egy fingerprint-adatbázissal. Így nem csak azt tudod meg, hogy a 443-as port nyitva van, hanem azt is, hogy nginx 1.24.0 fut rajta. Ez az audit szempontjából kulcsfontosságú: az elavult verziók azonosítása innen indul.

OS-detektálás (-O). Az Nmap TCP/IP stack fingerprintinget használ: legfeljebb 16 különböző szondát küld, és több tucat apró jellemzőt elemez, a TCP kezdeti szekvenciaszám mintázatát, a TCP-opciók sorrendjét, az IP ID viselkedését, a kezdeti ablakméretet. Az eredményt több mint 2600 ismert ujjlenyomattal veti össze.

Fontos korlát: az OS-detektálás nem 100%-os. A legjobb eredményhez kell egy nyitott ÉS egy zárt port a célgépen; a tűzfalak módosíthatják a válaszokat; a csomagvesztés rontja a pontosságot. Ezért ad az Nmap gyakran csak százalékos tippet, például: Linux 5.x (94%).

NSE: az Nmap szkriptmotorja

Az NSE (Nmap Scripting Engine) Lua nyelvű szkriptekkel bővíti az eszközt. Több száz szkript érhető el, 14 kategóriába sorolva (safe, default, discovery, version, vuln, auth, brute, intrusive és így tovább).

Néhány, ami a mindennapi üzemeltetésben tényleg hasznos:

• ssl-enum-ciphers, felsorolja a szervered által elfogadott TLS ciphersuite-okat, és A-tól F-ig osztályozza őket. Azonnal látod, ha gyenge titkosítás vagy elavult protokollverzió maradt engedélyezve.
• ssl-cert, tanúsítványadatok, köztük a lejárati dátum.
• http-headers, a HTTP-válaszfejlécek, ahol ellenőrizheted a biztonsági headereket.

Figyelem a --script all kapcsolóval: minden szkriptet lefuttat, beleértve az exploit, brute és dos kategóriákat is. Éles rendszeren ez kárt okozhat. Maradj a default és safe kategóriáknál, hacsak nincs jó okod másra.

Gyakorlati parancsok a saját infrastruktúrádon

Telepítés:

# Debian / Ubuntu
sudo apt update && sudo apt install nmap

# Fedora / RHEL
sudo dnf install nmap

# macOS
brew install nmap

# Windows
winget install Insecure.Nmap

nmap --version   # ellenőrzés

A leggyakoribb parancsok (mindegyik a saját szerveredre vagy hálózatodra):

# Alapszkennelés, a leggyakoribb 1000 TCP port
nmap sajat-szervered.hu

# Hálózati inventár: mely eszközök élnek a saját alhálózaton?
nmap -sn 192.168.1.0/24

# Gyors ellenőrzés, csak a top 100 port
nmap -F sajat-szervered.hu

# Teljes portrange, mind a 65535 port. Lassú, de ez a valódi kép
nmap -p- sajat-szervered.hu

# Szolgáltatásverziók felderítése
nmap -sV -p- sajat-szervered.hu

# SYN scan a saját alhálózaton, gyorsítva (root jog kell)
sudo nmap -sS -T4 192.168.1.0/24

# TLS-konfiguráció auditálása
nmap --script ssl-enum-ciphers -p 443 sajat-szervered.hu

# Teljes kép: OS, verzió, szkriptek, traceroute
sudo nmap -A sajat-szervered.hu

A leghasznosabb egyetlen parancs, ha most kezdenéd, futtasd a VPS-ed publikus IP-jére egy másik gépről:

nmap -p- -sV sajat-vps-ip-cime

Ez megmutatja, mit lát rólad a külvilág. A tapasztalat az, hogy itt szokott előkerülni a meglepetés.

Amire cloud- és konténerkörnyezetben figyelj

• A cloud provider tűzfala (security group) a VM saját tűzfala előtt van. Emiatt egy port kívülről filtered-nek látszhat, miközben a gépen belül nyitva van. Ezért érdemes kívülről ÉS a hálózaton belülről is szkennelni.
• A Docker alapértelmezetten megkerülheti az ufw szabályokat, mert közvetlenül az iptables-be ír. Ez az egyik leggyakoribb oka a véletlenül kitett adatbázisoknak.
• A publikus IP és a belső hálózati cím teljesen más képet adhat, mindkettőt nézd meg.

Változáskövetés: az igazi üzleti érték

Egy egyszeri szkennelés pillanatkép. A valódi érték az, ha észreveszed, amikor változik valami. Erre való az ndiff, ami két Nmap XML-kimenet különbségét mutatja meg.

# Első szkennelés, XML kimenettel
nmap -oX alap.xml -sV -p- sajat-vps-ip

# Egy héttel később
nmap -oX aktualis.xml -sV -p- sajat-vps-ip

# Mi változott?
ndiff alap.xml aktualis.xml

Az ndiff megmutatja az új és eltűnt hosztokat, a portállapot-változásokat és a szolgáltatásverzió-eltéréseket. Ezt cronból futtatva és riasztásra kötve kapsz egy egyszerű, de meglepően hatásos felügyeletet: ha holnap valaki kinyit egy portot, arról tudni fogsz.

Ez az a pont, ahol az Nmap átlép a „megnézem egyszer" kategóriából a folyamatos üzemeltetési gyakorlatba, és pontosan ez az, amit egy automatizált folyamatba érdemes kötni.

Alternatívák: Masscan, RustScan, Nessus

Az Nmap nem az egyetlen eszköz, és nem is mindig a legjobb választás.

Két megjegyzés a táblázathoz. Egyrészt a Masscan nagyságrendekkel gyorsabb (a szerzője szerint megfelelő hardveren percek alatt végigmegy a teljes interneten), de csak azt mondja meg, hogy egy port nyitva van, semmit nem tud a szolgáltatásról. Ezért terjedt el a kombinált munkafolyamat: gyors előszűrés Masscannel vagy RustScannel, majd részletes vizsgálat Nmappel a megtalált portokon.

Másrészt a Nessus és az OpenVAS más kategória: ezek sebezhetőség-szkennerek, amelyek a felismert szolgáltatásokat ismert CVE-khez kötik. Az Nmap megmondja, hogy OpenSSH 8.2 fut nálad; egy sebezhetőség-szkenner azt is, hogy ehhez milyen ismert hibák tartoznak.

Legális az Nmap? A jogi keret Magyarországon

Ez a leggyakoribb kérdés a téma kapcsán, és megérdemel egy tisztességes választ.

Maga az eszköz teljesen legális. Szabadon letölthető, disztribúciók csomagkezelőiben elérhető, egyetemi kurzusokon tanítják. A kérdés soha nem az eszköz, hanem a használat módja és célpontja.

Saját rendszer: nincs kérdés

A saját szervereid, a saját hálózatod, a saját eszközeid szkennelése teljesen jogszerű. Sőt, egy alapos üzemeltető rutinszerűen csinálja.

Idegen rendszer: itt kezdődnek a problémák

A magyar Büntető Törvénykönyv 423. §-a (információs rendszer vagy adat megsértése) az, ami a témát érinti. Az (1) bekezdés azt bünteti, ha valaki „információs rendszerbe az információs rendszer védelmét biztosító technikai intézkedés megsértésével vagy kijátszásával jogosulatlanul belép", illetve ha a jogosultságát túllépve bent marad. A büntetési tétel két évig terjedő szabadságvesztés.

A jogi helyzet a puszta portszkennelés kapcsán nem teljesen tisztázott. A tényállás konjunktív feltételeket kíván: kell a belépés a rendszerbe, kell a jogosulatlanság, és kell a védelmi intézkedés megsértése vagy kijátszása. Mivel a puszta portszkennelés nem lép be a rendszerbe, dogmatikailag vitatható, hogy kimeríti-e a tényállást, de nincs ismert magyar bírósági precedens, ami ezt egyértelműen kimondaná. A szakirodalomban is megjelenik az az álláspont, hogy a kéretlen sérülékenységvizsgálat tényállásszerű lehet.

Ez nem minősül jogi tanácsadásnak. Konkrét ügyben ügyvédhez fordulj.

Amit a jogi bizonytalanságon túl is figyelembe kell venni

A szolgáltatói szerződések. Ez sokakat meglep: a legtöbb VPS- és felhőszolgáltató szerződése (AUP, Acceptable Use Policy) önmagában tiltja az idegen rendszerek szkennelését, a jogi helyzettől függetlenül.

• A DigitalOcean feltételei kifejezetten tiltják a rendszerek vagy hálózatok szkennelését és sebezhetőség-tesztelését előzetes írásbeli hozzájárulás nélkül.
• A Hetzner automatikus „netscan" észlelése miatt a szervered akár néhány percen belül null-route-ra vagy leállításra kerülhet, nem ritka, hogy ez teljesen legitim szoftver hálózati viselkedése miatt történik meg.
• Az AWS 2019 óta engedélyez bizonyos biztonsági tesztelést a saját erőforrásaidon előzetes engedély nélkül, de csak egy meghatározott szolgáltatáslistán belül, és más ügyfelek erőforrásait érinteni továbbra is tilos.

A nemzetközi kitekintés. Németországban a StGB §202c („Hackerparagraf") a hacker-eszközök készítését és megszerzését bünteti, ha bűncselekmény előkészítése a cél. Az Egyesült Királyságban a Computer Misuse Act alapján vitatott, hogy a szkennelés „hozzáférésnek" minősül-e. Az Egyesült Államokban a CFAA jelent hasonló bizonytalanságot. Maga Fyodor, az Nmap szerzője is jelezte az aggodalmát ezekkel a szabályozásokkal kapcsolatban.

A gyakorlati szabály

Csak azt szkenneld, ami a tiéd, vagy amire írásos engedélyed van. Egy pentest-megbízásnál ez egy scope-megállapodás, amely rögzíti: mely IP-címek és domainek tartoznak bele, mi van kizárva, milyen időablakban végezhető a teszt, milyen technikák megengedettek, és ki a kapcsolattartó mindkét oldalon. Enélkül ne kezdj hozzá.

Ha idegen rendszereken szeretnél legálisan gyakorolni, arra valók a bug bounty programok és a dedikált gyakorlókörnyezetek, ezek előre meghatározott scope-pal és engedéllyel működnek.

NIS2: miért lett ez üzleti kérdés is?

Érdemes tudni, hogy a téma 2026-ban már nem csak technikai. A NIS2 irányelv magyar implementációja (2024. évi LXIX. törvény Magyarország kiberbiztonságáról, hatályos 2025. január 1-től) az érintett szervezetek széles körének ír elő kiberbiztonsági kötelezettségeket, köztük rendszeres auditot. Az első kiberbiztonsági audit határideje 2026. június 30. volt.

Vagyis: ha a céged a törvény hatálya alá esik, a rendszereid rendszeres felmérése már nem jó gyakorlat kérdése, hanem jogszabályi kötelezettség.

Védekezés: hogyan csökkentsd a támadási felületet

Ha megnézted, mi látszik kívülről, jön a fontosabb rész: mit kezdesz az eredménnyel.

1. A minimális nyitott portok elve. Minden nyitott portot indokolni kell tudni. Ha nem tudod megmondani, mi és miért figyel egy porton, valószínűleg be kell zárni.

2. Tűzfal alapértelmezett tiltással. Az ufw, nftables vagy a felhőszolgáltatód security group-ja alapértelmezetten mindent tiltson, és csak a szükséges portokat engedje.

3. Adminfelületek VPN mögé. Az SSH, adatbázis-portok és admin felületek ne legyenek nyilvánosan elérhetők. Ha muszáj, korlátozd IP-címre.

4. Docker-figyelmeztetés. Ellenőrizd, hogy a konténereid nem kerülik-e meg a tűzfalszabályaidat. A -p 3306:3306 publikálás sokszor nem azt jelenti, amire számítasz.

5. Naplózás és rate limiting. A fail2ban és hasonló eszközök a naplómintázatok alapján bannolják a gyanús forrásokat. Egy IDS/IPS (Snort, Suricata) képes a szkennelési mintázatokat is felismerni, bár a nagyon lassú szkennelést gyakran nem szűri ki.

6. Rendszeres újraellenőrzés. Egyszeri audit után hat hónappal a kép már más lesz. Ezért éri meg az ndiff-alapú automatizált változáskövetés.

Gyakran ismételt kérdések

Nézzük meg együtt a rendszereidet?

A Dropsite weboldalakat, automatizálásokat és AI megoldásokat épít magyar vállalkozásoknak, és ehhez hozzátartozik, hogy a megépített rendszerek biztonságosan is üzemeljenek. Ha nem vagy biztos benne, mit lát a külvilág a szervereidből, vagy szeretnél egy rendszeres, automatizált ellenőrzést a folyamataidba építeni, írj nekünk.