Finger用戶信息協議

1.介紹

1.1.目的
這個備忘錄描述了Finger用戶信息協議.它是提供遠程用戶信息程序(RUIP)接
口的簡單協議.
以前面描述最初Finger協議的RFC742為基礎,這個備忘錄盡力闡明Finger連接
兩端的期望通訊.它還盡力不使前面許多存在的執行失效或增加對前面最初協議定義的
不必要限制.
現在最流行的Finger應用可能是從California,Eerkeley大學BSDUNIX工作室
發展起來的.因此,這個備忘錄基于BSD版本內容.
但是,BSD版本提供很少選項針對特定站點安全政策的詳細FingerRUIP,或者
保護用戶以免受到危險數據的攻擊.而且,它存在許多用戶和管理員需要注意的安全隱患,
特別因為協議的目的是返回系統用戶信息,最有可能發生問題的部分.因此,這個備忘錄
提出了大量的重要安全建議和注釋.

1.2.歷史
最初在LesEnrnest寫的Finger程序是ITS命名程序的靈感.MIT的EarlKillian
和SAIL的BrianHarvery參加負責了最初協議的執行.
KenHarrenstien是RFC742的作者."命名/Finger"是這個備忘錄最初的狀態.

1.3.要求
在這個文檔里,用來定義每一個重要的特別要求的詞都用大寫.這些詞為:
*"MUST"
這個詞或形容詞"REQUIRED"表示某項是說明書的絕對具備的要求.
*"SHOULD"
它或形容詞"RECOMMENDED"表示在特殊環境下可能存在一些原因使忽略這
個規則,但是在選擇其他規則之前,應該了解完整應用和仔細權衡條件.
*"MAY"
它或形容詞"OPTIONAL"表示這個規則實際上是可選的.例如,一個買主可能選擇
這個規則因為特殊的市場需要它或因為它能增強產品競爭力;但是另外一個買主可能不
用這個規則.
如果一個應用程序沒有滿足一個或多個必須(MUST)要求,則是不符合條件.
滿足所有必須(MUST)和應該(SHOULD)條件的應用叫做無條件符合的;符合必須(MUST)
但是不符合所有應該(SHOULD)條件的叫做條件符合.
1.4.修正
這個備忘錄和RFC1196的差異為:
o在前面說明書中Finger的可選項/W開關錯誤的放置在一行的末尾.在這個
備忘錄中,4.2BSDFinger指定它應該在前面.
o在Finger查詢指定中的RNF處理空格不是很清楚.這個備忘錄通過包括清楚
的代號使之更加嚴格.
o現在Finger連接中的事物流在Finger的緊密連接方面更好的定義.
2.協議的使用
2.1.事物流
Finger基于傳輸控制協議(TCP),用TCP端口79.本地主機打開一個和遠程
主機在Finger端口的連接.在連接遠端主機的RUIP變成有效來處理請求.本地主機
發送給RUIP一行基于Finger查詢說明的請求,然后等待RUIP反應.RUIP接收處理這個
請求,返回答案,然后發起連接關閉.本地主機接收到答案和關閉信號,然后執行本地端
的關閉.
2.2.數據格式
任何傳輸的數據必須是ASCII格式,不用奇偶方式和CRLF結束行.這樣排除了
其他字符格式如EBCDIC,等等.這同時也表明任何在ASCII128到255的字符都真正是國際
數據,這個不是7位ASCII碼加上奇偶校驗.

2.3.請求說明
RUIP必須接收完整的Finger請求說明.
Finger請求說明定義為:
{Q1}::=[{W}|{W}{S}{U}]{C}

{Q2}::=[{W}{S}][{U}]{H}{C}

{U}::=用戶名

{H}::=@主機名|@主機名{H}

{W}::=/W

{S}::=<SP>|<SP>{S}

