İnternet kavramını ve altyapısını oluşturan bileşenler ağ cihazlarıdır. Her geçen gün farklı roller ve kategorilerle kullanmaya devam ettiğimiz ağ cihazları olmasaydı internetten bahsetmek mümkün olmazdı. Geçmişte bir ağ iletişimi, hub, switch, router gibi cihazlardan geçerek hedefine ulaşırken, günümüzde farklı görevlere sahip birçok cihaz (Firewall, IPS/IDS, Proxy, WAF gibi) farklı özelliklerle devreye giriyor. görevler ve yetenekler.
Genel Günlük Analizi (Netflow)
Netflow, IP trafik bilgilerini toplayan bir ağ protokolüdür. Cisco tarafından geliştirilmiş olmasına rağmen farklı üreticilerin Netflow’unu desteklemektedir. Bazı üreticiler Sflow veya farklı benzer protokolleri destekler. Markası veya protokolün geliştiricisi ne olursa olsun bu protokol ile ağ üzerinde görünürlük sağlaması önemlidir.
Bu görünürlük sayesinde;
– İSS’ler hizmetler için fatura kesebilir
– Ağ tasarımında veya analizinde kullanılır
– Ağ izleme amacıyla kullanılır. (En fazla trafiği oluşturan kaynaklar, en çok kullanılan port bilgileri vb.)
– Hizmet kalitesi ölçülebilir
– Anormalliklerin tespiti için SOC analistlerine bilgi sağlar.
Netflow, stateful bir yapıda çalışır ve izlenen arayüz üzerinden geçen tüm IP trafiğini izler ve raporlar. Buradaki her IP iletişimi bir akış olarak tanımlanır. Akış, kaynak ve hedef arasındaki iletişimi oluşturan paketler kümesidir. Akışın oluşumu için toplanan bilgiler aşağıdaki gibidir;
– Kaynak IP Adresi
– Hedef IP Adresi
– Kaynak Portu (Sadece UDP ve TCP protokolleri için)
– Hedef Port (Sadece UDP ve TCP protokolleri için)
– IP Protokolü
– Arayüz Bilgileri
– IP Versiyon Bilgisi
Örnek bir NetFlow çıktısı;
NOT: NetFlow verisi üreten cihazlar genellikle bu veriyi metin olarak okunaklı formatta üretmezler. Aşağıdaki çıktı bu verileri okuyabileceğimiz bir formata dönüştüren uygulamalardan alınmıştır.
NetFlow verileri oluşturmak için, ağdaki desteklenen yönlendiriciler veya anahtarlar üzerinde NetFlow ayarları yapılandırılır. Bu yapılandırmalar ana bilgisayarın komut satırı veya web arayüzü üzerinden yapılabilir. Hostlar bu verileri “Netflow Collector” veya “Netflow Analizörü” gibi ağ cihazlarına iletirler. Bunlar gelen NetFlow verilerini işleyecek ve yeteneklerine göre arayüzlerindeki verileri görselleştirerek rapor haline getirecekler.
NetFlow çıkışları aracılığıyla şunları tespit edebiliriz:
– Anormal trafik hacmi artar
– Veri sızıntıları
– Özel sistemlere erişim
– Ağdaki yeni IP’ler
– İlk kez erişilen sistemler ve ilgili konuların analizi
Güvenlik Duvarı Günlük Analizi
Güvenlik duvarları, ağın siber politikalarına bağlı olarak oluşturulan kurallara göre ağ üzerinde gelen ve giden paketleri kontrol eden fiziksel veya sanal cihazlardır. Büyük organizasyonlarda her sistemin/sunucunun kendine ait güvenlik duvarı uygulaması olabileceği gibi, ağın merkezi yönetimi için halka açık bir güvenlik duvarı cihazı da yerleştirilebilir. Bu sayede ağ iletişimi öncelikle güvenlik duvarından geçer ve güvenlik duvarı kurulumunda belirlenen kurallara göre hedefine ulaşır.
Bu anlamda güvenlik duvarları kuruluşlarda ağ erişimini kontrol ettiği için en önemli güvenlik bileşenlerinden biridir. Bu nedenle SOC Analistinin güvenlik duvarı cihazlarının ürettiği logları analiz edebilmesi son derece önemlidir.
Günümüz güvenlik duvarı cihazları, geçmişe göre sadece belirlenen kurallara göre paketlerin nereye gideceğine (OSI Layer-3) karar vermekle kalmıyor, aynı zamanda ek modülleri sayesinde farklı görevleri de üstleniyor. Örneğin uygulamaları ve içeriklerini tanıyabilir (OSI Layer-7). Yani uygulama katmanında iletişimi hangi uygulamanın (http, https, ssh, dns vb.) yaptığını tanıyan güvenlik duvarları NGFW (Yeni Nesil Güvenlik Duvarı) olarak tanımlanır. Güvenlik duvarı günlüklerinde, uygulamalarda ve hizmetlerde vb. bahsedilen uygulama adları, bu güvenlik duvarını NGFW olarak tanımlar. Bir uygulamayı tanıması, güvenlik duvarında kural yazarken uygulama tabanlı kurallar da yazılmasına olanak sağlar. Bu aslında, giden ssh erişimini yasaklamak için yalnızca hedef bağlantı noktası 22 ile paketleri engellemenin, ssh trafiğinin tamamen engellendiği anlamına gelmediği anlamına gelir. Hedef uygulama, hedef port 22 yerine SSH olarak tanımlandığında, güvenlik duvarı onu uygulama katmanında tanıyacak ve ssh iletişiminin gerçekleştirdiği porttan bağımsız olarak ssh erişimini engelleyecektir.
En önemli güvenlik duvarı logları cihaz üzerinden geçen trafiğin loglarıdır. Temel olarak bu günlük bize trafik süresini, kaynak IP/Port bilgisini, hedef IP/Port bilgisini, arayüz bilgisini, konum bilgisini vb. sağlar.
Örnek bir güvenlik duvarı trafik günlüğü
date=2022-05-21 time=14:06:38 devname=”FG500″ devid=”FG5HSTF109K” eventtime=1653131198230012501 tz=”+0300″ logid=”0000000013″ type=”traffic” subtype=”forward” level=”notice” vd=”root” srcip=172.14.14.26 srcname=”CNL” srcport=50495 srcintf=”ACC-LAN” srcintfrole=”lan” dstip=142.250.186.142 dstport=443 dstintf=”Wan” dstintfrole=”wan” srccountry=”Reserved” dstcountry=”United States” sessionid=445180938 proto=6 action=”accept” policyid=284 policytype=”policy” poluuid=”8ec32778-a70a-51ec-9265-8fdf896d07f1″ service=”HTTPS” trandisp=”snat” transip=89.145.185.195 transport=50495 duration=72 sentbyte=2518 rcvdbyte=49503 sentpkt=13 rcvdpkt=42
Yukarıdaki günlüğün ayrıntılarına bakıldığında
date= Tarih
time= Zaman
devname=Ana bilgisayar adı
devid= Cihaz Kimliği
eventtime= 1653131198230012501
tz= saat dilimi
logid= Günlük Kimliği
type= Günlük Türü (trafik, utm, etkinlik vb.)
subtype=Alt Günlük Türü (İletme, vpn, web filtresi, virüs, ips, sistem vb.)
level= günlük seviyesi
srcip= Kaynak IP Adresi
srcname= Kaynak Ana Bilgisayar Adı
srcport= Kaynak Bağlantı Noktası
srcintf= Kaynak Arayüzü Adı
srcintfrole= Kaynak Arayüzü’nün Rolü
dstip= Hedef IP Adresi
dstport= Hedef Bağlantı Noktası
dstintf= Hedef Arayüzün Adı
dstintfrole= Hedef Arayüzün Rolü
srccountry= Kaynak IP bilgisi (Ülke)
dstcountry= Hedef IP bilgisi (Ülke)
action= gerçekleştirilen eyleme ilişkin bilgi (bırakma, reddetme, kabul etme vb.)
service=hizmet bilgisi
transip= NAT IP bilgisi (özel kaynak adresinin dahili çıkışı)
transport= NAT bağlantı noktası bilgisi
duration= geçen süre
sentbyte= gönderilen paketlerin boyutu (bayt)
rcvdbyte= alınan paketlerin boyutu (bayt)
sentpkt= gönderilen paketlerin sayısı
rcvdpkt= alınan paketlerin sayısı
Log analizi yaparken ilk kontrol etmemiz gereken şey IP ve port bilgileridir. IP ve port bilgilerini aldıktan sonra “action” kısmından bu trafiğin hedefe ulaşıp ulaşmadığını kontrol etmeliyiz. Başka bir deyişle, güvenlik duvarı günlüğü bize trafiğin kaynağı, hedefi ve hangi portta gerçekleştirildiği hakkında bilgi sağlayacaktır.
Eylem olarak;
– accept: paketin başarıyla geçtiğini gösterir.
– deny: paket iletimi engellenir, bilgi engellendiği IP adresine geri gönderilir.
– drop: paket iletimi engellenir. Engellenen IP adresine herhangi bir bilgi geri dönmez.
– close: iletişimin karşılıklı olarak sonlandırıldığını belirtir.
– client-rst: iletişimin istemci tarafından sonlandırıldığını gösterir.
– server-rst: iletişimin sunucu tarafından sonlandırıldığını gösterir.
Örneğin, güvenlik duvarı kayıtlarını kontrol ederek, incelemeniz için tarafınıza iletilen bir IP adresi ile ağ iletişiminin kurulup kurulmadığına dair bilgilere ulaşabileceksiniz. Bulgularınızı kaynak ve hedef IP adreslerine göre filtrelemeniz arama yapmanızı kolaylaştıracaktır. Güvenlik duvarı günlükleri, SOC Analistinin olayları, vakaları, şüpheli etkinlikleri araştırırken başvurabileceği en önemli kaynaklardan biridir. Örneğin aşağıdaki gibi detayları bulmanız çok önemli olacaktır:
– Güvenlik duvarı loglarında IPS tarafından saldırıda bulunduğu tespit edilen ve reddedilen IP adresinden farklı zamanlarda kabul isteği geliyor mu?
– Güvenlik duvarı loglarını kontrol ederek, antivirüs loglarındaki kötü amaçlı içeriklerin analizi sonucu elde edilen şüpheli IP/Alanlara erişim olup olmadığını tespit edebileceksiniz.
– Güvenlik duvarı trafik günlükleri, virüslü bir sistemin ağ içinde hangi farklı sistemlerle iletişim kurduğunu tespit etmek için de iyi kaynaklardır.
Güvenlik duvarı günlükleri aracılığıyla aşağıdaki gibi şüpheli etkinlikler gerçekleşir:
– Port Tarama aktiviteleri
– IoC’lerle iletişim tespiti
– Yanal (lan-lan) veya dikey (lan-wan, wan-lan) yetkisiz erişimler tespit edilebilir
VPN Günlük Analizi
VPN, fiziksel olarak bağlı olmadığınız bir yerel ağa bağlanmanızı sağlayan teknolojidir. Genellikle kuruluşlar iç sistemlerine uzaktan erişim sağlamak için bu teknolojiyi tercih etmektedir. Günümüzde erişilemeyen sitelere erişim sağlayan bir teknoloji olarak bilinmektedir. Buradaki mantık şu şekilde işliyor; normalde bulunduğunuz konumdan erişemediğiniz sitelere, konumunuzu farklı bir konuma geçirerek (internete sanki oradaymış gibi bağlanarak) erişebilirsiniz.
Kurumsal ağlar için VPN teknolojisi vazgeçilmez bir erişim türüdür. Bu nedenle VPN logları SOC Analistlerinin günlük rutini için çok önemlidir. VPN halka açık hizmetlerden biri olduğu için saldırganların giriş noktası haline geliyor. VPN loglarında yer alan zaman bilgisi, kaynak IP bilgisi, kullanıcı bilgisi gibi veriler, olay/alarmları araştırırken analistlerin en faydalı bilgileri arasında yer almaktadır.
VPN’ler genellikle kuruluşun mevcut Güvenlik Duvarı (VPN’i destekleyen güvenlik duvarı) üzerinden kullanılır. Ayrıca bazı ağlarda sadece VPN’lere özel hizmet veren ürünleri de görmek mümkün. Özetle VPN logları Firewall cihazlarından alınabileceği gibi sadece VPN hizmeti veren cihazlardan da alınabilmektedir.
Örnek bir VPN logu
date=2022-05-21 time=14:06:38 devname=”FG500″ devid=”FG5HSTF109K” eventtime=1653134913959078891 tz=”+0300″ logid=”0101039424″ type=”event” subtype=”vpn” level=”information” vd=”root” logdesc=”SSL VPN tunnel up” action=”tunnel-up” tunneltype=”ssl-web” tunnelid=462105151 remip=13.29.5.4 user=”letsdefend-user” reason=”login successfully” msg=”SSL tunnel established”
Yukarıdaki günlüğün ayrıntılarını incelediğimizde
date= Date
time= Time
devname= Hostname
devid= Device ID
eventtime= 1653131198230012501
tz= time zone
logid= Log ID
type= Log Type (traffic, utm, event, etc.)
subtype=Sub Log Type (Forward, vpn, webfilter, virus, ips, system, etc.)
level= log level
logdesc= log description
action= action taken
tunneltype= VPN tunnel type
remip= IP address that established the VPN connection
user= User information
reason= VPN Connection Request Result
msg= Message (Detailed message after the access)
VPN logunda incelenmesi gereken en önemli bilgi bağlantıyı yapan IP adresi, hangi kullanıcıya bağlandığı ve bu erişim isteğinin sonucu (başarılı-başarısız durumu). Verilen örnek günlük, güvenlik duvarında ek modül olarak çalışan VPN hizmetinin günlüğüdür. Bu nedenle tür “event”, alt tür ise “vpn” olarak listelenmiştir. Başarılı bir VPN bağlantısının ardından, VPN sistemi üzerinden erişiminiz için size bir IP atanır. Atanan IP bilgilerinin log’u aynı log kaydında veya farklı bir log’da gönderilebilir. Yukarıdaki örnek logdaki bilgilere ek olarak başarılı VPN bağlantısı sonrasında diğer logda size atanan IP bilgisini “tunnelip” değeri ile de görebilirsiniz.
Yukarıdaki örnek vpn logunu incelediğimizde VPN isteğini yapan IP adresinin 13.29.5.4 olması, kullanıcı adının “letsdefend-user” olması ve cihazın ürettiği mesaj ile başarılı bir VPN erişiminin kurulduğunu tespit edebiliriz. VPN etkinliğine ait olan “başarıyla giriş yapın”.
Bundan sonra VPN üzerinden gerçekleştirilen ağ faaliyetlerinde kaynak IP adresi olarak size atanan “tunnelip”te belirtilen IP adresi ile güvenlik duvarı trafik loglarınız oluşturulacaktır.
Örneğin SOC Analistlerinin aşağıdaki gibi bir senaryo ile karşı karşıya kaldıklarında VPN loglarını analiz etmeleri beklenmektedir.
Senaryo: Kuruluşu hedef alan bir phishing e-postası sonrasında kuruluştaki bazı kullanıcıların bu e-postayı açarak kullanıcı adı ve şifre bilgilerini girdiği tespit edilmiştir. Bu kullanıcılar için, bu kullanıcıların tüm hizmetlerdeki, özellikle de halka açık hesaplardaki (örn. VPN) tüm faaliyetlerini kontrol etmek gerekir. İlgili kullanıcıların VPN logları analiz edilmelidir. Başarılı erişim kaynağı IP ve ülke bilgisi ve bu başarılı erişimlerin gerçekten kullanıcı tarafından yapılıp yapılmadığı ayrıca araştırılmalıdır.
VPN günlükleri aracılığıyla aşağıdaki şüpheli etkinlikler tespit edilebilir:
– Başarılı/Başarısız VPN erişimleri
– VPN hesaplarına yönelik kaba kuvvet saldırılarının tespiti
– Belirtilen ülkeler dışındaki VPN erişimlerinin tespiti
– Belirtilen zaman dilimleri dışındaki VPN erişimlerinin tespiti
Yukarıda logunu incelediğimiz başarılı VPN bağlantısı için aynı cihazdaki trafik logu aşağıdaki gibidir. (Birden fazla kayıt var, örnek olarak sadece 1 tanesi eklenmiştir.) Log’da görüldüğü gibi trafik/bağlantı güvenlik duvarı tarafında gerçekleştiği için güvenlik duvarı VPN erişimi yapılmadan önce öncelikle bu trafiğin logunu oluşturur. Bu logdaki srcip ile VPN logdaki remip değerlerinin aynı olduğunu görebilirsiniz . Trafik logunda yer alan uygulama (hizmet) bilgilerinin HTTPS olması kullanılan VPN tipinin SSL-VPN olmasından kaynaklanmaktadır.
Proxy Log Analysis
Proxy Günlük Analizi
Proxy temel olarak uç nokta ile internet arasında bir köprü görevi görür. Kuruluşlar proxy teknolojisini genel olarak internet hızı, merkezi kontrol ve güvenlik düzeyinin artırılması gibi amaçlarla kullanmaktadır. Proxy yapısının basit şematik çizimi aşağıda paylaşılmıştır. İstemci tarafından yapılan istekler önce Proxy Sunucuya, ardından İnternet’e ulaşır. Proxy’ler temel olarak 2 farklı türde çalışabilir:
Transparent Proxy: Eriştiğimiz hedef sunucu, gerçek kaynak IP adresini görebilir.
Anonymous Proxy: Eriştiğimiz hedef sunucu gerçek kaynak IP adresini göremez. Proxy’nin IP adresini kaynak IP adresi olarak görür. Böylece arka planda gerçekte isteği yapan sistem hakkında herhangi bir bilgi elde edemez.
Cisco Umbrella, Forcepoint Web Security Gateway, Check Point URL Filtering ve Fortinet Secure Web Gateway ürünleri piyasada iyi bilinen proxy çözümlerine örnektir.
Proxy çalışma yapısı, sistemlerin (sunucu, istemci vb.) HTTP, HTTPS, FTP gibi servislere erişimini belirlenen politikalara göre kontrol eder ve politikalara göre alınan aksiyonları bloklama veya geçme işlemleri olarak çalıştırır. Bu politikalar proxy yeteneklerine göre değişiklik gösterse de temel olarak kategori veri tabanından erişilecek URL/domain’i sorgular ve kategori riskli bir kategori ise engelleme işlemi uygulanır, aksi takdirde geçiş işlemi uygulanır. Bazı sistemlerin belirli ağlar dışında herhangi bir ağa erişmesine gerek olmadığından, erişilmesi gereken ağlar dışındaki tüm ağlara örtülü reddetme uygulanabilmektedir.
A sample proxy log:
date=2022-05-21 time=16:15:44 type=”utm” subtype=”webfilter” eventtype=”urlfilter” level=”warning” srcip=192.168.209.142 srcport=34280 srcintfrole=”lan” dstip=54.20.21.189 dstport=443 dstintfrole=”wan” service=”HTTPS” hostname=”android.prod.cloud.netflix.com” profile=”Wifi-Guest” action=”blocked” url=”https://android.prod.cloud.netflix.com/” sentbyte=517 rcvdbyte=0 direction=”outgoing” urlsource=”Local URLfilter Block” msg=”URL was blocked because it is in the URL filter list”
When we review the above log;
date= date information
time= time information
type= log type
subtype= log sub type (values like forward, vpn, webfilter, virus, ips, system etc.)
eventtype= event type that belongs to the sub type
level= incident severity level
srcip= source IP address
srcport= source port information
srcinfrole= source interface information
dstip= destination IP address
dstport= destination port information
dstinfrole= destination interface information
service= service information
hostname= requested domain
profile= source profile
action= action information
url= URL address requested
sentbyte = size of data sent by bytes
rcvdbyte= size of data received by bytes
direction= direction of the traffic
urlsource= URL sources
msg= message information
Logu incelediğimizde 192.168.1.1 IP adresi ile sistemin “https[:]//android[.]prod[.]cloud[.]netflix.com/” adresine erişimin engellendiğini görüyoruz. İlgili profile uygulanan politika nedeniyle “Wifi_Guest” grubunda 209.142. Bu isteğin engellenmesinin nedeni, erişilecek URL’nin “Yerel URLfiltre Engelleme” listesinde yer alması ve bu listedeki URL’lere erişimin engellenmesidir.
Proxy günlükleri, bir SOC analistinin bir sistemin (sunucu, istemci vb.) hangi etki alanı/URL’sinin iç sistemlerimize istekte bulunduğunu ve başarılı bir bağlantı kurup kuramadığını kontrol etmesi gerektiğinde en önemli günlük türlerinden biridir. Ayrıca alan adının/URL’nin riskli bir kategori olup olmadığının ve daha önce başarılı bir bağlantı kurulup kurulmadığının tespit edilebilmesi de önemlidir.
– Proxy günlüklerini inceleyerek aşağıdaki şüpheli etkinlikleri tespit edebiliriz:
– Şüpheli URL’lere/URL’lerden bağlantılar
– Virüslü sistem tespiti
– Tünel açma faaliyetlerinin tespiti
Örneğin aşağıdaki Forcepoint Web Security Gateway logu incelendiğinde;
17 Haz 10:47:00 10.10.18.11 CEF:0|Forcepoint|Güvenlik|8.5.4|194|İşlem engellendi|7| act=blocked app=https dvc=10.10.18.11 dst=104.26.11.18 dhost=sentry-proxy.cargox.cc dpt=443 src=10.80.18.50 spt=61603 suser=Test_User requestMethod=POST requestClientApplication=Mozilla/5.0 (Windows NT 10.0; Win64; x64) cs1Label=Policy cs1=Block_Risk_Category_Policy(Servers) request=https://sentry-proxy.cargox.cc/api/3/envelope/?sentry_key\=e2506000e29247eba06eee9df3f011e0&sentry_version\=7
Test_User kullanıcısı, 10.80.18.50 IP adresine sahip sunucusu üzerinden Mozilla tarayıcısı ile “https[:]//sentry-proxy[.]cargox[.]cc/” adresine POST isteği göndermiştir (tarafından belirlenmiştir). politikanın adı) ve hedef adres “Block_Risk_Category_Policy(Servers)” politikası olarak belirlenerek “act=blocked” aksiyonuna göre bloke edildi.
Bu logda erişilecek domain kategorisi, kategori numarası ile ifade edilir. Kategori numarası 194’tür. Bu sayıların karşılığını aşağıdaki belgeden alabilirsiniz. (Sayfa 31-36)
Kategori 194’ü incelediğimizde “194:Extended Protection Suspicious Content” şeklinde şüpheli alan adlarına ait bir kategorinin bulunduğunu öğreniyoruz.
IDS/IPS Günlük Analizi
IDS/IPS kavramı ve çözümleri, güvenlik dünyasında güvenlik duvarı cihazlarının yalnızca kural tabanlı erişim kontrollerinin yeterli olmadığı noktada geliştirilen teknolojilerdir. Kabaca, güvenlik duvarı kırmızı elmaların geçmesi, sarıların geçmemesi şeklinde kural bazında çalışırken, IDS/IPS çözümleri elmada solucan olup olmadığını kontrol edebiliyor. Yani paket içeriğini inceleyerek karar verme mekanizmasına sahiptir. Bu sayede şüpheli/kötü amaçlı paketlerin/isteklerin hedefe ulaşması engellenebilir ve sistemlerin bu saldırıdan etkilenmesi önlenebilir.
Günümüzde IDS/IPS teknolojisi birçok Güvenlik Duvarı üreticisi tarafından güvenlik duvarı cihazlarında ek modül/lisans olarak sağlansa da, yalnızca temel işlevler olarak IDS/IPS’ye sahip cihazlarda mevcuttur.
IDS ve IPS
– IPS: Saldırı Önleme Sistemi – Şüpheli faaliyetleri tespit eder ve engeller
– IDS: İzinsiz Giriş Tespit Sistemi – Yalnızca şüpheli etkinlikleri tespit eder
IDS ve IPS imza veritabanına sahiptir. İmza, bilinen saldırıları tespit etmek için tasarlanmış bir dizi kuraldır. Bu kurallar kümesini merkezi olarak sunan yapıya imza veri tabanı adı verilmektedir. Aşağıda açık kaynaklı imza veritabanı bağlantısı paylaşılmaktadır. Bu veritabanları yeni oluşan saldırı vektörlerine karşı sürekli güncellenmektedir. Bu imzaları tetikleyen ağ etkinlikleri, yalnızca imzanın belirlenen eylemine göre engellenebilir veya tespit edilebilir. Yani IDS ve IPS aynı cihaz/üründür ancak imzalardaki eyleme göre 2 farklı kavram/terim ortaya çıkmaktadır. Birçok güvenlik duvarı üreticisi, ürünlerinde IDS/IPS modülüne ek lisans sunabilmektedir. Snort veya Suricata piyasada iyi bilinen iki açık kaynaklı IDS/IPS çözümüdür.
Açık kaynak kodlu imzaların kaynağına aşağıdaki bağlantıdan ulaşabilirsiniz:
IDS/IPS sistemleri, ağ tabanlı veya ana bilgisayar tabanlı saldırıların tespiti için mevcut güvenlik araçları arasında en sık alarm üretecek kaynaklardan biridir. Saldırıların çoğu ağda veya uç noktada olduğundan, IDS/IPS sistemleri birçok şüpheli etkinliği tespit edip engelleyebilir. Organizasyonlar için hayati önem taşıyan güvenlik çözümleri olan IDS/IPS teknolojileri sayesinde log4j saldırısı, tarama sonrası aktiviteler, zafiyet istismarları, botnet aktiviteleri gibi pek çok farklı saldırı kategorisi tespit edilip önlenebilmektedir.
SOC analistleri IDS/IPS tarafından üretilen bu çıktılara genellikle SIEM veya SOAR üzerinden erişebilmektedir. SIEM, toplanan IDS/IPS alarmlarını, seviyelerine, kategorilerine ve belirli sayıda tekrarlanmalarına göre çeşitli kural/korelasyonlarla alarmlara dönüştürerek SOC Analistine sunar. Bu uyarılar bağımsız bir durum olarak veya farklı uyarılarla ilişkilendirilerek grup halinde incelenebilir (Bazı SIEM’ler de bu ilişkiyi kurabilir). Örneğin, port tarama faaliyeti sonrasında aynı kaynak IP adresinden port taraması yapan hedeflere yönelik istismar kategorisinde olay/alarm üretilmesi, birbirleriyle ilişkilendirilecek ve güvenlik açısından bir tehlike işareti olarak değerlendirilecektir.
A sample IPS log
date=2022-05-21 time=14:06:38 devname=”FG500″ devid=”FG5HSTF109K” eventtime=1650585615163261716 tz=”+0300″ logid=”0419016384″ type=”utm” subtype=”ips” eventtype=”signature” level=”alert” vd=”root” severity=”high” srcip=12.11.2.4 srccountry=”Reserved” dstip=19.66.201.16 dstcountry=”United States” srcintf=”AOS_LAN” srcintfrole=”lan” dstintf=”Wan_RL” dstintfrole=”lan” sessionid=254830141 action=”detected” proto=17 service=”DNS” policyid=2 poluuid=”6b5c8674-a36a-51ec-bbfd-2250544a9125″ policytype=”policy” attack=”DNS.Server.Label.Buffer.Overflow” srcport=57673 dstport=53 direction=”incoming” attackid=37088 profile=”default” ref=”http://www.fortinet.com/ids/VID37088″ incidentserialno=254762092 msg=”misc: DNS.Server.Label.Buffer.Overflow” crscore=30 craction=8192 crlevel=”high”
Looking at the details of the above log
date= date information
time= time information
devname= system name
devid= system ID information
tz= timezone
logid= log ID information
type= log type (values like traffic, utm, event, etc.)
subtype= log sub type (values like forward, vpn, webfilter, virus, ips, system etc.)
level= log level
severity= incident severity level
srcip= source IP address
dstip= destination IP address
srccountry= source country
dstcountry= destination country
action= action information
service= service information
attack= attack details
srcport= source port information
dstport= destination port information
direction= direction of packet
attackid= attack ID information
msg= additional message information
IDS/IPS günlükleri genellikle kaynak-hedef IP ve bağlantı noktası bilgileri, eylem bilgileri, saldırı türü, saldırı kategorisi ve saldırı düzeyi hakkında bilgiler içerir.
IDS/IPS logları analiz edilirken aşağıdaki bilgiler detaylı olarak araştırılmalıdır;
– Saldırının yönü (içeriye veya dışarıya) kontrol edilmelidir.
– Olayın şiddet düzeyi kontrol edilmelidir. Seviyeler genellikle düşük, orta, yüksek, kritik olarak ayarlanır. Yüksek ve kritik seviyeler, faaliyetin daha önemli olduğunu, hızlı eylemin gerekli olduğunu ve yanlış pozitif olasılığının daha düşük olduğunu gösterir.
– Aynı kaynak ve hedef arasında farklı bir imza tetikleme durumu kontrol edilmelidir. Farklı imzaların tetiklenmesi, olayın ciddiyet seviyesinin daha da yükseltilmesi ve daha hızlı aksiyon alınması gerektiği anlamına gelir. Aşağıdaki gibi durumlarda olay, önem düzeyine bağlı olarak hizmet düzeyi sözleşmesi (SLA) kapsamında çözümlenir:
– Tek imzanın tetiklenmesi durumunda,
– İlgili kaynaktan farklı bir talep gelmemesi,
– Firewall loglarında farklı bir kabul yoktur.
– Saldırı detayında belirtilen port/hizmet hedef portta çalışıyor mu? Çalışıyorsa olay düzeyi kritik düzeye yükseltilmeli ve hedef sistem enfeksiyon açısından kontrol edilmelidir. Ayrıca kaynaktan ilgili sisteme yanıt dönüp dönmediği de kontrol edilmelidir. Cevap hayır ise önlem olarak saldıran IP adresinin engellenmesi yerinde bir davranış olacaktır.
– Yapılan işlem sadece tespit mi, yoksa engellendi mi? Eğer saldırı engellenmişse ve güvenlik duvarında aynı IP adresinden başka bir istek yoksa aksiyon almak için biraz daha bekleyebiliriz. Ancak saldırı için yapılan eylem sadece bir tespit ise, bu durumda diğer benzer istekler incelenmeli ve IP adresinden gelen isteklerin içeriği yanlış pozitif değilse engelleme eylemi uygulanmalıdır.
Örneğin yukarıda verilen örnek logda 12.11.2.4 IP adresinden 19.66.201.16 IP adresinin 53 numaralı portuna yapılan istekte “DNS.Server.Label.Buffer.Overflow” saldırısı tespit edilmiştir. Ref üzerinden ulaşılabilen bu saldırının detaylarına baktığımızda. Log.url’de Tftpd32 DNS Sunucusunun bu saldırıdan etkilendiğini görüyoruz. 19.66.201.16 IP adresinin 53 numaralı portunda çalışan servis Tftpd32 DNS Server değilse bu saldırıdan etkilenmediğini söyleyebiliriz. Ancak işlem kısmında “algılandı” yazması bu trafiğin kaynak ile hedef arasında gerçekleştiği ve engellenmediği anlamına gelir. Yani kaynak IP adresinden yapılan bu istek, hedef IP adresinin 53 numaralı portunda çalışan servise ulaşmaktadır.
IDS/IPS günlükleri izlenerek aşağıdaki şüpheli faaliyetler tespit edilebilir;
– Port scanning activities
– Vulnerability scans
– Code Injection attacks
– Brute-Force attacks
– Dos/Ddos attacks
– Trojan activities
– Botnet activities
WAF Günlük Analizi
WAF (Web Uygulaması Güvenlik Duvarı), web tabanlı uygulamaların güvenliğini sağlamak için kullanılan teknolojidir. Güvenlik duvarı veya IDS/IPS loglarının analizi tek başına web tabanlı saldırıların tespiti için çoğu zaman yeterli değildir. Bunun temel nedenleri SSL boşaltma sorunu ve web isteğinin payload (veri) kısmındaki verilerin kontrolüdür.
SSL Aktarımı, SSL şifreli trafiğin şifresinin çözülmesidir. Sistemin temel amacı yükü azaltmak ve performansı artırmak, ayrıca şifrelenmiş trafiğin/isteğin şifresini çözerek içeriğin güvenlik açısından görünür ve kontrol edilebilir olmasını sağlamaktır. Bu sayede şifrelenmiş trafikteki görünmez saldırı vektörleri tespit edilebilir veya önlenebilir hale gelir.
WAF ile donatılmış ağlarda son kullanıcılardan gelen talepler ilk olarak internet üzerinden WAF’a ulaşır. Daha sonra WAF talebi inceler ve Web Sunucusuna aktarılıp aktarılmayacağına karar verir. Buradaki WAF’ların en büyük avantajlarından biri, HTTPS trafiğinin içeriğinin incelenmesine yardımcı olan SSL Off-load işlemini gerçekleştirebilmesidir. SSL Boşaltma özelliği olmayan WAF, HTTPS iletişiminin yük (veri) kısmını denetleyemeyeceği için tam etkili bir koruma sağlayamaz.
F5 Big-IP, Citrix, Imperva, Forti WAF ürünleri piyasada iyi bilinen WAF çözümlerine örnektir. Ayrıca Cloudflare, Akamai, AWS WAF çözümleri de cloud WAF çözümü olarak kullanılmaktadır.
WAF sistemleri genel olarak halka açık sistemlerde web erişim taleplerini karşılayan sistemlerdir. Dolayısıyla web saldırılarını tespit eden ilk sistemlerin WAF’lar olduğunu ve SOC Analistlerinin şüpheli etkinlikleri tespit etmelerine yardımcı olanların da WAF logları olduğunu söyleyebiliriz. Analistlerin WAF loglarını analiz ederken ağdaki konumlarını net bir şekilde bilmeleri gerekiyor. WAF günlükleri, yapılan tüm web isteklerini görüntülemek ve tespit edilen web saldırılarını veya engellenen web saldırılarını analiz etmek için kullanılan günlüklerin kaynağıdır. Tespit edilen veya engellenen saldırılar için oluşturulan uyarılar incelenirken, log/uyarıyı oluşturan kaynak IP adresinin itibarı da analiz edilmeli ve kaynak IP’nin diğer log kaynaklarında (IDS/IPS, Güvenlik Duvarı gibi) oluşturduğu benzer faaliyetler de analiz edilmelidir. araştırılacak.
A sample WAF log:
date=2022-01-26 time=19:47:26 log_id=20000008 msg_id=000018341360 device_id=FVVM08 vd=”root” timezone=”(GMT+3:00)Istanbul” timezone_dayst=”GMTg-3″ type=attack main_type=”Signature Detection” sub_type=”SQL Injection” severity_level=High proto=tcp service=https/tls1.2 action=Alert policy=”Alert_Policy” src=19.6.150.138 src_port=56334 dst=172.16.10.10 dst_port=443 http_method=get http_url=”?v=(SELECT (CHR(113)||CHR(120)||CHR(120)||CHR(118)||CHR(113))||(SELECT (CASE WHEN (1876=1876) THEN 1 ELSE 0 END))::text” http_host=”app.letsdefend.io” http_agent=”Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b1) Gecko/2007110703 Firefox/3.0b1″ msg=”Parameter(Password) triggered signature ID 030000136″ signature_subclass=”SQL Injection” signature_id=”030000136″ srccountry=”Germany” attack_type=”SQL Injection”
All determined web traffic passes through WAF. In other words, you can find all web request records on the WAF logs.
Following is the information you can find looking at the details of the above log
date= date information
time= time information
type: log type
main_type: detection type
sub_type: detected activity detail
severity_level: incident severity level
proto: protocol
service: service information
action: action taken
policy: rule name
src: source IP address
src_port: source port address
dst: destination IP address
dst_port: destination port address
http_method: http request method
http_url: URL requested
http_host: host requested
http_agent: user-agent info
msg: message related to the incident
signature_subclass: signature class
srccountry: source IP country
attack_type: attack type
Örnek WAF logu analiz edilirken imza tespiti yoluyla yüksek önem derecesine sahip bir SQL Injection saldırı tipine referans verdiği için kaynak ve hedef IP bilgilerinin kontrol edilmesi gerekmektedir. WAF’ın bu talebe verdiği yanıt, bildirilen saldırının yukarıdaki gibi genel (SQL intection, XSS vb.) bir web saldırısı olup olmadığı kontrol edilmelidir. WAF bu isteği engellemediyse uygulamanın döndürdüğü yanıt kontrol edilmelidir. Uygulamanın yanıtının (IIS, Apache, Nginx vb.) yanıt kodu da önemlidir ve araştırılmalıdır. WAF’ın önleyemediği bir saldırı için uygulama 200 yanıt verdiyse bu, saldırının web sunucusuna ulaştığı ve başarılı bir yanıt döndürdüğü anlamına gelir. Bazı durumlarda uygulama 200 kodunu döndürürken, uygulamadaki bazı teknik eksikliklerden dolayı aslında 404 kodunu döndürmesi gerekir. Bunlar ilgili istekler için yanlış pozitif olarak değerlendirilebilir.
Başvuru cevaplarından bazılarına örnekler;
– 200 (OK): The request was received successfully and the response was returned.
– 301 (Permanent Redirect): The request was redirected to a different location.
– 403 (Forbidden): Data requested to be accessed is not allowed.
– 404 (Not Found): The requested content could not be found.
– 503 (Service Unavailable): The server cannot respond.
Response code categories:
– Informational responses (100–199)
– Successful responses (200–299)
– Redirection messages (300–399)
– Client error responses (400–499)
– Server error responses (500–599)
Yukarıda paylaşılan örnek WAF logunda yer alan bağlantı isteği, WAF’ın 19.6.150.138 IP adresinden 443 numaralı porta gelen istek içerisindeki URL’de yer alan ifadeler nedeniyle WAF’ın kötü niyetli olarak tanıdığı imzalar nedeniyle engellenmiş ve bu konuda uyarı oluşturmuştur. WAF’ın arkasındaki 172.16.10.10 sunucusu. WAF üzerinde bu imzayla eşleşen isteklere uygulanan politika adı “Alert_Policy” olup, eylem izleme modu olan “alert” olarak ayarlanmıştır. Dolayısıyla isteğin hedef hosta ulaştığını söyleyebiliriz.
WAF’ın isteklere yönelik olarak bildirdiği saldırı, zafiyet tespiti amaçlı ise burada tespit edilecek zafiyetin detaylarına bakmak gerekir. Örneğin web uygulamanız ASP üzerinde çalışıyorsa ve zafiyet tespiti PHP uygulamasına özel bir tarama ise bu durumda böyle bir zafiyetin raporlanması beklenemez. Ancak yine de tarama faaliyetini gerçekleştiren IP adresi için herhangi bir işlem yapılması iyi bir uygulama olacaktır. Burada yapılacak en iyi işlem, gelen isteklerin ağımızla ilk etkileşime girdiği ağ geçidindeki ilk güvenlik cihazında gelen istekleri engellemektir.
Aşağıdaki algılamaları analiz ederken WAF günlüklerinin kullanılmasına yardımcı olabiliriz:
– Bilinen web açıklarının tespiti
– SQL Enjeksiyonu, XSS Saldırısı, Kod Enjeksiyonu, Dizin Geçişi gibi çeşitli web saldırılarının tespiti
– PUT, DELETE gibi şüpheli yöntem kullanımının tespiti
– En çok talep edilen IP adresi bilgileri
– En çok talep edilen URL bilgileri
İstek Yöntemi: Web dili içerisinde isteğin hangi yöntemle yapıldığını belirtir. Başlıca istek yöntemleri aşağıdaki gibidir.
– GET: Sunucudan veri almak için kullanılır
– POST: Sunucuya veri (resim, video gibi) göndermek için kullanılır.
– DELETE: Sunucudaki verileri silmek için kullanılır.
– PUT: Sunucuya veri göndermek için kullanılır (gönderilen veriler dosyaları oluşturur veya günceller)
– SEÇENEKLER: Sunucunun hangi yöntemleri kabul ettiğini söyler
Web Günlüğü Analizi
Günümüzde çoğu hizmet web tabanlı olup kuruluşların web hizmetleri dış dünyaya açık en yaygın hizmetlerdir. Bu, saldırganların bakış açısından web saldırılarına büyük ilgi göstermektedir. Bu nedenle SOC Analistlerinin web loglarını doğru analiz edebilmeleri çok önemlidir. En sık kullanılan web sunucuları Microsoft IIS, Apache, Nginx’tir. Uygulamalar farklı olsa da web sunucusu logları benzer içeriklere sahiptir.
Örnek bir web sunucusu günlüğü
71.16.45.142 – – [12/Ara/2021:09:24:42 +0200] “GET /?id=SELECT+*+FROM+users HTTP/1.1” 200 486 “-” “curl/7.72.0”
Yukarıdaki günlüğü analiz ettiğimizde
Kaynak IP’si: 71.16.45.142
Tarih: 12/Aralık/2021:09:24:42 +0200
İstek Yöntemi: GET
İstenen URL: /?id=SELECT+*+FROM+users
Sürüm Bilgisi: HTTP/1.1
Sunucu Yanıtı: 200
Veri Boyutu: 486
Kullanıcı Aracısı Bilgisi: curl/7.72.0
Talep Yöntemi:
İsteğin web dilindeki yöntemini belirtir. Ana istek yöntemleri şunlardır:
– GET: Sunucudan veri almak için kullanılır.
– POST: Sunucuya veri göndermek için kullanılır. (resim, video gibi)
– DELETE: Sunucudaki verileri silmek için kullanılır.
– PUT: Sunucuya veri göndermek için kullanılır (gönderilen veriler dosyaları oluşturur veya günceller)
– SEÇENEKLER: Sunucunun hangi yöntemleri kabul ettiğini belirtir.
Not: Genellikle (varsayılan olarak) web sunucuları, sunucuya POST veya PUT ile gönderilen verilerin içeriğini web günlüğüne yazmaz. Bu nedenle web günlüklerini analiz ederken bunu bilmek önemlidir.
İstenen URL: Talebin yapıldığı sunucudaki dizini/dosyayı belirtir. Aynı zamanda bir saldırı varsa tespit edilebiliyor. Yukarıdaki örnekte olduğu gibi “SELECT+*+FROM+users” ifadeleri bize bir “SQL Injection” saldırı modelini temsil etmektedir. Web log analizinde URL’lerin incelenmesi oldukça önemlidir.
Web saldırısı türleri ve örnek istek URL’leri
Sunucu Yanıtı: Sunucu, isteklere bazı sayı ifadeleriyle yanıt verir. Bu yanıt kodları, isteğin başarılı veya başarısız olduğunu gösterir.
Diyelim ki web loglarını incelerken URL’nin sql enjeksiyon saldırı vektörü ile ilgili bilgiler içerdiğini gördünüz, o zaman web sunucusunun yanıtına dikkat etmelisiniz;
– 200 döndürülürse: İstek sunucuya başarıyla ulaşmış ve sunucu başarıyla yanıt vermiş ve saldırı başarılı olmuştur. Bazen uygulama hataları, sunucuların aslında 404 döndürmesi gerekirken 200 ile yanıt vermesine neden olur. Bu gibi durumlarda, bunu açıklığa kavuşturmak için URL’yi sorgulamak ve isteğe verilen yanıtı analiz etmek gerekir.
– 404 döndürülürse: İstenen URL sunucuda bulunamadığından sunucu “Bulunamadı” döndürdü. Yani saldırının başarısızlıkla sonuçlandığını düşünüyoruz.
– 500 döndürülürse: Sunucu bu isteği yorumlayamadı ve “Sunucu Hatası” yanıtı döndürüldü. Yani saldırının başarısız olduğu şeklinde yorumlayabiliriz. Ancak sunucu tarafındaki bu istekler web servisin düzgün çalışmasını engellediğinden, saldırgan web saldırısı yapmak isterken servisin kesintiye uğramasına neden olarak DOS saldırısı olarak değerlendirilmektedir.
Bu durum kodlarının anlamları aşağıdaki gibidir.
– 200 (OK): The request was received successfully and the response was returned.
– 301 (Permanent Redirect): The request was redirected to a different location.
– 403 (Forbidden): Access to the data requested was not allowed.
– 404 (Not Found): The requested content could not be found.
– 503 (Service Unavailable): Occurs when the server service cannot respond.
Kategorik yanıt kodları
– Informational responses (100–199)
– Successful responses (200–299)
– Redirection messages (300–399)
– Client error responses (400–499)
– Server error responses (500–599)
Kullanıcı Aracısı Bilgileri: İstek için kullanılan uygulamayı belirtir. Kullanıcı Aracısı bilgileri, web log analizi sırasında yapılan isteklerin gerçek bir kullanıcı tarafından mı yoksa otomatik bir tarama aracı tarafından mı yapıldığının anlaşılmasına yardımcı olacaktır. Otomatik web tarama araçlarından bazıları “nikto”, “nessus”, “nmap”tir. Kullanıcı Aracısı bilgileri bölümünde “Mozilla, Chrome” veya benzeri bir web tarayıcısının bilgisini görüyorsak bu, isteğin gerçek bir kullanıcı tarafından yapıldığı anlamına gelir. Ancak Kullanıcı Aracısı bilgileri değişebilir ve bu nedenle bunun farkında olmalı ve günlüklerde gördüğümüz bilgileri doğruladığımızdan emin olmalıyız.
Saldırıya uğradığını tespit ettiğiniz web sunucusu (SQL enjeksiyonu, XSS saldırısı, kod enjeksiyonu vb. yöntemlerle) güvenlik cihazlarının (firewall, IPS/IDS, WAF vb.) arkasındaysa bu istek (aslında saldırı) bu güvenlik cihazlarından geçer. Özetle web log analizinde analistler için hemen hemen her detay önemlidir.
Web logları aracılığıyla aşağıdaki gibi bulgular üretebilir ve bunları analizlerimizde kullanabiliriz:
– Saldırı vektörlü web istekleri (SQL Enjeksiyonu, XSS Saldırısı, Kod Enjeksiyonu, Dizin Geçişi)
– En çok talep edilen IP bilgileri
– En çok talep edilen URL bilgileri
– En çok alınan HTTP yanıt kodu
– Şüpheli yöntem kullanımının tespiti (PUT, DELETE gibi)
Örnek web isteği, web günlüğü ve çıktının analizi
Web İsteği
192.168.8.11/bwapp/sqli_1.php?title=%25iron%27+union+select+1%2Cuser%28%29%2C3%2C4%2C5%2C6%2C7–+-+%25%27&action=arama
Kodu Çözülmüş Web İsteği:
Bunları (http://meyerweb.com/eric/tools/dencoder) adresinden çözebilirsiniz.
192.168.8.11/bwapp/sqli_1.php?title=%iron’ union select 1,user(),3,4,5,6,7– – %’&action=search
Web isteğinin tarayıcı çıktısı
Web Günlüğü
192.168.8.54 – – [29/Jun/2022:07:42:48 +0300] “GET /bwapp/sqli_1.php?title=%25iron%27+union+select+1%2Cuser%28%29%2C3%2C4%2C5%2C6%2C7–+-+%25%27&action=search HTTP/1.1” 200 13539 “http://192.168.8.11/bwapp/sqli_1.php?title=&action=search” “Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/102.0.0.0 Safari/537.36”
Yukarıdaki web saldırısının log analizi, saldırının 192.168.8.54’ten yapılan bir SQL enjeksiyonu olduğunu ve başarılı olduğunu göstermektedir. İsteğin URL’sinde “union”, “select” gibi ifadeler bulunması, web sunucusunun yanıtının 200 olması ve analistin bilgiye erişebildiğini doğrulayabilmesi nedeniyle bunun bir SQL enjeksiyonu olduğunu görebiliyoruz. “root@localhost” kullanıcısı hakkındaki veritabanından.
DNS Günlük Analizi
DNS internetin en temel yapı taşlarından biridir. DNS temel olarak etki alanı – IP çözümlemesi için kullanılan bir teknolojidir. Ağ trafiği temel olarak IP’ler üzerinden yürütülür ve DNS, “google.com”a erişmemiz gerektiğinde bize google.com sunucusunun IP adresinin ne olduğunu söyleyen sistemdir.
SOC analistleri genellikle bir sistemdeki olay incelemesi sırasında hangi etki alanlarının ve bunların ne zaman istendiğini kontrol etmek için DNS günlüklerini kullanır. Bu günlükleri kontrol ederken aşağıdakileri tutmalıyız:
– Sistem aslında erişilmemesi gereken kategorilerde alan adı istekleri yaptı mı?
– Sistem aslında riskli kategorilerde alan adı istekleri yaptı mı?
– Veri sızıntısı vb. durumlarda bilinen herhangi bir hizmete (google Drive, One Drive vb.) erişilmeye çalışıldı mı?
– Tehdit İstihbaratı kaynaklarından alınan domainlere istek yapan sistemler var mı?
– DNS Over TLS (DOT) veya DNS over HTTPS (DOH) servislerine erişim olup olmadığını tespit etmek için DNS logları üzerinde araştırmalar yapılmalıdır.
DNS logları, SOC Analisti açısından DNS sunucusu olayları ve DNS sorguları olarak 2 farklı kategoriye ayrılabilir.
DNS Sunucusu Kayıtları, DNS kayıtlarını barındıran sunucudaki DNS denetim olaylarıdır. Bu olaylar Windows sunucularında Eventlog’da “Uygulama ve Hizmet Logları -> Microsoft -> Windows -> DNS-Sunucu\Audit” bölümünde tutulur. DNS sunucusu üzerinde ekleme, silme, düzenleme, kayıt vb. işlemler bu loglar üzerinden izlenebilmektedir.
Örneğin aşağıdaki ekran görüntüsünde Event_ID: 516 deneme.dc.local dosyasının silinmesine ilişkin olay, bunu kimin sildiği ve Varsayılan bölge içinde hangi sunucuda silindiği ayrıntılarıyla birlikte gösterilmektedir.
DNS sorguları toplanması ve analiz edilmesi zor bir günlük kaynağıdır. DNS sunucuları varsayılan olarak bu günlükleri tutmaz ve bu günlükleri tutabilmeleri için etkinleştirilmeleri gerekir. Doğrudan DNS hizmeti tarafından oluşturulan DNS sorgularının analiz edilmesi de zordur. Ancak bunlar elde edilen IoC’lerdeki domainleri hangi sistemlerin sorguladığını bulabileceğiniz kayıtlardır. Özetle Microsoft DNS, Bind DNS, Dnsmasq gibi DNS sunucu hizmetlerini sağlayan uygulamalar, istek üzerine aldıkları DNS sorgularını kaydederler.
IOC’ler (Uzlaşma Göstergesi), bir siber güvenlik olayı öncesinde, sırasında ve sonrasında yer alan ve o siber güvenlik olayının analizi ve soruşturulması sırasında ortaya çıkan delillerdir. IOC’ler saldırının türü, saldırı sırasında kullanılan araçlar ve olası saldırganın kim olduğu gibi ayrıntıların belirlenmesinde hayati önem taşıyor.
Genellikle Linux sistemlerde kullanılan DNS sunucu hizmetleri olan bağlama günlüklerine, varsayılan yapılandırmada “/var/log/querylog” günlük dosyası aracılığıyla erişilebilir.
Örnek bir DNS günlüğü
{ “timestampt”: 1591367999.306059, “source_ip”: “192.168.4.76”, “source_port”: 36844, “destination_ip”: “192.168.4.1”, “destination_port”: 53, “protocol”: “udp”, “query”: “testmyids.com”, “qtype_name”: “A”, }
DNS sorgu günlükleri genellikle aşağıdaki verileri içerir
– Date-Time
– Querying IP, Port
– Query type
– The requested domain
Yukarıdaki örnek log, DNS sunucusu dışındaki dış ağdaki DNS kayıtlarını yakalayan bir üründen (Bro/Zeek) alındığından, sorgulamayı yapan IP’nin yanı sıra sorgulamanın yapıldığı sunucu bilgisi de bulunmaktadır. Bu nedenle DNS logları doğrudan sunucudan alınabileceği gibi ağ üzerinden bu sorguları toplayan sistemlerde de alınabilmektedir.
DNS log analizinde talep edilen domain ve onun itibarı/kategorisi önemlidir. 2020 “SolarWinds SUNBURST” saldırısında kullanılan alan adları, DNS logları analiz edilerek tespit edilmiş olabilir. Bir ağ cihazının, bir veritabanının veya 3. parti uygulama sunucularının iletişim kuracağı alanlar bellidir. Üreticinin sizinle paylaştığı ve iletişim kurması gereken alan adları, DNS logları aracılığıyla aşağıdakiler açısından araştırılmalıdır:
– İlk kez ziyaret edilen alanlar
– Belirli bir karakter boyutunun üzerindeki alanlar veya alt alanlar
– NX’ten dönen alanların tespiti
– Etki alanı IOC kontrolleri
– TLS üzerinden DNS, HTTPS üzerinden DNS erişimlerinin tespiti
Aşağıdaki DNS logları incelendiğinde 192.168.10.12 IP adresinden rastgele oluşturulan alt alan adlarına 1 dakikalık zaman diliminde DNS istekleri yapıldığını görüyoruz. DNS isteklerinin bu etkinliği, olası bir DNS tünelleme etkinliğinin işareti olabilir. Araştırmanın uç noktada bu aktiviteyi oluşturan kaynak süreç belirlenerek yürütülmesi gerekmektedir.
Aşağıdaki DNS günlüğünde yaptığımız incelemeler, istenen alan adlarının meşru göründüğünü gösteriyor. IP adresi 192.168.10.3 olan Oracle Database sunucusunun bu domainleri sorguladığı dikkate alındığında Oracle sunucusunun veri aktarımı için kullanılan Microsoft servislerine ait domainleri sorması bu aktiviteyi şüpheli hale getirmektedir.
Feb 5 09:12:11 ns1 named[80090]: client 192.168.10.3#3261: query: login.microsoftonline.com IN A
Feb 5 09:13:11 ns1 named[80090]: client 192.168.10.3#4536: query: onedrive.live.com IN A