1

Мне нужно использовать AWS WAF для моего веб-приложения, размещенного на AWS, для обеспечения дополнительной безопасности на основе правил. Я не мог найти какой-либо способ напрямую использовать WAF с ELB, а WAF требует Cloudfront для добавления WEB ACL для блокировки действий на основе правил. Итак, я добавил свое приложение ELB CNAME в облачный режим, только облачное имя, WebACL с блочным IP-протоколом и HTTPS-протоколом было обновлено облачным. Остальное все оставлено по умолчанию. как только WAF и Cloudfront с ELB CNAME были добавлены, я попытался получить доступ к ELAME CNAME с одного из ip-адресов, который находится в блочном ip-правиле в WAF. Я все еще могу получить доступ к своему веб-приложению с этого IP-адреса. Кроме того, я попытался проверить метрики cloudwatch для созданного веб-ACL, и я вижу, что он даже не попал. Во-первых, есть ли какой-либо хороший способ добиться того, что я делаю, а во-вторых, есть ли особый способ добавить ELB CNAME на облачную.Как использовать AWS WAF с применением ELB

Спасибо и наилучшие пожелания, Jay

+0

* Итак, я добавил свое приложение ELB CNAME в облачный режим, * где, в конфигурации CloudFront? Это то, что вы использовали бы как исходный сервер, и это единственное место. * * Я попытался получить доступ к электограмме CNAME из одного из ip-адресов, который находится в блочном ip-правиле в WAF. * Правильно, имя узла ELB указывает на ELB. У вас есть собственное доменное имя, указывающее на CloudFront? –

+0

Hi Michael, Да, домен, на который указывает облачный, принадлежит мне. поэтому значения, которые я добавил, это имя происхождения, которое является CNAME приложения ELB (я являюсь владельцем домена, CNAME ELB, как abc.mydomain.com). SSL-сертификат - это сертификат облачного интерфейса по умолчанию и добавлен правило WAF WEBACL, которое блокирует 1 Айпи адрес.Из этого ip-адреса я попытался получить доступ к CNAME ELB, и я смог его открыть, но он должен был быть заблокирован. – mrityunjay

ответ

7

обновление Service: оригинальные, расширенный ответ ниже был правильным в то время это было написано, но в настоящее время в основном применяется к классическому УДР, потому что - по состоянию на 2016- 12-07 - Балансировщики нагрузки (elbv2) теперь могут быть непосредственно интегрированы с брандмауэром веб-приложений (Amazon WAF).

Начиная с [2016-12-07] AWS WAF (брандмауэр веб-приложений) доступен на балансировщике нагрузки приложения (ALB). Теперь вы можете использовать AWS WAF непосредственно на балансирах нагрузки приложения (как внутренних, так и внешних) в VPC, чтобы защитить ваши веб-сайты и веб-службы. С помощью этого запуска клиенты теперь могут использовать AWS WAF на Amazon CloudFront и Application Load Balancer.

https://aws.amazon.com/about-aws/whats-new/2016/12/AWS-WAF-now-available-on-Application-Load-Balancer/


Похоже, вам нужны некоторые разъяснения относительно того, как эти части подходят друг к другу.

Итак, предположим, что ваш фактический сайт, который вы хотите защитить, - app.example.com.

Звучит так, как будто у вас есть CNAME elb.example.com, указывающий на назначенное имя хоста ELB, что-то вроде примера 123456789.us-west-2.elb.amazonaws.com. Если вы обращаетесь к любому из этих имен хостов, вы напрямую подключаетесь к ELB - независимо от того, что настроено в CloudFront или WAF. Эти машины по-прежнему доступны через Интернет.

Уловка здесь заключается в том, чтобы маршрутизировать трафик на CloudFront, где он может быть межсетевым экраном WAF, что означает, что должно произойти несколько дополнительных вещей: во-первых, это означает, что требуется дополнительное имя хоста, поэтому вы настраиваете app.example .com в DNS как CNAME (или Alias, если вы используете Route 53), указывая на имя хоста dxxxexample.cloudfront.net, назначенное вашему дистрибутиву.

