Защита сервера от ddos атак windows

По статистике, около 33% компаний попадают под DDoS-атаки. Предсказать атаку невозможно, а некоторые из них могут быть действительно мощными и достигать 300-500 Гб/с. Для того чтобы обезопасить себя от DDoS-атак можно воспользоваться услугами специализированных сервисов. Не все владельцы сайтов знают, куда бежать, если попал под атаку — так что я решил собрать несколько вариантов в одном топике.

Примечание: при подготовке к посту использовались англоязычные материалы и публикации на Хабре

Cloudflare

Один из самых известных защитных сервисов. При использовании тарифов FREE и PRO можно рассчитывать на базовую защиту от DDoS-атак. Для более надёжной защиты от атак уровней 3, 4 и 7 нужно подключить бизнес или корпоративный аккаунт.

В Cloudflare фиксированная оплата, то есть независимо от того сколько и каких уровней будут атаки, клиент платит одну и ту же сумму. Среди клиентов этого сервиса такие крупные компании, как Nasdaq, DigitalOcean, Cisco, Salesforce и Udacity.

Сеть Cloudflare представлена в 102 датацентрах с пропускной способностью более 10 Тбит/с и способна устранять любые атаки, а также отражать DNS и Smurf-атаки. У сервиса также есть круглосуточная служба экстренной помощи, куда можно обратиться во время атаки.

Incapsula

Этот сервис предлагает комплексную защиту от атак различных типов. Сервис может работать постоянно или по запросу и обнаруживать любые атаки. Сеть Incapsula состоит из 32 дата-центров с пропускной способностью в 3 Тбит/с. У Incapsula есть пробная версия для бизнеса c SSL протоколом, CDN и WAF, которая защитит от DDoS-атак.

На случай, если атака уже совершена и счёт идёт на минуты, можно воспользоваться сервисом экстренной помощи Under Attaсk.

Akamai

Этот сервис один из лидеров в сфере обеспечения безопасности и CDN. По заявоениям руководства Akamai, сервис может справиться с атакой в 1,3 терабита в секунду.

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

Qrator

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

Кроме того, даже при необходимости отражения атаки на уровне приложений (7 уровень модели OSI) не требуется тонкой настройки продукта — при обнаружении атаки система перейдет в нужный режим автоматически.

Для подключения защиты Qrator нужно изменить A-запись сайта. К недостаткам можно отнести достаточно высокую стоимость использования продукта, но компания предоставляет SLA (если уровень услуги не обеспечен, платить не обязательно) и бесплатный тестовый период в семь суток.

AWS Shield Advanced

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

Все эти службы защиты от DDoS-атак предназначены для блоггеров, электронной коммерции, малого и среднего бизнеса. Для бизнеса более крупных масштабов существуют другие сервисы, с более высоким уровнем защиты и большим функционалом. Вот некоторые из них: Сети ARBOR, Neustar, Rackspace, Akamai, F5 Silverline и Radware.

King Servers Anti DDoS

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

Компания дает гарантию безопасности от SYN Flood, UDP/ICMP Flood, HTTP/HTTPS-атак, фильтрацию грязного трафика до 1 ТБит/с — чистый трафик выделяется и направляется на сайт пользователя. Пользователям не нужно самим заниматься настройками, эту задачу берет на себя круглосуточная служба поддержки, которая отрабатывает и заявки на кастомизацию сервиса.

BeeThink Anti-DDoS Guardian

Этот инструмент защищает серверы Windows от большинства DoS и DDoS-атак: SYN, IP flood, TCP flood, UDP flood, ICMP flood, HTTP-DDoS, атак 7 уровня и многих других.

Сервис BeeThink совместим с Windows 10, Windows 8, Windows 7, Windows 2016, Windows 2012, Windows 2008, Windows 2003, Windows 2000, Windows XP и Vista.

Помимо защиты от DDoS-атак сервис в режиме реального времени проводит мониторинг сетевых операций, поддерживает разные форматы IP-адресов, поддерживает black и white листы, ищет удалённые IP-адреса и информацию о их владельцах. Базовый тариф стоит $99,95.

Sucuri

Этот сервис предоставляет защиту для любых сайтов: WordPress, Joomla, Drupal, Magento, Microsoft.Net и других.

Sucuri предоставляет антивирус и межсетевой экран для сайтов, в которые включена защита от DDoS. Также сервис обнаруживает и удаляет вредоносные программы, повышает производительность сайтов, защищает от брутфорс-атак и защищает от ботов. Минимальная стоимость месячного тарифа — $19,88.

Cloudbric

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

Разработчики гарантируют защиту от всех кибератак. Среди клиентов сервиса такие крупные компании, как Samsung, ING и eBay.

Стоимость использования зависит от объёма трафика, так за 10 Гб придётся заплатить $29, а за 100 Гб $149. Если объём трафика не превышает 4 Гб, сервисом можно пользоваться бесплатно.

Alibaba Anti-DDoS

Сервис китайского гиганта интернет-коммерции поможет справиться с атаками до 2 Тбит/с и поддерживает все протоколы: TCP, UDP, HTTP, HTTPS.

