Stress testing что это

Что такое стресс-тестирование. Объясняем простыми словами

Проще говоря, это прогноз того, что будет с экономикой, отдельными банками и компаниями при определённых (очень плохих) сценариях. Какие банки выживут, если государство объявит дефолт; хватит ли страховщикам средств на выплату возмещений, если Токио столкнётся с 8-балльным землетрясением; к каким последствиям приведут крупные сбои из-за хакерских атак; чем обернутся для финансовой системы локальные войны, погодные катаклизмы, эпидемии, санкции и так далее.

Пример употребления на «Секрете»

«Крупные системные предприятия, которые находятся в очень непростой ситуации, — это примерно 10 трлн рублей портфеля банковского сектора. Мы сделали стресс-тесты, примерно треть из них не прошли этот стресс-тест. Это те предприятия, которые не смогут самостоятельно выполнять обязательства перед банками».

(Глава Сбербанка Герман Греф — о проблемах предприятий в начале пандемии COVID-19.)

Нюансы

В основном стресс-тестирование нацелено на банки (отдельные или весь сектор), также его используют для оценки паевых фондов, страховых компаний и прочих финансовых институтов. Главный критерий, который интересует специалистов, — это платёжеспособность: достаточно ли у банков капитала, чтобы покрыть убытки, выплатить вклады и погасить долги.

Стресс-тесты могут выполнять сами банки — для этого они используют внутренние данные, а негативный сценарий определяет регулятор. Либо тест проводят центробанки на основе доступных данных по банковскому сектору.

Банк России выделяет четыре элемента стресс-теста.

Интерес к стресс-тестированию резко возрос в разгар финансового кризиса 2008 года, после череды банкротств крупных финансовых учреждений, включая американский инвестбанк Lehman Brothers (был четвёртым в США после Goldman Sachs, Morgan Stanley и Merrill). Власти охваченных кризисом стран стали использовать стресс-тесты, чтобы оценить состояние банков и решить, что делать с уязвимыми финансовыми институтами.

Источник

Нагрузочное тестирование

Что такое стресс-тестирование?

STRESS TESTING — это тип тестирования программного обеспечения, который проверяет стабильность и надежность системы. Этот тест в основном измеряет систему на ее устойчивость и способность обрабатывать ошибки в условиях чрезвычайно высокой нагрузки.

Стресс-тестирование проводится, чтобы убедиться, что система не будет аварийно завершать работу в критических ситуациях. Он даже тестирует за пределами нормальной рабочей точки и оценивает, как система работает в таких экстремальных условиях.

Тестируемое приложение будет загружено, когда данные 5 ГБ будут скопированы с веб-сайта и вставлены в блокнот. Блокнот находится в состоянии стресса и выдает сообщение об ошибке «Не ответили».

В этом уроке вы узнаете

Потребность в стресс-тестировании

Рассмотрим следующие сценарии —

Обязательно проводить стресс-тестирование, чтобы приспособиться к таким аномальным скачкам трафика. Неспособность приспособить этот внезапный трафик может привести к потере дохода и репутации.

Стресс-тестирование также чрезвычайно полезно по следующим причинам:

Цели стресс-тестирования

Целью стресс-тестирования является анализ поведения системы после сбоя. Чтобы стресс-тестирование было успешным, система должна отображать соответствующее сообщение об ошибке, пока оно находится в экстремальных условиях.

Для проведения стресс-тестирования иногда могут использоваться массивные наборы данных, которые могут быть потеряны во время стресс-тестирования. Тестеры не должны терять эти данные, связанные с безопасностью, во время стресс-тестирования.

Нагрузочное тестирование и стресс-тестирование

Типы стресс-тестирования:

Ниже приведены виды стресс-тестирования, которые объясняются следующим образом:

Распределенное стресс-тестирование:

В распределенных клиент-серверных системах тестирование выполняется на всех клиентах с сервера. Роль стресс-сервера заключается в распространении набора стресс-тестов среди всех стресс-клиентов и отслеживании статуса клиента. После того, как клиент связывается с сервером, сервер добавляет имя клиента и начинает отправку данных для тестирования.

Между тем клиентские машины посылают сигнал или пульс, что он связан с сервером. Если сервер не получает никаких сигналов от клиентского компьютера, его необходимо дополнительно изучить для отладки. Из рисунка сервер может соединиться с 2 клиентами (Client1 и Client2), но он не может отправлять или получать сигнал от клиентов 3 и 4.

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

