zapret

zapret v.60

English

For english version refer to docs/readme.eng.txt

Для чего это надо

Автономное, без задействования сторонних серверов, средство противодействия DPI. Может помочь обойти блокировки или замедление сайтов http(s), сигнатурный анализ tcp и udp протоколов, например с целью блокировки VPN.

Проект нацелен прежде всего на маломощные embedded устройства - роутеры, работающие под openwrt. Поддерживаются традиционные Linux системы, FreeBSD, OpenBSD, частично MacOS. В некоторых случаях возможна самостоятельная прикрутка решения к различным прошивкам.

Большая часть функционала работает на windows.

Как побыстрее начать

Читайте docs/quick_start.txt для linux и openwrt, docs/quick_start_windows.txt для windows.

Как это работает

В самом простейшем случае вы имеете дело с пассивным DPI. Пассивный DPI может читать трафик из потока, может инжектить свои пакеты, но не может блокировать проходящие пакеты. Если запрос "плохой", пассивный DPI инжектит пакет RST, опционально дополняя его пакетом http redirect. Если фейк пакет инжектится только для клиента, в этом случае можно обойтись командами iptables для дропа RST и/или редиректа на заглушку по определенным условиям, которые нужно подбирать для каждого провайдера индивидуально. Так мы обходим последствия срабатывания триггера запрета. Если пассивный DPI направляет пакет RST в том числе и серверу, то вы ничего с этим не сможете сделать. Ваша задача - не допустить срабатывания триггера запрета. Одними iptables уже не обойдетесь. Этот проект нацелен именно на предотвращение срабатывания запрета, а не ликвидацию его последствий.

Активный DPI ставится в разрез провода и может дропать пакеты по любым критериям, в том числе распознавать TCP потоки и блокировать любые пакеты, принадлежащие потоку.

Как не допустить срабатывания триггера запрета ? Послать то, на что DPI не расчитывает и что ломает ему алгоритм распознавания запросов и их блокировки.

Некоторые DPI не могут распознать http запрос, если он разделен на TCP сегменты. Например, запрос вида "GET / HTTP/1.1\r\nHost: kinozal.tv......" мы посылаем 2 частями : сначала идет "GET ", затем "/ HTTP/1.1\r\nHost: kinozal.tv.....". Другие DPI спотыкаются, когда заголовок "Host:" пишется в другом регистре : например, "host:". Кое-где работает добавление дополнительного пробела после метода : "GET /" => "GET /" или добавление точки в конце имени хоста : "Host: kinozal.tv."

Существует и более продвинутая магия, направленная на преодоление DPI на пакетном уровне.

Подробнее про DPI : https://habr.com/ru/post/335436 https://geneva.cs.umd.edu/papers/geneva_ccs19.pdf

Что сейчас происходит в России

Раньше , до внедрения повсеместных систем ТСПУ, использовался зоопарк различных DPI у провайдеров. Какие-то были активными, какие-то пассивными. Сейчас время простых iptables окончательно ушло. Везде активный DPI ТСПУ, но кое-где могут оставаться невыключенными дополнительные старые DPI из зоопарка. В этом случае приходится обходить сразу несколько DPI. Все больше становится внереестровых блокировок, о которых вы узнаете только по факту недоступности чего-либо, в списках этого нет. Применяются блокировки некоторых диапазонов ip адресов (автономный обход невозможен) и протоколов (VPN). На некоторых диапазонах IP используется более строгий фильтр, распознающий попытки обмана через сегментацию. Должно быть это связано с некоторыми сервисами, которые пытаются таким образом обмануть DPI.

Как это реализовать на практике в системе linux

Если кратко, то варианты можно классифицировать по следующей схеме :

Пассивный DPI, не отправляющий RST серверу. Помогут индивидуально настраиваемые под провайдера команды iptables. На rutracker в разделе "обход блокировок - другие способы" по этому вопросу существует отдельная тема. В данном проекте не рассматривается. Если вы не допустите срабатывание триггера запрета, то и не придется бороться с его последствиями.
Модификация TCP соединения на уровне потока. Реализуется через proxy или transparent proxy.
Модификация TCP соединения на уровне пакетов. Реализуется через обработчик очереди NFQUEUE и raw сокеты.

Для вариантов 2 и 3 реализованы программы tpws и nfqws соответственно. Чтобы они работали, необходимо их запустить с нужными параметрами и перенаправить на них определенный трафик средствами iptables или nftables.

Для перенаправления tcp соединения на transparent proxy используются команды следующего вида :

проходящий трафик : iptables -t nat -I PREROUTING -i <внутренний_интерфейс> -p tcp --dport 80 -j DNAT --to 127.0.0.127:988 исходящий трафик : iptables -t nat -I OUTPUT -o <внешний_интерфейс> -p tcp --dport 80 -m owner ! --uid-owner tpws -j DNAT --to 127.0.0.127:988

DNAT на localhost работает в цепочке OUTPUT, но не работает в цепочке PREROUTING без включения параметра route_localnet :

sysctl -w net.ipv4.conf.<внутренний_интерфейс>.route_localnet=1

Можно использовать "-j REDIRECT --to-port 988" вместо DNAT , однако в этом случае процесс transparent proxy должен слушать на ip адресе входящего интерфейса или на всех адресах. Слушать на всех - не есть хорошо с точки зрения безопасности. Слушать на одном (локальном) можно, но в случае автоматизированного скрипта придется его узнавать, потом динамически вписывать в команду. В любом случае требуются дополнительные усилия. Использование route_localnet тоже имеет потенциальные проблемы с безопасностью. Вы делаете доступным все, что висит на 127.0.0.0/8 для локальной подсети <внутренний_интерфейс>. Службы обычно привязываются к 127.0.0.1, поэтому можно средствами iptables запретить входящие на 127.0.0.1 не с интерфейса lo, либо повесить tpws на любой другой IP из из 127.0.0.0/8, например на 127.0.0.127, и разрешить входящие не с lo только на этот IP.

iptables -A INPUT ! -i lo -d 127.0.0.127 -j ACCEPT iptables -A INPUT ! -i lo -d 127.0.0.0/8 -j DROP

Фильтр по owner необходим для исключения рекурсивного перенаправления соединений от самого tpws. tpws запускается под пользователем "tpws", для него задается исключающее правило.

tpws может использоваться в режиме socks proxy. В этом случае iptables не нужны, а нужно прописать socks в настройки программы (например, броузера), с которой будем обходить блокировки. transparent proxy отличается от socks именно тем, что в варианте transparent настраивать клиентские программы не нужно.

Для перенаправления на очередь NFQUEUE исходящего и проходящего в сторону внешнего интерфейса трафика используются команды следующего вида :

iptables -t mangle -I POSTROUTING -o <внешний_интерфейс> -p tcp --dport 80 -j NFQUEUE --queue-num 200 --queue-bypass

Чтобы не трогать трафик на незаблокированные адреса, можно взять список заблокированных хостов, заресолвить его в IP адреса и загнать в ipset zapret, затем добавить фильтр в команду :

iptables -t mangle -I POSTROUTING -o <внешний_интерфейс> -p tcp --dport 80 -m set --match-set zapret dst -j NFQUEUE --queue-num 200 --queue-bypass

DPI может ловить только первый http запрос, игнорируя последующие запросы в keep-alive сессии. Тогда можем уменьшить нагрузку на проц, отказавшись от процессинга ненужных пакетов.

iptables -t mangle -I POSTROUTING -o <внешний_интерфейс> -p tcp --dport 80 -m connbytes --connbytes-dir=original --connbytes-mode=packets --connbytes 1:6 -m mark ! --mark 0x40000000/0x40000000 -m set --match-set zapret dst -j NFQUEUE --queue-num 200 --queue-bypass

Фильтр по mark нужен для отсечения от очереди пакетов, сгенерированных внутри nfqws. Если применяется фильтр по connbytes 1:6, то обязательно добавлять в iptables и фильтр по mark. Иначе возможно перепутывание порядка следования пакетов, что приведет к неработоспособности метода.

Для некоторых атак на DPI требуется перенаправлять один или несколько входящих пакетов от соединения :

iptables -t mangle -I PREROUTING -i <внешний_интерфейс> -p tcp --sport 80 -m connbytes --connbytes-dir=reply --connbytes-mode=packets --connbytes 1:6 -m set --match-set zapret src -j NFQUEUE --queue-num 200 --queue-bypass

Получаемые пакеты будут фильтровться по входящему интерфейсу, порту и IP источника, то есть наоборот прямому правилу.

Некоторые техники, ломающие NAT, не всегда можно реализовать через iptables. Требуются nftables.

Если ваше устройство поддерживает аппаратное ускорение (flow offloading, hardware nat, hardware acceleration), то iptables могут не работать. При включенном offloading пакет не проходит по обычному пути netfilter. Необходимо или его отключить, или выборочно им управлять.

В новых ядрах (и в более старых, openwrt портировал изменение на 4.14) присутствует software flow offloading (SFO). Пакеты, проходящие через SFO, так же проходят мимо большей части механизмов iptables. При включенном SFO работает DNAT/REDIRECT (tpws). Эти соединения исключаются из offloading. Однако, остальные соединения идут через SFO, потому NFQUEUE будет срабатывать только до помещения соединения в flowtable. Практически это означает, что nfqws будет работать на window size changing, но не будут работать опции по модификации содержимого пакетов. Offload включается через специальный target в iptables "FLOWOFFLOAD". Не обязательно пропускать весь трафик через offload. Можно исключить из offload соединения, которые должны попасть на tpws или nfqws. openwrt не предусматривает выборочного управления offload. Поэтому скрипты zapret поддерживают свою систему выборочного управления offload в openwrt.

Особенности применения ip6tables

ip6tables работают почти точно так же, как и ipv4, но есть ряд важных нюансов. В DNAT следует брать адрес --to в квадратные скобки. Например :

ip6tables -t nat -I OUTPUT -o <внешний_интерфейс> -p tcp --dport 80 -m owner ! --uid-owner tpws -j DNAT --to [::1]:988

Параметра route_localnet не существует для ipv6. DNAT на localhost (::1) возможен только в цепочке OUTPUT. В цепочке PREROUTING DNAT возможен на любой global address или на link local address того же интерфейса, откуда пришел пакет. NFQUEUE работает без изменений.