Сервис можно использовать не только для защиты сайтов, расположенных на хостинге Alibaba, но и размещённых на AWS, Azure, Google Cloud и других.

Также Anti-DDos Pro работает круглосуточно и в случае проблем, можно обратиться в службу поддержки к экспертам по безопасности.

StormWall Pro

Этот инструмент защищает от любых уровней DDoS-атак и поддерживает сайты на платформах Drupal, Joomla, WordPress, Bitrix, Magento, PrestaShop и других CMS.

Датацентры StormWall расположены в США, России и Европе и работают с минимальной задержкой. Настройка системы займёт всего несколько минут, а в случае трудностей, это могут сделать менеджеры компании. Любая техническая проблема, которая может возникнуть в течение работы, будет решена в короткие сроки — ответа техподдержки придётся ждать не дольше 15 минут.

Стоимость использования сервиса зависит от количества посетителей сайта. Так, за $69 можно обеспечить защиту сайта с 5000 посетителей в месяц, а за $300 купить безлимит.

Myra

Сервис Myra DDoS полностью автоматизирован и предназначен для защиты сайта, DNS-серверов и веб-приложений. Система подходит для всех типов CMS и интернет-магазинов.

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

---

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

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-атак.

Здравствуйте. Это снова Антон Чигарёв, и мы продолжаем серию заметок начинающего системного администратора. В прошлый раз я рассказывал о создании интернет-радио, а сегодня поделюсь советами, как защитить сервер от DoS-атак.

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

Эта статья – обзор механизмов защиты, с каждым из которых вы можете ближе познакомиться в материалах по приведённым мною ссылкам. Поскольку большинство серверов работает под управлением Linux, в тексте я ориентируюсь именно на эти системы.

Речь пойдёт прежде всего о бесплатных инструментах. Многие хостинг-провайдеры предлагают защиту от DoS как услугу. За 100-300 рублей в месяц они проверяют пакеты «на подступах» к вашему серверу и отсекают нежелательный трафик. Для коммерческого проекта такие затраты оправданы, а если сайт пока не приносит прибыли – попробуйте сначала защититься методами, о которых я расскажу ниже.

Сам я уже около года использую межсетевой экран ConfigServer Security Firewall (CSF), который успешно выявляет и пресекает нежелательную активность пользователей.

Способы защиты

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

1. Вы оставляете открытыми только нужные порты, а остальные закрываете. Это делается, чтобы злой хакер не проник в систему после простого сканирования портов.
2. Файервол следит за открытыми портами по указанным протоколам и блокирует отправителей, которые присылают серверу больше пакетов, чем вы позволили при конфигурации. Вы можете настроить время блокировки, но учтите, что по истечении этого периода преступник снова сможет присылать лишние пакеты.
3. При обнаружении нежелательной активности вы, администратор, получаете электронное письмо с уведомлением о происшествии и IP-адресом злоумышленника.

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

Инструменты

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

Сам по себе встроенный межсетевой экран сложен в настройке, но зато мы можем использовать его в связке с более понятными дополнительными файерволами. Один из них – CSF. У этого решения множество параметров, которые легко «подкрутить» как вам нужно в файле csf.conf. Либо вы можете поставить APF-firewall и к нему – скрипт DoS-deflate. Есть и другие аналогичные решения.

IPTables

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

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

• ACCEPT – принять пакет и пропустить дальше.
• DROP – отбросить пакет и не пропускать.

Подробное и понятное русскоязычное руководство по IPTables вы найдёте на сайте ITproffi.

При работе с этим софтом нужно быть внимательным, понимать, что и для чего вы делаете. Иначе легко закрыть доступ к серверу вообще всем и даже самому себе. В этом случае сервер придётся перезагружать через панель управления.

Важно! IPTables хранит правила только до перезагрузки системы. Чтобы сохранить правила насовсем, нужно установить одну из дополнительных утилит. В сети на этот счёт есть готовые инструкции.

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

Знакомимся с CSF 

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

По личному опыту могу сказать, что CSF действительно избавляет администратора от лишней возни и проблем с IPTables. Главное – быть внимательным и проверять, что вы вносите в конфиг.

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

Ставим серверный файервол 

Перед установкой межсетевого экрана необходимо установить два компонента, без которых ничего работать не будет. Это интерпретатор Perl и библиотека Library World Wide Web, сокращённо – libwww.

apt-get install -y libwww-perl

Теперь можно браться за ConfigServer Security Firewall. В официальном репозитории он отсутствует, поэтому скачиваем его по ссылке. Или сразу грузим архив к себе на сервер:

cd /usr/src

wget https://download.configserver.com/csf.tgz

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

tar xzf csf.tgz

cd csf

Дальше запускаем установку программы и проверяем, всё ли у нас впорядке с зависимостями – на месте ли необходимые компоненты.

sh install.sh

perl /usr/local/csf/bin/csftest.pl

В результате мы должны получить следующее: 

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

Настройка

После установки утилиты можно сразу переходить к настройке защиты. Файл конфигурации лежит здесь: /etc/csf/csf.conf. Откройте его.

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

Перевести CSF в рабочий режим очень просто  – надо в тексте конфига изменить значение флага TESTING на 0.

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

