Уровни данных и места хранения

В архитектуре NICE.SSA можно условно выделить четыре уровня данных:

• Сырые пакеты (L2–L7):
  попадают на интерфейс сенсора (VPC mirroring/TAP/SPAN). Часть пакетов может дополнительно записываться Arkime в PCAP-хранилище для последующего анализа.
• События Suricata (EVE JSON):
  сохраняются в файловой системе (обычно /var/log/suricata/eve.json или ротация в несколько файлов). Это основной источник событий для Vector.
• Индексы OpenSearch:
  структурированные документы в индексах «suricata-events-<дата>» и дополнительных индексах (например, для статистики, метаданных Arkime и служебных объектов).
• Локальные БД и служебные файлы:
  конфигурационная БД EveBox (например, /var/lib/evebox/config.sqlite), внутренние БД Arkime, конфиги Scirius, файлы настроек Nginx и др.

Такой дизайн позволяет чётко разделить: где хранится «дорогой» PCAP, где живут индексируемые события, а где лежат только служебные или конфигурационные данные.

Порты и протоколы взаимодействия

Компоненты стека общаются друг с другом преимущественно по HTTP/HTTPS внутри сенсора, а наружу выходит только Nginx.

# Типичные порты внутри NICE.SSA (можно адаптировать под политику компании)
```

# Хранилище и аналитика

OpenSearch REST API      : 9200/tcp (HTTP)
OpenSearch node/metrics  : 9600/tcp, 9650/tcp (HTTP)

# Визуализация и UI

OpenSearch Dashboards    : 5601/tcp (HTTP, только внутри)
EveBox                   : 5636/tcp (HTTP, только внутри; порт может отличаться)
Arkime (viewer)          : 8005/tcp или 8443/tcp (HTTP/HTTPS, только внутри)
Scirius                  : 8008/tcp (HTTP, только внутри)

# Внешний шлюз

Nginx (NICE.SSA портал)  : 80/tcp, 443/tcp (HTTP/HTTPS, наружу)

Suricata и Vector, как правило, не поднимают отдельные внешние HTTP-порты: Suricata пишет EVE в файлы, а Vector читает их локально и уже сам общается с OpenSearch по HTTP. Все пользовательские запросы снаружи приходят только на Nginx, который проксирует их к нужным внутренним сервисам.

Назначение и основные возможности

Suricata в составе NICE.SSA выполняет несколько ключевых ролей в контуре сетевой безопасности:

• IDS (Intrusion Detection System):
  анализирует трафик по сигнатурам и правилам, выявляет попытки эксплуатации уязвимостей, сканирования, вредоносные протоколы, C2-каналы и другие признаки атак. Результат — события и алерты, попадающие в OpenSearch.
• IPS (Intrusion Prevention System):
  может работать в режиме inline (NFQUEUE/AF_PACKET) и блокировать трафик, соответствующий правилам. В контексте NICE.SSA в Яндекс Cloud акцент делается на пассивный мониторинг, но архитектура не исключает использование IPS-режимов в on-premise.
• NSM (Network Security Monitoring):
  собирает метаданные о потоках, протоколах, HTTP/SSL/DNS/SMTP/SSH и других уровнях L7, формирует полную картину сетевой активности, даже если нет явных сигнатур атак.

В совокупности это позволяет использовать NICE.SSA и как систему обнаружения атак, и как инструмент высокоуровневого мониторинга сетевой безопасности и телеметрии.

Конфигурация и логи Suricata

Основной конфигурационный файл и логи Suricata в NICE.SSA размещаются в стандартных для NiceOS путях:

• /etc/suricata/suricata.yaml — главный конфиг Suricata;
• /var/log/suricata/ — каталог логов (включая eve.json);
• /etc/suricata/ — дополнительные конфиги (threshold, classification, reference);
• /usr/share/suricata/ — эталонные файлы и правила в поставке;
• /var/lib/suricata/update — рабочий каталог suricata-update.

Фрагмент базового конфига, отвечающего за включение EVE-логирования (ключевой источник для Vector):

# /etc/suricata/suricata.yaml (фрагмент)
```

outputs:

* eve-log:
  enabled: yes
  filetype: regular
  filename: /var/log/suricata/eve.json
  community-id: yes
  community-id-seed: 0
  types:
  - alert
  - dns
  - http
  - tls
  - ssh
  - smtp
  - flow
  - stats

Именно на этот файл eve.json настроен Vector в конфигурации /etc/vector/suricata.vector.yaml, обеспечивая непрерывный экспорт событий в OpenSearch.

