Chi gestisce un server linux non può non aver abilitato almeno una volta sshd. La shell, su molte installazioni (soprattutto se solo testuali), è spesso indispensabile.
Non ci soffermeremo in questo articolo sui dettagli della sicurezza di OpenSSH o se è corretto o meno esporre il servizio SSH con password o certificato. Lo scopo di questo articolo è richiamare l'attenzione sui tunnel SSH, spesso ignorati dagli EDP ma estremamente usati da chi intende compromettere un sistema linux.
Cos'è un tunnel SSH?
Che la si chiami "VPN SSL", "Binding SSH", "SSH Forwarding" o semplicemente "Tunnel SSH", poco cambia. I tunnel SSH sono uno strumento potentissimo, in grado di farsi carico del traffico di una socket e trasportarla ove risiede il server SSH.
Proviamo a fare qualche esempio.
Dando per scontato che un client SSH esterno ad una rete possa collegarsi ad un server linux interno con il servizio SSH attivo, e che non vi siano altre porte aperte e accessibili, è possibile raggiungere qualsiasi host o servizio della rete interna.
Schematizziamo:
Cosa si evince da questo schema? Ok, che uso ancora Paint (e per la precisione ho persino scaricato Paint per MAC). Ma non era qui che volevo arrivare.
Presupponiamo che:
- Il server SSH accetti le tunnellizzazioni e sia in ascolto sulla porta di default 22/TCP, per semplicità diciamo che non c'è NAT e che il server ha due schede di rete in routing che consentono il forwarding dei pacchetti (ma questo è del tutto irrilevante, si tratta di una esemplificazione; l'importante è arrivare a stabilire una sessione SSH, che questa avvenga su un IP pubblico statico o mediante un Port Address Translation è del tutto indifferente)
- Il Firewall, locato virtualmente tra internet ed il server, consenta esclusivamente la connessione SSH e in nessun caso l'apertura di altre porte (a noi basta la 22/TCP)
- Sul PC vi sia il servizio Terminal Service (Remote Desktop Protocol) di Microsoft in ascolto (ma può essere qualsiasi altro servizio
semplicemente stabilendo una connessione come segue è possibile aprire un tunnel verso il desktop remoto del pc interno alla rete, senza che questo abbia alcun servizio pubblicato all'esterno:
ssh -L 3389:192.168.1.2:3389 utente@11.22.33.44
(ma è possibile farlo con qualsiasi client, dall'intramontabile Putty a SecureCRT)
dove:
-L sta per "crea un tunnel SSH",
il primo 3389 sta per "apri in localhost la porta 3389"
192.168.1.2:3389 sta per "termina il tunnel contattando l'host 192.168.1.2 sulla porta 3389"
ed il resto sono le credenziali del server ssh.
A questo punto basterà collegarsi (con qualsiasi client RDP) in localhost per entrare nel tunnel
Facciamo delle considerazioni:
- L'host (nel nostro caso 192.168.1.2) vede connessioni arrivare dal server 192.168.1.1, e non dal nosro ip pubblico (per risalire al reale mittente è necessario consultare i log del server ssh... e se questo è compromesso come minimo dei log non ce ne facciamo molto)
- Tutto il traffico all'interno del tunnel è crittografato (essendo, di fatto, traffico al pari di ssh)
Facciamo qualche esercizio
Se all'interno di un'azienda il cui server web linux semiabbandonato dove ci girano due paginette statiche e "tanto anche se succede qualcosa non c'è niente di importante" espone un server SSH compromesso (che consente tunnellizzazioni) cosa succede?
Tutto ciò che può succedere quando c'è un hacker seduto alla scrivania accanto alla nostra con il suo bel notebook collegato sulla stessa rete del server compromesso.
Sostanzialmente, il server compromesso diventa il ponte tra la rete interna e l'attaccante, superando le canoniche policy di firewalling che isolano il mondo esterno da quello interno.
Ancora un esercizio:
ssh -L 8800:192.168.1.99:80 utente@11.22.33.44
Se 192.168.1.99 è il riservatissimo webserver Intranet degli ordini, categoricamente chiuso a qualsiasi accesso dal mondo esterno, ma terribilmente aperto dalla LAN ("perchè tanto lì ci sono solo i commerciali"), andando su http://127.0.0.1:8800 cosa vedrò?
Il riservatissimo webserver degli ordini.
E chi sono io?
Un tizio che viene dal mondo esterno.
Capite perchè è bene tenere a mente questo tipo di meccanismo?
Conclusioni e accorgimenti
Ci sono svariati modi per evitare spiacevolezze.
- Non esporre, ove possibile, il servizio SSH. E se proprio non si può fare a meno di farlo, utilizzare il meccanismo dei certificati, più robusto della semplice password.
- Disabilitare, se possibile, la tunnellizzazione SSH nel file /etc/ssh/sshd_conf (o dove è locato il file di conf in base alla distro utilizzata). Salvo, ovviamente, che non la si usi esplicitamente.
- AllowTcpForwarding no
- X11Forwarding no
- Specificare chi può accedere e chi no, per evitare che tutti gli utenti con una shell possano gironzolare in ssh. E, perchè no, incrementare la verbosità dei log.
- AllowUsers pippo pluto
- DenyUsers topolino paperino
- LogLevel INFO
- Implementare meccanismi di fail2ban in grado di blacklistare ip che tentano attacchi di tipo bruteforce (http://www.fail2ban.org/)
- Separare i server pubblici da quelli privati, creando una DMZ tramite firewall perimetrali e, ove necessario, VLAN sugli switch (se i server pubblici rimangono confinati in una zona "intermedia" che non ha accesso alle risorse private di LAN, i danni possono essere significativamente contenuti)
- Trattare i server pubblici come host "ostili" e non come host di LAN. Spesso le regole di firewalling che interessano i server pubblici sono troppo morbide (o semplicemente comode). Le policy di firewalling non devono solo gestire le transazioni tra internet ed il server pubblico, ma anche tra il server pubblico ed il resto della rete! Questo è un errore estremamente ricorrente: fidarsi di un server pubblico (seppur proprio e nella propria rete) è spesso un ottimo modo per rovinarsi qualche giornata.
E' bene, inoltre, ricordare che in genere le tunnellizzazioni SSH sono abilitate di default su moltissime distribuzioni linux.
Discaimer: Ogni articolo di questo blog è stato integralmente scritto dall'autore. Il contenuto è completamente originale e la riproduzione è vietata salvo autorizzazione.
