Linux security check-list

Riassumiamo qui una serie di configurazioni e ottimizzazioni post-installazione che possono aumentare il livello di sicurezza del sistema.

Non ci addentriamo nei particolari, ci si limita a dare indicazioni operative, lasciando a chi legge gli approfondimenti del caso.
Alcune indicazioni sono necessarie solo per server fisicamente posizionati in luoghi non sicuri ed in qualche modo accessibili da estranei (PHYSICAL), altre sono particolarmente pignole e dedicate a chi ha particolarmente a cuore la sicurezza del sistema o è particolarmente paranoico (PARANOID), altre ancora in qualche modo possono compromettere le funzionalità di parti del sistema per cui vanno adottate e testate adeguatamente (DISFUNCTION?), alcune sono particolarmente raccomandate (RECCOMENDED).
Queste impostazioni si riferiscono ad una distribuzione RedHat 7.2 standard. Su altre distribuzioni le posizioni dei file possono essere diverse e le indicazioni date vanno adattate.
In ogni caso queste indicazioni NON bastano a rendere un server sicuro, ma vanno affiancate ad altre precauzioni (aggiornamento costante di programmi e kernel - esposizione solo dei servizi strettamente necessari - utilizzo di IPTABLES adeguate - controllo della sicurezza dei servizi pubblici - installazione di un IDS e di un file integrity checker - log check regolare - BACKUP!).

Settare una password sul BIOS - PHYSICAL - RECCOMENDED
Necessario per impedire che si possa modificare il device di boot, impedendo la possibilità di fare password recovery o accesso non protetto ai dati bootando da floppy o CDROM estranei. Considerare che la password del BIOS è resettabile switchando un jumper sulla scheda madre. Il vero paranoico impedisce anche l'apertura del case se la macchina si trova in luoghi fisicamente non sicuri.

Strong password policy - RECCOMENDED
Le password di fatto sono il baluardo principale per permettere l'accesso al sistema. Se sono semplici, triviali, recuperabili da un dizionario o brevi sono password deboli.
E' possibile forzare il numero minimo di caratteri composti da una password editando /etc/login.defs e forzando a 8 il numero minimo di caratteri della password con PASS_MIN_LEN 8.
Altra opzione interessante presente nello stesso file è PASS_MAX_DAYS 99999 dove 99999 è la durata della password. Ha senso inserire un PASS_MAX_DAYS 180 per forzare il cambio della password ogni 180 giorni. Attenzione: Queste modifiche vanno fatte PRIMA di aggiungere utenti alla macchina. PASS_MAX_DAYS 99999 e altri parametri sono comunque modificabili successivamente in /etc/shadow.

