UPNP se interpretira takole: Za zasebni računalnik lahko BitCometova UPnP funkcija omogoči, da NAT modul prehoda ali usmerjevalnika samodejno preslika porte in preslika port, ki ga BitComet posluša iz prehoda ali usmerjevalnika, na intranet računalnik.
Omrežni požarni zid prehoda ali usmerjevalnika začne odpirati ta priključek za druge računalnike na internetu.
Tehnologija prehoda med NAT omogoča spletnim aplikacijam, da zaznajo, ali zaostajajo za napravo, ki podpira UPnP. Ti programi nato dobijo skupni globalni usmerljiv IP naslov in nastavijo preslikavo vrat za posredovanje paketov iz NAT zunanjih vrat na notranja vrata, ki jih uporablja aplikacija – vse samodejno, brez potrebe po ročnih preslikavah vrat ali česarkoli drugega. Tehnologija prehoda skozi NAT omogoča omrežnim napravam ali peer-to-peer aplikacijam komunikacijo z zunanjim svetom prek NAT prehodov z dinamičnim odpiranjem in zapiranjem komunikacijskih vrat z zunanjimi storitvami.
Z drugimi besedami, lahko to povzamemo takole: učinkovitost pretvorbe preprostega NAT ni visoka, in če se uvede tehnologija UPNP, se lahko učinkovitost pretvorbe NAT podatkov izboljša.
Zveni kot dobra stvar. Ampak kaj ???
UPNP ima resne pomanjkljivosti: Tukaj je odlomek:
Prva pomanjkljivost je, da uporaba medpomnilnikov ni preverjena in omejena. Zunanji napadalci lahko s tem pridobijo nadzor nad celotnim sistemom! Ker mora funkcija UPnp za delovanje uporabiti računalniške priključke, lahko napadalec, ki prevzame nadzor, prav tako uporabi te priključke za dosego cilja napadalca. Posledice te napake so zelo resne, ne glede na različico sistema Windows, dokler UPnP deluje, obstaja ta nevarnost! A strogo gledano to ni povsem težava same UPnP tehnologije, temveč bolj programerska napaka.
Druga pomanjkljivost je povezana z delovnim mehanizmom UPnP. Napaka se pojavi v fazi "odkrivanja naprave", ko UPnP deluje. Odkritje naprave lahko razdelimo na dve situaciji: če se računalnik, ki podpira UPnP, uspešno zažene in se poveže v omrežje, takoj pošlje "broadcast" v omrežje, s čimer UPnP napravo v omrežju obvesti, da je pripravljena, na programski ravni pa je vsebina oddajanja ukaz M-SEARCH (sporočilo). Oddajanje bodo "slišale" vse naprave znotraj "dosega zvoka". In povratno informacijo o svojih relevantnih informacijah pošilja računalniku za nadaljnje nadzorne namene.
Podobno, če je naprava pravkar povezana v omrežje, bo omrežju poslala tudi "obvestilo", da je pripravljena sprejeti nadzor od omrežja, kar je NOTIFY na programski ravni. Prav tako ga bodo sprejeli vsi računalniki znotraj območja "dosega zvoka". Računalnik bo "zaznal", da je naprava "poročala sama sebi". Pravzaprav se navodila NOTIFY ne pošiljajo le računalnikom, temveč jih lahko slišijo tudi druge omrežne naprave. Prav v zgoraj omenjenem oddajanju in poslušanju je težava!
Če heker pošlje ukaz NOTIFY uporabnikovemu sistemu, bo uporabnikov sistem prejel to navodilo NOTIFY in se po njegovih navodilih povezal s specifičnim strežnikom, nato pa zahteval storitev prenosa na ustrezni strežnik – prenesel vsebino storitve, ki se bo izvajala. Strežnik bo seveda odgovoril na to zahtevo. Servisni sistem UPnP bo pojasnil opis naprave, zahteval pošiljanje več datotek, strežnik pa bo moral na te zahteve odgovoriti. Na ta način nastane cikel "zahteve-odgovor", ki zasede veliko količino sistemskih virov in povzroči upočasnitev ali celo zaustavitev hitrosti storitve sistema UPnP. Tako bo ta napaka omogočila napad "zavrnitve storitve"!
Z drugimi besedami, funkcija UPNP med fazo uporabe nenehno porablja lastne omrežne vire, in ko so omrežni viri naprave izčrpani, pride do pojava suspendirane animacije. Poglejte zgornje informacije. |
Objavljeno na 12. 10. 2017 08:58:01
|
|
|
|
