In mancanza di un firewall di qualche tipo, la rete aziendale rimane ben aperta all'accesso da parte di chiunque sia collegato alla stessa rete pubblica. Il packet filtering è uno dei metodi più comuni per creare un firewall TCP/IP. Questa tecnica permette di controllare il movimento dei pacchetti IP in funzione dei loro contenuti.

Linee guida per rendere sicuro il server

Il packet filtering filtra i pacchetti IP sulla base di un insieme di regole che viene definito in corrispondenza di un router o di un altro dispositivo per l'inoltro dei pacchetti, per esempio un server Windows NT. Si possono implementare delle regole di packet filtering per una combinazione tra indirizzo host, protocollo, applicazione, direzione della connessione e tipo di messaggio. Gli aspetti specifici dell'implementazione delle regole del packet filtering dipendono dal particolare tipo di dispositivi che viene utilizzato e da loro produttore.

Per capire il funzionamento del packet filtering è necessario comprendere le relazioni che intercorrono tra i vari strati del protocollo TCP/IP. È inoltre necessario sapere in che modo il packet filtering si pone in relazione in modo specifico con vari protocolli TCP/IP e seguire alcune linee guida per filtrare i pacchetti IP.

Lo stack del protocollo TCP/IP

La figura 1 mostra i tre strati dello stack del protocollo TCP/IP che sono coinvolti nel packet filtering. L'intero stack TCP/IP è composto da quattro strati.

I protocolli per l'accesso alla rete definiscono l'infrastruttura di rete sulla quale avviene la comunicazione TCP/IP. I protocolli nello strato Network Access comprendono tutte le tecnologie e tipologie di rete implementate, come i collegamenti point-to-point dial-up e dedicati, ADSL (Asymmetric Digital Subscriber Line), ATM (Asynchronous Transfer Mode), frame relay e tutte le LAN. La figura 1 non comprende lo strato Network Access, dal momento che quest'ultimo non è rilevante per l'analisi del packet filtering.

Lo strato Internet equivale grossolanamente a quello OSI (Open Systems Interconnection) Network ed è responsabile soprattutto del routing. Il protocollo IP viene usato per la comunicazione device-to-device, per esempio nelle comunicazioni host-to-router e router-to-router. Le regole di packet filtering si applicano tipicamente al protocollo IP e ai protocolli usati nei datagrammi IP.

Lo strato Transport equivale grossolanamente a quello OSI Transport ed è responsabile delle comunicazioni host-to-host. I protocolli di comunicazione relativi a questo strato sono il TCP (Transport Control Protocol) e l'UDP (User Datagram Protocol), che forniscono rispettivamente un servizio orientato alla connessione (circuito virtuale) e connectionless (datagramma). Il pacchetto IP porta un segmento TCP o un datagramma UDP (come indica la figura 1 e come verrà spiegato più avanti, anche alcuni protocolli di strato non-Transport inseriscono i propri dati direttamente nei pacchetti IP).

Lo strato Application definisce i protocolli user application di livello più elevato, come l'HTTP (HyperText Transport Protocol) per il Web, oppure quelli SMTP (Simple Mail Transfer Protocol) o POP (Post Office Protocol) per la posta elettronica. Ogni protocollo application è associato a uno o entrambi i protocolli dello strato Transport.

Packet filtering e protocollo IP

Tutto il packet filtering TCP/IP inizia con un pacchetto IP. Tre campi dei pacchetti IP sono fondamentali per il filtering. L'indirizzo sorgente è l'indirizzo IP a 32 bit dell'host che ha inviato il pacchetto e ha generato le informazioni contenute in quest'ultimo. L'indirizzo di destinazione è l'indirizzo IP a 32 bit dell'host di destinazione previsto, che dovrebbe ricevere il pacchetto e le informazioni in esso contenute. Il PID (Protocol IDentifier) è l'identificatore delle informazioni di protocollo portate dal pacchetto IP. Il packet filtering si può basare su uno oppure su tutti questi campi. Usando l'indirizzo sorgente o quello di destinazione, è per esempio possibile bloccare tutti i pacchetti provenienti da un indirizzo o un insieme di indirizzi, oppure instradare verso un insieme di indirizzi i pacchetti che si ha deciso di lasciar entrare.

Il campo PID è particolarmente interessante. Se un pacchetto IP porta direttamente i dati per molti protocolli, tra cui:

* ICMP (Internet Control Message Protocol) - una parte essenziale del protocollo IP, che porta errori correlati a quest'ultimo e messaggi informazionali (PID=1).

