Hawk128 Опубликовано 6 августа, 2014 · Жалоба Добрый день. Начались атаки одного из абонентов как цель. Последняя атака положила оба канала в конкретную полку (гиг + 100 резервный). Приходит с множества адресов ответы DNS большого размера (UDP 53). И забивают весь канал. Пакеты доходят до шейпера и там гасятся, но толку от этого мало, т.к. внешние каналы лежат. Что можно предпринять? Сервер на FreeBSD, quagga, свой блок IP. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Antares Опубликовано 6 августа, 2014 · Жалоба Гасить абонента на порту Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Hawk128 Опубликовано 6 августа, 2014 · Жалоба Не помогает. Сеть от меня анонсируется и пакеты до моего шлюза все равно бегут. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
EDA_SPB Опубликовано 6 августа, 2014 · Жалоба Советы от диванного специалиста: 1. Звонить вышестоящему магистралу и просить помощи. 2. Менять DNS запись на 127.0.0.1 или на что-нибудь не из вашей сети по вкусу. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
st_re Опубликовано 6 августа, 2014 · Жалоба Ну или расширяться, чтобы влезло, или блекхолить или же просить аплинка резать у них dst 53 на цель. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
snvoronkov Опубликовано 6 августа, 2014 · Жалоба Ну или расширяться, чтобы влезло, или блекхолить или же просить аплинка резать у них dst 53 на цель. src 53 - не? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
st_re Опубликовано 6 августа, 2014 · Жалоба ну да, src. очепятка :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
g3fox Опубликовано 6 августа, 2014 · Жалоба Не понятно почему его валят. Может быть у него статический адрес и какой-то сервис крутится на нём? Тогда поменять DNS не в ваших силах. Возможно у аплинка есть blackhole community? Хотя, наверняка, такое бывает только в сказках. Гасить абонента на порту ***ь, слов нет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Hawk128 Опубликовано 6 августа, 2014 · Жалоба Адрес статический. Сервисов нет, простой TP LINK ADSL. Блочить порт - нереал, src ip динамические. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
st_re Опубликовано 6 августа, 2014 · Жалоба DST ip клиента с проблемой, SRC порт 53. Другой вопрос захочет ли так делать аплинк. ну или блекхол на IP. да и адреса там не динамические ни разу, их просто много. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
g3fox Опубликовано 6 августа, 2014 · Жалоба Запросто могут быть и динамические у какой-то части участников 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
st_re Опубликовано 6 августа, 2014 · Жалоба Но боты то их врядли ищут динамически. Шарашат по заранее набранной базе. ну IMHO конечно, я боты не пишу :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Hawk128 Опубликовано 6 августа, 2014 · Жалоба Пока что запросил про community blackhole вышестоящих. Думаю лучший вариант в моем случае... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Antares Опубликовано 6 августа, 2014 · Жалоба Не понятно почему его валят. Может быть у него статический адрес и какой-то сервис крутится на нём? Тогда поменять DNS не в ваших силах. Возможно у аплинка есть blackhole community? Хотя, наверняка, такое бывает только в сказках. Гасить абонента на порту ***ь, слов нет. Согласен, невнимательно прочитал пост, не проснулся видимо )) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
g3fox Опубликовано 6 августа, 2014 · Жалоба Кто ваши аплинки? Наверняка часть трафика к вам валит через других крупных магистралов. Попробуйте проанонсить адрес своего клиента с маской /32. Если повезёт, и его не фильтранут из-за отсутствия route object или из-за того, что он слишком мелкий - ставьте на него blackhole комьюнити всех крупных магистралов, какие только найдёте. Нашёл вот такие: РТ 12389:55555 - blackhole traffic L3 3356:9999 - blackhole У ТТК не нашёл, да и безсмысленно, написано, что фильтруют сети, меньше чем /24. У мегафона тоже не нашёл. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Hawk128 Опубликовано 6 августа, 2014 · Жалоба Что бы не гадать я своим аплинкам прямо вопрос написал, если есть - скажут. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Hawk128 Опубликовано 9 августа, 2014 · Жалоба Опять было 2 коротких атаки, и снова в вечернее время (20-22). Перед этим сменили абоненту модем (были подозрения что конкретно этот TP Link подглючивает.) и сменили белый адрес. Атака была на новый адрес... По нетфлоу - от абонента пакетов не было перед атакой. Сразу началась атака. Есть идеи? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pppoetest Опубликовано 9 августа, 2014 (изменено) · Жалоба А были ли пакетики извне на DST белый ip клиента порт 53? Изменено 9 августа, 2014 пользователем pppoetest Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
man781 Опубликовано 9 августа, 2014 · Жалоба А были ли пакетики извне на DST белый ip клиента порт 53? Пакеты на udp dst 53 летят всем и всегда ) Мы раздаем всем абонам белые ипы. И особо не испытываем проблем и жалоб нет. Но вот решил наконец-то не дожидаясь жалоб задропать из мира на абонов udp dst 53. И что вы думаете - в 20 раз уменьшилось к-во dns query на моем DNS серве от моих же клиентов. Вот вам и днс эмплификейшн и юзерские роутеры с открытым днс релеем. Вот думаю еще таким образом закрыть телнет, фтп, ссш, снмп, смтп, веб, чтобы защитить юзерские говнороутеры. (Оставлю нетронутым только пул для тех, кто берет статику) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
hsvt Опубликовано 30 апреля, 2015 (изменено) · Жалоба Подскажите как бороться, такая же ситуация вроде бы. У клиента на белом адресе открытый 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 Изменено 30 апреля, 2015 пользователем hsvt Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pavel.odintsov Опубликовано 30 апреля, 2015 · Жалоба Если у Вас в сети позволен спуфинг - то да, на жерству, в противном случае просто дропайте, если айпи подменили. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
hsvt Опубликовано 30 апреля, 2015 (изменено) · Жалоба Если у Вас в сети позволен спуфинг - то да, на жерству, в противном случае просто дропайте, если айпи подменили. Не совсем вас понял, ну могу я включить 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 на другой адрес. Изменено 30 апреля, 2015 пользователем hsvt Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ttttt Опубликовано 30 апреля, 2015 · Жалоба Но я не понимаю каким образом заставляют мой сервер отправлять запросы на адрес жертвы. Что тут не понятного - из другой сети спуфят, отправляют вам UDP пакет с src адресом жертвы, как-будто его жертва отправила, ваш сервер жертве и пытается ответить. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
hsvt Опубликовано 30 апреля, 2015 (изменено) · Жалоба Но я не понимаю каким образом заставляют мой сервер отправлять запросы на адрес жертвы. Что тут не понятного - из другой сети спуфят, отправляют вам 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 ? Изменено 30 апреля, 2015 пользователем hsvt Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 30 апреля, 2015 · Жалоба 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 - кто будет создавать этот список? Зачем ставить метку когда мы тут же дропаем пакет? Будет ли это работать - зависит от того какими путями у вас ходят пакеты от клиентов в инет и из инета к клиентам, и где при этом находится тазик на который эти правила будут вводить. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...