Archivio

Archivio Luglio 2006

Le Scie Chimiche Su Rai 2

30 Luglio 2006 1 commento

Pochi minuti fa, (domenica 30 Luglio 2006 ore 13:25)

Sveglio da circa un’oretta, dopo aver fatto colazione, mi ero messo a postare sul blog di Beppe Grillo, lasciando la televisione accesa su rai 2. D’improvviso sento le seguenti parole provenienti dal tg2: gli astronomi di ….vanno in protesta ed annunciano la loro estrema difficolta’ nello scrutare il cielo a causa degli aerei che rilasciano lunghe scie di condensazione (contrails) e che poi , dissolvendosi, formano una patina biancastra nel cielo. Mi sono catapultato da mia madre, per avere un testimone a portata d’orecchio, e come ci riposizioniamo davanti la tv, finalmente li vedo passare dalla malefica scatoletta della tv. Gli aerei cisterna per rifornimento in volo dell’aviazione americana mentre scaricano scie (Chimiche) e che per la prima volta in vita mia vedo spuntare davanti agli occhi di tutti, in pieno giorno. Il servizio continuava con la rassicurazione che le emissioni degli aerei (Contrails) sarebbero state a breve ridotte……e quelle CHIMICHE? Ridurranno anche quelle? Cioe’ chiuderanno H.A.A.R.P e accantoneranno il folle progetto “Guerre stellari?”. Di sicuro un piccolo passo avanti e’ stato fatto. CHEMTRAIL’S ARE HERE.
Riferimenti: Le SCIE CHIMICHE SU RAI 2

Corso Congas Autodidatta

28 Luglio 2006 Commenti chiusi

http://www.congaplace.com/instrument/congas/indexita.php
Riferimenti: Corso Congas Autodidatta

Linux Command

27 Luglio 2006 Commenti chiusi

http://erlug.linux.it/~da/doc/comandi.txt

http://www.europe.redhat.com/documentation/rhl9/rhl-gsg-it-9/generated-index.php3
Riferimenti: LINUx COMMAND

Set Up Linux

27 Luglio 2006 Commenti chiusi

http://www.europe.redhat.com/documentation/rhl9/rhl-gsg-it-9/generated-index.php3
Riferimenti: Set Up Linux

IP TABLES

27 Luglio 2006 Commenti chiusi

http://www.mod-xslt2.com/people/ccontavalli/docs-it/iptables/iptables4dummies/iptables4dummies.html#toc12
Riferimenti: IP TABLES

Server Firewall Routing Linux 3

27 Luglio 2006 Commenti chiusi

Ok, abbiamo visto come configurare dei filtri ed il NAT. Mancano però ancora un paio di cosettine di cui sarebbe il caso di parlare.

Prima di tutto, soprattutto quando staremo correggendo gli errori nelle nostre regole, caricheremo e ricaricheremo il nostro script finché non vedremo queste regole funzionare (molte volte). Il fatto è che creando delle catene, non chiediamo di svuotarle nel caso queste esistano già, per cui continueremmo ad aggiungere regole su regole, non semplificandoci affatto la correzione degli errori.

Potreste quindi voler aggiungere qualcosa come:

for table in nat mangle filter
do
iptables -t $table -F
iptables -t $table -X
done

all’inizio del vostro script… che elimina tutte le catene e tutte le regole inserite in ogni tabella. Allo stesso modo, potreste voler aggiungere qualcosa come

(
for interface in eth0 eth1 eth2 eth3
do
ip route flush dev $interface
ip addr flush dev $interface
ip link set down dev $interface
done;
) &>/dev/null

Sempre all’inizio del nostro script, per riportare tutte le interfacce e le impostazioni ad uno stato conosciuto, in modo che non si vadano in continuazione ad aggiungere route o indirizzi, che, aggiunti per ultimi, verrebbero ignorati in favore di vecchie configurazioni che si combinerebbero e mischierebbero in maniera poco prevedibile. Comunque, “ip route flush dev ethx” elimina tutti i route relativi ad ethx, “ip addr flush” elimina tutti gli indirizzi dell’interfaccia ed infine “ip link set down” spegnere la scheda di rete.

Infine, dobbiamo attivare le nostre interfacce di rete, configurare la tabella di routing ed abilitare il “forwarding”, dicendo al kernel di iniziare a trasmettere i pacchetti da una scheda di rete all’altra:

86: ip link set up dev eth0
87: ip link set up dev eth1
88: ip link set up dev eth2

89: ip route add default via 123.45.68.254

90: echo 1 > /proc/sys/net/ipv4/ip_forward

