Alapszintű port szkennelés - Avagy hogyan ellenőrizhetjük Linux szerverünk biztonságát az illetéktelen behatolókkal szemben

botond küldte be 2022. 10. 23., v – 09:30 időpontban
Alapszintű port szkennelés - Avagy hogyan ellenőrizhetjük Linux szerverünk biztonságát az illetéktelen behatolókkal szemben | Linuxportál

Az 1. oldal tartalma

  1. oldal: TCP és UDP portok szkennelése az nmap parancs használatával
  2. oldal: TCP és UDP portok szkennelése a Netcat implementációk használatával

 

Tartalom

 

Bevezető

A kívülről történő port ellenőrzéskor port scan (port letapogatás) műveletet hajtunk végre a vizsgálni kívánt számítógépen, hogy kiderítsük hogy mely portok vannak nyitva, milyen szolgáltatások figyelik ezeket a portokat, stb. Port szkennelést általában a rendszergazdák a kiszolgáló biztonsági ellenőrzésének céljából hajtják végre, de sajnos gyakran rosszindulatú támadók is használják a kiszemelt célszámítógép gyenge pontjainak feltérképezésére.

Ebben a leírásban tehát megnézzük hogyan ellenőrizhetjük "kívülről" saját számítógépünk vagy szerverünk biztonságát az illetéktelen behatolókkal szemben.

 

 

Port szkennelés

A port scan művelet során a parancsot jellemzően egy másik számítógépről futtatjuk a vizsgálni kívánt célszámítógép IP-címének megadásával, de akár helyben is futtathatjuk; ekkor a cél megadásakor a 127.0.0.1 IP-címet vagy a localhost hosztnevet használjuk.

Bárhogy is használjuk ezeket a parancsokat, a port szkennelés működési elve ugyanaz: kívülről a hálózati interfészen keresztül közelíti meg a feladatot, ezért a lehetőségek korlátozottabbak, mintha belelátnánk a rendszerben működő folyamatokba vagy nyitott fájlokba, egy belülről indított port ellenőrzés esetén, stb. Ilyenkor a port scan műveletet végrehajtó program adatcsomagokat küldözget a célként megadott számítógép vagy kiszolgáló hálózati portjaira és a kapott válaszokat kielemezve - a közismert minták felhasználásának segítségével - megpróbálja kideríteni, hogy mely portokon milyen szolgáltatás működik. Persze ez a művelet nem ad 100% pontosságú eredményt, mivel előfordulhatnak olyan szolgáltatások, amik igyekeznek "kerülni a feltűnést" a kíváncsiskodók elől, és akár szándékosan is megtévesztő válaszokat adhatnak. De alapvetően az alapértelmezett portokon figyelő közismert szolgáltatások viszonylag nagy pontossággal felderíthetők. Ezért a biztonság növelésének érdekében a különböző szolgáltatások alapértelmezett portszámait gyakran átállítják egy nem ismert, egyedi portszámra, hogy a port szkenneléssel ne lehessen rájuk találni, vagy legalább megnehezítsék a keresési műveletet.

A port szkennelési művelet során tehát csak olyan információkat kapunk, hogy egy adott port nyitva van-e, és azon milyen szolgáltatás várja a kapcsolatokat - szemben a belülről történő port ellenőrzésekkel, amikor a portok aktív állapotait (aktív adatkommunikáció zajlik rajtuk) is meg lehet különböztetni a listen (figyelő) állapotuktól, valamint hogy az aktív portokon éppen hány szálon/csatornán zajlik kommunikáció, azaz hány kliens kapcsolódik hozzájuk (pl. Apache webkiszolgáló, FTP, SSH, stb.)
A kívülről történő port letapogatás esetén tehát csak a figyelő (listening) portokról kapunk információkat. A parancsok működési elvéből következően ez természetesen igaz a localhost vizsgálatok esetén is, tehát függetlenül attól hogy a vizsgált gépen futtatjuk-e a parancsot vagy egy távoli gépről: mindkét esetben a hálózati interfészen keresztül történik a kommunikáció.

Továbbá még azt is célszerű észben tartani, hogy a vizsgált számítógépen vagy szerveren tűzfal is működhet, ami például fehér listázásos módszerrel csak néhány IP-címről vagy tartományból engedi a kapcsolódást bizonyos szolgáltatásokhoz, mint például az SSH vagy SMTP, stb. Ilyenkor ha a szkennelést végző számítógép kívül esik ezen az engedélyezett tartományon, akkor a vizsgálat során nem fogja érzékelni ezeket a portokat, illetve szolgáltatásokat.
Természetesen most abból indulunk ki, hogy a saját szerverünket szeretnénk ellenőrizni, amin nincs ilyen tűzfalbeállítás, így tehát letapogathatjuk a valóban nyitott hálózati portjait.

