MKB phpBB

Источники:
https://habrahabr.ru/post/204508/
https://habrahabr.ru/post/84172/
https://habrahabr.ru/post/83202/

В трёх томах:
1. Блокирование DNS DDoS при помощи пакета fail2ban
2. Оптимальная защита от DDoS с помощью netstat и iptables
3. Простой и эффективный метод отразить http DDoS от 50мбит с помощью nginx и iptables

Блокирование DNS DDoS при помощи пакета fail2ban
Вы уже устали от кучи сообщений от logcheck'а об откаpе в обслуживании запросов к named? Ниже будет написано как ограничить себя от DDoS к named'у при помощи пакета fail2ban.

События о которых идёт речь выглядят так:

System Events
=-=-=-=-=-=-=
Jan 21 06:02:13 www named[32410]: client 66.230.128.15#15333: query (cache) +'./NS/IN' denied

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

Устали от того, что ваш DNS сервер используется в качестве оружия в чужих DDoS-атаках? Попробуйте установить себе пакет fail2ban (Debian GNU/Linux). Оригинальный сайт проекта http://www.fail2ban.org.

Сначала установим себе пакет fail2ban. По умолчанию будут отслеживаться и блокироваться только атаки на службу ssh. Это неплохая идея. В пакете fail2ban могут контролироваться и другие службы, более того можно самостоятельно написать обработчики и фильтры к нему, но обсуждение этих вопросов выходит за рамки данной статьи.
aptitude install fail2ban

После того как пакет будет установлен проверяем содержимое файла /etc/fail2ban/jail.conf.
В конце файла находим описание которое надо произвести в настройках сервера named чтобы fail2ban смог нормально обрабатывать события для службы DNS.

Для начала создадим каталог в котором будет сохраняться журнал работы DNS-сервера:
mkdir /var/log/named
chown bind.bind /var/log/named
chmod 750 /var/log/named

После этого отредактируем /etc/bind/named.conf.local (У вас он может находиться в другом месте. Указанное имя актуально для пакета bind9 в Debian) добавив следующие строки:

logging {
    channel security_file {
        file "/var/log/named/security.log" versions 3 size 30m;
        severity dynamic;
        print-time yes;
    };
    category security {
        security_file;
    };
};

Перестартовываем Bind:
/etc/init.d/bind9 restart

Убеждаемся в том, что создаётся и заполняется журнал /var/log/named/security.log:

21-Jan-2010 07:19:54.835 client 66.230.160.1#28310: query (cache) './NS/IN' denied

Отлично, теперь внесём изменения в наструйку fail2ban. Открываем на редактирование /etc/fail2ban/jail.conf и вносим следующие изменения:

[named-refused-udp]

enabled  = false

заменяем на

[named-refused-udp]

enabled  = true

а также:

[named-refused-tcp]

enabled  = false

на

[named-refused-tcp]

enabled  = true

Перестартовываем fail2ban:
/etc/init.d/fail2ban restart

Убеждаемся, что fail2ban создаёт свой журнал /var/log/fail2ban.log, он будет содержать что-то вроде:

2010-01-21 07:34:32,800 fail2ban.actions: WARNING [named-refused-udp] Ban 76.9.16.171
2010-01-21 07:34:32,902 fail2ban.actions: WARNING [named-refused-tcp] Ban 76.9.16.171

Убеждаемся так-же в том, что fail2ban внёс соответствующие изменения в iptables:
$ sudo iptables-save | grep fail2ban

Теперь можно проверить насколько актуально и своевременно fail2ban ограничивает доступ:
tail -f /var/log/named/security.log

Теперь DNS сообщения об ошибках будут находиться в нескольких минутах друг от друга, а не в секундах.

Теперь о некоторых доработках напильником.
Скажем сервису logcheck смотреть в новое место для нахождения сообщений об ошибках. Правим файл /etc/logcheck/logcheck.logfiles добавив в конец файла строку:

/var/log/named/security.log

Убеждаемся, что мы теперь получаем сообщения от fail2ban по e-mail'у.
Хорошей идеей будет исследование опций в секции [DEFAULT] сервиса fail2ban в файле /etc/fail2ban/jail.conf. Возможно вы также захотите включить контроль других служб, кроме named. Может быть имеет смысл внести изменения в правила для игнорирования сетей из RFC1918 (смотрим в сторону опции ignoreip).
Также можно подумать об изменении bantime = 600 на более длительный срок.
Можно попробовать написать самостоятельно свои фильтры для fail2ban если вы в достаточной степени владеете магией составления регулярных выражений
Короче дерзаем и исследуем

