UPNP tolkes slik: For en privat datamaskin kan BitComets UPnP-funksjon få NAT-modulen til gatewayen eller ruteren til å utføre automatisk portkartlegging, og kartlegge porten BitComet lytter til fra gatewayen eller ruteren til intranettdatamaskinen.
Nettverksbrannmurmodulen til gatewayen eller ruteren begynner å åpne denne porten for andre datamaskiner på Internett.
NAT-traverseringsteknologi gjør det mulig for webapplikasjoner å oppdage om de er bak en UPnP-kompatibel NAT-enhet. Disse programmene får deretter en delt global rutbar IP-adresse og konfigurerer portkartlegging for å videresende pakker fra NAT eksterne porter til de interne portene applikasjonen bruker – alt automatisk, uten at brukerne trenger å manuelt kartlegge porter eller gjøre noe annet. NAT-traverseringsteknologi gjør det mulig for nettverksenheter eller peer-to-peer-applikasjoner å kommunisere med omverdenen via NAT-gatewayer ved å dynamisk åpne og lukke kommunikasjonsporter med eksterne tjenester.
Med andre ord kan det oppsummeres slik: konverteringseffektiviteten til enkel NAT er ikke høy, og hvis UPNP-teknologi lanseres, kan effektiviteten til NAT-datakonvertering forbedres.
Høres ut som en god ting. Men hva ???
UPNP har alvorlige mangler: Her er et utdrag:
Den første feilen er at bruken av buffere ikke blir kontrollert eller begrenset. Eksterne angripere kan få kontrollrettigheter over hele systemet gjennom dette! Siden UPnp-funksjonen må bruke datamaskinens porter for å fungere, kan en angriper som får kontroll også bruke disse portene for å oppnå angriperens mål. Konsekvensene av denne feilen er svært alvorlige, uansett hvilken versjon av Windows-systemet, så lenge UPnP kjører, er det denne faren! Men strengt tatt er dette ikke helt et problem med UPnP-teknologien i seg selv, men mer en programmeringsfeil.
Den andre feilen er knyttet til UPnPs arbeidsmekanisme. Feilen eksisterer i "enhetsoppdagelsesfasen" når UPnP fungerer. Å oppdage en enhet kan deles inn i to situasjoner: hvis en UPnP-kompatibel datamaskin starter opp og kobler seg til nettverket, vil den umiddelbart sende en "broadcast" til nettverket, og varsle UPnP-enheten på nettverket om at den er klar, og på programnivå er sendingsinnholdet en M-SEARCH (melding) instruksjon. Sendingen vil bli «hørt» av alle enheter innenfor «lydområdet». Og gi tilbake relevant informasjon til datamaskinen for senere kontrollformål.
På samme måte, hvis en enhet nettopp er koblet til nettverket, vil den også sende en "varsling" til nettverket om at den er klar til å motta kontroll fra nettverket, som er en NOTIS-indikasjon på programmeringsnivå. Den vil også bli akseptert av alle datamaskiner innenfor "lydrekkevidde"-området. Datamaskinen vil "merke" at enheten har "rapportert til seg selv". Faktisk sendes NOTIFY-instruksjoner ikke bare til datamaskiner, men kan også høres av andre nettverksenheter. Det er i den ovennevnte sendingen og lyttingen at det oppstår et problem!
Hvis en hacker sender en NOTIFY-instruksjon til en brukers system, vil brukerens system motta denne NOTICE-instruksjonen og koble seg til en spesifikk server under sine instruksjoner, og deretter be om en nedlastingstjeneste til den tilsvarende serveren – laste ned innholdet i tjenesten som skal kjøres. Serveren vil selvfølgelig svare på denne forespørselen. UPnP-tjenestesystemet vil forklare beskrivelsen av enheten, be om at flere filer skal sendes, og serveren må svare på disse forespørslene. På denne måten dannes en "forespørsel-svar"-syklus, som opptar store mengder systemressurser og får UPnP-systemets tjenestehastighet til å senke eller til og med stoppe. Så denne feilen vil gjøre et «tjenestenektangrep» mulig!
Faktisk, med andre ord, bruker UPNP-funksjonen kontinuerlig sine egne nettverksressurser under bruksfasen, og når enhetens nettverksressurser er oppbrukt, vil det oppstå et fenomen med suspendert animasjon. Se bare på informasjonen ovenfor. |
Publisert på 12.10.2017 08:58:01
|
|
|
|
