15.2. File di configurazione dei Wrapper TCP
Per determinare se la macchina di un client é abilitata a collegarsi ad un servizio, i wrapper TCP si riferiscono ai seguenti file, i quali sono conosciuti come file di accesso degli host:
/etc/hosts.allow
/etc/hosts.deny
Quando la richiesta di un client viene ricevuta dal servizio TCP wrapped, viene seguita la seguente procedura:
Il servizio si riferisce a /etc/hosts.allow. — Il servizio TCP wrapped analizza sequenzialmente il file /etc/hosts.allow e applica la prima regola specificata per quel servizio. Se trova una regola corrispondente, la connessione verrá abilitata. Altrimanti sará intrapresa la fase due.
Il servizio si riferisce a /etc/hosts.deny. — Il servizio TCP wrapped analizza sequenzialmente il file /etc/hosts.deny. Se trova una regola corrispondente, rifiuterá la connessione. In caso contrario, verrá garantito l'accesso.
I seguenti punti sono molto importanti da considerare quando si usano i wrapper TCP per la protezione dei servizi di rete:
Dato che le regole d'accesso in hosts.allow sono applicate prima, esse hanno la precedenza rispetto alle regole specificate in hosts.deny. Tuttavia, se viene permesso l'accesso ad un servizio in hosts.allow, viene ignorato il rifiuto d'accesso allo stesso servizio in hosts.deny.
Dato che le regole in ogni file vengono lette dall'alto verso il basso, applicando la prima regola corrispondente data ad un servizio, l'ordine delle regole é molto importante.
Se nessuna regola per il servizio viene trovata in entrambi i file, oppure se i file non esistono, l'accesso al servizio viene garantito.
I servizi TCP wrapped non nascondono le regole dai file di accesso agli host, cosí qualsiasi cambiamento su hosts.allow o hosts.deny sará confermato immediatamente senza riavviare i servizi di rete.
15.2.1. Formattazione delle regole d'accesso
Il formato per /etc/hosts.allow e /etc/hosts.deny é identico. Le righe vuote o quelle che iniziano con il segno (#) vengono ignorate, e ogni regola deve essere sulla propria riga.
Ogni regola usa il seguente formato di base per controllare l'accesso ai servizi di rete:
<daemon list>: <client list> [: <option>: <option>: ...] |
<daemon list> — Un elenco separato dei nomi del processo (non i nomi del servizio) oppure ALL wildcard (vedere la Sezione 15.2.1.1). L'elenco del demone accetta anche gli operatori elencati in la Sezione 15.2.1.3 per permettere una maggiore flessibilitá.
<client list> — Un elenco separato degli hostname, degli indirizzi IP dell'host, pattern speciali (vedere la Sezione 15.2.1.2), oppure wildcard speciali (vedere la Sezione 15.2.1.1) il quale identifica gli host influenzati dalla regola. L'elenco dei client accetta anche gli operatori elencati in la Sezione 15.2.1.3 per permettere una maggiore flessibilitá.
<option> — Un'azione facoltativa o un elenco di azioni separato da una colonna effettuato quando la regola viene innescata. I campi di opzione supportano le espansioni (vedere la Sezione 15.2.3.4) e puó essere usato per lanciare i comandi della shell, permettere o rifiutare l'accesso, e alterare il comportamento di logging (vedere la Sezione 15.2.3).
La seguente regola é un esempio di accesso degli host
vsftpd : .example.com |
Questa regola indica ai wrapper TCP di controllare per collegamenti al demone FTP (vsftpd) da ogni host nel dominio example.com. Se questa regola appare in hosts.allow, la connessione verrá accettata. Se la regola appare in hosts.deny, la connessione sará rifiutata.
Il prossimo esempio di regola di accesso agli host é piú complesso e usa due campi di opzione:
sshd : .example.com \ : spawn /bin/echo `/bin/date` access denied>>/var/log/sshd.log \ : deny |
Notare in questo esempio che ogni campo di opzione é preceduto dal carattere (\). L'uso di questo carattere evita il fallimento della regola a causa della lunghezza.
 | Avvertenza | |
|---|---|---|
Se l'ultima riga di un file di accesso agli host non é un carattere di
una nuova riga (creato premendo il testo
|
Questo esempio afferma che se si tenta una connessione al demone SSH (sshd) da un host nel dominio example.com, eseguire il comando echo (il quale registrerá il tentativo su di un file speciale), rifiutando il collegamento. A causa dell'uso della direttiva deny, questa riga rifiuterá l'accesso anche se apparirá nel file hosts.allow. Per maggiori informazioni sulle opzioni disponibili, consultare la Sezione 15.2.3.
15.2.1.1. Wildcard
Le Wildcard permettono ai wrapper TCP di corrispondere facilmente con i gruppi di demoni o degli host. Esse sono usate molto frequentemente nel campo dell'elenco dei client delle regole di accesso.
Possono essere usate le seguenti wildcard:
ALL — Corrisponde con tutto. Puó essere usato sia per l'elenco dei demoni che per quella dei client.
LOCAL — Corrisponde a qualsiasi host che non contiene un periodo (.), come ad esempio l'host locale.
KNOWN — Corrisponde a qualsiasi host dove l'hostname e l'indirizzo host sono conosciuti o dove l'utente é conosciuto.
UNKNOWN — Corrisponde a ogni host dove l'hostname o l'indirizzo host sono sconosciuti o dove anche l'utente é sconosciuto.
PARANOID — Corrisponde a qualsiasi host dove l'hostname non corrisponde all'indirizzo dell'host.
 | Attenzione |
|---|---|
Le wildcard KNOWN, UNKNOWN, and PARANOID dovrebbero essere usate con attenzione in quanto una rottura nella risoluzione del nome puó compromettere l'ingresso ad un servizio ad un utente abilitato. |
15.2.1.2. Pattern
I Pattern possono essere usati nel campo dell'elenco del client delle regole di accesso, per poter meglio specificare i gruppi di host del client.
Di seguito viene riportata una lista dei pattern piú comuni accettati per una entry dell'elenco del client.
Hostname che iniziano con un periodo (.) — Posizionando un periodo all'inizio di un hostname, si corrisponde a tutti gli host che condividono i componenti del nome elencati. Il seguente esempio sará applicato per ogni host all'interno del dominio example.com:
ALL : .example.com
Indirizzo IP che termina con un periodo (.) — Posizionando un periodo alla fine di un indirizzo IP, si corrisponde a tutti gli host che condividono i gruppi numerici iniziali di un indirizzo IP. Il seguente esempio sará valido per tutti gli host all'interno della rete 192.168.x.x.
ALL : 192.168.
accoppiamento indirizzo IP/maschera di rete — Espressioni della maschera di rete possono essere usate come un pattern per controllare l'accesso a un gruppo particolare di indirizzi IP. Il seguente esempio sará valido per qualsiasi host con un indirizzo di 192.168.0.0 fino a 192.168.1.255:
ALL : 192.168.0.0/255.255.254.0
L'asterisco(*) — L'asterisco puó essere usato per corrispondere interi gruppi di hostname o di indirizzi IP, solo se non sono mischiati in un elenco del client contenente altri tipi di pattern. Il seguente esempio sará valido ad ogni host all'interno del dominio example.com:
ALL : *.example.com
La barra (/) — Se l'elenco di un client inizia con una barra, verrá trattato come un file name. Ció é utile se sono necessarie le regole che specificano numeri molto grandi di molto grandi di host. Il seguente esempio si riferisce ai wrapper TCP per il file /etc/telnet.hosts per tutti i collegamenti Telnet:
in.telnetd : /etc/telnet.hosts
Altri pattern meno usati sono accettati dai wrapper TCP. Consultare la pagina man 5 dell'accesso agli host per maggiori informazioni.
| Avvertenza |
|---|---|
Prestate molta attenzione quando create le regole che richiedono una risoluzione del nome, come ad esempio hostname ed i nomi del dominio. Gli hacker possono usare una varietá di trucchi per aggirare tale risoluzione. In aggiunta, ogni interruzione nel servizio DNS eviterebbe anche agli utenti autorizzati l'uso dei servizi di rete. É consigliabile usare indirizzi IP quando possibile. |
15.2.1.3. Operatori
Al momento le regole del controllo di accesso, accettano un operatore, EXCEPT. Puó essere usato nell'elenco del demone oppure nell'elenco del client, di una regola.
L'operatore EXCEPT abilita specifiche eccezioni a corrispondenze piú vaste all'interno della stessa regola.
Nel seguente esempio da un file hosts.allow, tutti gli host example.com sono abilitati a connettersi a tutti i servizi eccetto cracker.example.com:
ALL: .example.com EXCEPT cracker.example.com |
In un altro esempio da un file hosts.allow, i client dalla rete 192.168.0.x possono usare tutti i servizi eccetto per FTP:
ALL EXCEPT vsftpd: 192.168.0. |
 | Nota Bene |
|---|---|
É sempre meglio usare gli operatori EXCEPT moderatamente, posizionando le eccezioni su di una regola nell'altro file di controllo d'accesso. Questo permette ad altri amministratori di controllare velocemente i file appropriati per vedere quali host dovrebbero essere autorizzati e quali no per accedere ai servizi senza passare per i vari operatori EXCEPT. |
15.2.2. Portmap e Wrapper TCP
Quando si creano le regole per il controllo dell'accesso per portmap, non usare gli hostname in quanto l'implementazione di wrapper TCP non supporta l'host look up. Per questa ragione, usare solo gli indirizzi IP o le keyword ALL quando si specificano gli host in hosts.allow o hosts.deny.
In aggiunta, i cambiamenti apportati sulle regole di controllo dell'accesso portmap possono non avere un effetto immediato.
Servizi molto diffusi, come ad esempio NIS e NFS, per operare dipendono da portmap, per questo motivo fate attenzione a questi limiti.
15.2.3. Campi di opzione
In aggiunta alle regole di base sul rifiuto o sul permesso di accesso, l'implementazione Red Hat Linux dei wrapper TCP, supporta le estensioni all'accesso del controllo della lingua attraverso i campi di opzione. Usando i campi di opzione all'interno delle regole di accesso degli host, gli amministratori possono ottenere una varietá di compiti come ad esempio l'alterazione del comportamento di log, il consolidamento del controllo d'accesso, e il lancio dei comandi della shell.
15.2.3.1. Logging
I campi di opzione permettono all'amministratore di cambiare la funzione di registrazione ed il livello di prioritá per una regola, usando la direttiva severity.
Nel seguente esempio, i collegamenti al demone SSH, da un qualsiasi host nel dominio example.com sono registrati per la funzione di default authpriv (perché nessun valore é specificato) con una priority di emerg:
sshd : .example.com : severity emerg |
É possibile specificare una funzione usando l'opzione severity. Il seguente esempio registra qualsiasi host dal dominio example.com che cerca di connettersi al servizio SSH alla funzione local0 con una priority di alert:
sshd : .example.com : severity local0.alert |
| Nota Bene |
|---|---|
In pratica, questo esempio non funzionerá fino a quando il demone syslog (syslogd) é configurato per effettuare una registrazione su local0. Consultare la pagina man syslog.conf per informazioni inerenti la configurazione delle funzioni di registrazione personalizzate . |
15.2.3.2. Controllo d'accesso
I campi di opzione permettono agli amministratori di abilitare o negare gli host con una regola singola aggiungendo le direttive allow o deny come opzione finale.
Per esempio, le due regole seguenti abilitano dei collegamenti SSH da client-1.example.com, ma rifiutano i collegamenti da client-2.example.com:
sshd : client-1.example.com : allow sshd : client-2.example.com : deny |
Permettendo il controllo d'accesso in base alla regola, il campo di opzione permette agli amministratori di consolidare tutte le regole d'accesso in un file singolo: hosts.allow o hosts.deny. Alcuni lo considerano il modo piú facile per organizzare le regole d'accesso.
15.2.3.3. Comandi della Shell
I campi di opzione permettono alle regole d'accesso di lanciare i comandi della shell attraverso le seguenti due direttive:
spawn — Lancia un comando della shell come programma bambino. Questa opzione puó effettuare dei compiti come ad esempio usare /usr/sbin/safe_finger per ottenere piú informazioni inerenti il client richiedente, o creare file di registrazione speciali usando il comando echo.
Nel seguente esempio, i client che cercano di accedere ai servizi Telnet dal dominio example.com sono registrati su di un file speciale:
in.telnetd : .example.com \ : spawn /bin/echo `/bin/date` from %h>>/var/log/telnet.log \ : allow
twist — Sostituisce il servizio richiesto con il comando specificato. Questa direttiva viene usata spesso per impostare delle "trappole" per gli intrusi (chiamate anche "honey pots"). Esso puó essere usato per mandare messaggi ai client. Il comando twist deve essere presente alla fine della riga della regola.
Nel seguente esempio, ai client che tentano di accedere i servizi FTP dal dominio example.com viene inviato un messaggio tramite il comando echo:
vsftpd : .example.com \ : twist /bin/echo "421 Bad hacker, go away!"
Per maggiori informazioni inerenti le opzioni di comando della shell, consultare la pagina man hosts_options.
15.2.3.4. Espansioni
Le espansioni, quando usate insieme con le direttive spawn e twist forniscono informazioni inerenti il client, server e i processi coinvolti.
Di seguito viene riportata una lista delle espansioni supportate:
%a — L'indirizzo IP del client.
%A — L'indirizzo IP del server.
%c — Fornisce una varietá d'informazioni inerenti il client, come ad esempio il nome utente e l'hostname, oppure il nome utente e l'indirizzo IP.
%d — il nome del processo demone..
%h — L'hostname del client (o l'indirizzo IP se l'hostname non è disponibile).
%H — L'hostname del server (o l'indirizzo IP se l'hostname non è disponibile).
%n — L'hostname del client. Se non è disponibile, viene visualizzato unknown. Se l'hostname e l'indirizzo host del client non corrispondono, viene visualizzato paranoid.
%N — L'hostname del server. Se non è disponibile, viene visualizzato unknown. Se l'hostname e l'indirizzo host del server non corrispondono, compare, paranoid.
%p — l'ID del processo demone.
%s — Vari tipi di informazioni del server, quali il processo demone e l'indirizzo host o IP del server.
%u — L'hostname del client. Se non è disponibile, compare unknown.
Il seguente esempio usa una espensione insieme con il comando spawn per identificare l'host del client in un file di registrazione personalizzato.
Indica ai wrapper TCP che se si tenta una connessione al demone SSH da un host nel dominio (sshd) example.com, eseguire il comando echo per registrare il tentativo, incluso l'hostname del client (usando l'espansione %h), per un file speciale:
sshd : .example.com \ : spawn /bin/echo `/bin/date` access denied to %h>>/var/log/sshd.log \ : deny |
In modo similare, le espansioni possono essere usate per personalizzare i messaggi per il client. Nell'esempio seguente, , i client che cercano di accedere ai servizi FTP dal dominio example.com sono informati che essi sono stati esclusi dal server:
vsftpd : .example.com \ : twist /bin/echo "421 %h has been banned from this server!" |
Per una spiegazione completa della espansioni disponibili, e anche delle opzioni del controllo di accesso aggiuntive, rivedere la sezione 5 delle pagine man per hosts_access (man 5 hosts_access) e la pagina man per hosts_options.
Per risorse aggiuntive inerenti i wrapper TCP, consultare la Sezione 15.5.