Capitolo 186. TCP wrapper più in dettaglio

L'uso del TCP wrapper (il programma tcpd) è già stato descritto in modo sommario nel capitolo 135. In quella fase sono state trascurate le sue potenzialià di controllo, che possono estendersi fino all'utilizzo del protocollo IDENT.

La configurazione del TCP wrapper avviene esclusivamente attraverso i file /etc/hosts.allow e /etc/hosts.deny, all'interno dei quali si possono utilizzare direttive più complesse di quelle già viste in precedenza. In ogni caso, è bene ribadire che lo scopo di questi file è quello di trovare una corrispondenza con l'utente e il nodo che tenta di accedere a uno dei servizi messi sotto il controllo del supervisore dei servizi di rete e di altri servizi che incorporano il TCP wrapper attraverso delle librerie. La verifica inizia dal file /etc/hosts.allow e continua con /etc/hosts.deny, fermandosi alla prima corrispondenza corretta. Se la corrispondenza avviene con una direttiva del file /etc/hosts.allow, l'accesso è consentito; se la corrispondenza avviene con una direttiva di /etc/hosts.deny, l'accesso è impedito; se non avviene alcuna corrispondenza l'accesso è consentito.

186.1 Limiti e particolarità del TCP wrapper

In generale, le connessioni RPC non si riescono a controllare facilmente con il TCP wrapper. In particolare, i servizi annotati come RPC-TCP nel file di configurazione del supervisore dei servizi di rete non sono gestibili attraverso il programma tcpd.

Alcuni demoni UDP e RPC rimangono attivi al termine del loro lavoro, in attesa di un'ulteriore richiesta eventuale. Questi servizi sono registrati nel file /etc/inetd.conf con l'opzione wait e così si possono riconoscere facilmente. Come si può intuire, solo la richiesta che li avvia può essere controllata da tcpd.

Alcuni dettagli di funzionamento di tcpd sono definiti in fase di compilazione dei sorgenti. Si tratta in particolare dell'opzione di compilazione -DPARANOID, con la quale è come se fosse sempre attivo il jolly PARANOID nei file /etc/hosts.allow e /etc/hosts.deny. Di solito, i pacchetti già compilati del TCP wrapper sono stati ottenuti senza questa opzione, in modo da lasciare la libertà di configurarlo come si vuole.

Un altro elemento che può essere definito con la compilazione è il tipo di direttive che si possono accettare nei file /etc/hosts.allow e /etc/hosts.deny. Le due sintassi possibili sono descritte in due documenti separati: hosts_access(5) e hosts_options(5).

186.2 Configurazione del TCP wrapper

In questa sezione viene mostrata in particolare la sintassi dei file /etc/hosts.allow e /etc/hosts.deny, quando nella fase di compilazione di tcpd non è stata abilitata l'estensione PROCESS_OPTIONS; in pratica quella più limitata. Negli esempi si mostreranno anche le corrispondenze con il secondo tipo di formato, che può essere approfondito leggendo hosts_options(5).

elenco_di_demoni : elenco_di_clienti [ : comando_di_shell ]

La sintassi mostrata, che si riferisce al tipo più semplice di formato delle direttive di questi file, potrebbe essere trasformata in quello più complesso nel modo seguente:

elenco_di_demoni : elenco_di_clienti [ : spawn comando_di_shell ]

Quando non si sa quale sia il formato giusto per il proprio tcpd, basta provare prima quello più semplice. Se non va bene si vede subito la segnalazione di errore nel registro del sistema.

I primi due elementi, l'elenco di demoni e l'elenco di clienti, sono già stati descritti nel capitolo 135. Vale forse la pena di ricordare che questi «elenchi» sono semplicemente nomi o modelli separati da spazi orizzontali, cosa che spiega la necessità di separare i vari campi delle direttive attraverso i due punti verticali.

Ciò che appare a partire dal terzo campo di queste direttive (nel caso mostrato si tratta di un comando di shell, ma con la sintassi più complessa si parla piuttosto di opzioni), può contenere delle variabili, rappresentate da un simbolo di percentuale (%) seguito da una lettera, che vengono espanse da tcpd ogni volta che viene verificata la corrispondenza con quella direttiva determinata che le contiene (tabella 186.1).

Tabella 186.1. Elenco delle variabili utilizzabili in alcune parti delle direttive dei file di controllo degli accessi.

Variabile	Contenuto
%a	L'indirizzo del nodo cliente.
%A	L'indirizzo del nodo servente.
%c	L'informazione completa del nodo cliente per quanto disponibile.
%d	Il nome del processo del demone.
%h	Il nome del nodo cliente o l'indirizzo se il nome non è disponibile.
%H	Il nome del nodo servente o l'indirizzo se il nome non è disponibile.
%n	Il nome del nodo cliente o `unknown` o `paranoid`.
%N	Il nome del nodo servente o `unknown` o `paranoid`.
%p	Il numero del processo del demone.
%s	Informazione completa del nodo servente per quanto disponibile.
%u	Il nome dell'utente del nodo cliente o `unknown`.
%%	Un simbolo di percentuale singolo.

Una direttiva può contenere il simbolo di due punti (:) all'interno di certi campi. In tal caso, per evitare che questi si confondano con la separazione dei campi, occorre precedere tale simbolo con la barra obliqua inversa: \:.

Una direttiva può essere interrotta e ripresa nella riga successiva se alla fine della riga appare una barra obliqua inversa, subito prima del codice di interruzione di riga.

Ogni volta che si modifica uno di questi file, è indispensabile verificare che nel registro di sistema non appaiano indicazioni di errori di sintassi. Un problema tipico che si incontra è dovuto al fatto che ogni direttiva deve terminare con un codice di interruzione di riga. Se alla fine di una direttiva terminasse anche il file, questo costituirebbe un errore che ne impedirebbe il riconoscimento.

186.2.1 Demoni e clienti specificati in modo più preciso

I primi due campi delle direttive di questi file, permettono di indicare con più precisione sia i demoni che i clienti che accedono.

Quando il servente ha diversi indirizzi IP con cui può essere raggiunto, è possibile indicare nel primo campo un demone in combinazione con un indirizzo particolare dal quale proviene la richiesta. In pratica, il primo campo diventa un elenco di elementi del tipo seguente:

demone@modello_servente

Il demone può essere indicato per nome, oppure può essere messo al suo posto il jolly ALL che li rappresenta tutti.

Il modello del servente serve a rappresentare questi indirizzi per nome o per numero. Valgono anche in questo caso le regole con cui si possono definire i nomi e gli indirizzi di clienti, anche per quanto riguarda le indicazioni parziali (un intero dominio o un gruppo di indirizzi).

Più interessante è invece la possibilità di ottenere dal TCP wrapper la verifica del nominativo-utente del processo avviato dal cliente per la connessione. Si veda per questo, quanto già descritto in precedenza al riguardo del protocollo IDENT. Basta utilizzare nel secondo campo la sintassi seguente:

modello_utente@modello_cliente

Utilizzando questa forma, tcpd, prima di concedere l'accesso al servizio, interpella il cliente attraverso il protocollo IDENT, per ottenere il nome dell'utente proprietario del processo che ha instaurato la connessione.

Se il cliente non risponde a questo protocollo, si crea una pausa di ritardo di circa 10 s. Implicitamente si penalizzano tutti gli utenti che usano sistemi operativi diversi da Unix e derivati.

Una volta ottenuta la risposta, o quando scade il tempo, può essere fatto il confronto con la direttiva. In ogni caso, questo tipo di direttiva fa sì che venga aggiunta questa informazione nel registro del sistema.

Il modello dell'utente può essere un nome puro e semplice, oppure un jolly: ALL, KNOWN e UNKNOWN. Il significato è intuitivo: tutti gli utenti; solo gli utenti conosciuti; solo gli utenti sconosciuti.

