Как повысить устойчивость сайтов и интернет-приложений к DDoS-атакам

13 октября 2022

Не стоит ожидать, что, подключив пусть даже лучший в мире сервис защиты от DDoS-атак, вы на 100% обезопасите от них свои сайты и интернет-приложения. И дело тут не в изъянах сервисов, а в том, что разные интернет-ресурсы обладают разным уровнем устойчивости к DDoS-атакам, причем чтобы довести ее до примерно одного уровня, могут потребоваться разные усилия, средства и сроки.

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

В этой статье мы обсудим, как добиться защищаемости сайтов и серверных компонентов браузерных, мобильных приложений и сервисов, взаимодействующих посредством API-интерфейсов с использованием протоколов на базе HTTP/HTTPS.

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

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

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

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

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

Что нужно сделать еще на стадии проектирования интернет-приложения

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

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

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

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

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

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

Провести аудит приложения и его безопасности, оценить потребности в DDoS-защите и спланировать ее развитие

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

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

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

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

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

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

По умолчанию для защиты приложений обычно выбирают более удобный вариант – защиту с раскрытием приватных ключей SSL. Однако если требуется обмен финансовыми или конфиденциальными данными, то следует выстраивать защиту без раскрытия приватных ключей. Она ограничивает возможности по проведению проверок клиентов приложения (каким образом к нему обратились, откуда – из какого браузера или мобильного приложения, и пр.), но позволяет более надежно защищать конфиденциальные данные.

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

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

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

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

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

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

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

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

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

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

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

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

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

Если к приложению обращаются мобильные приложения или легитимные боты, то “защитнику” нужно знать о них как можно больше: какие у них User-агенты, каких типов и с какими заголовками от них идут запросы, из каких легитимных локаций они могут идти, какова частота запросов с одного IP-адреса при нормальной активности клиентов. Эти данные позволят ему обеспечить более качественную фильтрацию трафика.

И, кстати, обратите внимание: если провайдер сам расспрашивает вас о подобных деталях, то это говорит о том, что он, скорее всего достаточно профессионален. Для сравнения: есть немало провайдеров Anti-DDoS, которые лишь ограничиваются подключением своих сервисов, считая свою “миссию” на этом завершенной.

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

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

Узнав IP-адрес вашего приложения или его компонента, злоумышленник сможет его атаковать, и сама по себе замена IP-адреса, которая производится при подключении сервисов Anti-DDoS, не поможет защитить его от DDoS-рисков, поскольку IP-адреса интернет-ресурсов несложно «вычислить» – в Интернете есть множество инструментов для этого. Есть, например, те, что позволяют отследить всю историю изменений IP-адреса того или иного домена, зафиксированного в DNS (один из наиболее популярных инструментов для этого – MyIP). Другие (например, Shodan) предоставляют возможность получить список всех IP-адресов, связанных с конкретным доменом. И так далее. IP-адреса также можно найти в заголовках почтовых пакетов SMTP, которыми ваше приложение наверняка обменивается. Если имя хоста у сервера, на котором развернуто приложение, совпадает с именем сайта, то, например, SSH в своем баннере его покажет, и с помощью простых инструментов злоумышленник сможет определить его IP-адрес. В идеале IP-адрес реального сервера не должен быть виден извне ни через почтовые заголовки, ни через открытые порты, ни через иные сервисы.

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

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

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

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

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

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

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

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

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

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

Систематически проверять защиту

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

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

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

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

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

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

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

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

Итоговый чек-лист

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

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