Ddos атака способ защиты

Что есть что и кто есть кто на рынке защиты от DDoS

Я на digital рынке с 2008 года, и за это время видел переход от веб-сайтов на Joomla (помните такую? ) до сегодняшнего Интернета с его mobile-first приложениями и сотнями миллионов IoT устройств, подключенных в сеть.
Атаки в Интернете также за это время неплохо развилиcь 🙂
Но рынок защиты от DDoS и используемые операторами технологии защиты от атак остаются все еще достаточно сильно закрытым.
Расскажу, что узнал про него, поддерживая веб-сайты и интернет-сервисы, находящиеся под непрерывными атаками несколько последних лет.

Регулярные атаки. 350k req total, 52k req legitimate

Первые атаки появились практически одновременно с интернетом. DDoS как явление стал массовым с конца 2000-х годов (поглядите www.cloudflare.com/learning/ddos/famous-ddos-attacks).

Примерно с 2015-2016 года почти все хостинг-провайдеры встали под защиту от DDoS атак, как и большинство заметных сайтов в конкурентных сферах (сделайте whois по IP сайтов eldorado.ru, leroymerlin.ru, tilda.ws, увидите сети операторов защиты).

Если 10-20 лет назад большинство атак можно было отбить на самом сервере (оцените рекомендации системного администратора Lenta.ru Максима Мошкова из 90-х), то сейчас все сложнее.

Сначала кратко про виды атак.

Виды DDoS атак с точки зрения выбора оператора защиты

Атаки на уровне L3 / L4 (по модели OSI)

• UDP flood с ботнета (напрямую с зараженных устройств на атакуемый сервис отправляется много запросов, серверам заваливают канал);
• DNS/NTP/etc amplification (с зараженных устройств отправляется много запросов на уязвимые DNS/NTP/etc, адрес отправителя подделывается, туча пакетов с ответом на запросы заваливает канал тому, кого атакуют; так выполняются самые массовые атаки в современном интернете);
• SYN / ACK flood (на атакуемые серверы отправляется много запросов на установление соединения, происходит переполнение очереди соединений);
• атаки с фрагментацией пакетов, ping of death, ping flood (погуглите плз);
• и т.п.

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

Атаки на L7 (уровень приложения)

• http flood (если атакуется веб-сайт или какой-нибудь http api);
• атака на уязвимые участки сайта (не имеющие кэша, очень сильно нагружающие сайт, етс.).

Цель — заставить сервер «тяжело работать», обрабатывать много «как будто бы реальных запросов» и остаться без ресурсов для настоящих запросов.
Хотя есть и другие атаки, эти — самые распространенные.
Серьезные атаки на L7 уровне создаются уникальным образом под каждый атакуемый проект.

Почему 2 группы?

Потому что есть много тех, кто умеет хорошо отбивать атаки на уровне L3 / L4, но или вообще не берется за защиту на уровне приложения (L7), или пока справляется с ними слабее альтернатив.

Кто есть кто на рынке защиты от DDoS

(мой личный взгляд)

Защита на уровне L3/L4

Чтобы отбивать атаки с амплификацией («завал» канала сервера) хватает широких каналов (многие из сервисов защиты подключаются к большинству крупных магистральных провайдеров в России и обладают каналами с теоретической емкостью больше 1 Тбит). Не забываем, что очень редкие атаки с амплификацией длятся дольше часа. Если вы Spamhaus и вас все не любят — да, вам могут стараться положить каналы на несколько суток даже с риском для дальнейшего выживания используемого мирового ботнета. Если у вас просто интернет-магазин, даже если это mvideo.ru — 1 Тбит в течение нескольких суток вы увидите очень нескоро (надеюсь).

Чтобы отбивать атаки с SYN/ACK флудом, фрагментацией пакетов, етс, необходимо оборудование или софтверные системы для детекции и отсекания таких атак.

Такое оборудование производят многие (Arbor, есть решения у Cisco, Huawei, софтверные реализации от Wanguard и т.п.), многие магистральные операторы уже установили его и продают услуги защиты от DDoS (я знаю про инсталляции у Ростелеком, Мегафон, ТТК, МТС, по сути у всех крупных провайдеров, это же делают хостеры со своей защитой a-la OVH.com, Hetzner.de, сталкивался сам с защитой в ihor.ru). Некоторые компании разрабатывают свои софтверные решения (технологии типа DPDK позволяют обрабатывать трафик в десятки гигабит на одной физической x86 машине).

