5. Informazioni generali sulla configurazione di rete.

È piuttosto importante conoscere e capire le seguenti sottosezioni prima di provare a configurare in pratica la propria rete. Questi sono principi fondamentali che si applicano indipendentemente dall'esatta natura della rete che si intende costruire.

5.1 Da dove devo partire?

Prima di iniziare a costruire o configurare la propria rete occorrono alcune cose. Le più importanti di queste sono:

Sorgenti aggiornati del kernel.

Siccome il kernel che si sta usando al momento potrebbe non avere ancora il supporto per i tipi di rete o di schede di interfaccia che si desidera usare, probabilmente occorrono i sorgenti del kernel, in modo da essere in grado di ricompilare il kernel con le opzioni appropriate.

I sorgenti più recenti si possono sempre ottenere da ftp.kernel.org.

Meglio ricordarsi che ftp.kernel.org viene seriamente sovraccaricato: un modo preferibile di ottenere i sorgenti aggiornati è scaricare le patch invece degli interi file sorgente in tar; meglio ancora cercare di utilizzare mirror del sito ftp principale, come ftp.funet.fi; ricordarsi inoltre che ogni sito Linux di solito fornisce sorgenti del kernel aggiornati.

Normalmente i sorgenti del kernel saranno scompattati da tar nella directory /usr/src/linux. Per informazioni riguardo a come si applicano le modifiche (patch) e come si ricompila il kernel si legga Kernel-HOWTO. Per informazioni su come si configurano i moduli del kernel si legga "Modules mini-HOWTO". Inoltre il file README che si trova nei sorgenti del kernel e la directory Documentation sono molto istruttivi per il lettore motivato.

A meno di trovare indicazioni differenti, io consiglio di utilizzare la distribuzione stabile del kernel (quella con un numero pari come seconda cifra nel numero di versione). Le distribuzioni dei kernel di sviluppo (quelle con la seconda cifra dispari) possono presentare differenze strutturali o altri cambiamenti che possono causare problemi quando usati con altro software di sistema. Se non si è sicuri di essere in grado di risolvere questo tipo di problemi, anche considerando il rischio che ci siano altri errori nel software, allora è bene non usare le versioni dispari.

D'altra parte, alcune delle funzionalità ivi descritte sono state introdotte nel corso dello sviluppo dei kernel 2.1, per cui è necessario fare una scelta: si può rimanere al 2.0, aspettando che esca il 2.2 e qualche distribuzione aggiornata e completa di ogni programma di supporto, o passare ai 2.1 ed aggiungere in proprio i vari programmi di supporto necessari per utilizzare al meglio le nuove funzionalità. Al momento della stesura di questo paragrafo, nell'Agosto 1998, è già stato rilasciato il 2.1.115 e si pensa che non manchi molto al rilascio del 2.2 [al momento della traduzione sono già uscite alcune distribuzioni con i nuovi kernel 2.2, tra le quali Debian 2.1 N.d.T.].

Gli strumenti di rete aggiornati

Gli strumenti di rete (i "network tools") sono i programmi che si usano per configurare le periferiche di rete di Linux. Questi programmi permettono per esempio di assegnare gli indirizzi alle periferiche e configurare l'instradamento.

La maggior parte delle moderne distribuzioni di Linux contengono già gli strumenti di rete, se perciò si è installato il proprio sistema da una distribuzione senza aver ancora installato gli strumenti di rete, occorre farlo.

Se il proprio sistema non è stato installato da una distribuzione, occorre recuperare i sorgenti e compilare i programmi da se. Questo non è difficile.

Gli strumenti di rete sono attualmente distribuiti da Bernd Eckenfels e sono disponibili presso: ftp.inka.de, sito che è presente in mirror anche su ftp.uk.linux.org.

Occorre essere sicuri di scegliere la versione più appropriata per il kernel che si intende usare e di seguire le istruzioni di installazione che si trovano nel pacchetto.

Per installare e configurare la versione corrente al momento della stesura di questo documento occorre invocare i seguenti comandi:

        user% tar xvfz net-tools-1.33.tar.gz
        user% cd net-tools-1.33
        user% make config
        user% make
        root# make install
        

Inoltre, se si intende configurare un firewall o utilizzare la possibilità di mascheramento dei pacchetti ("IP masquerading") occorre il comando ipfwadm, la cui versione aggiornata si può recuperare da: ftp.xos.nl. Ancora una volta, esistono diverse versioni del programma, e bisogna prendere la versione che meglio si adatta al proprio kernel. Da notare che le funzionalità di firewall di Linux sono cambiate durante lo sviluppo dei 2.1. Quanto si dice si applica solo alle versioni 2.0 del kernel.

Per installare e configurare la versione cui ho accesso in questo momento occorre invocare:

        user% tar xvfz ipfwadm-2.3.0.tar.gz
        user% cd ipfwadm-2.3.0
        user% make
        root# make install
        

Notare che se si utilizza una versione 2.2 (o uno degli ultimi 2.1) del kernel, ipfwadm non è lo strumento giusto per configurare il Firewall IP. Questa versione del NET-3-HOWTO attualmente non si occupa della nuova configurazione del firewall.

Programmi Applicativi di Rete.

Gli applicativi di rete sono i programmi come telnet e ftp, unitamente ai programmi server associati. David Holland <dholland@cs.harvard.edu> coordina la distribuzione dei più comuni di questi. Tale distribuzione si può ottenere ftp.uk.linux.org.

Nel Marzo 1997 il pacchetto è stato suddiviso in pacchetti distinti più piccoli, ma nel Maggio 1997 i programmi fondamentali sono stati incorporati in un pacchetto chiamato netkit-base-0.10. Potrebbe essere necessario procurarsi il pacchetto di base e/o pacchetti addizionali.

Per installare e configurare la versione corrente al momento della stesura di questo documento occorre invocare i seguenti comandi:

        user% tar xvfz netkit-base-0.10
        user% cd netkit-base-0.10
        user% more README
        user% vi MCONFIG
        user% make
        root# make install
        

Indirizzi.

Gli indirizzi IP sono composti da 4 byte. La convenzione usata per scrivere gli indirizzi è chiamata `dotted decimal notation', che significa "notazione decimale con i punti". In questa forma ogni byte è convertito in un numero decimale (tra 0 e 255) scartando gli zeri prefissi a meno che il numero sia zero, ogni byte è poi separato da un carattere `.'. Per convenzione ogni interfaccia di un calcolatore o router ha associato un indirizzo IP. In certe circostanze è permesso assegnare lo stesso indirizzo a tutte le interfacce di un singolo calcolatore, ma solitamente ogni interfaccia avrà un indirizzo diverso.

Le reti IP sono sequenze di indirizzi IP contigui. Tutti gli indirizzi all'interno di una rete hanno un certo numero di cifre del loro indirizzo in comune. La porzione di indirizzo comune all'interno della rete si chiama "network portion" (porzione di rete) dell'indirizzo. Le cifre rimanenti si chiamano "host portion". Il numero di bit che vengono condivisi tra tutti gli indirizzi all'interno della rete è chiamato "netmask" ed il suo ruolo è determinare quali indirizzi appartengono alla rete cui la maschera è applicata e quali no. Consideriamo il seguente esempio:

        -----------------  ---------------
        Host Address       192.168.110.23
        Network Mask       255.255.255.0
        Network Portion    192.168.110.
        Host portion                  .23
        -----------------  ---------------
        Network Address    192.168.110.0
        Broadcast Address  192.168.110.255
        -----------------  ---------------
        

Ogni indirizzo sottoposto ad un'operazione di "AND bit-a-bit" con la sua maschera di rete darà l'indirizzo della rete cui appartiene. La maschera di rete è perciò sempre il numero più basso all'interno dell'intervallo di indirizzi che formano quella rete, e ha sempre la parte di host dell'indirizzo pari a zero.

L'indirizzo di broadcast è un indirizzo speciale cui tutti gli host della rete ascoltano, in aggiunta al loro proprio indirizzo. Questo indirizzo è quello cui vengono mandati i pacchetti che devono essere ricevuti da tutti i calcolatori della rete. Certi tipi di dati, come le informazioni di instradamento e i messaggi di errore vengono trasmessi all'indirizzo di broadcast in modo che tutti i calcolatori sulla rete li possano ricevere contemporaneamente. Ci sono due standard comunemente usati su come debba essere un indirizzo di broadcast. Il più comunemente accettato stabilisce che debba essere usato come indirizzo di broadcast l'indirizzo più alto possibile della rete. Nell'esempio precedente questo sarebbe 192.168.110.255. Per qualche ragione alcuni siti hanno adottato la convenzione di usare l'indirizzo zero come indirizzo di broadcast. In pratica non fa molta differenza quale viene usato, ma bisogna assicurarsi che ogni host sulla rete sia configurato con lo stesso indirizzo di broadcast.

