Centos защита от ddos

Оказывается можно попытаться защитить свой сервер от DoS посредством (D)DoS Deflate, это сценарий, который на периодичной основе проверяет количетсво используемых подключений с одного IP адреса, проверить наличие таких подключений можно командой:

При наличии подключений более чем обозначили Вы, данный IP блокируется, благодаря созданному автоматически скриптом правилу в iptables.

Установка (D)DoS Deflate

Происходит посредством загрузки установочного скрипта, указанием разрешений на запуск и собственно запуск установки:

Удаление (D)DoS Deflate

Происходит в аналогичном порядке, за исключением загружаемого скрипта:

Настройка (D)DoS Deflate

Конфиг расположен в каталоге — /usr/local/ddos/, имя конфига — ddos.conf, основные настройки:

указание возможного количества соединений — NO_OF_CONNECTIONS=100
указание блокировки посредством iptables — APF_BAN=0
период блокирования в секундах — BAN_PERIOD=600
настрйоку — KILL=1 оставляем по умолчанию
указать email для отправки почтовых уведомлений — EMAIL_TO=" Этот адрес электронной почты защищён от спам-ботов. У вас должен быть включен JavaScript для просмотра. "
так же можно создать список "белых" IP в файле — IGNORE_IP_LIST="/usr/local/ddos/ignore.ip.list"

Запуск самого скрипта можно можно осуществить так:

Дополнительно

Просмотр общего количества соединений:

Далее можно просмотреть рейтинг количества подключений:

Предложение от 8host.com

Модуль веб-сервера Apache по имени mod_evasive (ранее – mod_dosevasive) защищает сервер от атак DoS, DDoS и brute force. Он может отразить атаки на электронную почту и системные логи. Модуль создаёт внутреннюю динамическую таблицу IP- и URL-адресов, а также блокирует любой IP-адреса, выполняющий любое из этих действий:

Запрос одной и той же страницы несколько раз в секунду.
Создание более 50 одновременных запросов в секунду на один и тот же дочерний процесс.
Создание каких-либо запросов при временном внесении в черный список.

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

Это руководство поможет установить, настроить и начать работу с mod_evasive.

Требования

64-битный сервер CentOS 7 (или 6).
Не-root пользователь с правами sudo (о начальной настройке сервера и создании такого пользователя можно прочитать здесь).
Предварительно установленный и запущенный сервер Apache (инструкции по установке можно найти специальном разделе данного руководства).

1: Установка mod_evasive

Для начала нужно установить все пакеты, необходимые для корректной работы mod_evasive.

Одним из них является репозиторий EPEL (Extra Packages for Enterprise Linux).

Примечание: EPEL создаёт, поддерживает и управляет высококачественными наборами дополнительных открытых пакетов для Enterprise Linux.

Чтобы установить и включить EPEL, запустите команду:

sudo rpm -ivh http://dl.fedoraproject.org/pub/epel/7/x86_64/e/epel-release-7-5.noarch.rpm

sudo rpm -ivh http://download.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm

Чтобы убедиться, что репозиторий EPEL включен, введите:

sudo yum repolist

Если репозиторий включен, он появится в следующем списке:

epel/x86_64 Extra Packages for Enterprise Linux 7 — x86_64

Теперь нужно защитить базовые пакеты системы от обновлений репозитория EPEL при помощи protectbase:

sudo yum install yum-plugin-protectbase.noarch -y

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

Теперь можно установить mod_evasive.

sudo yum install mod_evasive -y

2: Проверка установки

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

Во время установки в системе появляется конфигурационный файл модуля (/etc/httpd/conf.d/mod_evasive.conf). Чтобы убедиться, что этот файл существует, введите:

sudo ls -al /etc/httpd/conf.d/mod_evasive.conf

Команда должна вернуть:

-rw-r—r— 1 root root 3473 Jul 21 01:41 /etc/httpd/conf.d/mod_evasive.conf

По умолчанию в начало конфигурационного файла mod_evasive.con добавляется строка LoadModule. Откройте файл и добавьте эту строку самостоятельно, если она не добавилась автоматически; эта настройка отвечает за поддержку веб-сервером Apache модуля mod_evasive.

LoadModule evasive20_module modules/mod_evasive24.so

LoadModule evasive20_module modules/mod_evasive20.so

Запросите список модулей Apache и найдите в нём mod_evasive:

sudo httpd -M | grep evasive

Если модуль включен, в списке будет строка:

3: Настройка mod_evasive

Теперь нужно открыть конфигурационный файл модуля mod_evasive и настроить некоторые параметры.

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

Откройте файл в текстовом редакторе:

sudo nano /etc/httpd/conf.d/mod_evasive.conf

Первый параметр, который нужно отредактировать – DOSEmailNotify. Эта директива отправляет извещения на указанный адрес в случае атаки на сервер. Сообщение выглядит так:

mod_evasive HTTP Blacklisted 111.111.111.111

К примеру, чтобы модуль отправлял извещения на адрес 8host@example.com, нужно добавить в файл (или раскомментировать) строку:

Примечание: для отправки извещений модуль mod_evasive использует /bin/mail. Для этого вам нужно установить и настроить почтовый сервер.

Следующий параметр – DOSWhitelist. Эта директива задаёт список заведомо безопасных IP-адресов. Такие адреса никогда не будут заблокированы. Цель белого списка заключается в защите программного обеспечения, сценариев, локальных поисковиков и других автоматизированных средств системы от блокировки в случае запроса больших объемов данных.

Чтобы добавить адрес в белый список, внесите в файл следующую строку:

Примечание: Замените условный IP своим IP-адресом.

Чтобы добавить в белый список несколько IP-адресов, просто добавьте новую директиву DOSWhitelist для следующего адреса:

DOSWhitelist 111.111.111.111
DOSWhitelist 222.222.222.222

Далее рекомендуется настроить параметры DOSPageCount и DOSSiteCount. Установите более щадящие значения, в противном случае модуль будет безосновательно блокировать клиентов.

DOSPageCount ограничивает количество запросов IP-адреса к одной странице в течение определённого интервала времени (как правило, в течение 1 секунды). Если IP-адрес превысил лимит, он будет заблокирован. Значение по умолчанию – 2 – очень строгое, и многие клиенты могут случайно попасть в бан. Измените его хотя бы на 20:

DOSSiteCount ограничивает общее количество запросов IP-адреса (т.е. ко всем страницам сайта) в течение определённого интервала (по умолчанию – за 1 секунду). Увеличьте значение данного параметра до 100:

Параметр DOSBlockingPeriod задаёт временной интервал (в секундах), в течение которого клиент будет заблокирован на данном сайте. Отправляя запросы в течение этого периода, клиент будет получать ошибку 403, а интервал будет восстанавливаться (по умолчанию – 10 секунд).

Чтобы увеличить продолжительность блокировки, можно изменить значение данного параметра:

Параметр DOSLogDir ссылается на временный каталог mod_evasive; по умолчанию для блокировки используется каталог /tmp, который может стать причиной некоторых проблем безопасности, если система открыта для пользователей оболочки. Если в вашей сети есть непривилегированные пользователи оболочки, нужно создать отдельный каталог, доступный для записи только пользователю, управляющему Apache (обычно он называется apache), а затем установить этот параметр в файле mod_evasive.conf.

К примеру, можно настроить mod_evasive для использования нестандартного каталога /var/log/mod_evasive. Создайте каталог:

sudo mkdir /var/log/mod_evasive

Передайте права на него пользователю apache:

sudo chown -R apache:apache /var/log/mod_evasive

А затем отредактируйте конфигурацию mod_evasive и укажите новый каталог:

Параметр DOSSystemCommand задаёт команду, которую нужно запустить в случае блокировки IP-адреса. При помощи этого параметра можно интегрировать в mod_evasive брандмауэр или сценарий оболочки и заблокировать вредоносный IP при помощи брандмауэра.

4: Загрузка модуля mod_evasive

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

sudo systemctl restart httpd.service

sudo service httpd restart

Примечание: Модуль mod_evasive конфликтует с серверными расширениями FrontPage.

Также рекомендуется проверить настройки Apache на совместимость с настройками mod_evasive.

В случае конфликта рекомендуется увеличить значение параметра MaxRequestsPerChild (но не unlimited, которое задаётся при помощи 0) и включить KeepAlive, выбрав разумное значение для KeepAliveTimeout.

5: Тестирование mod_evasive

Выполните небольшое тестирование работы модуля. Для этого можно использовать perl-скрипт test.pl, написанный разработчиками mod_evasive. Чтобы выполнить скрипт, установите пакет perl:

sudo yum install -y perl

Тестовый скрипт устанавливается вместе с mod_evasive и хранится в:

По умолчанию скрипт test создаёт 100 запросов к одной странице Apache; такое поведение должно запустить модуль. Если вы изменили параметры модуля, сделав их более мягкими, отредактируйте скрипт, чтобы увеличить количество запросов до 200. Откройте файл скрипта:

sudo nano /usr/share/doc/mod_evasive-1.10.1/test.pl

Замените в ней 100 на 200:

Сохраните и закройте файл.

Чтобы выполнить скрипт, введите:

sudo perl /usr/share/doc/mod_evasive-1.10.1/test.pl
Вывод:
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
.

Код ошибки 403 значит, что доступ к серверу заблокирован. Модуль добавит вредоносный IP в системный лог. Просмотрите лог-файл:

sudo tailf /var/log/messages

Он должен содержать примерно такую запись:

Jul 29 00:11:18 servername mod_evasive[18290]: Blacklisting address 127.0.0.1: possible DoS attack.

Это значит, что модуль заблокировал IP-адрес злоумышленника.

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

mod_evasive HTTP Blacklisted 127.0.0.1

Заключение

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

В первой части обзора CentOS 7 было рассказано о поддержке контейнеров Linux в Cent OS 7. Во второй части мы поговорили об управлении идентификацией. В третья части обзора мы коснулись сетевой файловой системы NFS и ее окружению. В этой статье поговорим о смягчении DDoS атак TCP SYN Flood. В конце поста ссылка на бесплатное тестирование CentOS 7 в облачной VPS от Infobox.

