BiznetBiznet

By Hasan Keskin

IBM QRADAR’DA SNMP KULLANIMI

Ağ yöneticileri, onlarca hatta yüzlerce cihazı kurmak, yapılandırmak, yönetmekle sorumludurlar. Kurulum işlemini için her cihazla ayrı ayrı yapmak gerekir ama bu tek seferlik bir iştir, ya sonrası? Bir ağ yöneticisi kurduğu bütün ağ bileşenlerini tek tek kontrol edebilir mi? Her bileşenin sürekli olarak çalışması gerektiği bir ağda, cihazları devamlı, sağlıklı olarak yönetebilmek için kaç ağ yöneticisinin çalışması gerekirdi? Birçok soruna olduğu gibi zamanla bu soruna da otomatize edilmiş bir çözüm bulundu: SNMP (Simple Network Management Protocol).

SNMP, yönetici tarafından, merkezi bir cihazdan ağdaki bütün cihazların çalışma durumunun, servis bilgilerinin ve çalışma prensiplerinin yönetilmesini sağlar. SNMP vasıtasıyla yönetici eriştiği bütün ağ bileşenlerini görüntüleyebilir ve bu cihazlara komut vererek çalışmalarını yönlendirebilirler.

Bir ağ yöneticisi, sorumlusu olduğu ağa hakim olabilmek için temel olarak iki işlem yapar:

  • Ağdaki cihazların nasıl çalıştığını öğrenmek.
  • Cihazların işleyişini düzenlemek amacıyla komutlar girmek.

Bu iki işlem teknik olarak, sırasıyla okuma (read) ve yazma (write) işlemlerine karşılık gelmektedir.

Birçok protokol komut odaklı çalışır. Gerçekleştirilmesi amaçlanan işlemleri yerine getirmek için belirli bir komut vardır. Örneğin; “x servisi çalışıyor mu” ya da “y servisini çalıştır”.

Ağ yöneticisi uygun komutları kullanarak bir cihaz üzerindeki servisi kontrol edebilir ya da bir servisin aktif hale gelmesini sağlayabilir. Bu açıdan komut odaklı protokollerin çalışması kolaydır fakat bu işlemi çok fazla cihazın bulunduğu geniş bir ağda gerçekleştirmek isterse sorunlarla karşılaşabilir.

Ağdaki her cihaz farklı tür komutlarla çalışıyor olabilir, yeni bir cihaz üretildiğinde bu cihazı yönetmek için farklı bir protokol gerekebilir. Bir cihazın çalışma şekli değiştiğinde protokolün güncellenmesi gerekebilir ve protokolün güncellenmesi başka cihazları ya da donanımları etkiliyor olabilir.

Komut odaklı yönetim modeli yerine, bilgi odaklı bir yönetim modeli kullanmak yani cihaz yönetimi için belirli komutlar kullanmak yerine, cihaz ve yönetim birimi arasında bilgi alışverişini sağlayacak bir model kullanmak daha faydalı olacaktır.

SNMP,bu anlamda birçok protokolün aksine bilgi odaklı çalışan bir protokol olarak, uygulama seviyesinde çalışan, “object” adı verilen değişkenler yardımıyla cihazları yönetir. Yani bir komut çalıştırmak yerine bir değişkeni okuyarak cihazın durumunu görüntüler ya da bir değişkeni değiştirerek cihazın çalışmasını yönetebilir.

SNMP ile yönetilen basit bir ağ, 3 farklı bileşenden oluşur:

  • Uygulama seviyesinde çalışarak yönetici tarafından kullanılan “NMS” (Network Management System),
  • Yönetici ve yönetilen fiziksel cihazlar arasında ara yüzü sağlayan “Agent”,
  • Managed Device” olarak isimlendirilen fiziksel cihazlar.

SNMP ile cihazların yönetebilmesi için ağdaki her cihaza özel olarak bulunan, MIB (Management Information Base) adı verilen, içinde “object” isimli değişkenler barındıran veri tabanı bulunur. Yönetici ile agent arasındaki iletişim MIB aracılığıyla sağlanır.

