Come dare scacco al vile proxy aziendale

Nell’azienda dove lavoro la rete locale è ermeticamente isolata dal mondo esterno.
Il nostro è un ufficio periferico, in Italia, mentre la sede centrale si trova in un altro stato europeo. La connettività internet ce la fornisce Fastweb, ma dal nostro ufficio non si può accedere liberamente alla Grande Rete: tra noi e l’oceano mare c’è il router della casa madre che è connesso via VPN con la sede centrale. Quella VPN è l’unico canale di comunicazione che abbiamo.

Per visualizzare una qualsiasi pagina web con un browser l’unico modo è passare attraverso il proxy HTTP aziendale, ma il “fetuso” ha un sacco di limitazioni:

Limitazione n. 1
Il solo programma autorizzato ad utilizzare il proxy è Internet Explorer, aggiornato ad un preciso patch level.
Quindi niente Firefox né Chrome né Safari né Skype né <qualsiasi-cosa-vi-possa-venire-in-mente>. Ammesso che si riesca ad aggirare questa limitazione (con alcuni programmi si può fare: Firefox, ad esempio, consente di taroccare la User-agent string…) si andrà a sbattere il naso nella…

Limitazione n. 2
Gran parte dei siti là fuori sono bannati.
Quindi niente allegre gironzolate su Facebook, Youtube, Gmail, etc. etc…. E, come se non bastasse, c’è anche la…

Limitazione n. 3
Le uniche porte raggiungibili sono la 80 (HTTP) e la 443 (HTTPS) del protocollo TCP.
Quindi niente connessioni SSH o OpenVPN sul server casalingo, né POP3 o IMAP sul server della posta, né… nient’altro.

Brutta situazione davvero! Non riuscivo a vedere via d’uscita fino a che, cerca che ti ricerca, non ho scoperto la possibilità di bucare il proxy.

Un po’ di teoria…

I proxy HTTP lavorano in modo diverso sulle connessioni HTTP “normali” e quelle HTTPS. Durante le connessioni HTTP il proxy “rompe” la connessione in due pezzi: il primo pezzo va dal client (il browser) al proxy, e il secondo pezzo va dal proxy al server remoto (l’origin server, in gergo). Il proxy, che sta in mezzo, finge di essere l’origin server con il client e finge di essere il client con l’origin server. Poi si prende la briga di fare anche altre cose, tipo filtrare i siti bannati, controllare che non vengano trasmessi dei virus, etc. etc.

Per le connessioni HTTPS non si può lavorare allo stesso modo perché c’è il problema dell’autenticazione reciproca tra client e server e dell’integrità e certificazione dei dati: se si vuole che le connessioni HTTPS funzionino, il proxy non deve toccare neanche un byte. Inoltre, anche volendo, la connessione HTTPS è criptata, quindi il proxy non è in grado di capire alcunché sui dati trasportati. La scelta è tra a) impedire a priori tutte le connessioni HTTPS; oppure b) lasciarle fluire rinunciando a controllarle. A parte una ben nota black list di server squalificati, di solito, anche l’amministratore di rete più rigido le permette: evidentemente l’accredito dello stipendio glielo fanno proprio attraverso una connessione HTTPS ;-).

L’idea di base è quindi questa: imbrogliare il proxy facendogli credere di instaurare una normale connessione HTTPS, ma in realtà instaurare qualcos’altro: una connessione SSH!

… e poi la pratica

L’hacker dà scacco matto in 3 mosse.

Mossa 1
Occorre disporre di un server SSH là fuori sul quale si abbia libero accesso e potere di amministrazione: infatti, affinché l’inganno funzioni, si deve configurare il daemon sshd in modo che si ponga in ascolto sulla porta 443 – quella tipica di HTTPS -, e non su quella standard, la 22. In questo modo il proxy crederà di veicolare una normale connessione HTTPS, quando in realtà si tratterà di una connessione SSH.