Cript a lot - RECCOMENDED
E' fondamentale per un server pubblico che si gestisce via Internet rimuovere l'accesso telnet e sostituirlo con SSH, che cripta i dati trasmessi (e quindi login e password per l'accesso). SSH comunque non è esente da difetti, la versione 1 del protocollo ha potenziali buchi e in passato ci sono state serie vulnerabilities su alcuni software SSH. Si raccomanda di usare una versione recente di OpenSSH con supporto di SSH2, chiave di almeno 1024 bit e con accesso root diabilitato.

Permission restriction - PARANOID - DISFUNCTION?
In molte distribuzioni, spesso, alcuni file hanno di default permessi in lettura per tutti gli utenti anche quando non è necessario.
Non è una brutta idea restringere questi permessi, lasciando che sia root Colui Che Può:
chmod 600 /etc/inetd.conf Se presente inetd.conf. Ovviamente è pure necessario editarlo per rimuovere tutti i servizi inutili.
chmod 600 /etc/xinetd.conf Se presente Xinetd invece di inetd. Stesse raccomandazioni.
chmod 700 /etc/xinetd.d La directory dove Xinetd ha il file di configurazione per i singoli servizi.
chmod -R 700 /etc/&rc.d/init.d/* La directory dove sono presenti gli script di avvio. Perchè un normale utente dovrebbe vederlI?

Restrizione /etc/aliases - PARANOID - DISFUNCTION?
/etc/aliases gestisce gli alias di posta, spesso di default si forwardando a root la posta di altri utenti. E' opportuno commentare alcuni alias, inseriti di default, per evitare potenziali exploit tramite il loro utilizzo (in particolare l'alias decode). Segue una lista delle righe di /etc/aliases che si possono commentare o rimuovere. Dopo la modifica del file va eseguito il comando newaliases per rendarla effettiva:
# uucp: root
# operator: root
# games: root
# ingres: root
# system: root
# toor: root
# manager: root
# dumper: root
# decode: root

Boot loader password - PHYSICAL - RECCOMENDED
Impedire l'accesso alle opzioni del bootloader è fondamentale in un server fisicamente non custodito.
Se si usa lilo aggiungere a /etc/lilo.conf la riga password= e assicurarsi che lilo.conf sia leggibile solo da root.
Se si usa grub aggiungere a /etc/grub.conf la riga password  e assicurarsi che grub.conf sia leggibile solo da root o, meglio, usare l'opzione password --md5  

Disabilitare CTRL-ALT-CANC - PHYSICAL - RECCOMENDED
Sicuramente non ci piace l'idea che chiunque possa riavviare il nostro server con un comodo CTRL+ALT+CANC, per renderlo impossibile commentare in /etc/inittab la riga: ca::ctrlaltdel:/sbin/shutdown -t3 -r now

Stampare i log! - PARANOID
La prima cosa che fa un intrusore una volta preso possesso del sistema e coprire le proprie tracce, modificando e cancellando i log che ne possano rilevare l'entrata.
Questo è evitabile se si ha molta carta da sprecare: è possibile configurare syslog per stampare (su stampante a feed continuo) i log che si vogliono. E' semplice, basta aggiungere una riga come quella che segue ed avere una stampante funzionante su /dev/lp0
authpriv.* /dev/lp0

Usare un syslog server
Leggermente meno sicuro e definitivo del metodo precedente è quello di loggare i propri log su un syslog server remoto, opportunamente blindato, che risulti, per quanto possibile, inattaccabile per l'intrusore. Sul syslog locale aggiungere/modifcare:
authpriv.* @nomesyslogserver
Sul syslog server configurare /etc/rc.d/init.d/syslog per lanciare syslogd con l'opzione di accettare messaggi dalla rete, aggiungendo -r alle opzioni di startup.
In RedHat 7.2 modificare la riga: SYSLOGD_OPTIONS="-m 0" con SYSLOGD_OPTIONS="-r -m 0"
Buona scelta è anche usare alternative più sicure (paranoiche?) a syslogd.

Limitare la history della shell
E' possibile limitare la history predefinita della bash per ridurre i rischi che un hacker, leggendola, possa vederci delle password digitate per sbaglio.
Caso tipico è l'utente che prova a diventare superuser e scrive la password al momento sbagliato, passandola come comando shell (che probabilmente non verrà trovato) invece che come input alla richiesta della password. Tale leggerezza resta immortalata nella history della sua shell.
Editare /etc/profile per ridurre la dimensione della history. Modificare HISTSIZE=1000 in HISTSIZE=25 (o il valore che si preferisce).

Non urlare la proria identità - RECCOMENDED
Nonostante esistano tool come queso in grado di rivelare il sistema operativo installato su una macchina, è sempre buona norma fornire il minor numero possibile di informazioni sul sistema ed i suoi servizi. Questo non basta per fermare un bravo hacker, ma può essere abbastanza per fuorviare lo scan di uno script kiddie.
Per quanto riguarda i singoli servizi (web, dns, ssh, smtp ecc) riferirsi alle relative documentazioni per trovare il modo di nascondere versione e nome del programma utilizzato. Per quanto riguarda il sistema si può evitare di mostrare a console o via telnet/ssh un verboso banner introduttivo con nome distribuzione e versione del kernel.
Su RedHat7.2 editare rispettivamente /etc/issue e /etc/issue.net per mascherare versioni di kernel e distribuzione.
Su RedHat più vecchi uno sciagurato script di avvio (/etc/rc.d/rc.local) riscriveva ogni volta questi file con le informazioni originarie. In questo caso è necessario commentare le righe dello script che riscrivono /etc/issue e /etc/issue.net.

Rimuovere RPM, GCC e altri comandi utili - DISFUNCTION?
Se si vuole rendere la vita difficile ad un intrusore, e anche complicarsi un po' la propria, considerare la possibilità di spostare il comando RPM in una directory non standard (meglio cambiandogli anche il nome per evitare che un find lo trovi) o metterlo direttamente in un luogo inaccessibile (floppy estraibile).
Analogamente si può pensare di rimuovere dal sistema tutti i tool necessari per compilare del codice come gcc, make e le relative libraries (utili all'hacker che vuole crearsi delle backdoor) e i comandi che si possono usare per prendere un file dalle rete (lynx, ftp, irc, ncftp, wget, scp, rcp ...) e che si possono impropriamente essere utilizzare per caricare sulla macchina programmi estranei.
Queste precauzioni, seppur efficaci in un contesto di sicurezza estrema, rendono molto meno comoda e pratica la vita dell'amministratore.

Restringere le opzioni di mount del file-system - DISFUNCTION?
Il file /etc/fstab contiene le informazioni su quali dispotivi possono essere montati sulla macchina e può definire delle opzioni che introducono limitazioni sul file-system montato.
Per esempio un /etc/fstab con queste righe:
/dev/hda2 /tmp ext2 defaults 1 2
/dev/hdc1 /home ext2 defaults 1 1
può essere modificato con opzioni che restringono, sui file system montati, la possibilità di eseguire binari (noexec), di onorare i bit setUID e setGID su file che li hanno (nosuid), di interpretare caratteri o dispositivi a blocchi speciali (nodev):
/dev/hda2 /tmp ext2 nosuid,nodev,noexec 1 2
/dev/hdc1 /home ext2 nosuid,nodev 1 1

Limitare gli utenti che possono fare SU - RECCOMENDED
Qualsiasi utente con una shell sul sistema con il comando su, può diventare root (sapendo la password). Si può stroncare alla radice questa velleità editando il file /etc/pam.d/su e scommentando la riga:
auth required /lib/security/pam_wheel.so use_uid.
Una volta fatto, solo gli utenti appartenti al gruppo wheel (è un gruppo speciale, non si possono usare altri gruppi arbitrari per questa operazione) possono fare su, per cui editare /etc/group ed aggiungere al gruppo wheel gli utenti abilitati ad eseguire su.

Privacy Policy