Прямые IP-атаки, ElastickBeanstalk / NGINX
У меня небольшая проблема с моим сайтом. Итак, настройка - это ElasticBeanstalk (NGINX) + Cloudflare
Но каждый день около 4 утра у меня прямая IP-атака на мой сервер. Около 300 запросов за 1-2 минуты. Бот пытается получить доступ к некоторым ресурсам, например
GET /phpMyadmi/index.php HTTP/1.1
GET /shaAdmin/index.php HTTP/1.1
POST /htfr.php HTTP/1.1
Пока все они идут на 80 или 8080 портов. И успешно обрабатывается конфигурацией Nginx, которая перенаправляет его на пример: 443
server {
listen 80 default_server;
listen 8080 default_server;
server_name _;
return 301 https://example.com$request_uri;
}
server {
listen 443 ssl;
server_name example.com;
ssl on;
...
Итак, вопросы,
- многие владельцы сайтов / devOps сталкиваются с одной и той же атакой. Что вы делаете для предотвращения таких атак.
- На данный момент это обрабатывается очень хорошо и не влияет на работу сервера, стоит ли об этом беспокоиться? Или просто отфильтруйте логи с помощью / phpmy / pattern и забыли об этом.
- Перед этой атакой у меня был запрос с методом PROPFIND, должен ли я заблокировать его из соображений безопасности? Пока это обрабатывается сервером по умолчанию.
Я знаю, что могу использовать Cloudflare Argotunel или ELB + WAF. Но пока я не очень хочу этим заниматься.
Я нашел одно решение для stackoverflow. Белый список всех IP-адресов облачных вспышек. Но я думаю, что это не очень хорошо.
Также другое решение, которое должно работать, я думаю, это проверить заголовок Host и сравнить его с example.com.
Да, обычно все запросы в атаке с одного IP-адреса. Но IP у каждой атаки разный, причем из разных мест.
Ответы 1
Чтобы ответить на ваши конкретные вопросы:
Каждый публичный IP-адрес получает нежелательный трафик, как вы описали, к сожалению, это довольно нормально. На самом деле это не атака как таковая, это просто бот, ищущий признаки определенных слабых мест или иным образом пытающийся спровоцировать ответ, содержащий полезные данные. Эти данные, без сомнения, позже используются в реальных атаках, но в основном они автоматически распознаются в потенциально массовых масштабах.
Этот вид скрипта, скорее всего, не пытается нанести какой-либо ущерб, поэтому, пока ваш сервер хорошо настроен и полностью пропатчен, это не вызывает большого беспокойства. Однако такие виды сканирования являются первым шагом к запуску атаки - путем выявления сервисов и версий приложений с известными уязвимостями - поэтому разумно сохранить свои журналы для анализа.
Вы должны следовать принципу наименьших привилегий. PROPFIND связан с WebDAV - если вы не используете его, отключите его (или лучше занесите в белый список глаголы, которые вы поддерживаете, и проигнорируйте остальные).
Если ваш сайт уже находится за CloudFlare, вам действительно следует использовать брандмауэр для доступа к вашему IP, чтобы только IP-адреса Cloudflares могли общаться с вашим сервером. Эти IP-адреса меняются, поэтому я бы предложил сценарий для загрузки последней версии с https://www.cloudflare.com/ips-v4 и периодически обновлять ваш брандмауэр. Здесь есть небольшая справочная статья от CloudFlare по этой теме: https://support.cloudflare.com/hc/en-us/articles/200169166-How-do-I-whitelist-Cloudflare-s-IP-addresses-in-iptables-
Если по какой-либо причине вы не можете использовать брандмауэр IP, ваш следующий лучший вариант - это что-то вроде fail2ban (www.fail2ban.org) - это парсер журнала, который может манипулировать брандмауэром для временной или постоянной блокировки IP-адреса на основе шаблонов, найденных в вашем журнале. файлы.
Последняя мысль - id не советует перенаправлять с вашего IP на ваше доменное имя - вы сообщаете боту / хакерам ваш URL, который они затем могут использовать для обхода CDN и прямой атаки на ваш сервер. Если у вас нет причин разрешать трафик HTTP / HTTPS на ваш IP-адрес, возвращайте 4XX (возможно, 444 - «Соединение закрыто без ответа») вместо перенаправления, когда запросы попадают на ваш IP-адрес. Затем вы должны создать отдельный серверный блок для обработки ваших перенаправлений, но чтобы он отвечал только на подлинные именованные URL-адреса.
Запросы каждый раз с одного и того же IP-адреса (или небольшого диапазона IP-адресов)?