Вы также можете получить доступ к своему sitr, используя назначенное имя узла CloudFront, непосредственно для тестирования. Доступ к этой конечной точке с заблокированного IP-адреса должен действительно привести к тому, что запрос будет отклонен.

Итак, конечная точка CloudFront - это то место, где вам нужно отправить свой трафик - не напрямую в ELB.

Разве это не оставляет ваш ELB еще открытым?

Да, это так ... так что следующий шаг - подключить это отверстие.

Если вы используете пользовательское происхождение, вы можете использовать пользовательские заголовки, чтобы пользователи не обходили CloudFront и запрашивали контент непосредственно из вашего источника.

http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/forward-custom-headers.html

Идея заключается в том, что вы установить секретное значение, известное только для серверов и CloudFront. CloudFront отправит это в заголовки вместе с каждым запросом, и ваши серверы потребуют, чтобы это значение присутствовало, иначе они будут играть в немые и выдавать ошибку - например, 503 Service Unavailable или 403 Forbidden или даже 404 Not Found.

Таким образом, вы создаете имя заголовка, например X-My-CloudFront-Secret-String, и случайную строку, например o+mJeNieamgKKS0Uu0A1Fqk7sOqa6Mlc3, и настраиваете это как пользовательский заголовок заголовка в CloudFront. Показанные здесь значения - произвольные примеры - это может быть что угодно.

Затем настройте веб-сервер приложения, чтобы отклонить любой запрос, если этот заголовок и соответствующее значение отсутствуют, потому что это то, как вы знаете, что запрос пришел из вашего конкретного дистрибутива CloudFront. Все остальное (кроме проверок работоспособности ELB, для которых вам нужно сделать исключение) не принадлежит к вашему дистрибутиву CloudFront и поэтому по определению является несанкционированным, поэтому ваш сервер должен отклонить его с ошибкой, но не слишком много объяснять в сообщение об ошибке.

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

Обратите внимание, что вы должны получить сертификат SSL для своего ELB (для имени узла elb.example.com) и настроить CloudFront для пересылки всех запросов на ваш ELB с помощью HTTPS. Вероятность перехвата трафика между CloudFront и ELB невысока, но это защита, которую вы должны учитывать при внедрении.

Вы можете дополнительно также уменьшить (но не устранить) наиболее несанкционированный доступ, блокируя все запросы, которые не прибывают из CloudFront разрешива только диапазонов CloudFront IP-адресов в группе безопасности УДРА - диапазоны CloudFront адресов являются documented (найдите JSON для блоков, обозначенных как CLOUDFRONT, и разрешите их только в группе безопасности ELB), но обратите внимание, что если вы это сделаете, вам все равно нужно настроить настраиваемую конфигурацию заголовка заголовка, описанную выше, поскольку, если вы блокируете только уровень IP, вы по-прежнему технически разрешаете кому-либо CloudFront для доступа к вашему ELB. Ваш дистрибутив CloudFront разделяет IP-адреса в пуле с другим дистрибутивом CloudFront, поэтому тот факт, что запрос поступает с CloudFront, не является достаточной гарантией того, что он находится от вашего CloudFront. Также обратите внимание, что вам нужно зарегистрироваться для уведомлений об изменениях, чтобы, если в CloudFront добавлены новые диапазоны адресов, вы узнаете, чтобы добавить их в свою группу безопасности.

+0

Спасибо, Майкл за ваш ответ, и я принимаю это как ответ. Это было объяснение, которое я искал. Я правильно понял, как работает Cloudfront и WAF, и я смог выполнить эту работу с моим проектом. AWS выпустила WAF с балансировщиком нагрузки приложений через два дня, я сейчас пытаюсь, так как это облегчит мою работу :) – mrityunjay

+0

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

 Смежные вопросы

  • Нет связанных вопросов^_^