La macchina remota ha IP 192.168.1.2 con SSH in esecuzione sulla porta non standard 12345

ssh -p12345 -L 3333:localhost:5432 root@192.168.1.2

A questo punto la connessione può essere attivata sulla macchina locale collegandosi alla porta 3333, in questo modo si accede al server remoto.

Se è capitato anche a voi di vedere qualche simpaticone scaricare tutto il vostro sito a caccia di indirizzi email, forse vi sarà venuta voglia di impedirgli di fare danni intasando la banda (che si paga cara!) e magari trovando veramente gli indirizzi email lasciati da qualche incauto.

Un minimo di teoria

Per cercare gli indirizzi email contenuti nelle pagine di un sito, gli spammer utilizzano dei programmi che “scaricano” tutte le pagine di un sito seguendone i collegamenti interni, e le analizzano in cerca di stringhe (sequenze di caratteri) che possano assomigliare a degli indirizzi di posta elettronica.

Quando li trovano, li memorizzano e li usano per sommergervi di posta-spazzatura.

I programmi usati dagli spammer sono spesso (purtroppo non sempre) riconoscibili da particolari stringhe che li identificano, queste stringhe di connessione sono simili ma non identiche a quelle che i normali browser mandano quando si collegano al vostro server.

Mod_rewrite: il coltellino svizzero degli URL

Se il vostro server web è il diffusissimo Apache, questo dispone di un modulo (quasi sempre installato di default) che permette di manipolare gli indirizzi in vario modo, anche tramite istruzioni condizionali che analizzano le stringhe di connessione.

Ammesso che mod_rewrite sia correttamente installato, è quindi sufficiente inserire alcuni comandi nel file .htaccess per redirigere gli spammer su una pagina alternativa.

Ecco un esempio di configurazione:


# attiva il motore
RewriteEngine On

RewriteCond %{HTTP_USER_AGENT} Extractor [OR]
RewriteCond %{HTTP_USER_AGENT} ^EmailSiphon [OR]
RewriteCond %{HTTP_USER_AGENT} ^EmailWolf [OR]
RewriteCond %{HTTP_USER_AGENT} ^ExtractorPro [OR]
RewriteCond %{HTTP_USER_AGENT} ^Mozilla.*NEWT [OR]
RewriteCond %{HTTP_USER_AGENT} ^Crescent [OR]
RewriteCond %{HTTP_USER_AGENT} ^CherryPicker [OR]
RewriteCond %{HTTP_USER_AGENT} ^[Ww]eb[Bb]andit [OR]
RewriteCond %{HTTP_USER_AGENT} ^NICErsPRO [OR]
RewriteCond %{HTTP_USER_AGENT} ^Telesoft [OR]
RewriteCond %{HTTP_USER_AGENT} ^Zeus.*Webster [OR]
RewriteCond %{HTTP_USER_AGENT} ^Microsoft.URL [OR]
RewriteCond %{HTTP_USER_AGENT} ^Mozilla/3.Mozilla/2.01 [OR]
RewriteCond %{HTTP_USER_AGENT} ^EmailCollector
RewriteRule .* nospam.html [L]


In questo caso la pagina alternativa è nospam.html, qualsiasi pagina venga richiesta da un client che si identifica con una delle stringhe intercettate dalle espressioni regolari inserite sopra, viene automaticamente rediretto sulla pagina nospam.

Vendetta, tremenda vendetta!

Una possibile ritorsione, potrebbe essere quella di creare dinamicamente una pagina ricca di collegamenti e indirizzi email che puntino all’indirizzo IP dello spammer, in questo modo si potrebbe per lo meno infastidirlo (se il programma che usa non è abbastanza furbo da indovinare il trucco).

A seconda della configurazione i prezzi possono cambiare anche parecchio, il mio cliente ha scelto la configurazione “basic” che prevede una non meglio specificata priorità 5 nell’uso di RAM e CPU.

