UNIX: implementazione pratica servizi di base. Unix: servizi di base2 BIND Introduzione a DNS Quando gli host su di una rete, si collegano ad un'altra

UNIX: implementazione pratica servizi di base

Unix: servizi di base 2

BIND

Introduzione a DNS

Quando gli host su di una rete, si collegano ad un'altra tramite un hostname, chiamato anche fully qualified domain name (FQDN), viene usato un DNS per associare i nomi delle macchine all'indirizzo IP per l'host.

L'uso dei nomi FQDN e DNS, è vantaggioso per gli amministratori di sistema, perché consente una certa flessibilità nella modifica degli indirizzi IP per un host, senza influire sulle query basate sui nomi dei computer stessi. Gli amministratori inoltre possono stabilire quale computer gestisce una query basata sui nomi.

Il DNS, viene normalmente implementato utilizzando server centrali che risultano "autorevoli" per alcuni domini e si rivolgono ad altri server DNS per ottenere le informazioni di cui non dispongono.

Quando un'applicazione client richiede informazioni al server dei nomi, di solito connettendosi ad esso tramite la porta 53 del server. Il server dei nomi cerca di risolvere l'FQDN in base alla sua libreria di conversione, che può contenere informazioni "autorevoli" per l'FQDN in questione oppure dati memorizzati in seguito a una precedente query. Se la libreria di conversione del server dei nomi non contiene già la risposta, esso si rivolgerà ad altri server di nomi, chiamati server dei nomi root per determinare quali sono i server di nomi autorevoli per l'FQDN in questione. Poi, con queste informazioni, chiede ai server dei nomi autorevoli il nome per determinare l'indirizzo IP. Se invece si esegue una ricerca inversa, viene utilizzata la stessa procedura, ma la richiesta è inoltrata con un indirizzo IP sconosciuto anziché un nome.


BIND

Zone del server dei nomi

In Internet, l'FQDN di un host può essere suddiviso in sezioni diverse, organizzate in una gerarchia ad albero con un tronco, dei rami principali, dei rami secondari e così via. Consideriamo il seguente FQDN:

www.mlib.cnr.itPer capire come l'FQDN venga convertito nell'indirizzo IP che si riferisce a un determinato

sistema, è necessario leggere il nome da destra a sinistra, con ogni livello della gerarchia separato da punti (.). In questo esempio, it indica il dominio ad alto livello per questo FQDN. cnr indica un sottodominio di it e, a sua volta, mlib è un sottodominio di cnr. L'ultimo nome a sinistra in un FQDN è il nome dell'host che identifica una determinato calcolatore.

A eccezione del nome host, ogni sezione è definita zona e contraddistingue un particolare spazio dei nomi. Uno spazio dei nomi controlla la denominazione dei sottodomini alla propria sinistra. Mentre in questo esempio sono contenuti solo due sottodomini, un FQDN deve contenerne almeno uno, ma può comprenderne molti di più, a seconda di come sono organizzati gli spazi dei nomi.

Le zone sono definite nei server dei nomi autorevoli mediante l'uso di file zone, che descrivono lo spazio dei nomi di quella zona e i server di posta da usare per un dominio o sottodominio particolare. I file zone sono memorizzati in server dei nomi primari (chiamati anche server master) che sono autorevoli e consentono la modifica dei file e nei server dei nomi secondari (chiamati anche server slave), che ricevono i propri file zone dai server dei nomi primari. Ogni server dei nomi può essere allo stesso tempo primario o secondario per zone diverse e può essere riconosciuto autorevole per più zone. Dipende tutto dalla configurazione del server dei nomi.


BIND

Tipi di server dei nomi

Esistono quattro tipi principali di configurazione per i server dei nomi: master — memorizza i record di zona originali e autorevoli per un

determinato spazio dei nomi, rispondendo a richieste di altri server e cercando risposte relative a quello spazio dei nomi.

slave — risponde a richieste di altri server dei nomi relative agli spazi dei nomi sui quali ha autorità. Comunque i server slave ottengono le informazioni sugli spazi dei nomi dai server master.

caching-only — offre il nome ai servizi di risoluzione IP ma non è autorevole per tutte le zone. Di norma, le risposte a tutte le risoluzioni vengono memorizzate in un database archiviato in memoria per un determinato periodo di tempo, solitamente specificato dal record di zona recuperato.

forwarding — inoltra richieste a un elenco specifico di server dei nomi da convertire. Se nessuno dei server specificati può eseguire la risoluzione, il processo si interrompe e la risoluzione non viene completata.

Un server dei nomi può essere di uno o più tipi tra quelli descritti. Per esempio può essere un master per alcune zone e uno slave per altre e può offrire solo una risoluzione forwarding.


BIND

BIND sta per Berkeley Internet Name Daemon ed è il servizio preposto alla risoluzione dei nomi –nodo di uno o più domini. Ossia questo servizio è in grado di risalire dal nome di dominio all’indirizzo IP della macchina oppure dato un indirizzo IP risalire al nome internet.

Per avviare il servizio la sintassi è la seguente:

# /etc/rc.d/init.d/named [start | stop | restart | status etc. ]

Il servizio di BIND fa riferimento al file /etc/named.conf. In questo file sono indicate le zone o domini ed i relativi files associati.

Per default i files relativi alla risoluzione diretta (nome->nodo) ed inversa (nodo->nome) sono localizati nella directory /var/named. Ogni dominio ha associato un file detto file di zona. Nel file sono memorizzati record di vario tipo:

A: Address record; contiene un host name ed il relativo indirizzo IPMX: Mailer exchanger; identifica il mailer nel dominioNS: Name server record; identifica il Name Server in una zonaHINFO: Record per descrivere il tipo di hardwarePTR: Reverse lookup; contiene un IP ed il relativo nomeCNAME: Canonical name; identifica un alias


BIND

/etc/named.confIl file /etc/named.conf è un insieme di istruzioni che utilizza opzioni nidificate tra parentesi graffe { }. Gli

amministratori devono prestare attenzione nel modificare named.conf in quanto piccoli errori di sintassi impediscono la partenza del servizio named.

Un file tipico named.conf é organizzato in modo del tutto simile al seguente esempio: <statement-1> ["<statement-1-name>"] [<statement-1-class>] {

<option-1>; <option-2>; <option-N>;

}; <statement-2> ["<statement-2-name>"] [<statement-2-class>] {

<option-1>; <option-2>; <option-N>;

}; <statement-N> ["<statement-N-name>"] [<statement-N-class>] { <option-1>;

<option-2>; <option-N>;

};


BIND

Tipi di statement comuni

I seguenti tipi di statement sono usati comunemente in /etc/named.conf:

Statement acl

Lo statement acl (o statement di controllo di accesso) definisce il gruppo o gli host permessi o meno all'accesso al server dei nomi. Un commento acl ha la seguente forma:

acl <acl-name> { <match-element>; [<match-element>; ...]

};

In questo statement sostituire <acl-nome> con il nome della lista di controllo accesso e sostituire < match-element > con una serie di indirizzi IP separati da un punto e virgola.

La maggior parte delle volte vengono utilizzati gli indirizzi IP individuali o le notazioni di rete IP (come 10.0.1.0/24) per identificare gli indirizzi IP all'interno del commento acl.


BIND

Le seguenti liste di controllo accessi sono già definite come parole chiavi per semplificare la configurazione:

any - corrisponde a ogni indirizzo IP. localhost - corrisponde a qualsiasi indirizzo IP in uso nel sistema locale. localnets - corrisponde a qualsiasi indirizzo IP in qualsiasi rete a cui il sistema locale

è connesso. none - non corrisponde a nessun indirizzo IP.

Gli statement acl uniti agli statement options possono essere molto utili nel prevenire l'uso improprio di un server dei nomi BIND.


BIND

Il seguente esempio definisce due liste di controllo di accesso e usa uno statement options per definire come vengono trattate dal server:

acl black-hats { 10.0.2.0/24; 192.168.0.0/24;

}; acl red-hats {

10.0.1.0/24; };

options { blackhole { black-hats; }; allow-query { red-hats; }; allow-recursion { red-hats; };

}

