Ошибка при ддос атаке

Цунами DDoS-атак, накрывшее российские интернет-ресурсы весной и летом этого года, продемонстрировало всем актуальность этого вида киберугроз и развеяло последние сомнения относительно необходимости защиты от них. Вопрос — в том, как правильно выстраивать защиту от DDoS-атак и каких ошибок при этом следует избегать.

1. Введение
2. Основа основ — защищаемость
3. Первый шаг имеет значение
4. Особые требования — к обработке персональных и финансовых данных
5. Не все сервисы защиты одинаково полезны
6. Чего нельзя позволять атакующему
7. Не оставляйте «грабли»!
8. Самые сложные проблемы — те, что заложены изначально
9. Ещё раз о защищаемости
10. Золотые правила DDoS-защиты
11. Выводы

Введение

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

В июне Anti-Malware.ru собрал оценки зарегистрированного уровня DDoS-атак, зафиксированных в первом квартале 2022 года, в статье «Развенчиваем мифы: DDoS-атаки в первом квартале 2022 г. были аномально сильными». Стоит отметить их постоянно растущую мощность — полтора месяца назад Cloudflare зафиксировала атаку мощностью 26 млн запросов в секунду, — а также длительность: II квартал побил рекорд по длительности DDoS (по данным Kaspersky).

Основа основ — защищаемость

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

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

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

Чтобы обеспечить защищаемость ресурса, нужно решить четыре ключевые задачи:

1. Предоставить как можно меньше информации о ресурсе атакующему: для злоумышленника ваш ресурс должен быть в максимальной степени «чёрным ящиком».
2. Предоставить как можно больше информации провайдеру DDoS-защиты, чтобы он ясно представлял, что именно надо защищать, какие особенности имеются у ваших ресурсов и пр.
3. Обеспечить понятные провайдеру возможности для фильтрации атаки (особенно это касается защиты приложений).
4. Обеспечить надёжную и устойчивую работу ресурса во время атаки. Нужно, во-первых, понимать, что удар может прийтись на незащищённые по каким-то причинам компоненты ресурса. И, во-вторых, всегда нужно учитывать, что часть атаки, пусть и небольшая, может пробиться сквозь 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-атак.

1. Обращайтесь за консультациями к компетентным провайдерам Anti-DDoS, которые помогут принять правильные решения по организации защиты вашей инфраструктуры. Это позволит заметно снизить ваши бизнес-риски.
2. Постарайтесь начать обсуждение мер по защите от DDoS-рисков как можно раньше — лучше всего на стадии проектирования ваших будущих систем и приложений. Это поможет обеспечить устойчивость ваших ресурсов к DDoS-атакам.
3. Гармонично встраивайте защиту от DDoS-рисков в общую стратегию информационной безопасности вашей организации. Очень многие принципы, которые выработала отрасль ИБ, замечательно работают и в отношении DDoS-защиты. Но, конечно, есть у неё и своя специфика, связанная с особенностями DDoS-рисков.

Выводы

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

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

DDoS-атаки бывают разных типов — злоумышленники могут атаковать как сервер в целом, так и отдельный сайт. Сегодня мы подробнее остановимся на атаках уровня L7, его еще называют уровнем приложений. В случае с сайтами, такая атака направлена на http/https-сервер и проявляется, как правило, в том, что на веб-сервере запускается огромное количество процессов — нагрузка возрастает и сервер начинает тормозить или становится недоступен по причине исчерпания ресурсов.

Далее расскажем о том, как выявить проблемный сайт на сервере и восстановить работоспособность сайтов при атаках.

1. Диагностика на наличие атаки
   1. Определяем наличие атаки 
   2. DoS-атаки и выявление источника атаки по логам
   3. Простой, но важный способ снижения нагрузки от атак
2. Защита от DDoS-атак
   1. С помощью ISPmanager
      1. Точечная блокировка в ISPmanager
      2. Блокировка по странам
   2. Ручные настройки 
      1. Корректировка параметров apache
      2. Модули nginx
      3. Переменные sysctl
