全国攻防演习的防守体系建设

0. 前言

笔者于2019年入职阿里巴巴，负责某业务反入侵团队。这三年时间刚好完整参加了三次全国范围的攻防演习活动，第一次是刚入职参加的，刚了解业务，后两次攻防演习作为一号位，带领安全团队均拿下了优异的成绩（全国防守排名前三）。

21年9月加入了默安科技。本文是笔者对阿里这段工作经历的小结，希望能够对大家有所帮助。安全工作还是要结合业务情况来进行部署，不一定完全适用于所有公司。这几年一直在埋头苦干，非常希望与大家多多交流，如有不足之处欢迎批评指正。

1. 确定防守目标

攻防演习开始前，需要提交参演方相关信息，比较关键的的是核心业务系统和蜜罐信息。

前几年演习是有被攻击“出局”这个说法的，核心系统被攻破基本就“出局”了。核心业务系统的选择对结果有重要的影响，所以核心业务系统尽量选择业务隔离内网的目标作为核心目标。不仅可以提升攻击难度，也可以借助演习让攻击者对本单位进行一次彻彻底底的渗透测试。

在明确了核心业务系统后，我们后续的安全排查和加固工作，都要围绕核心业务系统展开。具体排查和加固方式后面3. 安全排查/加固部分重点分享。

另外一个要报备的关键信息是蜜罐，如果没有报备的蜜罐被入侵，不管是自建的还是采购的商业蜜罐，都会算做防守方失分，所以这点一定不能遗漏，尤其是具有高交互特性的蜜罐。蜜罐至少要提供蜜罐的URL、IP、端口、截图。关于蜜罐的部署和利用，我会在后面3.4 反入侵能力增强部分重点讲，蜜罐在威胁感知、溯源反制和威胁情报的重要作用。

2. 组织保障

整个攻防演习期间组织保障非常关键，公司业务层面的重视程度会影响安全排查和加固的效率，间接影响效果。举个最简单的例子，安全团队要梳理各域名资产责任人，需要与运维团队配合，很多老旧的历史资产无人维护，甚至需要找到对应的研发来确认资产所属。如果研发和运维团队认为演习只是安全团队的事情，配合效率低下，这是很可怕的事情。

2.1 项目重要性

为了解决组织内各个团队的配合问题，一定要将演习的优先级在大部门内提起来，这个各个公司可能都不太一样，我们公司是自上而下比较重视攻防演习，所以我们的重点工作主要是制定演习方案。制定好演习方案后与产研、运维、运营等团队达成一致，明确各团队职责，确定演习接口人与安全团队对接。

由于攻防演习本身的性质是针对基础设施的，所以大部分安全部门接到演习任务基本都是“政治任务”，很少会有不重视演习的情况。安全部门要借这个机会尽可能的争取资源、预算，不论整体安全能力如何，每年的攻防演习都是全员配合的重要任务，这是最容易提升安全能力的时候，日常推不动的工作，在演习的背景下，很多问题可以迎刃而解。

除了部门内部的协作外，还要考虑体系内是否有其它安全力量可以合作。比如部分生态公司、合作伙伴与本业务的网络架构有耦合，这些也可能会成为攻击者的突破口，需要对方也做好演习的相关准备，至少要做到攻击情报互通。

2.2 项目启动

在都已经明确各方职责，私下达成一致后，可以开一个项目启动会。介绍演习的背景、规则、目标，以及演习的时间安排、人员安排、工作内容安排等。工作内容是最重要的部分，主要的思路可参考后面3. 安全排查/加固部分的介绍。笔者在其他论坛上看到有人抱怨演习备战中各方都不配合，内部甚至也在“摸鱼”，其实核心原因就是大家的职责不明确，认为自己所做的事情可有可无。所以在启动会上一定要明确这点，大任务分拆成小任务，小任务完不成，大任务也不会有好结果。

2.3 进度风险汇报

项目启动会后，演习正式进入全面备战阶段。

