Copy Link
Add to Bookmark
Report
The Finger User Information Protocol
*************************************************************************
* Traduzione a cura di ADaM unno@softhome.net *
* a beneficio degli Spippolatori e di coloro che hanno sete di sapere. *
* La distribuzione del documento integrale è illimitata. *
* Revisione a cura di ................ *
*************************************************************************
Network Working Group D. Zimmerman
Request for Comments: 1288 Center for Discrete Mathematics and
Obsoletes: RFCs 1196, 1194, 742 Theoretical Computer Science
December 1991
The Finger User Information Protocol
Stato di questa Memo
Questa memo definisce un protocollo per lo scambio della info relative
all'user. Questa RFC specifica una traccia di protocollo standard per
la comunit‡ di Internet, e richiede un dibattito e suggerimenti per i
miglioramenti. Riferirsi alla corrente edizione della lista dei
protocolli Standard per lo stato di questo protocollo.
La distribuzione di questa memo è illimitata.
Abstract
Questa memo descrive il Finger, protocollo per ottenere le info relative
ad un certo utente. Questo è un semplice protocollo che d‡ un'interfaccia
a un programma di informazione di un utente remoto.
Basato sull'RFC 742, una descrizione del finger originale, questa memo tenta
di chiarire l'aspetto della comunicazione tra i due estremi della connessione
finger. Tenta inoltre di non invalidare le molte esistenti implementazioni o
aggiungere restrizioni non necessarie alla definizione originale del
protocollo.
Questa edizione corregge e chiarifica l'RFC 1196.
Tavola dei contenuti
1. Introduzione ............................................... 2
1.1. Intento ............................................... 2
1.2. Storia ................................................ 3
1.3. Requisiti ............................................. 3
1.4. Aggiornamenti........................................... 3
2. Uso del protocollo........................................ 4
2.1. Flusso degli eventi..................................... 4
2.2. Formattazione dei dati.................................. 4
2.3. Specifiche delle query.................................. 4
2.4. Comportmento del RUIP {Q2}.............................. 5
2.5. Risposta RUIP attesa .................................. 6
2.5.1. {C} query ........................................... 6
2.5.2. {U}{C} query ........................................ 6
2.5.3. Ambiguit‡ della {U} ................................. 7
2.5.4. Simbolo della query /W ............................... 7
Zimmerman [Page 1]
RFC 1288 Finger December 1991
2.5.5. Macchine vendute ......................................... 7
3. Sicurezza ............................................... 7
3.1. Implementazione della sicurezza......................... 7
3.2. Sicurezza di RUIP ..................................... 8
3.2.1. opzione {Q2} ........................................ 8
3.2.2. opzione {C} ........................................ 8
3.2.3. Atomic discharge .................................... 8
3.2.4. Files di info dell'utente ............................ 9
3.2.5. Esecuzione del programma dell'utente.................. 9
3.2.6. Ambiguit‡ di {U} .................................... 9
3.2.7. Controllo delle tracce .............................. 9
3.3. Sicurezza del Client .................................. 9
4. Esempi ....................................................10
4.1. Esempio col comando non valido ({C}) ................. 10
4.2. Esempio col nome specificato ({U}{C}) ................. 10
4.3. Esempio con nomi ambigui specificati ({U}{C}) ......... 11
4.4. Esempio della query tipo {Q2} ({U}{H}{H}{C}) .......... 11
5. Riconoscimenti .......................................... 12
6. Considerazioni sulla sicurezza............................ 12
7. Indirizzo dell'autore..................................... 12
1. Introduzione
1.1. Intento
Questa memo descrive il protocollo finger. Questo è un semplice protocollo
che fornisce una interfaccia ad un programma di info di un utente remoto
(RUIP,remote user information program).
Basata sulla RFC 742, una descrizione del protocollo finger originale,
questa memo tenta di chiarire l'aspetto della comunicazione tra i due estremi
della connessione finger. Cerca anche di non invalidare le molte correnti
implementazioni o aggiungere restrizioni non necessarie alla definizione
originale del protocollo.
L'implementazione prevalente del finger oggi sembra essere primariamente
derivata dal lavoro dell' unix BSD all'univ. della California, Berkeley.
CosÏ, questa memo è basata sul comportamento della versione BSD.
Comunque, la versione BSD fornisce poche opzioni per adattare il RUIP del
finger per la particolare politica di sicurezza di un sito, o per proteggere
l'utilizzatore da dati pericolosi. Inoltre, ci sono molti potenziali buchi
nella sicurezza di cui implementatori e amministratori occorre che siano al
corrente, particolarmente a causa del proposito di questo protocollo di
fornire informazioni sull'utilizzatore di un sistema. Perciò questa memo
fa un numero d importanti commenti e raccomandazioni sulla sicurezza.
Zimmerman [Page 2]
RFC 1288 Finger December 1991
1.2. Storia
Il programma finger al SAIL, scritto da Les Ernest, fu l'ispirazione per
il nome del programma all' ITS. Earl Kallian al MIT e Brian Harvey al SAIL
furono entrambi responsabili dell'implementazione del protocollo originale.
Ken Harrenstien è l'autore dell' RFC 742, "Name/Finger", con il quale questa
memo prende vita.
1.3. Requisiti
In questo documento, le parole che sono usate per definire il significato
di qualche particolare requisito sono scritte in maiuscolo. Queste parole
sono:
*"DEVE"*
Questa parola o l'aggettivo RICHIESTO significa che l'argomento è un
requisito assoluto della specifica.
*"DOVREBBE"*
Questa parola e l'aggettivo "RACCAMANDATO" significa che potrebbero
esisitere ragioni valide in particolari circostanze per ignorare questo
argomento, ma tutte le implicazioni dovrebbero essere capite e il caso
attentamente pesato prima di scegliere in modo differente.
*"PUO'"*
Questa parola e l'aggettivo "OPZIONALE" significa che questo argomento è
davvero opzionale. Un fornitore può scegliere di includere l'argomento perchè
un particolare mercato lo richiede o perchè migliora il prodotto, per esempio;
un altro fornitore può omettere lo stesso argomento.
Una implementazione non è soddisfacente se non soddisfa uno o pi˘ dei requi-
siti "DEVE". Un'implementazione che soddisfa tutti i requisiti "DEVI" e tutti
i requisiti "DOVREBBE" è detta "incondizionatamente soddisfacente"; una che
soddisfa tutti i requisiti "DEVE" ma non tutti i "DOVREBBE" è detta condizio-
natamente soddisfacente.
1.4. Aggiornamenti
Le differenze di nota tra RFC 1196 e questo sono:
* l'opzione /W nella specifica del query fu erroneamente messa alla fine
della linea. Il finger BSD 4.3 lo specifica all'inizio, dove questa memo ora
anche lo mette.
Zimmerman [Page 3]
RFC 1288 Finger December 1991
* Il BNF nella specifica del query non era chiaro nel trattare lo spazio
bianco. Questa memo è pi˘ precisa includendo un segno esplicito per questo.
* Il flusso di eventi in una conessione finger è ora meglio definito nell'
argomento della chiusura della connessione finger.
2. Uso del protocollo
2.1 Flusso degli eventi
Il finger è basato sul Protocollo di Controllo della Trasmissione (TCP =
Transmission Control Protocol), usando la porta TCP 79 decimale (117 in
base 8). L'host locale apre una connessione TCP su un host remoto nella porta
finger. Una RUIP diventa disponibile sul terminale remoto della connessione
per processare la richiesta. L'host locale manda alla RUIP una sola linea
di query basata sulla specifica della query del finger e aspetta che la RUIP
risponda. La RUIP riceve e processa la query, ritorna la risposta, quindi
inizia la chiusura della connessione. L'host locale riceve la risposta e
chiude il segnale, quindi procede ponendo fine alla connessione.
2.2. Formato dei dati
Ogni dato trasferito DEVE essere in formato ascii, senza parit‡, e con linee
che finiscono in CRLF (ascii 13 seguito da ascii 10). Questo esclude altri
formati di caratteri come il EBCDIC, etc. Ciò significa anche che alcuni
caratteri tra ascii 128 e ascii 255 potrebbero realmente essere
dati internazionali, non l'ascii a 7 bit con la parit‡.
2.3 Specifiche della query
Una RUIP DEVE accettare l'intera specifica della query del finger.
La specifica della query del finger è cosÏ definita:
{Q1} ::= [{W}|{W}{S}{U}]{C}
{Q2} ::= [{W}{S}][{U}]{H}{C}
{U} ::= username
{H} ::= @hostname | @hostname{H}
{W} ::= /W
{S} ::= <SP> | <SP>{S}
{C} ::= <CRLF>
Zimmerman [Page 4]
RFC 1288 Finger December 1991
{H},essendo ricorsiva, significa che non ci sono limiti arbitrari nel
numero dei @hostname nella query. Negli esempi della richiesta specifica
del {Q2}, il numero dei @hostname è limitato a due, semplicemente per brevi-
t‡. Occorre sapere che {Q1} e {Q2} non rimandano a un user digitando
"finger user@host" da un prompt di un sistema operativo. Rimandano alla linea
che una RUIP realmente riceve. CosÏ se un user digita "finger user@host<CRLF>"
, la RUIP nell'host remoto riceve "user<CRLF>", che corrisponde a {Q1}.
Questo perchè nessuna cosa nel protocollo IP "è tollerante in ciò che tu
accetti".
2.4. Comportamento della RUIP {Q2}
Una query di {Q2} è una richiesta per mandare una query a un'altra RUIP. Una
RUIP DEVE sia fornire o attivamente rifiutare questa servizio di inoltro
(vedi sezione 3.2.1). Se una RUIP fornisce questo servizio, DEVE seguire il
seguente comportamento:
Dato ciò:
Host <H1> apre una connessione finger <F1-2> a una RUIP in un host <H2>.
<H1> d‡ alla RUIP <H2> una query <Q1-2> di tipo {Q2} (per esempio
FOO@HOST1@HOST2).
Dovrebbe essere derivato che:
host <H3> è l'host pi˘ adatto in <Q1-2> (per esempio, HOST2)
La Query <Q2-3> è il resto di <Q1-2> dopo aver rimosso il pi˘ adatto
"@hostname" nella query (per es., FOO@HOST1)
E cosÏ:
La RUIP <H2> deve quindi aprirsi una connesione finger <F2-3> a <H3>
attraverso <F1-2>.
La RUIP <H2> deve ritornare qualche informazione ricevuta da <F2-3>
a <H1> attraverso <F1-2>.
La RUIP <H2> deve chiudere <F1-2> in circostanze normali solo quando
la RUIP <H3> chiude <F2-3>.
Zimmerman [Page 5]
RFC 1288 Finger December 1991
2.5. La risposta attesa della RUIP
Per la maggior parte, l'output di una RUIP non segue una stretta specifica
perchè è progettato per essere letto da persone invece che da programmi.
Dovrebbe principalmente sforzarsi di essere informativo.
L'output di QUALCHE uqery è soggetto alla discussione nella sezione sulla
sicurezza.
2.5.1. query {C}
Una query di {C} è una richiesta per una lista di tutti gli utlilizzatori on
line. Una RUIP DEVE sia rispondere o attivamente rifiutare (vedi sezione
3.2.2). Se risponde, allora deve fornire almeno il nome intero dell'user.
All'amministartore di sistema DOVREBBE essere permesso di includere altre
utili informazioni (vedi sezione 3.2.2), come:
-posizione del terminale
-posizione dell'ufficio
-numero di telefono dell'ufficio
-tipo di lavoro
-tempo di inattivit‡ (numero di minuti dall'ultimo input digitato o dall'
ultima attivit‡).
2.5.2. query {U}{C}
Una query di {U}{C} è una richiesta pi˘ approfondita dello stato di un user
{U}.
Se vuoi rifiutare questo servizio, probabilmente non vuoi il finger.
Una risposta deve includere almeno il nome intero dell'user. Se l'user è
connesso almeno la stessa quantit‡ di info fornite da {C} DEVE essere fornito
da {U}{C}.
Siccome questa è una query per informazioni su uno specifico user, l'ammini-
stratore di sistema DOVREBBE permettere la scelta di fornire utili info
addizionali (cfr sezione 3.2.3), come:
-luogo dell'ufficio
-numero di tel dell'ufficio
-numero di tel di casa
-stato del login (non connesso, tempo trascorso dall'ultima conessione, etc)
-file di informazioni dell'utente
Un file di informazioni dell'utente è una caratteristica per cui un user può
lasciare un breve messaggio che sar‡ incluso nella risposta alle richieste
del finger.
(Questo è a volte chiamato plan file). Questo è facilmente implementato
quando, per es., un programma aspetta un file di testo messo nella dir dell'
user o in qualche area comune;
Zimmerman [Page 6]
RFC 1288 Finger December 1991
il metodo esatto è lasciato all'implementatore. All'amministratore di sistema
DOVREBBE essere permesso di abilitarlo e disabilitarlo. Cfr la sezione 3.2.5
per le avvertenze.
2.5.3. L'ambiguit‡ di {U}
I nomi permessi nella linea di comando DEVONO includere l'user name o il
login name come sono definiti dal sistema. Se un nome è ambiguo,
all'amministratore di sistema DOVREBBE essere permesso di scegliere qualche
possibile adattamento (cfr 3.2.6)
2.5.4 Simbolo della query /W
Il simbolo /W nelle query {Q1} o {Q2} DOVREBBE essere interpretato all'
ultima RUIP per manifestare un pi˘ alto livello di prolissit‡ nell'output
sulle info sull'user, a alla peggio essere ignorata.
3. Sicurezza
3.1. Implementazione della sicurezza
La sana implementazione del finger è della massima importanza.
Le implementazioni dovrebbero essere testate contro varie forme di attacco.
In particolare, una RUIP DOVREBBE essere protetta contro input strani.
Chi vende il finger col sistema operativo o software per reti dovrebbe
testare la propria implementazione contro le penetrazioni.
Il finger è una delle vie pi˘ dirette alla penetrazione, come il worm Morris.
Come telnet, ftp e smtp, il finger è uno dei protocolli della sicurezza
perimetrale di un host.
Quindi, la sicurezza dell'implementazione è importante. L'implementazione
dovrebbe ricevere tanta accuratezza nella sicurezza durante il progetto
, l'implementazione, e i test come il telnet, ftp o smtp.
Zimmerman [Page 7]
RFC 1288 Finger December 1991
3.2. Sicurezza della RUIP
Attenzione! Il finger fornisce informazioni sugli users; inoltre, simile
informazione può essere considerata sensibile. Gli amministratori della
sicurezza dovrebbero prendere esplicite decisioni sul far girare il finger
e quali info fornire. Una implementazione esistente fornisce il tempo di
connessione dell'user, quando ha letto l'ultima volta le email, se c'è
posta in attesa, e da chi proviene la posta non letta. Questo rende
possibile tracciare conversazioni in corso e vedere dov'è focalizzata
l'attenzione di qualcuno. I siti intenzionati alla sicrezza sulle informa-
zioni non dovrebbero far girare il finger senza capire quante informazioni
d‡ via.
3.2.2. l'opzione {C}
Per ciò che concerne la sicurezza di un sito individuale, all'amministratore
di sistema DOVREBBE essere data un'opzione per abilitare e disabilitare
l'accettazione del {C}. Se la RUIP che processa la {C} è disabilitata, la RUIP
deve fornire un messaggio di rifiuto. "Finger online user list denied" è
adeguato. Il proposito di ciò è permettere agli hosts individualmente di
scegliere di non dare la lista degli users on line.
3.2.3. Flusso delle parti
Tutte le implementazioni del finger DOVREBBERO permettere a ogni amministra-
tore di sistema di decidere quali parti delle informazioni fornire alla query.
Per es.:
Zimmerman [Page 8]
RFC 1288 Finger December 1991
- All'amministratore A dovrebbe essere permesso di scegliere di fornire
specificatamente il luogo dell'ufficio, il numero di telefono dell'ufficio,
il numero di telefono di casa e il tempo di connessione e di non connessione.
- All'amministratore B dovrebbe essere permesso di scegliere di fornire solo
il luogo dell'ufficio e il numero di telefono dell'ufficio.
- All'amministratore B dovrebbe essere permesso di scegliere di fornire solo
la minima quantit‡ di info richieste, che è il nome intero delle persone.
3.2.4. File di info dell'utente
Permettere a una RUIP di fornire informazioni con un file modificabile di un
user dovrebbe essere visto come l'equivalente di fornire liberamente
qualunque info circa il tuo sistema. Questo è potenzialmente come abilitare
tutte le opzioni specificabili. Questa breccia nella sicurezza può essere
fatta in un numero di modi, qualcuno con l'intelligenza, altri con la forza.
Questo dovrebbe disturbare il sonno degli amministratori di sistema che
vogliono controllare le informazioni fornite.
3.2.5. Esecuzione di programmi dell'user
Permettere a una RUIP di far girare un programma di un user in risposta a una
query è potenzialmente pericoloso. Attenzione!, la RUIP non deve prmettere
che la sicurezza del sistema sia compromessa dal programma. Implementare
questa caratteristica può essere pi˘ preoccupante che utile, siccome ci sono
sempre bugs nei sistemi operativi, che potrebbero essere sfruttati attraverso
questo tipo di meccanismi.
3.2.6. L'ambiguit‡ di {U}
Essendo consapevoli che c'è un user malizioso, l'abile e/o persistente uso di
questa caratteristica può risultare in una lista della maggioranza degli
username in un sistema. Il rifiuto dell'ambiguit‡ di {U} dovrebbe essere
considerato alla stessa stregua del rifiuto delle richieste di {C} (cfr.
sezione 3.2.2).
3.2.7. Controllo delle tracce
Le implementazioni dovrebbero permettere agli amministratori di sistema
di loggare le query del finger.
3.3. Sicurezza del client
Ci si aspetta che ci sar‡ normalmente qualche programma client che l'user
usa per interrogare la RUIP iniziale. Per default, questo programma DOVREBBE
filtrare qualche dato non stampabile, lasciando solo i caratteri di 7 bit
stampabili (ascii 32 fino a ascii 126), tab (ascii 9), e CRLF.
Zimmerman [Page 9]
RFC 1288 Finger December 1991
Questo è oer proteggere contro le persone che con i codici escape, cambiando
altri nomi delle finestre x delle persone [peoples' X window names], o
commettendo altr vilt‡ o confondendosi. Due opzioni separate dell'user
DOVREBBERO essere considerate caratteri internazionali o di controllo:
-uno per permetter tutti i caratteri prima dell'ascii 32
-un altro per permettere tutti i caratteri pi˘ grandi dell'ascii 126
Per gli ambienti che vivono e respirano con dati internazionali, all'
amministratore di sistema DOVREBBE essere adto un meccanismo per abilitare
la seconda opzione per default per tutti gli user in un particolare sistema.
Questo può essere fatto attraverso una variabile di ambiente globale o
meccanismi simili.
4. Esempi
4.1. Esempio con un null command line ({C})
Site: elbereth.rutgers.edu
Command line: <CRLF>
Login Name TTY Idle When Office
rinehart Mark J. Rinehart p0 1:11 Mon 12:15 019 Hill x3166
greenfie Stephen J. Greenfiel p1 Mon 15:46 542 Hill x3074
rapatel Rocky - Rakesh Patel p3 4d Thu 00:58 028 Hill x2287
pleasant Mel Pleasant p4 3d Thu 21:32 019 Hill 908-932-
dphillip Dave Phillips p5 021: Sun 18:24 265 Hill x3792
dmk David Katinsky p6 2d Thu 14:11 028 Hill x2492
cherniss Cary Cherniss p7 5 Mon 15:42 127 Psychol x2008
harnaga Doug Harnaga p8 2:01 Mon 10:15 055 Hill x2351
brisco Thomas P. Brisco pe 2:09 Mon 13:37 h055 x2351
laidlaw Angus Laidlaw q0 1:55 Mon 11:26 E313C 648-5592
cje Chris Jarocha-Ernst q1 8 Mon 13:43 259 Hill x2413
4.2. Example with name specified ({U}{C})
Site: dimacs.rutgers.edu
Command line: pirmann<CRLF>
Login name: pirmann In real life: David Pirmann
Office: 016 Hill, x2443 Home phone: 989-8482
Directory: /dimacs/u1/pirmann Shell: /bin/tcsh
Last login Sat Jun 23 10:47 on ttyp0 from romulus.rutgers.
No unread mail
Project:
Plan:
Work Schedule, Summer 1990
Rutgers LCSR Operations, 908-932-2443
Zimmerman [Page 10]
RFC 1288 Finger December 1991
Monday 5pm - 12am
Tuesday 5pm - 12am
Wednesday 9am - 5pm
Thursday 9am - 5pm
Saturday 9am - 5pm
larf larf hoo hoo
4.3. Example with ambiguous name specified ({U}{C})
Site: elbereth.rutgers.edu
Command line: ron<CRLF>
Login name: spinner In real life: Ron Spinner
Office: Ops Cubby, x2443 Home phone: 463-7358
Directory: /u1/spinner Shell: /bin/tcsh
Last login Mon May 7 16:38 on ttyq7
Plan:
ught i
ca n
m a
' ... t
I . . i
! m
! ! e
p !pool
l
e
H
Login name: surak In real life: Ron Surak
Office: 000 OMB Dou, x9256
Directory: /u2/surak Shell: /bin/tcsh
Last login Fri Jul 27 09:55 on ttyq3
No Plan.
Login name: etter In real life: Ron Etter
Directory: /u2/etter Shell: /bin/tcsh
Never logged in.
No Plan.
4.4. Example of query type {Q2} ({U}{H}{H}{C})
Site: dimacs.rutgers.edu
Command line: hedrick@math.rutgers.edu@pilot.njin.net<CRLF>
[pilot.njin.net]
[math.rutgers.edu]
Login name: hedrick In real life: Charles Hedrick
Office: 484 Hill, x3088
Zimmerman [Page 11]
RFC 1288 Finger December 1991
Directory: /math/u2/hedrick Shell: /bin/tcsh
Last login Sun Jun 24 00:08 on ttyp1 from monster-gw.rutge
No unread mail
No Plan.
5. Riconoscimenti
Grazie a ognuno dell' Internet Engineering Task Force per i loro
commenti. Un grazie speciale a Steve Crocker per le sue raccomandazioni
sulla sicurezza e la sua prosa.
6. Considerazioni sulla sicurezza
I problemi sulla sicurezza sono discussi nella sezione 3.
7. Indirizzo dell'autore
David Paul Zimmerman
Center for Discrete Mathematics and
Theoretical Computer Science (DIMACS)
Rutgers University
P.O. Box 1179
Piscataway, NJ 08855-1179
Phone: (908)932-4592
EMail: dpz@dimacs.rutgers.edu
