Capitolo 135. Organizzazione e controllo generale dei servizi di rete

I servizi di rete vengono attivati all'avvio di un sistema GNU comune, attraverso la procedura di inizializzazione del sistema (Init), dopo che sono stati assegnati gli indirizzi alle interfacce di rete e dopo che gli instradamenti sono stati definiti.

135.1 Avvio

I demoni in grado di fornire servizi di rete ricadono in due categorie possibili:

autonomi (standalone);
gestiti dal supervisore dei servizi di rete, noto anche come Internet service daemon.

Nel primo caso, si tratta di programmi avviati normalmente che si occupano si ascoltare su una certa porta e di provvedere da soli ai controlli necessari contro gli accessi indesiderati. Nel secondo, si tratta di programmi che vengono avviati nel momento in cui ne esiste effettivamente l'esigenza attraverso il supervisore dei servizi di rete, che è il programma che si occupa di ascoltare su tutte le porte dei servizi che controlla.

Il primo modo è preferibile quando non è possibile attendere l'avvio di un programma ogni volta che si presenta una richiesta: il caso tipico è dato dal sistema di condivisione dei file system in rete, o NFS.

La gestione da parte del supervisore dei servizi di rete permette di ridurre il carico del sistema, avviando solo i servizi necessari nel momento in cui ne viene fatta richiesta, introducendo un sistema di controllo ulteriore attraverso un altro programma: il TCP wrapper, ovvero il programma tcpd.

135.2 Supervisore dei servizi di rete BSD

Inetd, ⁽¹⁾ ovvero il supervisore dei servizi di rete BSD, è costituito dal demone inetd. La supervisione si articola in due parti:

è in grado di fornire alcuni servizi direttamente;
controlla l'avvio di altri servizi.

La presenza di questo meccanismo che si applica alla maggior parte dei servizi di rete (cioè tutti quelli che non sono autonomi) permette di inserire un ulteriore controllo attraverso il TCP wrapper, ovvero il programma tcpd, il quale si occupa prevalentemente di verificare che le richieste dei servizi provengano da indirizzi autorizzati.

inetd [opzioni] [file_di_configurazione]

Di solito, il demone viene avviato automaticamente dalla procedura di inizializzazione del sistema. Quando è in funzione, si mette in ascolto di un gruppo di porte determinato; quando rivela una comunicazione in una di queste, determina qual è il servizio corrispondente e lo avvia. In sostanza, questo demone demanda ad altri demoni la gestione dei servizi richiesti specificatamente.

La configurazione avviene attraverso il file /etc/inetd.conf; al suo interno sono indicati in particolare i demoni per la gestione di servizi di rete specifici. In molti casi, l'avvio di questi demoni è controllato anche da tcpd (che verrà descritto in seguito). Se si fanno modifiche a questo file e si vuole che abbiano effetto, è necessario inviare a inetd un segnale di aggancio, ovvero SIGHUP:

kill -HUP pid_di_inetd

Sotto viene mostrato il contenuto tipico di questo file, così come appare nelle distribuzioni GNU più comuni. La prima cosa da osservare è che il simbolo #, posto all'inizio di una riga, introduce un commento; inoltre, le righe bianche e quelle vuote vengono ignorate. Tutte le altre righe vengono interpretate come direttive di dichiarazione di un servizio particolare.

# Internal services
#echo    stream tcp nowait root         internal
#echo    dgram  udp wait   root         internal
#chargen stream tcp nowait root         internal
#chargen dgram  udp wait   root         internal
discard  stream tcp nowait root         internal
discard  dgram  udp wait   root         internal
daytime  stream tcp nowait root         internal
#daytime dgram  udp wait   root         internal
time     stream tcp nowait root         internal
#time    dgram  udp wait   root         internal

# Standard services.
#ftp     stream tcp nowait root         /usr/sbin/tcpd    /usr/sbin/in.ftpd
#telnet  stream tcp nowait root         /usr/sbin/tcpd    /usr/sbin/in.telnetd

# Shell, login, exec and talk are BSD protocols.
#shell   stream tcp nowait root         /usr/sbin/tcpd    /usr/sbin/in.rshd
#login   stream tcp nowait root         /usr/sbin/tcpd    /usr/sbin/in.rlogind
#exec    stream tcp nowait root         /usr/sbin/tcpd    /usr/sbin/in.rexecd

