4.3.3 Create content in user specified chains– Если вы создали какие либо пользовательские цепочки в пределах этой таблицы, вы можете заполнить их правилами здесь.
4.3.4 PREROUTING– В этом пункте имеется только упоминание о цепочке.
4.3.5 INPUT chain– В этом пункте имеется только упоминание о цепочке.
4.3.6 FORWARD chain– В этом пункте имеется только упоминание о цепочке.
4.3.7 OUTPUT chain– В этом пункте имеется только упоминание о цепочке.
4.3.8 POSTROUTING chain– В этом пункте имеется только упоминание о цепочке.
Надеюсь, что я объяснил достаточно подробно, как каждый сценарий структурирован и почему они структурированы таким способом.
ОСТОРОЖНО: Обратить внимание, что эти описания чрезвычайно кратки, и являются лишь кратким пояснением того, почему сценарии имеют такую структуру. Я не претендую на истину в последней инстанции и не утверждаю, что это – единственный и лучший вариант.
The Linux Documentation Project. (Взгляните еще раз в начало документа, где описывается процесс установки iptables.
прим. перев.)
4.3.4 PREROUTING– В этом пункте имеется только упоминание о цепочке.
4.3.5 INPUT chain– В этом пункте имеется только упоминание о цепочке.
4.3.6 FORWARD chain– В этом пункте имеется только упоминание о цепочке.
4.3.7 OUTPUT chain– В этом пункте имеется только упоминание о цепочке.
4.3.8 POSTROUTING chain– В этом пункте имеется только упоминание о цепочке.
Надеюсь, что я объяснил достаточно подробно, как каждый сценарий структурирован и почему они структурированы таким способом.
ОСТОРОЖНО: Обратить внимание, что эти описания чрезвычайно кратки, и являются лишь кратким пояснением того, почему сценарии имеют такую структуру. Я не претендую на истину в последней инстанции и не утверждаю, что это – единственный и лучший вариант.
The Linux Documentation Project. (Взгляните еще раз в начало документа, где описывается процесс установки iptables.
прим. перев.)
Другие ошибки, которые вы можете получить при запуске iptables:
iptables: No chain/target/match by that name
Эта ошибка сообщает, что нет такой цепочки, действия или критерия. Это может зависеть от огромного числа факторов, наиболее вероятно, что вы пытаетесь использовать несуществующую (или еще не определенную) цепочку, несуществующее действие или критерий. Либо потому, что не загружен необходимый модуль.
B.2. Пакеты со статусом NEW и со сброшенным битом SYN
Это свойство
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, так как они, фактически, являются частью уже установленного соединения. Следовательно, пакет будет соответствовать правилам в результате чего будет зажурналирован и сброшен.
$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, так как они, фактически, являются частью уже установленного соединения. Следовательно, пакет будет соответствовать правилам в результате чего будет зажурналирован и сброшен.
B.3. SYN/ACK – пакеты и пакеты со статусом NEW
Существует одна из разновидностей спуфинг-атак (от англ. 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] и риск от их использования относительно невелик. Исключение составляют случаи использования серии брандмауэров. В этом случае некоторые соединения могут оказаться заблокированными, даже если они вполне законны. Эти правила, ко всему прочему, допускают некоторые виды сканирования портов, но не более того.
Для рассмотрения типичной 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] и риск от их использования относительно невелик. Исключение составляют случаи использования серии брандмауэров. В этом случае некоторые соединения могут оказаться заблокированными, даже если они вполне законны. Эти правила, ко всему прочему, допускают некоторые виды сканирования портов, но не более того.
B.4. Поставщики услуг Internet, использующие зарезервированные IP-адреса
Я добавил этот раздел чтобы предупредить вас о туповатых провайдерах (Internet Service Providers), которые назначают IP адреса, отведенные
IANAдля локальных сетей. Например, Swedish Internet Service Provider и телефонная монополия Telia используют такие адреса для своих серверов
DNS(диапазон 10.x.x.x). Проблема, с которой вы будете наиболее вероятно сталкиваться, состоит в том, что мы, в своих сценариях, блокируем подключения с любых IP в диапазоне 10.x.x.x, из-за возможности фальсификации пакетов. Если вы столкнетесь с такой ситуацией, то наверное вам придется снять часть правил. Или установить правила, пропускающие траффик с этих серверов, ранее цепочки