网站被黑客攻击了可以报网警吗？先固定证据

网站被黑客攻击了可以报网警吗？当然可以，但有个前提得先跟你说明白：报案不是把火气交上去就完事，得带着东西去。我见过太多站长，被挂马第一反应是登服务器删文件、重装系统、恢复备份，一顿操作猛如虎，等想起要报警，证据早没影了，连哪天被登进来的都说不上来。这篇只聊攻击发生之后的取证和报案这一段，止损和漏洞排查另有文章去讲。顺序就一句话：先固定证据，再提工单，最后带齐材料去报案。心里有个底，做起来就不慌。

第一步：先把时间线写清楚，别等记忆糊了

取证的头一件事不是敲命令，是拿张纸把时间线列出来，趁记忆还热的时候写。三个要素：发现时间，最好精确到几点几分，是你自己看出来的，还是访客、云厂商、搜索引擎的提示；异常现象，页面被改了、跳转到博彩站、后台多出陌生管理员、搜索引擎标了风险提示，一条条写；影响范围，是首页还是整站，是前台还是数据库，用户数据有没有外泄的迹象。这份时间线后面要同时用在工单、情况说明和报案材料里，写得越具体越省事。落笔就用朴素描述，别写判断词。

第二步：把服务器登录日志导出来，看清谁进来过

服务器是 Linux 的，登录记录主要看两处，导出之前千万别清空日志。先执行 last 看最近的登录会话，重点盯来源 IP、登录时间、退出方式，那种来源陌生、时间诡异、或者干脆没有正常退出的记录最可疑。再看 /var/log/secure，里面是认证过程的流水账，用 grep 把失败和成功的记录分别拉出来，例如 grep -i ‘Accepted’ /var/log/secure 和 grep -i ‘Failed password’ /var/log/secure。顺手把 who 和 lastlog 的输出一起留档，看看当前谁会话还挂着。看不懂内容没关系，导出来存好，让专业的人去解读。

第三步：从 Nginx 日志里筛出攻击 IP 和请求特征

Web 层的证据全在访问日志里，路径一般是 /var/log/nginx/access.log，站点单独配过日志的就去 /www/wwwlogs 一类的目录里找。它不用你从头读，靠命令筛：想看谁打得最凶，用 awk ‘{print $1}’ access.log | sort | uniq -c | sort -rn | head -30，访问量异常高的那几个 IP 基本跑不掉；想看谁在试后台和可疑路径，用 grep -E ‘wp-login\.php|xmlrpc\.php|\.env|phpmyadmin’ access.log；想看谁在传可疑文件，用 grep -E ‘POST .*\.(php|jsp|asp)’ access.log。把命中的原始行整段导出成文件，别只留截图。

第四步：连同被篡改文件一起打包，记好校验值

日志只是半边证据，另一半是现场本身。把被改过的页面、被塞进去的可疑文件、后门脚本、异常上传目录，按原路径整份保留下来。打包用 tar，例如 tar -czvf evidence.tar.gz /var/log/nginx/access.log /var/log/secure /www/wwwroot/你的站点目录，注意别在服务器上删原件，包是副本。打完包立刻算校验值，用 sha256sum evidence.tar.gz 把结果记在纸上或备忘录里，再复制一份存到别的地方。校验值的用处是证明这份证据从你手里出去以后没被改动过，这一步很多人省掉，真到要说明来源的时候就说不清了。

第五步：重要页面的截图和录屏，别嫌麻烦

日志很硬，但人看着费劲，截图和录屏是把事情说清楚的捷径。要拍的包括：被篡改的页面外观、跳转后的落地页、后台里的陌生账号列表、搜索结果里的风险提示、访客投诉的聊天记录。拍的时候让浏览器地址栏一起进画面，最好再带上系统时间，证明这是哪个域名在什么时候的样子。录屏就从打开首页开始，把跳转过程完整走一遍，别剪。文件统一命名，带上日期和内容，比如 0910 首页跳转录屏，攒在一个文件夹里，后面打证据包时一起放进去。

第六步：向云厂商提工单，请求协助溯源和出说明

证据固定好，接着找云厂商，这一步是正规流程里少不了的一环。工单里把三样写清楚：服务器 IP 和实例 ID、时间线摘要、证据包的校验值，然后明确提出诉求，请协助排查攻击来源、保留相关访问日志、必要时出具情况说明。出事之后别急着释放实例，机器一退，平台侧的网络日志和快照往往也跟着没了。各家能提供什么、保留多久、怎么申请，以服务商或官方页面说明为准，我不替他们打包票。工单回复和聊天记录都截图留档，这本身就是材料的一部分。

第七步：去当地网警报案，材料提前备齐

损失比较大，比如被勒索、被大量篡改、明显影响经营，就带上材料去当地网警报案，走正规渠道，别在网上乱找所谓的代办。材料清单照着准备：主体证明，营业执照或者个人身份证；域名与服务合同，域名证书、服务器购买记录、备案信息；损失凭证，订单退款记录、广告投放损失、恢复支出、客户索赔的往来记录；证据包，前面那个 tar 包加校验值、截图录屏、云厂商工单记录。所有材料各备两份，电子件放 U 盘里，别抱一堆散截图去现场。具体受理要求和流程以当地公安机关说明为准，拿不准先打 110 问清楚。

第八步：备份必须离线另存，别跟网站放一起

最后这条是无数人用真金白银换来的教训，比前面任何一步都重要。备份千万别跟网站待在同一台机器、同一个账号下：挂着的数据盘、同账号的对象存储、同一台机器上的定时打包，勒索类攻击上来先加密的就是它们，等于把备用钥匙和门锁挂一块儿。规矩是留一份离线备份，移动硬盘备份完就拔线，NAS 做快照，再配一份异地冷存。备份能不能用还得验证，恢复包在测试环境真跑一次，别等到出事才发现包是空的。平时顺手养成习惯，日志留存周期按服务商说明来，重要的自己定期导。

把顺序再顺一遍：写时间线、导登录日志、筛 Web 日志、打包算校验值、截图录屏、提工单、备材料报案，最后把离线备份这件事补上。被攻击丢人吗？一点不丢人，天天有人被扫；真正亏的是证据没留住、材料凑不齐，最后只能吃哑巴亏。平时把日志留存和离线备份当回事，真出事那天你会发现，省下的不是时间，是钱。