UPNP şu şekilde yorumlanır: Özel bir bilgisayar için, BitComet'in UPnP fonksiyonu, gateway veya yönlendiricinin NAT modülünün otomatik port eşlemesini yapabilir ve BitComet'in dinlediği portu gateway veya router'dan intranet bilgisayarına eşleyebilir.
Gateway veya yönlendiricinin ağ güvenlik duvarı modülü, bu portu İnternet'teki diğer bilgisayarlara açmaya başlar.
NAT geçiş teknolojisi, web uygulamalarının UPnP özellikli bir NAT cihazının arkasında olup olmadığını tespit etmelerini sağlar. Bu programlar daha sonra paylaşılan küresel yönlendirilebilir IP adresi alır ve port eşlemesini NAT harici portlarından uygulama tarafından kullanılan dahili portlara paketleri iletmek için otomatik olarak yapılandırır – kullanıcıların portları manuel olarak haritalamasına veya başka bir şey yapmalarına gerek kalmadan. NAT geçiş teknolojisi, ağ cihazlarının veya eşler arası uygulamaların dış dünyayla dış dünyayla iletişim kurmasını sağlar; bu bağlantı portlarını harici servislerle dinamik olarak açıp kapatır.
Başka bir deyişle, şu şekilde özetlenebilir: basit NAT'ın dönüşüm verimliliği yüksek değildir ve UPNP teknolojisi başlatılırsa, NAT veri dönüşümünün verimliliği artırılabilir.
Kulağa iyi bir şey gibi geliyor. Ama ne ???
UPNP'nin ciddi eksiklikleri var: İşte bir alıntı:
İlk kusur, tampon kullanımının kontrol edilmemesi ve kısıtlanmamasıdır. Dış saldırganlar bu sayede tüm sistemin kontrol ayrıcalıklarını elde edebilir! UPnp fonksiyonu çalışmak için bilgisayarın portlarını kullanmak zorunda olduğundan, kontrolü ele geçiren saldırgan da bu portları saldırganın hedefine ulaşmak için kullanabilir. Bu kusurun sonuçları çok ciddi, Windows sisteminin hangi sürümü olursa olsun, UPnP çalışırken bu tehlike var! Ama kesin olarak söylemek gerekirse, bu tamamen UPnP teknolojisinin kendisiyle ilgili bir sorun değil, daha çok bir programlama gözden kaçıdır.
İkinci kusur ise UPnP'nin çalışma mekanizmasıyla ilgilidir. Kusur, UPnP çalışırken "cihaz keşfi" aşamasında bulunur. Bir cihazın keşfedilmesi iki duruma ayrılabilir: UPnP özellikli bir bilgisayar başarıyla önyüklenip ağa bağlanırsa, hemen ağa bir "yayın" gönderir ve ağdaki UPnP cihazına hazır olduğunu bildirir ve programlama düzeyinde yayın içeriği M-SEARCH (mesaj) talimatıdır. Yayın, "ses erişimi" içindeki tüm cihazlar tarafından "duyulacak". Ve ilgili bilgileri bilgisayara geri göndererek sonraki kontrol amaçları için.
Benzer şekilde, bir cihaz sadece ağa bağlıysa, ağdan kontrolü kabul etmeye hazır olduğuna dair bir "bildirim" gönderir; bu da programlama düzeyinde bir NOTIFY göstergesidir. Ayrıca "ses erişimi" aralığındaki tüm bilgisayarlar tarafından da kabul edilir. Bilgisayar, cihazın "kendine rapor verdiğini" "algılar". Aslında, NOTIFY talimatları sadece bilgisayarlara gönderilmez, aynı zamanda diğer ağ cihazları tarafından da duyulabilir. Yukarıda bahsedilen yayın ve dinlemede bir sorun var!
Bir hacker bir kullanıcının sistemine NOTIFY talimatı gönderirse, kullanıcının sistemi bu NOTIFY komutunu alır ve onun talimatları altında belirli bir sunucuya bağlanır, ardından ilgili sunucuya indirme hizmeti talep eder - hizmetin içeriğini indirmek için çalıştırılır. Sunucu elbette bu talebe yanıt verecek. UPnP servis sistemi, cihazın tanımını açıklayacak, daha fazla dosya gönderilmesini talep edecek ve sunucunun bu taleplere yanıt vermesi gerekecek. Bu şekilde, büyük miktarda sistem kaynağını kaplayan ve UPnP sistem hizmet hızının yavaşlamasına veya hatta durmasına neden olan bir "talep-yanıt" döngüsü oluşur. Yani, bu kusur bir "hizmet rededi" saldırısını mümkün kılacak!
Aslında, başka bir deyişle, UPNP fonksiyonu kullanım aşamasında sürekli kendi ağ kaynaklarını tüketiyor ve cihazın ağ kaynakları tükendiğinde, askıya alınmış animasyon olgusu ortaya çıkar. Yukarıdaki bilgilere bir bakın. |
Yayınlandı 12.10.2017 08:58:01
|
|
|
|
