]> git.piffa.net Git - doc/.git/blob - source/servizi.txt
Merge branch 'master' of git@chrome.andreamanni.com:/home/git/doc
[doc/.git] / source / servizi.txt
1 ===============================
2 Servizi di rete passo a passo
3 ===============================
4 ----------------------------------------------------------
5 Appunti sulla installazione e configurazione dei servizi
6 ----------------------------------------------------------
7
8   :Author: Andrea Manni
9   :Copyright: GFDL
10   :Version: 0.7
11
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 .
13
14 .. sectnum::
15
16 .. contents:: Indice degli argomenti
17
18 Generato con: http://docutils.sourceforge.net/rst.html
19
20 Configurazione sistema
21 =========================
22 Solo per uso interno
23 ---------------------------
24
25 Impostazioni di base per la configurazione del sistema operativo e della rete nel laboratorio 208 facente parte della rete piffa.net .
26
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 *ip* della vostra rete.
28
29 Rete
30 ------
31
32 Parametri della rete attualmente in uso:
33
34 ============= ================
35      Parametri della rete
36 ------------------------------
37 rete          10.10.208.0/24
38 netmask       255.255.255.0
39 broadcast     10.10.208.255
40 gateway       10.10.208.254
41 gateway       10.10.208.250
42               persistente
43 DNS           10.10.208.254
44 DNS           10.10.208.250
45               persistente
46 proxy http    10.10.208.254:3128
47 ============= ================
48
49 Sul portatile di Andrea, corrispondente all'ip 254, gira un DHCP, proxy http e mirror di Debian ( http://debian.piffa.net). Se Andrea non e' in aula (o ancora peggio non c'e' il suo portatile Net) gli studenti dovranno darsi un indirizzo ip manualmente e disabilitare il proxy (che pero' e trasparente, quindi fate pure come se non ci fosse ;) . Questo in attesa che si sappia se sara' nuovamente utilizzabile il vecchio server Bender.
50
51 interfaces
52 ~~~~~~~~~~~~~~~
53
54 Segue un esempio del file di configurazione della scheda di rete con configurazione statica::
55         # /etc/network/interfaces -- configuration file for ifup(8), ifdown(8)
56
57         # The loopback interface
58         iface lo inet loopback
59
60         # La prima scheda di rete (se si chiama eth0)
61         # (network, broadcast and gateway sono optional)
62         iface etho inet static
63           # esempio con dhcp
64           # iface etho inet dhcp
65         address 212.22.136.101
66         netmask 255.255.255.0
67         network 212.22.136.0
68         broadcast 212.22.136.255
69         gateway 212.22.136.254
70
71         # Quali interfaccie devono partire automaticamente:
72         auto lo eth0
73
74 Controllare il nome della propia scheda di rete: a volte *udev* rinomina la prima scheda a ``eth1``, oppure potreste avere piu' di una scheda di rete (anche un'interfaccia *firewire* puo' essere automaticamente abilitata come scheda di rete).
75
76 Se si usano *schede di rete virtuali* ( eth0:1 , eth0:1 , ...) ricordarsi che queste dipendono dalla scheda fisica a cui sono associate: abbattere con ``ifconfig down eth0`` la scheda principale fara' cadere anche queste. Tornando ad attivare la schda principale con ``ifconfig eth0 up`` la virtuale tornera' attiva: nel caso voleste disabilitarla dovrete quindi sempre abbattere manualmente la scheda virtuale *prima* della scheda reale.
77
78 Bash completion
79 -------------------
80
81 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.
82
83 Bash_completion permette di integrare il completamento automatico con i nomi dei pacchetti e oggetti dei comandi: ad es. volendo digitare ``apt-get inst[TAB] xtigh[TAB]`` ora verra' completatato automaticamente sia la parola ``install`` che il nome del pacchetto ``xtightvncviewer``. 
84
85 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*)::
86
87         echo ". /etc/bash_completion" >> ~/.bashrc
88
89 Esempio di ~/.bahsrc ::
90
91         # ~/.bashrc: executed by bash(1) for non-login shells.
92         
93         export PS1='\h:\w\$ '
94         umask 022
95         
96         # Decommentare le seguenti righr per abilitare la colorazione dei
97         # nomi dei file:
98          export LS_OPTIONS='--color=auto'
99          eval "`dircolors`"
100          alias ls='ls $LS_OPTIONS'
101          alias ll='ls $LS_OPTIONS -l'
102          alias l='ls $LS_OPTIONS -lA'
103         
104         # Some more alias to avoid making mistakes:
105         # alias rm='rm -i'
106         # alias cp='cp -i'
107         # alias mv='mv -i'
108         
109         # questo abilita bash completion
110         . /etc/bash_completion
111
112 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.
113
114 Links:
115
116 * `An introduction to bash completion <http://www.debian-administration.org/articles/316>`_
117 * `Working more productively with bash 2.x/3.x <http://www.caliban.org/bash/>`_
118
119 Vim
120 ------------
121
122 Vim e' l'editor di testo preferito dai sistemisti, quindi sara' conveniente impostare fin da subito alcune impostazioni per renderlo piu' comodo.
123
124 Assicurarsi che sia installata nel sistema la versione completa dell'editor ``vim`` nstallando il  pacchetto vimi::
125
126         # apt-get install vim
127
128  e modificare il file di configurazione generale ``/etc/vim/vimrc`` ::
129
130     " All system-wide defaults are set in $VIMRUNTIME/debian.vim (usually just
131     " /usr/share/vim/vimcurrent/debian.vim) and sourced by the call to :runtime
132     " you can find below.  If you wish to change any of those settings, you should
133     " do it in this file (/etc/vim/vimrc), since debian.vim will be overwritten
134     " everytime an upgrade of the vim packages is performed.  It is recommended to
135     " make changes after sourcing debian.vim since it alters the value of the
136     " 'compatible' option.
137     
138     " This line should not be removed as it ensures that various options are
139     " properly set to work with the Vim-related packages available in Debian.
140     runtime! debian.vim
141     
142     " Uncomment the next line to make Vim more Vi-compatible
143     " NOTE: debian.vim sets 'nocompatible'.  Setting 'compatible' changes numerous
144     " options, so any other options should be set AFTER setting 'compatible'.
145     "set compatible
146     
147     " Vim5 and later versions support syntax highlighting. Uncommenting the next
148     " line enables syntax highlighting by default.
149     syntax on
150     
151     " If using a dark background within the editing area and syntax highlighting
152     " turn on this option as well
153     set background=dark
154     
155     " Uncomment the following to have Vim jump to the last position when
156     " reopening a file
157                       
158     if has("autocmd")
159       au BufReadPost * if line("'\"") > 0 && line("'\"") <= line("$")
160         \| exe "normal! g'\"" | endif
161     endif
162     
163     " Uncomment the following to have Vim load indentation rules and plugins
164     " according to the detected filetype.
165     if has("autocmd")
166       filetype plugin indent on
167     endif
168     
169     " The following are commented out as they cause vim to behave a lot
170     " differently from regular Vi. They are highly recommended though.
171     set showcmd             " Show (partial) command in status line.
172     "set showmatch          " Show matching brackets.
173     set ignorecase          " Do case insensitive matching
174     "set smartcase          " Do smart case matching
175     "set incsearch          " Incremental search
176     set autowrite           " Automatically save before commands like :next and :make
177     "set hidden             " Hide buffers when they are abandoned
178     "set mouse=a            " Enable mouse usage (all modes) in terminals
179     
180     " Source a global configuration file if available
181     " XXX Deprecated, please move your changes here in /etc/vim/vimrc
182     if filereadable("/etc/vim/vimrc.local")
183       source /etc/vim/vimrc.local
184     endif                                             
185
186 VNC
187 ------------
188
189 I Virtual Network Computing (o VNC) sono software di controllo remoto e servono per amministrare il proprio computer a distanza o visuallizare la sessione di lavoro di un altro computer sul proprio a scopo didattico. Installando un server VNC sulla propria macchina ed impostando una opportuna password si consente ai client VNC di ricevere una immagine dello schermo ed eventualmente di inviare input di tastiera e mouse al computer server (durante le lezioni questo non e' possibile per gli studenti, solo Andrea esegue i comandi). In pratica si può gestire il computer server da un'altra postazione, come se fosse il proprio computer fisico.
190
191 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`` ), rndere eseguibile lo script.
192
193 Procedura::
194
195     su root
196     cd /bin
197     wget http://debian.piffa.net/guarda.sh
198     chmod +x guarda.sh
199     exit
200
201 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.
202
203 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`` .
204
205 Lista dei pacchetti di base
206 -----------------------------
207
208 I pacchetti installati generalmente [#]_ per poter seguire le lezioni sono::
209
210         kde-core kdm kde-i18n-it xorg vim less xtightvncviewer 
211
212 .. [#] ``kde-core`` e' piu' leggero del pacchetto ``kde``, esiste anche un equivalente ``gnome-core gnome`` e il log-in manager ``gdm`` per il l'ambiente grafico Gnome.    
213
214 Apt configurazione
215 ---------------------
216
217 Vediamo i due file principali di apt:
218
219 * ``/etc/apt/sources.list``
220
221 * ``/etc/apt/apt.conf``
222
223 sources.list
224 ~~~~~~~~~~~~~~~~
225
226 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).
227
228 Gli archivi sono generalmente:
229
230 * ``deb`` per pacchetti Debian binari
231
232 * ``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.
233
234
235 ``/etc/apt/sources.list`` ::
236
237     # esempio di accesso a un CDROM:
238     # cdrom:[Debian GNU/Linux 5.0.1 _Lenny_ - Official i386 kde-CD Binary-1 20090$
239     
240     # Archivio principale debian via http su piffa.net,
241     # non funziona al difuori dell'aula dei corsi
242     deb http://debian.piffa.net/debian/ Lenny main
243     # deb http://debian.piffa.net/debian/ Lenny  non-free contrib
244     
245     # Mirror da kernel.org da usare a casa:
246     deb http://mirrors.eu.kernel.org/debian/ Lenny main
247     
248     # Security dal sito principale
249     deb http://security.debian.org/ Lenny/updates main
250     deb-src http://security.debian.org/ Lenny/updates main
251     
252     # Debian volatile per le cose soggette a cambiamenti non legati
253     # a dinamiche di sicurezza
254     deb http://volatile.debian.org/debian-volatile Lenny/volatile main
255     deb-src http://volatile.debian.org/debian-volatile Lenny/volatile main
256     
257     # Esempio di accesso a un filesystem locale contenente i pacchetti:
258     # deb file:/mnt/mirror Sid main non-free contrib
259
260
261 /etc/apt/apt.conf
262 ~~~~~~~~~~~~~~~~~~
263
264 Questo file contiene le opzioni di apt, come ad esempio il proxy::
265
266     Acquire::http::Proxy "http://10.10.208.254:3128";
267
268 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.
269
270
271 Squid
272 ======
273
274 Squid e' un proxy  cache http (ma anche FTP e https) robusto e strutturato, puo' essere usato sia in reti relativamente piccole grazie alla semplicita' di configurazione che in scenari piu' complessi grazie alla possibilita' di gestirne in modo granulare le risorse partendo dalle configurazioni piu' semplici per la semplice *condivisione della navigazione* internet, la gestione degli accessi, il filtraggio dei contenuti (Squid e' una applicazione che si muove nel 4' livello del modello TCP/IP a differenza di un *ipfilter* limitato al 2') nel l bilanciamento del carico tra piu' hosts.
275
276 Inoltre svolge la funzione di *anonymizer*:
277         nasconde i client http alla rete internet: risulta solo il server proxy nei log dei server web frequentati dagli utenti di Squid.
278
279 Cosa a volte sottovalutata, squid permette la navigazione web a una rete basata su *indirizzi ip privati* (es una 192.168.0.0/24). E se la rete privata deve *solo navigare* in internet, non serve un *NAT* od altro, basta il solo Squid. Per altro non servira' neanche un servizio DNS dato che *sara' il solo squid a risolvere i nomi di dominio* per i suoi client http.
280
281 Squid ascolta di default sulla porta 3128,  per impostare *apt* per utilizzarlo si aggiunga ad ``/etc/apt/apt.conf`` ::
282
283         Acquire::http::Proxy "10.10.208.254:3128";
284
285
286 Per installare Squid si usino i pacchetti::
287
288         squid3
289
290
291 Configurazione: squid.conf
292 -------------------------------
293
294 Segue un estratto delle direttive principali viste in aula presenti nel file di configurazione ``/etc/squid3/squid.conf`` .
295
296 Cache_dir
297 ~~~~~~~~~~~~
298
299 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.
300
301 La dimensione ovviamente dipendera' dallo spazio disponibile, dimensioni tipiche e massime degli oggetti che si vuole tenere in cache (un solo file *.iso e' circa ``700 MB``, il pacchetto *Openoffice.org* cira ``150 MB``, un pacchetto debian circa ``20 MB``), numero dei client.
302
303 Si presti poi attenzione alla natura dei dati che saranno salvati nella cache: sono tutti dati facilmenti sostituibili (gli originali sono *on-line*) la cui perdita non arreca danni permanenti. Questo rende la cache di Squid un possibile candidato ad un *RAID stripe* (livello 0), con vantaggi sia per le prestazioni (e la velocita' di navigazione e' uno dei motivi per cui si installa Squid) che per l'utilizzo estensivo dello spazio di storaggio. Questo fino al momento in cui per voi non sia piu' importante *garantire la disponibilita' del servizio* (se il RAID stripe dovesse rompersi gli utenti non potrebbero piu' navigare, cosa che per natura dello stripe e' maggiormente probabile rispetto  ad un *mirror* o a un filesytem *normale*)  con un RAID mirror o 5.
304
305 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):
306
307 /etc/fstab ::
308
309         ...
310         # Filesystem per Squid http cache
311         /dev/md3/       /var/spool/squid/       ext3,noexec,nosuid,noatime  0 3
312
313 Ora possiamo impostare la cache direttamente nel file ``/etc/squid3/squid.conf``::
314
315         #TAG: cache_dir (riga 1628)
316         #       Usage:
317         #
318         #       cache_dir Type Directory-Name Fs-specific-data [options]
319         #
320         #       You can specify multiple cache_dir lines to spread the
321         #       cache among different disk partitions.
322         #       ...
323         #Default:
324         # cache_dir ufs /var/spool/squid3 100 16 256
325         cache_dir aufs /var/spool/squid3 300 24 256
326         #         algoritmo
327         #              path della cache
328         #                                dimensione in MB
329         #                                    directory primo livello
330         #                                       secondo livello di directory 
331
332 Se si modifica la struttura del filesytem della cache di Squid, ad esempio variando il numero delle directory, puo' essere opportuno rigenerare la struttura della cache di squid (per lo meno se si *aumenta* il numero delle directory di primo o secondo livello). Tipicamente e' consigliabile cancellare (se si ha *ridotto* il numero delle diectory) la vecchia cache e poi generare una nuova struttura. Se si vuole *star nel sicuro* ogni volta che si modifica l'impostazione delle directory *si svuoti la vecchia cache e se ne generi una nuova* ::
333
334         # /etc/init.d/squid3 stop
335         # rm -r /var/spool/squid3/??
336         # squid3 -z
337         # /etc/init.d/squid3 start
338
339 TAG: maximum_object_size
340 ~~~~~~~~~~~~~~~~~~~~~~~~~~
341
342 Questa direttiva imposta la dimensione massima degli oggetti che vengono slvati sul supporto di storaggio, oggetti di dimensioni superiori saranno comunque scaricati ma non tenuti in cache.
343
344 TAG: maximum_object_size (1760)::
345
346         # TAG: maximum_object_size (1760)
347         #       Objects larger than this size will NOT be saved on disk.  The
348         #       value is specified in kilobytes, and the default is 4MB.  If
349         #       you wish to get a high BYTES hit ratio, you should probably
350         #       increase this (one 32 MB object hit counts for 3200 10KB
351         #       hits).  If you wish to increase speed more than your want to
352         #       save bandwidth you should leave this low.
353         #
354         #       NOTE: if using the LFUDA replacement policy you should increase
355         #       this value to maximize the byte hit rate improvement of LFUDA!
356         #       See replacement_policy below for a discussion of this policy.
357         #
358         #Default:
359         # maximum_object_size 4096 KB
360         maximum_object_size 150 MB
361         
362 TAG: cache_mem
363 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
364
365 *Cache_mem* imposta quanta memoria RAM venga utilizzata per la cache di Squid. 
366 Questo dipendera' dalla RAM disponibile sul sistema, e da quanta di questa volete mettere a disposizione di Squid (altri servizi iimportanti girano sulla stessa macchina?).
367 Questo paramentro influisce sulle prestazioni e sul degrado dei supporti di storaggio (sopratutto se magnetici).
368
369 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.
370
371 Se invece si disponesse di una macchina dedicata a Squid con gigabytes di RAM non si esiti a dedicarne buona parte a *cache_mem*.
372
373 TAG: cache_mem   (1566)::
374
375         #       'cache_mem' specifies the ideal amount of memory to be used
376         #       for:
377         #               * In-Transit objects
378         #               * Hot Objects
379         #               * Negative-Cached objects
380         #Default:
381         # cache_mem 8 M
382         cache_mem 100 M
383
384
385 TAG: minimum_object_size
386 ~~~~~~~~~~~~~~~~~~~~~~~~~~
387
388 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).
389
390 TAG: minimum_object_size::
391
392         #  TAG: minimum_object_size     (bytes)
393         #       Objects smaller than this size will NOT be saved on disk.  The
394         #       value is specified in kilobytes, and the default is 0 KB, which
395         #       means there is no minimum.
396         #
397         #Default:
398         # minimum_object_size 0 KB
399         minimum_object_size 0 KB
400
401 Negoziazione degli accesi al servizio
402 ---------------------------------------
403
404 Squid e' uno di quei servizi soggetto a problemi di tipo *open relay* , si deve quindi limitare la rete che puo' accedere al servizio. 
405
406 Open Relay:
407         Un servizio a cui possono accedere tutti indiscriminatamente.
408         La cosa puo' andare bene per servizi come i server web, che aspirano per loro natura
409         al maggior numero possibile di utenti, ma non a servizi come i proxy http oppure
410         ai server di posta elettronica (che permetterebbero l'invio di SPAM).
411
412 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*.
413
414 Per poter limitare gli accessi a Squid dal punto di vista dell'applicazione (quarto livello TCP/IP) si identifichera' inizialmente l'entita' *rete locale* (es: ``localnet``) con una ACL di tipo *src* (indirizi IP sorgenti) indicando la *classe / range di ip* della nostra rete.
415
416  Dopodiche l'accesso (``http_access``) si concedera' (*allow*) a questa entita' (es: ``localnet``) negando chiunque altro.
417
418 Per maggiori dettagli sulla sintassi utilizzabile per esprimere i range di ip: 
419 http://www.visolve.com/squid/squid24s1/access_controls.php
420
421
422 ACL e http access
423 ~~~~~~~~~~~~~~~~~~~~~
424 Si proceda a creare una ``ACL`` di tipo ``src`` per identificare la lostra rete locale, poi si abiliti l'accesso a questa con la direttiva ``http_access``. Tutto quanto non e' espressamente autorizzato viene poi negato da un ``http_access deny all`` finale.
425
426 ::
427
428         #  TAG: acl
429         #       Defining an Access List
430         #
431         #       Every access list definition must begin with an aclname and acltype,
432         #       followed by either type-specific arguments or a quoted filename that
433         #       they are read from.
434         #       ...
435         #       ***** ACL TYPES AVAILABLE *****
436         #
437         #       acl aclname src ip-address/netmask ...          # clients IP address
438         # riga 588
439         
440         # Example rule allowing access from your local networks.
441         # Adapt to list your (internal) IP networks from where browsing
442         # should be allowed
443         #acl localnet src 10.0.0.0/8    # RFC1918 possible internal network
444         #acl localnet src 172.16.0.0/12 # RFC1918 possible internal network
445         #acl localnet src 192.168.0.0/16        # RFC1918 possible internal network
446         #
447         acl localnet src 10.10.208.0/24    
448
449         # Riga 606
450         #  TAG: http_access
451         #       Allowing or Denying access based on defined access lists
452         #
453         #       Access to the HTTP port:
454         #       http_access allow|deny [!]aclname ...
455         #
456         #       NOTE on default values:
457         #
458         #       If there are no "access" lines present, the default is to deny
459         #       the request.
460         
461         # Riga 643
462         # INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS
463         
464         # Example rule allowing access from your local networks.
465         # Adapt localnet in the ACL section to list your (internal) IP networks
466         # from where browsing should be allowed
467         #http_access allow localnet
468         http_access allow localnet
469
470 Testare Squid
471 ---------------
472
473 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.
474
475
476 Client: ~/.wgetrc
477 ~~~~~~~~~~~~~~~~~~~
478
479 Nel file ``.wgetrc`` (si noti il punto iniziale: e' un file nascosto) si puo' impostare il proxy per wget. Si utililizzi l'indirizzo ip del server che si vuole testare, e si seguano i log ``/var/log/squid3/access.log`` sul server.
480
481 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``.
482
483 .wgetrc
484         http_proxy=10.10.208.178:3128
485
486 Si proceda a scaricare dal client scelto con un wget::
487
488         wget http://www.google.it
489
490 Server: access.log
491 ~~~~~~~~~~~~~~~~~~~~~
492
493 Si puo' controllare il corretto funzionamento del server seguendo i log di accesso a Squid::
494
495         # tail -f /var/log/squid3/access.log
496
497 In oltre e' possibile configurare diversi *analizzatori di log* come ``Webalizer`` per studiare i log di Squid.
498
499
500 Apache
501 ========
502
503 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.
504
505 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.
506
507 Pacchetti da installare::
508 ----------------------------
509
510          apache2 apache2-doc
511
512 Con la release 2.0 di Apache viene automaticamente resa disponibile anche la versione SSL (Secure Socket Layer, cpnnessioni criptate ) del web server.
513
514
515 Configurazione di Apache
516 ----------------------------
517
518 I file di configurazione di apache si trovano nella cartella: ``/etc/apache2`` e sono strutturati come descritto nel file 
519 ``/usr/share/doc/apache2/README.Debian.gz`` . Sostanzialmente lo schema e' il seguente:
520
521 apache2.conf
522           File di configurazione principale del servizio.
523
524           httpd.conf e' il vecchio file di configurazione di Apache1, presente per motivi di retrocompatibilita' e' generalemente vuoto.
525
526 ports.conf
527           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>``
528
529 sites-available
530           In questa cartella vengono raccolti i file di configurazione dei virtual host disponibili.
531
532 sites-enabled
533           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.
534
535 mods-available
536           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 .
537
538 mods-enabled
539           Moduli abilitati, effettivamente caricati.
540
541 apache.conf
542 ----------------
543
544 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.
545
546 Guardiamo alcune direttive interessanti:
547
548 Timeout
549                 Numero di secondi da aspettare prima di chiudere la connessione con il client. Questo parametro serve a liberare le risorse di sistema nel caso che un client, magar a causa di una connessione particolarmente lenta o instabili, tenga attivo indefinitivamente un processo di apache.
550
551 KeepAlive
552           L'estensione keep-alive (http 1.0) congiuntamente alle connessioni persistenti (http 1.1) permettono al server di rispondere a piu' richieste dei client mediante la stessa connessione. Il protocoll http per sua natura e' senza stato (*statelessi* ), quindi ogni risorsa richiesta (per pagine web si pensi ad esempio alle immagini) dal client necessita di una connessione autonoma. Keep-alive permette di ottimizzare la connessione anche fino al 50% a seconda delle situazioni e contenuti.
553
554 Server-Pool Size Regulation
555           Questi parametri (StartServers, MinSpareServers, ecc. Tutti spiegati nel manuale di apache) servono per attribuire le risorse di sistema disponibili al server Apache. Tenere questi parametri bassi serve a limitare il rischio di Denial of Service per il server, nel caso offra altri servizi. I settagi di default sono come sempre abbastanza conservativi, se si conta di usare il proprio Apache per servire un sito web con molti visitatori sara' necessario aumentare sensibilmente le impostazioni di base.
556
557 AccessFileName
558           Il nome del file che viene onorato per modificare le impostazioni per una singola directory, legato alla direttiva AllowOverride .
559
560 Installazione di PHP
561 ---------------------
562
563 Pacchetti da installare: ``php5 php-pear``
564
565 Test del modulo php
566 ~~~~~~~~~~~~~~~~~~~~
567
568 Creare nella cartella ``/var/www`` (o altra cartella visibile) un file con estensione \*.php (es ``/var/ww/info.php`` contenete codice php eseguibile dall'interprete, ad es::
569
570         <?php phpinfo() ; ?>
571
572 Questa funzione di php generera' la tipica pagina con le impostazioni attuali per PHP. Richiamando la pagina (es: ``http://localhost/info.php`` ) verra generata dall'interprete PHP la pagina HTML e resa disponibile tramite Apache ai utclient HTTP, a prova del correto funzionamento del modulo di PHP e della sua integrazione con il serv web Apache.  In caso contrario se il client http proporra di scaricare la pagina invece che visualizzarla nel browser: non funziona l'interprete di php o sono mal configurati i MIME-type. prima di tutto assicurarsi di aver fatoo ripartire Apache.
573
574 Installazione del supporto per Mysql
575 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
576
577 Installare i pacchetti::
578
579         php5-mysql phpmyadmin
580
581 Controllare tramite la pagina php.info che sia abilitato il supporto per Mysql (ripartito Apache, ricaricare la pagina e cercare con CTRL+f ``mysql``).
582
583 phpmyadmin
584 ~~~~~~~~~~~~~~~~~~~~~
585
586 L'interfaccia web Phpmyadmin non richede necessariamente la presenza di un database Mysql locale, puo' infatti essere utilizzata per gestire databases remoti (il suo file di configurazione: ``/etc/phpmyadmin/config.inc.php`` ). Nel caso si voglia installare localmente Mysql si utilizzi il pacchetto ``mysql-server`` .
587
588 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/`` .
589
590 Installazione del supporto per Postgresql
591 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
592
593 Installare i pacchetti::
594
595         php5-pgsql phppgadmin
596
597 Controllare tramite la pagina php.info che sia abilitato il supporto per PostgreSQL (ripartito Apache, ricaricare la pagina e cercare con CTRL+f ``pgsql``).
598
599
600 phppgadmin
601 ~~~~~~~~~~~~~~~~~~~~~
602
603 L'interfaccia web Phppgadmin per il database server PostgreSQL non richede necessariamente la presenza di un database locale, puo' infatti essere utilizzata per gestire databases remoti (il suo file di configurazione: ``/etc/phppgadmin/config.inc.php`` ). Nel caso si voglia installare localmente Mysql si utilizzi il pacchetto ``postgresql`` .
604
605 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/`` .
606
607 Virtual hosts
608 --------------------
609
610   * http://www.apacheweek.com/features/vhost
611
612   * http://www.onlamp.com/pub/a/apache/2004/01/08/apacheckbk.html
613
614 I virtual host permettono di avere piu' siti internet disponibili tramite lo stesso server web, eventualmente mappati su un solo indirizzo ip. Sono generalemente di due tipi:
615
616         * Basati su *indirizzi ip*. 
617           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.
618
619         * Basati su *nomi di dominio* che puntano allo stesso ip.
620           Soluzione piu' economica e diffusa che si basa sulle funzionalita' di http 1.1 . 
621
622 Prenderemo in esame la gestione di virtual hosts basati su nomi di dominio.
623
624 Gestione DNS
625 ~~~~~~~~~~~~~~~
626
627 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:
628
629          *Bind* (DNS server)
630           Impostare i campi A nelle proprie zone gestite dal server dns Bind. Ad es: ``papo            A       212.22.136.248``
631
632          *Servizio DNS dinamico on line*.
633           Utilizzare un servizio come ad es: https://www.dyndns.com/ per mappare nomi di dominio sul proprio indirizzo ip, comodo ad esempio se si dispone di un indirzzo ip pubblico (anche se dinamico) per la propria connessione ad internet.
634
635          *Dnsmasq* (DNS server)
636           Utilizzabile a livello locale per fare dei test, utilizzando direttive come: ``address=/davide.piffa.net/10.10.208.178``
637
638          ``/etc/hosts``
639           Per prove *strettamente a livello locale* potete impostare i nomi dei vostri virtual server nel file /etc/hosts .
640
641 ::
642
643     # dig 177.piffa.net
644
645     ; <<>> DiG 9.5.1-P1 <<>> 177.piffa.net
646     ;; global options:  printcmd
647     ;; Got answer:
648     ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38036
649     ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
650     
651     ;; QUESTION SECTION:
652     ;177.piffa.net.                 IN      A
653     
654     ;; ANSWER SECTION:
655     177.piffa.net.          0       IN      A       10.10.208.177
656     
657     ;; Query time: 12 msec
658     ;; SERVER: 10.10.208.254#53(10.10.208.254)
659     ;; WHEN: Wed May  6 12:27:08 2009
660     ;; MSG SIZE  rcvd: 47
661
662 La parte interessante e' ``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`` .
663
664 Virtual host
665 ~~~~~~~~~~~~~~
666
667 Esempio di Virtual host::
668
669         <VirtualHost *:80 >
670             ServerName 177.piffa.net
671             DocumentRoot /var/www/177.piffa.net/
672             ServerAdmin webmaster@177.piffa.net
673         </VirtualHost>
674
675 1. ``<VirtualHost \*:80 >``  La prima riga indica l'inizio della stanza relativa al nostro virtual host, che ascolotera' su qualunque indirizzo ip (nel caso il server abbia piu' indirizzi dai quali e' raggiungibile) sulla porta ``80``.
676 2. ``Server/name`` precisa quale sara' il nome di dominio a cui verra' associato questo sito rispetto ad altri eventualmenti presenti sullo stesso server web.
677 3. ``DocumentRoot`` : il path della directory che contiene le pagine del sito.
678 4. ``ServerAdmin``: l'indirizzo del webmaster, in modo da poterlo contattare in caso di problemi col sito.
679 5. ``</VirtualHost>``: *tag* di chiusura della stanza di definizione del virtual host.
680
681 Quelle che abbiamo appena visto sono le direttive essenziali per definire un sito virtuale, potrebbe essere utile aggiungene altre:
682
683 * ``ErrorLog /var/log/apache2/177.piffa.net/error.log``
684         Log degli errori separato dai restanti siti web ospitati dal server.
685         
686 * ``LogLevel warn``
687         Livello di importanza degli eventi loggati= warning *attenzione* . 
688
689 * ``CustomLog /var/log/apache2/177.piffa.net/access.log combined``
690         Log di accesso separati dagli altri siti, utile anche qua per statistiche di accesso per il solo sito virtuale.
691
692
693 Potrebbe essere utile modificare le impostazioni di una intera directory, ad esempio per abilitare l'``AuthConfig``::
694
695         <Directory "/var/www/miosito.net/privata">
696                 AllowOverride AuthConfig
697                 Options ExecCGI Indexes MultiViews FollowSymLinks
698                 Order allow,deny
699                 Allow from all
700         </Directory>
701
702 ``AllowOverride AuthConfig`` ora vale per l'intera directory, come le altre opzioni.
703
704 Negoziazione accessi
705 ---------------------
706
707 Tipicamente quando si installa un server web il proprio desiderio e' di dare accesso ai materiali disponibili al maggior numero di visitatori possibile. Talvolta pero' puo essere utile o necessario limitare gli accessi, ad esempio per escludere un *bot* indesiderato che scansiona ininterottamente le nostre pagine o per creare una *Area Riservata* i cui materiali non devono essere disponibile a tutti.
708
709 Limiti su base ip
710 ~~~~~~~~~~~~~~~~~~~~~~
711
712 La forma piu' semplice di restrizine degli accessi e' su base degli indirizzi IP dei client: tipicamente i siti web sono settati per dare accesso a chiunque::
713
714          <VirtualHost *:80 >
715                 # ...
716                 <Directory "/var/www/177.piffa.net">
717                 Order allow,deny
718                 Allow from all
719                 </Directory>
720          </VirtualHost>
721
722 Potremmo negare l'accesso a uno o piu' indirizzi IP in questo modo::
723
724          <VirtualHost *:80 >
725                 <Directory "/var/www/177.piffa.net">
726                 Order allow,deny
727                 Allow from all
728                 Deny from 192.168.0.1
729                 </Directory>
730          </VirtualHost>
731
732 Ora l'IP 192.168.0.1 non potra' piu' accedere ai materiali dell'intero sito virtuale, oppure potremmo lavorare su una sola directory::
733
734          <Directory "/var/www/miosito.net/limitata">
735                 Order allow,deny
736                 Allow from 192.168.0.0./24
737                 Deny from all
738          </Directory>
739
740 In questo modo solo la classe IP ``192.168.0.0/24`` potra' accedere alla directory ``/limitata``
741 Si tenga pero' conto che e' relativamente facile per un malintenzionato cambiare il propio indirizzo ip, oppure collegarsi da un altra zona. Meno facile e' accedere ad una classe privata trovandosi all'esterno di questa, ma e' comunque possibile mandare delle richieste ``GET`` per cercare di mandare in Denial Of Service il webserver.
742
743
744 User Authentication
745 ---------------------
746
747 A volte conviene negoziare gli accessi ad un area di un sito tramite autenticazione basata sull'accopiata *nome utente / password*. Questo puo' venire utile per creare una area download *intranet*, alla quale possano accedere solo gli utenti previsti a prescindere dagli indirizzi IP dei loro client. Per quanto esistano soluzioni piu' granulari e sofisticate per ottenere questo, *mod-auth* puo'essere sufficente. E mod auth non richiede l'installazione di software aggiuntivi.
748
749
750 link: http://www.apacheweek.com/features/userauth
751
752 Definire la cartella
753 ~~~~~~~~~~~~~~~~~~~~~~
754
755 Decidere quale sara' il *path* della cartella da sottoporre ad autentizazione:(e creiamo la cartella):
756
757         ``mkdir /var/www/177.piffa.net/privata``
758
759 Creazione del database delle passwords
760 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
761
762 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. 
763
764 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.
765
766 Creiamo (con il *flag* ``-c``) il file ``/home/utente/passwords`` con l'utente ``luca``::
767  
768         htpasswd -c /home/utente/passwords luca
769         
770 ``htpasswd`` ci chedera' la password da associare all'utente ``luca``. Per sucessive modifiche della password o aggiunta di nuovi utenti non sara' necessario usare il flag ``-c``.
771
772 Configurazione di Apache
773 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
774
775 Ora possiamo passare alla configurazione vera e propria di Apache, ma con una novita': andremo a inserire la voce in un ``.htaccess`` invece che modificare il file di impostazione del virtual-host.
776
777 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.
778
779 Dando agli utenti la possibilita' di modificare (*AllowOverride*) autonomamente alcuni parametri (in questo caso solo l'*AuthConfig*) relativi al funzionamenteo del loro spazio web ci togliera' l'incombenza di dover intervenire suii vari virtual host.
780
781 Abilitiamo l'AllowOverride nel file di configurazione del virtual host per la sola directory ``privata``::
782
783         <VirtualHost *:80 >
784             ServerName 177.piffa.net
785             DocumentRoot /var/www/177.piffa.net/
786             ServerAdmin webmaster@177.piffa.net
787             <Directory "/var/www/177.piffa.net/privata">
788                 AllowOverride AuthConfig
789             </Directory>
790         </VirtualHost>
791
792 Per rendere il cambiamento effettivo sara' necessario fare un restart / reload di Apache.
793
794 Ora sara' possibile, anche per l'utente di sistema, creare un fie ``.htaccess`` che sara' onorato da Apache.
795
796 /var/www/177.piffa.net/privata/.htaccess ::
797
798         # Questo file viene incluso
799         # nella configurazione del sito web
800         # Messaggio visualizzato al prompt per l'autenticazione
801         AuthName "Area privata soggetta ad autentizazione"
802         # tipo di autenticazione da usarsi
803         AuthType Basic
804         # File generato precedentemente con htpasswd
805         AuthUserFile  /home/utente/passwords
806         
807         # Negoziazione degli accessi
808         # valid users permette l'accesso agli utenti specificati
809         # nel file generato da htpasswd
810         require valid-user
811
812 Si noti che non e' necessario fare ripartire Apache per onorare i cambiamenti (un utente non avrebbe la possibilita' di farlo!).
813
814
815 Cavets
816 -----------
817
818 Problemi di cache:
819         
820         * 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.
821
822         *  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.
823
824 Domain Name System
825 ====================
826
827 Domain Name System (spesso indicato con DNS) e' un servizio utilizzato per la risoluzione di nomi di host in indirizzi IP e viceversa. Il servizio e' realizzato tramite un database distribuito, costituito dai server DNS.
828
829 Il nome DNS denota anche il protocollo che regola il funzionamento del servizio, i programmi che lo implementano, i server su cui questi girano, l'insieme di questi server che cooperano per fornire il servizio.
830
831 I nomi DNS, o "nomi di dominio", sono una delle caratteristiche piu' visibili di Internet.
832
833 C'e' confusione in merito alla definizione dell'acronimo: la S spesso viene interpretata come service, ma la definizione corretta e' system.
834
835 L'operazione di convertire un nome in un indirizzo e' detta risoluzione DNS, convertire un indirizzo IP in nome e' detto risoluzione inversa.
836
837 Nomi di dominio
838 -----------------
839
840 Un nome a dominio e' costituito da una serie di stringhe separate da punti, ad esempio it.wikipedia.org. A differenza degli indirizzi IP, dove la parte piu' importante del numero e' la prima partendo da sinistra, in un nome DNS la parte piu' importante e' la prima partendo da destra. Questa e' detta dominio di primo livello (o TLD, Top Level Domain), per esempio .org o .it.
841
842 Un dominio di secondo livello consiste in due parti, per esempio wikipedia.org, e cosi' via. Ogni ulteriore elemento specifica un'ulteriore suddivisione. Quando un dominio di secondo livello viene registrato all'assegnatario, questo e' autorizzato a usare i nomi di dominio relativi ai successivi livelli come it.wikipedia.org (dominio di terzo livello) e altri come some.other.stuff.wikipedia.org (dominio di quinto livello) e cosi' via.
843
844
845 Tipologie di record
846 -----------------------
847
848 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:
849
850 * 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).
851 * Record MX - (Mail eXchange) indica a quali server debba essere inviata la posta elettronica per un certo dominio.
852 * 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.
853 * 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).
854 * Record AAAA - Restituisce un indirizzo IPv6.
855 * Record SRV - Identificano il server per un determinato servizio all'interno di un dominio. Possono essere considerati una generalizzazione dei record MX.
856 * Record TXT - Associano campi di testo arbitrari ad un dominio. Questi campi possono contenere una descrizione informativa oppure essere utilizzati per realizzare servizi.
857
858 Vi sono anche tipi di record "di servizio", necessari al funzionamento del database distribuito:
859 * Record NS - Utilizzato per indicare quali siano i server DNS autoritativi per un certo dominio, ovvero per delegarne la gestione.
860 * Record SOA - (Start of Authority) usato per la gestione delle zone DNS.
861
862 Utilizzo
863 ------------
864
865 I computer vengono identificati in rete grazie agli indirizzi *IP*, questi pero' non sono comodi per gli utenti come riferimento per i vari server. Ad esempio sarebbe scomodoriferirsi al motore di ricerca Goggle con uno dei suoi IP: ``74.125.43.104``, e' preferibile usare il nome di dominio *www.google.com*::
866
867         ping -c 1 www.google.com
868         PING www.l.google.com (74.125.43.104) 56(84) bytes of data.
869
870 Risoluzione dei nomi di dominio
871 ----------------------------------
872
873 Ci sono vari strumenti per interrogare i server DNS e ottenere l'indirizzo IP associato al nome di dominio che ci interessa::
874
875   $ host www.piffa.net
876   www.piffa.net is an alias for piffa.net.
877   piffa.net has address 65.98.21.97
878   piffa.net mail is handled by 10 65.98.21.97
879
880
881   $ nslookup www.piffa.net
882   Server:         192.168.0.10
883   Address:        192.168.0.10#53
884   
885   Non-authoritative answer:
886   www.piffa.net   canonical name = piffa.net.
887   Name:   piffa.net
888   Address: 65.98.21.97
889
890
891   $ dig www.piffa.net
892   
893   ; <<>> DiG 9.6.0-P1 <<>> www.piffa.net
894   ;; global options: +cmd
895   ;; Got answer:
896   ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47751
897   ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 4
898   
899   ;; QUESTION SECTION:
900   ;www.piffa.net.                 IN      A
901   
902   ;; ANSWER SECTION:
903   www.piffa.net.          3489    IN      CNAME   piffa.net.
904   piffa.net.              3489    IN      A       65.98.21.97
905   
906   ;; AUTHORITY SECTION:
907   piffa.net.              86289   IN      NS      ns2.mydomain.com.
908   piffa.net.              86289   IN      NS      ns1.mydomain.com.
909   piffa.net.              86289   IN      NS      ns4.mydomain.com.
910   piffa.net.              86289   IN      NS      ns3.mydomain.com.
911   
912   ;; ADDITIONAL SECTION:
913   ns1.mydomain.com.       96208   IN      A       64.94.117.193
914   ns2.mydomain.com.       96208   IN      A       64.94.31.67
915   ns3.mydomain.com.       96208   IN      A       66.150.161.137
916   ns4.mydomain.com.       96208   IN      A       63.251.83.74
917   
918   ;; Query time: 1 msec
919   ;; SERVER: 192.168.0.10#53(192.168.0.10)
920   ;; WHEN: Sun May 10 21:23:11 2009
921   ;; MSG SIZE  rcvd: 209
922
923 Lo strumento piu' esaustivo e' ``dig``, installabile con il pacchetto ``dnsutils`` .
924
925 Dig
926 -----
927
928 Vediamo alcune opzioni utili nell'utilizzo di ``dig`` per l'inerrogazione dei DNS Server::
929
930
931         $ dig www.google.it
932         
933         ; <<>> DiG 9.6.0-P1 <<>> www.google.it
934         ;; global options: +cmd
935         ;; Got answer:
936         ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18816
937         ;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 7, ADDITIONAL: 0
938         
939         ;; QUESTION SECTION:
940         ;www.google.it.                 IN      A
941         
942         ;; ANSWER SECTION:
943         www.google.it.          250683  IN      CNAME   www.google.com.
944         www.google.com.         334819  IN      CNAME   www.l.google.com.
945         www.l.google.com.       186     IN      A       74.125.43.103
946         www.l.google.com.       186     IN      A       74.125.43.104
947         www.l.google.com.       186     IN      A       74.125.43.147
948         www.l.google.com.       186     IN      A       74.125.43.99
949         
950         ;; AUTHORITY SECTION:
951         l.google.com.           80856   IN      NS      f.l.google.com.
952         l.google.com.           80856   IN      NS      d.l.google.com.
953         l.google.com.           80856   IN      NS      b.l.google.com.
954         l.google.com.           80856   IN      NS      c.l.google.com.
955         l.google.com.           80856   IN      NS      a.l.google.com.
956         l.google.com.           80856   IN      NS      e.l.google.com.
957         l.google.com.           80856   IN      NS      g.l.google.com.
958         
959         ;; Query time: 1 msec
960         ;; SERVER: 192.168.0.10#53(192.168.0.10)
961         ;; WHEN: Sun May 10 21:34:47 2009
962         ;; MSG SIZE  rcvd: 255
963
964 $ dig
965         (semza opzioni o oggetti) Fornisce l'elenco dei *root servers* utilizzati. I root server sono i server che mantengono le informazioni sui domini di primo livello (TLD) e sono quindi il punto di partenza per scorrere nella directory dei DNS per recuperare le informazioni (tipicamente un campo ``A`` per un indirizzo IP) che ci servono per raggiungere un certo servizio.
966
967 $ dig
968
969         ...
970         
971         ;; ANSWER SECTION:
972         .                       192032  IN      NS      C.ROOT-SERVERS.NET.
973         .                       192032  IN      NS      E.ROOT-SERVERS.NET.
974         .                       192032  IN      NS      B.ROOT-SERVERS.NET.
975         .                       192032  IN      NS      L.ROOT-SERVERS.NET.
976         .                       192032  IN      NS      A.ROOT-SERVERS.NET.
977         .                       192032  IN      NS      F.ROOT-SERVERS.NET.
978         .                       192032  IN      NS      H.ROOT-SERVERS.NET.
979         .                       192032  IN      NS      G.ROOT-SERVERS.NET.
980         .                       192032  IN      NS      K.ROOT-SERVERS.NET.
981         .                       192032  IN      NS      M.ROOT-SERVERS.NET.
982         .                       192032  IN      NS      I.ROOT-SERVERS.NET.
983         .                       192032  IN      NS      J.ROOT-SERVERS.NET.
984         .                       192032  IN      NS      D.ROOT-SERVERS.NET.
985         
986         ...
987
988 dig @nome_dns 
989         Permette di fare una query ad un server dns particolare. 
990         Es: ``dig @151.99.25.1 www.google.it``
991
992 dig MX www.google.it
993         Chiede un campo in particolare, in questo caso il campo MX
994
995 dig ANY www.google.it
996         Chiede tutti i campi, non solo i campi *a*
997
998 dig -x 74.125.43.104
999         Effettua una richiesta inversa: dall'ip al PTR associato.
1000
1001 resolv.conf
1002 -----------------
1003
1004 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.
1005
1006 /etc/resolv.conf:
1007
1008         - ``nameserver``: indica il nameserver da utilizzare, indicato con l'indirizzo ip.
1009
1010         - ``domain``: indica il nome di dominio della rete attuale, vedi voce sucessiva.
1011
1012         - ``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``.
1013
1014
1015 Si veda anche la pagina man di resolv.conf.
1016
1017 Attenzione: se si usa un client DHCP o simile questo file potra' essere riscritto automaticamente in base a quanto ottenuto dal DHCP. Si veda la documentazione del pacchtto ``resolvconf``.
1018
1019
1020 /etc/hosts
1021 ---------------
1022
1023 Tabella statica per l'associazione tra IP e nomi di dominio::
1024
1025 # cat /etc/hosts
1026
1027         127.0.0.1       localhost.localdomain   localhost
1028         10.10.208.162   daniela         daniela.piffa.net
1029         10.10.208.254   mirror          mirror.piffa.net
1030         91.191.138.15   thepiratebay.org
1031         192.168.0.11    chrome  chrome.mydomain.com
1032
1033 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.
1034
1035 Il problema e' la gestione di questo file: quando gli host cambiano IP si devono aggiornare i records, e c'e' poi il problema di distribuire questo file tra i vari hosts della propia LAN. Un metodo semplice per distribuire questo file e' utilizzare ``Dnsmasq``: questo infatti legge e onora il file ``hosts`` locale e lo *distribuisce* ai clients.
1036
1037 Modificare (riconducendola a un ip interno, cosi' annullandola) la risoluzione di un nome di dominio e' un modo drastico e funzionale per *annullarlo* rendendolo indisponibile alla propia rete locale, ad esempio aggiungere al file ``/etc/hosts``::
1038         
1039          127.0.0.1       www.facebook.com 
1040
1041 Impedira' agli utenti della LAN di raggiungere *facebook*, ora reindirizzato a i``localhost``.
1042
1043
1044 Hostname
1045 ------------
1046
1047 Ogni computer ha un *propio nome* visualizzabile (e modificabile) con il comando ``hostname``.
1048
1049 Per modificare in modo permanente il nome del computer si modifichi il contenuto del file ``/etc/hostname``.
1050
1051 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.
1052 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::
1053
1054         * Squid: ``visible_hostname``
1055
1056         * Postfix: ``myhostname``
1057
1058         
1059 DNSmasq
1060 ========
1061
1062 Dnsmasq puo' svolgere le funzioni di  un DNS cache / forwarder e un server DHCP caratterizzato dalla facilita' di configurazione, dalla leggerezza e dalla possibilita' di modificare rapidamente i record DNS serviti alla rete. Puo' essere anche utilizzato come `server per il boot da rete <http://www.debian-administration.org/articles/478>_` .
1063
1064 Dnsmasq e' un interessante alternativa all'uso del server DNS Bind in modalita' cache-only (non autoritativo) accompagnato dal server DHCPD. I vantaggi sono:
1065
1066 - Leggerezza: puo' essere fatto girare su una macchina relativamente debole in caso di bisogno.
1067 - Rapidita' di configurazione (in particolare per servire dei record A / MX alla rete, modificando al volo i valori originali ospitati sul server DNS Publico).
1068 - Ben integrato con connssioni PPP (utile se dovete rendere disponibile rapidamente una connessione a internet a una rete in difficolta').
1069
1070 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. 
1071 Molto utile per scopi didattici, sopratutto per testare server SMTP impostando al volo i campi MX per nomi di dominio fittizi.
1072
1073
1074 Configurazione
1075 -----------------
1076
1077 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:
1078
1079
1080 domain-needed
1081         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* .
1082
1083
1084 bogus-priv
1085         Simile alla voce precedente ma per i reverse look-up.
1086
1087
1088 domain
1089         Nome di dominio della rete da passare ai client.
1090
1091
1092 expand_hosts
1093         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.
1094
1095
1096 DHCP
1097 -----------
1098
1099 Per attivare il demone DHCP di dnsmaq basta aggiungere al file di configurazione il *range* degli ip che si vuole assegnare ai client con il *lease time* (tempo di rilascio: quanto a lungo saranno validi gli ip assegnati) espresso in ore.
1100
1101 Si faccia *attenzione*: in una rete puo' esseere presente **un solo server DHCP**, o per meglio dire qualunque server DHCP ascolta sul broadcast ``255.255.255.255`` e potrebbe rispondere a un pacchetto di richesta DHCP. Quindi non fate partire inavvertitamente un server DHCP in una rete gia' servita e **non vi azzardate ad andare in giro con un portatile con un server DHCP attivo** nelle reti altrui. Questo vale anche per i laboratori di informatica dei corsi di reti: non fate partire il vostro server DHCP se siete collegati alla rete interna!
1102
1103 /etc/dnsmasq.conf (riga 118)::
1104
1105         dhcp-range=192.168.0.20,192.168.0.50,24h 
1106
1107 DNS cache
1108 -----------
1109
1110 Aggiungere al file ``/etc/resolv.conif`` il nameserver localhost in cima alla lista dei *nameserver* disponibili. Dnsmasq usera' la propia cache e in caso non abbia disponibile il *record DNS* richiesto fara' partire una query al primo DNS::
1111         
1112         nameserver      127.0.0.1
1113
1114
1115 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`` ::
1116
1117         prepend domain-name-servers 127.0.0.1;
1118
1119 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!).
1120
1121
1122 DHCPd
1123 ---------
1124
1125 Dnsmasq puo' lavorare anche come DHCP server per la vostra LAN.
1126
1127 Samba
1128 ======
1129
1130 Samba e' un progetto libero che fornisce servizi di condivisione di file e stampanti a client SMB/CIFS.
1131
1132 Samba e' liberamente disponibile, al contrario di altre implementazioni SMB/CIFS, e permette di ottenere interoperabilita' tra Linux, Unix, Mac OS X e Windows.
1133
1134 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.
1135
1136 Pacchetti
1137 --------------
1138
1139 Pacchetti da installare per utilizzare Samba in modalita' client [#]_ ::
1140
1141         samba-client
1142
1143 Pacchetti da installare per utilizzare Samba in modalita' server::
1144
1145         samba smbfs smbclient
1146
1147 .. [#] 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``.
1148
1149 Durante la prima installazione viene chiesto il nome del gruppo di appartenenza, il default per Windows e' ``WORKGROUP``. In aula usiamo invece ``208`` . 
1150
1151 Per riconfigurare Samba si usi il comando::
1152
1153         dpkg-reconfigure samba-common
1154
1155 Passwords e autenticazione
1156 ---------------------------
1157         
1158 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:
1159
1160 1 Sistema \*Unix ( GNU/Linux )
1161           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 propieta' dei *punti di mount**.
1162           Queste passwords sono salvate nel solito file /etc/shadow (richiamato da /etc/passwd).
1163
1164 2 Password per l'applicativo Samba
1165           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`` .
1166
1167 3 Password per Windows.
1168           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.
1169
1170
1171 Creazione Utenti
1172 -------------------
1173
1174 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!
1175
1176 Creazione di un utente denominato sambo::
1177         
1178         adduser --shell /bin/false sambo
1179
1180 Nel file ``/etc/passwd`` avremo qualcosa come::
1181
1182         sambo:x:1001:1001:Sambo utente Samba,,,:/home/sambo:/bin/false
1183
1184
1185 Aggiunta dell'utente al database delle password per Samba e generazione della sua password::
1186         
1187         smbpasswd -a sambo
1188
1189 Se successivamente si vorra' modificare la password di un utente gia' esistente si usi::
1190
1191         smbpasswd  sambo
1192
1193
1194 La password sotto Windows verra' modificata sul sistema Windows.
1195
1196 Creare la condivisione
1197 ------------------------
1198
1199 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.
1200
1201 Creazione della risorsa sambo_share nella home dell'utente sambo::
1202
1203         # mkdir /home/sambo/sambo_share
1204         # chown sambo:sambo /home/sambo/sambo_share/
1205
1206 Sicurezza: permessi di esecuzione sul server
1207 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1208
1209 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. 
1210 Si potrebbe avere quindi, ipotizzando una condivisione in ``/mnt/share`` che risieda su di un file system dedicato:
1211
1212 ``/etc/fstab`` 
1213
1214         /dev/hda10       /mnt/share      ext3    rw, **nosuid,noexec**  0  3
1215
1216 Si noti anche l'uso di *nosuid* per evitare la possibilita' di eseguire programmi con credenziali diverse.
1217
1218 Configurazione dell'applicativo Samba vero e proprio.
1219 ------------------------------------------------------
1220
1221 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.
1222
1223
1224 /etc/samba/smb.conf riga ~235 , Share Definitions (in vim si usi 235gg )::
1225
1226     [sambo_share]
1227             # Percorso della cartella condivisa
1228             path = /home/sambo/sambo_share
1229             # Se gli utenti possono scrivere / modificare file
1230             writable = yes
1231             # Negoziazione degli accessi su base utenti / passwords
1232             valid users = sambo
1233
1234             # ####################################### 
1235             # Altri parametri opzionali di interesse
1236             # Se posso vedere la condivisione da esplora risorse
1237             # anche se non ho i privilegi per accedervi.
1238             browseable = yes
1239             # Commento indicativo della risorsa
1240             comment = Condivisione per Sambo
1241
1242 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`` .
1243
1244
1245 Testare il Servizio
1246 --------------------
1247
1248 Come testare il servizio
1249
1250 es::
1251         
1252          smbclient -U sambo -L localhost
1253
1254 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::
1255
1256         Sharename       Type      Comment
1257         ---------       ----      -------
1258         sambo_share     Disk      Condivisione per Sambo
1259         print$          Disk      Printer Drivers
1260         IPC$            IPC       IPC Service (base server)
1261         sambo           Disk      Home Directories
1262
1263 In particolare l'ultima voce relativa alla home directory dell'utente dovrebbe essere visibile solo agli utenti autenticati.
1264
1265 In alternativa e' possibile montare realmente la condivisone anche su GNU/Linux tramite un client per samba e testarne il corretto funzionamento::
1266
1267         mount -t smbfs //localhost/sambo_share /mnt/sambo_mount/ --verbose -o user=sambo 
1268
1269 Server di posta: Postfix
1270 ============================
1271
1272 Il server di posta che prenderemo in considerazione e' Postfix, a seguire un estratto di un file do configurazione *semplie* con l'abilizazione delle *Maildir* nelle ``/home`` degli utenti per la consegna della posta:
1273
1274 ``/etc/postfix/main.cf``::
1275
1276         # ...segue dalla riga ~30
1277         myhostname = 162.piffa.net
1278         alias_maps = hash:/etc/aliases
1279         alias_database = hash:/etc/aliases
1280         myorigin = 162.piffa.net
1281         mydestination = 162.piffa.net, localhost
1282         # Se non avete un ip pubblico e statico, con un adeguato record PTR
1283         # dovrete usare un realy host per l'invio della posta
1284         relayhost = smtp.piffa.net
1285         mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
1286
1287         # Per effettuare lo storaggio della posta nelle home directory degli utenti
1288         # in una Maildir invece che la Mailbox in /var/mail/utente
1289         # si disabiliti procmail
1290         #mailbox_command = procmail -a "$EXTENSION"
1291
1292         # Storaggio della posta nella _cartella_ Maildir/ (si noti lo slash)
1293         # nella home dell'utente:
1294         home_mailbox = Maildir/
1295         mailbox_size_limit = 0
1296         recipient_delimiter = +
1297         inet_interfaces = all
1298
1299
1300 Imap e pop
1301 ------------------
1302
1303 Postfix e' un server SMTP, di conseguenza se volete che i vostri utenti possano *scaricare* in locale la posta generalemtne volete mettere a loro disposizione un server *POP3* o ancora meglio *IMAP*. Oppure entrambi.
1304
1305 Pacchetti da installare 
1306         courier-imap courier-pop
1307
1308 i noti che IMAP necessita delle Maildir, non funziona con le Mailbox in ``/var/mail/`` .
1309
1310
1311 Web client
1312 ~~~~~~~~~~~~~~~
1313
1314 Per mettere a disposizione degli utenti un client web per gestire la propia posta si installi il pacchetto: ``squirrelmail`` . Ci sono tanti altri client web disponibili: questo e' particolarmente semplice. Naturalemte dovrete aver installato: ``php5 apache2`` .
1315
1316 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::
1317
1318         cd /etc/apache2/conf.d/
1319         ln -s /etc/squirrelmail/apache.conf ./
1320
1321
1322
1323 Firewall
1324 ==========
1325
1326 In Informatica, nell'ambito delle reti di computer, un firewall (termine inglese dal significato originario di parete refrattaria, muro tagliafuoco, muro ignifugo; in italiano anche parafuoco o parafiamma) e' un componente passivo di difesa perimetrale che può anche svolgere funzioni di collegamento tra due o piu' tronconi di rete. Usualmente la rete viene divisa in due sottoreti: una, detta esterna, comprende l'intera Internet mentre l'altra interna, detta LAN (Local Area Network), comprende una sezione piu' o meno grande di un insieme di computer locali. In alcuni casi e' possibile che si crei l'esigenza di creare una terza sottorete detta DMZ (o zona demilitarizzata) atta a contenere quei sistemi che devono essere isolati dalla rete interna ma devono comunque essere protetti dal firewall.
1327
1328 Una prima definizione chiusa di firewall è la seguente:
1329
1330 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.
1331
1332 In realtà un firewall può essere realizzato con un normale computer (con almeno due schede di rete e software apposito), può essere una funzione inclusa in un router o può essere un apparato specializzato. Esistono inoltre i cosiddetti "firewall personali", che sono programmi installati sui normali calcolatori, che filtrano solamente i pacchetti che entrano ed escono da quel calcolatore; in tal caso viene utilizzata una sola scheda di rete.
1333
1334 La funzionalità principale in sostanza è quella di creare un filtro sulle connessioni entranti ed uscenti, in questo modo il dispositivo innalza il livello di sicurezza della rete e permette sia agli utenti interni che a quelli esterni di operare nel massimo della sicurezza. Il firewall agisce sui pacchetti in transito da e per la zona interna potendo eseguire su di essi operazioni di:
1335 controllo
1336 modifica
1337 monitoraggio
1338
1339 Questo grazie alla sua capacità di "aprire" il pacchetto IP per leggere le informazioni presenti sul suo header, e in alcuni casi anche di effettuare verifiche sul contenuto del pacchetto.
1340
1341 Links
1342 ------
1343
1344 * http://openskill.info/topic.php?ID=124
1345 * http://iptables-tutorial.frozentux.net/iptables-tutorial.html
1346
1347 Ipfilter
1348 ----------
1349
1350 Link: http://iptables-tutorial.frozentux.net/iptables-tutorial.html#IPFILTERING
1351
1352 Natura di un firewall ip: su cosa lavora (livello 2 e un po' del 3) e su cosa *non* lavora (livello 4).
1353 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.
1354
1355 Netfilter non ricostruisce il flusso di dati tra pacchetti, non puo' quindi rilevare la presenza di virus o simili che si trasmettono su pacchetti separati: ricomporre, analizzare e tornare a scomporre i frammenti rtichiederebbe troppa RAM e risorse di sistema, con il conseguente rischio di saturare il firewall fino all'abbandono dei nuovi pacchetti in transito.
1356 Ci sono altri software piu' adatti a questi compiti, ad esempio un proxy HTTP come Squid che e' appunto una applicazione di quarto livello, progettata e strutturata per analizzare e modificare i flussi di dati (il *contenuto* dei pacchetti, non le sole *inestazioni*) facendo abbondate uso delle risorse RAM e di calcolo del sistema. Non a caso su macchine embedded dalle prestazioni molto ridotte (CPU ARM ~250Mhz con ~30MB di RAM) Squid sfrutta al massimo le risorse di sistema per gestire il traffico di una rete 10/100, mentre il lavoro tipico svolto da netfilter e' quasi irrilevante.
1357
1358 Progettazione di un firewall
1359 -----------------------------
1360
1361 Per implementare un firewall bisogna decidere un aio di cose: la collocazione e l'approccio (inclusivo o esclusivo) al filtraggio, il tipo di hardware.
1362
1363 Collocazione
1364 ~~~~~~~~~~~~~
1365
1366 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.
1367
1368 Collocazione:
1369
1370         1. sul router
1371         2. tra router e servers / LAN
1372         3. Unico server / router / firewall e connessi rischi. considerare l'acquisto di un router hardware dedicato.
1373         
1374 Layeed security:
1375         Implementare piu' device / software sui diversi livelli: http://iptables-tutorial.frozentux.net/iptables-tutorial.html#HOWTOPLANANIPFILTER
1376
1377
1378 Policy di default
1379 ~~~~~~~~~~~~~~~~~~~
1380
1381 Drop o Accept: conseguenze per sicurezza, facilita' di gestione.
1382
1383
1384 Hardware
1385 ~~~~~~~~~~~~
1386
1387 Sostanzialmente potremmo distinquere due tipologie di hardware:
1388
1389 Network appliance dedicata::
1390         Un dispositivo hardware dedicato alla funzione di Firewall, ad es un Cisco / Fortigate.
1391         Si noti che molti firewall economici altro non sono che Linux box molto striminzite.
1392
1393 Server / Personal computer:
1394         Un server sul quale viene fatto girare Netfilter ad uso del server stesso e della rete connessa.
1395
1396 Vantaggi e svantaggi: consumo elettrico, efficenza, flessibilita', strumenti di gestione, sicurezza, OpenBSD.
1397
1398 Percorso dei pacchetti tra tabelle e catene
1399 -------------------------------------------
1400
1401 link: http://iptables-tutorial.frozentux.net/iptables-tutorial.html#TRAVERSINGOFTABLES
1402
1403
1404 Concetti di base
1405 -----------------
1406
1407 Tabelle, catene, regole
1408 ~~~~~~~~~~~~~~~~~~~~~~~~~
1409
1410 Iptables lavora su 3 tabelle (tables) di default:
1411
1412 * filter - Regola il firewalling: quali pacchetti accettare, quali bloccare
1413
1414 * nat - Regola le attività di natting
1415
1416 * mangle - Interviene sulla alterazione dei pacchetti.
1417
1418 Ogni tabella ha delle catene (chains) predefinite (INPUT, OUTPUT, FORWARD ... ) a cui possono essere aggiunte catene custom. 
1419 Ogni catena è composta da un elenco di regole (rules) che identificano pacchetti di rete secono criteri diversi (es: -p tcp --dport 80 -d 10.0.0.45)
1420 Ogni regola termina con una indicazione (target) su cosa fare dei pacchetti identificati dalla regola stessa (es: -j ACCEPT,  -j DROP ...)
1421
1422 Match 
1423 ~~~~~~~~~~~~~~~~~
1424
1425 I Match di una regola (rule) servono a testare un pacchetto per valutare se corrisponda a certe caratteriscttiche. I match di possono servire a controllare se un pacchetto e' destinato a una porta particolare o utilizza un protocollo particolare.
1426
1427 Alcuni esempi:
1428
1429 -p [!] proto 
1430         Protocollo IP. Secondo IP number o nome (es: tcp, udp, gre, ah...)
1431
1432 -s [!] address[/mask] 
1433         Indirizzo IP sorgente (o network con maschera di sottorete)
1434
1435 -d [!] address[/mask] 
1436         Indirizzo IP destinazione (o network)
1437
1438 -i [!] interface[+] 
1439         Interfaccia di rete di entrata ([+] wildcard)
1440
1441 -o [!] interface[+] 
1442         Interfaccia di rete di uscita ([+] wildcard)
1443
1444 -f 
1445         Frammento di pacchetto
1446
1447 Targets
1448 ~~~~~~~~~~~~~
1449
1450 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.
1451
1452 Target principali:
1453
1454 *-j ACCEPT* 
1455         Il pachetto matchato viene accettato e procede verso la sua destinazione. Si usa per definire il traffico permesso.
1456
1457 *-j DROP* 
1458         Il pacchetto viene rifiutato e scartato, senza alcuna notifica al mittente. Si usa, in alternativa a REJECT, per bloccare traffico. 
1459
1460 *-j REJECT* 
1461         Il pacchetto viene rifiutato. Al mittente viene mandato un pacchetto (configurabile) di notifica  tipo ICMP port-unreachable (--reject-with icmp-port-unreachable)
1462
1463 -t LOG 
1464         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) 
1465
1466 -j DNAT 
1467         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
1468
1469 -j SNAT 
1470         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.
1471
1472 -j MASQUERADE 
1473         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. 
1474
1475 -j REDIRECT 
1476         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)
1477
1478 -j RETURN 
1479         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.
1480
1481 -j TOS 
1482         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
1483
1484 -j MIRROR 
1485         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.
1486
1487
1488 Tabella Filter
1489 ---------------
1490
1491 E' quella implicita e predefinita (-t filter)
1492 Riguarda le attività di filtraggio del traffico.
1493 Ha 3 catene di default:
1494 INPUT - Riguarda tutti i pacchetti destinati al sistema. In entrata da ogni interfaccia.
1495 OUTPUT - Riguarda i pacchetti che sono originati dal sistema e destinati ad uscire.
1496 FORWARD - Riguarda i pacchetti che attraversano il sistema, con IP sorgente e destinazione esterni.
1497
1498 Esempio per permettere accesso alla porta 80 locale:
1499 iptables -t filter -I INPUT -p tcp --dport 80 -j ACCEPT
1500 Analoga a: iptables -I INPUT -p tcp --dport 80 -j ACCEPT
1501
1502 Esempio per permettere ad un pacchetto con IP sorgente 10.0.0.4 di raggiungere il server 192.168.0.1 attraversando il firewall:
1503 iptables -I FORWARD -s 10.0.0.4 -d 192.168.0.1 -j ACCEPT
1504
1505 Flush automatico per macchine remote
1506 ---------------------------------------
1507
1508 Se state provando una configurazione del firewall per una macchina remota e' buona norma per evitare brutte figure attivare uno script che faccia il *flush* delle regole dopo qualche minuto. Potreste infatti inavvertitamente impostare una regola che vi impedisca di raggiungere la macchina remota, cosi' da non poter neanche eliminare quella regola e ripristinare la situazioe precedente.
1509
1510 *Veramnete*, prima di lavorare sul firewall di una macchina remota inpostate almeno un ``at now +5 min`` o con un'oretta di margine per fare il *flush* delle regole (su tutte le tabelle)::
1511
1512             at now +5 min
1513         at> /sbin/iptables -F
1514         at> [CTR+d]
1515
1516
1517
1518 Gestione regole (rules)
1519 --------------------------
1520
1521 Il comando iptables viene usato per ogni attività di gestione e configurazione.
1522
1523 Inserimento regole:
1524
1525 iptables -A CATENA ... 
1526         Aggiunge una regola alla fine della catena indicata
1527
1528 iptables -I CATENA [#] ... 
1529         Inserisce alla riga # (default 1) una regola nella catena indicata
1530
1531 iptables -N CATENA 
1532         Crea una nuova catena custom
1533
1534 iptables -P CATENA TARGET 
1535         Imposta il target di default per la catena indicata
1536
1537 Rimozione regole e azzeramenti:
1538
1539 iptables -F [catena] 
1540         Ripulisce tutte le catene (o quella indicata)
1541
1542 iptables -X [catena] 
1543         Ripulisce tutte le catene custom (o quella indicata)
1544
1545 iptables -Z [catena] 
1546         Azzera i contatori sulle catene
1547
1548 iptables -D catena # 
1549         Cancella la regola numero # dalla catena indicata
1550
1551 Interrogazione:
1552
1553 iptables -L 
1554         Elenca le regole esistenti
1555
1556 iptables -L -n -v 
1557         Elenca, senza risolvere gli host, in modo verboso le regole esistenti
1558
1559
1560
1561
1562 Salvataggio regole
1563 ----------------------
1564
1565 Il comando ``iptables`` serve per interagire con il framework ``Netfilter`` ch gestisce il firewall di Linux al livello del kernel. Questo comporta, in modo analogo a quando avvene col comando ``ifconfig``, che i cambiameti impostati siano in *tempo reale, RAM*, non persistenti nel sistema: al boot sucessivo del sistema tutto tornera' alle impostazioni di base (in questo caso *nulle*, con policy di default settate su ``ACCEPT`` per tutto).
1566
1567 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.
1568
1569 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``.
1570
1571 Nel nostro caso avremo per una possibile scheda ``eth0``:
1572
1573 ``/etc/network/interfaces`` ::
1574                 
1575         iface eth1 inet static
1576                 up /sbin/iptables-restore /root/firewall/basic_fw
1577                 # Seguno i soliti parametri della scheda di rete
1578                 address 10.10.208.21 
1579  
1580
1581 Iptables-save
1582 ~~~~~~~~~~~~~~~
1583
1584 Per salvare le regole di iptables attualmente presenti nel kernel si usi il comando::
1585
1586         # iptables-save >> /root/firewall/basic_fw
1587
1588 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.
1589
1590
1591 Se non avete un'idea migliore potreste voler tenere gli script dei firewall in una cartella ``~/firewall`` nella home directory dell'utente ``root``.
1592
1593 Iptables-restore
1594 ~~~~~~~~~~~~~~~~~~~~
1595
1596 Per ripristinare un set di regole prcedentemente salvate con ``iptables-save`` si utilizzi ``iptables-restore``. Se questo deve essere fatto in modalita' *non interattiva*, ad esempio deve essere eseguito dal demone che si occupa di inizializzare le schede di rete, oppure un *cron* o altro, e' buona norma richiamare i percorsi completi sia dei comandi che dei file::
1597         
1598                 /sbin/iptables-restore /root/firewall/basic_fw
1599
1600
1601 NOTE
1602 ========
1603
1604 * controllare apache
1605
1606
1607 sintassi: in ``monospace`` :
1608
1609 * nomi di files
1610 * comandi
1611 * pacchetti