Questa è la seconda parte della guida Hardening Linux che spiega passo per passo come mettere in sicurezza il proprio server o computer al riparo di molti attacchi che si possono verificare quando si è connessi ad Internet per parecchio tempo.
Aggiornare i pacchetti
Come è stato già detto, nelle installazioni più comuni di sistemi Gnu/Linux viene installato molto software che può risultare nella maggior parte dei casi inutile per i propri scopi.
Ogni servizio in ascolto può soffrire di bachi di sicurezza, più servizi in ascolto ci sono, più si è esposti al rischio di un attacco, per questo motivo è necessario rimuovere i pacchetti superflui ed aggiornare il sistema per mantenersi in linea con l’ultimo rilascio stabile della propria distribuzione.
Quest’ ultima operazione è, generalmente, gestibile tramite il package manager di default, ma un buon amministratore dovrebbe prevedere degli aggiornamenti periodici per il software più a rischio.
Per individuare in modo rapido servizi che sono attualmente in ascolto su qualche porta del nostro S.O. possiamo fornirci dell’ottimo tool netstat nel modo seguente:
# netstat –tcp –udp –listening –programs
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 *:imaps *:* LISTEN 2870/dovecot
tcp 0 0 *:51234 *:* LISTEN 20669/teamspeak-ser
tcp 0 0 *:pop3s *:* LISTEN 2870/dovecot
tcp 0 0 *:31337 *:* LISTEN 2466/sshd
tcp 0 0 *:9000 *:* LISTEN 3290/vmware-authdla
tcp 0 0 *:mysql *:* LISTEN 2550/mysqld
tcp 0 0 *:8333 *:* LISTEN 3441/vmware-hostd
ecc.ecc.
In questo modo avremo il PID , la porta su cui è in ascolto e il nome del servizio.
Rimuovere tutti i servizi che non sono in linea con la funzione del server.
Sicurezza in SSH
Nella maggior parte dei server la scelta primaria ( e corretta ) per l’accesso remoto al S.O , ricade su SSH, e questo viene installato di default con una configurazione non troppo corretta per un sistema sicuro.
L’accesso root non deve MAI essere permesso per alcun utente ed i SysAdmin devono avere i propri account da dove guadagneranno i privilegi di root.[ad#midarticlequadr]
Per impedire il login come root cambiare la seguente linea nella configurazione di SSH (generalmente in /etc/ssh/sshd_config):
PermitRootLogin no
La porta standard del servizio è la 22, che è automaticamente la più esposta ad attacchi di tipo bruteforce e DOS , nonché appunto nota a chiunque.
E’ importante mettere in ascolto SSH su porte che non vadano in conflitto con altri demoni.
Per fare ciò cambiare la seguente linea nella configurazione di SSH:
Port 31337
Disabilitare l’autenticazione senza password ( NESSUN UTENTE OPERATIVO dovrebbe avere un account senza password) cambiando la seguente linea nella configurazione di SSH:
PermitEmptyPasswords no
Disabilitare infine sftp se non necessario commentando la suguente linea:
#Subsystem sftp /usr/lib/openssh/sftp-server
Ciao,
non sono d’accordo con il fatto che root vada disabilitato per l’accesso remoto…
e nemmeno con il fatto di cambiare porta (parlo come discorso generico, non di ogni singolo caso)… questo perche’:
-aggiungere utenti e’ sempre un problema di sicurezza, meglio avere 1 utente con una password (o meglio ancora leggi dopo) decente che 20 utenti e chissa’ che pass usano
-root dovrebbe essere l’unico che puo’ accedere, ma solo usando chiavi (al posto di: PermitRootLogin no si deve mettere: PermitRootLogin without-password in modo che ssh non accetti la password ma solo una chiave)
-restringere gli ip di accesso dell’utente root (o via iptables o nella configurazione di sshd usando qualcosa del tipo: AllowUsers root@20.30.40.50) (e ovviamente anche questo non vale in un discorso generale, ma va ponderato caso per caso)
-cambiare porta vuol dire rendere il servizio difficilmente raggiungibile da certe connessioni (e’ molto piu’ facile trovare aperta la porta 22 in uscita che una 31337)
questi sono i miei consigli, e ovviamente non hanno carattere generale ma andrebbero valutati caso per caso
Ciao e buon lavoro
Grazie per le osservazioni. Allora:
Security through obscurity è un concetto di sicurezza molto blando nel senso che cambiando porta a ssh si evitano alcuni tipi di attacchi (script kiddie) ma non quelli più avanzati.
Non permettere nessuno di fare login come root è una buona cosa perchè quando ti connetti al server se conosci già il nome utente se già a metà dell’opera cioè devi solo indovinare la password di root e poi hai il completo accesso, mentre se ti logghi con credenziali minori devi poi indovinare anche la password di root.
Restringere l’accesso ad un IP è potenzialmente pericoloso in quanto chi ti garantisce di avere lo stesso indirizzo IP? Metti che il tuo provider lo cambi o che stai in fastweb (il quale IP address è condiviso da non so quanti altri utenti)
Concordo che usare le chiavi sia molto meglio questo è certo, forse un po’ più complicato per chi usa Putty 🙂