Linux üzerinde Netfilter ve Suricata'yı uygulamaya yönelik eksiksiz kılavuz

Informatec Dijital » Ücretsiz Destekler » Linux üzerinde Netfilter ve Suricata'yı uygulamaya yönelik eksiksiz kılavuz

GNU/Linux ( güvenlik ve gizlilik için en iyi Linux dağıtımları ) üzerinde ağlarla çalışıyorsanız ve tipik statik güvenlik duvarının ötesine geçmekle ilgileniyorsanız, muhtemelen Netfilter, NFQUEUE ve Suricata'yı birleştirerek, tescilli donanıma servet harcamadan gerçekten esnek bir IDS/IPS oluşturmanın nasıl mümkün olduğunu merak ediyorsunuzdur. Bu makalede tam olarak bu alanı ele alacağız; düşük seviyeli unsurları (çekirdek, kuyruklar, C) yüksek seviyeli araçlarla (Suricata, kurallar, MySQL, Memcached, pfSense) birleştireceğiz.

Temel fikir oldukça güçlü: Çekirdeğin ( Linux çekirdeğini nasıl optimize edeceğinize bakın ) paketleri kullanıcı alanına sıraya koyabilmesi ve özel bir programın bunlarla ne yapacağına karar vermesine izin vermesi gerçeğinden yararlanmak. Bu, trafik filtreleme (gelişmiş güvenlik duvarı, IPS), dinamik yönlendirme veya iş mantığını entegre etme (veritabanları, önbellekler, web uygulaması saldırı tespiti, VoIP vb.) için kullanılabilir. Ve Suricata'yı çoklu işlem IDS/IPS motoru olarak eklersek, laboratuvarlardan yüksek trafikli veri merkezlerine kadar uzanan ortamlar için çok sağlam bir kombinasyon elde ederiz.

NFQUEUE ve Netfilter: Güvenlik duvarını kullanıcı alanına yükseltmek

Tipik bir GNU/Linux sisteminde, Netfilter/iptables (veya nftables) kuralları genellikle tamamen çekirdek alanında bulunan statik politikalar olarak kullanılır . Ön uçlar ve cihazlar (Netfilter veya BSD'nin Paket Filtresi tabanlı birçok çözüm dahil) yapılandırmayı metin, XML veya SQLite dosyalarında saklar ve bir şey değiştiğinde kuralları yeniden oluşturup yeniden yükler. Bu esnektir, ancak mantık, küçük dinamik ayarlamalarla (saniye başına bağlantı sınırları, bağlantı izleme, ülke eşleştirme, varsa katman 7, vb.) güvenlik duvarının bir tür anlık görüntüsü olarak kalır.

NFQUEUE'nun önerdiği şey çığır açıcı: çekirdeğin her zaman nihai kararı vermesi yerine, bu kararı bir kullanıcı işlemine devredebiliriz . Çekirdek paketi numaralı bir kuyruğa alır ve libnetfilter_queue kütüphanesini kullanan bir uygulama onu alır, analiz eder ve bir karar döndürür: kabul et, reddet veya hatta politika yönlendirmesi için işaretle. Bu, güvenlik duvarının üzerinde C, Python veya Perl ile yazılmış programlanabilir bir "hakim"e sahip olmak gibidir.

Bunun güzelliği, programımızın kelimenin tam anlamıyla istediğimiz her şeyi yapabilmesidir: çekirdeğe yanıt vermeden önce /dev/urandom'u, bir veritabanını, bir web servisini, dağıtılmış bir önbelleği veya karmaşık bir algoritmayı sorgulayabilir . Mimari açıdan bakıldığında, güvenlik duvarı basit bir statik kurallar kümesi olmaktan çıkıp, Netfilter, kuyruklar ve kullanıcı uygulamalarının bir yapbozun parçaları gibi bir araya geldiği bir işlem hattı haline gelir.

NFQUEUE iki kısımdan oluşur: paketleri belirli bir kuyruğa gönderen iptables'deki NFQUEUE hedefi ve bu paketleri okuyup bir karar vermenizi sağlayan libnetfilter_queue kullanıcı kütüphanesi . Bu, tcpdump gibi basit bir paket analiz aracı değildir: burada paketin izleyeceği yolu doğrudan belirleme olanağımız vardır.

NFQUEUE ile temel iptables yapılandırması

iptables açısından bakıldığında, NFQUEUE kullanımı oldukça basittir: belirli kriterleri (kaynak/hedef IP, portlar, durumlar, GeoIP veya layer7 gibi ek modüller vb.) karşılayan paketleri kuyruğa göndermek için ilgilendiğiniz zincire bir kural eklersiniz .

Örneğin, sunucuya gelen tüm ping'leri NFQUEUE'ye göndermek istiyorsak:

iptables -I INPUT -p icmp -j NFQUEUE

Bu, gelen ICMP paketlerini (aksi belirtilmedikçe) 0 numaralı kuyruğa gönderir. `--queue-num 3` gibi bir ifadeyle başka bir kuyruk da belirtebiliriz . Kuralları sayaçlarla listelerken (`iptables -L -n -v -x`), sayaçların arttığını ve paketlerin kuyruğa alındığını göreceğiz . Önemli bir ayrıntı: Kuyrukta paketler varsa ve hiçbir kullanıcı işlemi bunları alıp işlemiyorsa, varsayılan davranış bunları reddetmektir; bu nedenle, tasarım gereği, bir uygulama hatası trafiğin engellenmesine neden olur.

libnetfilter_queue'ye karşı programlama: C dilinde "hello world"

Kullanıcı alanından kuyruğa katılmak için libnetfilter_queue kütüphanesi kullanılır (bu da libnfnetlink'e bağlıdır). Debian gibi dağıtımlarda, geliştirme paketlerini kurmanız yeterlidir:

apt-get install libnfnetlink-dev libnetfilter-queue-dev gcc

Her zaman paket kabul eden minimal bir programın iskeleti birkaç çok açık adımdan oluşur: kütüphaneyi açın, mevcut işleyicileri devre dışı bırakın, AF_INET protokolüne bağlanın, geri çağırma fonksiyonuyla kuyruğu oluşturun, kopyalama modunu tanımlayın ve bir alma döngüsüne girin . Geri çağırma fonksiyonu, kuyruğa alınmış her paket için yürütülür, kimliği çıkarır ve sonucu döndürür.

Pratikte, akış şu şekildedir: `nfq_open` ile tanıtıcıyı alın, `nfq_unbind_pf` ile temizleyin, `nfq_bind_pf` ile AF_INET ile ilişkilendirin, `nfq_create_queue` ile geri çağırmayı 0 numaralı kuyruğa kaydedin, `nfq_set_mode` ile meta verileri mi yoksa tüm paketi mi istediğimizi belirtin, tanımlayıcı üzerinde `recv()` ile bir döngü yapın ve `nfq_handle_packet` ile her paketi işleyin . Çıkışta, kuyruk `nfq_destroy_queue` ile yok edilir ve tanıtıcı `nfq_close` ile kapatılır.

Bu tür bir "hello world" örneği, NFQUEUE'nun etkisinin net bir şekilde ölçülmesini sağlar. Örneği şöyle bir şeyle derlersek:

gcc -o nftest code.c -lnfnetlink -lnetfilter_queue

Eğer iperf'ten gelen trafiği kuyruğa alırsak (örneğin, INPUT ve OUTPUT'ta TCP 5001 portu), paketleri kabul eden kodun gigabit ağda performansı neredeyse hiç etkilemediğini göreceğiz . Ancak önemli bir ayrıntı var: geri çağırma fonksiyonunda bilgi yazdırmak (printf, fflush, vb.), iperf'i ekran hata ayıklamasıyla ve ekran hata ayıklaması olmadan karşılaştırdığımızda görülebileceği gibi, verimliliği önemli ölçüde düşürüyor.

Gelişmiş NFQUEUE seçenekleri: atlama, dengeleme ve açık kalma.

NFQUEUE, kuyrukların varsayılan davranışını değiştiren ve kullanıcı uygulaması hatası veya kuyruk dolmasının nasıl ele alınacağını etkiledikleri için üretim veya yüksek performanslı bir ortama girmeden önce bilinmesi gereken birkaç ilginç iptables seçeneğini içerir.

`--queue-bypass` komutu , kuyrukta hiçbir işlem dinlemiyorsa paketlerin düşürülmemesini, bunun yerine iptables zincirindeki bir sonraki adıma iletilmesini sağlar. Bu, kullanıcı hizmeti kullanılamaz olduğunda sistemin "açık kalmasını" istiyorsanız yararlı olabilir, ancak güvenlik açısından iki ucu keskin bir kılıçtır.

`--queue-balance` seçeneği, paketleri bir dizi kuyruğa (örneğin, 0'dan 3'e kadar) dağıtmanıza ve ardından her kuyruktan birden fazla bağımsız işlem veya iş parçacığının paket tüketmesine olanak tanır . Netfilter'ın kodu, aynı akıştan gelen paketlerin her zaman aynı kuyruğa düşmesini sağlar; bu da karar mantığında tutarlılığı korumayı büyük ölçüde kolaylaştırır.

Ayrıca, kullanıcı işlemi çok yavaş çalıştığı için kuyruk dolduğunda ne olacağını kontrol eden `--fail-open` modu da var . Bunu etkinleştirmek, çekirdeğin paketleri düşürmek yerine doğrudan kabul etmesini sağlayarak büyük trafik aksamalarını önler. Yine de bu bir güvenlik sorunu olabilir, çünkü duruma göre karar vermek istiyorsak, karar paketlerini kaybetmek bu amaca ulaşamamak anlamına gelir.

Kuyruklarda neler olup bittiğini izlemek için Netfilter, komut dosyaları veya izleme araçları aracılığıyla kolayca sorgulanabilen /proc/net/netfilter/nfnetlink_queue adlı sözde dosya sisteminde bilgi sunar.

İş mantığını entegre etme: Memcached ve MySQL ile test etme

"Merhaba dünya" süreci kontrol altına alındıktan sonra, bir sonraki doğal adım, geri çağırma işlevini harici sistemlere yapılan çağrılarla zenginleştirmektir . Tipik bir deney, kaynak IP adresinin MySQL veritabanı veya Memcached önbelleği gibi herhangi bir arka uçta görünüp görünmemesine bağlı olarak bir paketi kabul edip etmeme kararını içerir.

Memcached durumunda, servis kurulur (apt-get install memcached) ve örneğin authorized adlı bir anahtar , ilgilendiğimiz IP adresiyle yüklenir. Bunu basit bir echo ve netcat komutuyla yapabilir ve ardından bir get komutuyla değerin doğru şekilde saklandığını doğrulayabiliriz. Buradan itibaren, NFQUEUE programı, paket kimliğini almanın yanı sıra, NFQNL_COPY_PACKET kullanarak tüm paketi alır , IP başlığını (struct iphdr) çıkarır ve kaynak adresini inet_ntop ile bir dizeye dönüştürür.

Her pakette bağlantı açmak için zaman kaybını önlemek amacıyla, Memcached bağlantısı yalnızca ana metotta (memcached_create, memcached_server_list_append, memcached_server_push) bir kez başlatılır ve işleyici global değişkenlerde saklanır. Geri çağrı fonksiyonunda, istenen anahtar ile memcached_get çağrılır, kaynak IP adresi alınan değerle karşılaştırılır ve eşleşirse NF_ACCEPT, aksi takdirde NF_DROP döndürülür. Anahtar mevcut değilse veya bir hata varsa, paket ihtiyatlı bir politika olarak düşürülür.

iperf kullanılarak, bu strateji gigabit ağda verimi yaklaşık 140 Mbit/s'ye düşürüyor ve kuyrukta kayıplar yaşanmaya başladığı gözlemleniyor (örneğin, kodun içindeki sembollerle gösteriliyor). Başka bir deyişle, her paket için bir önbellek hizmetini çağırmak bile önemli bir maliyete yol açıyor, ancak optimize edilirse orta düzeydeki trafik hacimleri için uygulanabilir kalıyor.

MySQL ile yaklaşım benzer ancak daha karmaşıktır: sunucu ve istemci kütüphaneleri kurulur, authorized(ip varchar(50)) adlı basit bir tablo içeren bir veritabanı (örneğin, nfqueue) oluşturulur ve izin verilen IP adresi eklenir. Programda, başlangıçta `mysql_init` ve `mysql_real_connect` çalıştırılır ve geri çağrı fonksiyonunda `select * from authorized where ip like 'xxxx'` gibi bir sorgu oluşturulur. Sorgu başarıyla yürütülür ve bir satır bulunursa, paket kabul edilir; aksi takdirde, reddedilir.

MySQL sorgu önbelleklemesi etkinleştirildiğinde, testler yaklaşık 188 Mbit/s hız elde ederken, sorgu önbelleklemesi devre dışı bırakıldığında bu hız 103 Mbit/s'ye düşmektedir . Bu rakamlar gigabit seviyesinden çok uzak olsa da, en basit yaklaşımla (tek iş parçacıklı, optimizasyonsuz) bile , veritabanı tabanlı veya önbellekleme tabanlı kararlar kullanılarak saygın trafik hacimlerinin işlenebileceğini göstermektedir.

Performans, çoklu iş parçacığı kullanımı ve CPU kullanımı

iperf, Memcached ve MySQL ile yapılan testler, performans sınırının NFQUEUE'nun kendisinden ziyade kullanıcı alanında eklediğimiz mantık ve bunu nasıl uyguladığımızdan kaynaklandığını açıkça göstermektedir. Yalnızca NF_ACCEPT döndüren bir yürütülebilir dosya, neredeyse bir gigabit hızına sorunsuz bir şekilde ulaşır; ancak G/Ç veya ağ çağrıları eklediğimiz anda verimlilik düşer ve NFQUEUE makinesinin, Memcached daemon'unun veya MySQL'in CPU'su sınırlarına kadar zorlanır.

Mimari açıdan bakıldığında, bunun iki sonucu vardır. Bir yandan, her çağrının gerçek maliyetleri dikkate alındığı takdirde, önemli trafik hacimleri için güvenlik duvarı kararlarını kullanıcı uygulamalarına devretmenin tamamen uygulanabilir olduğunu doğrular. Öte yandan, platformun maksimum yeteneklerine yaklaşmak için çoklu iş parçacığı veya çoklu işlemenin dikkate alınması gerektiğini gösterir . NFQUEUE, trafiğin birden fazla kuyruğa dağıtılmasına olanak tanır; uygulamamızın her biri farklı bir kuyruğu dinleyen birkaç kopyasını başlatabilir ve pthreads veya büyük çatallanmaların zahmeti olmadan birden fazla çekirdeği kullanabiliriz.

Bir diğer bariz optimizasyon, NFQUEUE'den geçen trafiği sınırlandırmak olacaktır . Testlerde, tüm iperf akışı kuyruğa alınıyordu, ancak gerçek dünya senaryosunda, yalnızca NEW durumundaki paketleri kuyruğa alabilir, ESTABLISHED/RELATED paketlerinin geçmesine izin verebilir ve pahalı mantığı oturum açma işlemleri veya şüpheli kalıplar için saklayabiliriz.

Sonuç olarak, CPU kullanımı ve iş parçacığı tasarımı çok önemlidir: eğer kullanıcı işlemi yetersiz kalırsa, kuyruk dolar ve başarısız açma veya kabul etmeme gibi yöntemlere başvurmak zorunda kalırız; bu da bu yaklaşımın hedeflediği hassas kontrolün bir kısmını kaybetmemize neden olur.

Netfilter marka kimliğiyle dinamik yönlendirme

NFQUEUE, yalnızca "kabul et" veya "at" demekle sınırlı değildir. Ayrıca , paketlere Netfilter (fwmark) bayrakları uygulamak ve bunları ip rule ve iproute2 ile birleştirerek son derece esnek, neredeyse hafif VRF tarzı politik yönlendirme şemaları oluşturmak için de kullanılabilir .

Genel olarak prosedür şu şekilde olacaktır: /etc/iproute2/rt_tables dosyasında , örneğin slow ve fast gibi birkaç yönlendirme tablosu tanımlayın; her tabloya farklı bir varsayılan rota atayın (biri fiber üzerinden, diğeri daha sınırlı bir bağlantı üzerinden); fwmark 1 olan paketlerin fast tablosuna, fwmark 2 olanların slow tablosuna vb. gitmesini belirtmek için ip rule kullanın; ve son olarak, kararı döndürmeden önce paketleri uygun şekilde işaretlemek için NFQUEUE kullanın.

Geri çağrıdan bir karar belirlemek için, `nfq_set_verdict2` kullanılır ; bu, `nfq_set_verdict`'e benzer ancak `ip rule`'ın daha sonra göreceği bir karar değeri belirlemenize olanak tanır. Tüm bunları birleştirerek, rastgele kriterlere göre yönlendirmeye karar veren bir IP yönlendirici oluşturabilirsiniz: çift/tek paket boyutu gibi absürt şeylerden, trafik tahmin algoritmaları, sosyal medya olayları veya izleme sistemlerinden gelen sinyaller gibi harici girdilere kadar.

Sonuç olarak, çekirdeğin paketleri normal hızda iletmeye devam ettiği, ancak her akışın izleyeceği kesin yolun , statik kurallara dokunmadan gerçek zamanlı olarak fikrini değiştirebilen harici yazılımlara devredildiği bir sistem ortaya çıkar.

NFQUEUE ve Suricata: GNU/Linux'ta Yüksek Seviyeli IPS

Yukarıdakilerin tümü C dilinde elle programlanabilir, ancak saldırı tespiti ve derin paket incelemesi söz konusu olduğunda, genellikle olgun bir IDS/IPS motoruna güvenmek mantıklı seçenektir . İşte burada Suricata devreye giriyor; tam olarak Snort'a çoklu işlemci alternatifi olarak doğmuş, başından itibaren IPS yeteneklerine sahip ve günümüzde mevcut olan birçok CPU çekirdeğinden yararlanmaya odaklanmış bir platformdur.

Suricata sıfırdan yazılmış ve GPLv2 lisansı altında dağıtılmaktadır ; Açık Bilgi Güvenliği Vakfı (OISF) hem motoru hem de oldukça kapsamlı bir kural ve dokümantasyon ekosistemini sürdürmektedir. Tek iş parçacıklı bir çekirdeği miras alan ve üzerine yamalar eklenen Snort 2.x'in aksine, Suricata, farklı yük paylaşım stratejileriyle iş yükünü birden fazla iş parçacığına bölmek üzere tasarlanmıştır: yakalama, kod çözme, tespit ve çıktı.

İşlevsel düzeyde Suricata, IPv6 için yerel destek, katman 7 denetimi (HTP kütüphanesi aracılığıyla çok gelişmiş HTTP), portlardan bağımsız protokol tanıma , akış yeniden yapılandırma ve birden fazla TCP bağlantısı üzerinden yayılan bir saldırının farklı aşamalarını ilişkilendirmek için çok güçlü bir oturum değişkenleri sistemi (flowbits) sağlar.

Ek bir avantajı da Snort kurallarıyla uyumluluğu ve hem Sourcefire VRT hem de Emerging Threats imza setlerini (ücretsiz ET Open ve ticari ET Pro sürümleri) kullanabilmesidir. Ayrıca, SIEM'ler, ELK, Splunk ve diğer sistemlerle entegrasyon için olayları çok kullanışlı formatlarda (fast.log, eve.json'da JSON) dışa aktarır.

Linux'ta Suricata'yı IPS olarak kullanmak: yakalama modları ve NFQUEUE

GNU/Linux'ta Suricata, trafiğin nasıl yakalandığına bağlı olarak farklı modlarda çalışabilir: NFQUEUE, AF_PACKET, PF_RING, libpcap, NFLOG, IPFW, DAG, Napatech … Her birinin avantajları ve gereksinimleri vardır. Saf IPS seviyesinde en önemli ikisi NFQUEUE ve AF_PACKET'tir.

NFQ (NFQUEUE) modunda , akış daha önce açıklananla benzerdir: bir dizi iptables kuralı paketleri bir kuyruğa gönderir; kullanıcı alanında çalışan Suricata, bu kuyruktan okur, içeriği kurallarına göre inceler ve çekirdeğe bir sonuç döndürür: NF_ACCEPT, NF_DROP veya NF_REPEAT. Üçüncüsü, ek işaretler veya değişiklikler uygulandıktan sonra paketi aynı iptables tablosuna yeniden eklemek için kullanılabilir.

Bu mod, mevcut altyapılarda çok esnek ve uygulaması kolaydır , çünkü yalnızca belirli noktalardaki kuralları (örneğin, FORWARD, INPUT, OUTPUT) değiştirmeyi ve geri kalan her şeyi olduğu gibi bırakmayı gerektirir. Maliyeti, paketlerin NFQUEUE üzerinden yukarı ve aşağı iletilmesinin getirdiği ek yüktür ve hacim çok yüksekse veya kurallar kaynak yoğun ise yukarıda belirtilen etkiye sahiptir.

