rexec 与 512 端口
512 是一个双面端口：TCP 512 属于 Berkeley r-services 家族中的 rexec 远程执行，UDP 512 是 biff 与 comsat 邮件提醒服务。rexec 的认证模型建立在客户端源端口必须小于 1024 这一假设上，在今天的网络里等同于没有认证，因此它早已被 SSH 取代；UDP 侧的新邮件提醒功能在现代系统中也基本绝迹。排查老系统时，这类端口属于应当直接关闭的对象。
基本信息
| 服务 | exec（512/tcp）、comsat/biff（512/udp） |
|---|---|
| 协议 | TCP 与 UDP |
| 背景 | Berkeley r-services 家族 |
| 认证模型 | 基于来源特权端口的信任关系，等同无认证 |
| 现状 | rexec 应彻底禁用，biff 基本不再使用 |
| 替代方案 | SSH 单次命令执行与 SFTP |
典型使用场景
- 历史遗留系统维护：极少数老旧 UNIX 环境仍保留相关客户端
- 被动发现：扫描或资产盘点中发现这些端口时判断系统暴露面
- 加固验收：确认关闭结果是否符合基线要求
- 旧脚本迁移评估：梳理仍在调用远程执行的脚本，改为 SSH
- 事件排查：出现这些端口的连接时通常意味着异常访问
检查是否仍在监听 r-services
检查是否仍在监听 r-services
ss -ltnp | grep -E ':(512|513|514) ' # 逐个确认 TCP 端口是否在监听
ss -lunp | grep -E ':(512|514) ' # 512/udp 为 biff，514/udp 为 syslog
systemctl list-units --type=socket | grep -iE 'rexec|rlogin|rsh' # 是否由套接字单元托管
rpcinfo -p localhost 2>/dev/null | head # 顺带确认是否存在其他 RPC 暴露r-services 家族端口对照
| 端口 | 服务 | 风险 |
|---|---|---|
| 512/tcp | rexec 远程执行 | 基于源端口的信任，等于无认证 |
| 513/tcp | rlogin 远程登录 | 明文且依赖信任关系，凭据可被嗅探 |
| 514/tcp | rsh 远程 shell | 明文命令执行，常被用于横向移动 |
| 512/udp | biff 与 comsat | 暴露邮件到达信息，已基本废弃 |
| 514/udp | syslog 接收 | 默认无认证，可被伪造日志或注入垃圾 |
关闭与替代方案
关闭与替代方案
systemctl disable --now rexec.socket rlogin.socket rsh.socket # 由套接字激活的按此关闭
grep -rniE 'rexec|rsh|rlogin' /etc/inetd.conf /etc/xinetd.d/ 2>/dev/null # 传统超级守护进程中的残留配置
# 替代写法：把远程执行改为 SSH
ssh ops@host 'systemctl restart app' # 单次命令执行，自带加密与审计512 至 514 的 TCP 端口一旦对外开放，攻击者可直接获得远程命令执行或登录能力；这类服务没有可靠的加固手段，正确做法是关闭而不是限流。
内网同样要关：r-services 的信任模型只看来源地址与端口，内网任何一台被控制的主机都能借它横向跳到其他服务器，内网不等于可信。
排查思路调整：如果资产清单里出现 512、513、514 的 TCP 监听，先判断是否是历史系统遗留；确认无业务依赖后直接关闭，再核对依赖脚本并迁移到 SSH，避免为了兼容保留整条风险链。