Per ragioni amministrative, ad un certo punto durante lo sviluppo iniziale del protocollo IP sono stati formati alcuni gruppi di arbitrari di indirizzi e le reti sono state raggruppate in quelle che sono chiamate classi. Le classi caratterizzano le dimensioni delle reti che si possono allocare. Queste classi offrono un numero di dimensioni fisse di rete che possono essere allocate. Gli intervalli scelti per le varie classi sono:

        ----------------------------------------------------------
        | Network | Netmask       | Network Addresses            |
        | Class   |               |                              |
        ----------------------------------------------------------
        |    A    | 255.0.0.0     | 0.0.0.0    - 127.255.255.255 |
        |    B    | 255.255.0.0   | 128.0.0.0  - 191.255.255.255 |
        |    C    | 255.255.255.0 | 192.0.0.0  - 223.255.255.255 |
        |Multicast| 240.0.0.0     | 224.0.0.0  - 239.255.255.255 |
        ----------------------------------------------------------
        

La scelta di quali indirizzi usare per la propria rete dipende da cosa esattamente si sta facendo. Per ottenere gli indirizzi di cui si ha bisogno si può procedere in uno dei seguenti modi:

Installare una macchina Linux su una rete IP esistente

Se si desidera installare un calcolatore su una rete esistente si deve contattare chi amministra tale rete e chiedere loro le seguenti informazioni:

• L'indirizzo IP da assegnare al calcolatore
• L'indirizzo IP di rete
• L'indirizzo IP di broadcast
• La netmask
• L'indirizzo del router
• L'indirizzo del "name server".

Dopo di che bisogna configurare l'interfaccia di rete Linux in base a quei numeri. Non è possibile inventare dei numeri e sperare che la configurazione funzioni.

Costruire una rete nuova che non si connetterà mai a Internet

Se si sta preparando una rete privata e non si ha intenzione nemmeno in futuro di connettere tale rete ad Internet, allora si può scegliere qualunque indirizzo. Ciononostante, per ragioni di sicurezza e di coerenza ci sono alcuni indirizzi di reti IP che sono stati riservati specificamente a questo fine. Essi sono specificati nell'RFC1597 come segue:

        -----------------------------------------------------------
        |         RESERVED PRIVATE NETWORK ALLOCATIONS            |
        -----------------------------------------------------------
        | Network | Netmask       | Network Addresses             |
        | Class   |               |                               |
        -----------------------------------------------------------
        |    A    | 255.0.0.0     | 10.0.0.0    - 10.255.255.255  |
        |    B    | 255.255.0.0   | 172.16.0.0  - 172.31.255.255  |
        |    C    | 255.255.255.0 | 192.168.0.0 - 192.168.255.255 |
        -----------------------------------------------------------
        

Occorre innanzitutto decidere quanto grande deve essere la nuova rete, e poi scegliere gli indirizzi di cui si ha bisogno.

5.2 Dove bisogna mettere i comandi di configurazione?

Ci sono differenti approcci sotto Linux per le procedure di inizializzazione del sistema. Dopo che il kernel è partito, viene sempre eseguito un programma chiamato `init'. Il programma init poi legge il suo file di configurazione chiamato /etc/inittab ed inizia il processo di boot. Esistono versioni di init leggermente differenti, quantunque si stia convergendo verso lo stile System V (Five), sviluppato da Miguel van Smoorenburg.

Malgrado il fatto che il programma init sia sempre lo stesso, la configurazione di boot del sistema è organizzata in modi diversi nelle varie distribuzioni.

Solitamente il file /etc/inittab contiene una voce che assomiglia a:

        si::sysinit:/etc/init.d/boot
        

Questa riga specifica il nome dello script di shell che gestisce praticamente la sequenza di boot. Questo file è in qualche modo simile al file AUTOEXEC.BAT in DOS.

Di solito ci sono altri script che vengono chiamati dallo script di inizializzazione, e spesso la rete è configurata all'interno di uno di questi.

La seguente tabella può essere usata come guida per il proprio sistema:

--------------------------------------------------------------------
Distrib. | Interface Config/Routing          | Server Initialization
--------------------------------------------------------------------
Debian   | /etc/init.d/network               | /etc/rc2.d/*
--------------------------------------------------------------------
Slackware| /etc/rc.d/rc.inet1                | /etc/rc.d/rc.inet2 
--------------------------------------------------------------------
RedHat   | /etc/rc.d/init.d/network          | /etc/rc.d/rc3.d/*
--------------------------------------------------------------------

Si noti che Debian e Red Hat usano un'intera directory per ospitare gli script che attivano i servizi di sistema. Gli script di solito non contengono al loro interno le informazioni di configurazione necessarie. Ad esempio nei sistemi RedHat gli script di inizializzazione (boot script) si aspettano di trovarle nei file presenti in /etc/sysconfig. Se si vogliono comprendere i dettagli del processo di boot, suggerisco di dare un occhiata a /etc/inittab e alla documentazione associata a init. Linux Journal sta per pubblicare un articolo sulla inizializzazione del sistema, e a questo documento verrà aggiunto un puntatore ad esso non appena sarà disponibile sul web.

La maggior parte delle distribuzioni moderne includono un programma che permette di configurare la maggior parte dei tipi diffusi di interfacce di rete. Se si ha una di queste, allora bisognerebbe controllare se tale programma fa quello di cui si ha bisogno prima di tentare una configurazione manuale.

        -----------------------------------------
        Distrib   | Network configuration program
        -----------------------------------------
        RedHat    | /usr/bin/netcfg
        Slackware | /sbin/netconfig
        -----------------------------------------
        

5.3 Creazione delle interfacce di rete.

In molti sistemi Unix le periferiche di rete hanno il loro posto nella directory /dev. Questo non succede in Linux, dove i dispositivi di rete sono creati dinamicamente via software e quindi non hanno bisogno della presenza di file speciali.

Nella maggior parte dei casi i dispositivi di rete sono creati automaticamente dal driver durante la sua inizializzazione dopo che l'hardware è stato riconosciuto. Per esempio, il driver per la rete ethernet crea le interfacce eth[0..n] sequenzialmente, nell'ordine in cui le schede ethernet vengono riconosciute. La prima scheda che viene trovata prende il nome eth0, la seconda eth1, eccetera.

Ciononostante in alcuni casi, come succede per slip e ppp, i dispositivi di rete vengono creati a seguito di operazioni svolte da un programma. Si applica la stessa regola di numerazione sequenziale, ma le periferiche non sono create automaticamente all'accensione del sistema. La ragione di questo è che, a differenza di quello che accade per le schede ethernet, il numero di periferiche slip o ppp può cambiare durante la vita della macchina. Questi casi vengono analizzati in maggior dettaglio nelle sezioni successive.

5.4 Configurazione delle interfacce di rete.

Dopo aver recuperato tutti i programmi di cui si ha bisogno e tutti gli indirizzi e le informazioni sulla rete, si può procedere alla configurazione delle proprie interfacce di rete. Quando si parla di configurazione dell'interfaccia si intende il processo di assegnazione degli indirizzi appropriati alla periferica e all'assegnazione di valori appropriati per gli altri valori configurabili di un dispositivo di rete. Il programma più comunemente usato per questo compito è il comando ifconfig (interface configure).

Normalmente viene invocato un comando simile al seguente:

        root# ifconfig eth0 192.168.0.1 netmask 255.255.255.0 up
        

In questo esempio si è configurata una scheda ethernet `eth0' con l'indirizzo IP `192.168.0.1' e una maschera pari a `255.255.255.0'. La parola `up' finale significa che l'interfaccia deve essere attivata, ma può di solito essere omessa, dato che è l'opzione di default.

Il kernel assume alcuni valori di default quando un'interfaccia viene configurata. Per esempio, si può specificare l'indirizzo di rete e quello di broadcast per un'interfaccia, ma se questo non viene fatto, come nell'esempio precedente, il kernel farà delle scelte ragionevoli per i valori da assegnare in base alla maschera di rete fornita; se non viene fornita una maschera di rete si baserà sulla classe della rete associata all'indirizzo IP. Nell'esempio appena visto il kernel assegnerà un indirizzo di rete `192.168.0.0' e un indirizzo di broadcast `192.168.0.255' in base alla netmask specificata nel comando.

Si possono passare al comando ifconfig molte altre opzioni. Le più importanti di queste sono:

up

questa opzione attiva l'interfaccia (ed è l'impostazione di default).

down

questa opzione la disattiva.

[-]arp

questa opzione abitita o disabilita l'uso del protollo ARP ("Address Resulution Protocol") per questa interfaccia.

[-]allmulti

questa opzione abilita o disabilita la ricezione di tutti i pacchetti multicast. Il multicast permette di associare speciali indirizzi hardware di destinazione a gruppi di calcolatori, in modo che tutti gli appartenenti al gruppo ricevano certi pacchetti. Questa opzione può essere importante se si usano applicazioni come la videoconferenza ma normalmente non viene usata.

mtu N

questo parametro permette di assegnare il valore MTU ("Maximum Transfer Unit") per questa periferica.

netmask addr

questo parametro permette di specificare la maschera relativa alla rete cui questa interfaccia appartiene.

irq addr

questo parametro funziona solo con certi tipi di hardware e permette di scegliere la linea interruzione usata dall'hardware di questa interfaccia.

[-]broadcast [addr]

