[Bushi]

В таком случае действительно не понятен смысл.

А у вас нет принудительного заворота udp53 от абонентов на свой DNS сервер ?

Нет. А чем поможет "заворот"? Он только усугубит ситуацию. Тут может помочь только блокировка пакетов udp на порт 53 в сторону абонентов.

[Картуччо]

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

Хотя у них и так наверняка прописан провайдерский адрес днс.

[UglyAdmin]

После внедрения робота, анализирующего NetFlow - такие абоненты отстреливаются через 5 минут после начала атаки.

После чего им необходимо позвонить в техподдержку, которая им конкретно объяснит, что включить-то их включат, но если они не вылечатся - отстрел произойдёт через 5 минут автоматически.

[Bushi]

Хотя у них и так наверняка прописан провайдерский адрес днс.

Так и есть. Временно помогают подобные записи значительно снять нагрузку:

 

zone "bx139.com" { type master; file "/etc/namedb/master/empty.db"; };                                                                                       
zone "52huaer.com" { type master; file "/etc/namedb/master/empty.db"; };                                                                                     
zone "28qz.com" { type master; file "/etc/namedb/master/empty.db"; };                                                                                        
zone "8080hj.com" { type master; file "/etc/namedb/master/empty.db"; };                                                                                      
zone "531jy.com" { type master; file "/etc/namedb/master/empty.db"; };

Но домены постоянно меняются.

[Картуччо]

А не пробовали засниферить трафик по 53 порту юдп в сторону абонентов, то есть поймать и посмотреть оригинальные запросы извне ?

[Bushi]

А не пробовали засниферить трафик по 53 порту юдп в сторону абонентов, то есть поймать и посмотреть оригинальные запросы извне ?

Пробовали конечно, с разных хостов запросы A типа ezojkjqhedwjyb.qqq.28qz.com.

[Картуччо]

А спуфинга там никакого нет ?

[Bushi]

Нет, причем интересно, что запросы идут не из китая, конкретно в мою сеть запросы идут из Ростелекома и Интерсвязи.

 

Хотя не, вру, из разных стран.

[Картуччо]

Если не видно конкретной жертвы атаки, то может украинский след :)

[Negator]

мы уже пару месяцев как зафильтровали 53 порт к абонентам.

Пока никому не понадобилось открыть.

[Bushi]

У нас юрлиц много, некоторые держат свои зоны

[snvoronkov]

Меня сегодня тоже боты у юриков с атаками на DNS достали. Объявил им "войну".

 

Пока безуспешно - всем побоку, что у них в офисах боты на компах. ;-)

 

// Банкам тоже пофиг. Список оглашать не готов.

[Картуччо]

Так то не боты. Это извне долбят боты, а дальше уже днс форвардинг.

Скорее всего.

[Bushi]

Так то не боты. Это извне долбят боты, а дальше уже днс форвардинг.

Скорее всего.

О чем и речь, неверно настроенные или незакрытые dns сервисы у абонентов.

[snvoronkov]

Так то не боты. Это извне долбят боты, а дальше уже днс форвардинг.

Скорее всего.

О чем и речь, неверно настроенные или незакрытые dns сервисы у абонентов.

 

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

И таких орлов более единицы.

[Butch3r]

У нас какая-то странная проблема с DNSами. Переодически на самих серверах пропадает резолв до разных сайтов. Ни у кого такого больше нету?

[boco]

У нас какая-то странная проблема с DNSами. Переодически на самих серверах пропадает резолв до разных сайтов. Ни у кого такого больше нету?

а если в это время сделать

netstat -an | fgrep -w 53 | awk '{print $5}' | sort | uniq -c | sort -n

[YuryD]

У нас какая-то странная проблема с DNSами. Переодически на самих серверах пропадает резолв до разных сайтов. Ни у кого такого больше нету?

а если в это время сделать

netstat -an | fgrep -w 53 | awk '{print $5}' | sort | uniq -c | sort -n

 

dnstop из портов нагляднее

[boco]

dnstop из портов нагляднее

нет

[Butch3r]

У нас какая-то странная проблема с DNSами. Переодически на самих серверах пропадает резолв до разных сайтов. Ни у кого такого больше нету?

а если в это время сделать

netstat -an | fgrep -w 53 | awk '{print $5}' | sort | uniq -c | sort -n

в настоящий момент ничего криминального - попробую посмотреть в момент проявления проблемы

[YuryD]

dnstop из портов нагляднее

нет

Почему ? Я наглядно онлайн вижу кто из моих клиентов напрягает днс-ы вообще, очень помогает на промежуточном маршрутизаторе выявить негодяя, и принять меры, быстро. А про остальное я и из логов своего bind увижу. Проблема dns-ampl - от кривых серверов клиентов, мой тут ни причем.

[boco]

Почему ? Я наглядно онлайн вижу кто из моих клиентов напрягает днс-ы вообще, очень помогает на промежуточном маршрутизаторе выявить негодяя, и принять меры, быстро. А про остальное я и из логов своего bind увижу. Проблема dns-ampl - от кривых серверов клиентов, мой тут ни причем.

