Inserisci Infobox

Iptables Avanzato

Funzionalità avanzate di iptables.

Catene Custom
Autore: al - Ultimo Aggiornamento: 2005-05-22 22:04:34 - Data di creazione: 2005-05-21 15:16:35
Tipo Infobox: SLIDE - Skill: 3- INTERMEDIATE

E' possibile creare proprie catene con un set di regole autonomo.
La nuova regola può quindi diventare il target di qualsiasi altra regola.

Esempio (tipico) per catena custom che droppa, dopo aver loggato, i pacchetti
iptables -N LOGDROP
iptables -A LOGDROP -j LOG
iptables -A LOGDROP -j DROP


Per usarla:
iptables -A INPUT -p tcp --dport 22 -s ! 10.0.0.1 -j LOGDROP

Catene custom possono rendere più modulare e gestibile la configurazione di iptables.
Posso rivelarsi particolarmente utili in firewall complessi o particolarmente elaborati.
Su sistemi con logiche essenziali sono meno comode.

Logging dei pacchetti
Autore: al - Ultimo Aggiornamento: 2005-05-21 12:16:33 - Data di creazione: 2005-05-21 12:16:20
Tipo Infobox: SLIDE - Skill: 3- INTERMEDIATE

E' possibile loggare i pacchetti tramite il target LOG (log tramite syslog con facility kern) o ULOG (log tramite programmi in userspace).
Entrambi i target, a differenza di molti altri, NON interrompono il preseguimento di una catena.
Per pianificare le logiche di logging è opportuno:
- Decidere cosa si vuole loggare (di solito i pacchetti droppati)
- Definire come sono impostare le regole sul firewall
- Applicare le regole di log al posto giusto.

Se si vuole loggare solo i pacchetti droppati inserire una regola di LOG appena prima di ogni analoga regola di DROP.
Se si ha un DROP di default e si prevedono solo regole di ACCEPT, mettere la regola di LOG alla fine di una catena.

Nel target LOG è possibile definire:
- il livello di criticità per syslog (--log-level level);
- un prefisso, fino a 32 caratteri, per distinguere una riga di log (--log-prefix prefix);
- i dettagli da includere (--log-tcp-sequence , --log-tcp-options , --log-ip-options)

Nel target ULOG è possibile definire:
- il gruppo netlink (1-32) a cui il kernel manda in multicast i pacchetti (--ulog-nlgroup nlgroup). Default = 1.
- un prefisso, fino a 32 caratteri, per distinguere una riga di log (--ulog-prefix prefix);
- numeri di byte da copiare in userspace (Default = 0, tutti i byte del pacchetto) (--ulog-cprange size)
- numero di pacchetti da mettere in code nel kernel prima di inviarli al netlink. Default = 1 (--ulog-qthreshold size)

Dimensionamento Firewall
Autore: al - Ultimo Aggiornamento: 2005-05-21 15:04:34 - Data di creazione: 2005-05-21 15:04:34
Tipo Infobox: SLIDE - Skill: 3- INTERMEDIATE

TO DO

Criteri avanzati di match
Autore: al - Ultimo Aggiornamento: 2005-05-21 14:07:18 - Data di creazione: 2005-05-21 13:00:06
Tipo Infobox: SLIDE - Skill: 4- ADVANCED

Oltre alla possibilità di matchare pacchetti sulla base di logiche comuni, esistono delle estensioni particolarmente potenti e versatili.
Vanno richiamate con -m match e possono avere delle opzioni specifiche per il modulo di match utilizzato.
ADDRESS TYPE (-m addrtype) - Match sul tipo di pacchetto sulla base del suo indirizzo (es: UNSPEC, UNICAST, MULTICAST, BROADCAST, ANYCAST, LOCAL, BLACKHOLE... )
Es: iptables -I INPUT -m addrtype --src-type UNSPEC --dst-type UNICAST -j LOG
CONNECTION RATE (-m connrate) - Match sulla velocità di connessione in byte/secondo.
Es: iptables -I FORWARD -m connrate --connrate :36000 -d 213.215.151.8 -j ACCEPT
LIMIT (-m limit) - Impostazione di limiti sulla base di pacchetti /secondo /minuto /ora /giorno.
Es: iptables -I FORWARD -p tcp --syn -m limit --limit 10/second --limit-burst 20/second -d 213.215.151.8 -j ACCEPT
MAC ADDRESS (-m mac) - Match sul mac address di un frame ethernet.
Es: iptables -I INPUT -m mac --mac-source 00:50:8B:4D:55:BB -j ACCEPT
MULTIPORT (-m multiport) - Permette di definire più porte (sorgente o destinazaione).
Es: iptables -I INPUT -p tcp -m multiport --destination-port 25,80,110,143,443,993,995 -j ACCEPT
OWNER (-m owner) - Match di un pacchetto in uscita secondo onwer, pid o nome del processo che lo ha generato.
Es: iptables -I OUTPUT -m onwer --uid-owner 501 -j ACCEPT
PACKET TYPE (-m pkttype) - Match sul tipo di pacchetto a livello di datalink (UNICAST, MULTICAST, BROADCAST)
Es: iptables -I INPUT -m pkttype --pkt-type UNICAST -j LOG

Moduli sperimentali di iptables
Autore: al - Ultimo Aggiornamento: 2005-05-23 16:21:40 - Data di creazione: 2005-05-21 15:05:50
Tipo Infobox: SLIDE - Skill: 5- SENIOR

Lo sviluppo di moduli su iptables è costante e ai moduli stabili, integrati nelle distribuzioni comuni, si aggiungono moduli sperimentali di matching, target alternativi o patch per il connection tracking di protocolli particolari.
Lo script Patch'O'Matic permette di applicare facilmente le patch sperimentali sui sorgenti del proprio kernel.

Extra MATCH
condition - Match sulla base della presenza di file nel proc filesystem
connlimit - Permette di limitare il numero di connessioni per host
comment - Permette di aggiungere un commento alla regola
geoip - Controllo degli IP secondo la nazione di provenienza
nth - Controllo sulla base di logiche di alternanza configurabili
psd - Post Scan Detector
quota - Controllo delle quote di traffico
random - Gestione di regole sulla base di logiche random
string - Controllo a livello di payload: in pratica layer 7 filtering
time - Controllo sulla base dell'ora o del giorno