Il modello del cliente è quello già visto in precedenza: nomi interi; nomi parziali che iniziano con un punto; indirizzi IP interi; indirizzi IP parziali che terminano con un punto; jolly vari.

È bene ribadire che l'informazione sull'utente restituita dal protocollo IDENT, non è affidabile. Un sistema compromesso potrebbe essere stato modificato in modo da restituire informazioni false.

186.2.2 Comandi di shell

Il terzo campo delle direttive di questi file, permette di inserire un comando di shell. Quando un accesso trova corrispondenza con una direttiva contenente un comando di shell, questo comando viene eseguito; mentre l'accesso viene consentito se la corrispondenza avviene all'interno del file /etc/hosts.allow.

Il comando può contenere le variabili descritte nella tabella 186.1, che sono utili per dare un senso a questi comandi.

Il comando viene eseguito utilizzando l'interprete /bin/sh, connettendo standard input, standard output e standard error al dispositivo /dev/null. Generalmente, alla fine del comando viene indicato il simbolo &, in modo da metterlo sullo sfondo, per evitare di dover attendere la sua conclusione.

Questi comandi non possono fare affidamento sulla variabile di ambiente PATH per l'avvio degli eseguibili, per cui si usando generalmente percorsi assoluti, a meno che questa variabile sia inizializzata esplicitamente all'interno del comando stesso.

186.2.3 Esempi e trappole

Seguono alcuni esempi che dovrebbero chiarire meglio l'uso delle direttive dei file /etc/hosts.allow e /etc/hosts.deny.

In tutti gli esempi mostrati si suppone che il file /etc/hosts.deny contenga solo la direttiva ALL:ALL, in modo da escludere ogni accesso che non sia stato previsto espressamente nel file /etc/hosts.allow.

# /etc/hosts.allow
#
ALL : ALL@ALL

Supponendo che questa sia l'unica direttiva del file /etc/hosts.allow, si intende che vengono consentiti esplicitamente tutti gli accessi a tutti i servizi. Tuttavia, avendo utilizzato la forma ALL@ALL nel secondo campo, si attiva il controllo dell'identità dell'utente del cliente, ottenendone l'annotazione del registro del sistema.

# /etc/hosts.allow
#
ALL : KNOWN@ALL

La direttiva combacia solo con accessi in cui gli utenti siano identificabili.

# /etc/hosts.allow
#...
in.telnetd : ALL : ( /usr/sbin/safe_finger -l @%h  (segue)
  | /bin/mail -s '%d-%u@%h' root ) &

Si tratta di una trappola con cui l'amministratore vuole essere avvisato di ogni tentativo di utilizzo del servizio TELNET. Il comando avvia safe_finger (una versione speciale di Finger che accompagna il TCP wrapper) in modo da conoscere tutti i dati possibili sugli utenti connessi alla macchina cliente, inviando il risultato al comando mail per spedirlo a root.

Molto probabilmente, l'amministratore che prepara questa trappola, farà in modo che il demone in.telnetd non sia disponibile, in modo tale che la connessione venga comunque rifiutata.

Se fosse stato necessario utilizzare l'altro tipo di formato per le direttive di questi file, l'esempio appena mostrato sarebbe il seguente: si aggiunge la parola chiave spawn che identifica l'opzione corrispondente.

# /etc/hosts.allow
#...
in.telnetd : ALL : spawn ( /usr/sbin/safe_finger -l @%h  (segue)
  | /bin/mail -s '%d-%u@%h' root ) &

L'esempio seguente mostra un tipo di trappola meno tempestivo, in cui ci si limita ad aggiungere un'annotazione particolare nel registro del sistema per facilitare le ricerche successive attraverso grep.

