Ddos атака как найти

Время на прочтение
7 мин

Количество просмотров 22K

Приветствую, Хабр! Я работаю в небольшом интернет провайдере масштаба области. У нас транзитная сеть (это значит, что мы покупаем интернет у богатых провайдеров и продаем его бедным). Несмотря на небольшое количество клиентов и такое же небольшое количество трафика протекающего по нашей сети, довольно часто приходится иметь дело с весьма внушительными DDoS-атаками по 10-20Гбит/с. (чаще всего конечно это атаки гораздо меньшего калибра). И хотя некоторые из наших клиентов обзавелись уже системами обнаружения таких атак и могут самостоятельно отправить жертву в блек-холл, гораздо чаще обнаружение атаки и бан конкретного IP жертвы ложится на наши плечи (тем более, если атака способна забить наши внешние каналы).

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

На самом деле систем для обнаружения Ddos-атак основанных на анализе данных протоколов NetFlow/SFlow/IPFIX существует довольно много (вероятно почти все?). В первом приближении, суть всех таких систем сводится к установлению порогов по количеству пакетов/потоков/октетов на определенный тип трафика к конкретному IP, при превышении которого система сигнализирует о возможной атаке. И наше решение ничем от них в этом плане не отличается. Однако, основная проблема – большинство из них платные. А бесплатные версии предлагают довольно грубый анализ, который часто неэффективен (к примеру, позволяет устанавливать порог только на весь трафик к конкретному IP, без его предварительной фильтрации, что в случае анализа транзитного трафика почти всегда бесполезно).

Итак, сперва необходимо настроить протокол NetFlow на сетевом оборудовании с минимально возможным active timeout (интервал с котором экспортируются данные с оборудования на коллектор) — это 60с для Cisco и Juniper.

forwarding-options {
    sampling {
        input {
            rate 2000;
            run-length 0;
        }
        family inet {
            output {
                flow-inactive-timeout 15;
                flow-active-timeout 60; 
                flow-server 10.0.0.10 {
                    port 9999;
                    autonomous-system-type origin;
                    source-address 10.0.0.1;
                    version 5;
                }
            }
        }
    }
}

interfaces {
    ae1 {
            vlan-id ...;
            family inet {
                sampling {
                    input;
                    output;
                }
                address ...
            }
    }
}

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

В качестве коллектора решено было использовать многим знакомый flow-capture из набора утилит flow-tools. Именно набор утилит, который позволяет строить разнообразные и подробные отчеты на основе собранной статистики является главным достоинством этого пакета. (К слову в наборе утилит также есть и flow-dscan для обнаружения сканирования хостов/портов и другой нежелательной активности). В недостатки можно записать отсутствие веб-оболочки и отсутствие поддержки 9й версии NetFlow. Однако, повторюсь, гибкость таких утилит как flow-nfilter, flow-report и, конечно же, свободное распространение с легкостью все перекрывают.

# cd /usr/ports/net-mgmt/flow-tools
# make install clean

flow_capture_enable="YES"
flow_capture_localip="10.0.0.10"  #локальный ip на который принимается поток
flow_capture_remoteip="10.0.0.1" #ip с которого льется поток
flow_capture_port="9999" #порт на который льется поток
flow_capture_datadir="/var/db/flows" #директория с файлами собранной телеметрии
flow_capture_flags="-z0 -n1439 -N3 -E10G -e0 -S1" #параметры

Из всего набора утилит flow-tools нас будут интересовать три:

1. Flow-nfilter – позволяет фильтровать статистику по таким параметрам как ip адрес/протокол/порт. Нам она нужна будет для своеобразного белого списка IP, которые нужно исключить из проверки. Например, ip-адреса гугл-кэш серверов в вашей сети (или любых других кэшей), где достаточно высокий поток трафика может ложно сигнализировать о ддос-атаке. Создадим файл filters.cfg с фильтром (ip-адреса для примера):

   filter-primitive white-list-ip
       type ip-address-prefix
       deny 8.8.8.8
       deny 64.233.160.0/19
       default permit
   
   filter-definition white-list
       match ip-destination-address white-list-ip
       match ip-source-address white-list-ip
   