questo parametro permette di abilitare la ricezione di pacchetti di broadcast e assegna l'indirizzo di broadcast per questa interfaccia, oppure disabilita la ricezione di tali pacchetti.

[-]pointopoint [addr]

questo parametro permette di assegnare l'indirizzo della macchina che sta all'altro capo di una connessione punto-a-punto, come accade per slip e ppp.

hw <type> <addr>

questo parametro permette di assegnare l'indirizzo hardware di certi tipi di schede di rete. Questo è spesso inutile per per le interfaccie ethernet, ma è comodo per altri tipi di rete, come AX.25.

Il comando ifconfig può essere usato per agire su tutte le interfacce di rete. Alcuni programmi utente come pppd e dip configurano automaticamente le periferiche di rete quando le creano, e in questi casi l'uso manuale di ifconfig diventa inutile.

5.5 Configurazione del risolutore dei nomi (name resolver).

Il `Name Resolver' fa parte della libreria standard di Linux. La sua funzione principale è quella di fornire un servizio che converta i nomi dei calcolatori, quelli comprensibili all'uomo come `ftp.funet.fi', in indirizzi comprensibili alle macchine, come 128.214.248.6.

Cosa compone un nome?

Anche chi ha familiarità con i nomi degli host che costituiscono Internet potrebbe non comprendere come sono costituiti. I nomi di dominio (domain name) di Internet sono inerentemente gerarchici, hanno cioè una struttura ad albero. Un `dominio' (domain) è una famiglia, un gruppo di nomi. Un dominio può essere suddiviso in vari `sottodomini'. Un `dominio pricipale' (toplevel domain) è un dominio che non è un sottodominio. I domini principali sono specificati nell'RFC 920. I domini principali più comuni sono:

COM

Organizzazioni commerciali

EDU

Organizzazioni educative

GOV

Organizzazioni governative

MIL

Organizzazioni militari

ORG

Altre organizzazioni

NET

Organizzazioni connesse a Internet

Identificativo nazionale

questi sono codici di due lettere che rappresentano la nazione.

Per ragioni storiche la maggior parte dei domini che appartengono ai domini principali non nazionali sono stati usati da organizzazioni con sede negli Stati Uniti, malgrado gli Stati Uniti abbiano anche un proprio dominio nazionale `.us'. Questo non è più vero per i domini .com and .org, che vengono comunemente usati da società e organizzazioni non statunitensi.

Ognuno di questi domini pricipali ha i suoi sottodomini. I domini principali basati sui nomi di nazione sono spesso suddivisi in sottodomini come com, edu, gov, mil e org. Questo non succede in Italia, ma per esempio esistono i sottodomini com.au e gov.au per le organizzazioni commerciali e governative in Australia; da notare che questa non è una regola generale, dato che le linee effettive di condotta dipendono dalle autorità che gestiscono a livello locale l'assegnazione dei nomi.

Il livello successivo di divisione spesso rappresenta il nome dell'organizzazione. I sottodomini ulteriori possono essere di diversa natura; spesso il livello successivo è basato sulla suddivisione interna della organizzazione, ma può essere basato su qualsiasi criterio che sia considerato ragionevole e significativo all'interno dell'organizzazione.

La parte più a sinistra del nome è sempre il nome univocamente assegnato ad un calcolatore, e si chiama `hostname'. La parte di nome che sta alla destra del "hostname" si chiama `domainname', e il nome completo si chiama `Fully Qualified Domain Name', abbreviato FQDN.

Usando l'host di Terry come esempio, il FQDN è `perf.no.itg.telstra.com.au'. Questo significa che il suo "hostname" è `perf', e il "domain name" è `no.itg.telstra.com.au'. Il suo "domain name" è composto da un dominio principale basato sul nome della sua nazione, l'Australia, e poiché il suo indirizzo di posta elettronica appartiene ad un organizzazione commerciale c'è `.com' come sottodominio. Il nome della compagnia è (era) `telstra', e la sua struttura di nomi interna è basata sulla struttura gestionale, in questo caso il calcolatore appartiene al gruppo di tecnologia delle informazioni (Information Technology Group), sezione operazioni di rete (Network Operations).

Di solito, i nomi sono un po' più brevi; ad esempio il mio ISP (Internet Service Provider = fornitore di accesso a internet) si chiama `systemy.it' e la mia organizzazione senza scopo di lucro si chiama `linux.it', senza nessun sottodominio com e org , così che il mio host personale si chiama `morgana.systemy.it' e rubini@linux.it è un indirizzo di posta elettronica valido. Da notare che chi amministra un dominio può registrare nomi di singoli host come anche sottodomini; ad esempio il LUG a cui appartengo usa il dominio pluto.linux.it, poiché i titolari di linux.it hanno acconsentito a creare un sottodominio per il LUG.

Quali informazioni sono necessarie.

Per accedere al servizio di risoluzione dei nomi occorre sapere a quale dominio appartiene il proprio calcolatore. Il software di risoluzione dei nomi offre il servizio di traduzione dei nomi facendo delle richieste ad un `Domain Name Server' (di solito chiamato semplicemente `name server'), per cui occorre anche conoscere l'indirizzo di un name server locale che offra questo servizio.

Per configurare il proprio calcolatore occorre sistemare tre file, che descriverò uno alla volta.

/etc/resolv.conf

Il file /etc/resolv.conf è il file di configurazione principale per accedere al servizio di risoluzione dei nomi. Il suo formato è abbastanza semplice: si tratta di un file di testo con una parola chiave (direttiva) per linea. Le direttive comunemente usate sono tre:

domain

questa direttiva specifica il nome del dominio locale.

search

questa direttiva specifica una lista di domini da consultare in alternativa.

nameserver

questa direttiva, che può essere usata più di una volta, specifica l'indirizzo IP di un name server a cui rivolgersi per la risoluzione dei nomi.

Per esempio, /etc/resolv.conf potrebbe essere qualcosa di simile a:

        domain maths.wu.edu.au
        search maths.wu.edu.au wu.edu.au
        nameserver 192.168.10.1
        nameserver 192.168.12.1
        

Questo esempio specifica che il dominio di default da usare per i nomi non qualificati (cioè gli hostname senza un dominio associato) è maths.wu.edu.au, e che se l'host non viene trovato in quel dominio bisogna provare direttamente anche il dominio wu.edu.au. Il file specifica anche due name server, ciascuno dei quali può essere consultato dal software di risoluzione per risolvere un nome.

/etc/host.conf

Il file /etc/host.conf è quello dove si dichiarano alcuni elementi che governano il comportamento del codice di risoluzione dei nomi. Il formato di questo file è descritto in dettaglio nella pagina del manuale di `resolv+'. In quasi tutti i casi queste due linee sono tutto quello che serve:

                          
        order hosts,bind                                          
        multi on  
        

Questa configurazione dice al codice di risoluzione dei nomi di controllare il file /etc/hosts prima di tentare una ricerca attraverso un name server, e dice di ritornare tutti gli indirizzi definiti per un host descritto in /etc/hosts, invece che ritornare solo il primo.

/etc/hosts

Il file /etc/hosts è quello che contiene i nomi e gli indirizzi IP dei calcolatori locali. Se un host appare in questo file non occorre interrogare un name server per conoscere il suo indirizzo IP. Lo svantaggio di questo tipo di approccio è che occorre aggiornare questo file ogniqualvolta l'indirizzo IP relativo ad un calcolatore cambia. Solitamente, in un sistema ben gestito le uniche voci che appaiono in questo file sono una per l'interfaccia di loopback e una per il nome del calcolatore stesso.

        # /etc/hosts
        127.0.0.1      localhost loopback
        192.168.0.1    this.host.name
        

È possibile specificare più di un nome di calcolatore per linea, come dimostrato dalla prima voce qui sopra, che è il modo convenzionale per dare un nome all'interfaccia di loopback.

Attivare un name server

Se si desidera far girare un name server locale, lo si può fare facilmente. Si prega di fare riferimento al DNS-HOWTO e a ogni documento incluso nella propria versione di BIND (Berkeley Internet Name Domain).

5.6 Configurazione dell'interfaccia di loopback.

L'interfaccia `loopback' è un tipo speciale di interfaccia che permette ad un calcolatore di effettuare connessioni con se stesso. Ci sono diversi motivi per cui capita di aver bisogno di farlo; per esempio quando occorre verificare il funzionamento di programmi di rete senza interferire con nessun altro sulla rete. Per convenzione è stato assegnato all'interfaccia di loopback l'indirizzo IP `127.0.0.1'. Perciò, indipendentemente dal calcolatore sul quale si lavora, se si apre una connessione telnet a 127.0.0.1 si raggiungerà sempre la macchina da cui si è partiti.

La configurazione dell'interfaccia di loopback è semplice, ed è una cosa che bisogna assicurarsi di fare (ma da notare che di solito tale compito è svolto dagli script standard di inizializzazione).

        root# ifconfig lo 127.0.0.1
        root# route add -host 127.0.0.1 lo
        

Il comando route verrà trattato più estesamente nella prossima sezione.

5.7 Routing.