演习备战的大部分工作是安全自身要做的工作，比如Agent部署率、安全产品规则检查等。当然也有很大一部分工作其实并不是安全团队完成，比如业务接入统一认证系统、漏洞修复，可能更多的是研发需要工作，安全部门大多是推动工作，推动的痛苦相信甲乙方的同学应该都了解，如果推不动，对演习结果产生影响是谁都不想看到的，所以备战期间定期进度review非常重要，我们这两年都是秉承着“急事随时汇报，阶段性每周汇报”的思路。说起汇报，就要说一说，汇报给谁？答案是要汇报给兄弟团队，汇报给产研、运维、运营，最重要的是汇报给大领导，因为要汇报的不仅仅是进度，还有需要决策的风险。如果只是汇报进度，周报就完全足够了。

进度汇报的主要思路是围绕“风险”进行汇报，首先是我们目前关注哪些风险？其次是哪些已知的风险落地有风险？比如互联网边界排查，ACL边界开放过大是我们关注的风险，内部系统开放到外部的风险大家都懂，但是我们在排查中就发现有很多内部系统开放到一些未知的IP段，这些IP段看起来似乎也不是本业务的相关IP，但也无人认领。安全部门要不要封禁这些IP段？敢不敢封禁？如何封禁？每周的汇报会上就是要讨论这些风险的如何处理。

3. 安全排查/加固

攻防演习防守的其实是企业资产，演习前的一切安全排查和加固都围绕核心资产展开，以核心资产为中心，向外辐射到各个资产。资产包括物理资产、硬件资产、软件资产等，另外人也是红蓝对抗中最容易造成突破口的资产。梳理资产的目的是为了明确网络边界，只有明确了网络边界和防守边界，才能更好的制定策略。如何梳理全面企业资产我会在3.1 梳理资产部分详细介绍。

我们在落地过程中主要围绕安全部门各小团队的职责来划分工作，读者可以视各自的情况来定。我们主要分为生产网安全、物理安全、数据安全、反入侵这四个部分来构建防御体系。各个团队可能会有部分职责重叠的地方，比如系统网络和应用安全都会面临弱口令等数据安全相关的权限问题，这很正常，在进度风险汇报中说清楚做了哪些，哪些还没做，定清楚Owner即可。

为了保障安全排查的全面性，大部分工作都是正向自查和红队反查的方式进行。下面各章节会详细介绍如何正反怎么配合进行。

3.1 梳理资产

首先资产主要分为硬件资产、软件资产和人。软件资产和人其实相对是比较好收集的，数字化能力相对比较高。硬件资产比较依赖IT和IDC相关部门的能力。不论以何种方式完成资产的梳理，哪怕是Excel来收集，这是一定要做的。

硬件资产主要包括机房设备、网络设备、安全设备、办公网区设备等，这类资产一般涉及到多支团队，需要耗费大量人力投入去梳理。这里需要注意的外采设备的梳理，不论是外采的“盒子”还是私有化部署到服务器上的设备，都要收集到，比如VPN、APT威胁检测设备等，这类设备如果出现漏洞被攻击，比业务主机被拿下的风险还要大。

软件资产主要包括域名、IP、机器、应用等，我们的业务全部上了阿里云，阿里云有完整的API接口可以实现资产的拉取。结合业务使用的云产品，通过阿里云API接口可以基本可以实现云上资产的梳理。

• 域名资产：如果使用了阿里云“云解析”产品，可通过DescribeDomains接口获取所有域名，再通过DescribeDomainRecords接口获取所有子域名。

• IP资产：由于我们的网络架构问题，主要关注负载均衡SLB和弹性公网EIP，SLB可通过DescribeLoadBalancers接口获取所有SLB实例，EIP可以通过DescribeEipAddresses接口获取。

• 应用：阿里云上所有ECS都装了安骑士和态势感知的Agent，可以很方便的取得完整机器列表和IP列表，甚至包括端口开放情况、中间件和版本情况。另外态势感知也会基于中间件版本来匹配已公开漏洞，进行漏洞扫描。

