- NFQUEUE дозволяє Netfilter делегувати рішення щодо фільтрації та маркування процесам у просторі користувача, що дозволяє створювати динамічні IP-брандмауери та маршрутизатори.
- Suricata надає багатопроцесорний механізм IDS/IPS з підтримкою NFQUEUE, AF_PACKET та правил, сумісних зі Snort та Emerging Threats.
- Інтеграція NFQUEUE з Suricata, базами даних, Memcached або Pfsense дозволяє створювати передові рішення безпеки та маршрутизації за допомогою безкоштовного програмного забезпечення.
- Продуктивність значною мірою залежить від дизайну потоків та логіки простору користувача, що робить ключовим питанням оптимізацію та ретельний вибір трафіку для перевірки.
Якщо ви працюєте з мережами на GNU/Linux ( найкращі дистрибутиви Linux для безпеки та конфіденційності ) та зацікавлені у виході за рамки типового статичного брандмауера, вам, ймовірно, цікаво, як поєднати Netfilter, NFQUEUE та Suricata для створення справді гнучкої системи виявлення вторгнень/IPS, не витрачаючи цілий статок на власне обладнання. Саме цю область ми розглянемо в цій статті, поєднуючи низькорівневі елементи (ядро, черги, C) з високорівневими інструментами (Suricata, правила, MySQL, Memcached, pfSense).
Основна ідея дуже потужна: використовувати той факт, що ядро (див. як оптимізувати ядро Linux ) може ставити пакети в чергу в просторі користувача та дозволяти спеціальній програмі вирішувати, що з ними робити. Це можна використовувати для фільтрації трафіку (розширений брандмауер, IPS), динамічної маршрутизації або інтеграції бізнес-логіки (бази даних, кеші, виявлення атак на веб-застосунки, VoIP тощо). А якщо додати Suricata як багатопроцесорний механізм IDS/IPS, ми отримаємо дуже надійну комбінацію для середовищ, від лабораторій до центрів обробки даних з високим трафіком.
NFQUEUE та Netfilter: перенесення брандмауера на рівень користувача
У типовій системі GNU/Linux правила Netfilter/iptables (або nftables) зазвичай використовуються як статичні політики, що повністю знаходяться в просторі ядра . Фронтенди та пристрої (включаючи багато рішень на основі Netfilter або Packet Filter від BSD) зберігають конфігурацію в текстових, XML або SQLite файлах, і коли щось змінюється, вони регенерують та перезавантажують правила. Це гнучко, але логіка залишається своєрідним знімком брандмауера з незначними динамічними налаштуваннями (обмеження кількості підключень за секунду, conntrack, зіставлення країн, рівень 7, якщо доступний, тощо).
Те, що пропонує NFQUEUE, — це революційний процес: замість того, щоб ядро завжди приймало остаточне рішення, ми можемо делегувати це рішення користувацькому процесу . Ядро ставить пакет у пронумеровану чергу, а програма, яка використовує бібліотеку libnetfilter_queue, отримує його, аналізує та повертає вердикт: прийняти, відхилити або навіть позначити для маршрутизації за політикою. Це як мати програмованого «суддю», написаного на C, Python або Perl, поверх брандмауера.
Перевага цього полягає в тому, що наша програма може буквально робити все, що нам потрібно: запитувати /dev/urandom, базу даних, веб-сервіс, розподілений кеш або складний алгоритм, перш ніж відповісти ядру. З архітектурної точки зору, брандмауер перестає бути простим набором статичних правил і стає конвеєром, де Netfilter, черги та користувацькі програми складаються разом, як частини пазла.
NFQUEUE складається з двох частин: цільової об'єкта NFQUEUE в iptables , яка надсилає пакети до певної черги, та користувацької бібліотеки libnetfilter_queue , яка дозволяє зчитувати ці пакети та видавати вердикт. Це не простий сніффер, як tcpdump: тут ми маємо можливість безпосередньо визначати шлях, яким рухається пакет.
Базова конфігурація iptables за допомогою NFQUEUE
З точки зору iptables, використання NFQUEUE досить просте: ви додаєте правило до ланцюжка, який вас цікавить, щоб надсилати до черги пакети, що відповідають певним критеріям (IP-адреса джерела/приймача, порти, стани, додаткові модулі, такі як GeoIP або layer7, якщо доступні, тощо).
Наприклад, якщо ми хочемо надсилати до NFQUEUE всі пінги, що надходять на сам хост:
iptables -I INPUT -p icmp -j NFQUEUE
Це надсилає вхідні ICMP-пакети до черги 0 (якщо не вказано інше). Ми могли б вказати іншу чергу, наприклад, `--queue-num 3` . Під час перерахування правил з лічильниками (`iptables -L -n -v -x`) ми побачимо збільшення лічильників, що вказує на те, що пакети ставляться в чергу . Важлива деталь: якщо в черзі є пакети, і жоден процес користувача не отримує та не обробляє їх, поведінка за замовчуванням полягає в тому, щоб їх відхилити, тому збій програми, за своєю природою, призводить до блокування трафіку.
Програмування на основі libnetfilter_queue: «привіт, світе» в C
Щоб приєднатися до черги з простору користувача, використовується бібліотека libnetfilter_queue (яка, у свою чергу, залежить від libnfnetlink). У дистрибутивах, таких як Debian, просто встановіть пакети розробки:
apt-get install libnfnetlink-dev libnetfilter-queue-dev gcc
Скелет мінімальної програми, яка завжди приймає пакети, складається з кількох дуже чітких кроків: відкрити бібліотеку, відв'язати будь-які існуючі обробники, прив'язати до протоколу AF_INET, створити чергу за допомогою функції зворотного виклику, визначити режим копіювання та ввести цикл отримання . Зворотний виклик виконується для кожного пакета в черзі, витягуючи ідентифікатор та повертаючи вердикт.
На практиці, потік дій виглядає приблизно так: `nfq_open` для отримання дескриптора, `nfq_unbind_pf` для його очищення, `nfq_bind_pf` для зв'язку з AF_INET, `nfq_create_queue` для реєстрації зворотного виклику в черзі 0, `nfq_set_mode` для позначення метаданих чи всього пакета, цикл з `recv()` поверх дескриптора та `nfq_handle_packet` для обробки кожного пакета . Після виходу черга знищується за допомогою `nfq_destroy_queue`, а дескриптор закривається за допомогою `nfq_close`.
Такий тип "привіт, світе" дозволяє точно виміряти вплив NFQUEUE. Якщо ми скомпілюємо приклад таким чином:
gcc -o nftest code.c -lnfnetlink -lnetfilter_queue
А якщо ми поставимо в чергу трафік від iperf (наприклад, TCP-порт 5001 в INPUT та OUTPUT), ми побачимо, що код, який просто приймає пакети, майже не впливає на продуктивність у гігабітній мережі . Однак є ключова деталь: виведення інформації у зворотному виклику (printf, fflush тощо) значно знижує пропускну здатність, що можна побачити при порівнянні iperf з налагодженням екрана та без нього.
Розширені опції NFQUEUE: байпас, балансування та відключення при збої
NFQUEUE містить кілька цікавих параметрів iptables, які змінюють поведінку черг за замовчуванням і про які слід знати перед входом у робоче або високопродуктивне середовище, оскільки вони впливають на те, як обробляються збої користувацьких програм або заповнення черги.
Команда `--queue-bypass` дозволяє вам гарантувати, що якщо жоден процес не прослуховує чергу, пакети не будуть відкинуті, а натомість будуть перенаправлені на наступний стрибок у ланцюжку iptables. Це може бути корисним, якщо ви хочете, щоб система "відкрилася внаслідок збою", коли служба користувача недоступна, хоча з точки зору безпеки це палиця з двома кінцями.
Опція `--queue-balance` дозволяє розподіляти пакети по діапазону черг (наприклад, від 0 до 3), а потім мати кілька незалежних процесів або потоків, що споживають дані з кожної черги . Код Netfilter гарантує, що пакети з одного потоку завжди потрапляють в одну й ту саму чергу, що значно спрощує підтримку узгодженості в логіці прийняття рішень.
Також існує режим `--fail-open` , який контролює, що відбувається, коли черга заповнюється через те, що користувацький процес працює занадто повільно. Його ввімкнення призводить до того, що ядро приймає пакети безпосередньо, а не відкидає їх, запобігаючи масовим перебоям трафіку. Знову ж таки, це може бути проблемою безпеки, оскільки якщо ми хочемо приймати рішення в кожному окремому випадку, втрата пакетів рішень означає невиконання цієї мети.
Щоб відстежувати, що відбувається з чергами, Netfilter надає інформацію у псевдо-файлі /proc/net/netfilter/nfnetlink_queue , яку можна легко отримати зі скриптів або інструментів моніторингу.
Інтеграція бізнес-логіки: тестування за допомогою Memcached та MySQL
Щойно процес "привіт, світе", взято під контроль, наступним природним кроком є збагачення зворотного виклику викликами зовнішніх систем . Типовий експеримент включає вирішення питання про прийняття чи відхилення пакета на основі того, чи відображається вихідна IP-адреса в будь-якому серверному інтерфейсі, такому як база даних MySQL або кеш Memcached.
У випадку Memcached, демон встановлюється (apt-get install memcached), і ключ, наприклад authorized , завантажується з IP-адресою, яка нас цікавить. Ми можемо зробити це за допомогою простих команд echo та netcat, а потім перевірити за допомогою команди get, чи значення збережено правильно. Звідти програма NFQUEUE, окрім отримання ідентифікатора пакета, отримує весь пакет за допомогою NFQNL_COPY_PACKET , витягує IP-заголовок (struct iphdr) та перетворює адресу джерела на рядок за допомогою inet_ntop.
Щоб уникнути втрати часу на відкриття з'єднань з кожним пакетом, з'єднання Memcached ініціалізується лише один раз у головному методі (memcached_create, memcached_server_list_append, memcached_server_push), а обробник зберігається в глобальних змінних. У зворотному виклику викликається memcached_get з потрібним ключем, вихідна IP-адреса порівнюється з отриманим значенням, і якщо вони збігаються, повертається NF_ACCEPT; інакше повертається NF_DROP. Якщо ключ не існує або є помилка, пакет відкидається згідно з консервативною політикою.
Використовуючи iperf, ця стратегія знижує пропускну здатність приблизно до 140 Мбіт/с у гігабітній мережі , і спостерігається, що черга починає зазнавати втрат (що позначається, наприклад, символами в самому коді). Іншими словами, простий виклик служби кешування для кожного пакету вже несе значні витрати, хоча він залишається життєздатним для середніх обсягів трафіку за умови оптимізації.
З MySQL підхід подібний, але складніший: встановлюються серверна та клієнтська бібліотеки, створюється база даних (наприклад, nfqueue) з простою таблицею під назвою authorized(ip varchar(50)), і вставляється дозволена IP-адреса. У програмі `mysql_init` та `mysql_real_connect` виконуються під час запуску, а у зворотному виклику створюється запит типу `select * from authorized where ip like 'xxxx'`. Якщо запит виконується успішно і рядок знайдено, пакет приймається; інакше він відкидається.
З увімкненим кешуванням запитів MySQL тести дають близько 188 Мбіт/с , що падає до 103 Мбіт/с, коли кешування запитів вимкнено. Ці цифри, хоча й далекі від гігабіт, демонструють, що навіть за допомогою найменш елегантного підходу (однопотоковий, без оптимізації) можна обробляти значні обсяги трафіку за допомогою рішень, керованих базою даних або на основі кешування.
Продуктивність, багатопоточність та використання процесора
Тести з iperf, Memcached та MySQL чітко показують, що гранична продуктивність визначається не стільки самим NFQUEUE, скільки логікою, яку ми додаємо в просторі користувача , та тим, як ми її реалізуємо. Виконуваний файл, який повертає лише NF_ACCEPT, досягає майже гігабітної швидкості без жодних зайвих зусиль; щойно ми вводимо операції вводу/виводу або мережеві виклики, пропускна здатність падає, і процесор машини NFQUEUE, демона Memcached або MySQL досягає своїх меж.
З архітектурної точки зору, це має два наслідки. З одного боку, це підтверджує, що делегування рішень щодо брандмауера користувацьким програмам для значних обсягів трафіку є цілком життєздатним , за умови врахування фактичної вартості кожного виклику. З іншого боку, це демонструє, що для досягнення максимальних можливостей платформи необхідно враховувати багатопоточність або багатопроцесорність . NFQUEUE дозволяє розподіляти трафік між кількома чергами; ми могли б запустити кілька копій нашої програми, кожна з яких прослуховує окрему чергу, та використовувати кілька ядер без клопоту з pthreads або масивними форками.
Ще однією очевидною оптимізацією було б обмеження трафіку, який проходить через NFQUEUE . У тестах весь потік iperf ставився в чергу, але в реальному сценарії ми могли б ставити в чергу лише пакети зі станом NEW, дозволяти проходження пакетів ESTABLISHED/RELATED та резервувати дорогу логіку для входу в систему або підозрілих шаблонів.
Зрештою, використання процесора та проектування потоків є ключовими: якщо користувацький процес не виконує свою роботу, черга заповнюється, і нам доводиться вдаватися до таких речей, як відкриття після збою або прийняття видалень, втрачаючи частину точного контролю, на який спрямований цей підхід.
Динамічна маршрутизація з брендингом Netfilter
NFQUEUE не обмежується простими командами «прийняти» або «відкинути». Його також можна використовувати для застосування прапорців Netfilter (fwmark) до пакетів та поєднання їх з правилом ip та iproute2 для створення дуже гнучких, майже легких схем політичної маршрутизації в стилі VRF.
Процедура, загалом кажучи, буде такою: визначити кілька таблиць маршрутизації в /etc/iproute2/rt_tables , наприклад, slow та fast; призначити кожній таблиці окремий маршрут за замовчуванням (один через оптоволоконне з'єднання, а інший через обмеженіше з'єднання); використовувати правило ip, щоб вказати, що пакети з fwmark 1 йдуть до таблиці fast, ті, що з fwmark 2, - до slow тощо; і, нарешті, використовувати NFQUEUE для відповідної позначення пакетів перед поверненням вердикту.
Щоб встановити вердикт зворотного виклику, використовується `nfq_set_verdict2` , що подібно до `nfq_set_verdict`, але дозволяє встановити значення вердикту, яке потім бачитиме `ip rule`. Поєднуючи все це, можна побудувати IP-маршрутизатор, який вирішує, куди маршрутизувати, на основі довільних критеріїв: від абсурдних речей, таких як парний/непарний розмір пакета, до зовнішніх вхідних даних, таких як алгоритми прогнозування трафіку, події соціальних мереж або сигнали від систем моніторингу.
Результатом є система, в якій ядро продовжує пересилати пакети зі звичайною швидкістю, але точний шлях, яким проходить кожен потік, делегується зовнішньому програмному забезпеченню , яке може змінювати свою думку в режимі реального часу, не торкаючись статичних правил.
NFQUEUE та Suricata: Високорівнева IPS у GNU/Linux
Все вищезазначене можна запрограмувати вручну на C, але коли справа доходить до виявлення вторгнень та глибокої перевірки пакетів, розумним варіантом зазвичай є використання зрілого механізму IDS/IPS . Саме тут на допомогу приходить Suricata, яка народилася саме як багатопроцесорна альтернатива Snort, з можливостями IPS з самого початку та значним акцентом на використанні багатьох ядер процесора, доступних сьогодні.
Suricata написана з нуля та розповсюджується за ліцензією GPLv2 ; Фонд відкритої інформаційної безпеки (OISF) підтримує як сам рушій, так і досить повну екосистему правил і документації. На відміну від Snort 2.x, який успадкував однопотокове ядро та був налаштований на нього, Suricata була розроблена для розподілу робочого навантаження між кількома потоками: захоплення, декодування, виявлення та виведення, з різними стратегіями розподілу навантаження.
На функціональному рівні Suricata забезпечує вбудовану підтримку IPv6, інспекцію 7-го рівня (дуже просунутий HTTP через бібліотеку HTP), розпізнавання протоколів незалежно від портів , реконструкцію потоку та дуже потужну систему змінних сесії (flowbits) для кореляції різних етапів атаки, що поширюється на кілька TCP-з'єднань.
Додатковою перевагою є його сумісність із правилами Snort та можливість використовувати набори сигнатур Sourcefire VRT та Emerging Threats (безкоштовна версія ET Open та комерційна версія ET Pro). Крім того, він експортує події у дуже корисних форматах (fast.log, JSON та eve.json) для інтеграції із SIEM, ELK, Splunk та іншими системами.
Suricata як IPS у Linux: режими захоплення та NFQUEUE
У GNU/Linux Suricata може працювати в різних режимах залежно від способу перехоплення трафіку: NFQUEUE, AF_PACKET, PF_RING, libpcap, NFLOG, IPFW, DAG, Napatech … Кожен з них має свої переваги та вимоги. На рівні чистого IPS два найважливіших – це NFQUEUE та AF_PACKET.
У режимі NFQ (NFQUEUE) потік подібний до описаного раніше: набір правил iptables надсилає пакети до черги; Suricata, що працює в просторі користувача, зчитує з цієї черги, перевіряє вміст відповідно до своїх правил і повертає вердикт ядру: NF_ACCEPT, NF_DROP або NF_REPEAT. Третій варіант можна використовувати для повторного введення пакета в ту саму таблицю iptables після застосування додаткових позначок або модифікацій.
Цей режим дуже гнучкий і простий у впровадженні в існуючих інфраструктурах , оскільки він вимагає зміни правил лише в певних точках (наприклад, FORWARD, INPUT, OUTPUT) і залишає все інше як є. Вартість полягає в додаткових накладних витратах на передачу пакетів вгору та вниз через NFQUEUE, що впливає на вищезгаданий вплив, якщо обсяг дуже великий або правила є ресурсомісткими.
У режимі AF_PACKET Suricata працює ближче до мережевого інтерфейсу, копіюючи пакети через сокети AF_PACKET. Це набагато швидший підхід з нульовим копіюванням , але він вимагає, щоб система функціонувала як шлюз з двома інтерфейсами, а блокування трафіку виконувалося на рівні пересилання між мережевими картами: пакет, який потрібно заблокувати, просто не передається з вхідного інтерфейсу на вихідний.
В обох режимах Suricata можна поєднувати з Netfilter, але NFQUEUE особливо добре підходить для сценаріїв, де ми хочемо повторно використовувати всю логіку iptables (політики, діапазони, попередні правила) та надсилати до Suricata лише той трафік, який нас цікавить для детального аналізу.
Базова інсталяція Suricata з вихідного коду
Для тих, хто надає перевагу компіляції Suricata замість використання пакетів, процес на дистрибутивах типу Debian/Ubuntu включає спочатку встановлення залежностей компіляції (build-essential, libpcre, libpcap-dev, libnet-dev, libyaml-dev, zlib, libcap-ng-dev, libjansson-dev тощо), завантаження tar-архіву з офіційного веб-сайту та запуск класичної команди ./configure, make, make install.
Під час фази налаштування скрипт вкаже, які функції підтримки було ввімкнено: AF_PACKET так/ні, PF_RING, NFQUEUE так/ні, NFLOG, IPFW, підтримка libnss, libjansson, Prelude, PCRE JIT, Lua, GeoIP тощо. Важливо перевірити, чи ввімкнено NFQUEUE, якщо ми хочемо працювати в цьому режимі , і чи знайдено потрібну нам бібліотеку захоплення.
Після встановлення бінарного файлу ви можете виконати команду `make install-conf` , щоб розгорнути конфігурацію за замовчуванням у `/etc/suricata`, та `make install-rules` , щоб завантажити та розмістити набір правил Emerging Threats у `/etc/suricata/rules`. Ці набори потім можна оновити за допомогою таких інструментів, як `suricata-update`.
У системах Red Hat/CentOS логіка схожа: використання yum або dnf для залежностей (libpcap-devel, pcre-devel, libnet-devel, libyaml-devel, jansson-devel тощо) з подальшою компіляцією за тими ж кроками. З міркувань продуктивності також рекомендується вимкнути LRO/GRO в інтерфейсі захоплення за допомогою ethtool, оскільки ці функції розвантаження можуть впливати на видимість пакетів на рівні IDS.
Конфігурація Suricata: YAML, змінні та потоки
Основна конфігурація Suricata знаходиться у файлі /etc/suricata/suricata.yaml . Це досить читабельний та багатокоментований YAML-файл, де визначено все: від шляхів до журналів та наборів правил до політик цільової операційної системи та параметрів потоків.
Одним із основних полів є `default-log-dir` , яке вказує, де будуть зберігатися файли журналів (за замовчуванням `/var/log/suricata`). У розділі `vars` знаходяться такі змінні, як `HOME_NET`, `EXTERNAL_NET`, `HTTP_PORTS`, `SHELLCODE_PORTS` та `SSH_PORTS`, які служать скороченнями в правилах. `HOME_NET` зазвичай налаштовується з діапазоном локальної мережі, який ми хочемо захистити, тоді як `EXTERNAL_NET` зазвичай визначається як `!HOME_NET`.
Ще однією важливою частиною є host-os-policy , яка повідомляє Suricata, яка операційна система повинна запускати певні діапазони IP-адрес. Це дозволяє їй налаштувати спосіб перезбірки TCP або інтерпретації певної поведінки мережевого стеку , що ускладнює обхід протоколів на основі відмінностей між стеками (Windows проти Linux тощо). Певні діапазони можна призначити таким категоріям, як Windows, Linux, BSD, Vista, Windows 2003 тощо.
Щодо потоків, розділ потоків дозволяє точно налаштувати спорідненість процесора та кількість потоків виявлення. За замовчуванням `set-cpu-affinity` зазвичай вимкнено, що дозволяє системному планувальнику розподіляти потоки між ядрами. Параметр `detect-thread-ratio` вказує, скільки потоків виявлення створюється на кожне доступне ядро; з `detect-thread-ratio: 1.5` на 8-ядерній машині Suricata генеруватиме 12 потоків виявлення, а також потоки захоплення та управління.
Вся ця модель потім відображається у виводі під час запуску демона: видно потік захоплення (наприклад, pcap) та кілька потоків детекторів, а також менеджери потоків та менеджери статистики. Ця багатопроцесорна архітектура дозволяє Suricata масштабуватися набагато краще, ніж однопотокові двигуни, коли стикається з каналами 10/40 Гбіт/с.
Оновлення правил та підписів у Suricata
Suricata покладається на набори правил для виявлення шаблонів атак, аномальної поведінки та неправильного використання протоколів. Окрім прийняття правил у форматі Snort , найпоширенішою екосистемою є Emerging Threats: ET Open (безкоштовна версія) та ET Pro (комерційна версія), з правилами, орієнтованими на поточні загрози.
Багато сучасних дистрибутивів містять інструмент `suricata-update` , який спрощує керування правилами: він оновлює джерела, вмикає або вимикає певних постачальників та завантажує останні версії наборів сигнатур. Типовий робочий процес полягатиме в наступному: встановити `suricata-update` (наприклад, через pip), запустити перший `suricata-update` для завантаження ET Open, переглянути список джерел за допомогою `suricata-update list-sources`, увімкнути додаткові джерела, такі як `ptresearch/attackdetection`, `oisf/trafficid` або `sslbl/ssl-fp-blacklist`, та знову запустити `suricata-update` для повторного створення файлу правил.
Файл suricata.yaml налаштовується так, щоб він вказував на правильний шлях до правил, і звідти Suricata почне генерувати події сповіщень, які будуть реєструватися у fast.log (швидкий, читабельний текст) та eve.json (структурований JSON з дуже повною інформацією) . Цей останній формат особливо корисний для постачання інформаційних панелей, систем кореляції або користувацьких скриптів.
Окрім сигнатур, Suricata містить декодери та парсери для кількох протоколів , що дозволяє їй бути менш залежною від портів: вона може ідентифікувати HTTP-трафік, навіть якщо він проходить через нестандартні порти, виявляти SSH, TLS, DNS тощо через різні порти та рівні інкапсуляції (включаючи змішані тунелі IPv4/IPv6).
Практичне використання: від виявлення веб-експлойтів до автоматичного блокування
Одним із найбажаніших варіантів використання в хостингових середовищах або центрах обробки даних є виявлення в режимі реального часу спроб використання вразливостей у веб-додатках (наприклад, WordPress та його плагінах) та автоматичне реагування, зазвичай шляхом блокування або додавання вихідної IP-адреси до чорного списку у брандмауері.
Suricata, що працює на основі оновлених правил, здатна розпізнавати специфічні шаблони атак на URL-адреси, параметри, корисні навантаження HTTP та навіть послідовності запитів, що відповідають відомим експлойтам. IDS може працювати в пасивному режимі, отримуючи трафік через дзеркалювання з порту комутатора (SPAN), але щоб діяти як IPS та блокувати атаки, вона повинна бути інтегрована з площиною переадресації.
Існує два поширені підходи: налаштування IDS як онлайн-моста, щоб трафік фізично проходив через машину (використовуючи iptables, AF_PACKET або PF, залежно від платформи), або залишення топології як є, але поєднання дзеркалювання з діями на центральному брандмауері через API, скрипти або NFQUEUE . Перший підхід мінімізує затримку між виявленням та блокуванням, ціною додавання ще одного елемента «посередині» мережі; другий пропонує більшу гнучкість та стійкість, але вносить більше складності в оркестрацію.
Цілком можливо, щоб система виявлення вторгнень (IDS) виявила спробу використання вразливого плагіна WordPress, а потім, безпосередньо або через пов'язаний компонент, додала IP-адресу зловмисника до чорного списку iptables. Це можна зробити за допомогою виводу JSON Suricata та скриптів, які викликають iptables/nftables , або шляхом делегування частини логіки NFQUEUE, де сам движок або пов'язаний процес приймає рішення на льоту, не чекаючи оновлення зовнішнього списку.
Це дозволяє зосередитися на дійсно важливих загрозах (експлойти, спроби ескалації, дуже агресивні сканування), ігноруючи або просто реєструючи фоновий шум, такий як базове сканування портів, яке в багатьох випадках саме по собі не викликає занепокоєння.
Suricata на Pfsense: брандмауер з відкритим кодом та інтегрованими IDS/IPS
Не кожен може або хоче дозволити собі власний високоякісний брандмауер, такий як Palo Alto. У багатьох середовищах привабливіше налаштувати рішення з відкритим кодом на основі pfSense та Suricata , яке охоплює як розширені потреби брандмауера (багато WAN, VLAN, VPN, NAT тощо), так і IDS/IPS.
Pfsense, заснований на FreeBSD та Packet Filter, особливо добре працює з віртуалізованими середовищами (Proxmox, KVM тощо), за винятком того, що рекомендується використовувати карти E1000 замість Virtio в KVM-машинах, якщо ви хочете уникнути проблем із продуктивністю та збоїв під навантаженням, якщо ви не застосовуєте рекомендації Netgate (вимкніть розвантаження контрольної суми обладнання в Система > Додатково > Мережа та перезавантажте, знаючи, що цього може бути недостатньо при дуже високих навантаженнях).
Мінімальні вимоги до обладнання для лабораторії з Suricata на Pfsense можуть бути скромними (1 процесор 500 МГц, 1 ГБ оперативної пам'яті, 4 ГБ диска), але для серйозного використання рекомендується щонайменше 2 процесори, 4 ГБ оперативної пам'яті та 16 ГБ сховища , не забуваючи про наявність кількох мережевих інтерфейсів (один для WAN, інший для LAN, більше, якщо вам потрібно кілька WAN або складних VLAN).
Встановлення pfSense відбувається дуже швидко: ви завантажуєтесь з ISO-образу, приймаєте ліцензію, обираєте встановлення, вибираєте мову та розкладку клавіатури, залишаєте розбиття на розділи автоматичним (Auto UFS, якщо ви збираєтеся використовувати весь диск), і за кілька хвилин система готова до першого завантаження. Консоль пропонує меню для призначення інтерфейсів, перезавантаження, запуску оболонки тощо.
У лабораторних роботах, наприклад, у VirtualBox, зазвичай тимчасово вимикають брандмауер Pfsense з консолі за допомогою pfctl -d, щоб отримати доступ до веб-інтерфейсу через WAN (ім'я користувача admin, пароль pfsense) та виконати початковий майстер налаштування: загальні дані, NTP-сервери, конфігурація WAN (DHCP зазвичай достатньо в лабораторних роботах), локальна мережа, зміна пароля адміністратора та застосування конфігурації.
Після стабілізації доступу ви можете створити правило у брандмауері WAN, яке дозволяє HTTPS з будь-якого джерела на IP-адресу pfsense, додавши описові роздільники для візуального впорядкування правил (наприклад, «Доступ до брандмауера»). Також бажано вимкнути опцію блокування приватних мереж у WAN, якщо ви перебуваєте в тестовому середовищі з адресами RFC1918, щоб уникнути необхідності постійного використання `pfctl -d`.
Встановлення Suricata на pfSense та огляд
З запущеною базою pfSense встановлення Suricata відбувається так само просто, як перехід до Система > Менеджер пакетів > Доступні пакети , пошук Suricata та встановлення пакета. Процес завантаження кількох файлів може зайняти деякий час залежно від вашого обладнання, але він повністю підтримується веб-інтерфейсом.
Після встановлення на вкладці «Служби» з’явиться запис Suricata, де можна налаштувати екземпляри за інтерфейсом (WAN, LAN, VLAN тощо), вибрати набори правил для використання, активувати режим IDS або IPS , а також налаштувати параметри продуктивності та ведення журналу. Діапазон опцій широкий (достатньо для цілих статей лише про налаштування), але перевага полягає в тому, що багато завдань, які в Linux потребують ручного редагування YAML, обробляються тут за допомогою форм і прапорців.
Важливе зауваження: Хоча в лабораторному середовищі може виникнути спокуса відкрити адміністрування pfSense безпосередньо в Інтернеті, у робочому середовищі вкрай важливо обмежити доступ до статичних IP-адрес, використовувати VPN для віддаленого керування та уникати відкритого доступу до веб-консолі будь-якою ціною . pfSense дуже гнучкий, але до нього також слід ставитися як до критично важливого елемента.
З увімкненням Suricata на pfSense ви отримуєте середовище, де трафік проходить через pfSense для брандмауера та NAT, а Suricata перевіряє його відповідно до своїх правил і може блокувати в режимі IPS . Таке поєднання, кероване з єдиного веб-інтерфейсу, значно спрощує розгортання захисту DPI в мережах малого та середнього розміру.
У багатьох розгортаннях це доповнюється підключенням Pfsense/Suricata до SIEM або централізованої платформи журналів, що дозволяє використовувати структуровані формати виводу для співвіднесення подій та виявлення ширших кампаній.
Моніторинг подій та приклади журналів у Suricata
Після запуску Suricata події записуються в журнал за шляхом, визначеним параметром default-log-dir, зазвичай це /var/log/suricata . Файл fast.log використовує компактний текстовий формат з позначками часу, ідентифікаторами правил, класифікаціями та пріоритетом, що підходить для швидкої перевірки з терміналу (tail -f).
Наприклад, зіткнувшись із трафіком із неправильними контрольними сумами TCP, ми можемо побачити такі рядки: позначки часу з датою та часом, а потім ідентифікатор правила (наприклад, 1:2200074:1), повідомлення «SURICATA TCPv4 недійсна контрольна сума», класифікація, пріоритет та пара IP/порт джерела-приймача. Ці типи сповіщень дозволяють швидко ідентифікувати проблеми цілісності пакетів або спроби ухилення.
Файл eve.json містить ті самі події у форматі JSON, з такими полями, як timestamp, event_type, src_ip, dest_ip, src_port, dest_port, proto, та підфайлом сповіщень з action, gid, signature_id, rev, signature, category та severity. Цей формат можна легко використовувати за допомогою Logstash, Fluentd, Filebeat або будь-якого іншого агента журналів , що дозволяє отримувати набагато багатшу аналітику, ніж просто використовувати звичайний текст.
Під час розгортання Suricata на багатоядерному сервері (наприклад, 8 ядер) стиснення потоків легко помітне в таких інструментах, як htop, у режимі потоків, показуючи один або кілька потоків захоплення (pcap, AF_PACKET або NFQ) та велику кількість потоків виявлення, розподілених по ядрах. Налаштування співвідношення потоків виявлення та спорідненості процесора може суттєво вплинути на пропускну здатність та затримку, коли обсяг трафіку наближається до меж платформи.
Перш ніж розгортати його у продакшені, рекомендується витратити деякий час на налаштування активованих наборів правил , щоб уникнути потоку хибних спрацьовувань, які можуть блокувати легітимний трафік або захаращувати журнали. Suricata-update дозволяє вимикати цілі категорії або окремі правила, щоб знайти розумний баланс між чутливістю та зручністю використання.
Спеціальні програми: VoIP, аудіоаналітика та креативна NFQUEUE
Окрім класичних застосувань (захист веб-сервісів, виявлення шкідливого програмного забезпечення, аналіз DDoS-атак), дует Netfilter+NFQUEUE дозволяє створювати досить креативні рішення в таких сферах, як VoIP. Наприклад, можна налаштувати фільтр anti-SPIT (спам через IP-телефонію) або систему цензурування ненормативної лексики в RTP-потоках.
Ідея полягала б у наступному: ідентифікувати RTP-трафік за портами або розпізнаванням протоколу та надіслати його до NFQUEUE; з користувацького застосунку реконструювати RTP-потік за допомогою бібліотеки, такої як librtp , витягти аудіо у форматі WAV та передати його до механізму розпізнавання ключових слів (wordspotting), такого як бібліотека синтезу або розпізнавання, що пропонується третьою стороною.
На основі виявлених слів процес NFQUEUE може вирішити дозволити, заблокувати або навіть змінити відтворення, вставивши звуковий сигнал у потік, хоча останнє вимагає дуже точного контролю RTCP, послідовностей пакетів та таймінгів — майже підходу «людина посередині». Це не тривіально, але теоретично цілком досяжно, використовуючи ту саму систему черги та вердиктів.
Це правда, що частково це можна зробити за допомогою простого сніфера, який передає дані зовнішньому процесору, а потім впливає на сигналізацію SIP або через SBC (Asterisk, Kamailio тощо). Різниця у використанні NFQUEUE полягає в тому, що дія на потік RTP може бути негайною та безпосередньою , без необхідності координувати кілька компонентів або чекати, поки рівень сигналізації завершить виклик.
Ці сценарії чітко ілюструють потенціал комбінації GNU/Linux + Netfilter + Suricata + сторонніх бібліотек: справа не лише в блокуванні портів та IP-адрес, а й в оркестрації складних рішень щодо трафіку в режимі реального часу з використанням екосистеми повністю вільного програмного забезпечення.
Дивлячись на весь шлях, від невеликої програми на C, яка завжди приймає пакети, до багатопроцесорного розгортання Suricata, інтегрованого з NFQUEUE, Pfsense, базами даних та кешами, можна оцінити гнучкість, яку пропонує цей технологічний стек для побудови всього: від простих динамічних брандмауерів до архітектур IDS/IPS масштабу центрів обробки даних, з реальними можливостями глибокого інспектування та автоматизованим реагуванням на дедалі складніші атаки.