Snort и Suricata — обзор и настройка популярных IDPS

Рассказываем, что такое системы IDPS и какие они бывают, а также показываем, как их разворачивать на виртуальных серверах.

Межсетевые экраны — один из первых эшелонов защиты интернет-сервисов с довольно широким функционалом по безопасности. В их состав обычно входит класс решений IDPS, который позволяет с высокой точностью определять нелегитимные запросы и блокировать их.

В этом материале рассказываем, что такое системы IDPS и какие они бывают. А также показываем, как их разворачивать на виртуальных серверах и настраивать сигнатуры для блокирования вредоносного трафика. Все инструкции — на примере Snort и Suricata. Подробности под катом.

Знакомство с IDPS

Intrusion Detection and Prevention System, IDPS — это системы обнаружения и предотвращения вторжения. По сути, IDPS мониторит транзитный и локальный трафик на попытки сканирования и атак, соотнося их с имеющимися сигнатурами. Если трафик «зловредный» — он блокируется.

IDPS можно разделить на два класса: NIDS (Network Intrusion Detection System) и HIDS (Host-based Intrusion Detection). Первые мониторят сетевой трафик, в то время как вторые анализируют события хоста, в том числе приходящий и уходящий трафик внутри систем.

Как видно из названия, NIDS необходимо ставить на хосты, управляющие трафиком, а HIDS больше подходят для endpoint-хостов с локальными сервисами. Более подробно о классификации и особенностях IDPS-систем можно почитать в Академии Selectel.

В рамках статьи покажем, как начать работать с двумя представителями систем IDPS:

Suricata (как инстанс в Ubuntu 20.04) — это высокопроизводительный софт для анализа трафика и поиска угроз;
Snort (как пакет в pfSense 2.6.0) — это один из самых популярных IDPS с открытым исходным кодом.

Между этими решениями есть одно важное отличие. Snort работает только в однопоточном режиме, в то время как Suricata может запускаться в многопоточных сценариях и позволяет обрабатывать больше трафика одномоментно.

Сетевая схема на базе Suricata

В рамках статьи рассмотрим схемы включения IDPS в «разрыв».

В данной схеме между целевым веб-сервером и интернетом установлена IDPS. То есть маршрутизацию и проброс портов обеспечивает именно хост с IDPS. Таким образом, правильно настроив систему, можно блокировать трафик при срабатывании сигнатур.

Настройка хоста

Для начала развернем виртуальный сервер с Ubuntu — хост для IDPS. Это можно сделать за несколько кликов: регистрируемся и входим в панель управления, переходим в раздел Облачная платформа, выбираем Серверы и настраиваем конфигурации.

Создать облачный сервер

Выведем доступные сетевые интерфейсы. Один из них будет вести в интернет, а второй — в локальную сеть, ему необходимо назначить свободный адрес.


    eth1: inet 192.168.1.254/24 brd 192.168.1.255 scope global eth1


    $ sudo iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 80 -j DNAT --to-destination 192.168.1.2:80
$ sudo iptables -A FORWARD -p tcp -d 192.168.1.2 --dport 80 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
$ sudo iptables-save > /etc/iptables/rules.v4

Теперь настроим для локальной сети выход в интернет и заранее «опубликуем» веб-сервер наружу:


    $ sudo echo 1 > /proc/sys/net/ipv4/ip_forward
$ sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Вторым этапом развернем хост для веб-сервера, на который поставим Nginx и проверим доступность снаружи:


    $ sudo apt install nginx -y
$ curl http://45.145.64.243

Вот что должен вернуть cURL запрос к Nginx:


    <!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
    body {
        width: 35em;
        margin: 0 auto;
        font-family: Tahoma, Verdana, Arial, sans-serif;
    }

<h1>Welcome to nginx!</h1>
If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.
For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.
<em>Thank you for using nginx.</em>
</body>
</html>

Отлично — страница отвечает, в логах Nginx можно увидеть подобные обращения:


    $ tail -f /var/log/nginx/access.log 