还有一部分资产是“人”，梳理人的资产基本找HR就能拿到全集，梳理这部分数据是为了做后续的安全意识培训和钓鱼演练。

我们第一步花了大量的精力去梳理资产，最终得到了一张公司资产大图，下一步我们要做一件更加痛苦的事情，明确资产责任人和安全责任人。

一般运维团队会有CMDB系统协助我们完成很多资产的归属，但仍有一大部分需要人力推动去确认。如果这里的工作进展的极其痛苦，那么说明日常的安全流程建设，还是有很大的提升空间。如何提升我们在最后的5.2运营机制优化部分细聊。

完成资产梳理工作后，我们就可以正式进入安全自查阶段了。当然，部分已知的安全问题是可以和资产梳理工作同步进行的。

3.2 生产网安全

生产网安全部分主要分为应用安全、系统网络安全、数据和权限安全三大类。

3.2.1 应用安全

应用安全主要围绕漏洞管理和安全方案展开，主要目标是保障生产和测试环境完成安全加固，通过红队渗透测试验收。这里列几个重点工作方向供大家参考。

漏洞修复

已知漏洞修复（含日常SDL检出的漏洞、渗透测试发现的漏洞及其他漏洞）

封网和需求安全评审

演习期间要进行封网，演习期间原则上不允许上线新业务。应用安全团队要积极与产研梳理演习期间要上线的业务，该业务改动较大，安全风险比较大的，建议推迟到演习后上线。

安全能力覆盖率排查

如SDL卡点、白盒扫描、RASP、WAF、安全Agent等安全能力的覆盖率，若未覆盖全的需在演习前覆盖完毕并做好安全检查。

内部高风险系统安全排查

内部高风险系统进行重点安全评估，如运维系统、安全、客服系统。这类系统如果被入侵，通常具有较大权限，甚至可以直接控制线上所有资产。

社会工程学攻击防范

因为演习的规则是允许一定程度的社会工程学攻击的，比如钓鱼邮件、客服系统的攻击，都是比较高频的攻击手法。我们可以考虑在演习期间做一定程度的加固，比如禁止邮箱服务接受外域邮件、客服系统关闭文件上传通道、客服系统超链接点开前二次确认等。

供应链攻击防范

这里包含软件供应链以及生态公司、合作伙伴等，软件供应链主要是检查系统耦合的一些第三方包/库是否安全。对于在网络上存在耦合的合作伙伴和生态公司一方面是要求对方做好加固和值守准备，另一方面是要做好切断合作伙伴与本业务网络通道的应急预案。

3.2.2 系统网络安全

系统网络主要围绕网络边界、访问控制、认证鉴权、主机安全展开。主要目标是确保生产环境、测试环境、预发环境以及办公网的网络安全。列几个重点工作方向供大家参考。

网络隔离排查

网络隔离检查主要两方面，一是边界对外开放情况的摸排，确保内部系统都正确设置了ACL且没有开放过大的情况（比如将内部系统开放给某个大B段）。ACL排查的效果首先取决于3.1 梳理资产部分梳理的资产是否完整。二是内部网络区域划分检查，不要出现“一张网”的情况，防止攻击者突破边界后可直接访问到核心业务系统。

ACL排查主要分为两类，一是域名对外开放的情况排查，二是主机对外开放的排查。我司的安全架构设计的比较严格，所有的主机（ECS）禁止配置弹性公网IP，所有对外开放必须通过SLB，我们通过拉取SLB资产的配置信息即可拿到全部的ACL策略。域名通过拉取WAF/SLB即可拿到所有的ACL策略。所以我们的主要工作都在检查策略上。

检查ACL策略可以先指定一些黑名单，比如对外开放设置为*的，必然需要与业务方确认进行更细力度的设置。设置为大B段的同理。黑名单可以筛掉一大部分异常的ACL规则，白名单的只能逐步与业务方确认。

主机/终端高危漏洞修复

