云服务器安全防护实操：从入侵检测到防御加固

1. 先搞清楚：你的云服务器每天都在被谁扫描

1.1 为什么刚买的服务器就被攻击

很多新手第一次买云服务器，配置好环境，睡一觉起来发现CPU爆满、SSH登录慢得离谱，登录上去一看，跑了一个挖矿进程。这不是运气差，这是云服务器的新手村必修课。

我从2016年开始接触云服务器，前后管理过上百台不同配置的实例。一个残酷的事实是：公网IP只要暴露在互联网上，扫描和攻击几乎是持续不断的。你买下服务器的那一刻，IP就被各路扫描器盯上了。有的扫描器在全网扫段，有的是针对云厂商的IP段批量探测，有的干脆就是僵尸网络在随机扫。这不是危言耸听，你去翻一下服务器的认证日志，大概率能看到来自世界各地IP的SSH爆破尝试，很多甚至是刚开通几小时内就出现的。

为什么攻击者这么执着？因为云服务器价值密度很高。一台机器被攻破后，能干的事情太多了：拿去挖矿、发垃圾邮件、做跳板继续攻击内网、勒索、盗取数据。而且很多服务器管理员安全意识薄弱，弱口令、默认配置、不更新补丁，这些在攻击者眼里就是敞开的门。

搞清楚这个背景，你才能理解接下来的每一条防御措施都是有实战意义的，不是为了走形式。

1.2 常见攻击手段全景图

先给一张全景图，让我们对云服务器面临的威胁有个整体认知。根据我这些年处理过的攻击事件和看过的各类报告，常见的攻击手段基本可以分为这么几大类：

这不是孤立的，很多时候攻击是组合拳。比如先扫到你的Nginx版本有漏洞，利用漏洞拿下一个webshell，然后提权，最后装挖矿木马。或者先对一个开放了3389端口的Windows服务器做RDP爆破，成功后再手动投递勒索软件。

咱们这篇文章重点聊的是基础设施层面的攻击与防御，也就是服务器操作系统、网络、常用服务这三个层面。这部分做好了，能挡住80%以上的自动化攻击。

2. 攻击手段逐个拆解：它们到底是怎么得手的

2.1 SSH暴力破解：最常见的敲门声

如果你用的是Linux服务器，默认都会开SSH。SSH暴力破解是云服务器上最常见、最频繁的攻击行为，没有之一。

它的原理其实很简单：攻击者用字典或者撞库得到的用户名密码组合，不停地尝试登录。很多人的服务器密码是admin123、password、123456这种级别，或者干脆密码和用户名一样，那基本就是一撞一个准。

我见过最夸张的一次，一台裸奔状态的CentOS服务器（当时只是临时测试用），开放了22端口且用的是弱密码，结果第二天一看日志，/var/log/secure文件里刷了上万条Failed password记录，而且服务器上已经被种了一个挖矿木马。

除了纯密码爆破，现在还有一种更隐蔽的方式叫密码喷洒。传统爆破是拿一个用户名的字典去试密码，喷洒是只试几个最常见的密码（比如Welcome123、P@ssw0rd），但用大量不同的用户名去试。这种方式可以绕过一些"连续失败N次就锁定账号"的策略，因为每个账号只试了一两次，不够触发锁定阈值。

2.2 DDoS攻击：把你的带宽和资源打满

DDoS（分布式拒绝服务）攻击是云服务器面临的最"暴力"的威胁之一。它的思路是：我不需要攻破你的系统，我只需要让你的服务变得不可用就行。

具体手法有很多种，常见的有这么几类：

• 流量型攻击：用大量僵尸主机向你的IP发送海量数据包，把你的带宽打满。比如UDP Flood、ICMP Flood。这种攻击的量级可以轻松到几百Gbps，可以把大多数服务商的基础防护直接打穿。
• 连接型攻击：建立大量半连接或者全连接，耗尽服务器的连接表。最典型的是SYN Flood。服务器收到SYN请求后，需要分配内存记录这个半连接状态，如果短时间内涌入百万级别的SYN包，内存和处理能力都会被耗尽。
• 应用层攻击：针对具体应用发起看似正常的请求，比如HTTP Flood（也叫CC攻击）。攻击者模拟真实用户，频繁请求你的页面接口，把应用的计算资源和数据库连接池打满。这种攻击最可怕，因为流量特征和正常用户请求高度相似，很难用简单的限速规则来区分。

