Входящее оповещение на VPN-сервере: читаем точку наблюдения

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

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

Этап первый: что на самом деле увидел захват

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

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

Windows также фильтрует на нескольких уровнях стека, поэтому аккуратная модель, в которой средство захвата находится на втором уровне, а межсетевой экран на третьем, не выдерживает встречи с реальным продуктом. Обзор Windows Filtering Platform описывает фильтрацию поперёк уровней стека, поэтому порядок наблюдения нужно устанавливать, а не предполагать.

Этап второй: что устанавливает запись о блокировке

Запись о блокировке говорит, что граница политики отклонила этот пакет. Это сильное доказательство. Оно и узкое, потому что охватывает одно решение на одной границе. Ничего другого в стеке оно не описывает.

Сопоставляйте по кортежу и метке времени. Тот же источник, тот же получатель, тот же порт, в ту же секунду. Без такого совпадения похожее событие в другом журнале — просто другое событие, а их объединение даёт историю, которую никто не сможет защитить.

# what did the firewall actually drop, and when?
Get-NetFirewallProfile -PolicyStore ActiveStore | Select-Object Name, LogAllowed, LogBlocked
Get-Content "$env:systemroot\System32\LogFiles\Firewall\pfirewall.log" | Select-String 'DROP'

# correlate with a listening service on the same port
Get-NetTCPConnection -LocalPort 3389 -State Listen | Select-Object LocalAddress, OwningProcess

Закрытый порт и отброшенный пакет выглядят одинаково снаружи и совершенно по-разному в этих двух выводах. Именно эта разница и есть причина читать локальную запись.

Этап третий: что доказывает событие аутентификации

Событие аутентификации говорит, что компонент обработал запрос достаточно далеко, чтобы зафиксировать результат. Это единственный из трёх этапов, который говорит об идентичности, и он ничего не сообщает о том, сколько пакетов пришло до него.

Читайте фактический контекст события. Неудачный вход для несуществующей учётной записи — это шум от сканирования. Неудачный вход для реальной учётной записи с правдоподобным источником — другой приоритет. Успешный сеанс — совсем другая категория инцидента.

Следите и за названиями протоколов. RPC и RDP — разные службы с разными портами. Детектор, который следит за одной из них, не охватывает другую. Инструменты, обобщающие сетевую активность, не всегда указывают, какая из двух породила событие.

Один сопоставленный образец лучше панели мониторинга

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

Затем разделите две обязанности. Если администрирование должно идти только через VPN, обеспечьте это и на публичном пути, и на пути туннеля, сохранив одобренный маршрут восстановления. Наблюдение за отклонённой попыткой — не та же задача, что решение о том, что сервер должен принимать.

Географическое правило или заблокированный посторонний протокол не заменяют поиска наблюдавшейся записи и решения, которое она получила. И VPN тоже: маршрутизация исходящего трафика через туннель ничего не документирует о входящей авторизации.