Firewall Piercing mini-HOWTO François-René Rideau, fare@tunes.org v0.3b, 27 novembre 1998 Direttive per l'utilizzo del protocollo ppp usando telnet per operare in modo trasparente attraverso un firewall Internet. Traduzione a cura di Stefano di Sandro , ultima revisione 24 Gennaio 2000. ______________________________________________________________________ Indice Generale 1. Varie 1.1 LIBERATORIA 1.2 Copyright 1.3 Ringraziamenti 2. Introduzione 2.1 Premessa 2.2 Problemi di sicurezza 2.3 Altri requisiti 2.4 Scaricare il software 3. Capire il problema 3.1 Dare un nome alle cose 3.2 Il problema 3.3 Difficoltà aggiuntive 4. La soluzione 4.1 Il principio 4.2 fwprc 4.3 .fwprcrc 5. Piercing al contrario 5.1 Giustificazioni 5.2 Ricevere il messaggio di innesco 6. Note Finali 6.1 Altre impostazioni 6.2 Manutenzione dell'HOWTO 6.3 Copia extra della IMPORTANTE LIBERATORIA --- CREDETEMI!!! ______________________________________________________________________ 11.. VVaarriiee 11..11.. LLIIBBEERRAATTOORRIIAA LLEEGGGGII QQUUEESSTTAA SSEEZZIIOONNEE:: ÈÈ IIMMPPOORRTTAANNTTEE !!!!!! QQuuii ddii sseegguuiittoo ddeecclliinnoo ttuuttttee llee rreessppoonnssaabbiilliittàà ppeerr qquueessttee iinnffoorrmmaazziioonnii.. QQuuaalluunnqquuee ssiiaa iill mmooddoo iinn ccuuii iill lloorroo uuttiilliizzzzoo ppoossssaa rriittoorrcceerrssii ccoonnttrroo ddii vvooii,, nnoonn èè ccoollppaa mmiiaa.. SSee nnoonn ssiieettee iinn ggrraaddoo ddii ccoommpprreennddeerree ii rriisscchhii ccuuii vvii aacccciinnggeettee aa ssoottttooppoorrvvii ffaacceennddoo cciiòò cchhee qquuii èè ssccrriittttoo,, nnoonn ffaatteelloo.. SSee uusseerreettee qquueessttee iinnffoorrmmaazziioonnii ee cciiòò ppeerrmmeetttteerràà aa bbaalloorrddii tteeppppiissttii ddii ppeenneettrraarree llee ddiiffeessee ddeeii ccoommppuutteerr ddeellllaa vvoossttrraa aazziieennddaa ccoommpprroommeetttteennddoo vvooii,, iill vvoossttrroo iimmppiieeggoo ee ii mmiilliiaarrddii ddeellllaa vvoossttrraa aazziieennddaa,, bbeehh ssoonnoo pprroobblleemmii vvoossttrrii.. NNoonn vveenniittee aa ppiiaannggeerree ddaa mmee.. 11..22.. CCooppyyrriigghhtt Copyright © 1998 by François-René Rideau. 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. 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. 11..33.. RRiinnggrraazziiaammeennttii Sebbene abbia riscritto quasi tutto tranne la liberatoria, sono in debito con Barak Pearlmutter 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. 22.. IInnttrroodduuzziioonnee 22..11.. PPrreemmeessssaa 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. Tutto è liberamente inspirato al Term-Firewall mini_HOWTO di Barak Pearlmutter , 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. 22..22.. PPrroobblleemmii ddii ssiiccuurreezzzzaa 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. Quindi l'utilizzo dei varchi "legali" in un firewall diventa estremamente _c_o_n_v_e_n_i_e_n_t_e 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). 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). Sia come sia, il metodo qui presente dovrebbe essere _r_e_l_a_t_i_v_a_m_e_n_t_e 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. Per concludere: non usate questo metodologia se non sapete cosa state facendo. È meglio che rileggiate la liberatoria. 22..33.. AAllttrrii rreeqquuiissiittii 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. 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. 22..44.. SSccaarriiccaarree iill ssooffttwwaarree 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: · SLiRP si trova a oppure . · zsh la trovate presso . · ppp è scaricabile da . · fwprc e cotty sono invece a . 33.. CCaappiirree iill pprroobblleemmaa Capire un problema è la prima metà del percorso che porta alla sua soluzione. 33..11.. DDaarree uunn nnoommee aallllee ccoossee 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. 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". 33..22.. IIll pprroobblleemmaa 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. 33..33.. DDiiffffiiccoollttàà aaggggiiuunnttiivvee 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. Telnet si comporta _q_u_a_s_i 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). [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!] 44.. LLaa ssoolluuzziioonnee 44..11.. IIll pprriinncciippiioo Il programma per il firewall-piercing, fwprc, farà uso di un "proxy tty", cotty, 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. 44..22.. ffwwpprrcc Ho realizzato un script auto-documentato per "forare" i firewall, fwprc, disponibile al mio sito , insieme a cotty (che è necessario nelle versioni fwprc 0.2 e successive). Al momento di scrivere queste parole, le versioni più recenti sono fwprc 0.3a e cotty 0.3a. 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 _c_o_r_r_e_t_t_a configurazione). Se dovete pronunciare questa parola ad alta voce, fate in modo di dirla nel peggior modo possibile. SFIDA! SFIDA! Mandatemi un file audio in formato .au 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. 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. 44..33.. ..ffwwpprrccrrcc fwprc può essere personalizato attraverso il file .fwprcrc che deve essere disponibile su entrambi i lati della connessione. È anche possibile predisporre configurazioni diverse da usare alternativamente (per esempio, _i_o lo faccio), ed è lasciato come esercizio al lettore. Per cominciare, copiate la sezione appropriata di fwprc (la penultima) nel file .fwprcrc 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. 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 .fwprcrc con una linea del tipo: remote_IP_emu () { remote_pppd } 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. 55.. PPiieerrcciinngg aall ccoonnttrraarriioo 55..11.. GGiiuussttiiffiiccaazziioonnii 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. fwprc include il codice per scatenare tali connessioni a partire da un messaggio di posta elettronica autenticato con PGP; tutto ciò di cui abbisognate è aggiungere fwprc come filtro per procmail(1) ai messaggi che fanno uso di tale protocollo, (le istruzioni sono incluse in fwprc). Notate comunque che per lanciare pppd con i privilegi appropriati dovrete creare da soli un "suid wrapper" per diventare root. Istruzioni incluse in fwprc. 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. 55..22.. RRiicceevveerree iill mmeessssaaggggiioo ddii iinnnneessccoo 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 fetchmail(1) 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 sendmail(8) che, a sua volta, deve essere configurato per usare procmail(1) per il recapito. Se eseguite fetchmail(1) in background come demone, questi impedirà qualunque altra esecuzione di fetchmail: come nel caso dell'apertura di un fwprc. 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. 66.. NNoottee FFiinnaallii 66..11.. AAllttrree iimmppoossttaazziioonnii 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". In un caso estremamente semplice, potreste semplicemente lanciare ssh su un pty, e lavorare con il pppd nel tty slave. cotty 0.3a dovrebbe essere in grado di farlo, ma ancora nessuno ha modificato fwprc 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. 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. 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 fetchmail(1), suck(1) e altri programmi non interattivi. 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. 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". 66..22.. MMaannuutteennzziioonnee ddeellll''HHOOWWTTOO 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. 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. Non esitate a contribuire con altri problemi e possibilmente con altrettante soluzioni, a questo mini-HOWTO. 66..33.. CCooppiiaa eexxttrraa ddeellllaa IIMMPPOORRTTAANNTTEE LLIIBBEERRAATTOORRIIAA ------ CCRREEDDEETTEEMMII!!!!!! DDii sseegguuiittoo ddeecclliinnoo ooggnnii rreessppoonnssaabbiilliittàà ppeerr qquueessttaa mmeettooddoolloo­­ ggiiaa.. IIll ffaattttoo cchhee ppoossssaa rriittoorrcceerrssii ccoonnttrroo ddii vvooii iinn uunn qquuaalluunnqquuee mmooddoo èè uunn pprroobblleemmaa cchhee nnoonn mmii rriigguuaarrddaa.. SSee nnoonn rriiuusscciittee aa ccoommpprreennddeerree ii rriisscchhii iinneerreennttii iill ssuuoo uuttiilliizzzzoo,, nnoonn uuttiilliizzzzaatteelloo.. SSee,, uussaannddoo qquueessttaa mmeettooddoollooggiiaa,, ppeerrmmeett­­ tteerreettee aa bbaalloorrddii vvaannddaallii ddii ppeenneettrraarree nneeii ccoommppuutteerr ddeellllaa vvoossttrraa aazziieennddaa ccoommpprroommeetttteennddoo vvooii,, iill vvoossttrroo llaavvoorroo ee ii mmiill­­ iiaarrddii ddeellllaa sstteessssaa,, nnoonn vveenniittee aa ppiiaannggeerree ddaa mmee..