Продолжается тема IPTables, он же NetFilter. Прежде, чем начнётся разговор о том, как он устроен, хочу сделать замечание по поводу различия BSD и Linux. Довольно показательно смотреть, как созданы функциональные инструменты вокруг их файерволлов. Очень хорошо отслеживается специфика. Нельзя сказать, что вокруг FreeBSD маленькое сообщество, но, как говорилось когда-то давно, есть в случае свободного ПО 2 подхода. (Кстати, в сегодняшнем мире они смешаны.) Первый – линуксовый, когда ОС состоит из большого числа пакетов – одинаково сопровождаемых компонентов. При этом сам пакет – это некоторый ПП , взятый c сайта производителя в исходниках, скомпилированный в бинарник, оснащённый дополнительными сценариями и запатченный для правильной работы в данной ОС.

В Linux из пакетов формируется дистрибутив и определяется, какие пакеты важные (ядро, базовая система). А потом всякие маргинальные вещи уже менее важные. Достаточно хорошо так устроено сообщество Debian с жёсткими требованиями к пакету и развесистыми policy.

BSD вводит два принципиально разных набора программ – базовый дистрибутив и пакеты. Различие между ними велико. Прообразом ОС является базовый дистрибутив. Его затачивают, тестируют, применяют жёсткие требования к оформлению кода, к интеграции его частей друг с другом. Наследство тех времён, когда вся ОС занимала 29 МБ. Один отдельно взятый человек неплохо себе мог представлять структуру ОС. Преимущество такого подхода в большей степени интеграции, большей степени строгости, «вылизанности».
Что же касается пакетов – их актуальность становится более низкой. При этом, скорее всего, базовый дистрибутив немыслим без некоторых пакетов. Но даже без них базовый дистрибутив представлял собой полностью работающую ОС, которую поддерживают небольшое число разработчиков (core developers). А пакеты распространяются в более демократичной форме, чем в Linux. Большая часть пакетов считаются дополнительными. На них изначально не накладывается такое же строгое policy. Помните, я говорил, что три фв, входящие в базовый дистрибутив FreeBSD, (и особенно pf) обладают единообразным дизайном. Это связано с тем, что весь код майнтейнится небольшим сообществом core developers. Кодом pf занимается считанное число людей (около двух). Один из них – Глеб Смирнов – читал тут спецкурс в прошлом семестре.

В Linux же ядерная часть и утилита – базовая часть. Эта часть большая, все очем говорили в прошлый раз туда входит. Но, как было сказано в прошлый раз к фв линукс можно писать собственные модули и подключать их. С некоторыми видами протоколов и модулями мы познакомились. Контрэк, исмп и тд. Сегодня попробуем зачитать вслух не очень унылое описание модулей. Немножко выводов, перед основаниями.

Можно написать свой модуль к iptables и дополнить его с помощью 

-m <модуль>
--module <модуль>

Или, почти то же самое 

-p <модуль>

К тому же pf есть API. И более удобный, чем для iptables. Но тем не менее для iptables таких модулей десятки, а для pf модули активно не используются. В случае BSD модули пишутся только если очень припрёт. 95 процентов закрывается дефолтным pf. В iptables же этих модулей постоянно не хватает. Может быть апи не такой и удобный, но ситуации, когда модули нужны, возникают постоянно. И люди их пишут.

С точки зрения пользователя все выглядит прозрачно. Используете правило минус эм модуль, система проверяет его наличие и пытается подгрузить.
Напоминаю, что речь идет о правилах iptables, которые состоят из двух частей: матчинг и таргетирование. Кого обрабатывать и на какую цепочку переходить. В большинстве случаев таргеты – просто действия.

IPTables extensions

Отдельная группа модулей – модули, относящиеся к ipsec. Видимо про ipsec будет отдельная лекция.

addrtype
Что это за адрес? Выясняет, какой это адрес (broadcast, multicast, локальный, запрещенный). Сам ip-адрес бывает разных типов. Можем указать, на каком интерфейсе пакеты нам интересны.
claster
Манипуляция трафика на интерфейсном уровне: бриджи, фильтрация. Все эти устройства на линуксе можно использовать как работающие только на интерфейсном уровне. В частности, когда у вас есть машинка с несколькими бриджованными интерфейсами, вы можете сделать балансировщик нагрузки. Указываете, какие узлы в кластер входят, и кому предназначен пакет.
comment
Позволяет вставлять в правило текстовый комментарий.
connbytes
Connection bytes. Измеряет TCP соединение в байтах, в пакетах. Можно вычислять среднее. Мы уже обсуждали, что биллинг не задача фв, это более толстая задача.
connlimit

Ограничивает количество параллельных соединений одного и того же типа.
Пример: 

 -A INPUT -p tcp --syn --dport 23 -m connlimit --connlimit-above 2 -j REJECT