这里要特别提一句，很多入门玩家会忽略DDoS，觉得"我又没得罪人，谁会打我"。但现实中，DDoS不止是寻仇。有的纯粹是测试自己工具的新手，有的是同行恶意竞争，有的则是勒索团伙先打你一下，然后来谈"保护费"。所以即便你是个小站点，也最好有基本的防护预案。

2.3 Web漏洞利用：从删库到跑路

如果你的服务器上跑了Web服务，那攻击面就更大了。Web漏洞利用是攻击者拿到服务器权限最常用的路径，没有之一。

常见的Web漏洞有：

• SQL注入：把恶意的SQL代码拼接到参数里传给后端数据库执行。历史上有太多因为一个参数没做转义，整库被拖走或者被删库的案例。
• 文件上传漏洞：有些站点允许用户上传文件，但如果没做类型校验，攻击者可以传一个PHP或JSP webshell上去，然后直接通过这个webshell执行系统命令。
• 反序列化漏洞：Java和PHP应用里比较常见。攻击者构造恶意序列化数据，触发代码执行。这类漏洞危害极大，比如之前的WebLogic反序列化漏洞，一批一批的服务器被打穿。
• 命令注入：在调用系统命令的地方注入攻击者想要执行的命令。比如某些站点提供的Ping功能，如果直接拼字符串到Shell命令里，就能被插入; rm -rf /之类的命令。

Web漏洞利用得手后，攻击者通常有两条路：一是弹一个webshell做持久化后门，二是立刻提权然后装挖矿木马。反正最后你的服务器都会变成他的肉鸡。

2.4 恶意软件与挖矿木马：被薅羊毛的重灾区

从我的经验看，2020年之后，云服务器被植入恶意软件中，挖矿木马占了绝对大头。原因很简单，加密货币的匿名性和变现便利性，让挖矿成了网络犯罪最稳妥的变现渠道之一。

挖矿木马的入侵路径通常是：

1. 利用一个未修复的漏洞打进服务器（比如Redis未授权访问、Log4j RCE）
2. 下载一个恶意脚本执行
3. 脚本会检查系统架构，下载对应的挖矿二进制并启动
4. 创建定时任务或者systemd服务，实现持久化
5. 清理日志，规避检测

这里有个很搞笑的细节：很多挖矿木马会自带"防御功能"，它检查到其他挖矿木马占用了CPU资源，会直接kill掉对方的进程。所以有时候你发现CPU占用异常，登录进去却只看到一堆奇怪的进程名，那些可能已经是"幸存下来的赢家"了。

除了挖矿木马，还有一类比较讨厌的是Rootkit。它通过内核模块或者LD_PRELOAD劫持系统调用链，让你看不到它的进程和文件。遇到这种，排查起来非常痛苦，因为top、ps、ls这些都是不可信的。后面我会详细讲排查思路。

2.5 端口扫描与服务漏洞：被忽略的入口

最后聊一下端口扫描。攻击者会先对你的IP做全端口扫描，识别出你到底开了哪些服务。然后用对应的漏洞利用工具去测试每个服务的版本是否有已知漏洞。

举个例子，nmap -sV -p- 1.2.3.4，这行命令就能扫出你服务器上所有开放的端口，以及每个端口上跑的软件和版本号。扫完之后用searchsploit或者metasploit的模块去匹配漏洞，一条完整的攻击链就出来了。

很多管理员只关心Web服务，却忽略了数据库和中间件。比如：

• 3306端口开放给了公网，并且MySQL是弱密码
• 6379端口开放着，Redis没有设密码，攻击者可以直接写SSH公钥或者crontab
• 8080端口跑着老版本的Tomcat，存在已知的RCE漏洞
• 9200端口暴露了Elasticsearch，可以被任意删除索引

这些都是典型的"送分题"。

我之前接手过一个客户的服务器，他就只在安全组里开了22、80、443，但是因为用了Docker，启动容器的时候用了-p 3306:3306，结果Docker自动在iptables里开了端口，绕过了安全组的限制，MySQL直接暴露到了公网，密码还是root/123456。这种情况并不少见，因为很多人不清楚Docker和iptables的交互逻辑。

3. 基础防御：把服务器的"门窗"先关好

3.1 安全组配置：云上的第一道防火墙

云服务器的第一道防线，不是服务器内部的iptables，而是云厂商的安全组。安全组是虚拟防火墙，在流量进入实例之前就做过滤，它有两个很大的优势：一是性能损耗几乎为零，因为流量根本不会到你的操作系统；二是即使服务器本身被攻破，你也不至于把内部管理端口暴露给整个互联网。

安全组配置的核心原则是最小化暴露，也就是只开放业务必需的端口。

我的默认策略是这样的：

• 22端口：只允许你自己的IP段访问，或者通过堡垒机访问
• 80/443端口：对所有来源开放（这是网站服务必需的）
• 其他端口：默认不开放，需要的时候再加
• 数据库端口（3306/5432/6379等）：绝对不对公网开放，只用内网访问
• 远程桌面3389：如果非要开，只允许指定IP，并配合强密码

这里有个容易被忽视的细节：安全组是白名单机制，默认全拒绝。有些云厂商的安全组默认是允许所有的，你需要自己动手把规则改成白名单模式。

另外要注意，安全组只对入站流量过滤，出站流量默认是放行的。这就意味着，如果服务器被攻破，攻击者可以自由地向外发起连接（下载恶意软件、回传数据等）。所以，出站方向的安全组规则也值得配置，至少可以限制对高危险目标地址的访问。虽然配置出站规则比较麻烦，因为要放行DNS、HTTPS、软件源等，但这是纵深防御里很有价值的一环。

3.2 SSH安全加固：把暴力破解挡在门外

SSH是Linux服务器的生命线，也是攻击者的重点突破口。加固SSH能做到的事情很多，我按优先级列一下。

第一优先级：改用密钥登录，关闭密码登录

这是所有SSH加固里最有效的一条。生成一对密钥，把公钥放到服务器的~/.ssh/authorized_keys里，然后修改配置文件：

bash复制# /etc/ssh/sshd_config
PasswordAuthentication no
PubkeyAuthentication yes

改完重启sshd服务（systemctl restart sshd），从此以后，暴力破解就彻底失效了。因为攻击者没有你的私钥，再怎么猜密码也没有用。

第二优先级：修改SSH端口

把默认的22端口改成别的，比如22022或者一个不常用的高位端口。这虽然不能算严格的安全措施，毕竟扫描器可以扫全部端口，但实测下来，改完端口后，/var/log/secure里的暴力破解日志量能下降90%以上，因为绝大多数自动化攻击脚本都是针对默认端口的。

注意，改SSH端口之前，一定要先确认你用的云厂商安全组也放行了新端口，然后再改sshd_config，否则你可能会把自己锁在门外。

第三优先级：安装Fail2ban

Fail2ban是一个用Python写的入侵防御工具，它动态地监控日志文件，检测到多次失败的认证尝试后，会自动在iptables或firewalld里封禁对方的IP一段时间。

配置起来也很简单：

bash复制apt install fail2ban

它的核心配置在/etc/fail2ban/jail.local里，这是我常用的配置：

ini复制[DEFAULT]
bantime = 1h
findtime = 10m
maxretry = 3

[sshd]
enabled = true

这个配置的意思是：在10分钟内如果有3次失败的SSH尝试，就把这个IP封禁1小时。实测效果很好，暴力破解的日志量会呈断崖式下降。

第四优先级：禁用root直接登录

root是系统最高权限账号，攻击者拿到了root就等于掌控了整台机器。所以建议禁止root直接SSH登录，日常使用一个普通用户，需要提权的时候用sudo。

bash复制# /etc/ssh/sshd_config
PermitRootLogin no

