Come creare un tunnel HTTP, vantaggi e funzionalità

La necessita di fornire un livello di sicurezza elevato per le reti lan, aziendali o domestiche, con lo scopo di difenderle da tentativi di attacco e di intrusione, impone agli amministratori l'uso di policy molto restrittive che spesso si traducono nella chiusura di tutte le porte del firewall aziendale, lasciando aperte solo quelle strettamente necessarie per il lavoro quotidiano. Un attacco esterno, un tentativo di intrusione, la perdita di dati, il malfunzionamento o lo spegnimento di alcuni servizi, necessitano di un intervento degli amministratori, o si esperti esterni, e oltre tutto possono avere come conseguenza un disagio per gli utenti che possono trovarsi nella condizione di non poter completare le proprie attivita.


La necessità di fornire un livello di sicurezza elevato per le reti lan, aziendali o domestiche, con lo scopo di difenderle da tentativi di attacco e di intrusione, impone agli amministratori l’uso di policy molto restrittive che spesso si traducono nella chiusura di tutte le porte del firewall aziendale, lasciando aperte solo quelle strettamente necessarie per il lavoro quotidiano. 

Un attacco esterno, un tentativo di intrusione, la perdita di dati, il malfunzionamento o lo spegnimento di alcuni servizi, necessitano di un intervento degli amministratori, o si esperti esterni, e oltre tutto possono avere come conseguenza un disagio per gli utenti che possono trovarsi nella condizione di non poter completare le proprie attività. Queste azioni hanno quindi un costo economico.

Un elevato grado di sicurezza per quanto accettabile perché riduce la possibilità di rischi legati ad intrusioni, e conseguentemente un risparmio economico, ha d’altro canto il gap di non consentire l’utilizzo di molti servizi che spesso possono tornare utili agli utenti della rete; servizi quali il file sharing, il voip, l’IM, che sono veicolati su porte che nella maggior parte dei casi gli amministratori ritengono di dover tenere chiuse.

Un tunnel HTTP

Una possibilità per ovviare a questo problema senza dover riscrivere le policy di sicurezza dei firewall è quella di utilizzare un tunnel su una porta nota ed aperta, che incapsula il traffico per le altre porte, veicolandolo all’esterno attraverso quella aperta.

Un esempio tipico è il traffico web HTTP. Il traffico HTTP usa generalmente la porta 80, che viene mantenuta aperta dai firewall; potendo far passare attraverso questa porta anche il traffico di altri servizi destinato a porte diverse, si può aggirare il problema. Ovviamente un firewall controlla anche quello che passa attraverso le porte aperte, quindi è necessario “mascherare” tutto il traffico non originariamente destinato alla porta 80, “vestendolo” da HTTP.

Per tunneling si intendono le tecniche che incapsulano un protocollo all’interno di un altro dello stesso livello o di livello superiore; in particolare l’HTTP-tunneling è una tecnica che consente di incapsulare diversi protocolli all’interno del protocollo HTTP, che funge da wrapper, consentendo di far uscire sulla porta assegnata all’HTTP tutto il traffico che altrimenti troverebbe lo sbarramento del firewall, creando una sorta di tunnel virtuale.

Funzionamento di un tunnel HTTP

Questa operazione è realizzata con un’applicazione client/server; queste due applicazioni stabiliscono una connessione HTTP. Il client deve trovarsi all’interno della rete bloccata, mentre il server deve essere esterno, in modo da poter accedere a tutte le risorse disponibili. Un’applicazione di file sharing che intende attraversare il firewall sulla porta 80, comunica con il client del tunnel HTTP, che incapsula i pacchetti, li spedisce al server del tunnel; il server a sua volta provvede ad estrarre i pacchetti dal tunnel ed ad indirizzarli all’host remoto destinatario della comunicazione. 

In rete è possibile trovare diverse soluzioni che consentono questo tipo di operazioni, come GNU HTTP tunnel  e BoutDuTunnel; sono entrambi progetti open source, in grado di creare un tunnel HTTP per attraversare un proxy; GNU HTTP tunnel non supporta le password NTLM richieste dai proxy server Microsoft ISA, a differenza del secondo progetto che quindi ben si adatta ad una rete con server Microsoft.

Implementazione di un tunnel: BoutDuTunnel

BoutDuTunnel è compatibile con i proxy server HTTP, supporta l’autenticazione NTLM; il client opera come server Socks (le versioni v4, v4a e v5 sono supportate), e consente reindirizzamenti statici. I protocolli supportati sono diversi, in quanto sul lato server è disponibile un server HTTP che gestisce:

1. HTTP binary

2. HTTP Soap

3. TCP binary

4. IPC

Il pacchetto è disponibile all’indirizzo http://sourceforge.net/projects/bdtunnel/

Configurazione server

La cartella BdtServer contiene il server ed il file di configurazione BdtServerCfg.xml. Aprire questo file, il tag service name definisce l’interfaccia pubblica del server


<service name=”BdtServer” protocol=”Bdt.Shared.Protocol.HttpBinaryRemoting” port=”180″ />

  • name è il nome da attribuire e deve essere lo stesso per client e server;
  • l’attributo protocol definisce il formato dei pacchetti che saranno inviati attraverso il tunnel;
  • port definisce la porta di ascolto del server, e deve essere la stessa del proxy che limita il traffico sulla rete che cerchiamo di bypassare.

Inoltre è possibile aggiungere un utente a quelli di default, inserendo all’interno del tag users, un tag figlio con il nome scelto, ad esempio:

<users>

….

  <gabriele enabled=”false” password=”1234″ admin=”false” stimeout=”12″ ctimeout=”1″  /> 

….

</users>


il primo attributo è il nome, il secondo definisce se è abilitato o meno e la password dell’utente; admin fa riferimento ai permessi dell’utente, stimeout è il tempo definito in ore, prima di chiudere la sessione, ctimeout è il tempo sempre espresso in ore prima di chiudere una sessione occupata. Entrambi questi valori se settati ad un numero negativo, sono disabilitati. A questo punto è possibile lanciare il server ed osservare un output simile a quello mostrato in figura:

 http-tunnel.png

Configurazione del client

Per configurare il client, successivamente all’installazione nell’host collegato alle rete bloccata, è necessario modificare il file di configurazione del client BdtClientCfg.xml. Ci sono due diversi client che funzionano in modo identico, con la differenza che uno mette a disposizione una GUI, mentre l’altro è a riga di comando.


Entrando nella directory del client, all’internop del file di configurazione occorre cercare il tag service che contiene l’indirizzo IP del server che si vuole utilizzare per creare il tunnel. Un esempio è il tag seguente:


<service name=”BdtServer” protocol=”Bdt.Shared.Protocol.HttpBinaryRemoting” address=”server.address” port=”180″ username=”gabriele” password=”1234″ />


Alcuni dei parametri sono gli stessi inseriti nel tag del service del server, e quindi devono matchare. In particolare:

  • service name è il nome del server;
  • protocol è lo stesso attributo protocol settato nella configurazione del server
  • address è l’indirizzo Ip o DNS del server remoto
  • port la porta di ascolto del server
  • username uno degli utenti abilitati nella configurazione del server
  • password è quella relativa all’utente selezionato

Il passo successivo è abilitare il port forwarding in modo da veicolare il traffico bloccato all’interno del tunnel. Proviamo ad incapsulare il traffico ssh nel tunnel.


Nel file di configurazione del client il tag forward definisce le regole necessarie.


<forward>

  …. 

  <port22 shared=”false” enabled=”true” address=”ssh.server.com” port=”22″ /> 

  ….

  </forward>



Eseguendo il client un messaggio di log informa dell’avvenuta connessione al server. Il canale http è pronto.

Passi finali per l’uso del tunnel http

Ovviamente la configurazione del client con GUI è meno macchinosa di quanto lo sia leggere i tag XML, ad ogni modo i passi da seguire sono gli stessi.

Ora il client che voglia stabilire una connessione ssh con il server ssh.server.com che si trovi al di fuori della nostra rete protetta, può stabilire la connessione con il tunnel, collegandosi alla porta 22 del localhost; il tunnel si occuperà di fare tutto il resto.


Nell’esempio proposto è stata stabilita una connessione ssh, ma solitamente i firewall bloccano porte associate anche a servizi diversi e che per alcuni utenti sono più utili, come quello del remote control effettuato da software come VNC o Windows NX; anche per questi casi la soluzione del tunnel, sebbene introduca un overhead sulla trasmissione, in quanto l’incapsulamento all’interno di pacchetti HTTP non è esente da consumo di banda, riesce ad aggirare il problema, ma occorre comunque fare attenzione che sul server, lasciamo una porta aperta che è potenzialmente accessibile da tutti, e questo introduce quindi ad una maggiore attenzione nell’uso di questo tipo di soluzioni


Facci sapere cosa ne pensi!

L'indirizzo email non verrà pubblicato. I campi obbligatori sono contrassegnati *

È possibile utilizzare questi tag ed attributi XHTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">