1 ===============================
2 Servizi di rete passo a passo
3 ===============================
4 ----------------------------------------------------------
5 Appunti sulla installazione e configurazione dei servizi
6 ----------------------------------------------------------
12 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 .
16 .. contents:: Indice degli argomenti
18 Generato con: http://docutils.sourceforge.net/rst.html
20 Configurazione sistema
21 =========================
23 ---------------------------
25 Impostazioni di base per la configurazione del sistema operativo e della rete nel laboratorio 208 facente parte della rete piffa.net .
27 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.
32 Parametri della rete attualmente in uso:
34 ============= ================
36 ------------------------------
39 broadcast 10.10.208.255
42 proxy http 10.10.208.254:3128
43 ============= ================
45 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.
50 Segue un esempio del file di configurazione della scheda di rete con configurazione statica:
52 /etc/network/interfaces::
54 # /etc/network/interfaces -- configuration file for ifup(8), ifdown(8)
56 # The loopback interface
57 iface lo inet loopback
59 # La prima scheda di rete (se si chiama eth0)
60 # (network, broadcast and gateway sono optional)
61 iface etho inet static
63 # iface etho inet dhcp
67 broadcast 10.10.208.255
70 # Quali interfacci devono partire automaticamente:
73 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).
75 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.
77 I DNS vanno indicati nel file ``/etc/resolv.conf`` , la cui sintassi e' spiegata al punto 4.6 .
82 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.
84 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``.
86 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*)::
88 echo ". /etc/bash_completion" >> ~/.bashrc
90 Esempio di ~/.bahsrc ::
92 # ~/.bashrc: executed by bash(1) for non-login shells.
97 # De-commentare le seguenti righe per abilitare la colorazione dei
99 export LS_OPTIONS='--color=auto'
101 alias ls='ls $LS_OPTIONS'
102 alias ll='ls $LS_OPTIONS -l'
103 alias l='ls $LS_OPTIONS -lA'
105 # Some more alias to avoid making mistakes:
110 # questo abilita bash completion
111 . /etc/bash_completion
113 Il file ``/etc/bash_completion`` deve essere presente nel sistema, in caso contrario installare il pacchetto: ``bash-completion``. Generalmente l'utente ``root`` ha un file ``.bashrc`` preimpostato analogo a quello citato sopra, a differenza dei normali utenti di sistema.
117 * `An introduction to bash completion <http://www.debian-administration.org/articles/316>`_
118 * `Working more productively with bash 2.x/3.x <http://www.caliban.org/bash/>`_
123 Vim e' l'editor di testo preferito dai sistemisti, quindi sara' conveniente impostare fin da subito alcune impostazioni per renderlo piu' comodo.
125 Assicurarsi che sia installata nel sistema la versione completa dell'editor installando il pacchetto ``vim``::
127 # apt-get install vim
130 Modificare poi il file di configurazione generale ``/etc/vim/vimrc`` ::
132 " All system-wide defaults are set in $VIMRUNTIME/debian.vim (usually just
133 " /usr/share/vim/vimcurrent/debian.vim) and sourced by the call to :runtime
134 " you can find below. If you wish to change any of those settings, you should
135 " do it in this file (/etc/vim/vimrc), since debian.vim will be overwritten
136 " everytime an upgrade of the vim packages is performed. It is recommended to
137 " make changes after sourcing debian.vim since it alters the value of the
138 " 'compatible' option.
140 " This line should not be removed as it ensures that various options are
141 " properly set to work with the Vim-related packages available in Debian.
144 " Uncomment the next line to make Vim more Vi-compatible
145 " NOTE: debian.vim sets 'nocompatible'. Setting 'compatible' changes numerous
146 " options, so any other options should be set AFTER setting 'compatible'.
149 " Vim5 and later versions support syntax highlighting. Uncommenting the next
150 " line enables syntax highlighting by default.
153 " If using a dark background within the editing area and syntax highlighting
154 " turn on this option as well
157 " Uncomment the following to have Vim jump to the last position when
161 au BufReadPost * if line("'\"") > 0 && line("'\"") <= line("$")
162 \| exe "normal! g'\"" | endif
165 " Uncomment the following to have Vim load indentation rules and plugins
166 " according to the detected filetype.
168 filetype plugin indent on
171 " The following are commented out as they cause vim to behave a lot
172 " differently from regular Vi. They are highly recommended though.
173 set showcmd " Show (partial) command in status line.
174 "set showmatch " Show matching brackets.
175 set ignorecase " Do case insensitive matching
176 "set smartcase " Do smart case matching
177 "set incsearch " Incremental search
178 set autowrite " Automatically save before commands like :next and :make
179 "set hidden " Hide buffers when they are abandoned
180 "set mouse=a " Enable mouse usage (all modes) in terminals
182 " Source a global configuration file if available
183 " XXX Deprecated, please move your changes here in /etc/vim/vimrc
184 if filereadable("/etc/vim/vimrc.local")
185 source /etc/vim/vimrc.local
189 I principianti faranno bene ad esercitarsi con ``vimtutor it``.
194 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.
196 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.
202 wget http://debian.piffa.net/guarda.sh
206 Si noti che non e' possibile lanciare un applicativo sul server grafico di un utente da una shell in cui si sta lavorando come altro utente, anche se root. E' quindi necessario essere l'utente di sistema che si e' loggato inizialmente nella sessione grafica per poter lanciare lo script guarda.sh da una shell.
208 Controllare con ``whoami`` di essere l'utente normale (es ``utente | studente | proprio nome`` ), in caso si sia assunta una altra ``id`` si apra un altra shell o si esca da quella attuale con ``exit`` .
210 Lista dei pacchetti di base
211 -----------------------------
213 I pacchetti installati generalmente [#]_ per poter seguire le lezioni sono::
215 kde-core kdm kde-i18n-it xorg vim less xtightvncviewer
217 .. [#] ``kde-core`` e' piu' leggero del pacchetto ``kde``. Esiste un equivalente ``gnome-core gnome`` per chi preferisce gnome, nel caso si potrebbe installare il log-in manager ``gdm`` al posto di ``kdm``.
220 ---------------------
222 Vediamo i due file principali di apt:
224 * ``/etc/apt/sources.list``
226 * ``/etc/apt/apt.conf``
231 Questo file contiene i sorgenti da cui *apt* preleva i pacchetti da installare tramite *dpkg*, vengono quindi precisati i metodi (ad es. http / ftp / cdrom / file), la release che si vuole tracciare (es ``stable, testing, unstable`` oppure i corrispondenti release name es: ``Lenny, Squeeze, Sid``), i rami di interesse (es: ``main`` che e' l'archivio principale, ``non-free`` per il software non libero, ``contrib`` per i pacchetti non realizzati dai manutentori ufficiali).
233 Gli archivi sono generalmente:
235 * ``deb`` per pacchetti Debian binari
237 * ``deb-src`` per i pacchetti sorgenti (quindi da compilare, come il kernel) degli stessi pacchetti binari. In genere se non compilate spesso potete evitare di tracciare i sorgenti per risparmiare tempo e banda.
240 ``/etc/apt/sources.list`` ::
242 # esempio di accesso a un CDROM:
243 # cdrom:[Debian GNU/Linux 5.0.1 _Lenny_ - Official i386 kde-CD Binary-1 20090$
245 # Archivio principale debian via http su piffa.net,
246 # non funziona al di fuori dell'aula dei corsi
247 deb http://debian.piffa.net/debian/ Lenny main
248 # Sono disponibili anche i rami non-free contrib
249 # deb http://debian.piffa.net/debian/ lenny non-free contrib
251 # Mirror da kernel.org da usare a casa:
252 deb http://mirrors.eu.kernel.org/debian/ lenny main
254 # Security dal sito principale
255 deb http://security.debian.org/ lenny/updates main
256 deb-src http://security.debian.org/ lenny/updates main
258 # Debian volatile per le cose soggette a cambiamenti non legati
259 # a dinamiche di sicurezza
260 deb http://volatile.debian.org/debian-volatile Lenny/volatile main
261 deb-src http://volatile.debian.org/debian-volatile Lenny/volatile main
263 # Esempio di accesso a un file system locale contenente i pacchetti:
264 # deb file:/mnt/mirror Sid main non-free contrib
270 Questo file contiene le opzioni di apt, come ad esempio il proxy::
272 Acquire::http::Proxy "http://10.10.208.254:3128";
274 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 commentando la riga con ";" (''punto-e-virgola'')::
282 Squid e' un proxy cache http (ma anche FTP e https) robusto e strutturato, puo' essere usato sia in reti relativamente semplici 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 bilanciamento del carico tra piu' server proxy.
284 Inoltre Squid svolge la funzione di *anonymizer*:
285 nasconde i client http alla rete internet: e' solo il server proxy a risultare nei log dei server web frequentati dagli utenti di Squid. Glu utenti non sono percepiti ed esposti all'esterno.
287 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 dover introdurre nella rete un *NAT* (si veda la sezione sui firewall) per condividere la connessione, basta il solo Squid. Per altro non servira' neanche un servizio DNS utilizzabile dai clients dato che *sara' il solo Squid a risolvere i nomi di dominio* per i suoi client http.
289 Squid ascolta di default sulla porta 3128, per impostare *apt* per utilizzarlo si aggiunga ad ``/etc/apt/apt.conf`` ::
291 Acquire::http::Proxy "10.10.208.254:3128";
294 Per installare Squid si usino i pacchetti::
299 Configurazione: squid.conf
300 -------------------------------
302 Segue un estratto delle direttive principali viste in aula presenti nel file di configurazione ``/etc/squid3/squid.conf`` .
307 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.
309 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.
311 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.
313 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):
318 # Filesystem per Squid http cache
319 /dev/md3/ /var/spool/squid/ ext3,noexec,nosuid,noatime 0 3
321 Ora possiamo impostare la cache direttamente nel file ``/etc/squid3/squid.conf``::
323 #TAG: cache_dir (riga 1628)
326 # cache_dir Type Directory-Name Fs-specific-data [options]
328 # You can specify multiple cache_dir lines to spread the
329 # cache among different disk partitions.
332 # cache_dir ufs /var/spool/squid3 100 16 256
333 cache_dir aufs /var/spool/squid3 300 24 256
337 # directory primo livello
338 # secondo livello di directory
340 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* ::
342 # /etc/init.d/squid3 stop
343 # rm -r /var/spool/squid3/??
345 # /etc/init.d/squid3 start
347 TAG: maximum_object_size
348 ~~~~~~~~~~~~~~~~~~~~~~~~~~
350 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.
352 TAG: maximum_object_size (1760)::
354 # TAG: maximum_object_size (1760)
355 # Objects larger than this size will NOT be saved on disk. The
356 # value is specified in kilobytes, and the default is 4MB. If
357 # you wish to get a high BYTES hit ratio, you should probably
358 # increase this (one 32 MB object hit counts for 3200 10KB
359 # hits). If you wish to increase speed more than your want to
360 # save bandwidth you should leave this low.
362 # NOTE: if using the LFUDA replacement policy you should increase
363 # this value to maximize the byte hit rate improvement of LFUDA!
364 # See replacement_policy below for a discussion of this policy.
367 # maximum_object_size 4096 KB
368 maximum_object_size 150 MB
371 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
373 *Cache_mem* imposta quanta memoria RAM venga utilizzata per la cache di Squid.
374 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?).
375 Questo parametro influisce sulle prestazioni e sul degrado dei supporti di storaggio (sopratutto se magnetici).
377 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.
379 Se invece si disponesse di una macchina dedicata a Squid con gigabytes di RAM non si esiti a dedicarne buona parte a *cache_mem*.
381 TAG: cache_mem (1566)::
383 # 'cache_mem' specifies the ideal amount of memory to be used
385 # * In-Transit objects
387 # * Negative-Cached objects
393 TAG: minimum_object_size
394 ~~~~~~~~~~~~~~~~~~~~~~~~~~
396 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).
398 TAG: minimum_object_size::
400 # TAG: minimum_object_size (bytes)
401 # Objects smaller than this size will NOT be saved on disk. The
402 # value is specified in kilobytes, and the default is 0 KB, which
403 # means there is no minimum.
406 # minimum_object_size 0 KB
407 minimum_object_size 0 KB
409 Negoziazione degli accesi al servizio
410 ---------------------------------------
412 Squid e' uno di quei servizi soggetto a problemi di tipo *open relay* , si deve quindi limitare la rete che puo' accedere al servizio.
415 Un servizio a cui possono accedere tutti indiscriminatamente.
416 La cosa puo' andare bene per servizi come i server web, che aspirano per loro natura
417 al maggior numero possibile di utenti, ma non a servizi come i proxy http oppure
418 ai server di posta elettronica (che permetterebbero l'invio di SPAM).
420 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*.
422 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.
424 Dopodiche l'accesso (``http_access``) si concedera' (*allow*) a questa entita' (es: ``localnet``) negando chiunque altro.
426 Per maggiori dettagli sulla sintassi utilizzabile per esprimere i range di IP:
427 http://www.visolve.com/squid/squid24s1/access_controls.php
431 ~~~~~~~~~~~~~~~~~~~~~
432 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.
437 # Defining an Access List
439 # Every access list definition must begin with an aclname and acltype,
440 # followed by either type-specific arguments or a quoted filename that
441 # they are read from.
443 # ***** ACL TYPES AVAILABLE *****
445 # acl aclname src ip-address/netmask ... # clients IP address
448 # Example rule allowing access from your local networks.
449 # Adapt to list your (internal) IP networks from where browsing
451 #acl localnet src 10.0.0.0/8 # RFC1918 possible internal network
452 #acl localnet src 172.16.0.0/12 # RFC1918 possible internal network
453 #acl localnet src 192.168.0.0/16 # RFC1918 possible internal network
455 acl localnet src 10.10.208.0/24
459 # Allowing or Denying access based on defined access lists
461 # Access to the HTTP port:
462 # http_access allow|deny [!]aclname ...
464 # NOTE on default values:
466 # If there are no "access" lines present, the default is to deny
470 # INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS
472 # Example rule allowing access from your local networks.
473 # Adapt localnet in the ACL section to list your (internal) IP networks
474 # from where browsing should be allowed
475 #http_access allow localnet
476 http_access allow localnet
481 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.
487 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.
489 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``.
492 http_proxy=10.10.208.178:3128
494 Si proceda a scaricare dal client scelto con un wget::
496 wget http://www.google.it
499 ~~~~~~~~~~~~~~~~~~~~~
501 Si puo' controllare il corretto funzionamento del server seguendo i log di accesso a Squid::
503 # tail -f /var/log/squid3/access.log
505 In oltre e' possibile configurare diversi *analizzatori di log* come ``Webalizer`` per studiare i log di Squid.
511 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.
513 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.
515 Pacchetti da installare::
516 ----------------------------
520 Con la release 2.0 di Apache viene automaticamente resa disponibile anche la versione SSL (Secure Socket Layer, connessioni criptate ) del web server.
523 Configurazione di Apache
524 ----------------------------
526 I file di configurazione di apache si trovano nella cartella: ``/etc/apache2`` e sono strutturati come descritto nel file
527 ``/usr/share/doc/apache2/README.Debian.gz`` . Sostanzialmente lo schema e' il seguente:
530 File di configurazione principale del servizio.
532 httpd.conf e' il vecchio file di configurazione di Apache1, presente per motivi di retrocompatibilita' e' generalmente vuoto.
535 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>``
538 In questa cartella vengono raccolti i file di configurazione dei virtual host disponibili.
541 In questa cartella sono contenuti dei link simbolici ai files in ../sites-available : se il link e' presente in questa cartella il virtual host e' abilitato.
544 Stesso metodo per i moduli: in questa cartella ci sono i moduli veri e propri che verranno poi abilitati grazie all'esistenza di link simbolici nella cartella mods-enabled .
547 Moduli abilitati, effettivamente caricati.
552 File di configurazione del servizio Apache, contiene le impostazioni generiche (ad esempio utilizzo della RAM e risorse di sistema) dell'intero servizio. Nella configurazione di default per Debian non viene definito un vero e proprio sito di default ma solo dei virtual hosts.
554 Guardiamo alcune direttive interessanti:
557 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.
560 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.
562 Server-Pool Size Regulation
563 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.
566 Il nome del file che viene onorato per modificare le impostazioni per una singola directory, legato alla direttiva AllowOverride .
569 ---------------------
571 Pacchetti da installare: ``php5 php-pear``
576 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::
580 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.
582 Installazione del supporto per Mysql
583 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
585 Installare i pacchetti::
587 php5-mysql phpmyadmin
589 Controllare tramite la pagina php.info che sia abilitato il supporto per Mysql (ripartito Apache, ricaricare la pagina e cercare con CTRL+f ``mysql``).
592 ~~~~~~~~~~~~~~~~~~~~~
594 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`` .
596 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/`` .
598 Installazione del supporto per Postgresql
599 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
601 Installare i pacchetti::
603 php5-pgsql phppgadmin
605 Controllare tramite la pagina php.info che sia abilitato il supporto per PostgreSQL (ripartito Apache, ricaricare la pagina e cercare con CTRL+f ``pgsql``).
609 ~~~~~~~~~~~~~~~~~~~~~
611 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`` .
613 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/`` .
618 * http://www.apacheweek.com/features/vhost
620 * http://www.onlamp.com/pub/a/apache/2004/01/08/apacheckbk.html
622 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:
624 * Basati su *indirizzi IP*.
625 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.
627 * Basati su *nomi di dominio* che puntano allo stesso IP.
628 Soluzione piu' economica e diffusa che si basa sulle funzionalita' di http 1.1 .
630 Prenderemo in esame la gestione di virtual hosts basati su nomi di dominio.
635 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:
638 Impostare i campi A nelle proprie zone gestite dal server DNS Bind. Ad es: ``papo A 212.22.136.248``
640 *Servizio DNS dinamico on line*.
641 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.
643 *Dnsmasq* (DNS server)
644 Utilizzabile al livello della rete locale per fare dei test, utilizzando direttive come: ``address=/davide.piffa.net/10.10.208.178``
647 Per prove sul proprio sistema potete impostare i nomi dei vostri virtual server nel file /etc/hosts .
649 Query DNS con ``dig``::
653 ; <<>> DiG 9.5.1-P1 <<>> 177.piffa.net
654 ;; global options: printcmd
656 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38036
657 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
663 177.piffa.net. 0 IN A 10.10.208.177
666 La parte interessante e' l'*ANSWER SECTION*: ``177.piffa.net. 0 IN A 10.10.208.177`` . Il nome di dominio 177.piffa.net viene risolto sull'ip 10.10.208.177 , nel nostro Apache (che risponde all'ip 10.10.208.177 ) dovra' essere disponibile un virtual host che corrisponde al nome ``177.piffa.net`` (``ServerName``) .
671 Esempio di Virtual host::
674 ServerName 177.piffa.net
675 DocumentRoot /var/www/177.piffa.net/
676 ServerAdmin webmaster@177.piffa.net
679 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``.
680 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.
681 3. ``DocumentRoot`` : il path della directory che contiene le pagine del sito.
682 4. ``ServerAdmin``: l'indirizzo del webmaster, in modo da poterlo contattare in caso di problemi col sito.
683 5. ``</VirtualHost>``: *tag* di chiusura della stanza di definizione del virtual host.
685 Quelle che abbiamo appena visto sono le direttive essenziali per definire un sito virtuale, potrebbe essere utile aggiungere altre:
687 * ``ErrorLog /var/log/apache2/177.piffa.net/error.log``
688 Log degli errori separato dai restanti siti web ospitati dal server.
691 Livello di importanza degli eventi loggati= warning *attenzione* .
693 * ``CustomLog /var/log/apache2/177.piffa.net/access.log combined``
694 Log di accesso separati dagli altri siti, utile anche qua per statistiche di accesso per il solo sito virtuale.
697 Potrebbe essere utile modificare le impostazioni di una intera directory, ad esempio per abilitare l'``AuthConfig``::
699 <Directory "/var/www/miosito.net/privata">
700 AllowOverride AuthConfig
701 Options ExecCGI Indexes MultiViews FollowSymLinks
706 ``AllowOverride AuthConfig`` ora vale per l'intera directory, come le altre opzioni.
709 ---------------------
711 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.
714 ~~~~~~~~~~~~~~~~~~~~~~
716 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::
720 <Directory "/var/www/177.piffa.net">
726 Potremmo negare l'accesso a uno o piu' indirizzi IP in questo modo::
730 <Directory "/var/www/177.piffa.net">
733 Deny from 192.168.0.1
737 Ora l'IP 192.168.0.1 non potra' piu' accedere ai materiali dell'intero sito virtuale, oppure potremmo lavorare su una sola directory::
739 <Directory "/var/www/miosito.net/limitata">
741 Allow from 192.168.0.0./24
745 In questo modo solo la classe IP ``192.168.0.0/24`` potra' accedere alla directory ``/limitata``
746 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.
750 ---------------------
752 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.
754 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.
755 Mod auth non richiede l'installazione di niente di tutto questo.
758 link: http://www.apacheweek.com/features/userauth
761 ~~~~~~~~~~~~~~~~~~~~~~
763 Decidere quale sara' il *path* della cartella da sottoporre ad autenticazione:
765 ``mkdir /var/www/177.piffa.net/privata``
767 Creazione del database delle passwords
768 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
770 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.
772 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.
774 Creiamo (con il *flag* ``-c``) il file ``/home/utente/passwords`` con l'utente ``luca``::
776 htpasswd -c /home/utente/passwords luca
778 ``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``.
780 Configurazione di Apache
781 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
783 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 (tramite una direttiva ``<Directory>`` ) il file di impostazione del virtual-host.
785 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.
787 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.
789 Abilitiamo l'AllowOverride nel file di configurazione del virtual host per la sola directory ``privata``::
792 ServerName 177.piffa.net
793 DocumentRoot /var/www/177.piffa.net/
794 ServerAdmin webmaster@177.piffa.net
795 <Directory "/var/www/177.piffa.net/privata">
796 AllowOverride AuthConfig
800 Per rendere il cambiamento effettivo sara' necessario fare un restart / reload di Apache.
802 Ora sara' possibile, anche per l'utente di sistema, creare un file ``.htaccess`` che sara' onorato da Apache.
804 /var/www/177.piffa.net/privata/.htaccess ::
806 # Messaggio visualizzato al prompt per l'autenticazione
807 AuthName "Area privata soggetta ad autentizazione"
808 # tipo di autenticazione da usarsi
810 # File precedentemente generato con htpasswd
811 AuthUserFile /home/utente/passwords
813 # Negoziazione degli accessi
814 # valid users permette l'accesso agli utenti specificati
815 # nel file generato da htpasswd
818 Si noti che non e' necessario fare ripartire Apache per onorare i cambiamenti (un utente non avrebbe la possibilita' di farlo!).
820 Oltre a ``valid-users`` si potrebbe scegliere di usare la formula ``users`` che permette di elencare esplicitamente gli utenti::
821 require user pippo pluto
823 L'utente *paperino* che fosse comunque presente nel file generato da htpasswd non potrebbe accedere alla risorsa.
825 Nel caso ci fossero molti utenti conviene gestirli tramite *gruppi*::
826 require group staff studenti
828 I gruppi vengono definiti in un file in modo simile a ``/etc/groups`` per gli utenti di sistema::
831 studenti: lucap federico luca
833 da richiamare tramite la direttiva ``AuthGroupFile``.
840 * 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.
842 * 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.
847 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.
849 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*.
850 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.
852 Stessa cosa vale per gli altri servizi, come la posta elettronica, ssh, ecc. : *prima si deve effettuare una query DNS*.
854 Potrebbe verificarsi uno scenario simile a questo: i vostri server per i siti web funzionano correttamente come i siti ospitati, stessa cosa per i vostri server di posta, IMAP e POP3, e tutto il resto. Ma se poi un errore nella configurazione del DNS non rende raggiungibile l'intero *sito*: per l'utente finale e' come se nulla funzionasse.
856 Infatti quando si parla di un intervento della Polizia Postale per l'*oscuramento* di un sito dal punto di vista pratico questo si traduce generalmente nella rimozione o mistificazione del record DNS relativo a quel dominio (la *PP* ha facolta' di chiedere un simile intervento ai principali provider internet che forniscono connettivita' agli utenti italiani, oltre che poter agire direttamente sul NIC italiano per i domini della TLD *.it*)
858 L'operazione di convertire un nome in un indirizzo e' detta risoluzione DNS, convertire un indirizzo IP in nome e' detto risoluzione inversa.
860 Un *Registar* e' un operatore che ha la facolta' (accreditamento da parte dell ICANN) di registrare i domini di secondo livello per gli utenti finali, dietro compenso di una modica cifra (una decina di euro) che vale come contributo su base annuale per il mantenimento dell'infrastruttura.
863 -----------------------
865 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*.
867 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.0``. Se avete un solo IP conviene lasciare al fornitore la gestire del PTR, ma se avete a disposizione un'itera classe potete chiedere sempre al vostro provider che vi *deleghi* la gestione della zona tramite i vostri DNS.
869 Per alcuni servizi, ad esempio la spedizione della posta elettronica, e' richiedeiesto che venga impostata correttamente l'associazione tra il PTR dell'indirizzo IP usato dal server di postai e il record A RR al quale questo punta( RFC1912 sezione 2.1, paragrafo 2).
873 - http://www.faqs.org/rfcs/rfc1912.html 2.1 Inconsistent, Missing, or Bad Data
874 - http://www.ietf.org/rfc/rfc2505.txt
879 Un nome a dominio e' costituito da una serie di stringhe separate da punti, ad esempio bender.piffa.net. I nomi di dominio si leggono da destra verso sinistra: *TLD* o dominio di primo livello ``net``, secondo livello ``piffa``, terzo livello ``bender``. Il dominio di primo livello (o TLD, Top Level Domain, pronunciato *tilde* in Italia), per esempio .net o .it sono limitati e decisi direttamente dall'ente assegnatario ICANN ( Internet Corporation for Assigned Names and Numbers).
881 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.
883 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.
885 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.
888 -----------------------
890 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:
892 * 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).
893 * Record MX - (Mail eXchange) indica a quali server debba essere inviata la posta elettronica per un certo dominio.
894 * 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.
895 * 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).
896 * Record AAAA - Restituisce un indirizzo IPv6.
897 * Record SRV - Identificano il server per un determinato servizio all'interno di un dominio. Possono essere considerati una generalizzazione dei record MX.
898 * Record TXT - Associano campi di testo arbitrari ad un dominio. Questi campi possono contenere una descrizione informativa oppure essere utilizzati per realizzare servizi.
900 Vi sono anche tipi di record "di servizio", necessari al funzionamento del database distribuito:
901 * Record NS - Utilizzato per indicare quali siano i server DNS autoritativi per un certo dominio, ovvero per delegarne la gestione.
902 * Record SOA - (Start of Authority) usato per la gestione delle zone DNS.
907 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*::
909 ping -c 1 www.google.com
910 PING www.l.google.com (74.125.43.104) 56(84) bytes of data.
912 Risoluzione dei nomi di dominio
913 ----------------------------------
915 Ci sono vari strumenti per interrogare i server DNS e ottenere l'indirizzo IP associato al nome di dominio che ci interessa::
918 www.piffa.net is an alias for piffa.net.
919 piffa.net has address 65.98.21.97
920 piffa.net mail is handled by 10 65.98.21.97
923 $ nslookup www.piffa.net
925 Address: 192.168.0.10#53
927 Non-authoritative answer:
928 www.piffa.net canonical name = piffa.net.
935 ; <<>> DiG 9.6.0-P1 <<>> www.piffa.net
936 ;; global options: +cmd
938 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47751
939 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 4
945 www.piffa.net. 3489 IN CNAME piffa.net.
946 piffa.net. 3489 IN A 65.98.21.97
948 ;; AUTHORITY SECTION:
949 piffa.net. 86289 IN NS ns2.mydomain.com.
950 piffa.net. 86289 IN NS ns1.mydomain.com.
951 piffa.net. 86289 IN NS ns4.mydomain.com.
952 piffa.net. 86289 IN NS ns3.mydomain.com.
954 ;; ADDITIONAL SECTION:
955 ns1.mydomain.com. 96208 IN A 64.94.117.193
956 ns2.mydomain.com. 96208 IN A 64.94.31.67
957 ns3.mydomain.com. 96208 IN A 66.150.161.137
958 ns4.mydomain.com. 96208 IN A 63.251.83.74
960 ;; Query time: 1 msec
961 ;; SERVER: 192.168.0.10#53(192.168.0.10)
962 ;; WHEN: Sun May 10 21:23:11 2009
963 ;; MSG SIZE rcvd: 209
965 Lo strumento piu' esaustivo e' ``dig``, installabile con il pacchetto ``dnsutils`` .
970 Vediamo alcune opzioni utili nell'utilizzo di ``dig`` per l'interrogazione dei DNS Server::
975 ; <<>> DiG 9.6.0-P1 <<>> www.google.it
976 ;; global options: +cmd
978 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18816
979 ;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 7, ADDITIONAL: 0
985 www.google.it. 250683 IN CNAME www.google.com.
986 www.google.com. 334819 IN CNAME www.l.google.com.
987 www.l.google.com. 186 IN A 74.125.43.103
988 www.l.google.com. 186 IN A 74.125.43.104
989 www.l.google.com. 186 IN A 74.125.43.147
990 www.l.google.com. 186 IN A 74.125.43.99
992 ;; AUTHORITY SECTION:
993 l.google.com. 80856 IN NS f.l.google.com.
994 l.google.com. 80856 IN NS d.l.google.com.
995 l.google.com. 80856 IN NS b.l.google.com.
996 l.google.com. 80856 IN NS c.l.google.com.
997 l.google.com. 80856 IN NS a.l.google.com.
998 l.google.com. 80856 IN NS e.l.google.com.
999 l.google.com. 80856 IN NS g.l.google.com.
1001 ;; Query time: 1 msec
1002 ;; SERVER: 192.168.0.10#53(192.168.0.10)
1003 ;; WHEN: Sun May 10 21:34:47 2009
1004 ;; MSG SIZE rcvd: 255
1007 (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.
1014 . 192032 IN NS C.ROOT-SERVERS.NET.
1015 . 192032 IN NS E.ROOT-SERVERS.NET.
1016 . 192032 IN NS B.ROOT-SERVERS.NET.
1017 . 192032 IN NS L.ROOT-SERVERS.NET.
1018 . 192032 IN NS A.ROOT-SERVERS.NET.
1019 . 192032 IN NS F.ROOT-SERVERS.NET.
1020 . 192032 IN NS H.ROOT-SERVERS.NET.
1021 . 192032 IN NS G.ROOT-SERVERS.NET.
1022 . 192032 IN NS K.ROOT-SERVERS.NET.
1023 . 192032 IN NS M.ROOT-SERVERS.NET.
1024 . 192032 IN NS I.ROOT-SERVERS.NET.
1025 . 192032 IN NS J.ROOT-SERVERS.NET.
1026 . 192032 IN NS D.ROOT-SERVERS.NET.
1031 Permette di fare una query ad un server dns particolare.
1032 Es: ``dig @151.99.25.1 www.google.it``
1034 dig MX www.google.it
1035 Chiede un campo in particolare, in questo caso il campo MX
1037 dig ANY www.google.it
1038 Chiede tutti i campi, non solo i campi *a*
1040 dig -x 74.125.43.104
1041 Effettua una richiesta inversa: dall'IP al PTR associato.
1046 Il file ``/etc/resolv.conf`` contiene le impostazioni sul dns usato dal sistema, in genere anche altre applicazioni che devono effettuare query DNS leggono resolv.conf per conoscere l'ubicazione del DNS.
1050 - ``nameserver``: indica il nameserver da utilizzare, indicato con l'indirizzo IP.
1052 - ``domain``: indica il nome di dominio della rete attuale, vedi voce successiva.
1054 - ``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``.
1057 Si veda anche la pagina man di resolv.conf.
1059 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``.
1065 Tabella statica per l'associazione tra IP e nomi di dominio::
1069 127.0.0.1 localhost.localdomain localhost
1070 10.10.208.162 daniela daniela.piffa.net
1071 10.10.208.254 mirror mirror.piffa.net
1072 91.191.138.15 thepiratebay.org
1073 192.168.0.11 chrome chrome.mydomain.com
1075 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.
1077 Il problema e' la gestione di questo file: quando gli host cambiano IP si devono aggiornare i records, e poi c'e' 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.
1079 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``::
1081 127.0.0.1 www.facebook.com
1083 Impedira' agli utenti della LAN di raggiungere *facebook*, ora reindirizzato a i``localhost``.
1089 Ogni computer ha un *proprio nome* visualizzabile (e modificabile) con il comando ``hostname``.
1091 Per modificare in modo permanente il nome del computer si modifichi il contenuto del file ``/etc/hostname``.
1093 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.
1094 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::
1096 * Squid: ``visible_hostname``
1098 * Postfix: ``myhostname``
1100 Si faccia attenzione a non aver un hostname puramente numerico: ad es. ``161``. E' opportuno che il nome sia comunque un alfanumerico: ``host-161`` o simile.
1105 Dnsmasq puo' svolgere le funzioni di un DNS cache / forwarder e un server DHCP caratterizzato dalla facilita' di configurazione, 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>_` .
1107 Dnsmasq e' un interessante alternativa all'uso del server DNS Bind in modalita' cache-only (non autoritativo) accompagnato dal server DHCPd. I vantaggi sono:
1109 - Leggerezza: puo' essere fatto girare su una macchina relativamente debole in caso di bisogno.
1110 - Rapidita' di configurazione (in particolare per servire dei record A / MX alla rete, modificando al volo i valori originali ospitati sul server DNS pubblico).
1111 - Ben integrato con connessioni PPP : e' ingrado di rilevare i cambiamenti dei dns suggeriti e impostarli come forwarders (utile se dovete rendere disponibile rapidamente una connessione a internet a una rete in difficolta').
1113 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.
1114 Molto utile per scopi didattici, sopratutto per testare server SMTP impostando al volo i campi MX per nomi di dominio fittizi.
1120 Vediamo alcune direttive di basi del file di configurazione ``/etc/dnsmasq.conf`` utili per la configurazione sia del DNS cache che per il DHCP server:
1124 Non inoltrare query ai server DNS esterni per nomi semplici (es andrea, portatile, pippo) che verranno risolti solo in locale o causeranno direttamente una risposta *not found* .
1128 Simile alla voce precedente ma per i reverse look-up.
1132 Nome di dominio della rete da passare ai client.
1136 Aggiunge il ``nome host`` ( ``/etc/hostname``) dei client al nome di dominio per qualificarli in rete, senza bisogno di dover comporre a un elenco statico di record nel file ``/etc/hosts`` o nello stesso file di configurazione di dnsmasq. Es: se un vostro client si chiama ``chrome`` e il vostro dominio ``piffa.net`` dnsmasq rendera' disponibile il campo *A* per il dominio ``chrome.piffa.net`` diretto all'ip che verra' assegnato al client.
1142 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.
1144 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!
1146 /etc/dnsmasq.conf (riga 118)::
1148 dhcp-range=192.168.0.20,192.168.0.50,24h
1153 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::
1155 nameserver 127.0.0.1
1158 Questo pero' potrebbe essere problematico se un altro servizio, ad esempio il DHCP client, riscrive il contenuto del file ``/etc/resolv.conf``. Per superare il problema si aggiunga (riga 20) al file di configurazione ``/etc/dhcp3/dhclient.conf`` ::
1160 prepend domain-name-servers 127.0.0.1;
1162 Oppure potrebbe essere il nostro *PPP client* (per la connessione ADSL) a intervenire sul file ``//etc/resolv.conf``, si modifichi quindi ``/etc/ppp/peers/dsl-provider`` commentando ``usepeerdns``. Se la vostra connessione ad internet e' ADSL raramente dovreste aver bisogno di cambiare i DNS una volta impostati (a meno che non usiate un portatile!).
1165 Bind : DNS Autoritativo
1166 ===========================
1168 Le soluzioni viste possono bastare per la rete locale o per fare delle prove, ma prima o poi verra' il momento in cui si e' chiamati a gestire dei domini su internet: lo standard e' da sempre *Bind* ( demone *named*), ora alla versione 9.
1170 Installare i pacchetti::
1177 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*.
1179 E' comunque possibile impostare dei DNS forwarders, tipicamente i DNS server forniti dal proprio provider, per velocizzare le query:
1181 /etc/bind/named.conf.options (riga 13)::
1187 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:
1189 /etc/bind/named.conf.options (riga 19)::
1191 // Se il proprio server ha IP 10.10.208.254
1192 // sulla rete LAN privata:
1193 listen-on { 10.10.208.254; }
1195 E non si lasci il server in ascolto su uno degli eventuali indirizzi IP pubblici.
1197 Se questo non fosse possibile si puo' sempre lavorare su una *acl*:
1199 /etc/bind/named.conf ::
1202 10.10.208.0/24 ; 127.0.0.0/8 ;
1205 Per poi aggiungere all'interno della stanza options la direttiva che abilita' l'entita' ``localnet``:
1207 /etc/bind/named.conf.options ::
1209 allow-query {"localnet" ;} ;
1216 Samba e' un progetto libero che fornisce servizi di condivisione di file e stampanti a client SMB/CIFS.
1218 Samba e' liberamente disponibile, al contrario di altre implementazioni SMB/CIFS, e permette di ottenere interoperabilita' tra Linux, Unix, Mac OS X e Windows.
1220 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.
1225 Pacchetti da installare per utilizzare Samba in modalita' client [#]_ ::
1229 Pacchetti da installare per utilizzare Samba in modalita' server::
1231 samba smbfs smbclient
1233 .. [#] Anche se nato per i sistemi Windows, Samba puo' essere usato anche per montare cartelle sotto GNU/Linux come alternativa a NFS. Per la condivisione di stampanti sarebbe invece opportuno intervenire direttamente su ``CUPS``.
1235 Durante la prima installazione viene chiesto il nome del gruppo di appartenenza, il default per Windows e' ``WORKGROUP``. In aula usiamo invece ``208`` .
1237 Per riconfigurare Samba si usi il comando::
1239 dpkg-reconfigure samba-common
1241 Passwords e autenticazione
1242 ---------------------------
1244 Per poter configurare Samba in modo che usi un sistema di negoziazione degli accessi alle cartelle condivise basato su accoppiate *nome utente / password* bisogna distinguere tra 3 livelli di password (e generalmente volete usare *sempre la stessa password* per ognuno di questi) e delle differenze tra le modalita' di *autenticazione* (e quindi anche di criptaggio delle passwords) usate da sistemi GNU/Linux e Windows:
1246 1 Sistema \*Unix ( GNU/Linux )
1247 E' la password dell'*utente di sistema* che viene usata sul sistema operativo su cui gira il software Samba. E' importante tenere conto anche delle *user-id* e *group-id* degli utenti che dovranno fisicamente scrivere sui file system. Se un utente non puo' scrivere in una certa posizione del file system (ad esempio nella cartella ``/mnt/condivisione`` che sara' stata necessariamente creata inizialmente dall'utente ``root``) per mancanza dei privilegi di scrittura allora neanche Samba potra' farlo nel momento in mette a disposizione la risorsa all'utente. Se si montano file-system dedicati per le condivisioni controllare i permessi e proprieta' dei *punti di mount**.
1248 Queste passwords sono salvate nel solito file /etc/shadow (richiamato da /etc/passwd).
1250 2 Password per l'applicativo Samba
1251 Samba deve essere compatibile con Windows e quindi utilizzare un sistema di criptazione delle password diverso da /etc/shadow . Le password per Samba possono essere gestite ad esempio col comando ``smbpasswd`` e vengono generalmente salvate all'interno di ``/var/lib/samba/passdb.tdb`` .
1253 3 Password per Windows.
1254 Gli utenti Windows effettuano il log-in alla partenza della sessione di Windows. Se si avra' l'accortezza di usare sempre la *stessa password* data precedentemente anche a Windows (o viceversa impostare la password per GNU/Linux / Samba uguale a quella di Windows) l'utente potra' accedere automaticamente alle condivisioni a lui disponibili.
1260 Creiamo per primo l'utente sotto GNU/Linux, facendo attenzione a *non dargli una shell di sistema*. Gli utenti Windows che accedono al server solo per le condivisioni non hanno bisogno di poter eseguire comandi sul server!
1262 Creazione di un utente denominato sambo::
1264 adduser --shell /bin/false sambo
1266 Nel file ``/etc/passwd`` avremo qualcosa come::
1268 sambo:x:1001:1001:Sambo utente Samba,,,:/home/sambo:/bin/false
1271 Aggiunta dell'utente al database delle password per Samba e generazione della sua password::
1275 Se successivamente si vorra' modificare la password di un utente gia' esistente si usi::
1280 La password sotto Windows verra' modificata sul sistema Windows.
1282 Creare la condivisione
1283 ------------------------
1285 La condivisione altro non e' che una cartella sul server che viene resa disponibile ai client negoziando l'accesso in base a una autenticazione basata su *user-name / password*. E' per altro possibile permettere l'accesso a una risorsa a chiunque indiscriminatamente (a tutti i ``guest``) ma la cosa e' sconsigliabile dal punto di vista della sicurezza. Si decida se la cartella condivisa debba risiedere nella *home* di un utente (nel caso quest'ultimo ne sia l'unico fruitore) o in una cartella in /mnt/ (nel caso piu' utenti accedano a questa). Nel secondo caso si potranno gestire gli accessi sotto GNU/Linux tramite i gruppi.
1287 Creazione della risorsa sambo_share nella home dell'utente sambo::
1289 # mkdir /home/sambo/sambo_share
1290 # chown sambo:sambo /home/sambo/sambo_share/
1292 Sicurezza: permessi di esecuzione sul server
1293 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1295 Bisognerebbe notare sul server i permessi di esecuzione del file-system che ospita la cartella da condividere. Se i file che saranno contenuti nella condivisione saranno da usarsi sotto Windows non c'e' motivo che questi siano eseguibili sotto GNU/Linux.
1296 Si potrebbe avere quindi, ipotizzando una condivisione in ``/mnt/share`` che risieda su di un file system dedicato:
1300 /dev/hda10 /mnt/share ext3 rw, **nosuid,noexec** 0 3
1302 Si noti anche l'uso di *nosuid* per evitare la possibilita' di eseguire programmi con credenziali diverse.
1304 Configurazione dell'applicativo Samba vero e proprio.
1305 ------------------------------------------------------
1307 Avendo preparato gli utenti (ancora una volta: non si dia una shell completa a un utente che serve solo per Samba o la posta elettronica) e la cartella sul file system si puo' procedere a configurare la condivisione su Samba.
1310 /etc/samba/smb.conf riga ~235 , Share Definitions (in vim si usi 235gg )::
1313 # Percorso della cartella condivisa
1314 path = /home/sambo/sambo_share
1315 # Se gli utenti possono scrivere / modificare file
1317 # Negoziazione degli accessi su base utenti / passwords
1320 # #######################################
1321 # Altri parametri opzionali di interesse
1322 # Se posso vedere la condivisione da esplora risorse
1323 # anche se non ho i privilegi per accedervi.
1325 # Commento indicativo della risorsa
1326 comment = Condivisione per Sambo
1328 Dopo aver salvato il file si puo' fare un primo controllo tramite l'utility ``testparm`` , che controlla la sintassi del file di configurazione di Samba. Se questo non rileva problemi si puo' procedere a un ``# /etc/init.d/samba restart`` .
1332 --------------------
1334 Come testare il servizio
1338 smbclient -U sambo -L localhost
1340 Questo comando permette di esplorare la risorsa qualificandosi come utente, in questo modo potete testare il corretto funzionamento dell'autenticazione. Si provi inizialmente a sbagliare la password deliberatamente, poi a inserirla correttamente: dovrebbero essere visibili le risorse disponibili al solo utente sambo: la suo /home e la cartella samba_share::
1342 Sharename Type Comment
1343 --------- ---- -------
1344 sambo_share Disk Condivisione per Sambo
1345 print$ Disk Printer Drivers
1346 IPC$ IPC IPC Service (base server)
1347 sambo Disk Home Directories
1349 In particolare l'ultima voce relativa alla home directory dell'utente dovrebbe essere visibile solo agli utenti autenticati.
1351 In alternativa e' possibile montare realmente la condivisone anche su GNU/Linux tramite un client per samba e testarne il corretto funzionamento::
1353 mount -t smbfs //localhost/sambo_share /mnt/sambo_mount/ --verbose -o user=sambo
1355 Server di posta: Postfix
1356 ============================
1358 Il server di posta che prenderemo in considerazione e' Postfix, a seguire un estratto di un file di configurazione *semplice* con l'abilitazione delle *Maildir* nelle ``/home`` degli utenti per la consegna della posta:
1360 ``/etc/postfix/main.cf``::
1362 # ...segue dalla riga ~30
1363 myhostname = 162.piffa.net
1364 alias_maps = hash:/etc/aliases
1365 alias_database = hash:/etc/aliases
1366 myorigin = 162.piffa.net
1367 mydestination = 162.piffa.net, localhost
1368 # Se non avete un ip pubblico e statico, con un adeguato record PTR
1369 # dovrete usare un realy host per l'invio della posta
1370 relayhost = smtp.piffa.net
1372 mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
1373 # Se dovete inviare la posta per i client della vostra LAN privata:
1374 # mynetworks = 127.0.0.0/8 192.168.0.0/24 [::ffff:127.0.0.0]/104 [::1]/128
1375 # E si faccia BEN ATTENZIONE a non diventare un open realay smtp
1378 # Per effettuare lo storaggio della posta nelle home directory degli utenti
1379 # in una Maildir invece che nella Mailbox in /var/mail/nome_utente
1380 # si disabiliti procmail
1381 #mailbox_command = procmail -a "$EXTENSION"
1383 # cartella_i abiliti lo storaggio della posta nella Maildir/ (si noti lo slash)
1384 # all'interno della home dell'utente:
1385 home_mailbox = Maildir/
1386 mailbox_size_limit = 0
1387 recipient_delimiter = +
1388 inet_interfaces = all
1391 E' disponibile un file di configurazione di esempio ben piu' articolato e commentato::
1392 /usr/share/postfix/main.cf.dist .
1394 Test del server smtp
1395 -----------------------
1397 Per testare il corretto funzionamento del server di posta si puo' procedere in vari modi.
1399 - Spedire una mail a una casella locale / remota e controllare i log (syslog)
1400 - Collegarsi via *telnet* al server di posta: http://www.netadmintools.com/art276.html
1401 - usare una utility come SWAKS
1406 Per gli utenti meno esperti e' consigliabile utilizzare *SWAKS*: si installi l'omonimo pacchetto e si esegua un test con::
1407 swaks --to utente@destinatario.tilde --from utente@propio.mail.tilde
1409 Ecco un esempio di una sessione corretta::
1411 swaks --to andrea@piffa.net from andrea@mydomain.com
1412 === Trying smtp.piffa.net:25...
1413 === Connected to smtp.piffa.net.
1414 <- 220 zoo.piffa.net ESMTP Postfix (Debian/GNU)
1415 -> EHLO alice.mydomain.com
1416 <- 250-zoo.piffa.net
1418 <- 250-SIZE 10240000
1422 <- 250-ENHANCEDSTATUSCODES
1425 -> MAIL FROM:<root@alice.mydomain.com>
1427 -> RCPT TO:<andrea@piffa.net>
1430 <- 354 End data with <CR><LF>.<CR><LF>
1431 -> Date: Thu, 28 May 2009 13:11:19 +0200
1432 -> To: andrea@piffa.net
1433 -> From: root@alice.mydomain.com
1434 -> Subject: test Thu, 28 May 2009 13:11:19 +0200
1435 -> X-Mailer: swaks v20061116.0 jetmore.org/john/code/#swaks
1437 -> This is a test mailing
1440 <- 250 2.0.0 Ok: queued as 41FB261AFC
1443 === Connection closed with remote host.
1450 Postfix e' un server SMTP, di conseguenza se volete che i vostri utenti possano *scaricare* in locale la posta generalmente volete mettere a loro disposizione un server *POP3* o *IMAP*. Oppure entrambi.
1452 Pacchetti da installare
1453 courier-imap courier-pop
1455 Si noti che IMAP necessita delle *Maildir*, non funziona con le Mailbox in ``/var/mail/`` .
1457 Client a riga di comando
1458 ---------------------------
1460 Per testare il corretto funzionamento del server di posta e' utile avere a disposizione delle utility per inviare e leggere la posta: ovviamente da riga di comando.
1465 Uno dei client piu' semplici, sopratutto per inviare un messaggioi. e' sufficiente usare una formula come::
1466 mail utente@dominio.com
1468 Se il comando ``mail`` non fosse disponibile si installi il pacchetto ``mailx``.
1470 Al primo prompt si digitera' l'oggetto, il testo del messaggio (per terminare l'inserimento lasciare una riga vuota, digitare un ``punto + Invio`` su una riga vuota), la Carbon Copy (se necessaria).
1474 mail andrea@localhost
1475 Subject: Oggetto della mail
1477 per terminare il messaggio
1478 lasciare una riga vuota
1479 e un punto (poi Invio).
1484 Per altrre opzioni si veda la pagina man.
1489 Mutt e' uno dei gestori di posta preferiti da chi preferisce utilizzare l'interfaccia testuale per la gestione della posta.
1491 Mutt ha un file di configurazione ``.muttrc`` nella *home* dell'utente, alcuni settaggi possono essere utili:
1493 set folder="~/Maildir"
1494 Per utilizzare ``/home/nome_utente/Maildir come mailbox``, invece del default ``/var/mail/nome_utente``.
1497 Utilizzare ``vim`` come editor per comporre i messaggi.
1500 Spesso e' utile poter *levvere al volo* la Mailbox / Maildir di un utente sul server di posta, per controllare se i messaggi vengono recapitati correttamente::
1502 mutt -f /var/mail/utente
1503 mutt -f /home/utente/Maildir
1505 In modo analogo si puo' consultare al volo la propia mailbox su un server remoto tramite IMAP/POP::
1507 mutt -f imap://nome_utente@piffa.net
1513 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`` .
1515 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::
1517 cd /etc/apache2/conf.d/
1518 ln -s /etc/squirrelmail/apache.conf ./squirrelmail.conf
1524 Il *graylisting* e' un sistema relativamente poco invasivo, con un limitato consumo di risorse per limitare lo *SPAM* in arrivo sul propio server di posta. Come suggerisce il nome e' una via di mezzo tra una *white list* (una lista di mittenti privilegiata, sempre benvenuti) e una *black list* (mittenti *bannati*, banditi dal poter inviare nuovi messaggi).
1526 Il funzionamento e' relativamente semplice: ogni mittente sconosciuto viene immediatamente rifiutato con un errore *non grave* come un *server non disponibile, provare piu' tardi*. Questo inconveniente non dovrebbe mettere in difficolta' un server di posta / mittente legittimo, che dopo un periodo di attesa tentera' nuovamente di inviare il messaggio ottenendo finalmente il risultato atteso. Diversamente un *bot* per l'invio di SPAM o un applicazione improvvisata (tipicamente di derivazione virale) che stesse inviando il messaggio *probabilmente* non insisterebbe, rinunciano ad inviare il messaggio preferendo destinazioni meno problematiche.
1529 Abilitazione in Postfix
1530 ~~~~~~~~~~~~~~~~~~~~~~~~
1532 Installare il pacchetto: ``postgrey`` e aggiungere il file di configurazione di Postfix ``/etc/postfix/main.cf``::
1534 smtpd_recipient_restrictions =
1536 reject_unauth_destination,
1537 check_policy_service inet:127.0.0.1:60000
1542 Inviando un messaggio il client dovrebbe ricevere un iniziale messaggio di rifiuto del messaggio::
1544 swaks --to andrea@piffa.net from andrea@mydonain.com
1545 === Trying smtp.piffa.net:25...
1546 === Connected to smtp.piffa.net
1549 -> RCPT TO:<andrea@piffa.net>
1550 <** 450 4.2.0 <andrea@piffa.net>: Recipient address rejected:
1551 Greylisted, see http://postgrey.schweikert.ch/help/piffa.net.html
1554 === Connection closed with remote host.
1556 A lato server si dovrebbe rilevare su ``/var/log/syslog`` qualcosa di simile::
1558 connect from alice.mydomain.com[65.98.21.97]
1559 May 28 14:53:34 r24266 postgrey: action=greylist, reason=new,
1560 client_name=alice.mydomain.com,
1561 client_address=10.0.0.1, sender=root@alice.mydomain.com, recipient=andrea@piffa.net
1562 May 28 14:53:34 r24266 postfix/smtpd[22538]:
1563 NOQUEUE: reject: RCPT from alice.mydomain.com[10.0.0.1]:
1564 450 4.2.0 <andrea@piffa.net>: Recipient address rejected: Greylisted,
1565 see http://postgrey.schweikert.ch/help/piffa.net.html;
1566 from=<root@alice.mydomain.com> to=<andrea@piffa.net>
1567 proto=ESMTP helo=<alice.mydomain.com>
1568 May 28 14:53:34 r24266 postfix/smtpd[22538]: disconnect from alice.mydomain.com[10.0.0.1]
1574 E' sempre utile poter tracciare qualche statistica sulle percentuali di messaggi ricevuti, da chi, messaggi rifiutati (e per quale motivo). Statistiche che attingono dai soliti log del server di posta ``/var/log/syslog`` di default oltre che i dedicati ``/var/log/mail`` .
1576 Una utility semplice per analizzare l'attivita' del propio server smtp potrebbe essere ``pflogsumm`` , installato il pacchetto la si puo' invocare con::
1578 pflogsumm.pl /var/log/mail.log
1580 oppure utilizzare i log piu' vecchi ad es. ``/var/log/mail.log.0``
1585 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.
1587 Una prima definizione chiusa di firewall è la seguente:
1589 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.
1591 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.
1593 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:
1598 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.
1603 * http://openskill.info/topic.php?ID=124
1604 * http://iptables-tutorial.frozentux.net/iptables-tutorial.html
1609 Link: http://iptables-tutorial.frozentux.net/iptables-tutorial.html#IPFILTERING
1611 Natura di un firewall ip: su cosa lavora (livello 2 e un po' del 3) e su cosa *non* lavora (livello 4).
1612 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.
1614 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.
1615 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.
1617 Progettazione di un firewall
1618 -----------------------------
1620 Per implementare un firewall bisogna decidere un aio di cose: la collocazione e l'approccio (inclusivo o esclusivo) al filtraggio, il tipo di hardware.
1625 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.
1630 2. tra router e servers / LAN
1631 3. Unico server / router / firewall e connessi rischi. considerare l'acquisto di un router hardware dedicato.
1634 Implementare piu' device / software sui diversi livelli: http://iptables-tutorial.frozentux.net/iptables-tutorial.html#HOWTOPLANANIPFILTER
1640 Drop o Accept: conseguenze per sicurezza, facilita' di gestione.
1646 Sostanzialmente potremmo distinguere due tipologie di hardware:
1648 Network appliance dedicata::
1649 Un dispositivo hardware dedicato alla funzione di Firewall, ad es un Cisco / Fortigate.
1650 Si noti che molti firewall economici altro non sono che Linux box molto striminzite.
1652 Server / Personal computer:
1653 Un server sul quale viene fatto girare Netfilter ad uso del server stesso e della rete connessa.
1655 Vantaggi e svantaggi: consumo elettrico, efficienza, flessibilita', strumenti di gestione, sicurezza, OpenBSD.
1657 Percorso dei pacchetti tra tabelle e catene
1658 -------------------------------------------
1660 link: http://iptables-tutorial.frozentux.net/iptables-tutorial.html#TRAVERSINGOFTABLES
1666 Tabelle, catene, regole
1667 ~~~~~~~~~~~~~~~~~~~~~~~~~
1669 Iptables lavora su 3 tabelle (tables) di default:
1671 * filter - Regola il firewalling: quali pacchetti accettare, quali bloccare
1673 * nat - Regola le attivita'à di natting
1675 * mangle - Interviene sulla alterazione dei pacchetti.
1677 Ogni tabella ha delle catene (chains) predefinite (INPUT, OUTPUT, FORWARD ... ) a cui possono essere aggiunte catene custom.
1678 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)
1679 Ogni regola termina con una indicazione (target) su cosa fare dei pacchetti identificati dalla regola stessa (es: -j ACCEPT, -j DROP ...)
1684 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.
1689 Protocollo IP. Secondo IP number o nome (es: tcp, udp, gre, ah...)
1691 -s [!] address[/mask]
1692 Indirizzo IP sorgente (o network con maschera di sotto rete)
1694 -d [!] address[/mask]
1695 Indirizzo IP destinazione (o network)
1698 Interfaccia di rete di entrata ([+] wildcard)
1701 Interfaccia di rete di uscita ([+] wildcard)
1704 Frammento di pacchetto
1709 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.
1714 Il pacchetto matchato viene accettato e procede verso la sua destinazione. Si usa per definire il traffico permesso.
1717 Il pacchetto viene rifiutato e scartato, senza alcuna notifica al mittente. Si usa, in alternativa a REJECT, per bloccare traffico.
1720 Il pacchetto viene rifiutato. Al mittente viene mandato un pacchetto (configurabile) di notifica tipo ICMP port-unreachable (--reject-with icmp-port-unreachable)
1723 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)
1726 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
1729 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.
1732 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.
1735 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)
1738 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.
1741 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
1744 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.
1750 E' quella implicita e predefinita (-t filter)
1751 Riguarda le attività di filtraggio del traffico.
1752 Ha 3 catene di default:
1753 INPUT - Riguarda tutti i pacchetti destinati al sistema. In entrata da ogni interfaccia.
1754 OUTPUT - Riguarda i pacchetti che sono originati dal sistema e destinati ad uscire.
1755 FORWARD - Riguarda i pacchetti che attraversano il sistema, con IP sorgente e destinazione esterni.
1757 Esempio per permettere accesso alla porta 80 locale:
1758 iptables -t filter -I INPUT -p tcp --dport 80 -j ACCEPT
1759 Analoga a: iptables -I INPUT -p tcp --dport 80 -j ACCEPT
1761 Esempio per permettere ad un pacchetto con IP sorgente 10.0.0.4 di raggiungere il server 192.168.0.1 attraversando il firewall:
1762 iptables -I FORWARD -s 10.0.0.4 -d 192.168.0.1 -j ACCEPT
1764 Flush automatico per macchine remote
1765 ---------------------------------------
1767 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.
1769 *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)::
1772 at> /sbin/iptables -F
1777 Gestione regole (rules)
1778 --------------------------
1780 Il comando iptables viene usato per ogni attivita'à di gestione e configurazione.
1784 iptables -A CATENA ...
1785 Aggiunge una regola alla fine della catena indicata
1787 iptables -I CATENA [#] ...
1788 Inserisce alla riga # (default 1) una regola nella catena indicata
1791 Crea una nuova catena custom
1793 iptables -P CATENA TARGET
1794 Imposta il target di default per la catena indicata
1796 Rimozione regole e azzeramenti:
1798 iptables -F [catena]
1799 Ripulisce tutte le catene (o quella indicata)
1801 iptables -X [catena]
1802 Ripulisce tutte le catene custom (o quella indicata)
1804 iptables -Z [catena]
1805 Azzera i contatori sulle catene
1807 iptables -D catena #
1808 Cancella la regola numero # dalla catena indicata
1813 Elenca le regole esistenti
1816 Elenca, senza risolvere gli host, in modo verboso le regole esistenti
1822 ----------------------
1824 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).
1826 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.
1828 Altro problema: decidere quando attivare / disattivare queste regole. Utilizzare i *runlevels* non e' una soluzione adeguata: le regole del firewall sono legate all'attivita' delle schede di rete (e un host con diverse schede di rete puo' attivarle a secondo delle esigenze di routing, partenza di servizi es file_sharing per un back-up...): il sistema operativo Debian permette di legare l'esecuzione di comandi alla attivazione di una device di rete (``up``), dopo la sua attivazione (``post-up``, utile per devices che richiedono un certo tempo per inizializzarsi: come un tunnel o una connessione punto a punto), prima della sua attivazione (``pre-up``). Allo stesso modo sono disponibili eventi analoghi per accompagnare la disattivazione dei device di rete: si veda la pagina man di ``interfaces``.
1830 Nel nostro caso avremo per una possibile scheda ``eth0``:
1832 ``/etc/network/interfaces`` ::
1834 iface eth1 inet static
1835 up /sbin/iptables-restore /root/firewall/basic_fw
1836 # Seguono i soliti parametri della scheda di rete
1837 address 10.10.208.21
1843 Per salvare le regole di iptables attualmente presenti nel kernel si usi il comando::
1845 # iptables-save >> /root/firewall/basic_fw
1847 Il contenuto del file dovrebbe essere *comprensibile*: sostanzialmente sono regole di iptables, senza il comando iptables ripetuto, suddivisi per le varie tabelle. Potete comunque correggere eventuali parametri con un edito di testo.
1850 Se non avete un'idea migliore potreste voler tenere gli script dei firewall in una cartella ``~/firewall`` nella home directory dell'utente ``root``.
1853 ~~~~~~~~~~~~~~~~~~~~
1855 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::
1857 /sbin/iptables-restore /root/firewall/basic_fw
1863 Seguono alcuni esempi sull'uso di iptables, lo scenario e' un computer con un paio di schede di rete fisiche una delle quali collegata alla rete internet l'altra a una rete privata per la LAN interna.
1865 1. ``eth0`` scheda di rete principale sulla rete privata interna 192.168.0.0/24
1867 2. ``eth1`` scheda di rete secondaria per la connessione ad internet
1869 3. ``ppp0`` punto-a-punto per una connessione ad internet
1871 Bloccare i ping dall'esterno
1872 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1874 Spesso gli script che attaccano *automaticamente* le varie reti provano a fare un ping per verificare quali IP sono on-line: bloccare il traffico ``ICMP`` in ingresso puo' aiutare ad evitare parte di questi attacchi::
1876 iptables -A INPUT -i ppp0 -p ICMP -j DROP
1879 ~~~~~~~~~~~~~~~~~~~~
1881 Per attivare la network address translation (in questo caso un SNAT) per la rete locale privata sull'indirizzo ip del *modem*::
1882 iptables -A POSTROUTING -s 192.168.0.0/255.255.255.0 -o ppp0 -j MASQUERADE
1884 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.
1887 ## Change source addresses to 1.2.3.4.
1888 # iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to 1.2.3.4
1890 ## Change source addresses to 1.2.3.4, 1.2.3.5 or 1.2.3.6
1891 # iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to 1.2.3.4-1.2.3.6
1893 ## Change source addresses to 1.2.3.4, ports 1-1023
1894 # iptables -t nat -A POSTROUTING -p tcp -o eth0 -j SNAT --to 1.2.3.4:1-1023
1899 Per limitare attacchi di tipo brute force su SSH::
1901 iptables -A INPUT -i ppp0 -p tcp -m tcp --dport 22 -m state --state NEW -m recent --update --seconds 3000 --hitcount 4 --name DEFAULT --rsource -j DROP
1903 iptables -A INPUT -i ppp0 -p tcp -m tcp --dport 22 -m state --state NEW -m recent --set --name DEFAULT --rsource
1910 * controllare apache
1913 sintassi: in ``monospace`` :
projects / doc / .git / blob