Netscaler HTTP Dos Koruması

Transkript

1 Netscaler HTTP Dos Koruması Internet hacker ları bir siteye dalgalar halinde GET istekleri veya diğer HTTP seviyesinde istekleri göndererek aşağı indirebilirler. HTTP Denial-of-Service (HTTP Dos) konunan Web sunucularınıza yönlendirilen böyle saldırıları önlemek için etkili bir yol sağlar. HTTP Dos özeliği ayrıca internet cloud ve Web sunucularınız arasında kalan Netscaler cihazının bir HTTP Dos atağı tarafından aşağı indirilmesini önler. Internetteki çoğu saldırganlar hesaplama maliyetini azaltmak için web sunucularına geri yanıt dönmezler ve tespit edilmelerini önlemek için ebatlarını en aza indirgerler.bu saldırganlar atak paketlerini göndermek, bağlantı kurmak veya olabildiğince hızlı HTTP isteklerini göndermek için hız üzerinde odaklanırlar. Internet Explorer, Firefox veya NetScape browser lar gibi gerçek HTTP istemcileri HTML Refresh meta tag larını, Java script leri ve cookie leri anlayabilir. Standart HTTP istemcilerde bu özelliklerin çoku aktif durumdadır. Bu arada Dos saldırılarında kullanılan sahte istemciler sunucudan istemciye geri dönen yanıtları çözümleyemezler (pars edemezler). Eğer kötü niyetli istemciler istekleri çözümlemeye ve akıllıca göndermeye kalkışırlarsa saldırıları agresif başlatmak onlar için zor olur. Netscaler bir saldırıyı tespit ettiğinde, gelen isteklerin belli bir yüzdesine cookie veya basitce sayfanın yenilenmesini içeren Java veya HTML döner. (Client Detect Rate parametresi yle bu yüzde yi ayarlıyoruz). Gerçek Web tarayıcıları ve diğer Web tabanlı istemci programları sunucudan dönen yanıtı çözümleyebilir ve ondan sonra cookie ile bir POST isteğini tekrar gönderebilir. Dos istemcileri Netscaler ın yanıtını çözümlemek yerine drop lar ve onların istekleri de bu yüzden drop lanır. Meşru bir istemci Netscaler ın yenileme yanıtına (refresh response) doğru şekilde cevap verdiği zaman bile istemcinin POS isteğinde ki cookie aşağıda ki koşullarda geçersiz olabilir. Eğer orjinal istek Netscaler Dos saldırsını saptamadan önce yapıldıysa, ama tekrar gönderme isteği Netscaler saldırı altındaykenken yapıldıysa. Cookie geçersiz hale geldikten sonra,istemcinin düşünme zamanı dört dakikayı aştığından