AF_PACKET modunda , Suricata ağ arayüzüne daha yakın çalışır ve paketleri AF_PACKET soketleri üzerinden kopyalar. Bu, çok daha hızlı bir sıfır kopyalama yaklaşımıdır , ancak sistemin iki arayüzlü bir ağ geçidi olarak işlev görmesini ve trafik engellemenin NIC'ler arasında yönlendirme seviyesinde gerçekleştirilmesini gerektirir: engellenecek paket, giriş arayüzünden çıkış arayüzüne iletilmez.

Her iki modda da Suricata, Netfilter ile birleştirilebilir, ancak NFQUEUE özellikle tüm iptables mantığını (politikalar, aralıklar, önceki kurallar) yeniden kullanmak ve yalnızca derinlemesine incelemek istediğimiz trafiği Suricata'ya göndermek istediğimiz senaryolarda çok iyi sonuç verir .

Suricata'nın kaynak kodundan temel kurulumu

Suricata'yı paket kullanmak yerine derlemeyi tercih edenler için, Debian/Ubuntu tipi dağıtımlarda süreç şu şekilde ilerler: önce derleme bağımlılıklarını (build-essential, libpcre, libpcap-dev, libnet-dev, libyaml-dev, zlib, libcap-ng-dev, libjansson-dev, vb.) kurmak, resmi web sitesinden tarball dosyasını indirmek ve ardından klasik ./configure, make, make install komutlarını çalıştırmak.