# Mail, news and uucp services.
smtp     stream tcp nowait mail         /usr/sbin/exim    exim -bs
pop-2    stream tcp nowait root         /usr/sbin/tcpd    /usr/sbin/ipop2d
pop-3    stream tcp nowait root         /usr/sbin/tcpd    /usr/sbin/ipop3d

# Info services
finger   stream tcp nowait nobody       /usr/sbin/tcpd    /usr/sbin/in.fingerd
ident    stream tcp wait   identd       /usr/sbin/identd  identd

# Other services
rsync    stream tcp nowait root         /usr/bin/rsync    rsyncd --daemon

Per l'utente medio di un sistema GNU non è necessario approfondire la sintassi di queste direttive. Il file di configurazione predefinito è già sufficiente così com'è.

Le direttive di questo file sono dei record, corrispondenti in pratica alle righe, suddivisi in campi distinti attraverso spaziature orizzontali (spazi o tabulazioni). L'ultimo campo può contenere anche spazi.

servizio[/versione] tipo_socket protocollo {wait|nowait}[.max] utente[.gruppo] _<-'
^`->programma_del_servizio programma_e_argomenti

servizio[/versione]

Il primo campo serve a indicare il servizio. Normalmente si fa riferimento a una porta indicata per nome, secondo quanto definito dal file /etc/services. Se si indica un numero, si fa riferimento direttamente a quel numero di porta.

Eventualmente può essere indicato un servizio RPC; in tal caso si utilizza un nome secondo quanto riportato nel file /etc/rpc, seguito eventualmente da un barra obliqua e dal numero di versione.
tipo_socket

Definisce il tipo di socket attraverso diverse parole chiave:
- stream
- dgram datagramma
- raw
- rdm reliably delivered message
- seqpacket sequenced packet socket
protocollo

Serve a determinare il tipo di protocollo, utilizzando una parola chiave che si ottiene dal file /etc/protocols. Si tratta prevalentemente di tcp e udp. Nel caso si vogliano gestire protocolli RPC, questi si indicano come rpc/tcp e rpc/udp.
{wait|nowait}[.max]

Le parole chiave wait e nowait servono a definire il comportamento di un servizio, quando si utilizza il tipo di socket dgram (datagramma). In tutti gli altri casi, si usa esclusivamente la parola chiave nowait.

In base alle richieste dei clienti, inetd può avviare un certo numero (anche elevato) di copie di processi di uno stesso servizio. Il limite predefinito è di 40 ogni minuto (ovvero ogni 60 secondi) e può essere modificato aggiungendo alla parola chiave wait o nowait un'estensione composta da un punto seguito da un numero: il numero massimo di copie per minuto.
utente[.gruppo]

Serve a definire l'utente ed eventualmente il gruppo in nome del quale avviare il servizio. inetd viene avviato dalla procedura di inizializzazione del sistema, con i privilegi dell'utente root; di conseguenza, può cambiare l'utente e il gruppo proprietari dei processi che avvia, in modo da dare loro i privilegi strettamente necessari al compimento delle loro funzioni.
programma_del_servizio

Definisce il percorso assoluto di avvio del programma che offre il servizio. Se si tratta di un servizio interno al supervisore dei servizi di rete stesso, si utilizza la parola chiave internal e l'ultimo campo non viene indicato.
programma_e_argomenti

L'ultimo campo è anomalo, in quanto consente l'utilizzo degli spazi come parte dell'informazione in esso contenuta: si tratta del nome del programma, senza percorso, seguito dagli argomenti eventuali con cui questo deve essere avviato. Si osservi l'esempio seguente, in cui ci si trova a dover ripetere il nome in.finger per questo motivo:
finger stream tcp nowait nobody /usr/sbin/in.fingerd in.fingerd

135.3 TCP wrapper

L'avvio di alcuni servizi può essere controllato utilmente da un sistema di registrazione e verifica, definito TCP wrapper. ⁽²⁾ Si tratta di un programma, o di una libreria da inserire in un programma che offre qualche tipo di servizio, che esegue una serie di controlli, in base ai quali decide se avviare o meno il servizio corrispondente.

Il TCP wrapper non è indispensabile, ma il suo utilizzo è diventato una consuetudine, per poter avere almeno un controllo minimo sui servizi principali.

I compiti del TCP wrapper possono essere:

annotare le connessioni nel registro di sistema;
filtrare l'accesso ai servizi in base a regole determinate;
eseguire delle verifiche contro possibili «imbrogli»;
utilizzare protocolli di identificazione dell'utente da cui ha origine la richiesta di accesso.

Come accennato, può trattarsi di un programma generalizzato, come nel caso del demone tcpd, oppure di una libreria che normalmente viene utilizzata dai programmi che funzionano in modo indipendente dal supervisore dei servizi di rete.

Qui viene mostrato solo l'uso elementare del TCP wrapper; tuttavia, si deve considerare che le funzionalità effettivamente disponibili dipendono anche dal modo in cui questo è stato compilato. Per un approfondimento delle sue potenzialità, si può consultare la documentazione originale: tcpd(8) e hosts_access(5); inoltre, nel capitolo 186 viene descritto come si può usare per realizzare delle «trappole».

La configurazione del TCP wrapper avviene attraverso la coppia di file /etc/hosts.allow e /etc/hosts.deny. Semplificando, quando il TCP wrapper viene interpellato a proposito di un tentativo di accesso, questo verifica che l'indirizzo del chiamante sia incluso nell'elenco di /etc/hosts.allow. Se è così non esegue altri controlli e permette l'accesso, altrimenti verifica che questo non sia incluso nell'elenco di /etc/hosts.deny (se entrambi i file mancano o sono vuoti, sono consentiti tutti gli accessi).

135.3.1 Dichiarazione all'interno di /etc/inetd.conf

La dichiarazione di un servizio all'interno del file /etc/inetd.conf (relativo a Inetd) può avvenire fondamentalmente in due modi possibili: con o senza il filtro del TCP wrapper. Si osservino i due esempi seguenti.

telnet  stream  tcp     nowait  root    /usr/sbin/in.telnetd    in.telnetd

telnet  stream  tcp     nowait  root    /usr/sbin/tcpd  in.telnetd

Nel primo caso, quando si instaura una connessione TELNET, il supervisore dei servizi di rete avvia direttamente il binario /usr/sbin/in.telnetd, senza altre intermediazioni. L'albero dei processi potrebbe apparire come nell'esempio seguente:

init-+-inetd---in.telnetd---login---bash---...
     |
     ...

Nel secondo caso, invece, un'eventuale connessione TELNET viene preceduta dalla verifica attraverso il TCP wrapper (in questo caso, costituito dal demone tcpd), che potrebbe anche rifiutarla, oppure semplicemente aggiungere dei controlli. Ma una volta completati i controlli, se il servente può essere avviato, il programma tcpd si toglie di mezzo, per cui l'albero dei processi appare esattamente uguale a quanto già visto.

Quando si decide di utilizzare il TCP wrapper, si possono presentare altre possibilità. Per la precisione, perché funzioni quanto visto nell'ultimo esempio, occorre che l'eseguibile in.telnetd si trovi nella directory prevista dal programma tcpd, secondo quanto definito in fase di compilazione dei sorgenti. In pratica, per un sistema GNU si tratta di /usr/sbin/.

Se il demone di un servizio determinato si trova in una collocazione differente rispetto a quella standard, questo potrebbe essere indicato utilizzando il percorso assoluto, come nell'esempio seguente:

telnet  stream  tcp     nowait  root    /usr/sbin/tcpd  /root/bin/in.telnetd

In questo caso, viene specificato che il demone necessario a ricevere le connessioni TELNET è precisamente /root/bin/in.telnetd.

Nella documentazione del TCP wrapper si mostra la possibilità di utilizzare questo programma solo a scopo di verifica dei tentativi di accesso, che vengono annotati nel registro del sistema, sostituendo il demone che dovrebbe essere avviato con una copia di tcpd stesso. Supponendo di volere eliminare il servizio Finger pur continuando a monitorare le richieste di questo, si potrebbe agire come segue:

# mkdir /directory/segreta

# mv /usr/sbin/in.fingerd /directory/segreta

# cp /usr/sbin/tcpd /usr/sbin/in.fingerd

In alternativa, si può ottenere un risultato simile semplicemente togliendo il programma demone del servizio, lasciando però la dichiarazione nel file /etc/inetd.conf. La differenza che si può avvertire sta nelle ulteriori segnalazioni di errore che si ritrovano nel registro del sistema, che avvisano dell'impossibilità di avviare il programma corrispondente.

135.3.2 Configurazione

Come già accennato, la configurazione del TCP wrapper avviene attraverso la coppia di file /etc/hosts.allow e /etc/hosts.deny, dove il primo serve a individuare accessi consentiti, mentre il secondo serve a definire accessi non consentiti.

I tentativi di accesso sono confrontati con le direttive contenute nel file /etc/hosts.allow, continuando eventualmente con quelle di /etc/hosts.deny. Se si ottiene una corrispondenza con una direttiva del file /etc/hosts.allow, l'accesso viene concesso, senza passare al controllo di /etc/hosts.deny; se non si ottiene alcuna corrispondenza con le direttive del file /etc/hosts.allow, si passa all'analisi di quelle contenute in /etc/hosts.deny e solo se nessuna corrisponde all'accesso in corso, questo viene consentito. Pertanto, se i file /etc/hosts.allow e /etc/hosts.deny sono vuoti, o mancano, sono consentiti tutti gli accessi.

In generale, le righe che iniziano con il simbolo # sono ignorate, in qualità di commenti; le righe bianche e quelle vuote sono ignorate ugualmente. Le direttive occupano normalmente una riga, a meno che terminino con il simbolo \ (subito prima del codice di interruzione di riga) che rappresenta una continuazione nella riga successiva.

La sintassi minima per le direttive di questi file dovrebbe corrisponde allo schema seguente:

elenco_di_demoni : elenco_di_clienti

Alla sinistra dei due punti si elencano i programmi demone il cui utilizzo si vuole concedere ai nodi elencati alla destra. Gli elementi appartenenti a un elenco possono essere separati con una virgola o uno spazio.

È consentito l'uso di speciali nomi jolly e altri simboli che facilitano l'indicazione di gruppi di nomi. Segue un elenco di elementi utilizzabili.

`.indirizzo_ipv4` `.nome_di_dominio`	L'indirizzo IPv4 di un nodo che inizia con un punto indica in realtà tutti gli indirizzi che finiscono con quel suffisso. Se si utilizzano nomi di dominio invece di indirizzi numerici, si fa riferimento a un intero dominio. Per esempio, `.brot.dg` rappresenta tutti i nodi del dominio `brot.dg`.
`indirizzo_ipv4.` `prefisso_nome_di_dominio.`	L'indirizzo di un nodo che finisce con un punto indica in realtà tutti gli indirizzi che iniziano con quel prefisso. Se si utilizzano indirizzi IPv4 numerici, si fa riferimento a una rete intera. Per esempio, `192.168.` rappresenta tutti i nodi della rete 192.168.0.0.
`@dominio_nis`	Il nome di un dominio NIS viene indicato con il prefisso `@` e rappresenta tutti i nodi che appartengono a tale dominio.
`indirizzo_ipv4/maschera_ipv4`	Rappresenta gli indirizzi IPv4 che si ottengono eseguendo l'AND tra indirizzo e maschera. Per esempio, 192.168.72.0/255.255.254.0 rappresenta tutti gli indirizzi a partire da 192.168.72.0 a 192.168.73.255.
`[indirizzo_ipv6]/n_bit_maschera`	Rappresenta un gruppo di indirizzi IPv6, secondo la maschera. Per esempio, `[fec0:0:0:1::]/64` rappresenta tutti gli indirizzi fec0:0000:0000:0001::.
`ALL`	È un jolly che rappresenta tutto. Se si trova alla sinistra dei due punti indica tutti i demoni dei servizi, se si trova alla destra rappresenta tutti i nodi.
`LOCAL`	È un jolly che indica tutti gli elaboratori locali, intendendosi con questo quelli rappresentabili senza alcun punto.
`UNKNOWN`	È un jolly che rappresenta tutti i nodi il cui nome o indirizzo risulta sconosciuto. Se si vuole usare questo modello, occorre considerare che i nodi potrebbero risultare sconosciuti anche a causa di un'interruzione temporanea del servizio DNS.
`KNOWN`	È un jolly che rappresenta tutti i nodi il cui nome o indirizzo risulta conosciuto. Se si vuole usare questo modello, occorre considerare che i nodi potrebbero risultare sconosciuti anche a causa di un'interruzione temporanea del servizio DNS.
`PARANOID`	È un jolly che corrisponde ai nodi il cui nome non corrisponde all'indirizzo. In pratica, si vuole che `tcpd`, attraverso il DNS, determini l'indirizzo in base al nome, quindi si vuole ancora che trasformi il nome in indirizzo (indirizzo --> nome --> indirizzo); se non c'è corrispondenza tra gli indirizzi ottenuti, il nodo rientra in questa categoria.
`EXCEPT`	È un operatore che può essere utilizzato all'interno di un elenco di nomi per escluderne i successivi.

Segue un elenco di esempi riferiti a direttive del file /etc/hosts.deny:

ALL : ALL	Consente l'utilizzo di qualsiasi servizio da parte di qualsiasi nodo.
ALL : ALL EXCEPT .mehl.dg	Consente l'utilizzo di qualsiasi servizio da parte di qualsiasi nodo a eccezione di quelli il cui dominio è `mehl.dg`.
ALL : .brot.dg	Consente l'utilizzo di qualsiasi servizio da parte dei nodi appartenenti al dominio `brot.dg`.
ALL : .brot.dg EXCEPT caino.brot.dg	Consente l'utilizzo di qualsiasi servizio da parte dei nodi appartenenti al dominio `brot.dg`, a esclusione di `caino.brot.dg`.
ALL : 192.168.	Consente l'utilizzo di qualsiasi servizio da parte dei nodi appartenenti alla sottorete 192.168.0.0.
in.fingerd : LOCAL ALL : ALL	L'ordine in cui appaiono le direttive è importante. In questo caso, le richieste per il servizio Finger (rappresentato dal demone `in.fingerd`), vengono accettate solo se provengono da indirizzi locali. Tutti gli altri servizi sono permessi da qualunque origine.

Per un controllo più facile degli accessi, conviene indicare all'interno del file /etc/hosts.deny soltanto ALL : ALL in modo da impedire tutti gli accessi che non siano consentiti esplicitamente da /etc/hosts.allow.

135.4 Supervisore dei servizi di rete Xinetd

Xinetd, ⁽³⁾ è un supervisore dei servizi di rete alternativo al classico Inetd, che può essere usato anche con IPv6⁽⁴⁾ e può interpretare direttamente i file /etc/hosts.allow e /etc/hosts.deny senza bisogno di un programma esterno, in quanto incorpora le librerie del TCP wrapper.

Xinetd è costituito in pratica dall'eseguibile xinetd, che può essere avviato o meno con l'indicazione di opzioni:

xinetd [opzioni]

Naturalmente, di solito il demone xinetd viene avviato e fermato attraverso il controllo dalla procedura di inizializzazione del sistema, senza bisogno di un intervento umano diretto per la sua gestione.

Le funzionalità offerte da Xinetd dipendono dal modo in cui viene compilato. Si possono conoscere le caratteristiche di Xinetd utilizzando l'opzione -version:

# xinetd -version

Ciò che si ottiene è naturalmente il numero della versione del programma, con l'elenco delle componenti addizionali inserite. L'esempio seguente indica l'inclusione delle librerie utili all'utilizzo dei file /etc/hosts.allow e /etc/hosts.deny:

xinetd Version 2.3.3 libwrap

L'esempio seguente mostra invece l'inclusione di tutte le funzionalità più importanti:

xinetd Version 2.3.4 ipv6 libwrap loadavg

Se appare anche la stringa ipv6, si tratta di una versione compilata per IPv6.

135.4.1 Configurazione

La configurazione principale di Xinetd è contenuta solitamente nel file /etc/xinetd.conf che ha una struttura differente rispetto alla configurazione di Inetd.

Xinetd rilegge il file di configurazione con un segnale differente rispetto al solito aggancio, ma in generale, se il controllo di Xinetd è inserito correttamente nella gestione della procedura di inizializzazione di sistema, dovrebbe essere disponibile uno script adatto, con una sintassi simile a quella seguente, dove l'argomento reload è quello che garantisce la rilettura della configurazione:

xinetd {start|stop|reload}

Nel file di configurazione sono ignorate le righe vuote, quelle bianche e quelle che iniziano con il simbolo #; per il resto si tratta di direttive nella forma:

service nome_servizio { attributo =|+=|-= valore... ... }

In altri termini, si tratta di sezioni corrispondenti al nome del servizio a cui fanno riferimento, contenenti una serie di assegnamenti ad attributi individuati da parole chiave particolari. In generale, solo alcuni attributi consentono l'uso di assegnamenti del tipo += e -=, per aggiungere o togliere qualcosa all'attributo stesso. L'esempio seguente rappresenta una situazione abbastanza comune per il contenuto di questo file:

defaults
{
        log_type       = SYSLOG daemon
        log_on_success = PID HOST USERID EXIT DURATION
        log_on_failure = HOST USERID ATTEMPT DURATION
}

service discard
{
        socket_type     = stream
        protocol        = tcp
        wait            = no
        user            = root
        type            = INTERNAL
        id              = discard-stream
}

service discard
{
        socket_type     = dgram
        protocol        = udp
        wait            = yes
        user            = root
        type            = INTERNAL
        id              = discard-dgram
}

service daytime
{
        socket_type     = stream
        protocol        = tcp
        wait            = no
        user            = root
        type            = INTERNAL
        id              = daytime-stream
}

service time
{
        socket_type     = stream
        protocol        = tcp
        wait            = no
        user            = root
        type            = INTERNAL
        id              = time-stream
}

service telnet
{
        socket_type     = stream
        protocol        = tcp
        wait            = no
        user            = root
        server          = /usr/sbin/in.telnetd
}

service smtp
{
        socket_type     = stream
        protocol        = tcp
        wait            = no
        user            = mail
        server          = /usr/sbin/exim
        server_args     = -bs
}

service pop-2
{
        socket_type     = stream
        protocol        = tcp
        wait            = no
        user            = root
        server          = /usr/sbin/ipop2d
}

service pop-3
{
        socket_type     = stream
        protocol        = tcp
        wait            = no
        user            = root
        server          = /usr/sbin/ipop3d
}

service finger
{
        socket_type     = stream
        protocol        = tcp
        wait            = no
        user            = nobody
        server          = /usr/sbin/in.fingerd
}

service ident
{
        socket_type     = stream
        protocol        = tcp
        wait            = yes
        user            = identd
        server          = /usr/sbin/identd
}

service rsync
{
        socket_type     = stream
        protocol        = tcp
        wait            = no
        user            = root
        server          = /usr/bin/rsync
        server_args     = --daemon
}

Nell'elenco seguente, vengono descritti solo alcuni degli attributi utilizzabili.

`id = nome`	Consente di attribuire un nome alla sezione, quando lo stesso servizio appare in più di una sezione, con protocolli differenti. In mancanza di questa indicazione, il nome del protocollo è anche il nome usato per l'identificazione della sezione. Si osservi che se si usano i file `/etc/hosts.allow` e `/etc/hosts.deny`, se si fa riferimento al protocollo, in intende in realtà questo nome identificativo.
`type = RPC\|INTERNAL`_<-' ^`->`\|UNLISTED`	Si attribuisce a questo attributo una parola chiave: `RPC`, quando si tratta di un servizio RPC; `INTERNAL`, quando si tratta di un servizio interno di Xinetd; `UNLISTED`, quando si tratta di un servizio che non appare all'interno di `/etc/services` o `/etc/rpc`.
`disable = yes\|no`	Consente di abilitare, assegnando la parola chiave `no`, o di disabilitare il servizio, con la parola chiave `yes`
`socket_type = stream\|dgram`_<-' ^`->`\|raw\|seqpacket`	Definisce il tipo di socket, attraverso una tra le parole chiave indicate.
`protocol = protocollo`	Definisce il tipo di protocollo, individuato da un nome come dal file `/etc/protocols`.
`wait = yes\|no`	Se si abilita questo attributo con `yes`, si intende che il servizio non consente l'avvio di più processi paralleli; pertanto, viene concesso solo un servizio alla volta. Al contrario, con un valore `no`, il servizio può essere fornito in più copie simultaneamente.
`user = utente`	Consente di avviare il processo che si occupa del servizio con i privilegi dell'utente indicato (ammesso che Xinetd sia in funzione con i privilegi dell'utente `root`).
`group = gruppo`	Consente di avviare il processo che si occupa del servizio con i privilegi del gruppo indicato (ammesso che Xinetd sia in funzione con i privilegi dell'utente `root`).
`nice = n`	Consente di attribuire un valore nice al processo corrispondente al servizio (un valore positivo, fino a 19, dà al processo meno risorse in termini di potenza elaborativa).
`server_args = argomenti`	Consente di indicare gli argomenti da dare al programma avviato in corrispondenza del servizio di rete.
`only_from = indirizzi_di_origine...`	Consente di indicare degli indirizzi di origine a cui è consentito l'accesso, attraverso varie forme, come indicato da xinetd.conf(5).
`no_access = indirizzi_di_origine...`	Consente di indicare degli indirizzi di origine a cui non è consentito l'accesso, secondo le stesse modalità di `only_from`. Nel caso entrambi gli attributi possano fare riferimento allo stesso indirizzo, viene preso in considerazione quello più selettivo; per esempio, potrebbe essere consentito a tutta una sottorete di accedere, ma si potrebbe escludere precisamente un nodo della sottorete.
`access_time = intervallo...`	Consente di indicare gli intervalli di tempo in cui il servizio risulta accessibile. Gli intervalli hanno la forma: `ore:minuti-ore:minuti`.
`log_type = FILE file_delle_registrazioni`	Fa in modo che le informazioni vengano fatte nel file indicato.
`log_type = SYSLOG tipo [livello]`	Fa in modo che le informazioni vengano fatte nel registro del sistema, specificando il tipo ed eventualmente il livello. Il tipo può essere una parola chiave tra: `daemon`, `auth`, `authpriv`, `user`, `local0`, `local1`, `local2`, `local3`, `local4`, `local5`, `local6`, `local7`. Il livello può essere indicato come: `emerg`, `alert`, `crit`, `err`, `warning`, `notice`, `info`, `debug`.
`log_on_success = PID\|HOST`_<-' ^`->`\|USERID\|EXIT\|DURATION ...`	Annota le informazioni identificate dalle parole chiave utilizzate quando un accesso avviene con successo.
`log_on_failure = HOST`_<-' ^`->`\|USERID\|ATTEMPT ...`	Annota le informazioni identificate dalle parole chiave utilizzate quando un accesso avviene con successo. Si possono assegnare anche altri valori, come descritto in xinetd.conf(5).

Esiste anche la possibilità di definire una sezione contenente attributi predefiniti per tutte le altre sezioni:

default { attributo =|+=|-= valore... ... }

In questo modo, attributi come only_from possono essere gestiti più facilmente per tutti i servizi.

135.4.2 IPv6

Xinetd si comporta in modo differente quando compilato con la gestione di IPv6; la cosa più importante da osservare è che gli indirizzi IPv4 vengono poi gestiti sempre come indirizzi IPv6 ricavati da IPv4, ovvero IPv4-mapped IPv6 addresses. Pertanto, quando si vuole fare riferimento a indirizzi IPv4, si deve usare la forma seguente:

::ffff:indirizzo_ipv4_normale

Per esempio, per fare riferimento all'indirizzo 127.0.0.1, si indicherà invece ::ffff:127.0.0.1.

1) Inetd UCB BSD

2) TCP wrapper software libero con licenza speciale

3) Xinetd software libero con licenza speciale

4) Il funzionamento con IPv6 dipende dal modo in cui vengono compilati i sorgenti; pertanto, possono esistere edizioni precompilate di Xinetd che non sono in grado di gestire IPv6.