终端管控软件清单与 netadmin 监控边界分析(USB 分流能被监控吗)
日期：2026-09-16 | 主机：Ubuntu 22.04 工作机 | 方法：全部为本机实证（ps/systemctl/ss/resolvectl/nft/git),无猜测
关联：netadmin 分流系统(见 netadmin 项目文档)、netadmin
深挖版：Corplink-eDLP监控策略取证(4 路并行取证：策略配置/二进制静态分析/上报通道/16 万行全量日志)
1. 本机企业管控软件清单（实证）
| 软件 | 进程/服务 | 权限 | 状态 | 外联 |
|---|
| Corplink（飞连零信任客户端） | corplink-service + 多个 corplink-uc | root + user | 运行中 | 长连 fly.mioffice.cn:10443(=10.237.25.5,TLS) |
| ESET Management Agent | ERAAgent / eraagent.service | root | 运行中 | new.nod32.mioffice.cn:2222(gRPC)+ EPNS MQTT 长连 |
| ESET Endpoint Antivirus (eea) | eea.service | root | failed（从未跑起：内核模块编译缺 gcc-12) | — |
| auditd | auditd.service | root | enabled 但 rules 为空（等于摆设） | — |
Corplink 已加载组件（/opt/Corplink/bin/components.json 实证）
net_channel（网络通道）、availability、config_center、app_bridgeedlp（企业数据防泄漏，system 权限，独立进程） + edlp_ui（截屏执行器）av（杀毒组件，system，百度引擎）、threat_intelligence（威胁情报，.so 缺失空转）
- 理论能力全集(libedlp.so 实证）:fanotify 文件操作全量审计、敏感内容识别（Hyperscan)、文档正文抽取（压缩包穿透）、本地 OCR、Git/SVN push 监控、USB 只读重挂载、打印/浏览器上传监控、全盘敏感扫描、事件触发”前中后三张”取证截屏 + 预签名 URI 直传
- 本机实际状态:文件审计恒
disable dlp、截屏恒 enable:0(3013 次汇报无一例外、落盘目录空）、外设管控恒 enable:0、上传 0 成功、OCR/水印零调用 → 三大能力全部关闭，零产出
- ⚠️ 09-16 14:44 eDLP 主策略开关翻为
enable:1（子功能仍全关），服务端异动需持续盯
- 定性：文件/行为审计型 DLP（端点层），不是流量镜像型；无 TLS 中间人能力（无 CA 注入）
2. 已实证”没有”的监控手段
| 手段 | 检查方法 | 结果 |
|---|
| 流量透明代理/镜像 | nft list ruleset / iptables-save -t nat | 仅 Docker 规则，无 REDIRECT/TPROXY/DNAT |
| 公司根 CA(TLS 中间人前提） | /usr/local/share/ca-certificates、/etc/ssl/certs、trust list | 无任何公司 CA → 任意路径上都无法合法解密 TLS |
| Chrome 受管策略/强制扩展 | /etc/opt/chrome/policies/managed | 不存在 |
| 全局代理环境变量 | env、/etc/environment | 无 |
| 抓包进程 | /proc/net/packet 属主核查 | 仅 wpa_supplicant/NetworkManager(EAPoL/ARP),无 ETH_P_ALL 嗅探 |
| 采集型 eBPF | bpftool prog list | 仅 hid_tail_call(HID 驱动）与 cgroup_device(systemd) |
| 管控内核模块 | lsmod | 无 eset/corplink 模块（eDLP 纯用户态） |
| VPN 隧道接管 | ip link | 无 tun/tap（零信任隧道未建立） |
3. netadmin 分流现状（同日实证）
- 白名单 = /32 IPv4 主机路由
via 192.168.250.177(USB 手机）;默认路由仍 eno1 公司网（metric 100 vs 101)
- DNS 分流：USB link 配置 route-only 域
~api.openai.com ~api.anthropic.com ...,whitelist 域名解析走手机 DNS（绕过公司 DNS 10.237.25.8/9)
- 实测
resolvectl query api.openai.com → link: enxa245d59ed9cb ✓
- 本机 53 端口：systemd-resolved(127.0.0.53)+ NetworkManager dnsmasq(127.0.0.1,Corplink 注入
strict-order)
- 09-16 新增：双手机冗余(K80 Pro + 15S Pro 任一在线即分流，failover 自动 re-pin)+ v6_guard（见 §5)
4. 监控边界五层模型
App → [①端点层: root代理] → 内核路由 → [②USB链路] → [③手机] → [④运营商] → 互联网
↑ 公司网络层(防火墙/DNS/网关)只在 eno1 路径上
| 层 | 观察者 | USB 分流是否有效 |
|---|
| 公司网络层 | 防火墙/网关/DNS 10.237.25.8/9 | ✅ IPv4 白名单流量完全绕过 |
| 端点层 | Corplink eDLP / ESET(root) | ❌ 代理在分流决策上游，分流对其天然无效；但取证定案其审计/截屏/外设当前全关零产出，实际在跑的只有遥测（CPU/内存/进程/WiFi/软件清单）——见 Corplink-eDLP监控策略取证 |
| 手机 | 无公司 MDM（个人机） | ✅ 公司够不到 |
| 运营商 | 元数据（IP/SNI/明文DNS) | 替代公司成为网络侧观察者；TLS 内容不可见 |
| 行为画像 | 设备姿态上报（多网卡可见）+ 公司网”零流量缺席”信号 | ⚠️ 元数据层面躲不掉 |
5. ✅ 已修复：IPv6 泄漏（v6_guard,2026-09-16 落地）
问题（09-16 上午定案）:
- eno1 持有 RA 下发的全局 IPv6 + v6 默认路由 metric 100;USB 链路仅 link-local,无 v6 出口
- netadmin 白名单路由全部是 IPv4 /32
- 实测白名单域名经 USB DNS 仍返回 AAAA（运营商 DNS 污染，api.openai.com → facebook 段 2a03:2880:*)
- Chrome/curl Happy Eyeballs 优选 IPv6 → 白名单域名的 v6 流量直接走 eno1 公司网+公司 DNS
修复（09-16 同日落地）:v6_guard=true（默认开）——静态 v6 默认路由经主用手机，metric 90 压过 eno1 RA(100);USB 全断时摘除；老手机无前转 v6 时 fail 而非漏。
6. 残余泄漏点清单
| 泄漏点 | 现状 | 说明 |
|---|
| IPv6 | 已修 | v6_guard(09-16):静态 v6 默认走手机 metric 90 压 RA |
| 非白名单域名 DNS | 设计如此 | 全走公司 DNS，访问历史公司可见 |
| USB 断线回滚窗口 | 设计如此 | usb_fallback_enabled=true 时回滚期流量回公司网；strict_pin=true 时 blackhole fail-closed |
| eDLP 文件审计/截屏 | 无解（也不动它） | 端点层与网络路径无关 |
| 运营商 DNS 污染 | 观测到 | AAAA 返回异常段；TLS 证书校验兜底内容安全 |
7. 结论
- 走 USB 的 IPv4 白名单流量：公司网络侧（防火墙/DNS/网关）看不到，netadmin 有效；
- 公司在这台机器上的 root 端点代理（eDLP/ESET)与走哪张网卡无关——这是防护的物理上限，属正常企业管理软件，不改动、不对抗；取证定案其审计能力当前全部关闭、零产出（09-16 主策略开关翻 1，需盯子功能）;
- 唯一实证的分流破口 IPv6 已于 09-16 修复(v6_guard：静态 v6 默认走手机 metric 90 压 RA，全断摘除）。