17.4. File di configurazione xinetd

17.4.3.1. Opzioni di Logging

Le seguenti opzioni di logging sono disponibili per /etc/xinetd.conf e per i file di configurazione specifici del servizio nella directory /etc/xinetd.d/.

Di seguito � riportato un elenco di alcune delle opzioni di logging pi� comunemente usate:

• ATTEMPT — registra i tentativi falliti di accesso (log_on_failure).

• DURATION — registra il tempo di utilizzo di un servizio da parte di un sistema remoto (log_on_success).

• EXIT — registra il segnale di chiusura del servizio (log_on_success).

• HOST — registra l'indirizzo IP dell'host remoto (log_on_failure e log_on_success).

• PID — registra l'ID del server che riceve la richiesta (log_on_success).

• USERID — registra l'utente remoto usando il metodo definito in RFC 1413 per tutti i servizi stream multi-thread (log_on_failure e log_on_success).

Per un elenco completo delle opzioni di logging, consultare la pagina man xinetd.conf.

17.4.3.2. Opzioni di controllo dell'accesso

Gli utenti dei servizi xinetd possono scegliere di usare le regole di accesso host dei wrapper TCP, fornire il controllo di accesso tramite i file di configurazione xinetd, o un insieme dei due. Informazioni relative all'uso dei file di controllo dell'accesso host dei wrapper TCP sono riportate nella Sezione 17.2.

Questa sezione affronta l'uso di xinetd per controllare l'accesso ai servizi.

	Nota Bene
	A differenza dei wrapper TCP, le modifiche apportate al controllo dell'accesso verranno confermate se l'amministratore di xinetd riavvia il servizio xinetd. Inoltre, a differenza dei wrapper TCP, il controllo dell'accesso eseguito attraverso xinetd, influenzer� solo i servizi controllati da xinetd.

Il controllo dell'accesso fornito da xinetd differisce dal metodo usato dai wrapper TCP. Mentre i wrapper TCP raggruppano tutta la configurazione di accesso in due file, /etc/hosts.allow e /etc/hosts.deny, il controllo dell'accesso di xinetd viene trovato su ogni file di configurazione del servizio all'interno della directory/etc/xinetd.d/.

Le seguenti opzioni d'accesso host sono supportate da xinetd:

• only_from — Permette agli host specificati di usare il servizio.

• no_access — Impedisce a questi utenti di usare il servizio.

• access_times — specifica la fascia oraria in cui un particolare servizio pu� essere utilizzato. La fascia oraria deve essere specificata nel formato HH:MM-HH:MM e utilizzare le 24 ore della giornata.

Le opzioni only_from e no_access possono usare un elenco di indirizzi IP o di hostname, oppure � possibile specificare un'intera rete. Come per i wrapper TCP, se associate il controllo di accessoxinetd con una configurazione logging migliorata, potete aumentare la sicurezza, bloccando le richieste da host non autorizzati, registrando anche ogni tentativo effettuato.

Per esempio, il seguente file /etc/xinetd.d/telnet pu� bloccare l'accesso telnet da parte di uno specifico gruppo di rete e restringere la fascia oraria durante la quale anche gli utenti autorizzati possono collegarsi:

service telnet
{
        disable         = no
        flags           = REUSE
        socket_type     = stream
        wait            = no
        user            = root
        server          = /usr/sbin/in.telnetd
        log_on_failure  += USERID
        no_access       = 10.0.1.0/24
        log_on_success  += PID HOST EXIT
        access_times    = 09:45-16:15
}

In questo esempio, quando un sistema client dalla rete 10.0.1.0/24, come ad esempio 10.0.1.2, cerca di accedere al servizio Telnet, esso ricever� il seguente messaggio:

Connection closed by foreign host.

In aggiunta, il loro tentativo di login viene registrato in /var/log/secure:

May 15 17:38:49 boo xinetd[16252]: START: telnet pid=16256 from=10.0.1.2
May 15 17:38:49 boo xinetd[16256]: FAIL: telnet address from=10.0.1.2
May 15 17:38:49 boo xinetd[16252]: EXIT: telnet status=0 pid=16256

Quando si usano i wrapper TCP insieme ai controlli d'accesso xinetd, � importante capire il rapporto tra due meccanismi di controllo.

Di seguito viene riportato l'ordine delle operazioni seguite da xinetd quando un client richiede un collegamento:

1. Il demone xinetd accede alle regole dell'accesso host dei wrapper TCP attraverso una libreria libwrap.a. Se una regola di rifiuto "deny" corrisponde con il client host, la connessione viene passata su xinetd.

2. Il demone xinetd controlla le proprie regole di controllo dell'accesso sia per il servizio xinetd che per il servizio richiesto. Se una regola di rifiuto "deny" corrisponde con il client host, la connessione viene terminata. Altrimenti, xinetd avvia un esempio del servizio richiesto passando il controllo della connessione al servizio stesso.

	Importante
	Prestare attenzione quando si usano i controlli d'accesso dei wrapper TCP insieme con i controlli dell'accesso xinetd. Una configurazione errata pu� causare degli effett indesiderati.

17.4.3.3. Opzioni di collegamento e ridirezionamento