这里主要关注服务器上可被利用的RCE漏洞，未授权漏洞，主要是为了防止黑客利用这些漏洞突破边界，即便被突破，也可以增加横向移动的攻击成本。

如果企业有安装安全Agent，大概率会有主机漏洞扫描的能力，阿里云用户可以使用态势感知进行漏洞扫描，确定要修复的漏洞种类和机器，甚至可以一键修复。当然，修复是有稳定性影响的，需要和运维、研发定好策略，做好备份，按批次修复。

系统弱口令和未授权风险排查

对所有Web系统、安全设备、网络设备进行未授权和弱口令检测。这部分工作要根据梳理的资产写一些小脚本，快速进行检测，可通过主动扫描来做检测，也可通过流量分析来做检测，具体做法这里不细谈。

办公网网络加固

这部分主要是确保终端EDR的部署率，确保安全规则设置无误。可以根据各自的情况做一些相对严格的限制，比如封禁办公网终端间除80，443端口以外的其它端口访问、禁用USB读写（如有强需求建议专机专用）。另外办公网也可以部署一些蜜罐来迷惑攻击者。

办公网的WIFI也可视情况进行加固，如无必要，可在演习期间关闭WIFI网络。

办公网的硬件设备也要注意清点，比如VPN、会议系统等。这类设备很容易对公网开放，且0day比较多，如无必要也可以考虑在演习期间关闭。

3.2.3 数据和权限安全

数据和权限安全团队重点关注账号权限、密钥风险。列几个重点方向供大家参考。

账号权限收敛及密码策略排查

账号权限收敛首先根据梳理的资产明确具有账号权限的核心B类系统，安全设备、网络设备。权限收敛很大一部分工作是做闲置账号的清理。如果公司没有统一认证系统和权限管理系统，那么大概率会出现已离职人员账号未清理、闲置账号（一两年都没用）的情况，这些账号无人使用，如果出现弱口令，被攻击也无人感知，风险极大。密码策略排查这里就不再细说。

密钥治理

由于业务全部上云，各个云产品都有对应的AK/SK，密钥风险的管控在云上尤为重要。主要是密钥泄露风险，如果一个大权限AK被泄露，通过API基本可以控制云上所有资产。泄露的核心原因还是明文存储，在代码中明文存储、在服务器上明文存储、在脚本里明文存储。治理思路首先是排查大权限AK，确认是否有开这么大权限的必要，如果确实有必要，是否可以缩小为只读权限。排查明文存储根据我们的工作场景，主要排查主机文件、OSS Bucket上的文件、Git仓库文件，撰写脚本批量排查这些地方是否有明文存储AK的情况并进行整改。

另外一个方式是对AK做ACL限制，限制AK仅允许生产网的IP段访问API，另外听说阿里云后续要做到AK限制到只有哪个VPC来访问，这里给阿里云点个赞，期待。AK限制ACL这件事推动比较难，在AK申请流程中增加限制可解决增量问题，存量未设置ACL的AK就需要日常去推进了。

密钥治理我们更多的是在讲限制，但问题肯定是没法全部覆盖的，所以我们需要有兜底的手段，我们是通过与反入侵团队合作，调取AK调用记录，定制监控，若AK被非生产网IP所调用，会实时告警。

3.3 物理安全

物理安全顾名思义，也有不少需要注意的点。

3.3.1 办公区物理安全

办公区物理安全主要是防止近源攻击，WI-FI网络、RFID门禁、暴露的有线网口、USB接口等都可能会成为近源攻击的对象，比如我们当时就发现门口的打卡机连接的网线，可以直入办公网。还有乙方老生常谈的“捡U盘”、医院的服务终端机沙盒bypass等。各位可根据实际情况进行对应的加固。

3.3.2 机房物理安全

我司机房也有对应的安全团队，所以额外做了些限制和监控，托管的IDC可做的事情不多，这里不细说。

3.3.3 人员安全意识

