:Author: Andrea Manni
:Copyright: GFDL
- :Version: 0.4
+ :Version: 0.7
Questa guida e' dedicata agli studenti delle lezioni di informatica tenute da Andrea nel lab208. Nella parte iniziale sono presenti alcuni richiami alle impostazioni di rete e di installazione del laboratorio 208 (lab208) dove generalmente si tengono le lezioni. Questi parametri non sono interessanti per chiunque si trovasse al di fuori della rete piffa.net .
Impostazioni di base per la configurazione del sistema operativo e della rete nel laboratorio 208 facente parte della rete piffa.net .
-Qui riportati per comodita' degli studenti (e del docente che non sara' **mai piu'** costretto a ripeterli! )
+Qui riportati per comodita' degli studenti (e del docente che non sara' **mai piu'** costretto a ripeterli continuamente! ). Gli altri lettori potranno tenerli presenti per cercare di comprendere gli esempi nel testo. Ad esempio: quando leggerete ``10.10.208.254:3128`` saprete che si tratta del nostro *proxy http*, stara' quindi a voi sostituire i dati con gli *ip* della vostra rete.
Rete
------
DNS 10.10.208.254
DNS 10.10.208.250
persistente
+proxy http 10.10.208.254:3128
============= ================
-Sul portatile di Andrea, corrispondente all'ip 254, gira un DHCP, proxy http e mirror di Debian ( http://debian.piffa.net). Se Andrea non e' in aula (o ancora peggio non c'e' il suo portatile Net) gli studenti dovranno darsi un indirizzo ip manualmente e disabilitare il proxy (che pero' e trasparente, quindi fate pure come se non ci fosse ;) .
+Sul portatile di Andrea, corrispondente all'ip 254, gira un DHCP, proxy http e mirror di Debian ( http://debian.piffa.net). Se Andrea non e' in aula (o ancora peggio non c'e' il suo portatile Net) gli studenti dovranno darsi un indirizzo ip manualmente e disabilitare il proxy (che pero' e trasparente, quindi fate pure come se non ci fosse ;) . Questo in attesa che si sappia se sara' nuovamente utilizzabile il vecchio server Bender.
+
+interfaces
+~~~~~~~~~~~~~~~
+
+Segue un esempio del file di configurazione della scheda di rete con configurazione statica::
+ # /etc/network/interfaces -- configuration file for ifup(8), ifdown(8)
+
+ # The loopback interface
+ iface lo inet loopback
+
+ # La prima scheda di rete (se si chiama eth0)
+ # (network, broadcast and gateway sono optional)
+ iface etho inet static
+ # esempio con dhcp
+ # iface etho inet dhcp
+ address 212.22.136.101
+ netmask 255.255.255.0
+ network 212.22.136.0
+ broadcast 212.22.136.255
+ gateway 212.22.136.254
+
+ # Quali interfaccie devono partire automaticamente:
+ auto lo eth0
+
+Controllare il nome della propia scheda di rete: a volte *udev* rinomina la prima scheda a ``eth1``, oppure potreste avere piu' di una scheda di rete (anche un'interfaccia *firewire* puo' essere automaticamente abilitata come scheda di rete).
+
+Se si usano *schede di rete virtuali* ( eth0:1 , eth0:1 , ...) ricordarsi che queste dipendono dalla scheda fisica a cui sono associate: abbattere con ``ifconfig down eth0`` la scheda principale fara' cadere anche queste. Tornando ad attivare la schda principale con ``ifconfig eth0 up`` la virtuale tornera' attiva: nel caso voleste disabilitarla dovrete quindi sempre abbattere manualmente la scheda virtuale *prima* della scheda reale.
Bash completion
-------------------
Squid
======
+Squid e' un proxy cache http (ma anche FTP e https) robusto e strutturato, puo' essere usato sia in reti relativamente piccole grazie alla semplicita' di configurazione che in scenari piu' complessi grazie alla possibilita' di gestirne in modo granulare le risorse partendo dalle configurazioni piu' semplici per la semplice *condivisione della navigazione* internet, la gestione degli accessi, il filtraggio dei contenuti (Squid e' una applicazione che si muove nel 4' livello del modello TCP/IP a differenza di un *ipfilter* limitato al 2') nel l bilanciamento del carico tra piu' hosts.
+
+Inoltre svolge la funzione di *anonymizer*:
+ nasconde i client http alla rete internet: risulta solo il server proxy nei log dei server web frequentati dagli utenti di Squid.
+
+Cosa a volte sottovalutata, squid permette la navigazione web a una rete basata su *indirizzi ip privati* (es una 192.168.0.0/24). E se la rete privata deve *solo navigare* in internet, non serve un *NAT* od altro, basta il solo Squid. Per altro non servira' neanche un servizio DNS dato che *sara' il solo squid a risolvere i nomi di dominio* per i suoi client http.
+
+Squid ascolta di default sulla porta 3128, per impostare *apt* per utilizzarlo si aggiunga ad ``/etc/apt/apt.conf`` ::
+
+ Acquire::http::Proxy "10.10.208.254:3128";
+
+
Per installare Squid si usino i pacchetti::
squid3
Configurazione: squid.conf
-------------------------------
-Segue un estratto del file di configurazione::
+Segue un estratto delle direttive principali viste in aula presenti nel file di configurazione ``/etc/squid3/squid.conf`` .
+
+Cache_dir
+~~~~~~~~~~~~
+
+Cache dir serve per impostare dimensione e percorso della cache creata sul supporto di storaggio. Essendo la dimensione di default della cache pari a ``~100 MB`` e' altamente consigliabili aumentare questo parametro se si vuole poter utilizzare la funzione di *cache* http del software.
- #TAG: cache_dir (1628)
+La dimensione ovviamente dipendera' dallo spazio disponibile, dimensioni tipiche e massime degli oggetti che si vuole tenere in cache (un solo file *.iso e' circa ``700 MB``, il pacchetto *Openoffice.org* cira ``150 MB``, un pacchetto debian circa ``20 MB``), numero dei client.
+
+Si presti poi attenzione alla natura dei dati che saranno salvati nella cache: sono tutti dati facilmenti sostituibili (gli originali sono *on-line*) la cui perdita non arreca danni permanenti. Questo rende la cache di Squid un possibile candidato ad un *RAID stripe* (livello 0), con vantaggi sia per le prestazioni (e la velocita' di navigazione e' uno dei motivi per cui si installa Squid) che per l'utilizzo estensivo dello spazio di storaggio. Questo fino al momento in cui per voi non sia piu' importante *garantire la disponibilita' del servizio* (se il RAID stripe dovesse rompersi gli utenti non potrebbero piu' navigare, cosa che per natura dello stripe e' maggiormente probabile rispetto ad un *mirror* o a un filesytem *normale*) con un RAID mirror o 5.
+
+Altra considerazione: i dati del proxy vengono slavati sul filesytem del server dietro richiesta di utenti esterni talvolta sconosciuti. Come per i servizi di file sharing o per la posta elettronica non c'e' motivo che il filesystem su cui sono ospitati questi dati abbia i privilegi di eseguibilita' o suid (in genere si puo' anche usare *noatime* per renderlo piu' veloce, che si usi o meno il journal dipende dalle preferenze: affidabilita' oppure prestazioni):
+
+/etc/fstab ::
+
+ ...
+ # Filesystem per Squid http cache
+ /dev/md3/ /var/spool/squid/ ext3,noexec,nosuid,noatime 0 3
+
+Ora possiamo impostare la cache direttamente nel file ``/etc/squid3/squid.conf``::
+
+ #TAG: cache_dir (riga 1628)
# Usage:
#
# cache_dir Type Directory-Name Fs-specific-data [options]
# directory primo livello
# secondo livello di directory
-Se si modifica la struttura del filesytem della cache di Squid, ad esempio variando il numero delle directory, puo' essere (ed in genere lo e') opportuno rigenerare la struttura della cache di squid. Tipicamente e' opportuno cancellare la vecchia cache e poi generarne una nuova::
+Se si modifica la struttura del filesytem della cache di Squid, ad esempio variando il numero delle directory, puo' essere opportuno rigenerare la struttura della cache di squid (per lo meno se si *aumenta* il numero delle directory di primo o secondo livello). Tipicamente e' consigliabile cancellare (se si ha *ridotto* il numero delle diectory) la vecchia cache e poi generare una nuova struttura. Se si vuole *star nel sicuro* ogni volta che si modifica l'impostazione delle directory *si svuoti la vecchia cache e se ne generi una nuova* ::
# /etc/init.d/squid3 stop
# rm -r /var/spool/squid3/??
TAG: maximum_object_size
~~~~~~~~~~~~~~~~~~~~~~~~~~
-Questa direttiva imposta la dimensione massima degli oggetti che vengono slvati sul supporto di storaggio, oggetti di dimensioni superiori verranno scaricati ma non tenuti in cache.
+Questa direttiva imposta la dimensione massima degli oggetti che vengono slvati sul supporto di storaggio, oggetti di dimensioni superiori saranno comunque scaricati ma non tenuti in cache.
TAG: maximum_object_size (1760)::
TAG: cache_mem
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-*Cache_mem* imposta quanta memoria RAM utilizzare per la cache di Squid.
-Questo dipendera' dalla RAM disponibile sul sistema, e da quanta di questa volete mettere a disposizione di Squid.
+*Cache_mem* imposta quanta memoria RAM venga utilizzata per la cache di Squid.
+Questo dipendera' dalla RAM disponibile sul sistema, e da quanta di questa volete mettere a disposizione di Squid (altri servizi iimportanti girano sulla stessa macchina?).
Questo paramentro influisce sulle prestazioni e sul degrado dei supporti di storaggio (sopratutto se magnetici).
+Se si stesse pensando di usare dell'hardware *embedded* a basse prestazioni / consumo per realizzare un server gateway / NAT / Squid si tenga presente che Squid e' relativamente esoso di risorse: avra' bisogno di una macchina con ``~25MB`` (MegaByte) di RAM e *~150MHZ di CPU ARM* per servire decorosamente una decina di client http su una rete ethernet 10/100. In questo caso non fate scendere ``cache_mem`` sotto i ``2/4 MB`` pena un accesso continuo al supporto di storaggio.
+
+Se invece si disponesse di una macchina dedicata a Squid con gigabytes di RAM non si esiti a dedicarne buona parte a *cache_mem*.
+
TAG: cache_mem (1566)::
# 'cache_mem' specifies the ideal amount of memory to be used
TAG: minimum_object_size
~~~~~~~~~~~~~~~~~~~~~~~~~~
-Questo paramentro imposta la dimensione minima degli oggetti salvati nella cache. Settato a ``0`` o a valori molto piccoli puo' influire negativamente sulla deframmentazione del filesytem e consumare un numero elevato di *inode*.
+Questo parametro imposta la dimensione minima degli oggetti salvati nella cache. Settato a ``0`` o a valori molto piccoli puo' influire negativamente sulla deframmentazione del filesytem e consumare un numero elevato di *inode* (cosa non piu' importante con ext4 o altri filesytem).
TAG: minimum_object_size::
Negoziazione degli accesi al servizio
---------------------------------------
-Squid e' uno di quei servizi soggetto a problemi di tipo *open relay*, si deve quindi limitare la rete che puo' accedere al servizio.
+Squid e' uno di quei servizi soggetto a problemi di tipo *open relay* , si deve quindi limitare la rete che puo' accedere al servizio.
+
+Open Relay:
+ Un servizio a cui possono accedere tutti indiscriminatamente.
+ La cosa puo' andare bene per servizi come i server web, che aspirano per loro natura
+ al maggior numero possibile di utenti, ma non a servizi come i proxy http oppure
+ ai server di posta elettronica (che permetterebbero l'invio di SPAM).
+
+Generalmente non volete che il vostro proxy http venga usato da persone sconosciute le quali sostanzialmente *navigherebbero sotto l'identita' del vostro proxy* (probabilmente per visionare materiali che non vorrebbero fossero ricondotti direttamente a loro, per motivi che sta a voi prendere in considerazione) consumando traffico e banda della vostra connessione a internet. Tenere Squid in modalita' *Open relay* e' al giorno d'oggi un buon modo per essere inseriti in una *black list*.
+
+Per poter limitare gli accessi a Squid dal punto di vista dell'applicazione (quarto livello TCP/IP) si identifichera' inizialmente l'entita' *rete locale* (es: ``localnet``) con una ACL di tipo *src* (indirizi IP sorgenti) indicando la *classe / range di ip* della nostra rete.
+
+ Dopodiche l'accesso (``http_access``) si concedera' (*allow*) a questa entita' (es: ``localnet``) negando chiunque altro.
+
+Per maggiori dettagli sulla sintassi utilizzabile per esprimere i range di ip:
+http://www.visolve.com/squid/squid24s1/access_controls.php
+
ACL e http access
~~~~~~~~~~~~~~~~~~~~~
#acl localnet src 192.168.0.0/16 # RFC1918 possible internal network
#
acl localnet src 10.10.208.0/24
+
# Riga 606
# TAG: http_access
# Allowing or Denying access based on defined access lists
Configurato squid e' fondamentale testarne il corretto funzionamento per assicurarsi di non aver creato un *open-relay*. Per fare dei test significativi serve utilizzare degli host remoti: ci si connetta via ssh a questi per poi utilizzare ``wget`` da riga di comando.
-wgetrc
-~~~~~~~~~
+Client: ~/.wgetrc
+~~~~~~~~~~~~~~~~~~~
Nel file ``.wgetrc`` (si noti il punto iniziale: e' un file nascosto) si puo' impostare il proxy per wget. Si utililizzi l'indirizzo ip del server che si vuole testare, e si seguano i log ``/var/log/squid3/access.log`` sul server.
wget http://www.google.it
+Server: access.log
+~~~~~~~~~~~~~~~~~~~~~
+
Si puo' controllare il corretto funzionamento del server seguendo i log di accesso a Squid::
# tail -f /var/log/squid3/access.log
+In oltre e' possibile configurare diversi *analizzatori di log* come ``Webalizer`` per studiare i log di Squid.
+
Apache
========
Configurazione di Apache
----------------------------
-I file di configurazione di apache si trovano nella cartella: ``/etc/apache2`` e sono strutturati come descritto nel file ``/usr/share/doc/apache2/README.Debian.gz`` . Sostanzialmente lo schema e' il seguente:
+I file di configurazione di apache si trovano nella cartella: ``/etc/apache2`` e sono strutturati come descritto nel file
+``/usr/share/doc/apache2/README.Debian.gz`` . Sostanzialmente lo schema e' il seguente:
apache2.conf
File di configurazione principale del servizio.
...
+dig @nome_dns
+ Permette di fare una query ad un server dns particolare.
+ Es: ``dig @151.99.25.1 www.google.it``
+
+dig MX www.google.it
+ Chiede un campo in particolare, in questo caso il campo MX
+
+dig ANY www.google.it
+ Chiede tutti i campi, non solo i campi *a*
+
+dig -x 74.125.43.104
+ Effettua una richiesta inversa: dall'ip al PTR associato.
+
+resolv.conf
+-----------------
+
+Il file ``/etc/resolv.conf`` contiene le impostazioni sul dns usato dal sistema, in genere anche altre applicazioni che devono effettuare query DNS leggono resolv.conf per conoscere l'ubicazione del DNS.
+
+/etc/resolv.conf:
+
+ - ``nameserver``: indica il nameserver da utilizzare, indicato con l'indirizzo ip.
+
+ - ``domain``: indica il nome di dominio della rete attuale, vedi voce sucessiva.
+
+ - ``search``: nome di dominio usato dalla rete sul quale cercare gli hosts. Ad esempio se impostato su ``piffa.net`` pingando l'host ``bender`` viene automaticamente fatto un tentativo di ricerca per ``bender.piffa.net``.
+
+
+Si veda anche la pagina man di resolv.conf.
+
+Attenzione: se si usa un client DHCP o simile questo file potra' essere riscritto automaticamente in base a quanto ottenuto dal DHCP. Si veda la documentazione del pacchtto ``resolvconf``.
+
+
+/etc/hosts
+---------------
+
+Tabella statica per l'associazione tra IP e nomi di dominio::
+
+# cat /etc/hosts
+
+ 127.0.0.1 localhost.localdomain localhost
+ 10.10.208.162 daniela daniela.piffa.net
+ 10.10.208.254 mirror mirror.piffa.net
+ 91.191.138.15 thepiratebay.org
+ 192.168.0.11 chrome chrome.mydomain.com
+
+Il contenuto e' un associazione tra un *IP* e stringhe di testo (anche piu' di una es: ``mirror`` e ``mirror.piffa.net``), un record per riga.
+
+Il problema e' la gestione di questo file: quando gli host cambiano IP si devono aggiornare i records, e c'e' poi il problema di distribuire questo file tra i vari hosts della propia LAN. Un metodo semplice per distribuire questo file e' utilizzare ``Dnsmasq``: questo infatti legge e onora il file ``hosts`` locale e lo *distribuisce* ai clients.
+
+Modificare (riconducendola a un ip interno, cosi' annullandola) la risoluzione di un nome di dominio e' un modo drastico e funzionale per *annullarlo* rendendolo indisponibile alla propia rete locale, ad esempio aggiungere al file ``/etc/hosts``::
+
+ 127.0.0.1 www.facebook.com
+
+Impedira' agli utenti della LAN di raggiungere *facebook*, ora reindirizzato a i``localhost``.
+
+
+Hostname
+------------
+
+Ogni computer ha un *propio nome* visualizzabile (e modificabile) con il comando ``hostname``.
+
+Per modificare in modo permanente il nome del computer si modifichi il contenuto del file ``/etc/hostname``.
+
+Tipicamente si vuole mantenere una correlazione tra il nome dell'host, o meglio la stringa con cui il server si qualifica all'esterno, e il *PTR* dell'ip. Nel caso di *servizi virtuali* ci sara' un *nome server* principale associato al *PTR* condiviso.
+Non e' automatico che un servizio, ad esempio un server di posta, si qualifichi leggendo il contenuto di questo file e magari aggiungendo come suffisso il dominio di cui fa parte l'host: a volte questo parametro puo' essere specificato nel file di configurazione del servizio::
+
+ * Squid: ``visible_hostname``
+ * Postfix: ``myhostname``
+
DNSmasq
========
Tutto cio' rende Dnsmasq una soluzione valida in particolare quando si deve intervenire in una rete pre-esistente in cui il server principale e' in crisi: si potra' utilizzare Dnsmasq anche su una macchina piu' debole e *mascherare* i servizi al momento non disponibili.
Molto utile per scopi didattici, sopratutto per testare server SMTP impostando al volo i campi MX per nomi di dominio fittizi.
+
+Configurazione
+-----------------
+
+Vediamo alcune direttive di basi del file di configurazione ``/etc/dnsmasq.conf`` utili per la configurazione sia del DNS cache che per il DHCP server:
+
+
+domain-needed
+ Non inoltrare query ai server DNS esterni per nomi semplici (es andrea, portatile, pippo) che verranno risolti solo in locale o causeranno direttamente una risposta *not found* .
+
+
+bogus-priv
+ Simile alla voce precedente ma per i reverse look-up.
+
+
+domain
+ Nome di dominio della rete da passare ai client.
+
+
+expand_hosts
+ Aggiunge il ``nome host`` ( ``/etc/hostname``) dei client al nome di dominio per qualificarli in rete, senza bisogno di dover comporre a un elenco statico di record nel file ``/etc/hosts`` o nello stesso file di configurazione di dnsmasq. Es: se un vostro client si chiama ``chrome`` e il vostro dominio ``piffa.net`` dnsmasq rendera' disponibile il campo *A* per il dominio ``chrome.piffa.net`` diretto all'ip che verra' assegnato al client.
+
+
+DHCP
+-----------
+
+Per attivare il demone DHCP di dnsmaq basta aggiungere al file di configurazione il *range* degli ip che si vuole assegnare ai client con il *lease time* (tempo di rilascio: quanto a lungo saranno validi gli ip assegnati) espresso in ore.
+
+Si faccia *attenzione*: in una rete puo' esseere presente **un solo server DHCP**, o per meglio dire qualunque server DHCP ascolta sul broadcast ``255.255.255.255`` e potrebbe rispondere a un pacchetto di richesta DHCP. Quindi non fate partire inavvertitamente un server DHCP in una rete gia' servita e **non vi azzardate ad andare in giro con un portatile con un server DHCP attivo** nelle reti altrui. Questo vale anche per i laboratori di informatica dei corsi di reti: non fate partire il vostro server DHCP se siete collegati alla rete interna!
+
+/etc/dnsmasq.conf (riga 118)::
+
+ dhcp-range=192.168.0.20,192.168.0.50,24h
+
+DNS cache
+-----------
+
+Aggiungere al file ``/etc/resolv.conif`` il nameserver localhost in cima alla lista dei *nameserver* disponibili. Dnsmasq usera' la propia cache e in caso non abbia disponibile il *record DNS* richiesto fara' partire una query al primo DNS::
+
+ nameserver 127.0.0.1
+
+
+Questo pero' potrebbe essere problematico se un altro servizio, ad esempio il DHCP client, riscrive il contenuto del file ``/etc/resolv.conf``. Per superare il problema si aggiunga (riga 20) al file di configurazione ``/etc/dhcp3/dhclient.conf`` ::
+
+ prepend domain-name-servers 127.0.0.1;
+
+Oppure potrebbe essere il nostro *PPP client* (per la connessione ADSL) a intervenire sul file ``//etc/resolv.conf``, si modifichi quindi ``/etc/ppp/peers/dsl-provider`` commentando ``usepeerdns``. Se la vostra connessione ad internet e' ADSL raramente dovreste aver bisogno di cambiare i DNS una volta impostati (a meno che non usiate un portatile!).
+
+
+DHCPd
+---------
+
+Dnsmasq puo' lavorare anche come DHCP server per la vostra LAN.
+
Samba
======
mount -t smbfs //localhost/sambo_share /mnt/sambo_mount/ --verbose -o user=sambo
+Server di posta: Postfix
+============================
+
+Il server di posta che prenderemo in considerazione e' Postfix, a seguire un estratto di un file do configurazione *semplie* con l'abilizazione delle *Maildir* nelle ``/home`` degli utenti per la consegna della posta:
+
+``/etc/postfix/main.cf``::
+
+ # ...segue dalla riga ~30
+ myhostname = 162.piffa.net
+ alias_maps = hash:/etc/aliases
+ alias_database = hash:/etc/aliases
+ myorigin = 162.piffa.net
+ mydestination = 162.piffa.net, localhost
+ # Se non avete un ip pubblico e statico, con un adeguato record PTR
+ # dovrete usare un realy host per l'invio della posta
+ relayhost = smtp.piffa.net
+ mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
+
+ # Per effettuare lo storaggio della posta nelle home directory degli utenti
+ # in una Maildir invece che la Mailbox in /var/mail/utente
+ # si disabiliti procmail
+ #mailbox_command = procmail -a "$EXTENSION"
+
+ # Storaggio della posta nella _cartella_ Maildir/ (si noti lo slash)
+ # nella home dell'utente:
+ home_mailbox = Maildir/
+ mailbox_size_limit = 0
+ recipient_delimiter = +
+ inet_interfaces = all
+
+
+Imap e pop
+------------------
+
+Postfix e' un server SMTP, di conseguenza se volete che i vostri utenti possano *scaricare* in locale la posta generalemtne volete mettere a loro disposizione un server *POP3* o ancora meglio *IMAP*. Oppure entrambi.
+
+Pacchetti da installare
+ courier-imap courier-pop
+
+i noti che IMAP necessita delle Maildir, non funziona con le Mailbox in ``/var/mail/`` .
+
+
+Web client
+~~~~~~~~~~~~~~~
+
+Per mettere a disposizione degli utenti un client web per gestire la propia posta si installi il pacchetto: ``squirrelmail`` . Ci sono tanti altri client web disponibili: questo e' particolarmente semplice. Naturalemte dovrete aver installato: ``php5 apache2`` .
+
+L'interfaccia dovrebbe essere disponibile all'url: ``http://localhost/squirrelmail`` . Se cosi' non fosse assicuratevi che Apache abbia incluso il file di configurazione di squirrelmail::
+
+ cd /etc/apache2/conf.d/
+ ln -s /etc/squirrelmail/apache.conf ./
+
+
+
Firewall
==========
+Salvataggio regole
+----------------------
+
+Il comando ``iptables`` serve per interagire con il framework ``Netfilter`` ch gestisce il firewall di Linux al livello del kernel. Questo comporta, in modo analogo a quando avvene col comando ``ifconfig``, che i cambiameti impostati siano in *tempo reale, RAM*, non persistenti nel sistema: al boot sucessivo del sistema tutto tornera' alle impostazioni di base (in questo caso *nulle*, con policy di default settate su ``ACCEPT`` per tutto).
+
+Le varie invocazioni di iptables potrebbero essere richiamate da degli scripts dedicati, ma fortunatamente e' stata predisposta una apposita utility per gestire questi scripts in modo da avere a disposizione un *formato standard* per il salvataggio e il ripristino delle regole del firewall.
+
+Altro problema: decidere quando attivare / disattivare queste regole. Utilizzare i *runlevels* non e' una soluzione adeguata: le regole del firewall sono legate all'attivita' delle schede di rete (e un host con diverse schede di rete puo' attivarle a secondo delle esigenze di routing, partenza di servizi es file_sharing per un back-up...): il sistema operativo Debian permette di legare l'esecuzione di comandi alla attivazione di una device di rete (``up``), dopo la sua attivazione (``post-up``, utile per devices che richiedono un certo tempo per inizializzarsi: come un tunnel o una connessione punto a punto), prima della sua attivazione (``pre-up``). Allo stesso modo sono disponibili eventi analoghi per accompagnare la disattivazione dei device di rete: si veda la pagina man di ``interfaces``.
+
+Nel nostro caso avremo per una possibile scheda ``eth0``:
+
+``/etc/network/interfaces`` ::
+
+ iface eth1 inet static
+ up /sbin/iptables-restore /root/firewall/basic_fw
+ # Seguno i soliti parametri della scheda di rete
+ address 10.10.208.21
+
+
+Iptables-save
+~~~~~~~~~~~~~~~
+
+Per salvare le regole di iptables attualmente presenti nel kernel si usi il comando::
+
+ # iptables-save >> /root/firewall/basic_fw
+
+Il contenuto del file dovrebbe essere *comprensibile*: sostanzialmente sono regole di iptables, senza il comando iptables ripetuto, suddivisi per le varie tabelle. Potete comunque correggere eventuali parametri con un edito di testo.
+
+
+Se non avete un'idea migliore potreste voler tenere gli script dei firewall in una cartella ``~/firewall`` nella home directory dell'utente ``root``.
+
+Iptables-restore
+~~~~~~~~~~~~~~~~~~~~
+
+Per ripristinare un set di regole prcedentemente salvate con ``iptables-save`` si utilizzi ``iptables-restore``. Se questo deve essere fatto in modalita' *non interattiva*, ad esempio deve essere eseguito dal demone che si occupa di inizializzare le schede di rete, oppure un *cron* o altro, e' buona norma richiamare i percorsi completi sia dei comandi che dei file::
+
+ /sbin/iptables-restore /root/firewall/basic_fw
+
NOTE
========
projects / doc / .git / blobdiff