DDoS (Distributed Denial of Service) атаки становятся все более частым явлением, из-за того, что бизнес становится все более зависимым от сети Интернет. Одна из самых распространенных видов DDoS – SYN Flood. Эта основная атака конечных хостов, ставящая ваш сервер на колени. В результате ваш сервер не может правильно обрабатывать входящие запросы.

Важно заметить, что описанные механизмы защиты доступны в CentOS 7, но не включены по умолчанию.

Почему SYN-flood — боль для ядра

Основная проблема масштабируемости TCP для ядра Linux связана с тем, как много новых соединений могут быть созданы за секунду. Это относится к блокировке на сокет в состоянии «listen» (прослушивания). «Estabilished» (Установленные) соединения масштабируются очень хорошо. Блокировка состояния «listen» встречается не только с SYN–пакетами, но и другими пакетами для первоначального подключения «SYN-ACK» и «ACK» (пакеты тройного рукопожатия в TCP). В сценарии атаки флудом нам необходим механизм фильтрации фейковых попыток подключения до того, как сокет войдет в состояние «listen» и блокирует новые входящие соединения.

Основы фильтрации conntrack

Используя систему отслеживания соединений в Netfilter (conntrack), мы можем начать фильтрацию ложных SYN-ACK и ACK пакетов до того, как они вызовут блокирующее состояние «listen». Это было возможно уже долгое время, но не было включено по умолчанию.

Вам помогут следующие две команды:

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

Настройка sysctl сделает систему отслеживания соединений более строгой в категоризации и поможет уклониться в том числе от атак ACK–flood.

Что с производительностью?

В результате мы в 20 раз уменьшим влияние атак, основанных на SYN–ACK и ACK.

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

По сути это предотвратит проблемы от всех флудящих пакетов TCP, кроме SYN.

Почему это не работает с SYN-flood?

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

Даже после настройки contrack SYN пакеты будут отправлены сокету вызывая блокировку «listen». Методика смягчения этой атаки — отправить SYN–куки и предотвратить создание любого статуса, пока SYN–ACK не будет виден.

К сожалению SYN–куки, отправляются под той же блокировкой «listen», поэтому такое смягчение не решит проблему масштабируемости. Чуть позже мы обсудим, как обойти это ограничение.

Что нового в CentOS 7

На Netfilter Workshop 2013 была предложена идея «сетевых контрмер». Это дало рождение модулю iptables «SYNPROXY» и соответствующим изменениям в ядре Netfilter. Теперь эта функциональность доступна в CentOS 7.

Модуль SYNPROXY предназначен для решения двух проблем с масштабируемостью. Во-первых работает с SYN–куками параллельно. Во-вторых, он не создает conntrack до получения пакета SYN–ACK, что позволяет conntrack не блокировать новые соединения.

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

Тестирование на соединениях к localhost показали 10-и кратный рост производительности по смягчению SYN–атак.

Настройка SYNPROXY

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

Этот пример может быть использован для защиты веб-сервера на 80 порту.

Шаг 1

Убедитесь, что соединения, которые мы защищаем, не создают conntrack для SYN пакетов.

Шаг 2

Включим более строгий conntrack. Это необходимо чтобы иметь INVALID статус для плохих ACK пакетов.

Шаг 3

Теперь нам необходимо обрабатывать эти пакеты и передавать их напрямую в модуль SYNPROXY. Чтобы это сделать, используйте правило обработки UNTRACKED SYN и INVALID пакетов, которые содержат ACK от тройного рукопожатия (и других, но они просто будут проходить через это правило):

Шаг 4

Поймайте пакеты с состоянием INVALID, которые попали в SYNPROXY и уничтожьте их. Это предотвратит флуд SYN–ACK.

Шаг 5

Не забудьте включить временные метки TCP. SYN–куки используют это поле TCP.

Шаг 6

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

Необходимо устанавливать значение лимитов, актуальное для вашего сайта и посчитать использование памяти для него. Например, 2 000 000 записей за раз по 288 байт = максимум 576 Мб потенциального использования памяти. Для хеша, каждая голова хеш-таблицы занимает только 8 байт на миллион записей = 8 Мб фиксированной выделенной памяти (помните размер вашего кеша L3 у CPU, когда выбираете значение кеша). Узнать, какой процессор используется на хосте можно командой:

Соображения по использованию SYNPROXY

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

Параметры модуля SYNPROXY должны соответствовать опциям TCP и должны поддерживаться конечным хостом, для которого TCP соединение проксируется. Обнаружение и настройка производится вручную на основе правил (полезный инструмент «nfsynproxy» – часть релиза iptables 1.4.21). К сожалению это означает, что модуль не может быть просто развернуть на DHCP файрволы.

В будущем есть планы по авто-обнаружению опций TCP конечных хостов. Голосуйте за фичу в баг-трекере Red Hat.