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

Цунами 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-рисков.

DoS-атака

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

DDoS-атака.

Распределённая DoS-атака

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

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

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

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

Защита

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

Причины использования DDoS-атак

Жертвы DDoS-атак.

Специалисты в области защиты информации выделяют несколько причин использования DDoS-атак.

Личная неприязнь

Эта причина нередко служит поводом для атак на крупные коммерческие и правительственные организации и компании. Так в 1999 году были атакованы Web-узлы ФБР, которые впоследствии были недоступны в течение нескольких недель. Мотивом послужил недавний рейд ФБР против хакеров.

Развлечение

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

Политический протест

Наиболее известными DDoS-атаками с целью политического протеста были акции в поддержку Памятника Воину-освободителю в Эстонии (2007), Южной Осетии (2008), Wikileaks (2011), Megaupload (2012) и EX.UA (2012).

Недобросовестная конкуренция

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

Вымогательство или шантаж

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

Классификация DoS-атак

Работа сервера в нормальном режиме.

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

Насыщение полосы пропускания

В настоящее время практически каждый компьютер подключён к сети Internet, либо к локальной сети. Это служит отличным поводом для осуществления DoS-атаки за счет переполнения полосы пропускания. Обычно злоумышленники пользуются флудом (англ. flood — «наводнение», «переполнение») — атака, связанная с большим количеством обычно бессмысленных или сформированных в неправильном формате запросов к компьютерной системе или сетевому оборудованию, имеющая своей целью или приведшая к отказу в работе системы из-за исчерпания системных ресурсов — процессора, памяти или каналов связи. Есть несколько разновидностей флуда.

HTTP-флуд и ping-флуд

Это самый примитивный вид DoS-атаки. Насыщение полосы пропускания можно осуществить с помощью обычных ping-запросов только в том случае, если канал атакующего (например 1.544 Мбит/с) намного шире канала компьютера-жертвы, скорость в котором 128 Кбит/с. Но такая атака бесполезна против сервера, так как тот, в свою очередь, обладает довольно широкой полосой пропускания. Для атаки на сервер обычно применяется HTTP-флуд. Атакующий шлёт маленький по объёму HTTP-пакет, но такой, чтобы сервер ответил на него пакетом, размер которого в сотни раз больше. Даже если канал сервера в десять раз шире канала атакующего, то все равно есть большой шанс насытить полосу пропускания жертвы. А для того, чтобы ответные HTTP-пакеты не вызвали отказ в обслуживании у злоумышленника, он каждый раз подменяет свой ip-адрес на ip-адреса узлов в сети.

Smurf-атака (ICMP-флуд)

Атака Smurf или ICMP-флуд — одна из самых опасных видов DoS-атак, так как у компьютера-жертвы после такой атаки произойдет отказ в обслуживании практически со 100 % гарантией. Злоумышленник использует широковещательную рассылку для проверки работающих узлов в системе, отправляя ping-запрос. Очевидно, атакующий в одиночку не сможет вывести из строя компьютер-жертву, поэтому требуется ещё один участник — это усиливающая сеть. В ней по широковещательному адресу злоумышленник отправляет поддельный ICMP пакет. Затем адрес атакующего меняется на адрес жертвы. Все узлы пришлют ей ответ на ping-запрос. Поэтому ICMP-пакет, отправленный злоумышленником через усиливающую сеть, содержащую 200 узлов, будет усилен в 200 раз. Поэтому для такой атаки обычно выбирается большая сеть, чтобы у компьютера-жертвы не было никаких шансов.

Атака Fraggle (UDP-флуд)

Атака Fraggle (осколочная граната)(от англ. _Fraggle attack_) является полным аналогом Smurf-атаки, где вместо ICMP пакетов используются пакеты UDP, поэтому её ещё называют UDP-флуд. Принцип действия этой атаки простой: на седьмой порт жертвы отправляются echo-команды по широковещательному запросу. Затем подменяется ip-адрес злоумышленника на ip-адрес жертвы, которая вскоре получает множество ответных сообщений. Их количество зависит от числа узлов в сети. Эта атака приводит к насыщению полосы пропускания и полному отказу в обслуживании жертвы. Если все же служба echo отключена, то будут сгенерированы ICMP-сообщения, что также приведёт к насыщению полосы.