* TCP - comunicazione host-to-host affidabile e orientata alla connessione (PID=6).

* UDP - comunicazione host-to-host non affidabile e connectionless (PID=17).

* GRE (Generic Routing Encapsulation) - protocollo incapsulato comunemente usato nelle VPN (Virtual Private Network) (PID=47).

* IP ESP (Encapsulating Security Payload) - parte della suite di protocolli IPSec (Internet Protocol Security) che fornisce la crittografia dei dati e l'autenticazione della loro origine ( PID=50).

* IP AH (Authentication Header) - parte del protocollo IPSec che autentica l'origine dei dati del pacchetto (PID=51).

* OSPF (Open Shortest Path First) - principale protocollo di routing per il routing interno delle reti IP (PID=89).

All'indirizzo http://www.isi.edu/in-notes/iana/assignments/protocol-numbers, la IANA (Internet Assigned Numbers Authority) mantiene un elenco di tutti i numeri di protocollo. È necessario sapere quali protocolli devono essere filtrati presso il proprio sito e quali vengono supportati dal dispositivo di packet filtering. Alcuni filtri consentono di implementare un filtering basato soltanto su protocolli di livello più elevato già noti al software del filtro; altri permettano invece di specificare l'identificatore PID e quindi di ottenere un filtro basato su protocolli nuovi oppure non noti.

Packet filtering e protocolli TCP/UDP

Se vengono filtrati i pacchetti basati su un'applicazione che usa il protocollo TCP o UDP, è necessario avere una buona familiarità con le porte. Sulle reti IP, sono quattro i parametri che identificano in modo univoco le comunicazioni host-to-host attraverso il protocollo TCP o UDP: indirizzo IP della sorgente, numero di porta della sorgente, indirizzo IP della destinazione e numero di porta della destinazione.

Il numero di porta identifica l'applicazione eseguita sul protocollo TCP o UDP. I numeri di porta compresi tra 0 e 1023 vengono chiamati "porte ben note" e sono assegnati al lato server dell'applicazione. Nella maggior parte dei sistemi, le porte ben note possono essere usate soltanto dai processi caratterizzati da un livello elevato di privilegi (per esempio, radice, amministratore).

I numeri di porta compresi tra 1024 e 49151 vengono invece chiamati "porte registrate" e, per maggiore comodità della comunità Internet, sono definiti pubblicamente in modo da evitare conflitti a livello dei vari produttori. Le porte registrate possono essere usate dalle applicazioni server e client.

La IANA chiama "porte dinamiche e/o private" i rimanenti numeri di porta, nell'intervallo da 49152 a 65535. Qualsiasi client o server può usare liberamente le porte dinamiche. La tabella 1 elenca alcuni numeri di porta comuni e i protocolli che sono solitamente ad essi associati.

Controllando i numeri di porta che vengono consentiti dal filtro dei pacchetti, si può controllare a quali applicazioni e servizi esterni possono accedere gli utenti interni e a quali applicazioni e servizi interni possono accedere gli utenti esterni. La IANA mantiene un elenco dei numeri di porta TCP/UDP presso il sito http://www.isi.edu/in-notes/iana/assignments/port-numbers.

Un altro fattore da prendere in considerazione quando si devono impostare le regole per il filtro dei pacchetti relativamente al protocollo TCP è costituito dalla direzione della connessione. Gli host TCP devono instaurare una connessione virtuale prima di poter scambiare i dati. Il processo di setup della connessione usa un handshake a tre vie; è chiamato in questo modo poiché setup richiede lo scambio di tre segmenti TCP per sincronizzare i numeri di ricevuta e sequenza dei due host. Il client inizializza di solito una connessione con il server, ma ci sono alcune importanti eccezioni. Per esempio, anche se il client FTP inizializza una connessione TCP FTP-control con un server FTP, quest'ultimo inizializza la connessione FTP-data con il client.

La figura 2 mostra uno scenario in cui un server NT funge da router, inoltrando i pacchetti tra un sito utente e un ISP (Internet Service Provider). In questo contesto, con il termine "in arrivo" si fa riferimento ai pacchetti che entrano nella rete dall'esterno, mentre con "in partenza" ci si riferisce ai pacchetti che lasciano la rete diretti all'esterno. Quando si configura il filtro dei pacchetti, è possibile limitare non soltanto le applicazioni ma anche la direzione della connessione. In conseguenza, si possono per esempio limitare le connessioni in arrivo garantendo allo stesso tempo che gli utenti interni siano in grado di instaurare delle connessioni TCP con server situati all'esterno.

