Debian-way стартовать фаервал

Обычно pre-up iptables-restore < /etc/iptables.rules.

В sqeeze есть пакет iptables-persistent с примитивненьким init-скриптом, который делает практически то же самое.

Лично я предпочитаю использовать адаптированные версии редхатовских init-скриптов (вроде этого http://debian.nikolas.ru/debian/iptables-service_0.1-1_all.deb). Все-таки удобнее — автоматически подгружаются указанные conntrack-модули, можно разрешать, блокировать и сохранять простыми командами.

Спасибо. Но всё таки править, если понадобиться, скрипт всяко удобней, чем iptables.rules :) За ссылку спасибо. Посмотрим...

Все-таки удобнее — автоматически подгружаются указанные conntrack-модули, можно разрешать, блокировать и сохранять простыми командами.

А можно небольшой примерчик :)

А можно небольшой примерчик :)

Модули conntrack и nat (например, nf_conntrack_ftp и nf_nat_ftp) можно указывать в конфиге /etc/sysconfig/iptables-config в переменной IPTABLES_MODULES, и при старте фаервола они подгрузятся автоматически. Если указать там же IPTABLES_MODULES_UNLOAD=«yes», то при остановке/перезапуске они будут выгружаться.

Еще там есть полезные переменные IPTABLES_SAVE_ON_STOP и IPTABLES_SAVE_ON_RESTART, позволяющие указать сохранение списка правил при остановке или перезапуске.

Что касается самого init-скрипта:

• service iptables start — подгрузить модули, прочитать сохраненный список правил из /etc/sysconfig/iptables.
• service iptables stop — выгрузить модули (если указано), сохранить список правил (если указано), очистить все цепочки, установить везде -P ACCEPT
• service iptables save — просто сохранить правила.
• service iptables restart — stop, потом start.
• service iptables panic — экстренная блокировка сети. Очистить все цепочки, установить везде -P DROP.
• service iptables status — вывести содержимое всех таблиц и цепочек (вывод настраивается в том же iptables-config).

Вот такие вкусности дает редхат из коробки. Думаю, теперь понятно, почему я по возможности стараюсь перенести их в дебиан :)

Спасибо. Действительно, здоровские :) Простите за глупый вопрос, а в чём преимущества модуля conntrack? В смысле какие возможности он даёт?

Читать здесь. Там это объясняется на примере FTP.

Если кратко, FTP использует для передачи данных дополнительное соединение на случайный порт, и чтобы корректно его отфильтровать, нужно проанализировать первое (управляющее) соединение и узнать номер порта, по которому будет открыто второе соединение. Эту работу выполняет модуль ядра nf_conntrack_ftp (в старых ядрах ip_conntrack_ftp).

Такие трюки нужные не только для FTP, но и для многих других протоколов (IRC, SIP, H.323 и т.п.).

Большое спасибо. Получается, что всё вот эти модули

find /lib/modules/ -name '*nf_conntrack*'

необходимы, если соответствующие сервисы выполняются непосредственно на хосте (фаерволе), а

find /lib/modules/ -name '*nf_nat*'

если клиенты сидящие за натом, используют irc, sip, fto и т.д

Нет, все немного не так.

Во-первых, модули nf_nat_* требуют подгрузки соответствующих модулей nf_conntrack_*. conntrack-модули обеспечивают базовый функционал отслеживания соединений, и nat-модули опираются на этот функционал.

Во-вторых, необходимость использования conntrack-модулей на сервере или клиенте целиком и полностью зависит от уровня кривизны протокола. Например, при пассивном режиме FTP conntrack_ftp нужен на сервере, а при активном — на клиенте (что порой чревато, но сделать ничего, к сожалению, нельзя).

Разумеется, nat-модули нужны только на NAT-ах, причем необязательно на клиентских. Например, если входящий порт 21 FTP-сервера пробрасывается фаерволом на сервак в DMZ, то nf_nat_ftp тоже нужен.

Ну и наконец, вместо

find /lib/modules/ -name '*nf_nat*'

имхо проще использовать

modprobe -l '*nf_nat*'

Вы, как всегда, всё блестяще объяснили. Спасибо.

имхо проще использовать

спасибо за хинт