===============================
-Servizi Di rete passo a passo
+Servizi di rete passo a passo
===============================
----------------------------------------------------------
Appunti sulla installazione e configurazione dei servizi
:Author: Andrea Manni
:Copyright: GFDL
- :Version: 0.3
+ :Version: 0.5
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.
Bash completion
-------------------
Questo file contiene le opzioni di apt, come ad esempio il proxy::
- Acquire::http::Proxy "http://10.10.208.254:3128"
+ Acquire::http::Proxy "http://10.10.208.254:3128";
Si tenga conto che se si imposta un proxy per apt sul proprio portatile e tornati a casa propria si vuole scaricare nuovi pacchetti si dovra' disabilitare il proxy.
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 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.
+
+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]
+ #
+ # You can specify multiple cache_dir lines to spread the
+ # cache among different disk partitions.
+ # ...
+ #Default:
+ # cache_dir ufs /var/spool/squid3 100 16 256
+ cache_dir aufs /var/spool/squid3 300 24 256
+ # algoritmo
+ # path della cache
+ # dimensione in MB
+ # 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 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' opportuno 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/??
+ # squid3 -z
+ # /etc/init.d/squid3 start
+
+TAG: maximum_object_size
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+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: maximum_object_size (1760)
+ # Objects larger than this size will NOT be saved on disk. The
+ # value is specified in kilobytes, and the default is 4MB. If
+ # you wish to get a high BYTES hit ratio, you should probably
+ # increase this (one 32 MB object hit counts for 3200 10KB
+ # hits). If you wish to increase speed more than your want to
+ # save bandwidth you should leave this low.
+ #
+ # NOTE: if using the LFUDA replacement policy you should increase
+ # this value to maximize the byte hit rate improvement of LFUDA!
+ # See replacement_policy below for a discussion of this policy.
+ #
+ #Default:
+ # maximum_object_size 4096 KB
+ maximum_object_size 150 MB
+
+TAG: cache_mem
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+*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
+ # for:
+ # * In-Transit objects
+ # * Hot Objects
+ # * Negative-Cached objects
+ #Default:
+ # cache_mem 8 M
+ cache_mem 100 M
+
+
+TAG: minimum_object_size
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+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::
+
+ # TAG: minimum_object_size (bytes)
+ # Objects smaller than this size will NOT be saved on disk. The
+ # value is specified in kilobytes, and the default is 0 KB, which
+ # means there is no minimum.
+ #
+ #Default:
+ # minimum_object_size 0 KB
+ minimum_object_size 0 KB
+
+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.
+
+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
+~~~~~~~~~~~~~~~~~~~~~
+Si proceda a creare una ``ACL`` di tipo ``src`` per identificare la lostra rete locale, poi si abiliti l'accesso a questa con la direttiva ``http_access``. Tutto quanto non e' espressamente autorizzato viene poi negato da un ``http_access deny all`` finale.
+
+::
+
+ # TAG: acl
+ # Defining an Access List
+ #
+ # Every access list definition must begin with an aclname and acltype,
+ # followed by either type-specific arguments or a quoted filename that
+ # they are read from.
+ # ...
+ # ***** ACL TYPES AVAILABLE *****
+ #
+ # acl aclname src ip-address/netmask ... # clients IP address
+ # riga 588
+
+ # Example rule allowing access from your local networks.
+ # Adapt to list your (internal) IP networks from where browsing
+ # should be allowed
+ #acl localnet src 10.0.0.0/8 # RFC1918 possible internal network
+ #acl localnet src 172.16.0.0/12 # RFC1918 possible internal network
+ #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
+ #
+ # Access to the HTTP port:
+ # http_access allow|deny [!]aclname ...
+ #
+ # NOTE on default values:
+ #
+ # If there are no "access" lines present, the default is to deny
+ # the request.
+
+ # Riga 643
+ # INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS
+
+ # Example rule allowing access from your local networks.
+ # Adapt localnet in the ACL section to list your (internal) IP networks
+ # from where browsing should be allowed
+ #http_access allow localnet
+ http_access allow localnet
+
+Testare Squid
+---------------
+
+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.
+
+
+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.
+
+Da notare che la prova va' fatta su una macchina della rete che si vuole testare, non da *localhost*. Per altro se si utilizzasse *direttamente* ``localhost`` non si testerebbe la *ACL* predisposta, dato che si si rientrerebbe nella ACL (pre-configurata di default) ``localhost``.
+
+.wgetrc
+ http_proxy=10.10.208.178:3128
+
+Si proceda a scaricare dal client scelto con un wget::
+
+ 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
========
+Apache HTTP Server, o piu' comunemente Apache, e' il nome dato alla piattaforma server Web modulare piu' diffusa (ma anche al gruppo di lavoro open source che ha creato, sviluppato e aggiornato il software server), in grado di operare da sistemi operativi UNIX-Linux e Microsoft.
+
+Un server web e' un processo, e per estensione il computer su cui e' in esecuzione, che si occupa di fornire, su richiesta del browser, una pagina web (spesso scritta in HTML). Le informazioni inviate dal server web viaggiano in rete trasportate dal protocollo HTTP. L'insieme di server web dà vita al World Wide Web, uno dei servizi piu' utilizzati di Internet.
+
Pacchetti da installare::
+----------------------------
apache2 apache2-doc
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
+ File di configurazione principale del servizio.
+
httpd.conf e' il vecchio file di configurazione di Apache1, presente per motivi di retrocompatibilita' e' generalemente vuoto.
ports.conf
Guardiamo alcune direttive interessanti:
-timeout
+Timeout
Numero di secondi da aspettare prima di chiudere la connessione con il client. Questo parametro serve a liberare le risorse di sistema nel caso che un client, magar a causa di una connessione particolarmente lenta o instabili, tenga attivo indefinitivamente un processo di apache.
KeepAlive
- L'estensione keep-alive (http 1.0) congiuntamente alle connessioni persistenti (http 1.1) permettono al server di rispondere a piu' richieste dei client mediante la stessa connessione. Il protocoll http per sua natura e' connectio-less e senza stato, quindi ogni risorsa richiesta (per pagine web si pensi ad esempio alle immagini) dal client necessita di una connessione autonoma. Keep-alive permette di ottimizzare la connessione anche fino al 50% a seconda delle situazioni e contenuti.
+ L'estensione keep-alive (http 1.0) congiuntamente alle connessioni persistenti (http 1.1) permettono al server di rispondere a piu' richieste dei client mediante la stessa connessione. Il protocoll http per sua natura e' senza stato (*statelessi* ), quindi ogni risorsa richiesta (per pagine web si pensi ad esempio alle immagini) dal client necessita di una connessione autonoma. Keep-alive permette di ottimizzare la connessione anche fino al 50% a seconda delle situazioni e contenuti.
Server-Pool Size Regulation
Questi parametri (StartServers, MinSpareServers, ecc. Tutti spiegati nel manuale di apache) servono per attribuire le risorse di sistema disponibili al server Apache. Tenere questi parametri bassi serve a limitare il rischio di Denial of Service per il server, nel caso offra altri servizi. I settagi di default sono come sempre abbastanza conservativi, se si conta di usare il proprio Apache per servire un sito web con molti visitatori sara' necessario aumentare sensibilmente le impostazioni di base.
<?php phpinfo() ; ?>
-Questa funzione di php generera' la tipica pagina con le impostazioni attuali per php, se richiamando la pagina (es: ``http://localhost/info.php`` ) verra generata la pagina e resa disponibile tramite apache agli utenti allora l'integrazione tra PHP e Apache sara' corretta. In caso contrario se il client http proporra di scaricare la pagina invece che visualizzarla nel browser: non funziona l'interprete di php o sono mal configurati i MIME-type.
-
+Questa funzione di php generera' la tipica pagina con le impostazioni attuali per PHP. Richiamando la pagina (es: ``http://localhost/info.php`` ) verra generata dall'interprete PHP la pagina HTML e resa disponibile tramite Apache ai utclient HTTP, a prova del correto funzionamento del modulo di PHP e della sua integrazione con il serv web Apache. In caso contrario se il client http proporra di scaricare la pagina invece che visualizzarla nel browser: non funziona l'interprete di php o sono mal configurati i MIME-type. prima di tutto assicurarsi di aver fatoo ripartire Apache.
Installazione del supporto per Mysql
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Phpmyadmin dovrebbe essere disponibile all'URL: ``http://localhost/phpmyadmin/``, se cosi non fosse controllare che sia incluso il file ``/etc/phpmyadmin/apache.conf`` in ``/etc/apache2/conf.d/`` .
-
-
-
Installazione del supporto per Postgresql
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Controllare tramite la pagina php.info che sia abilitato il supporto per PostgreSQL (ripartito Apache, ricaricare la pagina e cercare con CTRL+f ``pgsql``).
+
+phppgadmin
+~~~~~~~~~~~~~~~~~~~~~
+
+L'interfaccia web Phppgadmin per il database server PostgreSQL non richede necessariamente la presenza di un database locale, puo' infatti essere utilizzata per gestire databases remoti (il suo file di configurazione: ``/etc/phppgadmin/config.inc.php`` ). Nel caso si voglia installare localmente Mysql si utilizzi il pacchetto ``postgresql`` .
+
+Phpmyadmin dovrebbe essere disponibile all'URL: ``http://localhost/phppgadmin/``, se cosi non fosse controllare che sia incluso il file ``/etc/phppgadmin/apache.conf`` in ``/etc/apache2/conf.d/`` .
+
Virtual hosts
--------------------
* http://www.onlamp.com/pub/a/apache/2004/01/08/apacheckbk.html
-I virtual host permettono di avere piu' siti internet disponibile tramite lo stesso server web, eventualmente mappati su un solo indirizzo ip. Sono generalemente di due tipi:
+I virtual host permettono di avere piu' siti internet disponibili tramite lo stesso server web, eventualmente mappati su un solo indirizzo ip. Sono generalemente di due tipi:
- * Basati su indirizzi ip diversi.
- Se si ha la possibilita' di avere piu' indirizzi ip dedicati per i diversi siti che si vuole servire. ES: <VirtualHost 192.168.0.2:80> . Soluzione dispendiosa, si tende ad usarla solo se servono certificati di sicurezza (SSL ) dedicati per ogni sito.
+ * Basati su *indirizzi ip*.
+ Se si ha la possibilita' di avere piu' indirizzi ip dedicati per i diversi siti che si vuole servire. ES: ``<VirtualHost 192.168.0.2:80>`` . Soluzione dispendiosa, si tende ad usarla solo se servono certificati di sicurezza (SSL ) dedicati per ogni sito.
- * Basati su nomi di dominio diversi che puntano allo stesso ip.
+ * Basati su *nomi di dominio* che puntano allo stesso ip.
Soluzione piu' economica e diffusa che si basa sulle funzionalita' di http 1.1 .
Prenderemo in esame la gestione di virtual hosts basati su nomi di dominio.
Prima di tutto per poter impostare i virtual hosts dovete avere un server DNS che risolva i vostri nomi di dominio sull'indirizzo ip del server. Questo si puo' ottenere in vari modi, ad es:
- * Bind
+ *Bind* (DNS server)
Impostare i campi A nelle proprie zone gestite dal server dns Bind. Ad es: ``papo A 212.22.136.248``
- * Servizio DNS dinamico on line.
+ *Servizio DNS dinamico on line*.
Utilizzare un servizio come ad es: https://www.dyndns.com/ per mappare nomi di dominio sul proprio indirizzo ip, comodo ad esempio se si dispone di un indirzzo ip pubblico (anche se dinamico) per la propria connessione ad internet.
- * Dnsmasq
+ *Dnsmasq* (DNS server)
Utilizzabile a livello locale per fare dei test, utilizzando direttive come: ``address=/davide.piffa.net/10.10.208.178``
- * /etc/hosts
+ ``/etc/hosts``
Per prove *strettamente a livello locale* potete impostare i nomi dei vostri virtual server nel file /etc/hosts .
-
-Testare con dig (disponibile nel pacchetto ``dnsutils`` ) il nome di dominio che si vuole utilizzare::
+::
# dig 177.piffa.net
Virtual host
~~~~~~~~~~~~~~
-Esempio di Virtual host
+Esempio di Virtual host::
+
+ <VirtualHost *:80 >
+ ServerName 177.piffa.net
+ DocumentRoot /var/www/177.piffa.net/
+ ServerAdmin webmaster@177.piffa.net
+ </VirtualHost>
+
+1. ``<VirtualHost \*:80 >`` La prima riga indica l'inizio della stanza relativa al nostro virtual host, che ascolotera' su qualunque indirizzo ip (nel caso il server abbia piu' indirizzi dai quali e' raggiungibile) sulla porta ``80``.
+2. ``Server/name`` precisa quale sara' il nome di dominio a cui verra' associato questo sito rispetto ad altri eventualmenti presenti sullo stesso server web.
+3. ``DocumentRoot`` : il path della directory che contiene le pagine del sito.
+4. ``ServerAdmin``: l'indirizzo del webmaster, in modo da poterlo contattare in caso di problemi col sito.
+5. ``</VirtualHost>``: *tag* di chiusura della stanza di definizione del virtual host.
+
+Quelle che abbiamo appena visto sono le direttive essenziali per definire un sito virtuale, potrebbe essere utile aggiungene altre:
+
+* ``ErrorLog /var/log/apache2/177.piffa.net/error.log``
+ Log degli errori separato dai restanti siti web ospitati dal server.
+
+* ``LogLevel warn``
+ Livello di importanza degli eventi loggati= warning *attenzione* .
+
+* ``CustomLog /var/log/apache2/177.piffa.net/access.log combined``
+ Log di accesso separati dagli altri siti, utile anche qua per statistiche di accesso per il solo sito virtuale.
+
+
+Potrebbe essere utile modificare le impostazioni di una intera directory, ad esempio per abilitare l'``AuthConfig``::
+
+ <Directory "/var/www/miosito.net/privata">
+ AllowOverride AuthConfig
+ Options ExecCGI Indexes MultiViews FollowSymLinks
+ Order allow,deny
+ Allow from all
+ </Directory>
+
+``AllowOverride AuthConfig`` ora vale per l'intera directory, come le altre opzioni.
+
+Negoziazione accessi
+---------------------
+
+Tipicamente quando si installa un server web il proprio desiderio e' di dare accesso ai materiali disponibili al maggior numero di visitatori possibile. Talvolta pero' puo essere utile o necessario limitare gli accessi, ad esempio per escludere un *bot* indesiderato che scansiona ininterottamente le nostre pagine o per creare una *Area Riservata* i cui materiali non devono essere disponibile a tutti.
+
+Limiti su base ip
+~~~~~~~~~~~~~~~~~~~~~~
+
+La forma piu' semplice di restrizine degli accessi e' su base degli indirizzi IP dei client: tipicamente i siti web sono settati per dare accesso a chiunque::
+
+ <VirtualHost *:80 >
+ # ...
+ <Directory "/var/www/177.piffa.net">
+ Order allow,deny
+ Allow from all
+ </Directory>
+ </VirtualHost>
+
+Potremmo negare l'accesso a uno o piu' indirizzi IP in questo modo::
+
+ <VirtualHost *:80 >
+ <Directory "/var/www/177.piffa.net">
+ Order allow,deny
+ Allow from all
+ Deny from 192.168.0.1
+ </Directory>
+ </VirtualHost>
+
+Ora l'IP 192.168.0.1 non potra' piu' accedere ai materiali dell'intero sito virtuale, oppure potremmo lavorare su una sola directory::
+
+ <Directory "/var/www/miosito.net/limitata">
+ Order allow,deny
+ Allow from 192.168.0.0./24
+ Deny from all
+ </Directory>
+
+In questo modo solo la classe IP ``192.168.0.0/24`` potra' accedere alla directory ``/limitata``
+Si tenga pero' conto che e' relativamente facile per un malintenzionato cambiare il propio indirizzo ip, oppure collegarsi da un altra zona. Meno facile e' accedere ad una classe privata trovandosi all'esterno di questa, ma e' comunque possibile mandare delle richieste ``GET`` per cercare di mandare in Denial Of Service il webserver.
+
User Authentication
-------------------------
+---------------------
+
+A volte conviene negoziare gli accessi ad un area di un sito tramite autenticazione basata sull'accopiata *nome utente / password*. Questo puo' venire utile per creare una area download *intranet*, alla quale possano accedere solo gli utenti previsti a prescindere dagli indirizzi IP dei loro client. Per quanto esistano soluzioni piu' granulari e sofisticate per ottenere questo, *mod-auth* puo'essere sufficente. E mod auth non richiede l'installazione di software aggiuntivi.
+
link: http://www.apacheweek.com/features/userauth
+Definire la cartella
+~~~~~~~~~~~~~~~~~~~~~~
+
+Decidere quale sara' il *path* della cartella da sottoporre ad autentizazione:(e creiamo la cartella):
+
+ ``mkdir /var/www/177.piffa.net/privata``
+
+Creazione del database delle passwords
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Un modo semplice per gestire una database di *user-id / passwords* e' utilizzare l'utility ``htpasswd`` di Apache. Questa crea un file in cui un *crypt* delle password viene associato agli utenti.
+
+Si dovra' decidere dove tenere questo file, la cosa importante e' che non sia visibile nel sito web: non deve essere scaricabile dai visitatori. Deve essere cioe' all'esterno della *DocumentRoot*: un buon posto potrebbe essere la /home dell'utente.
+
+Creiamo (con il *flag* ``-c``) il file ``/home/utente/passwords`` con l'utente ``luca``::
+
+ htpasswd -c /home/utente/passwords luca
+
+``htpasswd`` ci chedera' la password da associare all'utente ``luca``. Per sucessive modifiche della password o aggiunta di nuovi utenti non sara' necessario usare il flag ``-c``.
+
+Configurazione di Apache
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Ora possiamo passare alla configurazione vera e propria di Apache, ma con una novita': andremo a inserire la voce in un ``.htaccess`` invece che modificare il file di impostazione del virtual-host.
+
+Questo per motivi pratici: solo l'utente *root* puo' modificare l'impostazione del virtual host nel file ``/etc/apache2/sites-enabled/177.piffa.net``, ma spesso il motivo per cui creiamo i virtual hosts e' ospitare i siti di altri utenti, che possono solo pubblicare (generalmente tramite *FTP*) i loro documenti nella loro *DocumentRoot*, senza poter quindi modificare in alcun modo la configurazione del virtual host.
+
+Dando agli utenti la possibilita' di modificare (*AllowOverride*) autonomamente alcuni parametri (in questo caso solo l'*AuthConfig*) relativi al funzionamenteo del loro spazio web ci togliera' l'incombenza di dover intervenire suii vari virtual host.
+
+Abilitiamo l'AllowOverride nel file di configurazione del virtual host per la sola directory ``privata``::
+
+ <VirtualHost *:80 >
+ ServerName 177.piffa.net
+ DocumentRoot /var/www/177.piffa.net/
+ ServerAdmin webmaster@177.piffa.net
+ <Directory "/var/www/177.piffa.net/privata">
+ AllowOverride AuthConfig
+ </Directory>
+ </VirtualHost>
+
+Per rendere il cambiamento effettivo sara' necessario fare un restart / reload di Apache.
+
+Ora sara' possibile, anche per l'utente di sistema, creare un fie ``.htaccess`` che sara' onorato da Apache.
+
+/var/www/177.piffa.net/privata/.htaccess ::
+
+ # Questo file viene incluso
+ # nella configurazione del sito web
+ # Messaggio visualizzato al prompt per l'autenticazione
+ AuthName "Area privata soggetta ad autentizazione"
+ # tipo di autenticazione da usarsi
+ AuthType Basic
+ # File generato precedentemente con htpasswd
+ AuthUserFile /home/utente/passwords
+
+ # Negoziazione degli accessi
+ # valid users permette l'accesso agli utenti specificati
+ # nel file generato da htpasswd
+ require valid-user
+
+Si noti che non e' necessario fare ripartire Apache per onorare i cambiamenti (un utente non avrebbe la possibilita' di farlo!).
+
Cavets
-----------
* Proxy: nei settaggi del browser specificare di non utilizzare un server proxy http per il sito web locale (o per gli altri che si stanno monitorando). Se si ha il controllo del proxy server: stopparlo, ricaricare la pagina (operazione che fallira'), far ripartire il proxy, ricaricare la pagina.
- * Provare con un altro browser, o cercare di svuotare la cache chiudere/riaprire l'applicativo. Provare a fermare Apache, ricaricare la pagina (operazione che fallira'), far ripartire il Apache, ricaricare la pagina.
+ * Provare con un altro browser, o cercare di svuotare la cache chiudere/riaprire l'applicativo. Provare a fermare Apache, ricaricare la pagina (operazione che fallira'), far ripartire Apache, ricaricare la pagina.
Domain Name System
====================
-Informazioni di base sul servizio DNS.
-------------------------------------------
-
-Domain Name System (spesso indicato con DNS) è un servizio utilizzato per la risoluzione di nomi di host in indirizzi IP e viceversa. Il servizio è realizzato tramite un database distribuito, costituito dai server DNS.
+Domain Name System (spesso indicato con DNS) e' un servizio utilizzato per la risoluzione di nomi di host in indirizzi IP e viceversa. Il servizio e' realizzato tramite un database distribuito, costituito dai server DNS.
Il nome DNS denota anche il protocollo che regola il funzionamento del servizio, i programmi che lo implementano, i server su cui questi girano, l'insieme di questi server che cooperano per fornire il servizio.
-I nomi DNS, o "nomi di dominio", sono una delle caratteristiche più visibili di Internet.
+I nomi DNS, o "nomi di dominio", sono una delle caratteristiche piu' visibili di Internet.
-C'è confusione in merito alla definizione dell'acronimo: la S spesso viene interpretata come service, ma la definizione corretta è system.
+C'e' confusione in merito alla definizione dell'acronimo: la S spesso viene interpretata come service, ma la definizione corretta e' system.
-L'operazione di convertire un nome in un indirizzo è detta risoluzione DNS, convertire un indirizzo IP in nome è detto risoluzione inversa.
+L'operazione di convertire un nome in un indirizzo e' detta risoluzione DNS, convertire un indirizzo IP in nome e' detto risoluzione inversa.
Nomi di dominio
-----------------
-Un nome a dominio è costituito da una serie di stringhe separate da punti, ad esempio it.wikipedia.org. A differenza degli indirizzi IP, dove la parte più importante del numero è la prima partendo da sinistra, in un nome DNS la parte più importante è la prima partendo da destra. Questa è detta dominio di primo livello (o TLD, Top Level Domain), per esempio .org o .it.
+Un nome a dominio e' costituito da una serie di stringhe separate da punti, ad esempio it.wikipedia.org. A differenza degli indirizzi IP, dove la parte piu' importante del numero e' la prima partendo da sinistra, in un nome DNS la parte piu' importante e' la prima partendo da destra. Questa e' detta dominio di primo livello (o TLD, Top Level Domain), per esempio .org o .it.
-Un dominio di secondo livello consiste in due parti, per esempio wikipedia.org, e così via. Ogni ulteriore elemento specifica un'ulteriore suddivisione. Quando un dominio di secondo livello viene registrato all'assegnatario, questo è autorizzato a usare i nomi di dominio relativi ai successivi livelli come it.wikipedia.org (dominio di terzo livello) e altri come some.other.stuff.wikipedia.org (dominio di quinto livello) e così via.
+Un dominio di secondo livello consiste in due parti, per esempio wikipedia.org, e cosi' via. Ogni ulteriore elemento specifica un'ulteriore suddivisione. Quando un dominio di secondo livello viene registrato all'assegnatario, questo e' autorizzato a usare i nomi di dominio relativi ai successivi livelli come it.wikipedia.org (dominio di terzo livello) e altri come some.other.stuff.wikipedia.org (dominio di quinto livello) e cosi' via.
Tipologie di record
Ad un nome DNS possono corrispondere diversi tipi di informazioni. Per questo motivo, esistono diversi tipi di record DNS. Ogni voce del database DNS deve essere caratterizzata da un tipo. I principali tipi sono:
-* Record A - Indica la corrispondenza tra un nome ed uno (o più) indirizzi IP (per la precisione indirizzi IPv4, ovvero la versione attualmente in uso).
+* Record A - Indica la corrispondenza tra un nome ed uno (o piu') indirizzi IP (per la precisione indirizzi IPv4, ovvero la versione attualmente in uso).
* Record MX - (Mail eXchange) indica a quali server debba essere inviata la posta elettronica per un certo dominio.
-* Record CNAME - Sono usati per creare un alias, ovvero per fare in modo che lo stesso calcolatore sia noto con più nomi. Uno degli utilizzi di questo tipo di record consiste nell'attribuire ad un host che offre più servizi un nome per ciascun servizio. In questo modo, i servizi possono poi essere spostati su altri host senza dover riconfigurare i client, ma modificando solo il DNS.
+* Record CNAME - Sono usati per creare un alias, ovvero per fare in modo che lo stesso calcolatore sia noto con piu' nomi. Uno degli utilizzi di questo tipo di record consiste nell'attribuire ad un host che offre piu' servizi un nome per ciascun servizio. In questo modo, i servizi possono poi essere spostati su altri host senza dover riconfigurare i client, ma modificando solo il DNS.
* Record PTR - Il DNS viene utilizzato anche per realizzare la risoluzione inversa, ovvero per far corrispondere ad un indirizzo IP il corrispondente nome a dominio. Per questo si usano i record di tipo "PTR" (e una apposita zona dello spazio dei nomi in-addr.arpa).
* Record AAAA - Restituisce un indirizzo IPv6.
* Record SRV - Identificano il server per un determinato servizio all'interno di un dominio. Possono essere considerati una generalizzazione dei record MX.
mount -t smbfs //localhost/sambo_share /mnt/sambo_mount/ --verbose -o user=sambo
+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 può anche svolgere funzioni di collegamento tra due o piu' tronconi di rete. Usualmente la rete viene divisa in due sottoreti: 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 sottorete 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 è 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 realtà un firewall può essere realizzato con un normale computer (con almeno due schede di rete e software apposito), può essere una funzione inclusa in un router o può 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 funzionalità principale in sostanza è 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 capacità 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 rtichiederebbe 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 *inestazioni*) 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 distinquere 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, efficenza, 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 attività 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 è composta da un elenco di regole (rules) che identificano pacchetti di rete secono 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 caratteriscttiche. 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 sottorete)
+
+-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 pachetto 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 è previsto per fare un transparent proxy (con proxy server in esecuzione sulla macchina con iptables)
+
+-j RETURN
+ Interrompe l'attraversamento della catena. Se questa è una secondaria, il pacchetto torna ad attraversare la catena madre da punto in cui aveva fatto il salto nella secondaria. Se il RETURN è 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 è 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 attività 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 situazioe precedente.
+
+*Veramnete*, prima di lavorare sul firewall di una macchina remota inpostate 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 attività 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
+
+
+
+
+
NOTE
========
projects / doc / .git / blobdiff