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是直接渗透的一个林荫道.象Telnet,FTP和SMTP,
Finger是主机安全范围的一个协议.相应的,执行的健康是极为重要的.在设计,执行和测试
中,
Finger应该和Telnet,FTP,或FTP接受一样的安全审查.
3.2.RUIP安全性
警告!!Finger揭示用户信息;此外,那些信息都是敏感的.安全治理应该对是否运行
Finger和什么信息应该响应必须作出明确的决定。现有的执行提供最后一次登陆时间，最后
一次读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