zapret2/docs/manual.md

МАНУАЛ В ПРОЦЕССЕ НАПИСАНИЯ

Введение

zapret2 является пакетным манипулятором, основная задача которого - совершение различных автономных атак на DPI в реальном времени с целью преодоления ограничений (блокировок) ресурсов или сетевых протоколов. Однако, этим возможности zapret2 не ограничиваются. Архитектура позволяет выполнять и другие виды пакетных манипуляций. Например, двусторонняя (клиент+сервер) обфускация протоколов с целью их сокрытия от DPI. Возможны и иные применения.

Структура проекта

Главный компонент zapret2 - программа nfqws2 (dvtws2 на BSD, winws2 на Windows), написанная на C, которая и является пакетным манипулятором. Содержит функции по перехвату пакетов, базовой фильтрации, рапознавания основных протоколов и пейлоадов, поддержки хост и IP листов, автоматических хостлистов с распознаванием блокировок, систему множественных профилей (стратегий), возможности по отсылке raw пакетов и другие сервисные функции. Однако, там нет никаких возможностей собственно для воздействия на трафик. Это вынесено в код на языке LUA, вызываемый из nfqws2.

Поэтому следующая по важности часть проекта - LUA код. В базовый комплект входит библиотека функций-хелперов zapret-lib.lua, библиотека программ автономных атак на DPI zapret-antidpi.lua, библиотека функций принятия динамических решений (оркестрации) zapret-auto.lua. Дополнительно присутствует набор тестов C функций zapret-tests.lua, средство обфускации wireguard протокола zapret-wgobfs.lua и средство записи дампа пакетов в cap файлы zapret-pcap.lua.

Функции перенаправления трафика из ядра в Linux возложены на iptables и nftables, в FreeBSD - на ipfw, в OpenBSD - на pf, в Windows - встроены в сам процесс winws2 посредством драйвера windivert. Схема перехвата трафика из ядра , nfqws2 и lua код составляют минимально рабочее ядро проекта. Все остальное является дополнительным, второстепенным и опциональным.

Из второстепенных компонент - скрипты запуска под Linux - init.d, common, ipset, install_easy.sh, uninstall_easy.sh и средство автоматизации тестирования стратегий blockcheck2. Цель скриптов запуска - согласовать процесс поднятия таблиц и запуск инстансов nfqws2, учесть особенности интеграции в различные дистрибутивы (openwrt, systemd, openrc). Дополнительная функция - обеспечить поддержку и согласованное обновление различных листов и загрузку IP листов в пространство ядра - ipset. Все это можно сделать при желании и собственными средствами, если так удобнее или функционал скриптов запуска не подходит. Скрипты запуска выносят все настройки в файл config, лежащий в корне проекта. Этот конфиг относится только к ним, nfqws2 ничего о нем не знает.

Для обработки листов предусмотрены 2 программы, написанные на C. mdig - многопоточный ресолвер хостлистов неограниченного обьема. ip2net - программа для группировки отдельных IP адресов в подсети с целью сокращения их обьема. Эти программы испльзуются в скриптах запуска и в blockcheck2.

Скрипты запуска и инсталятор поддерживает установку на любые классические дистрибутивы Linux с systemd или openrc , из прошивок - на openwrt. Если система не удовлетворяет указанным требованиям - возможна самостоятельная "доприкрутка" к системе.

MacOS не поддерживается по причине отсутствия подходящего средства перехвата и управления пакетами. Стандартное для BSD средство ipdivert было убрано из ядра производителем.

Схема обработки трафика

Сети работают с IP пакетами. Поэтому единицей обработки являются именно они. Приемом и отправкой пакетов занимается сетевая подсистема в ядре ОС. nfqws2 работает не в ядре (kernel mode), а является процессом пространства пользователя (user mode). Поэтому первая часть процесса обработки состоит в передаче пакетов из ядра ОС в процесс nfqws2. Все 4 средства перехвата обладают некоторыми возможностями фильтрации пакетов. Максимальные возможности - в Linux. Чем больше на этом этапе будет отсечено ненужного трафика, тем меньше будет нагрузка на процессор, поскольку передача пакетов из ядра в user mode и обратно сопряжена со значительными накладными расходами.

Пакет пришел в nfqws2. Первое, что он делает, это разбирает его по уровням OSI модели - выделяет ip , ipv6, tcp, udp заголовки и поле данных. Это называется диссекцией. Результатом диссекции является диссект - представление пакета в виде структур, которые можно адресовать по полям.

Далее задействуется встроенная в nfqws2 подсистема conntrack - система отслеживания потоков поверх отдельно взятых пакетов. Ищется уже имеющаяся запись о соединении на основании данных L3/L4 пакета. Если ее нет - создается. Старые записи, по которым давно нет активности, удаляются. conntrack отслеживает логическое направление пакетов в потоке (входящее/исходящее), ведет подсчет количество прошедших пакетов и байт в обе стороны, следит за sequence numbers для tcp. Он же используется в случае необходимости для сборки сообщений, передаваемых несколькими пакетами.

Сигнатурно определяется тип пейлоада - содержимого отдельно взятого пакета или группы пакетов. На основании типа пейлоада определяется тип протокола всего потока, который сохраняется за потоком до конца его существования. В рамках одного соединения могут проходить разные типы пейлоадов. Например, протокол потока xmpp обычно несет несколько видов специфических для xmpp сообщений и сообщения, связанные с tls. Тип протокола потока xmpp остается, но последующие пакеты получают различные типы пейлоада - как известные, так и неизвестные. Неизвестные пейлоады определяются как тип "unknown".

Если для конкретного пейлоада и типа протокола потока выясняется необходимость реконструкции сообщения из нескольких пакетов, nfqws2 начинает их накапливать в связи с записью в conntrack и запрещает их немедленную отправку. После приема всех пакетов сообщения происходит реконструкция и при необходимости дешифровка составного пейлоада. Дальнейшие решения принимаются уже на базе полностью собранного пейлоада - reasm или результата сборки и дешифровки - decrypt.

Когда необходимая информация о пейлоаде получена, наступает очередь системы классификации по профилям. Профили содержат систему фильтров и команды действия внутри профиля. Профили фильтруются по L3 - версия IP протокола, ipset-ы - списки IP адресов, L4 - порты tcp или udp, L6/L7 - тип протокола потока, списки доменов (хостлисты). Профили сканируются строго в порядке от первого к последнему. При первом совпадении условий фильтра профиля выбирается этот профиль, а сканирование прекращается. Если ни одно из условий не выполнено, выбирается профиль по умолчанию, в котором нет никаких действий.

Все дальнейшие действия выполняются уже в рамках выбранного профиля. Выбранный профиль кэшируется в записи conntrack, поэтому для каждого пакета поиск заново не выполняется. Повторный поиск выполняется в случае изменения исходных данных - при обнаружении L7 протокола и при обнаружении имени хоста. В последних случаях производится повторный поиск и при необходимости переключение профиля. Таких переключений может быть за соединение до двух, поскольку есть лишь 2 изменяемых параметра.

Профиль выбран. Из чего состоит его содержание, отвечающее за действия ? За действия отвечают LUA функции. В профиле их может быть произвольное количество. Каждый вызов LUA функции из профиля называется инстансом. Функция может быть одна, вызовов несколько - с разными параметрами. Поэтому и применяется понятие инстанса - экземпляра вызываемой функции, который идентифицируется номером профиля и порядковым номером вызова внутри профиля. Инстансы вызываются через параметры --lua-desync. Каждый инстанс получает набор произвольных параметров, задаваемых в --lua-desync. Порядок вызовов имеет принципиальное значение для логики стратегии и выполняется строго в порядке задания параметров --lua-desync.

Присутствуют и внутипрофильные фильтры. Их 3 типа - фильтр --payload - список принимаемых инстансом пейлоадов, и 2 диапазонных фильтра --in-range и --out-range, позволяющих задать диапазон позиций внутри потока, который интересен для инстанса. Внутрипрофильные фильтры после их определения действуют на все последующие инстансы до их переопределения. Главный смысл наличия внутрипрофильных фильтров - сократить число относительно медленных вызовов LUA , принимая максимум решений на стороне C кода.

