ЗАЩИТА ОТ ДДОС АТАК своими руками. Лучшие методы. Защита от ddos атак сайта


Защита от DDoS-атак бесплатно: что может предложить рынок

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

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

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

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

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

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

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

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

Например, сервис бесплатной защиты DDoS-GUARD FREE включает в себя:

  • Защиту для 1 домена
  • Неограниченный объем/полосу легитимного трафика
  • Неограниченную полосу фильтрации
  • Поддержку SSL/TLS 1.2&1.3 шифрования
  • Бесплатный SSL-сертификат
  • Кэширование и доставку статического контента (CDN)
  • Поддержку HTTP/2 и SPDY

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

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

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

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

ddos-guard.net

Ddos атака в обход защиты. Методы защиты.

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

Давайте зарегистрируемся в таком сервисе и получим от него письмо о регистрации в почту. Откроем исходник письма и увидим:

Received: from mxfront8j.mail.yandex.net ([127.0.0.1])

by mxfront8j.mail.yandex.net with LMTP id c0MIOzBI

for < [email protected]>; Sun, 10 May 2015 15:58:47 +0300

Received: from srv1.example.com (srv1.example.com [xxx.xx.xx.xxx])

by mxfront8j.mail.yandex.net (nwsmtp/Yandex) with ESMTPS id FpRuMcFeJH-wksakWfe;

Sun, 10 May 2015 15:58:46 +0300

(using TLSv1 with cipher AES128-SHA (128/128 bits))

(Client certificate not present)

Received: from srv1.example.com (localhost [127.0.0.1])

by srv1.example.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id t4ACvd6T026304

for < [email protected]>; Sun, 10 May 2015 15:57:39 +0300

Received: (from [email protected])

by srv1.example.com (8.14.3/8.14.3/Submit) id t4ACvdQX026302;

Sun, 10 May 2015 15:57:39 +0300

Ну вот мы и нашли машину в подсети настоящего сервера в настоящем ДЦ, а не прокси. Вот она: srv1.example.com, xxx.xx.xx.xxx. С большой вероятностью эта машина находится в том же ДЦ и в той же подсети, что и www сервер. Обычно такие проекты не имеют больших сетей, не больше /24. Давайте просканим сетку и найдем все машины с открытым 80/tcp портом. Нуб отлично, есть список машин — зайдем на каждую браузером. На машине с адресом xxx.xx.xx.xxy с нами приключился редирект на www.example.com — это та самая машина, они отредиректила нас на проксю-защитника.

Теперь мы можем смело атаковать эту машину. Канал на машине вряд ли будет более 1GB, но есть материнки, где встроены сетевые карты сразу с 4-мя интерфейсами. Значит атака будет с запасом — 4GB. Мы не будем устраивать атаку на приложение, или атаку на nginx — можно просто залить канал трафиком. При том, то что мы зальем только входящее направление к серверу — не страшно. Запросы от пользователей — тоже входящее направление. Много ли это 4 GB для DDoS атаки? Давайте посчитаем. В Москве у многих людей дома хороший интернет — 40Мб минимум. 4 GB/40 MB = 100 машин. Это всего лишь 100 машин с ботом — такой ботнет можно организовать довольно быстро (если есть соответствующий навык), а для человека, постоянно занимающегося DDoS — это вообще не проблема. Современные ботнеты — это тысячи зараженных машин.

Как же защитится?

Простое решение — иметь почтовую машину вне ДЦ и вне боевой подсети, которая будет работать почтовым релеем и отрезать весь «Received», что у неё есть. Сделать это не сложно, в том же postfix есть опция content_filter, где можно указать SMTP-прокси для фильтрации контента. На любом языке можно легко и просто написать smtp-proxy, который отрежет всё лишнее в письме. Я готовых инструментов не знаю, если честно, но для меня задача написать smtp-proxy на python или ruby — задача на несколько часов.

Украсть DNS зону

Менее доступный, но тоже реальный способ. Утащив DNS-зону мы найдем в ней имена машин и IP адреса — обычно технические имена машин держат прямо в этой же зоне. Что-что вроде srv1.example.com IN A xxx.xx.xx.xxx. Защитится довольно просто — все технические DNS-ы, выносятся в отдельный поддомен и защищаются более тщательно. srv1.servers.example.com — как то так.

Непрямая атака

Не сложно сделать вывод, что сайт без статики — не работает. Обычно сервисы для защиты от DDoS берут деньги за трафик, поэтому статику с основного домена переносят на CDN. Завалить трафиком CDN — задача очень сложная, из-за его распределенности. Но можно посмотреть, что за статика есть еще на сайте. О! С левого сервиса показываются баннеры и он не сидит за проксей-защитником — это просто удача. Можно залить канал к баннерной системе: не загрузится js, не случится DOM Ready — если на сайте куча js — пользоваться им почти невозможно. Это не универсальный способ, но он может прокатить там, где сайт без js не работает в принципе. Защита от этого тоже максимально тупая — асинхронный js к баннерам. Не смог — ну и ладно.

Финансовая атака

Вот мы нашли на CDN интересный файлик: cdn-1.example.com/static/video/hardporn.flv. Весит он аж 140 MB. Мы-то помним, что прокси-защитники берут деньги за трафик. А откуда CDN возьмет этот файл? В простом случае с www.example.com/static/video/hardporn.flv. Проверим и убедимся, что он отдается. Ну и отлично. В простом случае нам нужен очень маленький ботнет, который просто будет пару дней скачивать этот файл — без особой нагрузки, не привлекая к себе внимания прокси-защитника. Конечно это будет превышение предоплаченного трафика и фирме-владельцу сайта придется очень печально.

Можно немного докрутить такую атаку — найти XSS и воткнуть туда html5 video с autoplay и display: none. Внешне ничего не меняется, но зато каждый пользователь тянет к себе большой трафик. Каждого пользователя, в отличие от ботнета, не отфильтруешь. Вообще финансовые атаки — наиболее опасные для бинзеса. Либо бизнес платит за огромный трафик, чтобы сайт работал (и тянул еще больший трафик), либо не платят и сервис ложится. Защита от такого проста до глупости — возвращайте 403 со статики всем, кроме CDN-ки.

Атака на мобильное API

Если сайт имеет еще и мобильное приложение — это сейчас модно, он значит современный сайт. Имея мобильное приложение, обычно сайт еще имеет и мобильное API. Установив себе приложение и собрав tcpdump-ом трафик (ну не сложно поднять wifi точка-точка на своем PC), можно найти api-mobile.example.com. Возможно из за желания экономить он тоже будет не за проксей-защитником, а прямо смотреть на сервер. Ну вот и спалился нужный нам IP. Защита, как вы уже поняли простая — трафик API должен идти через проксю-защитника.

Заключение

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

Защита от DDoS атак через сервисы-защитники — хороша, она оправдывает себя материально и технически. Осталась задача для админов сайта — да не спали свой IP!

ddos-defence.net

Как защитить сайт и веб сервер от ddos атаки

Некоторое время назад я написал подробную статью про установку и настройку web сервера на базе nginx и php-fpm последних версий. Там я упомянул, что это первая статья из цикла заметок о веб сервере. Сегодня я расскажу как простыми и подручными средствами защититься от простых ddos атак.

Введение

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

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

Я приведу советы по защите от простых атак ботов или каких-то мелких вредителей и пакостников, которые без должных действий с вашей стороны могут положить ваш сайт или сервер без особых проблем. Вот простой пример. Есть не очень слабый виртуальный сервер от keyweb, на бороту которого 2 ярда, 8 гигов оперативы и ssd диск.

Сервер настроен по моей предыдущей статье, ссылку на которую привел в начале. На сервере развернут wordpress сайт с некоторым содержимым. И есть у нас вредитель, который на своем сервере запускает простой тест от apache на производительность веб сервера:

# ab -c 50 -n 30000 "https://hl.zeroxzed.ru/"

Всего лишь 50 параллельных потоков. Что мы видим на своем веб сервере:

Нагрузка на сервер от ddos

Не очень приятная картина. Сервер загружен на 100%. И хотя он нормально обрабатывает запросы и в целом корректно работает. Даже не очень тормозит, но все равно это плохо. А если будет 3 сервера и по 100 потоков на каждом? Нет никаких проблем даже на тест взять у разных хостеров по виртуальной машине и запускать на них подобные штуки, имитируя ддос атаку.

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

Защита от ddos с помощью iptables

