![[Photo of the Author]](../../common/images/Georges-Tarbouriech.jpg)
original in en Georges Tarbouriech
en to en Lorne Bailey
en to it Toni Tiveron
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.
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!
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.
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.
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!.
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...
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.
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.