Роль Vector в стеке NICE.SSA

В архитектуре NICE.SSA Vector выполняет сразу несколько функций на пути от Suricata к OpenSearch:

• Транспорт событий: читает файлы логов Suricata (EVE JSON) и отправляет их в OpenSearch по HTTP, используя оптимизированную пакетную отправку.
• Нормализация и обогащение: приводит поля к нужным типам (IP, дата, числа), добавляет служебные атрибуты (имя сенсора, источник, теги среды — prod/test и т. д.).
• Буферизация и ретраи: при недоступности OpenSearch временно хранит события в памяти или на диске и повторяет попытки отправки, чтобы не терять данные при кратковременных сбоях.
• Разделение потоков: при необходимости может раскидывать разные типы событий (alerts, flows, http, tls и др.) по отдельным индексам или контурам обработки.

Vector делает работу Suricata и OpenSearch независимыми по времени: Suricata продолжает писать EVE, даже если OpenSearch перезапускается или испытывает нагрузку, а Vector берёт на себя выравнивание потока.

Конфигурация Vector: /etc/vector/suricata.vector.yaml

В NICE.SSA конфигурация Vector, отвечающая за работу с Suricata, хранится в файле: /etc/vector/suricata.vector.yaml. В ней описываются:

• sources — откуда читать события (файлы, journald и др.);
• transforms — как преобразовывать и нормализовать записи;
• sinks — куда отправлять данные (OpenSearch, файлы, stdout, др.).

Пример упрощённого конфига Vector, иллюстрирующий схему источников, трансформов и sink:

# /etc/vector/suricata.vector.yaml (пример)
```

sources:
suricata_eve:
type: file
include:
- /var/log/suricata/eve.json
read_from: end        # начинать с конца файла при старте
ignore_older: 7d      # игнорировать слишком старые файлы
multiline:
mode: none

transforms:
normalize_eve:
type: remap
inputs: [suricata_eve]
source: |
.@timestamp = to_timestamp!(.timestamp)
.sensor = "nice-ssa"
.stream = "suricata-eve"
# Приведение типов
.src_port = to_int!(.src_port)
.dest_port = to_int!(.dest_port)

sinks:
opensearch_eve:
type: elasticsearch
inputs: [normalize_eve]
endpoints: ["[http://127.0.0.1:9200](http://127.0.0.1:9200)"]
index: "suricata-events-%Y.%m.%d"
mode: "bulk"
request:
retry_attempts: 10
retry_backoff_secs: 5
buffering:
type: "disk"
max_size: 1024mb

В реальной поставке NICE.SSA в этот файл дополнительно добавляются настройки логирования самого Vector, ограничение объёма буфера, тюнинг размеров batch и прочие параметры, влияющие на производительность.

Хранилище и аналитический движок

В контуре NICE.SSA OpenSearch выполняет сразу несколько ключевых функций:

• Документное хранилище событий:
  каждое событие EVE (алерт, поток, HTTP-запрос, TLS-сессия, DNS-запрос и т. д.) превращается в документ, который попадает в индекс с правильными типами полей.
• Поисковый движок:
  позволяет выполнять фильтрацию и поиск по любым полям (IP, порты, имена правил, категории, гео, юзер-агенты, домены и др.), в том числе через REST API.
• Агрегации и аналитика:
  поддерживает построение метрик и графиков (top-N, гистограммы по времени, распределения по сегментам, пользователям, типам атак), которые используются в OpenSearch Dashboards.
• Основа для внешней интеграции:
  любые внешние системы (SIEM, отчётные сервисы, внутренние аналитические утилиты) могут забирать данные из OpenSearch по API, не вмешиваясь в работу Suricata и Vector.

Таким образом, OpenSearch — это «центр тяжести» NICE.SSA: все компоненты либо пишут в него данные, либо считывают из него информацию для визуализации и расследований.

Шаблоны индексов и ILM-политики
из /usr/share/suricata/opensearch/

Пакет suricata-opensearch в NICE.SSA содержит набор готовых артефактов для OpenSearch в каталоге /usr/share/suricata/opensearch/, в том числе:

• template-suricata-events.json — шаблон индексов событий Suricata;
• ilm-suricata-events.json — ILM-политика жизненного цикла данных;
• pipeline-suricata-eve.json — ingest-пайплайн для EVE-событий (при использовании ingest node).

При первоначальной настройке NICE.SSA специальный скрипт (например, /usr/sbin/suricata-opensearch-setup) применяет эти шаблоны к кластеру OpenSearch:

# Пример применения шаблона и ILM-политики (упрощённо)
```