Для защиты от простейшей атаки мы будем использовать firewall — iptables, модуль ядра ipset для хранения больших списков ip и самописные скрипты. По фаерволу смотрите мою статью — настройка iptables. Здесь я не буду на этом останавливаться.

Вопрос настройки ipset я подробно рассматривал в своей статье по блокировке ботов по странам. Советую посмотреть материал, так как он напрямую связан с этой статьей и дополняет ее.

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

# netstat -ntu | awk '{print $5}' | grep -vE "(Address|servers|127.0.0.1)" | cut -d: -f1 | sort | uniq -c | sort -n| sed 's/^[ \t]*//'

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

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

Выявление активного бота

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

#!/bin/sh netstat -ntu | awk '{print $5}' | grep -vE "(Address|servers|127.0.0.1)" | cut -d: -f1 | sort | uniq -c | sort -n| sed 's/^[ \t]*//' | awk '{if ($1 > 50 ) print$2}' > /root/ddos/much_conn.txt sleep 3 list=$(cat /root/ddos/much_conn.txt) for ipnet in $list do ipset -A much_conn $ipnet done

В принципе, комментировать тут особо нечего. Берем список подключений, который только что вывели, в нем сравниваем первую колонку, если она больше 50, то результат второй колонки, где записан ip адрес, передаем в файл.

Далее читаем этот файл и добавляем все ip адреса из него в ipset список под названием much_conn. Предварительно его надо создать. Подробно об этом я рассказывал в статье, на которую привел ссылку выше, но повторю еще раз здесь:

# ipset -N much_conn iphash

Посмотреть содержимое списка можно командой:

# ipset -L much_conn

Теперь нужно добавить в iptables правило, по которому будут блокироваться все подключения из указанного списка ipset.

# iptables -A INPUT -m set --match-set much_conn src -j DROP

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

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

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

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

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

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

ipset -N much_conn iphash timeout 3600

В данном случае запись с забаненным ip в списке ipset будет храниться в течении 3600 секунд или 60 минут.

Нужно понимать, что в данном примере с 1 ip адресом использовать ipset нет никакого смысла, можно сразу банить средствами самого iptables. Ipset нужен только тогда, когда этот список хотя бы в сотни строк. Если там несколько десяткой адресов, хватит и одного iptables.

Анализ лог файла web сервера для защиты от ddos

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

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

access_log /web/sites/hl.zeroxzed.ru/log/access.log main;

Мы не будем каждый раз анализировать весь лог файл. Эта операция сама по себе будет сильно нагружать веб сервер. Возьмем последние 1000 строк из лог файла и посчитаем количество подключений с одного ip с типовым содержимым, например запрос главной страницы по протоколу http 1.0, «GET / HTTP/1.0». Если вы заметите другой постоянный признак ботнета, который вас атакует, используйте его. Это может быть один и тот же user agent или что-то еще. Допустим, если атакующий будет долбить в уязвимое место, то это будет адрес этой страницы.

# tail -1000 /web/sites/hl.zeroxzed.ru/log/ssl-access.log | egrep "GET / HTTP/1.0" | awk '{print $1}' | sort -n | uniq -c

Результатом этой команды будет примерно такой список.

Поиск ботов на основе лога вебсервера

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

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

#!/bin/sh tail -1000 /web/sites/hl.zeroxzed.ru/log/ssl-access.log | egrep "GET / HTTP/1.0" | awk '{print $1}' | sort -n | uniq -c | sort -n | tail -n100 | awk '{if ($1 > 50 ) print $2}' > /root/ddos/much_gets.txt sleep 3 list=$(cat /root/ddos/much_gets.txt) for ipnet in $list do ipset -A much_gets $ipnet done

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

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

Не забудьте создать отдельный список в ipset и добавить отдельное правило в ipables. Можно использовать уже существующий список и добавленное правило из предыдущего примера, но я рекомендую все разделять. Так удобнее для последующего анализа.

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

Баним ботов с неправильным referer

Есть категория простых ботов, которые подставляют в referrer либо мусор, либо кривые урлы без http или https в начале. Например вот такие:

194.67.215.242 - - [30/Nov/2017:20:48:08 +0300] "POST /index.php HTTP/1.1" 200 913 "g0dfw4p1.ru" "Mozilla/5.0 (Windows NT 6.0; rv:34.0) Gecko/20100101 Firefox/34.0" "-"