Questo esempio contiene due elenchi di controllo accesso, black-hats e red-hats. Agli host nell'elenco black-hats viene rifiutato l'accesso al server dei nomi, mentre a quelli nell'elenco red-hats viene dato.


BIND

Statement options

Lo statement options definisce le opzioni di configurazione globale del server e imposta i default per altri statement. Puó essere usato per specificare la posizione della directory di lavoro named i tipi di query permessi e molto altro.

Il commento options assume la seguente forma:

options { <option>; [<option>; ...]

};


BIND

Le seguenti sono opzioni usate comunemente:

allow-query — specifica gli host autorizzati a interrogare questo server dei nomi. Per default, tutti gli host sono autorizzati. Un elenco di controllo accessi o un insieme degli indirizzi o reti IP può essere utilizzato, in questo caso, solo per autorizzare degli host particolari a interrogare il server dei nomi.

allow-recursion — simile a allow-query, tranne per il fatto che viene utilizzato per richieste ricorsive. Per default, tutti gli host sono autorizzati ad effettuare richieste ricorsive ai server dei nomi.

blackhole — Specifica quali host non possono interrogare i server. directory — modifica la directory di lavoro named (/var/named/), in una directory

diversa da quella predefinita /var/named. forward — controlla il modo in cui avviene l'inoltro da parte di una direttiva

forwarders. Sono accettate le seguenti opzioni:

first — i server dei nomi specificati nell'opzione forwarders vengono interrogati per primi e se non dispongono delle informazioni richieste named tenta di eseguire la risoluzione da solo.

only — Specifica che named non tenta di eseguire la risoluzione se i forwarder non hanno buon esito.

forwarders — Specifica un elenco di indirizzi IP validi per i server dei nomi a cui inviare le richieste di risoluzione.


BIND

listen-on — specifica l'interfaccia di rete che named utilizza per ricevere le interrogazioni. Per default, vengono utilizzate tutte le interfacce. In questo modo, se il server DNS é anche una porta "gateway", BIND puó essere configurato a rispondere alle domande che vengono fatte da una delle reti.A listen-on le direttive possono somigliare a quanto segue:

options { listen-on { 10.0.1.1; }; };

In tal modo vengono accettate solo le richieste che provengono dall'interfaccia che funge da rete privata (10.0.1.1)

notify — controlla se named invia una notifica ai server slave quando viene aggiornata una zona. Accetta le seguenti opzioni:

yes — Notifica i server slave. no — Non notifica i server slave. explicit — Notifica solo i server specificati in un elenco also-notify all'interno del

commento di zona. pid-file — vi consente di specificare la posizione del file di processo ID creato da named. statistics-file — Vi consente di specificare la posizione in cui è stato salvato il file delle

statistiche. Per default, le statistiche di named vengono salvate in /var/named/named.stats.

Sono inoltre disponibili decine di altre opzioni, molte delle quali dipendono l'una dall'altra per poter funzionare correttamente. Per maggiori dettagli, consultare il BIND 9 Administrator Reference Manual e la pagina man per bind.conf.


BIND

Statement zone

Uno statement zone definisce le caratteristiche di una zona come ad esempio la posizione dei propri file di configurazione e le opzioni specifiche di zona. Questo statement puó essere usato per sovrascrivere i commenti globali options.

Un statement zone assume la seguente forma:

zone <zone-name> <zone-class> { <zone-options>; [<zone-options>; ...]

};

<nome-zona> é il nome della zona, <classe-zona> é la zona facoltativa della zona, e <opzioni-zona> é un elenco di opzioni che caratterizzano la zona.

L'attributo <nome-zona> per il commento della zona, é particolarmente importante, dato che esso é il valore di default assegnato per la direttiva $ORIGIN usata all'interno il corrispondente file zone posizionato nella directory named. Il demone named conferisce il nome della zona a qualsiasi nome del dominio non qualificato elencato nel file zone.


BIND

Le opzioni piú comuni della zone include quanto segue:

allow-query — Specifica i client che sono permessi a richiedere informazioni inerenti questa zona. Per default tutte le richieste vengono permesse.

allow-transfer — Specifica i server slave abilitati a richiedere un trasferimento delle informazioni della zona. Il default é di permettere tutte le richieste di trasferimento.

allow-update — Specifica gli host che sono permessi ad aggiornare dinamicamente le informazioni nella loro zona. Il default é di negare tutte le richieste di aggiornamento dinamico. Fare attenzione a permettere agli host di aggiornare le informazioni inerenti le loro zone. Non abilitare questa funzione se l'utente non é fidato. In generale, é meglio avere un amministratore che aggiorni manualmente le informazioni e ricaricare il servizio named.

file — Specifica il nome del file nella directory di lavoro che contiene i dati di configurazione della zona. Il default é la directory /var/named/.

masters — L'opzione masters elenca gli indirizzi IP dai quali L'opzione masters elenca gli indirizzi IP dai quali si effettua la richiesta di informazioni di zona. Usarla solo se la zona é definita come type slave.


BIND

notify — Controlla se named notifica i server slave quando si aggiorna una zona. Accetta le seguenti opzioni:

yes — Notifica i server slave. no — Non notifica i server slave.

explicit — Notifica solo i server slave specificati in un elenco also-notify all'interno di un commento di zona.

type — Definisce il tipo di zona. Di seguito viene riportata una lista di opzioni valide:

forward — chiede al server dei nomi di reindirizzare ad altri server tutte le richieste di informazioni su questa zona.

hint — tipo speciale di zona usato per fare riferimento ai server dei nomi root, utilizzati per risolvere richieste quando una zona è sconosciuta. In genere non è necessario configurare una zona del tipo hint.

master — Definisce il server dei nomi autorevole per questa zona. Occorre impostare una zona del tipo master se nel vostro sistema vi sono i file di configurazione della zona.

slave — Definisce il server come slave per questa zona. Specifica anche l'indirizzo IP del server dei nomi per la zona.

zone-statistics — ordina al demone named di conservare le statistiche relative alla zona, memorizzandole nella posizione predefinita (/var/named/named.stats) o in una posizione definita con l'opzione statistics-file nell'istruzione server, se esistente.


BIND

File zone

I file zone, contenenti le informazioni relative a un determinato spazio dei nomi, sono memorizzati nella directory operativa di named (per default /var/named). Il nome di ogni file zone dipende dai dati indicati nell'opzione file contenuta nell'istruzione zone. In genere si riferisce al dominio in questione e identifica il file poiché contiene dati sulla zona, come per esempio example.com.zone.

Ogni file zone può contenere direttive e record di risorsa. Le direttive indicano al server dei nomi di eseguire una certa azione o di eseguire un'impostazione speciale per la zona. I record di risorsa definiscono i parametri della zona attribuendo un'identità a determinati sistemi nello spazio dei nomi della zona. Le direttive sono facoltative, mentre i record di risorsa sono necessari per fornire il servizio dei nomi a quella zona.

Tutte le direttive e i record di risorsa dovrebbero occupare righe diverse. Nei file zone è possibile aggiungere dei commenti dopo il carattere punto e virgola

(;).

Direttive dei file zone

Le direttive sono contraddistinte dal carattere $ che precede il nome della direttiva e che di solito si trova all'inizio del file zone.

Le direttive più usate sono le seguenti: $INCLUDE — indica a named di includere un file zone in un altro file nel punto in cui

viene usata la direttiva. Ciò consente di memorizzare impostazioni di zona aggiuntive separatamente dal file zone principale.


BIND

$ORIGIN — imposta il nome del dominio da accodare a qualsiasi record non qualificato, come quelli che specificano solo l'host e nient'altro. Per esempio, un file zone potrebbe contenere una riga come la seguente:

$ORIGIN example.com A questo punto a qualsiasi nome utilizzato nei record di risorsa, che non finisca

con un punto (.), presenterá example.com. Non è necessario usare la direttiva $ORIGIN se alla zona si assegna un nome nel file /etc/named.conf identico al valore che assegnereste a $ORIGIN. Il nome della zona viene utilizzato, per default, come valore della direttiva $ORIGIN.

