peter23 2 фев 2015 в 12:47

Исследование механизма блокировки сайтов «Ростелекомом» и способы ее обхода

6 мин

106K

Сетевые технологии*

+50

Комментарии 45

Rondo 2 фев 2015 в 13:02

Многое уже было описано до вас:
Определитель типа блокировки сайтов у провайдера habrahabr.ru/post/228305/
Статистика применяемых средств блокирования сайтов habrahabr.ru/post/229377/
tl;dr -> github.com/ValdikSS/blockcheck

peter23 2 фев 2015 в 15:07

Тут я несколько иное описал — подробное изучение конкретного метода блокировки у конкретного провайдера (одного из крупнейших в РФ). И выводы о способах его обхода.

ValdikSS 2 фев 2015 в 17:56

Стоило вам присмотреться к трафику, который приходит на интерфейс от Ростелекома. Вероятно, DPI подключен параллельно, а не последовательно, и туда приходит только клиентский трафик. Т.к. DPI стоит явно ближе, чем вебсайт, пакет с Location от DPI приходит быстрее, чем реальный первый пакет от сайта, а пакет от сайта уже отбрасывается ядром ОС как ретрансмиссия, поэтому, если вы используете Linux, достаточно одной строки в iptables, чтобы обойти блокировку:

iptables -A INPUT -p tcp --sport 80 -m string --algo bm --string "http://95.167.13.50/?st" -j DROP

peter23 2 фев 2015 в 18:57

Действительно, есть ретрансмиссия. Я смотрел трафик, но очевидно недостаточно внимательно.
Сначала приходит пакет, в котором только HTTP 302 и Location, затем приходит пакет с нормальным ответом сайта.
Однако система не отбрасывает второй пакет, а своеобразно объединяет с первым.
Т.е. приходят пакеты

HTTP/1.1 302 Found
Connection: close
Location: http://95.167.13.50/?st=0&dt=192.237.142.117&rs=grani.ru/

HTTP/1.1 200 OK
Server: nginx/1.2.1
Date: Sun, 01 Feb 2015 17:34:03 GMT
Content-Type: text/html; charset=utf-8
Transfer-Encoding: chunked
Connection: keep-alive

6d7
<!DOCTYPE HTML>
...

А приложение видит это

так

HTTP/1.1 302 Found
Connection: close
Location: http://95.167.13.50/?st=0&dt=192.237.142.117&rs=grani.ru/

f-8
Transfer-Encoding: chunked
Connection: keep-alive

6d7
<!DOCTYPE HTML>
...

Это наблюдается и в Windows и в Linux.

Но приведенное вами правило действительно решает вопрос.
Добавлю в пост :)

zalexz 5 июн 2020 в 15:51

Можно как-то повторить этот трюк на Mac OS и Windows 10?

НЛО прилетело и опубликовало эту надпись здесь

ValdikSS 8 июн 2020 в 01:38

Для macOS: github.com/dzhidzhoev/AntiRTDPI

FSA 2 фев 2015 в 15:00

Интересно, а можно ли через плагины заставить Firefox или Chrome игнорировать вредоносные редиректы на адрес Ростелекома?

peter23 2 фев 2015 в 15:05

Там не просто нужно игнорировать редирект, а именно восстановить заголовок. В частности Content-Type часто затирается.

Если плагины имеют права на модификацию заголовков, то это возможно. В таком случае и прокси не понадобится.

TiFFolk 2 фев 2015 в 15:14

уважаемый автор, подскажите пожалуйста, каким образом оператор заставит пользователей доверять своему сертификату для того, чтобы залезть в https

peter23 2 фев 2015 в 15:18

Никак. Когда они залазят в https, пользователи видят в браузерах сообщение о подмене сертификата.
Они несколько раз включали такой механизм для https-сайтов из реестра, потом отключали.

k0ldbl00d 2 фев 2015 в 16:13

В Squid 3.2.x, например, есть SSLBump. На каждый домен (например, vk.com) динамически генерится сертификат, подписанный своим CA. Единственное условие — чтобы этот CA был установлен как доверенный в браузере пользователя (мой ответ неточный, но смысл в целом такой). Я пользовался этой штукой, чтобы фильтровать https-трафик и собирать статистику юзеров на одном предприятии.

Статья на тему: habrahabr.ru/post/168515/

peter23 2 фев 2015 в 16:17

Если какой-то CA начнет так делать, то сертификат этого CA будет отозван из списка доверенных.
Ростелеком, когда начинает лезть в https, подписывает все своим собственным сертификатом, выданным для *.rt.ru. Либо у РТ нет своего CA, либо они им не рискуют.

dollar 2 фев 2015 в 23:48

А как жестко забанить у себя все сертификаты *.rt.ru, даже те, которые еще не появились? Так, на всякий пожарный.

Rondo 3 фев 2015 в 14:51

Для винды можно так попробовать — создать через makecert самоподписанный сертификат с CN=*.rt.ru и положить его в Untrusted certificates (certmgr.msc), хотя у меня есть сомнения в правильности этого способа.

НЛО прилетело и опубликовало эту надпись здесь

Rondo 3 фев 2015 в 16:33

Спасибо за совет, сохранил их сертификат, добавил в «Untrusted certificates» — при открытии страницы https://rt.ru IE и Chrome ругаются на отозванный сертификат, а FF почему-то нет.

KorDen32 3 фев 2015 в 16:38

У FF своя база сертификатов, нужно добавлять в самом FF… Вот только как там добавить исключение именно для блокировки — не знаю…

Doktor_Gradus 2 фев 2015 в 16:26

Элементарно. Люди периодически видят предупреждения о самоподписанных сертификатах и дают разрешение на использование, особо не вчитываясь.

k0ldbl00d 2 фев 2015 в 17:22

Для сайтов с HSTS и Chrome современных версий уже не прокатывает. Нельзя просто взять и дать разрешение (хотя всегда можно открыть в другом браузере).

state13 2 фев 2015 в 17:38

В Хроме ссылка на сайт прячется в «Дополнительно».

k0ldbl00d 2 фев 2015 в 18:04

Для обычных сайтов — да, но для сайтов с HSTS там ссылки нет. blogs.msdn.com/cfs-filesystemfile.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-00-47-13-metablogapi/8446.chrome37_5F00_404325B2.png

Doktor_Gradus 2 фев 2015 в 22:46

А для сайтов с HSTS блокировки актуальны?

KorDen32 2 фев 2015 в 23:10

GET https://github.com/
...
Strict-Transport-Security: max-age=31536000; includeSubdomains; preload

НЛО прилетело и опубликовало эту надпись здесь

peter23 2 фев 2015 в 16:01

Да, я писал

Отправка URL и Host разными пакетами.
Можно просто сначала вызвать send для первой строки запроса (HTTP-метод и URL), а затем обычным образом отправлять остальную часть запроса.

grumbler66rus 3 фев 2015 в 12:59

В iptables — одна строчка в таблице mangle
-A FORWARD -o eth1 -p tcp --tcp-flags SYN,RST SYN -m tcp --dport 80 -j TCPMSS --set-mss 10

peter23 3 фев 2015 в 13:16

По идее это не очень хорошо, ведь это приведет к тому, что весь обмен трафиком с сервером будет идти пакетами по 10 байт. Или я что-то упускаю?

grumbler66rus 3 фев 2015 в 13:55

Совершенно верно. «не очень хорошо» означает всего лишь увеличение служебного трафика. В случае IPv4 это 40 байт заголовков на каждый пакет. При современных каналах IMHO проблема невелика.

Chamie 3 фев 2015 в 18:48

40 байт на каждые 10? Т.е., в пять раз?

ValdikSS 3 фев 2015 в 19:57

Это очень плохо, это будет нереально тормозить интернет. Как крайний выход — устанавливать MSS, равный 10, только на заблокированные IP. Но вообще, по идее, в интернете нельзя использовать MSS меньше, чем 536 для IPv4 и 516 для IPv6.

Вообще, вот скрипт для OpenWRT и Ростелекома. Блокирует пакет от DPI на 80 порту, блокирует подмену сертификата для HTTPS.
github.com/proukornew/rt_iptables/blob/master/ipset.sh

KorDen32 4 фев 2015 в 00:02

О, спасибо, стащу к себе часть кода добавлялки дополнительных IP в фильтр (если они не резолвятся). Как будет возможность, потестирую на ростелекоме для Zyxel Keenetic с прошивкой первого поколения (там почти штатно сродни OpenWRT, но отличия есть)

Athari 2 фев 2015 в 16:19

С дом.ру/эртелекомом не сработает, ответ стабильный:

HTTP/1.1 302 Moved Temporarily
Cache-Control: no-cache,no-store,max-age=1
Pragma: no-cache
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Connection: close
Content-Length: 13
Location: http://lawfilter.ertelecom.ru

<html></html>

Реагирует только на GET, на регистр и пробелы пофиг.

peter23 2 фев 2015 в 16:22

Интересно было бы поэкспериментировать. Можете дать VPN на роутер? :)

Ну или попробуйте разные описанные варианты, в частности передачу заголовка Host в отдельном пакете.

KorDen32 2 фев 2015 в 23:12

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

Athari 3 фев 2015 в 00:10

Уже не только DNS. :(

inkvizitor68sl 2 фев 2015 в 18:01

> а в этой версии протокола не было заголовка Host, поэтому со многими сайтами это работать не будет.
Не не было, а был не обязательным.

Иначе бы, например, proxy_pass в nginx никогда не работал бы — он очень долгое время работал по HTTP/1.0 =)

inkvizitor68sl 2 фев 2015 в 18:03

> # кэшируем dns
> nscache 65536

А за такое нужно бить тапком по пальцам.

peter23 2 фев 2015 в 18:09

Без кэширования DNS-запросов прокси будет дергать DNS на каждый запрос. Очевидно, это будет приводить к задержкам.
А в чем вообще проблема с кэшированием в данном случае? Это же собственный прокси для собственного серфинга. Без использования прокси тоже самое кэширование DNS делает сам браузер.

inkvizitor68sl 2 фев 2015 в 18:30

В DNS и так есть кеширование. И есть TTL, на который полагаются админы и вообще команды сервисов.
А на практике, из-за таких рекомендаций, как выше, ещё месяц-два после смены dns-записи трафик ломится на старый IP.

peter23 2 фев 2015 в 18:44

В описанном мной случае смысл кэшировать DNS определенно есть, равно как есть смысл кэшировать DNS в браузере.
Без кэширования DNS происходило бы следующее:
— пришел запрос на www.example.com/, дернули DNS, только после получения ответа DNS можем обрабатывать запрос
— пришел запрос на www.example.com/scripts.js, дернули DNS, только после получения ответа DNS можем обрабатывать запрос
— пришел запрос на www.example.com/style.css, дернули DNS, только после получения ответа DNS можем обрабатывать запрос
и т.д.
Очевидно, что даже при наличии локального DNS вносятся заметные задержки.
HTTP Keep-Alive конечно сгладил бы негативный эффект, но не отменил бы его.

Вообще в данном случае прокси, кэшируя DNS, делает тоже самое, что и браузер.
При работе через прокси браузер не посылает DNS запросы, это делает прокси.
Поэтому и кэшировать DNS тоже должен прокси.

Что касается TTL, то я уверен, что 3proxy (как и браузер) учитывает его в алгоритме кэширования.

inkvizitor68sl 2 фев 2015 в 18:59

> Вообще в данном случае прокси, кэшируя DNS, делает тоже самое, что и браузер.
Вот только браузеры TTL учитывают.

> Что касается TTL, то я уверен, что 3proxy (как и браузер) учитывает его в алгоритме кэширования.
Нет. В данном примере написано «любую dns-запись кешировать на 65536 секунд». Для примера, у меня TTL — 360 секунд на всех хостах.

peter23 2 фев 2015 в 19:01

На самом деле в данном примере написано «кэшировать DNS, размер кэша 65536 записей».
65536 это лишь размер кэша, но не время кэширования.

inkvizitor68sl 2 фев 2015 в 19:03

Хым. И правда.
Пардон тогда.

0din 3 фев 2015 в 12:52

Для блокировки HTTPS трафика, многие DPI также смотрят на поле SNI, что позволяет блокировать не по IP, а по доменному имени. Фильтровать конкретный URI в пределах домена «увы» не получиться.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий