网站核心业务专属防攻击防漏洞配置技巧

给核心业务做防护，最忌讳的就是把运维厂商卖给你的那套“打补丁、装WAF、买高防IP”当成标准作业流程。这种流水线式的防御，对付脚本小子还行，碰上专门盯着你业务逻辑漏洞来的精准打击，一打一个准。核心业务的防护，必须从业务架构搭建的第一天就内嵌进去，而不是事后叠床架屋。

绝大多数应用被攻破，都是从扫描端口开始的。核心业务服务器上千万别开着Redis的6379、MySQL的3306、SSH的22端口，就这么赤裸裸地对公网开放。正确的做法是，利用云服务商的私有网络VPC，把所有数据库、缓存、消息队列全部放入无公网IP的子网。业务服务器如果需要主动外联，比如调用第三方支付接口，就用NAT网关统一出口。对于运维管理端口，必须通过堡垒机跳转，并且堡垒机自身要绑定多因素认证。不要迷信改端口号，把22改成2222，扫描器几秒钟就能发现，这属于自欺欺人。

核心业务里，最容易出现漏洞的地方往往是那些允许用户上传、交互的功能点。如果把用户上传的头像、附件直接存在核心业务服务器上，一旦被传进一个带后门的图片马，整个机器就沦陷了。必须做到动静分离，所有用户生成的内容，一律推送到对象存储，并且开启对象存储的公共读、私有写权限。前端页面直接走对象存储的CDN回源，压根不经过业务服务器。同时，在服务器层面，哪怕只有一台机器，也要用容器或者至少用非root用户去跑应用进程，限制该进程的系统权限，禁止其访问/etc/passwd这类敏感文件，禁止执行curl、wget这类外联命令。

很多人觉得数据库被拖走，只要密码哈希加盐了就万事大吉。但真实的黑产攻击中，手机号、邮箱、真实姓名这些明文信息的泄露，比密码泄露更致命。针对核心业务数据库，第一要务是做好数据脱敏。开发环境和测试环境，绝对不允许导入生产环境的全量真实数据。其次，对于必须展示给前端用户的敏感字段，比如身份证号中间几位，要在后端接口返回时做掩码处理，而不是前端拿到完整数据再隐藏。更硬核的做法是启用应用层加密，把加密密钥托管在KMS密钥管理服务里，数据库里只存密文，即使SQL注入打穿了，拿到的也是一堆无法解密的乱码，因为密钥根本不在数据库服务器上。

短信接口被刷、登录接口被撞库，这是核心业务最常见的痛点。传统的频率限制，按IP限流，在现在移动基站出口IP高度集中的情况下，很容易误伤一片正常用户。更精准的做法是引入设备指纹和全链路人机验证。在登录、注册等关键接口，前端集成设备指纹SDK，生成唯一设备ID。后端限流策略不能只盯IP，要结合设备ID、用户ID、会话Token做多维度的滑动窗口计数。一旦某个设备ID在短时间内频繁切换账号，或者某个IP下出现大量不同设备ID，立刻触发升级验证，比如弹出滑块验证码，或者直接静默丢弃请求，返回一个假的成功响应，让攻击者无法判断是密码错误还是被拦截了。

线上业务如果一报错就把详细的数据库表结构、代码文件路径抛给前端，等于给攻击者画了一张入侵路线图。全局异常捕获不是简单包一层try-catch就完了。在生产环境中，所有未捕获的异常，必须返回一个笼统的“系统繁忙，请稍后再试”或者统一的错误码，绝不能把类似“SQL syntax error near 'xxx'”这种信息透出。真正的错误详情，包括堆栈信息、请求参数、用户身份，要异步写入日志中心，并触发实时告警。这里有个细节，日志里如果记录了用户输入的密码、Token等敏感参数，必须在日志采集组件里配置脱敏规则，防止二次泄露。

