Материал из eSyr's wiki.

• Диктофонная запись: http://esyr.org/lections/audio/uneex_2009_summer/uneex_09_03_18.ogg

Несколько объявлений:

• Кто может прочесть лекцию по iptables. Если кто-то хочет прочитать лекцию по непонятной теме, то нужно понять её и тоже можно прочитать
• Требуется преподаватель по курсу "Введение в ОС Linux", оплата 500р/час, это вечером, с 6 до 9, время уточняется, курс 72 часа. Единственное требование — разбираться в том, о чём рассказываете. По этому поводу либо подойти после занятия, либо пишите письма лектору или Чёрному
• Уже не в первый раз в МПГУ лектор ведёт факультатив по Python на этот раз. Начало в 1420, конец в 1600. Если кто-то мог бы проести этот семинар в след четверг, было бы хорошо. Дети-первокурсники.

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

Посылка разг. о fw вообще в ОС общего назначения: посыл 1 — нет такого прогр. продукта под названием firewall, поск. задача очень разнообр. и реализ. разнообр. продуктами. Посыл 2 — есть такой фреймфорк обработка трафика, и в этом случае возм. вообр. ситуацию, когда с одной стороны со сторонры ядра предусмотрены ручки, чтобы отдавать проходящий трафик, и получать, чтобы он шёл дальше (первое --- поддержка на уровне ядра). Нужны дополнительные модули ядра, процедуры уровня kernel, которые собственео и занимаются обр., преобр. и делают что-то с ip-трафиком. Назовём это модулями. Это не совсем правильно, но для FreeBSD/Linux верно. С третьей стороны должны быть userspece-программы, утилиты и демоны, которые по большей части упр. этим безобразием, хотя ывают и имскл.

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

Содержание 1 польз. инт. 2 stateful firewall 3 Относительно traffic shaping 4 Конспект Kda

польз. инт.

Лекктор попыытается ответить на вопрос, как это управляется. ipfw, который дост. давно появился в freebsd (в версии 2.0). ipfw имеет линейчатую структуру, каждое правильо говорит, чот с пакетом делать. У такой архитектуры есть дост. и недостаток. Дост --- простота, недостатки --- необходимо делать нелинечатый разл. способами.

Фактически, всё своидтся к утилите под названием ipfw. Для добавления правлиа пишете

ipfw add [номер] [св-ва] тело

Несколько правил могут иметь один и тот же номер, сортируются они по порядку добавления. Если хотите удалить конкр. правило — не делайте две штуки под одним номером. Далее идут собственно правила, которые бывают разного вида. Здесь может быть всякие дополнительные свойства, дальше собственно тело. Что касается тела, мы с ним в прошлый раз разбирались.

какие можно написать свойства:

• log --- будет залоггировано в сист. журнале
• set [номер]. Это такое новое введение. В ipfw сделали мнго нововведений, в частности, понятие множества правил. Можно, включать-выкл.-удалять множества целиком.
• probability --- вероятность. Можно указать вероятность, с которой правило применится.
• tag# --- можно пометить правило тегом. Если правило с тегом срабатывает, то этот тег прилипает, и будет с ним висеть, пока оно ходит внутри ядра.

Для того, чтобы удалить правило, нужно сказать

ipfw del # [правило]

правило позв. удалить конкр. правило в одним и тем же номером

ipfw ...

ipfw show

ipfw show выводит правила, в том числе и динамические.

Лектор зачитате вслух, какие свойства можно указывтьа. Прежде, чем это сделать, лектор напомнить, что во freebsd сущ. 5 точек обр. трафика, из которой они пересылваются на бр. ipfw. Это взодящие на ур. интерфейса, вход. на уровне ip, исх. на уровне ip, исх. на ур. eth и bridge. Соотв., всё это запих. на обр. однй и той же цепочки правил, но можно указать префикс (например, in, out, bridge). что можно, какие свойства ук. в теле:

• Идент. инт. уровня: мак-адрес, если доступен. Напр., на исх. ip-трафике никакого мака нет.
• Все поля ipv4/ipv6.
• Направления
• ip-адрес. Можно указывать range и списки
• Название интерфейса
• Опции протокола ip
• Свойства протокола TCP, в первую очередь те, которые позв. упр. трафиком: флаги TCP, упр. сеансом работы
• ICMP, чтобы можно было пропускать-не пропцускать-модифицировать
• Если польз. divert socket, если есть такое место в ФВ, где divert есть, то divert state тоже проверяется --- можно проверить, был пакет через divert пропущен или нет

stateful firewall

Теперь, после того, как лектор это прочёл, лектор загладит свою вину, в прошлый раз он неудачно начал расск. про stateful firewall. Представьте, что есть здоровый фаерволл с тысячами правил, и он работает относительно долго.

Вообще, fw был создан по принципу first wins. Соотв., каждое правило сколько-то работает. В особенности много времени жрут правила divert (потому что приходится предавать пакет в userspace) и всевозможные пробивки пакета на предмет статуса в таблицах. Между тем, обмен данными по сети, особенно при исп. TCP, обл. следующим свойством: вот у нас есть tcp-соединение, у него есть некий идентификатор. С некоторой потерей безопасности можно утв. следующее: если TCP-соед. установлено, то все его пакеты можно пропускать. Если была разр. установка, то гонять данные тоже можно. Поэтому решено вот что: первый пакет идёт довольно долго, пока не упрётся вправило вида

ipfw add allow tcp from mynet to any setup

Обратите внимание на слово setup. Все пакеты, которые мы не отфильтровали раньше ... слово setup говорит о том, что нужно пропускать только пакеты, уст. соединение. Можно было пропустить setup, и огда любое соединение могло расчитывать, что его пропустят, но мы не хотим гонять процессор до него. Тогда мы пишем вот что:

ipfw add allow tcp from mynet to any setup kepp-state

Оно означает вот что: в этот момент формируется временное правило, которое откл. в раздел временных правил, там записывается четвёрка отпр. и получателя, и в кач. тела запис. то, что мы указали --- ipfw add allow tcp from mynet to any setup, и на него навеш. идент. соединения. Создаётся временное правило, которое позв. применять это для четвёрки идентификаторов.

По флагу keep-state созд. временное правлио, которое в обл. правил будет висеть. Временное правило живёт какое-то время, задаётся оно параметрами ядра, если случается так, что это временное правило применяется, то у него время жизни увеличивается, вместо keep-state мы могли написать limit и какой именно лимит, чтобы указать огр. по количеству использований. Чтобы, например, жти новые соед. 10 установились, а дальше нет.

Зачем эти правила? Чтобы в начале можно было написать

ipfw add checkstate

В этом месте происх. проверка, не попадает ли этот пакет под некое правило в области временных правил. Если вы в какой-то момент отметили какой-то пакет как опустимый, то все пакеты из этого tcp-соединения будут ещё на этапе checkstate пропущены, если временное правило дожило до этого момента.

Очевидное дост. безобразия следующее: можно писать после этого правила deny tcp from any to any, зная, что те правила, которые выше, всё, что нужно, пропучстило.

Кроме того, вы можете рассч. на о, что такого рода правило по расп. пакетов для TCP-сессии будут специфическими (например, setup), поэтому, если checkstate сильно раньше нашего правлиа, то это будет эффективно.

Поск. работа ipfw это факт. выполн. pattern matching, то такая штука востребована.

Недостаток checkstate в том, что его достаточно легко за dos'ить, если не включена соотв. ручка в ядре. Соотв., созд. много вр. правил и память заканчивается. Здесь помогает слово limit и спец. ручка в ядре, которая позв. этому противодействовать.

Лектор обр. внимание, что это не имеет ничего общего с NAT и теми вещами, о которых говорили ранее. Это возм. упростить сам линейчатый фаерволл и ускорить его работу.

Относительно traffic shaping

Что касается ipfw, есть специальный модуль dummynet, который отв. за шейпинг разнообр. способом.

Прежде, чем... что происх, когда вы впис. эти три правила в фаерволл: никакие входящие tcp-соед. не проходят совсем. Все исх. соед. и внутр. сети проходят наружу, таким обр., что созд. временное правило, обр. в checkstate. Есть ещё совет поставить после checkstate deny tcp from any to any established, чтобы оно не доходило до конца, а убивалось раньше. Ибо все валидные соединения пропустит checkstate.

dummynet изображает из себя сеть со всеми её свойствами: пропуск. способсность, потеря пакетов и так далее. С точки зрения польз. это такая руба, отн. которой можно задать параметр, которые лектор уже говорил:

• delay -- Задержка
• bw --- bandwidth
• plr -- packet loss rate

Выглядит это примерно след. обр.: с точки зрения польз: создать трубу и сконфигур. её с помощью команды ipfw pipe.

ipfw pipe 10 config bw 1Mbit/s

Обр. внимание, что мы сейчас, ис.п одну и ту же команду ipfw pipe. Тем самым мы что сделали: создали трубу под номером 10, у которой пропуск. способность 1 мегабит в секунду. Параметр pipe говорит о том, что мы с помощью утлииты ipfw мы работаем с другим модулем --- dummynet. Посел созд. трубы можно скзать

ipfw add pipe 10 ip from any to any port 80

Пишется для ip, а не для tcp, потому что можно и так, если это tcp и там есть порт, то оно приментся, иначе нет. Это вообще характерно для дружественных польз. фаерволлам. Чем больее друж. к польз., тем более деталей за кадром.