ps: Да, ещё, это всего лишь вольный перевод "Blocking a DNS DDOS using the fail2ban package" с некоторыми дополнениями из практики

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

Перекопав полчища статей и опробовав множество вариантов, так и не нашел, что помогло бы с защитой. Взяв за основу статьи "Простой и эффективный метод отразить http DDoS от 50мбит с помощью nginx и iptables" и (D)DoS Deflate решил написать свой скрипт. Ну вернее не решил, а методом тыка и исправлений он получился сам.

Должен заметить, что статья от Алексея Кузьмина не идеальна, т.к. в логах nginx`a не достаточно копаться, да и обработка логов может потребовать много ресурсов. А именно в моем случае создавались логи более 50 Гиг, плюс запросы шли не «GET / HTTP/1.1», а «GET / HTTP/1.0», плюс, как оказалось, мой сервер сам от себя получал редиректы (127.0.0.1), которые не отображались в логах, которые отображались в запросе
netstat -ntu | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -n

Суть скрипта такова, что через определенное время кроном запускается скрипт и проверяет все соединения с сервером, ip и кол-во их соединений которые записываются в файл. Потом запускается другой скрипт, который смотрит, если соединения, превышают заданное число (у меня стоит 20), то создается скрипт с блокировкой этих айпишников через iptables.

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

Теперь к практике:
создаем каталог, где будет скрипт
mkdir /usr/local/ddos

в нем создаем файл ddos.sh и меняем его права:
chmod 0755 /usr/local/ddos/ddos.sh

записываем в него:

#!/bin/sh

# находим все соединения и записываем их во временный файл ddos.iplist в каталоге tmp
netstat -ntu | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -n > /tmp/ddos.iplist

# очищаем скрипт бана айпишников
cat /dev/null > /tmp/iptables_ban.sh

# создаем DROP правила для 50 самых агрессивных ботов
awk '{if ($1 > 20) {print "/sbin/iptables -I INPUT -p tcp --dport 80 -s " $2 " -j DROP" }}' /tmp/ddos.iplist >> /tmp/iptables_ban.sh

# следующая строка нужна только для того, чтобы создавался файл с просмотром всех правил iptables
echo "/sbin/iptables -L INPUT -v -n > /tmp/iptables.log" >> /tmp/iptables_ban.sh

# запускаем скрипт бана айпишников
bash /tmp/iptables_ban.sh

# делаем ротацию лога
cat /dev/null > /var/log/ddos/error.log
[ ! -f /var/run/nginx.pid ] || kill -USR1 `cat /var/run/nginx.pid`

Вот в принципе и все. Теперь запускаем кронтаб, предпочитаю команду:
EDITOR=mcedit crontab -e

ну или просто
crontab -e

и добавляем новую задачу в него, выполняющуюся каждые 10 минут:

*/10 * * * * /bin/sh /usr/local/ddos/ddos.sh

Также я изменил ротацию логов в файле /etc/logrotate.d/nginx от nginx`a, чтобы многогиговые файлы не создавались

/var/log/nginx/*.log {
	daily
	size 20M
	missingok
	rotate 150
	compress
	delaycompress
	notifempty
	create 640 root adm
	sharedscripts
	postrotate
		[ ! -f /var/run/nginx.pid ] || kill -USR1 `cat /var/run/nginx.pid`
	endscript
}

и записал еще задачу в крон, выполняющуюся каждый час

0 * * * * /usr/sbin/logrotate /etc/logrotate.conf

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

0 4 * * * /sbin/reboot

общий список заданий, выведенный через crontab -l:

*/10 * * * * /bin/sh /usr/local/ddos/ddos.sh
0 * * * * /usr/sbin/logrotate /etc/logrotate.conf
0 4 * * * /sbin/reboot

я записывал все под пользователем root, поэтому если вы не под этим пользователем, перед каждой командой стоит добавить root, типа:

*/10 * * * * root /bin/sh /usr/local/ddos/ddos.sh

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

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

>>xandr0s
будет 100К и Линукс устанет считать. Фряха не против, линуксу эта нагрузка в часы пик может боком выйти. Пользуйте ss вместо netstat. Считаю им коннекты для заббикса раз в 30сек практически без оверхеда

>> EGDFree
Я извиняюсь, но зачем «awk '{print $5}' | cut -d: -f1», если можно обойтись одним awk или двумя cut?
netstat -ntu | awk '{split($5, a, ":"); print a[2];}'

>>FeaMor
SniFFeR:
netstat -ntu | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -n | grep -v "Ваш IP сервера" > /tmp/ddos.iplist
— с помощью данной команды можно исключить из проверки на количество подключение IP адрес самого сервера

Простой и эффективный метод отразить http DDoS от 50мбит с помощью nginx и iptables
Предлагаю простой и в то же время эффективный метод борьбы с http DDoS. На основе сервера Xeon 2.5GHz / 4Gb RAM / SAS можно отражать атаку примерно до 300 Мбит/с (значение получено методом экстраполяции).

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

Область применения
Борьба с Http DDoS на выделенном сервере или ВПС. Максимальная возможная мощность сдерживания DDoS атаки ограничивается физическими возможностями сервера и пропускной способностью канала.

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

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

Описание метода
Я буду рассказывать о применение метода и достигнутых результатах, на основе реального случай борьбы с http DDoS атакой.

В моем распоряжении было два сервера Xeon 2.5GHz / 4Gb RAM / SAS, первый под PHP, второй под БД. Все настройки производились на первом сервере.ОС – Debian 4, сайт был с посещаемостью ~ 60к. Фронтендом являлся nginx. Ядро системы было настроено по умолчанию. Стандартное средство бана по ip – iptables в конкретном случае справилось с атакой ботнета размером до 7К.
В случае более мощной атаки придется установить ipset.

История борьбы с DDoS
День первый. Переполнение сетевого стека
IP адрес выделенный под ДОСом перестанет отвечать на какие-либо запросы (ping,http,ssh), при том что остальные IP сервера продолжат исправно работать. Если у сервера несколько IP то сайт под ДОСом ляжет, работа других сайтов на сервере и ssh нарушена не будет.
По умолчанию ОС Debian и другие ОС не в состоянии поддерживать огромное количество соединений создаваемое ботнетом. Необходимо внести изменения в настройки ядра, чтобы укрепить стек TCP/IP. Я не буду подробно останавливается на настройке ядра, приведу лишь пример такой конфигурации.

net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.eth0.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.core.rmem_max = 996777216
net.core.wmem_max = 996777216
net.ipv4.tcp_rmem = 4096 87380 4194304
net.ipv4.tcp_mem= 786432 1048576 996777216
net.ipv4.tcp_wmem = 4096 87380 4194304
net.ipv4.tcp_max_orphans = 2255360
net.core.netdev_max_backlog = 10000
net.ipv4.tcp_fin_timeout = 10
net.ipv4.tcp_keepalive_intvl = 15
net.ipv4.tcp_max_syn_backlog = 2048
net.ipv4.tcp_synack_retries = 1
kernel.msgmnb = 65536
kernel.msgmax = 65536
kernel.shmmax = 494967295
kernel.shmall = 268435456
net.core.somaxconn= 16096

против массовых запросов SYN по идее должны помогать syn cookies.

# Uncomment the next line to enable TCP/IP SYN cookies
# See http://lwn.net/Articles/277146/
# Note: This may impact IPv6 TCP sessions too
net.ipv4.tcp_syncookies=1

Подобнее о параметрах можно прочитать в документации, например http://debian.telenet.ru/doc/sysctl.conf, а лучше поиск через google.com свежих статей по данной теме.
Аккуратно меняем конфигурацию ядра и перезагружаем сервер…
И так. Наша система способна выдержать натиск ботов. Но праздновать победу еще очень рано. Из-за огромного количества соединений процессы PHP и БД полностью «съедают» ресурсы памяти и процессора, так что значение load average превышает 100 пунктов.
Необходимо отсечь паразитные соединения

Недостатки поиска ботов командой netstat
Анти-дос администратор, к которому я обратился с проблемой, предложил метод поиска ботов командой netstat. В процессе применения данного метода я заметил несколько существенных недостатков. Рассмотрим их подробно:
1. Создание blacklist-а занимает много времени, что не позволяет нам часто обновлять blacklist
2. Эффективный поиск ботов возможен только при остановленном вебсервере. В это время сайт не доступен для клиентов и появляется угроза неправильной индексации сайта поисковыми системами
3. В blacklist могут попасть IP поисковых роботов, что недопустимо

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

День второй. Возможности железа сервера + nginx
Сервер Xeon 2.5GHz / 4Gb RAM / SAS DoS-ят запросами GET / HTTP/1.1.
Эксперимент А. Веб сервер (в данном случае nginx) остановлен
Входящий трафик 6085.2 kbits/sec
Исходящий трафик 5342.1 kbits/sec
Эксперимент Б. Nginx отдает пустой HTML (return 444;)
Входящий трафик 56 Мбит/с
Исходящий трафик 54 Мбит/с
Эксперимент В. Nginx отдает HTML размером около 2 Кб – это страничка с небольшим сообщением вроде «приносим свои извинения за перебои в работе сайта»
Входящий трафик 57 Мбит/с
Исходящий трафик 353 Мбит/с
<… >*

На основе эксперимента можно сделать следующие выводы:

1. ) Можно полностью отказаться от фильтрации при наличии достаточной емкости канала и отсутствием соотношений входящий/исходящий трафик.
   Ваш сайт будет доступен клиентам ценой огромного паразитного трафика.
   Легкомысленное решение полностью отказаться от фильтрации. Злоумышленники могу увеличить мощность DoS так что «ляжет» гигабитный канал.

2. ) Когда мы забаним абсолютно всех ботов то паразитный трафик от ботнета составит всего лишь 5 Мбит/с. Забанить всех ботов также невозможно, на это потребуется слишком много ресурсов. Кроме того, высока вероятность бана поисковых роботов.
   Также необходимо обратить внимание на то, что исходящий трафик с последнем случаем превысил 100 Мбит/с. Значит, сервер подключенный к порту 100 Мбит/с станет очень трудно доступен по ssh в силу полной загруженности канала. Во избежание подобной неприятности, я рекомендую настроить отдачу пустого HTML или return 444 в nginx до завершения настройки фильтрации ботов.

Поиск ботов средствами nginx
В данном случае сервер атакуют запросами request: «GET / HTTP/1.1».
Делаем предположение о том, что хорошие клиенты делают не более 2х одновременных запросов к главной странице сайта. Считаем клиентов открывших более 3х одновременных соединений атакующими ботами и баним их IP адресы на фаерволе.

Предположение было подтверждено экспериментально. На основе анализа лога http запросов за сутки из 120 000 IP адресов, только с 19ти IP было сделано более 2х одновременных запросов.

Для реализации поиска ботов создаем специальную обработку запросов
request: «GET / HTTP/1.1» в nginx.

error_log /var/log/nginx/error.log;
<…>
location =/ {
limit_conn one 3;
root /home/www/site.ru;
}

IP адреса с которых было открыто более 3х одновременных подключений буду записаны в error.log с сообщением limiting connections by zone. На основе лога ошибок мы сможем построить blacklist ip атакующего ботнета.

Фильтрация ботов в iptables
Важно заметить. IPtables не пригодны для фильтрации большого количества адресов. При количестве цепочек >2К iptables процесс ksoftirqd начинает потреблять 100% CPU, что приводит к запредельной загрузке сервера. Проблема решается установкой ipset или уменьшением количество правил в iptables.
В данном случае установка ipset была отложена на случай крайней необходимости. У сервера не было встроенного KVM и пересобрать ядро было рискованно.

Приступим к созданию blacklist-а. В бан мы помеcтим только самых агрессивных ботов, дабы не перегружать iptables.

# ищем ботов
cat /var/log/nginx/error.log | grep "limiting connections by zone" | grep "request: \"GET / HTTP/1.1"| awk '{print $12}'| awk -F"," '{print $
1}'| sort | uniq -c | sort -nr > /tmp/botnet.blacklist
# очищаем скрипт бана
cat /dev/null > /tmp/iptables_ban.sh
# создаем DROP правила для 50 самых агрессивных ботов
awk '{print "iptables -A INPUT -p tcp --dport 80 -s " $2 " -j DROP" }' botnet.blacklist | head -n 50 >> /tmp/iptables_ban.sh
# загружаем blacklist
bash /tmp/iptables_ban.sh
# делаем ротацию лога
cat /dev/null > /home/www/nginx_log/error.log
[ ! -f /var/run/nginx.pid ] || kill -USR1 `cat /var/run/nginx.pid`

