Как защитить сайты и приложения от DDoS-атак

Даже самый лучший в мире специализированный сервис защиты не может обезопасить онлайн-ресурс от DDoS-атак на 100%. И дело тут не в изъянах ИБ-продуктов, а в том, что разные сайты и веб-приложения обладают разным уровнем устойчивости к DDoS-атакам.  В 2017 году наша компания предложила использовать понятие «защищаемость». Коротко отметим, что под защищаемостью мы имеем в виду свойство интернет-ресурсов быть надёжно защищенными от DDoS-атак с минимальными затратами средств, времени и усилий.В этой статье мы обсудим, как добиться максимальной защищаемости сайтов и серверных компонентов браузерных, мобильных приложений, а также сервисов, взаимодействующих посредством API-интерфейсов с использованием протоколов на базе HTTP/HTTPS.

Специфика защиты сайта от атак

Современные сайты — это многокомпонентные онлайн-приложения. Они взаимодействуют с множеством клиентов разной природы: браузерами, мобильными приложениями и другим сервисами, которые могут подключаться посредством HTTP-запросов и через API-интерфейсы. Многие сайты — это сложные, критически важные для бизнеса ресурсы, в разработке которых всё чаще используются современные технологии, такие как AJAX, API, BFF и пр.

Неприятным побочным эффектом их архитектурной и технологической сложности очень часто становится достаточно высокая уязвимость к киберрискам, в том числе связанным с DDoS-атаками. По этой же причине защищать сайты во многих случаях приходится от атак, реализуемых на разных уровнях модели OSI: сетевом (L3), транспортном (L4) и уровне приложений (L7).

Кроме того, в последние годы атаки стали намного сложнее. Теперь злоумышленники фокусируют внимание не только на уровне приложений. Всё чаще они стремятся найти и использовать уязвимости не в самих протоколах HTTP/HTTPS, а в конкретных способах взаимодействия серверных компонентов веб-приложений с клиентскими программными модулями и другими системами (например, с СУБД или шинами данных).

Чтобы надёжно и эффективно защищать веб-приложения от DDoS-атак, нужны особые компетенции, поэтому мы рекомендуем очень тщательно выбирать провайдера сервисов anti-DDoS.

Задуматься о безопасности на этапе проектирования

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

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

Иногда разработчики приложений закладывают в них обращения к другим интернет-ресурсам напрямую по их IP-адресам, без использования DNS. В итоге эти адреса жёстко «зашиваются» в программный код. Заменить их бывает крайне проблематично, да и обезопасить приложение во время DDoS-атаки становится почти нереально. Для провайдера, который предоставил эти адреса, их защита — это дополнительные хлопоты и расходы, на которые он вряд ли пойдёт.

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

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

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

Провести аудит приложения и его безопасности

Прежде чем покупать и подключать сервис anti-DDoS, следует понять:

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

Исчерпывающее видение вашего приложения поможет четко описать ваши требования к безопасности и обеспечить ее всесторонний охват. Последний момент особенно важен, поскольку «лоскутность» или «кусочность» защиты от DDoS-атак позволит злоумышленнику достаточно легко найти незащищённые компоненты и нацелить на них вредоносный трафик. Чтобы избежать явных «дыр» в безопасности приложения, необходимо позаботиться о защите от DDoS-атак на всех уровнях OSI, на которых могут идти атаки: сетевом (L3), транспортный (L4) и прикладном (L7).

Для полноценной защиты от атак на интернет-приложения следует использовать специализированные сервисы anti-DDoS. Ещё лучше подключить решения с расширенным функционалом. В их числе файрволы для защиты веб-приложений (Web Application Firewall, WAF), которые помогают обезопасить приложения от атак сразу на нескольких уровнях OSI. (Изучите плюсы такого решения на примере нашего сервиса «Защита веб-приложений с использованием облачного WAF».)

Поскольку классический WAF сам по себе не предназначен для защиты от DDoS-атак высокой интенсивности, рекомендуем использовать его в «тандеме» с anti-DDoS.

Чтобы планомерно выстраивать защиту приложений от DDoS-атак, также советуем подготовить «дорожную карту» её подключения и развёртывания на начальных этапах. Также лучше сразу разработать стратегию на среднесрочную перспективу, учитывающую планы развития ваших онлайн-приложений, тенденции в области DDoS-атак и динамику актуальных для вас рисков. Поскольку защита от этого типа угроз является одним из направлений ИБ, очень важно, чтобы она работала в соответствии со стратегией развития ИБ в компании.

