Принципы работы

Компонент Dr.Web Firewall для Linux обеспечивает корректную работу компонента SpIDer Gate, анализируя правила маршрутизации, заданные для NetFilter (системного компонента GNU/Linux), и модифицируя их таким образом, чтобы устанавливаемые соединения перенаправлялись на SpIDer Gate, который выступает в качестве промежуточного звена (прокси) между клиентским приложением и удаленным сервером.

Dr.Web Firewall для Linux может отдельно управлять правилами перенаправления исходящих и входящих, а также транзитных соединений. Для тонкой настройки правил пропуска или перенаправления соединений компонент может использовать как правила, внедренные в настройки, так и скрипт проверки, написанный на языке Lua.

Для перехвата соединений Dr.Web Firewall для Linux использует таблицы маршрутизации, указанные в базе данных политик маршрутизации (см. man ip: ip route, ip rule), а также интерфейс nf_conntrack системного компонента NetFilter. Перехваченные соединения и передающиеся по ним пакеты с целью правильной маршрутизации помечаются битовыми метками, которые позволяют Dr.Web Firewall для Linux принимать правильные решения о перенаправлении соединений и обработке передающихся пакетов на различных этапах прохождения ими цепочек в NetFilter (подробнее см. man iptables).

Dr.Web Firewall для Linux использует следующие действия в правилах iptables:

•MARK. Это действие позволяет Dr.Web Firewall для Linux присвоить пакету указанную числовую метку.

•CONNMARK. Это действие позволяет Dr.Web Firewall для Linux присвоить соединению указанную числовую метку.

•TPROXY. Это действие позволяет Dr.Web Firewall для Linux перенаправить пакет из цепочки PREROUTING NetFilter на указанный сетевой сокет (<IP-адрес>:<порт>), не меняя содержимое пакета. Использование этого действия позволяет Dr.Web Firewall для Linux установить изначальный адрес назначения соединения.

•NFQUEUE. Это действие позволяет передать пакет из сетевого стека ядра на проверку процессу, работающему вне пространства ядра. Таким образом Dr.Web Firewall для Linux подключается к очереди NFQUEUE с заданным номером через специальный Netlink-сокет, и получает пакеты, про которые необходимо внести вердикты по дальнейшей обработке (Dr.Web Firewall для Linux обязан сообщить NetFilter один из следующих вердиктов: DROP, ACCEPT, REPEAT).

Для пометки пакетов Dr.Web Firewall для Linux использует следующие три бита (из доступных 32 бит) в метках пакетов и в метке соединения:

•бит LDM (Local Delivery Mark). Признак локального соединения. Пакеты, в метке которых установлен этот бит, с помощью установленных правил маршрутизации направляются на локальный хост;

•бит CPM (Client Packets Mark). Признак соединения между клиентом (инициатором соединения) и прокси, т. е. Dr.Web Firewall для Linux;

•бит SPM (Server Packets Mark). Признак соединения между прокси, т. е. Dr.Web Firewall для Linux, и сервером (приемником соединения).

Биты LDM, CPM и SPM могут быть любыми различными битами, не используемыми для пометки пакетов другими приложениями, выполняющими маршрутизацию соединений. При настройках по умолчанию Dr.Web Firewall для Linux выбирает подходящие (не используемые другими приложениями) биты автоматически.

Маршруты и политики маршрутизации (ip rule, ip route)

Для корректной работы Dr.Web Firewall для Linux (в любом режиме проверки соединений) в системе должна быть настроена политика маршрутизации ip rule, использующая таблицу маршрутов с номером 100:

В эту таблицу должен быть добавлен маршрут следующего вида:

Данная политика маршрутизации гарантирует, что пакеты, в метке которых установлен бит LDM, всегда направляются на локальный узел.

Здесь и далее выражение <XXX> для бита XXX представляет собой шестнадцатеричное (hexadecimal) число, равное 2N, где N — порядковый номер бита XXX в метке пакета. Например, если в качестве бита LDM выбран самый младший (нулевой) бит метки пакета, то <LDM> = 20 = 0x1.

