16.4. File di configurazione xinetd

I file di configurazione per xinetd sono di seguito riportati:

16.4.1. Il file /etc/xinetd.conf

Il file /etc/xinetd.conf contiene le impostazioni di configurazione generali che influenzano ogni servizio sotto il controllo di xinetd. Viene letto una volta quando il servizio xinetd viene avviato, cosí per poter confermare i cambiamenti riguardanti la configurazione, l'amministratore deve riavviare il servizio xinetd. Di seguito viene riportato un esempio del file /etc/xinetd.conf:

defaults
{
        instances               = 60
        log_type                = SYSLOG authpriv
        log_on_success          = HOST PID
        log_on_failure          = HOST
        cps                     = 25 30
}
includedir /etc/xinetd.d

Queste righe controllano i seguenti aspetti di xinetd:

NotaNota Bene
 

Spesso le impostazioni log_on_success e log_on_failure in /etc/xinetd.conf sono maggiormente modificate nei file di registrazione specifici del servizio. Per questa ragione, piú informazioni possono apparire in una registrazione di un servizio rispetto alle informazioni date dal file /etc/xinetd.conf.Consultare la Sezione 16.4.3.1 per maggiori informazioni inerenti le opzioni di logging.

16.4.2. La directory /etc/xinetd.d/

I file nella directory /etc/xinetd.d/ contengono i file di configurazione per ogni servizio gestito da xinetd e i nomi dei file relativi al servizio. Come con xinetd.conf, questo file viene letto solo quando il servizio xinetd é avviato. Per confermare qualsiasi cambiamento, l'amministratore deve riavviare il servizio xinetd.

Il formato dei file nella directory /etc/xinetd.d/ usa le stesse convenzioni di /etc/xinetd.conf. La ragione principale per la quale la configurazione di ogni servizio viene conservata in file separati, é quella di permettere una personalizzazione piú facile con minore probabilitá di condizionare altri servizi.

Per avere una idea di come questi file sono strutturati, considerate il file /etc/xinetd.d/telnet:

service telnet
{
        flags           = REUSE
        socket_type     = stream
        wait            = no
        user            = root
        server          = /usr/sbin/in.telnetd
        log_on_failure  += USERID
        disable         = yes
}

Queste righe controllano vari aspetti del servizio vsftpd

16.4.3. Alterazione dei file di configurazione xinetd

Vi é un grande assortimento di direttive disponibili per i servizi protetti xinetd. Questa sezione evidenzia alcune delle opzioni maggiormente usate.

16.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.

16.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 deiwrapper TCP sono riportate in la Sezione 16.2.

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

NotaNota Bene
 

A differenza dei wrapper TCP, le modifiche apportate al controllo dell'accesso verranno confermate se l'amministratore di xinetd riavviati il servizio xinetd.

Inoltre, a differenza dei wrapper TCP, il controllo dell'accesso effettuato 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, 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 dell'accesso.

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.

ImportanteImportante
 

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

16.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 collegamento, controllato tramite l'opzione bind nei file di configurazione dei servizi, collega un servizio a un particolare indirizzo IP usato con il sistema. Una volta configurata, l'opzione bind permette l'accesso al servizio solo alle richieste che utilizzano tale indirizzo IP. In questo modo servizi diversi possono essere inviati alle interfaccie di rete in base all'esigenza.

Questo è particolarmente utile per sistemi con con più adattatori di rete e indirizzi IP. Su tali 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 broadband e un unico indirizzo IP fisso. Quando viene utilizzato il (NAT) Network Address Translation, i sistemi dietro alla 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.

16.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 fonte "source". 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 threshold del CPU per un servizio. Accetta come argomento numeri "floating point" con virgola mobile.

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