核心业务系统用到的开源组件，像Struts2、Fastjson、Log4j，这些曾经引发血雨腥风的组件，至今仍有大量系统在裸奔。不要指望运维手动去查，必须把软件成分分析SCA工具集成到CI/CD流水线里。每次代码提交，自动扫描pom.xml、package.json、requirements.txt里引用的第三方库，对照公开漏洞库，发现高危漏洞直接阻断构建。同时，生产环境要部署运行时应用自保护RASP机制，它不像WAF那样站在门外靠规则猜，而是直接注入到应用进程里，能精准识别SQL注入、命令执行、反序列化攻击，并在攻击生效前拦截，连0day都有一定的防护能力。

全站上HTTPS已经是底线了，但证书私钥的管理才是命门。私钥文件绝对不能放在网站目录下，或者随代码一起提交到Git仓库。应该使用云平台的证书管理服务，或者至少做到密钥跟业务服务器分离。另外，为了防止中间人攻击和DNS劫持，核心业务应该开启HTTP严格传输安全HSTS头，并设置一个较长的有效期，甚至申请加入浏览器的预加载列表。对于App端核心业务，要做SSL Pinning证书绑定，只信任你自己的证书，就算用户手机被装了恶意根证书，也无法抓包分析你的接口协议。

大流量DDoS攻击，靠堆硬件带宽硬抗是无底洞。核心业务要做的是“近源清洗”加“智能调度”。首先，利用DNS的智能解析，把不同运营商的用户流量直接导向对应线路的清洗节点，避免绕路。其次，在业务入口处做前置的协议栈挑战，比如对TCP连接先做SYN Cookie校验，对UDP流量做反射放大识别。最关键的一点，是要跟业务做联动。当检测到某个业务域名正在遭受攻击时，能不能在30秒内自动将该域名的DNS解析切换到高防清洗中心，同时把其他没受攻击的业务流量保持在原线路不动？这种精细化的流量调度，比无脑买几百G的防御包要有效得多，也省钱得多。

薅羊毛、刷优惠券、恶意占库存，这些攻击走的都是正常业务流程，WAF和防火墙根本看不出来。对付这类问题，必须在业务代码里埋点。比如一个正常的用户浏览商品、加购物车、下单、支付，时间间隔和页面跳转是有逻辑关系的。如果发现某个用户直接请求下单接口，且连续尝试不同的优惠券码，这就是典型的脚本行为。可以做一个轻量级的规则引擎，把用户的行为链路抽象成状态机，一旦发现状态跳转异常，比如未经过浏览详情页就直接发起支付，或者在一个session内尝试了超过正常数量的优惠券，就对该会话实施风控策略，比如要求输入支付密码或人脸识别，而不是直接封号，以免误伤真实用户。

攻击者一旦拿下任何一台边缘服务器，下一步一定是横向移动寻找核心数据库。因此，内网不能是平坦的。要利用安全组策略，做到严格的白名单访问控制。比如，Web服务器只能访问数据库的特定端口，数据库服务器不能主动访问互联网，也不能访问其他Web服务器。同时，堡垒机录制的运维操作录像，不能只是存着当摆设，要启用命令审计，自动识别rm -rf、drop table、提权操作等危险指令，并触发实时拦截。对于服务器上突然出现的异常进程、异常外联、异常定时任务，要基于主机的入侵检测系统HIDS来抓，它能看到WAF和云防火墙看不到的机器内部鬼影。

数据库被删、文件被加密，面对勒索攻击，如果支付赎金能解决问题，那就不叫勒索了。现实中，很多支付了赎金的受害者，拿到的是有bug的解密工具，或者再次被勒索。所以，核心业务的备份策略必须是“3-2-1”原则的加强版：至少3份副本，存放在2种不同介质上，其中1份必须是离线的。这里强调离线，是因为现在很多勒索软件会主动搜寻挂载的备份盘和网络共享目录一并加密。可以用磁带库，或者用对象存储的合规保留模式，设置WORM一次写入多次读取锁，在锁定期内，即使管理员账号也无法删除或修改备份数据。定期做恢复演练，别等到真出事了才发现备份文件是坏的。