Il "routing", ovvero le questioni relative all'instradamento dei pacchetti, costituisce un argomento ampio. Si possono facilmente scrivere grossi libri su queste tematiche. La maggior parte delle persone, comunque, hanno necessità di instradamento abbastanza semplici, mentre poche altre hanno esigenze più complicate. Tratterò qui solo i concetti fondamentali dell'instradamento dei pacchetti. Suggerisco a chi è interessato ad avere informazioni più dettagliate di consultare i manuali elencati all'inizio di questo documento.

Inizierei con una definizione. Cos'è l'instradamento IP? Questa è la definizione che uso io:

L'instradamento IP (routing) è il procedimento attraverso il quale un calcolatore con connessioni di rete multiple decide dove trasmettere i pacchetti IP che ha ricevuto.

Potrebbe essere utile illustrare questa definizione con un esempio. Immaginiamo un tipico router in un ufficio, che abbia una connessione PPP verso Internet, un certo numero di segmenti ethernet che collegano le postazioni locali e un secondo collegamento PPP verso un altro ufficio. Quando il router riceve un pacchetto da una qualsiasi delle sue connessioni di rete, il meccanismo usato per determinare su quale interfaccia deve essere spedito il pacchetto è proprio il routing. Anche gli host più semplici hanno bisogno di instradare i pacchetti, tutti gli host di Internet hanno infatti due interfacce di rete: una è quella di loopback descritta prima e l'altra è queslla usata per comunicare col resto della rete; questa può essere una ethernet oppure un collegamento su porta seriale PPP o SLIP.

Bene, ma come funziona l'instradamento? Ogni host mantiene una lista di regole di instradamento, chiamata "routing table". Questa tabella contiene delle voci che sono in genere formate da almeno tre campi: il primo è l'indirizzo di destinazione, il secondo è il nome dell'interfaccia attraverso la quale instradare il pacchetto, e il terzo è l'indirizzo IP opzionale di un'altra macchina che si incarichi di decidere il prossimo passo che il pacchetto deve fare attraverso la rete. In Linux la tabella di instradamento può essere visualizzata usando il seguente comando:

        user% cat /proc/net/route
        

oppure uno dei seguenti:

        user% /sbin/route -n
        user% /bin/netstat -r
        

Il procedimento di instradamento è abbastanza semplice: viene ricevuto un pacchetto, viene esaminato il suo indirizzo di destinazione (a chi è destinato quel pacchetto) e tale indirizzo viene confrontato con tutte le voci della tabella. La voce che meglio rispecchia l'indirizzo di destinazione viene poi usata per la ritrasmissione del pacchetto, attraverso l'interfaccia specificata dalla voce. Se poi il campo `gateway' di questa voce è valido il pacchetto viene passato a tale host attraverso l'interfaccia specificata; in caso contrario si assume che l'indirizzo di destinazione sia sulla rete connessa all'interfaccia scelta.

Per manipolare la tabella esiste un comando specifico. Questo comando riceve degli argomenti sulla linea di comando e li converte in chiamate di sistema che richiedono al kernel di aggiungere, rimuovere o modificare le voci della tabella di routing. Tale comando si chiama `route'.

Passiamo ora ad un semplice esempio, immaginando che voi siate connessi ad una ethernet e che vi sia stato detto che la rete è una classe C con indirizzo 192.168.1.0; immaginiamo inoltre che l'indirizzo 192.168.1.10 sia stato assegnato alla vostra macchina, e che 192.168.1.1 sia il router connesso al resto di Internet.

Il primo passo da fare è configurare l'interfaccia come descritto in precedenza. A questo fine si userà un comando tipo:

        root# ifconfig eth0 192.168.1.10 netmask 255.255.255.0 up
        

Adesso occorre aggiungere nella tabella di routing una voce che dica al kernel che tutti i pacchetti destinati a calcolatori con indirizzi del tipo 192.168.1.* devono essere spediti sull'interfaccia ethernet. Il comando per dire ciò sarà:

        root# route add -net 192.168.1.0 netmask 255.255.255.0 eth0
        

Si noti l'uso dell'argomento `-net', che dice al programma "route" che questa voce si riferisce ad un'intera rete. L'altra possibilità è quella di specificare una regola di tipo `-host', cioè una regola di instradamento specifica ad un singolo indirizzo IP.

La regola di instradamento appena mostrata è quella che permette di stabilire connessioni con tutti gli host del proprio segmento ethernet. Ma come si fa a connettersi a tutte le macchine che non sono sul proprio ramo ethernet?

Dover aggiungere regole di instradamento per tutte le possibili reti sarebbe un lavoro molto difficile; perciò esiste un trucco per semplificare questo compito. Il trucco si chiama "regola di instradamento di `default'". La regola "di default" si riferisce a tutti gli indirizzi di destinazione, ma in modo "blando", cosicch se esiste un'altra voce nella tabella che si riferisce all'indirizzo di destinazione del pacchetto, questa voce verrà usata al posto di quella di default. L'idea della regola di default è semplicemente quella di dire "e tutto il resto deve andare qui". Nell'esempio di cui ci stiamo occupando si userà un comando come:

        # route add default gw 192.168.1.1 eth0
        

L'argomento `gw' dice al comando `route' che l'argomento seguente è l'indirizzo numerico, o il nome, di una macchina che fa da gateway, o router, cui devono essere spediti tutti i pacchetti ai quali questa regola si applica, ai fini di un ulteriore instradamento.

Perciò, la vostra configurazione completa sarà:

        root# ifconfig eth0 192.168.1.10 netmask 255.255.255.0 up
        root# route add -net 192.168.1.0 netmask 255.255.255.0 eth0
        root# route add default gw 192.168.1.1 eth0
        

Guardando attentamente i file di configurazione di rete che si trovano sulle macchine Linux troverete che almeno uno di essi sarà molto simile a quello appena mostrato. Questo tipo di configurazione è molto diffuso.

Vediamo ora una configurazione dell'instradamento leggermente più complicata. Immaginiamo di configurare il router che abbiamo visto prima, quello con la connessione PPP verso Internet e i segmenti ethernet verso i calcolatori nell'ufficio. Immaginiamo che il router abbia tre segmenti ethernet e un collegamento PPP. La nostra configurazione di routing sarà qualcosa come:

        root# route add -net 192.168.1.0 netmask 255.255.255.0 eth0
        root# route add -net 192.168.2.0 netmask 255.255.255.0 eth1
        root# route add -net 192.168.3.0 netmask 255.255.255.0 eth2
        root# route add default ppp0
        

Ognuna delle workstation sulla rete locale userà la forma più semplice presentata prima, solo il router deve specificare separatamente le informazioni relativa a ciascun tratto della rete locale, perché per le workstation il meccanismo della regola di default si occuperà di tutte le sottoreti, lasciando al router il compito di suddividere correttamente i pacchetti. Ci si può chiedere perché la regola di default appena vista per il router non specifichi un `gw'. La ragione è semplice: i protocolli su linea seriale come PPP e SLIP hanno sempre e solo due calcolatori sulla loro "rete": uno ad ogni estremo. Specificare il calcolatore che si trova all'altro estremo del cavo come `gateway' è inutile e ridondante, poiché non esistono altre possibilità, e per questo motivo non occorre esplicitare il gateway per questo tipo di connessioni. Altri tipi di rete, come ethernet, arcnet o token ring, richiedono invece che si specifichi il numero del gateway, poiché queste reti permettono a molti calcolatori di essere collegati insieme.

Allora a cosa serve il programma routed?

La configurazione di routing descritta fino adessso si applica bene a situazioni di rete semplici, dove c'è sempre solo un singolo percorso possibile per una data destinazione. Se la propria rete è più complessa, le cose diventano più complicate. Fortunatamente per la maggior parte delle persone questo non è un problema.

Il problema principale con il cosiddetto `instradamento manuale' o `instradamento statico' come quello appena descritto è che se un calcolatore o un collegamento all'interno della propria rete smette di funzionare, l'unico modo (se possibile) per dirigere i pacchetti su di un'altra strada consiste nell'intervenire a mano ed eseguire i comandi appropriati. Naturalmente questo è impegnativo, lento, poco pratico e rischia di fallire. Sono state sviluppate varie tecniche per correggere automaticamente le tabelle di routing in caso di problemi sulla rete quando ci siano percorsi alternativi. Tutte queste tecniche sono raggruppate sotto il nome di "protocolli dinamici di instradamento".

