DDOS Atak Mitigation Tekniği - SYN Cookie

 Bugün DDOS Atak Mitigation tekniklerinden birisi olan SYN Cookie den bahsedelim. 

Cookie internet dünyasında bir kullanıcıya atanan ve bir sunucuya istek yapan bu kullanıcı için "Evet seni geçmişten tanıyorum" diyen bir header. Peki SYN Cookie nedir ? 

Syn Cookie de aslında benzer işlemi Layer 7'de değil de Layer 4'de gerçekleştiren bir teknik. Niye ve Nasıl ? 

Layer 4 Transport katmanı temelde 2'ye ayrılır. TCP ve UDP olarak. TCP 3-way handshake ile önce bir connection kurar daha sonra ise paket alışverişi başlayabilir, session kurulabilir. 3-Way handshake görselde de görüleceği üzere bir sunucuyu ziyaret edecek ya da bir hedefe istekte bulunacak istemcinin selam vermesi ve selamına yanıt alması durumudur. (Resim-1)

Resim-1

1.SYN - 2.SYN/ACK - 3.ACK 

TCP çalışan her servis kendisine verilen selamı direk olarak yanıtlamaktadır. Kim sunucuya SYN derse sunucu otomatik olarak SYN/ACK demektedir. 3.adımda istemci de ACK gönderirse 2 taraf arasında bağlantı kurulacaktır. Ancak burada şu soruyu sormakta fayda var, bir sunucu ya da bir sistem kaç tane bu şekilde bağlantıyı destekleyebilir ? Tabiki hiçbir sistem ya da sunucu sınırsız değil. Google bile :)

Ancak sorun burada legal kullanıcılar değil. Sistemler, bankalar, alışveriş siteleri kendi altyapılarını müşterilerinin, yeterli bağlantıyı yapabilecekleri şekilde tasarlıyorlar. Burada illegal kullanıcılar, rakipler ya da fidyeciler asıl sorun. Bir alışveriş sitesine mail atıp "bana 3 bitcoin ver yoksa DDOS yaparım" diyen kötü niyetliler ile her zaman karşı karşıyayız. Bu sebepten herkesin SYN isteğine SYN/ACK yollayan bir sistem günün sonunda yeni bir bağlantıya SYN/ACK yollayamıyacak kadar kapasitesini doldurabilir. Yani SYN Flood DDOS Atağa karşı sistemler koruma sağlamıyorsa finalde 404 hatası bile veremeyecek kadar erişilemez olabilir.

Syn Flood DDOS u mitigate etmenin yollarından birisi olan SYN Cookie nasıl çalışır ? 

Bir sunucuya normalin çok üzerinde SYN isteği gelse bile,SYN/ACK yanıtı veriyor ve bir tabloya yazıyor, ancak sonunda tablo doluyor ya da tablo eşik bir limitin üzerine çıkıyor. Limit aşıldıktan sonra gelen her SYN isteğine yanıt vermeliyim ancak bu isteği tabloya yazmamalıyım şeklinde bir yaklaşım benimsenmeli. Sunucunun tabloya yazmadığı SYN isteği için, 3-WAY handshake in son aşaması olan, istemcinin ACK yollamasından sonra bağlantı kurulmalı, ancak ilk gönderilen SYN'i tabloda tutmadıysam ACK yollayan kişiyi nereden tanıyacağım. 

Layer 4 ve üzerinde, TCP çalışan her sistem Sequnence (Sıra) numarası kullanır. Aşağıdaki şekilde de gördüğünüz gibi istemci(Resim-2), her yolladığı paketi bir sıra numarası ile yollar ve bunu düzenli olarak arttırır. Aynı şekilde sunucu da her yolladığı paketi bir sıra numarası ile gönderir ve sıra numarasını sonraki paket için bir arttırır. Bir de Acknowlodgment Number(AckNumber) var. AckNumber tarafların karşıdan beklediği paket numarasını belirtir. AckNumber için şöyle bir örnek verelim. Sunucuya SYN gönderen istemci, sunucudan hemen bir SYN/ACK yanıtı alıyor. Bu istemciye gönderilen SYN/ACK yanıtının Sequence Number'ını sunucu "100" olarak belirlesin. Daha sonra istemci, ACK paketini yolladığı zaman, aynı paketin içeriğinde AckNumber'ı da gönderir. Göndermiş olduğu bu AckNumber daha önce de söylediğimiz gibi karşıdan isteği paketin numarasıdır. Yani Ey Sunucu bana bir önce göndermiş olduğun paketin Sequence Number'ı 100 idi şimdi senden sıradaki paketi yani "101" Sequence Numberlı paketi bekliyorum der. AckNumber=101. 

   Resim-2

