@Homas1 сен 2014 в 17:26

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

6 мин

59K

Информационная безопасность *

+38

Комментарии 45

@pavelodintsov 1 сен 2014 в 17:49

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

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

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

@Homas 1 сен 2014 в 18:32

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

@tgz 1 сен 2014 в 19:27

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

@gnomeby 2 сен 2014 в 09:14

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

@pavelodintsov 2 сен 2014 в 09:19

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

@flx 2 сен 2014 в 12:34

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

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

@pavelodintsov 2 сен 2014 в 12:42

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

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

@kukumumu 10 сен 2014 в 07:32

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

@flx 10 сен 2014 в 16:57

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

@iDen 1 сен 2014 в 17:53

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

@pavelodintsov 1 сен 2014 в 18:20

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

@iDen 1 сен 2014 в 18:23

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

@Homas 1 сен 2014 в 18:31

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

@Hesed 3 сен 2014 в 06: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 1 сен 2014 в 18:24

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

@Homas 1 сен 2014 в 18:26

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

@Meklon 1 сен 2014 в 18:30

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

@Andrewww 2 сен 2014 в 04:20

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

@k0ldbl00d 2 сен 2014 в 06:27

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

@Meklon 2 сен 2014 в 07:07

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

@kabachok 1 сен 2014 в 20:29

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

@sebres 1 сен 2014 в 20:54

http://www.dnsinspect.com/

@ValdikSS 3 сен 2014 в 19:47

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

@sebres 15 сен 2014 в 11:47

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

@pansa 1 сен 2014 в 21:20

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

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

@Homas 2 сен 2014 в 05:17

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

@catharsis 1 сен 2014 в 23:46

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

@Homas 2 сен 2014 в 05: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 2 сен 2014 в 05:38

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

@alexkbs 2 сен 2014 в 04:02

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

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

@Homas 2 сен 2014 в 05:36

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

@alexkbs 2 сен 2014 в 06:38

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

@Homas 2 сен 2014 в 06:52

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

@axeax 2 сен 2014 в 04:40

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

@pavelodintsov 2 сен 2014 в 06:46

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

@Homas 2 сен 2014 в 06:54

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

@pavelodintsov 2 сен 2014 в 07:27

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

@Homas 2 сен 2014 в 07:53

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

@swanrnd 2 сен 2014 в 07:41

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

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

@flx 2 сен 2014 в 13:55

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

@Homas 2 сен 2014 в 14:01

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

@flx 3 сен 2014 в 15:35

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

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

@Homas 3 сен 2014 в 16:05

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

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

@la0 2 сен 2014 в 18:06

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

@Hesed 3 сен 2014 в 06:22

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

Зарегистрируйтесь на Хабре, чтобы оставить комментарий