Windows 2008 ve Syn Flood saldırıları - Nass oluyor da oluyor?

Türkçe

DDOS saldırılarını önleyebildiğini iddia eden firmalardan Prolexic'in 2012 ikinci çeyrek raporuna baktığımızda infrastructure denen OSI modelinin 3. ve 4. seviyelerini hedef alan SYN saldırılarının popülaritesini koruduğunu görüyoruz.

Bloğun teması az bilinenden bahsetmek olduğu için SYN saldırısı hangi prensiplere dayanır, nasıl gerçekleştirilir gibi kolayca ulaşabileceğiniz bilgilere pek fazla girmeyeceğim. Bu yazının konusu Windows 2008 ( Aslına bakarsanız Windows Vista'dan itibaren Windows 7, Windows 2008, Windows 2008 R2 ) işletim sistemlerinde SYN  ( flood ya da attack ) saldırısına karşı savunma mekanizmasının nasıl işlediği.

Microsoft Windows 2000'den beri işletim sistemlerini bu saldırı tipine karşı korumaya çalışıyor. Windows Vista öncesi işletim sistemlerinde TCP/IP yığını (stack) registry'nin "HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters" alanında aşağıda belirtilen anahtarlarda yapılan değişikliklerle sıkılaştırılıyor ve Syn saldırılarına karşı bir nebze korunma sağlanıyordu.

• TcpWindowSize 
• SynAttackProtect 
• TcpMaxConnectResponseRetransmissions 
• EnableDeadGWDetect 
• EnablePMTUBHDetect 
• EnablePMTUDiscovery 
• TcpMaxHalfOpen 
• TcpMaxHalfOpenRetried 

Microsoft Windows Vista ile birlikte TCP/IP yığınını yeniden tasarladığını, işletim sistemlerinde ağ iletişimin kitabını yeniden yazdığını duyurdu. İşte ne olduysa bundan sonra oldu, Microsoft'un mühendislerine göre Windows Vista ve sonrası işletim sistemlerinde Syn Attack koruması varsayılan olarak etkin ( enabled ) ve devre dışı bırakılamıyor. Ama korumanın ne zaman devreye girdiği, bağlantı limitleri gibi bilgiler muamma. MSDN bloglarında yazılanlara göre Windows artık Syn saldırısında kullanacağı eşik değerlerini CPU core sayısı ve hafıza'ya göre dinamik olarak hesaplıyor ve kaynakların durumuna göre yarı-açık bağlantı kuyruklarını kullanıyor,kuyruk dolduğunda yeni gelen istekleri RST bayraklı paketlerle reddediyor. Bu da "ne kadar ekmek o kadar köfte" ya da sunucu CPU ve hafıza kaynaklarınız ne kadar fazlaysa Syn saldırılarına karşı o kadar dayanıklısınız demek. Bir bakıma bu değişiklik iyi bir şey, yeni sunucu kurulumlarında bu saldırıya karşı korumayı etkin hale getirmek, ince ayar yapmak zorunda kalmıyorsunuz. Can sıkıcı tarafıysa savunma mekanizmasında hiçbir değişiklik yapamamanız. Yarı-açık bağlantıları görebileceğiniz hiçbir performans sayacının, SNMP objesinin olmaması da kötü. Kısa aralıklarla

netstat -n -p TCP | find "SYN_RECEIVED"

komutunu çalıştırmaktan hoşlananlardansanız başka.
Windows 2008 R2'nin SYN saldırısına karşı mukavemetini test etmek için Vmware ile oluşturduğum ortamda saldırı için Backtrack 5 kullandım. Gelişigüzel kaynak IP adresleriyle ( --rand-source anahtarı ile ) ve --flood anahtarıyla yani mümkün olan en hızlı şekilde hedefin TCP 80 portuna paket gönderimiyle yaptığım testte hedef olarak 2 sanal CPU'lu ( tek CPU ile test yaptığımda dumpcap ile paket kaybı çok fazla oldu RST paketlerini kaydedemedim) , 1 GB Ram'li Windows 2008 R2 Enterprise sürümü kullandım. Daha önce bahsettiğim gibi yarı-açık bağlantıların sayısını görebileceğiniz bir yer yok, netstat komutundan başka. Ama saldırı başladıktan sonra -ki bu saniyede 100'den fazla paket gönderimi demek- bu komutun çalışması bile birkaç dakika alıyor. Ben de kabaca fikir vermesi bakımından şöyle bir yöntem izledim.

Windows 2008 R2 SYN bayraklı ilk paketi aldıktan sonra bağlantıyı yarı-açık ( half-open) konumuna alıyor ve istemciden ACK bayraklı paket cevabı alana kadar 20 saniye boyunca SYN ve ACK bayraklı 3 paket gönderiyor. Testte gelişigüzel kaynak IP adresleri kullandığım için hedef tüm çabalarına rağmen gönderdiği SYN ve ACK bayraklı paketlere karşılık ACK bayraklı 3-way handshake paketi alamadığı için yarı-açık bağlantıyı RST bayraklı paketle sonlandırıyor ve donanım kaynaklarını da başka işler ya da yeni gelen yarı-açık bağlantı istekleri için kullanmaya devam ediyor. Yani saldırı başladıktan yaklaşık 20 saniye sonra yarı-açık bağlantı sayısı bir yandan azalmaya başlarken bir yandan da yeni istekler kabul edilmeye devam ediliyor. Dolayısıyla ben bu kadar düşük sistem kaynaklarına sahip sanal sunucu ilk RST bayraklı paketi göndermeye başlamadan önce spoofed yani sahte kaç IP adresinden SYN paketini kabul ettiğini ölçmeye çalıştım. Bunu yaparken de sık sık "http://hedef_sunucu" adresindeki varsayılan IIS karşılama sayfasına erişimin aksayıp aksamadığını, normal sayılabilecek web erişim isteklerinin saldırı altındayken RST paketiyle sonlandırılıp sonlandırılmadığını yine BackTrack çalışan sanal pc'den kontrol etmeye çalıştım.

Yaptığım testte saldırı başlar başlamaz CPU kullanımı %100'e ulaştı, memory kullanımındaysa aşırı bir yükselme gözlemlemedim. Memory kullanımını da hedef sunucuda Wireshark çalıştırarak ve paket yakalayarak arttırdım ve neredeyse tamamını kullanmama rağmen hedefin varsayılan web sayfasını ( IIS e hoşgeldin sayfasını ) açmada sıkıntı görmedim. Tabi ki test ortamı gerçeğe çok uygun değil ama şunu rahatlıkla söylemek mümkün, IIS yeterli sistem kaynaklarıyla MB seviyesinde bandwidth harcanan SYN saldırılarına karşı dimdik ayakta duracaktır. Yeterli sistem kaynakları nedir diye soracak olursanız bunun cevabını vermek zor, mesai saatleri dışında ya da sabaha karşı yapacağınız testlerle üretim ortamında kullandığınız sunucularınızda ihtiyacınız olan kaynakları tespit edebilirsiniz.

RST bayraklı paketler 93484 numaralı paketten itibaren gönderilmeye başlandığı için ( dikkat edin yaklaşık 21 saniye sonra RST ler gönderilmeye ve yarı-açık bağlantılar kapatılmaya başlanıyor ) 1'den 93484'e kadar ki ve kaynak IP adresi 10.10.10.2 ( saldırıya uğrayan hedef sunucunun IP adresi ) 'den farklı olan paketleri sayacağım.

Tam olarak 35988 paket ( aslında frame ) için yarı-açık bağlantı oluşturuluyor yani sistem kaynakları kullanılmaya başlanıyor, bundan sonra zaman aşımına uğrayan bağlantılar bir yandan kapatılıyor ama bu sırada yeni yarı-açık bağlantılar kuyruğa alınmaya devam ediyor. Dediğim gibi sayıyı tespit etmek zor. Gelişigüzel IP adresleri arasında D ve E sınıfı IP adresleri de mutlaka var - ki bu da bu IP adreslerinden gelen  bağlantı istekleri yarı-açık konuma alınmaz anlamına gelir.Saldırının ortalarında Netstat komutuyla "SYN_RECEIVED" durumundaki bağlantıları saydığımda bağlantı sayısının 200 ila 400 bin arasında değiştiğini gördüm. Microsoft yarı-açık bağlantı sayısını gösteren bir counter ya da SNMP objesi koysa çok daha net anlık sayılar elde edebilirdik. İncelemek isteyenler için Wireshark paket dosyasını yazının sonuna ekliyorum. Tekrar hatırlatıyorum CPU kaynakları saldırı testi sırasında çok fazla kullanıldığı için dumpcap ile kaydetmeye çalıştığım paketlerde kayıplar oluştu yani tüm paket trafiği kaydedilememiş olabilir.

İlgili Yazılarım
Windows Sunucularda Gerçek Zamanlı SYN-Flood Tipi Saldırı Tespiti - Nass oluyor da oluyor?
Syn Proxy'nin bilinmeyenleri - Nass oluyor da oluyor?
Hping ile Syn saldırısı yapmak veya yapamamak

Ref:
http://blogs.technet.com/b/platformtr/archive/2009/11/23/windows-vista-2008-windows-7-ve-windows-2008-r2-daki-syn-attack-protection-degisiklikleri.aspx
http://blogs.technet.com/b/netro/archive/2010/08/30/tcp-ip-stack-hardening-in-operating-systems-starting-with-windows-vista.aspx

English

English version is coming as soon as possible...