Если у нас происх. соед. с 80 портомЮ то оно немедленно запих. в трубу. Как устроена труба: есть неск. bucket'ов, в которые закладываются пакеты, если не влезает, то ждёт, в зависимости от того, какой рафик, вх. или исх., нам может быть необх. вести по разному, напр., если трафик наш, то ...

Что в этих самых трубах есть примечательного: если мы устроим слишком жестокую трубу и приделаем к ней слишком короткую очередь (есть параметр под названием queue, который опр. сколько паметов может стоять), то пакеты будут пропадать,а это нехорошо. Если у вас большой трафик, то может быть большая потеря пакетов, при этом генер. сообщ. о потере пакетов, но это нехорошо. Особенно плохо, когда труба вроде работает, а потом если вдруг случается резкий наплыв. Но поск. есз саморег, то фиг бы с ним, но при этом трафик только увел., так как нач. обмен об ошибках. Для противод. этому есть алгоритм RED, который при приближении к пропуск. способности канала начинает по-тихоньку терять пакеты. Идлея в том, чтобы не сруз все соединения рушились, а постепенно тлько нек-рые подглюкивали.

Всё, что лектор раньше расск., подразумевает запих. в трубу по правилу. Часто нужно это делать по соединению, например, по мегабиту на соединение, то есть, фактически нужно вернуться к созд. временных правил, точнее труб, каждая из которых заводится в момент начала соед.и исч. с его смертью. Для этого есть опция mask (для ipfw pipe), у которой довольно моного опций, в том числе all, которая говорит, что под каждый отдельный поток будет отдельная труба. Лектор переписывает пример из документации. Трубами можно восп. не для огр., а для того, чтобы его посчитать. Можно сконф. трубу без огр. (ipfw pipe1 config mask all), после чего пропускаете весь трафик (ipfw add pipe tcp|udp|... from any to any), после чего всё работает как работало за одним искл: по каждому соединению считается статистика. Статистику снимает специальный софт.

На самом деле, ipfw это очень низк. инструмент, когда его читаешь, понимаешь, что можно сделать всё, но когда начинаешь делать, понимаешь, что будешь делать неделю.

Помимо труб есть queue (вместе с трубой созд. одна труба), каждую очередь можно сложить в одну трубу, и на каждую очередь можно поставить свой вес. Очереди не приоритетные, а весовые: если вес 2, 2 и 1, это озн., что что на 2 пакета из первой прих. 2 пакета из второй и 1 из третьей.

Чтобы закончить тему, лектор скажет, что не скзал про nat. Помимо natd, в ipfw в 2005 году появилась поддержка nat собственная. Лектор не сказал про транс. адресов, потому что не принято им её делать. Единственное, что там нет — много в много. Обычно nat делается через ipnat, и это так принято.

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

Конспект Kda

В прошлый раз один школьник попросил установить линукс на ноутбук.

Несколько объявлений. Первое. Кто-то должен прочесть лекцию по iptables вместо лектора в следующий раз. Лектор поедет на конференцию и либо ничего не будет, либо по непонятной теме. Это тоже вариант. Желательно предварительно проконсультироваться.

Второе. Требуется преподаватель по курсу Введение в Альтлинукс. Оплата 500 рублей в академический час. Вечером. С 6 до 9. Время уточняется. Курс 72 часа. Шесть часов в неделю нужно работать. Единственное требование — разбираться в предмете.

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

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

Посыл один. Нет программного продукта «Файрволл». Посыл два. Возможно, есть фреймворк «Фильтрация». В этом случае возможно вообразить ситуацию, когда со стороны ядра ОС предусмотрены ручки, с помощью которых можно трафик отдавать фильтрующей штуке. Также должны быть процедуры kernel-уровня (модули). С одной стороны, архитектура ядра, с другой стороны должны быть специальные уровни ядра. Также должны быть утилиты и демоны, управляющие всем этим безобразием. Бывают исключения.

Если мы начинаем читать документацию, увидим, что есть два вида (как минимум) документации.

ipfw. Лектор напоминает, что ipfw имеет линейчатую структуру. Ее достоинство — универсальность, простота. Недостаток — нужно делать структурную нелинейность. Есть специальный goto, с помощью которого можно делать ссылки.

Все сводится к утилизации ipfw. Для добавления пишем просто ipfw add [номер] [свойство] тело. Несколько правил могут иметь один номер. Применяется одно правило одного номера (по порядку добавления, первое применимое). Свойство может быть, например, log, tag#, set#, prob<P>. Вероятность применения правила.

ipfw del # [правило]

ipfw list

ipfw show

В FreeBsd есть 5 точек обработки сетевого трафика. Входящий на уровне интерфейса трафик, на уровне ip, выходящих два уровня и bridge, перекладывающий из одного ethernet в другой. Какие фильтры, свойства указываются в теле? MAC-адрес.

