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 ,İstemcinin düşünme zamanı dört dakikayı

aştığından

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.İsteklerde 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.

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

Done

> show ns feature

Feature Acronym Status

------- ------- ------

1) 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

Done

>

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

Done

> set dos policy pol-HTTP-DoS -qDepth 40

Done

> show dos policy

1) Policy: pol-HTTP-DoS QDepth: 40

Done

>

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

Done

Primary> show service Service-HTTP-DoS

Service-HTTP-DoS (192.168.3.81:80) - HTTP

State: UP

Last state change was at Sun Jan 10 00:32:10 2016

Time since last state change: 0 days, 00:02:45.470

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

Done

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

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.

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ş

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