110.2 Lezione 1

Certificazione:

LPIC-1

Versione:

5.0

Argomento:

110 Sicurezza

Obiettivo:

110.2 Configurare la sicurezza dell’host

Lezione:

1 di 1

Introduzione

Questo capitolo spiega quattro modi fondamentali per migliorare la sicurezza degli host:

Alcuni comandi di base e impostazioni di configurazione per migliorare la sicurezza dell’autenticazione con le shadow password .
Come usare i superdaemons per metterli in ascolto sulle connessioni di rete in entrata.
Controllare i servizi di rete rispetto a demoni non necessari.
Utilizzo di TCP wrapper come una sorta di semplice firewall.

Migliorare la Sicurezza dell’Autenticazione con le Shadow Password

I componenti di base dei dati dell’account di un utente sono memorizzati nel file /etc/passwd. Questo file contiene sette campi: nome di login, userid, groupid, password, commento (GECOS), posizione della home directory e infine la shell di default. Un modo semplice per ricordare l’ordine di questi campi è pensare al processo di login di un utente: prima si inserisce un nome di login, in secondo luogo il sistema lo mappa in un userid (uid) e in terzo luogo in un groupid (gid). Il quarto passo chiede una password, il quinto cerca il commento, il sesto entra nella home directory dell’utente e il settimo passo imposta la shell di default.

Nei sistemi moderni la password non è più memorizzata nel file /etc/passwd. Ciò che rimane al suo interno è una x minuscola nel campo password. Il file /etc/passwd deve essere leggibile da tutti gli utenti. La x indica che la password criptata (hash) è invece memorizzata nel file /etc/shadow. Questo file non deve essere leggibile da tutti gli utenti.

Le impostazioni delle password sono configurate con i comandi passwd e chage. Entrambi i comandi cambieranno la voce per l’utente emma nel file /etc/shadow. Come superutente puoi impostare la password per l’utente emma con il seguente comando:

$ sudo passwd emma
New password:
Retype new password:
passwd: password updated successfully

Ti verrà quindi richiesto due volte di confermare la nuova password.

Per elencare la data di scadenza della password e altre impostazioni di scadenza della password per l’utente emma usa:

$ sudo chage -l emma
Last password change					: Apr 27, 2020
Password expires					: never
Password inactive					: never
Account expires						: never
Minimum number of days between password change		: 0
Maximum number of days between password change		: 99999
Number of days of warning before password expires	: 7

Per impedire all’utente emma di accedere al sistema il superutente può impostare una data di scadenza della password che precede la data corrente. Per esempio, se la data di oggi fosse 2020-03-27, si potrebbe far scadere la password dell’utente usando una data antecedente:

$ sudo chage -E 2020-03-26 emma

In alternativa, il superutente può usare:

$ sudo passwd -l emma

per bloccare temporaneamente l’account tramite l’opzione -l per passwd. Per testare gli effetti di queste modifiche, prova a fare il login come emma:

$ sudo login emma
Password:
Your account has expired; please contact your system administrator

Authentication failure

Per impedire a tutti gli utenti tranne l’utente root di accedere al sistema temporaneamente, il superutente può creare un file chiamato /etc/nologin. Questo file può contenere un messaggio agli utenti che notifica loro il motivo per cui non possono accedere (per esempio con notifiche di manutenzione del sistema). Per dettagli vedere man 5 nologin. Nota che c’è anche un comando nologin che può essere usato per prevenire un login quando è impostato come shell di default per un utente. Per esempio:

$ sudo usermod -s /sbin/nologin emma

Vedi man 8 nologin per maggiori dettagli.

Come Mettere in Ascolto un Superdaemon sulle Connessioni di Rete in Entrata.

I servizi di rete come i server web, i server di posta elettronica e i server di stampa di solito funzionano come un servizio autonomo in ascolto su una porta di rete dedicata. Tutti questi servizi standalone sono in esecuzione fianco a fianco. Su un sistema classico basato su Sys-V-init ognuno di questi servizi può essere controllato dal comando service. Sugli attuali sistemi basati su systemd si dovrebbe usare systemctl per gestire il servizio.