$TTL — imposta il valore predefinito Time to Live (TTL) per la zona. Si tratta di un valore, in secondi, assegnato ai server dei nomi che indica il periodo di validità dei record di risorsa della zona. Un record di risorsa può avere un valore TTL proprio, che annulla quindi quello impostato da questa direttiva. Impostando un valore più alto si indica ai server dei nomi di conservare in memoria queste informazioni di zona per un periodo di tempo maggiore. Ciò riduce il numero di richieste relative a questa zona, ma allunga anche il tempo necessario per modificare il record di risorse.


BIND

Record di risorsa del file zone

Il componente primario di un file zone sono i propri record di risorsa. Ci sono molti tipi di file di record di risorsa, I seguenti tipi sono tra i più usati:

A — record di indirizzo che specifica un indirizzo IP da assegnare al nome, come in questo esempio:

<host> IN A <IP-address>

Se non viene indicato il valore <host>, il record A fa riferimento a un indirizzo IP predefinito per l'inizio dello spazio dei nomi. Questo sistema è utilizzato per tutte le richieste non FQDN.Prendete in considerazione i seguenti esempi di record A per il file zone example.com:

IN A 10.0.1.3 server1 IN A 10.0.1.5

Le richieste per example.com vengono indirizzate a 10.0.1.3, mentre quelle per server1.example.com a 10.0.1.5.


BIND

CNAME — record di nome tipico che mappa un nome all'altro, conosciuto anche come un alias. L'esempio successivo indica a named che tutte le richieste inviate a <nome-alias> sono dirette all'host <nome-reale>. I record CNAME sono utilizzati più comunemente per essere diretti a servizi che utilizzano uno schema di assegnazione dei nomi comune per l'host corretto, come ad esempio www per i server Web.

<alias-name> IN CNAME <real-name>

Consideriamo l'esempio riportato di seguito, in cui il record A imposta un indirizzo IP per un determinato nome di host e il record CNAME evidenzia come nome alias il nome host più comunemente usato www.

server1 IN A 10.0.1.5 www IN CNAME server1


BIND

MX — si tratta del record "Mail eXchange", che indica dove va inoltrata la posta inviata a un particolare spazio dei nomi controllato da questa zona.

IN MX <preference-value> <email-server-name>

In questo esempio il <valore-preferenza> vi consente di classificare numericamente i server e-mail su cui preferite ricevere la posta elettronica per questo spazio dei nomi, dando la precedenza ad alcuni sistemi e-mail rispetto ad altri. Il record di risorsa MX con il <valore-preferenza> più basso ha la precedenza sugli altri, ma potete comunque impostare vari server di posta elettronica con lo stesso valore e distribuire quindi il traffico di posta.Il <nome-server-email> può essere un nome host o un FQDN.

IN MX 10 mail.example.com. IN MX 20 mail2.example.com.

In questo esempio il primo server di posta mail.example.com ha la precedenza sul server mail2.example.com al momento della ricezione di posta per il dominio example.com.


BIND

NS — record NameServer che annuncia i server dei nomi autorevoli per una determinata zona. Ecco un esempio di record NS:

IN NS <nameserver-name>

L'opzione <nome-servernomi> deve corrispondere a un FQDN. Di seguito sono elencati due nomi di server come autorevoli per un dominio. Non importa se questi server dei nomi sono slave o master, poiché entrambi sono considerati autorevoli.

IN NS dns1.example.com. IN NS dns2.example.com.

PTR — record "PoinTeR" che serve per fare riferimento a un'altra "porzione" dello spazio dei nomi. I record PTR vengono usati principalmente per invertire la risoluzione del nome, riconvertendo gli indirizzi IP in un particolare nome. I record PTR saranno meglio spigati nei file per la risoluzione inversa.


BIND

SOA — acronimo di "Start Of Authority", questo record indica al server dei nomi, importanti informazioni autorevoli sullo spazio nomi.Posizionato dopo le direttive, SOA è il primo record di risorsa in un file zone.L'esempio riportato di seguito mostra la struttura di base di un record SOA:

@ IN SOA < primary-name-server> <hostmaster-email> ( <serial-number> <time-to-refresh> <time-to-retry> <time-to-expire> <minimum-TTL> )

Il simbolo @ serve a posizionare la direttiva $ORIGIN (o il nome della zona, se la direttiva non è impostata) come spazio dei nomi definito dal record di risorsa SOA. In <nome-server-primario> va indicato il server dei nomi primario e autorevole per questo dominio, mentre in <email-hostmaster> va inserito l'indirizzo e-mail della persona da contattare per questo spazio dei nomi.


BIND

In BIND il tempo viene riportato in secondi. Comunque potete utilizzare anche delle abbreviazioni per altre unità di tempo, come minuti (M), ore (H), giorni (D) e settimane (W). La tabella mostra un lasso di tempo in secondi e l'equivalente in un'altra unità.

Secondi Altre unità di tempo

60 1M

1800 30M

3600 1H

10800 3H

21600 6H

43200 12H

86400 1D

259200 3D

604800 1W

31536000 365D


BIND

$ORIGIN example.com $TTL 86400 @ IN SOA dns1.example.com. hostmaster.example.com.

( 2001062501 ; serial 2 1600 ; refresh after 6 hours 3600 ; retry after 1 hour 604800 ; expire after 1 week 86400 ) ; minimum TTL of 1 day IN NS dns1.example.com. IN NS dns2.example.com. IN MX 10 mail.example.com. IN MX 20 mail2.example.com. IN A 10.0.1.5

server1 IN A 10.0.1.5 server2 IN A 10.0.1.7 dns1 IN A 10.0.1.2 dns2 IN A 10.0.1.3 ftp IN CNAME server1 mail IN CNAME server1 mail2 IN CNAME server2 www IN CNAME server2


BIND

File zone per la risoluzione nomi inversa

Un file zone per la risoluzione nomi inversa viene utilizzato per tradurre un indirizzo IP in un FQDN all'interno di un particolare spazio dei nomi. Somiglia molto a un file zone standard, tranne per il fatto che i record di risorsa PTR vengono utilizzati per collegare gli indirizzi IP al nome di un determinato sistema.

Un record PTR è simile a quanto riportato di seguito:

<last-IP-digit> IN PTR <FQDN-of-system>

L'<ultima-cifra-IP> si riferisce all'ultimo numero in un indirizzo IP che dovrebbe far riferimento all'FQDN di un determinato sistema.


BIND

Nell'esempio gli indirizzi IP da 10.0.1.20 a 10.0.1.25 fanno riferimento agli FQDN corrispondenti.

$ORIGIN 1.0.10.in-addr.arpa $TTL 86400 @ IN SOA dns1.example.com. hostmaster.example.com.(

2001062501 ; serial21600 ; refresh after 6 hours 3600 ; retry after 1 hour604800 ; expire after 1 week 86400 ; minimum TTL of 1 day )

IN NS dns1.example.com. IN NS dns2.example.com.

20 IN PTR alice.example.com. 21 IN PTR betty.example.com. 22 IN PTR charlie.example.com. 23 IN PTR doug.example.com. 24 IN PTR ernest.example.com. 25 IN PTR fanny.example.com.


BIND

Questo file zone viene utilizzato con l'istruzione zone nel file named.conf simile a quello riportato di seguito:

zone "1.0.10.in-addr.arpa" IN { type master; file "example.com.rr.zone";allow-update { none; };

};

Esiste una differenza davvero minima tra questo esempio e un'istruzione standard zone, salvo per il nome della zona. Una zona per la risoluzione inversa dei nomi richiede che siano invertiti i primi tre blocchi dell'indirizzo IP e che dopo di questi venga aggiunto ".in-addr.arpa". Ciò permette che il blocco singolo di numeri IP utilizzato nel file della zona per la risoluzione inversa dei nomi venga collegato correttamente in questa zona.


BIND

Errori comuni da evitare

Spesso i principianti commettono degli errori quando modificano i file di configurazione di BIND. Assicuratevi quindi di evitare i seguenti problemi:

Quando modificate un file zone, assicuratevi di incrementare il numero seriale. Se non incrementate il numero seriale, il vostro server dei nomi master potrà disporre delle nuove informazioni, ma i server slave non riceveranno notifiche di cambiamenti e non aggiorneranno quindi i propri dati relativi a quella zona.

Ricordatevi di usare in modo corretto le parentesi graffe e i punti e virgola nel file /etc/named.conf

Se omettete un punto e virgola oppure una parentesi, named non può essere avviato. Non dimenticatevi di mettere i punti (.) nei file zone dopo tutti gli FQDN e di ometterli

nei nomi host. Il punto indica che il nome assegnato è completo. Se manca il punto, named completerà questo nome con quello della zona o con il valore di $ORIGIN.

Se un firewall blocca le connessioni tra il demone named e altri server dei nomi, potrebbe essere necessario modificare il file di configurazione. Per default, la versione 9 di BIND utilizza infatti porte casuali superiori alla 1024 per chiedere ad altri server di risolvere i nomi. Alcuni firewall, tuttavia, presuppongono che i server dei nomi comunichino tra loro utilizzando la porta 53. Quindi per forzare questo comportamento, inserite la seguente riga nell'istruzione options di /etc/named.conf:

query-source address * port 53;


Sendmail

E-mail

La nascita della posta elettronica (email) risale al 1960. Il mailbox era un file nella homedirectory dell'utente ed era leggibile solo da quell'utente. Le prime applicazioni per posta allegavano nuovi messaggi di testo nella parte inferiore del file, e l'utente doveva ricercare all'interno del file, quel particolare messaggio. Questo sistema era solo in grado di inviare messaggi agli utenti sullo stesso sistema.

Il primo vero trasferimento di rete di un messaggio di posta elettronica, é avvenuto nel 1971, quando un ingegnere di computer chiamato Ray Tomlinson invió un messaggio prova tra due macchine tramite ARPANET — il precursore di Internet. La comunicazione tramite email, diventó presto molto popolare, raggiungendo il 75 per cento del traffico di ARPANET in meno di 2 anni.

Oggi, il sistema basato su email su protocolli di rete standardizzati si sono evoluti in uno dei servizi piú diffusi di Internet.

Protocolli Email

Oggi, la email viene consegnata usando una architettura client/server. Un messaggio email é creato usando un programma client di posta. Questo programma poi, invia il messaggio a un server. Il server a sua volta inoltra il messaggio al server email del ricevente, dove il messaggio viene fornito al client email del ricevente.

Per abilitare questo processo, vi sono un certo numero di protocolli di rete standard che permettono a macchine diverse, che spesso eseguono sistemi operativi diversi e usano diversi programmi email, di inviare e ricevere email.

I seguenti protocolli sono fra i più comunemente utilizzati per il trasferimento di e-mail da un sistema all'altro.


Sendmail

Protocolli di trasporto posta

La consegna di posta da una applicazione client al server, e da un server originatore al server destinatario, é gestita dal Simple Mail Transfer Protocol (SMTP) .

SMTPLo scopo primario di SMTP é quello di trasferire le email tra i server di posta.

Tuttavia, é una fase critica anche per i client email. Per poter inviare email, il client invia il messaggio ad un server di posta in uscita, il quale contatta il server di posta destinatario per la consegna. Per questa ragione, é necessario specificare un server SMTP quando si configura un client email.

Con Red Hat Linux, un utente puó configurare un server SMTP sulla macchina locale per gestire la consegna della posta. Tuttavia, é possibile anche configurare server SMTP remoti per posta in uscita.

É inoltre importante puntualizzare che il protocollo SMTP non richiede una autenticazione. Questo permette a chiunque su Internet, di inviare email ad chiunque oppure a un gruppo molto grande di persone. É questa caratteristica di SMTP che rende possibile la cosí detta posta indesiderata o spam. I server SMTP moderni cercano di minimizzare questo comportamento, abilitando all'accesso solo host conosciuti. Questi server che non abilitano una tale restrizione vengono chiamati server open relay.

Red Hat Linux usa Sendmail (/usr/sbin/sendmail) come programma SMTP di default.


Sendmail

Mail Access Protocols

Ci sono due protocolli primari usati dalle applicazioni client email per riprendere le email dai server posta: il Post Office Protocol (POP) e il Internet Message Access Protocol (IMAP).

Diversamente da SMTP, entrambi questi protocolli richiedono ai client collegati una autenticazione usando il nome utente e una password. Per default, le password per entrambi i protocolli sono passete attraverso la rete in chiaro.

POPIl server POP di default con Red Hat Linux é /usr/sbin/ipop3d ed é fornito dal pacchetto

imap. Quando si usa un server POP, i messagi email sono scaricati dalle applicazioni client email. Per default, la maggior parte dei client POP di e-mail è configurata per l'eliminazione automatica del messaggio sul mail server dopo che questo è stato trasferito con successo sul sistema del client, anche se questo solitamente viene modificato.

POP é completamente compatibile con importante messaggistica Internet standard, come ad esempio Multipurpose Internet Mail Extensions (MIME), che permette di inserire gli allegati.

Il POP funziona meglio per utenti che hanno un sistema sul quale leggere la email. Lavora bene anche per utenti che non hanno una connessione persistente a Internet oppure una rete contenente il server posta. Sfortunatamente per quelli che hanno una connessione di rete lenta, POP richiede programmi client previa autenticazione, per scaricare l'intero contenuto di ogni messaggio. Questo puó richiedere molto tempo se un messaggio ha un allegato molto grande.


Sendmail

La versione piú recente del protocollo POP standard é POP3. Ci sono tuttavia una varietá di protocolli POP usati meno frequentemente: APOP — POP3 con autenticazione MDS, in cui il client e-mail invia al server la

password criptata e non in chiaro. KPOP — POP3 con autenticazione Kerberos. RPOP — POP3 con autenticazione RPOP, utilizza un'ID per ogni utente, simile a una

password, per autenticare le richieste del POP. L'ID non è tuttavia criptato, quindi RPOP non è più sicuro di un POP standard.

Per aumentare la sicurezza, é possibile usare il metodo di cifratura Secure Socket Layer (SSL) per autenticazione del client e per le sessioni di trasferimento dati. Questo puó essere abilitato usando il servizio ipop3s, oppure usando il programma /usr/sbin/stunnel.

IMAPIl server IMAP di default con Red Hat Linux é /usr/sbin/imapd ed é fornito dal

pacchetto imap. Quando si utilizza l'IMAP i messaggi di posta elettronica rimangono nell'e-mail server remoto, dove l'utente può leggerli o cancellarli, e creare, rinominare o eliminare caselle di posta per archiviare le e-mail.

L'IMAP è utilizzato principalmente da utenti che possono accedere alle e-mail mediante più computer. Gli utenti connessi a Internet o a una rete privata mediante connessione a banda bassa utilizzano spesso questo protocollo, poiché inizialmente visualizza le informazioni di testa del messaggio. Allo stesso modo, l'utente può cancellare i messaggi e-mail indesiderati senza visualizzare il corpo del messaggio, evitando addirittura di scaricarlo durante la connessione.


Sendmail

Per convenienza, le applicazioni client IMAP sono capaci di ottenere delle copie di messaggi in modo locale, in modo tale da permettere all'utente di controllare i messaggi letti precedentemente, anche non essendo collegato direttamente al server IMAP.

IMAP, come POP, é compatibile con importanti messaggi standard, come ad esempio MIME, il quale permette la creazione di allegati.

Per aumentare la sicurezza, é possibile usare il metodo di cifratura Secure Socket Layer (SSL) per autenticazione del client e per le sessioni di trasferimento dati. Questo puó essere abilitato usando il servizio imaps, oppure usando il programma /usr/sbin/stunnel.

Altri client e server IMAP sono disponibili sia gratis che a pagamento, molti dedi quali estendono il protocollo IMAP e forniscono delle funzioni aggiuntive. Un elenco completo puó essere trovato su http://www.imap.org/products/longlist.htm.


Sendmail

Diversi tipi di programmi e-mail

