前几期大概讲述了安全体系架构的概述以及管理层面的安全体系架构，这一期来讲讲业务在设计时制定安全架构的落地实施。

一、 确定业务接口因为业务的特殊性，业务接口可能不止是web层面的，有些业务为了保证传输速率甚至有可能是udp协议传输，也有些业务走的是socket协议，首先就是要确定你的业务接口走的是什么协议，以下以TCP-HTTP协议为主，其他协议的架构安全会在后期叙述。

二、 业务逻辑设计通过上面步骤确定好了业务接口后，需要按照业务的逻辑去设计架构（以下均为http接口设计架构），举例，某业务分为以下几点，API接口与客户对接，静态资源展示企业信息，管理接口对应企业内部人员审核等工作，客户接口对应客户的管理工作。

在资金并不充足的情况下（不投入厂商安全设备），那么对应的架构应该如何设计呢？逻辑架构图（可用性部分）：首先要有代理服务器，保证应用服务器不会直接暴露在公网上。

其次要有日志服务器，汇总应用日志与攻击日志，防御服务器可以自己组建，各种脚本的匹配来确定请求是否合法。

由互联网访问的请求首先经过代理服务器，这么做的好处在于会保护应用服务器的真实IP与端口，举个例子，应用服务器对外接口是443，那么在代理服务器仅需要代理443端口对应应用服务器的443端口，其他端口全部封闭，那么应用服务器上多余的端口是在互联网无法扫描到的，另外代理服务器上仅做转发，性能上消耗会很小，一台应用服务器上跑一个应用，然后通过代理服务器汇总，会很大程度上方便人员进行统一管理，不会造成应用堆砌的现象。

通过代理服务器转发进来的请求，首先进行行为异常分析，此处可以是使用厂商设备，也可以自研脚本，根据经费情况自行选择合适的方案。

关于防御服务器，有几点想跟大家分享，第一是WAF，第二是防CC攻击。

首先WAF我们都知道是通过正则表达式做内容匹配，如果内容匹配上则判定为攻击，那么就会产生三个问题：第一是正则的绕过第二是正则的业务阻断第三是正则书写本身的bug

第一点举个例子好了，目前开源的WAF中规则写的不错的就是modsecurity了，以它举例，规则基本上每周都会有更新，但是绕过方法还是屡见不鲜，没有哪种防御是能完全阻断攻击的，总会有各种各样没有被发现或已经被发现的漏洞，时常关注信息，及时查漏补缺方能在一定程度上体现安全性。

第二点是所有WAF的一个硬伤，因为业务是不固定的，随时可能有业务信息触发了WAF的规则而导致业务阻断，这也是为什么知名厂商WAF要先观察一段时间调优后才能开启阻断的原因。

第三点还是以modsecurity举例，毕竟是开源代码都能看到，正则表达式本身因为书写的问题，会有很多模糊匹配或者联合匹配，当这些匹配内容过大的时候就会因为变相DoS攻击，这在modsecurity3中也是被证实的，同样的问题在日志写入的时候也会发生，导致i/o读写通道堵塞引起的DoS攻击同样在modsecurity2中被证实。

安全无止境，并不是设备的堆砌，脚本的堆砌就能保证业务的安全可用，这点是我通过以上3个问题重点想要说的。

关于防CC攻击，一般的防CC设置是判定为是CC攻击，阻断，而非丢弃，这块我有不同的看法，假如说一个正常访问请求我响应需要100k的相应包，一个阻断包（返回403或自定义页面）假设需要5k，但是流量还是通过入口进来了，尤其是云服务器有的可能是按量付费，那我们是不是应该思考一下如何让非法流量不能通过入口进来？传统的抗DDoS设备做的流量清洗或者黑洞阀值不会设置的很低，那么这块要如何做？后期我会分享出来我的解决办法。

三、 业务架构图设计根据逻辑架构图来制定业务的整体现实架构（可用性部分）通过负载均衡实现代理服务器的双活，大程度保证访问不会中断，同时应用服务器使用主备双服务器，数据库也是主备双活，很大程度上保证了业务的可用性，防御服务器集群用来分析入侵行为，日志服务器用来汇总业务相关的所有日志。

当然防御服务器集群是至少3台以上，并且每台都会向下兼容应用服务器，这么做的目的在于，行为分析是十分耗资源的一件事，搭建集群会降低单一服务器的运算压力，并且不用担心出现单点故障。

同时保证每个业务接口的入口均为独立入口，这样可以将业务分离出来，也方便防御服务器做单一业务的规则，保证规则的准确性。