Come un proxy pubblico raggiunge un’origine privata attraverso una VPN

Pubblicare un sito web attraverso un tunnel e dare agli utenti l’accesso VPN sono due disposizioni diverse che condividono un cavo. Nella prima, un proxy inverso pubblico accetta la richiesta del visitatore e la inoltra attraverso il tunnel a un’origine che nessuno può raggiungere direttamente. Nella seconda, l’utente deve unirsi alla VPN prima che l’applicazione sia accessibile. Mescolare le due descrizioni è il modo in cui un backend privato finisce per essere esposto pubblicamente.

Due modelli che sembrano uguali su un diagramma

Disegnate le frecce prima di scegliere qualsiasi cosa. Un modello di pubblicazione pubblica va dal browser al proxy su HTTPS, poi dal proxy all’origine attraverso il tunnel, e l’origine non accetta mai una connessione da Internet. Un modello solo VPN va dal client al gateway, e l’applicazione è raggiungibile solo dall’interno di quel percorso. Il portatile dell’utente si trova sulla stessa rete dell’applicazione, ed è tutto il senso di quel modello.

I modelli differiscono in chi autentica e dove. Nel primo, il proxy è l’ingresso pubblico e inoltra qualsiasi richiesta arrivi, compresa una ostile, in base alla politica configurata su di esso. Nel secondo, l’accessibilità stessa è la porta, che è un’ammissione grossolana ma reale.

Dove si ferma TLS, e cosa dimostra realmente

TLS tra browser e proxy protegge quel salto e consente al browser di verificare il sito che intendeva visitare. Se il proxy termina TLS, la richiesta esiste in forma leggibile all’interno di quel processo prima di essere inoltrata. Una seconda sessione TLS verso l’origine può proteggere il salto successivo e verificare separatamente l’endpoint dell’applicazione. Nessuna delle due sessioni decide quale persona può usare l’applicazione. Un certificato jolly sul proxy non si estende nemmeno a quel secondo salto.

Questa è la parte che le persone riducono alla parola cifrato. Riservatezza, integrità e identità del server sono proprietà del trasporto; l’autorizzazione è una decisione dell’applicazione. Un indirizzo privato dietro un tunnel cambia chi può raggiungere il socket, non chi può accedere una volta arrivato.

Fidatevi delle intestazioni inoltrate solo dal proxy

Le applicazioni che registrano o autorizzano in base all’indirizzo del client leggono di solito un’intestazione che il proxy aggiunge. Quell’intestazione è solo testo, quindi qualsiasi cosa possa raggiungere direttamente l’origine può rivendicare qualsiasi indirizzo voglia. Limitate l’origine in modo che solo l’indirizzo del tunnel del proxy possa connettersi, e configurate l’applicazione per accettare l’intestazione solo da quell’indirizzo.

curl -s -o /dev/null -w '%{http_code}
' -H 'X-Forwarded-For: 203.0.113.9' http://172.20.5.40/

Se quella richiesta riesce da un host che non è il proxy, l’origine si fida di un’intestazione che dovrebbe ignorare. Correggete il listener prima di toccare l’applicazione. Un rifiuto è un risultato molto migliore di una riga di log che porta un indirizzo falsificato.

Mantenete l’origine raggiungibile da esattamente un posto

Legate il listener dell’origine all’indirizzo del tunnel o isolatelo con un firewall verso il proxy, poi confermate cosa sta effettivamente ascoltando. Un servizio avviato con un binding jolly accetta connessioni su ogni interfaccia dell’host, compresa una che avete dimenticato essere instradabile. La tabella di ascolto è la verità di base, non il file di configurazione che intendevate applicare. Se il binding jolly è intenzionale, il firewall deve comunque essere il componente che lo restringe.

ss -ltnp | grep -E ':(80|443)'

Fate la stessa revisione per le interfacce di gestione, che sono l’esposizione accidentale abituale. Poi scrivete i due modelli separatamente: il sito pubblico attraverso il proxy, e l’interfaccia di amministrazione raggiungibile solo attraverso il tunnel. La frase che il server è dietro una VPN non dice nulla di tutto ciò.