UDP bağlantı noktası kaynak yetersizliği hataları – (UDP Port leak)

Merhaba,

Geçen ay MS08-037 ve MS09-008 güvenlik güncellestirmeleri ile yapilan degisikliklerden bahsetmistim. Özellikle kisa süreli (ephemeral) baglanti noktalari ile ilgili degisiklikler nedeniyle firewall/router üzerinde gerekli ayarlamalari yapmak ve baglanti noktaslari ile ilgili engellemeleri buna göre ayarlamak gerekebilir.

Güncellestirmeler sonrasi DNS servisi kisa süreli olarak kullanilan baglanti noktalarini rastgele ayirir. UDP baglanti nokatalarini kullanan ve sistem üzerinde olan diger uygulamalar ile ilgili çakisma olusabilir. Yine bir önceki yazimda belirttigim gibi MaxUserPort registry anahtari ile birlikte kisa süreli baglanti noktalari araligi ayarlanabilir.

Eger sistem üzerinde çalisan diger servislerde rastgele baglanti noktalari kullaniyorsa, belirli bir süre herhangi bir problem ile karsilasmayabilirsiniz. Ancak WINSOCK socket uygulamalarindan biri UDP baglanti noktasi istediginde sistem kaynak kalmadigina dair bir hata mesaji dönebilir. Bu hata mesajlarindan en çok bilineni “kaynak yetersizligi” ile ilgili olandir:

Failed to bind the listening socket for the socket. Error = 10055

WSAENOBUFS (10055)
No buffer space available.
An operation on a socket could not be performed because the system lacked sufficient buffer space or because a queue was full.

Winsock socket uygulamalari ile ilgili hata mesajlari listesine asagidaki MSDN baglantisindan ulasabilirsiniz:
https://msdn.microsoft.com/en-us/library/ms740668(VS.85).aspx

Bu hata mesajinin nedeni, yukarida açiklamaya çalistigim gibi servis ya da uygulamalardan birinin sistem üzerinde tüm UDP baglanti noktasi kaynaklarini kullanmasidir.
Bu gibi baglanti noktasi problemlerinde sorun giderme adimlari olarak kullanacagimiz araçlardan biri NETSTAT’dir. Netstat bize UDP baglanti noktasina “bind” olmus islemlerin bir listesini verecektir.

Active Connections

Proto Local Address Foreign Address State PID
TCP 0.0.0.0:42 0.0.0.0:0 LISTENING 2616
TCP 0.0.0.0:53 0.0.0.0:0 LISTENING 1396
TCP 0.0.0.0:80 0.0.0.0:0 LISTENING 4
TCP 0.0.0.0:88 0.0.0.0:0 LISTENING 404
TCP 0.0.0.0:135 0.0.0.0:0 LISTENING 708
TCP 0.0.0.0:389 0.0.0.0:0 LISTENING 404

.

.

Ayni sekilde UDP baglantilarida listelenecektir. UDP, TCP gibi baglantinin durumu ile ilgili sorgu yapmadigi için hedef IP adresi ve baglanti durumu bilgiler görüntülenmeyecektir:

Proto Local Address Foreign Address State PID

UDP 0.0.0.0:42 *:* 2616
UDP 0.0.0.0:445 *:* 4
UDP 0.0.0.0:500 *:* 404
UDP 0.0.0.0:1040 *:* 1396
UDP 0.0.0.0:1058 *:* 1396
UDP 0.0.0.0:1128 *:* 1396
UDP 0.0.0.0:1129 *:* 1396
UDP 0.0.0.0:1134 *:* 1396
UDP 0.0.0.0:1221 *:* 1396
UDP 0.0.0.0:1243 *:* 1396
UDP 0.0.0.0:1261 *:* 1160
UDP 0.0.0.0:1272 *:* 1396
UDP 0.0.0.0:1278 *:* 1396

Son DNS servis güncellestirmeleri yüklendiginde yukarida bahsettigim gibi DNS servisinin belirli bir sayida UDP baglanti noktasini görebilirsiniz. Bunun için yapmaniz gereken komut isteminde netstat –ano veya netstat –bano komutlarini çalistirmanizdir. Burada –a anahtari tüm baglantilari, –n anahtari IP adreslerini ve baglanti noktalarini nümerik olarak, -o komutu ise PID (yani islem tanimlayicisini) göstermektedir. Bu anahtarlara ek larak –b anahtarini kullandigimizda hangi islem tanimlayicisinin (PID) hangi isleme ait oldugunu kontrol etmemiz gerekmeyecektir.

WSAENOBUFS (10055) hatasini aldigimiz sistemde netstat –bano komutu ile baktigimizda rastgele seçilen UDP baglanti noktalarinin hangi servis/uygulamaya ait oldugunu bulabiliriz. Benim üzerinde çalistigim problem kaydinda bu soruna DevManBE.exe (HP Power Manager) sebep oluyordu.

Windows'da belirli iletim denetimi protokolü baglanti noktalarini kullanan veya engelleyen programlari belirleme:
https://support.microsoft.com/kb/281336/tr

Okan Çetinim