[st_re]

 

Что значит "уберите 53 порт из src для запросов" и как это сделать?

Наш сервер разумеется отвечает на dns-запросы, т.к. у нас есть небольшой хостинг, свой почтовый сервер, клиенты регали свои домены и размещали у нас записи primary и secondary DNS-ов. Так что тут мы просто должны отвечать на DNS-запросы.

 

query-source address 1.3.4.5 port 53; есть ? уберите отсюда port 53. Грубо говоря, если Ваш сервер должен послать запрос то src порт у него должен быть не 53, а рандом из 1024-65к. На то, где Ваш сервер слушает запросы это не влияет.

 

На всех серверах, где нет необходимости отвечать на внешние запросы перевесить слушатель на

listen-on { 127.0.0.1; };

[Andrei]

 

Что значит "уберите 53 порт из src для запросов" и как это сделать?

Наш сервер разумеется отвечает на dns-запросы, т.к. у нас есть небольшой хостинг, свой почтовый сервер, клиенты регали свои домены и размещали у нас записи primary и secondary DNS-ов. Так что тут мы просто должны отвечать на DNS-запросы.

 

query-source address 1.3.4.5 port 53; есть ? уберите отсюда port 53. Грубо говоря, если Ваш сервер должен послать запрос то src порт у него должен быть не 53, а рандом из 1024-65к. На то, где Ваш сервер слушает запросы это не влияет.

Пока на пограниченой cisco фильтранул запросы по 53-му порту, т.к. было работать невозможно:

access-list 120 permit udp host 8.8.8.8 eq domain any
access-list 120 permit udp host 62.141.99.90 eq domain any
access-list 120 deny   udp any eq domain any
access-list 120 permit ip any any

