Windows RRAS как IPsec-клиент
Dec. 7th, 2018 02:37 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
cat_muciusДавно я Микрософт не ругал.
Понадобилось тут прокинуть site-to-site IPsec-туннель между FortiGate и Windows-сервером. Документации по такому сценарию нагуглилось ноль, пришлось действовать методом проб и ошибок. Благодаря сниффингу, дебаггингу и молитвам к известной матери построить таки получилось - см. описание в технобложике. Но до чего ж я в процессе пыли нажрался, и всё благодаря замечательным качествам Windows RRAS (Routing & Remote Access Service).
Сюрприз первый - ограничить принимаемые сертификаты от второй стороны только выписанными определённым CA нельзя. Можно жмякнуть по галке "Verify Name and Usage attributes of the server's certificate", и на этом всё. То есть да, будет проверено, что в сертификате значится хостнейм, к которому мы обращаемся, что сертификат не протух и что он подписан валидным CA. Да только этих валидных CA на любом Windows - несколько десятков!
То есть если между двумя сторонами сидит хакер, который может направить трафик на адрес Фортигейта на свой сервер (через DNS ли, через раутинг ли) - то он может как нефиг делать получить на этот хостнейм сертификат от LetsEncrypt, с их-то смехотворной верификацией. И затем выдавать себя за Фортигейт. Подключиться к Фортигейту от имени RRAS ему не выйдет - Фортигейт-то как раз проверяет, какой CA удостоверил вторую сторону. Но если обе стороны - Windows, то вот вам полноценный рецепт на man-in-the-middle.
В общем-то, эта проблема касается практически всех VPN-клиентов для рабочих станций, но для гейтов, связывающих сети разных организаций, хотелось бы большего.
(Справедливости ради, Windows позволяет использовать поверх IPsec протокол EAP, а вот там-то CA ограничивать можно. Но:
это усложняет инфраструктуру - нужен RADIUS (и проверяется сертификат именно RADIUS, а не VPN-гейта)
документации по такому использованию EAP у Фортинета примерно ноль, но в этом не Микрософт виноват,
это поверх - уже после аутентификации IPsec; проверяет оно юзера, и клиентский сертификат должен сидеть в профиле юзера. Как это заставить работать с автоматическим подключением RRAS? Может, если запустить certmgr.msc под SYSTEM и импортировать туды, то и выгорит...
В общем, дикие траблы. Скорее всего, не взлетит. Да и точно ли это устраняет MiTM?)
Этого можно было бы легко избежать, попросту перейдя с сертификатов на pre-shared keys, однако тут нас ждёт сюрприз второй - это работает примерно с десятого раза на двадцатый. Подозреваю баг. Девять раз получаешь "authentication failed", на десятый неожиданно подключаешься. Забиваешь PSK заново - сразу подключаешься; если отключишься, то по новой. Причём, похоже, работает только если сессию инициирует Фортигейт.
Сюрприз третий - назначить статический адрес диал-ап интерфейсу нельзя, настройки игнорируются. Because fuck you. В какой-то момент получилось через "netsh interface ipv4 add address", потом снова обломись.
Сюрприз четвёртый - банальный forwarding между LAN и туннелем раз работает, а раз нет. Почему - понять не удалось.
В общем - если рассудок и жизнь дороги вам, держитесь подальше от торфяных болот.
Понадобилось тут прокинуть site-to-site IPsec-туннель между FortiGate и Windows-сервером. Документации по такому сценарию нагуглилось ноль, пришлось действовать методом проб и ошибок. Благодаря сниффингу, дебаггингу и молитвам к известной матери построить таки получилось - см. описание в технобложике. Но до чего ж я в процессе пыли нажрался, и всё благодаря замечательным качествам Windows RRAS (Routing & Remote Access Service).
Сюрприз первый - ограничить принимаемые сертификаты от второй стороны только выписанными определённым CA нельзя. Можно жмякнуть по галке "Verify Name and Usage attributes of the server's certificate", и на этом всё. То есть да, будет проверено, что в сертификате значится хостнейм, к которому мы обращаемся, что сертификат не протух и что он подписан валидным CA. Да только этих валидных CA на любом Windows - несколько десятков!
То есть если между двумя сторонами сидит хакер, который может направить трафик на адрес Фортигейта на свой сервер (через DNS ли, через раутинг ли) - то он может как нефиг делать получить на этот хостнейм сертификат от LetsEncrypt, с их-то смехотворной верификацией. И затем выдавать себя за Фортигейт. Подключиться к Фортигейту от имени RRAS ему не выйдет - Фортигейт-то как раз проверяет, какой CA удостоверил вторую сторону. Но если обе стороны - Windows, то вот вам полноценный рецепт на man-in-the-middle.
В общем-то, эта проблема касается практически всех VPN-клиентов для рабочих станций, но для гейтов, связывающих сети разных организаций, хотелось бы большего.
(Справедливости ради, Windows позволяет использовать поверх IPsec протокол EAP, а вот там-то CA ограничивать можно. Но:
В общем, дикие траблы. Скорее всего, не взлетит. Да и точно ли это устраняет MiTM?)
Этого можно было бы легко избежать, попросту перейдя с сертификатов на pre-shared keys, однако тут нас ждёт сюрприз второй - это работает примерно с десятого раза на двадцатый. Подозреваю баг. Девять раз получаешь "authentication failed", на десятый неожиданно подключаешься. Забиваешь PSK заново - сразу подключаешься; если отключишься, то по новой. Причём, похоже, работает только если сессию инициирует Фортигейт.
Сюрприз третий - назначить статический адрес диал-ап интерфейсу нельзя, настройки игнорируются. Because fuck you. В какой-то момент получилось через "netsh interface ipv4 add address", потом снова обломись.
Сюрприз четвёртый - банальный forwarding между LAN и туннелем раз работает, а раз нет. Почему - понять не удалось.
В общем - если рассудок и жизнь дороги вам, держитесь подальше от торфяных болот.
