Introduzione al design di una infrastruttura di rete sicura

Non esistono certezze nel campo dell'Information Security, non esiste un sistema in rete sicuro al 100%: di un software che oggi appare sicuro, domani potranno essere trovati buchi sfruttabili per intrusioni esterne; una rete per quanto protetta deve essere amministrabile e chi la amministra o la utilizza con privilegi particolari, può essere esso stesso una minaccia.
Per quanto le problematiche di sicurezza siano quindi vaste e abbiano fattori diversi (accesso fisico ai sistemi, livello di fiducia nelle persone che li amministrano, potenziale insicurezza dei software usati...) si possono definire alcune linee guida minime per disegnare una rete il più possibile protetta da quelle che di fatto sono le maggiori minacce: l'intrusione di ignoti da Internet.
L'accesso da remoto ad un sistema può avvenire quasi esclusivamente tramite una porta TCP o UDP aperta su un host in rete, per cui a livello di networking il controllo e l'attenzione vanno posti su quali porte lasciare accessibili e come.
Realizzare una rete con un design di base sicuro richiede l'applicazione di alcune semplici regole di base, che vanno adattate ai diversi contesti specifici:

- Chiudere le porte su IP pubblico non utilizzate
Ogni tentativo di intrusione remoto può avvenire solo tramite eventuali porte aperte su un host. La prima, fondamentale, comoda e utile procedura da adottare per iniziare a proteggere il proprio network è quella di non lasciare varchi inutili ai potenziali intrusori.
La chiusura delle porte può essere fatta sia a livello dei singoli host (consigliata in ogni caso), rimuovendo tutti i servizi che non servono, sia a livello di firewall perimetrale, con un rigoroso packet filtering.
Le due soluzioni non sono alternative, anzi possono tranquillamente coesistere: sull'host si rimuovono i servizi inutili, sul firewall si possono gestire quali indirizzi IP sorgenti possono accedere a determinati servizi.
Questo si ricollega al secondo punto chiave:

- Centralizzare i punti di controllo del traffico
Tipicamente una rete aumenta la sua complessità con la sua naturale crescita, ma se non viene strutturata dall'inizio in modo lungimirante, rischia di diventare una matassa di router e firewall su cui si deve intervenire in caso di problemi o "aperture di porte".
Centralizzare i punti di routing e firewalling aiuta a implementare più facilmente modifiche alle configurazioni esistenti e a dignosticare problemi di rete, oltre a ridurre i point of failure della nostra infrastruttura.
Il firewall perimetrale (lo trattiamo come entità unica, ma può essere tranquillamente una coppia o una "nuvola" di firewall in failover) dovrebbe, di default, bloccare ogni tipo di pacchetto dall'esterno e prevedere regole specifiche per ogni server in produzione. Queste regole possono essere di 2 tipi:
- regole che aprono una determinata porta di un dato host a tutta Internet. Queste sono quelle necessarie per i servizi pubblici in produzione (server web, server di posta, DNS ecc.) ed è bene che "aprano" sono le porte strettamente necessarie e non tutto un indirizzo IP (anche se su questo risponde una macchina con tutti i servizi inutili disattivati). Sui firewall che gestiscono regole di filtraggio in modo sequenziale (le catene di iptables, le ACL del Cisco IOS o del PIX...) è sempre meglio mettere per prime le regole che riguardano i flussi di traffico maggiori, per diminuire l'impatto sulle risorse evitando inutili controlli su regole di filtering poco usate.
- regole che aprono l'accesso a determinate porte e IP da specifici IP sorgenti. Possono essere necessarie per aprire l'accesso FTP a dei data feed provider o permettere l'accesso in VPN da una determinata sede o l'accesso ad un database da un server remoto. Queste tipicamente tendono a rendere più verbosa e complicata la configurazione di un firewall, dal momento che devono adattarsi a IP sorgenti specifici, ma visto che sono necessarie è opportuno centralizzarle.
Nell'applicare simili regole, che tendono per il loro numero ad appesantire il firewall, si consiglia buon senso e tendenza al raggruppamento: se ci sono più IP da "aprire" della stessa subnet, si può considerare l'apertura dell'intera subnet, se ci sono più porte da aprire (sopratutto porte che di fatto permettono l'accesso al sistema, come telnet e ssh) può aver senso aprire l'accesso all'intero IP dell'host di destinazione, senza specificarne le singole porte.