In passato la disponibilità di risorse informatiche era molto minore. Eseguire molti servizi in modalità standalone non era una buona opzione. Invece veniva usato un cosiddetto "Superdemone" per ascoltare le connessioni di rete in arrivo e avviare il servizio appropriato su richiesta. Ben noti superdemoni sono inetd e xinetd. Sui sistemi attuali basati su systemd l’unità systemd.socket può essere usata in modo simile. In questa sezione useremo xinetd per intercettare le connessioni al demone sshd e avviare questo demone su richiesta per dimostrare come è stato usato il superdemone.

Prima di configurare il servizio xinetd è necessaria qualche attività preparatoria. Non importa se si usa un sistema basato su Debian o Red Hat: sebbene la lezione sia basata su Debian/GNU Linux 9.9, dovrebbero poter funzionare su qualsiasi sistema Linux attuale con systemd, senza alcun cambiamento significativo. Per prima cosa assicurati che i pacchetti openssh-server e xinetd siano installati. Quindi verifica che il servizio SSH funzioni con:

$ systemctl status sshd
● ssh.service - OpenBSD Secure Shell server
   Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: enabled)
   Active: active (running) since Mon 2020-04-27 09:33:48 EDT; 3h 11min ago
     Docs: man:sshd(8)
           man:sshd_config(5)
  Process: 430 ExecStartPre=/usr/sbin/sshd -t (code=exited, status=0/SUCCESS)
 Main PID: 460 (sshd)
    Tasks: 1 (limit: 1119)
   Memory: 5.3M
   CGroup: /system.slice/ssh.service
           └─460 /usr/sbin/sshd -D

Controllate anche che il servizio SSH sia in ascolto sulla sua porta di rete standard 22:

# lsof -i :22
COMMAND  PID USER   FD   TYPE   DEVICE SIZE/OFF NODE NAME
sshd    1194 root    3u  IPv4 16053268      0t0  TCP *:ssh (LISTEN)
sshd    1194 root    4u  IPv6 16053270      0t0  TCP *:ssh (LISTEN)

Infine fermate il servizio SSH con:

$ sudo systemctl stop sshd.service

Nel caso in cui tu voglia rendere questo cambiamento permanente, usa systemctl disable sshd.service.

Ora puoi creare il file di configurazione di xinetd /etc/xinetd.d/ssh con alcune impostazioni di base:

service ssh
{
	disable		= no
	socket_type	= stream
	protocol	= tcp
	wait		= no
	user		= root
	server		= /usr/sbin/sshd
	server_args 	= -i
	flags		= IPv4
	interface	= 192.168.178.1
}

Riavviate il servizio xinetd con:

$ sudo systemctl restart xinetd.service

Controlla quale servizio sia ora in ascolto ora per le connessioni SSH in entrata.

$ sudo lsof -i :22
COMMAND   PID USER   FD   TYPE  DEVICE SIZE/OFF NODE NAME
xinetd  24098 root    5u  IPv4 7345141      0t0  TCP 192.168.178.1:ssh (LISTEN)

Possiamo vedere che il servizio xinetd ha preso il controllo dell’accesso alla porta 22.

Qui di seguito ci sono alcuni dettagli in più sulla configurazione di xinetd. Il file di configurazione principale è /etc/xinetd.conf:

# Simple configuration file for xinetd
#
# Some defaults, and include /etc/xinetd.d/

defaults
{

# Please note that you need a log_type line to be able to use log_on_success
# and log_on_failure. The default is the following :
# log_type = SYSLOG daemon info

}

includedir /etc/xinetd.d

Oltre alle impostazioni predefinite, c’è solo una direttiva per impostare una include directory. In questa directory puoi impostare un singolo file di configurazione per ogni servizio che vuoi far gestire da xinetd. Lo abbiamo fatto sopra per il servizio SSH e abbiamo chiamato il file /etc/xinetd.d/ssh. I nomi dei file di configurazione possono essere scelti arbitrariamente, tranne i nomi di file che contengono un punto (.) o che terminano con una tilde (~). Ma è pratica diffusa nominare il file con il nome del servizio che si vuole configurare.

Alcuni file di configurazione nella directory /etc/xinet.d/ sono già forniti dalla distribuzione:

$ ls -l /etc/xinetd.d
total 52
-rw-r--r-- 1 root root 640 Feb  5  2018 chargen
-rw-r--r-- 1 root root 313 Feb  5  2018 chargen-udp
-rw-r--r-- 1 root root 502 Apr 11 10:18 daytime
-rw-r--r-- 1 root root 313 Feb  5  2018 daytime-udp
-rw-r--r-- 1 root root 391 Feb  5  2018 discard
-rw-r--r-- 1 root root 312 Feb  5  2018 discard-udp
-rw-r--r-- 1 root root 422 Feb  5  2018 echo
-rw-r--r-- 1 root root 304 Feb  5  2018 echo-udp
-rw-r--r-- 1 root root 312 Feb  5  2018 servers
-rw-r--r-- 1 root root 314 Feb  5  2018 services
-rw-r--r-- 1 root root 569 Feb  5  2018 time
-rw-r--r-- 1 root root 313 Feb  5  2018 time-udp

Questi file possono essere usati come modelli nel raro caso in cui si debbano usare alcuni servizi legacy come daytime, una primissima implementazione di un time server. Tutti questi file template contengono la direttiva disable = yes.

Qui ci sono alcuni dettagli in più sulle direttive usate nel file di esempio /etc/xinetd.d/ssh per ssh.

service ssh
{
	disable		= no
	socket_type	= stream
	protocol	= tcp
	wait		= no
	user		= root
	server		= /usr/sbin/sshd
	server_args 	= -i
	flags		= IPv4
	interface	= 192.168.178.1
}

service: Elenca il servizio che xinetd deve controllare. Si può usare un numero di porta, come 22, o il nome mappato al numero di porta in /etc/services, per esempio ssh.
{: Le impostazioni dettagliate iniziano con una parentesi graffa di apertura.
disable: Per attivare queste impostazioni, impostalo su no. Se vuoi disabilitare temporaneamente l’impostazione, puoi impostarla su yes.
socket_type: Puoi scegliere stream per le porte TCP o dgram per quelle UDP e altro.
protocol: Scegliere TCP o UDP.
wait: Per le connessioni TCP questo è impostato di solito su no.
user: Il servizio avviato sarà di proprietà di questo utente.
server: Percorso completo al servizio che dovrebbe essere avviato da xinetd.
server_args: Qui si possono aggiungere opzioni per il servizio. Se avviato da un super-server molti servizi richiedono un’opzione speciale. Per SSH questa opzione è -i.
flags: Si può scegliere tra IPv4, IPv6 e altri.
interface: L’interfaccia di rete che xinetd deve controllare. Nota: si può anche scegliere la direttiva bind, che è solo un sinonimo di interface.
}: Le impostazioni dettagliate terminano con una parentesi graffa di chiusura.

I successori dei servizi avviati dal super-server xinetd sono le unità socket di systemd. Impostare una socket unit di systemd è molto semplice e diretto, perché c’è una socket unit di systemd predefinita per SSH già disponibile. Assicurarsi che i servizi xinetd e SSH non siano in esecuzione.

Ora devi solo avviare l’unità socket SSH:

$ sudo systemctl start ssh.socket

Per controllare quale servizio è ora in ascolto sulla porta 22 usiamo di nuovo lsof. Nota qui che l’opzione -P è stata usata per mostrare il numero della porta invece del nome del servizio nell’output:

$ sudo lsof -i :22 -P
COMMAND PID USER   FD   TYPE   DEVICE SIZE/OFF NODE NAME
systemd   1 root   57u  IPv6 14730112      0t0  TCP *:22 (LISTEN)

Per completare il test, prova ad accedere al server con un client SSH di tua scelta.

Tip	Nel caso in cui `systemctl start ssh.socket` non funzioni con la tua distribuzione, prova `systemctl start sshd.socket`.

Controllare i Servizi per i Demoni non Necessari

Per ragioni di sicurezza, così come per controllare le risorse di sistema, è importante avere una panoramica di quali servizi siano in esecuzione. I servizi non necessari e inutilizzati dovrebbero essere disabilitati. Per esempio, se non avete bisogno di distribuire pagine web, non c’è bisogno di eseguire un server web come Apache o Nginx.

Sui sistemi basati su SyS-V-init potete controllare lo stato di tutti i servizi nel seguente modo:

$ sudo service --status-all

Verifica se ognuno dei servizi elencati nell’output del comando è necessario e disabilita tutti i servizi non necessari con (per i sistemi basati su Debian):

$ sudo update-rc.d SERVICE-NAME remove

O, su sistemi basati su Red Hat:

$ sudo chkconfig SERVICE-NAME off

Sui moderni sistemi basati su systemd possiamo usare il seguente modo per elencare tutti i servizi in esecuzione:

$ systemctl list-units --state active --type service

Dovreste quindi disattivare ogni unità di servizio non necessaria con:

$ sudo systemctl disable UNIT --now

Questo comando fermerà il servizio e lo rimuoverà dalla lista dei servizi, in modo da evitare che si avvii al prossimo avvio del sistema.

Inoltre, per ottenere una panoramica dei servizi di rete in ascolto, puoi usare netstat sui vecchi sistemi (a condizione che tu abbia installato il pacchetto net-tools):

$ netstat -ltu
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0 0.0.0.0:ssh             0.0.0.0:*               LISTEN
tcp        0      0 localhost:mysql         0.0.0.0:*               LISTEN
tcp6       0      0 [::]:http               [::]:*                  LISTEN
tcp6       0      0 [::]:ssh                [::]:*                  LISTEN
udp        0      0 0.0.0.0:bootpc          0.0.0.0:*

Oppure, sui sistemi moderni, si può usare il comando equivalente ss (per “socket services”):

$ ss -ltu
Netid      State         Recv-Q        Send-Q      Local Address:Port           Peer Address:Port
udp        UNCONN        0             0                 0.0.0.0:bootpc              0.0.0.0:*
tcp        LISTEN        0             128               0.0.0.0:ssh                 0.0.0.0:*
tcp        LISTEN        0             80              127.0.0.1:mysql               0.0.0.0:*
tcp        LISTEN        0             128                     *:http                      *:*
tcp        LISTEN        0             128                  [::]:ssh                    [::]:*

TCP Wrapper come una Sorta di Semplice Firewall

In tempi in cui non erano disponibili firewall per Linux, i wrapper TCP erano usati per proteggere le connessioni di rete in un host. Oggi molti programmi non obbediscono più ai wrapper TCP. Nelle recenti distribuzioni basate su Red Hat (per esempio Fedora 29) il supporto ai TCP wrapper è stato rimosso completamente. Al fine di supportare i sistemi Linux legacy che usano ancora i TCP wrapper, è utile avere alcune conoscenze di base su questa particolare tecnologia.

Useremo ancora una volta il servizio SSH come esempio di base. Il servizio sul nostro host di esempio dovrebbe essere raggiungibile solo dalla rete locale. Per prima cosa controlliamo se il demone SSH usa la libreria libwrap che offre supporto ai wrapper TCP:

$ ldd /usr/sbin/sshd | grep "libwrap"
        libwrap.so.0 => /lib/x86_64-linux-gnu/libwrap.so.0 (0x00007f91dbec0000)

Ora aggiungiamo la seguente linea nel file /etc/hosts.deny:

sshd: ALL

Infine configuriamo un’eccezione nel file /etc/hosts.allow per le connessioni SSH dalla rete locale:

sshd: LOCAL

I cambiamenti hanno effetto immediato, non c’è bisogno di riavviare alcun servizio. Puoi verificarlo con il client ssh.

Esercizi Guidati

Come si può sbloccare l’account emma precedentemente bloccato?
In precedenza l’account emma aveva una data di scadenza impostata. Come può la data di scadenza essere impostata su mai?
Immagina che il servizio di stampa CUPS che gestisce i lavori di stampa non sia necessario sul server. Come puoi disabilitare il servizio in modo permanente? Come puoi controllare che la porta appropriata non sia più attiva?
Hai installato il server web Nginx. Come puoi controllare se quest’ultimo supporta i wrapper TCP?

Esercizi Esplorativi

Verifica se l’esistenza del file /etc/nologin impedisce il login dell’utente root?
L’esistenza del file /etc/nologin impedisce i login senza password con chiavi SSH?
Cosa succede al login, quando il file /etc/nologin contiene solo questa linea di testo login currently is not possible?
Un utente ordinario emma può ottenere informazioni sull’utente root contenute nel file /etc/passwd, per esempio con il comando grep root /etc/passwd?
Un normale utente emma può recuperare informazioni sul suo password hash contenuto nel file /etc/shadow, per esempio con il comando grep emma /etc/shadow?
Quali passi devono essere fatti per abilitare e controllare il servizio legacy daytime attraverso l’utilizzo di xinetd? Nota che questo è solo un esercizio esplorativo, non farlo in un ambiente di produzione.

