Esposizione della rete dei container

Cos’è Esposizione della rete dei container?

Pubblicare una porta di un container la associa per impostazione predefinita a ogni interfaccia, quindi un mapping pensato per lo sviluppo locale può mettere un database su internet pubblico senza che sembri cambiare alcuna regola del firewall. Sulla rete bridge predefinita, inoltre, ogni container può raggiungere ogni altro container. Questo esercizio copre un database esposto tramite un mapping di porta: osserva un attaccante connettersi direttamente senza coinvolgere alcuna applicazione, quindi correggi il problema associandolo a localhost e collocando i servizi su una rete definita dall'utente.

Cosa imparerai in Esposizione della rete dei container

• A ogni interfaccia dell'host, incluse quelle pubbliche, motivo per cui una comodità pensata per lo sviluppo può esporre un database a internet.
• Il mapping viene creato dal runtime dei container sull'host, quindi nulla nella configurazione dei security group cloud cambia per rifletterlo.
• Ogni container su di essa può raggiungere ogni altro container, quindi la compromissione di un singolo container dà accesso di rete a tutti gli altri.
• Ruotare le credenziali che erano raggiungibili, perché chiudere la porta non invalida nulla di ciò che un attaccante ha già raccolto.

Esposizione della rete dei container — Fasi della formazione

1. Un database su internet aperto

   Bob non è dentro a nulla. Settimane fa ha acquistato un dump che includeva una credenziale di sola lettura per un database di Halvexis, ma una credenziale è inutile se non si può raggiungere il database. Quindi scansiona gli host dei data store dell'azienda per vedere se qualcuno risponde dall'esterno.

2. Dritto dentro, nessuna applicazione

   Non c'è nessuna pagina di login, nessuna API, nessun rate limit. Una porta di database pubblicata parla il protocollo Postgres grezzo a chiunque riesca a raggiungerla. Bob punta un client per database direttamente su di essa e si autentica con la credenziale che aveva già.

3. Leggi la tabella residents

   La credenziale è di sola lettura, ed è tutto ciò di cui Bob ha bisogno. Interroga la tabella che contiene gli inquilini della piattaforma e i loro dettagli, direttamente dalla produzione.

4. Cosa è cambiato

   Bob ha questa esatta credenziale da mesi e non l'ha mai usata.

5. Il monitoraggio segnala il traffico

   Halvexis esegue il monitoraggio cloud sui suoi host di produzione. Non sa a cosa serva il database; riporta ciò che ha visto.

6. Trova la porta aperta

   Se i security group non sono cambiati, l'esposizione è stata creata sull'host stesso, dal modo in cui un container ha pubblicato la sua porta. Alice elenca il container del database e legge la colonna che indica a quali interfacce è associata la porta.

7. Dove viene pubblicata la porta

   Il mapping della porta proviene dal file Compose che definisce lo stack. Alice lo apre per vedere la riga che ha pubblicato la 5432.

8. La riga responsabile

   Un unico mapping, scritto nel modo in cui uno sviluppatore lo scrive sul proprio laptop, è ciò che ha messo il database su internet quando questo stack è stato distribuito in produzione.

9. Associalo a localhost

   L'API raggiunge il database attraverso la rete Compose tramite il suo nome di servizio, non attraverso una porta host pubblicata. Quindi il mapping dell'host non ha alcun bisogno di essere pubblico. Alice lo fissa all'interfaccia di loopback, così solo l'host stesso, e i container sulla sua rete, possono raggiungerlo.

10. Leggi il binding corretto

    La modifica è un solo prefisso di interfaccia, ma è l'intera correzione. Alice esamina il mapping associato prima di ridistribuire, per vedere esattamente cosa è ora raggiungibile e da dove.