Comments 7
Ой как мне близка эта тема. С другой стороны баррикад :)
Я бы еще добавил бы тесты на тему «персистенс сессий». Некоторые аппликейшен сервера чувствительны к такого рода атакам.
Блокировка по айпи, это же какой то каменный век. Мало того, я видел атаки, которые как раз и имели перед собой цель, заставить заблокировать большие диапазоны адресов.
Вопрос: механизм обнаружения хонипотов у вас реализован? Не было случаев, когда вместо блокировок, тестируемая система, накопив аналитику, редиректерила ваших ботов на уровне l7 на внешние ссылки размером под многие сотни мегабайт? :)
Я бы еще добавил бы тесты на тему «персистенс сессий». Некоторые аппликейшен сервера чувствительны к такого рода атакам.
Если возвращаться к примеру интернет-магазина: допустим, сайт торгует автомобильной резиной и позволяет задавать радиус шин, тип машины и прочие параметры. Соответственно комбинации релевантных слов заставят базу данных работать в намного более сложных условиях.Потому что систему писали люди, которые не удосужились разобраться в предметной области. И сделали подбор по той же технологии, как и на сайтах торгующих айфонами.
что зачастую системные администраторы используют для защиты блокировку по IP. Причем блокировкой по IP страдают не только сисадмины, которые действуют по скриптам, но и, к сожалению, некоторые системы защиты, которые покупаются за большие деньги.
Блокировка по айпи, это же какой то каменный век. Мало того, я видел атаки, которые как раз и имели перед собой цель, заставить заблокировать большие диапазоны адресов.
Вопрос: механизм обнаружения хонипотов у вас реализован? Не было случаев, когда вместо блокировок, тестируемая система, накопив аналитику, редиректерила ваших ботов на уровне l7 на внешние ссылки размером под многие сотни мегабайт? :)
Собственно мы и сами с другой стороны баррикад.
По поводу хонипотов — нет, не сталкивались. Но это не будет проблемой, так как мы специально ограничиваем атаку, и перенаправить её редиректами на внешние ресурсы нельзя. А со своих начать отдавать сотни мегабайт — не самая хорошая идея, так как наши каналы заведомо толще. Или, в случае с реальной атакой, каналы ботнета.
По поводу хонипотов — нет, не сталкивались. Но это не будет проблемой, так как мы специально ограничиваем атаку, и перенаправить её редиректами на внешние ресурсы нельзя. А со своих начать отдавать сотни мегабайт — не самая хорошая идея, так как наши каналы заведомо толще. Или, в случае с реальной атакой, каналы ботнета.
Редирект только 1 раз делал, какой то «студент» пришел парсить, не получилось, разозлился и стал долбить нас уж очень настойчиво через прокси сеть.
В обычном случае, обнаружив бота, мы начинаем ему вместо динамики, статику правдоподобную отдавать, и не пускаем на уровень бекенда, отдаем на фронтсервере. Не самое лучшее решение, но в комплексе (бюджет, людские ресурсы, типовые атаки) — работает.
В обычном случае, обнаружив бота, мы начинаем ему вместо динамики, статику правдоподобную отдавать, и не пускаем на уровень бекенда, отдаем на фронтсервере. Не самое лучшее решение, но в комплексе (бюджет, людские ресурсы, типовые атаки) — работает.
был я на данном докладе на H++)
почему проводите данное разделение? стерсс-тестировани просто один из подвидов нагрузочных тестов, на равне с тем же тестированием на стабильность, объем и тд.
видимо имеется ввиду тестирование производительности или стабильности?
не совсем понятен смысл сказанного.
если сервис падает от 1rps, то его надо брать и выбрасывать на свалку.
Отличия нагрузочного и стресс-тестирования
почему проводите данное разделение? стерсс-тестировани просто один из подвидов нагрузочных тестов, на равне с тем же тестированием на стабильность, объем и тд.
У нас есть реальный пример, когда субподрядчик партнера провел только нагрузочное тестирование.
видимо имеется ввиду тестирование производительности или стабильности?
Чем меньшей нагрузкой мы сможем довести ресурс до отказа, тем лучше. Если получится сделать так, что сайт прекратит функционировать от одного запроса в секунду
не совсем понятен смысл сказанного.
если сервис падает от 1rps, то его надо брать и выбрасывать на свалку.
Мы проводим такое разделение потому, что в основном сейчас нагрузочное тестирование воспринимается исключительно как тестирование на максимальное количество условных пользователей. Т.е. производится эмуляция поведения пользователей на сайте.
Имеется ввиду как раз тестирование с помощью одного из распространенных бесплатных веб-инструментов.
А если 10? а 20? Очевидно, что если стрелять в корень — то отказ будет на одном потоке, если спамить комментариями — совсем на другом. Речь идет о поиске запроса (или их комплекса), который максимально нагружает ресурс.
видимо имеется ввиду тестирование производительности или стабильности?
Имеется ввиду как раз тестирование с помощью одного из распространенных бесплатных веб-инструментов.
не совсем понятен смысл сказанного.
если сервис падает от 1rps, то его надо брать и выбрасывать на свалку.
А если 10? а 20? Очевидно, что если стрелять в корень — то отказ будет на одном потоке, если спамить комментариями — совсем на другом. Речь идет о поиске запроса (или их комплекса), который максимально нагружает ресурс.
Мы проводим такое разделение потому, что в основном сейчас нагрузочное тестирование воспринимается исключительно как тестирование на максимальное количество условных пользователей. Т.е. производится эмуляция поведения пользователей на сайте.
мысль понятна, увы но такое действительно встречается часто, у людей нет понимания, что НТ это не взять условный гатлинг и потыкать, а сервис, который предусматривает определенный минимальный набор кейсов, таких как поиск максимума, тест надежности, интеграционные тесты и конечно стресс.
Имеется ввиду как раз тестирование с помощью одного из распространенных бесплатных веб-инструментов.вопрос не в инструменте, а в кейсе тестирования выполненого субподрядчиком. PS. вопрос выверенности линейки инструмента тестирования, лучше не поднимать, это надолго)))
А если 10? а 20? Очевидно, что если стрелять в корень — то отказ будет на одном потоке, если спамить комментариями — совсем на другом.
все конечно от нефункциональных требований зависит, мне просто сложно представить требования на 1rps)))
Речь идет о поиске запроса (или их комплекса), который максимально нагружает ресурс.
без анализа НТ бесполезно.
Привет. Может стоило бы подробней рассказать о создании zip-бомб; на Хабре есть статья, правда переводная, на эту тему. А также подробней рассказать про свой мощный тестовый сервер.
Спасибо за статью :))
Спасибо за статью :))
Sign up to leave a comment.
DDoS в помощь: как мы проводим стресс- и нагрузочные тесты