AWS NACL - работает, только если в правилах входящих и исходящих разрешен 0.0.0.0/0

Question

снова получает укус NACL. Я пытаюсь s sh из локальной сети, VPN-соединение между сайтами, к экземпляру в VP C, связанному с Transit Gateway. Вот что я имею в виду, чтобы заставить его работать:

Source : 10.0.12.0/28    [VPN]
Target : 10.114.1.0/28   [VPC]
------------------------------
Security Group:
        inbound  => SSH         | TCP | 22  | 10.0.12.0/28
        outbound => All traffic | All | All | 0.0.0.0/0
Network ACL:
      inbound:
         101 | SSH (22)   | TCP (6)      | 22            | 10.0.12.0/28 | ALLOW
         111 | Custom TCP | Rule TCP (6) | 32768 - 65535 | 0.0.0.0/0    | ALLOW
      outbound:
         101 | Custom TCP | Rule TCP (6) | 0 - 65535 | 0.0.0.0/0    | ALLOW

Я понимаю требование к эфемерному диапазону портов, но не понимаю, почему оно должно быть только 0.0.0.0/0. Кроме того, для исходящих правил он работает только для всего диапазона портов. Мой вопрос: правильно ли я поступаю - так ли это должно работать? Безопасность не позволяет мне использовать, но можно использовать указанный c адрес источника / назначения. Любые предложения от кого-либо?

-S

Answer 1

Вот два предложения, которые будут работать:

1. Эфемерные порты

   Эфемерные порты от 1024 до 65535. Все эти порты должны быть разрешены, чтобы разрешить возврат трафика c для S SH.

   Более подробная информация о эфемерных портах:

   https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html#nacl -фемеральные порты

---

Диапазон IP-адресов источника

Допустимый диапазон может быть ограничен только теми подсетями, из которых разрешен S SH.

Предположим, что Клиентский компьютер S SH находится в сети 192.168.1.0/24, затем 0.0.0.0/0 может быть заменен на 192.168.1.0/24 в NACL

. Это гарантирует, что только клиент из 192.168 .1.0 / 24 сеть может сделать s sh хостам VP C.

Answer 2

Хорошо, отвечая на мой собственный вопрос: это действительно было связано с Transit Gateway, который я использовал. Когда соединение проходит через TGW, требуется другой NACL (где правила NACL по умолчанию удалены), связывающий подсети, используемые TGW, с этими правилами:

inbound:
    500 | Custom TCP | Rule TCP (6) | 32768 - 61000 | 0.0.0.0/0    | ALLOW
outbound:
    500 | Custom TCP | Rule TCP (6) | 0 - 65535     | 0.0.0.0/0    | ALLOW

После этого все работает нормально. Нет необходимости разрешать правило входящих эфемерных портов (например, 111 в моем исходном сообщении) в NACL, связанном с частными su bnet (s). Еще один урок нацла

-S

Answer 3

Как правило, не должно быть причин для изменения сетевого ACL (NACL) . Это позволяет все трафик c, в обе стороны, по умолчанию. Существуют только очень конкретные c сценарии использования, когда стоит изменить NACL, например создание сетевых DMZ, блокировка ненадлежащих IP-адресов или блокировка su bnet для максимальной безопасности.

Группы безопасности немного отличаются. Настройки Outbound по умолчанию открыты. Это основано на предположении, что системы под вашим контролем "делают правильные вещи". Если им нужен доступ к ресурсу, то пусть. Тем не менее, вы можете sh ограничить исходящую группу безопасности, когда вы будете sh для повышения безопасности. Но, как правило, у вас должна быть причина для этого.

Входящие правила в группе безопасности должны всегда быть минимально возможными. Запуск веб-сервера? Затем откройте 80 и / или 443, предположительно, кому-нибудь на Inte rnet (0.0.0.0/0). Разрешение доступа S SH? Затем откройте порт 22, но только на свой собственный IP-адрес, чтобы ограничить потенциальную область для атак.

Группы безопасности с состоянием , что означает, что ответ разрешен через группу безопасности. Итак, если исходящее соединение установлено с портом 8080 на каком-либо сервере, то ответ разрешается снова, даже если этот порт не указан в списке входящих правил.

Таким образом, глядя на вашу конфигурацию:

Security Group:
        inbound  => SSH         | TCP | 22  | 10.0.12.0/28
        outbound => All traffic | All | All | 0.0.0.0/0

• Вы разумно ограничиваете доступ S SH через порт 22 * ​​1028 *
• Исходящая конфигурация в порядке, особенно если вам нужно программное обеспечение (или операционной системы) в экземпляре для доступа к Inte rnet (например, для загрузки обновлений программного обеспечения)

Network ACL:
      inbound:
         101 | SSH (22)   | TCP (6)      | 22            | 10.0.12.0/28 | ALLOW
         111 | Custom TCP | Rule TCP (6) | 32768 - 65535 | 0.0.0.0/0    | ALLOW
      outbound:
         101 | Custom TCP | Rule TCP (6) | 0 - 65535 | 0.0.0.0/0    | ALLOW

• Правила по умолчанию уже разрешают все трафик c, поэтому есть нет необходимости добавлять дополнительное правило для S SH. (Как только найдено соответствующее правило, трафик c разрешен / запрещен.)
• Ваше правило входящего NACL теперь запрещает все трафики c ниже 32768 (кроме S SH ), это означает, что весь порт su bnet не может быть доступен через порты, такие как 80, 443, 8080, 3306 (MySQL) и т. д. c. Это может вызвать проблемы со службами, которые вы используете в этом su bnet. Если у вас нет причин специально исключать такие порты, я рекомендую вам сбросить настройки NACL по умолчанию на «Разрешить все».