Può essere capitato a tutti di sentir nominare i protocolli dinamici più usati. I più comuni probabilmente sono RIP (Routing Information Protocol) e OSPF (Open Shortest Path First). Il protocollo RIP è molto comune nelle reti piccole, come le reti di organizzazioni di dimensione medio-piccola, o reti situate in un unico edificio. OSPF è più moderno e più in grado di gestire grosse configurazioni di rete, e pure più adatto ad ambienti dove esistono molti percorsi possibili attraverso la rete. Le implementazioni più diffuse di questi protocolli sono `routed' (per RIP), e `gated' (per RIP, OSPF e altri protocolli). Il programma `routed' di solito fa parte delle distribuzioni di Linux, oppure si può trovare incluso nel pacchetto `NetKit' descritto all'inizio.

Un esempio di dove e quando serva usare un protocollo di instradamento dinamico potrebbe somigliare al seguente:

    192.168.1.0 /                         192.168.2.0 /
       255.255.255.0                         255.255.255.0
     -                                     -
     |                                     |
     |   /-----\                 /-----\   |
     |   |     |ppp0   //    ppp0|     |   |
eth0 |---|  A  |------//---------|  B  |---| eth0
     |   |     |     //          |     |   |
     |   \-----/                 \-----/   |
     |      \ ppp1             ppp1 /      |
     -       \                     /       -
              \                   /
               \                 /
                \               /
                 \             /
                  \           /
                   \         /
                    \       /
                     \     /
                  ppp0\   /ppp1
                     /-----\
                     |     |
                     |  C  |
                     |     |
                     \-----/
                        |eth0
                        |
                   |---------|
                   192.168.3.0 /
                      255.255.255.0

Ci sono qui tre router: A, B e C. Ognuno di essi è connesso ad una ethernet che porta una rete di classe C (netmask 255.255.255.0). Ogni router ha anche una connessione PPP verso ognuno degli altri due router. La rete forma un triangolo.

Dovrebbe essere chiaro che la tabella di routing per il router A dovrebbe essere presente qualcosa come:

        root# route add -net 192.168.1.0 netmask 255.255.255.0 eth0
        root# route add -net 192.168.2.0 netmask 255.255.255.0 ppp0
        root# route add -net 192.168.3.0 netmask 255.255.255.0 ppp1
        

Questa situazione funzionerebbe bene, finché non si interrompesse il collegamento tra il router A e il router B. Se la connessione si interrompe, la tabella di instradamento mostrata non permetterebbe ai calcolatori sul segmento ethernet A di raggiungere calcolatori sul segmento B, perché i loro pacchetti sarebbero rediretti da A sulla connessione ppp0, che è momentaneamente caduta. I calcolatori sulla rete A possono comunque continuare a parlare ai calcolatori sulla rete C, e questi ultimo possono continuare a parlare con i calcolatori sulla rete B, poiché il collegamento tra B e C è ancora funzionante.

Ma allora, se A può parlare a C, e C può ancora parlare a B, perché non potrebbe A mandare i suoi pacchetti a B attraverso C? Questo è esattamente il tipo di problemi che viene affrontato dai protocolli dinamici come RIP. Se ognuno dei router A, B e C facesse girare un programma demone di instradamento, allora le loro tabelle di routing sarebbero corrette automaticamente per riflettere in nuovo stato della rete ogniqualvolta uno dei collegamenti della rete si interrompesse. Configurare questa rete è semplice: occorre fare solo due cose su ognuno dei router. In questo caso, per A bisogna invocare:

        root# route add -net 192.168.1.0 netmask 255.255.255.0 eth0
        root# /usr/sbin/routed
        

Il demone `routed' trova automaticamente le interfacce di rete attive nel momento in cui viene invocato, e successivamente manda dei messaggi e ascolta le risposte su ogni interfaccia di rete, in modo da poter determinare la routing table ed aggiornarla.

Questo termina la breve spiegazione dell'instradamento dinamico e dove è il caso di usarlo. Se si vogliono più informazioni al proposito occorre riferirsi alle fonti di informazione elencate all'inizio di questo documento.

I punti importanti relativi all'instradamento dinamico sono:

1. È necessario eseguire un demone per gestire un protocollo di instradamento dinamico solo quando la propria macchina Linux ha la possibilità di selezionare tra piu d'un percorso possibile per una stessa destinazione.
2. Il programma di instradamento dinamico modifica automaticamente la tabella di intradamento perché rispecchi i cambiamenti della rete.
3. RIP ben si presta alla gestione di reti piccole e medie.

5.8 Configurazione dei servizi di rete e dei programmi server.

I programmi "server" ed i servizi di rete sono quei programmi che permettono ad un utente remoto di utilizzare la macchina Linux locale. I programmi server attendono le connessioni entranti su di una porta di rete. Le porte sono un mezzo per indirizzare un particolare servizio su di un particolare calcolatore e sono il modo in cui un calcolatore server può distinguere tra una connessione entrante di tipo telnet ed una di tipo ftp. L'utente remoto stabilisce una connessione di rete con la macchina server e il programma server (anche detto "daemon" di rete) che sta attendendo una connessione su quella porta accetta la connessione ed inizia a funzionare. Ci sono due modi di utilizzare i servizi di rete, entrambi usati comunemente nella pratica. Questi modi sono:

standalone (da solo)

. Il programma di rete ascolta una porta specifica di rete e quando avverte una connessione in ingresso la gestisce da solo per fornire il servizio richiesto.

dipendente dal server inetd

Il server inetd è un programma-demone speciale di rete che si occupa di gestire le connessioni in ingresso. inetd fa uso di un file di configurazione che gli dice quale programma deve essere invocato quando viene ricevuta una connessione entrante su una particolare porta. Una porta può essere configurata per entrambi i protocolli, tcp o udp. Le porte stesse sono descritte in un altro file, di cui si parlerà presto.

Ci sono due file importanti che occorre configurare per usare inetd: /etc/services assegna dei nomi simbolici ai numeri delle porte, mentre /etc/inetd.conf è il file di configurazione per il programma inetd.

/etc/services

Il file /etc/services è un semplice database che associa ad ogni numero di porta comprensibile alla macchina un nome comprensibile all'uomo. Il suo formato è molto semplice: il file è un testo ciascuna riga del quale rappresenta una voce del database. Ogni voce è composta da tre campi separati da un numero qualunque di spazi bianchi (spazi o caratteri `tab'). I campi sono:

  nome      porta/protocollo     alias       # commento
  

nome

è una singola parola che rappresenta il servizio che si sta descrivendo.

porta/protocollo

questo campo è diviso in due sottocampi.

porta

un numero che specifica il numero di porta sulla quale il servizio è reso disponibile. La maggior parte dei servizi comunemente usati hanno un numero assegnato loro. Questi numeri sono descritti nel RFC-1340.

protocollo

questo sottocampo è o "tcp" o "udp".

È importante notare che un valore pari a 18/tcp è molto differente da 18/udp e che non ci sono ragioni tecniche per cui un servizio debba esistere su entrambe le porte. Normalmente si usa il buon senso, e il database contiene entrambe le voci solo se un servizio è disponibile sia attraverso tcp che attraverso udp.

alias

altri nomi che possono essere usati per indicare questo servizio.