Атака с помощью переполнения пакетами SYN (SYN-флуд)

Установка TCP — соединения.

До появления атаки Smurf была широко распространена атака с помощью переполнения пакетами SYN, также известная под названием SYN-флуд. Для описания её действия можно остановиться на рассмотрении двух систем А и В, которые хотят установить между собой TCP соединение, после которого они смогут обмениваться между собой данными. На установку соединения выделяется некоторое количество ресурсов, этим и пользуются DoS-атаки. Отправив несколько ложных запросов, можно израсходовать все ресурсы системы, отведённые на установление соединения. Рассмотрим подробнее, как это происходит. Хакер с системы А отправляет пакет SYN системе В, но предварительно поменяв свой IP-адрес на несуществующий. Затем, ничего не подозревая, компьютер В отправляет ответ SYN/ACK на несуществующий IP-адрес и переходит в состояние SYN-RECEIVED. Так как сообщение SYN/ACK не дойдет до системы А, то компьютер В никогда не получит пакет с флагом ACK. Данное потенциальное соединение будет помещено в очередь. Из очереди оно выйдет только по истечении 75 секунд. Этим пользуются злоумышленники и отправляют сразу несколько пакетов SYN на компьютер жертвы с интервалом в 10 секунд, чтобы полностью исчерпать ресурсы системы. Определить источник нападения очень непросто, так как злоумышленник постоянно меняет исходный IP-адрес.

Недостаток ресурсов

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

Отправка «тяжёлых» пакетов

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

Переполнение сервера лог-файлами

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

Плохая система квотирования

На некоторых серверах есть так называемая CGI-программа, которая связывает внешнюю программу с Web-сервером. Если хакер получит доступ к CGI, то он сможет написать скрипт (англ. scripting language), который задействует немало ресурсов сервера, таких как оперативная память и процессорное время. К примеру, скрипт CGI может содержать в себе циклическое создание больших массивов или вычисления сложных математических формул. При этом центральный процессор может обращаться к такому скрипту несколько тысяч раз. Отсюда вывод: если система квотирования настроена неправильно, то такой скрипт за малое время отнимет все системные ресурсы у сервера. Конечно, выход из этой ситуации очевиден — поставить определённый лимит на доступ к памяти, но и в этом случае процесс скрипта, достигнув этого лимита, будет находиться в ожидании до тех пор, пока не выгрузит из памяти все старые данные. Поэтому пользователи будут испытывать недостаток в системных ресурсах.

Недостаточная проверка данных пользователя

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

Атака второго рода

Это атака, которая стремится вызвать ложное срабатывание системы защиты и таким образом привести к недоступности ресурса.

Ошибки программирования

Профессиональные реализаторы DoS-атак не используют такой примитивный способ атаки, как насыщение полосы пропускания. Полностью разобравшись в структуре системы жертвы, они пишут программы (эксплойты), которые помогают атаковать сложные системы коммерческих предприятий или организаций. Чаще всего это ошибки в программном коде, приводящие к обращению к неиспользуемому фрагменту адресного пространства, выполнению недопустимой инструкции или другой необрабатываемой исключительной ситуации, когда происходит аварийное завершение программы-сервера — серверной программы. Классическим примером является обращение по нулевому (англ. null) адресу.

Недостатки в программном коде

Обработка исключительных ситуаций всегда была головной болью для создателей операционных систем. Злоумышленники ищут ошибки в программном коде какой-либо программы либо операционной системы, заставляют её обрабатывать такие исключительные ситуации, которые она обрабатывать не умеет. За счёт этого возникают ошибки. Простым примером может служить частая передача пакетов, в которой не учитываются спецификации и стандарты RFC-документов. Злоумышленники наблюдают за тем, справляется ли сетевой стек с обработкой исключительных ситуаций. Если нет, то передача таких пакетов приведёт к панике ядра (kernel panic) или даже к краху всей системы в целом.

