Как защитить сервер от dos-атак

Предотвращение и защита от DDoS-атак

Согласно данным Corero Network Security, более ⅔ всех компаний в мире ежемесячно подвергаются атакам «отказа в доступе». Причём их число доходит до 10 миллионов в год и имеет постоянную тенденцию к росту.

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

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

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

1. Еще на этапе написания программного обеспечения необходимо задуматься о безопасности сайта. Тщательно проверяйте ПО на наличие ошибок и уязвимостей.
2. Регулярно обновляйте ПО, а также предусмотрите возможность вернуться к старой версии при возникновении проблем.
3. Следите за ограничением доступа. Службы, связанные с администрированием, должны полностью закрываться от стороннего доступа. Защищайте администраторский аккаунт сложными паролями и почаще их меняйте. Своевременно удаляйте аккаунты сотрудников, которые уволились.
4. Доступ к интерфейсу администратора должен проводиться исключительно из внутренней сети или посредством VPN.
5. Сканируйте систему на наличие уязвимостей. Наиболее опасные варианты уязвимостей регулярно публикует авторитетный рейтинг OWASP Top 10.
6. Применяйте брандмауэр для приложений — WAF (Web Application Firewall). Он просматривает переданный трафик и следит за легитимностью запросов.
7. Используйте CDN (Content Delivery Network). Это сеть по доставке контента, функционирующая с помощью распределенной сети. Трафик сортируется по нескольким серверам, что снижает задержку при доступе посетителей.
8. Контролируйте входящий трафик с помощью списков контроля доступа (ACL), где будут указан список лиц, имеющих доступ к объекту (программе, процессу или файлу), а также их роли.
9. Можно блокировать трафик, которых исходит от атакующих устройств. Делается это двумя методами: применение межсетевых экранов или списков ACL. В первом случае блокируется конкретный поток, но при этом экраны не могут отделить «положительный» трафик от «отрицательного». А во втором — фильтруются второстепенные протоколы. Поэтому он не принесет пользы, если хакер применяет первостепенные запросы.
10. Чтобы защититься от DNS-спуфинга, нужно периодически очищать кеш DNS.
11. Использовать защиту от спам-ботов — капча (captcha), «человечные» временные рамки на заполнение форм, reCaptcha (галочка «Я не робот») и т. д.
12. Обратная атака. Весь вредоносный трафик перенаправляется на злоумышленника. Он поможет не только отразить нападение, но и разрушить сервер атакующего.
13. Размещение ресурсов на нескольких независимых серверах. При выходе одного сервера из строя, оставшиеся обеспечат работоспособность.
14. Использование проверенных аппаратных средств защиты от DDoS-атак. Например, Impletec iCore или DefensePro.
15. Выбирать хостинг-провайдера, сотрудничающего с надёжным поставщиком услуг кибербезопасности. Среди критериев надёжности специалисты выделяют: наличие гарантий качества, обеспечение защиты от максимально полного спектра угроз, круглосуточная техподдержка, транспарентность (доступ клиента к статистике и аналитике), а также отсутствие тарификации вредоносного трафика.

Почему сложно защититься от DDoS

Защититься от DDoS сложно по следующим трем основным причинам.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Инструменты

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

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

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

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

Долой 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 атака

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

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

IPTables

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

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

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

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

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

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

В сети на этот счёт есть готовые инструкции.

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

Определяем DDos

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

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

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

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

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

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

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

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

Рекомендации по выбору поставщика услуг защиты от DDoS

25 апреля 2017 г. компании Qrator Labs, Ngenix, Wallarm (Валарм) Онсек (Onsec) объявили о выпуске подробных рекомендаций по выбору поставщика услуг защиты сайтов от DDoS-атак и защиты от взломов, а также услуг обнаружения уязвимостей. Такой комплексный перечень критериев для выбора провайдера на российском рынке был создан впервые.

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

Среди основных бизнес-критериев можно отметить следующие:

Гарантии качества, или SLA (Service Level Agreement), где содержится описание гарантий доступности ресурса и материальной ответственности за их несоблюдение, в том числе во время атаки.

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

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

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

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

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

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

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

При поиске защиты от взлома (WEB Application Firewall, WAF) следует учесть наличие в решении активного и пассивного поиска уязвимостей, виртуального патчинга уязвимостей (возможность блокировки попыток эксплуатации уязвимости до момента, пока она фактически не исправлена) и защиты от брутфорс (brut force) атак – защиты от перебора паролей.

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

• ширина полосы пропускания,
• задержка между пакетами,
• показатель потери пакетов,
• джиттер (разброс времени прохождения пакетов).

Но этот подход не учитывает, что в силу распределённой природы сети, проблемы могут возникать ещё до установки соединения. Пример тому – Route Leaks, утечки маршрутов. По статистике Qrator Labs, в каждый момент времени около 1% маршрутов находятся в этом состоянии, за две недели эта проблема затрагивает около 5% префиксов. Эта проблема может усугубиться, если киберпреступники начнут эксплуатировать данный метод для похищения трафика и для организации DDoS. В этом случае отличить злой умысел от ошибок конфигурации и прочих результатов «человеческого фактора» будет настолько же сложно, как отыскать иголку в стогу сена.

Необходимо рассматривать качество на трёх уровнях:

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

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

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

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

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

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

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

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

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

#!/bin/sh

tail -1000 /web/sites/hl.zeroxzed.ru/log/ssl-access.log | egrep "GET / HTTP/1.0" | awk '{print $1}' | sort -n | uniq -c | sort -n | tail -n100 | awk '{if ($1 > 50 ) print $2}' > /root/ddos/much_gets.txt

sleep 3

list=$(cat /root/ddos/much_gets.txt)
for ipnet in $list
    do
	ipset -A much_gets $ipnet
    done

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

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

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

Важно это понимать и не применять решение бездумно. Будет только вред.

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

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

Выбор поставщика: что продумать и о чём спрашивать

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

Выбирая провайдера, очень важно выяснить следующие его особенности

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

Также нелишним будет проверить связность с транзитными операторами и запустить пинг до защищаемых провайдером ресурсов из разных мест (это можно сделать с помощью сервисов вроде https://bgp.he.net и https://ping.pe).
Важно выяснить, насколько давно и профессионально компания занимается защитой от DDoS и специализируется ли она на этих сервисах. Очень полезно изучить отзывы о компании в интернете, понять, насколько активно она участвует в жизни сообщества информационной безопасности и привносит ли в него что-то новое: это поможет понять, справится ли компания с нестандартной ситуацией.
Стоит узнать, как организована техническая поддержка провайдера

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

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