In generale, esistono tre tipi di programmi e-mail, ciascuno dei quali svolge un ruolo specifico nel processo di trasferimento e gestione dei messaggi di posta elettronica. La maggior parte degli utenti conosce solo il programma e-mail usato specificatamente per ricevere e inviare i messaggi, ma perché il messaggio arrivi al corretto destinatario sono fondamentali tutti e tre.

1. Mail Transfer AgentIl Mail Transfer Agent (MTA) rende possibile il trasferimento dei messaggi email tra host

usando SMTP. Un messaggio puó interessare diversi MTA mentre si sposta verso la destinazione desiderata.

La consegna dei messaggi tra computer sembra abbastanza diretta, ma in realtà l'intero processo necessario per decidere se un particolare MTA può o dovrebbe accettare un messaggio per la consegna, è piuttosto complicato. Inoltre, a causa di problemi dovuti allo spamming, l'uso di un MTA specifico è in genere limitato dalla sua stessa configurazione o dall'accesso alla rete del sistema che lo esegue.

Molti programmi client email moderni possono essere usati come un MTA durante l'invio di email. Tuttavia, la suddetta azione non deve essere confusa con i compiti di un MTA vero e proprio. La sola ragione per la quale i programmi client email sono capaci di inviare email, (come un MTA) é perché l'host che esegue l'applicazione, non ha il prorio MTA. Questo é particolarmente vero per i programmi client email su sistemi operativi non-Unix. Tuttavia, questi programmi client possono inviare solo messaggi in uscita ad un MTA che essi hanno autorizzato ad usare e non consegnano direttamente il messaggio al server email ricevente desiderato.


Sendmail

2. Mail Delivery Agent

Il Mail Delivery Agent (MDA) è utilizzato dall'MTA per consegnare le e-mail a una mailbox utente specifica. In molti casi, l'MDA è di fatto un Local Delivery Agent (LDA), come ad esempio mail o Procmail.

Tutti i programmi che gestiscono un messaggio da consegnare fino al punto in cui può essere letto da un MUA possono essere considerati MDA. Per questa ragione, alcuni MTA (come ad esempio Sendmail e Postfix) possono ricoprire il ruolo di un MDA quando aggiungono nuovi messaggi email ad un file spool di posta dell'utente locale. In generale, é importante ricordare che gli MDA non trasportano messaggi tra sistemi o interfacce; MDA distribuisce messaggi sulla macchina locale per far accedere una applicazione client email.

3. Mail User Agent

Un Mail User Agent (MUA) é sinonimo di applicazione client email. É un programma che consente all'utente almeno di leggere e scrivere messaggi e-mail. Molti MUA permettono all'utente di svolgere altri compiti, fra cui il reperimento di messaggi attraverso i protocolli POP o IMAP, l'impostazione di mailbox per archiviare i messaggi e il passaggio delle nuove e-mail a un programma Mail Transfer Agent.

I programmi MUA possono essere grafici, come Mozilla Mail, oppure possono avere un interfaccia semplice, basata sul testo, per esempio Mutt o pine.


Squid Proxy Server

Squid è un proxy caching server ad alte

prestazioni per client web. Cosa significa “caching”?. Il servizio processa la richiesta di un oggetto da parte di un client e conserva una copia dell’ogetto prima di inviarlo al client. In questo modo si ottengono due scopi; il primo è quello di nascondere il client da Internet e in secondo luogo fornire lo stesso oggetto ad altri client senza effettuare un nuova richiesta alla sorgente. Fornisce inoltre un passaggio obbligato per i flussi di dati in modo da poter effettuare una azione di filtro per motivi di sicurezza. Supporta dati da FTP, Gopher e HTTP. Mantiene in una memoria cache RAM tabelle di conversione DNS. Implementa SSL.

Il server è costituito da un programma principale, un Domain Name System, alcuni programmi optional per la riscrittura delle richieste e permettere autenticazione, alcuni tools di gestione e client.

Squid deriva dall’ ARPA-funded Harvest Project http://harvest.cs.colorado.edu/


Squid Proxy Server

Installazione

Il file di configurazione del server Squid è: /etc/squid/squid.conf

Questo file di configurazione è ampiamente commentato e contiene tutte le informazioni necessarie. Per funzionare le operazioni minime sono quelle di scommentare nel file di configurazione le seguenti righe e impostare gli appropriati valori:

httpd_accel_host virtualhttpd_accel_port 80httpd_accel_with_proxy on httpd_accel_uses_host_header on

Da ultimo impostare le access list. Di solito il valore di default è:http_access deny all

Questo impedisce a chiunque di accedere al proxy; in prima istanza questo valore può essere impostato a http_access allow all. E’ bene però impostare regole più restrittive in modo da impedire l’accesso a persone non autorizzate. Molto spesso si possono aggirare ostacoli o utilzzare cache poco protette e di conseguenza portare a decadimento l’ ampiezza di banda.

Per avviare il servizio # # /usr/local/squid /usr/local/squid <start C| stop | restart><start C| stop | restart>

Per default la porta di accesso alla cache è la 3128, questa può essere cambiata a seconda delle esigenze.


Server WEB Apache

Apache è il tipico web server che viene fornito in gran parte delle distribuzioni Linux. Il Demone responsabile del servizio è chiamato httpd (Hyper Text Transfer Protocol).

Il file di configurazione nella distribuzione RedHat è /etc/httpd/conf/httpd.conf

Mentre la directory default di partenza di Apache à /var/www.

Per avviare il server Web la riga di comando è: # /etc/rc.d/init.d/httpd [ start | stop | restart | status ]


Server WEB Apache

Configurazione del Server HTTP Apache Lo Strumento di configurazione di HTTP consente di configurare il file di

configurazione /etc/httpd/conf/httpd.conf per il Server HTTP Apache. Tramite l'interfaccia grafica, si possono configurare direttive quali host virtuali, attributi di login e numero massimo di connessioni.

Soltanto i moduli contenuti nella confezione di Red Hat Linux possono essere configurati mediante lo Strumento di configurazione di HTTP. Eventuali moduli aggiuntivi installati non possono essere configurati utilizzando questo tool.

Per poter usare lo Strumento di configurazione di HTTP, i pacchetti RPM redhat-config-httpd e httpd devono essere installati. Viene anche richiesto il sistema X Window e l'accesso come root. Per avviare l'applicazione, selezionare il Pulsante menu principale Impostazioni Server => Server HTTP oppure digitare il comando redhat-config-httpd al prompt della shell (per esempio, su un terminale XTerm o GNOME).

Per configurare il Server HTTP Apache mediante il Strumento di configurazione di HTTP è sufficiente eseguire quanto segue:

1. Configurare le impostazioni di base nel Tab Main.2. Fate clic sul Tab Virtual Hosts e configurare le impostazioni di default.3. Nel Tab Host virtuali, configurare l'host virtuale predefinito (Default Virtual Host).4. Se si desidera servire più URL o host virtuali, aggiungere altri host virtuali.5. Configurare le impostazioni del server nel Tab Server.6. Configurare le impostazioni di connessione nel Tab Ottimizzazione delle

prestazioni.7. Copiare tutti i file necessari nelle directory DocumentRoot e cgi-bin.8. Uscrte dall'applicazione e selezionare si per salvare le impostazioni.


Server WEB Apache

Impostazioni di base

Digitare un nome di dominio completo che sia consentito usare nell'area di testo Nome del server. Questa opzione corrisponde alla direttiva ServerName contenuta in httpd.conf. La direttiva Nome del server imposta l'hostname del server Web e serve per creare URL di reindirizzamento. Se non si definisce alcun nome per il server, il server Web cercherà di risolverlo sulla base dell'indirizzo IP o dal sistema. Il nome del server non deve necessariamente essere il nome di dominio risolto dall'indirizzo IP del server. Per esempio, si può impostare il nome del server come www.example.com se il nome DNS effettivo del vostro server è dns.example.com. Inserire l'indirizzo email dell'amministratore del server nell'area di testo Webmaster email address. Questa opzione corrisponde alla direttiva ServerAdmin contenuta in httpd.conf. Se si confiurano le pagine di errore del server in modo che contengano un determinato indirizzo email, tale indirizzo sarà a disposizione degli utenti per segnalare eventuali problemi all'amministratore del server. Il valore predefinito è root@localhost.

Utilizzare l'area Indirizzi disponibili per determinare le porte sulle quali il server accetterà le richieste in entrata. Questa opzione corrisponde alla direttiva Listen contenuta in httpd.conf. Per default, Red Hat configura il Server HTTP Apache in modo che resti in ascolto sulla porta 80 per le comunicazioni Web non sicure.


Server WEB Apache

Fare clic su Aggiungi per definire delle porte aggiuntive sulle quali il server accetterà le richieste. Comparirà una finestra come quella mostrata nella figura. A questo punto selezionare l'opzione Ascolto di tutti gli indirizzi per far passare tutti gli indirizzi IP dalla porta definita oppure specificate nel campo Indirizzo un indirizzo IP dal quale il server accetterà le connessioni. Specificatene uno solo per ogni numero di porta. Se si desidera specificare più di un indirizzo IP per una medisima porta, creare una voce per ogni singolo indirizzo IP. Se possibile, utilizzare un indirizzo IP al posto di un nome di dominio onde evitare che un lookup DNS possa fallire. Inserire un asterisco(*) nel campo Indirizzo equivale a selezionare l'opzione Ascolto di tutti gli indirizzi. Cliccando su Modifica compare la stessa finestra di Aggiungi (cambiano solo i campi relativi all voce selezionata). Per cancellare una voce, selezionarla e fare clic su Cancella.

Se si imposta il server in modo che resti in ascolto su una porta inferiore alla 1024, ci si deve collegare come root per avviarlo. Per le porte 1024 e superiori, httpd può essere avviato da utenti normali.


Glossario

AGP Accelerated Graphics Port ATA Advanced Technology Attachment BIND Berkeley Internet Name Daemon BIOS Basic Input/Output System CPU Central Processing Unit DHCP Dynamic Host Configuration Protocol EISA Extended Industry Standard

Architecture FTP File Transfer Protocol GUI Graphical User Interface HTTP Hyper Text Transfer Protocol IDE Intelligent Drive Electronics I2O Intelligent I/O ISA Industry Standard Architecture LBA Logical Block Allocation MBR Master Boot Record MCA Micro Channel Architecture NFS Network File System PCI Peripheral Component Interconnect PCMCIA Personal Computer Memory Card

International Association POP Post Office Protocol SCSI Small Computer System Interface

SMP Symmetric MultiProcessing SMTP Simple Mail Transfer Protocol UPS Uninterruptable Power Supply URL Uniform Resource Locator USB Universal Serial Bus


Bibliogrtafia/sitografia

Linux: www.linux.org Linux Redhat: http://www.redhat.com BIND: http://www.isc.org/products/BIND Sandmail: http://www.sendmail.org Squid: http://www.squid-cache.org Apache: http://www.apache.org

UNIX: implementazione pratica servizi ausiliari

Unix: servizi ausiliari 45

DHCP Dynamic Host Configuration Protocol

Ogni computer connesso ad Internet deve avere un suo proprio indirizzo IP. Questi indirizzi possono essere fissati permanentemente sul sistema locale oppure ottenuti attraverso un DHCP server. In Linux per esempio, gli indirizzi IP statici sono indicati nel file /etc/sysconfig/network-scripts/ifcfg-eth0 e sono determinati durante l’inizializzazione del sistema. Se si usa un DHCP server, ogni computer non ha bisogno di mantenere un indirizzamento fisso. Durante lo startup ogni computer esegue una richiesta al server il quale fornirà un indirizzo IP che il computer stesso potrà utilizzare. In Linux il servizio DHCP viene fornito dal demone dhcpd ed è avviato con:

# /etc/rc.d/init.d/dhcpd start

Le informazioni sugli indirizzi IP sono contenute nel file /etc/dhcpd.conf sono: Indirizzo IP Subnet mask Default gateway DNS domain name DNS server


DHCP

Dhcpd può fornire indirizzi in maniera dinamica o statica:

Indirizzamento dinamico: un certo numero di indirizzi viene impostato in anticipo. Quando si verifica una richiesta viene fornito un indirizzo non usato. Lo stesso indirizzo viene fornito ripetutamente allo stesso client finche il periodo di lease non termina.

Indirizzamento statico: gli indirizzi sono assegnati univocamente a determinati MAC (Media Access Control) address dei client.


DHCP

Esempio di file /etc/dhcpd.conf

option domain-name-server 10.152.240.16

option routers 192.168.1.254;

default-lease-time 21600;

host venus {

hardware ethernet 08:00:2b:3a:69:8d:

fixed-address 192.168.1.10;

}

subnet 192.168.1.0 netmask 255.255.255.0 {

range 192.168.1.33 192.168.1.62;

default-lease-time 600 max-lease-time 7200;

option subnet-mask 255.255.255.0;

option routers 192.168.1.1;

option domain-name-servers 192.168.1.2 ,192.168.1.3;

option domain-name “abc.org”;

}


NFS Network File System

NFS (Network File System) consente di montare delle partizioni su un sistema remoto e utilizzarle come se fossero filesystem locali. Ciò permette all'amministratore del sistema di immagazzinare le risorse in una posizione centrale sulla rete, garantendo agli utenti autorizzati la possibilità di accedervi costantemente. L'NFS permette di condividere file tra computer in rete come se fossero sul disco fisso locale del client. Red Hat Linux può essere sia un server che un client NFS, il che significa che può esportare filesystem verso altri sistemi nonché montare filesystem esportati da altri computer.

Perché usare NFS?NFS è utile per la condivisione di directory di file fra più utenti su una

stessa rete. Per esempio un gruppo che lavora su uno stesso progetto può accedere ai file di questo progetto usando una parte condivisa del filesystem di NFS (solitamente chiamata condivisione NFS) montata nella directory /myproject. Per accedere ai file condivisi, l'utente entra nella directory /myproject dal suo computer. Per accedervi non è richiesta alcuna password né alcun comando particolare. L'utente lavora come se la directory si trovasse sul suo computer locale.

Al momento sono disponibili due versioni di NFS. La versione 2 (NFSv2), che esiste già da alcuni anni, è ampiamente supportata da diversi sistemi operativi. La versione 3 (NFSv3) offre alcune opzioni aggiuntive, come un file handle di lunghezza variabile e report di errore più completi. Red Hat Linux ha il supporto per entrambi le versioni (NFSv2 e NFSv3) e utilizza NSFv3 per default in caso di connessione con un server che supporta tale versione.


NFS

Per consentire la condivisione dei file NFS, Linux utilizza il supporto a livello del kernel combinato con una serie di processi demoni in continua esecuzione; il supporto NFS deve essere abilitato nel kernel di Linux per poter funzionare. Per instradare le richieste tra client e server, NFS utilizza delle chiamate RPC (Remote Procedure Call); questo significa che il servizio portmap deve essere abilitato e attivato con runlevel corretti perché la comunicazione possa avere luogo. Lavorando con portmap, vari altri processi permettono l'avvio di una connessione NFS e ne garantiscono la corretta esecuzione. rpc.mountd — il processo in esecuzione che riceve la richiesta di montaggio da un client NFS ed esegue un controllo per vedere se corrisponde con un filesystem correntemente esportato.

rpc.nfsd — il processo che implementa la parte del servizio NFS relativa all'utente. Funziona con il kernel di Linux per soddisfare le richieste dinamiche dei client NFS, come per esempio l'aggiunta di thread del server.

rpc.lockd — un demone non più necessario per i kernel moderni. Attualmente, il blocco dei file NFS avviene per mezzo del kernel. Viene incluso nel pacchetto nfs-utils ad appannaggio degli utenti in possesso di kernel di vecchia generazione che non supportano questa funzionalità per default.

rpc.statd — implementa il protocollo RPC NSM (Network Status Monitor). Fornisce una notifica di riavvio quando un server NFS viene riavviato in seguito a una chiusura non regolare.

rpc.rquotad — un server RPC che fornisce informazioni relative alla quota utente per utenti remoti.


