[ON] Анализ перехвата провайдерами транзитного DNS-трафика

[rssbot]

Группа исследователей из нескольких университетов США и Китая провела исследование степени вмешательства провайдеров в транзитный DNS-трафик пользователей. Для обращения к DNS в большинстве случаев не применяются технологии аутентификации (DNSSEC) и шифрования (DNS over TLS/HTTPS), что позволяет провайдерам легко перехватывать и перенаправлять на свои сервера DNS-запросы к публичным DNS-серверам, таким как 8.8.8.8 (Google), 1.1.1.1 (Cloudflare), OpenDNS, Dyn DNS и Edu DNS. Основными мотивами перенаправления обычно является желание сэкономить трафик, снизить время отклика, обеспечить дополнительную защиту или реализовать блокировку запрещённых ресурсов.

В ходе исследования была изучена целостность доставки DNS-запросов c 148 тысяч клиентских IP-адресов, охватывающих 3047 автономных систем различных провайдеров. В итоге было обнаружено, что 0.66% всех запросов по протоколу TCP к публичным DNS-серверам перехватываются и подобный перехват практикуется владельцами 259 (8.5%) автономных систем. Предполагается, что для UDP, в силу более простой организации перехвата, доля проблемных систем заметно выше (в выборочной проверке в 3-4 раза), но точно оценить долю перехвата по UDP не удалось из-за применения для анализа вмешательства на системах 36 тысяч пользователей прокси-сети ProxyRack, позволяющей отправлять запросы только через TCP SOCKS (для остальных пользователей применялось отладочное мобильное приложение, которое позволило выявить подмену и по UDP).

Метод определения перехвата был основан на отправке запроса на резолвинг уникального хоста (UUID.OurDomain.TLD) ) с последующей проверкой c какого DNS-резолвера поступил запрос на обслуживающий данный хост авторитативный DNS-сервер (например, о перехвате свидетельствует активность, когда клиентом был отправлен запрос резолвинга на 8.8.8.8, а к авторитативному серверу пришёл запрос от стороннего IP провайдера, а не от DNS-сервера Google).

Наибольшая активность перехвата наблюдается в Китае, в котором из 356 автономных систем перехват применяется в 61 AS (17% от всех рассмотренных в данной стране AS), в России - 44 AS (28%), в США - 15 AS (9%), Бразилии и Индонезии по 7 AS (4%).

Из методов перехвата трафика наиболее популярными являются перенаправление запросов и реплицирование ответа (оригинальный запрос и ответ не блокируются, но провайдер также направляет свой подставной ответ, который обычно приходит раньше и воспринимается клиентом). Как правило, в рамках одной автономной системы используется один метод перехвата, который применяется к конкретным внешним DNS-серверам, что свидетельствует о применении провайдером единой политики.

Наиболее часто перехватываемым публичным DNS-сервером стал сервис Google (8.8.8.8), для которого в Китае перехватывается 27.9% запросов по UDP и 7.3% по TCP. В 82 автономных системах перехватывается более 90% трафика к Google DNS. При этом в AS9808 (Guangdong Mobile) зафиксирована подмена результата для 8 запросов к Google Public DNS, в которых вместо запрошенного хоста был выдан ответ с IP рекламного сайта, продвигающего приложение China Mobile.

Из заслуживающих внимание выводов также можно упомянуть то, что на 97 DNS-серверах провайдеров, которые использовались для перехвата DNS-трафика, выявлены устаревшие версии DNS-сервера BIND, поддержка которых была прекращена ещё в 2009 году и которые подвержен DoS-уязвимостям. 57% из DNS-серверов, применяемых для перенаправления, не поддерживают DNSSEC. Попытка оправдать некоторыми провайдерами перехват трафика желанием уменьшить время отклика поставлена под сомнение, так как ускорение незначительно, а для 15.37% UDP-запросов внешние публичные серверы отработали даже быстрее.


Источник: https://www.opennet.ru/opennews/art.shtml?num=49162
(opennet.ru, основная лента)

[chitatel]

Вот жеж блин...

Вот есть такая штука - dnscrypt-proxy, она даже работает. Однако основной разработчик, как я понял, проект закопал проклял и ушёл вмонастырь, в результате работает эта штука не няшно. Год назад можно было скачивать список живых серверов, поддерживающих криптованный dns, и этот список более-менее регулярно обновлялся. Сейчас он старый, как говно мамонта, и не обновляется. Через это у меня сервис периодически раз в сутки минимум отваливается, приходится перезапускать, порой до нескольких раз, пока не получается ответ от какого-либо живого сервера.

Есть ли тут люди, решившие проблему? Поделитесь полезным юзкейсом.