in.telnetd : ALL@ALL : ( /usr/bin/logger TRAPPOLA\: %d %c ) &
in.rshd    : ALL@ALL : ( /usr/bin/logger TRAPPOLA\: %d %c ) &
in.rlogind : ALL@ALL : ( /usr/bin/logger TRAPPOLA\: %d %c ) &
in.rexecd  : ALL@ALL : ( /usr/bin/logger TRAPPOLA\: %d %c ) &
ipop2d     : ALL@ALL : ( /usr/bin/logger TRAPPOLA\: %d %c ) &
ipop3d     : ALL@ALL : ( /usr/bin/logger TRAPPOLA\: %d %c ) &
imapd      : ALL@ALL : ( /usr/bin/logger TRAPPOLA\: %d %c ) &
in.fingerd : ALL@ALL : ( /usr/bin/logger TRAPPOLA\: %d %c ) &

Se necessario occorre aggiungere la parola chiave spawn:

in.telnetd : ALL@ALL : spawn ( /usr/bin/logger TRAPPOLA\: %d %c ) &
in.rshd    : ALL@ALL : spawn ( /usr/bin/logger TRAPPOLA\: %d %c ) &
in.rlogind : ALL@ALL : spawn ( /usr/bin/logger TRAPPOLA\: %d %c ) &
in.rexecd  : ALL@ALL : spawn ( /usr/bin/logger TRAPPOLA\: %d %c ) &
ipop2d     : ALL@ALL : spawn ( /usr/bin/logger TRAPPOLA\: %d %c ) &
ipop3d     : ALL@ALL : spawn ( /usr/bin/logger TRAPPOLA\: %d %c ) &
imapd      : ALL@ALL : spawn ( /usr/bin/logger TRAPPOLA\: %d %c ) &
in.fingerd : ALL@ALL : spawn ( /usr/bin/logger TRAPPOLA\: %d %c ) &

Trattandosi di servizi che non si vogliono offrire (altrimenti non ci sarebbe ragione di registrare tanto bene gli accessi), anche in questo caso è opportuno che i demoni corrispondenti non ci siano, oppure che i rispettivi eseguibili siano sostituiti da una copia dello stesso programma tcpd.

Si osservi in particolare che all'interno del comando appare il simbolo di due punti protetto da una barra obliqua. Se non si facesse così, potrebbe essere interpretato come l'inizio di un nuovo campo.

186.2.4 Comandi e servizi UDP

I servizi UDP non si prestano tanto per la creazione di trappole, a causa del fatto che non si instaura una connessione come nel caso del protocollo TCP. Il caso più importante di questo problema è rappresentato dal servizio TFTP, che di solito, nel caso il supervisore dei servizi di rete sia Inetd, viene indicato nel file /etc/inetd.conf nel modo seguente:

tftp    dgram   udp     wait    root    /usr/sbin/tcpd  in.tftpd

Se si creasse una direttiva come quella seguente,

# /etc/hosts.allow
#...
in.tftpd : ALL : ( /usr/sbin/safe_finger -l @%h  (segue)
  | /bin/mail -s '%d-%u@%h' root ) &

si rischierebbe di avviare il comando di shell un gran numero di volte. Si può limitare questo problema modificando la riga contenuta nel file /etc/inetd.conf nel modo seguente:

tftp    dgram   udp     wait.2  root    /usr/sbin/tcpd  in.tftpd

In tal modo, si accetterebbero un massimo di due tentativi al minuto.

In generale, dovendo realizzare delle trappole per servizi UDP, conviene eliminare del tutto il demone dal file system.

186.3 Verifica della configurazione

tcpdchk ⁽¹⁾ permette di controllare la configurazione del TCP wrapper, indicando problemi possibili ed eventualmente anche dei suggerimenti per la loro sistemazione.

tcpdchk [opzioni]

tcpdchk analizza i file /etc/inetd.conf, /etc/hosts.allow e /etc/hosts.deny. Tra i vari tipi di verifiche che vengono eseguite, ci sono anche i nomi utilizzati per i nodi e i domini NIS. In tal senso, per avere un controllo più preciso, è opportuno utilizzare tcpdchk anche quando il sistema viene collegato in rete, avendo accesso alla configurazione reale del DNS e del NIS.

