SSH, o Secure SHell, ha sostituito Telnet da qualche parte negli anni '90 come protocollo di accesso remoto preferito, e per una buona ragione. SSH consente agli amministratori, o agli utenti, di accedere a una shell remota tramite un tunnel sicuro, collegando il proprio client SSH a un server SSH. SSH può anche gestire i trasferimenti di file, che dovrebbero sostituire FTP, anche se ci sono un numero sorprendente di situazioni che si basano ancora sul buon vecchio FTP in chiaro.
Come mai? Uffa.
Per i motivi di cui sopra, i moderni sistemi Linux sono gestiti tramite SSH. Gli amministratori di sistema più esperti amano l'accesso diretto e la potenza che ottengono dalla connessione sicura alla shell del proprio sistema con relativa facilità. In questo articolo parlerò nello specifico del demone del server OpenSSH, sshd . Tratteremo alcuni dei problemi di sicurezza che potresti incontrare e come mitigarli o risolverli completamente.
Perché abbiamo bisogno di SSH
Come ho già detto, SSH è uno strumento potente. Attraverso una sessione SSH, puoi connettere un terminale virtuale direttamente al tuo sistema di destinazione. Nelle mani sbagliate, questa capacità può essere problematica, quindi perché lasciamo tale potere accessibile? Ebbene, il potere di SSH implica un delicato equilibrio. In pochi minuti, un amministratore può aprire una sessione sicura sul proprio server per rispondere a un incidente. La semplicità è elegante.
SSH è anche al centro di strumenti di automazione come Ansible. Ansible può applicare modifiche a un sistema tramite SSH senza la necessità di un agente. Tutte le modifiche vengono invece effettuate utilizzando SSH e Python.
SSH può anche essere utilizzato, come ho già detto, per trasferimenti di file sicuri. Ad esempio, rsync tunnel tramite SSH per una sincronizzazione sicura dei dati. SSH può anche essere utilizzato per passare da un sistema a un altro, il che è ottimo per la risoluzione dei problemi, ma anche per un utente malintenzionato.
Se i paragrafi precedenti non ti hanno convinto, lo ripeto:SSH è uno strumento potente e, come qualsiasi strumento potente, può essere abusato. Se un utente malintenzionato può ottenere una shell sicura nel tuo sistema, il gioco è finito. E gli aggressori lo sanno, quindi sono costantemente alla ricerca di sistemi con SSH aperti al mondo in modo da poter attaccare.
Blocca SSH
Il singolo attacco più comune contro SSH è la forza bruta. Sui miei sistemi, personalmente non ho mai avuto successo con un attacco di forza bruta contro SSH. Tuttavia, prima di iniziare a seguire delle semplici regole di blocco, posso dirti che ci hanno sicuramente provato.
Una rapida ricerca su Shodan, un motore di ricerca che prende di mira i dispositivi connessi a Internet, mostra 20.984.090 sistemi con SSH aperti al mondo. Devono essere impostati in questo modo? Posso quasi garantirti che ognuno di questi sistemi riceve diversi attacchi di forza bruta SSH al secondo. Mentre scrivevo questo articolo, ho avviato un droplet su Digital Ocean, ho lasciato SSH aperto al mondo e ho seguito /var/log/secure . In circa 20 minuti ho visto la prima sonda SSH. Nel giro di un'ora è iniziata la marea di attacchi di forza bruta.
Jun 23 01:35:33 centos-s-1vcpu-1gb-sgp1-01 sshd[10926]: Did not
receive identification string from 81.22.45.137 port 61000
Jun 23 01:37:47 centos-s-1vcpu-1gb-sgp1-01 sshd[10928]: Invalid
user fake from 104.248.132.25 port 36050
Jun 23 01:37:47 centos-s-1vcpu-1gb-sgp1-01 sshd[10928]:
input_userauth_request: invalid user fake [preauth]
Jun 23 01:37:47 centos-s-1vcpu-1gb-sgp1-01 sshd[10928]: Received
disconnect from 104.248.132.25 port 36050:11: Bye Bye [preauth]
In breve, una password errata su un sshd predefinito l'installazione potrebbe essere tutto ciò che si frappone tra i cattivi e il tuo sistema. Sebbene la configurazione predefinita per OpenSSH sia discretamente sicura, può sopportare di essere rafforzata. Fortunatamente per te, ho dei suggerimenti.
Limita l'accesso alla porta 22
Inizia controllando per vedere se la porta SSH predefinita (porta 22) è aperta al mondo. Puoi farlo eseguendo Nmap, che sonderà la tua rete in base alle tue specifiche:
Starting Nmap 7.70 ( https://nmap.org ) at 2019-06-22 20:56 EDT
Nmap scan report for 167.71.200.117
Host is up (0.26s latency).
Not shown: 995 closed ports
PORT STATE SERVICE
22/tcp open ssh Restringere chi può accedere alla porta 22 è la cosa più semplice che puoi fare per proteggere il tuo sistema. Mi rendo conto che questa tattica potrebbe non funzionare per ogni scenario. Forse stai utilizzando un sistema di uso pubblico, o forse il CIO viaggia molto e potrebbe accedere ai sistemi da molti luoghi diversi (parleremo tra un po' di VPN). Il mio punto è che potresti avere una valida ragione per cui SSH deve assolutamente essere aperto al pubblico in generale. Pensa molto difficile evitare quella configurazione, però. L'ho fatto, ma soprattutto per pigrizia. Di solito c'è un modo migliore.
Se stai utilizzando un provider cloud, configura un gruppo di sicurezza per accettare solo il traffico SSH dalla rete da cui stai lavorando. Questa attività dovrebbe essere semplice se accedi a questo provider da un ambiente aziendale. Probabilmente hai il tuo intervallo di indirizzi IP, il che significa che puoi aggiungerlo alla whitelist e bloccare tutto il resto. Se accedi al provider cloud da casa, tuttavia, potresti dover eseguire alcuni trucchi per inserire nella whitelist il blocco IP allocato dinamicamente del tuo ISP. L'utilizzo di un gruppo di sicurezza dovrebbe consentirti di modificare l'intervallo di indirizzi IP tramite il portale self-service del provider di servizi cloud, se necessario.
Se stai ospitando un sistema che non è protetto da un firewall, utilizza il firewall basato su host per bloccare la porta 22 da qualsiasi luogo tranne che dall'intervallo di indirizzi IP, utilizzando gli stessi metodi che ho appena descritto. Il problema, ovviamente, è che se vieni bloccato perché il tuo indirizzo IP è cambiato, sarà più difficile apportare le modifiche necessarie.
E non dimenticare che ci sono vantaggi in un ambiente aziendale. Se il tuo server si trova su una rete aziendale, ci sono buone probabilità che ci sia un firewall di rete che puoi utilizzare per bloccare l'accesso SSH, quindi usa questo fatto a tuo vantaggio. Difesa in profondità gente, è una cosa!
Richiedi una VPN per l'accesso remoto
Ok, allora parliamo di quel CIO itinerante di cui ha assolutamente bisogno accesso a ssh da una camera d'albergo. La soluzione sembra ovvia per quelli di noi che sono stati intorno al blocco, ma se stai pensando di aprire l'accesso SSH al mondo intero, forse devi sentire questo:una VPN, o rete privata virtuale, ti consente di costruire un tunnel crittografato da un endpoint, come il laptop del tuo CIO in quell'hotel a Maui, alla tua rete aziendale a Seattle. Questa connessione è protetta a modo suo e crittografata.
Tuttavia, le tue dozzine di server che non sono accessibili al mondo potrebbero diventare accessibili tramite questo unico punto. Sì, questa pratica sposta l'obiettivo dell'attacco sulla VPN, ma ciò significa che c'è un altro ostacolo da superare per i malintenzionati.
Nega l'accesso come root
Ora stiamo arrivando al vero sshd configurazione. Il demone OpenSSH ha un'opzione chiamata PermitRootLogin . Per impostazione predefinita, questa opzione è impostata su Yes , poiché quando installi alcuni sistemi, all'inizio esiste solo root. Quando si verifica questa situazione, è necessario l'account di root per accedere al sistema ed eseguire la configurazione iniziale.
Consiglio di aggiungere un utente durante il processo di installazione, o come parte della tua immagine dorata, e di disattivare gli accessi root fin dall'inizio. Non c'è motivo per accedere come root e non c'è sicuramente motivo per accedere come root su SSH. Quindi, cambia la riga di configurazione in:
PermitRootLogin no Implementa l'autenticazione basata su chiave
Inizialmente, ho utilizzato l'autenticazione basata su chiave per comodità. Ho generato una chiave privata, ho aggiunto la chiave pubblica alle mie authorized_keys file sui server che gestivo e potevo quindi connettermi in modo sicuro ai miei sistemi senza password. In questo modo si è risparmiato tempo e si è resa possibile l'automazione. VINCITA! Solo più tardi ho scoperto che l'autenticazione basata su chiave SSH può essere sfruttata per eliminare i tentativi di forza bruta delle password.
Per generare una chiave, esegui ssh-keygen su un computer Mac o Linux. Forse voi Windows potete farlo in modo nativo ora, ma su macchine Windows ho sempre usato PuTTYGen (e poi ho usato la chiave con il client PuTTY). Ti verrà chiesto un tipo di chiave e una lunghezza. Ultimamente sto realizzando chiavi RSA a 4096 bit. Più bit, più difficile sarà la chiave da decifrare. Allora perché no?
[gangrif@meliodas ~]$ ssh-keygen -b 4096
Generating public/private rsa key pair.
Enter file in which to save the key (/home/gangrif/.ssh/id_rsa): ./test-key
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in ./test-key.
Your public key has been saved in ./test-key.pub.
The key fingerprint is:
SHA256:xfHOf4t3V3CCkJ+3FbEnQusAjBwOjBXfOa9WdGXBMqc [email protected]
The key's randomart image is:
+---[RSA 4096]----+
| ++o.+. ....+o.|
| . .+o..+o+o+o..|
| o + =o=B..o|
| = *E.+.+|
| S o +. * |
| o .. .|
| o . o|
| . .o+|
| ...o|
+----[SHA256]-----+
Quello che poi ottieni è un nuovo file chiamato test-key (in questo caso) e test-key.pub . La chiave in test-key è la mia chiave privata e test-key.pub contiene la chiave pubblica. Proteggi la chiave privata con la tua vita. Tuttavia, puoi lasciare la chiave pubblica ovunque tu voglia, poiché è inutile senza la chiave privata.
[gangrif@meliodas ~]$ cat test-key.pub
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQDAQxmjoHO6i4Kkq8vp49KtqAsMcw+ptgvd+PGjxVYkDPGdzRZpJhq0c3BDstFs86ENlojs61zZaP3MihLR0BlDdIyM3jh9TmVvmOPiylhu4X9QliAca/ODxyVp76OpTKm+QcgBi/7i/JNiJdEgcSy8izB0Oil7LZjIhS6wCs3mQFVbkPXPfe1lmHQIcuMDOKO0RuyecY/lrKodcr/YbEE4GsM/P11QdDPZ78lq83G3H5vqLqMrxVKkLw7Z4//+PZPFFxi/N1EBwBp/uPEo4MfD1IwSmnKromRlkYTdOYlbiCNosdvEobtMARySdqjv7RDn0Iwb3JxioUW6jQdAXfl8d01LvX/0Yb1tq5hF44ahwvI6TyoB4z3DRs+3cFiMPWQR7LK8/qQOvHk5I2NMBAV9KuSN2ML0d7xeB8tglw38PYjhZsXl/t2rAWT4n8PU0o6+Hrrli+WEfvk8QWpLesmBBmzG0sLjH0mXBU/xN4UBLLJNlrsUQ/TzEsdknntMhh7leOzechlU3PiTNuUitweT9NqLJwCP+CHbeSJn2M5qzb090CPnCGpnr2GOfm2dL+RfHQi2R1Cf04nBDq3WuhAPJY5SoEw2llfSgA2GlOdhcY9N9Bl9rLUBPgQ6ttBd7qZJ6E3BkiPlHnU+kSSpYr8Gkw1oDGbtd2UUjExZqvz4rQ== [email protected]
Sulle macchine a cui vuoi connetterti senza usare una password, copia la chiave pubblica in .ssh/authorized_keys (o chiedi all'utente di farlo, a seconda della situazione). Ora, dico senza password, ma devi comunque sbloccare la chiave privata con la password che hai impostato durante la generazione. Hai impostato una password, vero?
Puoi anche copiare da remoto questa chiave su un server usando ssh-copy-id .
Disabilita l'autenticazione basata su password
Ricordi quando ho detto che l'autenticazione basata su chiave ti apre alla possibilità di bloccare completamente i tentativi di forza bruta SSH? Bene, ecco come. Con le tue chiavi private e pubbliche a posto, SSH non ti chiede più una password, giusto? Allora perché lasciare quella strada aperta come vettore di attacco?
Su ogni server Linux che eseguo, aggiungo la mia chiave pubblica come parte della nostra installazione di base e disattivo l'autenticazione della password SSH prima ancora che il sistema raggiunga la rete. Questa è un'impostazione direttamente in sshd il file di configurazione di. Anche in questo caso, l'impostazione predefinita consente l'autenticazione della password, poiché tale funzione deve funzionare per la configurazione. Una volta che hai le chiavi a posto, però, spegnilo.
PasswordAuthentication no Congratulazioni, ora sei immune agli attacchi di forza bruta delle password.
Carcere utente SSH, con chroot
Il chroot —solitamente pronunciato “chi-root” o “ch-root”—il comando è uno strumento accurato. Ti permette di cambiare la directory principale vista da un processo e dai suoi figli, da cui il nome. È ottimo per la risoluzione dei problemi di un sistema in cui puoi accedere al disco, ma non si avvia. Basta montare il suo disco e chroot su /mnt/qualunque cosa.
Questo è anche un ottimo strumento di sicurezza per qualcosa come un server shell. Puoi eseguire il chroot di un utente al login, quindi non può letteralmente vedere il resto del filesystem. Non lo faccio spesso, ma è una prigione molto praticabile per gli utenti. Ho trovato quello che sembra essere un articolo decente qui.
Rotazione
Vale la pena considerare la rotazione della password e della chiave ssh. Cercherò di delineare il buono e il cattivo qui.
Politica e rotazione delle password
Raggrupperò la politica delle password con la rotazione delle password perché sono correlate. I criteri delle password che impongono la complessità sono un ottimo modo per far scegliere agli utenti una password "forte". Tuttavia, questo ha alcuni avvertimenti, specialmente se abbinato a una scadenza arbitraria (cioè a tempo) della password. Potrei scrivere un intero articolo su come mi sento riguardo alla politica delle password e alla rotazione, ma cercherò di essere breve qui.
L'anno scorso, il NIST ha fatto una sorta di dietrofront sulle linee guida sulle password, modificando alcuni dei loro suggerimenti che erano stati radicati nella maggior parte delle nostre menti per la maggior parte delle nostre carriere. La comunità di Infosec (in cui mi diletto) ha suggerito per anni che una password casuale di 8 caratteri o una lunghezza minima di 8 caratteri con regole di complessità rigorose, stavano facendo di più per DANNEGGIARE l'igiene delle password che aiutarla. Combina rigorose regole di complessità con una politica di rotazione delle password di 3-6 mesi e stai preparando i tuoi utenti alla frustrazione. Questa frustrazione porta al riutilizzo delle password e ad altre cattive abitudini. Quindi pensa attentamente se vuoi imporre questo ai tuoi utenti. I nuovi consigli tendono a scadere solo quando si sospetta una violazione o una compromissione e una politica che porta i tuoi utenti a passare frasi di sicurezza piuttosto che a password. "Questo è il mio p@ssw0rd 2019." è molto più difficile da indovinare e decifrare rispetto a "W1nt3r2019". Che, a proposito, è un punto di riferimento comune sia per i programmatori di password che per i teamer rossi. Tieni presente, tuttavia, che se stai chiedendo agli amministratori intelligenti di ruotare le loro password, potresti non avere questo problema (perché capiscono PERCHÉ lo stanno facendo e quanto sia importante). Ma per i tuoi utenti in generale, la scadenza arbitraria e le complesse "password" stanno diventando un ricordo del passato.
Rotazione della chiave privata SSH
Come qualsiasi identificatore che può essere generato, potrebbe essere utile considerare la rotazione periodica della chiave privata. La tua chiave privata non è così facile da rubare o indovinare come potrebbe essere una password, ma è possibile che qualcuno abbia sollevato la tua chiave a tua insaputa. Questo entra nel territorio "quanto paranoico vorresti essere". Tuttavia, la modifica della password sulla chiave privata non è abbastanza. Quella password sblocca quella chiave, se faccio scorrere la tua chiave oggi e tu cambi la tua password domani, la copia se la tua chiave che ho ha ancora la tua vecchia password. Se hai intenzione di farlo bene, devi generare una chiave completamente nuova. Ora è un buon momento per aumentare la lunghezza della chiave se lo standard è aumentato dall'ultima volta che hai generato una chiave. Forse generi una nuova chiave ogni volta che il tuo datore di lavoro ti consegna un nuovo laptop, forse lo fai una volta all'anno nel tuo anniversario di lavoro. Tuttavia, non ho trovato una soluzione che gestisca questo per te.
Tieni presente che la generazione di una nuova chiave significa che tutte le chiavi pubbliche che hai nel mondo ora non sono valide. O almeno non sono validi con la tua nuova chiave. Probabilmente dovrai usare la tua vecchia chiave per posizionare la tua nuova chiave pubblica.
AMF
L'autenticazione a più fattori sta diventando la norma. Alcune persone hanno cercato di affermare che le chiavi SSH sono una forma di MFA, in qualche modo non lo sono. Soprattutto se hai disabilitato l'autenticazione della password. Puoi tuttavia integrare mfa come TOTP o YubiKey nella configurazione PAM del tuo sistema. Le soluzioni di autenticazione centralizzata come FreeIPA rendono tutto più semplice.
Conclusione
Quindi il gioco è fatto, spero che tu prenda queste informazioni e le applichi ai tuoi sistemi per migliorare la tua sicurezza. Non essere uno di quei 21 milioni di sistemi con SSH aperti al mondo. Semplicemente non c'è motivo per questo.
Grazie per aver letto!
Questo articolo è stato originariamente pubblicato su Undrground.org. Ripubblicato con autorizzazione.