==============================================================================
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
--------------------[ previous ]---[ index ]---[ next ]---------------------
------------------[ iNSTALLARE E C0NFiGURARE i TCP WRAPPERS ]-----------------
---------------------------------[ Pr3DaToR ]---------------------------------
Consumo: 3 Marlboro Rosse Standard ("Il fumo provoca il cancro")
2 BigFruit al limone
Saluti: SMaster (...per la sua pazienza!)
Musica ascoltata: Turn the Page - Metallica (Garage, Inc. 1998)
So What - Metallica (Garage, Inc. 1998)
Bleed - Soulfly (Soulfly, 1998)
- Introduzione -
La funzione dei tcp wrappers e' quella di monitorare e filtrare le richieste
di accesso a vari servizi di rete come SYSTAT, FINGER, TELNET, FTP, RLOGIN,
EXEC, TFTP, ecc. Essi, inoltre, permettono di negare o consentire l'accesso di
determinati host a determinati servizi (secondo i file di regole che vedremo
piu' avanti), di verificare che il client risponda alle specifiche RFC931, ma
soprattutto che tale client non cerchi di impersonare l'host address o l'host
name di altri client. Tale caratteristica e' particolarmente importante nei
sistemi che utilizzano servizi come RSH o RLOGIN dove l'hostname del client ha
un ruolo fondamentale nel processo di autenticazione. A tale proposito i
wrapper, oltre ad effettuare un lookup del client per ottenerne l'IP,
effettuano anche una richiesta ad un secondo DNS per verificare che a tale
IP corrisponda effettivamente quel client. Se il wrapper rileva delle
differenze, o se la risposta del secondo DNS non e' disponibile, l'accesso
viene rifiutato. Se sul vostro sistema i wrappers sono stati compilati con
l'opzione -DPARANOID, viene sempre effettuata tale verifica, altrimenti viene
semplicemente eseguito un lookup del client. Per quanto riguarda l'host
address spoofing, e' compito del kernel, se opportunamente compilato,
rifiutare le richieste di connessione da parte di IP numerici. Se il vostro
kernel non esegue tale operazione, potete sempre compilare i wrappers con
l'opzione -DKILL_IP_OPTIONS.
Se non temete lo spoofing, potete invece compilare i wrappers con
-DHOSTS_ACCESS consentendo solo semplici controlli o sull'host o sul servizio
richiesto (oppure una combinazione di entrambi).
Tengo a precisare che l'utilizzo dei tcp wrappers e' invisibile dall'esterno
ed inoltre essi non intervengono, se non nella fase iniziale, nelle
comunicazioni tra client e server: i wrappers sono necessari solo all'avvio
dei demoni (ftpd, telnetd, fingerd, ecc.) richiesti da inted.
Le uniche limitazioni dei tcp wrappers riguardano gli attacchi con la tecnica
della predizione dei numeri di sequenza (sequence number guessing) e, meno
importante, l'utilizzo dei servizi RPC che appaiono in inetd.conf come rpc/tcp
come ad esempio rexd (ma fidatevi, non e' una grossa perdita).
Bene, prima di passare alla configurazione vera e propria dei tcp wrappers
assicuratevi che essi siano installati sul vostro sistema. Nelle distribuzioni
piu' recenti di Linux essi sono gia' compilati (con -DPARANOID!!) e installati
per cui potete passare direttamente alla loro configurazione). Controllate
quindi con find se nel vostro sistema e' presente il file tcpd (solitamente si
trova in /usr/sbin). Se non l'avete vi consiglio di aggiornare il vostro
intero sistema :), altrimenti scaricatevi i tcp wrappers 7.6 da:
ftp.cert.org/pub/tools/tcp_wrappers/tcp_wrappers_7.6.tar.gz
Assicuratevi che dopo l'installazione dei wrappers sia tcpd che tutti i file
da esso utilizzati abbiano un permesso 755 o 555 .
Proseguiamo ora con il verificare che il nostro /etc/inted.conf appaia
come segue:
ftp stream tcp nowait root /usr/sbin/tcpd wu.ftpd -l -i -a
telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd
finger stream tcp nowait nobody /usr/sbin/tcpd in.fingerd -w
systat stream tcp nowait nobody /usr/sbin/tcpd /bin/ps -auwwx
netstat stream tcp nowait root /usr/sbin/tcpd /bin/netstat -a
Ho riportato solo alcune linee d'esempio, l'importante e' notare che, nei
sistemi con i tcp wrappers, i demoni vengono eseguiti mediante tcpd. Quindi
tutti i servizi, ad esclusione di quelli identificati come internal (echo,
daytime, time, ecc.) devono essere preceduti da /usr/sbin/tcpd.
Anche per i demoni che hanno un pathname (percorso) arbitrario potete
aggiungere il loro percorso in questo modo:
telnet stream tcp nowait root /usr/sbin/tcpd /usr/local/in.telnetd
Se avete apportato delle modifiche all'inted.conf ricordate che dovete farlo
"ripartire" se volete che tali modifiche abbiano effetto
( " ps -ax | grep inetd " per sapere il pid e " kill -HUP [pid] " ).
Editate ora il vostro /etc/syslog.conf per decidere dove andranno scritti, e
con quale criterio, i log prodotti dai wrappers. Un esempio potrebbe essere:
*.=info;*.=notice /usr/adm/messages
*.=debug /usr/adm/debug
*.err /usr/adm/syslog
Questo significa che tutti i log con priorita' info e notice verranno
memorizzati in /usr/adm/messages, mentre i log con priorita' debug saranno
scritti in /usr/adm/debug infine i log con priorita' err li troviamo in
/usr/adm/syslog.
La sintassi della configurazione dei log e' quindi: classe.priorita logfile
Priorita' possono essere debug, info, notice, emerg, err, ecc... mentre per
classi si intendono kern, auth, lpr, ecc... Altri esempi di syslog.conf:
mail.debug /var/log/syslog
Questo significa che tutti i log della classe mail con priorita' debug
(o superiore) verranno scritti in /var/log/syslog.
Se avete dei problemi con i file di log e non funzionano come vi aspettate,
usate syslogd -d per vedere cosa accade realmente.
Vi ricordo, a titolo informativo :) la locazione standard dei file di log di
alcuni os *nix:
aix - /var/adm/messages
dunix - /var/adm/syslog.dated/[DATA]/mail.log
hpux9&10 - /usr/spool/mqueue/syslog
irix - /var/adm/SYSLOG
linux - /var/adm/messages
solaris - /var/log/syslog
sunos - /var/log/syslog
Siamo giunti ora nella fase piu' importante della configurazione dei wrappers.
Prima di proseguire nella modifica dei due file interessati, e piu'
precisamente /etc/hosts.allow e /etc/hosts.deny, sappiate che esistono,
sostanzialemte, due modi per controllare l'accesso al vostro sistema.
Il primo prevede di negare, per default, l'accesso a chiunque e consentire
l'uso di determinati servizi a determinati host agendo unicamente su
/etc/hosts.allow (mostly closed). Questo risulta essere un metodo
particolarmente sicuro se intendete consentire l'accesso al vostro sistema
solo ai vostri amici o a persone fidate. Se, al contrario, volete gestire un
sistema aperto a tutti (ad esempio un servizio ftp) potete consentire per
dafault l'accesso a qualsiasi host e negarlo a particolari host, agendo
unicamente su /etc/hosts.deny (mostly opened). Personalmente preferisco il
primo metodo, in quanto mi consente di controllare meglio chi rovista nel mio
filesystem ed essere sicuro che non fara' danni o scherzi stupidi come un
rm -r /* :). Quindi modificate il file /etc/hosts.deny in modo che appaia solo
questa entry (tutte le altre righe potete commentarle con un #):
ALL:ALL
In questo modo abbiamo negato, come detto prima, per default qualsiasi accesso
a qualsiasi servizio.
Vediamo, finalmente, come creare le "regole" di accesso al nostro sistema.
Supponiamo di avere un /etc/hosts.allow come il seguente:
in.fingerd: ALL : banners /usr/local/etc/banners/ : spawn (echo "Access from
%u@%h using %d." | sendmail root) : DENY
in.telnetd: .lamers.edu : DENY
ALL: .arcanet.it EXCEPT lamer.arcanet.it
Nella prima linea il servizio in.fingerd viene negato (DENY) a tutti (ALL) gli
host e ogni richiesta a questo servzio comporta l'invio di una email al root.
Inoltre, ad ogni tentativo di accesso, viene presentato all'utente del client
il banner specificato.
Nella seconda entry il servizio di telnet e' negato solamente a tutti gli
host che terminano con .lamers.edu.
Nell'utima entry tutti i servizi sono consentiti agli host che terminano con
.arcanet.it ECCETTO lamer.arcanet.it.
Avrete gia' dedotto che la sintassi delle entry in hosts.allow e' la seguente:
service: hostname: banners(opzionale) : options
"service" identifica, chiaramente, il servzio in questione (in.fingerd,
in.telnetd, in.ftpd ... dipende da cio' che appare nel vostro inetd.conf).
"hostname" permette di specificare il nome dell'host interessato. Si possono
inoltre utilizzare le wildcard come ALL (tutti), LOCAL (hostname dove non
appare nessun punto), UNKNOW (host sconosciuti), KNOW e PARANOID (host a cui
l'address non corrisponde): EXCEPT non e' considerato come wildcard ma
semplicemente come "operatore".
"banners" specifica quale banner (messaggio) visualizzare ad un client che
richiede un determinato servizio.
Infine "options" permette di eseguire dei comandi da shell come, ad esempio,
spedire una mail al root. E' possibile, inoltre, porre al termine di tale
comando la famosa & che permette di porre in background il processo o il
comando dichiarato. Inoltre i wrappers mettono a disposizione delle variabili
che iniziano con % (come avete visto nell'esempio) chiamate "espansioni",
alcune possono essere:
%a fornisce l'host address
%c fornisce maggiori informazioni sul client
%d nome del processo
%u username del client
Per maggiori dettagli vi consiglio, inoltre, di dare un'okkiata a
man hosts_access(5) .
Infine, dopo aver configurato i nostri /etc/hosts.allow e /etc/hosts.deny,
vediamo di creare i file contenenti i banners, cioe' i messaggi che
appariranno al client. Essi possono essere messaggi di "benvenuto" o messaggi
di "rifiuto" (dipende dalle regole che avete stabilito :))
A tale proposito create, se necessario, la directory /usr/local/etc/banners
nella quale creerete i vostri banners, ognuno per ogni diverso servzio:
/usr/local/etc/banners/in.telnetd per il telnet
/usr/local/etc/banners/in.ftpd per l'ftp
OK, siamo giunti al termine della configurazione dei tcp wrappers.
Ora dovete solamente controllare se il vostro hosts.allow e' formalmente
corretto, usate a tale scopo il comando tcpdchk il quale provvedera' a
notificarvi se ha trovato degli errori e se volete simulare l'utilizzo dei
wrapper utilizzate tcpdmatch.
Per il momento questo e' tutto... cosa ci sara' la prossima volta? Bho!
Pr3DaToR
--------------------[ previous ]---[ index ]---[ next ]---------------------
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
==============================================================================