Yapılandırma aşamasında, komut dosyası hangi destek özelliklerinin etkinleştirildiğini gösterecektir: AF_PACKET evet/hayır, PF_RING, NFQUEUE evet/hayır, NFLOG, IPFW, libnss, libjansson, Prelude, PCRE JIT, Lua, GeoIP desteği vb. Bu modda çalışmak istiyorsak NFQUEUE'nun etkinleştirildiğini ve ilgilendiğimiz yakalama kütüphanesinin bulunduğunu doğrulamak önemlidir.

İkili dosyayı kurduktan sonra, varsayılan bir yapılandırmayı `/etc/suricata` dizinine dağıtmak için `make install-conf` komutunu ve bir dizi Gelişen Tehdit kuralını `/etc/suricata/rules` dizinine indirip yerleştirmek için `make install-rules` komutunu çalıştırabilirsiniz . Bu kurallar daha sonra `suricata-update` gibi araçlar kullanılarak güncellenebilir.

Red Hat/CentOS sistemlerinde mantık benzerdir; bağımlılıklar (libpcap-devel, pcre-devel, libnet-devel, libyaml-devel, jansson-devel, vb.) için yum veya dnf kullanılır ve ardından aynı adımlarla derleme yapılır. Performans nedenleriyle, bu yük boşaltma işlevleri IDS düzeyinde paketlerin görünürlüğünü etkileyebileceğinden, ethtool kullanarak yakalama arayüzünde LRO/GRO'yu devre dışı bırakmak da önerilir.

Suricata yapılandırması: YAML, değişkenler ve çoklu iş parçacığı kullanımı

Suricata'nın ana yapılandırması /etc/suricata/suricata.yaml dosyasında bulunur . Bu, oldukça okunaklı ve bolca yorum içeren bir YAML dosyasıdır; burada günlük yollarından kural kümelerine, hedef işletim sistemi politikalarından iş parçacığı parametrelerine kadar her şey tanımlanır.

Temel alanlardan biri , günlük dosyalarının nerede saklanacağını belirten `default-log-dir` alanıdır (varsayılan olarak `/var/log/suricata`). `vars` bölümünde, kurallarda kısaltma olarak kullanılan `HOME_NET`, `EXTERNAL_NET`, `HTTP_PORTS`, `SHELLCODE_PORTS` ve `SSH_PORTS` gibi değişkenler bulunur. `HOME_NET` genellikle korumak istediğimiz yerel ağ aralığıyla yapılandırılırken, `EXTERNAL_NET` genellikle `!HOME_NET` olarak tanımlanır.

Bir diğer önemli kısım ise , Suricata'ya hangi işletim sisteminin belirli IP aralıklarını çalıştırması gerektiğini söyleyen host-os-policy'dir . Bu , TCP'yi nasıl yeniden birleştireceğini veya belirli ağ yığını davranışlarını nasıl yorumlayacağını ayarlamasına olanak tanır ve yığınlar arasındaki farklılıklara (Windows ve Linux, vb.) dayalı protokollerden kaçınmayı zorlaştırır. Belirli aralıklar, Windows, Linux, BSD, Vista, Windows 2003 gibi kategorilere atanabilir.

Çoklu iş parçacığı kullanımıyla ilgili olarak, çoklu iş parçacığı bölümü, CPU yakınlığını ve algılama iş parçacığı sayısını hassas bir şekilde ayarlamanıza olanak tanır. Varsayılan olarak, `set-cpu-affinity` genellikle devre dışıdır; bu da sistem zamanlayıcısının iş parçacıklarını çekirdekler arasında dağıtmasına izin verir. `detect-thread-ratio` parametresi , kullanılabilir çekirdek başına kaç algılama iş parçacığı oluşturulacağını gösterir; 8 çekirdekli bir makinede `detect-thread-ratio: 1.5` ile Suricata, yakalama ve yönetim iş parçacıklarına ek olarak 12 algılama iş parçacığı oluşturacaktır.

Bu modelin tamamı, arka plan programı başlatıldığında çıktıya yansır: akış yöneticileri ve istatistik yöneticilerine ek olarak bir yakalama iş parçacığı (örneğin, pcap) ve birden fazla algılama iş parçacığı görünür. Bu çoklu işlem mimarisi, Suricata'nın 10/40 Gbit/s bağlantılarla karşılaştığında tek iş parçacıklı motorlardan çok daha iyi ölçeklenebilmesini sağlar .

