+
+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.
+
+
+
+