К этому классу относится ошибка Ping of death, распространённая в 1990-е годы. Длина пакета IPv4 по стандарту RFC 791 IPv4 не может превышать 65 535 байт; компьютеру-жертве посылается ICMP-пакет большей длины, предварительно разбитый на части; у жертвы от такого пакета переполняется буфер. Другая ошибка тех времён — WinNuke (Windows 95 неправильно обрабатывала редкий бит TCP-пакета URG).

Переполнение буфера

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

Маршрутизация и атаки DNS

Все атаки на DNS-серверы можно разбить на два типа:

1) DoS-атаки на уязвимости в программном обеспечении на DNS-серверах

Их ещё называют атаками на кэш. В процессе этой атаки злоумышленник подменяет IP-адрес DNS-сервера домена жертвы. После чего атакуемый при запросе HTML-страницы, попадает либо в «чёрную дыру» (если IP-адрес был заменён на несуществующий), либо прямиком на сервер злоумышленника. Второй случай более плачевен, так как злоумышленник легко может получить доступ к личным данным ничего не подозревающей жертвы. Рассмотрим на примере, как это происходит. Допустим, что клиент хочет попасть на Web-узел компании microsoft.com. Но использовав уязвимость в DNS-сервере компании, злоумышленник подменил IP-адрес узла microsoft.com на свой. Теперь жертва автоматически перенаправляется на узел к атакующему.

2) DDoS атаки на DNS-серверы

Иллюстрация примера атаки через неправильно сконфигурированный DNS-сервер.

Далее речь пойдёт о DDoS-атаках, так как участие DNS-серверов всегда подразумевает наличие большого количества компьютеров. Атаки на DNS-серверы — самые банальные атаки, приводящие к отказу в обслуживании DNS-сервера как путём насыщения полосы пропускания, так и путём захвата системных ресурсов. Но такая атака требует огромного количества компьютеров-зомби. После её успешного проведения пользователи не могут попасть на нужную им страницу в Интернете, потому что DNS-сервер не может преобразовать доменное имя в IP-адрес сайта. Но в настоящее время атаки на DNS-серверы с использованием большого числа компьютеров-зомби (такую систему называют «ботнет») менее актуальны, так как интернет-провайдеры легко замечают большое количество исходящего трафика и блокируют его. Злоумышленники теперь обходятся небольшими ботнетами, либо не используют их вовсе. Основная идея состоит в том, что хакеры используют DNS-серверы, работающие на основе технологии DNSSEC. Мощность атаки возрастает вследствие увеличения отражений DNS-запросов. В идеале DNS-серверы определённого провайдера должны обрабатывать только те запросы, которые пришли к ним от пользователей этого провайдера, но это далеко от реальности. По всему миру очень много некорректно настроенных серверов, которые могут принять запрос от любого пользователя в Интернете. Работники компании CloudFlare утверждают, что в настоящее время в Интернете более 68 тысяч неправильно настроенных DNS-серверов, из них более 800 — в России. Именно такие DNS-серверы используются для DDoS-атак. Основная идея состоит в том, что практически все DNS-запросы шлются по протоколу UDP, в котором сравнительно просто подменить обратный адрес на адрес жертвы. Поэтому через неправильно сконфигурированные DNS-серверы злоумышленник шлёт такой запрос, чтобы ответ на него был как можно больше по объёму (например, это может быть список всех записей в таблице DNS), в котором обратный IP-адрес подменяется на IP-адрес жертвы. Как правило, серверы провайдеров имеют довольно большую пропускную способность, поэтому сформировать атаку в несколько десятков Гбит/c не составляет особого труда.

Расположение неправильно сконфигурированных DNS-серверов.
Красный — около 30 тысяч штук; бледно-бордовый — около 5 тысяч штук; серый — от 10 до 2000 штук; белый — практически нет неправильно настроенных DNS-серверов

Список автономных систем с самым большим числом неправильно сконфигурированных DNS-серверов на 10.11.2013.

