как узнать кто ддосит меня

Обнаружение DDoS-атак «на коленке»

Приветствую, Хабр! Я работаю в небольшом интернет провайдере масштаба области. У нас транзитная сеть (это значит, что мы покупаем интернет у богатых провайдеров и продаем его бедным). Несмотря на небольшое количество клиентов и такое же небольшое количество трафика протекающего по нашей сети, довольно часто приходится иметь дело с весьма внушительными DDoS-атаками по 10-20Гбит/с. (чаще всего конечно это атаки гораздо меньшего калибра). И хотя некоторые из наших клиентов обзавелись уже системами обнаружения таких атак и могут самостоятельно отправить жертву в блек-холл, гораздо чаще обнаружение атаки и бан конкретного IP жертвы ложится на наши плечи (тем более, если атака способна забить наши внешние каналы).

О решении, которое помогает обнаруживать эти самые атаки и которое принято у нас в сети, я и хотел бы рассказать. Оно бесплатно, основывается на анализе данных NetFlow, поэтому просто и весьма эффективно.

На самом деле систем для обнаружения Ddos-атак основанных на анализе данных протоколов NetFlow/SFlow/IPFIX существует довольно много (вероятно почти все?). В первом приближении, суть всех таких систем сводится к установлению порогов по количеству пакетов/потоков/октетов на определенный тип трафика к конкретному IP, при превышении которого система сигнализирует о возможной атаке. И наше решение ничем от них в этом плане не отличается. Однако, основная проблема – большинство из них платные. А бесплатные версии предлагают довольно грубый анализ, который часто неэффективен (к примеру, позволяет устанавливать порог только на весь трафик к конкретному IP, без его предварительной фильтрации, что в случае анализа транзитного трафика почти всегда бесполезно).

Итак, сперва необходимо настроить протокол NetFlow на сетевом оборудовании с минимально возможным active timeout (интервал с котором экспортируются данные с оборудования на коллектор) — это 60с для Cisco и Juniper.

В качестве core-маршрутизатора у нас выступает Juniper MX480, он и будет заниматься отправкой телеметрии. Сначала настраиваем сэмплинг:

Далее, нам необходимо настроить NetFlow коллектор, который будет собирать данные статистики с оборудования.

В качестве коллектора решено было использовать многим знакомый flow-capture из набора утилит flow-tools. Именно набор утилит, который позволяет строить разнообразные и подробные отчеты на основе собранной статистики является главным достоинством этого пакета. (К слову в наборе утилит также есть и flow-dscan для обнаружения сканирования хостов/портов и другой нежелательной активности). В недостатки можно записать отсутствие веб-оболочки и отсутствие поддержки 9й версии NetFlow. Однако, повторюсь, гибкость таких утилит как flow-nfilter, flow-report и, конечно же, свободное распространение с легкостью все перекрывают.

Сервер, на котором работает коллектор, в нашем случае под FreeBSD (конечно flow-tools доступен и для linux).

Добавляем в /etc/rc.conf:

-z0 – сжатие файлов (0 — выключено)
-n1439 – количество файлов, которое создаст коллектор в сутки. По умолчанию 95 – это один файл в 15 минут. 1439 – максимальное значение — это один файл в минуту. Нам необходимо, чтобы файлики создавались как можно быстрее.
-N3 – это уровень вложенности файлов и папок (YYYY/YYYY-MM/YYYY-MM-DD/flow-file)
-E10G – ограничение на занимаемое пространство на диске. Будет удалять старые файлы таким образом, чтобы общий объем файлов с телеметрией был менее этого числа. Очень полезная штука, жаль не подчищает созданные директории.
-e0 – тоже самое только про количество файлов (0 – не следить)
-S1 – логировать каждую минуту сообщение о полученных/потерянных/обработанных потоках

Из всего набора утилит flow-tools нас будут интересовать три:

Код скрипта я приводить не буду, он с файлами filters.cfg и reports.сfg доступен на GitHub

Для его работы достаточно сконфигурировать некоторые параметры в config.ini. И добавить его в крон на исполнение в каждую минуту.

В частности, задать пороги для отчетов в зависимости от интенсивности трафика в вашей сети, а также от настроек семплинга NetFlow на сетевом оборудовании.

Письмо с уведомлением об атаке выглядит так:

Источник

Вычисляем DDOS на сервере

Бывает сидишь такой, никого не трогаешь, а тут тебе звонят и говорят что сервисы работают медленно, сайты открываются по 2-3 минуты умудряются выдавать 504 ошибку.
Расстроенным лезешь в cacti, а там такое:

Далее начинаешь судорожно искать причину всего этого, и выясняется что это обычный DDos…

Ниже будут приведены команды, которые помогут понять вам, что случилось, и точно ли это DDos.