Bir istemci sunucuya SYN isteği yolladığ zaman, sunucu SYN/ACK yanıtı gönderiyor ve bu gönderdiği SYN/ACK yanıtına bir Sequence Number veriyor. Sunucu artık SYN/ACK yanıtını gönderdikten sonra tabloya yazmak yerine sanki kendisine hiç SYN gelmemiş gibi davranacak. Ancak kendisine SYN/ACK'ın karşılığı olan bir ACK, istemci tarafından gönderilirse de hemen onu hatırlayacak evet sen bana geçmişte SYN yollamıştın diyecek. SYN Cookie'nin görevi tam olarak bunu sağlamak. Bir istemci SYN isteği yolladığı zaman sunucu, SYN isteği yollayan istemcinin IP Adresi, SYN İsteği yollayan istemicinin Source Port numarası gibi, istemciyi unique olarak tarif edebilecek değerleri bir algoritmaya sokar. Çıkan değeri ise sequence number olarak kullanır. Yani sunucu kendisine SYN isteği gönderen kullanıcıyı Sequence Numberdan tanıyabilecek durumdadır. Bir istemci sunucuya 3-Way Handshake'in son aşaması olan ACK ve AckNumber değeri gönderince sunucu tabloyu kontrol etmeden istemcinin kim olduğunu anlayacaktır. AckNumber'a baktığı zaman hemen şu hesabı yapacak:"Geçmişte ben bu istemciye 1231231 sequnce numarası ile SYN/ACK yollamışım ki şimdi bana ACK paketini 1231232 AckNumber'ı ile gönderiyor." Daha sonra bu 1231231 sayı değerini reverse bir işleme sokarak IP ve Port numarası çıkarımını yapıp, ACK gönderen kullanıcının IP ve Port numarası ile karşılaştırıyor. Her şey eşleştikten sonra bağlantı kurulabilir. 

Sonuç olarak SYN Flood atak bizim tablomuzu dolduramadı ve online satışlar devam etti. Teşekkürler Arbor, A10 vs. :)

Kurumları Hedef Alan DDOS Saldırı Olay Yönetimi (Özet) - Incident Management

Olay yönetiminin nasıl yapılması gerektiğinin anlatmaya yönelik bir yazıdır. Konunun ele alınması için DDOS Atak örneği kullanılmıştır.

Aşağıdaki yazıda kullanılan kişi ve kurum isimleri hayali yaşanan olay ise gerçektir.

Yaşaşan saldırıya asıl hedef olan X Bankasıdır. Ancak Y bankası ve diğer bankalar amplifikasyonun yapılması için zıplama noktası olarak kullanılmıştır.

2019 yılı Ekim ayında Türkiye'deki bankaları ve bu bankalar üzerinden de X Bankasını hedef alan DDOS atak sonucunda bazı bankaların servislerinde kısa süreli kesintiler X Bankasında da uzun süreli kesinti meydana gelmiştir. Ancak asıl hedefin X Bankası olduğu bu saldırıda zıplama noktası olarak kullanılan Y Bankası az oranda etkilenmiştir ve ilgili ekipler hızlıca bir araya gelerek olay anında değerlendirme ve aksiyonlarda bulunmuştur.

Atak tipi itibariyle Amplifikasyon (Amplification) ve Yansıtıcı(Reflector) ataktır. Bu atakta amaç genellikle bant genişliğini doldurmaya yöneliktir. Atak alt tipi DNS Amplifikasyon/Reflector olarak sınıflandırılmaktadır. Saldırgan kendisini gizleyerek ve mevcut tahribat gücünü yükselterek hedefte kesinti amaçlamaktadır.