Mossa 2
Serve un “grimaldello” che ci apra le porte del proxy: i client SSH, di solito, non lavorano con i proxy HTTP. Possono però usare un programma di appoggio che lo faccia al posto loro. Il grimaldello in questione è proxytunnel, di cui ci sono i sorgenti e i binari precompilati per diversi sistemi operativi. Compilarlo è assai semplice… seguendo le istruzioni nel file INSTALL vi ritroverete il binario in /usr/local/bin/proxytunnel.

Mossa 3
A questo punto occorre istruire ssh ad usare proxytunnel.
ssh permette di definire un dummy host per il quale userà i servigi forniti da proxytunnel. Per fare ciò si deve creare un file ~/.ssh/config che contenga le linee

Host foobar
ServerAliveInterval 30
ProxyCommand /usr/local/bin/proxytunnel -p proxy.customer.com:8080 -d mybox.athome.nl:443 -H "User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; InfoPath.1; .NET CLR 1.0.3705; .NET CLR 1.1.4322)"

Ovviamente occorre andare a sostituire proxy.customer.com:8080 con i dati relativi al vostro proxy server, e mybox.athome.nl con l’indirizzo del vostro server SSH esterno (verosimilmente il vostro server casalingo ;-)).
Il comando ServerAliveInterval 30 istruisce il client SSH ad inviare un pacchetto per mantenere viva la connessione con il server almeno una volta ogni 30 secondi. I proxy, infatti, quasi sempre abbattono le connessioni che non danno segni di vita.
L’opzione -H “User-agent: …” serve a far credere al proxy che il client sia Internet Explorer 6: mettetela solo se vi serve davvero ed aggiustatela in base ai vostri bisogni.
Se il vostro proxy (come il mio) lo richiede, potreste dover aggiungere le opzioni per l’autenticazione: proxytunnel -h per ottenere informazioni su tutte le opzioni accettate.

Fatto! Invocandolo così:
$ ssh nomeutente@foobar
ssh userà proxytunnel per bucare il proxy e sarà così in grado di raggiungere il vostro server. Ganzo!

Tutto qui?

A me riuscire a connettersi al server casalingo via SSH sembra già abbastanza: ma non lo sai che le connessioni SSH possono essere usate per veicolare di tutto? Ad esempio, potrai configurare Firefox in modo da fargli usare il client SSH come proxy SOCKS, arrivare al tuo server casalingo e, da lì, accedere a tutti i siti proibiti.
Oppure puoi realizzare una connessione VPN tra l’ufficio e casa senza bisogno d’altro.

Sì, ma io ho Windows

Sarei tentato di dirti “Comprati un Mac! O, se non hai i soldi, metti Linux!”, ma c’è una soluzione anche per te.
PuTTY è un ottimo client SSH per Windows che fa praticamente tutto quello che fa il client SSH su Unix, compreso usare proxytunnel per bucare i proxy aziendali, e funzionare come proxy SOCKS.
E se Windows ce l’hai sul tuo server casalingo, addirittura, c’è anche il server openssh per Windows. Questo non l’ho mai provato, ma non c’è motivo per cui non debba andare.

Annunci

