A portszkenner egy szoftvereszköz, amelyet arra terveztek, hogy megtalálja azokat a hálózati gazdagépeket , amelyeknél nyitva vannak a szükséges portok . Ezeket a programokat általában a rendszergazdák használják hálózataik biztonságának ellenőrzésére, a támadók pedig a hálózat feltörésére. Kereshet egy sor nyitott portot egy gazdagépen, vagy egy adott portot sok gazdagépen. Ez utóbbi számos hálózati féreg tevékenységére jellemző .
Magát a folyamatot port -ellenőrzésnek vagy (ha sok gazdagépet ellenőrizzük) hálózati vizsgálatnak nevezik . A port-ellenőrzés lehet az első lépés egy incidens vagy incidens megelőzési folyamatban, mivel segít azonosítani a lehetséges támadási célpontokat. Megfelelő eszközök segítségével adatcsomagok küldésével és a válaszok elemzésével megvizsgálhatók a gépen futó szolgáltatások ( webszerver , FTP szerver , levelezőszerver stb. ), megállapítható a verziószámuk és a használt operációs rendszer . .
Az interneten manapság a leggyakoribb protokollverem a TCP/IP . A hosztolt szolgáltatásokat két azonosító címzi: egy IP-cím és egy portszám . 65536 lehetséges portszám van. A legtöbb szolgáltatás korlátozott számú portszámot használ (a portszámot az IANA rögzíti , ha a szolgáltatás elég jelentőssé válik [1] ).
Egyes portszkennerek csak a leggyakrabban használt vagy legsebezhetőbb portokat keresik egy adott gazdagépen vagy gazdagépcsoporton.
A port-ellenőrzés eredménye általában három kategóriába sorolható:
A nyitott portokhoz kapcsolódó sebezhetőségek a következőkre oszthatók:
A zárt portok csak a második ponton jelenthetnek veszélyt. A blokkolt portok jelenleg nem jelentenek valódi veszélyt.
A portszkennelési technikák azon a feltételezésen alapulnak, hogy a gazdagép támogatja az RFC 792 -ben [2] meghatározott "Forward Control Protocol"-t ( ICMP ) . Bár ez a legtöbb esetben igaz, akkor is előfordulhat, hogy egy gazdagép furcsa csomagokkal válaszol, vagy hamis pozitív üzeneteket generál, ha a használt TCP/IP-verem nem RFC-kompatibilis, vagy módosították.
Egyes esetekben a tényleges vizsgálat megkezdése előtt célszerű ellenőrizni, hogy működik-e a rendszer a cél IP-címen. Ezt a problémát úgy lehet megoldani, hogy ICMP Echo üzeneteket küld a ping segédprogrammal , az összes hálózati címet sorrendbe állítja, vagy visszhang üzenetet küld egy broadcast címre.
A forgalom elemzésével és az összes csomóponthoz rövid időn belül küldött Echo üzenetek figyelésével lehetővé válik a keresési kísérletek azonosítása. Echo üzenetek helyett RST kódbittel rendelkező TCP szegmensek használhatók , válaszok nem létező DNS kérésekre. Ha a lapolvasó válaszként 1-es kódú ( host elérhetetlen ) ICMP Destination Unreachable csomagot kap , az azt jelenti, hogy a tesztelt csomópont ki van kapcsolva, vagy nem csatlakozik a hálózathoz.
Nem szabad megfeledkezni arról, hogy (a gyakorlatban) a kérésekre adott válasz hiánya nem garantálja a gazdagép nemlétét, mivel sok rendszergazda a "biztonság" érdekében a hálózati szabványok megsértésére megy.
Ez a fajta szkennelés a legnépszerűbb. Az operációs rendszer hálózati funkcióinak használata helyett a portszkenner maga generál IP-csomagokat és figyeli az azokra adott válaszokat. Ezt a technikát gyakran félig nyitott kapcsolatvizsgálatnak nevezik, mivel a teljes TCP/IP-kapcsolatot soha nem nyitják meg. A portszkenner SYN csomagot generál. Ha a célállomás portja nyitva van, a rendszer SYN-ACK csomagot küld róla. A szkenner gazdagépe egy RST-csomaggal válaszol, így lezárja a kapcsolatot, mielőtt a kapcsolatlétesítési folyamat befejeződött volna.
A saját generált hálózati csomagok használata számos előnnyel jár, mivel a szkennelő szoftver teljes ellenőrzést biztosít a küldött csomagok és az azokra adott válaszok, válaszkésések felett, és lehetővé teszi a részletes vizsgálati eredményeket.
A szkennelt gazdagépet érő lehetséges károkról vegyesek a vélemények. Egyrészt a SYN szkennelésnek megvan az az előnye, hogy az egyes alkalmazások soha nem kapnak bejövő kapcsolatot (a telepítési szakaszban megszakad), másrészt a kapcsolatlétesítés során RST-csomag küldése bizonyos hálózati eszközöknél problémákat okozhat, különösen egyszerű olyanok, mint a hálózati nyomtatók .
Ez az egyszerűbb módszer az operációs rendszer hálózati funkcióit használja, és akkor használatos, ha a SYN-vizsgálat ilyen vagy olyan okból nem kivitelezhető. Az operációs rendszer, ha a port nyitva van, befejezi a háromlépcsős kapcsolatfelvételi eljárást, majd azonnal bezárja a kapcsolatot. Ellenkező esetben hibakódot ad vissza. A módszer előnye, hogy nem igényel speciális hozzáférési jogokat a felhasználótól. Az operációs rendszer hálózati funkcióinak használata azonban nem teszi lehetővé az alacsony szintű vezérlést, így ez a típus nem olyan elterjedt.
Ennek a módszernek a fő hátránya a nagyszámú nyitott és azonnal megszakadt kapcsolat, ami megterheli a vizsgált rendszert, és megkönnyíti a portszkenner tevékenységének észlelését.
Az UDP -csomagok használatával történő szkennelés is lehetséges, bár ennek számos sajátossága van. Az UDP számára nincs kapcsolati koncepció, és nincs megfelelője a TCP SYN csomagnak. Ha azonban UDP-csomagot küld egy zárt portra, a rendszer egy ICMP „port not available” üzenettel válaszol. Az ilyen üzenet hiánya a port nyitott jelzéseként értelmezhető. Ha azonban a portot egy tűzfal blokkolja , a módszer helytelenül jelzi, hogy a port nyitva van. Ha az ICMP port elérhetetlen üzenetei blokkolva vannak, minden port nyitva lesz. Az ICMP-csomagok használatának gyakoriságát is korlátozni lehet, ami szintén befolyásolja a módszer által adott eredményeket.
Alternatív megoldás az alkalmazás-specifikus UDP-csomagok küldése az alkalmazási rétegtől érkező válasz megérkezésére várva. Például, ha DNS -lekérdezést küld az 53-as portra, akkor válasz érkezik, ha a kért címen DNS-kiszolgáló található. A probléma ebben az esetben az, hogy mindegyik porthoz van egy megfelelő "próbacsomag". Egyes esetekben előfordulhat, hogy egy szolgáltatás jelen van, de úgy van beállítva, hogy ne válaszoljon az ismert "próba" csomagokra.
Lehetséges hibrid megközelítés is, amely mindkét fenti módszert kombinálja. Például a vizsgálat kezdődhet egy UDP-csomag elküldésével, hogy ellenőrizze a „port nem elérhető” ICMP-választ, majd a kétértelmű „nyitott vagy blokkolt” eredményű portokat újra lehet vizsgálni az alkalmazás-specifikus válaszok keresésére.
Ez a vizsgálat annak meghatározására szolgál, hogy egy adott port szűrve van-e vagy sem, és különösen hatékony a tűzfalak jelenlétének észlelésére és szabályaik kiderítésére. Az egyszerű csomagszűrés lehetővé teszi az ACK bit beállított csomagok áthaladását (a már létrehozott kapcsolatokhoz használják), míg a kifinomultabb tűzfalak nem.
Egyes kiszolgálók képesek nyomon követni a SYN-vizsgálati kísérletet a portjaikon. Például egy SYN-vizsgálati kísérlet felismerhető a védett kiszolgáló zárt portjaira érkező "hamis" SYN-csomagokról, és ha több port is lekérdezésre kerül, a szerver lezárja a kapcsolatot, hogy megvédje a vizsgálatot.
A FIN-csomagokkal végzett szkennelés lehetővé teszi az ilyen védelmek megkerülését. Az RFC 793 szerint a zárt porton érkező FIN csomagra a szervernek RST csomaggal kell válaszolnia. A kiszolgálónak figyelmen kívül kell hagynia a portok megnyitásához szükséges FIN-csomagokat. Ezzel a különbséggel lehetővé válik a zárt port megkülönböztetése a nyitotttól.
Nem minden operációs rendszer követi ezt az RFC 793 ajánlást . Például a 95/98/NT családhoz tartozó Windows reakciója egy bejövő FIN csomagra nem különbözik a nyitott és a zárt portok esetében.
És egy másik módszer a szegmensek küldése FIN (nincs több adat a küldőtől), PSH (push funkció), URG (sürgős mutató mező jelentős) jelzőkkel, vagy akár üres kódbit mezővel. Ha a port zárva van, akkor válaszként egy RST jelzővel ellátott szegmens kerül visszaadásra , ha nincs válasz, akkor a port nyitva van (mivel az ilyen szegmenst egyszerűen figyelmen kívül hagyja).
A keresés sebessége olyan tényezőktől függ, mint az ellenőrzött portok száma, a vizsgált rendszerek ICMP-válaszokra való hajlama, a választott vizsgálati módszer, az ellenőrzött gazdagépek száma és a kérésekre való válaszadási hajlandóságuk, valamint attól, hogy a vizsgáló fél mennyire aggódik tevékenységének láthatatlansága. A portszkenner annak érdekében, hogy ne találja meg magát, meghosszabbíthatja az üzenetek küldését. Másrészt, mivel nagyszámú gépet ellenőriznek, párhuzamosan is lehet őket vizsgálni, így az egyes gazdagépek terhelése nagyon alacsony lesz.
A legtöbb tűzfal képes megvédeni a portok vizsgálatát. A tűzfal képes megnyitni a rendszer összes portját, hogy megakadályozza, hogy a lapolvasó portokat mutasson. Ez a módszer a legtöbb esetben működik, de nem véd az olyan új portellenőrzési technikák ellen, mint az ICMP portellenőrzés és a NULL-ellenőrzés.
Egyes internetszolgáltatók csomagszűrőket vagy nyitott proxykat alkalmaznak , amelyek megakadályozzák a kimenő portok vizsgálatát.
Sok internetszolgáltató kifejezetten megtiltja a felhasználóknak a portellenőrzést. Jellemzően ez a tilalom a szolgáltatási szabályzatban szerepel, amit az ügyfélnek a csatlakozáskor el kell fogadnia.
Az Orosz Föderáció Büntető Törvénykönyve büntetőjogi felelősséget ír elő a következő bűncselekményekért [3] :