Насколько опасен открытый рекурсивный DNS-сервер?



        Неоспоримо, что «выставляя сервер» в интернет необходимо позаботиться о его безопасности и максимально ограничить доступ к нему. Протокол DNS может использоваться как для атак на инфраструктуру (DNS сервер, канал) жертвы, так и для атаки на другие компании. За последний год количество таких атак увеличилось как минимум в 2 раза. На сайте digitalattackmap.com, который визуализирует DDoS атаки, DNS выделен из общего списка наравне с атаками на Web(80/443).

        Сервис DNS работает (в основном) по протоколу UDP, который не предполагает предварительной установки соединения, поэтому его без проблем можно использовать для атак на другие серверы (spoofing) без специальной подготовки. По информации из разных источников1,2 на текущий момент от 8 до 20 миллионов DNS серверов отвечают на рекурсивные запросы. Это могут быть как неправильно настроенные авторитативные и кэширующие DNS-серверы, так и простые CPE.

        Меня заинтересовало, насколько опасно (для себя и окружающих) держать открытый рекурсивный DNS сервер, поэтому я решил провести небольшое исследование.


    Постановка задачи


        Были сформулированы следующие вопросы, на которые хотелось бы получить ответы:
    1. Как быстро будет обнаружен открытый рекурсивный DNS сервер;
    2. Когда начнут использовать сервер в нелегальных целях;
    3. Определить нагрузку на сервер (количество запросов в секунду);
    4. Попытаться определить на какие организации нацелены атаки;
    5. Будут ли запрашиваться скомпрометированные (содержащиеся в черных списках) домены и/или IP-адреса.

        Для тестирования используется сервер установленный в нюрнбергском дата-центре Hetzner. На данном сервере ранее был расположен авторитативный DNS-сервер, количество запросов к которому не превышало 200 в сутки. IP адрес сервера (в связи с переездом на новое АО) изменялся в июле. Для проверки доменов использовался механизм RPZ (response policy zone) и черный список от компании Infoblox.

    Немного теории


        Для осуществления атак через DNS-сервер используются следующие принципы:
    1. DNS работает по протоколу UDP, поэтому атакующий может подменить свой IP-адрес на адрес жертвы;
    2. DNS-запросы ассиметричны, ответный трафик может превышать входящий в несколько раз.

        На основании этих принципов этого можно выделить следующие виды атак с использованием DNS:
    1. Amplification attack (атака с усилением) — направлена на перегрузку исходящего канала DNS-сервера. Она начинаются с отправки большого количества DNS-запросов, специально подобранных таким образом, чтобы получить очень большой ответ, размер которого может до 70 раз превышать размер запроса, что приведет к перегрузке исходящего канала DNS-сервера и в конечном счете к отказу в обслуживании (DoS);
    2. Reflection attack (атака с отражением) — используются сторонние DNS-серверы (например мой) для распространения DoS- или DDoS-атаки путем отправки большого количества запросов. При такой атаке адрес, с которого отправляются DNS-запросы, подменяется IP-адресом жертвы, и запрос будет иметь данные сервера жертвы, а не атакующего. В результате, когда сервер имен будет получать запросы, он будет отправлять все ответы на IP-адрес жертвы. Большой объем такого «отраженного» трафика может вывести из строя сервер/сеть жертвы;
    3. Distributed reflection DoS (DrDoS) — сочетает в себе атаки отражения и усиления, что значительно увеличивает вероятность нарушения работоспособности сервера жертвы. При этом DNSSEC, разработанный специально для защиты ответов DNS и предотвращения «отравления» кэша, могут сделать атаки такого типа еще более эффективными, поскольку увеличивается размер сообщений DNS. Усиление может доходить до 100 крат, а атакующие могут использовать сети botnet — в которые могут входить тысячи компьютеров.

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

    Результаты исследования


        За неделю всего поступило 416 тысяч запросов на 63 домена от 1169 клиентов, что свидетельствует об успешном проведении исследования и важности данной темы.
        Ниже приведен график количества запросов к DNS-серверу в секунду.

        Прежде всего, ответим на поставленные вопросы:
    1. Как быстро будет обнаружен открытый рекурсивный DNS сервер;
      Первый запрос пришел из Китая через 1 час 20 минут на домен www.google.it
    2. Когда начнут использовать сервер в нелегальных целях;
      Через 1 сутки (первый маленький всплеск на графике) началось периодическое использование сервера для атак. За 30 минут было получено 300 запросов к домену webpanel.sk. Постепенно количество запросов и продолжительность атак увеличивалась.
    3. Определить нагрузку на сервер (количество запросов в секунду);
      В момент проведения атак сервер испытывал максимальную нагрузку 2-4 запроса в секунду. В последний день тестирования количество запросов резко увеличилось до 20 запросов в секунду. Применялась атака DNS Amplification, комбинировалась ли она с DNS Reflection определить достаточно трудно.
    4. Попытаться определить, на какие организации нацелены атаки:


      Количество запрашиваемых доменов было невелико, поэтому выделить потенциальных жертв и домены, используемые исключительно для атак, было просто.
      — Министерство труда США, домен doleta.gov, используют DNSSEC, ответ сервера около 4 Кб, 127 тысяч запросов. Распределение количества запросов по клиентам достаточно ровное, TOP10 расположены в разных странах по всему миру (Южная и Северная Америка, Австралия и Новая Зеландия, Европа);
      — Компания в Словакии, домен webpanel.sk, используют DNSSEC, ответ сервера около 4 Кб – 162 тысячи запросов (большая часть запросов пришла в день составления статьи, цифры постоянно увеличиваются). dnsamplificationattacks.blogspot.ru подозревает, что данный домен используется исключительно для DNS-amplification атак. На самом деле ответы данного сервера не отличаются от любых других серверов, которые используют DNSSEC. Большое количество запросов приходит с серверов немецкого хостинга, российского игрового хостинга и некоторых клиентов в США;
      — Агентство защиты окружающей среды США, домен energystar.gov, используют DNSSEC, ответ сервера около 4 Кб – 79 тысяч запросов. Всего домен запрашивало 69 клиентов большая часть которых расположена в USA. 18 тысяч запросов было получено с игрового сервера Royal Empire. Так как на сервере нет пользователей, и в новостях указано, что beta в режиме онлайн с 11.07.2014, можно предположить, что данный сервер был взломан. Были замечены IP-адреса из сетей Qwerty и Microsoft.
      — FamiNetwork, домен famicraft.com, 7.5 тысяч запросов. Домен содержал бессмысленные TXT записи «wowowow» в результате чего ответ сервера достигал 4кб (50 кратное усиление атаки). В процессе написания статьи, я обнаружил, что ответ сервера famicraft.com изменился и он больше не представляет угрозы. Скорее всего владелец домена обнаружил взлом и внес необходимые исправления. Запросы приходили с 4х серверов, два из которых принадлежат Akamai Technologies (5 тысяч запросов);
      — 14 серверов Akamai Technologies были замечены в подозрительной активности по всем вышеперечисленным доменам, возможно это атака на Akamai или их серверы были взломаны;
      — В TOP10 по количеству входящих запросов (30% от всего количества запросов) попали: немецкий хостинг (по иронии предоставляющий защиту от DDoS), игровой хостинг (российский), игровой сервер, два сервера Akamai. Скорее всего, данные серверы были взломаны, а остальные клиенты входят в botnet`ы.
    5. Будут ли запрашиваться скомпрометированные домены.
      Нет. За всё время тестирования был заблокирован только один домен (ballsack.pw) по IP-адресу 104.28.0.111. Причину блокировки можно посмотреть на сервере ThreatStop (http://threatstop.com/checkip). В принципе, это логично, так как botnet/malware через внешний рекурсивный DNS-сервер осуществляет атаки, а подключение и получение команд с управляющего центра происходит при инициализации, и для этого используется рекурсивный DNS-сервер провайдера.

    В ходе анализа лог-файлов было выявлены:
    1. домены, которые были созданы и/или взломаны для проведения DDoS атак: jerusalem.netfirms.com (выдает большое количество А-записей) и famicraft.com (описан выше). Ответ от этих DNS серверов составляет 4 Кб, то есть при использовании данных можно добиться 50 кратной перегрузки исходящего канала (на графике желтый цвет);

    2. организаций, которые активно осуществляют мониторинг открытых рекурсивных DNS-серверов:
      www.openresolverproject.org;
      dnsscan.shadowserver.org;
      — поступило несколько запросов на домен openresolvertest.net, но на веб-сайте никакой информации нет.


    Открытые рекурсивные DNS-серверы


        Сервис dnsscan.shadowserver.org насчитывает 8 миллионов открытых рекурсивных DNS-серверов. Больше всего таких систем расположено в Китае, Россия расположилась на почетном 6 месте.
    Country Total
    China 2,886,523
    United States 662,593
    Korea, Republic of 591,803
    Taiwan 449,752
    Brazil 339,416
    Russian Federation 264,101

        Интересно графическое представление распределения DNS-серверов по странам, как открытых рекурсивных, так и авторитативных.



    Выводы


        Исходя из полученных результатов можно сделать следующие очевидные выводы:
    1. Необходимо ограничивать доступ ко всем ресурсам сервера, а в частности к рекурсивному DNS-серверу;
    2. Необходимо постоянно отслеживать загрузку DNS-сервера и канала данных. Резкое увеличение нагрузки может свидетельствовать как об осуществлении DDoS атаки, так и о взломе сервера;
    3. При использовании DNSSEC необходимо разумно ограничивать количество поступающих запросов (rate limit);
    4. Проверьте свой CPE на доступ к DNS через WAN интерфейс;
    5. Провайдерам имеет смысл принудительно ограничивать доступ из Internet к рекурсивным DNS-серверам клиентов.

        Сначала я предполагал завершить тестирование уже через неделю, но с учетом значительного роста нагрузки (с 2 до 20 QPS) в последний день тестирования, я решил продлить исследование ещё на неделю.

        Список источников:
    1. www.openresolverproject.org
    2. dnsscan.shadowserver.org
    3. www.digitalattackmap.com

    (с) Vadim Pavlov
    Share post

    Similar posts

    Comments 45

      +8
      Выводы к статье должны звучать примерно так.

      Если Вы используете PowerDNS, то вы беззащитны, он не имеет защиты от атаки на усиление (any-to-tcp не в счет)
      Если Вы используете маломальски стабильный дистрибутив и Bind, то Вы не защищены — только в самых новых версиях Bind добавлена поддержка RRL.
      Если Вы используете NSD и настроили RRL — Вы в полной безопасности и никому не испортите жизнь :)

      Используйте NSD, друзья! :)
        0
        На самом деле основной совет состоит в том, что нужно закрывать все неиспользуемые дыры, не важно какой софт.
          +5
          В debian аж с апреля прошлого года.
          Используйте Debian, друзья! :)
            0
            Вы ничего не написали про djbdns
              0
              Я просто не знаю, поэтому ничего про него не сказал :)
              0
              Нужно только помнить что включая RRL без DNSSEC вы делаете задачу с dns poisoning тривиальной

              ripe67.ripe.net/presentations/240-ipfragattack.pdf
                0
                Хреново :( Но без RRL явно жизни нету, а отравление кэша можно было сделать и ранее.

                Но толку его (dnssec) включать, если почти 99% резолверов его не умеют и просто будут игнорировать?
                  0
                  Александр, подскажите пож-та, а как связаны RRL и упрощение атаки DNS IP-фрагментами? Я что-то сходу не соображу :(
                    0
                    вы провоцируете ratelimit и получаете задержку между пакетами за которую можно подобрать часть ответа с authority.
                +1
                Подкинули бы что ли пару статеек с примерами конфигураций.
                Скоро собираюсь в своем небольшом ISP поднимать DNS для подписчиков.
                Очень был бы рад посмотреть на примеры конфигураций.
                  +1
                  Просто не открывайте его в мир и все :) А вот от атак изнутри сети защититься почти нереально, особенно если они низкоскоростные. Unbound/Powerdns recursor умеют рейт лимитинг с ооогромным трудом!
                    0
                    в мир конечноже нет. только для своих сабнетов.
                    а как быть с тем что у меня есть хостинг на пару сайтов и ДНС должен быть открыт для них наружу?
                    какими параметрами обычный пользовательские запросы отделить от авторитивных? у меня Bind
                      0
                      Всё просто настраивается через ACL.
                      Кэширующий DNS и авторитативный для надежности можно разнести на разные машины или виртуалки.
                      По Bind есть хорошие книги «DNS и BIND» Крикета Ли и Пола Альбитца, где всё подробно расписано.
                      PDF можно скачать на рутрекере.
                    +1
                    Для Bind используйте view.
                    Таким образом можно один сервер использовать, как authoritative для своих SOA и рекурсивный для клиентов.
                    Пример для Bind
                    acl internal {
                        172.16.0.0/12;
                        192.168.0.0/16;
                    };
                    
                    acl bogon {
                        0.0.0.0/8;
                        224.0.0.0/3;
                    };
                    
                    options {
                        blackhole {
                             bogon;
                        };
                        /* остальная часть конфигурации */
                    };
                    
                    view "internal" {
                        match-clients {
                                internal;
                        };
                        recursion yes;
                        /* остальная часть конфигурации */
                    };
                    
                    view "external" {
                        match-clients {
                                any;
                        };
                        recursion no;
                        /* остальная часть конфигурации */
                    };
                    



                    Для Unbound (предполагаю, что для клиентов нужен рекурсивный DNS) используйте директиву access-control.
                    Если нужен ещё и authoritative сервер, но одним комментарием тут не отделаешься, но копать надо будет в сторону stub-zone и forward-zone.
                    Пример для Unbound
                    server:
                        access-control: 172.16.0.0/12 allow
                        access-control: 192.168.0.0/16 allow
                        access-control: 0.0.0.0/8 refuse
                        access-control: 224.0.0.0/3 refuse
                    

                    0
                    Мне так MikroTik изнасиловали запросами. Я забыл закрыть DNS для внешних адресов, а в результате получил трафик ото всех кого ни лень мегабит на 20. Видимо, мой адрес отвечал быстрее. Адреса преимущественно местные были географически.
                      0
                      Просто нашли раньше и взялись основательно :)
                        0
                        Было больше похоже на незлонамеренное использование. Как будто где-то проанонсировался у моего провайдера.
                        0
                        Аналогично при базовой настройке MikroTik не уследил за этим, и весь канал на 50 Mbps забили довольно быстро…
                          0
                          Каждый кто впервые включает опцию «Allow Remote Requests» в RouterOS сталкивается с этим.
                            0
                            Это был мой первый MikroTik и опция была для меня не совсем очевидна)
                          0
                          Друзья, а подскажите нормальный сервис для проверки своих днс на уязвимости?
                            +2
                              0
                              Вот сразу видно, человек читает lowendtalk.
                                0
                                возможно, человек просто умеет пользовать google :)
                                А за lowendtalk спасибо…
                            0
                            > 1. Amplification attack (атака с усилением) — направлена на перегрузку исходящего канала DNS-сервера.
                            >… что приведет к перегрузке исходящего канала DNS-сервера и в конечном счете к отказу в обслуживании (DoS);

                            Эээ… Разве DNS amplification направлена на вывод из строя (канала) DNS? o_0 Я всегда считал, что это просто способ усиления «мощности» атаки. Что, собственно, и следует из её названия.

                              0
                              Если идет просто Amplification, без Reflection — то именно забивается канал DNS-сервера. Сервер при этом может быть простым авторитативным.
                              0
                              IP-адреса, которые вы наблюдаете в логах, вероятнее цели reflection-атаки, чем хосты, порождающие трафик.
                                0
                                Это сложно определить. Из просмотренной мной статистики потенциальными жертвами могут быть только серверы Akamai.
                                В других случаях (судя по DNS-имени, отсутствию сервисов за данным IP) это скорее всего простые абоненты интернет или взломанные серверы.
                                Например, сервер, от которого приходило больше всего запросов находится в немецком датацентре.
                                Этот сервер по HTTP радостно сообщает «It works», другие хосты из этой сети не были замечены. Так что скорее всего этот сервер просто поломали и именно с него идет паразитный трафик.

                                Вот TOP10:
                                Client: 73.44.189.65( || country: US, city: Mount Laurel, org: Comcast IP Services, L.L.C., cust: ) — 7203
                                Client: 69.31.20.75( || country: US, city: Cambridge, org:, cust: Akamai Technologies_data) — 8085
                                Client: 69.31.20.78( || country: US, city: Cambridge, org:, cust: Akamai Technologies_data) — 10623
                                Client: 192.99.201.56(ns501419.ip-192-99-201.net || country: CA, city: Montreal, org: OVH Hosting, Inc., cust: ) — 11673
                                Client: 173.50.175.84(pool-173-50-175-84.pghkny.fios.verizon.net || country: US, city: Ashburn, org: Verizon Online LLC, cust: ) — 12085
                                Client: 193.26.217.18(n18.serva4ok.ru || country: RU, city:, org:, cust: ) — 12132
                                Client: 67.48.118.214(mta-67-48-118-214.natsoe.res.rr.com || country: US, city: Herndon, org: Time Warner Cable Internet LLC, cust: ) — 15217
                                Client: 74.105.36.217(pool-74-105-36-217.nwrknj.fios.verizon.net || country: US, city: Ashburn, org: Verizon Online LLC, cust: ) — 15781
                                Client: 46.105.100.157(ns320483.ip-46-105-100.eu || country: FR, city:, org:, cust: ) — 18175
                                Client: 178.33.27.179(xeo454.serverkraft.de || country: DE, city:, org:, cust: ) — 31452
                                  0
                                  И BTW, пока основная жертва это мой DNS :)
                                  За прошедших 12 часов количество поступивших запросов удвоилось (то есть стало более миллиона), но при этом сервер выполнил всего около 4х тысяч рекурсивных запросов.
                                0
                                Интересно было бы видеть что атакуют через ваш сервер.

                                Ещё можно было бы сделать фильтр ответов, чтобы, например, с вашего сервера уходило не более одного ответа на рекурсивный запрос в час в адрес одного IP. Таким образом сервер всё ещё будет открытым и рекурсивным. Это означает что его нельзя будет практически использовать для атаки, но можно будет использовать для отслеживания целей атакующих. При этом сами атакующие не будут знать что ваш сервер не работает на атаку.
                                  0
                                  Как я написал в посте выше, определить жертву достаточно сложно. Фактически нужно «пробивать» какждый IP, смотреть какие потенциально интересные сервисы могут находится на данном сервере и в данной сети. И даже в этом случае нет 100% гарантии, что была найдена именно жертва.
                                    0
                                    Покажите список IP, а добровольцы-читатели пробьют и выяснят, что и где чьё.
                                      0
                                      Вот вчерашний файл файл.
                                      Формат: Client IP (DNS имя||Информация Whois) — Количество запросов.
                                      За ночь пришло очень много запросов (т.е. атака усилилась).
                                  0
                                  интернет не совершенен
                                    0
                                    Скорее люди несовершенны. А Интернет вполне чинится хорошо написанным ПО, в котором учтены подобные проблемы :)
                                      0
                                      Сразу сложно создать идеального сферического коня в вакууме :)
                                      Пример — DNSSEC. Затыкали одну дыру, а получили другую :)
                                        0
                                        Почему сферического? Про проблемы с DNS усилением известно уже года 3, но производителия DNS почему-то в упор не видят ее. Точнее нет, скажем иначе — пользователи не видят в этом проблемы. На удивление, в том же PowerDNS даже не заведено issue на тему «а как вы живете вообще без RRL????»
                                          +1
                                          Я говорю немного о другом. Создавая любой продукт не возможно сразу оценить все аспекты легитимного и нелегитимного его использования. То что дыры могут не замечаться/не закрываться годами — это другой вопрос.
                                          Надеюсь, эта статья донесет до продвинутых пользователей эту проблему. :)
                                    0
                                    У меня была раньше открыта. Написали абузу провайдеру. Тогда я узнал, что бывает такая проблема.

                                    По умолчанию это открыто. В документациях редко это выделяется красной рамочкой и жирным шрифтом.
                                      0
                                      Рекомендую вот эту бумажку про скорострельность почитать:
                                      www.slideshare.net/andreyleskin14/highload2013dns032
                                        0
                                        Используя dnsperf можно протестировать производительность своего DNS-сервера, лучше это делать без полезной нагрузки :)
                                          0
                                          вы, очевидно не обратили внимание на значения оси Y где отмечен RPS…

                                          dnsperf так не умеет %)
                                            0
                                            Обычного администратора должна волновать производительность его сервера (комбинация железа и софта) — это можно сделать с помощью dnsperf.
                                            А данное исследование нужно использовать для того что бы выбрать подходящий софт на этапе установки по производительности и фитчам.

                                            PS Были бы данные — графики любые красивые нарисовать :)
                                        +1
                                        Вон нормальные VDS провайдеры (провайдеры дедиков, тоже должны озаботиться, но им менее критично) уже автоматически сканируют свои IP на эту дырочку и уведомляют пользователя (а при долгом непонимании режут 53 порт).
                                        Как знаю как минимум три таких ( и, что характерно, они выгодно выделяются на фоне остальных по стабильности работы сервиса).
                                          0
                                          Не только VDS, в Латвии организация CERT уведомляет (и ненавязчиво обязывает) всех провайдеров закрывать рекурсивные DNS. А в последнее время просят и бесконтрольные NTP.

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