Regola EC2 solo VPN: ogni gruppo di sicurezza collegato deve essere d'accordo

Aggiungi una regola in ingresso per il pool di client VPN, non rimuovi nulla, e il servizio resta raggiungibile da internet. Nulla è rotto. Un gruppo di sicurezza non ha un'override, una priorità o un rifiuto finale contro cui la regola ristretta possa vincere. Ogni gruppo collegato all'istanza contribuisce con le proprie autorizzazioni a un unico insieme combinato, e la regola ampia che hai dimenticato è ancora in quell'insieme. Rendere l'istanza solo VPN significa controllarli tutti, non aggiungere una regola che suona meglio a uno solo.

Scrivi il servizio prima di scrivere la regola

Parti dalla destinazione esatta, dal protocollo e dalla porta, e dall'interfaccia di rete su cui il servizio ascolta davvero. Un'istanza con più interfacce o più servizi su una porta richiede il controllo per interfaccia, perché i gruppi collegati possono differire. Poi determina quale indirizzo di origine quell'interfaccia riceve davvero per un utente VPN, invece dell'indirizzo che il client mostra nella propria finestra di connessione.

Questi due indirizzi divergono più spesso di quanto la gente si aspetti appena entrano in gioco la traduzione e l'instradamento.

Tre modelli di origine, tre regole diverse

Con accesso privato instradato, l'istanza riceve il pool di client o l'intervallo aziendale, a seconda di come il percorso viene instradato e tradotto. Con un endpoint pubblico raggiunto tramite l'uscita aziendale, l'istanza vede invece l'indirizzo NAT aziendale, e solo se quella destinazione usa davvero il percorso VPN, poiché il tunneling diviso può lasciarla su una connessione domestica. Con un endpoint Client VPN gestito, si applica il modello documentato di associazione e rete di destinazione, e l'indirizzo del client proviene dal CIDR client configurato.

Ciò che non funziona è referenziare un gateway VPN come origine di un gruppo di sicurezza. I riferimenti di gruppo corrispondono a interfacce di rete elastiche all'interno della VPC o di una rete associata, e un gateway che inoltra pacchetti non è una di esse.

Leggi l'unione su tutti i gruppi collegati

Apri l'istanza, trova l'interfaccia di rete e elenca ogni gruppo di sicurezza collegato. Per ciascuno, controlla ogni regola che copre il tuo protocollo e la tua porta, compresi gli intervalli di porte ampi ed entrambe le famiglie di indirizzi. Una regola IPv4 da 0.0.0.0/0 non ti esime dal controllare ::/0, e una regola che consente tutto il traffico nasconde del tutto la questione della porta. Solo dopo questo inventario puoi dire qual è l'autorizzazione effettiva per il servizio.

Il riferimento alle regole di AWS descrive i gruppi di sicurezza come solo-consentire e afferma che le regole di tutti i gruppi collegati vengono aggregate, ed è l'intero meccanismo dietro questo errore.

Le ACL di rete sono una politica separata e senza stato con voci ordinate di autorizzazione e rifiuto, e vengono valutate sulla sottorete, non sull'istanza.

Non rispondere con un muro di rifiuti

Aggiungere un rifiuto NACL a livello di sottorete per imitare un firewall a cui sei abituato è lo strumento sbagliato e rischioso. Le voci NACL sono ordinate e senza stato, quindi un rifiuto posto sopra un'autorizzazione esistente rompe in silenzio traffico non correlato, compreso il percorso di ritorno delle sessioni che stavi cercando di mantenere. Correggi l'autorizzazione ampia del gruppo di sicurezza nel gruppo che la possiede, poi lascia stare l'ACL, a meno che non faccia davvero parte del progetto.

Rimuovere un indirizzo pubblico dall'istanza è una garanzia più forte, ed è anche un cambiamento architetturale con conseguenze amministrative e applicative, non una casella su un elenco di autorizzazioni.

Prova con una nuova sessione e conserva un modo per entrare

Prima di ritirare qualsiasi autorizzazione esistente, conferma un percorso amministrativo indipendente e approvato, perché la regola che stai per eliminare potrebbe essere quella da cui dipende il ripristino della tua sessione. Poi prova una nuova connessione consentita dalla VPN e una nuova connessione negata da un percorso di test autorizzato non VPN. Le sessioni tracciate esistenti sopravvivono ai cambiamenti delle regole in modi che rendono le vecchie shell aperte inutili come prova di accettazione.

Infine, mantieni l'autorizzazione propria dell'applicazione. Un'uscita aziendale tradotta può rappresentare centinaia di persone, e l'ammissione alla rete non ha mai identificato un singolo utente o il suo dispositivo.