Home  |  Mappa  |  Indice  |  Cerca

Convert to GutenPalm or to PalmDoc Georges Tarbouriech <georges.t(at)linuxfocus.org> L'autore: Georges è un utlizzatore di Unix di vecchia data, sia che si tratta di versioni commerciali o free. Si interessa della sicurezza e vuole ringraziare la comunità free per il grandioso lavoro che ha svolto nel software in questo settore. Tradotto in Italiano da: Toni Tiveron <toni(at)amicidelprosecco.com> Contenuto: Perchè utilizzare ssh? SSH e VNC SSH e MySQL SSH e l'emulazione terminale Dove arriveremo? Ed eccoci alla fine! Discussioni su quest'articolo

Nel tunnel

Premessa:

SSH, la shell sicura, un prodotto commerciale eccezionale. Tuttavia vi è una ampia scelta di implementazioni, sia di client che di server, di tipo gratuito. Queste implementazioni esistono sia per Unix (sia esso commerciale o no) sia per altri sistemi operativi.
La più nota implementazione si può trovare presso il sito http://www.openssh.org. In questo sito potrete trovare alternative per sistemi Unix, Windows, Mac,... Per alcuni prodotti, come per esempio Windows, esistono solo soluzioni alternative per i client.
In questo articolo vi presenterò alcuni esempi su come si possa sfruttare ssh per creare un tunnel di dati da e verso altri applicativi. VPN (Virtual Private Network - Rete Privata Virtuale) si basa su ssh, ma in maniera assai diversa, molto più complessa del caso che non andremo ad affrontare qui. Un'altra soluzione sofisticata è quella di ricorrere a VTun.
Secondo quando appena detto, consideriamo questa forma di tunnel come un semplice e lineare modo per inviare dati crittati su di una rete eterogenea in modo da preveneri lo snoop dei dati scambiati tra i due terminali. Tuttavia ricordate che ssh semplicimente cripta i dati, non rederà di certo la vostra rete sicura...
Siete stati avvertiti!

Perchè utilizzare ssh?