Tutto il testo che appare in una riga dopo un carattere `#' è trattato come commento.

Un file /etc/services di esempio.

Tutte le distribuzioni recenti di Linux contengono un buon file /etc/services. Nel caso occorra configurare un calcolatore da zero, questa è una copia del file /etc/services fornito con una vecchia distribuzione Debian:

# /etc/services:
# $Id: services,v 1.3 1996/05/06 21:42:37 tobias Exp $
#
# Network services, Internet style
#
# Si noti che attualmente la politica dello IANA è di assegnare
# un singolo numero di porta per entrambi TCP e UDP; perciò la maggior
# parte delle voci sono duplicate, anche se il protocollo non funziona
# con UDP.
# Aggiornato dall'RFC 1340, ``Assigned Numbers'' (Luglio 1992).
# Non sono incluse tutte le porte, solo le più comuni.

tcpmux          1/tcp                           # TCP port service multiplexer
echo            7/tcp
echo            7/udp
discard         9/tcp           sink null
discard         9/udp           sink null
systat          11/tcp          users
daytime         13/tcp
daytime         13/udp
netstat         15/tcp
qotd            17/tcp          quote
msp             18/tcp                          # message send protocol
msp             18/udp                          # message send protocol
chargen         19/tcp          ttytst source
chargen         19/udp          ttytst source
ftp-data        20/tcp
ftp             21/tcp
ssh             22/tcp                          # SSH Remote Login Protocol
ssh             22/udp                          # SSH Remote Login Protocol
telnet          23/tcp
# 24 - private
smtp            25/tcp          mail
# 26 - unassigned
time            37/tcp          timserver
time            37/udp          timserver
rlp             39/udp          resource        # resource location
nameserver      42/tcp          name            # IEN 116
whois           43/tcp          nicname
re-mail-ck      50/tcp                          # Remote Mail Checking Protocol
re-mail-ck      50/udp                          # Remote Mail Checking Protocol
domain          53/tcp          nameserver      # name-domain server
domain          53/udp          nameserver
mtp             57/tcp                          # deprecated
bootps          67/tcp                          # BOOTP server
bootps          67/udp
bootpc          68/tcp                          # BOOTP client
bootpc          68/udp
tftp            69/udp
gopher          70/tcp                          # Internet Gopher
gopher          70/udp
rje             77/tcp          netrjs
finger          79/tcp
www             80/tcp          http            # WorldWideWeb HTTP
www             80/udp                          # HyperText Transfer Protocol
link            87/tcp          ttylink
kerberos        88/tcp          kerberos5 krb5  # Kerberos v5
kerberos        88/udp          kerberos5 krb5  # Kerberos v5
supdup          95/tcp
# 100 - reserved
hostnames       101/tcp         hostname        # usually from sri-nic
iso-tsap        102/tcp         tsap            # part of ISODE.
csnet-ns        105/tcp         cso-ns          # also used by CSO name server
csnet-ns        105/udp         cso-ns
rtelnet         107/tcp                         # Remote Telnet
rtelnet         107/udp
pop-2           109/tcp         postoffice      # POP version 2
pop-2           109/udp
pop-3           110/tcp                         # POP version 3
pop-3           110/udp
sunrpc          111/tcp         portmapper      # RPC 4.0 portmapper TCP
sunrpc          111/udp         portmapper      # RPC 4.0 portmapper UDP
auth            113/tcp         authentication tap ident
sftp            115/tcp
uucp-path       117/tcp
nntp            119/tcp         readnews untp   # USENET News Transfer Protocol
ntp             123/tcp
ntp             123/udp                         # Network Time Protocol
netbios-ns      137/tcp                         # NETBIOS Name Service
netbios-ns      137/udp
netbios-dgm     138/tcp                         # NETBIOS Datagram Service
netbios-dgm     138/udp
netbios-ssn     139/tcp                         # NETBIOS session service
netbios-ssn     139/udp
imap2           143/tcp                         # Interim Mail Access Proto v2
imap2           143/udp
snmp            161/udp                         # Simple Net Mgmt Proto
snmp-trap       162/udp         snmptrap        # Traps for SNMP
cmip-man        163/tcp                         # ISO mgmt over IP (CMOT)
cmip-man        163/udp
cmip-agent      164/tcp
cmip-agent      164/udp
xdmcp           177/tcp                         # X Display Mgr. Control Proto
xdmcp           177/udp
nextstep        178/tcp         NeXTStep NextStep       # NeXTStep window
nextstep        178/udp         NeXTStep NextStep       # server
bgp             179/tcp                         # Border Gateway Proto.
bgp             179/udp
prospero        191/tcp                         # Cliff Neuman's Prospero
prospero        191/udp
irc             194/tcp                         # Internet Relay Chat
irc             194/udp
smux            199/tcp                         # SNMP Unix Multiplexer
smux            199/udp
at-rtmp         201/tcp                         # AppleTalk routing
at-rtmp         201/udp
at-nbp          202/tcp                         # AppleTalk name binding
at-nbp          202/udp
at-echo         204/tcp                         # AppleTalk echo
at-echo         204/udp
at-zis          206/tcp                         # AppleTalk zone information
at-zis          206/udp
z3950           210/tcp         wais            # NISO Z39.50 database
z3950           210/udp         wais
ipx             213/tcp                         # IPX
ipx             213/udp
imap3           220/tcp                         # Interactive Mail Access
imap3           220/udp                         # Protocol v3
ulistserv       372/tcp                         # UNIX Listserv
ulistserv       372/udp
#
# UNIX specific services
#
exec            512/tcp
biff            512/udp         comsat
login           513/tcp
who             513/udp         whod
shell           514/tcp         cmd             # no passwords used
syslog          514/udp
printer         515/tcp         spooler         # line printer spooler
talk            517/udp
ntalk           518/udp
route           520/udp         router routed   # RIP
timed           525/udp         timeserver
tempo           526/tcp         newdate
courier         530/tcp         rpc
conference      531/tcp         chat
netnews         532/tcp         readnews
netwall         533/udp                         # -for emergency broadcasts
uucp            540/tcp         uucpd           # uucp daemon
remotefs        556/tcp         rfs_server rfs  # Brunhoff remote filesystem
klogin          543/tcp                         # Kerberized `rlogin' (v5)
kshell          544/tcp         krcmd           # Kerberized `rsh' (v5)
kerberos-adm    749/tcp                         # Kerberos `kadmin' (v5)
#
webster         765/tcp                         # Network dictionary
webster         765/udp
#
# From ``Assigned Numbers'':
#
#> Le "porte registrate" non sono controllate dallo IANA e su molti
#> sistemi possono essere usate da ordinari processi dell'utente
#> o programmi eseguiti da utenti non privilegiati.
#
#> Le porte sono usate in TCP [45,106] per dare un nome agli estremi
#> di connessioni logiche che trasportano conversazioni a lungo termine.
#> Al fine di fornire servizi ad anonimi, viene definita
#> una porta di contatto per il servizio. Questa lista specifica
#> la porta usata dal processo server come porta di contatto. Anche se
#> lo IANA non può controllare l'uso di queste porte, registra
#> comunque queste porte e riconosce il loro uso per la convenienza
#> della comunità.
#
ingreslock      1524/tcp
ingreslock      1524/udp
prospero-np     1525/tcp                # Prospero non-privileged
prospero-np     1525/udp
rfe             5002/tcp                # Radio Free Ethernet
rfe             5002/udp                # Actually uses UDP only
bbs             7000/tcp                # BBS service
#
#
# Servizi Kerberos (Progetto Athena/MIT)
# Si noti che questi servizi sono usati da Kerberos versione 4,
# e non sono ufficiali. Chi usa la versione 4 dovrebbe scommentare
# queste voci e commentare quelle per la versione 5 definite più sopra.
#
kerberos4       750/udp         kdc     # Kerberos (server) udp
kerberos4       750/tcp         kdc     # Kerberos (server) tcp
kerberos_master 751/udp                 # Kerberos authentication
kerberos_master 751/tcp                 # Kerberos authentication
passwd_server   752/udp                 # Kerberos passwd server
krb_prop        754/tcp                 # Kerberos slave propagation
krbupdate       760/tcp         kreg    # Kerberos registration
kpasswd         761/tcp         kpwd    # Kerberos "passwd"
kpop            1109/tcp                # Pop with Kerberos
knetd           2053/tcp                # Kerberos de-multiplexor
zephyr-srv      2102/udp                # Zephyr server
zephyr-clt      2103/udp                # Zephyr serv-hm connection
zephyr-hm       2104/udp                # Zephyr hostmanager
eklogin         2105/tcp                # Kerberos encrypted rlogin
#
# Servizi non ufficiali ma necessari per NetBSD
#
supfilesrv      871/tcp                 # SUP server
supfiledbg      1127/tcp                # SUP debugging
#
# Servizi "Datagram Delivery Protocol"
#
rtmp            1/ddp                   # Routing Table Maintenance Protocol
nbp             2/ddp                   # Name Binding Protocol
echo            4/ddp                   # AppleTalk Echo Protocol
zip             6/ddp                   # Zone Information Protocol
#
# Servizi Debian GNU/Linux
rmtcfg          1236/tcp                # Gracilis Packeten remote config server
xtel            1313/tcp                # french minitel
cfinger         2003/tcp                # GNU Finger
postgres        4321/tcp                # POSTGRES
mandelspawn     9359/udp        mandelbrot      # network mandelbrot

# Local services

In realtà il file effettivo è in continua crescita dato che vengono continuamente creati nuovi servizi. Se si teme che la propria copia sia incompleta, si suggerisce di copiare un nuovo /etc/services da una distribuzione recente.

/etc/inetd.conf

Il file /etc/inetd.conf è il file di configurazione per il server di rete inetd. La sua funzione è quella di dire a inetd cosa fare quando riceve una richiesta di connessione per un particolare servizio. Bisogna dire ad inetd quale server demone di rete far partire per ciascun servizio che si vuole fornire, bisogna anche dire come farlo partire.

Il formato del file è abbastanza semplice: si tratta di un file di testo in cui ogni riga descrive un servizio che si intende offrire. Tutto quello che in una linea segue un segno # è ignorato e considerato un commento. Ogni linea contiene sette campi separati da un numero qualsiasi di spazi bianchi (tab o carattere di spazio). Il formato generale è:

service  socket_type  proto  flags  user  server_path  server_args

service

è il servizio al quale si riferisce questa riga, è cioè uno dei nomi che stanno nel file /etc/services.

socket_type

questo campo descrive il tipo di socket cui questa voce si riferisce, i cui valori validi sono: stream, dgram, raw, rdm, o seqpacket. Questa questione è abbastanza tecnica, ma come regola pratica basti ricordare che quasi tutti i servizi basati su tcp usano stream e quasi tutti i servizi basati su udp usano dgram. Solo servizi molto particolari useranno uno degli altri valori.

proto

il protocollo usato da questa voce. Questo deve corrispondere alla voce appropriata di /etc/services e sarà di solito tcp o udp. I servizi basati su "Sun RPC" (Remote Procedure Call) useranno rpc/tcp o rpc/udp.

flags

ci sono solo due valori possibili per questo campo, che dice a inetd se il programma server libera il socket dopo avere iniziato a lavorare. Il campo dice quindi se inetd deve far partire un altro server alla prossima richiesta di connessione oppure se deve attendere, assumendo che il processo già in funzione gestisca anche le nuove richieste di connessione. Ancora una volta, questa informazione può essere difficile da ottenere, ma in genere tutti i server tcp dovranno avere nowait in questo campo, mentre la maggior parte dei server udp dovrebbero avere il valore wait. Bisogna però fare attenzione alle eccezioni a questa regola, perciò quando non si è sicuri conviene farsi guidare dall'esempio che verrà introdotto a breve.