Число DNS-серверов	Имя автономной системы
2108	BELPAK-AS Republican Unitary Telecommunication Enterprise Be
1668	HINET Data Communication Business Group
1596	OCN NTT Communications Corporation
1455	TELEFONICA CHILE S.A.
1402	KIXS-AS-KR Korea Telecom
965	Telefonica de Argentina
894	ERX-TANET-ASN1 Tiawan Academic Network (TANet) Information C
827	KDDI KDDI CORPORATION
770	Compa Dominicana de Telefonos, C. por A. — CODETEL
723	CHINANET-BACKBONE No.31,Jin-rong Street
647	LGDACOM LG DACOM Corporation
606	UUNET — MCI Communications Services, Inc. d/b/a Verizon Busi
604	TELKOMNET-AS2-AP PT Telekomunikasi Indonesia
601	COLOMBIA TELECOMUNICACIONES S.A. ESP

Выявление DoS/DDoS-атак

Существует мнение, что специальные средства для выявления DoS-атак не требуются, поскольку факт DoS-атаки невозможно не заметить. Во многих случаях это действительно так. Однако достаточно часто наблюдались удачные DoS-атаки, которые были замечены жертвами лишь спустя 2-3 суток. Бывало, что негативные последствия атаки (флуд-атаки) выливались в излишние расходы на оплату избыточного Internet-трафика, что выяснялось лишь при получении счёта от Internet-провайдера. Кроме того, многие методы обнаружения атак неэффективны вблизи объекта атаки, но эффективны на сетевых магистральных каналах. В таком случае целесообразно ставить системы обнаружения именно там, а не ждать, пока пользователь, подвергшийся атаке, сам её заметит и обратится за помощью. К тому же для эффективного противодействия DoS-атакам необходимо знать тип, характер и другие характеристики DoS-атак, а оперативно получить эти сведения как раз и позволяют службы обеспечения безопасности. Они помогают произвести некоторые настройки системы. Но определить, была ли данная атака произведена злоумышленником, либо отказ в обслуживании был следствием нештатного события, они не могут. В соответствии с правилами политики обеспечения безопасности, при обнаружении DoS или DDoS-атаки потребуется её регистрация для дальнейшего аудита. После того, как атака была зафиксирована, могут потребоваться службы обеспечения безопасности для некоторых корректировок в системе и для её возвращения к прежнему уровню работы. Также для обнаружения DDoS-атаки могут использоваться службы, не связанные с безопасностью, например, перенаправление трафика по другим каналам связи, включение резервных серверов для копирования информации. Таким образом, средства для обнаружения и предотвращения DDoS-атак могут сильно различаться в зависимости от вида защищаемой системы.

Методы обнаружения DoS-атак можно разделить на несколько больших групп:

• сигнатурные — основанные на качественном анализе трафика.
• статистические — основанные на количественном анализе трафика.
• гибридные (комбинированные) — сочетающие в себе достоинства обоих вышеназванных методов.

Получившие известность DDoS атаки

Визуализация DDoS-атаки

Пик DDoS-атаки на CloudFlare

Воздействие DDoS-атаки на LINX в марте 2013 года.

Архитектура сетей разного уровня в Интернет

Так в 2012 году было проведено несколько крупномасштабных DDoS-атак на DNS-серверы. Первая из них планировалась на 31 марта, но так и не состоялась. Целью злоумышленников из группы Anonymous было довести до отказа всю глобальную сеть Интернет. Они хотели это сделать с помощью DDoS-атаки на 13 корневых DNS-серверов33. Злоумышленники выпустили специальную утилиту Ramp, которая предназначалась для объединения более мелких DNS-серверов и интернет-провайдеров. С помощью них и планировалось вывести из строя глобальную сеть.

Точно такая же атака была проведена в ноябре 2002 года. Её до сих пор считают самой глобальной DoS-атакой на DNS-серверы, так как в результате злоумышленники смогли вывести из строя 7 корневых серверов. Следующая атака прошла в августе на компанию AT&T, являющуюся крупнейшей американской телекоммуникационной компанией. В результате после атаки, которая продлилась 8 часов, вышли из строя DNS-серверы компании. Пользователи некоторое время не могли зайти не только на сайт компании AT&T, но и на коммерческие сайты в её сети.

