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 вам необходимо внести дополнения в этот сценарий, поскольку он ее не обрабатывает.
AGGREGATION WITH INDEPENDENT WORKS
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.
APPLICABILITY AND DEFINITIONS
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.
Цепочка FORWARD
Цепочка FORWARD содержит очень небольшое количество правил. Первое правило напрвляет все TCP пакеты на проверку в цепочку bad_tcp_packets, которая используется так же и в цепочке INPUT. Цепочка bad_tcp_packets сконструирована таким образом, что может вызываться из других цепочек, невзирая на то, куда направляется пакет. После проверки TCP пакетов, как обычно, мы разрешем движение пакетов из локальной сети без ограничений.
Далее, пропускается весь трафик из локальной сети без ограничений. Естественно, нужно пропустить ответные пакеты в локальную сеть, поэтому следующим правилом мы пропускаем все, что имеет признак ESTABLISHED или RELATED, т.е. мы пропускаем пакеты по соединению установленному ИЗ локальной сети.
И в заключение заносим в системный журнал информацию о сброшенных пакетах, предваряя их префиксом "IPT FORWARD packet died: ", чтобы потом, в случае поиска ошибок, не перепутать их с пакетами, сброшенными в цепочке INPUT.
Цепочка INPUT
Цепочка INPUT, как я уже писал, для выполнения основной работы использует другие цепочки, за счет чего снижая нагрузку на сетевой фильтр. Эффект применения такого варианта организации правил лучше заметен на медленных машинах, которые в другом случае начинают "терять" пакеты при высокой нагрузке. Достигается это разбиением набора правил по некоторому признаку и выделение их в отдельные цепочки. Тем самым уменьшается количество правил, которое проходит каждый пакет.
Первым же правилом мы пытаемся отбросить "плохие" пакеты. За дополнительной информацией обращайтесь к приложению Цепочка bad_tcp_packets. В некоторых особенных ситуациях такие пакеты могут считаться допустимыми, но в 99% случаев лучше их "остановить". Поэтому такие пакеты заносятся в системный журнал (логируются) и "сбрасываются".
Далее следует целая группа правил, которая пропускает весь трафик, идущий из доверительной сети, которая включает в себя сетевой адаптер, связанный с локальной сетью и локальный сетевой интерфейс (lo) и имеющий исходные адреса нашей локальной сети (включая реальный IP адрес). Эта группа правил стоит первой по той простой причине, что локальная сеть генерирует значительно бОльший трафик чем трафик из Internet. Поэтому, при построении своих наборов правил, всегда старайтесь учитывать объем трафика, указывая первыми те правила, которые будут обслуживать больший трафик.
Первым в группе, анализирующей трафик идущий с $INET_IFACE, стоит правило, пропускающее все пакеты со статусом ESTABLISHED или RELATED (эти пакеты являются частью уже УСТАНОВЛЕННОГО или СВЯЗАННОГО соединения). Это правило эквивалентно правилу, стоящему в цепочке allowed. И в некоторой степени является избыточным, поскольку затем цепочка allowed вызывается опосредованно через цепочку tcp_packets, однако оно несколько разгружает сетевой фильтр, поскольку значительная доля трафика пропускается этим праилом и не проходит всю последовательность до цепочки allowed.
После этого производится анализ трафика, идущего из Internet. Все пакеты, приходящие в цепочку INPUT с интерфейса $INET_IFACE распределяются по вложенным цепочкам, в зависимости от типа протокола. TCP пакеты передаются в цепочку tcp_packets, UDP пакеты отправляются в цепочку udp_packets и ICMP перенаправляются в цепочку icmp_packets. Как правило, большую часть трафика "съедают" TCP пакеты, потом UDP и меньший объем приходится на долю ICMP, однако в вашем конкретном случае это предположение может оказаться неверным. Очень важно учитывать объем трафика, проходящего через набор правил. Учет объема трафика - абсолютная необходимость. В случае неоптимального распределения правил даже машину класса Pentium III и выше, с сетевой картой 100 Мбит и большим объемом передаваемых данных по сети, довольно легко можно "поставить на колени" сравнительно небольшим объемом правил.
Далее следует весьма специфическое правило (по-умолчанию закомментировано). Дело в том, что клиенты Microsoft Network имеют "дурную привычку" выдавать огромное количество Multicast (групповых) пакетов в диапазоне адресов 224.0.0.0/8. Поэтому можно использовать данное правило для предотвращения "засорения" логов в случае, если с внешней стороны имеется какая либо сеть Microsoft Network. Подобную же проблему решают два последних правила (по-умолчанию закомментированы) в цепочке udp_packets, описанные в Цепочка для UDP.
Последним правилом, перед тем как ко всем не принятым явно пакетам в цепочке INPUT будет применена политика по-умолчанию, траффик журналируется, на случай необходимости поиска причин возникающих проблем. При этом мы устанавливаем правилу, ограничение на количество логируемых пакетов - не более 3-х в минуту, чтобы предотвратить чрезмерное раздувание журнала и кроме того подобные записи в журнал сопровождаются собственным комментарием (префиксом), чтобы знать откуда появились эти записи.
Все что не было явно пропущено в цепочке INPUT будет подвергнуто действию DROP, поскольку именно это действие назначено в качестве политики по-умолчанию. Политики по-умолчанию были описаны чуть выше в разделе Установка политик по-умолчанию.
Цепочка OUTPUT
Как я уже упоминал ранее, в моем случае компьютер используется как брандмауэр и одновременно как рабочая станция. Поэтому я позволяю покидать мой хост всему, что имеет исходный адрес $LOCALHOST_IP, $LAN_IP или $STATIC_IP. Сделано это для защиты от трафика, который может сфальсицировас моего компьютера, несмотря на то, что я совершенно уверен во всех, кто имеет к нему доступ. И в довершение ко всему, я журналирую "сброшенные" пакеты, на случай поиска ошибок или в целях выявления сфальсифицированных пакетов. Ко всем пакетам, не прошедшим ни одно из правил, применяется политика по-умолчанию -- DROP.
Цепочка PREROUTING таблицы nat
В данном сценарии эта цепочка не имеет ни одного правила и единственно, почему я привожу ее описание здесь, это еще раз напомнить, что в данной цепочке выполняется преобразование сетевых адресов (DNAT) перед тем как пакеты попадут в цепочку INPUT или FORWARD.
 |