人员安全意识比较关键，安全攻防核心其实是人的对抗。理解攻防演习通过社工攻击人的情况太多了，所以一定要做全员安全意识培训，不同工作性质的人群遇到的风险可能不近相同，比如客服是最容易被钓鱼的，那就要对症下药，政策和安全意识教育两手抓。

3.4 反入侵能力增强

聊起反入侵，其实很多公司可能没有反入侵这支团队，入侵检测和应急响应的事情更多的是其它安全工程师兼着就做了，但反入侵这些事情，对攻防演习的效果有决定性的影响。

笔者在阿里主要负责某个业务的反入侵（非集团/阿里云反入侵团队），团队职责主要是威胁感知和应急响应。因为部分思路和技术非本人原创，所以这里只能选择性的分享一些我自己的思考和实践。

我这里按照渗透测试、威胁情报、威胁感知、应急响应、溯源反制五个方面来详细介绍。因为红队的职责也在我这里，所以渗透测试也在这里一同分享。

3.4.1 渗透测试

其实常规的渗透测试可说的不多，每年我们在攻防演习前都会请阿里云对业务进行全面的渗透测试。因为演习目标是“零”失分，所以渗透测试重点一般是模拟突破边界。当然，在日常的渗透测试中也会做东西向渗透测试。

反向验证，在渗透测试这个部分单独说一下。我们安全团队虽然大家做的事情都是为了提升安全能力，但还是分为了以安全加固为主的“正向团队”和更偏攻防实战的“反向团队”。在演习前做的所有加固工作，反向团队都会进行验证。举两个例子，第一个是正向团队为了确保安全防护效果排查了WAF的部署率，那反向团队就会做反向扫描，看是否有遗漏？以及WAF规则是否都正确开启？结果还真发现了由于阿里云WAF大版本更新，IP加白/加黑配置方式变化，导致大版本更新后配置的ACL加白全部无效的情况。第二个是正向团队推进业务接入统一认证系统，结果在反向验证中发现统一认证系统接入SDK并不统一，各个业务放接入方式不一致，导致部分认证可被绕过。

说这么多是为了告诉大家，做安全加固还是要验证，不能太相信“经验”。

3.4.2 威胁情报

实战攻防演习在演习期间，其实是“情报战”。第一年参加演习的时候，感觉雷达就是黑的，不知道谁攻击了我，也不知道现在演习到底什么情况，非常惶恐，这其实就是情报不到位导致的。另外在威胁感知、应急响应、溯源反制大量利用到威胁情报，所以第二部分重点讲一下威胁情报的生产和消费。

威胁情报生产

我们建设了一个内部的威胁情报库，主要包括IP、UMID、UID、姓名、威胁类型、威胁等级、情报可信度等字段。根据如下信息产出威胁情报：

• 历史WAF、态势感知、安骑士、云防火墙、自建告警攻击记录

• 实时沉淀安全告警信息

• 互联网公开威胁情报收集

• 威胁情报蜜罐

• 三方安全厂商及威胁情报厂商合作

• 合作伙伴及生态公司威胁情报共享

上面列的这些威胁情报来源都比较好理解，历史攻击记录都存在ODPS中，通过ODPS SQL就可以查询出对应的信息并写入到威胁情报库。

阿里云大部分云产品日志都存储在日志服务SLS中，通过Blink或SLS自带的数据加工功能即可筛选想要的实时告警写入到威胁情报库。

互联网公开威胁情报就写对应的爬虫存入威胁情报库即可，这里推荐一个免费开源的firehol威胁情报库，firehol本身收集恶意IP是为了做防火墙规则的，当然也可以作为威胁情报来使用。firehol的缺点是只有IP和大致类别，没有更详细的字段。

威胁情报蜜罐这个顾名思义，甲方做的话成本比较高，要考虑投入产出比。建议了解下三方安全厂商和威胁情报厂商，另外默安科技的幻阵蜜罐目前用的厂商比较多，其实是能产出较多的威胁情报的，采购一波默安蜜罐，既能做威胁感知，又可以白嫖重保期间的威胁情报。

