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

Иностранный адрес — это вопрос, а не ответ

Поездки, мобильные операторы с выходом в другой стране, корпоративный веб-прокси и перераспределённый пул carrier-grade NAT — все они сдвигают видимый источник, не сдвигая атакующего. Запись входа отражает, откуда соединение вошло в сеть, а не кто держал устройство.

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

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

Три типа записей отвечают на три разных вопроса

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

RecordQuestion it answersWhat it cannot prove
Authentication decisionWhich identity was accepted or rejected, by which method, at what timeThat the person operating the device was the account owner
Session lifecycleWhich connection, gateway and assigned address were active, and for how longWhat the session did with that access
Resource eventWhich read, write or denied operation a service observedWhich human behind the session triggered it
Policy changeWhether an administrator altered the rule that governs the accessWhether the change was reviewed or intended

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

Бухгалтерские детали — это место, где сессии становятся проверяемыми. Учёт RADIUS, описанный в RFC 2866, несёт обновления начала, остановки и промежуточные, привязанные к идентификатору сессии, поэтому сессия с началом и без остановки — это пробел, который можно назвать, а не загадка.

Связывайте по сессии, а не по имени пользователя

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

Там, где перевод убирает исходный источник до того, как его увидит служба, используйте личность, которая выживает на этой границе, например субъект взаимного TLS или утверждение единого входа. Выдумывать взаимно однозначное сопоставление между адресом и человеком — та же ошибка с лишними шагами.

Оповещение без владельца — это панель

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

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

Проверьте путь сбора, прежде чем доверять тихой неделе

Докажите конвейер от начала до конца, прежде чем настраивать хотя бы одно правило. Команды ниже подтверждают, что прослушиватели аутентификации и учёта работают, что тестовые учётные данные отклоняются по правильной причине и что события сессий по-прежнему приходят:

ss -uanp | grep -E ':(1812|1813)\b'
radtest alice 'not-the-password' 127.0.0.1 0 testing123
journalctl -u openvpn-server@server --since '-30 min' | grep -c 'Peer Connection Initiated'
timedatectl | grep -E 'System clock|synchronized'

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

Состояние часов важно, потому что окна корреляции предполагают согласие. Шлюз, отклоняющийся на минуты, делает иначе чистое соединение сессии невозможным на вид, и проверяющие компенсируют, расширяя окно, пока соединение не перестанет различать. Проверьте смещение перед правкой правила.

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

Похожие статьи