2. Flow-report – утилита позволяющая строить отчеты, группируя трафик и сортируя данные по заданным параметрам. Чем-то похожа на функцию Groups By в SQL. Типов отчетов, которые она может сгенерировать множество (многие из них могут быть полезны для Traffic Engineering). Нас интересуют следующие:
   • ip-destination-address/ip-source/destination-port – группировка потоков, как не сложно догадаться, по ip-destination адресу, source/dest порту. Это значит, что будут объединены все потоки с одинаковыми ip-destination-address & ip-source & destination-port и представлены в отчете в отсортированном порядке, например, по потокам или пакетам (если конечно эту сортировку задать). Такого рода отчет позволит выявить так называемые DDoS-атаки с отражением на какой-нибудь сервис. К примеру, если зафиксировано аномально большое количество потоков с порта 53 на порт 80 какого-нибудь хоста, можно говорить о возможной атаке. Это удобно, так как в большинстве случаев такого рода потоков немного, и при правильно настроенном пороге можно выявить атаку даже с минимальным результирующим трафиком. Для того что бы задать отчет, нужно создать файл с его описанием. Создадим файл reports.cfg:

     stat-report sdport_flows
         type ip-destination-address/ip-source/destination-port
         output 
     		format ascii
     		options -header,-xheader,-totals,-names
     		fields +flows,-octets,-packets,-duration
     		sort +flows
      
     stat-definition sdport_flows
     	report sdport_flows
     

   • ip-destination-address/ip-destination-port – более грубая группировка, учитывающая только два параметра. Но работать она будет по пакетам. Добавим в созданный файл reports.cfg:

     stat-report dport_packets
     	type ip-destination-address/ip-destination-port
     	output 
     		format ascii
     		options -header,-xheader,-totals,-names
     		fields -flows,-octets,+packets,-duration
     		sort +packets
     
     stat-definition dport_packets
     	report dport_packets
     

   • ip-destination-address – и самая грубая группировка по результирующему трафику на конкретный ip. Здесь мы создадим два отчета по потокам и по пакетам.

     stat-report flows
     	type ip-destination-address
     	output 
     		format ascii
     		options -header,-xheader,-totals,-names
     		fields +flows,-octets,-packets,-duration
     		sort +flows
      
     stat-definition flows
     	report flows
     
     stat-report packets
     	type ip-destination-address
     	output 
     		format ascii
     		options -header,-xheader,-totals,-names
     		fields -flows,-octets,+packets,-duration
     		sort +packets
      
     stat-definition packets
     	report packets
     

3. Flow-print – позволяет отобразить собранную телеметрию.

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

Код скрипта я приводить не буду, он с файлами filters.cfg и reports.сfg доступен на GitHub

Для его работы достаточно сконфигурировать некоторые параметры в config.ini. И добавить его в крон на исполнение в каждую минуту.

[REPORTS]
sdport_flows
dport_packets
flows
packets

# Reports(rules) options 
# threshold - threshold value
# key_field - report field index number to which the threshold applies 
# filter - name of a filter described in FiltersFileName
[sdport_flows]
threshold = 300
key_field = 4
filter = white-list

[dport_packets]
threshold = 3000
key_field = 3
filter = white-list

[flows]
threshold = 2000
key_field = 2
filter = white-list

[packets]
threshold = 5000
key_field = 2
filter = white-list

[FILES]
# Dir with flow-tools binary files
FlowToolsBinDir = /usr/local/bin/
# Dir with Whois, AWK binary files
SysBinDir = /usr/bin/
FlowsDir = /var/db/flows/
ReportsFileName = reports.cfg
FiltersFileName = filters.cfg

[EMAIL]
SMTPServer = localhost
# 0-default port
SMTPPort = 0 
MailFrom = mail@example.com
MailTo = mail@example.com
Subject = [DDoS Detect]
# Amount of flow-print records in an email
FlowPrintTail = 50
# Use TLS (if True, Auth must be the same)
Secure = False
# Use Login and Password
Auth = False
# Notification Frequency about current DDoS attack - every value minutes
# if 0 - don't send email, print victims ip to stdout 
NotifyFreq = 5

# Act if Auth = True
[EMAIL-AUTH]
Login = ...
Password = ...

Письмо с уведомлением об атаке выглядит так:

Скрипт позволяет добавлять/убирать свои отчеты по которым будет происходить анализ трафика, задавать для каждого отчета свой фильтр из файла filters.cfg, менять частоту уведомлений для текущей DDoS-атаки. Позволяет также вывести список атакуемых IP на stdout, не отправляя письмо.

Еще раз ссылка на GitHub

Вот собственно и все. Спасибо за внимание!

Подписаться

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

Содержание:

• Что такое DDoS атака и чем отличается от DoS атак?
• Как распознать ДДоС атаку и определить ее источники
• Бесплатная защита для сайта от DoS и DDoS атак
  • Средствами блокировки htaccess
  • Сервис фильтрации трафика CloudFare
  • PHP скрипт для автоматической блокировки IP адресов
• Зачем злоумышленники атакуют сайты

DDoS атака – что это и в чем отличие от DoS?

Прежде чем перейти к рассказу о ДДоС атаках, стоит упомянуть об их младшем брате – DoS атаке (сокращение от Denial of Service – отказ в обслуживании). О ДоС атаках редко говорят и пишут, хотя, многие реальные ситуации должны интерпретироваться именно как DoS с одной буквой D. ДДоС, в свою очередь, является частным случаем первой и имеет существенные особенности.

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

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

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

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

