Nuclear Lightning's Track

В честь 26 годовщины 26 апреля уволился с текущей работы и таки наконец начал проект http://wiki.freebsd.org/IpfwNg — хотя на работе FreeBSD и была основной системой, реальную возможность пилить ядро я так и не получил (хотя тот же NAT64 нам бы понадобился не через полгода, так через год). В ближайшие недели посижу дома и надеюсь сделать хотя бы скелет, который можно будет потом уже в свободное время потихоньку пилить — работы по проекту предстоит очень много.

Желающие обсудить по делу — велкам в каменты (хотя я туда еще не все наброски оформил).

Как известно, инженер не должен помнить наизусть кучу формул, констант, свойств материалов, ключей командной строки и прочей информации: он должен помнить общие принципы, и уметь пользоваться справочниками, в которых и можно посмотреть нужное. А также уметь эту справочную информацию найти (знать, в какие справочники смотреть). Общие принципы netgraph были описаны в предыдущем посте, справочниками служат man-страницы и исходные тексты. Остается рассказать, какие узлы netgraph существуют (куда смотреть), и что они умеют — обзор того, что система умеет, какие задачи можно решать, что же именно можно комбинировать друг с другом.

Конечно, уделить внимание всем типам узлов не получится (ведь всего их уже более 60!), но хотя бы по некоторым будет иногда и такая информация, которой нет непосредственно в справочнике. Кроме того, этот пост можно рассматривать как приложение к предыдущему (ограничения на объем поста ЖЖ не позволяют даже поставить ссылку там сюда), для понимания материала необходимо его прочитать. Возможно, здесь будут и другие дополнения к нему.
( Итак, узлы можно условно разделить на... )

Патчи, позволяющие матчить и изменять ToS/DSCP на FreeBSD, ходят в разных вариантах по сети уже лет шесть, вот очередная инкарнация, например. К сожалению, ни один из них так и не попал в базовую систему, хотя пример по ссылке, скажем, для конкретной задачи удобнее того, что описано ниже. Даже возникает подозрение, что это всё потому, что предыдущие решения были недостаточно общие :) Вот Maxim Ignatenko написал ноду ng_patch(4) - и её, наконец, закоммиттили, а недавно смержили в 8-STABLE (r209843) и вчера - в 7-STABLE (r210019). Работает также на 6.4, если убрать в коде CSUM_SCTP, я проверял.
В настоящее время ng_patch - единственный штатный способ поменять что-то в проходящем пакете. Зато, в отличие от других решений (в том числе на других ОС), эта нода позволяет производить последовательность операций над произвольными байтами пакета, не только ToS или TTL. В мане рассмотрены примеры изменения ToS и TTL, я же расскажу чуть подробнее, с примером для DSCP.( Read more... )

Этот пост пригодится вам не только на FreeBSD, но и на Linux и любой другой системе с BPF (для Windows есть вот такое) в случае, когда вы хотите написать приложение, отбирающее напрямую с линии пакеты по некоторому критерию, как tcpdump (ну скажем, хотите проконтролировать ARP в вашей сети по типу приложения ipguard, или еще что). Здесь идет более подробная версия куска моей презентации на RootConf 2009 (по ссылке доступны слайды и видео), где также рассматривался и упоминаемый далее Netgraph.( Read more... )

