Follow Techotopia on Twitter

On-line Guides
All Guides
eBook Store
iOS / Android
Linux for Beginners
Office Productivity
Linux Installation
Linux Security
Linux Utilities
Linux Virtualization
Linux Kernel
System/Network Admin
Programming
Scripting Languages
Development Tools
Web Development
GUI Toolkits/Desktop
Databases
Mail Systems
openSolaris
Eclipse Documentation
Techotopia.com
Virtuatopia.com
Answertopia.com

How To Guides
Virtualization
General System Admin
Linux Security
Linux Filesystems
Web Servers
Graphics & Desktop
PC Hardware
Windows
Problem Solutions
Privacy Policy

  




 

 

NOTE: CentOS Enterprise Linux is built from the Red Hat Enterprise Linux source code. Other than logo and name changes CentOS Enterprise Linux is compatible with the equivalent Red Hat version. This document applies equally to both Red Hat and CentOS Enterprise Linux.
Linuxtopia - CentOS Enterprise Linux Reference Guide - File di configurazione xinetd

17.4. File di configurazione xinetd

I file di configurazione per xinetd sono di seguito riportati:

  • /etc/xinetd.conf — Il file di configurazione xinetd globale.

  • /etc/xinetd.d/ — La directory che contiene tutti i file del servizio specifico.

17.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:

  • 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 opzioni dichiarate nei file di configurazione del servizio specifico, posizionato nella directory /etc/xinetd.d/. Consultate la Sezione 17.4.2 per maggiori informazioni.

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 17.4.3.1 per maggiori informazioni.

17.4.2. La directory /etc/xinetd.d/

La directory /etc/xinetd.d/ contiene i file di configurazione per ogni servizio gestito da xinetd ed i nomi dei file relativi al servizio. Come con xinetd.conf, questa directory viene letta 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 user ID verr� eseguito il processo.

  • server — Definisce il binario eseguibile da lanciare.

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

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

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.

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

ImportanteImportante
 

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.

 
 
  Published under the terms of the GNU General Public License Design by Interspire