Può capitare a volte, per un motivo o per l’altro, di avere bisogno di un tunnel privato che ci colleghi ad un host remoto garantendo sicurezza e stabilità. Connessioni di questo tipo trovano largo impiego sia in ambito aziendale che privato, sebbene non tutte le soluzioni esistenti siano economiche o facili da realizzare.

Vediamo ora com’è possibile realizzare un tunnel fra due macchine senza necessità di agire su firewall per impostare regole di port forwarding.

Supponendo di volerci collegare alla macchina A alla macchina B, su cui sia già installato un server SSH, fra i vari client utilizzabili a tale scopo c’è Putty: leggero ed Open Source, non richiede installazione, e fa al caso nostro per risolvere la questione che ci siamo posti.

Aprendo Putty, inseriamo l’indirizzo della nostra macchina B verso cui vorremmo collegarci:

Spostiamoci poi nel menù a sinistra, verso il basso, aprendo il sottomenù Tunnels come in figura:

Qui, scegliamo Dynamic fra le scelte multiple in basso, immettiamo nel campo Source port la porta verso cui la macchina remota si collegherà alla nostra per aprire il tunnel (non è necessario che questa sia aperta verso l’esterno, poiché la connessione avverrà in reverse) e lasciamo bianco il campo Destination.

A questo punto, premendo Add dovrebbe comparire nell’elenco Forwarded ports la porta che abbiamo scelto, preceduta da una D:

La configurazione è finita, prememdo su Open si instaurerà la connessione, e una volta autenticatici nel server come di consueto avremo creato il nostro tunnel. Un esempio di utilizzo: proxy SOCKS – anche per accesso a servizi nella lan locale della macchina cui ci siamo collegati.

Impostando su FireFox come proxy SOCKS l’indirizzo localhost e come porta quella che abbiamo poc’anzi specificato, navigheremo usando la macchina remota come tramite.