Sommario

In questa lezione abbiamo imparato:

In quale file sono memorizzate le password e alcune impostazioni di sicurezza delle password, per esempio la data di scadenza.
Lo scopo del superdemone xinetd e come farlo funzionare e avviare il servizio sshd a richiesta.
A controllare quali servizi di rete sono in esecuzione e come disabilitare i servizi non necessari.
A usare i wrapper TCP come una sorta di semplice firewall.

Comandi usati nel laboratorio e negli esercizi:

chage: Comando che cambia la scadenza della password di un utente.
chkconfig: Un classico comando usato inizialmente sui sistemi basati su Red Hat per impostare se un servizio viene eseguito all’avvio o meno.
netstat: Una classica utility (ora nel pacchetto net-tools) che visualizza le statistiche e le informazioni di rete.
nologin: Un comando che può essere usato al posto della shell di un utente per impedirgli di fare il login.
passwd: Un comando usato per creare o cambiare la password di un utente.
service: Vecchio metodo per controllare lo stato di un demone, come fermare o avviare un servizio.
ss: L’equivalente moderno di netstat, ma mostra anche più informazioni sui vari socket in uso nel sistema.
systemctl: Il comando di controllo del sistema usato per gestire vari aspetti dei servizi e dei socket su un Linux che implementa systemd.
update-rc.d: Un classico comando simile a chkconfig che abilita o disabilita l’avvio di un servizio all’avvio nelle distribuzioni basate su Debian.
xinetd: Un superdemone che può controllare l’accesso a un servizio di rete su richiesta, lasciando così un servizio inattivo finché non venga effettivamente richiamato per eseguire un qualche compito.

Risposte agli Esercizi Guidati

Come si può sbloccare l’account emma precedentemente bloccato?

Il superutente può eseguire passwd -u emma per sbloccare l’account.
In precedenza l’account emma aveva una data di scadenza impostata. Come può la data di scadenza essere impostata su mai?

Il superutente può usare chage -E -1 emma per impostare la data di scadenza a mai. Questa impostazione può essere controllata con chage -l emma.
Immagina che il servizio di stampa CUPS che gestisce i lavori di stampa non sia necessario sul server. Come puoi disabilitare il servizio in modo permanente? Come puoi controllare che la porta appropriata non sia più attiva?

Come superutente digita:
```
systemctl disable cups.service --now
```
Ora controlla con:
```
netstat -l | grep ":ipp "` or `ss -l | grep ":ipp "
```
Hai installato il server web Nginx. Come puoi controllare se quest’ultimo supporta i wrapper TCP?

Il comando
```
ldd /usr/sbin/nginx | grep "libwrap"
```
mostrerà una voce nel caso in cui Nginx supporti i wrapper TCP.

Risposte agli Esercizi Esplorativi

Verifica se l’esistenza del file /etc/nologin impedisce il login dell’utente root?

L’utente root è ancora in grado di accedere.
L’esistenza del file /etc/nologin impedisce i login senza password con chiavi SSH?

Sì, anche i login senza password sono impediti.
Cosa succede al login, quando il file /etc/nologin contiene solo questa linea di testo login currently is not possible?

Verrà mostrato il messaggio login currently is not possible, e il login sarà impedito.
Un utente ordinario emma può ottenere informazioni sull’utente root contenute nel file /etc/passwd, per esempio con il comando grep root /etc/passwd?

Sì, perché tutti gli utenti hanno il permesso di lettura a questo file.
Un normale utente emma può recuperare informazioni sul suo password hash contenuto nel file /etc/shadow, per esempio con il comando grep emma /etc/shadow?

No, perché gli utenti ordinari non hanno il permesso di lettura a questo file.
Quali passi devono essere fatti per abilitare e controllare il servizio legacy daytime attraverso l’utilizzo di xinetd? Nota che questo è solo un esercizio esplorativo, non farlo in un ambiente di produzione.

Per prima cosa cambia il file /etc/xinetd.d/daytime e imposta la direttiva disable = no. In secondo luogo riavvia il servizio xinetd systemctl restart xinetd.service (o service xinetd restart sui sistemi con SyS-V-Init). Ora controlla se funziona con nc localhost daytime. Invece di nc si può usare anche netcat.