Linee guida del packet filtering per i protocolli TCP, UDP e IP

È opportuno impostare le proprie politiche e regole di packet filtering sulla base di due linee guida. Per prima cosa, bisogna fare in modo che il software di packet filtering blocchi tutto quello che non viene esplicitamente consentito. Secondariamente, i filtri dei pacchetti devono essere configurati in modo da proteggere il sito non soltanto nei confronti di un attacco proveniente da un agente esterno, ma anche in modo da bloccare tutti i pacchetti in partenza che potrebbero venire usati da un agente per sferrare un attacco nei confronti di un altro sito. Se tutti i siti adottassero questo approccio, Internet sarebbe senz'altro molto più sicura. Ulteriori strategie per filtrare i pacchetti IP e le applicazioni TCP/UDP sono quelle elencate a seguire.

Bloccare tutti i pacchetti IP in arrivo il cui campo dell'indirizzo sorgente contiene il proprio identificatore di rete (NET_ID). Questi pacchetti dovrebbero avere origine soltanto all'interno della propria rete; se uno di questi pacchetti ha origine in una rete esterna, significa che qualcuno sta cercando di falsificare gli indirizzi. Bloccare inoltre tutti i pacchetti IP in partenza il cui campo dell'indirizzo sorgente non contiene il proprio identificatore NET_ID. La presenza di questi pacchetti indica che qualcuno all'interno della rete aziendale sta tentando di falsificare gli indirizzi nei confronti di un'altra rete. Bisogna bloccare anche tutti i pacchetti IP in arrivo e in partenza il cui campo dell'indirizzo di destinazione contiene un indirizzo broadcast (per esempio, un identificatore host il cui valore sia composto soltanto da 1 o 255 - come 208.162.187.255).

Il documento RFC (Request for Comments) 1918 della IETF (Internet Engineering Task Force), disponibile all'indirizzo http://www.ietf.org/rfc/rfc1918.txt, definisce i seguenti indirizzi IP che possono essere usati su una rete privata ma non instradati su Internet: 10.0.0.0, da 172.16.0.0 a 172.31.0.0 e da 192.168.0.0 a 192.168.255.0. Bloccare tutti i pacchetti IP in arrivo e in partenza il cui campo dell'indirizzo di destinazione o sorgente contiene un indirizzo compreso in questi intervalli oppure l'indirizzo di loopback IP (NET_ID 127.0.0.0).

Consentire i pacchetti in arrivo diretti a un servizio di rete come quelli HTTP, FTP, SMTP, POP o NNTP (Network News Transfer Protocol), soltanto per collegarsi a un server pubblico che supporta quel servizio. Per esempio, a un segmento TCP in arrivo con un numero di porta di destinazione pari a 80 (HTTP), consentire soltanto di comunicare con il proprio server Web. Questa pratica impedisce agli utenti esterni di connettersi a un server "illegale" che sia stato inserito nella rete da un utente interno.

Il sistema DNS (Domain Name System) richiede un'attenzione particolare. Le tipiche query DNS vengono eseguite sul protocollo UDP; i trasferimenti di zona DNS (il trasferimento di un intero file dati DNS) usano invece il protocollo TCP. Impostare il firewall in modo da consentire i trasferimenti di zona DNS soltanto tra i propri server DNS primari e secondari. Questa procedura è una precauzione standard nei confronti degli attacchi che inviano per prima cosa delle informazioni DNS fasulle al server DNS secondario, poi seguono con un attacco di tipo Denial of Service in grado di mettere fuori gioco il server DNS primario.

Packet filtering e protocollo ICMP