DNS (Domain Name System) isim çözme amacıyla kullanılan ve evrensel olarak UDP/TCP 53 portunu kullanan, 7.katmanda çalışan bir servistir. Amacı kendisine sorgu olarak gönderilen alan adı, sistem adı vb. isteklere IP Adres çözümlemesi yaparak yanıt vermektir. Örnek vermek gerekirse www.youtube.com adresine erişmek için tarayıcınızın ilgili kısmına siteyi yapıştırdınız. Kullanmış olduğunuz bilgisayar ilk olarak hangi DNS IP Adresini kullandığınıza kontrole eder.        

Sorguya DNS Sunucusundan verilen yanıt aşağıdaki gibidir.

DNS isteğinin boyutunu 24 byte olarak kabul edilebilir. DNS yanıtı ise ortalama olarak 150 byte olarak kabul edilebilir. Bu bilgi ışığında eğer bir DNS Sunucusuna www.youtube.com adresini sormak için sunucuya giriş yönünde (download/receive) 24 byte boyutunda bir trfaik oluşur. Sunucu bu DNS sorgusunun geldiği kaynak IP Adresine ise 150 Byte’lık bir yanıt dönecektir. Bu durumda ise sunucudan çıkış yönünde (upload/transceive) 150 Byte’lık bir trafik oluşacaktır. Yani her sorgu, sorgunun katlarcası boyutta upload trafiği oluşturmaktadır.

DNS Amplifikasyon atak şu şekilde çalışır. İlk olarak bir public bir DNS sunucu tespit edilir. Bu DNS sunucuya sürekli olarak DNS istekleri gönderilir. Ancak gönderilen DNS istek paketlerinin kaynak IP adresi sorguyu atan kaynak değilde hedef alınan sistemlerdir. Sonuç olarak istekler DNS sunuya gönderilir ancak DNS sunucu yanıtları hedefe gönderecektir. Aynı anda atılan 1000 sorgu 100000x24 byte = 2400000 byte lık bir trafik oluşturuyor. DNS sunucu bu sorgulara ise 100000x150=15000000 byte’lı bir yanıt üreterek paket kaynak IP Adresine yönlendiriyor. Hedef alınan sitem için üretilen trafik bant genişliği olarak değerlendirilirse 8x150=120000 Kbps bir trafikten bahsedilebilir.Bu da 120 Mbps bir trafiktir. Aynı anda 100000 sorgu sürekli devam ederse  orta ölçekli çoğu şirkette hizmet kesintisi yaşanabileceği sonucunu çıkarabiliriz.

27 Ekim saldırıları da bu şekilde gerçekleştirilmiştir. X Bankası dışında diğer bankalar hedef alınan değil yükseltilmenin(zıplamamnın) gerçekleşmesi için kullanılmıştır. Diğer bankaların (Y Bankasının da dahil olduğu diğer bankalar) DNS Sunucuları kullanılarak, bu sunucular üzerinden asıl hedef olan X Bankasına saldırı gerçekleşmiştir.. Ancak gelen istekler o kadar yüksektir ki asıl hedef olan X Bankası dışındaki bankaların bant genişliği ve DNS sunucu servisleri olumsuz etkilemiştir.

Y Bankasının Bilgi Güvenliği olay yönetim aşamaları ile saldırıyı ele alacak olursak,

Olay Tespiti: Nöbetçi izleme ekibi Servis sağlayıcıdan alınan DDOS hizmeti sebebiyle otomatik alarm maili üzerine Y Bankası IT Güvenlik ekiplerine bilgi vermiştir. SIEM’i log kayıtları olarak besleyen Yük Dengeleyicinin (Load Balancer) üretmiş olduğu loglar kabul edilen eşik değer üstü olması sebebiyle SIEM ürünü tarafından da tespit yapılmıştır. Çift kontrol sonucu olay tespiti kesinleşmiştir. DDoS atak yaşanmaktadır.

Olay Tespiti sonrası hedef sistem tespiti için loglar ayrıntılı olarak incelenmiştir. DNS sunucuya yapılan çok fazla istek söz konusu ve bu istekleri sebebi ile DNS Sunucunun kullanmış olduğu altyapılarda yoğunluk söz konusudur.

DNS Sunucu sebebiyle birden fazla sistem etkilenmekte ve DNS Sunucu legal isteklere de zaman zaman yanıt verememektedir.

Olay Yanıtı: Servis sağlayıcıya bilgi verilmiş ve bilgi talep edilmiştir. IT Güvenlik ekibinin kararı doğrultusunda DNS sunucu IP adreslerinin koruma eşik değer azaltımı için Servis Sağlayıcıdan sağlanan DDOS hizmeti için konfigürasyon yapılmasını istenmiştir.

