Ddos атака — подробное руководство. Что такое ddos атаки, как их осуществляют и методы защиты от них. Что такое DDoS атака - суть и происхождение Как проводятся атаки

Введение

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

Что такое DDoS?

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

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

Некоторые особенности DDoS-атак

Против кого и с какой целью запускаются DDoS-атаки?

DDoS-атаки могут быть запущены против любого ресурса, представленного в сети Интернет. Наибольший ущерб от DDoS-атак получают организации, чей бизнес непосредственно связан с присутствием в Интернет - банки (предоставляющие услуги Интернет-банкинга), интернет-магазины, торговые площадки, аукционы, а также другие виды деятельности, активность и эффективность которых существенно зависит от представительства в Интернет (турфирмы, авиакомпании, производители оборудования и программного обеспечения, и т.д.) DDoS-атаки регулярно запускаются против ресурсов таких гигантов мировой IT-индустрии, как IBM, Cisco Systems, Microsoft и других. Наблюдались массированные DDoS-атаки против eBay.com, Amazon.com, многих известных банков и организаций.

Очень часто DDoS-атаки запускаются против web-представительств политических организаций, институтов или отдельных известных личностей. Многим известно про массированные и длительные DDoS-атаки, которые запускались против web-сайта президента Грузии во время грузино-осетинской войны 2008 года (web-сайт был недоступен в течение нескольких месяцев, начиная с августа 2008 года), против серверов правительства Эстонии (весной 2007 года, во время беспорядков, связанных с переносом Бронзового солдата), про периодические атаки со стороны северокорейского сегмента сети Интернет против американских сайтов.

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

Каковы механизмы запуска DDoS-атак?

Наиболее популярным и опасным способом запуска DDoS-атак является использование ботнетов (BotNets). Ботнет - это множество компьютеров, на которых установлены специальные программные закладки (боты), в переводе с английского ботнет - это сеть ботов. Боты как правило разрабатываются хакерами индивидуально для каждого ботнета, и имеют основной целью отправку запросов в сторону определенного ресурса в Интернет по команде, получаемой с сервера управления ботнетом - Botnet Command and Control Server. Сервером управления ботнетом управляет хакер, либо лицо, купившее у хакера данный ботнет и возможность запускать DDoS-атаку. Боты распространяются в сети Интернет различными способами, как правило - путем атак на компьютеры, имеющие уязвимые сервисы, и установки на них программных закладок, либо путем обмана пользователей и принуждения их к установке ботов под видом предоставления других услуг или программного обеспечения, выполняющего вполне безобидную или даже полезную функцию. Способов распространения ботов много, новые способы изобретаются регулярно.

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

Некоторые атаки запускаются более "безобидными" способами. Например, флэш-моб пользователей определенных форумов, которые по договоренности запускают в определенное время "пинги" или другие запросы со своих компьютеров в сторону конкретного сервера. Другой пример - размещение ссылки на web-сайт на популярных Интернет-ресурсах, что вызывает наплыв пользователей на целевой сервер. Если "фейковая" ссылка (внешне выглядит как ссылка на один ресурс, а на самом деле ссылается на совершенно другой сервер) ссылается на web-сайт небольшой организации, но размещена на популярных серверах или форумах, такая атака может вызвать нежелательный для данного сайта наплыв посетителей. Атаки последних двух типов редко приводят к прекращению доступности серверов на правильно организованных хостинг-площадках, однако такие примеры были, и даже в России в 2009 году.

Помогут ли традиционные технические средства защиты от DDoS-атак?

Особенностью DDoS-атак является то, что они состоят из множества одновременных запросов, из которых каждый в отдельности вполне "легален", более того - эти запросы посылают компьютеры (зараженные ботами), которые вполне себе могут принадлежать самым обычным реальным или потенциальным пользователям атакуемого сервиса или ресурса. Поэтому правильно идентифицировать и отфильтровать именно те запросы, которые составляют DDoS-атаку, стандартными средствами очень сложно. Стандартные системы класса IDS/IPS (Intrusion Detection / Prevention System - система обнаружения / предотвращения сетевых атак) не найдут в этих запросах "состава преступления", не поймут, что они являются частью атаки, если только они не выполняют качественный анализ аномалий трафика. А если даже и найдут, то отфильтровать ненужные запросы тоже не так просто - стандартные межсетевые экраны и маршрутизаторы фильтруют трафик на основании четко определяемых списков доступа (правил контроля), и не умеют "динамически" подстраиваться под профиль конкретной атаки. Межсетевые экраны могут регулировать потоки трафика, основываясь на таких критериях, как адреса отправителя, используемые сетевые сервисы, порты и протоколы. Но в DDoS-атаке принимают участие обычные пользователи Интернет, которые отправляют запросы по наиболее распространенным протоколам - не будет же оператор связи запрещать всем и всё подряд? Тогда он просто прекратит оказывать услуги связи своим абонентам, и прекратит обеспечивать доступ к обслуживаемым им сетевым ресурсам, чего, собственно, и добивается инициатор атаки.

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

Защита от DDoS-атак имеющимися средствами

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

Начнем с рекомендаций Cisco Systems. Специалисты этой компании рекомендуют обеспечить защиту фундамента сети (Network Foundation Protection), которая включает защиту уровня администрирования сетью (Control Plane), уровня управления сетью (Management Plane), и защиту уровня данных в сети (Data Plane).

Защита уровня администрирования (Management Plane)

Термин "уровень администрирования" охватывает весь трафик, который обеспечивает управление или мониторинг маршрутизаторов и другого сетевого оборудования. Этот трафик направляется в сторону маршрутизатора, или исходит от маршрутизатора. Примерами такого трафика являются Telnet, SSH и http(s) сессии, syslog-сообщения, SNMP-трапы. Общие best practices включают:

Обеспечение максимальной защищенности протоколов управления и мониторинга, использование шифрования и аутентификации:

• протокол SNMP v3 предусматривает средства защиты, в то время как SNMP v1 практически не предусматривает, а SNMP v2 предусматривает лишь частично--установленные по умолчанию значения Community всегда нужно менять;
• должны использоваться различные значения для public и private community;
• протокол telnet передает все данные, в том числе логин и пароль, в открытом виде (если трафик перехватывается, эта информация легко может быть извлечена и использована), вместо него рекомендуется всегда использовать протокол ssh v2;
• аналогично, вместо http используйте https для доступа к оборудованию;строгий контроль доступа к оборудованию, включая адекватную парольную политику, централизованные аутентификацию, авторизацию и аккаунтинг (модель AAA) и локальной аутентификации с целью резервирования;

Реализацию ролевой модели доступа;

Контроль разрешенных подключений по адресу источника с помощью списков контроля доступа;

Отключение неиспользуемых сервисов, многие из которых включены по-умолчанию (либо их забыли отключить после диагностики или настройки системы);

Мониторинг использования ресурсов оборудования.

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

• PAD (packet assembler/disassembler);

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

Желательно осуществлять мониторинг использования ресурсов оборудования. Это позволит, во первых, вовремя заметить перегруженность отдельных элементов сети и принять меры по предотвращению аварии, и во вторых, обнаружить DDoS-атаки и аномалии, если их обнаружение не предусмотрено специальными средствами. Как минимум, рекомендуется осуществлять мониторинг:

• загрузки процессора
• использования памяти
• загруженности интерфейсов маршрутизаторов.

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

