UPNP interpretuje się następująco: Dla komputera prywatnego funkcja UPnP w BitComet może sprawić, że moduł NAT bramy lub routera automatycznie mapuje porty i mapuje port, do którego BitComet słucha z bramy lub routera, na komputer intranetu.
Moduł sieciowy zapory bramki lub routera zaczyna otwierać ten port dla innych komputerów w Internecie.
Technologia przechodzenia NAT pozwala aplikacjom webowym wykrywać, czy są za urządzeniem NAT obsługującym UPnP. Programy te otrzymują następnie wspólny globalny adres IP routowalny i konfigurują mapowanie portów tak, aby przekazywać pakiety z zewnętrznych portów NAT do wewnętrznych portów używanych przez aplikację – wszystko automatycznie, bez konieczności ręcznego mapowania portów czy innych działań przez użytkowników. Technologia przechodzenia NAT umożliwia uporządkowaniu sieciowym lub aplikacjom peer-to-peer komunikację ze światem zewnętrznym za pośrednictwem bram NAT poprzez dynamiczne otwieranie i zamykanie portów komunikacyjnych z usługami zewnętrznymi.
Innymi słowy, można to podsumować następująco: efektywność konwersji prostego NAT nie jest wysoka, a jeśli zostanie wprowadzona technologia UPNP, efektywność konwersji danych NAT może zostać poprawiona.
Brzmi jak dobra wiadomość. Ale co ???
UPNP ma poważne wady: Oto fragment:
Pierwszą wadą jest brak kontroli i ograniczenia stosowania. Zewnętrzni atakujący mogą dzięki temu uzyskać uprawnienia do kontroli nad całym systemem! Ponieważ funkcja UPnp musi korzystać z portów komputera, atakujący, który przejmuje kontrolę, może również wykorzystać te porty, aby osiągnąć cel atakującego. Konsekwencje tej wady są bardzo poważne, niezależnie od wersji systemu Windows, dopóki działa UPnP, istnieje to zagrożenie! Ale ściśle mówiąc, nie jest to wyłącznie problem samej technologii UPnP, lecz raczej niedopatrzenie programistyczne.
Druga wada dotyczy mechanizmu działania UPnP. Usterka występuje w fazie "wykrywania urządzenia", gdy UPnP działa. Odkrycie urządzenia można podzielić na dwie sytuacje: jeśli komputer z UPnP pomyślnie się uruchomi i połączy z siecią, natychmiast wyśle "broadcast" do sieci, informując urządzenie UPnP w sieci o gotowości, a na poziomie programowania treść nadawana jest instrukcja M-SEARCH (wiadomość). Transmisja będzie "słyszana" przez wszystkie urządzenia znajdujące się w "zasięgu dźwięku". I przekazuje komputerowi odpowiednie informacje do dalszego sterowania.
Podobnie, jeśli urządzenie jest właśnie podłączone do sieci, wysyła również "powiadomienie" do sieci, że jest gotowe do przyjęcia kontroli od sieci, co jest sygnałem NOTIFY na poziomie programowania. Zostanie również zaakceptowany przez wszystkie komputery w zakresie "zasięgu dźwięku". Komputer "wyczuje", że urządzenie "zgłosiło się do siebie". W rzeczywistości instrukcje NOTIFY są wysyłane nie tylko do komputerów, ale mogą być także słyszane przez inne urządzenia sieciowe. To właśnie w wspomnianym wcześniej nadawaniu i słuchaniu pojawia się problem!
Jeśli haker wyśle do systemu użytkownika instrukcję NOTIFY, system użytkownika otrzyma tę instrukcję i połączy się z konkretnym serwerem zgodnie z jej instrukcjami, a następnie zażąda usługi pobrania do odpowiedniego serwera – pobiera zawartość usługi do uruchomienia. Serwer oczywiście odpowie na to żądanie. System usług UPnP wyjaśni opis urządzenia, żądając wysłania kolejnych plików, a serwer będzie musiał na nie odpowiadać. W ten sposób powstaje cykl "żądanie-odpowiedź", który zajmuje dużą ilość zasobów systemowych i powoduje spowolnienie lub nawet zatrzymanie prędkości usługi systemu UPnP. Ta wada umożliwi atak "odmowy usługi"!
W rzeczywistości, innymi słowy, funkcja UPNP nieustannie zużywa własne zasoby sieciowe podczas etapu użytkowania, a gdy zasoby sieciowe urządzenia zostaną wyczerpane, następuje zjawisko animacji zawieszonej. Wystarczy spojrzeć na powyższe informacje. |
Opublikowano 12.10.2017 08:58:01
|
|
|
|
