Firewall, netfilter, iptables

Firewall, netfilter, iptables Masetti Marco (marcomas@libero.it) v0.1, 01 Luglio 2000 Questo documento descrive come impostare un firewall usando Linux e in particolare il nuovo kernel 2.4 Introduzione

Durante il mio tirocinio presso un internet service provider ho avuto l'occasione di approfondire la conoscenza di Linux, sistema operativo che si sta ritagliando uno spazio sempre maggiore nel panorama informatico.

In particolare ho avuto la possibilità di utilizzare le versioni in sviluppo del nuovo kernel 2.4 (2.3) e di conoscere più da vicino il progetto Netfilter, il quale ha come obiettivo la realizzazione di una nuova infrastruttura adatta per la realizzazione di firewall evoluti con possibilità di NAT (Network Address Translation), manipolamento dei pacchetti, ...

Durante lo studio ho raccolto e ricercato varia documentazione, informazioni, notizie utili che mi sono poi servite per realizzare questo documento per utilizzo personale.

Quando ho poi deciso di realizzare la mia homepage ho pensato di metterlo a disposizione di chi ne avesse bisogno, con la speranza che possa essere in qualche modo di aiuto.

Chi dovesse poi trovare imprecisioni, errori (clamorosi?) o avesse voglia di inviarmi dei commenti è naturalmente invitato a scrivermi.

Liberatoria

L'autore non si assume alcuna responsabilità, esplicita o implicita, riguardante questo documento. Il documento deve essere visto come un'introduzione alle modalità di funzionamento del firewall in ambiente Linux. Non sono, e non pretendo di esserlo, un esperto sulla sicurezza.

Firewall Introduzione

Un firewall in genere è composto da uno o più computer che si pongono tra le reti private e quelle esterne (es. internet) con il preciso scopo di controllare ciò che transita da una rete verso l'altra.

In particolare sono utilizzati per stabilire a quali servizi (www, ftp, mail,...) presenti nella rete internet è possibile accedere dalla rete locale, e quali possonono essere resi disponibili alle reti esterne.

La necessità di questi controlli è dovuta al fatto che i sistemi operativi (Windows, Mac, Linux, ...), i protocolli utilizzati per lo scambio dei dati tra le reti (TCP/IP), i programmi hanno una serie di limiti, errori di programmazione che possono esporre la propria rete a diversi attacchi.

Questi attacchi possono permettere ad una persona con le giuste informazioni e con particolari programmi (exploit) di individuare eventuali vulnerabilità e di accedere e modificare una macchina. L'intruso potrebbe quindi apportare delle modifiche che gli consentano di accedere in qualsiasi momento senza essere scoperto (backdoor), oppure di sfruttarla per sottrarre informazioni (progetti confidenziali, password, ...), per coinvolgerla in attacchi DoS (Denial of Service), DDoS (Distribuited Denial of Service) ...

Le soluzioni adottate per proteggere le reti, viste anche le diversità dei sistemi, sono varie. L'ICSA, ente che certifica l'affidabilità di un prodotto firewall, ha individuato tre tipologie di firewall:

packet filtering application gateway packet inspection

packet filtering Questa probabilmente è la soluzione più semplice e consiste nel controllare ogni pacchetto che transita da una rete all'altra. I pacchetti contengono una serie di informazioni (indirizzo sorgente, indirizzo destinazione, porta sorgente, porta destinazione ...) che possono essere utilizzate per stabilire se il pacchetto può essere accettato e quindi lasciato proseguire oppure no e quindi rifiutato. Questo tipo di firewall non provvede a richiedere e a controllare login e password, quindi ad identificare l'utente che richiede una connessione, l'unico dato disponibile è l'indirizzo sorgente contenuto nell'intestazione del pacchetto. application gateway In questo caso un'applicazione detta proxy si occupa di analizzare, autorizzare e inoltrare i pacchetti che transitano. L'autenticazione deve avvenire in modo sicuro e protetto, basato in genere su account e password cifrate. Sono molto diffuse e considerate ottimali le soluzioni che impiegano come firewall una macchina proxy che effettua anche il filtraggio dei pacchetti (packet filtering). packet inspection In questo caso oltre al filtraggio, comunque essenziale, si aggiungono ulteriori controlli che riguardano anche le altre informazioni sempre contenute nei pacchetti.

Per valutare l'affidabilità della propria piattaforma (computer, sistema operativo, protocollo di rete) è possibile consultare il sito del (Computer Emergency Response Team) e per ottenere varie informazioni il sito dell'.

Norme generali di sicurezza

Ottenere un sistema sicuro e protetto da un qualsiasi attacco è molto difficile, sono molte infatti le variabili che entrano in gioco, è comunque possibile adottare vari accorgimenti per cercare di proteggere al meglio la propria rete.

In genere il punto di partenza per limitare queste vulnerabilità è quello di essere minimalisti, ossia configurare la propria macchina/firewall in modo che abbia lo stretto indispensabile, e di seguire i seguenti accorgimenti:

Aggiornare e compilare il kernel abilitando le voci sulla sicurezza I kernel minori della versione 2.2.16 sono vulnerabili al TCP root exploit, le versioni minori alla 2.2.11 hanno un bug riguardante IPCHAINS e la frammentazione, aggiornare alle ultime versioni stabili del kernel risolve questi e altri problemi. Quando si compila il kernel è raccomandabile selezionare, se possibile, le voci IP: syn cookies, IP: always defragment. Permettono di risolvere alcuni problemi noti riguardanti la sicurezza. Installare i programmi strettamente necessari I programmi in genere sono molto complessi e quindi è inevitabile che ci possano essere degli errori di programmazione (BUG). Questi errori possono essere usati per accedere alle macchine quindi è indispensabile installare possibilmente solo i programmi strettamente necessari e in ogni caso consultare spesso il sito della propria distribuzione Linux per aggiornarli alle ultime versioni, soprattutto se sono stati riscontrati problemi riguardanti la sicurezza. Nota: aggiornare in casi di bachi noti è importante, se l'aggiornamento riguarda solo aggiunta di nuove funzionalità allora è meglio fare attenzione, in quanto potrebbero contenere a loro volta nuovi bug. Abilitare solo quei servizi (telnet, ftp, finger ...) di cui si ha realmente bisogno Linux permette di offrire tutta una serie di servizi agli utenti: ftp, mail, web. Per ottenere un elenco dei servizi attivi nella propria Linux box è possibile utilizzare il seguente comando:

# netstat --inet -a -p Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 *:ftp *:* LISTEN 324/inetd tcp 0 0 *:telnet *:* LISTEN 324/inetd ...

Se sulla propria macchina ad esempio risulta attivo un server ftp e non si ha intenzione di permettere agli utenti di accedervi per effettuare upload/download di file allora è meglio disabilitare il servizio. A questo scopo basta modificare con un editor di testo il file /etc/inetd.conf e aggiungere un '#' all'inizio della riga:

ftp stream tcp nowait root /usr/sbin/tcpd in.ftpd -l -a

Quindi riavviare il processo inetd per rendere attiva la modifica.

Nota: questa modifica non preclude la possibilità di effettuare ftp da questa macchina verso altre, ma solo l'inverso, ossia l'accesso di altre macchine alla propria.

Utilizzare password cifrate (shadow, MD5) e scelte con criterio E' indispensabile scegliere password che non siano facilmente decifrabili, ossia brevi, appartenenti al dizionario o di uso comune. E' inoltre molto importante cambiarle con una certa frequenza. Rimuovere hardware non necessario Questo è un caso "paranoico" ma spesso anche hardware e driver non necessari possono essere sfruttati per degli attacchi. Controllare quali programmi possono essere pericolosi Con il comando:

# find / -type f -perm +6000 -exec ls -l {} \; ... -rwsr-xr-x 1 root root 35892 Dec 8 1999 /usr/bin/chage -rwsr-xr-x 1 root root 37960 Dec 8 1999 /usr/bin/gpasswd -rwxr-sr-x 1 root tty 8580 Dec 21 1999 /usr/bin/write -rwsr-xr-x 1 root root 22904 Oct 25 1999 /usr/bin/crontab ...

si ottiene una lista dei programmi che hanno particolare privilegi (root). Questi programmi potrebbero contenere dei bug che un intruso potrebbe sfruttare per acquisirne i privilegi e quindi arrecare danni al sistema. Se questi programmi sono indispensabili aggiornali con frequenza, in particolare se sono stati scoperti bachi riguardanti la sicurezza, o se inutili è possibile in molti casi anche eliminarli.

Controllare il file /var/log/messages e verificare eventuali stranezze Se si utilizza il filtraggio dei pacchetti (con ipchains o iptables) è possibile impostare delle regole per "registrare" eventuali pacchetti anomali. Controllando queste informazioni è possibile stabilire se ci sono state intrusioni o tentativi di accesso. Usare software che verifichi l'integrità dei file (Tripwire) Se qualcuno riesce ad accedere ad una macchina potrebbe essere in grado di sostituire un programma o daemon con un "troiano" ossia un file che svolge le stesse funzioni ma che in più permette ad esempio di prelevare dei dati (es. password) dalla macchina della vittima e di inviarli all'intruso. Tripwire è un noto programma che controlla e verifica l'integrità dei file. Se la propria distribuzione utilizza i pacchetti rpm è possibile verificarne l'integrità utilizzando: rpm --verify -a > /tmp/rpm-verify.txt. Se in rpm-verify.txt in una o più linee compare un 5 allora il file associato è stato modificato. In questi casi è meglio controllare se queste modifiche sono proprie, altrimenti qualcuno potrebbe essere penetrato nel sistema. Nota: è sempre meglio fare attenzione ai programmi che si installano in particolare se prelevati da siti internet, floppy, zip di dubbia provenienza. Utilizzare ssh (secure shell) Servizi come ad esempio telnet sono insicuri in quanto la trasmissione dei dati avviene in "chiaro", compresi username e password. Quindi qualcuno, utilizzando uno "sniffer", potrebbe essere in grado di leggerle e utilizzarle a proprio vantaggio. ssh provvede a risolvere il problema cifrando le connessioni garantendo così maggior sicurezza. Consultare i siti dedicati alla sicurezza e alla scoperta di errori o buchi per la sicurezza Esistono diversi siti che si occupano di segnalare tempestivamente problemi, bachi presenti nei programmi o nei sistemi operativi e le relative precauzioni o soluzioni per risolverli. Tra i più noti , .

Netfilter Descrizione

Netfilter è un'infrastruttura presente nel kernel, realizzata nel 1998 da Rusty Russell e Michael Neuling, che consente di scrivere dei moduli appositi per gestire il filtraggio, il manipolamento dei pacchetti, il NAT (Network Address Translation) e di caricarli quando necessario con il comando insmod o modprobe.

E' possibile compilarli e integrarli nel kernel, creare nuovi moduli, aggiungere nuove funzionalità a quelle esistenti e perfino utilizzare i tool ipfwadm e ipchains, utilizzati rispettivamente con le versioni 2.0 e 2.2 del kernel, presenti anch'essi come moduli per garantire compatibilità con il passato. Naturalmente ipfwadm e ipchains non saranno supportati ancora a lungo, a partire dal 2004 il tool ufficiale sarà iptables, già disponibile, ma ancora in fase di sviluppo.

Differenze rispetto alle versioni 2.0 e 2.2 del kernel

Le prime novità riguardano la gestione del passaggio dei pacchetti attraverso il sistema di filtraggio. Nei kernel 2.0 e 2.2 il pacchetto in arrivo è sottoposto innanzi tutto alle regole della catena INPUT (prima del routing) quindi successivamente, se destinato alla rete locale, alla catena forward e poi output, se destinato invece al firewall è inviato ai processi locali. I pacchetti in uscita dal firewall invece sono sottoposti alla sola catena output.

__ +-------+ +-------+ +---------+ +---------+ __ |__| --->| input | ---> |Routing| ---> | forward | ---> | output | ---> |__| +-------+ +-------+ +---------+ +---------+^ | ^ | | V | +------ processi locali ------+

L'impostazione classica del firewall prevede quindi di inserire le regole di filtraggio nella catena input e di usare eventualmente la catena forward per il mascheramento.

Nel prossimo kernel 2.4, a differenza della versione 2.2, quando un pacchetto arriva dalla rete viene innanzi tutto sottoposto al codice di routing e quindi se destinato o proveniente dalla rete locale e diretto all'esterno, è sottoposto esclusivamente alle regole della catena FORWARD. Alla catena INPUT sono destinati tutti i pacchetti diretti esclusivamente al firewall. Mentre i pacchetti che sono sottoposti alle regole della catena OUTPUT sono solo quelli generati esclusivamente dal firewall e in uscita.

__ +-------+ +---------+ __ |__| ---> |Routing| ---> | FORWARD | -->.-----> |__| +-------+ +---------+ ^ | | | | V | +-------+ +--------+ | INPUT | | OUTPUT | +-------+ +--------+ | ^ V | +---- processi locali ----+

Questa modifica permette di avere maggior efficienza, ogni pacchetto è sottoposto alle regole di una SOLA catena (INPUT o FORWARD o OUTPUT), e semplicità di utilizzo. E' possibile utilizzare la catena INPUT per filtrare i pacchetti diretti al firewall, la catena OUTPUT per filtrare i pacchetti creati dal firewall e in uscita, la catena FORWARD per filtrare i pacchetti che transitano attraverso il firewall diretti o provenienti dalla rete locale.

Kernel

Per poter utilizzare correttamente Netfilter e iptables è necessario compilare il kernel selezionando le seguenti voci:

Networking options ---> ... [*] Network packet filtering (replaces ipchains) [CONFIG_NETFILTER] [ ] Network packet filtering debugging [CONFIG_NETFILTER_DEBUG] ... IP: Netfilter Configuration ---> Connection tracking (required for masq/NAT) [CONFIG_IP_NF_CONNTRACK] FTP protocol support [CONFIG_IP_NF_FTP] Userspace queueing via NETLINK (EXPERIMENTAL) (NEW) [CONFIG_IP_NF_QUEUE] Iptables support (required for filtering/masq/NAT) [CONFIG_IP_NF_IPTABLES] limit match support [CONFIG_IP_NF_MATCH_LIMIT] MAC address match support [CONFIG_IP_NF_MATCH_MAC] netfilter MARK match support [CONFIG_IP_NF_MATCH_MARK] Multiple port match support [CONFIG_IP_NF_MATCH_MULTIPORT] TOS match support [CONFIG_IP_NF_MATCH_TOS] Connection state match support [CONFIG_IP_NF_MATCH_STATE] Packet filtering [CONFIG_IP_NF_FILTER] REJECT target support [CONFIG_IP_NF_TARGET_REJECT] MIRROR target support (EXPERIMENTAL) [CONFIG_IP_NF_TARGET_MIRROR] Full NAT [CONFIG_IP_NF_NAT] MASQUERADE target support [CONFIG_IP_NF_TARGET_MASQUERADE] REDIRECT target support [CONFIG_IP_NF_TARGET_REDIRECT] Packet mangling [CONFIG_IP_NF_MANGLE] TOS target support [CONFIG_IP_NF_TARGET_TOS] MARK target support [CONFIG_IP_NF_TARGET_MARK] LOG target support [CONFIG_IP_NF_TARGET_LOG]

Le voci relative a "IP: Netfilter Configuration" sono state tutte impostate come moduli (M), ma possono essere selezionate anche in modo da essere incluse direttamente nel kernel (*), o non essere proprio selezionate (sconsigliato). E' inoltre possibile includere solo una parte nel kernel e il resto compilarli come moduli, appena necessari potranno essere caricati con i comandi modprobe o insmod.

Descrizione

Networking options ---> [*] Network packet filtering (replaces ipchains) Selezionare questa voce se si desidera che la Linux box possa operare come firewall, e quindi filtrare, mascherare, manipolare i pacchetti usando l'infrastruttura netfilter e il nuovo programma iptables, sostituto di ipchains nel kernel 2.4. Networking options ---> [ ] Network packet filtering debugging Selezionare questa voce nel caso si debba effettuare il debug del codice di netfilter e si vogliano maggiori informazioni. IP: Netfilter Configuration ---> Menu principale per la selezione dei moduli. Connection tracking (required for masq/NAT) Il connection tracking tiene traccia delle connessioni stabilite in modo da riconoscere quali pacchetti ne fanno parte e quali no. Richiesto per il mascheramento (masquerading) e altre forme di NAT (Network Address Translation). Può essere utilizzato anche per supportare il filtraggio dei pacchetti. FTP protocol support Selezionare questa voce se la macchina effettua il masquerading o altra forma di NAT, e se si intende usare FTP. FTP causa alcuni problemi con il connection tracking quindi è necessario includere questo modulo per risolverli. Userspace queueing via NETLINK (EXPERIMENTAL) (NEW) Netfilter è in grado di accodare e passare i pacchetti allo userspace. Il dispositivo netlink può poi essere utilizzato per accedere a questi dati. Iptables support (required for filtering/masq/NAT) Selezionare questa voce per filtrare i pacchetti e/o per effettuare il NAT, utilizzando il nuovo tool iptables. limit match support Selezionare questa voce per poter limitare il numero di confronti. Utile se usato in combinazione con il modulo LOG per limitare la registrazione dei messaggi e per aggirare alcuni attacchi DoS (Denial of Service). MAC address match support Selezionare questa voce se si vogliono confrontare i pacchetti in base all'indirizzo ethernet associato. netfilter MARK match support Selezionare questa voce se si vogliono confrontare i pacchetti in base al valore 'nfmark'. Questo valore può essere impostato attraverso il target MARK (vedere iptables). Multiple port match support Selezionare questa voce se si vogliono confrontare i pacchetti TCP o UDP in base ad una serie di porte sorgenti o destinazione. Nota che normalmente una regola può confrontare solo un singolo intervallo di porte. TOS match support Selezionare questa voce se si vogliono confrontare i pacchetti in base ai campi TOS (Type Of Service) dei pacchetti IP. Connection state match support Selezionare questa voce se si vogliono confrontare i pacchetti in base all'appartenenza o meno ad una connessione tracciata (pacchetti precedenti). Se si decide di includere questo modulo nel kernel tutte le connessioni saranno automaticamente tracciate. Unclean match support (EXPERIMENTAL) Selezionare questa voce se si vogliono confrontare i pacchetti in base ad una serie di campi delle intestazioni IP, TCP, UDP, ICMP, utile per verificare la validità dei pacchetti. Owner match support (EXPERIMENTAL) Selezionare questa voce se si vogliono confrontare i pacchetti generati localmente in base a chi li ha creati: utente, gruppo, processo, sessione. Packet filtering Definisce una tabella 'filter', in cui è possibile inserire le regole per il filtraggio dei pacchetti. REJECT target support Selezionare questa voce se si vuole utilizzare il target REJECT, che permette di inviare un pacchetto ICMP error in risposta. MIRROR target support (EXPERIMENTAL) Selezionare questa voce se si vuole permettere ad una regola di rispedire indietro un pacchetto ricevuto. Full NAT Selezionare questa voce se si vuole implementare il masquerading, il port forwarding o altre forme di NAT (Network Address Translation). Queste forme di NAT si possono impostare utilizzando iptables e l'opzione '-t nat'. MASQUERADE target support Selezionare questa voce se si desidera utilizzare questa forma specializzata di mascheramento, implementata specificatamente per supportare i collegamenti PPP dialup. REDIRECT target support Selezionare questa voce se si desidera utilizzare il proxy trasparente, un'altra forma di NAT. Packet mangling Selezionare questa voce se si vogliono manipolare i pacchetti, ossia modificare i campi delle intestazioni. TOS target support Selezionare questa voce se si vogliono creare delle regole nella tabella 'mangle' che possano alterare i bit TOS (Type Of Service) dei pacchetti. MARK target support Selezionare questa voce per aggiungere un target 'MARK' che permetta di creare nella tabella 'mangle' delle regole che siano in grado di alterare il campo nfmark associato ai pacchetti. Utile per cambiare l'instradamento (routing) dei pacchetti. Utilizzato in particolare per lo shaping, controllo del traffico. LOG target support Selezionare questa voce per aggiungere un target 'LOG' che permetta di creare delle regole che registrino le intestazioni dei pacchetti.

Se si decide di includere queste voci come moduli, e quindi di non includerle direttamente nel kernel, allora nella directory /lib/modules/2.x.xx/ipv4/ dovrebbero essere presenti tutti i seguenti moduli o quasi dato che alcuni sono ancora sperimentali:

ip_conntrack.o ip_conntrack_ftp.o ip_nat_ftp.o ip_queue.o ip_tables.o ipt_LOG.o ipt_MARK.o ipt_MASQUERADE.o ipt_MIRROR.o ipt_REDIRECT.o ipt_REJECT.o ipt_TOS.o ipt_limit.o ipt_mac.o ipt_mark.o ipt_multiport.o ipt_owner.o ipt_state.o ipt_tos.o ipt_unclean.o iptable_filter.o iptable_mangle.o iptable_nat.o

iptables Introduzione

La seconda novità riguarda il tool designato per impostare le regole di filtraggio che è ora iptables. Questo programma sostituisce ipchains, che comunque sarà ancora supportato, e si integra e adegua alle novità introdotte con l'infrastruttura Netfilter (tabelle, moduli, ...).

