PREPARAZIONE ALLA CERTIFICAZIONE LPIC 202

Copyright © 2004 Truelite Srl <info@truelite.it> - http://www.truelite.it

Copyright © 2004 Eugenia Franzoni

Copyright © 2004 Daniela Paolotti

Coordinamento redazionale: Christopher R. Gabriel <cgabriel@truelite.it>

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation; with no Invariant Sections, with no Front-Cover Texts, and with no Back-Cover Texts. A copy of the license can be found on Free Software Foundation's web site http://www.fsf.org.

Contenuti

2.205.1 - Configurazione di base della rete	7

ifconfig	7

route	7

I file di configurazione	8

arp	9

arpwatch	10

mgetty	10

Configurazione di PAP	11

Configurazione di CHAP	12

Assegnazione degli indirizzi IP con PPP	12

2.205.2 Configurazione avanzata di rete e soluzione di problemi	12

ifconfig	12

route	14

routed	14

lsof	16

nc - netcat	17

tcpdump	17

ping	22

Esempi	23

netstat	24

2.206.2 - Sendmail	26

Configurazione di Sendmail	27

Riscrittura degli indirizzi	28

Alias	29

Domini virtuali	30

2.206.3 - Gestione del traffico di posta	31

Assegnazioni	32

Regole o “ricette”	33

Espressioni regolari	34

2.206.4 - Configurazione e installazione di un server di News	35

Programmi che operano nel contesto di innd	36

Configurazione di inn	36

2.207.1 - Configurazione di base di BIND	39

File di configurazione	39

Configurazione dei log	39

Configurazione delle opzioni	42

Indicazione dei server	43

La routine di supervisione ndc	43

Controllo del nameserver tramite segnali	44

2.207.2 - Creazione ed amministrazione delle zone del DNS	44

I file delle zone	45

Il record SOA	46

Record NS e MX	47

Le voci degli indirizzi IP nel file di zona diretto	48

Le voci del file inverso	48

I programmi dig, nslookup e host	48

I comandi interattivi di nslookup	49

Opzioni interattive di nslookup	49

Esempi di uso del comando dig	49

Esempi di uso del comando host	50

2.207.3 - Creare un server DNS sicuro	50

Esecuzione di BIND con privilegi di utente normale	50

Esecuzione di BIND sotto chroot	51

Uso delle dichiarazioni DS	52

Configurazione separata per i DNS forwarding	53

Cambiamento del numero di versione	54

2.208.1 - Implementazione di un server Web	55

Configurazione dei log del server	55

L'istruzione LogFormat	55

Configurazione di mod_perl	56

Configurazione di mod_php	57

Supervisione degli accessi da determinati computer	58

Autenticazione degli utenti con mod_auth	59

2.208.2 - Amministrazione di un server Web	63

I certificati SSL	64

Attivazione dell'SSL	65

Ulteriori informazioni su Apache SSL	65

La direttiva Redirect	65

2.208.3 - Implementazione di un server proxy	66

Controllo degli accessi con le ACL	67

Autenticazione degli utenti	70

Ulteriori informazioni su Squid	70

2.212.2 Configurazione di un router	71

Significato degli indirizzi privati per quanto riguarda la sicurezza	71

NAT/Masquerading	71

Attivazione del masquerading con ipchains	72

Attivazione del masquerading con iptables	72

Port forwarding	72

Port forwarding con ipchains	73

Port forwarding con iptables	73

Definizione delle regole del firewall	73

Regole formulate con ipchains	74

Regole formulate con iptables	74

2.212.3 Sicurezza dei server ftp	77

Accesso FTP per gli utenti	77

Accesso FTP anonimo	77

Possibilità di upload per l'utente anonimo	79

Controllo e configurazione degli accessi	79

Formazione delle classi	79

Caratteristiche delle classi	80

Altre regole di accesso	81

Configurazioni globali	82

Messaggi	82

Server FTP virtuali	83

Gruppi con ftpgroups	83

2.212.4 Secure shell (OpenSSH)	84

Architettura di SSH	84

Autenticazione	84

Generazione delle chiavi	86

Generazione della coppia di chiavi di un utente	86

Generazione di una coppia di chiavi host	87

Configurazione del server in sshd_config	88

Opzioni per l'autenticazione	88

Opzioni per la costruzione di tunnel	90

Tunneling di applicazioni non sicure	91

2.212.5 TCP_wrappers	92

La forma classica dei wrapper TCP	92

La forma più moderna del wrapper	94

2.212.6 - Gestione della sicurezza	95

Kerberos	95

Mailing list sulla sicurezza	96

Tripwire	96

Snort	96

Snort come sniffer	96

Snort come packet logger	96

Snort come IDS	97

Nmap	97

2.210.1 Configurazione del DHCP	99

Le basi	99

Configurazione statica e dinamica	100

Periodo di validità degli indirizzi assegnati dinamicamente	101

La configurazione in dhcpd.conf	101

2.210.2 Configurazione del NIS	105

I domini NIS	105

Configurazione di un server NIS	106

Creazione dei file di mappa	106

Sicurezza contro gli accessi esterni	106

Il file di configurazione /etc/ypserv.conf	107

Configurazione dei client NIS	107

Test della configurazione	108

Uso dei file delle mappe invece dei dati locali	108

Altri programmi legati a NIS	111

Implementare un server NIS slave	111

Gruppi di reti	112

Ulteriori informazioni sul NIS	113

2.210.3 Configurazione di LDAP	113

Cosa è un servizio di directory?	113

Configurazione di LDAP	114

Direttive generali	115

Direttive generali per i backend	116

Direttive generali sui database	117

Direttive per i database BDB	118

Creazione e manutenzione di un database	119

Creazione di un database online	119

Il formato LDIF	121

2.210.4 Autenticazione con PAM	123

Sintassi dei file PAM	123

Il file other	124

I principali moduli di PAM	125

2.214.7 Risoluzione dei problemi di rete	127

2.205.1 - Configurazione di base della rete

ifconfig

Ifconfig è usato per configurare le interfacce di rete supportate dal kernel. Viene utilizzato al momento del boot per configurare le interfacce e successivamente è utile solo per il debugging o per la configurazione del sistema. Se viene lanciato senza specificare nessun argomento, ifconfig mostra le interfacce di rete che risultano attive in quel momento. Se come argomento viene fornito il nome di un'interfaccia, allora ifconfig mostra soltanto lo stato relativo ad essa, mentre l'argomento -a mostra lo stato di tutte le interfacce, anche quelle non attive.

Normalmente viene invocato un comando simile al seguente:

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 netmask pari a `255.255.255.0'. La parola `up' finale corrisponde al fatto 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, nel momento in cui un'interfaccia venga configurata. Per esempio, per ciascuna interfaccia si può specificare l'indirizzo di rete e quello di broadcast; se questo non viene fatto, come nell'esempio precedente, il kernel farà delle scelte ragionevoli per i valori da assegnare in base alla netmask fornita; se questa non viene specificata, il kernel 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.

route

Route gestisce le tabelle di routing IP del kernel. Il suo uso primario riguarda la configurazione di route statiche a specifici host o reti attraverso un'interfaccia configurata tramite ifconfig.

Nel caso in cui si usino le opzioni del o add, route modifica le tabelle di routing. Senza di esse, route mostra il contenuto attuale delle tabelle di routing.

Passiamo ora ad un semplice esempio, immaginando di essere connessi ad una ethernet e di sapere che la rete è una classe C con indirizzo 192.168.1.0; supponiamo inoltre che l'indirizzo 192.168.1.10 sia stato assegnato alla propria 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 come:

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 fare ciò sarà:

route add -net 192.168.1.0 netmask 255.255.255.0 eth0