- Controllare tutti i punti di accesso
In termini di sicurezza informatica, l'anello debole, quello meno controllato e sicuro, riduce la sicurezza di tutta l'infrastruttura. Per questo motivo è fondamentale identificare e ponderare ogni punto di accesso ai nostri sistemi da remoto. Questo include router e linee di partner, clienti e fornitori, macchine per permettono l'accesso via modem alla rete da proteggere ma anche dipositivi meno comuni come gateway X25 per pagamenti elettronici.
A prescindere quindi da tutte le protezioni del caso da prendere sia a livello fisico, che a livello dei client degli utenti (sviluppatori, sistemisti, redattori ecc) che in qualche modo possono accedere in modo privilegiato alla nostra rete, vanno verificati anche tutti i punti di entrata accessibili pubblicamente.
Come sempre, se questi prevedono un accesso via password, la coppia login-password dovrebbe non essere facilmente intuibile e il relativo traffico dovrebbe essere criptato.

- Design multilayer in caso di reti complesse
Se la rete da gestire comprende decine di host, di diversi utilizzi (macchine in produzione di front-end, cioè che devono interagire direttamente con Internet, macchine di backend come database o sistemi di monitoring, macchine di stage e pre-produzione, macchine di sviluppo, client di sistemisti e sviluppatori ecc) è opportuno valutare una suddivisione della nostra rete in più livelli, cercando di proteggere quelli più interni e delicati (il backend) e limitando allo stretto necessario l'accesso a queste macchine da parte di altre macchine più esposte (per esempio i server pubblici di front-end, i server di sviluppo, i client vari).
In strutture complesse, inoltre, le macchine di frontend, se possibile, non dovrebbero avere accesso in scrittura ai dati: un web server per esempio non dovrebbe poter scrivere sulla directory in cui sono contenute le sue pagine web, eventualmente generate da un Content Management System sul backend.
Con reti più semplici è comunque buona norma cercare di limitare allo stretto necessario le possibilità di comunicazione di una macchina con qualciasi altra macchina del nostro network, in modo da limitare i potenziali danni su tutti i sistemi dopo l'intrusione in uno degli host.

- Diversificare le difese
Il Tipico Esperto di Sicurezza, per definizione, solleva una quantità di problematiche enormi, non del tutto ingiustificate invero, e arriva ad analizzare molteplici aspetti, dalla sicurezza fisica al training del personale, dal logging di ogni bit sospetto alla gestione di un verbosissimo IDS, che nella realtà spesso diventano di difficile attuazione.
Un'altra delle Tipiche Raccomandazioni del suddetto Esperto è la diversificazione delle difese: non basta il firewall, non basta l'IDS, non basta la password sul Bios: ogni possibile mezzo per rendere difficile la vita ad un cracker è un buon mezzo, anche se a volte rende la vita difficile anche ad un sysadmin.
Un esempio tipico è la rimozione di ogni programma non strettamente necessario da un server in produzione: nessun comando per scaricare un file da remoto (wget, ftp, lynk, irc, curl ecc), nessun compilatore che permetta ad un intrusore di compilarsi i suoi sorgenti maligni direttamente sul nostro sistema, sistema di Mandatory Access Control che impedisca ad un qualsiasi processo di fare qualcosa di diverso da quello che è stato configurato per fare.
Dal punto di vista della sicurezza sono tutti buoni mezzi che aumentano la solidità del sistema e al contempo ne aumentano la difficoltà di gestione.
Come al solito, nel mezzo e nelle nostre specifiche esigenze, sta la soluzione ideale.

A queste indicazioni generali, che si applicano considerando solo a livello di rete le nostre problematiche di sicurezza si affiancano tutte le altre procedure volte a rendere sicuri i servizi che si lasciano aperti in rete.
Questo è un argomento ben più complesso e articolato, che riguarda i singoli sistemi operativi, i software utilizzati e le proprie implementazioni specifiche.
Come si è potuto intravedere, quindi, realizzare un sistema estremamente sicuro è complicato e richiede sforzi e risorse notevoli, ma realizzare una struttura di rete "ragionevolmente" sicura, che ci possa proteggere dalla maggior parte delle insidie non è eccessivamente gravoso e si può riassumere, semplificando all'estremo, in tre principi fondamentali:
- ridurre al massimo le porte esposte a Internet;
- avere software aggiornati in ascolto sulle porte esposte;
- non configurare in modo scorretto i servizi pubblici.

Privacy Policy