+ forwarders {
+ 10.10.208.254;
+ };
+
+Nel caso si voglia usare Bind solo come server DNS cache per la propria LAN senza ospitare delle zone DNS pubbliche sara' il caso di limitare gli accessi al server alla sola LAN:
+
+/etc/bind/named.conf.options (riga 19)::
+
+ // Se il proprio server ha IP 10.10.208.254
+ // sulla rete LAN privata:
+ listen-on { 10.10.208.254; }
+
+E non si lasci il server in ascolto su uno degli eventuali indirizzi IP pubblici.
+
+Se questo non fosse possibile si puo' sempre lavorare su una *acl*:
+
+/etc/bind/named.conf ::
+
+ acl "localnet" {
+ 10.10.208.0/24 ; 127.0.0.0/8 ;
+ } ;
+
+Per poi aggiungere all'interno della stanza options la direttiva che abilita' l'entita' ``localnet``:
+
+/etc/bind/named.conf.options ::
+
+ allow-query {"localnet" ;} ;
+
+
+Ospitare una zona
+---------------------
+
+Se avete acquistato un nome di dominio e vi serve un software DNS per gestirlo Bind e' la scelta piu' diffusa. Ora vedremo come configurare una *zona* (come piffa.net) in modo che Bind sia autoritativoper questa, rispondendo alle query DNS di tutta la rete internet.
+
+
+named.conf.local
+~~~~~~~~~~~~~~~~
+
+Prima di tutti impostiamo il server bind per gestire la zona, per non fare confusione e' opportuno inserire le propie zone DNS nel file ``named.conf.local`` e non in ``named.conf``.
+
+named.conf.local::
+
+ /
+ // Do any local configuration here
+ //
+
+ // Consider adding the 1918 zones here, if they are not used in your
+ // organization
+ //include "/etc/bind/zones.rfc1918";
+
+ zone "piffa.net" {
+ type master;
+ file "/etc/bind/pz/piffa.net";
+ }
+
+type master
+ Il nostro server DNS sara' il principale, al quale poi potremo affiancare dei DNS secondari nel caso questo non sia disponibile.
+
+file "/etc/bind/pz/piffa.net"
+ Dove verranno inserite le informazioni vere e propie di questa zona.
+
+Configurazione della zona
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Ora dovremo preparare il file contenente i record DNS della zona *piffa.net*, come abbiamo indicato prima questi saranno contenuti nel file ``/etc/bind/pz/piffa.net`` . Tenere le zone dentro una sottocartella e' buona abitudine, usare ``pz`` per queste e' una vecchia abitudine.
+
+piffa.net::
+
+ ; Zona per il dominio di secondo livello piffa.net
+
+ $TTL 3D ; 3 days
+ @ IN SOA ns1.piffa.net. hostmaster.piffa.net. (
+ 200905245 ; serial
+ 8H ; refresh (8 hours)
+ 2H ; retry (2 hours)
+ 4W ; expire (4 weeks)
+ 1D ; minimum (1 day)
+ )
+ ;
+ NS ns1
+ NS ns2
+ A 94.23.63.105
+ MX 10 smtp
+ TXT "Piffanet main site"
+ ;
+ ns1 A 94.23.63.105
+ ns2 A 65.98.21.97
+ zoo A 94.23.63.105
+ smtp A 94.23.63.105
+ test.piffa.net. A 94.23.63.105
+ *.piffa.net. A 94.23.63.105 ; *catch all domain
+ www CNAME zoo
+ ftp CNAME zoo
+
+
+
+All'interno di questo file si possono inserire dei commenti con il carattere ``;`` (punto-e-virgola), si faccia attenzione alla rigida sintassi: apertura e chiusura delle parentesi tonde nella parte ``IN SOA``, uso del ``punto`` finale per precisare un nome di dominio specifico (*FQDN*: Fully-qualified Domain Name) come ``test.piffa.net.`` a differenza degli altri domini di terzo livello come ``pop,imap,smtp`` .
+
+La zona inizia con una direttiva ``$TTL 3D`` (RFC 2308) che indica la durata (in questo caso tre giorni) che ogni record dovrebbe avrebbe nella cache degli altri serber DNS. Questo valore dovrebbe essere superiore a un giorno, se non modificate spesso i valori dei vostri record DNS e' consigliabile settarlo a 2/3 settimane in modo da limitare la frequenza delle query al propio server. Questo parametro puo' essere modificato per singoli record::
+
+ $TTL 3D ; 3 giorni: default se non specificato altrimenti
+ rapido 5h IN A 94.23.63.105 ; usa un TTL di 5 ore
+ lento 3w IN A 94.23.63.105 ; usa un TTL di 3 settimane
+ normale IN A 94.23.63.105 ; usa il TTL di default: 3 giorni
+
+
+Segue poi il nome della zona, indicato con la ``@`` per richiamare la zona originale precisata nel file ``named.conf.options`` . Segue il campo ``SOA``.
+
+SOA: Start of Authority Record
+`````````````````````````````````
+
+Il record SOA puo' comparire solo una volta in una zona, contiene informazioni relative all'autorita' del server DNS.
+
+ns1.piffa.net. name-server
+ primary master DNS di questo dominio.
+
+hostmaster.piffa.net. email-addr
+ email-addr: indirizzo email della persona responsabile di questa zona, il primo punto viene tradotto in una *chiocciola* ``@`` dato che questo carattere ha un'altro utilizzo all'interno di questo file. Il referente della zona **deve** essere un email valido e controllato, come consuetudine si usa ``hostmaster@dominio.tilde`` .
+
+200905245 serial number
+ Questo valore serve per indicare quando e' stato modificato questo file di configurazione, secondo il formato ``yyyymmddss``: ``yyyy`` = anno, ''mm'' = mese, ''dd'' = giorno, ''ss'' = seriale. Il seriale che deve essere sempre specificato anche per una cifra, va incrementato di una unita' nel caso vengano fatte piu' modifiche *nello stesso giorno*.
+
+8H refresh
+ Indica ai DNS secondari quanto tempo attendere per cercare di aggiornare i loro dati con il DNS master.
+
+2H retry
+ Intervallo di tempo per il DNS slave (secondario) da aspettare prima di cercare di ricontattare il *master* in caso di problemi col *refresh*.
+
+4W expire
+ Indica quando i dati dei dns secondarinon sono piu' autoritativi in caso di impossibilita' degli *slaves* di ri-aggiornarsi con il *master*. Consigliato un valore di 2/4 settimane.
+
+1D minimum
+ Questo valore indicava il TTL fino alla versione 8 di Bind, da Bind 9 e secondo la RFC2308 indica la durata del *negative caching*, quanto i resolvers (ad esempio un server dns cache) puo' mantenere un record *negativo* (che non indica la corrispondenza tra un nome di dominio e un ip, ma la non esistenza del record). Nell'uso per il negative caching viene fissato un valore massimo di 3 ore dalla RFC 2308.
+
+
+Altri campi:
+```````````````
+
+All'interno della zona possono essere utilizati vari tipi di records (RR):
+
+TXT
+ Informazioni testuali associate ad un record
+
+NS
+ Name Server della zona. Non deve essere un cname.
+
+A
+ Indirizzo ipv4 da associare al record
+
+AAA
+ Indirizzo ipv6 da associare al record
+
+CNAME
+ Canonical Name: un alias per un host: ad esempio per il dominio piffa.net possiamo settare degli alias come ``www.piffa.net, http.piffa.net, virtual.piffa.net, ftp.piffa.net, imap.piffa.net``. Comodo quando diversi alias sono sempre riferiti allo stesso ip.
+
+MX
+ Mail Exchanger: server di posta che si occupera' della posta elettronica per questo dominio.E' opportuno avere almeno un server di posta di back-up, per indicare la priorita' di un MX rispettoad un altro si usa un valore di 2 cifre: il valore piu' basso indica priorita' piu' bassa. Es: ``MX 10 smtp.piffa.net.`` per il server SMTP principale e ``MX 40 smtp2.piffa.net`` per il secondario. Non deve essere un cname.
+
+PTR
+ Reverse look-up, usato per la mappatura inversa di un indirizzo ip a una stringa identificativa dell'host. Si noti che per poter modificare questi record si deve avere *in gestione* la *zona IP*, se cosi' non fosse si dovra' chiedere al propio provider la modifica di questo record per il propio ip. Links: http://www.zytrax.com/books/dns/ch3/
+
+DNS slave
+-------------
+
+Data l'importanza del servizio DNS e' necessario avere ridondanza per i server DNS che ospitano i vostri dati: in caso di indisponibilita' del server *master* (nel caso fosse il solo a tenere i dati questo comporterebbe la *scomparsa* di tutti i servizi / host da esso seviti!) il client potrebbe contattare uno degli *slave*.
+
+Gli slave recuperano i dati dei recordos RR direttamente dal master e non sara' quindi necessario dover mantenere manualmente il file di configurazione della zona sugli slaves, ogni volta che aggiorneremo il master questi dati si propaghera' agli slaves automaticamente.
+
+Per attivare uno *slave* per la nostra zona di esempio ``piffa.net`` si inserisca nel file ``named.conf.local`` dello slave server::
+
+ zone "piffa.net" {
+ type slave;
+ file "/etc/bind/pz/piffa.net";
+ masters { 192.168.0.1; };
+ };
+
+Facendo ripartire Bind il file ``/etc/bind/pz/piffa.net`` viene creato automaticamente.
+
+Segue un estratto di ``/var/log/syslog`` al ``restart`` di ``bind9`` sullo slave::
+
+ ... slave named[2256]: zone piffa.net/IN: loaded serial 200905245
+ ... slave named[2256]: running
+ ... slave named[2256]: zone piffa.net/IN: sending notifies (serial 200905245)
+ ... slave named[2256]: client 192.168.0.1#1464: received notify for zone 'piffa.net'
+ ... slave named[2256]: zone piffa.net/IN: notify from 192.168.0.1#1464: zone is up to date
+
+.. warning::
+ Bind9 (versione 9.3 presente in Debian Lenny) richiede una esplicita autorizzazione alla notifica per lo stesso server slave, che in fase di avvio interroghera' (inviando un notify) se' stesso per valutare se i dati relativi alla zona di cui e' slave sono aggiornati. Si aggiunga quindi al file ``/etc/bind/named.conf.options`` dello slave: ``allow-notify { 192.168.0.1; };`` all'interno della stanza ``options``, in cui l'inidirizzo IP inserito e' quello dello stesso slave server.
+
+Aggiornamento dinamico: nsupdate
+----------------------------------
+
+Dalla versione 8 di Bind e' dsponibile l'utility ``nsupdate`` (disponibile nel pacchetto ``dnsutils``) per aggiornare automaticamente i record di una zona secondo il paradigma client / server ( RFC2136 ) . Posto che abbiate a disposizione un server DNS Bind on-line su un indirizzo IP fisso e un zona da gestire (che potrebbe essere anche solo la delega di un dominio di terzo livello come *casa.miodominio.net*) sara' possibile aggiornare automaticamente i record che tirano a degli indirizzi IP *pubblici ma dnamici*, come quelli spesso messi a disposizione dei provider per le connessioni ad internet residenziali, in modo da poter rendere sempre raggiungibile la vostra workstation a casa anche dopo un aggiornamento dell'ip dinamico associato alla connessione.
+
+L'auenticazione del client nsupdate che avra' la possibilita' di aggiornare il server DNS master avviene tramite *Transaction signatures* (TSIG, RFC2845) usando un algoritmo di criptazione dati asimmetrico *HMAC-MD5* : generata una coppia di chiavi sul client / nsupdate con l'utility si dovra' trasferire la chiave pubblica sul server *master*, che verra' configurato per onorare gli aggiornamenti (eliminazione e inserimento di record RR) autenticati dalla chiave privata.
+
+Configurazione client (nsupdate)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Sul client, sul quale non deve essere necessariamente installato un server DNS Bind ma la sola utility ``nsupdate``, generiamo la coppia di chiavi con l'utility ``dnssec-keygen`` installabile tramite il pacchetto ``bind9utils``::
+
+ dnssec-keygen -a HMAC-MD5 -b 512 -n USER home.piffa.net.
+
+Otterremo le due chiavi ``Khome.piffa.net.+157+04331.key Khome.piffa.net.+157+04331.private``, la chiave pubblica dovra' essere resa noto al server master che ricevera' l'update dei records.
+
+Configurazione server: riconoscimento chiave
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Per rendere nota al server la chiave pubblica generata sul client si aggiunga quindi al file ``/etc/bind/named.conf`` sul server::
+ key home.piffa.net. {
+ algorithm HMAC-MD5;
+ secret "txfAkNTScANEu2V73mCeiDpXNc3pmf+7ONOoKnTKQKIZMzierSmeHjK5 Z8ntnByt/PJwv26jCIsVh8n+xzVsRw==";
+ };
+
+.. note::
+ La parte ``secret``, che potete leggere direttamente nel file \*.key della chiave genearta, e' scritto *tutto sulla stessa riga* senza ritorni a capo.
+
+
+Server: gestione dell'intera zona
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Sul server modifichiamo il file di configurazione ``named.conf.local`` della zona della quale vogliamo concedere l'aggiornamento al client::
+
+ zone "piffa.net" {
+ type master;
+ file "/etc/bind/pz/piffa.net" ;
+ allow-update {
+ key home.piffa.net;
+ };
+ };
+
+Sara' necessario assicurarsi che il demone di Bind sia in grado di modificare il file ``/etc/bind/pz/piffa.net``: dato che questo file ora sara' gestito da lui si proceda a cedergli la propieta' del file::
+ chown bind /etc/bind/pz/piffa.net
+
+Altro problema che si potrebbe porre: gli orologi di sistema dei due host devono essere sincronizzati per poter valutare l'opportunita' di un aggiornamento: si consigla di installare su entrambi l'utility ``ntpdate`` e di eseguirla facendo riferimento ai time server di Debian::
+
+ apt-get install ntpdate
+ ntpdate-debian
+
+
+Ora possiamo provare dal client a effettuare l'iserimento di un record per testarne il funzionamento::
+
+ # nsupdate -k Khome.piffa.net.+157+04331.private -v
+ > server ns1.piffa.net
+ > update add home.piffa.net. 86400 A 192.168.0.2
+ > show
+ Outgoing update query:
+ ;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id: 0
+ ;; flags: ; ZONE: 0, PREREQ: 0, UPDATE: 0, ADDITIONAL: 0
+ ;; UPDATE SECTION:
+ home.piffa.net. 86400 IN A 192.168.0.1
+
+
+ > send
+
+Per comprendere meglio l'uso dell'utility ``nsupdate`` si consiglia la lettura della relativa pagina man. Nella prima riga viene invocato il comando ``nsupdate`` impostando col flag ``-k`` la chiave privata generata precedentemente, con ``server`` si imposta quale server NS autoritario della zona (che abbiamo precedentemente configurato per ricevere gli aggiornamenti) vogliamo contattare. Alla riga sucessiva ``update`` viene aggiunto un record ``A`` per la il dominio ``home.piffa.net`` indirizzato all'IP ``192.168.0.2``, poi ``show`` mostra quanto ci si prepara a comunicare al server con il finale ``send`` .
+
+Si noti che in questo modo *l'intera zona* piffa.net e suscettibile di essere modificata dal client, che potra' eliminare e inserire qualunque record. E' possibile gestire in modo piu' granulare la zona, ad esempio concedendo al client i privilegi per gestire solo una parte della zona o i tipo di record da gestire.
+
+Automatizzare l'aggiornamento dinamico
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Nsupdate risulta comodo per tenere aggiornati i record DNS degli host connessi ad internet con indirizzi IP dinamici (pubblici) assegnati dal provider. Il client deve essere in grado di contattare autonomamente il server DNS per comunicare un cambiamento del suo ip. Vediamo innanzi tutto un primo script per nsupdate::
+
+ #!/bin/bash
+ # Diamo al demone ppp un po' di tempo per negoziare la connessione
+ # prima di leggere l'IP ottenuto
+ sleep 15
+ IPADDR=$(/sbin/ifconfig ppp0 | awk '/inet/ { print $2 } ' | sed -e s/addr://)
+
+ nsupdate -k /root/dns/Khome.piffa.net.+157+04331.private <<-EOF
+ server 192.168.0.254
+ zone home.piffa.net.
+ update delete home.piffa.net. A
+ update delete home.piffa.net. MX
+ update add home.piffa.net. 432000 A $IPADDR
+ update add home.piffa.net. 432000 MX 10 home.piffa.net.
+ show
+ send
+ EOF
+
+
+Questo script legge il valore del device di rete ``ppp0`` creato dal `pppoe` di una connessione ADSL per ottenere l'indirizzo IP ottenuto dal provider (prima di farlo aspetta 15 secondi per dare il tempo al ``pppoe`` di negoziare la connessione).Vengono poi eliminati gli esistenti valori ``A`` e ``MX`` per ``home.piffa.net`` (si noti il punto finale dopo *net*) e inseriti quelli attuali.
+
+Resta da decidere quando richiamare questo script: l'evento che causa l'assegnazione del nuovo IP in questo caso e una nuova connessione ``pppoe``, quindi sarebbe consigliabile inserire lo script nelle routine comprese in ``/etc/ppp/ip-up.d`` (si veda la documentazione di ppp), nel caso questo non desse i risultati sperati (per problemi di connessione) come via estrema si consideri di mettere lo script nella routine del demone ``cron`` in modo che venga eseguito periodicamente (ad esempio ogni giorno).
+
+
+Link suggeriti:
+----------------
+
+* DNS for Rocket Scientists http://www.zytrax.com/books/dns/
+* DNS HOWTO http://www.langfeldt.net/DNS-HOWTO/BIND-9/
+
+Samba
+======
+
+Samba e' un progetto libero che fornisce servizi di condivisione di file e stampanti a client SMB/CIFS.
+
+Samba e' liberamente disponibile, al contrario di altre implementazioni SMB/CIFS, e permette di ottenere interoperabilita' tra Linux, Unix, Mac OS X e Windows.
+
+Samba e' un software che puo' girare su piattaforme che non siano Microsoft Windows, per esempio, UNIX, Linux, IBM System 390, OpenVMS e altri sistemi operativi. Samba utilizza il protocollo TCP/IP utilizzando i servizi offerti sul server ospite. Quando correttamente configurato, permette di interagire con client o server Microsoft Windows come se fosse un file e print server Microsoft agendo da Primary Domain Controller (PDC) o come Backup Domain Controller, puo' inoltre prendere parte ad un dominio Active Directory.
+
+Pacchetti
+--------------
+
+Pacchetti da installare per utilizzare Samba in modalita' client [#]_ ::
+
+ samba-client
+
+Pacchetti da installare per utilizzare Samba in modalita' server::
+
+ samba smbfs smbclient
+
+.. [#] Anche se nato per i sistemi Windows, Samba puo' essere usato anche per montare cartelle sotto GNU/Linux come alternativa a NFS. Per la condivisione di stampanti sarebbe invece opportuno intervenire direttamente su ``CUPS``.
+
+Durante la prima installazione viene chiesto il nome del gruppo di appartenenza, il default per Windows e' ``WORKGROUP``. In aula usiamo invece ``208`` .
+
+Per riconfigurare Samba si usi il comando::
+
+ dpkg-reconfigure samba-common
+
+Passwords e autenticazione
+---------------------------
+
+Per poter configurare Samba in modo che usi un sistema di negoziazione degli accessi alle cartelle condivise basato su accoppiate *nome utente / password* bisogna distinguere tra 3 livelli di password (e generalmente volete usare *sempre la stessa password* per ognuno di questi) e delle differenze tra le modalita' di *autenticazione* (e quindi anche di criptaggio delle passwords) usate da sistemi GNU/Linux e Windows:
+
+1 Sistema \*Unix ( GNU/Linux )
+ E' la password dell'*utente di sistema* che viene usata sul sistema operativo su cui gira il software Samba. E' importante tenere conto anche delle *user-id* e *group-id* degli utenti che dovranno fisicamente scrivere sui file system. Se un utente non puo' scrivere in una certa posizione del file system (ad esempio nella cartella ``/mnt/condivisione`` che sara' stata necessariamente creata inizialmente dall'utente ``root``) per mancanza dei privilegi di scrittura allora neanche Samba potra' farlo nel momento in mette a disposizione la risorsa all'utente. Se si montano file-system dedicati per le condivisioni controllare i permessi e proprieta' dei *punti di mount**.
+ Queste passwords sono salvate nel solito file /etc/shadow (richiamato da /etc/passwd).
+
+2 Password per l'applicativo Samba
+ Samba deve essere compatibile con Windows e quindi utilizzare un sistema di criptazione delle password diverso da /etc/shadow . Le password per Samba possono essere gestite ad esempio col comando ``smbpasswd`` e vengono generalmente salvate all'interno di ``/var/lib/samba/passdb.tdb`` .
+
+3 Password per Windows.
+ Gli utenti Windows effettuano il log-in alla partenza della sessione di Windows. Se si avra' l'accortezza di usare sempre la *stessa password* data precedentemente anche a Windows (o viceversa impostare la password per GNU/Linux / Samba uguale a quella di Windows) l'utente potra' accedere automaticamente alle condivisioni a lui disponibili.
+
+
+Creazione Utenti
+-------------------
+
+Creiamo per primo l'utente sotto GNU/Linux, facendo attenzione a *non dargli una shell di sistema*. Gli utenti Windows che accedono al server solo per le condivisioni non hanno bisogno di poter eseguire comandi sul server!
+
+Creazione di un utente denominato sambo::
+
+ adduser --shell /bin/false sambo
+
+Nel file ``/etc/passwd`` avremo qualcosa come::
+
+ sambo:x:1001:1001:Sambo utente Samba,,,:/home/sambo:/bin/false
+
+
+Aggiunta dell'utente al database delle password per Samba e generazione della sua password::
+
+ smbpasswd -a sambo
+
+Se successivamente si vorra' modificare la password di un utente gia' esistente si usi::
+
+ smbpasswd sambo
+
+
+La password sotto Windows verra' modificata sul sistema Windows.
+
+Creare la condivisione
+------------------------
+
+La condivisione altro non e' che una cartella sul server che viene resa disponibile ai client negoziando l'accesso in base a una autenticazione basata su *user-name / password*. E' per altro possibile permettere l'accesso a una risorsa a chiunque indiscriminatamente (a tutti i ``guest``) ma la cosa e' sconsigliabile dal punto di vista della sicurezza. Si decida se la cartella condivisa debba risiedere nella *home* di un utente (nel caso quest'ultimo ne sia l'unico fruitore) o in una cartella in /mnt/ (nel caso piu' utenti accedano a questa). Nel secondo caso si potranno gestire gli accessi sotto GNU/Linux tramite i gruppi.
+
+Creazione della risorsa sambo_share nella home dell'utente sambo::
+
+ # mkdir /home/sambo/sambo_share
+ # chown sambo:sambo /home/sambo/sambo_share/
+
+Sicurezza: permessi di esecuzione sul server
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Bisognerebbe notare sul server i permessi di esecuzione del file-system che ospita la cartella da condividere. Se i file che saranno contenuti nella condivisione saranno da usarsi sotto Windows non c'e' motivo che questi siano eseguibili sotto GNU/Linux.
+Si potrebbe avere quindi, ipotizzando una condivisione in ``/mnt/share`` che risieda su di un file system dedicato:
+
+``/etc/fstab``
+
+ /dev/hda10 /mnt/share ext3 rw, **nosuid,noexec** 0 3
+
+Si noti anche l'uso di *nosuid* per evitare la possibilita' di eseguire programmi con credenziali diverse.
+
+Configurazione dell'applicativo Samba vero e proprio.
+------------------------------------------------------
+
+Avendo preparato gli utenti (ancora una volta: non si dia una shell completa a un utente che serve solo per Samba o la posta elettronica) e la cartella sul file system si puo' procedere a configurare la condivisione su Samba.
+
+
+/etc/samba/smb.conf riga ~235 , Share Definitions (in vim si usi 235gg )::
+
+ [sambo_share]
+ # Percorso della cartella condivisa
+ path = /home/sambo/sambo_share
+ # Se gli utenti possono scrivere / modificare file
+ writable = yes
+ # Negoziazione degli accessi su base utenti / passwords
+ valid users = sambo
+
+ # #######################################
+ # Altri parametri opzionali di interesse
+ # Se posso vedere la condivisione da esplora risorse
+ # anche se non ho i privilegi per accedervi.
+ browseable = yes
+ # Commento indicativo della risorsa
+ comment = Condivisione per Sambo
+
+Dopo aver salvato il file si puo' fare un primo controllo tramite l'utility ``testparm`` , che controlla la sintassi del file di configurazione di Samba. Se questo non rileva problemi si puo' procedere a un ``# /etc/init.d/samba restart`` .
+
+
+Creazione di un gruppo
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Se si deve condividere una risorsa con un numero consistente di utenti e' consigliabile lavorare in termini termini di gruppi piuttosto che elencare la lista degli utenti in ``valid users``.
+
+Dopo aver creato il gruppo del quale volete facciano parte i vostri utenti (``addgroup nome_gruppo``), inserite i vostri utenti nel gruppo (``adduser nome_utente nome_gruppo``) e modificate la direttiva ``valid users`` in ``smb.conf`` per riferirsi ad un gruppo piuttosto che a degli utenti. Per riferirsi a un gruppo si usi il carattere ``@ chicciola`` col ``nome_del_gruppo``::
+
+ # Negoziazione degli accessi su base gruppo
+ valid users = @nome_gruppo
+
+
+Testare il Servizio
+--------------------
+
+Come testare il servizio
+
+es::
+
+ smbclient -U sambo -L localhost
+
+Questo comando permette di esplorare la risorsa qualificandosi come utente, in questo modo potete testare il corretto funzionamento dell'autenticazione. Si provi inizialmente a sbagliare la password deliberatamente, poi a inserirla correttamente: dovrebbero essere visibili le risorse disponibili al solo utente sambo: la suo /home e la cartella samba_share::
+
+ Sharename Type Comment
+ --------- ---- -------
+ sambo_share Disk Condivisione per Sambo
+ print$ Disk Printer Drivers
+ IPC$ IPC IPC Service (base server)
+ sambo Disk Home Directories
+
+In particolare l'ultima voce relativa alla home directory dell'utente dovrebbe essere visibile solo agli utenti autenticati.
+
+In alternativa e' possibile montare realmente la condivisone anche su GNU/Linux tramite un client per samba e testarne il corretto funzionamento::
+
+ 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 di configurazione *semplice* con l'abilitazione 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
+ # Se dovete inviare la posta per i client della vostra LAN privata:
+ # mynetworks = 127.0.0.0/8 192.168.0.0/24 [::ffff:127.0.0.0]/104 [::1]/128
+ # E si faccia BEN ATTENZIONE a non diventare un open realay smtp
+
+
+ # Per effettuare lo storaggio della posta nelle home directory degli utenti
+ # in una Maildir invece che nella Mailbox in /var/mail/nome_utente
+ # si disabiliti procmail
+ #mailbox_command = procmail -a "$EXTENSION"
+
+ # cartella_i abiliti lo storaggio della posta nella Maildir/ (si noti lo slash)
+ # all'interno della home dell'utente:
+ home_mailbox = Maildir/
+ mailbox_size_limit = 0
+ recipient_delimiter = +
+ inet_interfaces = all
+
+
+E' disponibile un file di configurazione di esempio ben piu' articolato e commentato::
+ /usr/share/postfix/main.cf.dist .
+
+Test del server smtp
+-----------------------
+
+Per testare il corretto funzionamento del server di posta si puo' procedere in vari modi.
+
+- Spedire una mail a una casella locale / remota e controllare i log (syslog)
+- Collegarsi via *telnet* al server di posta: http://www.netadmintools.com/art276.html
+- usare una utility come SWAKS
+
+Swaks
+~~~~~~~~~~~
+
+Per gli utenti meno esperti e' consigliabile utilizzare *SWAKS*: si installi l'omonimo pacchetto e si esegua un test con::
+ swaks --to utente@destinatario.tilde --from utente@propio.mail.tilde
+
+Ecco un esempio di una sessione corretta::
+
+ swaks --to andrea@piffa.net from andrea@mydomain.com
+ === Trying smtp.piffa.net:25...
+ === Connected to smtp.piffa.net.
+ <- 220 zoo.piffa.net ESMTP Postfix (Debian/GNU)
+ -> EHLO alice.mydomain.com
+ <- 250-zoo.piffa.net
+ <- 250-PIPELINING
+ <- 250-SIZE 10240000
+ <- 250-VRFY
+ <- 250-ETRN
+ <- 250-STARTTLS
+ <- 250-ENHANCEDSTATUSCODES
+ <- 250-8BITMIME
+ <- 250 DSN
+ -> MAIL FROM:<root@alice.mydomain.com>
+ <- 250 2.1.0 Ok
+ -> RCPT TO:<andrea@piffa.net>
+ <- 250 2.1.5 Ok
+ -> DATA
+ <- 354 End data with <CR><LF>.<CR><LF>
+ -> Date: Thu, 28 May 2009 13:11:19 +0200
+ -> To: andrea@piffa.net
+ -> From: root@alice.mydomain.com
+ -> Subject: test Thu, 28 May 2009 13:11:19 +0200
+ -> X-Mailer: swaks v20061116.0 jetmore.org/john/code/#swaks
+ ->
+ -> This is a test mailing
+ ->
+ -> .
+ <- 250 2.0.0 Ok: queued as 41FB261AFC
+ -> QUIT
+ <- 221 2.0.0 Bye
+ === Connection closed with remote host.
+
+
+
+Imap e pop
+------------------
+
+Postfix e' un server SMTP, di conseguenza se volete che i vostri utenti possano *scaricare* in locale la posta generalmente volete mettere a loro disposizione un server *POP3* o *IMAP*. Oppure entrambi.
+
+Pacchetti da installare
+ courier-imap courier-pop
+
+Si noti che IMAP necessita delle *Maildir*, non funziona con le Mailbox in ``/var/mail/`` .
+
+Client a riga di comando
+---------------------------
+
+Per testare il corretto funzionamento del server di posta e' utile avere a disposizione delle utility per inviare e leggere la posta: ovviamente da riga di comando.
+
+mailx
+~~~~~~~~~~~~~~
+
+Uno dei client piu' semplici, sopratutto per inviare un messaggioi. e' sufficiente usare una formula come::
+ mail utente@dominio.com
+
+Se il comando ``mail`` non fosse disponibile si installi il pacchetto ``mailx``.
+
+Al primo prompt si digitera' l'oggetto, il testo del messaggio (per terminare l'inserimento lasciare una riga vuota, digitare un ``punto + Invio`` su una riga vuota), la Carbon Copy (se necessaria).
+
+es::
+
+ mail andrea@localhost
+ Subject: Oggetto della mail
+ Testo del messagio,
+ per terminare il messaggio
+ lasciare una riga vuota
+ e un punto (poi Invio).
+
+ .
+ Cc:
+
+Per altrre opzioni si veda la pagina man.
+
+Mutt
+~~~~~
+
+Mutt e' uno dei gestori di posta preferiti da chi preferisce utilizzare l'interfaccia testuale per la gestione della posta.
+
+Mutt ha un file di configurazione ``.muttrc`` nella *home* dell'utente, alcuni settaggi possono essere utili:
+
+set folder="~/Maildir"
+ Per utilizzare ``/home/nome_utente/Maildir come mailbox``, invece del default ``/var/mail/nome_utente``.
+
+set editor="vim"
+ Utilizzare ``vim`` come editor per comporre i messaggi.
+
+
+Spesso e' utile poter *levvere al volo* la Mailbox / Maildir di un utente sul server di posta, per controllare se i messaggi vengono recapitati correttamente::
+
+ mutt -f /var/mail/utente
+ mutt -f /home/utente/Maildir
+
+In modo analogo si puo' consultare al volo la propia mailbox su un server remoto tramite IMAP/POP::
+
+ mutt -f imap://nome_utente@piffa.net
+
+
+Web client
+~~~~~~~~~~~~~~~
+
+Per mettere a disposizione degli utenti un client web per gestire la propria posta si installi il pacchetto: ``squirrelmail`` . Ci sono tanti altri client web disponibili: questo e' particolarmente semplice. Naturalmente 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 ./squirrelmail.conf
+
+
+Graylisting
+----------------
+
+Il *graylisting* e' un sistema relativamente poco invasivo, con un limitato consumo di risorse per limitare lo *SPAM* in arrivo sul propio server di posta. Come suggerisce il nome e' una via di mezzo tra una *white list* (una lista di mittenti privilegiata, sempre benvenuti) e una *black list* (mittenti *bannati*, banditi dal poter inviare nuovi messaggi).
+
+Il funzionamento e' relativamente semplice: ogni mittente sconosciuto viene immediatamente rifiutato con un errore *non grave* come un *server non disponibile, provare piu' tardi*. Questo inconveniente non dovrebbe mettere in difficolta' un server di posta / mittente legittimo, che dopo un periodo di attesa tentera' nuovamente di inviare il messaggio ottenendo finalmente il risultato atteso. Diversamente un *bot* per l'invio di SPAM o un applicazione improvvisata (tipicamente di derivazione virale) che stesse inviando il messaggio *probabilmente* non insisterebbe, rinunciano ad inviare il messaggio preferendo destinazioni meno problematiche.
+
+
+Abilitazione in Postfix
+~~~~~~~~~~~~~~~~~~~~~~~~
+
+Installare il pacchetto: ``postgrey`` e aggiungere il file di configurazione di Postfix ``/etc/postfix/main.cf``::
+
+ smtpd_recipient_restrictions =
+ permit_mynetworks,
+ reject_unauth_destination,
+ check_policy_service inet:127.0.0.1:60000
+
+Test
+~~~~~~~~
+
+Inviando un messaggio il client dovrebbe ricevere un iniziale messaggio di rifiuto del messaggio::
+
+ swaks --to andrea@piffa.net from andrea@mydonain.com
+ === Trying smtp.piffa.net:25...
+ === Connected to smtp.piffa.net
+ ...
+ <- 250 2.1.0 Ok
+ -> RCPT TO:<andrea@piffa.net>
+ <** 450 4.2.0 <andrea@piffa.net>: Recipient address rejected:
+ Greylisted, see http://postgrey.schweikert.ch/help/piffa.net.html
+ -> QUIT
+ <- 221 2.0.0 Bye
+ === Connection closed with remote host.
+
+A lato server si dovrebbe rilevare su ``/var/log/syslog`` qualcosa di simile::
+
+ connect from alice.mydomain.com[65.98.21.97]
+ May 28 14:53:34 r24266 postgrey: action=greylist, reason=new,
+ client_name=alice.mydomain.com,
+ client_address=10.0.0.1, sender=root@alice.mydomain.com, recipient=andrea@piffa.net
+ May 28 14:53:34 r24266 postfix/smtpd[22538]:
+ NOQUEUE: reject: RCPT from alice.mydomain.com[10.0.0.1]:
+ 450 4.2.0 <andrea@piffa.net>: Recipient address rejected: Greylisted,
+ see http://postgrey.schweikert.ch/help/piffa.net.html;
+ from=<root@alice.mydomain.com> to=<andrea@piffa.net>
+ proto=ESMTP helo=<alice.mydomain.com>
+ May 28 14:53:34 r24266 postfix/smtpd[22538]: disconnect from alice.mydomain.com[10.0.0.1]
+
+
+Statistiche
+~~~~~~~~~~~~~~~
+
+E' sempre utile poter tracciare qualche statistica sulle percentuali di messaggi ricevuti, da chi, messaggi rifiutati (e per quale motivo). Statistiche che attingono dai soliti log del server di posta ``/var/log/syslog`` di default oltre che i dedicati ``/var/log/mail`` .
+
+Una utility semplice per analizzare l'attivita' del propio server smtp potrebbe essere ``pflogsumm`` , installato il pacchetto la si puo' invocare con::
+
+ pflogsumm.pl /var/log/mail.log
+
+oppure utilizzare i log piu' vecchi ad es. ``/var/log/mail.log.0``
+
+Firewall
+==========
+
+In Informatica, nell'ambito delle reti di computer, un firewall (termine inglese dal significato originario di parete refrattaria, muro tagliafuoco, muro ignifugo; in italiano anche parafuoco o parafiamma) e' un componente passivo di difesa perimetrale che puo anche svolgere funzioni di collegamento tra due o piu' tronconi di rete. Usualmente la rete viene divisa in due sotto reti: una, detta esterna, comprende l'intera Internet mentre l'altra interna, detta LAN (Local Area Network), comprende una sezione piu' o meno grande di un insieme di computer locali. In alcuni casi e' possibile che si crei l'esigenza di creare una terza sotto rete detta DMZ (o zona demilitarizzata) atta a contenere quei sistemi che devono essere isolati dalla rete interna ma devono comunque essere protetti dal firewall.
+
+Una prima definizione chiusa di firewall e' la seguente:
+
+Apparato di rete hardware o software che filtra tutti i pacchetti entranti ed uscenti, da e verso una rete o un computer, applicando regole che contribuiscono alla sicurezza della stessa.
+
+In realta' un firewall puo' essere realizzato con un normale computer (con almeno due schede di rete e software apposito), puo' essere una funzione inclusa in un router o puo' essere un apparato specializzato. Esistono inoltre i cosiddetti "firewall personali", che sono programmi installati sui normali calcolatori, che filtrano solamente i pacchetti che entrano ed escono da quel calcolatore; in tal caso viene utilizzata una sola scheda di rete.
+
+La funzionalita' principale in sostanza e' quella di creare un filtro sulle connessioni entranti ed uscenti, in questo modo il dispositivo innalza il livello di sicurezza della rete e permette sia agli utenti interni che a quelli esterni di operare nel massimo della sicurezza. Il firewall agisce sui pacchetti in transito da e per la zona interna potendo eseguire su di essi operazioni di:
+controllo
+modifica
+monitoraggio
+
+Questo grazie alla sua capacita' di "aprire" il pacchetto IP per leggere le informazioni presenti sul suo header, e in alcuni casi anche di effettuare verifiche sul contenuto del pacchetto.
+
+Links
+------
+
+* http://openskill.info/topic.php?ID=124
+* http://iptables-tutorial.frozentux.net/iptables-tutorial.html
+
+Ipfilter
+----------
+
+Link: http://iptables-tutorial.frozentux.net/iptables-tutorial.html#IPFILTERING
+
+Natura di un firewall ip: su cosa lavora (livello 2 e un po' del 3) e su cosa *non* lavora (livello 4).
+Netfilter lavora anche su parti del livello 3 (TCP, UDP, etc) e del livello 1 (MAC source address). Iptables comunque permette di fare il *connection-tracking*, mediante il quale possiamo implementare il Network Address Translation.
+
+Netfilter non ricostruisce il flusso di dati tra pacchetti, non puo' quindi rilevare la presenza di virus o simili che si trasmettono su pacchetti separati: ricomporre, analizzare e tornare a scomporre i frammenti richiederebbe troppa RAM e risorse di sistema, con il conseguente rischio di saturare il firewall fino all'abbandono dei nuovi pacchetti in transito.
+Ci sono altri software piu' adatti a questi compiti, ad esempio un proxy HTTP come Squid che e' appunto una applicazione di quarto livello, progettata e strutturata per analizzare e modificare i flussi di dati (il *contenuto* dei pacchetti, non le sole *intestazioni*) facendo abbondate uso delle risorse RAM e di calcolo del sistema. Non a caso su macchine embedded dalle prestazioni molto ridotte (CPU ARM ~250MHZ con ~30MB di RAM) Squid sfrutta al massimo le risorse di sistema per gestire il traffico di una rete 10/100, mentre il lavoro tipico svolto da netfilter e' quasi irrilevante.
+
+Progettazione di un firewall
+-----------------------------
+
+Per implementare un firewall bisogna decidere un aio di cose: la collocazione e l'approccio (inclusivo o esclusivo) al filtraggio, il tipo di hardware.
+
+Collocazione
+~~~~~~~~~~~~~
+
+DMZ e MZ, internet, intranet, extranet. Frammentazione della rete, decidere se diversi reparti di una azienda si possano vedere tra loro e in che misura.
+
+Collocazione:
+
+ 1. sul router
+ 2. tra router e servers / LAN
+ 3. Unico server / router / firewall e connessi rischi. considerare l'acquisto di un router hardware dedicato.
+
+Layeed security:
+ Implementare piu' device / software sui diversi livelli: http://iptables-tutorial.frozentux.net/iptables-tutorial.html#HOWTOPLANANIPFILTER
+
+
+Policy di default
+~~~~~~~~~~~~~~~~~~~
+
+Drop o Accept: conseguenze per sicurezza, facilita' di gestione.
+
+
+Hardware
+~~~~~~~~~~~~
+
+Sostanzialmente potremmo distinguere due tipologie di hardware:
+
+Network appliance dedicata::
+ Un dispositivo hardware dedicato alla funzione di Firewall, ad es un Cisco / Fortigate.
+ Si noti che molti firewall economici altro non sono che Linux box molto striminzite.
+
+Server / Personal computer:
+ Un server sul quale viene fatto girare Netfilter ad uso del server stesso e della rete connessa.
+
+Vantaggi e svantaggi: consumo elettrico, efficienza, flessibilita', strumenti di gestione, sicurezza, OpenBSD.
+
+Percorso dei pacchetti tra tabelle e catene
+-------------------------------------------
+
+link: http://iptables-tutorial.frozentux.net/iptables-tutorial.html#TRAVERSINGOFTABLES
+
+
+Concetti di base
+-----------------
+
+Tabelle, catene, regole
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Iptables lavora su 3 tabelle (tables) di default:
+
+* filter - Regola il firewalling: quali pacchetti accettare, quali bloccare
+
+* nat - Regola le attivita' di natting
+
+* mangle - Interviene sulla alterazione dei pacchetti.
+
+Ogni tabella ha delle catene (chains) predefinite (INPUT, OUTPUT, FORWARD ... ) a cui possono essere aggiunte catene custom.
+Ogni catena e' composta da un elenco di regole (rules) che identificano pacchetti di rete secondo criteri diversi (es: -p tcp --dport 80 -d 10.0.0.45)
+Ogni regola termina con una indicazione (target) su cosa fare dei pacchetti identificati dalla regola stessa (es: -j ACCEPT, -j DROP ...)
+
+Match
+~~~~~~~~~~~~~~~~~
+
+I Match di una regola (rule) servono a testare un pacchetto per valutare se corrisponda a certe caratteristiche. I match di possono servire a controllare se un pacchetto e' destinato a una porta particolare o utilizza un protocollo particolare.
+
+Alcuni esempi:
+
+-p [!] proto
+ Protocollo IP. Secondo IP number o nome (es: tcp, udp, gre, ah...)
+
+-s [!] address[/mask]
+ Indirizzo IP sorgente (o network con maschera di sotto rete)
+
+-d [!] address[/mask]
+ Indirizzo IP destinazione (o network)
+
+-i [!] interface[+]
+ Interfaccia di rete di entrata ([+] wildcard)
+
+-o [!] interface[+]
+ Interfaccia di rete di uscita ([+] wildcard)
+
+-f
+ Frammento di pacchetto
+
+Targets
+~~~~~~~~~~~~~
+
+Se un pacchetto soddisfa le condizioni del Match *salta* (jump) su uno dei target possibili, in caso contrario continua il suo percorso tra regole catene e tabelle.
+
+Target principali:
+
+*-j ACCEPT*
+ Il pacchetto matchato viene accettato e procede verso la sua destinazione. Si usa per definire il traffico permesso.
+
+*-j DROP*
+ Il pacchetto viene rifiutato e scartato, senza alcuna notifica al mittente. Si usa, in alternativa a REJECT, per bloccare traffico.
+
+*-j REJECT*
+ Il pacchetto viene rifiutato. Al mittente viene mandato un pacchetto (configurabile) di notifica tipo ICMP port-unreachable (--reject-with icmp-port-unreachable)
+
+-t LOG
+ Il pacchetto viene loggato via syslog e procede l'attraversamento della catena. Opzioni: (--log-level, --log-prefix, --log-tcp-sequence, --log-tcp-options, --log-ip-options)
+
+-j DNAT
+ Viene modificato l'IP di destinazione del pacchetto. Target disponibile solo in nat / PREROUTING e nat / OUTPUT. L'opzione --to-destination IP:porta definisce il nuovo IP di destinazione. Si usa tipicamente su network firewall che nattano server di una DMZ
+
+-j SNAT
+ Viene modificato l'IP sorgente. Solo in nat / POSTROUTING. Prevede l'opzione --to-source IP:porta. Si usa per permettere l'accesso a Internet da una rete locale con IP privati.
+
+-j MASQUERADE
+ Simile a SNAT, si applica quando i pacchetti escono da interfacce con IP dinamico (dialup, adsl, dhcp...). Si usa solo in nat / POSTROUTING e prevede l'opzione --to-ports porte.
+
+-j REDIRECT
+ Redirige il pacchetto ad una porta locale. Usabile solo in nat / PREROUTING e nat / OUTPUT e' previsto per fare un transparent proxy (con proxy server in esecuzione sulla macchina con iptables)
+
+-j RETURN
+ Interrompe l'attraversamento della catena. Se questa e' una secondaria, il pacchetto torna ad attraversare la catena madre da punto in cui aveva fatto il salto nella secondaria. Se il RETURN e' in una delle catene di default, il pacchetto interrompe l'attraversamento e segue la policy di default.
+
+-j TOS
+ Usabile solo nella tabella mangle, permette di cambiare il TOS (Type Of Service) di un pacchetto con l'opzione --set-tos. Per un elenco dei parametri disponibili: iptables -j TOS -h
+
+-j MIRROR
+ Curioso e sperimentale, questo target invia un pacchetto speculare al mittente. In pratica e' come se facesse da specchio per tutti i pacchetti ricevuti. Da usare con cautela, per evitare attacchi DOS indiretti.
+
+
+Tabella Filter
+---------------
+
+E' quella implicita e predefinita (-t filter)
+Riguarda le attivita' di filtraggio del traffico.
+Ha 3 catene di default:
+INPUT - Riguarda tutti i pacchetti destinati al sistema. In entrata da ogni interfaccia.
+OUTPUT - Riguarda i pacchetti che sono originati dal sistema e destinati ad uscire.
+FORWARD - Riguarda i pacchetti che attraversano il sistema, con IP sorgente e destinazione esterni.
+
+Esempio per permettere accesso alla porta 80 locale:
+iptables -t filter -I INPUT -p tcp --dport 80 -j ACCEPT
+Analoga a: iptables -I INPUT -p tcp --dport 80 -j ACCEPT
+
+Esempio per permettere ad un pacchetto con IP sorgente 10.0.0.4 di raggiungere il server 192.168.0.1 attraversando il firewall:
+iptables -I FORWARD -s 10.0.0.4 -d 192.168.0.1 -j ACCEPT
+
+Flush automatico per macchine remote
+---------------------------------------
+
+Se state provando una configurazione del firewall per una macchina remota e' buona norma per evitare brutte figure attivare uno script che faccia il *flush* delle regole dopo qualche minuto. Potreste infatti inavvertitamente impostare una regola che vi impedisca di raggiungere la macchina remota, cosi' da non poter neanche eliminare quella regola e ripristinare la situazione precedente.
+
+*Veramente*, prima di lavorare sul firewall di una macchina remota impostate almeno un ``at now +5 min`` o con un'oretta di margine per fare il *flush* delle regole (su tutte le tabelle)::
+
+ at now +5 min
+ at> /sbin/iptables -F
+ at> [CTR+d]
+
+
+
+Gestione regole (rules)
+--------------------------
+
+Il comando iptables viene usato per ogni attivita' di gestione e configurazione.
+
+Inserimento regole:
+
+iptables -A CATENA ...
+ Aggiunge una regola alla fine della catena indicata
+
+iptables -I CATENA [#] ...
+ Inserisce alla riga # (default 1) una regola nella catena indicata
+
+iptables -N CATENA
+ Crea una nuova catena custom
+
+iptables -P CATENA TARGET
+ Imposta il target di default per la catena indicata
+
+Rimozione regole e azzeramenti:
+
+iptables -F [catena]
+ Ripulisce tutte le catene (o quella indicata)
+
+iptables -X [catena]
+ Ripulisce tutte le catene custom (o quella indicata)
+
+iptables -Z [catena]
+ Azzera i contatori sulle catene
+
+iptables -D catena #
+ Cancella la regola numero # dalla catena indicata
+
+Interrogazione:
+
+iptables -L
+ Elenca le regole esistenti
+
+iptables -L -n -v
+ Elenca, senza risolvere gli host, in modo verboso le regole esistenti
+
+
+
+
+Salvataggio regole
+----------------------
+
+Il comando ``iptables`` serve per interagire con il framework ``Netfilter`` che gestisce il firewall di Linux al livello del kernel. Questo comporta, in modo analogo a quando avviene col comando ``ifconfig``, che i cambiamenti impostati siano in *tempo reale, RAM*, non persistenti nel sistema: al boot successivo 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
+ # Seguono 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 precedentemente 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
+
+
+Esempi
+-------------
+
+Seguono alcuni esempi sull'uso di iptables, lo scenario e' un computer con un paio di schede di rete fisiche una delle quali collegata alla rete internet l'altra a una rete privata per la LAN interna.
+
+ 1. ``eth0`` scheda di rete principale sulla rete privata interna 192.168.0.0/24
+
+ 2. ``eth1`` scheda di rete secondaria per la connessione ad internet
+
+ 3. ``ppp0`` punto-a-punto per una connessione ad internet
+
+Bloccare i ping dall'esterno
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Spesso gli script che attaccano *automaticamente* le varie reti provano a fare un ping per verificare quali IP sono on-line: bloccare il traffico ``ICMP`` in ingresso puo' aiutare ad evitare parte di questi attacchi::
+
+ iptables -A INPUT -i ppp0 -p ICMP -j DROP
+
+Masquerading (sNAT)
+~~~~~~~~~~~~~~~~~~~~
+
+Per attivare la network address translation (in questo caso un SNAT) per la rete locale privata sull'indirizzo ip del *modem*::
+ iptables -A POSTROUTING -s 192.168.0.0/255.255.255.0 -o ppp0 -j MASQUERADE
+
+Il *Masquerading* a differenza dello *SNAT* puro (``-j SNAT --to-source proprio_ip_pubblico ) legge l'indirizzo ip del device ``ppp0``. In questo modo se l'IP cambia automaticamente si aggiorna anche il source natting. Se avete un indirizzo IP statico assegnato al vostro gateway potete invece usare lo SNAT semplice.
+
+Altri esempi::
+ ## Change source addresses to 1.2.3.4.
+ # iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to 1.2.3.4
+
+ ## Change source addresses to 1.2.3.4, 1.2.3.5 or 1.2.3.6
+ # iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to 1.2.3.4-1.2.3.6
+
+ ## Change source addresses to 1.2.3.4, ports 1-1023
+ # iptables -t nat -A POSTROUTING -p tcp -o eth0 -j SNAT --to 1.2.3.4:1-1023
+
+Brute force
+~~~~~~~~~~~~
+
+Per limitare attacchi di tipo brute force su SSH::
+
+ iptables -A INPUT -i ppp0 -p tcp -m tcp --dport 22 -m state --state NEW -m recent --update --seconds 3000 --hitcount 4 --name DEFAULT --rsource -j DROP
+
+ iptables -A INPUT -i ppp0 -p tcp -m tcp --dport 22 -m state --state NEW -m recent --set --name DEFAULT --rsource
+
+
+FTP Server
+===========
+
+Il File Transfer Protocol (FTP) (protocollo di trasferimento file), è un Protocollo per la trasmissione di dati tra host basato su TCP, in genere usato dagli autori di pagine web per *pubblicare* queste nei propio spazi web. Storicamente veniva anche usato, mediate l'utilizzo di utenze anonime, come punto di scambio per materiali di vari utenti tra loro sconosciuti (una directory dei materiali scaricabili e una dedicata agli *uploads* degli utenti, poi riordinati dall'*ftpmaster*). Tuttora si mantiene la cosuetudine di renedere disponibile i materiali dei *mirrors* anche tramite FTP, probabilmente per garantire l'accesso ai client piu' datati che non possono utilizzare tecnologie piu' recenti.
+
+
+Il protocollo FTP e' in chiaro (cioe' non criptato), sia per quanto riguarda il traffico ad esso associato che per il passaggio delle passwords degli utenti, facilmente sniffabili da chiunque abbia accesso alla rete. Naturalmente vsftp per quanto votato alla sicurezza non modifica queste caratteristiche del protocollo FTP (ma consente di usare OpenSSL per la autenticazione degli utenti).
+
+Se propio si deve mettere a disposizione un server FTP ai propi utenti si considerino le seguenti alternative:
+
+- Spingere gli utenti ad usare SFTP invece che FTP
+- Spingere gli utenti ad usare SSL per autenticarsi al server FTP
+- Nel caso di webdesigners si consideri la possibilita' di offrire alternative come GIT, Subversion, Rsync o Webdav
+
+Nel caso non si possa evitare il server FTP:
+
+- Non dare agli utenti FTP una shell di sistema ( Concedere come shell ``ftp`` al posto di ``bash`` in ``/etc/passwd``)
+- Rendere il filesytem su cui scrive il demone FTP ``noexec`` e ``nosuid`` (vedi dopo)
+- Utilizzare un demone FTP come Vsftp: un server FTP con una forte inclinazione alla sicurezza: *Very Secure FTP Daemon*.
+
+Per maggiori informazioni sulle scelte di design legate alla sicurezza del demone si veda: http://vsftpd.beasts.org/DESIGN
+
+Vsftp mette a disposizione le seguenti funzionalita':
+
+- Virtual IP configurations
+- Virtual users
+- Standalone or inetd operation
+- Powerful per-user configurability
+- Bandwidth throttling
+- Per-source-IP configurability
+- Per-source-IP limits
+- IPv6
+- Encryption support through SSL integration
+
+
+Pacchetti
+---------------
+
+Per installare il demone vero e propio si usi il pacchetto ``vsftpd`` , mentre per aver un client da cui fare qualche test sono dipsonibili:
+
+- ``ftp`` (pacchetto da installare) e' il solito client a riga di comando
+- ``gftp`` e' un client grafico simile al classico *WSftp*
+- Normalmente i file mananager com Konqueror possono lavarorare come client FTP
+
+
+Sessioni ftp
+-------------
+
+Vediamo alcuni dei comandi di base per gestire una sessione ftp a riga di comando:
+
+ftp nome_host
+ stabilire la connessione all'host, poi verra' chiesta la password dell'utente. Se avete sbagliato utente: user .
+
+help
+ Lista dei comandi disponibili.
+help [nome_comando]
+ Cosa fa quel comando.
+put
+ Per caricare un file.
+get
+ Per scaricare un file.
+ls
+ Lista dei file disponibili.
+cd
+ Spostarsi in un altra directory.
+lcd
+ Cambio directory in LOCALE.
+mput/mget
+ Per lavorare su file multipli.
+prompt
+ Per uscire dalla modalita' interattiva
+ (non vi chiede conferma di ogni singola operazione
+ su ogni singolo file...).
+binary
+ Entra in modalita' trasferimento binario.
+asii
+ Entra in modalita' trasferimento ascii.
+bye
+ Per chiudere la sessione.
+
+
+Configurazione iniziale
+------------------------
+
+Il demone di vsftpd e' immediatamente disponibile ma solo in modalita' anonima (si pensi a uno scenario in cui si vuole rendere disponibili dei files tramite FTP) e in *sola lettura*. Per accedere al servizio si usi quini come utente ``anonymous`` (la passwords in genere e' come consuetudine il propio indirizzo email), la cui *home* directory sara' ``/home/ftp/``::
+
+ zoo:~# ftp localhost
+ Connected to localhost.localdomain.
+ 220 (vsFTPd 2.0.7)
+ Name (localhost:root): anonymous
+ 331 Please specify the password.
+ Password:
+ 230 Login successful.
+ Remote system type is UNIX.
+ Using binary mode to transfer files.
+ ftp> ls
+ 200 PORT command successful. Consider using PASV.
+ 150 Here comes the directory listing.
+ -rw-r--r-- 1 0 0 0 Feb 03 17:17 anoni
+ 226 Directory send OK.
+
+
+
+Abilitare gli utenti locali
+----------------------------
+
+
+Per poter modificare le impostazioni iniziali, ad esempio per permettere l'accesso agli utenti del server, si modifichera' il file ``/etc/vsftpd.conf``, a seguire le impostazioni fondamentali ed altre interessanti per rendere il server accessibile da utenti di sistema (autenticati tramite la loro password, quindi con PAM) per il tipico utilizzo di web designers che debbano pubblicare le loro pagine web (e non si siano fatti convincere a usare SFTP!)::
+
+
+ # Allow anonymous FTP? (Beware - allowed by default if you comment this out).
+ anonymous_enable=NO
+ # Disabilitiamo l'utente anonimo
+
+ # Uncomment this to allow local users to log in.
+ local_enable=YES
+ # Accesso garantito agli utenti di sistema
+
+ # Uncomment this to enable any form of FTP write command.
+ write_enable=YES
+ # Permettiamo agli utenti di caricare documenti nella loro home
+
+ # You may fully customise the login banner string:
+ ftpd_banner=Benvenuti al servizio ftp del sito example.com
+
+
+Per abilitare i cambiamenti si proceda a riavviare il server: ``/etc/init.d/vsftpd restart`` e si monitorizzi il file di log ``tail -f /var/log/vsftpd.log`` per controllarne il funzionamento (e anche ``/var/log/syslog`` nel caso non si riuscisse a far partire correttamente il servizio.
+
+NOTE: Se non riuscite ad ottenere un *directory listing* (``ls``) ottenendo un errore ``500 Illegal PORT command? FTP error`` abilitare la modalita' passiva col comando ftp ``passive``.
+
+
+Jail chroot
+------------
+
+Si puo' impedire all'utente di spostarsi arbitrariamente per il file system del servere visualizzare il contenuto delle directory, ad esempio la cartella ``/etc``, confinandolo in una jail chroot limitata alla sua home directory::
+
+ # You may restrict local users to their home directories. See the FAQ for
+ # the possible risks in this before using chroot_local_user or
+ # chroot_list_enable below.
+ chroot_local_user=YES
+
+
+Generalmente un utente di sistema con il solo accesso FTP non dovrebbe avere la possibilita' di poter navigare liberamente per il file system del server, esponendo file di configurazione e quant'altro l'utente potrebbe trarre utili informazioni sul quali software siano installati e di che tipo::
+
+
+ Remote system type is UNIX.
+ Using binary mode to transfer files.
+ ftp> pwd
+ 257 "/"
+ ftp> cd /etc/
+ 550 Failed to change directory.
+
+
+Permessi sul filesystem
+-------------------------
+
+Come accennato precedentemente e' opportuno che i filesystems sui quali un utente puo' scrivere o modificare il contenuto non abbiano i privilegi di eseguibilita' e suid, nel nonstro caso vsftpd lavora sull'intera ``/home/`` directory quindi avremo in ``/etc/fstab``::
+
+ /dev/mapper/store-homes /home ext3 rw,nosuid,noexec 0 2
+
+
+
+Altre opzioni
+-----------------
+
+xferlog_enable=YES
+ Verra' tenuto un file di log ``/var/log/vsftpd.log`` degli upload e download sul server.
+
+hide_ids=YES
+ Nasconde le userid e groupid mascherandole con ``ftp`` .
+
+anon_root=/home/ftp
+ Home directory dell'utente anonimo.
+
+write_enable=YES
+ Permette agli utenti di eseguire i comandi che possono modificare il filesystem: STOR, DELE, RNFR, RNTO, MKD, RMD, APPE e SITE .
+
+idle_session_timeout=600
+ Permette agli utenti di restare connessi piu' a lungo, utile per i webdesigners che passano intere giornate connessi al server.
+
+
+
+