Полноценную защиту корпоративной инфраструктуры сегодня сложно представить без коммерческих средств защиты информации. Однако далеко не каждая компания может позволить себе сразу построить подобный стек. Стартапы, небольшие организации, компании с ограниченным бюджетом зачастую вынуждены искать компромиссные решения и использовать open source.
В одной из прошлых статей я рассказывал об open source-сканерах уязвимостей. В этот раз предлагаю остановиться на защитных решениях и попробовать собрать на базе open source минимальный стек, который поможет закрыть базовые задачи информационной безопасности.
Прежде чем переходить к конкретным бесплатным инструментам, хочу пару слов сказать о том, какой набор задач я предлагаю считать базовым уровнем защиты инфраструктуры. Если совсем упростить, то любой минимальный стек ИБ должен закрывать несколько направлений. Во-первых, защиту конечных точек, чтобы обнаруживать вредоносное ПО и компрометацию рабочих станций. Во-вторых, защиту сетевого периметра и контроль сетевого трафика. В-третьих— централизованный сбор и анализ событий безопасности, чтобы понимать, что происходит в инфраструктуре, а не искать информацию по журналам каждого сервера вручную. И, наконец, управление доступом пользователей, ведь безопасность начинается не только с обнаружения атак, но и с правильной аутентификации и разграничения прав.
Сразу оговорюсь, что речь не идет о полной замене коммерческих средств защиты. Скорее, это отправная точка для тех, кто хочет выстроить защиту небольшой инфраструктуры или разобраться, какие open source-решения сегодня существуют на рынке и какие задачи они способны решать.
Антивирусная защита
Начну с самого базового компонента — антивирусной защиты. Конечно, ни один open source-антивирус не сможет полностью заменить коммерческие решения вроде Kaspersky или Symantec. В первую очередь из-за отсутствия централизованного управления, развитых механизмов обнаружения угроз и ряда функций, которые сегодня стали стандартом для корпоративных продуктов.
Тем не менее, если необходимо обеспечить минимальную защиту рабочих станций, серверов или почтового шлюза, можно обратить внимание на ClamAV. Это один из самых известных open source-антивирусов с кроссплатформенным движком, который поддерживает Linux, Windows и macOS. Для Windows также доступна графическая оболочка ClamWin.
Кроме защиты конечных точек, ClamAV нередко используют как средство проверки почтового трафика и файловых хранилищ. При этом стоит учитывать, что из-за отсутствия централизованного управления такое решение может не подойти для крупных инфраструктур.
Помимо ClamAV можно обратить внимание на OpenAntiVirus Project или KicomAV.
Как работать с ClamAV
Установить ClamAV можно, скачав дистрибутив с официального сайта.
На Windows установка выполняется стандартным способом через установочный файл. На Linux потребуется воспользоваться пакетным менеджером:
apt-get update
apt-get install clamav clamav-daemon
Эти команды подгрузят сам антивирус и два дополнительных сервиса: clamav-freshclam и clamav-daemon. Первый отвечает за автоматическое обновление антивирусных баз, второй — обеспечивает работу сервиса.
После установки можно проверить состояние сервисов с помощью следующих команд:
systemctl status clamav-freshclamsystemctl status clamav-daemon
Если сервисы не запустились автоматически, их можно перезапустить вручную. Делается это следующей командой:
service clamav-freshclam stop
freshclam
Для проверки файлов ClamAV использует утилиту clamscan. На Linux сканирование выполняется командой clamscan -r ~/clamav-test.
На Windows для проверки файлов необходимо запустить clamscan с параметром рекурсивного сканирования и указать путь к проверяемому файлу ./clamscan --recursive D:\ib
Защита сетевого периметра
Фаерволов, работающих на базе open source, существует гораздо больше, чем антивирусов. Среди наиболее известных я бы выделил три:
pfSense — один из самых популярных open source-firewall, построенный на базе FreeBSD, системы пакетной фильтрации PF (Packet Filter) и сетевого стека FreeBSD. Данный проект развивается компанией Netgate;
OPNsense — форк pfSense;
Squid — прокси-сервер, который нельзя в полной мере назвать фаерволом, но он умеет управлять доступом пользователей к интернет-ресурсам и фильтровать веб-трафик.
В этой статье подробнее остановлюсь на pfSense. Мне нравится этот продукт, поскольку, кроме всего прочего, он позволяет установить к себе «под капот» Snort, Suricata, и Squid для управления веб-трафиком. Хотя установка этих компонентов не превращает pfSense в полноценный NGFW (Next-Generation Firewall), это дает ИБ-специалистам гораздо больше возможностей. Среди основных опций можно выделить:
работу с несколькими интернет-каналами и балансировку нагрузки;
настройку VPN-серверов (IPsec, OpenVPN, L2TP, TINC);
работу в качестве DHCP-сервера и шлюза;
публикацию веб-сервисов через HAProxy;
настройку captive portal для отдельных сценариев авторизации;
отправку журналов событий во внешние системы анализа;
реализацию IDS/IPS на базе Snort и Suricata.
Еще одна полезная фишка pfSense — работа с алиасами, часовыми поясами, GeoIP-фильтрами и другими параметрами, которые помогают гибко настраивать правила доступа.
Настройка IDS/IPS на базе Snort и Suricata
Установка пакета Snort или Suricata в pfSense выполняется через раздел System -> Package Manager -> Available Packages.
После установки выбранного пакета необходимо настроить правила обнаружения атак (Rules). Есть несколько вариантов, как это можно сделать: использовать бесплатные правила ET Open (Emerging Threats) или зарегистрировать ключ для официальных правил Snort VRT (если он у вас есть).
Скачать правила можно по прямой ссылке, а также при помощи команды wget.
При настройке правил важно учитывать разницу между IDS и IPS.
IDS (Intrusion Detection System) только анализирует трафик, фиксирует подозрительные события и создает записи в журналах. IPS (Intrusion Prevention System) работает активнее: система может автоматически блокировать соединения или адреса, которые были определены как потенциально опасные.
После настройки правил и режима блокировки остается подключить передачу журналов во внешнюю систему анализа событий безопасности. В pfSense это настраивается через раздел
Status → System Log → Settings
Там можно выбрать необходимые журналы и указать адрес SIEM-системы, куда они будут отправляться.
Подробнее о настройке и работе со Snort и Suricata, а также в целом с pfSense, можно почитать на этом ресурсе.
Итак, мы уже закрыли два базовых уровня защиты: контроль конечных устройств и сетевого периметра. Но даже хороший фаервол и IDS/IPS не решают задачу анализа событий в инфраструктуре. Для этого нужна система централизованного сбора и анализа журналов безопасности.
Сбор и анализ событий безопасности
В экосистеме open source есть несколько подходов: можно самостоятельно собрать систему анализа событий (SIEM) или использовать готовые платформы, которые объединяют несколько функций безопасности.
Cобираем SIEM своими руками
Один из вариантов построения системы сбора и анализа событий — ELK Stack. Он включает три основных компонента:
Elasticsearch — хранение и быстрый поиск данных;
Logstash — сбор, обработка и обогащение событий;
Kibana — визуализация данных, построение отчетов и настройка правил.
В базовом виде ELK не является полноценной SIEM-системой, однако с помощью дополнительных механизмов на основе этого инструмента можно реализовать многие функции, необходимые для мониторинга безопасности. Например, Logstash и Ingest Pipelines позволяют выполнять первичную обработку событий. В частности, они помогают приводить данные к единому формату, добавлять дополнительный контекст и связывать информацию из разных источников.
Для обнаружения подозрительной активности можно использовать правила корреляции.
Один из самых простых вариантов — пороговые правила (Threshold). Например, система может создать уведомление, если за определенный промежуток времени произошло несколько одинаковых событий: неудачные попытки входа, запросы к одному сервису, подозрительные действия пользователя.
Более сложный вариант — анализ последовательностей событий, когда важно не только количество, но и порядок действий. Например, несколько ошибок авторизации, затем успешный вход, а после этого подозрительная активность пользователя. Для описания таких сценариев можно использовать EQL (Event Query Language).
eql
sequence by source.ip with maxspan=5m
[authentication where event.outcome == "failure" and event.dataset == "system.auth"] [5]
[authentication where event.outcome == "success" and event.dataset == "system.
Комплексный мониторинг безопасности
Если с ELK ИБ-специалистам приходится самостоятельно настраивать правила, источники данных и логику анализа, то Wazuh требует гораздо меньше телодвижений. Это мощный «комбайн», под капотом которого скрывается сканер уязвимостей (про эту возможность я уже рассказывал в прошлой статье), Threat Intelligence, функции контроля целостности файлов и мониторинга конечных устройств, а также EDR.
С помощью Wazuh SIEM можно собирать и анализировать события безопасности из различных источников, генерировать уведомления об инцидентах и строить отчеты.
Отдельного внимания заслуживает TI-модуль, который обогащает данные об обнаруженных событиях и сопоставляет найденные аномалии с известными техниками и тактиками атакующих. Для этого в Wazuh настроена интеграция с MITRE ATT&CK.
В дополнение к Threat Intelligence в Wazuh реализована возможность проактивного поиска угроз (Threat Hunting). Для этого доступны дашборды OpenSearch, маппинг с MITRE ATT&CK и списки IOC, которые пополняются разработчиками проекта. Также можно подключать собственные TI-источники и загружать индикаторы компрометации.
Еще одна в Wazuh есть мониторинг конечных устройств (аналог EDR). Для этого используются встроенный сканер уязвимостей и агент мониторинга.
EDR, встроенный в Wazuh, несколько отличается от классических коммерческих решений этого класса. Агент умеет отслеживать целостность файлов (FIM), контролировать изменения в реестре, анализировать процессы и сетевые соединения, собирать системные журналы Windows Event Log и syslog, выполнять автоматические действия реагирования (Active Response). Например, блокировать IP-адреса или завершать подозрительные процессы.
Однако там всё же отсутствует часть возможностей, характерных для полноценных EDR-платформ. В частности, нет глубокой телеметрии уровня ядра через ETW или eBPF и расширенных механизмов защиты от бесфайловых атак и угроз в памяти. Тем не менее для построения базового уровня мониторинга безопасности Wazuh остается одним из наиболее функциональных решений на базе open source.
Управление доступом и аутентификация
Коротко остановлюсь на таком средстве управления доступом и аутентификации (IAM), как Keycloak.
Как работает SSO в Keycloak?
Один аккаунт — множество сервисов. Это и есть SSO. Keycloak написан на Java и поддерживает стандарты OAuth2, OIDC и SAML.
Keycloak:
аутентифицирует пользователя;
создает сессию;
выдает токен (JWT) с правами и передает его между сервисами.
Токен можно автоматически обновлять (refresh token), и пользователь не замечает сложностей.
Почему это удобно?
Безопасно — меньше точек атаки.
Просто в управлении — один центр доступа.
Экономно — не нужно дублировать код.
Гибко — можно подключить Telegram, LDAP и др.
А теперь на примере Kibana покажу, как настроить SSO. Для начала необходимо создать в Keycloak нового клиента с типом OpenID Connect.
В качестве Client ID можно указать, например, kibana.
После этого важно настроить параметры подключения клиента. В полях Root URL и Valid Redirect URIs нужно указать адрес kibana, например:
https://<elk.example.local>:443/* (значение зависит от записи на вашем DNS-сервере).
Кстати, такой вариант — не самый секьюрный. В поле Valid Redirect URLs лучше указать полное значение, например:
https://elk.example.local:5601/auth/openid/login
Параметр Valid Redirect URLs определяет, куда Keycloak сможет перенаправить пользователя после успешной аутентификации.
На стороне Kibana нужно указать параметры подключения к Keycloak:
oidc.idp.openid_configuration_url — адрес сервера авторизации;
oidc.client_id — идентификатор созданного клиента;
oidc.client_secret — секретный ключ клиента (в Keycloak его можно найти на вкладке Credentials в настройках клиента).
Пример
oidc.client_id: “kibana”
oidc.client_secret:“<eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ>”
oidc.idp.openid_configuration_url: “https://keycloak.example.local/realms/your-realm/.well-known/openid-configuration” oidc.get_user_info: true oidc.use_pkce: true
После этого остается настроить сопоставление ролей и прав доступа. Для этого в разделе Security необходимо связать группы и роли из Keycloak с правами пользователей в Kibana. Например, можно создать отдельную роль администратора и назначить ей соответствующие разрешения.
Связка IAM и SSO помогает защитить данные от утечек, несанкционированного доступа и решить проблему слабых паролей. Пользователю больше не нужно держать в голове десятки учетных данных и записывать их на бумажках, а единый механизм входа помогает внимательнее относиться к тому, где именно он вводит пароль.
Выводы
Вот, пожалуй, и все, что я хотел рассказать про open source-инструменты для защиты инфраструктуры. Если собрать рассмотренные решения вместе, получится вполне рабочий набор компонентов для небольшой инфраструктуры. Однако важно понимать, что сами по себе описанные в статье решения не создают полноценную защиту сразу после установки. Их нужно настраивать под конкретную инфраструктуру, обновлять и регулярно проверять работу правил и политик.
И еще один момент, о котором не стоит забывать при использовании open source: перед скачиванием продукта важно изучить историю развития проекта и проанализировать активность сообщества. Не стоит использовать непонятные форки и сборки неизвестного происхождения: даже популярные проекты могут стать целью атаки.