Suricata'daki kurallar ve imza güncellemeleri

Suricata, saldırı modellerini, anormal davranışları ve protokol suistimalini tespit etmek için kural kümelerine dayanır. Snort formatındaki kuralları kabul etmenin yanı sıra , en yaygın ekosistem, mevcut tehditlere yönelik kurallar içeren Emerging Threats: ET Open (ücretsiz) ve ET Pro (ticari) ekosistemidir.

Birçok modern dağıtım , kural yönetimini basitleştiren `suricata-update` aracını içerir : kaynakları günceller, belirli sağlayıcıları etkinleştirir veya devre dışı bırakır ve imza setlerinin en son sürümlerini indirir. Tipik bir iş akışı, `suricata-update`'i (örneğin pip aracılığıyla) kurmak, ET Open'ı indirmek için ilk `suricata-update` komutunu çalıştırmak, `suricata-update list-sources` ile kaynakları listelemek, `ptresearch/attackdetection`, `oisf/trafficid` veya `sslbl/ssl-fp-blacklist` gibi ek kaynakları etkinleştirmek ve kural dosyasını yeniden oluşturmak için `suricata-update` komutunu tekrar çalıştırmak olacaktır.

Suricata.yaml dosyası, doğru kurallar yolunu gösterecek şekilde ayarlanır ve buradan itibaren Suricata , fast.log (hızlı, okunabilir metin) ve eve.json (çok eksiksiz bilgi içeren yapılandırılmış JSON) dosyalarına kaydedilecek uyarı olayları oluşturmaya başlar . Bu ikinci format, özellikle gösterge panolarını, korelasyon sistemlerini veya özel komut dosyalarını beslemek için kullanışlıdır.

İmzalara ek olarak, Suricata birden fazla protokol için kod çözücüler ve ayrıştırıcılar içerir ; bu da portlara olan bağımlılığını azaltır: HTTP trafiğini standart olmayan portlardan geçse bile tanımlayabilir, farklı portlar ve kapsülleme seviyeleri (karışık IPv4/IPv6 tünelleri dahil) üzerinden SSH, TLS, DNS vb. algılayabilir.

Pratik kullanım alanları: web saldırılarını tespit etmekten otomatik engellemeye kadar.

Barındırma ortamlarında veya veri merkezlerinde en çok istenen kullanım alanlarından biri, web uygulamalarındaki (örneğin WordPress ve eklentileri) güvenlik açıklarından yararlanma girişimlerini gerçek zamanlı olarak tespit etmek ve genellikle güvenlik duvarında kaynak IP adresini engelleyerek veya kara listeye alarak otomatik olarak tepki vermektir.

Güncellenmiş kurallarla desteklenen Suricata, URL'lere, parametrelere, HTTP yüklerine ve hatta bilinen güvenlik açıklarına uyan istek dizilerine karşı belirli saldırı modellerini tanıyabiliyor. IDS, bir anahtar bağlantı noktasından (SPAN) yansıtma yoluyla trafik alarak pasif modda çalışabilir, ancak bir IPS olarak hareket edip saldırıları engellemek için yönlendirme düzlemine entegre edilmesi gerekir.

İki yaygın yaklaşım vardır: IDS'yi çevrimiçi bir köprü olarak kurmak , böylece trafik fiziksel olarak makineden geçer (platforma bağlı olarak iptables, AF_PACKET veya PF kullanarak) veya topolojiyi olduğu gibi bırakmak ancak API, komut dosyaları veya NFQUEUE aracılığıyla merkezi güvenlik duvarındaki eylemlerle yansıtmayı birleştirmek . İlk yaklaşım, ağın "ortasına" başka bir unsur ekleme pahasına, tespit ve engelleme arasındaki gecikmeyi en aza indirir; ikincisi daha fazla esneklik ve dayanıklılık sunar, ancak orkestrasyona daha fazla karmaşıklık getirir.

Bir Saldırı Tespit Sistemi (IDS) için, savunmasız bir WordPress eklentisini istismar etme girişimini tespit etmek ve ardından, doğrudan veya ilişkili bir bileşen aracılığıyla, saldırganın IP adresini bir iptables kara listesine eklemek tamamen mümkündür. Bu, Suricata'nın JSON çıktısı ve iptables/nftables'ı çağıran komut dosyaları aracılığıyla veya mantığın bir kısmını NFQUEUE'ye devrederek yapılabilir; burada motorun kendisi veya ilişkili bir işlem, harici bir listenin güncellenmesini beklemeden anında karar verir.

Bu sayede, gerçekten önemli olan tehditlere (istismarlar, yükseltme girişimleri, çok agresif taramalar) odaklanabilir, temel port taramaları gibi birçok durumda kendi başlarına endişe verici olmayan arka plan gürültüsünü göz ardı edebilir veya sadece kaydedebilirsiniz.

PfSense üzerinde Suricata: Entegre IDS/IPS özellikli açık kaynaklı güvenlik duvarı.

Herkes Palo Alto gibi yüksek performanslı, tescilli bir güvenlik duvarını karşılayamaz veya satın almak istemez. Birçok ortamda, hem gelişmiş güvenlik duvarı ihtiyaçlarını (çoklu WAN, VLAN, VPN, NAT vb.) hem de IDS/IPS'yi kapsayan pfSense ve Suricata ile açık kaynaklı bir çözüm kurmak daha caziptir.

