Внутрішній ALB із публічним DNS-іменем: чи справді він відкритий?

Виконайте публічний DNS-запит до внутрішнього балансувальника навантаження, і ви можете отримати приватну адресу, що виглядає як помилка конфігурації, доки не перевірите, для чого цей запис. AWS документує, що імена внутрішніх балансувальників можуть бути публічно розв'язуваними, хоча їхні вузли мають лише приватні адреси. Резолвер відповів, де розташована служба; він не створив маршрут, не відкрив групу безпеки й нікого не автентифікував. Чи є ця відповідь проблемою, залежить від фактів, які можна перевірити по черзі.

Крок перший: читайте схему, а не IP

Поле схеми — це власне твердження балансувальника про його межу. aws elbv2 describe-load-balancers --names app-internal повертає Scheme зі значенням internal або internet-facing, плюс тип адреси для IPv4 або подвійного стеку. Балансувальник, обернений до інтернету, все одно може переспрямовувати на приватні цілі, тому вигляд приватних адрес бекенду нічого не доводить про фронтенд.

Запишіть схему, перш ніж дивитися на будь-що інше, бо кожне подальше судження залежить від неї. Вона також каже, які засоби контролю існують, від груп безпеки й правил listener до набору функцій цього типу балансувальника. Схема, скопійована зі старого знімка консолі, гірша за відсутність нотатки. Перечитайте її з API і вставте значення в тікет.

Крок другий: подивіться, у що розв'язується ім'я

Запитайте ззовні VPC за допомогою dig +short app-internal-1234567890.eu-west-1.elb.amazonaws.com і зауважте, чи відповіді в 10.0.0.0/8, 172.16.0.0/12 або 192.168.0.0/16. Приватна відповідь від публічного резолвера — очікувана поведінка для імені внутрішнього балансувальника; це не доказ, що адреса маршрутизується з інтернету.

Розв'яжіть те саме ім'я зсередини VPC і порівняйте. Якщо дві відповіді різняться, ви бачите іменування split-horizon, і ця різниця є деталлю дизайну, а не витоком.

Крок третій: перелічіть шляхи, які можуть до нього дістатися

Приватна адреса доступна скрізь, де існує маршрут і правило безпеки. Перелічіть їх навмисно: VPN між майданчиками, клієнтський VPN, VPC peering, підключення transit gateway, Direct Connect і будь-який проксі або бастіон усередині VPC. Один із них — запланований шлях, а решта — ті, які шукав би зловмисник.

Потім перевірте засоби контролю на кожному шляху: групи безпеки на балансувальнику, мережеві ACL на підмережах і маршрутизацію, яка взагалі створює шлях. Більшість заявлених випадків відкритої внутрішньої служби вирішується тут: або існував ненавмисний peering, або шлях був навмисним, а застосунок не мав автентифікації.

Крок четвертий: перевірте listener і застосунок окремо

Спробуйте підключитися з мережі, яка не повинна досягати служби, і підтвердьте, що не можете. Потім спробуйте з тієї, яка повинна, і підтвердьте, що досягаєте listener. Ці два результати відокремлюють мережеву доступність від поведінки застосунку, і вони є єдиним доказом, важливим для питання відкритості.

Досяжний listener — не те саме, що доступний застосунок. Перевірте TLS-сертифікат і політику протоколу, потім автентифікацію й авторизацію самого застосунку. Внутрішній інструмент, який приймає будь-якого викликача в корпоративному VPN, відкритий для кожного скомпрометованого ноутбука в цьому VPN, що є іншим ризиком, ніж обернений до інтернету, але все одно ризиком.

Пам'ятайте, що засоби контролю різняться за типом. Міжмережеві екрани прикладного рівня приєднуються до однієї родини балансувальників, а не до іншої, тому підтвердьте, що реально доступно для схеми й типу перед вами, замість припущення рівності.

Крок п'ятий: вирішіть, чи має значення саме ім'я

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

Якщо організація хоче приватного іменування, приватна розміщена зона може надавати псевдонім, який розв'язується лише в пов'язаних VPC. Це змінює ім'я, яке бачать користувачі; це не робить ім'я, згенероване провайдером, секретним і не видаляє жодного мережевого шляху.

Не намагайтеся закріплювати адреси, щоб приховати відповідь. Адреси балансувальника змінюються, закріплення псує звички перевірки TLS, а контроль, який вам справді потрібен, — це хто може встановити з'єднання і що застосунок від нього вимагає. Перевірте чотири факти, запишіть їх, і питання перестає бути двозначним.