Скажем так, я посчитал, что существует досадный пробел в HOWTO по части информации об iptables и функциях сетевого фильтра (netfilter), реализованных в новой серии ядер 2.4.x Linux. Кроме всего прочего, я попытался ответить на некоторые вопросы по поводу новых возможностей, например проверки состояния пакетов (state matching). Большинство из них проиллюстрированы в файле скрипта rc.firewall.txt, который вы можете вставить в /etc/rc.d/. Для тех, кому интересно, готов сообщить, что этот файл первоначально был основан на masquerading HOWTO.
      Там же вы найдете небольшой сценарий rc.flush-iptables.txt, написанный мною, который вы можете использовать, для своих нужд, при необходимости расширяя под свою конфигурацию.

      Я консультировался с Марком Бучером (Marc Boucher) и другими членами команды разработчиков netfilter. Пользуясь случаем, выражаю огромную признательность за их помощь в создании данного руководства, которое изначально было написано для boingworld.com, а теперь доступно на моем персональном сайте frozentux.net. С помощью этого документа вы пройдете процесс настройки шаг за шагом и, надеюсь, что к концу изучения его вы будете знать о пакете iptables значительно больше. Большая часть материала базируется на файле rc.firewall.txt, так как я считаю, что рассмотрение примера – лучший способ изучения iptables. Я пройду по основным цепочкам правил в порядке их следования. Это несколько усложняет изучение, зато изложение становится логичнее. И, всякий раз, когда у вас возникнут затруднения, вы можете обращаться к этому руководству.

      Этот документ содержит несколько терминов, которые следует пояснить прежде, чем вы столкнетесь с ними.
      DNAT – от англ. Destination Network Address Translation – Изменение Сетевого Адреса Получателя. DNAT – это изменение адреса назначения в заголовке пакета. Зачастую используется в паре с SNAT. Основное применение – использование единственного реального IP-адреса несколькими компьютерами для выхода в Интернет и предоставления дополнительных сетевых услуг внешним клиентам.
      «Поток» (Stream) – под этим термином подразумевается соединение, через которое передаются и принимаются пакеты. Я использовал этот термин для обозначения соединений, через которые передается по меньшей мере 2 пакета в обеих направлениях. В случае TCP это может означать соединение, через которое передается SYN пакет и затем принимается SYN/ACK пакет. Но это так же может подразумевать и передачу SYN пакета и прием сообщения ICMP Host unreachable. Другими словами, я использую этот термин в достаточно широком диапазоне применений.
      SNAT – от англ. Source Network Address Translation – Изменение Сетевого Адреса Отправителя. SNAT – это изменение исходного адреса в заголовке пакета. Основное применение – использование единственного реального IP-адреса несколькими компьютерами для выхода в Интернет. В натоящее время диапазон реальных IP-адресов, по стандарту IPv4, недостаточно широк, и его не хватает на всех (переход на IPv6 разрешит эту проблему).
      «Состояние» (State) – под этим термином подразумевается состояние, в котором находится пакет, согласно RFC 793 – RFC 793 – Transmission Control Protocol, а также трактовкам, используемым в netfilter/iptables. Хочу обратить ваше внимание на тот факт, что определения состояний пакетов, как для внутренних так и для внешних состояний, используемые Netfilter, не полностью соответствуют указанному выше RFC 793.
      «Пространство пользователя» (User space) – под этим термином я подразумеваю все, что расположено за пределами ядра, например: коменда iptables -hвыполняется за пределами ядра, в то время как команда iptables -A FORWARD -p tcp -j ACCEPTвыполняется (частично) в пространстве ядра, поскольку она добавляет новое правило к имеющемуся набору.
      «Пространство ядра» (Kernel space) – в большей или меньшей степени является утверждением, обратным термину «Пространство пользователя». Подразумевает место исполнения – в пределах ядра.
      «Userland» – см. «Пространство пользователя».

      Пакеты iptablesмогут быть загружены с домашней страницы . Кроме того, для работы iptables соответствующим образом должно быть сконфигурировано ядро вашей Linux-системы. Настройка ядра будет обсуждаться ниже.

      Для обеспечения базовых возможностей iptables, с помощью утилиты make configили ей подобных ( make menuconfigили make xconfigприм. перев.), в ядро должны быть включены следующие опции:
      CONFIG_PACKET – Эта опция необходима для приложений, работающих непосредственно с сетевыми устройствами, например: tcpdump или snort.
 
       ПРИМЕЧАНИЕ:Строго говоря, опция CONFIG_PACKET не требуетсядля работы iptables, но, поскольку она используется довольно часто, я включил ее в список. Если вам эта опция не нужна, то можете ее не включать.
 
      CONFIG_NETFILTER – Эта опция необходима, если вы собираетесь использовать компьютер в качестве сетевого экрана (firewall) или шлюза (gateway) в Интернет. Другими словами, вам она определенно понадобится, иначе зачем тогда читать это руководство!
      И конечно нужно добавить драйверы для ваших устройств, т.е. для карты Ethernet, PPPи SLIP. Эти опции необходимы для обеспечения базовых возможностей iptables, для получения дополнительных возможностей придется включить в ядро некоторые дополнительные опции. Ниже приводится список опций для ядра 2.4.9 и их краткое описание:
      CONFIG_IP_NF_CONNTRACK – Трассировка соединений. Трассировка соединений, среди всего прочего, используется при трансляции сетевых адресов и маскарадинге ( NATи Masquerading). Если вы собираетесь строить сетевой экран (firewall) для локальной сети, то вам определенно потребуется эта опция. К примеру, этот модуль необходим для работы rc.firewall.txt.
      CONFIG_IP_NF_FTP – Трассировка FTP соединений. Обмен по FTP идет слишком интенсивно, чтобы использовать обычные методы трассировки. Если не добавить этот модуль, то вы столкнетесь с трудностями при передаче протокола FTP через сетевой экран (firewall).
      CONFIG_IP_NF_IPTABLES – Эта опция необходима для выполнения операций фильтрации, преобразования сетевых адресов (NAT) и маскарадинга (masquerading). Без нее вы вообще ничего не сможете делать с iptables.
      CONFIG_IP_NF_MATCH_LIMIT – Этот модуль необязателен, однако он используется в примерах rc.firewall.txt. Он предоставляет возможность ограничения количества проверок для некоторого правила. Например, -m limit –limit 3/minuteуказывает, что заданное правило может пропустить не более 3-х пакетов в минуту. Таким образом, данный модуль может использоваться для защиты от нападений типа «Отказ в обслуживании».
      CONFIG_IP_NF_MATCH_MAC – Этот модуль позволит строить правила, основанные на MAC–адресации. Как известно, каждая сетевая карта имеет свой собственный уникальный Ethernet-адрес, таким образом, существует возможность блокировать пакеты, поступающие с определенных MAC–адресов (т.е. с определенных сетевых карт). Следует, однако, отметить что данный модуль не используется в rc.firewall.txtили где либо еще в данном руководстве.
      CONFIG_IP_NF_MATCH_MARK – Функция маркировки пакетов MARK. Например, при использовании функции MARKмы получаем возможность пометить требуемые пакеты, а затем, в других таблицах, в зависимости от значения метки, принимать решение о маршрутизации помеченного пакета. Более подробное описание функции MARKприводится ниже в данном документе.
      CONFIG_IP_NF_MATCH_MULTIPORT – Этот модуль позволит строить правила с проверкой на принадлежность пакета к диапазону номеров портов источника/приемника.
      CONFIG_IP_NF_MATCH_TOS – Этот модуль позволит строить правила, отталкиваясь от состояния поля TOSв пакете. Поле TOSустанавливается для Type Of Service. Так же становится возможным устанавливать и сбрасывать биты этого поля в собственных правилах в таблице mangleили командами ip/tc.
      CONFIG_IP_NF_MATCH_TCPMSS – Эта опция добавляет возможность проверки поля MSSв TCP–пакетах.
      CONFIG_IP_NF_MATCH_STATE – Это одно из самых серьезных усовершенствований по сравнению с ipchains. Этот модуль предоставляет возможность управления TCPпакетами, основываясь на их состоянии (state). К примеру, допустим, что мы имеем установленное TCP соединение, с траффиком в оба конца, тогда пакет полученный по такому соединению будет считаться ESTABLISHED(установленное соединение – прим. ред). Эта возможность широко используется в примере rc.firewall.txt.
      CONFIG_IP_NF_MATCH_UNCLEAN – Этот модуль реализует возможность дополнительной проверки IP, TCP, UDPи ICMPпакетов на предмет наличия в них несоответствий, «странностей», ошибок. Установив его мы, к примеру, получим возможность «отсекать» подобного рода пакеты. Однако хочется отметить, что данный модуль пока находится на экспериментальной стадии и не во всех случаях будет работать одинаково, поэтому никогда нельзя будет быть уверенным, что мы не «сбросили» вполне правильные пакеты.
      CONFIG_IP_NF_MATCH_OWNER – Проверка «владельца» соединения (socket). Для примера, мы можем позволить только пользователю root выходить в Internet. Этот модуль был написан как пример работы с iptables. Следует заметить, что данный модуль имеет статус экспериментального и может не всегда выполнять свои функции.
      CONFIG_IP_NF_FILTER – Реализация таблицы filterв которой в основном и осуществляется фильтрация. В данной таблице находятся цепочки INPUT, FORWARDи OUTPUT. Этот модуль обязателен, если вы планируете осуществлять фильтрацию пакетов.
      CONFIG_IP_NF_TARGET_REJECT – Добавляется действие REJECT, которое производит передачу ICMP–сообщения об ошибке в ответ на входящий пакет, который отвергается заданным правилом. Запомните, что TCPсоединения, в отличие от UDPи ICMP, всегда завершаются или отвергаются пакетом TCP RST.
      CONFIG_IP_NF_TARGET_MIRROR – Возможность отправки полученного пакета обратно (отражение). Например, если назначить действие MIRRORдля пакетов, идущих в порт HTTPчерез нашу цепочку INPUT(т.е. на наш WEB-сервер прим. перев.), то пакет будет отправлен обратно (отражен) и, в результате, отправитель увидит свою собственную домашнюю страничку. (Тут одни сплошные «если»: Если у отправителя стоит WEB-сервер, если он работает на том же порту, если у отправителя есть домашняя страничка, и т.д. . Суть-то собственно сводится к тому, что с точки зрения отправителя все выглядит так, как будто бы пакет он отправил на свою собственную машину, а проще говоря, действие MIRRORменяет местами адрес отправителя и получателя и выдает измененный пекет в сеть прим. перев.)
      CONFIG_IP_NF_NAT – Трансляция сетевых адресов в различных ее видах. С помощью этой опции вы сможете дать выход в Интернет всем компьютерам вашей локальной сети, имея лишь один уникальный IP-адрес. Эта опция необходима для работы примера rc.firewall.txt.
      CONFIG_IP_NF_TARGET_MASQUERADE – Маскарадинг. В отличие от NAT, маскарадинг используется в тех случаях, когда заранее неизвестен наш IP-адрес в Интернете, т.е. для случаев DHCP, PPP, SLIPили какого-либо другого способа подключения, подразумевающего динамическое получение IP-адреса. Маскарадинг дает несколько более высокую нагрузку на компьютер, по сравнению с NAT, однако он работает в ситуациях, когда невозможно заранее указать собственный внешний IP-адрес.
      CONFIG_IP_NF_TARGET_REDIRECT – Перенаправление. Обычно это действие используется совместно с проксированием. Вместо того, чтобы просто пропустить пакет дальше, это действие перенаправляет пакет на другой порт сетевого экрана (прокси-серверу прим. перев.). Другими словами, таким способом мы можем выполнять «прозрачное проксирование».
      CONFIG_IP_NF_TARGET_LOG – Добавляет действие LOGв iptables. Мы можем использовать этот модуль для фиксации отдельных пакетов в системном журнале (syslog). Эта возможность может оказаться весьма полезной при отладке ваших сценариев.
      CONFIG_IP_NF_TARGET_TCPMSS – Эта опция может использоваться для преодоления ограничений, накладываемых некоторыми провайдерами (Internet Service Providers), которые блокируют ICMP Fragmentation Neededпакеты. В результате таких ограничений серверы провайдеров могут не передавать web-страницы, ssh может работать, в то время как scp обрывается после установления соединения и пр. Для преодоления подобного рода ограничений мы можем использовать действие TCPMSSограничивая значение MSS(Maximum Segment Size) (обычно MSS ограничивается размером MTU исходящего интерфейса минус 40 байт прим. перев.). Таким образом мы получаем возможность преодолеть то, что авторы netfilter называют «преступной безмозглостью провайдеров или серверов» («criminally braindead ISPs or servers») в справке по конфигурации ядра.
      CONFIG_IP_NF_COMPAT_IPCHAINS – Добавляет совместимость с более старой технологией ipchains. Вполне возможно, что подобного рода совместимость будет сохранена и в ядрах серии 2.6.x.
      CONFIG_IP_NF_COMPAT_IPFWADM – Добавляет совместимость с ipfwadm, не смотря на то что это очень старое средство построения брандмауэров.
      Как вы можете видеть, я дал краткую характеристику каждому модулю. Данные опции доступны в ядре версии 2.4.9. Если вам потребуются дополнительные возможности – советую обратить внимание на расширения patch-o-matic, которые добавляют достаточно большое количество дополнительных функций к Netfilter. Patch-o-matic– это набор дополнений, которые, как предполагается, в будущем будут включены в состав ядра.
      Для работы сценария rc.firewall.txtвам необходимо будет добавить в ядро следующие опции или собрать соответствующие подгружаемые модули. За информацией по опциям, необходимым для работы других сценариев, обращайтесь к приложению с примерами этих сценариев.
      CONFIG_PACKET
      CONFIG_NETFILTER
      CONFIG_IP_NF_CONNTRACK
      CONFIG_IP_NF_FTP
      CONFIG_IP_NF_IRC
      CONFIG_IP_NF_IPTABLES
      CONFIG_IP_NF_FILTER
      CONFIG_IP_NF_NAT
      CONFIG_IP_NF_MATCH_STATE
      CONFIG_IP_NF_TARGET_LOG
      CONFIG_IP_NF_MATCH_LIMIT
      CONFIG_IP_NF_TARGET_MASQUERADE
      Выше приведен список минимально необходимых опций ядра для сценария rc.firewall.txtПеречень опций, необходимых для других примеров сценариев вы сможете найти в соответствующих разделах ниже. Сейчас же мы остановимся на главном сценарии и начнем его изучение.

      В первую очередь посмотрим как собрать (скомпилировать) пакет iptables. Сборка пакета в значительной степени зависит от конфигурации ядра и вы должны это понимать. Некоторые дистрибутивы предполагают предустановку пакета iptables, один из них – Red Hat. Однако, в RedHat этот пакет по умолчанию выключен, поэтому ниже мы рассмотрим как его включить в данном и в других дистрибутивах.

2.3.1. Сборка пакета

