Türkçe
RFC 2616'da tanımlanan HTTP 1.1 protokolüne göre HTTP Request headerlar birbirinden CR ( Carriage Return ) ve LF (Linefeed) karakterleriyle ayrılır (kafanız karışmasın satır sonlarında alt satıra geçişi gösteren karakterler). Headerlar ile asıl verinin iletildiği Body kısmını ise boş bir satır birbirinden ayırır. Hernekadar GET Requestlerin body kısmı boş olsa da isteğin web sunucu tarafından alınması ve değerlendirilmesi için yine de headerların bitişini simgeleyen boş satıra ( CR + LF ) ihtiyaç duyulur. Sunucu bu karakterleri görmezse rahat edemez ve Request headerların tamamlanmadığını düşünür ,istemciden Request headerların tamamı gelene kadar beklemeye devam eder, bağlantıyı da işletim sistemine ve web sunucusuna göre farklılık gösteren zamanaşımı süresi (timeout) dolana kadar açık tutar. Olması gereken, iyi niyetli insanların tasarladığı şekliyle protokol bu şekilde çalışıyor.
Resim 1
İşte Slow Loris'in kötü amaçla ama aynı zamanda zekice kullandığı daha doğrusu zaafiyete uğrattığı özellik de tam olarak budur. Slow loris gönderdiği HTTP GET Request'in headerlarını tamamlamaz, yani boş satır karakterini göndermez - ki web sunucu da "oh nihayet istek geldi ( request headerların tamamı geldi ), şimdi beklemeyi bırakıp kendi işime bakabilirim" desin. Aşağıdaki ekran görüntüsü aracı test modunda (araç test modunda sunucunun tahmini bekleme zaman aşımı süresini hesaplıyor bu da araç saldırı amacıyla kullanılacağında gerekli olan bir parametre) çalıştırdığımda gelen giden trafiği gösteriyor.
Resim 2
Resim 3
Script Kiddie'lerin favorilerinden olan araç Resim 2'de görüldüğü gibi "Content-Length" Headerından sonra belirli aralıklarla, sunucuyu mümkün olduğunca meşgul tutacak ve zamanaşımına uğramayacak şekilde "X-a" headerları gönderiyor. Siz Perl scriptte değişiklik yapıp bu header ismini değiştirebilirsiniz ( Ahmet, Mehmet yapın mesela) ,nihayetinde güvenlik cihazları bu tip belirgin Header'ları tanır,bilir ve sevmezler. İletişim sunucu ya da işletim sistemi tarafından engellenmediği ya da zamanaşımına uğramadığı sürece, bu headerlar saldırı yapılırken parametre olarak verilen timeout süresi boyunca gönderilir böylece sunucu kaynakları meşgul edilir ve nihayetinde sunucu hizmet veremez hale gelir.
Scripti bizzat hazırlayan kişinin belirttiğine göre bir takım web sunucuları bu saldırı tipinden etkilenmiyor, Versiyon 6 ve üzeri IIS Web sunucuları da etkilenmeyen sunuculardan. Ama gördüğüm kadarıyla kazın ayağı aslında öyle değil. Testlerde kullandığım sanal bilgisayarların IP adresleri şöyle;
Saldırgan ( Backtrack 5) : 10.10.10.4
Hedef ( IIS 7.5 web sunucusu) : 10.10.10.2
Varsayılan ayarlarla kurulduğunda IIS 7 ve 7.5, GET isteğinin yapıldığı paketi aldıktan sonra yaklaşık 120 saniye bağlantıyı açık ( ESTABLISHED durumunda ) tutar ve bu 120 saniye sonunda hala GET isteğindeki headerlar gönderilmediyse "yeter kardeşim seni mi bekliycem bütün gün" deyip RST bayraklı paketle bağlantıyı sonlandırır.(Resim 4'de 37 no'lu paket)
Resim 4
Slow Loris de bundan sunucunun timeout süresinin 90 saniye olabileceği tahmini sonucunu çıkarır (Resim 5), siz de "ha öyle mi?!" deyip bu timeout süresini scripti saldırı amacıyla kullanırken kullanırsınız.
Resim 5
Slow Loris ve bu araca karşı alınabilecek önlemlerin anlatıldığı yazılarda ve makalelerde özellikle IIS web sunucularda alınabilecek önlemlerden biri olarak "header wait timeout" değerinin düşürülmesinden bahsedilir ve bu değerin "IIS ApplicationHost.config" dosyasından elle ya da "appcmd.exe" aracılığıyla komut satırından değiştirilebileceği anlatılır.
"HeaderWaitTimeout" değerinin, web sunucusunun bir istekle gelen tüm headerları almak için bekleyeceği süreyi ifade eder ve HTTP protokolündeki bu zaafiyeti bir nebze azaltmak için IIS 6 sürümüyle birlikte kullanılmaya başlandığı söylenir.
appcmd.exe set config -section:system.applicationHost/webLimits /headerWaitTimeout:"00:00:30" /commit:apphost
komutuyla gerekli değişikliği yaparsınız, zaman aşımı süresini düşürürsünüz ancak faydası olmaz işletim sisteminin erişimi hala 120 saniye sonra kestiğini görürsünüz. Yine bu makalelerde anlatıldığı gibi ConnectionTimeout, minBytesPerSecond gibi değerlerde değişiklik yapsanız da IIS'in headerları bekleme süresini azaltamazsınız. Burası önemli ve bunu kimse yazdığını çizdiğini göremezsiniz ;
Sizin yukarda anlattığım yöntemle IIS'de yapacağınız değişikliğin bu saldırı tipine göre pek bir önemi yoktur çünkü Slow Loris ile yapılan istek tamamlanmadığı için henüz HTTP listener (http.sys)'dan sunucuya ulaşmamıştır yani istek kuyruğuna ( request queu ) gönderilmemiştir. Slow Loris isteklerini IIS log dosyalarında görmemenizin nedeni de budur. Bu nedenle yapılması gereken kernel mod da device driver olarak çalışan HTTP Listener ( http.sys) ın "header wait timeout" değerini düşürmektir. Bunu da netsh aracıyla Resim 6'da gösterildiği gibi ve aşağıdaki komutla yapmalısınız;
add timeout timeouttype=headerwaittimeout value=saniye_cinsinden_süre
"netsh http> show timeout" komutunun çıktısı IIS'in neden 120 saniye sonra tamamlanmamış Request Headerlar için RST bayraklı paket gönderdiği sorusunu cevaplıyor.
Resim 6
HTTP Listener servisinin "header wait timeout" değerini Resim 6 daki gibi 15 saniye yaptıktan sonra ( ekran görüntüsündeki bu düzenleme http request ile gönderilmesi gereken headerların tamamını almak için 15 saniye bekle, headerların tümü bu süre içinde gönderilmediyse bağlantıyı kes anlamına gelir), Slow Loris'i test modunda çalıştırdığımızda sunucunun bağlantı kesme isteğinin yaklaşık 27 saniye sonra RST bayraklı paketle geldiğini görebilirsiniz. ( Resim 7 )
Resim 7
Slow Loris de 30.saniyede göndereceği ACK paketinden önce RST paketi aldığı için timeout süresini tahmini 2 saniye olarak gösterir.
Resim 8
Aynı testi yine sanal makineye varsayılan ayarlarla kurduğum Ubuntu + Apache 2.2.22 kombinasyonunda yaptığımda ise Apache'nin yaklaşık 20 saniye sonra istemciye "HTTP 408 Request Time-Out" durum kodunu gönderdiğini ve 30. saniyede ise RST bayraklı paketle iletişimi kopardığını gördüm. ( Resim 9 )
Resim 9
Bu yazıda IIS web sunucuların varsayılan ayarlarıyla Slow Loris'e karşı göründüğü kadar mukavemeti olmadığını anlatmaya çalıştım.Header Wait Timeout'dan başka IIS Request Filtering özelliği ile Headerlara da sınırlama getirilerek Slow Loris ile yapılan saldırının bertaraf edilebileceği de söylenir ama daha önce bahsettiğim gibi Request tamamlanmadığı için HTTP Listener ( http.sys ) isteği request queu'ya atmayacak, dolayısıyla istek IIS worker process'ler tarafından cevaplanmayacaktır ,haliyle burada yapılacak düzenlemelerin de Slow Loris'le yapılan saldırıda etkili olacağını sanmıyorum. Test etmedim,denemedim. Bu yazıyı yazmak epey zamanımı almadı, fırsat bulduğumda bu kısıtlamaların da ne derece etkili olduğunu kontrol eder bu yazıyı da gerekirse güncellerim.
Bu aracın gerçekleştirdiği saldırıyla ilgili görüp görebileceğiniz tek şey HTTP Hata logundaki ( HttpErr Log) aşağıdaki gibi kayıtlar olabilir,ne IIS logunda ne Event loglarda başka birşey göremezsiniz.
Resim 10
Meraklısına;
Loris Nycticebus:Lorisler gece vakitlerinde faaliyet gösteren ve son derece yavaş hareket eden hayvanlardır. Bir av gördüklerinde çok yavaş ve dikkatli bir şekilde sürünerek yaklaşırlar. O kadar sessizce hareket ederler ki, duran bir böceği ya da uyumak üzere olan bir kuşu, onlar tehlikeyi farketmeden önce yakalayabilirler. Lorisler ağaçlarda asılı durarak yaşayan canlılardır. Başka bir canlının Loris kadar -kimi zaman tüm gün boyunca- bir dalda asılı kalması oldukça zordur. Loris içinse sürekli olarak ağaçlarda asılı kalmak hiçbir sorun oluşturmaz. Çünkü Loris'in ön kollarının her biri, kan akışını düzenleyen kapsamlı bir kan damarı ağına sahiptir.
İlgili Yazılarım
HTTP DoS'a Karşı Javascript'le Mücadele - Nass oluyor da oluyor?
IIS Sıkılaştırma Klavuzu - Nam-ı diğer Security Hardening Guide
Low Orbit Ion Cannon ( LOIC ) ve Http Redirection Yanılsaması - Nass oluyor da oluyor?
IIS 7 - 7.5 Request Filtering - Nass oluyor da oluyor ? File Name Extension & HTTP Verb filtreleme
IIS 7 - 7.5 Request Filtering - Nass oluyor da oluyor ? Rules & Headers
English
Hiç yorum yok:
Yorum Gönder