Есть множество различных причин, по которым может возникать потребность в ограничении к автоматическому доступу к информации:
парсеры нагружают ресурс, и эта нагрузка может составлять до 50% от трафика
информацию можно использовать для получения конкурентных преимуществ, например для поднятия своего предложения в товарном аггрегаторе при сортировке по цене
И так далее. Аргумент про то, что все равно достанут, вечен. Как и противостояние снаряда и брони. Остановить нельзя, можно только продолжать совершенствовать технологии.
Пиксель нужен для разметки, не для блокировки. Для блокировки нужно вставать на фильтрацию, при этом можно как пропускать через нас трафик, так и работать по более сложным схемам интеграции.
Я не вполне понимаю ваш вопрос. Разумеется статистика есть в нашем ЛК, но это аггрегированные данные. При этом мы даем возможность оперативно запросить вердикт по каждому отдельному запросу — для этого в запрос на пиксель можно встроить идентификаторы, для этого существует оперативное хранение результатов.
Смысл в том, чтобы компания, разместившая пиксель, могла оценить объем ботового трафика и узнать, было ли конкретное посещение страницы «человеческим».
Резать подобные атаки должен хотя бы WAF или какая-то аналогичная мера, а сам сайт/CMS лишь «страховать».
WAF, как правило, не лучшее решение в таком случае. Он хорошо фильтрует некорректные и «необычные» запросы к сайту, мы же тут говорим про абсолютно легитимные с точки зрения структуры и сессии запросы.
Звучит так, будто вместо код-ревью и вообще «работы над ошибками» вы предлагаете приделать какие-то «решения по защите от...», в итоге получая, по сути, костыли, да ещё и по ежемесячному тарифу.
… и уже потом начать платить сторонним конторам для обеспечения того функционала, за который они сначала не хотели платить нанятому разработчику?
Решения по защите разумно подключать в любом случае — своей инфраструктурой вы от атак не отобьетесь. В случае подбора логина-пароля, достаточно частотной и неприятной атакой является следующая: в интернет утекает очередная база со взломанного сайта и далее она проверяется на сайте с распределенного ботнета. Каждый раз у вас уникальный логин, пароль и IP — защититься средствами CMS/WAF вряд ли получится.
Да, мы стремимся к тому, чтобы уметь отрезать 100% ботовых запросов. И да, у нас есть успешные примеры фильтрации как раз таких массовых обращений к ресурсу с помощью headless chrome через ботнет.
С точки зрения идеального устройства мира так наверное и должно быть. К сожалению есть большое число сайтов, которые написаны неидеально или начинающими разработчиками. Или просто при разработке решили сэкономить и добавить все это «потом».
Мы проводим такое разделение потому, что в основном сейчас нагрузочное тестирование воспринимается исключительно как тестирование на максимальное количество условных пользователей. Т.е. производится эмуляция поведения пользователей на сайте.
видимо имеется ввиду тестирование производительности или стабильности?
Имеется ввиду как раз тестирование с помощью одного из распространенных бесплатных веб-инструментов.
не совсем понятен смысл сказанного.
если сервис падает от 1rps, то его надо брать и выбрасывать на свалку.
А если 10? а 20? Очевидно, что если стрелять в корень — то отказ будет на одном потоке, если спамить комментариями — совсем на другом. Речь идет о поиске запроса (или их комплекса), который максимально нагружает ресурс.
Собственно мы и сами с другой стороны баррикад.
По поводу хонипотов — нет, не сталкивались. Но это не будет проблемой, так как мы специально ограничиваем атаку, и перенаправить её редиректами на внешние ресурсы нельзя. А со своих начать отдавать сотни мегабайт — не самая хорошая идея, так как наши каналы заведомо толще. Или, в случае с реальной атакой, каналы ботнета.
И так далее. Аргумент про то, что все равно достанут, вечен. Как и противостояние снаряда и брони. Остановить нельзя, можно только продолжать совершенствовать технологии.
WAF, как правило, не лучшее решение в таком случае. Он хорошо фильтрует некорректные и «необычные» запросы к сайту, мы же тут говорим про абсолютно легитимные с точки зрения структуры и сессии запросы.
Решения по защите разумно подключать в любом случае — своей инфраструктурой вы от атак не отобьетесь. В случае подбора логина-пароля, достаточно частотной и неприятной атакой является следующая: в интернет утекает очередная база со взломанного сайта и далее она проверяется на сайте с распределенного ботнета. Каждый раз у вас уникальный логин, пароль и IP — защититься средствами CMS/WAF вряд ли получится.
Имеется ввиду как раз тестирование с помощью одного из распространенных бесплатных веб-инструментов.
А если 10? а 20? Очевидно, что если стрелять в корень — то отказ будет на одном потоке, если спамить комментариями — совсем на другом. Речь идет о поиске запроса (или их комплекса), который максимально нагружает ресурс.
По поводу хонипотов — нет, не сталкивались. Но это не будет проблемой, так как мы специально ограничиваем атаку, и перенаправить её редиректами на внешние ресурсы нельзя. А со своих начать отдавать сотни мегабайт — не самая хорошая идея, так как наши каналы заведомо толще. Или, в случае с реальной атакой, каналы ботнета.