2 Yukarda ki senaryoların ikiside çok nadirdir. Ek olarak HTTP Dos özelliğinin aşağıda ki sınırlamaları bulunmaktadır. Saldırı altında, Bütün POST istekleri düşürülür ve cookie ile bir hata sayfası gönderilir. Saldırı altında, cookie bulundurmayan bütün gömülü nesneler düşürülür ve bir cookie ile hata sayfası gönderilir. HTTP Dos özelliği belki Netscaler ın diğer özelliklerini etkileyebilir. Belirli bir contect switching kuralı için Dos korumasınıın kullanımı bu arada ekstra yük oluşturur. Çünkü Netscaler ın policy motoru eşleştirmek için policy yi bulmalıdır. Bu arada kriptolu verinin SSL kripto çözümünden dolayı SSL isteklerinde ekstra yük oluşturur Eğer Netscaler üzerinde priority queuing kuralı devreye aldıysanız, saldırı altındayken bile Netscaler cookie siz istekleri low-priority queue e koyar. Bu sizin için ekstra bir yük oluştursa bile, bu Web sunucularınızı sahte istemcilerden korur. Test JavaScript leri isteklerin küçük bir yüzdesine gönderildiğinden dolayı HTTP Dos korumasının tipik olarak throughput üzerinde minimal etkisi vardır.isteklerde gecikme artar çünkü istemci JavaScript I aldıktan sonra tekrar istek yapmalıdır. Bu istekler ayrıca kuyruğa atılır. HTTP Dos korumasını kullanmak için, bu özellik aktif edilmeli ve bu özelliği uygulamak için bir kural tanımlanmalıdır.daha sonra HTTP Dos için gerekli ayarlarla hizmetleriniz ayarlanmadır. Ayrıca her bir hizmete TCP monitor atanabilir ve TCP monitor ü yürürlüğe koymak için her bir hizmete oluşturduğunuz kural atanır. Layer 3-4 SYN Denial-of-Service Koruması Netscaler varsayılan olarak SYN Dos saldırılarına karşı koruma sağlıyor. Böyle bir saldırı düzenlemek için saldırgan büyük sayılarda TCP bağlantıları başlatır faka maüdur Sunucu tarafından gönderilen SYN-ACK mesajlarına cevap vermez. Sunucu tarafından alınana SYN mesajlarında ki kaynak ip adresi genellikle sahtedir. Çünkü yeni SYN mesajları bir önceki SYN mesajları tarafından başlatılan yarı açık bağlantılar zaman aşımına uğramadan önce ulaşır. Böyle bağlantı sayıları Sunucu yeni bağlantıları kabul edecek yeterli kullanılabilir memory si kalmayana kadar artar. Aşırı durumlarda sistem hafıza kümesi overflow olabilir. Netscaler SYN flood saldırılarına karşı kendini sistem hafıza kümesinde yarı açık bağlantı tutmak yerine SYN cookie kullanarak korur. Netscaler TCP bağlantı isteyen herbir istemciye a cookie gönderir. Fakat yarı açık bağlantıların durumunu tutmaz. Onun yerine Netscaler sadece en son ACK paketini alması üzerine veya bir HTTP isteği alması üzerine HTTP trafik için bir bağlantıya sistem hafızasında yer ayırır. Bu SYN ataklarını önler ve meşru istemcilerin kesintisiz olarak devam edebilmeleri için normal TCP bağlantılarına izin verir. Netscaler üzerinde ki SYN Dos koruması aşağıda ki leri garanti eder: Sahte SYN paketleri ile Netscaler hafızası boşa harcanmaz. Onun yerine hazıza sadece meşru istemcilere hizmet etmek için kullanılır.

3 Saldırı altındayken bile meşru istemcilerin normal TCP bağlantıları kesilmeksizin devam eder. Ek olarak, Netscaler hafızasını sadece, HTTP isteğini aldıktan sonra HTTP bağlantı durumu için ayırır. Bu Web suncularını idle bağlantı ataklarından korur. Netscaler üzerinde ki SYN Dos koruması harici bir konfigürasyon gerektirmez.varsayılan olarak üzerinde aktiftir. HTTP Dos korumasının aktif edilmesi HTTP Dos korumasını ayarlamak için öncelikle bu özelliği aktif etmeliyiz. Netscaler CLI ile HTTP Dos özelliğinin aktfi edilmesi > enable ns feature HttpDoSProtection > show ns feature Feature Acronym Status ) Web Logging WL ON 2) Surge Protection SP OFF... 10) Global Server Load Balancing GSLB ON 11) Http DoS Protection HDOSP ON 12) Content Filtering CF ON.. 23) HTML Injection HTMLInjection ON 24) NetScaler Push push OFF >

4 Netscaler GUI ile HTTP Dos özelliğinin aktif edilmesi 1. System>Settings gidelim. 2. Configure Advance Features etay panosunu açalım. HTTP Dos özelliğini aktif edelim ve Ok butonuna tıklayalım. HTTP Dos Policy tanımlama Netscaler CLI add dos policy <name> -qdepth <positive_integer> [-cltdetectrate <positive_integer>] set dos policy <name> -qdepth <positive_integer> [-cltdetectrate <positive_integer>] Örnek > add dos policy pol-http-dos -qdepth 30 > set dos policy pol-http-dos -qdepth 40 > show dos policy 1) Policy: pol-http-dos QDepth: 40