Differenze rispetto alle versioni 2.0 e 2.2 del kernel

La caratteristica principale introdotta è la modularità, in passato con ipchains si impostavano tutte le regole riguardanti non solo il filtraggio ma anche il mascheramento, i bit TOS (Type of Service), il log dei pacchetti rendendo difficile lo sviluppo e l'impostazioni delle regole.

Ora invece è possibile caricare solo i moduli che si intendono utilizzare e in qualsiasi momento. Si potranno inoltre aggiungerne di nuovi sviluppati ad esempio per svolgere compiti precisi, ciò amplia le possibilità e facilita l'introduzione di nuove caratteristiche ed opzioni.

Tabelle

Con Netfilter, per migliorare e facilitare le impostazioni delle regole, sono state introdotte le seguenti tre tabelle che si possono gestire e impostare correttamente solo con iptables:

filter nat mangle

filter Tabella contenente inizialmente le tre catene preesistenti INPUT, FORWARD e OUTPUT. Tutte le regole riguardanti il filtraggio dovranno essere inserite in questa tabella. nat Tutte le regole riguardanti masquerading, redirezione, port forwarding, proxy trasparente che ora sono raggruppate sotto il termine NAT (Network Address Translation) dovranno essere inserite all'interno di questa tabella che contiene le seguenti catene PREROUTING, POSTROUTING e OUTPUT. mangle In quest'ultima tabella invece si dovranno inserire le regole riguardanti il "manipolamento" dei pacchetti (bit TOS, marcamento dei pacchetti, ...). Le catene disponibili sono: PREROUTING e OUTPUT.

Queste tabelle possono essere richiamate con l'opzione '-t' (es. '-t nat'). Non è necessario specificare la tabella filter con '-t filter' in quanto è quella di default.

Criteri per il filtraggio

I criteri per il filtraggio sono aumentati rispetto ad ipchains e si può ora filtrare in base a:

interfaccia indirizzo sorgente e destinazione numero di porta indirizzo MAC protocollo IP flag dei pacchetti opzioni tcp

interfaccia E' possibile filtrare i pacchetti in base all'interfaccia di ingresso (-i) e di uscita (-o). Rispetto ad ipchains ora l'opzione '-i' serve per specificare esclusivamente l'interfaccia di ingresso, per quella di uscita è necessario utilizzare l'opzione '-o'. indirizzo sorgente e destinazione Come in ipchains è possibile filtrare i pacchetti in base all'indirizzo sorgente e/o quello di destinazione. numero di porta Anche in questo caso nulla di nuovo rispetto ad ipchains tranne per il fatto che ora è necessario indicare la porta (numero o nome) specificando esplicitamente l'opzione --sport o --dport. indirizzo MAC E' possibile filtrare anche in base all'indirizzo fisico di un'interfaccia ethernet. protocollo IP E' possibile indicare nelle proprie regole il tipo di protocollo: TCP, UDP, ICMP. flag dei pacchetti I pacchetti che transitano hanno dei flag (SYN, RST, FIN, ...) che possono essere utilizzate nelle regole di filtraggio. Particolarmente interessante è il flag SYN utilizzato per richiedere una connessione. opzioni tcp E' possibile filtrare i pacchetti tcp anche in base alle opzioni presenti.

Obiettivi

Per quanto riguarda gli obiettivi (target) ora sono disponibili:

ACCEPT DROP REJECT QUEUE RETURN MIRROR LOG SNAT, DNAT, MASQUERADE

ACCEPT E' utilizzata in una regola per accettare i pacchetti che la soddisfano, può essere usata inoltre anche come tattica (policy) di una catena. DROP Sostituisce DENY presente in ipchains e come scopo ha sempre quello di scartare il pacchetto che soddisfa la regola. Anche questo obiettivo può essere utilizzato come tattica. REJECT Stessa funzione di DROP con la differenza che viene inviato un pacchetto di errore ('port unreachable') all'altra macchina. QUEUE Utilizzato per accodare i pacchetti per elaborazioni userspace. RETURN Se la catena in cui si trova la regola con l'obiettivo RETURN è stata definita dall'utente allora la RETURN causa il ritorno alla catena precedente, altrimenti se la catena è predefinita (INPUT, OUTPUT, ...) viene eseguita la tattica. MIRROR Questo obiettivo è utilizzato per rispedire un pacchetto alla macchina che lo ha inviato. LOG Questo obiettivo permette di registrare i pacchetti che soddisfano la regola, consente inoltre di specificare diverse opzioni per migliorare la gestione e la leggibilità. Sostituisce e completa l'opzione '-l' utilizzata con ipchains. SNAT, DNAT, MASQUERADE Questi obiettivi sostituiscono e completano l'obiettivo MASQ presente in ipchains. Vedi capitolo sul NAT (Network Address Translation).

Per indicare questi obiettivi come per ipchains è necessario utilizzare il comando '-j' (es. -j ACCEPT).

Varie

Le operazioni classiche sono rimaste invariate rispetto ad ipchains, ci sono comunque le seguenti differenze: I nomi delle catene create con -N devono essere in minuscolo per distinguerle da quelle predefinite (INPUT, FORWARD, OUTPUT), da scrivere sempre in maiuscolo. Es. iptables -N logdrop. Non esiste più la policy DENY è stata sostituita con DROP. La lunghezza dei nomi delle catene ora può essere di max. 30 caratteri, con ipchains il limite massimo è di 8 caratteri. L'opzione -i serve a specificare esclusivamente l'interfaccia di input, -o l'interfaccia di output. Le porte UDP e TCP devono essere specificate utilizzando --sport (--source-port) o --dport (--destination-port) a seconda dei casi. Il flag -y ora deve essere indicato usando --syn e deve seguire '-p tcp'. L'opzione -C per i test non è stata ancora implementata. Il target MASQ e le opzioni '--masquerade' e '--set' non esistono più, vedere NAT. Per impostare il port forwarding, il proxy trasparente è necessario utilizzare la tabella NAT e l'obiettivo DNAT. Per impostare i bit TOS (Type Of Service) vedere tabella mangle e TOS. Non è più possibile specificare -l per loggare i messaggi, esiste un modulo separato (LOG) che si occupa ora della registrazione. L'opzione '-b' ('--bidirectional') non è più disponibile.

Compilare e installare iptables

iptables è disponibile in formato bz2 al seguente indirizzo . Sono disponibili anche i formati rpm e deb, ma è necessario visitare il sito della propria distribuzione Linux.

Una volta completato il download è necessario assicurarsi di avere nella directory /usr/src/linux/ gli include del kernel e poi impartire i seguenti comandi:

# bzip2 -d iptables-1.1.0.tar.bz2 # tar -xvf iptables-1.1.0.tar # cd iptables-1.1.0 # make # make install

Se si ottengono dei messaggi di errore o se si vuole solo cambiare la directory in cui saranno collocati i comandi leggere il file di testo INSTALL.

Se iptables sembra non funzionare correttamente controllare di aver eseguito il comando 'make install' e di aver caricato con insmod o modprobe tutti i moduli necessari (iptable_filter.o, ...).

Aggiornare iptables

iptables è ancora in fase di sviluppo, quindi periodicamente sono rilasciate delle patch che risolvono alcuni errori riguardanti iptables stesso, gli altri moduli e la documentazione.

L'ultima versione disponibile di iptables al momento è la 1.1.0, la documentazione invece è alla versione 1.0.1. Per aggiornare è sufficiente eseguire le seguenti operazioni:

1. Accedere al server CVS di SAMBA come utente 'anonymous': cvs -d :pserver:cvs@cvs.samba.org:/cvsroot login 2. Quando è richiesta la password digitare 'cvs' 3. Verificare il codice utilizzato: cvs -d :pserver:cvs@cvs.samba.org:/cvsroot co netfilter 4. Per effettuare l'aggiornamento vero e proprio utilizzare il seguente comando: cvs update -d -P

Si possono consultare le patch, la documentazione aggiornata, una lista TODO delle cose ancora da implementare, utilizzando anche il web, è sufficiente visitare l'indirizzo .

Documentazione, mailing list

E' possibile consultare le complete manpage con il comando:

# man iptables

Sono comunque disponibili le "Rusty's Unreliable Guides", quattro documenti completi che introducono ai concetti di rete, al filtraggio dei pacchetti, al mascheramento e alla realizzazione dei moduli di estensione.

Networking Concepts HOWTO Linux 2.4 Packet filtering HOWTO Linux 2.4 NAT HOWTO Linux netfilter hacking HOWTO

I suddetti documenti si trovano in vari formati (SGML, TXT, PS) al seguente indirizzo: .

Sempre a questo indirizzo si trovano due link alle mailing list ufficiali di netfilter.

Filtraggio

Il filtraggio sotto Linux 2.4 si basa come nelle versioni precedenti sui concetti di catene (chain), obiettivi (target), tattiche (policy).

Inizialmente sono disponibili tre catene predefinite: INPUT, FORWARD, OUTPUT (tabella filter).

INPUT Tutti i pacchetti destinati esclusivamente alla macchina firewall saranno sottoposti alle regole contenute nella catena INPUT.

+--+ |PC|--+ ==> +---+ <===== +--+ |_____| |_______ INTERNET +--+ | +---+ |PC|--+ +--+ LAN FIREWALL

FORWARD Tutti i pacchetti destinati non alla macchina firewall ma ad una delle macchine della rete locale o provenienti dalla rete locale e diretti verso l'esterno (non al firewall) saranno sottoposti alle regole della catena FORWARD.

+--+ |PC|--+ <== +---+ <===== +--+ |_____| |_______ INTERNET +--+ | +---+ |PC|--+ ==> =====> +--+ LAN FIREWALL

OUTPUT Tutti i pacchetti generati dalla macchina firewall e in uscita saranno sottoposti alle regole della catena OUTPUT.

+--+ |PC|--+ <== +---+ ===> +--+ |_____| |_______ INTERNET +--+ | +---+ |PC|--+ +--+ LAN FIREWALL

Ciascuna catena consiste di una tattica (policy), e di una o più regole che stabiliscono quali pacchetti sono accettati e quali no.

Una regola si compone in genere di una serie di caratteristiche che servono ad individuare un pacchetto e da un obiettivo (target) che indica cosa fare del pacchetto se la regola è soddisfatta. L'obiettivo può corrispondere ad ACCEPT (pacchetto accettato), DROP (pacchetto scartato), REJECT (pacchetto rifiutato).

Una catena si può rappresentare in questo modo (qui prendiamo ad esempio la catena INPUT):

INPUT +--------------+ | | Regola 1 | | ---------------- | | Regola 2 | | ---------------- V | Regola 3 | ---------------- Tattica

Tutti i pacchetti che arrivano dalla rete e destinati al firewall saranno sottoposti, in questo caso, a ciascuna regola contenuta nella catena INPUT in ordine. Se la Regola 1 non è soddisfatta si prosegue con la successiva, se una regola (es. Regola 2) è soddisfatta allora il pacchetto è accettato, scartato o rifiutato (questa informazione è contenuta nella regola). Se nessuna regola è soddisfatta allora si applica la tattica (policy), che non dice altro a sua volta se accettare, scartare o rifiutare.

I pacchetti che viaggiano nella rete contengono un insieme di informazione molto utili come ad esempio indirizzo sorgente (indirizzo di chi ha inviato il pacchetto), indirizzo destinazione (indirizzo a cui il pacchetto è destinato), tipo di pacchetto (TCP, UDP, ICMP), porta sorgente e porta destinazione (FTP, TELNET, WWW, ...), ...

Queste informazioni sono usate nelle regole per stabilire quali pacchetti sono da accettare e quali da scartare. Ad esempio se non si desidera che qualcuno dall'esterno possa effettuare un telnet su una macchina della LAN è necessario creare una regola nella tabella filter, catena FORWARD, che filtri, rifiuti i pacchetti destinati alla rete locale, aventi come porta destinazione la porta telnet.

iptables -A FORWARD -p tcp -i eth0 -o eth1 --dport telnet -j DROP ^^^^^^^^^^ ^^^^^^ ^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^ ^^^^^^^ | | | | | | | | | +- se la regola è soddisfatta | | | | scarta (DROP) il pacchetto | | | +- porta dest. del pacchetto (telnet) | | +---- interfacce ingresso e uscita del pacchetto | + protocollo tcp + aggiungi regola alla catena FORWARD

Con questa nuova versione come abbiamo visto il tool incaricato di impostare le regole di filtraggio nel kernel è iptables, anche se è ancora possibile usare ipfwadm e ipchains.

Questo modulo si occupa di fornire le operazioni di base per la creazione, gestione delle catene e delle regole.

Operazioni sulle catene

Segue un elenco delle operazioni che permettono di creare, modificare, cancellare le catene:

Crea una nuova catena (-N) ipchains: ipchains -N nuova (max. 8 caratteri) iptables: iptables -N nuova (max. 30 caratteri) Cancella una catena vuota, senza regole (-X) ipchains: ipchains -X nuova iptables: iptables -X nuova Cambia la tattica (policy) delle catene predefinite (-P) ipchains: ipchains -P input DENY iptables: iptables -P INPUT DROP Mostra elenco delle regole di una catena (-L) ipchains: ipchains -L iptables: iptables -L Svuota una catena di tutte le sue regole (-F) ipchains: ipchains -F output iptables: iptables -F OUTPUT Azzera i contatori (pacchetti e byte) di tutte le regole di una catena (-Z) ipchains: ipchains -Z input iptables: iptables -Z INPUT

NOTA 1: se non si specifica una catena con le opzioni '-L','-X','-F','-Z' si intenderanno tutte le catene. Esempio:

# Rimuovi tutte le regole della catena INPUT iptables -F INPUT # Rimuovi tutte le regole presenti in TUTTE le catene iptables -F

NOTA 2: l'opzione -L può essere utilizzata inoltre per visualizzare tutte le catene o una sola (se si desiderano anche i numeri di linea utilizzare l'opzione '--line-numbers'):

# iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination DROP tcp -- anywhere anywhere tcp dpt:telnet Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination # iptables -L INPUT Chain INPUT (policy ACCEPT) target prot opt source destination DROP tcp -- anywhere anywhere tcp dpt:telnet # iptables --line-numbers -L INPUT Chain INPUT (policy DROP) num target prot opt source destination 1 DROP tcp -- anywhere anywhere tcp dpt:telnet

E' inoltre possibile visualizzare informazioni sul numero dei pacchetti sottoposti alle regole con l'opzione '-v' (o '--verbose') oppure ottenere contemporaneamente un elenco delle regole e l'azzeramento dei contatori:

# iptables -v -L Chain INPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 2 120 DROP tcp -- any any anywhere anywhere tcp dpt:telnet Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination # iptables -v -L -Z Chain INPUT (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 2 120 DROP tcp -- any any anywhere anywhere tcp dpt:telnet Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 2 packets, 120 bytes) pkts bytes target prot opt in out source destination Zeroing chain `INPUT' Zeroing chain `FORWARD' Zeroing chain `OUTPUT'

Operazioni sulle regole

Segue un elenco delle operazioni che permettono di inserire, cancellare, modificare le regole delle catene:

Appendi una nuova regola alla catena (-A) ipchains: ipchains -A input -p tcp --dport telnet -j REJECT iptables: iptables -A INPUT -p tcp --dport telnet -j REJECT Inserisci una nuova regola alla catena (-I) # Inserisci una regola all'inizio della catena ipchains: ipchains -I input -p tcp --dport telnet -j REJECT iptables: iptables -I INPUT -p tcp --dport telnet -j REJECT Sostituisci una regola presente in una determinata posizione (-R) # Sostituisci la seconda regola con la nuova ipchains: ipchains -R input 2 -p icmp --icmp-type ping -j DENY iptables: iptables -R INPUT 2 -p icmp --icmp-type ping -j DROP Cancella una regola presente in una determinata posizione (-D) # Cancella la precedente regola (vedi -R) ipchains: ipchains -D input -p icmp --icmp-type ping -j DENY iptables: iptables -D INPUT -p icmp --icmp-type ping -j DROP # Cancella la terza regola della catena input ipchains: ipchains -D input 3 iptables: iptables -D INPUT 3

Operazioni di selezione

Segue una lista delle opzioni che consentono di realizzare delle regole per filtrare i pacchetti:

interfaccia ('-i' e '-o' oppure '--in-interface' e '--out-interface') ipchains: ipchains -A forward -i eth0 -d $RETE_LOCALE -p icmp -j REJECT iptables: iptables -A FORWARD -i eth0 -o eth1 -p icmp -j REJECT NOTA: con ipchains si utilizzava l'opzione -i che in base all'obiettivo (input, output) indicava rispettivamente interfaccia di ingresso e interfaccia di uscita, per la catena forward indicava sempre e solo l'interfaccia di uscita. Si possono inoltre indicare tutte le interfacce di un certo tipo aggiungendo un '+' (es. ppp+). Per indicare tutte le interfacce NON uguali ad una certa interfaccia, ad esempio a ppp0, si può aggiungere un '!' prima del nome dell'interfaccia. '!' si legge "non uguale a " es.: iptables -A FORWARD -i ! ppp0 -j ACCEPT USO: -i, --in-interface [!] [name][+] -o, --out-interface [!] [name][+] Indirizzo sorgente e/o destinazione ('-s' e '-o' oppure '--source' e '--destination') ipchains: ipchains -A input -s $RETE_LOCALE -d $RETE_ESTERNA -p icmp -j ACCEPT iptables: iptables -A INPUT -s $RETE_LOCALE -d $RETE_ESTERNA -p icmp -j ACCEPT USO: -s, --source [!] address[/mask] -d, --destination [!] address[/mask] Protocollo tcp ('-p tcp' o '--protocol tcp') ipchains: ipchains -A input -p tcp -j ACCEPT iptables: iptables -A INPUT -p tcp -j ACCEPT NOTA: è possibile specificare inoltre le opzioni '--tcp-flags', '--tcp-option', e '--syn' oltre a '--sport' e '--dport'. USO: -p, --protocol [!] protocol Porta sorgente e/o destinazione ('--sport' e '--dport' oppure '--source-port' e '--destination-port') ipchains: ipchains -A forward -p tcp -d 192.168.x.x telnet -j ACCEPT iptables: iptables -A FORWARD -p tcp -d 192.168.x.x --dport telnet -j ACCEPT NOTA: è possibile specificare anche un intervallo di porte (es. 21(ftp),22(ssh),23(telnet)). es. iptables -A INPUT -p tcp --dport ftp:telnet -j ACCEPT USO: --source-port [!] [port[:port]] --destination-port [!] [port[:port]] flags tcp ('--tcp-flags') ipchains: non possibile iptables: iptables -A INPUT -p tcp --tcp-flags ALL SYN,ACK -j DROP NOTA: i flag sono SYN,ACK,FIN,RST,URG,PSH. La prima stringa è la maschera (flag che vuoi esaminare), la seconda indica quali dovrebbero risultare impostati. USO: --tcp-flags [!] mask comp opzioni tcp ('--tcp-option') ipchains: non possibile iptables: iptables -A INPUT -p tcp --tcp-option 1 -j DROP USO: --tcp-option [!] number Pacchetti richiesta connessione ('--syn') ipchains: ipchains -A input -p tcp -y -j DENY iptables: iptables -A INPUT -p tcp --syn -j DROP NOTA: '--syn' si può utilizzare solo con il protocollo tcp, ed è molto utile per impedire i tentativi di connessione verso il firewall o la propria rete locale. USO: [!] --syn Protocollo udp ('-p udp' o '--protocol udp') ipchains: ipchains -A input -p udp -j ACCEPT iptables: iptables -A INPUT -p udp -j ACCEPT NOTA: è possibile specificare inoltre le opzioni '--sport', '--dport'. USO: -p, --protocol [!] protocol --source-port [!] [port[:port]] --destination-port [!] [port[:port]] Protocollo icmp ('-p icmp' o '--protocol icmp') ipchains: ipchains -A input -p icmp -j ACCEPT iptables: iptables -A INPUT -p icmp -j ACCEPT NOTA: è possibile specificare inoltre l'opzione '--icmp-type' per indicare il tipo ICMP (es. '--icmp-type destination-unreachable', '--icmp-type 3', '--icmp-type 3/3'). Per una lista completa utilizzare 'iptables -p icmp -h'. USO: -p, --protocol [!] protocol --icmp-type [!] typename

Estensioni

Oltre alle opzioni appena viste ci sono altre opzioni molto utili, disponibili come estensioni:

mac ('-m mac' o '--match mac') limit ('-m limit' o '--match limit') owner ('-m owner' o '--match owner') state ('-m state' o '--match state') multiport ('-m multiport' o '--match multiport') unclean ('-m unclean' o '--match unclean')

Vedere i capitoli corrispondenti per una completa descrizione.

NAT

insmod ipt_nat

Descrizione

Questo modulo permette di sfruttare le nuove funzionalità introdotte sotto il termine NAT (Network Address Translation). Precedentemente con ipchains si utilizzava l'obiettivo '-j MASQ', ora questo non è più possibile in quanto è stato sostituito con i seguenti obiettivi:

MASQUERADE specifico per il caso di connessioni dialup (PPP). SNAT (Source NAT) permette di alterare nei pacchetti l'indirizzo sorgente, il mascheramento è una forma specializzata di SNAT.

Per quanto riguarda invece il port-forwarding è necessario utilizzare:

DNAT (Destination NAT) consente di alterare nei pacchetti l'indirizzo destinazione, ciò permette di implementare oltre al port-forwarding anche il proxy trasparente, il load-balancing, ...

Operazioni

Prima di poter utilizzare una qualsiasi delle operazioni seguenti è necessario specificare l'opzione '-t nat', questa causa il caricamento del modulo ed è necessario ogni qual volta si vogliano effettuare operazioni di SNAT, DNAT, MASQUERADING. es. iptables -A PREROUTING -t nat ...

La tabella nat contiene tre catene predefinite:

PREROUTING da utilizzare per il DNAT POSTROUTING da utilizzare per il SNAT OUTPUT da utilizzare per il DNAT sui pacchetti generati localmente.

Queste catene sono disposte così:

Il filtraggio e il NAT sono distinti e in genere non è necessario preoccuparsi. DNAT è effettuato prima del routing e prima che i pacchetti siano filtrati. SNAT è effettuato dopo il routing e dopo che i pacchetti sono stati filtrati.

SNAT (Source NAT)

SNAT permette di modificare il campo sorgente del pacchetto. Questo avviene in POSTROUTING ossia subito dopo la fase di routing, poco prima che il pacchetto sia inviato nella rete.

Questa operazione è utilizzata principalmente per il mascheramento della connessione, e in particolare è specifica per indirizzi statici. In caso di indirizzi dinamici, connessioni dialup utilizzare MASQUERADE.

Sono richieste le seguenti informazioni: tabella ('-t nat'), catena ('-A POSTROUTING'), obiettivo ('-j SNAT'), indirizzo sorgente che andrà a sostituire quello presente nel pacchetto ('--to' o '--to-source').

L'utilizzo dell'opzione '--to/--to-source' è il seguente:

--to-source ipaddr[-ipaddr][:port-port]

E' possibile anche specificare più di un indirizzo sorgente. Quindi se si desidera che ai pacchetti siano assegnati come indirizzo sorgente uno tra due o più indirizzi (es. 1.2.3.0 e 1.2.3.1) si può utilizzare:

iptables -t nat -A POSTROUTING -o eth1 -j SNAT --to 1.2.3.0 --to 1.2.3.1

Si può inoltre specificare un'intervallo di indirizzi:

iptables -t nat -A POSTROUTING -o eth1 -j SNAT --to 1.2.3.0-1.2.3.5

E anche una o un'intervallo di porte (è necessario specificare il protocollo tcp/udp):

iptables -t nat -A POSTROUTING -p tcp --dport telnet -o eth1 -j SNAT --to 1.2.3.5:23

# -------------------------------------------------------------------------------- # Con il seguente comando indichiamo al kernel che a tutti i pacchetti in uscita # dall'interfaccia eth0 (-o eth0) deve sostituire l'indirizzo sorgente con quello # del firewall (es. 151.99.xxx.x). # -------------------------------------------------------------------------------- iptables -t nat -A POSTROUTING -o eth1 -j SNAT --to 151.99.xxx.x

MASQUERADE

MASQUERADE è una forma di SNAT creata appositamente per gestire i collegamenti dialup (PPP). E' raccomandato utilizzare l'obiettivo MASQUERADE solo se l'indirizzo IP viene assegnato dinamicamente ad esempio da un provider. Se si possiede invece un indirizzo statico è necessario utilizzare l'obiettivo SNAT.

Diversamente dal SNAT, se la linea dovesse interrompersi, i dati transitati e le connessioni saranno dimenticate, ciò è necessario per evitare problemi nel momento in cui ci si riconnetterà nuovamente al provider.

NOTA: in questo caso il provider ci fornirà un nuovo indirizzo IP.

Sono richieste le seguenti informazioni: tabella ('-t nat'), catena ('-A POSTROUTING'), interfaccia da cui usciranno i pacchetti ('-o ppp0'), obiettivo ('-j MASQUERADE'). Non è necessario specificare l'indirizzo sorgente, sarà utilizzato quello dell'interfaccia da cui usciranno i pacchetti.

E' inoltre possibile specificare una o un'intervallo di porte (è necessario specificare anche il protocollo tcp/udp):

--to-ports [-] Port (range) to map to.

Segue un esempio di come mascherare tutti i pacchetti in uscita dall'interfaccia ppp0 con l'indirizzo assegnato ad esempio dal provider.

# Carica il modulo NAT modprobe iptable_nat iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE

DNAT (Destination NAT)

DNAT permette di modificare il campo destinazione del pacchetto. Questo avviene in fase di PREROUTING ossia subito prima della fase di routing, appena il pacchetto arriva dalla rete.

Sono richieste le seguenti informazioni: tabella ('-t nat'), catena (-A PREROUTING o -A OUTPUT), obiettivo ('-j DNAT'), interfaccia di provenienza ('-i eth0'), indirizzo che andrà a sostituire quello presente nel pacchetto ('--to').

L'utilizzo dell'opzione '--to/--to-destination' è il seguente:

--to-destination ipaddr[-ipaddr][:port-port]

Esempio:

# -------------------------------------------------------------------------------- # Cambia l'indirizzo di destinazione in 192.168.0.6 # -------------------------------------------------------------------------------- iptables -t nat -A PREROUTING -i eth0 -j DNAT --to 192.168.0.6

E' possibile, come nel caso di SNAT, specificare più di un indirizzo destinazione. Se si desidera che ai pacchetti siano assegnati come indirizzo destinazione uno tra due o più indirizzi (es. 1.2.3.0 e 1.2.3.1) si può utilizzare:

iptables -t nat -A PREROUTING -i eth0 -j DNAT --to 1.2.3.0 --to 1.2.3.1

Si può inoltre specificare un'intervallo di indirizzi e ottenere il cosiddetto load-balancing primitivo:

# -------------------------------------------------------------------------------- # Tutti i pacchetti tcp destinati alla porta www e in ingresso dall'interfaccia eth0 # devono essere inviati verso le macchine 192.168.0.2 e 192.168.0.3. # -------------------------------------------------------------------------------- iptables -t nat -A PREROUTING -i eth0 -p tcp --dport www -j DNAT --to 192.168.0.2-192.168.0.3 +---+ |PC1|----+ +-- + | | Linux box +---+ | +---+<========= |MAC|----+-------|PC0|----O----- INTERNET +---+ | +---+\ | !! | \__________ eth0 +---+ | !! | +----+ |PC2|----+ !>>+-|WWW1| 192.168.0.2 +---+ !! | +----+ !! | +----+ !>>+-|WWW2| 192.168.0.3 +----+ LAN SERVERS Internet [rete locale]

E anche una o un'intervallo di porte (è necessario specificare il protocollo tcp/udp):

iptables -t nat -A PREROUTING -p tcp --dport www -i eth0 -j DNAT --to 192.168.0.5:8080 +---+ |PC1|----+ +-- + | | Linux box +---+ | +---+<========= |MAC|----+-------|PC0|----O----- INTERNET +---+ | +---+\ | !! | \__________ eth0 +---+ | !! | +---+ |PC2|----+ !>>+-|WWW| 192.168.0.5 porta 8080 +---+ | +---+ | +----+ +-|MAIL| +----+ LAN SERVERS Internet [rete locale]

Esiste anche una forma specializzata di DNAT detta Redirezione che permette di redirigire il traffico verso una determinata porta del firewall stesso utilizzando l'obiettivo REDIRECT.

E' più che altro una comodità, in quanto si può utilizzare allo stesso scopo anche il DNAT, ed è utile per implementare il proxy trasparente.

Sono richieste le seguenti informazioni: tabella ('-t nat'), catena ('-A PREROUTING'), obiettivo ('-j REDIRECT'), interfaccia di provenienza ('-i eth0'), porta che andrà a sostituire quella presente nel pacchetto ('--to-port'). Esempio:

# -------------------------------------------------------------------------------- # Invia i pacchetti diretti alla porta www verso il proxy squid che è in # ascolto sulla porta 3128 del firewall. # -------------------------------------------------------------------------------- iptables -t nat -A PREROUTING -i eth0 -p tcp --dport www -j REDIRECT --to-port 3128

+---+ pacchetto rediretto alla porta 3128 |PC1|----+ +-+ +---+ | | | | V | +---+ | +---+<========= |MAC|----+-------|PC0|----O----- INTERNET +---+ | +---+\ | \ +---+ | eth0 |PC2|----+ +---+ LAN Internet [rete locale]

Protocollo speciali (ftp, quake, irc)

In alcuni casi il NAT potrebbe non funzionare correttamente, questo a causa di alcuni protocolli "particolari" (es. ftp, irc). Questo problema è presente anche con ipchains e la soluzione consiste nel realizzare dei moduli specifici per ciascuno di essi.

Per ipchains esistono ip_masq_ftp, ip_masq_raudio, ip_masq_irc, ...

Per iptables al momento sono disponibili moduli specifici per FTP (ip_conntrack_ftp.o e ip_nat_ftp.o) e da poco per IRC, mentre altri sono in fase di realizzazione.

Connection tracking

insmod ip_conntrack Tipo: estensione (-m state) Es.: iptables -A INPUT -p tcp -m state --state ESTABLISHED,RELATED -j ACCEPT

Descrizione

Questo modulo è particolarmente interessante ed è una delle novità più importanti introdotte. Il suo ruolo è quello di tenere traccia delle connessioni stabilite e di indicare se un pacchetto appartiene o è relativo ad una di esse. Implementa quindi ciò che è comunemente definito "stateful firewall". Per connessioni si intendono impropriamente anche quelle UDP, ICMP che in realtà non prevedono un meccanismo di richiesta/conferma connessione ("three-way handshake").

Una volta caricato il modulo ip_conntrack.o appena viene stabilita una nuova connessione esso provvede a prendere nota delle informazioni più importanti (indirizzo sorgente, indirizzo destinazione, porta sorgente, porta destinazione ...) e a memorizzarle. E' in grado così per ogni pacchetto che giunge dalla rete o è generato dalla Linux box stessa di stabilire a quale delle seguenti categorie appartiene:

NEW ESTABLISHED RELATED INVALID

NEW Pacchetti che cercano di stabilire una nuova (NEW) connessione ESTABLISHED Pacchetti appartenenti ad una connessione esistente e nota. RELATED Pacchetti relativi ad una connessione esistente ma di cui non ne fanno parte, potrebbero essere pacchetti ICMP di errore o altro. INVALID Pacchetti non appartenenti a connessioni note, quindi in genere da rifiutare..

Quindi è possibile interrogare il "connection tracking" per conoscere che tipo di pacchetto è stato ricevuto (NEW,ESTABLISHED,RELATED,INVALID) e decidere l'azione da intraprendere (ACCEPT,DROP,...).

A questo scopo è necessario specificare l'opzione 'm state --state' seguita da una o più degli stati appena descritti: NEW, ESTABLISHED, RELATED, INVALID. Esempio:

# -------------------------------------------------------------------------------- # Interroghiamo il "connection tracking" e se il pacchetto appartiene ad una # connessione nota (ESTABLISHED) o è relativo (RELATED, es. ICMP error, ftp data, ...) # allora lo accettiamo (-j ACCEPT) # -------------------------------------------------------------------------------- iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT # -------------------------------------------------------------------------------- # Altrimenti lo scartiamo (-j DROP) # -------------------------------------------------------------------------------- iptables -A INPUT -j DROP

Questo tipo di implementazione consente di rendere più semplice la realizzazione di un firewall e inoltre garantisce un maggior controllo sui pacchetti UDP e ICMP. UDP infatti diversamente da TCP è connection less (senza connessione) ciò comporta l'impossibilità ad esempio di utilizzare l'opzione '--syn' e quindi di averne un completo controllo.

Naturalmente tenere traccia di tutte le connessioni, in particolare in caso di traffico notevole, può richiedere un maggior utilizzo di memoria e CPU, comunque in base a vari test condotti sembrano essere abbastanza contenuti. In caso si abbia a disposizione una banda larga e ci sia un traffico notevole da gestire la soluzione "classica", ossia che non utilizzi il connection tracking, garantisce in genere prestazioni migliori.

Se non si intende utilizzare il "connection tracking" allora è necessario non compilare il modulo ip_conntrack.o nel kernel o caricarlo con insmod, questo per evitare che tenga traccia delle connessioni inutilmente.

Il suo utilizzo è comunque obbligatorio se si intendono effettuare operazioni di NAT (masquerading, port forwarding ...) e può essere inoltre anche di aiuto per facilitare il filtraggio dei pacchetti.

In alcuni casi si ritiene che questo meccanismo possa essere vulnerabile ad alcuni attacchi tra cui quelli DoS, è sempre possibile però utilizzare delle regole di filtraggio prima di quella contenente l'opzione '-m state --state ESTABLISHED,RELATED' per migliorare la protezione. Alcuni problemi noti e perfezionamenti sono già stati realizzati e sono in fase di testing.

Opzioni

Non sono disponibili opzioni.

Esempi Esempio 1

#!/bin/bash # Esempio 1 # Supponiamo che PC1 appartenga ad una rete locale e che vogliamo renderla # più sicura e protetta. # # +---+ . # |PC1|------+ # +---+ | # | # +---..... INTERNET # +---+ | # | |------+ # +---+ | # | # . # -------------------------------------------------------------------------------- # Carichiamo i moduli necessari se non compilati nel kernel (es. ip_conntrack) # -------------------------------------------------------------------------------- modprobe ip_conntrack modprobe ipt_REJECT # -------------------------------------------------------------------------------- # Svuotiamo le catene di tutte le regole # -------------------------------------------------------------------------------- iptables -F # -------------------------------------------------------------------------------- # OUTPUT # Accettiamo tutti i pacchetti riguardanti una connessione stabilita o relativa # -------------------------------------------------------------------------------- iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT # -------------------------------------------------------------------------------- # I pacchetti di richiesta connessione o nuova connessione (NEW) accettati # sono solo quelli telnet,www, dns (tcp e udp) # Accettiamo inoltre anche i pacchetti in uscita dall'interfaccia lo # (localhost) # -------------------------------------------------------------------------------- iptables -A OUTPUT -o lo -j ACCEPT iptables -A OUTPUT -p tcp --dport telnet -m state --state NEW -j ACCEPT iptables -A OUTPUT -p tcp --dport domain -m state --state NEW -j ACCEPT iptables -A OUTPUT -p udp --dport domain -m state --state NEW -j ACCEPT iptables -A OUTPUT -p tcp --dport www -m state --state NEW -j ACCEPT # -------------------------------------------------------------------------------- # tutto il resto è rifiutato # -------------------------------------------------------------------------------- iptables -A OUTPUT -j REJECT # -------------------------------------------------------------------------------- # FORWARD # PC1 non è posto a protezione di una rete locale. # -------------------------------------------------------------------------------- iptables -A FORWARD -j DROP # -------------------------------------------------------------------------------- # INPUT - Accettiamo tutti i pacchetti che fanno parte di una connessione da # noi stabilita (ESTABLISHED) o che sono relativi (RELATED) come ad esempio # pacchetti ICMP di errore. # -------------------------------------------------------------------------------- iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT # -------------------------------------------------------------------------------- # il resto è scartato # -------------------------------------------------------------------------------- iptables -A INPUT -j DROP

Il connection tracking rende tutto molto più semplice, con ipchains sarebbe necessario utilizzare invece questo script:

Esempio 2

#!/bin/bash # Esempio 2 # Supponiamo che PC1 sia ora un vero e proprio firewall posto a protezione # della rete locale. Accettiamo in questo caso tutte le richieste provenienti # dalla rete locale. # # +---+ . # | |------+ eth0 ppp0 # +---+ | | | # | \ +---+ / # +----|PC1|----..... INTERNET # +---+ | +---+ # | |------+ # +---+ | # | # . # -------------------------------------------------------------------------------- # Carichiamo i moduli necessari se non compilati nel kernel (es. ip_conntrack, ip_conntrack_ftp) # -------------------------------------------------------------------------------- modprobe ip_conntrack modprobe ip_conntrack_ftp # ... # -------------------------------------------------------------------------------- # Svuotiamo le catene di tutte le regole # -------------------------------------------------------------------------------- iptables -F # -------------------------------------------------------------------------------- # OUTPUT - In questo caso non è di grosso interesse # Possiamo comunque filtrare ciò che è generato dal FIREWALL e in uscita # -------------------------------------------------------------------------------- # -------------------------------------------------------------------------------- # FORWARD # PC1 ora è posto a protezione di una rete locale, quindi stabiliamo quali # pacchetti possono transitare e arrivare alla rete locale e quali # provenienti dalla rete locale uscire verso internet # -------------------------------------------------------------------------------- # -------------------------------------------------------------------------------- # Tutti i pacchetti appartenenti ad una connessione nota o relativi sono accettati # -------------------------------------------------------------------------------- iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT # -------------------------------------------------------------------------------- # Qualsiasi nuova connessione (NEW) richiesta da una macchina della rete # locale verso internet, che quindi "entra" per l'interfaccia eth0, è accettata # -------------------------------------------------------------------------------- iptables -A FORWARD ! -i ppp0 -m state --state NEW -j ACCEPT # -------------------------------------------------------------------------------- # Tutto il resto è scartato # -------------------------------------------------------------------------------- iptables -A FORWARD -j DROP # -------------------------------------------------------------------------------- # INPUT # Qui stabiliamo quali pacchetti destinati esclusivamente al *firewall*, e # non alla rete locale, sono accettati. In questo esempio accettiamo solo i ping e # pacchetti provenienti dall'interfaccia lo. # -------------------------------------------------------------------------------- iptables -A INPUT -i lo -j ACCEPT iptables -A INPUT -p icmp --icmp-type ping -j ACCEPT # -------------------------------------------------------------------------------- # resto scartato # -------------------------------------------------------------------------------- iptables -A INPUT -j DROP

Esempio 3

#!/bin/bash # Esempio 3 # Supponiamo che PC1 sia ora un vero e proprio firewall posto a protezione # della rete locale. In questo caso restringiamo e accettiamo dalla rete locale # solo le richieste www, dns, telnet. Questo è solo un esempio e può essere # migliorato. # # +---+ . # | |------+ eth0 ppp0 # +---+ | | | # | \ +---+ / # +----|PC1|----..... INTERNET # +---+ | +---+ # | |------+ # +---+ | # | # . # -------------------------------------------------------------------------------- # Carichiamo i moduli necessari se non compilati nel kernel (es. ip_conntrack, ip_conntrack_ftp) # -------------------------------------------------------------------------------- modprobe ip_conntrack modprobe ip_conntrack_ftp # ... # -------------------------------------------------------------------------------- # Svuotiamo le catene di tutte le regole # -------------------------------------------------------------------------------- iptables -F # -------------------------------------------------------------------------------- # OUTPUT - In questo caso non è di grosso interesse # Possiamo comunque filtrare ciò che è generato dal FIREWALL e in uscita # -------------------------------------------------------------------------------- # -------------------------------------------------------------------------------- # FORWARD # Tutti i pacchetti che arrivano da internet (interfaccia di ingresso: ppp0) # appartenenti ad una connessione nota o relativi sono accettati # -------------------------------------------------------------------------------- iptables -A FORWARD -i ppp0 -m state --state ESTABLISHED,RELATED -j ACCEPT # -------------------------------------------------------------------------------- # Altrimenti se i pacchetti sono arrivati dall'interfaccia eth0 e quindi # dalla LAN e nuovi o di richiesta connessione (NEW) accettiamo solo # www, domain, telnet e ping. Accettiamo infine i pacchetti che appartengono # ad una connessione già stabilita (ESTABLISHED) o sono relativi. # -------------------------------------------------------------------------------- iptables -A FORWARD -i eth0 -p tcp --dport www -m state --state NEW -j ACCEPT iptables -A FORWARD -i eth0 -p tcp --dport domain -m state --state NEW -j ACCEPT iptables -A FORWARD -i eth0 -p udp --dport domain -m state --state NEW -j ACCEPT iptables -A FORWARD -i eth0 -p tcp --dport telnet -m state --state NEW -j ACCEPT iptables -A FORWARD -i eth0 -p icmp --icmp-type ping -m state --state NEW -j ACCEPT iptables -A FORWARD -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT # -------------------------------------------------------------------------------- # Tutto il resto è scartato # -------------------------------------------------------------------------------- iptables -A FORWARD -j DROP # -------------------------------------------------------------------------------- # INPUT # Qui stabiliamo quali pacchetti destinati esclusivamente al *firewall*, e # non alla rete locale, sono accettati. In questo esempio accettiamo solo i ping # sia che provengano dalla rete locale che dalla rete internet (nota che qui non # si specificano -i e -o) oltre ai pacchetti provenienti dall'interfaccia lo. # -------------------------------------------------------------------------------- iptables -A INPUT -i lo -j ACCEPT iptables -A INPUT -p icmp --icmp-type ping -j ACCEPT # -------------------------------------------------------------------------------- # resto scartato # -------------------------------------------------------------------------------- iptables -A INPUT -j DROP # //////////////////////////////////////////////////////////////////////////////// # -------------------------------------------------------------------------------- # Impartendo il comando 'iptables -L -v' si ottiene il seguente risultato: # #Chain OUTPUT (policy ACCEPT) #target prot opt source destination #[root@localhost netfilter]# iptables -L -v #Chain INPUT (policy ACCEPT 0 packets, 0 bytes) # pkts bytes target prot opt in out source destination # 0 0 ACCEPT icmp -- any any anywhere anywhere icmp echo-request # 0 0 DROP all -- any any anywhere anywhere # #Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) # pkts bytes target prot opt in out source destination # 0 0 ACCEPT all -- ppp0 any anywhere anywhere state RELATED,ESTABLISHED # 0 0 ACCEPT tcp -- eth0 any anywhere anywhere state NEW tcp dpt:www # 0 0 ACCEPT tcp -- eth0 any anywhere anywhere state NEW tcp dpt:domain # 0 0 ACCEPT udp -- eth0 any anywhere anywhere state NEW udp dpt:domain # 0 0 ACCEPT tcp -- eth0 any anywhere anywhere state NEW tcp dpt:telnet # 0 0 ACCEPT icmp -- eth0 any anywhere anywhere state NEW icmp echo-request # 0 0 ACCEPT all -- eth0 any anywhere anywhere state RELATED,ESTABLISHED # 0 0 DROP all -- any any anywhere anywhere # -------------------------------------------------------------------------------- # ////////////////////////////////////////////////////////////////////////////////