user

questo campo descrive a quale degli account presenti in /etc/passwd deve essere assegnata la proprietà del server di rete che viene fatto partire. Questo campo è spesso utile per proteggersi da possibili problemi di sicurezza. Si può assegnare l'utente nobody come proprietario di un server, in modo da minimizzare il danno possibile in caso di compromissione della sicurezza del server di rete. Di solito, comunque, questo campo viene posto a root, poiché molti server hanno bisogno dei privilegi del superutente per funzionare correttamente.

server_path

questo campo è il percorso completo (pathname) del programma server che deve essere eseguito in relazione a questo servizio.

server_args

questo campo comprende il resto della riga ed è opzionale. In questo campo si mettono gli argomenti di linea di comando che si intendono passare al programma server quando questo viene lanciato.

Un esempio di /etc/inetd.conf

Come per /etc/services, tutte le distribuzioni aggiornate di Linux includono un buon file /etc/inetd.conf con cui poter lavorare. Qui per completezza riporto il file /etc/inetd.conf che appare nella distribuzione Debian.

# /etc/inetd.conf:  see inetd(8) for further informations.
#
# Internet server configuration database
#
#
# Modified for Debian by Peter Tobias <tobias@et-inf.fho-emden.de>
#
# <service_name> <sock_type> <proto> <flags> <user> <server_path> <args>
#
# Internal services
#
#echo           stream          tcp     nowait          root    internal
#echo           dgram           udp     wait            root    internal
discard stream  tcp     nowait          root    internal
discard dgram           udp     wait            root    internal
daytime stream          tcp     nowait          root    internal
daytime dgram           udp     wait            root    internal
#chargen        stream          tcp     nowait          root    internal
#chargen        dgram           udp     wait            root    internal
time            stream          tcp     nowait          root    internal
time            dgram           udp     wait            root    internal
#
# These are standard services.
#
telnet          stream          tcp     nowait          root    /usr/sbin/tcpd  /usr/sbin/in.telnetd
ftp             stream          tcp     nowait          root    /usr/sbin/tcpd  /usr/sbin/in.ftpd
#fsp            dgram           udp     wait            root    /usr/sbin/tcpd  /usr/sbin/in.fspd
#
# Shell, login, exec and talk are BSD protocols.
#
shell   stream          tcp     nowait          root    /usr/sbin/tcpd  /usr/sbin/in.rshd
login   stream          tcp     nowait          root    /usr/sbin/tcpd  /usr/sbin/in.rlogind
#exec   stream          tcp     nowait          root    /usr/sbin/tcpd  /usr/sbin/in.rexecd
talk    dgram   udp     wait    root    /usr/sbin/tcpd  /usr/sbin/in.talkd
ntalk   dgram   udp     wait    root    /usr/sbin/tcpd  /usr/sbin/in.ntalkd
#
# Mail, news and uucp services.
#
smtp    stream          tcp     nowait          root    /usr/sbin/tcpd  /usr/sbin/in.smtpd  
#nntp   stream          tcp     nowait          news    /usr/sbin/tcpd  /usr/sbin/in.nntpd
#uucp   stream          tcp     nowait          uucp    /usr/sbin/tcpd  /usr/lib/uucp/uucico
#comsat dgram   udp     wait    root    /usr/sbin/tcpd  /usr/sbin/in.comsat
#
# Pop et al
#
#pop-2  stream          tcp     nowait  root    /usr/sbin/tcpd  /usr/sbin/in.pop2d
#pop-3  stream          tcp     nowait  root    /usr/sbin/tcpd  /usr/sbin/in.pop3d
#
# `cfinger' is for the GNU finger server available for Debian.  (NOTE: The
# current implementation of the `finger' daemon allows it to be run as `root'.)
#
#cfinger        stream          tcp     nowait          root    /usr/sbin/tcpd  /usr/sbin/in.cfingerd
#finger stream          tcp     nowait          root    /usr/sbin/tcpd  /usr/sbin/in.fingerd
#netstat        stream          tcp     nowait          nobody          /usr/sbin/tcpd  /bin/netstat
#systat stream          tcp     nowait          nobody          /usr/sbin/tcpd  /bin/ps -auwwx
#
# Tftp service is provided primarily for booting.  Most sites
# run this only on machines acting as "boot servers."
#
#tftp   dgram   udp     wait    nobody  /usr/sbin/tcpd  /usr/sbin/in.tftpd
#tftp   dgram   udp     wait    nobody  /usr/sbin/tcpd  /usr/sbin/in.tftpd /boot
#bootps dgram   udp     wait    root    /usr/sbin/bootpd        bootpd -i -t 120
#
# Kerberos authenticated services (these probably need to be corrected)
#
#klogin         stream          tcp     nowait          root    /usr/sbin/tcpd  /usr/sbin/in.rlogind -k
#eklogin        stream          tcp     nowait          root    /usr/sbin/tcpd  /usr/sbin/in.rlogind -k -x
#kshell         stream          tcp     nowait          root    /usr/sbin/tcpd  /usr/sbin/in.rshd -k
#
# Services run ONLY on the Kerberos server (these probably need to be corrected)
#
#krbupdate      stream tcp      nowait          root    /usr/sbin/tcpd  /usr/sbin/registerd
#kpasswd        stream          tcp     nowait          root    /usr/sbin/tcpd  /usr/sbin/kpasswdd
#
# RPC based services
#
#mountd/1       dgram   rpc/udp wait    root    /usr/sbin/tcpd  /usr/sbin/rpc.mountd
#rstatd/1-3     dgram   rpc/udp wait    root    /usr/sbin/tcpd  /usr/sbin/rpc.rstatd
#rusersd/2-3    dgram   rpc/udp wait    root    /usr/sbin/tcpd  /usr/sbin/rpc.rusersd
#walld/1        dgram   rpc/udp wait    root    /usr/sbin/tcpd  /usr/sbin/rpc.rwalld
#
# End of inetd.conf.
ident   stream          tcp     nowait          nobody          /usr/sbin/identd        identd -i

5.9 Altri file di configurazione relativi alla rete.

C'è un certo numero di altri file, relativi alla configurazione di rete sotto Linux, ai quali merita dare un'occhiata. Non ci sarà bisogno di modificare questi file, ma vale la pena di descriverli, in modo da sapere cosa contengono e a cosa servono.

/etc/protocols

Il file /etc/protocols è un database che associa i numeri identificativi dei protocolli al nomi di ciascun protocollo. Questa informazione viene usata dai programmatori per poter specificare per nome i protocolli all'interno dei programmi, e viene usata da alcuni programmi come tcpdump al fine di mostrare nei loro messaggi i nomi di protocollo invece dei numeri. La sintassi del file è:

  nome-protocollo  numero alias
  

Il file /etc/protocols che fa parte della distribuzione Debian è fatto così:

# /etc/protocols:
# $Id: protocols,v 1.1 1995/02/24 01:09:41 imurdock Exp $
#
# Internet (IP) protocols
#
#       from: @(#)protocols     5.1 (Berkeley) 4/17/89
#
# Updated for NetBSD based on RFC 1340, Assigned Numbers (July 1992).

ip      0       IP              # internet protocol, pseudo protocol number
icmp    1       ICMP            # internet control message protocol
igmp    2       IGMP            # Internet Group Management
ggp     3       GGP             # gateway-gateway protocol
ipencap 4       IP-ENCAP        # IP encapsulated in IP (officially ``IP'')
st      5       ST              # ST datagram mode
tcp     6       TCP             # transmission control protocol
egp     8       EGP             # exterior gateway protocol
pup     12      PUP             # PARC universal packet protocol
udp     17      UDP             # user datagram protocol
hmp     20      HMP             # host monitoring protocol
xns-idp 22      XNS-IDP         # Xerox NS IDP
rdp     27      RDP             # "reliable datagram" protocol
iso-tp4 29      ISO-TP4         # ISO Transport Protocol class 4
xtp     36      XTP             # Xpress Tranfer Protocol
ddp     37      DDP             # Datagram Delivery Protocol
idpr-cmtp       39      IDPR-CMTP       # IDPR Control Message Transport
rspf    73      RSPF            # Radio Shortest Path First.
vmtp    81      VMTP            # Versatile Message Transport
ospf    89      OSPFIGP         # Open Shortest Path First IGP
ipip    94      IPIP            # Yet Another IP encapsulation
encap   98      ENCAP           # Yet Another IP encapsulation

/etc/networks

Il file /etc/networks ha una funzione simile a /etc/hosts. Il file è un semplice database che associa i nomi delle reti ai loro indirizzi. Il suo formato è differente da /etc/hosts in quanto ci sono solo due campi per riga, che sono codificati come:

  nome-rete indirizzo-di-rete
  

Per esempio, il file potrebbe assomigliare al seguente:

        loopnet    127.0.0.0
        localnet   192.168.0.0
        amprnet    44.0.0.0
        

