Bruno Mendola

… un tunnel SSH! XD

OK, spiegazione!
Scenario:

1. una rete informatica dietro firewall e/o proxy, che impedisce le connessioni verso determinate porte all’esterno (ma che lascia libera almeno una porta, altrimenti non c’è soluzione);
2. un’applicazione che dovrebbe connettersi ad un server esterno, ma che viene bloccata da queste limitazioni;
3. una persona che ha veramente bisogno di utilizzare questa applicazione!!

Il programma in questione potrebbe essere un browser web, nel caso in cui non si volesse essere osservati dal proxy aziendale mentre si naviga, oppure un programma di posta elettronica, come Outlook o KMail, oppure un programma di chat, come Messenger o IRC, oppure un gioco online come World of Warcraft, Dark Age of Camelot o altri.

La soluzione a tutti i problemi di questo tipo si chiama TUNNEL SSH: per metterlo a punto serve un computer esterno al quale collegarsi, che abbia un server SSH in esecuzione (tutte le distribuzioni Linux lo hanno nella dotazione di default).

Praticamente succede qualcosa di simile a questa immagine:

Come realizzare questa configurazione? E’ facilissimo!
Ovviamente suppongo che su my.workplace.com abbiate a disposizione una macchina con una distribuzione GNU/Linux, nel mio caso Ubuntu (con Windows si potrebbe pure fare, ma… non mi interessa :)).

Dando per scontato che il server SSH su my.home.it funzioni correttamente, operiamo sulla macchina my.workplace.com.

Cominciamo aprendo un terminale (konsole, xterm o equivalenti).

Prima di tutto dovete sapere verso quale server volete connettervi e la porta (in questo caso other.server.com_, porta 25 perchè ipotizziamo che sia un server di posta in uscita).
Per conoscere l’IP e la porta giusta potete avviare il programma bloccato (che comunque al momento non potrà connettersi) e lanciare il comando netstat, in questo modo:

$ sudo netstat -vatnp

….

tcp  0  1 172.28.200.105:36687 89.238.64.166:25  SYNSENT  9334/kmail

….

Poi…

$ sudo iptables -t nat -A OUTPUT -d 89.238.64.166 -j DNAT --to 127.0.0.1
[sudo] password for user: *******

$ sudo ssh -L 25:89.238.64.166:25 username@my.home.it
username@my.home.it's password: *********

NB: nella mia macchina ho Ubuntu, quindi ho dovuto utilizzare sudo per eseguire quei comandi con i permessi di amministratore. Nelle altre distribuzioni dovrete semplicemente eseguire i suddetti comandi come utente root.

Il primo comando dice al sistema operativo di effettuare una deviazione di tutti i pacchetti diretti al server esterno, rinviandoli invece alla macchina locale (127.0.0.1) che, non passando dal firewall, risulterà raggiungibile sulla porta 25.
Il secondo comando avvia finalmente il tunnel SSH, aprendo la porta 25 in ascolto su localhost, collegata tramite il tunnel (quindi, tramite il computer my.home.it) alla porta 25 del server esterno other.server.com :)

NB: nel caso in cui la porta 22 (quella di SSH) risultasse anch’essa bloccata, sarà necessario modificare la configurazione del server SSH su my.home.it, mettendolo in ascolto su una porta che è possibile raggiungere da my.workplace.com.

Adesso potete lanciare il programma che precedentemente risultava bloccato e… magia! :)

Sicuramente la velocità non sarà quella di una linea ADSL, perchè sarà comunque limitata dalla banda in upload disponibile su my.home.it.
Inoltre questa tecnica non può funzionare con i programmi peer to peer, come Bittorrent o eMule, perchè sebbene si colleghino ad un server unico per ottenere le informazioni sui file da scaricare (nel caso dei torrent il server si chiama tracker), il resto della comunicazione avviene da e verso una miriade di altri computer (i peer), di cui è impossibile prevedere l’indirizzo IP.

Qualche giorno fa mi è arrivata una mail automatica dal mio provider di hosting, che mi segnalava la prossimità dell’esaurimento dello spazio su disco riservato al mio account…
3 GB di disco quasi pieni?!? La cosa mi è sembrata subito assurda, perchè un sito web con blog e alcune pagine non può occupare tutto questo spazio!! Ho pensato che probabilmente mi sfuggiva qualche particolare del comportamento di Rails…

ebbene, ho scoperto che 2 GB di spazio erano occupati dai file temporanei che Rails utilizza per memorizzare le sessioni di ogni utente che accede al sito!

