Приветствую тебя, дорогой читатель. Скорее всего, если ты это читаешь, то уже очень устал получать кучу алертов о том, что твоя площадка загибается от регулярных набегов печенегов ботов или других нежелательных посетителей контента. Я надеюсь, что эта статья поможет тебе спать спокойно и оградит тебя от недугов, а также внесет больше ясности в твое понимание теории и практики защиты от dos и ddos. Приятного чтения! Dos, или по-другому Denial of Service - «отказ в обслуживании». Это атака со стороны одиночного IP-адреса, связанная с отправкой нелегитимного трафика и приводящая к неработоспособности системы, что, в свою очередь, приводит к простою площадки или сервиса и потере финансовой составляющей.Ddos, или Distributed Denial of Service - «распределенный отказ в обслуживании».  Отличие данной атаки от описанной выше в том, что отправка трафика в данном случае будет идти с различных IP-адресов. Этот аспект приводит к сложности защиты сервисов. В случае, если на вашей машине, локальной или виртуальной, резко повысилась нагрузка на CPU и увеличилось потребление RAM, то, вероятнее всего, вы стали жертвой криво залитого кода или же ddos/dos-атаки. Распознать подобное поведение и определиться с окончательным выбором варианта ответа нам помогут следующие шаги. Во-первых, как уже было написано выше, - если у вас установлен мониторинг, и вы видите резкие скачки на графиках ресурсопотребления, к примеру: Также вы заметите увеличение количества коннектов на вашем сервисе обработчике данных. Для примера мы рассматриваем стандартный LEMP-стек Nginx + Apache + Mysql,  а значит в момент проблемы мы фиксируем резкий скачок соединений: Во-вторых можно произвести анализ запросов за время возникновения проблемы. В этом, как правило, могут помочь однострочные скрипты, которые полезно иметь каждому системному администратору под рукой, данные скрипты вы можете написать самостоятельно, изучив команды чуть подробнее или воспользоваться нашим готовым решением. Ниже команда для парсинга логов за последние 10000 и вывод в top IP адресов, встречающихся наиболее часто:  Так можно узнать количество уникальных IP, после чего можно сравнить с результатами за предыдущие сутки и узнать было ли значительное увеличение трафика: Следом представляем отличную команду для парсинга IP-адресов в момент фиксирования проблемы, а именно по дате и временному промежутку: Теперь давайте посмотрим примеры на практике нелегитимного трафика: В этом примере первое, что бросается в глаза - это около 4000 запросов за последний час с 00:00. Из этого можно сделать вывод, что это явно не обычный пользователь, которому нравится заходить на сайт. Также одним из отличительных признаков ddos-атаки можно назвать регулярное изменение user agent в каждом запросе, что наводит на мысль о машинном создании запроса. User agent — идентификационная строка клиентского приложения; обычно используется для приложений, осуществляющих доступ к веб-сайтам — браузеров, поисковых роботов и «пауков», мобильных телефонов и других устройств со встроенным доступом к веб-ресурсам. Например: Здесь прекрасно видно, как на протяжении 1 минуты useragent потенциального пользователя в каждом запросе меняет браузер на Chrome, Mozilla, Safari. Как и саму ОС, с которой происходит отправка Windows, Linux.Итак, когда мы чуть-чуть познакомились с теорией, настало время практики. В частности, мы поднимем стандартный Nginx на OC Debian 10 в качестве обработчика статического контента и Apache в качестве backend и произведем стресс тест нашей площадки. Начнём… Давайте поставим актуальный Nginx из официальных репозиториев для дальнейшей работы.  1.1. Ставим необходимые библиотеки:  1.2. Импортируем официальный ключ подписи:  1.3. Проверяем его правильность:  1.4. Добавляем репозитории:  1.5. Настраиваем приоритет наших пакетов, над пакетами из основного дистрибутива:  1.6. Перечитываем репозитории и ставим наш Nginx  2. Проверяем, что Nginx установлен корректно и уже автоматически запустился.  3. Теперь напишем простую конфигурацию для виртуального хоста и проведём тестирование. Конфигурация:  4. Прописываем необходимую запись к себе в hosts, чтобы иметь возможность открыть наш созданный сайт. Конфигурация:  5. Делаем проверку и получаем подобный результат. Картинка была заготовлена изначально и положена в файлы площадки.  6. Теперь проверим, как наш Nginx выдержит стресс-тест. Используем для этого любую тестовую утилиту для Dos. Я в качестве примера использую GoldenEye. Ссылка на источник прилагается. Её запуск можно произвести как со своей локальной машины, так и с другой  виртуальной машины для наглядности. Перемещаемся в рабочий каталог: И клонируем себе репозиторий: Если у вас изначально нету git и python, то их можно также легко установить себе на машину следующими командами: Теперь делаем тестовый запуск и смотрим на логи и результат:  7.  Результат. Площадка не отдает контент: В логах видим, что на площадку было отправлено 3000 беспорядочных запросов Nginx. При этом все запросы имеют примерно следующее содержание: Это привело к исчерпанию свободных workers обработчиков сервиса: Будьте аккуратны с GoldenEye, так как во время тестирования он потребляет основные ресурсы сервера и, как правило, при неправильном выставлении параметров из серии: Может привести к исчерпанию свободных ресурсов сервера и к его зависанию. После того, как наша площадка спустя непродолжительное время упала под натиском атаки, можно пробовать выстраивать защиту, которая сможет помочь избежать нелегитимного трафика и дать возможность почувствовать себя крутым IT-шником.Перед этим необходимо ответить себе на следующие вопросы: От каких атак я хочу защититься? Хочу ли я отсеять запросы ботов? Как не потерять трафик от реальных пользователей? Приступим...Разумеется, для тех, кто уже имел опыт работы с Nginx, не будет сюрпризом функция ‘rate’. Для тех, кто не имел такого опыта, ниже мы подробнее рассмотрим эту функцию: что это и с чем это едят. Шаг первый ‘rate’: rate - настраиваемая функция, которая позволяет вам ограничить количество HTTP-запросов, которые пользователь может сделать за определенный период времени.  1. Производим добавление зоны в блок server нашего виртуального хоста в корневой location: Конфигурация: Чтобы понимать, что мы пишем, разберём сразу несколько ‘лемм’ данной настройки: Результаты: После произведения небольшого теста мы сразу увидим в логах следующую картину работы нашей настройки: Отсюда мы видим, 1 запрос получил 200-й код ответа, после чего все остальные запросы получали 503-й код, говорящий о том, что сервер не готов обработать данный запрос. Прекрасно - мы на верном пути. После того как мы настроили данную защиту, мы защитились от вредоносных IP-адресов, которые создают ненужные запросы, но что, если мы представим ситуацию, когда к нам заглянут толпы поисковых ботов не принадлежащие Yandex, Google, Mail, исходя из нашей настройки 1 запрос будет всегда обрабатываться корректно, но нужен ли он нам? Шаг второй ‘блокировка по user_agent’ Производим настройку блокировки по user_agent, добавим в наш блок сервера интересное условие для блокировки наиболее популярных поисковых ботов и получим финальную конфигурацию: Результаты: Теперь боты, обращающиеся с данным user agent автоматически получают 403 независимо от запроса и отправляются отдыхать, не затрагивая нашу площадку. Шаг третий ‘fail2ban’ Пришло время для настройки отличного инструмента для защиты сервера и вашего продукта от вредоносного помешательства - fail2ban. Суть его работы такова, что он анализирует logs файлы запущенных программ и на основании выставленных условий производит блокировку IP-адреса на указанный промежуток времени.  1. Производим его установку на сервер  2. Время настройки! Копируем стандартный jail.conf и сохраняем его в jail.local: После чего редактируем jail.local: И вставляем в конце jail.local. Конфигурация: Где: Не забываем удалить повторяющиеся уже настройки данного фильтра в самой конфигурации иначе fail2ban не сможет перечитать конфиг и будет ругаться на ошибки.  3. Перезапускаем fail2ban и проверяем результат Либо сделать restart сервиса: Проверяем, что наш фильтр запущен: Результат: В дальнейшем, когда запросы будут идти в Nginx, наш настроенный выше ‘rate’ будет писать сообщения об ошибках в /var/log/nginx/error.log. Пример ответа из logs файлов: После этого в /var/log/fail2ban.log будет выведено сообщение о блокировке нашего подозрительного IP: и данный пользователь в дальнейшем не сможет отправлять запросы в течении 10 минут, так как будет заблокирован правилами iptables. Шаг четвертый ‘geoip’ Если вы прекрасно знакомы со своей аудиторией и знаете из каких стран вы желаете видеть пользователей, то для решения этой задачи отлично подойдет модуль, способный производить отсеивание и блокировку нежелательного трафика по геолокации IP адреса. Если ранее у нас уже был установлен Nginx, то для работы с geiop нам потребуется собрать модуль из исходников и подключить его.  1. Производим установку на сервер необходимых библиотек.  2. Компилируем модуль под нужную версию Nginx, у нас это будет 1.18.0  3.  Кладём его в наш каталог  4. Скачиваем актуальные БД с IP адресами:  5. После чего редактируем nginx.conf: И вставляем в блок http следующую мапу. Конфигурация:  6. Добавляем код location в наш виртуальный хост, как это делалось ранее. Конфигурация:  7. Посылаем команду нашему любимому Nginx на перечитку конфигураций и проверяем результат. Если вы хотите узнать более подробную информацию про сборку динамических модулей, то вы можете ознакомиться со статьёй написанной ранее нашим DevOps Engineer. Нельзя не заметить, что данная статья повествует о различных способах защиты от dos, но остаётся главный вопрос, который, я уверен, за время чтения уже был задан не однократно: “Как защититься от ddos?”. Ведь высококачественная атака, использующая большое количество IP-адресов может с лёгкостью обойти все уровни защиты, выставленные нами ранее. В данном случае лучше всего помогают следующие средства, а именно платформы по предоставлению услуг защиты и спокойного сна: Cloudflare, Incapsula, Servicepipe,  DDoS-Guard и etc…И хотя готовых решений может быть бесчисленное множество, необходимо уже изначально, на раннем этапе создавать грамотную настройку основного функционала сервиса обработчика. Ведь это позволяет с самого начала дать отпор ботам и недоброжелательным конкурентам, которые хотят создать проблемы в работе вашей инфраструктуры. Берегите свои площадки и не допускайте простоя!  P.S.: Кстати, DevOps-инженерам и системным администраторам будет интересно заглянуть в телеграм-канал DevOps FM, присоединяйтесь)   DevOps Engineer