Interna ALB kun publika DNS-nomo: ĉu ĝi vere estas elmetita?

Farigu publikan DNS-demandon al interna ŝarĝbalancilo kaj vi eble ricevos privatan adreson, kio aspektas kiel misagordo ĝis vi kontrolos por kio la rikordo estas. AWS dokumentas, ke nomoj de internaj ŝarĝbalanciloj povas esti publike solveblaj dum iliaj nodoj tenas nur privatajn adresojn. La solvilo respondis kie la servo estas; ĝi ne kreis vojon, ne malfermis sekurecan grupon kaj ne aŭtentikigis iun. Ĉu tiu respondo estas problemo dependas de faktoj, kiujn vi povas kontroli laŭorde.

Unua paŝo: legu la skemon, ne la IP

La kampo de skemo estas la propra aserto de la ŝarĝbalancilo pri sia limo. aws elbv2 describe-load-balancers --names app-internal redonas Scheme kun valoro internal aŭ internet-facing, plus adresan tipon por IPv4 aŭ duobla stako. Interret-alrigita ŝarĝbalancilo ankoraŭ povas plusendi al privataj celoj, do vidi privatajn malantaŭajn adresojn pruvas nenion pri la antaŭo.

Notu la skemon antaŭ ol rigardi ion ajn alian, ĉar ĉiu posta juĝo dependas de ĝi. Ĝi ankaŭ diras kiuj kontroloj ekzistas, de sekurecaj grupoj kaj aŭskultantaj reguloj ĝis la funkciaro de tiu tipo de ŝarĝbalancilo. Skemo kopiita el malnova ekrankopio de la konzolo estas pli malbona ol neniu noto. Relutu ĝin el la API kaj algluu la valoron en la bileton.

Dua paŝo: vidu al kio la nomo solviĝas

Demandu de ekster la VPC per dig +short app-internal-1234567890.eu-west-1.elb.amazonaws.com kaj notu ĉu la respondoj estas en 10.0.0.0/8, 172.16.0.0/12 aŭ 192.168.0.0/16. Privata respondo de publika solvilo estas la atendata konduto por nomo de interna ŝarĝbalancilo; ĝi ne estas pruvo, ke la adreso estas enirebla el la interreto.

Solvu la saman nomon de interne de la VPC kaj komparu. Se la du respondoj malsamas, vi vidas split-horizon nomadon, kaj tiu diferenco estas dezajna detalo, ne liko.

Tria paŝo: listigu la vojojn, kiuj povas atingi ĝin

Privata adreso estas atingebla de kie ajn ekzistas vojo kaj sekureca regulo. Listigu ilin intence: reteja VPN, klienta VPN, VPC-peering, aldonaĵoj de transit gateway, Direct Connect, kaj ajna prokurilo aŭ bastiono ene de la VPC. Unu el ili estas la celata vojo, kaj la ceteraj estas tiuj, kiujn atakanto serĉus.

Poste kontrolu la kontrolojn sur ĉiu vojo: sekurecaj grupoj sur la ŝarĝbalancilo, retaj ACL-oj sur la subretoj kaj la enkursigo, kiu entute kreas la vojon. Plej multaj raportitaj kazoj de elmetita interna servo solviĝas ĉi tie, ĉu ĉar ekzistis neintencita peering, ĉu ĉar la vojo estis intenca kaj la aplikaĵo havis neniun aŭtentikigon.

Kvara paŝo: testu la aŭskultanton kaj la aplikaĵon aparte

Provu konektiĝi el reto, kiu ne devus atingi la servon, kaj konfirmu, ke vi ne povas. Poste provu el unu, kiu devus, kaj konfirmu, ke vi atingas aŭskultanton. Tiuj du rezultoj apartigas retan atingeblon de aplikaĵa konduto, kaj ili estas la sola pruvo grava por la demando pri elmeto.

Atingebla aŭskultanto ne samas kiel alirebla aplikaĵo. Kontrolu la TLS-atestilon kaj protokolan politikon, poste la propran aŭtentikigon kaj rajtigon de la aplikaĵo. Interna ilo, kiu akceptas ĉiun alvokanton en la entreprena VPN, estas elmetita al ĉiu kompromitita tekkomputilo en tiu VPN, kio estas alia risko ol interret-alrigita, sed ankoraŭ risko.

Memoru, ke kontroloj varias laŭ tipo. Fajroŝirmiloj de la aplikaĵa tavolo aliĝas al unu familio de ŝarĝbalanciloj kaj ne al la alia, do konfirmu, kio fakte disponeblas por la skemo kaj tipo antaŭ vi, anstataŭ supozi egalecon.

Kvina paŝo: decidu ĉu la nomo mem gravas

Publika solveblo povas malkaŝi servan nomon, regionon kaj adresan intervalon. Traktu tion kiel demandon pri malkaŝo de informoj kun politika respondo, ne kiel aŭtomatan incidenton: tenu sentemajn komercajn terminojn ekster resurso-nomoj, kaj notu la malkaŝon en via riska registro se la nomiga konvencio malkaŝas pli ol vi volas.

Se la organizo volas privatan nomigan sperton, privata gastigita zono povas servi alias, kiu solviĝas nur ene de la asociitaj VPC-oj. Tio ŝanĝas la nomon, kiun uzantoj vidas; ĝi ne faras sekreta la nomon generitan de la provizanto kaj ne forigas ajnan retan vojon.

Ne provu fiksi adresojn por kaŝi la respondon. Adresoj de la ŝarĝbalancilo ŝanĝiĝas, fiksado difektas kutimojn de TLS-kontrolo, kaj la kontrolo, kiun vi vere bezonas, estas kiu povas establi la konekton kaj kion la aplikaĵo postulas de ili. Kontrolu la kvar faktojn, skribu ilin, kaj la demando ĉesas esti ambigua.