Az ebben a leírásban szereplő példákat az asztali gépemről futtatva a Debian 10 (Buster) tökéletes szerver 1.0 virtuális gép utódján, az 1.1-es változaton hajtom végre, mivel ezen a szerveren már elég sok szolgáltatás működik ahhoz, hogy demonstrálni lehessen velük a portok szkennelését.

 

Portok kívülről történő ellenőrzésére szolgáló (port scan) parancsok

Egy másik leírásban már érintőlegesen foglalkoztunk a hálózati portok kívülről történő ellenőrzését végző parancsokkal, most lássuk ezeket részletesebben, kicsit közelebbről:

nmap

Az nmap parancs (Network Mapper) egy hatékony hálózatfelderítésre és biztonsági ellenőrzésre szolgáló segédeszköz. Sima felhasználóként is futtatható, de számos funkcióját csak root jogosultsággal tudjuk használni, tehát az itt következő részeket root jogosultságokkal hajtsuk végre.

Telepítéséhez Debian/Ubuntu rendszereken futtassuk az alábbi parancsot:

sudo apt-get install nmap

TCP portok szkennelése

A legtöbb ismertebb szolgáltatás TCP protokollt használ, aminek - a működési elvéből adódóan - a szkennelése sokkal gyorsabb, mint az UDP portoké (erről majd egy másik leírásban), ezért itt először most a TCP portok szkennelését nézzük meg. Az alábbi egyszerű nmap paranccsal felderíthetjük egy távoli számítógép vagy kiszolgáló TCP portjait:

nmap <hosztnév>

A parancs alapértelmezetten a TCP portokat keresi, de akár meg is adhatjuk neki a -sT kapcsolóval. A következő parancs tehát ugyanazt a kimenetet adja:

nmap -sT <hosztnév>

Lássuk a működését! Nálam tehát a virtuális gépen:

nmap debian10.linuxportal.vm

Az nmap parancs használata - Alap TCP port szkennelés

