[Hawk128]

Добрый день.

 

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

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

 

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

 

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

[Antares]

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

[Hawk128]

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

[EDA_SPB]

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

 

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

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

[st_re]

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

[snvoronkov]

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

src 53 - не?

[st_re]

ну да, src. очепятка :)

[g3fox]

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

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

 

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

 

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

[Hawk128]

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

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

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

[st_re]

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

 

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

[g3fox]

Запросто могут быть и динамические у какой-то части участников 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

[st_re]

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

[Hawk128]

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

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

[Antares]

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

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

 

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

 

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

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

[g3fox]

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

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

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

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

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

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

[Hawk128]

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

[Hawk128]

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

 

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

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

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

 

Есть идеи?

[pppoetest]

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

Edited August 9, 2014 by pppoetest

[man781]

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

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

 

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

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

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

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

 

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

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

[hsvt]

Подскажите как бороться, такая же ситуация вроде бы. У клиента на белом адресе открытый 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 April 30, 2015 by hsvt

[pavel.odintsov]

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

[hsvt]

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

 

Не совсем вас понял, ну могу я включить 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 April 30, 2015 by hsvt

[ttttt]

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

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

[hsvt]

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

Что тут не понятного - из другой сети спуфят, отправляют вам 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 April 30, 2015 by hsvt

[Ivan_83]

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 - кто будет создавать этот список?

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

 

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