Для корректной работы Dr.Web Firewall для Linux (в любом режиме проверки соединений) в таблицах nat и mangle соответствующих цепочек компонента NetFilter должны присутствовать следующие шесть правил (представлены в формате вывода команды iptables-save):

*nat

-A POSTROUTING -o lo -m comment --comment drweb-firewall -m mark --mark <LDM>/<LDM> -j ACCEPT

*mangle

-A PREROUTING -m comment --comment drweb-firewall -m mark --mark 0x0/<CPM+SPM> -m connmark --mark <SPM>/<CPM+SPM> -j MARK --set-xmark <LDM>/<LDM>
-A PREROUTING -p tcp -m comment --comment drweb-firewall -m mark ! --mark <CPM+SPM>/<CPM+SPM> -m connmark --mark <CPM>/<CPM+SPM> -j TPROXY --on-port <порт> --on-ip <IP-адрес> --tproxy-mark <LDM>/<LDM>
-A OUTPUT -m comment --comment drweb-firewall -m mark --mark <CPM>/<CPM+SPM> -j CONNMARK --set-xmark <CPM>/0xffffffff
-A OUTPUT -m comment --comment drweb-firewall -m mark --mark <SPM>/<CPM+SPM> -j CONNMARK --set-xmark <SPM>/0xffffffff
-A OUTPUT -m comment --comment drweb-firewall -m mark --mark 0x0/<CPM+SPM> -m connmark ! --mark 0x0/<CPM+SPM> -j MARK --set-xmark <LDM>/<LDM>

В описании ниже этим правилам присвоены порядковые номера 0 — 5 (в том порядке, в котором они перечислены в документе). Выражение <X+Y> обозначает число, равное побитовому "ИЛИ" (сумме) соответствующих чисел X и Y.

Параметры <IP-адрес> и <порт> в правиле № 2 указывают на сетевой сокет, на котором Dr.Web Firewall для Linux контролирует перехваченные соединения.

Кроме того, при включении в настройках Dr.Web Firewall для Linux режима перехвата соединений (исходящих, входящих и транзитных), в таблицах mangle соответствующих цепочек (OUTPUT, INPUT, FORWARD) должны присутствовать следующие дополнительные правила (по одному для каждого из режимов):

•Для перехвата транзитных (forward) соединений:

-A FORWARD -p tcp -m comment --comment drweb-firewall -m tcp --tcp-flags SYN,ACK SYN -m mark --mark 0x0/<CPM+SPM> -j NFQUEUE --queue-num <FNum> --queue-bypass

В описании ниже этим правилам присвоены порядковые номера 6, 7 и 8 (в том порядке, в котором они перечислены в документе).

Здесь <ONum>, <INum> и <FNum> — номера очередей в NFQUEUE, в которых Dr.Web Firewall для Linux ожидает появление пакетов, сигнализирующих об установке соединений соответствующих направлений (это пакеты с установленным флагом SYN, но со сброшенным флагом ACK).

Согласно любому из правил № 6, 7 и 8, пакеты, сигнализирующие о начале нового сетевого соединения соответствующего направления, если они не помечены одновременно битами CPM и SPM, помещаются NetFilter в соответствующие очереди NFQUEUE, откуда они будут прочитаны Dr.Web Firewall для Linux через интерфейс nf_conntrack. Правила № 3 и 4 отмечают само соединение как перехватываемое, т. е. в метке соединения устанавливается бит, указывающий направление соединения; номер этого бита в метке соединения совпадает с номером бита в метке пакета. В результате этого пакеты, посылаемые по этому соединению, благодаря правилам № 1, 2 и 5, будут доставляться Dr.Web Firewall для Linux. Правило № 0 добавляется в начало цепочки POSTROUTING таблицы nat, чтобы в случае настроенного NAT не транслировать адреса для маркированных пакетов (так как это нарушит логику перехвата и обработки соединений Dr.Web Firewall для Linux).

