Panduan lengkap untuk melaksanakan Netfilter dan Suricata pada Linux

Informatec Digital » Sumber » Panduan lengkap untuk melaksanakan Netfilter dan Suricata pada Linux

Jika anda bekerja dengan rangkaian pada GNU/Linux ( pengagihan Linux terbaik untuk keselamatan dan privasi ) dan berminat untuk melangkaui firewall statik biasa, anda mungkin ingin tahu tentang cara menggabungkan Netfilter, NFQUEUE dan Suricata untuk membina IDS/IPS yang benar-benar fleksibel tanpa membelanjakan banyak wang untuk perkakasan proprietari. Itulah bidang yang akan kita terokai dalam artikel ini, menggabungkan elemen peringkat rendah (kernel, barisan, C) dengan alat peringkat tinggi (Suricata, peraturan, MySQL, Memcached, pfSense).

Idea asasnya sangat hebat: manfaatkan fakta bahawa kernel (lihat cara mengoptimumkan kernel Linux ) boleh memasukkan paket ke dalam ruang pengguna dan membiarkan program tersuai memutuskan apa yang perlu dilakukan dengannya. Ini boleh digunakan untuk penapisan trafik (firewall lanjutan, IPS), penghalaan dinamik atau penyepaduan logik perniagaan (pangkalan data, cache, pengesanan serangan aplikasi web, VoIP, dll.). Dan jika kita menambah Suricata sebagai enjin IDS/IPS berbilang proses, kita mempunyai kombinasi yang sangat mantap untuk persekitaran daripada makmal hingga pusat data trafik tinggi.

NFQUEUE dan Netfilter: meningkatkan firewall ke ruang pengguna

Dalam sistem GNU/Linux yang biasa, peraturan Netfilter/iptables (atau nftables) biasanya digunakan sebagai dasar statik yang berada sepenuhnya dalam ruang kernel . Bahagian hadapan dan perkakas (termasuk banyak penyelesaian berdasarkan Netfilter atau Penapis Paket BSD) menyimpan konfigurasi dalam fail teks, XML atau SQLite, dan apabila sesuatu berubah, ia menjana semula dan memuatkan semula peraturan. Ini fleksibel, tetapi logiknya kekal sebagai sejenis gambaran ringkas tembok api dengan sedikit perubahan dinamik (had sambungan-sesaat, jejak sambungan, padanan negara, lapisan 7 jika tersedia, dsb.).

Apa yang dicadangkan oleh NFQUEUE adalah pengubah keadaan: daripada kernel sentiasa membuat keputusan muktamad, kita boleh mewakilkan keputusan tersebut kepada proses pengguna . Kernel akan mengantri paket dalam barisan bernombor dan aplikasi yang menggunakan pustaka libnetfilter_queue akan mengambilnya, menganalisisnya dan mengembalikan keputusan: menerima, membuang atau menandakannya untuk penghalaan dasar. Ia seperti mempunyai "penilai" boleh atur cara yang ditulis dalam C, Python atau Perl di atas tembok api.

Keindahannya ialah program kita secara literal boleh melakukan apa sahaja yang kita mahukan: pertanyaan /dev/urandom, pangkalan data, perkhidmatan web, cache teragih atau algoritma yang canggih sebelum bertindak balas terhadap kernel. Dari segi seni bina, tembok api tidak lagi menjadi satu set peraturan statik yang mudah dan menjadi saluran paip di mana Netfilter, barisan dan aplikasi pengguna sesuai bersama seperti kepingan teka-teki.

NFQUEUE terdiri daripada dua bahagian: sasaran NFQUEUE dalam iptables , yang menghantar paket ke barisan tertentu, dan pustaka pengguna libnetfilter_queue , yang membolehkan anda membaca paket tersebut dan mengeluarkan keputusan. Ia bukan penghidu mudah seperti tcpdump: di sini kita mempunyai keupayaan untuk menentukan secara langsung laluan yang diambil oleh paket.

Konfigurasi iptables asas dengan NFQUEUE

Dari sudut pandangan iptables, penggunaan NFQUEUE agak mudah: anda menambah peraturan pada rantai yang anda minati untuk menghantar paket yang memenuhi kriteria tertentu (IP sumber/destinasi, port, keadaan, modul tambahan seperti GeoIP atau layer7 jika tersedia, dsb.) ke barisan.

Contohnya, jika kita ingin menghantar semua ping yang tiba di hos itu sendiri ke NFQUEUE:

iptables -I INPUT -p icmp -j NFQUEUE

Ini menghantar paket ICMP masuk ke baris gilir 0 (melainkan dinyatakan sebaliknya). Kita boleh menentukan baris gilir lain dengan sesuatu seperti `--queue-num 3` . Apabila menyenaraikan peraturan dengan kaunter (`iptables -L -n -v -x`), kita akan melihat kaunter meningkat, menunjukkan bahawa paket sedang dibariskan . Perincian penting: jika terdapat paket dalam baris gilir dan tiada proses pengguna mengambil dan memprosesnya, tingkah laku lalai adalah untuk menolaknya, jadi kegagalan aplikasi, secara reka bentuk, mengakibatkan trafik disekat.

