Редактирование: UNИX, весна 2009, 04 лекция (от 18 марта)

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

Внимание: Вы не представились системе. Ваш IP-адрес будет записан в историю изменений этой страницы.

ПРЕДУПРЕЖДЕНИЕ: Длина этой страницы составляет 34 килобайт. Страницы, размер которых приближается к 32 КБ или превышает это значение, могут неверно отображаться в некоторых браузерах. Пожалуйста, рассмотрите вариант разбиения страницы на меньшие части.

Правка может быть отменена. Пожалуйста, просмотрите сравнение версий, чтобы убедиться, что это именно те изменения, которые вас интересуют, и нажмите «Записать страницу», чтобы изменения вступили в силу.

* '''Диктофонная запись:''' 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.

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

[http://www.manpagez.com/man/8/ipfw/ man ipfw]

[http://bozza.ru/?c=124&p=content man 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. Представьте, что есть здоровый firewall с тысячами правил, и он работает относительно долго.

Вообще, ipfw был создан по принципу 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''' в том, что его достаточно легко за [http://ru.wikipedia.org/wiki/DoS-%D0%B0%D1%82%D0%B0%D0%BA%D0%B0 DoS'ить], если не включена соотв. ручка в ядре. Соотв., созд. много вр. правил и память заканчивается. Здесь помогает слово '''limit''' и специальная. ручка в ядре, которая позволяет этому противодействовать.

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

== Относительно Traffic Shaping ==
Что касается ipfw, есть специальный модуль '''dummynet''', который отвечает за [http://en.wikipedia.org/wiki/Traffic_shaping shaping] разнообразными способами.

Прежде, чем... что происходит, когда вы вписываете эти три правила в фаерволл: никакие входящие 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 pipe 1 config mask 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''', и это так принято.

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

=Конспект Kda=

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

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

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

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

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

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

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

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

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

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.

Пожалуйста, обратите внимание, что все ваши добавления могут быть отредактированы или удалены другими участниками. Если вы не хотите, чтобы кто-либо изменял ваши тексты, не помещайте их сюда.
Вы также подтверждаете, что являетесь автором вносимых дополнений, или скопировали их из источника, допускающего свободное распространение и изменение своего содержимого (см. eSyr's_wiki:Авторское право).
НЕ РАЗМЕЩАЙТЕ БЕЗ РАЗРЕШЕНИЯ ОХРАНЯЕМЫЕ АВТОРСКИМ ПРАВОМ МАТЕРИАЛЫ!

Описание изменений:

Отменить | Справка по редактированию (в новом окне)

Шаблоны, использованные на этой странице:

Получено с http://esyr.org/wiki/UN%D0%98X%2C_%D0%B2%D0%B5%D1%81%D0%BD%D0%B0_2009%2C_04_%D0%BB%D0%B5%D0%BA%D1%86%D0%B8%D1%8F_%28%D0%BE%D1%82_18_%D0%BC%D0%B0%D1%80%D1%82%D0%B0%29

@@ Строка 39: / Строка 39: @@
 ipfw show выводит правила, в том числе и динамические.
-Лектор зачитает вслух, какие свойства можно указывть. Прежде, чем это сделать, лектор хочет напомнить, что во FreeBSD существует 5 точек обработки трафика, из которых они пересылваются на обработку ipfw:
+Лектор зачитате вслух, какие свойства можно указывтьа. Прежде, чем это сделать, лектор напомнить, что во freebsd сущ. 5 точек обр. трафика, из которой они пересылваются на бр. ipfw. Это взодящие на ур. интерфейса, вход. на уровне ip, исх. на уровне ip, исх. на ур. eth и bridge. Соотв., всё это запих. на обр. однй и той же цепочки правил, но можно указать префикс (например, in, out, bridge). что можно, какие свойства ук. в теле:
-* входящие на уровне интерфейса
+* Идент. инт. уровня: мак-адрес, если доступен. Напр., на исх. ip-трафике никакого мака нет.
-* входящие на уровне ip
-* исходящие на уровне ip
-* исходящие на уровне eth
-* bridge
-Соответственно, всё это передается на обработку однй и той же цепочке правил, но можно указать префикс (например, in, out, bridge). Что можно, какие свойства указывать в теле:
-* Идентификатор интерфейсного уровня: мак-адрес, если доступен. Например, на исходящем ip-трафике никакого mac адреса нет.
 * Все поля ipv4/ipv6.
 * Направления

Редактирование: UNИX, весна 2009, 04 лекция (от 18 марта)

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

Просмотры

Личные инструменты

Навигация

инструменты

Разделы

Спецкурсы

9 семестр

7 семестр

5 семестр

3 семестр

Поиск

Инструменты