No TCP Wrapper? Ahiahiahiahi!!!

Articoli

No TCP wrapper? Haihaihai !!
Una maniera semplice ed efficace per rendere più sicuro il vostro sistema Unix

Introduzione
Dove trovare il software
Come funziona e come configurarlo
Alcuni esempi
Programmi di utilità e letture consigliate

Introduzione

Tutti i computer collegati ad Internet sono ben lontani dall'essere sistemi sicuri: basti pensare che un hacker di una qualsiasi città del mondo può, grazie ad Internet, accedere al vostro computer.
Lasciare il vostro sistema completamente sguarnito può rivelarsi davvero catastrofico: infatti un hacker che riuscisse a penetrarvi potrebbe cancellare tutto il vostro lavoro, o peggio (cosa può esserci di peggio ? Semplice: per esempio può installare dei programmi che intercettano tutta la vostra posta e quella dei vostri utenti... e voi non vi accorgereste di nulla! ).
Ma non esiste solo l'accesso in telnet: esistono anche tanti altri servizi, di cui magari non sospettate l'esistenza, che possono fornire ad un aggressore delle informazioni utili per penetrare nel vostro sistema.
Un esempio? Sapete che in certi sistemi (come il mio RedHat 4.0 subito dopo l'installazione) dando il comando telnet localhost systat mi veniva fuori la lista dei processi??? E con

telnet localhost
netstat

tira fuori lo stato della rete, compresa una lista delle connessioni attive??? E questo senza dover dare username e password!!
Se voglio un sistema sicuro ho due strade: una è disattivare tutti i servizi pericolosi, ma.....vogliamo veramente fare a meno del telnet, per esempio ? No ? Beh, allora non ci resta che la seconda strada: il TCP Wrapper,detto anche tcpd.
L'idea alla base è semplice: quando arriva una richiesta per un servizio (telnet, ftp, finger, etc.) non la soddisfiamo subito, ma andiamo a guardarci delle tabelline che ci dicono chi ha il permesso di accedere a che cosa, una cosa di questo tipo. Alla mia rete bianco.com, l'accesso in telnet è permesso solo alla rete bianco.com, finger dalla rete bianco.com e rosso.com, l'ftp è permesso da bianco.com e verde.com e così via.

Naturalmente queste considerazioni si applicano più a sistemi connessi ad Internet 24 ore su 24 che al nostro PC di casa, col quale ci colleghiamo ad Internet un'oretta al giorno; è infatti poco verosimile, anche se non impossibile, che un hacker penetri nel vostro sistema nell'oretta in cui voi accedete ad internet da casa con accesso dialup.

Dove trovare il software

Facile-facile. Sui sistemi Linux è di serie. C'è già, compilato ed installato: più facile di così...

Non succede altrettanto con altri sistemi Unix, in ogni caso lo potete trovare qua, direttamente dalla fonte, il Sig. Venema dell'Università di Eindhoven,Olanda:

ftp://ftp.win.tue.nl/pub/security/tcp_wrapper_XXX.tar.gz

dove XXX è l'ultima versione disponibile.

Come funziona e come configurarlo

I file importanti per tcpwrapper sono 3:

/etc/inetd.conf /etc/hosts.allow /etc/hosts.deny

Consiglio caldamente di dare una bella occhiata a /etc/inetd.conf: per chi non lo sapesse è il file di configurazione dell'Internet superd-daemon, cioè del demone che gestisce quasi tutti i servizi Internet del vostro sistema.
Per vedere il vostro, cliccate qui.
Una attenta occhiata (e magari un po' di man pages) ci riveleranno quali servizi il nostro sistema fornisce al resto del mondo. Ecco un esempio:


#
# These are standard services.
#
ftp     stream  tcp     nowait  root    /usr/sbin/tcpd  in.ftpd -l -a
telnet  stream  tcp     nowait  root    /usr/sbin/tcpd  in.telnetd
gopher  stream  tcp     nowait  root    /usr/sbin/tcpd  gn

questo brandello di inetd.conf ci rivela che sono forniti i servizi di ftp, telnet e gopher, e che sono gestiti rispettivamente dal programma in.ftpd, in.telnetd e gn *MA* attraverso /usr/sbin/tcpd: il tcp wrapper. La sequenza di connessione è questa: arriva una richiesta, lancio il tcpd (wrapper) che, se le regole di autorizzazione lo permettono, avvia il demone appropriato. Semplice ed efficace.

Annotiamoci tutti i nomi dei servizi (in.telnetd, etc.) perché ci serviranno in seguito, per wrapparli. Se nel vostro inetd.conf non avete /usr/sbin/tcpd significa che non avete il wrapper, oppure lo avete ma il sistema non è configurato per usarlo.
La riga di configurazione per un servizio non wrappato è per esempio:


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

Cioè appena arriva una richiesta, si lancia il demone senza alcun controllo.
Se avete modificato la configurazione di inetd, ricordatevi di dare


kill -1 1

per fargliela rileggere.

Ora che conosciamo tutti i servizi forniti dal nostro sistema, è l'ora di decidere una policy. La policy è la strategia di difesa: dobbiamo decidere quali servizi lasciare attivi e quali eventualmente disattivare del tutto, e per quelli che lasciamo attivi decidere quali macchine vi potranno accedere e a che condizioni. Possiamo anche decidere di tenere un log delle attività permesse e/o negate. Per esempio possiamo decidere di loggare tutti i telnet effettuati da un certo dominio, oppure farci mandare una mail se qualcuno fallisce il collegamento in telnet da una certa macchina, dove noi sappiamo che lavora sempre un tipo che noi sappiamo avere la fama di piantagrane; insomma, dobbiamo guardarci intorno e dire: da dove può arrivare il pericolo ???
Si consiglia un approccio un po' più prudente: lasciate attivi solo i servizi che vi servono veramente. Badate inoltre che permettere l'accesso da domini tipo .vol.it o .iol.it e via dicendo, permetteranno di entrare non solo a voi ma anche a tutti gli abbonati di Video On Line e Italia On Line..... in tal caso consiglio di guardare l'ip della sottorete del provider della vostra città; in questo modo potranno accedere al sistema solo gli abbonati per esempio a VOL che chiamano dalla vostra stessa città.

Una volta che avete deciso la vostra policy, si tratta di tradurla in un formato comprensibile dalla macchina: i files /etc/hosts.allow e /etc/hosts.deny. Cliccate sul nome del file per leggere i vostri.
hosts.allow dice quali servizi sono concessi, hosts.deny dice quali invece sono negati. Ogni riga contiene una regola del tipo:


lista_servizi  : lista_client [ : opzioni [: opzioni ]]

Il TCP wrapper si comporta così quando arriva una richiesta:

SE  la richiesta soddisfa una o più regole di /etc/hosts.allow
     l'accesso è accordato 
ALTRIMENTI
     SE la richiesta soddisfa una o più regole di /etc/hosts.deny
          l'accesso è negato
     ALTRIMENTI
          l'accesso è accordato

In genere i sistemi Linux vengono forniti con hosts.allow e hosts.deny vuoti, o per essere più precisi, solamente con righe di commento. Secondo l'algoritmo riportato sopra, l'accesso viene sempre accordato.
Vale la pena di spendere altre due parole sulla policy: possiamo decidere di permettere solo quello che è concesso da hosts.allow e negare tutto il resto. Per esempio, permettere telnet, ftp e finger da bianco.com e negare tutto il resto: /ect/hosts.allow sarà

in.telnetd, in.ftpd, in.fingerd: .bianco.com

e /etc/hosts.deny

ALL : ALL

ALL è una parola speciale, qua ALL:ALL significa "tutti i servizi" : "tutti gli host", così siamo sicuri di non lasciare buchi.
Notare il punto che precede bianco.com: indica un subdomain da autorizzare, anzichè un singolo host.

Un'altra policy è quella di negare esplicitamente, e permettere tutto quello che non è esplicitamente negato. Per esempio vogliamo negare solo l'accesso in telnet dalla macchina cattivo.rosso.com: /etc/hosts.allow non conterrà regole, /etc/hosts.deny avrà la regola:

in.telnetd : cattivo.rosso.com

CAVEAT: se in hosts.allow e hosts.deny mettete gli hostname, sappiate che se il vostro DNS non funziona, le regole potrebbero non essere eseguite correttamente. Inoltre, se un hacker prende il controllo del vostro DNS può fingersi una macchina da voi autorizzata sulla base dell'hostname, per cui si consiglia di mettere i numeri IP anzichè gli host/domain name. Userò comunque gli hostname per semplicità, ma è meglio mettere per esempio 194.116.2. anziché la forma letterale.

Le opzioni da specificare dopo l'host, permettono invece di fare tante cose utili come:

eseguire un comando quando viene negato/concesso un servizio (spawn shell_command , oppure twist shell_command; il primo lancia un processo in parallelo, l'altro si sostituisce a tcpd e può essere usato per lanciare un server diverso da quello di inetd.conf)
mostrare un banner personalizzato (banner directory , dove in directory si suppone ci siano i file testo contenenti i banner, col nome del servizio: in.telnetd per telnet, etc.)
cercare di ottenere lo username di chi cerca di accedere (rfc931 [timeout in secondi] usa il protocollo identd per cercare di scoprire, al massimo entro timeout secondi, lo username di chi cerca di collegarsi)
specificare i privilegi di tcpd (il suo username e il suo group, con user username[.groupname])
dirgli di verificare periodicamente che il client sia ancora attivo (keepalive)
cambiare la priorità del processo (nice +/-nn)

Alcuni esempi

Per negare tutti i servizi TRANNE finger da pirate.net (hosts.deny)

all EXCEPT in.fingerd : .pirate.net

Per negare gli accessi remoti: (sempre hosts.deny)

in.telnetd,in.rshd,in.rlogind: ALL

Non permettere login da pirate.net e loggare i tentativi:

in.telnetd,in.rlogind : .pirate.net : spawn=(/security/logit %d deny %c %p %a %h %u)&\ 
   : linger 10: rfc931: banners /security/banners

linger 10 significa che il kernel non deve cercare di mandare messaggi al client dopo 10 secondi che il server ha chiuso la connessione. rfc931 cerca di ottenere lo username, banners visualizza un messaggio del tipo: "Cercare di penetrare in un sistema informatico è un reato perseguibile dalla legge. Tutti i tentativi sono loggati".
Spawn lancia uno script (shell o perl) di nome logit, che salva nome del demone (%d), username@hostname (%c, se lo username è disponibile, altrimenti solo l'hostname o l'IP se il client non ha hostname), process ID del demone (%p), IP e hostname del client (%a %h) e lo username (%u).

Programmi di utilità e letture consigliate

Alcuni programmi forniti con tcpd ci aiutano a testare la nostra configurazione. Altrimenti, come faremmo a sapere se effettivamente l'accesso telnet viene negato all'indirizzo pericolo.pirate.net ?????
I programmi da usare sono i seguenti:

tcpdchk: ci dice se ci sono errori di sintassi in hosts.allow e hosts.deny

tcpdmatch: la sintassi corretta è

       tcpdmatch [-d] [-i inet_conf] daemon client

Quindi non controlla solo hosts.allow e deny, ma anche inetd.conf. -d gli dice di non usare hosts.allow e deny di sistema ma quelli nella directory corrente.
Per esempio, possiamo dargli:

tcpdmatch in.telnetd macchina.qualsiasi.dominio

Ci darà un output del genere:

client:   hostname paranoid
client:   address  123.12.164.12
server:   process  in.telnetd
matched:  /etc/hosts.deny line 10
access:   denied

Letture consigliate: pagine del manuale hosts_access e hosts_options (5), inetd, tcpd, tcpdchk e tcpdmatch (8).
Per gli amanti della carta, consiglio

Garfinkel & Spafford : Practical Unix & Internet Security 
(O'Reilly, 2nd edition, April 1996)

di Roberto Congiu.

Recensioni About Copertina Fake Mail