5 > Netscaler GUI 1. Security > Protection Features > HTTP DoS a gidelim 2. Detay panosundan Add butonuna tıklayalım 3. Name alanına oluşturmak istediğimiz HTTP Dos policy sinin ismini verelim. Queue Depth kutusuna Dos korumasının atanacağı servis üzerinde Dos koruması aktif edilmeden önce kuyruk büyüklüğünü (servis in kuyruğunda bekleyen istek sayısı) girmeliyiz. Client detect rate kutusuna servisin kuyruğunda ki bekleyen istek sayısı Queue Depth kutusunda ki değere eşit veya ondan büyük olduğunda istemciye gönderilecek olan yanıt yüzdesi girilmeli. Son olarak Create butonuna tıklayıp HTTP Dos policy sini oluşturalım. HTTP Dos Kuralının Servis e Atanması Netscaler CLI bind service <servicename> -policyname <policyname> Primary> bind service Service-HTTP-DoS -policyname HTTP_DoS_Policy

6 Primary> show service Service-HTTP-DoS Service-HTTP-DoS ( :80) - HTTP State: UP Last state change was at Sun Jan 10 00:32: Time since last state change: 0 days, 00:02: Server Name: Red_Server Server ID : None Monitor Threshold : 0 Max Conn: 0 Max Req: 0 Max Bandwidth: 0 kbits Use Source IP: NO Client Keepalive(CKA): NO Access Down Service: NO TCP Buffering(TCPB): NO HTTP Compression(CMP): NO Idle timeout: Client: 180 sec Server: 360 sec Client IP: DISABLED Cacheable: NO SC: OFF SP: ON Down state flush: ENABLED Appflow logging: ENABLED Process Local: DISABLED Traffic Domain: 0 1) Monitor Name: tcp-default State: UP Weight: 1 Passive: 0 Probes: 34 Failed [Total: 0 Current: 0] Last response: Success - TCP syn+ack received. Response Time: 0.0 millisec 1) DoS Policy :HTTP_DoS_Policy Netscaler GUI 1. Traffic Management>Load Balancing>Services e gidelim. 2. Detay panosundan HTTP Dos kuralını atamak istediğimiz servis I seçelim ve Open a tıklayalım. 3. Policies tab ını seçelim ve daha sonra HTTP Dos kuralını seçelim

7 4. Policy listesinden HTTP Dos policy mizi seçelim ve Select e tıklayalım. Policy Policy Binding de görülecektir. Bind a tıklayalım ve Policy yi servis e atayalım.

8

