legtöbbünk ismeri az egyszerű ICMP alapú “ping” parancsot, amely lehetővé teszi számunkra, hogy teszteljük az alapvető választ néhány hálózati csatlakoztatott eszközről. Bár nagyszerű az alapvető hibaelhárításhoz, ez nem teszi lehetővé annak megerősítését, hogy a másik végén lévő fogadó TCP vagy UDP portokon válaszol-e, ahol a szolgáltatások többsége valószínűleg rendelkezésre áll.,
Ping nem az lesz a vége pedig az összes hálózati hibaelhárítás, ha egy tűzfal letiltja a bejövő ICMP forgalmat, akkor a ping nem fog sikerülni, amely képes egy téves felfogás, hogy a házigazda le, mivel nem válaszol a ping, azonban egyéb szolgáltatások még lehet, hogy jól reagál.
Alternatív megoldásként, miközben a ping visszatérhet egy válaszhoz, ez nem jelzi, hogy egy webkiszolgáló válaszol-e a 80-as porton HTTP kérések esetén, előfordulhat, hogy a webkiszolgáló sikertelen volt, és már nem válaszol.
tehát ha a ping ICMP alapú, akkor inkább TCP vagy UDP portot érhetünk el válaszként?, A válasz igen, vessünk egy pillantást.
írja be a tcping
tcping egy olyan eszköz, amely felhasználható annak ellenőrzésére, hogy egy TCP port válaszol-e, van néhány verzió, azonban ezt használom: http://www.elifulkerson.com/projects/tcping.php
a kézikönyv ugyanazon az oldalon található, alapvetően az alábbiakhoz hasonló parancsot futtathat.
itt a tcping segítségével ellenőrizzük a 443-as portot google.com. mint látható, a port mutatja, hogy nyitott és válaszol, ha a port nincs nyitva, akkor nem jelenik meg válasz után 2000ms alapértelmezés szerint.,
a telnet segítségével tesztelheti a TCP-kapcsolatot egy porthoz, azonban a tcping eszköz további funkciókat kínál, amint azt az itt található használati szakasz ismerteti. Néhány ilyen funkciók közé tartozik, hogy képes folyamatosan futtatni a tesztet, amely lehetővé teszi a módját, hogy a forgalom, hogy néz ki az élő csomag rögzíti, valamint a válaszidő.
mi a helyzet az UDP-vel?
mivel az UDP egy kapcsolat nélküli protokoll, annak meghatározása, hogy válaszol-e, egy kicsit más., A TCP ‘ping’ úgy működik, hogy egy háromutas kézfogást hajt végre, a forrás egy SYN-ACK-t küld a célállomásra, a cél egy SYN-ACK-val válaszol, majd a forrás egy ACK-t küld a kézfogás befejezéséhez és a kapcsolat létrehozásához. Mivel az UDP nem hoz létre kapcsolatot, nem csak ezt keressük annak meghatározására, hogy a port válaszol-e, ehelyett konkrét adatokat kell küldenünk, hogy megtudjuk, kapunk-e választ.
NMAP egy nagyszerű eszköz erre, akkor töltse le, majd használja a port beolvasni a célcímet, hogy meghatározzák, milyen portok vannak nyitva.,
ebben a példában azt kérdezzük, hogy a 8.8.8.8 válaszol-e az UDP 53-as portján, mivel a DNS-t szolgálja, elvárjuk, hogy nyitva legyen.
a nyitott|szűrt eredmény akkor használható, ha az nmap nem tudja meghatározni, hogy a port nyitva van-e vagy szűrt-e, előfordulhat, hogy a nyitott port nem adott választ. Ez azt mutatja, hogy a szolgáltatást “domainként” azonosították, mivel a DNS kiszolgálására szolgál. Teszteltem ezt néhány más DNS-kiszolgálónak az interneten, mások pedig nyitottnak mutatják, csak megerősítve, hogy válaszolnak.
NMAP is lehet használni, hogy ellenőrizze a TCP port nyitott hasonló módon, csak change – su to-sT.,
miért nem válaszol egy port
van néhány egyszerű oka annak, hogy egy port nem reagál a tesztre.
- tűzfal blokkolja a forgalmat: lehet, hogy fut tűzfal között a forrás, míg a cél a szűrés a forgalom attól függően, hogy a szabályok még akkor is, ha tudod, hogy a cél legyen válaszol egy adott porton.
- előfordulhat, hogy a célállomás nem hallgat a porton: egyszerűen fogalmazva, hogy a csatlakozni kívánt célállomásnak nincs olyan szolgáltatása, amely a megadott porton hallgatna, így nem lesz válasz., Ez akkor is előfordulhat, ha egy szolgáltatás leállt, például ha leállítja az Apache-t, a webszerver már nem válaszol a 80-as port kérésekre.
- van egy másik hálózati probléma a forgalom forrása és célpontja között: a forrás és a rendeltetési hely között tetszőleges számú hálózati kapcsolódási probléma lehet, ha lehetséges, ellenőrizze a hálózatot azonban, ha a forgalom áthalad az interneten, akkor korlátozott lesz, amit ellenőrizhet.,
ellenőrizheti a kapcsolatot a forgalom útvonalán egy csomagrögzítés futtatásával, például a Wireshark vagy a tcpdump segítségével, ez megmutatja, hogy hol halad át a forgalom az útvonal mentén. Futtathatja azt a forrás-és célszervereken, valamint a köztük lévő eszközökön, amelyekhez hozzáférhet, például tűzfalakon vagy útválasztókon. Kövesse a forgalom áramlását, amíg meg nem határozza, hol van a probléma.,
összefoglaló
TCP “ping” végrehajtása közben megerősítheti, hogy a kívánt módon reagál-e, bár néhány oka van annak, hogy a port nem reagál a megjegyzésnek megfelelően. UDP lehet ellenőrizni azonban ez egy kicsit nehezebb, hogy bizonyos, ha helyesen kap választ, így a tesztek nem mindig megbízható, ami értelme UDP nem megbízható protokoll. Ezek a tesztek hasznosak lehetnek a biztonság tesztelésekor, megerősítve, hogy a portok nyitva vagy zárva vannak-e.
Leave a Reply