При появлении пакета в одной из очередей NFQUEUE Dr.Web Firewall для Linux выполняет базовую проверку правильности пакета на тот случай, если в NetFilter установлены неверные правила. Далее Dr.Web Firewall для Linux совершает попытку соединиться с сервером от своего имени с сокета, отмеченного меткой PSC. При этом сработает правило № 4. Правило локальной доставки № 5 не сработает, поскольку на пакете стоит метка SPM, а это правило действует только для пакетов с меткой <CPM+SPM>.

•Если соединиться с сервером не удалось, Dr.Web Firewall для Linux формирует для клиента пакет с установленным битом RST, заменяя в пакете пару <IP-адрес>:<порт> на адрес сетевого сокета запрашиваемого сервера. В NFQUEUE при этом отправляется вердикт DROP. На сокете, с которого будет оправлен пакет с битом RST, установлена метка <CPM+SPM>, так что ни одно из указанных выше правил не сработает, и этот пакет будет доставлен клиенту по обычным правилам маршрутизации.

•Если соединение с удаленным сервером удалось установить, Dr.Web Firewall для Linux копирует перехваченный SYN-пакет и повторно отправляет его с сокета, отмеченного меткой <LDM+CPM>, чтобы отправленный пакет был перенаправлен на локальный сетевой сокет. Благодаря установленному биту LDM, в процессе выбора выходного интерфейса, согласно заданным правилам маршрутизации, отправленный пакет попадет на интерфейс loopback, откуда попадет в цепочку NetFilter PREROUTING, где для него сработает правило № 2. Таким образом отправленный пакет в неизменном виде будет перенаправлен на сетевой сокет Dr.Web Firewall для Linux. Данный прием позволяет Dr.Web Firewall для Linux сохранить полную адресную четверку для соединения (IP-адрес и порт отправителя пакета, IP-адрес и порт получателя пакета).

Для сетевого сокета, на который Dr.Web Firewall для Linux принимает перехватываемые соединения согласно правилу № 2, установлена опция IP_TRANSPARENT и метка <LDM+CPM>, благодаря чему пакеты, отправляемые Dr.Web Firewall для Linux с этого сокета, не попадут в очереди NFQUEUE. При подключении клиента производится поиск парного сокета по сохраненной адресной четверке (IP-адрес и порт отправителя, IP-адрес и порт получателя). После того, как соединение с клиентом и с сервером установлено, к соединению применяется процедура проверки, заданная в виде процедуры на языке Lua, а также правила проверки, заданные в настройках Dr.Web Firewall для Linux. Если проверки пройдены успешно и соединение не подлежит разрыву, то сопоставленная пара сокетов, соединяющая клиентскую и серверную сторону установленного соединения, передается компоненту SpIDer Gate для анализа передаваемых по соединению данных. Дальнейшее взаимодействие клиента и сервера производится через посредника, роль которого играет SpIDer Gate. Кроме пары сокетов, ассоциированных с клиентской и серверной стороной соединения, SpIDer Gate получает от Dr.Web Firewall для Linux параметры и правила проверки установленного соединения.

Упрощенно схема работы Dr.Web Firewall для Linux показана на рисунке ниже.

Цифрами обозначены следующие этапы обработки соединения:

1.Попытка клиента установить соединение с сервером.

2.Перенаправление NetFilter устанавливаемого соединения в Dr.Web Firewall для Linux согласно правилам маршрутизации.

3.Попытка Dr.Web Firewall для Linux установить соединение с сервером от имени клиента и проверка соединения.

4.Передача пары сокетов, ассоциированных с клиентской и серверной стороной соединения, SpIDer Gate для обслуживания соединения, а также параметров и правил его проверки.

5.Обмен данными между сервером и клиентом через SpIDer Gate в роли посредника.

Для правильной работы компонента Dr.Web Firewall для Linux необходимо наличие указанных правил в таблицах маршрутизации с правильными номерами битов пометки, очередей NFQUEUE и адресом сетевого сокета для перехвата соединений. При настройках по умолчанию компонент выполняет надлежащую настройку правил автоматически. Если автоматическая настройка соединений компонентом отключена в его настройках, необходимо обеспечить наличие необходимых правил вручную при начале работы компонента.