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 collezzione di componenti che si piazzano
in mezzo a 2 reti ( e noi assumeremo Internet e la nostra piccola rete ) che
possiedono le seguenti propieta'
A) Tutto il traffico di dati entrante ed uscente dalla rete interna e
viceversa deve passare attraverso il firewall.
B) Solo il traffico autorizzato puo' passare impunemente attraverso il
firewall
C) 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
a) 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
1) DECISIONI su cio' e non cio' che e' permesso .
2) definire tipi ammessi di dati in termini di operazioni logiche
3) 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 ) .
b) 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.
c) 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) ed ora quel che tutti aspettavano ..........
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
Fico vero? 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 .
© GnomixLand
http://www.gnomixland.com/
http://www.gnomixland.com/