Sysadmin panics: sicurezza

Ed ecco come si comportati alcuni dei sysadmin disastrosi che ho conosciuto riguardo alla sicurezza.

Root? Sempre e comunque!

Ho assistito piu' volte a sysadmin che pur di voler mostrare la loro capacità nell'eseguire operazioni remote sui loro server via SSH (come che fosse una gran difficoltà!) non hanno esistato a collegarsi direttamente come root ai server remoti da computer assolutamente non fidati di aule corsi o addirittura da computer di altre persone. E se maliziosamente qualcuno avesse impostato un keylogger?

Ma tanto gli utenti non sanno usare SSH

Diversi anni fa mi trovai a svolgere dei compiti di manutenzione su un server di posta elettronica gestito da una software house esterna. Notai con ribrezzo che tutti gli account utente usati per la posta elettronica avevano abilitato il login. Non solo, la loro shell di login era bash, che per definizione è insicura specialmente in connessioni remote (si pensi a .bash_profile o perggio a .bashrc). Ovviamente ho fatto presente l'errore di configurazione, dovuto al fatto che comandi come useradd e simili, pensando che l'utente sia interattivo, propongo in default una shell di login. Tuttavia mi è stato risposto che, poiché gli utenti che usavano le caselle di posta non erano abbastanza smaliziati da usare anche SSH, non c'era nessun rischio di sicurezza. Devo commentare?

Ad ogni modo, il server in questione venne penetrato, con notevole disservizio. Parecchi anni dopo, la software house in questione continuava ad installare server di posta con utenti abilitati al login da ogni host remoto....

Aggiornamenti? Quando cambiamo il server!

 Gli aggiornamenti software si sa, possono essere problematici e difficilmente sono indolore. Tuttavia, almeno sul fronte della sicurezza, vanno fatti regolarmente seguendo gli advisor dei vari servizi e OS. Non tutti sono propensi agli aggiornamenti, seguendo il principio che quello che funziona non va toccato o si rischia di romperlo. Il principio è vero: se si ha un vaso di cristallo in equilibrio sopra ad un cornicione conviene non toccarlo, o si rischia di farlo cadere. Ma è anche vero che si potrebbe riuscire a metterlo in salvo da un eventuale terremoto. Insomma, io sono propenso a fare gli aggiornamenti il prima possibile e con tutto il lavoro necessario affinché i servizi siano sempre in ordine.

Inutile dire che molti sysadmin non la pensano così, e infatti piu' volte ho dovuto discutere per poter fare aggiornamenti di servizi vecchi di anni. E molto spesso la risposta che ho avuto è stata che le versioni nuove andavano installate con i nuovi server hardware, ovvero visto che all'acquisto di una macchina si deve "spendere" tempo per installare un sistema, quel tempo lo si sarebbe impiegato per installare un sistema aggiornato, risparmiando quindi il tempo "inutile" di aggiornamenti successivi. Inutile commentare oltre.

Password dei servizi

Ho visto così tante password di servizi e demoni impostate tutte uguali a valori noti che mi sono stancato dell'argomento e non intendo nemmeno commentarlo!

Impostare la propria password pensando alla propria banca

Si, un sysadmin impostò una password di amministratore scaduta secondo lo schema delle password della propria banca sostenendo che non era sicuro di poter usare alcuni caratteri perché nel login della sua banca non erano permessi. Se sembra senza senso, è vero. E ancora devo capire cosa mi volesse dire il sysadmin in questione!

Condivisioni, backup e tutto di tutti!

Uno dei miei primi lavori seri fu impostare dei livelli di sicurezza su delle condivisioni di file che risultavano di fatto accessibili a tutti gli utenti indiscriminatamente. E infatti spesso un utente cancellava i file di un altro utente senza motivo. 

Perfino le copie di backup erano "parcheggiate" su condivisioni accessibili a tutti gli utenti. A cosa serve quindi profilare gli utenti se poi chiunque può portarsi a casa l'intero set di dati dell'azienda?

Backup del capo? Totalmente insicuro!

Situazione: il capo chiede al suo sysadmin fidato di fargli una copia di backup dei dati del suo computer (posta e documenti). Il sysadmin ha fretta, quindi decide di posizionare il backup in uno storage di rete. Peccato che scelga una posizione accessibile a tutti gli utenti (si veda il paragrafo precedente). Poco male, visto che il backup viene fatto fuori dall'orario di lavoro, quando i dipendenti di fatto non hanno accesso fisico allo storage. Ben piu' grave è lasciare il backup in suddetta posizione per oltre un mese.