Extra TARGET
ACCOUNT - Per fare accounting (ad alta velocità) dei pacchetti matchati  
NETMAP - Utilizzabile per nattare 1:1 intere reti
ROUTE - Utile per modificare il routing di determinati pacchetti
TARPIT - Introduce una tarpit, una sorta di buco nero in cui le connessioni tendono a rimanere appese

Strumenti di analisi e monitoring
Autore: al - Ultimo Aggiornamento: 2005-05-30 15:52:00 - Data di creazione: 2005-05-21 15:08:47
Tipo Infobox: SLIDE - Skill: 4- ADVANCED

Analizzare i dati di traffico di iptables può essere utile.
In particolare è comodo verificare tutti i pacchetti droppati dal firewall.
I target LOG e ULOG permettono il logging dei pacchetti.

LOG genera una riga di testo via syslog per ogni pacchetto matchato. Strumenti che possono analizzare questi log sono:
Iptables Log Analyzer http://www.gege.org/iptables/
Usa uno script Perl per processare i log e scriverli su MySQL. L'output è una pagina php con dati in tempo reale.
LogRep http://logrep.sourceforge.net/
E' un versatile analizzatore di log di diverso tipo, include il supporto di iptables.
LogWatch http://www.logwatch.org/
E' un diffuso analizzatore di log generici. Invia mail con l'analisi e il riassunto dei log. Intepreta anche l'output di iptables.
ULOG tramite ulogd permette una gestione più comoda dei log su database. Fra i tool che usano ulogd:
Webfwlog Firewall Log Analyzer http://webfwlog.sourceforge.net
Fornisce pagine php spartane ma complete e configurabili.
Ulog-php http://www.inl.fr/article.php3?id_article=7
Pagina php essenziale ma completa che interroga log salvati su MySQL da ulodg.

Per informazioni sugli strumenti, i metodi e le alternative per la gestione e l'analisi dei log: http://www.loganalysis.org/

High Availability Firewall
Autore: al - Ultimo Aggiornamento: 2005-05-22 18:36:07 - Data di creazione: 2005-05-21 15:07:09
Tipo Infobox: SLIDE - Skill: 5- SENIOR

Ogni soluzione di High Availability esistente su linux per un cluster applicativo si può applicare ad un firewall, che lavora a livello di kernel
Gli scenari sono comuni:
- Cluster Attivo-Passivo (con programmi come Heartbeat) o Attivo-Attivo
- Non si sono grossi problemi di filesystem, i dati coinvolti sono pochi e poco variabili: si possono usare sistemi gemelli con meccanismi di sincronizzazione della configurazione del firewall (brbd, rsync, ssh)
- Oltre a cluster, si possono usare soluzioni di load balancing
- Al momento non è supportato uno stateful failover: le connessioni esistenti, in uno switch attivo-passivo, vengono interrotte.

Soluzioni possibili (Alcune)
- Heartbeat + rsync|ssh scripts (Cluster HA con sincronizzazione dei file gestita tramite script e fatta via rsync o ssh con chiavi autorizzate)
- Heartbeat + DRBD (Cluster HA con file system sincronizzato tramite network mirroring con DRBD)
- Linux Virtual Server (LVS) Sistema di Load Balancing basato su Linux Virtual Server
- LVS + Ultramonkey - Sistema LVS con HA su Director gestito con Ultramonkey
- LVS + Keepalived - Sistema LVS con Keepalived per monitoring e gestione failvover
- LVS + Piranha - Sistema LVS con HA su Director gestito con Ultramonkey
- LVS + Heartbeat - Sistema LVS con Heartbeat e sistemi di storage sharing

Links
Linux Virtual Server - http://www.linuxvirtualserver.org/
Keepalived - http://www.keepalived.org/
Heartbeat - http://www.linux-ha.org/

Scenari di Load Balancing
Autore: al - Ultimo Aggiornamento: 2005-05-22 19:16:56 - Data di creazione: 2005-05-21 15:08:07
Tipo Infobox: SLIDE - Skill: 4- ADVANCED

Esistono molti metodi per fare load balancing: alcuni sono semplici e grossolani, altri usano software dedicati per monitoring e failure management.

DNS round robin
E' uno dei metodi più semplici. Il bilanciamento viene fatto assegnando diversi indirizzi allo stesso hostname. Non gestisce guasti e, anche con script di monitoraggio/aggiornamento DNS e TTL bassi non risulta essere una soluzione ideale.

Round robin tramite iptables
Esistono diversi metodi: prevedono la gestione del reindirizzamento (tipicamente tramite PREROUTING) dei pacchetti in entrata sull'IP del firewall / balancer verso diversi server reali.
Per gestire l'alternanza si può usare:
- match nth, con alternanza round robin
- match random, con alternanza random
Per gestire il controllo dei server e togliere dal pool server guasti si può abbinare il match condition per una verifica su file che possono essere gestiti da script di monitoraggio.

Linux Virtual Server
Una soluzione strutturata, più complessa ma più affidabile perchè può essere affiancata da tool di monitoring e gestione.
Richiede: Patch LVS nel kernel (ormai ufficiale) e strumenti di controllo e gestione dei servizi
Il Load Balancer può a sua volta essere ridondato con Keepalived, Ultra Monkey, Piranha, Heartbeat ecc.
LVS inoltre include progetti figli interessanti (e sperimentali):
TCPHA - Supporto di strutture con triangolazione del traffico (Internet->Directory->RealServer->Internet) senza gestire i pacchetti di ritorno dai server tramite il Balancer
KTCPVS (Kernel TCP Virtual Server) implementa load balancing a livello applicativo.

Raccomandazioni per il network tuning del Kernel
Autore: al - Ultimo Aggiornamento: 2005-05-23 22:34:53 - Data di creazione: 2005-05-21 14:08:35
Tipo Infobox: SLIDE - Skill: 5- SENIOR

