EC2 pravilo samo za VPN: svaka pridružena sigurnosna grupa mora se složiti

Dodajete jedno ulazno pravilo za pool VPN klijenata, ne uklanjate ništa, a usluga je i dalje dostupna s interneta. Ništa nije pokvareno. Sigurnosna grupa nema nadjačavanje, prioritet ni konačno odbijanje protiv kojeg bi usko pravilo moglo pobijediti. Svaka grupa pridružena instanci doprinosi svojim dopuštenjima jednom zajedničkom skupu, a široko pravilo koje ste zaboravili još je u tom skupu. Učiniti instancu samo-VPN znači revidirati sve njih, a ne dodati ljepše zvučeće pravilo jednoj.

Zapišite uslugu prije nego što napišete pravilo

Počnite s točnim odredištem, protokolom i portom, te mrežnim sučeljem na kojem usluga stvarno sluša. Instanca s nekoliko sučelja ili nekoliko usluga na jednom portu zahtijeva reviziju po sučelju, jer se pridružene grupe mogu razlikovati. Zatim utvrdite koju adresu izvora to sučelje stvarno prima za VPN korisnika, a ne adresu koju klijent prikazuje u vlastitom prozoru veze.

Te se dvije adrese razilaze češće nego što ljudi očekuju kad se uključe prijevod i usmjeravanje.

Tri modela izvora, tri različita pravila

S privatnim usmjerenim pristupom instanca prima pool klijenata ili korporativni raspon, ovisno o tome kako se put usmjerava i prevodi. S javnom krajnjom točkom do koje se dolazi korporativnim izlazom instanca umjesto toga vidi korporativnu NAT adresu, i to samo ako to odredište stvarno koristi VPN put, jer podijeljeno tuneliranje može ga ostaviti na kućnoj vezi. S upravljanom krajnjom točkom Client VPN primjenjuje se dokumentirani model povezivanja i ciljne mreže, a adresa klijenta dolazi iz konfiguriranog CIDR-a klijenta.

Ono što ne radi jest referenciranje VPN pristupnika kao izvora sigurnosne grupe. Reference grupa podudaraju se s elastičnim mrežnim sučeljima unutar VPC-a ili povezane mreže, a pristupnik koji prosljeđuje pakete nije jedno od njih.

Pročitajte uniju kroz sve pridružene grupe

Otvorite instancu, pronađite njezino mrežno sučelje i popišite svaku sigurnosnu grupu pridruženu njoj. Za svaku provjerite svako pravilo koje pokriva vaš protokol i port, uključujući široke raspone portova i obje obitelji adresa. IPv4 pravilo iz 0.0.0.0/0 ne oslobađa vas provjere ::/0, a pravilo koje dopušta sav promet posve skriva pitanje porta. Tek nakon tog popisa možete reći koliko je stvarno dopuštenje za uslugu.

AWS referenca pravila opisuje sigurnosne grupe kao samo-dopuštajuće i navodi da se pravila svih pridruženih grupa agregiraju, što je cijeli mehanizam iza ovog neuspjeha.

Mrežni ACL-ovi zasebna su politika bez stanja s poredanim zapisima dopuštanja i odbijanja, a procjenjuju se na podmreži, a ne na instanci.

Ne odgovarajte zidom odbijanja

Dodavanje NACL odbijanja na razini podmreže kako biste oponašali vatrozid na koji ste navikli pogrešan je alat i rizičan. NACL zapisi su poredani i bez stanja, pa odbijanje postavljeno iznad postojećeg dopuštanja tiho kvari nepovezani promet, uključujući povratni put za sesije koje ste pokušavali zadržati. Popravite široko dopuštenje sigurnosne grupe u grupi koja ga posjeduje, a zatim ostavite ACL na miru osim ako stvarno nije dio dizajna.

Uklanjanje javne adrese s instance jače je jamstvo, a ujedno je i arhitektonska promjena s administrativnim i aplikacijskim posljedicama, a ne potvrdni okvir na popisu dopuštenja.

Testirajte novom sesijom i zadržite način ulaska

Prije nego što ukinete bilo koje postojeće dopuštenje, potvrdite odobren neovisni administrativni put, jer pravilo koje ćete obrisati može biti ono o kojem ovisi oporavak vaše sesije. Zatim testirajte novu dopuštenu vezu s VPN-a i novu odbijenu vezu s odobrenog testnog puta bez VPN-a. Postojeće praćene sesije preživljavaju promjene pravila na način koji stare otvorene ljuske čini beskorisnima kao dokaz prihvaćanja.

Na kraju, zadržite vlastitu autorizaciju aplikacije na mjestu. Prevedeni korporativni izlaz može predstavljati stotine ljudi, a mrežni pristup nikada nije identificirao pojedinog korisnika ni njegov uređaj.