Quando si usano comandi come route, se un indirizzo di destinazione è una rete e quella rete appare in/etc/networks, allora il comando mostrerà il nome della rete invece del suo indirizzo.

5.10 Sicurezza di rete e controllo degli accessi.

Vorrei iniziare questa sezione avvisando che la protezione di un calcolatore e di una rete da attacchi malevoli è un'arte complessa. Non mi considero assolutamente un esperto in questo campo: mentre i meccanismi che descrivo in seguito possono essere di aiuto, raccomando a chi prende seriamente il problema della sicurezza di fare qualche ricerca personale sull'argomento. Su Internet ci sono molti buoni documenti al proposito, compreso Security-HOWTO.

Una importante regola base è: `Non far girare i servizi che non si intendono usare'. Molte distribuzioni sono configurate per attivare ogni sorta di servizi, che vengono fatti partire automaticamente all'accensione della macchina. Per assicurare un livello di sicurezza minimale occorre passare in rassegna il proprio /etc/inetd.conf e commentare (mettendo un `#' all'inizio della riga) ogni voce relativa a servizi che non si intendono usare. Buoni candidati per questa operazione sono servizi come shell, login, exec, uucp, ftp, e servizi informativi come finger, netstat e systat.

Ci sono molti tipi di meccanismi di sicurezza e controllo degli accessi; qui descriverò solo i più elementari.

/etc/ftpusers

Il file /etc/ftpusers è un semplice meccanismo che permette di negare a certi utenti l'accesso via ftp alla macchina. Il file /etc/ftpusers viene letto dal demone ftp server (ftpd) quando vengono ricevute delle connessioni ftp in ingresso. Il file è semplicemente una lista di utenti a cui è impedito di collegarsi. Il file assomiglia al seguente:

        # /etc/ftpusers - users not allowed to login via ftp
        root
        uucp
        bin
        mail
        

/etc/securetty

Il file /etc/securetty permette di specificare a quali periferiche di tipo tty l'utente root può collegarsi. Il file /etc/securetty viene letto dal programma di login (di solito /bin/login). Il file è una lista di nomi di terminali ai quali root può collegarsi, mentre su tutti gli altri non è permesso di collegarsi come superutente:

        # /etc/securetty - tty's on which root is allowed to login
        tty1
        tty2
        tty3
        tty4
        

Il meccanismo di controllo degli accessi tcpd.

Il programma tcpd che avrete notato in /etc/inetd.conf fornisce i meccanismi di controllo degli accessi e di registrazione d'utilizzo (logging) per i servizi che protegge.

Quando viene invocato dal programma inetd, tcpd legge due file contenenti regole di accesso e di conseguenza permette l'accesso al servizio o lo rifiuta.

tcpd scandisce i file di regole finché non trova una corrispondenza. Se non ci sono corrispondenze valide, si assume che l'accesso sia permesso a tutti. I file che vengono scanditi in sequenza sono /etc/hosts.allow e /etc/hosts.deny. Li descriverò uno alla volta. Per una descrizione completa di questa funzionalità conviene riferirsi alle pagine del manuale (hosts_access(5) è un buon punto di partenza).

/etc/hosts.allow

Il file /etc/hosts.allow è uno dei file di configurazione del programma /usr/sbin/tcpd. hosts.allow contiene le regole che descrivono a quali calcolatori è permesso accedere ai servizi di questa macchina.

Il formato del file è molto semplice:

        # /etc/hosts.allow
        #
        # <lista servizi>: <lista calcolatori> [: comando]
        

lista servizi

è una lista delimitata da virgole di nomi di programmi server cui questa regola si applica. Esempi di nomi di server sono ftpd, telnetd e fingerd.

lista calcolatori

è una lista delimitata da virgole di nomi di host. Si possono, alternativamente, usare gli indirizzi IP. Si possono anche specificare nomi o indirizzi usando caratteri speciali per indicare gruppi di host. Per esempio, gw.vk2ktj.ampr.org corrisponde ad un host, .uts.edu.au indica tutti i nomi che terminano con questa stringa, 44. indica ogni indirizzo IP che inizia con 44. Ci sono alcune parole speciali per semplificare la configurazione, alcune delle quali sono: ALL per indicare tutti gli host, LOCAL per indicare gli host il cui nome non contiene un `.', cioè che sono nello stesso dominio di questa macchina, PARANOID indica tutti gli host il cui nome non corrisponde all'indirizzo (cioè nel caso sia in atto un `name spoofing'). Un'altra parola speciale che risulta utile è EXCEPT: permette di specificare una lista con delle eccezioni. Questo caso verrà coperto più avanti da un esempio.

comando

è un argomento opzionale. Questo parametro corrisponde al pathname completo di un comando che deve essere eseguito ogni volta che questa regola si applica. Per esempio potrebbe essere un comando che cerchi di identificare chi è collegato sul calcolatore che cerca di connettersi, o un comando che spedisce un messaggio di posta o altri avvertimenti all'amministratore di sistema riguardo al tentativo di connessione. Ci sono un certo numero di estensioni che possono essere incluse nel comando; alcuni esempi tipici sono: %h è il nome dell'host che cerca di collegarsi, o il suo indirizzo se il nome non può essere risolto, %d è il demone server che viene invocato.

Un esempio:

        # /etc/hosts.allow
        #
        # La posta è permessa e chiunque
        in.smtpd: ALL
        # telnet e ftp sono permessi solo a questo dominio e al mio
        # calcolatore di casa
        telnetd, ftpd: LOCAL, myhost.athome.org.au
        # finger è permesso a tutti, ma tenendo traccia di chi lo usa.
        fingerd: ALL: (finger @%h | mail -s "finger from %h" root)
        

/etc/hosts.deny

Il file /etc/hosts.deny è un file di configurazione del programma /usr/sbin/tcpd. Il file hosts.deny contiene le regole che descrivono a quali calcolatori non è permesso di accedere un servizio sul calcolatore locale.

Un semplice esempio potrebbe somigliare a questo:

        # /etc/hosts.deny
        #
        # Impedisci l'accesso a tutti i calcolatori con nomi sospetti
        ALL: PARANOID
        #
        # Impedisci l'accesso a tutti i calcolatori
        ALL: ALL
        

In realtà la voce PARANOID è ridondante perché l'altra voce si riferisce in ogni caso a tutti i calcolatori. L'uso di una di queste due voci potrebbe essere una scelta ragionevole, in base alle specifiche esigenze di controllo degli accessi.

La configurazione più sicura consiste nell'avere un default di ALL: ALL esplicito in /etc/hosts.deny ed abilitare esplicitamente in /etc/hosts.allow i servizi e gli host che si vogliono autorizzare.

/etc/hosts.equiv

Il file hosts.equiv viene usato per autorizzare alcuni calcolatori e alcuni utenti ad utilizzare gli account sulla macchina locale senza aver bisogno di fornire una password. Questo è utile in un ambiente sicuro, in cui si possano controllare tutte le macchine, ma è un grosso rischio in altre circostanze. Un calcolatore è sicuro solo tanto quanto lo è il meno sicuro dei calcolatori di cui ci si fida. Per massimizzare la sicurezza è bene non usare il meccanismo di hosts.equiv ed incoraggiare gli utenti a non usare nemmeno il file .rhosts.

Come configurare correttamente il server ftp.

Molti siti sono interessati ad offrire il servizio di ftp anonimo, per permettere ad altre persone di scaricare e depositare dei dati senza bisogno di un account specifico sulla macchina. Se si decide di offrire questo servizio bisogna assicurarsi di configurare correttamente il server ftp per l'accesso anonimo. La maggior parte delle pagine del manuale disponibili per ftpd(8) descrivono accuratamente come adempiere questo compito, e bisogna assicurarsi di seguire le istruzioni. Un consiglio importante è di non usare una copia del proprio file /etc/passwd nella directory /etc dell'account anonimo: bisogna assicurarsi di rimuovere tutti i dettagli tranne quelli necessari, altrimenti si diventa vulnerabili alle tecniche di rottura delle password "per forza bruta".

I firewall di rete.

Un eccellente modo per avere una certa sicurezza è impedire ai pacchetti di raggiungere il calcolatore che si intende proteggere. Questa tecnica è discussa in dettaglio nel Firewall-HOWTO, e (in forma concisa) in una sezione successiva di questo documento.

Altri suggerimenti.

Questi sono altri suggerimenti che val la pena di prendere in considerazione, anche se potenzialmente si prestano a guerre di religione.

sendmail

nonostante la sua popolarità, appare sugli annunci di attenzione alla sicurezza con impressionante regolarità. Dipende da voi, ma io preferisco non usarlo [un'ottima alternativa è postfix, si trova su mirror italiano di www.postfix.org N.d.T.].

NFS e altri servizi di tipo "Sun RPC"

bisogna fare attenzione: esistono un sacco di modi per sfruttare a fini malevoli questi servizi. È difficile trovare un'alternativa a servizi come NFS, ma se questi vengono abilitati bisogna fare estrema attenzione riguardo chi ha il permesso di montare i dischi della propria macchina.

Hosting by: hurra.com
Generated: 2007-01-26 17:56:13