9 HTTP Dos Koruması nı Konumlandırmak için Ana Prensipler HTTP Dos korumasını test edilerek planlı bir şekilde devreye alınmalı ve sonrasında yakından performansı izlenmelidir. HTTP Dos korumasını devreye alırken bulunduğunuz ortama göre ince ayar yapmak için aşağıda ki bilgileri kullanabilirsiniz. Suncularınız tarafından desteklenen maksimum eş zamanlı bağlantı sayısı Sunucularınız tarafından desteklenen normal ve ortalama eş zamanlı bağlantı değerleri. Sunucunuzun oluşturacağı maksimum yanıt oranı (responses/sec) Sunucunuzun üstesinden gelebileceği maksimum trafik Ağ ınızın tipik trafiği. Maksimum elverişli upstream bantgenişliği. Bantgenişliğini etkileyen limitler (harici linkler, router, trafik dalgalanmasından mağdur olan bir yol üzerinde ki diğer kıritik cihazlar ) Daha fazla sayıda istemcinin bağlanmasına izin vermenin upstream ağ cihazlarını korumaktan daha önemli olup olmaması. Bir HTTP Dos saldırılarısının karektiristiğini belirlemek için aşağıda ki konuları gözönünde bulundurmalısınız. Geçmişte deneyimlediğiniz gelen sahte isteğin oranı nedir? Aldığın isteklerin tipleri nelerdir? (tamamlanmış POST, tamamlanmamış GET) Bir önceki saldırı downstream link leri sature etti mi? Hayır ise bantgenişliği neydi? HTTP istekleri hangi tip kaynak IP adresleri ve kaynak port lara sahipti? (tek bir subnetten IP adresi, sabit IP,birer birer artan port lar) Gelecekte hangi tip atakları bekliyorsun? Geçmişte hangi tip ataklara maruz kaldın? Dos saldırı korumasını en uygun değerine ayarlamak için size yardımcı olacak bütün bilgiler. Client Detection/JavaScript Yanıt Oranının Ayarlanması HTTP Dos koruması ayarlandıktan ve aktfif edildikten sonra eğer Surge Queue de bekleyen istemci sayısı HTTP Dos için QDepth alanında belirtilen maksimum istemciden daha fazlası ise HTTP Dos koruması tetiklenir. İstemciye Netscaler tarafından JavaScript olarak gönderilen varsayılan JavaScript yanıtlarının oranı sunucu yanıt oranının yüzdebiri dir. HTTP Dos için varsayılan yanıt oranı çoğu gerçek saldırı senaryoları için yetersizdir ve müşteri ortamına göre ince ayar yapılmalıdır. Örneğin farzedelim ki Web sunucusu saniyede maksimum 500 yanıt dönebilme kapasitesine sahip ama saniyede 10,000 istek alıyor. Eğer sunucu yanıtının yüzde biri JavaScipt olarak gönderilirse Netscaler saldırı kontrülü yapmak için istemcilere gönderielcek JavaScript yanıtı neredeyse yok denecek kadar azdır: Onbin bekleyen istemci isteğine karşın sadece beş

10 istemciye (500*0.01) JavaScript olarak yanıt gönderilecektir. Bu durumda gerçek istemcilerin sadece yüzde 0.05 i civarı JavaScript yanıtı alır. Bu arada eğer client detection/javascript yanıt oranı çok yüksekse (Örneğin yüzde 10, saniyede 1000 JavaScript olarak yanıt istemcilere göndermek için oluşturulur.) belki upstream link satüre olabilir ve upstream ağ cihazlarına zarar verebilir. Varsayılan Client Detect Rate i değiştirirken dikkatli çalışma yapılmalıdır. Eğer surge queue korumasını tetiklemek için ayarlanan surge queue dip eşik değeri örneğin 200 ise ve HTP Dos için QDepth değeri 200 girilmişse Netscaler attack ve no-attack mod ları arasında gidip gelir. Bu arzu edilmeyen bir durumdur. HTTP Dos özelliği bu durum için bir windows mekanizmasına sahiptir. Surge queue büyüklüğü HTTP Dos koruması için tasarlanan QDepth değerine ulaştığında atak mod tetiklenir. Surge Queue büyüklüğü QDepth değerinden aşağı düştüğü zaman ise no-attack moda girer. Burda bahsi geçen senaryoda eğer WINDOW_SIZE 20 olarak ayarlanmışsa Netscaler ın no-attack moda girmesi için surge queue büyüklüğü 180 değerinden aşağıda düşmelidir. Dos policy ayarlanırken konfigürayon esnasında QDepth değeri için WINDOW_SIZE dan daha büyük bir değer belirtilmelidir. Tetikleyici surge queue eşik değeri HTTP Dos Koruması nı Konumlandırmak için Ana Prensipler kısımında ki gözlemlere dayanarak belirlenmelidir. Güncelleme Geçmişi Revizyon Değişiklik Açıklaması Güncelleme Tatih 1.0 Orjinal Versiyon Veli Anlama Ocak 2016

11