Прямые IP-атаки, ElastickBeanstalk / NGINX - PullRequest
0 голосов
/ 13 ноября 2018

У меня небольшая проблема с моим сайтом. Таким образом, настройка - 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;    
...

Так что вопросы,

  1. многие владельцы сайтов / devOps сталкиваются с одной и той же атакой. Каковы ваши действия по предотвращению подобных атак.
  2. На данный момент он обрабатывается очень хорошо и не влияет на работу сервера. Стоит ли беспокоиться об этом? Или просто отфильтруйте логи с помощью / phpmy / pattern и забудете об этом.
  3. Перед этой атакой у меня есть запрос с методом PROPFIND, должен ли я заблокировать его по соображениям безопасности? На данный момент он обрабатывается сервером по умолчанию.

Я знаю, что могу использовать Cloudflare Argotunel или ELB + WAF. Но я пока не хочу этого делать.

Я нашел одно решение для stackoverflow. Является белым списком всех облачных вспышек ips. Но я думаю, что это не очень хорошо.

Также другое решение, которое должно работать, я думаю, это проверить заголовок хоста и сравнить его с «example.com».

1 Ответ

0 голосов
/ 14 ноября 2018

Чтобы ответить на ваши конкретные вопросы:

  1. Каждый публичный IP-адрес получает нежелательный трафик, как вы описали, к сожалению, это довольно нормально. На самом деле это не атака как таковая, это просто бот, который ищет признаки определенных слабостей или пытается спровоцировать ответ, содержащий полезные данные. Эти данные, без сомнения, впоследствии используются в реальных атаках, но в основном это автоматическое распознавание в потенциально массовом масштабе.

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

  3. Вы должны следовать принципу наименьших привилегий. 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-адреса.

...