Comments 33
Это реклама Qrator? А то в статье начало «из wiki”, а потом реклама Qrator. Все! Это вся ценность статьи! Никаких анализов с CloudFlare/Incapsula и аналогичных сервисов, или они тоже маленькие по вашему?
Расскажу про недостатки Qrator.
1. У них нет выделенной публичной услуги защиты каналов, они защищают сайты и сервисы.
Если у тебя туча сайтов на серверах — защита будет очень дорогой.
2. Они просто дорогие. Когда защита от DDoS становится дороже, чем вся инфраструктура вместе взятая, хз, нужна ли вам такая защита.
Про Cloudflare. Это дешевый сервис и хорош он как дешевый сервис, имхо, я про них как-то писал. Для защиты большого сервиса типа mvideo.ru он не годится (если инженеры КФ не будут пилить настройки для вас на Enterprise тарифе), либо будет стоить дороже DDoS-Guard, Qrator, etc.
С Incapsula дела не имел. На «Западе» сервисов защиты много, но на российском рынке эффективнее местные игроки — как минимум их точки присутствия находятся здесь, скорость работы намного выше.
1. У них нет выделенной публичной услуги защиты каналов, они защищают сайты и сервисы.
Если у тебя туча сайтов на серверах — защита будет очень дорогой.
2. Они просто дорогие. Когда защита от DDoS становится дороже, чем вся инфраструктура вместе взятая, хз, нужна ли вам такая защита.
Про Cloudflare. Это дешевый сервис и хорош он как дешевый сервис, имхо, я про них как-то писал. Для защиты большого сервиса типа mvideo.ru он не годится (если инженеры КФ не будут пилить настройки для вас на Enterprise тарифе), либо будет стоить дороже DDoS-Guard, Qrator, etc.
С Incapsula дела не имел. На «Западе» сервисов защиты много, но на российском рынке эффективнее местные игроки — как минимум их точки присутствия находятся здесь, скорость работы намного выше.
Маленькая ремарка: оценивать затраты на защиту стоит не по стоимости инфраструктуры, а по потерям бизнеса.
Сколько для вас будет стоить час, два, сутки простоя? Вот из этого и надо считать, сколько разумно будет потратить на защиту
Сколько для вас будет стоить час, два, сутки простоя? Вот из этого и надо считать, сколько разумно будет потратить на защиту
«У них нет выделенной публичной услуги защиты каналов»
Меня поправили, здесь ошибся: qrator.net/ru/solutions/infrastructure-protection
Меня поправили, здесь ошибся: qrator.net/ru/solutions/infrastructure-protection
С вашего позволения есть два замечания.
1. В обзорной (не рекламной) статье не упомянуть средство защиты CloudFare не совсем верно т.к. это первое что приходит в голову когда клиент начинает защищать сайт. Хотя я сам не сторонник CloudFare. Иначе действительно все начинает походить на рекламу а не на обзор доступных средств защиты.
2. Показатель «заблокировано ip» на Вашем скрине говорит не в пользу защиты. Т.к блокировать желательно клиентов а не ip адрес. И насколько я знаю существуют такие провайдеры услуги защиты которые именно это и делают. В противном случае пострадаю много много пользователей. И в конечном итоге — пострадает клиент.
1. В обзорной (не рекламной) статье не упомянуть средство защиты CloudFare не совсем верно т.к. это первое что приходит в голову когда клиент начинает защищать сайт. Хотя я сам не сторонник CloudFare. Иначе действительно все начинает походить на рекламу а не на обзор доступных средств защиты.
2. Показатель «заблокировано ip» на Вашем скрине говорит не в пользу защиты. Т.к блокировать желательно клиентов а не ip адрес. И насколько я знаю существуют такие провайдеры услуги защиты которые именно это и делают. В противном случае пострадаю много много пользователей. И в конечном итоге — пострадает клиент.
спасибо
Добавлю про CloudFlare.
«заблокировано ip» — здесь есть проблема, мы не видим, что происходит на стороне сервиса фильтрации. Не знаем, на какое время происходит блокировка, и на основе каких именно принципов она выполняется. Я попробую пригласить коллег для комментария.
Добавлю про CloudFlare.
«заблокировано ip» — здесь есть проблема, мы не видим, что происходит на стороне сервиса фильтрации. Не знаем, на какое время происходит блокировка, и на основе каких именно принципов она выполняется. Я попробую пригласить коллег для комментария.
Блокирование точнее, чем IP-адрес — это миф. Оно возможно в простых случаях (грубо говоря, когда бот не использует браузер), но в общем случае оно не работает и, наоборот, снижает время реакции на атаку.
На практике в IPv4, не говоря уже об IPv6, блокирование на уровни точности «IP-адрес» к проблемам пользователей приводит только в вырожденных единичных случаях, которые полезнее и правильнее решать по мере их возникновения.
На практике в IPv4, не говоря уже об IPv6, блокирование на уровни точности «IP-адрес» к проблемам пользователей приводит только в вырожденных единичных случаях, которые полезнее и правильнее решать по мере их возникновения.
Блокировка IP-адресов = потенциальная потеря сотен тысяч живых клиентов за NAT сетями, а это как минимум пользователи всех публичных WiFi и мобильных операторов.
Есть на рынке компании, которые эффективно блокируют только бот-запросы (да, кстати, с самого первого), оставляя живых пользователей работать с защищаемым ресурсом.
Упомянутый G-Core использует такую защиту ;)
Есть на рынке компании, которые эффективно блокируют только бот-запросы (да, кстати, с самого первого), оставляя живых пользователей работать с защищаемым ресурсом.
Упомянутый G-Core использует такую защиту ;)
«Потенциальная», но на практике в моём практически 10-летнем опыте такого не было, а по мере распространения IPv6 эта проблема вообще уйдёт в прошлое.
Компаний, способных эффективно блокировать любых ботов с самого первого запроса, на рынке не существует, поскольку такое решение теоретически построить невозможно. В маркетинговых материалах написать можно, а вот сделать — нет, что легко демонстрируется.
Ну а блокировать некоторых ботов за один запрос, конечно, можно, мы это делаем и многие другие делают. Но это работает только против простеньких злоумышленников, продвинутые легко обойдут такую «защиту».
Компаний, способных эффективно блокировать любых ботов с самого первого запроса, на рынке не существует, поскольку такое решение теоретически построить невозможно. В маркетинговых материалах написать можно, а вот сделать — нет, что легко демонстрируется.
Ну а блокировать некоторых ботов за один запрос, конечно, можно, мы это делаем и многие другие делают. Но это работает только против простеньких злоумышленников, продвинутые легко обойдут такую «защиту».
Привет,
Меня в этот статью пригласил vadimisakanov, с просьбой дать комментарий к «почему Qrator блокирует по IP адрес?»
Ответ прост — IP адрес, в отличие от меты протоколов приложения, подделать достаточно сложно. Из нашего опыта — блокировки per-client надежно осуществить невозможно. Если у Вас есть идеи как это можно сделать — с удовольствием вас послушаю ;)
Меня в этот статью пригласил vadimisakanov, с просьбой дать комментарий к «почему Qrator блокирует по IP адрес?»
Ответ прост — IP адрес, в отличие от меты протоколов приложения, подделать достаточно сложно. Из нашего опыта — блокировки per-client надежно осуществить невозможно. Если у Вас есть идеи как это можно сделать — с удовольствием вас послушаю ;)
Решения собственно два. Одно простое другое сложное
1) Простое которым пользуюсь я это давать тикеты с учетом User-Agent и пока ip+User-Agent не выходят за рамки пропускать запросы.
2) Сложное и которое по слухам юзают некоторые провайдеры защиты это анализ на основании поведения (на технологиях искуственого интеллекта).
Опять же по слухам некоторые продвинутые из них режут уже первый запрос от бота даже если этот бот headless chrome
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 отнюдь не самый плохой случай :-)
a) User-Agent у значительного числа пользователей эквивалентен актуальной на текущую дату версии Chrome. Если бот использует такой же браузер (или делает вид), вы его пропустите.
b) Более того, вы фактически даёте возможность боту генерировать тикеты на вашей стороне путём перебора User-Agent'ов, что приведёт либо к тому, что у вас кончится память под тикеты, либо к тому, что вы заблокируете все новые тикеты с IP-адреса, то есть, фактически, весь IP-адрес.
2) Анализ на основе поведения невозможно делать на основе одного запроса, нужна история, собственно, поведения. При этом, если вы пытаетесь банить с точностью менее чем IP-адрес, то бот может начать имитировать толпу пользователей, каждый из которых отправляет свой самый первый запрос к сайту, что тоже приведёт либо к исчерпанию у вас памяти, либо к блокированию IP-адреса целиком.
«Первый запрос от бота» возможно отрезать, если бот непохож на браузер. Это не «продвинутость», это как раз простейший вариант фильтрации, который есть примерно у всех. Но на браузерных ботов он в общем случае не работает.
P.S. "даже если этот бот headless chrome" — это странное заявление, Headless Chrome отнюдь не самый плохой случай :-)
2) мы делаем с самого рождения компании — обнаружение и нейтрализация с самого пилились как полностью автоматизированные фичи. и КМК у нас получается достаточно неплохо.
по слухам некоторые продвинутые явно брешут, ибо не имея истории наблюдений моделировать поведение невозможно ;) «с-первого-запроса» ага…
1) мы курили эту тему конечно, еще в 2009м. Только помимо UA можно и нужно доставать еще все что можно выгрести из DOM браузера. Вот только одна засада — эти сущности со стороны атакующих можно плодить в неограниченных количествах. Только IP адрес является ограниченным в доступности ресурсом, да и и тот с определенными ограничениями.
по слухам некоторые продвинутые явно брешут, ибо не имея истории наблюдений моделировать поведение невозможно ;) «с-первого-запроса» ага…
1) мы курили эту тему конечно, еще в 2009м. Только помимо UA можно и нужно доставать еще все что можно выгрести из DOM браузера. Вот только одна засада — эти сущности со стороны атакующих можно плодить в неограниченных количествах. Только IP адрес является ограниченным в доступности ресурсом, да и и тот с определенными ограничениями.
с удовольствием вас послушаюНа ум приходит всё то же самое, что происходит с интернет рекламой: cookie-следилки. Как известно, у браузера есть большой цифровой след — куча разных cookies разных рекламных агентств, которые следят за твоими перемещениями по интернету. Если ты человек, то обычно, у тебя довольно большой след, и если при входе на атакуемый сайт вы сделаете запрос в не сколько рекламных площадок — «а какой уровень истории у этого пользователя?» то вероятно, вы сможете лучше отсекать ботов от не ботов. Конечно, и ботам можно накрутить историю посещений, но кмк это лучше, чем анализ действий на одном (атакуемом) сайте.
p.s. кстати, прикольная статья «из окопов». CloudFlare, кстати, это странное продуктовое позиционирование. Зачем продавать услугу заказчику которому «дешевле полежать»?
А CDN у них и правда неплох ;)
А CDN у них и правда неплох ;)
Про рекламу Qrator. Я честно попробовал пригласить в комментарии представителей других компаний (не в первый раз), но быстрее откликнулись ребята из Куратор. Другие компании тоже вполне неплохи, повторю, просто это говорит, например, о закрытости рынка. Не всем комфортно обсуждать, «чего там внутри» в их системах защиты.
Не стоит еще забывать про Imperva и Akamai с их Anti DDoS Protection, и конечно про упомянутую уже в комментариях Cloudflare. На рынке с 2008, а сильных игроков не знаете.
В моем шортлисте сначала было ~50 компаний, только читать такой список сложнее. Я еще Dragonara помню) Про игроков типа Akamai добавлю позже.
Под защитой CloudFlare стоит 2/3 сайтов, которые мы поддерживаем и которые в принципе стоят под защитой. Просто самые лучшие фичи у них — это не защита )))
Под защитой 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 большую его часть пропустят, и здесь ваша работа как администратора конечной инфраструктуры станет сложной.
Повторю, 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 ;)
рассказать почему?
рассказать почему?
Коллеги, хотел бы попросить по возможности не подкалывать друг друга (суть подколов все равно не понятна большинству читателей), а объяснить потенциальным клиентам, как работает правильная система защиты с вашей точки зрения.
Это в наших общих интересах, для этого я и писал статью.
Это в наших общих интересах, для этого я и писал статью.
Sign up to leave a comment.
Что есть что и кто есть кто на рынке защиты от DDoS