<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
<META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9">
<TITLE>Firewall Piercing mini-HOWTO</TITLE>
</HEAD>
<BODY>
<H1>Firewall Piercing mini-HOWTO</H1>
<H2>François-René Rideau, <CODE>fare@tunes.org</CODE></H2>v0.3b, 27 novembre 1998
<P><HR>
<EM>Direttive per l'utilizzo del protocollo ppp usando telnet
per operare in modo trasparente
attraverso un firewall Internet.
Traduzione a cura di
<A HREF="mailto:stedis@radiolink.net">Stefano di Sandro <stedis@radiolink.net></A>, ultima revisione 24 Gennaio 2000.</EM>
<HR>
<H2><A NAME="s1">1. Varie</A></H2>
<P>
<P>
<H2>1.1 LIBERATORIA</H2>
<P><B>LEGGI QUESTA SEZIONE: È IMPORTANTE !!!</B>
<P><B>Qui di seguito declino tutte le responsabilità per queste
informazioni.
Qualunque sia il modo in cui il loro utilizzo possa ritorcersi contro di voi,
non è colpa mia.
Se non siete in grado di comprendere i rischi cui vi accingete a sottoporvi
facendo ciò che qui è scritto, non fatelo.
Se userete queste informazioni e ciò permetterà a balordi teppisti
di penetrare le difese dei computer della vostra azienda compromettendo voi,
il vostro impiego e i miliardi della vostra azienda, beh sono problemi vostri.
Non venite a piangere da me.</B>
<H2>1.2 Copyright</H2>
<P>Copyright © 1998 by François-René Rideau.
<P>This document is free software; you can redistribute it and/or modify it
under the terms of the GNU General Public License
as published by the Free Software Foundation;
either version 2 of the License, or (at your option) any later version.
<P>Questo documento è da considerarsi software libero; ne è possibile la
redistribuzione e/o la modifica nei termini della GNU General Public License
così come pubblicata dalla Free Software Foundation,
sia nella versione 2 che (a vostra scelta) in una qualunque versione successiva.
<P>
<H2>1.3 Ringraziamenti</H2>
<P>Sebbene abbia riscritto quasi tutto tranne la liberatoria,
sono in debito con Barak Pearlmutter
<A HREF="mailto:bap@cs.unm.edu">mailto:bap@cs.unm.edu</A>
per il suo Term-Firewall mini-HOWTO:
penso che vi fosse la necessità di un mini-HOWTO sul "firewall piercing",
e nonostante qualche difetto, il suo mini-HOWTO si è rivelato un modello e un
incoraggiamento.
<P>
<H2><A NAME="s2">2. Introduzione</A></H2>
<H2>2.1 Premessa</H2>
<P>Dal momento che amministratori di sistema e semplici utenti hanno
diversi diritti e doveri, può accadere che un utente si trovi protetto
dietro un firewall, che è in grado di attraversare, ma in maniera complicata.
Questo mini-HOWTO spiega un metodo generale e versatile
per utilizzare gli strumenti di Internet, senza che apparentemente
si debba attraversare alcun firewall, facendo uso di un emulatore IP
all'interno di una sessione telnet.
<P>Tutto è liberamente inspirato al Term-Firewall mini_HOWTO di
Barak Pearlmutter
<A HREF="mailto:bap@cs.unm.edu">mailto:bap@cs.unm.edu</A>,
che si affidava sia all'antico e abbandonato Term (a suo tempo
un grande programma), che ai dettagli di una implementazione
di telnet non proprio standard, fatta di codice obsoleto e non portabile.
<P>
<H2>2.2 Problemi di sicurezza</H2>
<P>Se l'amministratore del vostro sistema ha predisposto
un firewall, è naturale che possa aver avuto le sue buone ragioni,
così come è probabile che voi abbiate sottoscritto l'accordo di non aggirarlo.
D'altro canto, l'eventuale possibilità di utilizzare telnet verso l'esterno
(che è un requisito affinché quanto ci accingiamo a spiegare funzioni)
significa che vi è stato concesso di connettervi con sistemi remoti
e, se potete effettuare il login su alcuni di questi sistemi,
significa che qualcuno ve l'ha a sua volta permesso.
<P>Quindi l'utilizzo dei varchi "legali" in un firewall
diventa estremamente <EM>conveniente</EM>
per permettere a qualunque programma remoto di comunicare con la nostra
macchina utilizzando i normali protocolli.
Nel caso opposto avremmo bisogno di programmi speciali o modificati (e
ricompilati) facenti uso di proxy dai compiti particolari, le cui configurazioni
possono essere opera di amministratori sprovveduti o incompetenti.
Oppure potremmo dover installare un certo numero di convertitori
per poter accedere a ciascuno dei normali servizi (come la posta elettronica)
attraverso le strade consentite dal firewall (come il web).
<P>Inoltre l'uso di un emulatore IP che operi a livello utente come SLiRP,
può essere anche utile per prevenire attacchi dall'esterno in grado di
perforare il firewall nuovamente in senso inverso, a meno che non siate voi
a permetterlo esplicitamente (oppure che l'attacco sia condotto in modo
abile e astuto o che l'intruso abbia acquisito i privilegi di root o,
infine, che sia in grado di spiarvi sull'host remoto).
<P>Sia come sia, il metodo qui presente dovrebbe essere <EM>relativamente</EM> sicuro.
Tutto dipende dalle particolari circostanze nelle quali vi troverete quando
lo metterete all'opera e io non posso darvi alcuna garanzia.
Molti sono gli aspetti intrinsecamente insicuri in una qualunque connessione
internet e non dipendono esclusivamente dall'uso di questo metodo;
non assumete a priori di essere al sicuro a meno che non ne abbiate delle
valide ragioni e cercate di criptare sempre l'informazione.
<P>Per concludere: non usate questo metodologia se non sapete cosa state facendo.
È meglio che rileggiate la liberatoria.
<P>
<P>
<P>
<H2>2.3 Altri requisiti</H2>
<P>Si dà per scontato che sappiate cosa state facendo;
che sappiate impostare una connessione di rete;
che possediate un account di shell su entrambi i lati del firewall;
che possiate usare telnet (o ssh, o equivalenti) da un account all'altro;
che possiate far girare un emulatore IP su entrambi i lati della connessione;
che possediate programmi in grado di lavorare su un'emulazione IP.
Si noti come qualunque programma possa usare la connnessione,
in questo caso è il pppd l'emulatore locale che colloquia con il kernel di Linux;
altri emulatori, come Term, necessitano di essere ricompilati e collegati
a speciali librerie.
<P>Parlando di emulatori IP, il demone pppd si trova in qualunque buona
distribuzione di Linux o sito ftp; e lo stesso vale per SLiRP.
Se l'account sulla shell remota vi consente di eseguire programmi soltanto
a livello utente, SliRP è la soluzione da adottare per la connessione.
<P>
<H2>2.4 Scaricare il software</H2>
<P>La maggior parte del software descritto sarà disponibile nella vostra
distribuzione o enventualmente tra i contrib; tranne gli ultimi due tutti si
possono trovare come pacchetti rpm.
Nel caso vogliate recuperare l'ultima versione dei sorgenti o degli eseguibili
(dopo tutto non è detto che su entrambi i lati della connessione si trovi un
sistema Linux) utilizzate gli indirizzi elencati di seguito:
<UL>
<LI><CODE>SLiRP</CODE> si trova a
<A HREF="http://blitzen.canberra.edu.au/slirp">http://blitzen.canberra.edu.au/slirp</A> oppure
<A HREF="ftp://www.ibc.wustl.edu/pub/slirp_bin/">ftp://www.ibc.wustl.edu/pub/slirp_bin/</A>.</LI>
<LI><CODE>zsh</CODE> la trovate presso
<A HREF="http://www.peak.org/zsh/">http://www.peak.org/zsh/</A>.</LI>
<LI><CODE>ppp</CODE> è scaricabile da
<A HREF="ftp://cs.anu.edu.au/pub/software/ppp/">ftp://cs.anu.edu.au/pub/software/ppp/</A>.</LI>
<LI><CODE>fwprc</CODE> e <CODE>cotty</CODE> sono invece a
<A HREF="http://www.tunes.org/~fare/files/fwprc/">http://www.tunes.org/~fare/files/fwprc/</A>.</LI>
</UL>
<P>
<H2><A NAME="s3">3. Capire il problema</A></H2>
<P>Capire un problema è la prima metà del percorso che porta alla sua soluzione.
<P>
<H2>3.1 Dare un nome alle cose</H2>
<P>Se volete che questo medoto funzioni,
è obbligatorio che abbiate un'idea di come funziona,
così, nell'eventualità che qualcosa vada storto,
saprete dove andare a mettere le mani.
<P>D'ora in avanti avranno aggettivo "locale" sia la macchina che inizia la
connessione, sia i programmi e i file che si trovano in essa;
dunque, tutto quello che si trova dall'altra parte sarà "remoto".
<P>
<H2>3.2 Il problema</H2>
<P>Il nostro fine è collegare l'ingresso e l'uscita di un emulatore IP locale
rispettivamente all'uscita e all'ingresso di un emulatore IP remoto.
I canali di comunicazione con i quali gli emulatori interagiscono
sono device diretti (come nel caso usuale del pppd) o il
"tty corrente".
Questo ovviamente non si verifica con una sessione telnet.
In quest'ultimo caso la situazione è complicata perché, quando
lanciate l'emulatore locale da riga comando, il "tty corrente" è
collegato all'utente non a una sessione remota. Inoltre quando apriamo
una nuova sessione, sia essa locale o remota, su un nuovo terminale,
dobbiamo sincronizzare l'avvio e la connessione di entrambi gli emulatori
IP altrimenti la spazzatura prodotta in uscita da una delle due sessioni
rappresenterà un comando per l'altra sessione con il risultato di produrre
altra spazzatura.
<P>
<H2>3.3 Difficoltà aggiuntive</H2>
<P>Per ottenenere la massima facilità d'uso,
l'emulatore IP locale deve fornire un IP al kernel per le operazioni di rete,
per tale ragione si usa il pppd.
Comunque, il pppd è limitato abbastanza da accettare dati attraverso una
sola voce all'interno della directory /dev o attraverso il terminale corrente (tty);
una coppia di pipe sarebbe stata molto più naturale.
Tutto funziona correttamente per quanto riguarda il pppd remoto,
visto che quest'ultimo può usare il tty della sessione telnet;
ma per il pppd locale è un problema perché non è in grado di
lanciare la sessione telnet per effettuare la connessione e quindi dovremo
provvedere ad aggiungergli attorno uno strato di software.
<P>Telnet si comporta <EM>quasi</EM> corretamente con una coppia di pipe,
solo che si ostinerà sempre a effettuare il controllo di I/O
(ioctl) sul tty corrente, con il quale interagisce;
usare telnet senza un tty è causa inoltre di corse critiche
che faranno fallire la connessione su macchine "lente"
(fwrpc 0.1 funziona perfettamente su un P/MMX 233, una
volta su sei su un 6x86-P200+ e mai su un 486DX2/66).
<P>[Nota: se trovo quel bischero
(probabilmente qualcuno del MULTICS,
sebbene debba esserci stata gente UNIX stupida abbastanza da copiare l'idea)
che ha inventato il principio dei dispositivi "tty"
in base al quale si legge e si scrive dallo "stesso" pseudo-file,
invece di poter disporre di una pulita coppia di pipe,
lo strangolo!]
<P>
<H2><A NAME="s4">4. La soluzione</A></H2>
<P>
<P>
<H2>4.1 Il principio</H2>
<P>Il programma per il firewall-piercing, <CODE>fwprc</CODE>,
farà uso di un "proxy tty", <CODE>cotty</CODE>,
che apre due dispositivi pseudo-tty,
invoca alcuni comandi su ciascuno di questi slave
e, senza più smettere, copia ogni carattere che viene battuto,
nel tty che serve da ingresso per l'altro comando.
Un comando sarà la connessione telnet al sito remoto
e l'altro sarà il locale demone pppd.
Il pppd può quindi aprire e controllare la sessione telnet
con il più classico degli script di chat.
<P>
<H2>4.2 fwprc</H2>
<P>Ho realizzato un script auto-documentato
per "forare" i firewall, <CODE>fwprc</CODE>,
disponibile al mio sito
<A HREF="http://www.tunes.org/~fare/files/fwprc/">http://www.tunes.org/~fare/files/fwprc/</A>,
insieme a <CODE>cotty</CODE>
(che è necessario nelle versioni <CODE>fwprc</CODE> 0.2 e successive).
Al momento di scrivere queste parole, le versioni più recenti sono
<CODE>fwprc</CODE> 0.3a e <CODE>cotty</CODE> 0.3a.
<P>Il nome "fwprc" è volutamente illeggibile e impronunciabile,
al fine di confondere il paranoico amministratore di sistema
che probabilmente è la causa del firewall che vi rompe le scatole
(naturalmente, possono esistere anche firewall opportuni,
e talvolta indispensabili;
la sicurezza è tutta una questione di <EM>corretta</EM> configurazione).
Se dovete pronunciare questa parola ad alta voce,
fate in modo di dirla nel peggior modo possibile.
<P>SFIDA! SFIDA! Mandatemi un file audio in formato <CODE>.au</CODE>
con la registrazione digitale della vostra pronuncia di "fwprc".
La peggiore vincerà un aggiornamento gratuito e il suo nome nella pagina della
versione 1.0 di fwprc.
<P>Ho verificato il programma con svariate impostazioni
configurandolo attraverso dei file di risorse.
Ma naturalmente, per la legge di Murphy, a voi non funzionerà.
Ritenetevi liberi di contribuire ai miglioramenti che potranno rendere la vita
più facile alle persone che faranno le cose dopo di voi.
<P>
<H2>4.3 .fwprcrc</H2>
<P><CODE>fwprc</CODE> può essere personalizato attraverso il file <CODE>.fwprcrc</CODE>
che deve essere disponibile su entrambi i lati della connessione.
È anche possibile predisporre configurazioni diverse da usare alternativamente
(per esempio, <EM>io</EM> lo faccio),
ed è lasciato come esercizio al lettore.
<P>Per cominciare, copiate la sezione appropriata di <CODE>fwprc</CODE>
(la penultima) nel file <CODE>.fwprcrc</CODE>
all'interno della vostra home directory.
Poi rimpiazzate i valori delle variabili con quelli adatti alla vostra
configurazione.
Infine copiate il tutto anche sull'altro host e provate.
<P>Il metodo di base prevede di usare il pppd localmente e slirp sulla
macchina remota.
Per modificarlo potreste ridefinire la appropriata funzione
all'interno del vostro <CODE>.fwprcrc</CODE> con una linea del tipo:
<BLOCKQUOTE><CODE>
remote_IP_emu () { remote_pppd }
</CODE></BLOCKQUOTE>
<P>Ricordate che SLiRP è più sicuro di pppd, ed è più facile accedervi,
dal momento che non richiede privilegi di root sull'host remoto.
Un'altra caratteristica di sicurezza consiste nel fatto che scarterà
tutti i pacchetti che non provengono direttamente dalla macchina a esso
connessa (tale caratteristica diventa un difetto se tentate di sfruttare
questo metodo per realizzare il routing di una sottorete usando il mascheramento
dell'IP).
Le funzionalità di base di SLiRP sono piuttosto affidabili
anche se l'ho trovato privo delle aggiunte promesse (quali la
controllabilità a tempo di esecuzione), ma, dal momento che è un
software libero, siete anche voi liberi di mettere le mani nel codice
sorgente in modo da implementare tutte le funzionalità di cui possiate
avere bisogno.
<P>
<P>
<P>
<H2><A NAME="s5">5. Piercing al contrario</A></H2>
<P>
<P>
<H2>5.1 Giustificazioni</H2>
<P>Talvolta, solo da un lato del firewall è possibile lanciare una sessione
telnet; ciò nonostante alcune forme di comunicazione restano possibili
(tipicamante usando la posta elettronica).
Forare il firewall è ancora possibile, escogitando un qualunque modo
di innescare una connessione telnet dalla parte "giusta" del firewall verso l'altra.
<P><CODE>fwprc</CODE> include il codice per scatenare tali connessioni
a partire da un messaggio di posta elettronica autenticato con PGP;
tutto ciò di cui abbisognate è aggiungere <CODE>fwprc</CODE> come filtro
per <CODE>procmail(1)</CODE> ai messaggi che fanno uso di tale protocollo,
(le istruzioni sono incluse in <CODE>fwprc</CODE>).
Notate comunque che per lanciare pppd con i privilegi appropriati
dovrete creare da soli un "suid wrapper" per diventare root.
Istruzioni incluse in <CODE>fwprc</CODE>.
<P>La sola autenticazione di questa sorta di "scintilla" non significa aver
predisposto una connessione sicura.
Diventa davvero opportuno, in questo caso, fare uso di una Secure Shell
(anche sopra telnet) per rendere sicuro il collegamento.
E infine osservate attentamente ciò che accade tra l'innesco della
connessione telnet e la ssh che ha luogo su tale connessione.
Qualunque contributo in questa direzione è ben accetto.
<P>
<P>
<H2>5.2 Ricevere il messaggio di innesco</H2>
<P>Se un firewall vi circonda, il vostro messaggio potrebbe trovarsi in un
server centrale che non consente il fitraggio con procmail o alcuna
connessione telnet. Niente paura! Potete usare <CODE>fetchmail(1)</CODE>
da eseguire in modalità "demone" per recuperare e trasferire la posta
al vostro sistema linux che opera da clien, e/o aggiungere un job al servizio
cron per automatizzare il recupero della posta ogni 1-5 minuti.
Fetchmail inoltrerà la posta verso l'indirizzo locale usando <CODE>sendmail(8)</CODE>
che, a sua volta, deve essere configurato per usare <CODE>procmail(1)</CODE> per il
recapito.
Se eseguite <CODE>fetchmail(1)</CODE> in background come demone,
questi impedirà qualunque altra esecuzione di fetchmail:
come nel caso dell'apertura di un <CODE>fwprc</CODE>.
Naturalmente potreste far girare fetchmail come falso utente.
Recuperi troppo frequenti possono non essere opportuni nei confronti del
server, così come recuperi troppo sporadici possono obbligare a pesanti attese
affinchè il messaggio venga letto e la connessione inversa stabilita.
Io uso una frequenza di recupero di due minuti.
<P>
<H2><A NAME="s6">6. Note Finali</A></H2>
<P>
<P>
<H2>6.1 Altre impostazioni</H2>
<P>Ci sono altri tipi di firewall, come quelli che non consentono
le connessioni telnet.
Dal momento che un continuo flusso di pacchetti attraversa un
firewall e trasporta informazioni fuori e dentro di esso,
è sempre possibile perforarlo; al solo prezzo di "usare il punteruolo
più in alto o più in basso".
<P>In un caso estremamente semplice, potreste semplicemente lanciare
<CODE>ssh</CODE> su un pty,
e lavorare con il <CODE>pppd</CODE> nel tty slave.
<CODE>cotty</CODE> 0.3a dovrebbe essere in grado di farlo,
ma ancora nessuno ha modificato <CODE>fwprc</CODE> per effettuare il login.
Potrebbe essere un buon esercizio per stanotte.
Potreste voler applicare quanto visto con un firewall ostile,
solo per costrure una ``VPN'' sicura (Virtual Private Network).
Leggete VPN mini-HOWTO a proposito di questo.
<P>Se dovete passare attraverso una linea a 7-bit, probabilmente userete SLIP al posto
di PPP. Io non ho mai provato: le linee sono quasi tutte 8 bit al giorno d'oggi,
ma non dovrebbe essere complicato.
<P>Ora, se l'unica strada attraverso il firewall è un proxy WWW
(di solito è il minimo per una rete connessa a internet)
potreste scrivere un demone che registra il traffico di dati
in ingresso e in uscita, e farlo girare durante le connessione HTTP,
ottenendo una sorta di telnet-su-HTTP con il quale eseguire
fwrpc.
Potrebbe rivelarsi una soluzione lenta e non molto efficace
ma sufficiente da permettervi di usare <CODE>fetchmail(1)</CODE>,
<CODE>suck(1)</CODE> e altri programmi non interattivi.
<P>Se volete prestazioni maggiori o se le uniche cose che passano
inalterate attraverso il firewall sono cosucce di basso livello
(richieste DNS, pacchetti ICMP, ecc.) allora il gioco si fa duro dal momento
che dovrete mettere le mani sul primitivo stack IP usando (per
esempio) i Fox project's packet-protocol functors.
Otterrete una forma diretta di IP-su-HTTP, IP-su-DNS, IP-su-ICMP,
o affini. Questi ultimi non richiedono soltanto un complesso protocollo,
ma anche un'interfaccia al nucleo del sistema operativo ed entrambi
sono costosi da implementare.
<P>Ancora una cosa, se usate un demone HTTP per il Firewall-piercing,
non dimenticate di fare in modo che serva pagine fasulle,
in questo modo ingannerete i sospettosi amministratori dei firewall "avversari".
<P>
<P>
<H2>6.2 Manutenzione dell'HOWTO</H2>
<P>Ho sentito il bisogno di scriverlo,
ma non ho tutto il tempo da dedicargli,
ecco perché questo HOWTO è così scarno.
E così resterà,
a meno che non riceva abbastanza commenti che mi permettano di individuare
le sezioni che devono essere migliorate.
I commenti sono benvenuti. L'aiuto è benvenuto.
Il mantenimento del mini-HOWTO è benvenuto.
<P>A ogni modo, le sezioni che avete letto hanno messo in evidenza
diversi problemi le soluzioni dei quali richiedono solo che qualcuno
(voi?) vi dedichi un po' di tempo (oppure denaro, pagando altri che lo
facciano in sua vece), sedendosi e scrivendole:
nulla di davvero complicato, sebbene i dettagli possano apparire
pesanti e difficili.
<P>Non esitate a contribuire con altri problemi e possibilmente con
altrettante soluzioni, a questo mini-HOWTO.
<P>
<H2>6.3 Copia extra della IMPORTANTE LIBERATORIA --- CREDETEMI!!!</H2>
<P>
<BLOCKQUOTE>
<B>Di seguito declino ogni responsabilità per questa metodologia.
Il fatto che possa ritorcersi contro di voi in un qualunque modo è
un problema che non mi riguarda.
Se non riuscite a comprendere i rischi inerenti il suo utilizzo,
non utilizzatelo.
Se, usando questa metodologia, permetterete a balordi vandali di penetrare
nei computer della vostra azienda compromettendo voi, il vostro lavoro e
i miliardi della stessa, non venite a piangere da me.</B>
</BLOCKQUOTE>
</BODY>
</HTML>