Pengaturcaraan terhadap libnetfilter_queue: "hello world" dalam C

Untuk menyertai barisan dari ruang pengguna, pustaka libnetfilter_queue digunakan (yang seterusnya bergantung pada libnfnetlink). Pada pengedaran seperti Debian, cuma pasang pakej pembangunan:

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

Rangka program minimum yang sentiasa menerima paket terdiri daripada beberapa langkah yang sangat jelas: buka pustaka, lepaskan ikatan mana-mana pengendali sedia ada, ikat kepada protokol AF_INET, cipta barisan dengan fungsi panggil balik, tentukan mod salin dan masukkan gelung terima . Panggilan balik dilaksanakan untuk setiap paket yang beratur, mengekstrak ID dan mengembalikan keputusan.

Dalam praktiknya, alirannya adalah seperti ini: `nfq_open` untuk mendapatkan pemegang, `nfq_unbind_pf` untuk membersihkannya, `nfq_bind_pf` untuk mengaitkan dengan AF_INET, `nfq_create_queue` untuk mendaftarkan panggilan balik dalam barisan 0, `nfq_set_mode` untuk menunjukkan sama ada kita mahukan metadata atau keseluruhan paket, gelung dengan `recv()` pada deskriptor, dan `nfq_handle_packet` untuk memproses setiap paket . Setelah keluar, barisan dimusnahkan dengan `nfq_destroy_queue` dan pemegang ditutup dengan `nfq_close`.

Jenis "hello world" ini membolehkan pengukuran kesan NFQUEUE yang jelas. Jika kita menyusun contoh dengan sesuatu seperti:

gcc -o nftest code.c -lnfnetlink -lnetfilter_queue

Dan jika kita beratur trafik dari iperf (contohnya, port TCP 5001 dalam INPUT dan OUTPUT), kita akan melihat kod yang hanya menerima paket hampir tidak menjejaskan prestasi pada rangkaian gigabit . Walau bagaimanapun, terdapat butiran penting: mencetak maklumat dalam panggilan balik (printf, fflush, dll.) akan menghukum daya pemprosesan dengan ketara, seperti yang dapat dilihat apabila membandingkan iperf dengan dan tanpa penyahpepijatan skrin.

Pilihan NFQUEUE lanjutan: pintasan, imbangan dan buka-gagal

NFQUEUE menggabungkan beberapa pilihan iptables yang menarik yang mengubah suai tingkah laku lalai barisan dan yang harus diketahui sebelum memasuki persekitaran pengeluaran atau berprestasi tinggi, kerana ia mempengaruhi cara kegagalan aplikasi pengguna atau pengisian barisan dikendalikan.

Arahan `--queue-bypass` membolehkan anda memastikan bahawa jika tiada proses yang mendengar baris gilir, paket tidak akan digugurkan tetapi sebaliknya akan dihantar ke hop seterusnya dalam rantaian iptables. Ini berguna jika anda mahu sistem "gagal dibuka" apabila perkhidmatan pengguna tidak tersedia, walaupun dari perspektif keselamatan ia umpama pedang bermata dua.

Pilihan `--queue-balance` membolehkan anda mengagihkan paket merentasi pelbagai baris gilir (contohnya, dari 0 hingga 3) dan kemudian mempunyai berbilang proses atau thread bebas yang mengambil daripada setiap baris gilir . Kod Netfilter memastikan bahawa paket daripada aliran yang sama sentiasa berakhir dalam baris gilir yang sama, yang sangat memudahkan pengekalan konsistensi dalam logik keputusan.

Terdapat juga mod `--fail-open` , yang mengawal apa yang berlaku apabila barisan penuh kerana proses pengguna berjalan terlalu perlahan. Mendayakannya menyebabkan kernel menerima paket secara langsung dan bukannya menjatuhkannya, sekali gus mencegah gangguan trafik yang besar. Sekali lagi, ini boleh menjadi isu keselamatan, kerana jika kita ingin membuat keputusan berdasarkan kes demi kes, kehilangan paket keputusan bermakna gagal memenuhi objektif tersebut.

Untuk memantau apa yang berlaku dengan barisan, Netfilter mendedahkan maklumat dalam pseudo-fs /proc/net/netfilter/nfnetlink_queue , yang boleh ditanya dengan mudah daripada skrip atau alat pemantauan.

Mengintegrasikan logik perniagaan: pengujian dengan Memcached dan MySQL

Sebaik sahaja proses "hello world" terkawal, langkah semula jadi seterusnya adalah memperkayakan panggilan balik dengan panggilan ke sistem luaran . Eksperimen biasa melibatkan keputusan sama ada untuk menerima atau menolak paket berdasarkan sama ada alamat IP sumber muncul dalam mana-mana backend, seperti pangkalan data MySQL atau cache Memcached.

Dalam kes Memcached, daemon dipasang (apt-get install memcached) dan kunci, contohnya authorized , dimuatkan dengan alamat IP yang kita minati. Kita boleh melakukan ini dengan echo dan netcat yang mudah, dan kemudian mengesahkan dengan arahan get bahawa nilai tersebut disimpan dengan betul. Dari situ, program NFQUEUE, selain mendapatkan ID paket, menerima keseluruhan paket menggunakan NFQNL_COPY_PACKET , mengekstrak pengepala IP (struct iphdr), dan menukar alamat sumber kepada rentetan dengan inet_ntop.

