Come sistemista negli anni ho svolto numerose attività di consulenza per varie aziende, italiane ed estere di tutte le dimensioni e, molte volte, ho scoperto configurazioni dei sistemi IT davvero grossolane. Quando scoppia qualche disastro nei sistemi aziendali la colpa viene sempre addossata a qualche fantomatico hacker, ma in realtà nella maggior parte delle volte le cause dipendono dal sistemista che gestisce l’infrastruttura.
Siamo tutti bravi a sparlare degli altri, siamo meno bravi a spiegare come si fanno le cose per bene.
Con questo articolo voglio riportare alcuni esempi reali di errata configurazione o cattiva gestione delle infrastrutture IT che hanno causato seri problemi ai clienti che ho assistito.
Spero che queste esperienze possano essere d’aiuto anche a te!
CASO 1
Sono stato chiamato da un cliente che riscontrava un rallentamento nelle procedure eseguite all’interno di uno dei suoi server.
Risultavano anche dei file anomali nella cartella temporanea.
Prima di prendere in esame il caso, faccio le consuete domande di routine:
- dove è localizzato il server?
- espone dei servizi verso Internet?
- se si, è adeguatamente protetto da accesso esterno con modalità di accesso sicuro (esempio impiego di VPN)?
- il server è monitorato?
- da quanto tempo ha riscontrato il problema?
- che politiche di sicurezza, in ingresso ed uscita, sono applicate al server?
Le risposte facevano presagire brutte sorprese:
Analizziamo le singole risposte:
Dove è localizzato il server?
In un datacenter con gestione interna di tutta l’infrastruttura da parte dei propri reparti IT.
Questa è una buona notizia, vuol dire che è più semplice applicare corrette politiche di gestione in accordo con le best practice della ISO 27001 ed altre in ambito di gestione di infrastrutture IT.
Espone dei servizi verso Internet?
Si.
Questo è un aspetto da tener da conto, perché potrebbero esserci problemi di intrusioni o attacchi da Internet.
Se si, è adeguatamente protetto da accesso esterno con modalità di accesso sicuro?
Si. usiamo l’accesso in SSH, e l’accesso avviene con le credenziali di root.
Questo aspetto è fortemente critico. L’accesso dall’esterno in SSH dovrebbe essere vietato, specialmente con l’impiego di username e password, inoltre mai con le credenziali di root. Sarebbe preferibile consentire l’accesso tramite VPN e sempre con credenziali non di amministratore. Questo aspetto eviterebbe la possibilità di accessi incontrollati, causati anche dalla sola perdita accidentale delle credenziali.
Il server è monitorato?
Si, ogni tanto mi collego per fare aggiornamenti applicativi ed estrarre dati.
Situazione grave. Non viene fatto monitoraggio. L’attività di monitoraggio è un’attività autonoma dall’intervento umano e deve essere continua nel tempo. Inoltre insieme all’attività di monitoraggio devono essere definite azioni specifiche al manifestarsi di anomalie.
Da quando ha riscontrato questo problema?
Non lo sappiamo, abbiamo ricevuto alcune segnalazioni da alcuni clienti da alcune settimane, ma dai file di log non è emerso nulla.
Molto male. Il caso non è stato gestito bene, inoltre le varie segnalazioni ricevute non hanno fatto innalzare il livello di guardia?
Che politiche di sicurezza, in ingresso ed uscita, sono applicate al server?
Sul server è presente un firewall che impedisce l’accesso dall’esterno escluse le porte http (80), https (443), ed ssh (22).
Male. E’ vero che si impesce l’acceso su altre porte TCP impiegate all’interno del server da vari servizi come database, application server, ecc; però non c’è nessun controllo sul traffico in uscita.
Hai individuato anche tu alcune criticità?
Dopo una breve esposizione delle mie varie osservazioni al cliente, sono passato ai fatti.
Accedo al server e scopro:
- La CPU del server viaggia al massimo. C’è un processo che non appartiene alla costellazione degli applicativi installati correttamente sul server dal cliente che consuma risorsa CPU
- sono presenti dei file nella cartella temporanea del server con date anche recenti.
Dopo una breve analisi individuo il problema:
E’ stato installato un programma di mining per monete virtuali, tipo bitcoin o altro.
Procedo alla bonifica ed invito il cliente a mitigare le falle di sicurezza intervenendo:
– con fix bug applicativo, porta di accesso all’installazione del programma di mining sul server;
– con l’introduzione di politiche di sicurezza atte ad impedire al server di poter instaurare connessioni in autonomia verso l’esterno (Internet) in questo modo, se in futuro dovesse presentarsi un’altra falla sull’applicativo si potrebbero mitigare gli effetti;
– con la predisposizione di un adeguato sistema di monitoraggio.
CASO 2
Vengo contattato da un cliente perché non riesce a spiegarsi sul perché si manifestano comportamenti anomali sul suo applicativo che espone dei servizi SOAP per postazioni client distribuiti su territorio nazionale.
Prima di prendere in esame il caso, faccio le consuete domande di routine (vedi il Caso 1):
Scopro subito un problema, ma non è la causa dell’anomalia.
I servizi SOAP viaggiano in HTTP e non HTTPS. Ricordo che un MUST è portare tutti i servizi su HTTPS.
L’attività di analisi ha richiesto diverso tempo, sia lato server sia lato client.
Per meglio comprendere il problema riporto l’iter corretto del processo di esecuzione:
A) Il client invia una richiesta SOAP per una elaborazione, e si mette in attesa di ricevere il risultato dell’elaborazione.
B) Il server riceve la richiesta SOAP, e la valida.
C) Una volta validata la richiesta, procede all’elaborazione che genera una serie di modifiche all’interno del database applicativo.
D) Il server risponde al client con un messaggio SOAP, fornendo la risposta richiesta con esito positivo.
E) Il cliente riceve la risposta e riporta le informazioni a video all’operatore.
Questo iter illustrato in forma semplificata gli elementi salienti della comunicazione con l’accesso ai servizi remoti.
Questo iter, funzionava perfettamente quasi sempre, tranne in rarissimi casi, apparentemente inspiegabili e che si manifestavano in modalità random.
La non determinabilità dell’errore e l’inesistenza di errori lato server, hanno complicano l’attività di analisi.
Approfondendo l’analisi, ho indagato più attentamente sui log dei client.
Su alcuni di questi risultava presente ogni tanto un messaggio di timeout nella connessione TCP/IP. A livello operativo è ammissibile. Stiamo parlando di connessioni TCP/IP da sedi remote con connessioni non sempre stabili. Continuando l’analisi, riesco ad individuare un esempio di comunicazione con un particolare insieme di dati forniti dal client al server.
Puntualmente con quella particolare combinazione di dati tutto va bene fino al punto D dell’iter.
Il punto E, invece, non si conclude correttamente; si manifesta sempre un errore di “Connection Time-out” nella richiesta SOAP da parte del client.
Quindi apparentemente sembra che il client non sia riuscito a contattare il server; in realtà dall’analisi sui log del server risulta che la richiesta SOAP sia giunta correttamente, sia stata processata e sia stata inviata la risposta.
A questo punto è stato necessario approfondire l’analisi perché per motivi inspiegabile il pacchetto TCP di ritorno risulta stato trasmesso e consegnato al legittimo destinatario, ma in realtà il client non l’aveva ricevuta.
La conferma di tutto questo arriva con una attività di sniffing del traffico di rete, che conferma il misterioso evento.
Scatta subito il sospetto che ci possa essere un terzo attore intermedio che deliberatamente faccia scomparire questo messaggio TCP/IP. Vengono interpellati i gestori della rete del datacenter ove è localizzato il server, per chiedere chiarimenti sul problema evidenziato.
Dopo innumerevoli sollecitazioni, riesco a scoprire che hanno da poco attivato un formidabile firewall hardware con antivirus integrato.
Disabilitando l’antivirus la comunicazione si concludeva correttamente.
Morale!
È sempre necessario porre molta attenzione a cosa e come si introducono i componenti di rete in un sistema IT, ma ancora di più bisogna sapere anche configurare correttamente un dispositivo di protezione.
Non è ammissibile far droppare semplicemente i pacchetti, senza far scattare le opportune segnalazioni per intervenire celermente prima che si provochino problemi seri sui servizi. Personalmente io avrei evitato di eseguire delle operazione di DROP su connessioni già stabilite, e se proprio si vogliono bloccare queste connessioni, bisogna gestire informando opportunamente il server ed il client con opportuni pacchetti TCP e/o HTTP.
CASO 3
Diversi clienti in questi anni mi hanno chiamato chiedendomi assistenza per un caso tipico di disservizio a livello applicativo.
La MTU (Maximum Transmission Unit).
Se vi capita di gestire un applicativo che espone un servizio via HTTP o HTTPS funzionando a singhiozzo, cioè a volte sembra che risponda correttamente ed altre volte no, ci potrebbe di mezzo la MTU, ed il 90% delle volte è così.
In alcune infrastrutture IT delle volte capita che la frammentazione IP non venga gestita correttamente e quindi nel caso il traffico transiti per tronconi di rete con MTU inferiori a quella di partenza, potrebbe capitare che la comunicazione venga abortita lungo il percorso tra il server ed il client. In questo caso se non si può risolvere il problema lato infrastruttura, l’unica strada percorribile è quella di variare, a mano, la configurazione della MTU dell’interfaccia di rete del server dove è localizzato l’applicativo.
Queste sono solo alcuni esempi di problematiche che ho gestito negli anni di lavoro e ho constatato che nonostante la tecnologia migliori e gli strumenti di analisi e supporto migliorino ed aumentino, gli errori nella gestione e configurazione dei sistemi IT si ripetono costantemente.
Avere dei buoni sistemisti al proprio fianco aiuta a prevenire i problemi e i conseguenti disastri.
