Quanto è sicuro SSH ForceCommand su un host di salto?

Ho la seguente configurazione nella mia rete:

Internet <--> Bastion <--> Local Network

Ho diversi utenti e ogni utente è assegnato a una macchina specifica. O in altre parole: ogni utente deve avere accesso solo a uno di quei server. Ad esempio: Utente1 -> Macchina1, Utente2 -> Macchina2 e così via.

Quegli utenti si collegheranno dall'esterno della mia rete e ho considerato molte opzioni su come inoltrare le loro connessioni tramite il mio host bastion alla mia rete.

Alla fine ho optato per Match Blocks e forcecommand.

Quindi, il mio / etc / ssh / sshd_config sul bastione è simile al seguente:

Match User User1
        ForceCommand ssh User1@Machine1 $SSH_ORIGINAL_COMMAND

Utente1 si collega all'host del bastione che stabilisce automaticamente una connessione con Machine1.

Per quanto ho capito ForceCommand, User1 non avrà alcun reale accesso all'host del bastione, perché tutte le sue operazioni saranno gestite per prime dal blocco delle partite, quindi dirottate su Machine1. Tuttavia è davvero vero? È già abbastanza per essere una configurazione sicura? L'utente è comunque imprigionato su Machine1, quindi non avrà molte possibilità lì.

Il modo in cui uso un host bastion sta usando ProxyCommande il -Wflag come in questo esempio:

ssh -o ProxyCommand='ssh -W %h:%p user@bastion' user@machine

Uso questo approccio per motivi di sicurezza. La comunicazione tra client e macchina di destinazione è crittografata e autenticata end-to-end, il che significa che rimane protetta anche se il bastione è compromesso. Un host bastion compromesso fornirebbe non meno sicurezza rispetto all'utilizzo di ssh end-to-end senza un bastione.

Elimina inoltre la necessità di utilizzare qualsiasi inoltro agente. Il client può utilizzare prima l'autenticazione basata su chiave per accedere al bastione e poi di nuovo per accedere all'host di destinazione senza che a nessuno di questi venga fornita una connessione agente che potrebbe essere utilizzata per abusare della chiave privata presente sul client.

Limita anche il codice da cui dipendo dall'host del bastione. Non ho bisogno di eseguire alcun comando sul bastione. -Wimplica il flag no command e un unico port forwarding, questo port forwarding è tutto ciò che l'host del bastione deve consentire.

Con questo approccio in mente, la mia raccomandazione sarebbe quella di bloccare il più possibile l'host del bastione consentendo l'utilizzo solo dei comandi della struttura sopra.

Il ~/.ssh/authorized_keysfile sul bastione potrebbe essere di proprietà di root (così come tutte le directory sul percorso dalla radice del file system ad esso), questo riduce il rischio che potrebbe essere modificato anche se qualcuno è riuscito a entrare come utente non privilegiato sul host bastione.

Nel authorized_keysprivilegi del cliente può essere limitato utilizzando le opzioni command, no-agent-forwarding, no-pty, no-user-rc, no-X11-forwarding, così come usando permitopenper l'inoltro delle porte limite per consentire solo l'accesso alla porta 22 dell'host che questo utente è consentito l'accesso a.

In linea di principio questo approccio sarebbe sicuro anche se più utenti condividessero il singolo nome utente sul bastione. Ma ottieni un po 'più di separazione usando nomi utente separati sul bastione.

Puoi aggirare facilmente ForceCommand dal momento che si avvia all'avvio della shell. Ciò significa essenzialmente che il tuo file rc della shell viene elaborato prima e poi ForceCommand se gli consenti di arrivarci. Semplice exec shnel tuo file rc della shell genererà un'altra shell e manterrà ForceCommand in attesa di uscire da questa shell.

Quindi linea di fondo; se l'utente può in qualche modo modificare la sua shell rc (diciamo .bashrc) tramite ftp, sftp, scp o in qualche altro modo, ForceCommand non è davvero qualcosa su cui fare affidamento.

Immagino che vada bene per la maggior parte del tempo, ma il problema con la sicurezza è che le cose a cui nessuno è ancora riuscito a pensare. Non ci sono garanzie

Come per esempio per molto tempo nessuno aveva pensato troppo al modo in cui le funzioni potevano essere create da variabili d'ambiente in bash, ma recentemente le persone hanno capito che potevano essere sovvertite e uno degli effetti di ciò era che ForceCommand poteva essere aggirato (at almeno come implementato nel file authorized_keys) se la shell degli utenti era bash. Bash è stato risolto e, si spera, la tua versione è aggiornata, ma succede cose del genere.

Non sono del tutto sicuro se la definizione di ForceCommand sia effettivamente uguale alla definizione di quei comandi nei file authorized_keys. Non l'ho guardato da vicino.

Rendi il .bashrcproprietario di root:usergrpma ancora leggibile dall'sshd in esecuzione come utente che accede. Imposta permessi / proprietario su $ HOME, impedendo la creazione di nuovi file da parte dell'utente. In questo modo il root controlla i contenuti di .bashrc, permettendogli di fare ciò di cui ha bisogno, ma l'utente stesso non può modificare tali impostazioni o autorizzazioni su file / directory che consentirebbero indirettamente loro di modificare i contenuti di .bashrc.

Ho un'altra idea Per ogni utente sul server bastion puoi definire la loro shell in / etc / passwd in modo che sia uno script bash che esegue semplicemente ssh user1 @ machine1, user2 @ machine2, ecc. In questo modo ti assicurerai che non abbiano alcun valido shell sul server stesso e che si collegano semplicemente alla macchina alla quale dovrebbero connettersi.