Для начала пропишем входящие порты. Указывать их надо в кавычках и через запятую:

TCP_IN = «20,21,22,25,53,80,110,143,443,465,587,993,995,10333,127015»

Теперь – исходящие:

TCP_OUT = «20,21,22,25,53,80,110,113,443,587,993,995,10333»

Если вы хотите задать диапазон портов, границы диапазона обозначайте при помощи  двоеточия. Например: 40000:55000,10335.

В блоке «EMAIL_ALERT» файла конфигурации вы можете настроить почтовые оповещения. Например, давайте установим оповещение о том, что кто-то подключился к ssh: 

LF_SSH_EMAIL_ALERT = «1»

Теперь, если кто-нибудь подключится к ssh, мы получим уведомление на почту. Кстати о почте! CSF – мощный и крутой защитник, но он не волшебник и не знает вашего электронного адреса, пока вы не укажете его в блоке «LF_ALERT_TO».

Пора сохранить все изменения и написать в терминале следующее:

systemctl restart {csf,lfd}

csf -r

Обратите внимание на команды csf -r и csf -f. Нужны они, чтобы перезагружать и останавливать выполнение правил. А когда вам нужно просмотреть цепочку правил, используйте команду csf -l.

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

csf -a 192.168.0.6

Когда нужно запретить подключение к серверу кому-то конкретно, можно воспользоваться командой: 

csf -d 192.168.0.7

А удалить все правила, связанные с заданным IP, можно с помощью команды:

csf -ar 192.168.0.6

Удалить все запрещающие правила, связанные с конкретным адресом, можно вот так:

csf -dr 192.168.0.7

Заключение 

Собственно, мы установили CSF и немного настроили его. Если у вас будет желание детальнее разобрать параметры инструмента, внимательно просмотрите файл конфигурации – там вы найдёте подробные комментарии на английском языке. Каким из возможных вариантов настройки пользоваться – решать вам. Главное, что у вас есть выбор.

А я пока прощаюсь с вами до следующей статьи, жду ваших комментариев и вопросов. 

Хотите свободно работать с Debian и другими дистрибутивами Linux? Приходите учиться на профессию «системный администратор», и через 9 месяцев вы не только освоите Linux, но и сможете обеспечивать бесперебойную работу компьютерной техники и ПО в любой организации! А если вас интересует защита IT-систем — приглашаем на факультет информационной безопасности!

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

1. Введение
2. Основа основ — защищаемость
3. Первый шаг имеет значение
4. Особые требования — к обработке персональных и финансовых данных
5. Не все сервисы защиты одинаково полезны
6. Чего нельзя позволять атакующему
7. Не оставляйте «грабли»!
8. Самые сложные проблемы — те, что заложены изначально
9. Ещё раз о защищаемости
10. Золотые правила DDoS-защиты
11. Выводы

Введение

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

В июне Anti-Malware.ru собрал оценки зарегистрированного уровня DDoS-атак, зафиксированных в первом квартале 2022 года, в статье «Развенчиваем мифы: DDoS-атаки в первом квартале 2022 г. были аномально сильными». Стоит отметить их постоянно растущую мощность — полтора месяца назад Cloudflare зафиксировала атаку мощностью 26 млн запросов в секунду, — а также длительность: II квартал побил рекорд по длительности DDoS (по данным Kaspersky).

Основа основ — защищаемость

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

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

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

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

1. Предоставить как можно меньше информации о ресурсе атакующему: для злоумышленника ваш ресурс должен быть в максимальной степени «чёрным ящиком».
2. Предоставить как можно больше информации провайдеру DDoS-защиты, чтобы он ясно представлял, что именно надо защищать, какие особенности имеются у ваших ресурсов и пр.
3. Обеспечить понятные провайдеру возможности для фильтрации атаки (особенно это касается защиты приложений).
4. Обеспечить надёжную и устойчивую работу ресурса во время атаки. Нужно, во-первых, понимать, что удар может прийтись на незащищённые по каким-то причинам компоненты ресурса. И, во-вторых, всегда нужно учитывать, что часть атаки, пусть и небольшая, может пробиться сквозь DDoS-защиту и существенно повысить нагрузку на ресурс.

Первый шаг имеет значение

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

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

Также надо определить, какая именно защита требуется вашим ресурсам: достаточно ли фильтровать пакеты сетевого (L3 по модели OSI) и транспортного (L4) уровней, нужен ли анализ трафика на уровне приложений (L7), передаваемого по протоколам HTTP / HTTPS или «поверх» них, какие ресурсы можно защитить с раскрытием приватных ключей SSL, а какие нельзя.

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

И вот пример того, к чему может привести недостаточная проработка этих потребностей. Один из наших клиентов подключил сервисы Anti-DDoS не только от крупного международного поставщика, но и от своего интернет-провайдера, однако эти сервисы не смогли обезопасить компанию от DDoS-атак минувшей весной. Когда мы стали разбираться, на каких уровнях осуществляется защита, то выяснилось, что защита от пакетного флуда на уровнях L3 и L4 есть, а от атак на уровне L7 её нет — что как раз и стало причиной недоступности интернет-приложений, оказавшихся целью атаки.

