Обхід межі правила ACL мережі AWS

Як максимум, до мережі ACL VPC може застосовуватися 40 правил.

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

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

Сподіваюся, що я не розумію цього на рівні системи / платформи. Групи безпеки чітко дозволяють, без жодних заперечень, тому вони не робитимуть трюку.

amazon-web-services access-control-list amazon-vpc

— emmdee
джерело

Використовуйте таке програмне забезпечення, як Ansible для управління iptables, і ви закінчили. Очевидно, що він працюватиме лише в екземплярах EC2; не LBs etc.

— Kyslik

Так, я погоджуюся з тим, що робити iptables добре для EC2, але 99% вхідного трафіку потрапляє до нашої структури ELB. Ми б платили за багато хітів цих відомих шахраїв, з якими нам доводиться мати справу. Дякую за внесок

— emmdee

Блокування 50 окремих IP-адрес здається дивним вимогою.

— користувач253751

... і жоден з ваших шахраїв не має динамічних IP-адрес?

— користувач253751

Іноді тримає їх у страху, іноді ні. Це ділова практика, яка фактично працює більшу частину часу, тому немає жодних причин зупиняти блокування ІР незалежно від того, якою ви будете думка. Здається, що 9 оновлень за 16 годин, це питання стало живим, це не є шаленим запитом. Продовжуйте утримувати цю гордість, хоча чомусь.

— emmdee

Відповіді:

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

Це не завадить трафіку IP-адрес потрапляти на вашу інфраструктуру (лише NACL та SGs запобігатимуть це), але це запобігає поверненню трафіку від кожного, що робить його "назад додому".

— Funky Penguin
джерело

Я випадково обернув нуль одного разу трафіком, створивши транзитний шлюз, налаштувавши маршрутизацію, а потім видалив транзитний шлюз. Однак може бути і простіший спосіб.

— Тім

Не погана ідея. Дуже поза рамками мислення дякую. Я буду робити експерименти. Це може бути правильний шлях, не платячи за WAF

— emmdee

Неможливо збільшити ліміт на NACL, і велика кількість правил NACL впливає на продуктивність мережі.

Ви можете мати архітектурне питання перш за все.

Чи мають ваші екземпляри бути у загальнодоступних підмережах?
Ви встановили NAT-шлюзи для обмеження вхідного трафіку?
Для тих випадків, які повинні бути у загальнодоступних підмережах, чи є у вас мінімальні правила вхідної групи безпеки?
Чи використовуєте Ви умови відповідності IP- WAF AWS для блокування небажаного трафіку до CloudFront та ваших навантажувачів?

Якщо ви досягаєте ліміту правил NACL, це, швидше за все, ви не застосовуєте рекомендований AWS підхід до архітектури VPC та використовуєте такі сервіси, як WAF (та Shield for DDoS) для блокування небажаного трафіку та явних атак.

Якщо вас турбують DDoS-атаки: як допомогти захистити динамічні веб-програми від DDoS-атак за допомогою Amazon CloudFront та Amazon Route 53

— Фо.
джерело

NAT шлюзи призначені для виїзного трафіку, а не для вхідного.

— Тім

Правильно @Tim, тому розміщення ваших примірників у приватних підмережах за NAT-шлюзами дає їм вихідний зв’язок, не відкриваючи їх для вхідних атак, і не потрібно блокувати IP-адреси в NACL

— Fo.

WAF досить дорогий для веб-сайтів з дуже високим трафіком. Намагаючись уникнути цього з цієї причини. Той факт, що групи безпеки не можуть чітко заблокувати і веб-ACL має цей ліміт, схоже, як головне захоплення грошових коштів.

— emmdee

Я думаю, це залежить від випадку використання, який не був пояснений. Якщо причиною блокування цих IP-адрес є те, що вони атакували веб-сервер, все ще повинен бути відкритий доступ до серверів, що означає балансир завантаження або проксі. Приватна підмережа не допоможе в цьому випадку.

— Тім

Мій випадок використання - 99% ELB, що займає вхідний трафік. Випадки EC2 є приватними поза межами ELB.

— emmdee

Це не зовсім те, про що ви просили, але це може зробити роботу досить добре.

Налаштуйте CloudFront перед вашою інфраструктурою. Використовуйте умови відповідності IP для ефективного блокування трафіку. CloudFront працює як зі статичним, так і з динамічним вмістом і може прискорювати динамічний контент, оскільки він використовує магістраль AWS, а не загальнодоступний Інтернет. Ось що кажуть документи

Якщо ви хочете дозволити деякі веб-запити та заблокувати інші на основі IP-адрес, з яких походять запити, створіть умову відповідності IP для IP-адрес, які ви хочете дозволити, та іншу умову відповідності IP-адрес для IP-адрес, які ви хочете заблокувати. .

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

Крім того, ви можете використовувати сторонні CDN, такі як CloudFlare. CloudFlare мають ефективний брандмауер, але для потрібної кількості правил це 200 доларів на місяць. Це може бути дешевше, ніж CloudFront, пропускна здатність AWS досить дорога. Безкоштовний план дає лише 5 правил брандмауера.

— Тім
джерело

Ми вже використовуємо хмарний фронт для статичного вмісту, але багато сайтів - це динамічний веб-контент.

— emmdee

CloudFront також можна використовувати для динамічного вмісту aws.amazon.com/blogs/networking-and-content-delivery/…

— Fo.

CloudFront може прискорити динамічний контент, я вважаю, що він використовує магістраль AWS, а не загальнодоступний Інтернет. CloudFront має дещо дешевшу пропускну здатність, ніж EC2, і я думаю, що я побачив повідомлення про те, що пропускна здатність CloudFront назад до EC2 є безкоштовною.

— Тім