По 23 порту не более двух соединений. Всё, что более двух – REJECT.
connmark
Раскрашивает все пакеты на данном этапе соединения числом от 0 до 2^32-1. Раскрашивание нужно для того, чтобы помечать пакеты на ранних этапах фильтрации. Классификация на входе, фильтрация на выходе.
mark
Аналог, но работает с отдельными пакетами, а connmark раскрашивает все пакеты соединения.
conntrack

Connection tracker. Замена допотопному пониманию ната и проброса портов, когда создавалось временное правило. Поскольку нам недостаточно одного правила, нужна логика отслеживания и соединения и подмены в нем чего-нибудь. Поэтому это большой модуль.
Например, можно отслеживать соединение по первому его состоянию; можно отследить, был ли пакет подвергнут пробросу портов (dnat)

cpu
Балансировщик нагрузки. Определяет, каким процессором обрабатывается данный пакет. Такое может понадобиться, если у вас выскоконагруженная система. Можно каждый пакет пихать в свою очередь для обработки.

Вот пример, когда модульность играет на руку. В iptables есть поддержка новомодных протоколов dccp, dsct, ecn. Пришло вам в голову фильтровать пакеты по полю глубокого удивления в протоколе передачи эмоций. Что делать с файерволлом? Два пути. Есть модуль u32. Вы говорите проверить четыре байты по смещению с такой то формулой. Вы прикидываетесь, что не умеете разбирать протокол, и просто говорите, какое место смотреть. Это очень неудобно. Другой вариант -- реализовать разбор протокола в виде модуля и предусмотреть какое-то количество опций.

dccp
Нечто среднее между датаграммами и TCP (не будем вдаваться).
u32
Unsigned 32 int – например, отступить столько-то от начала пакета и проверить эти биты.
dsct, ecn, ipvs
Ещё протоколы.
limit
Позволяет ограничить количество чего-то, например, числа подключений по порту. Он довольно развесистый.
hashlimit
В отличие от limit вы можете в каждом правиле вы можете указать много хостов и много портов. Из названия понятно, что используется хеш. Ограничения по айпишнику, хосту, дестинейшену. Есть burst -- начать применять ограничения после чего-то.
iprange
Позволяет вместо одного ip указать целый диапазон.
multiport
То же самое только по портам
length
Измеряет длину пакета.
mac
Классификация по mac-адресу: есть такой mac-адрес, или нет?
nfact

NetFilter Accounting. Классификация не пакетов, а данных по трафику. Идея такая. В этом модуле накапливается информация кто что делал. Потом юзерспейсной утилитой это можно смотреть.

osf
OS finger printing. Определение типа ОС по внешнему виду данных пакетов. Таблицы соответствия ОС обновляются. Их можно обновить, или Вы можете сами их изменить юзерспейсной утилитой.
owner

Если пакет породился нашей ОС, то скорее всего каким-то процессом, => определяет данный процесс, группу и т.п.

physdev
Классифицирует пакет по физическому устройству. Позволяет определить пакет, который перекладывается между интерфейсами без маршрутизации, то есть принадлежит бриджу. Можно например в любом случае его пропускать.
pkttype
Packet type. Multicast, unicast – определяет тип пакета. Аналог addrtype.
quota
Считает количество пакетов.
rateest
Rate estimate. Замеряет соединения, дельту, макс., мин., среднее значение. Организует стандартную исследовательскую среду, которую обычно городят вокруг потоков.
realm
Топология сети.
recent
Статистика реалтайм. Модуль, который запоминает недавно проведенные действия. Можно проверить, пришёл ли пакет из того интерфейса, через который мы ему написали? Пример: 
 -A FORWARD -m recent --name Badguy --rcheck --seconds 60 -j DROP
 # если он угодил в наши списки (--rcheck) в последние 60 секунд, DROP
 -A FORWARD -p tcp -i eth0 --dport 139 -m recent --name badguy --set -j DROP
 # если встретили впервые по порту 139 – добавить в этот список
rpath
Топология.
set
Таблицы. Адресов, портов, пар, четверок. Поиск по таблицам имеет логарифмическую сложность, а по списку линейную.
string
Поискать в пакете строку.
time
Посмотреть время, когда пакет пришёл. Например, разрешать пакет только, если он пришёл в выходные.

Таргеты

У модулей подгружаются собственные цепочки. Многие из модулей имеют соответствующий таргет.

-j AUDIT
производит передачу пакета специальному демону
-j CHECKSUM
позволяет мухлевать с чексуммой пакета
-j HMARK
-j LED
моргать лампочками
-j LOG
-j MASQUERADE
-j REJECT
-j SET
-j TEE
раздваивать пакет в 2 направления
-j MIRROR
поменять местами адреса отправителя и получателя (никому не нужен)