Никакого MAC-адреса нет. Все поля протокола ipv6.

Поля протокола tcp. syn, fin, ...

divert socket. divert state проверяется.

Все что можно ожидать от трафика уровня не выше транспортного. Все это можно прочесть в документации. В прошлый раз был неудачный рассказ про стек ipfw. У нас есть довольно здоровый файрвол. Он работает относительно долго. Файрволы, устроенные по принципу first wins, недетерминированно ест время. Очень много времени ест divert socket, передающий в userspace. Всевозможные пробивки пакета на предмет статуса. Использование tcp. У соединения есть идентификатор (адреса и порты).

Четверка определяет tcp соединение. С некоторой потерей безопасности можно согласиться с тем, что если соединение было установлено и одобрено, то остальные пакеты можно пропустить. Это бывает не всегда, но решение зарубить tcp — все же редкость. Первый пакет довольно долго идет по файрволу, пока не упрется в некоторое правило.

ipfw add allow tcp from mynet to any setup keep-state

Всем рекомендуется почитать man по ipfw. Например, там есть volk.tambov.su. Setup означает, что речь идет о пропуске только начальных пакетов. Можно опустить, тогда все пакеты будут пропущены. Формируется временное правило, записываемое в файрвол. В него записывается четверка, для четверки запоминается тело. По флагу keep-state создается временное правило. Оно живет какое-то время, задается какой-то таймаут. Если случается так, что это правило применяется, то у него время жизни увеличивается. limit ... Оно ограниченного количества раз использования. 10 раз установочный пакет пройдет, 11 раз уже нет.

check-state. Запускается проверка временных правил. Достоинство (очевидное) следующее: можно писать после этого правила deny from any to any, зная, что предыдущее правило все, что нужно, пропустило.

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

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

Это не имеет отношения к NAT, просто возможность не выполнять длинный список правил.

Traffic shaping. В FreeBsd существует несколько вариантов. Что касается ipfw, есть специальный модуль, который отвечает за shaping различными методами.

Когда мы вписываем правила, входящие снаружи не проходят. Исходящие из сети пропускаются, создаются временные правила. Можно выбрасывать соединения established после check-state. Злоумышленник может нагадить прокидыванием невалидных пакетов — пакетов с сеансом без начала.

dummynet. Изображает из себя сеть со всеми параметрами — пропускной способностью и пр. С точки зрения пользователя, это труба, относительно которой можно задать параметры: задержка delay, пропускная способность bw, процент потерь plr. Труба, обладающая ограниченными или неограниченными параметрами. Задержка и пропускная способность имеют смысл в ограничении Интернета до определенных масштабов.

Пользователь должен создать трубу и сконфигурировать ее. С помощью ipfw pipe.

ipfw pipe 10 config bw 1Mbit/s.

Это первая стадия. Параметр pipe говорит о том, что мы работаем с другой подсистемой. В файрвол вставляем

ipfw add pipe 10 ip from any to any port 80.

Файрвол может обрабатывать пакеты в разное время. Может быть MAC адрес, IP адрес и т.п.

Труба. Корзинки. Если нет места, ожидаем. Что может быть нам интересно? Если мы устроим слишком жестокую трубу и приделаем слишком короткую очередь (у самой трубы есть параметр очередь), то пакеты, которые туда не влезают, будут пропадать. Нужно понимать, что если предполагается серьезный трафик, нужно отводить правильный размер очереди. Когда пакет не будет влезать, будет генерироваться ошибка пересылки. А там либо ICMP, либо что-то еще. Если большинство пакетов не лезет в трубу, надо что-то делать. Шейпинг работает, но возникает проблема. Пользователи полезли дружно в Интернет. Их соединения стали резать. Трафик увеличился из-за сообщений об ошибках.

gred. Алгоритм, позволяющий начинать терять пакеты еще до того, как очередь будет забита. Если ниже определенного уровня, ничего не терять. Если выше уровня, начинать случайно терять. Не все рушатся, а только некоторые. Общая картина сбалансирована.

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

ipfw pipe 1 config mask all.

Труба без ограничений, но для каждого из соединений будет создана своя труба.

pipe tcp from any to any.

Все работает, как работало, но по каждой отдельно считается статистика. Сделать можно абсолютно все, но за неделю. В каждую трубу можно забрасывать трафик. Есть ipfw queue, очереди можно сложить в трубу, на каждой очереди поставить вес.

Помимо трубы, к ней привешена одна очередь. Можно привесить несколько очередей. У разных очередей разные веса. Идея в том, что пропускная способность общая на всех.

Не было сказано про NAT. В ipfw2 появилась поддержка NAT в ядре. Трансляция адресов. Не принято пользоваться ipfw для трансляции адресов. С 2005 года появилась поддержка NAT в ядре. Диапазон-диапазон сделать нельзя.

В следующий раз про iptables.