Esempio 4

In particolare nell'HOWTO Packet Filtering è presente il seguente esempio adatto per chi si connette al proprio ISP da casa via modem.

insmod ip_contrack insmod ip_contrack_ftp iptables -N block iptables -A block -m state --state ESTABLISHED, RELATED -j ACCEPT iptables -A block -m state --state NEW -i ! ppp0 -j ACCEPT iptables -A block -j DROP iptables -A INPUT -j block iptables -A FORWARD -j block

LOG

Modulo: insmod ipt_LOG Tipo: obiettivo (-j LOG) Es.: iptables -A INPUT -p icmp -j LOG --log-level info --log-prefix "ICMP: "

Descrizione

Questo modulo permette di gestire la registrazione dei pacchetti che transitano attraverso il firewall. Rispetto a ipchains che utilizza l'opzione '-l' ora si deve usare l'obiettivo '-j LOG'. Questa modifica ha consentito inoltre di introdurre due nuove opzioni che consentono di memorizzare i log in file diversi e di aggiungere una stringa di commento.

Opzioni

Sono disponibili le seguenti opzioni:

--log-level --log-prefix --log-tcp-sequence --log-tcp-options --log-ip-options

--log-level Questa opzione permette di specificare un nome di livello (debug, info, notice, warning, err, crit, alert, emerg) o il numero corrispondente (0-7). Configurando il file syslog.conf è possibile registrare le informazioni dei pacchetti in file differenti in base alle proprie esigenze, oppure direttamente sulla console. Ad esempio, con la Slackware, se si utilizza '--log-level info' o '--log-level notice' le informazioni dei pacchetti saranno memorizzate nel file /var/log/message, se si utilizza '--log-level debug' invece saranno registrate nel file /var/log/debug. Per ulteriori dettagli consultare il manuale di syslog.conf (man syslog.conf) e il file /etc/syslog.conf --log-prefix Questa opzione permette di specificare una stringa di max. 29 caratteri da inserire nel file di log (/var/log/messages) assieme al resto delle informazioni, usato per identificare rapidamente ciò che interessa. --log-tcp-sequence Registra i numeri di sequenza. Per default i numeri di sequenza (sequence number) non sono memorizzati (consigliato), se si desidera registrare queste informazioni (es. SEQ=3431266037) utilizzare '--log-tcp-sequence'. --log-tcp-options Registra le opzioni tcp, nel file si troverà una stringa simile alla seguente: OPT (020405B40000080A0004413D0000000001030300) --log-ip-options Registra le opzioni ip (flag).

Per ottenere un elenco con relativa breve spiegazione utilizzare il comando:

iptables -j LOG --help

Utilizzo

Per registrare le intestazioni dei pacchetti è necessario specificare il tipo di pacchetto, l'obiettivo LOG ('-j LOG') ed opzionalmente anche il livello ('--log-level') e la stringa che deve essere associata ('--log-prefix'). Esempio:

iptables -A INPUT -p tcp --dport telnet --syn -j LOG --log-level info \ --log-prefix "Firewall (telnet request) -->"

In questo caso i pacchetti tcp destinati alla porta telnet del firewall sono registrati nel file associato a info (vedere syslog.conf - man syslog.conf), nel caso della Slackware è /var/log/messages, e "contrassegnati" con la stringa Firewall (telnet request) -->.

In alcuni casi è necessario, oltre a registrare le informazioni di un pacchetto, anche scartarlo (o accettarlo):

iptables -A INPUT -s 192.168.0.0/24 -j LOG iptables -A INPUT -s 192.168.0.0/24 -j DROP

Questa soluzione in realtà non è utilizzata in quanto ripetitiva, è meglio creare delle catene specifiche ad esempio logdrop, logaccept e poi utilizzarle quando necessario.

iptables -N logdrop iptables -A logdrop -j LOG --log-level info --log-prefix "FIREWALL logdrop: " iptables -A logdrop -j DROP iptables -N logaccept iptables -A logaccept -j LOG --log-level info --log-prefix "FIREWALL logaccept: " iptables -A logaccept -j ACCEPT iptables -A INPUT -s 192.168.0.0/24 -j logdrop

Il meccanismo di LOG attuale non è ideale per tutti i casi, per questo motivo sono già state proposte nuovi soluzioni che dovrebbero sostituirlo e consentire un utilizzo più comodo.

Formato della registrazione

Il formato della registrazione in base al comando precedentemente indicato è il seguente:

Jun 5 17:35:49 localhost kernel: Firewall (telnet request) -->IN=lo OUT= MAC=00:00:00:00:00:00:00:00:00:00:00:00:08:00 SRC=127.0.0.1 DST=127.0.0.1 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=1061 DPT=23 WINDOW=30816 RES=0x00 SYN URGP=0 Firewall (telnet request) --> = stringa inserita con l'opzione --log-prefix IN = interfaccia di ingresso OUT = interfaccia di uscita SRC = indirizzo IP sorgente del pacchetto DST = indirizzo IP destinazione del pacchetto LEN = dimensione del pacchetto (LENGTH) TOS = bit TOS (Type Of Service) PREC = Precedence TTL = Time to Live ID = Identification (necessario per stabilire a quale pacchetto appartiene un frammento) DF = Don't Fragment (bit che segnala di non frammentare il pacchetto) SPT = porta sorgente DPT = porta destinazione PROTO = protocollo (tcp/udp/icmp) WINDOW= window size (indica quanti byte possono essere spediti a partire dal byte confermato) RES = SYN...= flag impostati (URG/ACK/PSH/RST/SYN/FIN) URGP = urgent pointer (scostamento in byte utile per trovare i dati urgenti)

Nel caso di pacchetti ICMP sono presenti oltre ad alcuni dei campi precedenti anche i seguenti:

TYPE = tipo pacchetto ICMP CODE = codice pacchetto ICMP [..SRC=.. DST=..] = informazioni sul pacchetto che ha causato la risposta ICMP

E' consigliato utilizzare LOG assieme a limit in quanto così è possibile stabilire dei limiti al numero di registrazioni, evitando casi di flood, ossia un numero esagerato di registrazioni che potrebbero causare l'esaurimento dello spazio su disco.

# -------------------------------------------------------------------------------- # Registra i pacchetti (-j LOG) che transitano per la catena FORWARD (-A FORWARD) e # aggiungi la stringa "FORWARD: " (--log-prefix "FORWARD: ". # Utilizza inoltre i parametri di default di limit (3/h, burst di 5 pacchetti) per # limitare il numero di registrazioni. # -------------------------------------------------------------------------------- iptables -A FORWARD -m limit -j LOG --log-prefix "FORWARD: " # -------------------------------------------------------------------------------- # Come esempio precedente solo che si stabilisce un limite alle registrazioni pari a # 5 pacchetti ogni ora (burst rimane invariato, 5 pacchetti). # -------------------------------------------------------------------------------- iptables -A FORWARD -m limit --limit 5/h -j LOG --log-prefix "FORWARD: "

L'esempio 1, riguardante il connection tracking, può essere modificato in questo modo:

#!/bin/bash # Esempio 1 # Supponiamo che PC1 appartenga ad una rete locale e che vogliamo renderla # più sicura e protetta. # # +---+ . # |PC1|------+ # +---+ | # | # +---..... INTERNET # +---+ | # | |------+ # +---+ | # | # . # -------------------------------------------------------------------------------- # Carichiamo i moduli necessari se non compilati nel kernel (es. ip_conntrack) # -------------------------------------------------------------------------------- modprobe ip_conntrack modprobe ipt_REJECT # -------------------------------------------------------------------------------- # Svuotiamo le catene di tutte le regole # -------------------------------------------------------------------------------- iptables -F # -------------------------------------------------------------------------------- # OUTPUT # Accettiamo tutti i pacchetti riguardanti una connessione stabilita o relativa # -------------------------------------------------------------------------------- iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT # -------------------------------------------------------------------------------- # I pacchetti di richiesta connessione o nuova connessione (NEW) accettati # sono solo quelli telnet,www, dns (tcp e udp). # Accettiamo anche i pacchetti in uscita dall'interfaccia lo (localhost). # -------------------------------------------------------------------------------- iptables -A OUTPUT -o lo -j ACCEPT iptables -A OUTPUT -p tcp --dport telnet -m state --state NEW -j ACCEPT iptables -A OUTPUT -p tcp --dport domain -m state --state NEW -j ACCEPT iptables -A OUTPUT -p udp --dport domain -m state --state NEW -j ACCEPT iptables -A OUTPUT -p tcp --dport www -m state --state NEW -j ACCEPT # -------------------------------------------------------------------------------- # tutto il resto è rifiutato # -------------------------------------------------------------------------------- iptables -A OUTPUT -j REJECT # -------------------------------------------------------------------------------- # FORWARD # PC1 non è posto a protezione di una rete locale. # -------------------------------------------------------------------------------- iptables -A FORWARD -j DROP # -------------------------------------------------------------------------------- # INPUT - Accettiamo tutti i pacchetti che fanno parte di una connessione da # noi stabilita (ESTABLISHED) o che sono relativi (RELATED) come ad esempio # pacchetti ICMP di errore. # -------------------------------------------------------------------------------- iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT # -------------------------------------------------------------------------------- # Registriamo i dati riguardanti i pacchetti che non sono appartenenti a connessioni note # o relativi. Nel file questi dati saranno evidenziati dalla stringa "FW ricevuto:" # Inoltre saranno registrati solo un numero limitato di pacchetti (-m limit). # Le opzioni di default di limit sono (--limit 3/hour --limit-burst 5). # -------------------------------------------------------------------------------- iptables -A INPUT -m limit -j LOG --log-level info --log-prefix "FW ricevuto: " # -------------------------------------------------------------------------------- # il resto è scartato # -------------------------------------------------------------------------------- iptables -A INPUT -j DROP

LIMIT

Modulo: insmod ipt_limit Tipo: estensione (-m limit) Es.: iptables -A INPUT -p tcp -m limit --limit 3/h -j LOG

Descrizione

Questo modulo permette di restringere il numero di confronti e per sopprimere i messaggi di log. In ipchains non è implementata.

Può essere utilizzato per limitare il numero di registrazioni dei log oppure per evitare alcuni Denial of Service (DoS), i port scanner sospetti, e i ping della morte (Ping of death).

Opzioni

--limit --limit-burst

--limit Questa opzione permette di specificare il numero confronti che devono essere effettuati in certo periodo di tempo. E' possibile specificare il numero di confronti da effettuare ogni secondo ('/second' o '/s'), oppure ogni minuto ('/minute' o '/m'), ogni ora ('/hour' o '/h'), ogni giorno ('/day' o '/d'). --limit-burst Questa opzione permette di specificare il burst, ossia il numero di pacchetti che devono essere confrontati la prima volta, e quanti ne devono essere recurati se ad ogni scadenza non sono pervenuti. Quindi se specifichiamo un limite di 1 pacchetto al minuto con burst di 5 la prima volta saranno confrontati 5 pacchetti, poi uno solo ogni minuto. Inoltre per ogni minuto che non si ricevono pacchetti allora ne sarà recuperato uno nel burst.

I parametri di default sono --limit 3/hour --limit-burst 5

E' importante fare attenzione a questa enstensione in quanto si potrebbero causare involontariamente dei DoS, in genere è comunque raccomandato utilizzarla con l'obiettivo LOG.

Esempi

# -------------------------------------------------------------------------------- # Appendiamo alla catena INPUT (-A INPUT) una regola che limiti (-m limit), usando # i parametri di default, le registrazioni. # -------------------------------------------------------------------------------- iptables -A INPUT -m limit -j LOG # -------------------------------------------------------------------------------- # Appendiamo alla catena FORWARD (-A FORWARD) una regola che limiti (-m limit), # le registrazioni accettando 1 pacchetto ogni ora (--limit 1/h), con burst # pari a 3 pacchetti (--limit-burst 3). # -------------------------------------------------------------------------------- iptables -A FORWARD -m limit --limit 1/h --limit-burst 3 -j LOG # -------------------------------------------------------------------------------- # Appendiamo una regola che accetti solo 1 pacchetto al secondo (burst di 5) # di tipo SYN (richiesta connessione tcp). # -------------------------------------------------------------------------------- iptables -A FORWARD -p tcp --syn -m limit --limit 1/s -j ACCEPT # -------------------------------------------------------------------------------- # Questo comando aggiunge una regola il cui scopo è di limitare il numero di pacchetti # RST da accettare (1 al secondo con burst di 5). # Utile nel caso qualcuno cerchi di effettuare un port-scanning. # -------------------------------------------------------------------------------- iptables -A INPUT -p tcp --tcp-flags SYN,ACK,FIN,RST RST -m limit --limit 1/s -j ACCEPT # -------------------------------------------------------------------------------- # Aggiungiamo una regola alla catena INPUT (-j INPUT) che accetti 1 pacchetto # icmp echo-request (ping) ogni secondo con burst di 5 pacchetti. # -------------------------------------------------------------------------------- iptables -A INPUT -p icmp --icmp-type echo-request -m limit --limit 1/s -j ACCEPT

Multiport

Modulo: insmod ipt_multiport.o Tipo: estensione (-m multiport) Es.: iptables -A INPUT -p tcp -m multiport --dports telnet,www,dns -j ACCEPT

Descrizione

Questo modulo permette di specificare sulla stessa riga di comando una o più porte anche non consecutive (es. 21,80,8080), altrimenti, non utilizzandolo, è possibile indicare solo una porta o un intervallo di porte consecutive (es. 21:23 che specifica porte 21,22,23).

NOTA: si può utilizzare solo con i protocolli tcp e udp.

Opzioni

--source-ports port(,port,port...) o --sports --destination-ports port(,port,port...) o --dports --ports port(,port,port...)

--sports Permette di specificare più porte sorgenti --dports Permette di specificare più porte destinazione --ports Permette di specificare più porte, sorgenti e destinazione

Esempi

#!/bin/bash # # Esempio 1 # PORTE_TCP=telnet,www,dns PORTE_UDP=dns # -------------------------------------------------------------------------------- # OUTPUT # -------------------------------------------------------------------------------- iptables -A OUTPUT -o lo -j ACCEPT iptables -A OUTPUT -m multiport -p tcp --dports $PORTE_TCP -j ACCEPT iptables -A OUTPUT -m multiport -p udp --dports $PORTE_UDP -j ACCEPT # -------------------------------------------------------------------------------- # accettiamo anche i pacchetti icmp necessari (vedi cap. ICMP) # -------------------------------------------------------------------------------- iptables -A OUTPUT -j icmp-accept iptables -A OUTPUT -j REJECT # -------------------------------------------------------------------------------- # FORWARD # -------------------------------------------------------------------------------- iptables -A FORWARD -j DROP # -------------------------------------------------------------------------------- # INPUT # -------------------------------------------------------------------------------- iptables -A INPUT -i lo -j ACCEPT iptables -A INPUT -p tcp ! --syn --sports $PORTE_TCP -j ACCEPT iptables -A INPUT -p udp --sports $PORTE_UDP -j ACCEPT iptables -A INPUT -j icmp-accept iptables -A INPUT -j DROP

Unclean

Modulo: insmod ipt_unclean Tipo: estensione (-m unclean) Es.: iptables -A INPUT -i eth0 -m unclean -j DROP

Descrizione

Questo modulo permette di riconoscere una serie di pacchetti che per varie ragioni sono malformati o inusuali.

Ecco un elenco dei pacchetti che il modulo è in grado di riconoscere:

Pacchetti troppo "corti" per avere un'intestazione ICMP/UDP/TCP completa. Pacchetti TCP e UDP con porte sorgente e destinazione uguali a zero (illegale). Pacchetti con combinazioni illegali di flag TCP Pacchetti con opzioni TCP e IP di lunghezza zero (illegale) o eccessiva, o con opzioni presenti dopo l'opzione END-OF-OPTIONS Frammenti con lunghezza o offset illegali (es. Ping della Morte).

In genere questi tipi di pacchetti devono essere scartati (DROP).

Questo modulo al momento è ancora sperimentale, quindi non dovrebbe essere utilizzato se non per dei test.

Opzioni

Non sono disponibili opzioni.

Esempi

#!/bin/bash # # Esempio # # -------------------------------------------------------------------------------- # Appendiamo una regola alla catena INPUT (-A INPUT) che per tutti i # pacchetti provenienti dall'interfaccia ppp0 (-i ppp0) malformati (-m unclean) # provveda a registrarli e ... # -------------------------------------------------------------------------------- iptables -A INPUT -i ppp0 -m unclean -j LOG --log-prefix "Ricevuto pacc. malformato: " # -------------------------------------------------------------------------------- # ... a scartarli # -------------------------------------------------------------------------------- iptables -A INPUT -j DROP

Owner

Modulo: insmod ipt_owner Tipo: estensione (-m owner) Es.: iptables -A OUTPUT -m owner --uid-owner 0 -j ACCEPT Descrizione

Questo modulo aggiunge la possibilità di creare delle regole che possano controllare e prendere delle decisioni in base a chi ha creato il pacchetto.

Ciò è possibile solo per i pacchetti generati localmente e destinati alla catena OUTPUT.

Inoltre non è sempre possibile per ogni pacchetto stabilire chi è il proprietario (es. risposte a ping ICMP).

Opzioni

Opzioni disponibili:

--uid-owner userid --uid-owner groupid --pid-owner processid --sid-owner processid

--uid-owner userid Il pacchetto soddisfa la regola se è stato creato dal userid (numerico) specificato. --uid-owner groupid Il pacchetto soddisfa la regola se è stato creato dal groupid (numerico) specificato. --uid-owner processid Il pacchetto soddisfa la regola se è stato creato dal processo con id (numerico) specificato. --uid-owner processid Il pacchetto soddisfa la regola se è stato creato dal processo con gruppo sessione (numerico) specificato.

E' inoltre possibile far precedere a queste opzioni il carattere '!' per negare.

Per ottenere una lista dei processi con relativi USER e PID numerici usare il comando:

# ps -auxn USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND 0 1 0.0 0.7 1120 476 ? S 09:32 0:00 init 0 2 0.0 0.0 0 0 ? SW 09:32 0:00 [kswapd] 0 3 0.0 0.0 0 0 ? SW 09:32 0:00 [kflushd] 0 4 0.0 0.0 0 0 ? SW 09:32 0:00 [kupdate] 0 246 0.0 0.8 1168 524 ? S 09:32 0:00 syslogd -m 0 0 255 0.0 0.8 1168 520 ? S 09:32 0:00 klogd 99 269 0.0 1.0 1292 628 ? S 09:32 0:00 identd -e -o 2 287 0.0 0.7 1144 496 ? S 09:32 0:00 /usr/sbin/atd Esempi

#!/bin/bash # # Esempio # # -------------------------------------------------------------------------------- # Aggiungiamo una regola alla catena OUTPUT (-A OUTPUT) che accetti (-j ACCEPT) solo i pacchetti, # generati localmente, che appartengono all'utente con userid uguale a 0 (root). # -------------------------------------------------------------------------------- iptables -A OUTPUT -m owner --uid-owner 0 -j ACCEPT # -------------------------------------------------------------------------------- # il resto dei pacchetti sono rifiutati (-j REJECT) # -------------------------------------------------------------------------------- iptables -A OUTPUT -j REJECT

Mac

Modulo: insmod ipt_mach Tipo: estensione (-m mac) Es.: iptables -A INPUT -p tcp -m mac --mac-source 08:00:39:00:2F:C3 -j ACCEPT

Descrizione

A volte può essere utile conoscere da quale interfaccia ethernet proviene un pacchetto. Il modulo 'ipt_mach.o' si occupa proprio di questo.