Защита уровня управления (Control Plane)

Уровень управления сетью включает весь служебный трафик, который обеспечивает функционирование и связность сети в соответствии с заданной топологией и параметрами. Примерами трафика уровня управления являются: весь трафик, генерируемый или предназначенный для процессора маршрутизации (route processor - RR), в том числе все протоколы маршрутизации, в некоторых случаях - протоколы SSH и SNMP, а также ICMP. Любая атака на функционирование процессора маршрутизации, а особенно - DDoS-атаки, могут повлечь существенные проблемы и перерывы в функционировании сети. Ниже описаны best practices для защиты уровня управления.

Control Plane Policing

Заключается в использовании механизмов QoS (Quality of Service - качество обслуживания) для предоставления более высокого приоритета трафику уровня управления, чем пользовательскому трафику (частью которого являются и атаки). Это позволит обеспечить работу служебных протоколов и процессора маршрутизации, то есть сохранить топологию и связность сети, а также собственно маршрутизацию и коммутацию пакетов.

IP Receive ACL

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

• применяются уже непосредственно на маршрутизирующем оборудовании перед тем, как трафик достигает процессора маршрутизации, обеспечивая "персональную" защиту оборудования;
• применяются уже после того, как трафик прошел обычные списки контроля доступа - являются последним уровнем защиты на пути к процессору маршрутизации;
• применяются ко всему трафику (и внутреннему, и внешнему, и транзитному по отношению к сети оператора связи).

Infrastructure ACL

Обычно, доступ к собственным адресам маршрутизирующего оборудования необходим только для хостов собственной сети оператора связи, однако бывают и исключения (например, eBGP, GRE, туннели IPv6 over IPv4, и ICMP). Инфраструктурные списки контроля доступа:

• обычно устанавливаются на границе сети оператора связи ("на входе в сеть");
• имеют целью предотвратить доступ внешних хостов к адресам инфраструктуры оператора;
• обеспечивают беспрепятственный транзит трафика через границу операторской сети;
• обеспечивают базовые механизмы защиты от несанкционированной сетевой активности, описанные в RFC 1918, RFC 3330, в частности, защиту от спуфинга (spoofing, использование поддельных IP адресов источника с целью маскировки при запуске атаки).

Neighbour Authentication

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

Настройка BGP

• фильтрация префиксов BGP (BGP prefix filters) - используется для того, чтобы информация о маршрутах внутренней сети оператора связи не распространялась в Интернет (иногда эта информация может оказаться очень полезной для злоумышленника);
• ограничение количества префиксов, которые могут быть приняты от другого маршрутизатора (prefix limiting) - используется для защиты от DDoS атак, аномалий и сбоев в сетях пиринг-партнеров;
• использование параметров BGP Community и фильтрация по ним также могут использоваться для ограничения распространения маршрутной информации;
• мониторинг BGP и сопоставление данных BGP с наблюдаемым трафиком является одним из механизмов раннего обнаружения DDoS-атак и аномалий;
• фильтрация по параметру TTL (Time-to-Live) - используется для проверки BGP-партнёров.

Если атака по протоколу BGP запускается не из сети пиринг-партнера, а из более удаленной сети, то параметр TTL у BGP-пакетов будет меньшим, чем 255. Можно сконфигурировать граничные маршрутизаторы оператора связи так, чтобы они отбрасывали все BGP пакеты со значением TTL < 255, а маршрутизаторы пиринг-партнеров наоборот - чтобы они генерировали только BGP-пакеты с параметром TTL=255. Так как TTL при каждом хопе маршрутизации уменьшается на 1, данный нехитрый приём позволит легко избежать атак из-за границ вашего пиринг-партнера.

Защита уровня данных в сети (Data Plane)

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

Unicast Reverse Path Forwarding (uRPF)

Нередко атаки запускаются с использованием технологии спуфинга (spoofing) - IP-адреса источника фальсифицируются с тем, чтобы источник атаки невозможно было отследить. Фальсифицированные IP-адреса могут быть:

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

Реализация на маршрутизаторах механизма uRPF позволит предотвратить маршрутизацию пакетов с адресами источника, несовместимыми или неиспользуемыми в сегменте сети, из которого они поступили на интерфейс маршрутизатора. Данная технология позволяет иногда достаточно эффективно отфильтровать нежелательный трафик наиболее близко к его источнику, то есть наиболее эффективно. Многие DDoS-атаки (включая известные Smurf и Tribal Flood Network) используют механизм спуфинга и постоянной смены адресов источника для того, обмануть стандартные средства защиты и фильтрации трафика.

Использование механизма uRPF операторами связи, предоставляющим абонентам доступ в Интернет, позволит эффективно предотвратить DDoS-атаки с применением технологии спуфинга, направленные со стороны собственных абонентов против Интернет-ресурсов. Таким образом, DDoS-атака подавляется наиболее близко к её источнику, то есть наиболее эффективно.

Remotely Triggered Blackholes (RTBH)

Управляемые черные дыры (Remotely Triggered Blackholes) используются для "сбрасывания" (уничтожения, отправления "в никуда") трафика, поступающего в сеть, путем маршрутизации данного трафика на специальные интерфейсы Null 0. Данную технологию рекомендуется использовать на границе сети для сброса содержащего DDoS-атаку трафика при его поступлении в сеть. Ограничением (причем существенным) данного метода является то, что он применяется ко всему трафику, предназначенному для определенного хоста или хостов, являющимися целью атаки. Таким образом, данный метод может использоваться в случаях, когда массированной атаке подвергается один или несколько хостов, что вызывает проблемы не только для атакуемых хостов, но также и для других абонентов и сети оператора связи в целом.

Управление черными дырами может осуществляться как вручную, так и посредством протокола BGP.

QoS Policy Propagation Through BGP (QPPB)

Управление QoS через BGP (QPPB) полволяет управлять политиками приоритета для трафика, предназначенного определенной автономной системе либо блоку IP-адресов. Данный механизм может оказаться очень полезен для операторов связи и крупных предприятий, в том числе и для управления уровнем приоритета для нежелательного трафика или трафика, содержащего DDoS-атаку.

Sink Holes

В некоторых случаях требуется не полностью удалять трафик с использованием черных дыр, а отводить его в сторону от основных каналов или ресурсов для последующего мониторинга и анализа. Именно для этого и предназначены "отводные каналы" или Sink Holes.

Sink Holes используются чаще всего в следующих случаях:

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

Защита от DDoS с использованием специальных средств

Концепция Cisco Clean Pipes - родоначальник отрасли

Современную концепцию защиты от DDoS-атак разработала (да, да, вы не удивитесь! :)) компания Cisco Systems. Разработанная Cisco концепция получила название Cisco Clean Pipes ("очищенные каналы"). В детально разработанной уже почти 10 лет назад концепции довольно подробно описывались основные принципы и технологии защиты от аномалий в трафике, большая часть которых используется и сегодня, в том числе другими производителями.

Концепция Cisco Clean Pipes предполагает следующие принципы обнаружения и подавления DDoS-атак.

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

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

Таким образом, весь цикл защиты от DDoS-атак включает следующие основные стадии:

• Обучение контрольным характеристикам трафика (профилирование, Baseline Learning)
• Обнаружение атак и аномалий (Detection)
• Перенаправление трафика с целью его пропуска через устройство очистки (Diversion)
• Фильтрация трафика с целью подавления атак (Mitigation)
• Ввод трафика обратно в сеть и отправка адресату (Injection).

