Правила iptables для DNS на шлюзе

[aviacliff]

Если посмотреть несколько примеров написания iptables (относительно DNS) на шлюзе

1) http://wiki.gentoo.ru/wiki/
«Логика и правила iptables»

Код: [Выделить]

einfo "Applying chains to INPUT"
$IPTABLES -A INPUT -s $LAN -p udp --dport domain -j com-allow

einfo "Applying chains to OUTPUT"
 $IPTABLES -A OUTPUT -p udp --dport domain -j com-allow
2)http://wiki.gentoo.ru/wiki/
«Подробная настройка iptables»

 

Код: [Выделить]

TCPSERV="domain ssh http https ftp ftp-data mail pop3 pop3s imap3 imaps imap2 time $PORTAGE $IRC $MSN $ICQ  $OpenPGP_HTTP_Keyserver" UDPSERV="domain time"
echo -n "FW: Allowing inside systems to use service:"
for i in $TCPSERV;
do
 echo -n "$i "
  $IPT -A OUTPUT  -o $EXTIF -p tcp -s $EXTIP --dport $i --syn -m state --state NEW -j ACCEPT

  done
echo ""
echo -n "FW: Allowing inside systems to use service:"
for i in $UDPSERV;
do
 echo -n "$i "
  $IPT -A OUTPUT  -o $EXTIF -p udp -s $EXTIP --dport $i -m state --state NEW -j ACCEPT
 
done
echo ""
3)http://www.gentoo.org/doc/ru/security/security-handbook.xml?part=1&chap=12
«Межсетевые экраны»

Код: [Выделить]

einfo "Applying chains to OUTPUT"
$IPTABLES -A OUTPUT -j allow-dns-traffic-out,

то видим

В первом примере прописаны правила как в цепочке INPUT так и в цепочке OUTPUT.

Во втором и в третьем примере имеются правила только для  цепочки OUTPUT.

Вопрос: для чего вводится правило в цепочке INPUT. Нельзя обойтись только цепочкой  OUTPUT ? Как будет правильнее с точки зрения безопасности?

[fisher74]

Не... главное начитались на сторонних ресурсах, а с вопросами сюда... Ну не нахал? )))
В основном зависит от назначения брандмауэра и паранои админа.

для чего вводится правило в цепочке INPUT

Ну так чтобы разрешить входящие запросы.

Нельзя обойтись только цепочкой  OUTPUT?

Можно. Но Ваш ДНС сервер может быть недоступен при некоторых обстоятельствах.

Как будет правильнее с точки зрения безопасности?

Безопасности чего собственно?

А вообще, цитаты вырваны из контекста.
Правила netfilter в плане безопасности всегда рассматриваются в комплексе, а не отдельно взятыми кусками

[aviacliff]

Да начитался и проверил почти все на собственной шкуре!!!
Могу задать вопрос и на другом ресурсе,но так уж сложилось, что тему iptables пришлось изучать с вами дружно обнявшись.
В чем моя вина, что здесь нет таких примеров?
Тем не менее за ответы спасибо!

[fisher74]

Да начитался ...
Могу ...

Вообще-то это была шутка.

В чем моя вина, что здесь нет таких примеров?

Ваша вина в том, что Вы обвиняете ресурс в отсутствии документации, забыв про раздел документации, где есть =iptables]целая статья, посвящённая iptables, С ПРИМЕРАМИ.

[aviacliff]

Fisher74 Вас понял — не въехал в тонкий английский юмор.

В вашем примере, что касается DNS присутствуют только цепочки  INPUT

Код: [Выделить]

# network.dns
-A INPUT -p tcp -m conntrack --ctstate NEW -m tcp --dport 53 -j ACCEPT
-A INPUT -p udp -m conntrack --ctstate NEW -m udp --dport 53 -j ACCEPT

Я так думаю, чтобы не нарушить функционал одной из ключевых служб DNS нужно задействовать как INPUT так и OUTPUT. Что то вроде такого:

Код: [Выделить]

# DNS client
$IPTABLES -A INPUT -i $INET_IFACE -p udp -s $NAMESERVER_1 --sport 53 -d $INET_IP --dport $UNPRIVPORTS -m conntrack --ctstate NEW -j ACCEPT
$IPTABLES -A OUTPUT -o $INET_IFACE -p udp -m udp -s $INET_IP --sport $UNPRIVPORTS -d $NAMESERVER_1 --dport 53 -m conntrack --ctstate NEW -j ACCEPT
Безопасность.
На одном из сайтов имеется такая вот ремарка.
Запросы от клиента к серверу по протоколу TCP разрешены, если
не прошли UDP-запросы. Это встречается редко. Обычно клиенты
используют TCP для передачи зон вторичному серверу от
первичного, и если они хакеры.
Не помешают следующие правила:

Код: [Выделить]

# DNS does known hacker
$IPTABLES -A INPUT -i $INET_IFACE -p tcp -m tcp ! --syn -s $NAMESERVER_1 --sport 53 -d $INET_IP --dport $UNPRIVPORTS  -j ACCEPT
$IPTABLES -A OUTPUT -o $INET_IPFACE -p tcp -m tcp -s $INET_IP --sport $UNPRIVPORTS -d $NAMESERVER_1 --dport 53 -j ACCEPT
где
$INET_IFACE-внешний сетевой интерфейс
$NAMESERVER_1-  IP-адрес Primary DNS-сервера из Вашей сети или ISP
INET_IP - IP адрес на внешнем сетевом интерфейсе

[fisher74]

Ещё раз повторюсь - зависит, как минимум, от общей концепции защиты.
Например, если дефолтное действие DROP стоит только на INPUT, то разрешающее правило для dns просто необходимо в этой цепочке и совершенно бессмысленно в цепочке OUTPUT.
В тоже время, если на OUTPUT дефолтным действием выставлено так же DROP, то без разрешающего правила dns-сервер никому не ответит.

Или я не совсем корректно понял Ваш вопрос?

[aviacliff]

Во всех приведенных примерах установлены политики по умолчанию
 

Код: [Выделить]

$IPTABLES -P FORWARD DROP
  $IPTABLES -P INPUT   DROP
  $IPTABLES -P OUTPUT  DROPчто не разрешено, то остальное запрещено.

Только в одном примере разрешены входящие и исходящие для DNS (INPUT, OUTPUT).
В двух других примерах разрешены только исходящие (OUTPUT).
В этом и заключается собственно вопрос:
что означает отсутствие допуска по цепочке INPUT - не делать лишних отверстий в щите?

[Karl500]

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

Например, если держите внутри DNS-сервер, обслуживающий Вашу зону (master или slave) - Вам нужен первый вариант.

[_set_]

Не пойму зачем разрешать входящие ДНС запросы со внешней сети, как правило они приходят с внутренней... Это для обновления зон?

[Karl500]

Не только. Если у Вас своя зона и свой DNS-сервер, то к нему снаружи будут идти входящие запросы от тех, кто хочет либо послать Вам письмо, либо залезть на Ваш веб-сайт.

Ну и обновления зон с Вашими slave'ми (или апдейт от master), конечно, тоже.

[aviacliff]

Спасибо за грамотное разъяснение!