Продолжается тема 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, которые состоят из двух частей: матчинг и таргетирование. Кого обрабатывать и на какую цепочку переходить. В большинстве случаев таргеты – просто действия.
Отдельная группа модулей – модули, относящиеся к 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
- поменять местами адреса отправителя и получателя (никому не нужен)