Si noti l'uso dell'argomento `-net', il quale 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 specifica di instradamento verso un singolo indirizzo IP.

La regola di instradamento appena mostrata è quella che permette di stabilire connessioni con tutti gli host del proprio segmento ethernet. . La regola "di default" si riferisce a tutti gli indirizzi di destinazione e viene aggiunta in fondo alle altre, in modo che venga usata solo quando non ne esistano altre corrispondenti. Nell'esempio di cui ci stiamo occupando si userà un comando come:

route add default gw 192.168.1.1 eth0

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

Perciò, la configurazione completa sarà:

ifconfig eth0 192.168.1.10 netmask 255.255.255.0 up

route add -net 192.168.1.0 netmask 255.255.255.0 eth0

route add default gw 192.168.1.1 eth0

I file di configurazione

I comandi ifconfig e route vengono usati manualmente per le configurazioni, ma le impostazioni relative non vengono memorizzate tra un riavvio e l'altro della macchina. In Debian GNU/Linux, tali impostazioni vengono messe nei file di configurazione dello script di inizializzazione /etc/init.d/networking, cioè in /etc/network/interfaces.

Tale file ha la seguente sintassi:

# /etc/network/interfaces -- configuration file for ifup(8),

#ifdown(8)

# The loopback interface

auto lo eth0

iface lo inet loopback

iface eth0 inet static

address 192.168.1.2

network 192.160.1.0

netmask 255.255.255.0

broadcast 192.168.1.255

gateway 192.168.1.1

La prima riga indica quali interfacce attivare automaticamente all'avvio; nel nostro caso sono l'interfaccia localhost e la prima scheda ethernet.

Le sezioni indicate con "iface" sono relative alle varie interfacce. La prima, lo, è l'interfaccia di loopback. La seconda, eth0, è la prima scheda ethernet. Per quest'ultima vengono indicati l'indirizzo IP (address), l'indirizzo della rete di cui fa parte (network), la relativa maschera di rete (netmask), l'indirizzo di broadcast (broadcast) e l'eventuale gateway di default (gateway).

All'avvio del sistema, viene eseguito il comando

/etc/init.d/networking start

e quindi vengono attivate le interfacce indicate. Se si cambia la configurazione nel file interfaces, quindi, perché il cambiamento venga reso effettivo si deve riavviare lo script con:

/etc/init.d/networking restart

arp

Questa istruzione viene utilizzata per la gestione della cache ARP nel Kernel. Una cache ARP è un archivio in cui vengono mappati gli indirizzi IP con indirizzi a livello link. Una cache ARP permette di evitare conversazioni del tipo richiesta/risposta per ciascun pacchetto IP scambiato. Naturalmente questa efficienza ha un prezzo: ciascun host mantiene la propria cache ARP, la quale però può diventare obsoleta quando l'host venga rimpiazzato o quando un indirizzo IP venga spostato da un host all'altro. La cache ARP è conosciuta anche come tavola dei vicini.

Tramite l'istruzione arp è possibile eliminare una singola cache ARP o aggiungerne a mano di nuove; è anche possibile lo svuotamento di tutta la cache.

Le azioni abitualmente effettuate sono le seguenti:

Annuncio della cache ARP

Utilizzando le sole istruzioni ARP, il contenuto della cache corrisponde quasi completamente a quello del file /proc/net/arp. In alternativa si può leggere il contenuto intero della cache in formato BSD con:

arp -a

In entrambi i casi si può indicare il nome di un host (oppure un indirizzo IP) in modo da avere solo la voce relativa al singolo host. L'opzione:

- n

forza la visualizzazione dell'indirizzo IP invece che del nome.

Eliminazione di una voce dalla cache

Con arp -d hostname oppure arp --delete hostname viene rimossa dalla cache la voce corrispondente all'hostname specificato. In alternativa all'hostname si può specificare l'indirizzo IP.

Inserimento di una voce nella cache

Con l'istruzione arp -s hostname MACaddress e/o arp --set hostname MACaddress si può inserire manualmente una voce nella cache. Il MAC address sarà nel formato xx:xx:xx:xx:xx:xx e potrà essere indicato al posto dell'indirizzo IP.

Impostazione delle voci della cache da un file

Con l'opzione -f nomefile e/o --file nomefile i dati vengono letti da un file e messi nella cache. Il file deve seguire la sintassi:

Hostname MACaddress

Inoltre si possono utilizzare le flag temp, pub e netmask. Il nome del file dei dati è spesso /etc/ethers, ma non obbligatoriamente. Se non viene specificato nessun nome, di default allora viene usato /etc/ethers.

Ciascuna voce completa nella cache ARP verrà marcata con la flag C. Le voci permanenti possiedono inoltre la flag M, mentre quelle pubblicate sono marcate con una P.

arpwatch

arpwatch è un demone che supervisiona al trasferimento di pacchetti via rete e segnala l'arrivo di eventuali pacchetti falsificati. Il messaggio giunge tramite e-mail all'amministratore o all'indirizzo specificato dal parametro -m email.

Si deve notare che arpwatch non funziona se non esiste il file /var/lib/arpwatch/arp.dat. Prima di effettuare la prima chiamata si deve creare questo file, anche vuoto. In tal modo saranno segnalati i nuovi computer che verranno posti in rete insieme alle eventuali ambiguità (ad esempio nei MAC address o negli indirizzi IP).

mgetty

Per poter fare login in un computer via modem, si deve configurare una getty sull'interfaccia del modem. Di solito, a questo scopo, si usa una speciale getty per il modem (mgetty), che ha il vantaggio di riconoscere automaticamente se la chiamata in arrivo trasmette dei dati o un fax. Se la trasmissione è di dati, la getty restituisce un normale messaggio di login.

Per far partire tale processo getty, si deve inserire una voce per ciascuna interfaccia nel file /etc/inittab.

Tale voce avrà la forma:

m1:123:respawn:/usr/sbin/mgetty opzioni

mgetty possiede alcuni importanti parametri che sono, di solito:

x LivelloDebug

Controlla la quantità di informazione di diagnostica. I possibili valori di LivelloDebug sono i numeri da 0 (nessun messaggio) a 9 (eccesso di messaggi).

n numero

mgetty risponde dopo numero squilli.

s velocità

Stabilisce la velocità della porta utilizzata, ad es. -s 3840

m ' stringa da inviare... '

Imposta la sequenza di chat da usare per inizializzare il modem.

Se non se ne vuole indicare una, si usino le virgolette vuote ("").

Dato che la sequenza contiene degli spazi, la si deve racchiudere tutta tra apici singoli.

ttydevice

Deve obbligatoriamente essere indicato come ultimo parametro; è il file di device dell'interfaccia su cui è collegato il modem.

A questo punto si può scegliere di aprire una sessione PPP; in questo caso mgetty deve essere compilato con l'opzione -DAUTO_PPP. In tal modo mgetty rileva i pacchetti PPP ricevuti ed esegue il programma indicato in login.conf con lo speciale nomeutente "/AutoPPP/"; ad esempio:

/AutoPPP/ - ppp /usr/sbin/pppd auth login +pap -chap modem crtscts LOCK,

Nel caso in cui il demone PPP venga inizializzato da pppd di mgetty, verrà usato il file /etc/ppp/options.server in cui sono indicate tutte le opzioni del demone PPP.

Configurazione di PAP

PAP (Password Authentication Protocol) è una delle due modalità di autenticazione che PPP può usare. Poiché PPP è tecnicamente visto come un Peer to Peer, le autenticazioni sono possibili in entrambi i versi, anche se ciò non è obbligatorio.

Nel file /etc/ppp/options.server devono essere presenti le istruzioni:

+pap

oppure

require pap

In tal modo vengono controllati i nomi degli utenti e le password nelle voci del file

/etc/ppp/pap secrets.

Tale file ha la seguente sintassi:

# client server segreti indirizzi

Per rendere possibile solo l'autenticazione dei client si possono semplicemente indicare tutti i server mettendo un asterisco. Ugualmente si può dare una configurazione per tutti gli indirizzi sostituendo la parola relativa con un asterisco.

In questo caso tuttavia, se non vengono usati gli asterischi, l'accesso è consentito solo se arriva la chiamata dall'indirizzo appropriato.

Se invece viene utilizzato /etc/passwd, allora si deve indicare per pppd l'opzione login.

Il file /etc/ppp/pap-secrets non deve necessariamente già esistere.

Configurazione di CHAP

Assegnazione degli indirizzi IP con PPP

Perché ppp funzioni, al client deve essere assegnato un indirizzo dinamico. Questa indicazione può essere posta nel file /etc/ppp/options.server oppure in /etc/ppp/options.ttySn. nella semplice forma:

Server_IP:Client_IP

Il primo è l'indirizzo IP del server, cioè il proprio, mentre il secondo viene assegnato all'interfaccia (e quindi al client). Si noti che è assolutamente necessario che il secondo indirizzo IP sia un indirizzo valido della LAN e che non sia ancora stato usato da nessun altro dispositivo.

2.205.2 Configurazione avanzata di rete e soluzione di problemi

ifconfig

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

up

attiva l'interfaccia (ed è l'impostazione di default)

down

disattiva l'interfaccia

[-]arp

abilita o disabilita l'uso del protollo ARP ("Address Resolution Protocol") per questa interfaccia

[-]allmulti

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

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

netmask addr

permette di specificare la netmask relativa alla rete cui questa interfaccia appartiene.

irq addr

funziona solo con certi tipi di hardware e permette di scegliere l'irq usato dall'hardware dell'interfaccia.

[-]broadcast [addr]

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

[-]pointopoint [addr]

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>

permette di assegnare l'indirizzo hardware (MAC address) di certi tipi di schede di rete. Questo è spesso inutile per per le interfacce 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.

route

Vediamo ora una configurazione dell'instradamento leggermente più complicata. Immaginiamo di configurare un router con una connessione PPP verso Internet e tre segmenti ethernet verso i pc nell'ufficio. La nostra configurazione di routing sarà:

route add -net 192.168.1.0 netmask 255.255.255.0 eth0

route add -net 192.168.2.0 netmask 255.255.255.0 eth1

route add -net 192.168.3.0 netmask 255.255.255.0 eth2

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 relative 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à, perciò 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.

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.

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 smettono 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 a rischio di fallimento. 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".

I più comuni protocolli dinamici sono RIP (Routing Information Protocol) e OSPF (Open Shortest Path First). Il protocollo RIP è molto comune nelle piccole reti, 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 risulta 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' fa parte del pacchetto omonimo.

Un esempio di dove e quando serva usare un protocollo di instradamento dinamico potrebbe essere:

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 quindi un triangolo.

Nella tabella di routing per il router A dovrebbe essere presente qualcosa come:

route add -net 192.168.1.0 netmask 255.255.255.0 eth0

route add -net 192.168.2.0 netmask 255.255.255.0 ppp0

route add -net 192.168.3.0 netmask 255.255.255.0 ppp1

Questa situazione funziona bene, finché non si interrompa il collegamento tra il router A e il router B. Se la connessione si interrompesse, 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 ultimi possono 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 verrebbero corrette automaticamente per riflettere il nuovo stato della rete ogniqualvolta uno dei collegamenti della rete si interrompa. Configurare questa rete è semplice: occorre fare solo due cose su ognuno dei router. In questo caso, per A bisogna invocare il comando:

route add -net 192.168.1.0 netmask 255.255.255.0 eth0

/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 tabella di routing ed aggiornarla.

lsof

lsof (List Open Files) elenca informazioni dettagliate circa i file aperti o in uso.

Nel campo della soluzione dei problemi di rete, c'è un'opzione particolarmente importante, che indica quali file sono stati aperti sopra una specifica connessione di rete.

L'opzione è i [indirizzo].

Se l'indirizzo viene omesso, vengono riportati tutti i file che sono stati aperti su connessioni di rete.

Per indicare solo i file appartenenti a determinate connessioni, occorre fornire un indirizzo nella forma:

[Protocollo][@nomehost|indirizzo][:servizio|porta]

Quindi occorre scegliere come protocollo tcp o udp (icmp infatti non apre file), seguito da @ e dal nome host o dal suo indirizzo IP. E' possibile specificare ulteriormente, aggiungendo un due punti ':' seguito dal numero di porta o dal nome del servizio, così come definito nel file /etc/services.

I servizi e/o i numeri di porta possono essere indicati come lista (separati da virgole e senza spazi).

E' anche possibile indicare i numeri soto forma di intervallo nella forma 12-24.Gli intervalli sono quindi rappresentati da un segno meno ('-').

Siccome anche i nomi dei servizi contenuti in "/etc/services" possono contenere segni '-', l'inizio di un intervallo può essere indicato solo come numero, e non come nome di servizio.

Tutte le specifiche di indirizzo sono opzionali.

Almeno uno dei componenti dell'indirizzo (protocollo, specifica dell'host, servizio o porta) deve essere necessariamente indicato.

Il carattere '@' è sempre richiesto all'inizio dell'indicazione dell'host, così come il carattere ':' all'inizio dell'indicazione della porta.

nc - netcat

Il programma nc (netcat) è considerato il coltellino svizzero del TCP/IP, data la sua importanza come strumento di diagnosi delle tecnologie di rete.

La sua funzione principale è semplicemente quella di connettere lo standard input/output in maniera simile a ciò che fa il programma "cat" con i file, ma con una combinazione computer/porta.

La sintassi più semplice per invocare nc è quindi:

nc nomecomputer porta

che stabilisce un canale TCP verso il computer indicato (è possibile specificarne sia il nome che l'indirizzo IP) alla porta specificata (sotto forma di numero di porta o di nome di servizio come riportato nel file /etc/services).

Tutto ciò che viene letto sullo standard input viene inviato su questo canale, così come tutto ciò che nc riceve sul canale TCP viene rappresentato sullo schermo.

Inoltre, nc può aprire connessioni UDP specificando l'opzione -u, cosa che lo rende uno strumento più generico di altri progammi come telnet.

Siccome nc agisce come programma filtro (utilizzando i canali di standard input/output), può essere utilizzato in combinazione con altri programmi, come fosse una pipe.

Contrariamente a telnet, nc può gestire correttamente stream di dati binari.

tcpdump

Tcpdump è lo strumento fondamentale per l'analisi del traffico che avviene nella rete fisica a cui si è collegati. Permette sia di ottenere una visione sintetica dei pacchetti, sia di visualizzarne il contenuto in cifre esadecimali. Inoltre, è possibile definire un filtro ai pacchetti da prendere in considerazione. Il suo utilizzo efficace richiede un'ottima conoscenza dei protocolli TCP/IP.

I pacchetti vengono analizzati solo nella prima parte, normalmente di 68 byte, perdendo le informazioni successive. Eventualmente, questa dimensione può essere aumentata, anche se in generale ciò è sconsigliabile dal momento che richiederebbe un tempo di elaborazione maggiore, portando anche alla perdita di pacchetti.

Tcpdump può generare un risultato in esadecimale, oppure può emettere i pacchetti così come sono. Per poter interpretare il contenuto dei pacchetti, è necessario conoscere la loro struttura, in base ai protocolli relativi.

tcpdump emette le informazioni tratte dalla parte iniziale dei pacchetti che possono essere intercettati attraverso un'interfaccia di rete e che corrispondono a una data espressione. L'uso normale è quindi:

tcpdump [opzioni] [espressione]

Opzione	Descrizione
-i interfaccia	Definisce l'interfaccia di rete attraverso cui tcpdump deve porsi in ascolto. Se non viene specificata, tcpdump sceglie la prima, ma potrebbe trattarsi anche di lo (loopback).
-l	Filtra l'output attraverso una memoria tampone, in modo da gestire meglio le pipeline.
-n	Fa in modo di non convertire gli indirizzi numerici e i numeri di porta nei nomi corrispondenti.
-s n_byte	Permette di definire esplicitamente la quantità di byte da prendere in considerazione per ogni pacchetto. In modo predefinito vengono trattati solo i primi 68 byte.
-w file	Memorizza i pacchetti grezzi all'interno di un file, invece di analizzarli ed emetterne il risultato. Il contenuto di questo file può essere elaborato successivamente con l'opzione -r.
-r file	Legge i pacchetti da quanto accumulato precedentemente in un file attraverso l'opzione -w. In pratica, permette di analizzare quanto raccolto in precedenza.
-x	Si limita a emettere i pacchetti in forma esadecimale. Per la precisione, viene emessa solo la parte dei pacchetti che rientra nel limite fissato con l'opzione -s, ovvero i primi 68 byte se questa non è stata indicata.
-F file	Permette di fornire l'espressione di filtro dei pacchetti attraverso un file indicato con questa opzione.

Segue la descrizione di alcuni esempi.

tcpdump -i eth0

Emette attraverso lo standard output tutto il traffico che può essere intercettato per mezzo dell'interfaccia eth0.

tcpdump -n -i eth0

Come nell'esempio precedente, ma le informazioni sugli indirizzi e sui numeri di porta vengono indicati in forma numerica.

tcpdump -x -i eth0

Emette attraverso lo standard output il contenuto della prima parte dei pacchetti che possono essere intercettati per mezzo dell'interfaccia eth0. Questi dati vengono espressi in forma esadecimale.

L'utilizzo di tcpdump non è molto utile se non viene definito un filtro per ciò che si vuole analizzare. Per questo motivo, dopo le opzioni normali della riga di comando può essere indicata un'espressione, più o meno articolata: solo i pacchetti che soddisfano la condizione espressa vengono presi in considerazione.

Questa espressione contiene spesso degli spazi: può essere fornita a tcpdump come argomento unico utilizzando dei delimitatori, oppure può essere composta da più argomenti in sequenza. Inoltre, attraverso l'opzione -F è possibile fornire l'espressione contenuta in un file; in tal caso, l'espressione può essere scritta su più righe, senza bisogno di simboli di continuazione.

Le espressioni di tcpdump sono composte da primitive che possono essere raggruppate per mezzo delle parentesi tonde (in modo da evitare ambiguità nell'ordine di risoluzione) e connesse attraverso operatori booleani

! | not	un punto esclamativo o la parola chiave not rappresenta la negazione logica;
&& | and	una doppia e-commerciale (&&) o la parola chiave and rappresenta il concatenamento, ovvero un AND logico;
|| | or	una doppia barra verticale (||) o la parola chiave or rappresenta l'alternanza, ovvero un OR logico.

All'interno delle primitive possono apparire riferimenti a diversi tipi di entità, che vengono descritte brevemente.

Gli indirizzi di origine o di destinazione, riferiti al protocollo TCP/IP, possono essere indicati attraverso nomi di dominio o numeri IP. In particolare, è possibile fare riferimento a una sottorete indicando il numero IP parziale.

Le porte possono essere identificate per numero o per nome.

Per identificare i protocolli si possono usare delle parole chiave precise; in particolare: ether, fddi, ip, arp, rarp, decnet, tcp, udp.

Il protocollo identificato dalle parole chiave elencate dovrebbe essere intuitivo, almeno per i casi più comuni (IP, ARP, RARP, TCP e UDP). Le prime due parole chiave sono equivalenti: ether e fddi rappresentano semplicemente il secondo livello, collegamento dati, del modello ISO-OSI.

Primitiva	Descrizione
dst host nodo src host nodo host nodo	Se viene usata la parola chiave dst, la regola è valida se il campo della destinazione IP corrisponde al nodo indicato; se viene usata la parola chiave src, la regola è valida se il campo dell'origine IP corrisponde al nodo indicato; altrimenti, in mancanza di tali parole chiave, la regola è valida se il nodo corrisponde indifferentemente all'origine o alla destinazione.
ether dst nodo_ethernet ether src nodo_ethernet ether host nodo_ethernet	Definisce un indirizzo Ethernet numerico o derivato dal contenuto del file /etc/ethers. Come si può intuire, nel primo caso si fa riferimento a una destinazione, nel secondo a un'origine, nel terzo non si fa differenza.
gateway nodo	La regola è valida nel caso i pacchetti utilizzino il nodo indicato come gateway, ovvero, quando l'indirizzo Ethernet dell'origine o della destinazione non appartiene né all'indirizzo IP dell'origine, né a quello della destinazione.
dst net rete src net rete net rete	Se viene usata la parola chiave dst, la regola è valida se il campo della destinazione IP appartiene alla rete indicata; se viene usata la parola chiave src, la regola è valida se il campo dell'origine IP appartiene alla rete indicata; altrimenti, in mancanza di tali parole chiave, se la rete corrisponde indifferentemente all'origine o alla destinazione. La rete può essere indicata con un numero IP incompleto, oppure attraverso l'aggiunta di una maschera di rete.
dst port porta src port porta port porta	Definisce una porta TCP o UDP, trattandosi rispettivamente di un'origine, di una destinazione, o di entrambe le cose indifferentemente.
less lunghezza greather lunghezza	La regola è valida se la dimensione del pacchetto è inferiore o uguale, oppure maggiore o uguale alla quantità di byte indicata.
ether proto protocollo	Definisce la selezione di un protocollo Ethernet attraverso un numero oppure un nome: ip, arp, rarp. Dal momento che questi nomi sono anche parole chiave per tcpdump, vanno indicati facendoli precedere da una backslash (\) (ciò tenendo conto anche del tipo di shell utilizzato; nel caso della shell Bash e di altre, occorre raddoppiare la backslash).
ip proto protocollo	Definisce la selezione di un protocollo IP attraverso un numero, oppure un nome: icmp, igrp, udp, nd, tcp. Tuttavia, i nomi icmp, tcp e udp vanno preceduti da una backslash (\) per evitare che vengano interpretati in modo speciale da tcpdump.
[ether] broadcast	Vale se il pacchetto è di tipo Ethernet broadcast.
ip broadcast	Vale avvera per un pacchetto IP broadcast.
[ether] multicast	Vale se il pacchetto è di tipo Ethernet multicast.
ip multicast	Vale per un pacchetto IP multicast.

Segue la descrizione di alcuni esempi.

tcpdump host qui.pippo.xyz

Individua ed emette tutto il traffico riferito a qui.pippo.xyz.

tcpdump host qui.pippo.xyz and host quo.pluto.xyz

Individua ed emette tutto il traffico riferito simultaneamente a qui.pippo.xyz e a quo.pluto.xyz. In pratica si limita a estrarre il traffico tra questi due nodi.

tcpdump host qui.pippo.xyz and \(host quo.pluto.xyz or qua.pluto.xyz\)

Individua esclusivamente il traffico intrattenuto tra qui.pippo.xyz e quo.pluto.xyz, oppure tra qui.pippo.xyz e qua.pluto.xyz. Le parentesi tonde sono state protette con una backslash per evitare una diversa interpretazione da parte della shell.

tcpdump host qui.pippo.xyz and not host quo.pluto.xyz

Analizza tutto il traffico intrattenuto da qui.pippo.xyz e tutti gli altri nodi, a esclusione di quo.pluto.xyz.

tcpdump gateway qui.pippo.xyz

Analizza tutto il traffico che attraversa il nodo qui.pippo.xyz senza essere diretto, o provenire da quello.

ping

ping [opzioni] indirizzo

ping permette di inviare una richiesta di eco a un indirizzo, utilizzando il protocollo ICMP, verificando di ricevere tale eco in modo corretto. ping viene usato quasi sempre senza opzioni, in modo da ottenere una richiesta di eco continuo, a intervalli di un secondo, che può essere interrotta attraverso la tastiera con la combinazione [Ctrl+c]. Tuttavia, dal momento che ping serve a scoprire dei problemi negli instradamenti e nel sistema di trasporto generale, può essere conveniente intervenire sulla dimensione dei pacchetti trasmessi e sul loro contenuto.

Alcune opzioni:

-c quantità

Conclude il funzionamento di ping dopo aver ricevuto il numero indicato di risposte.

-f

Invia la maggior quantità possibile di pacchetti di richiesta, limitandosi a segnalare graficamente la quantità di quelli che risultano persi, cioè per i quali non si ottiene l'eco di risposta. Serve per analizzare pesantemente un tratto di rete, tenendo conto che questa possibilità va usata con prudenza. Proprio a causa della pericolosità di tale opzione, questa può essere richiesta solo dall'utente root.

-i n_secondi_pausa

Permette di stabilire una pausa, espressa in secondi, tra l'invio di una richiesta di eco e la successiva. Se non viene utilizzata l'opzione -f, il valore predefinito di questa è di un secondo.

-p stringa_di_riempimento

Permette di aggiungere un massimo di 16 byte ai pacchetti utilizzati da ping, specificandone il contenuto in esadecimale. Ciò può essere utile per verificare il passaggio di pacchetti che hanno contenuti particolari e che per qualche ragione possono avere delle difficoltà.

-s dimensione

Permette di definire la dimensione dei pacchetti utilizzati, a cui si aggiunge l'intestazione ICMP. Il valore predefinito è di 56 byte a cui si aggiungono 8 byte di intestazione (64 in tutto).

Esempi

ping 192.168.1.1

Invia una richiesta di eco all'indirizzo 192.168.1.1, a intervalli regolari di un secondo, fino a che riceve un segnale di interruzione.

ping -c 1 192.168.1.1

Invia una richiesta di eco all'indirizzo 192.168.1.1 e termina di funzionare quando riceve la prima risposta di eco.

ping -p ffffffff 192.168.1.1

Invia una richiesta di eco all'indirizzo 192.168.1.1, utilizzando pacchetti contenenti una serie di 32 bit a uno

ping -s 30000 192.168.1.1

Invia una richiesta di eco all'indirizzo 192.168.1.1, utilizzando pacchetti lunghi 30 000 byte, oltre all'intestazione ICMP.

netstat

Netstat è un programma specifico di GNU/Linux, in grado di mostrare in modo agevole alcune informazioni contenute nella directory /proc/net/.

Le informazioni disponibili riguardano esclusivamente la sfera del nodo locale, comprese le connessioni che lo riguardano.

netstat potrebbe essere utilizzato per fornire le stesse informazioni che si possono ottenere già da route, ifconfig e in parte da iptables. In generale, comunque, questo non dovrebbe essere il suo uso normale, che qui non viene mostrato.

L'eseguibile netstat emette attraverso lo standard output una serie di notizie riferite a tutti i tipi di connessione disponibili, traendo le informazioni dai file virtuali della directory /proc/net/.

netstat [opzioni]

Se netstat viene usato senza opzioni, mostra la situazione di tutti i tipi di collegamento, elencando i socket aperti. Se tra le opzioni appare l'indicazione di uno o più protocolli, le informazioni che si ottengono si limitano a quanto richiesto espressamente.

Opzione	Descrizione
-t|--tcp	Richiede espressamente lo stato delle connessioni TCP.
-u|--udp	Richiede espressamente lo stato dei socket che utilizzano il protocollo UDP.
--inet|--ip	Richiede espressamente le informazioni che riguardano l'uso dei protocolli TCP/IP.
-e	Richiede di aggiungere l'indicazione dell'utente proprietario del processo relativo.
-o	Richiede di aggiungere l'indicazione dei timer di rete.
-a	Elenca tutte le porte utilizzate, incluse quelle dei server in ascolto.
-n	Mostra le informazioni in forma numerica: indirizzi IP, numeri di porta, numeri UID.

Segue la descrizione di alcuni esempi.

netstat --inet

Emette l'elenco dei socket di dominio Internet, ovvero tutte le comunicazioni aperte tra i programmi attraverso i protocolli TCP/IP.

netstat --inet -e

Come nell'esempio precedente, aggiungendo l'indicazione degli utenti proprietari dei processi che attuano le connessioni.

netstat --tcp -a

Mostra la situazione delle porte TCP, in particolare quelle dei servizi in ascolto.

Gli elenchi restituiti da netstat sono composti in forma tabellare. Di seguito appare la descrizione dei nomi delle colonne.

Colonna	Stato	Descrizione
Proto		Rappresenta il protocollo utilizzato in ogni porta attiva. Può trattarsi di tcp, udp o raw.
Recv-Q, Send-Q		Rappresenta la coda di byte che sono stati ricevuti ma non ancora prelevati dal programma che utilizza la connessione, o che sono stati trasmessi ma per i quali non è stata ricevuta conferma dal nodo remoto.
Local Address, Foreign Address		Rappresenta rispettivamente l'indirizzo locale e quello remoto, completo dell'indicazione della porta relativa.
State		Rappresenta lo stato della porta, indicato attraverso una parola chiave tra quelle elencate di seguito. Lo stato riguarda prevalentemente le connessioni TCP, negli altri casi dovrebbe essere assente.
	ESTABLISHED	La porta ha una connessione in corso.
	SYN SENT	La porta sta tentando di instaurare una connessione.
	SYN RECV	È in corso l'inizializzazione della connessione.
	FIN WAIT1	La porta è chiusa e la connessione è in corso di conclusione.
	FIN WAIT2	La connessione è chiusa e la porta è in attesa della conferma dall'altra parte.
	TIME WAIT	La porta è in attesa della conferma della conclusione della connessione.
	CLOSED	La porta non è in uso.
	CLOSE WAIT	La parte remota conclude la connessione ed è in attesa di conferma dell'altra parte.
	LAST ACK	La parte remota chiude la connessione e la porta è chiusa: si è in attesa della conferma finale.
	LISTEN	La porta è in ascolto in attesa di connessioni in arrivo. Queste porte vengono indicate solo se si utilizza l'opzione -a.
	CLOSING	Entrambe le porte stanno chiudendo la connessione, ma i dati non sono stati inviati completamente.
	UNKNOWN	Lo stato della porta è sconosciuto.
User		Il nome o il numero UID dell'utente proprietario della porta. Si ottiene questa informazione con l'opzione -e.

2.206.2 - Sendmail

L'utilizzo e la gestione di messaggi di posta elettronica avvengono tramite un MTA (Mail Transfer Agent). Dopo aver ricevuto una richiesta di invio, l'MTA inoltra il messaggio all'MTA corrispondente presente all'indirizzo del destinatario, o a una destinazione intermedia che si occupa dell'inoltro verso il destinatario finale. Nonostante tutto ciò possa sembrare molto semplice, la configurazione di un MTA può risultare piuttosto complessa.

Di solito, in presenza di una rete locale, il funzionamento corretto dell'MTA richiede la predisposizione di un servizio di risoluzione dei nomi locale, mentre il corretto invio di messaggi di posta elettronica avviene solitamente attraverso l'uso di un programma adatto alla loro composizione, che poi si mette in comunicazione con l'MTA per l'inoltro del messaggio.

L'MTA più diffuso nei sistemi Unix è Sendmail; tuttavia, è sempre più comune l'uso di MTA alternativi, meno complicati; il pregio di Sendmail è la sua estrema configurabilità, che però porta con sè il prezzo da pagare di un'estrema complessità.

A seconda delle opzioni con cui viene avviato l'eseguibile sendmail, si ottiene un demone in ascolto della porta SMTP (25), oppure la trasmissione di un messaggio fornito attraverso lo standard input, oppure si hanno altre funzioni accessorie.

Solitamente, Sendmail viene distribuito già configurato in modo standard, sia per l'attivazione del servizio SMTP, sia per la gestione della trasmissione dei messaggi e della consegna locale.

sendmail è l'eseguibile di Sendmail e viene usato per l'attivazione del servizio SMTP e per la trasmissione e la consegna locale dei messaggi.

Per l'attivazione del servizio SMTP, viene avviato normalmente come demone indipendente dal supervisore dei servizi di rete, con l'opzione -bd.

Ecco come potrebbe apparire la riga che avvia sendmail in uno script del genere:

/usr/sbin/sendmail bd -q10m

L'opzione -bd avvia Sendmail come demone, mentre l'opzione -q10m indica che la coda debba essere elaborata ogni dieci minuti.

Questa è la forma standard in cui sendmail viene inizializzato solo come servizio.

Per l'invio di un messaggio, è sufficiente avviare sendmail, fornendogli questo attraverso lo standard input, avendo cura di separare con una riga vuota l'intestazione dal testo.

/usr/sbin/sendmail -bs

L'opzione -bs è utilizzata per la lettura di un certo numero di messaggi in formato SMTP in batch.

/usr/sbin/sendmail -q

Con l'opzione -q sendmail viene forzato a elaborarela coda di posta per la spedizione dei messaggi presenti. Questa chiamata viene implementata periodicamente con un cron nel caso in cui sendmail non sia avviato come demone ma sia installato in un computer senza un collegamento permanente a Internet.

Sendmail può essere chiamato anche come runq, nel qual caso si comporta come se fosse presente l'opzione -q.

/usr/sbin/sendmail -bp

Infine l'opzione -bp stampa il contenuto della coda. Sendmail può essere chiamato anche come mailq, nel qual caso si comporta come se fosse presente l'opzione -bp.

Configurazione di Sendmail

La configurazione di Sendmail è piuttosto complicata e si attua attraverso il file /etc/sendmail.cf. Chi non è esperto è bene che scelga il file di configurazione tra un gruppo già pronto e ben descritto per i suoi effetti.

È chiaro che in questa situazione ci si deve fidare della propria distribuzione; di conseguenza occorre leggere la documentazione relativa che dovrebbe descrivere le scelte fatte nella configurazione di questo servizio.

Per modificare la configurazione di Sendmail, si evita generalmente di intervenire direttamente nel file /etc/sendmail.cf, utilizzando piuttosto dei linguaggi macro in grado di costruire un file facilmente.

Invece di costruire a mano un file di configurazione, si può fare affidamento sull'elaboratore di macro m4 per costruire un file di configurazione da “pezzi” già pronti i quali vengono distribuiti insieme a sendmail.

Come esempio esaminiamo le prime righe del file sendmail.mc:

include(/usr/lib/sendmail.cf/m4/cf.m4)

VERSIONID('sendmail.mc - roessler@guug.de')

OSTYPE(debian)

define('ALIAS_FILE','/etc/mail/aliases')

vediamo che all'inizio viene incluso cf.m4. Tale file macro contiene molte delle definizioni necessarie nel resto del file. Ci si assicuri che venga fornito il path corretto. Quello indicato nell'esempio è tipico per Debian GNU/Linux.

La macro OSTYPE è usata per dare diverse definizioni di default per determinati valori di configurazione. Se non si sta usando un sistema Debian, si deve rimpiazzare la parola "debian" con "linux".

ALIAS_FILE dice a sendmail dove cercare per la lista degli alias.

Le seguenti righe di codice, invece, indicano a sendmail di usare le caratteristiche di genericstable e dove trovare il file di configurazione necessario ad usarle:

FEATURE(masquerade_envelope) FEATURE(genericstable, ìhash -o /etc/mail/genericstable')

GENERICS_DOMAIN_FILE('/etc/mail/genericsdomain')

La masquerade_envelope si occupa di far applicare la riscrittura degli header alla “busta” del mittente del messaggio.

Quest'ultima è l'indirizzo di posta a cui il sottosistema di recapito della posta esterna dirigerà la notifica di fallimento di recapito e i messaggi di warning.

I file generics* vranno illustrati in seguito.

A questo punto si deve definire un cosiddetto smart-host, ovvero una macchina che gestirà la posta in uscita per il proprio sistema.

Si noti che tale macchina deve essere diversa dai propri server POP e IMAP.

Il codice è nel file di configurazione del master:

define('SMART_HOST','mail-out.your.provider')

La stringa mail-out.your.provider deve essere sostituita dall'hostname del proprio provider di servizi internet.

Le ultime due righe includono le definizioni di “mailer” che servono a sendmail per capire come gestire i vari tipi di mail:

MAILER(local)

MAILER(smtp)

Per generare il file di configurazione sendmail.cf da questo sendmail.mc,

si deve digitare il seguente comando da root:

m4 sendmail.mc > _sendmail.cf

mv -f _sendmail.cf sendmail.cf

Si noti la tecnica di scrivere l'output di m4 in un file temporaneo che viene poi spostato nella collocazione appropriata.

Questo aiuta ad evitare che sendmail legga da file di configurazione parzialmente riscritti.

Riscrittura degli indirizzi

In sendmail si deve specificare quali indirizzi vadano considerati locali (e che quindi vanno soggetti a riscrittura). Questa cosa è piuttosto semplice. è sufficiente specificare l'hostname completo della propria macchina nel file etc/mailg/enericsdomain. Per ottenere il proprio hostname completo si digiti il comando:

hostname -f

Una caratteristica utile di sendmail è genericstable che permette appunto di ridefinire l'header della mail in base ad una tabella creata appositamente dall'amministratore di sistema (root).

Come sempre questa feature si appoggia ad un file in cui sono definiti gli user ed gli indirizzi di e.mail che devono essere modificate. Un esempio, sul caso ipotetico visto prima, potrebbe essere:

daniela daniela@unicam.it

ove la prima parte indical'utente locale e la seconda come deve essere modificato l'header. La creazione del database deve essere fatta ogniqualvolta si modifica il file di appoggio ed il file di appoggio deve essere definito nella feature in fase di creazione del file.mc.

Il comando per la sua generazione è:

makemap hash /etc/genericstable < /etc/genericstable

e la feature deve essere definita (in questo caso) come:

Feature(genericstable, hash -o /etc/genericstable)

Riassumendo, la tabella di riscrittura: etc/mail/genericstable è costituita da due colonne separate da uno spazio bianco. La prima contiene gli indirizzi locali, mentre la seconda contiene gli indirizzi di posta elettronica che devono essere usati al posto degli indirizzi locali.

Tale file sarà del tipo:

chris	cgabriel@dominio.it

dani	daniela@dominio.it

eugenia	eugenia@dominio.it

root	daniela@dominio.it

news	daniela@dominio.it

Si noti che per ciascun account sulla macchina locale ci deve essere una sola voce in modo da evitare che posta generata automaticamente che esca dal sistema contenga header non validi.

Si noti che le regole di riscrittura date dalla genericstable non verranno applicate alla posta locale o a messaggi ricevuti dall'esterno. La mappatura è usata solo un messaggio parte dal sistema locale verso il proprio smarthost ISP.

Alias

Nel file /etc/aliases vengono definiti gli alias di posta. Essi sono semplici pseudonimi corrispondenti ai nomi degli utenti reali, nella forma:

Alias: nomereale

Ad esempio:

ftp: root

ftpadm: root

ftpadmin: root

ftp_adm: root

Questo esempio ci mostra che ogni tentativo di mandare una mail all'amministratore ftp in qualunque modo si scriva il nome, corrisponderà ad una mail a root.

D'altra parte questo file è utilizzato anche da utenti che ricevono la posta sul computer locale la quale però viene inoltrata in un altro computer:

alf: alf@pippo.it

max: max@2max.it

Un'ulteriore importante funzione del meccanismo di aliasiing è quello di distribuire messaggi a programmi che poi li processino, come ad esempio Majordomo. In /etc/aliases per esempio si può trovare una voce del tipo:

nome@dominio: "|/usr/bin/programma"

In tal modo tutti i messaggi mandati a nome@dominio vengono inoltrati al programma /usr/bin/programma che poi può processare questi messaggi nel modo corretto.

In più c'è la possibilità, con l'istruzione :include:file di utilizzare interi file contenenti degli alias. Ad esempio, con il file /var/listen/tutti che contenga:

dani chris eugenia

e la voce in /etc/aliases

admin: :include:/var/listen/tutti

Tutti i messaggi diretti ad admin vengono trasmessi a dani, chris ed eugenia. I due punti prima di include servono a distinguere l'istruzione include dal nome di un utente ed è obbligatorio usarli. Ogni volta che questo file viene modificato si deve eseguire newaliases.

Domini virtuali

Nel caso in cui in un server vengano ospitati diversi domini, allora si devono utilizzare il cosiddetti domini virtuali. Questo corrisponde ad esempio ai server web di Apache. Una macchina riceve posta da diversi domini con nomi diversi e sendmail fa sì che la posta ricevuta venga smistata agli indirizzi di posta originali. Perché questo funzioni, si deve specificare da quali domini sendmail deve accettare la posta. Questi dati sono contenuti nel file /etc/sendmail.cw, che in alcune distribuzioni si chiama /etc/mail/localhostnames.

In teoria il nome del file può essere indicato nel file di configurazione di m4, con l'istruzione:

FEATURE(use_cw_file) define('confCW_FILE', '/etc/mail/nomi')

In questo modo si ottiene di fare accettare a Sendmail l'identificazione del proprio nodo attraverso uno dei nomi elencati nel file /etc/sendmail.cw.

/etc/mail/virtusertable

Per usare questo file, si deve aggiungere la line seguente nel file di configurazione in m4:

FEATURE(virtusertable)

Questa caratteristica di sendmail permette di gestire domini virtuali. Se sulla propria macchina ci sono più domini, per esempio dom1.com e dom2.com e, come spesso avviene, devono essere create due e-mail con lo stesso nome ma riferite a domini diversi, sendmail non sa come interpretare il risultato e segnala un errore. In fase di generazione del sendmail.cf si usa VIRTUSERTABLE, che si appoggia ad un file che definisce come ridirigere la mail per ciascuno dei due domini..

Si dovrà in questo caso creare un file (/etc/virtusertable) che reindirizzi la posta per i 2 utenti.

Si dovrà quindi creare il database del virtusertable (operazione che dovrà essere fatta ogni qualvolta si aggiorni il file) con il comando:

makemap hash /etc/virtusertable < /etc/virtusertable

Ogni volta che si aggiorna il database , si deve rilanciare sendmail.

2.206.3 - Gestione del traffico di posta

Procmail è un programma che si occupa di gestire la consegna in ambito locale della posta elettronica nel sistema. Ciascun utente può impostare le proprie regole, le quali vengono poi elaborate dall'MTA (sendmail, exim...). Risulta molto utile per preordinare e preelaborare grandi quantità di messaggi in arrivo. Si possono catalogare messaggi in arrivo dalle mailing list, cestinare i messaggi-di spam, spedire risposte automatiche o persino gestire mailing list.

Nella maggior parte dei casi, procmail viene chiamato in automatico, per poter funzionare nella gestione della posta locale. In caso contrario, si può inserire la seguente riga nel file .forward per far partire procmail:

“|/usr/bin/procmail”

Il file di configurazione ~/.procmail

Nel file $HOME/.procmailrc vengono impostate le regole che controllano il processo di gestione dei messaggi relativi al singolo utente. Per maggiore chiarezza tali regole possono essere importate anche da altri file, utilizzando l'istruzione:

INCLUDERC = nomefile

In tal modo si possono disattivare molto velocemente determinate regole semplicemente commentando la riga corrispondente alle relative istruzioni (utilizzando di solito il carattere #).

Le parole chiave più importanti che possono essere inserite nel file di configurazione sono le seguenti:

LOG FILE = file

impostazione del file dove procmail scrive i propri log

Verbose = yes

utilizzato per l'individuazione degli errori, dà luogo a file di log dettagliati

MAILDIR = lista

posizione delle proprie mailbox (di solito $HOME/Mail)

Vediamo in dettaglio un semplice esempio di file di configurazione di procmail.

# .procmailrc

# redirige i messaggi in arrivo nelle caselle di posta

# appropriate

PATH=/usr/bin:/usr/local/bin

MAILDIR=$HOME/.mailspool	# tutte le caselle sono in .

# mailspool

DEFAULT=$HOME/.mailspool/daniela

LOGFILE=/dev/null

SHELL/bin/sh

#Archivia la mail dalla mailing list lug nella casella lug

:0:

* ^(From|Cc|To).*lug

lug

Un file .procmailrc si divide in due parti: assegnazioni e regole.

Le assegnazioni impostano le variabili, in modo che procmail sappia dove si trovano i programmi e le caselle di posta (parte iniziale del file di configurazione). Le regole o “ricette” sono la parte finale.

Assegnazioni

La sezione delle assegnazioni dice a procmail dove cercare le caselle di posta o programmi che gli possono essere utili. L'insieme delle assegnazioni può sostanzialmente riguardare ciò di cui la maggior parte degli utenti ha bisogno; il set completo viene discusso in dettaglio nella pagina di manuale di procmail.

Vediamo in dettaglio le assegnazioni che compaiono nel file di esempio. Esse sono utilizzate nel formato nome-variabile=valore.

PATH=/usr/bin:/usr/local/bin

questa istruzione dice a procmail dove cercare gli altri programmi (le directory sono separate dai due punti).

MAILDIR=$HOME/.mailspool

come visto sopra, MAILDIR corrisponde alla posizione delle proprie mailbox. $HOME è la home directory dell'utente, perciò tale assegnazione punta alla directory .mailspool nella home dell'utente. Nella maggior parte dei casi, la configurazione del sistema prevede che tale directory esista, ma è comunque bene controllare che ciò sia vero.

DEFAULT=$HOME/.mailspool/daniela

DEFAULT è la posizione di default per archiviare la posta dell'utente; dovrebbe essere la casella di posta principale.

LOGFILE=/dev/null

qui viene specificato il nome di un file da usare come log di utenza, nel quale procmail andrà a scrivere ogni messaggio di diagnosi o di errore durante la sua attività. In questo esempio il logging viene rediretto in /dev/null che è una sorta di “buco nero” del sistema dove scaricare i dati indesiderati. Con questo file .procmailrc i dati di log non vengono quindi conservati.

SHELL=/bin/sh

Definisce il tipo di shell o l'ambiente operativo in cui procmail gestisce gli altri programmi.

Regole o “ricette”

Ciascuna regola viene scritta in un formato ben definito:

:0 [flag] [:file di LOCK]]* < una o più condizioni

(una per ciascuna riga) > <dettagli singola azione>

La riga di ciascuna condizione comincia con un asterisco e tutto ciò che segue viene interpretato come un'espressione regolare. Se viene applicata questa espressione, allora viene implementata l'azione corrispondente. Più condizioni sono connesse tra loro da un AND logico. Se non specificato altrimenti, la regola viene usata sempre.

Le più importanti flag opzionali sono le seguenti:

H

l'intestazione del messaggio viene esaminata dall'espressione regolare

B

il corpo del messaggio viene esaminato dall'espressione regolare

D

viene effettuata la distinzione tra maiuscole e minuscole

Ci sono molte altre opzioni da poter specificare; l'elenco completo si può trovare nella pagina di manuale di procmail.

Le condizioni iniziano con un asterisco, seguito un'espressione regolare, la quale può contenere alcune estensioni specifiche per i messaggi:

^TO

si applica a tutte le righe che cominciano con To, Cc, Bcc o Resent to.

^FROM_DAEMON

si applica a tutte le righe che arrivano dal demone di posta o da mailing list.

MORE ^FROM_MAILER

simile a FROM_DAEMON ma senza mailing list.

Espressioni regolari

Le espressioni regolari sono in realtà ragionevolmente semplici, una volta che ci sia presa confidenza.

Innanzitutto va detto che ciascun carattere che non sia un carattere speciale si mappa su se stesso. Questo include tutte le lettere, i numeri, e una parte della punteggiatura. Ovvero l'espressione:

Ciro

corrisponde alla stringa Ciro. In procmail, le espressioni regolari sono case insentitive, ovvero tale stringa corrisponderà anche a “ciro”, oppure “CiRo” o “CIRO”.

Un punto “.” si mappa su ciascun carattere, tranne quello di newline. Ovvero l'espressione:

.iro Cattuto

corrisponderà alla stringa “Ciro Cattuto” ma anche a “Piro Cattuto” o “Biro Cattuto”.

Ogni carattere seguito da un asterisco “*” corrisponde a quel carattere ripetuto 0 o più volte. Quindi:

Ciro* Cattuto

corrisponde a “Cir Cattuto”, “Ciro Cattuto” o “Cirooooooo Cattuto”. L'espressione “.” corrisponde a un qualunque numero di caratteri non specificato.

I due modificatori '+' e '?' si riferiscono ad un determinato numero di caratteri: l'espressione “a+” corrisponde a una o più a, mentre “a?” corrisponde a zero o una a.

Si possono usare le parentesi per raggruppare un'espressione da usare con un modificatore. Ad esempio:

C(iro)+

corrisponde a “Ciro” e anche a “Ciroiroiroiro”.

L'elenco di tutti i caratteri speciali e della loro funzionalità può essere trovato nella pagina di manuale di procmail.

In conclusione si dovrebbe aver capito che la ricetta per le espressioni regolari rappresenta un pattern in un messaggio di posta. Possiamo usare le espressioni regolari per dire a procmail quale pattern cercare.

Per ulteriori informazioni su procmail

Procmail Quick And Easy howto http://www.mrshark.it/qechowto/procmail.html (in italiano)

La home page di Procmail http://www.procmail.org/ (in inglese)

2.206.4 - Configurazione e installazione di un server di News

INN (InterNet News) è un server estremamente flessibile e configurabile per la gestione delle news in Usenet/netnews.

In breve, netnews è un insieme di protocolli per lo scambio di messaggi tra una rete decentralizzata di server di news. Gli articoli di notizie possono essere organizzati in newsgroup i quali a loro volta possono essere organizzati in gerarchie. Ciascun server immagazzina localmente tutti gli articoli ricevuti da un determinato newsgroup, rendendo l'accesso all'archivio molto veloce. Netnews non richiede la presenza di nessun server centrale, anzi, ciascun server di news trasmette gli articoli che riceve a tutti gli altri server con cui è collegato, i quali a loro volta li passano ai server con cui sono in comunicazione e cosi' via, dando luogo a una propagazione “flood fill” degli articoli.

INN è un software libero, supportato dall'Internet Software Consortium e da volontari in tutto il mondo.

Il processo di startup di INN è piuttosto complicato. In Debian il demone che gestisce le news NNTP in arrivo si chiama innd.

Programmi che operano nel contesto di innd

innd

Innd, il demone di InterNet News gestisce tutte le news NNTP in arrivo. Dopo aver letto i file active, newsfeeds e hosts.nntp in memoria apre la porta NNTP per ricevere articoli da siti remoti (si veda l'opzione``-p'' ), una socket Unix a stream per ricevere articoli da processi locali come nnrpd e rnews, e una socket Unix a datagram per usare ctlinnd che si occupi di far eseguire al server determinate azioni. Inoltre apre il database history e due file di log per rimpiazzare il suo standard output e standard error.

nnrpd

nnrpd è un server NNTP per i newsreader; accetta comandi dallo standard input e risponde sullo standard output. Normalmente viene invocato da innd per mezzo dei descrittori collegati ad una connessione di un client remoto. Nnrpd può anche essere usato come demone standalone.

innxmit

Innxmit si connette al server NNTP sull'host indicato, autenticandosi tramite passwd.nntp, se possibile, ed invia ad esso gli articoli indicati nel file passato come argomento. Normalmente viene invocato da uno script di cron, che usa shlock per fare il lock dell'hostname, seguito da ctlinnd per fare il flush del file batch.

ctlinnd

Ctlinnd invia un messaggio al canale di controllo di innd; nel modo normale di esecuzione, il messaggio viene inviato al server, che esegue l'azione richiesta e risponde con un messaggio di testo contenente il codice di uscita di ctlinnd. Se il server esegue correttamente il comando, ctlinnd esce con uno stato di zero e stampa la risposta su standard output. Se il server non può eseguire il comando, ad esempio se gli viene richiesto di rimuovere un newsgroup inesistente, fa uscire ctlinnd con uno stato di uno.

innfeed

Innfeed implementa il protocollo NNTP per trasferire le news tra computer; gestisce sia il protocollo standard IHAVE, sia le estensioni streaming CHECK/TAKETHIS. Innfeed può gestire un numero qualsiasi di host remoti e può aprire connessioni multiple verso lo stesso host se viene configurato di conseguenza. L'unica limitazione sono i limiti per i descrittori di file aperti e la memoria.

Configurazione di inn

/etc/news/inn.conf

Questo è il file di configurazione principale per tutte le caratteristiche generali. Contiene i dati che riguardano il news server locale e i suoi path.

/var/lib/news/active

I nuovi gruppi offerti dal server sono indicati in questo file. Ciascuna riga consiste di quattro campi separati da spazi:

<nome> <max> <min> <opzioni>

Il primo campo è il nome del newsgroup. Il secondo e il terzo sono il massimo e il minimo numero di articoli da tenere nel newsgroup; tali numeri non devono essere accurati, ma vengono usati come suggerimento ed aggiornati di notte come parte del processo di expire.

Alcune delle opzioni che si possono usare sono le seguenti:

y

sono permessi messaggi provenienti da questo server

n

non sono permessi messaggi provenienti da questo server

m

questo gruppo è moderato

j

gli articoli di questo gruppo non vengono archiviati localmente ma vengono solo passati a server di ordine superiore

x

Non si possono inviare messaggi a questo gruppo

= pippo.pip

gli articoli vengono memorizzati localmente nel gruppo pippo.pip.

/var/lib/news/newsgroups

in ciascuna riga di questo file è contenuta la descrizione di un gruppo disponibile, nel formato:

Nome descrizione

/etc/news/newsfeeds

in questo file viene stabilito a quali server devono essere mandati i nuovi articoli che arrivano. Il formato delle righe è il seguente:

server:pattern:flag:parametri

Server è il nome del newsserver; non deve essere necessariamente il suo nome di dominio, poiché il nome reale viene determinato da innxmit. In tal modo è possibile amministrare diverse voci per ciascun server che vengano elaborate individualmente.

/etc/news/nntpsend.conf

In questo file i nomi simbolici provenienti dai newsfeed sono convertiti in nomi di dominio completi.

/etc/news/incoming.conf

In questo file vengono specificati quali nuovi server possono mandare messaggi

/etc/news/nnrp.access

Viene specificato chi ha accesso al nuovo server

/etc/news/expire.ctl

Qui vengono determinati gli intervalli di tempo per cui mantenere gli articoli nel database.

2.207.1 - Configurazione di base di BIND

File di configurazione

Il principale file di configurazione di bind8 è /etc/named.conf; qui vengono impostate le variabili fondamentali. Nelle vecchie versioni di bind (4.9.x) il file si chiamava /etc/named.boot ed aveva un formato totalmente diverso. Per facilitare la conversione tra le versioni, bind8 fornisce uno script di shell, bootconf, per mezzo del quale i file di configurazione di bind4.9 possono essere trasformati nel formato letto da bind8.

Nell'esame LPI102 è già stato trattato il meccanismo del name server con sola cache; esaminiamo quindi i dati più specifici:

Configurazione dei log

La versione 8 di bind ha introdotto una nuova forma di configurazione dei log; sotto la sezione LOGGING nel file di configurazione si possono inserire dati molto dettagliati, le informazioni sugli altri name server da usare e cosa fare con le informazioni.

Nel file di configurazione ci può essere solo una sezione LOGGING. Se ce ne sono più, viene usata solo la prima e per le altre viene inviato un warning.

Il LOGGING è basato sui cosiddetti canali (channels), che specificano i metodi di output, le opzioni di formattazione e i livelli di importanza con un nome che può in seguito essere usato con la parola chiave category per selezionare le modalità di log delle varie classi di messaggi.

Per i canali sono disponibili tre diverse tecniche:

file nomefile

I messaggi inviati a questo canale sono scritti nel file indicato. Possono essere definiti inoltre la dimensione massima del file e il numero di versioni che vengono salvate ogni volta che il file viene aperto.

syslog (origine)

L'argomento della clausola syslog è una funzionalità di syslog tra quelle descritte nella relativa pagina di manuale (core, user, mail, daemon, auth, syslog, lpr, news, UUCP, cron, authpriv, ftp,local0-7) . Come syslog gestisce i messaggi inviati a questa funzionalità viene descritto nella pagina di manuale di syslog.conf. Se avete un sistema che usa una versione di syslog vecchia con solo due argomenti per la funzione openlog(), questa clausola viene ignorata senza indicazioni di sorta.

null

I messaggi vengono ignorati.

Si possono definire un numero qualsiasi di canali.

Opzionalmente, per ciascun canale si possono indicare:

severity

Corrisponde alla priorità di syslog. I valori possibili sono dynamic critical, error, warning, notice, info., debug[livello].

print-category

Viene loggata la categoria del messaggio (yes o no).

print-severity

Viene loggata la priorità del messaggio (yes o no).

print-time

Vengono loggate data e ora (yes o no). Normalmente, syslog già indica questa informazione, quindi può essere impostata a no; è comunque comoda per il log diretto su file.

Se vengono definiti i canali, si può decidere quali messaggi vengono inviati in quali canali usando l'istruzione category. Le categorie disponibili sono:

default

La categoria di default, che comprende tutto ciò che non è compreso nelle altre categorie. Se per una categoria non si specificano canali, viene usata la categoria di default. Se non si definisce la categoria di default, viene usata questa definizione: category default {default_syslog; default_debug; };

config

L'elaborazione di file di configurazione ad alto livello.

parser

L'elaborazione di file di configurazione a basso livello.

queries

Per ogni query al server viene generato un breve messaggio di log.

lame-servers

I messaggi come "Lame server on ..."

statistics

Le statistiche.

panic

Se il server si deve fermare per un problema interno, scriverà il problema in questa categoria, oltre che in quella nativa del problema. Se non si definisce la categoria panic, viene usata la seguente definizione: category panic {default_syslog; default_stderr; };

update

Gli aggiornamenti dinamici.

update-security

Gli aggiornamenti dinamici negati a causa dei controlli sugli accessi.

ncache

I caching negativi.

xfer-in

I trasferimenti di zona ricevuti dal server..

xfer-out

I trasferimenti di zona inviati dal server.

db

Tutte le operazioni sui database.

eventlib

Il debug del sistema degli eventi. Per questa categoria può essere indicato solo un canale, e deve essere un file. Se non la si definisce, viene usata la seguente definizione: category eventlib { default_debug; };

packet

I dump dei pacchetti ricevuti e inviati. Per questa categoria può essere indicato solo un canale, e deve essere un file. Se non la si definisce, viene usata la seguente definizione:

category packet { default_debug; };

notify

Il protocollo NOTIFY.

cname

I messaggi del tipo "... points to a CNAME".

security

Le richieste approvate e non approvate.

os

I problemi di sistema operativo.

insist

I controlli di consistenza interni falliti.

maintenance

Gli eventi di manutenzione periodici.

load

I messaggi di caricamento delle zone.

response-checks

I messaggi provenienti dal controllo delle risposte, come "Malformed response ...", "wrong ans. name ...", "unrelated additional info ...", "invalid RR type ..." e "bad referral ...".

Una configurazione di LOGGING potrebbe quindi essere di questo tipo:

logging {

category default { default_syslog; default_debug; };

category panic { default_syslog; default_stderr; };

category packet { default_debug; };

category eventlib { default_debug; };

};

Configurazione delle opzioni

Come per LOGGING, nel file di configurazione di bind8 può esistere un solo blocco OPTION; se ce ne sono più, viene letto solo il primo e gli altri provocano un messaggio di warning.

Sono disponibili più di 50 opzioni, ma non tutte sono necessarie. Le più importanti sono:

version versione

L'indicazione della versione; se viene omessa, viene usata la reale versione di NAMED.

directory percorso

La directory di lavoro sul server. Tutti i percorsi non assoluti verranno considerati relativi a questa directory.

dump-file nomefile

Il nome del file in cui viene fatto il dump del database quando si riceve il segnale SIGINT.

recursion yes|no

Se yes e viene fatta una query DNS ricorsiva, il server cercherà di fare tutto il lavoro richiesto per rispondere alla query. Se non è attiva, invece, il server rimanda il client ad un referral se non conosce la risposta. Il default è yes.

fetch-glue yes|no

Se recursion è no, anche questa deve essere disattivata.

datasize numero

La massima memoria utilizzabile dal server.

allow-transfer {elenco di indirizzi};

Indica a quali host è permesso ricevere i trasferimenti di zone dal server.

Altre opzioni riguardano il controllo degli accessi e la sicurezza, e sono descritte nelle sezioni successive.

Indicazione dei server

Con la dichiarazione server si possono indicare le caratteristiche da associare con i server remoti. Tale dichiarazione ha la forma:

server ip_addr {

[ bogus yes_o_no; ]

[ support-ixfr yes_o_no; ]

[ transfers numero; ]

[ transfer-format ( one-answer | many-answers ); ]

[ keys { key_id [key_id ... ] }; ]

};

Se si scopre un server che invia dati non corretti, marcandolo come bogus si eviterà di richiedergli informazioni. Il valore di default è quindi no.

Il server supporta due metodi di trasferimento delle zone; il primo, one-answer, usa un messaggio DNS per record di risorsa trasferito. many-answers unisce più record possibii in un solo messaggio. many-answers è più efficiente, ma viene interpretato bene solo da BIND 8.1 e dalle versioni patchate di BIND 4.9.5. Si può indicare quale metodo usare per un server con l'opzione transfer-format. Se transfer-format non è indicata, viene usata quella di default indicata in options.

transfers verrà usata in versioni future del server per limitare il numero di trasferimenti in ingresso contemporanei dal server indicato. La sua sintassi viene controllata ma l'opzione viene ignorata.

La clausola keys viene usata per identificare un key_id definito dalla dichiarazione key, da usare per la sicurezza delle transazioni durante la comunicazione con il server. La dichiarazione key deve essere posta prima del server a cui si riferisce. Quando si invia una richiesta ad un server remoto, viene generata una firma usando questa chiave, e tale firma viene allegata al messaggio. Le richieste provenienti dal server remoto non devono necessariamente essere firmate con questa chiave.

La routine di supervisione ndc

Il programma ndc (name daemon control) rende possibile inviare delle istruzioni ad un nameserver bind8 senza riavviarlo. Oltre ad un canale di controllo usato, secondo lo standard viene creata una socket, /var/run/ndc, sulla quale il server resta in ascolto e nella quale il programma ndc va a scrivere.

ndc apre una shell interattiva, che permette di inviare i comandi al name server. Questa shell può essere chiusa con l'istruzione /exit. In alternativa, si può inviare un comando alla shell direttamente dalla linea di comando.

Dato che dipende dal nameserver usato in ciascun caso, i comandi specifici di ndc sono pochi; il più importante è /help, che chiede al nameserver quali comandi ha disponibili e li elenca.

I comandi più comuni sono:

getpid

Restituisce il PID del nameserver.

status

Indica lo stato del nameserver. Le informazioni date sono la versione, il livello di debug e il numero di query attive.

stop

Ferma il demone. Dopo questo comando è possibile solo /exit, dato che il canale non è più aperto.

reload [ zona ]

Una o tutte le zone vengono ricaricate. Utile se si modificano manualmente le zone.

dumpdb

Viene creato un file (di solito /var/tmp/named_dump.db o quello indicato dalla variabile d'ambiente_ PATH_DUMPFILE) in cui viene riversato l'intero contenuto della cache del nameserver.

Controllo del nameserver tramite segnali

Oltre che con il comando ndc, il nameserver può essere controllato mediante segnali, inviati tramite il comando kill. I segnali interpretati sono i seguenti:

SIGHUP

Rilegge il file di configurazione e ricarica i database.

SIGINT

Riversa la cache nel file in cui scriverebbe ndc dumpdb.

SIGTERM

Salva tutte le informazioni sulle zone e chiude il nameserver.

2.207.2 - Creazione ed amministrazione delle zone del DNS

Se si deve installare un nameserver non solamente caching, al suo interno devono essere memorizzate le informazioni su una o più zone, ed il lavoro diventa leggermente più complesso di quello fatto finora. Ogni zona viene memorizzata all'interno di un file che contiene i nomi in cui vengono trasformati gli indirizzi IP (file forward) e un altro in cui sono presenti gli indirizzi IP in cui vengono trasformati i nomi (file reverse).

Inoltre, per ciascuno di questi file deve essere presente una voce nel file di configurazione centrale, /etc/named.conf.

Oltre alle voci per i root server, quindi, abbiamo una voce per ciascuna zona diretta e inversa. Per ciascuna zona si decide se il server deve essere il primario o il secondario; il primario passa tutte le sue voci al secondario per mezzo del trasferimento delle zone. Ecco un esempio di voce di un server primario per la zona pippo.xyz, che ha l'indirizzo IP 199.45.67.0:

options {

directory "/var/named";

};

zone "pippo.xyz" IN {

type master; # E' un server primario

file "pippo.xyz.zone"; # I dati della zona

};

zone "67.45.199.in-addr.arpa" IN {

type master;

file "67.45.199.in-addr.arpa.zone";

};

I dati parlano da soli: si tratta del server primario per le zone indicate (type master), e in entrambi i casi viene indicato il file in cui si trovano i dati relali. Il nome del file è indicato in maniera relativa all'elenco indicato nell'opzione directory, quindi nel nostro esempio /var/named.

I file delle zone

Il prossimo passo è quindi esaminare i file in cui inserire i dati relativi alle zone (nel nostro esempio, /var/named/pippo.xyz e /var/named/67.45.199.in-addr.arpa.zone). I nomi possono essere qualsiasi, purché corrispondano a quanto è scritto in /etc/named.conf.

Ciascun file di zona è un database con record che contengono i seguenti elementi:

Domain-name

Il nome di dominio a cui si riferisce il record.

Time-to-live

Un valore opzionale che indica la stabilità di una voce, cioè quanto tempo deve restare valida. Spesso viene omesso.

Class

La classe di informazioni. Per Internet, è sempre IN.

Type

Indicate il tipo di record; i tipi possibili sono indicati più avanti.

Value

Il reale valore del record, dipende dal tipo usato.

Il database consiste di voci che seguono tutte questo formato. I valori possibili per il tipo sono:

Tipo	Significato	Voce
SOA	Start OF Authority	Indica l'inizio della parte relativa ad un server; finisce al successivo SOA.
A	ADDRESS	Un indirizzo Internet in notazione a punti.
MX	Mail Exchange	La priorità e il nome del server di posta responsabile del dominio.
NS	Name server	Il nameserver del dominio.
CNAME	Canonical name	Il nome di dominio di un computer (alias)
PTR	Pointer	Alias per un indirizzo IP numerico
HINFO	Host information	Descrizione ASCII dell'host (sistema operativo usato, ...)
TXT	Text	Commento di testo, non utilizzabile

Il record SOA

Il primo record di un file di zona è il cosiddetto SOA, che indica l'inizio della sezione relativa ad una zona per cui il server è autoritativo. Questo record contiene pochi dati criptici, che si possono capire solo con difficoltà. Una tipica voce di un record SOA potrebbe essere:

pippo.xyz. IN SOA qui root.qui.pippo.xyz. (

20040321001 ; serial

1H ; refresh

600 ; retry

40D ; expiry

2D ) ; minimum

La prima voce (pippo.xyz.) è il dominio a cui è relativa questa voce. Il punto finale significa che il dominio è completo, e non serve aggiungerci altro.

La seconda voce è la classe, nel nostro caso IN per un indirizzo di tipo Internet.

La voce è il tipo di voce, nel nostro caso SOA.

Una voce SOA consiste di diversi attributi; per prima cosa c'è il nome del server, che nel nostro caso si chiama qui. Il nome NON è seguito da un punto, perché deve essere seguito dal nome del dominio. Quindi, qui diventa qui.pippo.xyz.

La successiva voce nel record SOA è l'indirizzo di e-mail dell'amministratore. Invece della @, però, viene usato un punto; nel nostro esempio, quindi, l'indirizzo dovrebbe essere root@qui.pippo.xyz. Anche qui, dato che non si deve aggiungere il dominio, l'indirizzo viene terminato con un punto.

Poi segue una serie di dati tra parentesi, che si riferiscono alla validità del record. Per primo un numero di serie, che di solito consiste nella data dell'ultima modifica manuale del file e da un intero. Nel nostro esempio, quindi, 20040321001 sta per la prima voce del 21 Marzo 2004. Questo valore viene usato quando un server secondario deve decidere se la sua voce è ancora valida o deve essere trasferita. In caso di un cambiamento manuale, si deve modificare di conseguenza questo numero, in modo che i nameserver secondari capiscano che devono aggiornare i propri dati.

Le voci successive hanno il seguente significato:

1H

Indica l'intervallo di tempo per cui il server secondario aspetta prima di controllare se i dati sono stati modificati. L'unità di misura usata sono i secondi, oppure per maggiore leggibilità, aggiungendo la lettera corrispondente, ore, giorni, settimane o mesi (con H per le ore, D per i giorni, W per le settimane e M per i mesi).

600

Dopo dieci minuti il server tenta di nuovo di trasferire la zona, se il tentativo precedente non è andato a buon fine.

40D

Dopo 40 giorni senza poter contattare il server primario, il secondari considera le informazioni che ha in memoria non valide e non le fornirà più in risposta alle query.

2D

Indica il valore predefinito per la validità delle informazioni, per gli eventuali record mancanti per il TTL.

Record NS e MX

Dopo il record SOA, di solito vengono indicati i record che indicano chi è responsabile per il nameserver, indicati dalla classe IN, il tipo NS e l'indicazione del nome del server appropriato; se il nome non termina con un punto, viene aggiunto il nome di dominio, altrimenti viene interpretato come completo.

IN NS qui

IN NS quo

IN NS qua.pippo.xyz.

Dato che in queste voci non viene indicato un dominio, esse si riferiscono al campo SOA indicato. Se invece per esempio un sottodominio sub.pippo.xyz ha un proprio nameserver, viene indicato per primo il nome del sottodominio:

IN NS qui

IN NS quo

sub.pippo.xyz. IN NS nameserver.sub.pippo.xyz.

Se i domini amministrati hanno uno o più server di posta elettronica, anche questo deve essere indicato qui. Il tipo di record usato è MX (Mail Exchange), seguito dall'indicazione di un numero che indica l'ordine in cui i vari server di posta debbano essere usati; prima si tenta con il numero più basso, gli altri vengono usati solo se il primo non è disponibile.

IN MX 10 mail

IN MX 20 qua.pippo.xyz.

Qui possono essere indicati anche i server di posta dei sottodomini:

sub.pippo.xyz. IN MX 10 mail.sub.pippo.xyz.

La regola del punto dopo il nome è la stessa di prima; in questo caso, per prima cosa si cerca di usare mail.pippo.xyz e, se si fallisce, si prova con qua.pippo.xyz.

Le voci NS e MX si trovano di solito solo nei file di zona diretti (forward).

Le voci degli indirizzi IP nel file di zona diretto

Il lavoro principale del nameserver consiste nel connettere gli indirizzi IP con i nomi e viceversa. Nel file diretto ci sono ora due tipi possibili di dato di questo tipo: il primo è contenuto nelle voci che connettono un nome con un indirizzo IP, cioè quelle di tipo A

qui IN A 199.45.67.1

quo IN A 199.45.67.2

qua IN A 199.45.67.3

Anche qui sarebbe stato possibile indicare i nomi completi, aggiungendo il punto finale.

La seconda forma di questo tipo di voci sono gli pseudonimi (nomi canonici), che si indicano con il tipo CNAME:

mail IN CNAME qui

www IN CNAME quo.pippo.xyz.

In questo modo, quindi, mail.pippo.xyz è in realtà identificato da qui.pippo.xyz e www.pippo.xyz è solo un altro nome per quo.pippo.xyz.

Le voci del file inverso

Il compito del file inverso è di connettere gli indirizzi IP con i nomi; è quindi il compito inverso di quello normalmente assegnato ai nameserver.

Il file inverso deve avere esattamente la stessa voce del record SOA di quello diretto. Invece dei nomi di dominio, però, vanno indicati gli indirizzi IP della zona:

67.45.199.in-addr.arpa....

L'ultimo numero dell'indirizzo (e/o la parte locale) viene omesso.

Invece delle voci A o CNAME, il file contiene ora le voci PTR, che puntano dagli indirizzi ai nomi:

1 IN PTR qui

2 IN PTR quo

3 IN PTR qua.pippo.xyz.

Le parti mancanti degli indirizzi IP vengono ricavati dal record SOA.

I programmi dig, nslookup e host

Tutti e tre questi programmi servono per eseguire query ai nameserver.

Il comando nslookup può essere usato in maniera interattiva da una shell da cui cambiare server, impostare le opzioni delle query e fare il debug dei DNS; lo stesso comando può essere usato in maniera non interattiva per dare semplici query.

dig è un altro utile strumento a linea di comando per raccogliere informazioni dai server DNS; infine, si può usare il comando host per le query più semplici.

I comandi interattivi di nslookup

qui.pippo.xyz

Restituisce l'indirizzo IP di qui.pippo.xyz

199.215.12.13

Restituisce il nome che corrisponde all'indirizzo IP indicato.

set querytype=ns

Imposta il tipo di query al record NS; le successive query daranno come risposta il record NS dell'host indicato.

set querytype=a

Torna alle normali query per i record A.

server server

Di default effettua le query a server

Opzioni interattive di nslookup

[no]recurse

Imposta la ricorsione nelle query. Se impostato a norecurse, fa query iterative.

querytype=tipo

Imposta il tipodi query a quello indicato.

retry=n

Invia la query n volte prima di smettere.

root=root server

Imposta il root server al server indicato.

timeout=n

Il tempo per il quale nslookup aspetta una risposta prima di uscire. Ad ogni tentativo questo tempo raddoppia.

Si possono salvare queste opzioni in un file .nslookuprc nella propria home directory; il formato del file è di un comando set per linea. Ad esempio:

set querytype=a

set domain=pippo.xyz

set timeout=20

Esempi di uso del comando dig

Per ottenere l'ultima lista di server root:

dig . ns

Per trovare i nameserver di una zona:

dig @server dominio ns

Per richiedere tutti i record di una zona da un server autoritativo:

dig @server dominio axfr

Nota: questo comando richiede un trasferimento di zona, che può non essere permesso dal server.

Per trovare il nome di dominio corrispondente all'indirizzo 212.104.3.123:

dig 212.104.3.123

Esempi di uso del comando host

Per trovare tutti i record di una zona:

host -l dominio

Per richiedere tutti i record di una zona:

host -lv -t any dominio

2.207.3 - Creare un server DNS sicuro

A prima vista il DNS è un servizio relativamente semplice, che non offre grandi pericoli potenziali. Se però guardiamo meglio, anche il semplice DNS è un potenziale strumento di attacco. Se un aggressore riuscisse a falsificare le voci di un server, potrebbe fare sì che i client che vogliono accedere ad un server vengano rediretti ad un altro computer, con tutte le conseguenze possibili, dal bypass delle email al furto di informazioni sensibili come i numeri di carta di credito.

Per questo motivo la sicurezza dei server DNS è oggi molto importante. Le tecniche indicate in questa sezione si riferiscono a diversi aspetti della sicurezza dei server DNS contro attacchi e falsificazioni.

Esecuzione di BIND con privilegi di utente normale

Inizialmente, i servizi venivano fatti partire tutti dagli script di inizializzazione, che appartengono a root. Se un servizio come BIND quindi viene fatto partire da lì (come ad es. da /etc/init.d/named), viene eseguito con l'ID di root; questo è un rischio inutile per la sicurezza, dato che Bind non ha bisogno di particolari privilegi.

Per questa ragione, il programma accetta due parametri che rendono possibile farlo eseguire come un altro utente:

u nomeutente

Fa partire named sotto l'utente indicato

g nomegruppo

Fa partire named sotto il gruppo indicato.

Invece dei nomi di utente e gruppo si possono indicare degli ID. L'unica condizione necessaria per portare avanti correttamente questa operazione è che l'utente e/o il gruppo indicati abbiano il permesso di leggere i file di configurazione di bind e quello di scrittura sui file da modificare, come ad esempio i dump della cache.

Di solito si usano l'utente e il gruppo named, e nello script di inizializzazione la chiamata a named viene fatta con i relativi parametri:

/usr/sbin/named u named g named

I permessi d'accesso per /etc/named.conf sono impostati in modo che l'utente abbia accesso in lettura al file di configurazione e di scrittura sulla directory dei log, /var/named:

rw-r ---- 1 root named... /etc/named.conf

drwxr xr x 4 named named... /var/named

Ora il nameserver può essere eseguito completamente come utente normale ed eseguire tutte le operazioni necessarie. Se il nameserver deve poter scrivere determinati file di log, l'utente named deve avere permessi di scrittura anche su questi.

Esecuzione di BIND sotto chroot

Un ulteriore livello di sicurezza può essere raggiunto eseguendo il server DNS sotto chroot. Per farlo si deve creare una nuova directory che, dal punto di vista del root server, è la directory di root; questa deve contenere tutte le sottoliste, i file e i programmi necessari. Inoltre, anche le librerie necessarie devono risiedere nell'ambiente di chroot. La configurazione minima consiste in:

+ bin

- ldconfig

- named

- named-xfer

+ dev

- null

- zero

+ etc

- group

- localtime

- named.conf

+ lib

- libc-2.*.so

- libc.so.6

- ld-2.*.so

- ld-linux.so.2

+ var

+ named

- 127.0.0.zone

- localhost.zone

- pippo.xyz.zone

- 67.45.199.in-addr.arpa.zone

+ run

Questi file e directory risiederanno ad esempio in /var/adm/named-environment. In questo caso la chiamata al nameserver nello script di inizializzazione diventerà:

chroot /var/adm/named-environment /usr/sbin/named u named g named

Meglio ancora usare il parametro -t di named che serve proprio per indicare l'ambiente di chroot:

/var/adm/named-environment/bin/named u named g named t

/var/adm/named-environment

Così la directory /var/adm/named-environment è diventata la root del sistema per quanto concerne il nameserver. In questo modo esso, anche volendo, non può accedere al resto del sistema: è imprigionato in una gabbia, dalla quale non c'è uscita.

In modo che il nameserver possa continuare ad usare syslog, si deve usare l'opzione:

syslogd A /var/adm/named-environment/dev/log

In questo modo viene creata una nuova socket all'interno dell'ambiente di chroot, su cui syslog resta in attesa.

In modo che anche ndc possa accedere al nameserver, si fare in modo che il file in cui trovare il PID del nameserver sia disponibile.

Uso delle dichiarazioni DS

Con l'aumento vertiginoso dell'utilizzo di Internet e il successivo moltiplicarsi degli attacchi verso i nameserver, venne creato il gruppo DNSSEC (DNS Security), che ha il compito di rendere il DNS più sicuro contro i cosiddetti attacchi di spoofing (risposte DNS false). Le versioni più recenti di BIND supportano anche questi metodi, che per questo non funzionano con le versioni precedenti, come la 4.9.

Il requisito di sicurezza più importante per un sistema di DNS è che le risposte alle query e i trasferimenti di zona vengano veramente dai server primari o secondari dai quale le si aspetta. Per assicurarsi ciò, il DNSSEC dà la possibilità di lavorare con coppie di chiavi che rendono possibile l'autenticazione e l'identificazione dei server.

Queste coppie di chiavi possono essere di tre tipi:

Chiavi di zona

per assicurarsi che la risposta venga veramente dal server autoritativo per la zona

Chiavi di host

per assicurarsi che un pacchetto provenga veramente dall'host da cui dice di provenire

Chiavi di utente

per assicurarsi che una email provenga veramente dall'utente indicato

Qui ci limiteremo al primo metodo, quello delle chiavi di zona.

Per generare delle chiavi che rispondono ai requisiti del DNSSEC, esiste il programma dnskeygen. Quindi, per esempio:

dnskeygen -D 1024 -z -n pippo.xyz.

Crea una coppia di chiavi di zona (-z) per la zona pippo.xyz (-n pippo.xyz.). Vengono creati due file, che contengono le chiavi pubblica e privata:

-rw-r--r-- 1 root root 572 Feb 27 16:37 Kpippo.xyz.+003+36569.key

-rw------- 1 root root 688 Feb 27 16:37 Kpippo.xyz.+003+36569.private

Il file con la chiave finale contiene già la chiave pubblica in un formato adatto per i file del nameserver; la si può aggiungere direttamente alla fine del file di zona:

cat KPIPPO.xyz.+003+36569.key >> /var/named/pippo.xyz.zone

Con l'aiuto del comando dnssigner e della chiave privata, ciascuna voce del nameserver può venire segnata in modo che venga garantito che viene veramente dal server corretto.

Nella voce della zona presente in /etc/named.conf può essere indicata una chiave da usare come chiave pubblica. Le parole chiave da usare sono:

pubkey flag protocollo alghoritmo chiave

Dati della chiave pubblica usata

key

Informazioni per l'autenticazione e le autorizzazioni

trusted key

Contiene le chiavi pubbliche da usare per il DNS sicuro.

Con l'aiuto delle chiavi si possono definire delle ACL (liste di controllo degli accessi) che indichino con chi il nameserver può colloquiare. Inoltre, si gestiscono:

le query semplici (allow query)

le query ricorsive (allow recursion)

i trasferimenti di zona (allow transfer)

Si può anche indicare chi non possa fare determinare operazioni.

Configurazione separata per i DNS forwarding

Il forwarding può essere usato su una grande rete per ridurre il traffico di dati verso i server esterni; viene usato per le zone per cui il server non è autoritativo e per cui i dati non sono già nella cache.

Con l'istruzione

forward only

nel blocco delle opzioni del file /etc/named.conf si può indicare che named non deve cercare di effettuare da solo la risoluzione dei nomi se le query verso i nameserver indicati nella direttive forwarders falliscono.

Quindi si deve inserire l'istruzione forwarders, che contiene l'elenco di server DNS a cui rivolgere le query

forwarders {IP_address; IP_address;

...};

Se questi dati non si trovano nel blocco delle opzioni, ma dentro le definizioni delle zone, ci si può assicurare che diversi server siano responsabili per diverse zone nella rete locale, senza che un utente esterno lo possa capire. In questo modo, infatti, sembrerebbe comunque che il nameserver che ha fatto la query memorizzi anche la risposta; in questo modo ci si assicura una minore probabilità che il server possa essere attaccato con il DNS spoofing.

Cambiamento del numero di versione

Già nella sezione 2.207.1 abbiamo visto la possibilità di indicare, con l'aiuto dell'opzione version, una versione diversa da quella reale quando questa venga richiesta dai server. In questo modo si aumenta anche la sicurezza del server, in quando conoscendo la versione del server, un aggressore può sfruttarne esattamente i punti deboli per riuscire ad entrare.

2.208.1 - Implementazione di un server Web

Configurazione dei log del server

Il formato di output delle voci dei file di log può essere indicato tramite parole chiave nel file httpd.conf. Inoltre, sono necessarie due operazioni: per prima cosa, con la direttiva LogFormat si indica un formato e gli si dà un nome; se ne possono creare più di uno. Poi, globalmente o per ciascun virtual host, si indica una direttiva CustomLog seguita dal nome del file di log in cui scrivere e il nome del formato da usare.

L'istruzione LogFormat

La forma dell'istruzione usata è la seguente:

LogFormat format|nickname [nickname]

All'interno della stringa di formato possono essere usate numerose variabili:

Variabile	Significato
%a	Indirizzo IP del client
%A	Indirizzo IP del server
%B	Byte inviati, senza considerare gli header HTTP
%b	Byte inviati senza considerare gli header HTTP nel formato CLF, cioè ad esempio – invece di 0 se non sono stati inviati byte
%c	Stato di connessione dopo il completamento della risposta: 'X' = connessione interrotta '+' = la connessione può essere mantenuta attiva dopo l'invio della risposta '-' = la connessione verrà chiusa dopo l'invio della risposta
%{PIPPO}e	Contenuto della variabile d'ambiente PIPPO
%f	Nome del file
%h	Hostname del client
%H	Protocollo di richiesta
%{Pippo}i	Contenuto dell'header Pippo (nella richiesta inviata al server)
%l	Nome del log remoto (su identd, se possibile)
%m	Metodo della richiesta
%{Pippo}n	Contenuto della nota Pippo di un altro modulo
%{Pippo}o	Contenuto dell'header Pippo nella risposta del server
%p	Porta canonica del server che risponde alla richiesta
%P	L'ID del processo figlio che risponde alla richiesta
%q	La stringa di query
%r	La prima linea della richiesta
%s	Stato. Per le richieste redirette internamente, è lo stato della richiesta originale; per l'ultima richiesta si indica %>s
%t	Ora in formato standard inglese
% {format}t	L'ora in formato arbitrario, dato da strftime(3) e quindi potenzialmente localizzato.
%T	Il tempo, in secondi, necessario per rispondere alla richiesta
%u	L'utente remoto
%U	L'URL richiesto con le eventuali stringhe di query
%v	Il nome canonico del server che risponde alla domanda.
%V	Il nome del server secondo UseCanonicalName.

Un esempio di applicazione di queste variabili potrebbe essere:

LogFormat "%h %l %u %t \"%r\" %>s %b" miolog

CustomLog /var/log/apache/access.log miolog

Qui abbiamo prima un formato di log e lo abbiamo chiamato miolog; poi, abbiamo determinato con CustomLog che il file /var/log/apache/access.log deve essere riempito in questo formato. A questo punto, in questo file ci saranno solo voci che seguono il formato determinato con LogFormat.

Configurazione di mod_perl

Normalmente gli script in Perl non vengono elaborati direttamente da Apache, ma usando il sistema del cancelletto e punto esclamativo (#!...) viene eseguito un interprete Perl che richiama lo script, il cui output poi viene passato al server Web ed inviato al client.

Dato che questo tipo di implementazione è relativamente lenta, dato che pre ciascuno script deve essere caricato l'interprete Perl, è stata creata una forma di Perl embedded. Il modulo di Apache mod_perl fa sì che sia il server Web a fungere da interprete Perl, potendo così direttamente eseguire programmi Perl.

Dopo l'installazione del modulo, il file di configurazione del server Web deve essere adattato in alcuni punti, in modo che mod_perl venga caricato ed attivato.

Le configurazioni necessarie in httpd.conf sono:

...

# Caricamento del modulo Perl

LoadModule perl_module /usr/lib/apache/1.3/mod_perl.so

...

# Defimizione del gestore per gli script Perl

AddHandler perl-script .pl

PerlHandler Apache::Registry

PerlSendHeader On

...

# Quando il modulo è installato, lo si carica

<IfModule mod_perl.c>

Alias /perl/ /var/www/perl/ # Gli script Perl possono essere

# anche qui

<Location /perl>

SetHandler perl-script

PerlHandler Apache::Registry

Options +ExecCGI

</Location>

</IfModule>

Con questa configurazione ora è possibile eseguire gli script Perl che si trovano in /var/www/perl direttamente dal server Web. Le uniche condizioni sono che il server abbia accesso alla directory e che gli script in essa contenuti siano eseguibili.

Gli script non devono necessariamente iniziare con una riga #!, e se questa è presente non viene letta.

Configurazione di mod_php

Il linguaggio PHP, al contrario del Perl, offre la possibilità di inserire parti di codice direttamente all'interno dei file HTML e farle eseguire poi al server Web. Questi file hanno l'estensione php o php3 (per la versione più vecchia) e vengono elaborati prima di essere inviati al client.

Per far sì che il server Web possa elaborare il PHP, deve essere installato il modulo mod_php. Anche in questo caso sono necessarie alcune modifiche all'httpd.conf.

...

# Caricamento del modulo

LoadModule php4_module /usr/lib/apache/1.3/libphp4.so

...

# Associazione dell'applicazione con l'estensione

AddType application/x-httpd-php .php

AddType application/x-httpd-php-source .phps

Dopo aver riavviato Apache (/etc/init.d/apache restart), il PHP dovrebbe essere disponibile.

Supervisione degli accessi da determinati computer

Alcune directory (o URL o file) devono essere poter visti solo da determinati computer o domini. Per poter fare ciò ci sono alcune istruzioni che devono essere inserite in httpd.conf.

All'inizio c'erano tre diverse istruzioni che usavano lo stesso formato simile all'HTML: si trattava di tag tra parentesi angolate con i corrispondenti tag di chiusura con lo slash:

Directory	File	URL
<directory "nomedir"> istruzioni </directory>	<files "nomifile"> istruzioni </files>	<location "URL"> istruzioni </location>

La differenza tra location e directory è semplicemente che quest'ultima si riferisce ad un percorso assoluto, mentre l'URL è l'indirizzo visto dal server Web e non è necessario sapere in quale directory il file si trovi veramente.

Per poter escludere o comprendere determinati computer o nomi di dominio dalla visione di file o directory, è sufficiente inserire le relative istruzioni nelle corrette dichiarazioni.

Per prima cosa va indicato l'ordine in cui queste istruzioni vengono elaborate: si usa per questo la direttiva order, che permette solo due possibilità:

Order allow, deny

o

Order deny, allow

Le singole regole diventano:

Deny from nomecomputer o IP

Allow from nomecomputer o IP

I dati relativi ai nomi dei computer o agli IP seguono il seguente formati:

Il termine all

Tutti i client, non importa quale sia il loro nome o indirizzo

Un nome di dominio come miodominio.it

Tutti i computer membri di tale dominio

Un indirizzo IP completo come 123.45.67.89

Il solo computer con quell'indirizzo

Un indirizzo IP incompleto come 10.230

Tutti i computer il cui indirizzo IP inizia con 10.230

Un indirizzo con la maschera, come 10.230.0.0/255.255.0.0 o 10.230.0.0/16

Tutti i computer delle sottoreti indicate

Facciamo due esempi:

<Directory /usr/local/httpd/htdocs/test>

Order allow,deny

Allow from all

</Directory>

La directory /usr/local/httpd/htdocs/test può essere vista da tutti; invece avremmo potuto scrivere:

<Directory /usr/local/httpd/htdocs/test>

Order deny,allow

Deny from all

Allow from 10.230

</Directory>

La directory può così essere vista solo dai computer della rete 10.230.x.y.

Autenticazione degli utenti con mod_auth

Ciascuno degli elementi sopra indicati può essere soggetto anche ad una autenticazione da parte degli utenti; per prima cosa si devono inserire gli utenti e i gruppi, in questo modo:

AuthUserFile /etc/httpd/passwd

AuthGroupFile /etc/httpd/group

I nomi e i percorsi dei file possono essere qualsiasi; se non cominciano con una slash (e quindi non sono percorsi assoluti) vengono cercati nella directory principale del server. Il file delle password contiene una linea per utente nel formato:

nomeutente: lock password

il file dei gruppi, invece, ha il formato:

nomegruppo: utente1 utente2 utente3

Per inserire le password nel file relativo, si usa il comando htpasswd. Il file dei gruppi può essere modificato con qualsiasi editor. La sintassi di htpasswd è, se il file non esiste ancora:

htpasswd C password file utente

Se il file già esiste si deve omettere la C.

Ci servono poi ancora due informazioni: il tipo di autenticazione e una linea che venga indicata nella finestra di dialogo delle password; perché possa funzionare sono necessarie entrambe.

AuthType basic

AuthName "nome delle risorse"

Con l'istruzione Require si possono formulare ora delle condizioni da soddisfare per poter accedere alle directory; tale istruzione deve essere in una delle seguenti forme:

Require user nomeutente

Solo l'utente o gli utenti indicati, separati da spazi, possono accedere alla directory (o all'URL o al file).

Require group nomegruppo

Solo i membri del gruppo o dei gruppi indicati possono accedere.

Require valid user

Qualsiasi utente valido del sistema (cioè chiunque abbia una voce nel file delle password indicato) può accedere.

Il seguente esempio mostra una directory protetta in questo modo:

<Directory /usr/local/httpd/htdocs/test>

AuthType basic

AuthName "Directory segretissima"

AuthUserFile /etc/httpd/passwd

Require user eugy

</Directory>

In questo modo directory diverse possono essere rese accessibii a utenti diversi, senza che le relative voci nel file delle password interferiscano tra di loro. Teoricamente è anche possibile mettere il file delle password dentro la directory protetta, anche se è meglio non farlo per questioni di sicurezza.

Per dare a diversi utenti la possibilità di creare tali configurazioni, una possibilità molto elegante è quella di usare i file htpaccess; si tratta di file contenuti direttamente nella directory protetta, uguali a quelli visti prima. Tali file vengono letti automaticamente dal server Web ogni volta che si tenta un accesso. In questo modo non c'è bisogno di riavviare il server ogni volta che si fa una modifica alla configurazione. Il nome di questi file normalmente è htaccess, ma non è necessario che sia così, basta cambiare il file di configurazione generale con la direttiva

AccessFileName .htaccess

Inoltre, è possibile usare la direttiva AllowOverride, che indica se le configurazioni del file centrale possano essere sovrascritte da quelle dei singoli file. Tale istruzione ha validità solo all'interno delle direttive <Directory>, e le sue forme principali sono:

AllowOverride None

I file di accesso nelle directory non vengono letti

AllowOverride all

Tutte le direttive valide nei file di configurazione delle singole directory vengono lette.

AllowOverride AuthConfig

Le direttive di autenticazione e di autorizzazione vengono considerate, le altre no.

AllowOverride Fileinfo

Vengono considerate le direttive che controllano gli attributi del documento

AllowOverride Indexes

Vengono considerate le direttive di indicizzazione delle directory

AllowOverride Limit

Vengono considerate le direttive di controllo sugli accessi

AllowOverride Options

Vengono considerate le direttive che controllano specifiche caratteristiche delle directory

Un esempio di file degli accessi potrebbe essere quindi:

# .htaccess

AuthType Basic

AuthName "Dir segreta"

AuthUserFile /etc/httpd/passwd

Require valid-user

# Qui vogliamo che possano essere eseguiti script CGI

Options +ExecCGI

# Possono accedere solo i computer della rete 10.230

Order deny,allow

Deny from all

Allow from 10.230

Opzioni del server

ServerType standalone|inetd

Indica se il server Web deve essere eseguito da solo o tramite inetd. Farlo partire da inetd non è consigliabile, quindi in genere si usa il termine standalone.

ServerRoot "/usr/local/httpd"

L'indicazione della directory nella quale Apache trova i suoi file; da non confondere con la DocumentRoot, che contiene i file da rendere disponibili agli utenti.

Port 80

Indica il numero di porta su cui il server Web è in esecuzione. La porta standard per l'HTTP è la 80. Se si indica una porta inferiore alla 1024, il server Web deve essere avviato da root; non si tratta però di una falla di sicurezza, perché poi il server Web esegue i processi sotto un altro ID utente.

User nomeutente

L'ID utente sotto cui vengono eseguiti i processi figli del server.

LockFile /var/lock/subsys/httpd/httpd.accept.lock

Il file di lock del server; viene creato dal server quando questo parte e cancellato quando si ferma. In questo modo il server può sapere se c'è già un'istanza di Apache caricata in memoria.

PidFile /var/run/httpd.pid

Anche questo file viene creato dal server quando esso parte; contiene l'ID del processo del server stesso.

Timeout 300

Il numero di secondi per cui il server resta in attesa in quando invia o riceve dati, prima di inviare un errore di Timeout.

Alias pseudonimo nomereale

Rende possibile utilizzare directory al di fuori della DocumentRoot del server. Lo pseudonimo è un'indicazione del percorso relativo alla DocumentRoot, il nome reale è il percorso assoluto della directory, dal punto di vista del sistema. Se lo pseudonimo finisce una slash, la slash deve essere indicata anche nell'URL, perché non esiste pseudonimo senza slash.

KeepAlive on

KeepAlive rende possibile permettere (on) o vietare (off) più trasferimenti per connessione. In questo modo si evita di dover fare l'handshake TCP ogni volta.

MaxKeepAliveRequests 100

Questo valore determina il numero massimo di richieste su una connessione persistente; se è 0 non ci sono restrizioni.

KeepAliveTimeout 15

Il numero di secondi dalla trasmissione di un file alla successiva richiesta, per cui si può evitare di fare l'handshake.

Startservers 1

Il numero di processi server da caricare all'avvio.

MinSpareServers 1

Il numero minimo di processi server inutilizzati (figli); se si va sotto questo valore, vengono avviati nuovi server.

MaxSpareServers 1

Il numero massimo di processi server inutilizzati (figli); se si va sopra questo valore, dei server vengono chiusi.

MaxClients 150

Il numero massimo di connessioni TCP contemporanee. Se ne arrivano più, quelle in eccesso non vengono servite e viene restituito un messaggio d'errore.

MaxRequestsPerChild 0

Dopo il numero indicato di richieste elaborate, un processo figlio viene ucciso e sostituito con un altro. Se il valore è 0 non si ha questa sostituzione, e il numero è quindi infinito. Impostando questa opzione ad un numero finito, si evita che i processi potenzialmente rimasti appesi possano disturbare il server.

2.208.2 - Amministrazione di un server Web

Server virtuali

La terza sezione del file di configurazione principale di Apache contiene la definizione dei server virtuali; un singolo server Web, in questo modo, può gestire le pagine di vari domini con una configurazione separata per ciascuno di essi.

La definizione dei server virtuali rende possibile decidere come comportarsi, a seconda del nome e dell'indirizzo IP con cui viene richiamato il server. In genere in questo modo si gestiscono DocumentRoot diverse a seconda del dominio utilizzato.

Linux per questo scopo offre la possibilità di configurare più indirizzi IP sulla stessa scheda Ethernet; il nome dell'interfaccia viene fatto seguire da due punti e da un numero: eth0:1, eth0:2.... Ognuna di queste interfacce virtuali può essere quindi associata ad un suo indirizzo IP, con l'istruzione:

ifconfig eth0:1 indirizzo netmask mask

Il server Web può reagire a questo secondo (o terzo, quarto etc) indirizzo, se ha una sua voce nel nameserver. Per farlo, nel file di configurazione deve essere presente una voce di questo tipo:

NameVirtualHost indirizzoIP

Questa voce è necessaria solo se si vogliono gestire più server virtuali basati sul nome. L'indirizzo IP deve essere quello della scheda.

Ora possiamo definire i server Web virtuali; i dati tra le parentesi angolate possono essere associati con gli indirizzi IP (della mappa virtuale) o con i nomi di dominio (voci di alias nel name server, che si riferiscono ad un indirizzo della mappa virtuale).

Ciascuna di queste voci ora può avere la sua DocumentRoot e delle direttive specifiche tra quelle discusse finora. Un esempio può essere:

NameVirtualHost 10.230.1.101

<VirtualHost 10.230.1.101>

ServerAdmin root@qui.pippo.xyz

DocumentRoot /www2

ServerName www2.pippo.xyz

</VirtualHost>

<VirtualHost 10.230.1.101>

ServerAdmin eugy@qui.pippo.xyz

DocumentRoot /www3

ServerName www3.pippo.xyz

<Directory /www3/specialdir>

AllowOverride All

</Directory>

</VirtualHost>

Qui abbiamo definito due host virtuali, definiti sullo stesso indirizzo IP ma con diverso nome. Naturalmente, il secondo nome deve essere presente anche nel nameserver come alias del primo.

All'interno della direttiva <VirtualHost> possono stare tutte le configurazioni possibili per il server principale. In questo modo i server virtuali possono essere completamente indipendenti, con i propri script CGI, ad esempio. Il seguente esempio mostra due host virtuali, con directory e script CGI diversi.

<VirtualHost 10.230.1.105>

ServerAdmin root@qui.pippo.xyz

DocumentRoot /www1/htdocs

ScriptAlias /cgi-bin/ "www1/cgi-bin/"

ServerName virtual1.pippo.xyz

</VirtualHost>

<VirtualHost 10.230.1.106>

ServerAdmin eugy@qui.pippo.xyz

DocumentRoot /www2/htdocs

ScriptAlias /cgi-bin/ "www2/cgi-bin/"

ServerName virtual2.pippo.xyz

</VirtualHost>

I certificati SSL

Installando il pacchetto apache-ssl si può creare un certificato manualmente; tale certificato, però, può essere usato solamente per i test: perché sia utilizzato appieno deve essere firmato da una authority di certificazione.

Durante l'installazione del pacchetto, vengono prodotti due file; uno contiene il certificato di richiesta, il secondo la chiave privata, e da queste viene creato un file che contiene il certificato firmato, che viene messo sotto /etc/apache-ssl, in un file con estensione .pem.

L'ultima operazione che viene fatta è attivare tale certificato nel file di configurazione.

Attivazione dell'SSL

Nel file httpd.conf deve essere inserita la seguente direttiva:

SSLCertificateFile /etc/apache-ssl/apache.pem

#SSLCertificateKeyFile /etc/apache-ssl/chiave.pem

La prima direttiva indica il file del certificato SSL; la seconda serve solamente se il file del certificato e quello della chiave sono diversi.

Il server Apache SSL resta in ascolto sulla porta 443; per questo dovranno essere attivate le direttive

Port 443

Listen 443

Più sotto, con le direttive SSLVerifyClient, SSLVerifyDepth, SSLRequire, SSLOptions e SSLRequireSSL possono essere indicati esattamente i client a cui è permesso collegarsi al server. Di solito, però, lo scopo di un server SSL è solo garantire che il server sia realmente chi dice di essere, e che la trasmissione dei dati avvenga su una connessione sicura.

Ulteriori informazioni su Apache SSL

La homepage di Apache-ssl (inglese): http://www.apache-ssl.org

La direttiva Redirect

La direttiva Redirectnell'httpd.conf serve a reindirizzare un URL in uno nuovo. Tutte le richieste che vengono fatte al vecchio URL vengono reinviate al nuovo.

La sintassi di questa istruzione è:

Redirect [ status ] pathvecchioURL nuovoURL

Ad esempio, quindi, l'istruzione

Redirect /test http://www.pippo.xyz/test

redirige tutte le richieste della directory /test a'URL http://www.pippo.xyz/test/foobar.html.

L'argomento opzionale status può avere i seguenti valori:

permanently

Il server restituisce il codice 301 nella risposta, riferendosi così ad una redirezione permanente.

temp

Il server restituisce il codice 302 nella risposta, riferendosi così ad una redirezione temporanea. Se non si indica lo status, questo è il default.

seeother

Il server restituisce il codice 303, che indica che la risorsa è stata sostituita.

gone

Il server restituisce il codice 410, che indica che la risorsa è stata cancellata in modo permanente. In questo caso non si ha una redirezione, e l'argomento nuovoURL deve essere omesso.

2.208.3 - Implementazione di un server proxy

Configurazione di SQUID

L'intera configurazione del server proxy viene gestita, come avviene anche per Apache, da un solo file: squid.conf, che di solito si trova in /etc; si tratta di un file che può essere molto complesso, con circa 200 direttive diverse, alcune delle quali possono comparire più volte. Ne elenchiamo alcune delle più importanti.

http_port [hostname:|indirizzoIP:] porta

Il numero di porta sul quale resta in ascolto Squid. Se si specifica un hostname o un indirizzo IP, Squid si lega ad una socket su quell'indirizzo. Nella maggior parte dei casi è sufficiente indicare solo il numero della porta. Si possono usare più comandi di questo tipo per far ascoltare Squid su più porte.

cache_mem quantitàMB|KB

La dimensione della memoria principale per vari tipi di oggetti, come gli oggetti in transito, gli oggetti “hot” e quelli non in cache. Non è la memoria globale usata come cache!

cache_dir tipo directory dimcache l1 l2 [opzioni]

Indica in quale directory viene memorizzata la cache. Il tipo è il formato usato per la memorizzazione dei dati; normalmente è abilitato solo ufs, il formato standard di Squid, e per abilitarne altri si deve ricompilare. Directory è il percorso per la directory in cui viene contenuta la cache; deve esistere, aver sufficiente spazio libero ed essere scrivibile da Squid. Dimcache è la dimensione della cache, che di default è 100MB; non si deve indicare la dimensione totale del disco, ma è meglio sottrarre ad essa almeno il 20%. L1 è il numero delle sottodirectory di primo livello che vengono create nella directory della cache, di default 16, e l2 è il numero di sottodirectory di secondo livello, di default 256. Le opzioni più comuni sono: max-size, che indica la dimensione massima di un oggetto memorizzato in cache, e read-only, che fa sì che la cache sia di sola lettura. Un esempio di uso è

cache_dir ufs /var/spool/squid 100 16 256

Volendo un sistema replicato, si devono inserire alcune altre ACL e regole di accesso, che saranno descritte più avanti; intanto ecco una configurazione minimale:

cache_mem 8 MB

cache_dir ufs /var/spool/squid 100 16 256

acl manager proto cache_object

acl localhost src 127.0.0.1/255.255.255.255

acl all src 0.0.0.0/0.0.0.0

acl allowed_hosts src 192.168.10.0/255.255.255.0

http_access allow manager localhost

http_access deny manager all

http_access allow allowed_hosts

http_access deny all

icp_access allow allowed_hosts

icp_access deny all

Controllo degli accessi con le ACL

Il controllo degli accessi sotto Squid funziona con le ACL, che non limitano i diritti di accesso, ma definiscono solo un elenco, che poi può essere associato ai diritti di accesso da usare.

La definizione delle ACL può essere fatta in due modi:

acl nomeACL TipoACL Elemento1 Elemento2...

In questo modo viene creata una lista con il nome nomeACL e il tipo TipoACL, che contiene gli elementi Elemento1 ed Elemento2. L'altro metodo è prendere il contenuto da un file, così:

acl nomeACL TipoACL "nomefile"

Le virgolette intorno al nome del file fanno sì che Squid non pensi che il file sia un elemento della lista.

Ciascuna ACL deve avere un nome chiaro ed univoco. Se ci sono due ACL che fanno riferimento allo stesso nome, vengono gestite in maniera additiva, cioè la costruzione

acl ATTEMPT src 192.168.1.1/32

acl ATTEMPT src 192.168.1.2/32

è equivalente a

acl ATTEMPT src 192.168.1.1/32 192.168.1.2/32

Squid offre moltissimi tipi di ACL, che permettono di usare diversi criteri per la formulazione dei diritti d'accesso. I più importanti sono:

arp MacAddress...

Un elenco di MAC address separati da spazi

acl ATTEMPT arp 00:00:11:22:33:44 00:33:44:55:66:77

src IPaddress/netmask...

Prende come argomento un elenco di indirizzi IP e netmask. Le netmask possono essere indicate sia in forma breve (come /24) sia in forma classica (ad es. /255.255.255.0). L'elenco indica gli indirizzi del client che possono usare Squid.

acl ATTEMPT src 192.168.1.0/24 192.168.100.7/255.255.255.255

dst IPaddress/netmask...

La stessa cosa di src, ma indica gli indirizzi dei server a cui Squid può accedere.

srcdomain nomedominio...

Un elenco di nomi di dominio per cui deve essere fatta una ricerca inversa nel DNS prima di poterli usare. Questo tipo di ACL porta ad un rallentamento delle operazioni. Gli indirizzi indicati sono quelli dei client che devono poter usare Squid. Il dominio deve iniziare con un punto

acl ATTEMPT srcdomain .miodominio.it .altrodominio.it

dstdomain nomedominio...

Come srcdomain, ma si riferisce ai server Web a cui Squid può accedere.

time [giorno] h1:m1-h2:m2...

Elenco delle finestre temporali da usare. Il giorno è il giorno della settimana, indicato come segue: M=lunedì, T=martedì, W=mercoledì, H=giovedì, F=venerdì, A=sabato, S=domenica. Le istruzioni h1:m1 e h2:m2 indicano le ore e i minuti.

acl ATTEMPT time 09:30 17:00 # ogni giorno dalle 9:30

# alle 17:00

acl ATTEMPT time S 00:00 23:59 # tutte le domeniche

url_regex [-i] regexp...

Una lista di espressioni regolari a cui devono corrispondere gli URL. Lo switch opzionale -i indica che non si deve tener conto delle maiuscole e delle minuscole.

acl ATTEMPT url_regex HTTP://.* ftp://.*

urlpath_regex [-i] regexp...

Una lista di espressioni regolari a cui devono corrispondere gli URL ma senza protocollo e hostname. Tali espressioni regolari sono case-sensitive, a meno che non si indichi l'opzione -i.

acl ATTEMPT urlpath_regex -i \.gif$ \.jpg$ \.png$

port numeroporta...

Una lista di indirizzi di porta di destinazione, sia singoli che intervalli (separati con un trattino).

acl ATTEMPT port 80 81 443 1234-1299

proto protocollo...

Un elenco di protocolli accettati da Squid

acl ATTEMPT proto ftp HTTP

browser [-i] regexp...

Una lista di epressioni regolari che indicano il browser del client (il valore dell'header user-agent nella richiesta).

acl ATTEMPT browser [mM]ozilla.*

proxy_auth nomeutente...

Una lista di nomi utente che si assumono autenticati attraverso un processo esterno. La parola chiave REQUIRED per accettare un qualsiasi nome utente valido.

acl ATTEMPT proxy_auth eugenia daniela chris

proxy_auth_regex [-i] regexp...

Come proxy_auth, ma invece dei nomi utente vengono usate delle espressioni regolari.

Se nelle ACL vengono formulati gli elenchi corretti, si può poi assegnare ad essi le regole di accesso corrette. Per questo scopo sono disponibili diversi tipi di regole; il tipo di regola deve essere fatto seguire da allow o deny e da uno o più nomi di ACL. Se i nomi delle ACL vengono fatti precedere da un punto esclamativo, l'operazione viene negata.

acl ATTEMPT src 192.168.1.0/24

http_access allow ATTEMPT

Nell'esempio, viene fornita per prima cosa una ACL ATTEMPT, che contiene tutti i computer della rete 192.168.1.0. Nella seconda istruzione viene indicato che le richieste HTTP per questa ACL sono permesse. Se un client ha quindi un indirizzo che inizia per 192.168.1, può fare richieste HTTP.

Se nessuna delle linee “access” corrisponde, il default è l'inverso dell'ultima linea della lista. Se l'ultima linea era deny, il default sarà allow e viceversa. Per questo è sempre bene terminare la lista con “deny all” o “allow all” per evitare confusione.

Le regole di accesso più importanti sono:

http_access

Permette o vieta l'accesso http secondo le ACL.

always_direct

Definisce le richieste che devono essere sempre reindirizzate al server originale, senza usare la cache.

never_direct

Definisce le richieste che non devono essere mai reindirizzate al server originale, senza usare la cache.

Autenticazione degli utenti

Squid può regolare l'accesso ai suoi servizi ai soli utenti autenticati. Spesso conviene usare questo approccio invece di basarsi sugli IP o sui nomi di dominio, in particolare se si sta usando un sistema time sharing come Linux.

Se un accesso viene rediretto tramite l'ACL proxy_auth, l'utente deve essere autenticato. I modelli di autenticazione sono molti: si possono usare le password Unix o servizi esterni come i server di autenticazione Windows, LDAP o PAM.

La procedura da seguire è più o meno sempre la stessa:

Il client passa una richiesta a Squid

Squid risponde con 401 (Unauthorized) e fa aprire al browser una finestra in cui si richiede utente e password

Il client ripete la richiesta con utente e password nell'header

Squid esamina i dati sulla base del metodo indicato nel file di configurazione

Il modulo di autenticazione risponde al proxy con OK ONE o ERR, e il proxy di conseguenza risponde o si rifiuta di farlo.

Con l'aiuto della direttiva auth_param si possono indicare i programmi da usare per l'autenticazione.

Ulteriori informazioni su Squid

Lo Squid book, su http://merlino.merlinobbs.net/Squid-Book/ (in italiano)

La home page di Squid su http://www.squid-cache.org/ (in inglese)

2.212.2 Configurazione di un router

Il kernel Linux, in ciascuna delle sue versioni principali, ha introdotto una nuova tecnologia per amministrare le regole per i filtri dei firewall. La prima generazione (kernel 2.0.x) portò il programma ipfwadmin, nella successiva (kernel 2.2.x) questo venne rimpiazzato da ipchains. Il kernel attuale (a partire dalla versione 2.4.x) usa iptables. Sui moduli si possono anche usare kernel moderni con metodi più vecchi.

Nel seguito verranno discussi i due metodi ipchains e iptables. I metodi più vecchi non sono più richiesti e nella pratica non sono più usati.

Significato degli indirizzi privati per quanto riguarda la sicurezza

Gli indirizzi IP privati sono indirizzi che non possono essere visibili in Internet. Anche se dovessero essere visibili, non possono essere raggiunti perché possono essercene infiniti. Per tale motivo le reti locali che debbano essere non accessibili dall'esterno dovrebbero sempre essere gestite con questi indirizzi. Gli indirizzi privati sono:

Classe A: 10.0.0.0

Classe B: da 172.16.0.0 a 172.31.0.0

Classe C: da 192.168.0.0 a 192.168.255.0

Se una rete internamente funziona con questi indirizzi, un attacco dall'esterno non può avvenire in nessun modo poiché i singoli computer non sono visibili dall'esterno.

NAT/Masquerading

Affinché, nonostante l'uso di indirizzi privati, i membri di una rete locale possano avere accesso ad Internet si ha bisogno di un router che trasmetta i pacchetti dalla rete locale ad Internet. Tuttavia li indirizzi registrati negli header degli IP sono privati, ovvero un server in internet non potrebbe mandare risposta a domande provenienti da computer nella rete locale.

Per tale motivo il router può effettuare una traslazione degli indirizzi privati verso il proprio indirizzo. Inevitabilmente il router deve avere un indirizzo IP pubblico, altrimenti non potrebbe avere accesso a Internet. A questo punto il router riceve pacchetti dalla rete locale, rimpiazza gli indirizzi di ritorno con il proprio, e li annota in una tabella del kernel. Solo a questo punto trasmette realmente i pacchetti in internet. Un server in internet riceve il pacchetto con l'indirizzo valido del router; la risposta viene quindi mandata al router, che controlla in base alla tabella a quale computer la risposta va mandata e infine sostituisce l'indirizzo IP locale del ricevente con quello del router. Solo a questo stadio il pacchetto di risposta viene mandato al mandante originale.

Tale tecnologia fa sì che tutti i computer in una rete, dal punto di vista dell'accesso a internet, possiedano un unico indirizzo IP che corrisponde a quello del router. Un server in internet non può distinguere i singoli computer e comunica soltanto con il router. In tal modo si ha il vantaggio che il router è la sola superficie di attacco disponibile ad aggressori esterni.

Attivazione del masquerading con ipchains

In un router con ipchains si deve specificare una catena di regole di forward, che permetta il masquerading come politica di trasmissione. Supponiamo di avere un'interfaccia esterna eth1 e che l'indirizzo della rete privata sia 192.168.100.0. In tal caso la linea di comando appropriata per il router diventa:

EXTERNAL_INTERFACE=eth1

ipchains -A forward -i $EXTERNAL_INTERFACE -s 192.168.100.0/24 -j MASQ

che tradotto significa:

La regola seguente si applica alla catena di forward (- A forward): se sull'interfaccia esterna della rete privata emergono pacchetti (- i) con l'indirizzo di trasmissione indicato (- s), allora devono essere mascherati (- j MASQ)

Attivazione del masquerading con iptables

iptables non solo amministra la catena di regole come ipchains, ma gestisce anche tabelle per determinate procedure. Una delle tabelle standard si utilizza in particolare per il masquerading e per il NAT (Network Address Translation). La tabella che si occupa del NAT viene di conseguenza chiamata nat.

Per utilizzare iptables quindi si deve caricare un ulteriore modulo per il NAT, ovvero iptable_nat.

EXTERNAL_INTERFACE=eth1

iptables -t nat -A POSTROUTING -o $EXTERNAL_INTERFACE -j MASQUERADE

E' meglio tuttavia, invece che l'istruzione -j MASQUERADE, utilizzare l'istruzione -j SNAT, se non altro nel caso in cui si gestisca la connessione a internet di un indirizzo IP dinamico. Secondo questa indicazione risulta che la rete deve essere mascherata. Questo può essere indicato con -- to-source:

EXTERNAL_INTERFACE=eth1

iptables -t nat -A POSTROUTING -o $EXTERNAL_INTERFACE -j SNAT\

--to-source 192.168.1.1-192.168.100.17

Port forwarding

Il port forwarding è, in parole povere, l'esatto opposto del NAT, cioè possiamo immaginare che rappresenti un tipo di destinazione NAT piuttosto che una sorgente NAT. Come funziona?

Se una rete locale è connessa ad internet tramite un indirizzo privato attraverso un router NAT, nessun computer da internet può avere accesso al computer nella rete locale. Questo di solito è auspicabile, anche se in casi eccezionali si può volere che un computer nella rete locale funzioni anche da server. Supponiamo che un computer della rete privata debba essere un webserver che ascolti richieste TCP dall'esterno verso la porta 80. Quello che ci serve quindi è un NAT che funzioni nella direzione opposta, ovvero che permetta la mappatura degli indirizzi verso l'interno della rete locale e sulla base di criteri diversi (numeri delle porte).

Port forwarding con ipchains

ipchains non può inizializzare il port forwarding. Esiste allora a tale scopo un programma, chiamato ipmasqadm. Ad esempio, per pacchetti che vanno dall'esterno verso la porta 80 TCP i quali debbano essere passati al computer con indirizzo IP locale 192.168.100.17 possiamo scrivere:

EXT_IP_ADDR=199.232.12.23

ipmasqadm portfw -a -P tcp -L $EXT_IP_ADDR 80 -R 192.168.100.17 80

La variabile EXT_IP_ADDR si riferisce all'indirizzo IP reale che compare in internet e che è quello posseduto dal router verso l'esterno.

Port forwarding con iptables

Il programma iptables analizza la situazione con più logica e sa che il port forwarding è equivalente a un NAT. Per tale motivo, come nell'esempio precedente, si utilizza la tabella nat nel modo seguente:

iptables -A PREROUTING -t nat -p tcp -d $EXT_IP_ADDR --dport 80 \

-j DNAT --to 192.168.100.17:80

DNAT rappresenta la destinazione-NAT e, come detto prima, dà la conversione dell'indirizzo del ricevente.

Definizione delle regole del firewall

La seguente non può essere soltanto una breve trattazione delle regole necessarie alla configurazione di un firewall poiché ssarebbe necessario un manuale intero per ipchains e uno per iptables. Di conseguenza quelli che seguono sono soltanto i rudimenti di alcune tecniche.

Ciascuna regola si riferisce alle tre catene di filtri standard INPUT, OUTPUT e FORWARD. Ciascuna di queste catene di regole deve possedere dall'inizio una regola di permessi dalla quale segua che:

è proibito tutto ciò che non è permesso (DENY) oppure

è permesso tutto ciò che non è proibito (ACCEPT)

Certamente il primo metodo è più sicuro, anche se richiede un po' più di lavoro per la configurazione delle regole.

Ciascuna regola conosce l'indirizzo IP (e la porta) della macchina che trasmette (-s) e di quella che riceve (-D) e i criteri usati per decidere se un pacchetto debba essere lasciato passare oppure no.

Inoltre si possono avere anche informazioni sul protocollo utilizzato (tcp, udp, icmp), con l'opzione -p e anche a quale interfaccia (network map) la regola si riferisce.

Infine, con l'opzione -j, si può specificare quali pacchetti possono passare (ACCEPT, DENY...).

Regole formulate con ipchains

Con ipchains viene innanzitutto specificato quale debba essere il funzionamento di base di ciascuna catena di regole. Inoltre per prima cosa tutte le regole di una catena vengono cancellate:

ipchains -F

A questo punto i permessi delle regole sono impostati nel modo seguente:

ipchains -P input DENY

ipchains -P output DENY

ipchains -P forward DENY

A partire da questo momento, il nostro sistema è assolutamente impermeabile e nessun pacchetto può entrare o uscire. Da qui, si deve impostare il comportamento dei singoli servizi.

La seguente regola permette di mandare dal nostro computer pacchetti verso l'esterno, se sono indirizzati alla porta 80 TCP di una macchina in internet:

ipchains -A output -i eth1 -p tcp -d 0.0.0.0/0 80 -j ACCEPT

Analogamente per ricevere una risposta abbiamo bisogno di una regola per i pacchetti dall'esterno, i quali potranno essere ricevuti se provengono dalla porta 80 di un computer in internet:

ipchains -A input -i eth1 -p tcp -s 0.0.0.0/0 80 -j ACCEPT

In modo analogo devono essere specificate le regole per ogni pacchetto possibile.

Regole formulate con iptables

Le regole con iptables possono essere impostate in modo analogo, anche se con qualche lieve differenza. Innanzitutto le regole vengono scritte con caratteri maiuscoli invece che minuscoli, e inoltre i dati si riferiscono a determinate tabelle che iptables amministra. Queste tabelle possono essere omesse e così iptables funzionerà in modo analogo a ipchains:

iptables -A OUTPUT -p tcp -d 0.0.0.0/0 --dest-port 80 -j ACCEPT

iptables -A INPUT -p tcp -s 0.0.0.0/0 --source-port 80 -j ACCEPT

Gestione delle regole di firewall

Per rendere più sicure le regole del firewall si devono fornire alcuni permessi, nel caso in cui il firewall sia stato configurato con uno script, poiché questo script dovrà cominciare con il cancellare tutte regole per poter poi configurare i permessi e costruire tutte le regole necessarie. Con questa architettura lo script può essere chiamato arbitrariamente una volta dopo l'altra senza creare confusione.

ipchains interviene su un elenco di regole riferite alle funzionalità di firewall del kernel; un po' come avviene con la tabella degli instradamenti di un router. L'ordine in cui sono elencate tali regole è importante, quindi si deve poter distinguere tra l'inserimento di una regola all'inizio, alla fine o in un'altra posizione dell'elenco esistente.

Salvo eccezioni particolari, descritte nel contesto appropriato, la sintassi di massima per l'utilizzo di ipchains è la seguente:

ipchains opzione-punto_di_controllo [regola] [obiettivo]

L'opzione serve a stabilire il tipo di intervento nel sistema di gestione del firewall. L'elenco seguente si riferisce alle opzioni che permettono la cancellazione o l'inserimento delle regole in un punto di controllo:

| --flush

elimina tutte le regole del punto di controllo specificato;

-D | --delete

elimina una o più regole dal punto di controllo specificato;

-A | --append

aggiunge una regola in coda a quelle del punto di controllo selezionato;

-I | --insert

inserisce una regola in una posizione stabilita del punto di controllo selezionato;

-R | --replace

sostituisce una regola del punto di controllo selezionato.

Altre opzioni non modificano le regole; in particolare:

-L | --list

elenca le regole di un uno o di tutti i punti di controllo;

-P | --policy

cambia la politica predefinita per il punto di controllo specificato.

Caratteristiche della directory /proc

Nel file /proc/sys/net/ipv4/ si possono configurare molte caratteristiche del kernel per quanto riguarda la sicurezza nella rete. Le più importanti di queste possibilità sono le seguenti:

ip_forward

Tale file dà la possibilità al kernel di far passare i pacchetti da un'interfaccia di rete all'altra, ovvero in parole povere dà la risposta alla domanda se il nostro computer sia un router oppure no. Se nel file viene messo 0 allora i pacchetti non vengono fatti passare, mentre se viene messo 1 i pacchetti vengono lasciati passare. Tali valori possono anche essere registrati in un file.

echo 1 > /proc/sys/net/ipv4/ip_forward

tcp_syncookies

Regola per l'utilizzazione degli attacchi di synflooding. Un 1 in questo file attiva tale capacità e blocca questo tipo di attacchi.

tcp_syn_retries

Qui viene registrato il numero di pacchetti con il flag syn che vengono accettati uno dopo l'altro, prima che il metodo syncookie entri in funzione. Il numero di default è 5.

icmp_echo_ignore_all

Rende possibile bloccare tutte le richieste di ICMP-echo (ping).

icmp_echo_ignore_broadcasts

Rende possibile bloccare tutte le richieste di ICMP-echo (ping) che erano state mandate a indirizzi di broadcast.

Nella directory /proc/sys/net/ipv4/conf è contenuta una directory per ciascuna interfaccia di rete con i permessi relativi.

Il demone portsentry

Il demone portsentry è un programma che tenta di scoprire eventuali port scan sulle interfacce di rete. Nel caso si scopra un port scan possono essere attivati diversi rimedi, dalla semplice comunicazione al demone syslog fino alla costruzione delle regole del firewall (ipfwadm, ipchains o iptables). Nel file /etc/portsentry/portsentry.conf si possono impostare le caratteristiche appropriate, ad esempio quali porte debbano essere controllate e cosa fare nel caso un attacco venga scoperto.

Il demone di routing routed

Il demone routed viene inizializzato dal sistema con uno script di init. Il suo scopo è di gestire la tabella di routing del kernel adattando dinamicamente le route.

Il demone fa una richiesta di broadcast a tutte le interfacce e aspetta la risposta appropriata. Routed può specificare esattamente a partire da questa informazione quale intinerario esiste. In tal modo si può scrivere una tabella che sia aggiornata sempre sulle condizioni attuali.

2.212.3 Sicurezza dei server ftp

Accesso FTP per gli utenti

Dopo aver installato il server wu.ftpd si aggiunga la linea

ftp stream tcp nowait roots /usr/sbin/tcpd wu.ftpd A

al file /etc/inetd.conf per attivare il server da inetd e si faccia ripartire inetd; il server FTP può essere utilizzato dagli utenti registrati nel sistema, usando la normale autenticazione. Per farlo devono essere soddisfatte le seguenti condizioni:

L'utente deve essere noto al sistema

L'utente deve avere una voce nel file /etc/passwd con una password valida. La password non deve essere vuota.

Il nome dell'utente non deve essere contenuto nel file /etc/ftpusers

Il file /etc/ftpusers serve per escludere determinati utenti dal traffico ftp. Di solito qui sono elencati gli utenti di amministrazione (daemon, mail...).

L'utente deve avere una shell valida

Tale shell può essere anche /bin/false, nel qual caso gli è permesso fare ftp, ma non fare login normalmente.

Altre restrizioni possono essere indicate nel file /etc/ftpaccess.

Agli utenti FTP si applicano le stesse restrizioni sui file e sulle directory dei normali login; seguendo questi ultimi gli utenti FTP possono accedere ai file, spostarli, cancellarli e crearne di nuovi.

Accesso FTP anonimo

Il secondo metodo di accesso FTP è il cosiddetto FTP anonimo; si tratta di un caso leggermente diverso da quello degli utenti normali, perché l'utente anonimo non dovrebbe avere diritti sulle directory.

Al momento del login, viene indicato il nome di utente “anonymous” o “ftp”; il server chiede una password, ma se ne può inserire una qualsiasi. Di solito il server richiede come password l'email, ma ovviamente non se ne può controllare la veridicità. I browser Web come Netscape o MSIE si collegano con i server FTP in modo anonimo, anche se si possono indicare un nome di utente e una password nell'URL

Per permettere il login anonimo viene aggiunto l'utente ftp, che fa login nella propria home directory e non può uscire da essa, grazie a chroot.

In questo modo l'utente ftp vede la propria home directory come radice del filesystem e non può uscirne, né vedere quello che c'e' nelle altre directory.

La voce per l'utente ftp in /etc/passwd è

ftp:x:40:2:ftp account:/usr/local/ftp:/bin/bash

In questo modo l'utente entra con il nome ftp o anonymous nella directory /usr/local/ftp, che diventa la sua root. Perché tutto possa funzionare, si devono inserire alcune sottodirectory che contengano i file necessari.

La directory bin

Deve appartenere a root e non deve essere scrivibile da nessuno. In essa deve essere contenuto almeno il programma ls, in modo che gli utenti possano leggere il contenuto delle directory; tale programma deve avere diritti di accesso 111. Attenzione: il comando deve essere un link statico, altrimenti cerca la libreria standard e non può trovarla. Se non ci devono essere programmi linkati staticamente, si deve inserire anche la directory lib, che contenga le librerie necessarie.

La directory etc

Anche questa directory deve appartenere a root e non essere scrivibile da nessuno. Deve contenere i file passwd e group, ma senza password. I due file servono per poter far leggere i nomi degli utenti e dei gruppi a ls, al posto degli id numerici.

La directory pub

Qui sono contenuti i file che l'utente anonimo può scaricare.

Ci possono essere anche altre directory, ad esempio msgs (messages), che contenga i messaggi da stampare al login, oppure la già indicata directory lib per le librerie. Dato che per impostare l'FTP anonimo è necessario parecchio lavoro ma con poca differenza da un caso all'altro, la maggior parte delle distribuzioni di GNU/Linux rendono disponibile un pacchetto già preconfigurato che fornisce un ambiente ftp anonimo preconfigurato.

In molti casi si imposta una directory pub, in cui contenere i file per l'utente anonimo; allo stesso modo però si deve impostare un ambiente chroot; wu-ftpd permette di risolvere la questione in modo abbastanza semplice.

La voce della home directory per l'utente ftp in /etc/passwd può contenere un'estensione, cioè anche la directory in cui l'utente deve essere portato dopo aver fatto login. Tale estensione è separata dal resto da /./ (barra punto barra) dalla reale home directory. Nel nostro esempio, quindi, avremmo

/usr/local/ftp/./pub

invece di

/usr/local/ftp/

La linea completa, quindi, diventa:

ftp:x:40:2:ftp account:/usr/local/ftp/./pub:/bin/bash

Possibilità di upload per l'utente anonimo

La normale applicazione dell'utente anonimo di solito è limitata ai download; si può però volere che gli utenti anonimi possano anche fare upload in determinate directory, che di solito si chiamano incoming o upload.

Il trucco per farlo è semplicemente far appartenere la directory all'utente ftp e dare ad esso accessi di scrittura; meglio però non dargli accesso di lettura, in modo che non diventi un mezzo di scambio per file illegali.

Controllo e configurazione degli accessi

Wu.ftpd rende possibile una forma complessa di controllo degli accessi ed altre impostazioni nel file /etc/ftpaccess. Per far sì che il server legga questo file, deve essere avviato con l'opzione da linea di comando -A.

A parte i due metodi di accesso personale e anonimo, wu.ftpd permette l'accesso guest; in questa modalità un utente con nome utente e password può collegarsi e viene inviato in una directory sotto chroot, come se fosse l'utente anonimo e, come questo, non si può spostare nel sistema. Ciò in genere viene usato per permettere accesso ftp agli utenti di un server Web. La voce in /etc/passwd è la stessa che con l'utente anonimo (homedir/./directory).

Nel file /etc/ftpchroot può essere indicata un'altra directory per l'utente, che viene trasportato lì prima di avere accesso ai file.

Formazione delle classi

Wu.ftpd permette di associare i client in classi, a seconda del loro indirizzo IP o del dominio DNS. Gli indirizzi possono essere indicati anche tramite metacaratteri di shell (*?[]{}). Le classi vengono create mediante voci nel file /etc/ftpaccess, della forma:

class nomeclasse tipolista indirizzi

Il nome della classe può essere qualsiasi; il tipo della lista può essere material, anonymous e guest o più tra questi valori separati da virgole. Se un host non appartiene a nessuna classe non può avere accesso. Se ad un computer possono essere applicate più classi, viene usata la prima; l'ordine di definizione è quindi importante.

Con istruzioni successive che si riferiscano a queste classi può essere loro permesso o vietato l'accesso. Un semplice esempio potrebbe essere:

class admin real 10.230.1.{100,107,129}

class mio real,anonymous *.miodominio.it

class clienti real,guest *

class tutti anonymous *

Qui vengono definite quattro classi: admin comprende i computer 10.230.1.100, 10.230.1.107 e 10.230.1.129. I membri di questa classe si possono collegare con il proprio nome utente. La classe mio consiste nei computer con dominio miodominio.it, e anche essi possono collegarsi con il proprio nome, ma anche come anonimi. Se un computer è membro sia di admin che di mio, e l'utente vuole autenticarsi con il proprio nome, viene usata la classe admin.Tutti i computer del mondo possono appartenere alla classe real e guest, e quindi avere accesso reale e guest; inoltre, tutti i computer possono collegarsi come anonimo usando la classe tutti.

Caratteristiche delle classi

A ciascuna classe definita possono essere assegnate determinate caratteristiche e restrizioni all'interno del file /etc/ftpaccess. Ecco le più importanti:

autogroup nomegruppo classe [classe...]

Se un utente è membro di una delle classi indicate, automaticamente fa parte del gruppo corrispondente. Il gruppo è un normale gruppo Unix; in questo modo è possibile dare agli utenti del gruppo determinate classi di diritti di accesso ai file, che non hanno gli altri utenti anonimi.

limit classe numero ora file

Limita l'accesso agli utenti della classe indicata alle ore indicate; inoltre non ci possono essere più di numero utenti contemporaneamente. Se durante queste ore ci sono più utenti che cercano di connettersi, quelli a cui viene negato l'accesso vedranno stampato il contenuto di file.

Se viene indicato il numero -1 non vengono poste restrizioni.

L'ora deve essere in formato UUCP, descritto qui sotto in breve:

Le date iniziano con il giorno della settimana (Su, Mo, Tu, We, Th, Fr, Sa a partire dalla domenica), con Wk se si vogliono indicare tutti i giorni lavorativi (dal Lunedì al Venerdì) o Any per qualsiasi giorno della settimana. Segue poi l'indicazione dell'ora, nel formato hhmm-hhmm. Più intervalli di tempo possono essere indicati separati da virgole. Per non permettere mai la connessione, si può usare la parola chiave never.

Se esistono più indicazioni di questo tipo, viene usata la prima corrispondente.

compress yes|no classe [classe...]

Permette (yes) o vieta (no) l'uso di programmi di compressione per determinate classi.

tar yes|no classe [classe...]

Permette (yes) o vieta (no) l'uso di tar per determinate classi.

Possiamo ora impostare le regole per le nostre classi di esempio. Ho commentato le singole regole in modo che dovrebbe essere chiaro l'effetto di ciascuna.

# Per i membri della classe mio si ha accesso come membri del

# gruppo users

autogroup users mio

# Per gli utenti della classe si ha accesso come membri del gruppo

# ftpuser

autogroup ftpuser tutti

# Gli utenti del gruppo admin possono accedere quando vogliono

limit admin -1 Any /usr/local/ftp/msgs/msg.dead

# Ci possono essere massimo 20 utenti della rete local

limit mio 20 Any /usr/local/ftp/msgs/msg.dead

# Massimo 5 utenti della classe clienti e tutti dalle 8 alle 17, e

# solo 20 dalle 17 alle 8 del giorno dopo

limit clienti 5 Any0800-1700 /usr/local/ftp/msgs/msg.dead

limit tutti 5 Any0800-1700 /usr/local/ftp/msgs/msg.dead

limit clienti 20 Any1700-0800 /usr/local/ftp/msgs/msg.dead

limit tutti 20 Any1700-0800 /usr/local/ftp/msgs/msg.dead

# tar e compress per tutti

tar yes admin mio clienti tutti

compress yes admin mio clienti tutti

Con le classi quindi si possono indicare comportamenti diversi che permettono di regolare l'utilizzo del server ftp a determinate ore, o permettere determinate operazioni. In questo modo, molti server permettono ad esempio l'FTP personale per i propri clienti ma non l'accesso anonimo. Usando le classi è possibile fare questo ed altro.

Altre regole di accesso

Oltre alle classi, si possono usare altre regole di accesso per gli indirizzi singoli. Ad esempio:

deny indirizzo nomefile

Ai computer con gli indirizzi indicati nella regola viene negato l'accesso. Il contenuto del file indicato viene stampato quando cercano di fare login. Invece degli indirizzi si possono anche indicare i nomi di dominio (* miodominio.it) o il termine !nameserved (i computer che non hanno un nome registrato nel DNS).

guestgroup nomegruppo [nomegruppo...]

Se un utente fa parte del gruppo indicato, gli si applica la modalità guest.

noretrieve nomefile [nomefile...]

I file indicati non possono essere trasferiti. Se l'indicazione è assoluta (cioè se inizia con una barra) viene vietato di trasferire esattamente il file indicato; se il nome è senza percorso, l'operazione si applica a tutti i file con quel nome.

chmod yes|no tipolista

delete of yes|no tipolista

overwrite yes|no tipolista

rename yes|no tipolista

umask yes|no tipolista

Permette (yes) o vieta (no) l'azione corrispondente (cambio dei permessi, cancellazione, sovrascrittura, modifica del nome, cambiamento di umask) per il tipo di lista indicata. Il tipo di lista è, come sopra, un elenco dei termini material, anonymous e guest separati da virgole.

Configurazioni globali

Oltre alla configurazione dei diritti di accesso, in /etc/ftpaccess possono essere inserite delle configurazioni globali:

email indirizzoemail

L'indirizzo di posta elettronica del gestore del server FTP.

passwd check none|trivially|rfc822 [ enforce|warn ]

Indica che tipo di controllo viene fatto sulle password: none indica che non viene fatto alcun controllo, trivial che le password devono contenere una @, rfc822 che le password devono contenere un indirizzo che soddisfi lo standard RFC822. Inoltre, warn indica che l'utente deve essere avvisato, ma gli si deve permettere l'accesso anche se non ha inserito una password valida, mentre enforce indica che se l'utente non inserisce una password valida non può collegarsi.

Messaggi

Il server FTP restituisce messaggi agli utenti in diverse occasioni; tali messaggi si trovano in file che vengono inviati all'utente. In tali file si possono inserire delle variabili che vengono sostituite prima di inviare il messaggio all'utente. Le variabili valide sono le seguenti:

Variabile	Significato
%T	Ora locale del server nella forma: Thu November 15 17:12:42 1990
%F	Spazio disco libero nella partizione corrente, in kilobyte.
%C	Directrory corrente
%E	L'indirizzo di email dell'amministratore (definito in /etc/ftpaccess)
%R	L'hostname del client
%L	L'hostname del server
%U	Il nome dell'utente, determinato dal login
%M	Il numero massimo di client permessi per questa classe
%N	Il numero corrente di client collegati per questa classe

I messaggi vengono inviati in varie situazioni, ad esempio:

se si raggiunge il limite per una classe

viene negato l'accesso

Inoltre, è possibile far stampare un messaggio se vengono eseguite determinate azioni, usando il comando

message nomefile condizione [classe]

Viene inviato all'utente il file indicato se si avvera la condizione. Le condizioni valide sono:

login
al login

cwd =directory
al momento di entrare nella directory indicata. La directory può essere anche un metacarattere: cwd = * ad esempio sta per tutte le directory. In ogni caso, per ciascuna directory il file viene mostrato solo la prima volta, per non disturbare l'utente con troppi dati. Se il file indicato è un percorso relativo, lo si cerca nella directory in cui si sta passando.

Così è possibile dare diversi messaggi a diverse classi, quando si loggano o quando cambiano directory. Normalmente si usa qualcosa di questo tipo:

message messaggio cwd = *

In queto modo in qualsiasi directory l'utente passa, all'utente viene inviato il file messaggio, se esiste in quella directory. Di solito nel file viene inserita una breve descrizione dei contenuti della directory.

Server FTP virtuali

I server FTP più moderni permettono anche l'uso di server virtuali; su un computer con diversi indirizzo FTP si possono usare diversi server. Le istruzioni per farlo sono:

virtual indirizzoIP root directory

La directory di root del server virtuale per l'indirizzo indicato.

virtual indirizzoIP banner nomefile

Il nome del file da stampare come messaggio di benvenuto

virtual indirizzoIP logfile nomefile

Indica il nome del file di log su cui scrivere i messaggi di log. Se l'indicazione viene omessa viene usato il file di default.

Gruppi con ftpgroups

Nel file /etc/ftpgroups c'è un'altra possibilità di raggruppare gli utenti. Qui si possono inserire regole di questo tipo:

nomegruppo:password_criptata:gruppo_unix

Se un utente dà al server FTP, dopo essersi collegato, i comandi SITE GROUP e SITE GPASS con il gruppo e la password indicate in questa configurazione, coerenti con quelli presenti nel file ftpgroups, diventa membro del gruppo Unix indicato e ottiene i relativi permessi. In questo modo, quindi, si possono ad esempio assegnare permessi di scrittura su determinate directory anche a particolari utenti anonimi.

2.212.4 Secure shell (OpenSSH)

Architettura di SSH

SSH si basa su un'architettura di tipo client/server. Un computer che voglia contattarne un altro tramite SSH fa partire un client ssh. Nel computer che deve essere raggiunto invece deve girare sshd, il server SSH. Di solito il server SSH è un'applicazione stand-alone, quindi non viene inizializzato da inetd ma da uno script di init.

SSH lavora con due differenti versioni del protocollo (1 e 2) per permettere la comunicazione di client (o server) più vecchi con quelli più nuovi. Entrambe le versioni del protocollo funzionano con metodi simili ma naturalmente la seconda (più moderna) è più sicura.

Poiché SSH è stato pensato come sostituto di RSH/RLOGIN, risulta in qualche modo simile, per molti aspetti, al proprio predecessore. Ad esempio se il demone SSH è configurato in modo appropriato supporterà anche i file .rhosts (o .shosts) per rendere possibile il collegamento senza password, come avviene per questo metodo classico.

Tuttavia questo metodo è molto poco sicuro e SSH fornisce metodi molto più sicuri anche senza password.

Autenticazione

Da un punto di vista pratico, SSH trasmette tutti i dati (anche le password) in forma cifrata. Le seguenti tecniche di autenticazione tuttavia non hanno niente a che fare con questa cifratura ma si riferiscono piuttosto alla questione di sapere come un utente possa dimostrare di essere chi dice di essere.

Protocollo ssh versione 1

Il primo metodo che viene tentato, nel momento in cui si stabilisce una connessione tra client (ssh) e server (sshd), è quello contenuto nel file .rhosts. Se sul server (la macchina su cui gira sshd) il nome del computer dal quale arriva la richiesta è registrato nel file /etc/hosts.equiv o /etc/shosts.equiv e il nome dell'utente che effettua la richiesta esiste nel server, allora l'accesso è garantito immediatamente.

Nel caso in cui questo primo metodo fallisca, se .rhosts o .shosts esistono nella home dell'utente sulla macchina remota e contengono una linea con il nome del client e il nome dell'utente su quella macchina, allora all'utente viene permesso di collegarsi. Questa forma di autenticazione di solito non è permessa dal server perché non è sicura.

Il secondo metodo di autenticazione si basa sulla combinazione di .rhosts. o hosts.equiv con il metodo di autenticazione RSA. Ciò vuol dire che se il collegamento fosse permesso da $HOME/.rhosts, $HOME/.shosts, /etc/hosts.equiv o /etc/ssh/shosts.equiv, e se inoltre il server fosse in grado di verificare la chiave host del client (si veda nei file /etc/ssh/ssh_known_hosts e $HOME/.ssh/known_hosts), solo a questo punto il login sarebbe ammesso. Questo metodo di autenticazione chiude i buchi di sicurezza dovuti a IP spoofing, DNS spoofing e routing spoofing.

Nota per l'amministratore di sistema: in generale i metodi /etc/hosts.equiv, $HOME/.rhosts e rlogin/rsh non sono sicuri e dovrebbero essere disabilitati per avere una maggiore sicurezza.

Come terzo metodo di autenticazione, ssh supporta un'autenticazione basata su RSA.

Lo schema si fonda sulla crittografia con chiave pubblica: esistono sistemi di crittografia in cui la crittazione e decrittazione sono effettuate usando due chiavi diverse e non è possibile derivare l'una dall'altra. RSA è uno di tali sistemi. L'idea è che ciascun utente crea una coppia di chiavi, una pubblica e una privata, necessarie per l'autenticazione. Il server conosce la chiave pubblica, mentre soltanto l'utente conosce quella privata. Il file $HOME/.ssh/authorized_keys contiene la lista delle chiavi pubbliche alle quali sia permesso di collegarsi. Quando un utente si connette, il programma ssh comunica al server quale coppia di chiavi vuole usare per l'autenticazione. Il server controlla se questa chiave è permessa e, in caso affermativo, manda all'utente (più precisamente al client ssh che gira sulla macchina dell'utente) un challenge, ovvero un numero random crittato con la chiave pubblica dell'utente.

Il challenge può essere decrittato esclusivamente con la chiave privata appropriata. Il client dell'utente a questo punto decritta il challenge usando la chiave privata, dimostrando così di conoscerla senza rivelarla al server.

ssh implementa il protocollo di autenticazione RSA in modo automatico. L'utente crea la sua coppia di chiavi RSA utilizzando ssh-keygen (si veda la pagina di manuale relativa). In seguito la chiave privata viene memorizzata nel file $HOME/.ssh/identity e quella pubblica in $HOME/.ssh/identity.pub, nella home dell'utente. Dopodiché l'utente dovrebbe copiare la identity.pub che si trova in $HOME/.ssh/authorized_keys nella sua home della macchina remota (il file authorized_keys corrisponde al file convenzionale $HOME/.rhosts e possiede una chiave per ciascuna riga, anche se le righe possono essere molto lunghe). Dopo questa procedura l'utente si può collegare anche senza fornire la password. L'autenticazione RSA è molto più sicura che quella con rhosts.

Il modo più conveniente di usare l'autenticazione RSA può essere senza utilizzare un agente di autenticazione (si veda la sezione su ssh-agent per ulteriori informazioni).

Se tali metodi di autenticazione dovessero fallire, ssh chiede all'utente una password. La password viene mandata all'host remoto per il controllo. Tuttavia, poiché tutte le comunicazioni sono crittate, la password non può essere vista da chi stia in ascolto sulla rete.

Protocollo SSH versione 2

Quando un utente si connette con il protocollo 2, si usano metodi di autenticazione simili.

Usando i valori di default per PreferredAuthentications, il client proverà ad autenticarsi usando come prima cosa il metodo basato sull'host. Se tale metodo fallisce, si tenta l'autenticazione con il metodo della chiave pubblica e infine, nel caso in cui anche questa fallisca, si tenta l'autenticazione tramite password.

Il metodo della chiave pubblica è simile all'autenticazione RSA descritta in precedenza e permette l'utilizzo dell'algoritmo RSA o DSA. Il client usa la sua chiave privata, $HOME/.ssh/id_dsa o $HOME/.ssh/id_rsa, per firmare l'identificatore della sessione e manda il risultato al server. Il server controlla la corrispondenza con la chiave pubblica memorizzata in $HOME/.ssh/authorized_keys e garantisce l'accesso nel caso in cui entrambe le chiavi corrispondano e la firma sia corretta. L'identificatore della sessione viene derivato da un valore Diffie-Hellman condiviso e solo il client e il server ne sono a conoscenza. Se l'autenticazione con la chiave pubblica fallisce o non è disponibile, allora si può mandare una password crittata all'host remoto per provare l'identità dell'utente. Inoltre ssh supporta l'autenticazione con un responso challenge o basato su host.

Il protocollo versione 2 fornisce un meccanismo in più per la riservatezza (il traffico è crittato usando 3DES, Blowfish, CAST128 o Arcfour) e l'integrità (hmac-md5, hmac-sha1). Si noti che invece il protocollo versione 1 manca di un meccanismo efficace per assicurare l'integrità della connessione.

L'agente di autenticazione ssh-agent

ssh-agent è un programma che serve a mantenere le chiavi private utilizzate per l'autenticazione con chiave pubblica (RSA, DSA). L'idea è che ssh-agent venga fatto partire all'inizio di una sessione X o di una sessione di login e tutti gli altri programmi siano fatti partire come client del programma ssh-agent. Attraverso l'uso delle variabili di ambiente, l'agente può essere individuato e automaticamente usato per l'autenticazione durante il collegamento ad altre macchine utilizzando ssh.

Generazione delle chiavi

ssh-keygen è un programma che genera, gestisce e comunica tutte le chiavi necessarie per ssh. Può creare le chiavi RSA per la versione 1 del protocollo e le chiavi RSA e DSA per la versione 2. Il tipo di chiave da generare viene specificato con l'opzione -t. Di solito ciascun utente che voglia utilizzare ssh con l'autenticazione RSA o DSA fa girare questo programma una volta per creare la chiave di autenticazione in $HOME/.ssh/identity, $HOME/.ssh/id_dsa o $HOME/.ssh/id_rsa.

Inoltre l'amministratore di sistema può usare tale programma per generare le chiavi dell'host.

Generazione della coppia di chiavi di un utente

Ciascun utente può generare le proprie chiavi per ssh. Il programma ssh-keygen si aspetta almeno l'indicazione su quale tipo di chiave si voglia generare. Si possono generare i seguenti tipi:

-t rsa1

Viene generata una coppia di chiavi RSA per l'utilizzo da parte della versione 1 del protocollo ssh. La chiave privata viene scritta nel file $HOME/.ssh/identity, mentre quella pubblica viene memorizzata in $HOME/.ssh/identity.pub

-t rsa

Viene generata una coppia di chiavi per l'utilizzo da parte della versione 2 del protocollo di ssh. La chiave privata viene scritta in $HOME/.ssh/id_rsa, mentre quella pubblica in $HOME/.ssh/id_rsa.pub

t dsa

Viene generata una chiave DSA per l'utlizzo da parte della versione 2 del protocollo ssh. La chiave privata viene scritta in $HOME/.ssh/id_dsa, mentre quella pubblica in $HOME/.ssh/id_dsa.pub

L'istruzione:

ssh-keygen -t rsa

produce quindi la coppia di chiavi per l'utilizzo da parte della versione 2 del protocollo.

Il contenuto del file che contiene la chiave pubblica può adesso essere semplicemente aggiunto al file $HOME/.ssh/authorized_keys nel server. Si può fare ciò semplicemente con l'istruzione cat:

cat Datichiavepubblica | ssh nomeserver "cat >> .ssh/authorized_keys"

Le virgolette servono a fare sì che la shell locale non interpreti i simboli come comandi.

La prima volta che si utilizza questa istruzione deve essere fornita una password perché ancora l'autenticazione con le chiavi non è funzionante; successivamente non verrà richiesta più alcuna password.

Generazione di una coppia di chiavi host

La generazione di una coppia di chiavi viene effettuata con ssh-keygen esattamente nello stesso modo visto per quelle dell'utente. Tuttavia vanno distinte alcune caratteristiche:

Non si può utilizzare una password, perciò la domanda riguardo la password va lasciata vuota.

La chiave host viene memorizzata nella directory /etc/ssh, o, per versioni più vecchie, in /etc.

I nomi dei file per le chiavi host di solito sono:

ssh_host_key e ssh_host_key.pub

La chiave RSA1 per la versione 1

ssh_host_rsa_key e ssh_host_rsa_key.pub

La chiave RSA per la versione 2

ssh_host_dsa_key e ssh_host_dsa_key.pub

La chiave DSA per la versione 2

Quali nomi vengano poi usati in realtà viene scritto nel file sshd_config.

In condizioni normali, la coppia di chiavi host viene generata automaticamente con l'installazione da parte di ssh di uno script che implementi le istruzioni appropriate:

ssh-keygen -f /etc/ssh/ssh_host_key -N "" -t rsa1

ssh-keygen -f /etc/ssh/ssh_host_rsa_key -N "" -t rsa

ssh-keygen -f /etc/ssh/ssh_host_dsa_key -N "" -t dsa

La dicitura -N “ “ corrisponde al fatto che la nuova password è vuota, mentre con -f nomefile si indica il nome del file in cui la chiave è stata memorizzata.

Se fosse necessario produrre una nuova coppia di chiavi a mano, queste istruzioni possono essere fornite dall'amministratore anche manualmente.

Configurazione del server in sshd_config

sshd legge i dati di configurazione da /etc/ssh/sshd_config o dal file specificato con -f dalla linea di comando. Il file contiene coppie chiave-valore, una per ciascuna riga. Le righe che cominciano con '#' e quelle vuote sono interpretate come commenti

Le chiavi possibili e i loro significati sono i seguenti (si noti che le chiavi sono case-insensitive, mentre i valori sono case-sensitive):

Port

Specifica su quale porta sshd deve restare in ascolto. Il default è 22. Sono possibili più opzioni di questo tipo.

Protocol

Specifica la versione del protocollo che sshd supporta. I possibili valori sono 1 e 2. Versioni multiple devono essere separate da virgole. Il default è ``2,1''. Si noti che l'ordine dei protocolli non indica una preferenza perché il client sceglie tra le diverse versioni del protocollo offerte dal server.

HostKey

Specifica un file contenente una chiave privata utilizzata da ssh. Il default è /etc/ssh/ssh_host_key per la versione 1 del protocollo e /etc/ssh/ssh_host_rsa_key e /etc/ssh/ssh_host_dsa_key per la versione 2 del protocollo. Si noti che sshd rifiuterà di utilizzare un file se è accessibile dal gruppo o da tutti; è possibile avere file multipli per le chiavi di host. Le chiavi ``rsa1'' sono usate per la versione 1 mentre ``dsa'' o ``rsa'' sono usate per la versione 2 del protocollo ssh.

KeepAlive

Specifica se il sistema deve mandare messaggi del tipo TCP-keepalive all'altra macchina impegnata nella conversazione. Se vengono mandati, l'interruzione della connessione o il crash di una delle macchine verranno prontamente notati. Tuttavia ciò vuol dire che le connessioni verranno interrotte nel caso in cui il routing sia temporaneamente non disponibile, e qualcuno può trovare questa cosa fastidiosa. D'altra parte, se i messaggi di keepalive non vengono mandati, le sessioni possono rimanere appese indefinitamente sul server, lasciandosi dietro utenti fantasma e consumando risorse. Per disabilitare i keepalive questo valore deve essere messo uguale a ``no''.

Opzioni per l'autenticazione

LoginGraceTime

Il server si disconnette dopo il periodo di tempo indicato da questo valore nel caso in cui l'utente non sia riuscito a collegarsi. Se il valore è 0, allora non ci sono limiti di tempo. Il default è di 120 secondi.

PermitRootLogin

Specifica se al superutente sia permesso collegarsi utilizzando ssh. Tale argomento deve essere posto uguale a ``yes'', ``without-password'', ``forced-commands-only'' oppure``no''. Il default è ``yes''. Nel caso l'opzione sia stata posta uguale a ``without-password'', l'autenticazione con password per l'utente root viene disabilitata. Se l'opzione è posta uguale a ``forced-commands-only'', root si può collegare solo con autenticazione tramite chiave pubblica, ma solo nel caso in cui sia stato pasato anche come argomento un comando (il che può risultare utile per effettuare backup remoti anche nel caso in cui a root non sia permesso il collegamento). Tutti gli altri metodi di autenticazione sono disabilitati per root. Se questa opzione è posta pari a ``no'' a root non è permesso il collegamento.

RhostsAuthentication

Specifica se l'autenticazione tramite i file di rhosts o /etc/hosts.equiv è sufficiente. Di solito tale metodo non dovrebbe essere permesso in quanto piuttosto insicuro. Si dovrebbe utilizzare invece l'autenticazione RSA poiché effettua un'autenticazione dell'host tramite RSA, oltre a quella normale con rhosts or/etc/hosts.equiv. Il default è ``no''. Tale opzione si applica soltanto alla versione 1 del protocollo ssh.

RhostsRSAAuthentication

Specifica se è permessa l'autenticazione con rhosts o /etc/hosts.equiv insieme all'autenticazione RSA. Il default è ``no''. Tale opzione si applica solo alla versione 1 del protocollo.

RSAAuthentication

Specifica se l'autenticazione esclusivamente RSA sia permessa. Il default è ``yes''. Tale opzione si applica solo alla versione 1 del protocollo.

HostbasedAuthentication

Specifica se sia permessa l'autenticazione con rhosts o /etc/hosts.equiv insieme a quella con chiave pubblica dell'host client (basata su host). Tale opzione è simile alla RhostsRSAAuthentication e si applica solo alla versione 2 del protocollo. Il default è ``no''.

PubkeyAuthentication

Specifica se l'autenticazione con chiave pubblica è permessa. Il default è ``yes''. Si noti che questa opzione si applica solo alla versione 2 del protocollo.

IgnoreRhosts

Specifica se i file .rhosts e .shosts non verranno usati nelle autenticazioni di tipo rhosts, rhosts RSA e basata su host.

/etc/hosts.equiv e /etc/ssh/shosts.equiv sono comunque usati. Il default è ``yes''.

PasswordAuthentication

Specifica se viene permessa l'autenticazione tramite password. Il default è ``yes''.

PermitEmptyPasswords

Quando l'autenticazione con password è permessa, questo parametro specifica se il server permette il collegamento ad account con stringhe di password vuote. Il default è ``no''.

AllowUsers

Questa opzione può essere seguita da una serie di pattern di nomi di utenti separati da spazi. Se specificati, il collegamento è permesso soltanto ai nomi degli utenti che corrispondono a uno dei pattern. '*' e '?' possono essere usati come metacaratteri nei pattern. Sono validi i nomi degli utenti, non lo sono gli ID numerici. Per default, il collegamento è permesso a tutti gli utenti. Se il pattern assume la forma UTENTE@HOST allora UTENTE e HOST vengono controllati separatamente, restringendo il collegamento a determinati utenti da determinati computer.

AllowGroups

Questa opzione può essere seguita da una lista di pattern di nomi di gruppi separati da spazi. Se specificata, permette il collegamento solo agli utenti che appartengano a un gruppo che corrisponde a uno dei pattern.. '*' e '?' possono essere usati come metacaratteri nei pattern. Sono validi soltanto nomi di gruppi, non lo sono gli ID numerici. Per default il collegamento è permesso a tutti i gruppi.

Opzioni per la costruzione di tunnel

AllowTcpForwarding

Specifica che il TCP-forwarding è permesso. Il default è ``yes''. Si noti che disabilitarlo non aumenta la sicurezza, a meno che agli utenti non venga negato anche l'accesso alla shell, poiché si possono sempre installare il proprio forwarder.

X11Forwarding

Specifica se sia permesso l'X11-forwarding. L'argomento deve essere ``yes'' o ``no''. Il default è ``no''. Quando è abilitato, si possono verificare attacchi ai display del server e del client se il display proxy di sshd è configurato per ascoltare su tutti gli indirizzi (si veda sotto X11UseLocalhost). Tuttavia questo non è il default. Inoltre, lo spoofing di autenticazione e la verifica e sostituzione dei dati di autenticazione avvengono sul lato client. Il rischio per la sicurezza nell'uso del forwarding X11 è che il server del display di X11 possa essere esposto ad attacchi quando il client ssh richiede il forwarding (si vedano le avvertenze per ForwardX11 nelle pagine del manuale). Un amministratore di sistema può voler proteggere i client che espongano se stessi ad attacchi incautamente richiedendo l'X11-forwarding, mettendo un ``no'' in questa opzione. Si noti che disabilitare l'X11-forwarding non impedisce agli utenti di forwardare il traffico di X11, poiché gli utenti possono sempre installare il proprio forwarder. L'X11-forwarding è automaticamente disabilitato se UseLogin è abilitato.

X11UseLocalhost

Specifica se ssh debba connettere il server per l' X11 forwarding all'indirizzo di loopback o a qualsiasi indirizzo. Per default, sshd lega il server di forward all'indirizzo di loopback e imposta la parte di hostname della variabile d'ambiente DISPLAY a ``localhost''. Questo impedisce ad utenti remoti di connettersi da un display proxy. Tuttavia alcuni client X11 più vecchi possono non funzionare con questa configurazione. X11UseLocalhost può essere posto pari a ``no'' per specificare che il server di forward sia connesso a qualsiasi indirizzo. L'argomento deve essere ``yes'' or ``no''. Il default è ``yes''.

X11DisplayOffset

Specifica il primo numero di display disponibile per l'X11-forwarding di sshd. Questo impedisce a sshd di interferire con i veri server di X11. Il default è 10.

XauthLocation

Specifica il percorso completo del programma xauth. Il default è /usr/bin/X11/xauth.

Forwarding X11

Nel caso in cui un utente stia utilizzando il programma X11, in cui i vari programmi sono chiamati su un server ma devono essere visualizzati sullo schermo (o più esattamente sul server X) di una workstation remota, ssh possiede un meccanismo per cui si può effettuare una trasmissione sicura dei dati di queste applicazioni.

Di solito dovremmo digitare la seguente istruzione per vedere il programma xclock sul server del nostro schermo:

ssh SERVER /usr/X11R6/bin/xclock

export display=CLIENT:0.0

Questa trasmissione non è assolutamente cifrata perché la cifratura viene utilizzata solo per trasferire le istruzioni. Al ritorno, dal server al nostro computer, i dati sono trasferiti con il protocollo di X11 e quindi non sono cifrati (anche se la trasmissione di un clock non è di solito così segreta).

Se configuriamo le cose in modo tale che nel file di configurazione /etc/ssh/sshd_config ci sia la voce:

X11Forwarding yes

e allo stesso tempo nel file di configurazione del client ssh /etc/ssh/ssh_config

non compaia la voce:

ForwardX11 yes

allora l'istruzione precedente funziona molto più semplicemente:

ssh server /usr/X11R6/bin/xclock

e il clock è già sul nostro schermo. I vantaggi ora sono i seguenti:

Trasmissione in codice dei dati (ssh tunnel, che trasporta il protocollo X11)

Non serve indicare il DISPLAY, perché il server ssh automaticamente fa partire un server X virtuale che rappresenta la fine del tunnel. La variabile d'ambiente DISPLAY sul server è ora impostata secondo lo standard localhost:10

Non servono cookie; ssh realizza automaticamente cookie falsi necessari alle richieste di autenticazione.

E' importante non dimenticare che anche sul lato client si deve impostare l'opzione ForwardX11 yes in /etc/ssh/ssh_config.

Tunneling di applicazioni non sicure

Per creare un tunnel tra due computer, si usa un client ssh. Si tratta di un tipo di forwarding delle porte, poiché una porta locale (o remota) viene mappata su una porta remota (o locale) e si instaura tra queste una connessione ssh.

ssh -l portalocale:computerremoto:portaremota utente@dominio

Tale istruzione ci dice che la porta indicata del computer locale (portalocale) viene connessa alla porta remota del computer remoto e questa connessione avviene cifrata tramite ssh. L'istruzione utente@dominio si riferisce al proprietario della connessione e del computer locale. Quindi per avere la connessione tra la porta 12345 del computer einstein con la porta 80 del computer bohr, l'utente root di einstein scrive l'istruzione:

ssh -l 12345:bohr:80 root@einstein

ssh -r portaremota:computerremoto:portalocale utente@dominio

Il contrario del principio appena visto.

2.212.5 TCP_wrappers

Anche se originariamente erano stati sviluppati per poter essere usati con inetd, il principio di funzionamento dei wrapper TCP è stato accettato anche per servizi standalone come ssh. Di cosa si tratta?

Invece di chiamare direttamente i servizi, si chiama il programma tcpd, che a sua volta si occupa di richiamare il servizio desiderato, il quale viene poi passato come parametro. tcpd esamina le voci presenti nei file

/etc/hosts.allow

/etc/hosts.deny

e decide se il servizio può essere attivato per l'host indicato.

In maniera simile, anche i servizi standalone esaminano tali file, i quali vengono ugualmente chiamati wrapper TCP.

Quindi anche questa situazione se nel file /etc/hosts.allow, c'e' una voce corrispondente all'host viene dato accesso al servizio, altrimenti se la voce corrispondente all'host si trova nel file

/etc/hosts.deny l'accesso viene negato.

La forma classica dei wrapper TCP

Il formato di entrambi i file viene rappresentato nella pagina man di hosts_access e corrisponde a righe di questo tipo:

lista_server: lista_client [ : comando_shell ]

lista_server è una lista di server (nomi di programmi) o metacaratteri. I server sono indicati con il nome del programma corrispondente; ad esempio, in.telnetd

lista_client è un elenco di uno o più nomi di host, indirizzi IP, pattern o metacaratteri

comando_shell è un comando di shell che viene eseguito nella shell locale se il servizio viene richiesto e la voce per la sua esecuzione o non esecuzione è decisiva. Ad esempio, quindi, si può far emettere un warning a root se qualcuno prova ad accedere ad un servizio vietato.

Come pattern di ricerca si possono applicare due semplici procedure:

se un pattern inizia con un punto (ad es. .pippo.it), tutti i nomi di dominio devono finire con tale pattern (ad es. www.pippo.it).

se un pattern finisce con un punto (ad es. 192.168.1.) tutti i nomi e gli indirizzi devono iniziare con lo stesso pattern (ad es. 192.168.1.23).

Inoltre, si possono usare anche delle parole chiave, tra cui:

ALL

Si applica a tutto.

LOCAL

Si applica a tutti i nomi di host senza punto (e quindi locali).

UNKNOWN

Corrisponde a tutti gli utenti il cui nome non è noto e a tutti gli host il cui nome o indirizzo non è noto. Deve essere usato con attenzione dato che vengono considerati anche gli host i cui nomi sono temporaneamente non risolvibili per problemi al DNS.

KNOWN

Corrisponde a tutti gli utenti il cui nome è noto e a tutti gli host di cui è noto indirizzo IP e nome. Anche questo può dare risultati inaspettati in caso di problemi al nameserver.

EXEPT

Viene usato per escludere una lista (lista1 EXEPT lista2); ad esempio, ALL EXEPT UNKNOWN

PARANOID

Corrisponde a tutti gli host il cui nome non corrisponde all'indirizzo.

Il comando di shell dovrebbe essere terminato con una &, altrimenti si deve aspettare che termini la sua esecuzione prima di poter avviare il servizio.

Nei comandi di shell si possono inserire i seguenti costrutti:

%a

L'indirizzo IP dell'host che ha fatto la richiesta

%A

L'indirizzo IP del server richiamato

%c

Le informazioni sul client, sotto la forma utente@host, utente@indirizzoIP o indirizzoIP, a seconda delle informazioni disponibili

%d

Il nome del processo demone richiesto

%h

Il nome (o, se questo manca, l'indirizzo IP) del client

%H

Il nome (o, se questo manca, l'indirizzo IP) del server

%p

L'ID del processo demone

%s

Le informazioni sul server, sotto la forma demone@host, demone@indirizzoIP o indirizzoIP, a seconda delle informazioni disponibili

%u

Il nome dell'utente chiamante, o "unknown"

%%

Un carattere di %

La forma più moderna del wrapper

I sistemi moderni funzionano con il principio indicato, ma danno la possibilità di impostare tutte le regole in uno solo dei due file. Invece che nella pagina di manuale di hosts_access questo metodo viene descritto in hosts_options. La struttura dei due file è ora la seguente:

lista_server: lista_client [: opzione ] [: opzione...]

Invece di usare un comando di shell, si usano delle opzioni; le più importanti sono:

ALLOW

Permette il servizio indicato per i client indicati

DENY

Vieta il servizio indicato per i client indicati

spawn comando

Esegue il comando di shell indicato. Come nella forma classica possono essere fatte le sostituzioni indicate sopra.

twist comando

Esegue il comando di shell indicato e ne manda l'output al client, invece di eseguire il servizio indicato. Come nella forma classica possono essere fatte le sostituzioni indicate sopra.

user nomeutente[.gruppo]

Avvia il servizio indicato sotto l'ID dell' utente (e gruppo opzionale) indicato.

Il vantaggio di questo metodo è che tutte le configurazioni possono essere gestite da un solo file; dato che si possono usare le opzioni ALLOW e DENY, in /etc/hosts.allow si possono anche gestire dei divieti.

Da notare però che si applica sempre la sequenza indicata sopra. Non serve a niente permettere qualcosa ad un host senza vietarlo a tutti gli altri. Le voci vengono lette e la prima utile viene utilizzata. Quindi, per permettere solo al computer qui.pippo.xyz di usare il demone FTP, si deve scrivere:

in.ftpd : qui.pippo.xyz : ALLOW

in.ftpd : ALL : DENY

Se il computer qui.pippo.xyz richiede il servizio, l'accesso viene permesso; se dovesse provare a fare la stessa cosa un altro computer, l'accesso viene negato.

2.212.6 - Gestione della sicurezza

Kerberos

Kerberos è un protocollo che gestisce l'autenticazione per l'accesso alle risorse di rete da parte utenti e computer. Il suo scopo principale è prevenire la trasmissione di password di testo sulla rete. Kerberos assume che le reti siano poco sicure per natura e che le comunicazioni possano essere intercettate.

Kerberos viene chiamato "trusted third party service", cioè oltre al computer e all'utente che si vogliono autenticare ed al computer che offre il servizio per cui ci si vuole autenticare, c'è un terzo attore, di cui entrambe le parti si fidano: il server Kerberos.

I servizi e gli utenti sotto Kerberos vengono chiamati principal. Tutti i principal condividono con il server Kerberos una password, o una chiave, che permette di avere una comunicazione sicura con il server Kerberos.

I principal usano i cosiddetti ticket per provare che sono coloro che dicono di essere. Se un utente A vuole annunciarsi ad un servizio B all'incirca succede questo: l'utente A manda una richiesta di ticket al server Kerberos. Questa domanda contiene i nomi di A e B, oltre ad altre informazioni. Il server Kerberos riceve la domanda ed esamina per prima cosa se A e B sono principal validi. In tal caso, il server Kerberos fornisce il ticket richiesto, che contiene le seguenti informazioni:

I nomi di A e B

L'indirizzo di rete di A

L'ora corrente

Il periodo di validità del ticket

Una chiave segreta di sessione, usata solo per questa comunicazione

Questo ticket è codificato con la chiave di B, in modo che solo B possa decodificarlo. Viene inviato ad A, insieme con il nome di B e la chiave segreta di sessione. Prima che A mandi la richiesta a B, manda un pacchetto che contiene:

Il nome di A

L'indirizzo di A

L'ora corrente

Un checksum

A codifica questo pacchetto con la chiave di sessione che ha ricevuto dal server Kerberos, poi invia di nuovo il ticket e la sua busta a B, che può decodificarlo, dato che è stato codificato con la sua chiave. Nel ticket codificato è contenuta la chiave di sessione, con l'assistenza della quale B può decodificare il pacchetto di A e paragonare i dati di A con quelli del ticket. Se i dati corrispondono, A è autenticato.

L'area di responsabilità di un server Kerberos si chiama regno.

Mailing list sulla sicurezza

Per conoscere quali sono i bachi di sicurezza che vengono trovati sui vari programmi è sempre bene iscriversi ad una o più mailing list sulla sicurezza, che diffondono bollettini in tal merito. Le più importanti sono:

Bugtraq

Per iscriversi a bugtraq, si mandi una mail a listserv@netspace.org contenente nel corpo del messaggio subscribe bugtraq. (Si vedano gli archivi sopra).

CIAC

Si mandi una e-mail a majordomo@tholia.llnl.gov. Mettere nel CORPO (non nel subject) del messaggio: subscribe ciac-bulletin

La Red Hat ha una serie di mailing list, la più importante delle quali è la lista redhat-announce. Si potrà leggere di patch di sicurezza (e altro) non appena siano disponibili. Si mandi una e-mail a redhat- announce-list-request@redhat.com con il subject Subscribe. Si veda https://listman.redhat.com/mailman/listinfo/ per altre informazioni e archivi.

Il progetto Debian ha una mailing list di sicurezza che tratta dei loro fix. Si veda http://www.debian.com/security/ per altre informazioni.

Tripwire

Tripwire controlla le modifiche al filesystem. Inizialmente viene creato un database delle informazioni su tutti i file di sistema e periodicamente viene eseguito un processo in cron per controllare se ci sono state modifiche.

Snort

Snort è un sistema di rilevamento delle intrusioni che può operare anche come sniffer e packet logger.

Snort come sniffer

Se si vogliono semplicemente stampare gli header dei pacchetti su schermo:

./snort -v

Se si vogliono vedere i dati delle applicazioni in transito:

./snort -vd

Se si desiderano ancora più informazioni, con le intestazioni dei dati a livello link:

./snort -vde

Snort come packet logger

Se si vogliono memorizzare i pacchetti su disco, si deve indicare una directory:

./snort -dev -l ./log

La directory deve esistere, o il programma ritornerà un errore. Quando Snort viene eseguito in questa modalità, raccoglie tutti i pacchetti e li inserisce in una gerarchia di directory a seconda dell'indirizzo IP di uno degli host nel datagramma.

Se si usa semplicemente l'opzione -l, si può notare che Snort usa a volte l'indirizzo del computer remoto come directory in cui mettere i pacchetti, mentra altre volte usa quello del PC locale. Se volete fare il log di tutto quello che concerne la vostra rete locale, si deve specificare quale sia:

./snort -dev -l ./log -h 192.168.1.0/24

Questa regola dice a Snort che si vogliono stampare gli header di dati a livello link e TCP/IP, oltre che i dati dell'applicazione, nella directory ./log, e che si vogliono memorizzare i pacchetti relativi alla rete di classe C 192.168.1.0.

Se ci si trova su una rete veloce o si vogliono memorizzare i pacchetti in formato più compatto, si può fare il log in modalità binaria, in un singolo file nella directory di log:

./snort -l ./log -b

Una volta loggati i pacchetti nel file binario, li si può leggere usando qualsiasi sniffer che supporti il formato binario, come tcpdump. Si può usare anche lo stesso snort, con l'e opzioni:

./snort -dv -r packet.log

I dati nel file possono essere manipolati in molti modi, usando le funzionalità di packet logging e IDS di Snort, oltre all'interfaccia BPF disponibile da linea di comando. Ad esempio, se si vogliono vedere solo i pacchetti icmp, si indica un filtro BPF:

./snort -dvr packet.log icmp

Snort come IDS

In modalità IDS non tutti i pacchetti vengono loggati:

./snort -dev -l ./log -h 192.168.1.0/24 -c snort.conf

snort.conf è il file che contiene le regole secondo le quali i pacchetti verranno filtrati. Normalmente, tali regole possono essere scaricate dalla rete e ricercano dei pattern che possano identificare dei tentativi di intrusione.

Nmap

Nmap è un programma di scansione delle porte di uno o più nodi di rete, che mette a disposizione tecniche differenti per determinare se ci sono servizi disponibili e se ci sono firewall, o comunque altri sistemi che filtrano il passaggio delle comunicazioni. Per la precisione, Nmap distingue tre situazioni:

porte a cui corrisponde un servizio che accetta la connessione;

porte filtrate da qualcosa, per le quali non si può determinare se esista effettivamente un servizio disponibile;

porte inutilizzate, nel senso che non sono abbinate ad alcun servizio di rete in modo certo.

Nmap ha la seguente sintassi:

nmap [metodo_di_scansione] [opzioni] {nodo|rete}...

In pratica, si possono specificare uno o più metodi di scansione; se non lo si fa, viene usato quello predefinito che comporta la determinazione dei servizi disponibili, in base al fatto che questi accettino la connessione. Dopo altre opzioni particolari si indicano uno o più gruppi di nodi, secondo varie possibilità. Per la precisione, un gruppo di indirizzi può essere specificato attraverso il nome di dominio:

nome_di_dominio[/n]

In questo modo, si fa riferimento al nodo indicato per nome e se appare anche una barra obliqua seguita da un numero intero si intende includere nella scansione tutti i nodi che rientrano in quella maschera di rete. Per esempio, se qui.pippo.xyz corrispondesse all'indirizzo IPv4 1.2.3.4, scrivere qui.pippo.xyz/24 significa fare riferimento a tutti gli indirizzi 1.2.3.*.

Se si utilizzano indirizzi numerici è possibile avvalersi di asterischi per indicarne un gruppo. Gli asterischi possono essere collocati in qualunque posizione e, nel caso di indirizzi IPv4, rappresentano qualunque valore nell'ambito dell'ottetto. Naturalmente, dal momento che l'asterisco è utilizzato normalmente dalla shell per fare riferimento a nomi di file che si trovano nel filesystem, questo va protetto in qualche modo.

Come accennato sono disponibili molti tipi diversi di metodi di scansione, ma per poterli apprezzare occorre conoscere bene le caratteristiche dei protocolli TCP/IP. L'elenco seguente ne riepiloga alcuni; per gli altri si rimanda alla pagina di manuale di nmap(1).

Opzione	Descrizione
-sS	Esegue una scansione di tipo TCP SYN, che è quella predefinita se l'utente è root.
-sT	Esegue una scansione «normale», attraverso la funzione connect() del sistema operativo, che è quella predefinita se richiesta da un utente comune senza privilegi.
-sF	Scansione di tipo TCP FIN.
-sX	Scansione nota come Xmas tree.
-sN	Scansione nota come Null scan.
-sP	Scansione attraverso l'invio di richieste di eco ICMP (ping); serve soltanto per determinare la presenza dei nodi ipotizzati.
-sU	Scansione alla ricerca di servizi UDP.
-sO	Scansione IP, per determinare quali protocolli IP sono disponibili.
-sA	Scansione TCP ACK, per determinare la presenza di un firewall e delle sue caratteristiche generali.
-sW	Scansione Window, intesa come una variante del metodo ottenuto con l'opzione -sA.
-sR	Scansione RPC, da abbinare a un altro metodo di scansione, per determinare se le porte di servizi disponibili corrispondono a servizi RPC.

Tra le opzioni che non servono a specificare dei metodi di scansione ce ne sono tre molto utili:

Opzione	Descrizione
-O	Cerca di determinare il sistema operativo utilizzato nei nodi oggetto di indagine.
-p gruppo_porte	Limita il gruppo di porte che si vogliono scandire. Il gruppo di porte può essere indicato come un elenco separato da virgole o attraverso degli intervalli separati da un trattino medio.
-v	Dà maggiori dettagli sul lavoro che viene svolto.

Segue la descrizione di alcuni esempi.

nmap vittima.pippo.xyz

Esegue una scansione «normale» sul nodo corrispondente al nome vittima.pippo.xyz.

nmap '192.168.*.*'

Esegue una scansione «normale» su tutti i nodi della rete 192.168.*.*.

nmap -sU vittima.pippo.xyz

Tenta di determinare le porte UDP abbinate a qualche servizio presso il nodo specificato. Si osservi il fatto che si può usare questa opzione solo in qualità di utente root.

nmap -sS -sR vittima.pippo.xyz

Tenta di determinare le porte TCP abbinate a servizi RPC presso il nodo specificato, attraverso una prima scansione di tipo TCP SYN.

nmap -sU -sR vittima.pippo.xyz

Tenta di determinare le porte UDP abbinate a servizi RPC presso il nodo specificato.

2.210.1 Configurazione del DHCP

Le basi

Per quanto riguarda la struttura di una rete TCP/IP, esistono in linea di principio due modi per poter assegnare gli indirizzi IP e le caratteristiche necessarie.

Il primo caso è quello in cui ciascun computer riceva un indirizzo permanente, che deve essere configurato direttamente su tale computer; nel secondo, gli indirizzi vengono assegnati a un server centrale e i computer collegati fanno riferimento a questo per impostare tutte le loro caratteristiche.

Quest'ultimo tipo di procedimento viene chiamato Dynamic Host Configuration Protocol o, in breve, DHCP.

I vantaggi di un'amministrazione centralizzata di tutte le configurazioni sono abbastanza ovvii: a partire da una certa dimensione della rete, se la configurazione di ciascun computer deve essere compiuta individualmente, allora il lavoro di amministrazione può tranquillamente ignorare i cambiamenti della struttura della rete, soprattutto se non riguardano altre caratteristiche tranne l'indirizzo IP. DHCP può amministrare i seguenti parametri per la configurazione della rete:

Indirizzi IP

Nomi dei computer

Netmask

Indirizzi di broadcast

Gateway

Nome del server DNS

Nome del server NetBIOS

Immagine di boot per le workstation senza disco

Inoltre, con l'impiego di DHCP in una rete di grandi dimensioni l'installazione di nuovi computer diventa semplicissima anche per persone non esperte e non si hanno problemi di conflitto con altri computer.

La comunicazione in una rete locale (di solito ethernet) è effettuata dall'indirizzo permanente di hardware (MAC address) nelle mappe di rete. Dal punto di vista del modello OSI le mappe di rete nel layer link comunicano esclusivamente con questo MAC address. Un computer che non conosca il proprio indirizzo IP può immediatamente effettuare una richiesta in broadcast all'indirizzo 255.255.255.255 per sapere quale computer contenga le informazioni appropriate per se stesso. Di solito questa richiesta viene effettuata sul protocollo UDP, sulle porte 67 e 68.

Il server responsabile del DHCP riceve questa richiesta, così come ogni altro computer presente nella rete. Tale richiesta conterrà anche il MAC address del richiedente. Il server determina le istruzioni appropriate (indirizzi IP, netmask etc...) e le spedisce al client. Quest'ultimo può così completare la propria configurazione e utilizzare tutti i servizi ulteriori presenti nella rete.

Configurazione statica e dinamica

Il server DHCP può assegnare un indirizzo IP dinamico (solo momentaneo) a ciascun computer, o impostare un indirizzo statico sulla base del MAC address del client.

A seconda delle esigenze di quest'ultimo, si sceglie una delle due forme.

Indirizzi dinamici

Di solito vengono utilizzati non per computer che fanno da server, ma esclusivamente per workstation che non offrono servizi ad altri computer in rete. Questo perché non è necessario che gli altri computer presenti nella rete conoscano l'indirizzo IP di una workstation.

Inoltre, gli indirizzi dinamici hanno il vantaggio che in una rete con molti computer che non siano attivi contemporaneamente si può distribuire un numero di indirizzi IP limitato ai computer che siano attivi insieme.

Indirizzi statici

Sono utilizzati per i computer che offrono servizi ad altri computer della stessa rete. Se il loro indirizzo IP cambiasse in continuazione (per assegnazione dinamica) allora il nameserver dovrebbe essere riconfigurato ogni volta che i server cambiano indirizzo.

L'assegnazione degli indirizzi statici richiede che il server DHCP conosca il MAC address del computer che deve ricevere l'indirizzo IP statico. Questo perché se l'assegnazione degli indirizzi IP avviene tramite DHCP, i MAC address sono la sola caratteristica che distingue i computer l'uno dall'altro.

Periodo di validità degli indirizzi assegnati dinamicamente

Se un server DHCP assegna un indirizzo dinamico ad una workstation, naturalmente non può dare lo stesso indirizzo ad un altro computer, ovvero il server DHCP deve conservare due importanti informazioni a proposito delle condizioni momentanee:

Quali indirizzi siano stati assegnati tra quelli disponibili

Quale computer ha avuto ciascun indirizzo

L'assegnazione di un indirizzo dinamico ad una workstation da parte di un server DHCP viene chiamata “affitto”, dall'inglese “lease”, e corrisponde al fatto che il client “affitta” la sua posizione nella rete. Inizialmente può sembrare necessario solo che un server assegni un indirizzo in modo univoco, invece i server devono anche sapere per quanto tempo la workstation utilizzerà quell'indirizzo, altrimenti esaurirebbero subito tutti gli indirizzi disponibili. Per questa ragione è necessario che una workstation che abbia avuto il proprio indirizzo IP dal DHCP annunci se stessa al server per far vedere che risulta ancora attiva e che ha ancora bisogno dell'indirizzo. Il server può specificare con quali intervalli di tempo questi feedback debbano avvenire.

La risposta alla domanda su quanto debbano essere lunghi tali intervalli dipende da diversi fattori. Ad esempio:

Se in una rete fanno riferimento al server DHCP più computer degli indirizzi disponibili, questo tempo deve essere relativamente breve, in modo che il server di una workstation appena tolta dalla rete possa assegnare di nuovo il suo indirizzo.

Se una rete ha fluttuazioni relativamente alte, ad esempio in un laboratorio in cui i computer siano assemblati e disassemblati frequentemente, anche in questo caso tale intervallo di tempo deve essere breve.

In una rete in cui non ci siano cambiamenti frequenti ed esistano sufficienti indirizzi, allora tale intervallo di tempo può essere lungo, in modo da mantenere basso il traffico di rete.

La configurazione in dhcpd.conf

Come nella maggior parte dei servizi Linux, anche i server DHCP possiedono un file di configurazione centralizzato, in questo caso /etc/dhcpd.conf. Nella maggior parte delle distribuzioni si trova un file di esempio con voci molto ben commentate che può risultare molto utile. Un semplice file di configurazione può essere il seguente:

# identificazione dei server DHCP:

server identifier marvin.mydomain.xy;

# caratteristiche globali che si applicano a tutti:

option domain name "mydomain.xy";

option of domain name server 192.168.100.5, 192.168.100.200;

option routers 192.168.100.5;

option subnet MASK 255.255.255.0;

#computer ai quali vengono assegnati IP dinamici :

subnet 192.168.100.0 netmask 255.255.255.0 {

range 192.168.100.100 192.168.100.200;

default-lease-time 3600;

max-lease-time 4000;

get-lease-hostnames on;

}

#computer con indirizzi IP permanenti:

group {

use-host-decl-names on;

host golem {

hardware ethernet 00:A0:24:14:82:4A;

fixed OD ADDRESS 192.168.100.5;

option routers 123.45.67.89;

}

host hal {

hardware ethernet 00:A0:24:14:12:9C;

fixed OD ADDRESS 192.168.100.200;

}

}

La sintassi del file di configurazione è piuttosto chiara. Le istruzioni particolari sono separate da un punto e virgola (;). Tutti i dati che stanno per conto proprio si applicano direttamente a tutte le richieste. Differenti blocchi logici possono essere ottenuti mettendo i dati tra parentesi graffe. In particolare si notino i seguenti blocchi:

subnet indirizzo netmask netmask {...}

Questo blocco individua una sottorete per cui viene effettuata l'assegnazione di indirizzi dinamici.

Ciascun file di configurazione del DHCP deve mostrare almeno una definizione di sottorete.

group {...}

Con questo blocco si possono definire gruppi arbitrari con determinate caratteristiche. Nell'esempio visto sopra i due computer golem e hal hanno in comune la caratteristica di use-host-decl-names impostata ad on.

host hostname {...}

Computer singolo a cui si applicano determinate istruzioni

Come si può capire dall'esempio precedente, i blocchi possono a loro volta essere aggregati.

Se alcune istruzioni ricorrono più volte, si applicano sempre quelle più interne. Così, ad esempio. un'indicazione può specificare quale router deve essere utilizzato. Se un particolare computer ha un'altra indicazione, allora l'istruzione interna (quella del singolo computer) sovrascrive quella esterna (quella globale). Così le diverse indicazioni, secondo la sequenza con cui compaiono, hanno la seguente importanza:

server-identifier nomeDNS;

E' il nome con cui il server DHCP annuncia se stesso alla richiesta del client. Tale indicazione è necessaria soltanto se il server DHCP unisce più indirizzi IP su una mappa di rete. Altrimenti il nome corrispondente viene determinato con una richiesta al nameserver.

option domain-name stringa;

La stringa contiene (tra virgolette) il nome del dominio

option domain-name-servers listaIP;

Lista di indirizzi IP di nameserver DNS (separati da virgole) da usare. Per client Windows devono essere indicati i nameserver NetBIOS, perciò può succedere che ci sia l'opzione option netbios name server.

option routers listaIP;

Lista di gateway, separati da virgole. Di solito qui c'è un solo indirizzo.

option subnet-mask netmask;

La netmask da usare.

range [ dynamic-bootp ] indirizzoiniziale indirizzofinale;

Indica l'intervallo di indirizzi che possono essere usati per l'assegnazione dinamica. Per ciascuna sottorete si deve specificare almeno un intervallo. Per fornire anche client BOOTP, si può specificare l'intervallo prima dell'indirizzo inizale con la flag dynamic BOOTP.

default-lease-time secondi;

Si tratta del numero di secondi dopo i quali un client deve annunciare che ha ancora bisogno dell'indirizzo. Valido solo per indirizzi dinamici.

max-lease-time secondi;

Allo scadere dell'intervallo di tempo indicato, se il client non si è di nuovo annunciato, il server DHCP assume che sia stato “spento” e non abbia più bisogno dell'indirizzo. A partire da questo periodo il server può riassegnare l'indirizzo a un altro client dopo richiesta appropriata. Valido solo per indirizzi dinamici.

get-lease-hostname [on|off];

Se questo valore è on, il nome del computer che viene mandato indietro al client è determinato con una chiamata al DNS, altrimenti esiste la possibilità di assegnare un nome permanente indicando l'opzione hostname con una stringa di caratteri (ad esempio se non è disponibile nessun nameserver). Valido solo per indirizzi dinamici.

use-host-decl-names [on|off];

Se questo valore è on allora non viene fatta nessuna richiesta al DNS ma al client viene inviato il nome indicato dall'host tra parentesi graffe.

hardware tipohardware;

Con questo valore si può fare sì che, con un'assegnazione di indirizzo statico, un certo raggruppamento di host venga attribuito solo a computer con i MAC address specificati. Il valore del tipo di hardware può essere sia ethernet che token-ring. Valido solo all'interno di un raggruppamento di host.

fixed-address indirizzoIP;

Indirizzo statico che deve essere assegnato a un certo host. Valido solo all'interno di un raggruppamento di host.

Il demone DHCP possiede ulteriori caratteristiche che risultano particolarmente utili per l'assegnazione di informazioni al boot nel caso di workstation senza disco. Si può arrivare anche a file di configurazione di 2000 righe; i parametri menzionati sono però più che sufficienti per la configurazione di un server stabile.

Il file dhcpd.leases

Il server DHCP amministra i lease (gli indirizzi assegnati dinamicamente) che ha assegnato a partire da un database persistente. Tale database è organizzato in un file ASCII con il nome /var/lib/dhcp/dhcpd.leases. Prima che il server assegni un indirizzo IP ad un host, memorizza il lease in questo file e si assicura che il contenuto del file stesso venga scritto su disco. In questo modo, anche nell'eventualità di un crash di sistema, dhcpd non si dimenticherà degli indirizzi che ha assegnato.

Questo file non esiste, la prima volta che il server DHCP viene usato, ma deve essere creato, anche vuoto, perché tutto funzioni come si deve. Per fare in modo che questo database non cresca all'infinito, ogni tanto il contenuto del file viene spostato in dhcpd.leases~, e viene creato un nuovo dhcpd.leases. Si noti che i dati numerici sono immagazzinati in questo file in UTC (ora di Greenwich), non nel fuso locale.

Ricaricare il server dopo una modifica

Contrariamente a molti altri servizi, dhcpd non riconosce il segnale HUP. Ciò vuol dire che dopo una modifica al file di configurazione dei server il demone deve essere fermato manualmente e poi fatto partire di nuovo. Per far ciò si può mandare un segnale di TERM al PID del processo, che si trova in /var/run/dhcpd.pid, oppure usare lo script di avvio

/etc/init.d/dhcpd stop

Per farlo ripartire si usa il comando:

/etc/init.d/dhcpd start

Relay DHCP

Nello stesso pacchetto del server DHCP si trova normalmente il demone dhcrelay. Questo è in grado di fungere da ripetitore per una richiesta fatta da un client DHCP, in quanto questa, altrimenti, non può attraversare un router. Infatti il DHCP e soprattutto i client DHCP lavorano molto con i pacchetti di broadcast. I pacchetti di broadcast vengono mandati a tutti i dispositivi della rete fisica; in tal modo un client che si trovi sulla rete può sapere chi sia il responsabile del server DHCP. Tale tecnologia presenta però lo svantaggio che i pacchetti di broadcast non vanno oltre i limiti della rete fisica. Se tra il client e il server è presente un router, allora al server non arriveranno mai le richieste del client e quindi non può rispondere. La soluzione a questo problema sta nell'utilizzo di un programma i cui pacchetti possano oltrepassare un router, ovvero il demone dhcrelay. Esso è in grado di ritrasmettere le richieste fatte da un client DHCP a un server che altrimenti non sarebbe raggiungibile. Nello stesso modo le risposte vengono rinviate all'origine. dhcrelay non richiede configurazione, l'unica cosa indispensabile è l'indicazione di almeno un server DHCP alla fine della riga di comando, secondo la sintassi:

dhrelay [opzioni] server-dhcp

Vediamo ora alcune delle opzioni principali:

-p n_porta

permette di specificare un numero di porta differente da quello standard (67).

-i interfaccia

Permette di specificare in modo esplicito un'interfaccia di rete da cui dhcrelay può aspettarsi delle richieste da parte di client DHCP. Per indicare più interfacce, occorre usare più volte questa opzione. Questa opzione è utile in particolare per escludere eventualmente un'interfaccia di una rete fisica su cui potrebbe essere già presente un server DHCP in grado di intervenire da solo.

2.210.2 Configurazione del NIS

Un server NIS ricava le informazioni di cui ha bisogno per il suo funzionamento da dei file chiamati mappe. Tali file contengono sempre coppie chiave/valore, che però non sono memorizzate in formato testo, ma in genere in formato DBM Berkeley.

Un server NIS quindi nel suo filesystem memorizza molte mappe, alle quali i client possono accedere mediante diversi tipi di chiamate RPC. Le mappe normalmente contengono le stesse informazioni che si trovano nei file di testo come /etc/passwd o /etc/hosts. In alcuni casi, da un singolo file di testo vengono create diverse mappe, ciascuna contenente una coppia chiave/valore.

I domini NIS

Un dominio NIS comprende tutti i computer le cui configurazioni vengono condivise attraverso un server NIS. Questo dominio non coincide necessariamente con il dominio DNS, ma si riferisce solo ai computer che possono essere amministrati con informazioni condivise. Si tratta di dominio NIS solo da un punto di vista amministrativo, e un normale utente non si accorge della differenza.

Per l'affiliazione dei domini NIS si decide a quale server collegare ciascun host; una rete fisica può così essere divisa in diversi domini NIS, ciascuno con il proprio server.

Poiche' nel server NIS sono disponibili informazioni vitali per i propri membri, senza cui questi non possono funzionare, per ciascun dominio si possono inserire più server NIS: uno sarà il master, gli altri gli slave. Nel master vengono impostate le mappe, che poi vengono passate agli slave.

Per poter far sì che un client appartenente ad un dominio NIS trovi il server responsabile per i suoi dati, si usa il programma ypbind. Ogni volta che un client fa una richiesta NIS ad un server, ypbind fa una chiamata in broadcast per trovare il server disponibile per il dominio NIS indicato. In una rete in cui ci sia solo un server NIS, però, questo tipo di operazione crea del traffico inutile; per questo, ypbind si può configurare in modo che la richiesta venga fatta direttamente ad un singolo server.

Configurazione di un server NIS

Il primo passo per implementare la nostra configurazione è la definizione del nome del dominio NIS; per farlo si usa l'istruzione domainname. Ad esempio,

domainname prova

indica che il nostro dominio si deve chiamare “prova”. L'istruzione domainname può essere usata anche senza parametri, per richiedere il nome del dominio NIS usato.

Creazione dei file di mappa

Dopo l'installazione del server ci si deve assicurare che esista la directory dei file delle mappe. Di solito questo elenco si trova sotto /var/yp. Per il nostro dominio prova, ci serve una directory /var/yp/prova.

I file delle mappe vengono memorizzati con uno speciale formato di database; per poter trasformare in questo formato i file originali di testo, come /etc/passwd, si usa uno speciale Makefile, che normalmente si trova già installato nella directory /var/yp.

Una semplice chiamata a make nella directory /var/yp, quindi, crea i file delle mappe in maniera automatica. Il Makefile può essere modificato per indicare quali file debbano essere inseriti nelle mappe e a quali server slave debbano essere passati (i server slave sono di solito elencati nel file /var/yp/ypservers.)

Per far sì che il Makefile funzioni, il server NIS deve venire avviato; in genere viene fatto da uno script di init, dato che senza il server, i computer non possono funzionare. Il binario del server si chiama ypserv e viene chiamato senza parametri dallo script di init. A parte questo server, vengono inzializzati altri servizi, di cui parleremo più avanti in maggiore dettaglio.

Sicurezza contro gli accessi esterni

Per evitare che ogni computer su Internet possa accedere al nostro server NIS, ci sono due possibilità. Per prima cosa, possiamo usare i wrapper TCP: per far sì che solo la rete 192.168.1.0 possa accedere al server, inseriamo la seguente voce nel file /etc/hosts.allow:

ypserv: 192.168.1.

e in /etc/hosts.deny:

ypserv: ALL

Ora solo i computer in hosts.allow possono accedere al server.

La seconda possibilità è il file /etc/ypserv.securenets; il quale indica quali computer possono usare il server NIS. Il formato è semplice; ciascuna riga è della forma:

maschera indirizzoIP

Per la configurazione della nostra rete, si potrebbe usare:

# permette la connessione dal localhost – obbligatorio

host 127.0.0.1

# corrisponde a 255.255.255.255 127.0.0.1

#

# tutti i computer da 192.168.1.0 con netmask 255.255.255.0 hanno accesso

192.168.1.0

Il file di configurazione /etc/ypserv.conf

Questo file di configurazione rende possibile indicare a quali mappe del server ciascun host ha accesso.

Configurazione dei client NIS

La prima e più importante condizione, per un client NIS, è sapere chi è il suo server responsabile. A questa domanda normalmente viene data risposta dal programma ypbind, che esamina la rete attraverso un broadcast per ricavare l'IP del server.

In una rete in cui esistano delle piccole fluttuazioni, normalmente non è necessario iniziare una procedura così complicata, se esiste un solo server NIS disponibile. Per questo, è possibile indicare a ypbind già in partenza quali sono i server responsabili.

Tali informazioni possono essere memorizzate nel file /etc/yp.conf, in tre forme diverse:

domain dominionis hostnameserver

L'hostname del server indicato viene usato per il dominio dominionis; è possibile avere più di una voce per un singolo dominio, nel qual caso le voci successive saranno relative ai server slave.

domain dominionis broadcast

In questo caso per il dominio dominionis viene usata la normale tecnica del broadcast.

ypserver hostname

Il server hostname viene usato per il dominio NIS locale.

Il programma ypbind è un demone che viene fatto partire al momento dell'avvio del sistema. Se si effettuano delle modifiche al suo file di configurazione, il demone deve essere riavviato o gli si deve indicare di rileggerlo.

Con un computer che cambia regolarmente dominio NIS, come un portatile, si possono inserire anche altri dati in questo file:

domain casa 192.168.1.1

domain lavoro 172.23.45.67

Invece di usare gli hostname, si usano gli indirizzi IP, dato che, senza un DNS, non sarebbe possibile accedere al server NIS.

Test della configurazione

Se sul computer client le configurazioni sono state fatte correttamente, possiamo controllare se il server è disponibile. Il primo passo è esaminare se sul server è aperta la porta corrispondente; lo possiamo fare con rpcinfo:

rpcinfo -u server ypserv

La risposta dovrebbe essere di questo tipo:

Program 100004 version 1 is ready and waiting

Program 100004 version 2 is ready and waiting

Ora possiamo stampare i valori contenuti nelle mappe del server NIS usando il programma ypcat Come argomento ad ypcat si può passare il nome della mappa o il suo alias (gli alias vengono definiti in /var/yp/nicknames).

Chiamando quindi

ypcat hosts.byname

dovremmo avere una cosa del genere:

192.168.100.123 prova 127.0.0.1

prova localhost

Se fin qui funziona tutto, il server e il client dovrebbero essere pronti ad usare il NIS.

Uso dei file delle mappe invece dei dati locali

Per poter usare veramente le caratteristiche del NIS, si deve comunicare al client che non deve più utilizzare i file locali, ma al loro posto deve usare i dati contenuti nelle mappe del server NIS. Questa operazione sembra facile, ma in realtà non lo è.

Praticamente tutti gli strumenti importanti di Unix si appoggiano ad informazioni contenute in file di configurazione testuali. Anche un semplice comando come ls -l deve poter convertire gli UID e i GID del file in nomi di utente leggibili. L'unico punto in cui si possono fare queste conversioni sono i file /etc/passwd e /etc/group. Il sistema operativo e/o la libreria standard del sistema offrono le cosiddette chiamate di sistema, che centralizzano questo compito. Ad esempio, quindi, esiste la chiamata gethostbyname, che restituisce l'indirizzo IP di un host in base al suo nome. Quello che bisogna fare quindi è dire alle chiamate di sistema che non devono cercare più nel file di testo /etc/hosts, ma sul server NIS nel file della mappa hosts.byname. Come fare è indicato nel file /etc/nsswitch.conf. Questo file viene letto dalla libreria standard, cioè la GNU libc, e contiene dei riferimenti alle fonti di informazione ed alla sequenza di ricerca.

In questo file si possono trovare le seguenti voci:

hosts: nis files dns

services: files nis

networks: nis files

Così indichiamo che gli accessi agli hostname siano fatti prima sul server NIS, poi sul file locale /etc/hosts e infine,solo se entrambi falliscono, sul DNS. L'accesso al file /etc/services viene fatto prima sul file locale, poi su NIS, e quello che normalmente è nel file /etc/networks, viene richiesto prima su NIS e, solo se questo fallisce, sul file locale.

La parola “fallisce” in questo contesto porta a confusione: non si tratta di fallimento del server, che non è accessibile, ma si riferisce al caso in cui il server risponda di non conoscere la risorsa.

Per modificare cosa accade esattamente se il servizio non trova risposta, si può usare la seguente opzione, tra parentesi quadre:

[stato=azione]

o con la negazione logica dello stato:

[!stato=azione]

Lo stato risulta dal valore restituito dalla voce tra parentesi quadre, e l'azione è return (abortisce) o continue (continua con il servizio successivo nella lista). Lo stato può prendere i seguenti valori:

success

Non ci sono stati errori e la voce richiesta è stata trovata. L'azione predefinita per questo stato è return.

notfound

Il server era accessibile, ma non ha trovato il valore cercato. L'azione predefinita in questo caso è continue.

unavail

Il servizio è permanentemente non accessibile. L'azione predefinita in questo caso è continue.

tryagain

Il servizio è temporaneamente non accessibile. L'azione predefinita in questo caso è continue.

Alcuni esempi:

hosts: dns [!UNAVAIL=return] files

Se il DNS non restituisce il record dato, anche se il server esiste, i file non vengono considerati e vengono usati solo se il server DNS ha fallito.

networks: nis [NOTFOUND=return] files

Stessa cosa, ma con formulazione diversa.

Gli accessi più importanti si riferiscono non ai file indicati finora, ma alle informazioni sugli utenti e sui gruppi, presenti in /etc/passwd e /etc/group. Con le distribuzioni Linux moderne, che funzionano con glibc, risulta sufficiente:

passwd: nis files

group: nis files

Se si vuole usare anche il sistema delle shadow password, si deve aggiungere:

shadow: nis files

Il sistema NIS, però, sostituisce il principio delle shadow, poiché ciascun utente può ricavare la password codificata con una chiamata a

ypcat shadow.byname

ed è proprio questo che si vuole evitare con le shadow password.

Ora quindi, se un utente cambia la password, e questa risiede sul file della mappa del server e non sul file locale, il vecchio programma /bin/passwd deve essere sostituito da yppasswd. Il metodo migliore è rinominare il vecchio programma e fare un link, che fa rispondere yppasswd al comando passwd:

cd /bin

mv passwd passwd.org

ln yppasswd passwd

Ora, se un utente modifica la propria password con /bin/passwd , in realtà il programma chiamato è yppasswd. Questo programma trasmette la password modificata al demone yppasswdd in esecuzione sul server, il quale registra la nuova password nel file di mappa appropriato.

Per poter creare infine la possibilità di escludere l'accesso ai vari computer a determinati utenti, i singoli database locali (in questo caso /etc/passwd) possono contenere voci particolari, che iniziano con un segno di più o di meno. Per fare ciò si devono applicare ancora due modifiche:

La voce passwd in /etc/nsswitch.conf deve contenere la modalità di compatibilità per le vecchie versioni di NIS:

passwd: compat

L'ultima linea di /etc/passwd deve essere seguita da un segno + o – seguito da sei caratteri di due punti.

Se la voce inizia con +, le informazioni che sono qui vengono usate al posto di quelle del server NIS; per dare all'utente Otto la shell C invece che la bash su un determinato client, si può usare questa voce in /etc/passwd

+otto::::::/bin/csh

Tutti i campi vuoti vengono presi da NIS. Per vietare completamente l'accesso al nostro computer all'utente Pietro, anche se ad esso corrisponde una voce nel server NIS, si usa la seguente linea:

-pietro::::::

Altri programmi legati a NIS

Oltre ai programmi già nominati, ypbind e ypcat, ne esistono molti altri; eccone una breve descrizione:

ypmatch

Con ypmatch si possono richiedere singoli valori in base al loro campo chiave, prendendoli da specifici file di mappe su un determinato dominio NIS:

ypmatch daniela passwd.byname

Qui si richiede il record memorizzato per l'utente daniela nel file passwd.byname nel server NIS del dominio NIS corrente. Si può anche visualizzare l'intero elenco degli alias, con il comando

ypmatch -x

yppush

Il programma yppush serve a passare dal server master a tutti gli slave i file delle mappe che abbiano subito modifiche. Tale programma viene normalmente richiamato dal Makefile, se si fanno cambiamenti ai file originali e se nel Makefile è commentata la linea NOPUSH=true.

ypwhich

Il programma ypwhich restituisce il server NIS o il gestore delle mappe master. Con l'opzione -D dominio può essere indicato un altro dominio, invece di quello corrente. Se si dà come argomento il nome di un computer, ypwhich restituisce il server NIS del computer indicato.

Implementare un server NIS slave

I server slave hanno più o meno gli stessi compiti dei server master, con la differenza che le modifiche fatte ad esempio al file delle password possono essere effettuate solo sul master. Il server master si assicura che le informazioni aggiornate vengano inviate allo slave, il quale può sostituire il master nel caso in cui iquesto non sia disponibile.

La prima condizione, ovvia, per l'implementazione di un server slave è che esista un master, la seconda è che il computer che deve agire da server slave sia già configurato come client NIS.

Per rendere il computer un server slave basta dare il comando

ypinit -s master

Indicando -s master si fa in modo che il server master trasferisca le proprie mappe. Il nome dello slave deve essere registrato manualmente nel file /var/yp/ypservers.

Sul server master, dovrebbe venire avviato automaticamente dagli script di init il comando rpc.ypxfrd, che si occupa di passare agli slave le mappe modificate.

Gruppi di reti

Anche se i gruppi di reti non hanno a che fare con NIS, almeno da quando glibc e' stato introdotto, li tratteremo brevemente in questo capitolo. Si tratta di gruppi di utenti definiti nel file /etc/netgroup e non hanno niente a che fare con i normali gruppi di utenti di Unix/Linux, ma rendono possibile permettere o vietare a determinati utenti di fare login su specifici computer.

Se si gestisce una rete sopra NIS è possibile amministrare in maniera centralizzata gli utenti, ma si potrebbe voler evitare che tutti loro possano collegarsi a qualsiasi computer della rete.

Prima abbiamo visto come sia possibile escludere determinati utenti tramite l'introduzione nei file locali delle password di voci particolari del tipo:

-username::::::

ed attivando la modalità di compatibilità nel file /etc/nsswitch.conf. Ciò può però essere complesso in una grande rete, dato che si tratterebbe di escludere centinaia di utenti in ogni computer, e questo azzererebbe i vantaggi del NIS.

Il file /etc/netgroup offre la possibilità di definire gruppi di utenti per cui possano essere registrate voci con il + o il – nel file locale /etc/passwd; in tal modo si può permettere (con il +) o negare (con il -) l'accesso gruppo per gruppo, invece che utente per utente. La definizione dei gruppi è la seguente:

nomegruppo (host, utente, dominio) (host, utente, dominio)...

A questo punto ciascun utente viene considerato un membro del gruppo; se host, utente o dominio vengono omessi, si considerano come dei metacaratteri. Ad esempio, mancando l'host ci si riferisce a tutti gli host. Un gruppo di amministratori potrebbe essere così definito:

poweruser (, dani) (, eugy) (, chris)

In questo modo verrebbe creato il gruppo poweruser, che contiene gli utenti dani, eugy, chris. Nel file locale /etc/passwd basterebbe inserire:

more +@poweruser:::::: :*::::::/bin/false

Così solo i membri del gruppo poweruser possono fare login nel computer.

I nomi dei gruppi sono indicati nel file delle password facendoli precedere da una @.

Allo stesso modo è possibile negare l'accesso ad un gruppo, mettendo il segno meno invece del più.

In /etc/netgroup i gruppi possono a loro volta costituiti da altri gruppi annidati:

poweruser (, dani) (, eugy) (, chris)

utenti (, ciro) (,alf) (,andrea)

tutti poweruser utenti (, capo)

Il gruppo tutti sarebbe formato dai membri del gruppo poweruser, da quelli del gruppo utenti e dall'utente capo.

Il trucco sta nell'amministrare /etc/netgroup su NIS. In questo modo, i gruppi sono uguali per tutti i computer, ma per ogni computer ci può essere un gruppo che comprende gli utenti che possono lavorare su quel computer. Nel file centrale /etc/netgroup il server NIS può creare i gruppi per le singole workstation in questo modo:

pc1 (,dani,) (,eugy,) (,chris,)

pc2 (,ciro,) (,alf,) (,andrea,) (,ryo,)

Su PC1 si usa il + per il gruppo pc1, e così via.

Ulteriori informazioni sul NIS

Homepage dei progetti NIS/NIS+ per Linux: http://www.linux-nis.org (in inglese)

2.210.3 Configurazione di LDAP

Cosa è un servizio di directory?

Non c'entrano niente le directory del filesystem: i servizi di directory sono database che vengono scritti raramente e letti spesso. Si possono implementare localmente su una macchina (come finger) oppure globalmente, distribuendoli tra vari computer. I servizi globali devono definire uno spazio dei nomi (namespace) uniforme, in modo che vi si possa accedere allo stesso modo da qualsiasi macchina.

LDAP è un'implementazione di un servizio di directory; il suo modello si basa sulle voci, cioè delle collezioni di attributi di un nome. Il nome è il DN (distinguished name) e viene usato per fare riferimento chiaramente all'entità. Ciascun attributo di una voce ha un tipo e uno o più valori. Il tipo normalmente è costituito da una stringa abbreviata (come “cn” per il nome comune, “mail” per un indirizzo di e-mai). I valori dipendono dagli attributi del tipo: mail ha ad esempio il valore "dani@pippo.xyz", mentre un attributo JPEG photo conterrà una foto in binario, codificata secondo il formato JPG.

Le voci della directory sono organizzati gerarchicamente in una struttura ad albero. Le voci che rappresentano gli stati stanno sopra; sotto di essi ci sono le regioni, poi le città e così via.

Inoltre, LDAP permette di controllare quali attributi di una voce sono necessari e quali permessi, e come speciale attributo viene usata la classe di oggetti (objectclass). Il valore objectclass dell'attributo determina le regole a cui la voce deve soddisfare.

La correlazione delle informazioni (una voce) viene realizzata dal suo distinguished name (DN), che consiste nel nome della voce (relative distinguished name, o RDN) a cui sono collegati i nomi dei predecessori nell'albero. Ad esempio, l'RDN della voce di Hans Peter Huber dell'esempio nell'immagine è "cn=Hans Peter Huber", e il suo DN "cn=Hans Peter Huber, o=firma1, c=DE"

Configurazione di LDAP

La configurazione del server LDAP si trova nel file slapd.conf, che consiste in tre tipi di informazioni di configurazione: globali, specifiche del backend e specifiche del database. Le informazioni globali vengono indicate per prime, seguite da informazioni associate con un particolare tipo di backend, che poi viene seguito dalle informazioni associate con una particolare istanza del database.

Le direttive globali possono essere sovrascritte per un backend e/o per un database, e le direttive dei backend possono essere sovrascritte da quelle dei database.

Le linee vuote e i commenti che iniziano con # vengono ignorati. Se una linea comincia con dello spazio bianco, viene considerata la continuazione della precedente (anche se quest'ultima è un commento). Il formato generale di slapd.conf è il seguente:

# direttive di configurazione generali

<direttive generali>

# definizioni di backend

backend <tipoA>

<direttive di backend>

# prima definizione di database & direttive di configurazione

database <tipoA>

<direttive di database>

# seconda definizione di database & direttive di configurazione

database <tipoB>

<direttive di database>

# seconda definizione di database "typeA" & direttive di configurazione

database <tipoA>

<direttive di database>

# successive definizioni di backend e database & relative configurazioni

...

Ciascuna direttiva di configurazione può avere degli argomenti; se è così questi devono essere separati da spazi o tabulazioni. Se un argomento contiene degli spazi, deve essere racchiuso tra doppie virgolette; se contiene un backslash, lo si deve quotare con un altro backslash.

Direttive generali

Le direttive descritte in questa sezione si applicano a tutti i backend e database a meno che non vengano sovrascritte esplicitamente in una definizione di backend o database. Gli argomenti da sostituire con del testo sono riportati tra parentesi angolate <>.

access to <cosa> [ by <chi> <livelloaccesso> <controlli> ]+

Questa direttiva dà accesso (indicato da <livelloaccesso>) ad un insieme di voci e/o attributi (indicati da <cosa>) da parte di uno o più richiedenti (indicato da <chi>).

Importante: Se non vengono indicate direttive di accesso, la policy di default è permettere l'accesso da chiunque a qualsiasi cosa, con accesso in lettura sia da parte degli utenti autenticati che da quelli anonimi.

attributetype <Descrizione tipo attributo RFC2252>

Definisce un tipo di attributo.

idletimeout <intero>

Indica il numero di secondi da aspettare prima di chiudere forzatamente una connessione client non attiva. Un idletimeout di zero, il default, disabilita questa caratteristica.

include <nomefile>

Questa direttiva indica che slapd dovrebbe leggere altre informazioni sulla configurazione dal file dato, prima di continuare con la seguente linea del file. Il file incluso deve seguire la normale sintassi di slapd.conf.

Nota: si deve fare attenzione ad usare questa direttiva, dato che il limite al numero di direttive di include una dentro l'altra non è basso, e non vengono controllati i loop.

loglevel <intero>

Questa direttiva indica il livello a cui i messaggi di debug e le statistiche sulle operazioni vengano registrate in syslog. I livelli di log sono additivi. Per mostrare queli numeri corrispondono a quale tipo di debug, si può invocare slapd con -? o consultare la tabella riportata qui sotto. I possibili valori per <intero> sono:

Livello	Descrizione
-1	Abilita tutto il debug
0	Nessun debug
1	Traccia le chiamate a funzione
2	Debug della gestione dei pacchetti
4	Gestione delle heavy trace
8	Gestione delle connessioni
16	Stampa i pacchetti inviati e ricevuti
32	Elaborazione dei filtri di ricerca
64	Elaborazione dei file di configurazione
128	Elaborazione delle ACL
256	Connessioni/operazioni/risultati dei log delle statistiche
512	Voci di log delle statistiche inviate
1024	Stampa delle comunicazioni con i backend di shell
2048	Stampa del debugging del parsing delle voci

objectclass <Descrizione delle classi di oggetti RFC2252>

Questa direttiva definisce una classe di oggetti.

referral <URI>

Questa direttiva indica il referral da passare indietro quando slapd non riesce a trovare un database locale per gestire la richiesta.

Esempio:

referral ldap://root.openldap.org

Questo si riferisce alle query non locali verso il server di root globale del progetto OpenLDAP. I client LDAP intelligenti possono chiedere di nuovo a questo server, ma è da notare che la maggior parte di essi sapranno solo come gestire dei semplici URL LDAP che contengono una parte di host e una parte di DN opzionale.

sizelimit <intero>

Indica il numero massimo di voci da restituire con un'operazione di ricerca.

Default:

sizelimit 500

timelimit <intero>

Questa direttiva indica il numero massimo di secondi (di tempo reale) che slapd utilizzerà nella risposta ad una richiesta di ricerca. Se in questo tempo la ricerca non finisce, viene inviato un messaggio di timeout.

Default:

timelimit 3600

Direttive generali per i backend

Le direttive in questa sezione si applicano solo al backend in cui vengono definite; sono supportate da qualsiasi tipo di backend. Le direttive dei backend si applicano a tutte le istanze di database dello stesso tipo e, a seconda della direttiva, possono essere sovrascritte dalle direttive dei database.

backend <tipo>

Segna l'inizio della definizione del backend. <tipo> dovrebbe essere bdb o uno degli altri tipi supportati, elencati in tabella.

Tipo	Descrizione
bdb	Backend transazionale Berkeley DB
dnssrv	Backend DNS SRV
ldbm	Backend Lightweight DBM
ldap	Backend Lightweight Directory Access Protocol (Proxy)
meta	Backend Meta Directory
monitor	Monitor backend
passwd	Accesso in sola lettura a passwd(5)
perl	Backend programmabile in Perl
shell	Backend shell (programma esterno)
sql	Backend programmabile in SQL

Esempio:

backend bdb

Segna l'inizio di una nuova definizione di backend BDB.

Direttive generali sui database

Le direttive in questa sezione sono le principali tra quelle che si applicano solo al database nel quale sono state definite. Sono supportate da ogni tipo di database.

database <tipo>

Questa direttiva segna l'inizio di una nuova definizione di istanza di database. <tipo> deve essere uno dei tipi di backend elencati nella tabella precedente.

Esempio:

database bdb

Segna l'inizio di una nuova definizione di istanza di database BDB.

readonly { on | off }

Questa direttiva mette il database in modalità a sola lettura; qualsiasi tentativo di modifica restituirà un messaggio di errore “unwilling to perform”.

Default:

readonly off

replica uri=ldap[s]://<hostname>[:<port>] | host=<hostname>[:<port>]

[bindmethod={simple|kerberos|sasl}]

["binddn=<DN>"]

[saslmech=<mech>]

[authcid=<identity>]

[authzid=<identity>]

[credentials=<password>]

[srvtab=<filename>]

Questa direttiva indica un sito di replicazione per il database. Il parametro uri= indica uno schema, un host e una porta opzionale su cui trovare l'istanza dello slapd slave.

rootdn <dn>

Questa direttiva indica il DN che non è soggetto al controllo degli accessi o alle restrizioni amministrative per le operazioni sul database. Il DN non si deve riferire ad una voce della directory, ma si può riferire ad un'identità SASL.

rootpw <password>

Questa direttiva può essere usata per indicare una password per il rootdn (quando il rootdn è impostato ad un DN interno al database).

suffix <suffisso dn>

Questa direttiva indica il suffisso DN delle query che saranno passate a questo database di backend. Si possono dare più linee, e ne serve almeno una per definizione di database.

syncrepl

Si usa per mantenere un database replicato sincronizzato come il master.

updatedn <dn>

Questa direttiva si applica solo agli slapd slave; indica il DN a cui è permesso fare cambiamenti a questa replica.

updateref <URL>

Questa direttiva si applica solo agli slapd slave; indica l'URL da restituire ai client che inviano richieste di update alla replica. Se indicato più volte, vengono dati tutti gli URL.

Direttive per i database BDB

Le direttive di questa categoria si applicano solo ai database BDB. Per l'elenco completo, si veda la pagina man di slapd-bdb.

directory <directory>

Indica la directory in cui si trovano i file BDB che contengono il database e gli indici associati.

Default:

directory /usr/local/var/openldap-data

Creazione e manutenzione di un database

Questa sezione spiega come creare un database da zero. Si può fare in due modi; come prima opzione si può creare un database online usando LDAP: si avvia slapd e si aggiungono delle voci usando il client scelto. Questo metodo è utile per database relativamente piccoli (alcune centinaia o migliaia di voci, a seconda delle necessità) e con tipi di database che permettono le modifiche.

Il secondo metodo per creare un database è farlo offline usando delle speciali applicazioni fornite con slapd. Questo metodo è il migliore per diverse migliaia di voci, per cui ci vorrebbe troppo tempo con il metodo LDAP, o se si vuole essere sicuri che nessuno acceda al database mentre lo si sta creando. Da notare che non tutti i tipi di database supportano queste applicazioni.

Creazione di un database online

Il pacchetto software OpenLDAP contiene il programma ldapadd, che serve per aggiungere voci ad un server LDAP in esecuzione. Se si sceglie di creare il database online, si può usare ldapadd per aggiungere le voci (o anche altri client forniti a parte, come il browser LDAP, su http://www.iit.edu/~gawojar/ldap/). Dopo aver aggiunto le prime voci, si può usare ancora ldapadd per aggiungerne altre. Si deve fare attenzione ad impostare le seguenti opzioni di configurazione a sladp.conf file prima di avviare slapd:

suffix <dn>

Questa opzione indica quali voci gestire nel database. Il valore dovrebbe essere il DN della radice del sottoalbero che si vuole creare. Ad esempio:

suffix "o=UniPG, c=NL"

Si dovrebbe essere sicuri di indicare una directory in cui creare gli indici:

directory /usr/local/unipg

La directory deve esistere, e slapd deve avere i permessi appropriati per scriverci.

Si deve configurare slapd in modo che ci si possa connettere ad esso come utente delle directory con i permessi di aggiungere voci. Si può configurare la directory in modo che supporti un utente speciale, o root, solo per questo scopo; lo si fa usando le seguenti due opzioni nella definizione del database:

rootdn <dn>

rootpw <passwd> /* Ricordatevi di usare una password SHA!!! */

Queste opzioni indicano un DN e una password che possano essere usati per aggiungere la voce “superuser” del database (cioè quella a cui è permesso tutto). Il DN e la password indicati qui funzionano sempre, anche se la voce indicata non esiste o ha una password diversa. Questo risolve il problema dell'uovo e della gallina che si presenta quando ci si deve autenticare per aggiungere voci nel database ma ancora non esiste nessuna riferita all'autenticazione.

Slapd capisce autonomamente se inserite una password criptata con SHA1 nella direttiva rootpw. Per generare le password SHA1 si può usare il comando slappasswd:

slappasswd -h {SHA}

rootpw "{SHA}5en6G6MezRroT3XKqkdPOmY/BfQ="

Ad esempio:

rootdn "cn=Manager,dc=example,dc=com"

rootpw "{SHA}5en6G6MezRroT3XKqkdPOmY/BfQ="

L'output di default di slappasswd è generare password Secure Hash; in questo caso non si deve passare il parametro -h, ma basta chiamare slappasswd direttamente.

Se state usando SASL come meccanismo di autenticazione su LDAP, la linea rootpw può essere tralasciata.

Infine, dovreste assicurarvi che la definizione del database contenga le definizioni degli indice volute.

index {<attrlist> | default} [pres,eq,sub,none]

Ad esempio, per indicizzare gli attributi cn, sn, uid e objectclass, si possono usare le seguenti linee di configurazione per l'indice:

index cn,sn,uid pres,eq,sub

index objectClass pres,eq

Nota: Da notare che non tutti i tipi di indice sono disponibili per tutti i tipi di attributo.

Una volta configurate le cose, si avvia slapd, ci si connette con il client LDAP e si inizia ad aggiungere voci. Ad esempio, per inserire la voce di UniPG seguita da una voce Postmaster usando ldapadd, si può creare un file /tmp/nuovavoce che contenga:

o=UniPG, c=NL

objectClass=organization

description=Università degli studi di Perugia

cn=Postmaster, o=UniPG, c=NL

objectClass=organizationalRole

cn=Postmaster

description= Postmaster di UniPG – postmaster@unipg.it

e poi creare la voce con il comando:

ldapadd -f /tmp/nuovavoce -x -D "cn=Manager, o=UniPG, c=NL" -w secret

Il comando qui sopra assume che abbiate impostato rootdn to "cn=Manager, o=UniPG, c=NL" e rootpw a "secret" (forse SHA1, criptata in slapd.conf). Se non volete digitare la password sulla linea di comando, usate l'opzione -W per il comando ldapadd, invece di -w "password"; vi verrà chiesto di inserire la password:

ldapadd -f /tmp/newentry -x -D "cn=Manager, o=UniPG, c=NL" -W

Enter LDAP Password:

Il formato LDIF

Il formato LDAP Data Interchange Format (LDIF) viene usato per rappresentare le voci LDAP in un semplice formato di testo. La forma di base di una voce è:

#commento

dn: <distinguished name>

<descrattr>: <valoreattr>

<descrattr>: <valoreattr>

...

#commento

dn: <distinguished name>

<descrattr>: <valoreattr>

<descrattr>: <valoreattr>

...

Le linee che iniziano con un '#' sono commenti. Le descrizioni degli attributi (descrattr) possono essere semplicemente tipi di attributo come cn o objectClass o 1.2.3 (un'OID associata con un tipo di attributo) o possono includere opzioni come cn;lang_it_IT o userCertificate;binary.

Una linea può venire continuata sulla successiva facendo iniziare quest'ultima con uno spazio o una tabulazione. Ad esempio:

dn: cn=Daniela Paolotti, dc=esempio, dc=

com

cn: Dani

Paolotti

è equivalente a:

dn: cn=Daniela Paolotti, dc=esempio, dc=com

cn: Dani Paolotti

Su linee distinte si possono inserire valori multipli per lo stesso attributo:

cn: Daniela Paolotti

cn: Dani Paolotti

Se un <valoreattr> contiene caratteri non stampabili o comincia con uno spazio, un due punti (':'), o un minore di ('<'), il <valoreattr> è seguito da un doppio due punti e dalla codifica base64 del valore. Ad esempio, il valore " inizia con uno spazio" sarebbe codificato così:

cn:: IGJlZ2lucyB3aXRoIGEgc3BhY2U=

Si può anche specificare un URL che contenga il valore dell'attributo. Ad esempio, questo indica che il valore jpegPhoto dovrebbe essere presto dal file /percorso/per/file.jpeg.

cn:< file://percorso/per/file.jpeg

Voci multiple all'interno dello stesso file LDIF sono separate da linee vuote. Ecco un esempio di un file LDIF che contiene tre voci:

# Voce per Daniela

dn: cn=Daniela Paolotti, dc=esempio, dc=com

cn: Daniela Paolotti

cn: Dani Paolotti

objectClass: persona

sn: Paolotti

# Voce per Eugenia

dn: cn=Eugenia Franzoni, dc=esempio, dc=com

cn: Eugenia Franzoni

cn: Eugy Franzoni

objectClass: persona

sn: Franzoni

# Foto JPEG codificata in Base64

jpegPhoto:: /9j/4AAQSkZJRgABAAAAAQABAAD/2wBDABALD

A4MChAODQ4SERATGCgaGBYWGDEjJR0oOjM9PDkzODdASFxOQ

ERXRTc4UG1RV19iZ2hnPk1xeXBkeFxlZ2P/2wBDARESEhgVG

# Voce di Chris

dn: cn=Christopher R. Gabriel, dc=esempio, dc=com

cn: Christopher R. Gabriel

cn: Christopher Gabriel

objectClass: persona

sn: Gabriel

# Foto JPEG da file

jpegPhoto:< file://percorso/per/file.jpeg

Da notare che la jpegPhoto nella voce di Eugenia è codificata in base64, mentre quella di Christopher è contenuta in un file che si trova al percorso identificato dall'URL.

Gli spazi finali non vengono tolti dai file LDIF, né gli spazi ripetuti vengono sostituiti da uno solo. Se non ce li volete, non ce li mettete.

2.210.4 Autenticazione con PAM

Sintassi dei file PAM

Tipo controllo modulo percorso parametri

I vari campi hanno il seguente significato:

Tipo

Qui viene indicato il tipo di autenticazione, che cambia a seconda dell'uso del modulo. I moduli dello stesso tipo possono venire elaborati uno dopo l'altro, in modo che PAM permetta l'accesso quando siano verificate tutte le condizioni. PAM supporta i seguenti quattro tipi di autenticazione:

account

Decide se l'utente può accedere al servizio, se la sua password è scaduta eccetera.

auth

Decide se l'utente è chi dice di essere; di solito viene usata una password, ma si possono usare altri metodi, come la biometria.

password

Dà la possibilità di aggiornare i meccanismi di autenticazione,

session

Quello che deve essere eseguito prima o dopo l'autenticazione dell'utente: ad esempio, montare le home directory degli utenti.

Nel file di configurazione, pam.conf, ci deve essere almeno una voce per ciascuno di questi tipi.

control

Questa configurazione indica cosa deve fare PAM se uno dei moduli di autenticazione fallisce. Anche qui ci sono quattro possibilità:

requisite

Se l'autenticazione con questo modulo fallisce, qualsiasi altro tentativo viene cancellato, e non si può accedere al servizio.

required

La mancata autenticazione porta anche qui al rifiuto dell'accesso, ma altri eventuali moduli vengono comunque elaborati.

sufficient

Se l'autenticazione ha successo con questo modulo, viene garantito subito l'accesso, se tutti gli altri prima di questo hanno avuto successo. Se uno dei precedenti era required e non è passato, l'effetto di questo non viene considerato. I moduli successivi non vengono letti.

optional

Il successo o meno di questo modulo è rilevante solo se è l'unico del suo tipo per un servizio.

Nel file di configurazione, che gestisce il login, ci sono esempi di quasi tutti questi tipi di controllo. La maggior parte dei moduli di tipo required si riferiscono a pam_unix.so, il modulo di autenticazione principale. L'unico modulo con tipo requisite è pam_securetty.so, che viene eseguito quando si ha un login su un terminale sicuro, e l'unico modulo opzionale è quello che gestisce le informazioni dell'ultimo login, cioè pam_lastlogin.so.

modulo percorso

Il nome e il percorso opzionale del modulo, che deve eseguire il compito indicato. Se il percorso viene omesso, si suppone che i moduli si trovino in /usr/lib/security o /lib/security. Il filesystem standard indicherebbe la seconda posizione, in modo che i moduli esistano anche se è montato il solo filesystem di root.

parametri

I parametri passati al modulo; ogni modulo ha i propri.

Se le istruzioni di PAM sono invece che in /etc/pam.d tutti insieme in /etc/pam.conf, il nome del servizio precede comunque i quattro campi indicati sopra, che si riferiscono ad esso.

La linea è nel file /etc/pam.d/login:

auth required pam_unix.so nullok

o, in /etc/pam.conf:

login auth required pam_unix.so nullok

Il file other

Ciascun file in /etc/pam.d si riferisce ad un determinato servizio. L'unica eccezione è il file /etc/pam.d/other, che contiene la configurazione per tutti i servizi che non hanno un proprio file. Se si deve far partire un servizio, PAM cerca prima un file in /etc/pam.d, che abbia lo stesso nome del servizio. Se non lo trova, legge il file others in /etc/pam.d. Dato che questo file si riferisce a tutti i servizi non indicati altrove, deve essere particolarmente sicuro.

Per vietare tutto quello che non è espressamente permesso nel proprio file, in /etc/pam.d/other si possono inserire le seguenti righe:

auth required pam_deny.so

auth required pam_warn.so

account required pam_deny.so

account required pam_warn.so

password required pam_deny.so

password required pam_warn.so

session required pam_deny.so

session required pam_warn.so

In questo modo le quattro possibilità vengono negate (pam_deny.so) e memorizzate nei log (pam_warn.so).

I principali moduli di PAM

L'intera funzionalità di PAM viene resa disponibile attraverso dei moduli. Per risolvere ciascun compito, PAM ha un modulo; con questo principio si rende più semplice e veloce l'estensione dei programmi che richiedono un'autenticazione. Se non si facesse così, sarebbe necessario modificare direttamente il codice sorgente dei programmi.

I moduli più importanti di PAM sono:

pam_access.so

Rende possibile configurare su quale terminale permettere il login ai vari utenti (locali o in rete). Si può indicare qui, ad esempio, che l'utente chris può fare login sul computer pippo1, ma non su pippo2 o terminale1. Le configurazioni si trovano nel file /etc/security/access.conf, o nel file indicato nel parametro ACCESS file= file.

pam_chroot.so

Rende possibile avere diversi ambienti di chroot per utenti differenti.

pam_cracklib.so

Controlla se vengono usate password sicure. Ha bisogno della libreria libcrack e permette di richiedere, ad esempio, che le password siano almeno di un numero minimo di lettere, con minlen =...

pam_deny.so

Vieta qualsiasi servizio; utile per il file other.

pam_env.so

Rende possibile impostare e rimuovere le impostazioni delle variabili d'ambiente. La sua configurazione risiede in /etc/security/pam_env.conf.

pam_filter.so

Rende possibile l'uso di programmi di filtro, che appunto filtrano l'intput e l'output dei terminali. L'unica variante fornita è quella che trasforma le lettere minuscole in maiuscole.

pam_ftp.so

Rende possibile il login anonimo per l'FTP, indicando l'indirizzo di posta elettronica come password.

pam_group.so

Permette di impostare l'appartenenza degli utenti a dei gruppi; il suo file di configurazione è /etc/security/groups.conf.

pam_issue.so

Sostituisce le funzionalità del programma login/getty in modo da stampare il contenuto del file /etc/issue sul terminale prima di fare login.

pam_krb4.so

Permette l'autenticazione Kerberos4.

pam_lastlog.so

Gestisce il file /var/log/lastlog.

pam_limits.so

Si occupa delle regole sulle restrizioni di sicurezza contenute nel file /etc/security/limits.conf.

pam_listfile.so

Permette o vieta l'accesso agli utenti che siano elencati in determinati file (ad esempio /etc/ftpusers).

pam_mail.so

Controlla se c'è posta per gli utenti che si sono collegati, ed eventualmente glielo indica.

pam_mkhomedir

Crea delle home directory per gli utenti che ancora non ne hanno una.

pam_motd.so

Stampa il file motd dopo il login.

pam_nologin.so

Se esiste il file /etc/nologin, tutti i tentativi di login, tranne quelli di root, vengono negati.

pam_permit.so

L'opposto di pam_deny.so. Permette qualsiasi cosa. Molto pericoloso!

pam_pwdb.so

Gestione e autenticazione delle password di tipo Unix.

pam_rhosts_auth.so

Gestisce l'uso del file rhosts.

pam_rootok.so

Permette l'accesso ai servizi, se viene richiesto da root (con l'ID utente reale, non quello effettivo).

pam_securetty.so

Esamina il file /etc/securetty , per capire se root può collegarsi da un determinato terminale.

pam_tally.so

Considera i tentativi di login falliti; può opzionalmente chiudere gli accessi per un account dopo un certo numero di tentativi falliti.

pam_time.so

Rende possibile permettere o vietare gli accessi ad un determinato servizio nelle ore indicate in /etc/security/time.conf.

pam_unix.so

Gestisce le normali funzionalità dei file di Unix passwd e shadow , anche con NIS.

pam_userdb.so

Rende possibile l'autenticazione sui dati contenuti in un database Berkley (db).

pam_warn.so

Invia i messaggi a syslog.

pam_wheel.so

Assegna i privilegi di root ai membri del gruppo root (GID 0).

Esistono anche altri moduli, ad esempio pam_ldap.so, che rende possibile l'autenticazione sui server LDAP.

2.214.7 Risoluzione dei problemi di rete

Se la rete non funziona, la prima cosa da fare è seguire una semplice procedura:

Riavviare il computer.

Controllare all'avvio (o con il comando dmesg) se le interfacce di rete sono state rilevate correttamente; altrimenti, caricare i relativi moduli o ricompilare il kernel.

Controllare la corretta configurazione delle interfacce con ifconfig; dando il comando senza argomenti, si dovrebbe vedere l'elenco delle interfacce attive con i relativi IP.

Testare il funzionamento del loopback con il comando ping localhost.

Controllare la tabella di routing con il comando route.

Testare il funzionamento della rete raggiungendo l'indirizzo IP del gateway di default con il comando ping.

Controllare la risoluzione dei nomi in /etc/resolv.conf.

Testare il funzionamento della risoluzione dei nomi con il comando dig o cercando di eseguire un ping su un nome di dominio.

Per controllare il funzionamento dei servizi su un computer è utile il comando netstat, che permette di stampare le connessioni di rete, le tabelle di routing, le statistiche sulle interfacce, le connessioni in masquerade e i multicast. Si rimanda per le opzioni al modulo 2.205.2.

<!-- This is just an anchor for the next table.

-->

<!-- This is just an anchor for the next table.

-->

<!-- This is just an anchor for the next table.

-->

<!-- This is just an anchor for the next table.

-->

<!-- This is just an anchor for the next table.

-->

<!-- This is just an anchor for the next table.

-->

<!-- This is just an anchor for the next table.

-->

134

2004-03-11T19:15:16