Vediamo alcune impostazioni per il kernel che possono rivelarsi interessanti per un firewall.
Possono ovviamente essere applicate via /etc/sysctl.conf e editando direttamente i file in /proc/sys/net

sysctl -w net.ipv4.icmp_echo_ignore_broadcasts=1 - Disabilita echo request su ping a brodcast (anti smurf abuse)
sysctl -w net.ipv4.conf/all/accept_redirects=0 - Impedisce la modifica del routing tramite ICMP redirection.
sysctl -w net.ipv4.conf/all/send_redirects=0
sysctl -w net.ipv4.conf.all.accept_source_route=0 - Disabilita source-routing
sysctl -w net.ipv4.conf.all.forwarding=0
sysctl -w net.ipv4.conf.all.mc_forwarding=0
sysctl -w net.ipv4.conf.all.rp_filter=1 - Forza verifiche di congruità sul traffico in ingresso e uscita
sysctl -w net.ipv4.conf.all.log_martians=1 - Logga e droppa pacchetti "marziani" che non si sa dove routare
sysctl -w net.ipv4.tcp_syncookies=1 - Abilita i syn-cookie, allocando risorse (TCP buffer) solo dopo aver ricevuto un ACK di un SYN/ACK (Utile per Syn Flood)
sysctl -w net.ipv4.tcp_max_syn_backlog=1280 - Aumenta la dimensione della coda delle socket allocate per SYN ricevuti
sysctl -w net.ipv4.tcp_keepalive_time = 1800 - Imposta a 1800 secondi (30 minuti) il tempo di keepalive per una connessione TCP. Al termine di questo tempo una connessione non chiusa ma inattiva, viene chiusa (default 7200)

Design di reti sicure - Scenari e discussioni
Autore: al - Ultimo Aggiornamento: 2005-05-22 11:44:57 - Data di creazione: 2005-05-21 14:10:35
Tipo Infobox: SLIDE - Skill: 3- INTERMEDIATE

Una network disegnato secondo buoni principi di sicurezza dovrebbe:
- Avere firewall che limitano al massimo le porte esposte a Internet
- Avere firewall configurati per bloccare tutto, di default
- Differenziare in diversi network server pubblici, backend, e eventuale LAN interna.
- Separare fisicamente (switch diversi o VLAN) reti IP diverse
- Non avere assolutamente hsot con porte pubbliche a cavallo di due reti
- Limitare al massimo e non lasciare porte pubbliche sui firewall a cavallo di due reti
- Avere sistemi di monitoraggio e IDS isolati e non raggiungibili da Internet
- Avere sistemi di analisi dei pacchetti isolati
- Prevedere Intrusion Prevention Systems packet based e non policy based
- Aprire in modo selettivo e temporalmente limitato le porte di accesso a VPN

Logging con Iptables
Autore: al - ( Revisione: al ) - Ultimo Aggiornamento: 2005-05-14 22:11:24 - Data di creazione: 2003-02-24 17:00:18
Tipo Infobox: DESCRIPTION - Skill: 3- INTERMEDIATE

Iptables mette a disposizione la possibilità di loggare pacchetti per debugging e analisi del traffico.
Di fatto il log generato da iptables può essere utile sia per verificare le funzionalità delle regole inserite sia per essere analizzato da tool per creare statistiche e report.

Il logging viene abilitato tramite target LOG che lavora in kernel space e usa syslog per scrivere i log o con ULOG per trasmettere a programmi in user space le informazioni di log.
E' buon senso loggare solo i pacchetti che vengono bloccati, in modo da avere informazioni utili per troubleshooting (in fase di configurazione e test del firewall) e sicurezza (per capire i volumi e la qualità del traffico non desiderato).

A differenza di molti altri, i target LOG e ULOG non interrompono l'attraversamento di una catena: i pacchetti che matchano una regola di (U)LOG vengono loggati e continuano ad essere processati venendo gestiti da netfilter secondo le regole successive.

In un firewall, che di default blocca tutto, la regola di logging dovrebbe essere l'ultima prima del DROP di default.

Il target LOG
Il target LOG (-j LOG) permette di definire diverse opzioni:
--log-level # - Livello di logging, secondo le logiche di syslog, utile, insieme alla configurazione di syslog.conf, per loggare i dati sui pacchetti su file separato.
--log-prefix stringa - Una stringa, lunga fino a 29 caratteri, che viene messa come prefisso alla riga di log, per renderlo più leggibile e associarlo ad un dato tipo di traffico
--log-tcp-sequence - Logga il TCP sequence naumber. Dato sensibile, se accessibile ad altri utenti locali.
--log-tcp-options - Logga le opzioni presenti nell'intestazione TCP
--log-ip-options - Logga le opzioni presenti nell'intestazione IP (come il precedente può essere utile per strumenti di analisi dei log, altrimenti, se le informazioni aggiuntive non si reputano interessanti, è meglio disattivare)
--log-uid - Logga lo UserID del processo che ha generato il pacchetto (in OUTPUT).

Il target ULOG
Meno diffuso e usato rispetto a LOG, ULOG fornisce maggiore flessibilità ed estende notevolmente il campo di applicazioni possibili.
Redireziona infatti in multicast il pacchetto che ha matchato la regola su una netlink socket a cui possono legarsi uno o più processi in userspace ricevendo i pacchetti senza che un loro eventuale malfunzionamento interrompa la gestione del traffico da parte di netfilter.
I programmi che ricevono i pacchetti li possono quindi trattare per molteplici scopi:
- Logging su database o in formati diversi da quello standard via syslog del target LOG
- Ispezioni dei pacchetti per matching su tipologie di traffico articolate, come le regole di un IDS quale SNORT
- Attivazione di meccanismi di Intrusion Prevention, interrompendo flussi di traffico indesiderati o pericolosi
Le applicazioni possono essere molte e modulari e possono essere sviluppate come componenti esterne al kernel.
Una di queste è ULogD che funziona come un servizio e utilizza diversi plugin per gestire i dati in vario modo, tra cui la possibilità di loggare su database MySQL o PostgreSQL
--ulog-nlgroup nlgroup - Definisce il gruppo netlink (1-32) a cui è indirizzato il pacchetto. Di default è 1
--ulog-prefix prefix - Come su LOG, imposta una stringa come prefisso alla riga di log (max 32 caratteri)
--ulog-cprange # - Numero di byte da copiare in user space. Di default è 0 e l'intero pacchetto viene inviato
--ulog-qthreshold # - Numero di pacchetti che il kernel deve avere in coda prima di inviarli al netlink. Default è 1