Но это не вариант, т.к. мой сервак является для нескольких доменов primary или secondary DNS-ом. :(

 

На всех серверах, где нет необходимости отвечать на внешние запросы перевесить слушатель на

listen-on { 127.0.0.1; };

Это в каком конфигурационном файле bind-а надо сделать?

[flamaster]

 

st_re (Вчера, 15:14) писал:

На всех серверах, где нет необходимости отвечать на внешние запросы перевесить слушатель на

listen-on { 127.0.0.1; };

 

Это в каком конфигурационном файле bind-а надо сделать?

наверно на главном конфигурационном файлом named.conf

[st_re]

 

К примеру iftop -n -i eth2 показвает, что идет большое кол-во запросов с адреса 94.236.66.210

Записываю это дело в файл:

tshark -i eth2 -w /tmp/94_236_66_210.pcap host 94.236.66.210

Файл в аттаче

 

Ну да, бедного 94.236.66.210 напрягают

 

11:03:17.834386 IP 94.236.66.210.domain > 87.226.191.21.domain: 952+ [1au] ANY? ripe.net. (38)

11:03:17.834669 IP 87.226.191.21.domain > 94.236.66.210.domain: 952- 0/13/2 (261)

 

на 38 байт запроса к Вам (скорее всего посланных с поломанного хостинга c src ip жертвы) к бедному 94.236.66.210 поехало почти в 10 раз больше. (261)

 

причем, если бы ripe.net отдался из Вашего кеша, а не как тут, списком корневых NSов, ответ бы пошел еще больше. Там подписей дохрена в зоне.

сделайте в named.conf

acl intranet {
         localhost;
         localnets;
         x.x.x.x/y; # ваша(и) сеть(и)
};
...
options {
...
       listen-on       { 
                      127.0.0.1;
                      1.2.3.4; # ЭТО ip указанное у клиентов как ресолвер и/или как NS для доменов. все остальыне IP нафик.
                               # на остальных машинах в сети оставьте только 127ю0ю0ю1. Вообще похорошему 
                               # их надо разносить, и ресолвер закрывать снаружи фаерволом.
       };
       allow-query {
               intranet;
       };
       allow-query-cache {
               intranet;
       };
       allow-recursion {
               intranet;
       };
       allow-transfer {
              none;
       };
....
};
....
zone "ZZZZ.ru" IN {
....
       allow-query {
               any;
       };
...
};

 

при этом надо понимать, что Ваш сервер уже вписали в базу подходящих для их задач серверов, и ломиться будут еще долго. Они редко перепроверяют. Но, хотябы, пойдут короткие ответы.

 

и писать на абузу 94.236.66.210 без варианта. Скорее они должны писать Вам.. Это не Вас ддосят, а их. Вы одно из звеньев умножителей трафика.

[bitbucket]

Пока на пограниченой cisco фильтранул запросы по 53-му порту, т.к. было работать невозможно:

 

Но это не вариант, т.к. мой сервак является для нескольких доменов primary или secondary DNS-ом. :(

циска умеет pcf ? пакеты с запросом вполне все одинаковые, их легко отсеять через pcf фильтр.

[st_re]

Я думаю лучше мониторить скриптом логи, и при массовых запросах не своих доменов извне, фильтровать адресно типа на час.

[Andrei]

циска умеет pcf ? пакеты с запросом вполне все одинаковые, их легко отсеять через pcf фильтр.

acl я привел выше.

вешаю его на внешний интерфейс (ip access-group 120 in) ну и собственно всё.

[Andrei]

Andrei, у вас как со спуфингом дела обстоят ? Боритесь ? Ловите ? По шапке даете ?

Никак не обстоят.

С т.з. авторизации абонентов у нас применяется pptp разумеется с именем и паролем, а тут по большому счету все равно с какого адреса авторизуется клиент.

С т.з. хакерских поползновений абонентов в большом инете уже после авторизации - не отслеживаем.

[st_re]

Andrei, у вас как со спуфингом дела обстоят ? Боритесь ? Ловите ? По шапке даете ?

Никак не обстоят.

С т.з. авторизации абонентов у нас применяется pptp разумеется с именем и паролем, а тут по большому счету все равно с какого адреса авторизуется клиент.

 

Имеется в виду, что абонент или воткнувшить езернетом и не запустив pptp может отправить в интернет пакеты с src, скажем, 8.8.8.8 или же запустив pptp и получив IP 1.2.3.4 может сделать тоже самое (отправить в интернет пакеты с src 8.8.8.8). Имеется в виду что конечно отправлять то он может, но вот проходить они не должны должны дальше рутера. В идиале даже до соседа по дому долетать не должно. И обратное, в сеть не должно влетать ничего с Вашими src снаружи.

[Andrei]

Имеется в виду, что абонент или воткнувшить езернетом и не запустив pptp может отправить в интернет пакеты с src, скажем, 8.8.8.8

Не, тут все рубится shorewall-ом на линухе.

 

или же запустив pptp и получив IP 1.2.3.4 может сделать тоже самое (отправить в интернет пакеты с src 8.8.8.8). Имеется в виду что конечно отправлять то он может, но вот проходить они не должны должны дальше рутера.

А вот с этим точно не знаю.

[bitbucket]

Имеется в виду, что абонент или воткнувшить езернетом и не запустив pptp может отправить в интернет пакеты с src, скажем, 8.8.8.8

Не, тут все рубится shorewall-ом на линухе.

Там вообще то sysctl за это дело отвечает.

 

циска умеет pcf ? пакеты с запросом вполне все одинаковые, их легко отсеять через pcf фильтр.

acl я привел выше.

вешаю его на внешний интерфейс (ip access-group 120 in) ну и собственно всё.

Ну под тот acl много чего попадет и лишнего, а если pcf то только флуд, так как там еще и ripe.net можно заматчить.

[Andrei]

циска умеет pcf ? пакеты с запросом вполне все одинаковые, их легко отсеять через pcf фильтр.

acl я привел выше.

вешаю его на внешний интерфейс (ip access-group 120 in) ну и собственно всё.

Ну под тот acl много чего попадет и лишнего, а если pcf то только флуд, так как там еще и ripe.net можно заматчить.

"под тот acl много чего попадет и лишнего" - согласен полностью.

Как на циске (не свиче, а роутере) зафильтровать запросы относительно ripe.net ?

Хотя не факт, что злоумышленник не начнет бомбить DNS-запросами относительно например ya.ru.

[st_re]

У яндекса ответ помельче. он им не так интересен походу. Раньше любили аолом баловаться. И "NS ."

[bitbucket]

Как на циске (не свиче, а роутере) зафильтровать запросы относительно ripe.net ?

Видимо никак. На то она и циска. :)

 

Я бы сейчас озаботился заменой адреса dns сервера (передвинум бы на другой), и, через какое-то время просто бы начал дропать

трафик на старый адрес. Весь трафик, если там ничего из других сервисов не осталось.

[Andrei]

А если дропать не на циске, а на самом сервере (через iptables). Т.е. запросы по-прежнему будут приходить, но ответов-то от нас не будет. Наверное видя бесполезность запросов к нам, от нас наконец-то отстанут? :)

[karpa13a]

вот и такое может быть

син-ацк и тишина.

Изменено 17 сентября, 2012 пользователем karpa13a

[bitbucket]

А если дропать не на циске, а на самом сервере (через iptables). Т.е. запросы по-прежнему будут приходить, но ответов-то от нас не будет. Наверное видя бесполезность запросов к нам, от нас наконец-то отстанут? :)

Да, так тоже можно. Вариантов фильтров там уже множество: по строке в определенных оффсетах или u32. Но отстанут не скоро (не за день)

[Cramac]

Всем привет. Подниму старую тему. Подскажите, пришла напасть, зафлудили 53 порт.

в /proc/net/ip_conntrack куча

