Назад | Перейти на главную страницу

Вопросы о состоянии и политике брандмауэра?

Наконец-то мне удалось установить виртуальную машину, и теперь я возился с 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 for 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 и состоянием в контексте ниже?

государственный пример:
```
$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 заменяет - и поэтому устаревает - совпадение состояний. Но практически гос матч никоим образом не устарел.

Я также был бы признателен за хорошие онлайн-материалы для чтения по iptables.

Ссылки, рекомендуемые на данный момент:

Идеальный набор правил

Проект документации Linux

Рекомендуется применять свои правила как можно раньше. Поместите их в начало. Правила DROP для внутреннего трафика могут вызвать проблемы.
Это правило будет считаться ошибкой, поскольку оно реализует политику ПРИНЯТИЯ. Добавление правила принятия для каждой службы - это правильный способ создания брандмауэра.
Политика принятия означает, что вы используете в основном открытую политику. (Мы заперли входную дверь на замок, но вы можете использовать любую другую дверь, чтобы войти.) Лучшая политика - это в основном закрытая политика. Мы держим все двери и окна запертыми и открываем только те, которые нам нужны.
Казалось бы, нет никакой разницы, хотя все правила, которые я видел, используют состояние. Модуль conctrack будет следить за состоянием. Используйте это правило с правилом принятия порта в вопросе 2, чтобы включить службы.

Вы можете посмотреть на Shorewall документацию, чтобы узнать, что можно сделать с помощью iptables. Я использую его для создания брандмауэра на всех своих экземплярах Linux (включая OpenWRT). Он имеет хорошо документированные образцы (по умолчанию / базовые) конфигурации для серверов с 1, 2 или 3 интерфейсами.

Проект документации Linux также есть документация.

Вы ничего не упомянули о нац table, поэтому я предполагаю, что этот вопрос относится к написанию сценариев межсетевого экрана iptables для автономных серверов, а не для многосетевых / шлюзовых устройств.

Вы правы: каждая цепочка имеет одну политику, поэтому не имеет значения, где и в каком порядке изложены эти правила политики.
Это правило устанавливает соглашение, которое используют многие / большинство скриптов брандмауэра: статичность. Хотя это всего лишь мелкая придирка. Я бы не включил состояние 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 и т. Д.

State vs. Conntrack: State был удален в пользу conntrack, эффективного с ядром Linux 3.7