Продолжается тема иптаблес, она же нетфильтер. Прежде чем мы начнем разговор о том как оно устроено, хочу сделать замечание по поводу различия бзд и линукс. Довоьно показательно смотреть как созданы функциональные инстументывокруг фв. Очень хрошо отслеживается специфика. Нельзя сеазать, что вокруг фрибзд маленькое сообщество, но как говорилось когда то давно, есть в случае свободного по есть два подхода. Кстати в сегодняшнем мире они смешаны. Два подхода - линуксовый, когда ос как таковая состои из большого числа пакетов- одинаково сопровождаемых компонентов. При этом сам пакет это некотырый пп, взятый с сайта производителя в исходн ках, скомпилированный в бинарн к и оснащенный доп сценариями и запатченный для правил ной работы в данной ос.

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

Бзд вводит два принципиально разных набора прогамм -- базовый дистрибутив и пакеты. Различие между ними велико. Прообразом ос является базовый дистрибутив. Его затачивают, тестируют, применяют жестокие требования к оформлению кода, требования к интеграции частей друг с другом. Все то, что боллее мягко относится к пакетам в линукс. Наследство тех времен когда вся ос занимала 29 мб, один человек мог представлять себе структуру всей ос. Очевидно преимущество перед сборкой из пакетов -- можем потребовать большую строгость.

Что же касается пакетов - их актуальность становится более низкой. При этом скорее всего базовый дистрибутив немыслим без некоторых пакетов. Но даже без них базовый дистрибутив был работающей ос, контролируемый одним сообществом. С пакетами все было свободней чем в линуксе, строгих политик не накладывалось. Большая часть пакетов считается дополнительными.

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

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

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

Может быть апи и не такое удобное, но ситуация когда они нужны встречается намного чаще.

Документ назывется iptabkes extensions. С точки зрения пользователя все выглядит прозрачно. Используете правило минус эм модуль, система проверяет его наличие и пытается подгрузить.

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

Addrtype. Что это за адрес? Бродкаст, мультикаст, локальный, запрещенный? Сам ип адрес бывает разных типов. Можем указать, на каком интерфейсе пакеты нам интересны.

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

Следующий модуль по алфавиту - cluster. Имеет отношение к манипуляции трафиком на интерфейсном уровне. В частности, когда у вас есть машинка с несколькими бриджованными интерфейсами, вы можете сделать балансировщик нагрузки. Указываете, какие узлы в кластер входят, и каому предназначен пакет.

Comment -- позволяет вставлять в правило текстовый комментарий.

Connbytes -- мы уже обсуждали, что биллинг не задача фв, это болле толстая задача. А с другой стороны задача наблюдения актуальна. Модуль сбора статистики. Меряет тцп соединения в байтах, в пакетах, можете вычислять среднее.

Connlimit -- ограничивает количество параллельных соединений одного типа. Можете написать правило, в котором будет написано чтото типа -a input -p tcp -syn - dport 23 -m connlimit --connlimit 2 -j reject.

Обратите внимания, что у модулей собственные дополнительные параметры.

Следующий модуль connmark. Аналог модуля mark. Раскрашивание пакетов. Нужно чтобы классифицировать пакеты в одном месте, а принимать решения в другом. Mark работает с отдельными пакетами, а коннмарк раскрашивает все пакеты соединения.

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

Волшебный модуль под названием cpu. Определяет, каким процессором обрабатывается пакет.

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

Limit. Позволяет ограничить количество чего-то. Например количество соединений по порту.

Hashlimit. Тоже самое что лимит, но в одном правиле можно указать сразу много хостов и портов. Ограничения. По айпишнику, хосту, дестинейшену. Есть burst -- начать применять ограничения после чего-то.

Iprange. Аггрегация. Модуль, позволяющий вместо одного айпишника задать диапазон.

Multiport. Тоже самое для портов.

Ipvs. Что-то за модуль.

Len. Измерение длины пакета.

Mac. Классификация по мак адресу.

Nfact. Netfilter accounting. Идея такая. В этом модуле накапливается информация кто что делал. Потом юзерспейсной утилитой это можно смотреть.

Osf -- OS fingerprinting. Таблицы можно туда пропихивать юзерспейсной утилитой.

Owner. Если у нас пакет породился нашей системой, скорее всего его породил процесс.

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

Pkttype -- мультикаст, уникаст -- определяет тип пакета. Аналог аддртайпа.

Rateest -- статистика.

Realm. Топология.

Recent. Статистика реалтайм. Модуль, который запоминает недавно проведенные действия.

Rpfilter -- проверка из правильного ли места мы получили пакет.

Set -- таблицы. Адресов, портов, пар, четверок.

String -- классификация.

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

Audit. Проищводит передачу пакета специальному демону.