Starting Nmap 7.70 ( https://nmap.org ) at 2022-07-19 00:18 CEST
Nmap scan report for debian10.linuxportal.vm (192.168.1.130)
Host is up (0.00041s latency).
Not shown: 985 closed ports
PORT     STATE SERVICE
21/tcp   open  ftp
22/tcp   open  ssh
25/tcp   open  smtp
53/tcp   open  domain
80/tcp   open  http
110/tcp  open  pop3
143/tcp  open  imap
443/tcp  open  https
465/tcp  open  smtps
587/tcp  open  submission
993/tcp  open  imaps
995/tcp  open  pop3s
3306/tcp open  mysql
8080/tcp open  http-proxy
8081/tcp open  blackice-icecap
MAC Address: 08:00:27:4E:95:0C (Oracle VirtualBox virtual NIC)

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

A parancs, mint ahogyan írja is a kimenetében, 1.6 másodperc alatt végrehajtotta a műveletet. Elsőre gondolhatnánk hogy ez nagyon gyors, hiszen kevesebb, mint két másodperc alatt megvizsgált sokezer portot. A valóságban viszont nem így van, de mielőtt még kitérnénk erre, próbáljuk ki, hogy átállítjuk például az SSH kiszolgálónk portszámát egy másik portszámra, majd utána újra lefuttatjuk a parancsot. A példa kedvéért most átállítom a linkelt leírás alapján a portszámot 57345-re. Persze másra is állíthatjuk, de én maradok a saját példámnál. Az előző parancsot újra futtatva pedig a kimenetünk:

Az nmap parancs használata - Alap TCP port szkennelés - A 22-es port eltűnt

Ahogy itt láthatjuk, eltűnt a TCP portok listájából a 22-es SSH portunk. Vajon hogyhogy nem találta meg az SSH portot az átállított számon? A válasz egyszerű: Az nmap program alapértelmezetten az 1000 legismertebb portszámot és a hozzájuk tartozó szolgáltatást szkenneli protokollonként, az alapértelmezett működési módja tehát ezért ilyen gyors. Az ismertebb portok és szolgáltatások listáját az IANA (Internet Assigned Numbers Authority) szervezet állította össze, és tartja karban. A lista itt érhető el. Az nmap program a saját listáját ez alapján készíti el.

Tehát ha az nmap alapból nem szkenneli végig az összes portot, akkor hogyan deríthetjük ki az alapértelmezettől eltérő portszámú portok és szolgáltatások állapotát? A folytatásban ezt is megtudhatjuk.

 

 

Megadott portok, és porttartomány szkennelése

Az nmap parancsnak megadható, hogy mely portokat, illetve azok tartományát szkennelje a művelet során. Az erre szolgáló paraméter a -p. A parancs szintaktikája a -p kapcsoló használatának vonatkozásában:

nmap -p <portszám> <hoszt>
nmap -p <portszám>-<portszám> <hoszt>
nmap -p <portszám>,<portszám> <hoszt>

Az első példa egy adott portszámot vizsgál, a második egy tól-ig tartományt, és a harmadik pedig vesszővel felsorolt portszámokat vizsgál. Lássunk mindegyikre pár példát!

Egy adott port vizsgálata
nmap -p 22 debian10.linuxportal.vm
nmap -p 57345 debian10.linuxportal.vm
nmap -p 58000 debian10.linuxportal.vm

Az nmap parancs használata - Egy adott port vizsgálata

Itt az első parancsnál rákerestem az "eltűnt" 22-es portra. Itt kiírta, hogy SSH szolgáltatás "lenne" itt, de a port le van zárva. Tehát mivel egy ismert portra kerestem rá, így kiírta az alapértelmezetten hozzá társított közismert szolgáltatást.

A második példában rákerestem az átállított, 57345-ös portomra, amire kiírta, hogy nyitva van, de ismeretlen szolgáltatás van mögötte.

Egyből több érv is szól amellett, hogy miért érdemes átállítani például az SSH portunkat egy ismeretlen portszámra:
  • A támadónál rögtön visszadobja a kapcsolatot az alapértelmezett 22-es porton, ha ott próbálkozik. Ezért port szkenneléshez folyamodik...
  • A port szkennelés alapból nem jeleníti meg az átállított portot, ezért kiterjesztett tartományt kell neki szkennelnie, ami nagyon sokáig is eltarthat.
  • Ha végül meg is talál egy nyitott portot a hosszas keresgélés után, mivel nem ismert portszámról lévén szó, így nem tudja, hogy milyen szolgáltatás kapcsolódik hozzá, azaz nem derül ki számára, hogy az egy SSH port lenne. Ezért külön le kell azt kérdezni, hogy a talált ismeretlen portszámon milyen szolgáltatás várakozik. Ezt is mindjárt megnézzük.

Tehát megéri átállítani az olyan hálózati szolgáltatások portszámát, amik nem a nagy tömegek számára vannak fenntartva a "fogyasztói oldalon", hanem adminisztrációs célokra.

A harmadik példában pedig rákerestem egy szintén ismeretlen portszámra, ami mögött nincs semmilyen szolgáltatás. Ennél kiírta, hogy a port zárva van, és nincs is hozzá kapcsolódó ismert szolgáltatás.

Visszatérve a második parancsra, ha találtunk egy ismeretlen, de nyitott portot, akkor azt a -sV (kicsi s és nagy V) kapcsolóval kérdezhetjük le, hogy azon milyen szolgáltatás "lakik":

nmap -p 57345 debian10.linuxportal.vm
nmap -p 57345 -sV debian10.linuxportal.vm

Az nmap parancs használata - Egy adott port vizsgálata - Szolgáltatás detektálása

Starting Nmap 7.70 ( https://nmap.org ) at 2022-07-19 01:58 CEST
Nmap scan report for debian10.linuxportal.vm (192.168.1.130)
Host is up (0.00035s latency).

PORT      STATE SERVICE VERSION
57345/tcp open  ssh     OpenSSH 7.9p1 Debian 10+deb10u2 (protocol 2.0)
MAC Address: 08:00:27:4E:95:0C (Oracle VirtualBox virtual NIC)
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 0.89 seconds

Először lefuttattam simán a port lekérdezését, majd utána a -sV kapcsolóval. A kapcsoló hatására tehát detektálta a porton lévő szolgáltatást és annak verzióját, stb.

Persze ez nem úgy működik, hogy a szolgáltatás adja vissza magáról önszántából az információkat, ezáltal leleplezve saját magát, hanem visszaad valamilyen válaszcsomagot, ami akár egy hibaüzenet, stb is lehet. És az nmap a rendelkezésére álló ismert minták alapján kideríti, hogy a kapott válaszcsomag alapján az nagy valószínűséggel milyen szolgáltatás és annak melyik verziója lehet. A kimenet végén írja is, hogy kéretik jelenteni minden hibás eredményt. Tehát a program fejlesztői folyamatosan kapják a közösségtől a visszajelzéseket, amiket aztán kiértékelnek, és ezek alapján fejlesztik a mintákat tartalmazó adatbázisukat.
Porttartomány vizsgálata
nmap -p 1-100 debian10.linuxportal.vm
nmap -p 57000-58000 debian10.linuxportal.vm

Az első parancs lekérdezi az 1-100 -ig terjedő portszámokat, a másodikban pedig egy magasabb tartományt vizsgálunk, amibe beleesik az egyedi beállítású SSH portunk is. A kimenetük pedig:

Az nmap parancs használata - Porttartomány vizsgálata

Természetesen porttartomány szkennelése esetén is van lehetőség a -sV kapcsolóval detektáltatni a szolgáltatásokat, de ez jelentősen lelassítja a műveletet:

nmap -p 57000-58000 -sV debian10.linuxportal.vm

Az nmap parancs használata - Porttartomány vizsgálata szolgáltatás detektálásával

Itt a lekért tartományban csak 1 talált (nyitott) port van, de így is 1.63 másodpercről 1.90 másodpercre lassult a művelet. Ez egy többezres tartomány szkennelése esetén jelentősen lelassítja a tempót. Tehát célszerűbb első körben csak simán a tartományt lekérdezni, majd utána a talált portokat egy felsorolásban lekérdezni, és akkor használni a -sV kapcsolót.

Felsorolt portok vizsgálata
nmap -p 22,443,57345,58000,62500 debian10.linuxportal.vm
nmap -p 22,443,57345,58000,62500 -sV debian10.linuxportal.vm

Az első parancsnál a 22, a 443 (HTTPS), a beállított SSH portunkat és még 2 másik portot vizsgálunk. A második parancsnál ugyanezeket szkenneljük, de a -sV kapcsolóval a mögöttük lévő szolgáltatásokat is felderítjük. A kimenetük pedig:

Az nmap parancs használata - Felsorolt portok vizsgálata

Starting Nmap 7.70 ( https://nmap.org ) at 2022-07-19 02:39 CEST
Nmap scan report for debian10.linuxportal.vm (192.168.1.130)
Host is up (0.00044s latency).

PORT      STATE  SERVICE
22/tcp    closed ssh
443/tcp   open   https
57345/tcp open   unknown
58000/tcp closed unknown
62500/tcp closed unknown
MAC Address: 08:00:27:4E:95:0C (Oracle VirtualBox virtual NIC)

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

[...]

Starting Nmap 7.70 ( https://nmap.org ) at 2022-07-19 02:39 CEST
Nmap scan report for debian10.linuxportal.vm (192.168.1.130)
Host is up (0.00041s latency).

PORT      STATE  SERVICE  VERSION
22/tcp    closed ssh
443/tcp   open   ssl/http Apache httpd
57345/tcp open   ssh      OpenSSH 7.9p1 Debian 10+deb10u2 (protocol 2.0)
58000/tcp closed unknown
62500/tcp closed unknown
MAC Address: 08:00:27:4E:95:0C (Oracle VirtualBox virtual NIC)
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 12.96 seconds

Itt nem történt sok új dolog, csak a vesszőkkel történő felsorolást láthatjuk újként.

A két parancs sebességét érdemes még megnézni: ennél a néhány portnál 0.57 másodperc helyett 12.96 másodpercig tartott a szolgáltatások detektálása. Tehát a -sV kapcsolót csak akkor érdemes használni, ha már megvan a kiszemelt portunk, vagy néhány portunk, és azokról szeretnénk bővebb információt megtudni, különben egy nagyobb porttartomány vagy felsorolás szkennelése esetén nyugodtan elmehetünk ebédelni, mire végez a program. Persze ez még függ a hálózat sebességétől is, a rendszerben esetlegesen fennálló csomagtorlódástól, valamint hogy a vizsgált portok között mennyi nyitott illetve zárt port van, mivel a zárt portok esetén egységes válaszokat ad a rendszer, ami általában egy hibaüzenet, vagy nem is ad választ, és ilyenkor időtúllépés miatt szakad meg a kapcsolat, ami önmagában is hosszabb ideig tarthat. Például az UFW tűzfal használata esetén be lehet állítani a biztonsági házirendet, hogy hogyan zárjon le egy portot. Nyitott portoknál pedig az adott szolgáltatástól függ, hogy milyen válaszcsomagot ad vissza, mennyi a késleltetési ideje, szükséges-e többször is próbálkoznia az nmap-nak az adott porton, esetleg brute-force védelem jegyében még kivár egy kicsit a port mögött "rejtőzködő" szolgáltatás, amennyiben többször kell próbálkozni, stb.

 

 

UDP portok szkennelése

Az UDP portok vizsgálatát a -sU kapcsolóval végezhetjük, és csak root jogosultsággal futtathatjuk. Tehát ha eddig nem voltunk root-ként belépve, most tegyük meg, vagy használjuk a sudo parancsot.

A saját Debian 10-es virtuális gépes példámnál maradva az UDP portok szkennelése tehát:

nmap -sU debian10.linuxportal.vm

UDP portok szkennelése az nmap paranccsal

Starting Nmap 7.70 ( https://nmap.org ) at 2022-08-09 15:57 CEST
Nmap scan report for debian10.linuxportal.vm (192.168.1.130)
Host is up (0.00039s latency).
Not shown: 999 closed ports
PORT   STATE SERVICE
53/udp open  domain
MAC Address: 08:00:27:4E:95:0C (Oracle VirtualBox virtual NIC)

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

Az nmap az UDP portok esetén is végigvizsgálta az 1000 legismertebb portot, ezek közül talált itt egy 53-as (domain) portot, ami a DNS kiszolgálást hivatott ellátni. Jelen esetben erről a Bind9 DNS szerver gondoskodik, amit erre a tökéletes szerverre telepítettem korábban.

Figyelem!
Az iménti példa futtatása sok időt vesz igénybe, ennek okára és orvoslására később kitérünk.

Ha külön szeretnénk ránézni erre az 53-as portra, és szeretnénk lekérni a mögötte lévő szolgáltatás felismerését is, akkor - a fentebb már bemutatott TCP portokhoz hasonlóan - futtassuk az alábbi parancsokat 1-1 port lekéréséhez:

nmap -sU debian10.linuxportal.vm -p 53
nmap -sUV debian10.linuxportal.vm -p 53

Egyedi UDP port vizsgálata az nmap paranccsal

Az első parancs csak újra lekéri a megadott 53-as port adatait az ismert portok adatbázisa alapján, majd a második paranccsal - ami csak a -sV kapcsolóval egészíti ki az előzőt - pedig kérjük, hogy maga az nmap próbálja kideríteni, hogy valójában milyen szolgáltatás működik ezen a porton. A képen látható módon az nmap parancsnak nem sikerült beazonosítania a szolgáltatást a kapott válaszsomag alapján, ezért a parancs kimenetében kaptunk egy digitális ujjlenyomatot a válaszról, amit ha akarunk be is küldhetünk az nmap fejlesztőinek, hogy bővíthessék az adatbázisukat.

Ami viszont még az eredmények megjelenítései előtt már szembetűnik, az az UDP műveletek sebessége. A kimenetekben is láthatjuk, hogy a legelső szkennelő parancs bizony 1083 másodpercig futott, ami nem kevesebb, mint 18 perc, és az utána futtatott parancsok, amiknek egy-egy portot adtunk meg, azok is jóval lassabban futottak, mint a TCP-s lekérések. Korábban már említettem, hogy az UDP portok vizsgálata sokkal lassabb, mint a TCP portoké, ezért mielőtt még jobban belemennénk az UDP portok szkennelésébe, még kell valamit kezdenünk a futási sebesség növelésével, vagyis a szkennelési idő csökkentésével.

Szkennelési idő csökkentése

Ahogy fentebb már láthattuk, a port szkennelési művelet időnként iszonyatosan sok ideig tart. Ilyen szituáció többnyire az UDP portok vizsgálata esetén fordul elő, de TCP portok elemzésekor is tapasztalhatunk nagyobb mértékű lassulást, például ha szélesebb port tartomány vizsgálatát szolgáltatás felismeréssel párosítjuk. Szerencsére vannak erre is bevált technikák, azonban ne feledjük, hogy ezek a megoldások minden esetben valaminek a rovására mennek, ami általában a kapott eredmény pontosságával függ össze. Tehát az itt bemutatott technikák használatakor mindig mérlegeljünk, hogy melyik a fontosabb: az idő, vagy a keresett port vagy szolgáltatás felismerésének a pontossága. Lássunk tehát néhány megoldást.

A következő példasorozatban vegyük alapul a 40-80 UDP porttartományt, mivel ebbe egyrészt beleesik az egy szem nyitott UDP portunk is, valamint ez annyi ideig fut, ami még nem vesz el tőlünk sok időt, viszont a sebességnövekedések még látványosan mérhetők ekkora időkkel.

A parancs tehát az alábbi:

nmap -sU debian10.linuxportal.vm -p 40-80

nmap - UDP porttartomány szkennelési sebesség mérése

Starting Nmap 7.70 ( https://nmap.org ) at 2022-10-20 23:17 CEST
Nmap scan report for debian10.linuxportal.vm (192.168.1.130)
Host is up (0.00039s latency).
Not shown: 40 closed ports
PORT   STATE SERVICE
53/udp open  domain
MAC Address: 08:00:27:4E:95:0C (Oracle VirtualBox virtual NIC)

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

Itt tehát lekérdezzük a 40-80 UDP porttartományt, ami nálam most 37.40 másodperc alatt futott le. A tartományban természetesen megtalálta az 53-as nyitott portunkat is.

Ha mindezt még kipótoljuk egy -vv kapcsolóval, akkor sokkal részletesebb választ kapunk:

nmap -sU debian10.linuxportal.vm -p 40-80 -vv
Starting Nmap 7.70 ( https://nmap.org ) at 2022-10-21 00:08 CEST
Initiating ARP Ping Scan at 00:08
Scanning debian10.linuxportal.vm (192.168.1.130) [1 port]
Completed ARP Ping Scan at 00:08, 0.22s elapsed (1 total hosts)
Initiating UDP Scan at 00:08
Scanning debian10.linuxportal.vm (192.168.1.130) [41 ports]
Discovered open port 53/udp on 192.168.1.130
Increasing send delay for 192.168.1.130 from 0 to 50 due to max_successful_tryno increase to 4
Increasing send delay for 192.168.1.130 from 50 to 100 due to max_successful_tryno increase to 5
Completed UDP Scan at 00:08, 15.55s elapsed (41 total ports)
Nmap scan report for debian10.linuxportal.vm (192.168.1.130)
Host is up, received arp-response (0.00035s latency).
Scanned at 2022-10-21 00:08:19 CEST for 16s

PORT   STATE         SERVICE    REASON
40/udp open|filtered unknown    no-response
41/udp closed        graphics   port-unreach ttl 64
42/udp closed        nameserver port-unreach ttl 64
43/udp closed        whois      port-unreach ttl 64
44/udp open|filtered mpm-flags  no-response
45/udp closed        mpm        port-unreach ttl 64
46/udp open|filtered mpm-snd    no-response
47/udp open|filtered ni-ftp     no-response
48/udp closed        auditd     port-unreach ttl 64
49/udp closed        tacacs     port-unreach ttl 64
50/udp closed        re-mail-ck port-unreach ttl 64
51/udp open|filtered la-maint   no-response
52/udp closed        xns-time   port-unreach ttl 64
53/udp open          domain     udp-response ttl 64
54/udp closed        xns-ch     port-unreach ttl 64
55/udp closed        isi-gl     port-unreach ttl 64
56/udp open|filtered xns-auth   no-response
57/udp open|filtered priv-term  no-response
58/udp open|filtered xns-mail   no-response
59/udp closed        priv-file  port-unreach ttl 64
60/udp open|filtered unknown    no-response
61/udp open|filtered ni-mail    no-response
62/udp open|filtered acas       no-response
63/udp closed        via-ftp    port-unreach ttl 64
64/udp open|filtered covia      no-response
65/udp open|filtered tacacs-ds  no-response
66/udp closed        sqlnet     port-unreach ttl 64
67/udp closed        dhcps      port-unreach ttl 64
68/udp open|filtered dhcpc      no-response
69/udp open|filtered tftp       no-response
70/udp closed        gopher     port-unreach ttl 64
71/udp closed        netrjs-1   port-unreach ttl 64
72/udp closed        netrjs-2   port-unreach ttl 64
73/udp closed        netrjs-3   port-unreach ttl 64
74/udp open|filtered netrjs-4   no-response
75/udp closed        priv-dial  port-unreach ttl 64
76/udp closed        deos       port-unreach ttl 64
77/udp closed        priv-rje   port-unreach ttl 64
78/udp open|filtered vettcp     no-response
79/udp open|filtered finger     no-response
80/udp open|filtered http       no-response
MAC Address: 08:00:27:4E:95:0C (Oracle VirtualBox virtual NIC)

Read data files from: /usr/bin/../share/nmap
Nmap done: 1 IP address (1 host up) scanned in 15.93 seconds
           Raw packets sent: 222 (6.338KB) | Rcvd: 35 (2.428KB)

Mindezt csak érdekességképpen tettem be, de ezzel a részletesebb kimenettel sok hasznos információt kapunk az nmap port letapogatási mechanizmusáról, ami jó támpontként szolgálhat az alább bemutatott kapcsolók megfelelő beállításához. Zölddel kiemeltem az egyetlen nyitott port sorát.

A kimenetekben szereplő portok állapotainak részletes leírását itt találhatjuk. Ugyanezt magyar nyelven pedig itt olvashatjuk.

Akkor most - a teljesség igénye nélkül - lássunk pár kapcsolót, amivel rövidíthetjük a lekérdezés idejét, mindezt persze a pontosság rovására.

 

 

Maximális próbák száma (--max-retries kapcsoló)

Ha az nmap nem kap választ a letapogatás során, akkor elküld egy újabb próbát. Ilyen akkor szokott előfordulni, ha tűzfallal szűrik a portokat vagy a válasz elveszik a hálózaton, stb. Az nmap a körülményeknek megfelelően automatikusan szabályozza ezt az értéket. Például a hálózati teljesítmény vagy a kapott válaszok függvényében. Szükség esetén tehát a több próbálkozás pontosabb eredményt ad, viszont ez a teljesítmény rovására történik. Az nmap normál körülmények között csak egyszer ismétel meg egy próbát, azonban szükség esetén megemeli ezeknek a számát. Az alapértelmezett maximális próbák száma 10, tehát ha nem változtatunk ezen az értéken, akkor maximum ennyiszer ismételhet meg egy próbát. Ha a teljesítmény a fő szempont, akkor ezt az értéket állíthatjuk alacsonyabbra is. Tehát ha például rossz a hálózati teljesítmény, vagy bizonytalan válaszokat kap az nmap, akkor többször próbálkozik, így ezekben az esetekben javíthatunk a teljesítményen.

Próbaképpen állítsunk be 5-ös értéket, és nézzük meg a korábbi UDP porttartományunk letapogatásának eredményét:

nmap -sU debian10.linuxportal.vm -p 40-80 -vv --max-retries 5

NMAP - teljesítmény növelése a próbák számának korlátozásával

Itt láthatjuk, hogy megkaptuk ugyanazt az eredményt, de ezúttal 13 másodperc körül futott le a port szkennelés, ami majdnem 1/3-ad futási időt jelent.

Valamint láthatunk egy ilyen sort is a kimenetben:

Warning: 192.168.1.130 giving up on port because retransmission cap hit (5).

Az nmap ezzel jelezte, hogy a tartomány egyik portjának letapogatása során "feladta" a próbálkozásokat, mivel ebben az esetben elérte a maximális próbák számát.

Persze vihetnénk lejjebb is ezt a limitet, de alacsonyabb értékeknél már pontatlanabb kimenetet kapunk.

Próbák közti késleltetési idő korlátozása (--scan-delay és --max-scan-delay kapcsolók)

A kapcsolók segítségével szabályozhatjuk, hogy az elküldött próbák között mennyi időt várjon az nmap. A szabályozott forgalommal rendelhező kiszolgálók esetén különösen hasznos, mert például vannak olyan célállomások, amik az UDP letapogatási próbákra másodpercenként csak egy választ küldenek. Minden további elküldött próba ilyenkor elveszik. Ha nem határozzuk meg ezeket az értékeket, akkor - ahogy a fenti kimenetekben is jól látható - az nmap ezeket is maga szabályozza automatikusan a körülményektől függően. Ezt a kimenetekben az "Increasing send delay" kezdetű sorokkal jelzi, ahol feltűnteti a beállított új késleltetési időt.

Ha ezeket az értékeket túl alacsonyra állítjuk, akkor az sok elveszett próbát eredményez, aminek következtében az nmap a próbák számát fogja emelni. Így tehát be kell állítani egy optimális értéket, és/vagy a próbák számának korlátozásával célszerű kombinálni.

Ebben a példában most kipróbálunk egy elég alacsony értéksávot (50 és 100 ms között), és megnézzük mi történik:

nmap -sU debian10.linuxportal.vm -p 40-80 -vv --scan-delay 50ms --max-scan-delay 100ms

NMAP - Próbák közti késleltetési idő korlátozása

Itt láthatjuk, hogy az eredeti port szkennelésünkhöz képest arányában ez is jóval gyorsabban lefutott, itt 24.49 másodpercig tartott a művelet az eredeti 36 másodperchez képest.

Időzítési sablon használata (-T kapcsoló)

A korábban említett kapcsolók - és természetesen még sok másik kapcsoló is, amiről itt nem ejtettünk szót - mind hatékonyan alkalmazhatók, azonban sok felhasználó jobban szereti, ha ezeknek a beállításait különböző sablonokkal érheti el, így nem kell sokat bíbelődni a paraméterek optimális beállításával, ami sokszor több időt vesz igénybe, mint maga a port szkennelési művelet maga. Az nmap a -T kapcsoló segítségével 6 időzítési sablont kínál, amelyek mind más beállítási profilt tartalmaznak. A 6 sablon az alábbi:

  1. Paranoid
  2. Sneaky (trükkös)
  3. Polite (udvarias)
  4. Normal (normál) - ez az alapértelmezett is egyben
  5. Aggressive (agresszív)
  6. Insane (őrült)
Az első kettő sablon a behatolásérzékelők megtévesztésére szolgál.  Az udvarias mód lassú letapogatást végez kevesebb sávszélességet, valamint a célállomáson kevesebb erőforrást használva. A normál mód az alapértelmezett, így a -T3 paraméter megadása semmilyen változást nem idéz elő. Az agresszív mód felgyorsítja a letapogatást azt feltételezve, hogy gyors és megbízható hálózatot használ. Végül az őrült mód azt feltételezi, hogy egy különösen gyors hálózatot használ és a sebesség érdekében hajlandó feláldozni valamennyit a pontosságból. (forrás: nmap.org)

Érdemes kísérletezgetni ezekkel, de vegyük figyelembe, hogy az alacsonyabb módok esetén sokkal tovább tart a portok letapogatása. Az alábbi példában a 4-es módot, azaz az agresszív módot tekinthetjük meg a szokásos UDP porttartományunkon:

nmap -sU debian10.linuxportal.vm -p 40-80 -vv -T 4

NMAP - Időzítési sablon használata

A példában 14 másodperc alatt futott le a portletapogatás, ami szintén jóval gyorsabb, mint a kiindulási műveletünk során volt. Itt érdemes az 5-ös maximális értékről indulni, ami nálam már pontatlan eredményt adott, és lefelé lépegetni. Nálam az alsó értékek ezen a virtuális szerveren nagyon sokáig futottak, így meg is szakítottam a műveletet. Ez az 5-ös beállítás hozta a megfelelő sebességet és ugyanazt az eredményt ugyanabban az UDP porttartományban.

Ezekkel a sablonokkal megadható, hogy a letapogatás mennyire legyen agresszív, de meghagyja a lehetőséget az Nmap programnak, hogy az időzítéseket maga állítsa be. A sablonok ezen kívül elvégeznek néhány olyan sebesség beállítást, melyek önálló paraméterként jelenleg nem adhatók meg. Például a -T4 paraméter megakadályozza, hogy a dinamikusan változó letapogatásikésleltetés a TCP kapukon meghaladja a 10 milliszekundumot, míg a -T5 paraméter ugyanezt az értéket 5 milliszekundumra korlátozza. A sablonok mellett továbbra is használhatóak az egyedi időzítési paraméterek és ezek minden esetben felülbírálják a sablonokban beállított alapértékeket. Modern és megbízható hálózatok letapogatása esetén ajánlott a -T4 paraméter használata. Tartsa meg ezt a paramétert még akkor is, ha egyedi időzítési paramétereket használ, így kihasználhatja a sablonban lévő kisebb extra optimalizációt is.

Ha tisztességes szélessávú vagy ethernet kapcsolatot használ, javasolt a -T4 paraméter állandó használata. Néhányan szeretik használni a -T5 paramétert, ám ez sok esetben túl agresszív lehet. Vannak akik a -T2 paramétert szeretik használni, mert azt gondolják, hogy így kisebb valószínűséggel döntik romba a célpontot, vagy mert magukat általában udvarias embernek gondolják. Ők azonban gyakran nem veszik észre, hogy a -Tpolite valójában milyen lassú. Ez a letapogatás tízszer hosszabb is lehet, mint egy alapértelemeztt. Az alapértelmezett időzítésnél (-T3) ritkán fordulnak elő összeomlások vagy sávszélesség problémák, ezért vatoss letapogatásnál célszerű ezt használni. Ezeknek a problémáknak a csökkentésére sokkal alkalmasabb a változat érzékelés elhagyása, mint az időzítési paraméterek állítgatása. (forrás: nmap.org)

 

Természetesen ezeken a kapcsolókon kívül van még sok másik, ami a sebesség optimalizálásával foglalkozik, itt csak ezt a néhányat mutattam be a szemléltetés kedvéért. Ezekről a kapcsolókról itt olvashatunk bővebben:

 

A port szkennelésre használható parancsok leírása még nem ért véget, a következő oldalon folytatjuk az Ncat (OpenBSD és Tradicional implementációk) ismertetésével,

 

 

Kapcsolódó tartalom, hasznos linkek:

 

Lapozó

Ez a leírás több oldalból áll:

 

Címkék
port szkennelés
port scan
tcp
udp
nmap