767 是什么
767 的服务名是 phonebook，登记表里也写作 phone，IANA 登记说明为 phone，登记人 Josyula R Rao，协议为 TCP/UDP。名字指向目录或通讯录查询类功能，属于 1990 年代企业内部协作软件的常见组件。它与 754、776、780 出自同一登记人，说明这一批端口来自同一套系统的整体规划，处置时值得放在一起看。
基本信息
| 端口号 | 767（700-1023 系统端口区间） |
|---|---|
| 服务名 | phonebook（phone） |
| IANA 登记说明 | phone |
| 协议 | TCP、UDP 双登记 |
| 登记人 | Josyula R Rao |
| 功能类别 | 目录与通讯录查询 |
| 规范与实现 | 无公开规范，产品已退市 |
目录类服务的典型风险
- 目录里通常带有人员、分机、工位等信息，泄露后可用于社工与定向攻击
- 老目录服务查询往往不需认证，任意主机都可拉取全量条目
- 同步机制可能把主目录数据复制到多台主机，一处泄露等于多处泄露
- 产品退市后无补丁来源，潜在问题只能靠隔离缓解
- 目录数据一旦长期不更新，会与实际组织结构脱节，反过来影响业务判断
确认是否仍在提供查询
确认是否仍在提供查询
# 是否有监听
ss -lntup 'sport = :767'
# 是否存在查询行为（短时间内多次短连接很像批量拉取）
sudo ss -tnp | grep ':767' | head -20
# 抓包看返回数据量，判断是否在吐出目录内容
sudo timeout 20 tcpdump -nn -i any -c 30 'tcp port 767'
# 若确认在服务且无业务方，先限制来源再评估下线数据敏感度与处置
| 数据类型 | 敏感度 | 处置要点 |
|---|---|---|
| 人员与分机信息 | 中高 | 限制来源，评估是否改为现行系统承载 |
| 组织架构信息 | 中 | 确认业务方与使用频率 |
| 仅设备标识 | 低 | 按普通老服务处理 |
| 含口令或凭据 | 高 | 优先整改，必要时立即隔离 |
老目录服务的常见问题是查询无认证。评估时不妨直接问一个具体问题：任意一台内网主机能不能把全部条目拉下来。答案如果是能，就该列入整改。
同一登记人下的 754、767、776、780 建议合并成一条整改任务，一次确认业务依赖，避免反复走流程。