Reverse SSH con Lan Turtle

Un paio un po' di premesse

1) l'hardware non e' male .... il problema e' dal punto di vista software fa veramente schifo. E' molto meglio andare in shell e configurarsi tutto a mano

2) Nonostante abbia pagato la spedizione mi sono trovato la sorpresa della dogana. Non era meglio indicarlo prima ?'

3) l'hardware ripeto non e' male....ma sono cose che si possono fare con qualsiasi Raspberry o simili. L'unico vantaggio reale e' che il dispositivo e' molto anonimo...certo che si prevedeva l'alimentazione POE (e non come unica fonte dal lato USB) non era necessario attaccare un trasformatore od un powerbank che in un rack di rete attirano decisamente l'attenzione. Se si usa una porta USB dello switch si deve installare un dongle Data Blocker per evitare che si apra la porta sul 172.xxx.xxx.xxx

4) E' possibile configurare la Lan Turtle solo se si connettono insieme la USB e il cavo Ethernet. Solo con la USB connessa non si riesce ad entrare in SSH nonostante il dispositivo sia acceso

5) Visto le lamentele di molti utenti NON ho fatto l'update del firmware alla v.4

Dopo le premesse si inizia: Lan Turtle e' un dispositivo che puo' essere utile per amministrare le proprie reti oppure per violare reti altrui...in ogni caso si deve accesso fisico alla rete. E' costituito da una porta USB (che viene configurata come una scheda di rete virtuale) che si usa per la configurazione del dispositivo all'indirizzo 172.16.84.1 (con DHCP Server) ed una porta Ethernet (con un DHCP client). Quando si inserisce in un computer la scheda e' completamente trasparente e non si ha la necessita' di installare driver...tutto il traffico in entrata ed in uscita dal computer viene instradato in modo trasparente tra le due interfacce
La documentazione ufficiale si trova qui https://www.hak5.org/gear/lan-turtle/docs

Una volta entrati come root con la password di default sh3llz (e' richiesto il cambio al primo accesso) si entra in un menu di amministrazione (richiamabile da shell con il comando turtle) ma si fa prima a non usarlo perche' e' molto buggato (almeno per la parte autossh)

Prima di procedere alla configurazione di autossh si deve creare la chiave SSH e si deve effettuare lo scambio con il server esterno da cui controllare Lan Turtle. Per verificare che cio' sia avvenuto in modo corretto se ci ci connette in SSH da shell non dovra' essere richiesta la password (in questa fase ho riscontrato un problema ma i codici di errori erano sparsi per tutto lo schermo...meglio usare le vecchie maniere) 

Questa e' l'interfaccia di amministrazione di AutoSSH ... come si vede accanto all'IP del server remoto c'e' un carattere apice...non l'ho messo io...lo mette in automatico Lan Turtle ed il bello e' che lo scrive anche nel file /etc/init.d/autossh rendendolo lo script non eseguibile

Una volta fatta la configurazione si dovrebbe avviare AutoSSH ogni reboot....ma non funziona.

il file /etc/config/autossh configurato a mano e che funziona e' il seguente

-----------------------------------

config autossh

option gatetime '0'

option monitorport '20000'

option poll '600'

option ssh '-i /root/.ssh/id_rsa -N -T -R 2222:localhost:22 luca@xxx.xxx.xxx.xxx'

-----------------------------------

La soluzione per avviare AutoSSH al boot e' quella di configurare il file /etc/rc.local

/etc/init.d/autossh enable

Comunque puo' essere interessante fare un giro a questo link per vedere quanti problemi software ha questo dispositivo. In caso di problemi il reset del firmware e' possibile ma non immediato

SSH e disconnessione sessione

Succede piuttosto spesso di dover utilizzare una connessione remota in SSH e lanciare dei comandi (tipicamente delle query). Tipicamente quando si chiude una sessione ssh si uccidono anche tutti i processi che si erano aperti nella sezione. Per risolvere questo problema viene in aiuto il comando nohup

ssh luca@ip.ip.ip.ip "nohup /home/luca/comando> /dev/null 2>&1 &"

con la sintassi sopra riportata si lancia comando sia SSH senza che il suo processo venga chiuso al termine della sessione

Server casalingo con FastWeb

Una breve guida su come impostare un server casalingo affacciato su Internet usando una connessione FastWeb

In dotazione con il contratto FastWeb mi e' stato fornito un router Epicentro raggiungibile all'indirizzo 192.168.1.254.
Per entrare in amministrazione
username : Fastweb
password : [lasciare vuoto]

come si vede l'indirizzo e' di tipo pubblico ma dinamico

Il primo passo e' quello di impostare il DNS dinamico

Tra le varie opzioni quella piu' comoda (e gratuita) e' stata quella di usare no-ip.com
Per configurare il servizio e' sufficiente inserire username e password dopo aver impostato il nome sull'interfaccia di NoIp

Interfaccia Web di NoIp

Configurazione Dinamic DNS su router

fatto cio' si pasa al port forwarding (port mapping sulla configurazione del router)

la porta 22 (SSH) e' riservata e non si puo' fare il port forwarding. Non e' un problema perche' basta impostare una porta alternativa (tipo 2222)

non ci sono problemi invece con il port forwarding della porta 80 HTTP

Reverse SSH su Intel Edison

Il tunnel reverse SSH e' un metodo estremamente comodo per amministrare macchine su reti private senza necessariamente installare una VPN e senza dover cambiare le configurazioni dei firewall (questo perche' la connessione viene iniziata dall'interno della rete privata, regola generalmente accettata e non filtrata dai firewall su un protocollo SSH che viene spesso lasciato non filtrato)

Le condizioni necessarie sono
1) una macchina deve essere disponibile con indirizzo pubblico
2) le due macchine devono poter instaurare una connessione SSH