SNMP, yönetici ile agent arasındaki iletişim farklı komutlar yoluyla sağlanır:

  1. Get
  2. GetNext
  3. GetBulk (SNMPv2)
  4. GetResponse
  5. Set
  6. Trap
  7. Inform (SNMPv2)
  • Yönetici Get, GetNext ya da GetBulk mesajları ile bir ya da birden fazla değişken verisi talep eder, agent ise GetResponse mesajı ile talep edilen veriyi ya da isteğin neden cevaplandırılamadığını belirten hata mesajını iletir.
  • Yönetici Set mesajı ile bir değişken üzerindeki verinin değiştirilmesini talep eder, agent ise GetResponse mesajı ile değişikliğin yapıldığını veya hangi nedenle yapılamayacağını belirten GetResponse mesajı iletir.
  • Trap mesajı ise agent tarafından yöneticiye iletilen, önemli olayı ya da durumu belirten mesajdır.
  • Inform mesajı, mesaj iletildikten sonra yöneticiden onay paketi beklenir. Onay gelmediği durumda Inform mesajı tekrar gönderilir.

SNMP’nin 3 (üç) versiyonu vardır: SNMPv1, SNMPv2, SNMPv3.

SNMPv1

En eski versiyonudur ve yönetilen cihazlardan veri çekmek için basit fonksiyonlar sağlar. Basit ve kolay kullanılabilir bir yapıya sahiptir ve şifreleme algoritması barındırmaz. Güvenlik sebebiyle sadece LAN seviyesinde kullanmak daha sağlıklı olacaktır.

En büyük dezavantajı ise 32-bit counter yapısı ile günümüzde gigabyte ve terabyte’larla ifade edilen trafik için yetersiz kalmasıdır.

SNMPv2

Bu versiyonla 64-bit counter yapısına geçilmiştir fakat hala bazı kritik bilgilerin clear text olarak gönderiliyor olması, güvenlik açısından pek değer katmamıştır.

SNMPv2 konuşulurken genelde SNMP “v2c” ile karşılaşırız. “c” community anlamına gelmektedir. SNMP ”v2p“ ve . SNMP ”v2u” olmak üzere iki farklı versiyonu daha bulunmaktadır ama bunlar çok nadir durumlarda kullanılırlar.

SNMPv3

2002 yılında ortaya çıkarılan SNMPv3, önceki versiyon olan SNMPv2c özelliklerini barındırmakla birlikte, farklı güvenlik çözümleri ile gelmiştir: Kullanıcı hesabı (user account) tanımlama, kimlik doğrulama (authentication) ve veri şifreleme (encryption) özelliği. Bu açıdan kullanılması tavsiye edilen SNMP versiyonudur fakat unutulmamalıdır ki; bu özellikler yapılandırmayı zorlaştırdığı gibi daha çok veri işlem kapasitesine de ihtiyaç oluşturur.

Peki IBM QRadar’da SNMP nasıl kullanılıyor?

SNMP, IBM QRadar 7.2.x ve sonraki versiyonlarında desteklenen bir protokoldür. SNMP ile log toplamak isteyen kullanıcı, log kaynağını manuel olarak eklemek durumundadır. Çünkü QRadar event verilerini otomatik olarak tanımayacaktır. Log kaynağı eklenip, “Deploy configuration” yapıldıktan sonra, yapılandırmada belirtilen portun açıldığından emin olunmalıdır. Port açıldıktan sonra SNMP yoluyla alınan veriler parse edilir ve işlenir.

IBM QRadar varsayılan olarak UDP 162 portunu kullanır, eğer kullanıcı bunu değiştirmek isterse,

admin > system configuration > system settings > SNMP settings yolundan “destination port” seçeneğinden değiştirebilir. İşlemi tamamladıktan sonra “Deploy full configuration” işlemi yapılmalıdır.

SNMPv2 ya da SNMPv3 kullanan bir log kaynağı eklerken, event payloadlarının düzgün bir şekilde biçimlendirildiğinden ve isim-değer çiftinin doğru yapılandırıldığından emin olmak için “Include OIDs in Event Payload” seçeneği aktif edilmelidir. (OID=Object ID kısaltmasıdır ve her Event’in cihaz hakkındaki bilgiler yardımıyla eşsiz bir şekilde ayırt edilmesini sağlar)

