Редактирование: UNИX, весна 2009, 02 лекция (от 04 марта)
Материал из eSyr's wiki.
Внимание: Вы не представились системе. Ваш IP-адрес будет записан в историю изменений этой страницы.
Правка может быть отменена. Пожалуйста, просмотрите сравнение версий, чтобы убедиться, что это именно те изменения, которые вас интересуют, и нажмите «Записать страницу», чтобы изменения вступили в силу.
| Текущая версия | Ваш текст | ||
| Строка 1: | Строка 1: | ||
| - | [[Изображение:Frbrgeorge_09_03_04.jpg|thumb|320px|Георгий Владимирович Курячий]] | ||
| - | |||
| - | * '''Диктофонная запись:''' http://esyr.org/lections/audio/uneex_2009_summer/uneex_09_03_04.ogg | ||
| - | |||
| - | <gallery> | ||
| - | Изображение:Uneex desk 09 03 04 1.jpg|Схема работа линейного фаерволла, iptables | ||
| - | Изображение:Uneex desk 09 03 04 2.jpg|netgraph (ng) | ||
| - | Изображение:Uneex desk 09 03 04 3.jpg|Схема работа линейного фаерволла, iptables | ||
| - | Изображение:Uneex desk 09 03 04 4.jpg|1st wins vs. last wins | ||
| - | </gallery> | ||
| - | |||
| - | == Вступление == | ||
Лектор пообещал, что разговор про сетевые экраны будет построен по тому же принципу, что и в прошлом семестре — подъем по стеку протоколов. | Лектор пообещал, что разговор про сетевые экраны будет построен по тому же принципу, что и в прошлом семестре — подъем по стеку протоколов. | ||
Но это неправильно. | Но это неправильно. | ||
| Строка 47: | Строка 35: | ||
Это была преамбула. | Это была преамбула. | ||
| - | == Задача управления трафиком == | ||
Каким образом нам решать задачу, какие есть стратегии решения задачи управления трафиком? | Каким образом нам решать задачу, какие есть стратегии решения задачи управления трафиком? | ||
У нас некий общий случай. | У нас некий общий случай. | ||
| Строка 55: | Строка 42: | ||
Какие есть пути решения задачи? | Какие есть пути решения задачи? | ||
| - | |||
| - | == Традиционный путь решения == | ||
Самый традиционный путь состоит в следующем. | Самый традиционный путь состоит в следующем. | ||
Берем все трафики, превращаем в потоки пакетов, возможно, присоединяем дополнительную информацию. | Берем все трафики, превращаем в потоки пакетов, возможно, присоединяем дополнительную информацию. | ||
| Строка 68: | Строка 53: | ||
На основании накопленного принимаем решения, куда как перенаправлять, выбрасывать и прочее. | На основании накопленного принимаем решения, куда как перенаправлять, выбрасывать и прочее. | ||
| - | === Схема общей цепочки === | ||
Первая схема — общей цепочки. | Первая схема — общей цепочки. | ||
Мы знаем несколько файрволлов, которые устроены по такой схеме. | Мы знаем несколько файрволлов, которые устроены по такой схеме. | ||
| Строка 79: | Строка 63: | ||
По тем же канонам функционировал старый линуксовый файрволл ipchains, что-то похожее было. | По тем же канонам функционировал старый линуксовый файрволл ipchains, что-то похожее было. | ||
Каковы очевидные достоинства и недостатки подобного рода организации? | Каковы очевидные достоинства и недостатки подобного рода организации? | ||
| - | |||
| - | ==== Достоинства и недостатки ==== | ||
Начнем с достоинств. | Начнем с достоинств. | ||
Очень мало сущностей. | Очень мало сущностей. | ||
| Строка 118: | Строка 100: | ||
Если пакет 6000 раз прошел через одно правило, он сбрасывался. | Если пакет 6000 раз прошел через одно правило, он сбрасывался. | ||
| - | === Схема нескольких цепочек === | ||
Мы можем сохранить линейность правил, но разбить правила на цепочки и привязать каждую цепочку к обработке той или иной | Мы можем сохранить линейность правил, но разбить правила на цепочки и привязать каждую цепочку к обработке той или иной | ||
жизненной ситуации. | жизненной ситуации. | ||
| Строка 142: | Строка 123: | ||
Части, которые не пересекаются будут достаточно большими. | Части, которые не пересекаются будут достаточно большими. | ||
| - | == Топологический путь решения == | ||
Есть совершенно другая стратегия. | Есть совершенно другая стратегия. | ||
Описанная ранее стратегия — линейная. | Описанная ранее стратегия — линейная. | ||
| Строка 163: | Строка 143: | ||
Он проходит по графу, возможно, пропадает, попав в черную дыру. | Он проходит по графу, возможно, пропадает, попав в черную дыру. | ||
Обработка, преобразования, ограничения. | Обработка, преобразования, ограничения. | ||
| - | |||
| - | === Реализация === | ||
Свободная реализация известна лектору только одна. | Свободная реализация известна лектору только одна. | ||
netgraph (ng). | netgraph (ng). | ||
| Строка 173: | Строка 151: | ||
ng устроен функционально. | ng устроен функционально. | ||
Передачи не происходит, путь превращается в суперпозицию функций. | Передачи не происходит, путь превращается в суперпозицию функций. | ||
| - | |||
| - | === Достоинства и недостатки === | ||
Чем этот подход хорош? | Чем этот подход хорош? | ||
В отличие от непонятно каких правил, есть картина следования пакетов. | В отличие от непонятно каких правил, есть картина следования пакетов. | ||
| Строка 182: | Строка 158: | ||
Но свои задачи решает хорошо и эффективно. | Но свои задачи решает хорошо и эффективно. | ||
| - | + | Совмещенная стратегия. | |
Возможно, даже разрешены циклы. | Возможно, даже разрешены циклы. | ||
Отсылки на сторону внутрь ipfw не включены. | Отсылки на сторону внутрь ipfw не включены. | ||
| Строка 190: | Строка 166: | ||
Это может быть на уровне ядра, но система правил на него не распространяется. | Это может быть на уровне ядра, но система правил на него не распространяется. | ||
| - | === Работа с линейными файрволами === | ||
Как с той же самой проблемой справляются линейные файрволы? | Как с той же самой проблемой справляются линейные файрволы? | ||
Для каждого случая жизни пишется отдельный helper. | Для каждого случая жизни пишется отдельный helper. | ||
| Строка 199: | Строка 174: | ||
Мелких доклеек к iptables довольно много. | Мелких доклеек к iptables довольно много. | ||
| - | == Сравнение == | ||
Если в том же ipfw преобладала практика оформления сторонних модулей по тем же правилам, разницы особо нет. | Если в том же ipfw преобладала практика оформления сторонних модулей по тем же правилам, разницы особо нет. | ||
Есть топология, граф, рассчитанный на обработку. | Есть топология, граф, рассчитанный на обработку. | ||
| Строка 206: | Строка 180: | ||
Линейные модели хороши простотой. | Линейные модели хороши простотой. | ||
| - | == Реальное применение == | ||
Вопрос в том, как этими стратегиями можно воспользоваться. | Вопрос в том, как этими стратегиями можно воспользоваться. | ||
С одной стороны, есть подсистема стека. | С одной стороны, есть подсистема стека. | ||
| Строка 218: | Строка 191: | ||
В разные моменты между разными моментами обработки ядро может захватить управление и посмотреть, как дела. | В разные моменты между разными моментами обработки ядро может захватить управление и посмотреть, как дела. | ||
| - | === Требуемая поддержка со стороны ОС === | ||
Существует три сущности, которые должны быть реализованы в ОС, чтобы она стала межсетевым экраном. | Существует три сущности, которые должны быть реализованы в ОС, чтобы она стала межсетевым экраном. | ||
Разметка проходящих пакетов в соответствии с правилами файрвола. | Разметка проходящих пакетов в соответствии с правилами файрвола. | ||
| Строка 227: | Строка 199: | ||
При изучении линукса мы быстро наткнемся на пакет ebtables. | При изучении линукса мы быстро наткнемся на пакет ebtables. | ||
| - | + | pf. | |
В pf три года назад не было поддержки уровня 2. | В pf три года назад не было поддержки уровня 2. | ||
Сейчас ядерные ручки есть. | Сейчас ядерные ручки есть. | ||
| - | === Стратегии непосредственной работы файрвола === | ||
В случае, когда граф две стратегии. | В случае, когда граф две стратегии. | ||
First wins, last wins. | First wins, last wins. | ||
| - | |||
| - | === First wins === | ||
Файрвол пропускает соединение только из одной подсети или на 80-й порт. | Файрвол пропускает соединение только из одной подсети или на 80-й порт. | ||
Мы пишем пропускать из какой-то сети. | Мы пишем пропускать из какой-то сети. | ||
| Строка 252: | Строка 221: | ||
При сложной задачи правильность расположения правил позволяет экономить ресурсы. | При сложной задачи правильность расположения правил позволяет экономить ресурсы. | ||
| - | === Разрешение установленных соединений === | ||
Можно добавить первое правило, если TCP установлено, всегда его пропускать. | Можно добавить первое правило, если TCP установлено, всегда его пропускать. | ||
До этого уже пропустили пакеты установки соединения. | До этого уже пропустили пакеты установки соединения. | ||
Это сильно повышает работоспособность файрвола. | Это сильно повышает работоспособность файрвола. | ||
| - | |||
| - | === Устройство реальных файрволов === | ||
По принципу first wins устроены ipf, ipfw, iptables. | По принципу first wins устроены ipf, ipfw, iptables. | ||
Исключение — pf, он строит last wins. | Исключение — pf, он строит last wins. | ||
| - | |||
| - | === last wins === | ||
Применяются все правила к каждому пакету. | Применяются все правила к каждому пакету. | ||
В дополнительную информацию вносятся изменения. | В дополнительную информацию вносятся изменения. | ||
| Строка 277: | Строка 241: | ||
Поиск по линейным правилам имеет линейную сложность. | Поиск по линейным правилам имеет линейную сложность. | ||
| - | + | Смешанные стратегии. | |
В first wins файрволах есть возможность вернуть пакет обратно. | В first wins файрволах есть возможность вернуть пакет обратно. | ||
В файрволах last wins есть finally. | В файрволах last wins есть finally. | ||
| - | === Учет трафика === | ||
Что можно сказать еще? | Что можно сказать еще? | ||
Где здесь учет? | Где здесь учет? | ||
| Строка 296: | Строка 259: | ||
Вариант в бсд — сетевой интерфейс, из которого лезет только нужный трафик, а дальше с ним можно делать, что захотим. | Вариант в бсд — сетевой интерфейс, из которого лезет только нужный трафик, а дальше с ним можно делать, что захотим. | ||
| - | + | Таблицы. | |
Поделили трафик на разные виды. | Поделили трафик на разные виды. | ||
Действия должны происходить в разное время. | Действия должны происходить в разное время. | ||
| Строка 308: | Строка 271: | ||
Поскольку люди обсуждают, необходимость обойти возникает. | Поскольку люди обсуждают, необходимость обойти возникает. | ||
| - | + | Резюме. | |
Говоря о задачах преобразования, ограничения, перенаправления трафика, мы касаемся большего, чем iptables. | Говоря о задачах преобразования, ограничения, перенаправления трафика, мы касаемся большего, чем iptables. | ||
Сами файрволы могут быть организованы сильно по-разному. | Сами файрволы могут быть организованы сильно по-разному. | ||
| Строка 316: | Строка 279: | ||
В следующий раз будем говорить о линуксовом файрволе. | В следующий раз будем говорить о линуксовом файрволе. | ||
| - | |||
| - | <div style="font-size:60%"> | ||
| - | == Конспект eSyr == | ||
| - | Какие существуют стратегии решения задач ограничения-перенаправления-изменения: | ||
| - | |||
| - | Есть чёрный ящик, в него входят несколько потоков, несколько выходит, и есть чёрный ящик, который выполняет это преобразование. Эти потоки бывают разные, интерфейсы там, туннелируемы потоки и так далее. | ||
| - | |||
| - | Какие есть здесь пути решения задачи: можно взять перемешать все данные, превратить в потоки пакетов, к каждомцу присоед. дополнительную информцию. При этом важно, что всё это условно: под данными понимается | ||
| - | |||
| - | ... | ||
| - | |||
| - | Достоинства очевидны: способ обработки этих потоков аб. унифицирован, что хотим, то и делаем. Самым линейным был именно ipfw, но всё равно это такая идея, чтобы все пакеты обр. по очереди. Второе достоинство: если предусм. среди униф. набора дост. большой выбор возм. по огр-модиф-преобр, то факт. будет такой конструткор, с помощью которого кажется мождно решить что угодно. Потом, правда, выясн., что это не так: недост. принимать решения, что делать с трафиком, недост. содерж. инф. поля в приезж. пакете. То есть, нельз исп. конеч. автомат без сохр. сост. Типичный пример, где необх. сохр. сост. --- NAT. | ||
| - | |||
| - | Когда к нам призодит пакет, явлю ответом на пакет, пропущ. через нат (неважно, на каком уровне --- ICMP, TCP,...), и по этим правилам соверш. обр. подст. ip-адреса. Что это значит: где-то в строке этой замеч. красивой лин. системы должна быть спец. таблица, в которую модули по преобр. закл. информацию, а потом, когда настанет время преобр. пакет потенц. явл. ответом, другой модуль должен прийти, проск. табличку и на основании этого произвести или не произв. обр. замену. Примеро много. | ||
| - | |||
| - | Получается довольн. сложная структура, и это недостаток. Недостаток в том, что глядя на линию команд, сложно понять, что происх, поск. поведение команд зависит от того, что записано в табличке. Второй недост.Н: хорошифй фаервол делает много чего сразу, и прапвила того же ipfw могут исчисл. тысячами. Поэтому, сказав ipfw -L, вы увидите тысячу строк и ничего не поймёте. Поэтому каждый администратор пишет себе оболочку на перле, котрая делает то, что ему нужно. Проблема в ом, что все команды свалены в одну кучу. | ||
| - | |||
| - | Третий ндеостаток: если хотим делать сложную обработку пакета, циклы, то отловить вечный цикл в такой обр. --- занятие трудное. | ||
| - | |||
| - | В течение пары лет в ipfw существовала ошщибка, приводившая к появл. беск. цикла, даже если команды были правильные. | ||
| - | |||
| - | Что мы можем сделать, чтобы упр. эту стратегию: можем сохр. линейность правил, но разбить эти правила на цепочки, и привяз. каждую цепочку к обр. той или иной жизненно необх. ситуации. Пример: как то сделано в iptables. | ||
| - | |||
| - | Идея ipt следующая: мы рассм. три разных пути пакета: | ||
| - | * Транзитные: какой-то пакет пришёл с инт., и ушёл через какой-то | ||
| - | * Нам предназначающиеся, входящие | ||
| - | * Исходящие. Те, котрые мы сами сгенерировали. | ||
| - | |||
| - | Этитри пути очень сильно отлич. и вполне нормально для каждого из трёх путей сделать отдельные цепочки. В iptables сделано ещё более хитро: (картинка) | ||
| - | |||
| - | Это ниесильно отл. от того, что мы сейчас рассказали, за искл. одного: если бы мы взяли и расск. в пять цветов те правила, которые имеем в ipf, то получили бы ту же картинку. | ||
| - | |||
| - | Но, есть соверш. другая стратегия: назовём её топологической. Вот эта стратегия линейная. Мы берём и придумываем на азные случаи жизни модули-обработчики. Например, модуль абстрактный, проебр. pppoe: Входит ему eth, а из него исх. раздетый eth, поделенный в соотв. с каналом и пригодный для дальн. исопльзования. Или, у нас есть какой-нибудь хитрый модуль, который позв. по любому асинхр. каналу выковыривать трафик, пригодный для передачи по ppp. Ну или ещё десятка полтора подобного рода узлов. После чего мы все эти узлы, классы узлов, заводим нужно количество экз. каждого класса, соед. в граф, специфицируем входящие и исходящие узлы, и где-то в конце концов ... . Лектор знает только одну реализацию: netgraf, ng, используемый в freebsd. | ||
| - | |||
| - | почему ектор хотел нзазвать этот подход функциональным: потому что никакой передачи данных не происходит, происходит посл. применение функций, как в лиспе. | ||
| - | |||
| - | Чем этот подход хорош: вместо 1000 непонятных правил есть каритна следования пакетов. | ||
| - | |||
| - | Чем это плохо: эта структура плохо справляется с задачей произв. фильтрации пакетов. Чтобы справляться с произволной, нужно в качестве одного из узлов вставить рассмотреннее ранее штуку. | ||
| - | |||
| - | Поэтому ng не является полноценным фаерволлом для всего, но свои задачи решает намного эффективнее. Это, кстати нормальная ситуация для freebsd, когда одна задача может решаться неск. способами. | ||
| - | |||
| - | Помимо этотго есть ещё совмешённые стратегии. Лектор специально не написал ipfw, поск. он работает по совм. стратегии. ipfw работает по линейной стратегии, в которой разреш. циклы. Но вот такого рода отсылки на сторону внутри ipfw не включены вообще. Там введено понятие ... socket, и внутрь самого ipfw не вставлены возм. специфицир обр. обр. пакет, но есть возм. вставить сокет, который позв. отдать пакет в юзерспейс, который обр. его, передаст преолбр. обратно и он дальше так и пойдёт. То есть все откл. делаются с помощью сторонних вещей. Главное, что линейная система правил на него, сторонний модуль, не распространяется. Так, например, работает NAT, запускается natd и он осущ. соотв. преобразование. | ||
| - | |||
| - | Как с той же самой проблемой справляются линейне фаерволлы: приходится для каждого слуая жизни писать специальный хелпер, модуль ядра, оформленный с соотв. правилами, который решает одну задачу. Например, чтобы FTP работал за NAT: есть такая штука, как ftp helper, котораяпозв. распознать ftp трафик, и поск. есть условия, то можно что-то делать. Это именно хелпер, очередной модуль, который ещё одним способом обрабатывает и | ||
| - | |||
| - | .... | ||
| - | |||
| - | Что касается моедлей типа iptables, поскольку в них проще разобраться. | ||
| - | |||
| - | Теперь айдём с другой тсороны к этому делу: как жто должно быть реализовано, как этим воспользоваться. Есть система TCP/ip стека, которая пропускает через чсебя пакеты. Чтобы фаерфолл заработал, все пакеты должны изначально обл. не только инф. о том, что это за пакеты, но и доп. информация. Например, собрали ядро без поддержки фаерволов, тогда пакеты ходят чуть быстрее, но совсем голые. Если собрать с поддержкой всех трёх фаерволлов, то произв. немного упала, но зато можно встраивать разные правила. | ||
| - | |||
| - | Тем самым, сущ. три сущности, которые должны быть реализ. в ОС общего назначения: | ||
| - | * Разщметка пробегающих пакетов в соотв. с правилами фаерволла | ||
| - | * Отсылки к фаерволлу в процессе обр. пакета | ||
| - | * userspace-утилита, позв. этим безобразием управлять | ||
| - | Нет, скажем так, такого инструмента, именно потому, что эта такая сложная структура. | ||
| - | |||
| - | Почемул ектор про это вообще вспомнил: потому что если вы начнёте разбираться, как сделать фаервол, то довольно быстро упрётесь в ebtables. И он оперирует теми же сущностями. ... дальше api уже готово. | ||
| - | |||
| - | То же самое относится к тому же pf. Например, три года назад вообще не было поддержки со стороны ядра . | ||
| - | |||
| - | В том же ng ручки, которые управляют фаерволллом на уровне два, есть. | ||
| - | |||
| - | Осталось только последнюю вещь проговорить, и введение будет закрыто: вещь довольно смешная. В случае, когда у нас граф, поведение очевидно. В случае, когда цепочка правил, есть две стратегии: | ||
| - | * 1 wins | ||
| - | * last wins | ||
| - | что лектор имеет в виду: предположим, вы хотите устроить фаерволл, который пропускает вход. соед. только из, допустим, опр. подсети, или только на 80 порт для всех. Что пишете согл. стр. 1 wins: | ||
| - | # пропускать из опр. сети | ||
| - | # Пропускать на 80 порт отовсюду | ||
| - | # Никого не пропускать | ||
| - | Правила обр. начиная с первого, если условие собл., то обр. останавливается. Из этого следует, что цепочки, орг. по правилу 1st wins должны сост. из условия и действия. | ||
| - | |||
| - | Чем стратегия 1st wins хороша: в случае, когда много усл., надо применить их все, а тут же можно сделать так, что наиболее чатсо втсреч. трафик обр. быстрее. | ||
| - | |||
| - | Один из способов ускорить работоспособ. работы фаерволла --- пропускать все уже уст. соединения. | ||
| - | |||
| - | Все указанные фаерволлы: iptablef, ipfw... работают по правилу 1st wins | ||
| - | |||
| - | Единст. исключение, это pf, который устроен след. способом: правило что-то вписывают, вписывают, и что там останется, то и будет использоваться. Соответственно, правила будут звучать сле. образом: | ||
| - | * Не пропускать | ||
| - | * Пропускать из подсети | ||
| - | * Пропускать на 80 порт | ||
| - | |||
| - | Очевидный недостаток: каждый раз надо применять весь корпус парвил. Этот недостаток есть палка о двух концах, поск. если орг. сложный фаерволл по правилу 1st wins, то вы не знаете, сколько времени он буте там скитаться. Есди же вы пишете фаерволл, то позаботитесь о том, чтобы оно работало не склишком медленно. Например, не пи шется куча правил "убить, если из такой-то подсети", есть одно правило, убить если подсеть есть в данной таблице (поиск в таблице логарифмич., хождение оп ей линейно) | ||
| - | |||
| - | Возм. смеш. стратегия: в фаерволлах типа 1st wins можно делать переходы, и в фаерволлах типа last wins можно указать finally. | ||
| - | |||
| - | Вопрос, где же здесь учёт? Формально, это не тема межсетевого экранирования, но фаерволл должен иметь средства отдачи подобной информации, счётчиков. В ng есть просто специальный модуль, в линейных фаерволлах есть спец. правила, и надо понимать, куда их ставить. | ||
| - | |||
| - | Вообще говоря, можно в этом месте про учёт остановиться: все данные есть, как их учитывать, зависит от вашей политики. | ||
| - | |||
| - | В слдучае, если у вас фаерволл устроен по принципу last wins: эти счётчики могут жить в конце, кроме того во freebsd есть замечательный интерфейс под названием pflog, куда мождно дулбировать все пакеты, которые необх. учитывать. Зачем плодить сущности? Нужен учёт пакетов, есть интерфейс, из которого лезет весь этот трафик, и учитываете его сколько угодно. | ||
| - | |||
| - | Осталось 5 минут на то, чтобы вспомнить про таблицы: даже в ситуации, когда поделили наш набор правил на 5 случаев, можно выделить случаи, когда нам нужно делать разное. Логично их группировать. | ||
| - | |||
| - | Иногда эта невозможно прямо здесь и сейчас применить необх. правило смущает. | ||
| - | |||
| - | Пример, когда нам нужно это: проанализировать пакет до ната и посчитать его. | ||
| - | |||
| - | Говоря о задачах огр. и перенапр. трафика, мы кас. гораздо более широкого класса программ, чем iptables. Сами по себе фаерволлы как прогр. инстр. преобр. тарфика могут быть орг. по-разному, у каждлого вида есть свои дост. и недостатки (поэтому у bsd есть три фаерволла). Фаерволл как правило вкл. три компонента: поддержка метаины. внутри стека, ручки внутри стека для обр. пакета и us-команды, тилиты, позв. модиф. команды фаерволла. | ||
| - | |||
| - | В след. раз начнём говортиь о каком-нибудь из описанных фаерволлов. | ||
| - | </div> | ||
{{UNИX, весна 2009}} | {{UNИX, весна 2009}} | ||
{{Lection-stub}} | {{Lection-stub}} | ||
