1. Configuration– Прежде всего мы должны задать параметры конфигурации, для сценария. Параметры Конфигурации, в большинстве случаев, должны быть описаны первыми в любом сценарии.
1.1 Internet– Это раздел конфигурации, описывающей подключение к Internet. Этот раздел может быть опущен, если вы не подключены к Интернет. Обратите внимание, что может иметься большее количество подразделов чем, здесь перечислено, но только те, которые описывают наше подключение к Internet.
1.1.1 DHCP– Если имеются специфичные для DHCP настройки, то они добавляются здесь.
1.1.2 PPPoE– Описываются параметры настройки PPPoE подключения.
1.2 LAN– Если имеется любая ЛОКАЛЬНАЯ СЕТЬ за брандмауэром, то здесь указываются параметры, имеющие отношение к ней. Наиболее вероятно, что этот раздел будет присутствовать почти всегда.
1.3 DMZ– Здесь добавляется конфигурация зоны
DMZ. В большинстве сценариев этого раздела не будет, т.к. любая нормальная домашняя сеть, или маленькая локальная сеть, не будет иметь ее. (
DMZ– de-militarized zone. Скорее всего под это понятие автор подвел небольшую подсеть, в которой расположены серверы, например:
DNS,
MAIL,
WEBи т.п, и нет ни одной пользовательской машины.
прим. перев.)
1.4 Localhost– Эти параметры принадлежат нашему брандмауэру (localhost). В вашем случае эти переменные вряд ли изменятся, но, тем не менее, я создал эти переменные.Хотелось бы надеяться, что у вас не будет причин изменять эти переменные.
1.5 iptables– Этот раздел содержит информацию об iptables. В большинстве сценариев достаточно будет только одной переменной, которая указывает путь к iptables.
1.6 Other– Здесь располагаются прочие настройки, которые не относятся и к одному из вышеуказанных разделов.
2. Module loading– Этот раздел сценариев содержит список модулей. Первая часть должна содержать требуемые модули, в то время как вторая часть должна содержать нетребуемые модули.
ПРИМЕЧАНИЕ: Обратить внимание. Некоторые модули, отвечающие за дополнительные возможности, могут быть указаны даже если они не требуются. Обычно, в таких случаях, пример сценария отмечает эту особенность.
2.1 Required modules– Этот раздел должен содержать модули, необходимые для работы сценария.
2.2 Non-required modules– Этот раздел содержит модули, которые не требуются для нормальной работы сценария. Все эти модули должны быть закомментированы. Если вам они потребуются, то вы должны просто раскомментировать их.
3. proc configuration– Этот раздел отвечает за настройку файловой системы /proc. Если эти параметры необходимы – они будут перечислены, если нет, то они должны быть закомментированы по-умолчанию, и указаны как не-требуемые. Большинство полезных настроек /proc будут перечислены в примерах, но далеко не все.
3.1 Required proc configuration– Этот раздел должен содержать все требуемые сценарием настройка для /proc. Это могут быть настройки для запуска системы защиты, возможно, добавляют специальные возможности для администратора или пользователей.
3.2 Non-required proc configuration– Этот раздел должен содержать не-требуемые настройки /proc, которые могут оказаться полезными в будущем. Все они должны быть закомментированы, так как они фактически не требуются для работы сценария. Этот список будет содержать далеко не все настройки /proc.
4 rules set up– К этому моменту скрипт, как правило, уже подготовлен к тому, чтобы вставлять наборы правил. Я разбил все правила по таблицам и цепочкам. Любые пользовательские цепочки должны быть созданы прежде, чем мы сможем их использовать. Я указываю цепочки и их наборы правил в том же порядке, в каком они выводятся командой
iptables -L.
4.1 Filter table– Прежде всего мы проходим таблицу filter. Для начала необходимо установить политику по умолчанию в таблице.
4.1.1 Set policies– Назначение политик по-умолчанию для системных цепочек. Обычно я устанавливаю
DROPдля цепочек в таблице filter, и буду пропускать потоки, которые идут изнутри. Тем самым мы избавимся от всего, что нам неугодно.
4.1.2 Create user specified chains– В этом разделе, создаются все пользовательские цепочки, которые мы будем использовать позже в пределах этой таблицы. Мы не сможем использовать эти цепочки в до тех пор, пока не создадим их.
4.1.3 Create content in user specified chains– После создания пользовательских цепочек, мы можем заполнить их правилами. Единственная причина, по которой правила для пользовательских цепочек определяются здесь – это близость к командам, создающим эти цепочки. Вы же можете размещать правила в другом месте вашего сценария.
4.1.4 INPUT chain– В этом разделе добавляются правила для цепочки INPUT.
ПРИМЕЧАНИЕ: Как уже указывалось, я старался следовать порядку, который получается в выводе команды
iptables -L. Нет серьезных причин, чтобы соблюдать эту структуру, однако, пробуйте избежать смешивания данных из различных таблиц и цепочек, так как станет намного тяжелее читать такой набор правил и выискивать возможные проблемы.
4.1.5 FORWARD chain– Здесь мы добавляем правила в цепочку FORWARD
4.1.6 OUTPUT chain– амой последней в таблице filter, заполняется цепочка OUTPUT.
4.2 nat table– После таблицы filter мы переходим к таблице nat. Сделано это по ряду причин. Прежде всего – не следует запускать механизм NAT на ранней стадии, когда еще возможна передача пакетов без ограничений (то есть, когда NAT уже включена, но нет ни одного правила фильтрации). Также, я рассматриваю таблицу nat как своего рода уровень, который находится вне таблицы filter. Таблица filter является своего рода ядром, в то время как nat – оболочка вокруг ядра, а таблица mangle. может рассматриваться как оболочка вокруг таблицы nat. Это может быть не совсем правильно, но и не далеко от действительности.
4.2.1 Set policies– Прежде всего мы устанавливаем всю политику по умолчанию в пределах таблицы nat. Обычно, я устанавливаю ACCEPT. Эта таблица не должна использоваться для фильтрации, и мы не должны здесь «выбрасывать» (DROP) пакеты. Есть ряд неприятных побочных эффектов которые имеют место быть в таких случаях из-за наших предположений. Я пропускаю все пакеты в этих цепочках, поскольку не вижу никаких причин не делать этого.
4.2.2 Create user specified chains– Здесь создаются все пользовательские цепочки для таблицы nat. Обычно у меня их нет, но я добавил этот раздел на всякий случай. Обратите внимание, что пользовательские цепочки должны быть созданы до их фактического использования.
4.2.3 Create content in user specified chains– Добавление правил в пользовательские цепочки таблицы nat. Принцип размещения правил здесь тот же что и в таблице filter. Я добавляю их здесь потому, что не вижу причин выносить их в другое место.
4.2.4 PREROUTING chain– Цепочка PREROUTING используется для DNAT. В большинстве сценариев DNAT не используется, или по крайней мере закомментирована, чтобы не «открывать ворота» в нашу локальную сеть слишком широко. В некоторых сценариях это правило включено, так как единственная цель этих сценариев состоит в предоставлении услуг, которые без DNAT невозможны.
4.2.5 POSTROUTING chain– Цепочка POSTROUTING используется сценариями, которые я написал, так как в большинстве случаев имеется одна или более локальных сетей, которые мы хотим подключить к Интернет через сетевой экран. Главным образом мы будем использовать SNAT, но в некоторых случаях, мы вынуждены будем использовать MASQUERADE.
4.2.6 OUTPUT chain– Цепочка OUTPUT используется вообще в любом из сценариев. Но я пока не нашел серьезных оснований для использования этой цепочки. Если вы используете эту цепочку, черкните мне пару строк, и я внесу соответствующие изменения в данное руководство.
4.3 mangle table– Таблица mangle – последняя таблица на пути пакетов. Обычно я не использую эту таблицу вообще, так как обычно не возникает потребностей в чем либо, типа изменения TTL поля или поля TOS и пр. Другими словами, я оставил этот раздел пустым в некоторых сценариях, с несколькими исключениями, где я добавил, несколько примеров использования этой таблицы.
4.3.1 Set policies– Здесь задается Политика по-умолчанию. Здесь существуют те же ограничения, что и для таблицы nat. Таблица не должна использоваться для фильтрации, и следовательно вы должны избегать этого. Я не устанавливал никакой политики в любом из сценариев для цепочек в таблице mangle, и вам следут поступать так же.
4.3.2 Create user specified chains– Создаются пользовательские цепочки. Так как я не использую таблицу mangle в сценариях, я не стал создавать пользовательских цепочек. Однако, этот раздел был добавлен на всякий случай.
4.3.3 Create content in user specified chains– Если вы создали какие либо пользовательские цепочки в пределах этой таблицы, вы можете заполнить их правилами здесь.
4.3.4 PREROUTING– В этом пункте имеется только упоминание о цепочке.
4.3.5 INPUT chain– В этом пункте имеется только упоминание о цепочке.
4.3.6 FORWARD chain– В этом пункте имеется только упоминание о цепочке.
4.3.7 OUTPUT chain– В этом пункте имеется только упоминание о цепочке.
4.3.8 POSTROUTING chain– В этом пункте имеется только упоминание о цепочке.
Надеюсь, что я объяснил достаточно подробно, как каждый сценарий структурирован и почему они структурированы таким способом.
ОСТОРОЖНО: Обратить внимание, что эти описания чрезвычайно кратки, и являются лишь кратким пояснением того, почему сценарии имеют такую структуру. Я не претендую на истину в последней инстанции и не утверждаю, что это – единственный и лучший вариант.
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
Сценарий 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. Это может привести к излишним усложнениям, что в свою очередь, влечет ослабление защиты. Чем проще скрипт, тем проще его сопровождать.
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
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.
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. Теперь вы должны ясно видеть все используемые цепочки и порядок их прохождения.
ПРИМЕЧАНИЕ: Этот сценарий был написан исключительно в демонстрационных целях. Другими словами, не следует иметь правила для журналирования подобно этим, которые регистрируют все пакеты без ограничений. В противном случае вы рискуете стать легкой добычей для злоумышленника, который может засыпать вас пакетами, «раздуть» ваш лог, что может вызвать «Отказ в обслуживании», а после этого перейти к реальному взлому вашей системы не боясь быть обнаруженным, поскольку не сможет быть зарегистрирован системой.
8.7. rc.flush-iptables.txt
Сценарий rc.flush-iptables.txt в действительности не имеет самостоятельной ценности поскольку он сбрасывает все ваши таблицы и цепочки. В начале сценария, устанавливаются политики по-умолчанию ACCEPT для цепочек
INPUT,
OUTPUTи
FORWARDв таблице filter. После этого сбрасываются в заданную по-умолчанию политики для цепочек
PREROUTING,
POSTROUTINGи
OUTPUTтаблицы nat. Эти действия выполняются первыми, чтобы не возникало проблем с закрытыми соединениями и блокируемыми пакетами. Фактически, этот сценарий может использоваться для подготовки брандмауэра к настройке и при отладке ваших сценариев, поэтому здесь мы заботимся только об очистке набора правил и установке политик по-умолчанию.
Когда выполнена установка политик по-умолчанию, мы переходим к очистке содержимого цепочек в таблицах
filterи
nat, а затем производится удаление всех, определенных пользователем, цепочек. После этого работа скрипта завершается. Если вы используете таблицу
mangle, то вы должны будете добавить в сценарий соответствующие строки для обработки этой таблицы.
ПРИМЕЧАНИЕ: В заключение пару слов. Очень многие спрашивают меня, а почему бы не поместить вызов этого сценария в 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.
Приложение A. Детальное описание специальных команд
A.1. Вывод списка правил
Чтобы вывести список правил нужно выполнить команду
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
A.2. Изменение и очистка ваших таблиц
По мере того как вы продолжите углубляться в исследование
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вам необходимо внести дополнения в этот сценарий, поскольку он ее не обрабатывает.
Приложение B. Общие проблемы и вопросы
B.1. Проблемы загрузки модулей
Вы можете столкнуться с несколькими проблемами при попытке загрузить тот или иной модуль. Например, может быть выдано сообщение об отсутствии запрашиваемого модуля
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:
