Da quando ho aperto l’azienda, ho aperto la mia prima infrastruttura, che nel corso del tempo si è ampliata sempre di più, arrivando a quello che è oggi.
Ovviamente come tutti nel mondo digitale, quando inizi ad ampliarti oltre una certa soglia, inizi ad attirare l’attenzione di svariate tipologie di persone, tra qui quel genere di persona che non vorresti mai avere a che fare per nulla al mondo per via del fatto che sono li per causare dei problemi alla gente.
Infatti, non so se voi lo sapevate, molta gente per lavoro attacca svariati sistemi informatici con un duplice scopo in mente: il primo è quello di recuperare i dati memorizzati nel sistema informatico in questione e andarli quindi a rivendere, per guadagnarci quindi dei soldi a danno del proprietario dell’infrastruttura informatica e di tutti i clienti che si appoggiavano a tale infrastruttura e per fare curriculum. In pratica ogni volta che un attacco informatico da parte di una di queste persone ha esito positivo, quindi in pratica l’attacco riesce, l’autore dell’attacco posta lo stesso su internet per fare in modo che aziende o altre persone che lavorano nel suo settore (possiamo quindi definire queste altre persone come dei colleghi) possano vedere l’attacco eseguito. In pratica per mostrare in modo pratico cosa si sa fare.
Questo ovviamente è molto utile per poter avanzare nella propria carriera. Certo, come starete pensando ora e anche giustamente, una carriera criminale è e nulla di più. Ed è vero, ma è una vera e propria carriera comunque criminale o non.
Comunque senza tergiversare più di tanto, il giorno 23 novembre di quest’anno, controllando i log di accesso al server SSH (per chi non lo sapesse, il file che registra gli accessi effettuati al server SSH, quindi al server sshd o comunque che registra ogni tentativo di accesso, riuscito e quindi con credenziali corrette o meno, è il file auth.log nella directory /var/log/) ho notato che c’erano circa 25 mila tentativi di accesso, quindi un vero e proprio attacco brute force alla porta 22 del mio server, la porta che gestisce il modulo sshd, dallo stesso indirizzo IP. Andando a controllare su google l’indirizzo IP in questione, ho scoperto in seguito provenire dalla Cina e che lo stesso è stato e viene tuttora segnalato con una frequenza regolare da tantissimi sysadmin (persone che gestiscono una o più infrastrutture server) da tutto il mondo. Tutte le segnalazioni per altro portano ad un solo e unico punto: tentativo di brute forcing alla porta 22 del server sshd, con relativa traccia nel file auth.log.
Dai log mi sono reso conto che questa persona, o per meglio dire questo programma che utilizza una persona probabilmente in Cina, cercava di accedere, ad ogni tentativo all’account root della macchina. Per ovvie ragioni per altro; ovviamente se fosse riuscito ad accedere all’account root, avrebbe potuto controllare l’intera macchina e quindi creare non pochi problemi.
Mi sono anche reso conto, sempre guardando dai log (i log non so se lo avete capito, ma sono uno strumento fondamentale per poter monitorare tutte le operazioni che il server effettua ogni giorno e vedere se ci sono problemi, errori o questioni di sicurezza da controllare ed eventualmente andare a sistemare per mettere il tutto in sicurezza in modo tempestivo, evitando problematiche irreversibili, che peraltro nessuno vorrebbe), che la persona ad ogni tentativo cambiava porta. In pratica continuava a comunicare con la porta 22 del mio server, ma lui utilizzava di volta in volta una porta differente. E questo per un motivo. Io come sistema di protezione per l’accesso SSH utilizzo PAM. Questo strumento non è altro che un deamon che verifica ogni tentativo di accesso e li conta. Se ci sono 5 tentativi di accesso, provenienti dallo stesso indirizzo IP e dalla stessa porta in un intervallo di tempo ravvicinato, blocca l’indirizzo IP per una trentina di secondi, in modo tale da mandare in confusione il programma che sta effettuando l’attacco Brute Force e quindi costringendo il proprietario a reinizializzare l’attacco.
Ovviamente se invece il programma cambia porta ad ogni tentativo, PAM non riesce ad intervenire in modo efficace, permettendo quindi all’hacker di attaccare con lo stesso indirizzo IP praticamente all’infinito, nella speranza che il proprietario del server abbia inserito una password di root non troppo complicata e che quindi possa essere facilmente, o quasi per lo meno, recuperata.
Recuperate quindi tutte queste informazioni importanti per comprendere quale fosse il problema e la strategia per risolverlo al meglio, ho iniziato ad applicare una serie di strategie che hanno dato fin da subito, una volta terminato di impostare i nuovi parametri e sistemi di sicurezza, ovviamente, esito positivo. In pratica sono riuscito a risolvere il problema.
Cambiata la password di root
Per prima cosa ho provveduto a cambiare la password di root. Non perché quella precedente fosse debole, anzi, ma per sicurezza l’ho voluta modificare comunque, mettendone una di 67 caratteri alfanumerici e con simboli speciali vari. Per generale la nuova password ho usato l’estensione per Google Chrome denominata Last Pass.
Per modificare la password di root ho usato il comando chmod -> chmod root
Ho inserito la nuova password, l’ho ripetuta in modo da confermarla e il primo passaggio era fatto.
Disabilitato l’accesso root da ssh
La seconda modifica che ho adottato e applicato nel mio server è stata quella di disabilitare l’accesso all’account root da SSH. Per fare questo sono andato ad intervenire, mediante un editor di testo da riga di comando (io solitamente uso nano, ma potrete usare qualsiasi editor vogliate, non cambia nulla il risultato rimane il medesimo) il file sshd_config all’interno della directory /etc/sshd/ -> nano /etc/sshd/sshd_config
Qui ho cambiato da yes a no il parametro: PermessRootLogin
Installato fail2ban
Ho provveduto ad installare da Plesk (ho plesk quindi ho usato questo) il modulo fail2ban e metterlo in ascolto alla porta 22. Ho impostato un controllo tale che se un utente, con lo stesso indirizzo IP, prova ad accedere ad un qualsiasi utente mediante accesso SSH sbagliando per 3 volte nome utente e/o password, quest’ultimo viene bloccato (da IP) per 600 secondi
Configurata una nuova regola del firewall
Nel mio server principale ho una configurazione firewall particolare, che non sto a spiegare ora. Fatto sta che il firewall interno è impostato in modo tale da non intervenire su nessuna porta. In pratica c’è, ma è come se non ci fosse. Non mi serve se non in casi eccezionali, per via della struttura della rete che protegge il server. Ad ogni modo, ho aggiunto una nuova regola del server che prevede di bloccare tutte le porte ad uno o più specifici indirizzi IP. In questa regola vado ed andrò ad inserire tutti gli indirizzi IP che mi sembrano più problematici. Quelli che insistono con più regolarità nel cercare di entrare dentro il mio server mediante SSH.
Installato mod_security
Sempre con plesk ho installato e configurato mod_security per controllare e prevenire (l’ho impostato così io, disabilitando tutta una serie di funzioni per me inutili e talvolta anche problematiche per alcuni progetti che gestisco) attacchi DDoS, Brute force e altro.
Queste sono le misure che ho preso. Come ti sembrano? Per me hanno funzionato benissimo, visto che il problema con SSH è completamente rientrato. Ora non ho più e penso che non avrò mai più questo problema. Voi invece come avreste agito? Me lo raccontate nei commenti, se vi va ovviamente?
Prima di lasciarti voglio ricordarti che nella home page potrai trovare tutte le informazioni per contattarmi per una consulenza gratuita.
Da questo momento, ho aperto il nuovo sito Tech Developer.
NOVITA’: rilasciata la nuova home page di SharekFile.
Inoltre da poco tempo ho aperto un nuovo servizio di assistenza tecnica e ho pubblicato il mio listino prezzi, che potrai consultare nei rispettivi link.
Ti presento anche il mio nuovo servizio per aiutarti a mettere in regola il tuo progetto digitale alla GDPR.
Da oggi è disponibile un nuovo abbonamento premium, per usufruire di tutta una serie di post aggiuntivi e di tutti i benefici di SharekFile.
