Блокировка нежелательного DNS трафика



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

    Отсюда следует простой вывод — Ваши рекурсивные DNS сервера должны быть всегда доступны и в состоянии обслужить запросы клиента.



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

    Следующим шагом идёт наращивание мощностей самого сервера. Данным методом счастье тоже достигается, но при стабильном росте абонентской базы оно быстро заканчивается.

    Вы спросите, какое-же решение задачи существует, точнее, что же делать в данной ситуации?

    Ответ прост — необходимо ограничивать количество рекурсивных запросов определённых типов от каждого из наших клиентов. К огромному сожалению ни в одном из ныне существующих DNS серверов нет средств ограничения количества запросов определённого типа для каждого из рекурсивных клиентов. Мы возложим данную задачу на пакетный фильтр, в приведённых ниже примерах используется iptables.

    В большинстве случаев от завирусованных клиентов идет шквал DNS запросов различных типов, огромное количество MX запросов направленных на поиск ip адресов почтовых серверов, запросы типа A для экзотических доменов типа kljhajlhfqweqwe.com или ioweurtisdvfso.org.

    По нашим грубым оценкам 3% клиентских машин генерировали более 90% всех DNS запросов.

    Простой обзвон клиента зачастую проблему не решает, ибо клиента может и не быть дома, клиент не обладает квалификацией или же просто клиент не хочет лечиться (у меня и так все работает). Также зачастую при отключении клиентского порта, провайдеры оставляют открытым трафик до DNS сервера чтобы клиент мог войти в свой личный кабинет по его имени и посмотреть причину блокировки, но т. к. клиентский компьютер «валит» именно DNS сервер, то для решения данной проблемы надо искать другой выход.

    Итак нам необходимо решить две простые задачи.
    1.Определить все допустимые типы DNS запросов которые мы будем обрабатывать.
    2.Найти разумные интервалы поступления запросов каждого типа от каждого клиента.

    Давайте разберём запросы каких типов могут приходить от наших клиентов и что нам с ними делать.

    Запись A (address record) или запись адреса связывает имя хоста с адресом IP. Самый «наиполезнейший» тип запросов. Значения 100 запросов за 10 секунд вполне приемлемы даже для тех клиентов, которые серфят «ну очень быстро» :)

    Запись AAAA (IPv6 address record) связывает имя хоста с адресом протокола IPv6. Пока IPv6 распространён не сильно, можно оставить данный тип запросов к нашему DNS серверу, ограничив двумя запросами в 10 секунд от каждого из клиентов, чтобы пустые запросы типа AAAA localhost. не влияли на работу DNS сервера.

    Запись CNAME (canonical name record) или каноническая запись имени. Тип запроса полезный, блокировка должна быть мягкая чтобы запросов подобного типа блокировалось как можно меньше. Также как и для запросов типа A 100 запросов за 10 секунд вполне приемлемое значение.

    Запись MX (mail exchange) или почтовый обменник указывает сервер(ы) обмена почтой для данного домена. Для домашних клиентов интенсивные запросы к данным типам записей явно свидетельствуют о том, что компьютер клиента заражен заразой которая рассылает спам. 5 запросов за 60 секунд хватит для работы диагностических утилит.

    Запись NS (name server) указывает на DNS-сервер для данного домена. Напрямую пользователи услуг домашнего Интернет такие запросы не генерируют, в большинстве случаев такие запросы формируются вручную через диагностические утилиты типа nslookup в целях отладки работоспособности своих доменов и пр. 10 запросов данного типа за 60 секунд вполне приемлемое значение.

    Запись PTR (pointer) или запись указателя связывает IP хоста с его каноническим именем. Применительно к пользователям услуг домашнего интернета запросы подобного типа поступают достаточно часто во время работы торрент или p2p клиентов, для разрешения имен хостов с которых вы скачиваете и которым вы раздаете. Например 50 запросов за 10 секунд вполне приемлемое значение, которого в большинстве случаев хватает для любого пользователя.

    Запись SOA (Start of Authority) или начальная запись зоны указывает, на каком сервере хранится эталонная информация о данном домене, содержит контактную информацию лица, ответственного за данную зону, тайминги (параметры времени) кеширования зонной информации и взаимодействия DNS-серверов. Данный тип запросов может использоваться пользователями домашнего интернет только в целях отладки, разрешим каждому клиенту делать 5 запросов за 60 секунд.

    Запись SRV (server selection) указывает на серверы для сервисов. Данный тип запросов может использоваться пользователями домашнего интернет только в целях отладки, разрешим каждому клиенту делать 5 запросов за 60 секунд.

    Полный список типов DNS записей можно просмотреть здесь.

    Для того чтобы понять по каким сигнатурам нам классифицировать тот или иной DNS запрос необходимо «поймать» tcpdump-ом по одному типу пакета, заглянуть в тело запроса поле Type и убедиться что:

    запрос типа MX содержит в поле type — 00 0F
    запрос типа AAAA содержит в поле type — 00 1C
    запрос типа A содержит в поле type — 00 01
    запрос типа PTR содержит в поле type — 00 0C
    запрос типа CNAME содержит в поле type — 00 05
    запрос типа NS содержит в поле type — 00 02
    запрос типа SOA содержит в поле type — 00 06
    запрос типа SRV содержит в поле type — 00 21

    Заметим также, что в DNS запросе после поля Type идёт поле Class оно всегда равно 00 01 для DNS запроса. Добавим это поле ко всем сигнатурам чтобы уменьшить количество ложных срабатываний.

    Итак чтобы заблокировать DNS запросы типа MX нам необходимо на DNS серверах добавить правила iptables:
    -A INPUT -p udp --dport 53 -m string --algo kmp --hex-string "|00 0F 00 01|" -j DROP

    так как нам надо закрыть данные запросы не полностью а просто ограничить их количество в единицу времени чтобы данные запросы не «ложили» нам сервер просто добавим в правила модуль recent.

    Например правило которое ограничивает поступления DNS запросов типа MX в 5 запросов за 60 секунд будет выглядеть так:
    -A INPUT -p udp --dport 53 -m state --state NEW -m string --algo kmp --hex-string "|00 0F 00 01|" -m recent --set --name MXFLOOD --rsource

    -A INPUT -p udp --dport 53 -m state --state NEW -m string --algo kmp --hex-string "|00 0F 00 01|" -m recent --update --seconds 60 --hitcount 5 --rttl --name MXFLOOD -j DROP

    -A INPUT -p udp --dport 53 -m string --algo kmp --hex-string "|00 0F 00 01|" -j ACCEPT


    Аналогичным образом ограничиваются и другие типы DNS запросов.

    Так как DNS типов существует превеликое множество и мы разрешили все нужные нам типы DNS запросов, то было бы неплохо запретить все остальные запросы чтобы они не обрабатывались вашим DNS сервером.

    -A INPUT -p udp --dport 53 -j DROP


    Данные простейшие правила позволили нам сократить количество одновременных рекурсивных DNS запросов к нашим DNS серверам более чем в 20 раз (c 10000 до 400), без жалоб на работу DNS со стороны наших пользователей.
    Ads
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More

    Comments 46

      0
      хабракат поставьте
        +2
        Спасибо. Поправил.
        0
        Следующим шагом идёт наращивание мощностей самого сервера. Данным методом счастье тоже достигается, но при
        стабильном росте абонентской базы оно быстро заканчивается.

        Мне даже интересно стало, это сколько же у вас народу пользуется DNS и какой у вас рекурсор используется.
          0
          40k пользователей, сейчас стоит штатный bind

          rndc status

          recursive clients: 268/14900/15000
            0
            да, бинд достаточно быстр, работает по алгоритму конечного автомата. У меня 15к обслуживает и проц на 2-3% загружен.
              0
              Как мы все прекрасно понимаем, дело не в пользователях а в их запросах, и в отсутствии штатных средств ограничивать аппетиты конечного пользователя.

              Дело в том, что например в том же bind есть только одна опция которая может быть полезна — ограничение общего количества рекурсивных запросов, но что произойдет с bind-ом когда все эти запросы сделает один клиент? Правильно. Он просто перестанет обрабатывать валидные запросы других клиентов.

              На самом деле это огромная проблема.
                0
                ну, в вашем случае лимит на ip тоже может охреначить большую сетку за NAT-ом или нижестоящий кеш-dns-сервер.
                  0
                  Это ресолвер для клиентов домашнего интернет, т е конечных потребителей. Они все приходят к DNS со своими ip адресами. Если Вам кажется, что будут жалобы из-за слишком жестких лимитов — поправьте их в соответствии с Вашими желаниями :)
                    +1
                    ну да, в инфраструктуре провайдера схема работает отлично, т.к. все клиенты на ладони, никаких сюрпризов.
              0
              Выкиньте bind и возьмите unbound. Без всякого шаманства 4% загрузки CPU на Core 2 Duo. Правда еще память еще любит щас полгига выжирает. Статистика:
              total.num.queries=703792251
              total.num.cachehits=485271820
              total.num.cachemiss=218520431
              total.num.recursivereplies=217160216
              total.requestlist.avg=82.2027
              total.requestlist.max=1222
              total.requestlist.overwritten=1424
              total.requestlist.exceeded=1353691
              total.requestlist.current.all=84
              total.requestlist.current.user=83
              total.recursion.time.avg=15.325532
              total.recursion.time.median=0.0985865

              Порядка 20k клиентов.
                0
                Вы можете ограничить в unbound количество запросов от каждого клиента? Насколько я знаю — нет.

                Вы просто отсрочили ту же самую проблему, когда один клиент со скоростью в 100Мбит/s начинает тупо валить ваш DNS вполне валидными DNS запросами.
                  0
                  ну, тут вам файервол не поможет тоже, если канал забьют.
                    0
                    Вы можете ограничить в unbound количество запросов от каждого клиента? Насколько я знаю — нет.

                    Я не считаю это нужным.

                    когда один клиент со скоростью в 100Мбит/s начинает тупо валить ваш DNS вполне валидными DNS запросами.

                    В случае если такие клиенты есть и они забивают канал ваше решение не поможет. Думаю вы сами можете догадаться почему. А вот использование в качестве рекурсора bind верный путь продолжать вкладывать деньги в конфигурацию машины.
                      0
                      Вы поймите, что абсолютно не Важно какое название у вашего рекурсивного DNS сервера.

                      Если при максимальном количестве запросов к вашему серверу X, любой из Ваших пользователей может сделать X+1 запрос, то название Вашего DNS сервера меня не интересует :)

                        –1
                        А вас при этом не интересует, что ваш метод спасает только от тупняка сервера при такой атаке? И то тупняк возникает из-за использования bind? Ну и собственно что если пакет запроса от клиента пришел и был отброшен на сервере, то проблему DOS атаки по забиванию канала это не решает.
                          +1
                          вам правильно говорят. зачем делать сложные штуки с менеджментом запросов, когда можно сделать простой и реактивный резолвер на почти _любом_ относительно современном железе?

                          вы озадачиваетесь странными вещами, ресурс днс-сервера копеечен. в случае с анбаундом и правильно приложенным напильником вообще можно сказать бесплатен.

                          не понятно зачем что-то ограничивать, если это не мешает и ресурс настолько дешев. ну и конечно как рассказывать абонентам про кончившийся их ресурс днс-запросов и не открывающийся vkontakte.ru. Ж)

                          коли уж сами не можете приготовить годный рекурсер, отдайте абонентам на растерзание какие публичные, например, гугловские.

                          ps: на месте ваших абонентов я бы поднял свой собственный рекурсер с блэкджеком и шл… :)
                            0
                            Классно, вот как раз супер реактивного ресолвера мне то и не хватает для DNS туннелей.

                            Причем денег я вам платить не буду, а буду сидеть вечно в отключенном состоянии и гонять трафик поверх вашего реактивнейшего DNS ресолвера — побольше бы таких администраторов.

                            С чего Вы взяли, что режутся валидные DNS запросы? Мне кажется, что для домашнего клиента 100 запросов типа A за 10 секунд более чем достаточно.
                              +1
                              я вас умаляю, днс-туннеленг был актуалет наверно годы назад, когда интернет еще был медленным, дорогим и помегобайтным… но в те славные времена только особо отмороженные делали трафик до днс-сервера бесплатным. :)

                              а нынче цены вопроса 8 мегабит даже в моей деревне гроши, пускай и не гарантированных 8 мегабит. кому оно надо то возиться с днс-туннелингом?

                              >С чего Вы взяли, что режутся валидные DNS запросы?

                              а как вы отличаете валидные/невалидные? в статье вы всего лишь по оффсету определяете _тип_ запроса.

                              >Мне кажется, что для домашнего клиента 100 запросов типа A за 10 секунд более чем достаточно.

                              100 запросов за 10 секунд? т.е. 10 запросов в секунду? ) ну может быть. однако, днс-туннелинг слабый аргумент в пользу этих танцев :) может лучше вообще каждому клиенту ставить свой рекурсер, рас уж такая параноя о днс-туннелях пошла Ж)
                +1
                >> Пока IPv6 распространён не сильно, можно оставить данный тип запросов к нашему DNS серверу, ограничив двумя запросами в 10 секунд от каждого из клиентов, чтобы пустые запросы типа AAAA localhost. не влияли на работу DNS сервера.

                Вот от таких решений и задерживается введение IPv6.
                «Пока» у горе-админов это = «пока петух в жопу не клюнет».
                Начитаются и забудут же, а потом будут кричать что IPv6 плохой и глючный.
                  0
                  Я не говорю что IPv6 это плохо, IPv6 это хорошо, можно и красиво, но десятки клиентов которые «ложат» Ваш DNS сервер запросами типа AAAA? localhost. это действительно плохо.

                  Я не предлагаю убивать IPv6 я предлагаю вводить адекватные ограничения на использование DNS запросов определенных типов.

                  P.S. спасибо, что дочитали статью хотя бы до этого момента.
                    +3
                    Трафик то все равно будет идти, ответ на такой запрос у нормального рекурсора использует меньше ресурсов чем правило iptables.
                    P.S. Статью я прочитал полностью. Местами по делу, но местами очень спорно.
                      0
                      Не правда, проще дропнуть пакет, чем отдать его на обработку приложению и потом отдавать ответ клиенту.

                      iptables + recent наиболее быстрое решение для подобных задач, recent вообще работает поразительно быстро и не оказывает существенной нагрузки на CPU в отличии от connlimit.

                        +1
                        Просто эта нагрузка идет на уровне ядра.
                        Потом очень печально смотреть на сервера настроенные подобным образом когда после отключения iptables хоть и повышается трафик, но сервер перестает залипать на 50-70мс при запросах.
                        Трафика от АААА запросов мизер.
                  +7
                  > Запись SRV (server selection) указывает на серверы для сервисов. Данный тип запросов может использоваться пользователями домашнего интернет только в целях отладки, разрешим каждому клиенту делать 5 запросов за 60 секунд.

                  Вообще-то данные запросы направляют Jabber-клиенты.
                    +3
                    И SIP, да…
                      0
                      и это только самые популярные сервисы. На самом деле даже exim давно позволяет искать почтовые сервера не по МХ, а по SRV-записям (признаю, по умолчанию это отключено), так что область применения SRV в статье явно недооценена.
                        0
                        И это правильно, ибо позволяет делать балансировку нагрузки. Недооцененный в-целом протокол. :)
                    +11
                    В статье с громким названием «Производительный рекурсивный DNS сервер» сначала рассказывается, что такое A и MX запись, а потом даются советы как дропать запросы для того что бы «производительный сервер» на упал.

                    Мне одному кажется, что здесь что то неправильно? =)
                      0
                      Вам одному.

                      Проблема в том, что введение адекватных ограничений это единственный метод борьбы с DNS флудом.

                      В большинстве случаев даже завирусованный вусмерть клиент этих ограничений не заметит, а вот спам бот который будет пытаться ресолвить MX, не сможет это делать так быстро, как он этого хочет.
                        +3
                        Вы netflow собираете? думаю, что да. Так почему бы просто не длочить сразу DNS флудеров? За одно будете держать в разумный пределах количество спам ботов (заблоченные подсетки итд).

                        А статью надо было назвать «Как блокировать нежелательный DNS трафик».
                          0
                          По поводу названия погорячился :)

                          Netflow безусловно собирается. Поясните мысль по поводу блокировки на основании netflow.
                            0
                            Смысл в том, что бы на основе netflow генерировать список аккаунтов для блокировки. Можно обращать внимание как на количество DNS запросов, так и на трафик в сторону MX серверов. На основе этих данных разбираться с флудерами (банить, ограничивать, помогать избавиться от ботов).

                            Более конкретно к сожалению не могу, через час на поезд, да и остальное надо смотреть на конкретных реализациях сети.
                      +1
                      «Запись SRV (server selection) указывает на серверы для сервисов. Данный тип запросов может использоваться пользователями домашнего интернет только в целях отладки, разрешим каждому клиенту делать 5 запросов за 60 секунд.»

                      Гм… VoIP софтфоны и шлюзы, например, делают SRV запросы далеко не только в целях отладки. Но ограничение вполне достаточно для клиента, да.
                        +4
                        Зачем запрещать dns запросы? клиенты-же всёравно переспросят, и только будут ругаться что интернет медленно работает, нагрузку на сервер ваш способ никак не уменьшает, а даже увеличивает, добавляя нагрузку на работу netfilter и нагрузку на канал(за счёт повторных пакетов)
                        • UFO just landed and posted this here
                            +1
                            conntrack таблица в Linux ограничена размером оперативной памяти и вашей фантазией.

                            Если сетевые адаптеры не реалтек а нормальные Интелы и irq от них раскиданы по различным ядрам, то очень мало вероятно чтобы один клиент подключенный по 100 мбит/с завалил сервер подключеный по гигабиту.
                            –2
                            Все очень просто. Представьте себе клиента компьютер которого рассылает спам, и спам бот постояно обращается к DNS серверу провайдера «долбя» его вопросами типа

                            Где почтовик mail.ru?
                            Где почтовик gmail.ru?
                            Где почтовик yahoo.com?

                            DNS сервер мало того что принимает данные запросы, так он еще и тратит ценные ресурсы отвечая на них. В конечном итоге DNS сервером тратится огромное количество ресурсов на запросы которые генерируются вредноносным ПО.

                            В статье описан метод снижения нагрузки на DNS сервер, неважно какое ПО на нем работает, причем данный метод никак не отражается на работе валидных клиентов.

                              +1
                              Имхо, 99,9% ответов на вопрос «Где почтовик такой-то?» уже будут в кэше вашего днс.
                              Я тоже думаю, что вы пытаетесь экономить на спичках.
                              0
                              Перечитайте статью. Где Вы все увидили ограничение валидных запросов. Ограничение будет только если от клиента идет непрерывный DOS DNS сервера, вот для того чтобы все ресурсы сервера не были исчерпаны одним пользователей и вводятся ограничения. Для j,sxyjuj gjkmpjdfntkz никакой разницы не будет
                              0
                              Я бы добавил еще TXT-запросы — без них SPF не сильно будет работать — а это достаточно действенный способ борьбы со спамом (мы ведь не забываем про своих корпоративных клиентов, да? :)

                              PS 100k клиентов:

                              16:25:34 CPU %user %nice %sys %iowait %irq %soft %steal %idle intr/s
                              16:25:34 all 25,48 0,18 7,99 0,10 0,58 1,35 0,00 64,32 166,34
                              на

                              deb40:~# cat /proc/cpuinfo | grep 'model name'
                              model name: Intel® Xeon(TM) CPU 3.00GHz
                              model name: Intel® Xeon(TM) CPU 3.00GHz
                              model name: Intel® Xeon(TM) CPU 3.00GHz
                              model name: Intel® Xeon(TM) CPU 3.00GHz

                              deb40:~# free -m
                              total used free shared buffers cached
                              Mem: 3043 2590 453 0 19 552
                              -/+ buffers/cache: 2017 1025
                              Swap: 1529 154 1374

                              + на этом же сервере крутится корпоративная почта на 500 человек
                                0
                                Запускать критичный сетевой сервис (DNS) на одной машине с другим сервисом (SMTP) потребление ресурсов сервера которым не ограничено помоему очень плохая идея.
                                0
                                а что, если: запустить два днс-сервера на одном компьютере, один с высоким приоритетом, другой — с низким. клиентов, которые не перегружают сервер запросами, обслуживать на первом, а кто флудит — на втором? в результате хорошие клиенты будут обслуживаться заведомо хорошо, плохие — настолько хорошо, насколько это возможно не в ущерб первой группе
                                  0
                                  Вообще по хорошему хотелось бы иметь DNS Proxy на базе например того же nginx, который может работать с большим количеством backend серверов, и ограничивать количество запросов определенных типов от каждого из клиентов.

                                  Только я не представляю кто сможет взяться и осилить данную задачу.
                                    0
                                    для этой задачи может подойти powerdns
                                  0
                                  Т.е. если у клиента вирус, то вы его фактически отрубаете от ДНС?
                                  Его легитимные запросы не доходят до вашего ДНС и поэтому для него Интернет не работает?
                                  По-моему таким ограничением вы довольным клиента не сделаете.
                                    0
                                    Мне кажется, что сыр бор идет отчасти из-за того, что эффект не отражен должны образом. Я сторонник методов, что плохой админ тот, кто заморачивается из-за 5% производительности.

                                    Мы видим, что «количество одновременных рекурсивных DNS запросов к нашим DNS серверам более чем в 20 раз (c 10000 до 400), без жалоб на работу DNS со стороны наших пользователей. »

                                    Но не видим какие ресурсы стали экономиться на DNS сервере — процессор, память, нагрузка на канал и проч. и на какие величины. Т.е. до и после. Так же не видна насколько нагрузка возросла — из-за дополнительных правил фильтрации. Запросов стало меньше, но правил больше :).

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

                                    Only users with full accounts can post comments. Log in, please.