Корректное поле referer должно содержать либо http, либо https, либо быть пустым. Все, что иначе, можно смело блокировать или возвращать статус ошибки. Добавляем примерно такую конструкцию в конфигурацию виртуального хоста, в раздел server {}.

if ($http_referer !~* ^($|http://|https://) ) { return 403; }

После этого проверьте конфигурацию nginx и перечитайте ее.

# nginxt -t # nginx -s reload

Если вас достает какой-то бот с конкретным referer, можно забанить именно его. Для этого можно дополнить условие, или изменить. Например, вот так:

if ($http_referer = "https://bots.ru/dostanim_tebya.html") { return 403; }

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

Защита от ддос с помощью модулей nginx — limit_conn и limit_req

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

Смысл данных модулей в том, что один может ограничить одновременное количество разрешенных соединений с сайтом, а другой количество соединений в единицу времени.

Я ограничу в своем примере количество одновременных подключений к сайту с одного ip числом 50, а количество одновременных запросов к динамическому контенту не более 2-х в секунду. При этом будет разрешен всплеск (burst) запросов до 5-ти. Объясню, как понимать этот всплеск, так как сам не сразу понял, что конкретно он означает.

Если у нас идет превышение количества установленных запросов в секунду, то их выполнение задерживается, и они выстраиваются в очередь на исполнение с указанной скоростью. Размер этой очереди и равен значению всплеска. Все запросы, которым не хватит места в очереди, будут завершены с ошибкой.  То есть, если запросов будет 4 в секунду, то 2 выполнятся сразу и еще 2 встанут в очередь. А если будет 10, то 2 выполнятся сразу, 5 встанут в очередь на выполнение по 2 штуки в секунду, а остальные будут завершены с ошибкой.

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

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

http { ... limit_conn_zone $binary_remote_addr zone=perip:10m; limit_req_zone $binary_remote_addr zone=dynamic:10m rate=2r/s; ... server { ... limit_conn perip 50; ... location ~ \.php$ { ... limit_req zone=dynamic burst=5 nodelay; ... } } }

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

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

и запись в логе с ошибками:

2017/11/30 15:25:26 [error] 9773#9773: *51482 limiting requests, excess: 5.664 by zone "dynamic", client: 195.91.248.43, server: hl.zeroxzed.ru, request: "GET / HTTP/2.0", host: "hl.zeroxzed.ru", referrer: "https://hl.zeroxzed.ru/2013/03/15/featured-image-vertical/"

Лимит на количество подключений можете проверить той же утилитой ab, о которой я рассказал во введении.

017/11/30 15:38:56 [error] 9773#9773: *53938 limiting connections by zone "perip", client: 94.142.141.246, server: hl.zeroxzed.ru, request: "GET /wp-content/uploads/2013/03/the-dark-knight-rises.jpg HTTP/1.0", host: "hl.zeroxzed.ru"

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

При выставлении ограничений, не забудьте проконтролировать, не попадают ли в эти ограничения поисковые боты. По-умолчанию, они стараются не создавать повышенную нагрузку на сайт. При желании, роботу яндекса можно указать через robots.txt, с какой скоростью сканировать ваш сайт. А роботу гугла то же самое можно сделать через webmaster.

Заключение

Не понравилась статья и хочешь научить меня администрировать? Пожалуйста, я люблю учиться. Комментарии в твоем распоряжении. Расскажи, как сделать правильно!

Я рассмотрел наиболее простые способы для защиты web сервера от не менее простых ddos атак, которые больше похожи на баловство. Серьезная атака, которая просто зальет весь входящий канал сервера, даже не заметит наших защит. Но тем не менее, мне приходилось убеждаться в эффективности этих способов в отражении некоторых атак.

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

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

Суть защиты в том, что с помощью nginx выдаем пользователю определенную cookies, а потом редиректим на запрашиваемую страницу. Если бот не понимает кукисов или редиректов, то он отваливается. Нормальные пользователи ничего не замечают. Возможно позже я отдельно расскажу про этот способ и дополню статью. А пока все. Буду рад замечаниям по существу в статьях.

Помогла статья? Есть возможность отблагодарить автора

serveradmin.ru

Как защититься от DDoS-атак

Как предотвратить DDoS-атаку

Главная цель хакеров - это сделать атакуемый ресурс недоступным для пользователя. Для этого на него направляется огромное количество ложных запросов, которые сервер не в состоянии обработать, в результате ресурс "падает". Это можно сравнить с тем, как неподготовленному человеку под видом гантелей на привычные ему 3 кг внезапно дали такие же по виду, но по 9 кг каждая. Разумеется, он не справится. То же происходит с сайтом - и вместо привычной страницы пользователь видит "заглушку" с сообщением об ошибке.

Для генерации зловредного трафика, который по сути и является DDoS-атакой, чаще всего используется большое количество устройств, имеющих доступ к Интернет, зараженных специальным кодом. Эти устройства (ПК, смартфоны, "умные вещи", серверы) объединяются в ботнеты, которые посылают запросы на адрес жертвы. Иногда источником мусорного трафика могут быть соцсети, где размещена ссылка на сайт-жертву. Помимо прочего, в Интернете есть сервисы-стрессеры, с помощью которых любой желающий может устроить ddos-атаку.

               Как выглядит DDoS-атака на графике с интерфейса, через который проходит атакующий трафик

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

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

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

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

Скрипты и фаерволы

Допустим, что на условный сайт n.ru идет ддос-атака. По логам (истории) видно, что большое количество GET-запросов идет на главную страницу. В этом случае можно воспользоваться редиректом javascript, например:

<script type="text/javascript"> window.location = "n.ru/index.php" </script>

После этого легитимные пользователи, у которых не отключен javascript в браузере, перенаправляются на index.php.

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

Существует бесплатный скрипт DDoS Deflate - это своего рода сигнализация, которая использует команду «netstat» для обнаружения флуда (одного из видов DDoS), после чего блокирует подозрительные IP-адреса вредителей с помощью межсетевого экрана iptables (либо apf).

                                                                                  Как работает межсетовой экран

 Настройки параметров Apache

Чтобы предотвратить DDoS, можно еще изменить настройки параметров Apache:

  1. KeepAliveTimeout –  нужно снизить ее значение или полностью выключить эту директиву;
  2. TimeOut – установить как можно меньшее значение для данной директивы (веб-сервера, который подвержен DDoS-атаке).
  3. Директивы LimitRequestBody, LimitRequestFieldSize, LimitRequestFields, LimitRequestLine, LimitXMLRequestBody должны быть настроены на ограничение потребления ресурсов, вызванных запросами клиентов.

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

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

Способы защиты от DDoS-атак

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

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

Условно всё многообразие можно поделить на две большие группы: сервисы, которые подключаются удалённо, и "железные" решения, требующие установки оборудования на стороне клиента.

В первую группу входят следующие виды защиты от распределенных атак:

1. reverse proxy (обратное проксирование). Провайдер защиты выдает ресурсу, который надо защитить, новый IP-адрес - его необходимо внести в А-запись. После изменения А-записи входящий трафик будет идти сначала на очистку в сеть провайдера по новому IP-адресу, а после этого, уже очищенный, поступать на реальный адрес. При этом ресурс может оставаться на прежнем хостинге. Это самая доступная защита от DDoS: подходит сайтам различной посещаемости, подключение и настройка занимает не более 20 минут, требует минимальных знаний от вебмастера.

 

 

2. защищенный хостинг (или выделенный сервер). Такую услугу anti ddos предлагают хостеры, серверы которых уже подключены к системе защиты (это могут быть собственные фильтрующие станции либо услуга от компании-партнера). Это не менее популярная и выгодная защита от ddos атак, ее плюсы: один общий счёт за все услуги, все настройки выполняют специалисты хостинг-провайдера, перенос сайта с незащищенного стороннего хостинга осуществляется, зачастую, бесплатно. При создании нового сайта его можно сразу размещать на защищенном от ддос-атаки хостинге или выделенном сервере.

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

3. защищенный IP-транзит по виртуальному туннелю. Эта услуга подходит для проектов с большими объемами трафика, для защиты от мусорного трафика сразу всей автономной системы. Это дорогостоящая услуга, которой пользуются ЦОДы, хостинг-провайдеры, регистраторы доменных имен, операторы связи, которые не имеют собственных фильтрующих станций.

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

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

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

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

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

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

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

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

Кроме того, если Вы не имеете в штате подкованных опытных айтишников, которые сами всё настроят, то Вам понадобится помощь техподдержки. Большим плюсом будет, если саппорт компании, предоставляющей сервис по защите от DDoS, работает 24/7 и говорит на одном языке с заказчиком.

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

ddos-guard.net

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

echo $(($(fgrep -c "$(env LC_ALL=C date [email protected]$(($(date \ +%s)-60)) +%d/%b/%Y:%H:%M)" "$ACCESS_LOG")/60))

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

Тренды в DDoS

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

 

готовим ОС

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

15. Тюним ядро

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

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

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

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

Подробнее об установке параметров сетевого стека при наличии широкого канала можно прочитать здесь: http://bit.ly/8U0SDq.

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

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

 

Не бояться!

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

 

xakep.ru

Услуги « ДДОС ЗАЩИТА

Услуги

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

Компания «ДДОС ЗАЩИТА» предлагает защиту от любых известных типов распределённых атак на отказ в обслуживании http-серверов (канальный флуд — ICMP, UDP, TCP-SYN, etc., «интеллектуальный» http/https флуд). Атака обнаруживается нашей системой в автоматическом режиме, после чего происходит автоматическое переключение режимов фильтрации трафика в зависимости от характера и силы атаки. Мы готовы предложить различные вариации решений по предотвращению внешнего воздействия на клиентский сайт: выбор необходимого сценария зависит от конкретных нужд и требований заказчика.

Поддержка сотрудниками компании осуществляется посредством тикет-системы.

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

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

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

Обращаем ваше внимание, что стоимость услуг зависит от «полосы» белого трафика (bandwidth), сама атака, ее время и интенсивность — не учитываются. Это выгодно для клиента, поскольку легко запланировать месячный бюджет на защиту от Ddos-атак. Мы рады предоставить вам эту возможность.

Публичное предложение — Оферта

ddos-protection.ru

ЗАЩИТА ОТ ДДОС АТАК своими руками. Лучшие методы.

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

ЗАЩИТА ОТ ДДОС АТАК

Подготовка к защите от DDOS

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

1. Не использовать для защиты от ДДОС windows сервера.

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

2. Не использовать веб сервер APACHE

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

3. Отражаем ДДОС атаку

Собственно что предпринять, в случае если ваш сайт начали ДДоСить? Классическая техника самообороны — анализировать лог-файл HTTP-сервера, составить паттерн для grep (отлавливающий ддос ботов) и заблокировать всех, кто под него подпадет. Данная способ сработает… в случае если повезет. Ботнеты случаются 2-ух типов, оба небезопасны, но по-своему. Первый приходит на вебсайт мгновенно, второй — постепенно. 1-ый убивает все и незамедлительно, но несмотря на все вышесказанное в логах оставляет полный отпечаток своего присутствия, и в случае если вы их проgrepаете и забаните все IP, то вы — победили. 2 ботнет укладывает веб-сайт медленно, но банить для вас его будет необходимо, вполне вероятно, на протяжении дня и ночи. Всякому админу принципиально понять: в случае если главным инструментов будет grep, то нужно быть готовым потратить борьбе с атакой пару дней. Ниже идут рекомендации о том, куда возможно заблаговременно подсунуть соломки, дабы не больно было свалиться.

4. Используем модуль 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.

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

Кроме плюсов, у testcookie есть и дефекты:

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

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

5. Используем код 444

Целью атакующих не редко становится  ресурсоемкая часть веб-сайта. Примером может быть поисковый движек, который выполняет ресурсо-емкие  запросы к базе. И этим пользуются  ДДоСеры, зарядив сразу несколько десятков тысяч запросов к поисковому движку. Как построить защиту от DDoS в этом случае? Можно на время отключить поиск. Хотя клиенты и не смогут искать нужную информацию встроенными средствами, но весь основной сайт будет оставаться в работоспособном состоянии, пока вы не найдете корень всех проблем. Nginx поддерживает нестандартный код 444, который позволяет закрыть соединение и ничего не отдавать в ответ:

location /search { return 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

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 на регулярное выражение.

Продолжение следует..

Рейтинг материала

[Голосов: 1 Рейтинг: 5]

antiddos.biz