TELNET

HTTP e SMPT sono i più noti e richiesti servizi di rete. Ma oltre a questi, ne esiste una serie meno conosciuta ed utilizzata soprattutto dagli addetti ai lavori, come news telnet e gofer. Quello che ci accingiamo ad analizzare è un piccolo server telnet.

Introduzione

Che cosa è veramente un server telnet ? Il server telnet, è la versione moderna (si fa per dire) , delle vecchie connessioni ai grandi mainframe. Si basa sullo stesso criterio di allora. Il telnet di per se' può essere considerato come una finestra di console remota. L'idea di base è che il mainframe (o il server) esegue il lavoro per noi. I vantaggi prodotti da questo tipo d'approccio sono in genere due :

• Centralità dei dati.
• Basso costo delle stazioni client che avevano bisogno solo di un piccolo sistema di boot.

Questi concetti erano veri dieci anni fa', quando i costi per una stazione erano accessibili solo alle grandi società . Oggi con il basso costo dei PC, gli HOST e le sessioni telnet utilizzate sono diminuite di gran numero, soprattutto perché si preferisce usare Word piuttosto che il telnet. Prima di procedere ricordo che i sorgenti di questo progetto sono disponibili qui

PROGETTARE UN SERVER TELNET

Prima di realizzare un qualsiasi server ci si deve porre delle domande più o meno importanti, sia per il servizio che si intende dare all'utilizzatore, sia per le specifiche che intendiamo seguire nella realizzazione del server.

Un' ipotetica lista dei punti da seguire potrebbe essere :

• 1- SICUREZZA SERVIZIO

2- MODIFICA IMPOSTAZIONI SERVIZIO

SICUREZZA

Uno dei punti fondamentali su cui bisogna fare, secondo me, particolarmente attenzione sia in fase di analisi che in fase di stesura del codice è la sicurezza del servizio. La sicurezza del servizio può essere a sua volta suddivisa in vari eventi:

• a\) Crash servizio

Più un servizio è scritto bene, maggiore sarà' la sua vita, quindi è opportuno di gestire il maggior numero di eccezioni per evitare che nel mezzo della notte il servizio vada in crash lasciando tutti i nigth user (me compreso) delusi dalla sua momentanea assenza ingiustificata.

• b\) Crash sistema ospite

Oltre al crash del servizio in alcune circostanze si può anche assistere al crash del sistema ospite con notevole disappunto oltre che degli utenti anche del Webmaster.

c\) Attacchi esterni.

Tutti i servizi on-line devono essere molto robusti, per difendersi sia dai crash descritti sopra sia dagli attacchi esterni dei vari giocherelloni della rete, che si divertono a fare incursioni in tutti i server del pianeta. Questo forse è il punto più delicato e più difficile da proteggere, sia in fase di analisi, sia di stesura del codice, perché non sempre si conoscono le armi del nemico. Per esempio tramite alcune piccole utility è possibile intercettare le sessioni telnet degli altri utenti della rete e monitorare tutti i dati che fluiscono da loro verso il server e viceversa. L' unica soluzione a questo problema è quella di codificare le informazioni trasmesse dal server verso il client, questo pero' porta alla scrittura di un programma client in grado di decodificare i dati.

-

MODIFICA IMPOSTAZIONI SERVIZIO

Una delle caratteristiche più apprezzate di un server o di un sistema operativo è quella di permette la modifica delle impostazioni e dei servizi senza dover riavviare la macchina. Secondo il mio parere, questo è uno dei vincoli fondamentali a cui si deve pensare prima della stesura di qualunque applicativo la cui esecuzione puo' durare anche mesi. Nell'ipotesi di un servizio che abbia utenti per circa ventitré ore al giorno è impossibile chiedere a chi amministra il sistema di chiudere tutto e ripartire, disconnettendo gli utenti in quel momento connessi.

Dopo questa breve introduzione al mondo dei server incominciamo ad analizzare i sorgenti allegati all'articolo. Le classi che compongono Il nostro MokaServer telnet (da ora MST) si possono dividere in tre gruppi il server vero, le eccezioni e i suoi servizi.

SERVER DESCRIZIONE MokaServer Si occupa di accettare le connessioni dai vari client che vogliono accedere al servizio, si puo' considerare come la nostra porta di ascolto. MokaDialog Questa classe viene creata ogni volta che arriva una richiesta di connessione da parte di un nuovo utente.

È eseguita in thread.

GetTelnetLine E' la nostra interfaccia verso il client telnet, gestisce la sua connessione ed I possibili messaggi anomali, genera l'eccezione TException. ExecCommand Si occupa della gestione di tutte le richieste di comandi da parte dell'utente e di caricare se necessario i comandi richiesti.

