Как я могу предотвратить DDos-атаку на Amazon EC2?
Задержки приблизительно 5 секунд всегда пахнут DNS. Так как это - период тайм-аута по умолчанию большинства сопоставителей.
Согласно совету в этом вопросе, попытайтесь тестировать сервер с skip_name_resolve набор и гарантируя, что клиенты могут правильно разрешить адрес сервера, если Вы используете имена хостов. Если проблема разрешает себя (извините игру слов), затем перейдите на обеспечение, что DNS является установкой правильно в обоих направлениях.
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-атак в программных виртуальных машинах в EC2. Если вы объедините функцию системного журнала, она может защитить от среды с балансировкой нагрузки.
Решение, которое я использую для блокировки в реальном времени плохой активности IP, выходящей из AWS и других..... В моём CSF Firewall в конфигурации для LFD Blocklists я использую список, находящийся здесь - 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-трафика.
Я предвзято отношусь, так как работаю в сети доставки контента инженером по предпродажной безопасности.
Однако использование решения по предотвращению Ddos в сети доставки контента гарантирует, что у вас никогда не закончатся ресурсы в источнике. Это похоже на установку балансировщика нагрузки F5 перед вашим сайтом, но распространяется на тысячи мест по всему миру.
Хороший cdn позволит вам скрыть источник с помощью белого списка, который вы устанавливаете на брандмауэре aws. Поэтому, когда злоумышленники проводят разведку на Amazon, ваш IP-адрес окажется пустым, поскольку все будет заблокировано.
Таким образом, Ddos-атаки блокируются, когда трафик достигает узла как можно ближе к злоумышленнику. Это гарантирует, что вы предотвратите Ddos-атаки так далеко от актива, который вы пытаетесь защитить.
Хороший cdn также может выполнять проверки работоспособности и аварийный трафик в другие места, например, другое эго в заднице, Azure, пространство стойки, мягкий уровень, физический постоянный ток и т. Д.Он также должен иметь WAF, чтобы гарантировать, что вы можете блокировать атаки исчерпания уровня приложения, такие как RUDY, slowpost, slowloris, а также sqli, xss, rfi, lfi и т.д.
По умолчанию cdn также блокирует атаки сетевого уровня, такие как teardrop, icmp , синфлоды и т. д. CDN может противодействовать Ddos-атакам, потому что у них есть огромные возможности для приема запросов, фильтрации плохого трафика и передачи хорошего трафика. Таким образом, усиливающиеся атаки, такие как ntp, DNS, ssdp, chargen и snmp, могут быть заблокированы.
Самая крупная атака, которую я видел на сегодняшний день, была 321 Гбит / с в июле 2014 года. Во время этой атаки также была атака по протоколу DNS на 20 Гбит / с. Таким образом, вам нужно будет убедиться, что ваша инфраструктура DNS также устойчива и способна выдерживать огромное количество запросов.
Судя по предоставленному вами описанию, похоже, что вы подверглись атаке исчерпания ресурсов, когда злоумышленник открыл множество потоков, так что все потоки были поглощены на веб-сервере, сервере приложений или брандмауэре. Это похоже на что-то вроде slowpost, slowloris или RUDY.
Для защиты от атак исчерпания уровня приложений вам потребуется брандмауэр веб-приложений (WAF). Обычный сетевой брандмауэр (включая брандмауэр Amazon и брандмауэры нового поколения) не сможет его заблокировать. Отправленные рабочие брандмауэры в наши дни могут блокировать только около 30% всех атак (ноябрь 2014 г.).
Вот инструмент, который я сделал для тех, кто хочет использовать Fail2Ban на aws с apache, ELB и ACL: https://github.com/anthonymartin/aws-acl-fail2ban
Он полезен для обнаружения и предотвращения DoS-атак и злоупотреблений ec2 экземплярами.
.