In questo caso, ip_forward non può essere aggiunto al file sysctl.conf, in quanto vogliamo che il forwarding venga attivato solo dopo che abbiamo impostato correttamente le regole di firewalling.

Non ci resta quindi che creare in /etc/rcS.d/ o rc2.d (a secondo della distribuzione) un link al file appena completato, in modo che questo venga eseguito ad ogni reboot, con qualcosa come “ln -s ../init.d/ifconffw ./S40ifconffw” oppure “update-rc.d ifconffw start 40 S” in Debian.

Se il firewall ha un indirizzo ip diverso per ogni interfaccia ed utilizza come gateway il gateway fornito dal vostro provider, i vostri client dovranno utilizzare come gateway, come cancello che gli permetta di connettersi ad altre reti, l’indirizzo ip del vostro firewall relativo alla rete cui il vostro client è collegato.

Un server collegato alla dmz dovrà quindi utilizzare come gateway l’indirizzo ip della vostra interfaccia collegata alla DMZ. Allo stesso modo un client collegato alla LAN dovrà utilizzare come gateway l’indirizzo ip dell’interfaccia collegata alla lan. Per il resto, la configurazione dei client dipenderà principalmente dai server presenti (proxy, socks…) e dai giochini che avrete deciso di fare col NAT.

Sebbene sia veramente poco piacevole, è possibile utilizzare iptables direttamente da riga di comando.

Nonostante questo, alcune di queste funzioni possono risultare molto utili in fase di testing. Ad esempio, dovendo fare delle misure di banda può essere utile consentire temporaneamente solo il traffico tra determinate macchine, e non è il caso di perdere tempo a modificare file di configurazione o script dalla provata affidabilità. Ok, iniziamo quindi col vedere le regole attive sul kernel da me correntemente utilizzate, col comando “iptables -nL”, dove “n” dice di non risolvere i nomi (passando da indirizzi ip a nomi di domini) e “L” di “listare” o elencare (in italiano) tutte le regole:

Chain INPUT (policy DROP)
target prot opt source destination
ACCEPT all — 0.0.0.0/0 0.0.0.0/0
ACCEPT tcp — 0.0.0.0/0 0.0.0.0/0 tcp dpt:22
ACCEPT all — 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
REJECT tcp — 0.0.0.0/0 0.0.0.0/0 reject-with tcp-reset

Chain FORWARD (policy DROP)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

-n lo uso principalmente perché altrimenti ci metterebbe molto tempo a generare l’output (tentando di connettersi al database), per il resto, credo che l’output in se stesso credo che risulti abbastanza autoesplicativo… un problema di “iptables -nL” (rispetto ad usare un file di configurazione) è che molti dettagli non vengono mostrati e comunque la leggibilità è molto minore.

Per avere più dettagli, comunque, è possibile utilizzare l’opzione “-v” o “-vv”, con un comando simile a “iptables -v -nL”:

Chain INPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
41512 83M ACCEPT all — lo * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT tcp — * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22
0 0 ACCEPT all — * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
0 0 REJECT tcp — * * 0.0.0.0/0 0.0.0.0/0 reject-with tcp-reset

Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

Chain OUTPUT (policy ACCEPT 41513 packets, 83M bytes)
pkts bytes target prot opt in out source destination

ancora, l’output è abbastanza autoesplicativo. Se state leggendo il pdf notate però come le righe vengono troncate. Immaginate su un terminale con le classiche 80 colonne cosa verrebbe fuori.

Se siete interessati ad un’unica catena, potete specificarne il nome dopo il “-nL”. Con qualcosa di simile a “iptables -vv -nL INPUT” vedreste solo la catena di “INPUT” ed un dump delle informazioni del kernel. Come altre opzioni generiche, potete utilizzare “-x”, che mostrerà i valori esatti dei contatori, mentre “-Z” li azzererà, oppure “-t nometabella” per visualizzare altre tabelle.

Già conosciamo i parametri:

* -N — per creare nuove catene
* -X — per eliminare una catena (tutte, se non viene specificato un argomento)
* -F — per eliminare tutte le regole di una catena (tutte, se non viene specificato un argomento)
* -A — per aggiungere regole alle catene
* -P — per impostare le politiche

In più, vi possono tornare utili i comandi

* -I — per inserire una nuova regola in una determinata posizione di una catena
* -R — per sostituire una regola con un’altra
* -D — per rimuovere una regola

