È 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.
Prima di iniziare a costruire o configurare la propria rete occorrono alcune cose. Le più importanti di queste sono:
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 (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.
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
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:
Se si desidera installare un calcolatore su una rete esistente si deve contattare chi amministra tale rete e chiedere loro le seguenti informazioni:
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.
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.
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
-----------------------------------------
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.
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:
questa opzione attiva l'interfaccia (ed è l'impostazione di default).
questa opzione la disattiva.
questa opzione abitita o disabilita l'uso del protollo ARP ("Address Resulution Protocol") per questa interfaccia.
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.
questo parametro permette di assegnare il valore MTU ("Maximum Transfer Unit") per questa periferica.
questo parametro permette di specificare la maschera relativa alla rete cui questa interfaccia appartiene.
questo parametro funziona solo con certi tipi di hardware e permette di scegliere la linea interruzione usata dall'hardware di questa interfaccia.
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.
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.
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.
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.
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:
Organizzazioni commerciali
Organizzazioni educative
Organizzazioni governative
Organizzazioni militari
Altre organizzazioni
Organizzazioni connesse a Internet
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.
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.
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:
questa direttiva specifica il nome del dominio locale.
questa direttiva specifica una lista di domini da consultare in alternativa.
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.
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.
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.
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).
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.
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.
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:
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:
. 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.
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.
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
è una singola parola che rappresenta il servizio che si sta descrivendo.
questo campo è diviso in due sottocampi.
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.
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.
altri nomi che possono essere usati per indicare questo servizio.
Tutto il testo che appare in una riga dopo un carattere `#' è
trattato come commento.
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.
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
è il servizio al quale si riferisce questa
riga, è cioè uno dei nomi che stanno nel file
/etc/services.
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.
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.
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.
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.
questo campo è il percorso completo (pathname) del programma server che deve essere eseguito in relazione a questo servizio.
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.
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
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.
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/networksIl 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.
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.
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
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 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).
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)
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.
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.
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".
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.
Questi sono altri suggerimenti che val la pena di prendere in considerazione, anche se potenzialmente si prestano a guerre di religione.
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.].
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.