diciamo di avere una macchina A su indirizzo pubblico del tipo 150.217.xxx.xxx ed una chiamata B (una Intel Edison per esempio) su una rete privata con indirizzo del tipo 192.168.1.10. L'obbiettivo e' di amministrare la macchina B da A mediante una shell SSH

Per prima cosa si deve procedere allo scambio delle chiavi in modo da rendere l'autenticazione automatica (cio' aiuta nel caso in cui la connessione cada per creare uno script per riattivarla in modo automatico o per iniziare il reverse tunnel al boot)

Macchina B
con il comando
ssh-keygen 

si creano una coppia di chiave pubblica e privata per la macchina B.
Su Intel Edison non e' disponibile ssh-agent quindi e' piu' comodo NON utilizzare una passphrase 

a questo punto si copia la chiave pubblica sulla macchina A mediante

scp -P 22 ~/.ssh/id_rsa.pub root@150.217.xxx.xxx:~/.ssh/authorized_keys
per comodita' l'utente della Intel Edison e quello della macchina remota sono identici e sono root (lo so, non si fa....e' solo per semplicita')

da questo punto ci si dovrebbe loggare da B (Edison) al server esterno con il solo comando

ssh root@150.217.xxx.xxx
se tutto va bene si puo' procedere a creare il tunnel inverso

dalla macchina B si digita il comando

ssh -R 19999:localhost:22 root@150.217.xxx.xxx

a questo punto la connessione e' stabilita. Per amministrare la macchina B dalla macchina A si digita

ssh localhost -p 19999

e si entra nella shell di B

A questo punto non e' ancora finita perche' bisogna assicurarsi che la macchina B chiami A ad ogni riavvio (per esempio per mancanza di corrente)
Per fare cio' si deve creare la directory

mkdir /etc/init.d

copiare il file script che avvia il reverse tunnel e renderlo eseguibile
a questo punto si digita

update-rc.d script.sh defaults

sembra finito ma non e' cosi' perche' se la connessione non viene usata (ovvero non passano pacchetti lungo il tunnel) il collegamento viene resettato dopo un timeout. Non volendo modificare le impostazioni del server la soluzione piu' semplice e' usare autossh

L'installazione non e' banale perche' non e' disponibile il pacchetto opkg

wget http://www.harding.motd.ca/autossh/autossh-1.4e.tgz 

gunzip -c autossh-1.4e.tgz > autossh.tar  

tar xvf autossh.tar 

cd autossh-1.4e 

./configure 

make 

make install

si sostituisce il comando precedente con autossh