Confesso che ero sinceramente interessato a provare Virtuo, tanto da aver più volte meditato se acquistarne uno io stesso, ma purtropo dopo poco più di dieci minuti sul server, mi sono reso conto dello scampato pericolo.

Chi va piano…

L’antico motto non si applica purtroppo anche alla new economy, semmai è stato sostituito dall’adrenalinico Smaller Faster Cheaper Better, purtroppo il Virtuo si è subito rivelato più lento di una qualsiasi ADSL alice, mi sembrava di essere tornato ai tempi dei modem a 56K.

Leggendo qui e là

Mi sono accorto che la mia opinione su Virtuo è piuttosto condivisa: Il Mega Flop di NGI VIRTUO Virtual Server


./configure --with-interbase --with-mysql=/usr --with-ming=/usr --with-png-dir \
--with-jpeg-dir=/usr/local/src/jpeg-6b --with-zlib-dir --with-gd \
--with-flatfile \
--enable-exif --with-ttf --with-freetype-dir=/usr/include/freetype2 \
--with-t1lib --enable-gd-native-ttf --enable-debugger \
--enable-mbstr-enc-trans --with-iconv --with-pgsql --enable-dbase \
--enable-force-cgi-redirect
make clean
make install
service httpd stop
service httpd start


Vuoi scaricare dalla rete parecchi dati, magari stai scaricando le ISO della tua distribuzione Linux preferita. Questa operazione durerà diverse ore. Per scaricare i dati stai usando, diciamo, Firefox.
Hai un portatile ed é in rete con altri computer. Puoi usare i computer della rete per fare il download.

Ti connetti su un computer della rete (usando magari ssh) e lanci
il server di VNC vncserver.
Questo farà partire un desktop su quella macchina. Dopodiché fai partire il visualizzatore di VNC vncviewer sul tuo portatile, specificando il server VNC a cui ti vuoi connettere (in questo caso quello che hai appena fatto partire). A questo punto sei connesso al desktop remoto e potrai lanciare Firefox e tutte le applicazioni che vorrai. Potrai chiudere il vncviewer ed andartene.
La prossima volta che ti riconnetterai col vncviewer a quel server VNC ritroverai il desktop come l’avevi lasciato l’ultima volta ammesso che il server VNC non sia stato terminato nel frattempo .

Esempio di sessione GNOME con un vncviewer che mostra un desktop XFCE in cui si vede il browser Firefox  – beh, detta così sembra le scatole cinesi

Come fare nel dettaglio

Inizializzazione del server VNC

Supponiamo che l’utente che utilizzi per tutto l’esperimento sia dan e che il computer su cui farai partire il server si chiami mela. Il desktop che farai partire con vncserver apparterrà quindi all’utente dan.

Ecco l’esempio della sessione:

dan@uva > ssh dan@mela
dan@mela password:
dan@mela > vncserver
You will require a password to access your desktops.
Password: *****
Verify: *****
New 'mela:1 (dan)' desktop is mela:1
Creating default startup script /home/dan/.vnc/xstartup
Starting applications specified in /home/dan/.vnc/xstartup
Log file is /home/dan/.vnc/mela:1.log

Analizziamo cosa é successo:

• Ti sei connesso su mela con ssh.
• Hai lanciato vncserver, il quale ti ha chiesto una password. Questa password ti verra chiesta ogni volta che ti connetterai al server.
• vncserver ti ha detto che mela:1 sarà il desktop (o display) a cui potrai contattarlo col client.
• vncserver ha creato, essendo la prima volta che lo lanci, una directory /home/dan/.vnc e dentro ci ha messo alcuni file di utilità:
  • mela:1.log: il log del server. Se per qualche motivo non dovesse partire il server, in questo file é scritto il perché.
    Questo file viene ricreato ad ogni lancio del server.
  • mela:1.pid: con l’ID del processo del server.
    Questo file viene ricreato ad ogni lancio del server.
  • passwd: con la password (cifrata) che hai fornito.
  • xstartup: lo script di inizializzazione con cui viene lanciato il server VNC.
    Il server VNC é a tutti gli effetti un server X, ed é in grado di far partire qualsiasi ambiente grafico desideri.
    Di default parte con uno scarno twm. Se sostituisci l’ultima linea del file e ci metti startxfce4 invece di twm (non togliere il carattere & mi raccomando!) avrai qualcosa di più evoluto.