Еще раз хочу напомнить, что эта цепочка не предназначена ни для какого вида фильтрации, а только для преобразования адресов, поскольку в эту цепочку попадает только первый пакет из потока. |
COLLECTIONS OF DOCUMENTS
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.
COMBINING DOCUMENTS
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."
COPYING IN QUANTITY
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.
Действие ACCEPT
Данная операция не имеет дополнительных ключей. Если над пакетом выполняется действие ACCEPT, то пакет прекращает движение по цепочке (и всем вызвавшим цепочкам, если текущая цепочка была вложенной) и считается ПРИНЯТЫМ (то бишь пропускается), тем не менее, пакет продолжит движение по цепочкам в других таблицах и может быть отвергнут там. Действие задается с помощью ключа -j ACCEPT.
Действие DNAT
DNAT (Destination Network Address Translation) используется для преобразования адреса места назначения в IP заголовке пакета. Если пакет подпадает под критерий правила, выполняющего DNAT, то этот пакет, и все последующие пакеты из этого же потока, будут подвергнуты преобразованию адреса назначения и переданы на требуемое устройство, хост или сеть. Данное действие может, к примеру, успешно использоваться для предоставления доступа к вашему web-серверу, находящемуся в локальной сети, и не имеющему реального IP адреса. Для этого вы строите правило, которое перехватывает пакеты, идущие на HTTP порт брандмауэра и выполняя DNAT передаете их на локальный адрес web-сервера. Для этого действия так же можно указать диапазон адресов, тогда выбор адреса назначения для каждого нового потока будет производиться случайнам образом.
Действие DNAT может выполняться только в цепочках PREROUTING и OUTPUT таблицы nat, и во вложенных под-цепочках. Важно запомнить, что вложенные подцепочки, реализующие DNAT не должны вызываться из других цепочек, кроме PREROUTING и OUTPUT.
Таблица 6-16. Действие DNAT
| Ключ | --to-destination |
| Пример | iptables -t nat -A PREROUTING -p tcp -d 15.45.23.67 --dport 80 -j DNAT --to-destination 192.168.1.1-192.168.1.10 |
| Описание | Ключ --to-destination указывает, какой IP адрес должен быть подставлен в качестве адреса места назначения. В выше приведенном примере во всех пакетах, пришедших на адрес 15.45.23.67, адрес назначения будет изменен на один из диапазона от 192.168.1.1 до 192.168.1.10. Как уже указывалось выше, все пакеты из одного потока будут направляться на один и тот же адрес, а для каждого нового потока будет выбираться один из адресов в указанном диапазоне случайным образом. Можно также определить единственный IP адрес. Можно дополнительно указать порт или диапазон портов, на который (которые) будет перенаправлен траффик. Для этого после ip адреса через двоеточие укажите порт, например --to-destination 192.168.1.1:80, а указание диапазона портов выглядит так: --to-destination 192.168.1.1:80-100. Как вы можете видеть, синтаксис действий DNAT и SNAT во многом схож. Не забывайте, что указание портов допускается только при работе с протоколом TCP или UDP, при наличии опции --protocol в критерии. |
Действие DNAT достаточно сложно в использовании и требует дополнительного пояснения. Рассмотрим простой пример. У нас есть WEB сервер и мы хотим разрешить доступ к нему из Интернет. Мы имеем только один реальный IP адрес, а WEB-сервер расположен в локальной сети. Реальный IP адрес $INET_IP назначен брандмауэру, HTTP сервер имеет локальный адрес $HTTP_IP и, наконец брандмауэр имеет локальный алрес $LAN_IP. Для начала добавим простое правило в цепочку PREROUTING таблицы nat:
iptables -t nat -A PREROUTING
--dst $INET_IP -p tcp --dport 80 -j DNAT \
--to-destination $HTTP_IP
В соответствии с этим правилом, все пакеты, поступающие на 80-й порт адреса $INET_IP перенаправляются на наш внутренний WEB-сервер. Если теперь обратиться к WEB-серверу из Интернет, то все будет работать прекрасно. Но что же произойдет, если попробовать соединиться с ним из локальной сети? Соединение просто не установится. Давайте посмотрим как маршрутизируются пакеты, идущие из Интернет на наш WEB-сервер. Для простоты изложения примем адрес клиента в Интернет равным $EXT_BOX.
Пакет покидает клиентский узел с адресом $EXT_BOX и направляется на $INET_IP
Пакет приходит на наш брандмауэр.
Брандмауэр, в соответствии с вышеприведенным правилом, подменяет адрес назначения и передает его дальше, в другие цепочки.
Пакет передается на $HTTP_IP.
Пакет поступает на HTTP сервер и сервер передает ответ через брандмауэр, если в таблице маршрутизации он обозначен как шлюз для $EXT_BOX. Как правило, он назначается шлюзом по-умолчанию для HTTP сервера.
Брандмауэр производит обратную подстановку адреса в пакете, теперь все выглядит так, как будто бы пакет был сформирован на брандмауэре.
Пакет передается клиенту $EXT_BOX.
А теперь посмотрим, что произойдет, если запрос посылается с узла, расположенного в той же локальной сети. Для простоты изложения примем адрес клиента в локальной сети равным $LAN_BOX.
Пакет покидает $LAN_BOX.
Поступает на брандмауэр.
Производится подстановка адреса назначения, однако адрес отправителя не подменяется, т.е. исходный адрес остается в пакете без изменения.
Пакет покидает брандмауэр и отправляется на HTTP сервер.
HTTP сервер, готовясь к отправке ответа, обнаруживает, что клиент находится в локальной сети (поскольку пакет запроса содержал оригинальный IP адрес, который теперь превратился в адрес назначения) и поэтому отправляет пакет непосредственно на $LAN_BOX.
Пакет поступает на $LAN_BOX. Клиент "путается", поскольку ответ пришел не с того узла, на который отправлялся запрос. Поэтому клиент "сбрасывает" пакет ответа и продолжает ждать "настоящий" ответ.
Проблема решается довольно просто с помощью SNAT. Ниже приводится правило, которое выполняет эту функцию. Это правило вынуждает HTTP сервер передавать ответы на наш брандмауэр, которые затем будут переданы клиенту.
iptables -t nat -A POSTROUTING -p tcp
--dst $HTTP_IP --dport 80 -j SNAT \
--to-source $LAN_IP
Запомните, цепочка POSTROUTING обрабатывается самой последней и к этому моменту пакет уже прошел процедуру преобразования DNAT, поэтому критерий строится на базе адреса назначения $HTTP_IP.
Если вы думаете, что на этом можно остановиться, то вы ошибаетесь! Представим себе ситуацию, когда в качестве клиента выступает сам брандмауэр. Тогда, к сожалению, пакеты будут передаваться на локальный порт с номером 80 самого брандмауэра, а не на $HTTP_IP. Чтобы разрешить и эту проблему, добавим правило:
iptables -t nat -A OUTPUT --dst $INET_IP -p
tcp --dport 80 -j DNAT \
--to-destination $HTTP_IP
Теперь никаких проблем, с доступом к нашему WEB-серверу, уже не должно возникать.
 |
