Doch in iepenbiere DNS-ûndersyk tsjin in ynterne loadbalancer en jo kinne in partikulier adres weromkrije, wat as in ferkearde konfiguraasje liket oant jo kontrolearje wêr't it record foar is. AWS dokumintearret dat nammen fan ynterne loadbalancers iepenbier oplosber wêze kinne wylst har knopen allinnich partikuliere adressen hawwe. De resolver antwurde wêr't de tsjinst is; hy makke gjin rûte, iepene gjin befeiligingsgroep en autentisearre nimmen. Oft dat antwurd in probleem is, hinget ôf fan feiten dy't jo yn folchoarder kontrolearje kinne.

Stap ien: lês it skema, net it IP

It skema-fjild is de eigen ferklearring fan 'e loadbalancer oer syn grins. aws elbv2 describe-load-balancers --names app-internal jout in Scheme werom mei de wearde internal of internet-facing, plus in adrestype foar IPv4 of dûbeld stapel. In op it ynternet rjochte loadbalancer kin noch altyd trochstjoere nei partikuliere doelen, dus it sjen fan partikuliere backend-adressen bewiist neat oer de foarkant.

Skriuw it skema op foardat jo nei eat oars sjogge, want elk letter oardiel hinget derfan ôf. It fertelt ek hokker kontrôles besteane, fan befeiligingsgroepen en listener-regels oant de funksjeset fan dat loadbalancer-type. In skema dat fan in âlde konsoleskermprint kopiearre is, is slimmer as gjin notysje. Lês it op 'e nij út 'e API en plak de wearde yn it ticket.

Stap twa: sjoch wêr't de namme nei oplost

Freegje fan bûten de VPC mei dig +short app-internal-1234567890.eu-west-1.elb.amazonaws.com en notearje oft de antwurden yn 10.0.0.0/8, 172.16.0.0/12 of 192.168.0.0/16 lizze. In partikulier antwurd fan in iepenbiere resolver is it ferwachte gedrach foar in namme fan in ynterne loadbalancer; it is gjin bewiis dat it adres fan it ynternet ôf berikber is.

Los deselde namme fan binnen de VPC op en fergelykje. As de twa antwurden ferskille, sjogge jo split-horizon-nammejouwing, en dat ferskil is in ûntwerpdetail, gjin lek.

Stap trije: lis de paden op dy't der komme kinne

In partikulier adres is berikber fan oeral wêr't in rûte en in befeiligingsregel binne. Lis se bewust op: site-to-site VPN, kliïnt-VPN, VPC-peering, transit gateway-keppelings, Direct Connect en elke proxy of bastion binnen de VPC. Ien fan harren is it bedoelde paad, en de oare binne dejinge dy't in oanfaller sykje soe.

Kontrolearje dan de kontrôles op elk paad: befeiligingsgroepen op 'e loadbalancer, netwurk-ACL's op 'e subnetten en de routing dy't it paad überhaupt bestean lit. De measte rapportearre gefallen fan in bleatstelde ynterne tsjinst wurde hjir oplost, itsij om't der in ûnbedoelde peering wie, itsij om't it paad bedoeld wie en de applikaasje gjin autentikaasje hie.

Stap fjouwer: test de listener en de applikaasje apart

Probearje te ferbinen fan in netwurk dat de tsjinst net berikke moatte soe en befêstigje dat jo net kinne. Probearje dan fan ien dat wol moatte, en befêstigje dat jo in listener berikke. Dy twa resultaten skiede netwurkberikberens fan applikaasjegedrach, en se binne it iennichste bewiis dat foar de bleatstellingsfraach ta docht.

In berikbere listener is net itselde as in tagonklike applikaasje. Kontrolearje it TLS-sertifikaat en it protokolbelied, dan de eigen autentikaasje en autorisaasje fan 'e applikaasje. In yntern helpmiddel dat elke oanropper op it bedriuws-VPN akseptearret, is bleatsteld oan elke kompromittearre laptop op dat VPN, wat in oar risiko is as in op it ynternet rjochte ien, mar noch altyd in risiko.

Tink derom dat kontrôles per type ferskille. Fjoermuorren fan 'e applikaasjelaach hingje oan ien loadbalancer-famylje en net oan 'e oare, dus befêstigje wat der wier beskikber is foar it skema en type foar jo, ynstee fan gelykheid oan te nimmen.

Stap fiif: beslút oft de namme sels ta docht

Iepenbiere oplosberens kin in tsjinstnamme, in regio en in adresberik iepenbierje. Behannelje dat as in fraach oer ynformaasje-iepenbaring mei in beliedsantwurd, net as in automatysk ynsidint: hâld gefoelige saaklike termen bûten boarnenammen, en notearje de iepenbaring yn jo risikoregister as de nammejouwing mear ferriedt as jo wolle.

As de organisaasje in partikuliere namme-ûnderfining wol, kin in partikuliere hoste sône in alias tsjinje dy't allinnich binnen de keppele VPC's oplost. Dat feroaret de namme dy't brûkers sjogge; it makket de troch de provider generearre namme net geheim en it ferwideret gjin netwurkpaad.

Probearje adressen net fêst te pinjen om it antwurd te ferbergjen. Loadbalancer-adressen feroarje, pinjen brekt TLS-falidaasjegewoanten, en de kontrôle dy't jo wier nedich hawwe, is wa't de ferbining meitsje kin en wat de applikaasje fan harren freget. Kontrolearje de fjouwer feiten, skriuw se op, en de fraach is net mear dûbelsinnich.

Relatearre artikelen