A questo punto puoi passare ad usare il client.

Uso del client VNC

A questo punto su mela sta girando un ncserver.
Fai partire il client vnc. Se vuoi lanciarlo a linea di comando é molto semplice, il comando si chiama:
vncviewer
Ti chiederà il VNC server (nel caso dell’esempio
mela:1) e Password, quella che hai fornito la prima volta che hai fatto partire il server.

Chiusura di una sessione di lavoro

Se vuoi sospendere la sessione, per poi riprenderla successivamente, ripartendo da dove eri arrivato l’ultima volta a lavorare sul desktop,
é sufficiente che tu chiuda l’applicazione vncviewer.

Se vuoi terminare definitivamente la sessione, terminando anche il server VNC, devi usare il comando vncserver con l’opzione -kill sulla macchina su cui hai fatto partire il server VNC.
Quindi:

dan@uva > ssh dan@mela
dan@mela's password:
dan@mela > vncserver -kill :1
Killing Xvnc process ID 4838


NOTA: se usi il bottone di Logout del desktop remoto il server VNC finirà in uno stato indeterminato e dovrai uccidere il server con vncserver -kill :1.

Uso avanzato del server VNC

Cambiare la password del server VNC

Per cambiare la password del server devi connetterti sulla macchina su cui gira il server e lanciare il comando

vncpasswd:
dan@uva > ssh dan@mela
dan@mela's password:
dan@mela > vncpasswd
Password:
Verify:

NOTA: Questo comando non chiede la vecchia password, si fida del fatto che sei l’utente dan (sei stato autenticato dal sistema al login).

Server VNC multipli

Se vuoi puoi far partire diversi server sulla stessa macchina, magari con utenti diversi. VNC é in grado di gestire questa situazione assegnando ad ogni server un display diverso: mela:1 mela:2 e così via…

Puoi anche decidere di far partire un server sul display che decidi tu,
per esempio il 20:

dan@uva > ssh dan@mela
dan@mela's password:
dan@mela > vncserver :20


Dimensione del desktop per il Server VNC

Se hai un monitor piccolo, quando usi il vncviewer può essere antipatico avere un server con un desktop troppo grosso: continueresti ad usare le barre di scorrimento per accedere a tutta l’area visibile. In questo caso puoi far partire il server con le dimensioni del desktop che preferisci, nell’esempio 800×600:

dan@uva > ssh dan@mela
dan@mela's password:
dan@mela > vncserver -geometry 800x600

In questo caso vedrai che la finestra del vncviewer sarà ridotta rispetto al default.

Condivisione del desktop per il Server VNC

Questa funzionalità é sicuramente una tra le più impressionanti,
consente a più utenti simultaneamente di accedere allo stesso desktop.
Quello che fai tu da un client lo vedono tutti dagli altri client.
Questo tipo di modalità é particolarmente utile per mostrare applicativi al lavoro a più persone contemporaneamente.
Tutte le persone sui client possono fare tutto e il primo che muove il
mouse prende "il controllo".

Ci vuole armonia

Ecco come lanciare il server:

dan@uva > ssh dan@mela
dan@mela's password:
dan@mela > vncserver -alwaysshared

NOTA: Uno scenario tipico per questa modalità
é quello in cui alcuni client accedono al server attraverso internet.
Bisogna considerare i seguenti problemi di sicurezza:

• la password con la quale ci si connette al server VNC viaggia in chiaro
• il protocollo usato da VNC per la comunicazione client/server non è cifrato ma in chiaro.

Queste problematiche di sicurezza possono essere risolte usando
ssh.