Esempi
Per loggare i pacchetti sulle catene di filter FORWARD, INPUT e OUTPUT aggiungendo in ogni riga di log adeguato prefisso.
iptables -A FORWARD -j LOG --log-prefix="FORWARD: "
iptables -A INPUT -j LOG --log-prefix="INPUT:"
iptables -A OUTPUT -j LOG --log-prefix="OUTPUT:"


Per loggare tutti i pacchetti UDP in INPUT con porta sorgente diversa da 137,138 e 139, inserendo come prefisso INPUT UDP:
iptables -A INPUT -p UDP --source-port ! 137:139 -j LOG --log-prefix="INPUT UDP:"

Per loggare tramite ULOG:
iptables -A INPUT -j ULOG --log-prefix="INPUT:"
In esecuzione sul sistema deve  esserci us servizio come ulogd in grado di intercettare il multicast su netlink.

Un buona regola di log da appendere alla fine di una catena con policy di default DROP, può essere la seguente. Logga solo pacchetti di tipo unicast (comodo per evitare log di drop di multicast o broadcast inoffensivi) e con livello 7 di severity su sysylog (debug):
iptables -A INPUT -m pkttype --pkt-type unicast -j LOG --log-prefix "INPUT: " --log-level 7

Esempio di output di LOG su syslog
Feb 19 11:01:12 GIOVE kernel: FORWARD=eth1 OUT=eth0 SRC=192.168.0.98 DST=213.198.151.2 LEN=66 TOS=0x00 PREC=0x00 TTL=127 ID=165 PROTO=UDP SPT=1047 DPT=53 LEN=46

Utilizzo dei rulenum con iptables
Autore: neo - Ultimo Aggiornamento: 2003-03-31 14:34:37 - Data di creazione: 2003-03-31 14:34:37
Tipo Infobox: TIPS - Skill: 4- ADVANCED

Ad ogni regola è associato un numero univoco per catena (rulenum) da 1 a infinito che può essere utilizzato per semplificare la gestione delle regole in un firewall (cancellazione, aggiunta nuove regole, visualizzazione).

Per visualizzare le regole con il relativo rulenum occorre specificare l'opzione  "--line-numbers":

[root@GIOVE root]# iptables -L -nv --line-numbers
Chain INPUT (policy DROP 325 packets, 56856 bytes)
num   pkts bytes target     prot opt in     out     source               destination        
1        2   120 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0          
2     9673  677K ACCEPT     tcp  --  *      *       10.0.0.0/24          0.0.0.0/0          tcp dpt:22 state NEW,ESTABLISHED
3      329 57096 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0          LOG flags 0 level 4 prefix `DENY INPUT:'

Chain FORWARD (policy DROP 299 packets, 28380 bytes)
num    pkts bytes target     prot opt in     out     source               destination        
1        6   288 ACCEPT     tcp  --  eth0   *       10.0.0.0/24          0.0.0.0/0          state NEW,ESTABLISHED
2        3   120 ACCEPT     tcp  --  eth1   *       192.168.0.0/24       10.0.0.0/24        state RELATED,ESTABLISHED
3      113 10722 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0          LOG flags 0 level 4 prefix `FORWARD:'

Chain OUTPUT (policy DROP 665 packets, 98378 bytes)
num   pkts bytes target     prot opt in     out     source               destination        
1      235 38592 ACCEPT     tcp  --  *      *       0.0.0.0/0            10.0.0.0/24        
2        5   348 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0          
3        4   240 ACCEPT     all  --  *      *       192.168.0.0/24       10.0.0.0/24        state RELATED,ESTABLISHED
4      670  238K LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0          LOG flags 0 level 4 prefix `OUTPUT:'


Per quanto riguarda le operazioni  di cancellazione o aggiunta di nuove regole occorre solo specificare il numero della regola preceduto dalla catena:

Visualizzazione delle rules nella catena di FORWARD e cancellazione della regola numero 3
[root@GIOVE root]# iptables -L FORWARD  -nv --line-numbers
Chain FORWARD (policy DROP 299 packets, 28380 bytes)
num   pkts bytes target     prot opt in     out     source               destination        
1        6   288 ACCEPT     tcp  --  eth0   *       10.0.0.0/24          0.0.0.0/0          state NEW,ESTABLISHED
2        3   120 ACCEPT     tcp  --  eth1   *       192.168.0.0/24       10.0.0.0/24        state RELATED,ESTABLISHED
3     113 10722 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0          LOG flags 0 level 4 prefix `FORWARD:'
[root@GIOVE root]# iptables -D 3
[root@GIOVE root]# iptables -L FORWARD  -nv --line-numbers
Chain FORWARD (policy DROP 299 packets, 28380 bytes)
num   pkts bytes target     prot opt in     out     source               destination        
1        6   288 ACCEPT     tcp  --  eth0   *       10.0.0.0/24          0.0.0.0/0          state NEW,ESTABLISHED
2        3   120 ACCEPT     tcp  --  eth1   *       192.168.0.0/24       10.0.0.0/24        state RELATED,ESTABLISHED


