名端口与调度平台撞号
安全圈里的著名撞号端口：NetBus 木马的历史默认端口，同时 DolphinScheduler 的 API 服务默认也用 12345。防火墙日志里出现这个端口时不能一刀切，要先看进程路径、证书特征与流量方向，再区分是正常调度平台还是明确的失陷信号。
基本信息
| 服务 | NetBus 木马（历史）/ DolphinScheduler API |
|---|---|
| 协议 | TCP |
| 默认端口 | 12345 |
| 定性依据 | 进程路径、证书特征、流量方向与业务用途 |
| 处置思路 | 结合上下文，不做单端口黑名单 |
典型使用场景
- 安全运营：出站连接里出现 12345 时先做定性
- 自动化平台的正常 API 流量识别
- 资产盘点：确认内部系统是否使用该默认端口
- 告警降噪：把已知业务端口加入白名单并写清注释
- 应急响应：确认失陷后按主机隔离流程处置
主机侧定性
主机侧定性
ss -ntp | grep 12345 # Linux：连进程一起看
netstat -ano | findstr 12345 # Windows
# 再按 pid 定位: tasklist /FI "PID eq <pid>" 或 ps -fp <pid>
curl -s http://ds01:12345/dolphinscheduler/ | head -c 200排障与核对
| 检查项 | 做法 | 异常表现 |
|---|---|---|
| 进程归属 | ss -ntp / netstat -ano 定位 pid | 进程路径在临时目录：按失陷流程处置 |
| 服务特征 | HTTP 响应与证书 CN | 返回业务页面：多为调度平台 |
| 流量方向 | 防火墙日志中的目标地址 | 内网主机主动连陌生公网地址：优先排查失陷 |
| 端口来源 | 配置文件中的端口声明 | 默认端口未改：属配置问题，不是入侵 |
按端口做黑名单是常见误区：12345 既可能是自家调度平台，也可能是外部木马回连，规则写死后会同时拦掉两者。更稳妥的做法是先维护业务占用端口台账，再对未知流量做处置。
为什么要先定性
单看端口号无法区分正常业务与恶意流量：判定的关键是进程是否来自可信路径、目标地址是否在业务范围内、连接是否由服务或计划任务发起。定性没做完就隔离，可能误停调度平台；定性做完了不动手，则会放过真正的后门。
内部系统使用这类「知名木马端口」时，应在资产表与防火墙规则里显式注明用途和责任人；否则每次扫描或多方协同都要重新解释一遍，长期消耗团队精力。
安全设备按端口黑名单直接拦 12345：很可能把自家调度平台一并拦停，业务中断之余还找不到原因。