Почему мой AWS NACL разрешает доступ по протоколу HTTP только с правилами для входящего трафика "Весь трафик" или "Все TCP"?

Question

У меня настроен AWS VPC с 3 подсетями - 1 общедоступной и 2 частными. У меня есть экземпляр EC2 со связанным хранилищем эластичных блоков (EBS содержит мой веб-сайт), работающим в общедоступной подсети, и базой данных MySQL в частных подсетях. Группа безопасности, подключенная к экземпляру EC2, разрешает входящий доступ HTTP из любого источника и доступ SSH только с моего IP-адреса. Правило безопасности исходящего трафика разрешает весь трафик всем адресатам. Группа безопасности, связанная с базой данных, разрешает доступ MySQL/Aurora только как для входящего, так и для исходящего трафика, причем источником и получателем является группа безопасности общего доступа.

Все это работало отлично, но когда я подошел к настройке NACL для подсетей, я столкнулся с загвоздкой, которую не могу понять. Если я изменю правило для входящего трафика в NACL общедоступной подсети на любое другое значение, кроме "Весь трафик" или "Весь TCP", я получаю ответ с ошибкой со своего веб-сайта:Unable to connect to the database: Connection timed out. 2002.Я пробовал использовать все доступные варианты и всегда получаю такой результат. Я также получаю неожиданный результат от NACL, прикрепленного к частным подсетям: если я запрещаю весь доступ (т. Е. Удаляю все правила, кроме правила "запретить все" по умолчанию) как для входящего, так и для исходящего трафика, веб-сайт продолжает работать правильно. (при условии, что правило для входящего трафика в NACL общедоступной подсети установлено на "Весь трафик" или "Весь TCP").

Аналогичный вопрос был задан здесь, но ответ был по существу не пробуйте использовать NACLs, а не объяснение того, как использовать их правильно. Я изучаю сертификацию архитектора решений AWS, поэтому, очевидно, мне необходимо понимать их использование, и в моем реальном примере ни одна из рекомендуемых AWS настроек NACL не работает.

Answer 1

Я знаю, что это очень поздно, но я нашел ответ на этот вопрос, потому что я продолжаю сталкиваться с одной и той же проблемой и всегда пытаюсь решить ее с помощью правила ALL TRAFFIC. Однако больше этого делать не нужно; здесь ответили . Ответ Stack Overflow содержит ссылку на основной источник AWS, который фактически отвечает на ваш вопрос.

Вкратце, вам нужно добавить пользовательское правило TCP в исходящий NACL и добавить диапазон портов 1024–65535. Это позволит клиентам, запрашивающим доступ через различные порты, получать запрошенные данные. Если вы не добавите это правило, исходящий трафик не будет доходить до запрашивающих клиентов. Я проверил это через ICMP (ping), ssh (22), http (80) и https (443).

Зачем нужно добавлять порты? Судя по всему, AWS отправляет трафик через один из портов между 1024 и 63535. В частности, «когда клиент подключается к серверу, случайный порт из эфемерного диапазона портов (1024-63535) становится исходным портом клиента». (Смотрите вторую ссылку.)

Общее соглашение вокруг ACL заключается в том, что, поскольку они не имеют состояния, входящий трафик отправляется обратно через обязательный соответствующий порт, поэтому большинство новичков (или не практикующих, таких как я) могут пропустить часть « эфемерных портов » при создании пользовательских VPC. .

Как бы то ни было, я удалил все исходящие порты и оставил только временный диапазон портов. Исходящий трафик запрещен. Похоже, что ACL все еще нуждается в этих перечисленных портах, чтобы он мог отправлять запрошенный трафик через эти порты. Возможно, исходящие данные сначала проходят через соответствующий исходящий порт, а затем направляются на определенный эфемерный порт, к которому подключен клиент. Чтобы убедиться, что входящие правила все еще работают, я смог подключиться по ssh к EC2 в общедоступной подсети в VPC, но не смог выполнить ping google.com оттуда.

Альтернативная рабочая теория, объясняющая, почему исходящий трафик был запрещен, заключается в том, что все входящие и соответствующие исходящие порты находятся ниже 1024-63535. Возможно, поэтому исходящие данные не подхватываются этим диапазоном. Я займусь настройкой различных протоколов (ssh, http/s, imcp) на более высокие номера портов в пределах диапазона эфемерных портов, чтобы продолжить проверку второго пункта.

====== [Отредактировано для добавления выводов ======

В качестве продолжения я работал над альтернативной теорией, и вполне вероятно, что исходящий трафик не направлялся через эфемерные порты, поскольку включенные порты (22, 80 и 443) не перекрываются с эфемерным диапазоном портов (1024-63535). .

Я проверил это, перенастроив свой протокол ssh для входа через порт 2222, отредактировав файл sshd_config на EC2 ( инструкции здесь . Я также перенастроил свой протокол http, чтобы обеспечить доступ через порт 1888. Вам также необходимо отредактировать файл конфигурации выбранного вами веб-сервера. , который в моем случае был apache, таким образом, httpd. (Вы можете экстраполировать из этой ссылки). Для новичков файлы конфигурации обычно находятся в папке etc. Обязательно перезапустите каждую службу на EC2 ([ссылка][8] <-- используйте соглашение для перезапуска ssh)

Оба этих перенастроенных порта должны были обеспечить перекрытие с эфемерными портами. После того, как я внес изменения в EC2, я изменил входящее правило группы безопасности, удалил 22, 80 и 443 и добавил 1888 и 2222. Затем я пошел в NACL и удалил входящие правила 22, 80 и 443 и добавил 1888 и 2222. [![inbound][9]][9]Для NACL я удалил исходящие правила 22, 80 и 443 и просто оставил пользовательское правило TCP и добавил эфемерные порты 1024-63535.[![только эфемерные][10]][10]

Я могу использовать ssh, используя -p 2222, и получить доступ к веб-серверу через 1888, оба из которых перекрываются с эфемерными портами.[![p 1888][11]][11][![p2222][12]][12]

[8]: https://( https://hoststud.com/resources/how-to-start-stop-or-restart-apache-server-on-centos-linux-server.191/[9]: https://stackru.com/images/21b3245e7c048d1be5776b7f7f73ae2cdaf74532.png[10]: https://stackru.com/images/811906e3827a69c6f9f32bb0c4d336fc6e54d925.png[11]: https://stackru.com/images/79127d13df101dbb02585d13304cc92db20e4d15.png[12]: https://stackru.com/images/d9ad4c00a724df16df91365c9af429f678a566a2.png