Visualizzazione rule della catena di INPUT e aggiunta di una nuova regola tramite rulemun per assegnargli il secondo posto nella catena
[root@GIOVE root]# iptables -L INPUT   -nv --line-numbers
Chain INPUT (policy DROP 369 packets, 64998 bytes)
num   pkts bytes target     prot opt in     out     source               destination        
1        2   120 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0          
2   11484  803K ACCEPT     tcp  --  *      *       10.0.0.0/24          0.0.0.0/0          tcp dpt:22 state NEW,ESTABLISHED
3      373 65238 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0          LOG flags 0 level 4 prefix `DENY INPUT:
[root@GIOVE root]# iptables -I INPUT 2  -p tcp -s 192.168.0.0/24
[root@GIOVE root]# iptables -L INPUT -nv --line-numbers
Chain INPUT (policy DROP 383 packets, 67613 bytes)
num   pkts bytes target     prot opt in     out     source               destination        
1        2   120 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0          
2        0     0            tcp  --  *      *       192.168.0.0/24       0.0.0.0/0          
3    11635  814K ACCEPT     tcp  --  *      *       10.0.0.0/24          0.0.0.0/0          tcp dpt:22 state NEW,ESTABLISHED
4      387 67853 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0          LOG flags 0 level 4 prefix `DENY INPUT:'

Configurazione Kernel Linux per il firewalling
Autore: neo - ( Revisione: al ) - Ultimo Aggiornamento: 2002-10-04 01:20:15 - Data di creazione: 2002-10-04 01:20:15
Tipo Infobox: DESCRIPTION - Skill: 5- SENIOR

Per far si che il nostro linux funga da firewall, dovremo compilare il kernel abilitando il netfiltering e alcune sue features a seconda dello scopo e del tipo di traffico che dovra' filtrare.
Come la maggior parte delle features del kernel linux si ha la possibilita' di selezionarle come moduli oppure compilarli all'interno del kernel se si preferisce un kernel monolitico.

Di seguito vengono messe in evidenza le piu' importanti opzioni da considerare nella fase di configurazione del kernel per attivare e gestire il packet filtering:

CONFIG_PACKET
Permette a varie applicazione ed utility di lavorare direttamente sui device di rete
CONFIG_NETFILTER
DA ABILITARE!! Di fatto e' l'opzione base che vi permettera' anche di accedere al menu delle singole opzioni di iptables
CONFIG_IP_NF_CONNTRACK
Modulo che permette il tracking delle connessioni, utilizzato per il NAT e masquerading
CONFIG_IP_NF_FTP
Modulo che permette il tracking delle connessioni FTP, utile se volete fare firewall perimetrale o di contenimento che devono gestire anche traffico ftp. Bene o male FTP si utilizza ovunque, direi DA ABILITARE.

CONFIG_IP_NF_IPTABLES
DA ABILITARE!! Opzione che permette qualsiasi tipo di filtering, NAT e masquerading. Praticamento e' il core delle iptables
CONFIG_IP_NF_MATCH_LIMIT
Opzione non obbligatoria, ma permette di fare filtering sulle connessioni, stabilendo che un certo numero di pacchetti in un certo limite di tempo devono matchare alcune regole. Utile per difendersi da attacchi DoS
CONFIG_IP_NF_MATCH_MAC
Opzione che permette l'utilizzo del MAC address per il matching delle regole. Comodo se si hanno poche macchine da gestire, ma sarete pesantemente dipendenti dall'hardware che utilizzerete
CONFIG_IP_NF_MATCH_MARK
Abilita la possibilita' di fare il matching tramite il MARK dei pacchetti.
CONFIG_IP_NF_MATCH_MULTIPORT
Permette di filtrare le connessioni specificando un range di sorce port e destination port. DA ABILITARE
CONFIG_IP_NF_MATCH_TOS
Permette il filetring tramite TOS (Type of Service). ONLY FOR EXPERT
CONFIG_IP_NF_MATCH_TCPMSS
Abilita' la possibilita del matching del MSS field. ONLY FOR EXPERT
CONFIG_IP_NF_MATCH_STATE
Permette il stateful matching delle connessioni. DA ABILITARE !!
CONFIG_IP_NF_MATCH_UNCLEAN
Opzione che permette di filtrare il traffico TCP,UDP,ICMP che sono considerati invalidi. DA ABILITARE, ma ricordarsi che non funziona del tutto corettamente in tutti i casi
CONFIG_IP_NF_MATCH_OWNER
Ci permette di filtrare le socket, abilitando un'utente specifico per aprire un certo tipo di socket. E' ANCORA IN FASE DI SVILUPPO
CONFIG_IP_NF_FILTER
Modulo base per il packet filetering. DA AGGIUNGERE!!
CONFIG_IP_NF_TARGET_REJECT
Modulo che permette di specificare che i messagi di ICMP error di essere inviati alla sorgente
CONFIG_IP_NF_TARGET_MIRROR
Abilita il bounced back (rimbalzati indietro) dei pacchetti al sender. ES. se si decide di mettere un MIRROR target sulle porte di destinazione di HTTP (80), tutte le richieste verranno replicate al sender e poi seguite dai pacchetti contenenti le informazioni per visualizzare la pagina
CONFIG_IP_NF_NAT
Modulo che abilita il NAT, Port forwarding e masquerading. DA ABILIATRE se si vuole translare gli ip sorgente o di destinazione
CONFIG_IP_NF_TARGET_MASQUERADE
Modulo che permette di aggiungere il TARGET per il masquerading. DA ABILITARE, se si vuole fare masquerading.
CONFIG_IP_NF_TARGET_REDIRECT
Opzione che permette che vi permette di far funzionare il vostro firewall come se fosse un transparent proxy
CONFIG_IP_NF_TARGET_LOG
Permette la possibilita' di loggare i packetti. DA ABILITARE, anche se quello che si logga dipende dalle vostre regole. Se decidete di abilitare questa opzione e di loggare in syslog, utilizzate tools per avere un report del entry registrate nel log sia per rendere la lettura dei log piu' comprensibile sia per la possibilita' di mantenere una history
CONFIG_IP_NF_TARGET_TCPMSS
Questa opzione viene utilizzata per ovviare a vari problemi con host o ISP che bloccano i pacchetti che richiedono l'ICMP Fragmentation.
CONFIG_IP_NF_COMPAT_IPCHAINS
Abilita la compatibilita' con le vecchie IPCHAINS. DA ABILIATRE solo in caso di bisogno
CONFIG_IP_NF_COMPAT_IPFWADM
Abilita la compatibilita' con le vecchie IPCHAINS. DA ABILIATRE solo in caso di bisogno

