Un’intrusione nel server lascia tracce diverse da quelle nei siti: un utente o una chiave SSH in più, un permesso di sudo, un servizio che resta acceso, un programma di sistema sostituito. Il controllo del server le cerca confrontando il server con un riferimento, cioè com’era l’ultima volta che una persona l’ha approvato. Il primo controllo completo crea il riferimento.
Cosa si controlla
| Cosa | Quando |
|---|---|
| Utenti con una shell, e chiunque abbia l’UID 0 di root | Ogni ora e ogni notte |
| Membri dei gruppi con privilegi: sudo, docker, sshadmins e simili | |
File di sudo, della configurazione di SSH e di PAM, /etc/ld.so.preload | |
| Chiavi SSH di root e degli amministratori | |
| Porte in ascolto e il programma che le apre | |
| Servizi e timer di systemd: quali ci sono e se sono attivi | |
| Lavori pianificati di cron e at | |
| Container Docker (oggi c’è solo quello della dashboard) | |
| Chiavi pubbliche della cassaforte della produzione | |
Programmi in /usr/local: gli script della piattaforma e wp-cli | |
| File con il bit SUID o SGID, che girano con i permessi del proprietario | Ogni notte e a richiesta |
| File dei pacchetti installati, confrontati con gli originali (debsums) | |
| Aggiornamenti di sicurezza non ancora installati: solo una nota |
Allarme o nota
Ciò che è nuovo o cambiato è un allarme, e arriva anche come notifica, una volta sola. Ciò che non c’è più (un file di sudo tolto, una chiave revocata) è una nota: togliere riduce i permessi. L’eccezione sono i servizi di systemd: tolto o spento è un allarme, perché spegnere le difese è una delle prime cose che fa un intruso.
Dove si vede
Server → Sicurezza, sezione Server: gli allarmi, la tabella delle differenze dal riferimento, cosa è sotto controllo e gli aggiornamenti in sospeso. Controlla ora il server rifà il controllo completo in una ventina di secondi, e possono lanciarlo anche i lettori.
Accettare un cambiamento voluto
Avete aggiunto voi un amministratore, una chiave o un servizio? Un amministratore della dashboard spunta Le ho verificate: sono nostre e preme Accetta come nuovo riferimento. Il controllo si rifà, la pagina del lavoro dice cosa è stato accettato e nel Registro resta chi l’ha fatto. Se una differenza non la riconoscete, non accettate: è il segno di un’intrusione.
I file dei pacchetti alterati non si accettano dalla dashboard, perché un programma di sistema diverso dall’originale è il segnale più grave. Si rimette il pacchetto con apt-get install --reinstall <pacchetto> e si rifà il controllo.
Sui server di produzione i programmi in /usr/local che coincidono con il manifesto degli strumenti firmati, con la firma valida, entrano da soli nel riferimento: un aggiornamento degli strumenti non è un allarme, ogni altro cambio sì.
Nemmeno le chiavi della cassaforte si accettano dalla dashboard: chi le sostituisce riceverebbe i segreti salvati dopo. Si confronta da shell l’impronta di site-vault.py status con quella nel password manager; se il cambio è vostro, si accetta con integrity-check.sh --system --baseline. Vedi Produzione e cassaforte.
Il limite
Un attaccante diventato root può falsare qualsiasi controllo che gira sul server, compreso questo. I controlli servono a scoprire presto un’intrusione, non a ripararla: un server compromesso si rifà da zero con server-bootstrap.sh e i backup.
Da shell
integrity-check.sh --system
integrity-check.sh --system --baseline
server-scan.py check --light