Особые требования — к обработке персональных и финансовых данных

Если ваш ресурс представляет собой финансовый сервис или приложение обеспечивающее обмен конфиденциальными (например, персональными) данными, то, скорее всего, придётся использовать защиту без раскрытия приватных ключей SSL. В частности, она требуется для систем, которые должны соответствовать международному стандарту платёжных систем PCI DSS.

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

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

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

Не все сервисы защиты одинаково полезны

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

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

Схожая картина наблюдается и в ситуациях, когда оператор коммерческого дата-центра, облачный или интернет-провайдер перепродаёт сервисы защиты своего партнёра — провайдера Anti-DDoS. В принципе в этом нет ничего плохого. Вопрос — в том, какого качества и объёма поддержка при этом будет предоставляться в случае атаки: будет ли у вас прямая связь с провайдером сервисов Anti-DDoS и его службой поддержки и есть ли у хостера или интернет-провайдера, который непосредственно продаёт сервисы Anti-DDoS, собственные специалисты по защите от DDoS-атак.

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

Не все провайдеры Anti-DDoS предоставляют и доступ к настройкам защиты, а у тех, кто предоставляет, возможности этих настроек могут варьироваться в широком диапазоне. Полезно узнать и затем проверить в ходе тестирования, какова мощность системы фильтрации этого провайдера — 100, 200, 600 Гбит/с или какая-то иная: это поможет оценить, способны ли сами фильтры устоять в случае атаки с серьёзной мощностью.

Очень важно понять, какую именно защиту предлагает конкретный провайдер. Часто (особенно, если защита идёт как дополнение к интернет-услуге) это защита на уровнях L3 / L4 модели OSI. Но она в принципе неспособна обезопасить сайты и приложения от атак с применением HTML-ботов. Если атака запускается с нескольких компьютеров, то на пакетном уровне можно выявить некую аномальную активность, которую нужно отфильтровать. Однако если число атакующих ботов исчисляется тысячами (такие ботнеты можно арендовать буквально за гроши), то никакая защита уровня L3 / L4 такую атаку не отфильтрует. Впрочем, и не должна. Для отражения таких атак требуется полновесная защита уровня L7, позволяющая анализировать каждый HTTP-запрос, проводить дополнительные проверки, изучать системные журналы, исследовать их и выяснять, какие именно идут запросы, какого рода активность наблюдается, делать выводы и на их основе принимать решения.

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

Очень важно также понять, какие возможности предоставляет провайдер Anti-DDoS для оперативной связи с клиентами: есть ли у его службы технической поддержки телефон, чат, система приёма заявок (тикетов) или иные каналы, через которые можно задать вопрос и быстро получить ответ. Это тоже очень важно, поскольку самое ужасное, что может произойти во время DDoS-атаки, — это долгое, многочасовое, а то и многодневное (если, например, атака случилась вечером накануне выходных) ожидание ответа.

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

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

Также стресс-тестирование поможет оценить устойчивость вашего ресурса в случае слабой DDoS-атаки. Не факт, что провайдер сможет отфильтровать все 100 % нелегитимного трафика. И если он отсечёт 99 %, то оставшийся 1 % от мощной атаки легко сможет сделать недоступным ваш ресурс, если тот не обладает достаточной производительностью и неспособен обработать нелегитимный трафик.

Чего нельзя позволять атакующему

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

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

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

Если у вас есть своя собственная автономная система, свой префикс, если вы используете BGP, то эту сеть тоже надо защищать. DDoS-атака может обрушиться на незащищённый IP-адрес, и даже межсетевой экран (firewall) и ACL-фильтр не спасут от атаки на него мощностью, например, в 400 Гбит/с. Это вполне реальная угроза! В конце прошлого и начале нынешнего года специалисты StormWall практически каждый день наблюдали вредоносные потоки данных мощностью в 1,2 Тбит/с. Такая атака способна создать чрезмерную нагрузку не только на ваш ресурс, но и на всю сеть вашего провайдера. Поэтому если у вас используется протокол BGP, то надо подключить и защиту через BGP.

Конечно, надо учесть возможность атак на DNS. Обязательно нужно оценить, насколько защищены и насколько надёжно работают сервисы DNS, к которым подключены ваши ресурсы. Когда во время массированных атак, имевших место минувшей весной, крупный российский регистратор доменных имён стал работать нестабильно, многие его клиенты сильно пожалели о том, что не предусмотрели подключения к другому сервису DNS, надёжно защищённому от DDoS-атак. Подобные сервисы предоставляют и провайдеры Anti-DDoS, и компании специализирующиеся на предоставлении сервисов DNS. Лучше всего подключиться как минимум к двум поставщикам DNS-сервисов. И весьма желательно, чтобы провайдеры хотя бы двух таких сервисов обеспечивали их DDoS-защиту.

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

Отметим, что StormWall использует множество методов фильтрации трафика DNS на уровне приложений, начиная с простых ограничений по числу запросов к домену, запросов с IP-адреса и т. д. и заканчивая преобразованием DNS-трафика в трафик TCP и другими методами, специфичными именно для DNS-серверов.

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

Не оставляйте «грабли»!

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

