E’ da ieri sera che seguo con particolare curiosità le vicende del sito fidal.it, sito ufficiale della Federazione Italiana di Atletica Leggera.

In sintesi, ieri sera, durante un normale collegamento al sito web, mi è apparso questo:

Un chiaro esempio di Defacing, con ben chiari i riferimenti di chi ha portato a termine il colpo. In mattinata, dopo uno stringato comunicato presente nella pagina web che parlava di un non meglio precisati “problemi tecnici”, il sito è tornato online. Dopo 1 ora circa, il sito è stato di nuovo preso di mira, ma questa volta con un risvolto ironico molto simpatico:

Ed ecco, così, una specie di Howe che salta durante i Mondiali Indoor di Budapest 2004 con sopra la scritta PREVED, che in russo equivale, circa, alla parola SORPRESA.

In questo momento il sito è completamente irraggiungibile. Forse, per evitare continui attacchi, è stato messo off-line, o forse è sotto attacco DDOS.

Che l’intera struttura informatica federale non fosse un esempio di buona condotta, non era di certo un mistero. La cosa più preoccupante è, però, il fatto che siano veramente in pochi a preoccuparsene. Tralasciando le falle insite “nelle persone che usano il sistema stesso” e che qualsiasi malintenzionato potrebbe utilizzare (come, sicuramente, le decine di password appese davanti agli schermi di tutti i comitati regionali-provinciali…), quello che mi ha sempre preoccupato è l’aver voluto utilizzare un mix di sistemi aperti e sistemi chiusi, riuscendo a non utilizzare nè i vantaggi dei primi, nè dei secondi, ma soprattutto l’incapacità nel gestire gli svantaggi che entrambi i sistemi hanno nel loro DNA.

In pratica… la presenza web della fidal si compone di varie parti: un sito, un backend, un forum e altre componenti di vario tipo.

1) Il sito fidal.it è stato, a quanto sembra, sviluppato in economia. Questo ha portato ad una relativa flessibilità per adattare il tutto alle esigenze della federazione, ma espone il sistema ad una vulnerabilità maggiore, visto che alcune procedure di sicurezza potrebbero essere state saltate in pieno in fase di progettazione. Considerato il fatto che la manutenzione di questa parte sembra mancare completamente, sarebbe stato preferibile utilizzare una alternativa open-source (di CMS opensource ne è pieno e sono anche molto più potenti di quello in uso su www.fidal.it), da mantenere aggiornata nel tempo, ma che dia alcune garanzie (di sicuro maggiori rispetto al sistema attualmente in uso) per quanto riguarda la sicurezza.

2) Il backend è stato, ovviamente, completamente sviluppato in economia. Discorso diverso rispetto a prima, in quanto non è possibile utilizzare alcuna soluzione open-source, vista l’alta adattabilità che deve avere. La cosa più preoccupante è l’aver lasciato uno strumento di lavoro sui database completamente non aggiornato (la release che è stata installata sul sistema risale ad almeno 3 anni fa) ed accessibile a chiunque dall’esterno. Tralascio i link per bontà, ma chi è in grado di trovarlo non impiegherà molto tempo a farlo… la pagina è anche presente su alcuni motori di ricerca (usare un piccolissimo robots.txt, giusto per dare un minimo di sicurezza al tutto… no?)

3) Per il forum è stato utilizzato il FUDForum (!!! Ma qualche soluzione migliore e, magari, a buon mercato non c’era?? Lavoro con forum da una vita e sinceramente non ho mai avuto problemi dal Phpbb… bastava mantenerlo aggiornato… per quanto riguarda una versione ancora migliore, ma a pagamento – 160 euro circa -, c’è pur sempre il glorioso Vbulletin…). M, naturalmente, viene utilizzata da anni una versione non aggiornata (la 2.0.2, risalente al 2002), mentre l’ultima risale al settembre 2006 (la 2.7.6).

4) Il server web è un Apache 1.3.33. Tralasciando l’esistenza dell’Apache 2, per quanto riguarda la versione 1, ci sono decine di nuove release. Trovo anche qua preoccupante il fatto che un mattone così importante come il server web, sia lasciato completamente non aggiornato. Il server web che gestisce il backend è aggiornato, addirittura, alla release 1.3.26… Il server ftp è ProFTPD, ma, naturalmente, non aggiornato (la versione in uso è la 1.2.10, mentre disponibile in rete c’è la 1.3.1), mentre per la webmail è stato installato un Squirrelemail… non posso controllare la versione, ma dubito che sia quella più nuova…

5) Il Php (versione utilizzata la 4.3.10 del dicembre 2004… e neanche segnalo quelle più nuove con relativi changelog…) è compilato in malo modo (magic_quotes off, register_globals on… per chi volesse approfondire l’importanza di queste 2 variabili, c’è questo). L’error reporting è settato ad un valore alto e, quindi, restituisce al pubblico tutti gli errori php o mysql che il web server incontra in compilazione della pagina. La procedura migliore sarebbe quella di settare l’error reporting a 0, in modo da non rendere pubblici gli errori, evitando che qualche malintenzionato possa usufruirne senze troppe difficoltà.

In questo momento l’unica cosa che andrebbe fatta è quello di non cercare di ripristinare il sistema a tutti i costi sulla rete, ma piuttosto quello di mettersi offline per tutto il tempo necessario ad aggiornare tutto il sistema (e magari a far passare la voglia a chi si sta divertendo alle spalle della Fidal). Visti i continui down e up del sistema, sembra, invece, che stia passando solo l’idea di ripristinare il sistema nel più breve tempo possibile, tralasciando qualsiasi discorso sul lato sicurezza.

Quello che ho scritto sembra essere un piccolo manuale delle pratiche informatiche che NON dovrebbero essere utilizzate, soprattutto in ambienti non particolarmente protetti come Internet e quando si gestiscono sistemi con un elevato flusso di traffico (e quindi di occhi…). Chiaramente una analisi dettagliata può essere effettuata solo con tutti gli strumenti in mano, ma quello che ho riportato qua sopra è una breve analisi di quello che chiunque, con un minimo di conoscenze, può costatare pubblicamente, senza alcuna tecnica “strana”.