Каждый должен понять, что эти правила предназначены только лишь для корректной обработки адресации пакетов. В дополнение к этим правилам вам может потребоваться написать дополнительные правила для цепочки FORWARD таблицы filter. Не забудьте при этом, что пакеты уже прошли цепочку PREROUTING и поэтому их адреса назначения уже изменены действием DNAT. |
Действие DROP
Данное действие просто "сбрасывает" пакет и iptables "забывает" о его существовании. "Сброшенные" пакеты прекращают свое движение полностью, т.е. они не передаются в другие таблицы, как это происходит в случае с действием ACCEPT. Следует помнить, что данное действие может иметь негативные последствия, поскольку может оставлять незакрытые "мертвые" сокеты как на стороне сервера, так и на стороне клиента, наилучшим способом защиты будет использование действия REJECT особенно при защите от сканирования портов.
Действие LOG
LOG -- действие, которое служит для журналирования отдельных пакетов и событий. В журнал могут заноситься заголовки IP пакетов и другая интересующая вас информация. Информация из журнала может быть затем прочитана с помощью dmesg или syslogd либо с помощью других программ. Превосходное средство для отладки ваших правил. Неплохо было бы на период отладки правил вместо действия DROP использовать действие LOG, чтобы до конца убедиться, что ваш брандмауэр работает безупречно. Обратите ваше внимание так же на действие ULOG, которое наверняка заинтересует вас своими возможностями, поскольку позволяет выполнять запись журналируемой информации не в системный журнал, а в базу данных MySQL и т.п..
|
Обратите внимание - если у вас имеются проблемы с записью в системный журнал, то это проблемы не iptables или netfilter, а syslogd. За информацией по конфигурированию syslogd обращайтесь к man syslog.conf. |
Действие LOG имеет пять ключей, которые перечислены ниже.
Таблица 6-17. Ключи действия LOG
| Ключ | --log-level |
| Пример | iptables -A FORWARD -p tcp -j LOG --log-level debug |
| Описание | Используется для задания уровня журналирования (log level). Полный список уровней вы найдете в руководстве (man) по syslog.conf. Обычно, можно задать следующие уровни: debug, info, notice, warning, warn, err, error, crit, alert, emerg и panic. Ключевое слово error означает то же самое, что и err, warn - warning и panic - emerg. Важно: в последних трех парах слов не следует использовать error, warn и panic. Приоритет определяет различия в том как будут заноситься сообщения в журнал. Все сообщения заносятся в журнал средствами ядра. Если вы установите строку kern.=info /var/log/iptables в файле syslog.conf, то все ваши сообщения из iptables, использующие уровень info, будут заноситься в файл /var/log/iptables Однако, в этот файл попадут и другие сообщения, поступающие из других подсистем, которые используют уровень info. За дополнительной информацией по syslog и syslog.conf я рекомендую обращаться к manpages и HOWTO. |
| Ключ | --log-prefix |
| Пример | iptables -A INPUT -p tcp -j LOG --log-prefix "INPUT packets" |
| Описание | Ключ задает текст (префикс), которым будут предваряться все сообщения iptables. Сообщения со специфичным префиксом затем легко можно найти, к примеру, с помощью grep. Префикс может содержать до 29 символов, включая и пробелы. |
| Ключ | --log-tcp-sequence |
| Пример | iptables -A INPUT -p tcp -j LOG --log-tcp-sequence |
| Описание | Этот ключ позволяет заносить в журнал номер TCP Sequence пакета. Номер TCP Sequence идентифицирует каждый пакет в потоке и определяет порядок "сборки" потока. Этот ключ потенциально опасен для безопасности системы, если системный журнал разрешает доступ "НА ЧТЕНИЕ" всем пользователям. Как и любой другой журнал, содержащий сообщения от iptables. |
| Ключ | --log-tcp-options |
| Пример | iptables -A FORWARD -p tcp -j LOG --log-tcp-options |
| Описание | Этот ключ позволяет заносить в системный журнал различные сведения из заголовка TCP пакета. Такая возможность может быть полезна при отладке. Этот ключ не имеет дополнительных параметров, как и большинство ключей действия LOG. |
| Ключ | --log-ip-options |
| Пример | iptables -A FORWARD -p tcp -j LOG --log-ip-options |
| Описание | Этот ключ позволяет заносить в системный журнал различные сведения из заголовка IP пакета. Во многом схож с ключом --log-tcp-options, но работает только с IP заголовком. |
Действие MARK
Используется для установки меток для определенных пакетов. Это действие может выполняться только в пределах таблицы mangle. Установка меток обычно используется для нужд маршрутизации пакетов по различным маршрутам, для ограничения трафика и т.п.. За дополнительной информацией вы можете обратиться к Linux Advanced Routing and Traffic Control HOW-TO. Не забывайте, что "метка" пакета существует только в период времени пока пакет не покинул брандмауэр, т.е. метка не передается по сети. Если необходимо как-то пометить пакеты, чтобы использовать маркировку на другой машине, то можете попробовать манипулировать битами поля TOS.
Таблица 6-18. Ключи действия MARK
| Ключ | --set-mark |
| Пример | iptables -t mangle -A PREROUTING -p tcp --dport 22 -j MARK --set-mark 2 |
| Описание | Ключ --set-mark устанавливает метку на пакет. После ключа --set-mark должно следовать целое беззнаковое число. |
Действие MASQUERADE
Маскарадинг (MASQUERADE) в основе своей представляет то же самое, что и SNAT только не имеет ключа --to-source. Причиной тому то, что маскарадинг может работать, например, с dialup подключением или DHCP, т.е. в тех случаях, когда IP адрес присваивается устройству динамически. Если у вас имеется динамическое подключение, то нужно использовать маскарадинг, если же у вас статическое IP подключение, то бесспорно лучшим выходом будет использование действия SNAT.
Маскарадинг подразумевает получение IP адреса от заданного сетевого интерфейса, вместо прямого его указания, как это делается с помощью ключа --to-source в действии SNAT. Действие MASQUERADE имеет хорошее свойство - "забывать" соединения при остановке сетевого интерфейса. В случае же SNAT, в этой ситуации, в таблице трассировщика остаются данные о потерянных соединениях, и эти данные могут сохраняться до суток, поглощая ценную память. Эффект "забывчивости" связан с тем, что при остановке сетевого интерфейса с динамическим IP адресом, есть вероятность на следующем запуске получить другой IP адрес, но в этом случае любые соединения все равно будут потеряны, и было бы глупо хранить трассировочную информацию.
Как вы уже поняли, действие MASQUERADE может быть использовано вместо SNAT, даже если вы имеете постоянный IP адрес, однако, невзирая на положительные черты, маскарадинг не следует считать предпочтительным в этом случае, поскольку он дает большую нагрузку на систему.
Действие MASQUERADE допускается указывать только в цепочке POSTROUTING таблицы nat, так же как и действие SNAT. MASQUERADE имеет ключ, описываемый ниже, использование которого необязательно.
Таблица 6-19. Действие MASQUERADE
| Ключ | --to-ports |
| Пример | iptables -t nat -A POSTROUTING -p TCP -j MASQUERADE --to-ports 1024-31000 |
| Описание | Ключ --to-ports используется для указания порта источника или диапазона портов исходящего пакета. Можно указать один порт, например: --to-ports 1025, или диапазон портов как здесь: --to-ports 1024-3000. Этот ключ можно использовать только в правилах, где критерий содержит явное указание на протокол TCP или UDP с помощью ключа --protocol. |
Действие MIRROR
Действие MIRROR может использоваться вами только для экспериментов и в демонстрационных целях, поскольку это действие может привести к "зацикливанию" пакета и в результате к "Отказу от обслуживания". В результате действия MIRROR в пакете, поля source и destination меняются местами (invert the source and destination fields) и пакет отправляется в сеть. Использование этой команды может иметь весьма забавный результат, наверное, со стороны довольно потешно наблюдать, как какой нибудь кульхацкер пытается "взломать" свой собственный компьютер!
Данное действие допускается использовать только в цепочках INPUT, FORWARD и PREROUTING, и в цепочках, вызываемых из этих трех. Пакеты, отправляемые в сеть действием MIRROR больше не подвергаются фильтрации, трассировке или NAT, избегая тем самым "зацикливания" и других неприятностей. Однако это не означает, что проблем с этим действием нет. Давайте, к примеру, представим, что на хосте, использующем действие MIRROR фабрикуется пакет, с TTL равным 255, на этот же самый хост и пакет подпадает под критерий "зеркалирующего" правила. Пакет "отражается" на этот же хост, а поскольку между "приемником" и "передатчиком" только 1 хоп (hop) то пакет будет прыгать туда и обратно 255 раз. Неплохо для крякера, ведь, при величине пакета 1500 байт, мы потеряем до 380 Кбайт трафика!
Действие QUEUE
ействие QUEUE ставит пакет в очередь на обработку пользовательскому процессу. Оно может быть использовано для нужд учета, проксирования или дополнительной фильтрации пакетов.
От переводчика: Далее автор пространно рассуждает о том, что обсуждение данной темы далеко выходит за рамки документа и пр., поэтому, не мудрствуя лукаво, приведу здесь выдержку из http://antonio.mccinet.ru/protection/iptables_howto.html в переводе Евгения Данильченко aka virii5, eugene@kriljon.ru
"...Для того чтобы эта цель была полезна, необходимы еще два компонента:
"queue handler" - обработчик очереди, который выполняет работу по передаче пакетов между ядром и пользовательским приложением; и
пользовательское приложение которое будет получать, возможно обрабатывать, и решать судьбу пакетов.
Стандартный обработчик очереди для IPv4 - модуль ip-queue, который распространяется с ядром и помечен как экспериментальный. Ниже дан пример, как можно использовать iptables для передачи пакетов в пользовательское приложение:
# modprobe iptable_filter
# modprobe ip_queue # iptables -A OUTPUT -p icmp -j QUEUE
С этим правилом, созданные локально пакеты ICMP типа (такие, что создаются скажем при помощи команды ping) попадают в модуль ip_queue, который затем пытается передать их в пользовательское приложение. Если ни одно из таких приложений не найдено, пакеты сбрасываются. Чтобы написать пользовательскую программу обработки пакетов, используйте libipq API. Оно распространяется с пакетом iptables. Примеры можно найти в testsuite tools (например redirect.c) на CVS. Статус ip_queue можно проверить с помощью: /proc/net/ip_queue Максимальную длинну очереди (то есть, число пакетов передаваемых в пользовательское приложение без подтверждения обработки) можно контролировать с помощью: /proc/sys/net/ipv4/ip_queue_maxlen По умолчанию - максимальная длинна очереди равна 1024. Как только этот предел достигается, новые пакеты будут сбрасываться, пока очередь не снизиться ниже данного предела. Хорошие протоколы, такие как TCP интерпретируют сброшенные пакеты как перегруженность канала передачи, и успешно с этим справляются (насколько я помню, пакет будет просто переслан заново удаленной стороной, прим. перевод.). Однако, может потребоваться некоторого рода эксперементирование, чтобы определить оптимальную длину очереди в каждом конкретном случае, если по умолчанию очередь слишком мала..."
Действие REDIRECT
Выполняет перенаправление пакетов и потоков на другой порт той же самой машины. К примеру, можно пакеты, поступающие на HTTP порт перенаправить на порт HTTP proxy. Действие REDIRECT очень удобно для выполнения "прозрачного" проксирования (transparent proxying), когда машины в локальной сети даже не подозревают о существовании прокси.
REDIRECT может использоваться только в цепочках PREROUTING и OUTPUT таблицы nat. И конечно же это действие можно выполнять в подцепочках, вызываемых и вышеуказанных. Для действия REDIRECT предусмотрен только один ключ.
Таблица 6-20. Действие REDIRECT
| Ключ | --to-ports |
| Пример | iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-ports 8080 |
| Описание | Ключ --to-ports определяет порт или диапазон портов назначения. Без указания ключа --to-ports, перенаправления не происходит, т.е. пакет идет на тот порт, куда и был назначен. В примере, приведенном выше, --to-ports 8080 указан один порт назначения. Если нужно указать диапазон портов, то мы должны написать нечто подобное --to-ports 8080-8090. Этот ключ можно использовать только в правилах, где критерий содержит явное указание на протокол TCP или UDP с помощью ключа --protocol. |
Действие REJECT
REJECT используется, как правило, в тех же самых ситуациях, что и DROP, но в отличие от DROP, команда REJECT выдает сообщение об ошибке на хост, передавший пакет. Действие REJECT на сегодняшний день может использоваться только в цепочках INPUT, FORWARD и OUTPUT (и во вложенных в них цепочках). Пока существует только единственный ключ, управляющий поведением команды REJECT.
Таблица 6-21. Действие REJECT
| Ключ | --reject-with |
| Пример | iptables -A FORWARD -p TCP --dport 22 -j REJECT --reject-with tcp-reset |
| Описание | Указывает, какое сообщение необходимо передать в ответ, если пакет совпал с заданным критерием. При применении действия REJECT к пакету, сначала на хост-отправитель будет отослан указанный ответ, а затем пакет будет "сброшен". Допускается использовать следующие типы ответов: icmp-net-unreachable, icmp-host-unreachable, icmp-port-unreachable, icmp-proto-unreachable, icmp-net-prohibited и icmp-host-prohibited. По-умолчанию передается сообщение port-unreachable. Все вышеуказанные типы ответов являются ICMP error messages. Дополнительную информацию по типам ICMP сообщений вы можете получить в приложении Типы ICMP. В заключение укажем еще один тип ответа - tcp-reset, который используется только для протокола TCP. Если указано значение tcp-reset, то действие REJECT передаст в ответ пакет TCP RST, пакеты TCP RST используются для закрытия TCP соединений. За дополнительной информацией обращайтесь к RFC 793 - Transmission Control Protocol. (Список типов ICMP ответов и их алиасов вы сможете получить введя команду iptables -j REJECT -h прим. перев.). |
Действие RETURN
Действие RETURN прекращает движение пакета по текущей цепочке правил и производит возврат в вызывающую цепочку, если текущая цепочка была вложенной, или, если текущая цепочка лежит на самом верхнем уровне (например INPUT), то к пакету будет применена политика по-умолчанию. Обычно, в качестве политики по-умолчанию назначают действия ACCEPT или DROP .
Для примера, допустим, что пакет идет по цепочке INPUT и встречает правило, которое производит переход во вложенную цепочку - --jump EXAMPLE_CHAIN. Далее, в цепочке EXAMPLE_CHAIN пакет встречает правило, которое выполняет действие --jump RETURN. Тогда произойдет возврат пакета в цепочку INPUT. Другой пример, пусть пакет встречает правило, которое выполняет действие --jump RETURN в цепочке INPUT. Тогда к пакету будет применена политика по-умолчанию цепочки INPUT.
Действие SNAT
SNAT используется для преобразования сетевых адресов (Source Network Address Translation), т.е. изменение исходящего IP адреса в IP заголовке пакета. Например, это действие можно использовать для предоставления выхода в Интернет другим компьютерам из локальной сети, имея лишь один уникальный IP адрес. Для этого. необходимо включить пересылку пакетов (forwarding) в ядре и затем создать правила, которые будут транслировать исходящие IP адреса нашей локальной сети в реальный внешний адрес. В результате, внешний мир ничего не будет знать о нашей локальной сети, он будет считать, что запросы пришли с нашего брандмауэра.
SNAT допускается выполнять только в таблице nat, в цепочке POSTROUTING. Другими словами, только здесь допускается преобразование исходящих адресов. Если первый пакет в соединении подвергся преобразованию исходящего адреса, то все последующие пакеты, из этого же соединения, будут преобразованы автоматически и не пойдут через эту цепочку правил.
Таблица 6-22. Действие SNAT
| Ключ | --to-source |
| Пример | iptables -t nat -A POSTROUTING -p tcp -o eth0 -j SNAT --to-source 194.236.50.155-194.236.50.160:1024-32000 |
| Описание | Ключ --to-source используется для указания адреса, присваемового пакету. Все просто, вы указываете IP адрес, который будет подставлен в заголовок пакета в качестве исходящего. Если вы собираетесь перераспределять нагрузку между несколькими брандмауэрами, то можно указать диапазон адресов, где начальный и конечный адреса диапазона разделяются дефисом, например: 194.236.50.155-194.236.50.160. Тогда, конкретный IP адрес будет выбираться из диапазона случайным образом для каждого нового потока. Дополнительно можно указать диапазон портов, которые будут использоваться только для нужд SNAT. Все исходящие порты будут после этого перекартироваться в заданный диапазон. iptables старается, по-возможности, избегать перекартирования портов, однако не всегда это возможно, и тогда производится перекартирование . Если диапазон портов не задан, то исходные порты ниже 512 перекартируются в диапазоне 0-511, порты в диапазоне 512-1023 перекартируются в диапазоне 512-1023, и, наконец порты из диапазона 1024-65535 перекартируются в диапазоне 1024-65535. Что касается портов назначения, то они не подвергаются перекартированию. |
Действие TOS
Команда TOS используется для установки битов в поле Type of Service IP заголовка. Поле TOS содержит 8 бит, которые используются для маршрутизации пакетов. Это один из нескольких полей, используемых iproute2. Так же важно помнить, что данное поле может обрабатываться различными маршрутизаторами с целью выбора маршрута движения пакета. Как уже указывалось выше, это поле, в отличие от MARK, сохраняет свое значение при движении по сети, а поэтому может использоваться вами для маршрутизации пакета. На сегодняшний день, большинство маршрутизаторов в Интернете никак не обрабатывают это поле, однако есть и такие, которые смотрят на него. Если вы используете это поле в своих нуждах, то подобные маршрутизаторы могут принять неверное решение при выборе маршрута, поэтому, лучше всего использовать это поле для своих нужд только в пределах вашей WAN или LAN.
|
Действие TOS воспринимает только предопределенные числовые значения и мнемоники, которые вы можете найти в linux/ip.h. Если вам действительно необходимо устанавливать произвольные значения в поле TOS, то можно воспользоваться "заплатой" FTOS с сайта Paksecured Linux Kernel patches, поддерживаемого Matthew G. Marsh. Однако, будьте крайне осторожны с этой "заплатой". Не следует использовать нестандартные значения TOS иначе как в особенных ситуациях. |
|
Данное действие допускается выполнять только в пределах таблицы mangle. |
|
В некоторых старых версиях iptables (1.2.2 и ниже) это действие реализовано с ошибкой (не исправляется контрольная сумма пакета), а это ведет к нарушению протокола обмена и в результате такие соединения обрываются. |
Команда TOS имеет только один ключ, который описан ниже.
Таблица 6-23. Действие TOS
| Ключ | --set-tos |
| Пример | iptables -t mangle -A PREROUTING -p TCP --dport 22 -j TOS --set-tos 0x10 |
| Описание | Ключ --set-tos определяет числовое значение в десятичном или шестнадцатиричном виде. Поскольку поле TOS является 8-битным, то вы можете указать число в диапазоне от 0 до 255 (0x00 - 0xFF). Однако, большинство значений этого поля никак не используются. Вполне возможно, что в будущих реализациях TCP/IP числовые значения могут быть изменены, поэтому, во-избежание ошибок, лучше использовать мнемонические обозначения: Minimize-Delay (16 или 0x10), Maximize-Throughput (8 или 0x08), Maximize-Reliability (4 или 0x04), Minimize-Cost (2 или 0x02) или Normal-Service (0 или 0x00). По-умолчанию большинство пакетов имеют признак Normal-Service, или 0. Список мнемоник вы сможете получить, выполнив команду iptables -j TOS -h. |
Действие TTL
Действие TTL используется для изменения содержимого поля Time To Live в IP заголовке. Один из вариантов применения этого действия - это устанавливать значение поля Time To Live ВО ВСЕХ исходящих пакетах в одно и то же значение. Для чего это?! Есть некоторые провайдеры, которые очень не любят, когда одним подключением пользуется несколько компьютеров, если мы начинаем устанавливать на все пакеты одно и то же значение TTL, то тем самым мы лишаем провайдера одного из критериев определения того, что подключение к Интернету разделяется несколькими компьютерами. Для примера можно привести число TTL = 64, которое является стандартным для ядра Linux.
За дополнительной информацией по установке значения по-умолчанию обращайтесь к ip-sysctl.txt, который вы найдете в приложении Ссылки на другие ресурсы.
Действие TTL можно указывать только в таблице mangle и нигде больше. Для данного действия предусмотрено 3 ключа, описываемых ниже.
Таблица 6-24. Действие TTL
| Ключ | --ttl-set |
| Пример | iptables -t mangle -A PREROUTING -i eth0 -j TTL --ttl-set 64 |
| Описание | Устанавливает поле TTL в заданное значение. Оптимальным считается значение около 64. Это не слишком много, но и не слишком мало Не задавайте слишком большое значение, это может иметь неприятные последствия для вашей сети. Представьте себе, что пакет "зацикливается" между двумя неправильно сконфигурированными роутерами, тогда, при больших значениях TTL, есть риск "потерять" значительную долю пропускной способности канала. |
| Ключ | --ttl-dec |
| Пример | iptables -t mangle -A PREROUTING -i eth0 -j TTL --ttl-dec 1 |
| Описание | Уменьшает значение поля TTL на заданное число. Например, пусть входящий пакет имеет значение TTL равное 53 и мы выполняем команду --ttl-dec 3, тогда пакет покинет наш хост с полем TTL равным 49. Не забывайте, что сетевой код автоматически уменьшит значение TTL на 1, поэтому, фактически мы получаем 53 - 3 - 1 = 49. |
| Ключ | --ttl-inc |
| Пример | iptables -t mangle -A PREROUTING -i eth0 -j TTL --ttl-inc 1 |
| Описание | Увеличивает значение поля TTL на заданное число. Возьмем предыдущий пример, пусть к нам поступает пакет с TTL = 53, тогда, после выполнения команды --ttl-inc 4, на выходе с нашего хоста, пакет будет иметь TTL = 56, не забывайте об автоматическом уменьшении поля TTL сетевым кодом ядра, т.е. фактически мы получаем выражение 53 + 4 - 1 = 56. Увеличение поля TTL может использоваться для того, чтобы сделать наш брандмауэр менее "заметным" для трассировщиков (traceroutes). Программы трассировки любят за ценную информацию при поиске проблемных участков сети, и ненавидят за это же, поскольку эта информация может использоваться крякерами в неблаговидных целях. Пример использования вы можете найти в сценарии Ttl-inc.txt. |
Действие ULOG
Действие ULOG предоставляет возможность журналирования пакетов в пользовательское пространство. Оно заменяет традиционное действие LOG, базирующееся на системном журнале. При использовании этого действия, пакет, через сокеты netlink, передается специальному демону который может выполнять очень детальное журналирование в различных форматах (обычный текстовый файл, база данных MySQL и пр.) и к тому же поддерживает возможность добавления надстроек (плагинов) для формирования различных выходных форматов и обработки сетевых протоколов. Пользовательскую часть ULOGD вы можете получить на домашней странице ULOGD project page.
Таблица 6-25. Действие ULOG
| Ключ | --ulog-nlgroup |
| Пример | iptables -A INPUT -p TCP --dport 22 -j ULOG --ulog-nlgroup 2 |
| Описание | Ключ --ulog-nlgroup сообщает ULOG в какую группу netlink должен быть передан пакет. Всего существует 32 группы (от 1 до 32). Если вы желаете передать пакет в 5-ю группу, то можно просто указать --ulog-nlgroup 5. По-умолчанию используется 1-я группа. |
| Ключ | --ulog-prefix |
| Пример | iptables -A INPUT -p TCP --dport 22 -j ULOG --ulog-prefix "SSH connection attempt: " |
| Описание | Ключ --ulog-prefix имеет тот же смысл, что и аналогичная опция в действии LOG. Длина строки префикса не должна превышать 32 символа. |
| Ключ | --ulog-cprange |
| Пример | iptables -A INPUT -p TCP --dport 22 -j ULOG --ulog-cprange 100 |
| Описание | Ключ --ulog-cprange определяет, какую долю пакета, в байтах, надо передавать демону ULOG. Если указать число 100, как показано в примере, то демону будет передано только 100 байт из пакета, это означает, что демону будет передан заголовок пакета и некоторая часть области данных пакета. Если указать 0, то будет передан весь пакет, независимо от его размера. Значение по-умолчанию равно 0. |
| Ключ | --ulog-qthreshold |
| Пример | iptables -A INPUT -p TCP --dport 22 -j ULOG --ulog-qthreshold 10 |
| Описание | Ключ --ulog-qthreshold устанавливает величину буфера в области ядра. Например, если задать величину буфера равной 10, как в примере, то ядро будет накапливать журналируемые пакеты во внутреннем буфере и передавать в пользовательское пространство группами по 10 пакетов. По-умолчанию размер буфера равен 1 из-за сохранения обратной совместимости с ранними версиями ulogd, которые не могли принимать группы пакетов. |
Действия и переходы
Действия и переходы сообщают правилу, что необходимо выполнить, если пакет соотвествует заданному критерию. Чаще всего употребляются действия 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, но так же продолжает продвижение по цепочке.
FUTURE REVISIONS OF THIS LICENSE
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.
Где взять iptables
Пакеты iptables могут быть загружены с домашней страницы . Кроме того, для работы iptables соответствующим образом должно быть сконфигурировано ядро вашей Linux-системы. Настройка ядра будет обсуждаться ниже.
Подготовка
Целью данной главы является оказание помощи в понимании той роли, которую netfilter и iptables играют в Linux сегодня. Так же она должна помочь вам установить и настроить межсетевой экран (firewall).
Порядок прохождения таблиц и цепочек
В этой главе мы рассмотрим порядок прохождения таблиц и цепочек в каждой таблице. Эта информация будет очень важна для вас позднее, когда вы начнете строить свои наборы правил, особенно когда в наборы правил будут включаться такие действия как DNAT, SNAT и конечно же TOS.
Механизм определения состояний
В данной главе все внимание будет уделено механизму определения состояний пакетов (state machine). По прочтении ее у вас должно сложиться достаточно четкое представление о работе механизма, а способствовать этому должен значительный объем поясняющих примеров.
Сохранение и восстановление больших наборов правил
В состав пакета iptables входят две очень удобные утилиты, особенно если вам приходится иметь дело с большими наборами правил. Называются они iptables-save и iptables-restore. Первая из них сохраняет, а вторая восстанавливает наборы правил в/из файла. По своему формату файл с набором правил похож на обычные файлы сценариев командной оболочки (shell), в чем вы сможете убедиться чуть ниже.
Как строить правила
В данной главе будет обсуждаться порядок построения собственных правил для iptables. Каждая строка, которую вы вставляете в ту или иную цепочку, должна содержать отдельное правило. Мы так же обсудим основные критерии и действия (targets) и порядок создания своих собственных действий (т.е. подцепочек правил).
Файл rc.firewall
В этой главе мы рассмотрим настройку брандмауэра на примере сценария rc.firewall.txt. Мы будем брать каждую базовую настройку и рассматривать как она работает и что делает. Это может натолкнуть вас на решение ваших собственных задач. Для запуска этого сценария вам потребуется внести в него изменения таким образом, чтобы он мог работать с вашей конфигурацией сети, в большинстве случаев достаточно изменить только переменные.
|
Примечательно, что есть более эффективные способы задания наборов правил, однако я исходил из мысли о большей удобочитаемости сценария, так, чтобы каждый смог понять его без глубоких познаний оболочки BASH. |
Примеры сценариев
Цель этой главы состоит в том, чтобы дать краткое описание каждого сценария, в этом руководстве. Эти сценарии не совершенны, и они не могут полностью соответствовать вашим нуждам. Это означает, что вы должны сами "подогнать" эти сценарии под себя. Последующая часть руководства призвана облегчить вам эту подгонку.
How to Apply These Terms to Your New Programs
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.
How to use this License for your documents
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.
I.1. Пример rc.firewall
#!/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 #
I.2. Пример rc.DMZ.firewall
#!/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 #
I.3. Пример rc.UTIN.firewall
#!/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 #
I.4. Пример rc.DHCP.firewall
#!/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 #
I.5. Пример rc.flush-iptables
#!/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
I.6. Пример rc.test-iptables
#!/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:"
И минусы
У вас может сложиться впечатление, что iptables-restore может обрабатывать своего рода сценарии. Пока не может и вероятнее всего -- никогда не сможет. В этом и состоит главный недостаток iptables-restore. Чтобы было более понятно -- представьте себе случай, когда брандмауэр получает динамический IP-адрес и вы хотите вставить его значение в свои правила во время загрузки системы. Решить эту проблему с помощью iptables-restore практически невозможно.
Как одно из решений можно предложить написать небольшой скрипт, который определяет значение IP-адреса и затем вставляет его в набор правил (например, с помощью sed) на место некоторого ключевого слова. Здесь вам потребуется создать временный файл, в котором производятся изменения и который затем загружается с помощью iptables-restore. Однако такой вариант решения порождает свои проблемы -- вам придется отказаться от утилиты iptables-save поскольку она может затереть, созданную вручную, заготовку файла с правилами для iptables-restore. Вобщем -- довольно неуклюжее решение.
Еще один вариант -- хранить в файле для iptables-restore только статические правила, а затем с помощью небольшого скрипта добавлять правила с динамическими параметрами. Конечно же вы уже поняли, что это решение такое же неуклюжее как и первое. Вам придется смириться с тем, что iptables-restore не очень хорошо подходит для случая с динамически назначаемым IP-адресом и вообще для случаев, когда вам потребуется динамически изменять набор правил в зависимости от конфигурации системы и т.п..
Еще один недостаток iptables-restore и iptables-save в том, что их функциональность не всегда соответствует описанной. Проблема состоит в том, что не многие пользуются этими утилитами, еще меньше людей вовлечено в процесс поиска ошибок в этих программах. Поэтому, при использовании некоторых, вновь появившихся, критериев или действий вы можете столкнуться с неожиданным поведением своих правил. Несмотря на возможное существование некоторых проблем, я все же настоятельно рекомендую к использованию эти два инструмента, которые прекрасно работают в большинстве случаев, исключение могут составлять лишь некоторые новые критерии и действия.
ICMP соединения
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 используется для передачи сообщений о том, что происходит с тем или иным 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 и передает клиенту. После чего запись в таблице трассировщика уничтожается, а клиент благополучно обрывает соединение.
Iptables-restore
Утилита 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-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-save ruleset
Небольшой пример iptsave-saved.txt,, о котором говорилось в главе Сохранение и восстановление больших наборов правил, иллюстрирующий работу команды iptables-save. Не является исполняемым сценарием и предназначен лишь для демонстрации результата работы iptables-save.
Последнюю версию документа можно получить
Перевод:
Последнюю версию документа можно получить по адресу: http://iptables-tutorial.frozentux.net/ .
Допускается копирование и/или модификация данного документа или его части, в соответствии с соглашениями, принятыми в GNU Free Documentation License, версии 1.1. Неизменяемыми разделами являются раздел "Введение" и все подразделы этого раздела, а так же разделы, начинающиеся словами "Original Author: Oskar Andreasson", Копия GNU Free Documentation License включена в данный документ и находится в секции "GNU Free Documentation License".
Все сценарии в данном руководстве подпадают под действие GNU General Public License. Они являются свободно распространяемыми и могут копироваться и/или модифицироваться в соответствии с условиями GNU General Public License версии 2.
Сценарии распространяются в надежде на то, что они будут полезны вам, но БЕЗ КАКИХ ЛИБО ГАРАНТИЙ. За дополнительной информацией обращайтесь к тексту GNU General Public License.
С данным документом должна распространяться копия GNU General Public License, в секции "GNU General Public License"; в случае ее отсутствия вы можете написать по адресу Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
Содержание Посвящения
Об авторе Как читать этот документ Предварительные условия Типографские соглашения 1. Введение
1.1. Почему было написано данное руководство 1.2. Как он был написан 1.3. Термины, используемые в данном документе
2. Подготовка
2.1. Где взять iptables 2.2. Настройка ядра 2.3. Установка пакета
2.3.1. Сборка пакета 2.3.2. Установка в Red Hat 7.1
3. Порядок прохождения таблиц и цепочек
3.1. Общие положения 3.2. Таблица Mangle 3.3. Таблица Nat 3.4. Таблица Filter
4. Механизм определения состояний
4.1. Введение
4.2. Таблица трассировщика 4.3. Состояния в пространстве пользователя 4.4. TCP соединения 4.5. UDP соединения 4.6. ICMP соединения 4.7. Поведение по-умолчанию 4.8. Трассировка комплексных протоколов
5. Сохранение и восстановление больших наборов правил
5.1. Плюсы
5.2. И минусы 5.3. iptables-save
5.4. iptables-restore
6. Как строить правила
6.1. Основы
6.2. Таблицы
6.3. Команды
6.4. Критерии
6.4.1. Общие критерии 6.4.2. Неявные критерии 6.4.3. Явные критерии 6.4.4. Критерий "мусора" (Unclean match)
6.5. Действия и переходы
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
7. Файл rc.firewall
7.1. Пример rc.firewall 7.2. Описание сценария rc.firewall
7.2.1. Конфигурация
7.2.2. Загрузка дополнительных модулей 7.2.3. Настройка /proc 7.2.4. Размещение правил по разным цепочкам 7.2.5. Установка политик по-умолчанию 7.2.6. Создание пользовательских цепочек в таблице filter 7.2.7. Цепочка INPUT 7.2.8. Цепочка FORWARD 7.2.9. Цепочка OUTPUT 7.2.10. Цепочка PREROUTING таблицы nat 7.2.11. Запуск SNAT и цепочка POSTROUTING
8. Примеры сценариев
8.1. Структура файла rc.firewall.txt
8.1.1. Структура
8.2. rc.firewall.txt
8.3. rc.DMZ.firewall.txt
8.4. rc.DHCP.firewall.txt
8.5. rc.UTIN.firewall.txt
8.6. rc.test-iptables.txt
8.7. rc.flush-iptables.txt
8.8. Limit-match.txt
8.9. Pid-owner.txt
8.10. Sid-owner.txt
8.11. Ttl-inc.txt
8.12. Iptables-save ruleset
A. Детальное описание специальных команд
A.1. Вывод списка правил A.2. Изменение и очистка ваших таблиц
B. Общие проблемы и вопросы
B.1. Проблемы загрузки модулей B.2. Пакеты со статусом NEW и со сброшенным битом SYN B.3. SYN/ACK - пакеты и пакеты со статусом NEW B.4. Поставщики услуг Internet, использующие зарезервированные IP-адреса B.5. Как разрешить прохождение DHCP запросов через iptables B.6. Проблемы mIRC DCC
C. Типы ICMP D. Ссылки на другие ресурсы E. Благодарности
F. Хронология
G. GNU Free Documentation License
0. PREAMBLE
1. APPLICABILITY AND DEFINITIONS 2. VERBATIM COPYING 3. COPYING IN QUANTITY 4. MODIFICATIONS
5. COMBINING DOCUMENTS 6. COLLECTIONS OF DOCUMENTS 7. AGGREGATION WITH INDEPENDENT WORKS 8. TRANSLATION
9. TERMINATION
10. FUTURE REVISIONS OF THIS LICENSE How to use this License for your documents
H. GNU General Public License
0. Preamble
1. TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION 2. How to Apply These Terms to Your New Programs
I. Примеры сценариев
I.1. Пример rc.firewall I.2. Пример rc.DMZ.firewall I.3. Пример rc.UTIN.firewall I.4. Пример rc.DHCP.firewall I.5. Пример rc.flush-iptables I.6. Пример rc.test-iptables
Перечень таблиц 3-1. Порядок движения транзитных пакетов 3-2. Для локального приложения 3-3. От локальных процессов 4-1. Перечень состояний в пространстве пользователя 4-2. Internal states 6-1. Таблицы
6-2. Команды
6-3. Дополнительные ключи 6-4. Общие критерии 6-5. TCP критерии 6-6. UDP критерии 6-7. ICMP критерии 6-8. Ключи критерия limit 6-9. Ключи критерия MAC 6-10. Ключи критерия Mark 6-11. Ключи критерия Multiport 6-12. Ключи критерия Owner 6-13. Ключи критерия State 6-14. Ключи критерия TOS 6-15. Ключи критерия TTL 6-16. Действие DNAT 6-17. Ключи действия LOG 6-18. Ключи действия MARK 6-19. Действие MASQUERADE 6-20. Действие REDIRECT 6-21. Действие REJECT 6-22. Действие SNAT 6-23. Действие TOS 6-24. Действие TTL 6-25. Действие ULOG C-1. ICMP types
Явные критерии
Перед использованием этих расширений, они должны быть загружены явно, с помощью ключа -m или --match. Так, например, если мы собираемся использовать критерии state, то мы должны явно указать это в строке правила: -m state левее используемого критерия. Некоторые из этих критериев пока еще находятся в стадии разработки, а посему могут работать не всегда, однако, в большинстве случаев, они работают вполне устойчиво. Все отличие между явными и неявными критериями заключается только в том, что первые нужно подгружать явно, а вторые подгружаются автоматически.
6.4.3.1. Критерий Limit
Должен подгружаться явно ключом -m limit. Прекрасно подходит для правил, производящих запись в системный журнал (logging) и т.п. Добавляя этот критерий, мы тем самым устанавливаем предельное число пакетов в единицу времени, которое способно пропустить правило. Можно использовать символ ! для инверсии, например -m limit ! --limit 5/s. В этом случае подразумевается, что пакеты будут проходить правило только после превышения ограничения.
Более наглядно этот критерий можно представить себе как некоторую емкость с выпускным отверстием, через которое проходит определенное число пакетов за единицу времени (т.е. скорость "вытекания"). Скорость "вытекания" как раз и определяет величина --limit. Величина --limit-burst задает общий "объем емкости". А теперь представим себе правило --limit 3/minute --limit-burst 5, тогда после поступления 5 пакетов (за очень короткий промежуток времени), емкость "наполнится" и каждый последующий пакет будет вызывать "переполнение" емкости, т.е. "срабатывание" критерия. Через 20 секунд "уровень" в емкости будет понижен (в соответствии с величиной --limit), таким образом она готова будет принять еще один пакет, не вызывая "переполнения" емкости, т.е. срабатывания критерия.
Рассмотрим еще подробнее.
Предположим наличие правила, содержащего критерий -m limit --limit 5/second --limit-burst 10. Ключ limit-burst установил объем "емкости" равный 10-ти. Каждый пакет, который подпадает под указанное правило, направляется в эту емкость.
Допустим, в течение 1/ 1000 секунды, мы получили 10 пакетов, тогда с получением каждого пакета "уровень" в "емкости" будет возрастать: 1-2-3-4-5-6-7-8-9-10.
Емкость наполнилась. Теперь пакеты, подпадающие под наше ограничительное правило, больше не смогут попасть в эту "емкость" (там просто нет места), поэтому они (пакеты) пойдут дальше по набору правил, пока не будут явно восприняты одним из них, либо подвергнутся политике по-умолчанию.
Каждые 1/5 секунды "уровень" в воображаемой емкости снижается на 1, и так до тех пор, пока "емкость" не будет опустошена. Через секунду, после приема 10-ти пакетов "емкость" готова будет принять еще 5 пакетов.
Само собой разумеется, что "уровень" в "емкости" возрастает на 1 с каждым вновь пришедшим пакетом.
От переводчика: Очень долгое время мое понимание критериев limit находилось на интуитивном уровне, пока (снимаю шляпу в глубочайшем поклоне) не объяснил мне просто и понятно его суть. Постараюсь передать его пояснения:
Расширение -m limit подразумевает наличие ключей --limit и --limit-burst. Если вы не указываете эти ключи, то они принимают значение по-умолчанию.
Ключ --limit-burst - это максимальное значение счетчика пакетов, при котором срабатывает ограничение.
Ключ --limit - это скорость, с которой счетчик burst limit "откручивается назад".
Принцип, который просто реализуется на C и широко используется во многих алгоритмах-ограничителях.
Таблица 6-8. Ключи критерия limit
| Ключ | --limit |
| Пример | iptables -A INPUT -m limit --limit 3/hour |
| Описание | Устанавливается средняя скорость "освобождения емкости" за единицу времени. В качестве аргумента указывается число пакетов и время. Допустимыми считаются следующие единицы измерения времени: /second /minute /hour /day. По умолчанию принято значение 3 пакета в час, или 3/hour. Использование флага инверсии условия ! в данном критерии недопустим. |
| Ключ | --limit-burst |
| Пример | iptables -A INPUT -m limit --limit-burst 5 |
| Описание | Устанавливает максимальное значение числа burst limit для критерия limit. Это число увеличивается на единицу если получен пакет, подпадающий под действие данного правила, и при этом средняя скорость (задаваемая ключом --limit) поступления пакетов уже достигнута. Так происходит до тех пор, пока число burst limit не достигнет максимального значения, устанавливаемого ключом --limit-burst. После этого правило начинает пропускать пакеты со скоростью, задаваемой ключом --limit. Значение по-умолчанию принимается равным 5. Для демонстрации принципов работы данного критерия я написал сценарий Limit-match.txt С помощью этого сценария вы увидите как работает критерий limit, просто посылая ping-пакеты с различными временнЫми интервалами. |
6.4.3.2. Критерий MAC
MAC ( Ethernet Media Access Control) критерий используется для проверки исходного MAC-адреса пакета. Расширение -m mac, на сегодняшний день, предоставляет единственный критерий, но возможно в будущем он будет расширен и станет более полезен.
|
Модуль расширения должен подгружаться явно ключом -m mac. Упоминаю я об этом потому, что многие, забыв указать этот ключ, удивляются, почему не работает этот критерий. |
| Ключ | --mac-source |
| Пример | iptables -A INPUT -m mac --mac-source 00:00:00:00:00:01 |
| Описание | MAC адрес сетевого узла, передавшего пакет. MAC адрес должен указываться в форме XX:XX:XX:XX:XX:XX. Как и ранее, символ ! используется для инверсии критерия, например --mac-source ! 00:00:00:00:00:01, что означает - "пакет с любого узла, кроме узла, который имеет MAC адрес 00:00:00:00:00:01" . Этот критерий имеет смысл только в цепочках PREROUTING, FORWARD и INPUT и нигде более. |
Критерий mark предоставляет возможность "пометить" пакеты специальным образом. Mark - специальное поле, которое существует только в области памяти ядра и связано с конкретным пакетом. Может использоваться в самых разнообразных целях, например, ограничение трафика и фильтрация. На сегодняшний день существует единственная возможность установки метки на пакет в Linux -- это использование действия MARK. Поле mark представляет собой беззнаковое целое число в диапазоне от 0 до 4294967296 для 32-битных систем.
Таблица 6-10. Ключи критерия Mark
| Ключ | --mark |
| Пример | iptables -t mangle -A INPUT -m mark --mark 1 |
| Описание | Критерий производит проверку пакетов, которые были предварительно "помечены". Метки устанавливаются действием MARK, которое мы будем рассматривать ниже. Все пакеты, проходящие через netfilter имеют специальное поле mark. Запомните, что нет никакой возможности передать состояние этого поля вместе с пакетом в сеть. Поле mark является целым беззнаковым, таким образом можно создать не более 4294967296 различных меток. Допускается использовать маску с меткам. В данном случае критерий будет выглядеть подобным образом: --mark 1/1. Если указывается маска, то выполняется логическое AND метки и маски. |
6.4.3.4. Критерий Multiport
Расширение multiport позволяет указывать в тексте правила несколько портов и диапазонов портов.
|
Вы не сможете использовать стандартную проверку портов и расширение -m multiport (например --sport 1024:63353 -m multiport --dport 21,23,80) одновременно. Подобные правила будут просто отвергаться iptables. |
| Ключ | --source-port |
| Пример | iptables -A INPUT -p tcp -m multiport --source-port 22,53,80,110 |
| Описание | Служит для указания списка исходящих портов. С помощью данного критерия можно указать до 15 различных портов. Названия портов в списке должны отделяться друг от друга запятыми, пробелы в списке не допустимы. Данное расширение может использоваться только совместно с критериями -p tcp или -p udp. Главным образом используется как расширенная версия обычного критерия --source-port. |
| Ключ | --destination-port |
| Пример | iptables -A INPUT -p tcp -m multiport --destination-port 22,53,80,110 |
| Описание | Служит для указания списка входных портов. Формат задания аргументов полностью аналогичен -m multiport --source-port. |
| Ключ | --port |
| Пример | iptables -A INPUT -p tcp -m multiport --port 22,53,80,110 |
| Описание | Данный критерий проверяет как исходящий так и входящий порт пакета. Формат аргументов аналогичен критерию --source-port и --destination-port. Обратите внимание на то что данный критерий проверяет порты обеих направлений, т.е. если вы пишете -m multiport --port 80, то под данный критерий подпадают пакеты, идущие с порта 80 на порт 80. |
Расширение owner предназначено для проверки "владельца" пакета. Изначально данное расширение было написано как пример демонстрации возможностей iptables. Допускается использовать этот критерий только в цепочке OUTPUT. Такое ограничение наложено потому, что на сегодняшний день нет реального механизма передачи информации о "владельце" по сети. Справедливости ради следует отметить, что для некоторых пакетов невозможно определить "владельца" в этой цепочке. К такого рода пакетам относятся различные ICMP responses. Поэтому не следует применять этот критерий к ICMP responses пакетам.
Таблица 6-12. Ключи критерия Owner
| Ключ | --uid-owner |
| Пример | iptables -A OUTPUT -m owner --uid-owner 500 |
| Описание | Производится проверка "владельца" по User ID (UID). Подобного рода проверка может использоваться, к примеру, для блокировки выхода в Интернет отдельных пользователей. |
| Ключ | --gid-owner |
| Пример | iptables -A OUTPUT -m owner --gid-owner 0 |
| Описание | Производится проверка "владельца" пакета по Group ID (GID). |
| Ключ | --pid-owner |
| Пример | iptables -A OUTPUT -m owner --pid-owner 78 |
| Описание | Производится проверка "владельца" пакета по Process ID (PID). Этот критерий достаточно сложен в использовании, например, если мы хотим позволить передачу пакетов на HTTP порт только от заданного демона, то нам потребуется написать небольшой сценарий, который получает PID процесса (хотя бы через ps) и затем подставляет найденный PID в правила. Пример использования критерия можно найти в Pid-owner.txt. |
| Ключ | --sid-owner |
| Пример | iptables -A OUTPUT -m owner --sid-owner 100 |
| Описание | Производится проверка Session ID пакета. Значение SID наследуются дочерними процессами от "родителя", так, например, все процессы HTTPD имеют один и тот же SID (примером таких процессов могут служить HTTPD Apache и Roxen). Пример использования этого критерия можно найти в Sid-owner.txt. Этот сценарий можно запускать по времени для проверки наличия процесса HTTPD, и в случае отсутствия - перезапустить "упавший" процесс, после чего сбросить содержимое цепочки OUTPUT и ввести ее снова. |
Критерий state используется совместно с кодом трассировки соединений и позволяет нам получать информацию о признаке состояния соединения, что позволяет судить о состоянии соединения, причем даже для таких протоколов как ICMP и UDP. Данное расширение необходимо загружать явно, с помощью ключа -m state. Более подробно механизм определения состояния соединения обсуждается в разделе Механизм определения состояний .
Таблица 6-13. Ключи критерия State
| Ключ | --state |
| Пример | iptables -A INPUT -m state --state RELATED,ESTABLISHED |
| Описание | Проверяется признак состояния соединения (state) На сегодняшний день можно указывать 4 состояния: INVALID, ESTABLISHED, NEW и RELATED. INVALID подразумевает, что пакет связан с неизвестным потоком или соединением и, возможно содержит ошибку в данных или в заголовке. Состояние ESTABLISHED указывает на то, что пакет принадлежит уже установленному соединению через которое пакеты идут в обеих направлениях. Признак NEW подразумевает, что пакет открывает новое соединение или пакет принадлежит однонаправленному потоку. И наконец, признак RELATED указывает на то что пакет принадлежит уже существующему соединению, но при этом он открывает новое соединение Примером тому может служить передача данных по FTP, или выдача сообщения ICMP об ошибке, которое связано с существующим TCP или UDP соединением. Замечу, что признак NEW это не то же самое, что установленный бит SYN в пакетах TCP, посредством которых открывается новое соединение, и, подобного рода пакеты, могут быть потенциально опасны в случае, когда для защиты сети вы используете один сетевой экран. Более подробно эта проблема рассматривается ниже в главе Механизм определения состояний. |
Критерий TOS предназначен для проведения проверки битов поля TOS. TOS -- Type Of Service -- представляет собой 8-ми битовое, поле в заголовке IP-пакета. Модуль должен загружаться явно, ключом -m tos.
От переводчика: Далее приводится описание поля TOS, взятое не из оригинала, поскольку оригинальное описание я нахожу несколько туманным.
Данное поле служит для нужд маршрутизации пакета. Установка любого бита может привести к тому, что пакет будет обработан маршрутизатором не так как пакет со сброшенными битами TOS. Каждый бит поля TOS имеет свое значение. В пакете может быть установлен только один из битов этого поля, поэтому комбинации не допустимы. Каждый бит определяет тип сетевой службы:
Минимальная задержка Используется в ситуациях, когда время передачи пакета должно быть минимальным, т.е., если есть возможность, то маршрутизатор для такого пакета будет выбирать более скоростной канал. Например, если есть выбор между оптоволоконной линией и спутниковым каналом, то предпочтение будет отдано более скоростному оптоволокну.
Максимальная пропускная способность Указывает, что пакет должен быть переправлен через канал с максимальной пропускной способностью. Например спутниковые каналы, обладая большей задержкой имеют высокую пропускную способность.
Максимальная надежность Выбирается максимально надежный маршрут во избежание необходимости повторной передачи пакета. Примером могут служить PPP и SLIP соединения, которые по своей надежности уступают, к примеру, сетям X.25, поэтому, сетевой провайдер может предусмотреть специальный маршрут с повышенной надежностью.
Минимальные затраты Применяется в случаях, когда важно минимизировать затраты (в смысле деньги) на передачу данных. Например, при передаче через океан (на другой континент) аренда спутникового канала может оказаться дешевле, чем аренда оптоволоконного кабеля. Установка данного бита вполне может привести к тому, что пакет пойдет по более "дешевому" маршруту.
Обычный сервис В данной ситуации все биты поля TOS сброшены. Маршрутизация такого пакета полностью отдается на усмотрение провайдера.
Таблица 6-14. Ключи критерия TOS
| Ключ | --tos |
| Пример | iptables -A INPUT -p tcp -m tos --tos 0x16 |
| Описание | Данный критерий предназначен для проверки установленных битов TOS, которые описывались выше. Как правило поле используется для нужд маршрутизации, но вполне может быть использовано с целью "маркировки" пакетов для использования с iproute2 и дополнительной маршрутизации в linux. В качестве аргумента критерию может быть передано десятичное или шестнадцатиричное число, или мнемоническое описание бита, мнемоники и их числовое значение вы можете получить выполнив команду iptables -m tos -h. Ниже приводятся мнемоники и их значения. Minimize-Delay 16 (0x10) (Минимальная задержка), Maximize-Throughput 8 (0x08) (Максимальная пропускная способность), Maximize-Reliability 4 (0x04) (Максимальная надежность), Minimize-Cost 2 (0x02) (Минимальные затраты), Normal-Service 0 (0x00) (Обычный сервис) |
TTL (Time To Live) является числовым полем в IP заголовке. При прохождении очередного маршрутизатора, это число уменьшается на 1. Если число становится равным нулю, то отправителю пакета будет передано ICMP сообщение типа 11 с кодом 0 (TTL equals 0 during transit) или с кодом 1 (TTL equals 0 during reassembly) . Для использования этого критерия необходимо явно загружать модуль ключом -m ttl.
От переводчика: Опять обнаружилось некоторое несоответствие оригинального текста с действительностью, по крайней мере для iptables 1.2.6a, о которой собственно и идет речь, существует три различных критерия проверки поля TTL, это -m ttl --ttl-eq число, -m ttl --ttl-lt число и -m ttl --ttl-gt число. Назначение этих критериев понятно уже из их синтаксиса. Тем не менее, я все таки приведу перевод оригинала:
Таблица 6-15. Ключи критерия TTL
| Ключ | --ttl |
| Пример | iptables -A OUTPUT -m ttl --ttl 60 |
| Описание | Производит проверку поля TTL на равенство заданному значению. Данный критерий может быть использован при наладке локальной сети, например: для случаев, когда какая либо машина локальной сети не может подключиться к серверу в Интернете, или для поиска "троянов" и пр. Вобщем, области применения этого поля ограничиваются только вашей фантазией. Еще один пример: использование этого критерия может быть направлено на поиск машин с некачественной реализацией стека TCP/IP или с ошибками в конфигурации ОС. |
Как читать этот документ
Этот документ написан, так чтобы облегчить читателям понимание замечательного мира iptables. Здесь вы не найдете информации об ошибках в iptables или в netfilter. Если вы столкнетесь с ними, то можете связяться с командой разработчиков, а они в ответ могут сообщить вам, действительно ли существует такая ошибка. На сегодняшний день iptables и netfilter практически не содержат ошибок, хотя изредка одна - две "проскакивают". Информация о таких ошибках обязательно появляется на .
Вышесказанное также означает, что при написании наборов правил, прилагаемых к данному руководству, не учитывалось возможное наличие каких-либо ошибок внутри netfilter. Основная цель примеров - показать порядок написания набора правил и проблемы, с которыми вы можете столкнуться. Например, в этом документе не поясняется, как закрыть уязвимость Apache 1.2.12 на HTTP порту (фактически в примерах вы найдете, как закрыть этот порт, но по другой причине).
Этот документ был написан с целью дать начинающим хороший, простой и в то же время достаточно полный учебник по iptables. Он не содержит информации по действиям и критериям из patch-o-matic по той простой причине, что потребовалось бы слишком много усилий, чтобы запомнить весь список изменений. Если у вас возникнет необходимость в получении информации по модификациям patch-o-matic, то вам следует обращаться к документации, которая сопровождает конкретный patch-o-matic, она доступна на .
Как он был написан
Я консультировался с Марком Бучером (Marc Boucher) и другими членами команды разработчиков netfilter. Пользуясь случаем, выражаю огромную признательность за их помощь в создании данного руководства, которое изначально было написано для boingworld.com, а теперь доступно на моем персональном сайте frozentux.net. С помощью этого документа вы пройдете процесс настройки шаг за шагом и, надеюсь, что к концу изучения его вы будете знать о пакете iptables значительно больше. Большая часть материала базируется на файле rc.firewall.txt, так как я считаю, что рассмотрение примера -- лучший способ изучения iptables. Я пройду по основным цепочкам правил в порядке их следования. Это несколько усложняет изучение, зато изложение становится логичнее. И, всякий раз, когда у вас возникнут затруднения, вы можете обращаться к этому руководству.
Команды
Ниже приводится список команд и правила их использования. Посредством команд мы сообщаем 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). Этот ключ может использоваться с любой командой. |
Конфигурация
Первая часть файла rc.firewall.txt является конфигурационным разделом. Здесь задаются основные настройки брандмауэра, которые зависят от вашей конфигурации сети. Например IP адреса - наверняка должны быть изменены на ваши собственные. Переменная $INET_IP должна содержать реальный IP адрес, если вы подключаетесь к Интернет через DHCP, то вам следует обратить внимание на скрипт rc.DHCP.firewall.txt, Аналогично $INET_IFACE должна указывать ваше устройство, через которое осуществляется подключение к Интернет. Это может быть, к примеру, eth0, eth1, ppp0, tr0 и пр.
Этот сценарий не содержит каких либо настроек, специфичных для DHCP, PPPoE, поэтому эти разделы не заполнены. То же самое касается и других "пустых" разделов. Это сделано преднамеренно, чтобы вы могли более наглядно видеть разницу между сценариями. Если вам потребуется заполнить эти разделы, то вы можете взять их из других скриптов, или написать свой собственный.
Раздел Local Area Network должен содержать настройки, соответствующие конфигурации вашей локальной сети. Вы должны указать локальный IP адрес брандмауэра, интерфейс, подключенный к локальной сети, маску подсети и широковещательный адрес.
Далее следует секция Localhost Configuration, которую изменять вам едва ли придется. В этой секции указывается локальный интерфейс lo и локальный IP адрес 127.0.0.1. За разделом Localhost Configuration, следует секция Iptables Configuration. Здесь создается переменная $IPTABLES, содержащая путь к файлу iptables (обычно /usr/local/sbin/iptables). Если вы устанавливали iptables из исходных модулей, то у вас путь к iptables может несколько отличаться от приведенного в сценарии (например /usr/sbin/iptables), однако в большинстве дистрибутивов iptables расположена именно здесь.
Критерии
Здесь мы подробнее остановимся на критериях выделения пакетов. Я разбил все критерии на пять групп. Первая -- общие критерии которые могут использоваться в любых правилах. Вторая - TCP критерии которые применяются только к TCP пакетам. Третья -- UDP критерии которые применяются только к UDP пакетам. Четвертая -- ICMP критерии для работы с ICMP пакетами. И наконец пятая -- специальные критерии, такие как state, owner, limit и пр.
Критерий "мусора" (Unclean match)
Критерий unclean не имеет дополнительных ключей и для его использования достаточно явно загрузить модуль. Будьте осторожны, данный модуль находится еще на стадии разработки и поэтому в некоторых ситуациях может работать некорректно. Данная проверка производится для вычленения пакетов, которые имеют расхождения с принятыми стандартами, это могут быть пакеты с поврежденным заголовком или с неверной контрольной суммой и пр., однако использование этой проверки может привести к разрыву и вполне корректного соединения.
Limit-match.txt
Сценарий limit-match.txt написан с целью продемонстрировать работу с критерием limit. Запустите этот скрипт и попробуйте отправлять на этот хост ping-пакеты с различными интервалами.
MODIFICATIONS
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.