- - [25/Jun/2023:10:05:15 +0000] "PROPFIND / HTTP/1.1" 400 166 "-" "-"
- - [25/Jun/2023:10:05:15 +0000] "TRACE / HTTP/1.0" 405 166 "-" "Mozilla/5.00 (Nikto/2.1.5) (Evasions:None) (Test:httpoptions: TRACE)"
- - [25/Jun/2023:10:05:15 +0000] "TRACE / HTTP/1.0" 405 166 "-" "Mozilla/5.00 (Nikto/2.1.5) (Evasions:None) (Test:httpoptions: TRACE)"
- - [25/Jun/2023:10:05:15 +0000] "TRACK / HTTP/1.0" 405 166 "-" "Mozilla/5.00 (Nikto/2.1.5) (Evasions:None) (Test:httpoptions: TRACK)"
- - [25/Jun/2023:10:05:15 +0000] "TRACK / HTTP/1.0" 405 166 "-" "Mozilla/5.00 (Nikto/2.1.5) (Evasions:None) (Test:httpoptions: TRACK)"
- - [25/Jun/2023:10:05:15 +0000] "GET /TiVoConnect?Command=QueryServer HTTP/1.1" 404 162 "-" "Mozilla/5.00 (Nikto/2.1.5) (Evasions:None) (Test:000001)"
- - [25/Jun/2023:10:05:15 +0000] "GET /TiVoConnect?Command=QueryContainer&Container=/&Recurse=Yes HTTP/1.1" 404 162 "-" "Mozilla/5.00 (Nikto/2.1.5) (Evasions:None) (Test:000002)"
- - [25/Jun/2023:10:05:15 +0000] "GET /cfappman/index.cfm HTTP/1.1" 404 162 "-" "Mozilla/5.00 (Nikto/2.1.5) (Evasions:None) (Test:000013)"
- - [25/Jun/2023:10:05:15 +0000] "GET /cfdocs/examples/cvbeans/beaninfo.cfm HTTP/1.1" 404 162 "-" "Mozilla/5.00 (Nikto/2.1.5) (Evasions:None) (Test:000014)"
- - [25/Jun/2023:10:05:15 +0000] "GET /cfdocs/examples/parks/detail.cfm HTTP/1.1" 404 162 "-" "Mozilla/5.00 (Nikto/2.1.5) (Evasions:None) (Test:000015)"

Сервер начали сканировать — надо поспешить настроить IDPS. Система позволит отслеживать и блокировать обращения, которые будут совпадать с сигнатурами атак. Давайте поставим решение Suricata на хост.

Установка Suricata

Для начала скачаем необходимые зависимости.


    $ sudo apt install libpcre3 libpcre3-dbg libpcre3-dev build-essential libpcap-dev libnet1-dev libyaml-0-2 libyaml-dev pkg-config zlib1g zlib1g-dev libcap-ng-dev libcap-ng0 make libmagic-dev libjansson-dev libnss3-dev libgeoip-dev liblua5.1-dev libhiredis-dev libevent-dev python-yaml rustc cargo

Теперь у нас есть два способа, как установить систему Suricata на хост.

1. Сборка из исходников

Первый способ довольно простой: достаточно просто скачать архив и распаковать из него Suricata.


    $ wget https://www.openinfosecfoundation.org/download/suricata-6.0.13.tar.gz
$ ls
suricata-6.0.13.tar.gz
$ tar xzvf suricata-6.0.13.tar.gz
$ cd suricata-6.0.13
$ sudo ./configure --prefix=/usr/ --sysconfdir=/etc/ --localstatedir=/var/
$ sudo make
$ sudo make install

2. Установка из PPA

Второй способ — установить Suricata из Personal Package Archive, PPA. Это специальный репозиторий с open source-проектами разных компаний, в том числе разработчиков Suricata (OSIF).


    $ sudo add-apt-repository ppa:oisf/suricata-stable
$ sudo apt-get update
$ sudo apt-get install suricata

Супер! Suricata установлена на хосте. Это можно проверить, введя suricata -V — специальную команду, которая возвращает версию установленной системы.

Обновление

После установки Suricata важно обновить правила (сигнатуры) и их источники:


    root@suricata:~/suricata-6.0.12# suricata-update
