海上飞棚 公开笔记 · 静态阅读

7890 端口被恶意利用事件记录

更新于 2026-09-13

7890 端口被恶意利用事件记录

记录这次本机 mihomo(Clash.Meta)公开代理漏洞被外部滥用的全过程：发现 → 诊断 → 封堵 → 处置建议。 事件时间：2026-08-20 13:20 ~ 13:36

1. 事件性质（一句话总结）

本机运行的 mihomo（Clash Meta）代理,因为配置了 allow-lan: true + bind-address: '*' + 无任何认证而监听在公网 0.0.0.0:7890,被外部大量海外机器当免费公开 SOCKS5 代理滥用,用于转发赌博/色情站流量、发垃圾邮件(SMTP)、扫描撞库等黑灰产行为。

2. 背景：为什么会暴露

起因是排查"慢机访问 Docker/GitHub 慢"的问题网络。本机是服务主力(148 个 docker 容器 + NPM),上面本来就跑着一个 mihomo(clash 机场客户端),用于出国加速。

查 mihomo 的网络分流时发现异常——mihomo 监听在 0.0.0.0:7890(全网卡),而配置里 allow-lan: true,且没有 authentication 认证段。这意味着任何能连到这台的机器,都能直接当代理用,无需账号密码。

3. 发现恶意利用的信号（证据）

3.1 端口监听探测

ss -tlnp | grep mihomo
LISTEN  0  4096  127.0.0.1:9090  0.0.0.0:*   mihomo   # external-controller(仅本机)
LISTEN  0  4096  *:7890          0.0.0.0:*   mihomo   # mixed-port(全网! 危险)

3.2 API 里揭示的真实情况（mihomo REST API 127.0.0.1:9090/connections）

  • 总下载流量 171 GB / 总上传 278 GB → 这台 mihomo 被当代理吐了大量流量
  • 活跃连接一度达 7000+ 条,绝大多数 type: Socks5
  • 连接来源(sourceIP)全是海外 IP： 81.171.72.94 / 91.148.228.53 / 91.148.248.68 / 134.19.179.50 37.46.225.249 / 85.12.29.43 / 217.24.172.50 / 198.44.133.131 / 193.37.252.71 ... 这些几乎清一色是俄罗斯/欧洲数据中心段,并非本机(127.0.0.1)或私网来源。
  • 规则命中统计：7137 条走机场代理出口（那个机场节点）,仅 17 条 DIRECT → 恶意流量全部跑在你的节点出口上。

4. 恶意流量都干了什么（概览）

从封堵前 journalctl -u mihomo 的 warning 日志分析,这些被借用的流量主要流向以下类型：

  • 赌博 / 博彩 / 黑帽 SEO 站群（大量伪装成正常词的域名跑黑灰产流量）
  • 仿冒 / 钓鱼 / 恶意注册站（仿冒正规企业或机构域名）
  • 色情内容站点
  • 高危 raw-IP 直连 + 邮件端口（SMTP :25/:587） → 特征为发垃圾邮件 + 无域名扫描/爬虫（情报性质最严重）
  • 撞库 / 登录爆破接口（微软登录、Roblox、Instagram 等认证接口）

具体域名与攻击者 IP 的详细清单见私有笔记 7890恶意网站详细清单（不公开）。

来源(source attacker IP)：清一色俄罗斯/欧洲数据中心段，并非本机或私网来源。

5. 造成的实际影响

  1. 节点流量被白白消耗：约 171GB 下载 / 278GB 上传，是别人借你的出国加速节点跑的，直接烧你套餐流量/节点配额，封堵后应停止流失。
  2. 出口 IP 信誉被污染：你的节点出口 IP 大量参与赌博/垃圾邮件/撞库,会被相关站点和邮件黑名单标记,表现为出国访问莫名变慢/被拒/验证码增多("感觉越用越慢"很可能与此相关)。
  3. 安全与合规风险：黑产通过你的出口做违规行为,若涉及溯源会落到你的节点/账号上。

6. 处置措施（已实施）

  1. 备份原配置：cp /etc/mihomo/config.yaml /etc/mihomo/config.yaml.bak-<时间戳>
  2. 修改 /etc/mihomo/config.yaml： - allow-lan: false - bind-address: '127.0.0.1'（只监听本机回环）
  3. systemctl restart mihomo 生效
  4. 防火墙兜底（即使以后配置改回也不放行外部）： iptables -A INPUT ! -s 127.0.0.1 -p tcp --dport 7890 -j DROP iptables -A INPUT ! -s 127.0.0.1 -p tcp --dport 9090 -j DROP

有效性验证

  • 重启后 ss -tlnp|grep mihomo → 只监听 127.0.0.1:7890 和 127.0.0.1:9090
  • 外网测 nc -vz 103.217.201.96 7890 → Connection refused
  • mihomo API /connections → 活跃连接 0,downloadTotal/uploadTotal 归零
  • 本机 127.0.0.1:7890 走 loopback 仍可正常访问（本机程序不受影响）
  • mihomo 服务 systemctl is-enabled → enabled（持久化,重启不丢）

7. 复现该隐患的关键点 / 教训

  1. 本地跑 clash/mihomo 千万不要无脑开 allow-lan: true —— 没加认证就等于是把翻墙出口公开给全网。
  2. 只要开了监听端口,优先做法是： - 仅在 127.0.0.1 监听；或 - 加 authentication 账号；或 - 防火墙 IP 白名单。
  3. external-controller(9090)也应只绑 127.0.0.1（本机 OK,已是这样）。
  4. 疑似出口 IP 被污染时,可以换机场节点 IP / 重置节点,清洗信誉。
  5. mihomo 的 REST API 是排查被利用的好工具：curl 127.0.0.1:9090/connections 能直接看到每个连接的来源 IP、目标、规则链路和总流量。

8. 相关/后续

  • 安全修复也补充进了 WireGuard多跳搭建.md 第 8 节
  • 经验教训已写入 AGENTS.md（本地代理端口安全）
  • 后续若用到 mihomo 开放给局域网,务必：allow-lan: true + 认证 + 防火墙白名单 三者齐全。