В скриптах ipset/get_reestr* сделана поддержка ipban.
Забаненными IP считаются IP из реестра, которым не назначен hostname.
Источник : https://raw.githubusercontent.com/zapret-info/z-i/master/dump.csv
На деле какие-то IP забанены, какие-то нет. В dump.csv нет информации разбанена ли запись или нет.
Потому лист избыточен
Добавлена возможность переопределить порты для некоторых протоколов, проведенных через основные скрипты
#HTTP_PORTS=80-81,85
#HTTPS_PORTS=443,500-501
#QUIC_PORTS=443,444
Может понадобится, если DPI сечет разные порты.
Но вбивать сюда 1-65535 крайне не рекомендовано, поскольку весь трафик может упасть на nfqws или tpws
Переменные конфига
OPENWRT_WAN4
OPENWRT_WAN6
позволяют переопределить в openwrt WAN интерфейсы для ipv4 и ipv6
интерфейсы задаются как имена логических интерфейсов netifd (wan,lan), а не интерфейсов linux (eth0, eth1, br-lan)
множественные интерфейсы пишутся в кавычках через пробел
все по аналогии с OPENWRT_LAN
полезно, когда у вас несколько ipv6 аплинков, и общая стратегия может ломать другой аплинк
проверка : /etc/init.d/zapret list_ifsets
Вынес отдельным скриптом install_prereq.sh установку дополнительных пакетов в ОС.
Это надо для упрощения начальной процедуры развертывания, когда install_easy еще не выполнен и надо запускать blockcheck.sh.
Чтобы не запускать install_easy и не прерывать его после установки пакетов, и чтобы не помнить/читать про необходимые пакеты, не копипастить большие команды по их установке. Вместо этого install_bin + install_prereq сразу готовят систему к blockcheck
Заменил в nfqws дефолтный фейк http/https с w3.org на iana.org.
w3.org переехал на cloudflare.
Особенность cloudflare такова, что он позволяет дергать все свои сайты с любых своих IP.
Теперь представьте, что вы тестите в блокчеке rutracker.org, который тоже на клауде.
Если TTL превысит длину пути до сервера, то сервер получит фейк.
И вместо отлупа мы получаем 200 OK или 307 redirect, как будто все в порядке.
А на самом деле не в порядке, эта стратегия будет ломать сайт.
Хочу обратить внимание на особенности применения zapret в текущих условиях в России.
Сейчас ТСПУ любят ставить у магистралов, потому приходится сдвигать TTL дальше провайдера. Может быть и 8, и даже 11.
Может быть балансировка нагрузки на разные магистралы. И на одном DPI на 5-м , на другом на 11-м.
Значит от раза к разу количество хопов может быть разным до сервера из-за разного маршрута.
Может быть и такое, что на разные направления идет стабильно разный маршрут.
Чтобы обойти какие-то сайты на одном маршруте, вы ставите 11, но на другие маршрут иной, существенно короче, и там идет облом.
Проблема случается, когда фейковые пакеты без фулинга доходят до сервера и воспринимаются им как реальные пакеты от клиента. На http это могут быть ошибки 400. Так реагируют сервера на необслуживаемый домен (iana.org, w3.org)
На https будут ошибки другого вида, связанные с невозможностью выполнить TLS handshake.
Вообщем, здесь необходим дополнительный ограничитель.
Самый универсальный и совместимый - md5sig. Но он работает только с linux серверами.
badsum, кажется, перестал работать на многих провайдерах. Возможно, DPI стали проверять tcp checksum
badseq, как показывает практика, может работать только с https, но не работать с http (особенности DPI от rdp.ru/ТСПУ)
blockcheck.sh был создан не как конечный судья, выносящий вердикт “какие буковки писать сюда”.
Он скорее напоминает томограф, а вы - врач, изучающий томограмму и ставящий диагноз. За вас он это не всегда сможет сделать.
Потому тут надо думать и понимать что происходит, чтобы получить надежный результат, а не когда-то открывается, когда-то нет, а почему я без понятия, все вписал как сказали. Нет, это уже тоже не всегда работает
Самый бронебойный вариант - обход только нужных вам сайтов, которые можно вписать в фильтр по ip или hostlist, или же autohostlist.
autohostlist хорош тем, что при должной настройке и минимальном обслуживании не трогает то, что трогать не нужно, тем самым минимизируя риск поломки всевозможных сбербанков.
Но это не избавляет от необходимости находить надежную стратегию, иначе не будет нормально работать обход того, что вам нужно
- tpws : поддержка нового метода десинхронизации --oob. Посылка нулевого out of band байта после первой части сплита.
- Перевод схемы nftables на обслуживание tcp соединений после NAT (POSTNAT). Это позволяет задействовать атаки, ломающие NAT. При использовании MASQUERADE они невозможны на iptables, поскольку iptables не позволяют перехватить трафик после NAT.
В nftables теперь используется еще 1 бит в mark : DESYNC_MARK_POSTNAT. Так помечаются пакеты, перенаправляемые на nfqws в POSTNAT режиме. Чтобы потом можно было пакеты, генерируемые в nfqws, помечать как notrack, чтобы NAT их не ломал.
POSTNAT ломает десинхронизацию UDP протоколов с первого пакета, поэтому udp идет по старинке в PRENAT режиме - Режим дурения datanoack. Ломающий NAT режим, требует внешнего IP адреса на системе, где производится атака. Отсылка дурящего пакета без флага ACK. Это неправильно, поэтому сервера отбрасывают, а DPI может схавать
- Режим autottl в nfqws. На каких-то провайдерах может неплохо работать, на каких-то хуже или вообще плохо. Можно пробовать крутить параметры. Какой TTL выбрал автомат видно в nfqws --debug. Там же и видны TTL обрабатываемых пакетов. Для реализации режима требуется перенаправить как минимум первый пакет SYN,ACK
Как работает autottl.
--dpi-desync-autottl=[<delta>[:<min>[-<max>]]]
Берется входящий TTL. Если он ниже не более, чем на 31 хоп от стандартных значений 64,128,255, то соответствующее значение берется за исходный TTL входящего пакета и вычисляется длина пути как разница.
При других TTL алгоритм идет в отказ.
Далее от длины пути отнимается дельта, которую можно указать в параметре --dpi-desync-autottl. По умолчанию она = 1.
Полученное значение берется как TTL фейк пакетов.
Если оно выходит за пределы min-max, то оно нормализуется до min или до max. Если после нормализации превышена длина пути, алгоритм выдает отказ.
При отказе используется фиксированное значение ttl, заданное в параметре --dpi-desync-ttl.
Если у вас нет других ограничителей по fooling, лучше указать --dpi-desync-ttl=1, чтобы в случае отказа фейк пакет не дошел до сервера.
Можно настроить отдельную версию параметров для ipv6.
Смысл значений min-max означает диапазон длин пути, между которыми находится DPI. Нет смысла атаковать сервера слишком близкие, которые еще до DPI. Это обычно ресурсы самого провайдера. Так же нет смысла гнать фейки слишком далеко куда-то в США, потому что там тоже нет блокирующих DPI.
Значение дельты позволяет несколько сгладить небольшую разницу в длине исходящего и входящего пути. Но если сделать слишком большое значение, то можно вылезти в область DPI. Фейки перестанут доходить до DPI, и обход перестанет работать.
Блокчек прогоняет тесты на несколько вариантов delta. Это тот случай, когда тестирование надо выполнять на чем большем количестве заблокированых доменов, тем лучше. На разных доменах могут работать разные дельты. Если на большинстве доменов работает какая-то дельта, то ее и нужно использовать. Если везде все по разному, то от autottl стоит отказаться.
В tpws добавлена возможность указать OOB байт. В виде символа или 0xHEX.
Там же новые параметры --tamper-start и --tamper-cutoff позволяют ограничить байтовые позиции или номер блока исходящего потока, к которым применяется дурение. start<=pos<cutoff
cutoff - это точка отсечения, с которой больше не дурим.
Позиция относится к началу текущего принятого от клиента блока.
Обнаружилось, что некоторые провайдеские NAT datanoack проходит корректно. В этом случае внешний IP адрес может быть не обязателен.
megafon, beeline мобильные работают.
Но linux NAT оно не проходит. За домашним роутером это бесполезно, но можно с него.
autottl на BSD системах можно завести безкровно. В смысле, не надо перенаправлять весь входящий трафик с порта (ибо connbytes отсутствует).
Достаточно перенаправить 1 пакет SYN,ACK, и его легко фильтрануть правилом ipfw или PF.
autohostlist в dvtws по-прежнему не рекомендован на BSD, тк требует перенаправляения более одного входящего пакета на tcp соединение, и ограничить не представляется возможным.
Если ваш провайдер виснет на заблокированных ресурсах, то сработать может и без.
Вариант “зависло” детектится на основе только исходящего трафика. Вариант RST или redirect детектиться не будут
tpws c autohostlist работает без ограничений
Сделана частичная поддержка blockcheck в OpenBSD и MacOS. Частичная в том смысле, что tpws не поддерживается в OpenBSD, а в MacOS не поддерживается dvtws.
Увы, я до сих пор не понимаю как перенаправлять трафик в OpenBSD на tpws с локальной системы (не проходной)
Если брать инструкцию с route-to от TOR, то она работает, но невозможно узнать оригинальный адрес назначения у сокета через DIOCNATLOOK, так что этот варик редиректа бесполезен
В MacOS это работает без проблем.
Перевел тест tpws в blockcheck на использование socks, выкинув всю муть с перенаправлением трафика через фаервол.
Раньше от этого отказывался, потому что невозможно управлять версией ip (ipv4/ipv6), когда CURL работает через прокси.
Пришлось вынести ресолвер отдельно. mdig ресолвит домен, далее курлу подсовывается ключ --connect-to. Он доступен с версии 7.49, следовательно совсем уж древние курлы старее мая 2016 отваливаются , равно как и старые дистрибутивы ОС в варианте “из коробки”. Если у вас такой древнющий курл, можно собрать самому или взять готовый статический бинарик.
В openwrt с LEDE 17 версия curl достаточно новая.
В итоге tpws теперь можно тестировать в openbsd и pfsense, а код скрипта упростился
В blockcheck добавлена проверка на обход QUIC. Для нее требуется curl с поддержкой опции --http3-only.
Сейчас пока это диковинка, родной curl скорее всего не умеет
Тут есть статики для разных платформ : Releases · stunnel/static-curl · GitHub
Десинхронизация udp на nftables тоже переведена на POSTNAT схему вместе с TCP.
Этот вариант позволяет задействовать любые атаки, в том числе ломающие NAT, однако при включенном masquerade для проходного трафика может использоваться только через nftables.
Например, вариант ipfrag2 работает на многих сайтах для обхода блокировки QUIC.
Сеть очень плохо относится к фрагментации tcp на уровне IP. Это ненормальная ситуация, поэтому как правило такое режется.
Но к фрагментации udp сеть относится относительно лояльно. Есть ситуации, когда это вообще нормально.
IP фрагментация используется в IKE. В IKE уже изобрели свой метод фрагментации сообщений на уровне L7, но старые ОС об этом не знают. windows 7 отсылает фрагментированные udp, windows 10 - несколько нефрагментированных udp. Именно поэтому на некоторых VPS вам упорно не удастся подключиться к вашему strongwan с win7, и все лишь потому, что у вас слишком упертый хостер, который решил подрезать фрагментированные пакеты полностью.
Фрагментация QUIC по сути тоже ненормальна, но мало кто будет лезть так глубоко и анализировать udp payload (который еще надо суметь собрать).
cloudflare и bbc.com обходятся через ipfrag2, на facebook режут.
Новый метод десинхронизации нулевой фазы SYNDATA.
Термин нулевой фазы относится к десинхронизации на этапе TCP 3 way handshake.
К ней неприменимы фильтры на основе hostlist.
Этот тот случай, когда в --dpi-desync может быть 3 параметра через запятую.
Можно так : --dpi-desync=syndata,fake,split2
Суть в добавлении данных в пакет SYN. ОС принимают такие SYN пакеты, но данные игнорируют, а некоторые DPI их принимают. Кое-где работает на наших ТСПУ, но только для http.
На https может работать, если в параметре --dpi-desync-fake-syndata передать файл, содержащий TLS client hello с незаблокированным доменом. Фактически это аналог fake, поскольку расчет на то, что DPI принимает этот пейлоад как часть tcp stream, а сервер - нет.
Некоторые российские ТСПУ/DPI на http впадают в проблемы с синхронизацией sequence numbers, что приводит только к зависанию соединения.
Ломает некоторые сайты, видимо из-за собственных систем antiddos, которые плохо реагируют на аномалии
Поскольку ограничить хостлистом или аутохостлистом невозможно, применять с осторожностью
Главная цель этого режима десинхронизации - не атака на веб сайты, а атака на произвольные протоколы на конкретном сервере без применения техники split.
Сейчас наблюдается такая тема на ТСПУ. Если какой-то VPN сервис или другой сервис начинает применять техники обхода блокировок, связанные с сегментацией, то ТСПУ их обнаруживает и сразу блокирует соединение. Делается это обычно на ограниченных диапазонах IP.
В условиях жестких блокировок и противодействия техникам их обхода, ценна может быть каждая дырочка на свой сервер.
На udp это может быть ipfrag2, а на tcp - syndata.
Оказывается, старый добрый фейк на http и https может не работать в оригинальном виде.
Когда ты лезешь на http и шлешь фейк http iana.org, это может не сработать. Но если послать ерунду типа нулей, то может сработать. На syndata может быть наоборот. Ерунда не работает на https, а tls fake от iana.org - работает.
В связи с этим обновлен blockcheck на предмет поиска новых заковыристых стратегий
Еще немного по поводу SYNDATA.
На самом деле не запрещено по стандарту слать данные прямо в SYN. Поэтому такие пакеты без проблем проходят NAT и могут учитываться DPI.
Оригинальный стандарт запрещает передавать данные из SYN в сокет до полного прохождения tcp handshake. Но фактически по крайней мере linux, freebsd и windows данные в SYN игнорируют. При этом все последующие пакеты идут с сиквенсами, как будто бы SYN был пустой. То есть данные в SYN просто отбрасываются на стандартных сокетах.
Но есть еще более новый стандарт TCP fast open. В нем как раз отсылка данных в процессе хэндшейка - это нормально. Однако, для задействования функционала требуется особое программирование специально для поддержки fast open. Это должен уметь и серверный процесс, и клиентский.
Хотя некоторые веб сервера и умеют, и даже некоторые броузеры на некоторых платформах умеют, мало кто сейчас озабочен этим fast open. У меня нет статистики где и на каких ОС и на скольких сайтах он включен по умолчанию. Но как я понимаю немного где. Это уже устаревшая технология. Сейчас актуален QUIC. Он решает в том числе и проблему RTT.
Но если вдруг SYNDATA будет использован именно на fast open соединении, несомненно оно сломается. Поэтому соединения с признаками fast open не трогаются.
Сделал автоматическое перечитывание autohostlist другими процессами nfqws/tpws при модификации файла.
Выдал, допустим, блокчек 4 разных стратегии для http/https/ipv4/ipv6.
Юзер тупо вписал это в конфиг. Запущено 4 процесса.
Дернул https ipv4. Отлично, занеслось в аутолист.
Потом не работает. Почему ? Да потому что полезло по ipv6, а там не обновилось.
Реализован режим quick в blockcheck.
Его цель - найти хоть что-то работающее максимально быстро.
Изначально blockcheck создавался не как делатель волшебных пиллюль для копипасты в определенное место как на картинке. Это инструмент исследования DPI на предмет техник обхода блокировок.
Но юзера некоторые ниче не понимают, они все равно копипастят, и это их единственный шанс, чтобы оно заработало. Иначе им только отказываться от продукта, потому что не могут понять что там за буковки и что с ними делать.
В том числе для них может пригодиться этот режим, потому что все равно лишние буковки для них бесполезны.
Суть его в чем
- Отказ от тестов tpws. Все равно он как правило не обеспечивает должный уровень обхода. Чтобы вернуть используйте переменную SKIP_TPWS=0
- Поиск идет до первой рабочей стратегии
- При нескольких попытках любой фейл приводит к концу серии попыток. Ведь все равно будет итоговый фейл
По умолчанию все равно оставляю standard, чтобы основная цель скрипта оставалась неизменной
Из blockcheck убраны тесты ipfrag tcp, поскольку современная сеть практически не оставляет никаких шансов этому варианту.
Немного наблюдений по поводу протокола QUIC.
Если кратко, то на DPI он обрабатывается криво. Алгоритмы несовершенны.
Поведение DPI может зависеть от типа клиентской библиотеки.
quiche может пробивать блокировку и без средств обхода.
Пакеты initial от разных библиотек могут не собираться DPI, и он может не извлекать host.
curl с nghttp3 может долго (1-3 сек) выполнять запрос с пробивкой по fake. Там то ли теряются, то ли искажаются пакеты от сервера, вынуждая клиент еще раз слать initial.
При этом firefox может сразу и быстро открывать этот же сайт по quic, если количество пробивочных пакетов 5 и выше, и подвисать на QUIC, если меньше.
Аналогично у них реализуется и блокировка wireguard udp и openvpn udp. Для пробивки нужно слать 5 фейков.
DPI по-прежнему не может корректно сечь разбросанный на несколько пакетов initial. В хромах уже начали включать кибер по умолчанию, так что 50/50. Рандомизирует сигнатуру. То в первый пакет SNI попадет, то во 2-й
Вообщем, сложная эта штука QUIC, и curl test может не отражать реальной специфики как поведет себя броузер