服务器被入侵当肉鸡挖矿一套SSH安全加固指南我半小时救回朋友的云服务器上个月凌晨一点多我刚放下手机准备睡觉朋友弹过来一串语音“哥我服务器CPU告警96%网站已经打不开了里面还有客户数据救一下。”我爬起来开电脑——人生第一次处理真实入侵没想到一上来就是最麻烦的肉鸡挖矿。登录上去扫了一眼一个伪装成crond的进程几乎吃满全部核心落盘路径藏在/tmp/.X11-unix/这种临时目录里明显在刻意躲人再翻/var/log/auth.log几万条SSH失败登录记录排得密密麻麻。那一刻我反而冷静了思路非常清晰先隔离、再加固、最后清理恢复。整个过程半小时左右今天把当时的排查思路和落地配置完整复盘一遍给所有把SSH暴露在公网上的运维、站长、独立开发者一份直接能抄作业的模板。全程不花钱全靠开源和系统自带工具。1. 紧急状态判断先摸清“被控制到什么程度”处理服务器入侵和平时排障最大的区别在于你要面对的是一个有意识的对手而不是一段报错的日志。他可能已经拿到了root权限可能清理过痕迹可能预留了好几个后门。所以第一步绝对不能是“找到进程把它kill掉”——你得先搞清楚这机器到底被人折腾成什么样了再动手。1.1 CPU异常只是表象要顺着进程挖出真实身份我登录后的第一件事就是跑下面三组命令别嫌基础关键时候真能救命top -c # 按CPU排序看最耗资源的进程长什么样 ps aux --sort-%cpu | head -20 # 更详细的进程信息 ss -antp | grep ESTAB # 当前所有对外连接当时top里那个进程的名字叫“crond”乍一看像是系统计划任务但破绽太多了正常crond的启动路径是/usr/sbin/crond它却在/tmp/.X11-unix/下运行用户名是root但父进程根本对不上网络连接里它还持续往几个海外IP发数据包。这些特征几乎可以断定它就是挖矿程序本体。在ps的输出里我还会用ls -l /proc/PID/exe去看这个进程真正的可执行文件路径用cat /proc/PID/cmdline看完整启动参数。如果运行时已经带上特殊参数或者exe后面有“(deleted)”字样说明攻击者把源文件删了但进程还在跑这种内存驻留型最恶心必须连根拔起。1.2 先隔离再清理快照和防火墙是双保险不管三七二十一直接kill进程是最常见的翻车操作。攻击者往往设置了守护进程进程死了会自动拉起来甚至触发报警让他提前销毁证据。正确顺序是先隔离再取证最后清理。我的做法是三步走在云服务商控制台给磁盘打快照。这相当于事故现场的封存万一后面清理时误删了重要数据还能从快照恢复。立即收紧安全组/防火墙规则只保留我当前办公IP的访问权限。这一步等于把门关上让攻击者连不进来也切断了挖矿程序与矿池通信的通道。在控制台的VNC/远程终端里登录操作尽量不走SSH。因为攻击者如果还连在会话里他可能看到你敲的每条命令甚至抢先动手。有人嫌打快照浪费时间但后来我朋友的服务器清理完依然有业务文件损坏靠这个快照硬是救回了客户的配置数据。所以别省这一步。1.3 排查顺序要有章法进程-连接-自启三项联动单纯杀掉一个进程没有任何意义。攻击者为了保证挖矿程序长期存活一定会配置多种自启动手段。所以我把排查分成三层正在跑的进程、已建立的网络连接、以及打算自动运行的计划任务。进程层用上面提到的top和ps网络层用ss看外向连接重点查那些连到非标准端口和境外IP的记录自启层则要翻crontab、/etc/rc.local、systemd的timer和service。后面第四部分我会把清理步骤展开讲这里先记住一个原则清理动作必须“进程、持久化、凭证”三者一起做少一环都可能被再次打穿。2. 从日志里挖出攻击路径为什么偏偏是你这台机器隔离做完服务器暂时安全了但你得弄清楚攻击者是怎么进来的。不搞明白这个问题就算你完美加固一遍对方换个路径照样能进来。我朋友这台机器的情况其实非常典型从日志里一眼就能看出端倪。2.1 auth.log里的暴力破解痕迹SSH的登录记录集中在/var/log/auth.logDebian/Ubuntu系或/var/log/secureCentOS/RHEL系。我先跑了这两条grep Failed password /var/log/auth.log | tail -100 grep Accepted /var/log/auth.log | tail -30第一条是失败登录记录第二条是成功登录记录。朋友这台机器的情况很典型失败记录有几万条来源IP五花八门从凌晨到深夜没停过更致命的是最后几条记录里竟然出现了几行“Accepted password for root from 1.2.3.4”时间恰好和CPU飙高的节点吻合。换句话说攻击者用某个密码直接在root账号上成功登录了。这种“撞库爆破组合拳”是当下扫描全网SSH端口最常用的套路。攻击者手里握着海量的用户名密码组合往你的22端口上批量尝试试中就进。你可能会想“我密码不弱啊怎么会试中”现实是很多人习惯在一台机器上复用密码而那个密码早在别的网站泄露库里躺着了。2.2 三个最容易成为突破口的薄弱点从我处理过的以及身边人遇到的入侵案例来看SSH被攻破基本逃不出这三个原因薄弱点典型表现后果弱密码/复用密码账号密码在其他平台泄露过攻击者直接撞库登录暴露root账号PermitRootLogin yes还开着密码登录省去提权瞬间拿下最高权限默认22端口全网扫描的重灾区一天被打几千次攻击面最大随时被爆破朋友的服务器三条全中root可以密码登录、密码是早期某个项目的复用密码、端口还是默认的22。在这样的配置下被攻破只是时间问题谈不上技术含量。2.3 判断“被控制程度”的几个关键指标确认了攻击路径还得评估破坏范围。我快速过了一遍这四个位置awk -F: $30 {print $1} /etc/passwd # 列出所有UID为0的账号 cat /root/.ssh/authorized_keys # 看有没有被塞入陌生公钥 crontab -l ls -la /etc/cron.d/ # 检查计划任务 systemctl list-units --typeservice --staterunning # 检查正在运行的服务结果不太妙/root/.ssh/authorized_keys里多了一把来路不明的公钥。这意味着攻击者不光用密码登录过还留了一手“钥匙”以后哪怕你改了root密码他还能用这把公钥无缝进来。这种情况就别想着保留原系统了加固完成后直接把所有凭证彻底轮换一遍。3. SSH安全加固实操半小时完成的完整方案排查清楚后我开始落地真正的安全加固。以下所有操作都是通用做法你不需要等到被入侵才做建议新服务器上手直接照抄。3.1 第一层公钥认证替代密码登录密码爆破能成功核心原因是“密码”这个东西本身可被猜测和复用。而公钥认证使用的是非对称加密私钥只存在你自己的电脑上服务器只保存公钥。攻击者就算拿到公钥文件没有私钥也完全无法登录。先在本地电脑生成密钥对我推荐ed25519算法比RSA更短更快安全性也足够ssh-keygen -t ed25519 -a 100 -f ~/.ssh/id_ed25519 -C your-comment一路回车会在~/.ssh/下生成id_ed25519私钥和id_ed25519.pub公钥。然后我把公钥拷贝到服务器上ssh-copy-id -i ~/.ssh/id_ed25519.pub -p 当前端口 user服务器IP如果没有ssh-copy-id可以手动追加mkdir -p ~/.ssh chmod 700 ~/.ssh echo 你的公钥内容 ~/.ssh/authorized_keys chmod 600 ~/.ssh/authorized_keys注意权限一定不能错家目录是700或755.ssh目录必须700authorized_keys必须600或644。权限太松会直接导致SSH拒绝使用这个文件这是新手最容易踩的坑。3.2 第二层修改默认端口并限制来源IP把SSH从22端口改到高位端口属于“安全混淆”它不能真正挡住有耐心的攻击者但能让全网无差别的端口扫描收敛很多。扫22端口的是几百万台机器组成的僵尸网络扫2222或者62222的就少多了。编辑/etc/ssh/sshd_configPort 2222 PermitRootLogin prohibit-passwordPermitRootLogin prohibit-password的意思是禁止root用密码登录但允许root用密钥登录。阿里云、腾讯云的云服务器默认镜像有时候会有盲区后面我会专门说root登录的取舍。改端口前一定先把防火墙放行别把自己锁在门外。Ubuntu/Debian用ufwufw allow 2222/tcp ufw enable如果条件允许更硬核的做法是在防火墙层面只放行你公司的出口IPufw allow from 你的办公IP to any port 2222 proto tcp这样即使有人知道你的端口也连不上。但要注意如果办公IP不固定这个配置会变成定时炸弹出差换个网络就进不去了。所以我一般建议端口可以改来源IP限制只加在不需要频繁移动的管理机上。3.3 第三层fail2ban自动封禁暴力破解端口改了只是降低暴露度真正需要的是“自动反击”。fail2ban就是干这个的它监控SSH登录日志发现某个IP连续失败多次就自动写入防火墙规则封禁一段时间。安装和配置都非常简单apt install fail2ban编辑/etc/fail2ban/jail.local[sshd] enabled true port 2222 filter sshd logpath /var/log/auth.log maxretry 5 bantime 3600 findtime 600参数含义findtime600表示在600秒内如果同一IP登录失败达到maxretry5次就触发封禁封禁时长bantime3600秒1小时。这套参数对普通误操作也宽容连续输错5次密码不至于把自己封死。启动并检查状态systemctl enable --now fail2ban fail2ban-client status sshdfail2ban最实用的地方是日志可视化。fail2ban-client status sshd会直接列出被封禁的IP清单看到那一排排攻击源你会感觉这工具太值了。它还支持邮件告警、收窄封禁时长进阶玩法可以等稳定后再研究。3.4 第四层sshd_config里的隐蔽开关除了改端口和禁用密码sshd_config里还有几个开关对安全影响巨大我把完整推荐配置贴在下面敏感项逐一说明Port 2222 ListenAddress 0.0.0.0 PermitRootLogin no PubkeyAuthentication yes PasswordAuthentication no PermitEmptyPasswords no ChallengeResponseAuthentication no UsePAM yes X11Forwarding no AllowAgentForwarding no AllowTcpForwarding no MaxAuthTries 3 MaxSessions 10 LoginGraceTime 30 ClientAliveInterval 300 ClientAliveCountMax 2 AllowUsers admin deploy逐条说PermitRootLogin no直接禁止root登录。日常操作全部用普通用户sudo即使普通用户密码泄露攻击者也拿不到root权限多一道门槛就多一份安全。PasswordAuthentication no彻底关闭密码登录只允许密钥。这是整份配置里最关键的一条。MaxAuthTries 3单次SSH连接最多尝试认证3次超出立即断开对爆破是压制性的。LoginGraceTime 3030秒内必须完成登录否则断开连接能挡住大量慢速连接占资源的扫描器。ClientAliveInterval 300和ClientAliveCountMax 2每300秒给客户端发一次保活探测连续2次无响应就断开防止僵尸连接拖着不放。AllowUsers admin deploy只有这两个用户可以SSH登录其他人一律拒绝。改完一定要先检测配置再加载ssh -t systemctl restart sshd这里提醒一句修改sshd_config前先新开一个SSH会话保持登录再在另一个会话里改。如果配置写错导致服务起不来你还有一个窗口可以救回来。这是老运维的基本素养别嫌啰嗦。3.5 在VSCode和日常终端里共用同一套密钥加固完SSH后你肯定会遇到实际使用问题。比如很多开发者用VSCode的Remote-SSH插件连服务器开发如果端口变了、密码认证关了VSCode就会连不上。正确做法是在本地~/.ssh/config里写一段主机配置Host myserver HostName 1.2.3.4 Port 2222 User admin IdentityFile ~/.ssh/id_ed25519写完后VSCode连服务器时直接选myserver这个host它会自动套用端口、用户名和密钥全程不用输密码。命令行也一样ssh myserver这套配置还能帮你批量管理多台服务器每个业务一台机器全都走密钥登录比记忆IP和密码舒服得多。我自己的服务器、朋友的公司服务器现在都是这样一个config文件管所有入口。4. 现场清理与恢复把肉鸡变回正常服务器加固做完相当于门锁换好了但屋里的贼还在该清的东西还得彻底清干净。这个部分我放在加固后面做顺序很重要先封门再抓贼防止贼逃走前顺手破坏。4.1 定位并清除挖矿进程上面第1部分我们已经锁定了可疑进程的PID现在执行清除kill -9 目标PID如果进程有守护进程自动拉起就改为先停掉守护相关的systemd服务或cron任务再杀主进程。杀掉后别急等几分钟再跑一次top确认它没有复活。同时也把/tmp、/var/tmp、/dev/shm这几个临时目录扫一遍ls -la /tmp /var/tmp /dev/shm挖矿程序特别喜欢藏在 /tmp 下因为目录本身可写、权限混乱隐蔽性极强。看到不认识的目录名、文件名先用file命令确认类型有疑点就移到专门的文件隔离目录别随便删。我之前见过一个矿机把挖矿日志伪装成/sys/下的虚拟文件要不是file命令提示“ELF 64-bit executable”差点漏过去。4.2 检查计划任务与开机自启挖矿程序要长期存活最常见的持久化方式就是计划任务。逐项检查crontab -l # 当前用户的crontab ls -la /etc/cron.d /etc/cron.daily /etc/cron.hourly systemctl list-timers --all # systemd定时器 systemctl list-units --typeservice --staterunning朋友的机器上攻击者在/etc/cron.d/里留了个定时任务内容是每隔5分钟去某个URL下载脚本并执行。这个脚本会自动拉起被kill的挖矿进程。所以一定要把所有可疑的cron任务清理干净再断掉下载源否则杀多少次都会复活。检查systemd服务时重点关注描述信息乱七八糟、路径指向/tmp/或/var/tmp/下的unit文件。同样看到可疑服务就执行systemctl disable --now 服务名并删掉对应的unit文件。4.3 检查系统用户与SSH后门攻击者通常会新建一个隐藏用户当后门比如用户名起成sysadmin或者带空格的怪异名字。排查命令awk -F: $30 {print $1} /etc/passwd cat /etc/sudoers | grep -v ^#重点看有没有新增的UID为0的用户这种用户拥有root权限以及sudoers里是否被加入了奇怪成员。发现异常直接删用户userdel -r 可疑用户名SSH后门则是检查所有用户的authorized_keysfind /home /root -name authorized_keys -print 2/dev/null逐个确认每把公钥是否真实。我自己有一个判断标准如果authorized_keys不是你亲手添加过的一律视为可疑。别犹豫直接删。4.4 凭证轮换该换的全都换掉这是很多人最不愿意做但又最必须做的一步。既然攻击者已经拿到过root权限他可能已经把你系统里所有密码、密钥都看到了。所以修改服务器所有用户密码包括root和各应用账号。重新生成SSH密钥对替换服务器上的authorized_keys。数据库密码、API密钥、Token等所有应用级凭证全部重置。如果服务器跑了网站后台、第三方平台绑定记得去对应平台做一次会话失效/密钥轮换。朋友这台机器原先跑着客户的应用里面有支付回调的API密钥我一并帮他换掉了虽然麻烦但心里踏实时比什么都强。宁可多花半小时做全面轮换也不要留一个未知的后门在那里等你后悔。5. 长期运维与安全监控别等下次被入侵才发现救完火我给朋友补了一个长期监控方案。说真的哪怕前面加固做得再完善也不代表一劳永逸。攻击手段在进化你的系统在变化靠人工盯日志太不现实得让监控自动化。5.1 日志与异常负载的自动化报警最简单的监控不是装一堆庞然大物而是利用系统自带能力做一个负载告警脚本。比如下面这个#!/bin/bash load$(uptime | awk -Fload average: {print $2} | cut -d. -f1) if [ $load -gt 4 ]; then echo 服务器负载异常: $(uptime) /var/log/highload.log # 这里可以接邮件、钉钉/企业微信机器人、短信等通知 fi把它放进crontab每5分钟执行一次负载超过阈值就报警。挖矿、加密勒索这类程序都极其消耗CPU负载告警能在第一时间让你感知异常。千万不要等到网站打不开才去查那时候整个系统可能已经被拖垮了。有条件的话可以装一套轻量的开源监控面板比如Netdata或PrometheusGrafana把CPU、内存、网络连接、磁盘I/O都可视化。看着图识别异常比翻日志快太多。重点是这些工具全都开源免费个人服务器部署成本很低。5.2 安全加固习惯最小权限与定期更新长期安全靠的是习惯。我总结了几条纯经验层面的原则尽量用普通用户sudo操作不要整天挂root。真的遇到误操作普通用户最多影响当前目录root可以毁掉整个系统。定期更新系统和软件包。很多入侵利用的是已知漏洞厂商已经发了补丁你长期不更新就等于把门敞着。Ubuntu/Debian执行apt update apt upgradeCentOS执行yum update做完顺手重启一下。最小化开放端口。除了80/443业务端口和修改后的SSH端口其余端口一概不开。在云服务商的安全组里设规则比在服务器内部iptables折腾更直观可控。避免在同一台服务器上复用同一个密码/密钥。密码泄露不一定是服务器被入侵也可能是你在别处用的同密码泄露了。这也是为什么SSH一定要强制密钥登录的根本原因。还有一点容易忽略确保服务器时间和时间同步服务正常。日志分析、fail2ban判断时间窗口都依赖准确时间如果系统时间错乱排查入侵时会白费很多功夫。建议开启系统自带的时间同步服务比如systemd-timesyncd或chrony保持时间准确。5.3 应急演练不用多能跑通一条就行很多运维知道该怎么做但真出事时手忙脚乱。为了避免这个情况我建议每个季度花半小时做一次简易演练假装发现服务器异常按顺序走一遍排查、隔离、加固、恢复流程。把关键命令固化成一个文档或脚本用的时候照着执行就行。我给自己和朋友各准备了一份“服务器应急手册”内容包括异常排查命令序列、SSH加固配置备份、数据备份策略、服务商控制台的操作入口清单。遇到问题直接翻手册不用临时回忆。6. 常见问题与排查技巧实录最后这部分是我实操中遇到最多的坑也是帮朋友救完服务器后他天天追着我问的问题集中整理成速查表。6.1 改完SSH连不上八成是这三个原因现象原因解决办法连接超时防火墙没放行新端口到安全组/ufw放行新端口本地telnet测端口通不通提示拒绝连接sshd没起来或监听在别的地址执行ss -lntp密码被拒PasswordAuthentication no生效了确保私钥路径正确、权限600用ssh -i 私钥 -p 端口 userIP测试如果配置写错导致服务起不来千万别慌还有一招用云服务商的VNC/救援模式登录进去改回旧的配置重启。这也是为什么我强调改配置前一定要保留一个已登录的SSH会话。6.2 fail2ban把自己封了怎么办这问题几乎人人都遇到过。你在一台新机器上反复测试登录结果连续输错几次密码fail2ban把你的IP封了。解封命令fail2ban-client set sshd unbanip 你的IP如果连fail2ban都连不进服务器就用VNC登录后执行上面命令或者临时停一下fail2bansystemctl stop fail2ban。为了避免这类误伤我自己会在jail.local里加一段白名单把自己的IP加进去[DEFAULT] ignoreip 127.0.0.1/8 你的办公IP但也别把整个公司出口IP段都加进去万一公司有人中招变成攻击源白名单反而成了保护伞。6.3 密钥认证明明开了还是提示输密码这个问题最常见的原因是权限。authorized_keys文件权限太宽SSH会直接拒绝加载。检查三处chmod 700 ~/.ssh chmod 600 ~/.ssh/authorized_keys chmod 700 ~还有一个隐蔽坑如果你用的普通用户的家目录权限不是700而是777SSH同样会拒绝使用家目录下的密钥文件。另外用了SELinux的CentOS系统需要确认SELinux上下文没被改坏一般使用restorecon -Rv ~/.ssh恢复。6.4 加固后网站还能不能正常跑能完全可以。SSH加固只影响22/2222端口的登录服务不会动到80/443的Web流量。朋友最担心的就是“会不会越改越坏”我给他的保证是只要业务本身是正常的SSH配置改变不影响Nginx、MySQL、应用进程。唯一要注意的是如果应用里有通过SSH拉取代码或部署的流程端口改了以后这些脚本的连接参数也要同步更新。救援完朋友的服务器我自己最大的体会是安全这东西平时多花半小时预防好过事发后熬一整夜救火。SSH是公网服务器最重要的入口守住SSH就等于守住了服务器第一道门。建议你今天就检查三件事服务器上有没有password登录root能不能直接登录SSH日志里有没有大量失败记录如果有不用等出事照着这篇文章先加固一遍。