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 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 equivalenti *ip* della vostra rete.
+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 equivalenti *IP* della vostra rete.
Rete
------
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 ;) . Ad oggi il *lab208* e' servito dal server Bender (254 o 248) che ha ripreso le sue vecchie funzioni.
+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 ;) . Ad oggi il *lab208* e' servito dal server Bender (254 o 248) che ha ripreso le sue vecchie funzioni.
interfaces
~~~~~~~~~~~~~~~
broadcast 10.10.208.255
gateway 10.10.208.254
- # Quali interfaccie devono partire automaticamente:
+ # Quali interfacci devono partire automaticamente:
auto lo eth0
-Controllare il nome della propia scheda di rete: a volte *udev* rinomina la prima scheda a ``eth1``, oppure potreste avere piu' di una scheda di rete (anche un'interfaccia *firewire* puo' essere automaticamente abilitata come scheda di rete).
+Controllare il nome della propria scheda di rete: a volte *udev* rinomina la prima scheda a ``eth1``, oppure potreste avere piu' di una scheda di rete (anche un'interfaccia *firewire* puo' essere automaticamente abilitata come scheda di rete).
-Se si usano *schede di rete virtuali* ( eth0:1 , eth0:1 , ...) ricordarsi che queste dipendono dalla scheda fisica a cui sono associate: abbattere con ``ifconfig down eth0`` la scheda principale fara' cadere anche queste. Tornando ad attivare la schda principale con ``ifconfig eth0 up`` la virtuale tornera' attiva: nel caso voleste disabilitarla dovrete quindi sempre abbattere manualmente la scheda virtuale *prima* della scheda reale.
+Se si usano *schede di rete virtuali* ( eth0:1 , eth0:1 , ...) ricordarsi che queste dipendono dalla scheda fisica a cui sono associate: abbattere con ``ifconfig down eth0`` la scheda principale fara' cadere anche queste. Tornando ad attivare la scada principale con ``ifconfig eth0 up`` la virtuale tornera' attiva: nel caso voleste disabilitarla dovrete quindi sempre abbattere manualmente la scheda virtuale *prima* della scheda reale.
I DNS vanno indicati nel file ``/etc/resolv.conf`` , la cui sintassi e' spiegata al punto 4.6 .
Il completamento automatico della shell (che si attiva premendo il tasto tab una o due volte mentre si sta scrivendo un termine) permette di comporre automaticamente i nomi dei comandi e i percorsi dei file, sopratutto la composizione automatica dei percorsi dei file e' di grande importanza.
-Bash_completion permette di integrare il completamento automatico con i nomi dei pacchetti e oggetti dei comandi: ad es. volendo digitare ``apt-get inst[TAB] xtigh[TAB]`` ora verra' completatato automaticamente sia la parola ``install`` che il nome del pacchetto ``xtightvncviewer``.
+Bash_completion permette di integrare il completamento automatico con i nomi dei pacchetti e oggetti dei comandi: ad es. volendo digitare ``apt-get inst[TAB] xtigh[TAB]`` ora verra' completato automaticamente sia la parola ``install`` che il nome del pacchetto ``xtightvncviewer``.
Abilitare /etc/bash_completion nel file ``/etc/bash.bashrc`` oppure includerlo nel proprio ``~/.bashrc`` (che sarebbe il file *nascosto*, quindi con un punto all'inizio del nome del file, di configurazione della shell bash per ogni utente, presente nella propria *home directory*)::
export PS1='\h:\w\$ '
umask 022
- # Decommentare le seguenti righr per abilitare la colorazione dei
+ # De-commentare le seguenti righe per abilitare la colorazione dei
# nomi dei file:
export LS_OPTIONS='--color=auto'
eval "`dircolors`"
VNC
------------
-I Virtual Network Computing (o VNC) sono software di controllo remoto e servono per amministrare il proprio computer a distanza o visuallizare la sessione di lavoro di un altro computer sul proprio a scopo didattico.
+I Virtual Network Computing (o VNC) sono software di controllo remoto e servono per amministrare il proprio computer a distanza o visualizzare la sessione di lavoro di un altro computer sul proprio a scopo didattico.
Scaricare il pacchetto ``xtightvncviewer`` e lo script ``guarda.sh`` in una posizione (collocazione nel *path* degli utenti, es ``echo $PATH`` per visualizzare l'attuale path ) comoda per gli utenti ( in genere ``/bin`` ), rendere eseguibile lo script.
# cdrom:[Debian GNU/Linux 5.0.1 _Lenny_ - Official i386 kde-CD Binary-1 20090$
# Archivio principale debian via http su piffa.net,
- # non funziona al difuori dell'aula dei corsi
- deb http://debian.piffa.net/debian/ lenny main
- # Sono diponibili anche i rami non-free contrib
+ # non funziona al di fuori dell'aula dei corsi
+ deb http://debian.piffa.net/debian/ Lenny main
+ # Sono disponibili anche i rami non-free contrib
# deb http://debian.piffa.net/debian/ lenny non-free contrib
# Mirror da kernel.org da usare a casa:
deb http://volatile.debian.org/debian-volatile Lenny/volatile main
deb-src http://volatile.debian.org/debian-volatile Lenny/volatile main
- # Esempio di accesso a un filesystem locale contenente i pacchetti:
+ # Esempio di accesso a un file system locale contenente i pacchetti:
# deb file:/mnt/mirror Sid main non-free contrib
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. Si partira' dalle configurazioni piu' semplici per la semplice *condivisione della navigazione* internet, per poi poter ocnfigurare 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.
+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. Si partira' dalle configurazioni piu' semplici per la semplice *condivisione della navigazione* internet, per poi poter configurare 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 Squid 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.
+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`` ::
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.
+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* circa ``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.
+Si presti poi attenzione alla natura dei dati che saranno salvati nella cache: sono tutti dati facilmente 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 stirpe* (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):
# 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' consigliabile cancellare (se si ha *ridotto* il numero delle diectory) la vecchia cache e poi generare una nuova struttura. Se si vuole *star nel sicuro* ogni volta che si modifica l'impostazione delle directory *si svuoti la vecchia cache e se ne generi una nuova* ::
+Se si modifica la struttura del filesytem della cache di Squid, ad esempio variando il numero delle directory, puo' essere opportuno rigenerare la struttura della cache di squid (per lo meno se si *aumenta* il numero delle directory di primo o secondo livello). Tipicamente e' consigliabile cancellare (se si ha *ridotto* il numero delle directory) la vecchia cache e poi generare una nuova struttura. Se si vuole *star nel sicuro* ogni volta che si modifica l'impostazione delle directory *si svuoti la vecchia cache e se ne generi una nuova* ::
# /etc/init.d/squid3 stop
# rm -r /var/spool/squid3/??
TAG: maximum_object_size
~~~~~~~~~~~~~~~~~~~~~~~~~~
-Questa direttiva imposta la dimensione massima degli oggetti che vengono slvati sul supporto di storaggio, oggetti di dimensioni superiori saranno comunque scaricati ma non tenuti in cache.
+Questa direttiva imposta la dimensione massima degli oggetti che vengono salvati sul supporto di storaggio, oggetti di dimensioni superiori saranno comunque scaricati ma non tenuti in cache.
TAG: maximum_object_size (1760)::
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
*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).
+Questo dipendera' dalla RAM disponibile sul sistema, e da quanta di questa volete mettere a disposizione di Squid (altri servizi importanti girano sulla stessa macchina?).
+Questo parametro 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.
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.
+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* (indirizzi 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:
+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.
+Si proceda a creare una ``ACL`` di tipo ``src`` per identificare la nostra 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.
::
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.
+Nel file ``.wgetrc`` (si noti il punto iniziale: e' un file nascosto) si puo' impostare il proxy per wget. Si utilizzi 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``.
apache2 apache2-doc
-Con la release 2.0 di Apache viene automaticamente resa disponibile anche la versione SSL (Secure Socket Layer, cpnnessioni criptate ) del web server.
+Con la release 2.0 di Apache viene automaticamente resa disponibile anche la versione SSL (Secure Socket Layer, connessioni criptate ) del web server.
Configurazione di Apache
apache2.conf
File di configurazione principale del servizio.
- httpd.conf e' il vecchio file di configurazione di Apache1, presente per motivi di retrocompatibilita' e' generalemente vuoto.
+ httpd.conf e' il vecchio file di configurazione di Apache1, presente per motivi di retrocompatibilita' e' generalmente vuoto.
ports.conf
In questo file vengono specificate le porte sulle quali resta in ascolto il server web. Si noti che utilizzando dei virtual hosts generalmente viene specificata per questi la porta su cui ascoltare nel file di configurazione del virtual host, ad es: ``<VirtualHost *:80>``
Guardiamo alcune direttive interessanti:
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.
+ 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, magari a causa di una connessione particolarmente lenta o instabili, tenga attivo indefinitamente 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' 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.
+ 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 protocollo http per sua natura e' senza stato (*stateless* ), 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.
+ 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 settagli 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.
AccessFileName
Il nome del file che viene onorato per modificare le impostazioni per una singola directory, legato alla direttiva AllowOverride .
Test del modulo php
~~~~~~~~~~~~~~~~~~~~
-Creare nella cartella ``/var/www`` (o altra cartella visibile) un file con estensione \*.php (es ``/var/ww/info.php`` contenete codice php eseguibile dall'interprete, ad es::
+Creare nella cartella ``/var/www`` (o altra cartella visibile) un file con estensione \*.php (es ``/var/www/info.php`` contenete codice php eseguibile dall'interprete, ad es::
<?php phpinfo() ; ?>
-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.
+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 client HTTP, a prova del corretto funzionamento del modulo di PHP e della sua integrazione con il server 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 fatto ripartire Apache.
Installazione del supporto per Mysql
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
phpmyadmin
~~~~~~~~~~~~~~~~~~~~~
-L'interfaccia web Phpmyadmin non richede necessariamente la presenza di un database Mysql locale, puo' infatti essere utilizzata per gestire databases remoti (il suo file di configurazione: ``/etc/phpmyadmin/config.inc.php`` ). Nel caso si voglia installare localmente Mysql si utilizzi il pacchetto ``mysql-server`` .
+L'interfaccia web Phpmyadmin non richiede necessariamente la presenza di un database Mysql locale, puo' infatti essere utilizzata per gestire database remoti (il suo file di configurazione: ``/etc/phpmyadmin/config.inc.php`` ). Nel caso si voglia installare localmente Mysql si utilizzi il pacchetto ``mysql-server`` .
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/`` .
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`` .
+L'interfaccia web Phppgadmin per il database server PostgreSQL non richiede necessariamente la presenza di un database locale, puo' infatti essere utilizzata per gestire database 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/`` .
* http://www.onlamp.com/pub/a/apache/2004/01/08/apacheckbk.html
-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:
+I virtual host permettono di avere piu' siti internet disponibili tramite lo stesso server web, eventualmente mappati su un solo indirizzo IP. Sono generalmente di due tipi:
- * 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 *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* 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.
Gestione DNS
~~~~~~~~~~~~~~~
-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:
+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* (DNS server)
- Impostare i campi A nelle proprie zone gestite dal server dns Bind. Ad es: ``papo A 212.22.136.248``
+ 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*.
- 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.
+ 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 indirizzo IP pubblico (anche se dinamico) per la propria connessione ad internet.
*Dnsmasq* (DNS server)
Utilizzabile al livello della rete locale per fare dei test, utilizzando direttive come: ``address=/davide.piffa.net/10.10.208.178``
``/etc/hosts``
- Per prove sul propio sistema potete impostare i nomi dei vostri virtual server nel file /etc/hosts .
+ Per prove sul proprio sistema potete impostare i nomi dei vostri virtual server nel file /etc/hosts .
Query DNS con ``dig``::
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.
+1. ``<VirtualHost \*:80 >`` La prima riga indica l'inizio della stanza relativa al nostro virtual host, che ascoltera' 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 eventualmente 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:
+Quelle che abbiamo appena visto sono le direttive essenziali per definire un sito virtuale, potrebbe essere utile aggiungere altre:
* ``ErrorLog /var/log/apache2/177.piffa.net/error.log``
Log degli errori separato dai restanti siti web ospitati dal server.
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 poter limitare questi 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.
+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 poter limitare questi accessi, ad esempio per escludere un *bot* indesiderato che scansiona ininterrottamente 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::
+La forma piu' semplice di restrizione degli accessi e' su base degli indirizzi IP dei client: tipicamente i siti web sono settati per dare accesso a chiunque::
<VirtualHost *:80 >
# ...
</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 ci sono comunque soluzioni piu' eleganti.
+Si tenga pero' conto che e' relativamente facile per un malintenzionato cambiare il proprio indirizzo IP, oppure collegarsi da un altra zona. Meno facile e' accedere ad una classe privata trovandosi all'esterno di questa, ma ci sono comunque soluzioni piu' eleganti.
User Authentication
Si puo' negoziare gli accessi ad un area del sito tramite autenticazione basata su *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.
-Tramite il modulo di Apache *mod-auth* e' possibile implementare questo paradigma, per quanto esistano soluzioni piu' granulari e sofisticate, che richiedono pero' l'implementazione di interpreti di linuguaggi di programmazione, criptazione delle passwords, gestione degli utenti ed eventualmente delle sessioni.
+Tramite il modulo di Apache *mod-auth* e' possibile implementare questo paradigma, per quanto esistano soluzioni piu' granulari e sofisticate, che richiedono pero' l'implementazione di interpreti di linguaggi di programmazione, criptazione delle passwords, gestione degli utenti ed eventualmente delle sessioni.
Mod auth non richiede l'installazione di niente di tutto questo.
Definire la cartella
~~~~~~~~~~~~~~~~~~~~~~
-Decidere quale sara' il *path* della cartella da sottoporre ad autentizazione:
+Decidere quale sara' il *path* della cartella da sottoporre ad autenticazione:
``mkdir /var/www/177.piffa.net/privata``
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``.
+``htpasswd`` ci chiedera' la password da associare all'utente ``luca``. Per successive modifiche della password o aggiunta di nuovi utenti non sara' necessario usare il flag ``-c``.
Configurazione di Apache
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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 continuamente sui vari virtual host.
+Dando agli utenti la possibilita' di modificare (*AllowOverride*) autonomamente alcuni parametri (in questo caso solo l'*AuthConfig*) relativi al funzionamento del loro spazio web ci togliera' l'incombenza di dover intervenire continuamente sui vari virtual host.
Abilitiamo l'AllowOverride nel file di configurazione del virtual host per la sola directory ``privata``::
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.
+Ora sara' possibile, anche per l'utente di sistema, creare un file ``.htaccess`` che sara' onorato da Apache.
/var/www/177.piffa.net/privata/.htaccess ::
Oltre a ``valid-users`` si potrebbe scegliere di usare la formula ``users`` che permette di elencare esplicitamente gli utenti::
require user pippo pluto
-L'utente *paperino* che fosse comunque presente nel file generatoda htpasswd non potrebbe accedere alla risorsa.
+L'utente *paperino* che fosse comunque presente nel file generato da htpasswd non potrebbe accedere alla risorsa.
-Nel caso ci foosero molti utenti conviene gestirli tramite *gruppi*::
+Nel caso ci fossero molti utenti conviene gestirli tramite *gruppi*::
require group staff studenti
I gruppi vengono definiti in un file in modo simile a ``/etc/groups`` per gli utenti di sistema::
Domain Name System
====================
-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 sistema **gerarchico** (quindi una struttura ad albero, simile ai *file sytems*) **distribuito** (ogni server DNS facente parte del sistema puo' tenre solo una parte delle informazioni, ad esempio per la sua sola *zona*), 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 sistema **gerarchico** (quindi una struttura ad albero, simile ai *file system*) **distribuito** (ogni server DNS facente parte del sistema puo' mantenere solo una parte delle informazioni, ad esempio per la sua sola *zona*), costituito dai server DNS.
-I DNS sono un servizio *core* (fondamentale) per la rete internet come per qualunque rete locale. Ad esempio durante la navigazione web un client vorrebbe vedere l'*URL* ``http://ww.piffa.net/``, quindi per potersi connettere via *http* al server web deve prima ottenere l'indirizzo ip del *server http* corrispondente a *www.piffa.net*.
+I DNS sono un servizio *core* (fondamentale) per la rete internet come per qualunque rete locale. Ad esempio durante la navigazione web un client vorrebbe vedere l'*URL* ``http://ww.piffa.net/``, quindi per potersi connettere via *http* al server web deve prima ottenere l'indirizzo IP del *server http* corrispondente a *www.piffa.net*.
Se il DNS gli fornisce un IP sbagliato l'utente non potra' raggiungere il servizio: di fatto e' come se il serve http fosse spento.
Stessa cosa vale per gli altri servizi, come la posta elettronica, ssh, ecc. : *prima si deve effettuare una query DNS*.
Per la risoluzione inversa sono invece i provider di connettivita' a gestire i DNS: se volete impostare il *PTR* associato al vostro indirizzo IP dovete contattare il vostro provider (tipo *telecom* per una connessione ADSL) e *non il Registar del vostro dominio*.
-Ad esempio all'IP ``212.22.136.248`` era associato un PTR ``bender.piffa.net``, corrispondente al record ``212`` facente parte della zona ``136.22.212.in-addr.arpa`` gestito dal provider Tiscali/Nextra propietario della classe C ``212.22.136``. Se avete un solo IP conviene lasciare al fornitore la gestire il PTR, ma se avete a diposizione un'itera classe potete chiedere sempre al fornitore che vi *deleghi* la gestione della zona tramite i vostri DNS.
+Ad esempio all'IP ``212.22.136.248`` era associato un PTR ``bender.piffa.net``, corrispondente al record ``212`` facente parte della zona ``136.22.212.in-addr.arpa`` gestito dal provider Tiscali/Nextra proprietario della classe C ``212.22.136``. Se avete un solo IP conviene lasciare al fornitore la gestire il PTR, ma se avete a disposizione un'itera classe potete chiedere sempre al fornitore che vi *deleghi* la gestione della zona tramite i vostri DNS.
-Alcuni servizi, ad esempio la spedizione della posta elettronica, non funzionano se non viene impostata correttamente *anche* l'associzione inversa tra indirizzo IP e PTR (che corrisponderebbe in questo caso al nome con cui si presenta il server SMTP).
+Alcuni servizi, ad esempio la spedizione della posta elettronica, non funzionano se non viene impostata correttamente *anche* l'associazione inversa tra indirizzo IP e PTR (che corrisponderebbe in questo caso al nome con cui si presenta il server SMTP).
Nomi di dominio
-----------------
L'utente finale potra' chiedere l'assegnazione (pagando un contributo al Register preferito per il mantenimento delle spese dell'infrastruttura) di un dominio di *secondo* livello (es ``piffa``) di una delle varie TLD disponibili (noi italiani diciamo *tildi*), sempre che non sia gia' stato assegnato a qualcun altro.
-Ottenuto il secondo livello sara' l'utente a gestirlo: potra' instanziare domini di terzo livello (es ``bender``) e anche oltre (es www.andrea.bender.piffa.net). Tali records saranno mantenuti dall'utente, sotto la sua responsbilita': se il propio server DNS non fosse raggiungibile o risultasse malconfigurato gli utenti non potrebbero risolvere / raggiungere i siti di loro interesse.
+Ottenuto il secondo livello sara' l'utente a gestirlo: potra' in stanziare domini di terzo livello (es ``bender``) e anche oltre (es www.andrea.bender.piffa.net). Tali records saranno mantenuti dall'utente, sotto la sua responsbilita': se il proprio server DNS non fosse raggiungibile o risultasse mal configurato gli utenti non potrebbero risolvere / raggiungere i siti di loro interesse.
-Tipicamente si ha almeno un server DNS secondario per garantire la sussitenza del servizio in caso di guasto del DNS principale. I secondari *replicano* i dati presenti nei DNS principali.
+Tipicamente si ha almeno un server DNS secondario per garantire la sussistenza del servizio in caso di guasto del DNS principale. I secondari *replicano* i dati presenti nei DNS principali.
Tipologie di record
-----------------------
Utilizzo
------------
-I computer vengono identificati in rete grazie agli indirizzi *IP*, questi pero' non sono comodi per gli utenti come riferimento per i vari server. Ad esempio sarebbe scomodoriferirsi al motore di ricerca Goggle con uno dei suoi IP: ``74.125.43.104``, e' preferibile usare il nome di dominio *www.google.com*::
+I computer vengono identificati in rete grazie agli indirizzi *IP*, questi pero' non sono comodi per gli utenti come riferimento per i vari server. Ad esempio sarebbe scomodo riferirsi al motore di ricerca Goggle con uno dei suoi IP: ``74.125.43.104``, e' preferibile usare il nome di dominio *www.google.com*::
ping -c 1 www.google.com
PING www.l.google.com (74.125.43.104) 56(84) bytes of data.
Dig
-----
-Vediamo alcune opzioni utili nell'utilizzo di ``dig`` per l'inerrogazione dei DNS Server::
+Vediamo alcune opzioni utili nell'utilizzo di ``dig`` per l'interrogazione dei DNS Server::
$ dig www.google.it
;; MSG SIZE rcvd: 255
$ dig
- (semza opzioni o oggetti) Fornisce l'elenco dei *root servers* utilizzati. I root server sono i server che mantengono le informazioni sui domini di primo livello (TLD) e sono quindi il punto di partenza per scorrere nella directory dei DNS per recuperare le informazioni (tipicamente un campo ``A`` per un indirizzo IP) che ci servono per raggiungere un certo servizio.
+ (senza opzioni o oggetti) Fornisce l'elenco dei *root server* utilizzati. I root server sono i server che mantengono le informazioni sui domini di primo livello (TLD) e sono quindi il punto di partenza per scorrere nella directory dei DNS per recuperare le informazioni (tipicamente un campo ``A`` per un indirizzo IP) che ci servono per raggiungere un certo servizio.
$ dig
Chiede tutti i campi, non solo i campi *a*
dig -x 74.125.43.104
- Effettua una richiesta inversa: dall'ip al PTR associato.
+ Effettua una richiesta inversa: dall'IP al PTR associato.
resolv.conf
-----------------
/etc/resolv.conf:
- - ``nameserver``: indica il nameserver da utilizzare, indicato con l'indirizzo ip.
+ - ``nameserver``: indica il nameserver da utilizzare, indicato con l'indirizzo IP.
- - ``domain``: indica il nome di dominio della rete attuale, vedi voce sucessiva.
+ - ``domain``: indica il nome di dominio della rete attuale, vedi voce successiva.
- - ``search``: nome di dominio usato dalla rete sul quale cercare gli hosts. Ad esempio se impostato su ``piffa.net`` pingando l'host ``bender`` viene automaticamente fatto un tentativo di ricerca per ``bender.piffa.net``.
+ - ``search``: nome di dominio usato dalla rete sul quale cercare gli hosts. Ad esempio se impostato su ``piffa.net`` pingando l' host ``bender`` viene automaticamente fatto un tentativo di ricerca per ``bender.piffa.net``.
Si veda anche la pagina man di resolv.conf.
-Attenzione: se si usa un client DHCP o simile questo file potra' essere riscritto automaticamente in base a quanto ottenuto dal DHCP. Si veda la documentazione del pacchtto ``resolvconf``.
+Attenzione: se si usa un client DHCP o simile questo file potra' essere riscritto automaticamente in base a quanto ottenuto dal DHCP. Si veda la documentazione del pacchetto ``resolvconf``.
/etc/hosts
Il contenuto e' un associazione tra un *IP* e stringhe di testo (anche piu' di una es: ``mirror`` e ``mirror.piffa.net``), un record per riga.
-Il problema e' la gestione di questo file: quando gli host cambiano IP si devono aggiornare i records, e c'e' poi il problema di distribuire questo file tra i vari hosts della propia LAN. Un metodo semplice per distribuire questo file e' utilizzare ``Dnsmasq``: questo infatti legge e onora il file ``hosts`` locale e lo *distribuisce* ai clients.
+Il problema e' la gestione di questo file: quando gli host cambiano IP si devono aggiornare i records, e c'e' poi il problema di distribuire questo file tra i vari hosts della propria LAN. Un metodo semplice per distribuire questo file e' utilizzare ``Dnsmasq``: questo infatti legge e onora il file ``hosts`` locale e lo *distribuisce* ai clients.
-Modificare (riconducendola a un ip interno, cosi' annullandola) la risoluzione di un nome di dominio e' un modo drastico e funzionale per *annullarlo* rendendolo indisponibile alla propia rete locale, ad esempio aggiungere al file ``/etc/hosts``::
+Modificare (riconducendola a un IP interno, cosi' annullandola) la risoluzione di un nome di dominio e' un modo drastico e funzionale per *annullarlo* rendendolo indisponibile alla propria rete locale, ad esempio aggiungere al file ``/etc/hosts``::
127.0.0.1 www.facebook.com
Hostname
------------
-Ogni computer ha un *propio nome* visualizzabile (e modificabile) con il comando ``hostname``.
+Ogni computer ha un *proprio nome* visualizzabile (e modificabile) con il comando ``hostname``.
Per modificare in modo permanente il nome del computer si modifichi il contenuto del file ``/etc/hostname``.
-Tipicamente si vuole mantenere una correlazione tra il nome dell'host, o meglio la stringa con cui il server si qualifica all'esterno, e il *PTR* dell'ip. Nel caso di *servizi virtuali* ci sara' un *nome server* principale associato al *PTR* condiviso.
-Non e' automatico che un servizio, ad esempio un server di posta, si qualifichi leggendo il contenuto di questo file e magari aggiungendo come suffisso il dominio di cui fa parte l'host: a volte questo parametro puo' essere specificato nel file di configurazione del servizio::
+Tipicamente si vuole mantenere una correlazione tra il nome dell' host, o meglio la stringa con cui il server si qualifica all'esterno, e il *PTR* dell'IP. Nel caso di *servizi virtuali* ci sara' un *nome server* principale associato al *PTR* condiviso.
+Non e' automatico che un servizio, ad esempio un server di posta, si qualifichi leggendo il contenuto di questo file e magari aggiungendo come suffisso il dominio di cui fa parte l' host: a volte questo parametro puo' essere specificato nel file di configurazione del servizio::
* Squid: ``visible_hostname``
Dnsmasq puo' svolgere le funzioni di un DNS cache / forwarder e un server DHCP caratterizzato dalla facilita' di configurazione, dalla leggerezza e dalla possibilita' di modificare rapidamente i record DNS serviti alla rete. Puo' essere anche utilizzato come `server per il boot da rete <http://www.debian-administration.org/articles/478>_` .
-Dnsmasq e' un interessante alternativa all'uso del server DNS Bind in modalita' cache-only (non autoritativo) accompagnato dal server DHCPD. I vantaggi sono:
+Dnsmasq e' un interessante alternativa all'uso del server DNS Bind in modalita' cache-only (non autoritativo) accompagnato dal server DHCPd. I vantaggi sono:
- Leggerezza: puo' essere fatto girare su una macchina relativamente debole in caso di bisogno.
-- Rapidita' di configurazione (in particolare per servire dei record A / MX alla rete, modificando al volo i valori originali ospitati sul server DNS Publico).
-- Ben integrato con connssioni PPP (utile se dovete rendere disponibile rapidamente una connessione a internet a una rete in difficolta').
+- Rapidita' di configurazione (in particolare per servire dei record A / MX alla rete, modificando al volo i valori originali ospitati sul server DNS pubblico).
+- Ben integrato con connessioni PPP (utile se dovete rendere disponibile rapidamente una connessione a internet a una rete in difficolta').
Tutto cio' rende Dnsmasq una soluzione valida in particolare quando si deve intervenire in una rete pre-esistente in cui il server principale e' in crisi: si potra' utilizzare Dnsmasq anche su una macchina piu' debole e *mascherare* i servizi al momento non disponibili.
Molto utile per scopi didattici, sopratutto per testare server SMTP impostando al volo i campi MX per nomi di dominio fittizi.
DHCP
-----------
-Per attivare il demone DHCP di dnsmaq basta aggiungere al file di configurazione il *range* degli ip che si vuole assegnare ai client con il *lease time* (tempo di rilascio: quanto a lungo saranno validi gli ip assegnati) espresso in ore.
+Per attivare il demone DHCP di Dnsmasq basta aggiungere al file di configurazione il *range* degli IP che si vuole assegnare ai client con il *lease time* (tempo di rilascio: quanto a lungo saranno validi gli IP assegnati) espresso in ore.
-Si faccia *attenzione*: in una rete puo' esseere presente **un solo server DHCP**, o per meglio dire qualunque server DHCP ascolta sul broadcast ``255.255.255.255`` e potrebbe rispondere a un pacchetto di richesta DHCP. Quindi non fate partire inavvertitamente un server DHCP in una rete gia' servita e **non vi azzardate ad andare in giro con un portatile con un server DHCP attivo** nelle reti altrui. Questo vale anche per i laboratori di informatica dei corsi di reti: non fate partire il vostro server DHCP se siete collegati alla rete interna!
+Si faccia *attenzione*: in una rete puo' essere presente **un solo server DHCP**, o per meglio dire qualunque server DHCP ascolta sul broadcast ``255.255.255.255`` e potrebbe rispondere a un pacchetto di richiesta DHCP. Quindi non fate partire inavvertitamente un server DHCP in una rete gia' servita e **non vi azzardate ad andare in giro con un portatile con un server DHCP attivo** nelle reti altrui. Questo vale anche per i laboratori di informatica dei corsi di reti: non fate partire il vostro server DHCP se siete collegati alla rete interna!
/etc/dnsmasq.conf (riga 118)::
DNS cache
-----------
-Aggiungere al file ``/etc/resolv.conif`` il nameserver localhost in cima alla lista dei *nameserver* disponibili. Dnsmasq usera' la propia cache e in caso non abbia disponibile il *record DNS* richiesto fara' partire una query al primo DNS::
+Aggiungere al file ``/etc/resolv.conf`` il nameserver localhost in cima alla lista dei *nameserver* disponibili. Dnsmasq usera' la propria cache e in caso non abbia disponibile il *record DNS* richiesto fara' partire una query al primo DNS::
nameserver 127.0.0.1
DNS cache
-------------
-Bind appena installato funzionera' come DNS cache: si faccia un test con un ``dig @localhost`` . Bind a diffrenza di Dnsmasq e' autonomo: non ha bisogno di forwardare (inoltrare) le query a un DNS esterno: queste verranno risolte direttamente da Bind partendo dai *DNS root servers*.
+Bind appena installato funzionera' come DNS cache: si faccia un test con un ``dig @localhost`` . Bind a differenza di Dnsmasq e' autonomo: non ha bisogno di forwardare (inoltrare) le query a un DNS esterno: queste verranno risolte direttamente da Bind partendo dai *DNS root servers*.
-E' comunque possibile impostare dei DNS forwarders, tipicamente i DNS server forniti dal propio provider, per velocizzare le query:
+E' comunque possibile impostare dei DNS forwarders, tipicamente i DNS server forniti dal proprio provider, per velocizzare le query:
/etc/bind/named.conf.options (riga 13)::
10.10.208.254;
};
-Nel caso si voglia usare Bind solo come server DNS cache per la propia LAN senza ospitare delle zone DNS pubbliche sara' il caso di limitare gli accessi al server alla sola LAN:
+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 propio server ha ip 10.10.208.254
+ // Se il proprio server ha IP 10.10.208.254
// sulla rete LAN privata:
listen-on { 10.10.208.254; }
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.
+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
--------------
Server di posta: Postfix
============================
-Il server di posta che prenderemo in considerazione e' Postfix, a seguire un estratto di un file do configurazione *semplie* con l'abilizazione delle *Maildir* nelle ``/home`` degli utenti per la consegna della posta:
+Il server di posta che prenderemo in considerazione e' Postfix, a seguire un estratto di un file do configurazione *semplice* con l'abilitazione delle *Maildir* nelle ``/home`` degli utenti per la consegna della posta:
``/etc/postfix/main.cf``::
Imap e pop
------------------
-Postfix e' un server SMTP, di conseguenza se volete che i vostri utenti possano *scaricare* in locale la posta generalemtne volete mettere a loro disposizione un server *POP3* o ancora meglio *IMAP*. Oppure entrambi.
+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 ancora meglio *IMAP*. Oppure entrambi.
Pacchetti da installare
courier-imap courier-pop
Web client
~~~~~~~~~~~~~~~
-Per mettere a disposizione degli utenti un client web per gestire la propia posta si installi il pacchetto: ``squirrelmail`` . Ci sono tanti altri client web disponibili: questo e' particolarmente semplice. Naturalemte dovrete aver installato: ``php5 apache2`` .
+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::
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.
+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 è 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.
+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 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:
+La funzionalita'à 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.
+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
------
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.
+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
-----------------------------
Hardware
~~~~~~~~~~~~
-Sostanzialmente potremmo distinquere due tipologie di hardware:
+Sostanzialmente potremmo distinguere due tipologie di hardware:
Network appliance dedicata::
Un dispositivo hardware dedicato alla funzione di Firewall, ad es un Cisco / Fortigate.
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.
+Vantaggi e svantaggi: consumo elettrico, efficienza, flessibilita', strumenti di gestione, sicurezza, OpenBSD.
Percorso dei pacchetti tra tabelle e catene
-------------------------------------------
* filter - Regola il firewalling: quali pacchetti accettare, quali bloccare
-* nat - Regola le attività di natting
+* 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 è 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 catena è 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 caratteriscttiche. I match di possono servire a controllare se un pacchetto e' destinato a una porta particolare o utilizza un protocollo particolare.
+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:
Protocollo IP. Secondo IP number o nome (es: tcp, udp, gre, ah...)
-s [!] address[/mask]
- Indirizzo IP sorgente (o network con maschera di sottorete)
+ Indirizzo IP sorgente (o network con maschera di sotto rete)
-d [!] address[/mask]
Indirizzo IP destinazione (o network)
Target principali:
*-j ACCEPT*
- Il pachetto matchato viene accettato e procede verso la sua destinazione. Si usa per definire il traffico permesso.
+ 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.
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.
+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.
-*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)::
+*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
Gestione regole (rules)
--------------------------
-Il comando iptables viene usato per ogni attività di gestione e configurazione.
+Il comando iptables viene usato per ogni attivita'à di gestione e configurazione.
Inserimento regole:
Salvataggio regole
----------------------
-Il comando ``iptables`` serve per interagire con il framework ``Netfilter`` ch gestisce il firewall di Linux al livello del kernel. Questo comporta, in modo analogo a quando avvene col comando ``ifconfig``, che i cambiameti impostati siano in *tempo reale, RAM*, non persistenti nel sistema: al boot sucessivo del sistema tutto tornera' alle impostazioni di base (in questo caso *nulle*, con policy di default settate su ``ACCEPT`` per tutto).
+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.
iface eth1 inet static
up /sbin/iptables-restore /root/firewall/basic_fw
- # Seguno i soliti parametri della scheda di rete
+ # Seguono i soliti parametri della scheda di rete
address 10.10.208.21
Iptables-restore
~~~~~~~~~~~~~~~~~~~~
-Per ripristinare un set di regole prcedentemente salvate con ``iptables-save`` si utilizzi ``iptables-restore``. Se questo deve essere fatto in modalita' *non interattiva*, ad esempio deve essere eseguito dal demone che si occupa di inizializzare le schede di rete, oppure un *cron* o altro, e' buona norma richiamare i percorsi completi sia dei comandi che dei file::
+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
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 propio_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.
+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.
Brute force
projects / doc / .git / commitdiff