Н есколько особенностей.
В качестве детекторов могут использоваться два типа устройств:

• Детекторы производства Cisco Systems - сервисные модули Cisco Traffic Anomaly Detector Services Module, предназначенные для установки в шасси Cisco 6500/7600.
• Детекторы производства Arbor Networks - устройства Arbor Peakflow SP CP.

Ниже приведена таблица сравнения детекторов Cisco и Arbor.

Параметр	Cisco Traffic Anomaly Detector	Arbor Peakflow SP CP
Получение информации о трафике для анализа	Используется копия трафика, выделяемая на шасси Cisco 6500/7600	Используется Netflow-данные о трафике, получаемые с маршрутизаторов, допускается регулировать выборку (1: 1, 1: 1 000, 1: 10 000 и т.д.)
Используемые принципы выявления	Сигнатурный анализ (misuse detection) и выявление аномалий (dynamic profiling )	Преимущественно выявление аномалий; сигнатурный анализ используется, но сигнатуры имеют общий характер
Форм-фактор	сервисные модули в шасси Cisco 6500/7600	отдельные устройства (сервера)
Производительность	Анализируется трафик до 2 Гбит/с	Практически неограниченна (можно уменьшать частоту выборки)
Масштабируемость	Установка до 4 модулей Cisco Detector SM в одно шасси (однако модули действуют независимо друг от друга)	Возможность использования нескольких устройств в рамках единой системы анализа, одному из которых присваивается статус Leader
Мониторинг трафика и маршрутизации в сети	Функционал практически отсутствует	Функционал очень развит. Многие операторы связи покупают Arbor Peakflow SP из-за глубокого и проработанного функционала по мониторингу трафика и маршрутизации в сети
Предоставление портала (индивидуального интерфейса для абонента, позволяющего мониторить только относящуюся непосредственно к нему часть сети)	Не предусмотрено	Предусмотрено. Является серьезным преимуществом данного решения, так как оператор связи может продавать индивидуальные сервисы по защите от DDoS своим абонентам.
Совместимые устройства очистки трафика (подавления атак)	Cisco Guard Services Module	Arbor Peakflow SP TMS; Cisco Guard Services Module.
	Защита центров обработки данных (Data Centre) при их подключении к Интернет Мониторинг downstream-подключений абонентских сетей к сети оператора связи	Обнаружение атак на upstream -подключениях сети оператора связи к сетям вышестоящих провайдеров Мониторинг магистрали оператора связи

В последней строке таблицы приведены сценарии использования детекторов от Cisco и от Arbor, которые рекомендовались Cisco Systems. Данные сценарии отражены на приведенной ниже схеме.

В качестве устройства очистки трафика Cisco рекомендует использовать сервисный модуль Cisco Guard, который устанавливается в шасси Cisco 6500/7600 и по команде, получаемой с детектора Cisco Detector либо с Arbor Peakflow SP CP осуществляется динамическое перенаправление, очистка и обратный ввод трафика в сеть. Механизмы перенаправления - это либо BGP апдейты в сторону вышестоящих маршрутизаторов, либо непосредственные управляющие команды в сторону супервизора с использованием проприетарного протокола. При использовании BGP-апдейтов, вышестоящему маршрутизатору указывается новое значение nex-hop для трафика, содержащего атаку - так, что этот трафик попадает на сервер очистки. При этом необходимо позаботиться о том, чтобы эта информация не повлекла организацию петли (чтобы нижестоящий маршрутизатор при вводе на него очищенного трафика не пробовал снова завернуть этот трафик на устройство очистки). Для этого могут использоваться механизмы контроля распространения BGP-апдейтов по параметру community, либо использование GRE-туннелей при вводе очищенного трафика.

Такое положение дел существовало до тех пор, пока Arbor Networks существенно не расширил линейку продуктов Peakflow SP и не стал выходить на рынок с полностью самостоятельным решением по защите от DDoS-атак.

Появление Arbor Peakflow SP TMS

Несколько лет назад, компания Arbor Networks решила развивать свою линейку продуктов по защите от DDoS-атак самостоятельно и вне зависимости от темпов и политики развития данного направления у Cisco. Решения Peakflow SP CP имели принципиальные преимущества перед Cisco Detector, так как они анализировали flow-информацию с возможностью регулирования частоты выборки, а значит не имели ограничений по использованию в сетях операторов связи и на магистральных каналах (в отличие от Cisco Detector, которые анализируют копию трафика). Кроме того, серьезным преимуществом Peakflow SP явилась возможность для операторов продавать абонентам индивидуальный сервис по мониторингу и защите их сегментов сети.

Ввиду этих или других соображений, Arbor существенно расширил линейку продуктов Peakflow SP. Появился целый ряд новых устройств:

Peakflow SP TMS (Threat Management System) - осуществляет подавление DDoS-атак путем многоступенчатой фильтрации на основе данных, полученных от Peakflow SP CP и от лаборатории ASERT, принадлежащей Arbor Networks и осуществляющей мониторинг и анализ DDoS-атак в Интернете;

Peakflow SP BI (Business Intelligence) - устройства, обеспечивающие масштабирование системы, увеличивая число подлежащих мониторингу логических объектов и обеспечивая резервирование собираемых и анализируемых данных;

Peakflow SP PI (Portal Interface) - устройства, обеспечивающие увеличение абонентов, которым предоставляется индивидуальный интерфейс для управления собственной безопасностью;

Peakflow SP FS (Flow Censor) - устройства, обеспечивающие мониторинг абонентских маршрутизаторов, подключений к нижестоящим сетям и центрам обработки данных.

Принципы работы системы Arbor Peakflow SP остались в основном такими же, как и Cisco Clean Pipes, однако Arbor регулярно производит развитие и улучшение своих систем, так что на данный момент функциональность продуктов Arbor по многим параметрам лучше, чем у Cisco, в том числе и по производительности.

На сегодняшний день, максимальная производительность Cisco Guard модет быть достигнута путем создания кластера из 4-х модулей Guard в одной шасси Cisco 6500/7600, при этом полноценная кластеризация этих устройств не реализована. В то же время, верхние модели Arbor Peakflow SP TMS имеют производительность до 10 Гбит/с, и в свою очередь могут кластеризоваться.

После того, как Arbor стал позиционировать себя в качестве самостоятельного игрока на рынке систем обнаружения и подавления DDoS-атак, Cisco стала искать партнера, который бы обеспечил ей так необходимый мониторинг flow-данных о сетевом трафике, но при этом не являлся бы прямым конкурентом. Такой компанией стала Narus, производящая системы мониторинга трафика на базе flow-данных (NarusInsight), и заключившая партнерство с Cisco Systems. Однако серьезного развития и присутствия на рынке это партнерство не получило. Более того, по некоторым сообщениям, Cisco не планирует инвестиции в свои решения Cisco Detector и Cisco Guard, фактически, оставляя данную нишу на откуп компании Arbor Networks.

Некоторые особенности решений Cisco и Arbor

Стоит отметить некоторые особенности решений Cisco и Arbor.

