Что такое ддос атаки. DDoS-атака: что такое, как работает и можно ли защититься

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

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

Виды DoS-атак

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

Ошибка в программном коде , приводящая к обращению к неиспользуемому фрагменту адресного пространства, выполнению недопустимой инструкции или другой необрабатываемой исключительной ситуации, когда происходит аварийное завершение программы-сервера - серверной программы. Классическим примером является обращение по нулевому (англ. null ) адресу.
Недостаточная проверка данных пользователя , приводящая к бесконечному либо длительному циклу или повышенному длительному потреблению процессорных ресурсов (вплоть до исчерпания процессорных ресурсов) либо выделению большого объёма оперативной памяти (вплоть до исчерпания доступной памяти).
Флуд (англ. flood - «наводнение», «переполнение») - атака, связанная с большим количеством обычно бессмысленных или сформированных в неправильном формате запросов к компьютерной системе или сетевому оборудованию, имеющая своей целью или приведшая к отказу в работе системы из-за исчерпания системных ресурсов - процессора, памяти или каналов связи.
Атака второго рода - атака, которая стремится вызвать ложное срабатывание системы защиты и таким образом привести к недоступности ресурса.

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

Эксплуатация ошибок

Эксплойтом называют программу, фрагмент программного кода или последовательность программных команд, использующие уязвимости в программном обеспечении и применяемые для проведения атаки на киберсистему. Из эксплойтов, ведущих к DoS-атаке, но непригодных, например, для захвата контроля над «вражеской» системой, наиболее известны WinNuke и Ping of death (Пинг смерти).

Флуд

О флуде как нарушении сетевого этикета см. Флуд .

Флудом называют огромный поток бессмысленных запросов с разных компьютеров с целью занять «вражескую» систему (процессор, ОЗУ или канал связи) работой и этим временно вывести её из строя. Понятие «DDoS-атака» практически равносильно понятию «флуд», и в обиходе и тот и другой часто взаимозаменяемы («зафлудить сервер» = «заDDoS’ить сервер»).

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

Флуд канала связи и TCP-подсистемы

Любой компьютер, имеющий связь с внешним миром по протоколу TCP/IP , подвержен таким типам флуда:

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

Флуд прикладного уровня

Многие службы устроены так, что небольшим запросом можно вызвать большой расход вычислительных мощностей на сервере. В таком случае атакуется не канал связи или TCP-подсистема, а непосредственно служба (сервис) - флудом подобных «больных» запросов. Например, веб-серверы уязвимы для HTTP-флуда, - для выведения веб-сервера из строя может применяться как простейшее GET / , так и сложный запрос в базу данных наподобие GET /index.php?search=<случайная строка> .

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

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

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

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

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

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

Ниже приведён краткий перечень основных методов.

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

См. также

Примечания

Литература

Крис Касперски Компьютерные вирусы изнутри и снаружи. - Питер. - СПб. : Питер, 2006. - С. 527. - ISBN 5-469-00982-3
Stephen Northcutt, Mark Cooper, Matt Fearnow, Karen Frederik. Анализ типовых нарушений безопасности в сетях = Intrusion Signatures and Analysis. - New Riders Publishing (англ.) СПб.: Издательский дом «Вильямс» (русск.), 2001. - С. 464. - ISBN 5-8459-0225-8 (русск.), 0-7357-1063-5 (англ.)
Morris, R.T = A Weakness in the 4.2BSD Unix TCP/IP Software. - Computing Scienece Technical Report No.117. - AT&T Bell Laborotories, Feb 1985.
Bellovin, S. M. = Security Problems in the TCP/IP protocol Suite. - Computer Communication Review, Vol. 19, No.2. - AT&T Bell Laborotories, April 1989.
= daemon9 / route / infinity «IP-spooling Demystified: Trust Realationship Exploitation». - Phrack Magazine, Vol.7, Issue 48. - Guild Production, July 1996.
= daemon9 / route / infinity «Project Neptune». - Phrack Magazine, Vol.7, Issue 48. - Guild Production, July 1996.

Ссылки

