服务器被攻击后的正确顺序是先隔离止损、保留证据，再按“账号进程网络Web计划任务文件日志配置补丁”逐层排查，最后修复漏洞并做加固复盘。很多事故不是攻击多高明，而是入口没堵住、日志没留全、修复只做一半。
先止损再取证：服务器被攻击后的第一小时做什么
隔离、快照与证据保留
先别急着重启或重装，重启会丢内存现场，重装会丢日志和样本,更稳妥的动作是：
- 把机器从负载均衡或安全组里摘除，限制公网访问,只留运维入口。
- 对云服务器做快照,对本地机器做磁盘镜像或关键目录打包。
- 备份
/var/log、Web 访问日志、登录日志、进程列表、网络连接、计划任务。 - 记录时间线：发现时间、异常现象、处置动作、联系人。
常用命令不复杂：
ss -antp看监听端口和已建立连接。ps auxf看进程树，重点留意陌生路径、随机文件名、高 CPU 进程。lsof -i -P -n看哪个进程占了端口。last -a和lastb看成功登录与失败登录。journalctl -u sshd --since today看 SSH 日志；传统系统可查/var/log/auth.log或/var/log/secure。
先判断是流量型还是入侵型
流量型攻击表现为带宽打满、连接数暴涨、业务整体不可用，入侵型攻击更像“机器还在跑，但里面多了东西”：陌生账号、异常外连、Web 目录新增文件、计划任务被改，两类问题的处置顺序不同,混在一起容易越救越乱。
别把重启和重装当修复
重启只能让服务暂时恢复，入口没找到，密钥没换，旧组件没升级，攻击者还能回来，重装前至少确认：入口是弱口令、Web 漏洞、组件漏洞、配置暴露，还是供应链或运维终端被控，没有这个判断,重装只是把问题推迟。
服务器被攻击后如何排查漏洞？从入口到权限的六层检查
账号与登录层
先查有没有“多出来的人”，检查 /etc/passwd 中 UID 为 0 的账号：
awk -F: '($3==0){print}' /etc/passwd- 查看
/etc/shadow中是否有空密码或异常账号。 - 检查
/root/.ssh/authorized_keys和普通用户家目录下的authorized_keys。 - 检查
sshd_config是否开启了密码登录、是否允许 root 直连。
业内专家指出，很多入侵并非从高深漏洞开始，而是从弱口令、旧组件和错误权限开始。
进程、端口与外连层
看进程不能只看名字,要看路径和父进程：
ps auxf找异常路径，如/tmp、/dev/shm下的可执行文件。ss -antp找陌生监听端口。lsof -i -P -n关联进程和连接。- 必要时用
tcpdump -i any -nn port 53观察异常 DNS 外连,执行前确认权限和影响。
发现陌生外连先记录目标 IP、端口、进程 PID 和启动时间,不要急着删文件。
Web与中间件层
Web 入口是重灾区，检查 Nginx、Apache、Tomcat 的访问日志和错误日志：
/var/log/nginx/access.log/var/log/apache2/access.log- Tomcat 的
logs/catalina.out
重点看上传目录、后台路径、异常 POST、奇怪 User-Agent、同一 IP 高频请求，再查 Web 根目录近期改动：
find /var/www -type f -mtime -7 -name ".php"- 对比备份或版本库，确认是否多出 Webshell。
中间件也要看：Redis 是否绑公网、是否设密码；MySQL 是否只监听内网；Tomcat 管理后台是否弱口令,配置暴露往往比漏洞本身更好用。
计划任务、自启动与文件层
攻击者喜欢留后门,检查：
crontab -lcat /etc/crontabls -la /etc/cron.d /etc/cron.dailysystemctl list-unit-files --state=enabledls -la /etc/systemd/systemfind / -perm -4000 -type f查异常 SUID 文件。
文件完整性可用 rpm -Va 或 debsums -c 辅助，结果会有噪声,要结合时间线判断。
补丁、配置与供应链层
最后回到根因：系统补丁、Web 组件、数据库、Redis、容器镜像、第三方依赖是否长期未升级，管理端口是否直接暴露公网，安全组是否开了过多端口，运维终端是否被钓鱼或感染，行业共识认为，日志留存和备份恢复演练要跟业务等级匹配，关键系统不能只靠“出事再看”。
云服务器被DDoS攻击怎么处理？流量型与入侵型要分开
| 类型 | 典型现象 | 优先动作 |
|---|---|---|
| 流量型DDoS | 带宽打满、入流量突增、业务全断 | 接云清洗或高防、切DNS、联系云厂商、临时限速 |
| 应用层CC | 请求量高、连接数高、页面变慢 | 开WAF CC防护、限速、缓存、人机校验 |
| 入侵型异常 | 陌生进程、异常外连、Webshell、账号异常 | 隔离取证、查入口、清后门、换密钥、补漏洞 |
云上处置先看云监控和账单告警，再确认是攻击还是业务突增，不要一上来就封所有 IP，容易误伤正常用户，DDoS 清洗、WAF 策略、安全组限源要配合用，管理端口只允许固定运维 IP 或堡垒机访问,能减少很大一部分暴露面。
服务器被入侵和误封怎么区分？三个信号帮你判断
| 信号 | 更像误封 | 更像入侵 |
|---|---|---|
| 登录 | 正常 IP 被拒，但日志无异常成功记录 | 陌生 IP 成功登录，失败登录集中出现 |
| 文件 | 无新增可疑文件 | Web 目录新增文件，修改时间集中 |
| 网络 | 刚改过安全组或防火墙 | 异常外连、陌生进程、DNS 请求异常 |
判断不能靠感觉，要看证据链，安全组、运营商、防火墙策略变更都可能造成“像被攻击”，登录日志、文件时间、进程路径、外连目标能对上，才更接近真实入侵，据工信部相关通报，弱口令、未修复漏洞和暴露面过大仍是常见风险入口。
修复漏洞与安全加固：从补丁到监控的落地清单
服务器安全加固方案多少钱？先看范围和交付
报价差异通常来自资产数量、是否含 7×24 值守、是否做漏洞复现、是否含应急响应和修复复测，只买设备不做策略运营，往往解决不了入口问题，先做资产梳理和暴露面盘点，再谈方案和价格,比直接比价更靠谱。
补丁与组件升级
- 生产环境先测试再升级,避免一键全升。
- 优先处理公网暴露的 SSH、Web、数据库、Redis、容器组件。
- 下线不再维护的旧系统,或做网络隔离。
- 容器镜像固定版本，别长期用
latest。
最小权限与密钥管理
- 禁用密码登录,改用密钥或堡垒机。
- 禁止 root 直连,按角色分配权限。
- 定期轮换密钥,离职人员账号及时回收。
- 数据库、Redis、中间件只监听内网,必须设认证。
监控、备份与复盘
- 开启异常登录、异常外连、文件完整性、CPU 异常告警。
- 备份要离线或异地,定期做恢复演练。
- 修复后复测入口是否关闭，旧 Webshell 是否清干净。
- 写复盘：攻击时间线、入口判断、影响资产、修复验证。
修复不是“删掉一个文件”就结束，账号、密钥、计划任务、Web 目录、组件版本都要过一遍，入口不闭环,问题会回来。
服务器被攻击后，先保住证据再动手；排查要落到账号、进程、网络、Web、自启动和补丁上；修复要用验证收尾，而不是用重启收尾。
服务器被攻击排查与修复常见问答
服务器被攻击后先重装系统可以吗？
不建议直接重装，先隔离、快照、保留日志和样本，确认入口与横向移动范围后再重建，重装只解决表面，账号、密钥、供应链入口不换,仍可能再次中招。
北京服务器被攻击排查公司怎么选？
看是否能交付证据链、流量与日志分析、漏洞复现、修复验证和复盘报告，只做“清马”不够，要能说明入口和受影响资产，排查公司交付的核心物通常包括攻击时间线、入口判断、受影响资产清单和修复验证记录。
小公司没有安全团队怎么处理？
先做基础隔离和备份，再按清单检查账号、端口、补丁、Web 目录和计划任务，必要时找外部支持，但要把日志、备份和资产清单准备好，没有日志和备份时,恢复周期通常会被拉长。