3. Подключение DDoS-защиты
   1. Если нужен сервис защиты, но бюджет не позволяет

Диагностика на наличие атаки 

В первую очередь нам необходимо понять, есть ли DDoS-атака.

Если это атака на канальном уровне, то, скорее всего, ваш сервер будет недоступен, так как сетевой канал забит, и попасть на сервер можно будет только через VNC.
Однако в данной статье мы говорим об атаках на веб-сервер — в этом случае, если есть возможность — зайдите на сервер по ssh.

Определяем наличие атаки

Командами ps и top вы можете выявить главный признак атаки — большое количество процессов httpd (apache2), php-fpm или nginx (реже). 

Если на сервер по ssh войти не удается, то вполне возможно еще удастся попасть через окно VNC в панели VMmanager (бессетевой доступ к VDS).

Также можно перезагрузить сервер через VMmanager и попробовать зайти по ssh. Если возрастает количество процессов веб-сервера, то необходимо остановить его либо, как вариант, можно «убить» все процессы веб-сервера командой:

killall -9 <имя демона-процесса веб-сервера>

Посмотреть, какой процесс запускается в качестве веб-сервера, можно с помощью команды (если утилиты netstat нет, то необходимо предварительно ее установить):

netstat -na | grep ':80 '

netstat -na

Посмотреть количество процессов веб-сервера и количество подключений на 80-ый порт:

ps aux | grep -с <имя демона-процесса веб-сервера>

netstat -na | grep -с ":80 "

Эти команды считают количество процессов веб-сервера и количество подключений на 80 порт (если у вас используется SSL-сертификат, то вместо “80” необходимо указывать “443”, оптимально использовать оба варианта).

Если количество соединений превышает среднестатистическое, вероятно, это DoS/DDoS-атака.

DoS-атаки и выявление источника атаки по логам 

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

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

Посмотреть, какие источники подключений к 80-му (443-му) порту присутствуют, можно с помощью команды:

netstat -an | grep -E ':80 |:443 '| awk '{print $5}' | grep -Eo '[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}' | sort | uniq -c | sort -n

Команда выведет список по возрастанию в виде строк: количество подключений — ip-адрес источника.

Данная команда также поможет в выявлении DoS/DDoS. Tcpdump запишет в файл ddos.log первые 200 пакетов, которые соединений на 80/443 порту:

tcpdump -nr ddos.log | awk '{print $3}' |grep -oE '[0-9]{1,}.[0-9]{1,}.[0-9]{1,}.[0-9]{1,}' |sort |uniq -c |sort -rn

Если атака временно прекратилась или вы хотите узнать, откуда больше всего подключались, можно проанализировать access-лог веб-сервера командой:

grep `date +%d/%b/%Y` /var/www/httpd-logs/*.access.log  | awk '{print $1}' | sort | uniq -c | sort -nr | head -n 10

Она выведет список 10 наиболее «активных» IP-адресов. Также по логу можно выявить, на какой сайт идет очень много обращений.

Выяснить, не было ли однотипных обращений, можно командой:

grep `date +%d/%b/%Y` /var/www/httpd-logs/*.access.log | awk '{print $1" "$7}' | sort | uniq -c | sort -rnk1 | head -n 10

Для этой же цели многие предпочитают использовать модуль mod_status.

Mod_status позволяет в реальном времени осуществлять мониторинг загрузки сервера.

Например, в случае apache 2.4 необходимо отредактировать файл /etc/apache2/mods-enabled/status.conf

Поменять секцию:

      <Location /server-status>

               SetHandler server-status

               Require local

               #Require ip 192.0.2.0/24

       </Location>

на

      <Location /server-status>

               SetHandler server-status

       </Location>

Затем проверить, чтобы следующая строка строка была не закомментирована, т.е. присутствовала в файле именно в таком виде:

ExtendedStatus On

Перезапустите apache.

Теперь по адресу http://ip-aдрес.сервера/server-status доступна статистика запросов к нему.

Нас интересует следующее:

0-0    86795    0/31/31    W     0.54    0    0    0.0    0.09    0.09     89.18.166.89    example.com    GET / HTTP/1.0

1-0    86796    0/19/19    W     0.30    0    0    0.0    0.06    0.06     79.140.78.68    example.com    GET / HTTP/1.0

2-0    86801    0/9/9    W     0.15    0    0    0.0    0.03    0.03     89.18.166.89    example.com    GET / HTTP/1.0

3-0    86802    0/9/9    W     0.14    0    0    0.0    0.03    0.03     82.12.33.48    myhost.com    GET /server-status/ HTTP/1.1

4-0    86805    0/4/4    W     0.07    1    0    0.0    0.01    0.01     79.140.78.68    example.com    GET / HTTP/1.0

5-0    86806    0/3/3    W     0.06    2    0    0.0    0.01    0.01     89.18.166.89    example.com    GET / HTTP/1.0

6-0    86807    0/4/4    W     0.07    0    0    0.0    0.01    0.01     89.18.166.89    example.com    GET / HTTP/1.0

7-0    86808    1/4/4    C     0.08    0    2015    3.0    0.01    0.01     89.18.166.89    example.com    GET / HTTP/1.0

8-0    86811    0/1/1    W     0.02    0    0    0.0    0.00    0.00     89.18.166.89    example.com    GET / HTTP/1.0

9-0    86812    0/1/1    W     0.02    0    0    0.0    0.00    0.00     89.18.166.89    example.com    GET / HTTP/1.0

10-0    86813    0/1/1    W     0.02    0    0    0.0    0.00    0.00     89.18.166.89    example.com    GET / HTTP/1.0 

В данном случае атака идет пустыми запросами GET / к серверу example.com. Вам следует его отключить. Выполнить это лучше всего в панели управления: зайдя в раздел с сайтами, выбрать сайт (в данном случае example.com) и нажать сверху кнопку Файлы конфигурации, где вы увидите внизу конфигурационный файл nginx. Найдите отрывок такого вида:

server {

       listen       80;

       server_name  example.com www.example.com;

Пропишите ниже server_name строку

deny all;

Аналогично сделайте в секции, где указано listen 443;

Если у вас нет nginx, а только apache, то перейдите в корневую директорию сайта и создайте файл .htaccess с содержимым:

Deny from All

Теперь при обращении к сайту будет выдаваться ошибка 403 Forbidden, и нагрузка на остальные сайты значительно снизится.

Простой, но важный способ снижения нагрузки от атак

Как правило, флуд-боты обращаются по доменному имени, но могут перебирать и IP-адреса. В этом случае необходимо создать домен-заглушку. Но не забудьте для него в файлах конфигурации nginx указать deny all; (как в примере выше) или, если у вас только apache, в корневой директории заглушки добавить такой же файл .htaccess с содержимым:

Deny from All

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

Защита от DDoS-атак

С помощью ISPmanager

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

Приступаем к настройке.

Заходим в ISPmanager — раздел «Сайты» (в старом меню это «Домены-WWW-домены») — выделить домен — кнопка «Изменить». Ищем подраздел «Оптимизация» и «защита от DDos» и ставим галочку «Включить защиту от DDoS-атаки» — следом появятся параметры защиты от атаки.

А именно:

«Количество запросов в секунду» — при достижении указанного количества подключений, IP блокируется только в Nginx.
«Максимальный размер всплеска» — при достижении указанного количества подключений, IP блокируется по всем портам на 5 минут.

Обратите внимание! Данный модуль всего лишь метод сглаживания слабых атак силами веб-сервера. Если атака серьезная и полностью выводит из строя веб-сервер своей нагрузкой, то данный модуль никак не спасет. Также не указывайте экстремально низкие значения (меньше 30-20), так как архитектура некоторых сайтов подразумевает, что при одном клике на сайте к серверу уйдет несколько запросов, следовательно, повышается риск заблокировать легитимного пользователя.

Точечная блокировка в ISPmanager и блокировка по странам

Выше мы уже описывали варианты поиска источника нагрузки, когда атакующих IP-адресов немного. В этом случае их проще всего точечно заблокировать в панели ISPmanager в разделе «Администрирование» — «Брандмауэр», нажав кнопку «Создать» и указав адрес:

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

Ручные настройки

Чтобы точечно зафильтровать 80 порт для ip xxx.xxx.xxx.xxx, используйте команду:

iptables -A INPUT -p tcp --src xxx.xxx.xxx.xxx --dport 80 -j DROP

Эти и последующие команды можно и нужно аналогично использовать и для 443-го порта.
Можно использовать ipset (нужен соответствующий модуль):

ipset -N ddos iphash

iptables -A INPUT -p tcp -m tcp --dport 80 -m set --set ddos src -j DROP

while true; do tail -10000 /var/www/httpd-logs/site.ru.access.log | sort | cut -f 1 -d " " | uniq -c | awk '($1>50){print $2}' | xargs -tl -I _ ipset -A ddos _;sleep 30; done

Закрываем icmp (поможет при icmp-flood):

iptables -A INPUT -p icmp -j DROP --icmp-type 8

Ограничение максимального числа «полуоткрытых» соединений с одного IP к конкретному порту (необходим соответствующий модуль):

iptables -I INPUT -p tcp --syn --dport 80 -m iplimit --iplimit-above 10 -j DROP

Ограничение максимального числа соединений с одного IP к конкретному порту:

/sbin/iptables  -A INPUT -p tcp --syn --dport 80 -m connlimit --connlimit-above 3 -j REJECT

Корректировка параметров apache

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

Откройте любым удобным текстовым редактором конфигурационный файл /etc/httpd/conf/httpd.conf (если Centos) и /etc/apache2/mods-available/mpm_prefork.conf (если Debian/Ubuntu):

<IfModule mpm_itk_module>

   StartServers          1

   MinSpareServers       1

   MaxSpareServers       1

   MaxClients          150

   MaxRequestsPerChild  100

</IfModule>

Измените MaxClients (максимальное число процессов) в меньшую сторону до количества процессов, которые не забивают ресурсы вашего сервера до отказа. Каждый процесс apache занимает в среднем 4-8 мегабайт памяти. А лучше узнать точно, сколько памяти в среднем на вашем сервере занимает один процесс apache/httpd так:

top -d 1 | grep -E 'http|apache' | awk '{a+=$7}END{print a/(1024*NR) " Mb"}'

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

Отредактируйте /etc/httpd/conf/httpd.conf (если Centos) и /etc/apache2/apache2.conf (если Debian/Ubuntu)

Следует уменьшить параметры:

Timeout 300

MaxKeepAliveRequests 100

до 60 и 50 соответственно, чтобы как можно скорее старые процессы apache прекращали свое существование.

Модули Nginx

Если панели ISPmanager нет, но используется веб-сервер nginx, проверьте, чтобы nginx был собран с модулями http limit req и GeoIP. С их помощью аналогичным образом, как в панели ISPmanager, только вручную в конфигурационных файлах, можно блокировать доступ для IP-адресов, превысивших ограничение на количество подключений. Также можно заблокировать и доступ по странам. Ввиду возможных особенностей ручных конфигураций, рекомендуем самостоятельно изучить документацию nginx по модулю HTTP limit req и GeoIP.

Переменные sysctl

Системные переменные, которые могут быть полезны, при DDoS.

ICMP-FLOOD

Команда ниже поможет при отражении атаки типа icmp-flood:

sysctl net.ipv4.icmp_echo_ignore_all=1

SYN-FLOOD

Уменьшает время удержания «полуоткрытых» соединений:

sysctl -w net.ipv4.tcp_synack_retries=1

Включает TCP syncookies:

sysctl -w net.ipv4.tcp_syncookies=1

Увеличивает размер очереди полуоткрытых соединений, по умолчанию — 512:

sysctl -w net.ipv4.tcp_max_syn_backlog=4096

Проверяет TCP-соединение каждую минуту. Если на другой стороне — легальная машина, она сразу ответит. По умолчанию — 2 часа:
sysctl -w net.ipv4.tcp_keepalive_time=60

Повторяет проверку через 20 секунд:

sysctl -w net.ipv4.tcp_keepalive_intvl=20

Количество проверок перед закрытием соединения:

sysctl -w net.ipv4.tcp_keepalive_probes=3

Изменяет время ожидания приема FIN:

sysctl -w net.ipv4.tcp_fin_timeout=10

Обратите внимание! Эти настройки будут работать до первой перезагрузки сервера, для постоянного использования параметры необходимо внести в системный конфиг sysctl.conf

Подключение DDoS-защиты

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

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

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

Если нужен сервис защиты, но бюджет не позволяет

Стоит упомянуть и еще один сервис, который допускает вариант бесплатной защиты от DDoS (как вы понимаете, «бесплатно» означает, что это будет не настолько же эффективно) — Cloudflare. 

Базово, на этом сервисе можно добавить свой домен, направив его на предоставляемые ими NS. Также по умолчанию, направив домен на их NS, в качестве А-записей на стороне Cloudflare предлагается указать «проксирующий» IP-адрес, который будет отдаваться по домену глобально и принимать на себя все запросы и пропускать их через фильтр бесплатной защиты. 

Помимо того, что более эффективная фильтрация будет платной, есть еще «узкое горлышко» в том, что сам VDS при наличии доменов с Cloudflare не избавляется от угрозы прямой атаки по IP-адресу. Как правило, IP-адрес скрывают, стараются, чтобы по доменам нигде не «светились» старые DNS-записи, ведущие сразу на IP-адрес VDS и т.д.

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

На примере Iptables это можно сделать следующими командами:

iptables -I INPUT -p tcp -m multiport --dports 80,443 -j DROP

ip6tables -I INPUT -p tcp -m multiport --dports 80,443 -j DROP

wget -O - https://www.cloudflare.com/ips-v4 | while read subnet; do iptables -I INPUT -s $subnet -j ACCEPT; done

wget -O - https://www.cloudflare.com/ips-v6 | while read subnet; do ip6tables -I INPUT -s $subnet -j ACCEPT; done

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

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

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

Началось с того, 15 декабря на наш сайт посыпались запросы – тысячи ботов(зараженных устройств со всего мира) с различных IP-адресов отправляли запросы на наш сервер. Каждый бот стал выполнять запросы к своему DNS серверу с неподлинным обратным IP-адресом, который указывал на наш сервер.

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

Стали разбираться, оказывается место на сервере заполнялось, потому, что к сайту идут тысячи запросов – мы подверглись DDoS-атаке. Разработчики и сисадмины, покопались в логах сервера, на котором находится интернет-магазин, буквально за час-два собрался архив данных о том, когда и главное откуда к нам заходили посетители. Самое интересно, что подавляющее число запросов было с IP-адресов Таиланда и Румынии.

Общее количество запросов за 5 часов составило 145 млн.

Чтобы отразить атаку – мы пытались банить адреса и подсети, с которых приходили эти запросы, и на какое-то время это помогло. Через время нам пришло в ВК сообщение в секретном чате, в котором сообщалось, что с нами хотят сотрудничать и, если мы заплатим 50 тыс. руб. атаки прекратятся и они укажут нам на наши уязвимости. Это были словно отголоски из девяностых – принудительная оплата «крыши». Новый культурный интернет-рэкет… Не смотря на столь заманчивое предложение, мы вежливо отказались.

Воспользовавшись услугами наших IT-специалистов, мы отбили атаку, о чем не преминули сообщить в чат. Конечно, ранее мы никогда не сталкивались с атаками и не считали нужным как-то «предохраняться». У нас обычный интернет-магазин подарков, а не сайт Пентагона. Поэтому мы на ходу искали способы отбить атаку, так как опыта в этих вопросах у нас не было. Нам казалось, что мы справились, но это была ошибка – через несколько минут атака возобновилась с новой силой – запросов было в 40 раз больше. Через какое-то время сайт опять «лег».

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

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

Атака была нарастающей, изначально сисадмин банил подозрительные запросы вручную. Бан срабатывал согласно протоколу JavaScript Challenge – данный инструмент посредством математических вычислений проверяет, кто пытается зайти на сайт. Сайт во время проверки блокируется на пару секунд, после чего CloudFlare редиректит запросы на интернет-магазин, но только в том случае, если IP-адреса проходят проверку и получают статус безопасных. Мы решили не пользоваться бесплатным пакетом услуг сервиса и оплатили тариф Pro стоимостью 20 евро в месяц c кредитной карты, плюс мы заплатили 5 евро за выделенный IP-адрес.

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

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

Мы зашли в раздел «доменные имена», далее в «мои домены» и в разделе «сервера имен» нажали «изменить», после чего прописали новые NS адреса. Но мы не учли тот факт, что эта процедура может длится от 4 до 24 часов. Нас это не устраивало, и мы решили воспользоваться специальными настройками и уменьшить у регистратора время вступления изменений в силу. По умолчанию время стоит 12-24 часа, но вы можете задать любое нужное вам время вручную.

CloudFlare: да или нет

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

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

Qrator: плюсы

✔ Автоматическая смарт-фильтрация трафика – сервис фильтрует зашифрованный трафик без нашего участия.

✔ Быстрое подключение сайта к сервису – стар работы сразу после замены DNS интернет-магазина.

✔ Бесплатный тестовый период – 7 дней, если ваш сайт находится под DDoS – атакой, тогда тестовое время составляет 1 сутки.

✔ Защита в том числе и от атак по IP-адресам, для этого мы закрыли доступ к нашему сайту со всех адресов, кроме указанных Qrator.

✔ Русскоговорящая поддержка по телефону, которая помогает все быстро настроить.

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

Вывод

Интернет-магазин работает и наш, и конкурентов, кибер-злодеи остались ни с чем.

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

Цель данной статьи рассказать вам как в случае DDoS – атаки быстро и с минимальными потеря, используя наш опыт отбиться от атаки, не потерять репутацию, прибыль и не растерять клиентов. Да, наши потери составили несколько сотен тысяч рублей, и вы могли подумать, что выгоднее было заплатить 50 тыс. Мы же придерживаемся мнения, что никогда нельзя платить шантажистам, так как те, кто платит раз, будут платить постоянно.

Успешная атака на сервер методом DoS или DDoS способна вывести из строя веб-ресурс на длительный срок — от пары часов до нескольких дней. Это грозит владельцу незапланированными расходами и потерей потенциальной прибыли.

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

• Вымогательство. Злоумышленник нарушает работу ресурса и требует выкуп у владельца за остановку атаки и возвращение сети в рабочее состояние.
• Недобросовестная конкуренция. Заказное нападение со стороны компании-конкурента для переманивания потенциальных клиентов и занятия лидирующего положения на рынке.
• Хактивизм. Мотивом для нападения служат различия в политических взглядах или личная неприязнь. Подобные активисты-хакеры выбирают мишенью правительственные или корпоративные сайты для борьбы за собственные взгляды и обозначения несогласия с официальной позицией властей.
• Развлечение. Часть хакеров наносят вред владельцам ресурсов и их пользователям из хулиганских побуждений, без прямой финансовой выгоды.
• Недовольные сотрудники. В случае возникновения разногласий между работником и работодателем, нападение на корпоративный ресурс, методом DoS или DDoS, выступает как средство сведения счётов.

DoS-атака

Denial of Service («отказ в обслуживании») – нападение с целью вызвать перегрузку и нарушение работы сервиса, путём отправки максимального количества трафика жертве. DoS-атаки проводятся с одного хоста и направлены на отдельные сети или системы.

Особенности DoS

• Одиночная атака. Отправка вредоносных пакетов проводится из одной сети.
• Высокая заметность. Нападения DoS можно без труда зафиксировать, просмотрев журналы (логи) сервера. Достаточно беглого взгляда, чтобы заметить множество записей, связанных с одним IP-адресом.
• Лёгкость подавления. DoS-атаки можно легко предотвратить, заблокировав источник. Это может сделать системный администратор или сетевые фильтры, анализирующие трафик.

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

DDoS-атака

DDoS-атака (Distributed Denial of Service, распределённая атака типа «отказ в обслуживании») – та же DoS-атака, но реализованная с нескольких машин на один целевой хост. Этот метод атаки занимает важное место в арсенале профессиональных хакеров. Мощность нападения напрямую зависит от количества атакующих устройств и объёма отправляемого трафика.

Во время DDoS-атаки возникают большие сложности с обнаружением её источника, так как хакер использует целую сеть связанных между собой машин (ботов). В 9 из 10 случаев атаки ведутся с заражённых вирусами компьютеров обычных пользователей, которые даже не подозревают, что стали невольными соучастниками правонарушения.

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

Особенности DDoS

• Многопоточная атака. Благодаря возможности организовать атаку на ресурс с нескольких хостов шансы «положить» сервер намного выше, чем у нападения методом DoS. Если в подчинении злоумышленника сотни, тысячи, а то и миллионы ботов на разных хостах, то атаку не выдержат даже самые мощные и защищённые системы.
• Скрытность. Вредоносный трафик с нескольких хостов выглядит «живым» для защитных фильтров и администраторов, что усложняет обнаружение и защиту от DDoS-атак. Иногда злоумышленник намеренно ограничивает скорость отправки пакетов, чтобы обезопасить IP-адреса от блокировки.
• Сложность подавления. Остановить мощную DDoS-атаку крайне сложно. Трудности может вызвать не только подавление уже начавшегося нападения, но и обнаружение самого факта атаки.

Категории DoS и DDoS-атак

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

Атаки на переполнение канала

Нападения реализуются путём отправки серверу многочисленных эхо-запросов, которые потребляют ресурсы интернет-канала. Задача подобных атак — провести через сеть жертвы как можно больше ложного трафика, тем самым исчерпав всю ёмкость полосы пропускания. Успешность их проведения напрямую зависит от отправленного объёма данных (Гбит/сек.).

DNS-флуд

• Вид атаки: DDoS
• Тип: UDP-флуд
• Цель: DNS-сервер

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

Ping-флуд

• Вид атаки: DoS / DDoS
• Тип: ICMP-флуд
• Цель: сетевое оборудование III уровня и выше

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

UDP-флуд

• Вид атаки: DoS / DDoS
• Тип: UDP-флуд
• Цель: случайные порты удалённого хоста

Жертве отправляются большие пакеты через бессеансовый протокол пользовательских дейтаграмм (UDP). Когда сервер фиксирует отсутствие приложения, отвечающего за порт, в ответ злоумышленнику отправляется пакет ICMP с сообщением «адресат недоступен». У протокола UDP отсутствуют средства защиты от перегрузок, поэтому этот тип атаки способен захватить весь полезный интернет-трафик сервера.

Атаки, использующие уязвимость стека протоколов

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

SYN-флуд

• Вид атаки: DoS / DDoS
• Тип: TCP-флуд
• Цель: TCP-стек сервера

Злоумышленник создаёт с сервером несколько деактивированных подключений по протоколу TCP. Со стороны хакера отправляются SYN-запросы для соединения с целевой сетью, а жертва, в свою очередь, отправляет ответный пакет SYN-ACK. Для окончания квитирования со стороны отправителя ожидается пакет ACK.

Однако злоумышленник оставляет сессию полуоткрытой — не отправляет запрос или пересылает его на несуществующий адрес. Это происходит до тех пор, пока на сервере не сработает ограничение на максимальное число одновременных открытых подключений. В конечном результате система перестаёт принимать запросы на соединение от настоящих пользователей.

Slow HTTP POST

• Вид атаки: DoS / DDoS
• Тип: атака «медленными» сессиями
• Цель: веб-сервер

Атака Slow HTTP POST («медленные запросы HTTP») направлена на перегрузку веб-серверов с использованием уязвимости в HTTP протоколе. Во время начала нападения злоумышленник отправляет HTTP запрос с заголовком «Content-Length», который даёт информацию целевому веб-серверу о размере последующего пакета. Затем хакер отправляет само сообщение методом POST (отправка), но делает это с очень низкой скоростью, максимально растягивая продолжительность сессии. Таким образом, злоумышленник занимает ресурсы жертвы на длительное время, создавая проблемы при обработке запросов от настоящих пользователей.

«Пинг смерти» (Ping of Death / POD)

• Вид атаки: DoS / DDoS
• Тип: Ping-флуд
• Цель: сетевой стек компьютера

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

Атака приложений

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

Slowloris (Slow HTTP GET)

• Вид атаки: DoS
• Тип: атака «медленными» сессиями
• Цель: веб-сервер

Атака производится с помощью специальных программ, разработанных для нападения на интернет-сервисы, путём создания многочисленных «медленных сессий». Со стороны хакера, в рамках одного запроса, отправляется цепочка неполных HTTP-сессий, содержащих только заголовок без продолжения.

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

Переполнение буфера (Buffer Overflow)

• Вид атаки: DoS
• Тип: атака на уязвимые версии ПО
• Цель: буферная память

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

HTTP-флуд

• Вид атаки: DoS / DDoS
• Тип: HTTP-флуд
• Цель: веб-сервер / веб-приложение

Основная задача атаки: запустить максимальное количество процессов, направленных на обработку запроса. Для нападения злоумышленник отправляет HTTP-серверу многочисленные поддельные запросы GET (получение данных) или POST (отправка данных) через ботнет. В результате исчерпывается лимит размера log-файла и система перестаёт отвечать на реальные запросы пользователей. Хакеры часто применяют HTTP-флуд, поскольку для его реализации требуется меньшая пропускная способность, чем для других видов атак.

Как защитить ресурс от атак

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

Превентивный мониторинг сетевой активности

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

Для автоматической сортировки поступающих запросов рекомендуется использовать сервис с функционалом CDN (Content Delivery Network), например, Cloudflare. Данная сеть работает по принципу «обратного прокси». Копии страниц сайта переносятся на дублирующие серверы по всему миру, которые в критической ситуации отрабатывают весь ложный трафик.

Настройка фильтрации на уровне хостинга

Базовая защита от DoS- и DDoS-атаки – дополнительная услуга, входящая в тариф большинства современных хостинг-провайдеров. Сервис позволяет обеспечить безопасность многих веб-ресурсов малого и среднего масштаба (блогов, интернет-магазинов или форумов).

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

Тестовое нападение на сервер

Хотя полностью обезопасить сеть от DoS/DDoS-атак нельзя, можно подготовиться к нападениям методом пентестинга — моделирования атаки на сервер. Тестовые нападения дают ценный и безопасный опыт, который позволяет закрыть потенциальные проблемы в защите сети и составить эффективные стратегии устранения атак в реальном времени.

Программы для пентестинга

• Hping3. С помощью этого инструмента можно смоделировать стрессовую флуд-атаку (ICMP, SYN, UDP) на сервер. Программа доступна для Linux-систем.
• LOIC (Low Orbit Ion Cannon). Программа для проведения DoS-атаки несколькими методами флуда (HTTP, UDP, TCP). ПО доступно для ОС Windows.
• OWASP Switchblade. Инструмент для ОС Windows с тремя режимами атаки: SSL Half-Open, HTTP Post, Slowloris.

План действий

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

Вывод

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

Нужна надёжная защита сайта от DoS и DDoS-атак? Выбирайте Eternalhost — хостинг с индивидуальной защитой от DDoS, которая реально работает!