Product SiteDocumentation Site

Capitolo 14. Sicurezza

14.1. Definire la politica di sicurezza
14.2. Firewall o filtraggio dei pacchetti
14.2.1. nftables Behavior
14.2.2. Moving from iptables to nftables
14.2.3. Sintassi di nft
14.2.4. Installare le regole ad ogni avvio
14.3. Supervisione: prevenire, rilevare, dissuadere
14.3.1. Monitorare i log con logcheck
14.3.2. Attività di monitoraggio
14.3.3. Avoiding Intrusion
14.3.4. Rilevare le modifiche
14.3.5. Rilevare intrusioni (IDS/NIDS)
14.4. Introduzione a AppArmor
14.4.1. Princìpi
14.4.2. Abilitazione di AppArmor e gestione dei profili di AppArmor
14.4.3. Creare un nuovo profilo
14.5. Introduzione a SELinux
14.5.1. Princìpi
14.5.2. Impostare SELinux
14.5.3. Gestire un sistema SELinux
14.5.4. Adattare le regole
14.6. Altre considerazioni relative alla sicurezza
14.6.1. Rischi intrinseci delle applicazioni web
14.6.2. Sapere cosa aspettarsi
14.6.3. Scegliere saggiamente il software
14.6.4. Gestire una macchina nel suo complesso
14.6.5. Agli utenti piace giocare
14.6.6. Sicurezza fisica
14.6.7. Responsabilità legale
14.7. Gestire una macchina compromessa
14.7.1. Rilevare ed esaminare l'intrusione di un cracker
14.7.2. Mettere off-line il server
14.7.3. Mantenere tutto ciò che può essere usato come prova
14.7.4. Re-installare
14.7.5. Analisi forensi
14.7.6. Ricostruire lo scenario dell'intrusione
Un sistema informatico può presentare un livello di importanza variabile a seconda dell'ambiente. In alcuni casi è vitale per la sopravvivenza dell'azienda. Perciò deve essere protetto da vari tipi di rischi. Il processo di valutazione di questi rischi, la loro definizione e l'implementazione della protezione sono comunemente conosciuti come «processo di sicurezza».

14.1. Definire la politica di sicurezza

La parola «sicurezza» di per sé coinvolge un ampio inseme di concetti, strumenti e procedure, nessuno dei quali ha valenza universale. Per scegliere tra questi bisogna farsi un'idea precisa di quali siano i propri obbiettivi. La messa in sicurezza di un sistema inizia con la ricerca della risposta ad alcune domande. Buttandosi a capofitto nell'implementazione di un insieme arbitrario di strumenti, si rischia di concentrarsi su aspetti errati della sicurezza.
La primissima cosa da definire è perciò lo scopo. Un buon approccio che ne facilita l'individuazione inizia con le seguenti domande:
  • Cosa stiamo tentando di proteggere? La politica di sicurezza sarà differente se vogliamo proteggere il computer oppure i dati. Nell'ultimo caso, abbiamo anche bisogno di conoscere quali dati.
  • Da cosa stiamo tentando di proteggerci? Fuga di dati confidenziali? Perdita accidentale di dati? Mancati ricavi derivanti da interruzione di servizio?
  • Inoltre, da chi stiamo tentando di proteggerci? Le misure di sicurezza possono essere piuttosto differenti se si deve rimediare all'errore di un utente ordinario rispetto alla difesa da un gruppo di autori di attacchi determinati.
Il termine «rischio» è utilizzato abitualmente per riferirsi all'insieme di questi tre fattori: cosa proteggere, cosa si vuole evitare che accada, e chi vuole che accada. L'individuazione del rischio richiede la risposta a queste tre domande. Da questo modello di rischio può essere costruita una politica di sicurezza, che può essere implementata con azioni concrete.
Vale la pena di prendere in considerazione anche vincoli aggiuntivi, in quanto possono restringere la gamma delle politiche da intraprendere. Quanto siamo disposti a fare per proteggere il sistema? Questa domanda ha un forte impatto sulle scelte da adottare. La risposta è troppo spesso definita unicamente in base ad aspetti economici, ma bisogna considerare anche altri elementi, come la quantità di disagio imposto agli utenti del sistema o l'impatto negativo sulle prestazioni.
Una volta creato un modello del rischio, bisogna iniziare a pensare alla progettazione di una concreta politica di sicurezza.
Nella maggior parte dei casi, il sistema informatico può essere segmentato in sottoinsiemi coerenti e per lo più indipendenti. Ogni sottosistema avrà i propri requisiti e vincoli, e quindi la valutazione del rischio e la progettazione della politica di sicurezza dev'essere effettuata separatamente per ognuno. Un buon principio da seguire è che un perimetro breve e ben definito è più facile da difendere di una frontiera lunga e tortuosa. L'architettura di rete dev'essere progettata di conseguenza: i servizi critici devono essere concentrati in poche macchine, e tali macchine devono essere accessibili attraverso un numero minimo di punti di controllo; sarà più facile proteggere questi punti piuttosto di schermare tutte le macchine sensibili dall'intero mondo esterno. È a questo punto che diventa evidente l'utilità di regolamentare il traffico di rete (anche attraverso firewall). Questo processo può essere implementato con hardware dedicato, ma una possibile soluzione più semplice e flessibile è l'uso di un firewall software come quello integrato nel kernel Linux.