ICAP/DLP-анализ сервиса

ICAP/DLP-анализ — блок настроек конфигурации балансировки, который передаёт трафик сервиса на проверку внешней DLP-системы через ICAP-сервер.

Блок — секция ICAP на вкладке Безопасность конфигурации балансировки: Главная → Кластеры балансировки → <кластер> → Конфигурации балансировки → <конфигурация> → Безопасность. Описание полей формы — в статье Добавление конфигурации балансировки.

Порядок настройки

1. Создайте ICAP-сервер и убедитесь, что он доступен с агентов.

2. Включите ICAP инспекция для сервера и выберите профиль в поле ICAP-сервер.

3. Задайте режим инспекции, фильтр проверяемого трафика и пороги передачи тела.

Пока профиль не создан, поле ICAP-сервер содержит пустой список и недоступно для выбора.

Ограничения размещения

• Блок доступен конфигурациям с L4-протоколом TCP. Для сочетания TCP и HTTP, HTTPS или gRPC доступны все поля блока.
• Для TCP без L7-протокола доступно только зеркалирование сырого потока: режим Синхронная проверка не предлагается, фильтр и Код ответа при блокировке не показываются.
• Для остальных протоколов флажок ICAP инспекция для сервера неактивен, под ним выводится подпись «ICAP доступен только для TCP без L7 либо TCP с HTTP/HTTPS/gRPC».
• Блок есть только у конфигураций балансировки в кластере балансировки. В GSLB-кластере его нет.
• На инспекцию попадает только трафик, проходящий через опубликованный адрес сервиса.

Что получает DLP-система

Проверка запроса и проверка ответа оформлены как отдельные операции ICAP: REQMOD и RESPMOD. Заголовки и тело объекта передаются внутри этих операций. Метод, URI, заголовки и тело объекта передаются без изменений. Для HTTP и для HTTPS, где TLS завершается на балансировщике, тело передаётся в открытом виде; в конфигурациях без L7-протокола TLS не завершается, поэтому DLP-система получает байты сессии без изменений.

К заголовкам добавляются сведения о проверке:

X-5a-Capture-Mode позволяет DLP-системе отличить полный объект от усечённого: режим preview означает, что передано только начало тела, до 1 МБ, а режим headers — что передан только заголовок без тела. Заголовок X-5a-Original-Content-Length передаётся, когда размер объекта известен: при передаче ответа по частям, без объявленной длины, он отсутствует.

В режиме Зеркалирование и при проверке ответов действует меньший из двух пределов: заданного в Пороге полной передачи тела запроса, КБ или Пороге полной передачи тела ответа, КБ и локального предела агента на одну копию. Тело длиннее локального предела на проверку не попадает — проверка отбрасывается, а факт видно в метрике dropped_payload_limit. Локальный предел задаётся параметром slb.traffic_copy_buffer.max_single_copy_mb, см. Файл конфигурации агента.

Запросы без тела и запросы с бесконечным телом — WebSocket, Server-Sent Events, long-poll — проверяются по заголовкам, без тела и без ожидания вердикта. Сессия при этом не разрывается.

Ответ, превышающий Порог полной передачи тела ответа, КБ, передаётся на проверку частично: DLP-система получает заголовки и начало ответа, до 1 МБ и не больше заданного порога. Первую передаваемую часть DLP-система может уменьшить, объявив превью в ответе OPTIONS, а на 100 Continue агент передаёт остаток сохранённой части; часть ответа за её пределами на проверку не передаётся.

Ответ без объявленной длины, передаваемый по частям, отправляется на проверку целиком, если он не больше 1 МБ. Заданный порог для такого ответа не действует.

Что считается блокировкой

DLP-система возвращает решение ответами ICAP. Запрос считается заблокированным, если в ответе есть инкапсулированный HTTP-ответ, указан идентификатор заражения X-Infection-Found или X-Virus-Id, значение X-Violations-Found отлично от нуля либо заголовок X-Icap-Verdict, X-Verdict или X-Dlp-Verdict содержит block, blocked, deny или denied.

Причина блокировки передаётся в заголовке X-Dlp-Reason и попадает в журнал агента.

Ответ с кодом 4xx или 5xx не блокирует запрос: он означает, что проверка не состоялась.

Поведение при проверке

• В режиме Зеркалирование копия запроса уходит на проверку асинхронно: клиент не ждёт вердикта, а решение DLP-системы не изменяет трафик и попадает в журнал агента.
• В режиме Синхронная проверка решение ожидается до отправки запроса клиентскому серверу. Разрешающее решение пропускает запрос, блокирующее — отвечает клиенту кодом из поля Код ответа при блокировке и не передаёт тело запроса на сервер.
• Проверка ответов выполняется только после того, как ответ клиентского сервера получен. Влиять на выдачу ответа клиенту она не может.
• Несостоявшаяся проверка — недоступная DLP-система, истёкший таймаут ожидания вердикта, переполненная очередь проверок — не мешает обслуживанию: запрос проходит без вердикта.
• Повторные попытки обращения к DLP-системе не выполняются.
• Неверные значения настроек отклоняются при сохранении: конфигурация с ними не сохранится, а балансировка продолжит работать с прежними настройками.