Ещё одна атака прошла 10 ноября 2012 года на компанию Go Daddy, которая является крупнейшим в мире хостинг-провайдером. Последствия атаки были разрушительны: пострадал не только сам домен www.godaddy.com, но и более 33 миллионов доменов в сети Интернет, которые были зарегистрированы компанией.

Намного раньше, 22 августа 2003 года злоумышленники при помощи вируса Mydoom вывели из строя сайт компании SCO, занимающейся разработкой системного программного обеспечения. Целых 3 дня пользователи не могли попасть на сайт компании.

Атака на Spamhaus

15 сентября 2012 года, крупная DDoS-атака мощностью в 65 Гбит/с обрушилась на компанию CloudFlare, которая является сетью доставки контента, предназначенная для виртуального хостинга. Серверы данной компании расположены по всему миру. Это помогает пользователю загружать страницу в Интернете с ближайшего (с географической точки зрения) сервера CloudFlare намного быстрее. Ранее данная компания выдерживала DDoS-атаки мощностью в несколько десятков Гбит/с, но с атакой в 65 Гбит/с справиться не смогла. Этот пик пришёлся на субботу 15 сентября в 13:00. Сотрудники, работавшие на тот момент в компании CloudFlare, были бывшими хакерами, которым стало интересно разобраться, каким же именно методом была проведена данная DDoS-атака, и как злоумышленники смогли провести её с такой мощностью. Оказалось, что для такой атаки потребовалось бы 65 тысяч ботов, создающих трафик в 1 Мбит/c каждый. Но это невозможно, так как интернет-провайдеры с лёгкостью обнаружат и заблокируют такой большой объём трафика. При этом аренда большого ботнета очень дорого обходится. Поэтому выяснилось, что для такой атаки использовался метод приумножения DNS-запросов через открытые DNS-серверы.

Приблизительно через полгода, 18 марта, началась, по версии газеты The New York Times, самая большая DDoS-атака в истории, жертвой которой стала компания Spamhaus, занимающаяся занесением в чёрный список источников спама. Причиной атаки послужил тот факт, что Spamhaus занесла в чёрный список за рассылку спама голландского хост-провайдера Cyberbunker. Второй свое недовольство выразил с помощью DDoS-атаки с пиковой мощностью в 300 Гбит/с через открытые DNS-серверы. 19 марта мощность достигла 90 Гбит/c, меняя свое значение от 30 Гбит/с. После этого было затишье, но оно продлилось недолго и атака возобновилась с новой силой и 22 марта её мощность достигла 120 Гбит/c. Для отражения атаки компания CloudFlare распределила трафик между своими дата-центрами, после чего Cyberbunker поняла, что не сможет «положить» CloudFlare и начала новую волну атаки на её вышестоящие пиры. Некоторая часть пакетов отфильтровалась на уровне Tier2, остальной трафик попал на уровень Tier1, где мощность и достигла своего максимума в 300 Гбит/c. В этот момент миллионы пользователей сети Интернет почувствовали на себе всю мощь данной атаки, у них тормозили некоторые сайты. В итоге провайдеры выдержали эту атаку, но в Европе было зарегистрировано некоторое увеличение пинга при доступе к различным сайтам. Например, в лондонском центре обмена трафика LINX 23 марта из-за атаки скорость обмена данными упала более чем в два раза. Средняя скорость в 1.2 Тбит/c упала до 0.40 Тбит/c.

Защита от основных видов DoS-атак

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

Защита от HTTP-флуда

Для защиты от HTTP-флуда необходимо увеличить одновременное количество максимальных подключений к базе данных сервера, установить перед Web-сервером Apache производительный Nginx для кэширования запросов.

