Легитимный сценарий утечки VPN-трафика

Рассмотрим хост, который поддерживает оба стека протоколов, использует VPN-клиент (работающий только с IPv4-трафиком) для подключения к VPN-серверу и подключен к dual-stacked сети. Если какому-то приложению на хосте нужно взаимодействовать с dual-stacked узлом, клиент обычно запрашивает и А, и АААА-DNS-записи. Так как хост поддерживает оба протокола, а удаленный узел будет иметь оба типа DNS-записей (А и АААА), то одним из вероятных вариантов развития событий будет использование для связи между ними IPv6-протокола. А так как VPN-клиент не поддерживает шестую версию протокола, то IPv6-трафик не будет отправляться через VPN-соединение, а будет отправляться в открытом виде через локальную сеть.
Такой вариант развития событий подвергает угрозе передаваемые в открытом виде ценные данные, в то время как мы думаем, что они безопасно передаются через VPN-соединение. В данном конкретном случае утечка VPN-трафика является побочным эффектом использования ПО, не поддерживающего IPv6, в сети (и на хосте), поддерживающей(ем) оба протокола.
Преднамеренно вызываем утечку VPN-трафика
Атакующий может преднамеренно вызвать подключение по протоколу IPv6 на компьютере жертвы, посылая поддельные ICMPv6 Router Advertisement сообщения. Подобные пакеты можно рассылать при помощи таких утилит, как rtadvd Ibit.ly/WUH&x), SI6 Networks' IPv6 Toolkit lbit.lv/TYdw6jl или THC - IPv6 lbit.ly/150FQbCl. Как только соединение по протоколу IPv6 установлено, «общение» с системой, поддерживающей оба стека протоколов, может вылиться, как рассмотрено выше, в утечку VPN-трафика.
И хотя данная атака может быть достаточно плодотворной (из-за растущего числа сайтов, поддерживающих IPv6), она приведет к утечке трафика, только когда получатель поддерживает обе версии протокола IP. Однако для злоумышленника не составит труда вызвать утечки трафика и для любого получателя (dual-stacked или нет). Рассылая поддельные Router Advertisement сообщения, содержащие соответствующую RDNSS-опцию, атакующий может прикинуться локальным рекурсивным DNS-сервером, затем провести DNS-спуфинг, чтобы осуществить атаку man-in-the-middle и перехватить соответствующий трафик. Как и в предыдущем случае, помогут такие инструменты, как SI6 Networks' IPv6 Toolkit и THC-IPv6.
ПОЛЕЗНЫЕ СОВЕТЫ
Совсем не дело, если трафик, не предназначенный для чужих глаз, попадет в открытом виде в сеть. Как же обезопаситься в таких ситуациях? Вот несколько полезных рецептов:
1. Если VPN-клиент сконфигурирован таким образом, чтобы отправлять весь IPv4-трафик через VPN-соединение, то:
•если IPv6 VPN-клиентом не поддерживается - отключить поддержку шестой версии протокола IP на всех сетевых интерфейсах. Таким образом, у приложений, запущенных на компьютере, не будет другого выбора, как использовать IPv4;
•если IPv6 поддерживается - убедиться, что весь IPv6-трафик также отправляется через VPN.
2. Чтобы избежать утечки трафика, в случае если VPN-соединение внезапно отвалится, и все пакеты будут отправляться через default gateway, можно:
•принудительно заставить весь трафик идти через VPN
> route delete 0.9.0.0 192.168.1.1 // удаляем default
// gateway
> route add 83.170.76.128 mask 255.255.255.255 192.168.1.1 metric 1
•воспользоваться утилитой VPNetMon (bit.ly/HKpREg), которая отслеживает состояние VPN-соединения и, как только оно пропадает, мгновенно завершает указанные пользователем приложения (например, торрент-клиенты, веб-браузеры, сканеры);
•или утилитой УРМСЬеск(ЬП.1у/МХ2Р_гп), которая в зависимости от выбора пользователя может либо полностью отключить сетевую карту, либо просто завершить указанные приложения.
3. Проверить, уязвима ли твоя машина к утечке DNS-трафика, можно на сайте dnsleaktest.com, после чего применить советы, как пофиксить утечку, описанные тут: bit.ly/H KpQZ8.

Похожие записи:

Утечка VPN-трафика

Расшифровка VPN-трафика

Мониторинг сетевого трафика