EC2-regulo nur por VPN: ĉiu alkroĉita sekureca grupo devas konsenti

Vi aldonas unu envenan regulon por la VPN-klienta baseno, forigas nenion, kaj la servo ankoraŭ estas atingebla el la interreto. Nenio estas difektita. Sekureca grupo ne havas superregadon, prioritaton aŭ finan malpermeson, kontraŭ kiu la mallarĝa regulo povus venki. Ĉiu grupo alkroĉita al la instanco kontribuas siajn proprajn permesojn al unu komuna aro, kaj la larĝa regulo, kiun vi forgesis, ankoraŭ estas en tiu aro. Fari la instancon nur-VPN signifas revizii ĉiujn, ne aldoni pli bone sonantan regulon al unu.

Skribu la servon antaŭ ol skribi la regulon

Komencu per la preciza celo, protokolo kaj pordo, kaj la reta interfaco, sur kiu la servo vere aŭskultas. Instanco kun pluraj interfacoj aŭ pluraj servoj sur unu pordo postulas la revizion por ĉiu interfaco, ĉar la alkroĉitaj grupoj povas malsami. Poste determini kiun fontan adreson tiu interfaco vere ricevas por VPN-uzanto, anstataŭ la adreson, kiun la kliento montras en sia propra konekta fenestro.

Tiuj du adresoj diverĝas pli ofte, ol homoj atendas, tuj kiam tradukado kaj enkursigado eniras la ludon.

Tri fontmodeloj, tri malsamaj reguloj

Kun privata enkursigita aliro, la instanco ricevas la klientan basenon aŭ la firmaan gamon, depende de tio, kiel la vojo estas enkursigita kaj tradukita. Kun publika finpunkto atingata tra firmaa eliro, la instanco vidas anstataŭe la firmaan NAT-adreson, kaj nur se tiu celo vere uzas la VPN-vojon, ĉar dividita tunelado povas lasi ĝin sur hejma konekto. Kun administrata Client VPN-finpunkto validas la dokumentita modelo de asociiĝo kaj celreto, kaj la klienta adreso venas el la agordita klienta CIDR.

Kio ne funkcias, estas referenci VPN-pordegon kiel fonton de sekureca grupo. Grupaj referencoj kongruas kun elastaj retaj interfacoj ene de la VPC aŭ de kunligita reto, kaj pordego, kiu plusendas pakaĵojn, ne estas unu el ili.

Legu la kunigon tra ĉiuj alkroĉitaj grupoj

Malfermu la instancon, trovu ĝian retan interfacon, kaj listigu ĉiun sekurecan grupon alkroĉitan al ĝi. Por ĉiu kontrolu ĉiun regulon, kiu kovras vian protokolon kaj pordon, inkluzive larĝajn pordajn intervalojn kaj ambaŭ adresfamiliojn. IPv4-regulo el 0.0.0.0/0 ne liberigas vin de kontrolado de ::/0, kaj regulo permesanta la tutan trafikon tute kaŝas la pordan demandon. Nur post tiu inventaro vi povas diri, kio estas la efektiva permeso por la servo.

La AWS-regula referenco priskribas sekurecajn grupojn kiel nur-permesantaj kaj deklaras, ke la reguloj de ĉiuj alkroĉitaj grupoj estas agregataj, kio estas la tuta mekanismo malantaŭ ĉi tiu malsukceso.

Retaj ACL-oj estas aparta, senstata politiko kun ordigitaj permesaj kaj malpermesaj eroj, kaj ili estas taksataj sur la subreto, ne sur la instanco.

Ne respondu per malpermesa muro

Aldoni subret-larĝan NACL-malpermeson por imiti fajroŝirmilon, al kiu vi kutimas, estas la malĝusta ilo kaj riska. NACL-eroj estas ordigitaj kaj senstataj, do malpermeso metita super ekzistanta permeso silentete rompas nerilatan trafikon, inkluzive la revenan vojon por la sesioj, kiujn vi provis konservi. Riparu la larĝan sekurecgrupan permeson en la grupo, kiu posedas ĝin, kaj poste lasu la ACL trankvile, krom se ĝi vere estas parto de la dezajno.

Forigi publikan adreson de la instanco estas pli forta garantio, kaj ĝi ankaŭ estas arkitektura ŝanĝo kun administraj kaj aplikaj sekvoj, ne markobutono sur permeslisto.

Testu per nova sesio kaj konservu vojon enen

Antaŭ ol vi retiriĝos de iu ekzistanta permeso, konfirmu aprobitan sendependan administran vojon, ĉar la regulo, kiun vi baldaŭ forigos, povas esti tiu, de kiu dependas la restarigo de via sesio. Poste testu novan permesitan konekton el la VPN kaj novan rifuzitan konekton el rajtigita ne-VPN-testa vojo. Ekzistantaj spurataj sesioj postvivas regulajn ŝanĝojn tiel, ke malnovaj malfermitaj ŝeloj fariĝas senutilaj kiel akcepta pruvo.

Fine, konservu la propran rajtigon de la aplikaĵo. Tradukita firmaa eliro povas reprezenti centojn da homoj, kaj reta akcepto neniam identigis unuopan uzanton aŭ lian aparaton.