Атаки в Интернете также за это время неплохо развили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 сложнее и оригинальнее, они зависят от атакуемого приложения, возможностей и фантазии атакующих. Защита от них требует больших знаний и опыта, причем результат может быть не сразу и не стопроцентный. Пока Гугл не придумал для защиты очередную нейросеть.
Комментарии (28)
vadimisakanov Автор
30.04.2019 12:59Расскажу про недостатки Qrator.
1. У них нет выделенной публичной услуги защиты каналов, они защищают сайты и сервисы.
Если у тебя туча сайтов на серверах — защита будет очень дорогой.
2. Они просто дорогие. Когда защита от DDoS становится дороже, чем вся инфраструктура вместе взятая, хз, нужна ли вам такая защита.
Про Cloudflare. Это дешевый сервис и хорош он как дешевый сервис, имхо, я про них как-то писал. Для защиты большого сервиса типа mvideo.ru он не годится (если инженеры КФ не будут пилить настройки для вас на Enterprise тарифе), либо будет стоить дороже DDoS-Guard, Qrator, etc.
С Incapsula дела не имел. На «Западе» сервисов защиты много, но на российском рынке эффективнее местные игроки — как минимум их точки присутствия находятся здесь, скорость работы намного выше.
Night_Snake
02.05.2019 01:09+1Маленькая ремарка: оценивать затраты на защиту стоит не по стоимости инфраструктуры, а по потерям бизнеса.
Сколько для вас будет стоить час, два, сутки простоя? Вот из этого и надо считать, сколько разумно будет потратить на защиту
vadimisakanov Автор
02.05.2019 08:42+2«У них нет выделенной публичной услуги защиты каналов»
Меня поправили, здесь ошибся: qrator.net/ru/solutions/infrastructure-protection
apapacy
30.04.2019 14:12+1С вашего позволения есть два замечания.
1. В обзорной (не рекламной) статье не упомянуть средство защиты CloudFare не совсем верно т.к. это первое что приходит в голову когда клиент начинает защищать сайт. Хотя я сам не сторонник CloudFare. Иначе действительно все начинает походить на рекламу а не на обзор доступных средств защиты.
2. Показатель «заблокировано ip» на Вашем скрине говорит не в пользу защиты. Т.к блокировать желательно клиентов а не ip адрес. И насколько я знаю существуют такие провайдеры услуги защиты которые именно это и делают. В противном случае пострадаю много много пользователей. И в конечном итоге — пострадает клиент.vadimisakanov Автор
30.04.2019 15:13спасибо
Добавлю про CloudFlare.
«заблокировано ip» — здесь есть проблема, мы не видим, что происходит на стороне сервиса фильтрации. Не знаем, на какое время происходит блокировка, и на основе каких именно принципов она выполняется. Я попробую пригласить коллег для комментария.
ximaera
30.04.2019 16:11+1Блокирование точнее, чем IP-адрес — это миф. Оно возможно в простых случаях (грубо говоря, когда бот не использует браузер), но в общем случае оно не работает и, наоборот, снижает время реакции на атаку.
На практике в IPv4, не говоря уже об IPv6, блокирование на уровни точности «IP-адрес» к проблемам пользователей приводит только в вырожденных единичных случаях, которые полезнее и правильнее решать по мере их возникновения.
flx
30.04.2019 15:47+2Привет,
Меня в этот статью пригласил vadimisakanov, с просьбой дать комментарий к «почему Qrator блокирует по IP адрес?»
Ответ прост — IP адрес, в отличие от меты протоколов приложения, подделать достаточно сложно. Из нашего опыта — блокировки per-client надежно осуществить невозможно. Если у Вас есть идеи как это можно сделать — с удовольствием вас послушаю ;)apapacy
30.04.2019 15:59+1Решения собственно два. Одно простое другое сложное
1) Простое которым пользуюсь я это давать тикеты с учетом User-Agent и пока ip+User-Agent не выходят за рамки пропускать запросы.
2) Сложное и которое по слухам юзают некоторые провайдеры защиты это анализ на основании поведения (на технологиях искуственого интеллекта).
Опять же по слухам некоторые продвинутые из них режут уже первый запрос от бота даже если этот бот headless chromeximaera
30.04.2019 16:201)
a) User-Agent у значительного числа пользователей эквивалентен актуальной на текущую дату версии Chrome. Если бот использует такой же браузер (или делает вид), вы его пропустите.
b) Более того, вы фактически даёте возможность боту генерировать тикеты на вашей стороне путём перебора User-Agent'ов, что приведёт либо к тому, что у вас кончится память под тикеты, либо к тому, что вы заблокируете все новые тикеты с IP-адреса, то есть, фактически, весь IP-адрес.
2) Анализ на основе поведения невозможно делать на основе одного запроса, нужна история, собственно, поведения. При этом, если вы пытаетесь банить с точностью менее чем IP-адрес, то бот может начать имитировать толпу пользователей, каждый из которых отправляет свой самый первый запрос к сайту, что тоже приведёт либо к исчерпанию у вас памяти, либо к блокированию IP-адреса целиком.
«Первый запрос от бота» возможно отрезать, если бот непохож на браузер. Это не «продвинутость», это как раз простейший вариант фильтрации, который есть примерно у всех. Но на браузерных ботов он в общем случае не работает.
P.S. "даже если этот бот headless chrome" — это странное заявление, Headless Chrome отнюдь не самый плохой случай :-)
flx
30.04.2019 16:232) мы делаем с самого рождения компании — обнаружение и нейтрализация с самого пилились как полностью автоматизированные фичи. и КМК у нас получается достаточно неплохо.
по слухам некоторые продвинутые явно брешут, ибо не имея истории наблюдений моделировать поведение невозможно ;) «с-первого-запроса» ага…
1) мы курили эту тему конечно, еще в 2009м. Только помимо UA можно и нужно доставать еще все что можно выгрести из DOM браузера. Вот только одна засада — эти сущности со стороны атакующих можно плодить в неограниченных количествах. Только IP адрес является ограниченным в доступности ресурсом, да и и тот с определенными ограничениями.
TimsTims
02.05.2019 01:41с удовольствием вас послушаю
На ум приходит всё то же самое, что происходит с интернет рекламой: cookie-следилки. Как известно, у браузера есть большой цифровой след — куча разных cookies разных рекламных агентств, которые следят за твоими перемещениями по интернету. Если ты человек, то обычно, у тебя довольно большой след, и если при входе на атакуемый сайт вы сделаете запрос в не сколько рекламных площадок — «а какой уровень истории у этого пользователя?» то вероятно, вы сможете лучше отсекать ботов от не ботов. Конечно, и ботам можно накрутить историю посещений, но кмк это лучше, чем анализ действий на одном (атакуемом) сайте.
flx
30.04.2019 15:49+1p.s. кстати, прикольная статья «из окопов». CloudFlare, кстати, это странное продуктовое позиционирование. Зачем продавать услугу заказчику которому «дешевле полежать»?
А CDN у них и правда неплох ;)
vadimisakanov Автор
30.04.2019 16:39Про рекламу Qrator. Я честно попробовал пригласить в комментарии представителей других компаний (не в первый раз), но быстрее откликнулись ребята из Куратор. Другие компании тоже вполне неплохи, повторю, просто это говорит, например, о закрытости рынка. Не всем комфортно обсуждать, «чего там внутри» в их системах защиты.
kankord
01.05.2019 14:14Уважаемый автор прав — не комфортно и может даже не совсем разумно обсуждать подкапотные внутренности с коллегами по отрасли.
Клиентам всегда доступно больше информации.
STAY
30.04.2019 16:41Не стоит еще забывать про Imperva и Akamai с их Anti DDoS Protection, и конечно про упомянутую уже в комментариях Cloudflare. На рынке с 2008, а сильных игроков не знаете.
vadimisakanov Автор
30.04.2019 16:44В моем шортлисте сначала было ~50 компаний, только читать такой список сложнее. Я еще Dragonara помню, например ) Про игроков типа Akamai добавлю позже.
Под защитой CloudFlare стоит 2/3 сайтов, которые мы поддерживаем и которые в принципе стоят под защитой. Просто самые лучшие фичи у них — это не только защита )))
Night_Snake
02.05.2019 01:14Akamai и Imperva достаточно дорогие, особенно если брать always-on защиту.
Плюс, как и у всяких больших компаний, у них периодически недостаёт гибкости
SKRSKR
30.04.2019 22:05-1DDG/Qrator просто демо-версии нормальных защит как OVH/Cloudflare, при этом первый предоставляет 500/1000мбит безлимитного трафика с защитой бесплатно, которая держит даже на услугах за 200 руб 1тбит SYN, в РФ никто даже 300гбит SYN не потянет за любые деньги.
vadimisakanov Автор
30.04.2019 22:21+1Назовете компании в Рунете с сервисами, каждая минута простоя которых стоит пусть тысячи рублей (не говоря о миллионах), которые используют защиту от OVH & Cloudflare как основную?
Повторю, 2/3 наших клиентов стоят под защитой от СloudFlare. Мы их часто используем как сервис DNS хостинга, CDN, для прозрачного проксирования всех запросов (чтобы быстро переключать бэкенд серверы). Но при серьезных атаках обычно приходится переключаться на другие сервисы.
Каждому сервису свой клиент. Для не сложных атак и не самых критичных сервисов OVH & Cloudflare отлично подойдут. Защита похожего класса сейчас есть у многих российских хостеров, кстати, только каналы у них меньше.
Насчет 300 гбит — мои коллеги сталкивались в России с отбитыми атаками суммарной емкостью больше 400 гбит, это было в в 2017 году. Сейчас объемы выросли.
Вообще когда атаки становятся серьезнее — это будет не 1 терабит synflood, его никто в современном интернете не сгенерирует))) Но любой SYN/ACK флуд с амплификацией отбивать легче и намного дешевле, чем хороший http флуд, имитирующий реальных посетителей. OVH & Cloudflare большую его часть пропустят, и здесь ваша работа как администратора конечной инфраструктуры станет сложной.SKRSKR
01.05.2019 03:28Если включить у cloudflare кеш, настроить ratelimit, то его никто не положит, ибо весь контент будет отдаваться с серверов cloudflare которых крайне много, при этом работа сайта станет значительно быстрее) Но чтобы правильно такое настроить нужно иметь руки с правильного места, поэтому сервисам проще закинуть кратору 500к и они будут сами защищать ели живой сайт который даже 1гбит не отдаст. Про SYN наверно погорячился, но на овх уже бывали атаки 1+тбит, по TCP, которые DDG/Qrator не отобьет.
flx
30.04.2019 23:56сэр, SYN-flood обычно измеряют в pps а не в bps ;)
рассказать почему?
Valsha
Это реклама Qrator? А то в статье начало «из wiki”, а потом реклама Qrator. Все! Это вся ценность статьи! Никаких анализов с CloudFlare/Incapsula и аналогичных сервисов, или они тоже маленькие по вашему?
vadimisakanov Автор
Не, не реклама Qrator.
Один из скриншотов из G-Core Labs (SkyparkCDN).
Спасибо, я посмотрю, стоит ли чтото изменить в статье.