合作伙伴和生态公司威胁情报这个也很好理解，需要提前制定好威胁情报格式或者使用国际通用的STIX/TAXII格式，然后推动合作伙伴按照该格式共享威胁情报。当然，也可以在战时人工同步。

威胁情报消费

当我们收集了足够多的威胁情报后，只有在消费/利用了情报才会产生价值，否则就仅仅只是“威胁情报”。

情报消费消费主要分为三大场景：拦截、感知、响应。

拦截：高精准度的威胁情报，我们可以直接加入到防火墙规则拦截，比如firehol的威胁情报就分为很多种，有的是恶意邮件、有的是曾经是C2服务器，还有一类是目前没有被分配的IP，这类IP正常情况是不可能有访问行为的。大家可以根据自身业务情况，选择可以拦截的情报进行主动拦截。

感知：我们所有业务都在阿里云上，阿里云提供了所有ECS的网络连接日志，所以我们可以监测ECS外联威胁情报恶意IP的情况，包括Web访问日志可以过一遍威胁情报。部分无法直接拦截的情报，也可在内网网络连接中进行检测和告警。

响应：演习期间的告警量往往比平时高好几倍，为了提高告警运营效率，我们将所有告警统一到一起，全部过一遍威胁情报，告警运营时可参考威胁情报的评级重点关注相关告警。

威胁情报消费部分这里只是简单讲了讲思路，具体的做法在后面几个小章节里面会细讲。

3.4.2 威胁感知

威胁感知就像是攻防演习打仗时候的情报来源，像雷达一样。威胁感知做的不好，雷达上就一片黑。我们威胁感知的basline是靠阿里云WAF、威胁感知、安骑士等云安全产品支撑。

为了进一步提升威胁感知能力，我们在威胁情报、蜜罐、蜜饵、核心系统重保等方面也下了不少功夫。

蜜罐部署

我认为蜜罐有两个重大意义，一是做威胁感知的兜底，二是溯源反制的利器（后面3.4.4 溯源反制里面重点讲下如何利用蜜罐来做溯源）。大部分安全产品和自建的告警，其实是基于恶意行为的检测，都是“黑名单”，如果没有对某种威胁行为建模，就无法捕获这类攻击行为，所以蜜罐的部署和覆盖策略就非常关键。

蜜罐的原理是模拟真实业务系统，投放诱饵吸引攻击者攻击，攻击者攻击后蜜罐产出告警，达到威胁感知的能力。

互联网和内网面临的攻击手法大不同相同，所以我们在互联网上部署高交互、高仿真的蜜罐，吸引攻击者进行攻击，在蜜罐上植入溯源代码，获取攻击者的互联网ID、设备指纹等信息。除了采购安全公司的蜜罐（疯狂暗示默安幻阵），有条件的单位可以将自己的业务系统代码拿出来，剥离掉所有功能，仅保留登录功能，登录功能使用SSO，这样攻击者在攻击时一定会注册业务系统账号，可能就会留下注册所需的邮箱、手机号、IP等信息，便于识别和溯源攻击者。

扩大蜜罐感知面

互联网蜜罐在部署上我们一般会选择OA、VPN、MAIL等沙箱，那么互联网蜜罐可以使用oa.xxxx.com、vpn.xxxx.com、sslvpn.xxxx.com、webmail.xxxx.com诸如此类的域名，但要注意的是一定要在演习前将该域名报备到蜜罐列表中，否则蜜罐被攻击可能会导致失分。

内网蜜罐主要是为了发现攻击者进入到内网的情况，所以部署的越广越好，但内网假设有1000台机器，我们不可能部署1000台蜜罐，一般的思路是在每个网络区中部署一套蜜罐，然后在该网络区其它机器上部署流量转发脚本，将业务不需要的端口流量转发到内网蜜罐中。

我们的业务是全部上云的，如果是传统IDC厂商，默安有个硬件设备，叫做“中继节点”，部署在交换机上，可以将VLAN中空闲IP流量转发到蜜罐沙箱中（当然，得搭配默安的蜜罐使用）。