autossh -M 0 -o "ServerAliveInterval 30" -o "ServerAliveCountMax 3" -L 19999:localhost:22 root@150.217.xxx.xxx 

un altro sistema e' quello di usare la sintassi
autossh -i /home/root/.ssh/id_rsa. -M 20002 -N -R 20000:localhost:22 root@150.217.73.18 &

Mysql tunnel over SSH

Alcune volte, un po' per passare dati riservati, un po' per bucare firewall non particolarmente permissivi si puo' creare un tunnel SSH per far passare anche informazioni derivanti da altri server. In questo caso si puo' vedere come interagire direttamente con un database MySql nel caso in cui la porta 3306 del server sia filtrata mentre la porta 22 risulta accessibile

In pratica la connessione funziona in questo modo

server Mysql (3306 remota) <-> SSH remoto (22) <-> Internet <-> client locale ssh <->porta locale del tunnel

Linux
Nel caso Linux la procedura per creare un tunnel Mysql over SSH e' piuttosto banale e veloce
Si crea il tunnel con la seguente riga di comando

ssh login@server -L 3306:127.0.0.1:3306 -N &

login e server sono le credenziali del server SSH

in pratica ci si connette con la porta 3306 remota (passando dal tunnel SSH) ed creando una porta 3306 in ascolto. (Ovviamente sulla macchina client non deve essere presente nessun servizio che occupi la porta ... in caso contrario il numero della porta locale puo' essere modificato a piacere)

(importante la & finale per mandare il processo di tunnel in background...in caso si ometta si deve aprire un'altra shell per gestire il collegamento Mysql)

Fatto cio' ci si connette come se il server fosse installato in localhost

mysql -h 127.0.0.1 -p -u user_mysql
(ovviamente le credenziali di Mysql sono quelle dell'host remoto)

Windows

In questo caso il client SSH e' molto piu' spesso Putty. Per creare un tunnel SSH con Putty, dopo aver creato come di norma una sessione, 

si deve andare in Connection/SSH/Tunnels ed impostare 

Source port : 3306

Destination : 127.0.0.1:3306 

Anche in questo caso non deve esserci un altro servizio che occupa la porta 3306 ed in ogni caso la Destination port puo' essere modificata

Di preme Add e la schermata dovrebbe essere identica a quella sottostante

Fatto cio' si puo' aprire MysqlWorkbench e connettersi in localhost per creare una connessione con Mysql remoto

Mysql SSH Tunnel

In questo precedente post avevo indicato come mettere in ascolto un demone SSH su due schede di rete

Mi e' stato chiesto, sulla stessa macchina di poter interagire con il server Mysql, sia dalla scheda con indirizzo interno che da quella con indirizzo pubblico. Nonostante i vari tentativi di modificare il bind-address (impostandolo per esempio a 0.0.0.0 per il server SSH) non sono riuscito a mettere il server in ascolto.
A questo punto entra in gioco un piccolo trucco; visto che l'accesso SSH e' garantito si puo' creare un tunnel mysql over ssh, in pratica il traffico mysql viene instradato con canale SSH ed il client non si collega direttamente all'indirizzo remoto ma ad un propria porta locale

Il comando per fare cio' e' il seguente
ssh -fNg -L 3307:127.0.0.1:3306 luca@10.1.1.238

ci si collega dal client alla macchina remota (10.1.1.238) collegando la porta remota 3306 (Mysql) con una porta locale 3307

per collegarsi ed interrogare il database si puo' usare quindi la sintassi
mysql -h 127.0.0.1 -P 3307 -u luca 

(testato su Os X e Linux)

Rsync senza password per backup su macchine differenti

Supponiamo di avere due macchine, una di produzione e l'altra di backup, che devono condividere gli stessi dati o per lo meno la seconda macchina deve funzionare come backup del server principale

Il metodo piu' semplice e' utilizzare il comando rsync con lo scambio delle chiavi in modo da non necessitare l'introduzione di una password (per semplicita' su entrambe le macchine ci sara' lo stesso utente)

Si testa prima la connessione copiando i dati dal server principale (192.168.0.1) a quello di backup 192.168.0.2 (ci si mette quindi nella shell del server principale)

rsync -avz -e ssh /home/luca/ luca@192.168.0.2:/home/luca/backup

in questo modo i file della home dell'utente luca sul server sono copiati sulla macchina remota. Si deve inserire manualmente la password

Per evitarlo, stando nella shell del server principale, si creano le chiavi ssh con 

ssh-keygen

(si puo' digitare enter alla richiesta della passphrase)

si copiano quindi le chiavi sul server di backup

ssh-copy-id -i /home/luca/.ssh/id_rsa.pub 192.168.0.2

se ha funzionato possiamo loggarci in ssh come luca da 192.168.0.1 a 192.168.0.2 senza digitare password

ssh 192.168.0.2

terminato cio' se digitiamo di nuovo il comando
rsync -avz -e ssh /home/luca/ luca@192.168.0.2:/home/luca/backup

non verra' richiesta la password, cosa particolarmente utile se si mette la procedura in cron

Port Knocking

Stanco di aver sempre qualcuno che prova ad entrare sul servizio SSH del server mi sono deciso ad implementare il Port Knocking. In estrema sintesi con questo sistema e' possibile modificare le regole del firewall dall'esterno in modo da esporre un servizio che normalmente e' stato mascherato dal firewall e non ammette connessioni. Il trucco si basa sull'invio di una sequenza di pacchetti codificati che vengono letti da un demone sulla macchina che agisce poi in base a regole predefinite

Partiamo da un server in cui siano attive regole di firewall per filtrare tutto il traffico tranne quello entrante su porta 80 ma che comunque abbia attivo ma filtrato un servizio SSH. L'idea e' quello di usare Port Kocking per connettersi dall'esterno su SSH

con questi comandi viene ammesso tutto il traffico su localhost e viene droppato tutto il traffico dall'esterno ad eccezione di quello su porta 80

iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -j DROP

a questo punto si puo' installare il demone per il Port Knocking con

apt-get install knockd

una volta installato il demone non parte in autoesecuzione. Per prima cosa si deve configurare il comportamento dal file /etc/knockd.conf

I numeri della sequenza dovranno esssere specifici per la macchina in uso in quanto corrispondono alla chiave per attivare/disattivare il servizio (non e' necessario che la chiave per disattivare il servizio sia la medesima ma invertita  di quella per attivarlo). Ogni numero corrisponde ad una richiesta su una porta differente (attenzione, se c'e' a monte un firewall che prefiltra il traffico il trucco del port knocking potrebbe non funzionare)

------------------------------------------------------------------------
[options] 

 UseSyslog 

 [openSSH] 

 sequence = 1234,5678,9101 

 seq_timeout = 5 

 command = /sbin/iptables -A INPUT -s %IP% -p tcp --dport 22 -j ACCEPT 

 tcpflags = syn 

 [closeSSH] 

 sequence = 1019,8765,4321 

seq_timeout = 5
command = /sbin/iptables -D INPUT -s %IP% -p tcp --dport 22 -j ACCEPT 

 tcpflags = syn

------------------------------------------------------------------------

come si vede la regola di iptables semplicemente apre la connessione sulla porta 22 per l'ip da cui e' stata riconosciuta la giusta sequenza di bussate. 

Per mandare il servizio in esecuzione automatica si deve settare ad 1 START_KNOCKD in /etc/default/knockd (oppure si avvia a mano il servizio con service knockd start)

fatto partire il servizio si puo' sperimentare con il client

Il comando apt-get install knockd installa oltre al server anche il client per cui si puo' ripetere l'installazione sulla macchina da cui ci si vuole connettere

il comando e' il seguente. Vengono concantenati insieme il  knock porting e l'avvio della sessione SSH

knock ip_server 1234 5678 9101 && ssh luca@ip_server

SSH su TIM Mobile

Dopo un po' di tempo che non amministravo server Linux mi sono ritrovato con nuove macchine da gestire. Dato che sono sempre a giro oramai mi connetto quasi sempre via cellulare. Usando una scheda TIM per una connessione SSH mi sono spesso trovato disconnesso dopo pochi secondi (questo difetto e' sostanzialmente indipendente dall'hardware usato)

dopo un po' di ricerche su Internet ho trovato che questo malfunzionamento era segnalato da tempo su ADSL Telecom e la soluzione suggerita era di aggiungere il parametro ServerAliasInterval come segue

ssh user@host -o ServerAliveInterval=15

l'indicazione e' risultata valida anche per le connessioni mobile per cui adesso riesco ad usare SSH con TIM senza disconnessioni

Evadere da un proxy server 2 (la vendetta)

In un precedente post avevo scritto dei tentativi falliti di evadere dal http proxy server aziendale

Ovviamente non mi sono scoraggiato ed ho trovato un nuovo software Shellinabox che crea un server http su cui instrada una shell ssh mediante una interfaccia Ajax....poteva essere la soluzione per fregare il server proxy che instrada solo connessioni http legittime
si installa tramite il classico
apt-get install shellinabox

poi si edita il file di configurazione per il bucare il server proxy su una porta permessa (la 443 https)
nano /etc/default/shellinabox
in giallo l'ip della macchina

# TCP port that shellinboxd's webserver listens on 

SHELLINABOX_PORT=443

 # specify the IP address of a destination SSH server 

SHELLINABOX_ARGS="--o-beep -s /:SSH:150.xxx.xxx.xxx"

a questo punto si creano le chiavi per la connessione SSL

cd /var/lib/shellinabox
openssl genrsa -des3 -out server.key 1024
openssl req -new -key server.key -out server.csr
cp server.key server.key.org
openssl rsa -in server.key.org -out server.key
openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt
cat server.crt server.key > certificate.pem

si riavvia il servizio per le nuove impostazioni

service shellinabox reload

e si fa puntare il browser del client interno all'http proxy all'indirizzo https://150.xxxx.xxx.xxx, si accettano le eccezioni del certificato SSL e ci si trova di fronte alla shell ssh

Come si vede il login di root non e' permesso (nonostante il server ssh abbia PermitLoginRoot Yes) ma cio' puo' essere positivo

Si puo' obbiettare sulla falla di sicurezza che questo servizio puo' creare ed in questo senso puo' essere intelligente metterlo su una macchina destinata solo a fare da ponte verso l'esterno senza servizi critici e di produzione installati

in conclusione Missione Compiuta

Evadere da un proxy server

Per motivi di lavoro passo molto tempo dietro un http proxy server. La macchina di frontiera filtra tutto il traffico lasciando aperte solo la porta 80 e 443 effettuando anche content filtering (basato piu' che altro su una lista di domini ammessi/non ammessi senza entrare a leggere il contenuto vero e proprio dei pacchetti)

Visto che qualche volta (qualche spesso...) mi devo collegare in SSH a macchine esterne e non volendo sempre usare la connessione cellulare ho provato a forzare il blocco

La tecnica prevista consisteva nel predisporre una macchina esterna con ip statico e pubblico con il server SSH in ascolto non sulla porta standard 22 ma sulla 80 in modo da poter attraversare il proxy ed una volta all'esterno rimandare poi sulle macchine di interesse.

Dopo una mezza giornata di tentativi ho desistito. Il proxy server intercetta tutte le chiamate negando l'accesso all'esterno sia usando Putty su Windows che ssh da shell su Linux e Mac. A questo punto mi sono reso conto che la macchina di frontiera non fa solo il controllo sull'intestazione dei pacchetti ma anche all'interno degli stessi (non ho ben chiaro come fa ma di fatto lo fa). Sono quindi ancora prigioniero del proxy
I miei complimenti all'amministratore del sistema centrale (che poi mi deve spiegare perche' nega le connessioni ssh e poi permette il traffico su tutta una serie di siti quali Facebook, Youtube e compagnia dicendo)

SSH ed XForwading

Normalmente SSH viene usata per l'amministrazione remota a livello di shell
E' possibile instradare anche una connessione criptata del server X mediante SSH

per avviare lato client l'XForwarding e' sufficiente aggiungere lo switch -X

da una macchina Linux e' possibile scrivere
ssh -X luca@xxx.xxx.xxx.xxx

una volta effettuato il login ci si trova in shell senza che apparentemente ci sia stato un effetto dello switch -X. Se pero' si lancia un applicativo X (tipo gedit) si vedra' comparire lato client la finestra di Gedit...da notare bene che questa applicazione sta girando sul server remoto per cui gli eventuali file saranno salvati sul disco fisso remoto
Se invece di un applicativo si vuole interagire con tutto il desktop e' sufficiente digitare
gnome-session
per aprire (per esempio) il desktop di Gnome

Una sessione X remota su Mac Os X

Un aspetto curioso e' che quanto descritto funziona anche su Mac OS X  a patto di avere installato il pacchetto X11

Gedit in sessione remota su Mac Os X

Gedit in sessione remota su Mac Os X (da notare che il salvataggio e' sul disco del server remoto)

Quanto descritto e' stato testato, senza modifiche al demone del server ssh, sia su Ubuntu 14.04 che su Debian 7

Amministrare macchine sotto NAT

In alcuni casi puo' risultare necessario amministrare macchine che risultano dietro un router che fa NAT e quindi non hanno un indirizzo pubblico (ne' statico ne' dinamico) ma solo un indirizzo privato (si presentano su Internet con il solo indirizzo del router)

Un trucco puo' essere quello di configurare il router per fare port forwarding verso il client interno ma su alcuni reti (vedi quelle della telefonia mobile o Fastweb) cio' non e' possibile

In questi casi si puo' procedere con due metodi usando in entrambi i casi una reverse shell in cui la connessione e' iniziata dalla macchina nattata (questo permette di attraversare tranquillamente il router/firewall poiche' di solito le connessioni sono praticamente sempre filtrate solo dall'esterno verso l'interno)

Netcat
Su una macchina con indirizzo pubblico si digita (ovviamente non ci devono essere gia' server che sfruttano la porta 8080)
netcat -lvp 8080a questo punto dalla macchina nattata si digita

netcat -e /bin/sh ip_esterno 8080
a questo punto digitando i comandi sulla shell della macchina con ip pubblico si riescono ad eseguire i comandi sulla macchina nattata

SSH 
Supponiamo di avere una macchina con indirizzo pubblico su cui gira un server SSH ed un account su questa macchina (
Dalla macchina nattata si puo' digitare
ssh -R 8080:localhost:22 nome@ip_esterno

dalla macchina con ip pubblico si digita dove l'utente e la corrispettiva password sono quelle della macchina nattata

ssh utente1@localhost -p 8080

a questo punto i comandi digitati sulla macchina con ip pubblico vengono sulla macchina nattata

In tutto cio' c'e' un problema. Per effettuare il collegamento si deve interagire prima con la macchina nattata per poter aprire la connessione. Ma come si fa se questa e' irraggiungibile?? La soluzione, escludendo l'intervento umano di un collega sul posto, puo' essere quello di uno script in cron che lanci il comando a determinati intervalli. Se l'altro capo della comunicazione non e' pronto semplicemente la connessione viene interrotta, altrimenti inizia l'amministrazione remota

Editare file su server remoti

Accade spesso di dover editare file testo su server remoti. Al posto di spostare il file in locale, editarlo e poi ripassarlo sul server via SSH puo' essere comodo montare il filesystem remoto mediante SSHFS

su Debian di deve installare
apt-get install sshfs

si crea poi una directory
mkdir /mnt/remota

e si monta con
sshfs luca@150.217.xxx.xxx:/home/luca /mnt/remota

a questo punto in /mnt/remota troveremo i file remoti posti nella directory /home/luca e si editano direttamente i file remoti

per smontare la risorsa
fusermount -u /mnt/remota

di default questa operazione puo' essere effettuata solo da root. Per permettere ad un utente normale di usare sshfs si deve aggiungere al gruppo fuse (se si cerca di montare la risorsa remota via sshfs senza i permessi si ha il messaggio Transport Endpoint is not connected)

chgrp fuse /usr/bin/fusermount 

chmod u+s /usr/bin/fusermount 

adduser nomeutente fuse

SSH Client su Mac Os X

Per ottenere un client SSH su Mac Os X si puo', una volta aperto Terminale, andare nel menu Shell ed creare Nuova Connessione Remota dove impostare i parametri del server SSH

altrimenti rimane sempre valido da shell di Terminale digitare

ssh luca@xxx.xxx.xxx.xxx