</source lang="bash">
<spoiler title="Результат корректного обновления правил ↓">
<source lang="bash">
25/6/2023 -- 11:54:49 - <Info> -- Using data-directory /var/lib/suricata.
25/6/2023 -- 11:54:49 - <Info> -- Using Suricata configuration /etc/suricata/suricata.yaml
25/6/2023 -- 11:54:49 - <Info> -- Using /usr/share/suricata/rules for Suricata provided rules.
25/6/2023 -- 11:54:49 - <Info> -- Found Suricata version 6.0.13 at /usr/bin/suricata.
25/6/2023 -- 11:54:49 - <Info> -- Loading /etc/suricata/suricata.yaml
25/6/2023 -- 11:54:49 - <Info> -- Disabling rules for protocol http2
25/6/2023 -- 11:54:49 - <Info> -- Disabling rules for protocol modbus
25/6/2023 -- 11:54:49 - <Info> -- Disabling rules for protocol dnp3
25/6/2023 -- 11:54:49 - <Info> -- Disabling rules for protocol enip
25/6/2023 -- 11:54:49 - <Info> -- No sources configured, will use Emerging Threats Open
25/6/2023 -- 11:54:49 - <Info> -- Fetching https://rules.emergingthreats.net/open/suricata-6.0.13/emerging.rules.tar.gz.
 100% - 3949155/3949155               
25/6/2023 -- 11:54:50 - <Info> -- Done.
25/6/2023 -- 11:54:50 - <Info> -- Loading distribution rule file /usr/share/suricata/rules/app-layer-events.rules
25/6/2023 -- 11:54:50 - <Info> -- Loading distribution rule file /usr/share/suricata/rules/decoder-events.rules
25/6/2023 -- 11:54:50 - <Info> -- Loading distribution rule file /usr/share/suricata/rules/dhcp-events.rules
25/6/2023 -- 11:54:50 - <Info> -- Loading distribution rule file /usr/share/suricata/rules/dnp3-events.rules
25/6/2023 -- 11:54:50 - <Info> -- Loading distribution rule file /usr/share/suricata/rules/dns-events.rules
25/6/2023 -- 11:54:50 - <Info> -- Loading distribution rule file /usr/share/suricata/rules/files.rules
25/6/2023 -- 11:54:50 - <Info> -- Loading distribution rule file /usr/share/suricata/rules/http-events.rules
25/6/2023 -- 11:54:50 - <Info> -- Loading distribution rule file /usr/share/suricata/rules/ipsec-events.rules
25/6/2023 -- 11:54:50 - <Info> -- Loading distribution rule file /usr/share/suricata/rules/kerberos-events.rules
25/6/2023 -- 11:54:50 - <Info> -- Loading distribution rule file /usr/share/suricata/rules/modbus-events.rules
25/6/2023 -- 11:54:50 - <Info> -- Loading distribution rule file /usr/share/suricata/rules/nfs-events.rules
25/6/2023 -- 11:54:50 - <Info> -- Loading distribution rule file /usr/share/suricata/rules/ntp-events.rules
25/6/2023 -- 11:54:50 - <Info> -- Loading distribution rule file /usr/share/suricata/rules/smb-events.rules
25/6/2023 -- 11:54:50 - <Info> -- Loading distribution rule file /usr/share/suricata/rules/smtp-events.rules
25/6/2023 -- 11:54:50 - <Info> -- Loading distribution rule file /usr/share/suricata/rules/stream-events.rules
25/6/2023 -- 11:54:50 - <Info> -- Loading distribution rule file /usr/share/suricata/rules/tls-events.rules
25/6/2023 -- 11:54:51 - <Info> -- Ignoring file rules/emerging-deleted.rules
25/6/2023 -- 11:54:53 - <Info> -- Loaded 43346 rules.
25/6/2023 -- 11:54:53 - <Info> -- Disabled 14 rules.
25/6/2023 -- 11:54:53 - <Info> -- Enabled 0 rules.
25/6/2023 -- 11:54:53 - <Info> -- Modified 0 rules.
25/6/2023 -- 11:54:53 - <Info> -- Dropped 0 rules.
25/6/2023 -- 11:54:54 - <Info> -- Enabled 131 rules for flowbit dependencies.
25/6/2023 -- 11:54:54 - <Info> -- Backing up current rules.
25/6/2023 -- 11:54:57 - <Info> -- Writing rules to /var/lib/suricata/rules/suricata.rules: total: 43346; enabled: 34518; added: 0; removed 0; modified: 14
25/6/2023 -- 11:54:57 - <Info> -- Writing /var/lib/suricata/rules/classification.config
25/6/2023 -- 11:54:57 - <Info> -- Testing with suricata -T.
25/6/2023 -- 11:55:23 - <Info> -- Done.
root@suricata:~/suricata-6.0.12# suricata-update update-sources
25/6/2023 -- 11:56:27 - <Info> -- Using data-directory /var/lib/suricata.
25/6/2023 -- 11:56:27 - <Info> -- Using Suricata configuration /etc/suricata/suricata.yaml
25/6/2023 -- 11:56:27 - <Info> -- Using /usr/share/suricata/rules for Suricata provided rules.
25/6/2023 -- 11:56:27 - <Info> -- Found Suricata version 6.0.13 at /usr/bin/suricata.
25/6/2023 -- 11:56:27 - <Info> -- Downloading https://www.openinfosecfoundation.org/rules/index.yaml
25/6/2023 -- 11:56:28 - <Info> -- Adding all sources
25/6/2023 -- 11:56:28 - <Info> -- Saved /var/lib/suricata/update/cache/index.yaml

Далее в файле /etc/default/suricata сверим значение параметра IFACE с именем внешнего интерфейса хоста:


    $ cat /etc/default/suricata | grep IFACE
IFACE=eth0
$ ip a
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether fa:16:3e:29:e3:e3 brd ff:ff:ff:ff:ff:ff
    inet 45.145.64.243/29 brd 45.145.64.247 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::f816:3eff:fe29:e3e3/64 scope link 
       valid_lft forever preferred_lft forever

Названия интерфейсов совпадают, идем дальше. Проверим, чтобы это же значение стояло в файле /etc/suricata/suricata.yaml в блоках pcap, pfring и af-packet. По умолчанию там установлено eth0 — совпадает с именем внешнего интерфейса.

Конфигурирование

Основным конфигурационным файлом Suricata является /etc/suricata/suricata.yaml— откроем его и поправим настройки. В блоке outputs включим вывод данных:


    outputs:
  # a line based alerts log similar to Snort's fast.log
  - fast:
      enabled: yes
      filename: fast.log
      append: yes
- eve-log:
      enabled: yes
      filetype: regular #regular|syslog|unix_dgram|unix_stream|redis
      filename: eve.json
      types:
        - alert:
            payload: yes             # enable dumping payload in Base64
            # payload-buffer-size: 4kb # max size of payload buffer to output in eve-log
            # payload-printable: yes   # enable dumping payload in printable (lossy) format
            # packet: yes              # enable dumping of packet (without stream segments)
            # metadata: no             # enable inclusion of app layer metadata with alert. Default yes
            http-body: yes           # Requires metadata; enable dumping of HTTP body in Base64
  - http-log:
      enabled: yes
      filename: http.log
      append: yes

Проверить валидность файла конфигураций можно с помощью команды suricata -T -c /etc/suricata/suricata.yaml -v.

Результат проверки конфигурации:


    25/6/2023 -- 12:26:54 - <Info> - Running suricata under test mode
25/6/2023 -- 12:26:54 - <Notice> - This is Suricata version 6.0.13 RELEASE running in SYSTEM mode
25/6/2023 -- 12:26:54 - <Info> - CPUs/cores online: 2
25/6/2023 -- 12:26:54 - <Info> - Setting engine mode to IDS mode by default
25/6/2023 -- 12:26:54 - <Info> - fast output device (regular) initialized: fast.log
25/6/2023 -- 12:26:54 - <Info> - eve-log output device (regular) initialized: eve.json
25/6/2023 -- 12:26:54 - <Info> - http-log output device (regular) initialized: http.log
25/6/2023 -- 12:26:54 - <Info> - alert-debug output device (regular) initialized: alert-debug.log
25/6/2023 -- 12:26:54 - <Info> - stats output device (regular) initialized: stats.log
25/6/2023 -- 12:27:05 - <Info> - 2 rule files processed. 34519 rules successfully loaded, 0 rules failed
25/6/2023 -- 12:27:05 - <Info> - Threshold config parsed: 0 rule(s) found
25/6/2023 -- 12:27:06 - <Info> - 34522 signatures processed. 1280 are IP-only rules, 5229 are inspecting packet payload, 27806 inspect application layer, 108 are decoder event only
25/6/2023 -- 12:27:20 - <Notice> - Configuration provided was successfully loaded. Exiting.
25/6/2023 -- 12:27:20 - <Info> - cleaning up signature grouping structure... complete