NFS

NFS e portmap

NFS si serve di chiamate di procedura remota (RPC)per poter funzionare; il comando portmap è necessario per mappare le richieste RPC ai servizi corretti. I processi RPC notificano al portmap quando si avviano, rivelando il numero di porta che stanno monitorando e quali numeri di programmi RPC che sono pronti a servire. Il sistema client poi contatta portmap sul server con un particolare numero di programma RPC. A questo punto, portmap reindirizza il client al numero di porta corretto perché possa comunicare con il servizio desiderato.

Dal momento che i servizi basati su RPC si affidano al portmap per effettuare tutte le connessioni con le richieste in ingresso dei client, è chiaro che portmap deve essere disponibile prima che i servizi di cui sopra siano avviati. Se, per qualche motivo, il servizio portmap si arresta in modo inaspettato, riavviate portmap insieme a tutti i servizi che erano in esecuzione quando l'avevate lanciato.

Il servizio portmap può essere usato con i file di accesso del TCP wrappers (/etc/hosts.allow e /etc/hosts.deny) per controllare quali sistemi remoti possono utilizzare i servizi RPC sulla vostra macchina.


NFS

Montaggio di un filesystem NFS

Per montare una directory condivisa NFS da un altro computer, digitate il comando mount:

# mount nfsserv.mlib.cnr.it:/misc/export /myarea/local