23 Pensieri su &Idquo;Come dare scacco al vile proxy aziendale

  1. nella mia rete il protocollo https viene rediretto sulla 8080 (in verità tutto, compreso l’ftp deve passare per quella porta) ed il proxy richiede l’autenticazione, con il metodo descritto è possibile ovviare anche ad una situazione del genere?

    • Io sono esattamente nella tua condizione. Ricorda che, comunque, devi avere un server SSH esterno che faccia da ponte.

      Per l’autenticazione sul proxy le opzioni di proxytunnel sono:
      -P nomeutente:password (questi sono username e password per autenticarsi presso il proxy)
      -N (se l’autenticazione segue il protocollo NTLM)
      -t nomedominio (solo per l’autenticazione NTLM)

      Per vedere se le opzioni sono quelle giuste puoi provare a lanciarlo da linea di comando (nell’esempio seguente l’autenticazione presso il proxy segue il protocollo NTLM):

      $ proxytunnel -p indirizzo_proxy:8080 -d indirizzo_server_ssh_esterno:443 -N -P nomeutente:password -t nomedominio
      Via indirizzo_proxy:8080 -> indirizzo_server_ssh_esterno:443
      HTTP return code: 407 Proxy Authentication Required
      NTLM Overriding domain: nomedominio
      SSH-2.0-OpenSSH_5.3p1 Debian-3ubuntu4

      Se riesci a visualizzare un output simile, in particolare l’ultima linea, allora il tunnel funziona.

      Nota: mi sono accorto che, in effetti, la pagina del manuale di proxytunnel non è aggiornata. Per ottenere le informazioni attuali sulle opzioni è meglio lanciarlo con l’opzione ‘-h’.

  2. Bene… ma come la mettiamo se hai sul tuo PC un firewall the ti fa uscire solo con internet explorer e blocca gli altri programmi?
    Ovviamente non hai i poteri per modificare le politiche del firewall…

      • Giusto per provare, ma leggi fino in fondo: sostituisci l’eseguibile di Internet Explorer (oh, fanne una copia prima!) con quello di proxytunnel.
        Mantieni stessa posizione e stesso nome del file. Sul mio PC (Windows 7 64-bit) è “C:\Program Files (x86)\Internet Explorer\iexplore.exe”.

        Se è un firewall serio si sarà salvato da qualche parte un checksum dell’Internet Explorer originale quindi, sostituendolo, sarai sicuramente gabbato. E forse avviserà dell’incidente il tuo amministratore di rete: sei avvisato…

  3. Pingback: 7:55 #1 – juanito y la revolucion blanca « PurpleHare

  4. Scusa a me torna sempre il seguente errore:
    ssh_exchange_identification: Connection closed by remote host
    ovviamente se provo da un pc senza proxy a eseguire la connessione al server l’errore non lo da; sai darmi qualche consiglio

  5. Ciao
    ti chiedevo alcuni chiarimenti, se non ti spiace, riguardo a proxytunnel; ho scaricato il file proxytunnel-190-cygwin.zip il quale contiene

    cygcrypto-0.9.8.dll
    cygssl-0.9.8.dll
    cygwin1.dll
    proxytunnel.exe

    ma quando lancio proxytunnel.exe mi si apre e subito rischiude una finestra di terminale.
    Il programma va installato o viene eseguito stand alone?
    Mi potresti, eventualmente, suggerire un altro sw analogo e che sia eseguibile senza installazione o magari sia in versione portable?

    Grazie Mille
    E.

    • Ciao,
      proxytunnel.exe è un programma da linea di comando: si lancia dal Prompt dei Comandi.
      Nella situazione in oggetto, tuttavia, non si deve lanciarlo direttamente (se non per fare della diagnostica), ma è PuTTY che lo lancia al posto tuo. Segui il link indicato nella sezione per Windows che spiega come fare!

      • Ciao, grazie per la risposta.
        Avevo intuito che lanciandolo da cdm (sono sotto Win) mi servisse solo come diagnostica, e così ho fatto per provare la connessione.
        Ora però ti chiedevo un’altra cosa che non mi è chiara:
        dici che “Serve un “grimaldello” che ci apra le porte del proxy: i client SSH, di solito, non lavorano con i proxy HTTP”.
        Ma ne mio caso specifico però la connessione ssh con PUTTY riesco a farla direttamente, quindi proxytunnel posso evitare di usarlo, credo. Ho capito male?
        Mi sai dire cosa fa effettivamente proxytunnel? Crea lui la connessione? Ma allora ssh non mi servirebbe? Scusa ma nonostante abbia cercato di approfondire l’argomento ho ancora molti dubbi.
        Ultimissima cosa…

        Host foobar
        ServerAliveInterval 30
        ProxyCommand /usr/local/bin/proxytunnel

        foobar sarebbe il nome del tuo host dal quale lanci ssh (macchina linux dall’uffio per intenderci), giusto? Non il tuo nome utente…
        Il comando ProxyCommand è un parametro di ssh? Serve per passargli altri script o eseguibili?

        Grazie mille e scusami tanto per la lunghezza del post

      • Hai capito bene: se PuTTY riesce a connettersi direttamente, allora proxytunnel non ti serve.

        Proxytunnel apre una connessione HTTPS con un server remoto, passando attraverso un proxy. Fin qui si comporta esattamente come un qualsiasi browser (Firefox, Chrome etc.) quando, avendo impostato un proxy, viene inserito un indirizzo che inizia con ‘https://…’.
        A differenza di un normale browser, però, proxytunnel mette la connessione HTTPS che ha aperto a disposizione di altri programmi (ad esempio PuTTY sotto Windows, oppure il client ssh sotto Unix) che possono così farci fluire i propri dati.
        In pratica ci saranno due connessioni una dentro l’altra: la connessione SSH (creata da PuTTY) incapsulata nella connessione HTTPS (creata da proxytunnel). Questo ha senso quando il tuo firewall non autorizza il protocollo SSH, ma invece autorizza il protocollo HTTPS: il firewall osserverà solamente la connessione HTTPS, ignorando completamente che al suo interno fluisce una connessione SSH.

        Riguardo a quelle impostazioni: sono impostazioni per il client ssh per Unix (che vanno messe nel suo file di configurazione ~/.ssh/config), e il loro significato è spiegato nel manuale online di ssh (‘man ssh’ e/o ‘man ssh_config’ da terminale).
        In particolare, foobar è semplicemente un identificativo, scelto a piacere, per il server remoto. Il significato è più o meno questo: “Caro client ssh: quando ti chiedo di connetterti al server foobar, usa queste impostazioni, piuttosto che quelle di default!”.
        ProxyCommand, se c’è, forza ssh a passare attraverso un proxy utilizzando il comando indicato (proxytunnel, nel nostro caso), piuttosto che tentare di contattare direttamente il server foobar (che, essendo un nome scelto a caso, non esiste nemmeno…).

        Come avrai capito mi piace parlare/scrivere di queste questioni, quindi… sei il benvenuto! Salutoni!

  6. Perfetto! Sei stato chiarissimo!
    Mi fa davvero piacere trovare qualcuno così gentile e disponibile.
    L’argomento è molto affascinante e le domande sarebbero tantissime, ma non voglio esagerare hehe

    Ora, anche se non mi serve, ho provato lo stesso a lanciare proxytunnel tramite PuTTY, giusto per capite come funziona (a proposito, incanalando ssh nel tunnel si aggiunge un “grado di sicurezza” in più o è ininfluente?) ma non sono riuscito a impostarglielo.

    Seguendo il link che hai indicato sono andato nella scheda “Connection > Proxy” e ho selezionato “Local” come tipo di proxy.
    Poi nella finesta “Telnet command, or local proxy command” ho inserito

    “proxytunnel -p proxy.da.aggirare:8080 -d mio.server.acasa:443 -P user_x_proxy:PW_x_proxy”

    e invece di tentare un qualsiasi tipo di connessione, si apre una finestra “Putty Fatal Error – Server unexpectedly closed network connection”.
    Il server a cui si riferisce non capisco se è il proxy che rifiuta la connessione perchè “vede” qualcosa di strano, o se è lo stesso PuTTY.
    Devo precisare che:
    – lanciando da cmd “proxytunnel -p proxy.da.aggirare:8080 -d mio.server.acasa:443 -P user_x_proxy:PW_x_proxy” il tunnel viene creato;
    – ho messo proxytunnel e le sue dll nella cartella Putty, come consigliato sulla guida del tuo link

    Ho provato anche aggiungendo “connect” prima di “proxytunnel -p ecc…”, come proposto di default, ma niente.
    Ovviamente lasciando “HTTP” nella scheda “Connection > Proxy” la connessione avviene, MA SENZA USARE PROXYTUNNEL (ho verificato nel Gestore Attività).

    A questo punto non capisco cosa non funzioni, se un problema di Putty (versione 0.62 portable – non posso fare diversamente) o se invece sbaglio qualcosa io nella configurazione.

    Grazie ancora per la disponibilità!

    • PuTTY, con server, si può riferire al server proxy, oppure al server SSH. Ora, visto che: a) proxytunnel quando lanciato da solo riesce a bucare il proxy. E; b) proxytunnel non cambia il suo comportamento se lanciato da solo oppure tramite PuTTY; sono portato a pensare che sia il server SSH remoto (quello a casa) che, per qualche motivo, decide di interrompere la connessione. Hai per caso dato un’occhiata ai log del tuo server SSH?

  7. Ciao
    niente da fare, guardando il log nel file /var/log/auth.log sembra tutto pulito.

    Jan 30 16:06:23 MX-01 sshd[4827]: Accepted password for user01 from 178.209.372.598 port 47285 ssh2
    Jan 30 16:06:23 MX-01 sshd[4827]: pam_unix(sshd:session): session opened for user user01 by (uid=0)
    Jan 30 16:07:42 MX-01 sshd[4827]: pam_unix(sshd:session): session closed for user user01
    Jan 30 16:09:02 MX-01 sshd[5524]: Accepted password for user01 from 178.209.372.598 port 49591 ssh2
    Jan 30 16:09:02 MX-01 sshd[5524]: pam_unix(sshd:session): session opened for user user01 by (uid=0)

    Ho provato diverse volte ma il risultato è sempre lo stesso.

    Ripensandoci però, credo che il problema stia in PuTTy o in qualche sua configuarazione perchè il messaggio di errore mi arriva istantaneamente dopo aver premuto invio. Non tenta nemmeno una connessione.
    Lo stesso succede se nella scheda “Connection > Proxy” seleziono “Local” e non specifico nessun parametro in “Telnet command, or local proxy command”.
    E’ come se “non funzionasse” quando si usa “Local”.

    Magari si tratta di una banalità, ma prima di individuarla…

    Ciao

  8. Ciao
    Ho risolto. Riporto cos’era nel caso potesse interessare a qualcuno in futuro.
    Come immaginavo era veramente una banalità (per non dire di peggio), infatti bastava inserire l’opzione -q nella stringa di proxytunnel in “Telnet command, or local proxy command”.
    TRA L’ALTRO E’ ANCHE RIPORTATO in http://dag.wieers.com/howto/ssh-http-tunneling/ ma non ci avevo dato troppa importanza, anzi.

    Questo serve proprio per non avere output aggiuntivi da parte di Proxytunnel che farebbero andare in “confusione” PuTTY.

    Ciao

  9. ciao, io ho risolto installanto ajaxterm sul server ssh esterno in modo da collegarmi cosi’ via ssh. Certo non posso navigare su molti siti, ma ho il pc pieno di demoni di controllo ed ho paura che usando proxytunnel possano rompere le scatole 😉
    almeno con ajaxterm uso centerim e mutt per fare qualcosa anche dall’ufficio! 🙂

  10. Salve,

    Anche io, al lavoro, usufruisco di un proxy per accedere ad internet (impostato su Firefox).
    Secondo voi è possibile che qualche admin riesca a “sniffare” le password utilizzate per le connessioni https (posta elettronica, amazon, ebay, ecc.) utilizzando qualche software particolare ?

    grazie
    Andrea

Rispondi

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione / Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione / Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione / Modifica )

Google+ photo

Stai commentando usando il tuo account Google+. Chiudi sessione / Modifica )

Connessione a %s...