Cerchiamo però di vedere questi parametri nella pratica. Ipotizzando di avere una situazione come quella mostrata sopra con “iptables -nL”, immaginiamo di voler inserire una regola dopo quella relativa ad ssh (catena di INPUT, porta 22, riga 2) per consentire l’accesso ad un web server installato sul mio portatile. In questo caso, potremmo dare un comando come

iptables -I INPUT 3 -p tcp –dport 80 -j ACCEPT

Il 3 indica che questa regola deve essere inserita nella terza riga, spostando tutte le altre righe più in basso. Dopo questo comando, “iptables -nL INPUT” mostrerebbe qualcosa come

Chain INPUT (policy DROP)
target prot opt source destination
ACCEPT all — 0.0.0.0/0 0.0.0.0/0
ACCEPT tcp — 0.0.0.0/0 0.0.0.0/0 tcp dpt:22
ACCEPT tcp — 0.0.0.0/0 0.0.0.0/0 tcp dpt:80
ACCEPT all — 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
REJECT tcp — 0.0.0.0/0 0.0.0.0/0 reject-with tcp-reset

proprio come volevamo. Immaginiamo ora di spostare il web server sulla porta 443, e di voler rimpiazzare la regola appena inserita con qualcosa come “-p tcp –dport 443 -j ACCEPT”. In questo caso sarebbe sufficiente utilizzare

iptables -R INPUT 3 -p tcp –dport 443 -j ACCEPT

per ottenere qualcosa come

Chain INPUT (policy DROP)
target prot opt source destination
ACCEPT all — 0.0.0.0/0 0.0.0.0/0
ACCEPT tcp — 0.0.0.0/0 0.0.0.0/0 tcp dpt:22
ACCEPT tcp — 0.0.0.0/0 0.0.0.0/0 tcp dpt:443
ACCEPT all — 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
REJECT tcp — 0.0.0.0/0 0.0.0.0/0 reject-with tcp-reset

Infine, per rimuovere la regola, basterebbe qualcosa come

iptables -D INPUT 3

Se siete meno pigri di me, potete utilizzare anche

iptables -D INPUT -p tcp –dport 443 -j ACCEPT

che porterebbe esattamente allo stesso risultato.
Versioni relativamente recenti di iptables mettono anche a disposizione due tools: iptables-save ed iptables-restore. Il primo, stampa a video in un formato standard tutte le regole di firewalling, mentre il secondo è in grado di leggere delle regole in questo formato standard da standard input e di impostarle nel kernel. Ad esempio, per salvare delle regole correntemente utilizzate dal kernel, è possibile utilizzare il comando:

# iptables-save > nomefile

mentre per ripristinarle il comando

# iptables-restore < nomefile

In Debian, è possibile utilizzare “/etc/init.d/iptables save nomefile'' oppure “/etc/init.d/iptables load nomefile''. Utilizzando come nomefile “active'', le regole verranno automaticamente caricate ad ogni accensione della macchina. In quest'ultimo caso, potreste voler dare un'occhiata a /etc/default/iptables.
Le funzioni viste qua sopra non costituiscono probabilmente neanche il 25% di tutto ciò che il kernel 2.4 può fare. Mi basti ricordarvi che delle tre tabelle a disposizione ne abbiamo utilizzate soltanto 2 e che molte delle nuove funzionalità sono state soltanto accennate, senza dimenticare poi che nulla è stato visto in proposito del QoS e del fair queuing. Giusto per stuzzicare la vostra curiosità, la tabella di mangle serve per “maneggiare'' i pacchetti in maniera più sottile, in modo che comandi come ip e tc possano interagire tra di loro distinguendo pacchetti scelti da iptables o per modificare i parametri del pacchetto (modulo ttl & co.).

Giusto per fare un accenno, il fair queuing si gestisce attraverso il comando tc, e consente di suddividere tutti i pacchetti in transito in classi, dove ogni classe può avere una certa larghezza di banda riservata o una certa priorità. Si potrebbe poi parlare di funzioni come il proxy_arp, che in combinazione con il modulo ttl consentono di creare dei firewall (praticamente) invisibili.

Riferimenti: Server Firewall Routing Linux 3

Server Firewall Routing Linux 2

27 Luglio 2006 Commenti chiusi

Passando dalla teoria alla pratica, occorre prima di tutto parlare in maniera un pochettino più approfondita dei target di default messi a disposizione dalla tabella di NAT.