ECCEZIONI DESCRIZIONE TException Classe di eccezioni generate da GetTelnetLine, in particolare è generata alla chiusura del telnet e alla sua disconnessione. SERVIZI DESCRIZIONE LogIn Verifica login e passowrd per tutti i nuovi client. User Contiene tutte le informazioni sull'utente attualmente collegato. DynaMode Contiene il nostro ponte, la nostra interfaccia, per il caricamento dinamico dei dati. SYSTEM Esegue un CHECK del sistema del server. Questa classe viene caricata dinamicamente. PWD Esegue il comando PWD delle console UNIX, cioè mostra la directory corrente, nel nostro caso la directory privata. Questa classe viene caricata dinamicamente. DIR Esegue il vecchio e buon comando dir del dos. Questa classe viene caricata dinamicamente.

Ora possiamo analizzare gli unici due punti oscuri di tutto il programma, il quale rimane ugualmente di facile lettura .

DynaMode e il caricamento delle classi

La classe DynaMode è il punto di ingresso per le classi caricate dinamicamente. Questo meccanismo ci permette di chiamare dei metodi di una classe DERIVATA da una classe "PADRE " . Questo è quello che in C++ è gestito da quell'insieme di funzioni RTTI ( Run Time Type Identification ). Per maggiori informazioni a riguardo vedi la documentazione ufficiale. Il punto più caldo e pragmatico di tutti i sorgenti potrebbe essere la seguente istruzione :

• System.gc();

Con questa linea di codice obblighiamo la JVM ( Java Virtual Machine ) ad eseguire un GARBAGE COLLECTOR e quindi a scaricare dalla memoria tutte le classi caricate dinamicamente che possiedono zero instanze in quel momento. Questo è eseguito ogni volta che un utente richiede un comando, per permettere di cambiare o di aggiungere dei comandi anche con degli utenti collegati. ( Può essere considerato anche come un effetto sorpresa non indifferente per gli utenti che mentre sono on-line, si vedono cambiare il comando PWD da un'esecuzione all'altra ).

Hashtable per i comandi personalizzati

Per contenere tutti i comandi personalizzati di ogni utente, la mia scelta è ricaduta su una hashtable, questo perché permette un recupero dei comandi molto veloce e quindi riduce i tempi di risposta del servizio, anche se ha un grande spreco di risorse.

Come configurare un nuovo utente.

Ogni utente che accede al nostro MST dispone di :

• Login: da considerarsi unico per ogni utente, può contenere spazi.
• Password: può essere duplicata tra i vari utenti, può contenere spazi.
• Directory privata: dato che la versione corrente non permette di scrivere sul disco del server più utenti possono benissimo condividere la stessa direcory.

Il file di configurazione degli utenti deve essere nella stessa directory da cui parte il servizio e deve essere denominato come NomeFile.psw dove NomeFile è il login dell'utente.

Le linee del file vanno impostate nel seguente modo :

0 - password utente.

1 - directory privata

da 2 in poi la lista dei comandi dell'utente.

Ad esempio:

File : Moka.psw

\[ Linea 0 \] moka

\[ Linea 1 \] C:\\

\[ Linea 2 \] DIR

\[ Linea 3 \] PWD

\[ Linea 4 \] SYSTEM

La path privata deve terminare con il carattere ' . , . La password è case sensitive, qundi attenzione !

SICUREZZA

Quello che ho presentato è solo una bozza di ciò che si può fare e ci sono molte migliorie da apportare tra cui :

• Specifiche RFC
• Creazione dei file di log per monitorare gli accessi.
• Creare un file di configurazione dove poter inserire solo alcuni IP che possono accedere al servizio.

Spostare il parsec dei comandi in una classe esterna cosi' da poterlo aggiornare dinamicamente, insomma, quello che ho presentato è veramente una bozza di un piccolo SERVER, ma che mette in risalto tutte le caratteristiche più importanti di questa branca di servizi.

Quasi dimenticavo, se intendete scrivere delle applicazione CLIENT / SERVER che utilizzano I socket tramite internet non utilizzate come numero di porta i valori minori di 1000, perché il range di ' porte ' ; da o a 1000 sono riservati ai servizi noti tipo :

SERVIZIO PORTA HTTP 80 FTP 21 TELNET 23 MAIL 25 Buon divertimento. Pietro Venanzangeli

Pietro Venanzangeli è programmatore C/C++ e JAVA. Diplomato in informatica all'ITIS B.Pascal di Roma. Si interessa di amministrazione di siti WEB e allo sviluppo di applicazioni internet e di networking. Attualmente lavora come consulente. Puo' essere contattato via e-mail a: <networkmanager@lcnet.it>