# Увеличение максимального количества используемых файлов
  worker_rlimit_nofile 80000;
  events {
      # Увеличение максимального количества соединений
      worker_connections 65536;
      # Использование эффективного метода epoll для обработки соединений
      use epoll;
  }
  http {
      gzip off;
      # Отключение таймаута на закрытие keep-alive соединений
      keepalive_timeout 0;
      # Скрытие версии nginx в заголовке ответа
      server_tokens off;
      # Сбрасывание соединения по таймауту
      reset_timedout_connection on;
  }
  # Стандартные настройки для работы в качестве прокси
  server {
      listen 111.111.111.111 default deferred;
      server_name host.com www.host.com;
      log_format IP $remote_addr;
      location / {
          proxy_pass http://127.0.0.1/;
      }
     location ~* .(jpeg|jpg|gif|png|css|js|pdf|txt|tar)$ {
         root /home/www/host.com/httpdocs;
     }
  }

Защита от ICMP-флуда

Для того, чтобы защититься от ICMP-флуда нужно отключить ответы на запросы ICMP ECHO:

# sysctl net.ipv4.icmp_echo_ignore_all=1

или с помощью брандмауэра:

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

Защита от UDP-флуда

Так как UDP-пакеты отсылаются на различные UDP-сервисы, то достаточно просто отключить их от внешнего мира и установить ограничение на количество соединений к DNS-серверу:

# iptables -I INPUT -p udp—dport 53 -j DROP -m iplimit—iplimit-above 1

Защита от SYN-флуда

Защита строится на отключении очереди «полуоткрытых» TCP-соединений:

# sysctl -w net.ipv4.tcp_max_syn_backlog=1024

Включение механизма TCP syncookies:

# sysctl -w net.ipv4.tcp_syncookies=1 

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

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

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

 # Защита от спуфинга
  net.ipv4.conf.default.rp_filter = 1
  # Проверять TCP-соединение каждую минуту. Если на другой стороне - легальная машина, она сразу ответит. Значение по умолчанию - 2 часа.
  net.ipv4.tcp_keepalive_time = 60
  # Повторить через 10 секунд
  net.ipv4.tcp_keepalive_intvl = 10
  # Количество проверок перед закрытием соединения
  net.ipv4.tcp_keepalive_probes = 5

Универсальные советы

Также есть несколько универсальных советов, которые помогут подготовить систему к DoS-атаке.

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

Действия в самом начале DoS-атаки

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

grep ":80 " | grep SYN_RCVD

В идеале их не должно быть совсем (максимум 1-3). Если это не так, то можно говорить о наличии DoS-атаки. Сложнее обстоит дело с HTTP-флудом. В самом начале необходимо подсчитать количество подключений на 80 порт и количество процессов Apache. Если они значительно превышают среднестатистические, то следует задуматься.

grep httpd | wc -l |  grep ":80 " | wc -l

Список IP-адресов, с которых идут запросы на подключение можно посмотреть следующей командой:

grep ":80 " | sort | uniq -c | sort -nr | less

Далее следует провести анализ пакетов с помощью команды tcpdump:

# tcpdump -n -i eth0 -s 0 -w output.txt dst port 80 and host IP-сервера

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

# iptables -A INPUT -s xxx.xxx.xxx.xxx -p tcp—destination-port http -j DROP

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

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

Цитата

«Только атаки дилетантов нацелены на машины. Атаки профессионалов нацелены на людей».
Б. Шнайер

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

Меры противодействия DDoS-атакам можно разделить на пассивные и активные, а также на превентивные и реакционные. Ниже приведён краткий перечень основных методов.