DoS-атака в каталоге ссылок Open Directory Project (

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

Борьба с 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 неточны, а ростовчане иногда летают в Египет на отдых. Но если вам терять нечего, то следуйте инструкциям:

Подключите к nginx GeoIP-модуль (wiki.nginx.org/HttpGeoipModule).
Выведите информацию о геопривязке в access log.
Далее, модифицировав приведенный выше шелл-скрипт, про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 Задает тайм-аут при передаче ответа клиенту. Если по истечении этого времени клиент ничего не примет, соединение будет закрыто.

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

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

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

Непрерывно растет мощность атак сетевого и транспортного уровня. Потенциал среднестатистической атаки типа SYN-флуд достиг уже 10 миллионов пакетов в секунду.
Особым спросом в последнее время пользуются атаки на DNS. UDP-флуд валидными DNS-запросами со spoof’ленными IP-адресами источника - это одна из наиболее простых в реализации и сложных в плане противодействия атак. Многие крупные российские компании (в том числе хостинги) испытывали в последнее время проблемы в результате атак на их DNS-серверы. Чем дальше, тем таких атак будет больше, а их мощность будет расти.
Судя по внешним признакам, большинство ботнетов управляется не централизованно, а посредством пиринговой сети. Это дает злоумышленникам возможность синхронизировать действия ботнета во времени - если раньше управляющие команды распространялись по ботнету в 5 тысяч машин за десятки минут, то теперь счет идет на секунды, а ваш сайт может неожиданно испытать мгновенный стократный рост числа запросов.
Доля ботов, оснащенных полноценным браузерным движком с 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 атак в KALI вы можете выполнив команду:

kali > / usr / share / exploitdb / platforms / windows / dos

Данная команда показывает базу данных эксплоитов для атаки Windows систем.

Для просмотра доступных инструментов ДДОС атаки Linux вводим команду:

/ usr / share / exploitdb / platforms / Linux / dos .

2. LOIC

The Low Orbit Ion Cannon (LOIC) Низко орбитальная ионная пушка. Возможно самая популярная DDOS программа. Она может рассылать массовые запросы по протоколам ICMP, UDP тем самым забивая канал к серверу жертвы. Самая известная атака с помощью LOIC была совершена группой Anonymous в 2009 году и направлена против PayPal, Visa, MasterCard в отместку за отключение WikiLeaks от системы сбора пожертвований.

Атаки, организованые с помощью LOIC могут утилизироваться с помощью блокировки UDP и ICMP пакетов на сетевом оборудовании интернет провайдеров. Вы можете скачать саму программу LOIC бесплатно на сайте . Этот инструмент на базе Windows и работа с ним очень проста, указываете сайты жертвы и нажимаете всего одну кнопку.

2. HOIC

HOIC был разработан в ходе операции Payback by Praetox той же командой что создала LOIC. Ключевое отличие в том, что HOIC использует HTTP протокол и с его помощью посылает поток рандомизированных HTTP GET и POST запросов. Он способен одновременно вести атаку на 256 доменов. Вы можете скачать его с .

3. XOIC

XOIC еще один очень простой DDOS инструмент. Пользователю необходимо просто установить IP адрес жертвы, выбрать протокол (HTTP, UDP, ICMP, or TCP), и нажать на спусковой крючек! Скачать его можно с

5. HULK

6. UDP Flooder

UDP Flooder соотвествует своему названию - инструмент прендназначен для отсылки множества UDP пакетов к цели. UDP Flooder часто используется при DDOS атаках на игровые сервера, для отключения игроков от сервера. Для скачивания программа доступна на .

7. RUDY

8. ToR’s Hammer

ToR’s Hammer был создан для работы через сеть, с целью достижения большой анонимности атакующего . Проблема же данного инструмена в том, что сеть TOR является достаточно медленной и тем самым снижает эфективность ДДОС атаки. Скачать эту DDOS программу вы можете с сайтов Packet Storm или .

9. Pyloris

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

10. OWASP Switchblade

Open Web Application Security Project (OWASP) и ProactiveRISK разработали инсрумент Switchblade DoS tool для тестирования WEB приложений на устойчивость к ДДОС атакам.Он имеет три режима работы: 1. SSL Half-Open, 2. HTTP Post, и 3. Slowloris. Скачать для ознакомления можно с сайта OWASP .

11. DAVOSET

12. GoldenEye HTTP DoS Tool

13. THC-SSL-DOS

Эта программа для ДДОС (идет в поставке Kali) и отличается от большинства DDOS инструментов тем, что она не использует пропускную способность интернет канала и может быть использована с одного компьютера. THC-SSL-DOS использует уязвимость SSL протокола и способна “положить” целевой сервер. Если конечно эта уязвимость на нем имеется. Скачать программу можно с сайта THC , либо использовать KALI Linux где этот инструмент уже установлен.

14. DDOSIM – Layer 7 DDoS эмулятор

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

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

Причины DDoS-атак

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

Эта причина встречается довольно часто. Некоторое время назад независимый журналист-исследователь Брайан Кребс раскрыл деятельность крупнейшего сервиса по осуществлению заказных DDoS-атак — vDOS. Информация была представлена в полных подробностях, что вызвало арест организаторов данного сервиса. В ответ хакеры организовали атаку на блог журналиста, мощность которой достигла 1 Тбит/с. Эта атака стала самой мощной в мире за все годы.

Развлечение

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

Политический протест (хактивизм)

Одной из первых атак, имеющих социальную почву является DDoS-атака, реализованная в 1996 году хакером Omega. Omega являлся членом хакерской коалиции "Cult of the Dead Crew" (cDc). Термин хактивизм стал популярным в СМИ в связи с участившимися кибератаками, имеющим социальную почву. Типичными представителями хактивистов являются группы Anonymous и LulzSec.

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

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

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

В этом случае злоумышленник требует с потенциальной жертвы денежную сумму за несовершение атаки. Либо за её прекращение. Часто жертвами таких атак становятся крупные организации, например в течение 2014 были атакованы банк "Тинькофф" и IT-ресурс Хабрахабр, крупнейший торрент-трекер Rutracker.org (как это было?).

Последствия DDoS-атак

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

Атаки, вошедшие в историю Интернет

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

Пинг смерти (Ping Of Dead). Способ атаки, базирующийся на использовании команды ping. Эта атака получила популярность в 1990-х годах, благодаря несовершенству сетевого оборудования. Суть атаки заключается в отправке на сетевой узел одного запроса ping, при этом в тело пакета включаются не стандартные 64 байта данных, а 65535 байт. При получении такого пакета у оборудования переполнялся сетевой стэк и что вызывало отказ в обслуживании.

Атака, повлиявшая на стабильность работы Интернет. В 2013 году компания Spamhaus стала жертвой атаки мощностью более 280 Гбит/с. Самое интересное то, что для атаки хакеры использовали DNS-сервера из сети интернет, которые в свою очередь были очень загружены большим количеством запросов. В те сутки миллионы пользователей жаловались на медленно загружающиеся страницы в связи с перегруженности службы .

Рекордная атака с трафиком более 1 Тбит/с. В 2016 году хакеры пытались атаковать нас пакетной атакой со скоростью 360 Mpps и 1 Тбит/с. Эта цифра стала рекордной за время существования Интернет. Но и под такой атакой мы устояли и нагрузка на сеть лишь незначительно ограничила свободные ресурсы сетевого оборудования.

Характеристика атак сегодня

Исключая пиковые атаки можно сказать, что мощность атак с каждым годом растет более, чем в 3-4 раза. География атакующих от года к году изменяется лишь частично, ведь это обусловлено максимальным количеством компьютеров в определенной стране. Как видно из квартального отчета за 2016 год, подготовленного нашими специалистами, странами-рекордсменами по количеству ботов выступают Россия, США и Китай.

Какие бывают DDoS-атаки?

На данный момент типы атак можно разделить на 3 класса:

Атаки, направленные на переполнение канала

К этому типу атак можно отнести , и ;

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

Наиболее популярными и интересными атаками этого типа являются , / атака,

Почему стоит выбрать именно нас? Наше оборудование расположено в ключевых дата-центрах мира и способно отражать атаки до 300 Гбит/с или 360 миллионов пакетов в секунду. Также у нас организована сеть доставки контента () и имеется штат дежурных инженеров на случай нестандартной атаки или нештатных ситуаций. Поэтому, встав под защиту к нам, Вы можете быть уверены в доступности своего ресурса 24/7. Нам доверяют: REG.RU, Аргументы и Факты, WebMoney, российский радиохолдинг ГПМ и другие корпорации.

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