Добавляем скрипт в крон с частотой несколько минут. Частоту подбираем опытным путем. Я сделал раз в 5 минут.

*/5 * * * * /root/script/ban.sh

В результате iptables будет пополнятся новыми ботами.

День третий. Итог
Данный метод обеспечил стабильный доступ клиентов к сайту. Правильная индексация в ПС была подтверждена тем, что сайт сохранил свои позиции в выдаче. Загрузка сервера не выходила за разумные пределы la неболее 6-7 пунктов. Исходящий трафик с сервера не превышал 100 Мбит/с. Для отражения атаки >7К ботнета вполне достаточно возможностей iptables.

DDoS как стихийное бедствие и избежать ущерба невозможно.
Часть клиентов, за время сбоя вашего сервиса, перейдет к конкурентам.
Вам придется понести некоторые расходы на переработки программистов, администраторов или приобретение дополнительного оборудования.
Ваш ресурс активно продвигается в ПС (yandex, google) значит, критичен риск неправильной индексации и как результат провал позиций в выдаче.
Главная задача минимизировать ущерб от DDoS.

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

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

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

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

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

___
> Q2W
> Возник вопрос относительно экономической эффективности атаки и её отражения:
> Сколько стоит один запрос от ботнета? (На сколько я должен удешевить ответ, чтобы атака стала убыточной?).
> Сколько стоит мегабайт паразитного трафика у DDoS'еров?
___
> > Fedia 14 февраля 2010 в 15:02 0
> > хороший пассиврый ботнет почти ничего не стоит атакующему. Но есть плюс: такая атака мощная, но одноразовая.
> > А активный ботнет при нынешней дешевизне инета и компов тоже стоит копейки
___
> > > Q2W 14 февраля 2010 в 15:04 0
> > > «Почти ничего» и «копейки» — это сколько точно?
___
> > > > Fedia 14 февраля 2010 в 15:11 +3
> > > > (палюсь)
> > > > 50000р за 3 дня 7гбит/сек 300000 хостов
> > > > ЗЫ есличо, ботнет не мой. Я такую атаку отражал и мы производили анализ затрат. В прошлом году в феврале
> > > > Положить канал 100мбит/сек на день будет стоить наверно 5круб
___
> > > > > Q2W 14 февраля 2010 в 15:26 0
> > > > > Вот спасибо, это ценная информация.
> > > > > Кстати, сколько запросов делали эти 300к хостов? Эта атака была нацелена на то, чтобы положить канал? Если так, то ещё интересно, > > > > > сколько тратят атакующие при атаке, нацеленной на DoS из-за высокой нагрузки на сервер.
> > > > > Пойду посчитаю, во сколько мне обходятся мегабайты трафика. =)
___
> > > > > > AlekseyKuzmin 15 февраля 2010 в 19:45 0
> > > > > > Вам удалось сжать трафик помощью фильтрации? каково было значение?
> > > > > > Как я понимаю, фильтрация может позволить снизить паразитный трафик в 5 и более раз.
> > > > > > Достаточно сжать 7Гбит до 1Гбит/с и победа наша. Другой вопрос сколько нужно ресурсов для такой фильтрации.
> > > > > > 1 Гбит/с в Москве стоит около 40т.р. в месяц — небольшая сумма для крупного проекта.
> > > > > > > Fedia 15 февраля 2010 в 21:43 0
> > > > > > > У атакующего клиента было 2 гигабитных канала.
> > > > > > > Оба лежали. А также «зацепило» ещё кучку клиентов поменьше
> > > > > > > Трафик был: http GET, DNS, ICMP, мусор
> > > > > > > с http перешли на https (это была первая, слабенькая волна), остальное сильно урезали силами провайдера (за что было ему уплочено). ДДоС был на забивание канала, а не на убивание сервисов.
> > > > > > > Паразитный трафик силами провадера и выкаченного Cisco GUARD был урезан в 15 раз