curl -X PUT "[http://127.0.0.1:9200/_ilm/policy/suricata-events](http://127.0.0.1:9200/_ilm/policy/suricata-events)" 
-H 'Content-Type: application/json' 
--data-binary @/usr/share/suricata/opensearch/ilm-suricata-events.json

curl -X PUT "[http://127.0.0.1:9200/_index_template/suricata-events-template](http://127.0.0.1:9200/_index_template/suricata-events-template)" 
-H 'Content-Type: application/json' 
--data-binary @/usr/share/suricata/opensearch/template-suricata-events.json

Упрощённый пример ILM-политики (логика; реальные значения могут быть иными):

{
"policy": {
"phases": {
"hot": {
"min_age": "0d",
"actions": {
"rollover": { "max_age": "7d", "max_size": "50gb" }
}
},
"warm": {
"min_age": "30d",
"actions": {
"shrink": { "number_of_shards": 1 }
}
},
"delete": {
"min_age": "90d",
"actions": {
"delete": {}
}
}
}
}
}

Такая схема позволяет автоматически управлять временем хранения и размером индексов: свежие данные живут в «горячих» индексах с максимальной производительностью, старые — переводятся в более компактный формат или удаляются по истечении согласованного срока.

Функции EveBox: расследование, корреляция, алерт-менеджмент

EveBox собирает в одном интерфейсе всё, что нужно для повседневной работы SOC с алертами Suricata:

• Список алертов и событий:
  представление в виде ленты событий с основными полями — время, источник/назначение, сигнатура, категория, критичность, направление трафика. Позволяет быстро ответить на вопрос «что происходит прямо сейчас».
• Детальные карточки инцидентов:
  при открытии алерта показывается полный JSON-документ события, включая вложенные поля Suricata (alert, http, dns, tls, flow и др.), а также связанные события вокруг выбранного временного диапазона.
• Корреляция событий:
  EveBox группирует однотипные срабатывания (например, множество алертов по одному и тому же IP или сигнатуре) и позволяет рассматривать их как одну проблему, а не сотни отдельных записей.
• Управление жизненным циклом алерта:
  алерты можно подтверждать (ack), помечать как ложные (false positive), добавлять комментарии и теги, что формирует историю работы по каждому инциденту.

За счёт этих возможностей EveBox превращает поток суровых событий Suricata в управляемый список задач для SOC/IR-команд — с возможностью отследить, кто и когда принял решение по тому или иному инциденту.

Связь с OpenSearch: /etc/suricata/opensearch.conf

EveBox в NICE.SSA не хранит копию событий у себя — он напрямую работает с индексами OpenSearch, в которые Vector пишет EVE-события Suricata. Параметры подключения к OpenSearch вынесены в файл /etc/suricata/opensearch.conf, который используется как единый источник настроек для нескольких компонентов (EveBox, вспомогательные скрипты и др.).

Пример содержания /etc/suricata/opensearch.conf (логика, могут быть дополнительные поля):

