Имеется еще одна известная проблема с этими правилами. Если кто-то в настоящее время связан с брандмауэром, например из 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-пакеты будут «сбрасываться» этими правилами. Поэтому, следующее правило необходимо вставить в цепочку первым:

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