Esistono altri parametri configurabili in run-time ovvero dopo che il kernel e' stato caricato e il sistema è in funzione.
Si hanno piu' possibilita' per modificare questi parametri, quello piu' corretto e' quello di modificare i vari parametri editando /etc/sysctl.conf oppure usare il comando sysctl o scrivendo direttamente i valori voluti nel proc filesystem.
Questa operazione viene normalmente eseguita tramite script lanciati al boot della macchina.

Segue un elenco delle principali opzioni modificabili in modalita' run-time per quanto riguarda il network, ovviamente nel dubbio è meglio lasciare i valori di default, salvo quelli strettamente necessari per un firewall (ip_forward).
I valori che si possono assumere sono di tipo:
- BOOLEAN = 0 (disabilita) e 1(abilita)
- INTEGER = N , dove N e' un mumero intero Es 64
- N INTEGERS = X Y Z , N indica il numero dei valori(interi) da inserire, e X Y Z i valori che acquisisce la variabile

Tutte le variabili fanno riferimento a /proc/sys/net/ipv4/*:
ip_forward BOOLEAN - Permette il forwarding dei pacchetti fra le interfacce. DA ABILITARE.
ipfrag_high_thresh INTEGER - La massima memoria utilizzata per riassemblare i pacchetti IP frammentati. Quando questo valore verra' raggiunto, i pacchetti in surplus verranno scartati finche' non si raggiungera' di nuovo il valore settato in ip_frag_low_thresh
ipfrag_time INTEGER - Indica il tempo max in secondi per mantenere in memoria un "IP fragment"
tcp_syn_retries INTEGER - Indica il numero di volte che un SYN deve essere ritrasmesso per i tentativi di una connessione TCP attiva (non puo' essere piu' grande di 255)
tcp_synack_retries INTEGER - Indica il numero delle volte che un SYNACK deve essere ritrasmesso per i tentavi di connessioni TCP passive (non puo' essere piu' grande di 255)
tcp_keepalive_time INTEGER - Indica quanto spesso verra' inviato il messaggio TCP di keepalive. Default 2hdsfsfds
tcp_keepalive_probes INTEGER -  Indica quanti pacchetti Keepalive probes verranno inviati, finche' la connessione verra' considerata definitivamente broken
tcp_keepalive_interval INTEGER - Indica quanto frequentemente i pacchetti di probe sono inviati. Moltiplicando per tcp_keepalive_probes si ottiene il tempo per il KILL di una connessione che non risponde ai pacchetti di probes.
tcp_retries1 INTEGER - Indica il numero di tentativi/richieste prima che venga segnalato al network layer che sulla connessione c'e' qualcosa che non va.
tcp_retries2 INTEGER - Indica il numero di tentativi/richieste prima di killare una sessione TCP attiva
tcp_orphan_retries INTEGER - Indica il numero dei tentativi/richieste prima che una connessione TCP venga killata
tcp_fin_timeout INTEGER - Indica il tempo per cui mantenere una socket nello status di FIN-WAIT-2
tcp_max_tw_buckets INTEGER - Indica il numero massimo di socket simultanee in timewait che mantiene il sistema
tcp_max_orphans INTEGER - Numero massimo di socket TCP che possono rimanere non collegati a file handle aperti dal sistema.
tcp_abort_on_overflow BOOLEAN - Permette il reset di una connessione se un servizio in listening e' troppo lento per rispondere.
tcp_sysncookies BOOLEAN - Opzione valida solo se il kernel e' stato compilato con il supporto dei SYNCOOKIES, previene possibili "syn flood attack"
tcp_timestamps BOOLEAN - Abilita o disabilita il timestamp
tcp_ecn BOOLEAN - Abilita o disabilta  la notificazione di una possibile congestione della network
ip_local_port_range 2 INTEGERS - Desinisce il range delle porte locali, utilizzate  dal  protocollo TCP e UDP. Il primo numero indica la porta piu' bassa ed il secondo indica la porta piu' alta. Il valore di default dipende dal quantitativo di ram disponibile sul sistema
ip_dynaddr BOOLEAN  - Se settato non a zero abilita il supporto per il dynamic addresses
icmp_echo_ignore_all BOOLEAN - Ignora i Ping (ICMP ECHO Request)
icmp_echo_ignore_broadcasts BOOLEAN -  Se settati entrambi il sistema ignora gli ICMP ECHO solo verso indirizzi di broadcast/multicast
log_martians BOOLEAN - Logga i pacchetti con indirizzi impossibili.
accept_redirects BOOLEAN - Accetta o meno gli ICMP redirect
forwarding BOOLEAN -  Abilita il forwarding per una specifica interfaccia
proxy_arp BOOLEAN - Abilita il proxy arp.
secure_redirects BOOLEAN - Accetta ICMP redirect message solo dai gw configurati.
La modifica di alcuni parametri potrebbe pregiudicare il buon funzionamento del sistema, ma può essere necessaria per il fine tuning di sistemi sotto particolari carichi di rete.
Per maggiori informazioni e indicazioni utili sui parametri raccomandabili fare riferimento direttamente al file Documentation/networking/ip-sysctl.txt nel tarball del kernel.

Iptables Patch'O'Matic
Autore: al - Ultimo Aggiornamento: 2005-06-01 10:21:27 - Data di creazione: 2004-10-30 01:30:26
Tipo Infobox: DESCRIPTION - Skill: 5- SENIOR

Il team di sviluppatori di Netfilter e i loro collaboratori hanno realizzato numerose patch che allargano in modo considerevole le funzionalità del codice base, normalmente incluso nel kernel.
Molte di queste non sono incluse nel codice ufficiale del kernel in quanto considerate sperimentali, non completamente stabili o non necessarie, alcune lo saranno in futuro o sono incluse nel ramo 2.6 ma non nel 2.4, alcune sono incluse nei kernel forniti da specifiche distribuzioni.
Esiste comunque la possibilità di inserirle in un proprio kernel custom utilizzando Patch'O'Matic (POM), un comodo strumento realizzato dagli autori di Netfilter.

INTRODUZIONE
Per applicare le patch aggiuntive sul codice del proprio kernel sono necessari:
- I sorgenti del kernel (normalmente scompattati nella directory /usr/src/linux o /usr/src/kernel-versione o simili) su cui verranno applicate le patch
- I sorgenti di iptables, scaricabili dal sito ufficiale http://www.netfilter.org/ che vanno ricompilati per supportare le nuove opzioni introdotte
- I sorgenti di patch'o'matic, anch'essi scaricabili dal sito ufficiale. Notare che dai primi di Gennaio 2005 il team di Netfilter ha smesso di rilasciare release ufficiali di patch'o'matic, per cui è interessato a queste patch si deve basare sulle release "current" rilasciate regolarmente.

Le patch (sono numerose e variegate) sono divise in diversi gruppi:
submitted - Patch proposte e sottoposte per l'inclusione nel kernel ufficiale
pending - Patch che sono in attesa di essere proposte per essere incluse nel kernel ufficiale
base - Patch di base, comunque sperimentali e non testate in modo approfondito  
extra - Tutte le patch disponibili, numerose, variegate e sperimentali
obsolete - Codice obsoleto o deprecato.
Notare che esistono patch in conflitto fra loro, che non vanno compilate sullo stesso kernel. Generalmente i conflitti, le dipendenze e le incompatibilità sono indicate per ogni patch.

INSTALLAZIONE
Si scaricano e scompattano i sorgenti. Non essendoci più release ufficiali di POM, in questo esempio si è ricorso all'ultimo snapshot, con tutti i rischi del caso nell'usare software in testing.
wget http://ftp.netfilter.org/pub/patch-o-matic-ng/snapshot/patch-o-matic-ng-20050413.tar.bz2
tar -jxvf patch-o-matic-ng-20050413.tar.bz2
cd patch-o-matic-ng-20050413

A questo punto si può procedere con la procedura standard di POM:
export KERNEL_DIR=/usr/src/kerneldir Indicare la directory dove si trovano i sorgenti del kernel da patchare
export IPTABLES_DIR=/usr/src/iptablesdir Dove sono stati scompattati i sorgenti di iptables
./runme pending

Alternativamente eseguire ./runme base o ./runme extra per includere i diversi gruppi.
Per ogni patch viene data una breve spiegazione e chiesto se si vuole inserirla nel kernel.
Una volta completata questa operazione sarà possibile procedere alla compilazione del kernel secondo le solite procedure. Nel menu di configurazione del kernel tutte le patch aggiuntive sono include nella voce NetFilter Configuration del menu Networking options.
Oltre ai moduli del kernel, patch'O'matic permette di patchare il mondo userland del comando iptables, in modo da gestire le nuove funzionalità.

PATCH (+) INTERESSANTI
Vediamo alcune delle patch più interessanti che POM mette a disposizione, queste riguardano soprattutto nuovi criteri di matching dei pacchetti e nuovi target:

match: comment
Questa patch, già inclusa nel kernel ufficiale 2.6, permette di aggiungere un commento ad una regola, introducento il modulo di match comment con l'unica opzione --comment.
Esempio: -A INPUT -s 213.215.144.242 -m comment --comment "Host Webmaster"
Voce nel kernel .config: CONFIG_IP_NF_MATCH_COMMENT
Nome modulo: ipt_comment

target: NETMAP
Ancora sperimentale, presente nel repository base, introduce il target NETMAP che permette di nattare 1 a 1 tutti gli host di intere reti senza specificare i singoli IP. Comodo per firewall che nattano tutti i propri server in una DMZ con IP privati o per fare double natting per far comunicare reti con gli IP privati sovrapposti.
Esempio: iptables -t nat -A PREROUTING -d 213.215.144.128/25 -j NETMAP --to 10.0.0.128/25
Si può usare anche per source natting: iptables -t nat -A POSTROUTING -s 213.215.144.128/25 -j NETMAP --to 10.0.0.128/25
Voce nel kernel .config: CONFIG_IP_NF_TARGET_NETMAP
Nome modulo: ipt_NETMAP

match: connlimit
Patch sperimentale che imposta un numero massimo di connessioni tcp da un singolo arbitrario host IP o da una intera rete. Introduce il match connlimit con le opzioni --connlimit-above (determina il numero massimo di connessioni) e --connlimit-mask (imposta il limite allargandolo ad una intera rete, definendola tramite i subnet bit, ad esempio 24. Di default si limita al singolo host: 32)
Esempi:
Per limitare l'accesso SSH a due sole connessioni per IP sorgente:
-I INPUT -p tcp --dport 22 --syn -m connlimit --connlimit-above 2 -j DROP
Per impostare massimo 16 connessioni per rete di 256 indirizzi ad un server web dietro il firewall Linux:
-A FORWARD -d 213.215.144.242 -p tcp -m tcp --dport 80 --syn -m connlimit --connlimit-above 16 --connlimit-mask 32 -j DROP
Per impostare a 250 il numero massimo di connessioni contemporanee che possono essere fatte ad un server SMTP:
-A FORWARD -d 213.215.144.242 -p tcp -m tcp --dport 25 --syn -m connlimit --connlimit-above 250 --connlimit-mask 0 -j DROP
Voce nel kernel .config: CONFIG_IP_NF_MATCH_CONNLIMIT
Nome modulo: ipt_connlimit

match: iprange
Comoda patch che permette di fare il match su un range di IP sorgenti o destinazione. Introduce il modulo di match iprange con le opzioni: --src-range (range di IP sorgenti, es: 10.0.0.0-10.0.255.255) e --dst-range.
Esempio: iptables -A FORWARD -m iprange --dst-range 10.0.0.0-10.0.255.255 -j ACCEPT
Voce nel kernel .config: CONFIG_IP_NF_MATCH_IPRANGE
Nome modulo: ipt_iprange

match: nth
Curiosa e versatile patch che permette di fare un match ogni n pacchetti sulla base di opzioni varie, mettendo a disposizione di default 16 "contatori" indipendenti. Introduce il match nth con le opzioni:
--every Imposta ogni quanti pacchetti eseguire il match
--counter Definisce il contatore da utilizzare (di default 0)
--start Definisce a quale pacchetto iniziare a contare (di default 0)
--packet Definisce quale pacchetto all'interno del contatore matchare. Se viene definito va inserira una regola per ogni --packet da 0 a N-1
Esempio senza l'uso di --packet per loggare un pacchetto ogni 10, in entrata: iptables -I INPUT -m nth --every 10 -j LOG
Esempio per un semplice ma efficace load balancer dove tutti i pacchetti alla porta 80 dell'IP pubblico vengono forwardati in modalità round robin a 3 diversi server web nattati (viene usato il contatore 1):
iptables -t nat -A PREROUTING -d 213.215.144.242 -p tcp --dport 80 -m nth --counter 1 --every 3 --packet 0 -j DNAT --to-dest 10.0.0.10:80
iptables -t nat -A PREROUTING -d 213.215.144.242 -p tcp --dport 80 -m nth --counter 1 --every 3 --packet 1 -j DNAT --to-dest 10.0.0.11:80
iptables -t nat -A PREROUTING -d 213.215.144.242 -p tcp --dport 80 -m nth --counter 1 --every 3 --packet 2 -j DNAT --to-dest 10.0.0.12:80

Voce nel kernel .config: CONFIG_IP_NF_MATCH_NTH
Nome modulo: ipt_nth

match: psd
E' possibile identificare dei Port Scan tramite il match psd con le seguenti opzioni:
--psd-weight-threshold Peso degli ultimi pacchetti TCP/UDP a porte di destinazione diverse proveniente dallo stesso host.
--psd-delay-threshold Ritardo, in centesimi di secondi, per considerare pacchetti a porte diverse come dovuti ad un port scan
--psd-lo-ports-weight Peso dei pacchetti destinate a porte privilegiate (<=1024).
--psd-hi-ports-weight Peso dei pacchetti destinati a porte non privilegiate.
Un esempio essenziale per aggiungere un log, che può essere verboso, di tutti gli scan (Consigliabile aggiungerlo alla fine della catena di INPUT, con un default DROP finale):
iptables -A INPUT -m psd -j LOG --log-prefix "PORTSCAN: "
Voce nel kernel .config: CONFIG_IP_NF_MATCH_PSD
Nome modulo: ipt_psd

match: quota
Implementa il match quota con cui si definisce un contatore relativo al traffico di rete che si vuole permettere (o comunque matchare). Unica opzione: --quota (numero di byte massimi).
Esempio: iptables -A FORWARD -m quota --quota 1024000 -d 10.0.0.5 -j ACCEPT
Voce nel kernel .config: CONFIG_IP_NF_MATCH_QUOTA
Nome modulo: ipt_quota

match: random
Un curioso match random che introduce la possibiltà  di definire regole con possibilità di match random in base all'opzione: --average che indica la percentuale media di match (di default il 50%)
Esempio: iptables -A INPUT -m random --average 10 -d 10.0.0.5 -j LOG
Voce nel kernel .config: CONFIG_IP_NF_MATCH_RANDOM
Nome modulo: ipt_random

match: time
Permete di creare regole sulla base dell'ora, della data o del giorno della settimana. Introduce il match time con le seguenti opzioni:
--timestart value - Match se l'ora locale è successiva a quella indicata (HH:MM, default 00:00).
--timestop  value - Match se l'ora è prima di quella indicata (default 23:59).
--days - Giorno della settimana (formato: Mon,Tue,Wed,Thu,Fri,Sat,Sun ; default tutti i giorni)
--datestart - Match se la data è successiva a quella indicatata (Formato: YYYY[:MM[:DD[:hh[:mm[:ss]]]]])
--datestop - Match se la data locale è prima di quella indicata (Formato YYYY[:MM[:DD[:hh[:mm[:ss]]]]])
Esempio per permettere l'accesso solo in orari lavorativi:
iptables -A INPUT -m time --timestart 8:00 --timestop 18:00 --days Mon,Tue,Wed,Thu,Fri -j ACCEPT
Esempio per permettere l'accesso solo fino al 31 Dicembre 2005:
iptables -A INPUT -m time --datestop 2005:12:31:23:59 -j ACCEPT
Voce nel kernel .config: CONFIG_IP_NF_MATCH_TIME
Nome modulo: ipt_time

match: condition
Fornisce un meccanismo di matching che può rivelarsi estremamente flessibile per modificare le regole di firewalling secondo il contenuto di un file.
In pratica permette di verificare se un file qualsiasi nella directory /proc/net/ipt_condition/ ha valore 0 o 1.
Esempio per aprire la porta 80 se il file  /proc/net/ipt_condition/openweb ha contenuto "1":
iptables -A INPUT -m condition --condition openweb -p tcp --dport 80 -j ACCEPT
Voce nel kernel .config: CONFIG_IP_NF_MATCH_CONDITION
Nome modulo: ipt_condition

match: geoip
Rivoluzionario modulo per eseguire filtering sulla base della nazione da cui proviene un IP. Si appoggia ad un database GeoIP, ha bisogno dei file /var/geoip/geoipdb.bin e /var/geoip/geoipdb.idx su quali eseguire il check sulle nazioni a cui sono associati i vari IP.
I database si possono creare con l'utility csv2bin o scaricare da http://people.netfilter.org/peejix/geoip/database/.
Voce nel kernel .config: CONFIG_IP_NF_MATCH_GEOIP
Nome modulo: ipt_geoip

match: string
Permette il match di una stringa nel contenuto di un pacchetto. Di fatto, seppur non è questo l'utilizzo migliore perchè non prevede la conoscenza della logica del protocollo, permette filtering a livello applicativo.
Esempio classico per loggare CodeRed e affini (notare che non esclude falsi positivi): iptables -I INPUT -p tcp -s 0.0.0.0/0 -m string --string "cmd.exe" -j LOG
Voce nel kernel .config: CONFIG_IP_NF_MATCH_STRING
Nome modulo: ipt_string

Privacy Policy