Как я могу предотвратить DDOS-атаку на Amazon EC2?

Один из серверов, которые я использую, размещен в облаке Amazon EC2. Каждые несколько месяцев у нас, похоже, происходит атака DDOS на этот сервер. Это невероятно замедляет работу сервера. Примерно через 30 минут, а иногда и после перезагрузки, все возвращается в норму.

У Amazon есть группы безопасности и брандмауэр, но что еще я должен иметь на сервере EC2, чтобы смягчить или предотвратить атаку?

Из похожих вопросов я узнал:

• Ограничьте скорость запросов / минуту (или секунды) с определенного IP-адреса через что-то вроде IP-таблиц (или, может быть, UFW?)
• Иметь достаточно ресурсов, чтобы пережить такую ​​атаку - или -
• Возможно, создайте веб-приложение, чтобы оно было эластичным / имело эластичный балансировщик нагрузки и могло быстро масштабироваться для удовлетворения такого высокого спроса)
• При использовании mySql настройте соединения mySql так, чтобы они выполнялись последовательно, чтобы медленные запросы не приводили к перегрузке системы

Что еще мне не хватает? Мне бы хотелось получить информацию о конкретных инструментах и ​​параметрах конфигурации (опять же, используя Linux здесь) и / или обо всем, что касается Amazon EC2.

PS: Примечания о мониторинге для DDOS также будет приветствоваться - возможно, с nagios? ;)

DDOS (или даже DOS) по своей сути является исчерпанием ресурсов. Вы никогда не сможете устранить узкие места, так как вы можете оттолкнуть их только дальше.

В AWS вам повезло, потому что сетевой компонент очень сильный - было бы очень удивительно узнать, что восходящий канал был насыщенным. Тем не менее, ЦП, а также дисковый ввод-вывод, намного легче залить.

Наилучшим способом действий будет запуск некоторого мониторинга (локального, такого как SAR, удаленный с Nagios и / или ScoutApp) и некоторых средств удаленной регистрации (Syslog-ng). При такой настройке вы сможете определить, какие ресурсы насыщаются (сетевой сокет из-за перегрузки Syn; процессор из-за некорректных запросов или сканеров SQL; оперативная память из-за…). Не забудьте иметь раздел журнала (если у вас не включена функция удаленного ведения журнала) на томах 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 может ограничивать и ограничивать входящие запросы.

Решение, которое я использую для блокировки в реальном времени нежелательных IP-адресов, поступающих из AWS и других, заключается в следующем ... В моем брандмауэре CSF в конфигурации для LFD Blocklists я использую список, найденный здесь - http://myip.ms/browse/blacklist/ Blacklist_IP_Blacklist_IP_Addresses_Live_Database_Real времени

Загрузить черный список для межсетевого экрана CSF » http://myip.ms/files/blacklist/csf/latest_blacklist.txt

Нет больше отвратительно неприятного трафика AWS.

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

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

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

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

Хороший cdn также может выполнять проверки работоспособности и аварийный трафик в другие местоположения, например, другое эго в заднице, Azure, стойке, мягком слое, физическом постоянном токе и т. Д. Он также должен иметь WAF, чтобы гарантировать, что вы можете блокировать атаки истощения уровня приложения, такие как RUDY, slowpost, slowloris, а также sqli, xss, rfi, lfi и т. Д.

По умолчанию cdn также блокирует атаки сетевого уровня, такие как слезоточивый, icmp-атаки, синхронные потоки и т. Д. Cdn способен смягчать атаки Ddos, потому что у trey есть огромные возможности для приема запросов, фильтрации плохого трафика и передачи хорошего трафика. Таким образом, усиленные атаки, такие как ntp, DNS, ssdp, chargen и snmp, могут быть заблокированы объемными атаками.

Самая большая атака, которую я видел на сегодняшний день, была 321 Гбит / с в июле 2014 года. Во время этой атаки была также атака по протоколу DNS со скоростью 20 Гбит / с. Таким образом, вам необходимо убедиться, что ваша DNS-инфраструктура также устойчива к огромному количеству запросов.

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

Чтобы противостоять атакам на уровне приложений, вам нужно получить брандмауэр веб-приложений (WAF). Типичный сетевой брандмауэр (включая брандмауэр amazons и брандмауэры следующего поколения) не сможет его заблокировать. Отправленные рабочие брандмауэры в наши дни могут блокировать только около 30% всех атак в эти дни (ноябрь 2014 г.).

Вот инструмент, который я сделал для тех, кто хочет использовать Fail2Ban в aws с apache, ELB и ACL: https://github.com/anthonymartin/aws-acl-fail2ban

Это полезно для обнаружения и предотвращения DoS-атак и злоупотребления экземплярами ec2.

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

http://configserver.com/cp/csf.html