это совсем не то. штука полезная, не спорю. но моя команда позволяет определить "пожирателей сокетов". вчера, например, это был dns-сервер 117.27.250.231, авторитетный за czcbl.com. он работал, почитай, в режиме spamd - bind открывал к нему tcp (!) сокет и вис на передаче пары байтов туда-сюда. а вирусня с приличной скоростью генерила все новые и новые запросы типа ocdrfghvwkyz.www.czcbl.com. в результате у намеда тупо кончались свободные сокеты. в логах это выглядит примерно так: "socket: file descriptor exceeds limit (4096/4096)" и "recursive-clients soft limit exceeded, aborting oldest query". запуск с опцией -S 8192 (вместо умолчальных 4096) приводил к тому, что скоро заканчивались и они. когда стало понятно, в чем проблема, решение (частное, в данном случае) было простым - маршрут на проблемный сервер в нуль и фэйковая зона в конфиг намеда.

 

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

 

и третий тип запроса от этого вируса - запрашивает какую-нибудь длинную фигню, типа записи RRSIG. вчера был популярен isc.org, сегодня почему-то 1x1.cz. в результате сервер генерит приличный исходящий трафик в сторону клиента.

 

судя по всему, вирусня пытается вывести из строя днс-сервер провайдера путем 1) исчерпания лимита сокетов и 2) забивания канала мусорным трафиком.

 

но вот зачем оно это делает - непонятно. какой смысл класть днс провайдера? иногда оно еще пытается отрезолвить "itsnotworkinmf.aaa" =)

 

а вот общего решения пока не вижу. список того что уже удалось отловить:

 

zone "czcbl.com"        { type master; file "/etc/namedb/master/kavkaz.db"; };
zone "ljfczx.com"       { type master; file "/etc/namedb/master/kavkaz.db"; };
zone "yxsfwg.com"       { type master; file "/etc/namedb/master/kavkaz.db"; };
zone "hiyuxi.com"       { type master; file "/etc/namedb/master/kavkaz.db"; };
zone "560gg.com"        { type master; file "/etc/namedb/master/kavkaz.db"; };
zone "sf-45.com"        { type master; file "/etc/namedb/master/kavkaz.db"; };
zone "qbj888.com"       { type master; file "/etc/namedb/master/kavkaz.db"; };
zone "www.klmir2.com"   { type master; file "/etc/namedb/master/kavkaz.db"; };
zone "ltcq185.com"      { type master; file "/etc/namedb/master/kavkaz.db"; };
zone "www.5478pk.com"   { type master; file "/etc/namedb/master/kavkaz.db"; };
zone "zhaosf.cz"        { type master; file "/etc/namedb/master/kavkaz.db"; };
zone "180.86min.com"    { type master; file "/etc/namedb/master/kavkaz.db"; };
zone "www.xcs520.com"   { type master; file "/etc/namedb/master/kavkaz.db"; };
zone "3hao.56gw.net"    { type master; file "/etc/namedb/master/kavkaz.db"; };
zone "lolpop.biz"       { type master; file "/etc/namedb/master/kavkaz.db"; };
zone "www.0769cg.com"   { type master; file "/etc/namedb/master/kavkaz.db"; };
zone "www.xg6888.com"   { type master; file "/etc/namedb/master/kavkaz.db"; };
zone "dzfz.com.cn"      { type master; file "/etc/namedb/master/kavkaz.db"; };
zone "www.0769dd.com"   { type master; file "/etc/namedb/master/kavkaz.db"; };
zone "www.80078.com"    { type master; file "/etc/namedb/master/kavkaz.db"; };
zone "www.876yx.com"    { type master; file "/etc/namedb/master/kavkaz.db"; };
zone "www.in218.com"    { type master; file "/etc/namedb/master/kavkaz.db"; };

 

но это все равно что носить воду решетом - они создают все новые и новые домены.

 

ps. "fstat | fgrep named | wc -l" позволяет быстро оценить, с чем имеем дело (в линуксе вместо fstat надо заюзать lsof). в нормальном режиме работы пара намедов суммарно дают 300-400 открытых файлов. в режиме исчерпания сокетов - 8-16 тысяч (в зависимости от того, что указано в опции -S)

[Bushi]

Пришлось идти на радикальные меры, закрыл входящий к абонентам UDP на 53 порт, нагрузка на сервер упала в разы.

[boco]

Пришлось идти на радикальные меры, закрыл входящий к абонентам UDP на 53 порт, нагрузка на сервер упала вразы.

а как это помогает днс-серверу?

[st_re]

А, судя по всему, развелось куча клентских рутеров у которых открыт 53 для запросов снаружи, которые они радостно перенаправляют на то что в рутере настроено (т.е. на ресовлер провадера). С точки зрения ресолвера провайдера, это уже клентские запросы.

 

Единственное, сдается мне, направлено это не на ДОС провайдерского ресолвера а на NSы тех доменов. Ибо они вообще не Але от такого шквала в их сторону..