UNИX, весна 2009, 05 лекция (от 25 марта)
Материал из eSyr's wiki.
Лектор расскажет немного про iptables.
До этого мы лсушали про ipfw, это BSD, а в линуксе никакогно ipfw нет, в илнуксе всё по-другому. Точно также, как и в BSD, фильтрация в линуксе может быть разбита на неск. уровней:
- Вся фильтрация происх. в пространстве ядра, поск. выносить её в us клайне накладно. Система фильтрации в linux называется netfilter. iptables лишь один из вариантов реализации настройки его. Был ещё ipchains
- точно также, как в ipfw были divert-сокеты, здесь тоже есть us-фльитрация, тоже в виде сокетов. Кроме того, есть некоторые возм. доступа к настр. стека TCP/IP и netfilter. Доступны он в /proc
Кроме того, в us рабоатют инструменты.
какие задачи решает iptables:
IT — фильтр 2-го, 3-го уровня. Что касается ост. уровней, тут сложнее. Есть зацепки для нижележащих уровней, например, можно узнать mac-адреса. Но для фильтрации на первом уровне есть другие инструменты: arptables и ebtables.
iptables работает в терминах ip. Про то, что внутри пакетов, он может знать, но поск. любое сообщ. внутри пакета может быть разбито произвольно, то целостную инф. iptables получить не может. Есть расширения, позв. искать подстроки в tcp-пакетах, но это не та еиша, где необх. исп. iptables. Для фильтр. на уровне приложений необх. использовать прокси, понимающий соотв. протокол и в нём всё настраивать. В то же время, часто бывает, что для нек-рого взаимодействия по сети кроме как из 4 уровня получить нельзя, например, ftp. FTP использует два соединения, и нам нужна доп. информацуия, чтобы пропустить второе.
При помощи iptables можно настр. фильтрацию без учёта сост. соединения. Сущ. ряд случаев, когда этого либо недост., либо неэффективно, и, также как в ipfw, есть stateful фильтрация, назыв. conntrack.
какие ещё задачи можно решать: packet mangling
Что такое iptables: точно также, как в ipfw, в iptables вся логика фильтрации описывается при помощи набора правил. Правило сост. из двух частей: первая часть — matches, условие, при вып. которого правило срабатывает, и вторая часть — target, то, что делается при вып. условие.
Цели бывают двух видов: те, которые прекращают обр. пакета, и не прекращаются (примеры: drop, log). Часть правил iptables не прерывает выполнение фильтрации, оставляет его в живых.
iptables ---- достаточно модульный firewall, значит. часть даже базовой функциональности вынесена в отдельные подсистемы, в терминах iptables они наз. модулями, и дост. часто, если мы хотим исп. нек-рые условия или цели, то необх. явно сказать, что эти условия или цели отн. к опр. модулю. Это в нек. смысле тоже характеристика правил.
Все ти правила объед. в цепочки. Это примерно то же, что одна большая таблица в ipfw, но цепочек в нём очень много, и логика прохода по цепочкам нетривиальна, в частности, у нас может быть цепочка, одно из правил которой — переход на другую цепочку. То есть, мы брабатываем пакет, и какую-то проверку в таблицу не хзочется: она сложная, состоит из большого количества правил, и если мы будем смотреть на таблицу, то она удет мешать, поэтому хорошо бы вынести эту проверку в отдельную цепочку. точно также, как в прогр. подпрограмму можно как-то назвывать, точно также эти цепочки можно именовать.
Правила в цепочки обр. по одному по алгоритму first wins. Если правило terminating, то обр. пакета в данной цепочке прекратится, иначе продолжится.
Что происх., если ни одно из правил не применилось: если это была вложенная цепочка, то обр. вернётся в род. цепочку, если это одна из стандартных цепочек, то у цепочки есть политика по умолчанию, что делать с пакетом, дял которого не работало ни одно из правил, то можнт быть вердикт как выбросить пакет, так и разрешить его, по аналогии с посл. правилом ipfw.
Теперь начинается самое неприятное: при помощи iptables можно решать ряд задач: фильтрация, трансляция, изм. пакетов. Так как эти задачи специфич. каждая сама по себе, то объед. из все вместе в одну большую таблицу, как это сделано в ipfw, не выгодно с т. з. производительности, так как вполне может быть, что одно из правил будет применяться только для входящих пакетов, то непонятно, зачем его проверять для исходящих пакетов, поэтому держ. одну большую таблицк доаольно накладно. Поэтому хрошо бы задачи несколько разделить, в том числе для того, чтобы аставить пользхователя отдельно опис. трансл., изм., фильтрацию. Для этого сущ. 4 таблицы: filter, nat, mnagle, raw (появилась не так давно, она ост. специфическая; пример, зачем она нужна, лектор покажет позже).
Общая схема: есть три пути пакета: транзитный, входящ., исходящ. . Предлагается след. понимание этой схемы: пакет проходит сначала через цепочки PREROUTING, потом FORWARD, потом POSTROUTING. С этим есть одна единственная проблема: если мы созд. новую цепочку, то мы её созд. в рамках таблицы, и переход из цепочки в цепочку осущ. только в пределах таблицы. Поэтому, совсем забывать про орг. нельзя.
Теперь перейдём к тому, что можно делать в iptables:
Какие виды условий можно задавать: можно задать в качестве условия протокол, к которому относится давнный пакет. Можно в кач. условий исп. адрес или диапазон адресов источника/назначения, можно исп. имена интерфейсов входячщих/исходящих. Тут есть один момент: дело в том, что имя out интерфейса до принятия реш., через какой инт. будет отпр. пакет, неизвестно, поэтому на многие условия в правилах может быть наложено огр., они не все и не всегда могут применяться. Для tcp|udp можно указывать порт, для icmp можно указывать его тип. Что ещё можно в кач. правил использовать: раздличные хар=ки tcp-пакета: его флаги, поля в заголовке. Можно получить инф. о mac-адресе отправителя. Кроме того, можно указывать нек. сложные условия (atddrtype).
Что мы можем делать в пакетами: мы можем скзаать, что либо это ороший пакет (ACCEPT), либо плохой (DROP). Это фильтрация пакетов. Поэтому эти правила имеют смысл в таблице filter, в других таблицах не факт, что оно сработает. В старых версиях iptables был не очень критичен к пользователю, сейчас вот он на это ругается. Кроме просто выбрасывания пакет считается зорошим тоном сообщить о том, что мы не хотим видеть этот пакет по той или иной причине (для этого и нужен ICMP): при помощи REJECT можно сказать, что не так.
Эти три правила заканчивают пакеты в цепочке. Но кроме этого, есть правила для протоколирования: LOG/ULOG. LOG выводит сообщ. ядра, а ULOG выводится более настраиваемо (мы можем вывести не только что пакет прошёл через такое правило с такими характеристиками), и выводим мы их не в syslog, а в сокет, например, это может быть исп. для аккаунтинга.
Ещё есть вердикт TRACE: при прохождении пакета срабатывает
MIRROR: отпр. обратно такой же пакет. Одно время Гоша/Рома рассказывали, что когда они замечали, что кто-то начинал ломать их ssh, то они разворачивали трафик и люди начинали ломать сами себя.
QUEUE: аналог divert socket. Понятно, что копирование в us не есть хорошо, и на них под нагрузкой просаживается производительность.
iptables в качестве statelessfw исп. крайне неэфф. и сложно. Простой пример: кто-то из нашей сети пытается подкл. к хосту вовне. Например, мы разреш. эти подкл.. Но тот хост выключен и в рез-те получается icmp-ответ. Тогда нам необюх. разрешить те или иные сообщ. icmp. Но тогда мы разреш. пропускать произв. icmp-пакеты извне. Следовательно, нужен мезанизм, который позв. понять, что опр. пакет отн. к опр. трафику. Для этого исп. conn. track. У любого пакета есть такая вещь, как STATE. Если уст. новое соед., то fw про него ничего не знает, если это пакет с уст. SYN, то логично предп., что это уст. нового соед. и SYN=NEW. Как понять, что пакет. отн. к сущ. соед: у него STATE=ESTABLISHED. Если соед. отн. к сущ., то у него STATE=RELATED. Эти состояния опр. подсистема conntrack, это отдельный модуль, который может анализировать в том числе ур. приложений (например, для FTP).
Пожтому часто одним из первых правил ставится проверка на state=ESTABLISHED,RELATED и пропуск такизх пакетов
Кроме того, есть пакет patch-o-matic, это набор дополн. функц. к iptables, там есть дополн. модули, которые пред. доп. условия, дополн. targets и дополн. модули для conntrack.
У каждого модуля есть свои ручки, но он также сост. из двух частей: реализ. модуля в kernelspace, и утилита в userspace, которая позв. настр. эту функц.
Все эти моудил выполн. в виде модулей ядра. Если отдельный модуль (напр., для отслеж FTP) не загруж, то эти соед. не будут отслеживаться.
FTP conntrack очень тупой: он считает, что ftp- соед только на 21 порт, и один из параметров модуля — на каких портах нах. ftp-трафик. Эти параметры передаются в момент загрузки модуля.
STATE+INVALID уст. для некорр. пакетов (напр., для новых пакетов со сбр. SYN)
Для протокола udp если вдруг нам приходит пакет на тот адрес, с которого недавно ушёл udp, то мы можем с высокой долей вероятности сказать, что они отн. к одному соед.
Иногда может возн. необх, чтобы система conntrack не отслеж. опр. пакеты. Для этого введена таблица raw: conntrack начяинает работать после неё, и в ней можно указать для опр. пакетов NOTRACK.
Иногда ывает необх. в самом начале произвести сравнр. пакетов с неск. условиями., после чего мы можем понять, что это пакеет опр. типа. Во-первых, может оказаться, что мы не хотим применять его каждый раз, но мы можем выделить отдельную цепочку, в котором происх. возврат в род. цепочку., после этого мы поняли, что это интерес. нас пакет. Вместо того, чтобы проверять это каждый раз, можно пометить пакет неим числовм: MARK. Посел этого в другой таблице/цепочке можно посмотреть, что данный пакет помечен. Тут всё грустнее, чем ipfw, посе. mark только один. Но тут есть хитрость: можно использовать маски при сравнении.
Возникает такая ситуация: мы одни пакет пометили, но хотим помечать не пакеты, а соединения. Для этого сущ. CONNMARK, который хранит отметку в табл. conntrack, и можно специальной проверкой их выявлять.
Как всем этим управляют: самая главная утилита — iptables. Формат её простой: iptalbes [-t table] (по умолчанию filter). Можно:
- Создать цепочку — -N
- Задать политику по умолч.: -P
- Очистить цепочку: -F
- -A — удалить правило
- -D — удалить правило (по спеку или номеру)
- -I — вставить правило в середину
Что такое првавило: [[-m module] [!] match] -j TARGET [--target-options]
- ! — отрицание match
- -m module — явная загрузка модуля, если исп. неядерный match
match'ей может быть много
Пример:
- дропаем всё по умолчанию
- Разр. установленные соед.
- Разрешаем всё на lo
- Разр. входящие на 80 порт
- Исх. установленные разрешаются
- Разр. все исх. с lo
- Разр. исх. на 53, 25 порты (dns, почта)
Для рбаоты со списком правил есть iptables{-save|-restore}
При сохр. iptables-save пишет для цепочек количество прошедших байт через разл. цепочки.
Для включения forwarding необх. включить /proc/sys/net/ipv4/ip_forward
Чем лучше save|restore: оно применяется сразу.
Для того, чтобы посмотреть павила в таблице с номерами: iptables -L -nv --line-numbers . Ключик -v служит для показа доп. параметров, про него не стоит забывать.
Не стоит забывать, что модули iptables/conntrack должны ыть загружены.
Для ipv6 есть ip6tables, он исп. единую инфраструктуру, но чуть-чуть другой.
Ещё есть такой замеч. таргет TCPMSS, про который лектор хочет расск., поск может спасти некое количество нервов. Иногда бывает такая ситуация: есть некий хост, он подключен к интернету, есть интернет-сервер. В случае, если мы скачиваем с сервера что-то маленькое, как только скачиваем что-то болшое, оказывается, что висит, маленькие письма ходят, большие — нет.
Может оказаться так, что если посылаются большие пакеты, то они где-то проходят из-за маленького mtu. В случае eth это 1500, если он в pppoe, то там часть съедается на его заголовки. По идее, нам должно вернуться сообщение fragmentation needed. Но может оказаться так, что до нас он не доходит. Это может быть неприятно, и бороться ним непонятно как. Но в TCP есть специальное поле, MSS (maximum sement size), и та инф., которую мы туда запишем, будет инф. для удалённого узла, какой максимальный размер пакета можно пропускать. На роутере крайне желательно включать такое правило: для tcp-пакетов с SYN|RST SYN прописывать в поле MSS значение (можно указать --clamp-mss-to-pmtu).
Возможности patch-o-matcic:
- Списки портов
- Фильтрация по времени
- Вроятность срабатывания
практ. вся инф. почерпнута из iptables tutorial.