Из известных игроков более-менее эффективно L3/L4 DDoS отбивать умеют все. Я сейчас не скажу, у кого больше максимальная емкость канала (это инсайдерская информация), но обычно это не так важно, и разница только в том, насколько быстро срабатывает защита (мгновенно или через несколько минут даунтайма проекта, как в Hetzner).

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

Но при этом, исходя из моего опыта, все серьезные игроки на российском рынке с этим справляются без проблем: Qrator, DDoS-Guard, Kaspersky, G-Core Labs (бывший SkyParkCDN), ServicePipe, Stormwall, Voxility, etc.

С зарубежными операторами защиты компании в России работают редко, за исключением Cloudflare. Про Cloudflare напишу отдельно.

С защитой от операторов типа Ростелеком, Мегафон, ТТК, Билайн не сталкивался, по отзывам коллег они эти услуги оказывают достаточно качественно, но пока периодически сказывается недостаток опыта: иногда нужно что-нибудь докрутить через поддержку оператора защиты.
У некоторых операторов есть отдельная услуга «защита от атак на уровне L3/L4», или «защита каналов», она стоит намного дешевле защиты на всех уровнях.

Вот такие отчеты от вышестоящей L3/L4 защиты я регулярно получал, поддерживая системы хостинг-провайдера.

Защита на уровне L7 (уровень приложения)

Атаки на уровне L7 (уровень приложения) стабильно и качественно умеют отбивать единицы.
У меня есть реальный достаточно большой опыт с

• Qrator.net;
• DDoS-Guard;
• G-Core Labs;
• Kaspersky.

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

Реальный «царь горы» — Qrator.net, остальные от них несколько отстают. Qrator пока единственные в моей практике, кто дает близкий к нулю процент ложных срабатываний, но при этом они в несколько раз дороже остальных игроков рынка.

Качественная и стабильная защита есть и у других операторов. Многие сервисы на нашей поддержке (в т.ч. очень известные в стране!) стоят под защитой от DDoS-Guard, G-Core Labs, и вполне довольны получаемым результатом, могу их рекомендовать.

Атаки, отбитые Qrator

Есть еще опыт с небольшими операторами защиты типа cloud-shield.ru, ddosa.net и т.д. Однозначно рекомендовать не могу, т.к. опыт не очень велик, расскажу о принципах их работы. Стоимость защиты у них часто на 1-2 порядка ниже, чем у крупных игроков. Как правило, они покупают услугу частичной защиты (L3/L4) у кого-то из более крупных игроков + делают собственную защиту от атак на более высоких уровнях. Это может быть вполне эффективно + вы можете получить хороший сервис за меньшие деньги, но это все же небольшие компании с маленьким штатом, учтите, пожалуйста.

CloudFlare

CloudFlare — это отдельное явление. Это уже огромная компания, которая стоит несколько миллиардов долларов, их клиенты — половина трафикогенераторов мира, а услуга защиты от DDoS просто самая известная среди их услуг. Мы ими также постоянно пользуемся для DNS хостинга, CDN, в качестве сервиса проксирования трафика.

Для сайта/сервиса, на который не обрушиваются сложные атаки, Cloudflare вполне ок, но при серьезных атаках (когда не просто «заваливают» канал, а комбинируют много видов атак) их Business plan за 200 долларов нас никогда не спасал, а говорить про их Enterprise защиту для России нет смысла, дешевле и эффективнее обратиться к другим игрокам.
Почему так? Думаю, сложно делать массовый почти бесплатный сервис очень качественным.
Кстати, в CF работает много русскоязычных инженеров 🙂

Зарубежные операторы защиты

У меня реальный опыт когда-то был с Dragonara.net (когда-то самый крупный оператор защиты в мире), уже не существующим сейчас.
На Хабре уже много статей про современных операторов, я просто дам ссылку на свежий обзор: habr.com/ru/post/350384
Наверняка многие из них очень хороши, если проект нацелен не на российский рынок, но в России с ними есть проблемы.
Первая — эффективная защита должна быть как можно ближе к защищающемуся и должна учитывать локальные особенности (в России одни, в Китае вторые, в Южной Америке третьи).
Вторая причина: по-настоящему сложная и дорогая задача — это защита на уровне L7. И да, это дорого у всех, хорошую L7 защиту в принципе не много компаний в мире делает, и российские сервисы часто просто выигрывают конкуренцию.

