Вопросы по брандмауэру о состоянии и политике?
Мне наконец-то удалось установить свой виртуальный хост, и теперь я работаю с iptables для создания, тестирования и изучения.
Имеет ли значение, если я поставлю приведенные ниже правила в начале или в конце своих правил?
$IPT -P INPUT DROP $IPT -P FORWARD DROP $IPT -P OUTPUT DROPЯ проверил и не было никакой разницы, но я хотел бы подтвердить.
Ответ, который я пока выбрал: это хорошая идея, чтобы применить вашу политику как можно раньше. Поместите их в начале. Правила DROP для внутреннего трафика могут вызвать проблемы.
Наличие нижеследующего правила будет рассматриваться как ошибка на брандмауэре?
$IPT -A OUTPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPTБез этого правила мне нужно было бы добавить, например, правило OUTPUT для моего ssh-соединения, например:
$IPT -A OUTPUT -p tcp --sport 2013 -j ACCEPTОтвет: После дополнительных тестов и бесед с людьми на #iptables@freenode я пришел к выводу, что с помощью
-m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPTдля INPUT и OUPUT - хороший подход, который поможет вам справиться со многими вещами, такими как, например, FTP, и хороший подход, потому что, если у вас нет данного открытого порта и вы не примете, на нем не будет вредоносного соединения.Вот нормальный пример без использования вышеуказанного:
$IPT -A INPUT -p tcp --dport 20:21 -j ACCEPT $IPT -A OUTPUT -p tcp --dport 20:21 -j ACCEPTТеперь вот как выглядит правило, используя приведенное выше:
$IPT -A INPUT -p tcp --dport 21 -m conntrack --ctstate NEW -j ACCEPTЭто все, что вам нужно, потому что, как только соединение установлено, выходной результат будет сразу же отслежен, и вам не нужно будет устанавливать правила для порта ftp-data.
Что плохого в том, чтобы иметь приведенное ниже правило, не могли бы вы привести пример того, почему его нет, и вместо этого просто определите все, что вам может понадобиться?
$IPT -P OUTPUT ACCEPTОтвет, который я пока выбрал: это правило политики разрешает весь исходящий трафик. Как политика, разрешить все, очевидно, менее безопасно, чем разрешить только явные виды трафика. Так что, если безопасность является вашим высшим приоритетом, вместо этого вы захотите установить политику DROP в цепочке вывода. Просто имейте в виду, что вам нужно будет включить ряд правил, чтобы разрешить исходящий трафик большому количеству обыденных вещей, таких как: DNS, SMTP, IMAP, POP3, HTTP, HTTPS и т. Д.
В чем разница между conntrack и state в следующем контексте?
приведите пример:
$IPT -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPTпример conntrack:
$IPT -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPTОтвет: После некоторых исследований с людьми на #iptables@freenode я пришел к выводу, что с этого момента я должен использовать conntrack.
Технически соответствие conntrack заменяет - и, следовательно, устаревшее - соответствие состояния. Но практически государственный матч никак не устарел.
Я также был бы признателен за хорошие материалы для чтения в Интернете.
Ссылки рекомендованные до сих пор:
3 ответа
- Это хорошая идея, чтобы применить вашу политику как можно раньше. Поместите их в начале. Правила DROP для внутреннего трафика могут вызвать проблемы.
- Это правило будет считаться ошибкой, так как оно реализует и ПРИНЯТЬ политику. Добавление правила принятия для каждой службы является правильным способом построения вашего брандмауэра.
- Политика принятия означает, что вы используете в основном открытую политику. (Мы заперли входную дверь запертой, но вы можете использовать любую другую дверь, чтобы войти.) Лучшая политика - это в основном закрытая политика. Мы держим все двери и окна запертыми и открываем только те, которые нам нужны.
- Казалось бы, нет никакой разницы, хотя все правила, которые я видел, используют состояние. Модуль conctrack будет контролировать состояние. Используйте это правило с правилом принятия порта в вопросе 2, чтобы включить службы.
Возможно, вы захотите взглянуть на документацию Shorewall, чтобы узнать, что можно сделать с помощью iptables. Я использую его для создания брандмауэра на всех моих экземплярах Linux (включая OpenWRT). Он имеет хорошо документированные примеры (по умолчанию / базовые) конфигурации для серверов с 1, 2 или 3 интерфейсами.
Проект документации Linux также имеет документацию.
Вы ничего не упомянули о таблице nat, поэтому я собираюсь предположить, что этот вопрос относится к написанию сценариев брандмауэра iptables для автономных серверов, а не для блоков multi-homed/gateway.
Вы правы: каждая цепочка имеет единую политику, поэтому не имеет значения, где и в каком порядке указаны правила политики.
Это правило устанавливает соглашение, которое используют многие / большинство сценариев брандмауэра: сохранение состояния. Просто незначительный придира, хотя. Я бы не включил состояние NEW, и я бы также включил правило для цепочки INPUT, то есть:
$IPT -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT$IPT -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPTЯ разместил эти правила рядом или в верхней части всех моих сценариев брандмауэра, поскольку они позволяют мне сосредоточиться на создании правил для фильтрации попыток подключения и не должны думать о пакетах, не устанавливающих соединение. На мой взгляд, сценарий брандмауэра без этих правил, вероятно, будет более сложным и, следовательно, более подверженным ошибкам, чем тот, который включает их.
Это правило политики разрешает весь исходящий трафик. Как политика, разрешить все, очевидно, менее безопасно, чем разрешить только явные виды трафика. Так что, если безопасность является вашим высшим приоритетом, вместо этого вы захотите установить политику DROP в цепочке вывода. Просто имейте в виду, что вам нужно будет включить ряд правил, чтобы разрешить исходящий трафик большому количеству обыденных вещей, таких как: DNS, SMTP, IMAP, POP3, HTTP, HTTPS и т. Д.
Состояние против Conntrack: состояние было удалено в пользу conntrack, работающего с ядром Linux 3.7