Текст книги "Iptables Tutorial 1.1.19"
Автор книги: Oskar Andreasson
Жанр:
ОС и Сети
сообщить о нарушении
Текущая страница: 2 (всего у книги 14 страниц)
RedHAt 7.1, с установленным ядром 2.4.x уже включает предустановленные netfilter и iptables. Однако, для сохранения обратной совместимости с предыдущими дистрибутивами, по умолчанию работает пакет ipchains. Сейчас мы коротко разберем – как удалить ipchains и запустить вместо него iptables.
ПРИМЕЧАНИЕ: Версия iptables в Red Hat 7.1 сильно устарела и, наверное неплохим решением будет установить более новую версию.
Для начала нужно отключить ipchains, чтобы предотвратить загрузку соответствующих модулей в будущем. Чтобы добиться этого, нам потребуется изменить имена некоторых файлов в дереве каталогов /etc/rc.d/. Следующая команда, выполнит требуемые действия:
chkconfig –level 0123456 ipchains off
В результате выполнения этой команды, в некоторых именах ссылок, указывающих на файлы в каталоге /etc/rc.d/init.d/ipchains, символ S (который сообщает, что данный сценарий отрабатывает на запуске системы) будет заменен символом K (от слова Kill, который указывает на то, что сценарий отрабатывает, при завершении работы системы. Таким образом мы предотвратим запуск ненужного сервиса в будущем.
Однако ipchains по-прежнему остаются в работе. Теперь надо выполнить команду, которая остановит этот сервис:
service ipchains stop
И в заключение необходимо запустить сервис iptables. Для этого, во-первых, надо определиться с уровнями запуска операционной системы, на которых нужно стартовать этот сервис. Обычно это уровни 2, 3 и 5. Об этих уровнях мы знаем:
2. Многопользовательский режим без поддержки NFS или то же самое, что и 3, но без сетевой поддержки.
3. Полнофункциональный многопользовательский режим.
5. X11. Данный уровень используется для автоматической загрузки Xwindows.
Чтобы запустить iptables на этих уровнях нужно выполнить команду:
chkconfig –level 235 iptables on
Хочется упомянуть об уровнях, на которых не требуется запуска iptables: Уровень 1 – однопользовательский режим работы, как правило используется в экстренных случаях, когда мы «поднимаем» «упавшую» систему. Уровень 4 – вообще не должен использоваться. Уровень выполнения 6 – это уровень остановки системы при выключении или перезагрузке компьютера.
Для активации сервиса iptables подадим команду:
service iptables start
Итак, мы запустили iptables, но у нас пока еще нет ни одного правила. Чтобы добавить новые правила в Red Hat 7.1 можно пойти двумя путями, во-первых: подправить файл /etc/rc.d/init.d/iptables, но этот способ имеет одно негативное свойство – при обновлении iptables из RPM-пакетов все ваши правила будут утеряны, а во-вторых: занести правила и сохранить их командой iptables-save, сохраненные таким образом правила будут автоматически восстанавливаться при загрузке системы.
В случае, если вы избрали первый вариант установки правил в iptables, то вам необходимо занести их в секцию start сценария /etc/rc.d/init.d/iptables (для установки правил при загрузке системы) или в функцию start(). Для выполнения действий при остановке системы – внесите соответствующие изменения в секцию stop) или в функцию stop(). Так же не забудьте про секции restart и condrestart. Хочется еще раз напомнить, что в случае обновления iptables из RPM-пакетов или через автоматическое обновление по сети, вы можете утерять все изменения, внесенные в файл /etc/rc.d/init.d/iptables.
Второй способ загрузки правил предпочтительнее. Он предполагает следующие шаги. Для начала – запишите правила в файл или непосредственно, через команду iptables, смотря что для вас предпочтительнее. Затем исполните команду iptables-save. Эта команда эквивалентна команде iptables-save > /etc/sysconfig/iptables. В результате, весь набор правил будет сохранен в файле /etc/sysconfig/iptables, который автоматически подгружается при запуске сервиса iptables. Другим способом сохранить набор правил будет подача команды service iptables save, которая полностью идентична вышеприведенной команде. Впоследствии, при перезагрузке компьютера, сценарий iptables из rc.d будет выполнять команду iptables-restore для загрузки набора правил из файла /etc/sysconfig/iptables.
И наконец, в завершение установки, неплохо было бы удалить старые версии ipchains и iptables. Это необходимо сделать для того, чтобы система не «перепутала» старый пакет iptables с вновь установленным. Удаление старого пакета iptables необходимо произвести только в том случае, если вы производили установку из исходных текстов. Дело в том, что RPM пакеты устанавливаются в несколько иное место нежели пакеты, собранные из исходных текстов, а поэтому новый пакет не «затирает» старый. Чтобы выполнить деинсталляцию предыдущей версии iptables выполните следующую команду:
rpm -e iptables
Аналогичным образом удалим и ipchains, поскольку оставлять этот пакет в системе более нет никакого смысла.
rpm -e ipchains
Глава 3. Порядок прохождения таблиц и цепочек
В этой главе мы рассмотрим порядок прохождения таблиц и цепочек в каждой таблице. Эта информация будет очень важна для вас позднее, когда вы начнете строить свои наборы правил, особенно когда в наборы правил будут включаться такие действия как DNAT, SNAT и конечно же TOS.
3.1. Общие положения
Когда пакет приходит на наш брандмауэр, то он сперва попадает на сетевое устройство, перехватывается соответствующим драйвером и далее передается в ядро. Далее пакет проходит ряд таблиц и затем передается либо локальному приложению, либо переправляется на другую машину. Порядок следования пакета приводится ниже:
Таблица 3-1. Порядок движения транзитных пакетов
(Шаг – Таблица – Цепочка – Примечание)
Шаг: 1
Таблица: –
Цепочка: –
Примечание: Кабель (т.е. Интернет)
Шаг: 2
Таблица: –
Цепочка: -
Примечание: Сетевой интерфейс (например, eth0)
Шаг: 3
Таблица: mangle
Цепочка: PREROUTING
Примечание: Обычно эта цепочка используется для внесения изменений в заголовок пакета, например для изменения битов TOS и пр..
Шаг: 4
Таблица: nat
Цепочка: PREROUTING
Примечание: Эта цепочка используется для трансляции сетевых адресов (Destination Network Address Translation). Source Network Address Translation выполняется позднее, в другой цепочке. Любого рода фильтрация в этой цепочке может производиться только в исключительных случаях
Шаг: 5
Таблица: –
Цепочка: -
Примечание: Принятие решения о дальнейшей маршрутизации, т.е. в этой точке решается куда пойдет пакет – локальному приложению или на другой узел сети.
Шаг: 6
Таблица: mangle
Цепочка: FORWARD
Примечание: Далее пакет попадает в цепочку FORWARD таблицы mangle, которая должна использоваться только в исключительных случаях, когда необходимо внести некоторые изменения в заголовок пакета между двумя точками принятия решения о маршрутизации.
Шаг: 7
Таблица: Filter
Цепочка: FORWARD
Примечание: В цепочку FORWARD попадают только те пакеты, которые идут на другой хост Вся фильтрация транзитного трафика должна выполняться здесь. Не забывайте, что через эту цепочку проходит траффик в обоих направлениях, обязательно учитывайте это обстоятельство при написании правил фильтрации.
Шаг: 8
Таблица: mangle
Цепочка: POSTROUTING
Примечание: Эта цепочка предназначена для внесения изменений в заголовок пакета уже после того как принято последнее решение о маршрутизации.
Шаг: 9
Таблица: nat
Цепочка: POSTROUTING
Примечание: Эта цепочка предназначена в первую очередь для Source Network Address Translation. Не используйте ее для фильтрации без особой на то необходимости. Здесь же выполняется и маскарадинг (Masquerading).
Шаг: 10
Таблица: –
Цепочка: -
Примечание: Выходной сетевой интерфейс (например, eth1).
Шаг: 11
Таблица: –
Цепочка: -
Примечание: Кабель (пусть будет LAN).
Как вы можете видеть, пакет проходит несколько этапов, прежде чем он будет передан далее. На каждом из них пакет может быть остановлен, будь то цепочка iptables или что либо еще, но нас главным образом интересует iptables. Заметьте, что нет каких либо цепочек, специфичных для отдельных интерфейсов или чего либо подобного. Цепочку FORWARD проходят ВСЕ пакеты, которые движутся через наш брандмауэр/ роутер. Не используйте цепочку INPUT для фильтрации транзитных пакетов, они туда просто не попадают! Через эту цепочку движутся только те пакеты, которые предназначены данному хосту!
А теперь рассмотрим порядок движения пакета, предназначенного локальному процессу/приложению:
Таблица 3-2. Для локального приложения
(Шаг – Таблица – Цепочка – Примечание)
Шаг: 1
Таблица: –
Цепочка: -
Примечание: Кабель (т.е. Интернет)
Шаг: 2
Таблица: –
Цепочка: -
Примечание: Входной сетевой интерфейс (например, eth0)
Шаг: 3
Таблица: mangle
Цепочка: PREROUTING
Примечание: Обычно используется для внесения изменений в заголовок пакета, например для установки битов TOS и пр.
Шаг: 4
Таблица: nat
Цепочка: PREROUTING
Примечание: Преобразование адресов (Destination Network Address Translation). Фильтрация пакетов здесь допускается только в исключительных случаях.
Шаг: 5
Таблица: –
Цепочка: -
Примечание: Принятие решения о маршрутизации.
Шаг: 6
Таблица: mangle
Цепочка: INPUT
Примечание: Пакет попадает в цепочку INPUT таблицы mangle. Здесь внесятся изменения в заголовок пакета перед тем как он будет передан локальному приложению.
Шаг: 7
Таблица: filter
Цепочка: INPUT
Примечание: Здесь производится фильтрация входящего трафика. Помните, что все входящие пакеты, адресованные нам, проходят через эту цепочку, независимо от того с какого интерфейса они поступили.
Шаг: 8
Таблица: –
Цепочка: -
Примечание: Локальный процесс/приложение (т.е., программа-сервер или программа-клиент)
Важно помнить, что на этот раз пакеты идут через цепочку INPUT, а не через FORWARD.
И в заключение мы рассмотрим порядок движения пакетов, созданных локальными процессами.
Таблица 3-3. От локальных процессов
(Шаг – Таблица – Цепочка – Примечание)
Шаг: 1
Таблица: –
Цепочка: -
Примечание: Локальный процесс (т.е., программа-сервер или программа-клиент).
Шаг: 2
Таблица: –
Цепочка: -
Примечание: Принятие решения о маршрутизации. Здесь решается куда пойдет пакет дальше – на какой адрес, через какой сетевой интерфейс и пр.
Шаг: 3
Таблица: mangle
Цепочка: OUTPUT
Примечание: Здесь производится внесение изменений в заголовок пакета. Выполнение фильтрации в этой цепочке может иметь негативные последствия.
Шаг: 4
Таблица: nat
Цепочка: OUTPUT
Примечание: Эта цепочка используется для трансляции сетевых адресов (NAT) в пакетах, исходящих от локальных процессов брандмауэра.
Шаг: 5
Таблица: Filter
Цепочка: OUTPUT
Примечание: Здесь фильтруется исходящий траффик.
Шаг: 6
Таблица: mangle
Цепочка: POSTROUTING
Примечание: Цепочка POSTROUTING таблицы mangle в основном используется для правил, которые должны вносить изменения в заголовок пакета перед тем, как он покинет брандмауэр, но уже после принятия решения о маршрутизации. В эту цепочку попадают все пакеты, как транзитные, так и созданные локальными процессами брандмауэра.
Шаг: 7
Таблица: nat
Цепочка: POSTROUTING
Примечание: Здесь выполняется Source Network Address Translation. Не следует в этой цепочке производить фильтрацию пакетов во избежание нежелательных побочных эффектов. Однако и здесь можно останавливать пакеты, применяя политику по-умолчанию DROP.
Шаг: 8
Таблица: -
Цепочка: -
Примечание: Сетевой интерфейс (например, eth0)
Шаг: 9
Таблица: -
Цепочка: -
Примечание: Кабель (т.е., Internet)
Теперь мы знаем, что есть три различных варианта прохождения пакетов. Рисунок ниже более наглядно демонстрирует это:
Этот рисунок дает довольно ясное представление о порядке прохождения пакетов через различные цепочки. В первой точке принятия решения о маршрутизации (routing decision) все пакеты, предназначенные данному хосту направляются в цепочку INPUT, остальные – в цепочку FORWARD.
Обратите внимание также на тот факт, что пакеты, с адресом назначения на брандмауэр, могут претерпеть изменение сетевого адреса назначения (DNAT) в цепочке PREROUTING таблицы nat и соответственно дальнейшая маршрутизация в первой точке будет выполняться в зависимости от произведенных изменений. Запомните – все пакеты проходят через таблицы и цепочки по тому или иному маршруту. Даже если выполняется DNAT в ту же сеть, откуда пакет пришел, то он все равно продолжит движение по цепочкам.
СОВЕТ: В сценарии rc.test-iptables.txt вы сможете найти дополнительную информацию о порядке прохождения пакетов.
3.2. Таблица Mangle
Как уже упоминалось выше, эта таблица предназначена, главным образом для внесения изменений в заголовки пакетов (mangle – искажать, изменять. прим. перев.). Т.е. в этой таблице вы можете устанавливать биты TOS (Type Of Service) и т.д.
ОСТОРОЖНО: Еще раз напоминаю вам, что в этой таблице не следует производить любого рода фильтрацию, маскировку или преобразование адресов (DNAT, SNAT, MASQUERADE).
В этой таблице допускается выполнять только нижеперечисленные действия:
TOS
TTL
MARK
Действие TOS выполняет установку битов поля Type of Service в пакете. Это поле используется для назначения сетевой политики обслуживания пакета, т.е. задает желаемый вариант маршрутизации. Однако, следует заметить, что данное свойство в действительности используется на незначительном количестве маршрутизаторов в Интернете. Другими словами, не следует изменять состояние этого поля для пакетов, уходящих в Интернет, потому что на роутерах, которые таки обслуживают это поле, может быть принято неправильное решение при выборе маршрута.
Действие TTL используется для установки значения поля TTL (Time To Live) пакета. Есть одно неплохое применение этому действию. Мы можем присваивать определенное значение этому полю, чтобы скрыть наш брандмауэр от чересчур любопытных провайдеров (Internet Service Providers). Дело в том, что отдельные провайдеры очень не любят когда одно подключение разделяется несколькими компьютерами. и тогда они начинают проверять значение TTL приходящих пакетов и используют его как один из критериев определения того, один компьютер «сидит» на подключении или несколько.
Действие MARK устанавливает специальную метку на пакет, которая затем может быть проверена другими правилами в iptables или другими программами, например iproute2. С помощью «меток» можно управлять маршрутизацией пакетов, ограничивать траффик и т.п.
3.3. Таблица Nat
Эта таблица используется для выполнения преобразований сетевых адресов NAT (Network Address Translation). Как уже упоминалось ранее, только первый пакет из потока проходит через цепочки этой таблицы, трансляция адресов или маскировка применяются ко всем последующим пакетам в потоке автоматически. Для этой таблицы характерны действия:
DNAT
SNAT
MASQUERADE
Действие DNAT (Destination Network Address Translation) производит преобразование адресов назначения в заголовках пакетов. Другими словами, этим действием производится перенаправление пакетов на другие адреса, отличные от указанных в заголовках пакетов.
SNAT (Source Network Address Translation) используется для изменения исходных адресов пакетов. С помощью этого действия можно скрыть структуру локальной сети, а заодно и разделить единственный внешний IP адрес между компьютерами локальной сети для выхода в Интернет. В этом случае брандмауэр, с помощью SNAT, автоматически производит прямое и обратное преобразование адресов, тем самым давая возможность выполнять подключение к серверам в Интернете с компьютеров в локальной сети.
Маскировка (MASQUERADE) применяется в тех же целях, что и SNAT, но в отличие от последней, MASQUERADE дает более сильную нагрузку на систему. Происходит это потому, что каждый раз, когда требуется выполнение этого действия – производится запрос IP адреса для указанного в действии сетевого интерфейса, в то время как для SNAT IP адрес указывается непосредственно. Однако, благодаря такому отличию, MASQUERADE может работать в случаях с динамическим IP адресом, т.е. когда вы подключаетесь к Интернет, скажем через PPP, SLIP или DHCP.
3.4. Таблица Filter
Как следует из названия, в этой таблице должны содержаться наборы правил для выполнения фильтрации пакетов. Пакеты могут пропускаться далее, либо отвергаться (действия ACCEPT и DROP соответственно), в зависимости от их содержимого. Конечно же, мы можем отфильтровывать пакеты и в других таблицах, но эта таблица существует именно для нужд фильтрации. В этой таблице допускается использование большинства из существующих действий, однако ряд действий, которые мы рассмотрели выше в этой главе, должны выполняться только в присущих им таблицах.
Глава 4. Механизм определения состояний
В данной главе все внимание будет уделено механизму определения состояний пакетов (state machine). По прочтении ее у вас должно сложиться достаточно четкое представление о работе механизма, а способствовать этому должен значительный объем поясняющих примеров.
4.1. Введение
Механизм определения состояния (state machine) является отдельной частью iptables и в действительности не должен бы так называться, поскольку фактически является механизмом трассировки соединений. Однако значительному количеству людей он известен именно как «механизм определения состояния» (state machine). В данной главе эти названия будут использоваться как синонимы. Трассировщик соединений создан для того, чтобы netfilter мог постоянно иметь информацию о состоянии каждого конкретного соединения. Наличие трассировщика позволяет создавать более надежные наборы правил по сравнению с брандмауэрами, которые не имеют поддержки такого механизма.
В пределах iptables, соединение может иметь одно из 4-х базовых состояний: NEW, ESTABLISHED, RELATED и INVALID. Позднее мы остановимся на каждом из них более подробно. Для управления прохождением пакетов, основываясь на их состоянии, используется критерий –state.
Трассировка соединений производится специальным кодом в пространстве ядра – трассировщиком (conntrack). Код трассировщика может быть скомпилирован как подгружаемый модуль ядра, так и статически связан с ядром. В большинстве случаев нам потребна более специфичная информация о соединении, чем та, которую поставляет трассировщик по-умолчанию. Поэтому трассировщик включает в себя обработчики различных протоколов, например TCP, UDP или ICMP. Собранная ими информация затем используется для идентификации и определения текущего состояния соединения. Например – соединение по протоколу UDP однозначно идентифицируется по IP-адресам и портам источника и приемника.
В предыдущих версиях ядра имелась возможность включения/выключения поддержки дефрагментации пакетов. Однако, после того как трассировка соединений была включена в состав iptables/netfilter, надобность в этом отпала. Причина в том, что трассировщик не в состоянии выполнять возложенные на него функции без поддержки дефрагментации и поэтому она включена постоянно. Ее нельзя отключить иначе как отключив трассировку соединений. Дефрагментация выполняется всегда, если трассировщик включен.
Трассировка соединений производится в цепочке PREROUTING, исключая случаи, когда пакеты создаются локальными процессами на брандмауэре, в этом случае трассировка производится в цепочке OUTPUT. Это означает, что iptables производит все вычисления, связанные с определением состояния, в пределах этих цепочек. Когда локальный процесс на брандмауэре отправляет первый пакет из потока, то в цепочке OUTPUT ему присваивается состояние NEW, а когда возвращается пакет ответа, то состояние соединения в цепочке PREROUTING изменяется на ESTABLISHED, и так далее. Если же соединение устанавливается извне, то состояние NEW присваивается первому пакету из потока в цепочке PREROUTING. Таким образом, определение состояния пакетов производится в пределах цепочек PREROUTING и OUTPUT таблицы nat.
4.2. Таблица трассировщика
Кратко рассмотрим таблицу трассировщика, которую можно найти в файле /proc/net/ip_conntrack. Здесь содержится список всех активных соединений. Если модуль ip_conntrack загружен, то команда cat /proc/net/ip_conntrak должна вывести нечто, подобное:
tcp 6 117 SYN_SENT src=192.168.1.6 dst=192.168.1.9 sport=32775 dport=22 [UNREPLIED] src=192.168.1.9 dst=192.168.1.6 sport=22 dport=32775 use=2
В этом примере содержится вся информация, которая известна трассировщику, по конкретному соединению. Первое, что можно увидеть – это название протокола, в данном случае – tcp. Далее следует некоторое число в обычном десятичном представлении. После него следует число, определяющее «время жизни» записи в таблице (т.е. количество секунд, через которое информация о соединении будет удалена из таблицы). Для нашего случая, запись в таблице будет храниться еще 117 секунд, если конечно через это соединение более не проследует ни одного пакета. При прохождении каждого последующего пакета через данное соединение, это значение будет устанавливаться в значение по-умолчанию для заданного состояния. Это число уменьшается на 1 каждую секунду. Далее следует фактическое состояние соединения. Для нашего примера состояние имеет значение SYN_SENT. Внутреннее представление состояния несколько отличается от внешнего. Значение SYN_SENT говорит о том, что через данное соединение проследовал единственный пакет TCP SYN. Далее расположены адреса отправителя и получателя, порт отправителя и получателя. Здесь же видно ключевое слово [UNREPLIED], которое сообщает о том, что ответного трафика через это соединение еще не было. И наконец приводится дополнительная информация по ожидаемому пакету, это IP адреса отправителя/получателя (те же самые, только поменявшиеся местами, поскольку ожидается ответный пакет), то же касается и портов.
Записи в таблице могут принимать ряд значений, все они определены в заголовочных файлах linux/include/netfilter-ipv4/ip_conntrack*.h. Значения по-умолчанию зависят от типа протокола. Каждый из IP-протоколов – TCP, UDP или ICMP имеют собственные значения по-умолчанию, которые определены в заголовочном файле linux/include/netfilter-ipv4/ip_conntrack.h. Более подробно мы остановимся на этих значениях, когда будем рассматривать каждый из протоколов в отдельности.
ПРИМЕЧАНИЕ: Совсем недавно, в patch-o-matic, появилась заплата tcp-window-tracking, которая предоставляет возможность передачи значений всех таймаутов через специальные переменные, т.е. позволяет изменять их «на лету». Таким образом появляется возможность изменения таймаутов без необходимости пересборки ядра.
Изменения вносятся с помощью определенных системных вызовов, через каталог /proc/sys/net/ipv4/netfilter. Особое внимание обратите на ряд переменных /proc/sys/net/ipv4/netfilter/ip_ct_*.
После получения пакета ответа трассировщик снимет флаг [UNREPLIED] и заменит его флагом [ASSURED]. Этот флаг сообщает о том, что соединение установлено уверенно и эта запись не будет стерта по достижении максимально возможного количества трассируемых соединений. Максимальное количество записей, которое может содержаться в таблице зависит от значения по-умолчанию, которое может быть установлено вызовом функции ipsysctl в последних версиях ядра. Для объема ОЗУ 128 Мб это значение соответствует 8192 записям, для 256 Мб – 16376. Вы можете посмотреть и изменить это значение установкой переменной /proc/sys/net/ipv4/ip_conntrack_max.
