Вопрос или проблема
Я развернул свое контейнеризированное приложение с использованием AWS ECS Fargate. Моя установка состоит из:
- Веб-сервера FastAPI, работающего на порту 8000.
- Сервера NGINX, работающего на порту 8080.
Из соображений безопасности я заблокировал прямой доступ через группы безопасности – это значит, что никто не может получить доступ к публичному IP моего инстанса на портах 80, 443, 8080 или 8000.
Вместо этого я сделал свое приложение доступным только через AWS Application Load Balancer (ALB), который обрабатывает трафик на основе домена. Я предполагал, что так как публичный IP недоступен, то боты не смогут отправлять автоматические запросы, если только они не знают моего доменного имени.
Однако, я все еще вижу входящие запросы от ботов.
Мой вопрос:
- Как боты продолжают отправлять запросы к моей службе, если прямой доступ по IP заблокирован?
- Есть ли способ полностью предотвратить трафик от ботов без использования AWS WAF или других AWS служб безопасности?
- Не должно ли блокирование прямого доступа к публичному IP означать, что только пользователи, которые знают мой домен, могут достигнуть сервиса?
Буду признателен за любые идеи, почему это происходит и возможные решения.
ALB не фильтрует трафик от ботов, он просто передает его вашим контейнерам. Если бот знает ваше доменное имя, он может отправлять запросы напрямую к вашему ALB. Домен и ALB не защищены от трафика ботов только из-за того, что они находятся за SG.
Трудно понять из вопроса, что такое «боты» и что такое «запросы», но возможной причиной того, почему группы безопасности “не действуют”, может быть то, как работает изменение групп безопасности.
Когда вы меняете группу безопасности, изменения вступают в силу только для новых соединений, которые инициированы, это значит, что если у вас есть открытое TCP-соединение от клиента к вашей цели, то изменение правила для блокировки этого соединения не завершит существующее соединение (однако новые TCP-соединения от того же клиента будут заблокированы).
Применение сетевых ACL является более “сильным” вариантом для обеспечения блокировки соединений (и применяется немедленно на существующие соединения тоже).
Еще одна возможная причина: ваши таблицы маршрутизации VPC позволяют неожиданные пути подключения к вашей цели, обходя ваши правила.
Наконец, вы можете проверить, поступают ли какие-либо запросы на ваш балансировщик нагрузки, включив метрики CloudWatch и журналы доступа балансировщика нагрузки.
@Mark B нашел решение, Спасибо @Mark B
Балансировщик нагрузки возвращает 404 по умолчанию, и если заголовок хоста совпадает с моим доменом, он перенаправляет запрос к целевой группе. Я тестировал в течение двух часов, и никаких вредоносных запросов не прошло.
.
Ответ или решение
Ваша ситуация с использованием AWS ECS Fargate, FastAPI и NGINX вызывает несколько интересных вопросов относительно защиты ресурса от бот-трафика. Прежде чем уйти в детали, важно отметить, что, хотя закрытие прямого доступа через IP с использованием групп безопасности — это важная мера, она не обязательно гарантирует полную защиту от ботов, особенно если ваш сервис доступен через DNS.
Теория
-
Группы безопасности и ограничения: AWS Security Groups на уровне сетевых интерфейсов EC2 обеспечивают защиту от нежелательного трафика за счет блокировки портов. Однако, если ваш сервис доступен через DNS и обрабатывается ALB, ограничения по IP на уровне Security Groups действуют только на уровне VPC, а не на уровне приложения. Это значит, что любой трафик, который проходит через ALB, будет передан вашему приложению, независимо от правил в группах безопасности, если он соответствует условиям пересылки ALB.
-
Работа ALB: ALB переносит трафик от клиентов к таргет-группам и не блокирует трафик ботов автоматически. Он действует на уровне HTTP/HTTPS и, следовательно, трафик будет передан дальше, если запросы соответствуют требованиям конфигурации ALB (например, заголовок Host соответствует вашему домену).
-
Обход защитных механизмов: Боты, которые знают ваш домен, могут отправлять запросы через ALB, минуя ограничения групп безопасности. Также, если у ботов есть другие каналы обнаружения имени домена (например, публичные реестры или утечки в конфигурациях), они могут обратиться к вашему сервису.
Пример
Рассмотрим пример, когда бот обнаруживает ваш домен через данные публичных DNS-записей. Несмотря на то, что ваша инстанция защищена на уровне IP, DNS предоставляет необходимую информацию для доступа через ALB. Данный трафик может пройти через ALB, если заголовок соответствует вашим правилам маршрутизации, установленным на load balancer.
Применение
-
Проанализируйте конфигурацию ALB: Проверьте ваши правила маршрутизации, чтобы убедиться, что они соответствуют только необходимым шаблонам доступа. Например, вы можете добавить дополнительные проверки на заголовки или пути для отказа ботов в доступе.
-
Фильтрация по User-Agent: Простой способ снизить количество ботов — это блокировка известных User-Agent строк, используемых ботами. Это можно сделать через конфигурацию вашего NGINX сервера.
-
Использование CloudWatch и Logs: Включите метрики и логи в CloudWatch для анализа трафика. Это позволит вам мониторить, какие запросы поступают и какие, возможно, требуют дополнительной фильтрации.
-
Настройка маршрутизации на ALB: Используйте правила перенаправления, чтобы категорически фильтровать входящий трафик по нужным условиям. Это может включать проверку специфических заголовков или маршрутов.
-
Расширенная защита без AWS WAF: Although AWF WAF — это мощное средство защиты, вы можете также использовать CAPTCHAs или другие формы валидации на уровне приложения для подтверждения легитимности пользователя перед тем, как обработать их запросы.
Итак, ответ на ваш вопрос не столь прост и требует комплексного подхода. Изучение конфигурации вашего ALB, анализ метрик трафика и стратегическая настройка ваших правил — вот основные шаги, которые помогут вам добиться более высокой степени безопасности без внедрения новых инструментов AWS.