防火墙
当前主流防火墙在基本的基于五元组（源目IP、源目端口、协议号）检查的基础上引入了状态检测，即对于接收的报文顺序有所要求，比如需要先接受到某个5元组的IMCP request（type 8 code 0）报文，然后再从反向接受到对应5元组的ICMP replay（type 0 code 0）报文，才认为这是一个正常状态的报文，并将其放过。如果首包接受到一个ICMP replay报文则会认为其状态不合法并将其丢弃。这样实现的好处在于引入了更为严格的访问控制，能够极大减小伪造源地址攻击的危害。因此如果业务（主要是TCP这种有状态的）只是单向过墙，需要在防火墙上关闭状态检查。
将部分具有相似属性的接口划分安全域，为不同安全域分配优先级，各个安全域之间按照优先级互访的方法过于不安全。安全域只应该是一个名称，用于对防火墙连接的业务区域做逻辑划分，本身不该有优先级概念。隐式拒绝，按需放通，最小权限才是防火墙策略部署的正确做法。尤其在零信任愈发为各大公司所接受的当下，防火墙更为主要的作用在于拦截不必要的、非预期的访问流量。
防火墙的性能瓶颈主要在新建、并发和吞吐。由于其特性，新建会话需要上送到CPU进行安全过程的处理，进入稳态后才会通过硬件转发，高新建会极大消耗CPU处理能力，比如漏扫多线程对大目的地址段进行扫描、用zmap等扫描工具穿过防火墙进行扫描等很容易就将防火墙打挂，这种状态下由于探测完后就拆链所以并发不大，探测报文基本都是小包所以吞吐也不会成为瓶颈，唯一的瓶颈就行新建，这在防火墙作为出口网关的场景下比较常见。由于防火墙的状态检查机制，不同状态的连接有不同的老化时间，一旦连接老化后对应五元组的报文经过防火墙时会由于状态非法而被丢弃，部分业务基于其特性要求使用长连接（即对应五元组老化时间变长甚至不老化），如果并发过大而连接不老化会消耗设备内存。对于多核多线程的防火墙，如果逐流转发，一旦由于五元组hash问题导致流量集中到某几个核处理，将单核打满，即使未达整机吞吐也会出现部分业务丢包的情况。
IPS/IDS
IPS（入侵防御系统）和IDS（入侵检测系统）的区别在于部署位置的不同。IDS主要用于旁路部署在网络中接收镜像流量基于流量特征生成对应的告警日志，优点在于只需接收到镜像就来即可，不会由于增加IDS而影响现有网络或造成业务故障，缺点在于IDS仅检测上报，不对检测到的威胁进行阻断。IPS则是侵入式的部署到网络中，可以实现对检测到的威胁进行拦截阻断，但同时也引入了导致业务故障的风险。
在网络中引入IPS需要考虑如何避免IPS故障导致业务中断。对于IPS可靠性，可以通过双机热备实现故障切换，或者对于透明二层部署的IPS可以通过监控CPU和内存利用率在触发阈值时实现软件bypass，如果IPS有硬件bypass接口，在部署的时候应该考虑优先使用bypass接口对，这样在设备掉电时可以实现硬件bypass。此外，IPS作为7层设备，如果串联进网络中需要在部署前对网络吞吐进行详细评估，避免IPS成为性能瓶颈。
IPS/IDS需要保持特征库和官方最新才能有最好的防护效果。任何一款IPS/IDS都不可避免的存在漏报（false pasitive）和误报（false negative），漏报需要在有对比的情况下才能评估判断，而误报需要及时排除，避免由于频繁的误报掩盖了真实的攻击信息。在设备上线初期可以开启所有规则，然后动作设置为放行并记录日志，定期和业务侧就日志进行沟通，将确认是误报的规则关闭或者放行，一段时间后在基于前期整理的误报规则重新配置IPS规则。对于IPS误阻断业务从业务侧的定位方法可参考我之前写的文章：为什么服务器突然回复RST——小心网络中的安全设备
以上描述的都是网络侧的入侵检测和入侵防御（NIPS、NIDS），HIDS（Host-based Intrusion Detection System）也是防护中不可缺少的一环，尤其是当终端和服务器之间建立的是HTTPS连接时，NIPS和NIDS基本没有检测效果，此时HIDS可以对服务器上的文件进行扫描，并对主机上的操作进行监控，可以及时发现webshell、后门等威胁。关于HIDS更多的信息可见保障IDC安全：分布式HIDS集群架构设计
WAF
WAF常见的部署方式有：透明部署、旁路监听、反向代理。透明部署的优点和IPS一样，无需改动上下游网络，设备出现异常时可以通过bypass跳过设备保障业务。旁路监听模式用于对镜像流量进行审计，和IDS功能类似，不过更专注于Web层的防御，部分旁路监听模式的WAF可以通过伪造服务器地址发给RST报文给终端来实现阻断恶意攻击，这需要WAF的响应包比服务器响应包先到达终端才能实现。反向代理是WAF部署中最常见的部署方式，无论硬件WAF还是软件WAF都适用，在WAF反向代理的场景下，服务器对终端呈现的地址是WAF的反代地址。反代部署的优点在于一方面可以通过路由控制只将需要防护的流量指向WAF从而减少无关流量对WAF性能的影响；另一方面，反代模式下，终端和WAF的反代地址建立一个TCP连接，WAF和服务器建立一个TCP连接，因此可以通过WAF拦截掉4层及以下的攻击流量。
WAF透明部署的缺点在于所有流量都会经过WAF，WAF会消耗性能对这些流量进行转发，而且一旦WAF挂死且bypass失败会导致所有业务中断，有单点故障风险。旁路部署模式的WAF一般用于威胁监控，部分攻击需要基于服务器返回值才能进行判断，所以在做流量镜像时需要保证双向流量都被镜像到WAF，否则会导致WAF的检出率下降。反代模式部署时，对外提供的服务器地址是WAF地址，需要在部署阶段考虑WAF的高可用性，避免在WAF故障后业务无法迁移，常见的做法是在出口防火墙上对WAF监听地址做一次NAT，一旦WAF故障后可以在防火墙上修改映射关系将映射地址指向服务器地址。此外，由于WAF会作为客户端向服务器发起访问，如果业务并发过大，需要在部署初期考虑到WAF反代时候连接服务器的地址是否能池化，如果WAF连接服务器时只有一个地址那么即使把保留端口（1-1024）用上，最大并发（五元组）也只能是65535个。如果出现服务器主动发FIN拆除连接的情况，可用并发数会更低。具体请见之前写的例子：TCP状态机：当服务端主动发FIN进TIME_WAIT，客户端源端口复用会发生什么
作为一个七层设备WAF对Web攻击的敏感度要远高于IPS，因此在部署上线初期必然会出现大量的误报，为了将业务影响降低到最小，可以在上线初期对业务流量仅检测记录日志不阻断，在手工排除误报项后定期和业务侧对无法确定是否为误报的项进行沟通，整理出规则例外列表和误报URL，当规则例外列表中的规则数和误报URL数趋于稳定后，可以将明细的误报URL加白，对于规则例外列表中的规则谨慎禁用，将其他规则启用阻断后WAF完成上线。特征库是WAF识别能力的重要依据，因此需要保持特征库最新。建立和业务侧的沟通机制及时解决误阻断。
VPN
当前最常见的VPN有IPsec、SSLVPN、L2TP等。基于IPsec流量可以通过ESP进行加密保证传输的安全性，常用于点对点之间建立加密通道保护数据流。SSLVPN基于SSL提供加密传输，可以支持Web接入、TCP接入、IP接入，是远程办公的首选方式。L2TP可以封装2层报文并且能够提供终端身份认证功能，但是其本书不具有加密能力，因此L2TP常常结合IPsec使用，在提供认证的同时对流量进行加密，主要用于移动终端远程接入内网。
IPsec部署最大的困难在于需要一一比对建立IPsec隧道的两端设备的各项参数，基于IKE的IPsec认证中，一阶段主要实现双方互相进行身份认证，以及协商保护二阶段所需要使用的加密和认证算法，二阶段主要用于双方交换IPsec加密相关算法，协商感兴趣流。IPsec建立起来后，对IPSec的维护主要有两方面的工作：一方面是对于新增业务，需要同时修改两端的IPSec感兴趣流，两端协商出来的感兴趣流是各自感兴趣流的交集。另一方面需要防止IPSec隧道异常断开，异常断开一般是由于中间链路不稳定导致报文被丢弃或者长时间没有业务流量经过IPSec隧道自然老化，可以通过配置DPD检测的方式规避此类问题。
SSLVPN有丰富的认证方式，可以在拨号过程中完成多因素身份认证（我是谁、我有什么、我知道什么），常见的认证有：用户名密码认证、证书认证、短信认证等，而用户名和密码认证即可以在设备本地完成，也可以将认证数据摆渡到远端的Radius、LDAP等类型的认证服务器，基于其返回结果对终端进行动态授权。终端通过SSLVPN进行IP接入后会在终端生成虚拟网卡，该网卡会基于VPN网关设备上配置的策略进行路由下发将匹配的流量转发到VPN网关处理。在此种场景中需要注意，如果不是所有流量都强制走VPN网关，终端通过域名方式访问内网资源时，由于终端系统的实现，会轮询进行DNS查询，有可能会通过本机物理网卡设置的DNS地址进行解析，进而出现解析失败或者解析到公网地址的情况。对于此类异常，一般需要强制流量走VPN隧道或者修改终端host来解决。
两种VPN还有一个共性问题，由于VPN内部封装的是IP层报文，为了保持一致性，外层VPN报文的IP层一般会复制内层报文IP头中的FLAG置位情况，也就是说，如果内层报文的DF标志位置位，外层VPN报文也会将自己的DF标志位置位。如果内层报文比较大，在经过加密、外层封装后，整个报文的长度可能大于接口MTU，又由于该报文设置了DF位，因此报文到达出出接口时会由于报文长度大于MTU，而又不允许分片导致报文被丢弃造成业务异常。常见的规避办法是在VPN设备连接内网资源的接口上或者全局调小TCP MSS 值，减少封装后报文长度大于MTU的情况出现。但是TCP MSS的值也不宜设置过小，否则会导致文件传输速率明显降低。
（未完...）