3.3 系统更新与补丁管理：最无聊但最有效

讲真的，有太多安全事件的根本原因就一句话：没打补丁。

2021年底那个Log4j漏洞（Log4Shell），影响面极其夸张，很多服务器被挖矿木马入侵，都是因为公网服务用了带漏洞的Log4j版本。当时打补丁快的团队基本没事，没打的基本都中招了。

在云服务器上，系统更新这块建议不要偷懒：

• 操作系统层面：Ubuntu/Debian用apt update && apt upgrade，CentOS/RHEL用yum update，或者直接用unattended-upgrades做自动安全更新。
• Web服务与中间件：Nginx、Apache、Tomcat、Java、Node.js这些，要养成定期关注安全公告的习惯。
• Docker镜像：镜像里的依赖也要定期rebuild，很多人只更新宿主机，却忘了容器里的东西早就旧掉了。

我个人的经验是每周做一次系统更新，不需要太频繁，因为生产环境太频繁升级可能引入不兼容的问题。但安全更新例外，高危漏洞出来后12小时内就要评估并安排升级。

4. 进阶防御：入侵检测与主动防护

4.1 主机入侵检测：给你的服务器装个"哨兵"

防火墙和安全组做的是"防患于未然"，但总有漏网之鱼。所以我们需要主机层面的入侵检测系统（HIDS）来兜底。

HIDS能做的事情包括：监控文件完整性、检测异常进程、监控系统日志、识别可疑网络连接。比较常见的开源方案有：

• Osquery：Facebook开源的，可以用SQL语句查询系统的进程、网络连接、文件等，非常灵活。配合定时任务或者调度器，可以实现类似"Sysmon for Linux"的效果。
• Wazuh：功能更全面的开源HIDS平台，基于Osquery，加上了文件完整性监控（FIM）、日志分析、主动响应等能力。部署稍重，但功能也更强。
• AIDE：轻量级的文件完整性检查工具。它会给关键文件（比如/etc/passwd、/usr/bin/下的二进制）建立数据库，定期比对，发现文件被改动就会告警。

我最早用AIDE，后来发现那种"事后比对"的模式对于真实攻击场景来说太慢了，因为攻击者可能改完文件后第二天就删除了痕迹。后来改用了Osquery做实时查询，配合告警规则，能及时发现异常。

一个比较实用的Osquery查询例子——找出所有正在监听的端口和对应的进程：

sql复制SELECT p.name, p.pid, l.port, l.address
FROM process_open_ports l
JOIN processes p ON l.pid = p.pid
WHERE l.port > 0 AND l.address NOT IN ('127.0.0.1', '::1')
ORDER BY l.port;

这个查询能快速发现所有暴露到公网的端口，以及是谁在监听，对于排查可疑后门非常有用。

4.2 Web应用防火墙：别让你的业务成为突破口

如果有对外提供Web服务，在Nginx前面加一层Web应用防火墙（WAF）是个很强的防护手段。WAF的核心能力是检测和拦截常见的Web攻击流量，比如SQL注入、XSS、文件上传等。

云厂商基本都提供商业WAF服务，但价格不便宜。对于很多个人和小团队来说，用开源方案更实际：

• ModSecurity：老牌开源WAF，配合Nginx或Apache使用。核心是它的规则集（OWASP CRS），能拦截大多数已知的Web攻击。默认规则确实会有误报，需要根据业务调整。
• 宝塔面板/Nginx防火墙：很多国内用户在用，配置简单，拦截效果也不错。虽然没有ModSecurity那么强大，但对于常见攻击已经足够了。

另外，如果你用CDN（比如Cloudflare），它的CDN本身也自带WAF功能，相当于多了一层免费或者低成本的防护。把源站IP藏到CDN后面，还有一个额外的好处：攻击者直接扫你的源站IP扫不到太多东西，Web攻击会被CDN过滤一层。

这里插一句，永远不要让源站IP暴露。有些人虽然挂了CDN，但解析记录里还有一条A记录直接指向源站IP，这就等于把自己脱光给别人看。排查方法很简单，用nslookup或dig看看子域名解析到的IP是不是CDN的IP。