* SNAT: serve per modificare il mittente di un pacchetto (l’indirizzo ip sorgente). Viene utilizzato nella catena di POSTROUTING proprio perché il cambiare il mittente non interferisce sulla scelta dell’interfaccia da utilizzare per raggiungere il destinatario. Consente anche di modificare manualmente la porta sorgente di un pacchetto. Attenzione! Funziona solo con indirizzi ip statici!
* DNAT: serve per modificare il destinatario di un pacchetto (l’indirizzo ip destinatario). Viene utilizzato nella catena di PREROUTING in quanto la modifica deve essere effettuata prima di decidere da che parte fare uscire il pacchettino. E’ possibile inoltre specificare una diversa porta di destinazione.
* MASQUERADE: è un tipo particolare di SNAT: fa in modo che i pacchettini abbiano come mittente l’indirizzo IP della interfaccia di rete dalla quale usciranno. Si utilizza nella tabella di POSTROUTING (modifica il mittente) e viene utilizzato al posto dello SNAT su interfacce con IP assegnato dinamicamente, ad esempio tramite dhcp o bootp.
* REDIRECT: è una versione semplificata del DNAT mantenuta più che altro per motivi di compatibilità e fa in modo che il pacchettino venga rediretto sulla macchina locale (127.0.0.1) ad una porta specifica. Equivale a qualcosa del tipo: -j DNAT –to 127.0.0.1:porta -j REDIRECT –to-ports porta.

Esistono molti altri target che possono essere aggiunti tramite il patch-o-matic adatti a tutte le esigenze. Date un’occhiata al manuale di iptables ed alle informazioni mostrate sullo schermo durante l’aggiornamento di iptables per maggiori informazioni.

Tornando invece al nostro esempio (presentato nei paragrafi sul filtraggio), è per noi indispensabile utilizzare il NAT in quanto:

* dobbiamo “deviare” tutti le connessioni web verso internet sul nostro proxy server che si trova nella dmz (transparent proxy).
* dobbiamo fare in modo che la nostra rete interna che utilizza indirizzi ip di classe 192.168.200.x (indirizzi per reti private) possa navigare su internet.

Avendo però spesso a che fare con reti di discrete dimensioni dove il dhcp è raramente utilizzato, mi piace aggiungere alcune regole per rendere le macchine “indipendenti” dalle modifiche del provider di turno o eventuali riconfigurazioni della rete (vi è mai capitato di dover cambiare l’ip del dns su n macchine diverse, dove n tende ad infinito?).

Per fare questo normalmente si possono utilizzare diversi approcci:

* Se la rete è divisa in diverse sottoreti (subnet), si possono “inventare” due indirizzi ip che non risiedano su nessuna delle nostre reti ed impostare tutti i client per utilizzare quegli indirizzi ip come dns primario e secondario.
* Si possono semplicemente deviare tutti i pacchetti destinati ad un dns verso il dns reale (c’è il problema del dns secondario, però).
* Semplicemente ignorare il problema inizialmente ed in caso di cambio di ISP aggiungere due regole per deviare il traffico sui nuovi dns.

Trattandosi comunque di regole abbastanza semplici ed interessanti dal punto di vista didattico, verranno presentate tutte e tre le soluzioni (la prima è quasi perfettamente equivalente alla terza).

Vediamo quindi le nostre prime regole di NAT:

77: iptables -t nat -A PREROUTING -p tcp -i eth0 –dport www -j DNAT –to nostro.proxy.server:8080
78: iptables -t nat -A POSTROUTING -o eth2 -s 192.168.200.0/24 -j SNAT –to 123.45.68.1

Ok, la prima regola dice, a parole, di inserire una regola nella tabella di nat per intercettare tutti i pacchetti provenienti da eth0 e destinati ad un server www (porta 80 — prima che venga deciso da che interfaccia farli uscire) e di deviarli sul nostro.proxy.server porta 8080.

Attenzione però che proxy server come squid devono essere configurati per poter accettare connessioni deviate in questo modo, in quanto non seguono perfettamente lo standard utilizzato dai proxy (leggete la documentazione di squid!).

Tornando a parlare delle regole, la seconda dice di modificare il mittente (l’indirizzo ip sorgente) dei pacchetti uscenti da eth2 e provenienti dalla nostra LAN (192.168.200.0/24) con l’indirizzo ip esterno del nostro firewall.

A proposito di queste due regole ci sono alcune cose importanti da dire:

* Prima di tutto, nella prima regola si è reso necessario indicare la scheda di rete sorgente in modo da non deviare le richieste del nostro proxy server. Per la cronaca: quando facciamo una richiesta al nostro proxy server, questo se non ha le pagine richieste in cache dovrà collegarsi al server web richiesto, e dobbiamo quindi stare attenti a non deviare anche le richieste provenienti dal proxy (si creerebbe una sorta di circolo vizioso (loop) né molto bello né molto positivo per la salute della nostra rete).
* Nella seconda regola, invece, è importante fare in modo che soltanto i pacchetti provenienti dalla nostra rete interna (e non dalla DMZ!) vengano modificati e soltanto quelli uscenti verso internet (quelli destinati al nostro proxy non devono essere toccati: saremo così in grado di fare un minimo di statistiche sui siti più interessanti per i nostri utenti).
* Nella seconda regola, è fondamentale fare in modo che i pacchetti abbiano come mittente uno degli indirizzi ip esterni del firewall. Per chi si accontenta di poche parole, basti dire che in caso contrario non funzionerebbe. Per tutti gli altri, invece, il motivo sta nell’arp, address resolution protocol. Ovvero, se l’indirizzo ip non fosse uno di quelli del firewall (aggiunti con ip o ifconfig, per intenderci), il firewall non risponderebbe alle query ARP, ed i pacchetti uscirebbero felici dalla rete ma il gateway di default del nostro firewall non sarebbe in grado di rimandare i pacchetti indietro. Come sempre, linux lascia la massima libertà: sta all’amministratore evitare di farsi male con errori di questo tipo.
* Riferendosi al funzionamento del SNAT come prima descritto, a volte (in reti particolarmente affollate) potrebbe essere indispensabile utilizzare più indirizzi ip per effettuare lo SNAT (il numero di porte disponibili ed utilizzabili su un host per fare il giochettino descritto è abbastanza limitato). Il target fortunatamente consente di indicare più indirizzi ip (date un’occhiata al manuale di iptables).

L’esperienza però mi insegna che in tali reti si supererebbe molto prima il numero massimo di connessioni tracciabili rispetto alle porte disponibili. Per aumentare questo numero, basta dare un:

echo 16384 > /proc/sys/net/ipv4/ip_conntrack_max

o, in maniera del tutto equivalente, scrivere qualcosa come

net.ipv4.ip_conntrack_max=16384

nel file /etc/sysctl.conf. Comunque sia, tenete presente che già una rete di 100-200 computer potrebbe aver bisogno di essere in grado di tracciare più connessioni, mentre non mi è ancora capitato di dover utilizzare più di un indirizzo ip in uscita.

Il kernel comunque, vi avviserà in caso fosse necessario aumentare questi limiti, con un messaggio nei log per ogni connessione scartata.
* Nell’ultima regola, infine, se avessimo avuto a disposizione una connessione dial-up (come isdn) o tramite adsl con indirizzi ip assegnati dinamicamente, si sarebbe dovuto usare come target “MASQUERADE”, senza però specificare alcun indirizzo ip sorgente. Attenzione! Lo SNAT proprio non funziona su interfacce con ip dinamici assegnati! Potete vedere un esempio di come utilizzare il target MASQUERADE in uno dei paragrafi introduttivi…
* Per quanto riguarda le regole di NAT e filtraggio, è fondamentale notare (per poter ottenere un firewall funzionante) che le regole di firewalling, inserite nella tabella di filter, vedranno i pacchetti con i loro indirizzi reali. Nel caso di DNAT, per esempio, il filtro vedrà pacchetti con la destinazione modificata (in questo caso, il proxy server). In caso invece di SNAT, il filtro vedrà come mittente l’indirizzo reale del mittente (non quello modificato), come se il codice di filtraggio fosse inserito dopo la catena di PREROUTING ma prima della catena di POSTROUTING.

Volendo fare il giochettino con il DNS, le due possibilità sono realizzabili utilizzando o queste regole:

80: iptables -t nat -A PREROUTING -p tcp –dport domain -j DNAT –to nostro.dns
81: iptables -t nat -A PREROUTING -p udp –dport domain -j DNAT –to nostro.dns

che deviano tutto il traffico verso un qualsiasi dns su nostro.dns, o queste altre, che similmente intercettano il traffico verso un dns da noi specificato e deviano il traffico verso il nostro dns reale:

83: iptables -t nat -A PREROUTING -p tcp -d un.dns –dport domain -j DNAT –to nostro.dns
84: iptables -t nat -A PREROUTING -p udp -d un.dns –dport domain -j DNAT –to nostro.dns

A questo punto, non vi rimane che divertirvi con i pacchetti che fluiscono dalle vostre reti.
Riferimenti: Server Firewall Routing Linux 2

Server Firewall Routing Linux

27 Luglio 2006 Commenti chiusi

