Один из серверов, которые я использую, размещен в облаке Amazon EC2. Каждые несколько месяцев мы, похоже, проводим DDOS-атаку на этот сервер. Это невероятно замедляет работу сервера. Примерно через 30 минут, а иногда и после перезагрузки, все возвращается в нормальное состояние.
У Amazon есть группы безопасности и брандмауэр, но что еще мне нужно установить на сервере EC2, чтобы смягчить или предотвратить атаку?
Из похожих вопросов я узнал:
Что еще мне не хватает? Я хотел бы получить информацию о конкретных инструментах и параметрах конфигурации (опять же, здесь используется Linux) и / или обо всем, что относится к Amazon EC2.
ps: Примечания о мониторинге DDOS также приветствуются - возможно, с помощью nagios? ;)
DDOS (или даже DOS) по своей сути является исчерпанием ресурсов. Вы никогда не сможете устранить узкие места, так как вы можете только отодвинуть их подальше.
В AWS вам повезло, потому что сетевой компонент очень силен - было бы очень удивительно узнать, что восходящий канал был переполнен. Тем не менее, ЦП, а также ввод-вывод дисков, гораздо легче переполнить.
Лучшим вариантом действий будет запуск некоторого мониторинга (локального, например SAR, удаленного с помощью Nagios и / или ScoutApp) и некоторых средств удаленного ведения журнала (Syslog-ng). С такой настройкой вы сможете определить, какие ресурсы становятся перегруженными (сетевой сокет из-за Syn flood; CPU из-за неправильных запросов SQL или поисковых роботов; RAM из-за…). Не забудьте разместить свой раздел журнала (если у вас не включено удаленное ведение журнала) на томах EBS (для последующего изучения журналов).
Если атака происходит через веб-страницы, журнал доступа (или аналог) может быть очень полезным.
Вы также можете дополнительно изолировать свои экземпляры EC2, поместив их за Elastic Load Balancer и принимая трафик только от экземпляра ELB. Это возлагает на Amazon большую ответственность за управление DDOS-атаками.
Я предполагаю, что у вас по-прежнему будет SSH, открытый для всех, поэтому вполне вероятно, что вы все еще будете видеть поступающий туда мошеннический трафик, если только вы не заблокируете этот порт для некоторых статических IP-адресов. Вы можете изменить порт SSHd на что-то более неясное (например, на что-то другое, чем 22), чтобы еще больше уменьшить количество попаданий DDOS (большинство ботов проверяют только известные порты).
Я также упомяну fail2ban, который может отслеживать журналы и временно изменять ваши таблицы IP для блокировки определенных IP-адресов (например, если было 6 неудачных попыток подключения по SSH к вашему хосту с одного IP-адреса, он может заблокировать этот IP-адрес на 30 минут или около того). Имейте в виду, что (как проницательно прокомментировал Джордан) fail2ban, вероятно, не подходит для блокировки проксируемого трафика (например, от ELB), потому что он блокирует IP-адрес прокси, не обязательно исходный удаленный IP-адрес.
Я не использовал его, но, возможно, стоит изучить Apache mod_evasive; однако у него может быть та же слабость, что и у fail2ban, когда дело доходит до блокировки по IP.
Если вы используете Apache, я предлагаю использовать mod_security. Базовый набор правил, упакованный большинством поставщиков, отлично справляется со своей задачей.
Еще один шаг по усилению защиты - ограничение запросов на уровне веб-сервера. Nginx., Apache может регулировать и ограничивать входящие запросы.
Я пристрастен, поскольку работаю в сети доставки контента инженером по предпродажной безопасности.
Однако использование решения по предотвращению Ddos в сети доставки контента гарантирует, что у вас никогда не закончатся ресурсы в источнике. Это похоже на установку балансировщика нагрузки F5 перед сайтом, но распространяется на тысячи мест по всему миру.
Хороший cdn позволит вам скрыть происхождение с помощью белого списка, который вы установите на брандмауэре aws. Поэтому, когда злоумышленники проводят разведку на Amazon, ваш IP-адрес окажется пустым, так как все будет заблокировано.
Таким образом, Ddos-атаки блокируются, когда трафик достигает узла как можно ближе к злоумышленнику. Это гарантирует, что вы смягчите Ddos-атаки так далеко от актива, который вы пытаетесь защитить.
Хороший cdn также может выполнять проверки работоспособности и аварийный трафик в другие места, например, другое эго в заднице, Azure, пространство стойки, мягкий уровень, физический постоянный ток и т. Д. Он также должен иметь WAF, чтобы гарантировать, что вы можете блокировать атаки исчерпания уровня приложения, такие как RUDY, slowpost, slowloris, а также sqli, xss, rfi, lfi и т. Д.
По умолчанию cdn также блокирует атаки сетевого уровня, такие как teardrop, icmp-атаки, synfloods и т. Д. Cdn может смягчить Ddos-атаки, потому что у них есть огромные возможности для приема запросов, фильтрации плохого трафика и передачи хорошего трафика. Таким образом, усиливающиеся атаки, такие как ntp, DNS, ssdp, chargen и snmp, могут быть заблокированы.
Самая крупная атака, которую я видел на сегодняшний день, была 321 Гбит / с в июле 2014 года. Во время этой атаки также была атака по протоколу DNS на 20 Гбит / с. Таким образом, вам нужно будет убедиться, что ваша инфраструктура DNS также устойчива и способна выдерживать огромное количество запросов.
Из предоставленного вами описания похоже, что вы подверглись атаке исчерпания ресурсов, когда злоумышленник открыл множество потоков, так что все потоки были поглощены на веб-сервере, сервере приложений или брандмауэре. Это похоже на что-то вроде slowpost, slowloris или RUDY.
Чтобы заблокировать атаки исчерпания уровня приложений, вам потребуется брандмауэр веб-приложений (WAF). Обычный сетевой брандмауэр (включая брандмауэр Amazon и брандмауэры нового поколения) не сможет его заблокировать. Отправленные рабочие брандмауэры в наши дни могут блокировать только около 30% всех атак (ноябрь 2014 г.).
Решение, которое я использую для блокировки IP-адресов плохой активности в реальном времени, исходящих из AWS и других, заключается в следующем ... В моем брандмауэре CSF в конфигурации для списков блокировки LFD я использую список, найденный здесь - http://myip.ms/browse/blacklist/Blacklist_IP_Blacklist_IP_Addresses_Live_Database_Real-time
Загрузить черный список для CSF Firewall » http://myip.ms/files/blacklist/csf/latest_blacklist.txt
Больше никакого возмутительно неприятного трафика AWS.
Вот инструмент, который я сделал для тех, кто хочет использовать Fail2Ban на aws с apache, ELB и ACL: https://github.com/anthonymartin/aws-acl-fail2ban
Это полезно для обнаружения и предотвращения DoS-атак и злоупотреблений экземплярами ec2.
Межсетевой экран сервера конфигурации - лучшее, что я видел для защиты от DDoS-атак в программных виртуальных машинах в EC2. Если вы объедините функцию системного журнала, она может защитить от среды с балансировкой нагрузки.