Homas Sep 1 2014 at 21:26

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

6 min

58K

Information Security*

+39

Comments 45

pavelodintsov Sep 1 2014 at 21:49

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

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

Используйте NSD, друзья! :)

Homas Sep 1 2014 at 22:32

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

tgz Sep 1 2014 at 23:27

В debian аж с апреля прошлого года.
Используйте Debian, друзья! :)

gnomeby Sep 2 2014 at 13:14

Вы ничего не написали про djbdns

pavelodintsov Sep 2 2014 at 13:19

Я просто не знаю, поэтому ничего про него не сказал :)

flx Sep 2 2014 at 16:34

Нужно только помнить что включая RRL без DNSSEC вы делаете задачу с dns poisoning тривиальной

ripe67.ripe.net/presentations/240-ipfragattack.pdf

pavelodintsov Sep 2 2014 at 16:42

Хреново :( Но без RRL явно жизни нету, а отравление кэша можно было сделать и ранее.

Но толку его (dnssec) включать, если почти 99% резолверов его не умеют и просто будут игнорировать?

kukumumu Sep 10 2014 at 11:32

Александр, подскажите пож-та, а как связаны RRL и упрощение атаки DNS IP-фрагментами? Я что-то сходу не соображу :(

flx Sep 10 2014 at 20:57

вы провоцируете ratelimit и получаете задержку между пакетами за которую можно подобрать часть ответа с authority.

iDen Sep 1 2014 at 21:53

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

pavelodintsov Sep 1 2014 at 22:20

Просто не открывайте его в мир и все :) А вот от атак изнутри сети защититься почти нереально, особенно если они низкоскоростные. Unbound/Powerdns recursor умеют рейт лимитинг с ооогромным трудом!

iDen Sep 1 2014 at 22:23

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

Homas Sep 1 2014 at 22:31

Всё просто настраивается через ACL.
Кэширующий DNS и авторитативный для надежности можно разнести на разные машины или виртуалки.
По Bind есть хорошие книги «DNS и BIND» Крикета Ли и Пола Альбитца, где всё подробно расписано.
PDF можно скачать на рутрекере.

Hesed Sep 3 2014 at 10:18

Для 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

Meklon Sep 1 2014 at 22:24

Мне так MikroTik изнасиловали запросами. Я забыл закрыть DNS для внешних адресов, а в результате получил трафик ото всех кого ни лень мегабит на 20. Видимо, мой адрес отвечал быстрее. Адреса преимущественно местные были географически.

Homas Sep 1 2014 at 22:26

Просто нашли раньше и взялись основательно :)

Meklon Sep 1 2014 at 22:30

Было больше похоже на незлонамеренное использование. Как будто где-то проанонсировался у моего провайдера.

Andrewww Sep 2 2014 at 08:20

Аналогично при базовой настройке MikroTik не уследил за этим, и весь канал на 50 Mbps забили довольно быстро…

k0ldbl00d Sep 2 2014 at 10:27

Каждый кто впервые включает опцию «Allow Remote Requests» в RouterOS сталкивается с этим.

Meklon Sep 2 2014 at 11:07

Это был мой первый MikroTik и опция была для меня не совсем очевидна)

kabachok Sep 2 2014 at 00:29

Друзья, а подскажите нормальный сервис для проверки своих днс на уязвимости?

sebres Sep 2 2014 at 00:54

http://www.dnsinspect.com/

ValdikSS Sep 3 2014 at 23:47

Вот сразу видно, человек читает lowendtalk.

sebres Sep 15 2014 at 15:47

возможно, человек просто умеет пользовать google :)
А за lowendtalk спасибо…

pansa Sep 2 2014 at 01:20

> 1. Amplification attack (атака с усилением) — направлена на перегрузку исходящего канала DNS-сервера.
>… что приведет к перегрузке исходящего канала DNS-сервера и в конечном счете к отказу в обслуживании (DoS);

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

Homas Sep 2 2014 at 09:17

Если идет просто Amplification, без Reflection — то именно забивается канал DNS-сервера. Сервер при этом может быть простым авторитативным.

catharsis Sep 2 2014 at 03:46

IP-адреса, которые вы наблюдаете в логах, вероятнее цели reflection-атаки, чем хосты, порождающие трафик.

Homas Sep 2 2014 at 09:30

Это сложно определить. Из просмотренной мной статистики потенциальными жертвами могут быть только серверы 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

Homas Sep 2 2014 at 09:38

И BTW, пока основная жертва это мой DNS :)
За прошедших 12 часов количество поступивших запросов удвоилось (то есть стало более миллиона), но при этом сервер выполнил всего около 4х тысяч рекурсивных запросов.

alexkbs Sep 2 2014 at 08:02

Интересно было бы видеть что атакуют через ваш сервер.

Ещё можно было бы сделать фильтр ответов, чтобы, например, с вашего сервера уходило не более одного ответа на рекурсивный запрос в час в адрес одного IP. Таким образом сервер всё ещё будет открытым и рекурсивным. Это означает что его нельзя будет практически использовать для атаки, но можно будет использовать для отслеживания целей атакующих. При этом сами атакующие не будут знать что ваш сервер не работает на атаку.

Homas Sep 2 2014 at 09:36

Как я написал в посте выше, определить жертву достаточно сложно. Фактически нужно «пробивать» какждый IP, смотреть какие потенциально интересные сервисы могут находится на данном сервере и в данной сети. И даже в этом случае нет 100% гарантии, что была найдена именно жертва.

alexkbs Sep 2 2014 at 10:38

Покажите список IP, а добровольцы-читатели пробьют и выяснят, что и где чьё.

Homas Sep 2 2014 at 10:52

Вот вчерашний файл файл.
Формат: Client IP (DNS имя||Информация Whois) — Количество запросов.
За ночь пришло очень много запросов (т.е. атака усилилась).

axeax Sep 2 2014 at 08:40

интернет не совершенен

pavelodintsov Sep 2 2014 at 10:46

Скорее люди несовершенны. А Интернет вполне чинится хорошо написанным ПО, в котором учтены подобные проблемы :)

Homas Sep 2 2014 at 10:54

Сразу сложно создать идеального сферического коня в вакууме :)
Пример — DNSSEC. Затыкали одну дыру, а получили другую :)

pavelodintsov Sep 2 2014 at 11:27

Почему сферического? Про проблемы с DNS усилением известно уже года 3, но производителия DNS почему-то в упор не видят ее. Точнее нет, скажем иначе — пользователи не видят в этом проблемы. На удивление, в том же PowerDNS даже не заведено issue на тему «а как вы живете вообще без RRL????»

Homas Sep 2 2014 at 11:53

Я говорю немного о другом. Создавая любой продукт не возможно сразу оценить все аспекты легитимного и нелегитимного его использования. То что дыры могут не замечаться/не закрываться годами — это другой вопрос.
Надеюсь, эта статья донесет до продвинутых пользователей эту проблему. :)

swanrnd Sep 2 2014 at 11:41

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

По умолчанию это открыто. В документациях редко это выделяется красной рамочкой и жирным шрифтом.

flx Sep 2 2014 at 17:55

Рекомендую вот эту бумажку про скорострельность почитать:
www.slideshare.net/andreyleskin14/highload2013dns032

Homas Sep 2 2014 at 18:01

Используя dnsperf можно протестировать производительность своего DNS-сервера, лучше это делать без полезной нагрузки :)

flx Sep 3 2014 at 19:35

вы, очевидно не обратили внимание на значения оси Y где отмечен RPS…

dnsperf так не умеет %)

Homas Sep 3 2014 at 20:05

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

PS Были бы данные — графики любые красивые нарисовать :)

la0 Sep 2 2014 at 22:06

Вон нормальные VDS провайдеры (провайдеры дедиков, тоже должны озаботиться, но им менее критично) уже автоматически сканируют свои IP на эту дырочку и уведомляют пользователя (а при долгом непонимании режут 53 порт).
Как знаю как минимум три таких ( и, что характерно, они выгодно выделяются на фоне остальных по стабильности работы сервиса).

Hesed Sep 3 2014 at 10:22

Не только VDS, в Латвии организация CERT уведомляет (и ненавязчиво обязывает) всех провайдеров закрывать рекурсивные DNS. А в последнее время просят и бесконтрольные NTP.