Comments 33
Это реклама Qrator? А то в статье начало «из wiki”, а потом реклама Qrator. Все! Это вся ценность статьи! Никаких анализов с CloudFlare/Incapsula и аналогичных сервисов, или они тоже маленькие по вашему?
Не, не реклама Qrator.
Один из скриншотов из G-Core Labs (SkyparkCDN).
Спасибо, я посмотрю, стоит ли чтото изменить в статье.
Расскажу про недостатки Qrator.
1. У них нет выделенной публичной услуги защиты каналов, они защищают сайты и сервисы.
Если у тебя туча сайтов на серверах — защита будет очень дорогой.
2. Они просто дорогие. Когда защита от DDoS становится дороже, чем вся инфраструктура вместе взятая, хз, нужна ли вам такая защита.

Про Cloudflare. Это дешевый сервис и хорош он как дешевый сервис, имхо, я про них как-то писал. Для защиты большого сервиса типа mvideo.ru он не годится (если инженеры КФ не будут пилить настройки для вас на Enterprise тарифе), либо будет стоить дороже DDoS-Guard, Qrator, etc.
С Incapsula дела не имел. На «Западе» сервисов защиты много, но на российском рынке эффективнее местные игроки — как минимум их точки присутствия находятся здесь, скорость работы намного выше.
Маленькая ремарка: оценивать затраты на защиту стоит не по стоимости инфраструктуры, а по потерям бизнеса.
Сколько для вас будет стоить час, два, сутки простоя? Вот из этого и надо считать, сколько разумно будет потратить на защиту
С вашего позволения есть два замечания.
1. В обзорной (не рекламной) статье не упомянуть средство защиты CloudFare не совсем верно т.к. это первое что приходит в голову когда клиент начинает защищать сайт. Хотя я сам не сторонник CloudFare. Иначе действительно все начинает походить на рекламу а не на обзор доступных средств защиты.
2. Показатель «заблокировано ip» на Вашем скрине говорит не в пользу защиты. Т.к блокировать желательно клиентов а не ip адрес. И насколько я знаю существуют такие провайдеры услуги защиты которые именно это и делают. В противном случае пострадаю много много пользователей. И в конечном итоге — пострадает клиент.
спасибо
Добавлю про CloudFlare.

«заблокировано ip» — здесь есть проблема, мы не видим, что происходит на стороне сервиса фильтрации. Не знаем, на какое время происходит блокировка, и на основе каких именно принципов она выполняется. Я попробую пригласить коллег для комментария.
Блокирование точнее, чем IP-адрес — это миф. Оно возможно в простых случаях (грубо говоря, когда бот не использует браузер), но в общем случае оно не работает и, наоборот, снижает время реакции на атаку.

На практике в IPv4, не говоря уже об IPv6, блокирование на уровни точности «IP-адрес» к проблемам пользователей приводит только в вырожденных единичных случаях, которые полезнее и правильнее решать по мере их возникновения.
Блокировка IP-адресов = потенциальная потеря сотен тысяч живых клиентов за NAT сетями, а это как минимум пользователи всех публичных WiFi и мобильных операторов.
Есть на рынке компании, которые эффективно блокируют только бот-запросы (да, кстати, с самого первого), оставляя живых пользователей работать с защищаемым ресурсом.
Упомянутый G-Core использует такую защиту ;)
«Потенциальная», но на практике в моём практически 10-летнем опыте такого не было, а по мере распространения IPv6 эта проблема вообще уйдёт в прошлое.

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

Ну а блокировать некоторых ботов за один запрос, конечно, можно, мы это делаем и многие другие делают. Но это работает только против простеньких злоумышленников, продвинутые легко обойдут такую «защиту».
Привет,
Меня в этот статью пригласил vadimisakanov, с просьбой дать комментарий к «почему Qrator блокирует по IP адрес?»