Ore 0:53, sono appena arrivato a casa dopo una serata passata nel datacenter del mio cliente invece di essere a cena con Greta.
Tutto e’ iniziato alle 20:15 con l’arrivo di una chiamata di un collega (Pj), che mi chiedeva se questa sera dopo le 21:00 avessi potuto lavorare con lui, all’analisi di un problema verificatosi in giornata su un’applicazione per video chiamata basata su protocollo SIP.
Ovviamente non potevo “esimermi” da tale impegno, dato che il tono di Pj lasciava trasparire che il problema “esigeva” una soluzione nel breve termine e che molto probabilmente anche questa volta il commerciale si era “prostituito” col cliente finale promettendo una soluzione in tempi rapidi…ssimi.
In breve:
il client dell’applicazione (installata presso il call center) deve collegarsi ad un server (in IDC) utilizzando il protocollo SIP con porta sorgente 5060 e porta di destinazione 5060, ma dai logs del firewall emerge che “qualcosa” modifica la porta sorgente del client, infatti tutti i frames vengono allegramente droppati dal firewall perche sorgenti da porte random (???????). Ovviamente tutti i vari carrier che forniscono servizi di rete nel “mezzo” (tra il call center e l’IDC) giurano di non apportare nessun tipo di modifica, quindi tocca a noi fare l’analisi.
Del resto questa è la professione che ho scelto, per cui parto alla volta dell’ IDC Settimo Milanese, faccio tappa in autogrill per pieno di gasolio (quando si ha fretta, il serbatoio e’ sempre vuoto) e sacchetto con panino e bibita, conscio del fatto che quella sarebbe stata la mia cena.
Arrivo all’IDC alle ore 21:15, preparo il portatile, ripassando mentalmente la topologia della rete realizzata piu di una anno fa e che nel frattempo ha subito notevoli modifiche (gli switch sono piu del doppio, rispetto a quelli installati in origine), apro un terminale sullo switch sul quale e’ attestata la rete MPLS che collega il call center all’IDC per configurare l’interfaccia in mirror e verificare se il traffico in ingresso è effettivamente quello che ci apettiamo di ottenere, verificando che nessuna delle parti coinvolte abbia commesso spergiuro.
Chiamo Pj e lo informo, intanto collego il pc, avvio lo sniffer per raccogliere il traffico di un paio di minuti, ed effettivamente le richieste dirette al server sono “pulite” (source 5060, destination 5060), nessuno ha commesso spergiuro, il problema è altrove.
Sempre al telefono col “serafico” Pj, apro un terminale sul nodo attivo del firewall (cluster Checkpoint), avvio tcpdump sull’interfaccia in ingresso del firewall, ma anche qui il traffico in ingresso è pulito, avvio tcpdump sull’interfaccia in uscita e BANG…trovato!!!!
Dal firewall le richieste entrano corrette, ma escono modificate, la porta sorgente non e’ piu’ 5060 ma e’ 14322 (?????), vuol dire che il software di firewalling apporta alcune modifiche, Pj si abbandona ad un sarcastico “ottimo”.
Apro la rule based, verifico la regola, ma è corretta (source x.x.x.x, destination y.y.y.y, service “sip”), domani dovremo contattare l’assistenza e aspettare che rispondano in “tempi biblici”, Pj non e’ felice di doverlo dire al cliente.
Nel frattempo che Pj informa il tecnico che si occupa dell’applicazione in questione, apro le proprieta’ dell’oggetto “sip” di checkpoint e noto che è attivo il “packet inspection”, in pratica checkpoint non si limita a controllare IP e porta, ma verifica se il protocollo in transito sia effettivamente SIP.
Vado su google, cerco un possibile caso analogo, e trovo il post di uno sventurato che si e’ scontrato con un problema analogo utilizzando ASTERISK, il quale suggerisce, per risolvere il problema, di impostare il packet inspection a “none”.
Lo faccio, chiedo a Pj di ripetere la prova, acconsente….FUNZIONA!!!!!!!!!.
Ci siamo salutati contenti di aver trovato la soluzione, seppur un po’ amareggiati per aver capito che checkpoint ne era la causa.

La Sicurezza informatica è il settore dell’informatica atto alla salvaguardia dei sistemi informativi dal rischio di violazione dei dati o del sistema stesso.
Si fonda su alcuni aspetti principali per la protezione dei dati, confidenzialità , integrità e disponibilità .

La “Sicurezza Informatica” si ottiene agendo su più livelli:
1) Livello fisico: Ponendo i server in luoghi il sicuri, con controllo accessi e dotati di sorveglianza;
2) Livello Logico: Prevedendo controlli quali autenticazione e autorizzazione dell’utente nel sistema. Le operazioni effettuate dall’utente successivamente al processo di autenticazione, devono essere tracciate in file di log (processo di accounting).

Ritiriamo il firewall dal corriere, apriamo l’imballo, lo appoggiamo sul tavolo, lo collego al pc portatile e comincio la configurazione.
Operazione fatta già molte volte.
Configuro le varie interfacce, configuro le vlan sugli switch, intanto Dino si occupa di smontare il vecchio firewall, ripulire le vecchie tratte sostituendole con nuove e appena ho finito collega correttamente il firewall alla rete.
Accendiamo e proviavo a fare il canonico “ping” …NULLA!
Controlliamo tutto, dal camblaggio alla configurazione degli switch…e’ tutto a posto, facciamo l’ennesimo ping….NULLA!
Ok, caparbiamente ricontrolliamo tutto, cablaggio, switch, configurazione appena fatta, tabelle arp, tutto in ordine, ma il ping non vuole saperne.
Ok, cancello la configurazione, la rifaccio daccapo come da schema, verifico ed è corretta, quindi non mi resta che fare ancora il famoso ping…NULLA!
Decidiamo di riavviare il firewall, facciamo il ping…FUNZIONA!
…e dire che non e’ Windows.