http://www.mod-xslt2.com/people/ccontavalli/docs-it/iptables/iptables4dummies/iptables4dummies-29.htmlIl NAT consente ad un firewall o router linux di non limitarsi a bloccare o consentire i pacchetti in transito, bensì anche di modficarli secondo delle regole ben definite.

Il codice che in linux gestisce il NAT è stato completamente ridisegnato per iptables ed il risultato è stato un sistema molto più pulito e flessibile rispetto quello utilizzato da ipchains. ipchains, per effettuare modifiche ai pacchetti, utilizzava semplicemente dei target diversi come MASQ (per mascherare i pacchetti). Questo però creava molta confusione sul meccanismo di scansione delle regole ed andava ad interferire con le regole di filtraggio. In iptables, invece, la parte di filtraggio dei pacchetti è completamente indipendente da quella di modifica e di gestione delle regole di nat. Per raggiungere questa indipendenza è stato infatti introdotto il concetto di “tabella” di cui fin’ora non avevamo parlato. Ebbene, le 3 catene principali di cui abbiamo parlato fin’ora (INPUT, OUTPUT, FORWARD) si trovano nella tabella “filter”. La tabella di filter è quella che viene scelta in automatico se non viene specificata un’altra tabella (per questioni di compatibilità).

Esistono quindi altre tabelle in iptables, ognuna delle quali mette a disposizione diverse catene di base:

* la tabella filter, le cui catene principali sono INPUT, OUTPUT, FORWARD
* la tabella nat, le cui catene principali sono PREROUTING, OUTPUT, POSTROUTING
* la tabella mangle, le cui catene principali sono PREROUTING, OUTPUT

Beh, ci sono 3 tabelle in totale. La prima, che normalmente non viene mai indicata esplicitamente, che serve per filtrare i pacchetti. La seconda, quella di nat, che serve normalmente per modificare ciò che ha a che vedere col mittente o il destinatario di un pacchetto, ed infine la tabella di mangle che consente di modificare tutte le altre caratteristiche dei pacchetti.

La distinzione tra mangle e nat non è così netta, si tratta soltanto di un criterio di base, ed il manuale vi saprà sicuramente indicare la tabella migliore da utilizzare a secondo delle vostre necessità.

Ma guardiamo meglio i nomi delle catene: nella tabella filter, ci troviamo le solite INPUT, OUTPUT, FORWARD, col significato che ormai conosciamo. Nella tabella di nat abbiamo invece 3 nuove catene: la catena di PREROUTING, la catena di OUTPUT e la catena di POSTROUTING. La catena di OUTPUT mantiene lo stesso significato che aveva nella tabella di filter. La catena di PREROUTING e quella di POSTROUTING classificano invece i pacchetti diversamente: non più in base alla direzione dei pacchetti, bensì al fatto che sia già stata presa una decisione di routing su questi pacchetti. Vediamo di spiegare meglio l’idea: quando un pacchetto di qualsiasi protocollo deve uscire da una macchina connessa ad una rete (poco importa la provenienza del pacchetto) deve essere presa una decisione di routing. Deve cioè essere stabilito da che interfaccia dovrà uscire questo pacchetto e con quali caratteristiche dovrà essere mandato (es, il TTL dovrebbe essere decrementato, l’MTU potrebbe essere diverso e necessitare una frammentazione, l’indirizzo hardware specificato potrebbe essere quello di un gateway…). Dal punto di vista logico, quindi, ogni pacchetto che deve uscire da un’interfaccia di rete passa prima dalla catena di PREROUTING, viene presa una decisione sull’interfaccia da cui fare uscire il pacchetto, dopodichè passa dalla catena di POSTROUTING.

PREROUTING e POSTROUTING sono state introdotte proprio per consentire di realizzare diversi comportamenti: ad esempio, se si vuole cambiare l’indirizzo di destinazione di un pacchetto sarà importante farlo prima che venga deciso da dove fare uscire il pacchetto (se così non fosse, il pacchetto uscirebbe dall’interfaccia sbagliata, a meno che questo non sia l’effetto desiderato). Mentre, al contrario, quando si cambia il mittente di un pacchetto potrebbe essere importante farlo dopo che una decisione di routing è stata presa (in questo caso però l’errore non sarebbe così palese).

Comunque sia, in ognuna di queste tabelle è possibile specificare dei target differenti utilizzando però le stesse opzioni e gli stessi moduli per creare delle regole. Di base, i target più conosciuti per la tabella di NAT sono proprio:

* SNAT consente di cambiare l’indirizzo ip sorgente di un pacchetto (POSTROUTING)
* DNAT consente di cambiare l’indirizzo ip destinazione di un pacchetto (PREROUTING)
* MASQUERADE consente di cambiare l’indirizzo ip sorgente di un pacchetto (verrà spiegata in seguito la differenza – POSTROUTING).
* REDIRECT consente di cambiare la porta di destinazione di un pacchetto (PREROUTING)

Torniamo ora al nostro esempio: la nostra lan utilizza degli indirizzi ip del tipo 192.168, e come tali non possono viaggiare su internet (192.168 è una classe di indirizzi ip riservati per reti private). Per consentire quindi ai computer della nostra rete di navigare, sarebbe necessario o un proxy (che però gestisca tutti i protocolli) o fare in modo che l’indirizzo ip sorgente dei pacchetti originati dalla nostra rete venga cambiato con un indirizzo ip valido per viaggiare in internet (come quello del nostro firewall, per esempio).

Realizzare questo a livello di regole di iptables è estremamente facile. Bisogna però fare una piccola introduzione e dare un minimo di spiegazioni. A molti di voi, ad esempio, sarà sorto spontaneo chiedersi come diavolo può fare un firewall a nascondere 20 computer (per esempio) dietro un unico indirizzo ip. Voglio dire, in uscita funziona bene: il client FOO dietro il firewall manda un pacchettino al gateway (il nostro firewall), il nostro firewall cambia l’indirizzo ip sorgente col suo (valido su internet) e manda avanti il pacchettino, il server remoto risponde, il pacchettino torna indietro, e… il pacchettino che gli torna indietro ha come mittente il server remoto, come destinatario il firewall… non sembra funzionare tanto… come fa il firewall a capire a quale dei nostri client deve rimandare il pacchetto, se l’indirizzo di destinazione è il suo indirizzo esterno? E anche ipotizzando di avere un indirizzo ip solo per i client, come farebbe a mandare la risposta al client corretto? Se guardasse l’indirizzo ip del server remoto, solo un client per volta potrebbe navigare su un determinato sito… non proprio funzionale. Una soluzione potrebbe essere quella di avere tanti ip esterni quanti client. Ma allora perché usare il nat? La sicurezza potrebbe essere un buon motivo, ma normalmente il nat si usa quando ci sono meno (o molti meno) indirizzi esterni a disposizione rispetto ai client della propria rete (attualmente, gli indirizzi ip hanno un costo, e non indifferente).

Beh, la soluzione che è stata trovata per risolvere questo problema si basa sull’idea di porta. Quando stabilite una connessione tcp verso un server, l’unica porta veramente importante è quella di destinazione, che identifica univocamente un servizio. Quella mittente, invece, non viene quasi mai guardata e spesso viene scelta a caso.

Con il NAT, il nostro firewall linux cambierà (se necessario) la porta sorgente dei pacchetti in uscita ed utilizzerà quella per identificare univocamente un client. Se la soluzione vi convince poco, provate a pensare al flusso dei pacchetti… il client A manda un pacchetto proveniente da A porta x al server B porta 80. Il firewall riceve il pacchetto, cambia x in y (dove x può essere uguale a y, se tale porta non è utilizzata da nessuno), si segna che y è associata solo ad A e cambia l’indirizzo ip sorgente con il suo, il pacchetto arriva al server remoto R porta 80 come proveniente da F:y, e risponde creando un pacchetto proveniente da R:80 e destinato al firewall F porta y. Firewall riceve il pacchetto, vede che la connessione non è stata creata direttamente da lui (ogni sistema operativo sa quali connessioni ha iniziato) cerca nella tabella e vede che la porta y era in origine x ed era associata al client A. Prende il pacchetto, modifica il destinatario in modo che indichi A porta x e rimanda il pacchetto ad A. Sembra funzionare, no? L’idea è abbastanza furba e permette di identificare univocamente un client utilizzando qualche bit in più di informazioni. Il problema è che a volte questa tecnica non funziona:

* ad esempio, quando la trasmissione non fa uso del concetto di porta (solo le trasmissioni tcp e udp hanno delle porte associate). Fortunatamente però, oltre all’icmp, non esistono protocolli realmente utilizzati che non usino il concetto di porta, e gli errori sono facilmente associabili (non sono specifici al client: se un server non è raggiungibile, questo non sarà raggiungibile per tutti i client dietro al NAT box). Cioè, questi protocolli esistono ma vengono comunque normalmente gestiti non dal kernel ma da demoni dedicati per cui il problema non si pone.
* ad esempio, quando c’è bisogno che i pacchettini provengano da una porta specifica: un client, nascosto dal firewall, non saprà mai in realtà che porta sorgente utilizzerà il firewall per rispedire i suoi pacchetti.
* ad esempio, quando il protocollo si basa su connessioni effettuate da un server esterno verso un client interno.

