I file di configurazione per xinetd sono di seguito riportati:
/etc/xinetd.conf — Il file di configurazione xinetd globale.
/etc/xinetd.d/ directory — La directory che contiene tutti i file del servizio specifico.
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:
instances — Imposta il numero massimo di richieste che xinetd puó far fronte contemporaneamente.
log_type — Configura xinetd in modo da usare la funzione di log authpriv, il quale scrive le entry di registrazione sul file /var/log/secure. Se si aggiungesse una direttiva come ad esempio FILE /var/log/xinetdlog viene creato un file di log personalizzato chiamato xinetdlog nella directory /var/log/.
log_on_success — Indica a xinetd cosa registrare se la connessione avviene correttamente. Per default, vengono registrati l'indirizzo IP dell'host remoto e l'ID del server che elabora la richiesta.
log_on_failure —indica a xinetd cosa registrare se la connessione fallisce o non è autorizzata.
cps — indica a xinetd di non abilitare più di 25 connessioni al secondo verso uno specifico servizio. Quando tale limite viene raggiuto, il servizio entra in pausa per 30 secondo.
includedir /etc/xinetd.d/ — Include le opzione dichiarate nei file di configurazione del servizio specifico, posizionato nella /etc/xinetd.d/. Consultate la Sezione 16.4.2 per maggiori informazioni.
![]() | Nota 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. |
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
service — Definisce il nome del servizio, generalmente usando un nome elencato nel file /etc/services.
flags — Imposta un numero di attributi per il collegamento. REUSE indica a xinetd di usare nuovamente il socket per un collegamento Telnet.
socket_type — Imposta il tipo di rete socket per stream.
wait — Definisce se il servizio é singolo "single-threaded" (yes) o multiplo "multi-threaded" (no).
user — Definisce con quale ID dell'utente verrá eseguito il processo.
server — Definisce il binario eseguibile per essere lanciato.
log_on_failure — Definisce i parametri di logging per log_on_failure in aggiunta a quelli giá definiti in xinetd.conf.
disable — Definisce se il server é attivo.
Vi é un grande assortimento di direttive disponibili per i servizi protetti xinetd. Questa sezione evidenzia alcune delle opzioni maggiormente usate.
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.
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.
![]() | Nota 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:
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.
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 dell'accesso dei wrapper TCP insieme con i controlli dell'accesso xinetd. Una configurazione errata puó causare degli effett indesiderati. |
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.
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.