SSH è un sostituto di telnet, rsh, rlogin, come già vi era stato spiegato in un precedente articolo. Sebbene si siano, recentemente, trovati alcuni problemi di sicurezza in ssh, essa rimane un ottimo e sicuro strumento per la crittazione dei dati. A proposito del succitato problema di sicurezza inerente le password: vi raccomando caldamente di ricorrere all'autentificazione per mezzo delle passphrases e del sistema RSA! L'utilizzo di ssh non vi vieta di ricorrere anche all'usto di altri strumenti di sicurezza, come per esempio, tcpwrapper.
È abbastanza semplice fare uno snoop dei dati che transitano in una rete con strumento come tcpdump o snoop. Potete fare una prova con due macchine che si scambiano dati, per esempio, mentre è attiva una sessione di telnet. Da una terza macchina che utilizzi Linux come Sistema Operativo, eseguite, per esempio, tcpdump (ovviamente da un utente con i privilegi di root) e date un'occhiata a quel che capita. Potrete leggere tutti i dati!!!! (Nota dell'editore: i tre computer devono obbligatoriamenti essere collegati per mezzo di un HUB, non di uno switch).
Noterete che quello che compare a video è troppo veloce per esser letto, ma nessuno vi vieta di ridirezionarel l'output su un file, che potrete tranquillamente leggere con calma mente vi bevete un caffè. Se questo è vero per i dati, a maggior ragione lo è per le password: ed ecco che il gioco è fatto, ovvero come si possa trovare una porta spalancata per i cracker. Consegnerete loro così la chiave della porta di casa vostra, che in questo caso è il vostro account.
Immaginatevi cosa accadrebbe se il tipo di traffico sulla vostra rete è strettamente riservato.... se voi foste l'amministratore di sistema, temo che il vostro capo a breve di chiederà di trovarvi un nuovo lavoro in un' altra compagnina!!!
Similmente i comandi remoti, come rsh, rcp, rlogin, sono altrettanto pericolosi, in quanto anche questo tipo di dati non è crittato. Se ssh è una valida alternativa a rsh e rlogin, esso ha con se anche un altro strumento: scp, ovvero una valida alternativa a rcp. Con questo voglio dirvi che non vi serviranno più comandi remoti o telnet se ricorrete ad ssh, o almeno, non dovresti utilizzarli.
Come installare ssh, generare le chiavi pubbliche e private... non rientra nello scopo di questo articolo. Troverete tutto quello che vi serve all'interno dell'archivo di ssh che scaricherete, o potrete leggerne la documentazione relativa all'argomento su the Linux Documentation Project (in inglese) e Italian Linux Documentation Project (in italiano).
Dato che l'utilizzo di un computer oggigiorno verte essenzialmente nel trasferimento di dati, sia in un senso che nell'altro, ssh dovrebbe essere uno strumento obbligatorio... bhe in ogni caso spetta a voi la scelta. Tuttavia ssh può servire a ben altro che non semplicemente sostituire telnet o la suite di comandi remoti.
Può essere utilizzata per crittare i dati trasferiti da applicazioni esterne, ed ovviamente, tra sistemi operativi diversi. Può anche comprimere i dati. È spesso usata in associazione a protocolli come pop, ftp, http... sia per comprimere che per crittare dati. È altresì molto utile se siete degli amministratori di sistema, per esempio, per collegarvi da casa al lavoro e viceversa.
Trattandosi di un applicativo client/server, ssh ovviamente per poter lavorare necessita di una macchina su giri il server ed una su cui giri il client (spero che abbiate notato quanto sia arguto!).
Se vi chiedete come mai io abbia sottolineato un aspetto così banale ora ve ne darò una esauriente risposta!. Infatti, dato che qui si sta parlando di software gratuito, molti sistemi operativi che non siano unix, non posseggono una implementazione gratuita del server. Ed eccoci al punto, cioè a volte non si è in grado di vedere le cose più ovvie, e quindi si deve cercare una strada alternativa: la soluzione è chiamata forwarding. Parleremo poi di questa soluzione. Questo vuol dire che se utilizziamo sistemi operativi come Mac Os o Windows, non potremmo avere dei server gratuiti, ma dovremmo arrangiarci con i soli client gratuiti. Come fare questo non è, dopotutto, una cosa così immediata ed ovvia. Proviamo ad affrontare alcuni esempi concreti.

SSH e VNC

Se non conoscete che cosa sia VNC, vi state perdendo uno dei più grandi strumenti mai creati. Potete darci un occhio qui per saperne di più.
Se visitate il sito web di VNC (http://www.uk.research.att.com/vnc/docs.html) troverete la docuemntazione inerente il problema che stiamo affrontando. Per esempio, troverete come utilizzare VNC per mezzo di ssh, da un client Windows verso un server Unix. Di conseguenza io non riscriverò il grandioso lavoro fatto da Frank Stajano, dato che quest'ultimo è di certo migliore del mio.
Diamo ora un'occhiata a come funziona il tutto.
Dapprima dobbiamo scegliere un client gratuito per Windows. Durante questo esempio utilizzeremo Teraterm Pro con l'estensione ttssh. Lo potrete trovare http://hp.vector.co.jp/authors/VA002416/teraterm.html. Per dovere di cronaca noi utilizzeremo ttssf, che è la versione dell' estensione permessa in Francia. (Le cose stanno, comunqe variando, per quel che concerne le leggi sull'esportazione della crittografia. Potete controllare lo stato inerente il vostro paese su questo sito: http://www2.epic.org/reports/crypto2000/countries.html.)
Ora supponiamo di aver avviato il server ssh su di una macchina Unix. Supponiamo anche che nella stessa macchina noi si abbia attiva una sessione VNC Server. Quando avremo questi due server funzionanti, potremmo far collegare una macchina WindowsNT al server Unix per messo di Ttssh.. Questo vuol direi che avremmo una connessione crittata tra le due macchine. Tuttavia questo non vi permette di attivare, dalla macchina NT, un client VNC con protocollo crittografico. Per ottenere questa funzione dovremmo indicare a ssh di inoltrare (ed è appunto per questo che ho scritto questo articolo!) i dati sulla giusta porta.
La macchina Unix su cui gira VNCserver si chiamerà "bandit" ed è in ascolto sulla porta 5901, in quanto si tratta del primo display, di conseguenza il display X per questa macchina sarà 0. Nel caso di uso diretto si dovrebbe utilizzare il seguente comando: "vncviever bandit:1". Ovviamente questa soluzione funziona, ma non staremo trasmettendo dati crittografati. Per mezzo della "shell" di NT (alcuni la chiamano interfaccia DOS...), digitiamo il seguente comando: "/ssh-L5902:bandit:5901" senza spazi. Questo serve a creare una porta locale, nella fattispecie la 5902. Grazie a questo comando potremmo avere una connessione crittografata sul protocollo VNC dalla nostra macchina NT. Questo può esser fatto senza la necesstà di ricorrere alla linea di comando, dato che, Ttssh ha una propria interfaccia grafica. Permettemi di aggiungere che questa sintassi inerente Ttssh. Se lo digitassimo da una macchina Unix dovremo scrivere: "ssh -L 5902:bandit:5901 bandit".
Ovviamente questo era un esempio molto semplice: potrete fare cose molto più complesse. Date un occhio alla documentazione presente sul sito di VNC, in particolarmodo quella redatta da Frank Stajano.

SSH e MySQL

MySQL è probabilmente uno dei DBMS più utilizzati, specialmente in internet. So di essere monotono, ma rendere MySQL sicuro va oltre lo scopo di questo articolo. Tuttavia rendere il flusso di dati tra il server ed i client crittato contribuisce a rendere le connessioni sicure. SSH ci permette di fare ciò, proprio come abbiamo precedentemente fatto con VNC, insomma inoltrare una porta.
Poniamo come caso una situazione Intranet. Il server MySQL gira su di una macchina Linux, e la maggior parte dei client sono macchine WindowsNT. Anche in questo caso ricorreremo all'uso di Ttssh come client sulle macchine Windows.
La porta predefinita del server MySQL è la 3306. Noi inoltreremo i dati sulla medesima porta.
Potrete scegliere se inoltrare in locale o in remoto.
Un inoltro locale apparirà all'incirca così:"/ssh-L3306:localhost:3306" sulla macchina NT o "ssh -L 3306:localhost:3306" su una macchina Unix. Se utilizzeremo come host "localhost" faremo passare i dati per mezzo dell'interfaccia di loopback invece che per mezzo della scheda di interfaccia esterna della macchina.
Un inoltro remoto assomiglierà a: "/ssh-R3306:bandit:3306" su una macchina NT e "ssh -R 3306:bandit:3306" si di una Unix.
Questo riguarda, ovviamente, la sola connessione. Per accedere al DBM, dovrete, ovviamente, configurare e l'hostname e lo username del vostro server MySQL, che probabilmente, saranno diversi dallo username della macchina in cui vi trovate. Verficate nelle pagine del manuale di ssh (man ssh) sull'uso dell'opzione "-l".
Ovviamente questo funzionerà solo se avete un client MySQL sulla vostra macchina WindowsNT.
Se non lo avete, dovrete ricorrere all'uso di un applicazione ODBC, come Sybase. Avviate la vostra applicazione e configuratene l'ODBC per collegarsi al vostro server MySQL. Ora potrete collegarvi al localhost, non al server MySQL, per accedere la server MySQL. Il dati che transitano tra il client ed il server ora sono crittografati. Potete verficare, se volete, con snoop e tcpdump.
Questo è un esempio su rete locale (LAN). Se volete utilizzare questa soluzione su una WAN, potrebbe essere un poco più complesso, specialmente se dovete passare attraverso un firewall. Questa potrebbe essere una soluzione per amministrare da casa, se siete un amministratore di sistema, ma non potete pensare a ricorrere ad un tale metodo se volete interfacciare un sito web con un DBM. In questo caso dovrete cercare soluzioni più complesse, come una VPN. Dopotutto questa è solo un suggerimento.
Attenzione, non crediate che questa soluzione sia sufficientemente sicura per dati molto sensibili, come le carte di credito, per trasferire i dati da e verso il DBM! E dopotutto, chi veramente può affermare di avere un server così sicuro da poter effettuare questo tipo di transizioni senza alcun rischio? Bhe io no di certo!.

SSH e l'emulazione terminale

Cosa vuole dire questa assurda affermazione dato che stiamo già utilizzando un'emulazione terminale?
Facciamo un esempio. Poniamo di utilizzare una vecchia applicazione Cobol su di un server Unix. I client, sono anche questa volta delle macchine WindowNT. Per poter utilizzare questa applicazione, i client, devono poter utilizzare un'emulazione terminale più evoluta di un semplice vt100, vt220 o vt320. Ovvero gli accenti, le tabelle, e tutti gli altri caratteri speciali non sarebbero visibili con queste emulazioni. Forzare un'emulazione standard (vt100, vt200, ...) in modalità 8 bit, non sarà sufficiente ad avere il tutto correttamente funzionante. Anzi renderà il tutto semplicemente instabile. Oltretutto, trattandosi di un prodotto alquanto datato, dovrete ricorrere ad un'emulazione terminale piuttosto vecchia.
Dopo varie peripezie e tentativi per avere un'emulazione funzionante, scopirete che l'emulazione "ibm3151" è quella che vi dà il miglior risultato.
Dato che il software che andrete ad utilizzare è stato sviluppato tempo addietro, di sicuro non avrà in sè alcun concetto di sicurezza. La connessione, difatti, si basa essenzialmente sul protocollo telnet! E come noto, i dati che si vanno a visualizzare sono alquanto confidenziali... Che fare allora? Dobbiamo, per lo meno, trovre un modo per crittare i dati. Ed ecco che ssh ci viene nuovamente in aiuto.
In ogni caso, vi è più di una soluzione per ottenere il nostro risultato...
Potete o ridirezionalre il telnet sulla porta 22 (ssh) o inoltrare la porta dell'emulazione terminale. Purtroppo... temo che il server non accetterà il reindirizzamento del telnet (la porta di questo servizio è normalmente 23): dovrete esser root per poter effetture questo tipo di operazioni (o almeno io mi auguro dobbiate esserlo!). Per quel che rigurda l'applicazione terminale, puo' esser utilizzata da svariate persone allo stesso tempo, ovviamente ricorrendo ad una porta diversa per ogni connessione, mi spiego: 10 utenti, 10 porte.
La cosa si sta un attimo complicando vero??
Iniziamo premettendo che il server su gui gira l'applicativo deve avere il servizio ssh attivo e funzionante, pronto a ricevere connessioni sulla porta 22.
Da un client WinNT, collegatevi al server dell'applicativo per mezzo di Ttssh o per mezzo dei comandi ad interfaccia testo. Semplicemente stabilirete una connessione sicura tra il server ed il client per un determinato utente. Dalle opzioni di Ttssh scegliere l'inoltro della porta 50000 alla porta 23 remota (servizio telnet) sul server. Nella riga di comando dovrebbe esser un qualcosa del tipo "ssh-L50000:servername:23". Ora potrete istruire il vostro emulatore di terminale di collegarsi alla porta 50000 invece della 23. Ora i dati che transiteranno saranno in un canale sicuro, ovvero crittato. Potrete verificarlo per mezzo di snoop e di tcpdump.
Ovviamente dovrete fare la stessa cosa in ogni postazione utente per collegarvi all'applicativo, cambiando, ovviamente il numero della porta. Per sempio potrete utilizzare le porte 50001, 50002, e così via.
Ora qualcuno potrebbe chiedersi: perchè ricorrere a dei valori di porta così elevati?. La risposta è: Moltissime ragioni!
Seriamente, la ragione principale è che si possono gesitre porte di valore elevato senza aver bisogno di avere i privilegi di root.
Il secondo motivo è dato dal fatto che le porte su cui andremo ad eseguire il forward non devono essere già in uso. Per esempio, se utilizziamo Solaris, molte delle porte della fascia alta sono in uso, in accordo ai servizi del sistema. Tuttavia iniziando ad utilizzare la porta 50000, o superiore, il tutto dovrebbe funzionare. Con questo voglio sottolineare il fatto che dovete controllare le porte che andrete ad utilizzare per effettuare le connessioni.
Ovviamente, questo dovrebbe funzionare per tutti i sistemi operativi in grado di utilizzare un client ssh.
Sui metodi di automatizzazione dei processi di configurazione sui client, potete sbizzarrire la vostra fantasia. Ricordate però che non potete chiedere ad un utente medio di effettuare tutte queste operazioni prima di potersi collegare. Lascio questa parte come esercizio per il lettore...

Dove arriveremo?

Questi pochi esempi ci danno un'idea delle possibilità d'uso di ssh. Potete fare molto di più con molte applicazioni ed ssh. Dipende dalle vostre necessità. Alla fine di tutto comunque la filosfia che sta alla base del è l'inoltro dei pacchetti ad un'altra porta.
Tuttavia prestate attenzione quando ricorrete a situazioni più complesse. Per esempio se inoltrate i dati per mezzo di una terza macchina, i dati che transiteranno nel mezzo non satanno crittati.
Un'altro aspetto riguarda i client per Windows che ricorrono a Ttssh. L'inoltro dei dati si basa sull'indirizzo IP, come fanno i comandi remoti, permettendo quindi attacchi di tipo spoof. Ecco qui che ci si trova nella necessità di dover ricorrere ad altri strumenti, come, per esempio, tcpwrapper.
Approfondendo lo studio della documentazione su ssh, imparerete molto. La vostra immaginazione farà poi il resto.

Ed eccoci alla fine!

La sicurezza dovrebbe essere un argomento che riguarda tutti, ma spesso non è così! ssh è solo uno dei tanti strumenti che potete utilizzate ogni giorno. È un ottimo strumento, specie se si considera il suo uso, ovvero uno strumento per crittografare e comprimere i dati.
Dal canto suo ssh risulta esser alquanto inutile fintantochè non avrete risolto i numerosi problemi di sicurezza che avete presenti sulla macchina o sulla rete. Render sicura una rete o una macchina non è certo cosa semplice, anzi! Spesso molti strumenti aiutano e sono molto validi, ma di certo non fanno tutto il possibile o il necessario.
Vi sono alcune operazioni basilari ma essenziali per quello che riguarda la sicurezza di una rete e di un sistema. Non dimenticate di disabilitare tutti i servizi che non vi sono indispensabili, di controllare il bit di SUID, di disabilitare i programmi "a rischio"... C'è moltissimo lavoro da fare e non sarà mai abbastanza. Potretre installre tutte le correzioni di sicurezza che volete su di un sistema, ma tutto ciò si dimostrerà perfettamente inutile se lasciate una o più backdoor disponibili. Ovviamente qui si sta digredendo su un altro argomento, ma è bene ricordare di non tralasciare le cose più ovvie.
Tornando ad ssh, potremmo dire che si tratta di uno strumento senza cui sarebbe impossibile vivere, fintanto che lo si utilizza in maniera propria e per le funzioni per cui è nata. Mi ripeto, ma utilizzatela con passphrases e chiavi RSA, non con le semplici password. Controllare i permessi dei vari file contenuti nella cartella .ssh e gli stessi permessi della cartella in questione. Mi raccomando, utulizzare anche i wrapper!
Vi ricordo che è possibile fare un tunnel via ssh con la maggior parte dei protocolli esistenti. Ciò può risultare utile al fine di ottenere delle connessioni più sicure.
Esiste un altro utilizzo assai comune di ssh, di cui non abbiamo parlato: l'inoltro di una sessione X. Dato che questo avrebbe implicto il fatto di dover far girare X in più sistemi operativi, lo ho volutamente tralasciato. Ma vertendo questo articolo sui tunnel di protocollo la cosa ci riguarda. Specialmente se si considera che X non è un sistema molto sicuro, ssh può migliorare lo stato delle cose.
Per un uso più sofisticato e complesso ssh non è sufficiente. Come avevo detto precedentemente date un'occhiata alle VPN o a strumenti come VTun. Questi probabilmente vi aiuteranno molto.
Come ultima cosa, ma no per questo meno importante, verificate lo stato d'uso della crittografia nel vostro paese. Sarebbe alquanto seccante finire in galera solo per avere utilizzato ssh ed essere trattato come un comune criminale o una spia.
E con questo abbiamo finito!
Stiamo vivendo in tempi grandiosi.  

Discussioni su quest'articolo

2002-07-28, generated by lfparser version 2.25

mirror server hosted at Truenetwork, Russian Federation.