[orlik]

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

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

[alibek]

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

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

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

[wtyd]

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

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

 

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

[orlik]

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

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

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

 

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

[terrible]

dnsmasq не?

[vlad11]

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

[boco]

http://forum.nag.ru/forum/index.php?showtopic=42406&st=120 и далее

[s.lobanov]

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

[orlik]

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

 

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

[wtyd]

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

 

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

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

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

 

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

 

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

 

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

[s.lobanov]

wtyd

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

 

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

[zhenya`]

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

 

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

[wtyd]

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

 

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

 

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

[hsvt]

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

[avb1987]

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

 

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

 

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

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

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

Изменено 14 декабря, 2015 пользователем avb1987

[Negator]

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

 

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

 

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

 

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

[hsvt]

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