Avvertenza Nel computer locale deve esistere la directory mount point (/myarea/local

nell'esempio sopra citato).In questo comando nfsserv.mlib.cnr.it corrisponde al nome dell'host del fileserver

NFS, /misc/export è la directory che nfsserv sta esportando e /misc/local è la directory del computer locale dove si vuole montare il filesystem. Una volta eseguito il comando mount (e se avete le autorizzazioni appropriate dal server NFS nfsserv.mlib.cnr.it), potete digitare ls /misc/local per ottenere un elenco di file in /misc/export su nfsserv.mlib.cnr.it.

Montaggio di filesystem NFS con /etc/fstabPer montare una condivisione NFS da un altro computer potete anche aggiungere una

linea al file /etc/fstab. La linea deve riportare il nome dell'host del server NFS, la directory che viene esportata e la directory che deve contenere la condivisione NFS sul computer locale. Per modificare il file /etc/fstab dovete essere collegati come root.

Di seguito è riportata la sintassi generale per la linea in /etc/fstab: server:/usr/local/pub /pub nfs rsize=8192,wsize=8192,timeo=14,intrIl vostro computer client deve contenere il mount point /pub. Una volta aggiunta la

linea a /etc/fstab sul sistema client, digitate il comando mount /pub al prompt della shell e il mount point /pub sarà montato dal server.


NFS

Montaggio di filesystem NFS con autofs

Il terzo metodo di montaggio di una condivisione NFS prevede l'utilizzo di Autofs, che impiega il demone automount per gestire i mount point montandoli in modo dinamico.

Autofs consulta il file di configurazione della mappa master /etc/auto.master per determinare quali mount point sono definiti. Avvia quindi un processo di automontaggio con i parametri appropriati per ogni mount point. Ogni linea della mappa master definisce un mount point e un file di mappa separato che definisce i filesystem da montare sotto questo mount point. Per esempio, il file /etc/auto.misc definisce i mount point nella directory /misc; ciò viene definito nel file /etc/auto.master.

Ogni voce in auto.master ha tre campi. Il primo campo è il mount point. Il secondo campo indica la posizione del file di mappa e il terzo campo, opzionale, può contenere informazioni quali il valore di timeout.


NFS

Per esempio, per montare la directory /proj52 della macchina remota penguin.example.net sul mount point /misc/myproject della vostra macchina, aggiungete la riga seguente ad auto.master:

/misc /etc/auto.misc --timeout 60Aggiungete questa riga al file /etc/auto.misc: myproject -rw,soft,intr,rsize=8192,wsize=8192 penguin.example.net:/proj52Il primo campo contenuto in /etc/auto.misc indica il nome della sottodirectory /misc, che

viene creata in modo dinamico da automount. In realtà la directory non dovrebbe esistere sul computer client. Il secondo campo contiene opzioni di montaggio quali rw per accesso in lettura e scrittura. Il terzo campo è la posizione dell'NFS di esportazione e contiene il nome dell'host e la directory.

Nota Bene La directory /misc deve esistere nel filesystem locale, che non deve contenere

sottodirectory di /misc. Il servizio Autofs può essere avviato dal prompt della shell digitando i comandi

seguenti: # /sbin/service autofs restartPer visualizzare i mount point attivi, digitate il comando seguente al prompt della shell: # /sbin/service autofs statusSe modificate il file di configurazione /etc/auto.master mentre autofs è in esecuzione,

dovete dire ai demoni automount di ricaricare autofs digitando al prompt della shell il comando seguente:

# /sbin/service autofs reload


NFS

Avvio e arresto del server

Sul server che esporta i filesystem NFS deve essere in esecuzione il servizio nfs. Visualizzare lo stato del demone NFS con il comando seguente:

# /sbin/service nfs status

Avviare il demone NFS con il comando seguente:

# /sbin/service nfs start

Arrestare il demone NFS con il comando seguente:

# /sbin/service nfs stop

Per avviare il servizio nfs all'avvio, utilizzate il comando:

# /sbin/chkconfig --level 345 nfs on


SAMBA

Samba utilizza il protocollo SMB per la condivisione di file e di stampanti tramite una connessione di rete. I sistemi operativi che supportano questo protocollo sono Microsoft Windows (tramite il suo Network Neighborhood), OS/2 e Linux.

Perché usare Samba?Samba è utile se alla vostra rete sono collegate sia macchine Windows sia

Linux. Samba consente la condivisione di file e stampanti da parte di tutti i vari sistemi in rete. Se si desidera condividere file solo tra macchine Red Hat Linux, usare NFS. Se si desidera condividere stampanti solo tra macchine Red Hat Linux, non si avrà bisogno di usare Samba.


SAMBA

avvio e arresto del server

Sul server che stá condividendo le directory tramite Samba, deve essere eseguito il servizio smb.

Visualizzare la condizione del demone di Samba con il seguente comando:

# /sbin/service smb status

Avviare il server con il seguente comando:

# /sbin/service smb start

Fermare il demone con il seguente comando:

# /sbin/service smb stop

Per avviare il servizio smb al momento dell'avvio, usare il comando:

# /sbin/chkconfig --level 345 smb on


SSH Secure SHell

Protocollo SSH

SSH™ consente il collegamento in modalità remota. A differenza di FTP o telnet, SSH cripta la sessione di login, impedendo alle persone non autorizzate di raccogliere le password in chiaro.

SSH è progettato per sostituire applicazioni precedenti, meno sicure utilizzate per l'accesso a sistemi remoti come telnet o rsh. Un programma chiamato scp sostituisce i programmi meno recenti per copiare i file tra host, quali rcp. Dato che queste applicazioni non cifrano le password tra il client e il server, si consiglia di utilizzarle il meno possibile. Se usate dei metodi sicuri per collegarvi ad altri sistemi in remoto, correte meno rischi per la sicurezza del vostro sistema e del sistema a cui vi collegate.

Caratteristiche di SSH

SSH è un protocollo che consente di stabilire connessioni sicure tra due sistemi mediante un'architettura client server. Il protocollo SSH fornisce le seguenti misure di protezione: Dopo una connessione iniziale, il client verifica il collegamento allo stesso server durante sessioni successive. Il client trasmette le proprie informazioni di autenticazione al server usando una cifratura a 128 bit. Tutti i dati inviati e ricevuti durante la connessione vengono trasferiti utilizzando una cifratura a 128 bit. In questo modo è estremamente complesso decifrare e leggere le trasmissioni decifrate. Il client può utilizzare le applicazioni X11 avviate dal prompt della shell. Questa tecnica, chiamata X11 forwarding, fornisce un'interfaccia grafica e sicura.

Dato che il protocollo SSH cifra tutto ciò che invia e riceve, può essere usato per cifrare dei protocolli che altrimenti non sarebbero sicuri. Se usate il port forwarding, potete utilizzare un server SSH per cifrare protocolli non sicuri, come POP, aumentando la sicurezza dei dati e del sistema in generale.


SSH

Red Hat Linux include i pacchetti, OpenSSH generico (openssh), server OpenSSH (openssh-server) e client (openssh-clients). Per istruzioni sull'installazione di OpenSSH, consultate il capitolo OpenSSH della Red Hat Linux Customization Guide. I pacchetti OpenSSH richiedono l'installazione del pacchetto OpenSSL (openssl). OpenSSL installa numerose librerie per la cifratura che consentono a OpenSSH di fornire comunicazioni cifrate.

Molti programmi client e server possono utilizzare il protocollo SSH. Esistono varie versioni del client SSH per quasi tutti i maggiori sistemi operativi in uso.

Perché usare SSH?

Utenti con cattive intenzioni dispongono di un'ampia varietà di strumenti per interrompere, intercettare e reindirizzare il traffico di rete allo scopo di ottenere l'accesso al vostro sistema. In generale queste minacce possono essere raggruppate in due categorie:

Intercettazione delle comunicazioni tra due sistemi — in questo scenario un malintenzionato può trovarsi in qualche punto della rete tra le due entità in comunicazione ed eseguire una copia delle informazioni trasmesse tra i due sistemi, per conservarle o inviarle modificate al destinatario originale. Questo attacco può essere sventato attraverso l'utilizzo di una comune utility di rete per la rilevazione delle intrusioni, puó essere rappresentata da un pacchetto sniffer [1].


SSH

Imitazione di un host particolare — con questa strategia, il malintenzionato finge di essere il destinatario di un messaggio. Se la strategia funziona, il sistema dell'utente non si accorge dell'inganno.

Questo attacco può essere sventato attraverso tecniche note come DNS poisoning [2] o IPspoofing [3].

Entrambe le tecniche descritte sopra consentono l'intercettazione di informazioni potenzialmente importanti e, se l'intrusione avviene a scopi malvagi, i risultati possono essere disastrosi.

Se SSH è usato per i login con la shell remota e per la copia dei file, le minacce alla sicurezza si riducono notevolmente. Questo perché il server utilizza le firme digitali per verificare l'identità degli utenti. Inoltre, tutte le comunicazioni tra i sistemi client e server sono cifrate. I tentativi di assumere l'identità di uno dei due sistemi comunicanti non funzioneranno, poiché ogni pacchetto è cifrato con un codice conosciuto solo dai sistemi locali e remoti.

Note

X11 si riferisce al sistema di visualizzazione a finestre X11R6, generalmente conosciuto come X. Red Hat Linux comprende XFree86, un sistema X Window Open Source molto diffuso e basato su X11R6.

1.Il DNS poisoning si verifica quando un intruso ottiene l'accesso a un server DNS, indirizzando i sistemi client a un host duplicato con intenti dannosi.

2.L'IP spoofing si verifica quando un intruso invia pacchetti di rete che sembrano provenire da un

host fidato della rete.


SSH

File di configurazione OpenSSH

OpenSSH possiede due diversi tipi di file di configurazione, uno per i programmi client (ssh, scp e sftp) e l'altro per il demone del server (sshd). Le informazioni di configurazione SSH sono memorizzate nella directory /etc/ssh/:

moduli — contiene gruppi Diffie-Hellman usati per lo scambio delle chiavi. In sostanza, questo consente di creare un livello di trasporto sicuro. Quando le chiavi sono scambiate all'inizio di una sessione SSH, viene creato un valore segreto e condiviso che non può essere determinato da una singola parte e viene usato per fornire l'autenticazione dell'host.

ssh_config — il file di configurazione del client SSH. Viene sovrascritto se anche nella home directory dell'utente (~/.ssh/config) ne è presente uno.

sshd_config — il file di configurazione per il demone sshd. ssh_host_dsa_key — la chiave privata DSA utilizzata dal demone sshd. ssh_host_dsa_key.pub — la chiave pubblica DSA usata dal demone sshd. ssh_host_key — la chiave privata RSA usata dal demone sshd per la versione 1

del protocollo SSH. ssh_host_key.pub — la chiave pubblica RSA usata dal demone sshd per la

versione 1 del protocollo SSH. ssh_host_rsa_key — la chiave privata RSA usata dal demone sshd per la versione

2 del protocollo SSH. ssh_host_rsa_key.pub — la chiave pubblica RSA usata dal demone sshd per la

versione 2 del protocollo SSH.


SSH

Le informazioni di configurazione SSH specifiche per l'utente sono archiviate nella sua directory home all'interno di ~/.ssh/:

authorized_keys — il file che contiene un elenco delle chiavi pubbliche "autorizzate" per i server. Quando un client si collega ad un server, lo stesso autentica il client stesso controllando la propria chiave pubblica immagazzinata all'interno di questo file.

id_dsa — contiene l'identità di autenticazione DSA dell'utente. id_dsa.pub — la chiave DSA pubblica dell'utente. id_rsa — la chiave RSA pubblica usata da ssh per la versione 2 del protocollo SSH. id_rsa.pub — la chiave RSA pubblica usata da ssh per la versione 2 del protocollo

SSH. identity — la chiave RSA privata usata da ssh per la versione 1 del protocollo SSH. identity.pub — la chiave RSA pubblica usata da ssh per la versione 1 del protocollo

SSH. known_hosts — contiene le chiavi host DSA dei server a cui l'utente si collega

tramite SSH. Questo file è importante per garantire che il client SSH si colleghi al server SSH corretto.


SSH

Richiesta di SSH per le connessioni remote

Per rendere SSH davvero efficace nel proteggere le vostre connessioni di rete, è necessario smettere di utilizzare tutti i protocolli di connessione non sicuri, come Telnet. Se questo non avviene, una password protetta tramite SSH può essere individuata alla prima connessione via Telnet.

Alcuni servizi da disabilitare sono:

telnetrshftprloginvsftpd

Per disabilitare i metodi di connessione poco sicuri, utilizzate il comando chkconfig, il programma basato su ncurses ntsysv o l'applicazione grafica Strumento di configurazione dei servizi. Per utilizzare questi strumenti dovete collegarvi come root.


Strumento di configurazione dei servizi

Strumento di configurazione dei servizi

Strumento di configurazione dei servizi è un'applicazione grafica sviluppata da Red Hat per impostare i servizi SysV contenuti in /etc/rc.d/init.d che devono essere eseguiti durante l'avvio del sistema (per i runlevel 3, 4 e 5) e per stabilire quali servizi xinetd devono essere attivati. Quest'applicazione vi consente, inoltre, di avviare, arrestare e riavviare i servizi SysV e di riavviare xinetd.

Per avviare Strumento di configurazione dei servizi dal desktop, selezionate Pulsante del menu principale (sul Pannello) => Impostazioni del sistema => Servizi oppure digitate il comando redhat-config-services al prompt della shell (per esempio in un terminale XTerm o GNOME).


Sitografia

http://www.isc.org/products/BIND — La home page del progetto BIND. In questo sito potete trovare le informazioni relative alle versioni attuali e scaricare una versione PDF del BIND 9 Administrator Reference Manual.

http://www.redhat.com/mirrors/LDP/HOWTO/DNS-HOWTO.html — illustra l'uso di BIND come server dei nomi "caching" oppure la configurazione dei vari file zone che fungono da server dei nomi primari per un dominio.


Bibliografia

DNS and BIND di Paul Albitz e Cricket Liu; edito da O'Reilly & Associates — un famoso libro di riferimento che illustra le opzioni di configurazione di BIND, comuni e non, e suggerisce strategie per un server DNS sicuro.

The Concise Guide to DNS and BIND di Nicolai Langfeldt; edito da Que — approfondisce la connessione tra servizi di rete multipli e BIND, concentrandosi in modo particolare sugli argomenti tecnici "task-oriented".

Documents

UNIX: implementazione pratica servizi di base. Unix: servizi di base2 BIND Introduzione a DNS Quando gli host su di una rete, si collegano ad un'altra