Редактирование: UNИX, весна 2009, 03 лекция (от 11 марта)
Материал из eSyr's wiki.
Внимание: Вы не представились системе. Ваш IP-адрес будет записан в историю изменений этой страницы.
Правка может быть отменена. Пожалуйста, просмотрите сравнение версий, чтобы убедиться, что это именно те изменения, которые вас интересуют, и нажмите «Записать страницу», чтобы изменения вступили в силу.
| Текущая версия | Ваш текст | ||
| Строка 137: | Строка 137: | ||
В след раз про check-state, nat и очереди. | В след раз про check-state, nat и очереди. | ||
| - | |||
| - | |||
| - | |||
| - | '''Конспект Kda''' | ||
| - | |||
| - | Рассказа про iptables не будет. | ||
| - | Рассказ будет про ipfw. | ||
| - | Даже не одна лекция, а несколько. | ||
| - | Очень многие понятия, присущие фарйволу вообще, проще рассматривать не на примере древовидных структур вроде iptables. | ||
| - | Некоторая специфика реализации внутри ipfw зашита глубоко, и очень долго кажется, что сделать можно все. | ||
| - | В случае iptables это не так. | ||
| - | |||
| - | Чтобы было понятно, о чем идет речь. | ||
| - | Само название довольно старое, в том смысле, что функциональность была реализована еще во второй версии freebsd. | ||
| - | Он обладал некоторыми недостатками по сравнению с толстыми файрволами. | ||
| - | Был портирован другой вариант файрвола ipf. | ||
| - | В 2002 появились сразу два новых. | ||
| - | ipfw стал ipfw2. | ||
| - | Пакет ipfilter. | ||
| - | Если не считать других вещей вроде нетграфа, файрволов 3 штуки. | ||
| - | Каждый предполагал покрывать функциональность предыдущих. | ||
| - | Но ipfw2 тоже весьма развесистая штука. | ||
| - | |||
| - | Файрвол имеет строгий список правил, которые применяются к пакету, проходящему через tcp/ip стек, причем сразу в нескольких местах. | ||
| - | Давайте нарисуем картинку. | ||
| - | В мане по ipfw эта картинка есть в аски-арте. | ||
| - | Есть два случая, когда нужно отрабатывать пакеты, исходящие и входящие. | ||
| - | Одни обрабатываются, когда пакет вошел, другие — перед выходом из интерфейса. | ||
| - | Приняли все решения относительно судьбы пакета. | ||
| - | |||
| - | Есть входящий и исходящий поток — ip_in, ip_out. | ||
| - | Вполне возможно, что пакет пройдет на более высокий уровень (транспортный, прикладной). | ||
| - | С более высокими уровнями тоже возможно работать. | ||
| - | Существует еще ethernet уровень. | ||
| - | На вход eth_demix, на выход eth_outp. | ||
| - | Можно включить в ядре опцию bridge, тогда появится еще пятый элемент — собственно bridge. | ||
| - | Интерфейсный уровень работает обычно с bridge. | ||
| - | |||
| - | В чем хитрость линейного файрвола? | ||
| - | На каждом этапе ставится обработка по всей очереди правил, которые сформулированы на этот счет. | ||
| - | Пакет проходит область и прощелкивается в соответствии с правилами файрвола. | ||
| - | |||
| - | Общий формат правил достаточно сложный. | ||
| - | Правила линейчатые и программа немного похожа на программу на бейсике — есть номера строк. | ||
| - | Есть правило делать шаг 100 — в бейсике шаг 10, а в ipfw шаг 100. | ||
| - | При этом одно из правил всегда пробито — 65535, в зависимости от параметров компиляции файрвола. | ||
| - | Частая практика — перекомпиляция ядра с разными ключами. | ||
| - | Либо всех выпустить, либо всех впустить. | ||
| - | Список правил организован по принципу first wins. | ||
| - | Если правил нет, или ни одно не сработало, применяется общее правило — всех убить или всех пропустить. | ||
| - | |||
| - | Примерный вид правила. | ||
| - | Номер, действие, тело. | ||
| - | Правило может выполнять различные действия. | ||
| - | Помимо фильтрации могут быть другие действия — например, пометка пакета. | ||
| - | Проверка внутренних таблиц. | ||
| - | С момента выполнения действия пакеты проверяются на таблицы. | ||
| - | Нельзя определить точно, что есть последняя часть. | ||
| - | Цепочка — действие и условие (ранее рассмотрено). | ||
| - | Тело нельзя называть условием, там много разного. | ||
| - | |||
| - | Самое популярное действие — allow, drop, reject, fwd. | ||
| - | Что касается allow — тело будет условием. | ||
| - | Если при прохождении правил это было первое совпавшее, то пакет просто пропускается. | ||
| - | Если он модифицирован или что-то произошло, значит да. | ||
| - | Давайте посмотрим на drop и reject. | ||
| - | Что касается правила drop, то пакет, попавший под него, просто исчезает. | ||
| - | Чем это плохо? | ||
| - | Это плохо тем, что если мы честные люди, то пакет, который мы не хотим, чтобы он был доставлен, нужно ответить по | ||
| - | ICMP хотя бы unreachable. | ||
| - | Если пользователь запустил программу, ломящуюся по UDP, то если написано drop, то он не будет знать, что они не дошли | ||
| - | и завалит пакетами. | ||
| - | |||
| - | Если же reject, то будет сгенерировано unreachable. | ||
| - | ICMP пакет будет отправлен отправителю. | ||
| - | Если мы защищаемся от атак, то ответов слать не нужно, потому что он плевать хотел на них, а кроме того, | ||
| - | они будут загружать нашу сеть. | ||
| - | |||
| - | fwd. | ||
| - | На выходные пакеты. | ||
| - | Относительно них принято решение о маршрутизации. | ||
| - | fwd это решение меняет. | ||
| - | Оно меняет и пробивает next hop на тот, который мы напишем. | ||
| - | Если машина не настроена на прием пакетов с чужими ip, то она выбросит пакет. | ||
| - | Не обязательно пользоваться для этого более глубинными инструментами. | ||
| - | Пакет не модифицируется. | ||
| - | Это бывает нужно: висит демон, который все пакеты принимает и журнализирует. | ||
| - | |||
| - | 65535 deny ip from any to any | ||
| - | |||
| - | Все, что после deny — тело. | ||
| - | Это правило выбрасывает все отовсюду. | ||
| - | |||
| - | 100 allow ip from any to any via lo0 | ||
| - | |||
| - | lo0 — loopback | ||
| - | |||
| - | Если будем интересоваться, то в freebsd называются интерфейсы по драйверам, а не eth*. | ||
| - | Потом появилось переименование интерфейсов. | ||
| - | |||
| - | Что делает правило? | ||
| - | Кто бы что не пытался пропустить через loopback, пускай шлет. | ||
| - | Есть пример, когда пришедшие пакеты на 127.0.0.1 человек режет. | ||
| - | Если пакет через loopback изнутри, нормально, а вот если снаружи (с нашим маком, но с таким ip — глупая хакерская атака). | ||
| - | |||
| - | 200 deny all from any to 127.0.0.0/8 | ||
| - | |||
| - | Это будет работать, потому что в нормальном режиме до 200 анализатор не дойдет. | ||
| - | Редирект ip нужно сделать так, чтобы принимающая машина нормально приняла пакет с чужим ip. | ||
| - | В принципе слово ip — синоним для all. | ||
| - | Можно написать ip4. | ||
| - | На уровне ipfw мы манипулируем такими пакетами. | ||
| - | Можно написать me — любой их моих адресов, loopback, адреса сетевых карт. | ||
| - | Если речь идет о манипуляции пакетами, то выбор не очень большой. | ||
| - | Пишем тип, откуда, куда, опционально флаги. | ||
| - | |||
| - | NAT — в ipfw не было. | ||
| - | Как изначально был сделан NAT в FreeBSD. | ||
| - | NAT делался в userspace. | ||
| - | Divert socket. | ||
| - | К нему можно забиндиться, но если указать адрес, он проигнорируется. | ||
| - | {divert tee} <ropt> | ||
| - | Перенаправляем в сокет пришедший пакет. | ||
| - | IP-адрес в таком сокете игнорируется. | ||
| - | В userspace запущена программа, которая биндится к сокету, слушает его. | ||
| - | Читает командой receive. | ||
| - | Делает все, что хочет с полученными пакетами, как-то их обрабатывает. | ||
| - | С помощью стандартных команд пишет обратно. | ||
| - | |||
| - | Возможно несколько правил с одним номером для атомарности — удаление всех правил с одним номером. | ||
| - | Правила под одним номером идут в нужном порядке в таблице. | ||
| - | Можно делать что угодно с пакетами, не заморачиваясь написанием ядерного модуля. | ||
| - | Ядерный модуль писать сложнее userspace программы. | ||
| - | Если не забинден сокет, пакет исчезает, ничего плохого не происходит. | ||
| - | Мы записали в сокет, файрволинг идет своим чередом. | ||
| - | Программа прочухивается, пишет обратно. | ||
| - | Пакет возникает. | ||
| - | divert — пакет уйдет и удалится, а если tee — пойдет в обе стороны. | ||
| - | Может быть журнализатор на стороне сокета, а пакет будет обрабатываться дальше. | ||
| - | natd — догадайтесь, что он делает. | ||
| - | Слушает сокеты, вынимает пакеты, умеет все, что должен делать nat. | ||
| - | Он разбирается, в какую сторону натить. | ||
| - | Может быть запущен в режиме входного и выходного ната. | ||
| - | |||
| - | Если мы хотим произвольным образом обрабатывать пакеты, мы можем написать референс, а потом для ускорения сделать | ||
| - | netgraph. | ||
| - | Можно написать что-нибудь на пакете для сведения нетграфа. | ||
| - | netgraph <Надпись> | ||
| - | Нетграф работает очень быстро. | ||
| - | Передача через divert работает достаточно долго. | ||
| - | Понадобился нормальный kernelspace NAT. | ||
| - | Пока интерфейсы были 10 мегабит, проблем не было. | ||
| - | Довольно забавно — у каждого правила есть счетчик, сколько раз оно применялось. | ||
| - | Можно ничего не делать, только считать. | ||
| - | Помимо netgraph есть еще ngtee (то же самое, только шлет дальше). | ||
| - | |||
| - | skipto <номер> | ||
| - | Нужно обеспечить возможность применять куски правил в зависимости от условий. | ||
| - | Можно уйти назад, даже завесить намертво (не выйдет из kernelspace никогда). | ||
| - | Тем не менее, без этой штуки обойтись нельзя. | ||
| - | Все пакеты, проходящие через эти пять точек обрабатываются списком правил. | ||
| - | Есть флаги, которые позволяют определять фильтр. | ||
| - | Здоровенный свод правил, удобно использовать флаги и применять нужные куски правил. | ||
| - | Но это сильно усложняет линейную структуру. | ||
| - | |||
| - | Очень часто из соображений быстродействия полезно делать следующее. | ||
| - | Прогнали пакет по своду правил и решили допускать его и все его класса. | ||
| - | Установление соединения tcp прошло и дальше пускаем все его пакеты. | ||
| - | Во-первых, есть правило checkstate. | ||
| - | У него нет параметров. | ||
| - | Это правило приводит к тому, что все пакеты обрабатываются куском анализа состояний. | ||
| - | Почему правило есть? | ||
| - | Прогонка по всем состояниям — относительно тяжеловесная процедура, и если возможно принять решение до проверки состояний, | ||
| - | лучше это сделать. | ||
| - | Включаем это правило. | ||
| - | Если пакет принадлежит потоку данных с запомненным состоянием, то запомненное правило будет применено. | ||
| - | Рассказ будет продолжен в следующий раз. | ||
| - | Есть набор правил и флаг keep-state. | ||
| - | Если среди списка состояний есть такое, про которое было применено данное правило, оно будет использовано. | ||
| - | Не в таблице дело, а в том, что проверить, что такие пакеты уже пропускались. | ||
| - | Это способ убыстрить файрвол, проверив, не относится ли данный пакет к типу уже проверенных. | ||
| - | Общая идея в том, что мы допускаем пакеты setup в начале сессии и говорим сохранить состояние. | ||
| - | |||
| - | Ограничение трафика. | ||
| - | pipe, queue. | ||
| - | Что делают эти команды? | ||
| - | Подробнее в следующий раз. | ||
| - | Для того, чтобы команда работала, должен быть модуль в ядре. | ||
| - | Вместо отсылки пакетов они засовываются в трубу с соответствующим номером. | ||
| - | Труба — некий конвейер. | ||
| - | У него определенная пропускная способность и другие свойства — процент потери пакетов, длина очереди и пр. | ||
| - | Очередь — другой механизм, нет процента потери пакетов, но есть политики обработки очереди. | ||
| - | У нас на факультете трубы используются для любителей запускать осла на бесконечно большой скорости и с | ||
| - | неограниченным количеством пользователей. | ||
| - | У такого пользователя несколько сотен соединений с большим трафиком на специальный ослиный порт. | ||
| - | Трафик такого пользователя ограничивается специальным каналом для всех таких людей. | ||
| - | Используется труба. | ||
| - | Когда количество мест в очереди заканчивается, то пакеты, которым не хватило места, выбрасываются. | ||
| - | Передергивается tcp. | ||
| - | Очередь — более хитрая. | ||
| - | |||
| - | Основной способ работы файрвола — при прохождении пакеты снабжаются метаинформацией. | ||
| - | В частности, при каждом таком пакете можно сделать ipfw на предмет что с ним делать. | ||
| - | tag # | ||
| - | Приклеить бумажку очередного цвета. | ||
| - | Номера от одного до 65534. | ||
| - | Мы можем навесить метку и потом указать флаг tagging #, то есть если есть бумажка, сделать что-то. | ||
| - | Когда пакет уезжает в divert socket, бумажки снимаются. | ||
| - | А так будет таскать на себе. | ||
| - | |||
| - | Мы можем указать вероятность применения правила. | ||
| - | Правило будет срабатывать не всегда. | ||
| - | Вряд ли оно будет ждать, пока накопится энтропия из /dev/random. | ||
| - | Скорее всего, механизм более простой. | ||
| - | |||
| - | Возможность включать и выключать правила целыми блоками. | ||
| - | Днем политика одна, а ночью совершенно другая, потому что охранники качают специфические фильмы. | ||
| - | Какие интересные флаги есть? | ||
| - | Помимо типа откуда и куда, можно, например, затребовать userid. | ||
| - | Ограничиваем именно конкретного пользователя. | ||
| - | Если с пакетом что-то было — ходил через divert, bridge или еще что-то. | ||
| - | Проверяем, что было с пакетом. | ||
| - | Флаг in, out. | ||
| - | В freebsd есть виртуализация (простая) — jail. | ||
| - | Запуск процесса в ограниченном пространстве, файловом и ограниченном ipc. | ||
| - | Таблица процессов одна, но они изолированы в jail'ах. | ||
| - | Можно проверить, из какого jail пришел пакет. | ||
| - | Флагов очень много. | ||
| - | Можем указать протокол. | ||
| - | Вид ICMP. | ||
| - | Правильная настройка файрвола заключается в затыкании ICMP и разрешении большого числа типов ICMP. | ||
| - | Ограничение количества применений правила к пакетам. | ||
| - | В ipfw2 есть встроенный nat. | ||
| - | Про NAT разговор в следующий раз. | ||
| - | |||
| - | Есть ipfw — замечательная утилита. | ||
| - | Позволяет делать все это из командной строки. | ||
| - | Есть скрипт старта файрвола. | ||
| - | Файрвол открытый всем. | ||
| - | Разрешить все всем и запретить все всем. | ||
| - | Клиентская машина с открытым пингом. | ||
| - | Сервер с открытыми 80 портом или другими. | ||
| - | ipfw предназначена не только для добавления-удаления правил, но и для настройки пайпов, очередей, таблиц. | ||
| - | Таблицы адресов. | ||
| - | В ipfw2 таблица адресов. | ||
| - | Просмотр по таблице имеет логарфмическую сложность. | ||
| - | |||
| - | Чтобы закончить: еще один способ использования сеток. | ||
| - | Два множества правил — текущее и новое. | ||
| - | Текущее — действующее. | ||
| - | Новая выключена. | ||
| - | Когда заводим файрвол, обрабатываются и те правила, и другие. | ||
| - | Модифицируем файрвол, новые таблицы и проверяем новые таблицы. | ||
| - | Мы ничего не меняем, и ситуация пропадания доступа по ssh в свежеисправленном в файрволе почти исключается. | ||
| - | Строим новую таблицу, смотрим, свапаем таблицы. | ||
| - | |||
{{UNИX, весна 2009}} | {{UNИX, весна 2009}} | ||
{{Lection-stub}} | {{Lection-stub}} | ||
