Stampa e tunnel criptati micro HOWTO

(ovvero HOWTO*10^-6)



Autore: ZioPino metaluxisdn@tiscalinet.it

Data stesura: 02.10.2002

Data modifica: 22.10.2002

Versione originale documento: 0.1c

Versione modificata: 01d

Licenza d'uso: GPL

( for more information see: http://www.gnu.org/licenses/gpl.html )



Contenuti:


  1. Perché un altro HOWTO sulla stampa

  2. Strumenti sw provati ed utilizzati

  3. Casi della vita

  4. Note “a latere”

  5. Appendici



I) Perché un altro HOWTO sulla stampa


Di certo non se ne sentiva il bisogno; tuttavia ho voluto mettere a disposizione di quei (pochi) che ne avessero bisogno tutte le esperienze fatte da me su lavoro per quanto riguarda i canali criptati e le stampe in remoto.

L'esigenza nasce dalla necessità di connettersi dalla rete pubblica ad un server (unix o windows indifferentemente) utilizzare una applicazione residente sul server (anche con logica client-server) e stampare sulla stampante fisicamente connessa al client o su di una stampante alla quale l'utente del client possa facilmente accedere. Il tutto con la sicurezza che deriva dall'uso di un canale criptato e quindi ragionevolmente al sicuro da potenziali e maliziosi “sniffamenti”.




II) Strumenti sw provati ed utilizzati


Strumenti free con licenza GPL


OpenSSH (shell remota criptata)

Credo che non ci sia bisogno di presentazione. Anche se periodicamente questo demone è afflitto da bachi o da troiani resta il non plus ultra delle shell remote criptate


OpenSSH per Unix/linux http://www.openssh.org

OpenSSH per Windows http://www.networksimplicity.com/openssh


ZebeDee (tunnelling criptato per tcp/udp)

Grandissima utility che premette veramente di tutto. E' simile (nello spirito) a CIPE ma in user space (quindi è più semplice da configurare ed installare) e dalla funzionalità ottima sia in Windows che in Unix/linux.


ZeBeDee per Windows/Unix http://www.winton.org.uk/zebedee


rlpr (un client enhanced per lpd)

Un'altra utility salvavita. Si comporta come lpr con in più la possibilità di indirizzare stampanti remote non descritte in /etc/printcap e di interagire con demoni lpd che possono rispondere anche su porte diverse da 515/tcp.


rlpr per Unix ftp://truffula.com/pub/rlpr-2.04.tar.gz


rdesktop (Terminal client)

Un piccolo Terminal client tutto sommato usabile


rdesktop per Unix/Linux http://www.rdesktop.org/


Strumenti free con licenza BSD


Putty (telnet-ssh client per Windows)

Il client telnet free per eccellenza


Putty + plink http://www.chiark.greenend.org.uk/~sgtatham/putty


Strumenti a pagamento con licenza proprietaria


SmarTerm (telnet-ssh client + LPD server)

Client telnet e (da poco) anche ssh il cui unico pregio è quello di fornire nel prezzo pagato anche un demone lpd per Windows con discrete funzionalità.


SmarTerm http://www.esker.com/esker_com/products/smarterm_home.html



III) Casi della vita

Sono un strenuo sostenitore del metodo socratico, perciò elencherò una serie (il più possibile esaustiva) di casi pratici cercando di spiegare più chiaramente possibile le soluzioni da me adottate per la risoluzione del problema.


1) Servente host NT/W2000 con IP statico + client W9x/Me/XP/2000 con stampante fisicamente connessa al client. L'applicazione sia residente sull'Host


La situazione è schematizzata al meglio dal seguente grafico:


   [host/server]NT/W2000 +APP <=====> [client] W9x/Me/XP/2000--> [printer]
        IP = 10.0.0.10 (statico) | IP = ? (fornito dal provider)
                                 +
                     rete pubblica (insicura)
                                 +
                        tunnelling criptato

La nostra necessità è naturalmente utilizzare l'applicazione sull'host e stampare sul client veicolando il tutto con un tunnel criptato.


Soluzione a)

Uso di Terminal server + OpenSSH su [host/server] e Putty + Terminal client su [client]


Configurazione del canale criptato:



Esempio

Se sull'host il servizio Terminal Server sta su 163/TCP sul client basterà lanciare, a connessione con il provider avvenuta, il seguente comando (uso plink data la sua affinità con il comando unix ssh):

plink -ssh -L 163:10.0.0.10:163 10.0.0.10

Ovviamente le porte possono essere anche diverse i.e. -L 3000:10.0.0.10:2048 e così via, basta solo ricordare che il primo valore rappresenta la porta locale (ossia quella sul client) mentre l'ultimo rappresenta la porta sul server che interessa veicolare.

A questo punto tutto quello che ci resta da fare è lanciare sul nostro client il Terminal client e usando come host il localhost (127.0.0.1) e come porta quella che ci ci siamo scelta (163, 3000 etc)

per vederci comparire la login di NT/W2000 e lanciare il nostro utente e le nostre app.

E la stampante? Bè in questo caso Zio Bill ci fa un regalo (lo so non è da lui ma forse gli è scappato :)) il protocollo Terminal server veicola le stampati del client e le fa comparire come stampanti di sistema sull'host; i nomi di queste posso essere singolari ma normalmente contengono cose del tipo \\Prima-Sessione\HPColor dove HPcolor è la nostra stampante.

A livello tecnico il tutto può essere spiegato dal fatto che Terminal server trasporta in modo trasparente il NetBios e quindi anche le Print-Share.

Soluzione b)

Uso di Terminal server + ZebeDee su [host/server] e Terminal client + ZeBeDee su [client]


Nel caso OpenSSH non si possa/voglia usare si può ricorrere all'uso di ZeBeDee.


Passiamo direttamente alla configurazione del canale criptato prendendo spunto dall'esempio descritto sopra


Installato ZeBeDee su server lo si esegue con i seguenti parametri:

zebedee -s 10.0.0.10:163

In sintesi si mette in ascolto come server (-s) e mette a disposizione il servizio 163

(Naturalmente può anche essere permanentemente in ascolto)


Installato ZeBeDee su client dopo la connessione al provider lo si esegue con i seguenti parametri

zebedee 163:10.0.0.10:163

In sintesi zebedee come client veicola il servizio 163 residente su 10.0.0.10 in localhost 163 (zebedee ha anche delle opzioni che gli permettono di scegliere l'ip su cui fare il bind, qui non usate per semplicità)


Si usa ora il Terminal Client nel modo descritto sopra e il gioco è fatto.


Piccola nota su ZeBeDee.


Questo sw permette cose egregie; per semplicità didattica è stato invocato via linea comando ma, può essere installato come servizio, legge le configurazioni da file ed anche in grado di effettuare un port-forwarding su macchine differenti da quelle dove risiede. Veramente un coltellino svizzero (Swiss knife) per i tunnelling criptati. E' anche possibile usare per l'autenticazione dei client il meccanismo chiave pubblica/privata. Consiglio prima dell'utilizzo brutale di leggersi attentamente le doc del pacchetto si avrà così modo di apprezzare la grande versatilità di questo piccolo pezzo di Open-Source.


2) Servente host NT/W2000 con IP statico + client Unix/Linux con stampante fisicamente connessa al client.L'applicazione sia residente sull'Host.


La situazione è schematizzata al meglio dal seguente grafico:


   [host/server]NT/W2000 +APP <=====> [client] Unix/Linux--> [printer]
        IP = 10.0.0.10 (statico) | IP = ? (fornito dal provider)
                                 +
                     rete pubblica (insicura)
                                 +
                        tunnelling criptato

La nostra necessità è naturalmente utilizzare l'applicazione sull'host e stampare sul client veicolando il tutto con un tunnel criptato.


Soluzione a)

Uso di Terminal server + OpenSSH +Lpr (lpd client) su [host/server] e ssh + XFree86 + rdesktop + Lpd su [client]


Configurazione del canale criptato:


Esempio

Per configurare il client lpr su W2000 rimando agli Help del sistema suddetto bisogna fare solo attenzione a questi 2 semplici fatti:


Sul client Unix una volta connessi al provider si userà ssh

ssh -L 163:10.0.0.10:163 -R515:127.0.0.1:515 10.0.0.10


Cosa s'è fatto qui? Semplicemente abbiamo detto al client ssh di aprire 2 canali di cui il primo (-L) veicola il servizio Terminal Server dal server W2000 al client unix , il secondo (-R) veicola il servizio LPD dal client unix al server W2000

Lanciando rdesktop dal nostro client con il nome dell'host 127.0.0.1 comparirà il login di W2000 e se stamperemo sulla stampante di sistema W2000 \\127.0.0.1\HPColor la stampa arriverà sul nostro client (tempi di trasferimento permettendo :)).


Soluzione b)

Uso di Terminal server + ZeBeDee +Lpr (lpd client) su [host/server] e ZeBeDee + XFree86 + rdesktop + Lpd su [client]


Quello che s'è appena fatto con OpenSSH è naturalmente possibile farlo anche usando ZeBeDee solamente che in questo caso la configurazione del tunnel criptato sarà più complicata.

Procediamo con una configurazione d'esempio come al solito

Per veicolare il servizio Terminal server (che, nel nostro esempio, sta su 163/tcp) sull'host W2000 si lancerà:

zebedee -s -T20000 10.0.0.10:163

In sintesi zebedee come server (-s) rimane in ascolto su porta 20000/tcp (-T) per la connessione a zebedee client e mette a disposizione il servizio (porta) 163/tcp


Mentre sul client unix

zebedee -T20000 163:10.0.0.10:163

Credo che il significato sia ormai chiaro


Per veicolare il servizio Lpd (che, va ricordato, sta su 515/tcp sul client Unix) sull'host W2000 si lancerà:

zebedee -l -T20001 515:*:515

In sintesi qui zebedee è usato come client (ricordo che lpd sta sul client unix) in listen mode (-l) ossia aspetta che sia un server ad iniziare il colloquio rimane in ascolto su porta 20001/tcp (-T) inoltre attende una connessione da qualunque indirizzo ip (*) per il servizio 515/tcp


Sul client unix

zebedee -d -c 10.0.0.10 -T20001 127.0.0.1:515

In sintesi zebedee come server (-d) cerca la connessione con un client (-c) in 10.0.0.10 utilizzando la porta 20001/tcp (-T) e mette a disposizione il servizio 515/tcp.


Una volta connessi si procede come descritto nella Soluzione a)


3) Servente host Unix/Linux con IP statico + client W9x/Me/XP/2000 con stampante fisicamente connessa al client. L'applicazione sia residente sull'Host


La situazione è schematizzata al meglio dal seguente grafico:


 [host/server]Unix/linux +APP <=====> [client]W9x/Me/XP/2000--> [printer]
        IP = 10.0.0.10 (statico) | IP = ? (fornito dal provider)
                                 +
                     rete pubblica (insicura)
                                 +
                        tunnelling criptato


La nostra necessità è naturalmente utilizzare l'applicazione sull'host e stampare sul client veicolando il tutto con un tunnel criptato. In questo caso specifico le applicazioni residenti su Unix non richiedono l'uso di Xfree86 (nel mio caso erano semplicemente dei programmi di calcolo) richiedono semplicemente un client di tipo telnet


Soluzione a)

ZebeDee + rlpr + telnetd su [host/server] e ZeBedee + SmarTerm +lpd su [client]


SmarTerm è stato usato solo per la presenza in bundle di un demone lpd dalle discrete prestazioni che trasforma le stampanti di sistema Windows in code di stampa con nomi a piacere. E' ovvio che avendo a disposizione un altro demone lpd per esempio quello che forniscono con alcuni Xserver su W9x/ Me (su XP/2000 Client esiste un server lpd installabile) il client telnet potrebbe essere qualunque anche quello minimale presente nelle installazioni di W9x/Me/XP/2000

La configurazione del lato server non presenta particolari problemi ricalcando quelle che abbiamo già visto con una particolarità che adesso illustrerò:


Per veicolare il servizio telnet che sull'host unix/linux si lancerà:

zebedee -s -T20000 10.0.0.10:23


Per veicolare il servizio Lpd (che, va ricordato, sta su 515/tcp sul client Unix) sull'host Unix/Linux si lancerà:

zebedee -l -T20001 515:*:515


Nel caso esista già un servizio lpd locale all'host Unix/linux la riga sopra andrà così modificata:

zebedee -l -T20001 2048:*:515

In sintesi la porta locale su cui sarà veicolato lpd del client diventerà la porta 2048 ed il comando di stampa da dare sarà del tipo:


rlpr -–port=2048 -Hlocalhost -PnomecodastampanteWindows file .....

rlpr agisce come il comando lpr senza però la necessità di avere in /etc/printcap una entry per la stampante invocata e soprattutto permettendo di specificare una porta qualunque per arrivare al demone lpd

Naturalmente dettagli maggiori su questo potranno essere trovati sulle doc di rlpr (pagine man)


Nel client W9x/Me/2000/XP avremo:

zebedee -T20000 23:10.0.0.10:23


ed inoltre per lpd:

zebedee -s -c 10.0.0.10 -T20001 127.0.0.1:515


Il significato è stato già spiegato precedentemente.


Soluzione b)

ZebeDee + Samba + telnetd su [host/server] e ZeBedee + Putty su [client]


E' la soluzione più complicata perchè si basa sull'idea di propagare attraverso ZeBeDee gli share Netbios. E' anche la soluzione che funziona peggio non tanto dal punto di vista prestazionale quanto da quello dell'affidabilità. Questo deriva senz'altro dal numero di esperimenti limitato che ho potuto fare e con non mi hanno permesso a tutt'oggi di formalizzare in modo chiaro la soluzione. Insomma per dirla breve alle volte va alle volte no e, per quanto abbia un idea del perchè, non sono ancora sicuro di come risolvere compiutamente la cosa. Quanto descritto in seguito va perciò preso con beneficio d'inventario in attesa che la situazione mi si chiarisca completamente.


Per propagare gli share NetBios abbiamo bisogno di lavorare sulle porte seguenti:


137/tcp – 137/udp, 138/tcp - 138/udp, 139/tcp - 139/udp


Dal lato server dopo aver configurato samba possiamo lanciare zebedee con i seguenti parametri:

zebedee -l -U 137-139/tcp,137-139/udp:*:137-139/tcp,137-139/udp


Dal lato client

zebedee -s -U -c 10.0.0.10 127.0.0.1:137-139/tcp,137-139/udp


A questo punto se tutto è andato bene con smbprint (uno script che invoca smbclient) posso arrivare alla stampante del lato client a patto che abbia configurato la medesima come stampante condivisa. Anche qui occhio ai driver che vanno installati correttamente sul lato client, altrimenti gli unici file stampabili sono quelli di testo.


4) Servente host Unix/Linux con IP statico + client Unix/linux con stampante

Questo ed ultimo caso è risolvibile come combinazione degli altri già citati. In questo caso i demoni di stampa saranno (presumibilmente) entrambi lpd e quindi nel tunnelling si dovrà tener conto di spostare la porta remota in una delle tante porte alte aperte disponibili.




IV) Note “a latere”


Tutti i casi menzionati sono stati realmente provati ossia non esiste alcun esempio che, almeno per breve tempo, non sia stato funzionante.

Per esigenze di sintesi non mi sono sono soffermato sul problema utenti/permessi che, tra l'altro, è gestito in maniera differente tra W9x,Me,W2000, e Unix/Linux.

Ho sorvolato anche sulla crittografia che ritengo argomento noto comunque approfondibile compiutamente consultanto la documentazione dei pacchetti citati e senz'altro documenti in rete.




V) Appendici


5.1 File di configurazione di ZeBeDee


Come accennato ZebeDee può leggersi la configurazione oltre che da linea comando anche da file (parametro -f) qui di seguito riporto i file relativi a alcuni esempi citati con ovvia estensione per gli altri:


linea comando:

zebedee -s 10.0.0.10:163


equivalente con file di configurazione (il nome del file è anch'esso un esempio; può essere infatti qualunque):


zebedee -f server.zbd

struttura di server.zbd (E' un file ascii editabile manualmente)

#

# Sample Zebedee server configuration file

#

# This shows the use of many, but not all, of the configuration file

# options available for use by a server.

#

# $Id: index.html,v 1.1.1.1 2006/04/16 16:13:49 pragma Exp $


verbosity 3 # Slightly more than basic messages


# Comment out the following line once you have read the comments

# in this file and enabled or disabled the appropriate options!


message "Terminal Server redirector"

detached false # You will probably want this 'true' for normal

# use but I want to make sure that you see the

# preceding message if you haven't edited this.


server true # Yes, it's a server!


compression zlib:9 # Allow maximum zlib compression

keylength 256 # Allow keys up to 256 bits

keylifetime 36000 # Shared keys last 10 hours

maxbufsize 16383 # Allow maximum possible buffer size


# Uncomment the following line to log messages to a local file.

#

logfile './server.log'

#

# Or to log to the system logging facility uncomment this:

#

# logfile SYSLOG (solo per unix)


keygenlevel 2 # Generate maximum strength private keys


# Uncomment the following line if you want to use a fixed private

# key stored in a static file. The file should contain a line of

# the form "privatekey hexadecimal-key-string". This file should

# be readable by the user running Zebedee but no-one else.

#

# include 'server.key'


# To validate the identity of clients use a line something like

# the following:

#

# checkidfile './clients.id'


# The "redirect" expression can be use to set the default ports

# allowed when a target specification consists of a hostname but

# no other ports. The "redirect none" statement prohibits

# tunnelling anywhere by default.

#

redirect none


# Set up allowed targets. Note that there are NO targets allowed

# by this file by default. You must explicitly edit it to enable

# them.

target 10.0.0.10:163


# end


Per il client


lienea comando:

zebedee 163:10.0.0.10:163

equivalente con file di configurazione:

zebedee -f client.zbd


struttura di client.zbd

#

# Saranno qui per brevità indicate solo le opzioni che variano

#

message "Terminal Server client"


detached true # You will probably want this 'true' for normal use

server false #

Serverhost 10.0.0.10

tunnel 163:10.0.0.10:163

# end


Passiamo ad un ulteriore caso


linea comando

zebedee -s -T20000 10.0.0.10:163


equivalente con file di configurazione:

zebedee -f server1.zbd


struttura di server1.zbd

#

# Saranno qui per brevità indicate solo le opzioni che variano

#

message "Terminal Server"


detached true # You will probably want this 'true' for normal use

server true

serverport 20000

target 10.0.0.10:23

# end


linea comando

zebedee -T20000 163:10.0.0.10:163


equivalente con file di configurazione:

zebedee -f client1.zbd

#

message "Terminal Client"


detached true # You will probably want this 'true' for normal use

server false

serverport 20000

Serverhost 10.0.0.10

tunnel 163:10.0.0.10:163

# end


Linea comando (N.B. anche se agisce da client zebedee è invocato dal server):

zebedee -l -T20001 515:*:515


equivalente con file di configurazione:

zebedee -f server2.zbd

#

message "Lpd Client"


detached true # You will probably want this 'true' for normal use

server false

serverport 20001

listenmode true

tunnel 515:*:515

# end


Linea comando ( N.B. anche se agisce da server zebedee è invocato dal client):

zebedee -s -c 10.0.0.10 -T20001 127.0.0.1:515


equivalente con file di configurazione:


zebedee -f client2.zbd

#

message "Lpd Server"


detached true # You will probably want this 'true' for normal use

server true

serverport 20001

clienthost 10.0.0.10

target 127.0.0.1:515

# end


Spero che questi esempi siano chiarificatrici della sintassi dei file ZeBeDee. Un'ultima caratteristica che mi preme evidenziare è che quando ZeBeDee agisce come client oppure come server in clienthost (e deve quindi avere un client in listenmode) può veicolare la sua connessione in http tunnelling e quindi passando attraverso un httpproxy (molto comodo!) perfora de facto il proxy stesso (operazione intrinsecamente pericolosa riflettendoci ;-)).


Riga di configurazione (da aggiungere ad un file conf di ZeBeDee):


#

httpproxy ipproxy:proxyport

# per esempio

# httpproxy 10.10.1.10:8080

# oppure

# httpproxy proxy.pino.org:3128



5.2 Uso di TightVNC e ZeBeDee


TightVNC ( http://www.tightvnc.com ) è una versione migliorata di VNC (http://www.uk.research.att.com/vnc/).


In che senso migliorata?

  1. Usa estensivamente la zlib e la compressione jpeg permettendo così l'uso agevole di connessioni con limitata banda passante (buoni risultati si ottengono già con una connessione ISDN a 64Kbits o V92 a 56kbits);

  2. rimane perfettamente compatibile con l'avo VNC permettendo così a client e server differenti il colloquio anche se le caratteristiche aggiuntive sono disabilitate;

  3. abilita la connessione anche su localhost permettendo così l'uso di tunnel crittografici tipo ZeBeDee ed altri;

  4. il minuscolo web server interno (tecnologia Java) è stato adeguato cosicchè anche l'uso via browser ora beneficia dei miglioramenti introdotti.


Per brevità ecco qui di seguito un esempio di configurazione.

(Il test è stato fatto con macchine Windows ma è replicabile su macchine *nix dal momento che i sw utilizzati lavorano ottimamente su entrambe le piattaforme sw)


Lato server (nell'esempio IP Host = 10.0.0.10 come al solito)


Per ZeBeDee

zebedee -s 10.0.0.10:5800-5999



Per TightVNC (snapshot di $win)

















E le caratteristiche avanzate (snapshot di $win):





Per il lato client


zebedee 5800-5999:10.0.0.10:5800-5999


Per TightVNC (snapshot di $win)




E le caratteristiche avanzate (snapshot di $win):





Stunnel e servizi pop3, imap, smtp, lpd


Per completezza voglio accennare ad un altro tunnel crittografico che usavo prima di venire a conoscenza di ZeBeDee. Stunnel (http://www.stunnel.org) è un canale criptato molto interessante e può essere usato per veicolare quei servizi che non hanno o per vari motivi contingenti non possono avere tale capacità. Tecnicamente parlando si appoggia al TSL di OpenSSL.

Anche in questo caso il tunnel presenta pregi e difetti:

Pregi

  1. semplice da configurare ed installare;

  2. multipiattaforma (*nix e Win$);

  3. è possibile usare sia un file di configurazione che una serie di switch via linea comando.



Difetti

  1. non permette di avere un client in listenmode (come ZeBeDee) e quindi di veicolare dei servizi senza conoscere a priori gli IP;

  2. non riesce a veicolare il servizio FTP (mentre ZeBeDee lo può fare) dal momento che FTP daemon utilizza (specialmente in PASV mode) più porte per il data transfer;

  3. non usa compressione del protocollo;

  4. non permette l'http-tunnelling e quindi non connette attraverso un http-proxy.



Qui di seguito c'è una traccia del suo file di configurazione generico (ossia quello del tarball) e poi un esempio che uso (usavo :-)) al lavoro.

# Sample stunnel configuration file

# Copyright by Michal Trojnara 2002

# Comment it out on Win32

cert = /etc/stunnel/mail.pem

chroot = /var/run/stunnel/

# PID is created inside chroot jail

pid = /stunnel.pid

setuid = nobody

setgid = nogroup



# Authentication stuff

#verify = 2

# don't forget about c_rehash CApath

# it is located inside chroot jail:

#CApath = /certs

# or simply use CAfile instead:

#CAfile = @prefix@/etc/stunnel/certs.pem

# Some debugging stuff

#debug = 7

#output = stunnel.log



# Use it for client mode

#client = yes



# Service-level configuration

[pop3s]

accept = 995

connect = 110



[imaps]

accept = 993

connect = 143



[ssmtp]

accept = 465

connect = 25



[s1]

accept = 5000

connect = mail.osw.pl:110

# delay = yes



[s2]

accept = 5001

connect = mail.osw.pl:25



#[https]

#accept = 443

#connect = 80

#TIMEOUTclose = 0



Uso di un pop3 server su host 10.0.0.10

per il server (conf via linea comando):

stunnel -d 110 -r 10.0.0.10:110



per il client (conf via linea comando):

stunnel -c -d pop3 10.0.0.10:110



Lascio ad una lettura della man page il significato delle opzioni via linea comando (peralto intuibili)


Spero che il tutto sia stato abbastanza chiaro e divertente (che è poi la cosa sempre più importate).

In futuro a mano a mano che le mie prove progrediranno aggiornerò il tutto.


Per dubbi, consigli, pernacchie ed insulti (pochi spero ;-)), ringraziamenti, donazioni in solido, suggerimenti e correzioni scrivete a ZioPino <metaluxisdn@tiscalinet.it>


Ad maiora!!!!!!!!!