EC2-regel alleen voor VPN: elke gekoppelde beveiligingsgroep moet het eens zijn

U voegt één inkomende regel toe voor de VPN-clientpool, verwijdert niets, en de dienst blijft bereikbaar vanaf het internet. Niets is kapot. Een beveiligingsgroep heeft geen overschrijving, prioriteit of definitieve weigering waartegen de smalle regel kan winnen. Elke groep die aan de instantie is gekoppeld, draagt zijn eigen toestemmingen bij aan één gecombineerde set, en de brede regel die u vergat, zit nog steeds in die set. De instantie alleen-VPN maken betekent ze allemaal controleren, niet een beter klinkende regel aan één ervan toevoegen.

Schrijf de dienst op voordat u de regel schrijft

Begin met de exacte bestemming, het protocol en de poort, en de netwerkinterface waarop de dienst werkelijk luistert. Een instantie met meerdere interfaces of meerdere diensten op één poort vereist de controle per interface, omdat de gekoppelde groepen kunnen verschillen. Bepaal daarna welk bronadres die interface werkelijk ontvangt voor een VPN-gebruiker, in plaats van het adres dat de client in zijn eigen verbindingsvenster toont.

Die twee adressen lopen vaker uiteen dan mensen verwachten zodra vertaling en routing in het spel zijn.

Drie bronmodellen, drie verschillende regels

Bij privé gerouteerde toegang ontvangt de instantie de clientpool of de bedrijfsrange, afhankelijk van hoe het pad wordt gerouteerd en vertaald. Bij een openbaar eindpunt dat via de bedrijfsuitgang wordt bereikt, ziet de instantie in plaats daarvan het bedrijfs-NAT-adres, en alleen als die bestemming werkelijk het VPN-pad gebruikt, omdat split-tunneling het op een thuisverbinding kan laten. Bij een beheerd Client VPN-eindpunt geldt het gedocumenteerde associatie- en doelnetwerkmodel, en het clientadres komt uit de geconfigureerde client-CIDR.

Wat niet werkt, is een VPN-gateway als bron van een beveiligingsgroep opgeven. Groepsverwijzingen komen overeen met elastische netwerkinterfaces binnen de VPC of een peered netwerk, en een gateway die pakketten doorstuurt is er daar geen van.

Lees de vereniging over alle gekoppelde groepen

Open de instantie, zoek de netwerkinterface en som elke gekoppelde beveiligingsgroep op. Controleer voor elk daarvan elke regel die uw protocol en poort dekt, inclusief brede poortreeksen en beide adresfamilies. Een IPv4-regel van 0.0.0.0/0 ontslaat u niet van het controleren van ::/0, en een regel die al het verkeer toestaat verbergt de poortvraag volledig. Pas na die inventarisatie kunt u zeggen wat de effectieve toestemming voor de dienst is.

De AWS-regelreferentie beschrijft beveiligingsgroepen als alleen-toestaan en stelt dat de regels van alle gekoppelde groepen worden samengevoegd, en dat is het hele mechanisme achter deze fout.

Netwerk-ACL's zijn een apart, staatloos beleid met geordende toestaan- en weigeringsregels, en ze worden op het subnet geëvalueerd en niet op de instantie.

Antwoord niet met een weigeringsmuur

Een subnetbrede NACL-weigering toevoegen om een firewall na te bootsen waaraan u gewend bent, is het verkeerde gereedschap en een riskante. NACL-regels zijn geordend en staatloos, dus een weigering boven een bestaande toestemming breekt stilzwijgend ongerelateerd verkeer, inclusief het retourpad voor de sessies die u wilde behouden. Repareer de brede beveiligingsgroepstoestemming in de groep die hem bezit, en laat de ACL daarna met rust, tenzij die echt deel van het ontwerp is.

Een openbaar adres van de instantie verwijderen is een sterker waarborg, en het is ook een architectuurwijziging met administratieve en applicatiegevolgen, geen vinkje op een toelatingslijst.

Test met een nieuwe sessie en houd een weg naar binnen

Voordat u een bestaande toestemming opheft, bevestig een goedgekeurd onafhankelijk beheerpad, want de regel die u gaat verwijderen kan degene zijn waarvan uw sessieherstel afhangt. Test daarna een nieuwe toegestane verbinding vanaf de VPN en een nieuwe geweigerde verbinding vanaf een geautoriseerd niet-VPN-testpad. Bestaande gevolgde sessies overleven regelwijzigingen op manieren die oude open shells nutteloos maken als acceptatiebewijs.

Ten slotte, houd de eigen autorisatie van de applicatie op zijn plaats. Een vertaalde bedrijfsuitgang kan honderden mensen vertegenwoordigen, en netwerktoelating heeft nooit een individuele gebruiker of zijn apparaat geïdentificeerd.