Untuk mengelakkan pembaziran masa membuka sambungan dengan setiap paket, sambungan Memcached hanya diinisialisasi sekali dalam kaedah utama (memcached_create, memcached_server_list_append, memcached_server_push), dan pengendali disimpan dalam pembolehubah global. Dalam panggilan balik, memcached_get dipanggil dengan kunci yang dikehendaki, alamat IP sumber dibandingkan dengan nilai yang diambil, dan jika sepadan, NF_ACCEPT dikembalikan; jika tidak, NF_DROP dikembalikan. Jika kunci tidak wujud atau terdapat ralat, paket akan digugurkan sebagai dasar konservatif.

Menggunakan iperf, strategi ini mengurangkan daya pemprosesan kepada kira-kira 140 Mbit/s pada rangkaian gigabit , dan diperhatikan bahawa barisan mula mengalami kerugian (ditunjukkan, contohnya, oleh simbol dalam kod itu sendiri). Dalam erti kata lain, hanya memanggil perkhidmatan cache setiap paket sudah menanggung kos yang ketara, walaupun ia kekal berdaya maju untuk jumlah trafik sederhana jika dioptimumkan.

Dengan MySQL, pendekatannya adalah serupa tetapi lebih kompleks: pustaka pelayan dan klien dipasang, pangkalan data (contohnya, nfqueue) dicipta dengan jadual ringkas yang dipanggil authorized(ip varchar(50)), dan alamat IP yang dibenarkan dimasukkan. Dalam program ini, `mysql_init` dan `mysql_real_connect` dijalankan semasa permulaan, dan dalam panggilan balik, pertanyaan seperti `select * from authorized where ip like 'xxxx'` dibina. Jika pertanyaan dilaksanakan dengan jayanya dan baris ditemui, pakej diterima; jika tidak, ia akan dibuang.

Dengan caching pertanyaan MySQL diaktifkan, ujian menghasilkan sekitar 188 Mbit/s , yang menurun kepada 103 Mbit/s apabila caching pertanyaan dinyahdayakan. Angka-angka ini, walaupun jauh daripada gigabit, menunjukkan bahawa walaupun dengan pendekatan yang paling kurang elegan (benang tunggal, tanpa pengoptimuman) , jumlah trafik yang baik boleh dikendalikan menggunakan keputusan berasaskan pangkalan data atau caching.

Prestasi, multithreading dan penggunaan CPU

Ujian dengan iperf, Memcached dan MySQL jelas menunjukkan bahawa had prestasi tidak banyak dikenakan oleh NFQUEUE itu sendiri tetapi oleh logik yang kita tambahkan dalam ruang pengguna dan cara kita melaksanakannya. Boleh laku yang hanya mengembalikan NF_ACCEPT mencapai hampir satu gigabit tanpa perlu bersusah payah; sebaik sahaja kita memperkenalkan I/O atau panggilan rangkaian, daya pemprosesan menurun dan CPU mesin NFQUEUE, daemon Memcached atau MySQL ditolak ke hadnya.

Dari sudut seni bina, ini mempunyai dua implikasi. Di satu pihak, ia mengesahkan bahawa mewakilkan keputusan firewall kepada aplikasi pengguna untuk jumlah trafik yang ketara adalah sangat berdaya maju , dengan syarat kos sebenar setiap panggilan diambil kira. Sebaliknya, ia menunjukkan bahawa untuk mendekati keupayaan maksimum platform , multithreading atau multiprocessing mesti dipertimbangkan . NFQUEUE membolehkan trafik diagihkan merentasi berbilang baris gilir; kita boleh melancarkan beberapa salinan aplikasi kita, setiap satu mendengar baris gilir yang berbeza dan memanfaatkan berbilang teras tanpa kerumitan pthreads atau fork yang besar.

Satu lagi pengoptimuman yang jelas adalah untuk mengehadkan trafik yang melalui NFQUEUE . Dalam ujian, keseluruhan aliran iperf sedang dalam barisan, tetapi dalam senario dunia sebenar, kita hanya boleh membariskan paket dengan keadaan BARU, membenarkan paket ESTABLISHED/RELATED melaluinya dan menyimpan logik yang mahal untuk log masuk atau corak yang mencurigakan.

Akhirnya, penggunaan CPU dan reka bentuk thread adalah kunci: jika proses pengguna gagal, barisan akan penuh dan kita terpaksa menggunakan perkara seperti fail-open atau accept drops, lalu kehilangan beberapa kawalan halus yang disasarkan oleh pendekatan ini.

Penghalaan dinamik dengan penjenamaan Netfilter

NFQUEUE tidak terhad kepada hanya mengatakan "terima" atau "buang." Ia juga boleh digunakan untuk menggunakan bendera Netfilter (fwmark) pada paket dan menggabungkannya dengan peraturan ip dan iproute2 untuk mencipta skema penghalaan politik gaya VRF yang sangat fleksibel dan hampir ringan.

