服务器不会直接告诉你“我被攻击了”，但系统日志、流量曲线和CPU利用率会判断服务器是否遭受攻击，核心看四个层面：资源耗尽、登录异常、网络连接异常、文件系统异常。
行业共识认为,攻击者的下手目标里，配置不当的云主机比高防服务器更容易得手，不是因为技术多高明，而是因为不少站长根本没留意过自己的登录日志和进程列表，服务器被攻击通常不是一瞬间的事，多数情况下有一个过程从扫描、爆破到植入后门，这个过程中留下的痕迹，就是可以判断的依据。
服务器被攻击了怎么查：五个必须盯住的异常信号
担心服务器被攻击了怎么查,别急着翻安全报告，先从自己机器上找证据。
CPU和内存无故打满，但找不到高消耗进程
打开top命令,发现CPU跑到90%以上，但排在第一的进程只占20%，剩余消耗对不上账，大概率是隐藏进程或内核模块在做手脚。
实操：按top里的H键查看线程，再对照ps -aux看进程数是否一致，两边对不上，基本可以断定有东西藏起来了。
登录记录里出现陌生IP和异常时间段
你一个月都没登过服务器,但last输出里有一堆凌晨三点的root登录记录，这几乎可以直接宣告服务器被拿下了。
实操：执行last -f /var/log/wtmp查看完整历史，重点关注三类内容：不是你的常用IP段、连续失败登录后的成功记录、比你更频繁的登录频率。
对外连接数暴增，出现大量异常TCP连接
正常业务服务器的TCP连接数是平稳的,如果你用ss -antp看到同一时刻上千个外部IP连到你的80端口或443端口，且来源地域分散，这通常是流量攻击的预兆，而如果你的服务器主动向陌生IP发起大量外连，则是木马外联的特征。
网站文件被批量篡改，安装包被替换
页面里被塞入一段不相干的外链代码,这不是程序出bug，是被注入了，更隐蔽的是下载链接里的安装包被替换成带后门的版本，在开源软件镜像被污染时常见这种情况。
实操：用find /var/www/html -name ".php" -mtime -3查最近三天修改过的文件，凡是你没改过的，逐一打开看内容。
系统服务里多出不认识的驻留进程
systemctl list-units --type=service列出一个你没安装过的UUID名称的守护进程，这是典型的持久化后门特征，攻击者会注册一个随机名服务，设置开机自启，确保重启后依然存活。
服务器被攻击如何排查：一份可直接执行的命令清单
确认了异常信号之后,服务器被攻击如何排查就变成一个顺序问题，按四层来，每一层都有明确目的。
第一层：看资源占用，锁定吃CPU的进程
# 动态查看，2秒刷新一次，按P按CPU排序，按M按内存排序 top -c # 查看多核CPU各核心使用情况 mpstat -P ALL 2 # 追踪特定进程的CPU历史 pidstat -p PID 1
核心思路：把占用最高的进程名记下来，直接去搜索引擎搜这个名字，如果搜出来全是“挖矿程序”“恶意进程”一类结果，那就是它。
第二层：看网络连接，找出异常连接方向
判断服务器是否遭受攻击,网络层证据往往比日志更硬。
# 列出所有TCP连接，看外部地址和端口
ss -antp
# 统计每个IP连到你服务器的连接数
ss -antp | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -rn | head -20
依次检查：TCP 80端口有大量来自同一IP段的连接，可能是CC攻击；系统有主动连向陌生中继IP的加密连接，可能是外联木马；UDP 53端口频繁闪烁，考虑是否存在DNS隧道。
第三层：看认证日志，还原入侵路径
Debian/Ubuntu看/var/log/auth.log，CentOS/RHEL看/var/log/secure。
# 统计认证失败次数
grep "Failed password" /var/log/auth.log | wc -l
# 看哪些IP在暴力破解
grep "Failed password" /var/log/auth.log | awk '{print $11}' | sort | uniq -c | sort -rn
# 查看所有成功登录记录
grep "Accepted password" /var/log/auth.log
如果失败次数达到数百甚至上千次,说明服务器正在被爆破，过程中极有可能已出现一次成功登录，那就是攻破开始的节点。
第四层：看文件变化，确认后门位置
# 24小时内改动的可执行文件 find /usr/bin /usr/sbin /bin -newermt "24 hours ago" -type f -executable # 最近7天内改动的动态链接库 find / -name ".so" -newermt "7 days ago" -size +10M
网站服务器被攻击症状：三种典型攻击场景的区别
HTTP/CC应用层攻击
这类攻击主要消耗应用资源,典型症状：网站能打开但极慢，数据库连接数打满，nginx或Apache访问日志里出现对同一个URL的高频请求，且User-Agent和Referer高度一致。
攻击特点是QPS异常升高,如果正常站点日均请求量在几万级别，突然出现几十万甚至上百万的峰值，基本可以判定为CC攻击。
SYN Flood / 流量型DDoS
这类攻击直接消耗带宽和连接表资源,典型症状：服务器即使配置再高也失联，安全组和防火墙没有改动但ping和SSH全部超时，云厂商控制台的流量监控显示带宽被打满到上限。
与CC攻击的区别：这类攻击不只是慢，而是完全不响应，带宽曲线呈现“脉冲式顶格”状态，持续几十分钟到几小时。
入侵提权 / 木马留存
这类是真正的“被攻破”而非“被攻击”，攻击者获得普通用户权限后，通过内核漏洞提权到root，然后创建计划任务、植入后门、替换系统命令，典型症状与前面说的信号重叠：进程列表不可信、登录历史出现陌生IP、/etc/crontab多了不明任务。
| 症状维度 | CC攻击 | 流量型DDoS | 入侵后门 |
|---|---|---|---|
| 网站响应 | 极慢但间歇可达 | 完全无法访问 | 正常但偶发卡顿 |
| 服务器资源 | CPU/内存高 | 带宽/连接数满 | 无明显特征 |
| 系统登录 | 正常 | 正常 | 陌生IP出现过 |
| 进程/文件 | 无明显变化 | 无明显变化 | 有新增可疑文件 |
| 持续时长 | 数小时到数天 | 几十分钟到几小时 | 持续存在直到被查 |
服务器被攻击怎么办：应急处理的先后顺序
判断服务器是否遭受攻击的最终目的,是决定服务器被攻击怎么办，应急响应的顺序不能乱。
第一步：立刻隔离，而不是立刻修
确认被攻击后,第一时间断开与内网其他机器的连接，如果这台服务器上有其他业务依赖，在云控制台修改安全组规则，只保留必要业务端口对外，SSH端口临时限定一个IP才能连入。
第二步：保留证据，拷贝日志到本地
把/var/log、当前进程列表快照、/etc/passwd、/etc/cron打包存档，这一步容易被忽略，但后续要追溯攻击源头或向云厂商反馈，证据就是底牌。
第三步：批量改密，关掉不用的入口
涉及管理员账号、数据库账号、SSH Key、FTP账号，全部重新生成，同时关闭不必要的对外服务端口，特别是Redis、MongoDB、Memcached这类默认无认证的中间件，如果之前绑定在0.0.0.0上，立刻改绑内网。
第四步：明确DDoS的缓解方案
确认是流量型DDoS后,云服务器被攻击费用和处理方案的走向直接相关，高防套餐的价格从几十块到数千块不等，按天计费的防护流量包适合短期应急，长期业务建议接入高防机房或云DDoS防护产品。
第五步：全盘查杀后，加固重来
杀完进程只是清理了现象,后门的根源不在进程，而在创建后门所用的漏洞上，升级内核到新版本，修复中间件已知漏洞，修改NoSQL服务的端口绑定，尽量当天完成，核心原则：宁可重装系统，也不要只杀进程，重装后先打补丁，再恢复数据。
Q&A：服务器被攻击判断的常见疑问
问题1：网站服务器被攻击症状有哪些容易被当成普通故障？
最常见的误判是把内存打满导致的OOM重启当成单纯代码问题,区分方法：同一段代码以前跑得好好的，最近突然频繁OOM，而且free -m里缓存占比异常低、被kill掉的进程名陌生，就要怀疑是否被植入了挖矿程序，网站变慢可能被误判成带宽不够，但在没有增加图片或视频资源的情况下带宽频繁打满，更可能是攻击流量。
问题2：云服务器被攻击费用会体现在哪里，有没有办法降低损失？
费用主要出现在三处：流量带宽超额费用、高防IP购买费用、以及被入侵后的数据恢复与人工运维时费，据云厂商公开计费规则，按量付费的带宽被DDoS打满后，产生的流量费用在正常运营状态下无法预期，降低损失的办法只有一个前置手段：提前购买保底防护套餐，或至少设置安全组只放行必要端口，不要裸奔上线。
问题3：服务器被攻击后必须重装系统吗？
分情况,纯流量型的DDoS，攻击结束后系统本身没被动过，不需要重装，但如果出现文件篡改、陌生登录、进程注入三项中的任一项，建议重装，业内专家指出，在后门植入场景中，清理不彻底的概率远高于一次重装，而被替换的系统命令（如ls、ps、netstat）仅靠肉眼根本分辨不出来，重装之前先脱机备份业务数据，再用官方镜像重装系统，不要在旧环境的残留上叠加修复。
判断服务器是否遭受攻击,不需要你是安全专家，只需要你在异常发生前掌握常态数据平时的CPU占用、带宽峰值量级、常用登录IP，没有基线，就没有判断依据，养成随手查看日志的习惯，比装任何安全软件都管用。