Differences between revisions 1 and 2
Revision 1 as of 2014-04-04 15:31:42
Size: 12749
Editor: Allena
Comment:
Revision 2 as of 2014-04-06 12:40:13
Size: 16112
Editor: Ray
Comment:
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
Продолжается тема иптаблес, она же нетфильтер.
Прежде чем мы начнем разговор о том как оно устроено, хочу сделать замечание по поводу различия бзд и линукс. Довоьно показательно смотреть как созданы функциональные инстументывокруг фв. Очень хрошо отслеживается специфика. Нельзя сеазать, что вокруг фрибзд маленькое сообщество, но как говорилось когда то давно, есть в случае свободного по есть два подхода. Кстати в сегодняшнем мире они смешаны. Два подхода - линуксовый, когда ос как таковая состои из большого числа пакетов- одинаково сопровождаемых компонентов. При этом сам пакет это некотырый пп, взятый с сайта производителя в исходн ках, скомпилированный в бинарн к и оснащенный доп сценариями и запатченный для правил ной работы в данной ос.
Продолжается тема IPTables, он же `NetFilter`. Прежде, чем начнётся разговор о том, как он устроен, хочу сделать замечание по поводу различия BSD и Linux. Довольно показательно смотреть, как созданы функциональные инструменты вокруг их файерволлов. Очень хорошо отслеживается специфика. Нельзя сказать, что вокруг FreeBSD маленькое сообщество, но, как говорилось когда-то давно, есть в случае свободного ПО 2 подхода. (Кстати, в сегодняшнем мире они смешаны.)
Первый – линуксовый, когда ОС состоит из большого числа пакетов – одинаково сопровождаемых компонентов. При этом сам пакет – это некоторый ПП /* программный продукт? */ , взятый c сайта производителя в исходниках, скомпилированный в бинарник, оснащённый дополнительными сценариями и запатченный для правильной работы в данной ОС.
Line 4: Line 4:
Из пакетов формируется дистрибутив и определяется какие пакеты вадные -- ядро, базовая система. А потом всякие маргинальные вещи уже менее важные. Достаточно хорошо устроено сообщество дебиан с жесткм требованиям к пакету и развесистыми полиси. Введем грубое различие на базовые и доп пакеты. В Linux из пакетов формируется дистрибутив и определяется, какие пакеты важные (ядро, базовая система). А потом всякие маргинальные вещи уже менее важные. Достаточно хорошо так устроено сообщество Debian с жёсткими требованиями к пакету и развесистыми policy.
Line 6: Line 6:
Бзд вводит два принципиально разных набора прогамм -- базовый дистрибутив и пакеты. Различие между ними велико. Прообразом ос является базовый дистрибутив. Его затачивают, тестируют, применяют жестокие требования к оформлению кода, требования к интеграции частей друг с другом. Все то, что боллее мягко относится к пакетам в линукс. Наследство тех времен когда вся ос занимала 29 мб, один человек мог представлять себе структуру всей ос. Очевидно преимущество перед сборкой из пакетов -- можем потребовать большую строгость. BSD вводит два принципиально разных набора программ – базовый дистрибутив и пакеты. Различие между ними велико. Прообразом ОС является базовый дистрибутив. Его затачивают, тестируют, применяют жёсткие требования к оформлению кода, к интеграции его частей друг с другом.
Наследство тех времён, когда вся ОС занимала 29 МБ. Один отдельно взятый человек неплохо себе мог представлять структуру ОС. Преимущество такого подхода в большей степени интеграции, большей степени строгости, «вылизанности».<<BR>>
Что же касается пакетов – их актуальность становится более низкой. При этом, скорее всего, базовый дистрибутив немыслим без некоторых пакетов. Но даже без них базовый дистрибутив представлял собой полностью работающую ОС, которую поддерживают небольшое число разработчиков (core developers). А пакеты распространяются в более демократичной форме, чем в Linux. Большая часть пакетов считаются дополнительными. На них изначально не накладывается такое же строгое policy.
Помните, я говорил, что три фв, входящие в базовый дистрибутив FreeBSD, (и особенно pf) обладают единообразным дизайном. Это связано с тем, что весь код майнтейнится небольшим сообществом core developers. Кодом pf занимается считанное число людей (около двух). Один из них – Глеб Смирнов – читал тут спецкурс в прошлом семестре.
Line 8: Line 11:
Что же касается пакетов - их актуальность становится более низкой. При этом скорее всего базовый дистрибутив немыслим без некоторых пакетов. Но даже без них базовый дистрибутив был работающей ос, контролируемый одним сообществом. С пакетами все было свободней чем в линуксе, строгих политик не накладывалось.
Большая часть пакетов считается дополнительными.
В Linux же ядерная часть и утилита – базовая часть. Эта часть большая, все очем говорили в прошлый раз туда входит. Но, как было сказано в прошлый раз к фв линукс можно писать собственные модули и подключать их. С некоторыми видами протоколов и модулями мы познакомились. Контрэк, исмп и тд. Сегодня попробуем зачитать вслух не очень унылое описание модулей. Немножко выводов, перед основаниями.
Line 11: Line 13:
Помните я говорил, что три фв, входящих в базовый дистрибутив фрибзд, и особенно пф обладает единообразным дизайном. Весь код мантейнится небольшим сообществом кор девелоперс. Аккуратный аудит кода и защита от несообразностей и глюков. Можно написать свой модуль к iptables и дополнить его с помощью
{{{
-m <модуль>
--module <модуль>
}}}
Или, почти то же самое
{{{
-p <модуль>
}}}
К тому же pf есть API. И более удобный, чем для iptables. Но тем не менее для iptables таких модулей десятки, а для pf модули активно не используются. В случае BSD модули пишутся только если очень припрёт. 95 процентов закрывается дефолтным pf. В iptables же этих модулей постоянно не хватает. Может быть апи не такой и удобный, но ситуации, когда модули нужны, возникают постоянно. И люди их пишут.
Line 13: Line 24:
А вот что касается фаерволла влинукс -- там ситуация другая. Есть ядерная часть и утилита -- базовая часть. Эта часть большая, все очем говорили в прошлый раз туда входит. Но, как было сказано в прошлый раз к фв линукс можно писать собственные модули и подключать их. С некоторыми видами протоколов и модулями мы познакомились. Контрэк, исмп и тд. Сегодня попробуем зачитать вслух не очень унылое описание модулей.
Немножко выводов, перед основаниями.
С точки зрения пользователя все выглядит прозрачно. Используете правило минус эм модуль, система проверяет его наличие и пытается подгрузить.<<BR>>
Напоминаю, что речь идет о правилах iptables, которые состоят из двух частей: матчинг и таргетирование. Кого обрабатывать и на какую цепочку переходить. В большинстве случаев таргеты – просто действия.
Line 16: Line 27:
На самом деле дя написания модулей к пфу есть апи. И тем не менее для иптейблз модулей многие десятки, а для пф модули активно не используются. Видать структура сообществ разная. В случае бзд модули пишутся только если очень припрет. 95 процентов закрывается дефолтным пф. В случае, когда почти все является модулями, этих модулей вечно не хватает. ~+[[http://ipset.netfilter.org/iptables-extensions.man.html|IPTables extensions]]+~
Line 18: Line 29:
Может быть апи и не такое удобное, но ситуация когда они нужны встречается намного чаще. Отдельная группа модулей – модули, относящиеся к ipsec. Видимо про ipsec будет отдельная лекция.
Line 20: Line 31:
Документ назывется iptabkes extensions. С точки зрения пользователя все выглядит прозрачно. Используете правило минус эм модуль, система проверяет его наличие и пытается подгрузить.  addrtype:: Что это за адрес? Выясняет, какой это адрес (broadcast, multicast, локальный, запрещенный). Сам ip-адрес бывает разных типов. Можем указать, на каком интерфейсе пакеты нам интересны.
Line 22: Line 33:
Напоминаю, что речь идет оправилах иптаблес, которые состоят из двух частей -- матчинг и таргетирование. Кого обрабатывать и на какую цепрчку переходить. В большинстке случаев таргеты -- просто действия.  claster:: Манипуляция трафика на интерфейсном уровне: бриджи, фильтрация. Все эти устройства на линуксе можно использовать как работающие только на интерфейсном уровне. В частности, когда у вас есть машинка с несколькими бриджованными интерфейсами, вы можете сделать балансировщик нагрузки. Указываете, какие узлы в кластер входят, и кому предназначен пакет.
Line 24: Line 35:
Addrtype. Что это за адрес? Бродкаст, мультикаст, локальный, запрещенный? Сам ип адрес бывает разных типов. Можем указать, на каком интерфейсе пакеты нам интересны.  comment:: Позволяет вставлять в правило текстовый комментарий.
Line 26: Line 37:
Отдельная группа модулей - модули, относящиеся к ипсеку. Видимо про ипсек будет отдельная лекция.  connbytes:: Connection bytes. Измеряет TCP соединение в байтах, в пакетах. Можно вычислять среднее. Мы уже обсуждали, что биллинг не задача фв, это более толстая задача.
Line 28: Line 39:
Следующий модуль по алфавиту - cluster. Имеет отношение к манипуляции трафиком на интерфейсном уровне. В частности, когда у вас есть машинка с несколькими бриджованными интерфейсами, вы можете сделать балансировщик нагрузки. Указываете, какие узлы в кластер входят, и каому предназначен пакет.  connlimit:: Ограничивает количество параллельных соединений одного и того же типа.<<BR>>
 Пример:
 {{{
 -A INPUT -p tcp --syn --dport 23 -m connlimit --connlimit-above 2 -j REJECT
 }}}
 По 23 порту не более двух соединений. Всё, что более двух – REJECT.
Line 30: Line 46:
Comment -- позволяет вставлять в правило текстовый комментарий.  connmark:: Раскрашивает все пакеты на данном этапе соединения числом от 0 до 2^32-1.
 Раскрашивание нужно для того, чтобы помечать пакеты на ранних этапах фильтрации.
 Классификация на входе, фильтрация на выходе.
Line 32: Line 50:
Connbytes -- мы уже обсуждали, что биллинг не задача фв, это болле толстая задача. А с другой стороны задача наблюдения актуальна. Модуль сбора статистики. Меряет тцп соединения в байтах, в пакетах, можете вычислять среднее.  mark:: Аналог, но работает с отдельными пакетами, а connmark раскрашивает все пакеты соединения.
Line 34: Line 52:
Connlimit -- ограничивает количество параллельных соединений одного типа. Можете написать правило, в котором будет написано чтото типа -a input -p tcp -syn - dport 23 -m connlimit --connlimit 2 -j reject.  conntrack:: Connection tracker. Замена допотопному пониманию ната и проброса портов, когда создавалось временное правило. Поскольку нам недостаточно одного правила, нужна логика отслеживания и соединения и подмены в нем чего-нибудь. Поэтому это большой модуль.<<BR>>
 Например, можно отслеживать соединение по первому его состоянию; можно отследить, был ли пакет подвергнут пробросу портов (dnat)
Line 36: Line 55:
Обратите внимания, что у модулей собственные дополнительные параметры.  cpu:: Балансировщик нагрузки. Определяет, каким процессором обрабатывается данный пакет. Такое может понадобиться, если у вас выскоконагруженная система. Можно каждый пакет пихать в свою очередь для обработки.
Line 38: Line 57:
Следующий модуль connmark. Аналог модуля mark. Раскрашивание пакетов. Нужно чтобы классифицировать пакеты в одном месте, а принимать решения в другом. Mark работает с отдельными пакетами, а коннмарк раскрашивает все пакеты соединения. Вот пример, когда модульность играет на руку. В iptables есть поддержка новомодных протоколов dccp, dsct, ecn. Пришло вам в голову фильтровать пакеты по полю глубокого удивления в протоколе передачи эмоций. Что делать с файерволлом? Два пути. Есть модуль u32. Вы говорите проверить четыре байты по смещению с такой то формулой. Вы прикидываетесь, что не умеете разбирать протокол, и просто говорите, какое место смотреть. Это очень неудобно. Другой вариант -- реализовать разбор протокола в виде модуля и предусмотреть какое-то количество опций.
Line 40: Line 59:
Conntrack. Замена допотопному пониманию ната и проброса портов, когда создавалось временное правило. Поскольку нам недостаточно одного правила, нужна логика отслеживания и соединения и подмены в нем чего-нибудь. Поэтому это большой модуль.  dccp:: Нечто среднее между датаграммами и TCP (не будем вдаваться).
 u32:: Unsigned 32 int – например, отступить столько-то от начала пакета и проверить эти биты.
 dsct, ecn, ipvs:: Ещё протоколы.
Line 42: Line 63:
Волшебный модуль под названием cpu. Определяет, каким процессором обрабатывается пакет.  limit:: Позволяет ограничить количество чего-то, например, числа подключений по порту. Он довольно развесистый.
Line 44: Line 65:
Вот пример, когда модульность играет на руку. В иптаблес есть поддержка новомодных протоколов dscp, ecn dccp. Пришло вам в голову фильтровать пакеты по полю глубокого удивлеия в протоколе передачи эмоций. Что делат с фаерволлом? Два пути. Есть модуль u32. Вы говорите проверить четыре байты по смещению с такой то формулой. Вы прикидываетесь, что не умеете разбират протокол, и просто говорите какое мето смотреть. Это очень неудобно. Другой вариант реализовать разбор проткола в виде модуля и предусмотрет какое-то количество опций.  hashlimit:: В отличие от limit вы можете в каждом правиле вы можете указать много хостов и много портов. Из названия понятно, что используется хеш. Ограничения по айпишнику, хосту, дестинейшену. Есть burst -- начать применять ограничения после чего-то.
Line 46: Line 67:
Limit. Позволяет ограничить количество чего-то. Например количество соединений по порту.  iprange:: Позволяет вместо одного ip указать целый диапазон.
Line 48: Line 69:
Hashlimit. Тоже самое что лимит, но в одном правиле можно указать сразу много хостов и портов.
Ограничения. По айпишнику, хосту, дестинейшену. Есть burst -- начать применять ограничения после чего-то.
 multiport:: То же самое только по портам
Line 51: Line 71:
Iprange. Аггрегация. Модуль, позволяющий вместо одного айпишника задать диапазон.  length:: Измеряет длину пакета.
Line 53: Line 73:
Multiport. Тоже самое для портов.  mac:: Классификация по mac-адресу: есть такой mac-адрес, или нет?
Line 55: Line 75:
Ipvs. Что-то за модуль.  nfact:: `NetFilter` Accounting. Классификация не пакетов, а данных по трафику. Идея такая. В этом модуле накапливается информация кто что делал. Потом юзерспейсной утилитой это можно смотреть.
Line 57: Line 77:
Len. Измерение длины пакета.  osf:: OS finger printing. Определение типа ОС по внешнему виду данных пакетов.
 Таблицы соответствия ОС обновляются. Их можно обновить, или Вы можете сами их изменить юзерспейсной утилитой.
Line 59: Line 80:
Mac. Классификация по мак адресу.  owner:: Если пакет породился нашей ОС, то скорее всего каким-то процессом, => определяет данный процесс, группу и т.п.
Line 61: Line 82:
Nfact. Netfilter accounting. Идея такая. В этом модуле накапливается информация кто что делал. Потом юзерспейсной утилитой это можно смотреть.  physdev:: Классифицирует пакет по физическому устройству. Позволяет определить пакет, который перекладывается между интерфейсами без маршрутизации, то есть принадлежит бриджу. Можно например в любом случае его пропускать.
Line 63: Line 84:
Osf -- OS fingerprinting. Таблицы можно туда пропихивать юзерспейсной утилитой.  pkttype:: Packet type. Multicast, unicast – определяет тип пакета. Аналог addrtype.
Line 65: Line 86:
Owner. Если у нас пакет породился нашей системой, скорее всего его породил процесс.  quota:: Считает количество пакетов.
Line 67: Line 88:
Physdev. Позволяет определить пакет, который перекладывается между интерфейсами без маршрутизации, то есть принадлежит бриджу. Можно например в любом случае его пропускать.  rateest:: Rate estimate. Замеряет соединения, дельту, макс., мин., среднее значение. Организует стандартную исследовательскую среду, которую обычно городят вокруг потоков.
Line 69: Line 90:
Pkttype -- мультикаст, уникаст -- определяет тип пакета. Аналог аддртайпа.  realm:: Топология сети.
Line 71: Line 92:
Rateest -- статистика.  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 – добавить в этот список
 }}}