# /etc/suricata/opensearch.conf (пример)
```

OPENSEARCH_URL="[http://127.0.0.1:9200](http://127.0.0.1:9200)"
OPENSEARCH_USERNAME="suricata"
OPENSEARCH_PASSWORD="changeme"
OPENSEARCH_INDEX_PATTERN="suricata-events-*"

На базе этих переменных при запуске EveBox можно задавать параметры подключения:

# Пример запуска EveBox с параметрами из opensearch.conf
. /etc/suricata/opensearch.conf

INDEX_PREFIX="${OPENSEARCH_INDEX_PATTERN%%-*}"

EVEBOX_ELASTICSEARCH_URL="$OPENSEARCH_URL" 
EVEBOX_ELASTICSEARCH_USERNAME="$OPENSEARCH_USERNAME" 
EVEBOX_ELASTICSEARCH_PASSWORD="$OPENSEARCH_PASSWORD" 
evebox server 
-k 
--index "$INDEX_PREFIX" 
--host 0.0.0.0

В результате EveBox видит те же индексы, что и OpenSearch Dashboards: любые изменения в потоке событий или структуре индексов сразу отражаются и в визуализации, и в интерфейсе расследования.

Назначение Arkime: анализ и просмотр PCAP

В составе NICE.SSA Arkime выполняет три ключевые задачи:

• Запись трафика в PCAP:
  отдельный capture-процесс Arkime принимает копию того же зеркалируемого трафика, что и Suricata, и сохраняет его в виде PCAP-файлов на диск. Запись может быть непрерывной или с ограничениями по объёму/времени.
• Индексация метаданных сессий:
  для каждого потока (flow/session) Arkime извлекает метаданные (IP, порты, протокол, время начала/окончания, байты, пакеты, теги) и сохраняет их в поисковом backend (OpenSearch). Это позволяет быстро находить нужные сессии без сканирования всего PCAP.
• Интерактивный просмотр и экспорт:
  через веб-интерфейс Arkime можно просматривать списки сессий, фильтровать их по любым полям, раскрывать содержимое пакетов, следить за потоками и экспортировать интересующие фрагменты в отдельные PCAP-файлы.

Arkime превращает трафик в «сетевой видеорегистратор»: если Suricata подняла алерт, с Arkime всегда можно вернуться назад и посмотреть, как именно выглядел сетевой диалог, который к нему привёл.

Включение записи трафика и связь Arkime с OpenSearch

В NICE.SSA Arkime настраивается так, чтобы:

• capture-процесс слушал тот же интерфейс, что и Suricata (интерфейс зеркалируемого трафика);
• PCAP-файлы укладывались в выделенный каталог/том (обычно /var/lib/arkime/raw);
• метаданные сессий сохранялись в OpenSearch в отдельные индексы (например, arkime-sessions-*);
• веб-интерфейс Arkime был доступен через Nginx по защищённому URI (например, /arkime).

Типичные шаги включения записи трафика:

1. Определить интерфейс, на который приходит зеркалируемый трафик (например, eth1).
```

2. Указать этот интерфейс в конфигурации Arkime capture.
3. Создать каталог для PCAP и настроить права.
4. Настроить подключение к OpenSearch для индексации сессий.
5. Запустить capture-сервис Arkime и убедиться, что сессии появляются в Web UI.

Пример фрагмента конфигурации Arkime (логика; имена файлов и параметры могут отличаться):

# /etc/arkime/config.ini (фрагмент примера)
```

[default]
interface=eth1
pcapDir=/var/lib/arkime/raw
esHost=127.0.0.1:9200
esIndex=arkime-sessions
rotateIndex=daily

# Опционально: ограничение скорости записи/чтения, фильтры BPF и др.

После настройки Arkime начинает:

• принимать пакеты с интерфейса eth1,
• писать PCAP-файлы в /var/lib/arkime/raw,
• создавать записи о сессиях в индексах OpenSearch (arkime-sessions-YYYY.MM.DD или аналогичных).

Назначение Scirius: управление правилами и сигнатурами

В NICE.SSA Scirius решает сразу несколько практических задач, связанных с жизненным циклом правил Suricata:

• Управление источниками правил:
  подключение и отключение внешних feeds (ET, коммерческие подписки, собственные репозитории), настройка расписания обновления, контроль версий и статусов.
• Поиск и анализ сигнатур:
  удобный поиск по sid, имени сигнатуры, категории, полям протокола; просмотр исходного текста правила и встроенных комментариев; оценка того, что конкретно правило детектирует и как может влиять на шумность.
• Включение/выключение и тюнинг правил:
  массовое включение/отключение целых категорий, fine-tune отдельных правил, перевод действия из alert в drop (актуально для IPS-режимов), управление приоритетами.
• Локальные правила:
  создание и сопровождение собственных сигнатур для внутренних сервисов, специфических протоколов и локальных политик, с хранением в отдельных rule-файлах.

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

Общий поток: синхронизация, компиляция, деплой

В терминах NICE.SSA работа Scirius с правилами может быть описана как цепочка: «получить → отфильтровать → скомпилировать → развернуть».

1. Получить правила:
   Scirius обновляет подключённые источники (локальные/внешние) через интеграцию с suricata-update или собственные механизмы загрузки.
2. Отфильтровать и настроить:
   администратор в UI решает, какие категории включить/выключить, какие правила переопределить, какие локальные сигнатуры добавить.
3. Скомпилировать результирующий набор:
   на основе выбранных источников и настроек формируется единый ruleset, который будет применён к Suricata.
4. Развернуть и активировать:
   скомпилированный набор правил записывается в каталог /etc/suricata/rules/ (или его подкаталоги), после чего инициируется перезапуск/перечитывание правил Suricata через systemd.

Таким образом, Scirius становится «оркестратором» правил: он сам не анализирует трафик, но управляет тем, как именно это делает Suricata, и какие сигнатуры будут действовать на сенсоре в каждый момент времени.

Единая точка входа и маршрутизация UI

В типовой конфигурации NICE.SSA все интерфейсы доступны с одного доменного имени, например: sensor.example.ru. NGINX маршрутизирует запросы по URI:

• https://sensor.example.ru/ → OpenSearch Dashboards (основной портал и дашборды);
• https://sensor.example.ru/evebox → EveBox (инциденты и алерты);
• https://sensor.example.ru/scirius → Scirius (управление правилами Suricata);
• https://sensor.example.ru/arkime → Arkime (PCAP и сессии).

Логика проста: снаружи существует один «вход в сенсор», изнутри — несколько приложений, каждое отвечает за свою задачу. Это:

• упрощает коммуникацию с пользователями (один URL вместо набора портов и адресов);
• упрощает управление сертификатами (один домен/набор SAN);
• позволяет централизованно внедрять политики доступа и логирования.

Упрощённый пример server-блока с маршрутизацией:

server {
listen 443 ssl http2;
server_name sensor.example.ru;

ssl_certificate     /etc/nginx/tls/sensor.crt;
ssl_certificate_key /etc/nginx/tls/sensor.key;

# По умолчанию → OpenSearch Dashboards
location / {
    proxy_pass http://opensearch-dashboards:5601/;
    include /etc/nginx/snippets/proxy-common.conf;
}

location /evebox/ {
    proxy_pass http://evebox:5636/;
    include /etc/nginx/snippets/proxy-common.conf;
}

location /scirius/ {
    proxy_pass http://scirius:8008/;
    include /etc/nginx/snippets/proxy-common.conf;
}

location /arkime/ {
    proxy_pass http://arkime-ui:8005/;
    include /etc/nginx/snippets/proxy-common.conf;
}
```

}