Стресс-тестирование приложения:

Это тестирование сосредоточено на поиске дефектов, связанных с блокировкой и блокировкой данных, проблемами сети и узкими местами производительности в приложении.

Транзакционное стресс-тестирование:

Проводится стресс-тестирование одной или нескольких транзакций между двумя или более приложениями. Он используется для тонкой настройки и оптимизации системы.

Системное стресс-тестирование:

Это комплексное стресс-тестирование, которое можно протестировать на нескольких системах, работающих на одном сервере. Он используется для поиска дефектов, когда данные одного приложения блокируют другое приложение.

Поисковое стресс-тестирование:

Это один из видов стресс-тестирования, который используется для тестирования системы с необычными параметрами или условиями, которые вряд ли произойдут в реальном сценарии. Он используется для поиска дефектов в неожиданных сценариях, таких как

Как сделать стресс-тестирование?

Процесс стресс-тестирования можно выполнить в 5 основных этапов:

Наконец, вы снова запускаете весь цикл, чтобы определить, что настройки дали желаемые результаты. Например, нет ничего необычного в том, что для достижения целей производительности требуется от 3 до 4 циклов стресс-тестирования.

Инструменты, рекомендуемые для стресс-тестирования:

LoadRunner

LoadRunner от HP — широко используемый инструмент нагрузочного тестирования. Результаты нагрузочных испытаний, сформированные Loadrunner, считаются эталонными.

Jmeter

Стресс-тестер

Этот инструмент обеспечивает подробный анализ производительности веб-приложения, предоставляет результаты в графическом формате и чрезвычайно прост в использовании. Никаких высокоуровневых сценариев не требуется и дает хороший возврат инвестиций.

Нео груз

Это популярный на рынке инструмент для тестирования веб- приложений и мобильных приложений. Этот инструмент может моделировать тысячи пользователей, чтобы оценить производительность приложения под нагрузкой и проанализировать время отклика. Он также поддерживает Cloud-Integrated — производительность, нагрузочное и стресс-тестирование. Он прост в использовании, экономичен и обеспечивает хорошую масштабируемость.

Метрики для стресс-тестирования

Метрики помогают оценить производительность Системы и, как правило, изучаются в конце Стресс-теста. Обычно используемые метрики —

Измерение масштабируемости и производительности

Ответ приложения

Отказы

Вывод

Целью стресс-тестирования является проверка системы в экстремальных условиях. Он контролирует системные ресурсы, такие как память, процессор, сеть и т. Д., И проверяет способность системы вернуться к нормальному состоянию. Он проверяет, отображает ли система соответствующие сообщения об ошибках в состоянии стресса.

Источник

Кратко о стресс-тестировании

Под стресс-тестированием (stress testing) в широком смысле понимается анализ, исследование изменений свойств, характеристик и параметров системы, модуля, объекта в нестандартной и так называемой шоковой или стрессовой ситуации. Инструментарий стресс-тестирования позволяет определить возможность устойчивости системы, непотери ею своих основных свойств и характеристик в условиях превышения пределов нормального функционирования. Элементы стресс-тестирования применяются в различных секторах человеческой деятельности: социологии, медицине, машиностроении, телекоммуникациях, электроэнергетике, транспорте и в финансовом секторе. В узком смысле стресс-тестирование подразумевает исследование возможностей отдельного финансового института или целого сектора противостоять влиянию «исключительного, но возможного» шокового сценария.
В финансовом секторе стресс-тестирование за последние 25 лет из индивидуального инструмента риск-менеджмента наиболее продвинутых
банковских институтов США и Западной Европы трансформировалось в обязательные требования ФРС и ЕЦБ к банковскому сектору. Распространение
стресс-тестирования было поддержано требованиями Базельского комитета, рекомендациями Международного валютного фонда, Всемирного банка,
а также надзорными требованиями ФРС и ЕЦБ. Этот инструмент управления рисками прошел сложный путь трансформации: от индивидуальных внутренних методов отдельных банков сперва через обязательные требования оценки рыночного риска в шоковых ситуациях (Basel, 1996, после банкротства старейшего английского банка Barings Bank), потом благодаря рекомендации Международного валютного фонда и Всемирного банка
в качестве оценки рисков финансовой системы (Financial Sector Assessment Program, FSAP, 1999 г., после кризиса 1997—1998 гг. в Юго-Восточной Азии и банкротства хеджевого фонда LTCM), а затем через обязательные требования оценки кредитного риска в шоковых ситуациях (Basel II, 2004 г.). Крупнейший финансовый кризис XXI в. — в 2007—2009 гг., запомнившийся банкротством американского банка Lehman Brothers, стал причиной внесения в стресс-тестирование банковского сектора надзорных требований к достаточности капитала (Программа надзорной оценки капитала
в США (SCAR), 2009 г., ФРС; аналогичная программа Комитета европейских банковских надзорных органов (CEBS) со
стресс-тестами банковской системы ЕС в 2009—2010 гг.).
История трансформации стресс-тестирования с начала 1990-х до настоящего времени представлена на рисунке:

В настоящее время стресс-тесты широко используются в банковском и страховом секторах финансовыми институтами и надзорными органами, которые их контролируют. Например, стресс-тесты лежат в основе структуры контроля в рамках рекомендаций Basel III и Solvency II для банков и страховых компаний ЕС, соответственно. Результаты стресс-тестов также используются в оценке финансового сектора Международного валютного фонда.
Стресс-тесты, применяемые в настоящее время центральными банками и надзорными органами, делятся на две группы:
• подход «снизу вверх» (bottom-up);
• подход «сверху вниз» (top-down).
В первом случае финансовым институтам задаются сценарные условия, они самостоятельно делают расчеты и предоставляют результаты в регулирующий орган. Во втором случае надзорный орган сам осуществляет расчеты по единой методологии.
Стресс-тесты, как правило характеризуются четырьмя основными элементами:
1. Выборка тестируемых рисков (стресс-тесту должны подвергаться ключевые риски финансового сектора; они могут быть сформулированы в общем
виде:
• кредитный риск;
• рыночный риск;
• риск ликвидности;
или конкретно:
• кредитные риски банков, связанные с определенным сектором экономики;
• риск концентрации, возникающий в связи с зависимостью кредитного портфеля банка от группы лиц;
• рыночные риски, обусловленные ужесточением денежно-кредитной политики крупнейшими мировыми эмиссионными центрами;
• и другие.
2. Макроэкономический сценарий, при котором происходит реализация рисков (сценарии предполагают экономический спад, рост безработицы, падение цен на недвижимость на горизонте стресс-теста 2—5 лет). Данный временной горизонт применяется, как правило, в банковском секторе — для страховых компаний и пенсионных фондов применяют иные временные горизонты с учетом актуарных особенностей этих секторов.
3. Модели, описывающие влияние рисков на тестируемые параметры (модели определяют корреляцию и иные взаимосвязи между макроэкономическими показателями и рыночными индикаторами — процентными ставками, доходностями облигаций, ценами акций и так далее, а также финансовыми параметрами, например рейтингами корпоративных заемщиков, которые влияют в свою очередь на объем необходимого увеличения резервов по ссудам).
4. Измерение результатов (в большинстве случаев оценивается финансовый результат на горизонте стресс-теста, итоговый показатель достаточности капитала сравнивается с нормативом и рассчитывается дефицит капитала; в ряде стресс-тестов также оценивается дефицит ликвидности).
Более подробное освещение особенностей механизмов стресс-тестирования с учетом анализа однофакторных и многофакторных моделей выходит за рамки данной публикации. Однако, подводя своеобразный итог этой статьи, отметим, что многие многофакторные модели стресс-тестирования используют исторические ряды, учитывающие экстремальные движения рынка и банкротства отдельно взятых финансовых институтов. В качестве примеров экстремальных событий на финансовом рынке в последние десятилетия, как правило, приводят следующие:

• крах фондового рынка 1987 г. (Индекс Dow Jones упал на 23%, индекс S&P 500 — на 20%, вследствие «эффекта заражения» упали индексы
Nikkei, FTSE 100, Hang Seng);
• падение рынка высокодоходных бумаг в 1990 г. (Nikkei упал на 48%, японский индекс недвижимости — на 56% и т. д.);
• кризис европейских валют в 1992 г. (система обменных курсов, установленная между 12 европейскими странами, прекратила свое существование, многие валюты были обесценены);
• мексиканский кризис («текиловый» кризис) 1994 г.;
• крах банка Barings в 1995 г.;
• кризис в Юго-Восточной Азии в 1997 г.;
• кризис в России 1998 г.;
• крах хеджевого фонда LTCM в 1998 г.;
• бразильский кризис в 1999 г.;
• глобальный финансовый кризис в 2007—2009 гг.;
• банкротство Lehman Brothers в 2008 г.;
• долговой европейский кризис в 2010—2012 гг. (Греция, 2010 г., Ирландия, 2011 г.).
За последние 30 лет мировые финансовые рынки существенно изменились, но еще более сильно изменились требования надзора и регулирования. Несмотря на наблюдаемые новации в части ужесточения надзора банковского сектора и иных сегментов финансового рынка, неизбежно
возникает вопрос: насколько тонка грань, отделяющая желание контролировать финансовые рынки в попытках снизить системные риски от удушения развития новаций в финансировании? В этом смысле, возможно, стоит вспомнить фразу,
которую в 1994 г. произнес Алан Гринспэн, будучи председателем Совета управляющих ФРС: «Кое-кто может согласиться с тем, что роль контроля над банками заключается в сведении к минимуму или даже к полному исключению случаев разорения банков, но я думаю, что эта точка зрения ошибочна. Готовность к риску необходима для развития экономики свободного рынка… Если бы все, кто имеет сбережения, и их посредники инвестировали только в безрисковые активы, потенциал экономического роста остался бы нереализованным».
В 1994 г. эта фраза была с благосклонностью услышана представителями мировых финансов. Сейчас после череды кризисов последних 20 лет отношение к этим словам Алана Гриспэна неоднозначное.

Источник

Что такое стресс-тестирование

Что такое стресс-тестирование

В общем смысле стресс-тестирование подразумевает исследование изменений свойств системы или объекта в нестандартных (стрессовых) условиях. В приложении к финансовой организации или институту стресс-тест — это испытание на прочность ее финансового положения в условиях «серьезного, но вместе с тем вероятного шока».

Стресс-тест, как правило, включает четыре элемента:

Стресс-тесту должны подвергаться ключевые риски финансового сектора; они могут быть сформулированы в общем виде: кредитный риск, рыночный риск, риск ликвидности, или конкретно: например, кредитные риски банков, связанные с компаниями-экспортерами, или рыночные риски, обусловленные ужесточением денежно-кредитной политики ведущими центральными банками.

Сценарии предполагают экономический спад, рост безработицы, падение цен на недвижимость на горизонте стресс-теста — как правило, 2 — 5 лет.

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

В большинстве случаев оценивается финансовый результат на горизонте стресс-теста, итоговый показатель достаточности капитала сравнивается с нормативом и рассчитывается дефицит капитала; в ряде стресс-тестов также оценивается дефицит ликвидности.

Стресс-тест, направленный на выявление стабильности функционирования отдельного финансового института в случае негативного экономического сценария, — это стресс-тест на микроуровне. Глобальный финансовый кризис 2007 — 2009 гг. продемонстрировал, что устойчивости отдельных финансовых институтов недостаточно для обеспечения устойчивости финансовой системы. Поэтому с тех пор широкое распространение получили стресс-тесты на макроуровне, предполагающие проверку устойчивости группы финансовых институтов, которая может оказать влияние на экономику в целом. Также активно применяется термин «макропруденциальный стресс-тест», который определен в докладе МВФ как стресс-тест, «учитывающий реакцию финансовых институтов на экономический шок и их взаимодействие друг с другом, направленный на исследование устойчивости финансовой системы в целом, а не конкретных институтов».

Стресс-тесты, осуществляемые в настоящее время центральными банками и надзорными ведомствами различных стран, фактически направлены на обе цели. При проведении централизованных стресс-тестов распространено разделение на bottom-up и top-down стресс-тесты.

Результаты стресс-тестов могут использоваться самими банками для усиления риск-менеджмента, надзорными органами при установлении требований к капиталу банка в рамках Базеля II, а также регулятором, ответственным за обеспечение финансовой стабильности, при реализации макропруденциальной или антикризисной политики.

Источник

DDoS в помощь: как мы проводим стресс- и нагрузочные тесты

Компания Variti разрабатывает защиту от ботов и DDoS-атак, а также проводит стресс- и нагрузочное тестирование. На конференции HighLoad++ 2018 мы рассказывали, как обезопасить ресурсы от различного вида атак. Если коротко: изолируйте части системы, используйте облачные сервисы и CDN и регулярно обновляйтесь. Но без специализированных компаний с защитой вы все равно не справитесь 🙂

Перед прочтением текста можете ознакомиться с короткими тезисами на сайте конференции.
А если вы не любите читать или просто хотите посмотреть видео, запись нашего доклада ниже под спойлером.

Многие компании уже умеют делать нагрузочные тестирования, но не все делают стресс-тестирования. Некоторые наши заказчики думают, что их сайт неуязвим, потому что у них есть highload система, и она хорошо защищает от атак. Мы же показываем, что это не совсем правда.

Разумеется, перед проведением тестов мы получаем разрешение от заказчика, с подписью и печатью, и с нашей помощью DDoS-атаку сделать ни на кого нельзя. Тестирование проводится в выбранное заказчиком время, когда посещаемость его ресурса минимальна, а проблемы с доступом не отразятся на клиентах. Кроме того, поскольку в процессе тестирования всегда может пойти что-то не так, у нас есть постоянный контакт с заказчиком. Это позволяет не только сообщать о достигнутых результатах, но и что-то менять в ходе тестирования. При завершении тестирования мы всегда составляем отчет, в котором указываем на обнаруженные недостатки и даем рекомендации по устранению слабых мест сайта.

Как мы работаем

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

Постулаты

Чем меньшей нагрузкой мы сможем довести ресурс до отказа, тем лучше. Если получится сделать так, что сайт прекратит функционировать от одного запроса в секунду, или даже от одного запроса в минуту, это прекрасно. Потому что по закону подлости пользователи или злоумышленники случайно попадут именно в эту уязвимость.

Мы всегда советуем делать системы гетерогенными. Причем разделять их стоит именно на физическом уровне, а не только контейниризацией. В случае физического разделения, даже если на сайте что-то откажет, то велика вероятность, что он не прекратит работу полностью, и у пользователей сохранится доступ хотя бы к части функционала.

Правильная архитектура — основа устойчивости

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

Хорошим должен быть не только код, но и конфиг

Многие думают, что хорошая команда разработки это гарантия отказоустойчивости сервиса. Хорошая команда разработки действительно необходима, но должна быть еще и хорошая эксплуатация, хороший DevOps. То есть нужны специалисты, которые правильно сконфигурируют Linux и сеть, правильно напишут конфиги в nginx, настроят лимиты и прочее. В противном случае ресурс будет хорошо работать только на тесте, а в продакшене в какой-то момент все сломается.

Отличия нагрузочного и стресс-тестирования

Нагрузочное тестирование позволяет выявить пределы функционирования системы. Стресс-тестирование направлено на поиск слабых мест системы и используется для того, чтобы эту систему сломать и посмотреть, как она будет вести себя в процессе отказа тех или иных частей. При этом при характер нагрузки обычно остается неизвестным для заказчика до начала стресс-тестирования.

Отличительные черты L7 атак

Виды нагрузки мы обычно делим на нагрузки на уровне L7 и L3&4. L7 — это нагрузка на уровне приложения, чаще всего под ней понимают только HTTP, мы же подразумеваем любую нагрузку на уровне протокола TCP.

У L7 атак есть определенные отличительные черты. Во-первых, они приходят непосредственно в приложение, то есть отразить их сетевыми средствами вряд ли получится. Такие атаки задействуют логику, и за счет этого очень эффективно и при небольшом трафике потребляют ЦПУ, память, диск, базу данных и прочие ресурсы.

HTTP Flood

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

В качестве первого примера рассмотрим атаку HTTP Flood. Из графика видно, что обычно такие атаки очень мощные, в примере ниже пиковое число запросов превосходило 600 тысяч в минуту.

HTTP Flood — это самый простой способ создать нагрузку. Обычно для него берется какой-то инструмент нагрузочного тестирования, например, ApacheBench, и задаются запрос и цель. При таком простом подходе велика вероятность нарваться на кеширование сервера, но его легко обойти. Например, добавив случайные строки в запрос, что вынудит сервер постоянно отдавать свежую страницу.
Также не стоит забывать про user-agent в процессе создания нагрузки. Многие user-agent популярных инструментов тестирования фильтруются системными администраторами, и в таком случае нагрузка может просто не дойти до бэкенда. Значительно улучшить результат можно, вставляя в запрос более или менее валидный заголовок из браузера.
При всей простоте атаки HTTP Flood имеют и свои недостатки. Во-первых, для создания нагрузки требуются большие мощности. Во-вторых, такие атаки очень легко обнаруживаются, особенно если идут с одного адреса. В итоге, запросы сразу же начинают фильтроваться либо системными администраторами, либо даже на уровне провайдера.

Что искать

Чтобы снизить количество запросов в секунду и при этом не потерять в эффективности, нужно проявить немного фантазии и исследовать сайт. Так, нагружать можно не только канал или сервер, но и отдельные части приложения, например, базы данных или файловые системы. Также можно поискать места на сайте, которые делают большие вычисления: калькуляторы, страницы с подбором продуктов и прочее. Наконец, часто бывает, что на сайте есть некий php-скрипт, который генерирует страницу из нескольких сотен тысяч строк. Такой скрипт тоже в значительной степени нагружает сервер и может стать мишенью для атаки.

Где искать

Когда мы сканируем ресурс перед проведением тестирования, то в первую очередь смотрим, конечно, на сам сайт. Мы ищем всевозможные поля ввода, тяжелые файлы — в общем все, что может создать проблемы ресурсу и замедляет его работу. Здесь помогают банальные средства разработки в Google Chrome и Firefox, показывающие время ответов страницы.

Также мы сканируем поддомены. Например, есть некий онлайн-магазин, abc.com, и у него есть поддомен admin.abc.com. Скорее всего, это админка с авторизацией, но если в нее пустить нагрузку, то она может создать проблемы для основного ресурса.

У сайта может быть поддомен api.abc.com. Скорее всего, это ресурс для мобильных приложений. Приложение можно найти в App Store или Google Play, поставить специальную точку доступа, препарировать API и зарегистрировать тестовые аккаунты. Проблема в том, что зачастую люди думают, что все, что защищено авторизацией, неуязвимо для атак на отказ в обслуживании. Якобы авторизация это лучшая CAPTCHA, но это не так. Сделать 10-20 тестовых аккаунтов просто, а создав их, мы получаем доступ к сложному и неприкрытому функционалу.

Естественно, мы смотрим на историю, на robots.txt и WebArchive, ViewDNS, ищем старые версии ресурса. Иногда бывает так, что разработчики выкатили, скажем, mail2.yandex.net, а старая версия, mail.yandex.net, осталась. Этот mail.yandex.net перестает поддерживаться, на него не отводятся ресурсы разработки, но он продолжает потреблять базу данных. Соответственно с помощью старой версии можно эффективно задействовать ресурсы бэкенда и всего того, что стоит за версткой. Конечно, так происходит не всегда, но с подобным мы сталкиваемся все равно довольно часто.

Естественно, мы препарируем все параметры запроса, структуру cookie. Можно, скажем, запулить в JSON массив внутри cookie какое-то значение, создать большую вложенность и заставить ресурс работать неразумно долго.

Нагрузка в поиск

Первое, что приходит в голову при исследовании сайта, это нагрузить базу данных, поскольку поиск есть почти у всех, и почти у всех он, к сожалению, защищен плохо. Почему-то разработчики не уделяют поиску достаточное внимание. Но тут есть одна рекомендация — не стоит делать однотипные запросы, потому что можно столкнуться с кешированием, как и в случае с HTTP flood.

Делать случайные запросы в базу данных тоже не всегда эффективно. Гораздо лучше создать список ключевых слов, которые относятся к поиску. Если возвращаться к примеру интернет-магазина: допустим, сайт торгует автомобильной резиной и позволяет задавать радиус шин, тип машины и прочие параметры. Соответственно комбинации релевантных слов заставят базу данных работать в намного более сложных условиях.

Кроме того, стоит использовать пагинацию: поиску гораздо сложнее отдать предпоследнюю страницу выдачи, чем первую. То есть с помощью пагинации можно немного разнообразить нагрузку.

На примере ниже показываем нагрузку в поиск. Видно, что с первой же секунды теста на скорости десять запросов в секунду сайт лег и не отвечал.

Если поиска нет?

Если поиска нет, то это не значит, что сайт не содержит в себе других уязвимых полей ввода. Таким полем может оказаться авторизация. Сейчас разработчики любят делать сложные хеши, чтобы защитить базу логинов от атаки по радужным таблицам. Это хорошо, но такие хеши потребляют большие ресурсы CPU. Большой поток ложных авторизаций приводит к отказу процессора, и как следствие, на выходе сайт перестает работать.

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

Rest API

Хотелось бы уделить немного внимания таким популярным нынче сервисам, как Rest API. Защитить Rest API гораздо сложнее, чем обычный сайт. Для Rest API не работают даже банальные способы защиты от перебора паролей и прочей нелигитимной активности.

Rest API очень просто сломать, потому что он обращается непосредственно к базе данных. При этом вывод такого сервиса из строя влечет за собой достаточно тяжелые последствия для бизнеса. Дело в том, что на Rest API обычно завязан не только главный сайт, но и мобильное приложение, какие-то внутренние бизнес-ресурсы. И если это все падает, то эффект гораздо сильнее, чем в случае с выходом из строя простого сайта.

Нагрузка на тяжелый контент

Если нам предлагают тестировать какое-то обычное одностраничное приложение, лендинг, сайт-визитку, у которых нет сложного функционала, мы ищем тяжелый контент. Например, большие картинки, которые отдает сервер, бинарные файлы, pdf-документацию, — мы пробуем все это выкачивать. Такие тесты хорошо грузят файловую систему и забивают каналы, и поэтому эффективны. То есть даже если вы не положите сервер, скачивая большой файл на небольших скоростях, то вы просто забьете канал целевого сервера и тогда наступит отказ в обслуживании.
На примере такого теста видно, что на скорости 30 RPS сайт перестал отвечать, либо выдавал 500-е ошибки сервера.

Не стоит забывать и про настройку серверов. Часто можно встретить, что человек купил виртуалку, поставил туда Apache, настроил все по умолчанию, расположил php-приложение, и ниже можно увидеть результат.

Здесь нагрузка шла в корень и составляла всего 10 RPS. Мы подождали 5 минут, и сервер упал. До конца, правда, неизвестно, почему он упал, но есть предположение, что он просто объелся памяти, и поэтому перестал отвечать.

Wave based

В последние год-два достаточно популярными стали волновые атаки. Это связано с тем, что многие организации покупают те или иные железки для защиты от DDoS, которые требуют определенного времени накопления статистики для начала фильтрации атаки. То есть они не фильтруют атаку в первые 30-40 секунд, потому что накапливают данные и обучаются. Соответственно в эти 30-40 секунд на сайт можно запустить столько, что ресурс будет лежать длительное время, пока не разгребутся все запросы.

В случае с атакой ниже был интервал 10 минут, после чего прилетела новая, видоизмененная порция атаки.

То есть защита обучилась, запустила фильтрацию, но прилетела новая, совершенно другая порция атаки, и защита снова начала обучение. Фактически, фильтрация перестает работать, защита становится неэффективной, и сайт недоступен.

Для волновых атак характерны очень высокие значения на пике, она может достигать ста тысяч или миллиона запросов в секунду, в случае с L7. Если говорить про L3&4, то там могут быть сотни гигабит трафика, или, соответственно, сотни mpps, если считать в пакетах.

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

Не HTTP единым

Помимо HTTP на уровне L7, мы любим эксплуатировать и другие протоколы. Как правило, у обычного веб-сайта, тем более у обычного хостинга, наружу торчат почтовые протоколы и MySQL. Почтовые протоколы подвержены нагрузкам в меньшей степени, чем базы данных, но их тоже можно нагружать достаточно эффективно и на выходе получать перегруженный CPU на сервере.

Мы вполне реально с помощью уязвимости SSH 2016 года добивались успеха. Сейчас эта уязвимость почти у всех поправлена, но это не значит, что в SSH нельзя подавать нагрузку. Можно. Просто подается огромная нагрузка авторизаций, SSH съедает почти весь CPU на сервере и дальше веб-сайт складывается уже от одного-двух запросов в секунду.

Соответственно эти один-два запроса по логам никак нельзя отличить от легитимной нагрузки.
Остаются актуальными и множество соединений, которые мы открываем в серверах. Раньше этим грешил Apache, сейчас этим фактически грешит и nginx, поскольку он часто настраивается по дефолту. Количество соединений, которые nginx может держать открытыми, лимитировано, соответственно мы открываем это количество соединений, новое соединение nginx уже не принимает, и на выходе сайт не работает.

Наш тестовый кластер обладает достаточным CPU, чтобы атаковать SSL handshake. В принципе, как показывает практика, ботнеты тоже иногда любят это делать. С одной стороны, понятно, что без SSL не обойтись, потому что выдача Google, ранжирование, безопасность. С другой стороны, у SSL, к сожалению, есть проблема с CPU.

Когда мы говорим об атаке на уровнях L3&4, мы говорим, как правило, об атаке на уровне канала. Такая нагрузка почти всегда отличима от легитимной, если это не атака SYN-flood. Проблема SYN-flood атак для средств защиты заключается в большом объеме. Максимальная величина L3&4 составляла 1,5-2 Тбит/с. Такой трафик очень сложно обработать даже крупным компаниям, включая Oracle и Google.

SYN и SYN-ACK — это пакеты, которые используются при установке соединения. Поэтому SYN-flood и сложно отличить от легитимной нагрузки: непонятно, это SYN, который пришел на установку соединения, или часть флуда.

UDP-flood

Обычно у злоумышленников нет тех мощностей, которые есть у нас, поэтому для организации атак может использоваться амплификация. То есть злоумышленник сканирует интернет и находит либо уязвимые, либо неправильно настроенные серверы, которые, например, в ответ на один SYN-пакет, отвечают тремя SYN-ACK. Подделывая адрес источника с адреса целевого сервера, можно с помощью одного пакета увеличить мощность, скажем, в три раза, и перенаправить трафик на жертву.

Проблема амплификаций заключается в их сложном обнаружении. Из последних примеров можно привести нашумевший случай с уязвимым memcached. Плюс, сейчас появилось множество устройств IoT, IP-камер, которые тоже в основном настроены по дефолту, и по дефолту они настроены неправильно, поэтому через такие устройства злоумышленники и делают атаки чаще всего.

Непростой SYN-flood

SYN-flood, наверное, самый интересный вид из всех атак с точки зрения разработчика. Проблема в том, что зачастую системные администраторы используют для защиты блокировку по IP. Причем блокировкой по IP страдают не только сисадмины, которые действуют по скриптам, но и, к сожалению, некоторые системы защиты, которые покупаются за большие деньги.

Такой метод может обернуться катастрофой, ведь если злоумышленники подменят IP-адреса, то компания заблокирует собственную подсеть. Когда Firewall заблокирует собственный кластер, на выходе будут рушиться внешние взаимодействия, и ресурс сломается.

Причем добиться блокировки собственной сети несложно. Если в офисе клиента есть WI-Fi-сеть, или если работоспособность ресурсов измеряется с помощью различных мониторингов, то мы берем IP-адрес этой системы мониторинга или офисного Wi-Fi клиента, и используем его в качестве источника. На выходе ресурс вроде бы доступен, но целевые IP-адреса заблокированы. Так, может быть заблокирована Wi-Fi-сеть конференции HighLoad, где презентуется новый продукт компании, — и это влечет определенные бизнес- и экономические издержки.

Во время тестирования мы не можем использовать амплификацию через memcached какими-то внешними ресурсами, потому что есть договоренности по подаче трафика только в разрешенные IP-адреса. Соответственно мы используем амплификацию через SYN и SYN-ACK, когда на отправку одного SYN система отвечает двумя-тремя SYN-ACK, и на выходе атака умножается в два-три раза.

Инструменты

Один из основных инструментов, которым мы пользуемся для нагрузки на уровне L7, — это Yandex-tank. В частности, в качестве пушки используется фантом, плюс есть несколько скриптов для генерации патронов и для анализа результатов.

Для анализа сетевого трафика используется Tcpdump, для анализа сервера — Nmap. Для создания нагрузки на уровне L3&4 используется OpenSSL и немного собственной магии с библиотекой DPDK. DPDK — это библиотека от Intel, которая позволяет работать с сетевым интерфейсом, минуя стек Linux, и тем самым повышает эффективность. Естественно, DPDK мы используем не только на уровне L3&4, но и на на уровне L7, потому что она позволяет создавать очень высокий поток нагрузки, в пределах нескольких миллионов запросов в секунду с одной машины.
Также мы используем определенные трафик-генераторы и специальные инструменты, которые пишем под специфические тесты. Если вспомнить уязвимость под SSH, то приведенным выше набором она не может быть проэскпулатирована. Если мы атакуем почтовый протокол, то берем почтовые утилиты или просто пишем на них скрипты.

Выводы

В качестве итогов хотелось бы сказать:

Источник