CSS e servizi, sempre tutto in RST
[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.9
11
12 Questa guida tratta la configurazione di base dei principali servizi di rete utilizzati con sistemi operativi *Unix* e derivati come *GNU/Linux* per gli studenti dei corsi per amministratori di rete in ambiente *GNU/Linux*. In particolare questa guida e' stata scritta usando come riferimento la distribuzione *Debian GNU/Linux*. Gli esempi presentati dovrebbero quindi essere direttamente utilizzabili anche su distribuzioni derivate da Debian come Ubuntu, per sistemi operativi diversi si presti attenzione ai percorsi dei file citati.
13
14 .. sectnum::
15
16 .. contents:: Indice degli argomenti
17 .. |date| date::
18
19 Generato il |date| con: http://docutils.sourceforge.net/rst.html
20
21 Configurazione sistema
22 =========================
23 Solo per uso interno
24 ---------------------------
25
26 Impostazioni di base per la configurazione del sistema operativo e della rete nel laboratorio 208 facente parte della rete piffa.net .
27
28 Sono qui riportati i parametri della rete locale per comodita' degli studenti, gli altri lettori possono considerarli come riferimento per comprendere i valori espressi nei vari file di configurazione. Ad esempio: quando leggerete ``10.10.208.248:3128`` saprete che si tratta del nostro *proxy http* in ascolto sulla porta `3128`, stara' quindi a voi sostituire i dati con gli equivalenti *IP* della vostra rete.
29
30 Rete
31 ------
32
33 Parametri della rete attualmente in uso:
34
35 ============= ================
36      Parametri della rete
37 ------------------------------
38 rete          10.10.208.0/24
39 netmask       255.255.255.0
40 broadcast     10.10.208.255
41 gateway       10.10.208.248
42 DNS           10.10.208.248
43 ============= ================
44
45 Dal server locale degli studeti, **Bender**, corrispondente all'IP ``10.10.208.248``, vengono erogati i servizi DHCP, DNS, gateway (con NAT), proxy http e mirror della distribuzione Debian ( http://debian.piffa.net). Altri servizi in esecuzione sul server:
46
47 - Rsync server e altri software di aggiornamento / installazione di massa
48 - Server imap / pop3 / webmail / smtp
49 - Server ssh per i test degli studenti 
50 - File server Samba, NFS e controller di qualsiasi altro FS distribuito
51 - Print server per la gestione delle stampanti
52 - DNS server
53 - Mirror locale delle \*.iso dei sistemi operativi e dei vari software usati durante le lezioni
54 - Spazi web con PHP, MySQL, Postgresql (altri DB o framework vengono attivati a seconda dei corsi attivi)
55
56
57 Durante il corso delle lezioni e' opportuno che le macchine degli studenti si appoggino al server Bender (ottetto finale ``248``), nel caso questo non fosse raggiungibile (ad esempio per permettere impostazioni di DHCP / routing diverse) sara' comunque disponibile il ``10.10.208.254`` come gateway | DNS per la rete ``10.10.208.10``.
58
59 **Non e' piu' possibile** raggiungere Bender tramite l'IP pubblico ``212.22.136.248`` o *qualsiasi altro ip* della classe ``C 212.22.136.0/24`` precedentemente disponibile.
60
61 Il computer del docente con il server VNC e' sempre configurato con l'ottetto finale: ``177`` della rete utilizzata durante le lezioni (quindi generalmente la VNC sara' disponibile sul ``10.10.208.177:1``. 
62
63 Gli studenti sono pregati di non impedire l'accesso SSH alla propria macchina dal computer del docente, e non modificare la password dell'utente ``root`` del sistema operativo *pre-istallato* (ad es: *Diurno*).
64
65 interfaces
66 ~~~~~~~~~~~~~~~
67
68 Segue un esempio del file di configurazione della scheda di rete con configurazione statica:
69
70 /etc/network/interfaces::
71
72         # /etc/network/interfaces -- configuration file for ifup(8), ifdown(8)
73
74         # The loopback interface
75         iface lo inet loopback
76
77         # La prima scheda di rete (se si chiama eth0)
78         iface etho inet static
79           # esempio con dhcp:
80           # iface etho inet dhcp
81         address 10.10.208.101
82         netmask 255.255.255.0
83         network 10.10.208.0
84         broadcast 10.10.208.255
85         gateway 10.10.208.254
86
87         # Quali interfaccie devono partire automaticamente:
88         auto lo eth0
89
90 Controllare il nome della propria scheda di rete: a volte *udev* rinomina la prima scheda a ``eth1``, oppure potreste avere piu' di una scheda di rete (anche un'interfaccia *firewire* puo' essere automaticamente abilitata come scheda di rete).
91
92 Se si usano *schede di rete virtuali* ( eth0:1 , eth0:1 , ...) ricordarsi che queste dipendono dalla scheda fisica a cui sono associate: abbattere con ``ifconfig down eth0`` la scheda principale fara' cadere anche queste. Tornando ad attivare la scada principale con ``ifconfig eth0 up`` la virtuale tornera' attiva: nel caso voleste disabilitarla dovrete quindi sempre abbattere manualmente la scheda virtuale *prima* della scheda reale.
93
94 I DNS vanno indicati nel file ``/etc/resolv.conf`` , la cui sintassi e' spiegata al punto 4.6 . Come DNS si *deve* usare il server Bender, alcuni parametri dei software di installazione, risoluzione dei mirror, vengono opportunamente modificatia da questo DNS.
95
96 Bash completion
97 -------------------
98
99 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.
100
101 Bash_completion permette di integrare il completamento automatico con i nomi dei pacchetti e oggetti dei comandi: ad es. volendo digitare ``apt-get inst[TAB] xtigh[TAB]`` ora verra' completato automaticamente sia la parola ``install`` che il nome del pacchetto ``xtightvncviewer``. 
102
103 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*)::
104
105         echo ". /etc/bash_completion" >> ~/.bashrc
106
107 Esempio di ~/.bahsrc ::
108
109         # ~/.bashrc: executed by bash(1) for non-login shells.
110         
111         export PS1='\h:\w\$ '
112         umask 022
113         
114         # De-commentare le seguenti righe per abilitare la colorazione dei
115         # nomi dei file:
116          export LS_OPTIONS='--color=auto'
117          eval "`dircolors`"
118          alias ls='ls $LS_OPTIONS'
119          alias ll='ls $LS_OPTIONS -l'
120          alias l='ls $LS_OPTIONS -lA'
121         
122         # Abilitare i seguenti alias per impostare la conferma per cancellare file
123         # alias rm='rm -i'
124         # alias cp='cp -i'
125         # alias mv='mv -i'
126         
127         # questo abilita bash completion
128         . /etc/bash_completion
129
130 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.
131
132 Links:
133
134 * `An introduction to bash completion <http://www.debian-administration.org/articles/316>`_
135 * `Working more productively with bash 2.x/3.x <http://www.caliban.org/bash/>`_
136 * UNIX / Linux Shell Scripting Tutorial: http://steve-parker.org/sh/sh.shtml
137
138 Vim
139 ------------
140
141 Vim e' l'editor di testo preferito dai sistemisti, quindi sara' conveniente impostare fin da subito alcune impostazioni per renderlo piu' comodo.
142
143 Assicurarsi che sia installata nel sistema la versione completa dell'editor installando il  pacchetto ``vim``::
144
145         # apt-get install vim
146
147
148 Modificare poi il file di configurazione generale ``/etc/vim/vimrc`` ::
149
150     " All system-wide defaults are set in $VIMRUNTIME/debian.vim (usually just
151     " /usr/share/vim/vimcurrent/debian.vim) and sourced by the call to :runtime
152     " you can find below.  If you wish to change any of those settings, you should
153     " do it in this file (/etc/vim/vimrc), since debian.vim will be overwritten
154     " everytime an upgrade of the vim packages is performed.  It is recommended to
155     " make changes after sourcing debian.vim since it alters the value of the
156     " 'compatible' option.
157     
158     " This line should not be removed as it ensures that various options are
159     " properly set to work with the Vim-related packages available in Debian.
160     runtime! debian.vim
161     
162     " Uncomment the next line to make Vim more Vi-compatible
163     " NOTE: debian.vim sets 'nocompatible'.  Setting 'compatible' changes numerous
164     " options, so any other options should be set AFTER setting 'compatible'.
165     "set compatible
166     
167     " Vim5 and later versions support syntax highlighting. Uncommenting the next
168     " line enables syntax highlighting by default.
169     syntax on
170     
171     " If using a dark background within the editing area and syntax highlighting
172     " turn on this option as well.
173     set background=dark
174     
175     " Uncomment the following to have Vim jump to the last position when
176     " reopening a file
177                       
178     if has("autocmd")
179       au BufReadPost * if line("'\"") > 0 && line("'\"") <= line("$")
180         \| exe "normal! g'\"" | endif
181     endif
182     
183     " Uncomment the following to have Vim load indentation rules and plugins
184     " according to the detected filetype.
185     " This is not recommanded if you often copy and paste into vim,
186     " as it messes all the indentation.
187     if has("autocmd")
188       filetype plugin indent on
189     endif
190
191     " This goes for comments folding: use co to expnad and zc to compress,
192     " zi to toggle on/off
193     set fdm=expr
194     set fde=getline(v:lnum)=~'^\\s*#'?1:getline(prevnonblank(v:lnum))=~'^\\s*#'?1:getline(nextnonblank(v:lnum))=~'^\\s*#'?1:0
195     
196     " The following are commented out as they cause vim to behave a lot
197     " differently from regular Vi. They are highly recommended though.
198     set showcmd             " Show (partial) command in status line.
199     "set showmatch          " Show matching brackets.
200     # Ignorecase is quite userfull
201     set ignorecase          " Do case insensitive matching
202     "set smartcase          " Do smart case matching
203     "set incsearch          " Incremental search
204     set autowrite           " Automatically save before commands like :next and :make
205     "set hidden             " Hide buffers when they are abandoned
206     "set mouse=a            " Enable mouse usage (all modes) in terminals
207     
208     " Source a global configuration file if available
209     " XXX Deprecated, please move your changes here in /etc/vim/vimrc
210     if filereadable("/etc/vim/vimrc.local")
211       source /etc/vim/vimrc.local
212     endif                                             
213
214
215 I principianti faranno bene ad esercitarsi con ``vimtutor it``.
216
217 Altri link per VIM:
218
219 - Vim Introduction and Tutorial: http://blog.interlinked.org/tutorials/vim_tutorial.html
220 - http://blog.smr.co.in/category/vim/
221 - http://vimdoc.sourceforge.net/
222
223 VNC
224 ------------
225
226 I Virtual Network Computing (o VNC) sono software di controllo remoto e servono per amministrare il proprio computer a distanza o visualizzare la sessione di lavoro di un altro computer sul proprio a scopo didattico. 
227
228 Scaricare il pacchetto ``xtightvncviewer`` e lo script ``guarda.sh`` in una posizione (collocazione nel *path* degli utenti, es ``echo $PATH`` per visualizzare l'attuale path ) comoda per gli utenti ( in genere ``/bin`` ), rendere eseguibile lo script.
229
230 Procedura::
231
232     su root
233     cd /bin
234     wget http://bender/guarda.sh
235     chmod +x guarda.sh
236     exit
237
238
239 Per eseguire lo script digitare semplicemente ``guarda.sh``, oppure creare un link / collegamento sul Desktop allo script ``/bin/guarda.sh``.
240
241 Le impostazioni del server VNC sono:
242
243 ===================== =================
244 Parametro               Valore
245 ===================== =================
246 IP                      10.10.208.177:1
247 Server grafico          :1
248 password                password
249 ===================== =================
250
251
252 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.
253
254 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`` .
255
256 Lista dei pacchetti di base
257 -----------------------------
258
259 I pacchetti installati generalmente [#]_ per poter seguire le lezioni sono::
260
261         kde-core kdm kde-i18n-it xorg vim less xtightvncviewer 
262
263 .. [#] ``kde-core`` e' piu' leggero del pacchetto ``kde``. Esiste un equivalente ``gnome-core`` per chi preferisce Gnome, nel caso si potrebbe installare  il log-in manager `gdm` al posto di `kdm`.    
264
265 Apt configurazione
266 ---------------------
267
268 Vediamo i due file principali di apt:
269
270 * ``/etc/apt/sources.list``
271
272 * ``/etc/apt/apt.conf``
273
274 sources.list
275 ~~~~~~~~~~~~~~~~
276
277 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).
278
279 Gli archivi sono generalmente:
280
281 * ``deb`` per pacchetti Debian binari, pronti per l'installazione.
282
283 * ``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.
284
285
286 ``/etc/apt/sources.list`` ::
287
288     # esempio di accesso a un CDROM:
289     # cdrom:[Debian GNU/Linux 5.0.1 _Lenny_ - Official i386 kde-CD Binary-1 20090$
290     
291     # Archivio principale debian via http su piffa.net,
292     # non funziona al di fuori dell'aula dei corsi
293     deb http://debian.piffa.net/debian/ lenny main
294     # Sono disponibili anche i rami non-free contrib
295     # deb http://debian.piffa.net/debian/ lenny  non-free contrib
296     # Sono disponibili anche le release unstable e testing
297     # deb http://debian.piffa.net/debian/ testing  main non-free contrib
298     # deb http://debian.piffa.net/debian/ sid  main non-free contrib
299     
300     # Mirror da kernel.org europa da usare a casa:
301     deb http://mirrors.eu.kernel.org/debian/ lenny main
302     
303     # Security dal sito principale
304     deb http://security.debian.org/ lenny/updates main
305     deb-src http://security.debian.org/ lenny/updates main
306     
307     # Debian volatile per le cose soggette a cambiamenti non legati
308     # a dinamiche di sicurezza
309     deb http://volatile.debian.org/debian-volatile Lenny/volatile main
310     deb-src http://volatile.debian.org/debian-volatile Lenny/volatile main
311     
312     # Esempio di accesso a un file system locale contenente i pacchetti:
313     # Potete scaricarei in aula con debmirror  da debian.piffa.net
314     # un mirror locale da usare poi a casa anche senza internet
315     # deb file:/mnt/mirror sid main non-free contrib
316
317
318 /etc/apt/apt.conf
319 ~~~~~~~~~~~~~~~~~~
320
321 Questo file contiene le opzioni di apt, come ad esempio il proxy::
322
323     Acquire::http::Proxy "http://10.10.208.248:3128";
324
325 Si tenga conto che se si imposta un proxy per apt sul proprio portatile e tornati a casa propria si vuole scaricare nuovi pacchetti si dovra' disabilitare il proxy commentando la riga con ";" (''punto-e-virgola'')::
326
327 E' consigliabile impostare il proxy per apt anche in presenza di un proxy-http *trasparente*.
328
329
330 Squid
331 ======
332
333 Squid e' un proxy  cache http (ma anche FTP e https) robusto e strutturato, puo' essere usato sia in reti relativamente semplici che in scenari piu' complessi grazie alla possibilita' di gestirne in modo granulare le risorse.  Si partira' dalle configurazioni piu' semplici per la semplice *condivisione della navigazione* internet, per poi poter negoziare la gestione degli accessi, il filtraggio dei contenuti (Squid e' una applicazione che si muove nel 4' livello del modello TCP/IP a differenza di un *ipfilter* limitato al 2'), nel  bilanciamento del carico tra piu' server proxy.
334
335 Inoltre Squid svolge la funzione di *anonymizer*:
336         Nasconde i client http alla rete internet:  e' solo il server proxy ad accedere ai server web frequentati dai client: questi non sono percepiti ed esposti all'esterno della rete locale ma si relazionano solo con il server proxy. Dal punto di vista della sicurezza della rete locale questo e' preferibile ad un approccio alla navigazione basato su *NAT*.
337
338 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 introdurre nella rete un *NAT* (si veda la sezione sui firewall) per condividere la connessione: basta il solo Squid. Per altro non servira' neanche un servizio DNS accessibile dai clients dato che *sara' il solo Squid a risolvere i nomi di dominio* per i suoi client http.
339
340 Squid ascolta di default sulla porta 3128,  per impostare *apt* per utilizzarlo si aggiunga ad ``/etc/apt/apt.conf`` ::
341
342         Acquire::http::Proxy "10.10.208.254:3128";
343
344
345 Per installare Squid si usino i pacchetti::
346
347         squid3
348
349
350 Configurazione: squid.conf
351 -------------------------------
352
353 Segue un estratto delle direttive principali viste in aula presenti nel file di configurazione ``/etc/squid3/squid.conf`` .
354
355 Cache_dir
356 ~~~~~~~~~~~~
357
358 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.
359
360 La dimensione ovviamente dipendera' dallo spazio disponibile, dimensioni tipiche e massime degli oggetti che si vuole tenere in cache (un solo file *.iso e' circa ``700 MB``, il pacchetto *Openoffice.org* circa ``150 MB``, un pacchetto debian circa ``20 MB``), numero dei client.
361
362 Si presti poi attenzione alla natura dei dati che saranno salvati nella cache: sono tutti dati facilmente sostituibili (gli originali sono *on-line*) la cui perdita non arreca danni permanenti. Questo rende la cache di Squid un possibile candidato ad un *RAID stirpe* (livello 0) a ad un file system che prediliga le performance a scapito della consistenza, 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. 
363
364 Questo fino al momento in cui per voi non sia piu' importante *garantire la disponibilita' del servizio*, ad esempio con un RAID *mirror* o 5 (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*).
365
366 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):
367
368 /etc/fstab ::
369
370         ...
371         # Filesystem per Squid http cache
372         /dev/md3/       /var/spool/squid/       ext2,noexec,nosuid,noatime  0 3
373
374 Ora possiamo impostare la cache nel file di configurazione ``/etc/squid3/squid.conf``::
375
376         #TAG: cache_dir (riga 1628)
377         #       Usage:
378         #
379         #       cache_dir Type Directory-Name Fs-specific-data [options]
380         #
381         #       You can specify multiple cache_dir lines to spread the
382         #       cache among different disk partitions.
383         #       ...
384         #Default:
385         # cache_dir ufs /var/spool/squid3 100 16 256
386         cache_dir aufs /var/spool/squid3 300 24 256
387         #         |    |                 |   |  secondo livello di directory 
388         #         |    |                 |   directory primo livello
389         #         |    |                 dimensione in MB
390         #         |    path della cache
391         #         algoritmo
392
393 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. Tipicamente e' consigliabile cancellare (se si ha *ridotto* il numero delle directory) la vecchia cache e poi generare una nuova struttura. Se si vuole *star nel sicuro* ogni volta che si modifica l'impostazione delle directory *si svuoti la vecchia cache e se ne generi una nuova* ::
394
395         # /etc/init.d/squid3 stop
396         # rm -r /var/spool/squid3/??
397         # squid3 -z
398         # /etc/init.d/squid3 start
399
400 TAG: maximum_object_size
401 ~~~~~~~~~~~~~~~~~~~~~~~~~~
402
403 Questa direttiva imposta la dimensione massima degli oggetti che vengono salvati sul supporto di storaggio, oggetti di dimensioni superiori saranno comunque scaricati ma non tenuti in cache.
404
405 TAG: maximum_object_size (1760)::
406
407         # TAG: maximum_object_size (1760)
408         #       Objects larger than this size will NOT be saved on disk.  The
409         #       value is specified in kilobytes, and the default is 4MB.  If
410         #       you wish to get a high BYTES hit ratio, you should probably
411         #       increase this (one 32 MB object hit counts for 3200 10KB
412         #       hits).  If you wish to increase speed more than your want to
413         #       save bandwidth you should leave this low.
414         #
415         #       NOTE: if using the LFUDA replacement policy you should increase
416         #       this value to maximize the byte hit rate improvement of LFUDA!
417         #       See replacement_policy below for a discussion of this policy.
418         #
419         #Default:
420         # maximum_object_size 4096 KB
421         maximum_object_size 150 MB
422         
423 TAG: cache_mem
424 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
425
426 *Cache_mem* imposta quanta memoria RAM venga utilizzata per la cache di Squid. 
427 Questo dipendera' dalla RAM disponibile sul sistema, e da quanta di questa volete mettere a disposizione di Squid (altri servizi importanti girano sulla stessa macchina? ).
428 Questo parametro influisce sulle prestazioni e sul degrado dei supporti di storaggio (sopratutto se magnetici).
429
430 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 rispetto agli altri servizi: avra' bisogno di  ``~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.
431
432 Se invece si disponesse di una macchina dedicata a Squid con gigabytes di RAM non si esiti a dedicarne buona parte a *cache_mem*.
433
434 TAG: cache_mem   (1566)::
435
436         #       'cache_mem' specifies the ideal amount of memory to be used
437         #       for:
438         #               * In-Transit objects
439         #               * Hot Objects
440         #               * Negative-Cached objects
441         #Default:
442         # cache_mem 8 M
443         cache_mem 100 M
444
445
446 TAG: minimum_object_size
447 ~~~~~~~~~~~~~~~~~~~~~~~~~~
448
449 Questo parametro imposta la dimensione minima degli oggetti salvati nella cache. Settato a ``0`` o a valori molto piccoli puo' influire negativamente sulla frammentazione del filesytem e consumare un numero elevato di *inode* (cosa non piu' importante con ext4 o altri filesytem).
450
451 TAG: minimum_object_size::
452
453         #  TAG: minimum_object_size     (bytes)
454         #       Objects smaller than this size will NOT be saved on disk.  The
455         #       value is specified in kilobytes, and the default is 0 KB, which
456         #       means there is no minimum.
457         #
458         #Default:
459         # minimum_object_size 0 KB
460         minimum_object_size 0 KB
461
462 Negoziazione degli accesi al servizio
463 ---------------------------------------
464
465 Squid e' uno di quei servizi soggetto a problemi di tipo *open relay* , si deve quindi limitare la rete che puo' accedere al servizio. 
466
467 Open Relay:
468         Un servizio a cui possono accedere tutti indiscriminatamente.
469         La cosa puo' andare bene per servizi come i server web, che aspirano per loro natura
470         al maggior numero possibile di utenti, ma non a servizi come i proxy http oppure
471         ai server di posta elettronica (adibiti ai soli utenti della rete locale).
472
473 Generalmente non volete che il vostro proxy http venga usato da persone sconosciute ed esterne alla vostra rete, le quali sostanzialmente *navigherebbero sotto l'identita' del vostro proxy* (probabilmente per visionare materiali che non vorrebbero fossero ricondotti direttamente a loro) generando traffico e consumando 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*.
474
475 Per poter limitare gli accessi a Squid dal punto di vista dell'applicazione (quarto livello TCP/IP) si identifichera' inizialmente l'entita' *rete locale* (es: ``localnet``) con una ACL di tipo *src* (indirizzi IP sorgenti) indicando la *classe / range di IP* della nostra rete.
476
477  Dopodiche l'accesso (``http_access``) si concedera' (*allow*) a questa entita' (es: ``localnet``) negando chiunque altro.
478
479 Per maggiori dettagli sulla sintassi utilizzabile per esprimere i range di IP: 
480 http://www.visolve.com/squid/squid24s1/access_controls.php
481
482 E' poi sempre possibile tenere il proxy in ascolto su un solo indirizzo IP, nel caso si disponga di piu' devicei di rete, oppure settare un firewall per limitare il traffico dai primi livelli del TCP/IP.
483
484
485
486 ACL e http access
487 ~~~~~~~~~~~~~~~~~~~~~
488 Si proceda a creare una ``ACL`` di tipo ``src`` per identificare la nostra rete locale, poi si abiliti l'accesso a questa con la direttiva ``http_access``. Tutto quanto non e' espressamente autorizzato viene poi negato da un ``http_access deny all`` finale.
489
490 ::
491
492         #  TAG: acl
493         #       Defining an Access List
494         #
495         #       Every access list definition must begin with an aclname and acltype,
496         #       followed by either type-specific arguments or a quoted filename that
497         #       they are read from.
498         #       ...
499         #       ***** ACL TYPES AVAILABLE *****
500         #
501         #       acl aclname src ip-address/netmask ...          # clients IP address
502         # riga 588
503         
504         # Example rule allowing access from your local networks.
505         # Adapt to list your (internal) IP networks from where browsing
506         # should be allowed
507         #acl localnet src 10.0.0.0/8    # RFC1918 possible internal network
508         #acl localnet src 172.16.0.0/12 # RFC1918 possible internal network
509         #acl localnet src 192.168.0.0/16        # RFC1918 possible internal network
510         #
511         acl localnet src 10.10.208.0/24    
512
513         # Riga 606
514         #  TAG: http_access
515         #       Allowing or Denying access based on defined access lists
516         #
517         #       Access to the HTTP port:
518         #       http_access allow|deny [!]aclname ...
519         #
520         #       NOTE on default values:
521         #
522         #       If there are no "access" lines present, the default is to deny
523         #       the request.
524         
525         # Riga 643
526         # INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS
527         
528         # Example rule allowing access from your local networks.
529         # Adapt localnet in the ACL section to list your (internal) IP networks
530         # from where browsing should be allowed
531         #http_access allow localnet
532         http_access allow localnet
533
534 Testare Squid
535 ---------------
536
537 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.
538
539
540 Client: ~/.wgetrc
541 ~~~~~~~~~~~~~~~~~~~
542
543 Nel file ``.wgetrc`` (si noti il punto iniziale: e' un file nascosto) si puo' impostare il proxy per wget. Si utilizzi l'indirizzo IP del server che si vuole testare, e si seguano i log ``/var/log/squid3/access.log`` sul server.
544
545 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``.
546
547 .wgetrc
548         http_proxy=10.10.208.178:3128
549
550 Si proceda a scaricare dal client scelto con un wget::
551
552         wget http://www.google.it
553
554 Server: access.log
555 ~~~~~~~~~~~~~~~~~~~~~
556
557 Si puo' controllare il corretto funzionamento del server seguendo i log di accesso a Squid::
558
559         # tail -f /var/log/squid3/access.log
560
561 In oltre e' possibile configurare diversi *analizzatori di log* come ``Webalizer`` per studiare i log di Squid.
562
563
564 Apache
565 ========
566
567 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.
568
569 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 da' vita al World Wide Web, uno dei servizi piu' utilizzati di Internet.
570
571 Pacchetti da installare::
572 ----------------------------
573
574          apache2 apache2-doc
575
576 Con la release 2.0 di Apache viene automaticamente resa disponibile anche la versione SSL (Secure Socket Layer, connessioni criptate ) del web server.
577
578
579 Configurazione di Apache
580 ----------------------------
581
582 I file di configurazione di apache si trovano nella cartella: ``/etc/apache2`` e sono strutturati come descritto nel file 
583 ``/usr/share/doc/apache2/README.Debian.gz`` . Sostanzialmente lo schema e' il seguente:
584
585 apache2.conf
586           File di configurazione principale del servizio.
587
588           httpd.conf e' il vecchio file di configurazione di Apache1, presente per motivi di retrocompatibilita' e' generalmente vuoto.
589
590 ports.conf
591           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>``
592
593 sites-available
594           In questa cartella vengono raccolti i file di configurazione dei virtual host disponibili.
595
596 sites-enabled
597           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.
598
599 mods-available
600           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 .
601
602 mods-enabled
603           Moduli abilitati, effettivamente caricati.
604
605 apache.conf
606 ----------------
607
608 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.
609
610 Guardiamo alcune direttive interessanti:
611
612 Timeout
613                 Numero di secondi da aspettare prima di chiudere la connessione con il client. Questo parametro serve a liberare le risorse di sistema nel caso che un client, magari a causa di una connessione particolarmente lenta o instabili, tenga attivo indefinitamente un processo di apache.
614
615 KeepAlive
616           L'estensione keep-alive (http 1.0) congiuntamente alle connessioni persistenti (http 1.1) permettono al server di rispondere a piu' richieste dei client mediante la stessa connessione. Il protocollo http per sua natura e' senza stato (*stateless* ), quindi ogni risorsa richiesta (per pagine web si pensi ad esempio alle immagini) dal client necessita di una connessione autonoma. Keep-alive permette di ottimizzare la connessione anche fino al 50% a seconda delle situazioni e contenuti.
617
618 Server-Pool Size Regulation
619           Questi parametri (StartServers, MinSpareServers, ecc. Tutti spiegati nel manuale di apache) servono per attribuire le risorse di sistema disponibili al server Apache. Tenere questi parametri bassi serve a limitare il rischio di Denial of Service per il server, nel caso offra altri servizi. I settagli di default sono come sempre abbastanza conservativi, se si conta di usare il proprio Apache per servire un sito web con molti visitatori sara' necessario aumentare sensibilmente le impostazioni di base.
620
621 AccessFileName
622           Il nome del file che viene onorato per modificare le impostazioni per una singola directory, legato alla direttiva AllowOverride .
623
624 Installazione di PHP
625 ---------------------
626
627 Pacchetti da installare: ``php5 php-pear``
628
629 Test del modulo php
630 ~~~~~~~~~~~~~~~~~~~~
631
632 Creare nella cartella ``/var/www`` (o altra cartella visibile) un file con estensione \*.php (es ``/var/www/info.php`` contenete codice php eseguibile dall'interprete, ad es::
633
634         <?php phpinfo() ; ?>
635
636 Questa funzione di php generera' la tipica pagina con le impostazioni attuali per PHP. Richiamando la pagina (es: ``http://localhost/info.php`` ) verra' generata dall'interprete PHP la pagina HTML e resa disponibile tramite Apache ai client HTTP, a prova del corretto funzionamento del modulo di PHP e della sua integrazione con il server web Apache.  In caso contrario se il client http proporra' di scaricare la pagina invece che visualizzarla nel browser: non funziona l'interprete di php o sono mal configurati i MIME-type. prima di tutto assicurarsi di aver fatto ripartire Apache.
637
638 Installazione del supporto per Mysql
639 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
640
641 Installare i pacchetti::
642
643         php5-mysql phpmyadmin
644
645 Controllare tramite la pagina php.info che sia abilitato il supporto per Mysql (ripartito Apache, ricaricare la pagina e cercare con CTRL+f ``mysql``).
646
647 phpmyadmin
648 ~~~~~~~~~~~~~~~~~~~~~
649
650 L'interfaccia web Phpmyadmin non richiede necessariamente la presenza di un database Mysql locale, puo' infatti essere utilizzata per gestire database remoti (il suo file di configurazione: ``/etc/phpmyadmin/config.inc.php`` ). Nel caso si voglia installare localmente Mysql si utilizzi il pacchetto ``mysql-server`` .
651
652 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/`` .
653
654 Installazione del supporto per Postgresql
655 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
656
657 Installare i pacchetti::
658
659         php5-pgsql phppgadmin
660
661 Controllare tramite la pagina php.info che sia abilitato il supporto per PostgreSQL (ripartito Apache, ricaricare la pagina e cercare con CTRL+f ``pgsql``).
662
663
664 phppgadmin
665 ~~~~~~~~~~~~~~~~~~~~~
666
667 L'interfaccia web Phppgadmin per il database server PostgreSQL non richiede necessariamente la presenza di un database locale, puo' infatti essere utilizzata per gestire database remoti (il suo file di configurazione: ``/etc/phppgadmin/config.inc.php`` ). Nel caso si voglia installare localmente Mysql si utilizzi il pacchetto ``postgresql`` .
668
669 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/`` .
670
671 Virtual hosts
672 --------------------
673
674   * http://www.apacheweek.com/features/vhost
675
676   * http://www.onlamp.com/pub/a/apache/2004/01/08/apacheckbk.html
677
678 I virtual host permettono di avere piu' siti internet disponibili tramite lo stesso server web, eventualmente mappati su un solo indirizzo IP. Sono generalmente di due tipi:
679
680         * Basati su *indirizzi IP*. 
681           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.
682
683         * Basati su *nomi di dominio* che puntano allo stesso IP.
684           Soluzione piu' economica e diffusa che si basa sulle funzionalita' di http 1.1 . 
685
686 Prenderemo in esame la gestione di virtual hosts basati su nomi di dominio.
687
688 Gestione DNS
689 ~~~~~~~~~~~~~~~
690
691 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:
692
693          *Bind* (DNS server)
694           Impostare i campi A nelle proprie zone gestite dal server DNS Bind. Ad es: ``papo            A       212.22.136.248``
695
696          *Servizio DNS dinamico on line*.
697           Utilizzare un servizio come ad es: https://www.dyndns.com/ per mappare nomi di dominio sul proprio indirizzo IP, comodo ad esempio se si dispone di un indirizzo IP pubblico (anche se dinamico) per la propria connessione ad internet.
698
699          *Dnsmasq* (DNS server)
700           Utilizzabile al livello della rete locale per fare dei test, utilizzando direttive come: ``address=/davide.piffa.net/10.10.208.178``
701
702          ``/etc/hosts``
703           Per prove sul proprio sistema potete impostare i nomi dei vostri virtual server nel file /etc/hosts .
704
705 Query DNS con ``dig``::
706
707     # dig 177.piffa.net
708
709     ; <<>> DiG 9.5.1-P1 <<>> 177.piffa.net
710     ;; global options:  printcmd
711     ;; Got answer:
712     ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38036
713     ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
714     
715     ;; QUESTION SECTION:
716     ;177.piffa.net.                 IN      A
717     
718     ;; ANSWER SECTION:
719     177.piffa.net.          0       IN      A       10.10.208.177
720     
721
722 La parte interessante e' l'*ANSWER SECTION*: ``177.piffa.net.          0       IN      A       10.10.208.177`` . Il nome di dominio 177.piffa.net viene risolto sull'ip 10.10.208.177 , nel nostro Apache (che risponde all'ip 10.10.208.177 ) dovra' essere disponibile un virtual host che corrisponde al nome ``177.piffa.net`` (``ServerName``) .
723
724 Virtual host
725 ~~~~~~~~~~~~~~
726
727 Esempio di Virtual host::
728
729         <VirtualHost *:80 >
730             ServerName 177.piffa.net
731             DocumentRoot /var/www/177.piffa.net/
732             ServerAdmin webmaster@177.piffa.net
733         </VirtualHost>
734
735 1. ``<VirtualHost \*:80 >``  La prima riga indica l'inizio della stanza relativa al nostro virtual host, che ascoltera' su qualunque indirizzo IP (nel caso il server abbia piu' indirizzi dai quali e' raggiungibile) sulla porta ``80``.
736 2. ``Server/name`` precisa quale sara' il nome di dominio a cui verra' associato questo sito rispetto ad altri eventualmente presenti sullo stesso server web.
737 3. ``DocumentRoot`` : il path della directory che contiene le pagine del sito.
738 4. ``ServerAdmin``: l'indirizzo del webmaster, in modo da poterlo contattare in caso di problemi col sito.
739 5. ``</VirtualHost>``: *tag* di chiusura della stanza di definizione del virtual host.
740
741 Quelle che abbiamo appena visto sono le direttive essenziali per definire un sito virtuale, potrebbe essere utile aggiungere altre:
742
743 * ``ErrorLog /var/log/apache2/177.piffa.net/error.log``
744         Log degli errori separato dai restanti siti web ospitati dal server.
745         
746 * ``LogLevel warn``
747         Livello di importanza degli eventi loggati= warning *attenzione* . 
748
749 * ``CustomLog /var/log/apache2/177.piffa.net/access.log combined``
750         Log di accesso separati dagli altri siti, utile anche qua per statistiche di accesso per il solo sito virtuale.
751
752
753 Potrebbe essere utile modificare le impostazioni di una intera directory, ad esempio per abilitare l'``AuthConfig``::
754
755         <Directory "/var/www/miosito.net/privata">
756                 AllowOverride AuthConfig
757                 Options ExecCGI Indexes MultiViews FollowSymLinks
758                 Order allow,deny
759                 Allow from all
760         </Directory>
761
762 ``AllowOverride AuthConfig`` ora vale per l'intera directory, come le altre opzioni.
763
764 Negoziazione accessi
765 ---------------------
766
767 Tipicamente quando si installa un server web il proprio desiderio e' di dare accesso ai materiali disponibili al maggior numero di visitatori possibile. Talvolta pero' puo' essere utile poter limitare questi accessi, ad esempio per escludere un *bot* indesiderato che scansiona ininterrottamente le nostre pagine o per creare una *Area Riservata* i cui materiali non devono essere disponibile a tutti.
768
769 Limiti su base IP
770 ~~~~~~~~~~~~~~~~~~~~~~
771
772 La forma piu' semplice di restrizione degli accessi e' su base degli indirizzi IP dei client: tipicamente i siti web sono settati per dare accesso a chiunque::
773
774          <VirtualHost *:80 >
775                 # ...
776                 <Directory "/var/www/177.piffa.net">
777                   Order allow,deny
778                   Allow from all
779                 </Directory>
780          </VirtualHost>
781
782 Potremmo negare l'accesso a uno o piu' indirizzi IP in questo modo::
783
784          <VirtualHost *:80 >
785                 # ...
786                 <Directory "/var/www/177.piffa.net">
787                   Order allow,deny
788                   Allow from all
789                   Deny from 192.168.0.1
790                 </Directory>
791          </VirtualHost>
792
793 Ora l'IP 192.168.0.1 non potra' piu' accedere ai materiali dell'intero sito virtuale, oppure potremmo lavorare su una sola directory::
794
795          <Directory "/var/www/miosito.net/limitata">
796                 Order allow,deny
797                 Allow from 192.168.0.0./24
798                 Deny from all
799          </Directory>
800
801 In questo modo solo la classe IP ``192.168.0.0/24`` potra' accedere alla directory ``/limitata``
802 Si tenga pero' conto che e' relativamente facile per un malintenzionato cambiare il proprio indirizzo IP, oppure collegarsi da un altra zona. Meno facile e' accedere ad una classe privata trovandosi all'esterno di questa, ma ci sono comunque soluzioni piu' eleganti.
803
804
805 User Authentication
806 ---------------------
807
808 Si puo' negoziare gli accessi ad un area del sito tramite autenticazione basata su *nome utente / password*. Questo puo' venire utile per creare una area download *intranet*, alla quale possano accedere solo gli utenti previsti a prescindere dagli indirizzi IP dei loro client. 
809
810 Tramite il modulo di Apache *mod-auth* e' possibile implementare questo paradigma, per quanto esistano soluzioni piu' granulari e sofisticate, che richiedono pero' l'implementazione di interpreti di linguaggi di programmazione, criptazione delle passwords, gestione degli utenti ed eventualmente delle sessioni. 
811 Mod auth non richiede l'installazione di niente di tutto questo.
812
813
814 link: http://www.apacheweek.com/features/userauth
815
816 Definire la cartella
817 ~~~~~~~~~~~~~~~~~~~~~~
818
819 Decidere quale sara' il *path* della cartella da sottoporre ad autenticazione:
820
821         ``mkdir /var/www/177.piffa.net/privata``
822
823 Creazione del database delle passwords
824 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
825
826 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. 
827
828 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.
829
830 Creiamo (con il *flag* ``-c``) il file ``/home/utente/passwords`` con l'utente ``luca``::
831  
832         htpasswd -c /home/utente/passwords luca
833         
834 ``htpasswd`` ci chiedera' la password da associare all'utente ``luca``. Per successive modifiche della password o aggiunta di nuovi utenti non sara' necessario usare il flag ``-c``.
835
836 Configurazione di Apache
837 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
838
839 Ora possiamo passare alla configurazione vera e propria di Apache, ma con una novita': andremo a inserire la voce in un ``.htaccess`` invece che modificare (tramite una direttiva ``<Directory>`` ) il file di impostazione del virtual-host.
840
841 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.
842
843 Dando agli utenti la possibilita' di modificare (*AllowOverride*) autonomamente alcuni parametri (in questo caso solo l'*AuthConfig*) relativi al funzionamento del loro spazio web ci togliera' l'incombenza di dover intervenire continuamente sui vari virtual host.
844
845 Abilitiamo l'AllowOverride nel file di configurazione del virtual host per la sola directory ``privata``::
846
847         <VirtualHost *:80 >
848             ServerName 177.piffa.net
849             DocumentRoot /var/www/177.piffa.net/
850             ServerAdmin webmaster@177.piffa.net
851             <Directory "/var/www/177.piffa.net/privata">
852                 AllowOverride AuthConfig
853             </Directory>
854         </VirtualHost>
855
856 Per rendere il cambiamento effettivo sara' necessario fare un restart / reload di Apache.
857
858 Ora sara' possibile, anche per l'utente di sistema, creare un file ``.htaccess`` che sara' onorato da Apache.
859
860 /var/www/177.piffa.net/privata/.htaccess ::
861
862         # Messaggio visualizzato al prompt per l'autenticazione
863         AuthName "Area privata soggetta ad autentizazione"
864         # tipo di autenticazione da usarsi
865         AuthType Basic
866         # File precedentemente generato con htpasswd
867         AuthUserFile  /home/utente/passwords
868         
869         # Negoziazione degli accessi
870         # valid users permette l'accesso agli utenti specificati
871         # nel file generato da htpasswd
872         require valid-user
873
874 Si noti che non e' necessario fare ripartire Apache per onorare i cambiamenti (un utente non avrebbe la possibilita' di farlo!).
875
876 Oltre a ``valid-users`` si potrebbe scegliere di usare la formula ``users``  che permette di elencare esplicitamente gli utenti::
877         require user pippo pluto 
878
879 L'utente *paperino* che fosse comunque presente nel file generato da htpasswd non potrebbe accedere alla risorsa.
880
881 Nel caso ci fossero molti utenti conviene gestirli tramite *gruppi*::
882         require group staff studenti
883
884 I gruppi vengono definiti in un file in modo simile a ``/etc/groups`` per gli utenti di sistema::
885
886         staff:andrea sara
887         studenti: lucap federico luca
888
889 da richiamare tramite la direttiva ``AuthGroupFile``.
890
891 Cavets
892 -----------
893
894 Problemi di cache:
895         
896         * 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.
897
898         *  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.
899
900 Domain Name System
901 ====================
902
903 Domain Name System (spesso indicato con DNS) e' un servizio utilizzato per la risoluzione di nomi di host in indirizzi IP e viceversa. Il servizio e' realizzato tramite un sistema **gerarchico** (quindi una struttura ad albero, simile ai *file system*) **distribuito** (ogni server DNS facente parte del sistema puo' mantenere solo una parte delle informazioni, ad esempio per la sua sola *zona*), costituito dai server DNS.
904
905 I DNS sono un servizio *core* (fondamentale) per la rete internet come per qualunque rete locale. Ad esempio durante la navigazione web un client vorrebbe vedere l'*URL* ``http://ww.piffa.net/``, quindi per potersi connettere via *http* al server web deve prima ottenere l'indirizzo IP del *server http* corrispondente a *www.piffa.net*. 
906 Se il DNS gli fornisce un IP sbagliato l'utente non potra' raggiungere il servizio: di fatto e' come se il serve http fosse spento.
907
908 Stessa cosa vale per gli altri servizi, come la posta elettronica, ssh, ecc. : *prima si deve effettuare una query DNS*. 
909
910 Potrebbe verificarsi uno scenario simile a questo: i vostri server per i siti web funzionano correttamente come i siti ospitati, stessa cosa per i vostri server di posta, IMAP e POP3, e tutto il resto. Ma se poi un errore nella configurazione del DNS non rende raggiungibile l'intero *sito*: per l'utente finale e' come se nulla funzionasse.
911
912 Infatti quando si parla di un intervento della Polizia Postale per l'*oscuramento* di un sito dal punto di vista pratico questo si traduce generalmente nella rimozione o mistificazione del record DNS relativo a quel dominio (la *PP* ha facolta' di chiedere un simile intervento ai principali provider internet che forniscono connettivita' agli utenti italiani, oltre che poter agire direttamente sul NIC italiano per i domini della TLD *.it*)
913
914 L'operazione di convertire un nome in un indirizzo e' detta risoluzione DNS, convertire un indirizzo IP in nome e' detto risoluzione inversa.
915
916  Un *Registar* e' un operatore che ha la facolta' (accreditamento da parte dell ICANN) di registrare i domini di secondo livello per gli utenti finali, dietro compenso di una modica cifra (una decina di euro) che vale come contributo su base annuale per il mantenimento dell'infrastruttura. 
917
918 Risoluzione Inversa
919 -----------------------
920
921 Per la risoluzione inversa sono invece i provider di connettivita' a gestire i DNS: se volete impostare il *PTR* associato al vostro indirizzo IP dovete contattare il vostro provider (tipo *telecom* per una connessione ADSL) e *non il Registar del vostro dominio*.
922
923 Ad esempio all'IP ``212.22.136.248`` era associato un PTR ``bender.piffa.net``, corrispondente al record ``212`` facente parte della zona ``136.22.212.in-addr.arpa`` gestito dal provider Tiscali/Nextra proprietario della classe C ``212.22.136.0``. Se avete un solo IP conviene lasciare al fornitore la gestire del PTR, ma se avete a disposizione un'itera classe potete chiedere sempre al vostro provider che vi *deleghi* la gestione della zona tramite i vostri DNS.
924
925 Per alcuni servizi, ad esempio la spedizione della posta elettronica, e'  richiedeiesto  che venga impostata correttamente  l'associazione tra il PTR dell'indirizzo IP usato dal server di postai e il record A RR al quale questo punta( RFC1912 sezione 2.1, paragrafo 2). 
926
927 Si veda:
928
929 - http://www.faqs.org/rfcs/rfc1912.html 2.1 Inconsistent, Missing, or Bad Data
930 - http://www.ietf.org/rfc/rfc2505.txt 
931
932 Nomi di dominio
933 -----------------
934
935 Un nome a dominio e' costituito da una serie di stringhe separate da punti, ad esempio bender.piffa.net. I nomi di dominio si leggono da destra verso sinistra: *TLD* o  dominio di primo livello ``net``, secondo livello ``piffa``, terzo livello ``bender``. Il dominio di primo livello (o TLD, Top Level Domain, pronunciato *tilde* in Italia), per esempio .net o .it sono limitati e decisi direttamente dall'ente assegnatario ICANN ( Internet Corporation for Assigned Names and Numbers).
936
937 L'utente finale potra' chiedere l'assegnazione (pagando un contributo al Register preferito per il mantenimento delle spese dell'infrastruttura) di un dominio di *secondo* livello (es ``piffa``) di una delle varie TLD disponibili (noi italiani diciamo *tildi*), sempre che non sia gia' stato assegnato a qualcun altro.
938
939 Ottenuto il secondo livello sara' l'utente a gestirlo: potra' in stanziare domini di terzo livello (es ``bender``) e anche oltre (es www.andrea.bender.piffa.net). Tali records saranno mantenuti dall'utente, sotto la sua responsbilita': se il proprio server DNS non fosse raggiungibile o risultasse mal configurato gli utenti non potrebbero risolvere / raggiungere i siti di loro interesse.
940
941 Tipicamente si ha almeno un server DNS secondario per garantire la sussistenza del servizio in caso di guasto del DNS principale. I secondari *replicano* i dati presenti nei DNS principali.   
942
943 Tipologie di record
944 -----------------------
945
946 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:
947
948 * 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).
949 * Record MX - (Mail eXchange) indica a quali server debba essere inviata la posta elettronica per un certo dominio.
950 * 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.
951 * 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).
952 * Record AAAA - Restituisce un indirizzo IPv6.
953 * Record SRV - Identificano il server per un determinato servizio all'interno di un dominio. Possono essere considerati una generalizzazione dei record MX.
954 * Record TXT - Associano campi di testo arbitrari ad un dominio. Questi campi possono contenere una descrizione informativa oppure essere utilizzati per realizzare servizi.
955
956 Vi sono anche tipi di record "di servizio", necessari al funzionamento del database distribuito:
957 * Record NS - Utilizzato per indicare quali siano i server DNS autoritativi per un certo dominio, ovvero per delegarne la gestione.
958 * Record SOA - (Start of Authority) usato per la gestione delle zone DNS.
959
960 Utilizzo
961 ------------
962
963 I computer vengono identificati in rete grazie agli indirizzi *IP*, questi pero' non sono comodi per gli utenti come riferimento per i vari server. Ad esempio sarebbe scomodo riferirsi al motore di ricerca Goggle con uno dei suoi IP: ``74.125.43.104``, e' preferibile usare il nome di dominio *www.google.com*::
964
965         ping -c 1 www.google.com
966         PING www.l.google.com (74.125.43.104) 56(84) bytes of data.
967
968 Risoluzione dei nomi di dominio
969 ----------------------------------
970
971 Ci sono vari strumenti per interrogare i server DNS e ottenere l'indirizzo IP associato al nome di dominio che ci interessa::
972
973   $ host www.piffa.net
974   www.piffa.net is an alias for piffa.net.
975   piffa.net has address 65.98.21.97
976   piffa.net mail is handled by 10 65.98.21.97
977
978
979   $ nslookup www.piffa.net
980   Server:         192.168.0.10
981   Address:        192.168.0.10#53
982   
983   Non-authoritative answer:
984   www.piffa.net   canonical name = piffa.net.
985   Name:   piffa.net
986   Address: 65.98.21.97
987
988
989   $ dig www.piffa.net
990   
991   ; <<>> DiG 9.6.0-P1 <<>> www.piffa.net
992   ;; global options: +cmd
993   ;; Got answer:
994   ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47751
995   ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 4
996   
997   ;; QUESTION SECTION:
998   ;www.piffa.net.                 IN      A
999   
1000   ;; ANSWER SECTION:
1001   www.piffa.net.          3489    IN      CNAME   piffa.net.
1002   piffa.net.              3489    IN      A       65.98.21.97
1003   
1004   ;; AUTHORITY SECTION:
1005   piffa.net.              86289   IN      NS      ns2.mydomain.com.
1006   piffa.net.              86289   IN      NS      ns1.mydomain.com.
1007   piffa.net.              86289   IN      NS      ns4.mydomain.com.
1008   piffa.net.              86289   IN      NS      ns3.mydomain.com.
1009   
1010   ;; ADDITIONAL SECTION:
1011   ns1.mydomain.com.       96208   IN      A       64.94.117.193
1012   ns2.mydomain.com.       96208   IN      A       64.94.31.67
1013   ns3.mydomain.com.       96208   IN      A       66.150.161.137
1014   ns4.mydomain.com.       96208   IN      A       63.251.83.74
1015   
1016   ;; Query time: 1 msec
1017   ;; SERVER: 192.168.0.10#53(192.168.0.10)
1018   ;; WHEN: Sun May 10 21:23:11 2009
1019   ;; MSG SIZE  rcvd: 209
1020
1021 Lo strumento piu' esaustivo e' ``dig``, installabile con il pacchetto ``dnsutils`` .
1022
1023 Dig
1024 -----
1025
1026 Vediamo alcune opzioni utili nell'utilizzo di ``dig`` per l'interrogazione dei DNS Server::
1027
1028
1029         $ dig www.google.it
1030         
1031         ; <<>> DiG 9.6.0-P1 <<>> www.google.it
1032         ;; global options: +cmd
1033         ;; Got answer:
1034         ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18816
1035         ;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 7, ADDITIONAL: 0
1036         
1037         ;; QUESTION SECTION:
1038         ;www.google.it.                 IN      A
1039         
1040         ;; ANSWER SECTION:
1041         www.google.it.          250683  IN      CNAME   www.google.com.
1042         www.google.com.         334819  IN      CNAME   www.l.google.com.
1043         www.l.google.com.       186     IN      A       74.125.43.103
1044         www.l.google.com.       186     IN      A       74.125.43.104
1045         www.l.google.com.       186     IN      A       74.125.43.147
1046         www.l.google.com.       186     IN      A       74.125.43.99
1047         
1048         ;; AUTHORITY SECTION:
1049         l.google.com.           80856   IN      NS      f.l.google.com.
1050         l.google.com.           80856   IN      NS      d.l.google.com.
1051         l.google.com.           80856   IN      NS      b.l.google.com.
1052         l.google.com.           80856   IN      NS      c.l.google.com.
1053         l.google.com.           80856   IN      NS      a.l.google.com.
1054         l.google.com.           80856   IN      NS      e.l.google.com.
1055         l.google.com.           80856   IN      NS      g.l.google.com.
1056         
1057         ;; Query time: 1 msec
1058         ;; SERVER: 192.168.0.10#53(192.168.0.10)
1059         ;; WHEN: Sun May 10 21:34:47 2009
1060         ;; MSG SIZE  rcvd: 255
1061
1062 $ dig
1063         (senza opzioni o oggetti) Fornisce l'elenco dei *root server* utilizzati. I root server sono i server che mantengono le informazioni sui domini di primo livello (TLD) e sono quindi il punto di partenza per scorrere nella directory dei DNS per recuperare le informazioni (tipicamente un campo ``A`` per un indirizzo IP) che ci servono per raggiungere un certo servizio.
1064
1065 $ dig
1066
1067         ...
1068         
1069         ;; ANSWER SECTION:
1070         .                       192032  IN      NS      C.ROOT-SERVERS.NET.
1071         .                       192032  IN      NS      E.ROOT-SERVERS.NET.
1072         .                       192032  IN      NS      B.ROOT-SERVERS.NET.
1073         .                       192032  IN      NS      L.ROOT-SERVERS.NET.
1074         .                       192032  IN      NS      A.ROOT-SERVERS.NET.
1075         .                       192032  IN      NS      F.ROOT-SERVERS.NET.
1076         .                       192032  IN      NS      H.ROOT-SERVERS.NET.
1077         .                       192032  IN      NS      G.ROOT-SERVERS.NET.
1078         .                       192032  IN      NS      K.ROOT-SERVERS.NET.
1079         .                       192032  IN      NS      M.ROOT-SERVERS.NET.
1080         .                       192032  IN      NS      I.ROOT-SERVERS.NET.
1081         .                       192032  IN      NS      J.ROOT-SERVERS.NET.
1082         .                       192032  IN      NS      D.ROOT-SERVERS.NET.
1083         
1084         ...
1085
1086 dig @nome_dns 
1087         Permette di fare una query ad un server dns particolare. 
1088         Es: ``dig @151.99.25.1 www.google.it``
1089
1090 dig MX www.google.it
1091         Chiede un campo in particolare, in questo caso il campo MX
1092
1093 dig ANY www.google.it
1094         Chiede tutti i campi, non solo i campi *a*
1095
1096 dig -x 74.125.43.104
1097         Effettua una richiesta inversa: dall'IP al PTR associato.
1098
1099 resolv.conf
1100 -----------------
1101
1102 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.
1103
1104 /etc/resolv.conf:
1105
1106         - ``nameserver``: indica il nameserver da utilizzare, indicato con l'indirizzo IP.
1107
1108         - ``domain``: indica il nome di dominio della rete attuale, vedi voce successiva.
1109
1110         - ``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``.
1111
1112 Predisponendo l'infrastruttura di rete della vostra LAN e' consigliabile impostare sempre un DNS cache sul vostro server locale per i vari client. In questo modo in caso di malfunzionamento del DNS o necessita' di intervenire / sostituire i DNS non sara' piu' necessario dover reimpostare ogni singolo client della LAN: bastera' modificare l'impostazione del server DNS cache, ad esempio per utilizzare un nuovo forwarder, o modificare al volo un record DNS. La modifica, anche detta *mascheramento*, di un record come il *server smtp* o un *MX* potrebbe tirarvi rapidamente fuori dai guai nel caso di un problema improvviso con la posta elettronica o qualunque altro servizio che possiate reindirizzare col DNS.
1113
1114 Un server DHCP e un DNS cache come ``Dnsmasq`` possono permettervi di risolvere al volo (o per lo meno reindirizzare) molte delle problematiche relative alla configurazione della rete della vostra LAN: dover intervenire manualmente su decine di client per modificare le impostazioni di SMTP | gateway | SMTP | proxy.
1115
1116 Si veda anche la pagina man di resolv.conf.
1117
1118 .. warning::
1119         Attenzione: se si usa un client DHCP, ppp (ADSL compresa)  o simile questo file potrebbe' essere riscritto automaticamente in base a quanto ottenuto dal DHCP. Si veda la documentazione del pacchetto ``resolvconf``.
1120
1121
1122 /etc/hosts
1123 ---------------
1124
1125 Tabella statica per l'associazione tra IP e nomi di dominio::
1126
1127 # cat /etc/hosts
1128
1129         127.0.0.1       localhost.localdomain   localhost
1130         10.10.208.162   daniela         daniela.piffa.net
1131         10.10.208.254   mirror          mirror.piffa.net
1132         91.191.138.15   thepiratebay.org
1133         192.168.0.11    chrome  chrome.mydomain.com
1134
1135 Il contenuto e' un associazione tra un *IP* e stringhe di testo (anche piu' di una per IP) es: ``mirror`` e ``mirror.piffa.net``.
1136
1137 Il problema e' la gestione di questo file: quando gli host cambiano IP si devono aggiornare i records, e poi c'e' il problema di distribuire questo file tra i vari hosts della propria LAN. Un metodo semplice per distribuire questo file e' utilizzare ``Dnsmasq``: questo infatti legge e onora il file ``hosts`` che avete prodotto e lo *distribuisce* ai clients tramite le normali query DNS.
1138
1139 Modificare (riconducendola a un IP interno, cosi' annullandola) la risoluzione di un nome di dominio e' un modo drastico e funzionale per *annullarlo* rendendolo indisponibile alla propria rete locale, ad esempio aggiungere al file ``/etc/hosts``::
1140         
1141          127.0.0.1       www.facebook.com 
1142
1143 Impedira' agli utenti della LAN di raggiungere *facebook*, ora reindirizzato a i``localhost``.
1144
1145
1146 Hostname
1147 ------------
1148
1149 Ogni computer ha un *proprio nome* visualizzabile (e modificabile) con il comando ``hostname``.
1150
1151 Per modificare in modo permanente il nome del computer si modifichi il contenuto del file ``/etc/hostname``.
1152
1153 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.
1154 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::
1155
1156         * Squid: ``visible_hostname``
1157
1158         * Postfix: ``myhostname``
1159
1160 Si faccia attenzione a non aver un hostname puramente numerico: ad es. ``161``. E' opportuno che il nome sia comunque un alfanumerico: ``host-161`` o simile.
1161         
1162 DNSmasq
1163 ========
1164
1165 Dnsmasq puo' svolgere le funzioni di  un DNS cache / forwarder, server DHCP, e' caratterizzato dalla facilita' di configurazione, limitato uso di risorse, adattabilita' a connessioni *dinamiche* come ADSL o altre punto a punto (anche via cellulari) per condividere rapidamente la rete (cosa molto utile se ci dovesse trovare a ridare connettetivita' a una rete momentaneamente sprovvista),  dalla possibilita' di modificare rapidamente i record DNS serviti alla rete anche grazie alla distribuzione del file ``/etc/hosts`` locale. Puo' essere anche utilizzato come `server per il boot da rete <http://www.debian-administration.org/articles/478>_` .
1166
1167 Dnsmasq e' un interessante alternativa all'uso del server DNS Bind in modalita' *forwarding e cache-only* (non autoritativo) accompagnato dal server DHCPd. I vantaggi sono:
1168
1169 - Leggerezza: puo' essere fatto girare su una macchina relativamente debole in caso di bisogno.
1170 - Rapidita' di configurazione (in particolare per servire dei record A / MX alla rete, modificando al volo i valori originali ospitati sul server DNS pubblico).
1171 - Ben integrato con connessioni PPP : e' ingrado di rilevare i cambiamenti dei dns suggeriti e impostarli come forwarders (utile se dovete rendere disponibile rapidamente una connessione a internet a una rete in difficolta').
1172
1173 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. 
1174 Molto utile per scopi didattici, sopratutto per testare server SMTP impostando al volo i campi MX per nomi di dominio fittizi.
1175
1176
1177 Configurazione
1178 -----------------
1179
1180 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:
1181
1182
1183 domain-needed
1184         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* .
1185
1186
1187 bogus-priv
1188         Simile alla voce precedente ma per i reverse look-up.
1189
1190
1191 domain
1192         Nome di dominio della rete da passare ai client.
1193
1194
1195 expand_hosts
1196         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.
1197
1198
1199 DHCP
1200 -----------
1201
1202 Per attivare il demone DHCP di Dnsmasq basta aggiungere al file di configurazione il *range* degli IP che si vuole assegnare ai client con il *lease time* (tempo di rilascio: quanto a lungo saranno validi gli IP assegnati) espresso in ore.
1203
1204 Si faccia *attenzione*: in una rete puo' essere presente **un solo server DHCP**, o per meglio dire qualunque server DHCP ascolta sul broadcast ``255.255.255.255`` e potrebbe rispondere a un pacchetto di richiesta DHCP. Quindi non fate partire inavvertitamente un server DHCP in una rete gia' servita e **non vi azzardate ad andare in giro con un portatile con un server DHCP attivo** nelle reti altrui. Questo vale anche per i laboratori di informatica dei corsi di reti: non fate partire il vostro server DHCP se siete collegati alla rete interna!
1205
1206 /etc/dnsmasq.conf (riga 118)::
1207
1208         dhcp-range=192.168.0.20,192.168.0.50,24h 
1209
1210 DNS cache
1211 -----------
1212
1213 Dnsmasq lavora di default come cache dns: inserire al file ``/etc/resolv.conf`` il nameserver localhost in cima alla lista dei *nameserver* disponibili. 
1214         
1215         nameserver      127.0.0.1
1216
1217
1218 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`` ::
1219
1220         prepend domain-name-servers 127.0.0.1;
1221
1222 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!).
1223
1224
1225 Bind : DNS Autoritativo
1226 ===========================
1227
1228 Le soluzioni viste possono bastare per la rete locale o per fare delle prove, ma prima o poi verra' il momento in cui si e' chiamati a gestire dei domini su internet: lo standard e' da sempre *Bind* ( demone *named*), ora alla versione 9.
1229
1230 Installare i pacchetti::
1231         
1232         bind9
1233
1234 DNS cache
1235 -------------
1236
1237 Bind appena installato funzionera' come DNS cache: si faccia un test con un ``dig @localhost`` . Bind a differenza di Dnsmasq e' autonomo: non ha bisogno di forwardare (inoltrare) le query a un DNS esterno: queste verranno risolte direttamente da Bind partendo dai *DNS root servers*.  
1238
1239 E' comunque possibile impostare dei DNS forwarders, tipicamente i DNS server forniti dal proprio provider, per velocizzare le query:
1240
1241 /etc/bind/named.conf.options  (riga 13)::
1242
1243        forwarders {
1244                         10.10.208.254;
1245                   }; 
1246
1247 Nel caso si voglia usare Bind solo come server DNS cache per la propria LAN senza ospitare delle zone DNS pubbliche sara' il caso di limitare gli accessi al server alla sola LAN:
1248
1249 /etc/bind/named.conf.options  (riga 19)::
1250         
1251         // Se il proprio server ha IP 10.10.208.254 
1252         // sulla rete LAN privata:
1253         listen-on { 10.10.208.254; }
1254
1255 E non si lasci il server in ascolto su uno degli eventuali indirizzi IP pubblici.
1256
1257 Se questo non fosse possibile si puo' sempre lavorare su una *acl*:
1258
1259 /etc/bind/named.conf ::
1260         
1261         acl "localnet" {
1262                 10.10.208.0/24 ; 127.0.0.0/8 ;
1263                 } ;
1264
1265 Per poi aggiungere all'interno della stanza options la direttiva che abilita' l'entita' ``localnet``:
1266
1267 /etc/bind/named.conf.options ::
1268
1269         allow-query {"localnet" ;} ;
1270
1271
1272 Ospitare una zona
1273 ---------------------
1274
1275 Se avete acquistato un nome di dominio e vi serve un software DNS per gestirlo Bind e' la scelta piu' diffusa. Ora vedremo come configurare una *zona* (come piffa.net) in modo che Bind sia autoritativoper questa, rispondendo alle query DNS di tutta la rete internet.
1276
1277
1278 named.conf.local
1279 ~~~~~~~~~~~~~~~~
1280
1281 Prima di tutti impostiamo il server bind per gestire la zona, per non fare confusione e' opportuno inserire le propie zone DNS nel file ``named.conf.local`` e non in ``named.conf``.
1282
1283 named.conf.local::
1284
1285         /
1286         // Do any local configuration here
1287         //
1288
1289         // Consider adding the 1918 zones here, if they are not used in your
1290         // organization
1291         //include "/etc/bind/zones.rfc1918";
1292
1293         zone "piffa.net" {
1294                 type master;
1295                 file "/etc/bind/pz/piffa.net";
1296                 }
1297
1298 type master
1299         Il nostro server DNS sara' il principale, al quale poi potremo affiancare dei DNS secondari nel caso questo non sia disponibile.
1300
1301 file "/etc/bind/pz/piffa.net"
1302         Dove verranno inserite le informazioni vere e propie di questa zona.
1303
1304 Configurazione della zona
1305 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
1306
1307 Ora dovremo preparare il file contenente i record DNS della zona *piffa.net*, come abbiamo indicato prima questi saranno contenuti nel file ``/etc/bind/pz/piffa.net`` . Tenere le zone dentro una sottocartella e' buona abitudine, usare ``pz`` per queste e' una vecchia abitudine.
1308
1309 piffa.net::
1310
1311         ; Zona per il dominio di secondo livello piffa.net
1312
1313         $TTL 3D     ; 3 days
1314         @                    IN SOA  ns1.piffa.net. hostmaster.piffa.net. (
1315                                         200905245  ; serial
1316                                         8H         ; refresh (8 hours)
1317                                         2H         ; retry (2 hours)
1318                                         4W         ; expire (4 weeks)
1319                                         1D         ; minimum (1 day)
1320                                         )
1321         ;
1322                                 NS      ns1
1323                                 NS      ns2
1324                                 A       94.23.63.105
1325                                 MX      10 smtp
1326                                 TXT     "Piffanet main site"
1327         ;
1328         ns1             A       94.23.63.105
1329         ns2             A       65.98.21.97
1330         zoo             A       94.23.63.105
1331         smtp            A       94.23.63.105
1332         test.piffa.net. A       94.23.63.105
1333         *.piffa.net.    A       94.23.63.105 ; *catch all domain
1334         www             CNAME   zoo
1335         ftp             CNAME   zoo
1336
1337
1338
1339 All'interno di questo file si possono inserire dei commenti con il carattere ``;`` (punto-e-virgola), si faccia attenzione alla rigida sintassi: apertura e chiusura delle parentesi tonde nella parte ``IN SOA``, uso del ``punto`` finale per precisare un nome di dominio specifico (*FQDN*:  Fully-qualified Domain Name) come ``test.piffa.net.`` a differenza degli altri domini di terzo livello come ``pop,imap,smtp`` .
1340
1341 La zona inizia con una direttiva ``$TTL 3D`` (RFC 2308) che indica la durata (in questo caso tre giorni) che ogni record dovrebbe avrebbe nella cache degli altri serber DNS. Questo valore dovrebbe essere superiore a un giorno, se non modificate spesso i valori dei vostri record DNS e' consigliabile settarlo a 2/3 settimane in modo da limitare la frequenza delle query al propio server. Questo parametro puo' essere modificato per singoli record::
1342
1343         $TTL 3D     ; 3 giorni: default se non specificato altrimenti
1344         rapido  5h      IN      A       94.23.63.105 ; usa un TTL di 5 ore
1345         lento   3w      IN      A       94.23.63.105 ; usa un TTL di 3 settimane
1346         normale         IN      A       94.23.63.105 ; usa il TTL di default: 3 giorni
1347
1348
1349 Segue poi il nome della zona, indicato con la ``@`` per richiamare la zona originale precisata nel file ``named.conf.options`` . Segue il campo ``SOA``.
1350
1351 SOA: Start of Authority Record
1352 `````````````````````````````````
1353
1354 Il record SOA puo' comparire solo una volta in una zona, contiene informazioni relative all'autorita' del server DNS.
1355
1356 ns1.piffa.net. name-server
1357         primary master DNS di questo dominio.
1358
1359 hostmaster.piffa.net. email-addr
1360         email-addr: indirizzo email della persona responsabile di questa zona, il primo punto viene tradotto in una *chiocciola* ``@`` dato che questo carattere ha un'altro utilizzo all'interno di questo file. Il referente della zona **deve** essere un email valido e controllato, come consuetudine si usa ``hostmaster@dominio.tilde`` .
1361
1362 200905245 serial number
1363         Questo valore serve per indicare quando e' stato modificato questo file di configurazione, secondo il formato ``yyyymmddss``: ``yyyy`` = anno, ''mm'' = mese, ''dd'' = giorno, ''ss'' = seriale. Il seriale che deve essere sempre specificato anche per una cifra, va incrementato di una unita' nel caso vengano fatte piu' modifiche *nello stesso giorno*.
1364
1365 8H refresh
1366         Indica ai DNS secondari quanto tempo attendere per cercare di aggiornare i loro dati con il DNS master.
1367
1368 2H retry
1369         Intervallo di tempo per il DNS slave (secondario) da aspettare prima di cercare di ricontattare il *master* in caso di problemi col *refresh*.
1370
1371 4W expire
1372         Indica quando i dati dei dns secondarinon sono piu' autoritativi in caso di impossibilita' degli *slaves* di ri-aggiornarsi con il *master*. Consigliato un valore di 2/4 settimane.
1373
1374 1D minimum
1375         Questo valore indicava il TTL fino alla versione 8 di Bind, da Bind 9 e secondo la RFC2308 indica la durata del *negative caching*, quanto i resolvers (ad esempio un server dns cache) puo' mantenere un record *negativo* (che non indica la corrispondenza tra un nome di dominio e un ip, ma la non esistenza del record). Nell'uso per il negative caching viene fissato un valore massimo di 3 ore dalla RFC 2308.
1376
1377
1378 Altri campi:
1379 ```````````````
1380
1381 All'interno della zona possono essere utilizati vari tipi di records (RR):
1382
1383 TXT
1384         Informazioni testuali associate ad un record
1385
1386 NS
1387         Name Server della zona. Non deve essere un cname.
1388
1389 A
1390         Indirizzo ipv4 da associare al record
1391
1392 AAA
1393         Indirizzo ipv6 da associare al record
1394
1395 CNAME
1396         Canonical Name: un alias per un host: ad esempio per il dominio piffa.net possiamo settare degli alias come ``www.piffa.net, http.piffa.net, virtual.piffa.net, ftp.piffa.net, imap.piffa.net``. Comodo quando diversi alias sono sempre riferiti allo stesso ip.
1397
1398 MX
1399         Mail Exchanger: server di posta che si occupera' della posta elettronica per questo dominio.E' opportuno avere almeno un server di posta di back-up, per indicare la priorita' di un MX rispettoad un altro si usa un valore di 2 cifre: il valore piu' basso indica priorita' piu' bassa. Es: ``MX    10 smtp.piffa.net.`` per il server SMTP principale e ``MX      40 smtp2.piffa.net`` per il secondario. Non deve essere un cname.
1400
1401 PTR
1402         Reverse look-up, usato per la mappatura inversa di un indirizzo ip a una stringa identificativa dell'host. Si noti che per poter modificare questi record si deve avere *in gestione* la *zona IP*, se cosi' non fosse si dovra' chiedere al propio provider la modifica di questo record per il propio ip. Links: http://www.zytrax.com/books/dns/ch3/
1403
1404 DNS slave
1405 -------------
1406
1407 Data l'importanza del servizio DNS e' necessario avere ridondanza per i server DNS che ospitano i vostri dati: in caso di indisponibilita' del server *master* (nel caso fosse il solo a tenere i dati questo comporterebbe la *scomparsa* di tutti i servizi / host da esso seviti!) il client potrebbe contattare uno degli *slave*.
1408
1409 Gli slave recuperano i dati dei recordos RR direttamente dal master e non sara' quindi necessario dover mantenere manualmente il file di configurazione della zona sugli slaves, ogni volta che aggiorneremo il master questi dati si  propaghera' agli slaves automaticamente.
1410
1411 Per attivare uno *slave* per la nostra zona di esempio ``piffa.net`` si inserisca nel file ``named.conf.local`` dello slave server::
1412
1413         zone "piffa.net" {
1414                 type slave;
1415                 file "/etc/bind/pz/piffa.net";
1416                 masters { 192.168.0.1; };
1417                 };
1418         
1419 Facendo ripartire Bind il file ``/etc/bind/pz/piffa.net`` viene creato automaticamente.
1420
1421 Segue un estratto di ``/var/log/syslog`` al ``restart`` di ``bind9`` sullo slave::
1422
1423         ... slave named[2256]: zone piffa.net/IN: loaded serial 200905245
1424         ... slave named[2256]: running
1425         ... slave named[2256]: zone piffa.net/IN: sending notifies (serial 200905245)
1426         ... slave named[2256]: client 192.168.0.1#1464: received notify for zone 'piffa.net'
1427         ... slave named[2256]: zone piffa.net/IN: notify from 192.168.0.1#1464: zone is up to date
1428
1429 .. warning::
1430         Bind9 (versione 9.3 presente in Debian Lenny) richiede una esplicita autorizzazione alla notifica per lo stesso server slave, che in fase di avvio interroghera' (inviando un notify) se' stesso per valutare se i dati relativi alla zona di cui e' slave sono aggiornati. Si aggiunga quindi al file ``/etc/bind/named.conf.options`` dello slave: ``allow-notify { 192.168.0.1; };`` all'interno della stanza ``options``, in cui l'inidirizzo IP inserito e' quello dello stesso slave server.
1431
1432 Aggiornamento dinamico: nsupdate
1433 ----------------------------------
1434
1435 Dalla versione 8 di Bind e' dsponibile l'utility ``nsupdate`` (disponibile nel pacchetto ``dnsutils``) per aggiornare automaticamente i record di una zona secondo il paradigma client / server ( RFC2136 ) . Posto che abbiate a disposizione un server DNS Bind on-line su un indirizzo IP fisso e un zona da gestire (che potrebbe essere anche solo la delega di un dominio di terzo livello come *casa.miodominio.net*) sara' possibile aggiornare automaticamente i record che tirano a degli indirizzi IP *pubblici ma dnamici*, come quelli spesso messi a disposizione dei provider per le connessioni ad internet residenziali, in modo da poter rendere sempre raggiungibile la vostra workstation a casa anche dopo un aggiornamento dell'ip dinamico associato alla connessione.
1436
1437 L'auenticazione del client nsupdate che avra' la possibilita' di aggiornare il server DNS master avviene tramite *Transaction signatures* (TSIG, RFC2845) usando un algoritmo di criptazione dati asimmetrico *HMAC-MD5* : generata una coppia di chiavi sul client / nsupdate  con l'utility  si dovra' trasferire la chiave pubblica sul server *master*, che verra' configurato per onorare gli aggiornamenti (eliminazione e inserimento di record RR) autenticati dalla chiave privata.
1438
1439 Configurazione client (nsupdate)
1440 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1441
1442 Sul client, sul quale non deve essere necessariamente  installato un server DNS Bind ma la sola utility ``nsupdate``, generiamo la coppia di chiavi con l'utility ``dnssec-keygen`` installabile tramite il pacchetto  ``bind9utils``::
1443         
1444         dnssec-keygen -a HMAC-MD5 -b 512 -n USER home.piffa.net.
1445
1446 Otterremo le due chiavi ``Khome.piffa.net.+157+04331.key  Khome.piffa.net.+157+04331.private``, la chiave pubblica dovra' essere resa noto al server master che ricevera' l'update dei records. 
1447
1448 Configurazione server: riconoscimento chiave
1449 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1450
1451 Per rendere nota al server la chiave pubblica generata sul client si aggiunga quindi al file ``/etc/bind/named.conf`` sul server::
1452         key home.piffa.net. {
1453                 algorithm HMAC-MD5;
1454                 secret "txfAkNTScANEu2V73mCeiDpXNc3pmf+7ONOoKnTKQKIZMzierSmeHjK5 Z8ntnByt/PJwv26jCIsVh8n+xzVsRw==";
1455                 };
1456
1457 .. note::
1458         La parte ``secret``, che potete leggere direttamente nel file \*.key della chiave genearta, e' scritto *tutto sulla stessa riga* senza ritorni a capo.
1459
1460
1461 Server: gestione dell'intera zona
1462 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1463
1464 Sul server modifichiamo il file di configurazione ``named.conf.local`` della zona della quale vogliamo concedere l'aggiornamento al client::
1465         
1466         zone "piffa.net" {
1467                 type master;
1468                 file "/etc/bind/pz/piffa.net" ;
1469                 allow-update {
1470                                 key  home.piffa.net;
1471                                 };
1472         };
1473
1474 Sara' necessario assicurarsi che il demone di Bind sia in grado di modificare il file ``/etc/bind/pz/piffa.net``: dato che questo file ora sara' gestito da lui si proceda a cedergli la propieta' del file::
1475         chown bind /etc/bind/pz/piffa.net
1476
1477 Altro problema che si potrebbe porre: gli orologi di sistema dei due host devono essere sincronizzati per poter valutare l'opportunita' di un aggiornamento: si consigla di installare su entrambi l'utility ``ntpdate`` e di eseguirla facendo riferimento ai time server di Debian::
1478
1479         apt-get install ntpdate
1480         ntpdate-debian
1481
1482
1483 Ora possiamo provare dal client a effettuare l'iserimento di un record per testarne il funzionamento::
1484
1485         # nsupdate -k Khome.piffa.net.+157+04331.private -v
1486         > server ns1.piffa.net
1487         > update add home.piffa.net. 86400 A 192.168.0.2
1488         > show
1489         Outgoing update query:
1490         ;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id:      0
1491         ;; flags: ; ZONE: 0, PREREQ: 0, UPDATE: 0, ADDITIONAL: 0
1492         ;; UPDATE SECTION:
1493         home.piffa.net.         86400   IN      A       192.168.0.1
1494         
1495         
1496         > send
1497
1498 Per comprendere meglio l'uso dell'utility ``nsupdate`` si consiglia la lettura della relativa pagina man. Nella prima riga viene invocato il comando ``nsupdate`` impostando col *flag* ``-k`` la chiave *privata* generata precedentemente, con ``server`` si imposta quale server NS autoritario della zona (che abbiamo precedentemente configurato per ricevere gli aggiornamenti) vogliamo contattare. Alla riga sucessiva ``update`` viene aggiunto un record ``A`` per la il dominio ``home.piffa.net`` indirizzato all'IP ``192.168.0.2``, poi ``show`` mostra quanto ci si prepara a comunicare al server con il finale ``send`` .
1499
1500 Si noti che in questo modo *l'intera* zona piffa.net e suscettibile di essere modificata dal client, che potra' eliminare e inserire qualunque record. E' possibile gestire in modo piu' granulare la zona, ad esempio concedendo al client i privilegi per gestire solo una parte della zona o i tipo di record da gestire.
1501
1502
1503 Link suggeriti:
1504 ----------------
1505
1506 * DNS for Rocket Scientists http://www.zytrax.com/books/dns/
1507 * DNS HOWTO http://www.langfeldt.net/DNS-HOWTO/BIND-9/
1508
1509 Samba
1510 ======
1511
1512 Samba e' un progetto libero che fornisce servizi di condivisione di file e stampanti a client SMB/CIFS.
1513
1514 Samba e' liberamente disponibile, al contrario di altre implementazioni SMB/CIFS, e permette di ottenere interoperabilita' tra Linux, Unix, Mac OS X e Windows.
1515
1516 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.
1517
1518 Pacchetti
1519 --------------
1520
1521 Pacchetti da installare per utilizzare Samba in modalita' client [#]_ ::
1522
1523         samba-client
1524
1525 Pacchetti da installare per utilizzare Samba in modalita' server::
1526
1527         samba smbfs smbclient
1528
1529 .. [#] 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``.
1530
1531 Durante la prima installazione viene chiesto il nome del gruppo di appartenenza, il default per Windows e' ``WORKGROUP``. In aula usiamo invece ``208`` . 
1532
1533 Per riconfigurare Samba si usi il comando::
1534
1535         dpkg-reconfigure samba-common
1536
1537 Passwords e autenticazione
1538 ---------------------------
1539         
1540 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:
1541
1542 1 Sistema \*Unix ( GNU/Linux )
1543           E' la password dell'*utente di sistema* che viene usata sul sistema operativo su cui gira il software Samba. E' importante tenere conto anche delle *user-id* e *group-id* degli utenti che dovranno fisicamente scrivere sui file system. Se un utente non puo' scrivere in una certa posizione del file system (ad esempio nella cartella ``/mnt/condivisione`` che sara' stata necessariamente creata inizialmente dall'utente ``root``)  per mancanza dei privilegi di scrittura allora neanche Samba potra' farlo nel momento in  mette a disposizione la risorsa all'utente. Se si montano file-system dedicati per le condivisioni controllare i permessi e proprieta' dei *punti di mount**.
1544           Queste passwords sono salvate nel solito file /etc/shadow (richiamato da /etc/passwd).
1545
1546 2 Password per l'applicativo Samba
1547           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`` .
1548
1549 3 Password per Windows.
1550           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.
1551
1552
1553 Creazione Utenti
1554 -------------------
1555
1556 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!
1557
1558 Creazione di un utente denominato sambo::
1559         
1560         adduser --shell /bin/false sambo
1561
1562 Nel file ``/etc/passwd`` avremo qualcosa come::
1563
1564         sambo:x:1001:1001:Sambo utente Samba,,,:/home/sambo:/bin/false
1565
1566
1567 Aggiunta dell'utente al database delle password per Samba e generazione della sua password::
1568         
1569         smbpasswd -a sambo
1570
1571 Se successivamente si vorra' modificare la password di un utente gia' esistente si usi::
1572
1573         smbpasswd  sambo
1574
1575
1576 La password sotto Windows verra' modificata sul sistema Windows.
1577
1578 Creare la condivisione
1579 ------------------------
1580
1581 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.
1582
1583 Creazione della risorsa sambo_share nella home dell'utente sambo::
1584
1585         # mkdir /home/sambo/sambo_share
1586         # chown sambo:sambo /home/sambo/sambo_share/
1587
1588 Sicurezza: permessi di esecuzione sul server
1589 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1590
1591 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. 
1592 Si potrebbe avere quindi, ipotizzando una condivisione in ``/mnt/share`` che risieda su di un file system dedicato:
1593
1594 ``/etc/fstab`` 
1595
1596         /dev/hda10       /mnt/share      ext3    rw, **nosuid,noexec**  0  3
1597
1598 Si noti anche l'uso di *nosuid* per evitare la possibilita' di eseguire programmi con credenziali diverse.
1599
1600 Configurazione dell'applicativo Samba vero e proprio.
1601 ------------------------------------------------------
1602
1603 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.
1604
1605
1606 /etc/samba/smb.conf riga ~235 , Share Definitions (in vim si usi 235gg )::
1607
1608     [sambo_share]
1609             # Percorso della cartella condivisa
1610             path = /home/sambo/sambo_share
1611             # Se gli utenti possono scrivere / modificare file
1612             writable = yes
1613             # Negoziazione degli accessi su base utenti / passwords
1614             valid users = sambo
1615
1616             # ####################################### 
1617             # Altri parametri opzionali di interesse
1618             # Se posso vedere la condivisione da esplora risorse
1619             # anche se non ho i privilegi per accedervi.
1620             browseable = yes
1621             # Commento indicativo della risorsa
1622             comment = Condivisione per Sambo
1623
1624 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`` .
1625
1626
1627 Creazione di un gruppo
1628 ~~~~~~~~~~~~~~~~~~~~~~~~~
1629
1630 Se si deve condividere una risorsa con un numero consistente di utenti e' consigliabile lavorare in termini termini di gruppi piuttosto che elencare la lista degli utenti in ``valid users``.
1631
1632 Dopo aver creato il gruppo del quale volete facciano parte i vostri utenti (``addgroup nome_gruppo``), inserite i vostri utenti nel gruppo (``adduser nome_utente nome_gruppo``) e modificate la direttiva ``valid users`` in ``smb.conf`` per riferirsi ad un gruppo piuttosto che a degli utenti. Per riferirsi a un gruppo si usi il carattere ``@ chicciola`` col ``nome_del_gruppo``::
1633
1634         # Negoziazione degli accessi su base gruppo
1635         valid users = @nome_gruppo
1636
1637
1638 Testare il Servizio
1639 --------------------
1640
1641 Come testare il servizio
1642
1643 es::
1644         
1645          smbclient -U sambo -L localhost
1646
1647 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::
1648
1649         Sharename       Type      Comment
1650         ---------       ----      -------
1651         sambo_share     Disk      Condivisione per Sambo
1652         print$          Disk      Printer Drivers
1653         IPC$            IPC       IPC Service (base server)
1654         sambo           Disk      Home Directories
1655
1656 In particolare l'ultima voce relativa alla home directory dell'utente dovrebbe essere visibile solo agli utenti autenticati.
1657
1658 In alternativa e' possibile montare realmente la condivisone anche su GNU/Linux tramite un client per samba e testarne il corretto funzionamento::
1659
1660         mount -t smbfs //localhost/sambo_share /mnt/sambo_mount/ --verbose -o user=sambo 
1661
1662 Server di posta: Postfix
1663 ============================
1664
1665 Il server di posta che prenderemo in considerazione e' Postfix, a seguire un estratto di un file di configurazione *semplice* con l'abilitazione delle *Maildir* nelle ``/home`` degli utenti per la consegna della posta:
1666
1667 ``/etc/postfix/main.cf``::
1668
1669         # ...segue dalla riga ~30
1670         myhostname = 162.piffa.net
1671         alias_maps = hash:/etc/aliases
1672         alias_database = hash:/etc/aliases
1673         myorigin = 162.piffa.net
1674         mydestination = 162.piffa.net, localhost
1675         # Se non avete un ip pubblico e statico, con un adeguato record PTR
1676         # dovrete usare un realy host per l'invio della posta
1677         relayhost = smtp.piffa.net
1678         
1679         mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
1680         # Se dovete inviare la posta per i client della vostra LAN privata:
1681         # mynetworks = 127.0.0.0/8 192.168.0.0/24 [::ffff:127.0.0.0]/104 [::1]/128
1682         # E si faccia BEN ATTENZIONE a non diventare un open realay smtp
1683
1684
1685         # Per effettuare lo storaggio della posta nelle home directory degli utenti
1686         # in una Maildir invece che nella Mailbox in /var/mail/nome_utente
1687         # si disabiliti procmail
1688         #mailbox_command = procmail -a "$EXTENSION"
1689
1690         # cartella_i abiliti lo storaggio della posta nella Maildir/ (si noti lo slash)
1691         # all'interno della  home dell'utente:
1692         home_mailbox = Maildir/
1693         mailbox_size_limit = 0
1694         recipient_delimiter = +
1695         inet_interfaces = all
1696
1697
1698 E' disponibile un file di configurazione di esempio ben piu' articolato e commentato::
1699          /usr/share/postfix/main.cf.dist .
1700
1701 Test del server smtp
1702 -----------------------
1703
1704 Per testare il corretto funzionamento del server di posta si puo' procedere in vari modi.
1705
1706 - Spedire una mail a una casella locale / remota e controllare i log (syslog)
1707 - Collegarsi via *telnet* al server di posta: http://www.netadmintools.com/art276.html
1708 - usare una utility come SWAKS
1709
1710 Swaks
1711 ~~~~~~~~~~~
1712
1713 Per gli utenti meno esperti e' consigliabile utilizzare *SWAKS*: si installi l'omonimo pacchetto e si esegua un test con::
1714          swaks --to utente@destinatario.tilde --from utente@propio.mail.tilde
1715
1716 Ecco un esempio di una sessione corretta::
1717
1718         swaks --to andrea@piffa.net from andrea@mydomain.com
1719         === Trying smtp.piffa.net:25...
1720         === Connected to smtp.piffa.net.
1721         <-  220 zoo.piffa.net ESMTP Postfix (Debian/GNU)
1722          -> EHLO alice.mydomain.com
1723         <-  250-zoo.piffa.net
1724         <-  250-PIPELINING
1725         <-  250-SIZE 10240000
1726         <-  250-VRFY
1727         <-  250-ETRN
1728         <-  250-STARTTLS
1729         <-  250-ENHANCEDSTATUSCODES
1730         <-  250-8BITMIME
1731         <-  250 DSN
1732          -> MAIL FROM:<root@alice.mydomain.com>
1733         <-  250 2.1.0 Ok
1734          -> RCPT TO:<andrea@piffa.net>
1735         <-  250 2.1.5 Ok
1736          -> DATA
1737         <-  354 End data with <CR><LF>.<CR><LF>
1738          -> Date: Thu, 28 May 2009 13:11:19 +0200
1739          -> To: andrea@piffa.net
1740          -> From: root@alice.mydomain.com
1741          -> Subject: test Thu, 28 May 2009 13:11:19 +0200
1742          -> X-Mailer: swaks v20061116.0 jetmore.org/john/code/#swaks
1743          ->
1744          -> This is a test mailing
1745          ->
1746          -> .
1747         <-  250 2.0.0 Ok: queued as 41FB261AFC
1748          -> QUIT
1749         <-  221 2.0.0 Bye
1750         === Connection closed with remote host.
1751
1752
1753
1754 Imap e pop
1755 ------------------
1756
1757 Postfix e' un server SMTP, di conseguenza se volete che i vostri utenti possano *scaricare* in locale la posta generalmente volete mettere a loro disposizione un server *POP3* o *IMAP*. Oppure entrambi.
1758
1759 Pacchetti da installare 
1760         courier-imap courier-pop
1761
1762 Si noti che IMAP necessita delle *Maildir*, non funziona con le Mailbox in ``/var/mail/`` .
1763
1764 Client a riga di comando
1765 ---------------------------
1766
1767 Per testare il corretto funzionamento del server di posta e' utile avere a disposizione delle utility per inviare e leggere la posta: ovviamente da riga di comando.
1768
1769 mailx
1770 ~~~~~~~~~~~~~~
1771
1772 Uno dei client piu' semplici, sopratutto per inviare un messaggioi.  e' sufficiente usare una formula come::
1773         mail utente@dominio.com
1774
1775 Se il comando ``mail`` non fosse disponibile si installi il pacchetto ``mailx``.
1776
1777 Al primo prompt si digitera' l'oggetto, il testo del messaggio (per terminare l'inserimento lasciare una riga vuota, digitare un ``punto + Invio`` su una riga vuota), la Carbon Copy (se necessaria).
1778
1779 es::
1780
1781         mail andrea@localhost
1782         Subject: Oggetto della mail
1783         Testo del messagio,
1784         per terminare il messaggio
1785         lasciare una riga vuota
1786         e un punto (poi Invio).
1787
1788         .
1789         Cc:
1790         
1791 Per altrre opzioni si veda la pagina man.
1792
1793 Mutt
1794 ~~~~~
1795
1796 Mutt e' uno dei gestori di posta preferiti da chi preferisce utilizzare l'interfaccia testuale per la gestione della posta. 
1797
1798 Mutt ha un file di configurazione ``.muttrc`` nella *home* dell'utente, alcuni settaggi possono essere utili:
1799
1800 set folder="~/Maildir"
1801         Per utilizzare ``/home/nome_utente/Maildir come mailbox``, invece del default ``/var/mail/nome_utente``.
1802
1803 set editor="vim"
1804         Utilizzare ``vim`` come editor per comporre i messaggi.
1805
1806
1807 Spesso e' utile poter *levvere al volo* la Mailbox / Maildir di un utente sul server di posta, per controllare se i messaggi vengono recapitati correttamente::
1808         
1809         mutt -f /var/mail/utente
1810         mutt -f /home/utente/Maildir
1811
1812 In modo analogo si puo' consultare al volo la propia mailbox su un server remoto tramite IMAP/POP::
1813
1814                 mutt -f imap://nome_utente@piffa.net
1815
1816
1817 Web client
1818 ~~~~~~~~~~~~~~~
1819
1820 Per mettere a disposizione degli utenti un client web per gestire la propria posta si installi il pacchetto: ``squirrelmail`` . Ci sono tanti altri client web disponibili: questo e' particolarmente semplice. Naturalmente dovrete aver installato: ``php5 apache2`` .
1821
1822 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::
1823
1824         cd /etc/apache2/conf.d/
1825         ln -s /etc/squirrelmail/apache.conf ./squirrelmail.conf
1826
1827
1828 Graylisting
1829 ----------------
1830
1831 Il *graylisting* e' un sistema relativamente poco invasivo, con un limitato consumo di risorse per limitare lo *SPAM* in arrivo sul propio server di posta. Come suggerisce il nome e' una via di mezzo tra una *white list* (una lista di mittenti privilegiata, sempre benvenuti) e una *black list* (mittenti *bannati*, banditi dal poter inviare nuovi messaggi).
1832
1833 Il funzionamento e' relativamente semplice: ogni mittente sconosciuto viene immediatamente rifiutato con un errore *non grave* come un *server non disponibile, provare piu' tardi*. Questo inconveniente non dovrebbe mettere in difficolta' un server di posta / mittente legittimo, che dopo un periodo di attesa tentera' nuovamente di inviare il messaggio ottenendo finalmente il risultato atteso. Diversamente un *bot* per l'invio di SPAM o un applicazione improvvisata (tipicamente di derivazione virale) che stesse inviando il messaggio *probabilmente* non insisterebbe, rinunciano ad inviare il messaggio preferendo destinazioni meno problematiche.
1834
1835
1836 Abilitazione in Postfix
1837 ~~~~~~~~~~~~~~~~~~~~~~~~
1838
1839 Installare il pacchetto: ``postgrey`` e aggiungere il file di configurazione di Postfix ``/etc/postfix/main.cf``::
1840
1841         smtpd_recipient_restrictions =
1842                 permit_mynetworks,
1843                 reject_unauth_destination,
1844                 check_policy_service inet:127.0.0.1:60000
1845
1846 Test
1847 ~~~~~~~~
1848
1849 Inviando un messaggio il client dovrebbe ricevere un iniziale messaggio di rifiuto del messaggio::
1850
1851         swaks --to andrea@piffa.net from andrea@mydonain.com
1852         === Trying smtp.piffa.net:25...
1853         === Connected to smtp.piffa.net
1854         ...
1855         <-  250 2.1.0 Ok
1856          -> RCPT TO:<andrea@piffa.net>
1857         <** 450 4.2.0 <andrea@piffa.net>: Recipient address rejected: 
1858         Greylisted, see http://postgrey.schweikert.ch/help/piffa.net.html
1859          -> QUIT
1860         <-  221 2.0.0 Bye
1861         === Connection closed with remote host.
1862
1863 A lato server si dovrebbe rilevare su ``/var/log/syslog`` qualcosa di simile::
1864
1865         connect from alice.mydomain.com[65.98.21.97]
1866         May 28 14:53:34 r24266 postgrey: action=greylist, reason=new, 
1867            client_name=alice.mydomain.com,
1868            client_address=10.0.0.1, sender=root@alice.mydomain.com, recipient=andrea@piffa.net
1869         May 28 14:53:34 r24266 postfix/smtpd[22538]: 
1870            NOQUEUE: reject: RCPT from alice.mydomain.com[10.0.0.1]: 
1871            450 4.2.0 <andrea@piffa.net>: Recipient address rejected: Greylisted, 
1872            see http://postgrey.schweikert.ch/help/piffa.net.html; 
1873            from=<root@alice.mydomain.com> to=<andrea@piffa.net> 
1874            proto=ESMTP helo=<alice.mydomain.com>
1875         May 28 14:53:34 r24266 postfix/smtpd[22538]: disconnect from alice.mydomain.com[10.0.0.1]
1876
1877
1878 Statistiche
1879 ~~~~~~~~~~~~~~~
1880
1881 E' sempre utile poter tracciare qualche statistica sulle percentuali di messaggi ricevuti, da chi, messaggi rifiutati (e per quale motivo). Statistiche che attingono dai soliti log del server di posta ``/var/log/syslog`` di default oltre che i dedicati ``/var/log/mail`` .
1882
1883 Una utility semplice per analizzare l'attivita' del propio server smtp potrebbe essere ``pflogsumm`` , installato il pacchetto la si puo' invocare con::
1884         
1885         pflogsumm.pl  /var/log/mail.log
1886
1887 oppure utilizzare i log piu' vecchi ad es. ``/var/log/mail.log.0``
1888
1889 Firewall
1890 ==========
1891
1892 In Informatica, nell'ambito delle reti di computer, un firewall (termine inglese dal significato originario di parete refrattaria, muro tagliafuoco, muro ignifugo; in italiano anche parafuoco o parafiamma) e' un componente passivo di difesa perimetrale che puo anche svolgere funzioni di collegamento tra due o piu' tronconi di rete. Usualmente la rete viene divisa in due sotto reti: una, detta esterna, comprende l'intera Internet mentre l'altra interna, detta LAN (Local Area Network), comprende una sezione piu' o meno grande di un insieme di computer locali. In alcuni casi e' possibile che si crei l'esigenza di creare una terza sotto rete detta DMZ (o zona demilitarizzata) atta a contenere quei sistemi che devono essere isolati dalla rete interna ma devono comunque essere protetti dal firewall.
1893
1894 Una prima definizione chiusa di firewall e' la seguente:
1895
1896 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.
1897
1898 In realta' un firewall puo' essere realizzato con un normale computer (con almeno due schede di rete e software apposito), puo' essere una funzione inclusa in un router o puo' essere un apparato specializzato. Esistono inoltre i cosiddetti "firewall personali", che sono programmi installati sui normali calcolatori, che filtrano solamente i pacchetti che entrano ed escono da quel calcolatore; in tal caso viene utilizzata una sola scheda di rete.
1899
1900 La funzionalita' principale in sostanza e' quella di creare un filtro sulle connessioni entranti ed uscenti, in questo modo il dispositivo innalza il livello di sicurezza della rete e permette sia agli utenti interni che a quelli esterni di operare nel massimo della sicurezza. Il firewall agisce sui pacchetti in transito da e per la zona interna potendo eseguire su di essi operazioni di:
1901 controllo
1902 modifica
1903 monitoraggio
1904
1905 Questo grazie alla sua capacita' di "aprire" il pacchetto IP per leggere le informazioni presenti sul suo header, e in alcuni casi anche di effettuare verifiche sul contenuto del pacchetto.
1906
1907 Links
1908 ------
1909
1910 * http://openskill.info/topic.php?ID=124
1911 * http://iptables-tutorial.frozentux.net/iptables-tutorial.html
1912
1913 Ipfilter
1914 ----------
1915
1916 Link: http://iptables-tutorial.frozentux.net/iptables-tutorial.html#IPFILTERING
1917
1918 Natura di un firewall ip: su cosa lavora (livello 2 e un po' del 3) e su cosa *non* lavora (livello 4).
1919 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.
1920
1921 Netfilter non ricostruisce il flusso di dati tra pacchetti, non puo' quindi rilevare la presenza di virus o simili che si trasmettono su pacchetti separati: ricomporre, analizzare e tornare a scomporre i frammenti richiederebbe troppa RAM e risorse di sistema, con il conseguente rischio di saturare il firewall fino all'abbandono dei nuovi pacchetti in transito.
1922 Ci sono altri software piu' adatti a questi compiti, ad esempio un proxy HTTP come Squid che e' appunto una applicazione di quarto livello, progettata e strutturata per analizzare e modificare i flussi di dati (il *contenuto* dei pacchetti, non le sole *intestazioni*) facendo abbondate uso delle risorse RAM e di calcolo del sistema. Non a caso su macchine embedded dalle prestazioni molto ridotte (CPU ARM ~250MHZ con ~30MB di RAM) Squid sfrutta al massimo le risorse di sistema per gestire il traffico di una rete 10/100, mentre il lavoro tipico svolto da netfilter e' quasi irrilevante.
1923
1924 Progettazione di un firewall
1925 -----------------------------
1926
1927 Per implementare un firewall bisogna decidere un aio di cose: la collocazione e l'approccio (inclusivo o esclusivo) al filtraggio, il tipo di hardware.
1928
1929 Collocazione
1930 ~~~~~~~~~~~~~
1931
1932 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.
1933
1934 Collocazione:
1935
1936         1. sul router
1937         2. tra router e servers / LAN
1938         3. Unico server / router / firewall e connessi rischi. considerare l'acquisto di un router hardware dedicato.
1939         
1940 Layeed security:
1941         Implementare piu' device / software sui diversi livelli: http://iptables-tutorial.frozentux.net/iptables-tutorial.html#HOWTOPLANANIPFILTER
1942
1943
1944 Policy di default
1945 ~~~~~~~~~~~~~~~~~~~
1946
1947 Drop o Accept: conseguenze per sicurezza, facilita' di gestione.
1948
1949
1950 Hardware
1951 ~~~~~~~~~~~~
1952
1953 Sostanzialmente potremmo distinguere due tipologie di hardware:
1954
1955 Network appliance dedicata::
1956         Un dispositivo hardware dedicato alla funzione di Firewall, ad es un Cisco / Fortigate.
1957         Si noti che molti firewall economici altro non sono che Linux box molto striminzite.
1958
1959 Server / Personal computer:
1960         Un server sul quale viene fatto girare Netfilter ad uso del server stesso e della rete connessa.
1961
1962 Vantaggi e svantaggi: consumo elettrico, efficienza, flessibilita', strumenti di gestione, sicurezza, OpenBSD.
1963
1964 Percorso dei pacchetti tra tabelle e catene
1965 -------------------------------------------
1966
1967 link: http://iptables-tutorial.frozentux.net/iptables-tutorial.html#TRAVERSINGOFTABLES
1968
1969
1970 Concetti di base
1971 -----------------
1972
1973 Tabelle, catene, regole
1974 ~~~~~~~~~~~~~~~~~~~~~~~~~
1975
1976 Iptables lavora su 3 tabelle (tables) di default:
1977
1978 * filter - Regola il firewalling: quali pacchetti accettare, quali bloccare
1979
1980 * nat - Regola le attivita' di natting
1981
1982 * mangle - Interviene sulla alterazione dei pacchetti.
1983
1984 Ogni tabella ha delle catene (chains) predefinite (INPUT, OUTPUT, FORWARD ... ) a cui possono essere aggiunte catene custom. 
1985 Ogni catena e' composta da un elenco di regole (rules) che identificano pacchetti di rete secondo criteri diversi (es: -p tcp --dport 80 -d 10.0.0.45)
1986 Ogni regola termina con una indicazione (target) su cosa fare dei pacchetti identificati dalla regola stessa (es: -j ACCEPT,  -j DROP ...)
1987
1988 Match 
1989 ~~~~~~~~~~~~~~~~~
1990
1991 I Match di una regola (rule) servono a testare un pacchetto per valutare se corrisponda a certe caratteristiche. I match di possono servire a controllare se un pacchetto e' destinato a una porta particolare o utilizza un protocollo particolare.
1992
1993 Alcuni esempi:
1994
1995 -p [!] proto 
1996         Protocollo IP. Secondo IP number o nome (es: tcp, udp, gre, ah...)
1997
1998 -s [!] address[/mask] 
1999         Indirizzo IP sorgente (o network con maschera di sotto rete)
2000
2001 -d [!] address[/mask] 
2002         Indirizzo IP destinazione (o network)
2003
2004 -i [!] interface[+] 
2005         Interfaccia di rete di entrata ([+] wildcard)
2006
2007 -o [!] interface[+] 
2008         Interfaccia di rete di uscita ([+] wildcard)
2009
2010 -f 
2011         Frammento di pacchetto
2012
2013 Targets
2014 ~~~~~~~~~~~~~
2015
2016 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.
2017
2018 Target principali:
2019
2020 *-j ACCEPT* 
2021         Il pacchetto matchato viene accettato e procede verso la sua destinazione. Si usa per definire il traffico permesso.
2022
2023 *-j DROP* 
2024         Il pacchetto viene rifiutato e scartato, senza alcuna notifica al mittente. Si usa, in alternativa a REJECT, per bloccare traffico. 
2025
2026 *-j REJECT* 
2027         Il pacchetto viene rifiutato. Al mittente viene mandato un pacchetto (configurabile) di notifica  tipo ICMP port-unreachable (--reject-with icmp-port-unreachable)
2028
2029 -t LOG 
2030         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) 
2031
2032 -j DNAT 
2033         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
2034
2035 -j SNAT 
2036         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.
2037
2038 -j MASQUERADE 
2039         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. 
2040
2041 -j REDIRECT 
2042         Redirige il pacchetto ad una porta locale. Usabile solo in nat / PREROUTING e nat / OUTPUT e' previsto per fare un transparent proxy (con proxy server in esecuzione sulla macchina con iptables)
2043
2044 -j RETURN 
2045         Interrompe l'attraversamento della catena. Se questa e' una secondaria, il pacchetto torna ad attraversare la catena madre da punto in cui aveva fatto il salto nella secondaria. Se il RETURN e' in una delle catene di default, il pacchetto interrompe l'attraversamento e segue la policy di default.
2046
2047 -j TOS 
2048         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
2049
2050 -j MIRROR 
2051         Curioso e sperimentale, questo target invia un pacchetto speculare al mittente. In pratica e' come se facesse da specchio per tutti i pacchetti ricevuti. Da usare con cautela, per evitare attacchi DOS indiretti.
2052
2053
2054 Tabella Filter
2055 ---------------
2056
2057 E' quella implicita e predefinita (-t filter)
2058 Riguarda le attivita' di filtraggio del traffico.
2059 Ha 3 catene di default:
2060 INPUT - Riguarda tutti i pacchetti destinati al sistema. In entrata da ogni interfaccia.
2061 OUTPUT - Riguarda i pacchetti che sono originati dal sistema e destinati ad uscire.
2062 FORWARD - Riguarda i pacchetti che attraversano il sistema, con IP sorgente e destinazione esterni.
2063
2064 Esempio per permettere accesso alla porta 80 locale:
2065 iptables -t filter -I INPUT -p tcp --dport 80 -j ACCEPT
2066 Analoga a: iptables -I INPUT -p tcp --dport 80 -j ACCEPT
2067
2068 Esempio per permettere ad un pacchetto con IP sorgente 10.0.0.4 di raggiungere il server 192.168.0.1 attraversando il firewall:
2069 iptables -I FORWARD -s 10.0.0.4 -d 192.168.0.1 -j ACCEPT
2070
2071 Flush automatico per macchine remote
2072 ---------------------------------------
2073
2074 Se state provando una configurazione del firewall per una macchina remota e' buona norma per evitare brutte figure attivare uno script che faccia il *flush* delle regole dopo qualche minuto. Potreste infatti inavvertitamente impostare una regola che vi impedisca di raggiungere la macchina remota, cosi' da non poter neanche eliminare quella regola e ripristinare la situazione precedente.
2075
2076 *Veramente*, prima di lavorare sul firewall di una macchina remota impostate almeno un ``at now +5 min`` o con un'oretta di margine per fare il *flush* delle regole (su tutte le tabelle)::
2077
2078             at now +5 min
2079         at> /sbin/iptables -F
2080         at> [CTR+d]
2081
2082
2083
2084 Gestione regole (rules)
2085 --------------------------
2086
2087 Il comando iptables viene usato per ogni attivita' di gestione e configurazione.
2088
2089 Inserimento regole:
2090
2091 iptables -A CATENA ... 
2092         Aggiunge una regola alla fine della catena indicata
2093
2094 iptables -I CATENA [#] ... 
2095         Inserisce alla riga # (default 1) una regola nella catena indicata
2096
2097 iptables -N CATENA 
2098         Crea una nuova catena custom
2099
2100 iptables -P CATENA TARGET 
2101         Imposta il target di default per la catena indicata
2102
2103 Rimozione regole e azzeramenti:
2104
2105 iptables -F [catena] 
2106         Ripulisce tutte le catene (o quella indicata)
2107
2108 iptables -X [catena] 
2109         Ripulisce tutte le catene custom (o quella indicata)
2110
2111 iptables -Z [catena] 
2112         Azzera i contatori sulle catene
2113
2114 iptables -D catena # 
2115         Cancella la regola numero # dalla catena indicata
2116
2117 Interrogazione:
2118
2119 iptables -L 
2120         Elenca le regole esistenti
2121
2122 iptables -L -n -v 
2123         Elenca, senza risolvere gli host, in modo verboso le regole esistenti
2124
2125
2126
2127
2128 Salvataggio regole
2129 ----------------------
2130
2131 Il comando ``iptables`` serve per interagire con il framework ``Netfilter`` che gestisce il firewall di Linux al livello del kernel. Questo comporta, in modo analogo a quando avviene col comando ``ifconfig``, che i cambiamenti impostati siano in *tempo reale, RAM*, non persistenti nel sistema: al boot successivo del sistema tutto tornera' alle impostazioni di base (in questo caso *nulle*, con policy di default settate su ``ACCEPT`` per tutto).
2132
2133 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.
2134
2135 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``.
2136
2137 Nel nostro caso avremo per una possibile scheda ``eth0``:
2138
2139 ``/etc/network/interfaces`` ::
2140                 
2141         iface eth1 inet static
2142                 up /sbin/iptables-restore /root/firewall/basic_fw
2143                 # Seguono i soliti parametri della scheda di rete
2144                 address 10.10.208.21 
2145  
2146
2147 Iptables-save
2148 ~~~~~~~~~~~~~~~
2149
2150 Per salvare le regole di iptables attualmente presenti nel kernel si usi il comando::
2151
2152         # iptables-save >> /root/firewall/basic_fw
2153
2154 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.
2155
2156
2157 Se non avete un'idea migliore potreste voler tenere gli script dei firewall in una cartella ``~/firewall`` nella home directory dell'utente ``root``.
2158
2159 Iptables-restore
2160 ~~~~~~~~~~~~~~~~~~~~
2161
2162 Per ripristinare un set di regole precedentemente salvate con ``iptables-save`` si utilizzi ``iptables-restore``. Se questo deve essere fatto in modalita' *non interattiva*, ad esempio deve essere eseguito dal demone che si occupa di inizializzare le schede di rete, oppure un *cron* o altro, e' buona norma richiamare i percorsi completi sia dei comandi che dei file::
2163         
2164                 /sbin/iptables-restore /root/firewall/basic_fw
2165
2166
2167 Esempi
2168 -------------
2169
2170 Seguono alcuni esempi sull'uso di iptables, lo scenario e' un computer con un paio di schede di rete fisiche una delle quali collegata alla rete internet l'altra a una rete privata per la LAN interna.
2171
2172         1. ``eth0`` scheda di rete principale sulla rete privata interna 192.168.0.0/24
2173
2174         2. ``eth1`` scheda di rete secondaria per la connessione ad internet
2175
2176         3. ``ppp0`` punto-a-punto per una connessione ad internet
2177
2178 Bloccare i ping dall'esterno
2179 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2180
2181 Spesso gli script che attaccano *automaticamente* le varie reti provano a fare un ping per verificare quali IP sono on-line: bloccare il traffico ``ICMP`` in ingresso puo' aiutare ad evitare parte di questi attacchi::
2182
2183         iptables -A INPUT -i ppp0 -p ICMP -j DROP
2184
2185 Masquerading (sNAT)
2186 ~~~~~~~~~~~~~~~~~~~~
2187
2188 Per attivare la network address translation (in questo caso un SNAT) per la rete locale privata sull'indirizzo ip del *modem*::
2189         iptables -A POSTROUTING -s 192.168.0.0/255.255.255.0 -o ppp0 -j MASQUERADE
2190
2191 Il *Masquerading* a differenza dello *SNAT* puro (``-j SNAT --to-source proprio_ip_pubblico ) legge l'indirizzo ip del device ``ppp0``. In questo modo se l'IP cambia automaticamente si aggiorna anche il source natting. Se avete un indirizzo IP statico assegnato al vostro gateway potete invece usare lo SNAT semplice.
2192
2193 Altri esempi::
2194        ## Change source addresses to 1.2.3.4.
2195        # iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to 1.2.3.4
2196
2197        ## Change source addresses to 1.2.3.4, 1.2.3.5 or 1.2.3.6
2198        # iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to 1.2.3.4-1.2.3.6
2199
2200        ## Change source addresses to 1.2.3.4, ports 1-1023
2201        # iptables -t nat -A POSTROUTING -p tcp -o eth0 -j SNAT --to 1.2.3.4:1-1023
2202
2203 Brute force
2204 ~~~~~~~~~~~~
2205
2206 Per limitare attacchi di tipo brute force su SSH::
2207
2208         iptables -A INPUT -i ppp0 -p tcp -m tcp --dport 22 -m state --state NEW -m recent --update --seconds 3000 --hitcount 4 --name DEFAULT --rsource -j DROP
2209
2210         iptables -A INPUT -i ppp0 -p tcp -m tcp --dport 22 -m state --state NEW -m recent --set --name DEFAULT --rsource
2211
2212
2213
2214 NOTE
2215 ========
2216
2217 Bind:
2218         - altri esempi commenti su una zona
2219         - esempi di una zona PTR?
2220         - dns secondari
2221         - nsupdate
2222
2223
2224 sintassi: in ``monospace`` :
2225
2226 * nomi di files
2227 * comandi
2228 * pacchetti