dtk 是什么
dtk 是登记在 365 上的 IANA 服务名，注册人是 Fred Cohen，安全圈常把 DTK 与 Deception ToolKit（欺骗防御工具包）联系起来，但注册表本身没有展开说明，也没有协议文档。欺骗防御的思路是让攻击者把时间花在假目标上，典型做法是开放大量看起来像真实服务的端口并记录访问行为。365 位于 0-1023 的知名端口段，绑定需要 root 或 CAP_NET_BIND_SERVICE，因此它的监听记录往往是分析访问来源的现成素材。
基本信息
| 服务名 | dtk（DTK） |
|---|---|
| 端口与协议 | 365，TCP 与 UDP 均有登记 |
| 注册情况 | IANA 早期登记项，无 RFC |
| 名称关联 | 常被联系到欺骗防御类工具 |
| 现网现状 | 研究用途为主，现网极少出现 |
| 权限要求 | 0-1023 段端口，绑定需 root 或 CAP_NET_BIND_SERVICE |
典型使用场景
- 欺骗环境识别：确认主机上的 365 监听是否属于蜜罐或欺骗类部署，而非真实业务
- 访问来源分析：若为欺骗端口，访问日志本身就是情报来源，可用于排查内网扫描
- 暴露面盘点：非欺骗场景下出现 365 监听，需确认程序来源与启动方式
- 规则治理：确认用途后决定是否保留放行条目，避免无意中扩大暴露面
- 安全运营流程：明确欺骗端口的责任人与日志留存要求，避免被误判为故障
定位与排查
定位与排查
ss -lntup 'sport = :365' # 查看 365 的监听与进程
sudo lsof -i :365 # 反查进程与可执行文件
awk '$2 ~ /:016D$/ {print}' /proc/net/tcp # 十六进制端口，365 = 0x016D
sudo tcpdump -nni any port 365 -c 20 # 采样看访问来源与频率
sudo journalctl -u <服务名> --since -1h # 结合服务日志判断是否为欺骗组件ss 输出逐列读法
| 列 | 含义 | 关注点 |
|---|---|---|
| State | LISTEN 监听、ESTAB 已连接 | 欺骗端口通常会出现大量短连接 |
| Recv-Q | 未读字节数 | 长期堆积说明记录程序未跟上访问节奏 |
| Send-Q | 未确认字节数 | 与链路和对端行为有关 |
| Local Address:Port | 本机地址与端口 | 欺骗端口一般对外可见，需评估影响范围 |
| Process | 程序名与 PID | 确认是否为安全团队部署的组件 |
欺骗类部署必须提前在资产与监控系统里登记，否则同一端口会被安全扫描、运维巡检和应急响应反复当成问题处理，既浪费人力，也容易在真实事件中被误判为无害监听而放过。登记内容至少包括：责任团队、部署范围、日志留存位置与预期访问特征。