Работа с ограничением правила ACL для сети AWS


12

Максимально к ACL-списку сети VPC может применяться 40 правил.

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

Конечно, я могу сделать это в IPTables на каждом хосте, но я хочу заблокировать любой трафик для всех компонентов в VPC (например, для ELB). Более того, гораздо удобнее управлять этими правилами в одном месте, а не на каждом хосте.

Я надеюсь, что есть какой-то способ, которого я не понимаю, делая это на уровне системы / платформы. Группы безопасности явно разрешают, без каких-либо действий запрета, поэтому они не сработают.


Используйте программное обеспечение для обеспечения доступа, такое как Ansible, для управления iptables, и все готово. Очевидно, это будет работать только в случаях EC2; не LBs и т. д.
Kyslik

Да, я согласен, что iptables подходит для EC2, но 99% моего входящего трафика соответствует нашей структуре ELB. Мы заплатили бы за много хитов от этих известных мошенников, с которыми нам приходится иметь дело. Спасибо за вклад
Эмми

1
Блокировка 50 отдельных IP-адресов кажется странным требованием.
user253751

@immibis Странно для тебя, может быть. Мы получаем много мошенников, пытающихся обмануть наших законных клиентов. Мы блокируем их учетные записи, но также делаем полный IP-запрет для таких очевидных русских / нигерийских / китайских мошенников. В нашем продукте много взаимодействия с пользователем, чата и т. Д., Что совсем не странно для такой платформы.
Эмми

1
... и никто из ваших мошенников не имеет динамических IP-адресов?
user253751

Ответы:


8

Вот идея левого поля ... вы можете «пустить» 50 заблокированных IP-адресов, добавив «сломанный» маршрут в таблицу маршрутов VPC для каждого IP-адреса.

Это не предотвратит попадание трафика IP-адресов в вашу инфраструктуру (это предотвратит только NACL и SG), но предотвратит обратный трафик, который заставит его «вернуться домой».


Я случайно обнулял маршрутизируемый трафик один раз, создав транзитный шлюз, настроив маршрутизацию, а затем удалив транзитный шлюз. Там может быть более простой способ, хотя.
Тим

Неплохая идея. Очень нестандартное мышление, спасибо. Я сделаю некоторые эксперименты. Может быть правильный путь, не платя за WAF
emmdee

0

Нет никакого способа увеличить ограничение на NACL, и большое количество правил NACL влияет на производительность сети.

Вы можете иметь архитектурную проблему превыше всего.

  1. Ваши экземпляры должны быть в общедоступных подсетях?
  2. Вы настроили шлюзы NAT для ограничения входящего трафика?
  3. Для тех экземпляров, которые должны быть в общедоступных подсетях, есть ли у вас минимальные правила группы входящей безопасности?
  4. Используете ли вы условия соответствия AWS WAF IP для блокировки нежелательного трафика в CloudFront и ваших балансировщиках нагрузки?

Если вы достигаете предела правила NACL, это, скорее всего, связано с тем, что вы не используете рекомендованный AWS подход к архитектуре VPC и использование таких сервисов, как WAF (и Shield для DDoS), для блокирования нежелательного трафика и явных атак.

Если вы беспокоитесь о DDoS-атаках: как помочь защитить динамические веб-приложения от DDoS-атак с помощью Amazon CloudFront и Amazon Route 53


Шлюзы NAT предназначены для исходящего трафика, а не входящего.
Тим

Исправьте @Tim, так что размещение ваших экземпляров в частных подсетях за шлюзами NAT дает им исходящее соединение, не открывая их для входящих атак, и нет необходимости блокировать IP-адреса в NACL
Fo.

WAF довольно дорог для сайтов с очень высоким трафиком. Попытка избежать этого по этой причине. Тот факт, что группы безопасности не могут явно блокировать, а веб-списки ACL имеют этот предел, выглядит как крупный захват денег.
Эмми

Я думаю, это зависит от варианта использования, который не был объяснен. Если причина блокирования этих IP-адресов заключается в том, что они атаковали веб-сервер, все равно необходим общий доступ к серверам, что означает балансировщик нагрузки или прокси-сервер. Частная подсеть не поможет в этом случае.
Тим

Мой пример использования - это 99% ELB, принимающих входящий трафик. Экземпляры EC2 являются частными за ELB.
Эмми

0

Это не совсем то, что вы просили, но может сделать работу достаточно хорошо.

Установите CloudFront перед вашей инфраструктурой. Используйте условия соответствия IP для эффективной блокировки трафика. CloudFront работает как со статическим, так и с динамическим контентом и может ускорять динамическое содержимое, поскольку оно использует магистраль AWS, а не общедоступный Интернет. Вот что говорят доктора

Если вы хотите разрешить некоторые веб-запросы и заблокировать другие на основе IP-адресов, с которых исходят запросы, создайте условие сопоставления IP-адресов для разрешаемых IP-адресов и другое условие сопоставления IP-адресов для блокируемых IP-адресов. ,

При использовании CloudFront вы должны заблокировать прямой доступ к любым общедоступным ресурсам, используя группы безопасности. Лямбда - AWS Обновление групп безопасности будет держать ваши группы безопасности до настоящего времени , чтобы позволить CloudFront трафика в но отвергает другие виды трафика. Если вы перенаправляете http на https с помощью CloudFront, вы можете немного изменить сценарии, чтобы предотвратить попадание http в вашу инфраструктуру. Вы также можете внести в белый список любые IP-адреса, которым нужен прямой доступ администратора.

Кроме того, вы можете использовать сторонние CDN, такие как CloudFlare. CloudFlare имеет эффективный межсетевой экран, но для количества правил, которые вы хотите, это 200 долларов в месяц. Это может быть дешевле, чем CloudFront, пропускная способность AWS довольно высока. Бесплатный план дает вам только 5 правил брандмауэра.


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

CloudFront также можно использовать для динамического контента aws.amazon.com/blogs/networking-and-content-delivery/…
Fo.

CloudFront может ускорять динамический контент, я полагаю, что он использует магистраль AWS, а не общедоступный Интернет. CloudFront имеет немного более низкую пропускную способность, чем EC2, и я думаю, что недавно я объявил, что пропускная способность CloudFront для EC2 бесплатна.
Тим
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.