Snort на границе VPN: где видны пакеты

Проследите один запрос с удалённого ноутбука, и он пересекает несколько границ, прежде чем что-либо сможет его проверить. Внешний туннель заканчивается в процессе VPN, внутренний пакет появляется на интерфейсе, а сеанс HTTPS внутри продолжается до приложения. Средство проверки видит только то, что видно в точке, где пакеты до него доходят. Установите его, не определив эту точку, и журналы опишут не тот уровень.

Один пакет пересекает несколько границ

До завершения VPN наблюдатель видит одно внешнее соединение, обычно к порту VPN, с адресами и размерами, но без внутренней структуры. После завершения внутренние адреса, порты и протоколы доступны в той точке обработки, которая их передаёт. Собственный TLS приложения остаётся зашифрованным, если отдельный проект его не завершает. Это три уровня видимости, и имя пакета не говорит, какой из них вы купили.

Нарисуйте путь с отмеченными границами, затем поместите датчик на линию, где можно ответить на вопрос, потому что место — часть ответа. Граница, которую вы не можете назвать, — это граница, которую вы не можете проверить.

Посмотрите, что читается в каждой точке

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

ip -br link
tcpdump -ni tun0 -c 10 'tcp port 443'

Список ссылок показывает существующие туннели и физические интерфейсы, а запись показывает именно то, что получил бы подключённый там датчик. Если он показывает внутренние адреса, но не строки запросов HTTP, вы находитесь после завершения VPN и всё ещё вне TLS приложения. Это обычное место для сетевого обнаружения и неправильное место для проверки содержимого. Повторите запись на внешнем интерфейсе, чтобы сравнить, что раскрывает другая граница.

Пассивное обнаружение не может блокировать само по себе

Документация Snort по проверке отделяет пассивное наблюдение от работы в линии. Пассивный режим может предупреждать о трафике, не останавливая его на этом пути.

snort -T -c /etc/snort/snort.lua

Тестовый режим проверяет конфигурацию, не запуская датчик, и это правильный первый шаг перед любым развёртыванием. Работа в линии требует совместимой схемы захвата пакетов и соответствующей конфигурации применения, а не просто дополнительного флага. Поэтому запись в журнале не является доказательством того, что запрос был предотвращён, и процесс, запущенный с похожей на работу в линии опцией, не доказывает, что реальный пересылаемый поток проходит через него. Подтвердите, где реализация на самом деле передаёт пакеты.

Выберите режим применения до развёртывания

Решите, требуется ли видимость или предотвращение, потому что у них разное поведение при отказе. Пассивный датчик, который выходит из строя, оставляет трафик идущим и создаёт пробел в мониторинге; устройство в линии, которое выходит из строя, может либо пропускать трафик, либо останавливать его, и этот выбор должен быть осознанным. Договоритесь об одном разрешённом потоке, одном потоке, который должен быть отклонён, и о поведении, которое вы хотите при отказе датчика. Держите восстановление управления отдельно от проверяемого пути, чтобы ошибка в датчике не лишила вас доступа.

Затем запишите видимый трафик, точку обработки и поведение применения. Эти три факта, а не установленный пакет, описывают, что развёртывание действительно делает.