Каковы последствия использования правила DROP по умолчанию на общедоступном DNS-сервере
RHEL 6.6 авторитетный DNS-сервер. Прямо сейчас в IPtables цепочка INPUT по умолчанию принимает значение ACCEPT.
:INPUT ACCEPT [0:0]
В последнее время у меня возникли некоторые проблемы с его атакой, и мне просто интересно, что будет затронуто с точки зрения службы DNS, если я изменю политику по умолчанию на DROP?
:INPUT DROP [0:0]
Я также смотрю на то, чтобы сделать это с выходной цепочкой, но опять же меня беспокоит, поскольку это общедоступный DNS-сервер, если я изменю его, это будет иметь негативные последствия в том, как сервер взаимодействует с другими DNS-серверами, выполняя такие вещи, как зональные передачи, кеширование и тому подобное?
Чтобы дать представление о том, что у меня сейчас есть, вот содержимое / etc / sysconfig / iptables.
*filter
:INPUT ACCEPT [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [1015316:198598633]
-A INPUT -m state --state INVALID -j DROP
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -s X.X.X.X/24 -p tcp -m tcp --dport 22 -m state --state NEW -j ACCEPT
-A INPUT -s X.X.X.X/18 -p icmp -m icmp --icmp-type 8 -m state --state NEW -j ACCEPT
-A INPUT -p tcp -m tcp --dport 53 -m state --state NEW -j ACCEPT
-A INPUT -p udp -m udp --dport 53 -m state --state NEW -j ACCEPT
-A INPUT -s X.X.X.X/32 -j DROP
-A INPUT -s X.X.X.X/32 -j DROP
-A INPUT -j DROP
-A OUTPUT -d X.X.X.X/20 -j DROP
COMMIT
Поскольку вы не рассказываете о природе атаки, мой совет будет более общим.
- Вы используете
-состояние, которое загружает модуль conntrack. Это не общеизвестно, но это всегда следует рассматривать как крайний вариант с сервисами, которые могут рассчитывать на большое количество запросов как часть нормальной работы. Как только таблица сеансов заполнит ваш сервер, начнут выпадать пакеты, и в dmesg начнут появляться предупреждения о них. Даже если мы предположим, что это не должно происходить на авторитетном DNS-сервере, если только вас не используют в атаке (и, следовательно, вы не будете использовать sysctl для повышения лимита), это плохая стратегия, потому что вы отбрасываете хорошие пакеты вместе с плохими. Было бы гораздо предпочтительнее исследовать использование новых возможностей BIND по ограничению клиентской скорости, так как в этот момент вы бросаете правый трафик. - RE: политика DROP по умолчанию в таблице OUTPUT, ожидайте увидеть сообщения журнала о невозможности разрешения имен.
NSзаписи, которые вы обслуживаете, запускают внутренний поиск этих записей (известный как дополнительная обработка разделов ), и если вы не уверены на 100%, что у вас нет делегаций, вы увидите эти сообщения журнала. Даже если у вас нет делегаций, разумно ожидать, что они будут присутствовать в будущем. Поэтому рекомендуется добавить порт 53 в таблицу OUTPUT, несмотря на то, что ваш сервер не является рекурсивным.
Наконец, и, возможно, самое главное, крайне маловероятно, что вы на самом деле получите какое-либо преимущество от установки здесь брандмауэра на основе пакетов.
- Большинство DNS-атак используют нормальную работу DNS-сервера. Брандмауэр не остановит это. Минимизация поверхности атак DNS - это все о вашем сервере имён и сетевой конфигурации.
- Брандмауэр не заставляет пакеты уходить. Он просто сбрасывает их до того, как принимающая программа их увидит. Если ваша цепь переполняется входящим трафиком, наводнение все еще происходит, а вы все еще в отключенном состоянии. Если ваша цепь переполняется исходящим трафиком с вашего сервера как часть атаки, вам нужно решить проблему напрямую, и ваш вопрос-ответ на самом деле не объясняет природу атаки.
Учитывая вышеперечисленные факторы, включение iptables в этом сценарии, скорее всего, не принесет большой пользы, которая не могла бы быть лучше решена с помощью других стратегий. Таким образом, такой подход в основном увеличивает вероятность того, что вы будете сбрасывать легитимный трафик во время событий атаки, когда его можно было бы избежать.
.