Главная › Тарифы › Как ддосить сервер Майнкрафт — эффективные способы. DOS и DDoS-атаки: понятие, разновидности, методы выявления и защиты

Как ддосить сервер Майнкрафт — эффективные способы. DOS и DDoS-атаки: понятие, разновидности, методы выявления и защиты

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

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

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

Одной из таких неприятностей может стать ddos атака!

В статье я хотел бы рассказать вам о следующем:

Что такое ddos атака?

DDoS-атака — это аббревиатура Distributed Denial Of Service Attack. Существует также DoS-атаки, отличающиеся от первого вида тем, что нападение происходит не с разных IP-адресов. Но сейчас обо всем по порядку.

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

А все почему? Потому что на тот момент никто не знал, как справиться с подобными атаками.

Итак, давайте подробнее разберем, как хакеры подвергали опасности хорошо защищенные веб узлы?

Все выглядит достаточно просто, но все же сделать это не так уж легко.

Схема DDoS-атаки построена вот так. Хакеры выбрали один сервер, на который сейчас совершат нападение. И разом обрушивают на него кучу ложных запросов, причем в се это делают со всех уголков мира, а значит с разных IP-адресов. В конце концов ресурс тратит все свои силы на обработку.

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

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

Dos-атака.

Теперь немного о Dos-атаки. Это немного иное, нежели чем ddos, однако также отказ в обслуживании ресурса будет вам обеспечен.

Суть её заключается в том, хакер используют уязвимость на компьютере, которая способствуют появлению ошибки. Она в свою очередь приостанавливает работу веб- ресурса.

Если уязвимость на ПК закинуть не получилось, то злоумышленник пользуется вторым вариантом, который немного схож с ddos атакой.

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

Виды ddos атак и как от них защититься?

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

Вот, что вам следует проделать, точнее операции необходимо выполнить:

Предотвращение.

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

Фильтрация.

Если вы заметили трафик от атакующих машин, то смело блокируйте его любыми методами. Например, воспользуйтесь плагин WordFence Security, позволяющий закрыть доступ IP-адресам, даже целых стран. Но с этим баловаться очень опасно, так и самим себя загубить можно. Короче, действуйте лишь тогда, когда уверены, что вы правы. Здесь нет такого выражения: «Риск благородное дело» или"Кто не рискует тот не пьет шампанского".

Обратный DDOS.

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

Устранение уязвимостей.

Уязвимость можно убрать при помощи Антивируса. Лично я использую Касперского, о его преимуществах и характеристиках можете ознакомиться в статье про

Рассредоточение.

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

Такой метод профилактики отлично подойдет для себ ресурсов корпораций, крупных компаний, фирм и т.д.

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

Уклонение.

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

Активные ответные меры.

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

С профилактическими мерами ознакомились. Теперь познакомлю вас с видами ddos-атак.

Виды ddos-атак.

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

памтHTTP-флуд.

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

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

Это самый опасный тип ddos-атаки. Все происходит вот так: системе отправляют поддельный пакет инфы с данными. Хакер изменяет свой адрес на адрес атакуемого объекта. Для более эффективного нападения используют «зомби-компьютеры». В начале статьи я об этом говорил. Допустим набрали 1000 IP-адресов и отправляют пакет инфы, но не просто так, а усилив 1 к комп в 1 к раз.Это значит направили на ресурс 1000 запросов, при этом увеличив их число в тысячу раз.

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

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

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

Как понять, что идет ddos атака на сайт?

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

Чтобы этого избежать надо заранее позаботиться об обнаружении ddos -атак на свой блог.

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

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

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

До свидания, уважаемые читатели!

С уважением, Жук Юрий.

Борьба с 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-атаки можно трактовать, исходя из расшифровки английского сокращения. Аббревиатура расшифровывается, как Distributed Denial of Service, то есть, грубо говоря, отказ в обслуживании или работоспособности.

Если разбираться в том, что такое DDoS-атака на сервер, в общем случае это нагрузка на ресурс посредством увеличенного количества пользовательских обращений (запросов) по определенному каналу связи, который, естественно, имеет ограничения по объему трафика, когда сервер просто не в состоянии их обработать. Из-за этого и происходит перегрузка. Фактически у программной и аппаратной части сервера банально не хватает вычислительных ресурсов, чтобы справиться со всем запросами.

Принципы организации атак

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

Как устроить DDoS-атаку самому именно на этом этапе? Совершенно просто. Для заражения компьютеров можно использовать так называемые снифферы. Достаточно прислать жертве письмо на электронный адрес с вложением (например, картинкой, содержащей исполняемый код), при открытии которой злоумышленник получает доступ к чужому компьютеру через его IP-адрес.

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

Виды DDoS-атак

ДДоС-атака в общем смысле называется так только условно. На самом деле существует как минимум четыре ее разновидности (хотя сегодня насчитывают целых 12 модификаций):

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

История появления

Впервые об атаках такого рода заговорили еще в 1996 году, однако тогда особо значения этому никто не придал. Серьезно проблему начали осуждать только в 1999 году, когда были атакованы крупнейшие мировые серверы вроде Amazon, Yahoo, E-Trade, eBay, CNN и др.

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

Самый известный случай DDoS-атаки

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

Первая организация без объяснения причин включила провайдера в список спамеров, несмотря на то, что его серверами пользовались многие уважаемые (и не очень) организации и службы. К тому же серверы провайдера, как ни странно это выглядит, были расположены в здании бывшего бункера НАТО.

В ответ на такие действия Cyberbunker начал атаку, которую на себя приняла CDN CloudFlare. Первый удар пришелся на 18 марта, на следующий день скорость обращений возросла до 90 Гбит/с, 21-го числа наступило затишье, но 22 марта скорость составила уже 120 Гбит/с. Вывести из строя CloudFlare не удалось, поэтому скорость была увеличена до 300 Гбит/с. На сегодняшний день это является рекордным показателем.

Что представляют собой программы для DDoS-атак?

В плане используемого ныне программного обеспечения наиболее часто используемым приложением считается программа LOIC, которая, правда, позволяет производить атаки только на серверы с уже известными IP- и URL-адресами. Что самое печальное, она выложена в интернете для свободного скачивания.

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

Как произвести атаку самостоятельно?

Итак, нужна DDoS-атака. Как сделать ее самостоятельно, сейчас кратко и рассмотрим. Предполагается, что сниффер сработал, и у вас есть доступ к чужому терминалу. При запуске исполняемого файла программы Loic.exe в окне просто вписываются нужные адреса и нажимается кнопка блокировки (Lock On).

После этого в регулировке скорости передачи по протоколам HTTP/UDF/TCP фейдером устанавливается максимальное значение (10 в минимуме по умолчанию), после чего используется кнопка IMMA CHARGIN MAH LAZER для старта атаки.

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

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

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

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

Что нужно знать еще?

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

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

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

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