Ayrıca, IBM QRadar, üzerinde oluşan alarm/offense’leri SNMP trap yardımıyla farklı cihazlara gönderebilir. Fakat bu özellik varsayılan olarak aktif değildir.

SNMP ile SolarWinds Orion’da Log Toplama (SolarWinds Orion NPM 12.4)

SolarWinds Orion ile IBM QRadar’ı entegre etmek için sırasıyla aşağıdaki işlemler gerçekleştirilmelidir:

  • Otomatik güncellemeler aktif değil ise IBM Support (http://www.ibm.com/support) sitesinden SolarWinds Orion DSM RPM dosyası QRadar Console’a indirilir,
  • Loglarını QRadar’a göndermesi için SolarWinds Orion cihazı yapılandırılır,
  • IBM QRadar üzerinde SolarWinds Orion log kaynağı olarak eklenir,
  • QRadar’ın doğru yapılandırıldığından emin olunur.

SOLARWINDS ORION’U YAPILANDIRMA

  1. Alerts & Activity menüsünden Alerts sekmesine ulaşılır.
  2. Alerts sekmesi açıldıktan sonra, sağ üst bölgede bulunan Manage Alerts menüsü açılır.
  1. ADD NEW ALERT seçeneği seçilir.
  2. Add action sekmesinde, “Send SNMP Trap” seçeneği seçilir.
  • Configure Action” seçeneği seçilerek açılan menüde eklenen action için isim belirlenir. “SNMP Trap Destinations” bölümünde ise, IBM QRadar Console ya da Event Collector IP adresi belirtilir.

NOT: SNMP Properties bölümünde, eğer default SNMP portu kullanılmayacaksa, değişiklik yapılarak istenilen SNMP portu ve versiyonu belirlenmelidir. Community string değeri de bu bölümde değiştirilir.

  • Summary sekmesinde, geriye dönük bir değişiklik yapılması gerekmiyorsa, “Submit” butonuna tıklanır ve SolarWinds Orion yapılandırması tamamlanır. İşlem sonucunda, oluşturulan alert, “Alerts” bölümüne eklenecektir.

IBM QRADAR YAPILANDIRMASI (Ver: 7.3.1)

IBM QRadar 7.3.1 üzerinde log kaynayı ekleme işlemi için, IBM QRadar Console’da;

  1. “Admin” menüsü açılır.
  2. “Data sources” Menüsünden “Log sources” penceresi açılır.
  3. Açılan pencerede, ekleme işlemişi başlatmak üzere, üstte bulunan “add” butonuna tıklanır.

Açılan ekranda;

  1. “Log Source Name” kısmına SolarWinds Orion cihazın adı verilir.
  2. “Log Source Description” kısmında, istenilen log kaynağı tanımı yazılabilir.
  3. “Log Source Type” olarak, SolarWinds Orion seçilmelidir.
  4. “Protocol Configuration” kısmında SNMP versiyonu seçilir. (SNMP v2 ya da SNMPv3)

SolarWinds Orion NPM 12.4 cihazında yapmış olduğumuz tanımlamalara istinaden;

  1. “Log Source Identifier” kısmında SolarWinds Orion cihazının IP adresi belirtilir.
  2. “Authentication Protocol” kısmında, SolarWinds Orion cihazında tanımlanmış olan algoritma seçilir. (MD5 ya da SHA)
  3. “Authentication Password” kısmında, SolarWinds Orion cihazında tanımlanmış olan şifre girilmelidir. Şifre en az 8 karakter içermelidir.
  4. “Decryption Protocol” kısmında, SolarWinds Orion cihazında tanımlanmış olan decryption algoritması seçilir. (DES, AES128, AES192 ya da AES256. Eğer AES192 ya da AES256 seçilmişse, Java Cryptography eklentisi yüklenmelidir.)
  5. “Decryption Password” kısmında, SolarWinds Orion cihazında tanımlanmış olan decryption şifresi girilir. Şifre en az 8 karakter içermelidir.
  6. SolarWinds Orion cihaz loglarının event payload bölümünde standart payload görünümü yerine isim-değer ikilisi görüntülenmesi için, “Include OIDs in Event Payload” seçeneği aktif edilir.

NOT: SNMPv2 ile log kaynağı ekleniyorsa, belirlenmiş olan “community string” değeri “community” bölümünde belirtilir. Bu ayar default olarak “public” şeklinde tanımlıdır, değişiklik yapılmamışsa sonraki adıma geçebilirsiniz.

  1. Yapılan değişiklikler kaydedilir.
  2. Admin sekmesine dönülür ve s ol üst bölgede bulunan “Deploy Changes” seçeneği seçilir.

By Orhan Solak

IBM QRadar UBA’NIN ETKİNLİĞİNİ GELİŞTİRME

IBM QRadar User Behaviour Analytics (UBA) uygulamasının asıl hedeflerinden biri, kullanıcılarını enine boyuna analiz ederek, tehlike oluşturabilecek kullanıcıları tespit etmek veya sistemdeki kullanıcılara ait paylaşılmaması gereken bilgilerin ifşa olup olmadığını saptamaktır. Bir diğer temel hedefi ise, edindiği kullanıcı bilgileri ile diğer log kaynaklarından gelen bilgilerin korelasyonunu sağlayıp, atakları daha çabuk ve doğru bir şekilde tespit etmektir.

Siber saldırganların bir an bile boş durmadıkları bir zaman diliminde yaşadığımız için, atakların daha çabuk ve doğru bir şekilde tespit edilebilmesi hayati önem arz etmektedir. Dolayısıyla, IBM QRadar UBA uygulaması, analistlerin saldırıları tespit ederken en önemli yardımcılarından biri olmuştur.

Saldırı tespiti konusunda kullanılan hiçbir ürün ya da yazılım, ilk başlatıldığı anda yeterli verimliliği sağlayamamaktadır. Çünkü ürün ya da yazılımların, kurumun siber güvenlik mimarisine uygun bir şekilde ayarlanması ve geliştirilmesi gerekmektedir. Örneğin; herhangi bir sunucuya sadece bir kere bile hatalı giriş (login) denemesi yapılmasının oldukça kritik olduğu bir kurumda, en az 3 hatalı login denemesinden sonra alarm üretilmesi doğal olarak bu kurumda bir zafiyet yaratacaktır. IBM QRadar kullanılan kurumlarda bu gibi durumların önüne geçmek için, IBM QRadar UBA uygulamasının da kuruma özel bir şekilde geliştirilmesi gerekmektedir.

IBM QRadar UBA uygulamasının daha başarılı bir şekilde çalışması için yapılması gereken geliştirmeleri iki ana başlık altında inceleyebiliriz;

1.            Kullanıcı Erişimleri

1.1)        Anormal Erişimler Yapılması kurum tarafından onaylanmayan erişimlerin kontrolünü takip ederek istenmeyen olayların önüne geçilebilir. Ayrıca, kullanıcıların giriş hareketlerini takip ederek aktif olmayan kullanıcı isimleri ile olan işlemleri, şifre çalma ya da şifre kırma olayları tespit edilebilir, hatta yerel networkte cihazdan cihaza atlayama çalışan kullanıcılar da tespit edilebilir.

1.2)        Kritik Varlıklar ve Kritik Kullanıcılar

Çok kritik ve sadece belirli kullanıcıların girişinin izinli olduğu cihazlara, yetkisi olmadan erişmeye çalışan kullanıcılar tespit edilebilir. Daha önce kritik işleri yapacak yetkisi olmayan kullanıcıların ilk defa bu tarz aktivitelerde bulunması da takip edilmesi gereken hareketlerden biri.

1.3)        Olağandışı Aktiviteler

IBM QRadar’ın sahip olduğu ADE (Anomaly Detection Engine) kuralları yardımı ile birtakım alarmlar oluşturarak, bir kullanıcının her zaman kullandığı IP adresinin değişmesi, genellikle oluşturmadığı event logları oluşturması, her zaman bulunduğu konum dışında bir konumdan bağlantı sağlaması ya da mesaiye kalmayan bir kullanıcının mesai saatleri dışında event logu oluşturması gibi olağandışı aktiviteler tespit edilebilir.

Birinci görselde bir kullanıcının günlük çalışma saatlerindeki konumu mavi ile gösterilirken, yıldız ile işaretlenmiş konumlar bu kullanıcının normal çalışma konumunun dışında bir alanda bulunduğunu göstermektedir.

İkinci görselde ise; bir kullanıcının belli bir zaman içerisinde oluşturduğu network hareketleri bulunmaktadır. Mavi ile gösterilenler olağan trafik miktarını, kırmızılar ise anomali durumunu (oluşturulan olağan dışı trafik miktarı) temsil etmektedir.

2.            Network Aktiviteleri

Network harekeleri ile kullanıcı bilgilerini korele edip, bu bilgiler ışığında kuruma uygun kurallar yazmak, kullanıcı anomalilerini tespit etmede oldukça yardımcı bir konumdadır.

Takip edilebilecek network hareketlerine aşağıdaki örnekler verilebilir:

  • Uzun zaman boyunca (örnek olarak 10 saat) SSH bağlantısında bulunan kullanıcı olması,

  • Bir kullanıcının DoS ya da DDoS atağında bulunması,

  • Network analizi ya da dinlemesi yapan kullanıcıların olması,

  • SSL/TLS oturumunda, tarihi geçmiş ya da geçersiz bir sertifika kullanılması,

  • Zararlı yazılım aracığıyla ya da zararlı yazılım içeren bir alan adıyla trafik oluşturulması,

  • Sistemde bulunmayan bir kullanıcıya gelen maillerin görülmesi,

  • Sürekli spam ya da muhtemel oltalama mailleri alan kullanıcıların bulunması,

  • IBM X-Force Exchange TI veri tabanında bulunan IP’ler ile iletişime geçen kullanıcıların tespit edilmesi.

IBM QRadar UBA ara yüzünün bir örneği aşağıdaki görselde verilmiştir. Yukarıda verdiğimiz anomali tespit yöntemleri başarılı bir şekilde uygulandığında, IBM QRadar UBA anormal hareketleri inceleyerek aşağıdaki gibi riskli kullanıcıları belirleyebilir, yapılan tehlikeli hareketleri yakalayabilir ve daha detaylı raporlar oluşturabilir.

Bu iki temel UBA geliştirme alanlarında kuruma uygun gerekli iyileştirmeler yapıldıktan sonra, IBM QRadar ürünü analistlere daha çabuk ve daha başarılı alarmlar üretecek ve oluşacak false-positive sayısını gözle görülür biçimde azaltacaktır.

By Fatih Mustafa Oysal

Command and Control [C&C] Server

Bilgisayarınızda tarayıcınızı açtığınızda sürekli rahatsız edici pop-up’ların otomatik olarak açılması veya bilgisayarınızda hiçbir bir problem olmamasına rağmen normalden daha yavaş çalışması…

Bu tür olaylar ne kadar da tanıdık geliyor değil mi? Peki ya nasıl yüklendiğini bile bilmediğiniz, hiç kullanmadığınız ve yüklü olmasını önemsemediğiniz tarayıcı eklentileri? İyi de bunlar nasıl oluyor?

Tam şu anda, bütün bunları yapan bir malware olarak düşünebilir miyiz veya bilgisayarımıza virüs bulaşmış diyebilir miyiz? Haklısınız! Cihazınız bir C&C tarafından kontrol edilen “Zombi”ye dönüştürülmüş olabilir.

Command and Control Server, aynı zamanda C&C veya C2 olarak da bilinen, ransomware veya rootkit gibi kötü amaçlı yazılım bulaşmış cihazlara komutlar/yönergeler gönderen merkezi bir sunucudur. Bu sunucunun göndermiş olduğu komutlar sayesinde veri çalma, DDoS atakları, veri silme, cihazdaki verileri şifreleme gibi birden çok işlem yapılabilmektedir. Örneğin; Kredi Kartı bilgilerini öğrenme.

C&C sunucusu tarafından kontrol edilen malware bulaşmış cihazlara Zombi denilmektedir. Bu cihazların kullanıcıları, verilerinin internet yoluyla başka bir bilgisayara gönderildiğinden haberleri yoktur. Bu cihazları “Botnet” olarak da adlandırabiliriz. Botnet, robot ve network kelimelerinin birleşiminden ortaya çıkarılmış bir isimdir.

Aşağıdaki grafikte C&C sunucularının nasıl çalıştığını kolayca anlayabiliriz.

Genel anlamda 2 farklı Botnet yapısı bulunmaktadır. Bunlar Centralized ve Decentralized yapılarıdır.

Centralized en yaygın ve kullanılan Botnet yapısıdır. Bu yapı kendi arasında aşağıdaki resimde görüldüğü gibi 3 farklı yapıda oluşturulabilir.

  • Internet Relay Chat (IRC) protokolünü kullanılarak C&C sunucu ile Botnet bilgisayar arasında iletişim sağlanır.
  • Botnet bilgisayarlar aralarındaki iletişimi “Chat” sunucularını kullanarak sağlarlar.
  • Basit ve düşük band genişliği iletişim metotları kullanırlar.

Decentralized veya Peer-to-Peer (P2P) olarak da bilinen diğer Botnet yapısıdır.

Aşağıdaki resimde görüldüğü üzere, bu yapıda C&C sunucusu için merkezi bir nokta yoktur. Botnet ağı içerisindeki herhangi bir host C&C sunucusu ve Zombi bilgisayar olarak kullanılabilir. Bu sayede C&C sunucu iletişiminin fark edilmesi önlenir ve C&C başarısızlıkları en aza indirilmiş olur. Böylece bir Zombi host saptandığında aradaki boşluk Botnet ağında bulunan diğer hostlar tarafından sekteye uğramadan devam ettirilebilmektedir.

IBM QRadar SIEM ürünü çeşitli birçok C&C server offenseleri üretebilmektedir. Ortaya çıkan bu offenseleri inceleyip muhtemel saldırının gerçek olup olmadığına karar verebiliriz. Bu sayede olası bir Botnet bilgisayarı tespit edebilir veya Botnet bilgisayarlardan gelen trafiği saptayabiliriz.

IBM QRadar SIEM ürününün üretmiş olduğu örnek bir offense’i inceleyelim.

  1. IBM QRadar üzerinde oluşturulan olay örgüsüne verilen isim
  2. Olayın kısa bir açıklaması
  3. Oluşan offense’in ağ içerisindeki etkisi (Kural oluşturulurken 1 ile 10 arasında bir değer atanabilir). Örnek olarak eğer ki tehdit açık bir porta doğru ise relevance değeri yüksek olacaktır.
  4. Tehdit seviyesi (Kural oluşturulurken 1 ile 10 arasında bir değer atanabilir)
  5. Oluşan tehdidin doğruluğu (Kural oluşturulurken 1 ile 10 arasında bir değer atanabilir). Aynı zamanda birden fazla log kaynağı aynı offense’i üretirse credibility yüksek olacaktır.
  6. Trafiği oluşturan kaynak cihaza giriş yapmış kullanıcının adı
  7. Trafiği oluşturan kaynak cihazın IP adresi
  8. Trafiğin kaynaktan çıkarak muhtemel C&C sunucusuna gitmek istediği IP adresi
  9. Kaynak cihazın adı
  10. Trafiği oluşturan kaynak cihazın port numarası
  11. Kaynak cihazın erişmek istediği IP adresinin port numarası
  12. Kaynak cihazın MAC adresi
  13. Log’un içerisindeki ham veriler. Buradaki ham veriler pars edilerek bahsi geçen alanlarda gösterilmektedir.

IBM QRadar SIEM ürünü içerisinde IBM tarafından oluşturulan kurallar vardır. Offense’ler ürün içerisinde gelen Log’ların parslanmasından sonra bir Event QID ve Low Level Category dediğimiz değerlerle eşlenip eşlenmediğine bakarak üretilir. Bu EventQID ve Low Level Category değerleri QRadar cihazının yapmış olduğu korelasyonlar sayesinde atanır.