• Предотвращение. Профилактика причин, побуждающих тех или иных лиц организовывать и предпринять DDoS-атаки. (Очень часто кибератаки вообще являются следствиями личных обид, политических, религиозных и иных разногласий, провоцирующего поведения жертвы и т. п.). Нужно вовремя устранить причины DDoS-атак, после этого сделать выводы, чтобы избежать таких атак в будущем.
• Ответные меры. Применяя технические и правовые меры, нужно как можно активнее воздействовать на источника и организатора DDoS-атаки. В настоящее время даже существуют специальные фирмы, которые помогают найти не только человека, который провел атаку, но даже и самого организатора.
• Программное обеспечение. На рынке современного программного и аппаратного обеспечения существует и такое, которое способно защитить малый и средний бизнес от слабых DDoS-атак. Эти средства обычно представляют собой небольшой сервер.
• Фильтрация и блэкхолинг. Блокирование трафика, исходящего от атакующих машин. Эффективность этих методов снижается по мере приближения к объекту атаки и повышается по мере приближения к атакующей машине. В этом случае фильтрация может быть двух видов: использование межсетевых экранов и списков ACL. Использование межсетевых экранов блокирует конкретный поток трафика, но не позволяет отделить «хороший» трафик от «плохого». ACL списки фильтруют второстепенные протоколы и не затрагивают протоколы TCP. Это не замедляет скорость работы сервера, но бесполезно в том случае, если злоумышленник использует первостепенные запросы.
• Обратный DDOS — перенаправление трафика, используемого для атаки, на атакующего. При достаточной мощности атакуемого сервера позволяет не только успешно отразить атаку, но и вывести из строя сервер атакующего.
• Устранение уязвимостей. Не работает против флуд-атак, для которых «уязвимостью» является конечность тех или иных системных ресурсов. Данная мера нацелена на устранение ошибок в системах и службах.
• Наращивание ресурсов. Абсолютной защиты, естественно, не дает, но является хорошим фоном для применения других видов защиты от DDoS-атак.
• Рассредоточение. Построение распределённых и дублирование систем, которые не прекратят обслуживать пользователей, даже если некоторые их элементы станут недоступны из-за DoS-атаки.
• Уклонение. Увод непосредственной цели атаки (доменного имени или IP-адреса) подальше от других ресурсов, которые часто также подвергаются воздействию вместе с непосредственной целью атаки.
• Активные ответные меры. Воздействие на источники, организатора или центр управления атакой, как техногенными, так и организационно-правовыми средствами.
• Использование оборудования для отражения DDoS-атак. Например, DefensePro® (Radware), SecureSphere® (Imperva), Периметр (МФИ Софт), Arbor Peakflow®, Riorey, Impletec iCore и от других производителей.
• Приобретение сервиса по защите от DDoS-атак. Актуально в случае превышения флудом пропускной способности сетевого канала.

Также компания Google готова предоставлять свои ресурсы для отображения контента вашего сайта в том случае, если сайт находится под DDoS-атакой. На данный момент сервис Project Shield находится на стадии тестирования, но туда могут быть приняты сайты некоторых тематик. Цель проекта — защитить свободу слова.

3 Ноября 2015

4 703

В избр.
Сохранено

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

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

Почему сайты подвергаются атакам?

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

Различают несколько видов причин для атаки:

• Недобросовестная конкуренция служит поводом для атак на крупные коммерческие компании и организации. Если ваш ресурс является коммерческим, то убедитесь, что это не атака конкурирующих компаний. Такие атаки на сайт прекращаются с завершением оплаченного “объема” атаки.
• Развлечение. Как ни странно, DDoS-атаки могут служить развлечением для начинающих злоумышленников, поэтому иногда причиной проблемы может быть хулиганство со стороны хакеров без конкретной цели нанести урон компании. Такие атаки завершаются, когда хакеру становиться скучно атаковать ресурс.
• Идеологические причины. Такие атаки обычно ведутся на какие-либо ресурсы организаций, действия которых не устраивают хакеров. В этом случае действия хакера могут иметь принципиальный характер и продолжаться очень долго.
• Вымогательство или шантаж. Таким атакам чаще всего подвергаются популярные интернет-ресурсы. В этом случае злоумышленник связывается с владельцем сайта с требованием предоставить выкуп в обмен на прекращение атаки. Вступать в переговоры не рекомендуется, так как легкие и средние атаки вы сможете отбить без существенных затрат. Крупные же атаки длятся не более 1 дня в виду их высокой стоимости. Поэтому маловероятно, что причиной крупных атак может стать желание обогатиться за ваш счет.

Типы DDoS-атаки

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

Обычно атаки на сайт делятся на два уровня:

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

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

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

Зная детали атаки, вам будет проще решить, какие именно меры следует принимать для решения проблемы.

Устранение возникшей проблемы

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

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

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

