UPNP tolkas som följande: För en privat dator kan BitComets UPnP-funktion få NAT-modulen på gatewayen eller routern att göra automatisk portmappning och kartlägga porten som BitComet lyssnar på från gatewayen eller routern till intranätdatorn.
Gatewayens eller routerns nätverksbrandväggsmodul börjar öppna denna port för andra datorer på Internet.
NAT-traverseringsteknik gör det möjligt för webbapplikationer att upptäcka om de ligger bakom en UPnP-kompatibel NAT-enhet. Dessa program får sedan en delad global routbar IP-adress och konfigurerar portmappning för att vidarebefordra paket från externa NAT-portar till de interna portar som applikationen använder – allt automatiskt, utan att användarna behöver mappa portar manuellt eller göra något annat. NAT-traverseringsteknik gör det möjligt för nätverksenheter eller peer-to-peer-applikationer att kommunicera med omvärlden via NAT-gateways genom att dynamiskt öppna och stänga kommunikationsportar med externa tjänster.
Med andra ord kan det sammanfattas så här: konverteringseffektiviteten för enkel NAT är inte hög, och om UPNP-teknik lanseras kan effektiviteten av NAT-datakonvertering förbättras.
Låter som något bra. Men vad ???
UPNP har allvarliga brister: Här är ett utdrag:
Den första bristen är att användningen av buffertar inte kontrolleras och begränsas. Externa angripare kan få kontrollrättigheter över hela systemet genom detta! Eftersom UPnp-funktionen måste använda datorns portar för att fungera, kan en angripare som får kontroll också använda dessa portar för att uppnå angriparens mål. Konsekvenserna av detta fel är mycket allvarliga, oavsett vilken version av Windows-systemet det är, så länge UPnP körs finns denna fara! Men strikt taget är detta inte helt ett problem med UPnP-teknologin i sig, utan mer ett programmeringsfel.
Den andra bristen är relaterad till UPnP:s arbetsmekanism. Defekten finns i "enhetsupptäckt"-fasen när UPnP fungerar. Att upptäcka en enhet kan delas in i två situationer: om en UPnP-kompatibel dator startar framgångsrikt och ansluter till nätverket, kommer den omedelbart att skicka en "broadcast" till nätverket, som meddelar UPnP-enheten i nätverket att den är redo, och på programnivå är sändningsinnehållet en M-SEARCH (meddelande) instruktion. Sändningen kommer att "höras" av alla enheter inom "ljudområdet". Och återge sin relevanta information till datorn för efterföljande kontrolländamål.
På samma sätt, om en enhet bara är ansluten till nätverket, skickar den också en "notis" till nätverket om att den är redo att ta emot kontroll från nätverket, vilket är en NOTAGE-indikation på programnivå. Den kommer också att accepteras av alla datorer inom "ljudräckvidd"-intervallet. Datorn kommer att "känna" av att enheten har "rapporterat till sig själv". Faktum är att NOTICE-instruktioner inte bara skickas till datorer, utan kan även höras av andra nätverksenheter. Det är i den ovan nämnda sändningen och lyssningen som det uppstår ett fel!
Om en hackare skickar en NOTIFY-instruktion till en användares system, kommer användarens system att ta emot denna NOTIFY-instruktion och ansluta till en specifik server under sina instruktioner, och sedan begära en nedladdningstjänst till motsvarande server – ladda ner innehållet i tjänsten som ska köras. Servern kommer naturligtvis att svara på denna förfrågan. UPnP-tjänstesystemet kommer att förklara beskrivningen av enheten, begära att fler filer ska skickas, och servern måste svara på dessa förfrågningar. På detta sätt bildas en "request-response"-cykel, som upptar stora mängder systemresurser och får UPnP-systemets servicehastighet att sakta ner eller till och med stanna. Så denna brist kommer att göra en "denial of service"-attack möjlig!
Med andra ord förbrukar UPNP-funktionen ständigt sina egna nätverksresurser under användningsstadiet, och när enhetens nätverksresurser är slut uppstår ett fenomen av suspenderad animation. Titta bara på informationen ovan. |
Publicerad på 2017-10-12 08:58:01
|
|
|
|
