Каков канонический способ хранения правил iptables

iptables, стандартный брандмауэр Linux, не сохраняет правила между перезагрузками. Вы должны позаботиться об этом сами. Есть много способов сделать это. Какой канонический способ сделать это? Каковы лучшие практики?

Я отвечу своим собственным решением, но меня интересуют другие / лучшие решения.

Вот несколько примеров правил. Сохраните их в /etc/iptables.rules

# Generated by iptables-save v1.3.6 on Wed Oct 24 17:07:29 2007
*filter
:INPUT ACCEPT [89458:132056082]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [263904:15667452]
-A INPUT -i lo -j ACCEPT 
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT 
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT 
-A INPUT -m limit --limit 5/min -j LOG --log-prefix "iptables denied: " --log-level 7 
-A INPUT -j DROP 
COMMIT
# Completed on Wed Oct 24 17:07:29 2007

добавьте эту строку в конец / etc / network / interfaces

pre-up iptables-restore < /etc/iptables.rules

Мы используем множество правил iptables , поэтому для упрощения администрирования мы делаем следующее:

• Все правила вызываются из скриптов - скрипты вызываются из /etc/init.d/firewall (пользовательский скрипт)
• Файл имен серверов / сетевых имен (переменных IP-адресов) сохраняется и включается в каждый сценарий iptables для согласованности.
• отдельные сценарии хранятся для каждой подсети (например, частная / DMZ / VPN и т. д.), чтобы упростить поиск. Правила, которые принадлежат двум сценариям (например, те, которые ограничивают общение в частном порядке и DMZ), помещаются в более «безопасный» сетевой сценарий
• везде, где это возможно, используются циклы и вложенные циклы, чтобы сделать скрипты максимально короткими.
• каждое новое правило или изменение документируется с комментариями, предшествующими соответствующему разделу сценария.

Я не знаю, является ли это лучшим способом сделать это, но это хорошо сработало для нас.

Хотя это правда, это зависит от среды и платформы, в зависимости от платформы я видел два хороших подхода:

• RHEL / CentOS: хранить все правила в одном файле / etc / sysconfig / iptables, который считывается сценарием запуска iptables.

• Debian / Ubuntu: храните все правила в отдельных служебных файлах в каталоге /etc/iptables.d/. Например, /etc/iptables.d/port_http, /etc/iptables.d/port_dns, где port_service сопоставляется с именем службы в / etc / services.

В любом случае, файл или файлы управляются инструментом конфигурации, таким как Chef или Puppet, и считываются сценарием запуска «master» для iptables, который запускается во время загрузки.

В дополнение к iptables-save(и iptables-restore), сложные схемы брандмауэра лучше обрабатываются специальными программами. Например, мы использовали shorewall(«iptables made easy») для настройки iptables.

Также доступны более простые инструменты, такие как firestarter и kmyfirewall .

Это зависит от используемого вами дистрибутива. В некоторых дистрибутивах, особенно в дистрибутивах Red Hat, правила iptables сохраняются автоматически, но в них есть специальный каталог. Я наиболее знаком с RHEL, и правила iptables можно найти в / etc / sysconfig / iptables. Познакомиться с синтаксисом правил iptables поначалу может быть непросто, но довольно просто, когда вы освоите его.

На сайте netfilter есть много документации по iptables, включая некоторые введения. Если вы готовы немного почитать, вы можете найти много полезной информации здесь: http://www.netfilter.org/documentation/

Этот вопрос очень близок к дупле 4934 и относится к 397 .

Я использую Firehol в сочетании с веб-интерфейсом, который я разработал для управления файлом конфигурации.

Мне действительно нравится firehol, он обеспечивает более простой синтаксис, чем прямое использование iptables.

• Вы можете использовать команду отладки firehol для точного генерирования команд iptables.
• Если у вас есть ошибка в вашей конфигурации и вы запускаете брандмауэр, firehol обнаруживает ошибку и возвращается к предыдущему состоянию.
• Firehol имеет команду «try», которую вы можете использовать для удаленного запуска брандмауэра. Если ваши изменения уничтожат ваше соединение, firehol вернется в предыдущее состояние, если вы не уничтожили ваше соединение, он попросит вас подтвердить изменение.
• Firehol имеет большой набор предварительно определенных сервисов, поэтому вам не нужно точно помнить, какие порты вам нужны, какие порты открывать для какого-то непонятного протокола.

Конечно, мы используем собственный init-скрипт. Я могу использовать циклы for для перебора списка портов, анализа других конфигурационных файлов, таких как vpn-users и т. Д. Отлично!

И iptables-restore, безусловно, самый «канонический» способ его сохранения.

Что я хочу добавить:

Обратите внимание, что текущая версия iptables будет при каждом вызове просить ядро ​​вернуть полный список цепочек. Затем он внесет одно изменение, которое вы просите сделать. Затем он снова загрузит список.

Это медленно (O (n ^ 2)), нам нужно 5 секунд, что слишком долго ;-)

Если вы используете iptables-restore, все это происходит за одну быструю операцию.