UPNP aiškinamas taip: Privačiam kompiuteriui "BitComet" UPnP funkcija gali priversti šliuzo ar maršrutizatoriaus NAT modulį atlikti automatinį prievado atvaizdavimą ir susieti prievadą, kurio "BitComet" klausosi iš šliuzo ar maršrutizatoriaus, į intraneto kompiuterį.
Šliuzo arba maršrutizatoriaus tinklo užkardos modulis pradeda atidaryti šį prievadą kitiems kompiuteriams internete.
NAT perėjimo technologija leidžia žiniatinklio programoms nustatyti, ar jos yra už UPnP palaikančio NAT įrenginio. Tada šios programos gauna bendrą visuotinį maršrutizuojamą IP adresą ir sukonfigūruoja prievadų susiejimą, kad paketai būtų persiųsti iš NAT išorinių prievadų į programos naudojamus vidinius prievadus – visa tai automatiškai, vartotojams nereikia rankiniu būdu susieti prievadų ar daryti ką nors kito. NAT perėjimo technologija leidžia tinklo įrenginiams arba peer-to-peer programoms bendrauti su išoriniu pasauliu per NAT šliuzus, dinamiškai atidarant ir uždarant ryšio prievadus su išorinėmis paslaugomis.
Kitaip tariant, tai galima apibendrinti taip: paprasto NAT konversijos efektyvumas nėra didelis, o paleidus UPNP technologiją, NAT duomenų konvertavimo efektyvumą galima pagerinti.
Skamba kaip geras dalykas. Bet ką ???
UPNP turi rimtų trūkumų: Štai ištrauka:
Pirmasis trūkumas yra tas, kad buferių naudojimas nėra tikrinamas ir ribojamas. Išoriniai užpuolikai gali įgyti visos sistemos valdymo privilegijas! Kadangi UPnp funkcija turi naudoti kompiuterio prievadus, kad veiktų, užpuolikas, įgijęs kontrolę, taip pat gali naudoti šiuos prievadus, kad pasiektų užpuoliko tikslą. Šio defekto pasekmės yra labai rimtos, nesvarbu, kuri "Windows" sistemos versija, kol veikia UPnP, yra šis pavojus! Tačiau griežtai tariant, tai nėra visiškai pačios UPnP technologijos problema, o labiau programavimo priežiūra.
Antrasis trūkumas yra susijęs su UPnP veikimo mechanizmu. Defektas yra "įrenginio aptikimo" fazėje, kai veikia UPnP. Įrenginio atradimą galima suskirstyti į dvi situacijas: jei UPnP palaikantis kompiuteris sėkmingai paleidžiamas ir prisijungia prie tinklo, jis nedelsdamas išsiųs "transliaciją" į tinklą, pranešdamas UPnP įrenginiui tinkle, kad jis yra paruoštas, o programavimo lygmeniu transliacijos turinys yra M-SEARCH (pranešimo) instrukcija. Transliaciją "girdės" visi įrenginiai, esantys "garso pasiekiamoje vietoje". Ir grįžtamasis ryšys su savo svarbia informacija į kompiuterį vėlesniais valdymo tikslais.
Panašiai, jei įrenginys ką tik prijungtas prie tinklo, jis taip pat išsiųs "pranešimą" į tinklą, kad yra pasirengęs priimti valdymą iš tinklo, o tai yra NOTIFY indikacija programavimo lygiu. Jį taip pat priims visi kompiuteriai, esantys "garso pasiekiamumo" diapazone. Kompiuteris "pajus", kad įrenginys "pranešė sau". Tiesą sakant, NOTIFY instrukcijos siunčiamos ne tik į kompiuterius, bet ir gali būti girdimos kituose tinklo įrenginiuose. Būtent minėtoje transliacijoje ir klausyme yra problema!
Jei įsilaužėlis siunčia nurodymą NOTIFY į vartotojo sistemą, vartotojo sistema gaus šią instrukciją NOTIFY ir prisijungs prie konkretaus serverio pagal jo nurodymus, o tada paprašys atsisiuntimo paslaugos į atitinkamą serverį - atsisiųskite vykdomos paslaugos turinį. Serveris, žinoma, atsakys į šią užklausą. UPnP paslaugų sistema paaiškins įrenginio aprašymą, paprašys išsiųsti daugiau failų, o serveris turės atsakyti į šias užklausas. Tokiu būdu susidaro "užklausos-atsakymo" ciklas, kuris užima daug sistemos išteklių ir sukelia UPnP sistemos aptarnavimo greitį sulėtėti ar net sustoti. Taigi, šis trūkumas padarys "paslaugų atsisakymo" ataką įmanoma!
Tiesą sakant, kitaip tariant, UPNP funkcija naudojimo etape nuolat naudoja savo tinklo išteklius, o išnaudojus įrenginio tinklo išteklius, atsiras sustabdytos animacijos reiškinys. Tiesiog pažvelkite į aukščiau pateiktą informaciją. |
Paskelbta 2017-10-12 08:58:01
|
|
|
|
