Укрепление VPN в Windows: сначала исправьте аутентификацию, потом туннель
MS-CHAPv2 — не та проверка пароля, которой стоит доверять, а длинный предварительно разделённый ключ — не аутентификация пользователя. Упорядочьте исправления по тому, что злоумышленник может воспроизвести.
Ваш VPN-сервер в Windows просит имя пользователя и пароль, и этот единственный диалог скрывает три несвязанные обязанности. Одна доказывает, кто этот человек, другая не даёт тому, кто наблюдает за линией, повторно использовать это доказательство, а третья решает, к каким адресам он может обращаться дальше. Большинство небольших развёртываний сначала укрепляют туннель, а первые две обязанности оставляют на значениях по умолчанию, и это неверный порядок.
Работайте в том порядке, в котором работает злоумышленник. Сначала то, что можно перехватить с линии. Затем то, что можно позже воспроизвести с этой записью. Наконец, то, до чего аутентифицированный злоумышленник доберётся, уже находясь внутри.
Три обязанности, один диалог
Идентичность — это та часть, о которой думают люди, и она составляет лишь треть проблемы. Доказательство идентичности должно выдержать наблюдателя, который записывает обмен и позже пробует снова. А авторизация — отдельное решение, которое сервер принимает после того, как идентичность установлена, и Windows хранит её в другой службе, нежели та, что проверяет учётные данные.
Когда все три живут в одном мысленном ведре, обычный результат — сервер, который строго аутентифицирует, а затем позволяет пользователю добраться до всего. Исправить это позже труднее, чем определить политику сейчас, потому что к тому времени профиль межсетевого экрана, пул адресов и маршруты уже кодируют прежнее допущение.
Разделите три вещи в своих заметках, прежде чем трогать любую настройку, а затем исправляйте их от самого слабого звена вверх.
Почему MS-CHAPv2 не проходит проверку на повтор
Если сервер всё ещё принимает PPTP с MS-CHAPv2, туннель не защищает пароль ни в каком осмысленном смысле. Вызов и ответ можно перехватить и атаковать офлайн, и в 2012 году публичный сервис взлома продемонстрировал восстановление из такого рукопожатия примерно за сутки для типичного пароля. Более длинный и сложный пароль повышает стоимость; он не убирает материал, который злоумышленник получает из сети.
Нужное свойство — учётные данные, которые нельзя воспроизвести. EAP-TLS с клиентскими сертификатами даёт каждому устройству собственную идентичность и позволяет отозвать ровно одно устройство.
Развёртывание сертификатов — настоящая работа: собственный CA, путь отзыва, который проверяют клиенты, и план обновления, переживающий смену персонала. Относитесь к этой работе как к проекту, а не как к препятствию между вами и работающим туннелем. Планируйте на неё бюджет так, как планировали бы замену межсетевого экрана. Общий пароль дешевле только до первого отзыва.
Предварительно разделённый ключ аутентифицирует пару, а не человека
L2TP/IPsec с предварительно разделённым ключом доказывает, что два шлюза знают один и тот же секрет. Он ничего не говорит о том, какой человек подключается, и на этом уровне не может отличить одного сотрудника от другого. Используйте длинное случайное значение, намного больше десяти символов, которые советуют некоторые руководства, потому что любой, кто перехватит рукопожатие, может атаковать ключ офлайн.
Каждый клиент в этом профиле разделяет секрет, поэтому удаление одного человека означает его повторное распределение среди всех остальных. Держите отдельный шаг аутентификации пользователя поверх секрета уровня машины и переходите на сертификаты по мере роста числа клиентов. Предварительно разделённый ключ вместе с MS-CHAPv2 — это два слабых слоя, и второй сводит на нет первый.
Авторизация принадлежит Network Policy Server
NPS в Windows решает, кому можно подключаться, и делает это после того, как аутентификация уже прошла успешно. Это разделение — самая полезная мера укрепления в продукте, и многие развёртывания оставляют её нетронутой.
Используйте условия политики, отражающие реальные ограничения: членство в группе, временное окно, когда поддержка укомплектована, и состояние устройства из проверки работоспособности. Добавьте второй фактор там, где данные оправдывают трение, и помните, что политика оценивается при каждой попытке подключения, что делает её живым контролем, а не документом.
Учёт RADIUS также даёт одну запись о том, кто и когда подключился. Этот журнал — разница между разбором инцидента и догадкой, и он существует независимо от того, читает ли его кто-нибудь.
Ограничьте, до чего может добраться успешный вход
VPN-адаптер должен попадать в профиль межсетевого экрана, который разрешает службы, нужные его роли, а не всю подсеть. Вопрос маршрутизации отделён от фильтрации. Полный туннель защищает устройство клиента и прогоняет каждый байт через вашу восходящую линию, тогда как раздельный туннель оставляет локальный трафик локальным и подвергает устройство любой сети, в которой оно окажется.
Ни один из вариантов не является настройкой безопасности по умолчанию. Оба нужно записать рядом с профилем межсетевого экрана, который они предполагают.
Проверьте пути отказа
Проверьте, что должно сломаться: неверный пароль, истёкший сертификат, отозванное устройство, пользователь вне группы. Каждый случай должен отказать в своей точке, и журнал должен сказать, в какой именно. Прогоните набор сначала на тестовой учётной записи, затем повторите для реального пользователя. Отказ, который без причины попадает в журнал событий, стоит исправить задолго до того, как вам понадобится эта запись.
Затем подтвердите, какие порты опубликованы и почему. PPTP требует TCP 1723 и GRE как IP-протокол, а не порт, IKEv2 требует UDP 500 и 4500, а L2TP требует UDP 1701 плюс IPsec. Открытие интерфейса управления, чтобы клиент подключился, — не ремонт, а второй инцидент, ждущий обнаружения.
Наконец, решите, что сервер записывает и как долго. Конечная точка без истории аутентификации не может ответить на первый вопрос после инцидента, а именно была ли попытка когда-либо разрешена.