Per vedere dove sta il problema, proviamo a vedere un esempio. Ipotizziamo che il solito client FOO si colleghi a uno strano server con uno strano protocollo. Per via di questo strano protocollo, il server deve aprire una connessione verso la porta 789 del client e tenta quindi di collegarsi. Quello che però per lui è l’indirizzo del client è in realtà l’indirizzo del firewall, per via del NAT che ha cambiato l’indirizzo del mittente.

Così facendo, il server tenterà di collegarsi al firewall, che però questa volta non avrà nessuna associazione nella sua tabella (l’associazione si crea solo per le connessioni che escono, e non è possibile indovinarle per quelle che entrano, a meno che non vengano stabilite a priori dall’amministratore) e sarà quindi costretto a buttare via il pacchetto rispondendo al server con un messaggio icmp con scritto qualcosa del tipo “la porta è chiusa e io non so chi tu sia”.

Fortunatamente però il primo caso è estremamente raro (non credo sia stato mai nemmeno preso in considerazione il problema), il secondo capita ancora molto raramente, mentre per il terzo esistono delle soluzioni: il tracciamento delle connessioni.

Infatti, i moduli del kernel prima caricati che si occupavano di aprire o chiudere dinamicamente le porte sono anche in grado di aggiungere o rimuovere associazioni dalla famosa tabella, o di fare delle piccole modifiche al protocollo in modo che questo possa funzionare. Per fare questo però, se non avete compilato staticamente il kernel, dovete caricare anche i moduli “ip_nat_ftp”, “ip_nat_irc” o “ip_nat_protocollo_strano_che volete usare” con il solito “modprobe”.

Il problema che a volte si incontra, però, è che questi moduli non sono proprio facili da scrivere, per cui è relativamente facile trovarne per i protocolli standard, mentre non esistono per quei protocolli inventati dalla fantasia dei venditori di software di turno, che non sentono il dovere morale di rispettare degli standard.

Normalmente i problemi si incontrano solo per parti dei vari “protocolli” (ad esempio, dietro un firewall linux di questo tipo, col messanger sarebbe difficile farsi mandare dei file da altri utenti, pur funzionando per tutte le altre cose). E se per ftp e IRC (anche netmeeting, ma sperimentale) sono stati scritti dei moduli, per altri protocolli meno utilizzati credo che sarà difficile che qualcuno si occupi di realizzarli.

In questi casi, un “socks server” vi consentirà il più delle volte di rendere felici i vostri utenti. Il prezzo da pagare è che un socks server di base è molto aperto ed una configurazione errata o superficiale di questo potrebbe vanificare completamente i vostri sforzi. In più, preparatevi a ricevere chiamate a tutte le ore del tipo “come si fa ad impostare il socks server su fuffolo 3.0 piuttosto che kazzat 2.8”
Riferimenti: Server Firewall Routing Linux

Mandriva Firewall

27 Luglio 2006 Commenti chiusi

Author: network
Date: 2006-01-20 07:55 +100
To: network
Subject: Re: [network] gateway mandriva
Ho fatto il test proprio ora nella mia lan, che assomiglia un po alla tua.

Apri una shell (se sei sotto X apri una konsole) e dopo essere diventato
root (con “su”), digita:
route add -host 192.168.2.1 eth0

Suppongo ci sia una sola scheda di rete, se ce ne dovessero essere piu’
d’una (verifica col comando “ifconfig”, sono le voci eth0, eth1 eth2 ecc)
ripeti tutto il procedimento con ognuna delle schede sostituendo eht0 con
eth1 ecc.

ping 192.168.2.1

Poi per internet digita:
route add -net default gw 192.168.2.1

Ah non dimenticare di impostare un server dns per la risoluzione dei
dominii, per farlo sotto shell apri (con pine per tua comodita’)
/etc/resolv.conf, cancella tutto e inserisci
nameserver 212.216.112.112
dove l’indirizzo ip e’ un server dns valido, questo indicato e’ della
telecom e funziona (nel caso non ne avessi uno valido).

ping aruba.it

ora dovrebbe funzionare ^^

Scusa ma non usando madriva non conosco i suoi tool grafici

Ciao

Riferimenti: Mandriva Firewall

http://youtube.com/

24 Luglio 2006 Commenti chiusi

http://youtube.com/
Riferimenti: http://youtube.com/