Тут коллега Citrin (ospf_ripe) поделился опытом о программировании netgraph-ноды ng_bpf(4). Этот узел использует BPF (Berkeley Packet Filter) и позволяет ловить пакеты по определенным критериям, то есть может все то же самое, что и всем хорошо известный tcpdump. То есть, если ipfw(8) у нас умеет фильтровать только по заголовку пакета, то с помощью этой ноды можем фильтровать пакеты прямо в ядре как хотим, по содержимому, благо netgraph легко стыкуется с ipfw при помощи ng_ipfw(4). Citrin'у это понадобилось для фильтрации спамерских DNS-запросов на MX-записи (DoS'ящих DNS-сервер), что требует не такого уж и тривиального анализа пакета - нужно смотреть на байты, которые лежат по смещениям, вычисляемым по другим байтам в пакете. И возможности BPF эту задачу решить позволяют.
Да вот незадача - язык bpf(4) представляет собой специфический ассемблер виртуальной BPF-машины. И если tcpdump предоставляет удобный язык, самостоятельно компилируя заданное выражение в опкоды BPF (между прочим, в libpcap встроен неплохой компилятор, даже с оптимизатором), то ng_bpf требует программирования прямо в этих самых опкодах, которые надо откуда-то сначала получить. Конечно, можно изучить этот ассемблер и написать нужную программу на нем, он не очень сложен - но понятно, что это неудобно. Man-страница ng_bpf(4) предлагает способ использования для этой цели отладочного вывода компилятора libpcap, используемого в tcpdump, с помощью вспомогательного awk-скрипта. Здесь, однако, возникает проблема с отсылкой пакетов в netgraph из ipfw - они туда приходят без Ethernet-заголовка, занимающего 14 байт. А tcpdump генерирует программу с его проверкой. Есть, конечно, вариант подключения ng_bpf к ng_ether(4), напрямую, без файрвола, тогда выражение будет соответствовать. Однако это означает, что необходимо будет самостоятельно здесь же в программе проверять адреса назначения и тому подобное, что удобнее делать в файрволе, отправляя лишь нужные пакеты, кроме того, поскольку проверяться будет каждый пакет, возрастет нагрузка (ng_bpf может быть довольно прожорлив). Citrin решил это написанием небольшой программки на Си, которая компилирует выражение с типом DLT_RAW - каковые пакеты и ходят через ng_ipfw, что описал в подробностях на http://citrin.ru/freebsd:ng_ipfw_ng_bpf вместе с остальными подробностями по фильтрации MX-запросов (живой пример всегда интересен).
Здесь надо заметить, что по ссылке описан случай, когда пакеты, удовлетворяющие условию, просто отбрасываются - часто же нужно что-то сделать с ними дальше в файрволе другое, после проверки по содержимому как части правил файрвола, так сказать. Это можно сделать спомощью появившихся во FreeBSD 6.2-RELEASE тегов ipfw (ipfw tags) - в нетграф на пакет навешивается тег, потом в ipfw он проверяется (возможен и обратный сценарий). Когда я писал для этой цели ng_tag(4) (эта нода тоже вошла в состав 6.2), я столкнулся с той же проблемой - мне надо было фильтровать p2p-пакеты, что делалось в ng_bpf(4). И я, и Citrin попробовали опцию tcpdump -y raw, но tcpdump проверяет допустимый DLT для интерфейса, и не дает указать DLT_RAW. В результате в примере в man ng_tag даются выражения tcpdump в "сырых" смещениях от начала пакета, вычисленных вручную по их формату (это все же проще, чем писать на ассемблере BPF, да); то же сделано и в проскакивавших в mail-листах FreeBSD подробных примерах фильтрации ICQ (авторства bird_of_Luck в IRC-сети RusNet) и BitTorrent.
Стоит заметить, что не всякий L7 filtering может быть сделан с помощью ng_bpf - поскольку в этом ассемблере запрещены условные переходы назад и таким образом циклы, нельзя организовать, например, поиск фиксированной подстроки по заранее неизвестному (и никак не вычисляемому из других данных) смещению в пакете (то, что делает iptables -m string) - думается, в будущем будет написан netgraph-узел, который займется именно этим :)
...Ну а что касается любителей хитрых трюков, то способ использования tcpdump в привычном виде без всяких программок все же был найден :) Для этого необходим файл, записанный ранее с помощью tcpdump -w с data link type DLT_RAW. Содержимое неважно - ведь используется отладочный вывод. То есть, необходимо дать команду вида tcpdump -ddd -r file.raw expression (заменить в скриптах по вкусу).
Получить такой файл можно, например, с помощью утилиты ipfwpcap(8). Это, кстати, довольно полезная вещь сама по себе - вешается на divert-сокет и записывает в файл, который потом можно прочитать с помощью tcpdump -r, пришедшие в него пакеты. Она включена в состав 7-CURRENT, правда, я бы порекомендовал взять версию с http://antigreen.org/vadim/freebsd/ipfwpcap/ - там добавлено несколько полезных фич вроде переоткрытия логов по SIGHUP и т.п. приближений по функционалу к pflogd(8).

UPD: Более подробно тема программирования BPF раскрыта здесь: http://nuclight.livejournal.com/124989.html