Оценить, нужна ли защита без раскрытия приватных ключей SSL

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

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

В ряде случаев применяется гибридный подход с использованием пары сертификат-ключ, которые создаются специально для защиты от DDoS-атак (например, StormWall это может делать автоматически при помощи сервиса Let’s Encrypt).

Предоставить провайдеру anti-DDoS возможности для фильтрации атак

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

Как мы уже отметили выше, было бы замечательно заложить эти возможности ещё на стадии проектирования приложения. Желательно продумать и обсудить с разработчиками,  как именно планируете распознавать легитимные клиентские запросы и отбраковывать нелегитимные. Очень важно все эти правила  задокументировать. Так их будет легче передать затем провайдеру anti-DDoS.

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

Как обычно строится DDoS-защита приложений, использующих нестандартизованные способы взаимодействия (в первую очередь это касается мобильных приложений и программных клиентов, обращающихся через API)? На первом шаге механизм машинного обучения сервиса anti-DDoS выявляет схему работы приложения. Он выясняет такие важные детали, как география источников легитимных запросов, сигнатуры заголовков и методов взаимодействия, динамика и интенсивность запросов, и пр. На втором шаге, исходя из этой модели, строится модель нормальных активностей. Именно с ней в дальнейшем будут сопоставляться все запросы, встречающиеся в потоке трафика. Если они соответствуют нормальной модели поведения, то передаются приложению на исполнение, если нет — блокируются.

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

Если вы, как владелец или оператор приложения, не позаботились заранее о возможности чёткого выявления легитимных пользователей, то признаком начала атаки провайдер anti-DDoS сможет считать разве что подозрительно высокую активность отдельных групп клиентов или наличие их IP-адресов в базах нежелательных адресов. В любом случае провайдеру anti-DDoS будет сложнее выявлять зловредные активности. В частности, хитроумные боты могут сделать приложение недоступным, не отправляя на него шквал запросов, а, например, вынуждая генерировать «тяжеловесные» ответы, подготовка и отправка которых приведет к исчерпанию производительности или пропускной способности.

Подготовить информацию для провайдера anti-DDoS

В первую очередь для провайдера защиты нужно собрать перечень локаций, из которых к вашему приложению могут обращаться клиенты, которые не являются браузерами. В их числе мобильные приложения, сервисы, подключенные с помощью  API, AJAX и т.д.  Список поможет провайдеру точнее настроить процедуру проверки клиентов приложения и избежать ошибочных блокировок их запросов.

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

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

И ещё один важный момент: если провайдер сам расспрашивает вас о подобных деталях, то это говорит о том, что он, скорее всего обладает достаточными компетенциями. Зачастую, к сожалению, многие участники этого рынка ограничиваются лишь подключением своих сервисов, считая свою «миссию» на этом завершённой.

Скрыть от злоумышленника информацию о вашем приложении

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

Если киберпреступник узнает IP-адрес вашего приложения или его компонента, то сможет его атаковать. При этом только замена IP-адреса, которая производится при подключении сервисов anti-DDoS, проблему не решает. Дело в том, что  IP-адреса интернет-ресурсов несложно «вычислить» — в Сети есть множество инструментов для этого. 

Некоторые из них позволяют отследить всю историю изменений IP-адреса того или иного домена, зафиксированного в DNS (один из наиболее популярных инструментов для этого – MyIP). Другие (например, Shodan) выдают список всех IP-адресов, связанных с конкретным доменом.

Кроме того, IP-адреса можно найти в заголовках почтовых пакетов SMTP, которыми ваше приложение наверняка обменивается. Типичный случай: имя хоста у сервера, на котором развёрнуто приложение, совпадает с именем сайта. В этом кейсе в своём баннере его покажет SSH. Определить его IP-адрес для злоумышленника — дело на пять минут. . Напомним, что в идеале IP-адрес реального сервера не должен быть виден извне ни через почтовые заголовки, ни через открытые порты, ни через иные сервисы.

Закрыть неиспользуемые сервисы и порты

При ИБ-аудите приложения рекомендуем также определить, какие сервисы и порты используются в его работе, а какие нет. Последние нужно закрыть. В противном случае вас попытаются атаковать именно через незакрытые порты. Такая атака зачастую становится неожиданной как для жертвы, так и для её провайдера защиты.

Кроме того (и это очень важно!), после подключения защиты необходимо разрешить доступ к сайту только через IP-адрес, предоставленный провайдером anti-DDoS. В то же время доступ ко всем другим IP-адресам нужно закрыть, настроив нужным образом межсетевой экран. Это позволит предотвратить DDoS-атаки в обход сервисов защиты.

