Изменения в «LecturesCMC/UnixFirewalls2014/Conspects/07»

Продолжается тема 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

поменять местами адреса отправителя и получателя (никому не нужен)