网站安全建设早已不是买一台防火墙或者装一个SSL证书就能解决的问题。攻击者会从网络协议的底层开始探测，一路摸到业务逻辑的漏洞，任何一层出现短板，整个体系都可能被击穿。真正有效的防护必须分层设计，让每一层都具备独立的阻断能力，同时层与层之间形成联动，把攻击者的横向移动空间压缩到最小。

先从网络层说起。这一层的核心任务是过滤掉绝大多数自动化扫描和流量型攻击，让后面的应用层只需要处理“看起来像正常用户”的请求。DDoS防护是基础中的基础，但很多人只关注流量清洗，忽略了更隐蔽的慢速攻击。例如Slowloris通过保持大量半开连接耗尽服务器资源，这类攻击流量很小，传统阈值检测根本发现不了。解决办法是在反向代理或负载均衡层强制配置请求超时、最大并发连接数和最小传输速率，同时启用连接复用限制。具体到Nginx配置，可以这样写：

http {
    limit_conn_zone $binary_remote_addr zone=conn_per_ip:10m;
    limit_req_zone $binary_remote_addr zone=req_per_ip:10m rate=10r/s;
    client_body_timeout 10s;
    client_header_timeout 10s;
    keepalive_timeout 30s;
    send_timeout 10s;
    limit_conn conn_per_ip 20;
    limit_req zone=req_per_ip burst=20 nodelay;
}

这段配置把单IP并发连接限制在20个，请求速率限制在每秒10个，突发允许20个但立即处理，同时强制所有客户端在10秒内完成头部和包体传输。对于慢速攻击，这比任何流量清洗设备都直接有效。

网络层的第二道防线是访问控制。除了传统的IP黑白名单，更重要的是基于地理位置的访问策略和异常协议行为识别。如果你的业务只面向特定地区，直接在边界设备上丢弃其他地区的TCP握手包，能减少大量无效流量。同时要监控SYN包比例、分片包比例、异常标志位组合等协议层特征。正常用户流量中SYN包占比通常稳定在某个区间，如果短时间内SYN包占比突然飙升到90%以上，大概率是扫描器在探测端口。

传输层安全同样不能只停留在“启用HTTPS”。TLS配置不当等于把加密通道变成了攻击者的掩护。必须强制TLS1.2以上版本，禁用所有已知弱加密套件，启用OCSP Stapling减少证书验证延迟，同时配置HSTS头防止降级攻击。更关键的是证书私钥管理，私钥一旦泄露，所有加密流量都能被解密。生产环境建议使用支持密钥轮换的证书管理服务，或者至少把私钥存储在硬件安全模块中，Web服务器只持有短期有效的临时密钥。

上升到应用层，第一道关口是Web应用防火墙。但WAF不是买来开箱即用就完事了，默认规则集只能拦截已知攻击模式，对业务特有的逻辑漏洞毫无办法。真正有效的WAF策略必须结合业务场景定制。例如一个电商网站的订单提交接口，正常请求的POST参数中价格字段应该是服务端计算好的，如果客户端提交的价格参数与数据库中的商品价格不一致，这就是典型的篡改攻击。这类逻辑漏洞WAF默认规则根本识别不了，需要在WAF中配置自定义规则，对关键参数做业务级校验。

应用层最容易被忽视的是身份认证体系。很多人以为密码加验证码就安全了，实际上撞库攻击、凭证填充、会话劫持才是真正的大头。密码策略必须强制使用足够强度的密码，同时接入多因素认证。但多因素认证不能只支持短信验证码，短信通道本身可能被劫持或遭受SIM卡交换攻击。建议同时支持TOTP动态口令和硬件安全密钥，让用户至少选择两种不同的认证因子。会话管理方面，登录成功后必须重新生成Session ID，防止会话固定攻击；同时设置合理的会话过期时间，对敏感操作要求二次验证。

权限控制是应用层安全的核心。很多系统在设计时只做了“登录”和“未登录”的区分，登录后的用户权限完全靠前端隐藏菜单来控制。攻击者只要直接调用后端API，就能访问未授权的数据。正确的做法是在每个API端点都进行服务端权限校验，基于用户角色和资源归属双重判断。例如查询订单接口，不仅要验证用户已登录，还要验证该订单确实属于当前用户。这种校验必须写在业务逻辑层，不能只依赖路由中间件。

数据安全层往往被放在最后考虑，但数据泄露的后果恰恰是最严重的。数据库中的敏感信息必须加密存储，密码使用bcrypt或argon2这类慢哈希算法，每个用户使用独立的盐值。身份证号、银行卡号等需要可逆加密的数据，使用AES-256-GCM算法，密钥通过密钥管理服务定期轮换。同时严格控制数据库访问权限，应用服务器连接数据库时使用最小权限账号，只授予必要的表和操作权限，禁止使用root账号跑业务。

日志与监控是贯穿所有层的关键能力。没有完整的日志记录，被攻击了都不知道怎么被攻破的。日志必须记录所有关键操作，包括登录成功与失败、权限变更、敏感数据访问、配置修改等。日志内容要包含时间戳、用户标识、来源IP、操作类型、操作对象和结果。同时日志系统本身也要做防篡改保护，建议使用独立的日志服务器，通过只写接口接收日志，应用服务器没有删除和修改日志的权限。监控方面，除了基础的资源使用率监控，更重要的是建立行为基线，对偏离基线的行为自动告警。例如某个账号在短时间内从多个地理位置登录，或者某个API的调用频率突然暴增，这些异常行为需要实时触发告警并自动采取临时限制措施。

纵深防御的真正价值在于让攻击者即使突破了某一层，也会被下一层拦住。网络层的IP限制被绕过，还有WAF的规则拦截；WAF被绕过，还有应用层的权限校验；权限校验被绕过，还有数据层的加密保护。每一层都要假设其他层可能失效，自己必须独立发挥作用。这种设计思路下，攻击成本会成倍增加，大多数自动化攻击会在前几层就被消耗殆尽，而针对性的高级攻击也会因为层层阻碍而暴露更多痕迹。

最后要强调的是，安全防护体系不是一次搭建就永久有效的。每上线一个新功能，每修改一次业务逻辑，都可能引入新的攻击面。必须把安全评审纳入开发流程，每次代码变更都评估对现有防护体系的影响。定期进行渗透测试和红蓝对抗演练，用真实的攻击手法检验各层防护的实际效果。安全建设是一个持续迭代的过程，今天的完善体系明天可能就会出现新的缺口，保持对攻击趋势的敏感度和快速响应的能力，才是多层防护体系最底层的支撑。