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

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

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

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

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

      Это полный список типов ICMP сообщений:
       Таблица C-1. ICMP types
      (Тип – Код – Описание – Запрос – Ошибка)
 
       Тип: 0
       Код: 0
       Описание: Echo Reply
       Запрос: x
       Ошибка: -
 
       Тип: 3
       Код: 0
       Описание: Network Unreachable
       Запрос: -
       Ошибка: x
 
       Тип: 3
       Код: 1
       Описание: Host Unreachable
       Запрос: -
       Ошибка: x
 
       Тип: 3
       Код: 2
       Описание: Protocol Unreachable
       Запрос: -
       Ошибка: x
 
       Тип: 3
       Код: 3
       Описание: Port Unreachable
       Запрос: -
       Ошибка: x
 
       Тип: 3
       Код: 4
       Описание: Fragmentation needed but no frag. bit set
       Запрос: -
       Ошибка: x
 
       Тип: 3
       Код: 5
       Описание: Source routing failed
       Запрос: -
       Ошибка: x
 
       Тип: 3
       Код: 6
       Описание: Destination network unknown
       Запрос: -
       Ошибка: x
 
       Тип: 3
       Код: 7
       Описание: Destination host unknown
       Запрос: -
       Ошибка: x
 
       Тип: 3
       Код: 8
       Описание: Source host (isolated obsolete)
       Запрос: -
       Ошибка: x
 
       Тип: 3
       Код: 9
       Описание: Destination network administratively prohibited
       Запрос: -
       Ошибка: x
 
       Тип: 3
       Код: 10
       Описание: Destination host administratively prohibited
       Запрос: -
       Ошибка: x
 
       Тип: 3
       Код: 11
       Описание: Network unreachable for TOS
       Запрос: -
       Ошибка: x
 
       Тип: 3
       Код: 12
       Описание: Host unreachable for TOS
       Запрос: -
       Ошибка: x
 
       Тип: 3
       Код: 13
       Описание: Communication administratively prohibited by filtering
       Запрос: -
       Ошибка: x
 
       Тип: 3
       Код: 14
       Описание: Host precedence violation
       Запрос: -
       Ошибка: x
 
       Тип: 3
       Код: 15
       Описание: Precedence cutoff in effect
       Запрос: -
       Ошибка: x
 
       Тип: 4
       Код: 0
       Описание: Source quench
       Запрос: -
       Ошибка: -
 
       Тип: 5
       Код: 0
       Описание: Redirect for network
       Запрос: -
       Ошибка: -
 
       Тип: 5
       Код: 1
       Описание: Redirect for host
       Запрос: -
       Ошибка: -
 
       Тип: 5
       Код: 2
       Описание: Redirect for TOS and network
       Запрос: -
       Ошибка: -
 
       Тип: 5
       Код: 3
       Описание: Redirect for TOS and host
       Запрос: -
       Ошибка: -
 
       Тип: 8
       Код: 0
       Описание: Echo request
       Запрос: x
       Ошибка: -
 
       Тип: 9
       Код: 0
       Описание: Router advertisement
       Запрос: -
       Ошибка: -
 
       Тип: 10
       Код: 0
       Описание: Route solicitation
       Запрос: -
       Ошибка: -
 
       Тип: 11
       Код: 0
       Описание: TTL equals 0 during transit
       Запрос: -
       Ошибка: x
 
       Тип: 11
       Код: 1
       Описание: TTL equals 0 during reassembly
       Запрос: -
       Ошибка: x
 
       Тип: 12
       Код: 0
       Описание: IP header bad (catchall error)
       Запрос: -
       Ошибка: x
 
       Тип: 12
       Код: 1
       Описание: Required options missing
       Запрос: -
       Ошибка: x
 
       Тип: 13
       Код: 0
       Описание: Timestamp request (obsolete)
       Запрос: x
       Ошибка: -
 
       Тип: 14
       Код: 0
       Описание: Timestamp reply (obsolete)
       Запрос: x
       Ошибка: -
 
       Тип: 15
       Код: 0
       Описание: Information request (obsolete)
       Запрос: x
       Ошибка: -
 
       Тип: 16
       Код: 0
       Описание: Information reply (obsolete)
       Запрос: x
       Ошибка: -
 
       Тип: 17
       Код: 0
       Описание: Address mask request
       Запрос: x
       Ошибка: -
 
       Тип: 18
       Код: 0
       Описание: Address mask reply
       Запрос: x
       Ошибка: -

      Здесь приведен список ссылок, где вы сможете получить дополнительную информацию :
      ip-sysctl.txt – из документации к ядру 2.4.14. Маленький, но хороший справочник по организации сетевого кода ядра.
      ip_dynaddr.txt – из документации к ядру 2.4.14. Маленький справочник по параметрам настройки ip_dynaddr, доступным через sysctl и файловую систему /proc.
      iptables.8 – Маны для iptables 1.2.4 в формате HTML Прекрасное руководство для создания правил в iptables. Всегда полезно иметь под рукой.
       – Хороший и подробный документ, описывающийпротокол ICMP. Написан Ральфом Уолденом (Ralph Walden).
       – Официальный источник информации по протоколу ICMP. Содержит всю техническую информацию о протоколе ICMP, которая только может потребоваться. Автор J. Postel.
       – Этот документ описывает стандарт протокола TCP. Документ чрезвычайно насыщен техническими подробностями, однако всякий, желающий понять работу протокола TCP во всех деталях, должен прочитать этот документ. Автор J. Postel.
       – Официальный сайт netfilterи iptables. Необходим для всех желающих установить iptablesи netfilterв linux.
      Firewall rules table – Небольшой файл в формате PDF, любезно предоставленный Стюартом Кларком (Stuart Clark), который представляет из себя набор бланков для ведения отчетности по правилам, используемым на брандмауэре.
      /etc/protocols – Пример файла protocols, полученный в дистрибутиве Slackware. Может служить справочником по номерам протоколов, таких как IP, ICMP или TCP.
      /etc/services – Пример файла services, полученный в дистрибутиве Slackware. Чрезвычайно полезен для просмотра, чтобы увидеть какие протоколы с какими портами работают.
       – Одна из самых больших групп, которые занимаются установлением и поддержкой стандартов Internet. Поддерживает свой репозиторий RFC. Включает в себя как крупные компании, так и отделные лица, с целью обеспечения межоперабельности Интернета.
       – Один из лучших документов, касающихся роутинга. Поддерживается сайт Бертом Хубертом (Bert Hubert).
       – На сайте вы найдете все «заплаты» к ядру, написанные Matthew G. Marsh. Среди всего прочего, здесь вы найдете «заплату» FTOS.
       – Домашняя страница проекта ULOGD.
      The один из лучших сайтов, содержащих документацию. Здесь вы найдете огромное количество документов по Linux-тематике.
       – Официальный FAQ (Frequently Asked Questions) по netfilter .
       – Rusty Russells Unreliable Guide to packet filtering. Прекрасная документация по основам фильтрации пакетов с помощью iptables, написанная одним из разработчиков iptables и netfilter.
       – Rusty Russells Unreliable Guide to Network Address Translation. Замечательная документация по Network Address Translation в iptables и netfilter, написанная одним из основных разработчиков Расти Расселом (Rusty Russell).
       – Rusty Russells Unreliable Netfilter Hacking HOWTO. Один из немногих документов по созданию кода для работы с netfilter и iptables. Так же написан Расти Расселом (Rusty Russell).
       – Содержит множество ссылок в Интернет по тематике. Имеется список сценариев iptables для различных применений.
       – Отличное обсуждение по автоматизации работы iptables, например: как, внесением незначительных изменений, заставить ваш компьютер автоматически добавлять «неугодные» сайты в специальный список (banlist) в iptables.
       – Прекрасное описание модулей трассировщика соединений. Если вам интересна тема трассировки соединений, то вам следует это прочитать.
       – Один из немногих сайтов, который содержит информацию о командах Linux CBQ, tc и ip. Поддерживает сайт – Stef Coene.
       – Официальный список адресов (mailing-list) по netfilter. Чрезвычайно полезен для разрешения вопросов по iptables и netfilter.
 
      И конечно же исходный код iptables, документация и люди, которые помогали мне.

      Я хотел бы выразить особую признательность людям, которые оказали мне неоценимую помощь при создании этого документа.:
       , Как главному редактору, за исправление моих жутких ошибок. А так же огромное спасибо за перевод этого документа в формат DocBook.
       , За помощь по некоторым аспектам работы механизма определения состояния пакетов.
       , За усовершенствование правил rc.firewall, за вдохновление меня на переписывание правил и за введение нескольких таблиц в этот же файл.
       , , За помощь в понимании порядка прохождения пакетами основных таблиц NAT и filter.
       , , За помощь в создании работоспособных правил, использующих критерии проверки состояния пакетов (state matching).
       , За помощь с картинками. Я знаю, что я плохой оформитель, а Kent – лучший из всех кого я знаю ;). А так же спасибо за поиск ошибок в этом документе.
       Anders 'DeZENT' Johansson, За информацию о странных провайдерах (ISP), которые используют адреса, зарезервированные для локальных сетей.
       , за многочисленные подсказки и за вылавливание моих ошибок.
      И конечно же всем остальным, кто отвечал на мои вопросы, высказывал свои суждения об этом документе. Очень сожалею, что не могу упомянуть всех.

      Version 1.1.19 (21 May 2003)
      http://iptables-tutorial.frozentux.net
      By: Oskar Andreasson
      Contributors: Peter van Kampen, Xavier Bartol, Jon Anderson, Thorsten Bremer
      and Spanish Translation Team.
 
      Version 1.1.18 (24 Apr 2003)
      http://iptables-tutorial.frozentux.net
      By: Oskar Andreasson
      Contributors: Stuart Clark, Robert P. J. Day, Mark Orenstein and Edmond Shwayri.
 
      Version 1.1.17 (6 Apr 2003)
      http://iptables-tutorial.frozentux.net
      By: Oskar Andreasson
      Contributors: Geraldo Amaral Filho, Ondrej Suchy, Dino Conti, Robert P. J. Day,
      Velev Dimo, Spencer Rouser, Daveonos, Amanda Hickman, Olle Jonsson and
      Bengt Aspvall.
 
      Version 1.1.16 (16 Dec 2002)
      http://iptables-tutorial.frozentux.net
      By: Oskar Andreasson
      Contributors: Clemens Schwaighower, Uwe Dippel and Dave Wreski.
 
      Version 1.1.15 (13 Nov 2002)
      http://iptables-tutorial.frozentux.net
      By: Oskar Andreasson
      Contributors: Clemens Schwaighower, Uwe Dippel and Dave Wreski.
 
      Version 1.1.15 (13 Nov 2002)
      http://iptables-tutorial.frozentux.net
      By: Oskar Andreasson
      Contributors: Mark Sonarte, A. Lester Buck, Robert P. J. Day, Togan Muftuoglu,
      Antony Stone, Matthew F. Barnes and Otto Matejka. 
 
      Version 1.1.14 (14 Oct 2002)
      http://iptables-tutorial.frozentux.net
      By: Oskar Andreasson
      Contributors: Carol Anne, Manuel Minzoni, Yves Soun, Miernik, Uwe Dippel, 
      Dave Klipec and Eddy L O Jansson.
 
      Version 1.1.13 (22 Aug 2002)
      http://iptables-tutorial.haringstad.com
      By: Oskar Andreasson
      Contributors: Tons of people reporting bad HTML version.
 
      Version 1.1.12 (19 Aug 2002)
      http://www.netfilter.org/tutorial/
      By: Oskar Andreasson
      Contributors: Peter Schubnell, Stephen J. Lawrence, Uwe Dippel, Bradley 
      Dilger, Vegard Engen, Clifford Kite, Alessandro Oliveira, Tony Earnshaw, 
      Harald Welte, Nick Andrew and Stepan Kasal.
 
      Version 1.1.11 (27 May 2002)
      http://www.netfilter.org/tutorial/
      By: Oskar Andreasson
      Contributors: Steve Hnizdur, Lonni Friedman, Jelle Kalf, Harald Welte, 
      Valentina Barrios and Tony Earnshaw.
 
      Version 1.1.10 (12 April 2002)
      http://www.boingworld.com/workshops/linux/iptables-tutorial/
      By: Oskar Andreasson
      Contributors: Jelle Kalf, Theodore Alexandrov, Paul Corbett, Rodrigo 
      Rubira Branco, Alistair Tonner, Matthew G. Marsh, Uwe Dippel, Evan 
      Nemerson and Marcel J.E. Mol. 
 
      Version 1.1.9 (21 March 2002)
      http://www.boingworld.com/workshops/linux/iptables-tutorial/
      By: Oskar Andreasson
      Contributors: Vince Herried, Togan Muftuoglu, Galen Johnson, Kelly Ashe, Janne
      Johansson, Thomas Smets, Peter Horst, Mitch Landers, Neil Jolly, Jelle Kalf,
      Jason Lam and Evan Nemerson.
 
      Version 1.1.8 (5 March 2002)
      http://www.boingworld.com/workshops/linux/iptables-tutorial/
      By: Oskar Andreasson
 
      Version 1.1.7 (4 February 2002)
      http://www.boingworld.com/workshops/linux/iptables-tutorial/
      By: Oskar Andreasson
      Contributors: Parimi Ravi, Phil Schultz, Steven McClintoc, Bill Dossett,
      Dave Wreski, Erik Sjilund, Adam Mansbridge, Vasoo Veerapen, Aladdin and
      Rusty Russell.
 
      Version 1.1.6 (7 December 2001)
      http://people.unix-fu.org/andreasson/
      By: Oskar Andreasson
      Contributors: Jim Ramsey, Phil Schultz, Giran Bхge, Doug Monroe, Jasper
      Aikema, Kurt Lieber, Chris Tallon, Chris Martin, Jonas Pasche, Jan
      Labanowski, Rodrigo R. Branco, Jacco van Koll and Dave Wreski.
 
      Version 1.1.5 (14 November 2001)
      http://people.unix-fu.org/andreasson/
      By: Oskar Andreasson
      Contributors: Fabrice Marie, Merijn Schering and Kurt Lieber.
 
      Version 1.1.4 (6 November 2001)
      http://people.unix-fu.org/andreasson
      By: Oskar Andreasson
      Contributors: Stig W. Jensen, Steve Hnizdur, Chris Pluta and Kurt Lieber.
 
      Version 1.1.3 (9 October 2001)
      http://people.unix-fu.org/andreasson
      By: Oskar Andreasson
      Contributors: Joni Chu, N.Emile Akabi-Davis and Jelle Kalf.
 
      Version 1.1.2 (29 September 2001)
      http://people.unix-fu.org/andreasson
      By: Oskar Andreasson
 
      Version 1.1.1 (26 September 2001)
      http://people.unix-fu.org/andreasson
      By: Oskar Andreasson
      Contributors: Dave Richardson.
 
      Version 1.1.0 (15 September 2001)
      http://people.unix-fu.org/andreasson
      By: Oskar Andreasson
 
      Version 1.0.9 (9 September 2001)
      http://people.unix-fu.org/andreasson
      By: Oskar Andreasson
 
      Version 1.0.8 (7 September 2001)
      http://people.unix-fu.org/andreasson
      By: Oskar Andreasson
 
      Version 1.0.7 (23 August 2001)
      http://people.unix-fu.org/andreasson
      By: Oskar Andreasson
      Contributors: Fabrice Marie.
 
      Version 1.0.6
      http://people.unix-fu.org/andreasson
      By: Oskar Andreasson
 
      Version 1.0.5
      http://people.unix-fu.org/andreasson
      By: Oskar Andreasson
      Contributors: Fabrice Marie.

      Version 1.1, March 2000
      Copyright (C) 2000 Free Software Foundation, Inc. 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.

0. PREAMBLE

1. APPLICABILITY AND DEFINITIONS