Az UPNP-t a következőképpen értelmezik: Magánszámítógép esetén a BitComet UPnP funkciója automatikus portleképezést tud elérni a átjáró vagy router NAT moduljának, és leképezni azt a portot, amelyet a BitComet hallgat a gatewayről vagy routerről az intranet számítógépre.
A gateway vagy router hálózati tűzfal modulja elkezdi megnyitni ezt a portot más számítógépek számára az interneten.
A NAT átjárás technológia lehetővé teszi a webalkalmazások számára, hogy felismerjenek, hátha egy UPnP-képes NAT eszköz mögött vannak-e. Ezek a programok ezután megosztott, globális irányítható IP-címet kapnak, és konfigurálják a portfelleképezést úgy, hogy továbbítsák a csomagokat a NAT külső portjairól az alkalmazás által használt belső portokra – mindezt automatikusan, anélkül, hogy a felhasználóknak kézzel kellene portokat térképezniük vagy bármi mást csinálniuk. A NAT átjárási technológia lehetővé teszi, hogy hálózati eszközök vagy peer-to-peer alkalmazások kommunikáljanak a külvilággal NAT átjárókon keresztül, dinamikusan nyitva és zárva a kommunikációs portokat külső szolgáltatásokkal.
Más szóval, a következőképpen összefoglalható: az egyszerű NAT átalakítási hatékonysága nem magas, és ha az UPNP technológiát elindítják, a NAT adatátalakítás hatékonysága javulhat.
Ez jó dolognak hangzik. De mi ???
Az UPNP-nek komoly hiányosságai vannak: Íme egy részlet:
Az első hiba, hogy a pufferek használatát nem ellenőrizik és nem korlátozzák. Külső támadók ezzel szerezhetik meg az egész rendszer irányítási jogait! Mivel az UPnp függvénynek a számítógép portjait kell használnia a működéshez, az irányítást szerező támadó ezeket a portokat is felhasználhatja a támadó céljának eléréséhez. Ennek a hibának a következményei nagyon súlyosak, bármelyik Windows verzióban is van, amíg az UPnP fut, fennáll ez a veszély! De szigorúan véve ez nem teljesen magával a UPnP technológiával kapcsolatos probléma, inkább programozási hibá.
A második hiba az UPnP működési mechanizmusához kapcsolódik. A hiba a "eszköz felfedezése" fázisban létezik, amikor az UPnP működik. Egy eszköz felfedezése két helyzetre osztható: ha egy UPnP-képes számítógép sikeresen bootol és csatlakozik a hálózathoz, azonnal "sugárzást" küld a hálózatnak, jelezve a hálózaton lévő UPnP eszközt, hogy készen áll, és a programozási szinten a sugárzott tartalom egy M-SEARCH (üzenet) utasítás. A közvetítést minden olyan eszköz "hallja" a "hangterjedésen" belül. És visszaküldi a releváns információkat a számítógépnek a későbbi vezérlés céljából.
Hasonlóképpen, ha egy eszköz csak csatlakozik a hálózathoz, akkor "értesítést" is küld a hálózatnak, hogy készen áll a hálózat irányításának elfogadására, ami a programozási szinten ÉRTESÍT jelzés. A "hangterjedés" tartományban lévő összes számítógép is elfogadja. A számítógép "érzékeli", hogy az eszköz "jelentett önmagának". Valójában a NOTIFY utasításokat nemcsak számítógépekre küldik, hanem más hálózati eszközök is hallhatják őket. A fent említett adásban és hallgatásban van probléma!
Ha egy hacker NOTIFY utasítást küld a felhasználó rendszerének, a felhasználó rendszere megkapja ezt a NOTIFY utasítást, csatlakozik egy adott szerverhez az utasításai szerint, majd letöltő szolgáltatást kér a megfelelő szerverre – letölti a végrehajtandó szolgáltatás tartalmát. A szerver természetesen válaszolni fog erre a kérésre. Az UPnP szolgáltatási rendszer elmagyarázza az eszköz leírását, további fájlok küldését kéri, és a szervernek válaszolnia kell ezekre a kérésekre. Így egy "kérés-válasz" ciklus alakul ki, amely nagy mennyiségű rendszererőforrást foglal el, és az UPnP rendszer szolgáltatási sebességének lelassulását vagy akár megállását okozza. Tehát ez a hiba lehetővé teszi egy "szolgáltatásmegtagadás" támadást!
Valójában más szóval, az UPNP függvény folyamatosan fogyasztja a saját hálózati erőforrásait a használati szakasz alatt, és amikor az eszköz hálózati erőforrásai kimerülnek, felfüggesztett animáció jelensége alakul ki. Csak nézd meg a fenti információkat. |
Közzétéve 2017. 10. 12. 8:58:01
|
|
|
|