Line 73: Line 102:
Realm. Топология.  rpath:: Топология.
Line 75: Line 104:
Recent. Статистика реалтайм. Модуль, который запоминает недавно проведенные действия.  set:: Таблицы. Адресов, портов, пар, четверок. Поиск по таблицам имеет логарифмическую сложность, а по списку линейную.
Line 77: Line 106:
Rpfilter -- проверка из правильного ли места мы получили пакет.  string:: Поискать в пакете строку.
Line 79: Line 108:
Set -- таблицы. Адресов, портов, пар, четверок.  time:: Посмотреть время, когда пакет пришёл. Например, разрешать пакет только, если он пришёл в выходные.
Line 81: Line 110:
String -- классификация.

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

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

 
=== Таргеты ===
У модулей подгружаются собственные цепочки. Многие из модулей имеют соответствующий таргет.
 -j AUDIT:: производит передачу пакета специальному демону
 -j CHECKSUM:: позволяет мухлевать с чексуммой пакета
 -j HMARK::
 -j LED:: моргать лампочками
 -j LOG::
 -j MASQUERADE::
 -j REJECT::
 -j SET::
 -j TEE:: раздваивать пакет в 2 направления
 -j MIRROR:: поменять местами адреса отправителя и получателя (никому не нужен)

Продолжается тема 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
поменять местами адреса отправителя и получателя (никому не нужен)

LecturesCMC/UnixFirewalls2014/Conspects/07 (last edited 2014-04-06 12:40:13 by Ray)