udp      17 176 src=168.63.125.125 dst=188.x.x.38 sport=58175 dport=53 packets=11 bytes=792 src=188.x.x.38 dst=168.63.125.125 sport=53 dport=58175 packets=11 bytes=792 [ASSURED] mark=0 secmark=0 use=2
udp      17 135 src=168.63.125.125 dst=188.x.x.38 sport=19842 dport=53 packets=13 bytes=936 src=188.x.x.38 dst=168.63.125.125 sport=53 dport=19842 packets=12 bytes=864 [ASSURED] mark=0 secmark=0 use=2
udp      17 172 src=168.63.125.125 dst=188.x.x.38 sport=53128 dport=53 packets=13 bytes=936 src=188.x.x.38 dst=168.63.125.125 sport=53 dport=53128 packets=13 bytes=936 [ASSURED] mark=0 secmark=0 use=2
udp      17 168 src=198.27.112.169 dst=188.x.x.38 sport=37835 dport=53 packets=18 bytes=1296 src=188.x.x.38 dst=198.27.112.169 sport=53 dport=37835 packets=17 bytes=1224 [ASSURED] mark=0 secmark=0 use=2
udp      17 130 src=185.28.20.225 dst=188.x.x.38 sport=9158 dport=53 packets=12 bytes=864 src=188.x.x.38 dst=185.28.20.225 sport=53 dport=9158 packets=11 bytes=792 [ASSURED] mark=0 secmark=0 use=2
udp      17 168 src=213.127.143.42 dst=188.x.x.38 sport=56465 dport=53 packets=18 bytes=1296 src=188.x.x.38 dst=213.127.143.42 sport=53 dport=56465 packets=18 bytes=9358 [ASSURED] mark=0 secmark=0 use=2
udp      17 109 src=185.28.20.225 dst=188.x.x.38 sport=40951 dport=53 packets=18 bytes=1296 src=188.x.x.38 dst=185.28.20.225 sport=53 dport=40951 packets=18 bytes=17420 [ASSURED] mark=0 secmark=0 use=2
udp      17 174 src=108.71.203.245 dst=188.x.x.38 sport=26580 dport=53 packets=27 bytes=1944 src=188.x.x.38 dst=108.71.203.245 sport=53 dport=26580 packets=27 bytes=26130 [ASSURED] mark=0 secmark=0 use=2
udp      17 159 src=185.28.20.225 dst=188.x.x.38 sport=20198 dport=53 packets=23 bytes=1656 src=188.x.x.38 dst=185.28.20.225 sport=53 dport=20198 packets=23 bytes=33787 [ASSURED] mark=0 secmark=0 use=2
udp      17 119 src=185.28.20.225 dst=188.x.x.38 sport=6182 dport=53 packets=23 bytes=1656 src=188.x.x.38 dst=185.28.20.225 sport=53 dport=6182 packets=23 bytes=37584 [ASSURED] mark=0 secmark=0 use=2
udp      17 92 src=112.198.82.152 dst=188.x.x.38 sport=25393 dport=53 packets=34 bytes=2448 src=188.x.x.38 dst=112.198.82.152 sport=53 dport=25393 packets=33 bytes=58108 [ASSURED] mark=0 secmark=0 use=2
udp      17 56 src=112.198.82.152 dst=188.x.x.38 sport=2002 dport=53 packets=23 bytes=1656 src=188.x.x.38 dst=112.198.82.152 sport=53 dport=2002 packets=22 bytes=57455 [ASSURED] mark=0 secmark=0 use=2

 

в настройках bind было всем разрешено, сейчас разрешил только нужным. Как убить все эти левые коннекты и достаточно будет что в настройках бинд описаны доступ только определенных сетей? :)

[stas_k]

достаточно будет что в настройках бинд описаны доступ только определенных сетей?

Достаточно.

[Bushi]

Мой сервер DNS валят абоненты, у которых открыт 53 порт и разрешены рекурсивные запросы (от серверов до мыльниц), запросы рекурсивные такого типа:

 

ijerolgvqxsrmfox.qqq.28qz.com

ulinyzcpgtwhufuf.www.bx139.com.

cvgt.liebiao.800fy.com.

 

Причем домены в зоне .com реально существуют, и все расположены в Китае. Каждый запрос уникален, поэтому кэширование не помогает, это вызывает сильную нагрузку на сервер. Не вижу никакого выхода, как закрыть для всех абонентов входящий трафик на udp port 53.

Непонятен смысл атаки.

Кто-нибудь столкнулся с этой проблемой?

[Картуччо]

Да, проблема с DNS дней 10 как очень актуальна. Просто эпидемия какая-то.

[IL86]

Непонятен смысл атаки.

Кто-нибудь столкнулся с этой проблемой?

 

Да, у нас такая же проблема с несколькими нс-серверами. Увеличили ресурсы на серверах, обновили bind до 9.9.5. С утра пока нагрузку выдерживают.

[Картуччо]

А обязательно сервера должны смотреть наружу для всех ?

Это ж DNS амплификация, если не ошибаюсь. Зачем её поддерживать ещё и наращивая сервера ?

[Bushi]

А обязательно сервера должны смотреть наружу для всех ?

Это ж DNS амплификация, если не ошибаюсь. Зачем её поддерживать ещё и наращивая сервера ?

Дык досят через своих же абонентов. Сервера не обрабатывают снаружи рекурсивные запросы, но должны обрабатывать для своих абонентов. Это не амплификация, потому что сервер отвечает ServFail. Прочитайте целиком мое предыдущее сообщение.

[Картуччо]

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

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