Наличие дополнительной «D» означает Distributed Denial of Service – распределенный отказ в обслуживании.

Четкой границы в названиях нет, условно мы можем считать, что DoS атака – это хакерская атака, характеризующаяся всего парой атакующих IP адресов, а DDoS – это все что выше. вот выглядит архитектура DDoS атаки в упрощенном виде:

Принципиальное отличие в классификации этих типов становится понятным только на этапе формирования комплекса мер по защите – защищаться от DDoS значительно сложнее, об этом поговорим ниже.

Виды DoS атак по уровню воздействия

1. Массовые спамные – это атаки, при которых система нагружается за счет огромного количества запросов. Даже на обработку простых действий тратится процессорное время сервера, и, при их большом, количестве сервер не справляется;
2. Умные точечные – при такой атаке запросы шлются к тем элементам системы, которые являются наиболее уязвимыми (потребляют максимум процессорной мощности). Общее количество запросов может быть небольшим, а сервер виснет.

Как распознать DDoS атаку и определить ее источники?

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

Симптомы DoS атак совпадают со многими другими проблемами, главный из них – это периодическая или полная потеря работоспособности сайта (вместо нужных страниц сервер выдает ошибки 50x или полную недоступность). В некоторых случаях, когда атака слабая сайт может работать, но жутко тормозить.

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

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

Лог сайта – это файл, в который записывается информация о поступающих запросах. Бывает лог ошибок, он короткий и в нем отражаются только те запросы, в ответ на которые сервер был вынужден дать ошибку. Но нам нужен лог посещений, в него пишется каждый запрос поступающий сайту, фиксируется – время, IP адрес, с которого поступает запрос, тип запроса (GET, POST, HEAD) целевой URL, код выданного ответа, идентификатор пользователя (браузер, данные роботов и т.д.).

Пример одиночной записи лога доступа:

biznessystem.ru 104.194.196.238 - - [27/Nov/2016:11:01:26 +0300] "GET /2014/01/kak-otkryt-fajl-rar-kak-polzovatsa-winrar/ HTTP/1.1" 200 74658 "-" "Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13" 0

Последовательно здесь указано: мой домен, IP адрес источника запроса, дата и время, тип запроса и адрес страницы, код ответа сервера (200), данные источника запроса (браузер, операционная система).

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

Признаки DoS атаки:

1. Большое число запросов с одного IP адреса, превышающее адекватные потребности живого человека (тысячи);
2. Интервал между запросами существенно меньше, чем нужен человеку. Например, живой человек не будет открывать новую страницу сайта каждую секунду (она даже загрузиться не успеет);
3. Повторение одинаковых запросов, как будто кто-то постоянно обновляет страницу.
4. Запросы к страницам, которых не существует или которые не предназначены для пользователей – это не всегда признак именно DoS атаки, но всегда должно обращать внимание, может быть вас пытаются взломать, ища уязвимые места.

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

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

При анализе лога было обнаружено 11253 запроса с IP 213.159.212.73. Причем, все эти запросы были отправлены в течение 40 минут.

В данном случае налицо были признаки: много запросов, маленькие интервалы (по 3-4 новых страницы в секунду), обращение к несуществующим страницам (404 ошибка), обращение к запрещенным страницам (403 ошибка).

Как бесплатно защитить сайта от DoS и DDoS атак?

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

Защиту необходимо организовывать по двум направлениям:

1. Оптимизировать работу сайта таким образом, чтобы он потреблял меньше ресурсов при передаче пользователям данных. Это отдельная тема для разговора, по которой я планирую сделать отдельную подробную статью — Как ускорить работу сайта (чтобы не пропустить подписывайтесь на обновления). Как минимум, поставьте кэширование страниц (для WordPress делается плагином Hyper Cache) и оптимизируйте размер изображений. На масштабную атаку это мало повлияет, а от небольших поможет существенно.
2. Фильтровать трафик, поступающий на сайт – задача в том, чтобы спамные запросы до сайта не доходили и не заставляли сервер напрягаться впустую. Фильтрацию можно осуществлять на 3 уровнях, которые мы ниже рассмотрим подробнее – фильтрация доступа через файл htaccess, использование сторонних ресурсов для очистки трафика, блокировка атакующих ip адресов php скриптом.

1. Блокировка нежелательных запросов через htaccess

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

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

Защита от DDoS атак с помощью htaccess осуществляется по двум направлениям – ограничения по IP адресам и ограничения по определенным признакам в самих запросах.

Защита по IP адресам

Есть две команды deny и allow, которые, соответственно, значат запрещено и разрешено. Конструкция с их участием выглядит как

deny from XXX.XXX.XXX.XXX
allow from XXX.XXX.XXX.XXX

где вместо X указывается IP адрес запроса (диапазон адресов) или ставится all (для всех). Адреса, которые надо блокировать берем из логов.

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

1. Запрет доступа к особым файлам сайта