Пакет пришел в LUA инстанс. Функция имеет 2 параметра - ctx и desync. ctx - это контекст для связи с некоторыми функциями на стороне C кода. desync - таблица, содержащая множество параметров обрабатываемого пакета. Прежде всего это диссект - подтаблица dis. Информация из записи conntrack - подтаблица track. Еще целый ряд параметров, который можно увидеть, выполнив var_debug(desync) или просто вызвав готовый инстанс pktdebug.

Если идет перепроигрывание задержанных пакетов (replay), LUA инстанс получает информацию о номере части, количестве частей исходного сообщения, позиции текущей части, reasm или decrypt при наличии.

LUA код может использовать глобальное пространство переменных для хранения данных, не относящихся к конкретному обрабатываемому пакету. Ему доступна таблица desync.track.lua_state, в которой он может хранить любую информацию, связанную с записью conntrack. При каждом новом пакете потока в LUA выдается одна и та же таблица. Таблицу desync можно использовать для генерации и хранения временных данных, актуальных в цепочке обработки текущего пакета. Следующие LUA инстансы получают ту же таблицу desync и тем самым могут принимать данные от предыдущих инстансов.

LUA инстанс может создавать копии текущего диссекта, вносить в них изменения, генерировать собственные диссекты, отправлять их через вызовы C кода. Итогом работы каждого инстанса является вердикт - VERDICT_PASS - не делать ничего с текущим диссектом, VERDICT_MODIFY - в конце всей цепочки отослать модифицированное содержимое диссекта, VERDICT_DROP - дропнуть текущий диссект. Вердикты всех инстансов аггрегируются - MODIFY замещает PASS, а DROP замещает и PASS, и MODIFY.

LUA инстанс может сам себя отключить от получения дальнейших пакетов потока по направлению in/out - это назвается instance cutoff. Может отключить направление in/out текущего потока от всей LUA обработки - lua cutoff. Может запросить отмену всей дальнейшей цепочки вызовов LUA инстансов по текущему диссекту. Инстанс, принимающий такое решение, берет на себя функцию координации дальнейших действий. Такой инстанс называется оркестратором. Он получает от C кода план дальнейшего выполнения со всеми фильтрами профиля и параметрами вызова всех оставшихся инстансов и сам принимает решения когда и при каких условиях их вызывать или не вызывать, менять их параметры. Так реализуются динамические сценарии без модификации основных составлящих кода стратегии. Например, определение блокировки ресурса и смена стратегии, если предыдущая не сработала.

Если все инстансы текущего профиля вошли в состояние cutoff по текущему потоку, либо текущая позиция потока находится за верхней границей range фильтров, значит по этому потоку больше не будет LUA вызовов. C код помечает такие потоки специальным признаком "lua cutoff", который проверяется максимально быстро без вызовов кода LUA. Тем самым экономятся ресурсы процессора.

После выполнения всей цепочки инстансов профиля C код получает итоговый вердикт - что делать с текущим диссектом. Отправить как есть, отправить модифицированный вариант или дропнуть.

В конце nfqws2 переходит к ожиданию следующего пакета, и цикл повторяется вновь.

Перехват трафика из ядра ОС

Перехват трафика в ядре Linux

Осуществляется при помощи iptables или nftables с использованием механизма очередей NFQUEUE. nftables - предпочтительны, потому что позволяют работать с трафиком после NAT, а iptables - нет. Это важно при обработке проходящего (forwarded) трафика. На iptables перехват после NAT невозможен, поэтому некоторые воздействия, ломающие NAT, на iptables на проходящем трафике нереализуемы. У nftables есть один важный недостаток - чрезмерное требование к памяти при загрузке больших set-ов. Например, чтобы загрузить 100K IP адресов, требуется от 256-320 Mb, что для роутеров часто оказывается за пределом возможностей. ipset от iptables такое может провернуть даже на 64 Mb RAM.

Приведенные далее тестовые примеры предназначены для своей системы запуска или запуска вручную. Скрипты запуска zapret сами генерируют необходимые правила, никаких ip/nf tables самому писать не нужно.

Перехват трафика с помощью nftables

Тестовая таблица для POSTNAT схемы. Обеспечивает перехват первых входящих и исходящих пакетов по потоку после NAT, если таковой присутствует. Из-за NAT IP адреса клиентов теряются, замещаясь IP wan интерфейса. Количество первых пакетов регулируется согласно вашей стратегии. Лишний перехват - дополнительная нагрузка на CPU. Перехват RST и FIN желателен для максимально корректной работы conntrack.

Фильтр по mark необходим для предотвращения кольца. Без этого возможны зависания и неправильная работа.

notrack нужен, чтобы NAT не ломал техники, которые не совместимы с NAT. Генерируемые nfqws2 пакеты не должны проходить проверки на валидность с точки зрения NAT и дропаться стандартными правилами таблиц. Подстановка IP адресов NAT не требуется, поскольку попадающий на nfqws2 пакет уже прошел NAT и имеет корректные адрес и порт источника для wan.

IFACE_WAN=wan
MAX_PKT_IN=15
MAX_PKT_OUT=15
FWMARK=0x40000000
PORTS_TCP=80,443
PORTS_UDP=443
QNUM=200

nft create table inet ztest

nft add chain inet ztest postnat "{type filter hook postrouting priority srcnat+1;}"
nft add rule inet ztest postnat oifname $IFACE_WAN meta mark and $FWMARK == 0 udp dport "{$PORTS_UDP}" ct original packets 1-$MAX_PKT_OUT queue num $QNUM bypass
nft add rule inet ztest postnat oifname $IFACE_WAN meta mark and $FWMARK == 0 tcp dport "{$PORTS_TCP}" ct original packets 1-$MAX_PKT_OUT queue num $QNUM bypass
nft add rule inet ztest postnat oifname $IFACE_WAN meta mark and $FWMARK == 0 tcp dport "{$PORTS_TCP}" tcp flags fin,rst queue num $QNUM bypass

nft add chain inet ztest pre "{type filter hook prerouting priority filter;}"
nft add rule inet ztest pre iifname $IFACE_WAN udp sport "{$PORTS_UDP}" ct reply packets 1-$MAX_PKT_IN queue num $QNUM bypass
nft add rule inet ztest pre iifname $IFACE_WAN tcp sport "{$PORTS_TCP}" ct reply packets 1-$MAX_PKT_IN queue num $QNUM bypass
nft add rule inet ztest pre iifname $IFACE_WAN tcp sport "{$PORTS_TCP}" "tcp flags & (syn | ack) == (syn | ack)" queue num $QNUM bypass
nft add rule inet ztest pre iifname $IFACE_WAN tcp sport "{$PORTS_TCP}" tcp flags fin,rst queue num $QNUM bypass

nft add chain inet ztest predefrag "{type filter hook output priority -401;}"
nft add rule inet ztest predefrag "mark & $FWMARK != 0x00000000 notrack"

Удаление тестовой таблицы :

nft delete table inet ztest

Перехват трафика с помощью iptables

Caution

Начиная с ядер Linux 6.17 присутствует параметр конфигурации ядра CONFIG_NETFILTER_XTABLES_LEGACY, который по умолчанию в дистрибутиве может быть "not set". Отсутствие этой настройки выключает iptables-legacy. Это часть процесса депрекации iptables. Тем не менее iptables-nft будут работать, поскольку используют backend nftables.

Тестовые правила для PRENAT схемы. Обеспечивают перехват первых входящих и исходящих пакетов по потоку до NAT, если таковой присутствует. Адреса и порты источника внутренней сети сохраняются. Атаки на проходящий трафик, ломающие NAT, невозможны, но возможны с самой системы.

IFACE_WAN=wan
MAX_PKT_IN=15
MAX_PKT_OUT=15
FWMARK=0x40000000
PORTS_TCP=80,443
PORTS_UDP=443
QNUM=200