{C}::=<CRLF>
遞歸的{H}表示查詢中@主機名字表示的數量不會有特別的限制.在例子{Q2}請求
說明中,@hostname表示的數量限制為2.
注意{Q1}和{Q2}不是參考從操作系統命令的用戶類型"finger用戶@主機".它指
出RUIP確切收到的數據.所以,如果一個用戶敲下"fingeruser@host<CRLF>",遠程主機的
RUIP收到和{Q1}對應的"user<CRLF>".
和IP協議組的任何部分一樣,"對接收的信息不限制".

2.4.RUIP{Q2}表現
{Q2}請求信息是發送到另外一個RUIP的請求.RUIP必須或者提供或動態拒絕這個
向前服務(看3.2.1).如某個RUIP提供這個服務,它必須符合下列要求:
如下:
主機<H1>打開Finger連接<F1-2>到主機<H2>上的RUIP.
<H1>給<H2>RUIP一個(Q2}類型的查詢<Q1-2>.
(e.g.,FOO@HOST1@HOST2).
它源自:
主機<H3>是在<Q1-2>最右邊的主機(如主機2)
查詢<Q2-3>是<Q1-2>在移去查詢中最右端"@HOSTNAME"標志后的剩余.(如FOO@HOST1).
和:
<H2>RUIP必須自己用<Q2-3>打開一個到<H3>的Finger連接<F2-3>.
<H2>RUIP必須返回通過<F1-2>從<F2-3>收到的任何信息.
除了<H3>RUIP關掉<F2-3>連接外,<H2>RUIP必須關掉正常情況下的<F1-2>.
2.5.期望的RUIP反應:
大部分情況下,RUIP的結果不是遵循嚴格的規范,因為它是設計成人看的而
不是機器.它主要是致力于提供信息.任何查詢的輸出服從安全問題的討論.
2.5.1{C}查詢
{C}查詢是對所有在線用戶的請求.RUIP必須或者回答或者動態拒絕(看3.2.2).
如果RUIP應答,然后它必須至少提供用戶的全名.系統管理員應該允許包括其它有用的信
息,例如:
--終端位置
--辦公室位置
--辦公室電話號碼
--工作名稱
--空閑時間(自從最后一次輸入的分鐘數或自從最后工作起)
2.5.2.{U}{C}查詢
{U}{C}查詢是針對一個特定用戶{U}的深入狀態查詢.如果確實要拒絕這個服務,
你可能不要在第一位置運行Finger.
應答必須至少包括用戶全名.如果用戶登陸,因為用戶必須由{U}{C}返回,所以
至少相同數量的信息返回.
因為這個是對特定用戶的信息查詢,系統管理員應該允許返回附加的有用信息(
如3.2.3),例如:
-辦公室地址
-辦公室電話號碼
-家庭電話號碼
-登陸狀態(沒有登陸成功,注銷時間等)
-用戶信息文件
用戶信息文件是用戶在Finger請求應答中留下的短信息特性.(這有時稱為"計劃"
文件.)這使很容易在用戶本地目錄或一些公共區域尋找一些特殊命名文本文件;確切的方
式是執行的左邊.系統管理員應該允許特定的關掉或打開這個特性.看3.2.4的注意事項.
用戶可能運行程序適應Finger查詢.如果這個特性存在,系統管理員應該允許特別
指定打開或關閉它.看3.2.5注意事項.

2.5.3.{U}不明確
在命令行中允許的"名字"必須包括系統定義的"用戶名"或"登陸名".如果名字含混
不清,系統管理員應該允許選擇是否所有可能的出處按照某種方式返回.(看3.2.6)

2.5.4./W查詢記號
在{Q1}或{Q2}查詢類型中的記號/W應該最多在最后一個RUIP解釋成用戶信息輸出更
高冗于層,或者忽略掉.
2.5.5.販賣機
販賣機應該用對銷售或可能消費有效的所有列單對{C}請求反應.販賣機應該用特殊
產品或商品投幣孔的詳細數量或列表對{U}{C}進行響應.販賣機應該從來決不吃錢.
3.安全
3.1.安全執行
Finger的健康執行是最重要的.運行程序應該在各種不同的攻擊下測試.特別的,RUIP
應該防止畸形輸入.買主提供的操作系統Finger或者網絡軟件應該把它們的執行進行滲透測
試.
正如Morrisworm形象指出的一樣,Finger是直接滲透的一個林蔭道.象Te.net,FTP和SMTP,
Finger是主機安全范圍的一個協議.相應的,執行的健康是極為重要的.在設計,執行和測試
中,
Finger應該和Telnet,FTP,或FTP接受一樣的安全審查.
3.2.RUIP安全性
警告!!Finger揭示用戶信息;此外,那些信息都是敏感的.安全管理應該對是否運行
Finger和什么信息應該響應必須作出明確的決定?，F有的執行提供最后一次登陸時間，最后
一次讀mail的時間，是否未讀文件等待他，和最近未讀mail是誰發出來的。這使跟蹤正在
進
行的對話成為可能和可以看出某個人的注意集中在哪塊。具有信息安全意識的站點應該不要
運行對什么信息它該丟去沒有明確了解的Finger.

3.2.1.{Q2}拒絕
對個人站點安全問題,應該提供給系統管理員一些選項來個別關閉或打開{Q2}的RUIP
處理過程.如果{Q2}的RUIP處理過程關閉了,RUIP必須發揮某類的服務拒絕信息."Finger繼
續服
務否認"就足夠了.這樣的目的是允許主機選擇不讓Finger請求繼續,但是如果它選擇了這個,
則
一直這樣.
總之,根本很少情況下授權{Q2}處理過程,和遠遠低于拒絕{Q2}處理過程的情況數量.特
別的,注意如果一臺機器是安全防衛的一部分(也就是,它是從外面世界到內部機器組合的網
關),
那么打開{Q2}提供穿過安全邊界的一個路徑.因此,建議{Q2}處理選項默認為拒絕處理.肯定
不要
在網關機器激活它,如果沒有對安全應用考慮周全的話.
3.2.2.{C}拒絕
對個人安全站點問題,應該提供給系統管理員一個選項是個別關閉或打開{C}RUIP接收.
如果{C}的RUIP處理關閉,RUIP必須返回某類的服務拒絕信息."Finger在線用戶列表拒絕"
已經足
夠.這個的目的是允許個別主機選擇不把當前在線用戶列出來.

3.2.3.原子卸貨
所有Finger執行應該允許個人系統管理員裁減依據詢問返回的原子信息。例如：
-應該提供給管理員A特定選擇返回辦公室地址，辦公室電話號碼，家庭電話號碼，和登
陸/注銷時間。
-應該給管理員B提供特別地只有返回辦公室地址和辦公室電話號碼。
-應該給出管理員C特別地選擇返回必須信息的最小數量，它是用戶的全名。

3.2.4.用戶信息文件
允許RUIP返回用戶不可改變文件信息應該看成允許任何系統信息自由發布。也就是，可
能
和打開所有可指明選項。這個信息安全破壞有可能用好多方式，有些聰明點，其它則直接點。
這個
將影響想控制返回信息系統管理員的美夢。


3.2.5.用戶程序的執行
允許RUIP運行適應Finger詢問可能危險的用戶程序。注意！RUIP必須不允許系統安全
被那
個程序改變。執行這個特性可能比它所值更劃不來，因為在操作系統中總是存在許多錯誤，
而能夠
通過這種機制暴露出來。

3.2.6.{U}含糊不清
注意惡意用戶對這個特性的聰明和/或長時間使用可能導致系統的最常用用戶列表。應該
把{U}含糊性和{C}請求拒絕一致對待（看3.2.2)。

3.2.7.審計跟蹤
應用程序應該允許系統管理員記錄Finger查詢。


3.3.客戶安全
期望用戶客戶程序運行詢問初始RUIP信息正常。程序應該默認過濾任何不道德數據，只
留下
可打印7位字符（ASCII32到126），tabs(ASCII9），和CRLF。
這樣將阻止一些人使用終端溢出設備代碼，改變其他用戶的X窗口名字，或提交其它卑
鄙的
或混亂的事實。兩個孤立的用戶選項應該認為是改變它們的行為，以至用戶應該選擇瀏覽國
際或控制
字符：
-一個允許所有小于ASCII32的字符
-另外一個允許所有大于ASCII126的字符
對于生存和發出國際數據環境，應該給系統管理員提供一個機制，它能激活后面的在特
定系
統對所有用戶默認選項。

4.例子

4.1.空命令行例子({C})
網點:elbereth.rutgers.edu
命令行:<CRLF>

LoginNameTTYIdleWhenOffice
rinehartMarkJ.Rinehartp01:11Mon12:15019Hillx3166
greenfieStephenJ.Greenfielp1Mon15:46542Hillx3074
rapatelRocky-RakeshPatelp34dThu00:58028Hillx2287
pleasantMelPleasantp43dThu21:32019Hill908-932-
dphillipDavePhillipsp5021:Sun18:24265Hillx3792
dmkDavidKatinskyp62dThu14:11028Hillx2492
chernissCaryChernissp75Mon15:42127Psycholx2008
harnagaDougHarnagap82:01Mon10:15055Hillx2351
briscoThomasP.Briscope2:09Mon13:37h055x2351
laidlawAngusLaidlawq01:55Mon11:26E313C648-5592
cjeChrisJarocha-Ernstq18Mon13:43259Hillx2413

4.2.特定名例子({U}{C})

站點:dimacs.rutgers.edu
命令行:pirmann<CRLF>
登陸時間:pirmann真名:DavidPirmann
辦公室:016Hill,x2443家庭電話:989-8482
路徑:/dimacs/u1/pirmannShell:/bin/tcsh
最后登陸SatJun2310:47onttyp0fromromulus.rutgers.
沒有未讀文件
Project:
Plan:
WorkSchedule,Summer1990
RutgersLCSROperations,908-932-2443

Monday5pm-12am
Tuesday5pm-12am
Wednesday9am-5pm
Thursday9am-5pm
Saturday9am-5pm

larflarfhoohoo

4.3.沒有明確指定名字例子({U}{C})

站點:elbereth.rutgers.edu
命令行:ron<CRLF>
登陸時間:spinner真名:RonSpinner
辦公室:OpsCubby,x2443家庭電話:463-7358
路徑:/u1/spinnerShell:/bin/tcsh
最后登陸MonMay716:38onttyq7
計劃:
ughti
can
ma
'...t
I..i
!m
!!e
p!pool
l
e
H

登陸名:surak 真名:RonSurak
辦公室:000OMBDou,x9256
路徑:/u2/surakShell:/bin/tcsh
最后登陸FriJul2709:55onttyq3
沒有計劃.

登陸名:etter 真名:RonEtter
目錄:/u2/etterShell:/bin/tcsh
從未登陸.
沒有計劃.

4.4.詢問類型例子{Q2}({U}{H}{H}{C})

站點:dimacs.rutgers.edu
命令行:hedrick@math.rutgers.edu@pilot.njin.net<CRLF>
[pilot.njin.net]
[math.rutgers.edu]
登陸名:hedrick真名:CharlesHedrick
辦公室:484Hill,x3088

路徑:/math/u2/hedrickShell:/bin/tcsh
最后登陸SunJun2400:08onttyp1frommonster-gw.rutge
沒有未讀文件
沒有計劃.

5.確認
感謝每一位在因特網工程任務的建議.特別感謝SteveCrocker的安全建議和
文章.
6.安全考慮

安全問題在第3部分已經討論.

7.作者地址

DavidPaulZimmerman
CenterforDiscreteMathematicsand
TheoreticalComputerScience(DIMACS)
RutgersUniversity
P.O.Box1179
Piscataway,NJ08855-1179

Phone:(908)932-4592

EMail:dpz@dimacs.rutgers.edu