Короткий ответ

Утек пароль (или сертификат/PSK) VPN — оборвите живые туннели учётки ivan.petrov, заблокируйте её на RADIUS/IdP, смените пользовательский секрет. Если слили общий pre-shared key сайта — это уже ротация PSK на шлюзе с простоем и сменой у всех клиентов, не «пароль Ивана». Логи IKE/RADIUS сохраните. Firewall/VPN-концентратор не выключайте.

Дальше смотрите, что успели сделать из туннеля: вход, lateral. Ноутбук украден — потеря устройства.

Симптомы и как отличить

  • Два активных туннеля ivan.petrov: офис и 10.0.10.55.
  • Have I Been Pwned / корпоративный мониторинг: пароль из стороннего слива совпал с VPN-логином (reuse).
  • RADIUS: Access-Accept ночью, Иван спит.
  • Сразу после VPN — SMB/RDP внутрь.
КартинаНе утечка пароля VPNКуда
Реконнект одного клиентастабильность каналане Disable
Site-to-site моргаетPSK/фаза 1 между офисамисеть, если нет чужого трафика
Always-On VPN с корпоративного ПКштатносверка device cert
Утекла учётка почты, VPN на другом паролевсё равно проверьте reuseящик

Возможные причины

  1. Reuse пароля VPN = почта = «тот же везде».
  2. Фишинг страницы «обновите VPN».
  3. Украден ноутбук без блокировки сессии.
  4. Общий PSK в инструкции на файловой шаре.
  5. Сертификат пользователя экспортировали с WS-042.
  6. Компрометация RADIUS-секрета между NPS и шлюзом (редко, очень широко).

Диагностика

Плейсхолдеры: пользователь ivan.petrov, подозрительный внешний 10.0.10.55, клиент Windows WS-042, Linux-бастион host.example.

1. Живые сессии на концентраторе

Снимайте штатными средствами вашего VPN (Windows RRAS, strongSwan, коммерческий SSL VPN — GUI/CLI вендора). Минимум в тикет: username, outer IP, assigned inner IP, время.

Пример RRAS (Windows Server):

Get-RemoteAccessConnectionStatistics | Format-Table UserName, ClientIPAddress, ConnectionDuration
Disconnect-VpnUser -UserName 'ivan.petrov' -ErrorAction SilentlyContinue

Пример strongSwan на Ubuntu host.example (если это ваш концентратор):

sudo ipsec status
sudo ipsec leases
# отключение конкретного SA — по документированной команде вашей версии после идентификации Connection
sudo journalctl -u strongswan --since '7 days ago' | grep -i ivan.petrov | tee /var/ir/vpn-ivan.txt

Не публикуйте здесь «эксплойт IKE». Только статус и лог.

2. RADIUS / NPS / FreeRADIUS

Get-WinEvent -LogName 'Security' -MaxEvents 200 |
  Where-Object { $_.Id -eq 6272 -or $_.Message -match 'ivan\.petrov' }
# 6272 Network Policy Server granted access — штатный ID NPS
sudo grep ivan.petrov /var/log/freeradius/radius.log | tail

3. Что было после туннеля

На DC: 4624 с inner IP. На файловых: SMB. На host.example: SSH с inner.

Решение

Сценарий A. Украден пароль пользователя

  1. Disconnect сессии.
  2. Disable VPN-учётки (часто это тот же AD: Disable-ADAccount или снять из группы VPN-Users).
  3. Сменить пароль, включить/проверить MFA на VPN.
  4. Ревизия: не админ ли это был.
Get-ADUser 'ivan.petrov' -Properties MemberOf
# снимите из группы доступа к VPN до выдачи нового секрета
Remove-ADGroupMember -Identity 'VPN-Users' -Members 'ivan.petrov' -Confirm:$false

Сценарий B. Утек shared PSK site-to-site или «один ключ на всех клиентов»

Это инцидент периметра. Планируйте окно: новый PSK на обоих концах, обновление клиентов. Старый ключ считайте известным атакующему. Временно ограничьте IKE источником (известные IP офисов), если топология позволяет.

Сценарий C. Утек клиентский сертификат

Отзовите сертификат в CA (Revoke + CRL/OCSP), не только пароль. Выпустите новый на чистое устройство.

Сертификаты, профили и второй фактор

После обрыва туннеля пройдите профили: Always-On с машинным сертификатом WS-042$ не умрёт от смены пароля ivan.petrov. Проверьте хранилище Personal на чистом эталоне (не на украденном ноуте) и CRL. Если MFA на VPN не было — включите в этом же изменении, иначе ротация пароля даст сутки спокойствия. Логи NPS 6272/6273 и journal strongSwan сохраните в IR до ротации, которая зашумит Accept новыми легитимными сессиями. Не тестируйте новый пароль, отправив его в чат с того же телефона, где стоял фишинговый «портал VPN».

Как проверить, что проблема устранена

  • Нет активных туннелей ivan.petrov с 10.0.10.55.
  • Access-Accept после отсечки нет, либо только с ожидаемого устройства после нового секрета.
  • Группа VPN-доступа соответствует решению IR.
  • По внутренним логам нет новых 4624 с выданного dirty inner IP.
  • Если меняли PSK — пиры UP, старый ключ нигде в wiki/чате.

Если не помогло

  • Сессия жива после Disconnect — другой продукт/учётка (ivan.petrov vs ivan.petrov@contoso). Ищите дубликаты.
  • Always-On поднимается машинным сертификатом ПК, не паролем пользователя — отзывайте device cert / блокируйте компьютер в AD.
  • После смены пароля AD VPN всё ещё пускает — кеш RADIUS или второй IdP (облачный VPN).
  • Tunnels с нового IP каждые 10 минут — бот с паролем, учётка должна быть Disabled, не «ещё раз Disconnect».

Профилактика

  • MFA на VPN обязательно.
  • Запрет reuse: отдельный секрет или SSO с условным доступом.
  • Не общий PSK для пользователей; сертификаты + device compliance.
  • Алерт: два одновременных туннеля одной учётки.
  • PSK site-to-site в vault, не в Excel.

FAQ

Достаточно ли сменить пароль AD, не трогая VPN-группу?

Если сессия жива — нет. Сначала обрыв и снятие доступа, потом секрет.

Нужно ли менять PSK, если утёк только пароль Ивана?

Нет, если PSK не тот же секрет и не лежал рядом в том же файле. Если в письме «инструкция VPN» был и PSK — меняйте оба.

Иван в отпуске, туннель качается сам

Always-On с его ноутбука. Сверьте устройство. Если ноут у няни/в такси — потеря.

Можно ли забанить /32 10.0.10.55 и не трогать учётку?

Как временный стоп — да. Как решение — нет: пароль работает с любого IP.

Linux-клиент nmcli хранит пароль

После инцидента на чистом ПК удалите connection и создайте заново, не «поменяйте одну цифру».