Сегодня немножко подробней про то, как работает ипфв.

Если времени не хватит, то читать эту документацию совершенно ненапряжно. FreeBSD handbook написан крайне аккуратно и понятно.

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

Сначала из вредности напишем полный внешний вид правила ipfw. Квадратные скобочки означают необзяательность. <#> -- номер.

[<#>][set <#>][prob <вероятность>] <действие> [log[<уровень>]] [][{tag|untag}]<#><правило>

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

Это напоминает нам нормальные алгоритмы маркова.

Что касается множества правил -- правила располагаются в столбик, сквозная нумерация. Но, при добавлении правила можно сказать, что оно принадлежит тому или иному множеству. От 0 до 31. Последнее правило 65535 всегда принадлежит множеству 31, и чаще всего DENY ALL. Идея в том, чтобы атомарно менять фаерволл. Например, выключить множество номер два.

ipfw set enable
ipfw set disable
ipfw set flush
ipfw set swap

Удобно, когда вы хотите в процессе работы с компьютером менять поведение фаерволла.

Очень многие свойства, которые есть сейчас, добавлены в 2004-2006 году, по примеру pf.

Еще можно правила можно перемещать из одного множества в другое командой move. Номера при этом не меняются. Фаерволл продолжает работать также, как работал (если, конечно, оба этих множеств включены/выключены).

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

Журнализация бывает двух видов. Может класть пакеты прямо в сислог. Сислогд слушает сокет, а туда наваливаются сообщения. Такую Журнализацию можно делать прямо по сети. Но плох он тем, что это довольно глубокое путешествие в юзерспейс, через сокеты и всякие такие штуки. Если надо журнализировать очень много, ваш сислогд либо задохнется, либо будет поедать очень много ресурсов.

Другой способ -- посылать в специальный виртуальный интерфейс, в который можно смотреть tcpdump.

ifconfig ipfwfw0 create

tag|untag -- раскрашивание пакетов. У нас есть 256 цветов, которые вы можете по одним вам ведомомым приницпам накрасить пакет и он у вас будет накрашенным. Даже не цвета, а клейкие метки. На пакет можно наклеить сколько угодно такиех меток. Потом в правилах будет встречаться фильтр tagged и вы будете проверять, помечен пакет этим цветом или нет.

Такая простота -- видимость. На самом деле все непросто. Достаточно задуматься, какого уровня это пакет. Подразумевается, что для пользователя эта вещь достаточно прозрачная.

Результат фильтрации непонятно на каком уровне происходит.

Теперь давайте поговорим о том, что может происходить с пакетом.

allow, deny, host <ответ>.

Командочка host выбрасывает пакет, а адресату отправляется сообщение ("host unreachable" или другое), и адресат на сетевом уровне получает это сообщение.

Следующее по важности действие check-state. Оно имеет отношение к опциям keep state и limit по айпишнику, порту и количество соединений.

Фильтр лимит это не фильтр, это правило действие, которое записывает в специальнуб таблицу временныз правил или состояний, правило о том, что данное действие с данным соединением одобрено, но этих соединений должно быть не более чем столько то. И правило срабатывает только до этого лимита. allow лимит такой то.

ipfw add allow tcp from any to any limit port 80 10

Более частый случай правила типа keep-state. У вас какой-то пакет проезжает через ваш фильтр, в котором написано много чего. Правило типа allow, из него генерируется временное правило, что с такого-то на такой-то вот с таким-то разрешено. И если есть правило check state, то просматривается таблица временных правил.

Эти состояния нужны для двух вещей. Первая -- когда вы хотите просто убыстрить работу файерволла. И как правило все стараются написать правила таким образом, чтобы наиболее разгрузочные правила стояли первыми, а наименее используемые -- в конце. Операция keep-state позволяет не каждый раз проверять сложную логику.

Если чек стейт отсутствует, то его роль возьмет на себя любой первое попавшееся правило, в котором есть keep-state.

В качестве примера -- как это делать.

ipfw add check-state
.
.
.
ipfw add allow tcp from <mynet> to any setup keep state
.
.
.
ipfw add deny tcp from any to any

Слово setup матчит только те пакеты, в которых есть syn, но нету ack.

Самые часто используемые фильтры from и to. Может быть айпи адрес, маска, порт.

Следующая группа правил scipto, call, return.

Это goto. Дополнительное правило -- прыгать можно только вперед.

Зачем это нужно?

Чтобы позволит разрабатывать более секционированный свод правил.

fwd <ip> [<port>]

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

Гораздо более популярна команда divert socket. Это еще одна соверешенно волшебная штука от создателей ипфв, которая позволяет перекладывать пакет в юзерспейс. Вы отфильтровали пакет, а дальше хотите Deep Package Inspection, которое длеается приложением в юзерспейсе.

В ранних версиях ipfw вообще не было ната.

Ещё есть действие под названием reass. Это ситуация, когда вы пересобираете прищедший ип-пакет, как будто он был порожден вашим ип-стеком.

В ядре фрибсд есть передача произвольных типизированных сообщений netgraph.

Обработчик типизированных данных в кернел спейсе, с другой стороны обработчик гибкий и программируемый вами на си.

    ipfw pipe # config bw{<#>|<устройство>} delay <#> plr <скорость утери пакетов>

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

Есть ещё burst -- объем данных, которые мы пропускаем без шейпинга если труба пуста.

Если вы хотите сформулировать хитрый профиль, то его можно описать в файле и сказать profile имя_файла.

Это, конечно, не ограничение трафика в смысле его пропускания, а создание агрессивной среды. Трубы -- очень хорошая штука, чтобы на них экспериментировать.

Тут мы плавно переходим к разделу optionsт.

Помимо фильтро from и to, есть еще in и out -- пакеты пойманные на входе и на выходе. Это очень важные поля фильтрации.

Всевозможные опции tcp.

Всевозможные поля ip.

Отдельно флаг под названием diverted -- если пакет получен из divert сокета.

Фрагментирован ли пакет.

Отдельно стоит сказать про фильтры вида layer 2/ bridged. Это означает, что пакет в фаерволл вошел на уровне езернета, а вы уже чего-нибудь с ним делаете.

netmap + ipfw на интерфейсном уровне дает чудеса (juniper).

uid, gid, номер jail.

look up filters.

Набор волшебных адресов, которые к вам приезжают в попытке ддосить вашу машину, и они к вам приезжают, и они все разные. В look-up tables можно забить эти адреса, и по ним будет искаться за логарифм, а не линейно, как если бы было много правил.

Разбор примеров будет домашним заданием.

LecturesCMC/UnixFirewalls2014/Conspects/03 (last edited 2014-03-14 13:58:51 by Allena)