组织:中国互动出版网(http://www.china-pub.com/) RFC文档中文翻译计划(http://www.china-pub.com/compters/emook/aboutemook.htm) E-mail:ouyang@china-pub.com 译者:卢伍春(spacelu wuchun_lu@xanet.edu.cn) 译文发布时间:2001-6-15 版权:本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载,但必须 保留本文档的翻译及版权信息。 网络工作组 D. Zimmerman Request for Comments: 1288 Center for Discrete Mathematics and 废弃: RFCs 1196, 1194, 742 Theoretical Computer Science December 1991 Finger用户信息协议 (RFC1288 The Finger User Information Protocol) 备忘录状态 这个备忘录定义了用户信息交换协议.这个RFC详细说明了因特网中的IAB标准追踪协 议, 和讨论要求以及提高的建议.请查阅当前版本的"IAB正式协议标准"来确立协议规定和状态 的标准 化.该备忘录的发行没有限制. 摘要 这个备忘录描述了Finger用户信息协议.这是一个为远程用户信息程序提供接口的简单 协议. 以前面描述最初Finger协议的RFC742为基础,这个备忘录尽力阐明Finger连接两端 的期望通 讯.它还尽力不使前面许多存在的执行失效或增加对前面最初协议定义的不必要限制. 这个版本更正和阐明了RFC1196. 目录 1. 简介 ........................................... 2 1.1. 目的 ............................................... 2 1.2. 历史 .............................................. 3 1.3. 要求 ......................................... 3 1.4. 更新 .............................................. 3 2. 协议的使用 .................................... 4 2.1. 事物流 ....................................... 4 2.2. 数据格式 .......................................... 4 2.3. 查询指定 ................................. 4 2.4. RUIP {Q2} 表现 ................................... 5 2.5. 期望 RUIP 反映 ............................... 6 2.5.1. {C} 查询 .......................................... 6 2.5.2. {U}{C} 查询 ....................................... 6 2.5.3. {U} 不明确信息 ...................................... 7 2.5.4. /W 查询表示 ..................................... 7 2.5.5. 自动销售机 ................................... 7 3. 安全性 ............................................... 7 3.1. 安全执行 .............................. 7 3.2. RUIP 安全 ........................................ 8 3.2.1. {Q2} 拒绝 ....................................... 8 3.2.2. {C} 拒绝 ........................................ 8 3.2.3. 原子交换 ................................... 8 3.2.4. 用户信息文件 ............................. 9 3.2.5. 用户程序执行 ......................... 9 3.2.6. {U} 不明确信息 ...................................... 9 3.2.7. 审计跟踪 ....................................... 9 3.3. 客户安全 ...................................... 9 4. 例子 ............................................... 10 4.1. 空命令行例子 ({C}) ............... 10 4.2. 指定名例子 ({U}{C}) ................. 10 4.3. 不明确名例子 ({U}{C}) ....... 11 4.4. 查询类例子 {Q2} ({U}{H}{H}{C}) ............ 11 5. 确认 ........................................ 12 6. 安全考虑 ................................ 12 7. 作者地址 ....................................... 12 1. 介绍 1.1. 目的 这个备忘录描述了Finger用户信息协议.它是提供远程用户信息程序(RUIP)接 口的简单协议. 以前面描述最初Finger协议的RFC742为基础,这个备忘录尽力阐明Finger连接 两端的期望通讯.它还尽力不使前面许多存在的执行失效或增加对前面最初协议定义的 不必要限制. 现在最流行的Finger应用可能是从California,Eerkeley大学BSD UNIX工作室 发展起来的.因此,这个备忘录基于BSD版本内容. 但是,BSD版本提供很少选项针对特定站点安全政策的详细Finger RUIP,或者 保护用户以免受到危险数据的攻击.而且,它存在许多用户和管理员需要注意的安全隐患, 特别因为协议的目的是返回系统用户信息,最有可能发生问题的部分.因此,这个备忘录 提出了大量的重要安全建议和注释. 1.2. 历史 最初在Les Enrnest写的Finger程序是ITS命名程序的灵感.MIT的Earl Killian 和SAIL的Brian Harvery参加负责了最初协议的执行. Ken Harrenstien是RFC 742的作者."命名/Finger"是这个备忘录最初的状态. 1.3. 要求 在这个文档里,用来定义每一个重要的特别要求的词都用大写.这些词为: * "MUST" 这个词或形容词"REQUIRED"表示某项是说明书的绝对具备的要求. * "SHOULD" 它或形容词"RECOMMENDED"表示在特殊环境下可能存在一些原因使忽略这 个规则,但是在选择其他规则之前,应该了解完整应用和仔细权衡条件. * "MAY" 它或形容词"OPTIONAL"表示这个规则实际上是可选的.例如,一个买主可能选择 这个规则因为特殊的市场需要它或因为它能增强产品竞争力;但是另外一个买主可能不 用这个规则. 如果一个应用程序没有满足一个或多个必须(MUST)要求,则是不符合条件. 满足所有必须(MUST)和应该(SHOULD)条件的应用叫做无条件符合的;符合必须(MUST) 但是不符合所有应该(SHOULD)条件的叫做条件符合. 1.4. 修正 这个备忘录和RFC1196的差异为: o 在前面说明书中Finger的可选项/W开关错误的放置在一行的末尾.在这个 备忘录中,4.2BSD Finger指定它应该在前面. 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} ::= | {S} {C} ::= 递归的{H}表示查询中@主机名字表示的数量不会有特别的限制.在例子{Q2}请求 说明中,@hostname表示的数量限制为2. 注意{Q1}和{Q2}不是参考从操作系统命令的用户类型"finger 用户@主机".它指 出RUIP确切收到的数据.所以,如果一个用户敲下"finger user@host",远程主机的 RUIP收到和{Q1}对应的"user". 和IP协议组的任何部分一样,"对接收的信息不限制". 2.4. RUIP {Q2} 表现 {Q2}请求信息是发送到另外一个RUIP的请求.RUIP必须或者提供或动态拒绝这个 向前服务(看3.2.1).如某个RUIP提供这个服务,它必须符合下列要求: 如下: 主机

打开Finger连接到主机

上的RUIP.

RUIP一个(Q2}类型的查询. (e.g., FOO@HOST1@HOST2). 它源自: 主机

是在最右边的主机(如主机2) 查询在移去查询中最右端"@HOSTNAME"标志后的剩余.(如FOO@HOST1). 和:

RUIP必须自己用打开一个到

的Finger连接.

RUIP必须返回通过收到的任何信息. 除了

RUIP关掉连接外,

RUIP必须关掉正常情况下的. 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或者网络软件应该把它们的执行进行渗透测 试. 正如Morris worm形象指出的一样,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(ASCII 9),和CRLF。 这样将阻止一些人使用终端溢出设备代码,改变其他用户的X窗口名字,或提交其它卑 鄙的 或混乱的事实。两个孤立的用户选项应该认为是改变它们的行为,以至用户应该选择浏览国 际或控制 字符: -一个允许所有小于ASCII32的字符 -另外一个允许所有大于ASCII126的字符 对于生存和发出国际数据环境,应该给系统管理员提供一个机制,它能激活后面的在特 定系 统对所有用户默认选项。 4. 例子 4.1. 空命令行例子({C}) 网点:elbereth.rutgers.edu 命令行: 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. 特定名例子 ({U}{C}) 站点: dimacs.rutgers.edu 命令行: pirmann 登陆时间: pirmann 真名: David Pirmann 办公室: 016 Hill, x2443 家庭电话: 989-8482 路径: /dimacs/u1/pirmann Shell: /bin/tcsh 最后登陆 Sat Jun 23 10:47 on ttyp0 from romulus.rutgers. 没有未读文件 Project: Plan: Work Schedule, Summer 1990 Rutgers LCSR Operations, 908-932-2443 Monday 5pm - 12am Tuesday 5pm - 12am Wednesday 9am - 5pm Thursday 9am - 5pm Saturday 9am - 5pm larf larf hoo hoo 4.3. 没有明确指定名字例子 ({U}{C}) 站点: elbereth.rutgers.edu 命令行: ron 登陆时间: spinner 真名: Ron Spinner 办公室: Ops Cubby, x2443 家庭电话: 463-7358 路径: /u1/spinner Shell: /bin/tcsh 最后登陆 Mon May 7 16:38 on ttyq7 计划: ught i ca n m a ' ... t I . . i ! m ! ! e p !pool l e H 登陆名: surak 真名: Ron Surak 办公室: 000 OMB Dou, x9256 路径: /u2/surak Shell: /bin/tcsh 最后登陆 Fri Jul 27 09:55 on ttyq3 没有计划. 登陆名: etter 真名: Ron Etter 目录: /u2/etter Shell: /bin/tcsh 从未登陆. 没有计划. 4.4. 询问类型例子 {Q2} ({U}{H}{H}{C}) 站点: dimacs.rutgers.edu 命令行: hedrick@math.rutgers.edu@pilot.njin.net [pilot.njin.net] [math.rutgers.edu] 登陆名: hedrick 真名: Charles Hedrick 办公室: 484 Hill, x3088 路径: /math/u2/hedrick Shell: /bin/tcsh 最后登陆 Sun Jun 24 00:08 on ttyp1 from monster-gw.rutge 没有未读文件 没有计划. 5. 确认 感谢每一位在因特网工程任务的建议.特别感谢Steve Crocker的安全建议和 文章. 6. 安全考虑 安全问题在第3部分已经讨论. 7. 作者地址 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 RFC1288 The Finger User Information Protocol Finger用户信息协议 1