JNFQ="-j NFQUEUE --queue-num $QNUM --queue-bypass"
CHECKMARK="-m mark ! --mark $FWMARK/$FWMARK"
CB_ORIG="-m connbytes --connbytes-dir=original --connbytes-mode=packets"
CB_REPLY="-m connbytes --connbytes-dir=reply --connbytes-mode=packets"
for tables in iptables ip6tables; do
	$tables -t mangle -N ztest_post 2>/dev/null
	$tables -t mangle -F ztest_post
	$tables -t mangle -C POSTROUTING -j ztest_post 2>/dev/null || $tables -t mangle -A POSTROUTING -j ztest_post
	$tables -t mangle -N ztest_pre 2>/dev/null
	$tables -t mangle -F ztest_pre
	$tables -t mangle -C PREROUTING -j ztest_pre 2>/dev/null || $tables -t mangle -A PREROUTING -j ztest_pre
	$tables -t mangle -I ztest_post -o $IFACE_WAN $CHECKMARK -p udp -m multiport --dports $PORTS_UDP $CB_ORIG --connbytes 1:$MAX_PKT_OUT $JNFQ
	$tables -t mangle -I ztest_post -o $IFACE_WAN $CHECKMARK -p tcp -m multiport --dports $PORTS_TCP $CB_ORIG --connbytes 1:$MAX_PKT_OUT $JNFQ
	$tables -t mangle -I ztest_post -o $IFACE_WAN $CHECKMARK -p tcp -m multiport --dports $PORTS_TCP --tcp-flags fin fin $JNFQ
	$tables -t mangle -I ztest_post -o $IFACE_WAN $CHECKMARK -p tcp -m multiport --dports $PORTS_TCP --tcp-flags rst rst $JNFQ
	$tables -t mangle -I ztest_pre -i $IFACE_WAN -p udp -m multiport --sports $PORTS_UDP $CB_REPLY --connbytes 1:$MAX_PKT_IN $JNFQ
	$tables -t mangle -I ztest_pre -i $IFACE_WAN -p tcp -m multiport --sports $PORTS_TCP $CB_REPLY --connbytes 1:$MAX_PKT_IN $JNFQ
	$tables -t mangle -I ztest_pre -i $IFACE_WAN -p tcp -m multiport --sports $PORTS_TCP --tcp-flags syn,ack syn,ack $JNFQ
	$tables -t mangle -I ztest_pre -i $IFACE_WAN -p tcp -m multiport --sports $PORTS_TCP --tcp-flags fin fin $JNFQ
	$tables -t mangle -I ztest_pre -i $IFACE_WAN -p tcp -m multiport --sports $PORTS_TCP --tcp-flags rst rst $JNFQ
done

Удаление тестовых правил zapret :

for tables in iptables ip6tables; do
	$tables -t mangle -D POSTROUTING -j ztest_post
	$tables -t mangle -D PREROUTING -j ztest_pre
	$tables -t mangle -F ztest_post
	$tables -t mangle -X ztest_post
	$tables -t mangle -F ztest_pre
	$tables -t mangle -X ztest_pre
done

Удаление всех правил из таблицы mangle, включая и иные правила :

iptables -F -t mangle
ip6tables -F -t mangle

Перехват трафика в ядре FreeBSD

Основная боль при перехвате трафика на системах, отличных от Linux, - невозможность перехватить первые пакеты потока. Можно перехватить только весь поток целиком по направлению. В BSD с этим дела хуже всего - нет даже возможностей фильтрации raw payload, то есть по содержимому пакета. Поэтому первый набор правил - это перехват всех исходящих по портам и перехват только SYN+ACK,FIN,RST для TCP, чтобы без нагрузки на процессор можно было задействовать режим autottl и максимально корректно работал conntrack. Однако, в таком варианте не будет работать ничего, что требует иного входящего трафика.

RULE=100
IFACE_WAN=vmx0
PORTS_TCP=80,443
PORTS_UDP=443
PORT_DIVERT=989

ipfw delete $RULE
ipfw add $RULE divert $PORT_DIVERT tcp from any to any $PORTS_TCP out not diverted xmit $IFACE_WAN
ipfw add $RULE divert $PORT_DIVERT udp from any to any $PORTS_UDP out not diverted xmit $IFACE_WAN
ipfw add $RULE divert $PORT_DIVERT tcp from any $PORTS_TCP to any tcpflags syn,ack in not diverted recv $IFACE_WAN
ipfw add $RULE divert $PORT_DIVERT tcp from any $PORTS_TCP to any tcpflags fin in not diverted recv $IFACE_WAN
ipfw add $RULE divert $PORT_DIVERT tcp from any $PORTS_TCP to any tcpflags rst in not diverted recv $IFACE_WAN

Вариант с перехватом потока в обе стороны. Особо сильно загружает процессор. Все скачиваемые гигабайты пойдут через dvtws2. Из них обычно нужно всего 1-2 пакета, все остальное - впустую расходует CPU, но средства ipfw не предоставляют иных возможностей.

RULE=100
IFACE_WAN=vmx0
PORTS_TCP=80,443
PORTS_UDP=443
PORT_DIVERT=989

ipfw delete $RULE
ipfw add $RULE divert $PORT_DIVERT tcp from any to any $PORTS_TCP out not diverted xmit $IFACE_WAN
ipfw add $RULE divert $PORT_DIVERT udp from any to any $PORTS_UDP out not diverted xmit $IFACE_WAN
ipfw add $RULE divert $PORT_DIVERT tcp from any $PORTS_TCP to any in not diverted recv $IFACE_WAN
ipfw add $RULE divert $PORT_DIVERT udp from any $PORTS_UDP to any in not diverted recv $IFACE_WAN

Теоретически возможен перехват через pf divert-to, но на практике механизм предотвращения зацикливания сломан, поэтому использовать pf нереально. На pfsense и opnsense требуются дополнительные меры для задействования pf и ipfw одновременно. Часто с этим бывают проблемы, конфликты и глюки.

Перехват трафика в ядре OpenBSD

В OpenBSD есть только pf. С механизмом предотвращения зацикливания divert все в порядке.

Первый вариант - перехват всех исходящих по портам и перехват только SYN+ACK,FIN,RST для TCP, чтобы без нагрузки на процессор можно было задействовать режим autottl и максимально корректно работал conntrack. Однако, в таком варианте не будет работать ничего, что требует иного входящего трафика.

pf требует файлов с правилами. Вы пишите pf файл (обычно используется /etc/pf.conf), потом его применяете через pfctl -f /etc/pf.conf. pfctl -e включает pf, pfctl -d - выключает. Возможно использование якорей (anchors) с отдельными файлами правил, читайте документацию по pf.

Трюки с no state нужны, чтобы предотвратить автоматический перехват и входящих пакетов по потоку.

IFACE_WAN = "em0"
PORTS_TCP = "80,443"
PORTS_UDP = "443"
PORT_DIVERT = "989"

pass in quick on $IFACE_WAN proto tcp from port { $PORTS_TCP } flags SA/SA divert-packet port $PORT_DIVERT no state
pass in quick on $IFACE_WAN proto tcp from port { $PORTS_TCP } flags R/R divert-packet port $PORT_DIVERT no state
pass in quick on $IFACE_WAN proto tcp from port { $PORTS_TCP } flags F/F divert-packet port $PORT_DIVERT no state
pass in quick on $IFACE_WAN proto tcp from port { $PORTS_TCP } no state
pass out quick on $IFACE_WAN proto tcp to port { $PORTS_TCP } divert-packet port $PORT_DIVERT no state
pass out quick on $IFACE_WAN proto udp to port { $PORTS_UDP } divert-packet port $PORT_DIVERT no state

Вариант с перехватом потока в обе стороны. Особо сильно загружает процессор. Все скачиваемые гигабайты пойдут через dvtws2. Из них обычно нужно всего 1-2 пакета, все остальное - впустую расходует CPU, но средства pf не предоставляют иных возможностей.

Перехват входящих по тем же портам обеспечивается автоматически за счет state.

IFACE_WAN = "em0"
PORTS_TCP = "80,443"
PORTS_UDP = "443"
PORT_DIVERT = "989"

pass out quick on $IFACE_WAN proto tcp to port { $PORTS_TCP } divert-packet port $PORT_DIVERT
pass out quick on $IFACE_WAN proto udp to port { $PORTS_UDP } divert-packet port $PORT_DIVERT

Caution

В FreeBSD другая версия pf и немного другой синтаксис. Однако, фактически pf в FreeBSD сломан, поскольку не работает предотвращение зацикливания. В MacOS хотя и используется pf, ipdivert из ядра убран, правила работать не будут.

Перехват трафика в ядре Windows

В Windows нет встроенных средств для перехвата трафика. Используется стороннее решение - драйвер windivert. Управление интегрируется в сам процесс winws2.

windivert принимает текстовые фильтры, похожие на фильтры wireshark и tcpdump. В них есть возможности фильтрации по ip (без ipset), портам и raw пейлоадам. Нет побитовых логических операций и сдвигов. Нет отслеживания потоков и ограничения по первым пакетам.

Драйвер windivert больше не разрабатывается, однако имеются подписанные варианты драйвера, совместимые со всеми современными windows, но только для архитектуры x86_64. На arm64 есть неподписанный драйвер, требующий тестового режима подписи драйверов. При использовании winws2 на Windows 11 arm64 приходится пользоваться x86_64 версией, поскольку winws2 написан под cygwin, а его нет для arm. Драйвер .sys при этом заменяется на неподписанную arm64 версию. Запуск на Windows 10 arm64 теоретически возможен, но только с 32-битной версией winws2 x86, поскольку эмуляция x64 в Windows 10 не предусмотрена.

windivert является частой целью для нападок антивирусов. Это хакерский инструмент, но вирусом он не является. Правильнее воспринимать его как замену iptables для windows. Иногда случаются конфликты со сторонним ПО, использующим драйвера режима ядра - прежде всего антивирусы и фаерволы, вплоть до синих экранов. Практически исправить это нереально хотя бы из-за подписи драйверов, которую получить простому смертному без стоящих за ним корпораций очень непросто и накладно.

windivert не может обеспечить корректного перехвата проходящего трафика при раздаче сети средствами windows и как следствие использовании NAT, поэтому возможности работы по проходящему трафику не реализованы. Единственный доступный вариант - установить proxy server.

winws2 может принимать полные raw фильтры - вы пишите фильтр сами и указываете его в параметре --wf-raw=<filter> или --wf-raw=@<filter_file>. Но это обычно не очень удобно, поэтому существует встроенный конструктор фильтров.

--wf-tcp-out, --wf-tcp-in, --wf-udp-out, --wf-udp-in берут список портов (80,443) или диапазонов портов (80,443,500-1000) и включают полный перехват портов по указанному направлению.

--wf-raw-part принимает частичные windivert фильтры. Синтаксис аналогичен --wf-raw. --wf-raw-part может быть несколько. Частичные фильтры встраиваются конструктором в итоговый фильтр по принципу OR. Или указанные порты, или ваш фильтр1 или ваш фильтр2.

--wf-save=<filter_file> записывает созданный конструктором фильтр в файл для последующего анализа и модификации.

Конструктор фильтров автоматически перехватывает входящие tcp с флагами SYN+ACK,FIN,RST. Писать специально правила не нужно.

--wf-filter-lan (по умолчанию включен) отфильтровывает пакеты на не глобальные IP адреса, такие как 192.168.0.0/16.

--wf-tcp-empty (по умолчанию выключен) включает перехват пустых tcp пакетов без флагов SYN,FIN,RST. Если параметр не включен, перехват пустых ACK пакетов не производится, что позволяет существенно сэкономить на процессоре. Но для некоторых стратегий эти пакеты могут понадобиться. Только вы можете знать нужны они вам или нет.

Если есть перехват любого tcp порта, автоматически включается перехват всех http редиректов, чтобы работал autohostlist. Перехват http redirect работает по payload сигнатуре, то есть проверяются байты в определенных позициях содержимого пакета.

Предпочтительно по udp протоколам, особенно по тем, где порт не определен, использовать свои --wf-raw-part фильтры, чтобы сэкономить на процессоре. Для tcp тоже возможны фильтры, но надо учитывать потребности conntrack. Он нуждается как минимум в SYN пакете, а желательно еще и FIN, RST. Если нужна фильтрация по сообщениям , занимающим более одного tcp сегмента, такое отфильтровать средствами windivert невозможно - требуется полный перехват порта по направлению.

nfqws2

Общие принципы задания параметров

Все параметры nfqws2 передаются в командной строке, либо загружаются из файла в том же самом формате. nfqws2 использует стандартный парсер getopt_long_only. Опции имеют формат --name[=value]. Некоторые опции не требуют параметров, другие требуют, а третьи могут их брать опционально. Парсер getopt позволяет задавать значение через знак = или через пробел. Лишние значения через пробел могут игнорироваться, поэтому казалось бы ошибочные параметры могут не вызвать ошибку. Лучше всегда писать значения через знак =.

Чтение параметров из файла реализовано через задание единственной опции @config_file. Все остальные параметры командной строки будут проигнорированы. Опции будут прочитаны из файла, как будто бы вы ввели его содержимое в командой строке. Возможность не поддерживается в Android и OpenBSD версиях.

Полный список опций

Общие параметры для всех версий - nfqws2, dvtws2, winws2.

 @<config_file>                                         ; чтение опций командной строки из файла. все остальные опции из командной строки игнорируются.

 --debug=0|1|syslog|android|@<filename>                 ; писать дебаг лог. 0 - нет , 1 - на консоль, syslog - в unix syslog, android - системный log android, @<filename> - в файл
 --version                                              ; вывести версию и выйти
 --dry-run                                              ; проверить валидность параметров командной строки и наличие файлов. не проверяет корректность скриптов LUA !
 --comment=any_text                                     ; любой текст. игнорируется
 --daemon                                               ; отключиться от консоли (демонизироваться)
 --pidfile=<filename>                                   ; запись PID в файл
 --ctrack-timeouts=S:E:F[:U]                            ; таймауты conntrack для стадий tcp SYN, ESTABLISHED, FIN и для udp
 --ctrack-disable=[0|1]                                 ; 1 отключает conntrack
 --server=[0|1]                                         ; серверный режим. для обслуживания listener-ов меняются многие аспекты выбора направления и ip/port источника/приемника
 --ipcache-lifetime=<int>                               ; время жизни записей кэша IP в секундах. 0 - без ограничений.
 --ipcache-hostname=[0|1]                               ; 1 или отсутствие аргумента включают кэширование имен хостов для применения в стратегиях нулевой фазы
 --reasm-disable=[proto[,proto]]                        ; отключить сборку фрагментов для списка пейлоадов : tls_client_hello quic_initial . без аргумента - отключить reasm для всего.

DESYNC ENGINE INIT:
 --writeable[=<dir_name>]                               ; создать директорию для LUA с разрешением записи и поместить путь к ней в переменную env "WRITEABLE" (только одна директория)
 --blob=<item_name>:[+ofs]@<filename>|0xHEX             ; загрузить бинарный файл или hex строку в переменную LUA <item_name>. +ofs задает смещение от начала файла
 --lua-init=@<filename>|<lua_text>                      ; однократно при старте выполнить LUA код из строки или из файла
 --lua-gc=<int>                                         ; интервал вызова сборщика мусора LUA в секундах. 0 отключает периодический вызов.

MULTI-STRATEGY:
 --new                                                  ; начало нового профиля
 --skip                                                 ; игнорировать профиль
 --name=<name>                                          ; установить имя профиля
 --template[=<name>]                                    ; использовать профиль как шаблон, задать имя
 --cookie[=<string>]                                    ; установить значение LUA переменной "desync.cookie", передаваемое каждому инстансу данного профиля
 --import=<name>                                        ; копировать настройки из шаблона в текущий профиль с полным замещением
 --filter-l3=ipv4|ipv6                                  ; фильтр профиля : версия ip протокола
 --filter-tcp=[~]port1[-port2]|*                        ; фильтр профиля : порты tcp или диапазоны портов через запятую
 --filter-udp=[~]port1[-port2]|*                        ; фильтр профиля : порты udp или диапазоны портов через запятую
 --filter-l7=proto[,proto]                              ; фильтр профиля : список протоколов потока. полный список доступен в help тексте программы.
 --ipset=<filename>                                     ; фильтр профиля : включающий список ip адресов или подсетей из файла. может быть смешанным ipv4+ipv6.
 --ipset-ip=<ip_list>                                   ; фильтр профиля : включающий фиксированный список ip адресов или подсетей через запятую
 --ipset-exclude=<filename>                             ; фильтр профиля : исключающий список ip адресов или подсетей из файла. может быть смешанным ipv4+ipv6.
 --ipset-exclude-ip=<ip_list>                           ; фильтр профиля : исключающий фиксированный список ip адресов или подсетей через запятую
 --hostlist=<filename>                                  ; фильтр профиля : включающий список доменов из файла
 --hostlist-domains=<domain_list>                       ; фильтр профиля : включающий фиксированный список доменов из файла
 --hostlist-exclude=<filename>                          ; фильтр профиля : исключающий список доменов из файла
 --hostlist-exclude-domains=<domain_list>               ; фильтр профиля : исключающий фиксированный список доменов из файла
 --hostlist-auto=<filename>                             ; фильтр профиля : автоматически пополняемый по обратной связи включающий фильтр доменов
 --hostlist-auto-fail-threshold=<int>                   ; параметр автолиста : количество неудач подряд для занесения в лист. по умолчанию 3
 --hostlist-auto-fail-time=<int>                        ; параметр автолиста : максимальное время между неудачами без сброса счетчика. по умолчанию 60 секунд
 --hostlist-auto-retrans-threshold=<int>                ; параметр автолиста : количество tcp ретрансмиссий в одном сеансе для фиксации неудачи. по умолчанию 3
 --hostlist-auto-retrans-maxseq=<int>                   ; параметр автолиста : исходящий relative sequence, после которого детект неудачи прекращается. по умолчанию 32768
 --hostlist-auto-incoming-maxseq=<int>                  ; параметр автолиста : входящий relative sequence, после которого детект неудачи прекращается, а счетчик сбрасывается. по умолчанию 4096
 --hostlist-auto-udp-out=<int>                          ; параметр автолиста : условие неудачи udp : количество исходящих пакетов больше или равно значению. по умолчанию 4
 --hostlist-auto-udp-in=<int>                           ; параметр автолиста : условие неудачи udp : количество входящих пакетов меньше или равно значению. по умолчанию 1
 --hostlist-auto-debug=<logfile>                        ; дебаг лог автолиста

LUA PACKET PASS MODE:
 --payload=type[,type]                                  ; внутрипрофильный фильтр : фильтр пейлоада для последующих инстансов внутри профиля. список пейлоадов доступен в help тексте программы.
 --out-range=[(n|a|d|s|p)<int>](-|<)[(n|a|d|s|p)<int>]  ; внутрипрофильный фильтр : диапазон счетчиков conntrack для последующих инстансов внутри профиля - исходящее направление
 --in-range=[(n|a|d|s|p)<int>](-|<)[(n|a|d|s|p)<int>]   ; внутрипрофильный фильтр : диапазон счетчиков conntrack для последующих инстансов внутри профиля - входящее направление

LUA DESYNC ACTION:
 --lua-desync=<functon>[:param1=val1[:param2=val2]]     ; при обработке профиля вызвать LUA инстанс с указанными параметрами, если соблюдены условия внутрипрофильных фильтров

Специфические параметры nfqws2 :

 --qnum=<nfqueue_number>                ; номер очереди NFQUEUE в Linux
 --user=<username>                      ; сменить uid/gid на те, что связаны с указанным именем пользователя
 --uid=uid[:gid1,gid2,...]              ; сменить uid/gid на указанные числовые значения
 --bind-fix4                            ; лечение проблемы ухода генерированных пакетов на Linux с неверного интерфейса при использовании PBR (ipv4)
 --bind-fix6                            ; аналогично для ipv6
 --fwmark=<int|0xHEX>                   ; бит в mark для предотвращения зацикливания. default = 0x40000000
 --filter-ssid=ssid1[,ssid2,ssid3,...]  ; фильтр профиля : имя wifi сети

Специфические параметры dvtws2 :

 --port=<port>                          ; номер divert порта
 --user=<username>                      ; сменить uid/gid на те, что связаны с указанным именем пользователя
 --uid=uid[:gid1,gid2,...]              ; сменить uid/gid на указанные числовые значения

Специфические параметры winws2 :

 --wf-iface=<int>[.<int>]               ; windivert конструктор : номер сетевого интерфейса
 --wf-l3=ipv4|ipv6                      ; windivert конструктор : версия ip
 --wf-tcp-in=[~]port1[-port2]           ; windivert конструктор : tcp порты или диапазоны портов для перехвата по входящему направлению. список через запятую
 --wf-udp-in=[~]port1[-port2]           ; windivert конструктор : udp порты или диапазоны портов для перехвата по входящему направлению. список через запятую
 --wf-tcp-in=[~]port1[-port2]           ; windivert конструктор : tcp порты или диапазоны портов для перехвата по исходящему направлению. список через запятую
 --wf-udp-in=[~]port1[-port2]           ; windivert конструктор : udp порты или диапазоны портов для перехвата по исходящему направлению. список через запятую
 --wf-tcp-empty=[~]port1[-port2]        ; windivert конструктор : перехватывать пустые tcp пакеты ACK. по умолчанию - нет.
 --wf-raw-part=<filter>|@<filename>     ; windivert конструктор : частичный windivert raw фильтр. обьединяется по принципу ИЛИ.
 --wf-filter-lan=0|1                    ; windivert конструктор : отфильтровывать неглобальные IP адреса. по умолчанию - да.
 --wf-raw=<filter>|@<filename>          ; полный windivert фильтр. замещает конструктор.
 --wf-save=<filename>                   ; сохранить полный итоговый windivert фильтр в файл
LOGICAL NETWORK FILTER:
 --ssid-filter=ssid1[,ssid2,ssid3,...]  ; список сетей wifi, при наличии подключения к которым перехват включается, а иначе не включается.
 --nlm-filter=net1[,net2,net3,...]      ; список сетей Network List Manager, при наличии подключения к которым перехват включается, а иначе не включается.
 --nlm-list[=all]                       ; вывести список подключенных NLM сетей. all - список всех NLM сетей

Использование множественных профилей

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

nfqws2 <глобальные_параметры>
<фильтр 1> <стратегия 1> --new
<фильтр 2> <стратегия 2> --new
...............
<фильтр N> <стратегия N>

Когда на вход поступает пакет, и для него еще нет записи в conntrack, происходит выбор профиля. Фильтры профиля проверяются от первого до последнего - с начала в конец - слева направо, и никак иначе. Всегда выигрывает только один профиль - по первому совпадению условий фильтра, а все остальные не задействуются. Если не сработал ни один фильтр, выбирается пустой профиль с номером 0, не предполагающий никаких действий с трафиком.

Все условия, кроме --filter-l7 и хостлистов, являются однозначными и известными с момента начала обработки потока (с начала соединения). В начале как правило еще неизвестнен протокол потока и имя хоста, выделяемое из сообщений потока. Когда эти величины становятся известны, происходит поиск профиля заново. Если выбирается другой профиль - происходит перескок. Таких перескоков может быть до двух, поскольку есть только 2 величины, влияющие на выбор, неизвестные с самого начала. Для протоколов потока tls, http, quic обычно бывает только 1 перескок, поскольку определение протокола и имени хоста происходит по одному пакету или группе пакетов. Для XMPP это 2 перескока - сначала определяется xmpp как таковой, затем ловится переход на TLS, и только в нем выделяется имя хоста. При написании стратегий следует их продумывать с учетом логики перескоков. Если нужно, чтобы стратегия начала работу с самого первого пакета и продолжила работать дальше после изменения профиля, нужно дублировать вызовы во всех профилях, по которым может пройти поток.

Шаблоны профилей

Когда имеется много сложных и повторяющихся стратегий, может быть удобно использовать шаблоны. Шаблон - это такой же профиль, только он не идет в работу, а попадает в отдельный список шаблонов. Шаблоном профиль становится через задание параметра --template=<name>. Далее он может быть импортирован (--import=<name>). Импорт предполагает копирование профиля полностью, а не только тех настроек, которые в нем были указаны - все остальные настройки имеют значения по умолчанию. Любые настройки текущего профиля стираются, включая и имя. Поэтому --import надо писать в начале, а потом добавлять уникальные для профиля параметры. Шаблоны могут импортировать и друг друга. Для шаблона обязательно уникальное имя, а при импорте имя копируется, поэтому обязательно надо задать уникальное имя через --name.

nfqws2 <глобальные_параметры>
--template=tpl1 <базовые параметры 1> --new
--template=tpl2 <базовые параметры 2> --new
--template --import tpl2 --name tpl3 <базовые параметры 3> --new
--import tpl1 --name prof1 <дополнительные параметры 1> --new
--import tpl3 --name prof2 <дополнительные параметры 2> --new
--name prof3 <параметры 3>

В примере имеется 3 рабочих профиля и 3 шаблона, 1 из которых импортирует настройки другого.

• Профиль prof1 получает обьединение <базовые параметры 1> и <дополнительные параметры 1>.
• Профиль prof2 получает обьединение <базовые параметры 2>, <базовые параметры 3> и <дополнительные параметры 2>
• Профиль prof3 получает <параметры 3>. Он не импортирует шаблоны.

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

Фильтрация по листам

Если имеются фильтры по хостлистам, и есть хотя бы один домен в любом хостлисте или указан автохостлист, то профиль никогда не будет выбран при отсутствующем имени хоста. Случай, когда нет автохостлиста, а все файлы листов пустые, приравнивается к отсутствию фильтра по хостлисту.

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

Если есть автохостлист, то при наличии имени хоста профиль выбирается всегда вне зависимости от его вхождения в какие-либо листы этого профиля. Действия зависят от вхождения в листы.

• Если хост входит в исключающие листы, не происходит никаких действий и не происходит попытки выяснить работает ли ресурс.
• Если хост не входит в исключающие листы, но входит во включающие - происходит применение стратегии без попыток выяснить работает ли ресурс с ней.
• Если хост не входит ни в исключающие листы, ни во включающие - стратегия не применяется, происходит обнаружение неудачи доступа к ресурсу. Если случилась неудача, увеличивается счетчик неудач. Если случается удача или превышается интервал времени между неудачами --hostlist-auto-fail-time - счетчик сбрасывается. Когда счетчик достигает --hostlist-auto-fail-threshold, происходит занесение хоста в автолист. При следующем запросе будет считаться, что хост входит во включающий лист.
• Файлы хостлистов и ipset-ов перечитываются автоматически при изменении - перезапуск nfqws2 не нужен.
• Сигнал SIGHUP помечает все листы для принудительной перечитки при обработки следующего пакета
• Каждая запись о домене, IP адресе или подсети идет на новой строке.
• Хостлисты и ipset-ы поддерживают комментарии. Пустые строки и строки, начинающиеся с #, игнорируются.
• В хостлистах поддомены учитываются автоматически. * не поддерживается. Если в начале идет символ ^, автоматический учет поддоменов отменяется для этого домена.
• ipset-ы могут включать адреса и подсети как ipv4, так и ipv6.
• В статическом варианте --ipset-ip и --hostlist-domains домены идут через запятую. В статическом хостлисте # и ^ так же поддерживаются.
• Для листов поддерживается сжатие gzip.

Детектор неудач автохостлистов

Детектор срабатывает только при наличии имени хоста. Неудачей считается :

• tcp : происходит не менее --hostlist-auto-retrans-threshold ретрансмиссий в пределах исходящего relative sequence --hostlist-auto-retrans-maxseq
• tcp : приходит RST в пределах входящего relative sequence от 1 до --hostlist-auto-incoming-maxseq
• tcp : принят пейлоад http_reply и http ответ является переадресацией 302 или 307 на абсолютный URL с доменом 2 уровня, не совпадающим с доменом 2 уровня хоста.
• udp : ушло не менее --hostlist-auto-udp-out пакетов, пришло не более --hostlist-auto-udp-in пакетов. Эта ситуация означает, что клиент шлет запросы, а сервер на них не отвечает или отвечает меньше, чем должен по протоколу.

Удачей считается :

• tcp : превышение исходящего relative sequence --hostlist-auto-retrans-maxseq . Клиент смог отослать достаточно много, что вряд ли бы случилось в случае реакции DPI.
• tcp : превышение входящего relative sequence --hostlist-auto-incoming-maxseq . Сервер прислал достаточно много, чтобы это не было похоже на ответ DPI.
• udp : превышение количества пришедших пакетов --hostlist-auto-udp-in . Сервер ответил достаточно много.

При неудаче, если с прошлой неудачи прошло не более --hostlist-auto-fail-time секунд, счетчик неудач увеличивается. Если прошло больше времени - счетчик сбрасывается, счет идет заново.

При удаче счетчик сбрасывается. Считается, что ресурс работает, а сбой был временным и не связанным с блокировкой.

При достижении счетчиком --hostlist-auto-fail-threshold происходит занесение хоста в лист.

Большинство критериев удачи или неудачи требует анализа входящего и исходящего трафика, поэтому необходим их перехват в достаточном обьеме для возможности срабатывания критериев.

Фильтр по наличию сетей

Если, допустим, вам нужно применить одну стратегию для wifi, другую для провода, это делается через фильтр, основанный на имени интерфейса. Но что делать, если вы подключаетесь к разным wifi сетям или подключаете провод в разных локациях ? В случае провода решение есть только на windows, на других системах - нет. Для wifi есть решение на Linux и Windows, на BSD - нет.

Фильтр по wifi берет список SSID через запятую, однако он реализован по-разному в Linux и Windows. В Linux используется фильтр профиля --filter-ssid. Если он задан, nfqws2 пытается получить SSID на интерфейсе, куда этот пакет уходит или откуда он приходит. Если ему это удается - происходит проверка по списку сетей, если нет - условие фильтра не соблюдается, профиль не выбирается. Такая концепция позволяет работать даже если вы подключаетесь к нескольким wifi сетям на разных адаптерах.

В Windows концепция иная. Мониторится наличие указанных wifi сетей на всех wifi адаптерах, и если на любом из них SSID есть, перехват windivert включается, а иначе выключается. Чтобы обслужить wifi сети с разными стратегиями нужно запускать несколько истансов winws2. Один будет включаться, остальные - отключаться. Список SSID задается параметром --ssid-filter.

Другой способ решить вопрос, и не только с wifi, - использование фильтра NLM - Network List Manager. --nlm-list[=all] вернет список GUID подключенных или всех сетей, если указано значение параметра "all". Далее вписываете список GUID через запятую в --nlm-filter.

Сеть NLM - это результат детекта системой подключения к конкретной сети. Вы можете подключиться к роутеру по wifi или проводу, но сеть будет одна. Для различения сетей система обычно смотрит на MAC шлюза. Технология NLM интересная и полезная, но , увы , адекватное управление ей было только в Windows 7. В остальных системах нужно копаться в powershell или лезть в реестр, чтобы раскидать подключения по нужным GUID, если вдруг они раскидались системой неправильно. Но можно и не бороться, а просто внести список GUID, назначенных системой автоматически.

Серверный режим

Некоторые виды воздействий можно осуществлять не только со стороны клиента, но и сервера. nfqws2 создавался с учетом полноценной работы как по входящему, так и по исходящему трафику, как на клиентской стороне, так и на стороне сервера.

Понятие направления в сети во многом условно. Для адресатов пакетов все ясно - что-то отсылается, что-то принимается. Но для роутера это неясно совсем. Есть только входящий интерфейс и исходящий. По сути 2 направления равнозначны, если рассматривать только уровень L3 - уровень отдельных IP пакетов.

Поэтому направление в nfqws2 учитывается за счет слежения за потоками. Поток - это либо tcp соединение, либо последовательность udp пакетов. udp не предполагает понятия соединения, поэтому оставлено общее название - поток.

Поток характеризуется 4 величинами : ip1:port1-ip2:port2. Их совокупность (tuple) определяет принадлежность пакета к конкретному потоку.

За потоками в nfqws2 следит conntrack. Тот, кто первым послал SYN (tcp) или первый UDP пакет, считается клиентом, а противоположный конец - сервером. Если создание записи о потоке в conntrack произошло по SYN,ACK пакету (tcp), то этот конец считается сервером, а противоположный - клиентом. Таким образом conntrack определяет роли в установлении соединения и хранит по каждой роли отдельный набор счетчиков - сколько пакетов прошло, сколько пакетов с данными, сколько байт передано и тд.

В клиентском режиме исходящим направлением считается направление от клиента, в серверном (--server) - от сервера. Входящим считается противоположное направление.

При указании --server направления инвертируются. --in-range, --out-range, а так же признак desync.outgoing в LUA функциях меняются местами, чтобы соответствовать фактически отсылаемым или принимаемым данным со стороны сервера. Клиент шлет запросы (http_req) и принимает ответы (http_reply). Сервер шлет ответы (http_reply) и принимает запросы (http_req).

Для обоих режимов - клиентского и серверного - поиск в ipset осуществляется по IP адресу назначения для исходящего направления и IP адресу источника для входящего направления.

В клиентском режиме фильтры портов проверяют порт назначения для исходящего направления и порт источника для входящего направления.

В серверном режиме фильтры портов проверяют порт назначения для входящего направления и порт источника для исходящего направления.

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

Таким образом, сервер фильтрует по ipset ip клиентов, а клиент - ip серверов. Но и сервер, и клиент фильтруют порт сервера.

Linux conntrack имеет похожий способ определения направлений. Для клиента исходящими будут пакеты original, входящими - reply. Для сервера - наоборот. Это нужно учитывать при написании правил перехвата, полагающихся на направление conntrack.

Можно определять направление и по именам интерфейсов. При стандартной конфигурации lan-wan входящими считаются пакеты, полученные с wan , а исходящими - отправленные через wan. Именно wan, поскольку обычно используется NAT, а для nfqws2 важно перехватывать исходящие пакеты после NAT и принимать входящие до NAT.

Если роутер работает без NAT (типично для ipv6), не имеет значения на каком этапе перехватываются пакеты. Все IP адреса равнозначны. Вы можете подключаться к интернету, интернет - к вам. Вы - его составная часть с прямой IP адресацией. Но на практике все же к вам подключаться скорее всего не будут, а вы защититесь от таких подключений фаерволом. Поэтому направление все равно по интерфейсу определяется достаточно однозначно. Но если у вас все-же есть внутренний сервер, вы можете для него запустить отдельный инстанс nfqws2 в серверном режиме, а для клиентского трафика - в обычном режиме.

В BSD правила ipfw или pf обычно так и пишутся - "xmit wan", "recv wan" + добавляются фильтры по номерам портов назначения для xmit и портов источника для recv (или наоборот для серверного режима). Это достаточно надежно идентифицирует необходимый к перехвату трафик по направлению.

Песочница

В целях безопасности nfqws2 после инициализации сбрасывает свои привилегии. Весь LUA код выполняется только после сброса привилегий. Он никогда не получает исходные права.

BSD :

• Меняется UID/GID на указанные в параметрах --user, --uid. По умолчанию на 0x7FFFFFFF.

Linux :

• Меняется UID/GID на указанные в параметрах --user, --uid. По умолчанию на 0x7FFFFFFF.
• Сбрасываются capabilities до cap_net_raw, cap_net_admin (требуется для NFQUEUE). Сбрасывается bounding set до нуля.
• Выставляется признак NO_NEW_PRIVS, чтобы не работали suid биты и caps на файлах.
• Включается seccomp фильтр, запрещающий exec и ряд файловых операций - чтение содержимого каталогов, создание/удаление каталогов, создание специальных файлов (линки, девайсы), chmod, chown, посылание сигналов (kill), ptrace. В случае нарушения процесс аварийно завершается.

Windows :

• Хотя драйвер windivert требует привилегий администратора, после его инициализации процесс winws2 ставит себе low mandatory level. Это предотвращает доступ на запись практически ко всем файлам и обьектам, защищенным security descriptor. Процесс больше не может управлять службами и осуществлять привилегированные действия. Однако, группа Administrators остается в токене процесса, поэтому ничто не предотвращает чтение большинства файлов, если на них есть доступ для Administrators. LUA не имеет встроенных средств чтения содержимого каталогов, поэтому обнаружение интересующих файлов для злоумышленника затруднено.
• Безвозвратно убираются все Se* привилегии из токена, кроме SeChangeNotifyPrivilege.

Есть простой способ передать LUA коду каталог, доступный на запись - параметр --writeable[=<dirname>]. nfqws2 создает каталог, назначает на него такие права, чтобы LUA код смог писать туда файлы, передает имя директории в переменной env WRITEABLE. Если dirname не задан, на Windows создается каталог внутри %USERPROFILE%/AppData/LocalLow

Со стороны LUA убираются опасные функции - os.execute, io.popen, package.loadlib и модуль debug. На github исполняемые файлы nfqws2 собираются с вариантом luajit без FFI.

Вызов LUA кода

LUA код вызывается в 2 этапа.

1. Однократно при запуске программы через --lua-init=code|@file. Если значение параметра начинается с @, выполняется файл, иначе значение параметра является LUA кодом.
2. При обработке профиля через --lua-desync=function_name:arg1[=val1]:arg2[=val2]:argN[=valN]. Сначала идет имя функции, затем через двоеточия аргументы и их значения. Все значения являются строками. Если значение не задано, оно равно пустой строке. Реализовано 2 типа автоматических подстановок на строне C кода. %var подставляет значение переменной desync.var или var, если первая отсутствует. #var подставляет длину переменной desync.var или var, если первая отсутствует. Двоеточия и знаки %, # в начале могут быть эскейпнуты через \.

И --lua-init, и --lua-desync может быть несколько. Выполнение производится строго в порядке указания.

Передача блобов

Блоб - это двоичный блок данных любого размера, который может быть загружен в переменную LUA средствами C кода при старте программы.

--blob=<item_name>:[+ofs]@<filename>|0xHEX

• item_name - имя переменной LUA.
• [+ofs]@<filename> - загрузка из файла со смещения ofs.
• 0xHEX - загрузка из HEX строки

Прямые операции с файлами из кода LUA не рекомендованы без необходимости. LUA код выполняется с ограниченными правами, задуманное может не получиться или не работать на разных ОС в разных условиях. Загрузка blob происходит до вхождения в песочницу, поэтому шансов на успех больше.

Внутрипрофильные фильтры

Они бывают трех видов - --payload, --in-range, --out-range. Значения фильтров действуют с момента их указания до следующего переопределения.

• --payload=type1[,type2][,type2]... принимает список известных пейлоадов через зяпятую, "all" или "known". Список известных пейлоадов доступен в help тексте nfqws2. По умолчанию --payload=all.
• --(in-range|out-range)=[(n|a|d|s|p)<int>](-|<)[(n|a|d|s|p)<int>] задает диапазоны счетчиков conntrack по входящему и исходящему направлениям. По умолчанию --in-range=x, --out-range=a.

Диапазоны задаются в формах : mX-mY, mX<mY, -mY, <mY, mX-, где m - режим счетчика, X - нижнее значение, Y - верхнее значение. Режимы x и a задаются без диапазона и значения счетчика - единственной буквой. Знак - означает включающую верхнюю границу, < - исключающую.

Доступны следующие режимы счетчика :

• 'a' - всегда
• 'x' - никогда
• 'n' - номер пакета
• 'd' - номер пакета с данными
• 'b' - байт-позиция переданных данных
• 's' - tcp: relative sequence начала текущего пакета
• 'p' - tcp: relative sequence верхней границы текущего пакета (s + длина пейлоада)

nfqws2 следит за превышением верхней границы счетчиков для всех LUA инстансов. Если во всех инстансах превышена верхняя граница по направлению или инстансы вошли по направлению в состояние cutoff добровольно, происходит lua cutoff - выключение процессинга LUA в текущем потоке. Это нужно для экономии ресурсов процессора, поскольку проверка единственного bool признака практически не требует никаких ресурсов.

Типичная схема вызова инстансов внутри профиля

В рассматриваемом примере решается задача для пейлоадов tls_client_hello и http_req попробовать фейки, отдельные для каждого типа пейлоада, а если это не работает, перейти на multidisorder для tls и multisplit для http. Если и это не работает - крутить стратегии по кругу.

--filter-tcp=80,443 --filter-l7=http,tls
--out-range=-d10
--in-range=-s1 --lua-desync=circular
--in-range=x
--payload=tls_client_hello
--lua-desync=fake:blob=fake_default_tls:badsum:strategy=1
--lua-desync=multidisorder:strategy=2
--payload=http_req
--lua-desync=fake:blob=fake_default_http:badsum:strategy=1
--lua-desync=multisplit:strategy=2

Не суть важно как работают конкретные функции, сейчас важно понять как работают внутрипрофильные фильтры и как передаются параметры LUA инстансам.

• Профильный фильтр по tcp портам и типу протокола потока позволяет избежать вызовов LUA на другом трафике. Профиль вообще не будет задействован, если условия фильтра не выполнятся.
• --out-range указан, чтобы отсечь поток от LUA по исходящему направлению после 10 отправленных пакетов с данными - для экономии процессора. На Linux может быть не нужно, если используется фильтр connbytes.
• Инстанс circular для своей работы требует начальные входящие пакеты потока, а по умолчанию они отключены. Поэтому включаем вплоть до первого пакета с данными tcp, который имеет relative sequence 1.
• Остальные инстансы не нуждаются во входящем трафике. Снова отключаем. Действие --in-range=x распространяется до конца профиля.
• Действие --payload распространяется на два следующих за ним инстанса.
• Строчка --lua-desync=fake:blob=fake_default_tls:badsum:strategy=1 вызывает функцию fake с 3 аргументами : blob, badsum, strategy. Значением аргумента badsum является пустая строка.

Прототип LUA функции

Стандартная LUA функция имеет прототип

function desync_f(ctx,desync)

• ctx - контекст для вызова некоторых C функций
• desync - таблица, содержащая все передаваемые значения, включая аргументы, диссект текущего пакета и т.д.

Функция возвращает вердикт по текущему пакету - VERDICT_PASS, VERDICT_MODIFY, VERDICT_DROP. Может не возвращать ничего, тогда результат приравниваться к VERDICT_PASS.

• VERDICT_PASS передает пакет как есть без учета изменений диссекта
• VERDICT_MODIFY выполняет реконструкцию и отправку текущего диссекта
• VERDICT_DROP дропает текущий пакет

Результат всех lua-desync инстансов аггрегируется : VERDICT_MODIFY замещает VERDICT_PASS, VERDICT_DROP замещает их обоих.

Структура таблицы desync

Лучше всего изучать структуру desync по ее реальному содержиому, выполняя тестовую desync функцию pktdebug из zapret-lib.lua.

Пакет http-req от запроса по ipv6 к http://one.one.one.one

desync:
.target
  .port
    number 80
  .ip6
    string 26 06 47 00 47 00 00 00 00 00 00 00 00 00 10 01
.func
  string pktdebug
.func_n
  number 1
.profile_n
  number 1
.l7payload
  string http_req
.dis
  .tcp
    .th_dport
      number 80
    .th_x2
      number 0
    .th_off
      number 8
    .th_sum
      number 18781
    .th_win
      number 64
    .options
      .1
        .kind
          number 1
      .2
        .kind
          number 1
      .3
        .data
          string 30 40 18 9A 6F A5 3E 89
        .kind
          number 8
    .th_seq
      number 19930989
    .th_ack
      number 1489231977
    .th_flags
      number 24
    .th_urp
      number 0
    .th_sport
      number 48118
  .ip6
    .ip6_flow
      number 1871905881
    .ip6_hlim
      number 64
    .ip6_dst
      string 26 06 47 00 47 00 00 00 00 00 00 00 00 00 10 01
    .exthdr
    .ip6_plen
      number 110
    .ip6_src
      string 1A E5 18 81 E1 CD E8 24 BA 16 39 FF FE 8A DE 12
    .ip6_nxt
      number 6
  .payload
    string 47 45 54 20 2F 20 48 54 54 50 2F 31 2E 31 0D 0A 48 6F 73 74 3A 20 6F 6E 65 2E 6F 6E 65 2E 6F 6E 65 2E 6F 6E 65 0D 0A 55 73 65 72 2D 41 67 65 6E 74 3A 20 63 75 72 6C 2F 38 2E 38 2E 30 0D 0A 41 63 63 65 70 74 3A 20 2A 2F 2A 0D 0A 0D 0A
  .l4proto
    number 6
  .transport_len
    number 110
.reasm_offset
  number 0
.reasm_data
  string 47 45 54 20 2F 20 48 54 54 50 2F 31 2E 31 0D 0A 48 6F 73 74 3A 20 6F 6E 65 2E 6F 6E 65 2E 6F 6E 65 2E 6F 6E 65 0D 0A 55 73 65 72 2D 41 67 65 6E 74 3A 20 63 75 72 6C 2F 38 2E 38 2E 30 0D 0A 41 63 63 65 70 74 3A 20 2A 2F 2A 0D 0A 0D 0A
.ifout
  string eth0
.fwmark
  number 0
.func_instance
  string pktdebug_1_1
.replay
  boolean false
.track
  .pos
    .dt
      number 0.013066192
    .server
      .tcp
        .pos
          number 1
        .rseq
          number 1
        .scale
          number 13
        .mss
          number 1360
        .winsize_calc
          number 65535
        .uppos
          number 0
        .seq0
          number 1489231976
        .seq
          number 1489231977
        .uppos_prev
          number 0
        .winsize
          number 65535
      .pcounter
        number 1
      .pdcounter
        number 0
      .pbcounter
        number 0
    .client
      .tcp
        .pos
          number 79
        .rseq
          number 1
        .scale
          number 10
        .mss
          number 1380
        .winsize_calc
          number 65536
        .uppos
          number 79
        .seq0
          number 19930988
        .seq
          number 19930989
        .uppos_prev
          number 0
        .winsize
          number 64
      .pcounter
        number 3
      .pdcounter
        number 1
      .pbcounter
        number 78
    .reverse
      .tcp
        .pos
          number 1
        .rseq
          number 1
        .scale
          number 13
        .mss
          number 1360
        .winsize_calc
          number 65535
        .uppos
          number 0
        .seq0
          number 1489231976
        .seq
          number 1489231977
        .uppos_prev
          number 0
        .winsize
          number 65535
      .pcounter
        number 1
      .pdcounter
        number 0
      .pbcounter
        number 0
    .direct
      .tcp
        .pos
          number 79
        .rseq
          number 1
        .scale
          number 10
        .mss
          number 1380
        .winsize_calc
          number 65536
        .uppos
          number 79
        .seq0
          number 19930988
        .seq
          number 19930989
        .uppos_prev
          number 0
        .winsize
          number 64
      .pcounter
        number 3
      .pdcounter
        number 1
      .pbcounter
        number 78
  .lua_state
  .hostname
    string one.one.one.one
  .hostname_is_ip
    boolean false
  .lua_in_cutoff
    boolean true
  .lua_out_cutoff
    boolean false
  .t_start
    number 1700000000
  .incoming_ttl
    number 51
  .l7proto
    string http
.arg
  .testarg1
    string val1
  .testarg2
    string val2
.tcp_mss
  number 1360
.l7proto
  string http
.outgoing
  boolean true

Поле	Тип	Содержание	Примечание
func	string	имя desync функции
func_n	number	номер инстанса внутри профиля
func_instance	string	название инстанса	производная имени функции, номера инстанса и номера профиля
profile_n	number	номер профиля
profile_name	string	название профиля	может отсутствовать
template_n	number	номер шаблона, на базе которого создан профиль	может отсутствовать
template_name	string	название шаблона, на базе которого создан профиль	может отсутствовать
cookie	string	значение параметра nfqws2 --cookie для профиля	может отсутствовать
outgoing	bool	true , если направление исходящее
ifin	string	имя входящего интерфейса	может отсутствовать
ifout	string	имя исходящего интерфейса	может отсутствовать
fwmark	number	fwmark текущего пакета	только в Linux
target	table	таблица, включающая ip адрес и порт, на базе которых проверяются ipset-ы и фильтры по портам
replay	bool	проигрывание задержанного пакета (replay)
replay_piece	number	номер проигрываемой части	нумерация с 1
replay_piece_count	number	количество проигрываемых частей
replay_piece_last	bool	последняя проигрываемая часть
l7payload	string	тип пейлоада текущего пакета или группы пакетов	если неизвестно - unknown
l7proto	string	тип протокола сеансе	если неизвестно - unknown
reasm_data	string	результат сборки многопакетного сообщения, либо сам пейлоад, если сборки не было	только для tcp
reasm_offset	string	смещение текущего переигрываемого пакета в сборке	только для tcp
decrypt_data	string	результат сборки и дешифровки пейлоада или пейлоадов нескольких пакетов	применяется для quic
tcp_mss	number	MSS противоположного конца tcp соединения	только для tcp
lua_state	table	таблица, привязанная к потоку и передаваемая всем инстансам	только если есть conntrack, может не быть
track	table	данные, привязанные к записи conntrack	только если есть conntrack, может не быть