HTTPS, Basic Auth и интеграция с Yandex IAM

NGINX в NICE.SSA отвечает за безопасность фронтового слоя:

• HTTPS (TLS-терминация):
  на уровне NGINX настраиваются сертификаты (самоподписанные, корпоративные, доверенные CA), версии протокола TLS, наборы шифров, HSTS и другие параметры, отвечающие требованиям политики безопасности.
• Basic Auth:
  самый простой и часто достаточный вариант аутентификации — базовая авторизация с использованием htpasswd. Она может применяться как ко всему серверу, так и к отдельным локациям (например, закрыть Arkime отдельным логином).
• Интеграция с Yandex IAM / внешним SSO:
  возможно построение схемы, где NGINX работает совместно с внешним OIDC/OAuth2-прокси (например, отдельный сервис- «auth-gateway»), который проверяет токены Yandex Cloud или корпоративного IdP. После успешной проверки в NGINX приходят только запросы с валидным заголовком (например, X-User), а доступ для остальных блокируется.

Пример включения Basic Auth (схема, реальные пути могут отличаться):

server {
listen 443 ssl http2;
server_name sensor.example.ru;

ssl_certificate     /etc/nginx/tls/sensor.crt;
ssl_certificate_key /etc/nginx/tls/sensor.key;

# Общая базовая аутентификация для всех UI
auth_basic           "NICE.SSA restricted";
auth_basic_user_file /etc/nginx/htpasswd-nice-ssa;

location / {
    proxy_pass http://opensearch-dashboards:5601/;
    include /etc/nginx/snippets/proxy-common.conf;
}

location /evebox/ {
    proxy_pass http://evebox:5636/;
    include /etc/nginx/snippets/proxy-common.conf;
}

# При необходимости можно усилить правила по отдельным разделам
location /arkime/ {
    # Дополнительное ограничение по IP
    allow 10.0.0.0/24;
    deny  all;

    proxy_pass http://arkime-ui:8005/;
    include /etc/nginx/snippets/proxy-common.conf;
}
```

}

Для интеграции с Yandex IAM или другим внешним SSO обычно используется связка:

• отдельный OAuth2/OIDC-прокси (docker-сервис в том же стеке NICE.SSA);
• NGINX, отправляющий неаутентифицированные запросы на этот прокси (через auth_request);
• передача в backend-интерфейсы информации о пользователе и его ролях через заголовки.

В результате правила доступа к сенсору заводятся в одном месте — в IAM/IdP организации, а NGINX выступает как технический enforcement point, который пропускает внутрь только аутентифицированных и авторизованных пользователей.