Вот пример, демонстрирующий необходимость быть очень осторожными с обращением к интернет-ресурсам напрямую по их IP-адресам, минуя DNS. Атака на одного из наших клиентов пришлась на один из IP-адресов, к которому приложения клиента обращались не через доменное имя, а напрямую. Заменить такой адрес крайне сложно, поскольку он жёстко «прошит» в приложениях. И защитить его во время DDoS-атаки практически невозможно, поскольку для этого пришлось бы уговаривать поставщика этого арендованного IP-адреса обезопасить всю его сеть /24 (а это 256 адресов) с использованием сервисов Anti-DDoS. Однако наверняка провайдер не станет этого делать в спешке.

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

У некоторых клиентов обнаружились устаревшие системы, которые не поддерживали протокол SNI (расширение компьютерного протокола TLS) и не передавали в заголовках IP-адрес HTTP-хоста, на который отправляется запрос. Эту проблему также можно решить, но, опять-таки, нужно уделить ей время.

Ещё одна «хрестоматийная» проблема: нередко на границе сети стоит устройство (например, маршрутизатор, межсетевой экран или балансировщик) с низкой производительностью. Очень часто среди таких устройств встречаются межсетевые экраны Cisco ASA и маршрутизаторы MikroTik — они вполне справляются с обычной нагрузкой, но не могут «переварить» даже слабый флуд, блокируя любую проходящую через них сетевую связность. В случае атаки процессор устройства получает стопроцентную загрузку, поэтому понять, что происходит с устройством, во время атаки практически нереально. Если же на этих устройствах работает фильтрация на основе технологии SPI (Stateful Packet Inspection, инспекция пакетов с хранением состояния), то положение усугубляется ещё больше.

Не так просто бывает разрешить ситуации, когда клиент использует защиту от DDoS-атак, которая предложена его транзитным провайдером, поскольку она может сработать в непредсказуемый момент. Один из клиентов применял upstream-маршрутизацию и DDoS-защиту, предоставляемые одним из сотовых операторов «большой четвёрки». В какой-то момент клиент решил отказаться от его сервисов защиты и перейти на наши. Один из наших upstream-каналов проходит также через сеть этого оператора: через неё трафик поступает на фильтры StormWall, а затем уже очищенный передаётся клиентам. Если начинается даже слабая атака, оператор её фиксирует (поскольку у провайдера остались прежние настройки) и начинает перехват (hijacking) трафика на IP-адрес /32, который «закольцовывается» и никуда не уходит. В итоге у клиента становится недоступным банковское приложение. Решение этой проблемы оказалось очень простым: нужно было лишь попросить оператора отключить DDoS-защиту для этого клиента. Поскольку с подобной проблемой уже столкнулись несколько организаций, можно предположить, что она будет достаточно распространённой и в дальнейшем, поскольку сейчас многие операторы и провайдеры на том или ином уровне предоставляют услуги DDoS-защиты.

Самые сложные проблемы — те, что заложены изначально

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

Приведём пример — типичный, но далеко не исчерпывающий весь спектр ошибок, связанных с проектированием программных продуктов. На приложение дистанционного банковского обслуживания (ДБО) одного из банков, на которое обычно приходит в среднем 500 запросов в секунду, вдруг накатилась мощная волна запросов — порядка 10 тыс. в секунду, причём с каждого IP-адреса источника приходило по 200 запросов в секунду, и все они получали от приложения ответ 401 Unauthorized («отказ в доступе»). Подозревая начало атаки, мы стали блокировать запросы. Неожиданно банк обратился к нам с вопросом о том, почему вдруг заблокированы легитимные посетители. Пытаясь разобраться в ситуации, мы связались с разработчиками, и они нам объяснили: приложение начало выгрузку и эту волну запросов следует расценивать как нормальное поведение. Мы удивились: если такое поведение считается нормальным, то как может выглядеть атака на это приложение? И как нам отличить нормальную активность от инициированной злоумышленниками, если приложение никак себя не обозначает — ни какими-либо особыми методами, ни локациями, ни заголовками, и что делать, если трафик от этого приложения ДБО ничем не отличается от трафика, который генерировал бы бот?

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

Нам также довелось встречать великое множество других ошибок, сделанных ещё на стадии проектирования приложений и сервисов, из-за которых программные продукты получались плохо защищаемыми и на снижение их уязвимости к DDoS-атакам требовалось много денег, времени и усилий. Решение проблемы понятно: заказчики и разработчики приложений должны уже на самых ранних стадиях создания продуктов привлекать к своим проектам специалистов по информационной безопасности (ИБ), в том числе по DDoS-защите. Индустрия ИБ твердит об этом уже не один десяток лет…

Ещё раз о защищаемости

Напоследок ещё раз опишем основные задачи по обеспечению защищаемости, но более развёрнуто, в расчёте на специалистов.

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

Во-вторых, предоставить как можно больше информации провайдеру DDoS-защиты. Он должен ясно понимать архитектуру ваших ресурсов и правила, по которым они взаимодействуют между собой и со внешними ресурсами. Также он должен знать, какие сервисы (сайт, DNS, VPN и пр.) на каких IP-адресах находятся, и иметь возможность распознавать, насколько штатно работают ваши ресурсы в тот или иной момент. Если у вас есть UDP-приложения, то нужно рассказать, где и как они развёрнуты, что и как делают.

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

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

Нередко сложности возникают и в защите UDP-приложений, поскольку фильтровать UDP-трафик сложнее, чем TCP-трафик. Чтобы точнее определять, является ли очередной пользователь такого приложения легитимным, провайдеру Anti-DDoS необходимо ясно понимать применяемый протокол взаимодействия с клиентами. Возможно, для оценки легитимности у вас предусмотрена процедура предварительной авторизации. Или, другой вариант, имеются чёткие правила взаимодействия с легитимными клиентами, по которым фильтр трафика сможет определить, что данный клиент легитимен. Иногда оценить легитимность удаётся с помощью какого-нибудь TCP­-сервиса.

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

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

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

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

Кроме того, надо обеспечить резервирование мощностей и добиться устойчивости ресурса к слабым атакам. Это особенно важно при использовании асимметричной защиты. Как мы уже говорили, при фильтрации некоторых типов DDoS-атак часть трафика «пролетает» насквозь. И если идёт мощная атака, например, в 40 Гбит/с, то отсекание 99 % нелегитимного трафика приведёт к тому, что на защищаемый ресурс обрушится DDoS-воздействие мощностью 400 Мбит/c. Сможет ли он его выдержать — большой вопрос. Чтобы это было возможным, ваш маршрутизатор, межсетевой экран и сервер должны обладать достаточно высокой производительностью.

Кстати, более качественно настроить правила защиты помогает разнесение разных функций и сервисов ресурса по разным IP-адресам: сайты и HTTP-приложения — на одних, UDP-приложения — на других, сервисы обеспечивающие Pull-схему — на третьих, и так далее. Неиспользуемые сетевые сервисы лучше вообще заблокировать, чтобы пресечь возможность DDoS-атак на них.

Золотые правила DDoS-защиты

Напоследок приведём три простых правила, которые помогут вам выстроить надёжную линию обороны от DDoS-атак.

1. Обращайтесь за консультациями к компетентным провайдерам Anti-DDoS, которые помогут принять правильные решения по организации защиты вашей инфраструктуры. Это позволит заметно снизить ваши бизнес-риски.
2. Постарайтесь начать обсуждение мер по защите от DDoS-рисков как можно раньше — лучше всего на стадии проектирования ваших будущих систем и приложений. Это поможет обеспечить устойчивость ваших ресурсов к DDoS-атакам.
3. Гармонично встраивайте защиту от DDoS-рисков в общую стратегию информационной безопасности вашей организации. Очень многие принципы, которые выработала отрасль ИБ, замечательно работают и в отношении DDoS-защиты. Но, конечно, есть у неё и своя специфика, связанная с особенностями DDoS-рисков.

Выводы

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

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

Многие популярные ресурсы подвергаются DDoS-атакам с той или иной целью.

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

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

Понятие

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

В итоге учитель сдавался, так и не начав новую тему. ДоС мало чем отличается от этой элементарной схемы.

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

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

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

Как организовать

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

Во втором случае владельцы ПК не всегда догадаются, чем занята их машина в данный момент.

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

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

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

Рис. 2 – Как защититься от атаки

Защититься от DDoS на 100% не может никто и нигде, ведь любой программный код имеет свои недостатки, плюс его можно взломать.

Да и человеческий фактор в таком случае играет далеко не второстепенную роль: правильная настройка оборудования и программного обеспечения – залог успешной работы.

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

Второй и менее распространённый алгоритм – приглашение добровольцев для участия в массированной отправке запросов на указанный сервер через специальное программное обеспечение.

Третья разновидность таких кибепреступных действий – размещение ссылок на целевой ресурс на крупных порталах (новостных). Из-за стремительного наплыва юзеров сервер не выдерживает нагрузки и «падает».

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

Рис. 3 – Распространённые типы атак

Причины

Специалисты в области компьютерной безопасности выделяют несколько факторов, провоцирующих DDoS:

• Самообразование, развлечение – начинающие взломщики могут попытаться навредить небольшому ресурсу с целью попрактиковаться в организации DDoS или проверить свои силы на деле.
• Личные мотивы – может быть местью кому-либо или какой-нибудь организации, например, после облав на группы хакеров веб-узлы американской спецслужбы ФБР и некоторых правительственных ведомств несколько недель не функционировали.

Схожими были и последствия блокировки крупного украинского файлообменника ex.ua.

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

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

• Финансовая выгода – злоумышленник требует определённую пользу от владельца веб-ресурса, как правило, финансовую. Такими поступками известны группы ezBTC и RedDoor.

Разновидности

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

1. Переполнение интернет-канала или флуд.

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

2. SYN-флуд – переполнение вычислительных возможностей системы ложными запросами. После установки соединения система под каждый запрос выделяет определённое количество физических ресурсов сервера.

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

3. Захват аппаратных ресурсов – схож с предыдущим типом, его цель – загрузить центральный процессор жертвы на 100%.

Рис. 4 – Уровни модели OSI

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

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

5. Smurf-атака. Самый серьёзный алгоритм ввиду большой вероятности того, что в обслуживании атакованной машины будет отказано.

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

Рис. 5 – Smurf — самая мощная атака

6. UDP-флуд – Жертве посылаются echo-команды, IP атакующего изменяется на адрес атакованного, который вынужден принимать собственные запросы в большом количестве и так до занятия ложными ответами всей полосы.

7. Переполнение вычислительных мощностей – посылание запросов, которые для обработки требуют много процессорного времени. Когда ЦП будет загружен на 100%, пользователи доступ к сайту не получат.

8. Переполнение HDD лог-файлами. Мы говорили о влиянии квалификации системного администратора на возможность осуществления атаки на серверы, которые тот обслуживает. Если неопытный человек не установит определённые лимиты на размер лог-файла или количество записей в нём, протоколирование многочисленных запросов займет всё дисковое пространство и выведет сервер из строя.

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

10. Атаки на кэш – подмена IP DNS-сервера на адрес жертвы. Запрос приводит не на страницу атакованного ресурса, а на сайт злоумышленника. При наличии огромного количества зомби-компьютеров они насыщают DNS-сервер запросами, ввиду чего тот не справляется с преобразованием IP в доменные имена.

При правильной конфигурации DNS вероятность успешной атаки опускается до ноля.

11. Layer 7 – на запрос сервер должен отправить тяжелый пакет, например, архив или pdf-файл.

Существуют платные ресурсы для осуществления киберпреступлений, как vDOS.

Он предоставляет услуги всем, не спрашивая имени пользователя и цели эксплуатации сервиса.

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

Разберёмся, как это делается.

Определяем DDos

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

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

Рис. 6 – Архитектура

По статистике Akamai, более половины ботнетов и инициаторов DDoS располагаются в Китае и Соединённых Штатах.

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

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

Такие люди помогут выполнить пару манипуляций в настройках для отражения атаки. Средства их выявления относятся к нескольким категориям:

• статистика – изучение активности пользователей на ресурсе;
• сигнатуры – качественный анализ входящего и исходящего трафика;
• комбинация первой и второй.

Защита: общие понятия

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

Да и то, порой лишь снизят эффективность атаки. Закрытие дыр в программном коде – более эффективная мера борьбы с зомби-компьютерами и сетями ботнетов.

И оставлять её на потом ни в коем случае не нужно.

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

Выигрываем время

В зависимости от типа злодеяния различают разные алгоритмы предотвращения прерывания обслуживания.

• Для предотвращения HTTP-флуда повышаем число одновременных соединений с базой, а если атака развивается, сбрасываем эти соединения.
• ICMP-флуд – отключаем ответы на ICMP ECHO запросы.
• UDP-флуд – также отключаем данный вид запросов или ограничиваем их допустимое количество.
• SYN-флуд – если определили его наличие, уменьшаем очередь полуоткрытых соединений TCP до 1-3-х.

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

Рис. 7 – Как происходит ДДоС

Советы

• Своевременное обновление ПО на сервере и движка сайта.
• Наличие плана реагирования на появление внештатной ситуации.
• Учёт вероятности DDoS ещё на стадии написания/заказа программного кода, его тщательное тестирование.
• Отсутствие доступа к интерфейсу администрирования с внешней сети.
• Эксплуатация тестов на проникновение и критические проблемы OWASP Top 10 Vulnerability.
• Если аппаратные средства обеспечения безопасности недоступны, предусмотрите услугу программной защиты по требованию путём внесения корректировок в схему маршрутизации.
• Эксплуатация сетей доставки контента CDN. Они позволяют распределить трафик между несколькими серверами для уменьшения таймингов и повышения скорости доступа.
• Установка файрвола Web Application Firewall на веб-приложения, который будет мониторить трафик, приходящий на сайт, и проверять его подлинность, что с большой вероятностью исключит ложные запросы.
• Не используем Apache. При эксплуатации Апачи устанавливайте кэширующий прокси nginx, но и он не спасёт от Slowloris – самого опасного способа DDoS. Лучше остановитесь на защищенном HTTPS-сервере.
• Воздействие на источник проблемы. Если знаете обидчика, посредством законодательства или иных рычагов давления вынудите его прекратить противозаконные действия. Для этого даже специальные фирмы существуют.

Безопасность DNS

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

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

В общем случае доступны следующие методы.

1. Регулярная проверка серверов на наличие подозрительной активности. Коммерческие решения, вроде BIND, открывают доступ к статистике в реальном времени. Такие процедуры очень ресурсоёмкие, поэтому рекомендуется создать базовый профиль при нормальной нагрузке и сравнивать его с текущей в критические моменты.

2. Активация Response Rate Limiting снизит быстроту ответа на повторяющиеся запросы.

3. Развёртывание DNS на сервере HL (высокой доступности). После падения первого активируется второй.

Рис. 8 – Принцип защиты DNS

Приведённые способы требуют вложения ресурсов, в первую очередь финансовых, и подходят не для всех случаев.

На практике более эффективно себя зарекомендовало использование распределённых сетей DNS посредством Anycast либо Unicast.

