**Требования для деанонимизации (раскрытия) VPN-трафика** * Целевой хост должен принять DHCP-аренду от сервера, контролируемого злоумышленником. * DHCP-клиент целевого хоста должен поддерживать опцию DHCP 121. **Мы хотим подчеркнуть, что существуют способы, с помощью которых злоумышленник, находящийся в той же сети, что и целевой пользователь, может стать его DHCP-сервером:** * Вредоносный DHCP-сервер, использующий атаку DHCP starvation против настоящего DHCP, а затем отвечающий новым клиентам. Мы добились этого в лабораторных условиях и работаем над последующим постом в блоге. * Вредоносный DHCP-сервер, опережающий запросы DHCPDISCOVER, чтобы воспользоваться распространенным поведением DHCP-клиентов, заключающимся в выборе первой предложенной аренды. * Подмена (спуфинг) ARP для перехвата трафика между настоящим DHCP-сервером и клиентом, а затем ожидание, пока клиент обновит свою аренду. **Выполнение атаки** * Наша методика заключается в запуске DHCP-сервера в той же сети, что и целевой пользователь VPN, а также в настройке нашей DHCP-конфигурации для использования себя в качестве шлюза. Когда трафик попадает на наш шлюз, мы используем правила переадресации трафика на DHCP-сервере, чтобы передавать трафик через легитимный шлюз, одновременно прослушивая его. * Мы используем опцию DHCP 121 для установки маршрута в таблице маршрутизации пользователя VPN. Устанавливаемый нами маршрут является произвольным, а при необходимости мы можем установить и несколько маршрутов. Устанавливая маршруты, которые являются более специфичными, чем диапазон CIDR /0, используемый большинством VPN, мы можем создать правила маршрутизации, имеющие более высокий приоритет, чем маршруты для виртуального интерфейса, создаваемого VPN. Мы можем установить несколько маршрутов /1, чтобы воссоздать правило 0.0.0.0/0 для маршрутизации всего трафика, установленное большинством VPN. * Установка маршрута также означает, что сетевой трафик будет отправляться через тот же интерфейс, что и DHCP-сервер, а не через виртуальный сетевой интерфейс. Это предусмотренная функциональность, которая нечетко прописана в RFC. Таким образом, для маршрутов, которые мы устанавливаем, трафик никогда не шифруется виртуальным интерфейсом VPN, а вместо этого передается сетевым интерфейсом, взаимодействующим с DHCP-сервером. Будучи злоумышленником, мы можем выбрать, какие IP-адреса будут проходить через туннель, а какие - через сетевой интерфейс, взаимодействующий с нашим DHCP-сервером.
Вы бы хоть источник указали, что-ли. При этом, адаптация на русский язык вышла крайне корявой и неполной.