4.3 日志审计与监控：攻击发生后能不能快速发现

很多人直到服务器卡死了才发现被入侵，就是因为根本没有监控。日志和监控是我们复盘、溯源、止损的依据。

Linux服务器上最核心的日志有这些：

• /var/log/secure 或 /var/log/auth.log：认证日志，SSH登录、sudo操作都在这里
• /var/log/messages 或 /var/log/syslog：系统运行日志
• /var/log/nginx/access.log：Web访问日志（如果是Nginx的话）

对于个人服务器，至少要养成一个习惯：每周看一眼认证日志，看有没有异常登录。

bash复制# 查看最近的认证失败记录
grep "Failed password" /var/log/secure | tail -20

# 查看最近的登录成功记录
grep "Accepted password" /var/log/secure | tail -20

单机看日志比较痛苦，有条件的话可以上一套集中式日志系统，比如ELK（Elasticsearch + Logstash + Kibana）或者Loki + Grafana。但这套方案对个人玩家来说有点重，可以先从监控告警做起。

云厂商的监控服务（比如阿里云的云监控、腾讯云的云监控）可以设置CPU使用率、内存使用率的告警阈值。比如CPU使用率持续5分钟超过90%，就发短信提醒。这个告警在挖矿攻击场景下是很有用的，因为挖矿会瞬间拉高CPU。

我自己的经验是设置了两层告警：

• 紧急告警：CPU使用率 > 95%，持续5分钟。一般是挖矿或者配置出错。
• 一般告警：出网带宽 > 100Mbps，持续10分钟。可能是被DDoS流量攻击，也可能是数据被窃取外传。

5. 实战复盘：一次真实的入侵排查过程

5.1 事件发现

说一个真实的案例，是我曾帮一个朋友排查的。他的云服务器跑着一个PHP博客，某天发现网站打开特别慢，后台登录也进不去了。登录服务器一看，CPU使用率100%，top命令里有一个叫kdevtmpfsi的进程占了300%多的CPU。这个名字看着像系统内核相关的东西，但其实是个非常经典的挖矿木马，相信熟悉安全的朋友一眼就知道。

一开始朋友慌了，问我要不要重置系统。我告诉他先别急，用这个案例当课本，好好排查一遍。

5.2 排查思路与操作步骤

第一步：查看进程和网络连接

首先确认可疑进程，然后再看这个进程有没有连接外部的矿池地址。

bash复制ps aux | grep kdevtmpfsi
# 或
pidstat -p $(pgrep kdevtmpfsi) 2

ss -tnp | grep $(pgrep kdevtmpfsi)

ss命令能看到这个进程建立的外部连接，矿池地址一般在境外（比如某个欧洲IP）。拿到对方的IP和端口后，可以先在云厂商的安全组里把这个IP封掉，断掉挖矿的数据通道。

第二步：查找持久化方式

挖矿木马为了保证重启后还能运行，一般都会写定时任务或者systemd服务。检查这两处：

bash复制# 检查当前用户的crontab
crontab -l

# 检查系统的定时任务
cat /etc/crontab
ls /etc/cron.*
ls /var/spool/cron/

# 检查systemd服务
systemctl list-units --type=service --state=running | grep -v systemd
ls -la /etc/systemd/system/ | grep -v 'unit'

朋友这台机器上，果真在/etc/cron.d/里发现了一个名为update的文件，内容就是一段脚本，从某个恶意域名下载挖矿程序并执行。

第三步：查找攻击入口

这是最重要的一步。挖矿木马不会凭空出现，一定是从某个入口进来的。查看认证日志：

bash复制grep "Accepted password" /var/log/secure

结果发现有一个来自国外IP的SSH登录记录，时间戳正好在挖矿木马出现之前。进一步验证之后确认，那个IP就是用弱密码爆破进来的。朋友这台服务器的root密码是123456，直接被扫到并且登录成功了。

如果SSH日志干净，那就要检查Web日志，看看有没有异常的上传请求、命令注入的痕迹。再检查一下MySQL慢查询日志和错误日志。