诱饵投放

投放诱饵其实也是为了扩大蜜罐感知面，吸引攻击者来进行攻击。投放诱饵其实是顺着攻击者的思路来进行投放，攻击者在做攻击的第一步永远是信息收集，那么攻击者会收集哪里的信息？答案是：Github、百度文库、百度网盘、企查查等等，红队信息收集手法很多，我们在这些必经之路上都可以设置诱饵，比如我们在Github上传一些代码，其中夹杂着蜜罐的URL，甚至放个假密码上去。在百度文库上上传一个XX系统使用文档，里面包含蜜罐的URL和默认账号密码。在百度网盘上传个反制木马，命名为“XXX单位VPN使用帮助”，诸如此类，可做的很多。不过这里想要起到更好的效果，可以先对本单位做一次互联网风险暴露面的排查，看看重灾区在哪，边做排查清理，边做诱饵的投放。在Github上投放诱饵也有一个小tips，如果我们按照正常流程上传代码，那么Github会显示该项目是1秒前刚上传，攻击者又不傻，HW各个公司都在做安全意识培训，怎么可能有研发蠢到在这个时间点上传代码到Github，所以我们可以通过修改系统时间，然后commit的方式，让Github显示这个代码是x年前/x个月前上传的代码。像这样的小tips非常非常多，就不在这里赘述了，我的建议是，买默安的重保服务吧。

3.4.4 应急响应

3.4.4.1 完善感知和处置能力

攻防演习核心其实是攻击和防守，防守上有两个重点，一个是感知（发现攻击），另一个是处置（阻断攻击）。首先在网络层面，至少需要有全流量安全感知设备，可以配套用蜜罐来做兜底的威胁检测。这里也可以做的比较细，比如从互联网的攻击可以用WAF来做感知和阻断，办公网的可以用EDR来做感知和阻断，办公网VLAN间用防火墙来做隔离，邮件安全用邮件网关，诸如此类，要保障几乎所有外到内、内到内的路径我们能发现攻击，且能阻断攻击。

3.4.4.2 完善处置流程

感知和处置能力完成以后，还要考虑人为因素，应急响应流程应该由谁来发起，谁来审批，谁来执行处置动作。这类预案要提前设好，比如DMZ区的主机权限被控如何应急、隔离内网的主机被控如何应急、Web发现攻击如何应急、如果流程上审批都通过了，技术人员按照哪种步骤进行应急。这都要提前写好预案，至少有技术上的playbook。

3.4.4.3 应急演练

应急演练主要是两个目的，一是验证处置能力是否有效。二是验证应急响应流程是否有效。

首先是验证处置能力是否有效，比如：模拟黑客攻击Web，看WAF是否能发现Web被攻击，使用WAF进行拦截，验证WAF拦截的有效性、时效性等。主机侧和网络侧类似。

二是验证应急响应流程是否有效。比如：发现某类攻击，启动应急响应流程，关键人是否敢审批？我们之前在突击演练中就发现一些问题，当技术提交应急响应流程单以后，客户需要层层向上报批，一直报到大领导，才敢审批，这个过程持续了将近30分钟，应急响应的难度大大增加。这种情况就需要对流程进行优化。

3.4.4 溯源反制

规划文章目录的时候，规划了溯源反制，但觉得内容太敏感，这里就省略了。

如果真的感兴趣，建议是私聊我微信吧。

4. 总结

这篇文章缝缝补补写了很久，内容主要围绕在反入侵和攻防的内容，因为这是我的职责所在。现在回头看，觉得写的挺不好的，有很多地方值得改进，不过还是分享出来供大家参考讨论。

最后发个小广告，我目前在默安科技主要负责010实验室，base北京，日常也会打红队项目，也会帮助客户做安全建设，欢迎感兴趣的小伙伴加入我们。

我的联系方式如下：

微信：StrikerSb

邮箱：wangsong#moresec.cn