Ultra Secure Computing
By Vrt__
FIREWALLS: QUELLO CHE AVRESTE SEMPRE VOLUTO SAPERE E NON AVETE MAI OSATO CHIEDERE.
0 INDICE
0 - Indice :-)
1 - Introduzione
2 - Cosa e' un Firewall
3 - Filosofia dei Firewalls
4 - Cosa non possono fare i Firewalls
5 - Costruirsi un Application Level
GW
5-1 - Installazione
Iniziale
5-2 - Gateway Tools
5-3 - Installazione
dei servizi
5-4 - X11
5-5 - E chi protegge
il Gateway?
6 - Amministrazione del Gateway
6-1 - Logs
6-2 - Integrita' dei
Files
6-3 - Altro
6-4 - Riassumendo
7 - Software Utile
8 - Bibliografia
1) INTRODUZIONE
Questo testo servira' a chi come me si e' interessato di firewalls in
quanto nella sua universita' se ne è
montato uno e quindi ( un pò per forza e un po' per diletto ) uno si deve
interessare a certe cose che gli accadono intorno :-) Questo testo non ha uno
schema preciso e sarebbe piu' un memorandum di quello che sto' facendo io in
questo momento dato che ora un firewall sulla mia macchina non esiste . Non ci
interesseremo solo di come installare un firewall ma anche di come migliorare
la sicurezza del nostro sito ed eventualmente dei consigli su come Improvare
:-) ossia migliorare la sicurezza del proprio sito e creare ( nel nostro piccolo
) una vera e propria " ETICA DELLA SICUREZZA DIGITALE" cosa che in
Italia in questo periodo manca e manchera' per un bel po' di tempo. (per
sfortuna o fortuna ????????????????) mah comunque....Perdonatemi quindi le
mille e mille cretinate che scrivero ' in questo testo e andiamo avanti .
2) CHE COSA
E' UN FIREWALL
Noi intenderemo un firewall come una collezione di componenti che si
piazzano in mezzo a 2 reti ( e noi assumeremo Internet e la nostra piccola rete
) che possiedono le seguenti propieta'
-
Tutto il traffico di
dati entrante ed uscente dalla rete interna e viceversa deve passare attraverso
il firewall.
-
Solo il traffico
autorizzato puo' passare impunemente attraverso il firewall.
-
Il firewall e'
immune ( o almeno si spera ) alle penetrazioni illegali.
Non male vero? Ora passiamo ad analizzare i vari svantaggi e vantaggi ad usare una macchina ( e quindi investimenti ) configurata come firewall. Una ottima ragione per montare dei firewalls e' che dedicare e concentrarsi su una macchina sola e interessarsi in buona parte della SUA sicurezza e' molto meglio che guardare tutta la sicurezza di una rete intera , magari costituita da computers di marche differenti .....quindi dedicare una macchina SOLO a questo scopo e' ben piu' vantaggioso che usarne una general purpose e dirsi TANTO A ME NON MI SFONDANO !!! Tutta la mia attenzione dopo sarta' dedicata a curarmi della mia rete e non della sua " sicurezza" ( anche se ...... mah) . La seconda ( che e' anche lo scopo di questo testo e' che comunque una persona che si occupa di firewall HA una coscienza di sicurezza ,cosa che i sistemisti di ben piu' che mezzo mondo non hanno.
3) FILOSOFIA
DEI FIREWALLS
Siamo quindi ben piu'
precisi ...... lo schema di un firewall e' il seguente :
|-------------|------
------|------------|
| | | |
| | GATEWAY | |
| | | |
|-------------|------
------|------------|
Rete Filtro Filtro Rete
Interna Esterna
Filtro : blocca le
trasmissioni di certe classi di dati
Gateway: macchina/e che
provvede ai servizi per compensare l'effetto del filtro
Generalmente si dice che
la zona protetta o rete interna si chiama ZONA DEMILITARIZZATA ( nota che un
gateway possono essere piu' macchine e quindi essere divise in esterne od
interne, le esterne sono detti BASTIONI) Anche il piazzamento di questi firewalls
e' una cosa molto importante , e' facile dire da un mondo interno ad uno
esterno, ma in grosse aziende e' utile tante volte ISOLARE I DOMINI in termini
di sicurezza e quindi di MODULARIZZARE a livello ingegneristico la rete di casa
nostra individuando le varie aree di impiego . Le ragioni di questo fatto sono
che gli impiegati stessi possono essere abilitati o meno a certi dati . Noi
potremo quindi vederci i nostri firewalls come grossi DIODI o DIGHE che isolano
i dati come piu' lo preferiamo. Andiamo con le prime classificazioni:
Un firewall e' suddiviso
come:
-
Packet Filtering:
Poco costoso e facile da reperire e' semplicemente il NOSTRO ROUTER e il suo
software .....(NB le aziende dovrebbero
averne uno) Il nostro installatore dovra quindi per esempio avere una
lista dei siti autorizzati o meno , ma non solo ...saremo in grado di definire
se dal sito pippo.pluto.it vogliamo ricevere soltanto mail. Configurare un
Packet Filtering possiamo dire che e' una operazione di 3 passi:
-
DECISIONI su cio' e
non cio' che e' permesso.
-
Definire tipi
ammessi di dati in termini di operazioni logiche.
-
Riscivere queste
regole nel tuo sistema operativo.
Esempio: porta 25 SENDMAIL dalla rete a SOLO il
tuo Gateway
Azione NostroHost porta lorohost porta commento
-----------------------------------------------
block
- - CATTIVI
- Non li vogliamo
allow
Nostro-gw 25 -
- connessione al SMTP
Pacchetti non esplicitamente espressi da una
regola precedente sono bloccati automaticamente ( KOOL!!!!! :-) )
La filosofia di base e' questa :
QUELLO CHE NON E' ESPRESSO NON E' PERMESSO.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
ancora meglio sarebbe permettere chiamate uscenti
alla porta 25
action
source port dest
port flags commento
--------------------------------------------------------
allow
Noi - -
25 collegamento
noi-loro SMTP
allow
- 25 -
- ACK loro risposta
Supponiamo l'FTP
action
source port dest
port flags commento
--------------------------------------------------------
allow
noi per uscire
allow ack per risposta
allow >1024 traffico non FTP
Supponiamo ora di filtrare sessioni X11
Dovremo sapere tutti che per x abbiamo bisogno di un server al quale x11 si connette via TCP , e che inoltre certe applicazioni devono poter essere pilotate dall' esterno. In questo caso consigliamo di bloccare tutte le chiamate in ingresso sulle porte 6000-6100 almeno ( dipende dal numero di utenti ) .
- Application level gateways
Usato in unione agli altri 2 come protezione aggiuntiva minimale per esempio nel caso dell' X11 visto sopra .....
Svantaggio / Vantaggio e' che e' molto generale e che quindi se noi useremo programmi molto particolari non serve a molto. E' come se avesse gia' un DB di liste come le precedenti a seconda di cio' che ho lanciato nel mio sistema.
-
Circuit
level Gateways
(Il migliore per chiamate in uscita) controlla solamente connessioni TCP. Il chiamante chiama una porta del gateway con TCP che lo connette con qualche cosa all' infuori della rete . Durante la connessione il GW registra tutte le azioni commesse dal malcapitato ( caso mia univ.) .Funziona come se fosse un filo . La connessione puo' essere automatica e espressa direttamente dall' utente (In questo caso il GW si chiama PROXY). Non e' necessario loggare tutto cio ' che esce ...ma basterebbe gia'il numero di bytes e la destinazione per una ottima loggatura . Greppando su un utente o su siti si scopre che cosa ha combinato il CONTROLLATO .:-)
Naturalmente potremo dire
il tempo di connessione ( cosa che da noi non fanno) e una lista di utenti
abilitati all' accesso dall' esterno.
4) COSA NON
POSSONO FARE I FIREWALLS
Anche loro hanno delle limitazioni ...come tutti del resto. Per esempio
sono completamente indifesi agli attacchi su porta alta come puo' essere il
peeking ....ma se il GW rifiuta connesioni X11 siamo a posto . Anche una
corretta manutenzione del nostro gateway e' importante ....se ce ne freghiamo
della sicurezza dei nostri programmi tali che possono essere Sendmail Telnetd
etc etc non montiamoci un firewall ...e' un aiuto ma non e' la soluzione ;e' un
programma anch'esso come tutti gli altri e quindi baggato come tutti gli altri.
Comunque per un attacco medio della stragrande maggioranza dei Lamahs e' ben
piu' che sufficiente
5) COSTRUIRSI
UN APPLICATION LEVEL GATEWAY
Tratteremo l'analisi di costruzione di un Application level gateway con sicurezza ad alto livello . Nota che il seguente viene usato ( teoricamente ) dall' At & T . Considereremo basilari :
1) Un computer unix
(LINUX RULEZZ) :-)
2) Routers
3) software tools
descritti sotto
4) demoni di network
trovabili su Internet ...( solo versioni recenti)
La costruzione descritta
dovrete adattarvela al vostro computer .
Assumeremo che :
-
Gli utenti si
sappiano tenere i dati di sistema tipo passwd e altro per loro conto senza
spedirli in giro per il mondo.
-
Le password non
saranno idiote.
-
Gli hacker che ci
attaccano sono hacker " normali "... non dei geni!
-
I dati interni sono
di media importanza.
Abbiamo
3 sottotipi corrispondenti a 3 livelli di sicurezza crescenti :
-------------Inside-------GW----------Router--------------INTERNET (A)
-Inside----GW-Inside----Privatenet----GW-Outside--Router--INTERNET (B)
-GW-Inside-----Inside-----Router------GW-Outside--Router--INTERNET (C)
(choke)
5.1)
INSTALLAZIONE INIZIALE
Iniziamo
a dire che i comandi del firewall devono essere dati in maniera fisica e
direttamente dalla console del GW .. un accesso fisico e' ben piu' difficile di
uno da Internet per un hacker.
Durante
la configurazione iniziale ha senso connettere gli host a una rete
"sicura" quindi:
-
Per A) e B) spegnere
IP forwarding e source routing dai kernels .
-
Per C) non e' un
passo importante , ma si deve essere sicuri che i dati non passino attraverso
il router choke
-
Il kernel ha bisogno
di alcune configurazioni aggiuntive.
*e' configurato per un numero sufficente di processi? un migliaio e' OK per
una rete gia' tosta.
*eliminare eventuali assegnamenti di limite di uso CPU ai processi del GW.
*verificare che vi siano sufficenti mbuf configurati ..dato che li useremo
spesso.
-
abbondare con la
memoria ...32 mega e' il MINIMO.
-
settare
accuratamente lo spazio di SWAP .
-
cancellare tutti i
servizi di network , commenta /etc/inetd.conf.
-
togliere TUTTI i
compilatori.
-
eliminare programmi
con lo sticky bit non necessari o non capiti.
-
eliminare accounts
non voluti dalla macchina , non vi deve essere nulla se non root e passwords
usuali di amministrazione.
-
riavviare e netstat
-a per verificare che tutti i servizi non sono piu' presenti.
-
settare /etc/motd
per avvertire gli utenti del log continuo e persecutorio ....motivi legali e
psicologici.
-
configurare le
partizioni dell ' HD ..ricordati che fuori possono leggere logs diretory di
spool e ftp directory quindi tutte queste devono finire su partizioni diverse.
-
connettere l'host
alla rete esterna.
-
aggiungere l'entrata
ARP del router agli host . se il router non annuncia le sue informazioni di ARP
solo i nostri 2 hosts sapranno come raggiungerlo.
-
sull' host esterno
aggiungiamo il classico routing di default.
-
salva tutta la
configurazione degli hosts e mettila sottochiave.
-
considera
attentamente l'idea di un backup giornaliero.
-
configuriamo il
Choke ossia il router il quale ha una configurazione strana in quanto abbiamo 2
hosts che lo possono usare .. Quindi…
-
eliminare l'accesso
di telnet dal router , se si possiede un cisco cio' vuol dire che i controlli
del cisco stesso saranno svolti solo dalla console.
-
eliminare accessi
all ARP dal router , in particolare il router non mi deve rispondere alle
richieste di ARP tipo:
no service_finger
no ip redirects
no ip route-cache
no ip proxy-arp
no mop enabled
no ip unreachables
-
istallare nella ARP
degli accessi per gli hosts interni ed esterni , nota come non sia necessario
un routing ...infatti lui si connette solamente con le networks locali.
-
settare un filtro di
pacchetti che nega tutti gli accessi agli hosts interni.
-
per sicurezza
estrema bloccare anche tutti i pacchetti diretti all' indirizzo ethernet del
choke .
Sembra
facile vero? considerate che avete appena configurato le macchine in modo da
poterle elaborare !!!!!!!
Ora
infatti abbiamo bisogno di alcuni attrezzi .....
5.2)
GATEWAY TOOLS
Abbiamo
disponibili in rete alcuni " Tools " essenziali freeware per la
costruzione del nostro gateway .
Prendiamoli
in analisi :
TCP
WRAPPER : Sappiamo ( o almeno dovremo saperlo ) che in un sistema Unix
-----------
abbiamo alcuni demoni uno tra i quali Inetd e' in attesa di eventuali
connessioni dall' esterno , pronto ad attivare i programmi relativi al tipo di
connessione richiesta. Quindi il nostro gateway li dovra' attentamente valutare
(
etc/inetd.conf ). Per esempio abbiamo che :
#
#Procedure interne
#
echo stream tcp nowait root internal
dischard stream tcp nowait root internal
chargen stream tcp nowait root internal
daytime stream tcp nowait root internal
time stream tcp nowait root internal
echo dgram udp wait root internal
dischard dgram udp wait root internal
chargen dgram udp wait root internal
daytime dgram udp wait root internal
time dgram udp wait root internal
#
#Servizi Reali
#
ftp stream tcp nowait /usr/sbin/ftpd wu.ftpd
Abbiamo
che quindi questo file e' di enorme importanza per la nostra configurazione .
Il
Tcp Wrapper provvede a effettuare un controllo sulle connessioni quindi se noi
modificheremo la precedente come :
ftp stream tcp nowait root /gatew/tcpd /usr/sbin/ftpd
il nostro wrapper controllera'
in /etc/hosts.allow se accettare la connessione .
Questo pacchetto serve quindi per determinare eventuali
politiche di connessione del nostro gateway
RELAY : E' una applicazione propria degli
Apllication-Level per loggare
-----
tutte le connessioni che il nostro computer effettua all' esterno
Supponiamo quindi di voler offrire al mondo la nostra stampante (!!!!!) e quindi ammettere delle connessioni sulla porta 515 (vedi sempre /etc/services) abbiamo che quindi il /etc/inetd.conf dovrebbe essere :
printer stream tcp nowait daemon /gatew/relay
tcp!pserver!printer
quindi abbiamo che pserver ,un programma che copia i bit in entrambe le direzioni di ingresso e in uscita, abilita la connessione .
TELNETD : Non staro' esattamente a discquisire
sul fatto che le versioni
------- aggiornate sono da preferirsi a quelle vecchie .:-) Possiamo inoltre far notare come piazzando un RELAY visto prima in maniera da loggare il Telnetd e quindi vedere cosa i nostri utenti effettivamente fanno non e' male .....ma alla mia
universita' queste cose TROPPO
SEMPLICI non si fanno ....quindi si
preferisce TOGLIERE IL TELNET ....che e' piu' sicuro (TZE!!!!!) Potremmo per
esempio sostituire il comando di login con eventuali forme piu' avanzate con le
quali MAGARI ci potremmo anche permettere di LIMITARE I LOGIN ESTERNI come
tempo di Cpu
etc .......
SERVIZI
FTP : Come precedentemente discusso avremo che inoltre possiamo
----------- permetterci di usare il GW come PROXY e quindi di creare links nuovi di zecca ( e ampiamente loggabili )
5-3 INSTALLAZIONE
DEI SERVIZI
L'installazione dei servizi penso che sarebbe la parte piu' noiosa e piena di verifiche sotto verifiche etc che tutta la installazione del firewall puo' offrirci ..ma tante' ...se deve fa'! Nota che all 'inizio di questa fase abbiamo bisogno di TUTTI gli IP numerici della nostra rete ...altrimenti sono cavolacci quando , se per pura sfiga , il nostro computer cerca di fare un resolve .
MAIL : Abbiamo che naturalmente sara' il nostro GW a prendere e mandare la posta .....quindi cio' significa che deve essere correttamente configurato per sopportare qualsiasi tipo di errore. Supponiamo che la posta viene salvata su un computer apposito detto PIPPO configurato con tutti gli uucp che servono. Vogliamo che quindi ( SFATICATI ) la posta arrivi su PIPPO attraverso il GW .
Configuriamo
il mailer esterno se possiamo a ricevere posta sulla 26 per esempio .
- Sul computer CHOKE
action src
port dest port
flags comment
---------------------------------------------------
allow EXTERN >1023 GW 26
allow GW 26 EXTERN >1023 ACK
che mi accetta la
connessione .
Quindi aggiungeremo in /etc/inetd.conf
port26 stream tcp nowait daemon /gatew/tcpd /gatew/relay tcp!PIPPO!25
Non
dimenticate di connettere la porta 26 in
/etc/services
Per
una connessione diretta con l'esterno abbaimo che
action src
port dest port
flags comment
---------------------------------------------------
allow GW >1023 EXTERN 25
allow EXTERN 25 GW >1023 ACK
TELNET :Possiamo permettere a degli utenti autorizzati fuori dal sistema di effetturare connessioni dentro il sistema magari con login sonoio :-) Il relay connette l'utente con il programma di autenticazione di PIPPO e se il login e' OK l'utente puo' fare un rlogin dove vuole. Quindi :
-
mettiamo sonoio nel
passwd
-
sonoio::500:501:
LOGIN ESTERNA:/gatew/usr/sonoio:/gatew/sonoio.sh
-
il demone di telnetd
telnetd stream tcp nowait root
/gatew/tcpd /usr/sbin/telnetd
- vediamo ora /gatew/sonoio.sh
#!/bin/sh
/gatew/relay tcp!PIPPO!666
- e relative connessioni per
il choke
action
src port dest
port flags comment
---------------------------------------------------
allow GW >1023 EXTERN 666
allow EXTERN 666 GW >1023 ACK
-
il servizio in PIPPO
port666 stream tcp nowait root /gatew/sonoio sonoio
-
aggiungere porta in /etc/services
PROXY : installazione :
-----
- in PIPPO
per EXTERN . Useremo la porta per es 402 qui di la dovremo
aggiungere
in /etc/services e /etc7inetd.conf
- sempre il
choke (uff...)
action
src port dest
port flags comment
---------------------------------------------------
allow GW >1023 EXTERN 402
allow EXTERN 402 GW >1023 ACK
- in EXTERN
proxy stream tcp nowait daemon /gatew/tcpd /gatew/proxy
-sempre
in EXTERN aggiungi la 402 in /etc/services
Considero sempre una
installazione minima ..altri servizi a piacimento sono comunque sulla stessa
linea.
5-4 X11
Per questo sevizio che comunque e' sempre molto pericoloso in quanto consente di controllare in modo remoto il video, mouse , tastiera etc , abbiamo una serie di pacchetti che comunque non sono di difficile reperibilita' tipo :
xp11 - xgate : Per
esempio :connetto il server X11 che risiede sulla 6000 + un
numero random e trasmetto il
risultato al mio xp11 il quale genera
un X11 $DISPLAY per quella porta
.
Se mi giunge una richiesta questa
e' compito della xgate che crea
un socket random anche in questo
caso e informa internamente xp11
di cio' . Se l'utente e'
autorizzato ( configurazione xgate) si crea il collegamento.
5-5 E CHI
PROTEGGE IL GATEWAY?
Abbiamo che un largo uso di servizi sono gia' protetti dal tcp wrapper stesso, ma servizi richiesti per esempio da localhost o 127.0.0.1 possono essere comunque disabilitati mettendosi cosi' se' stessi nella lista di un possibile nemico. Abbiamo possibili attacchi sulla nostra syslog , e quindi noi potremmo controllare il demone e uploadarlo sovente .
Anche il choke e' un
elemento vulnerabile del nostro sistema. quindi dovremo disabilitare tutte le
chiamate a questo computer quindi :
action
src port dest
port flags comment
-------------------------------------------------------
block 127.0.0.1 no loopback
block 514 no syslog
block choke no choke
block PIPPO no pacchetti a pippo
allow tutto il resto OK
6 AMMINISTRAZIONE
DEL GATEWAY
Prendiamo atto che anche
il nostro mitico gateway e' una macchina e quindi avra' bisogno di manutenzione
....quindi let's start..:
6-1 Logs : i log creati dal GW
possono crearci una serie di problemi in quanto se la nostra rete e' massiccia
essi diverranno di proporzioni esagerate…mediamente 20 30 mega al giorno !!!
Quindi da cui il problema di prendere solo le informazioni necessarie e
fondamentali . Ovviamente tanto per dire un accesso illegale dall' esterno o
comunque per esempio un tentativo errato di login tipo root o una lettura del
passwd . Anche la locazione di questo
file e' una fase critica del progetto in quanto deve risiedere in una macchina
interna e ben protetta , invece di risiedere all' esterno e quindi di possibili
modifiche da parte di incursori esterni brutti e cattivi .
6-2 Integrita' dei Files : Un buon backup dei propri dati e' un imperativo da
rispettare sempre allo scopo di poter ripristinare il sistema. Un altro
concetto sempre legato al backup e' quello di monitorare costantemente il
nostro sistema. Possiamo vedere attraverso i files vecchi come il sistema e'
cambiato dalle volte precedenti ....anche per cause non- naturali tipo accessi
illegali ...vedasi RootKit Attacks e le varie directory tipo bin root e uucp (
il vecchio giochetto del rhosts + +
e' sempre valido ) e anche i vari lavori di cron eseguiti di notte
tipicamente .
Considerate di iniziare a
usare pacchetti tipo il TRIPWIRE .
6-3 Altro : - Come fa' root a
loggarsi sul gateway? A parte concedere l'accesso alla console solo a root si
potrebbe consigliare telnetd protetti dal tcp wrapper.
- Attenzione ai trasferimenti di
file binari via FTP .....anche dall' interno .
- Cambiare se possibile i nomi di
file di log.
- Loggare se possibile i tentativi
di intrusione.
6-5 Riassumendo :
- Ftp : protetto da chroot , nessun
privilegio.
- SMTP : per la posta e il talk usare
possibilmente SOLO l' UPAS
..un pacchetto piu' sicuro del sendmail
ma meno noto .
- Telnet : connesso direttamente all'
interno ma a un programma che
effettua l'autenticazione .
- Printer : protetta dal tcp wrapper
- Proxynfs : protetto dal wrapper ,
eseguito dall' interno in una
directory con il chroot
- Telnet verso esterno : protetto dal
wrapper , accesso dall'
interno , deve sfociare in un menu' del
proxy .
NB ...uno dei pacchetti liberamente accessibili per l'applicazione di queste piccole regole esistenziali e' il TIS FIREWALL TOOLKIT che implementa benissimo un Application level ed e' studiato per l'uso su macchina singola . Abbiamo protezione estrema per Rlogin Telnet e Ftp . I nostri cari utenti potranno quindi uscire sulla Rete sulla porta corrispondente del nostro gateway. Possiamo inoltre permettere autenticazioni tipo utente@destinazione . Il traffico di sendmail e' controllato da un programma particolrare che impedisce l'accesso a demoni BAGgati . Ftp anonimi sono in una bella directory chroot con un passwd differente da quello reale e solo per accessi ftpd .
7- SOFTWARE
UTILI :
Dunque.... un hacker
trova la maggior parte delle sue info su internet ....bene anche noi andremo a
prendere le nostre proprio la' .
TCP WRAPPER
ftp.win.tue.nl /pub/security/tcp_wrapper
SECURELIB ( addon per
SunOs per eliminazione inetd)
eecs.nwu.edu /pub/securelib.tar
TIS FIREWALL TOOLKIT
ftp.tis.com /pub/firewalls/toolkit
PROXY X11
crl.dec.com /pub/DEC/xforward.tar.Z
IDENTD DAEMON
ftp.uu.net /networking/ident
SWATCH ( associazione
azioni con logfiles)
sierra.stanford.edu
/pub/sources/swatch.tar.Z
SCREEND ( converte il
nostro sistema in un filtratore di pacchetti)
gatekeeper.dec.com /pub/DEC/screend/screend.tar.Z
TRIPWIRE (controllo
pacchetti alterati)
ftp.cs.purdue.edu
/pub/spaf/COAST/Tripwire
E ultimo ma non in
ordine.........
FIREWALLS MAILING LIST!!!!!!!
una bella mail a
majordomo@GREATCIRCLE.COM e messaggio.....
subscribe firewalls tuo_email
8- BIBLOGRAFIA
Firewalls and the internet security
W.R. Cheswick
M.Bellovin , Addison Wesley
LINUX Network Administrator Guide
Olaf Kirch
Le informazioni contenute
in questo testo si intendono a uso FORMATIVO e NON devono essere usate ne' a
scopo di lucro (previa autorizzazione del creatore) ne' tantomeno a scopo
distruttivo .
Non si intende assumere
ALCUNA RESPONSABILITA' per quanto potrebbe derivare dall' applicazione di
quanto scritto e riportato in questo testo .
Email
per info : vrt__@iol.it
Ciao
a Tutti .