orlik Опубликовано 5 мая, 2014 · Жалоба А подскажите кто, как борется с флудом на dns сервера от клиентов ? Сейчас вижу множество запросов от клиентов вида mrqber.www.500sf.com. . Причем mrqber - постоянно меняется и время от времени меняется и основной домен 500sf.com. на что-то аналогичное. Интересует вопрос как бороться с подобными запросами , блокировать клиентов не вариант , хотелось бы просто не отвечать на эти запросы (ну и чтоб с сервера не сыпались в сеть ). Можно конечно поднять локально 500sf.com , но это придется отслеживать регулярно меняюзиеся домены, а хотелось бы как-то это автоматизировать ... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alibek Опубликовано 5 мая, 2014 · Жалоба Ну самое простое — лимитировать количество запросов. Помоему в BIND такое есть в конфигурации. Но можно и на уровне файрвола настроить лимиты. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
wtyd Опубликовано 5 мая, 2014 · Жалоба А подскажите кто, как борется с флудом на dns сервера от клиентов ? Сейчас вижу множество запросов от клиентов вида mrqber.www.500sf.com. . Причем mrqber - постоянно меняется и время от времени меняется и основной домен 500sf.com. на что-то аналогичное. Интересует вопрос как бороться с подобными запросами , блокировать клиентов не вариант , хотелось бы просто не отвечать на эти запросы (ну и чтоб с сервера не сыпались в сеть ). Можно конечно поднять локально 500sf.com , но это придется отслеживать регулярно меняюзиеся домены, а хотелось бы как-то это автоматизировать ... Скорее всего это делается через открытые DNS у ваших клиентов. Просканировать свою сеть на предмет публичных ДНС и отключить их на своих ДНС ? :-). Будут звонить, ругаться. Можно не отключать, а сперва предупредить тех, кому не жалко держать у себя паблик ДНС за 300 рублей в месяц на вашей сети (или не знаю, сколько у вас абоненты платят) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
orlik Опубликовано 5 мая, 2014 · Жалоба Ну самое простое — лимитировать количество запросов. Помоему в BIND такое есть в конфигурации. Но можно и на уровне файрвола настроить лимиты. Да у bind есть rate-limit , пробовал включать, но что-то не заметил эффекта. А блокировать на фаерволе не хочется, слишком проблематично, клиенты начнут звонить ... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
terrible Опубликовано 5 мая, 2014 · Жалоба dnsmasq не? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vlad11 Опубликовано 5 мая, 2014 · Жалоба Уведомить клиентов с паблик ДНС и через сутки запретить пакеты на их 53 порт. Пусть используют провайдерский ДНС. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
boco Опубликовано 6 мая, 2014 · Жалоба http://forum.nag.ru/forum/index.php?showtopic=42406&st=120 и далее Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 6 мая, 2014 · Жалоба А подскажите кто, как борется с флудом на dns сервера от клиентов ? Сейчас вижу множество запросов от клиентов вида mrqber.www.500sf.com. . Причем mrqber - постоянно меняется и время от времени меняется и основной домен 500sf.com. на что-то аналогичное. Интересует вопрос как бороться с подобными запросами , блокировать клиентов не вариант , хотелось бы просто не отвечать на эти запросы (ну и чтоб с сервера не сыпались в сеть ). Можно конечно поднять локально 500sf.com , но это придется отслеживать регулярно меняюзиеся домены, а хотелось бы как-то это автоматизировать ... Скорее всего это делается через открытые DNS у ваших клиентов. Просканировать свою сеть на предмет публичных ДНС и отключить их на своих ДНС ? :-). Будут звонить, ругаться. Можно не отключать, а сперва предупредить тех, кому не жалко держать у себя паблик ДНС за 300 рублей в месяц на вашей сети (или не знаю, сколько у вас абоненты платят) это не операторский подход. ваш метод работает когда у вас 50 абонентов и один раз в год начинает флудить и для вас это событие правильных подхода 2: 1. per-customer rate-limit на сервере/фаерволе перед ним 2. запрет udp/53, tcp/53 inbound по умолчанию и открытие через ЛК (первый раз такую фишку увидел у Билайна) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
orlik Опубликовано 6 мая, 2014 · Жалоба На данный момент заблокировал все входящие в сеть рекурсивные запросы ( iptables) пока наблюдаю и думаю что делать дальше Вероятно будем блокировать 53 порт и разблокировать через личный кабинет Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
wtyd Опубликовано 8 мая, 2014 · Жалоба это не операторский подход. ваш метод работает когда у вас 50 абонентов и один раз в год начинает флудить и для вас это событие правильных подхода 2: 1. per-customer rate-limit на сервере/фаерволе перед ним 2. запрет udp/53, tcp/53 inbound по умолчанию и открытие через ЛК (первый раз такую фишку увидел у Билайна) Операторский подход или нет -- это же всё относительно :-). Да, относительно количества абонентов. Вообще, я думал, что ТС работает в ISP с многими тысячами абонентов, но после его ответа про iptables ... :-). Так что все подходы заслуживают внимания. Пока загрузка ДНС сервера в норме, мы не волнуемся, даже если там есть днс-амплификейшн-атак. Если загрузка начинает расти, то стараемся быстро выяснить причины и быстро принять меры. Массового характера эта атака пока не принимала, 10 абонентов одновременно видел, через которых делали эту атаку. В общем, в нашей сети пока нет смысла городить фичу в ЛК или иной "поцанский" подход. В других сетях, вероятно, есть причины так делать из-за массовости явлений -- как вы сказали, у Билайна это сделано. Народ у нас такой -- не будет у него работать порт 53, в следующем месяце он уже не заплатит, исчезнет и молча подключится к другому оператору. Палка о двух концах. Это любых запретов касается. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 12 мая, 2014 · Жалоба wtyd я же не предлагаю закрыть udp/53 out (т.е. запросы к сторонним dns-серверам), а только udp/53 in (к абонентам). у вам много абонентов, которые дома держут auth-dns? щас просто куча всякого говна у абонентов, которые разрешают рекурсию с wan-порта Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
zhenya` Опубликовано 12 мая, 2014 · Жалоба да это ломают роутеры клиентские. в основном дир 300 и подобные и потом они долбят провайдерские днсы. п.с. dnsbl .nts.su экономит проц :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
wtyd Опубликовано 20 мая, 2014 · Жалоба да это ломают роутеры клиентские. в основном дир 300 и подобные и потом они долбят провайдерские днсы. п.с. dnsbl .nts.su экономит проц :) https://github.com/smurfmonitor/dns-iptables-rules -- а тут вон вообще брутальное решение :-). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
hsvt Опубликовано 14 декабря, 2015 (изменено) · Жалоба Разбираюсь с такой же проблемой как в сабже, в списке клиентов около 10 штук с открытым dns резолвером в мир (Router OS, pfsence, etc), закрыл на шлюзе к ним из мира udp/53 in. Осталось тройка, из мира они больше ботам не резолвят, но мусорные запросы такого характера всё равно вижу. Source Query Name Count % cum% -------------- ---------------- --------- ------ ------ my.dns.ip x99moyu.net 473855 35.9 35.9 client.ip x99moyu.net 29402 2.2 38.1 client.ip x99moyu.net 13020 1.0 39.1 client.ip x99moyu.net 7124 0.5 39.6 unbound-control dump_requestlist thread #0 # type cl name seconds module status 0 A IN u1.51dns.com. - iterator wait for 218.66.171.27 1 A IN u2.51dns.com. - iterator wait for 117.25.132.187 2 A IN ns1.reg.cn. - iterator wants A IN u1.51dns.com. A IN u2.51dns.com. 3 A IN ns2.reg.cn. - iterator wait for 203.119.28.1 4 A IN brk.cm. 1.063556 iterator wants A IN ns1.reg.cn. A IN ns2.reg.cn. 5 A IN fvin.x99moyu.net. 0.384564 iterator wait for 173.245.58.146 6 A IN pwwz.x99moyu.net. 0.822173 iterator wait for 173.245.58.146 7 A IN ucus.dls.ucweb.com. 17.579414 iterator wait for 65.255.37.6 8 A IN match.v1.rtb.revcloud.adaos-ads.net. 30.638155 iterator wait for 62.75.239.82 9 A IN cclhvy.x99moyu.net. 5.778976 iterator wait for 173.245.58.146 10 A IN njnawgrr.x99moyu.net. 0.040925 iterator wait for 173.245.58.146 11 A IN wiepkaxssgnsj.x99moyu.net. 2.326662 iterator wait for 173.245.58.146 12 A IN egsencwrtvivia.x99moyu.net. 3.846701 iterator wait for 173.245.58.146 13 A IN jesmsikssgmgve.x99moyu.net. 5.828172 iterator wait for 173.245.58.146 14 A IN ocgmtpvmknccia.x99moyu.net. 4.686485 iterator wait for 173.245.58.146 15 A IN saixxoubislmvp.x99moyu.net. 4.677297 iterator wait for 173.245.58.146 16 A IN spbuwxqtidrlge.x99moyu.net. 0.249721 iterator wait for 173.245.58.146 17 A IN sscaiiydnytbfp.x99moyu.net. 2.848551 iterator wait for 173.245.58.146 18 A IN tmdreamnjprspt.x99moyu.net. 0.255090 iterator wait for 173.245.58.146 19 A IN tpeebrsnytivgj.x99moyu.net. 0.093264 iterator wait for 173.245.58.146 20 A IN wcakoczsgdtvsg.x99moyu.net. 0.992163 iterator wait for 173.245.58.146 21 A IN dzbiayvmefotmhhx.x99moyu.net. 3.775252 iterator wait for 173.245.58.146 22 A IN eprwsrwxuiprkqxv.x99moyu.net. 5.834634 iterator wait for 173.245.59.151 23 A IN fiafgcbygrdgjglp.x99moyu.net. 1.835604 iterator wait for 173.245.59.151 24 A IN kohomtsgzozddavqp.x99moyu.net. 3.087575 iterator wait for 173.245.58.146 16:47:27.838991 IP client.ip.54105 > my.dns.ip.53: 38774+ A? uyyzaaogtvirno.x99moyu.net. (44) 16:47:27.839050 IP client.ip.61898 > my.dns.ip.53: 8811+ A? ozoukn.x99moyu.net. (36) 16:47:27.839200 IP client.ip.49613 > my.dns.ip.53: 9456+ A? eefgwxqocknpvjzx.x99moyu.net. (46) 16:47:27.839496 IP client.ip.63864 > my.dns.ip.53: 48821+ A? ydjlbnspuqyplwfx.x99moyu.net. (46) 16:47:27.839598 IP client.ip.63772 > my.dns.ip.53: 39491+ A? ggmhonoc.x99moyu.net. (38) 16:47:27.839677 IP client.ip.54959 > my.dns.ip.53: 29944+ A? jaxbizmdno.x99moyu.net. (40) 16:47:27.839748 IP client.ip.54959 > my.dns.ip.53: 58452+ A? pbjyvrpmeszhr.x99moyu.net. (43) 16:47:27.839793 IP client.ip.58151 > my.dns.ip.53: 23459+ A? wocbmnmfgumu.x99moyu.net. (42) 16:47:27.839953 IP client.ip.57782 > my.dns.ip.53: 20302+ A? tcrxenid.x99moyu.net. (38) 16:47:27.840134 IP client.ip.61505 > my.dns.ip.53: 15011+ A? uyyzaaogtvirno.x99moyu.net. (44) 16:47:27.840303 IP client.ip.61505 > my.dns.ip.53: 64443+ A? eefgwxqocknpvjzx.x99moyu.net. (46) 16:47:27.840501 IP client.ip.60841 > my.dns.ip.53: 52201+ A? ydjlbnspuqyplwfx.x99moyu.net. (46) 16:47:27.840698 IP client.ip.57929 > my.dns.ip.53: 15214+ A? krgnrijzwk.x99moyu.net. (40) Вопрос, как закрыть остальную тройку? Судя по всему заражены уже сами железки\клиенты раз они по прежнему пытаются обращаться на эти x99moyu и кучу других разных доменов. И судя по dump_requestlist конечная цель это 173.245.58.146 из подсети CloudFare. Все похожие здесь темы по dns ddos уже перечитал. Изменено 14 декабря, 2015 пользователем hsvt Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
avb1987 Опубликовано 14 декабря, 2015 (изменено) · Жалоба Та же фигня, сегодня резко начался DNS-флуд с использованием открытых DNS и доменов test1124.com, lolzq.com и теперь x99moyu.net. Решение - заставлять клиентов закрывать открытые ДНС и лечить свои устройства, или же блокировать им запросы. - Не знаю есть ли в unbound возможность так сделать - в bind можно указать IP с которых нельзя делать запросы. - Если у вас Linux, то можно через iptables установить лимит количества запросов с client.ip - Возможно кто-то, кто также открытый резолвер, использует "client.ip" как резолвер (например из его внутренней сети), а он в свою очередь шлет запросы вам. Изменено 14 декабря, 2015 пользователем avb1987 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Negator Опубликовано 14 декабря, 2015 · Жалоба я же не предлагаю закрыть udp/53 out (т.е. запросы к сторонним dns-серверам), а только udp/53 in (к абонентам). у вам много абонентов, которые дома держут auth-dns? щас просто куча всякого говна у абонентов, которые разрешают рекурсию с wan-порта +1. Посмотрите сами со своего порта. Сделали именно так уже года 2 назад - тепеь никаких проблем и никаких жалоб от клиентов. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
hsvt Опубликовано 16 декабря, 2015 (изменено) · Жалоба Та же фигня, сегодня резко начался DNS-флуд с использованием открытых DNS и доменов test1124.com, lolzq.com и теперь x99moyu.net. Решение - заставлять клиентов закрывать открытые ДНС и лечить свои устройства, или же блокировать им запросы. - Не знаю есть ли в unbound возможность так сделать - в bind можно указать IP с которых нельзя делать запросы. - Если у вас Linux, то можно через iptables установить лимит количества запросов с client.ip - Возможно кто-то, кто также открытый резолвер, использует "client.ip" как резолвер (например из его внутренней сети), а он в свою очередь шлет запросы вам. Вопрос в том, что я задропал dst 53 к абонентам из мира, но осталось парочка абонов через которых всё равно до нас долетает... iptables -A FORWARD -p udp -d client.ip/32 --dport 53 -j DROP iptables -A FORWARD -p tcp -d client.ip/32 --dport 53 -j DROP На них эти правила не действуют, возможно здесь как раз "кто-то" с открытым резолвером еще который использует их. Queries: 242 new, 702940 total Wed Dec 16 14:26:09 2015 Source Query Name Count % cum% -------------- ----------- --------- ------ ------ my.dns.ip x99moyu.net 629271 89.5 89.5 client.ip x99moyu.net 46012 6.5 96.1 client.ip x99moyu.net 27657 3.9 100.0 Изменено 16 декабря, 2015 пользователем hsvt Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...