Qradar - Port Taramaların Tespiti - Dinamik IP Liste Kullanılarak Firewall'da Engellenmesi

Merhaba Arkadaşlar,

Bu yazımızda ilk olarak, Qradar'ın WAN'da konumlandırılmış Firewallardan almış olduğu logları kullanarak port taramalarını tespit edeceğiz. Daha sonra dış IP Adreslerimizde tarama gerçekleştiren bu kaynak IP Adreslerini Qradar'da bir referans tablosuna yazacağız. Referans tablosundaki IP Adresleri potansiyel saldırganlar olduğu için bunları API ile bir text dosyasına yazacağız. Bu text sayfasını bir IIS sunucuda host edeceğiz. Son olarak da kullanmış olduğumuz Firewallda bu text i engellenmesi için Dinamik IP Adresi olarak tanımlayacağız. 

İlk aşama olarak tespit ettiğimiz port taraması gerçekleştiren kaynak IP Adreslerini Qradar'da bir reference tablosuna yazmalıyız. Bu tabloyu oluşturmak için Qradar'da 

1-Admin > 2-Reference Set Management > 3-Add

Resim-1 (Admin)

Resim-2 (Reference Set Management)

Resim-3 (Add)

Görsellerdeki aşamaları uygulayarak, Qradar'da "Port_Scan_IP" isminde bir reference set oluşturduk.

İkinci aşamamız olan Port Taramalarının tespiti ile devam edelim. Port taraması için öncelikle bir AQL tanımladık. AQL sorgumuzun döndüğü sonucu görmek için Resim-4 ' e tıklayabilirsiniz.

Resim-4 (AQL Araması)

AQL sorgu açıklamaları:

( logsourcename(logsourceid)='--Series -------'  kaynakları kısıtlayarak sadece belirli kaynaklar olan Firewallar için sorguyu çalıştırır.

 

NOT INCIDR('10.0.0.0/8',sourceip) ise kaynak IP Adresi private IP Adresi ise hesaba katma demektir.

group by sourceip,destinationip,destinationport 

group by sourceip,destinationip,destinationport ise bir kaynaktan bir hedefe bir port için birden fazla istek olsa da bunları tekilleştirir.

AQL sorgusu:

( logsourcename(logsourceid)='--Series -------' or 

logsourcename(logsourceid)='--Series ------' ) and 

( NOT INCIDR('10.0.0.0/8',sourceip) and NOT INCIDR('172.16.0.0/12',sourceip) and

NOT INCIDR('192.168.0.0/16',sourceip) ) 

group by sourceip,destinationip,destinationport

Port Taramalarının tespiti için tek başına bu sorgumuz yeterli değildir. Bu sorgumuzu başka bir sorgu ile "AND" işlemine tabi tutmamız gerekiyor. Peki bahsetmiş olduğumuz bu diğer sorgu nasıl olmalıdır ? Aynı Kaynak IP adresinden, Aynı Hedef IP Adrese farklı portlar için geliyorsa, her istek yapılan farklı portları 10 dakika içerisinde say. 10 dakika içerisinde aynı Kaynak IP Adresinden, aynı Hedef IP Adresine 10 dakika içinde 10'dan fazla farklı port için istek gelirse bu bir port taraması şeklinde kabul edeceğiz. Bu değerleri istediğiniz gibi değiştirebilirsiniz. 

Şimdi Qradar üzerinden iki farklı sorgunun AND işlemine tabi tutulmasını gerçekleştirelim. Aşağıdaki gösterilen sıra ile Qradar GUI'sinden kuralı tanımlayabiliriz. 6.Adım ve sonrası için görsel paylaşmak yeterli olacaktır.

1-Offenses > 2-Rules > 3-Action > 4-New Event Rule > 5-Events > 

6-RuleWizard: Rule Test Stack Editor

6. adımda 2 farklı sorgu girişimizi yapabileceğimiz kısım karşımıza çıkıyor. (Resim-5)

Resim-5 (6-RuleWizard: Rule Test Stack Editor)

Rule Test Stack Editor Ekranından filter ile 2 farklı sorgumuzu ekleyeceğiz. İlk olarak AQL sorgusunun eklenebilmesi için Filter kısmına "AQL" keyword ü ile "when the event matches AQL filter query" filterini ekleyebiliriz. Daha sonra yukarıdaki AQL sorgumuzu buraya ekleyerek dış IP Adreslerimize yapılan isteklerin tespitini sağlayabiliriz. ( Resim-6 )

AQL sorgumuzu AND işlemine sokacağımız diğer sorgu için "events are seen with the same" keyword ü ile filterda arama yaparak ekleyebiliriz. Aynı Kaynak IP Adresinden aynı hedef IP Adresine 10 farklı port için 10 dakikada gönderilen istek sayısı 10 u geçerse şeklinde 2.sorumuzu düzenleyebiliriz.  (Resim-6)

Resim-6 (Sorguların Eklenmesi)

Üçüncü aşamamız ise 2 sorgunun beraber çalıştığında ürettiği sonuçları bir reference tablosuna göndermek olacaktır. Rule Wizard'da bir kez daha "next" e tıklayarak devam edebiliriz. 

Add to a Reference Set i işaretledikten sonra ilk aşamada oluşturmuş olduğumuz Reference Set olan Port_Scan_IP'yi seçebiliriz. gösterebiliriz. Burada tarama tespit edildiğinde mail gönderilmesini isterseniz Email i de işaretleyebilirsiniz. (Resim-7)

Resim-7 (Reference Set Enable)

Bir süre sonra portlarımızı tarayan IP Adreslerinin Reference tablomuzda oluştuğunu görebiliriz. (Resim-8)

Resim-8 (Port_Scan_IP)

Dördüncü aşamamız olan Reference tablosundaki verilerin API ile çekilerek bir text dosyasına yazma adımlarını gerçekleştirebiliriz.

Burada öncelikle "Interactive API for Developers" tabını kullanarak, oluşturduğumuz reference set e istekte bulunarak port taraması gerçekleştiren IP adreslerini çekmeyi deneyeceğiz. (Resim-9)

Resim-9 (Interactive API for Developers)

Açılan sayfada soldaki sekmeden reference_data > sets > {name} kısmını açmamız gerek. (Resim-10)

Resim-10

Şu anda get request ile "Port_Scan_IP" reference tablosunu çekeceğimiz URL ve Headerları elde edeceğiz. Daha sonra bu URL ve Headerları Qradar API'sine erişmek için geliştireceğimiz python kodunda kullanacağız. Parametresi "name" olan kısım için "Value" olarak reference tablo ismimiz olan Port_Scan_IP'yi girebiliriz. (Resim-11) 

Resim-11 (Value=Port_Scan_IP)

Try it out! a tıkladıktan sonra Port taraması sonucu reference tablomuza eklenen IP adreslerini "Response Body" kısmında görebilirsiniz. Request URI istek yapacağımız URI ve Request Header ise istek yaparken ekleyecek olduğumuz header ları göstermektedir.(Resim-12)

Resim-12 (Request Headers / URI)

Python "request" package ' i kullanılarak isteğimizi yapacağımız bir koda ihtiyacımız bulunmaktadır. (Kullanacağınız dili özgürce seçebilirsiniz.) "headers" ları Dictionary olarak oluşturduktan sonra isteğimize ekleyebiliriz. "auth" ile Qradar'a login olduğumuz username password girişlerini yapabiliriz.

verify=False diyerek de sertifika trust check i disable ettik. Public ortamlardaki kullanımda asla "False" a çekilmemelidir. Aşağıdaki kod ile Qradar API'si ile haberleşerek Reference tablosunu çekebiliriz.

import requests

import re

headers = {

    'Range': 'items=0-100000',

    'Version': '12.0',

    'Accept': 'application/json',

}

response = requests.get('https://qradar/api/reference_data/sets/Port_Scan_IP', headers=headers, auth=('username', 'password'), verify=False)

Beşinci aşamamız olarak Qradar'dan fetch ettiğimiz reference tablo datasını host etmeyi konuşacağız. Bunun için ilk olarak IIS Sunucumuzu aktif hale getirelim. Aşağıda eklemiş olduğum resimdeki adımları sırasıyla uygulayarak IIS Sunucuyu enable edebilirsiniz. Internetten kolayca bulabileceğiniz adımlardır. 

Resim-13 (IIS Kurulumu 1.Adım)

Resim-14 (IIS Kurulumu 2.Adım)

Resim-15 (IIS Kurulumu 3.Adım)

Resim-16 (IIS Kurulumu 4.Adım)

Resim-17 (IIS Kurulumu 5.Adım)

Resim-18 (IIS Kurulumu 6.Adım)

Resim-19 (IIS Kurulumu 7.Adım)

Resim-20 (IIS Kurulumu 8.Adım)

Resim-21 (IIS Kurulumu 9.Adım)

Resim-22 (IIS Kurulumu 10.Adım)

Önce IIS sunucu yönetim arayüzüne erişelim daha sonra da Sites tabında gerekli düzenlemeleri yapalım. Öncelikle IIS ' de host edilecek alanı gösterelim. Bunun için ilk olarak "Default Web Site" ı silebiliriz.(Resim-24)

Resim-23 (IIS Arayüz)

"Default Web Site" silindikten sonra ise host edeceğimiz text dosyasını ekleyebiliriz. Add Website diyerek ilgili işlemi yapabiliriz. (Resim-24 / Resim-25)

Resim-24

Resim-25

C:/WEB klasörüne yükleyeceğimiz bir text IIS tarafından host edilecektir. Bu sebepten üstte yazığımızı kodu biraz daha geliştirmemiz gerekecektir. Qradar çekmiş olduğumuz dataları önce bir text file a yazacağız daha sonra bu text file ı Palo Alto Firewall un anlayabileceği formata çevireceğiz ve C:/WEB klasörüne taşıyacağız. Bu işlemi sağlayan kullanabileceğimiz Python kodumuz aşağıdaki gibidir. 

import requests

import re

import time

headers = {

    'Range': 'items=0-100000',

    'Version': '12.0',

    'Accept': 'application/json',

}

x=0

while True:

    x=x+1

    print("Dongu %s" %x)

    time.sleep(43200)

    response = requests.get('https://qradar/api/reference_data/sets/Port_Scan_IP', headers=headers, auth=('username', 'password'), verify=False)

    abc=response.text

    cde=re.findall("value\":\"([0-9.]+[0-9.]+[0-9.]+[0-9.]+)", abc)

    print(cde)

    with open('response5.txt', 'w') as f:

        print(cde, file=f)

    with open('response5.txt', 'r') as infile, open('C:\WEB\index.txt', 'w') as outfile:

        data = infile.read()

        data = data.replace("[", "")

        data = data.replace("]", "")

        data = data.replace("'", "")

        data = data.replace(",", "/32\n")

        data = data.replace(" ", "")

        outfile.write(data)

Yukarıdaki script bir döngüye sokularak yarım günde bir çalışacak hale getirildi. Yani günde 2 kere Qradar ile haberleşerek dinamik listemizi güncelliyor. Bunu dilediğiniz gibi ayarlayabilirisiniz. 

Artık Firewall tarafından kullanılabilecek dinamik listemiz hazır durumda. 

http://IPAdresi/index.txt ile dinamik listemize erişebiliriz.

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.