Для начала я рекомендую прочитать статью «Средства мониторинга Linux системы (часть 1?)» в ней подробно описано какие логи нам интересны, как читать вывод команды top и как пользоваться командой ps. Все они нам пригодятся для того чтобы понять какие хосты у нас подверглись атаке и какие узкие места есть на сервере.

Какими командами, и что мы можем определить?

Для начала можно посмотреть число запущенных процессов Apache. Если их более 20-30 то явно уже что-то не так.

Смотрим число процессов Apache в Debian:

Смотрим число процессов Apache в CentOS:

Данной командой мы можем посмотреть количество соединений с сервером:

Так же показателем того, что на сервер идет DDos может служить числе коннектов на 80 или 443 порт. Вот команды способные показать это число:

Существует еще такая разновидность DDod, как SYN. Ниже приведена команда позволяющая определить число SYN запросов на те же 80 и 443 порты:

А эта команда показывает количество SYN запросов:

Следующая команда позволит понять нам, на какой домен идет больше всего запросов:

Теперь посмотрим какое количество запросов приходит с каждого IP. Эта команда показывает по всем портам:

Эта команда показывает количество запросов только по 80 порту:

Эта команда показывает все запросы на 80 порт, не считая их, т.е. «упрощенный» но «наиболее полный» вариант вывода:

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

Кстати, если у вас не настроен server-status на Apache, то статус этого сервера можно посмотреть в CLI:

Лог Файлы

Естественно рекомендуется смотреть лог файлы вашего сервера Apache и Nginx (если он есть).

Глобальные логи Apache, в Debian, обычно находятся там:

Глобальные логи Nginx находятся там:

Так же не забывайте просматривать логи виртуальных хостов, если хосты у вас настроены. Нас будет интересовать самый большой лог, который «растет» на глазах.

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

Выявить конкретные IP с числом запросов до сайта можно данной командой:

Так же можно получить статистика по запросам с группировкой по IP с помощью утилиты logtop.

Для начала установим эту утилиту:

И теперь получим статистику:

Следующая команда поможет нам выявить популярные user-агенты:

Как блокировать?

Вот как можно заблокировать tcp запросы на 80 порт с определенного IP:

Так мы блокируем запросы на все порты с определенного IP:

Посмотреть список уже заблокированных мы можем данными командами:

Если нам нужно удалить из блокировки определенный IP, можно воспользоваться этой командой

Чтобы удалить все правила, можно воспользоваться командой:

Немного профилактики, в целях защиты от DDos…

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

Следующей командой мы установим максимальное количество подключений с одного IP на 80 порт:

Тоже самое можно сделать и для DNS:

Следующее правило в iptables будет препятствовать спуфингу от нашего имени. Как правило, во время ddos мы получаем пакет с установленными флагами SYN и ACK по еще не открытому соединению (этой комбинацией флагов обладает только ответ на SYN-пакет). Это говорит о том, что кто-то послал другому хосту SYN-пакет от нашего имени, и ответ пришел к нам.
По данному правилу, наш хост ответит RST-пакетом, после получения которого атакуемый хост закроет соединение.

Сохранить правила можно следующей командой:

Что еще можно сделать?

Еще не помешает немного «оттюнинговать» ядро, сделать тонкую настройку Apache и Nginx (если таковой стоит), поставить дополнительные модули и пакеты для защиты от атак, такие как Fail2Ban, mod_evasive, ModSecurity..

Но все это темы других статей, которые скоро будут написаны…

Источник

Как узнать кто ддосит меня

А вот, кстати, опровержение очередного бреда журналистов относительно дела по второй ссылке:

Смотри в логах айпишки атакующих машин, пробуй получить доступ к одной из них для анализа DDoS бота и определения админки/командного центра, получай доступ к ней и т.д.

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

А вообще все индивидуально, есть много частных случаев и общего рецепта нет. Это вообще может быть личная месть, тест ботнета и т.д.

Смотри в логах айпишки атакующих машин, пробуй получить доступ к одной из них для анализа DDoS бота и определения админки/командного центра, получай доступ к ней и т.д.

Все я понимаю:
http://ru.wikipedia.org/wiki/DDoS
Или тута ложь написано?
Абсолютно не трудно определить с какого адреса пытаются пробивать защиту!
Существуют сигнатуры по которым можно определить тип атаки, да и вообще, что приходят некорректные пакеты. По достижению определенного количества этих ошибок с данного адреса принимаются ряд вариантов:
1. Блокировка данного адреса.
2. Игнорировать все данные от источника пакетов (принципиальной разницы с 1-м вариантом нету. она заключается только в отсылке сообщений источнику, либо ничего не отсылаем, тем самым заставляем источник ожидать какое-то время нашего ответа)
3. Перенаправление всех пакетов на другой компьютер.

