Редактирование: UNИX, весна 2009, 04 лекция (от 18 марта)
Материал из eSyr's wiki.
Внимание: Вы не представились системе. Ваш IP-адрес будет записан в историю изменений этой страницы.
ПРЕДУПРЕЖДЕНИЕ: Длина этой страницы составляет 33 килобайт. Страницы, размер которых приближается к 32 КБ или превышает это значение, могут неверно отображаться в некоторых браузерах. Пожалуйста, рассмотрите вариант разбиения страницы на меньшие части.
Правка может быть отменена. Пожалуйста, просмотрите сравнение версий, чтобы убедиться, что это именно те изменения, которые вас интересуют, и нажмите «Записать страницу», чтобы изменения вступили в силу.
| Текущая версия | Ваш текст | ||
| Строка 1: | Строка 1: | ||
| - | * '''Диктофонная запись:''' http://esyr.org/lections/audio/uneex_2009_summer/uneex_09_03_18.ogg | ||
| - | |||
Несколько объявлений: | Несколько объявлений: | ||
* Кто может прочесть лекцию по iptables. Если кто-то хочет прочитать лекцию по непонятной теме, то нужно понять её и тоже можно прочитать | * Кто может прочесть лекцию по iptables. Если кто-то хочет прочитать лекцию по непонятной теме, то нужно понять её и тоже можно прочитать | ||
| Строка 13: | Строка 11: | ||
| - | == | + | == польз. инт. == |
| - | + | Лекктор попыытается ответить на вопрос, как это управляется. ipfw, который дост. давно появился в freebsd (в версии 2.0). ipfw имеет линейчатую структуру, каждое правильо говорит, чот с пакетом делать. У такой архитектуры есть дост. и недостаток. Дост --- простота, недостатки --- необходимо делать нелинечатый разл. способами. | |
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
Фактически, всё своидтся к утилите под названием ipfw. Для добавления правлиа пишете | Фактически, всё своидтся к утилите под названием ipfw. Для добавления правлиа пишете | ||
ipfw add [номер] [св-ва] тело | ipfw add [номер] [св-ва] тело | ||
| - | Несколько правил могут иметь один и тот же номер, сортируются они | + | Несколько правил могут иметь один и тот же номер, сортируются они по порядку добавления. Если хотите удалить конкр. правило — не делайте две штуки под одним номером. Далее идут собственно правила, которые бывают разного вида. Здесь может быть всякие дополнительные свойства, дальше собственно тело. Что касается тела, мы с ним в прошлый раз разбирались. |
какие можно написать свойства: | какие можно написать свойства: | ||
* log --- будет залоггировано в сист. журнале | * log --- будет залоггировано в сист. журнале | ||
| - | * set [номер]. Это такое новое введение. В ipfw сделали мнго нововведений, в частности, понятие множества правил. Можно, включать- | + | * set [номер]. Это такое новое введение. В ipfw сделали мнго нововведений, в частности, понятие множества правил. Можно, включать-выкл.-удалять множества целиком. |
* probability --- вероятность. Можно указать вероятность, с которой правило применится. | * probability --- вероятность. Можно указать вероятность, с которой правило применится. | ||
* tag# --- можно пометить правило тегом. Если правило с тегом срабатывает, то этот тег прилипает, и будет с ним висеть, пока оно ходит внутри ядра. | * tag# --- можно пометить правило тегом. Если правило с тегом срабатывает, то этот тег прилипает, и будет с ним висеть, пока оно ходит внутри ядра. | ||
| Строка 32: | Строка 26: | ||
Для того, чтобы удалить правило, нужно сказать | Для того, чтобы удалить правило, нужно сказать | ||
ipfw del # [правило] | ipfw del # [правило] | ||
| - | правило | + | правило позв. удалить конкр. правило в одним и тем же номером |
ipfw ... | ipfw ... | ||
| Строка 39: | Строка 33: | ||
ipfw show выводит правила, в том числе и динамические. | ipfw show выводит правила, в том числе и динамические. | ||
| - | Лектор | + | Лектор зачитате вслух, какие свойства можно указывтьа. Прежде, чем это сделать, лектор напомнить, что во freebsd сущ. 5 точек обр. трафика, из которой они пересылваются на бр. ipfw. Это взодящие на ур. интерфейса, вход. на уровне ip, исх. на уровне ip, исх. на ур. eth и bridge. Соотв., всё это запих. на обр. однй и той же цепочки правил, но можно указать префикс (например, in, out, bridge). что можно, какие свойства ук. в теле: |
| - | + | * Идент. инт. уровня: мак-адрес, если доступен. Напр., на исх. ip-трафике никакого мака нет. | |
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
| - | * | + | |
* Все поля ipv4/ipv6. | * Все поля ipv4/ipv6. | ||
* Направления | * Направления | ||
| Строка 57: | Строка 44: | ||
* Если польз. divert socket, если есть такое место в ФВ, где divert есть, то divert state тоже проверяется --- можно проверить, был пакет через divert пропущен или нет | * Если польз. 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 | 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 kepp-state | ||
| - | Оно означает вот что: в этот момент формируется временное правило, которое | + | Оно означает вот что: в этот момент формируется временное правило, которое откл. в раздел временных правил, там записывается четвёрка отпр. и получателя, и в кач. тела запис. то, что мы указали --- ipfw add allow tcp from mynet to any setup, и на него навеш. идент. соединения. Создаётся временное правило, которое позв. применять это для четвёрки идентификаторов. |
| - | По флагу | + | По флагу keep-state созд. временное правлио, которое в обл. правил будет висеть. Временное правило живёт какое-то время, задаётся оно параметрами ядра, если случается так, что это временное правило применяется, то у него время жизни увеличивается, вместо keep-state мы могли написать limit и какой именно лимит, чтобы указать огр. по количеству использований. Чтобы, например, жти новые соед. 10 установились, а дальше нет. |
Зачем эти правила? Чтобы в начале можно было написать | Зачем эти правила? Чтобы в начале можно было написать | ||
ipfw add checkstate | ipfw add checkstate | ||
| - | В этом месте происх. проверка, не попадает ли этот пакет под некое правило в области временных правил. Если вы в какой-то момент отметили какой-то пакет как опустимый, то все пакеты из этого tcp-соединения будут ещё на этапе | + | В этом месте происх. проверка, не попадает ли этот пакет под некое правило в области временных правил. Если вы в какой-то момент отметили какой-то пакет как опустимый, то все пакеты из этого tcp-соединения будут ещё на этапе checkstate пропущены, если временное правило дожило до этого момента. |
| - | Очевидное | + | Очевидное дост. безобразия следующее: можно писать после этого правила deny tcp from any to any, зная, что те правила, которые выше, всё, что нужно, пропучстило. |
| - | Кроме того, вы можете | + | Кроме того, вы можете рассч. на о, что такого рода правило по расп. пакетов для TCP-сессии будут специфическими (например, setup), поэтому, если checkstate сильно раньше нашего правлиа, то это будет эффективно. |
| - | + | Поск. работа ipfw это факт. выполн. pattern matching, то такая штука востребована. | |
| - | Недостаток | + | Недостаток checkstate в том, что его достаточно легко за dos'ить, если не включена соотв. ручка в ядре. Соотв., созд. много вр. правил и память заканчивается. Здесь помогает слово limit и спец. ручка в ядре, которая позв. этому противодействовать. |
| - | Лектор | + | Лектор обр. внимание, что это не имеет ничего общего с NAT и теми вещами, о которых говорили ранее. Это возм. упростить сам линейчатый фаерволл и ускорить его работу. |
| - | == Относительно | + | == Относительно traffic shaping == |
| - | Что касается ipfw, есть специальный модуль | + | Что касается ipfw, есть специальный модуль dummynet, который отв. за шейпинг разнообр. способом. |
| - | Прежде, чем... что | + | Прежде, чем... что происх, когда вы впис. эти три правила в фаерволл: никакие входящие tcp-соед. не проходят совсем. Все исх. соед. и внутр. сети проходят наружу, таким обр., что созд. временное правило, обр. в checkstate. Есть ещё совет поставить после checkstate deny tcp from any to any established, чтобы оно не доходило до конца, а убивалось раньше. Ибо все валидные соединения пропустит checkstate. |
| - | + | dummynet изображает из себя сеть со всеми её свойствами: пропуск. способсность, потеря пакетов и так далее. С точки зрения польз. это такая руба, отн. которой можно задать параметр, которые лектор уже говорил: | |
* delay -- Задержка | * delay -- Задержка | ||
* bw --- bandwidth | * bw --- bandwidth | ||
* plr -- packet loss rate | * plr -- packet loss rate | ||
| - | Выглядит это примерно | + | Выглядит это примерно след. обр.: с точки зрения польз: создать трубу и сконфигур. её с помощью команды ipfw pipe. |
ipfw pipe 10 config bw 1Mbit/s | 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 | ipfw add pipe 10 ip from any to any port 80 | ||
| - | Пишется для | + | Пишется для ip, а не для tcp, потому что можно и так, если это tcp и там есть порт, то оно приментся, иначе нет. Это вообще характерно для дружественных польз. фаерволлам. Чем больее друж. к польз., тем более деталей за кадром. |
| - | Если у нас | + | Если у нас происх. соед. с 80 портомЮ то оно немедленно запих. в трубу. Как устроена труба: есть неск. bucket'ов, в которые закладываются пакеты, если не влезает, то ждёт, в зависимости от того, какой рафик, вх. или исх., нам может быть необх. вести по разному, напр., если трафик наш, то ... |
Что в этих самых трубах есть примечательного: если мы устроим слишком жестокую трубу и приделаем к ней слишком короткую очередь (есть параметр под названием queue, который опр. сколько паметов может стоять), то пакеты будут пропадать,а это нехорошо. Если у вас большой трафик, то может быть большая потеря пакетов, при этом генер. сообщ. о потере пакетов, но это нехорошо. Особенно плохо, когда труба вроде работает, а потом если вдруг случается резкий наплыв. Но поск. есз саморег, то фиг бы с ним, но при этом трафик только увел., так как нач. обмен об ошибках. Для противод. этому есть алгоритм RED, который при приближении к пропуск. способности канала начинает по-тихоньку терять пакеты. Идлея в том, чтобы не сруз все соединения рушились, а постепенно тлько нек-рые подглюкивали. | Что в этих самых трубах есть примечательного: если мы устроим слишком жестокую трубу и приделаем к ней слишком короткую очередь (есть параметр под названием queue, который опр. сколько паметов может стоять), то пакеты будут пропадать,а это нехорошо. Если у вас большой трафик, то может быть большая потеря пакетов, при этом генер. сообщ. о потере пакетов, но это нехорошо. Особенно плохо, когда труба вроде работает, а потом если вдруг случается резкий наплыв. Но поск. есз саморег, то фиг бы с ним, но при этом трафик только увел., так как нач. обмен об ошибках. Для противод. этому есть алгоритм RED, который при приближении к пропуск. способности канала начинает по-тихоньку терять пакеты. Идлея в том, чтобы не сруз все соединения рушились, а постепенно тлько нек-рые подглюкивали. | ||
| - | Всё, что лектор раньше | + | Всё, что лектор раньше расск., подразумевает запих. в трубу по правилу. Часто нужно это делать по соединению, например, по мегабиту на соединение, то есть, фактически нужно вернуться к созд. временных правил, точнее труб, каждая из которых заводится в момент начала соед.и исч. с его смертью. Для этого есть опция mask (для ipfw pipe), у которой довольно моного опций, в том числе all, которая говорит, что под каждый отдельный поток будет отдельная труба. Лектор переписывает пример из документации. Трубами можно восп. не для огр., а для того, чтобы его посчитать. Можно сконф. трубу без огр. (ipfw pipe1 config mask all), после чего пропускаете весь трафик (ipfw add pipe tcp|udp|... from any to any), после чего всё работает как работало за одним искл: по каждому соединению считается статистика. Статистику снимает специальный софт. |
| - | + | ||
| - | Трубами можно | + | |
| - | + | ||
| - | после чего пропускаете весь трафик | + | |
| - | + | ||
| - | + | ||
| - | На самом деле, ipfw это очень | + | На самом деле, ipfw это очень низк. инструмент, когда его читаешь, понимаешь, что можно сделать всё, но когда начинаешь делать, понимаешь, что будешь делать неделю. |
| - | Помимо труб есть | + | Помимо труб есть queue (вместе с трубой созд. одна труба), каждую очередь можно сложить в одну трубу, и на каждую очередь можно поставить свой вес. Очереди не приоритетные, а весовые: если вес 2, 2 и 1, это озн., что что на 2 пакета из первой прих. 2 пакета из второй и 1 из третьей. |
| - | Чтобы закончить тему, лектор скажет, что не скзал про | + | Чтобы закончить тему, лектор скажет, что не скзал про nat. Помимо natd, в ipfw в 2005 году появилась поддержка nat собственная. Лектор не сказал про транс. адресов, потому что не принято им её делать. Единственное, что там нет — много в много. Обычно nat делается через ipnat, и это так принято. |
| - | + | Соотв., ничего хитрого лектор про нат расск. сейчас не будет, в след. раз про iptables. | |
=Конспект Kda= | =Конспект Kda= | ||