Примеры настройки

Синхронная защита загрузок

Если запрещённый файл не должен попасть на клиентский сервер, включите режим Синхронная проверка:

• Режим инспекции — Синхронная проверка;
• ICAP-сервер — профиль с заданным REQMOD URL;
• HTTP-методы — POST, PUT;
• Content-Type — multipart/form-data;
• Только пути — /upload, /api/documents;
• Код ответа при блокировке — 403.

При блокировке клиент получит 403, а тело запроса на клиентский сервер не уйдёт.

Проверка без задержки

Если задержка недопустима и достаточно анализа постфактум, оставьте режим Зеркалирование: копия трафика уходит на проверку асинхронно, пользователь не ждёт вердикта DLP-системы.

Снижение нагрузки на DLP-систему

Чтобы не отправлять лишний трафик, исключите служебные пути и ограничьте методы:

• HTTP-методы — POST, PUT, PATCH;
• Только пути — /upload;
• Исключить пути — /health, /metrics.

Если пользователи загружают файлы крупнее заданного порога, уменьшите Порог полной передачи тела запроса, КБ: в DLP-систему уйдут заголовки и начало тела, а не файл целиком.

Зеркалирование сырого TCP

Для конфигурации без L7-протокола доступен только режим Зеркалирование. Одна сессия TCP передаётся в DLP-систему одной операцией REQMOD: запрос имеет тип содержимого application/octet-stream и путь вида /session-\<идентификатор\>.bin, а данные сессии передаются по мере их поступления.

Объект сопровождается заголовками сессии: X-5A-Stream-Session, X-5A-Stream-Event, X-5A-Stream-Sequence, X-5A-Stream-Offset, X-5A-Stream-Direction, X-5A-Stream-Source, X-5A-Stream-Destination. На уровне ICAP добавляются X-Client-Ip и X-Server-Ip. Операция закрывается, когда сессия завершилась или перестала передавать данные.

Объём зеркалируемых данных ограничен полем Максимальный размер TCP-потока, КБ: DLP-система получает данные направления от клиента к клиентскому серверу до достижения заданного порога. Зеркалирование прекращается на пороге, а передача по сессие продолжается: соединение не разрывается, данные передаются в обоих направлениях. Данные от клиентского сервера к клиенту на проверку не передаются.

Решение по такой сессии не влияет на трафик: клиент и клиентский сервер обмениваются данными независимо от вердикта. Кадры сессии отбрасываются, если они крупнее 64 КБ, если исчерпан лимит памяти на тела проверок или если кадр повреждён; факт отбрасывания виден в метриках агента.

Проверка

В режиме Зеркалирование агент читает ответ DLP-системы и записывает вердикт в журнал, но к трафику его не применяет. Проверить доставку и решение можно в журнале агента и по метрикам. Метрики агента отдаёт его порт управления по пути /metrics в формате Prometheus, по умолчанию 50050: http://<адрес агента>:50050/metrics.

Счётчик a5_icap_transactions_total с меткой result показывает результат каждой операции ICAP:

Метрика a5_icap_inspection_modes_total с метками path и mode показывает, какая часть объекта уходила на проверку: mirror или inline в path, full, preview или headers в mode. Значение preview при большой доле трафика означает, что пороги передачи тела заданы слишком низкими.

Счётчики a5_icap_async_reqmod_total и a5_icap_async_respmod_total с меткой outcome показывают судьбу асинхронных проверок. Значения queued и completed потерь не означают: первое — проверка принята в очередь, второе — вердикт получен. Остальные значения — потери:

Для зеркалирования сырого TCP добавьте метрики a5_icap_stream_mirror_frames_total с меткой event, a5_icap_stream_mirror_dropped_frames_total с меткой reason, a5_icap_stream_mirror_active_sessions, a5_icap_stream_mirror_queued_bytes и a5_icap_stream_mirror_icap_requests_total с меткой result.

Гистограмма a5_icap_transaction_duration_seconds показывает время операции ICAP, счётчик a5_icap_inspections_in_flight с меткой service — число проверок, ожидающих вердикта прямо сейчас. По нему видно, что синхронная проверка упирается в таймаут: значение держится на уровне ICAP таймаут, мс.

Счётчик a5_icap_options_requests_total с меткой result показывает результаты запросов OPTIONS: success, error, rejected. Счётчик a5_icap_preview_outcomes_total с меткой outcome показывает, чем закончилась передача усечённого объекта: continued — DLP-система запросила продолжение, early_204 или early_final — вернула решение сразу, не запрашивая остаток, unsupported, error.