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:
Riferimenti /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.
Riferimenti /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.
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.
![]() | Avvertenza | |
---|---|---|
Se l'ultima riga di un file di accesso agli host non é un carattere di una nuova riga (creato premendo il testo
|
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 16.2.1.1). L'elenco del demone accetta anche gli operatori elencati in la Sezione 16.2.1.4 per permettere una maggiore flessibilitá.
<client list> — Un elenco, separato da una virgola, degli hostname, degli indirizzi IP dell'host, pattern speciali (vedere la Sezione 16.2.1.2), oppure wildcard speciali (vedere la Sezione 16.2.1.1) il quale identifica gli host influenzati dalla regola. L'elenco del client accetta anche gli operatori riportati in la Sezione 16.2.1.4 per permettere una maggiore flessibilitá.
<option> — Un'azione facoltativa o un elenco di azioni separato da due punti effettuate quando la regola viene innescata. I campi di opzione supportano le estensioni (vedere la Sezione 16.2.2.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 16.2.2).
La seguente regola é un esempio di accesso degli host
vsftpd : .example.com |
Questa regola indica ai wrapper TCP di cercare i 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.
Questo esempio afferma che se si cerca di effettuare un collegamento 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), e negare 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 16.2.2.
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. |
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 punto (.) — Posizionando un punto 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 punto (.) — Posizionando un punto 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. |
indirizzo IP/maschera di rete — Espressioni della maschera di rete possono essere usate come modello 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 |
![]() | Importante |
---|---|
Quando si lavora nello spazio dell'indirizzo IPv4, la lunghezza della coppia indirizzo/prefisso (prefixlen) non è supportata. Solo le regole IPv6 possono usare questo formato. |
coppia [IPv6 address]/prefixlen — Le coppie [net]/prefixlen possono essere usate come modello per controllare l'accesso a un gruppo particolare di indirizzi IP. Il seguente esempio sará valido per qualsiasi host con un indirizzo di 3ffe:505:2:1:: fino a 3ffe:505:2:1:ffff:ffff:ffff:ffff:
ALL : [3ffe:505:2:1::]/64 |
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 modelli meno usati sono accettati dai wrapper TCP. Consultare la pagina man 5 hosts_access per maggiori informazioni.
![]() | Avvertenza |
---|---|
Prestate molta attenzione quando usate gli hostname e i nomi del dominio.Gli aggressori possono usare una varietá di trucchi per aggirare un'accurata risoluzione del nome. In aggiunta, ogni interruzione nel servizio DNS eviterebbe anche agli utenti autorizzati l'uso dei servizi di rete. Pertanto è meglio usare indirizzi IP quando possibile. |
Quando si creano le regole per il controllo dell'accesso per portmap, non usare gli hostname come implementazione portmap dei wrapper TCP 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 alle regole di controllo per l'accesso aportmap possono non avere un effetto immediato se non si riavvia il servizio portmap.
Servizi molto diffusi, come ad esempio NIS e NFS, per operare dipendono da portmap, per questo motivo fate attenzione a questi limiti.
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 |
---|---|
Amministrativamente, è sempre meglio evitare di usare gli operatori EXCEPT. Questo permette ad altri amministratori di controllare velocemente i file appropriati per vedere quali host dovrebbero essere autorizzati e quali no, ad accedere i servizi senza passare per i vari operatori EXCEPT. |
In aggiunta alle regole di base sul rifiuto o sul permesso all'accesso, l'implementazione Red Hat Enterprise Linux dei wrapper TCP, supporta le estensioni per la lingua di controllo per l'accesso 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.
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 per il demone SSH, da un qualsiasi host nel dominio example.com sono registrati per la funzione di default authpriv syslog (perché nessun valore é specificato) con una priorità 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 funziona fino a quando il demone syslog (syslogd) é configurato per effettuare un log per la facility local0. Consultare la pagina man syslog.conf per informazioni inerenti la configurazione delle facility log personalizzate. |
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.
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 opzioni_host.
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 estensioni supportate:
%a — Fornisce l'indirizzo IP del client.
%A — Fornisce 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 — Fornisce il nome del processo del demone..
%h — Fornisce l'hostname del client (o l'indirizzo IP se l'hostname non è disponibile).
%H — Fornisce l'hostname del server (o l'indirizzo IP se l'hostname non è disponibile).
%n — Fornisce l'hostname del client. Se non è disponibile, viene visualizzato unknown. Se l'hostname del client e l'indirizzo host non corrispondono, viene visualizzato paranoid.
%N — Fornisce l'hostname del server. Se non è disponibile, viene visualizzato unknown. Se l'hostname del server e l'indirizzo host non corrispondono, compare, paranoid.
%p — Fornisce l'ID del processo demone.
%s — Fornisce vari tipi di informazioni del server, quali il processo demone e l'indirizzo host o IP del server.
%u — Fornisce l'username del client. Se non è disponibile, viene visualizzato unknown.
Il seguente esempio usa una espensione insieme con il comando spawn per identificare l'host del client in un file di registrazione personalizzato.
Quando si cerca di effettuare un collegamento al demone SSH (sshd), da un host nel dominio example.com, eseguire il comando echo per registrare il tentativo, includendo 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 delle estensioni disponibili, e anche delle opzioni aggiuntive del controllo di accesso, consultare la sezione 5 delle pagine man per hosts_access (man 5 hosts_access) e la pagina man per hosts_options.
Per informazioni aggiuntive sui wrapper TCP, consultare la Sezione 16.5. Per informazioni aggiuntive su come rendere sicuri i wrapper TCP, consultare il capitolo intitolato Sicurezza del server nel Red Hat Enterprise Linux Security Guide.