I file di configurazione dei servizi di xinetd supportano anche il collegamento dei servizi a particolari indirizzi IP e il ridirezionamento delle richieste in entrata ad altri indirizzi IP, nomi host o porte.

Il binding � controllato tramite l'opzione bind nei file di configurazione dei servizi, collega un servizio a un particolare indirizzo IP usato sul sistema. Una volta configurata, l'opzione bind permette l'accesso al servizio solo alle richieste che utilizzano tale indirizzo IP. In questo modo i servizi diversi possono essere inviati alle interfacce di rete in base all'esigenza.

Questo � particolarmente utile per sistemi con pi� adattatori di rete e indirizzi IP. Su tale sistema, i servizi non sicuri, come Telnet, possono essere configurati in solo ascolto sull'interfaccia collegata ad una rete privata e non con una interfaccia collegata con Internet.

L'opzione redirect, che accetta un indirizzo IP o un nome host seguito da un numero di porta, indica al servizio di ridirezionare tutte le richieste per il servizio verso la posizione specificata. Questa funzione pu� essere usata per puntare verso un altro numero di porta sullo stesso sistema, ridirezionare la richiesta verso altri indirizzi IP sulla stessa macchina, inviare la richiesta a un numero di porta e sistema completamente diverso oppure a una combinazione di queste opzioni. In questo modo, un utente che si collega a un servizio su un sistema pu� essere instradato verso un altro sistema senza causare problemi.

Il demone xinetd � in grado di compiere questo ridirezionamento creando un processo che rimane attivo durante la connessione tra la macchina client che svolge la richiesta e l'host che effettivamente fornisce il servizio e che trasferisce i dati fra i due sistemi.

La vera forza delle opzioni bind e redirect si nota quando queste vengono usate insieme. Collegando un servizio a un indirizzo IP su un sistema e ridirezionando successivamente la richiesta per il servizio a una seconda macchina che pu� essere vista solo dalla prima macchina, potete usare un sistema interno che fornisce servizi a una rete totalmente diversa. Altrimenti, le due opzioni possono essere usate per limitare l'esposizione di un servizio su una macchina multihome a un indirizzo IP conosciuto, e ridirigere tutte le richieste per il servizio verso un'altra macchina appositamente configurata.

Per esempio, esaminate un sistema usato come firewall i cui parametri per il servizio Telnet sono:

service telnet
{
        socket_type		= stream
        wait			= no
        server			= /usr/sbin/in.telnetd
        log_on_success		+= DURATION USERID
        log_on_failure		+= USERID
        bind                    = 123.123.123.123
        redirect                = 10.0.1.13 23
}

Le opzioni bind e redirect contenute in questo file assicurano che il servizio Telnet della macchina sia collegato all'indirizzo IP esterno (123.123.123.123), quello rivolto verso Internet. Inoltre, tutte le richieste per il servizio telnet inviate a 123.123.123.123 vengono ridirezionate tramite un altro adattatore di rete a un indirizzo IP interno (10.0.1.13) accessibile solo dal firewall e dai sistemi interni. Il firewall invia in seguito la comunicazione tra i due sistemi e il sistema in collegamento crede di essere collegato a 123.123.123.123 mentre in realt� � collegato a un'altra macchina.

Questa funzione � particolarmente utile per gli utenti con collegamenti veloci e un unico indirizzo IP fisso. Quando viene utilizzato il (NAT) Network Address Translation, i sistemi dietro la macchina gateway che utilizzano solo indirizzi IP interni, non sono disponibili all'esterno del sistema gateway. Tuttavia, quando alcuni servizi controllati da xinetd sono configurati con le opzioni bind e redirect, la macchina gateway pu� agire come un proxy fra i sistemi esterni e una macchina interna configurata per fornire il servizio. Inoltre, le varie opzioni di controllo dell'accesso e di loggin dixinetd sono disponibili per una protezione aggiuntiva.

17.4.3.4. Opzioni di amministrazione delle risorse

Il demone xinetd pu� aggiungere un livello basico di protezione per attacchi Denial of Service (DoS). Di seguito viene riportata una lista di direttive che possono aiutare a limitare gli effetti di tali attacchi:

• per_source — Definisce il numero massimo di istanze per un servizio per indirizzo IP della sorgente. Accetta solo numeri interi come argomento e pu� essere usato in xinetd.conf e nei file di configurazione del servizio specifico nella directory xinetd.d/.

• cps — Definisce il numero massimo di connessioni al secondo. Questa direttiva prende due argomenti separati da uno spazio bianco. Il primo � il numero massimo di connessioni permesse al sirvizio al secondo. Il secondo � il numero dei secondi che xinetd deve attendere prima di abilitare nuovamente il servizio. Accetta solo numeri interi come argomento e pu� essere usato in xinetd.conf e nei file di configurazione del servizio specifico nella directory xinetd.d/.

• max_load — Definisce l'uso del limite della CPU per un servizio. Accetta come argomento numeri 'floating point' con virgola mobile.

Ci sono altre opzioni di gestione delle risorse disponibili per xinetd. Consultate il capitolo intitolato Sicurezza del server nel Red Hat Enterprise Linux Security Guide per maggiori informazioni. Consultate altres� anche la pagina man xinetd.conf.