2.3.2. Установка в Red Hat 7.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вы сможете найти дополнительную информацию о порядке прохождения пакетов.

      Как уже упоминалось выше, эта таблица предназначена, главным образом для внесения изменений в заголовки пакетов (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. С помощью «меток» можно управлять маршрутизацией пакетов, ограничивать траффик и т.п.

      Эта таблица используется для выполнения преобразований сетевых адресов 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.

      Как следует из названия, в этой таблице должны содержаться наборы правил для выполнения фильтрации пакетов. Пакеты могут пропускаться далее, либо отвергаться (действия ACCEPTи DROPсоответственно), в зависимости от их содержимого. Конечно же, мы можем отфильтровывать пакеты и в других таблицах, но эта таблица существует именно для нужд фильтрации. В этой таблице допускается использование большинства из существующих действий, однако ряд действий, которые мы рассмотрели выше в этой главе, должны выполняться только в присущих им таблицах.

      Механизм определения состояния (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.

      Кратко рассмотрим таблицу трассировщика, которую можно найти в файле /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.

      Как вы уже наверняка заметили, в пространстве ядра, в зависимости от типа протокола, пакеты могут иметь несколько различных состояний. Однако, вне ядра пакеты могут иметь только 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, чтобы пропустить обратный трафик в локальную сеть, теперь же, при наличии механизма определения состояния, необходимость в этом отпала, поскольку появилась возможность «открывать» доступ только для обратного (ответного) трафика, пресекая попытки установления соединений извне.

      В этом и в последующих разделах мы поближе рассмотрим признаки состояний и порядок их обработки каждым из трех базовых протоколов TCP, UDPи ICMP, а так же коснемся случая, когда протокол соединения не может быть классифицирован на принадлежность к трем, вышеуказанным, протоколам. Начнем рассмотрение с протокола TCP, поскольку он имеет множество интереснейших особенностей в отношении механизма определения состояния в iptables.
       TCPсоединение всегда устанавливается передачей трех пакетов, которые инициализируют и устанавливают соединение, через которое в дальнейшем будут передаваться данные. Сессия начинается с передачи SYNпакета, в ответ на который передается SYN/ACKпакет и подтверждает установление соединения пакет ACK. После этого соединение считается установленным и готовым к передаче данных. Может возникнуть вопрос: «А как же трассируется соединение?». В действительности все довольно просто.
      Для всех типов соединений, трассировка проходит практически одинаково. Взгляните на рисунок ниже, где показаны все стадии установления соединения. Как видите, трассировщик, с точки зрения пользователя, фактически не следит за ходом установления соединения. Просто, как только трассировщик «увидел» первый ( SYN) пакет, то присваивает ему статус NEW. Как только через трассировщика проходит второй пакет ( SYN/ACK), то соединению присваивается статус ESTABLISHED. Почму именно второй пакет? Сейчас разберемся. Строя свой набор правил, вы можете позволить покидать локальную сеть пакетам со статусом NEWи ESTABLISHED, а во входящем трафике пропускать пакеты только со статусом ESTABLISHEDи все будет работать прекрасно. И наоборот, если бы трассировщик продолжал считать соединение как NEW, то фактически вам никогда не удалось бы установить соединение с «внешним миром», либо пришлось бы позволить прохождение NEWпакетов в локальную сеть. С точки зрения ядра все выглядит более сложным, поскольку в пространстве ядра TCPсоединения имеют ряд промежуточных состояний, недоступных в пространстве пользователя. В общих чертах они соответствуют спецификации RFC 793 – Transmission Control Protocolна странице 21-23. Более подробно эта тема будет рассматриваться чуть ниже.
 
      С точки зрения пользователя все выглядит достаточно просто, однако если посмотреть с точки зрения ядра, то все выглядит несколько сложнее. Рассмотрим порядок изменения состояния соединения в таблице /proc/net/ip_conntrack. После передачи первого пакета SYN.
      tcp 6 117 SYN_SENT src=192.168.1.5 dst=192.168.1.35 sport=1031 \ dport=23 [UNREPLIED] src=192.168.1.35 dst=192.168.1.5 sport=23 \ dport=1031 use=1
      Как видите, запись в таблице отражает точное состояние соединения – был отмечен факт передачи пакета SYN (флаг SYN_SENT), на который ответа пока не было (флаг [UNREPLIED]). После получения пакета-ответа, соединение переводится в следующее внутреннее состояние:
      tcp 6 57 SYN_RECV src=192.168.1.5 dst=192.168.1.35 sport=1031 \ dport=23 src=192.168.1.35 dst=192.168.1.5 sport=23 dport=1031 \ use=1
      Теперь запись сообщает о том, что обратно прошел пакет SYN/ACK. На этот раз соединение переводится в состояние SYN_RECV. Это состояние говорит о том, что пакет SYNбыл благополучно доставлен получателю и в ответ на него пришел пакет-подтверждение ( SYN/ACK). Кроме того, механизм определения состояния «увидев» пакеты, следующие в обеих направлениях, снимает флаг [UNREPLIED]. И наконец после передачи заключительного ACK–пакета, в процедуре установления соединения
      tcp 6 431999 ESTABLISHED src=192.168.1.5 dst=192.168.1.35 \ sport=1031 dport=23 src=192.168.1.35 dst=192.168.1.5 \ sport=23 dport=1031 use=1
      соединение переходит в состояние ESTABLISHED(установленное). После приема нескольких пакетов через это соединение, к нему добавится флаг [ASSURED] (уверенное).
      При закрытии, TCPсоединение проходит через следующие состояния.
 
 
      Как видно из рисунка, соединение не закрывается до тех пор пока не будет передан последний пакет ACK. Обратите внимание – эта картинка описывает нормальный процесс закрытия соединения. Кроме того, если соединение отвергается, то оно может быть закрыто передачей пакета RST(сброс). В этом случае соединение будет закрыто по истечение предопределенного времени.
      При закрытии, соединение переводится в состояние TIME_WAIT, продолжительность которого по-умолчанию соответствует 2 минутам, в течение которого еще возможно прохождение пакетов через брандмауэр. Это является своего рода «буферным временем», которое дает возможность пройти пакетам, «увязшим» на том или ином маршрутизаторе (роутере).
      Если соединение закрывается по получении пакета RST, то оно переводится в состояние CLOSE. Время ожидания до фактического закрытия соединения по-умолчанию устанавливается равным 10 секунд. Подтверждение на пакеты RSTне передается и соединение закрывается сразу же. Кроме того имеется ряд других внутренних состояний. В таблице ниже приводится список возможных внутренних состояний соединения и соответствующие им размеры таймаутов.
       Таблица 4-2. Internal states
      (Состояние – Время ожидания )
      NONE – 30 минут
      ESTABLISHED – 5 дней
      SYN_SENT – 2 минуты
      SYN_RECV – 60 секунд
      FIN_WAIT – 2 минуты
      TIME_WAIT – 2 минуты
      CLOSE – 10 секунд
      CLOSE_WAIT – 12 часов
      LAST_ACK – 30 секунд
      LISTEN – 2 минуты
      Эти значения могут несколько изменяться от версии к версии ядра, кроме того, они могут быть изменены через интерфейс файловой системы /proc (переменные proc/sys/net/ipv4/netfilter/ip_ct_tcp_*). Значения устанавливаются в сотых долях секунды, так что число 3000 означает 30 секунд.
 
       ПРИМЕЧАНИЕ: Обратите внимание на то, что со стороны пользователя, механизм определения состояния никак не отображает состояние флагов TCPпакетов. Как правило – это не всегда хорошо, поскольку состояние NEWприсваивается, не только пакетам SYN.
 
      Это качество трассировщика может быть использовано для избыточного файерволлинга (firewalling), но для случая домашней локальной сети, в которой используется только один брандмауэр это очень плохо. Эта проблема более подробно обсуждается в разделе Пакеты со статусом NEW и со сброшенным битом SYNприложения Общие проблемы и вопросы. Альтернативным вариантом решения этой проблемы может служить установка заплаты tcp-window-trackingиз patch-o-matic, которая сделает возможным принятие решений в зависимости от значения TCP window.

      По сути своей, UDPсоединения не имеют признака состояния. Этому имеется несколько причин, основная из них состоит в том, что этот протокол не предусматривает установления и закрытия соединения, но самый большой недостаток – отсутствие информации об очередности поступления пакетов. Приняв две датаграммы UDP, невозможно сказать точно в каком порядке они были отправлены. Однако, даже в этой ситуации все еще возможно определить состояние соединения. Ниже приводится рисунок того, как выглядит установление соединения с точки зрения трассировщика.
 
 
      Из рисунка видно, что состояние UDPсоединения определяется почти так же как и состояние TCPсоединения, с точки зрения из пользовательского пространства. Изнутри же это выглядит несколько иначе, хотя во многом похоже. Для начала посмотрим на запись, появившуюся после передачи первого пакета UDP.
      udp 17 20 src=192.168.1.2 dst=192.168.1.5 sport=137 dport=1025 \ [UNREPLIED] src=192.168.1.5 dst=192.168.1.2 sport=1025 \ dport=137 use=1
      Первое, что мы видим – это название протокола (udp) и его номер (см. /etc/protocols прим. перев.). Третье значение – оставшееся «время жизни» записи в секундах. Далее следуют характеристики пакета, прошедшего через брандмауэр – это адреса и порты отправителя и получателя. Здесь же видно, что это первый пакет в сессии (флаг [UNREPLIED]). И завершают запись адреса и порты отправителя и получателя ожидаемого пакета. Таймаут такой записи по умолчанию составляет 30 секунд.
      udp 17 170 src=192.168.1.2 dst=192.168.1.5 sport=137 \ dport=1025 src=192.168.1.5 dst=192.168.1.2 sport=1025 \ dport=137 use=1
      После того как сервер «увидел» ответ на первый пакет, соединение считается ESTABLISHED(установленным), единственное отличие от предыдущей записи состоит в отсутствии флага [UNRREPLIED] и, кроме того, таймаут для записи стал равным 180 секундам. После этого может только добавиться флаг [ASSURED] (уверенное соединение), который был описан выше. Флаг [ASSURED] устанавливается только после прохождения некоторого количества пакетов через соединение.
      udp 17 175 src=192.168.1.5 dst=195.22.79.2 sport=1025 \ dport=53 src=195.22.79.2 dst=192.168.1.5 sport=53 \ dport=1025 [ASSURED] use=1
      Теперь соединение стало «уверенным». Запись в таблице выглядит практически так же как и в предыдущем примере, за исключением флага [ASSURED]. Если в течение 180 секунд через соединение не пройдет хотя бы один пакет, то запись будет удалена из таблицы. Это достаточно маленький промежуток времени, но его вполне достаточно для большинства применений. «Время жизни» отсчитывается от момента прохождения последнего пакета и при появлении нового, время переустанавливается в свое начальное значение, это справедливо и для всех остальных типов внутренних состояний.

       ICMPпакеты используются только для передачи управляющих сообщений и не организуют постоянного соединения. Однако, существует 4 типа ICMPпакетов, которые вызывают передачу ответа, поэтому они могут иметь два состояния: NEWи ESTABLISHED. К этим пакетам относятся ICMP Echo Request/Echo Reply, ICMP Timestamp Request/Timestamp Reply, ICMP Information Request/Information Replyи ICMP Address Mask Request/Address Mask Reply. Из них – ICMP Timestamp Request/Timestamp Replyи ICMP Information Request/Information Replyсчитаются устаревшими и поэтому, в большинстве случаев, могут быть безболезненно сброшены ( DROP). Взгляните на рисунок ниже.
 
 
      Как видно из этого рисунка, сервер выполняет Echo Request(эхо-запрос) к клиенту, который (запрос) распознается брандмауэром как NEW. На этот запрос клиент отвечает пакетом Echo Reply, и теперь пакет распознается как имеющий состояние ESTABLISHED. После прохождения первого пакета ( Echo Request) в ip_conntrack появляется запись:
      icmp 1 25 src=192.168.1.6 dst=192.168.1.10 type=8 code=0 \ id=33029 [UNREPLIED] src=192.168.1.10 dst=192.168.1.6 \ type=0 code=0 id=33029 use=1
      Эта запись несколько отличается от записей, свойственных протоколам TCPи UDP, хотя точно так же присутствуют и название протокола и время таймаута и адреса передатчика и приемника, но далее появляются три новых поля – type, code и id. Поле type содержит тип ICMP, поле code – код ICMP. Значения типов и кодов ICMPприводятся в приложении Типы ICMP. И последнее поле id содержит идентификатор пакета. Каждый ICMP–пакет имеет свой идентификатор. Когда приемник, в ответ на ICMP–запрос посылает ответ, он подставляет в пакет ответа этот идентификатор, благодаря чему, передатчик может корректно распознать в ответ на какой запрос пришел ответ.
      Следующее поле – флаг [UNREPLIED], который встречался нам ранее. Он означает, что прибыл первый пакет в соединении. Завершается запись характеристиками ожидаемого пакета ответа. Сюда включаются адреса отправителя и получателя. Что касается типа и кода ICMPпакета, то они соответствуют правильным значениям ожидаемого пакета ICMP Echo Reply. Идентификатор пакета-ответа тот же, что и в пакете запроса.
      Пакет ответа распознается уже как ESTABLISHED. Однако, мы знаем, что после передачи пакета ответа, через это соединение уже ничего не ожидается, поэтому после прохождения ответа через netfilter, запись в таблице трассировщика уничтожается.
      В любом случае запрос рассматривается как NEW, а ответ как ESTABLISHED.
 
       ПРИМЕЧАНИЕ: Заметьте при этом, что пакет ответа должен совпадать по своим характеристикам (адреса отправителя и получателя, тип, код и идентификатор) с указанными в записи в таблице трассировщика, это справедливо и для всех остальных типов трафика.
 
      ICMP запросы имеют таймаут, по-умолчанию, 30 секунд. Этого времени, в большинстве случаев, вполне достаточно. Время таймаута можно изменить в /proc/sys/net/ipv4/netfilter/ip_ct_icmp_timeout. ( Напоминаю, что переменные типа /proc/sys/net/ipv4/netfilter/ip_ct_* становятся доступны только после установки «заплаты» tcp-window-tracking из patch-o-matic прим. перев.).
      Значительная часть ICMPиспользуется для передачи сообщений о том, что происходит с тем или иным UDPили TCPсоединением. Всвязи с этим они очень часто распознаются как связанные ( RELATED) с существующим соединением. Простым примером могут служить сообщения ICMP Host Unreachableили ICMP Network Unreachable. Они всегда порождаются при попытке соединиться с узлом сети когда этот узел или сеть недоступны, в этом случае последний маршрутизатор вернет соответствующий ICMPпакет, который будет распознан как RELATED. На рисунке ниже показано как это происходит.
 
 
      В этом примере некоторому узлу передается запрос на соединение ( SYNпакет). Он приобретает статус NEWна брандмауэре. Однако, в этот момент времени, сеть оказывается недоступной, поэтому роутер возвращает пакет ICMP Network Unreachable. Трассировщик соединений распознает этот пакет как RELATED, благодаря уже имеющейся записи в таблице, так что пакет благополучно будет передан клиенту, который затем оборвет неудачное соединение. Тем временем, брандмауэр уничтожит запись в таблице, поскольку для данного соединения было получено сообщение об ошибке.
      То же самое происходит и с UDPсоединениями – если обнаруживаются подобные проблемы. Все сообщения ICMP, передаваемые в ответ на UDPсоединение, рассматриваются как RELATED. Взгляните на следующий рисунок.
 
 
      Датаграмма UDPпередается на сервер. Соединению присваивается статус NEW. Однако доступ к сети запрещен (брандмауэром или роутером), поэтому обратно возвращается сообщение ICMP Network Prohibited. Брандмауэр распознает это сообщение как связанное с открытым UDPсоединением, присваивает ему статус RELATEDи передает клиенту. После чего запись в таблице трассировщика уничтожается, а клиент благополучно обрывает соединение.

      В некоторых случаях механизм определения состояния не может распознать протокол обмена и, соответственно, не может выбрать стратегию обработки этого соединения. В этом случае он переходит к заданному по-умолчанию поведению. Поведение по-умолчанию используется, например при обслуживании протоколов NETBLT, MUXи EGP. Поведение по-молчанию во многом схоже с трассировкой UDPсоединений. Первому пакету присваивается статус NEW, а всем последующим – статус ESTABLISHED.
      При использовании поведения по-умолчанию, для всех пакетов используется одно и то же значение таймаута, которое можно изменить в /proc/sys/net/ipv4/netfilter/ip_ct_generic_timeout. По-умолчанию это значение равно 600 секундам, или 10 минутам В зависимости от типа трафика, это время может меняться, особенно когда соединение устанавливается по спутниковому каналу.

      Имеется ряд комплексных протоколов, корректная трассировка которых более сложна. Прмером могут служить протоколы ICQ, IRCи FTP. Каждый из этих протоколов несет дополнительную информацию о соединении в области данных пакета. Соответственно корректная трассировка таких соединений требует подключения дополнительных вспомогательных модулей.
      В качестве первого примера рассмотрим протокол FTP. Протокол FTPсначала открывает одиночное соединение, которое называется «сеансом управления FTP» ( FTP control session). При выполнении команд в пределах этого сеанса, для передачи сопутствующих данных открываются дополнительные порты. Эти соединения могут быть активными или пассивными. При создании активного соединения клент передает FTPсерверу номер порта и IPадрес для соединения. Затем клент открывает порт, сервер подключает к заданному порту клиента свой порт с номером 20 (известный как FTP-Data) и передает данные через установленное соединение.
      Проблема состоит в том, что брандмауэр ничего не знает об этих дополнительных подключениях, поскольку вся информация о них передается через область данных пакета. Из-за этого брандмауэр не позволит серверу соединиться с указанным портом клиента.
      Решение проблемы состоит в добавлении специального вспомогательного модуля трассировки, который отслеживает, специфичную для данного протокола, информацию в области данных пакетов, передаваемых в рамках сеанса управления. При создании такого соединения, вспомогательный модуль корректно воспримет передаваемую информацию и создаст соответствующую запись в таблице трассировщика со статусом RELATED, благодаря чему соединение будет установлено. Рисунок ниже поясняет порядок выполнения подобного соединения.
 
 
      Пассивный FTPдействует противоположным образом. Клиент посылает запрос серверу на получение данных, а сервер возвращает клиенту IPадрес и номер порта для подключения. Клиент подключает свой 20-й порт ( FTP-data) к указанному порту сервера и получает запрошенные данные. Если ваш FTP сервер находится за брандмауэром, то вам потребуется этот вспомогательный модуль для того, чтобы сервер смог обслуживать клиентов из Интернет. То же самое касается случая, когда вы хотите ограничить своих пользователей только возможностью подключения к HTTPи FTPсерверам в Интернет и закрыть все остальные порты. Рисунок ниже показывает как выполняется пассивное соединение FTP.
 
 
      Некоторые вспомогательные модули уже включены в состав ядра. Если быть более точным, то в состав ядра включены вспомогательные модули для протоколов FTPи IRC. Если в вашем распоряжении нет необходимого вспомогательного модуля, то вам следует обратиться к patch-o-matic, который содержит большое количество вспомогательных модулей для трассировки таких протоколов, как ntalkили H.323. Если и здесь вы не нашли то, что вам нужно, то у вас есть еще варианты: вы можете обратиться к CVS iptables, если искомый вспомогательный модуль еще не был включен в patch-o-matic, либо можете войти в контакт с разработчиками netfilter и узнать у них – имеется ли подобный модуль и планируется ли он к выпуску. Если и тут вы потерпели неудачу, то наверное вам следует прочитать Rusty Russell's Unreliable Netfilter Hacking HOW-TO.
      Вспомогательные модули могут быть скомпилированы как в виде подгружаемых модулей ядра, так и статически связаны с ядром. Если они скомпилированы как модули, то вы можете загрузить их командой:
       modprobe ip_conntrack_*
      Обратите внимание на то, что механизм определения состояния не имеет никакого отношения к трансляции сетевых адресов ( NAT), поэтому вам может потребоваться большее количество дополнительных модулей, если вы выполняете такую трансляцию. Допустим, что вы выполняете трансляцию адресов и трассировку FTPсоединений, тогда вам необходим так же и соответствующий вспомогательный модуль NAT. Имена вспомогательных модулей NATначинаются с ip_nat_, в соответствии с соглашением об именах. В данном случае модуль называется ip_nat_ftp. Для протокола IRCтакой модуль будет называться ip_nat_irc. Тому же самому соглашению следуют и названия вспомогательных модулей трассировщика, например: ip_conntrack_ftpи ip_conntrack_irc.

      Один из плюсов использования утилит iptables-saveи iptables-restoreсостоит в высокой скорости загрузки и сохранения больших наборов правил. Главный недостаток, связанный с установкой наборов правил из сценариев командной оболочки состоит в том, что команда iptablesкопирует набор правил из пространства ядра в пространство пользователя, вставляет, добавляет или изменяет правило и, наконец, весь набор правил копируется обратно в пространство ядра. Эта последовательность действий выполняется для каждого правила, которое вставляется или изменяется в наборе правил.
      Эта проблема легко решается с помощью iptables-saveи iptables-restoreУтилита iptables-saveзаписывает набор правил в обычный текстовый файл в особом формате. Утилита iptables-restoreзагружает набор правил из файла. Главное преимущество этих утилит состоит в том, что они производят сохранение/восстановление всего набора правил за одно обращение. iptables-save«в один присест» получает из пространства ядра и записывает в файл весь набор правил, а iptables-restoreзагружает из файла и переписывает за одно обращение в пространство ядра набор правил для каждой таблицы. Или другими словами – вместо того, чтобы обращаться огромное число раз к ядру для того чтобы получить набор правил, а затем опять записать его в пространство ядра не меньшее число раз, можно просто сохранить набор правил в файл, а затем загружать его из файла, при этом число перемещений наборов в ядро будет зависеть только от числа используемых таблиц.
      Вы уже наверняка поняли, что эти утилиты могут представлять для вас интерес, особенно если вам приходится загружать огромные наборы правил. Однако использование этих утилит имеет и свои отрицательные стороны, которые мы рассмотрим в следующем разделе.

      У вас может сложиться впечатление, что iptables-restoreможет обрабатывать своего рода сценарии. Пока не может и вероятнее всего – никогда не сможет. В этом и состоит главный недостаток iptables-restore. Чтобы было более понятно – представьте себе случай, когда брандмауэр получает динамический IP-адрес и вы хотите вставить его значение в свои правила во время загрузки системы. Решить эту проблему с помощью iptables-restoreпрактически невозможно.
      Как одно из решений можно предложить написать небольшой скрипт, который определяет значение IP-адреса и затем вставляет его в набор правил (например, с помощью sed) на место некоторого ключевого слова. Здесь вам потребуется создать временный файл, в котором производятся изменения и который затем загружается с помощью iptables-restore. Однако такой вариант решения порождает свои проблемы – вам придется отказаться от утилиты iptables-saveпоскольку она может затереть, созданную вручную, заготовку файла с правилами для iptables-restore. Вобщем – довольно неуклюжее решение.
      Еще один вариант – хранить в файле для iptables-restoreтолько статические правила, а затем с помощью небольшого скрипта добавлять правила с динамическими параметрами. Конечно же вы уже поняли, что это решение такое же неуклюжее как и первое. Вам придется смириться с тем, что iptables-restoreне очень хорошо подходит для случая с динамически назначаемым IP-адресом и вообще для случаев, когда вам потребуется динамически изменять набор правил в зависимости от конфигурации системы и т.п..
      Еще один недостаток iptables-restoreи iptables-saveв том, что их функциональность не всегда соответствует описанной. Проблема состоит в том, что не многие пользуются этими утилитами, еще меньше людей вовлечено в процесс поиска ошибок в этих программах. Поэтому, при использовании некоторых, вновь появившихся, критериев или действий вы можете столкнуться с неожиданным поведением своих правил. Несмотря на возможное существование некоторых проблем, я все же настоятельно рекомендую к использованию эти два инструмента, которые прекрасно работают в большинстве случаев, исключение могут составлять лишь некоторые новые критерии и действия.

      Утилита iptables-save, как я уже упоминал, предназначена для сохранения текущего набора правил в файл, который затем может быть использован утилитой iptables-restore. Эта команда очень проста в использовании и имеет всего два аргумента.
       iptables-save[-c] [-t table]
      Первый аргумент -c(допустимо использовать более длинный вариант –counters) заставляет iptables-saveсохранить знчения счетчиков байт и пакетов. Это делает возможным рестарт брандмауэра без потери счетчиков, которые могут использоваться для подсчета статистики. По-умолчанию, при запуске без ключа -с, сохранение счетчиков не производится.
      С помощью ключа -t(более длинный вариант –table) можно указать имя таблицы для сохранения. Если ключ -tне задан, то сохраняются все таблицы. Ниже приведен пример работы команды iptables-saveв случае, когда набор не содержит ни одного правила.
      # Generated by iptables-save v1.2.6a on Wed Apr 24 10:19:17 2002
      *filter
      :INPUT ACCEPT [404:19766]
      :FORWARD ACCEPT [0:0]
      :OUTPUT ACCEPT [530:43376]
      COMMIT
      # Completed on Wed Apr 24 10:19:17 2002
      # Generated by iptables-save v1.2.6a on Wed Apr 24 10:19:17 2002
      *mangle
      :PREROUTING ACCEPT [451:22060]
      :INPUT ACCEPT [451:22060]
      :FORWARD ACCEPT [0:0]
      :OUTPUT ACCEPT [594:47151]
      :POSTROUTING ACCEPT [594:47151]
      COMMIT
      # Completed on Wed Apr 24 10:19:17 2002
      # Generated by iptables-save v1.2.6a on Wed Apr 24 10:19:17 2002
      *nat
      :PREROUTING ACCEPT [0:0]
      :POSTROUTING ACCEPT [3:450]
      :OUTPUT ACCEPT [3:450]
      COMMIT
      # Completed on Wed Apr 24 10:19:17 2002
      Строки, начинающиеся с символа #, являются комментариями. Имена таблиц начинаются с символа * (звездочка), например: *mangle. После каждого имени таблицы следуют описания цепочек и правил. Описания цепочек записываются в формате :<chain-name> <chain-policy> [<packet-counter>:<byte-counter>], где <chain-name> – это название цепочки (например PREROUTING), <chain-policy> – политика по-умолчанию (например ACCEPT). Завершают описание цепочки значения счетчиков пакетов и байт, те самые счетчики, которые вы получите в результате выполнения команды iptables -L -v. Описание каждой таблицы завершает ключевое слово COMMIT, которое означает, что в этой точке набор правил для данной таблицы будет передан в пространство ядра.
      Пример выше показал как выглядит содержимое пустого набора правил, сохраненного утилитой iptables-save. Ниже показан результат сохранения небольшого набора правил ( Iptables-save ruleset) :
      # Generated by iptables-save v1.2.6a on Wed Apr 24 10:19:55 2002
      *filter
      :INPUT DROP [1:229]
      :FORWARD DROP [0:0]
      :OUTPUT DROP [0:0]
      [0:0] -A INPUT -m state –state RELATED,ESTABLISHED -j ACCEPT
      [0:0] -A FORWARD -i eth0 -m state –state RELATED,ESTABLISHED -j ACCEPT
      [0:0] -A FORWARD -i eth1 -m state –state NEW,RELATED,ESTABLISHED -j ACCEPT
      [0:0] -A OUTPUT -m state –state NEW,RELATED,ESTABLISHED -j ACCEPT
      COMMIT
      # Completed on Wed Apr 24 10:19:55 2002
      # Generated by iptables-save v1.2.6a on Wed Apr 24 10:19:55 2002
      *mangle
      :PREROUTING ACCEPT [658:32445]
      :INPUT ACCEPT [658:32445]
      :FORWARD ACCEPT [0:0]
      :OUTPUT ACCEPT [891:68234]
      :POSTROUTING ACCEPT [891:68234]
      COMMIT
      # Completed on Wed Apr 24 10:19:55 2002
      # Generated by iptables-save v1.2.6a on Wed Apr 24 10:19:55 2002
      *nat
      :PREROUTING ACCEPT [1:229]
      :POSTROUTING ACCEPT [3:450]
      :OUTPUT ACCEPT [3:450]
      [0:0] -A POSTROUTING -o eth0 -j SNAT –to-source 195.233.192.1
      COMMIT
      # Completed on Wed Apr 24 10:19:55 2002
      Из примера виден результат действия аргумента -c– перед каждым правилом и в строке описания каждой цепочки имеются числа, отображающие содержимое счетчиков пакетов и байт. Сразу замечу, что набор правил утилита iptables-saveвыдает на стандартный вывод, поэтому, при сохранении набора в файл команда должна выглядеть примерно так:
       iptables-save -c > /etc/iptables-save
      Эта команда запишет весь набор правил, вместе с содержимым счетчиков, в файл с именем /etc/iptables-save.

      Утилита iptables-restoreиспользуется для восстановления (загрузки) набора правил, который ранее был сохранен утилитой iptables-save. Набор правил утилита получает со стандартного ввода и не может загружать его из файла напрямую. Команда имеет следующий синтаксис:
       iptables-restore[-c] [-n]
      Ключ -c(более длинный вариант –counters) заставляет восстанавливать значения счетчиков.
      Указание ключа -n(более длинный вариант –noflush) сообщает iptables-restoreо том, что правила должны быть добавлены к имеющимся. По-умолчанию утилита iptables-restore(без ключа -n) очистит содержимое таблиц и цепочек перед загрузкой нового набора правил.
      Для загрузки набора правил утилитой iptables-restoreиз файла можно предложить несколько вариантов, но наиболее употребимый:
       cat /etc/iptables-save | iptables-restore -c
      В результате выполнения этой команды содержимое файла /etc/iptables-save будет прочитано утилитой catи перенаправленно на стандартный ввод утилиты iptables-restore. Можно было бы привести еще целый ряд команд, с помощью которых можно организовать загрузку набора правил из файла, но это выходит за рамки темы, поэтому оставлю читателю возможность самому найти более удобный для него вариант.
      После исполнения этой команды набор правил должен загрузиться и все должно работать. Если это не так, то скорее всего вы допустили ошибку при наборе команды.

      Как уже говорилось выше, каждое правило – это строка, содержащая в себе критерии определяющие, подпадает ли пакет под заданное правило, и действие, которое необходимо выполнить в случае выполнения критерия. В общем виде правила записываются примерно так:
       iptables[-t table] command [match] [target/jump]
      Нигде не утверждается, что описание действия (target/jump) должно стоять последним в строке, однако, такая нотация более удобочитаема. Как бы то ни было, но чаще всего вам будет встречаться именно такой способ записи правил.
      Если в правило не включается спецификатор [-t table], то по умолчанию предполагается использование таблицы filter, если же предполагается использование другой таблицы, то это требуется указать явно. Спецификатор таблицы так же можно указывать в любом месте строки правила, однако более или менее стандартом считается указание таблицы в начале правила.
      Далее, непосредственно за именем таблицы, должна стоять команда. Если спецификатора таблицы нет, то команда всегда должна стоять первой. Команда определяет действие iptables, например: вставить правило, или добавить правило в конец цепочки, или удалить правило и т.п.
      Раздел match задает критерии проверки, по которым определяется подпадает ли пакет под действие этого правила или нет. Здесь мы можем указать самые разные критерии – IP-адрес источника пакета или сети, IP-адрес места назначения,порт, протокол, сетевой интерфейс и т.д. Существует множество разнообразных критериев, но об этом – несколько позже.
      И наконец target указывает, какое действие должно быть выполнено при условии выполнения критериев в правиле. Здесь можно заставить ядро передать пакет в другую цепочку правил, «сбросить» пакет и забыть про него, выдать на источник сообщение об ошибке и т.п.

      Опция -tуказывает на используемую таблицу. По умолчанию используется таблица filter. С ключом -tприменяются следующие опции.
       Таблица 6-1. Таблицы
      (Таблица – Описание)
 
       Таблица: nat
       Описание: Таблица natиспользуется главным образом для преобразования сетевых адресов ( Network Address Translation). Через эту таблицу проходит только первый пакет из потока. Преобразования адресов автоматически применяется ко всем последующим пакетам. Это один из факторов, исходя из которых мы не должны осуществлять какую-либо фильтрацию в этой таблице. Цепочка PREROUTINGиспользуется для внесения изменений в пакеты на входе в брандмауэр. Цепочка OUTPUTиспользуется для преобразования адресов в пакетах, созданных приложениями внутри брандмауэра, перед принятием решения о маршрутизации. И последняя цепочка в этой таблице – POSTROUTING, которая используется для преобразования пакетов перед выдачей их в сеть.
 
       Таблица: mangle
       Описание: Эта таблица используется для внесения изменений в заголовки пакетов. Примером может служить изменение поля TTL, TOSили MARK. Важно: в действительности поле MARKне изменяется, но в памяти ядра заводится структура, которая сопровождает данный пакет все время его прохождения через брандмауэр, так что другие правила и приложения на данном брандмауэре (и только на данной брандмауэре) могут использовать это поле в своих целях. Таблица имеет пять цепочек PREROUTING, POSTROUTING, INPUT, OUTPUTи FORWARD. PREROUTINGиспользуется для внесения изменений на входе в брандмауэр, перед принятием решения о маршрутизации. POSTROUTINGиспользуется для внесения изменений на выходе из брандмауэра, после принятия решения о маршрутизации. INPUT– для внесения изменений в пакеты перед тем как они будут переданы локальному приложению внутри брандмауэра. OUTPUT– для внесения изменений в пакеты, поступающие от приложений внутри брандмауэра. FORWARD– для внесения изменений в транзитные пакеты после первого принятия решения о ипршрутизации, но перед последним принятием решения о ипршрутизации. Замечу, что таблица mangleни в коем случае не должна использоваться для преобразования сетевых адресов или маскарадинга ( Network Address Translation, Masquerading), поскольку для этих целей имеется таблица nat.
 
       Таблица: filter
       Описание: Таблица filterиспользуется главным образом для фильтрации пакетов. Для примера, здесь мы можем выполнить DROP, LOG, ACCEPTили REJECTбез каких либо ограничений, которые имеются в других таблицах. Имеется три встроенных цепочки. Первая – FORWARD, используемая для фильтрации пакетов, идущих транзитом через брандмауэр. Цепочку INPUTпроходят пакеты, которые предназначены локальным приложениям (брандмауэру). И цепочка OUTPUT– используется для фильтрации исходящих пакетов, сгенерированных приложениями на самом брандмауэре.
 
      Выше мы рассмотрели основные отличия трех имеющихся таблиц. Каждая из них должна использоваться только в своих целях, и вы должны это понимать. Нецелевое использование таблиц может привести к ослаблению защиты брандмауэра и сети, находящейся за ним. Позднее, в главе Порядок прохождения таблиц и цепочек, мы подробнее остановимся на этом.

      Ниже приводится список команд и правила их использования. Посредством команд мы сообщаем iptablesчто мы предполагаем сделать. Обычно предполагается одно из двух действий – добавление нового правила в цепочку или удаление существующего правила из той или иной таблицы. Далее приведены команды, которые используются в iptables.
       Таблица 6-2. Команды
      (Команда – Пример – Описание)
 
       Команда: -A, –append
       Пример: iptables -A INPUT ...
       Описание: Добавляет новое правило в конец заданной цепочки.
 
       Команда: -D, –delete
       Пример: iptables -D INPUT –dport 80 -j DROP, iptables -D INPUT 1
       Описание: Удаление правила из цепочки. Команда имеет два формата записи, первый – когда задается критерий сравнения с опцией -D (см. первый пример), второй – порядковый номер правила. Если задается критерий сравнения, то удаляется правило, которое имеет в себе этот критерий, если задается номер правила, то будет удалено правило с заданным номером. Счет правил в цепочках начинается с 1.
 
       Команда: -R, –replace
       Пример: iptables -R INPUT 1 -s 192.168.0.1 -j DROP
       Описание: Эта команда заменяет одно правило другим. В основном она используется во время отладки новых правил.
 
       Команда: -I, –insert
       Пример: iptables -I INPUT 1 –dport 80 -j ACCEPT
       Описание: Вставляет новое правило в цепочку. Число, следующее за именем цепочки указывает номер правила, перед которым нужно вставить новое правило, другими словами число задает номер для вставляемого правила. В примере выше, указывается, что данное правило должно быть 1-м в цепочке INPUT.
 
       Команда: -L, –list
       Пример: iptables -L INPUT
       Описание: Вывод списка правил в заданной цепочке, в данном примере предполагается вывод правил из цепочки INPUT. Если имя цепочки не указывается, то выводится список правил для всех цепочек. Формат вывода зависит от наличия дополнительных ключей в команде, например -n, -v, и пр.
 
       Команда: -F, –flush
       Пример: iptables -F INPUT
       Описание: Сброс (удаление) всех правил из заданной цепочки (таблицы). Если имя цепочки и таблицы не указывается, то удаляются все правила, во всех цепочках. (Хочется от себя добавить, что если не указана таблица ключом -t (–table), то очистка цепочек производится только в таблице filter, прим. перев.)
 
       Команда: -Z, –zero
       Пример: iptables -Z INPUT
       Описание: Обнуление всех счетчиков в заданной цепочке. Если имя цепочки не указывается, то подразумеваются все цепочки. При использовании ключа -vсовместно с командой -L, на вывод будут поданы и состояния счетчиков пакетов, попавших под действие каждого правила. Допускается совместное использование команд -Lи -Z. В этом случае будет выдан сначала список правил со счетчиками, а затем произойдет обнуление счетчиков.
 
       Команда: -N, –new-chain
       Пример: iptables -N allowed
       Описание: Создается новая цепочка с заданным именем в заданной таблице В выше приведенном примере создается новая цепочка с именем allowed. Имя цепочки должно быть уникальным и не должно совпадать с зарезервированными именами цепочек и действий (такими как DROP, REJECTи т.п.)
 
       Команда: -X, –delete-chain
       Пример: iptables -X allowed
       Описание: Удаление заданной цепочки из заданной таблицы. Удаляемая цепочка не должна иметь правил и не должно быть ссылок из других цепочек на удаляемую цепочку. Если имя цепочки не указано, то будут удалены все цепочки заданной таблице кроме встроенных.
 
       Команда: -P, –policy
       Пример: iptables -P INPUT DROP
       Описание: Задает политику по-умолчанию для заданной цепочки. Политика по-умолчанию определяет действие, применяемое к пакетам не попавшим под действие ни одного из правил в цепочке. В качестве политики по умолчанию допускается использовать DROPи ACCEPT.
 
       Команда: -E, –rename-chain
       Пример: iptables -E allowed disallowed
       Описание: Команда -Eвыполняет переименование пользовательской цепочки. В примере цепочка allowed будет переименована в цепочку disallowed. Эти переименования не изменяют порядок работы, а носят только косметический характер.
 
      Команда должна быть указана всегда. Список доступных команд можно просмотреть с помощью команды iptables -hили, что тоже самое, iptables –help. Некоторые команды могут использоваться совместно с дополнительными ключами. Ниже приводится список дополнительных ключей и описывается результат их действия. При этом заметьте, что здесь не приводится дополнительных ключей, которые используются при построении критериев (matches) или действий (targets). Эти опции мы будем обсуждать далее.
       Таблица 6-3. Дополнительные ключи
      (Ключ – Команды, с которыми используется – Описание)
 
       Ключ: -v, –verbose
       Команды, с которыми используется: –list, –append, –insert, –delete, –replace
       Описание: Используется для повышения информативности вывода и, как правило, используется совместно с командой –list. В случае использования с командой –list, в вывод этой команды включаются так же имя интерфейса, счетчики пакетов и байт для каждого правила. Формат вывода счетчиков предполагает вывод кроме цифр числа еще и символьные множители K (x1000), M (x1,000,000) и G (x1,000,000,000). Для того, чтобы заставить команду –listвыводить полное число (без употребления множителей) требуется применять ключ -x, который описан ниже. Если ключ -v, –verboseиспользуется с командами –append, –insert, –deleteили –replace, то будет выведен подробный отчет о произведенной операции.
 
       Ключ: -x, –exact
       Команды, с которыми используется: –list
       Описание: Для всех чисел в выходных данных выводятся их точные значения без округления и без использования множителей K, M, G. Этот ключ используется только с командой –listи не применим с другими командами.
 
       Ключ: -n, –numeric
       Команды, с которыми используется: –list
       Описание: Заставляет iptables выводить IP-адреса и номера портов в числовом виде предотвращая попытки преобразовать их в символические имена. Данный ключ используется только с командой –list.
 
       Ключ: –line-numbers
       Команды, с которыми используется: –list
       Описание:Ключ –line-numbersвключает режим вывода номеров строк при отображении списка правил командой –list. Номер строки соответствует позиции правила в цепочке. Этот ключ используется только с командой –list.
 
       Ключ: -c, –set-counters
       Команды, с которыми используется: –insert, –append, –replace
       Описание: Этот ключ используется для установки начального значения счетчиков пакетов и байт в заданное значение при создании нового правила. Например, ключ –set-counters 20 4000 установит счетчик пакетов = 20, а счетчик байт = 4000.
 
       Ключ: –modprobe
       Команды, с которыми используется: Все
       Описание: Ключ –modprobeопределяет команду загрузки модуля ядра. Данный ключ может использоваться в случае, когда модули ядра находится вне пути поиска (search path). Этот ключ может использоваться с любой командой.

      Здесь мы подробнее остановимся на критериях выделения пакетов. Я разбил все критерии на пять групп. Первая – общие критериикоторые могут использоваться в любых правилах. Вторая – TCP критериикоторые применяются только к TCPпакетам. Третья – UDP критериикоторые применяются только к UDPпакетам. Четвертая – ICMP критериидля работы с ICMPпакетами. И наконец пятая – специальные критерии, такие как state, owner, limit и пр.

6.4.1. Общие критерии

6.4.2. Неявные критерии

6.4.3. Явные критерии

6.4.4. Критерий «мусора» (Unclean match)

      Действия и переходы сообщают правилу, что необходимо выполнить, если пакет соотвествует заданному критерию. Чаще всего употребляются действия ACCEPTи DROP. Однако, давайте кратко рассмотрим понятие переходов.
      Описание переходов в правилах выглядит точно так же как и описание действий, т.е. ставится ключ -jи указывается название цепочки правил, на которую выполняется переход. На переходы накладывается ряд ограничений, первое – цепочка, на которую выполняется переход, должна находиться в той же таблице, что и цепочка, из которой этот переход выполняется, второе – цепочка , являющаяся целью перехода должна быть создана до того как на нее будут выполняться переходы. Например, создадим цепочку tcp_packetsв таблице filter с помощью команды
       iptables -N tcp_packets
      Теперь мы можем выполнять переходы на эту цепочку подобно:
       iptables -A INPUT -p tcp -j tcp_packets
      Т.е. встретив пакет протокола tcp, iptables произведет переход на цепочку tcp_packetsи продолжит движение пакета по этой цепочке. Если пакет достиг конца цепочки то он будет возвращен в вызывающую цепочку (в нашем случае это цепочка INPUT) и движение пакета продолжится с правила, следующего за правилом, вызвавшем переход. Если к пакету во вложенной цепочке будет применено действие ACCEPT, то автоматически пакет будет считаться принятым и в вызывающей цепочке и уже не будет продолжать движение по вызывающим цепочкам. Однако пакет пойдет по другим цепочкам в других таблицах. Дополнительную информацию о порядке прохождения цепочек и таблиц вы сможете получить в главе Порядок прохождения таблиц и цепочек.
      Действие – это предопределенная команда, описывающая действие, которое необходимо выполнить, если пакет совпал с заданным критерием. Например, можно применить действие DROPили ACCEPTк пакету, в зависимости от наших нужд. Существует и ряд других действий, которые описываются ниже в этом разделе. В результате выполнения одних действий, пакет прекращает свое прохождение по цепочке, например DROPи ACCEPT, в результате других, после выполнения неких операций, продолжает проверку, например, LOG, в результате работы третьих даже видоизменяется, например DNATи SNAT, TTLи TOS, но так же продолжает продвижение по цепочке.

6.5.1. Действие ACCEPT

6.5.2. Действие DNAT

6.5.3. Действие DROP

6.5.4. Действие LOG

6.5.5. Действие MARK

6.5.6. Действие MASQUERADE

6.5.7. Действие MIRROR

6.5.8. Действие QUEUE

6.5.9. Действие REDIRECT

6.5.10. Действие REJECT

6.5.11. Действие RETURN

6.5.12. Действие SNAT

6.5.13. Действие TOS

6.5.14. Действие TTL

6.5.15. Действие ULOG

      Итак, все готово для разбора файла примера rc.firewall.txt(сценарий включен в состав данного документа в приложении Примеры сценариев). Он достаточно велик, но только из-за большого количества комментариев. Сейчас я предлагаю вам просмотреть этот файл, чтобы получить представление о его содержимом и затем вернуться сюда за более подробными пояснениями.

      Все сценарии, описанные в этом руководстве, имеют определенную структуру. Сделано это для того, чтобы сценарии были максимально похожи друг на друга, облегчая тем самым поиск различий между ними. Эта структура довольно хорошо описывается в этой главе. Здесь я надеюсь дать вам понимание, почему все сценарии были написаны именно так и почему я выбрал именно эту структуру.
 
       ПРИМЕЧАНИЕ: Обратите внимание на то, что эта структура может оказаться далеко неоптимальной для ваших сценариев. Эта структура выбрана лишь для лучшего объяснения хода моих мыслей.

8.1.1. Структура

 
 
      Сценарий rc.firewall.txt – основное ядро, на котором основывается остальные сценарии. Глава Файл rc.firewallдостаточно подробно описывает сценарий. Сценарий написан для домашней сети, где вы имеете одну ЛОКАЛЬНУЮ СЕТЬ и одно подключение к Internet. Этот сценарий также исходит из предположения, что вы имеете статический IP адрес, и следовательно не используете DHCP, PPP, SLIPлибо какой то другой протокол, который назначает IP динамически. В противном случае возьмите за основу сценарий rc.DHCP.firewall.txt
      Сценарий требует, чтобы следующие опции были скомпилированы либо статически, либо как модули. Без какой либо из них сценарий будет неработоспособен Кроме того, изменения, которые вы возможно внесете в текст сценария, могут потребовать включения дополнительных возможностей в ваше ядро.
      CONFIG_NETFILTER
      CONFIG_IP_NF_CONNTRACK
      CONFIG_IP_NF_IPTABLES
      CONFIG_IP_NF_MATCH_LIMIT
      CONFIG_IP_NF_MATCH_STATE
      CONFIG_IP_NF_FILTER
      CONFIG_IP_NF_NAT
      CONFIG_IP_NF_TARGET_LOG

 
 
      Сценарий rc.DMZ.firewall.txt был написан для тех, кто имеет доверительную локальную сеть, одну «Демилитаризированную Зону» и одно подключение к Internet. Для доступа к серверам Демилитаризированной Зоны, в данном случае, извне, используется NAT «один к одному», то есть, Вы должны заставить брандмауэр распознавать пакеты более чем для одного IP адреса.
      Сценарий требует, чтобы следующие опции были скомпилированы либо статически, либо как модули. Без какой либо из них сценарий будет неработоспособен
      CONFIG_NETFILTER
      CONFIG_IP_NF_CONNTRACK
      CONFIG_IP_NF_IPTABLES
      CONFIG_IP_NF_MATCH_LIMIT
      CONFIG_IP_NF_MATCH_STATE
      CONFIG_IP_NF_FILTER
      CONFIG_IP_NF_NAT
      CONFIG_IP_NF_TARGET_LOG
      Сценарий работает с двумя внутренними сетями, как это продемонстрировано на рисунке. Одна использует диапазон IP адресов 192.168.0.0/24 и является Доверительной Внутренней Сетью. Другая использует диапазон 192.168.1.0/24 и называется Демилитаризированной Зоной (DMZ), для которой мы будем выполнять преобразование адресов (NAT) «один к одному». Например, если кто-то из Интернет отправит пакет на наш DNS_IP, то мы выполним DNATдля передачи пакета на DNSв DMZ. Если бы DNATне выполнялся, то DNS не смог бы получить запрос, поскольку он имеет адрес DMZ_DNS_IP, а не DNS_IP. Трансляция выполняется следующим правилом:
       $IPTABLES -t nat -A PREROUTING -p TCP -i $INET_IFACE -d $DNS_IP \ –dport 53 -j DNAT –to-destination $DMZ_DNS_IP
      Для начала напомню, что DNATможет выполняться только в цепочке PREROUTINGтаблицы nat. Согласно этому правилу, пакет должен приходить по протоколу TCPна $INET_IFACE с адресатом IP, который соответствует нашему $DNS_IP, и направлен на порт 53. Если встречен такой пакет, то выполняется подмена адреса назначения, или DNAT. Действию DNATпередается адрес для подмены с помощью ключа –to-destination $DMZ_DNS_IP. Когда через брандмауэр возвращается пакет ответа, то сетевым кодом ядра адрес отправителя будет автоматически изменен с $DMZ_DNS_IP на $DNS_IP, другими словами обратная детрансляция адресов выполняется автоматически и не требует создания дополнительных правил.
      Теперь вы уже должны понимать как работает DNAT, чтобы самостоятельно разобраться в тексте сценария без каких либо проблем. Если что-то для вас осталось не ясным и это не было рассмотрено в данном документе, то вы можете сообщить мне об этом – вероятно это моя ошибка.

 
 
      Сценарий The rc.DHCP.firewall.txt очень похож на оригинал rc.firewall.txt. Однако, этот сценарий больше не использует переменную STATIC_IP, это и является основным отличием от оригинала rc.firewall.txt. Причина в том, что rc.firewall.txt не будет работать в случае динамического IP адреса. Изменения, по сравнению с оригиналом – минимальны. Этот сценарий будет полезен в случае DHCP, PPPи SLIPподключения к Интернет.
      Сценарий требует, чтобы следующие опции были скомпилированы либо статически, либо как модули. Без какой либо из них сценарий будет неработоспособен
      CONFIG_NETFILTER
      CONFIG_IP_NF_CONNTRACK
      CONFIG_IP_NF_IPTABLES
      CONFIG_IP_NF_MATCH_LIMIT
      CONFIG_IP_NF_MATCH_STATE
      CONFIG_IP_NF_FILTER
      CONFIG_IP_NF_NAT
      CONFIG_IP_NF_TARGET_MASQUERADE
      CONFIG_IP_NF_TARGET_LOG
      Главное отличие данного скрипта состоит в удалении переменной STATIC_IP и всех ссылок на эту переменную. Вместо нее теперь используется переменная INET_IFACE. Другими словами -d $STATIC_IPзаменяется на -i $INET_IFACE. Собственно это все, что нужно изменить в действительности. (Хочется отметить, что в данном случае под STATIC_IP автор понимает переменную INET_IP прим. перев.)
      Мы больше не можем устанавливать правила в цепочке INPUTподобных этому: –in-interface $LAN_IFACE –dst $INET_IP. Это в свою очередь вынуждает нас строить правила основываясь только на сетевом интерфейсе. Например, пусть на брандмауэре запущен HTTP сервер. Если мы приходим на главную страничку, содержащую статическую ссылку обратно на этот же сервер, который работает под динамическим адресом, то мы можем «огрести» немало проблем. Хост, который проходит через NAT, запросит через DNS IP адрес HTTP сервера, после чего попробует получить доступ к этому IP. Если брандмауэр производит фильтрацию по интерфейсу и IP адресу, то хост не сможет получить ответ, поскольку цепочка INPUTотфильтрует такой запрос. Это так же справедливо и для некоторых случаев когда мы имеем статический IP адрес, но тогда это можно обойти, используя правила, которые проверяют пакеты, приходящие с LAN интерфейса на наш INET_IP и выполнять ACCEPTдля них.
      После всего вышесказанного, не такой уж плохой может показаться мысль о создании сценария, который бы обрабатывал динамический IP. Например, можно было бы написать скрипт, который получает IP адрес через ifconfigи подставляет его в текст сценария (где определяется соответствующая переменная), который «поднимает» соединение с Интернет. Замечательный сайт linuxguruz.org имеет огромную коллекцию скриптов, доступных для скачивания. Ссылку на linuxguruz.org вы найдете в приложении Ссылки на другие ресурсы.
 
       ПРИМЕЧАНИЕ: Этот сценарий менее безопасен чем rc.firewall.txt. Я настоятельно рекомендую вам использовать сценарий rc.firewall.txt, если это возможно, так как rc.DHCP.firewall.txt более открыт для нападений извне.
      Также, можно добавить в ваши сценарии что нибудь вроде этого:
       INET_IP=`ifconfig $INET_IFACE | grep inet | cut -d : -f 2 | \ cut -d ' ' -f 1`
      Выше приведенная команда получает динамический IP от интерфейса. Более совершенные методы получения IP адреса вы найдете в сценарии retreiveip.txt. Однако у такого подхода есть серьезные недостатки, которые описанны ниже.
      1. Если скрипт запускается из другого сценария, который в свою очередь запускается демоном PPP, то это может привести к «зависанию» всех, уже установленных соединений, из-за правил, которые отбраковывают пакеты со статусом NEW и со сброшенным битом SYN. (смотри раздел Пакеты со статусом NEW и со сброшенным битом SYN). Проблему конечно можно разрешить удалением этих правил, но такое решение довольно сомнительно с точки зрения безопасности.
      2. Предположим, что у вас есть набор статических правил, довольно грубо будет постоянно стирать и добавлять правила, к тому же рискуя повредить существующие.
      3. Это может привести к излишним усложнениям, что в свою очередь, влечет ослабление защиты. Чем проще скрипт, тем проще его сопровождать.

 
 
      Сценарий rc.UTIN.firewall.txt, в отличие от других сценариев, блокирует LAN, которая находится за брандмауэром. Мы доверяем внутренним пользователям не больше чем пользователям из Internet. Другими словами, мы не доверяем никому, ни в Интернет, ни в локальной сети, с которыми мы связаны. Поэтому доступ к Интернет ограничивается только протоколами POP3, HTTP и FTP.
      Этот сценарий следует золотому правилу – «не доверяй никому, даже собственным служащим». Это грустно но факт – большая часть атак и взломов, которым подвергается компания, производится служащими компаний из локальных сетей. Этот сценарий, надеюсь, даст некоторые сведения, которые помогут вам усилить вашу межсетевую защиту. Он мало отличается от оригинала rc.firewall.txt, но содержит подсказки о том, что мы обычно пропускаем.
      Сценарий требует, чтобы следующие опции были скомпилированы либо статически, либо как модули. Без какой либо из них сценарий будет неработоспособен
      CONFIG_NETFILTER
      CONFIG_IP_NF_CONNTRACK
      CONFIG_IP_NF_IPTABLES
      CONFIG_IP_NF_MATCH_LIMIT
      CONFIG_IP_NF_MATCH_STATE
      CONFIG_IP_NF_FILTER
      CONFIG_IP_NF_NAT
      CONFIG_IP_NF_TARGET_LOG
      This script follows the golden rule to not trust anyone, not even our own employees. This is a sad fact, but a large part of the hacks and cracks that a company gets hit by is a matter of people from their own staff perpetrating the hit. This script will hopefully give you some clues as to what you can do with your firewall to strengthen it up. It's not very different from the original rc.firewall.txt script, but it does give a few hints at what we would normally let through etc.

      Сценарий rc.test-iptables.txt предназначен для проверки различных цепочек но может потребовать дополнительных настроек, в зависимости от вашей конфигурации, например, включения ip_forwardingили настройки masquerading и т.п. Тем не менее в большинстве случаев с базовыми настройками, когда настроены основные таблицы, этот сценарий будет работоспособен. В действительности, в этом сценарии производится установка действий LOGна ping-запросы и ping-ответы. Таким способом появляется возможность зафиксировать в системном журнале какие цепочки проходились и в каком порядке. Запустите сценарий и затем выполните следующие команды:
       ping -c 1 host.on.the.internet
      И во время исполнения первой команды выполните tail -n 0 -f /var/log/messages. Теперь вы должны ясно видеть все используемые цепочки и порядок их прохождения.
 
       ПРИМЕЧАНИЕ: Этот сценарий был написан исключительно в демонстрационных целях. Другими словами, не следует иметь правила для журналирования подобно этим, которые регистрируют все пакеты без ограничений. В противном случае вы рискуете стать легкой добычей для злоумышленника, который может засыпать вас пакетами, «раздуть» ваш лог, что может вызвать «Отказ в обслуживании», а после этого перейти к реальному взлому вашей системы не боясь быть обнаруженным, поскольку не сможет быть зарегистрирован системой.

      Сценарий rc.flush-iptables.txt в действительности не имеет самостоятельной ценности поскольку он сбрасывает все ваши таблицы и цепочки. В начале сценария, устанавливаются политики по-умолчанию ACCEPT для цепочек INPUT, OUTPUTи FORWARDв таблице filter. После этого сбрасываются в заданную по-умолчанию политики для цепочек PREROUTING, POSTROUTINGи OUTPUTтаблицы nat. Эти действия выполняются первыми, чтобы не возникало проблем с закрытыми соединениями и блокируемыми пакетами. Фактически, этот сценарий может использоваться для подготовки брандмауэра к настройке и при отладке ваших сценариев, поэтому здесь мы заботимся только об очистке набора правил и установке политик по-умолчанию.
      Когда выполнена установка политик по-умолчанию, мы переходим к очистке содержимого цепочек в таблицах filterи nat, а затем производится удаление всех, определенных пользователем, цепочек. После этого работа скрипта завершается. Если вы используете таблицу mangle, то вы должны будете добавить в сценарий соответствующие строки для обработки этой таблицы.
 
       ПРИМЕЧАНИЕ: В заключение пару слов. Очень многие спрашивают меня, а почему бы не поместить вызов этого сценария в rc.firewal, написав что нибудь типа rc.firewall start для запуска скрипта. Я не сделал этого до сих пор, потому что считаю, что учебный материал должен нести в себе основные идеи и не должен быть перегружен разнообразными сценариями со странным синтаксисом. Добавление специфичного синтаксиса делает сценарии менее читабельными, а сам учебный материал более сложным в понимании, поэтому данное руководство остается таким, каково оно есть, и продолжит оставаться таким.

      Сценарий limit-match.txt написан с целью продемонстрировать работу с критерием limit. Запустите этот скрипт и попробуйте отправлять на этот хост ping-пакеты с различными интервалами.

      Сценарий pid-owner.txt демонстрирует использование критерия –pid-owner. Фактически, этот сценарий ничего не блокирует, поэтому, чтобы увидеть его действие, вам потребуется воспользоваться командой iptables -L -v.

      Сценарий sid-owner.txt демонстрирует использование критерия –sid-owner. Фактически, этот сценарий ничего не блокирует, поэтому, чтобы увидеть его действие, вам потребуется воспользоваться командой iptables -L -v.

      Небольшой пример ttl-inc.txt, демонстрирующий как можно сделать брандмауэр/роутер «невидимым» для трассировщиков, осложняя тем самым работу атакующего.

      Небольшой пример iptsave-saved.txt,, о котором говорилось в главе Сохранение и восстановление больших наборов правил, иллюстрирующий работу команды iptables-save. Не является исполняемым сценарием и предназначен лишь для демонстрации результата работы iptables-save.

      Чтобы вывести список правил нужно выполнить команду iptablesс ключом L, который кратко был описан ранее в главе Как строить правила. Выглядит это примерно так:
       iptables -L
      Эта команда выведет на экран список правил в удобочитаемом виде. Номера портов будут преобразованы в имена служб в соответствии с файлом /etc/services, IP адреса будут преобразованы в имена хостов через разрешение имен в службе DNS. С разрешением (resolving) имен могут возникнуть некоторые проблемы, например, имея сеть 192.168.0.0/16 служба DNSне сможет определить имя хоста с адресом 192.168.1.1, в результате произойдет подвисание команды. Чтобы обойти эту проблему следует выполнить вывод списка правил с дополнительным ключом:
       iptables -L -n
      Чтобы вывести дополнительную информацию о цепочках и правилах, выполните
       iptables -L -n -v
      Не забывайте о ключе -t, который может быть использован для просмотра таблиц nat и mangle, например:
       iptables -L -t nat
      В файловой системе /proc имеется ряд файлов, которые содержат достаточно интересную для нас информацию. Например, допустим нам захотелось просмотреть список соединений в таблице conntrack. Это основная таблица, которая содержит список трассируемых соединений и в каком состоянии каждое из них находится. Для просмотра таблицы выполните команду
       cat /proc/net/ip_conntrack | less

      По мере того как вы продолжите углубляться в исследование iptables, перед вами все актуальнее будет вставать вопрос об удалении отдельных правил из цепочек без необходимости перезагрузки машины. Сейчас я попробую на него ответить. Если вы по ошибке добавили какое либо правило, то вам нужно только заменить команду -Aна команду -Dв строке правила. iptablesнайдет заданное правило и удалит его. Если имеется несколько правил, которые выглядят как заданный шаблон для удаления, то будет стерто первое из найденных правил. Если такой порядок вещей вас не устраивает, то команде -D, в качестве параметра, можно передать номер удаляемой строки, например, команда iptables -D INPUT 10сотрет десятое правило в цепочке INPUT. (Чтобы узнать номер правила, подайте команду iptables -L НАЗВАНИЕ_ЦЕПОЧКИ –line-numbers, тогда правила будут выводиться со своими номерами прим. перев.)
      Для удаления содержимого целой цепочки используйте команду -F. Например: iptables -F INPUT– сотрет все правила в цепочке INPUT, однако эта команда не изменяет политики цепочки по-умолчанию, так что если она установлена как DROPто будет блокироваться все, что попадает в цепочку INPUT. Чтобы сбросить политику по-умолчанию, нужно просто установить ее в первоначальное состояние, например iptables -P INPUT ACCEPT. (И еще: если таблица не указана явно ключом -t (–table), то очистка цепочек производится ТОЛЬКОв таблице filter, прим. перев.)
      Мною был написан небольшой сценарий (описанный несколько выше) который производит очистку всех таблиц и цепочек, и переустанавливает политики цепочек в iptables. Запомните, что при использовании таблицы mangleвам необходимо внести дополнения в этот сценарий, поскольку он ее не обрабатывает.

      Вы можете столкнуться с несколькими проблемами при попытке загрузить тот или иной модуль. Например, может быть выдано сообщение об отсутствии запрашиваемого модуля
      insmod: iptable_filter: no module by that name found
      Пока еще нет причин для беспокойства. Вполне возможно, что запрашиваемый модуль (или модули) был связан с ядром статически. Это первое, что вы должны проверить. В примере, приведенном выше, произошла ошибка при загрузке таблицы filter. Чтобы проверить наличие этой таблицы просто запустите команду:
       iptables -t filter -L
      Если все нормально, то эта команда выведет список всех цепочек из таблицы filter. Вывод должен выглядеть примерно так:
      Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination
      Если таблица filter отсутствует, то вывод будет примерно следующим
      iptables v1.2.5: can't initialize iptables table `filter': Table \ does not exist (do you need to insmod?) Perhaps iptables or your kernel needs to be upgraded.
      Это уже серьезнее, так как это сообщение указывает на то, что либо вы забыли установить модули, либо вы забыли выполнить depmod -a, либо вы вообще не скомпилировали необходимые модули Для решения первой проблемы запустите команду make modules_installв каталоге с исходными текстами ядра. Вторая проблема решается запуском команды depmod -a. Разрешение третьей проблемы уже выходит за рамки данного руководства, и в этом случае рекомендую посетить домашнюю страничку . (Взгляните еще раз в начало документа, где описывается процесс установки iptables. прим. перев.)
      Другие ошибки, которые вы можете получить при запуске iptables:
      iptables: No chain/target/match by that name
      Эта ошибка сообщает, что нет такой цепочки, действия или критерия. Это может зависеть от огромного числа факторов, наиболее вероятно, что вы пытаетесь использовать несуществующую (или еще не определенную) цепочку, несуществующее действие или критерий. Либо потому, что не загружен необходимый модуль.

      Это свойство iptablesнедостаточно хорошо задокументировано, а поэтому многие могут уделить ему недостаточное внимание (включая и меня). Если вы используете правила, определяющие статус пакета NEW, но не проверяете состояние бита SYN, то пакеты со сброшенным битом SYNсмогут «просочиться» через вашу защиту. Хотя, в случае, когда мы используем несколько брандмауэров, такой пакет может оказаться частью ESTABLISHEDсоединения, установленного через другой брандмауэр. Пропуская подобные пакеты, мы делаем возможным совместную работу двух или более брандмауэров, при этом мы можем любой из них остановить не боясь разорвать установленные соединения, Поскольку функции по передаче данных тут же возьмет на себя другой брандмауэр. Однако это позволит устанавливать практически любое TCP соединение. Во избежание этого следует добавить следующие правила в цепочки INPUT, OUTPUTи FORWARD:
       $IPTABLES -A INPUT -p tcp ! –syn -m state –state NEW -j LOG \ –log-prefix «New not syn:» $IPTABLES -A INPUT -p tcp ! –syn -m state –state NEW -j DROP
 
       ОСТОРОЖНО: Вышеприведенные правила позаботятся об этой проблеме. Будьте чрезвычайно внимательны при построении правил принимающих решение на основе статуса пакета.
 
      Обратите внимание, что имеются некоторые неприятности с вышеприведенными правилами и плохой реализацией TCP/IP от Microsoft. Дело в том, что при некоторых условиях, пакеты, сгенерированные программами от Microsoft маркируются как NEWи согласно этим правилам будут сброшены. Это, однако, не приводит к разрушению соединений, насколько я знаю. Происходит это потому, что, когда соединение закрывается, и посылается завершающий пакет FIN/ACK, то netfilterзакрывает это соединение и удаляет его из таблицы conntrack. В этот момент, дефектный код Microsoft посылает другой пакет, которому присваивается статус NEW, но в этом пакете не установлен бит SYNи, следовательно соответствует вышеупомянутым правилам. Короче говоря – особо не переживайте по поводу этих правил. В случае чего – вы сможете просмотреть системный журнал, куда логируются отбрасываемые пакеты (см. правила выше) и разобраться с ними.
      Имеется еще одна известная проблема с этими правилами. Если кто-то в настоящее время связан с брандмауэром, например из LAN, и активирует PPP, то в этом случае соединение будет уничтожено. Это происходит в момент, когда загружаются или выгружаются conntrackи natмодули. Другой способ получить эту проблему состоит в том, чтобы выполнить сценарий rc.firewall.txtиз сеанса telnetс другого компьютера. Для этого вы соединяетесь по telnetс брандмауэром. Запускаете rc.firewall.txt, в процессе исполнения которого, запускаются модули трассировки подключений, грузятся правила «NEW not SYN». Когда клиент telnetили daemon пробуют послать что нибудь, то это подключение будет распознано трассировочным кодом как NEW, но пакеты не имеют установленного бита SYN, так как они, фактически, являются частью уже установленного соединения. Следовательно, пакет будет соответствовать правилам в результате чего будет зажурналирован и сброшен.

      Существует одна из разновидностей спуфинг-атак (от англ. spoofing – мистификация, подмена. прим. перев.), которая называется «Предсказание номера TCP-последовательности» (Sequence Number Prediction). Смысл атак такого рода заключается в использовании чужого IP-адреса для нападения на какой либо узел сети.
      Для рассмотрения типичной Sequence Number Prediction атаки обозначим через [A] – атакующий хост, [V] – атакуемый хост, [O] – третий хост, чей IP-адрес используется атакующим.
      1. Хост [A] отправляет SYN-пакет (запрос на соединение прим. перев.) хосту [V] с обратным IP-адресом хоста [O].
      2. Хост [V] отвечает хосту [O] пакетом SYN/ACK.
      3. Теперь, по логике вещей, хост [O] должен разорвать соединение пакетом RST, поскольку он не посылал запрос на соединение (пакет SYN) и попытка атаки провалится, однако, допустим, что хост [O] не ответил (оказался выключенным, перегружен работой или находится за брандмауэром, который не пропустил пакет SYN/ACK).
      4. Если хост [O] не отправил пакет RST, прервав таким образом начавшуюся атаку, то атакующий хост [A] получает возможность взаимодействия с хостом [V], выдавая себя за [O].
      Не передав RST-пакет мы, тем самым, способствуем выполнению атаки на хост [V], которая может быть инкриминирована нам самим. Общепринятой считается необходимость отправления пакета RST в подобных случаях (RST в ответ на незапрошенный SYN/ACK). Если в вашем брандмауэре используются правила, фильтрующие пакеты со статусом NEW и сброшенным битом SYN, то SYN/ACK-пакеты будут «сбрасываться» этими правилами. Поэтому, следующее правило необходимо вставить в цепочку bad_tcp_packetsпервым:
       iptables -A bad_tcp_packets -p tcp –tcp-flags SYN,ACK SYN,ACK \ -m state –state NEW -j REJECT –reject-with tcp-reset
      В большинстве случаев подобные правила обеспечивают достаточный уровень безопасности для хоста [O] и риск от их использования относительно невелик. Исключение составляют случаи использования серии брандмауэров. В этом случае некоторые соединения могут оказаться заблокированными, даже если они вполне законны. Эти правила, ко всему прочему, допускают некоторые виды сканирования портов, но не более того.

      Я добавил этот раздел чтобы предупредить вас о туповатых провайдерах (Internet Service Providers), которые назначают IP адреса, отведенные IANAдля локальных сетей. Например, Swedish Internet Service Provider и телефонная монополия Telia используют такие адреса для своих серверов DNS(диапазон 10.x.x.x). Проблема, с которой вы будете наиболее вероятно сталкиваться, состоит в том, что мы, в своих сценариях, блокируем подключения с любых IP в диапазоне 10.x.x.x, из-за возможности фальсификации пакетов. Если вы столкнетесь с такой ситуацией, то наверное вам придется снять часть правил. Или установить правила, пропускающие траффик с этих серверов, ранее цепочки INPUT, например так:
       /usr/local/sbin/iptables -t nat -I PREROUTING -i eth1 -s \ 10.0.0.1/32 -j ACCEPT
      Хотелось бы напомнить подобным провайдерам, что эти диапазоны адресов не предназначены для использования в Интернет. Для корпоративных сетей – пожалуйста, для ваших собственных домашних сетей – прекрасно! Но вы не должны вынуждать нас «открываться» по вашей прихоти.

      В действительности, эта задача достаточно проста, если вам известны принципы работы протокола DHCP. Прежде всего необходимо знать, что DHCPработает по протоколу UDP. Следовательно, протокол является первым критерием. Далее, необходимо уточнить интерфейс, например, если DHCPзапросы идут через $LAN_IFACE, то движение запросов DHCPследует разрешить только через этот интерфейс. И наконец, чтобы сделать правило более определенным, следует уточнить порты. DHCPиспользует порты 67 и 68. Таким образом, искомое правило может выглядеть следующим образом:
       $IPTABLES -I INPUT -i $LAN_IFACE -p udp –dport 67:68 –sport \ 67:68 -j ACCEPT
      Обратите внимание, это правило пропускает весь трафик по протоколу UDPчерез порты 67 и 68, однако это не должно вас особенно смущать, поскольку оно разрешает лишь движение запросов от узлов сети, пытающихся установить соединение с портами 67 и 68. Этого правила вполне достаточно, чтобы позволить выполнение DHCPзапросов и при этом не слишком широко «открыть ворота». Если вас очень беспокоит проблема безопасности, то вы вполне можете ужесточить это правило.

      mIRC использует специфичные настройки, которые позволяют соединяться через брандмауэр и обрабатывать DCC соединения должным образом. Если эти настройки используются совместно с iptables, точнее с модулями ip_conntrack_irc и ip_nat_irc, то эта связка просто не будет работать. Проблема заключается в том, что mIRC автоматически выполняет трансляцию сетевых адресов (NAT) внутри пакетов. В результате, когда пакет попадает в iptables, она просто не знает, что с ним делать. mIRC не ожидает, что брандмауэр будет настолько «умным», чтобы корректно обрабатывать IRC, и поэтому самостоятельно запрашивает свой IP у сервера и затем подставляет его, при передаче DCC запроса.
      Включение опции «I am behind a firewall» («Я за брандмауэром») и использование модулей ip_conntrack_irc и ip_nat_irc приводит к тому, что netfilter пишет в системный журнал сообщение «Forged DCC send packet».
      У этой проблемы есть простое решение – отключите эту опцию в mIRC и позвольте iptables выполнять всю работу.

      The purpose of this License is to make a manual, textbook, or other written document «free» in the sense of freedom: to assure everyone the effective freedom to copy and redistribute it, with or without modifying it, either commercially or noncommercially. Secondarily, this License preserves for the author and publisher a way to get credit for their work, while not being considered responsible for modifications made by others.
      This License is a kind of «copyleft», which means that derivative works of the document must themselves be free in the same sense. It complements the GNU General Public License, which is a copyleft license designed for free software.
      We have designed this License in order to use it for manuals for free software, because free software needs free documentation: a free program should come with manuals providing the same freedoms that the software does. But this License is not limited to software manuals; it can be used for any textual work, regardless of subject matter or whether it is published as a printed book. We recommend this License principally for works whose purpose is instruction or reference.

      This License applies to any manual or other work that contains a notice placed by the copyright holder saying it can be distributed under the terms of this License. The «Document», below, refers to any such manual or work. Any member of the public is a licensee, and is addressed as «you».
      A «Modified Version» of the Document means any work containing the Document or a portion of it, either copied verbatim, or with modifications and/or translated into another language.
      A «Secondary Section» is a named appendix or a front-matter section of the Document that deals exclusively with the relationship of the publishers or authors of the Document to the Document's overall subject (or to related matters) and contains nothing that could fall directly within that overall subject. (For example, if the Document is in part a textbook of mathematics, a Secondary Section may not explain any mathematics.) The relationship could be a matter of historical connection with the subject or with related matters, or of legal, commercial, philosophical, ethical or political position regarding them.
      The «Invariant Sections» are certain Secondary Sections whose titles are designated, as being those of Invariant Sections, in the notice that says that the Document is released under this License.
      The «Cover Texts» are certain short passages of text that are listed, as Front-Cover Texts or Back-Cover Texts, in the notice that says that the Document is released under this License.
      A «Transparent» copy of the Document means a machine-readable copy, represented in a format whose specification is available to the general public, whose contents can be viewed and edited directly and straightforwardly with generic text editors or (for images composed of pixels) generic paint programs or (for drawings) some widely available drawing editor, and that is suitable for input to text formatters or for automatic translation to a variety of formats suitable for input to text formatters. A copy made in an otherwise Transparent file format whose markup has been designed to thwart or discourage subsequent modification by readers is not Transparent. A copy that is not «Transparent» is called «Opaque».
      Examples of suitable formats for Transparent copies include plain ASCII without markup, Texinfo input format, LaTeX input format, SGML or XML using a publicly available DTD, and standard-conforming simple HTML designed for human modification. Opaque formats include PostScript, PDF, proprietary formats that can be read and edited only by proprietary word processors, SGML or XML for which the DTD and/or processing tools are not generally available, and the machine-generated HTML produced by some word processors for output purposes only.
      The «Title Page» means, for a printed book, the title page itself, plus such following pages as are needed to hold, legibly, the material this License requires to appear in the title page. For works in formats which do not have any title page as such, «Title Page» means the text near the most prominent appearance of the work's title, preceding the beginning of the body of the text.

      You may copy and distribute the Document in any medium, either commercially or noncommercially, provided that this License, the copyright notices, and the license notice saying this License applies to the Document are reproduced in all copies, and that you add no other conditions whatsoever to those of this License. You may not use technical measures to obstruct or control the reading or further copying of the copies you make or distribute. However, you may accept compensation in exchange for copies. If you distribute a large enough number of copies you must also follow the conditions in section 3.
      You may also lend copies, under the same conditions stated above, and you may publicly display copies.

      If you publish printed copies of the Document numbering more than 100, and the Document's license notice requires Cover Texts, you must enclose the copies in covers that carry, clearly and legibly, all these Cover Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on the back cover. Both covers must also clearly and legibly identify you as the publisher of these copies. The front cover must present the full title with all words of the title equally prominent and visible. You may add other material on the covers in addition. Copying with changes limited to the covers, as long as they preserve the title of the Document and satisfy these conditions, can be treated as verbatim copying in other respects.
      If the required texts for either cover are too voluminous to fit legibly, you should put the first ones listed (as many as fit reasonably) on the actual cover, and continue the rest onto adjacent pages.
      If you publish or distribute Opaque copies of the Document numbering more than 100, you must either include a machine-readable Transparent copy along with each Opaque copy, or state in or with each Opaque copy a publicly-accessible computer-network location containing a complete Transparent copy of the Document, free of added material, which the general network-using public has access to download anonymously at no charge using public-standard network protocols. If you use the latter option, you must take reasonably prudent steps, when you begin distribution of Opaque copies in quantity, to ensure that this Transparent copy will remain thus accessible at the stated location until at least one year after the last time you distribute an Opaque copy (directly or through your agents or retailers) of that edition to the public.
      It is requested, but not required, that you contact the authors of the Document well before redistributing any large number of copies, to give them a chance to provide you with an updated version of the Document.

      You may copy and distribute a Modified Version of the Document under the conditions of sections 2 and 3 above, provided that you release the Modified Version under precisely this License, with the Modified Version filling the role of the Document, thus licensing distribution and modification of the Modified Version to whoever possesses a copy of it. In addition, you must do these things in the Modified Version:
      Use in the Title Page (and on the covers, if any) a title distinct from that of the Document, and from those of previous versions (which should, if there were any, be listed in the History section of the Document). You may use the same title as a previous version if the original publisher of that version gives permission.
      List on the Title Page, as authors, one or more persons or entities responsible for authorship of the modifications in the Modified Version, together with at least five of the principal authors of the Document (all of its principal authors, if it has less than five).
      State on the Title page the name of the publisher of the Modified Version, as the publisher.
      Preserve all the copyright notices of the Document.
      Add an appropriate copyright notice for your modifications adjacent to the other copyright notices.
      Include, immediately after the copyright notices, a license notice giving the public permission to use the Modified Version under the terms of this License, in the form shown in the Addendum below.
      Preserve in that license notice the full lists of Invariant Sections and required Cover Texts given in the Document's license notice.
      Include an unaltered copy of this License.
      Preserve the section entitled «History», and its title, and add to it an item stating at least the title, year, new authors, and publisher of the Modified Version as given on the Title Page. If there is no section entitled «History» in the Document, create one stating the title, year, authors, and publisher of the Document as given on its Title Page, then add an item describing the Modified Version as stated in the previous sentence.
      Preserve the network location, if any, given in the Document for public access to a Transparent copy of the Document, and likewise the network locations given in the Document for previous versions it was based on. These may be placed in the «History» section. You may omit a network location for a work that was published at least four years before the Document itself, or if the original publisher of the version it refers to gives permission.
      In any section entitled «Acknowledgements» or «Dedications», preserve the section's title, and preserve in the section all the substance and tone of each of the contributor acknowledgements and/or dedications given therein.
      Preserve all the Invariant Sections of the Document, unaltered in their text and in their titles. Section numbers or the equivalent are not considered part of the section titles.
      Delete any section entitled «Endorsements». Such a section may not be included in the Modified Version.
      Do not retitle any existing section as «Endorsements» or to conflict in title with any Invariant Section.
      If the Modified Version includes new front-matter sections or appendices that qualify as Secondary Sections and contain no material copied from the Document, you may at your option designate some or all of these sections as invariant. To do this, add their titles to the list of Invariant Sections in the Modified Version's license notice. These titles must be distinct from any other section titles.
      You may add a section entitled «Endorsements», provided it contains nothing but endorsements of your Modified Version by various parties–for example, statements of peer review or that the text has been approved by an organization as the authoritative definition of a standard.
      You may add a passage of up to five words as a Front-Cover Text, and a passage of up to 25 words as a Back-Cover Text, to the end of the list of Cover Texts in the Modified Version. Only one passage of Front-Cover Text and one of Back-Cover Text may be added by (or through arrangements made by) any one entity. If the Document already includes a cover text for the same cover, previously added by you or by arrangement made by the same entity you are acting on behalf of, you may not add another; but you may replace the old one, on explicit permission from the previous publisher that added the old one.
      The author(s) and publisher(s) of the Document do not by this License give permission to use their names for publicity for or to assert or imply endorsement of any Modified Version.

      You may combine the Document with other documents released under this License, under the terms defined in section 4 above for modified versions, provided that you include in the combination all of the Invariant Sections of all of the original documents, unmodified, and list them all as Invariant Sections of your combined work in its license notice.
      The combined work need only contain one copy of this License, and multiple identical Invariant Sections may be replaced with a single copy. If there are multiple Invariant Sections with the same name but different contents, make the title of each such section unique by adding at the end of it, in parentheses, the name of the original author or publisher of that section if known, or else a unique number. Make the same adjustment to the section titles in the list of Invariant Sections in the license notice of the combined work.
      In the combination, you must combine any sections entitled «History» in the various original documents, forming one section entitled «History»; likewise combine any sections entitled «Acknowledgements», and any sections entitled «Dedications». You must delete all sections entitled «Endorsements.»

      You may make a collection consisting of the Document and other documents released under this License, and replace the individual copies of this License in the various documents with a single copy that is included in the collection, provided that you follow the rules of this License for verbatim copying of each of the documents in all other respects.
      You may extract a single document from such a collection, and distribute it individually under this License, provided you insert a copy of this License into the extracted document, and follow this License in all other respects regarding verbatim copying of that document.

      A compilation of the Document or its derivatives with other separate and independent documents or works, in or on a volume of a storage or distribution medium, does not as a whole count as a Modified Version of the Document, provided no compilation copyright is claimed for the compilation. Such a compilation is called an «aggregate», and this License does not apply to the other self-contained works thus compiled with the Document, on account of their being thus compiled, if they are not themselves derivative works of the Document.
      If the Cover Text requirement of section 3 is applicable to these copies of the Document, then if the Document is less than one quarter of the entire aggregate, the Document's Cover Texts may be placed on covers that surround only the Document within the aggregate. Otherwise they must appear on covers around the whole aggregate.

      Translation is considered a kind of modification, so you may distribute translations of the Document under the terms of section 4. Replacing Invariant Sections with translations requires special permission from their copyright holders, but you may include translations of some or all Invariant Sections in addition to the original versions of these Invariant Sections. You may include a translation of this License provided that you also include the original English version of this License. In case of a disagreement between the translation and the original English version of this License, the original English version will prevail.

      You may not copy, modify, sublicense, or distribute the Document except as expressly provided for under this License. Any other attempt to copy, modify, sublicense or distribute the Document is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance.

      The Free Software Foundation may publish new, revised versions of the GNU Free Documentation License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. See .
      Each version of the License is given a distinguishing version number. If the Document specifies that a particular numbered version of this License «or any later version» applies to it, you have the option of following the terms and conditions either of that specified version or of any later version that has been published (not as a draft) by the Free Software Foundation. If the Document does not specify a version number of this License, you may choose any version ever published (not as a draft) by the Free Software Foundation.

      To use this License in a document you have written, include a copy of the License in the document and put the following copyright and license notices just after the title page:
      Copyright (c) YEAR YOUR NAME. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation; with the Invariant Sections being LIST THEIR TITLES, with the Front-Cover Texts being LIST, and with the Back-Cover Texts being LIST. A copy of the license is included in the section entitled «GNU Free Documentation License».
      If you have no Invariant Sections, write «with no Invariant Sections» instead of saying which ones are invariant. If you have no Front-Cover Texts, write «no Front-Cover Texts» instead of «Front-Cover Texts being LIST»; likewise for Back-Cover Texts.
      If your document contains nontrivial examples of program code, we recommend releasing these examples in parallel under your choice of free software license, such as the GNU General Public License, to permit their use in free software.

      The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public License is intended to guarantee your freedom to share and change free software–to make sure the software is free for all its users. This General Public License applies to most of the Free Software Foundation's software and to any other program whose authors commit to using it. (Some other Free Software Foundation software is covered by the GNU Library General Public License instead.) You can apply it to your programs, too.
      When we speak of free software, we are referring to freedom, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish), that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs; and that you know you can do these things.
      To protect your rights, we need to make restrictions that forbid anyone to deny you these rights or to ask you to surrender the rights. These restrictions translate to certain responsibilities for you if you distribute copies of the software, or if you modify it.
      For example, if you distribute copies of such a program, whether gratis or for a fee, you must give the recipients all the rights that you have. You must make sure that they, too, receive or can get the source code. And you must show them these terms so they know their rights.
      We protect your rights with two steps: (1) copyright the software, and (2) offer you this license which gives you legal permission to copy, distribute and/or modify the software.
      Also, for each author's protection and ours, we want to make certain that everyone understands that there is no warranty for this free software. If the software is modified by someone else and passed on, we want its recipients to know that what they have is not the original, so that any problems introduced by others will not reflect on the original authors' reputations.
      Finally, any free program is threatened constantly by software patents. We wish to avoid the danger that redistributors of a free program will individually obtain patent licenses, in effect making the program proprietary. To prevent this, we have made it clear that any patent must be licensed for everyone's free use or not licensed at all.
      The precise terms and conditions for copying, distribution and modification follow.

      This License applies to any program or other work which contains a notice placed by the copyright holder saying it may be distributed under the terms of this General Public License. The «Program», below, refers to any such program or work, and a «work based on the Program» means either the Program or any derivative work under copyright law: that is to say, a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language. (Hereinafter, translation is included without limitation in the term «modification».) Each licensee is addressed as «you».
      Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running the Program is not restricted, and the output from the Program is covered only if its contents constitute a work based on the Program (independent of having been made by running the Program). Whether that is true depends on what the Program does.
      You may copy and distribute verbatim copies of the Program's source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and give any other recipients of the Program a copy of this License along with the Program.
      You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee.
      You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions:
      You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change.
      You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.
      If the modified program normally reads commands interactively when run, you must cause it, when started running for such interactive use in the most ordinary way, to print or display an announcement including an appropriate copyright notice and a notice that there is no warranty (or else, saying that you provide a warranty) and that users may redistribute the program under these conditions, and telling the user how to view a copy of this License. (Exception: if the Program itself is interactive but does not normally print such an announcement, your work based on the Program is not required to print an announcement.)
      These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it.
      Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Program.
      In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License.
      You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following:
      Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,
      Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,
      Accompany it with the information you received as to the offer to distribute corresponding source code. (This alternative is allowed only for noncommercial distribution and only if you received the program in object code or executable form with such an offer, in accord with Subsection b above.)
      The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.
      If distribution of executable or object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place counts as distribution of the source code, even though third parties are not compelled to copy the source along with the object code.
      You may not copy, modify, sublicense, or distribute the Program except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense or distribute the Program is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance.
      You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Program or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying or distributing the Program (or any work based on the Program), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the Program or works based on it.
      Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to this License.
      If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Program at all. For example, if a patent license would not permit royalty-free redistribution of the Program by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Program.
      If any portion of this section is held invalid or unenforceable under any particular circumstance, the balance of the section is intended to apply and the section as a whole is intended to apply in other circumstances.
      It is not the purpose of this section to induce you to infringe any patents or other property right claims or to contest validity of any such claims; this section has the sole purpose of protecting the integrity of the free software distribution system, which is implemented by public license practices. Many people have made generous contributions to the wide range of software distributed through that system in reliance on consistent application of that system; it is up to the author/donor to decide if he or she is willing to distribute software through any other system and a licensee cannot impose that choice.
      This section is intended to make thoroughly clear what is believed to be a consequence of the rest of this License.
      If the distribution and/or use of the Program is restricted in certain countries either by patents or by copyrighted interfaces, the original copyright holder who places the Program under this License may add an explicit geographical distribution limitation excluding those countries, so that distribution is permitted only in or among countries not thus excluded. In such case, this License incorporates the limitation as if written in the body of this License.
      The Free Software Foundation may publish revised and/or new versions of the General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns.
      Each version is given a distinguishing version number. If the Program specifies a version number of this License which applies to it and «any later version», you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Program does not specify a version number of this License, you may choose any version ever published by the Free Software Foundation.
      If you wish to incorporate parts of the Program into other free programs whose distribution conditions are different, write to the author to ask for permission. For software which is copyrighted by the Free Software Foundation, write to the Free Software Foundation; we sometimes make exceptions for this. Our decision will be guided by the two goals of preserving the free status of all derivatives of our free software and of promoting the sharing and reuse of software generally.
      NO WARRANTY
      BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM «AS IS» WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
      IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
      END OF TERMS AND CONDITIONS

      If you develop a new program, and you want it to be of the greatest possible use to the public, the best way to achieve this is to make it free software which everyone can redistribute and change under these terms.
      To do so, attach the following notices to the program. It is safest to attach them to the start of each source file to most effectively convey the exclusion of warranty; and each file should have at least the «copyright» line and a pointer to where the full notice is found.
      <one line to give the program's name and a brief idea of what it does.>
      Copyright (C) <year> <name of author>
 
      This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.
      This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
      You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
      Also add information on how to contact you by electronic and paper mail.
      If the program is interactive, make it output a short notice like this when it starts in an interactive mode:
      Gnomovision version 69, Copyright (C) year name of author Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'. This is free software, and you are welcome to redistribute it under certain conditions; type `show c' for details.
      The hypothetical commands `show w' and `show c' should show the appropriate parts of the General Public License. Of course, the commands you use may be called something other than `show w' and `show c'; they could even be mouse-clicks or menu items–whatever suits your program.
      You should also get your employer (if you work as a programmer) or your school, if any, to sign a «copyright disclaimer» for the program, if necessary. Here is a sample; alter the names:
      Yoyodyne, Inc., hereby disclaims all copyright interest in the program
      `Gnomovision' (which makes passes at compilers) written by James Hacker.
 
      <signature of Ty Coon>, 1 April 1989
      Ty Coon, President of Vice
 
      This General Public License does not permit incorporating your program into proprietary programs. If your program is a subroutine library, you may consider it more useful to permit linking proprietary applications with the library. If this is what you want to do, use the GNU Library General Public License instead of this License.

      #!/bin/sh
      #
      # rc.firewall – Initial SIMPLE IP Firewall script for Linux 2.4.x and iptables
      #
      # Copyright (C) 2001 Oskar Andreasson <bluefluxATkoffeinDOTnet>
      #
      # This program is free software; you can redistribute it and/or modify
      # it under the terms of the GNU General Public License as published by
      # the Free Software Foundation; version 2 of the License.
      #
      # This program is distributed in the hope that it will be useful,
      # but WITHOUT ANY WARRANTY; without even the implied warranty of
      # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
      # GNU General Public License for more details.
      #
      # You should have received a copy of the GNU General Public License
      # along with this program or from the site that you downloaded it
      # from; if not, write to the Free Software Foundation, Inc., 59 Temple
      # Place, Suite 330, Boston, MA 02111-1307 USA
      #
 
      ###########################################################################
      #
      # 1. Configuration options.
      #
 
      #
      # 1.1 Internet Configuration.
      #
 
      INET_IP="194.236.50.155"
      INET_IFACE="eth0"
      INET_BROADCAST="194.236.50.255"
 
      #
      # 1.1.1 DHCP
      #
 
      #
      # 1.1.2 PPPoE
      #
 
      #
      # 1.2 Local Area Network configuration.
      #
      # your LAN's IP range and localhost IP. /24 means to only use the first 24
      # bits of the 32 bit IP address. the same as netmask 255.255.255.0
      #
 
      LAN_IP="192.168.0.2"
      LAN_IP_RANGE="192.168.0.0/16"
      LAN_IFACE="eth1"
 
      #
      # 1.3 DMZ Configuration.
      #
 
      #
      # 1.4 Localhost Configuration.
      #
 
      LO_IFACE="lo"
      LO_IP="127.0.0.1"
 
      #
      # 1.5 IPTables Configuration.
      #
 
      IPTABLES="/usr/sbin/iptables"
 
      #
      # 1.6 Other Configuration.
      #
 
      ###########################################################################
      #
      # 2. Module loading.
      #
 
      #
      # Needed to initially load modules
      #
 
      /sbin/depmod -a
 
      #
      # 2.1 Required modules
      #
 
      /sbin/modprobe ip_tables
      /sbin/modprobe ip_conntrack
      /sbin/modprobe iptable_filter
      /sbin/modprobe iptable_mangle
      /sbin/modprobe iptable_nat
      /sbin/modprobe ipt_LOG
      /sbin/modprobe ipt_limit
      /sbin/modprobe ipt_state
 
      #
      # 2.2 Non-Required modules
      #
 
      #/sbin/modprobe ipt_owner
      #/sbin/modprobe ipt_REJECT
      #/sbin/modprobe ipt_MASQUERADE
      #/sbin/modprobe ip_conntrack_ftp
      #/sbin/modprobe ip_conntrack_irc
      #/sbin/modprobe ip_nat_ftp
      #/sbin/modprobe ip_nat_irc
 
      ###########################################################################
      #
      # 3. /proc set up.
      #
 
      #
      # 3.1 Required proc configuration
      #
 
      echo "1" > /proc/sys/net/ipv4/ip_forward
 
      #
      # 3.2 Non-Required proc configuration
      #
 
      #echo "1" > /proc/sys/net/ipv4/conf/all/rp_filter
      #echo "1" > /proc/sys/net/ipv4/conf/all/proxy_arp
      #echo "1" > /proc/sys/net/ipv4/ip_dynaddr
 
      ###########################################################################
      #
      # 4. rules set up.
      #
 
      ######
      # 4.1 Filter table
      #
 
      #
      # 4.1.1 Set policies
      #
 
      $IPTABLES -P INPUT DROP
      $IPTABLES -P OUTPUT DROP
      $IPTABLES -P FORWARD DROP
 
      #
      # 4.1.2 Create userspecified chains
      #
 
      #
      # Create chain for bad tcp packets
      #
 
      $IPTABLES -N bad_tcp_packets
 
      #
      # Create separate chains for ICMP, TCP and UDP to traverse
      #
 
      $IPTABLES -N allowed
      $IPTABLES -N tcp_packets
      $IPTABLES -N udp_packets
      $IPTABLES -N icmp_packets
 
      #
      # 4.1.3 Create content in userspecified chains
      #
 
      #
      # bad_tcp_packets chain
      #
 
      $IPTABLES -A bad_tcp_packets -p tcp –tcp-flags SYN,ACK SYN,ACK \
      –m state –state NEW -j REJECT –reject-with tcp-reset
      $IPTABLES -A bad_tcp_packets -p tcp ! –syn -m state –state NEW -j LOG \
      –log-prefix «New not syn:»
      $IPTABLES -A bad_tcp_packets -p tcp ! –syn -m state –state NEW -j DROP
 
      #
      # allowed chain
      #
 
      $IPTABLES -A allowed -p TCP –syn -j ACCEPT
      $IPTABLES -A allowed -p TCP -m state –state ESTABLISHED,RELATED -j ACCEPT
      $IPTABLES -A allowed -p TCP -j DROP
 
      #
      # TCP rules
      #
 
      $IPTABLES -A tcp_packets -p TCP -s 0/0 –dport 21 -j allowed
      $IPTABLES -A tcp_packets -p TCP -s 0/0 –dport 22 -j allowed
      $IPTABLES -A tcp_packets -p TCP -s 0/0 –dport 80 -j allowed
      $IPTABLES -A tcp_packets -p TCP -s 0/0 –dport 113 -j allowed
 
      #
      # UDP ports
      #
 
      #$IPTABLES -A udp_packets -p UDP -s 0/0 –destination-port 53 -j ACCEPT
      #$IPTABLES -A udp_packets -p UDP -s 0/0 –destination-port 123 -j ACCEPT
      $IPTABLES -A udp_packets -p UDP -s 0/0 –destination-port 2074 -j ACCEPT
      $IPTABLES -A udp_packets -p UDP -s 0/0 –destination-port 4000 -j ACCEPT
 
      #
      # In Microsoft Networks you will be swamped by broadcasts. These lines
      # will prevent them from showing up in the logs.
      #
 
      #$IPTABLES -A udp_packets -p UDP -i $INET_IFACE -d $INET_BROADCAST \
      #–destination-port 135:139 -j DROP
 
      #
      # If we get DHCP requests from the Outside of our network, our logs will
      # be swamped as well. This rule will block them from getting logged.
      #
 
      #$IPTABLES -A udp_packets -p UDP -i $INET_IFACE -d 255.255.255.255 \
      #–destination-port 67:68 -j DROP
 
      #
      # ICMP rules
      #
 
      $IPTABLES -A icmp_packets -p ICMP -s 0/0 –icmp-type 8 -j ACCEPT
      $IPTABLES -A icmp_packets -p ICMP -s 0/0 –icmp-type 11 -j ACCEPT
 
      #
      # 4.1.4 INPUT chain
      #
 
      #
      # Bad TCP packets we don't want.
      #
 
      $IPTABLES -A INPUT -p tcp -j bad_tcp_packets
 
      #
      # Rules for special networks not part of the Internet
      #
 
      $IPTABLES -A INPUT -p ALL -i $LAN_IFACE -s $LAN_IP_RANGE -j ACCEPT
      $IPTABLES -A INPUT -p ALL -i $LO_IFACE -s $LO_IP -j ACCEPT
      $IPTABLES -A INPUT -p ALL -i $LO_IFACE -s $LAN_IP -j ACCEPT
      $IPTABLES -A INPUT -p ALL -i $LO_IFACE -s $INET_IP -j ACCEPT
 
      #
      # Special rule for DHCP requests from LAN, which are not caught properly
      # otherwise.
      #
 
      $IPTABLES -A INPUT -p UDP -i $LAN_IFACE –dport 67 –sport 68 -j ACCEPT
 
      #
      # Rules for incoming packets from the internet.
      #
 
      $IPTABLES -A INPUT -p ALL -d $INET_IP -m state –state ESTABLISHED,RELATED \
      –j ACCEPT
      $IPTABLES -A INPUT -p TCP -i $INET_IFACE -j tcp_packets
      $IPTABLES -A INPUT -p UDP -i $INET_IFACE -j udp_packets
      $IPTABLES -A INPUT -p ICMP -i $INET_IFACE -j icmp_packets
 
      #
      # If you have a Microsoft Network on the outside of your firewall, you may
      # also get flooded by Multicasts. We drop them so we do not get flooded by
      # logs
      #
 
      #$IPTABLES -A INPUT -i $INET_IFACE -d 224.0.0.0/8 -j DROP
 
      #
      # Log weird packets that don't match the above.
      #
 
      $IPTABLES -A INPUT -m limit –limit 3/minute –limit-burst 3 -j LOG \
      –log-level DEBUG –log-prefix "IPT INPUT packet died: "
 
      #
      # 4.1.5 FORWARD chain
      #
 
      #
      # Bad TCP packets we don't want
      #
 
      $IPTABLES -A FORWARD -p tcp -j bad_tcp_packets
 
      #
      # Accept the packets we actually want to forward
      #
 
      $IPTABLES -A FORWARD -i $LAN_IFACE -j ACCEPT
      $IPTABLES -A FORWARD -m state –state ESTABLISHED,RELATED -j ACCEPT
 
      #
      # Log weird packets that don't match the above.
      #
 
      $IPTABLES -A FORWARD -m limit –limit 3/minute –limit-burst 3 -j LOG \
      –log-level DEBUG –log-prefix "IPT FORWARD packet died: "
 
      #
      # 4.1.6 OUTPUT chain
      #
 
      #
      # Bad TCP packets we don't want.
      #
 
      $IPTABLES -A OUTPUT -p tcp -j bad_tcp_packets
 
      #
      # Special OUTPUT rules to decide which IP's to allow.
      #
 
      $IPTABLES -A OUTPUT -p ALL -s $LO_IP -j ACCEPT
      $IPTABLES -A OUTPUT -p ALL -s $LAN_IP -j ACCEPT
      $IPTABLES -A OUTPUT -p ALL -s $INET_IP -j ACCEPT
 
      #
      # Log weird packets that don't match the above.
      #
 
      $IPTABLES -A OUTPUT -m limit –limit 3/minute –limit-burst 3 -j LOG \
      –log-level DEBUG –log-prefix "IPT OUTPUT packet died: "
 
      ######
      # 4.2 nat table
      #
 
      #
      # 4.2.1 Set policies
      #
 
      #
      # 4.2.2 Create user specified chains
      #
 
      #
      # 4.2.3 Create content in user specified chains
      #
 
      #
      # 4.2.4 PREROUTING chain
      #
 
      #
      # 4.2.5 POSTROUTING chain
      #
 
      #
      # Enable simple IP Forwarding and Network Address Translation
      #
 
      $IPTABLES -t nat -A POSTROUTING -o $INET_IFACE -j SNAT –to-source $INET_IP
 
      #
      # 4.2.6 OUTPUT chain
      #
 
      ######
      # 4.3 mangle table
      #
 
      #
      # 4.3.1 Set policies
      #
 
      #
      # 4.3.2 Create user specified chains
      #
 
      #
      # 4.3.3 Create content in user specified chains
      #
 
      #
      # 4.3.4 PREROUTING chain
      #
 
      #
      # 4.3.5 INPUT chain
      #
 
      #
      # 4.3.6 FORWARD chain
      #
 
      #
      # 4.3.7 OUTPUT chain
      #
 
      #
      # 4.3.8 POSTROUTING chain
      #
 

      #!/bin/sh
      #
      # rc.DMZ.firewall – DMZ IP Firewall script for Linux 2.4.x and iptables
      #
      # Copyright (C) 2001 Oskar Andreasson <bluefluxATkoffeinDOTnet>
      #
      # This program is free software; you can redistribute it and/or modify
      # it under the terms of the GNU General Public License as published by
      # the Free Software Foundation; version 2 of the License.
      #
      # This program is distributed in the hope that it will be useful,
      # but WITHOUT ANY WARRANTY; without even the implied warranty of
      # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
      # GNU General Public License for more details.
      #
      # You should have received a copy of the GNU General Public License
      # along with this program or from the site that you downloaded it
      # from; if not, write to the Free Software Foundation, Inc., 59 Temple
      # Place, Suite 330, Boston, MA 02111-1307 USA
      #
 
      ###########################################################################
      #
      # 1. Configuration options.
      #
 
      #
      # 1.1 Internet Configuration.
      #
 
      INET_IP="194.236.50.152"
      HTTP_IP="194.236.50.153"
      DNS_IP="194.236.50.154"
      INET_IFACE="eth0"
 
      #
      # 1.1.1 DHCP
      #
 
      #
      # 1.1.2 PPPoE
      #
 
      #
      # 1.2 Local Area Network configuration.
      #
      # your LAN's IP range and localhost IP. /24 means to only use the first 24
      # bits of the 32 bit IP address. the same as netmask 255.255.255.0
      #
 
      LAN_IP="192.168.0.1"
      LAN_IFACE="eth1"
 
      #
      # 1.3 DMZ Configuration.
      #
 
      DMZ_HTTP_IP="192.168.1.2"
      DMZ_DNS_IP="192.168.1.3"
      DMZ_IP="192.168.1.1"
      DMZ_IFACE="eth2"
 
      #
      # 1.4 Localhost Configuration.
      #
 
      LO_IFACE="lo"
      LO_IP="127.0.0.1"
 
      #
      # 1.5 IPTables Configuration.
      #
 
      IPTABLES="/usr/sbin/iptables"
 
      #
      # 1.6 Other Configuration.
      #
 
      ###########################################################################
      #
      # 2. Module loading.
      #
 
      #
      # Needed to initially load modules
      #
      /sbin/depmod -a
 
 
 
      #
      # 2.1 Required modules
      #
 
      /sbin/modprobe ip_tables
      /sbin/modprobe ip_conntrack
      /sbin/modprobe iptable_filter
      /sbin/modprobe iptable_mangle
      /sbin/modprobe iptable_nat
      /sbin/modprobe ipt_LOG
      /sbin/modprobe ipt_limit
      /sbin/modprobe ipt_state
 
      #
      # 2.2 Non-Required modules
      #
 
      #/sbin/modprobe ipt_owner
      #/sbin/modprobe ipt_REJECT
      #/sbin/modprobe ipt_MASQUERADE
      #/sbin/modprobe ip_conntrack_ftp
      #/sbin/modprobe ip_conntrack_irc
      #/sbin/modprobe ip_nat_ftp
      #/sbin/modprobe ip_nat_irc
 
      ###########################################################################
      #
      # 3. /proc set up.
      #
 
      #
      # 3.1 Required proc configuration
      #
 
      echo "1" > /proc/sys/net/ipv4/ip_forward
 
      #
      # 3.2 Non-Required proc configuration
      #
 
      #echo "1" > /proc/sys/net/ipv4/conf/all/rp_filter
      #echo "1" > /proc/sys/net/ipv4/conf/all/proxy_arp
      #echo "1" > /proc/sys/net/ipv4/ip_dynaddr
 
      ###########################################################################
      #
      # 4. rules set up.
      #
 
      ######
      # 4.1 Filter table
      #
 
      #
      # 4.1.1 Set policies
      #
 
      $IPTABLES -P INPUT DROP
      $IPTABLES -P OUTPUT DROP
      $IPTABLES -P FORWARD DROP
 
      #
      # 4.1.2 Create userspecified chains
      #
 
      #
      # Create chain for bad tcp packets
      #
 
      $IPTABLES -N bad_tcp_packets
 
      #
      # Create separate chains for ICMP, TCP and UDP to traverse
      #
 
      $IPTABLES -N allowed
      $IPTABLES -N icmp_packets
 
      #
      # 4.1.3 Create content in userspecified chains
      #
 
      #
      # bad_tcp_packets chain
      #
 
      $IPTABLES -A bad_tcp_packets -p tcp –tcp-flags SYN,ACK SYN,ACK \
      –m state –state NEW -j REJECT –reject-with tcp-reset
      $IPTABLES -A bad_tcp_packets -p tcp ! –syn -m state –state NEW -j LOG \
      –log-prefix «New not syn:»
      $IPTABLES -A bad_tcp_packets -p tcp ! –syn -m state –state NEW -j DROP
 
      #
      # allowed chain
      #
 
      $IPTABLES -A allowed -p TCP –syn -j ACCEPT
      $IPTABLES -A allowed -p TCP -m state –state ESTABLISHED,RELATED -j ACCEPT
      $IPTABLES -A allowed -p TCP -j DROP
 
      #
      # ICMP rules
      #
 
      # Changed rules totally
      $IPTABLES -A icmp_packets -p ICMP -s 0/0 –icmp-type 8 -j ACCEPT
      $IPTABLES -A icmp_packets -p ICMP -s 0/0 –icmp-type 11 -j ACCEPT
 
      #
      # 4.1.4 INPUT chain
      #
 
      #
      # Bad TCP packets we don't want
      #
 
      $IPTABLES -A INPUT -p tcp -j bad_tcp_packets
 
      #
      # Packets from the Internet to this box
      #
 
      $IPTABLES -A INPUT -p ICMP -i $INET_IFACE -j icmp_packets
 
      #
      # Packets from LAN, DMZ or LOCALHOST
      #
 
      #
      # From DMZ Interface to DMZ firewall IP
      #
 
      $IPTABLES -A INPUT -p ALL -i $DMZ_IFACE -d $DMZ_IP -j ACCEPT
 
      #
      # From LAN Interface to LAN firewall IP
      #
 
      $IPTABLES -A INPUT -p ALL -i $LAN_IFACE -d $LAN_IP -j ACCEPT
 
      #
      # From Localhost interface to Localhost IP's
      #
 
      $IPTABLES -A INPUT -p ALL -i $LO_IFACE -s $LO_IP -j ACCEPT
      $IPTABLES -A INPUT -p ALL -i $LO_IFACE -s $LAN_IP -j ACCEPT
      $IPTABLES -A INPUT -p ALL -i $LO_IFACE -s $INET_IP -j ACCEPT
 
      #
      # Special rule for DHCP requests from LAN, which are not caught properly
      # otherwise.
      #
 
      $IPTABLES -A INPUT -p UDP -i $LAN_IFACE –dport 67 –sport 68 -j ACCEPT
 
      #
      # All established and related packets incoming from the internet to the
      # firewall
      #
 
      $IPTABLES -A INPUT -p ALL -d $INET_IP -m state –state ESTABLISHED,RELATED \
      –j ACCEPT
 
      #
      # In Microsoft Networks you will be swamped by broadcasts. These lines
      # will prevent them from showing up in the logs.
      #
 
      #$IPTABLES -A INPUT -p UDP -i $INET_IFACE -d $INET_BROADCAST \
      #–destination-port 135:139 -j DROP
 
      #
      # If we get DHCP requests from the Outside of our network, our logs will
      # be swamped as well. This rule will block them from getting logged.
      #
 
      #$IPTABLES -A INPUT -p UDP -i $INET_IFACE -d 255.255.255.255 \
      #–destination-port 67:68 -j DROP
 
      #
      # If you have a Microsoft Network on the outside of your firewall, you may
      # also get flooded by Multicasts. We drop them so we do not get flooded by
      # logs
      #
 
      #$IPTABLES -A INPUT -i $INET_IFACE -d 224.0.0.0/8 -j DROP
 
      #
      # Log weird packets that don't match the above.
      #
 
      $IPTABLES -A INPUT -m limit –limit 3/minute –limit-burst 3 -j LOG \
      –log-level DEBUG –log-prefix "IPT INPUT packet died: "
 
      #
      # 4.1.5 FORWARD chain
      #
 
      #
      # Bad TCP packets we don't want
      #
 
      $IPTABLES -A FORWARD -p tcp -j bad_tcp_packets
 
 
      #
      # DMZ section
      #
      # General rules
      #
 
      $IPTABLES -A FORWARD -i $DMZ_IFACE -o $INET_IFACE -j ACCEPT
      $IPTABLES -A FORWARD -i $INET_IFACE -o $DMZ_IFACE -m state \
      –state ESTABLISHED,RELATED -j ACCEPT
      $IPTABLES -A FORWARD -i $LAN_IFACE -o $DMZ_IFACE -j ACCEPT
      $IPTABLES -A FORWARD -i $DMZ_IFACE -o $LAN_IFACE -m state \
      –state ESTABLISHED,RELATED -j ACCEPT
 
      #
      # HTTP server
      #
 
      $IPTABLES -A FORWARD -p TCP -i $INET_IFACE -o $DMZ_IFACE -d $DMZ_HTTP_IP \
      –dport 80 -j allowed
      $IPTABLES -A FORWARD -p ICMP -i $INET_IFACE -o $DMZ_IFACE -d $DMZ_HTTP_IP \
      –j icmp_packets
 
      #
      # DNS server
      #
 
      $IPTABLES -A FORWARD -p TCP -i $INET_IFACE -o $DMZ_IFACE -d $DMZ_DNS_IP \
      –dport 53 -j allowed
      $IPTABLES -A FORWARD -p UDP -i $INET_IFACE -o $DMZ_IFACE -d $DMZ_DNS_IP \
      –dport 53 -j ACCEPT
      $IPTABLES -A FORWARD -p ICMP -i $INET_IFACE -o $DMZ_IFACE -d $DMZ_DNS_IP \
      –j icmp_packets
 
      #
      # LAN section
      #
 
      $IPTABLES -A FORWARD -i $LAN_IFACE -j ACCEPT
      $IPTABLES -A FORWARD -m state –state ESTABLISHED,RELATED -j ACCEPT
 
      #
      # Log weird packets that don't match the above.
      #
 
      $IPTABLES -A FORWARD -m limit –limit 3/minute –limit-burst 3 -j LOG \
      –log-level DEBUG –log-prefix "IPT FORWARD packet died: "
 
      #
      # 4.1.6 OUTPUT chain
      #
 
      #
      # Bad TCP packets we don't want.
      #
 
      $IPTABLES -A OUTPUT -p tcp -j bad_tcp_packets
 
      #
      # Special OUTPUT rules to decide which IP's to allow.
      #
 
      $IPTABLES -A OUTPUT -p ALL -s $LO_IP -j ACCEPT
      $IPTABLES -A OUTPUT -p ALL -s $LAN_IP -j ACCEPT
      $IPTABLES -A OUTPUT -p ALL -s $INET_IP -j ACCEPT
 
      #
      # Log weird packets that don't match the above.
      #
 
      $IPTABLES -A OUTPUT -m limit –limit 3/minute –limit-burst 3 -j LOG \
      –log-level DEBUG –log-prefix "IPT OUTPUT packet died: "
 
      ######
      # 4.2 nat table
      #
 
      #
      # 4.2.1 Set policies
      #
 
      #
      # 4.2.2 Create user specified chains
      #
 
      #
      # 4.2.3 Create content in user specified chains
      #
 
      #
      # 4.2.4 PREROUTING chain
      #
 
      $IPTABLES -t nat -A PREROUTING -p TCP -i $INET_IFACE -d $HTTP_IP –dport 80 \
      –j DNAT –to-destination $DMZ_HTTP_IP
      $IPTABLES -t nat -A PREROUTING -p TCP -i $INET_IFACE -d $DNS_IP –dport 53 \
      –j DNAT –to-destination $DMZ_DNS_IP
      $IPTABLES -t nat -A PREROUTING -p UDP -i $INET_IFACE -d $DNS_IP –dport 53 \
      –j DNAT –to-destination $DMZ_DNS_IP
 
      #
      # 4.2.5 POSTROUTING chain
      #
 
      #
      # Enable simple IP Forwarding and Network Address Translation
      #
 
      $IPTABLES -t nat -A POSTROUTING -o $INET_IFACE -j SNAT –to-source $INET_IP
 
      #
      # 4.2.6 OUTPUT chain
      #
 
      ######
      # 4.3 mangle table
      #
 
      #
      # 4.3.1 Set policies
      #
 
      #
      # 4.3.2 Create user specified chains
      #
 
      #
      # 4.3.3 Create content in user specified chains
      #
 
      #
      # 4.3.4 PREROUTING chain
      #
 
      #
      # 4.3.5 INPUT chain
      #
 
      #
      # 4.3.6 FORWARD chain
      #
 
      #
      # 4.3.7 OUTPUT chain
      #
 
      #
      # 4.3.8 POSTROUTING chain
      #

      #!/bin/sh
      #
      # rc.firewall – UTIN Firewall script for Linux 2.4.x and iptables
      #
      # Copyright (C) 2001 Oskar Andreasson <bluefluxATkoffeinDOTnet>
      #
      # This program is free software; you can redistribute it and/or modify
      # it under the terms of the GNU General Public License as published by
      # the Free Software Foundation; version 2 of the License.
      #
      # This program is distributed in the hope that it will be useful,
      # but WITHOUT ANY WARRANTY; without even the implied warranty of
      # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
      # GNU General Public License for more details.
      #
      # You should have received a copy of the GNU General Public License
      # along with this program or from the site that you downloaded it
      # from; if not, write to the Free Software Foundation, Inc., 59 Temple
      # Place, Suite 330, Boston, MA 02111-1307 USA
      #
 
      ###########################################################################
      #
      # 1. Configuration options.
      #
 
      #
      # 1.1 Internet Configuration.
      #
 
      INET_IP="194.236.50.155"
      INET_IFACE="eth0"
      INET_BROADCAST="194.236.50.255"
 
      #
      # 1.1.1 DHCP
      #
 
      #
      # 1.1.2 PPPoE
      #
 
      #
      # 1.2 Local Area Network configuration.
      #
      # your LAN's IP range and localhost IP. /24 means to only use the first 24
      # bits of the 32 bit IP address. the same as netmask 255.255.255.0
      #
 
      LAN_IP="192.168.0.2"
      LAN_IP_RANGE="192.168.0.0/16"
      LAN_IFACE="eth1"
 
      #
      # 1.3 DMZ Configuration.
      #
 
      #
      # 1.4 Localhost Configuration.
      #
 
      LO_IFACE="lo"
      LO_IP="127.0.0.1"
 
      #
      # 1.5 IPTables Configuration.
      #
 
      IPTABLES="/usr/sbin/iptables"
 
      #
      # 1.6 Other Configuration.
      #
 
      ###########################################################################
      #
      # 2. Module loading.
      #
 
      #
      # Needed to initially load modules
      #
 
      /sbin/depmod -a
 
      #
      # 2.1 Required modules
      #
 
      /sbin/modprobe ip_tables
      /sbin/modprobe ip_conntrack
      /sbin/modprobe iptable_filter
      /sbin/modprobe iptable_mangle
      /sbin/modprobe iptable_nat
      /sbin/modprobe ipt_LOG
      /sbin/modprobe ipt_limit
      /sbin/modprobe ipt_state
 
      #
      # 2.2 Non-Required modules
      #
 
      #/sbin/modprobe ipt_owner
      #/sbin/modprobe ipt_REJECT
      #/sbin/modprobe ipt_MASQUERADE
      #/sbin/modprobe ip_conntrack_ftp
      #/sbin/modprobe ip_conntrack_irc
      #/sbin/modprobe ip_nat_ftp
      #/sbin/modprobe ip_nat_irc
 
      ###########################################################################
      #
      # 3. /proc set up.
      #
 
      #
      # 3.1 Required proc configuration
      #
 
      echo "1" > /proc/sys/net/ipv4/ip_forward
 
      #
      # 3.2 Non-Required proc configuration
      #
 
      #echo "1" > /proc/sys/net/ipv4/conf/all/rp_filter
      #echo "1" > /proc/sys/net/ipv4/conf/all/proxy_arp
      #echo "1" > /proc/sys/net/ipv4/ip_dynaddr
 
      ###########################################################################
      #
      # 4. rules set up.
      #
 
      ######
      # 4.1 Filter table
      #
 
      #
      # 4.1.1 Set policies
      #
 
      $IPTABLES -P INPUT DROP
      $IPTABLES -P OUTPUT DROP
      $IPTABLES -P FORWARD DROP
 
      #
      # 4.1.2 Create userspecified chains
      #
 
      #
      # Create chain for bad tcp packets
      #
 
      $IPTABLES -N bad_tcp_packets
 
      #
      # Create separate chains for ICMP, TCP and UDP to traverse
      #
 
      $IPTABLES -N allowed
      $IPTABLES -N tcp_packets
      $IPTABLES -N udp_packets
      $IPTABLES -N icmp_packets
 
      #
      # 4.1.3 Create content in userspecified chains
      #
 
      #
      # bad_tcp_packets chain
      #
 
      $IPTABLES -A bad_tcp_packets -p tcp –tcp-flags SYN,ACK SYN,ACK \
      –m state –state NEW -j REJECT –reject-with tcp-reset
      $IPTABLES -A bad_tcp_packets -p tcp ! –syn -m state –state NEW -j LOG \
      –log-prefix «New not syn:»
      $IPTABLES -A bad_tcp_packets -p tcp ! –syn -m state –state NEW -j DROP
 
      #
      # allowed chain
      #
 
      $IPTABLES -A allowed -p TCP –syn -j ACCEPT
      $IPTABLES -A allowed -p TCP -m state –state ESTABLISHED,RELATED -j ACCEPT
      $IPTABLES -A allowed -p TCP -j DROP
 
      #
      # TCP rules
      #
 
      $IPTABLES -A tcp_packets -p TCP -s 0/0 –dport 21 -j allowed
      $IPTABLES -A tcp_packets -p TCP -s 0/0 –dport 22 -j allowed
      $IPTABLES -A tcp_packets -p TCP -s 0/0 –dport 80 -j allowed
      $IPTABLES -A tcp_packets -p TCP -s 0/0 –dport 113 -j allowed
 
      #
      # UDP ports
      #
 
      #$IPTABLES -A udp_packets -p UDP -s 0/0 –source-port 53 -j ACCEPT
      #$IPTABLES -A udp_packets -p UDP -s 0/0 –source-port 123 -j ACCEPT
      $IPTABLES -A udp_packets -p UDP -s 0/0 –source-port 2074 -j ACCEPT
      $IPTABLES -A udp_packets -p UDP -s 0/0 –source-port 4000 -j ACCEPT
 
      #
      # In Microsoft Networks you will be swamped by broadcasts. These lines
      # will prevent them from showing up in the logs.
      #
 
      #$IPTABLES -A udp_packets -p UDP -i $INET_IFACE -d $INET_BROADCAST \
      #–destination-port 135:139 -j DROP
 
      #
      # If we get DHCP requests from the Outside of our network, our logs will
      # be swamped as well. This rule will block them from getting logged.
      #
 
      #$IPTABLES -A udp_packets -p UDP -i $INET_IFACE -d 255.255.255.255 \
      #–destination-port 67:68 -j DROP
 
      #
      # ICMP rules
      #
 
      $IPTABLES -A icmp_packets -p ICMP -s 0/0 –icmp-type 8 -j ACCEPT
      $IPTABLES -A icmp_packets -p ICMP -s 0/0 –icmp-type 11 -j ACCEPT
 
      #
      # 4.1.4 INPUT chain
      #
 
      #
      # Bad TCP packets we don't want.
      #
 
      $IPTABLES -A INPUT -p tcp -j bad_tcp_packets
 
      #
      # Rules for special networks not part of the Internet
      #
 
      $IPTABLES -A INPUT -p ALL -i $LO_IFACE -s $LO_IP -j ACCEPT
      $IPTABLES -A INPUT -p ALL -i $LO_IFACE -s $LAN_IP -j ACCEPT
      $IPTABLES -A INPUT -p ALL -i $LO_IFACE -s $INET_IP -j ACCEPT
 
      #
      # Rules for incoming packets from anywhere.
      #
 
      $IPTABLES -A INPUT -p ALL -d $INET_IP -m state –state ESTABLISHED,RELATED \
      –j ACCEPT
      $IPTABLES -A INPUT -p TCP -j tcp_packets
      $IPTABLES -A INPUT -p UDP -j udp_packets
      $IPTABLES -A INPUT -p ICMP -j icmp_packets
 
      #
      # If you have a Microsoft Network on the outside of your firewall, you may
      # also get flooded by Multicasts. We drop them so we do not get flooded by
      # logs
      #
 
      #$IPTABLES -A INPUT -i $INET_IFACE -d 224.0.0.0/8 -j DROP
 
      #
      # Log weird packets that don't match the above.
      #
 
      $IPTABLES -A INPUT -m limit –limit 3/minute –limit-burst 3 -j LOG \
      –log-level DEBUG –log-prefix "IPT INPUT packet died: "
 
      #
      # 4.1.5 FORWARD chain
      #
 
      #
      # Bad TCP packets we don't want
      #
 
      $IPTABLES -A FORWARD -p tcp -j bad_tcp_packets
 
      #
      # Accept the packets we actually want to forward
      #
 
      $IPTABLES -A FORWARD -p tcp –dport 21 -i $LAN_IFACE -j ACCEPT
      $IPTABLES -A FORWARD -p tcp –dport 80 -i $LAN_IFACE -j ACCEPT
      $IPTABLES -A FORWARD -p tcp –dport 110 -i $LAN_IFACE -j ACCEPT
      $IPTABLES -A FORWARD -m state –state ESTABLISHED,RELATED -j ACCEPT
 
      #
      # Log weird packets that don't match the above.
      #
 
      $IPTABLES -A FORWARD -m limit –limit 3/minute –limit-burst 3 -j LOG \
      –log-level DEBUG –log-prefix "IPT FORWARD packet died: "
 
      #
      # 4.1.6 OUTPUT chain
      #
 
      #
      # Bad TCP packets we don't want.
      #
 
      $IPTABLES -A OUTPUT -p tcp -j bad_tcp_packets
 
      #
      # Special OUTPUT rules to decide which IP's to allow.
      #
 
      $IPTABLES -A OUTPUT -p ALL -s $LO_IP -j ACCEPT
      $IPTABLES -A OUTPUT -p ALL -s $LAN_IP -j ACCEPT
      $IPTABLES -A OUTPUT -p ALL -s $INET_IP -j ACCEPT
 
      #
      # Log weird packets that don't match the above.
      #
 
      $IPTABLES -A OUTPUT -m limit –limit 3/minute –limit-burst 3 -j LOG \
      –log-level DEBUG –log-prefix "IPT OUTPUT packet died: "
 
      ######
      # 4.2 nat table
      #
 
      #
      # 4.2.1 Set policies
      #
 
      #
      # 4.2.2 Create user specified chains
      #
 
      #
      # 4.2.3 Create content in user specified chains
      #
 
      #
      # 4.2.4 PREROUTING chain
      #
 
      #
      # 4.2.5 POSTROUTING chain
      #
 
      #
      # Enable simple IP Forwarding and Network Address Translation
      #
 
      $IPTABLES -t nat -A POSTROUTING -o $INET_IFACE -j SNAT –to-source $INET_IP
 
      #
      # 4.2.6 OUTPUT chain
      #
 
      ######
      # 4.3 mangle table
      #
 
      #
      # 4.3.1 Set policies
      #
 
      #
      # 4.3.2 Create user specified chains
      #
 
      #
      # 4.3.3 Create content in user specified chains
      #
 
      #
      # 4.3.4 PREROUTING chain
      #
 
      #
      # 4.3.5 INPUT chain
      #
 
      #
      # 4.3.6 FORWARD chain
      #
 
      #
      # 4.3.7 OUTPUT chain
      #
 
      #
      # 4.3.8 POSTROUTING chain
      #

      #!/bin/sh
      #
      # rc.firewall – DHCP IP Firewall script for Linux 2.4.x and iptables
      #
      # Copyright (C) 2001 Oskar Andreasson <bluefluxATkoffeinDOTnet>
      #
      # This program is free software; you can redistribute it and/or modify
      # it under the terms of the GNU General Public License as published by
      # the Free Software Foundation; version 2 of the License.
      #
      # This program is distributed in the hope that it will be useful,
      # but WITHOUT ANY WARRANTY; without even the implied warranty of
      # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
      # GNU General Public License for more details.
      #
      # You should have received a copy of the GNU General Public License
      # along with this program or from the site that you downloaded it
      # from; if not, write to the Free Software Foundation, Inc., 59 Temple
      # Place, Suite 330, Boston, MA 02111-1307 USA
      #
 
      ###########################################################################
      #
      # 1. Configuration options.
      #
 
      #
      # 1.1 Internet Configuration.
      #
 
      INET_IFACE="eth0"
 
      #
      # 1.1.1 DHCP
      #
 
      #
      # Information pertaining to DHCP over the Internet, if needed.
      #
      # Set DHCP variable to no if you don't get IP from DHCP. If you get DHCP
      # over the Internet set this variable to yes, and set up the proper IP
      # address for the DHCP server in the DHCP_SERVER variable.
      #
 
      DHCP="no"
      DHCP_SERVER="195.22.90.65"
 
      #
      # 1.1.2 PPPoE
      #
 
      # Configuration options pertaining to PPPoE.
      #
      # If you have problem with your PPPoE connection, such as large mails not
      # getting through while small mail get through properly etc, you may set
      # this option to «yes» which may fix the problem. This option will set a
      # rule in the PREROUTING chain of the mangle table which will clamp
      # (resize) all routed packets to PMTU (Path Maximum Transmit Unit).
      #
      # Note that it is better to set this up in the PPPoE package itself, since
      # the PPPoE configuration option will give less overhead.
      #
 
      PPPOE_PMTU="no"
 
      #
      # 1.2 Local Area Network configuration.
      #
      # your LAN's IP range and localhost IP. /24 means to only use the first 24
      # bits of the 32 bit IP address. the same as netmask 255.255.255.0
      #
 
      LAN_IP="192.168.0.2"
      LAN_IP_RANGE="192.168.0.0/16"
      LAN_IFACE="eth1"
 
      #
      # 1.3 DMZ Configuration.
      #
 
      #
      # 1.4 Localhost Configuration.
      #
 
      LO_IFACE="lo"
      LO_IP="127.0.0.1"
 
      #
      # 1.5 IPTables Configuration.
      #
 
      IPTABLES="/usr/sbin/iptables"
 
      #
      # 1.6 Other Configuration.
      #
 
      ###########################################################################
      #
      # 2. Module loading.
      #
 
      #
      # Needed to initially load modules
      #
 
      /sbin/depmod -a
 
      #
      # 2.1 Required modules
      #
 
      /sbin/modprobe ip_conntrack
      /sbin/modprobe ip_tables
      /sbin/modprobe iptable_filter
      /sbin/modprobe iptable_mangle
      /sbin/modprobe iptable_nat
      /sbin/modprobe ipt_LOG
      /sbin/modprobe ipt_limit
      /sbin/modprobe ipt_MASQUERADE
 
      #
      # 2.2 Non-Required modules
      #
 
      #/sbin/modprobe ipt_owner
      #/sbin/modprobe ipt_REJECT
      #/sbin/modprobe ip_conntrack_ftp
      #/sbin/modprobe ip_conntrack_irc
      #/sbin/modprobe ip_nat_ftp
      #/sbin/modprobe ip_nat_irc
 
      ###########################################################################
      #
      # 3. /proc set up.
      #
 
      #
      # 3.1 Required proc configuration
      #
 
      echo "1" > /proc/sys/net/ipv4/ip_forward
 
      #
      # 3.2 Non-Required proc configuration
      #
 
      #echo "1" > /proc/sys/net/ipv4/conf/all/rp_filter
      #echo "1" > /proc/sys/net/ipv4/conf/all/proxy_arp
      #echo "1" > /proc/sys/net/ipv4/ip_dynaddr
 
      ###########################################################################
      #
      # 4. rules set up.
      #
 
      ######
      # 4.1 Filter table
      #
 
      #
      # 4.1.1 Set policies
      #
 
      $IPTABLES -P INPUT DROP
      $IPTABLES -P OUTPUT DROP
      $IPTABLES -P FORWARD DROP
 
      #
      # 4.1.2 Create userspecified chains
      #
 
      #
      # Create chain for bad tcp packets
      #
 
      $IPTABLES -N bad_tcp_packets
 
      #
      # Create separate chains for ICMP, TCP and UDP to traverse
      #
 
      $IPTABLES -N allowed
      $IPTABLES -N tcp_packets
      $IPTABLES -N udp_packets
      $IPTABLES -N icmp_packets
 
      #
      # 4.1.3 Create content in userspecified chains
      #
 
      #
      # bad_tcp_packets chain
      #
 
      $IPTABLES -A bad_tcp_packets -p tcp –tcp-flags SYN,ACK SYN,ACK \
      –m state –state NEW -j REJECT –reject-with tcp-reset
      $IPTABLES -A bad_tcp_packets -p tcp ! –syn -m state –state NEW -j LOG \
      –log-prefix «New not syn:»
      $IPTABLES -A bad_tcp_packets -p tcp ! –syn -m state –state NEW -j DROP
 
      #
      # allowed chain
      #
 
      $IPTABLES -A allowed -p TCP –syn -j ACCEPT
      $IPTABLES -A allowed -p TCP -m state –state ESTABLISHED,RELATED -j ACCEPT
      $IPTABLES -A allowed -p TCP -j DROP
 
      #
      # TCP rules
      #
 
      $IPTABLES -A tcp_packets -p TCP -s 0/0 –dport 21 -j allowed
      $IPTABLES -A tcp_packets -p TCP -s 0/0 –dport 22 -j allowed
      $IPTABLES -A tcp_packets -p TCP -s 0/0 –dport 80 -j allowed
      $IPTABLES -A tcp_packets -p TCP -s 0/0 –dport 113 -j allowed
 
      #
      # UDP ports
      #
 
      $IPTABLES -A udp_packets -p UDP -s 0/0 –source-port 53 -j ACCEPT
      if [ $DHCP == «yes» ] ; then
      $IPTABLES -A udp_packets -p UDP -s $DHCP_SERVER –sport 67 \
      –dport 68 -j ACCEPT
      fi
 
      #$IPTABLES -A udp_packets -p UDP -s 0/0 –source-port 53 -j ACCEPT
      #$IPTABLES -A udp_packets -p UDP -s 0/0 –source-port 123 -j ACCEPT
      $IPTABLES -A udp_packets -p UDP -s 0/0 –source-port 2074 -j ACCEPT
      $IPTABLES -A udp_packets -p UDP -s 0/0 –source-port 4000 -j ACCEPT
 
      #
      # In Microsoft Networks you will be swamped by broadcasts. These lines
      # will prevent them from showing up in the logs.
      #
 
      #$IPTABLES -A udp_packets -p UDP -i $INET_IFACE \
      #–destination-port 135:139 -j DROP
 
      #
      # If we get DHCP requests from the Outside of our network, our logs will
      # be swamped as well. This rule will block them from getting logged.
      #
 
      #$IPTABLES -A udp_packets -p UDP -i $INET_IFACE -d 255.255.255.255 \
      #–destination-port 67:68 -j DROP
 
      #
      # ICMP rules
      #
 
      $IPTABLES -A icmp_packets -p ICMP -s 0/0 –icmp-type 8 -j ACCEPT
      $IPTABLES -A icmp_packets -p ICMP -s 0/0 –icmp-type 11 -j ACCEPT
 
      #
      # 4.1.4 INPUT chain
      #
 
      #
      # Bad TCP packets we don't want.
      #
 
      $IPTABLES -A INPUT -p tcp -j bad_tcp_packets
 
      #
      # Rules for special networks not part of the Internet
      #
 
      $IPTABLES -A INPUT -p ALL -i $LAN_IFACE -s $LAN_IP_RANGE -j ACCEPT
      $IPTABLES -A INPUT -p ALL -i $LO_IFACE -j ACCEPT
 
      #
      # Special rule for DHCP requests from LAN, which are not caught properly
      # otherwise.
      #
 
      $IPTABLES -A INPUT -p UDP -i $LAN_IFACE –dport 67 –sport 68 -j ACCEPT
 
      #
      # Rules for incoming packets from the internet.
      #
 
      $IPTABLES -A INPUT -p ALL -i $INET_IFACE -m state –state ESTABLISHED,RELATED \
      –j ACCEPT
      $IPTABLES -A INPUT -p TCP -i $INET_IFACE -j tcp_packets
      $IPTABLES -A INPUT -p UDP -i $INET_IFACE -j udp_packets
      $IPTABLES -A INPUT -p ICMP -i $INET_IFACE -j icmp_packets
 
      #
      # If you have a Microsoft Network on the outside of your firewall, you may
      # also get flooded by Multicasts. We drop them so we do not get flooded by
      # logs
      #
 
      #$IPTABLES -A INPUT -i $INET_IFACE -d 224.0.0.0/8 -j DROP
 
      #
      # Log weird packets that don't match the above.
      #
 
      $IPTABLES -A INPUT -m limit –limit 3/minute –limit-burst 3 -j LOG \
      –log-level DEBUG –log-prefix "IPT INPUT packet died: "
 
      #
      # 4.1.5 FORWARD chain
      #
 
      #
      # Bad TCP packets we don't want
      #
 
      $IPTABLES -A FORWARD -p tcp -j bad_tcp_packets
 
      #
      # Accept the packets we actually want to forward
      #
 
      $IPTABLES -A FORWARD -i $LAN_IFACE -j ACCEPT
      $IPTABLES -A FORWARD -m state –state ESTABLISHED,RELATED -j ACCEPT
 
      #
      # Log weird packets that don't match the above.
      #
 
      $IPTABLES -A FORWARD -m limit –limit 3/minute –limit-burst 3 -j LOG \
      –log-level DEBUG –log-prefix "IPT FORWARD packet died: "
 
      #
      # 4.1.6 OUTPUT chain
      #
 
      #
      # Bad TCP packets we don't want.
      #
 
      $IPTABLES -A OUTPUT -p tcp -j bad_tcp_packets
 
      #
      # Special OUTPUT rules to decide which IP's to allow.
      #
 
      $IPTABLES -A OUTPUT -p ALL -s $LO_IP -j ACCEPT
      $IPTABLES -A OUTPUT -p ALL -s $LAN_IP -j ACCEPT
      $IPTABLES -A OUTPUT -p ALL -o $INET_IFACE -j ACCEPT
 
      #
      # Log weird packets that don't match the above.
      #
 
      $IPTABLES -A OUTPUT -m limit –limit 3/minute –limit-burst 3 -j LOG \
      –log-level DEBUG –log-prefix "IPT OUTPUT packet died: "
 
      ######
      # 4.2 nat table
      #
 
      #
      # 4.2.1 Set policies
      #
 
      #
      # 4.2.2 Create user specified chains
      #
 
      #
      # 4.2.3 Create content in user specified chains
      #
 
      #
      # 4.2.4 PREROUTING chain
      #
 
      #
      # 4.2.5 POSTROUTING chain
      #
 
      if [ $PPPOE_PMTU == «yes» ] ; then
      $IPTABLES -t nat -A POSTROUTING -p tcp –tcp-flags SYN,RST SYN \
      –j TCPMSS –clamp-mss-to-pmtu
      fi
      $IPTABLES -t nat -A POSTROUTING -o $INET_IFACE -j MASQUERADE
 
      #
      # 4.2.6 OUTPUT chain
      #
 
      ######
      # 4.3 mangle table
      #
 
      #
      # 4.3.1 Set policies
      #
 
      #
      # 4.3.2 Create user specified chains
      #
 
      #
      # 4.3.3 Create content in user specified chains
      #
 
      #
      # 4.3.4 PREROUTING chain
      #
 
      #
      # 4.3.5 INPUT chain
      #
 
      #
      # 4.3.6 FORWARD chain
      #
 
      #
      # 4.3.7 OUTPUT chain
      #
 
      #
      # 4.3.8 POSTROUTING chain
      #

      #!/bin/sh
      #
      # rc.flush-iptables – Resets iptables to default values.
      #
      # Copyright (C) 2001 Oskar Andreasson <bluefluxATkoffeinDOTnet>
      #
      # This program is free software; you can redistribute it and/or modify
      # it under the terms of the GNU General Public License as published by
      # the Free Software Foundation; version 2 of the License.
      #
      # This program is distributed in the hope that it will be useful,
      # but WITHOUT ANY WARRANTY; without even the implied warranty of
      # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
      # GNU General Public License for more details.
      #
      # You should have received a copy of the GNU General Public License
      # along with this program or from the site that you downloaded it
      # from; if not, write to the Free Software Foundation, Inc., 59 Temple
      # Place, Suite 330, Boston, MA 02111-1307 USA
 
      #
      # Configurations
      #
      IPTABLES="/usr/sbin/iptables"
 
      #
      # reset the default policies in the filter table.
      #
      $IPTABLES -P INPUT ACCEPT
      $IPTABLES -P FORWARD ACCEPT
      $IPTABLES -P OUTPUT ACCEPT
 
      #
      # reset the default policies in the nat table.
      #
      $IPTABLES -t nat -P PREROUTING ACCEPT
      $IPTABLES -t nat -P POSTROUTING ACCEPT
      $IPTABLES -t nat -P OUTPUT ACCEPT
 
      #
      # reset the default policies in the mangle table.
      #
      $IPTABLES -t mangle -P PREROUTING ACCEPT
      $IPTABLES -t mangle -P OUTPUT ACCEPT
 
      #
      # flush all the rules in the filter and nat tables.
      #
      $IPTABLES -F
      $IPTABLES -t nat -F
      $IPTABLES -t mangle -F
      #
      # erase all chains that's not default in filter and nat table.
      #
      $IPTABLES -X
      $IPTABLES -t nat -X
      $IPTABLES -t mangle -X

      #!/bin/bash
      #
      # rc.test-iptables – test script for iptables chains and tables.
      #
      # Copyright (C) 2001 Oskar Andreasson <bluefluxATkoffeinDOTnet>
      #
      # This program is free software; you can redistribute it and/or modify
      # it under the terms of the GNU General Public License as published by
      # the Free Software Foundation; version 2 of the License.
      #
      # This program is distributed in the hope that it will be useful,
      # but WITHOUT ANY WARRANTY; without even the implied warranty of
      # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
      # GNU General Public License for more details.
      #
      # You should have received a copy of the GNU General Public License
      # along with this program or from the site that you downloaded it
      # from; if not, write to the Free Software Foundation, Inc., 59 Temple
      # Place, Suite 330, Boston, MA 02111-1307 USA
      #
 
      #
      # Filter table, all chains
      #
      iptables -t filter -A INPUT -p icmp –icmp-type echo-request \
      –j LOG –log-prefix="filter INPUT:"
      iptables -t filter -A INPUT -p icmp –icmp-type echo-reply \
      –j LOG –log-prefix="filter INPUT:"
      iptables -t filter -A OUTPUT -p icmp –icmp-type echo-request \
      –j LOG –log-prefix="filter OUTPUT:"
      iptables -t filter -A OUTPUT -p icmp –icmp-type echo-reply \
      –j LOG –log-prefix="filter OUTPUT:"
      iptables -t filter -A FORWARD -p icmp –icmp-type echo-request \
      –j LOG –log-prefix="filter FORWARD:"
      iptables -t filter -A FORWARD -p icmp –icmp-type echo-reply \
      –j LOG –log-prefix="filter FORWARD:"
 
      #
      # NAT table, all chains except OUTPUT which don't work.
      #
      iptables -t nat -A PREROUTING -p icmp –icmp-type echo-request \
      –j LOG –log-prefix="nat PREROUTING:"
      iptables -t nat -A PREROUTING -p icmp –icmp-type echo-reply \
      –j LOG –log-prefix="nat PREROUTING:"
      iptables -t nat -A POSTROUTING -p icmp –icmp-type echo-request \
      –j LOG –log-prefix="nat POSTROUTING:"
      iptables -t nat -A POSTROUTING -p icmp –icmp-type echo-reply \
      –j LOG –log-prefix="nat POSTROUTING:"
      iptables -t nat -A OUTPUT -p icmp –icmp-type echo-request \
      –j LOG –log-prefix="nat OUTPUT:"
      iptables -t nat -A OUTPUT -p icmp –icmp-type echo-reply \
      –j LOG –log-prefix="nat OUTPUT:"
 
      #
      # Mangle table, all chains
      #
      iptables -t mangle -A PREROUTING -p icmp –icmp-type echo-request \
      –j LOG –log-prefix="mangle PREROUTING:"
      iptables -t mangle -A PREROUTING -p icmp –icmp-type echo-reply \
      –j LOG –log-prefix="mangle PREROUTING:"
      iptables -t mangle -I FORWARD 1 -p icmp –icmp-type echo-request \
      –j LOG –log-prefix="mangle FORWARD:"
      iptables -t mangle -I FORWARD 1 -p icmp –icmp-type echo-reply \
      –j LOG –log-prefix="mangle FORWARD:"
      iptables -t mangle -I INPUT 1 -p icmp –icmp-type echo-request \
      –j LOG –log-prefix="mangle INPUT:"
      iptables -t mangle -I INPUT 1 -p icmp –icmp-type echo-reply \
      –j LOG –log-prefix="mangle INPUT:"
      iptables -t mangle -A OUTPUT -p icmp –icmp-type echo-request \
      –j LOG –log-prefix="mangle OUTPUT:"
      iptables -t mangle -A OUTPUT -p icmp –icmp-type echo-reply \
      –j LOG –log-prefix="mangle OUTPUT:"
      iptables -t mangle -I POSTROUTING 1 -p icmp –icmp-type echo-request \
      –j LOG –log-prefix="mangle POSTROUTING:"
      iptables -t mangle -I POSTROUTING 1 -p icmp –icmp-type echo-reply \
      –j LOG –log-prefix="mangle POSTROUTING:"