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

dns ddos amplification

Добрый день.

 

Начались атаки одного из абонентов как цель. Последняя атака положила оба канала в конкретную полку (гиг + 100 резервный).

Приходит с множества адресов ответы DNS большого размера (UDP 53). И забивают весь канал. Пакеты доходят до шейпера и там гасятся, но толку от этого мало, т.к. внешние каналы лежат.

 

Что можно предпринять?

 

Сервер на FreeBSD, quagga, свой блок IP.

Share this post


Link to post
Share on other sites

Не помогает. Сеть от меня анонсируется и пакеты до моего шлюза все равно бегут.

Share this post


Link to post
Share on other sites

Советы от диванного специалиста:

 

1. Звонить вышестоящему магистралу и просить помощи.

2. Менять DNS запись на 127.0.0.1 или на что-нибудь не из вашей сети по вкусу.

Share this post


Link to post
Share on other sites

Ну или расширяться, чтобы влезло, или блекхолить или же просить аплинка резать у них dst 53 на цель.

Share this post


Link to post
Share on other sites

Ну или расширяться, чтобы влезло, или блекхолить или же просить аплинка резать у них dst 53 на цель.

src 53 - не?

Share this post


Link to post
Share on other sites

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

Возможно у аплинка есть blackhole community? Хотя, наверняка, такое бывает только в сказках.

 

Гасить абонента на порту

 

***ь, слов нет.

Share this post


Link to post
Share on other sites

Адрес статический.

Сервисов нет, простой TP LINK ADSL.

Блочить порт - нереал, src ip динамические.

Share this post


Link to post
Share on other sites

DST ip клиента с проблемой, SRC порт 53. Другой вопрос захочет ли так делать аплинк. ну или блекхол на IP.

 

да и адреса там не динамические ни разу, их просто много.

Share this post


Link to post
Share on other sites

Запросто могут быть и динамические у какой-то части участников DDoS. У нас развелась куча абонентов с руками из жопы, тупой головой, и микротиками. В итоге получаем открытый на микротике 53-ий порт. Адреса у нас динамические, соответственно и участники DDoS тоже имеют динамические адреса.

 

З.Ы. Для nmap есть скрипт, который позволяет определить возможность выполнения рекурсивных запросов. Периодически проверяем свои публичные адреса на наличие проблемных абонентов.

 

nmap -n -p53 -sU -oG --open --script=dns-recursion 8.8.8.8

Starting Nmap 5.00 ( http://nmap.org ) at 2014-08-06 19:12 YEKT
Interesting ports on 8.8.8.8:
PORT   STATE         SERVICE
53/udp open|filtered domain
|_ dns-recursion: Recursion appears to be enabled

Nmap done: 1 IP address (1 host up) scanned in 0.80 seconds

Share this post


Link to post
Share on other sites

Но боты то их врядли ищут динамически. Шарашат по заранее набранной базе. ну IMHO конечно, я боты не пишу :)

Share this post


Link to post
Share on other sites

Пока что запросил про community blackhole вышестоящих.

Думаю лучший вариант в моем случае...

Share this post


Link to post
Share on other sites

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

Возможно у аплинка есть blackhole community? Хотя, наверняка, такое бывает только в сказках.

 

Гасить абонента на порту

 

***ь, слов нет.

Согласен, невнимательно прочитал пост, не проснулся видимо ))

Share this post


Link to post
Share on other sites

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

Попробуйте проанонсить адрес своего клиента с маской /32. Если повезёт, и его не фильтранут из-за отсутствия route object или из-за того, что он слишком мелкий - ставьте на него blackhole комьюнити всех крупных магистралов, какие только найдёте.

Нашёл вот такие:

РТ 12389:55555 - blackhole traffic
L3 3356:9999 - blackhole

У ТТК не нашёл, да и безсмысленно, написано, что фильтруют сети, меньше чем /24.

У мегафона тоже не нашёл.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Опять было 2 коротких атаки, и снова в вечернее время (20-22).

 

Перед этим сменили абоненту модем (были подозрения что конкретно этот TP Link подглючивает.) и сменили белый адрес.

Атака была на новый адрес...

По нетфлоу - от абонента пакетов не было перед атакой. Сразу началась атака.

 

Есть идеи?

Share this post


Link to post
Share on other sites

А были ли пакетики извне на DST белый ip клиента порт 53?

Edited by pppoetest

Share this post


Link to post
Share on other sites

А были ли пакетики извне на DST белый ip клиента порт 53?

Пакеты на udp dst 53 летят всем и всегда )

 

Мы раздаем всем абонам белые ипы. И особо не испытываем проблем и жалоб нет.

Но вот решил наконец-то не дожидаясь жалоб задропать из мира на абонов udp dst 53.

И что вы думаете - в 20 раз уменьшилось к-во dns query на моем DNS серве от моих же клиентов.

Вот вам и днс эмплификейшн и юзерские роутеры с открытым днс релеем.

 

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

