E’ da qualche giorno che me ne sono accorto, e la cosa poi è stata confermata da più parti. In sostanza c’è una ondata di scansioni su siti WordPress che mira a cercare le chiavi SSH private le quali darebbero l’accesso al server. Come potete vedere nell’immagine qui sotto gli attacchi cercano il file id_rsa o id_dsa, ovvero il nome di default generato dalla chiave SSH. Non essendoci l’estensione .pub, questa è la chiave privata. Ovviamente da sola non basta, perché poi è necessaria la username, che arrivati a questo punto è molto probabile sia root.
Alcuni consigli.
Non pubblicare mai le chiavi private da nessuna parte nel server. Infatti non serve, ma è necessaria solo la chiave pubblica all’interno del file authorized_keys all’interno della cartella .ssh del profilo utente preposto a potersi collegare. Questo file poi deve avere i permessi di lettura/scrittura solo da parte del proprietario, mentre per gruppi e altro non deve avere nessun permesso, specie di lettura!
In ogni caso mai, per nessun motivo, pubblicare la home directory (la cartella profilo utente) all’interno di una cartella gestita da un webserver (apache/nginx).
Cercare ove possibile di non utilizzare root come utente di accesso, ma rendere più complicata la questione con utenti più difficili da trovare. Come detto la chiave va in coppia con la username, ma un nome utente non standard aumenta l’efficacia della chiave stessa.
Il webserver non deve MAI permettere il browsing (la navigazione) dei file, in particolare modo al di fuori della root folder a lei designata. Questi scan infatti mirano anche a cercare questi file grazie a configurazioni di Apache errate. Se non sapete come fare rivolgetevi ad un sistemista.
Quando generate le chiavi, mettete sempre una password alla chiave privata. Nella procedura guidata ve lo chiede, non saltate questa parte, visto che potenzialmente si può fare e molti sono portati a saltare perché è una scocciatura. La chiave privata di per se è molto sicura, ma per l’appunto se ve la fregano senza la password per attivarla diventa inutilizzabile. Inoltre è possibile per i computer che sapete utilizzare soltanto voi, fare in modo che la password venga memorizzata in modo sicuro e quindi evitare la famosa scocciatura. Chiaramente queste procedure hanno valore solo su una precisa macchina, se la chiave viene utilizzata in un nuovo computer tornerà a chiedere la password.
Se effettuate backup delle chiavi, fatelo in modo che siano protette da una ulteriore password (diversa dalla privata) e magari in modo cifrato. Ci sono molti programmi di compressione che permettono di proteggere da password. A questo punto chi potesse rubare il file si troverebbe con due strati di password differenti da fornire. Salvate comunque i file i luoghi adatti (una chiavetta usb che tenete in luogo sicuro) e mai in giro per servizi cloud.
Se utilizzate sistemi di versionamento o sincronizzazione, fate attenzione affinché le chiavi SSH non siano contemplate.
Inoltre, ma questo ammetto che è troppo, cambiare periodicamente le chiavi. Sarebbe utile farlo, ma troppo dispendioso nel caso dobbiate gestire più server, poiché dovreste prima di scaricare la vecchia chiave, dichiarare quella nuova. Tutto questo con il rischio di commettere qualche errore e magari ritrovarsi tagliati fuori.
Come faccio a sapere se ho pubblicato una chiave ssh?
Ci colleghiamo in SSH al server e daremo il seguente comando:
sudo find / | grep -i id_rsaSe non ritorna nessun risultato siamo a posto. Viceversa vi verrà indicata la path di dove si trova il file incriminato.
Concludendo, si tratta di una scansione e non un attacco, il fatto che sia su WordPress è dovuta soltanto alla probabilità che i progetti siano stati copiati con sistemi automatici. Non ha nulla a che fare con WordPress come sistema. Se avete pubblicato le chiavi private sulla root del webserver, o al suo interno, scusate, ma un po’ polli lo siete.