Если открыть лог-файлы, вы увидите обращения к веб-серверу, которые фиксирует Suricata. Это связано с тем, что в большинстве правил этой IDPS-системы указано действие alert. Чтобы Suricata не просто логировала подозрительный трафик, но и блокировала его, нужно добавить действие drop в сигнатурах, которые находятся по адресу /var/lib/suricata/rules. В этом же каталоге можно создавать файлы со своими правилами.


    $ tail -f /var/log/suricata/http.log 
06/25/2023-12:33:15.638309 45.145.64.243[**]/[**]Mozilla/5.00 (Nikto/2.1.5) (Evasions:None) (Test:Port Check)[**]109.207.173.75:51566 -> 45.145.64.243:80
06/25/2023-12:33:15.763447 45.145.64.243[**]/[**]Mozilla/5.00 (Nikto/2.1.5) (Evasions:None) (Test:getinfo)[**]109.207.173.75:51566 -> 45.145.64.243:80
06/25/2023-12:33:15.799758 45.145.64.243[**]/[**]Mozilla/5.00 (Nikto/2.1.5) (Evasions:None) (Test:map_codes)[**]109.207.173.75:51566 -> 45.145.64.243:80
06/25/2023-12:33:15.836635 45.145.64.243[**]/dpyyI9SK.link[**]Mozilla/5.00 (Nikto/2.1.5) (Evasions:None) (Test:map_codes)[**]109.207.173.75:51566 -> 45.145.64.243:80
06/25/2023-12:33:15.873426 45.145.64.243[**]/dpyyI9SK.de[**]Mozilla/5.00 (Nikto/2.1.5) (Evasions:None) (Test:map_codes)[**]109.207.173.75:51566 -> 45.145.64.243:80
06/25/2023-12:33:15.909272 45.145.64.243[**]/dpyyI9SK.nlm[**]Mozilla/5.00 (Nikto/2.1.5) (Evasions:None) (Test:map_codes)[**]109.207.173.75:51566 -> 45.145.64.243:80
06/25/2023-12:33:15.945103 45.145.64.243[**]/dpyyI9SK.var[**]Mozilla/5.00 (Nikto/2.1.5) (Evasions:None) (Test:map_codes)[**]109.207.173.75:51566 -> 45.145.64.243:80
06/25/2023-12:33:15.980823 45.145.64.243[**]/dpyyI9SK.pm[**]Mozilla/5.00 (Nikto/2.1.5) (Evasions:None) (Test:map_codes)[**]109.207.173.75:51566 -> 45.145.64.243:80
06/25/2023-12:33:16.016680 45.145.64.243[**]/dpyyI9SK.config[**]Mozilla/5.00 (Nikto/2.1.5) (Evasions:None) (Test:map_codes)[**]109.207.173.75:51566 -> 45.145.64.243:80
06/25/2023-12:33:16.053655 45.145.64.243[**]/dpyyI9SK.jsp[**]Mozilla/5.00 (Nikto/2.1.5) (Evasions:None) (Test:map_codes)[**]109.207.173.75:51566 -> 45.145.64.243:80
06/25/2023-12:33:16.089380 45.145.64.243[**]/dpyyI9SK.pwd[**]Mozilla/5.00 (Nikto/2.1.5) (Evasions:None) (Test:map_codes)[**]109.207.173.75:51566 -> 45.145.64.243:80

Сетевая схема на базе Snort

В данной схеме, как и в первой, есть промежуточный маршрутизатор pfSense, на котором настроен NAT для выхода веб-сервера в интернет. А также port-forwarding для доступа к службе веб-сервера снаружи.

Внутри репозиториев pfSense есть пакет snort, который мы установим и настроим в режиме мониторинга. Таким образом, мы сможем наблюдать срабатывания IDS, но трафик до сервера блокироваться не будет.

В качестве IDS для второй схемы рассмотрим Snort — вероятно, самый популярный open source-IDPS. Давайте соберем целевую схему и посмотрим, как работать с этой системой.

Запуск хоста с веб-сервером

Разворачиваем хост для IDPS. Создаем сервер и настраиваем произвольную конфигурацию. Оптимальный вариант — 2 ядра vCPU, 4 ГБ ОЗУ, универсальный SSD-диск и Ubuntu в качестве операционной системы.

Далее подключаемся к виртуальной машине из консоли панели управления и меняем адрес шлюза по умолчанию на 192.168.0.254. Это будущий LAN-адрес хоста с Snort.


    # ip route replace default via 192.168.0.254 dev eth0