1. Cisco Guard можно использовать как совместно с детектором, так и самостоятельно. В последнем случае он устанавливается в режим in-line и выполняет функции детектора анализируя трафик, а при необходимости включает фильтры и осуществляет очистку трафика. Минус этого режима заключается в том, что, во первых, добавляется дополнительная точка потенциально отказа, и во-вторых, дополнительная задержка трафика (хотя она и небольшая до тех пор, пока не включается механизм фильтрации). Рекомендуемый для Cisco Guard режим - ожидания команды на перенаправление трафика, содержащего атаку, его фильтрации и ввода обратно в сеть.
2. Устройства Arbor Peakflow SP TMS также могут работать как в режиме off-ramp, так и в режиме in-line. В первом случае устройство пассивно ожидает команды на перенаправление содержащего атаку трафика с целью его очистки и ввода обратно в сеть. Во втором пропускает через себя весь трафик, вырабатывает на его основе данные в формате Arborflow и передает их на Peakflow SP CP для анализа и обнаружения атак. Arborflow - это формат, похожий на Netflow, но доработанный компанией Arbor для своих систем Peakflow SP. Мониторинг трафика и выявление атак осуществляет Peakflow SP CP на основании получаемых от TMS данных Arborflow. При обнаружении атаки, оператор Peakflow SP CP дает команду на её подавление, после чего TMS включает фильтры и очищает трафик от атаки. В отличие от Cisco, сервер Peakflow SP TMS не может работать самостоятельно, для его работы требуется наличие сервера Peakflow SP CP, который производит анализ трафика.
3. Сегодня большинство специалистов сходятся во мнении, что задачи защиты локальных участков сети (например, подключение ЦОДов или подключение downstream-сетей) эффек

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

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

Правильные ингредиенты

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

1. Отказаться от Windows Server

Практика подсказывает, что сайт, который работает на винде (2003 или 2008 - неважно), в случае DDoS обречен. Причина неудачи кроется в виндовом сетевом стеке: когда соединений становится очень много, то сервер непременно начинает плохо отвечать. Мы не знаем, почему Windows Server в таких ситуациях работает настолько отвратно, но сталкивались с этим не раз и не два. По этой причине речь в данной статье будет идти о средствах защиты от DDoS-атак в случае, когда сервер крутится на Linux. Если вы счастливый обладатель относительно современного ядра (начиная с 2.6), то в качестве первичного инструментария будут выступать утилиты iptables и ipset (для быстрого добавления IP-адресов), с помощью которых можно оперативно забанить ботов. Еще один ключ к успеху - правильно приготовленный сетевой стек, о чем мы также будем говорить далее.

2. Расстаться с Apache

Второе важное условие - отказ от Apache. Если у вас, не ровен час, стоит Apache, то как минимум поставьте перед ним кеширующий прокси - nginx или lighttpd. Apache"у крайне тяжело отдавать файлы, и, что еще хуже, он на фундаментальном уровне (то есть неисправимо) уязвим для опаснейшей атаки Slowloris, позволяющей завалить сервер чуть ли не с мобильного телефона. Для борьбы с различными видами Slowloris пользователи Apache придумали сначала патч Anti-slowloris.diff, потом mod_noloris, затем mod_antiloris, mod_limitipconn, mod_reqtimeout... Но если вы хотите спокойно спать по ночам, проще взять HTTP-сервер, неуязвимый для Slowloris на уровне архитектуры кода. Поэтому все наши дальнейшие рецепты основываются на предположении, что на фронтенде используется nginx.

Отбиваемся от DDoS

Что делать, если пришел DDoS? Традиционная техника самообороны - почитать лог-файл HTTP-сервера, написать паттерн для grep (отлавливающий запросы ботов) и забанить всех, кто под него подпадет. Эта методика сработает... если повезет. Ботнеты бывают двух типов, оба опасны, но по-разному. Один целиком приходит на сайт моментально, другой - постепенно. Первый убивает все и сразу, зато в логах появляется весь полностью, и если вы их проgrepаете и забаните все IP-адреса, то вы - победитель. Второй ботнет укладывает сайт нежно и осторожно, но банить вам его придется, возможно, на протяжении суток. Любому администратору важно понимать: если планируется бороться grep’ом, то надо быть готовым посвятить борьбе с атакой пару дней. Ниже следуют советы о том, куда можно заранее подложить соломки, чтобы не так больно было падать.

3. Использовать модуль testcookie

Пожалуй, самый главный, действенный и оперативный рецепт этой статьи. Если на ваш сайт приходит DDoS, то максимально действенным способом дать отпор может стать модуль testcookie-nginx , разработанный хабрапользователем @kyprizel. Идея простая. Чаще всего боты, реализующие HTTP-флуд, довольно тупые и не имеют механизмов HTTP cookie и редиректа. Иногда попадаются более продвинутые - такие могут использовать cookies и обрабатывать редиректы, но почти никогда DoS-бот не несет в себе полноценного JavaScript-движка (хотя это встречается все чаще и чаще). Testcookie-nginx работает как быстрый фильтр между ботами и бэкендом во время L7 DDoS-атаки, позволяющий отсеивать мусорные запросы. Что входит в эти проверки? Умеет ли клиент выполнять HTTP Redirect, поддерживает ли JavaScript, тот ли он браузер, за который себя выдает (поскольку JavaScript везде разный и если клиент говорит, что он, скажем, Firefox, то мы можем это проверить). Проверка реализована с помощью кукисов с использованием разных методов:

• «Set-Cookie» + редирект с помощью 301 HTTP Location;
• «Set-Cookie» + редирект с помощью HTML meta refresh;
• произвольным шаблоном, причем можно использовать JavaScript.

Чтобы избежать автоматического парсинга, проверяющая кукиса может быть зашифрована с помощью AES-128 и позже расшифрована на клиентской стороне JavaScript. В новой версии модуля появилась возможность устанавливать кукису через Flash, что также позволяет эффективно отсеять ботов (которые Flash, как правило, не поддерживают), но, правда, и блокирует доступ для многих легитимных пользователей (фактически всех мобильных устройств). Примечательно, что начать использовать testcookie-nginx крайне просто. Разработчик, в частности, приводит несколько понятных примеров использования (на разные случаи атаки) с семплами конфигов для nginx.

Помимо достоинств, у testcookie есть и недостатки:

• режет всех ботов, в том числе Googlebot. Если вы планируете оставить testcookie на постоянной основе, убедитесь, что вы при этом не пропадете из поисковой выдачи;
• создает проблемы пользователям с браузерами Links, w3m и им подобными;
• не спасает от ботов, оснащенных полноценным браузерным движком с JavaScript.

Словом, testcookie_module не универсален. Но от ряда вещей, таких как, например, примитивные инструментарии на Java и C#, он помогает. Таким образом вы отсекаете часть угрозы.

4. Код 444

Целью DDoS’еров часто становится наиболее ресурсоемкая часть сайта. Типичный пример - поиск, который выполняет сложные запросы к базе. Естественно, этим могут воспользоваться злоумышленники, зарядив сразу несколько десятков тысяч запросов к поисковому движку. Что мы можем сделать? Временно отключить поиск. Пускай клиенты не смогут искать нужную информацию встроенными средствами, но зато весь основной сайт будет оставаться в работоспособном состоянии до тех пор, пока вы не найдете корень всех проблем. Nginx поддерживает нестандартный код 444, который позволяет просто закрыть соединение и ничего не отдавать в ответ:

Location /search { return 444; }

Таким образом можно, например, оперативно реализовать фильтрацию по URL. Если вы уверены, что запросы к location /search приходят только от ботов (например, ваша уверенность основана на том, что на вашем сайте вообще нет раздела /search), вы можете установить на сервер пакет ipset и забанить ботов простым shell-скриптом:

Ipset -N ban iphash tail -f access.log | while read LINE; do echo "$LINE" | \ cut -d""" -f3 | cut -d" " -f2 | grep -q 444 && ipset -A ban "${L%% *}"; done

Если формат лог-файлов нестандартный (не combined) или требуется банить по иным признакам, нежели статус ответа, - может потребоваться заменить cut на регулярное выражение.

5. Баним по геопризнаку

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

1. Подключите к nginx GeoIP-модуль (wiki.nginx.org/HttpGeoipModule).
2. Выведите информацию о геопривязке в access log.
3. Далее, модифицировав приведенный выше шелл-скрипт, проgrepайте accesslog nginx’а и добавьте отфутболенных по географическому признаку клиентов в бан.

Если, к примеру, боты по большей части были из Китая, то это может помочь.

6. Нейронная сеть (PoC)

Наконец, вы можете повторить опыт хабрапользователя @SaveTheRbtz, который взял нейронную сеть PyBrain, запихал в нее лог и проанализировал запросы (habrahabr.ru/post/136237). Метод рабочий, хотя и не универсальный:). Но если вы действительно знаете внутренности своего сайта - а вы, как системный администратор, должны, - то у вас есть шансы, что в наиболее трагических ситуациях такой инструментарий на основе нейронных сетей, обучения и собранной заранее информации вам поможет. В этом случае весьма полезно иметь access.log до начала DDoS"а, так как он описывает практически 100% легитимных клиентов, а следовательно, отличный dataset для тренировки нейронной сети. Тем более глазами в логе боты видны не всегда.

Диагностика проблемы

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

7. Юзайте профайлер и отладчик

Для наиболее распространенной платформы создания веб-сайтов - PHP + MySQL - узкое место можно искать с помощью следующих инструментов:

• профайлер Xdebug покажет, на какие вызовы приложение тратит больше всего времени;
• встроенный отладчик APD и отладочный вывод в лог ошибок помогут выяснить, какой именно код выполняет эти вызовы;
• в большинстве случаев собака зарыта в сложности и тяжеловесности запросов к базе данных. Здесь поможет встроенная в движок базы данных SQL-директива explain.

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

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

8. Анализируйте ошибки

Проанализируйте объем трафика, время ответа сервера, количество ошибок. Для этого смотрите логи. В nginx время ответа сервера фиксируется в логе двумя переменными: request_time и upstream_response_time. Первая - это полное время выполнения запроса, включая задержки в сети между пользователем и сервером; вторая сообщает, сколько бэкенд (Apache, php_fpm, uwsgi...) выполнял запрос. Значение upstream_response_time чрезвычайно важно для сайтов с большим количеством динамического контента и активным общением фронтенда с базой данных, им нельзя пренебрегать. В качестве формата лога можно использовать такой конфиг:

Log_format xakep_log "$remote_addr - $remote_user [$time_local] " ""$request" $status $body_bytes_sent " ""$http_referer" "$http_user_agent" $request_time \ $upstream_response_time";

Это combined-формат с добавленными полями тайминга.

9. Отслеживайте количество запросов в секунду

Также посмотрите на число запросов в секунду. В случае nginx вы можете примерно оценить эту величину следующей shell-командой (переменная ACCESS_LOG содержит путь к журналу запросов nginx в combined-формате):

Echo $(($(fgrep -c "$(env LC_ALL=C date --date=@$(($(date \ +%s)-60)) +%d/%b/%Y:%H:%M)" "$ACCESS_LOG")/60))

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

10. Не забывайте про tcpdump

Многие забывают, что tcpdump - это обалденное средство диагностики. Я приведу пару примеров. В декабре 2011-го был обнаружен баг в ядре Linux, когда оно открывало TCP-соединение при выставленных флагах TCP-сегмента SYN и RST. Первым багрепорт отправил именно системный администратор из России, чей ресурс был атакован этим методом, - атакующие узнали об уязвимости раньше, чем весь мир. Ему, очевидно, такая диагностика помогла. Другой пример: у nginx есть одно не очень приятное свойство - он пишет в лог только после полной отработки запроса. Бывают ситуации, когда сайт лежит, ничего не работает и в логах ничего нет. Все потому, что все запросы, которые в данный момент загружают сервер, еще не выполнились. Tcpdump поможет и здесь.

Он настолько хорош, что я советовал людям не использовать бинарные протоколы до того, как они убедятся, что все в порядке, - ведь текстовые протоколы отлаживать tcpdump"ом легко, а бинарные – нет. Однако сниффер хорош как средство диагностики - в качестве средства поддержания production"а он страшен. Он легко может потерять сразу несколько пакетов и испортить вам историю пользователя. Смотреть его вывод удобно, и он пригодится для ручной диагностики и бана, но старайтесь ничего критичного на нем не основывать. Другое любимое многими средство «погрепать запросы» - ngrep - вообще по умолчанию пытается запросить в районе двух гигабайт несвопируемой памяти и только потом начинает уменьшать свои требования.

11. Атака или нет?

Как отличить DDoS-атаку, например, от эффекта рекламной кампании? Этот вопрос может показаться смешным, но эта тема не менее сложная. Бывают довольно курьезные случаи. У одних хороших ребят, когда они напряглись и основательно прикрутили кеширование, сайт слег на пару дней. Выяснилось, что в течение нескольких месяцев этот сайт незаметно датамайнили какие-то немцы и до оптимизации кеширования страницы сайта у этих немцев со всеми картинками грузились довольно долго. Когда страница начала выдаваться из кеша моментально, бот, у которого не было никаких тайм-аутов, тоже начал собирать их моментально. Тяжело пришлось. Случай особенно сложный по той причине, что если вы сами изменили настройку (включили кеширование) и сайт после этого перестал работать, то кто, по вашему и начальственному мнению, виноват? Вот-вот. Если вы наблюдаете резкий рост числа запросов, то посмотрите, например, в Google Analytics, кто приходил на какие страницы.

Тюнинг веб-сервера

Какие еще есть ключевые моменты? Конечно, вы можете поставить «умолчальный» nginx и надеяться, что у вас все будет хорошо. Однако хорошо всегда не бывает. Поэтому администратор любого сервера должен посвятить немало времени тонкой настройке и тюнингу nginx.

12. Лимитируем ресурсы (размеры буферов) в nginx

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

• client_header_buffer_size_ _ Задает размер буфера для чтения заголовка запроса клиента. Если строка запроса или поле заголовка запроса не помещаются полностью в этот буфер, то выделяются буферы большего размера, задаваемые директивой large_client_header_buffers.
• large_client_header_buffers Задает максимальное число и размер буферов для чтения большого заголовка запроса клиента.
• client_body_buffer_size Задает размер буфера для чтения тела запроса клиента. Если тело запроса больше заданного буфера, то все тело запроса или только его часть записывается во временный файл.
• client_max_body_size Задает максимально допустимый размер тела запроса клиента, указываемый в поле «Content-Length» заголовка запроса. Если размер больше заданного, то клиенту возвращается ошибка 413 (Request Entity Too Large).

13. Настраиваем тайм-ауты в nginx

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

• reset_timedout_connection on; Помогает бороться с сокетами, зависшими в фазе FIN-WAIT.
• client_header_timeout Задает тайм-аут при чтении заголовка запроса клиента.
• client_body_timeout Задает тайм-аут при чтении тела запроса клиента.
• keepalive_timeout Задает тайм-аут, в течение которого keep-alive соединение с клиентом не будет закрыто со стороны сервера. Многие боятся задавать здесь крупные значения, но мы не уверены, что этот страх оправдан. Опционально можно выставить значение тайм-аута в HTTP-заголовке Keep-Alive, но Internet Explorer знаменит тем, что игнорирует это значение
• send_timeout Задает тайм-аут при передаче ответа клиенту. Если по истечении этого времени клиент ничего не примет, соединение будет закрыто.

Сразу вопрос: какие параметры буферов и тайм-аутов правильные? Универсального рецепта тут нет, в каждой ситуации они свои. Но есть проверенный подход. Нужно выставить минимальные значения, при которых сайт остается в работоспособном состоянии (в мирное время), то есть страницы отдаются и запросы обрабатываются. Это определяется только тестированием - как с десктопов, так и с мобильных устройств. Алгоритм поиска значений каждого параметра (размера буфера или тайм-аута):

1. Выставляем математически минимальное значение параметра.
2. Запускаем прогон тестов сайта.
3. Если весь функционал сайта работает без проблем - параметр определен. Если нет - увеличиваем значение параметра и переходим к п. 2.
4. Если значение параметра превысило даже значение по умолчанию - это повод для обсуждения в команде разработчиков.

В ряде случаев ревизия данных параметров должна приводить к рефакторингу/редизайну сайта. Например, если сайт не работает без трехминутных AJAX long polling запросов, то нужно не тайм-аут повышать, а long polling заменять на что-то другое - ботнет в 20 тысяч машин, висящий на запросах по три минуты, легко убьет среднестатистический дешевый сервер.

14. Лимитируем соединия в nginx (limit_conn и limit_req)

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

Предположим, что на сайте есть разделы с говорящими названиями /download и /search. При этом мы:

• не хотим, чтобы боты (или люди с чересчур ретивыми рекурсивными download-менеджерами) забили нам таблицу TCP-соединений своими закачками;
• не хотим, чтобы боты (или залетные краулеры поисковых систем) исчерпали вычислительные ресурсы СУБД множеством поисковых запросов.

Для этих целей сгодится конфигурация следующего вида:

Http { limit_conn_zone $binary_remote_addr zone=download_c:10m; limit_req_zone $binary_remote_addr zone=search_r:10m \ rate=1r/s; server { location /download/ { limit_conn download_c 1; # Прочая конфигурация location } location /search/ { limit_req zone=search_r burst=5; # Прочая конфигурация location } } }

Обычно имеет прямой смысл установить ограничения limit_conn и limit_req для locations, в которых находятся дорогостоящие к выполнению скрипты (в примере указан поиск, и это неспроста). Ограничения необходимо выбирать, руководствуясь результатами нагрузочного и регрессионного тестирования, а также здравым смыслом.

Обратите внимание на параметр 10m в примере. Он означает, что на расчет данного лимита будет выделен словарь с буфером в 10 мегабайт и ни мегабайтом более. В данной конфигурации это позволит отслеживать 320 000 TCP-сессий. Для оптимизации занимаемой памяти в качестве ключа в словаре используется переменная $binary_remote_addr, которая содержит IP-адрес пользователя в бинарном виде и занимает меньше памяти, чем обычная строковая переменная $remote_addr. Нужно заметить, что вторым параметром к директиве limit_req_zone может быть не только IP, но и любая другая переменная nginx, доступная в данном контексте, - например, в случае, когда вы не хотите обеспечить более щадящий режим для прокси, можно использовать $binary_remote_addr$http_user_agent или $binary_remote_addr$http_cookie_myc00kiez - но использовать такие конструкции нужно с осторожностью, поскольку, в отличие от 32-битного $binary_remote_addr, эти переменные могут быть существенно большей длины и декларированные вами «10m» могут скоропостижно закончиться.

Тренды в DDoS

1. Непрерывно растет мощность атак сетевого и транспортного уровня. Потенциал среднестатистической атаки типа SYN-флуд достиг уже 10 миллионов пакетов в секунду.
2. Особым спросом в последнее время пользуются атаки на DNS. UDP-флуд валидными DNS-запросами со spoof’ленными IP-адресами источника - это одна из наиболее простых в реализации и сложных в плане противодействия атак. Многие крупные российские компании (в том числе хостинги) испытывали в последнее время проблемы в результате атак на их DNS-серверы. Чем дальше, тем таких атак будет больше, а их мощность будет расти.
3. Судя по внешним признакам, большинство ботнетов управляется не централизованно, а посредством пиринговой сети. Это дает злоумышленникам возможность синхронизировать действия ботнета во времени - если раньше управляющие команды распространялись по ботнету в 5 тысяч машин за десятки минут, то теперь счет идет на секунды, а ваш сайт может неожиданно испытать мгновенный стократный рост числа запросов.
4. Доля ботов, оснащенных полноценным браузерным движком с JavaScript, все еще невелика, но непрерывно растет. Такую атаку сложнее отбить встроенными подручными средствами, поэтому Самоделкины должны с опасением следить за этим трендом.

готовим ОС

Помимо тонкой настройки nginx, нужно позаботиться о настройках сетевого стека системы. По меньшей мере - сразу включить net.ipv4.tcp_syncookies в sysctl, чтобы разом защитить себя от атаки SYN-flood небольшого размера.

15. Тюним ядро

Обратите внимание на более продвинутые настройки сетевой части (ядра) опять же по тайм-аутам и памяти. Есть более важные и менее важные. В первую очередь надо обратить внимание на:

• net.ipv4.tcp_fin_timeout Время, которое сокет проведет в TCP-фазе FIN-WAIT-2 (ожидание FIN/ACK-сегмента).
• net.ipv4.tcp_{,r,w}mem Размер приемного буфера сокетов TCP. Три значения: минимум, значение по умолчанию и максимум.
• net.core.{r,w}mem_max То же самое для не TCP буферов.

При канале в 100 Мбит/с значения по умолчанию еще как-то годятся; но если у вас в наличии хотя бы гигабит в cекунду, то лучше использовать что-то вроде:

Sysctl -w net.core.rmem_max=8388608 sysctl -w net.core.wmem_max=8388608 sysctl -w net.ipv4.tcp_rmem="4096 87380 8388608" sysctl -w net.ipv4.tcp_wmem="4096 65536 8388608" sysctl -w net.ipv4.tcp_fin_timeout=10

16. Ревизия /proc/sys/net/**

Идеально изучить все параметры /proc/sys/net/**. Надо посмотреть, насколько они отличаются от дефолтных, и понять, насколько они адекватно выставлены. Linux-разработчик (или системный администратор), разбирающийся в работе подвластного ему интернет-сервиса и желающий его оптимизировать, должен с интересом прочитать документацию всех параметров сетевого стека ядра. Возможно, он найдет там специфические для своего сайта переменные, которые помогут не только защитить сайт от злоумышленников, но и ускорить его работу.

Не бояться!

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

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

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

Терминология

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

Dos атака - атака типа "отказ в обслуживании". Отсюда и английская аббревиатура dos - Denial of Service. Один из подтипов - распределенная атака, осуществляющаяся одновременно с нескольких, а как правило, с большого количества хостов. Основную часть обсуждения мы посвятим именно этому варианты, потому что ddos атака несет в себе больше разрушительных последствий, а существенная разница лишь в количестве хостов, используемых для атаки.

Чтобы вам было легче понять . Подобного рода действия направлены на временное прекращение работы какого-либо сервиса. Это может быть отдельный сайт в сети, крупный интернет или сотовый провайдер, а также отдельная служба (прием пластиковых карт). Чтобы атака удалась, и принесла разрушительные действия, выполнять ее нужно с большого количества точек (далее этот момент будет рассмотрен более подробно). Отсюда и "распределенная атака". Но суть остается та же - прервать работу определенной системы.

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

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

Допустим на рынке услуг небольшого города есть два крупных провайдера интернет. И один из них хочет вытеснить конкурента. Они заказывают в хакеров распределенную dos атаку на сервера конкурента. И второй провайдер из-за перегрузки своей сети не в силах больше предоставлять доступ в интернет своим пользователям. Как итог - потеря клиентов и репутации. Хакеры получают свое вознаграждение, недобросовестный провайдер - новых клиентов.

Но нередки случаи, когда "ддосят" и просто ради забавы, или оттачивания навыков.

Распределенная Ddos атака

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

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

Давайте посмотрим, как это выглядит на схеме ниже:

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

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

Вам пригодится : мы описывали некоторые аспекты безопасности, в статье .

А вот каким образом они будут использоваться, зависит от того, какой вариант выбран злоумышленник

Классификация ddos атак

Следующие типы нападений могут быть предприняты злоумышленниками:

1. Перегрузка полосы пропускания . Чтобы компьютеры, подключенные к сети, могли нормально взаимодействовать между собой, канал связи, через которые они соединяются, должен нормально работать, и предоставлять достаточные параметры для конкретных задач (например, полоса пропускания). Данный тип атак, направлен именно на перегрузку сетевых каналов связи. Достигается это путем постоянной отправки бессвязной или системной информации (команда ping )
2. Ограничение ресурсов . Данный тип мы уже рассмотрели выше, в примере с доступом к веб-сайту. Как мы отметили - сервер имел возможность обрабатывать ограниченное количество одновременных подключений. Злоумышленнику необходимо направить на сервер большое количество одновременных подключений. В итоге сервер не справится с нагрузкой, и перестанет работать.
3. Нападение на DNS сервера . В этом случае DDOS атака призвана также прекратить доступ к веб-сайту. Другой вариант - перенаправить пользователя с правильного сайта на фальшивый. Это может быть сделано с целью похищения персональные данные. Достигается это путем атаки на DNS сервера, и подмены ip-адресов на фальшивые. Давайте разберем это на примере. Некий банк использует для расчета через интернет свой веб-сайт. Пользователю необходимо зайти на него, и ввести данные своей пластиковой карты. Злоумышленник с целью похищения этой информации создает однотипный сайт, и проводит атаку на DNS сервера (сервера имен). Целью данного мероприятия является перенаправления пользователя на сайт злоумышленника, когда тот попытается зайти на сайт банка. Если это удается, пользователь не подозревая угрозы, введет свои персональные данные на сайте злоумышленника, и он получит к ним доступ
4. Недоработки в программном обеспечении . Самым сложным является данный тип атак. Злоумышленники выявляют недоработки в программном обеспечении, и используют их с целью разрушения системы. Чтобы заказать такую ddos атаку, необходимо будет потратить немало средств

Как провести DDOS атаку своими руками

В качестве примера, мы решили показать вам, как можно осуществить DDOS атаку, с использованием специального программного обеспечения.

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

Нужно провести минимальные настройки:

1. В графе "URL" пишем адрес сайта, который мы хотим подвергнуть атаке
2. Затем нажимаем кнопку "Lock on" - Мы увидим целевого ресурса
3. Ставим метод TCP
4. Выбираем количество потоков (Threads)
5. Выставляем скорость отправки с помощью ползунка
6. Когда все настройки будут закончены, нажимаем кнопку "IMMA CHARGIN MAH LAZER"

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

Как защититься от DDOS атак

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

1. Настройка систем фильтрации - задача для системных администраторов и хостинг провайдеров
2. Приобретение систем защиты от DDOS атак (программные и аппаратные комплексы)
3. Использование Firewall и списков контроля доступа (ACL) - данная мера направлена на фильтрацию подозрительного трафика
4. Увеличение доступных ресурсов, и установка систем резервирования
5. Ответные технические и правовые меры. Вплоть до привлечения виновника к уголовной ответственности

Видео к статье :

Заключение

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

Постоянные читатели очень часто задавали вопрос, как можно редактировать текст, если файл имеет формат PDF. Ответ можно найти в материале -

Для защиты своих данных можно использовать целый комплекс мер. Одним из таких вариантов является

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

Зачем искать информацию на других сайтах, если все собрано у нас?

Как происходит DDoS-атака и какие ее виды существуют? Понимание проблемы это уже половина ее решения. Поэтому рассмотрим основные типы DDoS и с какой целью их осуществляют на сайты.

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

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

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

Первые DDoS-атаки появились в 1996 году. Правда, особое внимание такое явление привлекло к себе в 1999 году, когда из рабочего строя были выведены мировые гиганты – Amazon, Yahoo, CNN, eBay, E-Trade. А принимать срочные меры по решению проблемы стали только в 2000 году, когда вновь были совершены воздействия на сервера ключевых компаний.

Типы DDoS.

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

HTTP GET

• HTTP(S) GET-запрос - способ, запрашивающий данные на сервере. Этот запрос может “попросить” у сервера передать какой-то файл, изображение, страницу или скрипт, для отображения в веб-браузере.
• HTTP(S) GET-флуд - DDoS атака прикладного уровня (7) модели OSI. Злоумышленник посылает мощный поток запросов на сервер для переполнения его ресурсов. В этом случае сервер перестает отвечать на запросы реальных посетителей.

HTTP POST

• HTTP(S) POST-запрос - метод, суть которого лежит в том, что данные помещаются в тело запроса для последующей обработки на сервере. HTTP POST-запрос кодирует передаваемую информацию и помещает на форму, а затем отправляет этот контент на сервер. Этот метод используют, когда необходимо передавать большие объемы данных.
• HTTP(S) POST-флуд - тип DDoS-атаки, при котором количество POST-запросов переполняют сервер, в итоге он не может ответить на них. Это влечет за собой аварийную остановку сервера с вытекающими последствиями.

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

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

UDP флуд (или атака Fraggle) . По своему типу аналогичен ICMP флуду, правда в данном случае применяются UDP пакеты. Из-за насыщения полос пропускания происходит отказ в обслуживании сервера жертвы.

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

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

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

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

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

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

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

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

Использование специализированного программного и аппаратного обеспечение .

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

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

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

Устранение уязвимостей – тип защиты нацелен на устранение ошибок в системах или службах. К сожалению, такой способ защиты не работает против флуд-атак.

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

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

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

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

Только комплекс выше описанных мер поможет Вам защитить сайт от DDoS и уберечь свой сервис.

О DDoS-атаках. Базовые правила защиты ресурса в Сети, подробнее по .

9109 раз(а) 11 Сегодня просмотрено раз(а)

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

Памятный день

20 ноября 2013 года впервые за 8-летнюю историю нашей компании вся техническая площадка оказалась недоступна на несколько часов по причине беспрецедентной DDoS-атаки. Пострадали десятки тысяч наших клиентов по всей России и в СНГ, не говоря уже о нас самих и нашем интернете-провайдере. Последнее, что успел зафиксировать провайдер, прежде чем белый свет померк для всех - что его входные каналы забиты входящим трафиком наглухо. Чтобы представить это наглядно, вообразите себе вашу ванну с обычным сливом, в которую устремился Ниагарский водопад.

Даже вышестоящие в цепочке провайдеры ощутили отголоски этого цунами. Графики ниже наглядно иллюстрируют, что происходило в тот день с интернет-трафиком в Петербурге и в России. Обратите внимание на крутые пики в 15 и 18 часов, как раз в те моменты, когда мы фиксировали атаки. На эти внезапные плюс 500-700 Гб.

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

Миф номер один: «Объект атаки - всегда хостинг-провайдер. Это происки его конкурентов. Не моих.» На самом деле, наиболее вероятная мишень интернет-террористов - обычный клиентский сайт. То есть сайт одного из ваших соседей по хостингу. А может быть, и ваш.

Не все то DDoS…

После событий на нашей техплощадке 20 ноября 2013 и их частичного повторения 9 января 2014 некоторые пользователи стали предполагать DDoS в любом частном сбое работы собственного сайта: «Это DDoS!» и «У вас опять DDoS?»

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

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

А пока - ради точности словоупотребления - проясним термины.

О терминах

DoS-атака (от английского Denial of Service) - это атака, призванная добиться отказа сервера в обслуживании по причине его перегрузки.

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

Но в действительности мы практически не наблюдаем DoS-атак. Почему? Потому что объектами атак чаще всего выступают промышленные объекты (например, мощные производительные серверы хостинг-компаний). А чтобы причинить сколь-нибудь заметный вред работе такой машины, нужны гораздо бОльшие мощности, чем ее собственные. Это во-первых. А во-вторых, инициатора DoS-атаки достаточно легко вычислить.

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

Соучастники

Что за компьютеры включаются в ботнет?

Вы удивитесь, но зачастую это самые обычные домашние машины. Who knows?.. - вполне возможно, ваш домашний компьютер увлечен на сторону зла .

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

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

Это действительно происходит. Даже если вы об этом не думаете. Даже если вы страшно далеки от ИТ (особенно если вы далеки от ИТ!).

Занимательное хакерство или механика DDoS

Явление DDoS неоднородно. Это понятие объединяет множество вариантов действий, которые приводят к одному результату (отказу в обслуживании). Рассмотрим варианты неприятностей, которые могут преподнести нам DDoS’еры.

Перерасход вычислительных ресурсов сервера

Делается это путем отправки на определенный IP пакетов, обработка которых требует большого количества ресурсов. Например, для загрузки какой-то страницы требуется выполнить большое число SQL-запросов. Все атакующие будут запрашивать именно эту страницу, что вызовет перегрузку сервера и отказ в обслуживании для обычных, легитимных посетителей сайта.
Это атака уровня школьника, посвятившего пару вечеров чтению журнала «Хакер». Она не является проблемой. Один и тот же запрашиваемый URL вычисляется моментально, после чего обращение к нему блокируется на уровне вебсервера. И это только один из вариантов решения.

Перегрузка каналов связи до сервера (на выход)

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

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

Миф номер три: «А таки на мой хостинг просходят редко часто, и я их всегда замечаю.» На самом деле, 99,9% атак вы не видите и не ощущаете. Но ежедневная борьба с ними - это будничная, рутинная работа хостинговой компании. Такова наша реальность, в которой атака стоит дешево, конкуренция зашкаливает, а разборчивость в методах борьбы за место под солнцем демонстрируют далеко не все.

Перегрузка каналов связи до сервера (на вход)

Это уже задачка для тех, кто читал журнал «Хакер» больше, чем один день.

Фото с сайта радио «Эхо Москвы». Не нашли ничего более наглядного, чтобы представить DDoS c перегрузкой каналов на вход.
Чтобы забить канал входящим трафиком до отказа, нужно иметь ботнет, мощность которого позволяет генерировать нужное количество трафика. Но может быть, есть способ отдать мало трафика, а получить много?

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

Мы с вами знаем, что публичный DNS-сервер по запросу сообщает любому желающему данные о любом доменном имени. Например, мы спрашиваем такой сервер: расскажи мне о домене sprinthost.ru. И он, ничтоже сумняшеся, вываливает нам все, что знает.

Запрос к DNS-серверу - очень простая операция. Обратиться к нему почти ничего не стоит, запрос будет микроскопическим. Например, вот таким:

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

Но как сделать так, чтобы ответ направлялся на нужный IP? Как подделать IP источника запроса, чтобы DNS-сервер выдавал свои ответы в направлении жертвы, которая никаких данных не запрашивала?

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

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

Чего досер не может знать, так это емкости каналов атакуемого. И если он не рассчитает мощность своей атаки верно и не забьет канал до сервера сразу на 100%, атака может быть достаточно быстро и несложно отбита. С помощью утилит типа TCPdump легко выяснить, что входящий трафик прилетает от DNS, и на уровне Firewall запретить его принимать. Этот вариант - отказ принимать трафик от DNS - сопряжен с определенным неудобством для всех, однако и серверы, и сайты на них при этом будут продолжать успешно работать.

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

Если атака мощная

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

И вот тогда это становится глобальной проблемой для всех. И если вкратце, это то, с чем нам пришлось иметь дело 20 ноября 2013 года. А когда происходят масштабные потрясения, время включать особую магию!

Примерно так выглядит особая магия С помощью этой магии удается вычислить сервер, на который нацелен трафик, и заблокировать его IP на уровне интернет-провайдера. Так, чтобы он перестал принимать по своим каналам связи с внешним миром (аплинкам) какие-либо обращения к этому IP. Любителям терминов: эту процедуру специалисты называют «заблэкхолить» , от английского blackhole.

При этом атакованный сервер c 500-1500 аккаунтами остается без своего IP. Для него выделяется новая подсеть IP-адресов, по которым случайным образом равномерно распределяются клиентские аккаунты. Далее специалисты ждут повторения атаки. Она практически всегда повторяется.

А когда она повторяется, на атакуемом IP уже не 500-1000 аккаунтов, а какой-нибудь десяток-другой.

Круг подозреваемых сужается. Эти 10-20 аккаунтов снова разносятся по разным IP-адресам. И снова инженеры в засаде ждут повторения атаки. Снова и снова разносят оставшиеся под подозрением аккаунты по разным IP и так, постепенным приближением, вычисляют объект атаки. Все остальные аккаунты к этому моменту возвращаются к нормальной работе на прежнем IP.

Как понятно, это не моментальная процедура, она требует времени на реализацию.

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

Есть ли свет в конце тоннеля?

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

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

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

Правовая сторона вопроса

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

Миф номер шесть: « Теперь я знаю про DDoS достаточно, закажу-ка праздник для конкурента - и ничего мне за это не будет!» Не исключено, что будет. И если будет, то мало не покажется.

• Завязка истории с DDoS платежной системы Assist
• Волнующая развязка

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

PS: у нас не находится достаточно теплых слов, чтобы выразить всю нашу признательность, поэтому мы просто говорим «Спасибо!» нашим терпеливым клиентам, которые горячо поддержали нас в трудный день 20 ноября 2013 года. Вы сказали много ободряющих слов в нашу поддержку в