Prosedurnya, secara amnya, adalah seperti berikut: tentukan beberapa jadual penghalaan dalam /etc/iproute2/rt_tables , contohnya perlahan dan pantas; tetapkan setiap jadual laluan lalai yang berbeza (satu melalui gentian optik dan satu lagi melalui pautan yang lebih terhad); gunakan peraturan ip untuk menentukan bahawa paket dengan fwmark 1 pergi ke jadual pantas, yang dengan fwmark 2 menjadi perlahan, dsb.; dan akhirnya, gunakan NFQUEUE untuk menandakan paket dengan sewajarnya sebelum mengembalikan keputusan.

Untuk menetapkan keputusan daripada panggilan balik, `nfq_set_verdict2` digunakan , yang seperti `nfq_set_verdict` tetapi membolehkan anda menetapkan nilai keputusan yang kemudiannya akan dilihat oleh `ip rule`. Dengan menggabungkan semua ini, anda boleh membina penghala IP yang menentukan ke mana hendak menghalakan berdasarkan kriteria sewenang-wenangnya: daripada perkara yang tidak masuk akal seperti saiz paket genap/ganjil kepada input luaran seperti algoritma ramalan trafik, peristiwa media sosial atau isyarat daripada sistem pemantauan.

Hasilnya adalah sistem di mana kernel terus menghantar paket pada kadar biasa, tetapi laluan tepat yang diambil oleh setiap aliran diwakilkan kepada perisian luaran yang boleh mengubah fikirannya dalam masa nyata tanpa menyentuh peraturan statik.

NFQUEUE dan Suricata: IPS peringkat tinggi dalam GNU/Linux

Semua perkara di atas boleh diprogramkan secara manual dalam C, tetapi apabila melibatkan pengesanan pencerobohan dan pemeriksaan paket mendalam, pilihan yang bijak biasanya bergantung pada enjin IDS/IPS yang matang . Di sinilah Suricata memainkan peranan, yang dilahirkan sebagai alternatif berbilang proses kepada Snort, dengan keupayaan IPS sejak awal dan tumpuan yang besar untuk memanfaatkan pelbagai teras CPU yang tersedia hari ini.

Suricata ditulis dari awal dan diedarkan di bawah lesen GPLv2 ; Open Information Security Foundation (OISF) mengekalkan kedua-dua enjin dan ekosistem peraturan dan dokumentasi yang agak komprehensif. Tidak seperti Snort 2.x, yang mewarisi teras berulir tunggal dan dipasang padanya, Suricata direka bentuk untuk membahagikan beban kerja merentasi berbilang utas: penangkapan, penyahkodan, pengesanan dan output, dengan strategi perkongsian beban yang berbeza.

Pada tahap fungsian, Suricata menyediakan sokongan asli untuk IPv6, pemeriksaan lapisan 7 (HTTP yang sangat canggih melalui pustaka HTP), pengecaman protokol bebas daripada port , pembinaan semula aliran dan sistem pembolehubah sesi (flowbit) yang sangat berkuasa untuk menghubungkan peringkat serangan yang berbeza yang tersebar merentasi beberapa sambungan TCP.

Satu lagi kekuatan ialah keserasiannya dengan peraturan Snort dan keupayaannya untuk menggunakan kedua-dua set tandatangan Sourcefire VRT dan Emerging Threats (versi ET Open percuma dan versi ET Pro komersial). Tambahan pula, ia mengeksport peristiwa dalam format yang sangat berguna (fast.log, JSON dalam eve.json) untuk penyepaduan dengan SIEM, ELK, Splunk dan sistem lain.

Suricata sebagai IPS dalam Linux: mod tangkapan dan NFQUEUE

Pada GNU/Linux, Suricata boleh beroperasi dalam mod yang berbeza bergantung pada cara trafik dipintas: NFQUEUE, AF_PACKET, PF_RING, libpcap, NFLOG, IPFW, DAG, Napatech … Setiap satu mempunyai kelebihan dan keperluannya sendiri. Pada peringkat IPS tulen, dua yang paling penting ialah NFQUEUE dan AF_PACKET.

Dalam mod NFQ (NFQUEUE) , alirannya serupa dengan yang diterangkan sebelum ini: satu set peraturan iptables menghantar paket ke barisan; Suricata, yang berjalan dalam ruang pengguna, membaca dari barisan tersebut, memeriksa kandungan mengikut peraturannya dan mengembalikan keputusan ke kernel: NF_ACCEPT, NF_DROP atau NF_REPEAT. Yang ketiga boleh digunakan untuk menyuntik semula paket ke dalam jadual iptables yang sama selepas menggunakan tanda atau pengubahsuaian tambahan.

Mod ini sangat fleksibel dan mudah dilaksanakan dalam infrastruktur sedia ada , kerana ia hanya memerlukan pengubahsuaian peraturan pada titik tertentu (contohnya, FORWARD, INPUT, OUTPUT) dan membiarkan semua yang lain seperti sedia ada. Kosnya ialah overhed tambahan untuk menghantar paket ke atas dan ke bawah melalui NFQUEUE, dengan kesan yang dinyatakan di atas jika volumnya sangat tinggi atau peraturan memerlukan banyak sumber.

