Caso reale · infrastruttura anonimizzata
Proteggere un VPS Debian 12 senza interrompere gli accessi amministrativi.
Un’attivazione reale su un server applicativo esterno: Sentinel è stato affiancato a Fail2Ban, collegato al nucleo centrale e verificato fino al firewall locale.
Debian 12SSH ristrettoFail2Ban esistenteVerifica del 29 agosto 2026
Il contesto
Una macchina già protetta, ma con strumenti e responsabilità separate.
L’obiettivo non era sostituire ciò che funzionava: serviva aggiungere visibilità centrale e indicatori condivisi senza introdurre un nuovo punto di blocco per gli amministratori.
VPS applicativo esterno
Server Debian 12 con applicazione web e amministrazione SSH limitata a un gruppo ristretto di sorgenti autorizzate.
Fail2Ban già operativo
Tre jail attive e regole firewall già presenti. Sentinel doveva convivere con queste difese mantenendo distinta la proprietà dei blocchi.
Nessun lockout
Un falso blocco su una sorgente amministrativa avrebbe potuto rendere irraggiungibile la macchina. L’allowlist era quindi un prerequisito, non un’aggiunta successiva.
La sfida tecnica
Debian 12 usava journald, mentre il watcher SSH attendeva un file di autenticazione.
Il preflight ha rilevato l’assenza di /var/log/auth.log: su questa installazione Debian gli eventi erano disponibili soltanto in journald. Un agent formalmente avviato, senza una sorgente leggibile, non avrebbe svolto il controllo SSH previsto.
In parallelo, il firewall ospitava già le catene di Fail2Ban e più sessioni amministrative erano aperte. Prima di applicare qualsiasi indicatore condiviso bisognava proteggere le sorgenti autorizzate.
L’intervento
Cinque controlli, nello stesso ordine in cui riducono il rischio.
- 01
Preflight
Inventario, backup e verifica del canale
Sono stati controllati distribuzione, configurazione esistente, repository firmato, endpoint TLS e credenziale dedicata. Il file locale è stato salvato prima delle modifiche.
EsitoPacchetto verificato e configurazione precedente recuperabile. - 02
Sorgente eventi
Preparazione del log di autenticazione
È stato attivato il percorso supportato per gli eventi
authprive generato il primo evento, così il watcher non ha dovuto attendere un futuro tentativo di accesso per trovare il file.EsitoWatcher SSH avviato su una sorgente reale e leggibile. - 03
Anti-lockout
Allineamento delle allowlist
Le nove sorgenti amministrative autorizzate sono state protette sia in Sentinel sia in Fail2Ban. Sono state inoltre verificate le sessioni SSH già stabilite prima di applicare i blocchi.
EsitoNessuna sorgente autorizzata presente nella catena di blocco Sentinel. - 04
Firewall
Catena Sentinel separata
L’agent ha creato la propria catena e il proprio insieme di indirizzi. Fail2Ban è rimasto attivo sulle sue catene: nessuna regola preesistente è stata sovrascritta.
EsitoResponsabilità delle regole leggibile e rollback circoscritto. - 05
Validazione
Sincronizzazione, riavvio e lettura dei log
Al primo collegamento sono stati sincronizzati 183 indicatori attivi. Dopo il riavvio finale sono stati verificati servizio, watcher, firewall, sessioni SSH e messaggi successivi al nuovo timestamp.
EsitoAgent stabile, collegato e senza nuovi errori nel journal osservato.
Il risultato
Più contesto centrale, senza togliere controllo alla macchina.
Sentinel ha aggiunto telemetria e indicatori condivisi mantenendo locali le decisioni firewall. Le difese esistenti hanno continuato a funzionare e le sessioni autorizzate non sono state interrotte.
Verifica completataSnapshot del 29/08/2026
- Servizio agent
- active (running)
- Canale centrale
- TLS verificato
- Watcher SSH
- Attivo
- Firewall
- Catena dedicata
- Fail2Ban
- Operativo, non sostituito
- Errori dopo il riavvio
- 0 osservati
Cosa abbiamo imparato
Le verifiche che rendono ripetibile il deployment.
“Running” non basta
Un servizio attivo può avere un watcher inutilizzabile. La verifica deve arrivare fino alla sorgente degli eventi e all’azione sul firewall.
L’allowlist viene prima
Le reti di gestione vanno raccolte e protette prima della sincronizzazione dei blocchi, soprattutto nelle installazioni automatiche.
Ogni sistema mantiene le sue regole
Sentinel e Fail2Ban possono convivere se catene, log e ownership restano identificabili e il rollback non cancella controlli estranei.
I log vanno letti nel tempo giusto
Gli errori precedenti a una correzione non descrivono lo stato corrente. Il controllo finale parte sempre dal timestamp dell’ultimo riavvio.
Trasparenza del caso studio
Dati reali, identità rimossa e confini dichiarati.
Questo caso deriva da una verifica tecnica eseguita su una singola macchina. Per sicurezza non pubblichiamo cliente, IP, hostname, provider, API key, reti autorizzate o contenuti applicativi.
I numeri rappresentano lo stato osservato durante quella verifica: non sono un benchmark, una media della rete Sentinel o una garanzia di risultati identici su altre infrastrutture.
Periodo della verifica: 29 agosto 2026 · Revisione editoriale: 9 settembre 2026
Vuoi applicare lo stesso metodo alla tua infrastruttura?
Partiamo da accessi, log, firewall e strumenti già presenti, poi definiamo un’attivazione verificabile e reversibile.