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

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

Виберіть режим застосування до розгортання

Вирішіть, чи вимога — це видимість чи запобігання, бо вони мають різну поведінку під час відмови. Пасивний датчик, що виходить з ладу, залишає трафік іти й створює прогалину в моніторингу; пристрій у лінії, що виходить з ладу, може або пропускати трафік, або зупиняти його, і цей вибір має бути свідомим. Домовтеся про один дозволений потік, один потік, який треба відхилити, і поведінку, яку ви хочете, коли датчик відмовляє. Тримайте відновлення керування окремо від перевіреного шляху, щоб помилка в датчику не позбавила вас доступу.

Потім запишіть видимий трафік, точку обробки й поведінку застосування. Ці три факти, а не встановлений пакет, описують, що розгортання насправді робить.