Dalam mod AF_PACKET , Suricata beroperasi lebih dekat dengan antara muka rangkaian, menyalin paket merentasi soket AF_PACKET. Ini adalah pendekatan salinan sifar yang jauh lebih pantas , tetapi ia memerlukan sistem berfungsi sebagai pintu masuk dengan dua antara muka dan penyekatan trafik dilakukan pada tahap pemajuan antara NIC: paket yang hendak disekat tidak dihantar dari antara muka input ke antara muka output.

Dalam kedua-dua mod, Suricata boleh digabungkan dengan Netfilter, tetapi NFQUEUE amat sesuai dalam senario di mana kita ingin menggunakan semula semua logik iptables (dasar, julat, peraturan sebelumnya) dan hanya menghantar kepada Suricata trafik yang kita berminat untuk periksa secara mendalam.

Pemasangan asas Suricata daripada kod sumber

Bagi mereka yang lebih suka mengkompilasi Suricata dan bukannya menggunakan pakej, proses pada pengedaran jenis Debian/Ubuntu melibatkan pemasangan kebergantungan kompilasi (build-essential, libpcre, libpcap-dev, libnet-dev, libyaml-dev, zlib, libcap-ng-dev, libjansson-dev, dll.), memuat turun tarball dari laman web rasmi dan menjalankan ./configure, make, make install . klasik .

Semasa fasa konfigurasi, skrip akan menunjukkan ciri sokongan yang telah diaktifkan: AF_PACKET yes/no, PF_RING, NFQUEUE yes/no, NFLOG, IPFW, sokongan untuk libnss, libjansson, Prelude, PCRE JIT, Lua, GeoIP, dll. Adalah penting untuk mengesahkan bahawa NFQUEUE diaktifkan jika kita ingin bekerja dalam mod tersebut , dan pustaka tangkapan yang kita minati telah ditemui.

Selepas memasang binari, anda boleh menjalankan `make install-conf` untuk menggunakan konfigurasi lalai kepada `/etc/suricata` dan `make install-rules` untuk memuat turun dan meletakkan satu set peraturan Ancaman Baru Muncul dalam `/etc/suricata/rules`. Set ini kemudiannya boleh dikemas kini menggunakan alatan seperti `suricata-update`.

Pada sistem Red Hat/CentOS, logiknya adalah serupa, menggunakan yum atau dnf untuk kebergantungan (libpcap-devel, pcre-devel, libnet-devel, libyaml-devel, jansson-devel, dll.) dan kemudian mengkompilasi dengan langkah yang sama. Atas sebab prestasi, adalah dinasihatkan untuk melumpuhkan LRO/GRO dalam antara muka tangkapan menggunakan ethtool, kerana fungsi offload ini boleh menjejaskan keterlihatan pakej pada peringkat IDS.

Konfigurasi Suricata: YAML, pembolehubah dan threading

Konfigurasi utama Suricata terletak di /etc/suricata/suricata.yaml . Ia merupakan fail YAML yang agak mudah dibaca dan banyak diulas, di mana segala-galanya daripada laluan log dan set peraturan hinggalah dasar sistem pengendalian sasaran dan parameter threading ditakrifkan.

Salah satu medan asas ialah `default-log-dir` , yang menentukan tempat fail log akan disimpan (secara lalai, `/var/log/suricata`). Di bawah bahagian `vars` terdapat pembolehubah seperti `HOME_NET`, `EXTERNAL_NET`, `HTTP_PORTS`, `SHELLCODE_PORTS` dan `SSH_PORTS`, yang berfungsi sebagai singkatan dalam peraturan. `HOME_NET` biasanya dikonfigurasikan dengan julat rangkaian setempat yang ingin kita lindungi, manakala `EXTERNAL_NET` biasanya ditakrifkan sebagai `!HOME_NET`.

Satu lagi bahagian penting ialah host-os-policy , yang memberitahu Suricata sistem pengendalian yang sepatutnya menjalankan julat IP tertentu. Ini membolehkannya melaraskan cara ia memasang semula TCP atau mentafsir tingkah laku tindanan rangkaian tertentu , menjadikannya lebih sukar untuk mengelak protokol berdasarkan perbezaan antara tindanan (Windows vs. Linux, dsb.). Julat tertentu boleh diberikan kepada kategori seperti Windows, Linux, BSD, Vista, Windows 2003, dsb.

Berkenaan dengan threading, bahagian threading membolehkan anda memperhalusi afiniti CPU dan bilangan thread pengesanan. Secara lalai, `set-cpu-affinity` biasanya dinyahdayakan, yang membolehkan penjadual sistem mengagihkan thread merentasi teras. Parameter `detect-thread-ratio` menunjukkan berapa banyak thread pengesanan yang dicipta bagi setiap teras yang tersedia; dengan `detect-thread-ratio: 1.5` pada mesin 8 teras, Suricata akan menjana 12 thread pengesanan, serta thread penangkapan dan pengurusan.

