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. Порядок прохождения таблиц и цепочек
3.1. Общие положения
3.2. Таблица Mangle
3.3. Таблица Nat
3.4. Таблица Filter
Глава 4. Механизм определения состояний
4.1. Введение
4.2. Таблица трассировщика
4.3. Состояния в пространстве пользователя
4.4. TCP соединения
Второй способ загрузки правил предпочтительнее. Он предполагает следующие шаги. Для начала – запишите правила в файл или непосредственно, через команду 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-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. С помощью «меток» можно управлять маршрутизацией пакетов, ограничивать траффик и т.п.
ОСТОРОЖНО: Еще раз напоминаю вам, что в этой таблице не следует производить любого рода фильтрацию, маскировку или преобразование адресов (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 адреса для указанного в действии сетевого интерфейса, в то время как для SNATIP адрес указывается непосредственно. Однако, благодаря такому отличию, MASQUERADEможет работать в случаях с динамическим IP адресом, т.е. когда вы подключаетесь к Интернет, скажем через PPP, SLIPили DHCP.
DNAT
SNAT
MASQUERADE
Действие DNAT(Destination Network Address Translation) производит преобразование адресов назначения в заголовках пакетов. Другими словами, этим действием производится перенаправление пакетов на другие адреса, отличные от указанных в заголовках пакетов.
SNAT(Source Network Address Translation) используется для изменения исходных адресов пакетов. С помощью этого действия можно скрыть структуру локальной сети, а заодно и разделить единственный внешний IP адрес между компьютерами локальной сети для выхода в Интернет. В этом случае брандмауэр, с помощью SNAT, автоматически производит прямое и обратное преобразование адресов, тем самым давая возможность выполнять подключение к серверам в Интернете с компьютеров в локальной сети.
Маскировка ( MASQUERADE) применяется в тех же целях, что и SNAT, но в отличие от последней, MASQUERADEдает более сильную нагрузку на систему. Происходит это потому, что каждый раз, когда требуется выполнение этого действия – производится запрос IP адреса для указанного в действии сетевого интерфейса, в то время как для SNATIP адрес указывается непосредственно. Однако, благодаря такому отличию, 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.
В пределах 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.
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.
4.3. Состояния в пространстве пользователя
Как вы уже наверняка заметили, в пространстве ядра, в зависимости от типа протокола, пакеты могут иметь несколько различных состояний. Однако, вне ядра пакеты могут иметь только 4 состояния. В основном состояние пакета используется критерием
–state. Допустимыми являются состояния
NEW,
ESTABLISHED,
RELATEDи
INVALID. В таблице, приводимой ниже, рассмтриваются каждое из возможных состояний.
Таблица 4-1. Перечень состояний в пространстве пользователя
(Состояние – Описание)
Состояние: NEW
Описание:Признак NEWсообщает о том, что пакет является первым для данного соединения. Это означает, что это первый пакет в данном соединении, который увидел модуль трассировщика. Например если получен SYNпакет являющийся первым пакетом для данного соединения, то он получит статус NEW. Однако, пакет может и не быть SYNпакетом и тем не менее получить статус NEW. Это может породить определенные проблемы в отдельных случаях, но может оказаться и весьма полезным, например когда желательно «подхватить» соединения, «потерянные» другими брандмауэрами или в случаях, когда таймаут соединения уже истек, но само соединение не было закрыто.
Состояние: RELATED
Описание:Состояние RELATEDодно из самых «хитрых». Соединение получает статус RELATEDесли оно связано с другим соединением, имеющим признак ESTABLISHED. Это означает, что соединение получает признак RELATEDтогда, когда оно инициировано из уже установленного соединения, имеющего признак ESTABLISHED. Хорошим примером соединения, которое может рассматриваться как RELATED, является соединение FTP-data, которое является связанным с портом FTP control, а так же DCCсоединение, запущенное из IRC. Обратите внимание на то, что большинство протоколов TCPи некоторые из протоколов UDPвесьма сложны и передают информацию о соединении через область данных TCPили UDPпакетов и поэтому требуют наличия специальных вспомогательных модулей для корректной работы.
Состояние: ESTABLISHED
Описание:Состояние ESTABLISHEDговорит о том, что это не первый пакет в соединении. Схема установки состояния ESTABLISHEDдостаточна проста для понимания. Единственное требование, предъявляемое к соединению, заключается в том, что для перехода в состояние ESTABLISHEDнеобходимо чтобы узел сети передал пакет и получил на него ответ от другого узла (хоста). После получения ответа состояние соединения NEWили RELATEDбудет изаменено на ESTABLISHED.
Состояние: INVALID
Описание:Признак INVALIDговорит о том, что пакет не может быть идентифицирован и поэтому не может иметь определенного статуса. Это может происходить по разным причинам, например при нехватке памяти или при получении ICMP–сообщения об ошибке, которое не соответствует какому либо известному соединению. Наверное наилучшим вариантом было бы применение действия DROPк таким пакетам.
Эти четыре состояния могут использоваться в критерии –state. Механизм определения состояния позволяет строить чрезвычайно мощную и эффективную защиту. Раньше приходилось открывать все порты выше 1024, чтобы пропустить обратный трафик в локальную сеть, теперь же, при наличии механизма определения состояния, необходимость в этом отпала, поскольку появилась возможность «открывать» доступ только для обратного (ответного) трафика, пресекая попытки установления соединений извне.
Таблица 4-1. Перечень состояний в пространстве пользователя
(Состояние – Описание)
Состояние: NEW
Описание:Признак NEWсообщает о том, что пакет является первым для данного соединения. Это означает, что это первый пакет в данном соединении, который увидел модуль трассировщика. Например если получен SYNпакет являющийся первым пакетом для данного соединения, то он получит статус NEW. Однако, пакет может и не быть SYNпакетом и тем не менее получить статус NEW. Это может породить определенные проблемы в отдельных случаях, но может оказаться и весьма полезным, например когда желательно «подхватить» соединения, «потерянные» другими брандмауэрами или в случаях, когда таймаут соединения уже истек, но само соединение не было закрыто.
Состояние: RELATED
Описание:Состояние RELATEDодно из самых «хитрых». Соединение получает статус RELATEDесли оно связано с другим соединением, имеющим признак ESTABLISHED. Это означает, что соединение получает признак RELATEDтогда, когда оно инициировано из уже установленного соединения, имеющего признак ESTABLISHED. Хорошим примером соединения, которое может рассматриваться как RELATED, является соединение FTP-data, которое является связанным с портом FTP control, а так же DCCсоединение, запущенное из IRC. Обратите внимание на то, что большинство протоколов TCPи некоторые из протоколов UDPвесьма сложны и передают информацию о соединении через область данных TCPили UDPпакетов и поэтому требуют наличия специальных вспомогательных модулей для корректной работы.
Состояние: ESTABLISHED
Описание:Состояние ESTABLISHEDговорит о том, что это не первый пакет в соединении. Схема установки состояния ESTABLISHEDдостаточна проста для понимания. Единственное требование, предъявляемое к соединению, заключается в том, что для перехода в состояние ESTABLISHEDнеобходимо чтобы узел сети передал пакет и получил на него ответ от другого узла (хоста). После получения ответа состояние соединения NEWили RELATEDбудет изаменено на ESTABLISHED.
Состояние: INVALID
Описание:Признак INVALIDговорит о том, что пакет не может быть идентифицирован и поэтому не может иметь определенного статуса. Это может происходить по разным причинам, например при нехватке памяти или при получении ICMP–сообщения об ошибке, которое не соответствует какому либо известному соединению. Наверное наилучшим вариантом было бы применение действия DROPк таким пакетам.
Эти четыре состояния могут использоваться в критерии –state. Механизм определения состояния позволяет строить чрезвычайно мощную и эффективную защиту. Раньше приходилось открывать все порты выше 1024, чтобы пропустить обратный трафик в локальную сеть, теперь же, при наличии механизма определения состояния, необходимость в этом отпала, поскольку появилась возможность «открывать» доступ только для обратного (ответного) трафика, пресекая попытки установления соединений извне.
4.4. TCP соединения
В этом и в последующих разделах мы поближе рассмотрим признаки состояний и порядок их обработки каждым из трех базовых протоколов
TCP,
UDPи
ICMP, а так же коснемся случая, когда протокол соединения не может быть классифицирован на принадлежность к трем, вышеуказанным, протоколам. Начнем рассмотрение с протокола TCP, поскольку он имеет множество интереснейших особенностей в отношении механизма определения состояния в iptables.