Con il termine telnet si fa riferimento ad un programma di comunicazione molto popolare nei decenni scorsi, che permette di connettere due host in modo tale che uno dei due possa essere assimilato ad un terminale mentre l'altro funge da computer centrale. Questo schema era molto diffuso un tempo quando gli elaboratori erano poco diffusi, molto grandi e costosi e, quindi, l'utente medio vi poteva accedere in modalità terminale remoto.
Attualmente la maggior parte delle funzionalità, che venivano eseguite remotamente, sono realizzate sul proprio computer personale per cui telnet ha perso gran parte d'interesse. Rimane, tuttavia, assai utile in alcune circostanze particolari. Oggigiorno, le applicazioni di maggior interesse sono quelle che permettono di accedere alle informazioni contenute su elaboratori ed, eventualmente, trasferirle localmente sul proprio computer utilizzando protocolli piuù specializzati come HTTP e FTP.
Telnet è uno dei protocolli storici della rete Internet, utilizzato fin dai tempi della rete, precursore di Internet, Arpanet. Nei documenti IETF STD 8 (RFC 854 e RFC 855) si afferma che:
Per estensione, telnet è anche il nome di un programma che un utente può usare per avviare una sessione telnet ad un host remoto; il programma telnet implementa la parte client del protocollo. I client telnet sono stati disponibili per parecchi anni, e lo sono tutt'oggi, nella maggior parte dei sistemi UNIX e sono disponibili per qualsiasi tipo di computer.
In inglese to telnet è usato come verbo e significa stabilire una connessione telnet.
Telnet è un protocollo client-server basato su TCP; usualmente, ma non necessariamente, come si è già visto nella scorsa lezione, i clienti si connettono alla porta 23 del server (ma la porta può essere differente). In parte a causa della progettazione del protocollo e in parte per la flessibilità tipicamente fornita dai programmi telnet, è possibile utilizzare un programma telnet per stabilire una connessione interattiva ad un qualche altro servizio su un server internet.
Un utilizzo classico è di collegarsi con telnet alla porta 25 (sulla quale tipicamente si trova un server SMTP) per effettuare il debugging di un server di posta. Il protocollo Telnet si divide in una parte principale ed in un insieme di estensioni. La parte principale è descritta dalle RFC 854 e RFC 855 dell'IETF, che sono anche unite nell'STD 8, e definiscono le caratteristiche base del protocollo ed il modo di implementare le estensioni.
Fra le molte estensioni, alcune sono state adottate come Standard Internet. I documenti STD dal 27 al 32 definiscono varie estensioni di Telnet, la maggior parte delle quali sono molto diffuse. Tra le estensioni rimanenti, le più importanti sono quelle proposte dall'IETF come standard; ulteriori dettagli possono esser trovati nella STD 1. Come spiegato nel seguito, Telnet non è sicuro e dovrebbe esser generalmente evitato. Il suo impiego sulle reti pubbliche comporta seri rischi per la sicurezza.
Sono essenzialmente tre gli aspetti che fanno di Telnet una scelta non appropriata dal punto di vista della sicurezza nei sistemi moderni:
Queste ed altre falle sono state la causa per cui l'uso del protocollo telnet è andato rapidamente sostituito col più sicuro protocollo SSH, rilasciato nel 1998. SSH offre tutte le funzioni di telnet alle quali si aggiunge una criptazione sicura, che previene l'intercettazione dei dati scambiati, ed un'autenticazione a chiave pubblica, che assicura l'identità del server remoto. In effetti, gli esperti di sicurezza informatica sconsigliano l'uso di Telnet per login remoti anche in circostanze normali d'uso.
Quando telnet è stato sviluppato all'inizio degli anni 80, secondo alcune fonti addirittura nel 1969, la maggior parte degli utenti delle reti appartenevano a dipartimenti di istituti accademici o a centri di ricerca privati o governativi. In quell'ambiente, la sicurezza non era così importante quanto lo è oggi, con l'espansione della banda larga. Con la crescita esponenziale del numero di persone che accedono ad internet, e del numero di coloro che vogliono entrare in sistemi altrui, telnet non dovrebbe essere usato in reti internet.
I clienti telnet sono ancora usati occasionalmente per "parlare" con altri servizi. Telnet è usato sporadicamente nel debug di servizi di networking come i server SMTP e HTTP, in quanto rappresenta un modo semplice per inviare comandi al server ed esaminare le risposte. Telnet può anche essere usato come un rudimentale client IRC se si possiede una conoscenza adeguata.
Telnet è molto usato per i giochi Multi User Dungeon giocati in rete. Nel campo della Posta elettronica Telnet ha molti validi usi, per esempio è possibile leggere la corrispondenza sulla propria mailbox, cancellarla oppure spedire missive elettroniche. Poichè l'accesso alle caselle di posta elettronica è realizzato in modalità non sicuro e, perfino, da un Computer pubblico, i problemi di sicurezza di Telnet in questo non sono un ostacolo.
In alcuni casi le Webmail presentano problemi di accesso alla propria mailbox risolvibili talvolta con Telnet come nel caso, ad esempio, del superamento della memoria concessa; accade allora che alcune caselle si bloccano mentre con Telnet è possibile by-passare il problema.
Per la sua semplicità d'uso Telnet è particolarmente adatto in tutte le situazioni in cui la sicurezza non è un problema significativo e, quindi, utilizzabile in rete locale quando le sessioni di accesso al sistema distribuito sono controllate e non sono fonte di errori malevoli.
Il protocollo Telnet va realizzato seguendo le direttive già citate e deve permettere l'utilizzo dei caratteri di controllo da tastiera secondo lo specifiche. Si tratta, comunque, di un protocollo connesso costruito sulla suite TCP/IP per cui si deve fare molta attenzione al modo con cui i messaggi vengono costruiti ed inviati sulla rete. La funzione C riportata nel seguito mostra come deve essere implementato il meccanismo di trasmissione dati realizzato da un cliente telnet che utilizza la connessione in rete per mezzo delle socket.
int DoConnect(const char *host, const char *service, const char *transport)
/* arguments:
* host --- name of host to which connection is desired
* service -- service associated with the desired port
* transport --- name of transport protocol to use ("tcp" or "udp")
*/
{
struct hostent *phe; /* pointer to host information entry */
struct servent *pse; /* pointer to service information entry */
struct protoent *ppe; /* pointer to protocol information entry */
struct sockaddr_in sin; /* an Internet endpoint addredd */
int s,type; /* socket descriptor and socket type */
memset(&sin,0,sizeof(sin));
sin.sin_family=AF_INET;
/* Map service name to port number */
if (pse = getservbyname(service,transport))
sin.sin_port = pse->s_port;
else if ((sin.sin_port = htons((u_short)atoi(service))) == 0 )
{
printf("can't get \"%s\" service entry\n",service);
return 0;
}
/* Map host name to IP address,allowing for dotted decimal */
if (phe = gethostbyname(host))
memcpy(&sin.sin_addr,phe->h_addr,phe->h_length);
else if ((sin.sin_addr.s_addr = inet_addr(host)) == INADDR_NONE)
{
printf("can't get \"%s\" protocol entry\n",transport);
return 0;
}
/* Map transport protocol name to protocol number */
if ((ppe = getprotobyname(transport))==0)
{
printf("can't get \"%s\" protocol entry\n",transport);
return 0;
}
/* User protocol to choose a socket type */
if (strcmp(transport,"udp") == 0)
type = SOCK_DGRAM;
else
type = SOCK_STREAM;
/*Allocate a socket */
s = socket(PF_INET, type, ppe->p_proto);
if (s < 0)
{
printf("can't create socket:%s\n", strerror(errno));
return 0;
}
/* connect the socket */
if (connect (s,(struct sockaddr *)&sin,sizeof(sin)) < 0)
{
printf("can't connect to %s.%s: %s\n",host,service,strerror(errno));
return 0;
}
return s;
}
|
A parte i soliti controlli, necessari a verificare la correttezza dei parametri utilizzati per la creazione della socket, si noti l'impiego della funzione connect che tenta la connessione col server remoto.
Si è già discusso in precedenti lezioni lo schema generale di un server iterativo connesso nel quale si è evidenziato il ruolo delle socket nella gestione della connessione, invocando le necessarie chiamate di sistema.
Nell'esempio proposto nel seguito viene illustrato l'utilizzo dello stesso schema per implementare un web server. Si procede in modo del tutto analogo a quello discusso nella lezione citata ma, ora, bisogna tener conto del diverso protocollo di comunicazione utilizzato a livello applicativo dal client e dal server.
#include <sys/socket.h> /* socket definitions */
#include <sys/types.h> /* socket types */
#include <sys/wait.h> /* for waitpid() */
#include <arpa/inet.h> /* inet (3) funtions */
#include <unistd.h> /* misc. UNIX functions */
#include <stdio.h>
#include <stdlib.h>
#include "helper.h"
#include "servreq.h"
#define SERVER_PORT (8080)
/* main() funcion */
int main(int argc, char *argv[]) {
int listener, conn;
pid_t pid;
struct sockaddr_in servaddr;
/* Create socket */
if ( (listener = socket(AF_INET, SOCK_STREAM, 0)) < 0 )
Error_Quit("Couldn't create listening socket.");
/* Populate socket address structure */
memset(&servaddr, 0, sizeof(servaddr));
servaddr.sin_family = AF_INET;
servaddr.sin_addr.s_addr = htonl(INADDR_ANY);
servaddr.sin_port = htons(SERVER_PORT);
/* Assign socket address to socket */
if ( bind(listener, (struct sockaddr *) &servaddr, sizeof(servaddr)) <0 )
Error_Quit("Couldn't bind listening socket.");
/* Make socket a listening socket */
if ( listen(listener, LISTENQ) < 0 )
Error_Quit("Call to listen failed.");
/* Loop infinitely to accept and service connections */
while ( 1 ) {
/* Wait for connection */
if ( (conn = accept(listener, NULL, NULL)) < 0 )
Error_Quit("Error calling accept()");
/* Fork child process to service connection */
if ( (pid = fork()) == 0 ) {
/* This is now the forked child process, so
close listening socket and service request */
if ( close(listener) < 0 )
Error_Quit("Error closing listening socket in child.");
Service_Request(conn);
/* Close connected socket and exit */
if ( close(conn) < 0 )
Error_Quit("Error closing connection socket.");
exit(EXIT_SUCCESS);
}
/* If we get here, we are still in the parent process,
so close the connected socket, clean up child processes,
and go back to accept a new connection. */
if ( close(conn) < 0 )
Error_Quit("Error closing connection socket in parent.");
waitpid(-1, NULL, WNOHANG);
}
return EXIT_FAILURE; /* We shouldn't get here */
}
|
L'impiego del diverso protocollo di comunicazione, detto protocollo HTTP, fa si che il server debba gestire in proprio la specifica struttura dei dati trasmessa dal client e dalla quale il server deve estrarre i parametri della richiesta. In quest'ottica va letta l'implementazione proposta per tale server nella quale, per ragioni di semplicità, non si tiene conto dei problemi di sicurezza e di gestione di tutti i tipi di dati trasmissibili (MIME-FORMAT).
Una rete di calcolatori è un grafo i cui nodi rappresentano elaboratori (host) e i cui archi sono connessioni fisiche che permettono ad elaboratori, giograficamente vicini, di parlarsi direttamente. Naturalmente, questa è soltanto una definizione approssimata perchè è necessario specificare nel dettaglio quali convenzioni (i cosiddetti protocolli) devono essere rispettate affinchè gli elaboratori della rete possano realmente scambiarsi messaggi, in modo trasparente rispetto all'implementazione della rete e alle specificità con cui ciascun elaboratore diventa un nodo della rete.
C'è, infine, un ulteriore problema e che si riferisce alle dimensioni fisiche della rete e che, attualmente, non bisogna dimenticarlo si attesta su una struttura comprendente 300-400 milioni di nodi le cui funzionalità richiedono algoritmi di gestione della rete pensati ad hoc per poter lavorare bene con questi numeri. Così, la rete, oggi generalmente conosciuta col nome internet, è dotata di due strutture connettive che la sostengono permanentemente e che si presentano come due sottoreti dense sulla rete stessa:
La rete per poter assolvere al suo compito deve essere implementata in modo che, quando due processi in esecuzione remota su due distinti calcolatori, vogliono comunicare fra loro sia possibile determinare nella rete un cammino lungo il quale i messaggi, transitando di nodo in nodo, possano giungere a destinazione.
A tale scopo è necessario specificare un certo un insieme di protocolli che, realizzati utilizzando le convenzioni rispettate da tutti gli elaboratori della rete, permettono di sezionare un messaggio di arbitraria lunghezza (sessione) in pacchetti di dimensione fissa opportunamente segnati tali da ricostruire (trasporto), giunti a destinazione, il messaggio originale.
Naturalmente, ciascun pacchetto deve essere in grado di seguire il giusto cammino (istradamento) attraversando i nodi della rete (router) le cui tabelle forniscono localmente la direzione più conveniente (RIP e splitting the horizon) per proseguire. Ma i pacchetti devono essere trasmessi come segnali elettrici per cui devono essere divisi in frame che i protocolli ARP e PPP destinano senza indugi.
Comunque sia, la rete internet utilizza le convenzioni definite dai protocolli TCP e IP per generare, mantenere, istradare e ricostruire i messaggi per cui TCP/IP è la suite di protocolli che talvolta identifica la rete internet per cui questi termini vanno considerati come sinonimi.
Nel seguito viene riportata una collezione di comandi che il sistema operativo Unix mette a disposizione sia dell'utente normale che del system manager per gestire l'accesso in rete ed avere da questa utili informazioni.
Qualunque distribuzione di Linux si consideri risulta dotata di molti comandi per configurare, verificare lo stato e accedere alla rete. Si tratta di comandi resi disponibili al momemto dell'installazione. Nel seguito verrà data una breve descrizione dei comandi di rete più utilizzati i quali, per comodità di comprensione ed utilizzo, sono convenientemente organizzati nelle seguenti categorie:
Configurazione Di Rete |
I comandi più importanti sono quelli usati per configurare le interfacce e i metodi di accesso alla rete e, in quanto tali, sono normalmente utilizzati dagli amministratori di sistema, avendo la responsabilità ed il permesso di configurare le macchine di cui sono gestori. Ciò non toglie che gli utenti normali possano utilizzare tali comandi per determinare lo stato dell'installazione in rete della macchina.
Si noti che la maggior parte di questi comandi compaiono negli shell script lanciati durante la fase di boot del sistema che installa la rete. Linux riconosce automaticamente le interfacce della rete al momento del boot, purchè il nucleo sia configurato correttamente. Ad ogni interfaccia viene assegnata automaticamente un'etichetta - come l'interfaccia lo0 di "loopback"con cui la macchina comunica con se stessa, oppure eth0, la prima scheda di rete installata nel sistema.
Questi comandi sono elencati nell'ordine con cui sarebbe necessario invocarli qualora la rete venisse installata manualmente.
TCP/IP: Analisi del Traffico |
Il comando ping (così chiamato per il suono prodotto da un sistema sonar attivo) trasmette le richieste di eco all'host remoto seconde le specifiche indicate nella linea di comando. Le righe di risposta contengono il tempo totale impiegato dal pacchetto per raggiungere l'host remoto e tornare indietro. Terminata l'esecuzione di ping (mediante un control-C) il comando ricapitola i risultati, fornendo il "tempo totale medio di viaggio" e la "perdita percentuale dei pacchetti". Usate questo comando per verificare se ci sia qualche problema di collegamento fra voi e l'host remoto.
Tutti questi comandi effettuano interrogazioni ai DNS che possono essere semplici (dal nome dell'host all'indirizzo), inverse (dall'indirizzo al al nome dell'host), complesse (come l'elenco degli host in un dominio). Il comando dig è considerato quello in grado di fornire il maggior numero di informazioni mentre host produce l'output di default più semplice.
Clienti e Servizi di Rete |
Per configurare o eseguire servizi di rete, il primo package necessario allo scopo è quello dei TCP wrapper che gestiscono la maggior parte delle connessioni entranti. Una volta, ad esempio, il daemon FTP andava in esecuzione fin dall'inizio agganciandosi alla porta 21 per eseguire successivamente ascolti di richieste ftp e poi servirle. Ma il fatto che ciascun servizio prendesse la propria decisione sulle connessioni da accettare, ha reso più difficile o impossibile la creazione e l'applicazione di una politica uniforme degli accessi
Attualmente i sistemi sono realizzati con TCP wrapper, che controllano tutte le porte su cui possono essere fatte richieste di servizio. Quando si realizza una connessione i wrapper decidono se consentire o meno l'accesso e soltanto nel caso di connessione permessa viene attivato il daemon che deve rispondere ad essa. Tali regole si trovano nei file di configurazione /etc/hosts.deny e /etc/hosts.allow.
| Porta | Client | Server | Descrizione |
|---|---|---|---|
| 21 | ftp | in.ftpd | File Transfer Protocol - il protocollo standard per il trasferimento di file attraverso Internet, disponibili sia da account d'utente protetti da parola chiave sia da server "anonimi" pubblicamente disponibili |
| 23 | telnet | in.telnetd | Protocollo telnet d'accesso remoto via terminale - il protocollo standard per connettersi remotamente ad una macchina. |
| 37 | rdate | in.timed | Tempo di sistema - risponde con il tempo fornito dall'orologio di sistema. |
| 67 | bootptest | bootpd | Protocollo di Bootstrap da Internet - se si vuole controllare l'assegnazione di IP ADDRESS da una postazione centrale, si permette a tali macchine di trasmettere un messaggio broadcast al momento del booting in modo che un server della LAN risponda con IP ADDRESS che la macchina dovrebbe usare e possibilmente un nome di file di configurazione da richiamare attraverso tftp |
| 69 | tftp | in.tftpd | Trivial File Transfer Protocol - un File Transfer Protocol molto semplice che permette a qualunque host di trasferire qualunque file dal sistema centrale pubblicamente leggibile nella propria directory (normalmente /tftpboot ). |
| 70 | Gopher | gn | Gopher - un browser gerarchico delle informazioni che era in uso prima dell'introduzione di HTML. |
| 79 | finger | in.fingerd | User Information Lookup - introdotti una username (o, per alcuni server, parte del nome di un utente) fornisce alcune statistiche generali, compreso l'ultimo periodo di inizio delle attività e se l'utente ha letto la sua posta. L'accesso al servizio è spesso limitato dai TCP wrapper poichè la conoscenza pubblica degli utenti riduce la sicurezza. |
| 110 | (vario) | ipop3d | PostOffice V.3 - Un protocollo per l'accesso remoto di una casella postale con la relativa lettura remota della posta |
| 113 | (vario) | in.identd | Autenticazione dell'utente - un servizio importante che, dato il numero di una porta attiva e dell'IP di un host, restituisce lo username dell'utente che sta impiegando quella porta. Usato in molte applicazioni che hanno a che fare con il controllo d'accesso e la sicurezza. |
| 119 | NNTP | in.nntpd | Usenet Transfer Protocol - il protocollo che permette ad un cliente remoto di interrogare un server di notizie. |
| 512 | rexec | in.rexecd | Esecuzione remota di un comando - permette ad un utente di eseguire un comando su un sistema remoto. I servizi seguenti forniscono un metodo di autenticazione abbreviato, permettendo ad un utente di creare un file .rhosts nella propria home directory che elenca i login name e le macchine che possono accedere al proprio account senza dovere digitare la password. La possibilità di utilizzare questi servizi va considerata in termini di sicurezza. |
| 513 | rlogin | in.rlogind | Remote login - Consente di effettuare un login da un sistema remoto (vedi anche rexec). |
| 514 | rsh | in.rshd | Remote shell - Permette che un utente possa accedere remotamente ad una shell di comandi (vedi anche rexec). |
| 517 | talk | in.talkd | Parla con un altro utente - Consente ad una coppia di utenti di scambiarsi messaggi in tempo reale utilizzando tastiera e videoterminale. Molto popolare nelle istituzioni universitarie quando internet non consentiva ancora connessioni multimediali. |
| 540 | uucp | uucico | Unix-to-Unix Copy protocol - Realizzazione su internet del vecchio e famoso protocollo UUCP che permetteva la connessione di sistemi Unix quando ancora le connessioni fisiche erano realizzate periodicamente via modem. |
Esistono, inoltre, servizi ancora più complessi, alcuni dei quali realizzati con TCP wrapper.
Monitoraggio della Rete |