Limitazione dell'accesso alla rete del contenitore Docker

Sono in procinto di creare un contenitore Docker solo SFTP , che verrà utilizzato da più persone al solo scopo di caricare e gestire i file nel proprio chrootambiente ed.

Sulla carta, è abbastanza sicuro: disabiliterò ogni forma di bashaccesso e non eseguirò nessun altro processo al suo interno. Tuttavia, vorrei renderlo ancora più duro:

Voglio impedire a questo contenitore di accedere a Internet dall'interno, tranne per il suo scopo di essere un server SFTP.

Per chiarire le cose: so come impedire al mondo esterno di accedere al mio contenitore: posso impostare le iptablesregole in entrata e posso esporre solo la porta SFTP nel mio comando run docker.

Tuttavia vorrei far fallire il seguente comando (come esempio), quando eseguito all'interno del contenitore:

curl google.com

La mia intenzione è di ridurre la quantità di danno che un contenitore hackerato può fare (non potendo essere utilizzato per inviare e-mail di spam, ecc.).

Ha ancora senso inserire alcune regole di ingresso all'interno dell'istanza della finestra mobile per evitare gli attacchi, ma dovrai limitare l'accesso in uscita (Internet) da qualsiasi router a monte a cui si collega l'immagine della finestra mobile. Il motivo è che, se si tenta di bloccare l'accesso in uscita con le regole del firewall all'interno dell'istanza, se l'istanza è compromessa, tali regole potrebbero essere rimosse dall'aggressore. Bloccando l'uscita attraverso il router dell'istanza, si blocca l'accesso in uscita anche in caso di compromissione: anche l'attaccante dovrebbe compromettere il router.

Ok, quindi dopo aver ricevuto alcuni commenti che spiegano che il filtro era destinato all'host del contenitore, è un po 'più chiaro cosa sta cercando di ottenere. Nel qual caso, sull'host, dovresti aggiungere alcune regole simili a questa:

iptables -A FORWARD -s lo.cal.sub.net -d con.tai.ner.ip -j ACCEPT
iptables -A FORWARD -s con.tai.ner.ip -d lo.cal.sub.net -j ACCEPT
iptables -A FORWARD -s ! lo.cal.sub.net -d con.tai.ner.ip -p tcp --dport sftp -j ACCEPT
iptables -A FORWARD -s con.tai.ner.ip -d ! lo.cal.sub.net -p tcp --sport sftp -j ACCEPT
iptables -A FORWARD -s con.tai.ner.ip -m state --state related,established -j ACCEPT
iptables -A FORWARD -s con.tai.ner.ip -j DROP

Le prime due regole sono per l'accesso tra l'host e il contenitore. La terza regola dice (approssimativamente) che tutto ciò che non è la sottorete dell'host diretto a SFTP è giusto per noi; la quarta è la regola in uscita che è sostanzialmente una gemella alla terza; la quinta regola è un catch-all (nel caso in cui siano utilizzate altre porte correlate), anche se non dovrebbe essere necessario, è possibile rimuoverlo; l'ultima regola è la magia attiva che impedisce l'accesso a qualsiasi cosa diversa dalla sottorete host. Poiché l'accesso viene fornito nelle prime poche regole, non si attiverà mai a meno che non si applichi nessuna delle regole precedenti, nel qual caso stiamo dicendo "non ci importa di ciò che vuoi, non hai abbinato nulla per cui sei approvato, quindi non puoi arrivarci da qui ". Il traffico in entrata dall'esterno sarà soddisfatto dalla 3a e 4a regola.

Questo non è un problema specifico per la finestra mobile. Ci sono un paio di modi per risolverlo.

1. Utilizzare le iptablesregole stateful per consentire le connessioni in entrata e il traffico correlato / stabilito, quindi bloccare tutto il resto.

2. Utilizzare un servizio solo sftp come ProFTPD che non è in grado di eseguire una shell.

In generale, se non si consente agli utenti di ottenere una shell e non si consente loro di eseguire programmi dall'interno del contenitore, non è necessario preoccuparsene.

Questo è solo un rapido brainstorming e non l'ho ancora testato. Ti consigliamo di controllarlo in laboratorio prima di portarlo in produzione.

Per impedire il traffico in uscita su porte non SSH (SFTP) e Web, è possibile applicare criteri tramite IPTABLES o un altro firewall Layer4 al traffico DROP o REJECT proveniente dal segmento utilizzato dai contenitori docker destinati a 0.0.0.0/0 tranne quando Destinazione La porta è TCP22.

Per risolvere il problema di andare in unapprove-on-the-web, potresti provare a configurare un'istanza di un proxy di filtro / cache, come squid o bluecoat, che è in ascolto sull'interfaccia docker0 e che sta utilizzando la rotta defalt dell'host per uscire su Internet. Da lì, è possibile applicare criteri basati su molti criteri, nonché salvare l'utilizzo della rete memorizzando nella cache il contenuto statico. Potresti voler usare NAT (penso che IPTABLES e Masquerade lo forniscano in Linux) sul computer host per imporre in modo trasparente l'uso del proxy (ho descritto questo nella mia risposta a voglio delegare solo HTTP ma non sono sicuro di cosa fare con il traffico HTTPS ). Ciò implica una ragione per andare sul web in primo luogo che è in linea con le politiche della tua azienda.

A causa della natura di SSH (su cui si basa SFTP), non sarà possibile fornire l'interdizione del traffico per lo spostamento di file se non si implementa una politica in base alla quale i contenitori possono utilizzare solo coppie di chiavi fornite dall'utente. Questo è un bene per te, perché ti dà un po '" Non avevo visibilità o controllo sui file trasferiti"difesa se uno dei tuoi clienti trasferisce qualcosa di illegale (come una violazione dell'IP, o utilizza il tuo servizio per esfiltrare informazioni che portano un'etichetta di classificazione o commerciano in CP), se sei portato in tribunale per qualcosa che i tuoi clienti fanno (pensa analogo a lo stato di corriere comune per le telecomunicazioni). Questo è un problema per te perché non puoi memorizzare nella cache file invariati, spesso modificati, e perché qualsiasi politica che scrivi nel contratto con i tuoi clienti sarà sostanzialmente inapplicabile con mezzi tecnici.