Ogni scheda Ethernet si suppone che abbia un unico indirizzo "hardware" MAC (Media Access Control) a 48 bit (es. 00:60:08:91:CC:B7). Con alcune schede è possibile modificarlo con altre no, comunque attraverso questo indirizzo siamo in grado di verificare con maggior sicurezza da quale macchina arriva un pacchetto (o meglio da quale interfaccia).

Questo modulo deve essere specificato esplicitamente con '-m mac' oppure '--match mac', inoltre può essere utilizzato solo con le catene PREROUTING e INPUT.

Opzioni

--mac-source [!] XX:XX:XX:XX:XX:XX Permette di specificare l'indirizzo ethernet, es. 00:60:08:91:CC:B7. Può essere seguito da '!' (NOT) per indicare gli indirizzi ethernet diversi da quello specificato es. -m mac --mac-source ! 00:60:08:91:CC:B7.

Esempi

#!/bin/bash # # Esempio 1 # MAC_ADDR=08:00:39:00:2F:C3 PC1=192.168.0.5 # -------------------------------------------------------------------------------- # Accettiamo i pacchetti provenienti dall'interfaccia lo # -------------------------------------------------------------------------------- iptables -A INPUT -i lo -j ACCEPT # -------------------------------------------------------------------------------- # Accettiamo (-j ACCEPT) le richieste di connessione e i dati diretti alla porta telnet (--dport telnet) # solo se provengono da PC1 (-s $PC1) e hanno indirizzo MAC associato pari a # MAC_ADDR (--mac-source $MAC_ADDR) # -------------------------------------------------------------------------------- iptables -A INPUT -p tcp -m mac --mac-source $MAC_ADDR -s $PC1 --dport telnet -j ACCEPT # -------------------------------------------------------------------------------- # accettiamo eventuali pacchetti icmp (vedi cap. ICMP) # -------------------------------------------------------------------------------- iptables -A INPUT -j icmp-accept # -------------------------------------------------------------------------------- # resto è rifiutato # -------------------------------------------------------------------------------- iptables -A INPUT -j REJECT iptables -A FORWARD -j DROP # -------------------------------------------------------------------------------- # Accettiamo i pacchetti diretti all'interfaccia lo # -------------------------------------------------------------------------------- iptables -A OUTPUT -o lo -j ACCEPT # -------------------------------------------------------------------------------- # Accettiamo (-j ACCEPT) i pacchetti inviati in risposta a PC1 (-d $PC1) # -------------------------------------------------------------------------------- iptables -A OUTPUT -p tcp -d $PC1 --sport telnet -j ACCEPT # -------------------------------------------------------------------------------- # Accettiamo i pacchetti icmp (vedi cap. ICMP) # -------------------------------------------------------------------------------- iptables -A OUTPUT -j icmp-accept # -------------------------------------------------------------------------------- # Resto rifiutato # -------------------------------------------------------------------------------- iptables -A OUTPUT -j REJECT

MARK

Modulo: insmod ipt_MARK Tipo: obiettivo (-j MARK) Es.: iptables -A PREROUTING -i eth0 -t mangle -p tcp --dport telnet -j MARK --set-mark 1 Descrizione

In alcuni casi può essere utile marcare i pacchetti per poi prendere, in base a queste, delle decisioni di instradamento particolari (routing).

In particolare può essere utilizzato assieme al comando tc del pacchetto iproute2 per gestire il controllo del traffico.

I pacchetti sono sottoposti a tutte le regole presenti in questa tabella, anche se ad esempio soddisfano già la prima regola.

Opzioni

--mark-value[/mask] Permette di specificare il valore ed eventualmente anche la maschera che contrassegnerà i pacchetti specificati. E' possibile far precedere all'opzione il carattere '!' per negare.

Esempi

Esempio1

#!/bin/bash # # Esempio 1 # modprobe ipt_MARK ETH=eth0 FTP=1 TELNET=2 PC1=192.168.0.2 PC2=192.168.0.3 FAST=1 SLOW=0 # -------------------------------------------------------------------------------- # Prima che i pacchetti generati localmente siano immessi nella rete in base alla # porta di destinazione sono marcati con un valore. # NOTA: Qui si utilizza la catena OUTPUT ma della tabella mangle ! # -------------------------------------------------------------------------------- iptables -A OUTPUT -o $ETH -t mangle -p tcp --dport ftp -j MARK --set-mark $FTP iptables -A OUTPUT -o $ETH -t mangle -p tcp --dport telnet -j MARK --set-mark $TELNET # -------------------------------------------------------------------------------- # Prima che i pacchetti siano instradati sono marcati in base all'indirizzo di destinazione # Il kernel potrà utilizzare queste informazioni ad esempio per indirizzare i # pacchetti FAST su una "banda" veloce e i SLOW su una lenta. # -------------------------------------------------------------------------------- iptables -A PREROUTING -t mangle -p tcp -d $PC1 -j MARK --set-mark $FAST iptables -A PREROUTING -t mangle -p tcp -d $PC2 -j MARK --set-mark $SLOW

TOS (Type Of Service)

Modulo: insmod ipt_TOS Tipo: obiettivo (-j TOS) Es.: iptables -A PREROUTING -t mangle -p tcp --dport telnet -j TOS --set-tos Minimize-Delay

Descrizione

Questo modulo permette di impostare i bit TOS (Type Of Service). Questi bit sono presenti nell'intestazione IP dei pacchetti e influenzano come devono essere trattati dalla macchina che li invia.

Ognuno ha un suo scopo e non è possibile combinarli assieme.

Opzioni

--set-tos value Permette di specificare quale bit impostare

Bit

I bit sono cinque:

Minimize-Delay (16, 0x10) ritardo minimo Maximize-Throughput (8, 0x08) massima velocità di trasmissione Maximize-Reliability (4, 0x04) massima affidabilità Minimize-Cost (2, 0x02) costo minimo Normal-Service (0, 0x00) servizio normale

L'uso comune è quello di impostare telnet e ftp a "Minimize-Delay", ftp-data, www a "Maximize-Throughput", snmp, dns a "Maximize-Reliability" e nntp, smtp a "Minimize-Cost".

Per l'elenco completo compresi valori esadecimali utilizzare il comando:

iptables -j TOS --help

Per impostare i bit tos è necessario utilizzare la tabella mangle usando l'opzione '-t mangle', specificare il protocollo (-p), la porta (--dport), l'obiettivo (-j) e il bit da impostare (--set-tos).

Le regole devono essere aggiunte alla catena PREROUTING, in quanto si possono modificare solo i pacchetti che sono in uscita dalla macchina e prima del routing.

Esempi

# -------------------------------------------------------------------------------- # TOS # -------------------------------------------------------------------------------- iptables -A PREROUTING -t mangle -p tcp --dport telnet -j TOS --set-tos Minimize-Delay iptables -A PREROUTING -t mangle -p tcp --dport ftp -j TOS --set-tos Minimize-Delay iptables -A PREROUTING -t mangle -p tcp --dport ftp-data -j TOS --set-tos Maximize-Throughput

ipchains vs. iptables

Anche ipchains permette di impostare i bit TOS usando il seguente comando:

ipchains -A output -p tcp -d 0.0.0.0/0 telnet -t 0x01 0x10

Questa linea con iptables dovrebbe diventare:

iptables -A PREROUTING -p tcp --dport telnet -d 0.0.0.0/0 -j TOS --set-tos Minimize-Delay

MIRROR

Modulo: insmod ipt_MIRROR Tipo: obiettivo (-j MIRROR) Es.: iptables -A -p tcp -s 213.15.12.3 -j MIRROR Descrizione

Questo modulo aggiunge la possibilità di specificare MIRROR come target (-j MIRROR), in questo modo i pacchetti che soddisfano la regola saranno rispediti indietro al mittente. In pratica non fa altro che inverire i campi indirizzo sorgente e indirizzo destinazione contenuti nell'intestazione IP dei pacchetti. Questo modulo è ancora sperimentale e da utilizzare esclusivamente per effettuare dei test.

Opzioni

Non sono disponibili opzioni

REJECT

Modulo: insmod ipt_REJECT Tipo: obiettivo (-j REJECT) Es.: iptables -A INPUT -p tcp --syn -j REJECT --reject-with proto-unreach Descrizione

Questo modulo aggiunge la possibilità di specificare REJECT come target (-j REJECT), in questo modo se la regola è soddisfatta sarà spedito al mittente un pacchetto icmp. Si può usare in alternativa di DROP che invece scarta il pacchetto senza inviare alcun messaggio alla macchina che lo ha spedito.

Opzioni

--reject-with Con questa opzione è possibile indicare quale tipo di pacchetto icmp inviare alla macchina mittente. I pacchetti supportati attualmente sono:

icmp-net-unreachable o net-unreach icmp-host-unreachable o host-unreach icmp-port-unreachable o port-unreach icmp-proto-unreachable o proto-unreach echo-reply o echoreply

Esempi

#! /bin/sh # # Esempio # ... # -------------------------------------------------------------------------------- # Inviamo un pacchetto icmp 'icmp-net-unreachable' a chi invia pacchetti destinati # alla rete 192.168.1.0 perché ad esempio non presente # -------------------------------------------------------------------------------- iptables -A INPUT -p tcp -d 192.168.1.0 -j REJECT --reject-with icmp-net-unreachable # -------------------------------------------------------------------------------- # Inviamo un pacchetto icmp 'port-unreach' a chi invia pacchetti destinati alla porta ftp # -------------------------------------------------------------------------------- iptables -A INPUT -p tcp --dport ftp -j REJECT --reject-with port-unreach # -------------------------------------------------------------------------------- # tutto il resto è scartato # -------------------------------------------------------------------------------- iptables -A INPUT -j DROP ...

TCP/IP

Il modello più diffuso per la trasmissione dei dati attraverso le reti è oggi il TCP/IP.

Il nome deriva dai suoi due protocollo principali: TCP (Transmission Control Protocol) e IP (Internet Protocol).

I dati che viaggiano nella rete sono organizzati in pacchetti, ciascuno contiene un'intestazione IP in cui sono presenti alcune informazioni molto importanti (indirizzo sorgente, indirizzo destinazione, lunghezza totale, ...) che permettono loro di giungere a destinazione. Inoltre se i pacchetti sono di tipo TCP allora conterranno anche un'intestazione TCP che raccoglie un insieme di informazioni (porta sorgente, porta destinazione, Type Of Service, flags, ...) utili per verificare la correttezza dei pacchetti, per riordinarli nell'ordine corretto, per stabilire a quale servizio sono destinati (ftp, telnet, mail, www, ...).

Il protocollo TCP è orientato alla connessione affidabile, si occupa di riassemblare, frammentare, riordinare, ritrasmettere, controllare i pacchetti. Esiste anche una "versione" più semplice nota come UDP (User Datagram Protocol) non basata su connessione e quindi inaffidabile ma estremamente veloce, in alcuni casi è preferita al TCP ad esempio per richieste al DNS (Domain Name System) o per tftp (Trivial ftp). Il protocollo IP ha come compito invece quello di instradare e consegnare i pacchetti a destinazione.

I pacchetti possono essere graficamente rappresentati in questo modo:

+------------+------------+------------- - - |intestazione|intestazione| DATI | IP | TCP | .... +------------+------------+------------- - - 20 bytes 20 bytes [ Pacchetto ]

Sempre nei pacchetti IP sono inoltre incapsulati anche i pacchetti UDP e i pacchetti ICMP, questi ultimi usati per lo più per segnalare errori o problemi riscontrati nella rete o nella consegna dei pacchetti.

Per una completa descrizione dei campi delle varie intestazioni consultare l'appendice.

Il filtraggio dei pacchetti si basa proprio su queste informazioni per stabilire se un pacchetto deve essere accettato o meno. In particolare è importante conoscere come si stabilisce una connessione, come sono scambiati i dati, e quali sono i punti deboli.

La maggior parte dei servizi (ftp, telnet, mail) oltre all'indispensabile protocollo IP utilizzano anche il protocollo TCP che è affidabile, completo e basato su connessione.

Connessione "Three-way handshake"

La connessione si basa sul "Three-way handshake" ossia tre fasi in cui due computer stabiliscono e negoziano la connessione.

La prima fase prevede che il client richieda una connessione (SYN) alla macchina server, ossia invii un pacchetto completo di intestazione IP e TCP con il flag SYN impostato:

+---+ +-------+ |PC1|------------ SYN --------------->|SERVER | +---+ +-------+

La seconda fase prevede che il server, se disponibile, invii un pacchetto di risposta affermativo (SYN/ACK):

+---+ +-------+ |PC1|<------- SYN/ACK ------------- |SERVER | +---+ +-------+

La terza fase prevede che il client invii a sua volta un pacchetto di conferma (ACK):

+---+ +-------+ |PC1| ---------- ACK -----------> |SERVER | +---+ +-------+

Concluse con successo queste fasi il client può cominciare a inviare i pacchetti con i dati.

NOTA: questo schema è semplificato e non ha preso in esame le porte e il 'sequence number'.

Porte

Per poter stabilire una connessione con un computer è necessario indicare a quale servizio (telnet, ftp, www, finger, rlogin, ...) si è interessati. Nel file /etc/services è possibile trovare un elenco dei servizi standard che si possono richiedere completi di numero, protocollo e in alcuni casi breve descrizione. Esempio:

... echo 7/tcp telnet 23/tcp ftp 21/tcp www 80/tcp http # WorldWideWeb HTTP www 80/udp # HyperText Transfer Protocol domain 53/tcp nameserver # name-domain server domain 53/udp nameserver ...

NOTA: in alcuni casi si possono trovare nomi differenti a seconda della distribuzione Linux (es. pop3 e pop-3) i numeri sono comunque gli stessi.

Le porte sono suddivise in porte note o privilegiate (well-known port) e porte non privilegiate. Le porte note appartengono all'intervallo da 1 a 1023, ad ognuna è associato un servizio e protocollo, secondo quanto stabilito dallo IANA (RFC 1700). Se un computer vuole offrire un servizio ftp a qualsiasi utente allora si dovrà mettere in "ascolto" sulla porta 21 in attesa che qualcuno invii una richiesta di connessione, quindi provvedere a stabilire la connessione (caso TCP) e a scambiare i dati.

Le porte che appartengono all'intervallo 1024-65535 sono invece utilizzato in genere dal client come vedremo.

L'intestazione TCP comprende due campi importanti: porta sorgente e porta destinazione. Quando si vuole stabilire una connessione per accedere ad una macchina presente nella rete utilizzando ad esempio il telnet è necessario che questi due campi siano impostati in modo appropriato, le fasi nel caso del telnet sono le seguenti:

Il client invia pacchetto inizio connessione specificando anche il servizio alla quale è interessato (es. telnet), indica inoltre verso quale porta devono essere indirizzati i pacchetti in risposta (ne seleziona una libera tra quelle dell'intervallo 1024-65535 partendo da 1024) e il protocollo:

+---+ +-------+ |PC1|----------- SYN ----------->|SERVER | PD = Porta Destinazione +---+ PD=23 +-------+ PS = Porta Sorgente PS=1024 PT = Protocollo (tcp/udp/icmp) PT=tcp

In questo caso è inviata una richiesta di connessione alla porta 23 (telnet) del server specificando che le risposte dovranno essere indirizzate alla porta 1024 del client, protocollo tcp.

Se il server offre quel servizio ed è in "ascolto" sulla porta 23 (telnet), se decide di accettare la connessione, invierà un pacchetto di conferma (ACK) dove specificherà che deve essere destinato alla porta 1024 del client, proveniente dalla sua porta 23:

+---+ +-------+ |PC1| <------- SYN/ACK ---------- |SERVER | PD = Porta Destinazione +---+ PD=1024 +-------+ PS = Porta Sorgente PS=23 PT = Protocollo (tcp/udp/icmp) PT=tcp

Nota che ora la porta destinazione è 1024 e non più 23, la situazione si è insomma invertita.

Poi si prosegue più o meno nella stesso modo anche nella fase di invio/ricezione dei dati.

E' necessario precisare che in qualche caso alcuni servizi, ad esempio www, possono essere presenti su porte differenti. E' infatti possibile che ad esempio www sia disponibile invece che sulla porta 80 sulla 8080, sono comunque casi noti.

Altri servizi come RealPlayer, X Window, Quake, utilizzano porte prestabilite ma appartenenti all'intervallo 1024-65535, e non una delle note (1-1023). Ciò è dovuto al fatto che sono servizi resi disponibili recentemente.

In alcuni casi un servizio (es. dns/domain) è disponibile sia con protocollo tcp sia udp. Nel caso di dns ad esempio è utilizzato in genere il protocollo udp (veloce e privo di connessione 3-way handshake), ma in alcuni casi si rende necessario anche l'utilizzo del protocollo tcp più completo e affidabile. Ciò è importante per chi deve realizzare un firewall.

La porta sorgente è utile anche per distinguere tra due diverse connessioni alla stessa porta destinazione. Ad esempio quando si accede all'indirizzo www.linux.org e si aprono due pagine dello stesso sito con netscape come fa il client a riconoscere quali dati riguardano una e quali l'altra ? In base alla porta sorgente che sarà ovviamente diversa.

+=============================+ | Netscape | +-----------------------------+ | www.linux.org/index.html |<-----SP=80 (www) DP=1024 ... --- +------------+ |^^^+============================+ | SERVER WWW | | | Netscape | | | | +----------------------------+ | | | |www.linux.org/page1.html |<--SP=80 (www) DP=1025 ... --- | linux.org | | |^^^^^^^^^^^^^^^^^^^^^^^^^^^^| | | | | | +------------+ . . .

Esempio

Esempio di una connessione ad un www server per reperire delle pagine web:

Supponiamo di voler instaurare una connessione con il sito internet www.linux.com e di aver la seguente situazione:

+----+ +----------+ |PC1 | |SERVER WWW| | | |linux.com | +----+ +----------+ 151.186.5.4 198.186.203.55

Inseriamo l'indirizzo www.linux.com nel nostro browser e iniziamo una connessione. L'applicazione Netscape richiede quindi al kernel una connessione TCP al server www.linux.com. A questo punto è selezionata una porta sorgente tra quelle disponibili nell'intervallo 1024-65535 a partire però dalla 1024 se è disponibile. Il nome www.linux.com viene risolto attraverso il dns (Domain Name System), ossia un computer, il cui indirizzo deve essere presente nel file /etc/resolv.conf, che ha il compito di restituire l'indirizzo IP numerico corrispondente: 198.186.203.55.

Quindi tenta di instaurare una connessione al WEB server inviando un pacchetto con indirizzo sorgente l'indirizzo 151.186.5.4 (PC1), indirizzo destinazione 198.186.203.55 (www.linux.com), porta sorgente 1024, porta destinazione ovviamente 80 (porta nota www), flag SYN impostato. E' inoltre scelto arbitrariamente da Linux un 'sequence number' (numero di sequenza) es. 1000000.

+----+ +----------+ |PC1 | ------------o-------------> |SERVER WWW| | | / \ |linux.org | +----+ / \ +----------+ 151.186.5.4 / \ 198.186.203.55 ______________/ \______________________ / \ +----------------------------------------------------+ | IP IS=151.186.5.4 ID=198.186.203.55 | IS=indirizzo sorgente | ... | ID=indirizzo destinazione +----------------------------------------------------+ | TCP PS=1024 PD=80 (www) | PS=porta sorgente | FLAG=SYN SEQ_NR=1000000 | PD=porta destinazione | ... | +----------------------------------------------------+

Il server WEB www.linux.com riceve il pacchetto, accetta la connessione e risponde inviando un pacchetto di conferma con flag ACK impostato. Questo pacchetto inoltre conterrà il sequence number inviato con in più sommato 1 (SYN) (posto nel campo 'acknowledgement number') e il sequence number scelto dal server es. 2000000.

+----+ +----------+ |PC1 | <-----------o------------- |SERVER WWW| | | / \ |linux.org | +----+ / \ +----------+ 151.186.5.4 / \ 198.186.203.55 ______________/ \______________________ / \ +----------------------------------------------------+ | IP IS=151.190.20.12 ID=198.186.203.55 | IS=indirizzo sorgente | ... | ID=indirizzo destinazione +----------------------------------------------------+ | TCP PS=80 (www) PD=1024 | PS=porta sorgente | FLAG=SYN+ACK SEQ_NR=2000000 | PD=porta destinazione | ... ACK_NR=1000001 | +----------------------------------------------------+

La macchina PC1 riceve il pacchetto controlla che il campo 'acknowledgement number' sia corretto e conclude la fase di connessione inviando un ultimo pacchetto TCP di conferma ossia con il flag ACK impostato. Il sequence number sarà 1000000 + 1 inoltre sarà inviato anche il sequence number del server con sommato 1 (SYN) ossia 2000001 nel campo 'acknowledgement number'.

+----+ +----------+ |PC1 | ------------o-------------> |SERVER WWW| | | / \ |linux.org | +----+ / \ +----------+ 151.186.5.4 / \ 198.186.203.55 ______________/ \______________________ / \ +----------------------------------------------------+ | IP IS=151.186.5.4 ID= 198.186.203.55 | IS=indirizzo sorgente | ... | ID=indirizzo destinazione +----------------------------------------------------+ | TCP PS=1024 PD=80 (www) | PS=porta sorgente | FLAG=ACK SEQ_NR=1000001 | PD=porta destinazione | ... ACK_NR=2000001 | +----------------------------------------------------+

A questo punto PC1 da Netscape può effettuare una richiesta HTTP, inoltrata come sempre con un pacchetto TCP sequence number 1000001 e ack number 2000001, flag ACK impostato.

Il server riceve e risponde con un pacchetto TCP con sequence number 2000001, acknowledgement number pari a 1000001 + (dimensione pacchetto TCP inviato da PC1), e i dati (pagina web) richiesti.

Quest'ultime due fasi poi si ripetono per ogni invio/ricezione di richieste/dati.

Terminata la visita al sito, PC1 chiude la connessione inviando un pacchetto TCP con il flag FIN impostato.

NOTA: l'utilizzo dei campi 'sequence number' e 'acknowledgement number' è fondamentale in quanto consente ai computer di controllare e verificare l'ordine e la correttezza dei pacchetti scambiati.

Problemi

Il meccanismo che permette di stabilire una connessione e scambiare dati non è perfetto, in alcuni casi anche a causa di errori presenti nelle varie implementazioni dello stack TCP/IP, è possibile aggirare e intromettersi nella comunicazione.

Sono note diverse tecniche che possono creare problemi riguardanti l'area della sicurezza, tra queste le più note sono: IP spoofing, smurfing, Blind spoofing, ...

IP spoofing

Quando si richiede una connessione ad una macchina, come si è visto, si inviano una serie di pacchetti dove nelle intestazioni sono presenti varie informazioni tra cui indirizzo sorgente, indirizzo destinazione, porta destinazione, ... In particolare l'indirizzo sorgente specifica l'indirizzo IP di chi invia i pacchetti, l'IP spoofing si basa proprio su questo campo, che può essere modificato, forgiato da un attacker per effettuare un attacco. E' possibile cioè che qualcuno possa creare e inviare dei pacchetti in modo tale che sembrino provenire da un qualunque indirizzo IP. Ciò consente di agire senza essere facilmente rintracciabilili.

Questo tipo di attacco è particolarmente pericoloso per quei servizi che sono impostati in modo da non richiedono login e password, e che quindi fanno affidamento per identificare l'utente solo sull'indirizzo IP.

Per proteggersi da questo tipo di attacchi è possibile impostare il parametro "rp_filter" presente nella directory /proc/sys/net/ipv4/conf/default in modo che tutti i pacchetti che arrivano dalla rete esterna aventi come indirizzo sorgente un'indirizzo della propria rete locale siano scartati. Per impostare questo parametro in modo che protegga tutte le interfacce presenti nella macchina (es. firewall) utilizzare:

if [ -e /proc/sys/net/ipv4/conf/all/rp_filter ] then for f in /proc/sys/net/ipv4/conf/*/rp_filter do echo 1 > $f done fi

Questa è la soluzione migliore, un'alternativa può essere quella di utilizzare iptables:

# Scartiamo tutti i pacchetti in entrata dall'interfaccia esterna (qui eth0) con indirizzo # uguale a quello della nostra rete iptables -A FORWARD -i eth0 -s 207.102.5.0/24 -j DROP

Con questo comando tutti i pacchetti che arrivano all'interfaccia esterna eth0 aventi per indirizzo sorgente un indirizzo della nostra rete locale (207.102.5.0/24) sono scartati (DROP).

E' anche consigliato impedire che dalla nostra rete locale possano uscire dei pacchetti con indirizzo sorgente diverso da quello atteso, che dovrebbe essere ovviamente del tipo 207.102.5.x. Questo per impedire che qualcuno cerchi di inviare pacchetti di tipo "spoofing" dalla nostra rete locale.

+---+ |PC1|---+ eth1 eth0 +---+ | | | +---+ | \+---+/ |MAC|---+---| |---- INTERNET +---+ | +---+ . [RETE LOCALE] [firewall] 207.102.5.0/24

# iptables -A FORWARD -i eth1 ! -s 207.102.5.0/24 -j REJECT

I pacchetti giunti dalla rete locale (-i eth1) con indirizzo sorgente diverso da 207.102.5.0/24 (! -s 207.102.5.0/24) sono rifiutati (-j REJECT).

Dovrebbero essere eseguiti comandi simili per ogni interfaccia del firewall ed anche per la catena INPUT.

Proteggersi dall'IP spoofing è molto importante in quanto molti attacchi ne fanno ancora uso.

Blind spoofing

Questa tecnica si basa sull'IP spoofing e ha come scopo stabilire una connessione con un server utilizzando un indirizzo sorgente fasullo.

+---+ +---+ | | <----o---- | | +---+ ^ +---+ [SERVER] | [ATTACKER] | +---+ '-------- pacchetto con indirizzo sorgente fasullo 213.120.4.3 | | +---+ [213.120.4.3]

A prima vista potrebbe sembrare molto semplice ma in realtà non lo è. Quando si invia un pacchetto con indirizzo sorgente fasullo ad un server quest'ultimo invierà le risposte non all'attacker ma alla macchina con l'indirizzo IP uguale a quello fasullo indicato nel pacchetto.

+---+ +---+ | | | | +---+ +---+ [SERVER] [ATTACKER] | o <-- pacchetto di risposta diretto a 213.120.4.3 e non all'attacker | v +---+ |PC2| +---+ [213.120.4.3]

Il problema è che la macchina 213.120.4.3 riceve il pacchetto, rileva che non ha effettuato alcuna richiesta per quella connessione (infatti è stata fatta dall'attacker) e quindi invierà di conseguenza un pacchetto di RST per annullarla.

Questo chiuderebbe la connessione impedendo all'attacker di stabilire e concludere la connessione. L'attacker deve quindi impedire che ciò avvenga e ciò è possibile se riesce a bloccare PC2. A questo scopo si può utilizzare un DoS (Denial of Service) che non deve far altro che "disabilitare" forzatamente e per un certo tempo PC2 in modo che non sia in grado di inviare i pacchetti RST.

Risolto questo problema è necessario infine predire il sequence number iniziale inviato dal server, per concludere la "Three-way handshake" infatti è necessario che l'attacker invii un pacchetto di conferma (ACK) contenente l'acknowledgement number (basato sul sequence number inviato dal server) corretto. Fino a qualche tempo fa ciò era possibile e in alcuni casi era banale quindi l'attacker poteva concludere la connessione con successo, ora lo stack TCP/IP di vari sistemi operativi generano numeri di sequenza casuali difficilmente predicibili.

Abilitando la protezione contro l'IP spoofing e grazie alla capacità di Linux di generare sequence number casuali non facilmente predicibili, questo tipo di attacco è evitabile.

Port scanning

Tra gli strumenti utilizzati per ottenere informazioni utili per scoprire eventuali punti deboli di un computer connesso in rete ci sono i cosiddetti port scanner.

Attraverso questi programmi è possibile ottenere di una macchina un elenco delle porte aperte, ossia dei servizi (ftp, www, ...) che offre volutamente, potrebbe essere un server WWW, oppure no (macchina malconfigurata). Le porte aperte rappresentano un potenziale canale di comunicazione, utilizzabile per scambiare dati e per portare un eventuale attacco.

Le tecniche adottate sono diverse e permettono di ottenere un certo grado di anonimato, in genere non si desidera che la "macchina vittima" possa rilevare e registrare i port scanning.

Tra le tecniche più note troviamo:

Vanilla TCP connect() scanning TCP SYN (half-open) scanning TCP FIN (stealth) scanning UDP ICMP port unreachable scanning

Vanilla TCP connect() Questa è la tecnica più semplice e consiste nella chiamata alla routine di sistema connect(). Se la porta desiderata (es. www) è aperta allora avrà successo altrimenti la porta risulterà irraggiungibile. I vantaggi di questa tecnica sono la velocità e il fatto che per eseguirla non è necessario possedere particolari privilegi (es. root). Lo svantaggio è che può essere facilmente rilevata e registrata dal server vittima. TCP SYN (half-open) scanning In questo caso non è necessario completare la "Three hand-shake", ossia si invia un pacchetto di richiesta connessione (SYN) alla porta della macchina vittima, e si attende una risposta che potrebbe essere RST (porta/servizio non disponibile) o SYN-ACK (porta/servizio disponibile), in quest'ultimo caso si provvederà allora ad inviare un pacchetto RST per chiudere immediatamente la connessione. Utile in quanto in alcuni casi i server non rilevano e registrano queste prove. TCP FIN (stealth) scanning Questa tecnica è stato implementata in quanto i tentativi basati sui pacchetti SYN è molto nota e quindi in molti casi i server sono in grado di rilevarla utilizzando anche specifici programmi. La soluzione in questo caso consiste nell'invio di un pacchetto FIN, in genere utilizzato per chiudere una connessione stabilita. La macchina che riceve questo pacchetto si è osservato che in genere, se la porta/servizio non è disponibile, invia un pacchetto in risposta di tipo RST, in caso contrario nulla è inviato. In base a queste informazioni è così possibile stabilire se un determinato servizio è o meno disponibile e senza dover utilizzare un pacchetto SYN. NOTA: macchine con sistema operativo Microsoft non operano in questo modo (standard), in caso di pacchetti FIN rispondono in ogni caso con un pacchetto RST. UDP ICMP port unreachable scanning In questo caso non si invia un pacchetto TCP ma bensì UDP (User Datagram Protocol). Questi pacchetti sono molto semplici ma non sono affidabili. In molti casi si è notato che inviando questi pacchetti verso una porta UDP si è ottenuto in risposta un pacchetto ICMP_PORT_UNREACH, ciò permette di conoscere quali porte UDP non sono sicuramente disponibili, mentre sulle altre è possibile fare solo alcune considerazioni. UDP è un protocollo inaffidabile che non si basa sul concetto di connessione quindi i pacchetti che si inviano o che si dovrebbero ricevere potrebbero andare persi, e quindi le informazioni ricavate potrebbero non corrispondere al vero. Altro problema è la scarsa velocità offerta. Utile però per verificare quale delle porte alte (1024-65535) UDP sono aperte.

FRAMMENTI Descrizione

I pacchetti che viaggiano attraverso la rete hanno una dimensione, questa può variare da caso a caso. Nel caso Ethernet i pacchetti hanno una dimensione di 1500 byte, nel caso invece di pacchetti inviati verso internet attraverso l'interfaccia ppp0 (dialup) è in genere pari a 296 byte, ma è comunque possibile variarla modificando il parametro MTU (Maximum Transmission Unit).

Di questi 296 byte una parte è occupata dalle intestazioni (IP e TCP, o IP e ICMP ...) il resto dai dati.

In particolare un'intestazione TCP occupa 20 byte, e visto che deve essere incapsulato sempre in un pacchetto IP è necessario aggiungere anche l'intestazione IP (20 byte), quindi lo spazio a disposizione per i dati in ciascun pacchetto sarà pari a 296 (MTU) - 20 (intestazione IP) - 20 (intestazione TCP) = 256 byte.

Graficamente possiamo rappresentarli così:

0 20 40 295 +-------+-------+------------------------+ | IP | TCP | DATI | +-------+-------+------------------------+

Questo è valido per il primo pacchetto, infatti i pacchetti/frammenti successivi conterranno solo l'intestazione IP e i dati, l'intestazione TCP non sarà più necessaria:

0 20 295 +-------+--------------------------------+ | IP | DATI | +-------+--------------------------------+

Quindi se volessimo inviare 1500 byte di dati attraverso l'interfaccia ppp0, in realtà, come visto, non sarà spedito un solo pacchetto da 1500 byte, ma diversi pacchetti/frammenti:

Pacchetto iniziale con intestazione IP (20 byte), TCP (20 byte) e dati (256 byte, totale 296 byte) Pacchetto successivo con solo intestazione IP (20 byte) e dati (276 byte, totale 296 byte) Pacchetto successivo con solo intestazione IP (20 byte) e dati (276 byte, totale 296 byte) ...

La macchina che li riceverà provvederà poi a ordinarli, riassemblarli e a ricostruire i pacchetti originali. Ping della morte, Teardrop, ...

I frammenti sono stati, particolarmente in passato, causa di notevoli problemi e crash delle macchine. Questi problemi sono derivati da una non corretta implementazione di molti stack TCP/IP.

Tra i più noti e citati ci sono il Ping della Morte (Ping of Death), Teardrop, Bonk, Zero Length Fragments.

Il Ping della morte si basa sul campo "Total Lenght" (lunghezza totale) del pacchetto IP. Un pacchetto IP non può essere lungo più di 65535 byte. Il ping della morte consiste nell'inviare un frammento con lunghezza di 1000 bytes e impostare il campo "Fragment Offset" del pacchetto stesso a 65400 byte, lo stack TCP/IP vulnerabile della macchina che lo riceve cercherà quindi di assemblare un pacchetto di lunghezza 65400+1000 byte = 66400 byte con risultati spiacevoli (crash).

Ora gran parte dei sistemi operativi sono immuni da questo tipo di attacco, ossia controllano la dimensione dei pacchetti riassemblati, anche linux ha sofferto di questo problema fino alla versione 2.0.24 del kernel.

Teardrop, Bonk, ... invece creano ad arte dei frammenti in modo tale che con il riassemblamento i frammenti si "sovrappongano" confondendo e mettendo in crisi la macchina destinataria.

I Zero length Fragments hanno creato problemi a Linux fino alla serie 2.2.4 del kernel. Questo attacco si basa sull'invio di un frammento di lunghezza zero, la macchina erroneamente lo accoda assieme agli altri frammenti da riassemblare, invece di scartarlo.

Per quanto riguarda il filtraggio dei pacchetti il problema riguarda la struttura dei frammenti successivi al primo, che come abbiamo visto non contengono l'intestazione TCP. Questo significa che non sarà possibile controllare i relativi campi.

Esistono comunque diverse soluzioni, ad esempio se la propria macchina firewall è l'unica che protegge la rete locale è possibile compilare il kernel con la voce "always defragment" selezionata, in questo modo tutti i frammenti diretti alle macchine della rete locale, prima di essere inoltrati, saranno riassemblati dal firewall. Questo inoltre permette di utilizzare iptables/ipchains senza doversi preoccupare dei frammenti.

In questo caso è necessario fare attenzione nel caso ci siano più firewall, se i frammenti dovessero arrivare parte a uno e parte all'altro il riassemblaggio fallirebbe miseramente.

Altrimenti sarà necessario accettare i frammenti e lasciare alle macchine destinatarie della rete locale il compito di riassemblarli (non consigliato). Con iptables è necessario specificare esplicitamente che i frammenti devono essere accettati con l'opzione '-f'.

Ad esempio è possibile accettare tutti i frammenti diretti alla rete locale, in questo modo:

iptables -A FORWARD -f -j ACCEPT

Oppure potremmo voler accettare solo i pacchetti www e i frammenti e rifiutare il resto:

iptables -A INPUT -p tcp ! --syn --sport www -j ACCEPT iptables -A INPUT -p tcp --sport www -f -j ACCEPT ... iptables -A INPUT -j REJECT

Nota: se si utilizza il tracciamento delle connessioni o il NAT, i frammenti prima di essere filtrati dal firewall saranno sempre riassemblati.

ICMP Descrizione

ICMP (Internet Control Message Protocol) è un protocollo designato per effettuare test, controlli e gestire situazioni di errore.

Per essere indirizzati nella rete anch'essi si appoggiano al protocollo IP, che contiene le informazioni di instradamento (indirizzo sorgente, destinazione).

+-------+--------+ | IP | ICMP | +-------+--------+

Un programma molto noto che utilizza questo protocollo è ping, il cui scopo principale è di verificare se una macchina nella rete è raggiungibile e in funzione oppure no. Per verificare se la macchina con indirizzo IP 192.168.0.1 è presente nella rete è sufficiente quindi impartire il comando:

ping 192.168.0.1

Ping non fa altro che inviare un pacchetto ICMP di tipo 0 (echo request) alla macchina destinataria e attendere che questa risponda con un pacchetto ICMP di tipo 8 (echo reply).

Tipi ICMP

Ecco un elenco dei pacchetti ICMP più importanti:

ICMP tipo 0 - Echo reply (pong) Come visto è il pacchetto inviato dalle macchine in risposta ad un pacchetto ICMP tipo 8 echo request (ping). In genere non sono filtrati. ICMP tipo 3 - Destination Unreachable Questo tipo di pacchetti segnalano all'host che ha spedito un pacchetto che non è stato possibile consegnarlo all'host destinatario in quanto non raggiungibile (unreachable) o perchè il servizio (porta) richiesto non era disponibile (Port Unreachable). Il codice associato può essere uno dei seguenti:

0 Net Unreachable 1 Host Unreachable 3 Port Unreachable 4 Fragmentation Needed but DF set 5 Source route failed

Quando in una regola si utilizza l'obiettivo REJECT (-j REJECT) il firewall per ogni pacchetto che soddisfa quella regola provvederà a spedire all'host che l'ha inviato un pacchetto ICMP di tipo 3. Per default il codice associato è 3 (Port Unreachable) ma può essere cambiato.

Può essere utilizzato per attachi DoS, comunque è sconsigliato filtrare questi pacchetti, in quanto si potrebbero ottenere malfunzionamenti e ritardi nelle risposte. In particolare 'Fragmentation Needed but DF set' è molto importante in quanto utilizzato per stabilire la dimensione massima che può avere un pacchetto senza dover essere frammentato. Scartare questi pacchetti potrebbe causare malfunzionamenti e un calo di prestazione.

ICMP tipo 4 - Source Quench Congestione nella rete. Gli host in genere reagiscono a questo tipo di pacchetti ICMP "rallentando" la comunicazione, potrebbero quindi essere usati per un attacco DoS. Pare che siano utilizzati da alcuni server SMTP. In genere comunque non sono filtrati. ICMP tipo 5 - Redirect Questi pacchetti devono essere filtrati, in quanto sono utilizzati per modificare la tabella di routing, ciò può consentire a qualcuno di redirigere il traffico della propria rete. Possono essere utilizzati anche per attacchi DoS. ICMP tipo 8 - Echo Request (ping) Questo pacchetto ICMP è utilizzato per verificare se una macchina è presente nella rete o per effettuare dei test. In molti casi si preferisce filtrare e limitare i ping provenienti dall'esterno. Con iptables è possibile comunque accettarli e utilizzare '-m limit' per evitare attacchi DoS. ICMP tipo 11 - Time Exceeded in Transit Nell'intestazione IP è presente un campo TTL (Time To Live) utilizzato come un vero e proprio contatore. Questo contatore misura il "tempo da vivere" che ha un pacchetto ed è decrementato in pratica ad ogni salto da un router all'altro. Lo scopo è quello di impedire che un pacchetto possa viaggiare nella rete per un tempo indeterminato. Se un router riceve un pacchetto con il campo TTL uguale a 0 provvederà a scartarlo e ad inviare un pacchetto ICMP TTL Exceeded (codice 0) alla macchina che lo ha inviato. Altro caso si ha quando un host non è in grado di assemblare i frammenti di un pacchetto entro il TTL, anche in questo caso il pacchetto è scartato e un ICMP Fragment reassembly timeout (codice 1) è inviato alla macchina mittente. Un programma noto che utilizza questi pacchetti è 'traceroute'. In genere non è filtrato. Il codice associato può essere quindi uno dei seguenti:

0 TTL Exceeded 1 Fragment reassembly timeout

ICMP tipo 12 - Parameter Problem Se un router o un host dovessero ricevere un pacchetto con qualche problema riguardante i parametri delle intestazioni, ad esempio argomenti non corretti presenti nelle opzioni, potrebbero decidere di scartarlo e di inviare un pacchetto ICMP Parameter Problem all'host che lo ha inviato. In alcuni casi può essere indicatore di un attacco. In genere non è filtrato.

Se si utilizza il connection tracking e il modulo 'state' non è necessario preoccuparsi di questi pacchetti. In caso contrario è necessario filtrarli, a questo scopo è possibile creare una catena apposita che accetti solo i tipi che non rappresentano un pericolo o che sono indispensabili:

iptables -N icmp-accept iptables -A icmp-accept -p icmp --icmp-type destination-unreachable -j ACCEPT iptables -A icmp-accept -p icmp --icmp-type source-quence -j ACCEPT iptables -A icmp-accept -p icmp --icmp-type time-exceeded -j ACCEPT iptables -A icmp-accept -p icmp --icmp-type parameter-problem -j ACCEPT NOTA: deve precede le regole che utilizzano -j DROP/REJECT e anche -j LOG se presente es.: ... iptables -A INPUT -j icmp-accept iptables -A INPUT -j LOG --log-level info iptables -A INPUT -j DROP

Per quanto riguarda ping (echo-request) e pong (echo-reply) si preferisce specificarli separatamente in base alla catena e alle proprie scelte.

Masquerading, port forwarding Masquerading

Il mascheramento (masquerading) è una tecnica con cui il primo pacchetto di una connessione provenienti dalla rete locale e diretto verso ad esempio internet, subisce da parte del firewall una modifica del campo source address (indirizzo sorgente) presente nell'intestazione IP, in modo che il pacchetto e i successivi sembreranno provenire dal firewall e non dalla macchina della rete locale, nascondendone così l'esistenza.

Questa tecnica si utilizza in quanto spesso si possiede un unico indirizzo IP statico (registrato), ma si desidera utilizzarlo con tutte le macchine della propria rete locale ad esempio per collegarsi ad internet. Senza il mascheramento ciò non sarebbe possibile, bisognerebbe infatti registrare un indirizzo statico per ogni macchina della propria rete locale (scomodo e costoso).

+---+ 192.168.1.5 |PC1|----+ +---+ | | +---+ | +---+ |MAC|----+-------| |-MASQ--+ INTERNET +---+ | +---+ | 151.99.180.5 +---+ | |PC2|----+ +---+ LAN Linux box Internet [ firewall ]

Nell'esempio supponiamo che la macchina PC1 voglia iniziare una connessione con www.kernelnotes.org, quindi invierà un pacchetto che avrà nell'intestazione le seguenti informazioni:

indirizzo IP sorgente 192.168.1.5 (indirizzo di PC1) indirizzo IP destinazione 192.130.8.25 (ossia www.kernelnotes.org) +---+ +---+ +---+ |PC1| --->|FW | |KER| +---+ +---+ +---+ [firewall]

Quando il pacchetto giunge al firewall, se abbiamo impostato una regola di mascheramento l'intestazione del pacchetto subirà la seguente modifica:

indirizzo IP sorgente 151.99.180.5 (indirizzo IP del firewall) indirizzo IP destinazione 192.130.8.25 (www.kernelnotes.org) +---+ +---+ +---+ |PC1| |FW | --->|KER| +---+ +---+ +---+ [firewall]

E quindi verrà spedito nella rete. Nota che quando arriverà da www.kernelnotes.org il pacchetto di risposta, questo avrà nell'intestazione le seguenti informazioni:

indirizzo IP sorgente 192.130.8.25 (www.kernelnotes.org) indirizzo IP destinazione 151.99.180.5 (indirizzo IP del firewall) +---+ +---+ +---+ |PC1| |FW |<--- |KER| +---+ +---+ +---+ [firewall]

A questo punto si nota che il pacchetto è destinato al firewall, ma in realtà deve arrivare a PC1! Nessun problema in quanto il firewall tiene traccia dei pacchetti inviati e mascherati, quando arriva il pacchetto di risposta, il firewall provvederà automaticamente a identificarlo, a modificare l'intestazione e a inviarlo a PC1, in questo modo tutto funziona correttamente.

Gran parte del lavoro viene effettuato da netfilter e dai moduli, in modo trasparente all'utente.

Port-forwarding, load-balancing, proxy trasparente

In molti casi invece si ha la necessità di cambiare dove i pacchetti sono destinati, ad esempio potremmo creare una rete con diversi server tra cui uno web e uno mail.

+---+ |PC1|----+ +---+ | | Linux box +---+ | +---+ |MAC|----+-------|PC0|---------- INTERNET +---+ | +---+ | | +---+ | | +---+ |PC2|----+ +-|WWW| +---+ | +---+ | +----+ +-|MAIL| +----+ LAN SERVERS Internet [rete locale]

Come abbiamo visto abbiamo un solo indirizzo statico (151.99.180.5) ora però vogliamo che dall'esterno i nostri utenti possano accedere al nostro WWW server, in questo caso tutti i pacchetti saranno destinati al firewall (PC0), che dovrà quindi dirottarli rispettivamente al WWW server, se sono pacchetti www, o al server MAIL se sono pacchetti smtp.

Per ottenere ciò è necessario che il firewall modifichi l'indirizzo di destinazione dei pacchetti con quello del server corrispondente.

+---+ |PC1|----+ +-- + | | Linux box +---+ | +---+<========= |MAC|----+-------|PC0|---------- INTERNET +---+ | +---+ | !! | +---+ | !! | +---+ |PC2|----+ !>>+-|WWW| +---+ | +---+ | +----+ +-|MAIL| +----+ LAN SERVERS Internet [rete locale]

In altri casi si può desiderare di distribuire il traffico web su diversi server WWW (load-balancing), in altri ancora semplicemente inviare i pacchetti su porte differenti (proxy trasparente). Tutte queste operazioni richiedono la modifica dell'indirizzo destinazione dei pacchetti, che con netfilter si realizzano utilizzando l'obiettivo DNAT.

FTP Descrizione

Il protocollo FTP (File Trasfert Protocol) è un protocollo molto noto e utilizzato che consente di trasferire file da una macchina ad un'altra.

Per effettuare operazioni FTP sono disponibili due modalità: attiva e passiva.

La modalità attiva in particolare è nota per i problemi che crea a chi deve impostare un firewall a protezione ad esempio di una rete locale.

Il protocollo FTP richiede che inizialmente sia comunque stabilita una connessione FTP, indipendentemente dal tipo (passiva o attiva), tra il client e il server. Questo avviene attraverso una richiesta inviata dal client alla porta 21 (FTP) del server, il quale se disponibile accetterà la connessione. Quindi nel nostro caso il firewall dovrà accettare le richieste inviate da un computer della rete locale (client) ad un server presente nella rete esterna.

+---+ ...... |PC1|----+ . +---+ | . | . +---+ | ....> +---+ .......................> +---+ |MAC|----+-------|PC0|---------- INTERNET ----- | | +---+ | +---+ +---+ . LAN Linux Box Internet Server FTP [rete locale]

In questo caso non ci sono grossi problemi, se usiamo iptables possiamo utilizzare:

# -------------------------------------------------------------------------------- # Appendiamo una regola che accetti tutti i pacchetti provenienti dalla rete locale # (LAN) e destinati alla porta ftp # -------------------------------------------------------------------------------- iptables -A FORWARD -s $LAN -p tcp --dport ftp -j ACCEPT # Appendiamo una regola che accetti tutti i pacchetti provenienti da un computer presente nella rete internet # con porta sorgente ftp e che non siano di richiesta connessione iptables -A FORWARD -s $INTERNET -p tcp ! --syn --sport ftp -j ACCEPT

NOTA: è importante impedire che dall'esterno qualcuno cerchi di effettuare connessioni con le macchine della LAN. In genere le macchine della rete locale non dovrebbero offrire alcun servizio (FTP, telnet, mail, ...) all'esterno. Ciò si può realizzare utilizzando l'opzione ! --syn, ossia non accettando pacchetti con il flag SYN (richiesta connessione) impostato.

A questo punto è necessario stabilire una seconda connessione, quella che si occuperà dello scambio dei dati. E' possibile utilizzare sia una connessione attiva sia passiva come detto.

La modalità attiva crea grossi problemi in quanto è il client a stabilire indirizzo e porta su cui deve avvenire la trasmissione dei dati e ad inviare un pacchetto con queste informazioni e il comando PORT al server.

Questa situazione richiede che il server accetti e stabilisca una connessione con il client, solo che se il client è protetto da un firewall, quest'ultimo in genere rifiuta (e deve rifiutare!) questo tipo di connessioni dall'esterno verso l'interno, oltretutto effettuate su una porta qualsiasi. Ciò richiederebbe al firewall di aprire una grossa falla, ossia praticamente accettare tutte le richieste connessioni provenienti dall'esterno.

+---+ |PC1|----+ +---------- il pacchetto viene scartato (DROP) +---+ | | | V +---+ | +---+X<...................... +---+ |MAC|----+-------|PC0|---------- INTERNET ----- | | +---+ | +---+ +---+ . LAN Linux Box Internet Server FTP [rete locale]

Nel caso della modalità passiva la situazione è esattamente il contrario, il client invia un pacchetto contenente il comando PASV, e poi è il server a inviare al client indirizzo IP e porta per la connessione. Questa situazione è quindi molto simile alla connessione ftp vista all'inizio. Il client si può così connettere.

Il firewall non crea problemi, la connessione viene stabilita e i dati sono scambiati.

In alcuni casi si noterà che la modalità attiva utilizza esclusivamente la porta 20 (ftp-data), questa modifica è stata introdotta da non molto tempo, quindi alcuni server potrebbero non accettarla.

In questo caso il meccanismo è lo stesso del caso descritto prima solo che la porta sorgente utilizzata è la porta 20, ciò permette di identificare i pacchetti ftp-data e di ridurre i rischi.

# -------------------------------------------------------------------------------- # In questo caso i pacchetti provenienti dall'esterno hanno la porta sorgente # impostata a 20 (ftp-data) ciò permette di facilitare al firewall il riconoscimento. # 1024: indica una porta alta (compresa tra 1024 e 65535). # -------------------------------------------------------------------------------- iptables -A FORWARD -s $INTERNET -p tcp --sport ftp-data -d $LAN --dport 1024: -j ACCEPT iptables -A FORWARD -s $LAN -p tcp ! --syn --sport 1024: -d $INTERNET --dport ftp-data -j ACCEPT

NOTA: in questo caso non è possibile utilizzare nella seconda linea l'opzione '--syn', in quanto la connessione è stabilita dal server.

Se possibile comunque è meglio utilizzare la modalità passiva, altrimenti è necessario caricare il modulo 'ip_conntrack_ftp.o' (usa insmod ip_conntrack_ftp) il quale si occuperà di cercare nel pacchetto eventuali comandi PORT e quindi ad aggiungere e riscrivere le informazioni in modo che tutto funzioni nel modo corretto. Se si utilizza inoltre il masquerading è necessario caricare anche il modulo 'ip_nat_ftp.o'.

Ecco un esempio di come impostare una connessione ftp data passiva:

# -------------------------------------------------------------------------------- # La connessione è stabilita da una macchina della rete locale. # Le porte scelte sono due porte alte. # -------------------------------------------------------------------------------- iptables -A FORWARD -s $LAN -p tcp --sport 1024: -d $INTERNET --dport 1024: -j ACCEPT iptables -A FORWARD -s $INTERNET -p tcp ! --syn --sport 1024: -d $LAN --dport 1024: -j ACCEPT

NOTA: i browser MSIE, Netscape, Mozilla utilizzano la modalità passiva, quindi non dovrebbero esserci problemi. Altri programmi come quelli a riga di comando (es. ftp) e win utilizzano spesso la modalità attiva per default ma supportano anche la modalità passiva. Il programma ftp di Linux ad esempio usa la modalità attiva, per passare a quella passiva utilizzare:

# ftp ftp> passive Passive mode on. ftp> o (o) ...

E' necessario segnalare inoltre che alcuni server, in genere pochi e molto vecchi, non supportano la modalità passiva.

Esempi

Esempio 1

Supponiamo che la nostra macchina appartenga ad una LAN e che la vogliamo più sicura, inoltre utilizziamo per comodità il connection tracking.

modprobe ip_conntrack_ftp modprobe ip_nat_ftp iptables -A FORWARD -j REJECT # -------------------------------------------------------------------------------- # prima di tutto dobbiamo accettare e far passare i pacchetti destinati alla porta ftp (indispensabile) # -------------------------------------------------------------------------------- iptables -A OUTPUT -p tcp --sport 1024: --dport ftp -j ACCEPT # -------------------------------------------------------------------------------- # modalità attiva utilizzando ftp-data # -------------------------------------------------------------------------------- iptables -A OUTPUT -p tcp --sport 1024: --dport ftp-data -j ACCEPT # -------------------------------------------------------------------------------- # modalità passiva # -------------------------------------------------------------------------------- iptables -A OUTPUT -p tcp --sport 1024: --dport 1024: -j ACCEPT # -------------------------------------------------------------------------------- # altro (es. www, telnet ...) # -------------------------------------------------------------------------------- # ... # -------------------------------------------------------------------------------- # Il resto invece sarà scartato # -------------------------------------------------------------------------------- iptables -A OUTPUT -j REJECT # -------------------------------------------------------------------------------- # se il pacchetto appartiene ad una connessione stabilita (ESTABLISHED) o comunque relativa (RELATED) # allora pacchetto accettato. # -------------------------------------------------------------------------------- iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT # -------------------------------------------------------------------------------- # altrimenti registriamo i dati di questo pacchetto nel file di log e ... # -------------------------------------------------------------------------------- iptables -A INPUT -j LOG --log-level info --log-prefix "FIREWALL (INPUT): " # -------------------------------------------------------------------------------- # ... rifiutiamolo # -------------------------------------------------------------------------------- iptables -A INPUT -j REJECT

DoS (Denial of Service) Introduzione

Gli attacchi di tipo DoS (Denial of Service) sono differenti rispetto ai precedenti (IP spoofing, ...) in quanto l'obiettivo non è più quello di ottenere l'accesso ad una rete, ma bensì di rendere un servizio (www, ftp, mail, ...) offerto da una macchina indisponibile agli utenti, utilizzando diverse tecniche.

Le principali consistono nell'esaurire le risorse della macchina, in particolare memoria e spazio su disco fino a causarne addirittura il blocco, oppure nel consumare la bandwidth a disposizione in modo che la "vittima" non sia più in grado di operare correttamente, di stabilire o accettare nuove connessioni, di inviare pacchetti nella rete.

Questi attacchi possono quindi sfruttare i difetti e limiti delle implementazioni dello stack TCP/IP, oppure il meccanismo di inizio connessione (3-way handshake), o ancora macchine configurate male. In molti casi per risolvere il problema di alcuni di questi attacchi è stato necessario correggere lo stack TCP/IP, e ricercare vulnerabilità simili.

Per realizzare attacchi DoS viene spesso coinvolto anche l'IP spoofing, quindi come primo passo per prevenire i DoS è senz'altro raccomandato bloccare questo attacco.

In alcuni casi è possibile effettuare un attacco DoS perfino utilizzando un vecchio Pc dotato di un modem lento contrapponendolo ad una macchina o rete veloce. Questo tipo di attacco è noto come attacco asimmetrico.

Tra i DoS più noti ci sono: TCP SYN flooding, smurfing, UDP port.

Molto recenti sono inoltre gli attacchi cosiddetti DDoS (Distributed Denial of Service). Questo tipo di attacco ha le stesse funzioni del classico DoS solamente che l'attacco viene effettuato sfruttando più macchine. In questo modo il traffico che si può generare è talmente notevole da poter mettere in difficoltà anche grandi nomi come Yahoo, Amazon, ... che dispongono di notevoli risorse.

Per effettuare un DDoS è necessario comunque impossessarsi di diverse macchine della rete, in genere non è difficile trovare macchine/server configurate male da "conquistare". Successivamente l'attacker provvederà ad installare dei programmi, spesso troiani, che permetteranno di nasconderne la presenza, e quindi il programmma che controllato da remoto permetterà di sferrare l'attacco. Questa è sicuramente la fase più complicata.

Questi attacchi sono notevoli e difficilmente contrastabili, tra le poche soluzioni c'è sicuramente quella di migliorare la sicurezza delle macchine presenti in internet, in modo che non possano essere conquistate e utilizzate per questi attacchi.

TCP SYN Flooding

Questo attacco riguarda in particolare i protocolli IP+TCP e ancora una volta è la fase di inizio connessione ad essere presa di mira. In particolare lo scopo non è quello di accedere ad una macchina ma piuttosto quello di esaurire e consumare la banda a disposizione della macchina "vittima" in modo che non riesca più a soddisfare le richieste di connessione ai servizi (www, ftp, ...) effettuate dagli utenti e ad operare correttamente.

Come già descritto quando un utente vuole stabilire una connessione con una macchina deve inviare un pacchetto con flag SYN impostato.

Il server riceve la richiesta e inoltra un pacchetto SYN-ACK in risposta allocando inoltre spazio in memoria dove poter memorizzare le informazioni sulla connessione. A questo punto attende il pacchetto ACK di conferma.

L'attacker però non invia questo pacchetto lasciando volontariamente la connessione pendente (half-open connection), e anzi continua a inviare a raffica una moltitudine di pacchetti di inizio connessione (SYN). Il server li riceverà e allocherà per ciascuno di essi altra memoria. In molti casi questa situazione porterà il server ad esaurire la memoria, a non poter soddisfare altre richieste di connessione, e addirittura al crash.

E' necessario specificare che in genere un server o una qualsiasi macchina che offre dei servizi accetta solo un determinato numero di richieste connessione, di solito 5 per porta, inoltre se un pacchetto di ACK non arriva entro un certo limite di tempo allora le connessioni pendenti sono annullate e lo spazio di memoria allocato recuperato. Ciò però potrebbe non essere sufficiente se i pacchetti dovessero arrivare a raffica in un brevissimo lasso di tempo.

Questo attacco è diffuso e in genere è utilizzato anche l'IP spoofing per nascondere l'origine dell'attacco. Linux è in grado di contrastarlo però è necessario compilare il kernel con la voce "IP: TCP syncookie support" (Networking options) selezionata e impostare il parametro tcp_syncookies da script o linea di comando:

if [ -e /proc/sys/net/ipv4/tcp_syncookies ] then echo 1 > /proc/sys/net/ipv4/tcp_syncookies fi

Smurfing

Lo smurfing è un altro attacco DoS basato sempre sull'IP spoofing e sui pacchetti ICMP ping, utilizzati in genere per verificare se una macchina è presente e attiva nella rete.

Questo attacco consiste nell'inviare un pacchetto ICMP echo request (ping) con indirizzo sorgente fasullo e con indirizzo destinazione l'indirizzo broadcast di una rete. L'indirizzo broadcast è utilizzato per inviare un pacchetto contemporaneamente a tutte le macchine di una rete, ad esempio per una rete 192.168.0.0/24 l'indirizzo di broadcast corrisponde a 192.168.0.255, per una rete 192.168.0.0/16 a 192.168.255.255. Graficamente si può rappresentare in questo modo:

+---+ +---+ |PC1|-<<. | | [ATTACKER] +---+ ^ +---+ +---+ ^ 213.76.5.2 |PC2|-<<. +---+ | +---+ |<<<<<| | <---- o -----. +---+ v +---+ \_______________________ pacchetto ping "broadcast" |PC3|-<<. [ROUTER] +---+ +---+ v | | [VITTIMA] +---+ v +---+ |PC4|-<<. 213.72.10.1 +---+ [LAN]

Il pacchetto ICMP echo request (ping), con indirizzo destinazione l'indirizzo broadcast, è ricevuto dal router che provvede quindi a inoltrarlo a tutte le macchine della rete che in genere risponderanno inviando un pacchetto echo reply (pong) alla macchina mittente.

In questo caso i pong arriveranno alla macchina "vittima", con indirizzo IP pari a quello indicato dall'attacker nel pacchetto. Se la banda a disposizione della vittima dovesse essere limitata questo flusso di pacchetti potrebbe consumarla rapidamente, impedendo quindi alla macchina di stabilire connessioni e di operare correttamente.

+---+>>>>>. +---+ |PC1|---+ v | | [ATTACKER] +---+ | v +---+ +---+>>>>>. 213.76.5.2 |PC2|---+ v +---+ +---+ |_v_>>>>>| |>>>>>>>>>>>>>>. +---+>>>>>. +---+ v |PC3|---+ ^ [ROUTER] +---+ +---+ | ^ | | [VITTIMA] +---+>>>>>. +---+ |PC4|---+ 213.72.10.1 +---+ [LAN]

In questo caso la soluzione per proteggere la propria rete da questo attacco richiede di impostare il ROUTER affinché ignori, scarti i pacchetti IP broadcast, ossia aventi come indirizzo destinazione l'indirizzo broadcast della propria rete. Per quanto riguarda le macchine della rete locale è consigliato impostarle in modo che non rispondano a pacchetti ICMP echo request (ping) aventi come indirizzo destinazione l'indirizzo broascast.

Quest'ultimo caso è importante perché se un attacker riesce ad accedere ad una delle macchine della rete locale è in grado di aggirare il router e di utilizzare un attacco smurf dall'interno.

Con Linux è disponibile il parametro 'icmp_ignore_echo_broadcast' che può essere impostato per ignorare gli icmp echo request (ping) broadcast.

Per quanto riguarda il firewall, se si usa il connection tracking ('-m state -state ESTABLISHED,RELATED') questo tipo di attacco proveniente dall'esterno è respinto.

In caso contrario è meglio scartare specificatamente questi pacchetti:

## Caso di pacchetti icmp echo-request (ping) # iptables -A FORWARD -i eth0 -p icmp -icmp-type ping -d 255.255.255.255 -j DROP

UDP Port DoS

Esistono attacchi DoS che utilizzano anche il protocollo UDP (User Datagram Protocol).

In questo caso quando due macchine trasmettono dati utilizzando due servizi UDP che generano entrambe dell'output (es. chargen ed echo) possono generare un traffico così notevole da causare una situazione di DoS.

In genere sono proprio i servizi chargen ed echo ad essere utilizzati per questo attacco, quindi se possibile è raccomandabile disabilitarli modificando il file /etc/inetd.conf nelle macchine della propria rete locale e impostare il firewall in modo che questi servizi siano filtrati.

E' inoltre raccomandato disabilitare, filtrare allo stesso modo tutti i servizi UDP che non sono necessari o utilizzati.

LOG

In genere può essere utile registrare le informazioni riguardanti quei pacchetti che si ritengono anomali.

Netfilter e iptables permettono di registrare queste informazioni utilizzando l'obiettivo LOG (-j LOG). I pacchetti che soddisferanno la regola saranno registrati per poter essere poi analizzati. Il problema che può però sorgere è che qualcuno potrebbe intenzionalmente inviare una raffica di pacchetti affinchè siano registrati. Siccome le registrazioni richiedono spazio su disco, infatti in genere sono memorizzati nel file /var/log/messages, potrebbero essere usate per un attacco DoS, mirato a esaurire lo spazio disponibile.

In questo caso è raccomandato utilizzare assieme a LOG anche il modulo limit, che consente di specificare quante registrazioni effettuare in un dato arco di tempo (es. 10 registrazioni ogni ora).

# -------------------------------------------------------------------------------- # connessioni telnet accettate # -------------------------------------------------------------------------------- iptables -A INPUT -p tcp -dport telnet -j ACCEPT # -------------------------------------------------------------------------------- # tutto gli altri pacchetti sono registrati (10 pacchetti ogni ora) e ... # -------------------------------------------------------------------------------- iptables -A INPUT -m limit -limit 10/h -j LOG -log-level info -log-prefix "Firewall: " # -------------------------------------------------------------------------------- # ... scartati # -------------------------------------------------------------------------------- iptables -A INPUT -j DROP

Nessus e nmap Introduzione

Per effettuare un controllo sul grado di sicurezza e affidabilità della propria rete è possibile utilizzare i programmi Nessus e nmap.

nmap

Nmap è un'utility per l'esplorazione e l'auditing della propria rete. Disponibile per quasi tutte i sistemi UNIX (Linux, FreeBSD, NetBSD, OpenBSD, Solaris ...) attualmente non ne esiste una versione per Windows.

Supporta ping scanning (determina quali host sono attivi), diverse tecniche di port scanning (determinano quali servizi offrono gli host presenti nella rete) e TCP/IP fingerprinting (identificazione del sistema operativo utilizzato dall'host remoto). Inoltre offre specificazione delle porte, obiettivi flessibili, decoy scanning, sunRPC scanning, reverse-identd scanning, ... E' disponibile sia in versione per X sia per terminale (Nmap). In particolare per X esistono due front-end grafici:

NmapFE - usa la libreria GTK+ (GNOME) kmap - usa la libreria qt (KDE)

Nominato "Security Product of the Year" dalla Info World e Codetalker Digest.

Dove si trova ?

nmap è reperibile alla pagina . Nel momento in cui scrivo sono disponibili, sia in formato tgz che rpm, la versione stabile 2.53 e la beta 1 della nuova versione 2.54.

Installazione

Per installare il formato tarball (.tgz) e necessario eseguire i seguenti comandi:

# gzip -cd nmap-VERSION.tgz | tar -xvf # NOTA: al posto di VERSION inserire la versione di nmap utilizzata es. nmap-2.53.tgz # cd nmap-VERSION # ./configure # make # su root # make install

Per installare la versione x86/rpm utilizzare:

# rpm -vhU ftp://ftp.server51.freshmeat.net/pub/nmap/nmap-2.53-1.rpm # rpm -vhU ftp://ftp.server51.freshmeat.net/pub/nmap/nmap-frontend-0.2.53-1.i386.rpm Nota: il primo comando installa nmap, la seconda installa l'interfaccia grafica che fa uso di X e della libreria GTK+.

Esecuzione

Per eseguire un semplice test sulla propria macchina utilizzare il comando da terminale:

# nmap -v -sS -O 127.0.0.1 Starting nmap V. 2.30BETA17 by fyodor@insecure.org ( www.insecure.org/nmap/ ) Host localhost.localdomain (127.0.0.1) appears to be up ... good. Initiating SYN half-open stealth scan against localhost.localdomain (127.0.0.1) Adding TCP port 21 (state Open). Adding TCP port 514 (state Open). Adding TCP port 513 (state Open). Adding TCP port 98 (state Open). Adding TCP port 23 (state Open). Adding TCP port 79 (state Open). Adding TCP port 113 (state Open). Adding TCP port 6000 (state Open). The SYN scan took 180 seconds to scan 1517 ports. For OSScan assuming that port 21 is open and port 30938 is closed and neither are firewalled sendto in send_tcp_raw: sendto(3, packet, 60, 0, 127.0.0.1, 16) => Operazione non permessa For OSScan assuming that port 21 is open and port 32223 is closed and neither are firewalled sendto in send_tcp_raw: sendto(3, packet, 60, 0, 127.0.0.1, 16) => Operazione non permessa For OSScan assuming that port 21 is open and port 40569 is closed and neither are firewalled sendto in send_tcp_raw: sendto(3, packet, 60, 0, 127.0.0.1, 16) => Operazione non permessa Interesting ports on localhost.localdomain (127.0.0.1): (Ports scanned but not shown below are in state: filtered) Port State Service 21/tcp open ftp 23/tcp open telnet 79/tcp open finger 98/tcp open linuxconf 113/tcp open auth 513/tcp open login 514/tcp open shell 6000/tcp open X11 TCP Sequence Prediction: Class=random positive increments Difficulty=750295 (Good luck!) Sequence numbers: 6B85B59E 6B85B59E 6B6DA5EE 6B6DA5EE 6B844A25 6B844A25 No OS matches for host (If you know what OS is running on it, see http://www.insecure.org/cgi-bin/nmap-submit.cgi). TCP/IP fingerprint: TSeq(Class=RI%gcd=1%SI=B69A5) TSeq(Class=RI%gcd=1%SI=B72D1) TSeq(Class=RI%gcd=1%SI=B72D7) T1(Resp=Y%DF=Y%W=2D24%ACK=S++%Flags=AS%Ops=MNNTNW) T2(Resp=N) T3(Resp=Y%DF=Y%W=2D24%ACK=S++%Flags=AS%Ops=MNNTNW) T4(Resp=Y%DF=Y%W=0%ACK=O%Flags=R%Ops=) T5(Resp=Y%DF=Y%W=0%ACK=S++%Flags=AR%Ops=) T6(Resp=Y%DF=Y%W=0%ACK=O%Flags=R%Ops=) T7(Resp=Y%DF=Y%W=0%ACK=S++%Flags=AR%Ops=) PU(Resp=Y%DF=Y%TOS=C0%IPLEN=164%RIPTL=148%RID=E%RIPCK=E%UCK=E%ULEN=134%DAT=E)

Documentazione

La documentazione di nmap si trova sempre al sito citato precedentemente sono disponibili la man page (formato HTML), un articolo su nmap e il port scanning e una guida.

Nessus

Nessus è un progetto che ha come scopo quello di fornire alla comunità uno strumento potente, facile, free per analizzare e scoprire le vulnerabilità di una rete.

Nessus è composto da due parti: un server (nessusd) e un client (nessus). Per il corretto funzionamento è necessario installarli entrambi. Il suo funzionamento è semplice, attraverso il client (nessus) è possibile impostare gli host (computer) della rete da sottoporre ai test, quali e che tipo di test effettuare, oltre ad altre opzioni (es. dove salvare i risultati, in quale formato, ...). Il client (nessus) una volta ricevute queste informazioni contatta il server nessusd che si occuperà di effettuare i vari test selezionati. Il client (nessus) e il server (nessusd) possono essere installati nella stessa macchina oppure su macchine diverse. Esistono inoltre client grafici per Windows, Posix/GTK+ (Linux, Solaris, ...) e JAVA.

Dove si trova ?

Nessus è reperibile all'indirizzo , esiste anche un sito dedicato in italiano all'indirizzo url="http://www.it.nessus.org" "name="www.it.nessus.org.">. Sono presenti due link per Windows e Java, questi link permetteno di prelevare i rispettivi CLIENT grafici. Non sono invece disponibile per questi sistemi il server nessusd, è necessario per forza usare Linux o altro sistema Unix.

E' raccomandato inoltre installare anche nmap in quanto Nessus è in grado di rilevarne la presenza e di utilizzarlo per effettuare ulteriori controlli.

Per Linux, FreeBSD, Solaris selezionare il link Posix download page quindi se si ha una distribuzione Linux che supporta il formato rpm prelevare il file .rpm da uno dei siti ftp indicati, altrimenti prelevare i tarball (sempre da uno dei siti ftp indicati):

libsnal-1.0.3.tar.gz (218Kb) nessus-core-1.0.3.tar.gz (497Kb) nessus-libraries-1.0.3.tar.gz (1512Kb) nessus-plugins-1.0.3.tar.gz (365Kb)

L'installazione dei pacchetti .rpm è semplice e rapida, mentre per installare i tarball è necessario un po' di lavoro in più. Prima di tutto si devono scompattare i file:

tar -zxvf nessus-libraries-x.x.tar.gz tar -zxvf libsnal-x.x.tar.gz tar -zxvf nessus-core.x.x.tar.gz tar -zxvf nessus-plugins.x.x.tar.gz

Poi ci si deve assicurare che nel PATH sia presente /usr/local/bin altrimenti usare il comando:

# export PATH=$PATH:/usr/local/bin

Altro passo necessario è verificare che /usr/local/lib sia presente nel file /etc/ld.so.conf, altrimenti impartire i seguenti comandi:

# echo "/usr/local/lib" >> /etc/ld.so.conf # ldconfig

nessus-libraries

Completate le fasi precedenti è necessario compilare i sorgenti cominciando da nessus-libraries. Nota: se si pensa di utilizzare i client grafici di Windows o Java allora non si avrà bisogno del cypher quindi si potranno usare i seguenti comandi:

# cd nessus-libraries # ./configure --disable-cipher # make # make install

Altrimenti, se si desidera utilizzare esclusivamente Linux, usare:

# cd nessus-libraries # ./configure # make # make install

Il passo successivo è quello di compilare libnasl:

cd nessus-libnasl # ./configure # make # make install

nessus-core

A questo punto è necessario accedere alla directory nessus-core e poi specificare se si intende utilizzare l'interfaccia grafica (richiede la libreria GTK+ e X!) o il terminale.

Se la libreria GTK+ è installata (se GNOME o gimp sono installati l'avete) potete usare i seguenti comandi:

cd nessus-core # ./configure # make # make install

Altrimenti è sempre possibile utilizzare nessus dalla linea comando del terminale:

cd nessus-core # ./configure --disable-gtk # make # make install

nessus-plugins

Infine compilare nessus-plugins:

cd nessus-plugins # ./configure # make # make install

A questo punto se tutto è stato eseguito correttamente dovrebbero essere presenti nella directory /usr/local/bin i seguenti comandi: nasl, nasl-config, nessus, nessus-build, nessus-config. Se non c'è nessus allora è stato sbagliato qualcosa, ripetere la compilazione di nessus-core e fare attenzione al messaggio visualizzato alla fine.

Il passo successivo consiste nel configurare nessusd, a questo scopo è necessario impostare il file /usr/local/etc/nessus/nessusd.conf. Se si hanno dei dubbi è possibile leggere e prelevare il file nessusd.conf.txt all'indirizzo

Non resta quindi che aggiungere un utente con il comando:

# nessus-adduser

E avviare il server nessusd:

# nessusd -D

A questo punto si può eseguire un client windows, java oppure se si usa Linux e X il comando:

# nessus

Se si è compilato con l'opzione --disable-gtk allora è necessario innanzi tutto leggere l'help:

# nessus --help

L'help è abbastanza chiaro, comunque un esempio di utilizzo può essere il seguente:

# nessus 192.168.0.154 3001 marco myhosts.txt result.txt Nota: 192.168.0.154 è l'indirizzo della macchina che esegue nessusd 3001 è la porta di default usata da nessusd per i test marco è il nome dell'utente che ho creato precedentemente myhosts.txt è un file di testo in cui ho inserito gli indirizzi IP delle macchine da sottoporre ai test result.txt è il file in cui voglio che siano memorizzati i risultati dei test

Se si desidera che il file con i risultati sia in formato html è possibile specificare l'opzione '-T html'. Altri formati disponibili sono: text, tex, nsr.

Segue un esempio di output (html) ottenuto:

127.0.0.1 Repartition of the level of the security problems : [Back to the index] List of open ports : ftp (21/tcp) telnet (23/tcp) finger (79/tcp) linuxconf (98/tcp) (Security warnings found) auth (113/tcp) login (513/tcp) shell (514/tcp) printer (515/tcp) unknown (1027/tcp) unknown (1032/tcp) unknown (1033/tcp) unknown (1035/tcp) unknown (1036/tcp) unknown (3001/tcp) unknown (6000/tcp) general/tcp (Security notes found) general/udp (Security notes found) [ back to the list of ports ] Warning found on port linuxconf (98/tcp) Linuxconf is running on this port [ back to the list of ports ] Information found on port general/tcp Nmap found that this host is running Linux 2.1.122 - 2.2.14 [ back to the list of ports ] Information found on port general/udp For your information, here is the traceroute to 127.0.0.1 : 127.0.0.1 This file was generated by Nessus, the open-sourced security scanner.

Per ulteriori informazioni vedere

Per selezionare i plugin e apportare altre modifiche riguardanti il funzionamento del programma nessus, modificare il file '.nessusrc'.

Sono disponibili inoltre numerosi script in grado di effettuare altri controlli riguardanti la sicurezza. E' possibile reperirli alla pagina . Dopo il download è sufficiente copiarli nella directory /usr/local/lib/nessus/plugins/ o quella usata (vedi nessusd.conf), quindi riavviare nessusd. Se il file ha suffisso .tar.gz è necessario "scompattare" il file nella directory sopra indicata.

Esiste anche un metodo più semplice per scaricarli e installarli, ossia eseguire il programma (da root):

nessus-update-plugins

Documentazione

La documentazione di Nessus è reperibile all'indirizzo sono disponibili istruzioni su come effettuare l'installazione, pagine dimostrative con immagini, una FAQ, le man pages e altro.

Risorse

Per scrivere questo documento ho trovato di notevole interesse i seguenti siti:

(pmfirewall) (FAQ)

Marchi registrati

Tutti i marchi sono registrati. Linux è un marchio registrato di Linus Torvalds. MS-DOS, Windows NT sono marchi registrati di Microsoft Corporation. Apple e MacOS sono marchi registrati da Apple Computer Inc.

Appendice Intestazione IP (Internet Protocol)

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 ----------------------------------------------------------------- |Version| IHL |Type of Service| Total Length | ----------------------------------------------------------------- | Identification |Flags| Fragment Offset | ----------------------------------------------------------------- | Time to Live | Protocol | Header Checksum | ----------------------------------------------------------------- | Source Address | ----------------------------------------------------------------- | Destination Address | ----------------------------------------------------------------- | Options | Padding | -----------------------------------------------------------------

Version Versione del protocollo utilizzata. Attualmente è utilizzato l'IPv4 è comunque già disponibile anche la versione più recente dell'internet protocol (IPv6). IHL Lunghezza dell'intestazione espressa in parole di 32 bit. Type of Service (TOS) Consente di specificare il tipo di servizio desiderato (ritardo minimo, massimo throughput, massima affidabilità, costo minimo). In particolare contiene 3 bit per indicare la precedenza (Precedence), 3 flag (D, T ed R), e 2 bit inutilizzati. Total length Lunghezza totale del pacchetto (intestazioni e dati). La lunghezza massima prevista è di 65535 byte. Identification Questo campo permette di stabilire a quale pacchetto appartiene il frammento arrivato. In caso di frammentazione solo il primo frammento ha sia l'intestazione IP sia l'intestazione UDP o TCP, il secondo e i successivi hanno solo l'intestazione IP. Flags Il campo flags è composto da 3 bit, il primo è inutilizzato, il secondo detto DF (Don't Fragment) se impostato serve a segnalare di non frammentare i pacchetti. Il terzo bit MF (More Fragments) serve ad indicare che il "pacchetto" è in realtà un frammento, a parte l'ultimo tutti i frammenti hanno questo bit impostato. Fragment Offset Serve per specificare in quale posizione del pacchetto corrente si trova questo frammento. Time to Live (TTL) Questo campo è impostato con un valore che stabilisce quanto può vivere un pacchetto. In genere ad ogni salto da un host all'altro è decrementato. Quando un host riceve un pacchetto con campo TTL pari a zero provvede ad eliminarlo. Questa operazione è necessaria per impedire che i pacchetti continuino a viaggiare nella rete a tempo indeterminato. Protocol Un pacchetto IP incapsula in genere un pacchetto TCP o ICMP o UDP. Questo campo è utilizzato per specificare il tipo di pacchetto. Header checksum Questo campo è utilizzato per controllare se il pacchetto è corretto o se è stato danneggiato durante il passaggio da un host all'altro. Source Address Indirizzo IP sorgente dell'host che ha inviato il pacchetto Destination Address Indirizzo IP destinazione ossia indirizzo IP dell'host a cui è destinato il pacchetto. Options Questo campo è stato aggiunto per supportare le nuove caratteristiche, informazioni richieste da nuove versioni del protocollo.

Intestazione TCP (Transmission Control Protocol)

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 ----------------------------------------------------------------- | Source Port | Destination Port | ----------------------------------------------------------------- | Sequence Number | ----------------------------------------------------------------- | Acknowledgment Number | ----------------------------------------------------------------- | Data | |U|A|P|R|S|F| | | Offset| Reserved |R|C|S|S|Y|I| Window | | | |G|K|H|T|N|N| | ----------------------------------------------------------------- | Checksum | Urgent Pointer | -----------------------------------------------------------------

Source Port Il campo Source Port (porta sorgente) è indispensabile per specificare a quale porta devono essere indirizzati i pacchetti tcp di risposta. Destination Port Destination Port (porta destinazione) serve per specificare a quale porta (telnet, www, ...) è destinato il pacchetto tcp. Sequence Number e Acknowledgment Number Numeri di sequenza utilizzati per riordinare i pacchetti ed effettuare controlli. Data Offset Questo campo è utilizzato per specificare la lunghezza in parole di 32 bit dell'intestazione TCP. Reserved Campo riservato per uso futuro. URG,ACK,PSH,RST,SYN,FIN Flag (1 bit ciascuno) con ciascuno con diversa funzione. URG è impostato per segnalare dati urgenti. ACK è utilizzato per indicare che il pacchetto è di conferma. PSH (PUSH) da impostare se si desidera che il pacchetto giunga a destinazione e direttamente all'applicazione senza essere memorizzato temporaneamente in un buffer. RST (RESET) è impostato quando si desidera reinializzare una connessione a causa di problemi. SYN è utilizzato per indicare che il pacchetto è di richiesta connessione. La "three way handshake" utilizzata per stabilire una connessione richiede l'invio di pacchetti SYN e ACK. FIN quando si desidera chiudere una connessione stabilita è richiesto l'invio di un pacchetto con il flag FIN impostato. Window Size Questo campo è utilizzato per specificare quanti byte possono essere spediti a partire dal byte confermato. Checksum Come nel caso dell'intestazione IP, anche TCP prevede un campo dedicato alla verifica della correttezza dell'intestazione. Urgent Pointer E' utilizzato per specificare lo scostamento in byte a partire dal numero di sequenza attuale dove possono essere trovati i dati urgenti.

Intestazione UDP (User Datagram Protocol)

Source Port Porta sorgente. Destination Port Porta destinazione. Lenght Dimensione del pacchetto (intestazione + dati). Checksum Utilizzato per garantire l'affidabilità e la correttezza delle informazioni contenute.

Anche i pacchetti UDP sono incapsulati in pacchetti IP.

Intestazione ICMP (Internet Control Message Protocol)

I pacchetti ICMP possono avere intestazioni con campi diversi, tutti comunque hanno i campi Type, Code e Checksum. Seguono le intestazioni dei pacchetti ICMP "destination unreachable" (tipo 3) e "echo-request/reply" (tipo 8 e 0):

Destination unreachable 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 ----------------------------------------------------------------- | Type | Code | Checksum | ----------------------------------------------------------------- | Unused | ----------------------------------------------------------------- echo-request/echo-reply 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 ----------------------------------------------------------------- | Type | Code | Checksum | ----------------------------------------------------------------- | Identifier | Sequence number | -----------------------------------------------------------------

Type Tipo di pacchetto icmp. I tipi disponibili sono: Echo Reply (0), Destination Unreachable (3), Source Quench (4), Redirect (5), Echo (8), Time Exceeded (11), Parameter Problem (12), Timestamp (13), Timestamp Reply (14), Information Request (15) e Information Reply (16). Code Codice associato. Ad esempio al tipo "Destination Unreachable" può essere associato: net unreachable (code=0), host unreachable (1), protocol unreachable (2), port unreachable (3), fragmentation needed and DF set (4), source route failed (5). Identifier e Sequence number Utilizzati per identificare i pacchetti icmp.

Servizi

I seguenti servizi presentano dei problemi per quanto riguarda la sicurezza se si permette di accedervi dall'esterno.

Se non servono allora è il caso di filtrarli.

NOME SERVIZIO PORTA PROTOCOLLO ------------- ----- ---------- echo 7 TCP/UDP systat 11 TCP netstat 15 TCP bootp 67 UDP tftp 69 UDP link 87 TCP supdup 95 TCP sunrpc 111 TCP/UDP NeWS 144 TCP snmp 161 UDP xdmcp 177 UDP exec 512 TCP login 513 TCP shell 514 TCP printer 515 TCP biff 512 UDP who 513 UDP syslog 514 UDP uucp 540 TCP route 520 UDP openwin 2000 TCP NFS 2049 UDP/TCP X11 6000 6000+n TCP n = numero max. di server X.

Fonte: