RussianLDP Є┼╩╘╔╬╟@Mail.ru
WebMoney: 
WMZ Z294115950220 
WMR R409981405661 
WME E134003968233 		 Visa 
4274 3200 2453 6495 

Глава 8. Примеры скриптов

Цель этой главы состоит в том, чтобы дать краткое описание каждого скрипта в этом руководстве. Эти скрипты не совершенны и не могут полностью соответствовать Вашим нуждам. Это означает, что Вы должны сами подогнать эти скрипты под себя. Последующая часть руководства призвана облегчить Вам эту подгонку.

8.1. Структура файла rc.firewall.txt

Все скрипты, описанные в этом руководстве, имеют определенную структуру. Сделано это для того, чтобы они были максимально похожи друг на друга, облегчая тем самым поиск различий между ними. Эта структура довольно хорошо описывается в этой главе. Здесь я надеюсь дать Вам понимание, почему все скрипты были написаны именно так, и почему я выбрал именно эту структуру.

Note

Обратите внимание на то, что эта структура может оказаться далеко не оптимальной для Ваших скриптов. Эта структура выбрана лишь для лучшего объяснения хода моих мыслей.

8.1.1. Структура

Это структура, которой следуют все скрипты в этом руководстве. Если Вы обнаружите, что это не так, то скорее всего это моя ошибка, если конечно я не объяснил, почему я нарушил эту структуру.

  1. Configuration: Прежде всего мы должны задать параметры конфигурации для скрипта. Параметры конфигурации, в большинстве случаев, должны быть описаны первыми в любом скрипте.

    1. Internet. Это раздел конфигурации, описывающей подключение к Internet. Этот раздел может быть опущен, если Вы не подключены к Интернет. Обратите внимание, что может имется большее количество подразделов, чем здесь перечислено, но только те, которые описывают наше подключение к Internet.

      1. DHCP. Если имеются специфичные для DHCP настройки, то они добавляются здесь.

      2. PPPoE. Описываются параметры настройки PPPoE-подключения.

    2. LAN. Если имеется любая локальная сеть за брандмауэром, то здесь указываются параметры, имеющие отношение к ней. Наиболее вероятно, что этот раздел будет присутствовать почти всегда.

    3. DMZ. Здесь добавляется конфигурация зоны DMZ. В большинстве скриптов этого раздела не будет, так как любая нормальная домашняя сеть или маленькая локальная сеть не будет иметь ее.

    4. Localhost. Эти параметры принадлежат нашему брандмауэру (localhost). В Вашем случае эти переменные вряд ли изменятся, но тем не менее я создал эти переменные. Хотелось бы надеяться, что у Вас не будет причин изменять эти переменные.

    5. iptables. Этот раздел содержит информацию об iptables. В большинстве скриптов достаточно будет только одной переменной, которая указывает путь к iptables.

    6. Other. Здесь располагаются прочие настройки, которые не относятся ни к одному из вышеуказанных разделов.

  2. Module loading. Этот раздел скрипта содержит список модулей. Первая часть должна содержать требуемые модули в то время, как вторая часть должна содержать не требуемые модули.

    Note

    Обратите внимание. Некоторые модули, отвечающие за дополнительные возможности, могут быть указаны, даже если они не требуются. Обычно в таких случаях пример отмечает эту особенность.

    1. Required modules: Этот раздел должен содержать модули, необходимые для работы скрипта.

    2. Non-required modules: Этот раздел содержит модули, которые не требуются для нормальной работы. Все эти модули должны быть закомментированы. Если они потребуются, то Вы должны просто раскомментировать их.

  3. proc configuration: Этот раздел отвечает за настройку файловой системы /proc. Если эти параметры необходимы, они будут перечислены, если нет, то они должны быть закомментированы по умолчанию и указаны как не требуемые. Большинство полезных настроек /proc будут перечислены в примерах, но далеко не все.

    1. Required proc configuration: Этот раздел должен содержать все требуемые настройки для /proc. Это могут быть настройки для запуска системы защиты, возможно, добавляющие специальные возможности для администратора или пользователей.

    2. Non-required proc configuration: Этот раздел должен содержать не требуемые настройки /proc, которые могут оказаться полезными в будущем. Все они должны быть закомментированы, так как они фактически не требуются для работы. Этот список будет содержать далеко не все настройки /proc.

  4. rules set up: К этому моменту скрипт, как правило, уже подготовлен к тому, чтобы вставлять наборы правил. Я разбил все правила по таблицам и цепочкам. Любые пользовательские цепочки должны быть созданы прежде, чем мы сможем их использовать. Я указываю цепочки и их наборы правил в том же порядке, в каком они выводятся командой iptables -L.

    1. Filter table. Прежде всего мы проходим таблицу filter. Для начала необходимо установить политику по умолчанию в таблице.

      1. Set policies. Назначение политик по умолчанию для системных цепочек. Обычно я устанавливаю DROP для цепочек в таблице filter и буду пропускать потоки, которые идут изнутри. Тем самым мы избавимся от всего, что нам неугодно.

      2. Create user specified chains. В этом разделе создаются все пользовательские цепочки, которые мы будем использовать позже в пределах этой таблицы. Мы не сможем использовать эти цепочки до тех пор, пока не создадим их.

      3. Create content in user specified chains. После создания пользовательских цепочек мы можем заполнить их правилами. Единственная причина, по которой правила для пользовательских цепочек определяются здесь, это близость к командам, создающим эти цепочки. Вы же можете размещать правила в другом месте скрипта.

      4. INPUT chain. В этом разделе добавляются правила для цепочки INPUT.

        Note

        Как уже указывалось, я старался следовать порядку, который получается в выводе команды iptables -L. Нет серьезных причин, чтобы соблюдать эту структуру, однако, пробуйте избежать смешивания данных из различных таблиц и цепочек, так как станет намного тяжелее читать такой набор правил и выискивать возможные проблемы.

      5. FORWARD chain. Здесь мы добавляем правила в цепочку FORWARD

      6. OUTPUT chain. Самой последней в таблице filter заполняется цепочка OUTPUT.

    2. nat table. После таблицы filter мы переходим к таблице nat. Сделано это по ряду причин. Прежде всего: не следует запускать механизм NAT на ранней стадии, когда еще возможна передача пакетов без ограничений (то есть, когда NAT уже включена, но нет ни одного правила фильтрации). Также я рассматриваю таблицу nat как своего рода уровень, который находится вне таблицы filter. Таблица filter является своего рода ядром, в то время как nat оболочка вокруг ядра, а таблица mangle. может рассматриваться как оболочка вокруг таблицы nat. Это может быть не совсем правильно, но и не далеко от действительности.

      1. Set policies. Прежде всего мы устанавливаем всю политику по умолчанию в пределах таблицы nat. Обычно я устанавливаю ACCEPT. Эта таблица не должна использоваться для фильтрации, и мы не должны здесь выбрасывать (DROP) пакеты. Есть ряд неприятных побочных эффектов, которые имеют место быть в таких случаях из-за наших предположений. Я пропускаю все пакеты в этих цепочках, поскольку не вижу никаких причин не делать этого.

      2. Create user specified chains. Здесь создаются все пользовательские цепочки для таблицы nat. Обычно у меня их нет, но я добавил этот раздел на всякий случай. Обратите внимание, что пользовательские цепочки должны быть созданы до их фактического использования.

      3. Create content in user specified chains. Добавление правил в пользовательские цепочки таблицы nat. Принцип размещения правил здесь тот же, что и в таблице filter. Я добавляю их здесь потому, что не вижу причин выносить их в другое место.

      4. PREROUTING chain. Цепочка PREROUTING используется для DNAT. В большинстве скриптов DNAT не используется или по крайней мере закомментирована, чтобы не "открывать ворота" в нашу локальную сеть слишком широко. В некоторых скриптах это правило включено, так как единственная цель этих скриптов состоит в предоставлении услуг, которые без DNAT невозможны.

      5. POSTROUTING chain. Цепочка POSTROUTING используется скриптами, которые я написал, так как в большинстве случаев имеется одна или более локальных сетей, которые мы хотим подключить к Интернет через сетевой экран. Главным образом мы будем использовать SNAT, но в некоторых случаях мы вынуждены будем использовать MASQUERADE.

      6. OUTPUT chain. Цепочка OUTPUT используется вообще в любом из скриптов. Но я пока не нашел серьезных оснований для использования этой цепочки. Если Вы используете эту цепочку, черкните мне пару строк, и я внесу соответствующие изменения в данное руководство.

    3. mangle table. Таблица mangle последняя на пути пакетов. Обычно я не использую эту таблицу вообще, так как обычно не возникает потребностей в чем-либо, типа изменения TTL-поля или TOS и пр. Другими словами, я оставил этот раздел пустым в некоторых скриптах, с несколькими исключениями, где я добавил несколько примеров использования этой таблицы.

      1. Set policies. Здесь задается политика по умолчанию. Здесь существуют те же ограничения, что и для таблицы nat. Таблица не должна использоваться для фильтрации, и следовательно Вы должны избегать этого. Я не устанавливал никакой политики в любом из скриптов для цепочек в таблице mangle, и Вам следут поступать так же.

      2. Create user specified chains. Создаются пользовательские цепочки. Так как я не использую таблицу mangle в скриптах, я не стал создавать пользовательских цепочек. Однако, этот раздел был добавлен на всякий случай.

      3. Create content in user specified chains. Если Вы создали какие-либо пользовательские цепочки в пределах этой таблицы, Вы можете заполнить их правилами здесь.

      4. PREROUTING. В этом пункте имеется только упоминание о цепочке.

      5. INPUT chain. В этом пункте имеется только упоминание о цепочке.

      6. FORWARD chain. В этом пункте имеется только упоминание о цепочке.

      7. OUTPUT chain. В этом пункте имеется только упоминание о цепочке.

      8. POSTROUTING chain. В этом пункте имеется только упоминание о цепочке.

Надеюсь, что я объяснил достаточно подробно, как каждый скрипт структурирован и почему они структурированы таким способом.

Caution

Обратите внимание, что эти описания чрезвычайно кратки и являются лишь кратким пояснением того, почему скрипты имеют такую структуру. Я не претендую на истину в последней инстанции и не утверждаю, что это единственный и лучший вариант.

8.2. rc.firewall.txt

Скрипт 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

8.3. rc.DMZ.firewall.txt

Скрипт 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, чтобы самостоятельно разобраться в тексте скрипта без каких-либо проблем. Если что-то для Вас осталось неясным и это не было рассмотрено в данном документе, то можете сообщить мне об этом, вероятно, это моя ошибка.

8.4. rc.DHCP.firewall.txt

Скрипт 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. Собственно это все, что нужно изменить в действительности.

Мы больше не можем устанавливать правила в цепочке 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 Вы найдете в приложении Ссылки на другие ресурсы.

Note

Этот скрипт менее безопасен, чем 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. Это может привести к излишним усложнениям, что в свою очередь влечет ослабление защиты. Чем проще скрипт, тем проще его сопровождать.

8.5. rc.UTIN.firewall.txt

Скрипт 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

8.6. rc.test-iptables.txt

Скрипт rc.test-iptables.txt предназначен для проверки различных цепочек, но может потребовать дополнительных настроек, в зависимости от Вашей конфигурации, например, включения ip_forwarding или настройки masquerading и т.п. Тем не менее в большинстве случаев с базовыми настройками, когда настроены основные таблицы, этот скрипт будет работоспособен. В действительности, в этом скрипте производится установка действий LOG на ping-запросы и ping-ответы. Таким способом появляется возможность зафиксировать в системном журнале, какие цепочки проходились и в каком порядке. Запустите скрипт и затем выполните следующие команды:


ping -c 1 host.on.the.internet

И во время исполнения первой команды выполните tail -n 0 -f /var/log/messages. Теперь Вы должны ясно видеть все используемые цепочки и порядок их прохождения.

Note

Этот скрипт был написан исключительно в демонстрационных целях. Другими словами, не следует иметь правила для журналирования подобно этим, которые регистрируют все пакеты без ограничений. В противном случае Вы рискуете стать легкой добычей для злоумышленника, который может засыпать Вас пакетами, раздуть Ваш лог, что может вызвать отказ в обслуживании, а после этого перейти к реальному взлому Вашей системы, не боясь быть обнаруженным, поскольку не сможет быть зарегистрирован системой.

8.7. rc.flush-iptables.txt

Скрипт rc.flush-iptables.txt в действительности не имеет самостоятельной ценности, поскольку он сбрасывает все Ваши таблицы и цепочки. В начале скрипта устанавливаются политики по умолчанию ACCEPT для цепочек INPUT, OUTPUT и FORWARD в таблице filter. После этого сбрасываются в заданную по умолчанию политики для цепочек PREROUTING, POSTROUTING и OUTPUT таблицы nat. Эти действия выполняются первыми, чтобы не возникало проблем с закрытыми соединениями и блокируемыми пакетами. Фактически, этот скрипт может использоваться для подготовки брандмауэра к настройке и при отладке скриптов, поэтому здесь мы заботимся только об очистке набора правил и установке политик по умолчанию.

Когда выполнена установка политик по умолчанию, мы переходим к очистке содержимого цепочек в таблицах filter и nat, а затем производится удаление всех определенных пользователем цепочек. После этого работа скрипта завершается. Если Вы используете таблицу mangle, то Вы должны будете добавить в скрипт соответствующие строки для обработки этой таблицы.

Note

В заключение пару слов. Очень многие спрашивают, а почему бы не поместить вызов этого скрипта в rc.firewal, написав что-нибудь типа rc.firewall start для запуска скрипта. Я не сделал этого до сих пор, потому что считаю, что учебный материал должен нести в себе основные идеи и не должен быть перегружен разнообразными скриптами со странным синтаксисом. Добавление специфичного синтаксиса делает скрипты менее читабельными, а сам учебный материал более сложным в понимании, поэтому данное руководство остается таким, каково оно есть, и продолжит оставаться таким.

8.8. Limit-match.txt

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

8.9. Pid-owner.txt

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

8.10. Sid-owner.txt

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

8.11. Ttl-inc.txt

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

8.12. Iptables-save ruleset

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

Ё╧╔╙╦

  

ю┴╩─╔ ╙╫╧╔╚ ╦╧╠╠┼╟!