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