(Оставлю нетронутым только пул для тех, кто берет статику)

Share this post


Link to post
Share on other sites

Подскажите как бороться, такая же ситуация вроде бы. У клиента на белом адресе открытый DNS. (скорее всего микротик или какой нибудь pfsense)

 

UPD: оказывается циска

PORT     STATE SERVICE    VERSION
22/tcp   open  ssh        Cisco SSH 1.25 (protocol 2.0)
23/tcp   open  telnet     Cisco IOS telnetd
53/tcp   open  tcpwrapped
2222/tcp open  ssh        OpenSSH 6.4 (protocol 2.0)

В логах куча таких запросов к от них к нашему серверу:

 

30-Apr-2015 09:45:04.340 query-errors: info: client 1.1.1.232#53453 (cn.www.appledaily.com.tw): view external: rate limit drop SERVFAIL error response to 1.1.1.232/32

 

Но в итоге получается аката в отражение...

 

Т.к. он заставляет отвечать наш сервер на, видимо адрес жертвы:

 

09:51:33.146646 IP 5.5.5.5.62746 > 198.41.222.12.53: 165% [1au] A? sjsvkjor.www.appledaily.com.tw. (59)
09:51:33.150144 IP 5.5.5.5.56943 > 198.41.222.12.53: 28393% [1au] A? opwfclwtcf.www.appledaily.com.tw. (61)

Apr 30 09:01:33 hkl kernel: sonewconn: pcb 0xfffffe017cdac620: Listen queue overflow: 151 already in queue awaiting acceptance (4 occurrences)
Apr 30 09:03:08 hkl kernel: sonewconn: pcb 0xfffffe017cdac620: Listen queue overflow: 151 already in queue awaiting acceptance (2 occurrences)
Apr 30 09:04:08 hkl kernel: sonewconn: pcb 0xfffffe017cdac620: Listen queue overflow: 151 already in queue awaiting acceptance (19 occurrences)
Apr 30 09:05:18 hkl kernel: sonewconn: pcb 0xfffffe017cdac620: Listen queue overflow: 151 already in queue awaiting acceptance (10 occurrences)
Apr 30 09:06:20 hkl kernel: sonewconn: pcb 0xfffffe017cdac620: Listen queue overflow: 151 already in queue awaiting acceptance (10 occurrences)
Apr 30 09:07:21 hkl kernel: sonewconn: pcb 0xfffffe017cdac620: Listen queue overflow: 151 already in queue awaiting acceptance (5 occurrences)

 

Кроме зарезания из мира на udp dst 53, может есть еще варианты или конфиге как то можно? 9.9.6-P1

Edited by hsvt

Share this post


Link to post
Share on other sites

Если у Вас в сети позволен спуфинг - то да, на жерству, в противном случае просто дропайте, если айпи подменили.

Share this post


Link to post
Share on other sites

Если у Вас в сети позволен спуфинг - то да, на жерству, в противном случае просто дропайте, если айпи подменили.

 

Не совсем вас понял, ну могу я включить uPRF или antispoof это изменит что-то ? rate limit и так дропает. Но я не понимаю каким образом заставляют мой сервер отправлять запросы на адрес жертвы.

 

bind     named      22566 876 udp4  5.5.5.5:54296    198.41.222.8:53
bind     named      22566 883 udp4  5.5.5.5:50624    198.41.222.8:53
bind     named      22566 884 udp4  5.5.5.5:63885    198.41.222.8:53
bind     named      22566 889 udp4  5.5.5.5:57740    198.41.222.8:53
bind     named      22566 895 udp4  5.5.5.5:56002    198.41.222.8:53

 

sockstat -4 | grep 198.41.222.8 | wc -l

194

 

Клиент и днс сервер в одной сети, у клиента открытый резолвер и его видимо ддосят, при этом заставляя мой сервер отправлять запросы dst 53 на другой адрес.

Edited by hsvt

Share this post


Link to post
Share on other sites

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

Что тут не понятного - из другой сети спуфят, отправляют вам UDP пакет с src адресом жертвы, как-будто его жертва отправила, ваш сервер жертве и пытается ответить.

Share this post


Link to post
Share on other sites

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

Что тут не понятного - из другой сети спуфят, отправляют вам UDP пакет с src адресом жертвы, как-будто его жертва отправила, ваш сервер жертве и пытается ответить.

 

Как бороться с таким? Что нибудь из этого поможет?

 

net.inet.ip.check_interface=1

scrub in all

antispoof log for $ext_if inet

block in quick from urpf-failed label uRPF 

 

Заблокировать на порту клиента dst 53 ?

Edited by hsvt

Share this post


Link to post
Share on other sites
net.inet.ip.check_interface=1

net.inet.ip.check_interface: Verify packet arrives on correct interface

 

block in quick from urpf-failed label uRPF

urpf-failed - кто будет создавать этот список?

Зачем ставить метку когда мы тут же дропаем пакет?

 

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

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