Выберите стабильный хостинг с качественной поддержкой

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 тыс. Мы же придерживаемся мнения, что никогда нельзя платить шантажистам, так как те, кто платит раз, будут платить постоянно.

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

Сложность защиты от DDoS-атак заключается в распределенности атакующих хостов. Заблокировать трафик с помощью брандмауэра довольно непросто.

Существует множество различных типов DDoS-атак. Мы разделим их на три основные категории: объемные, протокольные и прикладные. Давайте рассмотрим каждый из них подробно.

Широкомасштабные DDoS-атаки

Широкомасштабные DDoS-атаки созданы для перегрузки трафиком пропускного канала жертвы. Одним из наиболее популярных ее видов является атака отражения (reflection). Принцип ее следующий:

1. Злоумышленники, поменяв свой IP-адрес на адрес цели, отсылают, якобы от неё, запросы серверам, на которых работают службы UDP или TCP.
2. Принимающие сервера отражают сигнал, отправляя ответы на IP-адрес отправителя, используя тот же протокол.

Вы спросите, зачем же такой замысловатый алгоритм действий? Не проще ли напрямую атаковать объект? Дело в том, что ответные пакеты обычно намного больше, чем пакеты исходящих. Например, ответ на DNS-запрос может быть в 28–54 раза больше исходного запроса. Если таких пакетов много – масштаб ущерба может быть критическим.

Протокольные и прикладные DDoS-атаки

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

Когда злоумышленник отправляет на машину большое количество пакетов SYN (synchronize – запрос на синхронизацию), сервер выделяет ресурсы для этого запроса и отправляет обратно пакет SYN ACK (acknowledges, готовность к принятию пакета), предполагая, что это начало запроса на подключение.

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

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

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

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

Увеличить пропускную способность

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

Ответы на аутсорсинг

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

Иметь четкий план реагирования

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

Он должен включать следующее.

Перед атакой:

1. Создайте как можно более точные принципиальные схемы с планом локализации в случае непредвиденной ситуации, с четко прописанными действиями каждого сотрудника компании.
2. Определите, когда и как привлечь вашего интернет-провайдера или организацию по предотвращению DDoS-атак
3. Составьте список тех, кого следует уведомить и когда (контактная информация группы безопасности, соответствующие контакты сетевой команды и т. д.)
4. Убедитесь, что у вашей команды по связям с общественностью есть план того, как и что сообщать вашим клиентам, в случае инцидента, приводящего к потере активов.
5. Все эти документы и списки контактов следует регулярно (не реже одного раза в квартал) пересматривать.

Очень важно, чтобы этот план был распечатан и распространен среди работников, и в случае отказа системы, он был доступен каждому.

Во время атаки:

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

После атаки:

1. Соберите как можно более подробные сведения о произошедшем инциденте.
2. На основании анализа произошедшего обновите план реагирования.

Создание устойчивой архитектуры

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

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

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

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

Нельзя недооценивать

Рассмотренный вид атак нельзя игнорировать, поскольку порой последствия таких действий злоумышленников могут быть непредсказуемыми. Обычно для ее запуска применяются огромные сети из нескольких сотен или даже тысяч зараженных устройств, называемые ботнетами. Мощность последних постоянно увеличивается и их запуск может нанести колоссальный ущерб. Достаточно вспомнить известный случай с ботнетом Mirai, который в 2016 году атаковал крупного DNS-провайдера Dyn, когда из-за возросшей нагрузки упал целый ряд популярных сайтов: GitHub, HBO, Twitter, Reddit, PayPal, Netflix и Airbnb. Mirai на пике нагрузки запускал около 60000 iOT-устройств, в основном это были камеры и маршрутизаторы и специалисты фиксировали его активность вплоть до 2017 года. Поэтому, если вы хотите обезопасить свою компанию, подумайте об этом заранее. Удачи!

***

Материалы по теме

• 🕵 Лучшие инструменты для специалиста по кибербезопасности в 2022 году
• 🕵 Я узнаю тебя из тысячи: поиск киберпреступников с помощью Maltego. Опыт REG.RU

Успешная атака на сервер методом 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, которая реально работает!