Редактирование: UNИX, весна 2009, 05 лекция (от 25 марта)
Материал из eSyr's wiki.
Внимание: Вы не представились системе. Ваш IP-адрес будет записан в историю изменений этой страницы.
Правка может быть отменена. Пожалуйста, просмотрите сравнение версий, чтобы убедиться, что это именно те изменения, которые вас интересуют, и нажмите «Записать страницу», чтобы изменения вступили в силу.
| Текущая версия | Ваш текст | ||
| Строка 120: | Строка 120: | ||
практ. вся инф. почерпнута из iptables tutorial. | практ. вся инф. почерпнута из iptables tutorial. | ||
| - | |||
| - | = Конспект Kda = | ||
| - | == Вступление == | ||
| - | Георгий Курячий уехал на конференцию. | ||
| - | Сегодня рассказ про iptables. | ||
| - | |||
| - | Возможно, кто-то по теме знает больше лектора. | ||
| - | Рассказ, что это такое и как работает. | ||
| - | Сегодня, скорее всего, не будет про MAC. | ||
| - | |||
| - | == Что такое iptables? == | ||
| - | До этого мы слушали про ipfw. | ||
| - | Это BSD, а в Linux все по-другому. | ||
| - | Точно так же, как и в BSD, фильтрацию можно разбить на несколько частей. | ||
| - | Фильтрация происходит в пространстве ядра, потому что в userspace это накладно. | ||
| - | Netfilter. | ||
| - | Iptables — одна из реализаций системы реализации в рамках netfilter. | ||
| - | Точно так же, как в ipfw есть divert socket, здесь есть возможность фильтрации в userspace. | ||
| - | |||
| - | Нужно упомянуть, что есть некоторые возможности доступа к настройках стека TCP/IP и netfilter. | ||
| - | В userspace работают инструменты. | ||
| - | Основной — утилита iptables. | ||
| - | Помимо него, некоторые настройки выполняются в файловой системе | ||
| - | /proc/sys/net/ipv{4|6} | ||
| - | |||
| - | == Уровни работы iptables == | ||
| - | Фильтр второго уровня — IP. | ||
| - | Та база, которая работает, т.к. третий уровень достаточно стандартизован, все используют TCP или UDP, | ||
| - | появились и другие протоколы. | ||
| - | На третьем уровне тоже возможна работа. | ||
| - | Касательно других уровней все сложнее. | ||
| - | Мы можем узнать некоторые характеристики пакетов с первого уровня. | ||
| - | Как уже было ранее, iptables не фильтрует на первом уровне, для этого есть arptables, ebtables. | ||
| - | |||
| - | Iptables работает в терминах пакетов ip. | ||
| - | Любое сообщение уровня приложений может быть по-разному разбито на пакеты, | ||
| - | получить целостную информацию iptables не может. | ||
| - | Есть расширения, ищущие подстроки в содержимом пакета, но это не та ниша, где нужно использовать iptables. | ||
| - | Нужно ставить прокси, понимающий конкретный протокол. | ||
| - | В то же время достаточно часто бывает, что некоторое взаимодействие по сети, и информацию получить кроме как с 4 уровня, | ||
| - | нельзя. | ||
| - | Одно соединение для команд управления, а данные по другому соединению. | ||
| - | Файрвол должен разобраться в ftp. | ||
| - | Иначе он должен пропускать все соединения, но среди них могут быть ненужные. | ||
| - | |||
| - | == Connection tracking == | ||
| - | Можно настроить фильтрацию без учета состояния соединения. | ||
| - | Каждый пакет оцениваем и принимаем решение. | ||
| - | Существует ряд случаев, когда этого недостаточно или это неэффективно. | ||
| - | Средства фильтрации есть в iptables. | ||
| - | Есть connection tracking. | ||
| - | |||
| - | == Задачи == | ||
| - | Какие еще задачи? | ||
| - | Были задачи фильтрации, перенаправления, изменения. | ||
| - | Про перенаправление опустим. | ||
| - | Это, скорее всего, тема следующей лекции. | ||
| - | Что касается изменения пакетов, то iptables может вносить изменения, связанные с маршрутизацией. | ||
| - | NAT. | ||
| - | |||
| - | == Правила == | ||
| - | Что такое iptables? | ||
| - | Так же, как и ipfw, вся логика фильтрации описывается с помощью набора правил. | ||
| - | Правило состоит из двух частей. | ||
| - | Первая часть — matching, а вторая часть — то, что делает правило, если сработало условие. | ||
| - | |||
| - | === Виды целей === | ||
| - | Надо отметить, что цели двух видов. | ||
| - | Прекращающие обработку — например, пакет нужно отправить в /dev/null. | ||
| - | Часть правил не прекращает обработку. | ||
| - | Другой пример — нужно сохранить информацию о пакете для статистики. | ||
| - | |||
| - | == Модульность == | ||
| - | Файрвол модульный. | ||
| - | Базовая функциональность вынесена в подсистемы. | ||
| - | Они называются модули. | ||
| - | Достаточно часто, если мы хотим использовать некоторые условия или цели, необходимо сказать, что условия или цели относятся к модулю. | ||
| - | Правила объединяются в цепочки. | ||
| - | Цепочка — то, же что большая таблица в ipfw. | ||
| - | Но цепочек очень много. | ||
| - | Логика прохода пакетов по цепочке нетривиальна. | ||
| - | В частности, у нас может быть цепочка с переходом на другую цепочку. | ||
| - | Обрабатываем пакет и какую-то сложную проверку не хочется вставлять в общую таблицу. | ||
| - | Мы не поймем, если вставить 25 правил, где именно эта проверка. | ||
| - | В такой ситуации хорошо вынести часть проверок в отдельную цепочку и вызывать из основной. | ||
| - | Как в программировании функцию можно вызывать неоднократно, так и здесь | ||
| - | можно вызывать из разных мест. | ||
| - | |||
| - | === Рекурсия === | ||
| - | iptables более линеен. | ||
| - | Было бы странно, если был бы разрешен рекурсивный вызов. | ||
| - | |||
| - | == Работа файрвола == | ||
| - | Работает стратегия first wins. | ||
| - | Если правило сработало и оно является завершающим, то правило применится. | ||
| - | Иначе будет применяться следующее правило. | ||
| - | Правила другой цепочки будут применяться последовательно. | ||
| - | Если обработка дошла до конца и ничего не произошло, то: | ||
| - | если цепочка вложенная, обработка вернется. | ||
| - | Если цепочка основная, то сработает политика по умолчанию. | ||
| - | Может быть выброс пакета, либо его разрешение. | ||
| - | |||
| - | Либо может сработать какое-то из правил, либо вернется в родительскую цепочку. | ||
| - | Можно принудительно вернуться. | ||
| - | |||
| - | == Разделение == | ||
| - | Самое неприятное. | ||
| - | В iptables можно решать разные задачи. | ||
| - | И фильтрация, и изменение полей пакета, и трансляция адресов. | ||
| - | Эти задачи достаточно специфичны каждая сама по себе, и объединять в одну большую таблицу невыгодно с точки зрения | ||
| - | производительности. | ||
| - | Может быть, одно правило применяется только для входящих пакетов. | ||
| - | Зачем его применять для исходящих? | ||
| - | Можно просто поставить одно из условий. | ||
| - | Но держать одну большую таблицу правил может быть сильно накладно. | ||
| - | Эти задачи, по-хорошему, лучше разделить. | ||
| - | Отдельно описывать трансляцию, отдельно модификацию, отдельно фильтрации. | ||
| - | |||
| - | === Таблицы === | ||
| - | Есть 4 таблицы. | ||
| - | Таблица filter, nat, mangle, raw. | ||
| - | Raw — она появилась не так давно и она достаточно специфична. | ||
| - | Пример будет позже. | ||
| - | Mangle — модификация, filter и nat — понятно. | ||
| - | Картинка есть на презентации. | ||
| - | В начале пакет существует в сети. | ||
| - | Он приходит на интерфейс и проходит различные цепочки. | ||
| - | Проходит Prerouting: raw, mangle, nat; routing. | ||
| - | Затем разветвление, потом пути сходятся. | ||
| - | |||
| - | В документации сказано, что есть таблицы, в таблицах есть цепочки. | ||
| - | С одной стороны правильно, с другой стороны сильно путает. | ||
| - | Понять, что как, сложно. | ||
| - | |||
| - | === Понимание Георгия Курячего === | ||
| - | Пакет проходит через цепочки разных таблиц, затем дальше. | ||
| - | Объединение вершин графа по цепочкам. | ||
| - | Есть одна проблема. | ||
| - | Если создаем руками цепочку, мы ее создаем в рамках таблицы. | ||
| - | В одну и ту же цепочку мы можем перейти как из Input, так и из Output. | ||
| - | Забывать про то, что цепочки сгруппированы по таблицам, нельзя. | ||
| - | Отказаться от этого не получается. | ||
| - | |||
| - | == Условия == | ||
| - | Можно задать в качестве условия протокол. | ||
| - | Можно использовать адрес, диапазон адресов источника, назначения. | ||
| - | Имена интерфейсов, с которых пришел пакет. | ||
| - | Имя выходного интерфейса неизвестно. | ||
| - | На многие условия в правилах могут быть наложены ограничения. | ||
| - | Не все и не всегда могут применяться. | ||
| - | |||
| - | Для протоколов TCP, UDP можно указывать порт. | ||
| - | Для ICMP — тип. | ||
| - | Помимо этого, можно указывать не один порт. | ||
| - | Различные характеристики пакета — флаги и т.п. | ||
| - | |||
| - | Есть целое семейство правил, условие с несколькими вариантами. | ||
| - | Нас могут интересовать пакеты, адресованные одному из наших адресов. | ||
| - | Или пакеты, адресованные на unicast/broadcast адрес. | ||
| - | |||
| - | == Правила == | ||
| - | === Accept === | ||
| - | Мы можем сказать, что это хороший пакет. | ||
| - | Фильтрация пакета. | ||
| - | === Drop === | ||
| - | Правило drop имеет смысл в таблице фильтров. | ||
| - | В других таблицах не факт, что оно сработает. | ||
| - | Сейчас как минимум есть ругание на то, что он делается не там. | ||
| - | |||
| - | Передача пакета дальше процессу. | ||
| - | Передача дальше по цепочкам. | ||
| - | |||
| - | === Reject === | ||
| - | Помимо выброса пакета, хорошим тоном считается сообщить тому, кто прислал пакет, что мы не хотим этот пакет видеть. | ||
| - | Для этого используется ICMP. | ||
| - | При помощи reject мы можем сказать host unreachable, network unreachable и пр. | ||
| - | Все три правила прерывают обработку. | ||
| - | |||
| - | === Log, Ulog === | ||
| - | Log — информация. | ||
| - | Ulog — не только вывод информации о пакете с характеристиками, но и вывести первые n байт пакета. | ||
| - | Вывод в специальный сокет, который могут слушать userspace демоны. | ||
| - | Подсчет трафика. | ||
| - | Мониторинг. | ||
| - | При перекидывании пакетов целиком, не факт, что выведутся все пакеты. | ||
| - | |||
| - | === Trace === | ||
| - | Есть замечательное правило Trace. | ||
| - | Можно использовать в raw. | ||
| - | Эта таблица выполняется в самом начале работы, до какой-то другой работы. | ||
| - | Пакет пришел из сети или из локального процесса. | ||
| - | Trace — проходя каждую цепочку, если сработало правило, будет записано в лог. | ||
| - | Если все пакеты, это плохо, а если определенные, то сможем увидеть, как что работает. | ||
| - | |||
| - | === Return === | ||
| - | Возврат из вложенной цепочки. | ||
| - | |||
| - | === Mirror === | ||
| - | Отправляет назад идентичный пакет. | ||
| - | В случае, если они обнаруживают, что кто-то сканирует ssh на серверах, они разворачивают трафик и сканирующий брутфорсит | ||
| - | сам себя. | ||
| - | Там другие механизмы. | ||
| - | В реальной жизни использовать не стоит. | ||
| - | Если будут ддосить, возникнет перегрузка. | ||
| - | |||
| - | Еще одно — аналог divert socket. | ||
| - | Так же, как и в BSD, перехода нет. | ||
| - | |||
| - | === Connection tracking === | ||
| - | iptables как stateless использовать неэффективно и сложно. | ||
| - | Простой пример — кто-то из нашей сети пытается подключиться к хосту. | ||
| - | Мы разрешаем какие-то подключения. | ||
| - | Мы можем сказать, что разрешаем ICMP наружу всегда. | ||
| - | Это нехорошо. | ||
| - | Можем разрешить типа destination host unreachable. | ||
| - | Есть еще некоторое количество ситуаций. | ||
| - | Разрешаем другие типы ICMP. | ||
| - | Разрешаем ото всех всегда, это нехорошо. | ||
| - | Нам нужен какой-то механизм, который бы позволял понять, что входящий пакет относится к нашему трафику. | ||
| - | Для этого используется connection tracking. | ||
| - | У любого пакета есть match state. | ||
| - | В случае нового соединения, про него ничего неизвестно. | ||
| - | Кто-то из нашей сети пытается подключиться. | ||
| - | |||
| - | Когда пойдет пакет назад, как понять, что он относится к установленному соединению? | ||
| - | state established. | ||
| - | Когда приходит пакет, не относящийся к установленному соединению, но он не левый, а ожидаемый. | ||
| - | В iptables есть модуль, который умеет анализировать проходящие пакеты, если пакет ftp, там установление соединения, | ||
| - | то он извлекает информацию и заносит в таблицу информацию. | ||
| - | Если проходит пакет со state established или related, то его пропускаем. | ||
| - | Снижение нагрузки. | ||
| - | |||
| - | === «Ручки» === | ||
| - | У каждого модуля есть свои ручки. | ||
| - | |||
| - | При помощи параметров модуля ядра — еще одна ручка. | ||
| - | Соединения на 21 порт — ftp. | ||
| - | Если есть сервер не на 21 порту, то соединение не пройдет. | ||
| - | |||
| - | Возможность узнать состояние пакета. | ||
| - | Возможность проверить, что данный проходящий пакет принадлежит к сессии, которая описана в таблице. | ||
| - | Для каждого протокола свои таблицы. | ||
| - | Может возникнуть необходимость, чтобы система не отслеживала какие-то пакеты. | ||
| - | Для UDP нет установления соединения. | ||
| - | Если нам приходит пакет, то мы можем предполагать, что это работает прикладной протокол UDP. | ||
| - | И он относится к тому, что мы отправили. | ||
| - | |||
| - | == NOTRACK == | ||
| - | Таблица raw для NOTRACK. | ||
| - | В таблице можем отключить учет пакета в системе connection tracking. | ||
| - | Что еще стоит упомянуть? | ||
| - | В самом начале произвести какие-то сложные сравнения пакета. | ||
| - | Если условие выполнено, то это пакет интересного нам типа. | ||
| - | Мы можем хотеть применять условия каждый раз. | ||
| - | Может быть проверка условий растянута на несколько правил. | ||
| - | Если не является тем-то, тем-то и тем-то, то он нам интересен. | ||
| - | Выделяем в одну цепочку. | ||
| - | |||
| - | Берем и помечаем пакет каким-то числом. | ||
| - | В другой цепочке, в другой таблице при помощи connmark match проверить отметку. | ||
| - | |||
| - | == Метка пакета == | ||
| - | В ipfw пакет можно помечать несколькими тегами. | ||
| - | Здесь только один mark. | ||
| - | mark — 32 разряда. | ||
| - | Если нужно пометить пакет по двум характеристикам, два марка нельзя. | ||
| - | Но мы можем применять некоторую маску и сравнить результаты. | ||
| - | Для остальных пакетов хотим отслеживать изменения. | ||
| - | |||
| - | == Управление == | ||
| - | Самая главная утилита управления — iptables. | ||
| - | iptables [-t table] | ||
| - | Мы можем создать цепочку, применить политику, удалить, посмотреть список правил, добавить правило в цепочку. | ||
| - | См. презентацию. | ||
| - | Удаляются цепочки так же. | ||
| - | Если мы знаем номер правила в цепочке, можно удалить его по номеру. | ||
| - | Можем вставить в середину. | ||
| - | |||
| - | Формат правила см. презентацию. | ||
| - | Пример конфигурации см. презентацию. | ||
| - | |||
| - | В принципе, есть такой хитрый таргет, с помощью которого можем вставить правило в цепочку. | ||
| - | Что это даст? | ||
| - | Он только для того, чтобы в каком-то виде сохранять комментарии. | ||
| - | |||
| - | Надо не забывать, что модули как iptables, так и connection tracking должны быть загружены. | ||
| - | Для ipv6 существует отдельный инструмент ip6tables. | ||
| - | Он использует единую инфраструктуру. | ||
| - | Что-то общее есть, но структура пакетов другая. | ||
| - | По тому, как с ним работать, он похож на iptables. | ||
| - | |||
| - | Может быть еще что-то. | ||
| - | Есть еще немного времени. | ||
| - | |||
| - | == TCPMSS == | ||
| - | Есть target TCPMSS. | ||
| - | Вдруг спасет какое-то количество нервов. | ||
| - | Есть некоторый хост. | ||
| - | Он подключен к Интернет. | ||
| - | Есть сервер. | ||
| - | В случае, если мы скачиваем что-то маленькое, все хорошо. | ||
| - | Если большое, соединение устанавливается и висит. | ||
| - | |||
| - | Это может быть связано с тем, что когда посылаем большие пакеты или приходят, | ||
| - | пакеты не доходят из-за того, что посередине маленький MTU. | ||
| - | Полтора килобайта, а посередине есть MTU 1300. | ||
| - | Большой пакет не пролезет. | ||
| - | Есть такой механизм, как фрагментация. | ||
| - | Но некоторые узлы не умеют выполнять фрагментацию. | ||
| - | Тупые, или считают, что не барское это дело. | ||
| - | |||
| - | Понятно, что пакет не пройдет. | ||
| - | Вернется ICMP сообщение. | ||
| - | Есть аналог с большим пакетом. | ||
| - | Мы умные, и считаем, что все нужно пропускать. | ||
| - | Провайдер же не пропускает входящие ICMP пакеты, говорящие об уменьшении пакетов. | ||
| - | Есть поле MSS. | ||
| - | Maximum segment size. | ||
| - | |||
| - | Та информация, которую запишем — информация об узле, которую будет посылать. | ||
| - | На роутере крайне желательно включать правило. | ||
| - | Для пакетов с флагами syn, rst можно задать поле, описывающее ширину канала. | ||
| - | С этим лектор сталкивался дважды. | ||
| - | |||
| - | На этом все. | ||
| - | |||
| - | == Литература == | ||
| - | Информация почерпнута в основном из iptables tutorial. | ||
| - | Есть старый перевод, тем не менее, в основном актуальный. | ||
| - | Есть man iptables (8). | ||
| - | |||
| - | == Завершение == | ||
| - | В следующий раз будет Георгий Курячий, расскажет про NAT и еще что-нибудь. | ||
| - | |||
{{UNИX, весна 2009}} | {{UNИX, весна 2009}} | ||
{{Lection-stub}} | {{Lection-stub}} | ||
