26 Октября 2020 12:22 | 26 Окт 2020 12:22 | |

Поделиться

Как не потратить деньги на защиту от DDoS впустую

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

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

• ИБ — это процесс обеспечения деятельности бизнеса, и стоит X, а снижает риски на Y. Цель сделать X < Y;
• на имеющийся бюджет желательно получить именно то, что подходит конкретной инфраструктуре и соответствует конкретным рискам. Эффективные универсальные средства, как правило, дороги.

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

BC or not BC?

В первую очередь надо определиться, какие интернет-приложения являются Business Critical (критически важными для бизнеса), а какие нет. Есть ли вообще такие в вашей сети? C каким перерывом доступности вы готовы мириться для различных интернет-ресурсов?

Возможно, для каких-то элементов вашей инфраструктуры будет достаточно магистральной защиты канала и инфраструктурных сервисов. А какие-то требуют дополнительной более сложной защиты на уровне приложений, расшифровки трафика и разбора логики запросов-ответов. Здесь, в частности, может помочь Web Application Firewall (WAF), который отвечает за безопасность приложения: противодействует попыткам кражи и изменения его данных, а также фильтрует DDoS на уровне приложения.

Не стоит «класть все яйца в одну корзину» и держать на одном адресе и Business Critical приложения, и все остальные. Подобную ошибку допускают многие компании. Например, один из наших заказчиков — крупный интернет-магазин — до того, как стать клиентом «Ростелекома», пользовался услугами облачного провайдера Аnti-DDoS. Все его сервисы находились на едином выделенном ресурсе у хостинг-провайдера. При этом реальные адреса ресурса заказчика не фигурировали в DNS-ответах — клиенты получали адреса облачного провайдера Anti-DDoS, трафик до веб-сервера ритейлера был разрешен только с адреса своего Аnti-DDoS-провайдера, но при этом почтовый сервер оставался на том же адресе и не был вынесен на отдельную инфраструктуру.

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

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

• при целевой атаке на портал партнеров основной сайт не пострадает;
• компрометация реальных адресов портала партнеров не позволит «положить» основной сайт.

Так же важно не забыть поставить под защиту все критические поддомены.

Насколько важны SLA?

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

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

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

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

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

Кто ваши соседи?

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

Примерно так может произойти и в случае, если вы перенаправляете, трафик через облачного провайдера Anti-DDoS, меняя в A-записи DNS-адрес своего сайта на адрес провайдера. Дело в том, что у провайдера есть определенный набор адресов, которые он в случайном порядке раздает клиентам. Если на «соседнем» от вас адресе расположен нелегальный сайт, который нарушает законодательство, то его блокировка может повлиять на доступность и ваших ресурсов.

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

Какой будет полоса атаки?

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

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

На что способна защищаемая инфраструктура и сервисы?

Многие методы защиты от DDoS — статистические, то есть основанные на мониторинге и анализе трафика с целью выявления его аномалий. Однако такой подход не отсекает 100% «мусорных» запросов к ресурсу. В случае массированного DDoS, полоса атаки может на несколько порядков превышать легитимный трафик. Если запас по полосе отсутствует, то даже небольшой процент пропущенного провайдером Anti-DDoS вредоносного трафика может оказаться критичным. Поэтому, чтобы понять, какие гарантии сервиса Anti-DDoS потребуются, и реальны ли они вообще, для начала нужно определить пределы собственной инфраструктуры в экстремальных сетевых условиях.

Для понимания пределов инфраструктуры и сервисов имеет смысл:

• провести нагрузочное тестирование инфраструктуры, чтобы знать предельные значения трафика, которые может купировать канал или оборудование. Тесты помогут выявить узкие места, на которые стоит обратить внимание;
• выявить уязвимости в приложениях, которые могут привести к их недоступности и понять, при каких значениях (запросах в секунду) или объеме запросов, производительность ресурса начинает деградировать.

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

Что можно сделать в подобной ситуации? Во-первых, периодически или при запуске новых версий web-приложения сканировать его на уязвимости средствами SAST — статического анализа кода (например, Solar appScreener). Это помогает решать часть проблем уже на этапе разработки, так как большинство таких средств выдает конкретные прикладные рекомендации как исправить ошибки. Во-вторых, не забывать периодически сканировать защищаемое веб-приложение на уязвимости динамическими средствами DAST, то есть находить уязвимости тестовым трафиком методами «black box» в уже работающем приложении.

Но сами по себе DAST и SAST не блокируют уязвимости, а только их обнаруживают. Соответствующие правила блокировки реализуются на WAF, в который уже иногда интегрированы средства динамического анализа уязвимостей.

Сильна ли экспертиза поставщика услуг?

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

Прежде чем покупать сервис по Anti-DDoS, стоит обратить внимание на:

• опыт оказания услуги и портфолио исполнителя;
• подходы исполнителя к изучению инфраструктуры заказчика в рамках оказания услуг;
• широту линейки сервисов кибербезопасности и опыт в нахождении корреляций между событиями ИБ разных сервисов.

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

А есть ли у нас план действий при атаке?

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

В компании, которая уже перешла от стадии небольшого стартапа к более масштабному бизнесу, в этом списке будут следующие сотрудники (или роли):

• офицер безопасности;
• сетевой инженер;
• ответственный за взаимоотношения с ISP;
• ответственный за взаимоотношения с провайдером (-ами) Anti-DDoS;
• ответственный за CDN (если такой сервис есть);
• ответственный за DNS;
• владелец приложения.

И самое главное — необходим один человек, принимающий решение в случае DDoS-атаки (например, главный сотрудник по информационной безопасности [CISO], операционный менеджер). Он же — единый контакт для бизнес-подразделений (поверьте, у бизнеса появятся вопросы, если угроза будет реализована).

Как есть план действий при пожаре, в компании должна быть инструкция по реагированию на DDoS.

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

Поделиться

Короткая ссылка