Что такое DDOS атака и Как её Сделать? Защита от DDoS: как своими силами отбить атаку – руководство

Здравствуйте, дорогие друзья и читатели — сайт!

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

Из-за их преступных действий доступ к ресурсу был закрыт.

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

Теперь, когда страсти немного утихли, давайте разберёмся, что такое DDOS атака.

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

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

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

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

Ну, ничего, мы и сами не лыком шиты.

Думаю, что у Вас уже назрел вопрос — «Как сделать DDOS атаку? ».

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

В своё время, всё теми же умными дядьками была создана лазерная пушка под кодовым названием – «LOIC ». С помощью этой программы для DDOS атак, разработчики проверяли на устойчивость серверное оборудование, подвергая его различным нагрузкам имитируя дос атаки.

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

Эта программа не засекречена и находится в общем доступе сети Интернет. Её скачать можно .

Пользоваться программой LOIC просто. Запускаем LOIC .exe и видим следующее окно:

В двух верхних строчках вписываете URL или IP адрес жертвы и нажимаете Lock on :

После этих действий, в большом окне с надписью NONE появится IP мишени:

В нижнем окне устанавливаем поток (TCP , HTTP или UDP ), количество запросов (по умолчанию стоит 10 ) и передвигаем ползунок скорости передачи:

Закончив настройки, жмём на большую кнопку – :

Это всё, дос атака началась. Остановить процесс можно нажав туже кнопку.

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

Но повторюсь, это неправомерные действия и при сговоре с группой лиц, вызов DDOS атаки уголовно наказуем. Данный материал, только для ознакомительных целей.

Запуск лазерной пушки LOIC:

Защита от DDOS атак.

На сегодняшний день 100% защиты от DDOS атак не существует. Конечно, различные компании за серьёзные деньги предлагают услуги по защите сайтов от дос атак, но всё относительно. Если Ваш ресурс подвергнется мощному натиску, в котором будет задействовано много участников и дос-ботов, то не одна система не устоит.

Поэтому, всё, что Вы можете, это отражать атаки и блокировать IP адреса источника доса.

Кстати, скоро будет объявлен новый конкурс! Не пропустите!

До следующих статей…

P. S.

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

Спасибо за понимание!

С уважением, Денис Черников!

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

Введение

Представьте себе, что сейчас на ваш WEB сервер одновременно подключатся 100 тысяч человек из Интернет и попытается загрузить его главную страницу. Хватит ли пропускной способности канала в Интернет? Как защититься от злонамеренной перегрузки ваших каналов связи?

Определения

В сети Интернет есть большое число зараженных компьютеров, которые выполняют удаленно команды, в том числе по команде могут подключаться и загружать любые страницы с любого WEB сервера. Такой управляемый компьютер называет ботом. Множество таких управляемых компьютеров называется бот сетью. Каждый такой компьютер в этой сети – зомби, который всегда готов выполнить команду своего повелителя. В составе такой бот сети может быть одновременно до нескольких сотен тысяч компьютеров.

Откуда берутся боты?

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

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

Пример 1. Самые большие бот сети

Обнаружена новая бот сеть под названием Kraken, включающая порядка 400 тысяч компьютеров. Размеры бот сети превосходят всемирно известную бот сеть Storm, размер которой около 100 тысяч компьютеров. Источник: компания Damballa на конференции RSA 7.04.2008

Спросите у самого себя: а какие у меня гарантии, что мой компьютер не входит в бот сеть? Дает ли такие гарантии установленный сигнатурный антивирус? Непохоже. По статистике 40% компьютеров входящих в бот сеть имеют антивирус, который не определяет, что компьютер заражен. Дает ли гарантии установленный поведенческий антивирус или система предотвращения атак? Возможно, но многие люди даже не знают что это такое. И, слово специально, уходя с работы никогда не выключают компьютер. Никто не застрахован от соучаствия в организации DDOS атак.

Для того, чтобы ваш компьютер стал участником DDoS атаки совершенно необязательно, чтобы на нем была уязвимость или установлен какой-то злонамеренный код. Код для атаки может быть у вашего соседа в сети или на популярном сайте в Интернете. Так Trojan-Downloader.JS.Agent вставляет вредоносный javascript во все соседние компьютеры при помощи атаки , пока они грузят странички в своим браузером из Интернет. Это может быть любой код, включая код для проведения DDoS атаки. Вот этот код в вашем браузере выполнит 10000 соединений с любым сайтом:

attack_host="www.{атакуемый сайт}.com" attack_port=80 path="index.html" for(i=1;i

attack_host = "www.{атакуемый сайт}.com"

attack_port = 80

path = "index.html"

for (i = 1 ; i

Если вы читаете какую-то страницу через WEB браузер, например страницу с этой статьей, и в ней будет внедрен этот javascript код, то вы становитесь соучастником DDoS атаки и 10000 раз нападете на выбранный автором скрипта сайт. А если эту статью прочтет 10000 человек, то на сайт уже будет осуществлено уже 100 000 000 (100 миллионов) соединений. Другой вариант, если один из пользователей вставит этот javascript в сайт, где контент сайта заполняется самими пользователями (форумы, блоги, социальные сети), то помогать в осуществлении атаки будет любой человек зашедший на сайт. Например, если это будут odnoklassniki.ru, где уже 20 миллионов пользователей, то теоретически можно осуществить атаку на сайт при помощи 200000000000 (200 миллиардов) соединений. и это не предел Так что вы уже представляете себе масштаб угрозы. Защищаться надо. Как владельцам сетевых ресурсов от атак, так и пользователям от того, чтобы не стать соучастниками атаки.

Пример 2: Как осуществить DoS атаку на WEB сервер при помощи двух отверток и браузера.

Запускаете Internet Explorer, вводите адрес необходимого сайта, одной отверткой фиксируете кнопку Ctrl, другой F5. Количество запросов в секунду, которые будет посылать ваш Internet Explorer может затруднить работу сайта и даже помешать другим людям посетить это же ресурс.

К DDoS атаке нужно готовиться

Интернет достаточно агрессивная среда, чтобы начинать в нем бизнес, не позаботившись о своей защите. Но многие компании живут в нем согласно поговорке: пока гром не грянет, мужик не перекрестится. DoS и DDoS атаки отличаются тем, что с ними невозможно бороться без предварительной подготовки. И вдобавок, и это еще хуже, с ними все равно сложно бороться, даже если вы подготовились заранее. Если сейчас страдают DNS и WEB сайты, то на подходе угроза таким все более популярным сервисам как VoIP и IPTV.

Пример 3: DDoS атака на правительственные сайты Эстонии

Атаки против эстонских правительственных сайтов начались после переноса властями статуи Бронзового солдата из центра Таллина на окраины. В результате многие правительственные сайты Эстонии перестали работать, а местная компьютерная группа быстрого реагирования была вынуждена закрыть доступ к сайтам из-за границы. Пик атак пришёлся на 8 и 9 мая 2007 года. По словам премьер-министра Эстонии, атаки представляли собой лавину запросов, иногда до 5 миллионов в секунду против обычной посещаемости 1-1,5 тыс. в день. В этой атаке обвинили Россию, тем более, что некоторые российские хакеры брали на себя ответственность за эти действия. Была ли действительно Россия источником атаки читайте в конце статьи.

К сожалению, многие сервера выставляются в Интернете даже без защиты межсетевым экраном, не говоря уже про более сложные системы защиты типа систем предотвращения атак. В итоге, в тот момент когда начинается атака, выясняется, что защищаться нечем и компании вынуждены тратить драгоценное (в момент атаки) время на простые вещи, такие как установка межсетевого экрана на сервер, установка системы предотвращения атак или переход к другому провайдеру. Но, поскольку DDoS атаки даже с установленными системами защиты сложно остановить, а в момент атаки у вас не будет времени на выбор верного способа защиты, то вы сможете положиться только на средства защиты своего провайдера. И, как правило, в том что DDoS атака провалилась – заслуга провайдера. Именно про правильный выбор провайдера и пойдет рассказ в этой статье. Для начала давайте посмотрим более подробно какими бывают атаки типа отказ в обслуживании.

Виды DoS атак

Существует несколько способов группирования DoS атак по типам. Одна из логичных категоризаций DoS атак находится тут http://www.niser.org.my/resources/dos_attack.pdf

Различают несколько видов DoS атак.

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

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

Еще одной разновидностью DDoS атак такого типа являются DRDoS атаки (Distributed Reflection DoS) , которые могут использовать как источник своей атаки любой сервер в Интернете. Идея DRDoS : любой сервер на пакет TCP c SYN флагом обязательно ответит пакетом TCP c флагами SYN+ACK . Если адресом источника в первом пакете поставить адрес жертвы, то сервер пошлет несколько TCP пакетов с флагами SYN+ACK по адресу жертвы, пока не поймет, что жертва соединения не хочет и соединения не будет. Если использовать для атаки много таких мощных серверов, отвечающих на ложные пакеты по ложному адресу, то жертва будет запружена потоком пакетов.

Пример 4: DDoS на Коммерсант

Генеральный директор издательского дома “Коммерсант” Демьян Кудрявцев заявил в интервью агентству “Интерфакс” 14 марта 2008 года, что финансовые потери компании, связанные с блокировкой сайта www.kommersant.ru в результате DDoS атак, исчисляются десятками или даже сотнями тысяч долларов.

Кудрявцев подчеркнул, что DDoS атаки на сайт “Коммерсанта” беспрецедентны для России: “Если известные атаки на сайты эстонского посольства, радиостанции “Эхо Москвы” представляли собой 200-300 мегабайт мусорного трафика в секунду, то вчера на наш сайт его уровень достиг 2 гигабайт в секунду “, – отметил он.

Источник: securitylab.ru

Атаки 1 и 2 типа встречаются достаточно части и для борьбы с ними администраторы уже давно эффективно используют как сетевые так и хостовые системы предотвращения атак (IPS). В этой статье мы будем говорить о защите от атак 3 типа, поскольку об этих методах защиты пока еще нет информации в русскоязычном Интернете. Атака третьего типа может быть обнаружена системой обнаружения или предотвращения атак, но заблокировать такую атаку на самом канале ни одна система защиты к сожалению будет неспособна. Канал во время атаки переполнен и в защите от атак должен принимать участие вышестоящий провайдер. IPS обычно не используются для защиты от таких атак, хотя сигнатуры для защиты SYN-Flood и UDP-Flood помогают уменьшить влияние этих атак, разгрузив атакованные сервера.

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

Защита от DDoS для корпоративной сети

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

Перенаправление DNS и использование прокси

Вы можете прописать в DNS IP адреса сети компании Допустим прописать, что ваш WEB сервер стоит на IP адресах Antiddos. В итоге атака будет направляться в их сеть, трафик DDoS будет отрезаться, а нужный трафик с вашего WEB сайта при помощи обратного прокси доставляться всем клиентам. Этот вариант очень подходит Интернет банкам, Интернет магазинам, онлайн-казино или электронным журналам. Вдобавок прокси позволяет кешировать данные.

BGP маршруты и GRE туннели

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

Прямое подключение к сайт

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

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

Сервис от Akamai

Большие компании, такие как IBM, Microsoft, Apple, Sony, AMD, BMW, Toyota, FedEx, NASA, NBA, MTV защищают свои WEB сайты от DDoS атак при помощи сервиса Akamai (www.akamai.com). Однако защита от DDoS, это лишь одна из возможностей сервиса Akamai. Этот сервис позволяет компаниям иметь зеркало своих сайтов в тысячах различных точек по всему земному шару, гарантируя 100% доступность в любое время. Обычно на зеркалах лежат мультимедийные данные, такие как видео, аудио и графика. Akamai использует математические алгоритмы для решения проблем с перегрузками возникающими на WEB серверах в глобальном масштабе. Эти алгоритмы были разработаны в Массачусетском технологическом институте (MIT). И именно благодаря им Akamai обеспечивает быструю и надежную передачу контента пользователям Интернет. Есть в судьбе компании и печальный факт: один из основателей Akamai Даниель Левин был убит при попытке остановить террористов в одном из самолетов захваченных 11 сентября 2001 года в США.

Пример 6.

Но даже Akamai однажды в 2004 году был выведен на час из строя. Говорят, что это была атака на DNS, но это тоже одна из темных историй. Подробнее тут www.washingtonpost.com/wp-dyn/articles/A44688-2004Jun15.html

Средства защиты от DDoS атак для провайдеров

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

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

Arbor (www.arbornetworks.com/en/threat-management-system.html)
Cisco (www.cisco.com/en/US/products/ps5888/index.html)
CloudShield (www.cloudshield.com/Products/cs2000.asp)
Narus (www.narus.com/products/index.html)

Компания Arbor собирает списки адресов бот сетей (http://atlas.arbor.net/summary/botnets), что используется в продуктах Arbor и ее партнеров. Такие списки адресов постоянно обновляются раз в 15 минут и, например, используются для обнаружения подключения защищаемых рабочих станций к бот сетям в продукте IBM Proventia Anomaly Detection System. В первом случае у провайдеров используется технология Peakflow SP, в другом в корпоративных сетях технология Peakflow X. Устройства производителей систем защиты от распределенных атак отличаются в первую очередь максимальными скоростями на которых они работают и числом одновременно защищаемых клиентов. Если у вас каналы передачи данных используют или планируют более одного 10Гбит соединения, то нужно уже задумываться какого производителя выбрать. Кроме того, производители отличаются различным дополнительным функционалом, временем требуемым на обнаружение атаки и включение защиты, производительностью и другими параметрами.

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

В случае, когда атака направлена не на сервер, а на переполнение канала, то боты подставляют в качестве адреса-источника любые адреса и трафик выглядит как поток каких-то данных со всех адресов Интернета на все адреса атакуемой сети. Это самый сложный вид атаки.

Пример 7: Атака на провайдера

30-31 мая 2007 года петербургский провайдер Infobox подвергся массированной DDoS-атаке – до 2 Гб в секунду. Атака велась с десятков тысяч адресов, расположенных по всему миру, в том числе из России, Кореи, ОАЭ, Китая. Атаке подвергались DNS сервера. В результате большая часть каналов оказалась перегружена. Cайт, размещенные у провайдера серверы и почтовые ящики были полностью или частично недоступны. Техподдержка сообщила: “Мы стараемся минимизировать ущерб, наносимый атакой, но это достаточно проблематично и может вызывать неудобства для части клиентов (блокировка доступа из сетей крупных провайдеров) “. По словам генерального директора “Инфобокса” Алексея Бахтиарова, атака велась с десятков тысяч адресов, расположенных по всему миру”.

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

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

DDoS или distributed denial-of-service (разделенный отказ в обслуживании) - это атака на определенный компьютер в сети, которая заставляет его путем перегрузки не отвечать на запросы других пользователей.

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

Если скорость поступления новых запросов превышает скорость обработки, то, со временем, очередь запросов будет настолько длинной, что фактически новые запросы уже не будут обрабатываться. Это и есть главный принцип ddos атаки. Раньше такие запросы отправлялись с одного IP адреса и это называлось атакой отказа в обслуживании - Dead-of-Service, по сути, это ответ на вопрос что такое dos. Но с такими атаками можно эффективно бороться, просто добавив ip адрес источника или нескольких в список блокировки, к тому же несколько устройство из-за ограничений пропускной способности сети не физически не может генерировать достаточное количество пакетов, чтобы перегрузить серьезный сервер.

Поэтому сейчас атаки выполняются сразу с миллионов устройств. К называнию было добавлено слово Distribed, распределенная, получилось - DDoS. По одному эти устройства ничего не значат, и возможно имеют подключение к интернету с не очень большой скоростью, но когда они начинают все одновременно отправлять запросы на один сервер, то могут достигнуть общей скорости до 10 Тб/с. А это уже достаточно серьезный показатель.

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

Виды DDoS атак

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

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

DoS атаки на интернет канал требуют намного больше ресурсов, но зато с ними намного сложнее справиться. Если проводить аналогию с osi, то это атаки на 3-4 уровень, именно на канал или протокол передачи данных. Дело в том, что у любого интернет-соединения есть свой лимит скорости, с которой по нему могут передаваться данные. Если данных будет очень много, то сетевое оборудование точно так же, как и программа, будет ставить их в очередь на передачу, и если количество данных и скорость их поступления будет очень сильно превышать скорость канала, то он будет перегружен. Скорость передачи данных в таких случаях может исчисляться в гигабайтах в секунду. Например, в случае с отключения от интернета небольшой страны Либерии, скорость передачи данных составила до 5 Тб/сек. Тем не менее 20-40 Гб/сек достаточно, чтобы перегрузить большинство сетевых инфраструктур.

Происхождение DDoS атак

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

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

В случае с военной стратегией мы можем очень просто думать о типах ресурсов, которые можно ограничить, для ограничения возможностей противника. Ограничение воды, еды и строительных материалов просто уничтожили бы противника. С компьютерами все по-другому тут есть различные сервисы, например, DNS, веб-сервер, сервера электронной почты. У всех них различная инфраструктура, но есть то, что их объединяет. Это сеть. Без сети вы не сможете получить доступ к удаленной службе.

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

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

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

Почему сайт попал под атаку? Сколько атака может продолжаться?

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

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

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

Отдельно следует рассматривать проекты, априори подверженные DDOS-атакам: сайты онлайн-игр (Lineage 2), инвест-проекты и так далее. Если ваш проект изначально в зоне повышенного риска, то подумать о защите от атак нужно заранее, еще до запуска.

С какой именно атакой вы столкнулись?

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

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

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

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

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

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

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

Хостер стандартно предлагает переход на VPS или выделенный сервер, где можно настроить фильтрацию проблемных запросов на уровне веб-сервера Nginx, либо блокировать ip-адреса бот-машин фаерволом (iptables, APF, ipfw). Cкрипты анализа логов веб-сервера можно запускать регулярно по cron, что позволяет обеспечить защиту от средних атак в автоматическом режиме.

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

Если хостер не готов помочь с защитой от атаки, или не может дать никаких гарантий того, что справится с атакой текущего уровня, то не спешите с переходом на сервер. Рассмотрите доступные средства внешней защиты. Например, сервис http://www.cloudflare.com , где даже бесплатный тарифный план может помочь отбить флуд и атаки среднего уровня. Настройка сводится всего лишь к регистрации на CloudFlare, и изменению DNS для домена вашего сайта. Аналогичные услуги можно получить в Highloadlab .

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