Ответ прост — IP адрес, в отличие от меты протоколов приложения, подделать достаточно сложно. Из нашего опыта — блокировки per-client надежно осуществить невозможно. Если у Вас есть идеи как это можно сделать — с удовольствием вас послушаю ;)
Решения собственно два. Одно простое другое сложное
1) Простое которым пользуюсь я это давать тикеты с учетом User-Agent и пока ip+User-Agent не выходят за рамки пропускать запросы.
2) Сложное и которое по слухам юзают некоторые провайдеры защиты это анализ на основании поведения (на технологиях искуственого интеллекта).
Опять же по слухам некоторые продвинутые из них режут уже первый запрос от бота даже если этот бот headless chrome
1)
a) User-Agent у значительного числа пользователей эквивалентен актуальной на текущую дату версии Chrome. Если бот использует такой же браузер (или делает вид), вы его пропустите.
b) Более того, вы фактически даёте возможность боту генерировать тикеты на вашей стороне путём перебора User-Agent'ов, что приведёт либо к тому, что у вас кончится память под тикеты, либо к тому, что вы заблокируете все новые тикеты с IP-адреса, то есть, фактически, весь IP-адрес.

2) Анализ на основе поведения невозможно делать на основе одного запроса, нужна история, собственно, поведения. При этом, если вы пытаетесь банить с точностью менее чем IP-адрес, то бот может начать имитировать толпу пользователей, каждый из которых отправляет свой самый первый запрос к сайту, что тоже приведёт либо к исчерпанию у вас памяти, либо к блокированию IP-адреса целиком.

«Первый запрос от бота» возможно отрезать, если бот непохож на браузер. Это не «продвинутость», это как раз простейший вариант фильтрации, который есть примерно у всех. Но на браузерных ботов он в общем случае не работает.

P.S. "даже если этот бот headless chrome" — это странное заявление, Headless Chrome отнюдь не самый плохой случай :-)
2) мы делаем с самого рождения компании — обнаружение и нейтрализация с самого пилились как полностью автоматизированные фичи. и КМК у нас получается достаточно неплохо.

по слухам некоторые продвинутые явно брешут, ибо не имея истории наблюдений моделировать поведение невозможно ;) «с-первого-запроса» ага…

1) мы курили эту тему конечно, еще в 2009м. Только помимо UA можно и нужно доставать еще все что можно выгрести из DOM браузера. Вот только одна засада — эти сущности со стороны атакующих можно плодить в неограниченных количествах. Только IP адрес является ограниченным в доступности ресурсом, да и и тот с определенными ограничениями.
с удовольствием вас послушаю
На ум приходит всё то же самое, что происходит с интернет рекламой: cookie-следилки. Как известно, у браузера есть большой цифровой след — куча разных cookies разных рекламных агентств, которые следят за твоими перемещениями по интернету. Если ты человек, то обычно, у тебя довольно большой след, и если при входе на атакуемый сайт вы сделаете запрос в не сколько рекламных площадок — «а какой уровень истории у этого пользователя?» то вероятно, вы сможете лучше отсекать ботов от не ботов. Конечно, и ботам можно накрутить историю посещений, но кмк это лучше, чем анализ действий на одном (атакуемом) сайте.
Не работает: бот, как правило, находится на заражённом компьютере или телефоне, то есть, на чьём-то персональном компьютере или телефоне, и может использовать весь накопленный трек браузера.

Ну то есть, опять же, в вырожденных простеньких случаях срабатывает, да. Пока за вас не взялись всерьёз.
p.s. кстати, прикольная статья «из окопов». CloudFlare, кстати, это странное продуктовое позиционирование. Зачем продавать услугу заказчику которому «дешевле полежать»?

А CDN у них и правда неплох ;)
Про рекламу Qrator. Я честно попробовал пригласить в комментарии представителей других компаний (не в первый раз), но быстрее откликнулись ребята из Куратор. Другие компании тоже вполне неплохи, повторю, просто это говорит, например, о закрытости рынка. Не всем комфортно обсуждать, «чего там внутри» в их системах защиты.
Уважаемый автор прав — не комфортно и может даже не совсем разумно обсуждать подкапотные внутренности с коллегами по отрасли.
Клиентам всегда доступно больше информации.
Я лично не понимаю, что тут может быть некомфортного. В частности, клиент наверняка должен насторожиться, если ему предлагают подписать NDA ещё до того, как расскажут про техническое решение :-)

