UPNP fortolkes således: For en privat computer kan BitComets UPnP-funktion få NAT-modulet på gatewayen eller routeren til at udføre automatisk portkortlægning og kortlægge porten, som BitComet lytter til, fra gatewayen eller routeren til intranetcomputeren.
Gatewayens eller routerens netværksfirewallmodul begynder at åbne denne port til andre computere på internettet.
NAT-traverseringsteknologi gør det muligt for webapplikationer at opdage, om de er bag en UPnP-kompatibel NAT-enhed. Disse programmer får derefter en delt global routabel IP-adresse og konfigurerer portmapping til at videresende pakker fra NAT-eksterne porte til de interne porte, applikationen bruger – alt sammen automatisk, uden behov for, at brugerne manuelt skal kortlægge porte eller gøre andet. NAT-traverseringsteknologi gør det muligt for netværksenheder eller peer-to-peer-applikationer at kommunikere med omverdenen via NAT-gateways ved dynamisk at åbne og lukke kommunikationsporte med eksterne tjenester.
Med andre ord kan det opsummeres således: konverteringseffektiviteten af simpel NAT er ikke høj, og hvis UPNP-teknologi lanceres, kan effektiviteten af NAT-datakonvertering forbedres.
Det lyder som en god ting. Men hvad ???
UPNP har alvorlige mangler: Her er et uddrag:
Den første fejl er, at brugen af buffere ikke er kontrolleret eller begrænset. Eksterne angribere kan opnå kontrolrettigheder over hele systemet gennem dette! Da UPnp-funktionen skal bruge computerens porte for at fungere, kan en angriber, der får kontrol, også bruge disse porte til at opnå angriberens mål. Konsekvenserne af denne fejl er meget alvorlige, uanset hvilken version af Windows-systemet det er, så længe UPnP kører, er der denne fare! Men strengt taget er det ikke udelukkende et problem med UPnP-teknologien i sig selv, men mere en programmeringsfejl.
Den anden fejl er relateret til UPnP's arbejdsmekanisme. Fejlen eksisterer i "enhedsopdagelsesfasen", når UPnP fungerer. Opdagelsen af en enhed kan opdeles i to situationer: hvis en UPnP-kompatibel computer starter op og forbinder til netværket, vil den straks sende en "broadcast" til netværket, hvor UPnP-enheden på netværket bliver meddelt, at den er klar, og på programniveau er broadcast-indholdet en M-SEARCH (besked) instruktion. Udsendelsen vil blive "hørt" af alle enheder inden for "lydens rækkevidde". Og give den relevante information tilbage til computeren til efterfølgende kontrolformål.
Tilsvarende, hvis en enhed blot er tilsluttet netværket, vil den også sende en "notifikation" til netværket om, at den er klar til at modtage kontrol fra netværket, hvilket er en NOTIFY-indikation på programmeringsniveau. Den vil også blive accepteret af alle computere inden for "lydrækkevidde"-området. Computeren vil "fornemme", at enheden har "rapporteret til sig selv". Faktisk sendes NOTIFY-instruktioner ikke kun til computere, men kan også høres af andre netværksenheder. Det er i den ovennævnte udsendelse og lytning, at der opstår et problem!
Hvis en hacker sender en NOTIFY-instruktion til en brugers system, vil brugerens system modtage denne NOTIFY-instruktion og forbinde til en specifik server under sine instruktioner, og derefter anmode om en downloadtjeneste til den tilsvarende server – downloade indholdet af den service, der skal udføres. Serveren vil naturligvis svare på denne anmodning. UPnP-servicesystemet vil forklare beskrivelsen af enheden, anmode om flere filer, der skal sendes, og serveren skal svare på disse anmodninger. På denne måde dannes en "request-response"-cyklus, som optager store mængder systemressourcer og får UPnP-systemets servicehastighed til at sænke eller endda stoppe. Så denne fejl vil gøre et "denial of service"-angreb muligt!
Med andre ord forbruger UPNP-funktionen konstant sine egne netværksressourcer under brugsfasen, og når enhedens netværksressourcer er opbrugt, vil der opstå et fænomen suspenderet animation. Se bare på ovenstående information. |
Opslået på 12/10/2017 08.58.01
|
|
|
|