• Anycast более надёжный за счёт использования общего IP.
• При Unicast все серверы получают уникальные IP. За счёт этого смягчается нагрузка: после заполнения одного сервера подключается второй.

Инструменты провайдера

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

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

Действенные меры

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

Долой Windows

Самая распространённая платформа является и наиболее уязвимой. Когда число запросов растёт, Windows Server непременно начинает тормозить.

Останавливайтесь на решениях, которые работают на ядре Linux. Хакеры не столь прониклись знаниями об этой платформе.

Основным инструментом для прерывания атаки являются консольные утилиты iptables и ipset. C их помощью боты легко отправляются в бан.

Модуль testcookie

Одним из наиболее быстрых и эффективных рецептов вернуть сайт к нормальному состоянию является модуль testcookie-nginx, способный предотвратить простые атаки, разработанные начинающими программистами на C#/Java.

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

Хотя в последнее время и они эволюционируют, а потому борорьба с такими программами становится сложнее.

Модуль отслеживает мусорные запросы, ведь тело бота почти никогда (но случаи становятся всё более частыми) не несёт в себе движка JavaScript. Он становится фильтром в случае атаки Layer 7.

Модуль проверяет:

• действительно ли бот является браузером, за который себя выдаёт:
• на самом ли деле он поддерживает JS;
• умеет ли тот переадресовывать.

Рис. 9 – Алгоритм работы testcookies

Способов проверки несколько и для их всех задействуются cookies, которые в последней версии еще и шифруются посредством AES-128 при необходимости. Также cookies может инсталлироваться через Flash, который боты не поддерживают.

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

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

С недостатков testcookie обладает следующими:

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

Временное отключение функций

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

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

Географическое положение

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

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

Точность определения геометок, бан пользователей, работающих через VPN и прочие недостатки – временная плата за работоспособность сайта в дальнейшем.

Отладчик

Использование профайлера Xdebug позволит увидеть самые тяжелые запросы.

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

Блокирование подозрительного трафика

Используем межсетевой экран или ACL списки для блокировки подозрительного трафика.

Такое программное обеспечение способно закрыть доступ к сайту определённым категориям запросов, но отделить реальный трафик от «плохого» не в силах.

Обратная DDoS атака

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

Часто такой процесс позволяет прекратить нападки и даже загрузить сервер атакующего до его вывода из строя.

Сервисы

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

В таких ситуациях финансовые вложения в стабильное функционирование ресурса, как правило, окупаются с лихвой.

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

Akamai

https://www.akamai.com/

После приобретения Prolexic, которая работала в сфере защиты от DDoS, компания стала лидером рынка средств для поиска уязвимостей веб-ресурсов.

Совмещение двух технологий предоставляет гарантированную безопасность любого сайта.

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

Рис. 10 – Akamai

Arbor

www.arbornetworks.com/ddos-protection-products

Предоставляет высококлассную защиту от ДДоС для дата-центров программным и аппаратным путём, причем всё оборудование монтируется специалистами фирмы у заказчика.

Благодаря сервису облачной фильтрации трафика с возможность выбора пропускной способности сети/сайта Arbor – одно из наиболее популярных решений на рынке России.

Особенности:

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

Cloudflare

https://www.cloudflare.com/ddos/

Распространяется в двух пакетах: базовый и профи, однако для комплексных мер в сфере бизнеса придётся приобрести расширенные пакет, функционирующий на трёх (3,4,7) уровнях базовой модели.

Из достоинств: фиксированная цена за весь период эксплуатации, каким бы мощным ни было нашествие ботов.

Рис. 11 – Логотип Cloudflare

Услугами Cloudflare пользуются такие гиганты, как Cisco, Microsoft.

Особенности:

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

Radware

www.radware.com/Products/DefensePro/

Разработчик сетевого оборудования для защиты сайтов и прочих сетевых ресурсов. Также компания предоставляет услуги информационной безопасности, в первую очередь от DDoS. Установки DefensePro являются одними из самых производительных – более 200 Мбит/с для бюджетной модели.

Рис. 12 – Radware

Особенности:

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

SUCURI

https://sucuri.net/website-antivirus

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

Комплексное решение Website Antivirus дополнительно позволяет:

• отыскать и удалить вредоносный код;
• защитить от брутфорса и ботов.

Цена за услуги меньше $20, что делает предложение выгодным для многих пользователей.

MYRA

https://myracloud.com/en/ddos-protection/

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

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

Qrator

Эффективность превыше всего.

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

Из недостатков:

• возможности личного кабинета никакие;
• WAF приобретается отдельно;
• высокая цена и дополнительная оплата трафика;
• из CDN провайдеров поддерживается лишь Ngenix.

МФИ Софт

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

Аппаратный комплекс «Периметр» с передовой программной начинкой подходит не только для рядовых пользователей и мелкого бизнеса, но и для провайдеров.

Для безопасности корпоративной сетевой инфраструктуры применяется «Скаут» — универсальный инструмент для анализа и поиска угроз на скорости до 1 Тб/с и фильтрации трафика при пропускной способности чуть более 600 Мб/с.

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

Рис. 13 – Логотип МФИ Софт

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

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

Источник