5.3 加固方案

排查完，我给出的加固方案是这样的：

1. 立刻封堵入口：关闭密码登录，改用密钥登录；修改SSH端口；在安全组里封掉矿池IP段。
2. 清理挖矿木马：杀掉进程、删除定时任务、删除恶意脚本和二进制文件、删除恶意SSH公钥（注意检查~/.ssh/authorized_keys里有没有被写入陌生公钥）。
3. 修补漏洞：如果是Web漏洞进来的，修复对应代码；如果是弱口令，改强密码（虽然已经改用密钥了）。
4. 全面更新：把系统和中件软的补丁都打上。
5. 事后监控：安装Fail2ban，配置好监控告警，确保下次能在几分钟内发现异常。

最麻烦的一点是，如果已经被人拿过root权限，你无法保证系统里没有留其他后门（比如替换了系统二进制、加载了恶意内核模块）。所以我个人的建议是：如果是生产环境且数据不重要，直接重置系统最稳妥。但如果是想学习排查过程，或者数据无法重建，那就按上面的步骤做深入排查。

6. 常见问题速查表与避坑经验

6.1 常见问题速查表

6.2 踩过几次坑之后，我的心得体会

最后分享几个实操经验，这些是文档里一般不写但很重要的细节。

第一，改SSH端口前先开防火墙端口。 我自己就干过这事儿：改了sshd_config里的端口，重启服务，然后发现自己被锁在门外了，因为安全组里忘了放行新端口。如果你用的是云厂商的弹性IP管理，还能用网页版的VNC登录救回来，但如果连这个都不支持，就只能开机重置密码再进去了。后来我的习惯是：先改安全组放行新端口，再改sshd_config，测试能连上之后再在防火墙里关掉旧端口。

第二，尽量不要用root直接跑业务。 很多一键安装脚本喜欢让你用root执行，方便是方便，但养成坏习惯。一旦你的Web应用有漏洞，攻击者拿到的是PHP进程的权限，如果PHP-FPM是root跑的，那他就直接拿到root了。正确做法是让Nginx/PHP-FPM用www-data这样的普通用户跑，即使被利用，权限也是很有限的。

第三，Docker的端口映射会绕过安全组限制。 这是让我印象最深刻的坑。安全组是在宿主机的虚拟网络层做过滤的，但Docker容器通过iptables的DNAT规则把端口映射出来之后，有些安全组规则拦不住。也就是说，你明明在安全组里没放行3306，但如果Docker用了-p 3306:3306，MySQL还是可能暴露到公网。所以用Docker部署的时候，一定要确认容器端口真的没暴露出去。可以用云厂商的端口扫描工具或者在线端口扫描网站检查一下自己的公网IP开放的端口。

第四，日志文件也要看。 很多人配了logrotate让日志自动切割，但从不打开看。安全事件的迹象往往就藏在这些日志里。我建议每个月的某一天，花10分钟看一下认证日志和Web访问日志，比事后排查要省心得多。

第五，安全组规则要定期清理。 有时候临时调试会在安全组里开一个端口，调试完了就忘了关。这个端口就像一扇没锁的窗户，随时可能被人推开。我一般每季度做一次安全组规则审计，看看有没有不符合"最小化暴露"原则的规则，看到就删。

再补充一个非常实用的小技巧：用last -f /var/log/wtmp查看最近所有登录记录，包括IP、时间、来源。如果你发现某个陌生IP登录了你的服务器，那基本可以断定已经被入侵了，立刻按"断网->保护现场->排查"的流程处理。

云服务器安全防护这件事，没有一劳永逸的银弹，它更像是一个不断迭代的过程。先把基础防御做好，再逐步叠加检测和响应能力，最后形成自己的安全习惯。从我的经验来看，80%以上的攻击都可以通过"密钥登录+安全组最小化+及时更新补丁+日志监控"这四个基础动作挡住。剩下那20%，考验的是你发现异常和快速响应的能力。希望这篇文章里的思路和实操能帮你在云服务器安全这条路上少踩几个坑。