Jump to content
Калькуляторы

dns flood от клиентов

А подскажите кто, как борется с флудом на dns сервера от клиентов ?

Сейчас вижу множество запросов от клиентов вида mrqber.www.500sf.com. . Причем mrqber - постоянно меняется и время от времени меняется и основной домен 500sf.com. на что-то аналогичное. Интересует вопрос как бороться с подобными запросами , блокировать клиентов не вариант , хотелось бы просто не отвечать на эти запросы (ну и чтоб с сервера не сыпались в сеть ). Можно конечно поднять локально 500sf.com , но это придется отслеживать регулярно меняюзиеся домены, а хотелось бы как-то это автоматизировать ...

Share this post


Link to post
Share on other sites

Ну самое простое — лимитировать количество запросов.

Помоему в BIND такое есть в конфигурации.

Но можно и на уровне файрвола настроить лимиты.

Share this post


Link to post
Share on other sites

А подскажите кто, как борется с флудом на dns сервера от клиентов ?

Сейчас вижу множество запросов от клиентов вида mrqber.www.500sf.com. . Причем mrqber - постоянно меняется и время от времени меняется и основной домен 500sf.com. на что-то аналогичное. Интересует вопрос как бороться с подобными запросами , блокировать клиентов не вариант , хотелось бы просто не отвечать на эти запросы (ну и чтоб с сервера не сыпались в сеть ). Можно конечно поднять локально 500sf.com , но это придется отслеживать регулярно меняюзиеся домены, а хотелось бы как-то это автоматизировать ...

 

Скорее всего это делается через открытые DNS у ваших клиентов. Просканировать свою сеть на предмет публичных ДНС и отключить их на своих ДНС ? :-). Будут звонить, ругаться. Можно не отключать, а сперва предупредить тех, кому не жалко держать у себя паблик ДНС за 300 рублей в месяц на вашей сети (или не знаю, сколько у вас абоненты платят)

Share this post


Link to post
Share on other sites

Ну самое простое — лимитировать количество запросов.

Помоему в BIND такое есть в конфигурации.

Но можно и на уровне файрвола настроить лимиты.

 

Да у bind есть rate-limit , пробовал включать, но что-то не заметил эффекта. А блокировать на фаерволе не хочется, слишком проблематично, клиенты начнут звонить ...

Share this post


Link to post
Share on other sites

Уведомить клиентов с паблик ДНС и через сутки запретить пакеты на их 53 порт. Пусть используют провайдерский ДНС.

Share this post


Link to post
Share on other sites

А подскажите кто, как борется с флудом на 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 по умолчанию и открытие через ЛК (первый раз такую фишку увидел у Билайна)

Share this post


Link to post
Share on other sites

На данный момент заблокировал все входящие в сеть рекурсивные запросы ( iptables) пока наблюдаю и думаю что делать дальше

 

Вероятно будем блокировать 53 порт и разблокировать через личный кабинет

Share this post


Link to post
Share on other sites

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

 

правильных подхода 2:

1. per-customer rate-limit на сервере/фаерволе перед ним

2. запрет udp/53, tcp/53 inbound по умолчанию и открытие через ЛК (первый раз такую фишку увидел у Билайна)

 

Операторский подход или нет -- это же всё относительно :-). Да, относительно количества абонентов. Вообще, я думал, что ТС работает в ISP с многими тысячами абонентов, но после его ответа про iptables ... :-). Так что все подходы заслуживают внимания.

 

Пока загрузка ДНС сервера в норме, мы не волнуемся, даже если там есть днс-амплификейшн-атак. Если загрузка начинает расти, то стараемся быстро выяснить причины и быстро принять меры. Массового характера эта атака пока не принимала, 10 абонентов одновременно видел, через которых делали эту атаку. В общем, в нашей сети пока нет смысла городить фичу в ЛК или иной "поцанский" подход. В других сетях, вероятно, есть причины так делать из-за массовости явлений -- как вы сказали, у Билайна это сделано.

 

Народ у нас такой -- не будет у него работать порт 53, в следующем месяце он уже не заплатит, исчезнет и молча подключится к другому оператору. Палка о двух концах. Это любых запретов касается.

Share this post


Link to post
Share on other sites

wtyd

я же не предлагаю закрыть udp/53 out (т.е. запросы к сторонним dns-серверам), а только udp/53 in (к абонентам). у вам много абонентов, которые дома держут auth-dns?

 

щас просто куча всякого говна у абонентов, которые разрешают рекурсию с wan-порта

Share this post


Link to post
Share on other sites

да это ломают роутеры клиентские. в основном дир 300 и подобные и потом они долбят провайдерские днсы.

 

п.с. dnsbl .nts.su экономит проц :)

Share this post


Link to post
Share on other sites

да это ломают роутеры клиентские. в основном дир 300 и подобные и потом они долбят провайдерские днсы.

 

п.с. dnsbl .nts.su экономит проц :)

 

https://github.com/smurfmonitor/dns-iptables-rules -- а тут вон вообще брутальное решение :-).

Share this post


Link to post
Share on other sites

Разбираюсь с такой же проблемой как в сабже, в списке клиентов около 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 уже перечитал.

Edited by hsvt

Share this post


Link to post
Share on other sites

Та же фигня, сегодня резко начался DNS-флуд с использованием открытых DNS и доменов test1124.com, lolzq.com и теперь x99moyu.net.

 

Решение - заставлять клиентов закрывать открытые ДНС и лечить свои устройства, или же блокировать им запросы.

 

- Не знаю есть ли в unbound возможность так сделать - в bind можно указать IP с которых нельзя делать запросы.

- Если у вас Linux, то можно через iptables установить лимит количества запросов с client.ip

- Возможно кто-то, кто также открытый резолвер, использует "client.ip" как резолвер (например из его внутренней сети), а он в свою очередь шлет запросы вам.

Edited by avb1987

Share this post


Link to post
Share on other sites
я же не предлагаю закрыть udp/53 out (т.е. запросы к сторонним dns-серверам), а только udp/53 in (к абонентам). у вам много абонентов, которые дома держут auth-dns?

 

щас просто куча всякого говна у абонентов, которые разрешают рекурсию с wan-порта

 

+1. Посмотрите сами со своего порта.

 

Сделали именно так уже года 2 назад - тепеь никаких проблем и никаких жалоб от клиентов.

Share this post


Link to post
Share on other sites

Та же фигня, сегодня резко начался 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

Edited by hsvt

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this