В чем сложность отражения атак на уровне L7?

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

Когда-то хватало модуля nginx-testcookie, и его и сейчас хватает для отражения большого числа атак. Когда я работал в хостинг-индустрии, моя L7 защита была построена как раз на nginx-testcookie. Кстати, у Beget.ru, Netangels.ru, FastVPS.ru была похожая система.

Увы, атаки стали сложнее. testcookie использует проверки на ботов на базе JS, а многие современные боты умеют их успешно проходить.

Атакующие ботнеты также уникальны, и нужно учитывать особенности каждого крупного ботнета.
Амплификация, прямой флуд с ботнета, фильтрация трафика из разных стран (разная фильтрация для разных стран), SYN/ACK флуд, фрагментация пакетов, ICMP, http флуд, при этом на уровне приложения/http можно придумывать неограниченное число разных атак.

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

Чтобы правильно управляться с этим и корректно тюнить настройки фильтрации под разных пользователей, нужен большой опыт и квалифицированные кадры. Даже крупный оператор, решивший оказывать услуги защиты, не может «тупо закидать проблему деньгами»: опыт придется набивать на лежащих сайтах и ложных срабатываниях на легитимном трафике.

Для оператора защиты нет кнопки «отбить DDoS», есть большое число инструментов, ими нужно уметь пользоваться.

И еще один бонусный пример.

Сервер без защиты был заблокирован хостером при атаке емкостью в 600 мбит
(«Пропадание» трафика не заметно, т.к. атакован был только 1 сайт, его на время убрали с сервера и блокировка была снята в пределах часа).

Этот же сервер под защитой. Атакующие “сдались” после суток отбитых атак. Cама атака оказалась не самой сильной.

Атаки L3/L4 и защита от них более тривиальны, в основном, они зависят от толщины каналов, алгоритмов детекции и фильтрации атак.

Атаки L7 сложнее и оригинальнее, они зависят от атакуемого приложения, возможностей и фантазии атакующих. Защита от них требует больших знаний и опыта, причем результат может быть не сразу и не стопроцентный. Пока Гугл не придумал для защиты очередную нейросеть.

Источник

Методы борьбы с DDoS-атаками

Хотелось бы поговорить с вами на актуальную нынче тему, а именно — про DDoS и методы борьбы с ним. Рядовые администраторы знают, что это такое, а вот для большинства вебмастеров это аббревиатура остается загадкой до того момента пока они на личном опыте не столкнуться с этой неприятностью. Итак, DDoS — это сокращение от Distributed Denial of Service (распределенный отказ в обслуживании), когда тысячи зараженных компьютеров отправляют на сервер множество запросов, с которыми он, в последствии, не может справиться. Целью DDoS атаки является нарушение нормальной работы сервера, а в дальнейшем — «падение» сайта или сервера целиком.

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

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

Для защиты IIS серверов можно воспользоваться (программным) решением от компании Microsoft, но, зная щедрость этой компании, можно догадаться, что они тоже далеко не бесплатные.

В настоящее время, заказные DDoS-атаки превратились в выгодную и активно развивающуюся нишу сетевой преступности. Поискав в Google, можно найти десятки предложений от «специалистов» по устранению сайта конкурентов.

Какие же основные принципы по защите от DDoS? В первую очередь, не нужно привлекать к себе (своему сайту) лишнее внимание радикально настроенной общественности, публикуя контент, способный задеть расовые, национальные или религиозные чувства каких либо индивидов.

Если же вас «заказали», или вы не послушались предыдущего совета, будьте начеку — аппаратные ресурсы веб-сервера обязательно должны иметь некоторый резерв производительности, а распределенные и дублирующие системы — построены максимально эффективно. Без понимания принципов работы DDoS, эффективную защиту построить просто невозможно. Для осуществления DDoS-атак используется большое количество компьютеров, зараженных вредоносным кодом. Эти компьютеры объединяются в ботнеты (“bot-net” — сети зомби-машин), которые по приказу злоумышленника осуществляют DDoS-атаки, причем владельцы компьютеров зачастую даже не подозревают об этом.