Оптимизировать серверные компоненты

Задача на этом этапе — обеспечить устойчивость ваших интернет-приложений к слабым DDoS-атакам. Дело в том, что не всегда сервисы защиты могут by-design обеспечить стопроцентную очистку трафика от нелегитимных пакетов. В этом случае какая-то их часть, пусть и небольшая, может просочиться сквозь фильтр. Но если атака крупная (например, если её мощность достигает сотен гигабит в секунду), то даже один процент её вредоносного трафика может сделать ваше приложение недоступным. Чтобы этого не произошло, серверные компоненты приложения и инфраструктура, на которой оно развёрнуто, должны обладать достаточно высокой производительностью. Цель оптимизации — её увеличить.

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

В частности, нужно обратить внимание на параметры, определяющие производительность сервера при работе популярных веб-серверов и «движков» CMS, а также сетевого стека. Кроме того, стоит позаботиться об оптимизации производительности СУБД, если ваше онлайн-приложение их использует.

Если вы развернули продукт на хостинге или в публичном облаке, то следует обсудить возможность оптимизации и увеличения производительности со службой технической поддержки вашего провайдера.. Возможно, потребуется перейти на более мощное серверное оборудование или на виртуальные машины с большим объёмом ресурсов. Эта мера не только повысит устойчивость вашего приложения к слабым DDoS-атакам, но и позволит лучше справляться с пиковыми нагрузками.

Подключить защищённые DNS-сервисы

При выстраивании защиты от DDoS-рисков надо, конечно, предусмотреть и возможность атак на DNS. Если последние окажутся успешными, пользователи не смогут получить доступ к вашему приложению либо он будет нестабильным. Необходимо оценить, защищены ли от DDoS-атак сервисы DNS, к которым подключено ваше приложение, насколько они производительны и надежны. (Подробнее читайте в нашей статье об атаках на DNS и мерах защиты.) 

Мы рекомендуем подключаться, как минимум, к двум поставщикам DNS-сервисов. Причём лучше, если хотя бы один из этих сервисов будет защищён от DDoS-атак на разных уровнях OSI (L3, L4 и L7). Такие DNS-сервисы можно найти как у провайдеров anti-DDoS, так и в компаниях, которые специализируются на этих решениях и услугах. Один из DNS-сервисов можно подключить как первичный (primary), другой — как вторичный (secondary).

На всякий случай напомним, что StormWall располагает широким арсеналом методов фильтрации трафика DNS на уровне приложений.

Регулярно проверять защиту

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

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

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

Кроме того, полезно проводить проверки не только в обычные рабочие дни, но и в выходные, праздничные и предпраздничные периоды. В такие моменты есть высокая вероятность того, что техническая поддержка провайдера anti-DDoS работает в расслабленном режиме и не ожидает массированных атак. Заодно можно проверить реакцию техподдержки на ваши сообщения об атаках. Например, если защищаемый ресурс внезапно становится недоступным, то техподдержка StormWall самостоятельно связывается с его владельцем независимо от того, идёт ли на него DDoS-атака в данный момент или нет.

Выстроить процессы по защите от DDoS-атак

Очень важно добиться того, чтобы защита от DDoS-атак не ограничилась разовыми мероприятиями и была тесно интегрирована с другими процессами ИБ.

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

Кроме того, рекомендуем связать действия по защите от DDoS-атак с другими процессами ИБ, включая мониторинг и аудит инфраструктуры, а также управление уязвимостями, конфигурациями, инцидентами и др.

Как защитить сайт от DDoS – итоговый чек-лист

• Заложить основу защищаемости ещё на стадии проектирования сайта / онлайн-приложения.
• Провести аудит онлайн-ресурса и его безопасности, оценить потребности в DDoS-защите, составить план её развития.
• Оценить, нужна ли защита без раскрытия приватных ключей SSL. Определить ресурсы, которые будут защищаться с раскрытием и без него.
• Предоставить провайдеру anti-DDoS возможности для фильтрации атак.
• Подготовить информацию для провайдера защиты.
• Скрыть от злоумышленника информацию о вашем приложении.
• Закрыть неиспользуемые сервисы и порты.
• Оптимизировать серверные компоненты.
• Подключить защищенные DNS-сервисы.
• Проводить регулярные проверки защиты.
• Выстроить процессы по обеспечению защиты от DDoS-атак.

Отслеживайте всё важное и интересное в нашем Telegram-канале: подписаться