In qualità di amministratore di sistema, potresti aver già sperimentato la gioia (?) di far controllare i tuoi sistemi da un professionista della sicurezza o della gestione del rischio. Gli strumenti di sicurezza utilizzati dai revisori generalmente scansionano i sistemi e producono un rapporto per il revisore che evidenzia le vulnerabilità rilevate nel sistema scansionato, che il revisore presenta quindi al team che gestisce i sistemi. L'aspettativa è che il team di amministrazione e gestione risolverà le vulnerabilità segnalate. Tuttavia, per le distribuzioni Linux aziendali, le correzioni consigliate dal revisore potrebbero non essere la scelta migliore per l'organizzazione.
Ottenere le informazioni
Partendo da un esempio, molti di questi strumenti di controllo iniziano con la scansione delle porte di un sistema di destinazione e la connessione a porte aperte per raccogliere dati sui servizi offerti dalla macchina. Ecco un esempio di scansione delle porte dal mio sistema, generato da nmap comando:
[root@somebox ~]# nmap 10.200.157.174
Starting Nmap 6.40 ( http://nmap.org ) at 2020-01-29 13:40 CET
Nmap scan report for 10.200.157.174
Host is up (0.000010s latency).
Not shown: 997 closed ports
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
111/tcp open rpcbind
Nmap done: 1 IP address (1 host up) scanned in 0.41 seconds
Da questo output puoi vedere che le porte 22, 80 e 111 sono disponibili per i servizi che si connettono a questo sistema. È probabile che uno strumento di controllo della sicurezza si connetta a ciascuna di queste porte per determinare cosa è in esecuzione su di esse oppure potrebbe utilizzare un'utilità di profilazione per raccogliere e analizzare questi dati. Userò il telnet comando per connettersi alla porta 80 di questa macchina per determinare cosa è in esecuzione lì:
[root@somebox ~]# telnet 10.200.157.174 80
Trying 10.200.157.174...
Connected to 10.200.157.174.
Escape character is '^]'.
help
HTTP/1.1 400 Bad Request
Date: Wed, 29 Jan 2020 12:46:39 GMT
Server: Apache/2.4.6 (Red Hat Enterprise Linux)
Content-Length: 226
Connection: close
Content-Type: text/html; charset=iso-8859-1
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>400 Bad Request</title>
</head><body>
<h1>Bad Request</h1>
<p>Your browser sent a request that this server could not understand.<br />
</p>
</body></html>
Connection closed by foreign host.
Dopo aver stabilito la connessione, ho dovuto fare una richiesta del servizio. In questo caso ho digitato la parola “help” che, a seconda del servizio, potrebbe essere un comando. Per il servizio in esecuzione sulla porta 80 di questo sistema, tuttavia, la guida non è un comando compreso. Di conseguenza, viene prodotto un errore. Nell'intestazione, puoi vedere alcune informazioni sul sistema e sul servizio. In particolare, il servizio su questa porta è Apache versione 2.4.6.
Abbastanza sicuro, se verifico queste informazioni guardando un yum list , Apache versione 2.4.6 è la versione installata e in esecuzione sulla macchina:
[root@somebox ~]# yum list httpd
… output truncated…
Installed Packages
httpd.x86_64 2.4.6-89.el7_6.1 @rhel-x86_64-workstation-7.6
Gestione della relazione di revisione
È qui che le cose iniziano a farsi interessanti. Nella mia esperienza, quello che succede è che il rapporto di audit arriva sulla scrivania e dice qualcosa del tipo:
Rilevata vecchia versione di Apache (2.4.6) che presenta diverse vulnerabilità che sono state chiuse nelle versioni più recenti di Apache.
Raccomandazione:installa la versione aggiornata di Apache, 2.4.41, la più recente.
A questo punto, come distribuzione Linux aziendale, dovresti interrompere. Comprendere che la relazione del revisore evidenzia che, in base alle informazioni di scansione del sistema, questo sistema potrebbe presentare vulnerabilità aperte. Il rapporto del revisore è corretto affermando che l'installazione della versione più recente di Apache da apache.org risolverebbe il problema. Tuttavia, come sistema Linux aziendale, queste potenziali vulnerabilità sono probabilmente già chiuse nella versione di Apache attualmente distribuita sul sistema.
Si noti che la versione sul sistema è 2.4.6-89.el7_6.1, dove 2.4.6 è il numero di versione effettivo e il numero di versione aggiuntivo per questo pacchetto è 89.el7_6.1. Le distribuzioni Enterprise Linux spesso prendono correzioni per problemi da versioni più recenti e trasferiscono tali correzioni in una base di codice precedente, quindi compilano una versione aggiornata di questo pacchetto software precedente. Per Red Hat Enterprise Linux, il sistema operativo sul mio sistema di esempio, gli ingegneri che gestiscono il pacchetto Apache tengono traccia di queste modifiche applicate tramite questo numero di versione aggiuntivo sul pacchetto rpm.
Alcuni revisori lo sanno già e alcuni strumenti tengono conto anche di questo tipo di gestione del software. A volte, però, lavorerai con qualcuno che utilizza uno strumento di scansione meno sofisticato. Non solo, questa persona potrebbe anche non essere a conoscenza del fatto che la versione precedente di Apache su questo sistema è corretta versione da installare su questa macchina e che le vulnerabilità di sicurezza che potrebbero interessare le persone che si occupano della sicurezza o della gestione del rischio sono già chiuse. E in quanto amministratore di sistema, spesso spetta a te spiegare perché la tua organizzazione non dovrebbe installare la versione più aggiornata di questo pacchetto, contrariamente alla raccomandazione dell'auditor.
In base alla mia esperienza, uno dei modi migliori per illustrare questo punto è esaminare i dati aggiuntivi inclusi nella versione Linux aziendale di questo pacchetto software. Molte distribuzioni Linux aziendali utilizzeranno funzionalità come il registro delle modifiche RPM per evidenziare questi dati. Ecco le informazioni dal mio sistema di esempio:
[root@somebox ~]# rpm -q httpd --changelog
* Tue Jun 25 2019 Lubos Uhliarik <> - 2.4.6-89.1
- Resolves: #1719722 - CVE-2018-1312 httpd: Weak Digest auth
nonce generation in mod_auth_digest
… output truncated …
Secondo l'avviso CVE collegato sopra, questa vulnerabilità non è stata risolta in Apache fino a dopo 2.4.29. Tuttavia, puoi vedere nell'output del log delle modifiche di questo pacchetto che una correzione per CVE-2018-1312 è stata trasferita e applicata alla base di codice attualmente installata, che è basata su Apache 2.4.6. Questo fatto significa che il mio sistema di esempio non è vulnerabile a questo exploit, nonostante sia una versione precedente del software Apache.
Perché tutto questo è importante? Probabilmente, se stai utilizzando una distribuzione Linux aziendale, lo stai facendo perché vuoi ridurre al minimo le modifiche, i potenziali conflitti e altri problemi di mancata corrispondenza del software. L'aggiornamento di Apache, come indicato dalla raccomandazione di audit, sarebbe contrario all'obiettivo di ridurre al minimo le modifiche. Se sei un cliente supportato commercialmente, il tuo fornitore probabilmente non supporterebbe più i problemi relativi ad Apache su questa macchina se passassi a una versione che non viene fornita con la loro distribuzione.
Conclusione
Per sopravvivere a un rapporto di controllo, come nell'esempio sopra, devi collaborare con l'auditor per assicurarti che comprenda come vengono mantenuti i pacchetti Linux aziendali (che la versione visualizzata sulla porta potrebbe non essere la stessa della versione installata sul sistema) e che il packager Linux aziendale in genere conserva le versioni precedenti di questi pacchetti per tenere conto delle vulnerabilità che un revisore dei conti, un professionista della sicurezza informatica o un addetto alla gestione del rischio potrebbero trovare. L'uso di dati come le informazioni del registro delle modifiche può aiutare a dimostrare questo concetto di backporting e gestione dei pacchetti Linux aziendali.
Vuoi provare Red Hat Enterprise Linux? Scaricalo ora gratuitamente.