Anche se il protocollo ICMP (Internet Control Message Protocol) costituisce una parte integrante di quello IP, si tratta in ogni caso di un protocollo indipendente e i suoi messaggi vengono filtrati separatamente dai pacchetti IP. Il ruolo del protocollo ICMP è quello di notificare gli errori o altre informazioni a un host IP. Molti attacchi fanno uso dei messaggi ICMP, come il Ping of Death (messaggi ping giganteschi che mandano i buffer in overflow), Smurf (che usa i messaggi ping e l'indirizzo broadcast IP per intasare il collegamento Internet della vittima) e gli attacchi ICMP Redirect (inviare messaggi fasulli che ridirigono altrove il traffico diretto a un sito affidabile). Sebbene tutti i messaggi ICMP siano utili (ma non necessariamente essenziali) per l'attività della rete, gli attaccanti possono anche abusare di quasi tutti questi messaggi. I seguenti suggerimenti possono risultare particolarmente utili per filtrare i messaggi ICMP.

Attivare Echo ed Echo Reply soltanto se si deve supportare ping (cosa che non accade in molti siti). Ping espone la rete a potenziali attacchi Smurf; il blocco dello spoofing degli indirizzi IP e l'uso dell'indirizzo broadcast (come descritto in precedenza) aiuta tuttavia a impedire gli attacchi Smurf. Anche l'implementazione Windows di traceroute (ovvero tracert) usa i messaggi Echo ed Echo Reply.

Consentire i messaggi Destination Unreachable e Network Unreachable in arrivo e in partenza, e consentire i messaggi Port Unreachable in arrivo. I messaggi Port Unreachable in partenza creano maggiori problemi; se questa opzione viene attivata, un eventuale attaccante potrebbe usare la scansione delle porte UDP contro la rete. La disattivazione dei messaggi Port Unreachable in partenza implica tuttavia il fatto che le connessioni client in entrata verso una porta non valida vadano in timeout invece di venire immediatamente chiuse. Anche se riteniamo preferibile bloccare questa opzione, bisogna comunque essere consapevoli di quale sia il prezzo da pagare, in modo da poter prendere la decisione giusta. Probabilmente è necessario consentire i messaggi Source Quench in arrivo e in partenza (che vengono usati per il controllo di flusso). Bisogna tuttavia riconoscere che gli utenti mal disposti potrebbero anche abusare di questi messaggi nel quadro di alcuni attacchi. È quindi necessario bloccare i messaggi Redirect, Router Advertisement e Router Selection. Consentire Timestamp e Timestamp Reply, ma tenere conto del fatto che un attaccante sofisticato potrebbe essere in grado di usare i messaggi ping o timestamp per prevedere il valore dei contatori quasi-casuali, come quelli che determinano il numero di sequenza iniziale delle connessioni TCP. Se un attaccante riesce a indovinare il numero di sequenza iniziale, la rete diventa suscettibile nei confronti di vari tipi di attacchi con spoofing IP.

Probabilmente è opportuno consentire i messaggi Time Exceeded (verificando la scadenza della vita o del reassembly timer dei pacchetti) e Parameter Problem in arrivo e in partenza. È necessario attivare i messaggi Traceroute soltanto se si desidera consentire il funzionamento dei comandi traceroute degli utenti esterni.

È necessario essere consapevoli del fatto che il protocollo ICMP definisce dei tipi e sottotipi dei messaggi. Il messaggio ICMP type 3, per esempio, è Destination Unreachable. Questo tipo di messaggio è caratterizzato da vari sottotipi, che vengono specificati da un codice: code=0 è Network Unreachable; code=1 è Host Unreachable; code=3 è Port Unreachable. Verificare che il filtro dei pacchetti offra la granularità necessaria per implementare le politiche di sicurezza del sito. L'elenco dei messaggi ICMP della IANA è disponibile all'indirizzo http://www.isi.edu/in-notes/iana/assignments/icmp-parameters.

Il packet filtering nel mondo reale

Il packet filtering può venire implementato in un router, in un server per l'inoltro dei pacchetti, oppure in un firewall. I router, come quelli prodotti da Cisco Systems, Bay Networks e Ascend, sono caratterizzati da propri sistemi operativi e proprie interfacce a linea di comando. Uno svantaggio del packet filtering è costituito dal fatto che è difficile creare correttamente un insieme di regole; inoltre, la sintassi arcana del router esaspera questa difficoltà. Un server per l'inoltro dei pacchetti, come una macchina NT Server che esegue il servizio RRAS (Routing and Remote Access Service), oppure un firewall come FireWall-1 di Check Point Software Technologies, offre un'interfaccia GUI (Graphical User Interface) per configurare il insieme di regole di packet filtering, cosa che semplifica di molto il lavoro.

Ovviamente, il packet filtering non è l'unico modo per proteggere una rete locale. Un altro approccio può essere quello di utilizzare un server proxy. I server proxy non filtrano i pacchetti di per sé; quando un server locale cerca di collegarsi a un server esterno, viene creata una connessione con il server proxy che a sua volta si connette al server esterno. Un'attività simile ha luogo quando un utente esterno si collega a un server interno. La maggior parte dei server proxy viene avvantaggiata dall'uso con il packet filtering.

Il packet filtering è un potente strumento di sicurezza. Per creare un insieme di regole valido e funzionante per il filtraggio dei pacchetti bisogna in ogni caso capire la suite di protocolli TCP/IP e il modo in cui i singoli protocolli operano e interagiscono.

Il Packet Filtering è usato nei personal firewall

Con l'avvento delle tecnologie XDsl, ci si è trovati ad affrontare in maniera rapida delle problematiche legate alla protezione di configurazioni SOHO. Trattandosi fondamentalmente di connessione ad IP fisso o quantomeno incluso in un range predefinito, infatti, si sta notando l'incremento degli attacchi su questo tipo di macchine, in quanto esse sono potenzialmente più rintracciabili.

Quanto sopra, inoltre, rappresenta un presupposto alle ulteriori potenziali vulnerabilità. Partendo da questi presupposti sono molti i vendor che hanno sviluppato una serie di Personal Firewall che si propongono proprio di effettuare questo tipo di protezione. Questi sono basati principalmente su Packet Filtering, con ulteriori feature correlate alla gestione di determinate funzioni di content control.

Recentemente sono stati segnalati una serie di problemi relativi ad alcuni personal firewall, tra cui segnaliamo quello recentemente occorso a BID (BlackICE Defender). Si tratta, per esempio, di una serie di problematiche correlate alla gestione dei vari livelli di "security level": Trusting, Cautious, Nervous, e Paranoid. Questi livelli sono gestiti dal punto di vista del front end, da un'interfaccia grafica. I problemi che sono stati segnalati sono relativi a cattive impostazioni del progetto e alla circolazione nella rete di copie contenenti Trojan che sarebbero distribuite da falsi mall.

Le critiche che vengono mosse sono, inoltre, relative alla mancanza di controllo interno delle applicazioni. Questo significa che non vengono effettuate controlli al di qua del firewall ( cioè sulla parte interna) ma solo a livello perimetrale puro. E ancora sembra che questo prodotto non abbia una documentazione sufficiente, ne sarebbe conseguenza una leggerezza nella configurazione, con potenziali falle nella sicurezza. Conclude questa Black List una serie di problemi relativi ai bug correlati alle nuove versioni di BID che andrebbero al malfunzionamento del personal firewall in occasione di nuove installazioni di software susseguenti al setup del firewall stesso. Inoltre questi malfunzionamenti del firewall non si manifesterebbero palesemente, bensì determinerebbero soltanto l'inefficacia delle politiche di sicurezza impostate. In pratica il firewall lavorerebbe male e in maniera del tutto "trasparente" all'utente finale.


Gli autori

Gary C. Kessler è senior network
security analyst presso SymQuest Group, una società di consulenza sull'integrazione di rete che ha sede a South Burlington nel Vermont. È possibile contattarlo all'indirizzo di posta elettronica gkessler@symquest.com.

Dario Forte, si occupa di information security nella PA. Pubblica i suoi
articoli in tutto il mondo e tiene corsi e conferenze internazionali su Windows NT e UNIX security management,
anche per DUKE Italia. Può essere contattato all'indirizzo di posta elettronica dario.forte@acm.org.

Rik J. Dayvie è technical services coordinator presso Hill Associates, una società di training e formazione nelle telecomunicazioni che ha sede a Colchester nel Vermont. È possibile contattarlo all'indirizzo di posta elettronica r.dayvie@hill.com.

Craig T. Martin è un componente dello staff tecnico di Hill Associates. È possibile contattarlo all'indirizzo di posta elettronica c.martin@hill.com.


FIGURA 1:
Stack abbreviato del protocollo TCP/IP.

FIGURA 2:
Uno scenario con NT Server quale router.

TABELLA 1:
Numeri di porta comuni e protocolli associati.


Numero di porta Protocollo Applicazione
20 TCP FTP data
21 TCP FTP control
23 TCP Telnet
25 TCP SMTP
37 UDP Time
43 TCP NICNAME/whois
53 TCP/UDP DNS
69 UDP Trivial File Transfer Protocol (TFTP)
79 TCP Finger
80 TCP HTTP
110 TCP POP3
119 TCP NNTP
123 UDP Network Time Protocol (NTP)
137 TCP/UDP NetBIOS Name Service
138 UDP NetBIOS Datagram Service
139 TCP NetBIOS Session Service
143 TCP Internet Message Access Protocol (IMAP)
161 UDP SNMP
162 UDP SNMP trap
179 TCP Border gateway protocol (BGP)
443 TCP HTTP over Secure Sockets Layer (HTTPS)
520 UDP Routing Information Protocol (RIP)
1080 TCP SOCKS
33434 UDP Invalid port that traceroute uses

Copyright (c) 2000-3000 by Ing. Eduardo Palena - Napolifirewall.com