Индустрия должна быть прозрачной, и в этом должен быть вклад каждого без исключения игрока.
Не стоит еще забывать про Imperva и Akamai с их Anti DDoS Protection, и конечно про упомянутую уже в комментариях Cloudflare. На рынке с 2008, а сильных игроков не знаете.
В моем шортлисте сначала было ~50 компаний, только читать такой список сложнее. Я еще Dragonara помню) Про игроков типа Akamai добавлю позже.
Под защитой CloudFlare стоит 2/3 сайтов, которые мы поддерживаем и которые в принципе стоят под защитой. Просто самые лучшие фичи у них — это не защита )))
Akamai и Imperva достаточно дорогие, особенно если брать always-on защиту.
Плюс, как и у всяких больших компаний, у них периодически недостаёт гибкости
DDG/Qrator просто демо-версии нормальных защит как OVH/Cloudflare, при этом первый предоставляет 500/1000мбит безлимитного трафика с защитой бесплатно, которая держит даже на услугах за 200 руб 1тбит SYN, в РФ никто даже 300гбит SYN не потянет за любые деньги.
Назовете компании в Рунете с сервисами, каждая минута простоя которых стоит пусть тысячи рублей (не говоря о миллионах), которые используют защиту от OVH & Cloudflare как основную?
Повторю, 2/3 наших клиентов стоят под защитой от СloudFlare. Мы их часто используем как сервис DNS хостинга, CDN, для прозрачного проксирования всех запросов (чтобы быстро переключать бэкенд серверы). Но при серьезных атаках обычно приходится переключаться на другие сервисы.

Каждому сервису свой клиент. Для не сложных атак и не самых критичных сервисов OVH & Cloudflare отлично подойдут. Защита похожего класса сейчас есть у многих российских хостеров, кстати, только каналы у них меньше.
Насчет 300 гбит — мои коллеги сталкивались в России с отбитыми атаками суммарной емкостью больше 400 гбит, это было в в 2017 году. Сейчас объемы выросли.

Вообще когда атаки становятся серьезнее — это будет не 1 терабит synflood, его никто в современном интернете не сгенерирует))) Но любой SYN/ACK флуд с амплификацией отбивать легче и намного дешевле, чем хороший http флуд, имитирующий реальных посетителей. OVH & Cloudflare большую его часть пропустят, и здесь ваша работа как администратора конечной инфраструктуры станет сложной.
Если включить у cloudflare кеш, настроить ratelimit, то его никто не положит, ибо весь контент будет отдаваться с серверов cloudflare которых крайне много, при этом работа сайта станет значительно быстрее) Но чтобы правильно такое настроить нужно иметь руки с правильного места, поэтому сервисам проще закинуть кратору 500к и они будут сами защищать ели живой сайт который даже 1гбит не отдаст. Про SYN наверно погорячился, но на овх уже бывали атаки 1+тбит, по TCP, которые DDG/Qrator не отобьет.
сэр, SYN-flood обычно измеряют в pps а не в bps ;)
рассказать почему?
Если разбираетесь, то можете прикинуть примерный pps по трафику, и это была не SYN атака в 1+тбит, извиняюсь.
в том то и дело что это был ack flood пакетами с MTU 1500.
вам, похоже, разница не очевидна ;)
Коллеги, хотел бы попросить по возможности не подкалывать друг друга (суть подколов все равно не понятна большинству читателей), а объяснить потенциальным клиентам, как работает правильная система защиты с вашей точки зрения.
Это в наших общих интересах, для этого я и писал статью.
Only those users with full accounts are able to leave comments. Log in, please.
Information
Founded

February 22, 2008

Location

Россия

Employees

31–50 человек

Registered

15 November 2012