网站遭遇攻击这件事，没碰到过的人会觉得离自己很远，经历过之后才知道麻烦不小。有个中小型电商网站，遭受CC攻击持续三小时，服务器CPU满载，正常用户无法访问。这三小时损失订单，加上后续客户流失带来的损失，总额超过一年服务器费用。攻击者不会区分网站大小，依靠扫描工具全网段探测，只要找到存在漏洞的站点就发起攻击。只要你的网站接入公网，就会进入扫描范围。
先梳理网站常见攻击类型。底层是DDoS攻击，向目标IP灌入海量流量，占满带宽，正常用户请求无法抵达服务器。这类攻击比拼流量规模，小型站点很难自行抵御，需要依靠上游流量清洗服务。再往上是CC攻击，不抢占带宽资源，模拟大量正常访问请求，反复调用消耗服务器资源的页面，例如搜索接口、登录接口、数据库查询页面。单次请求就会加重服务器运算压力，几千并发请求就会打满CPU，耗尽数据库连接池。CC攻击更难防御，请求特征和真人访问高度相似。
更高一层是应用层漏洞攻击。SQL注入属于老牌高危攻击手段，攻击者在输入框构造恶意SQL语句，直接拖取数据库，用户信息、订单记录全部泄露。XSS跨站脚本，在页面植入恶意JavaScript代码，其他用户访问页面时脚本在浏览器运行，盗取cookie，劫持账号。文件上传漏洞更直接，上传伪装成图片的webshell，攻击者拿到服务器命令执行权限，相当于拿到服务器操作权限。还有文件包含、命令注入、反序列化攻击，原理各不相同，目标都是夺取服务器控制权。
防护第一步不是采购高价防护设备，先把基础配置落实到位。服务器只开放必要端口，80、443端口对外，SSH端口修改为非标准端口，数据库3306、5432端口禁止对公网暴露，仅允许本机或者内网访问。这一步可以拦截绝大多数自动化扫描探测。密码策略也要规范，SSH禁用密码登录，改用密钥认证；数据库密码设置长且复杂，不要直接使用root账号对接应用程序，单独为每个应用创建数据库账号，账号权限只开放对应数据库和数据表。
第二步及时更新补丁。CMS系统、开发框架、插件、中间件，只要发布安全更新，尽快完成升级。很多攻击利用的漏洞，数月甚至数年前就已经修复，攻击者专门扫描没有升级补丁的网站。WordPress站点要格外留意，插件是主要风险点，安装大量长期不更新插件，等于在服务器预留后门。不用的插件直接删除，不要只做停用操作。
第三步部署WAF。Web应用防火墙部署在服务器前端，检查每一条HTTP请求，识别SQL注入、XSS、文件包含这类攻击特征并拦截。云WAF接入简单，修改DNS解析即可生效，厂商持续维护规则库，新漏洞出现后更新速度比自己维护更快。ModSecurity搭配OWASP核心规则集这类开源方案也能使用，但规则调优需要经验，误拦截概率高于云WAF。WAF不是万能防护，无法拦截零日漏洞和精心构造的绕过攻击，但缺少WAF，基础自动化攻击都挡不住。
第四步做好备份，并且做恢复演练。备份遵循3-2-1原则，至少三份数据副本，存储在两种不同介质，一份异地保存。很多人做了备份，但从不测试恢复，等到出事才发现备份文件损坏或者不全。定期在测试环境尝试恢复备份，确认网站可以正常启动。备份频率跟随数据更新速度，电商站点每天甚至每小时备份，博客站点每周备份一次就足够。
还有几个细节容易忽略。网站目录权限收紧，上传目录禁止脚本执行权限，图片文件只能作为静态资源，不能运行脚本。错误提示不要直接展示给访客，PHP关闭display_errors选项，数据库报错、服务器路径这类信息泄露，等于给攻击者提示攻击方向。后台登录页面开启二次验证，或是限制可访问IP，不要直接对外暴露admin、login这类常见后台地址。日志文件做好留存，Nginx访问日志和错误日志至少保存一个月，遭遇攻击之后，可以回溯攻击者IP和攻击方式。
如果网站已经遭受攻击，不要第一时间直接关闭站点。保留现场，保存日志与流量记录，确认攻击类型和入侵入口。DDoS攻击，联系云厂商或者CDN服务商，切换至高防流量清洗。CC攻击，开启WAF对应的CC防护规则，限制单IP请求频率。漏洞入侵，先修补漏洞，清理webshell，重置所有账号密码与密钥，再通过备份恢复站点数据。最忌讳发现被入侵直接重装系统，日志全部丢失，无法确认入侵途径，也不能排查是否留有后门。
网站安全不存在一劳永逸的方案，攻击手段持续迭代，防护策略也要同步调整。落实前面这些基础防护操作，可以阻挡九成以上攻击。剩下的攻击风险，依靠持续监控和快速响应处理。不要等到遭受攻击才查看日志，养成定期巡检的习惯，比高价防护设备更有效。