Вътрешен ALB с публично DNS име: наистина ли е изложен?

Изпълнете публична DNS заявка към вътрешен балансьор на натоварването и може да получите частен адрес, което изглежда като грешна конфигурация, докато не проверите за какво е записът. AWS документира, че имената на вътрешни балансьори могат да бъдат публично разрешими, докато възлите им държат само частни адреси. Резолверът отговори къде е услугата; той не създаде маршрут, не отвори група за сигурност и не удостовери никого. Дали този отговор е проблем зависи от факти, които можете да проверите по ред.

Първа стъпка: четете схемата, не IP адреса

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

Запишете схемата, преди да гледате каквото и да е друго, защото всяка следваща преценка зависи от нея. Тя също показва какви контроли съществуват — от групи за сигурност и правила на слушателя до набора от функции на този тип балансьор. Схема, копирана от стар екран на конзолата, е по-лоша от липса на бележка. Прочетете я отново от 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, или пътят е бил умишлен, а приложението не е имало удостоверяване.

Четвърта стъпка: тествайте слушателя и приложението поотделно

Опитайте да се свържете от мрежа, която не би трябвало да достига услугата, и потвърдете, че не можете. После опитайте от такава, която би трябвало, и потвърдете, че достигате слушател. Тези два резултата разделят мрежовата достижимост от поведението на приложението и те са единственото доказателство, което има значение за въпроса за излагането.

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

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

Пета стъпка: решете дали самото име има значение

Публичната разрешимост може да разкрие име на услуга, регион и диапазон от адреси. Отнасяйте се към това като към въпрос за разкриване на информация с политически отговор, а не като автоматичен инцидент: дръжте чувствителните бизнес термини извън имената на ресурси и отбележете разкриването в регистъра си на рискове, ако конвенцията за именуване показва повече, отколкото искате.

Ако организацията иска частно именуване, частна хостирана зона може да обслужва псевдоним, който се разрешава само в свързаните VPC. Това променя името, което потребителите виждат; не прави името, генерирано от доставчика, тайна и не премахва мрежов път.

Не се опитвайте да заковавате адреси, за да скриете отговора. Адресите на балансьора се менят, заковаването разваля навиците за TLS валидация, а контролът, който наистина ви трябва, е кой може да установи връзката и какво приложението изисква от него. Проверете четирите факта, запишете ги и въпросът престава да е двусмислен.