Keseluruhan model ini kemudiannya dicerminkan dalam output apabila daemon bermula: thread tangkapan (contohnya, pcap) dan berbilang thread pengesan kelihatan, selain pengurus aliran dan pengurus statistik. Seni bina berbilang proses inilah yang membolehkan Suricata berskala jauh lebih baik daripada enjin thread tunggal apabila berhadapan dengan pautan 10/40 Gbit/s.

Peraturan dan kemas kini tandatangan dalam Suricata

Suricata bergantung pada set peraturan untuk mengesan corak serangan, tingkah laku anomali dan penyalahgunaan protokol. Selain menerima peraturan dalam format Snort , ekosistem yang paling biasa ialah Emerging Threats: ET Open (percuma) dan ET Pro (komersial), dengan peraturan yang ditujukan kepada ancaman semasa.

Banyak pengedaran moden menyertakan alat `suricata-update` , yang memudahkan pengurusan peraturan: ia mengemas kini sumber, mendayakan atau melumpuhkan pembekal tertentu dan memuat turun versi terkini set tandatangan. Aliran kerja biasa adalah memasang `suricata-update` (contohnya, melalui pip), jalankan `suricata-update` pertama untuk memuat turun ET Open, senaraikan sumber dengan `suricata-update list-sources`, dayakan sumber tambahan seperti `ptresearch/attackdetection`, `oisf/trafficid` atau `sslbl/ssl-fp-blacklist` dan jalankan `suricata-update` sekali lagi untuk menjana semula fail peraturan.

Fail suricata.yaml dilaraskan untuk menunjukkan laluan peraturan yang betul, dan dari situ Suricata akan mula membangkitkan peristiwa amaran yang akan direkodkan dalam fast.log (teks pantas dan boleh dibaca) dan eve.json (JSON berstruktur dengan maklumat yang sangat lengkap) . Format yang terakhir ini amat berguna untuk memberi makan papan pemuka, sistem korelasi atau skrip tersuai.

Selain tandatangan, Suricata menggabungkan penyahkod dan penghurai untuk berbilang protokol , yang membolehkannya kurang bergantung pada port: ia boleh mengenal pasti trafik HTTP walaupun ia melalui port bukan standard, mengesan SSH, TLS, DNS, dsb. melalui port dan tahap enkapsulasi yang berbeza (termasuk terowong IPv4/IPv6 campuran).

Kegunaan praktikal: daripada mengesan eksploitasi web kepada penyekatan automatik

Salah satu kes penggunaan yang paling diingini dalam persekitaran pengehosan atau pusat data adalah untuk mengesan percubaan masa nyata untuk mengeksploitasi kerentanan dalam aplikasi web (cth., WordPress dan pemalamnya) dan bertindak balas secara automatik, biasanya dengan menyekat atau menyenaraihitamkan IP sumber dalam tembok api.

Suricata, yang dikuasakan oleh peraturan yang dikemas kini, mampu mengenali corak serangan tertentu terhadap URL, parameter, muatan HTTP dan juga urutan permintaan yang sepadan dengan eksploitasi yang diketahui. IDS boleh beroperasi dalam mod pasif, menerima trafik melalui pencerminan daripada port suis (SPAN), tetapi untuk bertindak sebagai IPS dan menyekat serangan, ia perlu disepadukan dengan satah pemajuan.

Terdapat dua pendekatan biasa: menyediakan IDS sebagai jambatan dalam talian, supaya trafik melalui mesin secara fizikal (menggunakan iptables, AF_PACKET atau PF, bergantung pada platform), atau membiarkan topologi sebagaimana adanya tetapi menggabungkan pencerminan dengan tindakan pada tembok api pusat melalui API, skrip atau NFQUEUE . Pendekatan pertama meminimumkan kependaman antara pengesanan dan penyekatan, dengan kos menambah elemen lain "di tengah" rangkaian; pendekatan kedua menawarkan fleksibiliti dan daya tahan yang lebih besar, tetapi memperkenalkan lebih banyak kerumitan pada orkestrasi.

Sistem Pengesanan Pencerobohan (IDS) adalah sangat sesuai untuk mengesan percubaan mengeksploitasi pemalam WordPress yang terdedah dan kemudian, sama ada secara langsung atau melalui komponen yang berkaitan, menambah alamat IP penyerang ke senarai hitam iptables. Ini boleh dilakukan melalui output JSON Suricata dan skrip yang memanggil iptables/nftables , atau dengan mewakilkan sebahagian logik kepada NFQUEUE, di mana enjin itu sendiri atau proses yang berkaitan membuat keputusan dengan pantas tanpa menunggu senarai luaran dikemas kini.

Ini membolehkan anda memberi tumpuan kepada ancaman yang benar-benar penting (eksploitasi, percubaan peningkatan, imbasan yang sangat agresif), mengabaikan atau hanya merekod hingar latar belakang seperti imbasan port asas yang, dalam banyak konteks, tidak membimbangkan.

Suricata pada Pfsense: tembok api sumber terbuka dengan IDS/IPS bersepadu

Bukan semua orang mampu atau mahu membeli firewall canggih proprietari seperti Palo Alto. Dalam banyak persekitaran, adalah lebih menarik untuk menyediakan penyelesaian sumber terbuka dengan pfSense dan Suricata , yang merangkumi kedua-dua keperluan firewall lanjutan (multi-WAN, VLAN, VPN, NAT, dll.) dan IDS/IPS.