Мы, как хостинг-компания, сталкиваемся с DDoS-атаками на сайты наших клиентов ежедневно и имеем некоторый опыт в борьбе с ними. Как было сказано выше, универсальных мер защиты попросту нет, но атаку все же можно отразить. Предположим, что на некий сайт (пусть это будет domain.ru) идет DDoS атака. По логам видно, что большое количество GET запросов идет на главную страницу. В большинстве таких случаев, ботов можно обмануть воспользовавшись javascript-редиректом. К примеру:

Как результат — с каждым разделом, который атакован GET запросом прямо в корень, размер файла получится всего несколько байт, что гораздо лучше, чем когда бот соприкасается c

50-100кб страницей и при этом подтягивает

5-10 SQL запросов. Легитимные же пользователи, у которых не отключен javascript в браузере, перенаправляются на index.php.

Но есть одно большое НО – поисковые-боты тоже не оборудованы js-интерпретаторами и точно так же, как и атакующие боты, будут утопать в js редиректе. Можно, воспользовавшись такими UNIX утилитами как tcpdump или netstat, написать небольшой скрипт, который будет считать кол-во коннектов с определенного IP адреса, и банить его.

Определить бота можно, например, проверив его host. Небольшой пример элементарного скрипта по блокировке IP, которые создают много коннектов к серверу (данный вариант проверялся на Centos 5.6):

*/1 * * * * netstat -an | grep tcp | awk ‘‘ | cut -d: -f1 | sort -n | uniq -c > /var/log/ip.list

Данная команда создает список с кол-вом подключений и самим IP, пример:

10 209.232.223.117
1 209.85.161.191
2 212.113.39.162
1 212.78.78.78
61 213.142.213.19
5 213.151.240.177
1 210.169.67.225
1 216.179.59.97

Сам скрипт, который можно запустить в screen-е или сделать демоном:

#!/bin/bash
connects=150 /dev/null 2>&1
then
// если в имени хоста есть слово google (у гугло-ботов это слово присутствует)
if echo $hostname | grep «google» > /dev/null 2>&1
then
// то добавляем его в белый список и делаем запись в лог
echo «$ip» >> /etc/white.list
echo `date +%H:%M_%d-%m-%Y` $ip «- ADDED TO WHITE LIST AS $hostname SEARCH BOT IP» >> /var/log/ddos_log
else
// если не гугл — блочим
route add $hostname reject
fi
fi
fi
done

Давайте также посмотрим и на настройки параметров Apache, которые помогут избежать некоторых проблем вызванных DDoS атакой.

TimeOut – указывайте как можно меньшее значение для данной директивы (веб сервера, который подвержен DDoS атаке).

KeepAliveTimeout директива – также нужно снизить ее значение или полностью выключить.

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

Директивы LimitRequestBody, LimitRequestFields, LimitRequestFieldSize, LimitRequestLine, LimitXMLRequestBody должны быть тщательно настроены на ограничение потребления ресурсов вызванных запросами клиентов.

Убедитесь, что вы используете директиву AcceptFilter (на ОС которые поддерживают ее). По умолчанию она включена в конфигурации Apache httpd, но для своей работы может потребовать пересборку с новыми настройками ядра вашей ОС (*nix, *bsd).

Используйте директиву MaxClients, чтобы указать максимальное количество клиентов, которые смогут быть одновременно подключены к серверу — уменьшив значение директивы вы сможете снизить нагрузку на web-сервер.

Защитится от DDoS можно и на программном уровне. В этом вам поможет бесплатный скрипт – DDoS Deflate. С его помощью можно легко избавится от детского флуда и DDoS. Скрипт использует команду «netstat» для обнаружения DDoS и флуда, после чего блокирует IP адреса вредителей с помощью фаервола iptables или apf. Но не стоит расслабляться и считать, что слабый DDoS не сможет нанести ущерб вашему серверу. Возьмем, к примеру, что атакующих зомби-машин всего 10-50, но все они с толстыми каналами, а Вы, как назло, уехали в командировку, или у вас десятки (а то и сотни) серверов, и Вы не успеваете физически “мониторить” их все. В таком случае, даже небольшое количество машин сможет “зафлудить” канал или заставить выйти из строя вебсервер apache, mysql, etc. Другое дело, когда администратор круглосуточно “мониторит” сервер и с легкостью обнаруживает атаки. Но такое бывает крайне редко, поэтому нужно подключить систему сигнализации, а процесс блокировки атакующих зомби-машин — автоматизировать.

Источник