摘要
- RFC 742 把只有 CRLF 的空行定义成默认查询:列出当前所有在线者,并鼓励返回姓名、终端地点、作业和空闲时间等便于人与人联系的资料。
- RFC 1288 保留了“一行提问、文本回答、随后断开”的小协议,却要求服务端要么回答、要么明确拒绝,并让管理员逐项决定披露什么。
- 79 端口只统一了提问的入口。Finger 不认证被查询者,不保证答案真实,也不给查询者取得资料的当然权利;人类可读的返回值仍是需要过滤的不可信输入。
空白并不意味着没有命令
在许多协议里,空行是分隔符、结束符,或者无事可做。Finger 恰恰把它变成信息量最大的入口。RFC 742 规定,客户端连接八进制 117、十进制 79 号 socket,发送一条以 CRLF 结束的命令行。命令行若为空,服务器应给出默认报告,列出当时所有使用该系统的人。
这份报告的目的不是供程序继续计算,而是让人读。规范没有规定固定格式,却建议至少给出每位用户的全名和能够确定的终端物理位置。作业名称、距离上次键盘输入或作业活动过去的分钟数,也被视为“合理而有用”。
若命令行写入一个用户名,问题就缩到个人。服务器可以回答此人是否在线、最后退出时间,并读取一份用户自行维护的短消息。那份文件后来通常被称为 plan。它像一块挂在网络门口的小黑板:今天在哪儿、怎样联系、正在做什么,均可由本人留下。
1977 年,这种服务的背景很具体。RFC 742 点名 SAIL、SRI 与 ITS 系统,记载 Les Earnest 在 SAIL 编写的 FINGER 启发了 ITS 的 NAME,并说明 Earl Killian 与 Brian Harvey 共同实现了网络协议。一个熟人众多、站点有限的研究共同体,会把“谁在线”理解成协作线索。
但协议一旦跨越原来的圈子,同一行空白就换了含义。请求者无需先说明目的,也无需证明与被列出的人有关系。默认问题不是“某位同事在吗”,而是“把所有人给我看”。最小报文因此承载了最大的枚举面。
互通只统一问法,没有统一答案
Finger 的输出故意宽松。不同系统掌握不同资料,也习惯不同的排版。只要返回对人有帮助的文字,协议就算完成使命。于是,79 端口与 CRLF 可以完全互通,披露内容却可能从一行姓名增长到房间、电话、shell、目录、邮件状态和私人计划。
/W 把“更多”写进了查询语法。早期文档把它叫作 Whois switch;最终的 RFC 1288 把 /W 放在查询开头,要求最后一个服务端把它理解成更详细的输出,或者干脆忽略。它不是另一个经过强认证的权限层,只是同一条通道里的详细度请求。
姓名匹配也会扩张。服务器必须理解本机登录名,还可以理解姓氏或全名。若输入含糊,系统可能返回多个候选。这样的设计方便记不清账号的人找到同事,也让攻击者即使拿不到空查询列表,仍可能反复利用含糊姓名推测大部分账号。
人类可读并不等于语义一致。一个站点的 “idle” 可能按上次键盘输入计算,另一个按作业活动计算;一个站点的 “not logged in” 可能附带上次退出,另一个只写一句拒绝。接收者看到的是答复者对本地状态的呈现,不是跨站点统一测量。
1990 年后的变化是把拒绝写进协议
RFC 1196 于 1990 年 12 月发布。它以当时常见的 BSD 行为为基础,试图在不破坏大量既有实现的前提下澄清通信。文档直言:协议的目的就是返回系统用户资料,这在安全上本来就是敏感问题。
一年后的 RFC 1288 修正 /W 的位置,补清空格语法,也更精确地说明谁先关闭连接。网络交换仍然很小:TCP 79、ASCII、一行 CRLF 结尾的查询、一个回答、连接关闭。真正新增的秩序在于政策结果必须被看见。
对于只含 CRLF 的 {C} 查询,远程用户信息程序必须回答或主动拒绝。若回答,至少给出全名;管理员应能决定是否再给终端位置、办公室、办公电话、作业名和空闲时间。若站点不愿列出在线人员,它不必用空白伪装“无人在线”,而可以明确表示 online user list denied。
这一区别决定了证据应怎样解释。“空列表”像是事实判断;“拒绝”则是政策判断。两者都没有泄露名单,但只有后者没有冒充世界状态。协议用一个负面结果,把隐私决定从沉默中分离出来。
RFC 1288 还提出按信息原子配置。管理员 A 可以公开办公室、办公与家庭电话、登录和退出时间;管理员 B 只给办公室与办公电话;管理员 C 只给规范要求的最低值——全名。共同端口不再意味着共同披露包。
转发改变了谁能够提问
Finger 的 Q2 查询允许在名称后面串接 @hostname。收到请求的服务器可以再向下一个服务器建立 Finger 连接,转交剩余问题,再把结果沿原连接返回。语法对主机链长度没有任意上限。
RFC 1288 要求服务器要么提供这种转发,要么明确拒绝,并建议默认拒绝。对网关尤其如此:外部来客若能让网关替自己查询内部主机,原本友好的人员查询就变成穿过安全边界的通道。
转发没有替原始请求者增加身份,也没有把内部资料自动变成公共资料。它只借用了中间主机的网络可达性。每一跳都讲同一种语法,不能证明每一跳都拥有向下一跳提问的正当权力。
因此,检查 Finger 暴露面不能只看“谁能直接连 79”。还要看谁能委托一台可达主机继续问,转发是否留下拒绝或日志,以及回答究竟来自哪一个终端服务。
plan 文件把写作权与传播权分开
plan 的魅力在于它由用户本人书写。相比管理员数据库,它更像个人状态:出差时间、值班安排、项目说明、替代联系方式。可是,作者控制内容,不等于作者看见全部受众。
RFC 1288 警告,允许服务端返回用户可修改文件,应当视同允许关于本系统的任何信息自由传播。用户可能无意中留下内部资料,也可能放入欺骗内容;读取文件的实现还可能踩进路径、权限或格式假设。
有些实现甚至允许查询触发用户程序。于是一个网络请求不再只是读取文本,而会执行本机代码。规范要求管理员能够关闭这项能力,并明确警告程序不得损害系统安全。便利功能把信息面扩成执行面,仍然只用一行查询触发。
这里至少有三种权力。用户决定写什么;运营者决定哪些用户资料可以越过主机边界;客户端决定怎样显示。任何一层的同意,都不能替另外两层作决定。
给人看的文字仍是不可信字节
因为 Finger 输出不遵循严格格式,人们很容易把它当成“只是文字”。RFC 1288 要求客户端默认过滤不可打印字符,只留下七位可打印 ASCII、制表符与 CRLF。原因很实际:终端转义序列可以改变别人的 X Window 标题,或者执行其他混淆动作。
发送端也有对应风险。RFC 742 已经提醒,用普通 Telnet 客户端直接连接 Finger,可能自动发送 IAC 选项协商,污染服务器要解析的命令行。两种工具都传文本,不代表它们在应用语义上可以互换。
所谓“面向人类”,只说明最终读者是谁,不能当作安全保证。客户端必须严格发送 Finger 的一行语法;收到的文字也必须先被当作外部输入,再决定哪些字符可以进入终端或界面。
守住进程与少披露资料是两件事
RFC 1288 借 Morris worm 强调 Finger 实现位于主机安全周界,应该像 Telnet、FTP、SMTP 一样接受渗透测试。这支持的结论很窄:协议再小,也会把解析代码直接暴露给不可信网络输入。
但实现没有漏洞,不等于资料披露合理。文档举例,有实现会返回用户最后登录、最后读信、是否有未读邮件,甚至最近一封未读邮件来自谁。攻击者可以由此追踪一段对话和某人的注意力。所有内存访问都正确,隐私仍可能失败。
反过来,回答字段很少,也不能证明守护进程安全。畸形输入、转发递归、用户程序和输出转义仍要单独验证。代码安全与信息最小化相互配合,却不能互相替代。
查询日志让政策具备事后证据。它可以揭示某个来源是否持续枚举姓名,是否使用转发,是否反复索要详细输出。但日志本身记录了谁对谁感兴趣,也需要限定访问、保存期限和用途。
注册表保存门牌,不发放知情权
当前 IANA 服务名与传输协议端口号注册表 在 TCP 与 UDP 的 79 端口都保留 finger。RFC 1288 所定义的交换使用 TCP。这些记录让实现知道传统服务名与门牌。
注册表不能证明某台主机今天启用了服务,也不能证明回答安全、最新或真实。端口分配协调相遇地点;是否开门、给什么资料、怎样理解文字,仍由运营者、用户和接收者分别承担。
这也解释了 Finger 与正式登记目录的差别。它常常暴露的是某台主机当下对登录会话的看法,加上一段用户自述。它既没有签署身份声明,也没有提供资料变更的行政责任链。
最有价值的改进,是让默认不再冒充权利
Finger 的历史不是一句“早期天真、后来安全”就能概括。1977 年文档已经承认输出各异,也看见 Telnet 协商会污染命令。后来的标准没有抹掉人与人联络的价值,而是把围绕这种价值的决定写得更清楚。
空查询仍可询问所有在线者,但服务端可以拒绝;姓名查询仍可返回详细资料,但字段由管理员选择;转发仍在语法中,但默认应关闭;plan 仍属于个人表达,但个人写作不保证无限传播安全;输出仍为人服务,但客户端必须过滤控制字符。
这不是协议自动实现的隐私,而是协议承认隐私政策必须落在何处。79 端口回答“到哪里问”;运营者回答“是否披露”;客户端回答“如何安全展示”。任何一方都不能从共享语法中取得替别人决定的权力。
来源与证据边界
- https://www.rfc-editor.org/rfc/rfc742.html
- https://www.rfc-editor.org/rfc/rfc1196.html
- https://www.rfc-editor.org/rfc/rfc1288.html
- https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.csv
这些一手资料证明协议沿革、查询与拒绝语义、安全建议和端口注册,不统计当前部署、攻击频率或任何具体站点今天的政策。本文不以 IANA 条目推断服务仍广泛开放,也不把 RFC 示例中的全部字段归给每一个历史实现。
会员简报
档案背景详情
使用相应会员等级登录,即可解锁完整简报与来源注释。
仅限 Strategic Circle
Strategic Circle
所有读者均可浏览。加入并登录后可解锁档案简报。
加入 Strategic Circle仅限 Leadership Alliance
Leadership Alliance
符合条件的 IP 资产所有者和管理层可登录查看 Leadership Alliance 简报。
加入 Leadership Alliance