Opzione	Descrizione
`-d`	Esamina i file `./hosts.allow` e `./hosts.deny`, cioè quelli che si trovano nella directory corrente.
`-i file_inetd`	Specifica il file da utilizzare al posto di `/etc/inetd.conf`.

186.4 Verifica delle corrispondenze

tcpdmatch ⁽²⁾ permette di verificare il comportamento della configurazione simulando delle richieste. In pratica, verifica il contenuto di /etc/inetd.conf, /etc/hosts.allow e /etc/hosts.deny, mostrando quello che succederebbe con una richiesta di connessione determinata.

tcpdmatch [opzioni] demone[@servente] [utente@]cliente

È obbligatoria l'indicazione di un demone, con l'eventuale aggiunta dell'indicazione del servente quando si possono distinguere per questo degli indirizzi diversi; inoltre è obbligatoria l'indicazione del cliente, con l'eventuale aggiunta dell'utente.

Nell'indicazione del servente si possono usare anche i jolly UNKNOWN e PARANOID; il valore predefinito, se questa indicazione manca, è UNKNOWN.

L'utente può essere indicato per nome o per numero UID; anche in questo caso si ammette il jolly UNKNOWN, che è il valore predefinito in mancanza di questa indicazione.

Opzione	Descrizione
`-d`	Esamina i file `./hosts.allow` e `./hosts.deny`, cioè quelli che si trovano nella directory corrente.
`-i file_inetd`	Specifica il file da utilizzare al posto di `/etc/inetd.conf`.

Segue la descrizione di alcuni esempi.

# tcpdmatch in.telnetd localhost

Verifica il comportamento della configurazione per una richiesta di accesso al servizio TELNET, corrispondente al demone in.telnetd, da parte del nodo localhost.
# tcpdmatch in.telnetd tizio@roggen.brot.dg

Verifica il comportamento della configurazione per una richiesta di accesso al servizio TELNET, corrispondente al demone in.telnetd, da parte dell'utente tizio dal nodo roggen.brot.dg.
# tcpdmatch in.telnetd@dinkel.brot.dg tizio@roggen.brot.dg

Verifica il comportamento della configurazione per una richiesta di accesso al servizio TELNET, corrispondente al demone in.telnetd, proveniente dall'interfaccia corrispondente al nome dinkel.brot.dg, da parte dell'utente tizio dal nodo roggen.brot.dg.

186.5 Un Finger speciale

safe_finger ⁽³⁾ è un cliente Finger che, da quanto indicato nella documentazione originale, dovrebbe essere più adatto per la creazione di trappole attraverso i comandi di shell.

Le sue funzionalità sono le stesse del comando finger normale e non viene indicato altro nella documentazione originale.

186.6 Verifica della propria identificazione

try-from ⁽⁴⁾ permette di verificare il funzionamento del sistema di identificazione del servente e del cliente. Si utilizza nel modo seguente:

rsh host /usr/sbin/try-from

Di solito, questo programma si utilizza per verificare il proprio sistema. Per fare un esempio, si immagina di essere l'utente caio che dal nodo dinkel.brot.dg si connette al suo stesso elaboratore per avviare try-from.

$ rsh dinkel.brot.dg /usr/sbin/try-from[Invio]

client address  (%a): 192.168.1.1
client hostname (%n): dinkel.brot.dg
client username (%u): caio
client info     (%c): caio@dinkel.brot.dg
server address  (%A): 192.168.1.1
server hostname (%N): dinkel.brot.dg
server process  (%d): try-from
server info     (%s): try-from@dinkel.brot.dg

Dal risultato che si ottiene, si può determinare che anche il servizio IDENT dell'elaboratore dinkel.brot.dg (visto come cliente) funziona correttamente.

1) TCP wrapper software libero con licenza speciale

2) TCP wrapper software libero con licenza speciale

3) TCP wrapper software libero con licenza speciale

4) TCP wrapper software libero con licenza speciale