Introduzione
GARR-B, evoluzione della rete GARR-2, è la nuova rete della ricerca italiana (per maggiori dettagli: "GARR-B, Piano Esecutivo").
La topologia della rete GARR-B semplifica la realizzazione di una politica di sicurezza: la connessione a GARR-B da un sito utente avviene direttamente sul più vicino POP del backbone, gestito centralmente dal Network Operation Centre (si veda: "Definizione delle funzioni del NOC nella rete GARR-B"). Quindi quasi tutti i siti utente in GARR-B sono delle semplici foglie della rete (anche se alcuni possono avere delle backdoor tra loro o con altri siti non GARR); inoltre il controllo centralizzato del backbone permette, in linea di principio, interventi di emergenza atti ad isolare situazioni "pericolose".
D'altra parte una politica
di sicurezza preventiva può essere effettuata efficacemente solo a livello
di sito utente tramite un'opportuna configurazione degli apparati.
Scopo di questo documento
è esaminare politiche preventive di sicurezza, illustrando le forme di
protezione realizzabili sul router utente verso i più comuni attacchi
via rete con particolare attenzione verso i problemi legati ai difetti
intrinseci del protocollo IP.
Gli esempi si riferiscono
all'IOS dei router Cisco.
Configurazione di
base
|
Il primo passo per la prevenzione
è abilitare il sistema di log per tenere traccia di tutti gli eventi "interessanti".
(È inutile dire che il
server sul quale viene registrato il file di log deve essere adeguatamente
protetto; è consigliabile inoltre adottare meccanismi automatici di
allarme, ad es. swatch).
service timestamps log datetime logging trap debugging logging facility <LOG FILE> logging <LOG SERVER>
Per eliminare la possibilita`
che un router utente sia utilizzato come "ponte" per
connessioni illecite, è consigliabile disabilitare la
possibilita` di fare telnet dal router, pur lasciando un account
non privilegiato per diagnostica: la connessione inoltre dovra` essere
possibile solo da alcuni host prestabiliti (ad es.: dalla rete interna
e dal router del
PoP). | |
Attacchi di tipo Denial of Service (DoS)
Gli attacchi di tipo DoS hanno come scopo di rendere inutilizzabile un servizio o una risorsa, eventualmente per sostituirsi ad essa e trarne un illecito vantaggio.
La tipologia di questi
attacchi spazia dall'impedire la connessione ad un server (o a un
router) al mandare in crash lo stesso.
Vediamo i casi più
diffusi.
smurfing
Un grave disservizio verificatosi recentemente in alcuni siti GARR è stato causato dall'invio dall'esterno di pacchetti ICMP all'indirizzo di broadcast di una delle reti del sito ("broadcast storm"): lo "smurfing".
Tale tipo di attacco coinvolge solitamente tre siti: il sito di origine dell'attacco (sito O) e altri due siti "vittime", uno intermedio che "amplifica" l'attacco (sito I) ed uno terminale (sito T).
Solitamente dal sito O vengono effettuati ping sull'indirizzo di broadcast di una (o più reti) del sito I, con il campo source ip address dell'header falsificato e posto uguale a quello di un host del sito T (per maggiori dettagli: CERT CA-98.01, RFC 2267). In questo modo viene generato un flusso consistente di pacchetti ICMP dal sito I al sito T (per una stima del disservizio, si veda: "THE LATEST IN DENIAL OF SERVICE ATTACKS: "SMURFING" DESCRIPTION AND INFORMATION TO MINIMIZE EFFECTS")
Purtroppo non c'è modo per il sito T di difendersi direttamente, se non tramite una politica preventiva estesa a quanti più siti possibile tesa ad eliminare le cause (cioè ad impedire comportamenti "scorretti" dei propri utenti).
E` quindi importante impedire che la propria LAN sia origine dell'attacco o amplificatore ignaro (ed allo stesso tempo vittima) dello stesso.
Per evitare che la propria LAN agisca da sito intermedio, è necessario disabilitare la possibilità di inviare pacchetti dall'esterno sull'indirizzo di broadcast delle proprie reti nel seguente modo:
Questa operazione deve essere ripetuta su ogni router connesso alla propria LAN.
Inoltre, per evitare che la propria LAN sia origine dell'attacco o quanto meno per permettere di individuare l'origine dell'attacco, è necessario controllare che i pacchetti che escono dalla LAN abbiano nell'header come source address un indirizzo appartenente ad essa. In questo modo è almeno possibile evitare di coinvolgere siti "terzi" e risalire all'origine dell'attacco disponendo di un sistema di monitoraggio sulla LAN (si veda ad es: "Building a Network Monitoring and Analysis Capability Step by Step")
L'access-list seguente effettua il controllo richiesto (si ricordi che le access-list estese sono identificate da un numero compreso nell'intervallo 100-199 e che l'IOS CISCO effettua il controllo sequenzialmente dalla prima istruzione, fermandosi al primo match di condizione esatto che trova).
L'uso di una access-list per filtrare i pacchetti in uscita dalla propria LAN (è sufficiente l'access-list applicata come misura preventiva per lo smurfing) permette di circoscrivere eventuali attacchi verso terzi provenienti dalla propria LAN.
Attacchi UDP-TCP
sulle porte di diagnostica del router
Un altro possibile attacco, di tipo DoS, cui sono soggetti router CISCO è l'invio di un grande numero di pacchetti spuri UDP o TCP sulle porte echo, chargen, discard e daytime (quest'ultimo solo TCP). In questi casi il router, per rispondere a queste richieste, può arrivare a consumare una grande percentuale della propria CPU fino, in casi estremi, ad andare in crash (per maggiori dettagli: "White Paper: Strategies to Protect Against UDP Diagnostic Port Denial of Service Attacks").
È consigliabile disabilitare tale accesso, con le seguenti istruzioni in configurazione:
Attacco "land"
Come è noto,
è diffuso un "tool" (noto come land) che
permette l'invio ad un determinato host di pacchetti TCP SYN (inizio
di connessione), con "ip source address" e
"port" falsificati e posti uguali all'indirizzo ed
alla porta dell'host di destinazione, causando in alcuni casi anche lo
stallo del router.
Il problema è stato risolto nelle più
recenti versioni di IOS Cisco, ma negli altri casi è necessario
applicare un filtro che blocchi per ogni interfaccia la ricezione di
questi pacchetti (per maggiori dettagli: "TCP
Loopback DoS Attack (land.c) and Cisco Devices").
! impedisce
l'invio alle interfacce di pacchetti
! con ip source address
uguale a quello dell'interfaccia
!
interface ethernet 0
.....
ip address <ETH ADDRESS> <SUBNET MASK>
ip access-group 102 in
.....
!
! il filtro è inutile se
l'interfaccia è unnumbered o
! comunque se ha un indirizzo
non annunciato
!
interface serial 0
......
ip address <SERIAL
ADDRESS> <SUBNET MASK>
ip access-group 102 in
.....
!
access-list 102 deny
ip <ETH ADDRESS>
0.0.0.0
<ETH
ADDRESS> 0.0.0.0
access-list 102 deny
ip <SERIAL
ADDRESS> 0.0.0.0 <SERIAL
ADDRESS> 0.0.0.0
access-list 102 permit
ip any any
Attacchi "TCP SYN"
Un altro possibile attacco di tipo DoS è l'attacco "TCP SYN" caratterizzato dalla richiesta di un grande numero di connessioni, apparentemente da host diversi, ad un router il quale però non riceverà mai l'acknowledgment di chiusura del "TCP three-way handshake" per queste connessioni, causando quindi il riempimento della sua coda di connessione e quindi realizzando una situazione di Denial of Service (per maggiori dettagli si veda: "White Paper: Defending Strategies to Protect Against TCP SYN Port Denial of Service Attacks").
Non è possibile rintracciare l'origine dell'attacco in quanto il mittente viene falsificato, né esistono metodi semplici di difesa (non è fattibile ad esempio l'attivazione di una access-list che filtri le connessioni in ingresso, perchè tipicamente l'ip sorgente è falsificato in maniera casuale e quindi un attacco può coprire buona parte dello space-address di Internet).
Sono attuabili alcune contromisure come aumentare la dimensione della coda di connessione (SYN ACK queue) e diminuire il tempo di time-out per il "three-way handshake".
Anche in questo caso la
realizzazione dell'acces-list per filtrare i pacchetti in
uscita diminuisce la probabilità che la LAN sia utilizzata come
base per questo tipo di attacchi (è sufficiente
l'access-list applicata come misura preventiva per lo
smurfing).
Uso non autorizzato delle risorse
Protezione degli host sulla LAN
In situazioni normali è difficilmente attuabile il controllo centralizzato di tutti gli host sulla propria LAN. La misura alternativa è filtrare selettivamente sul router i servizi tendenzialmente pericolosi.
In linea di principio, la situazione ottimale è isolare su una LAN dedicata i server "esterni" ovvero quelli che devono essere visibili a tutti, permettendo l'accesso verso di essi però solo limitatamente ai servizi "ufficiali" offerti; per quanto riguarda invece le macchine utente, dovrebbe essere bloccato tutto il traffico diretto verso le porte "pericolose" (dalle quali comunque di norma non dovrebbero essere offerti servizi).
Nella seguente tabella
sono riportati i servizi da filtrare o bloccare.
|
|
|
|
|
|
|
|
|
|
|
DoS |
|
|
|
|
|
informativo |
|
|
|
|
|
|
|
|
|
|
|
informativo |
|
|
|
|
|
|
|
|
|
|
|
DoS |
|
|
|
|
|
|
|
|
|
|
|
inutile |
|
|
|
|
|
|
|
|
|
|
|
Usato principalmente per zone transfer |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
obsoleto |
|
|
|
|
|
informativo |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
obsoleto |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
informativo |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Mail Spamming
Come esempio significativo di uso illecito delle risorse (soprattutto della rete) esaminiamo il "mail spamming", ovvero l'uso di mailer SMTP da parte di utenti non autorizzati per ottenere l'invio di decine di migliaia di messaggi di e-mail, di solito contenenti messaggi pubblicitari non richiesti dai destinatari (detti UCE: Unsolicited Commercial E-mails).
Per prevenire questo fenomeno, in linea di principio, è sufficiente configurare correttamente gli host di una LAN eliminando (selettivamente) la possibilità di utilizzarli come mail relay dall'esterno (per maggiori dettagli: sendmail organization )
In realtà però, come abbiamo notato precedentemente, è necessario filtrare il servizio smtp dall'esterno verso tutti gli host ritenuti non "affidabili" (cioè non controllati direttamente dai reponsabili del sito), lasciando pieno accesso smtp solo verso i mail server "ufficiali".
Viene riportato di seguito
un esempio di access-list che realizza questo filtro.
!
impedisce
le connessioni smtp dall'esterno verso host non autorizzati
! (nell'esempio
si suppone che la connessione verso l'esterno avvenga
! tramite
l'interfaccia serial 0)
!
interface
serial 0
......
ip access-group 103 in
.....
!
! definizione
access-list (nell'esempio
RETE è una
rete di "classe C")
!
access-list 103 permit tcp any host <MAIL SERVER
1>
access-list 103 permit tcp any host <MAIL SERVER
2>
access-list 103 deny tcp any <RETE>
0.0.0.255 eq smtp log
access-list 103 permit ip any any
Si noti che una simile configurazione non impedisce alle macchine interne di parlare SMTP tra di loro nè di trasmettere direttamente posta elettronica a tutto il mondo esterno: impedisce solamente al mondo esterno di accedere direttamente alla porta SMTP delle macchine non autorizzate (per maggiori dettagli si veda, ad es.: "Installazione e configurazione di Berkeley sendmail su piattaforma Unix").
Un problema che rimane comunque aperto è lo spamming con il metodo del "doppio non delivery". In questo caso lo "spammer", per aggirare le protezioni sul mail-relay, invia il mail ad un utente inesistente in un dato dominio con il campo From falsificato e posto uguale al "bersaglio": il sistema di mail del dominio ricevente accetta l'e-mail (è diretto ad utente del proprio dominio) ma poi constata che l'utente è inesistente e quindi lo rispedisce al mittente (a quello che crede essere il mittente...).
Purtoppo non c'è
modo di difendersi se non segnalando il fatto ai gestori dell'ISP dal
quale avvengono queste connessioni ed eventualmente filtrare la
connessione smtp dalle reti in questione (eliminando quindi anche i
mail "legittimi"); d'altra parte questo tipo di
"mail-spamming" è assolutamente inefficiente dal
punto di vista dello spammer (deve mandare un mail per ogni
"vittima").
Bibliografia