Pfsense, berdasarkan FreeBSD dan Packet Filter, berfungsi dengan baik dengan persekitaran maya (Proxmox, KVM, dll.), kecuali disyorkan untuk menggunakan kad E1000 dan bukannya Virtio dalam mesin KVM jika anda ingin mengelakkan masalah prestasi dan ranap semasa beban, melainkan anda menggunakan cadangan Netgate (lumpuhkan beban checksum perkakasan dalam Sistem > Lanjutan > Rangkaian dan mulakan semula, kerana ini mungkin tidak mencukupi dengan beban yang sangat tinggi).

Keperluan perkakasan minimum untuk makmal dengan Suricata pada Pfsense boleh jadi sederhana (1 CPU 500 MHz, 1 GB RAM, 4 GB cakera), tetapi untuk kegunaan yang serius, sekurang-kurangnya 2 CPU, 4 GB RAM dan 16 GB storan disyorkan , tidak lupa untuk mempunyai beberapa antara muka rangkaian (satu untuk WAN, satu lagi untuk LAN, lebih banyak jika anda mahukan berbilang WAN atau VLAN yang kompleks).

Memasang pfSense sendiri adalah sangat pantas: anda but dari ISO, menerima lesen, memilih untuk memasang, memilih bahasa dan susun atur papan kekunci anda, membiarkan pembahagian pada automatik (Auto UFS jika anda akan menggunakan keseluruhan cakera), dan dalam beberapa minit sistem sedia untuk but pertamanya. Konsol menawarkan menu untuk menetapkan antara muka, memulakan semula, melancarkan shell, dsb.

Dalam makmal, contohnya dalam VirtualBox, adalah perkara biasa untuk melumpuhkan sementara firewall Pfsense daripada konsol dengan pfctl -d untuk mengakses antara muka web melalui WAN (nama pengguna admin, kata laluan pfsense) dan melengkapkan wizard awal: data umum, pelayan NTP, konfigurasi WAN (DHCP biasanya mencukupi dalam makmal), LAN, perubahan kata laluan admin dan aplikasi konfigurasi.

Sebaik sahaja akses distabilkan, anda boleh mencipta peraturan dalam tembok api WAN yang membenarkan HTTPS daripada mana-mana sumber ke alamat IP pfsense, dengan menambah pemisah deskriptif untuk menyusun peraturan secara visual (contohnya, "Akses Tembok Api"). Anda juga dinasihatkan untuk melumpuhkan pilihan untuk menyekat rangkaian peribadi pada WAN jika anda berada dalam persekitaran ujian dengan alamat RFC1918, bagi mengelakkan daripada sentiasa menggunakan `pfctl -d`.

Pemasangan Suricata pada pfSense dan gambaran keseluruhan

Dengan pangkalan pfSense yang telah berjalan, pemasangan Suricata semudah pergi ke Sistem > Pengurus Pakej > Pakej yang Tersedia , mencari Suricata dan memasang pakej tersebut. Proses ini memuat turun beberapa fail dan mungkin mengambil sedikit masa bergantung pada perkakasan anda, tetapi ia dibantu sepenuhnya melalui antara muka web.

Setelah dipasang, entri Suricata akan muncul dalam tab Perkhidmatan, di mana anda boleh mengkonfigurasi tika mengikut antara muka (WAN, LAN, VLAN, dll.), memilih set peraturan yang hendak digunakan, mengaktifkan mod IDS atau IPS , dan melaraskan parameter prestasi dan pengelogan. Pelbagai pilihan adalah luas (cukup untuk keseluruhan artikel hanya pada konfigurasi), tetapi kelebihannya ialah banyak tugas yang memerlukan penyuntingan YAML manual dalam Linux dikendalikan di sini dengan borang dan kotak pilihan.

Nota penting: Walaupun mungkin menggoda untuk membuka pentadbiran pfSense terus ke internet dalam persekitaran makmal, dalam pengeluaran adalah penting untuk menyekat akses kepada alamat IP statik, menggunakan VPN untuk pengurusan jarak jauh dan elakkan daripada membiarkan konsol web terdedah dengan apa jua cara . pfSense sangat fleksibel, tetapi ia juga mesti dianggap sebagai elemen kritikal.

Dengan Suricata diaktifkan pada pfSense, anda akan mendapat persekitaran di mana trafik melalui pfSense untuk firewall dan NAT, dan Suricata memeriksanya mengikut peraturannya dan boleh menyekatnya dalam mod IPS . Gabungan ini, yang diuruskan daripada antara muka web tunggal, sangat memudahkan penggunaan perlindungan DPI dalam rangkaian kecil dan sederhana.

Dalam banyak penggunaan, ini dilengkapi dengan sambungan Pfsense/Suricata kepada SIEM atau platform log berpusat, memanfaatkan format output berstruktur untuk menghubungkan peristiwa dan mengesan kempen yang lebih luas.

Pemantauan peristiwa dan contoh log dalam Suricata

