Secure shell
Da Wikipedia, l'enciclopedia libera.
| Suite di protocolli Internet | |
| Livello applicazioni | DHCP, HTTP, HTTPS , SMTP, POP3, IMAP, FTP, SFTP, DNS, SSH, IRC, SNMP, SIP, RTSP, Rsync, Telnet, HSRP, RTP, BGP, RIP, IGRP, VoIP,... |
| Livello di trasporto | TCP, UDP, SCTP, DCCP ... |
| Livello di internetworking | IPv4, IPv6, ICMP, ICMPv6, IGMP, IPsec... |
| Livello di collegamento | Ethernet, WiFi, PPP, Token ring, ARP, ATM, FDDI, LLC, SLIP, WiMAX, HSDPA, OSPF, MPLS ... |
SSH (Secure SHell, shell sicura) è un protocollo che permette di stabilire una sessione remota cifrata ad interfaccia a linea di comando con un altro host.
Il client SSH ha una interfaccia a linea di comando simile a quella di telnet e rlogin, ma l'intera comunicazione (ovvero sia l'autenticazione che la sessione di lavoro) avviene in maniera cifrata. Per questo motivo, SSH è diventato uno standard di fatto per l'amministrazione remota di sistemi unix e di dispositivi di rete, rendendo obsoleto il protocollo telnet, giudicato troppo pericoloso per la sua mancanza di protezione contro le intercettazioni.
Il client ed il server SSH sono installati o installabili su molte versioni di UNIX, Linux, Mac OS X e Microsoft Windows. Inoltre è disponibile come strumento di amministrazione su alcuni apparati di rete
La sintassi su sistemi UNIX-like è la seguente:
% ssh [opzioni] nomeutente@host [comando]
dove con "%" si intende il prompt della shell utilizzata
Indice |
[modifica] Port forwarding
SSH permette di realizzare dei tunnel criptati, che permettono di trasportare sessioni TCP arbitrarie all'interno della connessione criptata, permettendo di proteggere da intercettazione protocolli non sicuri, o di aggirare limitazioni di routing.
Questa funzionalità è detta port forwarding, e permette di aprire un socket TCP sul client SSH (local port forwarding) o sul server (remote port forwarding). Le connessioni ricevute su questa porta vengono inoltrate dall'altro capo della connessione SSH, verso un host e una porta specificata.
Ad esempio, con questo comando ci si collega ad host1, inoltrando la porta 10022 della macchina in cui lanciamo il client ssh alla porta 22 di host2 attraverso un canale sicuro tra client e host1:
ssh host1 -L 10022:host2:22
Mentre questa connessione è attiva, collegandosi alla porta 10022 del client si viene rediretti verso la porta 22 di host2.
[modifica] X forwarding
Il port forwarding è utile anche per trasportare applicazioni X Window attraverso una connessione SSH. SSH imposta anche automaticamente le opportune variabili d'ambiente, in modo che le applicazioni X lanciate da un terminale remoto vengano visualizzate sul display da cui è stata avviata la connessione.
L'X forwarding dal lato client deve essere abilitato passando l'opzione "-X" mentre dal lato server va modificato il file di configurazione /etc/ssh/sshd_config abilitando la direttiva X11Forwarding (ricordatevi di riavviare il server una volta apportata la modifica al file di configurazione).
[modifica] Esempio di uso del port forwarding
Il port forwarding è utile ad esempio per fare assistenza remota a macchine prive di un sistema di gestione remota sicuro. È possibile creare un tunnel sicuro tra una porta del client e una porta del server remoto o di qualsiasi terza macchina dietro al sever remoto, a patto che la macchina server abbia abilitato il forwarding. Questo è normalmente possibile senza installare nessun pacchetto aggiuntivo.
Ad esempio, nel seguente scenario
CLIENT --[rete insicura]--> ssh server --[rete sicura]--> TERZA MACCHINA
Se vogliamo utilizzare un desktop remoto sulla terza macchina basta che ci connettiamo al server ssh includendo un tunnel tra una porta locale della macchina dove lavoriamo e la porta 3389 della TERZA MACCHINA. Dopo di che basterà avviare il client RDP e connettersi a localhost:(porta scelta).
Il client ssh locale stabilirà una connessione criptata con il server, creerà un tunnel all'interno di questa connessione criptata, ed invierà la connessione RDP su questo tunnel. Il server a sua volta stabilirà una normale sessione TCP con la terza macchina sulla porta richiesta.
Come risultato, il client RDP verrà messo in comunicazione con la terza macchina. La connessione tra ssh server e terza macchina non sarà criptata, per cui è opportuno che la comunicazione tra queste due macchine non sia a rischio di intercettazione. La terza macchina vedrà la connessione TCP provenire dal server ssh invece che dal client.
Non ci puo' essere nessuna applicazione che faccia quello che chiedi. Se usi un modem e hai il firewall di sistema spento, qualsiasi applicazione puo' essere avviata e restare in ascolto con successo su qualsiasi porta. Se invece usi un router le cose sono leggermente piu' complesse. Visto che l'argomento è ricorrente, colgo l'occasione per un breve tutorial (attenzione: cercando di essere semplice, dovro' essere anche un poco approssimativo).
Per capire meglio cosa accade usando un router, occorrono alcune nozioni minime di reti. Nel momento in cui ci colleghiamo ad internet ci viene assegnato un indirizzo IP (internet Protocol) pubblico; un esempio di queto tipo di indirizzi è 195.210.91.83 (l'indirizzo Ip di Libero).
Questo indirizzo IP pubblico è unico in tutto il mondo, e definisce univocamente su internet il computer in questione. Ovviamente gli indirizzi ip non sono infiniti, e sono assegnati (a pagamento) da appositi organismi. Normalmente gli internet provider ne possiedono grossi blocchi che assegnano poi ai propri clienti nel momento in cui questi si connettono; il provider puo' assegnare gli indirizzi o in modo dinamico (in questo caso uno stesso computer, ogni volta che si connette, potenzialmente si vedrà assegnato un IP differente, ovviamente sempre appartenente al blocco posseduto dal provider) o in modo statico (in questo caso lo stesso computer sarà sempre identificato dallo stesso indirizzo).
Ma come abbiamo detto gli indirizzi IP sono un bene finito, e comunque non sempre (per vari motivi) è consigliabile assegnare ai computer un indirizzo IP pubblico. Per questo motivo sono state create tre classi di indirizzi IP riservati ad uso privato; questo significa che possiamo creare delle reti private, ad esempio in casa o in ufficio, assegnando arbitrariamente degli indirizzi ai nostri computer in modo che questi possano comunicare usando il protocollo TCP/IP. Le classi private sono:
classe A: 10.0.0.0 – 10.255.255.255
classe B: 172.16.0.0 – 172.31.255.255
classe C: 192.168.0.0 – 192.168.255.255
Non è questa l'occasione per spiegare in cosa differiscono l'una dall'altra e parlare della logica delle sottoreti. Limitiamoci a ricordare che se vogliamo mettere in una rete privata dei computer dobbiamo usare indirizzi appartenenti a uno di questi range.
Il punto successivo è mettere in comunicazione la nostra rete (o il nostro singolo computer) con Internet. Il router, per funzionare, normalmente ha due indirizzi IP, uno pubblico (quello proiettato su internet e fornito dal provider) e quello privato (fornito da noi che abbiamo creato la rete privata). Facciamo un esempio:
computer A: 192.168.1.2 (IP privato)
computer B: 192.168.1.3 (IP privato)
Router: 192.168.1.1 (IP privato) - 195.210.91.83 (IP pubblico)
Tutti i computer della rete privata, nella loro configurazione TCP/IP, hanno un parametro definito come default gateway, Il default gateway è l'indirizzo IP dell'apparato che mette in comunicazione la rete interna con internet (in questo caso sara' il nostro router, con indirizzo 192.168.1.1). Ogni volta che un computer della rete privata cercherà di accedere ad un indirizzo non appartenente alla sua stessa rete privata, la richiesta verrà indirizzata verso l'esterno via default gateway.
Il router, nel momento in cui trasferisce le richieste all'esterno, tipicamente opera tramite un meccanismo chiamato NAT (network address translation), tramite il quale all'esterno le richieste provenienti da qualsiasi computer della rete privata vengono presentate come provenienti dall'indirizzo IP pubblico del router. Facciamo un esempio: su internet esistono molti siti che ci permettono di verificare quale sia il nostro IP pubblico (as: http://whatsmyip.net); se ci colleghiamo ad uno di questi siti con il computer A e con il computer B, vedremo che l'IP indicato è lo stesso, e precisamente quello appartenente alla interfaccia pubblica del nostro router. Ovviamente il router si preoccupa di gestire la mappa del traffico e quindi a smistare correttamente le risposte alle richieste. Quindi, sempre nel nostro esempio, indirizza opportunamente verso il computer A le risposte a richieste originate dal computer A e indirizza verso il computer B le risposte a richieste originate dal computer B.
Tutto questo funziona perfettamente per l'appunto quando le richieste sono originate dalla nostra rete interna privata, ma cosa accade se le richieste provengono dall'esterno? In questo caso, ovviamente, il router non ha modo di sapere verso quale computer indirizzare queste richieste, a meno di non avere scritta qualche regola. Ecco che entra in azione il port forwarding: tramite questa tecnica possiamo istruire il router su come comportarsi nel caso in cui dovee ricevere una richiesta dall'esterno su una determinata porta.
Facciamo un esempio: vogliamo installare un server web nella nostra rete privata interna, e vogliamo che sia visibile anche dall'esterno (su internet). Sappiamo che il traffico http (per default) "bussa" alla porta numero 80, quindi dovremo scrivere una regola che dica al router come deve comportarsi nel caso in cui riceva delle richieste dall'esterno sulla porta 80. Se il nostro server web è sul computer A (indirizzo IP 192.168.1.2), scriveremo che tutto il traffico che arriva sulla porta 80 della interfaccia esterna (pubblica) del router, deve essere inoltrato sulla porta 80 del computer 192.168.1.2 (rete privata). Con una seconda regola potremo fare altrettanto per un server di posta e così via. Per verificare di aver scritto correttamente la regola possiamo collegarci ad uno dei tanti siti che effettuano uno scan delle porte del nostro IP pubblico (es. http://scan.sygate.com/quickscan.html). La porta rediretta dovra' risultare in ascolto.
Naturalmente il modo in cui materialmente deve essere configurato il router differisce da modello a modello, ma normalmente tutti dispongono di una interfaccia web abbastanza chiara, una volta che si siano compresi questi concetti basilari.
[modifica] Meccanismi di autenticazione del client
Esistono principalmente due metodi di autenticazione per controllare l'accesso ad un server ssh:
[modifica] Username/Password
L'utente fornisce un nome utente ed una password, che vengono validati dal server. Questo scambio avviene all'interno di un canale cifrato, per cui non è a rischio di intercettazione.
Procedura:
- A ⇒ B: SSH_MSG_USERAUTH_REQUEST, pappy, ssh-userauth, keyboard-interactive
- B ⇒ A: SSH_MSG_USERAUTH_INFO_REQUEST, pappy, password-authentication, 1, "Enter Password"
- A ⇒ B: SSH_MSG_USERAUTH_INFO_RESPONSE, 1, "love"
- B ⇒ A: SSH_MSG_USERAUTH_SUCCESS.
Per prevenire attacchi brute force si può utilizzare un tool DenyHosts o Fail2ban.
[modifica] Chiave pubblica
Questo metodo di autenticazione è basato sulla crittografia asimmetrica. Per utilizzarlo l'utente genera una coppia di chiavi. La chiave pubblica è copiata sul server, tipicamente in un apposito file nella home directory dell'utente; la chiave privata deve essere conservata dall'utente, ed è bene che sia protetta con una parola chiave (passphrase).
Nella fase di accesso, il client ssh prova al server di essere in possesso della chiave privata, e in caso di successo viene consentito l'accesso. In questo modo, all'utente non è richiesto di fornire la propria password ad ogni connessione.
[modifica] Autenticazione del Server
SSH prevede anche la verifica dell'autenticità del server. Questo serve ad evitare che un utente maligno "impersoni" il server, facendosi fornire le credenziali dell'utente (attacco man in the middle). A questo scopo, per ciascun server viene generata una coppia di chiavi asimmetriche. La chiave privata rimane sul server. La chiave pubblica deve essere installata sui client. Quando un client si collega ad un server di cui conosce la chiave pubblica, verifica che il server sia ancora in possesso della chiave privata. Se questa verifica fallisce, la connessione viene abbattuta, evitando di fornire credenziali al server.
Nella pratica, quando ci si collega ad un server per la prima volta, il client chiede se si vuole accettare la chiave pubblica di questo server, e se l'utente risponde positivamente memorizza questa chiave e prosegue nella connessione. Alle connessioni successive con lo stesso server, il client ne verifica l'autenticità, e in caso la chiave privata non corrisponda impedisce di proseguire la connessione.