Gelen isteklerin yurtdışı kaynaklı olması sebebiyle yurtdışı ağ trafiği yük dengeleyici üzerinde engellenmiştir ve servis sağlayıcıya ikinci konfigürasyon talebi olarak da iletilmiştir.

Yük dengeleyici üzerinde session limit ayarları daha da düşürülmüştür. Bu olay yanıtları sonrası sistem normale dönmüştür.

Olay Analizi: Olay analizi sırasında saldırının kök nedeni tespit edilmiştir. Y Bankası üzerinden hedef alınan bir başka banka asıl hedeftir. Bu tespit DNS paket kaynak IP adreslerinin bir bloğa ait olması üzerine yapılan araştırma sonucu yapılmıştır. Hızlıca Y Kurumu güvenlik duvarlarında politika tanımlanmıştır: "Kaynak ve hedef IP adresi hedef alınan banka bloklarına ait ise engelle" 

Olay Raporlama: Yaşanan olay sonrası küçük kesintilerin olması ve başka kurumu hedeflemesi sebebiyle birden fazla raporlama yapılmıştır. İlk olarak kurum içi olay raporu tutulmuştur. 

Ancak hedef alınan başka bir sistem olması sebebiyle X Bankası güvenlik ekiplerine bilgi verilmiştir. X Bankası konunun bilgisi dahilinde olduğunu belirtmiştir.

Y Bankasının bağlı olduğu yasal otoritelere (BDDK vb.) rapor hazırlanarak paylaşılmıştır. 

İyileştirme: Kurum bünyesinde lokal olarak konumlandırılmış bir DDOS koruma ürünü olmaması sebebiyle bu konuda bir risk değerlendirme çalışması yapılmıştır. Değerlendirme sonucunda grup şirketleri dış altyapı sistemlerinin birleştirilmesi kararı ve ortak bir koruma cihazı ile korunması amaçlanmıştır.

Y Bankası Olay yönetim prosedüründe yer alan, yaşanan bilgi güvenlik olaylarına göre yanıtları ile ilgili kısım aşağıdaki gibidir.

DDOS atak aksiyonları:

a-) Atağın gerçekleştiği sistem tespit edilmelidir.

b-) Atağın banka üzerinden başka bir kurumu hedef alıp almadığı tespit edilmelidir.

c-) Başka kurumu hedef alan bir atak ise, hedef alınan kuruma ait IP adreslerine erişimin engellenmesi için kural yazılmalıdır.

d-) Atağın başka bir kuruma ait IP adres/adreslerinden geldiği gözlemlenirse ilgili kurum IP adresleri engellenmeli ve kuruma bilgi verilerek önlem alması sağlanmalıdır. Bu durum yükseltme(Amplification) ataklarda söz konusudur.

e-) Web servislerini hedef alan bir atak ise hizmet alınan servis sağlayıcıya bilgi verilerek sistem eşik değerleri düşürülmelidir.

f-) Web servislerini hedef alan atak için servis sağlayıcının sistem eşik değer düşürmesi sonrası atak kesintiye sebebiyet vermeye devam ediyorsa, banka atak koruma sistemlerinin de eşik değerleri düşürülmelidir.

f-) Bant genişliğini hedef alan bir atak ise servis sağlayıcıya bilgi verilerek eşik değerleri düşürmesi sağlanmalıdır.

g-) Yurtdışı kaynaklı ve engellenemeyen bir atak ile karşı kaşıya kalındığı durumda servis sağlayıcıdan yurtdışı erişimlerini engellemesi için kural yazılması talep edilmelidir.

h-) Banka içerisinden dış bir hedefe doğru gerçekleştirilen atak tespiti yapılması durumunda atağı gerçekleştiren (zombie) makine tespiti yapılarak karantinaya alınmalıdır. Daha sonra Bilgi Güvenliği ekibi ilgili sistem analiz işlemlerini gerçekleştirmelidir.

ı-)  Yukarıdaki tespitlerin tek ya da az sayıda IP adres kaynağından gerçekleştiği tespit edilirse bu kaynaklar için servis sağlayıcı ve banka koruma sistemlerinde engelleyici kural tanımı yapılmalıdır.