Закрывать доступ к конкретным файлам вещь очень полезная – с ее помощью мы можем наглухо запечатать дорогу любым хакерам к админке и другим важным служебным элементам сайта. Конструкция выглядит вот так:

<Files wp-login.php>
order deny,allow
deny from all
allow from 1.2.3.4
</files>

Здесь указан файл wp-login.php (вход в админку), запрещен доступ всем адресам, разрешен доступ для адреса 1.2.3.4 (ваш личный IP).

В разных CMS служебные файлы разные, для WordPress рекомендую закрыть файлы xmlrpc.php, readme.html, wp-config.php

2. Блокировка по типам запросов

Есть разные типы запросов, в логах почти всегда вы будете видеть GET – получить данные или POST – отправить данные (запостить что-то).

Когда я анализирую логи, то выявляю IP адреса, которые пытаются взломать сайт (лезут в админку и т.д.) – этим надо ограничить возможность слать POST, тем, которые ддосят запрещаю  полностью и GET и POST.

Но есть один нюанс во всем этом – большинство IP адресов динамические и пользователи их могут постоянно менять, в результате чего бан по отдельным IP редко эффективен. Приходится банить весь диапазон подсети (если он маленький или принадлежит другим странам) или оставлять доступ открытым – это неприятный минус, но терять посетителей не хочется. Вы решайте сами, как поступить. Местонахождение IP и диапазон адресов подсети я смотрю тут — 2ip.ru/whois/

Технически делается так:

Блокировка POST для подсети (3 строка) и IP адреса (4 строка).

<Limit POST>
order allow,deny
deny from 195.22.124.
deny from 195.22.125.45
allow from all
</Limit>

Блокировка GET и POST для диапазона и IP адреса.

<Limit GET POST>
order allow,deny
deny from 107.150.46.52
deny from 103.13.31.
allow from all
</Limit>

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

Защита по признакам User Agent в запросах

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

В htaccess добавьте следующий код:

# Запрет хакерских ботов
RewriteEngine on
RewriteCond %{HTTP_USER_AGENT} ^$ [OR]
RewriteCond %{HTTP_USER_AGENT} (<|>|'|%0A|%0D|%27|%3C|%3E|%00) [NC,OR]
RewriteCond %{HTTP_USER_AGENT} .*(libwww-perl|wget|python|nikto|curl|scan|java|winhttp|clshttp|loader).* [NC]
RewriteRule ^(.*)$ - [F,L]

Первая строка защитит от пустых user agent, вторая — от агентов со странным одиночным символом, а в третьей перечислены некоторые бесполезные и вредные боты (можно добавлять по мере появления новых). Вот пример работы такого бота, сразу видно, что он лезет не туда, куда надо:

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

2. Сервис для очистки от спамного трафика Cloudflare

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

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

До недавнего времени я не использовал данную схему, так как платить лишние деньги не хотелось, а защитить сайт от редких DoS атак мне удавалось через блокировку адресов в htaccess. Но, оказалось, что есть сервисы, которые дают защиту начального уровня бесплатно – для небольших некоммерческих проектов этого достаточно.

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

Шаг 1. Регистрируем аккаунт

Здесь — www.cloudflare.com/plans/ — выбираем бесплатный вариант

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

Шаг 2. Сканирование DNS записей

В форму вписываете свой домен и нажимаете кнопку «Scan DNS Records».

Минуту будет идти сканирование, после чего станет активной кнопка «Continue» — ее и жмем. Результат проведенной проверки содержит информацию обо всех найденных системой DNS записях, относящихся к вашему сайту. При желании их можно править и добавлять новые – перед нами информация о том, куда будет идти очищенный трафик – туда же, куда шел неочищенный до настройки.

Оставляем все без изменений и жмем «Continue» еще раз.

Шаг 3. Выбор тарифа (повторно)

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

Шаг 4. Настройка новых NS серверов

Все что мы сделали до этого – подготовили свой аккаунт в сервисе к перенаправлению трафика на хостинг. Теперь нужно сделать так, чтобы сам домен направлял трафик не напрямую на хостинг, а на CloudFlare для фильтрации. Для этого требуется сменить NS записи серверов – они настраиваются у регистратора доменов, если домен регистрировали напрямую у хостера, то прямо в админке хостинга должна быть смена (или спросите у тех поддержки).

На картинке слева показаны текущие записи, справа — те, на которые нужно сменить.

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

Шаг 5. Проверка статуса

После нажатия «Continue» на этой странице будет проведена проверка DNS записей домена. Если они еще не сменились, то мы получим такой результат со статусом — обрабатывается:

Как только система перепроверит работу NS серверов, статус обновится на активный. Дополнительно, на почту должно придти уведомление о том, что сайт принят к защите в ClowdFlare.

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

Основные настройки и возможности CloudFlare

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

Analytics (Аналитика) – это раздел, в котором показана вся статистика по работе системы безопасности CloudFlare. Показан общий трафик, и много других данных, но, главное — количество заблокированных угроз —  Threats. По ним вы можете оценить уровень безопасности вашего ресурса. Я ничего не сказал о дополнительных функциях CloudFlare, так вот, он не только фильтрует плохие запросы, он еще кэширует данные и экономит как серверные мощности хостинга, так и снижает загруженность канала, в моем случае экономия больше 80% (все на стандартных настройках).

DNS – раздел доменных записей, в котором меняются настройки NS записей. Например, если вы решите перенести сайт на другой хостинг, то целевые сервера поменяются. И, для того, чтобы CloudFlare перестал слать фильтрованные пакеты на старый сервер, надо указать новый.

Firewall – в этом разделе можно менять степень защиты. Security level позволяет выбрать несколько уровней подозрительности к трафику. Если сайт висит из-за ДДоС атаки, то установка режима «I’m under attack!» Будет пропускать к сайту только после подтверждения того, что запрос от человека. Время разрешения доступа показывает, как долго пользователь остается в белом списке, после последнего запроса, по истечении этого времени его запросы снова тщательно проверяются сервисом. В самом низу мы есть табличка для ручной блокировки определенных IP адресов и целых стран.

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

3. Защита от DDoS с помощью PHP скрипта

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

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

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

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

Вот здесь приведена инструкция и сам скрипт для защиты от DDoS атак (в конце статьи) — перейти на сайт.

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

Зачем злоумышленники атакуют сайты?

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

1. Проверка сил у школоты

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

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

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

2. С целью вымогательства

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

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

Все это сопровождается посланием, в котором от вас попросят заплатить за прекращение DDoS атаки или предложение «крыши» защиты от хакеров.

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

3. Взлом сайта

Не всегда цель хакеров – это уронить ваш сайт. Зачастую их основная цель заключена в поиске уязвимых мест в вашей CMS, через которые они смогут в будущем внедрить вредоносный код. А поиск таких уязвимостей ведут боты, которые тупо «пробивают» разные известные им заранее косяки – есть они у вас или нет. Когда эти боты работают чересчур усердно и шлют очень много запросов, получается типичная DoS атака и слабенький хостинг не выдерживает.

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

4. Конкуренты

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

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

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

5. Политика, религия и т.п.

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

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

Что такое DDoS-атака?

Распределенная атака типа «отказ в обслуживании» — это когда хакер использует ботнет для отправки вашему веб-серверу подавляющего числа HTTP-запросов за очень короткий промежуток времени.

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

Во время нормальной работы веб-сервер предоставляет вашу веб-страницу посетителям следующим образом:

— Человек вводит ваш URL в свой веб-браузер.

— Веб-браузер отправляет HTTP-запрос к URL-адресу веб-сайта.

— DNS-серверы вашего провайдера преобразуют URL-адрес в правильный IP-адрес веб-сервера.

— HTTP-запрос направляется через Интернет на веб-сервер.

— Веб-сервер использует страницу, запрошенную в URL, чтобы найти правильный файл HTML.

— Веб-сервер отвечает всем содержимым этого HTML-файла.

— Браузер пользователя получает файл HTML и отображает страницу для пользователя.

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

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

Поскольку ваш веб-сервер не был рассчитан на такой объем трафика, веб-сервер будет отвечать на ваши обычные посетители сайта с сообщением об ошибке «Сервис недоступен». Это также известно как ошибка HTTP 503.

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

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

Как вы узнаете, что ваш сайт только что вышел из строя из-за DDoS-атаки? Есть несколько симптомов, которые являются мертвой раздачей.

Обычно ошибка 503 HTTP, описанная выше, является четким указанием. Однако еще одним признаком DDoS-атаки является очень сильный скачок пропускной способности.

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

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

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

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

Как остановить DDoS-атаку

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

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

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

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

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

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

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

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

Понимание того, как определить DDoS-атаку и как ее остановить, может сократить время простоя и сократить время, необходимое вам и вашему хостинг-провайдеру для восстановления после него. С уважением к Вам Администратор сайта Kaknastroit.com!

DDoS-атаки бывают разных типов — злоумышленники могут атаковать как сервер в целом, так и отдельный сайт. Сегодня мы подробнее остановимся на атаках уровня L7, его еще называют уровнем приложений. В случае с сайтами, такая атака направлена на http/https-сервер и проявляется, как правило, в том, что на веб-сервере запускается огромное количество процессов — нагрузка возрастает и сервер начинает тормозить или становится недоступен по причине исчерпания ресурсов.

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

1. Диагностика на наличие атаки
   1. Определяем наличие атаки 
   2. DoS-атаки и выявление источника атаки по логам
   3. Простой, но важный способ снижения нагрузки от атак
2. Защита от DDoS-атак
   1. С помощью ISPmanager
      1. Точечная блокировка в ISPmanager
      2. Блокировка по странам
   2. Ручные настройки 
      1. Корректировка параметров apache
      2. Модули nginx
      3. Переменные sysctl
3. Подключение DDoS-защиты
   1. Если нужен сервис защиты, но бюджет не позволяет

Диагностика на наличие атаки 

В первую очередь нам необходимо понять, есть ли DDoS-атака.

Если это атака на канальном уровне, то, скорее всего, ваш сервер будет недоступен, так как сетевой канал забит, и попасть на сервер можно будет только через VNC.
Однако в данной статье мы говорим об атаках на веб-сервер — в этом случае, если есть возможность — зайдите на сервер по ssh.

Определяем наличие атаки

Командами ps и top вы можете выявить главный признак атаки — большое количество процессов httpd (apache2), php-fpm или nginx (реже). 

Если на сервер по ssh войти не удается, то вполне возможно еще удастся попасть через окно VNC в панели VMmanager (бессетевой доступ к VDS).

Также можно перезагрузить сервер через VMmanager и попробовать зайти по ssh. Если возрастает количество процессов веб-сервера, то необходимо остановить его либо, как вариант, можно «убить» все процессы веб-сервера командой:

killall -9 <имя демона-процесса веб-сервера>

Посмотреть, какой процесс запускается в качестве веб-сервера, можно с помощью команды (если утилиты netstat нет, то необходимо предварительно ее установить):

netstat -na | grep ':80 '

netstat -na

Посмотреть количество процессов веб-сервера и количество подключений на 80-ый порт:

ps aux | grep -с <имя демона-процесса веб-сервера>

netstat -na | grep -с ":80 "

Эти команды считают количество процессов веб-сервера и количество подключений на 80 порт (если у вас используется SSL-сертификат, то вместо “80” необходимо указывать “443”, оптимально использовать оба варианта).

Если количество соединений превышает среднестатистическое, вероятно, это DoS/DDoS-атака.

DoS-атаки и выявление источника атаки по логам 

DoS-атаки случаются даже чаще,чем DDoS, и если говорить максимально упрощенно, то их отличает то, что они:

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

Посмотреть, какие источники подключений к 80-му (443-му) порту присутствуют, можно с помощью команды:

netstat -an | grep -E ':80 |:443 '| awk '{print $5}' | grep -Eo '[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}' | sort | uniq -c | sort -n

Команда выведет список по возрастанию в виде строк: количество подключений — ip-адрес источника.

Данная команда также поможет в выявлении DoS/DDoS. Tcpdump запишет в файл ddos.log первые 200 пакетов, которые соединений на 80/443 порту:

tcpdump -nr ddos.log | awk '{print $3}' |grep -oE '[0-9]{1,}.[0-9]{1,}.[0-9]{1,}.[0-9]{1,}' |sort |uniq -c |sort -rn

Если атака временно прекратилась или вы хотите узнать, откуда больше всего подключались, можно проанализировать access-лог веб-сервера командой:

grep `date +%d/%b/%Y` /var/www/httpd-logs/*.access.log  | awk '{print $1}' | sort | uniq -c | sort -nr | head -n 10

Она выведет список 10 наиболее «активных» IP-адресов. Также по логу можно выявить, на какой сайт идет очень много обращений.

Выяснить, не было ли однотипных обращений, можно командой:

grep `date +%d/%b/%Y` /var/www/httpd-logs/*.access.log | awk '{print $1" "$7}' | sort | uniq -c | sort -rnk1 | head -n 10

Для этой же цели многие предпочитают использовать модуль mod_status.

Mod_status позволяет в реальном времени осуществлять мониторинг загрузки сервера.

Например, в случае apache 2.4 необходимо отредактировать файл /etc/apache2/mods-enabled/status.conf

Поменять секцию:

      <Location /server-status>

               SetHandler server-status

               Require local

               #Require ip 192.0.2.0/24

       </Location>

на

      <Location /server-status>

               SetHandler server-status

       </Location>

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

ExtendedStatus On

Перезапустите apache.

Теперь по адресу http://ip-aдрес.сервера/server-status доступна статистика запросов к нему.

Нас интересует следующее:

0-0    86795    0/31/31    W     0.54    0    0    0.0    0.09    0.09     89.18.166.89    example.com    GET / HTTP/1.0

1-0    86796    0/19/19    W     0.30    0    0    0.0    0.06    0.06     79.140.78.68    example.com    GET / HTTP/1.0

2-0    86801    0/9/9    W     0.15    0    0    0.0    0.03    0.03     89.18.166.89    example.com    GET / HTTP/1.0

3-0    86802    0/9/9    W     0.14    0    0    0.0    0.03    0.03     82.12.33.48    myhost.com    GET /server-status/ HTTP/1.1

4-0    86805    0/4/4    W     0.07    1    0    0.0    0.01    0.01     79.140.78.68    example.com    GET / HTTP/1.0

5-0    86806    0/3/3    W     0.06    2    0    0.0    0.01    0.01     89.18.166.89    example.com    GET / HTTP/1.0

6-0    86807    0/4/4    W     0.07    0    0    0.0    0.01    0.01     89.18.166.89    example.com    GET / HTTP/1.0

7-0    86808    1/4/4    C     0.08    0    2015    3.0    0.01    0.01     89.18.166.89    example.com    GET / HTTP/1.0

8-0    86811    0/1/1    W     0.02    0    0    0.0    0.00    0.00     89.18.166.89    example.com    GET / HTTP/1.0

9-0    86812    0/1/1    W     0.02    0    0    0.0    0.00    0.00     89.18.166.89    example.com    GET / HTTP/1.0

10-0    86813    0/1/1    W     0.02    0    0    0.0    0.00    0.00     89.18.166.89    example.com    GET / HTTP/1.0 

В данном случае атака идет пустыми запросами GET / к серверу example.com. Вам следует его отключить. Выполнить это лучше всего в панели управления: зайдя в раздел с сайтами, выбрать сайт (в данном случае example.com) и нажать сверху кнопку Файлы конфигурации, где вы увидите внизу конфигурационный файл nginx. Найдите отрывок такого вида:

server {

       listen       80;

       server_name  example.com www.example.com;

Пропишите ниже server_name строку

deny all;

Аналогично сделайте в секции, где указано listen 443;

Если у вас нет nginx, а только apache, то перейдите в корневую директорию сайта и создайте файл .htaccess с содержимым:

Deny from All

Теперь при обращении к сайту будет выдаваться ошибка 403 Forbidden, и нагрузка на остальные сайты значительно снизится.

Простой, но важный способ снижения нагрузки от атак

Как правило, флуд-боты обращаются по доменному имени, но могут перебирать и IP-адреса. В этом случае необходимо создать домен-заглушку. Но не забудьте для него в файлах конфигурации nginx указать deny all; (как в примере выше) или, если у вас только apache, в корневой директории заглушки добавить такой же файл .htaccess с содержимым:

Deny from All

Это не самый эффективный способ борьбы с атаками, но крайне полезный, так как он решает помимо этого много проблем с индексацией сайта, со сканом сайтов по IP-адресу и другие случаи. Однако далее мы рассмотрим уже целенаправленные способы фильтрации атак.

Защита от DDoS-атак

С помощью ISPmanager

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

Приступаем к настройке.

Заходим в ISPmanager — раздел «Сайты» (в старом меню это «Домены-WWW-домены») — выделить домен — кнопка «Изменить». Ищем подраздел «Оптимизация» и «защита от DDos» и ставим галочку «Включить защиту от DDoS-атаки» — следом появятся параметры защиты от атаки.

А именно:

«Количество запросов в секунду» — при достижении указанного количества подключений, IP блокируется только в Nginx.
«Максимальный размер всплеска» — при достижении указанного количества подключений, IP блокируется по всем портам на 5 минут.

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

Точечная блокировка в ISPmanager и блокировка по странам

Выше мы уже описывали варианты поиска источника нагрузки, когда атакующих IP-адресов немного. В этом случае их проще всего точечно заблокировать в панели ISPmanager в разделе «Администрирование» — «Брандмауэр», нажав кнопку «Создать» и указав адрес:

В этом же разделе есть возможность включить блокировку по определенным странам, нажав сверху кнопку «Страны». Стоит учитывать, что географическая привязанность IP-адресов всегда условна и может быть не точна. По этой причине для более-менее рабочей точности геораспределения адреса используются платные базы IP-адресов, в ISPmanager это работает именно так, и блокировка будет доступна, если вы зарегистрируетесь и приобретете ключ доступа к базам сервиса Maxmind:

Ручные настройки

Чтобы точечно зафильтровать 80 порт для ip xxx.xxx.xxx.xxx, используйте команду:

iptables -A INPUT -p tcp --src xxx.xxx.xxx.xxx --dport 80 -j DROP

Эти и последующие команды можно и нужно аналогично использовать и для 443-го порта.
Можно использовать ipset (нужен соответствующий модуль):

ipset -N ddos iphash

iptables -A INPUT -p tcp -m tcp --dport 80 -m set --set ddos src -j DROP

while true; do tail -10000 /var/www/httpd-logs/site.ru.access.log | sort | cut -f 1 -d " " | uniq -c | awk '($1>50){print $2}' | xargs -tl -I _ ipset -A ddos _;sleep 30; done

Закрываем icmp (поможет при icmp-flood):

iptables -A INPUT -p icmp -j DROP --icmp-type 8

Ограничение максимального числа «полуоткрытых» соединений с одного IP к конкретному порту (необходим соответствующий модуль):

iptables -I INPUT -p tcp --syn --dport 80 -m iplimit --iplimit-above 10 -j DROP

Ограничение максимального числа соединений с одного IP к конкретному порту:

/sbin/iptables  -A INPUT -p tcp --syn --dport 80 -m connlimit --connlimit-above 3 -j REJECT

Корректировка параметров apache

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

Откройте любым удобным текстовым редактором конфигурационный файл /etc/httpd/conf/httpd.conf (если Centos) и /etc/apache2/mods-available/mpm_prefork.conf (если Debian/Ubuntu):

<IfModule mpm_itk_module>

   StartServers          1

   MinSpareServers       1

   MaxSpareServers       1

   MaxClients          150

   MaxRequestsPerChild  100

</IfModule>

Измените MaxClients (максимальное число процессов) в меньшую сторону до количества процессов, которые не забивают ресурсы вашего сервера до отказа. Каждый процесс apache занимает в среднем 4-8 мегабайт памяти. А лучше узнать точно, сколько памяти в среднем на вашем сервере занимает один процесс apache/httpd так:

top -d 1 | grep -E 'http|apache' | awk '{a+=$7}END{print a/(1024*NR) " Mb"}'

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

Отредактируйте /etc/httpd/conf/httpd.conf (если Centos) и /etc/apache2/apache2.conf (если Debian/Ubuntu)

Следует уменьшить параметры:

Timeout 300

MaxKeepAliveRequests 100

до 60 и 50 соответственно, чтобы как можно скорее старые процессы apache прекращали свое существование.

Модули Nginx

Если панели ISPmanager нет, но используется веб-сервер nginx, проверьте, чтобы nginx был собран с модулями http limit req и GeoIP. С их помощью аналогичным образом, как в панели ISPmanager, только вручную в конфигурационных файлах, можно блокировать доступ для IP-адресов, превысивших ограничение на количество подключений. Также можно заблокировать и доступ по странам. Ввиду возможных особенностей ручных конфигураций, рекомендуем самостоятельно изучить документацию nginx по модулю HTTP limit req и GeoIP.

Переменные sysctl

Системные переменные, которые могут быть полезны, при DDoS.

ICMP-FLOOD

Команда ниже поможет при отражении атаки типа icmp-flood:

sysctl net.ipv4.icmp_echo_ignore_all=1

SYN-FLOOD

Уменьшает время удержания «полуоткрытых» соединений:

sysctl -w net.ipv4.tcp_synack_retries=1

Включает TCP syncookies:

sysctl -w net.ipv4.tcp_syncookies=1

Увеличивает размер очереди полуоткрытых соединений, по умолчанию — 512:

sysctl -w net.ipv4.tcp_max_syn_backlog=4096

Проверяет TCP-соединение каждую минуту. Если на другой стороне — легальная машина, она сразу ответит. По умолчанию — 2 часа:
sysctl -w net.ipv4.tcp_keepalive_time=60

Повторяет проверку через 20 секунд:

sysctl -w net.ipv4.tcp_keepalive_intvl=20

Количество проверок перед закрытием соединения:

sysctl -w net.ipv4.tcp_keepalive_probes=3

Изменяет время ожидания приема FIN:

sysctl -w net.ipv4.tcp_fin_timeout=10

Обратите внимание! Эти настройки будут работать до первой перезагрузки сервера, для постоянного использования параметры необходимо внести в системный конфиг sysctl.conf

Подключение DDoS-защиты

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

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

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

Если нужен сервис защиты, но бюджет не позволяет

Стоит упомянуть и еще один сервис, который допускает вариант бесплатной защиты от DDoS (как вы понимаете, «бесплатно» означает, что это будет не настолько же эффективно) — Cloudflare. 

Базово, на этом сервисе можно добавить свой домен, направив его на предоставляемые ими NS. Также по умолчанию, направив домен на их NS, в качестве А-записей на стороне Cloudflare предлагается указать «проксирующий» IP-адрес, который будет отдаваться по домену глобально и принимать на себя все запросы и пропускать их через фильтр бесплатной защиты. 

Помимо того, что более эффективная фильтрация будет платной, есть еще «узкое горлышко» в том, что сам VDS при наличии доменов с Cloudflare не избавляется от угрозы прямой атаки по IP-адресу. Как правило, IP-адрес скрывают, стараются, чтобы по доменам нигде не «светились» старые DNS-записи, ведущие сразу на IP-адрес VDS и т.д.

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

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

iptables -I INPUT -p tcp -m multiport --dports 80,443 -j DROP

ip6tables -I INPUT -p tcp -m multiport --dports 80,443 -j DROP

wget -O - https://www.cloudflare.com/ips-v4 | while read subnet; do iptables -I INPUT -s $subnet -j ACCEPT; done

wget -O - https://www.cloudflare.com/ips-v6 | while read subnet; do ip6tables -I INPUT -s $subnet -j ACCEPT; done

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

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