objcall 是什么
objcall（Tivoli Object Dispatcher）是 IANA 在 0-99 系统端口段保留的历史注册，TCP 与 UDP 同名登记，登记人为 Tom Bereiter。它属于 Tivoli 系统管理套件的早期组件，用来调度管理平台内部的对象分发与调用。Tivoli 后来并入 IBM 产品线，早期私有协议被标准接口与消息总线取代，该端口在新体系中已无实现。今天在主机上看到 94 号被监听，几乎都不是 Tivoli，而是别的程序占了低位号。
基本信息
| 服务名 | objcall（Tivoli Object Dispatcher） |
|---|---|
| 端口号 | 94（TCP/UDP 同名登记） |
| IANA 登记说明 | Tivoli Object Dispatcher |
| 登记人 | Tom Bereiter |
| 所属号段 | 0-1023 系统端口（System Ports） |
| 号段规则 | 该段新增分配需 IETF 评审，历史注册不会自动回收 |
| 现状 | 产品演进后弃用，无现代实现 |
| 处置口径 | 按未知服务核实进程与业务归属 |
现网出现时怎么处置
- 确认监听者身份：先在主机上用 ss 或 lsof 找到持有 94 的进程，记录可执行文件路径与启动用户
- 判断暴露面：看监听地址是 127.0.0.1 还是 0.0.0.0，前者通常是本机组件，后者需要额外解释
- 对照业务台账：把进程、启动方式（systemd 单元、计划任务、容器）与在册业务比对，无主进程按未知服务处理
- 观察对端流量：存在 ESTABLISHED 连接时记录远端地址与端口，区分内部扫描、监控采集和外部探测
- 留证后再动作：隔离或下线前保存进程信息、文件哈希与网络日志，便于事后回溯
定位占用进程
定位占用进程
ss -lntup 'sport = :94' # Linux：列出 94 的 TCP/UDP 监听与进程
sudo lsof -i :94 # 打开 94 端口的进程与文件描述符
sudo fuser -n tcp 94 # 只看谁占着这个 TCP 端口
ss -tnp state established '( sport = :94 )' # 已建立连接及对端
netstat -ano | findstr :94 # Windows：列出端口与对应 PID
tasklist /FI "PID eq 1234" # Windows：用 PID 反查进程名
nmap -sV -p 94 10.0.0.5 # 服务指纹探测（仅限已授权目标）历史沿革
| 阶段 | 状态 | 说明 |
|---|---|---|
| 登记期 | 私有协议注册 | 厂商为套件内部组件申请专用端口，避开既有服务 |
| 产品期 | 随套件部署 | 端口只在 Tivoli 管理域内部使用，不面向公网 |
| 并入 IBM 后 | 逐步替换 | 私有协议被标准接口与消息总线取代，端口退出使用 |
| 现状 | 名录保留 | IANA 仍记录该服务名，但无实现存在 |
objcall 是有正式登记的历史服务名，不是恶意程序的专属标记。反过来，扫描器也常把低频端口直接标成可疑。判断依据始终是主机上的进程与业务归属，而不是端口号本身。
0-1023 在 Unix/Linux 上默认只有 root 或具备 CAP_NET_BIND_SERVICE 的进程能绑定。若看到普通业务账号占用 94，说明系统做过额外授权或程序带能力位启动，这类变更值得追查来源。