Sebaik sahaja Suricata berjalan, peristiwa direkodkan ke laluan yang ditakrifkan oleh default-log-dir, biasanya /var/log/suricata . Fail fast.log menggunakan format teks padat dengan cap waktu, ID peraturan, pengelasan dan keutamaan, sesuai untuk pemeriksaan pantas dari terminal (tail -f).

Contohnya, apabila menghadapi trafik dengan semakan TCP yang salah, kita mungkin melihat baris seperti ini: cap waktu dengan tarikh dan masa, diikuti dengan pengecam peraturan (cth., 1:2200074:1), mesej "SURICATA TCPv4 checksum tidak sah", pengelasan, keutamaan dan pasangan IP/port sumber-destinasi. Jenis amaran ini membolehkan pengenalpastian pantas isu integriti paket atau percubaan pengelakan.

Fail eve.json mengandungi peristiwa yang sama dalam format JSON, dengan medan seperti cap waktu, jenis_peristiwa, src_ip, dest_ip, src_port, dest_port, proto dan subfail amaran dengan tindakan, gid, signature_id, rev, signature, kategori dan keterukan. Format ini boleh diakses dengan mudah dengan Logstash, Fluentd, Filebeat atau mana-mana ejen log lain , yang membolehkan analitik yang lebih kaya daripada sekadar menggunakan teks biasa.

Apabila menggunakan Suricata pada pelayan berbilang teras (cth., 8 teras), pemampatan thread mudah dilihat dalam alat seperti htop dalam mod thread, menunjukkan satu atau lebih thread tangkapan (pcap, AF_PACKET atau NFQ) dan sebilangan besar thread pengesanan yang diedarkan merentasi teras. Melaraskan nisbah pengesanan-thread dan afiniti CPU boleh memberi kesan yang ketara kepada daya pemprosesan dan latensi apabila jumlah trafik menghampiri had platform.

Sebelum menggunakannya dalam pengeluaran, adalah dinasihatkan untuk meluangkan sedikit masa untuk memperhalusi set peraturan yang diaktifkan bagi mengelakkan limpahan positif palsu yang boleh menyekat trafik yang sah atau mengacaukan log. Suricata-update membolehkan anda melumpuhkan keseluruhan kategori atau peraturan individu untuk mencari keseimbangan yang munasabah antara sensitiviti dan kebolehgunaan.

Aplikasi khas: VoIP, analitik audio dan NFQUEUE kreatif

Selain kegunaan klasik (perlindungan perkhidmatan web, pengesanan malware, analisis DDoS), duo Netfilter+NFQUEUE membolehkan penyelesaian yang agak kreatif dalam bidang seperti VoIP. Contohnya, penapis anti-SPIT (spam melalui telefoni IP) atau sistem untuk menapis kata-kata kesat dalam strim RTP boleh disediakan.

Ideanya ialah: untuk mengenal pasti trafik RTP melalui port atau pengecaman protokol dan menghantarnya ke NFQUEUE; daripada aplikasi pengguna, bina semula strim RTP menggunakan pustaka seperti librtp , ekstrak audio dalam format WAV dan serahkannya kepada enjin pengecaman kata kunci (wordspotting), seperti pustaka sintesis atau pengecaman yang ditawarkan oleh pihak ketiga.

Berdasarkan perkataan yang dikesan, proses NFQUEUE boleh memutuskan untuk membenarkan, menyekat atau mengubah main balik dengan memasukkan bunyi bip ke dalam strim, walaupun yang kedua memerlukan kawalan RTCP, jujukan paket dan pemasaan yang sangat halus—hampir seperti pendekatan orang tengah. Ia bukan perkara remeh, tetapi secara teorinya ia boleh dicapai dengan memanfaatkan sistem giliran dan keputusan yang sama.

Memang benar bahawa sebahagian daripada ini boleh dilakukan dengan penghidu mudah yang memberi data kepada pemproses luaran, dan kemudian bertindak pada isyarat SIP atau melalui SBC (Asterisk, Kamailio, dll.). Perbezaan dengan menggunakan NFQUEUE ialah tindakan pada aliran RTP boleh serta-merta dan terus , tanpa perlu menyelaraskan berbilang komponen atau menunggu lapisan isyarat untuk menyelesaikan panggilan.

Senario-senario ini dengan jelas menggambarkan potensi gabungan GNU/Linux + Netfilter + Suricata + pustaka pihak ketiga: ia bukan sekadar tentang menyekat port dan alamat IP, tetapi tentang mengatur keputusan trafik yang kompleks dalam masa nyata menggunakan ekosistem perisian 100% percuma.

Melihat keseluruhan perjalanan, daripada program C kecil yang sentiasa menerima paket kepada penggunaan Suricata berbilang proses yang disepadukan dengan NFQUEUE, Pfsense, pangkalan data dan cache, seseorang dapat menghargai fleksibiliti yang ditawarkan oleh susunan teknologi ini untuk membina segala-galanya daripada tembok api dinamik mudah kepada seni bina IDS/IPS berskala pusat data, dengan keupayaan pemeriksaan mendalam yang sebenar dan tindak balas automatik terhadap serangan yang semakin kompleks.