1 ===============================
2 Servizi di rete passo a passo
3 ===============================
4 ------------------------------------------------------------------------------------
5 Appunti sulla installazione e configurazione dei servizi di rete in ambiete Gnu/Linx
6 ------------------------------------------------------------------------------------
12 Questa guida tratta la configurazione di base dei principali servizi di rete utilizzati con sistemi operativi *Unix* e derivati come *GNU/Linux* per gli studenti dei corsi per amministratori di rete in ambiente *GNU/Linux*. In particolare questa guida e' stata scritta usando come riferimento la distribuzione *Debian GNU/Linux*. Gli esempi presentati dovrebbero quindi essere direttamente utilizzabili anche su distribuzioni derivate da Debian come Ubuntu, per sistemi operativi diversi si presti attenzione ai percorsi dei file citati.
16 .. contents:: Indice degli argomenti
19 Generato il |date| con: http://docutils.sourceforge.net/rst.html
21 Configurazione sistema
22 =========================
24 ---------------------------
26 Impostazioni di base per la configurazione del sistema operativo e della rete nel laboratorio 208 facente parte della rete piffa.net .
28 Sono qui riportati i parametri della rete locale per comodita' degli studenti, gli altri lettori possono considerarli come riferimento per comprendere i valori espressi nei vari file di configurazione. Ad esempio: quando leggerete ``10.10.208.248:3128`` saprete che si tratta del nostro *proxy http* in ascolto sulla porta `3128`, stara' quindi a voi sostituire i dati con gli equivalenti *IP* della vostra rete.
33 Parametri della rete attualmente in uso:
35 ============= ================
37 ------------------------------
40 broadcast 10.10.208.255
43 ============= ================
45 Dal server locale degli studeti, **Bender**, corrispondente all'IP ``10.10.208.248``, vengono erogati i servizi DHCP, DNS, gateway (con NAT), proxy http e mirror della distribuzione Debian ( http://debian.piffa.net). Altri servizi in esecuzione sul server:
47 - Rsync server e altri software di aggiornamento / installazione di massa
48 - Server imap / pop3 / webmail / smtp
49 - Server ssh per i test degli studenti
50 - File server Samba, NFS e controller di qualsiasi altro FS distribuito
51 - Print server per la gestione delle stampanti
53 - Mirror locale delle \*.iso dei sistemi operativi e dei vari software usati durante le lezioni
54 - Spazi web con PHP, MySQL, Postgresql (altri DB o framework vengono attivati a seconda dei corsi attivi)
57 Durante il corso delle lezioni e' opportuno che le macchine degli studenti si appoggino al server Bender (ottetto finale ``248``), nel caso questo non fosse raggiungibile (ad esempio per permettere impostazioni di DHCP / routing diverse) sara' comunque disponibile il ``10.10.208.254`` come gateway | DNS per la rete ``10.10.208.10``.
59 **Non e' piu' possibile** raggiungere Bender tramite l'IP pubblico ``212.22.136.248`` o *qualsiasi altro ip* della classe ``C 212.22.136.0/24`` precedentemente disponibile.
61 Il computer del docente con il server VNC e' sempre configurato con l'ottetto finale: ``177`` della rete utilizzata durante le lezioni (quindi generalmente la VNC sara' disponibile sul ``10.10.208.177:1``.
63 Gli studenti sono pregati di non impedire l'accesso SSH alla propria macchina dal computer del docente, e non modificare la password dell'utente ``root`` del sistema operativo *pre-istallato* (ad es: *Diurno*).
68 Segue un esempio del file di configurazione della scheda di rete con configurazione statica:
70 /etc/network/interfaces::
72 # /etc/network/interfaces -- configuration file for ifup(8), ifdown(8)
74 # The loopback interface
75 iface lo inet loopback
77 # La prima scheda di rete (se si chiama eth0)
78 iface etho inet static
80 # iface etho inet dhcp
84 broadcast 10.10.208.255
87 # Quali interfaccie devono partire automaticamente:
90 Controllare il nome della propria scheda di rete: a volte *udev* rinomina la prima scheda a ``eth1``, oppure potreste avere piu' di una scheda di rete (anche un'interfaccia *firewire* puo' essere automaticamente abilitata come scheda di rete).
92 Se si usano *schede di rete virtuali* ( eth0:1 , eth0:1 , ...) ricordarsi che queste dipendono dalla scheda fisica a cui sono associate: abbattere con ``ifconfig down eth0`` la scheda principale fara' cadere anche queste. Tornando ad attivare la scada principale con ``ifconfig eth0 up`` la virtuale tornera' attiva: nel caso voleste disabilitarla dovrete quindi sempre abbattere manualmente la scheda virtuale *prima* della scheda reale.
94 I DNS vanno indicati nel file ``/etc/resolv.conf`` , la cui sintassi e' spiegata al punto 4.6 . Come DNS si *deve* usare il server Bender, alcuni parametri dei software di installazione, risoluzione dei mirror, vengono opportunamente modificatia da questo DNS.
99 Il completamento automatico della shell (che si attiva premendo il tasto tab una o due volte mentre si sta scrivendo un termine) permette di comporre automaticamente i nomi dei comandi e i percorsi dei file, sopratutto la composizione automatica dei percorsi dei file e' di grande importanza.
101 Bash_completion permette di integrare il completamento automatico con i nomi dei pacchetti e oggetti dei comandi: ad es. volendo digitare ``apt-get inst[TAB] xtigh[TAB]`` ora verra' completato automaticamente sia la parola ``install`` che il nome del pacchetto ``xtightvncviewer``.
103 Abilitare /etc/bash_completion nel file ``/etc/bash.bashrc`` oppure includerlo nel proprio ``~/.bashrc`` (che sarebbe il file *nascosto*, quindi con un punto all'inizio del nome del file, di configurazione della shell bash per ogni utente, presente nella propria *home directory*)::
105 echo ". /etc/bash_completion" >> ~/.bashrc
107 Esempio di ~/.bahsrc ::
109 # ~/.bashrc: executed by bash(1) for non-login shells.
111 export PS1='\h:\w\$ '
114 # De-commentare le seguenti righe per abilitare la colorazione dei
116 export LS_OPTIONS='--color=auto'
118 alias ls='ls $LS_OPTIONS'
119 alias ll='ls $LS_OPTIONS -l'
120 alias l='ls $LS_OPTIONS -lA'
122 # Abilitare i seguenti alias per impostare la conferma per cancellare file
127 # questo abilita bash completion
128 . /etc/bash_completion
130 Il file ``/etc/bash_completion`` deve essere presente nel sistema, in caso contrario installare il pacchetto: ``bash-completion``. Generalmente l'utente ``root`` ha un file ``.bashrc`` preimpostato analogo a quello citato sopra, a differenza dei normali utenti di sistema.
134 * `An introduction to bash completion <http://www.debian-administration.org/articles/316>`_
135 * `Working more productively with bash 2.x/3.x <http://www.caliban.org/bash/>`_
136 * UNIX / Linux Shell Scripting Tutorial: http://steve-parker.org/sh/sh.shtml
141 Vim e' l'editor di testo preferito dai sistemisti, quindi sara' conveniente impostare fin da subito alcune impostazioni per renderlo piu' comodo.
143 Assicurarsi che sia installata nel sistema la versione completa dell'editor installando il pacchetto ``vim``::
145 # apt-get install vim
148 Modificare poi il file di configurazione generale ``/etc/vim/vimrc`` ::
150 " All system-wide defaults are set in $VIMRUNTIME/debian.vim (usually just
151 " /usr/share/vim/vimcurrent/debian.vim) and sourced by the call to :runtime
152 " you can find below. If you wish to change any of those settings, you should
153 " do it in this file (/etc/vim/vimrc), since debian.vim will be overwritten
154 " everytime an upgrade of the vim packages is performed. It is recommended to
155 " make changes after sourcing debian.vim since it alters the value of the
156 " 'compatible' option.
158 " This line should not be removed as it ensures that various options are
159 " properly set to work with the Vim-related packages available in Debian.
162 " Uncomment the next line to make Vim more Vi-compatible
163 " NOTE: debian.vim sets 'nocompatible'. Setting 'compatible' changes numerous
164 " options, so any other options should be set AFTER setting 'compatible'.
167 " Vim5 and later versions support syntax highlighting. Uncommenting the next
168 " line enables syntax highlighting by default.
171 " If using a dark background within the editing area and syntax highlighting
172 " turn on this option as well.
175 " Uncomment the following to have Vim jump to the last position when
179 au BufReadPost * if line("'\"") > 0 && line("'\"") <= line("$")
180 \| exe "normal! g'\"" | endif
183 " Uncomment the following to have Vim load indentation rules and plugins
184 " according to the detected filetype.
185 " This is not recommanded if you often copy and paste into vim,
186 " as it messes all the indentation.
188 filetype plugin indent on
191 " This goes for comments folding: use co to expnad and zc to compress,
192 " zi to toggle on/off
194 set fde=getline(v:lnum)=~'^\\s*#'?1:getline(prevnonblank(v:lnum))=~'^\\s*#'?1:getline(nextnonblank(v:lnum))=~'^\\s*#'?1:0
196 " The following are commented out as they cause vim to behave a lot
197 " differently from regular Vi. They are highly recommended though.
198 set showcmd " Show (partial) command in status line.
199 "set showmatch " Show matching brackets.
200 # Ignorecase is quite userfull
201 set ignorecase " Do case insensitive matching
202 "set smartcase " Do smart case matching
203 "set incsearch " Incremental search
204 set autowrite " Automatically save before commands like :next and :make
205 "set hidden " Hide buffers when they are abandoned
206 "set mouse=a " Enable mouse usage (all modes) in terminals
208 " Source a global configuration file if available
209 " XXX Deprecated, please move your changes here in /etc/vim/vimrc
210 if filereadable("/etc/vim/vimrc.local")
211 source /etc/vim/vimrc.local
215 I principianti faranno bene ad esercitarsi con ``vimtutor it``.
219 - Vim Introduction and Tutorial: http://blog.interlinked.org/tutorials/vim_tutorial.html
220 - http://blog.smr.co.in/category/vim/
221 - http://vimdoc.sourceforge.net/
226 I Virtual Network Computing (o VNC) sono software di controllo remoto e servono per amministrare un computer a distanzai. Nel nostro caso la VNC sara' utilizzata per visualizzare la sessione di lavoro di un altro computer sul proprio a scopo didattico.
228 Per collegarvi al server del docente usate lo script ``guarda.sh`` che dovrebbe gia essere disponibili sui sistemi preconfigurati, oppure potete invocare direttamente il collegamento con::
230 xtightvncviewer -viewonly 10.10.208.177:1
233 Se il comando non fosse disponibile installate il pacchetto ``xtightvncviewer``. Potete anche scaricare lo script ``guarda.sh`` e renderlo eseguibile, ed eventualmente creare una voce nel menu di KDE per richiamarlo.
239 wget http://bender/guarda.sh
244 Per eseguire lo script digitare semplicemente ``guarda.sh``, oppure creare un link / collegamento sul Desktop allo script ``/usr/local/bin/guarda.sh``.
246 Le impostazioni del server VNC sono:
248 ===================== =================
250 ===================== =================
254 ===================== =================
257 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.
259 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`` .
261 Lista dei pacchetti di base
262 -----------------------------
264 I pacchetti installati generalmente [#]_ per poter seguire le lezioni sono::
266 kde-core kdm kde-i18n-it xorg vim less xtightvncviewer
268 .. [#] ``kde-core`` e' piu' leggero del pacchetto ``kde``. Esiste un equivalente ``gnome-core`` per chi preferisce Gnome, nel caso si potrebbe installare il log-in manager `gdm` al posto di `kdm`.
271 ---------------------
273 Vediamo i due file principali di apt:
275 * ``/etc/apt/sources.list``
277 * ``/etc/apt/apt.conf``
282 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).
284 Gli archivi sono generalmente:
286 * ``deb`` per pacchetti Debian binari, pronti per l'installazione.
288 * ``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.
291 ``/etc/apt/sources.list`` ::
293 # esempio di accesso a un CDROM:
294 # cdrom:[Debian GNU/Linux 5.0.1 _Lenny_ - Official i386 kde-CD Binary-1 20090$
296 # ftp.it.debian.org viene rediretto su un mirror interno
297 # quando vi trovate nella rete interna piffa.net
298 deb http://ftp.it.debian.org/debian/ lenny main
299 # Sono disponibili anche i rami non-free contrib
300 # deb http://ftp.it.debian.org/debian/ lenny non-free contrib
301 # Sono disponibili anche le release unstable e testing
302 # deb http://ftp.it.debian.org/debian/ testing main non-free contrib
303 # deb http://ftp.it.debian.org/debian/ sid main non-free contrib
305 # Sorgenti dei pacchetti:
306 # deb-src http://ftp.bononia.it/debian/ lenny main
308 # Mirror da kernel.org europa da usare a casa:
309 deb http://mirrors.eu.kernel.org/debian/ lenny main
311 # Security dal sito principale
312 deb http://security.debian.org/ lenny/updates main
313 # deb-src http://security.debian.org/ lenny/updates main
315 # Debian volatile per i pacchetti soggetti a frequanti cambiamenti
316 # non legati a dinamiche di sicurezza
317 deb http://volatile.debian.org/debian-volatile Lenny/volatile main
318 # deb-src http://volatile.debian.org/debian-volatile Lenny/volatile main
320 # Esempio di accesso a un file system locale contenente i pacchetti:
321 # Potete scaricarei in aula con debmirror da debian.piffa.net
322 # un mirror locale da usare poi a casa anche senza internet
323 # deb file:/mnt/mirror sid main non-free contrib
329 Questo file contiene le opzioni di apt, come ad esempio il proxy::
331 Acquire::http::Proxy "http://10.10.208.248:3128";
333 Si tenga conto che se si imposta un proxy per apt sul proprio portatile e tornati a casa propria si vuole scaricare nuovi pacchetti si dovra' disabilitare il proxy commentando la riga con ";" (''punto-e-virgola''). Su un portatile vi conviene tracciare il mirror ``ftp.it.debian.org`` senza impostare il proxy: in aula verra' rediretto al mirror locale e a casa vi appoggerete al mirror ufficiale.
335 E' consigliabile impostare il proxy per apt anche in presenza di un proxy-http *trasparente*.
341 Squid e' un proxy cache http (ma puo' anche gestire i protocolli FTP e https) robusto e strutturato, grazie alla sua flessibilita' puo' essere utilizzato sia in piccole reti locali che in scenari piu' complessi. E' molto semplice configurarlo per la semplice *condivisione della navigazione internet* all'interno di una rete locale, per poi poter sucessivamente implementare la autenticazione degli utenti, 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'), il bilanciamento del carico tra piu' server proxy.
343 Se il server Squid e' in grado di accedere a internet puor' permette la navigazione web a una rete basata su indirizzi IP privati (es una 192.168.0.0/24). E se la rete privata deve solo navigare in internet, non serve introdurre nella rete un NAT (si veda la sezione sui firewall) per condividere la connessione: basta il solo Squid. Per altro non servira' neanche un servizio DNS accessibile dai clients dato che sara' il solo Squid a risolvere i nomi di dominio per i suoi client http.
345 Inoltre Squid svolge la funzione di *anonymizer*: nasconde i client http alla rete internet: e' solo il server proxy ad accedere ai server web frequentati dai client: questi non sono percepiti ed esposti all'esterno della rete locale ma si relazionano solo con Squid. Dal punto di vista della sicurezza della rete locale questo e' preferibile ad un approccio alla navigazione basato su NAT.
347 Squid ascolta di default sulla porta ``3128``, per quanto in genere la porta preferita per i servizi di caching http sia la ``8080``. Per utilizzarlo subito anche per apt si aggiunga ad ``/etc/apt/apt.conf`` ::
349 Acquire::http::Proxy "10.10.208.254:3128";
352 Per installare Squid si usi il pacchetto::
357 Configurazione: squid.conf
358 -------------------------------
360 egue un estratto delle direttive principali viste in aula presenti nel file di configurazione ``/etc/squid3/squid.conf`` .
365 Cache dir serve per impostare caratteristiche fondamentali della cache creata sul supporto di storaggio quali dimensione e percorso nel file-system. Essendo la dimensione di default della cache pari a ~``100 MB`` e' altamente consigliabili aumentare questo parametro se si vuole godere dei vantaggi della funzione di cache per piu' clients.
367 Per stabilire il dimensionamento della cache si tenga conto dello spazio disponibile, dimensioni tipiche e massime degli oggetti che si vuole tenere in cache (un solo file .iso occupa circa ``700 MB``, il pacchetto Openoffice.org circa 150 MB, un pacchetto Debian circa 20 MB), e in fine del numero dei client.
369 Si presti poi attenzione alla natura dei dati che saranno salvati nella cache: sono tutti dati facilmente sostituibili (gli originali sono on-line) la cui perdita causerebbe solo la necessita' di ripopolare la cache. Questo rende la cache di Squid un possibile candidato ad un RAID stirpe (livello 0) a ad un file system che prediliga le performance a scapito della consistenza, con vantaggi sia per le prestazioni (e la velocita' di navigazione e' uno dei motivi per cui si installa Squid) che per l'utilizzo estensivo dello spazio di storaggio.
371 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' piu' probabile rispetto ad un filesytem normale.
373 Opzioni del file system
374 `````````````````````````
376 I dati che compongono la cache vengono salvati sul filesytem del server dietro richiesta dei client http degli utenti della rete locale. 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 abbiano i privilegi di eseguibilita' o suid (in genere si possono anche usare opzioni come noatime per rendere i file-systems piu' veloci, scegliere di utilizzare un journal dipende dalla dimesione della cache dalle preferenze: affidabilita' oppure prestazioni):
381 # Filesystem per Squid http cache
382 /dev/md3/ /var/spool/squid/ ext2,noexec,nosuid,noatime 0 3
385 Configurazioni di Cache_dir
386 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
388 Ora possiamo impostare la cache nel file di configurazione ``/etc/squid3/squid.conf``::
390 #TAG: cache_dir (riga 1628)
393 # cache_dir Type Directory-Name Fs-specific-data [options]
395 # You can specify multiple cache_dir lines to spread the
396 # cache among different disk partitions.
399 # cache_dir ufs /var/spool/squid3 100 16 256
400 cache_dir aufs /var/spool/squid3 300 24 256
401 # | | | | secondo livello di directory
402 # | | | directory primo livello
403 # | | dimensione in MB
407 Se si modifica la struttura della cache di Squid, ad esempio variando il numero delle directory, puo' essere opportuno cancellare e rigenerare la cache. Tipicamente e' consigliabile cancellare (se si ha ridotto il numero delle directory) la vecchia cache e poi generare una nuova struttura. Se si vuole star nel sicuro ogni volta che si modifica l'impostazione delle directory si svuoti la vecchia cache e se ne generi una nuova::
409 # /etc/init.d/squid3 stop
410 # rm -r /var/spool/squid3/??
412 # /etc/init.d/squid3 start
414 TAG: maximum_object_size
415 ~~~~~~~~~~~~~~~~~~~~~~~~~~
417 Questa direttiva imposta la dimensione massima degli oggetti che vengono salvati sul supporto di storaggio, oggetti di dimensioni superiori saranno comunque scaricati ma non tenuti in cache.
419 TAG: maximum_object_size (1760)::
421 # TAG: maximum_object_size (1760)
422 # Objects larger than this size will NOT be saved on disk. The
423 # value is specified in kilobytes, and the default is 4MB. If
424 # you wish to get a high BYTES hit ratio, you should probably
425 # increase this (one 32 MB object hit counts for 3200 10KB
426 # hits). If you wish to increase speed more than your want to
427 # save bandwidth you should leave this low.
429 # NOTE: if using the LFUDA replacement policy you should increase
430 # this value to maximize the byte hit rate improvement of LFUDA!
431 # See replacement_policy below for a discussion of this policy.
434 # maximum_object_size 4096 KB
435 maximum_object_size 150 MB
438 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
440 **Cache_mem** imposta quanta memoria RAM venga dedicata alla cache di Squid. Si consideri non solo quanta RAM sia disponibile sul sistema, ma anche quale sia l'utilizzo tipico di questo: altri servizi fondamentali necessitano di molta memoria?
442 Questo parametro per altro influisce sulle prestazioni e sul degrado dei supporti di storaggio (sopratutto se magnetici). Ad esempio se si stanno utilizzando dischi rigidi esterni USB per la cache sara' preferibile cercare di usare quanta piu' RAM possibile per evitare il sovraccarico computazionale dovuto alla gestione dello stack USB, fenomeno evidente sui sistemi embedded come NAS.
444 Se si stesse pensando di usare dell'hardware *embedded* a basse prestazioni / consumo per realizzare un server gateway / NAT / Squid si tenga presente che Squid e' relativamente esoso di risorse rispetto agli altri servizi: avra' bisogno di ``~25MB`` (MegaByte) di RAM e *~150MHZ di CPU ARM* per servire decorosamente una decina di client http su una rete ethernet 10/100. In questo caso non fate scendere ``cache_mem`` sotto i ``2/4 MB`` pena un accesso continuo al supporto di storaggio.
446 Se invece si disponesse di una macchina dedicata a Squid con gigabytes di RAM non si esiti a dedicarne buona parte a *cache_mem*.
448 TAG: cache_mem (1566)::
450 # 'cache_mem' specifies the ideal amount of memory to be used
452 # * In-Transit objects
454 # * Negative-Cached objects
460 TAG: minimum_object_size
461 ~~~~~~~~~~~~~~~~~~~~~~~~~~
463 Questo parametro imposta la dimensione minima degli oggetti salvati nella cache. Settato a ``0`` o a valori molto piccoli puo' influire negativamente sulla frammentazione del filesytem e consumare un numero elevato di *inode* (cosa non piu' importante con ext4 o altri filesytem).
465 In scenari con connessioni molto veloci ( >~10Mb), pochi client (una decina) e server poco performanti nella velocita' di accesso ai filesystem ( ~20MB/s, per quanto il limte sia piuttosto il *seek-time* ) tenere in cache i file piu' piccoli finisce per aumentare la latenza della navigazione.
467 TAG: minimum_object_size::
469 # TAG: minimum_object_size (bytes)
470 # Objects smaller than this size will NOT be saved on disk. The
471 # value is specified in kilobytes, and the default is 0 KB, which
472 # means there is no minimum.
475 # minimum_object_size 0 KB
476 minimum_object_size 0 KB
478 Negoziazione degli accesi al servizio
479 ---------------------------------------
481 Squid fa parte di quei servizi suscettibili di diventare un open relay, sara' quindi necessario prestare attenzione a delimitare la rete che puo' accedere al servizio.
484 Un servizio a cui possono accedere tutti indiscriminatamente.
485 La cosa puo' andare bene per servizi come i server web, che aspirano per loro natura
486 al maggior numero possibile di utenti, ma non a servizi come i proxy http oppure
487 ai server di posta elettronica (adibiti ai soli utenti della rete locale).
489 Generalmente non volete che il vostro proxy http venga usato da persone sconosciute ed esterne alla vostra rete, le quali sostanzialmente *navigherebbero sotto l'identita' del vostro proxy* (probabilmente per visionare materiali che non vorrebbero fossero ricondotti direttamente a loro) generando traffico e consumando banda della vostra connessione a internet. Tenere Squid in modalita' *Open relay* e' al giorno d'oggi un buon modo per essere inseriti in una *black list*.
491 Per poter limitare gli accessi a Squid dal punto di vista dell'applicazione (quarto livello TCP/IP) si identifichera' inizialmente l'entita' *rete locale* (es: ``localnet``) con una ACL di tipo *src* (indirizzi IP sorgenti) indicando la *classe / range di IP* della nostra rete.
493 Dopodiche l'accesso (``http_access``) si concedera' (*allow*) a questa entita' (es: ``localnet``) negando chiunque altro.
495 Per maggiori dettagli sulla sintassi utilizzabile per esprimere i range di IP:
496 http://www.visolve.com/squid/squid24s1/access_controls.php
498 E' poi sempre possibile tenere il proxy in ascolto su un solo indirizzo IP, nel caso si disponga di piu' device di rete, oppure settare un IP firewall per limitare il traffico in base al protocollo IP.
503 ~~~~~~~~~~~~~~~~~~~~~
504 Si proceda a creare una ``ACL`` di tipo ``src`` per identificare la nostra rete locale, poi si abiliti l'accesso a questa con la direttiva ``http_access``. Tutto quanto non e' espressamente autorizzato viene poi negato da un ``http_access deny all`` finale.
509 # Defining an Access List
511 # Every access list definition must begin with an aclname and acltype,
512 # followed by either type-specific arguments or a quoted filename that
513 # they are read from.
515 # ***** ACL TYPES AVAILABLE *****
517 # acl aclname src ip-address/netmask ... # clients IP address
520 # Example rule allowing access from your local networks.
521 # Adapt to list your (internal) IP networks from where browsing
523 #acl localnet src 10.0.0.0/8 # RFC1918 possible internal network
524 #acl localnet src 172.16.0.0/12 # RFC1918 possible internal network
525 #acl localnet src 192.168.0.0/16 # RFC1918 possible internal network
527 acl localnet src 10.10.208.0/24
531 # Allowing or Denying access based on defined access lists
533 # Access to the HTTP port:
534 # http_access allow|deny [!]aclname ...
536 # NOTE on default values:
538 # If there are no "access" lines present, the default is to deny
542 # INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS
544 # Example rule allowing access from your local networks.
545 # Adapt localnet in the ACL section to list your (internal) IP networks
546 # from where browsing should be allowed
547 #http_access allow localnet
548 http_access allow localnet
553 Dopo aver 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 e si usi ``wget`` da riga di comando.
559 Nel file ``.wgetrc`` (si noti il punto iniziale: e' un file nascosto) si puo' impostare il proxy per wget. Si utilizzi l'indirizzo IP del server che si vuole testare, e si seguano i log ``/var/log/squid3/access.log`` sul server.
561 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``.
564 http_proxy=10.10.208.178:3128
566 Si proceda a scaricare dal client scelto con un wget::
568 wget http://www.google.it
571 ~~~~~~~~~~~~~~~~~~~~~
573 Si puo' controllare il corretto funzionamento del server seguendo i log di accesso a Squid::
575 # tail -f /var/log/squid3/access.log
577 In oltre e' possibile configurare diversi *analizzatori di log* come ``Webalizer`` per studiare i log di Squid.
583 Se avete l'esigenza di un proxy server per la condivisione della connessione ad internet ma non avete la necessita' o le risorse di un *caching* proxy come Squid potete considerare **tinyproxy**, questo e' molto piu' leggero (utilizza circa ~2MB di RAM e ovviamente non deve accedere continuamente ad un file system per lo storaggio della cache) e risulta piu' semplice nella configurazione.
585 TinyProxy puo' essere utilizzato come sostituto di emergenza in una rete in cui Squid e' momentaneamente non disponibile.
587 File di configurazione: ``/etc/tinyproxy/tinyproxy.conf`` ::
589 # Porta su cui ascoltare
591 # IP su cui ascoltare
593 # Negoziazione accessi
601 Apache HTTP Server, o piu' comunemente Apache (*a patchy NCSA web server* ), e' il server web modulare piu' diffuso e strutturato disponibile con licenza libera, in grado di operare da sistemi operativi UNIX/Linux e Microsoft.
603 Un server web e' un processo, e per estensione il computer su cui e' in esecuzione, che si occupa di fornire, su richiesta del browser, una pagina web (spesso scritta in HTML). Le informazioni inviate dal server web viaggiano in rete trasportate dal protocollo HTTP. L'insieme di server web da' vita al World Wide Web, uno dei servizi piu' utilizzati di Internet.
605 Pacchetti da installare::
606 ----------------------------
610 Con la release 2.0 di Apache viene automaticamente resa disponibile anche la versione SSL (Secure Socket Layer, connessioni criptate ) del web server senza che ci sia la necessita' di installare altri pacchetti.
613 Configurazione di Apache
614 ----------------------------
616 I file di configurazione di apache si trovano nella cartella: ``/etc/apache2`` e sono strutturati come descritto nel file
617 ``/usr/share/doc/apache2/README.Debian.gz`` . Sostanzialmente lo schema e' il seguente:
620 File di configurazione principale del servizio.
622 httpd.conf e' il vecchio file di configurazione di Apache1, presente per motivi di retrocompatibilita' e' generalmente vuoto.
625 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>``
628 In questa cartella vengono raccolti i file di configurazione dei virtual host disponibili.
631 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.
634 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 .
637 Moduli abilitati, effettivamente caricati.
642 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.
644 Guardiamo alcune direttive interessanti:
647 Numero di secondi da aspettare prima di chiudere la connessione con il client. Questo parametro serve a liberare le risorse di sistema nel caso che un client, magari a causa di una connessione particolarmente lenta o instabili, tenga attivo indefinitamente un processo di apache.
650 L'estensione keep-alive (http 1.0) congiuntamente alle connessioni persistenti (http 1.1) permettono al server di rispondere a piu' richieste dei client mediante la stessa connessione. Il protocollo http per sua natura e' senza stato (*stateless* ), quindi ogni risorsa richiesta (per pagine web si pensi ad esempio alle immagini) dal client necessita di una connessione autonoma. Keep-alive permette di ottimizzare la connessione anche fino al 50% a seconda delle situazioni e contenuti.
652 Server-Pool Size Regulation
653 Questi parametri (StartServers, MinSpareServers, ecc. Tutti spiegati nel manuale di apache) servono per attribuire le risorse di sistema disponibili al server Apache. Tenere questi parametri bassi serve a limitare il rischio di Denial of Service per il server, nel caso offra altri servizi. I settagli di default sono come sempre abbastanza conservativi, se si conta di usare il proprio Apache per servire un sito web con molti visitatori sara' necessario aumentare sensibilmente le impostazioni di base.
656 Il nome del file che viene onorato per modificare le impostazioni per una singola directory, legato alla direttiva AllowOverride .
660 ---------------------
662 Pacchetti da installare: ``php5 php-pear``
667 Creare nella cartella ``/var/www`` (o altra cartella visibile) un file con estensione \*.php (es ``/var/www/info.php`` contenete codice php eseguibile dall'interprete, ad es::
671 Questa funzione di php generera' la tipica pagina con le impostazioni attuali per PHP. Richiamando la pagina (es: ``http://localhost/info.php`` ) verra' generata dall'interprete PHP la pagina HTML e resa disponibile tramite Apache ai client HTTP, a prova del corretto funzionamento del modulo di PHP e della sua integrazione con il server web Apache. In caso contrario se il client http proporra' di scaricare la pagina invece che visualizzarla nel browser: non funziona l'interprete di php o sono mal configurati i MIME-type. prima di tutto assicurarsi di aver fatto ripartire Apache.
673 Installazione del supporto per Mysql a PHP
674 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
676 Installare i pacchetti::
678 php5-mysql phpmyadmin
680 Controllare tramite la pagina php.info che sia abilitato il supporto per Mysql (ripartito Apache, ricaricare la pagina e cercare con CTRL+f ``mysql``).
685 L'interfaccia web Phpmyadmin non richiede necessariamente la presenza di un database Mysql locale, puo' infatti essere utilizzata per gestire database remoti (il suo file di configurazione: ``/etc/phpmyadmin/config.inc.php`` ). Nel caso si voglia installare localmente Mysql si utilizzi il pacchetto ``mysql-server`` .
687 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/`` .
689 Installazione del supporto per Postgresql a PHP
690 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
692 Installare i pacchetti::
694 php5-pgsql phppgadmin
696 Controllare tramite la pagina php.info che sia abilitato il supporto per PostgreSQL (ripartito Apache, ricaricare la pagina e cercare con CTRL+f ``pgsql``).
700 ~~~~~~~~~~~~~~~~~~~~~
702 L'interfaccia web Phppgadmin per il database server PostgreSQL non richiede necessariamente la presenza di un database locale, puo' infatti essere utilizzata per gestire database remoti (il suo file di configurazione: ``/etc/phppgadmin/config.inc.php`` ). Nel caso si voglia installare localmente Mysql si utilizzi il pacchetto ``postgresql`` .
704 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/`` .
709 * http://www.apacheweek.com/features/vhost
711 * http://www.onlamp.com/pub/a/apache/2004/01/08/apacheckbk.html
713 I virtual host permettono di avere piu' siti internet disponibili tramite lo stesso server web, eventualmente mappati su un solo indirizzo IP. Sono generalmente di due tipi:
715 * Basati su *indirizzi IP*.
716 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.
718 * Basati su *nomi di dominio* che puntano allo stesso IP.
719 Soluzione piu' economica e diffusa che si basa sulle funzionalita' di http 1.1 .
721 Prenderemo in esame la gestione di virtual hosts basati su nomi di dominio.
726 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:
730 Per prove sul proprio sistema potete impostare i nomi dei vostri virtual server nel file /etc/hosts .
732 *Dnsmasq* (DNS server)
733 Utilizzabile al livello della rete locale per fare dei test, utilizzando direttive come: ``address=/davide.piffa.net/10.10.208.178``
735 *Servizio DNS dinamico on line*.
736 Utilizzare un servizio come ad es: https://www.dyndns.com/ per mappare nomi di dominio sul proprio indirizzo IP, comodo ad esempio se si dispone di un indirizzo IP pubblico (anche se dinamico) per la propria connessione ad internet.
739 Impostare i campi A nelle proprie zone gestite dal server DNS Bind. Ad es: ``papo A 212.22.136.248``
742 Eseguire una query DNS con ``dig``::
743 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
745 Per testare la corretta risoluzione dei vostri nomi di dominio sui relaivi indirizzi IP si usi dig (o altre utlity, vedere la sezione relativa i DNS). Dig e' contenuto nel pacchetto ``dnsutils``.
749 ; <<>> DiG 9.5.1-P1 <<>> 177.piffa.net
750 ;; global options: printcmd
752 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38036
753 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
759 177.piffa.net. 0 IN A 10.10.208.177
761 ;; SERVER: 10.10.208.248#53(10.10.28.248)
764 La parte interessante e' l'*ANSWER SECTION*: ``177.piffa.net. 0 IN A 10.10.208.177`` . Il nome di dominio 177.piffa.net viene risolto sull'ip 10.10.208.177 , nel nostro Apache (che risponde all'ip 10.10.208.177 ) dovra' essere disponibile un virtual host che corrisponde al nome ``177.piffa.net`` (``ServerName``) .
766 Il server DNS utilizzato dal sistema e' evidenziato dalla stringa: ``;; SERVER: 10.10.28.248#53(10.10.28.248)`` che dovrebbe corrispondere a quanto impostato nel vostro ``/etc/resolv.conf``. Se il vostro browser web utilizza un proxy http sara questo a risolvere i nomi di dominio, tipicamente potete disabilitare l'uso del proxy per determinati domini nella sezione di configurazione del browser.
772 Esempio di Virtual host::
775 ServerName 177.piffa.net
776 DocumentRoot /var/www/177.piffa.net/
777 ServerAdmin webmaster@177.piffa.net
780 1. ``<VirtualHost \*:80 >`` La prima riga indica l'inizio della stanza relativa al nostro virtual host, che ascoltera' su qualunque indirizzo IP (nel caso il server abbia piu' indirizzi dai quali e' raggiungibile) sulla porta ``80``.
781 2. ``Server/name`` precisa quale sara' il nome di dominio a cui verra' associato questo sito rispetto ad altri eventualmente presenti sullo stesso server web.
782 3. ``DocumentRoot`` : il path della directory che contiene le pagine del sito.
783 4. ``ServerAdmin``: l'indirizzo del webmaster, in modo da poterlo contattare in caso di problemi col sito.
784 5. ``</VirtualHost>``: *tag* di chiusura della stanza di definizione del virtual host.
786 Quelle che abbiamo appena visto sono le direttive essenziali per definire un sito virtuale, potrebbe essere utile aggiungere altre:
788 * ``ErrorLog /var/log/apache2/177.piffa.net/error.log``
789 Log degli errori separato dai restanti siti web ospitati dal server.
792 Livello di importanza degli eventi loggati: warning *attenzione* .
794 * ``CustomLog /var/log/apache2/177.piffa.net/access.log combined``
795 Log di accesso separati dagli altri siti, utile anche qua per statistiche di accesso per il solo sito virtuale.
798 Potrebbe essere utile modificare le impostazioni di una intera directory, ad esempio per abilitare l'``AuthConfig``::
800 <Directory "/var/www/miosito.net/privata">
801 AllowOverride AuthConfig
802 Options ExecCGI Indexes MultiViews FollowSymLinks
807 ``AllowOverride AuthConfig`` ora vale per l'intera directory, come le altre opzioni.
810 ---------------------
812 Tipicamente quando si installa un server web il proprio desiderio e' di dare accesso ai materiali disponibili al maggior numero di visitatori possibile. Talvolta pero' puo' essere utile poter limitare questi accessi, ad esempio per escludere un *bot* indesiderato che scansiona ininterrottamente le nostre pagine o per creare una *Area Riservata* i cui materiali non devono essere disponibile a tutti.
815 ~~~~~~~~~~~~~~~~~~~~~~
817 La forma piu' semplice di restrizione degli accessi e' su base degli indirizzi IP dei client: tipicamente i siti web sono settati per dare accesso a chiunque::
821 <Directory "/var/www/177.piffa.net">
827 Potremmo negare l'accesso a uno o piu' indirizzi IP in questo modo::
831 <Directory "/var/www/177.piffa.net">
834 Deny from 192.168.0.1
838 Ora l'IP 192.168.0.1 non potra' piu' accedere ai materiali dell'intero sito virtuale, oppure potremmo lavorare su una sola directory::
840 <Directory "/var/www/miosito.net/limitata">
842 Allow from 192.168.0.0./24
846 In questo modo solo la classe IP ``192.168.0.0/24`` potra' accedere alla directory ``/limitata``
847 Si tenga pero' conto che e' relativamente facile per un malintenzionato cambiare il proprio indirizzo IP, oppure collegarsi da un altra zona. Meno facile e' accedere ad una classe privata trovandosi all'esterno di questa, ma ci sono comunque soluzioni piu' eleganti.
849 * Mod_access: http://httpd.apache.org/docs/2.0/mod/mod_access.html
850 * mod_authz_hosti(Available in Apache 2.1 and later): http://httpd.apache.org/docs/2.2/mod/mod_authz_host.html
853 ---------------------
855 Si puo' negoziare gli accessi ad un area del sito tramite autenticazione basata su *nome utente / password*. Questo puo' venire utile per creare una area download *intranet*, alla quale possano accedere solo gli utenti previsti a prescindere dagli indirizzi IP dei loro client.
857 Tramite il modulo di Apache *mod-auth* e' possibile implementare questo paradigma, per quanto esistano soluzioni piu' granulari e sofisticate, che richiedono pero' l'implementazione di interpreti di linguaggi di programmazione, criptazione delle passwords, gestione degli utenti ed eventualmente delle sessioni.
858 Mod auth non richiede l'installazione di niente di tutto questo.
861 link: http://www.apacheweek.com/features/userauth
864 ~~~~~~~~~~~~~~~~~~~~~~
866 Decidere quale sara' il *path* della cartella da sottoporre ad autenticazione:
868 ``mkdir /var/www/177.piffa.net/privata``
870 Creazione del database delle passwords
871 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
873 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.
875 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.
877 Creiamo (con il *flag* ``-c``) il file ``/home/utente/passwords`` con l'utente ``luca``::
879 htpasswd -c /home/utente/passwords luca
881 ``htpasswd`` ci chiedera' la password da associare all'utente ``luca``. Per successive modifiche della password o aggiunta di nuovi utenti non sara' necessario usare il flag ``-c``.
883 Configurazione di Apache
884 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
886 Ora possiamo passare alla configurazione vera e propria di Apache, ma con una novita': andremo a inserire la voce in un ``.htaccess`` invece che modificare (tramite una direttiva ``<Directory>`` ) il file di impostazione del virtual-host.
888 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.
890 Dando agli utenti la possibilita' di modificare (*AllowOverride*) autonomamente alcuni parametri (in questo caso solo l'*AuthConfig*) relativi al funzionamento del loro spazio web ci togliera' l'incombenza di dover intervenire continuamente sui vari virtual host.
892 Abilitiamo l'AllowOverride nel file di configurazione del virtual host per la sola directory ``privata``::
895 ServerName 177.piffa.net
896 DocumentRoot /var/www/177.piffa.net/
897 ServerAdmin webmaster@177.piffa.net
898 <Directory "/var/www/177.piffa.net/privata">
899 AllowOverride AuthConfig
903 Per rendere il cambiamento effettivo sara' necessario fare un restart / reload di Apache.
905 Ora sara' possibile, anche per l'utente di sistema, creare un file ``.htaccess`` che sara' onorato da Apache.
907 /var/www/177.piffa.net/privata/.htaccess ::
909 # Messaggio visualizzato al prompt per l'autenticazione
910 AuthName "Area privata soggetta ad autentizazione"
911 # tipo di autenticazione da usarsi
913 # File precedentemente generato con htpasswd
914 AuthUserFile /home/utente/passwords
916 # Negoziazione degli accessi
917 # valid users permette l'accesso agli utenti specificati
918 # nel file generato da htpasswd
921 Si noti che non e' necessario fare ripartire Apache per onorare i cambiamenti (un utente non avrebbe la possibilita' di farlo!).
923 Oltre a ``valid-users`` si potrebbe scegliere di usare la formula ``users`` che permette di elencare esplicitamente gli utenti::
924 require user pippo pluto
926 L'utente *paperino* che fosse comunque presente nel file generato da htpasswd non potrebbe accedere alla risorsa.
928 Nel caso ci fossero molti utenti conviene gestirli tramite *gruppi*::
929 require group staff studenti
931 I gruppi vengono definiti in un file in modo simile a ``/etc/groups`` per gli utenti di sistema::
934 studenti: lucap federico luca
936 da richiamare tramite la direttiva ``AuthGroupFile``.
943 * 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.
945 * 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.
950 Domain Name System (spesso indicato con DNS) e' un servizio utilizzato per la risoluzione di nomi di host in indirizzi IP e viceversa. Il servizio e' realizzato tramite un sistema **gerarchico** (quindi una struttura ad albero, simile ai *file system*) **distribuito** (ogni server DNS facente parte del sistema puo' mantenere solo una parte delle informazioni, ad esempio per la sua sola *zona*), costituito dai server DNS.
952 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*.
953 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.
955 Stessa cosa vale per gli altri servizi, come la posta elettronica, ssh, ecc. : *prima si deve effettuare una query DNS*.
957 Potrebbe verificarsi uno scenario simile a questo: i vostri server per i siti web funzionano correttamente come i siti ospitati, stessa cosa per i vostri server di posta, IMAP e POP3, e tutto il resto. Ma se poi un errore nella configurazione del DNS non rende raggiungibile l'intero *sito*: per l'utente finale e' come se nulla funzionasse.
959 Infatti quando si parla di un intervento della Polizia Postale per l'*oscuramento* di un sito dal punto di vista pratico questo si traduce generalmente nella rimozione o mistificazione del record DNS relativo a quel dominio (la *PP* ha facolta' di chiedere un simile intervento ai principali provider internet che forniscono connettivita' agli utenti italiani, oltre che poter agire direttamente sul NIC italiano per i domini della TLD *.it*)
961 L'operazione di convertire un nome in un indirizzo e' detta risoluzione DNS, convertire un indirizzo IP in nome e' detto risoluzione inversa.
963 Un *Registar* e' un operatore che ha la facolta' (accreditamento da parte dell ICANN) di registrare i domini di secondo livello per gli utenti finali, dietro compenso di una modica cifra (una decina di euro) che vale come contributo su base annuale per il mantenimento dell'infrastruttura.
966 -----------------------
968 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*.
970 Ad esempio all'IP ``212.22.136.248`` era associato un PTR ``bender.piffa.net``, corrispondente al record ``212`` facente parte della zona ``136.22.212.in-addr.arpa`` gestito dal provider Tiscali/Nextra proprietario della classe C ``212.22.136.0``. Se avete un solo IP conviene lasciare al fornitore la gestire del PTR, ma se avete a disposizione un'itera classe potete chiedere sempre al vostro provider che vi *deleghi* la gestione della zona tramite i vostri DNS.
972 Per alcuni servizi, ad esempio la spedizione della posta elettronica, e' richiedeiesto che venga impostata correttamente l'associazione tra il PTR dell'indirizzo IP usato dal server di postai e il record A RR al quale questo punta( RFC1912 sezione 2.1, paragrafo 2).
976 - http://www.faqs.org/rfcs/rfc1912.html 2.1 Inconsistent, Missing, or Bad Data
977 - http://www.ietf.org/rfc/rfc2505.txt
982 Un nome a dominio e' costituito da una serie di stringhe separate da punti, ad esempio bender.piffa.net. I nomi di dominio si leggono da destra verso sinistra: *TLD* o dominio di primo livello ``net``, secondo livello ``piffa``, terzo livello ``bender``. Il dominio di primo livello (o TLD, Top Level Domain, pronunciato *tilde* in Italia), per esempio .net o .it sono limitati e decisi direttamente dall'ente assegnatario ICANN ( Internet Corporation for Assigned Names and Numbers).
984 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.
986 Ottenuto il secondo livello sara' l'utente a gestirlo: potra' in stanziare domini di terzo livello (es ``bender``) e anche oltre (es www.andrea.bender.piffa.net). Tali records saranno mantenuti dall'utente, sotto la sua responsbilita': se il proprio server DNS non fosse raggiungibile o risultasse mal configurato gli utenti non potrebbero risolvere / raggiungere i siti di loro interesse.
988 Tipicamente si ha almeno un server DNS secondario per garantire la sussistenza del servizio in caso di guasto del DNS principale. I secondari *replicano* i dati presenti nei DNS principali.
991 -----------------------
993 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:
995 * 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).
996 * Record MX - (Mail eXchange) indica a quali server debba essere inviata la posta elettronica per un certo dominio.
997 * 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.
998 * 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).
999 * Record AAAA - Restituisce un indirizzo IPv6.
1000 * Record SRV - Identificano il server per un determinato servizio all'interno di un dominio. Possono essere considerati una generalizzazione dei record MX.
1001 * Record TXT - Associano campi di testo arbitrari ad un dominio. Questi campi possono contenere una descrizione informativa oppure essere utilizzati per realizzare servizi.
1003 Vi sono anche tipi di record "di servizio", necessari al funzionamento del database distribuito:
1004 * Record NS - Utilizzato per indicare quali siano i server DNS autoritativi per un certo dominio, ovvero per delegarne la gestione.
1005 * Record SOA - (Start of Authority) usato per la gestione delle zone DNS.
1010 I computer vengono identificati in rete grazie agli indirizzi *IP*, questi pero' non sono comodi per gli utenti come riferimento per i vari server. Ad esempio sarebbe scomodo riferirsi al motore di ricerca Goggle con uno dei suoi IP: ``74.125.43.104``, e' preferibile usare il nome di dominio *www.google.com*::
1012 ping -c 1 www.google.com
1013 PING www.l.google.com (74.125.43.104) 56(84) bytes of data.
1015 Risoluzione dei nomi di dominio
1016 ----------------------------------
1018 Ci sono vari strumenti per interrogare i server DNS e ottenere l'indirizzo IP associato al nome di dominio che ci interessa::
1020 $ host www.piffa.net
1021 www.piffa.net is an alias for piffa.net.
1022 piffa.net has address 65.98.21.97
1023 piffa.net mail is handled by 10 65.98.21.97
1026 $ nslookup www.piffa.net
1027 Server: 192.168.0.10
1028 Address: 192.168.0.10#53
1030 Non-authoritative answer:
1031 www.piffa.net canonical name = piffa.net.
1033 Address: 65.98.21.97
1038 ; <<>> DiG 9.6.0-P1 <<>> www.piffa.net
1039 ;; global options: +cmd
1041 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47751
1042 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 4
1044 ;; QUESTION SECTION:
1045 ;www.piffa.net. IN A
1048 www.piffa.net. 3489 IN CNAME piffa.net.
1049 piffa.net. 3489 IN A 65.98.21.97
1051 ;; AUTHORITY SECTION:
1052 piffa.net. 86289 IN NS ns2.mydomain.com.
1053 piffa.net. 86289 IN NS ns1.mydomain.com.
1054 piffa.net. 86289 IN NS ns4.mydomain.com.
1055 piffa.net. 86289 IN NS ns3.mydomain.com.
1057 ;; ADDITIONAL SECTION:
1058 ns1.mydomain.com. 96208 IN A 64.94.117.193
1059 ns2.mydomain.com. 96208 IN A 64.94.31.67
1060 ns3.mydomain.com. 96208 IN A 66.150.161.137
1061 ns4.mydomain.com. 96208 IN A 63.251.83.74
1063 ;; Query time: 1 msec
1064 ;; SERVER: 192.168.0.10#53(192.168.0.10)
1065 ;; WHEN: Sun May 10 21:23:11 2009
1066 ;; MSG SIZE rcvd: 209
1068 Lo strumento piu' esaustivo e' ``dig``, installabile con il pacchetto ``dnsutils`` .
1073 Vediamo alcune opzioni utili nell'utilizzo di ``dig`` per l'interrogazione dei DNS Server::
1078 ; <<>> DiG 9.6.0-P1 <<>> www.google.it
1079 ;; global options: +cmd
1081 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18816
1082 ;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 7, ADDITIONAL: 0
1084 ;; QUESTION SECTION:
1085 ;www.google.it. IN A
1088 www.google.it. 250683 IN CNAME www.google.com.
1089 www.google.com. 334819 IN CNAME www.l.google.com.
1090 www.l.google.com. 186 IN A 74.125.43.103
1091 www.l.google.com. 186 IN A 74.125.43.104
1092 www.l.google.com. 186 IN A 74.125.43.147
1093 www.l.google.com. 186 IN A 74.125.43.99
1095 ;; AUTHORITY SECTION:
1096 l.google.com. 80856 IN NS f.l.google.com.
1097 l.google.com. 80856 IN NS d.l.google.com.
1098 l.google.com. 80856 IN NS b.l.google.com.
1099 l.google.com. 80856 IN NS c.l.google.com.
1100 l.google.com. 80856 IN NS a.l.google.com.
1101 l.google.com. 80856 IN NS e.l.google.com.
1102 l.google.com. 80856 IN NS g.l.google.com.
1104 ;; Query time: 1 msec
1105 ;; SERVER: 192.168.0.10#53(192.168.0.10)
1106 ;; WHEN: Sun May 10 21:34:47 2009
1107 ;; MSG SIZE rcvd: 255
1110 (senza opzioni o oggetti) Fornisce l'elenco dei *root server* utilizzati. I root server sono i server che mantengono le informazioni sui domini di primo livello (TLD) e sono quindi il punto di partenza per scorrere nella directory dei DNS per recuperare le informazioni (tipicamente un campo ``A`` per un indirizzo IP) che ci servono per raggiungere un certo servizio.
1117 . 192032 IN NS C.ROOT-SERVERS.NET.
1118 . 192032 IN NS E.ROOT-SERVERS.NET.
1119 . 192032 IN NS B.ROOT-SERVERS.NET.
1120 . 192032 IN NS L.ROOT-SERVERS.NET.
1121 . 192032 IN NS A.ROOT-SERVERS.NET.
1122 . 192032 IN NS F.ROOT-SERVERS.NET.
1123 . 192032 IN NS H.ROOT-SERVERS.NET.
1124 . 192032 IN NS G.ROOT-SERVERS.NET.
1125 . 192032 IN NS K.ROOT-SERVERS.NET.
1126 . 192032 IN NS M.ROOT-SERVERS.NET.
1127 . 192032 IN NS I.ROOT-SERVERS.NET.
1128 . 192032 IN NS J.ROOT-SERVERS.NET.
1129 . 192032 IN NS D.ROOT-SERVERS.NET.
1134 Permette di fare una query ad un server dns particolare.
1135 Es: ``dig @151.99.25.1 www.google.it``
1137 dig MX www.google.it
1138 Chiede un campo in particolare, in questo caso il campo MX
1140 dig ANY www.google.it
1141 Chiede tutti i campi, non solo i campi *a*
1143 dig -x 74.125.43.104
1144 Effettua una richiesta inversa: dall'IP al PTR associato.
1149 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.
1153 - ``nameserver``: indica il nameserver da utilizzare, indicato con l'indirizzo IP.
1155 - ``domain``: indica il nome di dominio della rete attuale, vedi voce successiva.
1157 - ``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``.
1159 Predisponendo l'infrastruttura di rete della vostra LAN e' consigliabile impostare sempre almeno un DNS cache sul vostro server locale per i vari client. In questo modo in caso di malfunzionamento del DNS o necessita' di intervenire / sostituire i DNS non sara' piu' necessario dover reimpostare ogni singolo client della LAN: bastera' intervenire sul server DNS cache, ad esempio per utilizzare un nuovo forwarder, o modificare al volo un record DNS. La modifica, anche detta *mascheramento*, di un record come il *server smtp* o un *MX* potrebbe tirarvi rapidamente fuori dai guai nel caso di un problema improvviso con la posta elettronica o qualunque altro servizio che possiate reindirizzare col DNS.
1161 Utilizzare un server DHCP e una DNS cache come ``Dnsmasq`` possono permettervi di risolvere al volo molte delle problematiche relative alla configurazione della vostra LAN: ad esempio dover intervenire manualmente su decine di client per modificare le impostazioni di SMTP | gateway | DNS | proxy.
1163 Si veda anche la pagina man di resolv.conf.
1166 Attenzione: se si usa un client DHCP, ppp (ADSL compresa) o simile questo file potrebbe' essere riscritto automaticamente in base a quanto ottenuto dal DHCP. Si veda la documentazione del pacchetto ``resolvconf``.
1172 Tabella statica per l'associazione tra IP e nomi di dominio::
1176 127.0.0.1 localhost.localdomain localhost
1177 10.10.208.162 daniela daniela.piffa.net
1178 10.10.208.254 mirror mirror.piffa.net
1179 91.191.138.15 thepiratebay.org
1180 192.168.0.11 chrome chrome.mydomain.com
1182 Il contenuto del file e' un associazione tra un *IP* e stringhe di testo (anche piu' di una per IP) es: ``mirror`` o veri e propi nomi di dominio ``mirror.piffa.net``. Si puo inserire un nome semplice come *casa* per riferirsi ad un host che si ha necessita' di contattare spesso, oppure mappare un nome di dominio completo su un indirizzo IP.
1184 Il problema e' la gestione di questo file su molti hosts: quando gli host cambiano IP si devono aggiornare manualmente i records, operazione in se' non particolarmente gravosa ma che andra' fatta per ogni client della vostra LAN. Un metodo semplice per distribuire questo file e' utilizzare ``Dnsmasq``: questo infatti legge e onora il file ``hosts`` che avete prodotto e lo rende disponibile ai clients tramite le query DNS.
1186 Dnsmasq lavora come un server DNS, i vostri client lo interrogheranno per tradurre nomi di host e domini in indirizzi IP, risolvendo il problema della *distribuzione* del file ``hosts`` tra molteplici clients. Infatti il servizio DNS indica appunto una *directory distribuita* per la risoluzione dei nomi di dominio, risolvendo i problemi dell'aggiornamento e diffusione dei continui cambiamenti di questa.
1188 Modificare la risoluzione di un nome di dominio esistente (ad esempio riconducendola a un IP interno) e' un modo drastico e funzionale per *annullarlo* rendendolo non disponibile alla propria rete locale. Ad esempio aggiungere al file ``/etc/hosts``::
1190 127.0.0.1 www.facebook.com
1192 Impedira' agli utenti della LAN di raggiungere *facebook*, ora reindirizzato a ``localhost``.
1194 Oppure si potrebbe ricondurre l'indirizzo IP di un server HTTP pubblico usato per i downloads (ad esempio un mirror della propia distribuzione come ``ftp.it.debian.org``) a un equivalente mirror creato all'interno della rete locale, riducendo il traffico verso l'esterno e aumentando notevolmente la velocita' di scaricamento.
1199 Ogni computer ha un *proprio nome* visualizzabile (e modificabile) con il comando ``hostname``. Quando utilizzate a una shell su un host in genere l'hostname compare nel prompt della shell.
1201 Per visualizzare il nome dell'host su cui si sta operando si digiti semplicemnte ``hostname``, lo stesso comando con un oggetto modifica temporaneamente il nome dell'host. Per modificare in modo permanente il nome del computer si modifichi il contenuto del file ``/etc/hostname``.
1203 Si faccia attenzione a non aver un hostname puramente numerico: ad es. ``161``. E' opportuno che il nome sia comunque un alfanumerico: ``host-161`` o simile.
1208 Per semplicita' gli host sono generalemente raggiungibili dall'esterno mappando il loro IP su un nome di dominio FQDN: fully qualified domain name, composto generalmente da *hostname*.``domain-name``, ad es. *bender*.``piffa.net``.
1210 Alcuni servizi internet fanno affidamento sul PTR dell'IP del server per cercare una conferma che il *servizio* sia veramente chi afferma di essere (ad esempio STMP).
1212 Non e' automatico che un servizio, ad esempio un server di posta, si qualifichi leggendo il contenuto del file ``hostname`` aggiungendo come suffisso il dominio della rete di cui fa parte l' host: a volte questo parametro puo' essere specificato nel file di configurazione del servizio::
1214 * Squid (HTTP proxy): ``visible_hostname``
1216 * Postfix (SMTP server): ``myhostname``
1218 I motivi sono diversi, senza entrare nel dettaglio dei vari protocolli si pensi comunque che un host ha sempre un solo nome, ma puo' avere un numero variabile di *device di rete* sia fisici che virtuali con relativi *indirizzi IP*, e piu' servizi in ascolto sui vari IP.
1223 Dnsmasq puo' svolgere le funzioni di un DNS cache / forwarder, server DHCP, e' caratterizzato dalla facilita' di configurazione, limitato uso di risorse, adattabilita' a connessioni *dinamiche* come ADSL o altre punto a punto (anche via cellulari) per condividere rapidamente la rete (cosa molto utile se ci dovesse trovare a ridare connettetivita' a una rete momentaneamente sprovvista), dalla possibilita' di modificare rapidamente i record DNS serviti alla rete anche grazie alla distribuzione del file ``/etc/hosts`` locale. Puo' essere anche utilizzato come `server per il boot da rete <http://www.debian-administration.org/articles/478>_` .
1225 Dnsmasq e' un interessante alternativa all'uso del server DNS Bind in modalita' *forwarding e cache-only* (non autoritativo) accompagnato dal server DHCPd. I vantaggi sono:
1227 - Leggerezza: puo' essere fatto girare su una macchina relativamente debole in caso di bisogno.
1228 - Rapidita' di configurazione (in particolare per servire dei record A / MX alla rete, modificando al volo i valori originali ospitati sul server DNS pubblico).
1229 - Ben integrato con connessioni PPP : e' ingrado di rilevare i cambiamenti dei dns suggeriti e impostarli come forwarders (utile se dovete rendere disponibile rapidamente una connessione a internet a una rete in difficolta').
1231 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.
1232 Molto utile per scopi didattici, sopratutto per testare server SMTP impostando al volo i campi MX per nomi di dominio fittizi.
1238 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:
1242 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* .
1246 Simile alla voce precedente ma per i reverse look-up.
1250 Nome di dominio della rete da passare ai client.
1254 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.
1260 Per attivare il demone DHCP di Dnsmasq basta aggiungere al file di configurazione il *range* degli IP che si vuole assegnare ai client con il *lease time* (tempo di rilascio: quanto a lungo saranno validi gli IP assegnati) espresso in ore.
1262 Si faccia *attenzione*: in una rete puo' essere presente **un solo server DHCP**, o per meglio dire qualunque server DHCP ascolta sul broadcast ``255.255.255.255`` e potrebbe rispondere a un pacchetto di richiesta DHCP. Quindi non fate partire inavvertitamente un server DHCP in una rete gia' servita e **non vi azzardate ad andare in giro con un portatile con un server DHCP attivo** nelle reti altrui. Questo vale anche per i laboratori di informatica dei corsi di reti: non fate partire il vostro server DHCP se siete collegati alla rete interna!
1264 /etc/dnsmasq.conf (riga 118)::
1266 dhcp-range=192.168.0.20,192.168.0.50,24h
1271 Dnsmasq lavora di default come cache dns: inserire al file ``/etc/resolv.conf`` il nameserver localhost in cima alla lista dei *nameserver* disponibili.
1273 nameserver 127.0.0.1
1276 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`` ::
1278 prepend domain-name-servers 127.0.0.1;
1280 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!).
1283 Bind : DNS Autoritativo
1284 ===========================
1286 Le soluzioni viste possono bastare per la rete locale o per fare delle prove, ma prima o poi verra' il momento in cui si e' chiamati a gestire dei domini su internet: lo standard e' da sempre *Bind* ( demone *named*), ora alla versione 9.
1288 Installare i pacchetti::
1295 Bind appena installato funzionera' come DNS cache: si faccia un test con un ``dig @localhost`` . Bind a differenza di Dnsmasq e' autonomo: non ha bisogno di forwardare (inoltrare) le query a un DNS esterno: queste verranno risolte direttamente da Bind partendo dai *DNS root servers*.
1297 E' comunque possibile impostare dei DNS forwarders, tipicamente i DNS server forniti dal proprio provider, per velocizzare le query:
1299 /etc/bind/named.conf.options (riga 13)::
1305 Nel caso si voglia usare Bind solo come server DNS cache per la propria LAN senza ospitare delle zone DNS pubbliche sara' il caso di limitare gli accessi al server alla sola LAN:
1307 /etc/bind/named.conf.options (riga 19)::
1309 // Se il proprio server ha IP 10.10.208.254
1310 // sulla rete LAN privata:
1311 listen-on { 10.10.208.254; }
1313 E non si lasci il server in ascolto su uno degli eventuali indirizzi IP pubblici.
1315 Se questo non fosse possibile si puo' sempre lavorare su una *acl*:
1317 /etc/bind/named.conf ::
1320 10.10.208.0/24 ; 127.0.0.0/8 ;
1323 Per poi aggiungere all'interno della stanza options la direttiva che abilita' l'entita' ``localnet``:
1325 /etc/bind/named.conf.options ::
1327 allow-query {"localnet" ;} ;
1331 ---------------------
1333 Se avete acquistato un nome di dominio e vi serve un software DNS per gestirlo Bind e' la scelta piu' diffusa. Ora vedremo come configurare una *zona* (come piffa.net) in modo che Bind sia autoritativoper questa, rispondendo alle query DNS di tutta la rete internet.
1339 Prima di tutti impostiamo il server bind per gestire la zona, per non fare confusione e' opportuno inserire le propie zone DNS nel file ``named.conf.local`` e non in ``named.conf``.
1344 // Do any local configuration here
1347 // Consider adding the 1918 zones here, if they are not used in your
1349 //include "/etc/bind/zones.rfc1918";
1353 file "/etc/bind/pz/piffa.net";
1357 Il nostro server DNS sara' il principale, al quale poi potremo affiancare dei DNS secondari nel caso questo non sia disponibile.
1359 file "/etc/bind/pz/piffa.net"
1360 Dove verranno inserite le informazioni vere e propie di questa zona.
1362 Configurazione della zona
1363 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
1365 Ora dovremo preparare il file contenente i record DNS della zona *piffa.net*, come abbiamo indicato prima questi saranno contenuti nel file ``/etc/bind/pz/piffa.net`` . Tenere le zone dentro una sottocartella e' buona abitudine, usare ``pz`` per queste e' una vecchia abitudine.
1369 ; Zona per il dominio di secondo livello piffa.net
1372 @ IN SOA ns1.piffa.net. hostmaster.piffa.net. (
1374 8H ; refresh (8 hours)
1375 2H ; retry (2 hours)
1376 4W ; expire (4 weeks)
1377 1D ; minimum (1 day)
1384 TXT "Piffanet main site"
1390 test.piffa.net. A 94.23.63.105
1391 *.piffa.net. A 94.23.63.105 ; *catch all domain
1397 All'interno di questo file si possono inserire dei commenti con il carattere ``;`` (punto-e-virgola), si faccia attenzione alla rigida sintassi: apertura e chiusura delle parentesi tonde nella parte ``IN SOA``, uso del ``punto`` finale per precisare un nome di dominio specifico (*FQDN*: Fully-qualified Domain Name) come ``test.piffa.net.`` a differenza degli altri domini di terzo livello come ``pop,imap,smtp`` .
1399 La zona inizia con una direttiva ``$TTL 3D`` (RFC 2308) che indica la durata (in questo caso tre giorni) che ogni record dovrebbe avrebbe nella cache degli altri serber DNS. Questo valore dovrebbe essere superiore a un giorno, se non modificate spesso i valori dei vostri record DNS e' consigliabile settarlo a 2/3 settimane in modo da limitare la frequenza delle query al propio server. Questo parametro puo' essere modificato per singoli record::
1401 $TTL 3D ; 3 giorni: default se non specificato altrimenti
1402 rapido 5h IN A 94.23.63.105 ; usa un TTL di 5 ore
1403 lento 3w IN A 94.23.63.105 ; usa un TTL di 3 settimane
1404 normale IN A 94.23.63.105 ; usa il TTL di default: 3 giorni
1407 Segue poi il nome della zona, indicato con la ``@`` per richiamare la zona originale precisata nel file ``named.conf.options`` . Segue il campo ``SOA``.
1409 SOA: Start of Authority Record
1410 `````````````````````````````````
1412 Il record SOA puo' comparire solo una volta in una zona, contiene informazioni relative all'autorita' del server DNS.
1414 ns1.piffa.net. name-server
1415 primary master DNS di questo dominio.
1417 hostmaster.piffa.net. email-addr
1418 email-addr: indirizzo email della persona responsabile di questa zona, il primo punto viene tradotto in una *chiocciola* ``@`` dato che questo carattere ha un'altro utilizzo all'interno di questo file. Il referente della zona **deve** essere un email valido e controllato, come consuetudine si usa ``hostmaster@dominio.tilde`` .
1420 200905245 serial number
1421 Questo valore serve per indicare quando e' stato modificato questo file di configurazione, secondo il formato ``yyyymmddss``: ``yyyy`` = anno, ''mm'' = mese, ''dd'' = giorno, ''ss'' = seriale. Il seriale che deve essere sempre specificato anche per una cifra, va incrementato di una unita' nel caso vengano fatte piu' modifiche *nello stesso giorno*.
1424 Indica ai DNS secondari quanto tempo attendere per cercare di aggiornare i loro dati con il DNS master.
1427 Intervallo di tempo per il DNS slave (secondario) da aspettare prima di cercare di ricontattare il *master* in caso di problemi col *refresh*.
1430 Indica quando i dati dei dns secondarinon sono piu' autoritativi in caso di impossibilita' degli *slaves* di ri-aggiornarsi con il *master*. Consigliato un valore di 2/4 settimane.
1433 Questo valore indicava il TTL fino alla versione 8 di Bind, da Bind 9 e secondo la RFC2308 indica la durata del *negative caching*, quanto i resolvers (ad esempio un server dns cache) puo' mantenere un record *negativo* (che non indica la corrispondenza tra un nome di dominio e un ip, ma la non esistenza del record). Nell'uso per il negative caching viene fissato un valore massimo di 3 ore dalla RFC 2308.
1439 All'interno della zona possono essere utilizati vari tipi di records (RR):
1442 Informazioni testuali associate ad un record
1445 Name Server della zona. Non deve essere un cname.
1448 Indirizzo ipv4 da associare al record
1451 Indirizzo ipv6 da associare al record
1454 Canonical Name: un alias per un host: ad esempio per il dominio piffa.net possiamo settare degli alias come ``www.piffa.net, http.piffa.net, virtual.piffa.net, ftp.piffa.net, imap.piffa.net``. Comodo quando diversi alias sono sempre riferiti allo stesso ip.
1457 Mail Exchanger: server di posta che si occupera' della posta elettronica per questo dominio.E' opportuno avere almeno un server di posta di back-up, per indicare la priorita' di un MX rispettoad un altro si usa un valore di 2 cifre: il valore piu' basso indica priorita' piu' bassa. Es: ``MX 10 smtp.piffa.net.`` per il server SMTP principale e ``MX 40 smtp2.piffa.net`` per il secondario. Non deve essere un cname.
1460 Reverse look-up, usato per la mappatura inversa di un indirizzo ip a una stringa identificativa dell'host. Si noti che per poter modificare questi record si deve avere *in gestione* la *zona IP*, se cosi' non fosse si dovra' chiedere al propio provider la modifica di questo record per il propio ip. Links: http://www.zytrax.com/books/dns/ch3/
1465 Data l'importanza del servizio DNS e' necessario avere ridondanza per i server DNS che ospitano i vostri dati: in caso di indisponibilita' del server *master* (nel caso fosse il solo a tenere i dati questo comporterebbe la *scomparsa* di tutti i servizi / host da esso seviti!) il client potrebbe contattare uno degli *slave*.
1467 Gli slave recuperano i dati dei recordos RR direttamente dal master e non sara' quindi necessario dover mantenere manualmente il file di configurazione della zona sugli slaves, ogni volta che aggiorneremo il master questi dati si propaghera' agli slaves automaticamente.
1469 Per attivare uno *slave* per la nostra zona di esempio ``piffa.net`` si inserisca nel file ``named.conf.local`` dello slave server::
1473 file "/etc/bind/pz/piffa.net";
1474 masters { 192.168.0.1; };
1477 Facendo ripartire Bind il file ``/etc/bind/pz/piffa.net`` viene creato automaticamente.
1479 Segue un estratto di ``/var/log/syslog`` al ``restart`` di ``bind9`` sullo slave::
1481 ... slave named[2256]: zone piffa.net/IN: loaded serial 200905245
1482 ... slave named[2256]: running
1483 ... slave named[2256]: zone piffa.net/IN: sending notifies (serial 200905245)
1484 ... slave named[2256]: client 192.168.0.1#1464: received notify for zone 'piffa.net'
1485 ... slave named[2256]: zone piffa.net/IN: notify from 192.168.0.1#1464: zone is up to date
1488 Bind9 (versione 9.3 presente in Debian Lenny) richiede una esplicita autorizzazione alla notifica per lo stesso server slave, che in fase di avvio interroghera' (inviando un notify) se' stesso per valutare se i dati relativi alla zona di cui e' slave sono aggiornati. Si aggiunga quindi al file ``/etc/bind/named.conf.options`` dello slave: ``allow-notify { 192.168.0.1; };`` all'interno della stanza ``options``, in cui l'inidirizzo IP inserito e' quello dello stesso slave server.
1490 Aggiornamento dinamico: nsupdate
1491 ----------------------------------
1493 Dalla versione 8 di Bind e' dsponibile l'utility ``nsupdate`` (disponibile nel pacchetto ``dnsutils``) per aggiornare automaticamente i record di una zona secondo il paradigma client / server ( RFC2136 ) . Posto che abbiate a disposizione un server DNS Bind on-line su un indirizzo IP fisso e un zona da gestire (che potrebbe essere anche solo la delega di un dominio di terzo livello come *casa.miodominio.net*) sara' possibile aggiornare automaticamente i record che tirano a degli indirizzi IP *pubblici ma dnamici*, come quelli spesso messi a disposizione dei provider per le connessioni ad internet residenziali, in modo da poter rendere sempre raggiungibile la vostra workstation a casa anche dopo un aggiornamento dell'ip dinamico associato alla connessione.
1495 L'auenticazione del client nsupdate che avra' la possibilita' di aggiornare il server DNS master avviene tramite *Transaction signatures* (TSIG, RFC2845) usando un algoritmo di criptazione dati asimmetrico *HMAC-MD5* : generata una coppia di chiavi sul client / nsupdate con l'utility si dovra' trasferire la chiave pubblica sul server *master*, che verra' configurato per onorare gli aggiornamenti (eliminazione e inserimento di record RR) autenticati dalla chiave privata.
1497 Configurazione client (nsupdate)
1498 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1500 Sul client, sul quale non deve essere necessariamente installato un server DNS Bind ma la sola utility ``nsupdate``, generiamo la coppia di chiavi con l'utility ``dnssec-keygen`` installabile tramite il pacchetto ``bind9utils``::
1502 dnssec-keygen -a HMAC-MD5 -b 512 -n USER home.piffa.net.
1504 Otterremo le due chiavi ``Khome.piffa.net.+157+04331.key Khome.piffa.net.+157+04331.private``, la chiave pubblica dovra' essere resa noto al server master che ricevera' l'update dei records.
1506 Configurazione server: riconoscimento chiave
1507 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1509 Per rendere nota al server la chiave pubblica generata sul client si aggiunga quindi al file ``/etc/bind/named.conf`` sul server::
1510 key home.piffa.net. {
1512 secret "txfAkNTScANEu2V73mCeiDpXNc3pmf+7ONOoKnTKQKIZMzierSmeHjK5 Z8ntnByt/PJwv26jCIsVh8n+xzVsRw==";
1516 La parte ``secret``, che potete leggere direttamente nel file \*.key della chiave genearta, e' scritto *tutto sulla stessa riga* senza ritorni a capo.
1519 Server: gestione dell'intera zona
1520 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1522 Sul server modifichiamo il file di configurazione ``named.conf.local`` della zona della quale vogliamo concedere l'aggiornamento al client::
1526 file "/etc/bind/pz/piffa.net" ;
1532 Sara' necessario assicurarsi che il demone di Bind sia in grado di modificare il file ``/etc/bind/pz/piffa.net``: dato che questo file ora sara' gestito da lui si proceda a cedergli la propieta' del file::
1533 chown bind /etc/bind/pz/piffa.net
1535 Altro problema che si potrebbe porre: gli orologi di sistema dei due host devono essere sincronizzati per poter valutare l'opportunita' di un aggiornamento: si consigla di installare su entrambi l'utility ``ntpdate`` e di eseguirla facendo riferimento ai time server di Debian::
1537 apt-get install ntpdate
1541 Ora possiamo provare dal client a effettuare l'iserimento di un record per testarne il funzionamento::
1543 # nsupdate -k Khome.piffa.net.+157+04331.private -v
1544 > server ns1.piffa.net
1545 > update add home.piffa.net. 86400 A 192.168.0.2
1547 Outgoing update query:
1548 ;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id: 0
1549 ;; flags: ; ZONE: 0, PREREQ: 0, UPDATE: 0, ADDITIONAL: 0
1551 home.piffa.net. 86400 IN A 192.168.0.1
1556 Per comprendere meglio l'uso dell'utility ``nsupdate`` si consiglia la lettura della relativa pagina man. Nella prima riga viene invocato il comando ``nsupdate`` impostando col flag ``-k`` la chiave privata generata precedentemente, con ``server`` si imposta quale server NS autoritario della zona (che abbiamo precedentemente configurato per ricevere gli aggiornamenti) vogliamo contattare. Alla riga sucessiva ``update`` viene aggiunto un record ``A`` per la il dominio ``home.piffa.net`` indirizzato all'IP ``192.168.0.2``, poi ``show`` mostra quanto ci si prepara a comunicare al server con il finale ``send`` .
1558 Si noti che in questo modo *l'intera zona* piffa.net e suscettibile di essere modificata dal client, che potra' eliminare e inserire qualunque record. E' possibile gestire in modo piu' granulare la zona, ad esempio concedendo al client i privilegi per gestire solo una parte della zona o i tipo di record da gestire.
1560 Automatizzare l'aggiornamento dinamico
1561 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1563 Nsupdate risulta comodo per tenere aggiornati i record DNS degli host connessi ad internet con indirizzi IP dinamici (pubblici) assegnati dal provider. Il client deve essere in grado di contattare autonomamente il server DNS per comunicare un cambiamento del suo ip. Vediamo innanzi tutto un primo script per nsupdate::
1566 # Diamo al demone ppp un po' di tempo per negoziare la connessione
1567 # prima di leggere l'IP ottenuto
1569 IPADDR=$(/sbin/ifconfig ppp0 | awk '/inet/ { print $2 } ' | sed -e s/addr://)
1571 nsupdate -k /root/dns/Khome.piffa.net.+157+04331.private <<-EOF
1572 server 192.168.0.254
1573 zone home.piffa.net.
1574 update delete home.piffa.net. A
1575 update delete home.piffa.net. MX
1576 update add home.piffa.net. 432000 A $IPADDR
1577 update add home.piffa.net. 432000 MX 10 home.piffa.net.
1583 Questo script legge il valore del device di rete ``ppp0`` creato dal `pppoe` di una connessione ADSL per ottenere l'indirizzo IP ottenuto dal provider (prima di farlo aspetta 15 secondi per dare il tempo al ``pppoe`` di negoziare la connessione).Vengono poi eliminati gli esistenti valori ``A`` e ``MX`` per ``home.piffa.net`` (si noti il punto finale dopo *net*) e inseriti quelli attuali.
1585 Resta da decidere quando richiamare questo script: l'evento che causa l'assegnazione del nuovo IP in questo caso e una nuova connessione ``pppoe``, quindi sarebbe consigliabile inserire lo script nelle routine comprese in ``/etc/ppp/ip-up.d`` (si veda la documentazione di ppp), nel caso questo non desse i risultati sperati (per problemi di connessione) come via estrema si consideri di mettere lo script nella routine del demone ``cron`` in modo che venga eseguito periodicamente (ad esempio ogni giorno).
1591 * DNS for Rocket Scientists http://www.zytrax.com/books/dns/
1592 * DNS HOWTO http://www.langfeldt.net/DNS-HOWTO/BIND-9/
1597 Samba e' un progetto libero che fornisce servizi di condivisione di file e stampanti a client SMB/CIFS.
1599 Samba e' liberamente disponibile, al contrario di altre implementazioni SMB/CIFS, e permette di ottenere interoperabilita' tra Linux, Unix, Mac OS X e Windows.
1601 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.
1606 Pacchetti da installare per utilizzare Samba in modalita' client [#]_ ::
1610 Pacchetti da installare per utilizzare Samba in modalita' server::
1612 samba smbfs smbclient
1614 .. [#] 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``.
1616 Durante la prima installazione viene chiesto il nome del gruppo di appartenenza, il default per Windows e' ``WORKGROUP``. In aula usiamo invece ``208`` .
1618 Per riconfigurare Samba si usi il comando::
1620 dpkg-reconfigure samba-common
1622 Passwords e autenticazione
1623 ---------------------------
1625 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:
1627 1 Sistema \*Unix ( GNU/Linux )
1628 E' la password dell'*utente di sistema* che viene usata sul sistema operativo su cui gira il software Samba. E' importante tenere conto anche delle *user-id* e *group-id* degli utenti che dovranno fisicamente scrivere sui file system. Se un utente non puo' scrivere in una certa posizione del file system (ad esempio nella cartella ``/mnt/condivisione`` che sara' stata necessariamente creata inizialmente dall'utente ``root``) per mancanza dei privilegi di scrittura allora neanche Samba potra' farlo nel momento in mette a disposizione la risorsa all'utente. Se si montano file-system dedicati per le condivisioni controllare i permessi e proprieta' dei *punti di mount**.
1629 Queste passwords sono salvate nel solito file /etc/shadow (richiamato da /etc/passwd).
1631 2 Password per l'applicativo Samba
1632 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`` .
1634 3 Password per Windows.
1635 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.
1641 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!
1643 Creazione di un utente denominato sambo::
1645 adduser --shell /bin/false sambo
1647 Nel file ``/etc/passwd`` avremo qualcosa come::
1649 sambo:x:1001:1001:Sambo utente Samba,,,:/home/sambo:/bin/false
1652 Aggiunta dell'utente al database delle password per Samba e generazione della sua password::
1656 Se successivamente si vorra' modificare la password di un utente gia' esistente si usi::
1661 La password sotto Windows verra' modificata sul sistema Windows.
1663 Creare la condivisione
1664 ------------------------
1666 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.
1668 Creazione della risorsa sambo_share nella home dell'utente sambo::
1670 # mkdir /home/sambo/sambo_share
1671 # chown sambo:sambo /home/sambo/sambo_share/
1673 Sicurezza: permessi di esecuzione sul server
1674 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1676 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.
1677 Si potrebbe avere quindi, ipotizzando una condivisione in ``/mnt/share`` che risieda su di un file system dedicato:
1681 /dev/hda10 /mnt/share ext3 rw, **nosuid,noexec** 0 3
1683 Si noti anche l'uso di *nosuid* per evitare la possibilita' di eseguire programmi con credenziali diverse.
1685 Configurazione dell'applicativo Samba vero e proprio.
1686 ------------------------------------------------------
1688 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.
1691 /etc/samba/smb.conf riga ~235 , Share Definitions (in vim si usi 235gg )::
1694 # Percorso della cartella condivisa
1695 path = /home/sambo/sambo_share
1696 # Se gli utenti possono scrivere / modificare file
1698 # Negoziazione degli accessi su base utenti / passwords
1701 # #######################################
1702 # Altri parametri opzionali di interesse
1703 # Se posso vedere la condivisione da esplora risorse
1704 # anche se non ho i privilegi per accedervi.
1706 # Commento indicativo della risorsa
1707 comment = Condivisione per Sambo
1709 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`` .
1712 Creazione di un gruppo
1713 ~~~~~~~~~~~~~~~~~~~~~~~~~
1715 Se si deve condividere una risorsa con un numero consistente di utenti e' consigliabile lavorare in termini termini di gruppi piuttosto che elencare la lista degli utenti in ``valid users``.
1717 Dopo aver creato il gruppo del quale volete facciano parte i vostri utenti (``addgroup nome_gruppo``), inserite i vostri utenti nel gruppo (``adduser nome_utente nome_gruppo``) e modificate la direttiva ``valid users`` in ``smb.conf`` per riferirsi ad un gruppo piuttosto che a degli utenti. Per riferirsi a un gruppo si usi il carattere ``@ chicciola`` col ``nome_del_gruppo``::
1719 # Negoziazione degli accessi su base gruppo
1720 valid users = @nome_gruppo
1724 --------------------
1726 Come testare il servizio
1730 smbclient -U sambo -L localhost
1732 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::
1734 Sharename Type Comment
1735 --------- ---- -------
1736 sambo_share Disk Condivisione per Sambo
1737 print$ Disk Printer Drivers
1738 IPC$ IPC IPC Service (base server)
1739 sambo Disk Home Directories
1741 In particolare l'ultima voce relativa alla home directory dell'utente dovrebbe essere visibile solo agli utenti autenticati.
1743 In alternativa e' possibile montare realmente la condivisone anche su GNU/Linux tramite un client per samba e testarne il corretto funzionamento::
1745 mount -t smbfs //localhost/sambo_share /mnt/sambo_mount/ --verbose -o user=sambo
1747 Server di posta: Postfix
1748 ============================
1750 Il server di posta che prenderemo in considerazione e' Postfix, a seguire un estratto di un file di configurazione *semplice* con l'abilitazione delle *Maildir* nelle ``/home`` degli utenti per la consegna della posta:
1752 ``/etc/postfix/main.cf``::
1754 # ...segue dalla riga ~30
1755 myhostname = 162.piffa.net
1756 alias_maps = hash:/etc/aliases
1757 alias_database = hash:/etc/aliases
1758 myorigin = 162.piffa.net
1759 mydestination = 162.piffa.net, localhost
1760 # Se non avete un ip pubblico e statico, con un adeguato record PTR
1761 # dovrete usare un realy host per l'invio della posta
1762 relayhost = smtp.piffa.net
1764 mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
1765 # Se dovete inviare la posta per i client della vostra LAN privata:
1766 # mynetworks = 127.0.0.0/8 192.168.0.0/24 [::ffff:127.0.0.0]/104 [::1]/128
1767 # E si faccia BEN ATTENZIONE a non diventare un open realay smtp
1770 # Per effettuare lo storaggio della posta nelle home directory degli utenti
1771 # in una Maildir invece che nella Mailbox in /var/mail/nome_utente
1772 # si disabiliti procmail
1773 #mailbox_command = procmail -a "$EXTENSION"
1775 # cartella_i abiliti lo storaggio della posta nella Maildir/ (si noti lo slash)
1776 # all'interno della home dell'utente:
1777 home_mailbox = Maildir/
1778 mailbox_size_limit = 0
1779 recipient_delimiter = +
1780 inet_interfaces = all
1783 E' disponibile un file di configurazione di esempio ben piu' articolato e commentato::
1784 /usr/share/postfix/main.cf.dist .
1786 Test del server smtp
1787 -----------------------
1789 Per testare il corretto funzionamento del server di posta si puo' procedere in vari modi.
1791 - Spedire una mail a una casella locale / remota e controllare i log (syslog)
1792 - Collegarsi via *telnet* al server di posta: http://www.netadmintools.com/art276.html
1793 - usare una utility come SWAKS
1798 Per gli utenti meno esperti e' consigliabile utilizzare *SWAKS*: si installi l'omonimo pacchetto e si esegua un test con::
1799 swaks --to utente@destinatario.tilde --from utente@propio.mail.tilde
1801 Ecco un esempio di una sessione corretta::
1803 swaks --to andrea@piffa.net from andrea@mydomain.com
1804 === Trying smtp.piffa.net:25...
1805 === Connected to smtp.piffa.net.
1806 <- 220 zoo.piffa.net ESMTP Postfix (Debian/GNU)
1807 -> EHLO alice.mydomain.com
1808 <- 250-zoo.piffa.net
1810 <- 250-SIZE 10240000
1814 <- 250-ENHANCEDSTATUSCODES
1817 -> MAIL FROM:<root@alice.mydomain.com>
1819 -> RCPT TO:<andrea@piffa.net>
1822 <- 354 End data with <CR><LF>.<CR><LF>
1823 -> Date: Thu, 28 May 2009 13:11:19 +0200
1824 -> To: andrea@piffa.net
1825 -> From: root@alice.mydomain.com
1826 -> Subject: test Thu, 28 May 2009 13:11:19 +0200
1827 -> X-Mailer: swaks v20061116.0 jetmore.org/john/code/#swaks
1829 -> This is a test mailing
1832 <- 250 2.0.0 Ok: queued as 41FB261AFC
1835 === Connection closed with remote host.
1842 Postfix e' un server SMTP, di conseguenza se volete che i vostri utenti possano *scaricare* in locale la posta generalmente volete mettere a loro disposizione un server *POP3* o *IMAP*. Oppure entrambi.
1844 Pacchetti da installare
1845 courier-imap courier-pop
1847 Si noti che IMAP necessita delle *Maildir*, non funziona con le Mailbox in ``/var/mail/`` .
1849 Client a riga di comando
1850 ---------------------------
1852 Per testare il corretto funzionamento del server di posta e' utile avere a disposizione delle utility per inviare e leggere la posta: ovviamente da riga di comando.
1857 Uno dei client piu' semplici, sopratutto per inviare un messaggioi. e' sufficiente usare una formula come::
1858 mail utente@dominio.com
1860 Se il comando ``mail`` non fosse disponibile si installi il pacchetto ``mailx``.
1862 Al primo prompt si digitera' l'oggetto, il testo del messaggio (per terminare l'inserimento lasciare una riga vuota, digitare un ``punto + Invio`` su una riga vuota), la Carbon Copy (se necessaria).
1866 mail andrea@localhost
1867 Subject: Oggetto della mail
1869 per terminare il messaggio
1870 lasciare una riga vuota
1871 e un punto (poi Invio).
1876 Per altrre opzioni si veda la pagina man.
1881 Mutt e' uno dei gestori di posta preferiti da chi preferisce utilizzare l'interfaccia testuale per la gestione della posta.
1883 Mutt ha un file di configurazione ``.muttrc`` nella *home* dell'utente, alcuni settaggi possono essere utili:
1885 set folder="~/Maildir"
1886 Per utilizzare ``/home/nome_utente/Maildir come mailbox``, invece del default ``/var/mail/nome_utente``.
1889 Utilizzare ``vim`` come editor per comporre i messaggi.
1892 Spesso e' utile poter *levvere al volo* la Mailbox / Maildir di un utente sul server di posta, per controllare se i messaggi vengono recapitati correttamente::
1894 mutt -f /var/mail/utente
1895 mutt -f /home/utente/Maildir
1897 In modo analogo si puo' consultare al volo la propia mailbox su un server remoto tramite IMAP/POP::
1899 mutt -f imap://nome_utente@piffa.net
1905 Per mettere a disposizione degli utenti un client web per gestire la propria posta si installi il pacchetto: ``squirrelmail`` . Ci sono tanti altri client web disponibili: questo e' particolarmente semplice. Naturalmente dovrete aver installato: ``php5 apache2`` .
1907 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::
1909 cd /etc/apache2/conf.d/
1910 ln -s /etc/squirrelmail/apache.conf ./squirrelmail.conf
1916 Il *graylisting* e' un sistema relativamente poco invasivo, con un limitato consumo di risorse per limitare lo *SPAM* in arrivo sul propio server di posta. Come suggerisce il nome e' una via di mezzo tra una *white list* (una lista di mittenti privilegiata, sempre benvenuti) e una *black list* (mittenti *bannati*, banditi dal poter inviare nuovi messaggi).
1918 Il funzionamento e' relativamente semplice: ogni mittente sconosciuto viene immediatamente rifiutato con un errore *non grave* come un *server non disponibile, provare piu' tardi*. Questo inconveniente non dovrebbe mettere in difficolta' un server di posta / mittente legittimo, che dopo un periodo di attesa tentera' nuovamente di inviare il messaggio ottenendo finalmente il risultato atteso. Diversamente un *bot* per l'invio di SPAM o un applicazione improvvisata (tipicamente di derivazione virale) che stesse inviando il messaggio *probabilmente* non insisterebbe, rinunciano ad inviare il messaggio preferendo destinazioni meno problematiche.
1921 Abilitazione in Postfix
1922 ~~~~~~~~~~~~~~~~~~~~~~~~
1924 Installare il pacchetto: ``postgrey`` e aggiungere il file di configurazione di Postfix ``/etc/postfix/main.cf``::
1926 smtpd_recipient_restrictions =
1928 reject_unauth_destination,
1929 check_policy_service inet:127.0.0.1:60000
1934 Inviando un messaggio il client dovrebbe ricevere un iniziale messaggio di rifiuto del messaggio::
1936 swaks --to andrea@piffa.net from andrea@mydonain.com
1937 === Trying smtp.piffa.net:25...
1938 === Connected to smtp.piffa.net
1941 -> RCPT TO:<andrea@piffa.net>
1942 <** 450 4.2.0 <andrea@piffa.net>: Recipient address rejected:
1943 Greylisted, see http://postgrey.schweikert.ch/help/piffa.net.html
1946 === Connection closed with remote host.
1948 A lato server si dovrebbe rilevare su ``/var/log/syslog`` qualcosa di simile::
1950 connect from alice.mydomain.com[65.98.21.97]
1951 May 28 14:53:34 r24266 postgrey: action=greylist, reason=new,
1952 client_name=alice.mydomain.com,
1953 client_address=10.0.0.1, sender=root@alice.mydomain.com, recipient=andrea@piffa.net
1954 May 28 14:53:34 r24266 postfix/smtpd[22538]:
1955 NOQUEUE: reject: RCPT from alice.mydomain.com[10.0.0.1]:
1956 450 4.2.0 <andrea@piffa.net>: Recipient address rejected: Greylisted,
1957 see http://postgrey.schweikert.ch/help/piffa.net.html;
1958 from=<root@alice.mydomain.com> to=<andrea@piffa.net>
1959 proto=ESMTP helo=<alice.mydomain.com>
1960 May 28 14:53:34 r24266 postfix/smtpd[22538]: disconnect from alice.mydomain.com[10.0.0.1]
1966 E' sempre utile poter tracciare qualche statistica sulle percentuali di messaggi ricevuti, da chi, messaggi rifiutati (e per quale motivo). Statistiche che attingono dai soliti log del server di posta ``/var/log/syslog`` di default oltre che i dedicati ``/var/log/mail`` .
1968 Una utility semplice per analizzare l'attivita' del propio server smtp potrebbe essere ``pflogsumm`` , installato il pacchetto la si puo' invocare con::
1970 pflogsumm.pl /var/log/mail.log
1972 oppure utilizzare i log piu' vecchi ad es. ``/var/log/mail.log.0``
1977 In Informatica, nell'ambito delle reti di computer, un firewall (termine inglese dal significato originario di parete refrattaria, muro tagliafuoco, muro ignifugo; in italiano anche parafuoco o parafiamma) e' un componente passivo di difesa perimetrale che puo anche svolgere funzioni di collegamento tra due o piu' tronconi di rete. Usualmente la rete viene divisa in due sotto reti: una, detta esterna, comprende l'intera Internet mentre l'altra interna, detta LAN (Local Area Network), comprende una sezione piu' o meno grande di un insieme di computer locali. In alcuni casi e' possibile che si crei l'esigenza di creare una terza sotto rete detta DMZ (o zona demilitarizzata) atta a contenere quei sistemi che devono essere isolati dalla rete interna ma devono comunque essere protetti dal firewall.
1979 Una prima definizione chiusa di firewall e' la seguente:
1981 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.
1983 In realta' un firewall puo' essere realizzato con un normale computer (con almeno due schede di rete e software apposito), puo' essere una funzione inclusa in un router o puo' essere un apparato specializzato. Esistono inoltre i cosiddetti "firewall personali", che sono programmi installati sui normali calcolatori, che filtrano solamente i pacchetti che entrano ed escono da quel calcolatore; in tal caso viene utilizzata una sola scheda di rete.
1985 La funzionalita' principale in sostanza e' quella di creare un filtro sulle connessioni entranti ed uscenti, in questo modo il dispositivo innalza il livello di sicurezza della rete e permette sia agli utenti interni che a quelli esterni di operare nel massimo della sicurezza. Il firewall agisce sui pacchetti in transito da e per la zona interna potendo eseguire su di essi operazioni di:
1990 Questo grazie alla sua capacita' di "aprire" il pacchetto IP per leggere le informazioni presenti sul suo header, e in alcuni casi anche di effettuare verifiche sul contenuto del pacchetto.
1995 * http://openskill.info/topic.php?ID=124
1996 * http://iptables-tutorial.frozentux.net/iptables-tutorial.html
2001 Link: http://iptables-tutorial.frozentux.net/iptables-tutorial.html#IPFILTERING
2003 Natura di un firewall ip: su cosa lavora (livello 2 e un po' del 3) e su cosa *non* lavora (livello 4).
2004 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.
2006 Netfilter non ricostruisce il flusso di dati tra pacchetti, non puo' quindi rilevare la presenza di virus o simili che si trasmettono su pacchetti separati: ricomporre, analizzare e tornare a scomporre i frammenti richiederebbe troppa RAM e risorse di sistema, con il conseguente rischio di saturare il firewall fino all'abbandono dei nuovi pacchetti in transito.
2007 Ci sono altri software piu' adatti a questi compiti, ad esempio un proxy HTTP come Squid che e' appunto una applicazione di quarto livello, progettata e strutturata per analizzare e modificare i flussi di dati (il *contenuto* dei pacchetti, non le sole *intestazioni*) facendo abbondate uso delle risorse RAM e di calcolo del sistema. Non a caso su macchine embedded dalle prestazioni molto ridotte (CPU ARM ~250MHZ con ~30MB di RAM) Squid sfrutta al massimo le risorse di sistema per gestire il traffico di una rete 10/100, mentre il lavoro tipico svolto da netfilter e' quasi irrilevante.
2009 Progettazione di un firewall
2010 -----------------------------
2012 Per implementare un firewall bisogna decidere un aio di cose: la collocazione e l'approccio (inclusivo o esclusivo) al filtraggio, il tipo di hardware.
2017 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.
2022 2. tra router e servers / LAN
2023 3. Unico server / router / firewall e connessi rischi. considerare l'acquisto di un router hardware dedicato.
2026 Implementare piu' device / software sui diversi livelli: http://iptables-tutorial.frozentux.net/iptables-tutorial.html#HOWTOPLANANIPFILTER
2032 Drop o Accept: conseguenze per sicurezza, facilita' di gestione.
2038 Sostanzialmente potremmo distinguere due tipologie di hardware:
2040 Network appliance dedicata::
2041 Un dispositivo hardware dedicato alla funzione di Firewall, ad es un Cisco / Fortigate.
2042 Si noti che molti firewall economici altro non sono che Linux box molto striminzite.
2044 Server / Personal computer:
2045 Un server sul quale viene fatto girare Netfilter ad uso del server stesso e della rete connessa.
2047 Vantaggi e svantaggi: consumo elettrico, efficienza, flessibilita', strumenti di gestione, sicurezza, OpenBSD.
2049 Percorso dei pacchetti tra tabelle e catene
2050 -------------------------------------------
2052 link: http://iptables-tutorial.frozentux.net/iptables-tutorial.html#TRAVERSINGOFTABLES
2058 Tabelle, catene, regole
2059 ~~~~~~~~~~~~~~~~~~~~~~~~~
2061 Iptables lavora su 3 tabelle (tables) di default:
2063 * filter - Regola il firewalling: quali pacchetti accettare, quali bloccare
2065 * nat - Regola le attivita' di natting
2067 * mangle - Interviene sulla alterazione dei pacchetti.
2069 Ogni tabella ha delle catene (chains) predefinite (INPUT, OUTPUT, FORWARD ... ) a cui possono essere aggiunte catene custom.
2070 Ogni catena e' composta da un elenco di regole (rules) che identificano pacchetti di rete secondo criteri diversi (es: -p tcp --dport 80 -d 10.0.0.45)
2071 Ogni regola termina con una indicazione (target) su cosa fare dei pacchetti identificati dalla regola stessa (es: -j ACCEPT, -j DROP ...)
2076 I Match di una regola (rule) servono a testare un pacchetto per valutare se corrisponda a certe caratteristiche. I match di possono servire a controllare se un pacchetto e' destinato a una porta particolare o utilizza un protocollo particolare.
2081 Protocollo IP. Secondo IP number o nome (es: tcp, udp, gre, ah...)
2083 -s [!] address[/mask]
2084 Indirizzo IP sorgente (o network con maschera di sotto rete)
2086 -d [!] address[/mask]
2087 Indirizzo IP destinazione (o network)
2090 Interfaccia di rete di entrata ([+] wildcard)
2093 Interfaccia di rete di uscita ([+] wildcard)
2096 Frammento di pacchetto
2101 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.
2106 Il pacchetto matchato viene accettato e procede verso la sua destinazione. Si usa per definire il traffico permesso.
2109 Il pacchetto viene rifiutato e scartato, senza alcuna notifica al mittente. Si usa, in alternativa a REJECT, per bloccare traffico.
2112 Il pacchetto viene rifiutato. Al mittente viene mandato un pacchetto (configurabile) di notifica tipo ICMP port-unreachable (--reject-with icmp-port-unreachable)
2115 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)
2118 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
2121 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.
2124 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.
2127 Redirige il pacchetto ad una porta locale. Usabile solo in nat / PREROUTING e nat / OUTPUT e' previsto per fare un transparent proxy (con proxy server in esecuzione sulla macchina con iptables)
2130 Interrompe l'attraversamento della catena. Se questa e' una secondaria, il pacchetto torna ad attraversare la catena madre da punto in cui aveva fatto il salto nella secondaria. Se il RETURN e' in una delle catene di default, il pacchetto interrompe l'attraversamento e segue la policy di default.
2133 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
2136 Curioso e sperimentale, questo target invia un pacchetto speculare al mittente. In pratica e' come se facesse da specchio per tutti i pacchetti ricevuti. Da usare con cautela, per evitare attacchi DOS indiretti.
2142 E' quella implicita e predefinita (-t filter)
2143 Riguarda le attivita' di filtraggio del traffico.
2144 Ha 3 catene di default:
2145 INPUT - Riguarda tutti i pacchetti destinati al sistema. In entrata da ogni interfaccia.
2146 OUTPUT - Riguarda i pacchetti che sono originati dal sistema e destinati ad uscire.
2147 FORWARD - Riguarda i pacchetti che attraversano il sistema, con IP sorgente e destinazione esterni.
2149 Esempio per permettere accesso alla porta 80 locale:
2150 iptables -t filter -I INPUT -p tcp --dport 80 -j ACCEPT
2151 Analoga a: iptables -I INPUT -p tcp --dport 80 -j ACCEPT
2153 Esempio per permettere ad un pacchetto con IP sorgente 10.0.0.4 di raggiungere il server 192.168.0.1 attraversando il firewall:
2154 iptables -I FORWARD -s 10.0.0.4 -d 192.168.0.1 -j ACCEPT
2156 Flush automatico per macchine remote
2157 ---------------------------------------
2159 Se state provando una configurazione del firewall per una macchina remota e' buona norma per evitare brutte figure attivare uno script che faccia il *flush* delle regole dopo qualche minuto. Potreste infatti inavvertitamente impostare una regola che vi impedisca di raggiungere la macchina remota, cosi' da non poter neanche eliminare quella regola e ripristinare la situazione precedente.
2161 *Veramente*, prima di lavorare sul firewall di una macchina remota impostate almeno un ``at now +5 min`` o con un'oretta di margine per fare il *flush* delle regole (su tutte le tabelle)::
2164 at> /sbin/iptables -F
2169 Gestione regole (rules)
2170 --------------------------
2172 Il comando iptables viene usato per ogni attivita' di gestione e configurazione.
2176 iptables -A CATENA ...
2177 Aggiunge una regola alla fine della catena indicata
2179 iptables -I CATENA [#] ...
2180 Inserisce alla riga # (default 1) una regola nella catena indicata
2183 Crea una nuova catena custom
2185 iptables -P CATENA TARGET
2186 Imposta il target di default per la catena indicata
2188 Rimozione regole e azzeramenti:
2190 iptables -F [catena]
2191 Ripulisce tutte le catene (o quella indicata)
2193 iptables -X [catena]
2194 Ripulisce tutte le catene custom (o quella indicata)
2196 iptables -Z [catena]
2197 Azzera i contatori sulle catene
2199 iptables -D catena #
2200 Cancella la regola numero # dalla catena indicata
2205 Elenca le regole esistenti
2208 Elenca, senza risolvere gli host, in modo verboso le regole esistenti
2214 ----------------------
2216 Il comando ``iptables`` serve per interagire con il framework ``Netfilter`` che gestisce il firewall di Linux al livello del kernel. Questo comporta, in modo analogo a quando avviene col comando ``ifconfig``, che i cambiamenti impostati siano in *tempo reale, RAM*, non persistenti nel sistema: al boot successivo del sistema tutto tornera' alle impostazioni di base (in questo caso *nulle*, con policy di default settate su ``ACCEPT`` per tutto).
2218 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.
2220 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``.
2222 Nel nostro caso avremo per una possibile scheda ``eth0``:
2224 ``/etc/network/interfaces`` ::
2226 iface eth1 inet static
2227 up /sbin/iptables-restore /root/firewall/basic_fw
2228 # Seguono i soliti parametri della scheda di rete
2229 address 10.10.208.21
2235 Per salvare le regole di iptables attualmente presenti nel kernel si usi il comando::
2237 # iptables-save >> /root/firewall/basic_fw
2239 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.
2242 Se non avete un'idea migliore potreste voler tenere gli script dei firewall in una cartella ``~/firewall`` nella home directory dell'utente ``root``.
2245 ~~~~~~~~~~~~~~~~~~~~
2247 Per ripristinare un set di regole precedentemente salvate con ``iptables-save`` si utilizzi ``iptables-restore``. Se questo deve essere fatto in modalita' *non interattiva*, ad esempio deve essere eseguito dal demone che si occupa di inizializzare le schede di rete, oppure un *cron* o altro, e' buona norma richiamare i percorsi completi sia dei comandi che dei file::
2249 /sbin/iptables-restore /root/firewall/basic_fw
2255 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.
2257 1. ``eth0`` scheda di rete principale sulla rete privata interna 192.168.0.0/24
2259 2. ``eth1`` scheda di rete secondaria per la connessione ad internet
2261 3. ``ppp0`` punto-a-punto per una connessione ad internet
2263 Bloccare i ping dall'esterno
2264 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2266 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::
2268 iptables -A INPUT -i ppp0 -p ICMP -j DROP
2271 ~~~~~~~~~~~~~~~~~~~~
2273 Per attivare la network address translation (in questo caso un SNAT) per la rete locale privata sull'indirizzo ip del *modem*::
2274 iptables -A POSTROUTING -s 192.168.0.0/255.255.255.0 -o ppp0 -j MASQUERADE
2276 Il *Masquerading* a differenza dello *SNAT* puro (``-j SNAT --to-source proprio_ip_pubblico ) legge l'indirizzo ip del device ``ppp0``. In questo modo se l'IP cambia automaticamente si aggiorna anche il source natting. Se avete un indirizzo IP statico assegnato al vostro gateway potete invece usare lo SNAT semplice.
2279 ## Change source addresses to 1.2.3.4.
2280 # iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to 1.2.3.4
2282 ## Change source addresses to 1.2.3.4, 1.2.3.5 or 1.2.3.6
2283 # iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to 1.2.3.4-1.2.3.6
2285 ## Change source addresses to 1.2.3.4, ports 1-1023
2286 # iptables -t nat -A POSTROUTING -p tcp -o eth0 -j SNAT --to 1.2.3.4:1-1023
2291 Per limitare attacchi di tipo brute force su SSH::
2293 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
2295 iptables -A INPUT -i ppp0 -p tcp -m tcp --dport 22 -m state --state NEW -m recent --set --name DEFAULT --rsource
2301 Il File Transfer Protocol (FTP) (protocollo di trasferimento file), รจ un Protocollo per la trasmissione di dati tra host basato su TCP, in genere usato dagli autori di pagine web per *pubblicare* queste nei propio spazi web. Storicamente veniva anche usato, mediate l'utilizzo di utenze anonime, come punto di scambio per materiali di vari utenti tra loro sconosciuti (una directory dei materiali scaricabili e una dedicata agli *uploads* degli utenti, poi riordinati dall'*ftpmaster*). Tuttora si mantiene la cosuetudine di renedere disponibile i materiali dei *mirrors* anche tramite FTP, probabilmente per garantire l'accesso ai client piu' datati che non possono utilizzare tecnologie piu' recenti.
2304 Il protocollo FTP e' in chiaro (cioe' non criptato), sia per quanto riguarda il traffico ad esso associato che per il passaggio delle passwords degli utenti, facilmente sniffabili da chiunque abbia accesso alla rete. Naturalmente vsftp per quanto votato alla sicurezza non modifica queste caratteristiche del protocollo FTP (ma consente di usare OpenSSL per la autenticazione degli utenti).
2306 Se propio si deve mettere a disposizione un server FTP ai propi utenti si considerino le seguenti alternative:
2308 - Spingere gli utenti ad usare SFTP invece che FTP
2309 - Spingere gli utenti ad usare SSL per autenticarsi al server FTP
2310 - Nel caso di webdesigners si consideri la possibilita' di offrire alternative come GIT, Subversion, Rsync o Webdav
2312 Nel caso non si possa evitare il server FTP:
2314 - Non dare agli utenti FTP una shell di sistema ( Concedere come shell ``ftp`` al posto di ``bash`` in ``/etc/passwd``)
2315 - Rendere il filesytem su cui scrive il demone FTP ``noexec`` e ``nosuid`` (vedi dopo)
2316 - Utilizzare un demone FTP come Vsftp: un server FTP con una forte inclinazione alla sicurezza: *Very Secure FTP Daemon*.
2318 Per maggiori informazioni sulle scelte di design legate alla sicurezza del demone si veda: http://vsftpd.beasts.org/DESIGN
2320 Vsftp mette a disposizione le seguenti funzionalita':
2322 - Virtual IP configurations
2324 - Standalone or inetd operation
2325 - Powerful per-user configurability
2326 - Bandwidth throttling
2327 - Per-source-IP configurability
2328 - Per-source-IP limits
2330 - Encryption support through SSL integration
2336 Per installare il demone vero e propio si usi il pacchetto ``vsftpd`` , mentre per aver un client da cui fare qualche test sono dipsonibili:
2338 - ``ftp`` (pacchetto da installare) e' il solito client a riga di comando
2339 - ``gftp`` e' un client grafico simile al classico *WSftp*
2340 - Normalmente i file mananager com Konqueror possono lavarorare come client FTP
2346 Vediamo alcuni dei comandi di base per gestire una sessione ftp a riga di comando:
2349 stabilire la connessione all'host, poi verra' chiesta la password dell'utente. Se avete sbagliato utente: user .
2352 Lista dei comandi disponibili.
2354 Cosa fa quel comando.
2356 Per caricare un file.
2358 Per scaricare un file.
2360 Lista dei file disponibili.
2362 Spostarsi in un altra directory.
2364 Cambio directory in LOCALE.
2366 Per lavorare su file multipli.
2368 Per uscire dalla modalita' interattiva
2369 (non vi chiede conferma di ogni singola operazione
2370 su ogni singolo file...).
2372 Entra in modalita' trasferimento binario.
2374 Entra in modalita' trasferimento ascii.
2376 Per chiudere la sessione.
2379 Configurazione iniziale
2380 ------------------------
2382 Il demone di vsftpd e' immediatamente disponibile ma solo in modalita' anonima (si pensi a uno scenario in cui si vuole rendere disponibili dei files tramite FTP) e in *sola lettura*. Per accedere al servizio si usi quini come utente ``anonymous`` (la passwords in genere e' come consuetudine il propio indirizzo email), la cui *home* directory sara' ``/home/ftp/`` (``/srv/ftp`` in Squeeze)::
2384 zoo:~# ftp localhost
2385 Connected to localhost.localdomain.
2387 Name (localhost:root): anonymous
2388 331 Please specify the password.
2390 230 Login successful.
2391 Remote system type is UNIX.
2392 Using binary mode to transfer files.
2394 200 PORT command successful. Consider using PASV.
2395 150 Here comes the directory listing.
2396 -rw-r--r-- 1 0 0 0 Feb 03 17:17 anoni
2397 226 Directory send OK.
2401 Abilitare gli utenti locali
2402 ----------------------------
2405 Per poter modificare le impostazioni iniziali, ad esempio per permettere l'accesso agli utenti del server, si modifichera' il file ``/etc/vsftpd.conf``, a seguire le impostazioni fondamentali ed altre interessanti per rendere il server accessibile da utenti di sistema (autenticati tramite la loro password, quindi con PAM) per il tipico utilizzo di web designers che debbano pubblicare le loro pagine web (e non si siano fatti convincere a usare SFTP!)::
2408 # Allow anonymous FTP? (Beware - allowed by default if you comment this out).
2410 # Disabilitiamo l'utente anonimo
2412 # Uncomment this to allow local users to log in.
2414 # Accesso garantito agli utenti di sistema
2416 # Uncomment this to enable any form of FTP write command.
2418 # Permettiamo agli utenti di caricare documenti nella loro home
2420 # You may fully customise the login banner string:
2421 ftpd_banner=Benvenuti al servizio ftp del sito example.com
2424 Per abilitare i cambiamenti si proceda a riavviare il server: ``/etc/init.d/vsftpd restart`` e si monitorizzi il file di log ``tail -f /var/log/vsftpd.log`` per controllarne il funzionamento (e anche ``/var/log/syslog`` nel caso non si riuscisse a far partire correttamente il servizio.
2426 NOTE: Se non riuscite ad ottenere un *directory listing* (``ls``) ottenendo un errore ``500 Illegal PORT command? FTP error`` abilitare la modalita' passiva col comando ftp ``passive``.
2432 Si puo' impedire all'utente di spostarsi arbitrariamente per il file system del servere visualizzare il contenuto delle directory, ad esempio la cartella ``/etc``, confinandolo in una jail chroot limitata alla sua home directory::
2434 # You may restrict local users to their home directories. See the FAQ for
2435 # the possible risks in this before using chroot_local_user or
2436 # chroot_list_enable below.
2437 chroot_local_user=YES
2440 Generalmente un utente di sistema con il solo accesso FTP non dovrebbe avere la possibilita' di poter navigare liberamente per il file system del server, esponendo file di configurazione e quant'altro l'utente potrebbe trarre utili informazioni sul quali software siano installati e di che tipo::
2443 Remote system type is UNIX.
2444 Using binary mode to transfer files.
2448 550 Failed to change directory.
2451 Permessi sul filesystem
2452 -------------------------
2454 Come accennato precedentemente e' opportuno che i filesystems sui quali un utente puo' scrivere o modificare il contenuto non abbiano i privilegi di eseguibilita' e suid, nel nonstro caso vsftpd lavora sull'intera ``/home/`` directory quindi avremo in ``/etc/fstab``::
2456 /dev/mapper/store-homes /home ext3 rw,nosuid,noexec 0 2
2460 ----------------------
2462 Come gia' detto piu' volte le passwords degli utenti viaaggiano in rete in chiaro, ponendo un grave problema di sicurezza. Sara' quindi opportuno disbilitare la shell di questi utenti, tramite il flag ``--shell /bin/false`` in fase di creazione degli utenti::
2464 # adduser --shell /bin/false nome_utente
2467 Oppure correggiendo manualmente il file ``/etc/passwd`` per modificare l'inpostazione della shell dell'utente::
2469 nome_utente:x:1001:1001::/var/spool/postfix:/bin/bash
2470 # la riga sopra deve essere trasformata in
2471 nome_utente:x:1001:1001::/var/spool/postfix:/bin/false
2474 Sui sistemi DEbian REcenti sara' necessario aggiungere ``/bin/false`` all'elenco delle shell valide.
2486 Verra' tenuto un file di log ``/var/log/vsftpd.log`` degli upload e download sul server.
2489 Nasconde le userid e groupid mascherandole con ``ftp`` .
2492 Home directory dell'utente anonimo.
2495 Permette agli utenti di eseguire i comandi che possono modificare il filesystem: STOR, DELE, RNFR, RNTO, MKD, RMD, APPE e SITE .
2497 idle_session_timeout=600
2498 Permette agli utenti di restare connessi piu' a lungo, utile per i webdesigners che passano intere giornate connessi al server.
projects / doc / .git / blob