🥇Dahili ağ güvenliğini izleme aracı olarak akış protokolleri

Dahili bir kurumsal veya departman ağının güvenliğinin izlenmesi söz konusu olduğunda, çoğu kişi bunu bilgi sızıntılarını kontrol etmek ve DLP çözümlerini uygulamakla ilişkilendirir. Ve soruyu açıklığa kavuşturmaya çalışırsanız ve iç ağdaki saldırıları nasıl tespit ettiğinizi sorarsanız, o zaman cevap, kural olarak, izinsiz giriş tespit sistemlerinden (IDS) bahsedecektir. Ve 10-20 yıl önce tek seçenek olan şey bugün anakronizme dönüşüyor. Dahili bir ağı izlemek için daha etkili ve bazı yerlerde mümkün olan tek seçenek var - başlangıçta ağ sorunlarını aramak (sorun giderme) için tasarlanmış, ancak zamanla çok ilginç bir güvenlik aracına dönüşen akış protokollerini kullanmak. Hangi akış protokollerinin mevcut olduğu ve ağ saldırılarını tespit etmede hangilerinin daha iyi olduğu, akış izlemeyi nerede uygulamanın en iyi olduğu, böyle bir planı dağıtırken nelere dikkat edilmesi gerektiği ve hatta tüm bunların yerli ekipmanlarda nasıl "kaldırılacağı" hakkında konuşacağız. bu makale kapsamında.

“İç altyapı güvenliği izlemesine neden ihtiyaç duyulur?” sorusu üzerinde durmayacağım. Cevap açık gibi görünüyor. Ancak yine de bugün onsuz yaşayamayacağınızdan bir kez daha emin olmak istiyorsanız, bakmak Güvenlik duvarı tarafından korunan kurumsal bir ağa 17 yolla nasıl girebileceğinizi anlatan kısa bir video. Bu nedenle, iç izlemenin gerekli bir şey olduğunu anladığımızı ve geriye kalan tek şeyin nasıl organize edilebileceğini anlamak olduğunu varsayacağız.

Ağ düzeyinde altyapının izlenmesi için üç temel veri kaynağının altını çizeceğim:

Yakaladığımız ve belirli analiz sistemlerine analiz için gönderdiğimiz “ham” trafik,
Trafiğin geçtiği ağ cihazlarından gelen olaylar,
akış protokollerinden biri aracılığıyla alınan trafik bilgileri.

Ham trafiği yakalamak, güvenlik uzmanları arasında en popüler seçenektir çünkü bu, tarihsel olarak ortaya çıktı ve ilk oldu. Geleneksel ağ saldırı tespit sistemleri (ilk ticari saldırı tespit sistemi, 1998'de Cisco tarafından satın alınan Wheel Group'tan NetRanger'dı) belirli imzaların arandığı paketleri (ve daha sonraki oturumları) tam olarak yakalamakla meşguldü (bkz. FSTEC terminolojisi), sinyal saldırıları. Tabii ki, ham trafiği yalnızca IDS kullanarak değil, aynı zamanda diğer araçları (örneğin, Wireshark, tcpdum veya Cisco IOS'taki NBAR2 işlevselliği) kullanarak da analiz edebilirsiniz, ancak genellikle bir bilgi güvenliği aracını normal bir bilgi güvenliği aracından ayıran bilgi tabanından yoksundurlar. BT aracı.

Yani saldırı tespit sistemleri. Ağ saldırılarını tespit etmenin en eski ve en popüler yöntemi, çevrede (kurumsal, veri merkezi, segment vb. ne olursa olsun) iyi iş çıkarır, ancak modern anahtarlamalı ve yazılım tanımlı ağlarda başarısız olur. Geleneksel anahtarlar temelinde oluşturulan bir ağ durumunda, saldırı tespit sensörlerinin altyapısı çok genişliyor; saldırıları izlemek istediğiniz düğüme yapılan her bağlantıya bir sensör kurmanız gerekecek. Elbette her üretici size yüzlerce, binlerce sensör satmaktan mutluluk duyacaktır ancak bütçenizin bu tür masrafları karşılayamayacağını düşünüyorum. Fiyat meselesi önümüzde gibi görünse de Cisco olarak bile (ve biz NGIPS'in geliştiricileriyiz) bunu yapamadık diyebilirim. Ayakta durmamalıyım; bu bizim kendi kararımız. Ek olarak, sensörün bu versiyona nasıl bağlanacağı sorusu ortaya çıkıyor? Boşluğa mı? Ya sensörün kendisi arızalanırsa? Sensörde bir bypass modülüne mi ihtiyacınız var? Ayırıcılar kullanılsın mı (dokunma)? Bütün bunlar çözümü daha pahalı hale getiriyor ve her büyüklükteki şirket için karşılanamaz hale getiriyor.

Sensörü bir SPAN/RSPAN/ERSPAN bağlantı noktasına "asmayı" ve gerekli anahtar bağlantı noktalarından trafiği ona yönlendirmeyi deneyebilirsiniz. Bu seçenek önceki paragrafta açıklanan sorunu kısmen ortadan kaldırır, ancak başka bir sorunu ortaya çıkarır - SPAN bağlantı noktası kendisine gönderilecek tüm trafiği kesinlikle kabul edemez - yeterli bant genişliğine sahip olmayacaktır. Bir şeyleri feda etmeniz gerekecek. Ya bazı düğümleri izlemeden bırakın (o zaman önce onlara öncelik vermeniz gerekir) ya da düğümden gelen trafiğin tamamını değil, yalnızca belirli bir türü gönderin. Her durumda bazı saldırıları kaçırabiliriz. Ayrıca SPAN portu diğer ihtiyaçlar için de kullanılabilir. Sonuç olarak, sahip olduğunuz sensör sayısıyla ağınızı maksimum düzeyde kapsamak (ve bunu BT ile koordine etmek) için mevcut ağ topolojisini gözden geçirmemiz ve muhtemelen üzerinde ayarlamalar yapmamız gerekecek.

Ağınız asimetrik rotalar kullanıyorsa ne olur? Peki ya SDN'yi uyguladıysanız veya uygulamayı planlıyorsanız? Trafiği fiziksel anahtara hiç ulaşmayan sanallaştırılmış makineleri veya konteynerleri izlemeniz gerekirse ne olur? Bunlar, geleneksel IDS satıcılarının hoşlanmadığı sorular çünkü onlara nasıl cevap vereceklerini bilmiyorlar. Belki sizi tüm bu moda teknolojilerin abartılı olduğuna ve bunlara ihtiyacınız olmadığına ikna edeceklerdir. Belki küçük başlamanın gerekliliği hakkında konuşacaklar. Ya da belki ağın merkezine güçlü bir harmanlayıcı koymanız ve dengeleyicileri kullanarak tüm trafiği ona yönlendirmeniz gerektiğini söyleyecekler. Size hangi seçenek sunulursa sunulsun, bunun size ne kadar uygun olduğunu açıkça anlamanız gerekir. Ve ancak bundan sonra ağ altyapısının bilgi güvenliğini izlemeye yönelik bir yaklaşım seçmeye karar verin. Paket yakalama konusuna dönecek olursak, bu yöntemin oldukça popüler ve önemli olmaya devam ettiğini ancak asıl amacının sınır kontrolü olduğunu söylemek istiyorum; kuruluşunuz ile İnternet arasındaki sınırlar, veri merkezi ile ağın geri kalanı arasındaki sınırlar, süreç kontrol sistemi ile kurumsal segment arasındaki sınırlar. Bu yerlerde klasik IDS/IPS'nin hala var olma ve görevleriyle iyi bir şekilde başa çıkma hakkı vardır.

İkinci seçeneğe geçelim. Ağ cihazlarından gelen olayların analizi de saldırı tespit amacıyla kullanılabilir, ancak yalnızca küçük bir izinsiz giriş sınıfının tespit edilmesine izin verdiği için ana mekanizma olarak kullanılamaz. Ek olarak, bazı tepkiselliklerin doğasında vardır - önce saldırının gerçekleşmesi gerekir, ardından bir ağ cihazı tarafından kaydedilmesi gerekir; bu, şu veya bu şekilde bilgi güvenliğiyle ilgili bir soruna işaret edecektir. Bunun gibi birkaç yol var. Bu sistem günlüğü, RMON veya SNMP olabilir. Bilgi güvenliği bağlamında ağ izlemeye yönelik son iki protokol, yalnızca ağ ekipmanının kendisine yönelik bir DoS saldırısını tespit etmemiz gerektiğinde kullanılır, çünkü RMON ve SNMP kullanarak örneğin cihazın merkezi üzerindeki yükü izlemek mümkündür. işlemci veya arayüzleri. Bu, "en ucuz" yöntemlerden biridir (herkesin sistem günlüğü veya SNMP'si vardır), ancak aynı zamanda dahili altyapının bilgi güvenliğini izlemeye yönelik tüm yöntemler arasında en etkisiz olanıdır - birçok saldırı ondan gizlenir. Elbette ihmal edilmemelidirler ve aynı sistem günlüğü analizi, cihazın konfigürasyonundaki değişiklikleri ve bunun tehlikeye atılmasını zamanında tespit etmenize yardımcı olur, ancak tüm ağdaki saldırıları tespit etmek için pek uygun değildir.

Üçüncü seçenek, çeşitli akış protokollerinden birini destekleyen bir cihazdan geçen trafik hakkındaki bilgileri analiz etmektir. Bu durumda, protokolden bağımsız olarak iş parçacığı altyapısı zorunlu olarak üç bileşenden oluşur:

Akışın oluşturulması veya dışa aktarılması. Bu rol genellikle bir yönlendiriciye, anahtara veya başka bir ağ cihazına atanır; bu, ağ trafiğini kendi içinden geçirerek, ondan anahtar parametreleri çıkarmanıza olanak tanır ve bunlar daha sonra toplama modülüne iletilir. Örneğin Cisco, Netflow protokolünü yalnızca sanal ve endüstriyel olanlar da dahil olmak üzere yönlendiriciler ve anahtarlarda değil, aynı zamanda kablosuz denetleyicilerde, güvenlik duvarlarında ve hatta sunucularda da destekler.
Toplama akışı. Modern bir ağın genellikle birden fazla ağ cihazına sahip olduğu göz önüne alındığında, akışların toplanması ve birleştirilmesi sorunu ortaya çıkar ve bu sorun, alınan akışları işleyen ve ardından bunları analiz için ileten toplayıcılar kullanılarak çözülür.
Akış analizi Analizör ana entelektüel görevi üstlenir ve akışlara çeşitli algoritmalar uygulayarak belirli sonuçlar çıkarır. Örneğin, bir BT fonksiyonunun parçası olarak böyle bir analizör, ağ darboğazlarını belirleyebilir veya daha fazla ağ optimizasyonu için trafik yükü profilini analiz edebilir. Bilgi güvenliği açısından böyle bir analizör veri sızıntılarını, kötü amaçlı kodların yayılmasını veya DoS saldırılarını tespit edebilir.

Bu üç katmanlı mimarinin çok karmaşık olduğunu düşünmeyin - diğer tüm seçenekler (belki de SNMP ve RMON ile çalışan ağ izleme sistemleri hariç) de buna göre çalışır. Analiz için bir ağ cihazı veya bağımsız bir sensör olabilen bir veri oluşturucumuz var. Tüm izleme altyapısı için alarm toplama sistemimiz ve yönetim sistemimiz var. Son iki bileşen tek bir düğümde birleştirilebilir, ancak az çok büyük ağlarda, ölçeklenebilirlik ve güvenilirliği sağlamak için genellikle en az iki cihaza yayılırlar.

Her paketin başlık ve gövde verilerinin ve içerdiği oturumların incelenmesine dayanan paket analizinden farklı olarak akış analizi, ağ trafiğine ilişkin meta verilerin toplanmasına dayanır. Ne zaman, ne kadar, nereden ve nereden, nasıl... bunlar çeşitli akış protokolleri kullanılarak ağ telemetrisinin analiziyle yanıtlanan sorulardır. Başlangıçta istatistikleri analiz etmek ve ağdaki BT sorunlarını bulmak için kullanıldılar, ancak daha sonra analitik mekanizmalar geliştikçe bunların güvenlik amacıyla aynı telemetriye uygulanması mümkün hale geldi. Akış analizinin paket yakalamanın yerini almadığını veya değiştirmediğini bir kez daha belirtmekte fayda var. Bu yöntemlerin her birinin kendine has uygulama alanı vardır. Ancak bu makalenin bağlamında, iç altyapının izlenmesi için en uygun olanı akış analizidir. Bir saldırının atlayamayacağı ağ cihazlarınız var (ister yazılım tanımlı bir paradigmada ister statik kurallara göre çalışıyor olsunlar). Klasik bir IDS sensörünü atlayabilir ancak akış protokolünü destekleyen bir ağ cihazı bunu yapamaz. Bu, bu yöntemin avantajıdır.

Öte yandan, kolluk kuvvetleri veya kendi olay araştırma ekibiniz için kanıta ihtiyacınız varsa, paket yakalama olmadan yapamazsınız - ağ telemetrisi, kanıt toplamak için kullanılabilecek trafiğin bir kopyası değildir; bilgi güvenliği alanında hızlı tespit ve karar verebilmek için gereklidir. Öte yandan, telemetri analizini kullanarak, tüm ağ trafiğini değil (eğer varsa, Cisco veri merkezleriyle ilgilenir :-), yalnızca saldırıya dahil olanı "yazabilirsiniz". Bu bağlamda telemetri analiz araçları, seçici yakalama ve depolama için komutlar vererek geleneksel paket yakalama mekanizmalarını iyi bir şekilde tamamlayacaktır. Aksi halde devasa bir depolama altyapısına sahip olmak zorunda kalacaksınız.

250 Mbit/sn hızında çalışan bir ağ düşünelim. Tüm bu hacmi depolamak istiyorsanız, bir saniyelik trafik aktarımı için 31 MB, bir dakika için 1,8 GB, bir saat için 108 GB ve bir gün için 2,6 TB depolama alanına ihtiyacınız olacak. 10 Gbit/s bant genişliğine sahip bir ağdan günlük verileri depolamak için 108 TB depolama alanına ihtiyacınız olacaktır. Ancak bazı düzenleyiciler, güvenlik verilerinin yıllarca saklanmasını gerektirir... Akış analizinin uygulamanıza yardımcı olduğu isteğe bağlı kayıt, bu değerlerin büyüklük sırasına göre azaltılmasına yardımcı olur. Bu arada, kayıtlı ağ telemetri verilerinin hacminin ve tam veri yakalamanın oranı hakkında konuşursak, bu yaklaşık olarak 1 ila 500'dür. Yukarıda verilen aynı değerler için, tüm günlük trafiğin tam bir transkriptinin saklanması sırasıyla 5 ve 216 GB olacaktır (hatta normal bir flash sürücüye bile kaydedebilirsiniz).

Ham ağ verilerini analiz etmeye yönelik araçlar için, bu verileri yakalama yöntemi satıcıdan satıcıya neredeyse aynıysa, akış analizi durumunda durum farklıdır. Güvenlik bağlamında bilmeniz gereken farklılıklar olan akış protokolleri için çeşitli seçenekler vardır. En popüler olanı Cisco tarafından geliştirilen Netflow protokolüdür. Bu protokolün yetenekleri ve kaydedilen trafik bilgisi miktarı bakımından farklılık gösteren çeşitli versiyonları vardır. Mevcut sürüm, IPFIX olarak da bilinen endüstri standardı Netflow v9'un geliştirildiği dokuzuncu sürümdür (Netflow v10). Günümüzde çoğu ağ satıcısı ekipmanlarında Netflow veya IPFIX'i desteklemektedir. Ancak akış protokolleri için çeşitli başka seçenekler de vardır - sFlow, jFlow, cFlow, rFlow, NetStream, vb., bunlardan en popüler olanı sFlow'dur. Uygulama kolaylığı nedeniyle yerli ağ ekipmanı üreticileri tarafından en çok desteklenen bu türdür. Fiili bir standart haline gelen Netflow ile sFlow arasındaki temel farklar nelerdir? Birkaç önemli noktanın altını çizeceğim. İlk olarak Netflow, sFlow'daki sabit alanların aksine kullanıcı tarafından özelleştirilebilir alanlara sahiptir. İkincisi, ki bizim durumumuzdaki en önemli şey budur, sFlow örneklenmiş telemetri adı verilen verileri toplar; Netflow ve IPFIX için örneklenmemiş olanın aksine. Onların arasındaki fark ne?

Kitabı okumaya karar verdiğinizi hayal edin”Güvenlik Operasyon Merkezi: SOC'nizi Oluşturma, Çalıştırma ve Bakımını Yapma” meslektaşlarımdan - Gary McIntyre, Joseph Munitz ve Nadem Alfardan (kitabın bir kısmını bağlantıdan indirebilirsiniz). Hedefinize ulaşmak için üç seçeneğiniz var: kitabın tamamını okuyun, göz atın, her 10. veya 20. sayfada bir durun veya bir blogda veya SmartReading gibi bir hizmette önemli kavramların yeniden anlatımını bulmaya çalışın. Yani örneklenmemiş telemetri, ağ trafiğinin her "sayfasını" okuyor, yani her paket için meta verileri analiz ediyor. Örneklenmiş telemetri, seçilen örneklerin ihtiyacınız olanı içermesi umuduyla trafiğin seçici olarak incelenmesidir. Kanal hızına bağlı olarak, örneklenmiş telemetri her 64'üncü, 200'üncü, 500'üncü, 1000'inci, 2000'inci ve hatta 10000'inci pakette bir analiz için gönderilecektir.

Bilgi güvenliği izleme bağlamında bu, örneklenmiş telemetrinin DDoS saldırılarını tespit etmek, taramak ve kötü amaçlı kodları yaymak için çok uygun olduğu ancak analiz için gönderilen örnekte yer almayan atomik veya çoklu paket saldırılarını kaçırabileceği anlamına gelir. Örneklenmemiş telemetrinin bu tür dezavantajları yoktur. Bu sayede tespit edilen saldırıların menzili çok daha geniş oluyor. Ağ telemetri analiz araçları kullanılarak tespit edilebilecek olayların kısa bir listesini burada bulabilirsiniz.

Elbette, bazı açık kaynaklı Netflow analizörleri bunu yapmanıza izin vermeyecektir, çünkü ana görevi telemetriyi toplamak ve BT açısından temel analizleri yapmaktır. Bilgi güvenliği tehditlerini akışa dayalı olarak belirlemek için analiz cihazını, standart veya özel Netflow alanlarına dayalı olarak siber güvenlik sorunlarını tanımlayacak, standart verileri çeşitli Tehdit İstihbaratı kaynaklarından vb. harici verilerle zenginleştirecek çeşitli motorlar ve algoritmalarla donatmak gerekir. .

Bu nedenle, seçeneğiniz varsa Netflow veya IPFIX'i seçin. Ancak ekipmanınız yerli üreticiler gibi yalnızca sFlow ile çalışsa bile, bu durumda bile güvenlik bağlamında bundan yararlanabilirsiniz.

2019 yazında Rus ağ donanımı üreticilerinin sahip olduğu yetenekleri analiz ettim ve NSG, Polygon ve Craftway hariç hepsi sFlow'u (en azından Zelax, Natex, Eltex, QTech, Rusteleteh) desteklediklerini duyurdu.

Karşılaşacağınız bir sonraki soru, güvenlik amacıyla akış desteğinin nerede uygulanacağıdır? Aslında soru tamamen doğru sorulmadı. Modern ekipman neredeyse her zaman akış protokollerini destekler. Bu nedenle soruyu farklı bir şekilde yeniden formüle edeceğim: Güvenlik açısından telemetriyi toplamak en etkili nerededir? Cevap oldukça açık olacaktır - tüm trafiğin %100'ünü göreceğiniz, ana bilgisayarlar (MAC, VLAN, arayüz kimliği) hakkında ayrıntılı bilgiye sahip olacağınız, hatta ana bilgisayarlar arasındaki P2P trafiğini bile izleyebileceğiniz erişim düzeyinde. kötü amaçlı kodun taranması ve dağıtılması açısından kritik öneme sahiptir. Çekirdek düzeyde trafiğin bir kısmını göremeyebilirsiniz ancak çevre düzeyinde tüm ağ trafiğinizin dörtte birini göreceksiniz. Ancak herhangi bir nedenle ağınızda, saldırganların çevreyi atlamadan "girip çıkmasına" izin veren yabancı cihazlar varsa, o zaman telemetriyi buradan analiz etmek size hiçbir şey sağlamayacaktır. Bu nedenle maksimum kapsam için erişim düzeyinde telemetri toplamanın etkinleştirilmesi önerilir. Aynı zamanda, sanallaştırmadan veya konteynerlerden bahsediyor olsak bile, modern sanal anahtarlarda akış desteğinin de sıklıkla bulunduğunu ve oradaki trafiği de kontrol etmenize olanak sağladığını belirtmekte fayda var.

Ancak konuyu gündeme getirdiğim için şu soruyu yanıtlamam gerekiyor: Peki ya fiziksel veya sanal ekipman akış protokollerini desteklemiyorsa? Yoksa dahil edilmesi yasak mı (örneğin, güvenilirliği sağlamak için endüstriyel segmentlerde)? Yoksa onu açmak yüksek CPU yüküne mi yol açıyor (bu durum eski donanımlarda oluyor)? Bu sorunu çözmek için, trafiği kendi içinden geçiren ve onu akış biçiminde toplama modülüne yayınlayan, esasen sıradan ayırıcılar olan özel sanal sensörler (akış sensörleri) vardır. Doğru, bu durumda paket yakalama araçlarıyla ilgili olarak yukarıda bahsettiğimiz tüm sorunları yaşıyoruz. Yani akış analizi teknolojisinin yalnızca avantajlarını değil aynı zamanda sınırlamalarını da anlamanız gerekir.

Akış analizi araçlarından bahsederken unutulmaması gereken bir diğer nokta. Güvenlik olaylarını oluşturmanın geleneksel araçlarıyla ilgili olarak EPS metriğini (saniye başına olay) kullanırsak, bu gösterge telemetri analizi için geçerli değildir; onun yerini FPS (saniyedeki akış) alır. EPS'de olduğu gibi önceden hesaplanamaz, ancak belirli bir cihazın görevine bağlı olarak oluşturduğu yaklaşık iş parçacığı sayısını tahmin edebilirsiniz. İnternette farklı türdeki kurumsal cihazlar ve koşullar için yaklaşık değerler içeren tablolar bulabilirsiniz; bu, analiz araçları için hangi lisanslara ihtiyacınız olduğunu ve bunların mimarisinin ne olacağını tahmin etmenize olanak tanır. Gerçek şu ki, IDS sensörü "çekebileceği" belirli bir bant genişliği ile sınırlıdır ve akış toplayıcının anlaşılması gereken kendi sınırlamaları vardır. Bu nedenle, büyük, coğrafi olarak dağıtılmış ağlarda genellikle birden fazla toplayıcı bulunur. tarif ettiğimde Ağın Cisco içinde nasıl izlendiği, Toplayıcılarımızın sayısını zaten verdim - bunlardan 21 tane var ve bu, beş kıtaya dağılmış ve yaklaşık yarım milyon aktif cihazdan oluşan bir ağ içindir).

Netflow izleme sistemi olarak kendi çözümümüzü kullanıyoruz Cisco Gizli İzlemeözellikle güvenlik sorunlarını çözmeye odaklanmıştır. Anormal, şüpheli ve açıkça kötü niyetli etkinlikleri tespit etmek için birçok yerleşik motora sahiptir; bu, kripto madenciliğinden bilgi sızıntılarına, kötü amaçlı kodların yayılmasından dolandırıcılığa kadar çok çeşitli farklı tehditleri tespit etmenize olanak tanır. Çoğu akış analizörü gibi Stealthwatch da üç seviyeli bir şemaya göre üretilmiştir (jeneratör - toplayıcı - analizör), ancak söz konusu materyal bağlamında önemli olan bir dizi ilginç özellik ile desteklenmiştir. İlk olarak, daha sonra derinlemesine araştırma ve analiz için seçilen ağ oturumlarını kaydetmenize olanak tanıyan paket yakalama çözümleriyle (Cisco Security Packet analyzer gibi) bütünleşir. İkinci olarak, özellikle güvenlik görevlerini genişletmek için, uç düğümlerdeki (sunucular, iş istasyonları vb.) uygulamaların etkinliğini telemetriye "yayınlamanıza" ve daha fazla analiz için toplayıcıya aktarmanıza olanak tanıyan özel bir nvzFlow protokolü geliştirdik. Stealthwatch orijinal sürümünde ağ düzeyinde herhangi bir akış protokolüyle (sFlow, rFlow, Netflow, IPFIX, cFlow, jFlow, NetStream) çalışıyorsa, nvzFlow desteği düğüm düzeyinde de veri korelasyonuna izin verir. tüm sistemin verimliliğini arttırır ve geleneksel ağ akış analizörlerine göre daha fazla saldırı görür.

Güvenlik açısından Netflow analiz sistemlerinden bahsederken pazarın Cisco'nun tek bir çözümüyle sınırlı olmadığı açıktır. Hem ticari hem de ücretsiz veya paylaşılan yazılım çözümlerini kullanabilirsiniz. Rakiplerin çözümlerini Cisco blogunda örnek olarak göstermem oldukça garip, bu yüzden ağ telemetrisinin, adı benzer ancak yine de farklı iki popüler araç olan SiLK ve ELK kullanılarak nasıl analiz edilebileceği hakkında birkaç kelime söyleyeceğim.

SiLK, Amerikan CERT/CC tarafından geliştirilen ve bugünkü makale bağlamında Netflow'u (5. ve 9., en popüler sürümler) IPFIX'i destekleyen trafik analizi için bir dizi araçtır (İnternet Düzeyinde Bilgi Sistemi). ve sFlow ve ağ telemetrisinde yetkisiz eylemlerin işaretlerini tespit etmek amacıyla çeşitli işlemler gerçekleştirmek için çeşitli yardımcı programların (rwfilter, rwcount, rwflowpack vb.) kullanılması. Fakat dikkat edilmesi gereken birkaç önemli nokta var. SiLK, aşağıdaki gibi komutlar girerek çevrimiçi analiz gerçekleştiren bir komut satırı aracıdır (200 bayttan büyük ICMP paketlerinin tespiti):

rwfilter --flowtypes=all/all --proto=1 --bytes-per-packet=200- --pass=stdout | rwrwcut --fields=sIP,dIP,iType,iCode --num-recs=15

pek rahat değil. iSiLK GUI'yi kullanabilirsiniz, ancak hayatınızı çok kolaylaştırmaz, yalnızca görselleştirme işlevini çözer ve analistin yerini almaz. Ve bu ikinci nokta. Halihazırda sağlam bir analitik temele, anormallik tespit algoritmalarına, ilgili iş akışına vb. sahip olan ticari çözümlerin aksine, SiLK söz konusu olduğunda tüm bunları kendiniz yapmak zorunda kalacaksınız ve bu da, halihazırda hazır olanlardan biraz farklı yeterlilikler gerektirecektir. kullanılacak araçlar. Bu ne iyi ne de kötü; bu, ne yapacağınızı bildiğinizi varsayan hemen hemen tüm ücretsiz araçların bir özelliğidir ve yalnızca bu konuda size yardımcı olacaktır (ticari araçlar kullanıcılarının yeterliliklerine daha az bağımlıdır, ancak aynı zamanda analistlerin en azından ağ araştırmaları ve izlemenin temellerini anladıkları). Ama SiLK'ye dönelim. Analistin bununla çalışma döngüsü şöyle görünür:

Bir hipotezin formüle edilmesi. Ağ telemetrisinde ne arayacağımızı anlamalı, belirli anormallikleri veya tehditleri tanımlayacağımız benzersiz özellikleri bilmeliyiz.
Bir model oluşturmak. Bir hipotez formüle ettikten sonra onu SiLK'de bulunmayan aynı Python, kabuk veya diğer araçları kullanarak programlıyoruz.
Test yapmak. Şimdi 'rw', 'set', 'bag' ile başlayan SiLK araçlarını kullanarak doğrulanan veya reddedilen hipotezimizin doğruluğunu kontrol etme sırası geldi.
Gerçek verilerin analizi. Endüstriyel operasyonda SiLK, bir şeyi tanımlamamıza yardımcı olur ve analistin "Beklediğimizi bulduk mu?", "Bu hipotezimize uyuyor mu?", "Yanlış pozitiflerin sayısı nasıl azaltılır?", "Nasıl yapılır?" gibi soruları yanıtlaması gerekir. Tanınma düzeyini artırmak için? » ve benzeri.
Gelişim. Son aşamada, daha önce yapılanları iyileştiriyoruz - şablonlar oluşturuyoruz, kodu geliştirip optimize ediyoruz, hipotezi yeniden formüle edip açıklığa kavuşturuyoruz vb.

Bu döngü aynı zamanda Cisco Stealthwatch için de geçerli olacak; yalnızca sonuncusu bu beş adımı maksimuma otomatikleştirerek analist hatalarının sayısını azaltıyor ve olay tespitinin verimliliğini artırıyor. Örneğin, SiLK'de elle yazılmış komut dosyalarını kullanarak kötü amaçlı IP'lere ilişkin harici verilerle ağ istatistiklerini zenginleştirebilirsiniz ve Cisco Stealthwatch'ta bu, ağ trafiğinin kara listedeki IP adresleriyle etkileşimler içermesi durumunda anında alarm görüntüleyen yerleşik bir işlevdir.

Akış analizi yazılımının "ücretli" piramidinde daha yukarılara çıkarsanız, tamamen ücretsiz SiLK'den sonra üç temel bileşenden oluşan bir paylaşımlı ELK olacaktır: Elasticsearch (indeksleme, arama ve veri analizi), Logstash (veri girişi/çıkışı). ) ve Kibana (görselleştirme). Her şeyi kendinizin yazmanız gereken SiLK'den farklı olarak ELK'de, ağ telemetrisinin analizini otomatikleştiren birçok hazır kütüphane/modül (bazıları ücretli, bazıları değil) zaten bulunmaktadır. Örneğin, Logstash'taki GeoIP filtresi, izlenen IP adreslerini coğrafi konumlarıyla ilişkilendirmenize olanak tanır (Stealthwatch'ta bu yerleşik özellik vardır).

ELK ayrıca bu izleme çözümünün eksik bileşenlerini tamamlayan oldukça geniş bir topluluğa da sahip. Örneğin Netflow, IPFIX ve sFlow ile çalışmak için modülü kullanabilirsiniz. elastik akışYalnızca Netflow'u destekleyen Logstash Netflow Modülünden memnun değilseniz.

ELK, akışı toplama ve içinde arama yapma konusunda daha fazla verimlilik sağlarken, şu anda ağ telemetrisindeki anormallikleri ve tehditleri tespit etmeye yönelik zengin yerleşik analitiklerden yoksundur. Yani, yukarıda açıklanan yaşam döngüsünün ardından, ihlal modellerini bağımsız olarak tanımlamanız ve ardından onu savaş sisteminde kullanmanız gerekecektir (orada yerleşik modeller yoktur).

Elbette, ağ telemetrisindeki anormallikleri tespit etmek için bazı modeller içeren ELK için daha karmaşık uzantılar var, ancak bu tür uzantılar paraya mal oluyor ve burada soru, oyunun muma değip değmeyeceğidir - benzer bir modeli kendiniz yazın, satın alın izleme aracınız için uygulama yapın veya Ağ Trafiği Analizi sınıfının hazır çözümünü satın alın.

Genel olarak, para harcamanın ve ağ telemetrisindeki anormallikleri ve tehditleri izlemek için hazır bir çözüm satın almanın (örneğin, Cisco Stealthwatch) veya bunu kendiniz çözüp aynısını özelleştirmenin daha iyi olduğu tartışmasına girmek istemiyorum. Her yeni tehdit için SiLK, ELK veya nfdump veya OSU Akış Araçları (son ikisinden bahsediyorum) ben söyledim son kez)? Herkes kendisi için seçim yapar ve herkesin iki seçenekten herhangi birini seçmek için kendi nedenleri vardır. Ağ telemetrisinin, iç altyapınızın ağ güvenliğini sağlamada çok önemli bir araç olduğunu ve medyada “lakaplarıyla adı geçen şirketler listesine girmemek için bunu ihmal etmemeniz gerektiğini” göstermek istedim. hacklendi”, “bilgi güvenliği gerekliliklerine uymadı” “, “kendi verilerinin ve müşteri verilerinin güvenliğini düşünmediler.”

Özetlemek gerekirse, iç altyapınızın bilgi güvenliği izlemesini oluştururken takip etmeniz gereken temel ipuçlarını sıralamak istiyorum:

Kendinizi sadece çevreyle sınırlamayın! Ağ altyapısını yalnızca trafiği A noktasından B noktasına taşımak için değil, aynı zamanda siber güvenlik sorunlarını çözmek için de kullanın (ve seçin).
Ağ ekipmanınızdaki mevcut bilgi güvenliği izleme mekanizmalarını inceleyin ve bunları kullanın.
Dahili izleme için telemetri analizini tercih edin - bu, ağ paketlerini yakalarken ve tüm bilgi güvenliği olaylarını depolamak için yerden tasarruf ederken imkansız olanı yaparken, tüm ağ bilgi güvenliği olaylarının %80-90'ına kadar tespit etmenize olanak tanır.
Akışları izlemek için Netflow v9 veya IPFIX'i kullanın; bunlar güvenlik bağlamında daha fazla bilgi sağlar ve yalnızca IPv4'ü değil aynı zamanda IPv6, MPLS vb.'yi de izlemenize olanak tanır.
Örneklenmemiş bir akış protokolü kullanın; tehditlerin tespit edilmesi için daha fazla bilgi sağlar. Örneğin Netflow veya IPFIX.
Ağ ekipmanınızdaki yükü kontrol edin; akış protokolünü de kaldıramayabilir. Daha sonra sanal sensörleri veya Netflow Generation Appliance'ı kullanmayı düşünün.
Kontrolü öncelikle erişim düzeyinde uygulayın - bu size tüm trafiğin% 100'ünü görme fırsatı verecektir.
Başka seçeneğiniz yoksa ve Rus ağ ekipmanı kullanıyorsanız, akış protokollerini destekleyen veya SPAN/RSPAN bağlantı noktalarına sahip olanı seçin.
Uçlardaki izinsiz giriş/saldırı tespit/önleme sistemlerini ve dahili ağdaki (bulutlar dahil) akış analizi sistemlerini birleştirin.

Son ipucuna gelince, daha önce verdiğim bir örneği vermek istiyorum. Daha önce Cisco bilgi güvenliği hizmetinin neredeyse tamamen bilgi güvenliği izleme sistemini izinsiz giriş tespit sistemleri ve imza yöntemleri temelinde oluşturduğunu, şimdi bunların olayların yalnızca %20'sini oluşturduğunu görüyorsunuz. Diğer bir %20 ise akış analiz sistemlerine düşüyor, bu da bu çözümlerin bir heves değil, modern bir işletmenin bilgi güvenliği hizmetleri faaliyetlerinde gerçek bir araç olduğunu gösteriyor. Üstelik bunların uygulanması için en önemli şeye sahipsiniz - ağ altyapısı, ağa bilgi güvenliği izleme fonksiyonları atanarak daha fazla korunabilecek yatırımlar.

Ağ akışlarında tespit edilen anormalliklere veya tehditlere müdahale konusuna özellikle değinmedim ancak izlemenin yalnızca tehdidin tespit edilmesiyle bitmemesi gerektiğinin zaten açık olduğunu düşünüyorum. Bunu bir yanıt takip etmeli ve tercihen otomatik veya otomatik modda olmalıdır. Ancak bu ayrı bir makalenin konusu.