После переключения трафика сервера на pfSense обновим локальную копию списка пакетов в репозиториях и поставим Nginx. А после — проверим доступность веб-сервера снаружи с помощью cURL-запроса.


    # apt update && apt install nginx -y
$ curl http://45.145.64.242/

Запуск второго хоста

Теперь развернем второй хост, но уже с системой Snort. В качестве него может выступить, например, Linux-сервер, виртуальная машина с pfSense или межсетевой экран Selectel.

В рамках теста развернем виртуальную машину с pfSense 2.6 — ее также можно создать через панель управления. Сначала скачаем образ pfsense с официального сайта, а после — загрузим в хранилище образов.

Во время настройки конфигурации нужно выбрать загруженный образ в разделе Источник. Далее все стандартно: для сервера с pfSense будет достаточно 4 ядер vCPU, 8 ГБ ОЗУ и универсального SSD на 50 ГБ.

После включения хоста назначаем адресацию, как указано на целевой схеме выше.

Супер! Теперь нужно провести первичную инициализацию pfSense, изменить пароль администратора — и pfSense готов к работе:

Наиболее подробно мы рассказали о настройке pfSense в отдельной статье.

Настроим проброс порта 80/TCP с Nginx в интернет. Это можно сделать в разделе Port Forward внутри панели pfSense.

Установка и настройка Snort

Хост подготовлен к установке Snort. Это можно сделать через менеджер пакетов в pfSense. На данный момент в репозиториях доступна версия Snort 2.9.20.

Отлично! Теперь идем в раздел конфигурирования Snort и настраиваем обновления сигнатур в разделе Global Settings:

В Snort есть несколько категорий сигнатур — community, registered и subscription. Подробнее о каждой можно узнать на официальном сайте.

Все архивы с сигнатурами Snort подтягивает из следующих репозиториев: SNORT_ENFORCING_RULES, ET_BASE_DNLD_URL, SNORT_GPLV2_DNLD, SNORT_OPENAPPID_DNLD_URL, SNORT_OPENAPPID_RULES, SNORT_ENFORCING_RULES, FEODOTRACKER.

Сигнатуры Snort можно использовать в качестве правил для Suricata. Также их можно конвертировать в сигнатуры для других IDPS-систем — например, с помощью fortios-ips-snort ретранслировать правила из Snort для Fortigate.

Далее необходимо установить параметры детектирования трафика в разделе Snort Interface.

Pattern Match — алгоритм обнаружения подозрительных запросов; Blocking Mode — способ блокирования. По умолчанию можно установить на DISABLED.

В логах Snort (раздел Alerts) будет информация о выявленном вредоносном трафике, приходящим на наш опубликованный веб-сервер:

В описании алертов можно найти краткую информацию о найденных атаках. Также на сайте Snort есть более подробное описание — например, WEBROOT DIRECTORY TRAVERSAL и UNESCAPED SPACE IN HTTP URI.

Snort, как и Suricata, умеет блокировать IP-адрес источника атаки — это можно настроить в разделе Snort Interfaces/Block Settings:

А что насчет отправки логов, например, в собственную SIEM? Тут схема такая: Snort умеет отправлять данные в System Log, а pfSense — пересылать логи на удаленный syslog-сервер. Настраивается это довольно просто.

1. Настраиваем логирование в Snort:

2. Включаем отправку логов на внешний syslog-сервер:

Настройка IDPS и применение сигнатур — не самая сложная задача, но крайне полезная, если вы заботитесь о безопасности своих сервисов. Важно понимать, что это не панацея от взлома, но важный элемент эшелонированной защиты инфраструктуры.

Информационная безопасность и 152-ФЗ Облачные серверы Сетевые технологии

Snort и Suricata — обзор и настройка популярных IDPS

Знакомство с IDPS

Межсетевые экраны

Сетевая схема на базе Suricata

Настройка хоста

Установка Suricata

Обновление

Конфигурирование

Сетевая схема на базе Snort

Запуск хоста с веб-сервером

Запуск второго хоста

Установка и настройка Snort

Зарегистрируйтесь в панели управления

Читайте также:

Брокеры сообщений на практике: как подключиться и пользоваться RabbitMQ в Python

Утечки информации: виды, причины и каналы

Выделенный и облачный серверы: создание, настройка, сетевая связность