FreeBSD ve Packet Filter tabanlı PfSense, sanallaştırılmış ortamlarda (Proxmox, KVM vb.) özellikle iyi çalışır; ancak performans sorunlarını ve yük altında çökmeleri önlemek istiyorsanız, KVM makinelerinde Virtio yerine E1000 kartları kullanmanız önerilir (Netgate'in önerilerini uygulamadığınız sürece: Sistem > Gelişmiş > Ağ bölümünde donanım sağlama toplamı boşaltmasını devre dışı bırakın ve yeniden başlatın; ancak bunun çok yüksek yüklerde yeterli olmayabileceğini unutmayın).

Pfsense üzerinde Suricata kullanan bir laboratuvar için minimum donanım gereksinimleri mütevazı olabilir (1 adet 500 MHz CPU, 1 GB RAM, 4 GB disk), ancak ciddi kullanım için en az 2 CPU, 4 GB RAM ve 16 GB depolama alanı önerilir ; ayrıca birden fazla ağ arayüzüne (biri WAN için, diğeri LAN için, birden fazla WAN veya karmaşık VLAN'lar istiyorsanız daha fazlası) sahip olmanız da gerekir.

pfSense'in kurulumu oldukça hızlıdır: ISO dosyasından önyükleme yaparsınız, lisansı kabul edersiniz, kurulumu seçersiniz, dilinizi ve klavye düzeninizi seçersiniz, bölümlemeyi otomatik olarak bırakırsınız (tüm diski kullanacaksanız Otomatik UFS), ve birkaç dakika içinde sistem ilk önyükleme için hazır olur. Konsol, arayüz atama, yeniden başlatma, kabuk başlatma vb. için bir menü sunar.

Laboratuvarda, örneğin VirtualBox'ta, web arayüzüne WAN üzerinden (kullanıcı adı admin, parola pfsense) erişmek ve başlangıç ​​sihirbazını tamamlamak için konsoldan pfctl -d komutuyla Pfsense güvenlik duvarını geçici olarak devre dışı bırakmak yaygındır : genel veriler, NTP sunucuları, WAN yapılandırması (laboratuvarda genellikle DHCP yeterlidir), LAN, admin parolasının değiştirilmesi ve yapılandırmanın uygulanması.

Erişim istikrara kavuştuktan sonra, WAN güvenlik duvarında pfsense IP adresine herhangi bir kaynaktan HTTPS'ye izin veren bir kural oluşturabilir ve kuralları görsel olarak düzenlemek için açıklayıcı ayırıcılar ekleyebilirsiniz (örneğin, "Güvenlik Duvarı Erişimi"). Ayrıca, RFC1918 adresleriyle bir test ortamındaysanız, sürekli olarak `pfctl -d` komutunu kullanmak zorunda kalmamak için WAN'da özel ağları engelleme seçeneğini devre dışı bırakmanız önerilir.

pfSense üzerinde Suricata kurulumu ve genel bakış

pfSense temel kurulumu tamamlandıktan sonra, Suricata'yı yüklemek oldukça basittir: Sistem > Paket Yöneticisi > Kullanılabilir Paketler bölümüne gidin , Suricata'yı arayın ve paketi yükleyin. İşlem birkaç dosya indirir ve donanımınıza bağlı olarak biraz zaman alabilir, ancak web arayüzü üzerinden tam destek sağlanır.

Kurulum tamamlandıktan sonra, Hizmetler sekmesinde bir Suricata girişi görünür; burada arayüze göre (WAN, LAN, VLAN'lar vb.) örnekleri yapılandırabilir, hangi kural kümelerinin kullanılacağını seçebilir, IDS veya IPS modunu etkinleştirebilir ve performans ve günlük kaydı parametrelerini ayarlayabilirsiniz. Seçenek yelpazesi oldukça geniştir (sadece yapılandırma hakkında bile makaleler yazılabilecek kadar), ancak avantajı, Linux'ta manuel YAML düzenlemesi gerektiren birçok görevin burada formlar ve onay kutuları ile halledilmesidir.

Önemli not: Laboratuvar ortamında pfSense yönetimini doğrudan internete açmak cazip gelse de, üretim ortamında erişimi statik IP adresleriyle sınırlandırmak, uzaktan yönetim için VPN kullanmak ve web konsolunu her ne pahasına olursa olsun açıkta bırakmaktan kaçınmak çok önemlidir . pfSense çok esnektir, ancak aynı zamanda kritik bir unsur olarak da ele alınmalıdır.

pfSense üzerinde Suricata etkinleştirildiğinde, trafik pfSense üzerinden güvenlik duvarı ve NAT işlemleri için geçerken, Suricata kendi kurallarına göre trafiği inceler ve IPS modunda engelleyebilir . Tek bir web arayüzünden yönetilen bu kombinasyon, küçük ve orta ölçekli ağlarda DPI korumasının dağıtımını büyük ölçüde basitleştirir.

Birçok kurulumda, bu durum Pfsense/Suricata'nın bir SIEM veya merkezi günlük platformuna bağlanmasıyla tamamlanır ve olayları ilişkilendirmek ve daha geniş kapsamlı kampanyaları tespit etmek için yapılandırılmış çıktı biçimlerinden yararlanılır.

Suricata'da olay izleme ve örnek günlükler

Suricata çalışmaya başladıktan sonra, olaylar default-log-dir tarafından tanımlanan yola, genellikle /var/log/suricata'ya kaydedilir . fast.log dosyası, zaman damgaları, kural kimlikleri, sınıflandırmalar ve öncelik içeren, terminalden hızlı incelemeye (tail -f) uygun, kompakt bir metin formatı kullanır.

Örneğin, hatalı TCP sağlama toplamlarına sahip trafikle karşılaştığımızda, şu gibi satırlar görebiliriz: tarih ve saat içeren zaman damgaları, ardından kural tanımlayıcısı (örneğin, 1:2200074:1), "SURICATA TCPv4 geçersiz sağlama toplamı" mesajı, sınıflandırma, öncelik ve kaynak-hedef IP/port çifti. Bu tür uyarılar, paket bütünlüğü sorunlarının veya kaçınma girişimlerinin hızlı bir şekilde belirlenmesini sağlar.

eve.json dosyası, zaman damgası, olay türü, kaynak IP, hedef IP, kaynak bağlantı noktası, hedef bağlantı noktası, protokol gibi alanlara ve eylem, grup kimliği, imza kimliği, rev, imza, kategori ve önem derecesi içeren bir uyarı alt dosyasına sahip aynı olayları JSON formatında içerir. Bu format , Logstash, Fluentd, Filebeat veya diğer herhangi bir günlük kaydı aracıyla kolayca işlenebilir ve düz metin kullanmaya kıyasla çok daha zengin analizler sağlar.

Suricata'yı çok çekirdekli bir sunucuya (örneğin, 8 çekirdek) dağıtırken, iş parçacığı sıkıştırması, htop gibi araçlarda iş parçacığı modunda açıkça görülebilir; bu araçlar bir veya daha fazla yakalama iş parçacığı (pcap, AF_PACKET veya NFQ) ve çekirdekler arasında dağıtılmış çok sayıda algılama iş parçacığı gösterir. Trafik hacmi platformun sınırlarına yaklaştığında, algılama iş parçacığı oranını ve CPU yakınlığını ayarlamak, verimliliği ve gecikmeyi önemli ölçüde etkileyebilir .

Üretim ortamına dağıtmadan önce, meşru trafiği engelleyebilecek veya günlükleri karmaşık hale getirebilecek yanlış pozitiflerin önüne geçmek için hangi kural kümelerinin etkinleştirileceğini ince ayar yapmak için biraz zaman ayırmak önerilir . Suricata-update, hassasiyet ve kullanılabilirlik arasında makul bir denge bulmak için tüm kategorileri veya tek tek kuralları devre dışı bırakmanıza olanak tanır.

Özel uygulamalar: VoIP, ses analizi ve yaratıcı NFQUEUE

Klasik kullanım alanlarının (web servis koruması, kötü amaçlı yazılım tespiti, DDoS analizi) ötesinde, Netfilter+NFQUEUE ikilisi VoIP gibi alanlarda oldukça yaratıcı çözümler sunar. Örneğin, SPIT (IP telefon üzerinden spam) karşıtı bir filtre veya RTP akışlarında küfürleri sansürleyen bir sistem kurmak mümkündür .

Buradaki fikir şu olurdu: RTP trafiğini portlara veya protokol tanımaya göre tanımlamak ve NFQUEUE'ye göndermek; kullanıcı uygulamasından, librtp gibi bir kütüphane kullanarak RTP akışını yeniden oluşturmak , sesi WAV formatında çıkarmak ve bunu üçüncü taraf bir şirket tarafından sunulan sentez veya tanıma kütüphanesi gibi bir anahtar kelime tanıma motoruna (wordspotting) iletmek.

Tespit edilen kelimelere dayanarak, NFQUEUE işlemi oynatmayı izin verme, engelleme veya hatta akışa bir bip sesi ekleyerek değiştirme kararı verebilir; ancak sonuncusu, RTCP, paket dizileri ve zamanlamaların çok hassas bir şekilde kontrol edilmesini gerektirir - neredeyse bir "araya giren adam" yaklaşımı. Bu kolay değil, ancak teorik olarak aynı kuyruk ve karar sisteminden yararlanılarak mükemmel bir şekilde başarılabilir.

Doğru, bunların bir kısmı verileri harici bir işlemciye besleyen basit bir paket yakalayıcı ile ve ardından SIP sinyallemesi üzerinde veya bir SBC (Asterisk, Kamailio, vb.) aracılığıyla işlem yaparak gerçekleştirilebilir. NFQUEUE kullanmanın farkı, RTP akışı üzerindeki işlemin , birden fazla bileşeni koordine etmeye veya sinyal katmanının çağrıyı tamamlamasını beklemeye gerek kalmadan anında ve doğrudan olabilmesidir.

Bu senaryolar, GNU/Linux + Netfilter + Suricata + üçüncü taraf kütüphaneler kombinasyonunun potansiyelini açıkça göstermektedir: mesele sadece portları ve IP adreslerini engellemek değil, %100 özgür yazılım ekosistemi kullanarak karmaşık trafik kararlarını gerçek zamanlı olarak yönetmektir .

Küçük bir C programından, NFQUEUE, Pfsense, veritabanları ve önbelleklerle entegre edilmiş çok işlemcili bir Suricata dağıtımına kadar tüm yolculuğa bakıldığında, bu teknoloji yığınının basit dinamik güvenlik duvarlarından veri merkezi ölçekli IDS/IPS mimarilerine kadar her şeyi oluşturmak için sunduğu esnekliği takdir etmek mümkündür; bu mimariler gerçek anlamda derinlemesine inceleme yeteneklerine ve giderek karmaşıklaşan saldırılara otomatik yanıt verme özelliğine sahiptir.