Questi file dal nome ruby_sess.QUALCOSA sono contenuti nella directory tmp/sessions all’interno della root dell’applicazione Rails.
File temporanei, che nella maggior parte delle volte sono utili solo per pochi secondi, il tempo di caricare una pagina, dopo di che andrebbero eliminati. Certo, con cautela, perchè alcuni possono essere realmente importanti (come le sessioni degli utenti attualmente connessi al sito).

La soluzione che ho adottato è stata quella di cancellare giornalmente, nottetempo, tutte le sessioni più vecchie di 2 giorni, giusto per essere sicuro di non togliere il pavimento da sotto i piedi di nessuno :)

Ho schedulato su cron questa operazione di pulizia, con un semplice comando:

$ crontab -e

per entrare nel crontab in modalità modifica, e poi ho aggiunto la riga

0 4 * * * find ~/rails-app/tmp/sessions -type f -name 'ruby_sess*'
-ctime +2 -exec rm -f {} \;

(tutto su una riga): in questo modo ogni notte alle 4:00 viene avviata una ricerca su tutti i file (-type f) nella directory ~/rails-app/tmp/sessions il cui nome inizia con il prefisso ‘ruby_sess’, che siano più vecchi di 2 giorni (-ctime +2). Ogni risultato di questa ricerca viene finalmente eliminato (-exec rm -f {} \;)

Sospiro di sollievo! =)

La nuova Ubuntu 8.10 Intrepid Ibex ha adottato l’ultimissima versione di OpenSSH, la 5.1, che ha una feature interessantissima: la possibilità di automatizzare il chroot di una sessione SFTP.

In pratica, l’utente che effettua il login tramite SFTP avrà la possibilità di vedere soltanto la sua home directory (o la directory impostata come chroot), senza poter risalire le directory fino alla root, come invece accade normalmente.
Utilissimo nel caso in cui si voglia dare la possibilità ad un utente di effettuare degli upload su una directory accessibile anche dal web, ma non gli si vuole lasciare la libertà di girovagare per tutto il sistema.
Con le versioni precedenti di OpenSSH, per fare la stessa cosa, era necessaria una procedura lunghissima.

Andiamo all’_how-to_:

1) installare il server SSH, se non è già installato

$ sudo apt-get install openssh-server

$ sudo vim /etc/ssh/sshd_config

2) modificare il file di configurazione in questo modo:

Subsystem       sftp    internal-sftp

# Queste righe andranno aggiunte  alla *fine* del file di configurazione
Match Group uploaders
	ChrootDirectory %h
	ForceCommand internal-sftp
	AllowTcpForwarding no

3) creare un utente uploader ed aggiungerlo al gruppo uploaders:

sudo adduser --home /var/www/uploads --no-create-home \
	--ingroup uploaders \
	--shell /bin/false \
	uploader

4) controllare che il proprietario della home directory del nuovo utente (e delle directory che risalgono il percorso, fino alla radice) sia root e che nessun altro utente o gruppo abbia permessi di scrittura su tale directory (impostarli a 755 con chown). Se questa condizione non viene soddisfatta, il login SFTP fallirà.

Risultato: l’utente uploader potrà entrare via SFTP e operare soltanto sulla sua home directory; il login SSH invece non sarà possibile.

PS: purtroppo questo metodo non è implementato sulla versione di OpenSSH presente sull’ultima LTS di Ubuntu, la 8.04 Hardy Heron… significa che i più prudenti dovranno attendere fino al 2010 per la prossima LTS.

Mi è capitato di dover schedulare il backup settimanale su un server web LAMP (Linux + Apache + MySQL + PHP), di cui bisognava salvare il contenuto del database ed i file caricati in una directory tramite upload.

Ho pensato subito a cron, un demone (cioè un processo in background) che funge da agenda per mettere in coda dei comandi da eseguire a date ed orari prestabiliti.

Per modificare la lista dei comandi schedulati (detta crontab), c’è appunto il comando

$ crontab -e

Le voci vanno inserite una per riga, nel formato

minuti ore giorno_del_mese mese giorno_della_settimana comando

quindi, ad esempio, per eseguire lo shutdown della macchina ogni giorno all’una di notte, basterà scrivere nel crontab

0 1 * * * shutdown -h now

Torniamo al problema iniziale: archiviare una copia del database e della directory degli upload, una volta alla settimana (domenica a mezzanotte).

Per il database, utilizziamo mysqldump e gzip:

$ mysqldump --opt -uUSER -pPASSWORD DATABASE | \
gzip -9 > /backup/`date -I`_db.sql.gz

l’opzione

--opt

è un alias per tutte queste opzioni:

--add-drop-table --add-locks --create-options --disable-keys \
--extended-insert --lock-tables --quick --set-charset

utili per bloccare momentaneamente lo stato corrente del database e salvarlo integralmente senza metterne in pericolo la coerenza.

Il comando

`date -I`

restituisce una stringa con la data corrente, nel formato AAAA−MM−GG.

Per i file utilizziamo tar e gzip con qualche opzione simpatica:

$ tar cfPpz /backup/`date -I`_uploads.tar.gz /var/www/uploads

Mettiamo i comandi appena descritti in un bellissimo script bash (backup.sh):

#!/bin/bash

tar cfPpz …

mysqldump …

chmod 400 /backup/`date -I`_*.gz

e spostiamolo sotto la home dell’utente root (se non lo è già), dando tutti i permessi al solo proprietario (visto che ci sono le password scritte in chiaro):

# mv backup.sh /root
# chown root:root /root/backup.sh
# chmod 700 /root/backup.sh

(NB: ho utilizzato una shell di root, ma ovviamente su Ubuntu si deve utilizzare sudo per eseguire i comandi come super-user)

Infine modifichiamo il crontab dell’utente root :

# crontab -u root -e

0 0 * * 0 ~/backup.sh > /dev/null 2>&1

Ok, il backup verrà effettuato automaticamente ogni domenica a mezzanotte.

Qualora succedesse qualcosa di grave, per ripristinare un backup basterà eseguire:

# tar xfPpz /backup/DATA_uploads.tar.gz

# gunzip < /backup/DATA_db.sql.gz | mysql -uUSERNAME -pPASSWORD DATABASE

Si fa prima a farlo che a dirlo :)

I programmatori web di Microsoft si ostinano a voler limitare l’accesso alle loro web application controllando il parametro “User Agent” inviato dal browser ad ogni richiesta HTTP; dovrebbe essere una stringa che identifica univocamente il software di navigazione in uso e la sua versione.

Il problema è che, come spesso succede, i programmatori M$ non si sono preoccupati di garantire il funzionamento per i browser diversi da Internet Explorer.
Ad esempio, ad alcune versioni di Firefox è impedito di accedere a tutte le funzionalità di Windows Live Mail (ex Hotmail), anche se avrebbe tutte le carte in regola (leggi supporto agli stadard W3C migliore di quello di IE) per poter far girare correttamente tutti gli script del sito in questione.

Il secondo problema (che comunque sarebbe risolto da una migliore competenza dei programmatori di zio Bill) è che le versioni di Firefox installate tramite i pacchetti precompilati delle distribuzioni Linux (come Fedora 9), inviano una stringa supplementare come suffisso allo User Agent, che identifica la distribuzione in uso (il cosiddetto Vendor). Ne consegue che lo script dei siti Microsoft che si dovrebbe occupare di stabilire la compatibilità del browser… si confonde! Quindi risulta possibile utilizzare soltanto una vecchia versione limitata di Windows Live Mail, anche se Firefox 3 funzionerebbe perfettamente.

Il messaggio visualizzato sulla prima pagina del servizio è:

Versione classica di Windows Live Hotmail
Questa versione è più adatta al browser in uso. La versione completa di Windows Live Hotmail può essere eseguita in Internet Explorer 6.0 e versioni successive. Prima di installarla, verifica i requisiti di sistema. La versione completa può inoltre essere utilizzata in Firefox 2.0.

Ok, adesso risolviamo il problema:

1. nella barra dell’indirizzo di Firefox digitare “about:config” (senza virgolette)
2. se spunta un avvertimento che mette in guardia sui possibili pericoli blablabla… andate avanti! :)
3. nella casella Filtro digitare “useragent.vendor” (sempre senza virgolette), vedrete spuntare 2 voci
4. fare doppio-click su ognuna delle voci e cancellare i valori (qui sono “Fedora” e “3.0.1-1.fc9”), cliccando poi su OK
5. chiudere la pagina di configurazione
6. ricaricare Windows Live Mail dall’indirizzo mail.live.com e… utilizzare finalmente la versione “moderna” :)

Per coloro i quali si stanno scandalizzando perchè ho dedicato un post ad un prodotto M$: sappiate semplicemente che io ODIO le limitazioni! :P