Все зависит от типа атак. Если тупо гасим размерами пакетов, то конечно в перенаправлении эфективности нету! Канал просто ляжет!
Но вот про более интелектуальные атаки, на ошибки в сервисах (например по переполнению буфера), то тута можно и перенаправление применить! Пусть ломают не рабочий сервак! Который будет выдавать абсолютно неадекватные ответы и вести себя по отношению к источникам атаки как угодно, что по моему мнению может затормозить атаку и поломать голову над ответами сервера (одним из ответов может быть, к примеру, что сервис в данный момент не работает, а через минуты выдать, что заработал). А как известно время деньги! За это время у админа есть время разобратся в ситуации и начать принимать меры.
Это моя логика на все это.

Если есть какие-то замечания, то хотелось бы услышать! Может я и не прав, тогда поясните в чем?

2. http://www.cyberguru.ru/networks/network-technologies/ddos-protection-page4.html
Принцип работы систем защит от DDoS атак
Система защиты от DDoS атак базируется на уже имеющихся в сети маршрутизаторах и добавляет в сеть свои два компонента:

•устройство для блокирования DDoS атаки. В английском языке это устройство называют mitigator. В связи с отсутствием аналогичных статей по данной теме я введу русский термин: буду называть его блокиратор;
•устройство со встроенным искусственным интеллектом для обнаружения DDoS атаки и перенаправления атаки на блокиратор, буду называть его детектор.

Источник

Как выявить атаку-DDoS на сервер и остановить ее

Продолжим изучать DDoS-атаки. Определенная атака типа «отказ в обслуживании» (DDoS) может произойти с кем угодно и когда угодно. Если вы владелец веб-сайт, который работает на выделенном веб-сервере, важно понять, что такое DDoS-атака, правильно ее идентифицировать и что необходимо предпринять, чтобы остановить и предотвратить ее.

Что такое DDoS-атака?

Во время нормальной работы веб-сервер предоставляет вашу веб-страницу посетителям следующим образом:

— Человек вводит ваш URL в свой веб-браузер.

— Веб-браузер отправляет HTTP-запрос к URL-адресу веб-сайта.

— DNS-серверы вашего провайдера преобразуют URL-адрес в правильный IP-адрес веб-сервера.

— HTTP-запрос направляется через Интернет на веб-сервер.

— Веб-сервер использует страницу, запрошенную в URL, чтобы найти правильный файл HTML.

— Веб-сервер отвечает всем содержимым этого HTML-файла.

— Браузер пользователя получает файл HTML и отображает страницу для пользователя.

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

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

Поскольку ваш веб-сервер не был рассчитан на такой объем трафика, веб-сервер будет отвечать на ваши обычные посетители сайта с сообщением об ошибке «Сервис недоступен». Это также известно как ошибка HTTP 503.

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

Как определить DDoS-атаку?

Как вы узнаете, что ваш сайт только что вышел из строя из-за DDoS-атаки? Есть несколько симптомов, которые являются мертвой раздачей.

Обычно ошибка 503 HTTP, описанная выше, является четким указанием. Однако еще одним признаком DDoS-атаки является очень сильный скачок пропускной способности.

Вы можете просмотреть это, войдя в свою учетную запись с веб-хостинга и открыв Cpanel. Прокрутите страницу вниз до раздела «Журналы» и выберите «Пропускная способность».

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

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

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

Как остановить DDoS-атаку

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

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

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

Как победить DDoS-атаку

Если вы выполняете критически важную онлайн-операцию, такую Икак крупный бизнес, и хотите, чтобы ваш сайт был защищен от DDoS-атак, это возможно, но это не дешево. Службы защиты от DDoS работают, создавая своего рода ботнет-счетчик, который больше ботнета, выполняющего DDoS-атаку. Это создает распределенный ответ на входящие HTTP-запросы, даже если таких запросов сотни тысяч или миллионы.

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

Источник

Как определить что меня досят?

т.е. подозреваю что это ддос но не уверен.

CentOS.. с ВДСа может переперть хостер.

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

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

Посмотри что говорит iftop и iptraf

Медленно прогружались страницы сайта.. Были подозрения на флуд какимто скриптом или ДДОСик.

System hostname vps.arbusi.net Operating system CentOS Linux 5.5 Webmin version 1.530 Time on system Mon Jan 3 19:57:27 2011 Kernel and CPU Linux 2.6.18-194.8.1.el5.028stab070.4 on i686 Processor information AMD Phenom(tm) II X4 945 Processor, 4 cores System uptime 1 days, 21 hours, 15 minutes Running processes 28 CPU load averages 0.29 (1 min) 0.21 (5 mins) 0.16 (15 mins) CPU usage 0% user, 0% kernel, 0% IO, 100% idle Real memory 1024 MB total, 273.12 MB used

Local disk space 30 GB total, 1.26 GB used

Package updates All installed packages are up to date

Источник