Proteggi il tuo deployment SSH con l'autenticazione a due fattori WiKID

Proteggi il tuo deployment SSH con l’autenticazione a due fattori WiKID

SSH offre un canale altamente sicuro per l’amministrazione remota dei server. Tuttavia, se affronti un audit per requisiti normativi o aziendali, come il PCI di Visa/Mastercard, devi essere consapevole di alcune potenziali carenze relative all’autenticazione che potrebbero causare mal di testa durante un audit. Ad esempio:

Non c’è modo di controllare quali utenti hanno l’autorizzazione con chiave pubblica
Non c’è modo di imporre la complessità della passphrase (o anche di essere sicuri che ne venga utilizzata una)
Non c’è modo di far scadere una chiave pubblica

In questo documento dimostreremo come combinare l’autenticazione a due fattori di WiKID con un server gateway SSH con chiavi private ospitate per creare una soluzione di accesso remoto altamente sicura, auditabile e facile da usare. Il WiKID Strong Authentication System è una soluzione di autenticazione a due fattori commerciale/open source. Prima configureremo un dominio sul server WiKID, poi aggiungeremo i server come client di rete al server WiKID e infine configureremo la box gateway e i server target - nel nostro caso, server Fedora Core 6.

Aggiungere un dominio al server WiKID

Crea dominio

Crea un client di rete

Dopo aver salvato le informazioni sul dominio, fai clic sulla scheda Client di rete e Crea nuovo client di rete. Inserisci un nome per questo client e l’indirizzo IP del gateway SSH sulla rete interna. Seleziona Radius come protocollo e il dominio che hai creato sopra come dominio.

Crea client di rete

Fai clic su Aggiungi per accedere alla pagina successiva e inserire il segreto condiviso per Radius.

Crea client di rete 2

Dovrai ripetere questo processo per ogni server sulla tua rete.

Configurare il gateway SSH

Ora configureremo il gateway SSH centrale. Questa box linux è il gateway/proxy per tutti i server di produzione nella farm. Dovrebbe essere bloccata in modo rigoroso senza software o servizi superflui in esecuzione su di essa. Dovrebbe avere un’interfaccia esterna per le connessioni in entrata e un’interfaccia interna per le connessioni interne. Prima, configureremo la box gateway per utilizzare WiKID per l’autenticazione forte degli utenti SSH. Modifica il tuo file /etc/pam.d/sshd in questo modo:

#%PAM-1.0   
auth       sufficient   /lib/security/pam_radius_auth.so   
auth       include      system-auth   
account    required     pam_nologin.so   
account    include      system-auth   
password   include      system-auth   
session    include      system-auth   
session    required     pam_loginuid.so

Aggiungi il tuo server WiKID al file /etc/raddb/server, utilizzando l’indirizzo IP interno del server WiKID e il segreto condiviso che hai inserito nella pagina di creazione del client di rete:

# server[:port] shared_secret      timeout (s)   
127.0.0.1       secret             1   
xxx.xxx.xxx.xx  wikidserver_secret 3

Aggiungiamo anche un po’ di sicurezza alla configurazione SSH qui. Apri il tuo file /etc/ssh/sshd_config (non il vicino file ssh_config). Aggiungi queste opzioni di configurazione:

#Protocol 2,1   
#Controlla che sia consentito solo il protocollo 2:   
Protocol 2   
#Disabilita il login come root:   
PermitRootLogin no   
#Disabilita gli account senza password:   
PermitEmptyPasswords no

Se desideri cambiare la porta, puoi farlo. Non fermerà un attaccante, ma potrebbe ridurre gli eventi di log causati da script kiddies. Questa box gateway è ora impostata per utilizzare le password usa e getta WiKID per l’autenticazione SSH. Tutti gli utenti devono essere registrati con il server WiKID e nessuno può accedere come root. Prima di lasciare questa box, faremo qualcosa di un po’ diverso: faremo creare agli utenti la loro chiave privata RSA sulla gateway. Una volta che ogni utente è connesso alla box con WiKID, chiedi loro di creare le loro chiavi:

ssh-keygen -t rsa

A mio avviso, le passphrase per queste chiavi sono ridondanti. Sono qui solo per creare una funzionalità di accesso unico nella farm di server. Ovviamente, devi fare attenzione a garantire che gli utenti non abbiano accesso ad altre chiavi.

Configurare i server target

Ovviamente, configuriamo questi server per accettare solo richieste SSH in arrivo dal gateway. Lo facciamo limitando l’accesso sulla porta 22 ai nostri indirizzi interni. Modifica /etc/sysconfig/iptables e aggiungi o modifica la riga per SSH sulla porta 22:

-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp -s 192.168.1.0/24 --dport 22 -j ACCEPT

È probabile che tu possa utilizzare la configurazione standard per sshd_config, che consente l’autenticazione con chiave pubblica. Quindi, abbiamo finito!

Conclusione

SSH remoto è ora estremamente sicuro. Nessun utente può accedere alla farm di server senza prima ottenere un codice di accesso usa e getta dal server WiKID. I due fattori di autenticazione sono il possesso del token WiKID (e della sua chiave crittografica) e la conoscenza del PIN. Poiché il PIN è convalidato sul server WiKID, è molto facile disabilitare un utente. Tutto è registrato e qualsiasi auditor dovrebbe essere molto soddisfatto.

Inoltre, potresti richiedere un codice di accesso usa e getta WiKID per l’accesso root su macchine interne. Basta creare un nuovo dominio per su e modificare /etc/pam.d/su di conseguenza. Questo ti permetterà anche di suddividere i server in diversi gruppi per la gestione. Ad esempio, se hai un insieme di server per le risorse umane ai quali solo alcuni amministratori hanno accesso root, possono essere configurati per un dominio WiKID specifico - consentendo un controllo degli accessi dettagliato e un’autenticazione forte. Ottieni ulteriori informazioni sull’autenticazione a due fattori dal sito web di WiKID.