Цунами DDoS-атак, накрывшее российские интернет-ресурсы весной и летом этого года, продемонстрировало всем актуальность этого вида киберугроз и развеяло последние сомнения относительно необходимости защиты от них. Вопрос — в том, как правильно выстраивать защиту от DDoS-атак и каких ошибок при этом следует избегать.
- Введение
- Основа основ — защищаемость
- Первый шаг имеет значение
- Особые требования — к обработке персональных и финансовых данных
- Не все сервисы защиты одинаково полезны
- Чего нельзя позволять атакующему
- Не оставляйте «грабли»!
- Самые сложные проблемы — те, что заложены изначально
- Ещё раз о защищаемости
- Золотые правила DDoS-защиты
- Выводы
Введение
В этой аналитической статье собраны основные наблюдения и выводы, сделанные на основе почти десятилетней практики компании StormWall по выстраиванию защиты её клиентов от DDoS-атак. Статья будет, безусловно, полезной тем, кто хочет обеспечить эффективность защиты как с точки зрения качества отражения DDoS-атак, так и в отношении затрат, которые при этом потребуются. Особо ценной эта статья будет для тех, кто только приступает к созданию интернет-систем и имеет возможность уже на стадии проектирования заложить в них высокую устойчивость к DDoS-рискам.
В июне Anti-Malware.ru собрал оценки зарегистрированного уровня DDoS-атак, зафиксированных в первом квартале 2022 года, в статье «Развенчиваем мифы: DDoS-атаки в первом квартале 2022 г. были аномально сильными». Стоит отметить их постоянно растущую мощность — полтора месяца назад Cloudflare зафиксировала атаку мощностью 26 млн запросов в секунду, — а также длительность: II квартал побил рекорд по длительности DDoS (по данным Kaspersky).
Основа основ — защищаемость
Чтобы интернет-ресурс (сеть, сервер, сайт или приложение, предоставляющее мобильные или веб-сервисы) сохранял доступность не только в «мирное» время, но и находясь под атакой, зачастую бывает недостаточно просто подключить к нему DDoS-защиту. И правильные настройки тоже не всегда помогают. Всё дело в том, что разные ресурсы имеют разную степень устойчивости к DDoS-атакам. Она зависит не только от технических характеристик ресурса, но и от того, как его владельцы или те, кто за него отвечает, взаимодействуют с поставщиками решений для защиты от DDoS-атак.
В 2017 году наша компания сформулировала концепцию защищаемости от DDoS-атак и определила основные параметры, которые на неё влияют. В нашем понимании защищаемость — это способность подключённых к интернету ресурсов быть эффективно защищёнными от DDoS-атак с минимальными затратами средств, времени и усилий. Эффективность в данном случае мы трактуем как отношение продолжительности времени, когда последствия атаки не отражаются на доступности ресурсов, к общей длительности атаки. В идеале это отношение должно стремиться к единице. Меньшее его значение говорит о том, что с какого-то момента доступность атакованного ресурса стала критически низкой.
Защищаемость — это, если угодно, иммунитет ресурса к воздействию DDoS-атак: чем он выше, тем более эффективной может быть его защита. И, наоборот, если иммунитет слаб, то и защита может не спасти этот ресурс — он наверняка на какое-то время окажется недоступным.
Чтобы обеспечить защищаемость ресурса, нужно решить четыре ключевые задачи:
- Предоставить как можно меньше информации о ресурсе атакующему: для злоумышленника ваш ресурс должен быть в максимальной степени «чёрным ящиком».
- Предоставить как можно больше информации провайдеру DDoS-защиты, чтобы он ясно представлял, что именно надо защищать, какие особенности имеются у ваших ресурсов и пр.
- Обеспечить понятные провайдеру возможности для фильтрации атаки (особенно это касается защиты приложений).
- Обеспечить надёжную и устойчивую работу ресурса во время атаки. Нужно, во-первых, понимать, что удар может прийтись на незащищённые по каким-то причинам компоненты ресурса. И, во-вторых, всегда нужно учитывать, что часть атаки, пусть и небольшая, может пробиться сквозь DDoS-защиту и существенно повысить нагрузку на ресурс.
Первый шаг имеет значение
Первым вашим шагом, который следовало бы сделать, прежде чем приобретать сервисы Anti-DDoS, должно быть составление перечня ресурсов, которые вы планируете защищать, и подробного описания необходимых уровней их защиты. Нужно сесть и подумать, какие сайты, веб-приложения, сервисы, обслуживающие мобильные устройства, а также серверы, сети, IP-адреса и прочие ресурсы могут подвергнуться DDoS-атакам, а потому нуждаются в защите.
Иначе получится как в случае с нашим клиентом, который начал (причём срочно) подключать защиту лишь тогда, когда понял, что ему не устоять против мощной атаки. И тогда выяснилось, что у его специалистов нет под рукой ни списка всех интернет-сервисов, ни сертификатов и приватных ключей к ним. Пока клиент судорожно пытался найти или заново составить список своих сервисов, его сеть стала недоступной. И поскольку он не мог зайти в сеть, то и понять, какие именно из его ресурсов стали целями атаки, тоже не смог.
Также надо определить, какая именно защита требуется вашим ресурсам: достаточно ли фильтровать пакеты сетевого (L3 по модели OSI) и транспортного (L4) уровней, нужен ли анализ трафика на уровне приложений (L7), передаваемого по протоколам HTTP / HTTPS или «поверх» них, какие ресурсы можно защитить с раскрытием приватных ключей SSL, а какие нельзя.
Подробный анализ потребностей в защите поможет избежать многих проблем, возникающих из-за DDoS-атак.
И вот пример того, к чему может привести недостаточная проработка этих потребностей. Один из наших клиентов подключил сервисы Anti-DDoS не только от крупного международного поставщика, но и от своего интернет-провайдера, однако эти сервисы не смогли обезопасить компанию от DDoS-атак минувшей весной. Когда мы стали разбираться, на каких уровнях осуществляется защита, то выяснилось, что защита от пакетного флуда на уровнях L3 и L4 есть, а от атак на уровне L7 её нет — что как раз и стало причиной недоступности интернет-приложений, оказавшихся целью атаки.
Особые требования — к обработке персональных и финансовых данных
Если ваш ресурс представляет собой финансовый сервис или приложение обеспечивающее обмен конфиденциальными (например, персональными) данными, то, скорее всего, придётся использовать защиту без раскрытия приватных ключей SSL. В частности, она требуется для систем, которые должны соответствовать международному стандарту платёжных систем PCI DSS.
Поясним: на уровне L7 обычно применяется защита с раскрытием приватных ключей SSL, поскольку этот способ предоставляет широкие возможности для интерактивных проверок клиентов приложения (тех, кто обратился к нему с запросом) и облегчает принятие решения о том, безопасно ли приложению иметь дело с конкретным клиентом.
Но если приложение обменивается финансовыми или иными конфиденциальными данными, то нужно использовать защиту без раскрытия приватных ключей. В этом случае круг возможностей для проведения проверок клиентов приложения резко сужается. Не вдаваясь в подробности, скажем, что для оценки легитимности в таких сценариях применяется анализ системных журналов (логов) на наличие сигнатур, а также более сложный анализ с построением поведенческой модели клиентов приложения на основе машинного обучения: по накопленным в системных журналах данным создаётся модель нормального поведения, а заметное отклонение от неё воспринимается как сигнал тревоги. Если такой сигнал поступает, то трафик, связанный с подозрительным клиентом, блокируется.
Иногда бывает удобно использовать гибридный подход с применением отдельной пары, состоящей из сертификата и ключа, которая создаётся специально для обеспечения защиты от DDoS-атак. При таком сценарии удаётся скрыть «родной» приватный ключ, но при этом использовать защиту с раскрытием — у StormWall есть такая возможность.
Не все сервисы защиты одинаково полезны
После составления списка всех ресурсов, которые необходимо обезопасить, и определения способов их защиты нужно выбрать качественного, надёжного провайдера Anti-DDoS с хорошей репутацией, обладающего достаточной компетентностью не только для оказания услуг защиты, но и для консультирования по поводу выстраивания обороны от кибератак и подключения сервисов Anti-DDoS наилучшим образом.
Как правило, компании, которые не специализируются на оказании услуг защиты от DDoS-атак, просто продают доступ к веб-интерфейсам каких-то решений или устройств, сами толком не понимая, как они работают. С этим как раз и связаны все дальнейшие проблемы: защита, скорее всего, предоставляется лишь на бумаге, а на деле она либо вовсе не работает, либо оказывается неэффективной.
Схожая картина наблюдается и в ситуациях, когда оператор коммерческого дата-центра, облачный или интернет-провайдер перепродаёт сервисы защиты своего партнёра — провайдера Anti-DDoS. В принципе в этом нет ничего плохого. Вопрос — в том, какого качества и объёма поддержка при этом будет предоставляться в случае атаки: будет ли у вас прямая связь с провайдером сервисов Anti-DDoS и его службой поддержки и есть ли у хостера или интернет-провайдера, который непосредственно продаёт сервисы Anti-DDoS, собственные специалисты по защите от DDoS-атак.
Впрочем, что говорить о хостерах и интернет-провайдерах, если даже у специализированных DDoS-защитников уровень и качество сервисов сильно различаются. Далеко не каждый провайдер Anti-DDoS сможет, например, подстроить свою защиту под особенности ваших интернет-ресурсов. Поэтому следует заранее уточнить, насколько он готов адаптироваться под ваши требования и специфику.
Не все провайдеры Anti-DDoS предоставляют и доступ к настройкам защиты, а у тех, кто предоставляет, возможности этих настроек могут варьироваться в широком диапазоне. Полезно узнать и затем проверить в ходе тестирования, какова мощность системы фильтрации этого провайдера — 100, 200, 600 Гбит/с или какая-то иная: это поможет оценить, способны ли сами фильтры устоять в случае атаки с серьёзной мощностью.
Очень важно понять, какую именно защиту предлагает конкретный провайдер. Часто (особенно, если защита идёт как дополнение к интернет-услуге) это защита на уровнях L3 / L4 модели OSI. Но она в принципе неспособна обезопасить сайты и приложения от атак с применением HTML-ботов. Если атака запускается с нескольких компьютеров, то на пакетном уровне можно выявить некую аномальную активность, которую нужно отфильтровать. Однако если число атакующих ботов исчисляется тысячами (такие ботнеты можно арендовать буквально за гроши), то никакая защита уровня L3 / L4 такую атаку не отфильтрует. Впрочем, и не должна. Для отражения таких атак требуется полновесная защита уровня L7, позволяющая анализировать каждый HTTP-запрос, проводить дополнительные проверки, изучать системные журналы, исследовать их и выяснять, какие именно идут запросы, какого рода активность наблюдается, делать выводы и на их основе принимать решения.
Необходимо также убедиться, что провайдер Anti-DDoS знает, как фильтровать наиболее критические для вас виды DDoS-атак, и имеет для этого необходимый набор методов и инструментов, чтобы успешно отсекать нелегитимный трафик. Мы знаем, например, что далеко не все DDoS-защитники умеют фильтровать трафик UDP, причём выясняется это нередко только тогда, когда ресурсы клиента оказываются недоступными. Некоторые защитники, распознав атаку, просто блокируют UDP-трафик, даже не пытаясь его отфильтровать. Многие провайдеры Anti-DDoS не умеют фильтровать DNS-трафик на уровне приложений. И так далее.
Очень важно также понять, какие возможности предоставляет провайдер Anti-DDoS для оперативной связи с клиентами: есть ли у его службы технической поддержки телефон, чат, система приёма заявок (тикетов) или иные каналы, через которые можно задать вопрос и быстро получить ответ. Это тоже очень важно, поскольку самое ужасное, что может произойти во время DDoS-атаки, — это долгое, многочасовое, а то и многодневное (если, например, атака случилась вечером накануне выходных) ожидание ответа.
Все эти нюансы необходимо заранее обсудить с провайдером и проработать ещё до подписания договора с ним. Желательно, чтобы он выделил время и проконсультировал вас: предложил варианты для более эффективной защиты вашего периметра, рассказал, что следует учесть и какие методы защиты использовать, чтобы обезопасить те или иные компоненты ваших интернет-ресурсов, и пр.
Кроме того, важно и после подключения защиты не забывать систематически проверять её на работоспособность, используя, например, стресс-тестирование: оно поможет получить хотя бы общее представление о том, что может произойти с вашим сервисом при реальной атаке. В частности, важно понять, как работает поддержка сервисов защиты и что будет, если атака начнётся в пятницу вечером или в воскресное утро, когда большинство специалистов отдыхает, поможет ли вам в этом случае кто-нибудь со стороны провайдера, и пр.
Также стресс-тестирование поможет оценить устойчивость вашего ресурса в случае слабой DDoS-атаки. Не факт, что провайдер сможет отфильтровать все 100 % нелегитимного трафика. И если он отсечёт 99 %, то оставшийся 1 % от мощной атаки легко сможет сделать недоступным ваш ресурс, если тот не обладает достаточной производительностью и неспособен обработать нелегитимный трафик.
Чего нельзя позволять атакующему
Нередко на практике случается так, что в ходе выстраивания защиты от DDoS-атак остаётся некоторое количество незакрытых брешей. Анализируя их, атакующий может узнать о ваших ресурсах достаточно много для того, чтобы провести успешную атаку, пусть и не с первого раза. Иной раз ему удаётся понять особенности вашей инфраструктуры даже лучше вас.
Использование брешей и уязвимостей ресурсов в первую очередь свойственно DDoS-атакам на серверные компоненты мобильных и интернет-приложений. При подключении защиты со сменой IP-адреса на адрес провайдера Anti-DDoS прежний IP-адрес сайта может быть, во-первых, уже известен злоумышленникам, а во-вторых, при желании его легко можно найти через различные ресурсы. Один из них (из этических соображений мы не будем его указывать) позволяет отследить всю историю изменений адреса того или иного IP-домена. Через другой можно получить список всех IP-адресов, с которыми связан этот домен. И так далее. Реальный IP-адрес можно также увидеть анализируя заголовки пакетов протокола электронной почты SMTP, которые ваш сайт отправляет, например, при регистрации пользователей, рассылках писем и других подобных операциях.
Ещё одна частая ошибка — «лоскутность» или «кусочность» выстраивания обороны от DDoS, когда часть ресурсов охвачена ею, а другая часть — нет. Злоумышленники легко смогут найти все ваши ресурсы и выявить среди них незащищённые, уязвимые для DDoS-атак. Можете не сомневаться: при должной мотивации эти ресурсы рано или поздно будут найдены и атакованы.
Если у вас есть своя собственная автономная система, свой префикс, если вы используете BGP, то эту сеть тоже надо защищать. DDoS-атака может обрушиться на незащищённый IP-адрес, и даже межсетевой экран (firewall) и ACL-фильтр не спасут от атаки на него мощностью, например, в 400 Гбит/с. Это вполне реальная угроза! В конце прошлого и начале нынешнего года специалисты StormWall практически каждый день наблюдали вредоносные потоки данных мощностью в 1,2 Тбит/с. Такая атака способна создать чрезмерную нагрузку не только на ваш ресурс, но и на всю сеть вашего провайдера. Поэтому если у вас используется протокол BGP, то надо подключить и защиту через BGP.
Конечно, надо учесть возможность атак на DNS. Обязательно нужно оценить, насколько защищены и насколько надёжно работают сервисы DNS, к которым подключены ваши ресурсы. Когда во время массированных атак, имевших место минувшей весной, крупный российский регистратор доменных имён стал работать нестабильно, многие его клиенты сильно пожалели о том, что не предусмотрели подключения к другому сервису DNS, надёжно защищённому от DDoS-атак. Подобные сервисы предоставляют и провайдеры Anti-DDoS, и компании специализирующиеся на предоставлении сервисов DNS. Лучше всего подключиться как минимум к двум поставщикам DNS-сервисов. И весьма желательно, чтобы провайдеры хотя бы двух таких сервисов обеспечивали их DDoS-защиту.
Если сервер DNS расположен в вашей собственной сети, то эту сеть стоило бы защитить с помощью анонса через BGP. Для этого надо узнать у провайдера Anti-DDoS, умеет ли он фильтровать атаки на DNS, и если умеет, то сообщить ему адреса DNS-серверов, чтобы он настроил на них фильтрацию трафика соответствующего протокола.
Отметим, что StormWall использует множество методов фильтрации трафика DNS на уровне приложений, начиная с простых ограничений по числу запросов к домену, запросов с IP-адреса и т. д. и заканчивая преобразованием DNS-трафика в трафик TCP и другими методами, специфичными именно для DNS-серверов.
Одним словом, подключать DDoS-защиту частично — бесполезно. Нужно комплексно подходить к её выстраиванию, защищать всю цепочку, по которой идёт трафик, начиная от DNS и заканчивая серверными компонентами приложений, и убедиться, что каждый из ваших ресурсов в достаточной степени защищён.
Не оставляйте «грабли»!
Нередко защита от DDoS-атак вроде бы выстраивается, но из-за нелепых ошибок оказывается неэффективной. И поскольку эти ошибки встречаются у самых разных клиентов, мы уже стали называть их «граблями».
Вот пример, демонстрирующий необходимость быть очень осторожными с обращением к интернет-ресурсам напрямую по их IP-адресам, минуя DNS. Атака на одного из наших клиентов пришлась на один из IP-адресов, к которому приложения клиента обращались не через доменное имя, а напрямую. Заменить такой адрес крайне сложно, поскольку он жёстко «прошит» в приложениях. И защитить его во время DDoS-атаки практически невозможно, поскольку для этого пришлось бы уговаривать поставщика этого арендованного IP-адреса обезопасить всю его сеть /24 (а это 256 адресов) с использованием сервисов Anti-DDoS. Однако наверняка провайдер не станет этого делать в спешке.
Ещё один неприятный случай: приложения написаны так, что используют протокол HTTP, но придерживаются его «по-своему». Так, одно банковское приложение нашего клиента проводило авторизацию посредством HTTP, применяя для этого стандартные методы, а затем начинало безо всякого соблюдения протокола отправлять поток данных. Ни одна нормальная DDoS-защита, которая различает методы протокола HTTP, такие запросы не пропустит. Проблема эта в принципе решаема, но её решение требует времени. А когда DDoS-атака уже началась, дорога каждая минута.
У некоторых клиентов обнаружились устаревшие системы, которые не поддерживали протокол SNI (расширение компьютерного протокола TLS) и не передавали в заголовках IP-адрес HTTP-хоста, на который отправляется запрос. Эту проблему также можно решить, но, опять-таки, нужно уделить ей время.
Ещё одна «хрестоматийная» проблема: нередко на границе сети стоит устройство (например, маршрутизатор, межсетевой экран или балансировщик) с низкой производительностью. Очень часто среди таких устройств встречаются межсетевые экраны Cisco ASA и маршрутизаторы MikroTik — они вполне справляются с обычной нагрузкой, но не могут «переварить» даже слабый флуд, блокируя любую проходящую через них сетевую связность. В случае атаки процессор устройства получает стопроцентную загрузку, поэтому понять, что происходит с устройством, во время атаки практически нереально. Если же на этих устройствах работает фильтрация на основе технологии SPI (Stateful Packet Inspection, инспекция пакетов с хранением состояния), то положение усугубляется ещё больше.
Не так просто бывает разрешить ситуации, когда клиент использует защиту от DDoS-атак, которая предложена его транзитным провайдером, поскольку она может сработать в непредсказуемый момент. Один из клиентов применял upstream-маршрутизацию и DDoS-защиту, предоставляемые одним из сотовых операторов «большой четвёрки». В какой-то момент клиент решил отказаться от его сервисов защиты и перейти на наши. Один из наших upstream-каналов проходит также через сеть этого оператора: через неё трафик поступает на фильтры StormWall, а затем уже очищенный передаётся клиентам. Если начинается даже слабая атака, оператор её фиксирует (поскольку у провайдера остались прежние настройки) и начинает перехват (hijacking) трафика на IP-адрес /32, который «закольцовывается» и никуда не уходит. В итоге у клиента становится недоступным банковское приложение. Решение этой проблемы оказалось очень простым: нужно было лишь попросить оператора отключить DDoS-защиту для этого клиента. Поскольку с подобной проблемой уже столкнулись несколько организаций, можно предположить, что она будет достаточно распространённой и в дальнейшем, поскольку сейчас многие операторы и провайдеры на том или ином уровне предоставляют услуги DDoS-защиты.
Самые сложные проблемы — те, что заложены изначально
Как правило, клиенты обращаются за DDoS-защитой тогда, когда их приложения уже созданы, развёрнуты и находятся в промышленной эксплуатации. И в этот момент нередко обнаруживается, что защитить их не так-то просто, поскольку изначально ни заказчики приложений, ни их разработчики не задумывались о связанных с DDoS-атаками рисках и изначально спроектировали эти приложения неудачно.
Приведём пример — типичный, но далеко не исчерпывающий весь спектр ошибок, связанных с проектированием программных продуктов. На приложение дистанционного банковского обслуживания (ДБО) одного из банков, на которое обычно приходит в среднем 500 запросов в секунду, вдруг накатилась мощная волна запросов — порядка 10 тыс. в секунду, причём с каждого IP-адреса источника приходило по 200 запросов в секунду, и все они получали от приложения ответ 401 Unauthorized («отказ в доступе»). Подозревая начало атаки, мы стали блокировать запросы. Неожиданно банк обратился к нам с вопросом о том, почему вдруг заблокированы легитимные посетители. Пытаясь разобраться в ситуации, мы связались с разработчиками, и они нам объяснили: приложение начало выгрузку и эту волну запросов следует расценивать как нормальное поведение. Мы удивились: если такое поведение считается нормальным, то как может выглядеть атака на это приложение? И как нам отличить нормальную активность от инициированной злоумышленниками, если приложение никак себя не обозначает — ни какими-либо особыми методами, ни локациями, ни заголовками, и что делать, если трафик от этого приложения ДБО ничем не отличается от трафика, который генерировал бы бот?
Обычно DDoS-защита мобильных приложений работает так: сначала составляется схема того, как работает приложение (из каких локаций идут посетители, какие заголовки и методы использует, с какой интенсивностью и т. д.), затем на основе этой схемы выстраивается модель нормального взаимодействия, с которой сравниваются все запросы, идущие к приложению. Если никаких признаков, которые позволяли бы отличить легитимные запросы от сгенерированных ботами, не предусмотрено, то распознавание нелегитимных запросов от ботов становится весьма сложным.
Нам также довелось встречать великое множество других ошибок, сделанных ещё на стадии проектирования приложений и сервисов, из-за которых программные продукты получались плохо защищаемыми и на снижение их уязвимости к DDoS-атакам требовалось много денег, времени и усилий. Решение проблемы понятно: заказчики и разработчики приложений должны уже на самых ранних стадиях создания продуктов привлекать к своим проектам специалистов по информационной безопасности (ИБ), в том числе по DDoS-защите. Индустрия ИБ твердит об этом уже не один десяток лет…
Ещё раз о защищаемости
Напоследок ещё раз опишем основные задачи по обеспечению защищаемости, но более развёрнуто, в расчёте на специалистов.
Во-первых, нужно предоставить как можно меньше информации атакующему: по возможности скрыть от него детали вашей архитектуры и протоколов взаимодействия с вашими ресурсами, так чтобы злоумышленник не смог ни определить уязвимые места в них, ни оценить возможный ущерб от воздействия на них, ни выделить возможные цели для атаки, ни понять, насколько успешно она прошла, ни взломать ваши системы, чтобы завладеть нужной информацией или взять под контроль отдельные их компоненты. Если злоумышленник поймёт, что атака не удалась, он начнёт (разумеется, при наличии должной мотивации) искать уязвимости в системе, на которую нацелился, и попытается выявить слабые места в инфраструктуре или приложении, чтобы организовать более эффективную атаку.
Во-вторых, предоставить как можно больше информации провайдеру DDoS-защиты. Он должен ясно понимать архитектуру ваших ресурсов и правила, по которым они взаимодействуют между собой и со внешними ресурсами. Также он должен знать, какие сервисы (сайт, DNS, VPN и пр.) на каких IP-адресах находятся, и иметь возможность распознавать, насколько штатно работают ваши ресурсы в тот или иной момент. Если у вас есть UDP-приложения, то нужно рассказать, где и как они развёрнуты, что и как делают.
В-третьих, надо обеспечить понятные провайдеру Anti-DDoS возможности для фильтрации атаки — это особенно важно для защиты приложений. Крайне желательно, чтобы эти возможности были в них встроены: они позволят провайдеру защиты практически безошибочно отличать поведение легитимных посетителей от поведения ботов, опираясь на конкретные формальные признаки. От решения этой задачи во многом будет зависеть принципиально возможная эффективность защиты ваших приложений.
Если, например, среди ваших ресурсов есть API, мобильные приложения и вы не позаботились заранее о различиях между их взаимодействием с легитимными клиентами и поведением ботов, то единственным, что будет отличать запросы злоумышленников от прочих, окажется подозрительно высокая активность (и, возможно, наличие IP-адресов ботов в базах нежелательных адресов). И если активность бота не превысит активности обычного посетителя, то ни один провайдер DDoS-защиты не сможет его выявить и блокировать.
Нередко сложности возникают и в защите UDP-приложений, поскольку фильтровать UDP-трафик сложнее, чем TCP-трафик. Чтобы точнее определять, является ли очередной пользователь такого приложения легитимным, провайдеру Anti-DDoS необходимо ясно понимать применяемый протокол взаимодействия с клиентами. Возможно, для оценки легитимности у вас предусмотрена процедура предварительной авторизации. Или, другой вариант, имеются чёткие правила взаимодействия с легитимными клиентами, по которым фильтр трафика сможет определить, что данный клиент легитимен. Иногда оценить легитимность удаётся с помощью какого-нибудь TCP-сервиса.
Как мы уже сказали, идеальный вариант — заложить возможности фильтрации атак уже на стадии создания приложения. Для этого нужно ещё в ходе обсуждения общих контуров будущего программного продукта подробно рассказать вашим разработчикам, как вы планируете отличать легитимных клиентов от нелегитимных. Эти знания нужно задокументировать, сохранить и затем передать DDoS-защитнику.
Если же ваше приложение весьма давно находится в продуктивной эксплуатации, можно пойти другим путём: выделить время и разобраться вместе с провайдером Anti-DDoS в том, как оно работает. Подробный анализ его поведения поможет провайдеру подготовить профиль защиты, максимально учитывающий особенности этого приложения.
В-четвёртых, важно обеспечить достаточно высокую устойчивость вашего ресурса к DDoS-воздействиям. Для этого нужно заранее определить, как зависят друг от друга компоненты вашего ресурса, какие у него имеются точки отказа.
Простейший пример: сайт работает в связке с клиентским мобильным приложением, которое запрашивает с него курсы валют или какие-то другие данные. Что будет, если сайт окажется недоступен? Не возникнет ли при этом проблем с мобильным приложением? По-хорошему, оно должно перестать выводить на экран текущие курсы валют или среагировать как-то иначе, но в целом продолжать работать.
Кроме того, надо обеспечить резервирование мощностей и добиться устойчивости ресурса к слабым атакам. Это особенно важно при использовании асимметричной защиты. Как мы уже говорили, при фильтрации некоторых типов DDoS-атак часть трафика «пролетает» насквозь. И если идёт мощная атака, например, в 40 Гбит/с, то отсекание 99 % нелегитимного трафика приведёт к тому, что на защищаемый ресурс обрушится DDoS-воздействие мощностью 400 Мбит/c. Сможет ли он его выдержать — большой вопрос. Чтобы это было возможным, ваш маршрутизатор, межсетевой экран и сервер должны обладать достаточно высокой производительностью.
Кстати, более качественно настроить правила защиты помогает разнесение разных функций и сервисов ресурса по разным IP-адресам: сайты и HTTP-приложения — на одних, UDP-приложения — на других, сервисы обеспечивающие Pull-схему — на третьих, и так далее. Неиспользуемые сетевые сервисы лучше вообще заблокировать, чтобы пресечь возможность DDoS-атак на них.
Золотые правила DDoS-защиты
Напоследок приведём три простых правила, которые помогут вам выстроить надёжную линию обороны от DDoS-атак.
- Обращайтесь за консультациями к компетентным провайдерам Anti-DDoS, которые помогут принять правильные решения по организации защиты вашей инфраструктуры. Это позволит заметно снизить ваши бизнес-риски.
- Постарайтесь начать обсуждение мер по защите от DDoS-рисков как можно раньше — лучше всего на стадии проектирования ваших будущих систем и приложений. Это поможет обеспечить устойчивость ваших ресурсов к DDoS-атакам.
- Гармонично встраивайте защиту от DDoS-рисков в общую стратегию информационной безопасности вашей организации. Очень многие принципы, которые выработала отрасль ИБ, замечательно работают и в отношении DDoS-защиты. Но, конечно, есть у неё и своя специфика, связанная с особенностями DDoS-рисков.
Выводы
Как мы много раз имели возможность убедиться, защищаемость представляет собой интегральный показатель, от которого кардинальным образом зависит устойчивость интернет-систем и ресурсов к DDoS-рискам. В идеале защищаемость должна закладываться ещё на стадии проектирования интернет-систем: правильные шаги, сделанные на этом этапе, позволят заложить в них высокую устойчивость к DDoS и при подключении защиты обеспечат выгодное соотношение эффективности и стоимости отражения этого вида атак.
И, конечно же, нужно понимать, что обеспечение защищаемости — задача многоплановая, затрагивающая все этапы жизненного цикла интернет-систем. Для обеспечения защищаемости необходимо продумывать множество аспектов, поскольку очень многие просчёты и ошибки, совершаемые при её выстраивании, так или иначе снижают эффективность защиты от DDoS-атак и повышают стоимость последующих мероприятий, которые требуются для достижения высокого уровня устойчивости к DDoS. Чтобы справиться со всем комплексом непростых вопросов, касающихся обеспечения защищаемости интернет-систем и ресурсов, рекомендуем не полагаться на собственный опыт, а активно привлекать к сотрудничеству профессиональные компании, специализирующиеся на защите от DDoS-рисков.
