HW行动，攻击方的专业性越来越高，ATT&CK攻击手段覆盖率也越来越高，这对于防守方提出了更高的要求，HW行动对甲方是一个双刃剑，既极大地推动了公司的信息安全重视度和投入力量，但同时对甲方人员的素质要求有了很大提升，被攻破，轻则批评通报，重则岗位不保；大的金融、央企可能不担心，有很强的防护，很全面的安全值守；但是相当多的二级单位或者中型公司，可能没那么专业，然后听从乙方来忽悠，上一堆设备，上大屏展示，图很酷炫，数字很夸张，每天防守几万次攻击，不是说这些没用，而是首先要立足于将产品和服务用好，比如资产梳理，比如防火墙，waf策略优化，这个应该是甲方最基础的事情，也不应该全部交给乙方，有的单位被忽悠上了态势感知，但是连基本的waf策略也没有优化，报表表面上很客观，实际的攻击含金量很低。

作为参与了2年HW的甲方，总结了一些防御尤其是边界防御的基本要素，简单明了，抛砖引玉，给大家参考。

首先在HW期间（其实平时也需要这样），都是战略上藐视敌人、战术上重视敌人，敌暗我明，敌众我寡，这个现实是摆在眼前的，而且我方是一定存在漏洞的，这个也是必然的，兵来将挡水来土掩的方式不再适用于现代化的网络战，基于这样考虑，我们可以做如下假设：

1.我方是一定存在漏洞的，攻方也一定存在破绽，高手对决就看谁先露出破绽；

2.一次成功的攻击，背后必定有10次以上的失败攻击；

3.拥有0day类的核弹、能够一发制敌的绝世高手是很少的；

4.将敌人由暗转明，只要发现敌人露出破绽，绝不恋战，立即封堵ip，歼灭敌人有生力量；

5.攻击者都是有成本的，也都是检软柿子捏，打不过一定不会投入巨大的时间和人力成本，一定会换目标攻击。

以上的假设也适应于真实的黑客攻击，尤其是勒索类、病毒木马类，这类攻击往往是广撒网，弱者上钩，因为他们不在乎攻击的是啥行业啥客户，最终的目标是经济利益。

基于这样的考虑，我们要作出详细的战术规划动作：

1.知己知彼，谁是我们的朋友，谁是我们的敌人，是HW的首要问题，朋友当然指的就是安全设备、安全体系和安全人员，包括监控、分析研判、应急等，谁是我们的敌人，就是指我们要第一时间识别攻击者并作出响应。这个方面还要加一条，就是谁是我们要保护的目标，如果我们连自己的资产都不清楚，就谈不上保护，所以资产摸底，互联网暴露面收窄，一定是我们要做的第一要务；互联网暴露面大，战线拉得过长，仗就不好打，这个道理都懂。

2.避敌锋芒、绝不恋战，防守方往往要分兵四处防守，而攻击方只需攻其一处，所以要在有限的时间和有限的空间内反击，该封堵ip绝不手软，该下线系统绝不含糊。

3.诱敌深入、攻其薄弱，让攻方露出破绽，立马出局。攻方不按套路出牌，防守方也不能够规规矩矩作战，蜜罐使用的好就是一个非常好用的场景（封IP甚至溯源）；能够御敌于国门之外最好（决战于境外），但大多数场景阵地战是打不过的，边界失守时有发生，这时候就靠纵深防御体系来拉锯战了。

4.稳扎稳打，有效联动，快速响应，让自己的各种安全设备发挥出最大效能，敌我双方都有漏洞的情况下，就比谁的的响应快谁响应快谁就赢。攻方发现漏洞之后，他们利用漏洞打通一个通往内网的道路也需要时间，而且即使通向了内网进行游弋渗透，也一定会有露出破绽的时候，所以就需要比响应，这个时候就要看安全监控和值守来发挥作用。

上面说的可能还是比较虚，下面就详细描述一些防御细节，首先当然是HW设备套餐，哪些是最基本的，然后将设备策略优化，发挥到极致，极致的关键就是封IP，而且是自动化的封堵，最后就是通过监控类策略，人工介入来弥补防御类设备的不足等等。

在HW前，各种安全公司都会推销花样很多的HW套餐，如果不差钱的主当然是多多益善，但是相当多的企业估计也没那么土豪，所以从自身条件出发选择一个合适的HW套餐，必须的套餐包括：防火墙+WAF+蜜罐+威胁监测系统（流量分析回溯或态势感知类）+安全值守（一个人的信息安全部也得至少7*9小时值班），这个我认为是所有企业必须上的；那么豪华套餐，就包括防火墙+WAF+蜜罐+威胁监测系统（流量分析回溯或态势感知类）+威胁情报+ 主机HIDS +安全服务（渗透测试、安全监控组、分析组、处置组、报告总结组）等。各个企业可以根据自己情况，有针对性的上一些设备，这些设备和服务，不只是为了HW临阵磨枪，而是真的是要常态化运营。

虽然有了这些设备，还是万里长征走完第一步，很多企业啥设备都上，用简单的产品堆叠，最终效果不好，影响了老板对信息安全的看法，会认为信息安全团队能力不行，所以有了设备，还需要响应的策略、配置和服务进行运营好。

对安全设备的策略优化，是一个很细且长期的过程，一般安全设备商，他们的kpi是卖设备，让设备去上线验收，而甲方的kpi是要防止信息安全事件的发生，所以这就是一个矛盾，除非特别有钱的甲方，常驻一个安全团队来进行运营，一般很多公司，都是靠甲方自己去做安全策略的优化，下面我们分这几个维度来分享一下几个经验技巧：

1.拦截事件分类

2.防火墙拦截策略

3.Waf拦截策略

4.流量监控类策略

拦截事件分类这块，我们一定要有这么三类：**阻止会话、阻止会话并短暂封堵IP、阻止会话并长期封堵IP；**防火墙是边界全部防护，waf则是针对具体每个站点来设置策略，为了误报，设备上线时候，乙方都推荐不会用封堵类策略，但是在实战场景是一定要有封堵类的策略的，因为在HW中，红方高手很多，而且可能有很多我们不知道的神兵利器，我们的设备有可能能够防住他一招两式，但是没法保证说对方所有绝招能够拦截，所以我们在策略上也要进行封堵，发现敌人破绽就封堵ip立马让其下线，敌人要继续攻击就得换个ip来，这样抬高了攻击成本。

一定要自动封ip，自动封ip，自动封ip，能永久封就永久封，重要的事情说三遍。

那么问题来了，如何封堵ip并不产生误报了？封堵ip如果是靠人工一个一个判断再操作也是不可取的，所以一定要进行策略优化，自动进行封堵操作。我们通过优化，每天自动化封堵1000个ip左右（永久封堵），而且基本上无误报，如何自动化封堵，我们将下一个文章详细介绍。

首先在防火墙上，对来自于互联网的以下端口拦截并永久封堵（或长期封堵ip）的策略。

|
端口

|

策略

|

封堵

|
| — | — | — |
|

445

|

拦截

|

永久封堵

|
|

3389

|

拦截

|

永久封堵

|
|

1433

|

拦截

|

永久封堵

|
|

6379

|

拦截

|

永久封堵

|
|

2181

|

拦截

|

永久封堵

|
|

11211

|

拦截

|

永久封堵

|
|

27017

|

拦截

|

永久封堵

|
|

50070

|

拦截

|

永久封堵

|
|

11211

|

拦截

|

永久封堵

|
|

5900

|

拦截

|

永久封堵

|

以上为高危端口包括远程桌面、VNC、常见数据库服务等端口，以上是攻方必攻之地，对于这样的端口，一定要封而且要封堵来源IP。

对于数据中心外联互联网，一定要采取限制策略，禁止外联互联网，对于很多企业来说，由于历史原因，可能直接放通了互联网的对外访问，那么就要仔细梳理，哪些是必要的访问，要采用白名单方式。

服务器外访，有个攻方常用的攻击方式，就是dns回显式注入，那么就将dnslog.cn等域名加入拦截和监控。

WAF在使用中最大的问题也就是误报与漏报,同时，waf绕过是红方必然要求的一个技能，所以在实战中，waf是必然会被绕过，但是不代表waf策略就不需要优化，那么waf策略优化可以有这么几点：

红方在踩点过程中，必然要用扫描器，连接高危端口的扫描器方式在上面的防火墙策略已经拦截，那么就开始用web应用扫描器，常见的扫描器user-agent如下，策略都是永久封堵。

类似如上user-agent包含上述关键字的，都将拦截并封堵源ip，在这些user-agent中，有一个非常重要的user-agent为python，这个对于很多扫描甚至是poc都是用python开发，所以封堵这个很有必要。当然这个也存在误报，那么就是在软件开发过程中，也可能有测试人员模拟测试场景，那么就要进行区分。

很多高危漏洞一出来，针对该漏洞的poc扫描就非常多，针对这些poc的扫描攻击，可以建立一个url列表来拦截，waf本身策略更新也有这方面的配置，可以拦截，但是由于waf策略本身是需要有通用性，他会将策略做的更严格，我们自定义策略可以更宽松，比如前段时间F5的远程代码执行漏洞爆发 (CVE-2020-5902) ，那么我们已经确定没有使用F5，或者F5不会暴露在公网，那么我们可以将url关键字如下进行拦截，发现即封堵。

/tmui/login.jsp/…;/tmui/locallb/workspace/tmshCmd.jsp

常见的poc攻击url特征清单如下，以下基本上发现为攻方必然扫描的url，当然有一些需要根据企业情况分析，比如我们企业没有使用php作为开发语言，那么大量php的漏洞可以直接拦截并封堵：

/phpmyadmin

/wls-wsat/CoordinatorPortType

/_async/AsyncResponseService

/_async/AsyncResponseServiceSoap12

uddiexplorer/SearchPublicRegistries.jsp

/_async/

bea_wls_deployment_internal

NCFindWeb?service=IPrealertConfigService&filename

action=nc.ui.iufo.release.InfoReleaseAction&method=createBBSRelease&TreeSelectedID=&TableSelectedID=

/uapws/service

.svn/format

WEB-INF/web.xml

/cgi-bin/libagent.cgi

/config.php

fckeditor/editor/filemanager/connectors

/FCKeditor/editor/filemanager/connectors/asp/connector.asp

/FCKeditor/editor/filemanager/browser/default/browser.html

fckeditor/editor/filemanager/connectors/test.html

/secure/ContactAdministrators!default.jspa

/phpinfo.php

/ispirit/interface/gateway.php

/weaver/bsh.servlet.BshServlet

/console/

/wls-wsat

/solr/admin/cores?wt=json

/install.txt

/install.php

/plugins/weathermap/editor.php

/?q=node&destination=node

/hedwig.cgi

/device.rsp?cmd=list&opt=user

/node/?_format=hal_json

/_users/org.couchdb

/mailsms/s?dumpConfig=%2F&func=ADMIN%3AappState

mailsms/s?func=ADMIN:appState&dumpConfig=/

/plus/download.php

/druid/index.html

org.apache.dubbo

/tmui/login.jsp/…;/tmui/locallb/workspace/tmshCmd.jsp

这些url代表啥含义就不再描述了，基本上踩点扫描中，如上的地址都是跑不掉的。

还有一类poc，是通过http请求中包含恶意代码来执行的，比如struts2漏洞，比如fastjson漏洞，所以也需要对类似特征值进行防范,比如我们用部分包含特征样例如下：

part=“com.sun.xml.internal.ws.encoding.xml.XMLMessage$XmlDataSource”,part=“java.lang.ProcessBuilder”,part=“command”

part=“getRuntime”,part=“exec”,part=“java.lang.Runtime”

part=“type=java.net.InetSocketAddress”

part=“dataSourceName=rmi”

part=“#ognlUtil=#container.getInstance(@com.opensymphony.xwork2”

part=“.OgnlContext”,part=“DEFAULT_MEMBER_ACCESS”

3.2.4信息泄露类的扫描

对于部分扫描，在很多waf产品策略中，可能将其列为低危，或者仅仅拦截而不封堵。

那么我们应该自定义一些信息泄露的url，直接拦截并封堵，样例如下：

/configuration/config.php

/.bash_history

/.git/config

/.htpasswd

/admin.rar

/admin.sql

/backup.gz

/backup.rar

/backup.sh

/backup.sql

/backup.zip

/database.rar

/database.sql

/wwwroot.rar

以上策略都是拦截并封堵ip，这个在我们实战中很有效，基本上能够封堵大部分的扫描，如果能够将扫描拦截住，那么就将大部分的低层次的攻击给拦截了。

上面也说到了流量监控设备如流量分析回溯、态势感知、威胁检测系统，基本上还是一个必需品，这些产品主要是流量镜像方式，那么他们自带了一些特征库，可以监测到经过了安全设备之后还遗存的攻击，所以上面的所有特征库，依然适用于流量监控设备，当流量监控设备上设置了如上告警特征，依然还存在，那么就要反过来查查防火墙和waf的配置，是不是策略没配置对，还是说站点没配置全等等。

Webshell监控是一个很难的事情，尤其是冰蝎等这类加密而且快速升级，在流量层面监控的确比较复杂且容易误报，而且当到了webshell这个层面，说明敌人已经深入腹地，那么只有主机安全和流量监控系统是最后一道防线。

常见webshell上传中特征值如下，可以在流量监控中进行告警。

<%execute request("

<%execute(request("

<%ExecuteGlobal request("

%><%Eval(Request(chr(

<%if(request.getParameter("

=@eval(base64_decode($_POST

class U extends ClassLoader{U(ClassLoader c

System.Text.Encoding.GetEncoding(936).GetString

com.sun.rowset.JdbcRowSetImpl

getClass().forName(“java.lang.Runtime”).getRuntime().exec

(#dm=@ognl.OgnlContext@DEFAULT_MEMBER_ACCESS).(#_me

当我们的流量中出现如上特征的时候，那么就要小心可能就真的有webshell上传在尝试。

其实流量监控和防火墙、waf要形成有益补充，防火墙和waf策略优化的好，那么流量监控设备中，告警数量是非常少的，这样也方便安全监控人员进行值守，否则，一天几千条几万条告警，是没办法从中找到真实的蛛丝马迹的。通过流量监控系统反过来优化防火墙、waf策略，也是一个长期要做的事情。每当流量监控出现一个告警，而且告警来自于边界的话，我们就要问问，这个告警真实吗？为何边界设备未能拦截？如何优化？等等。

推荐使用日志收集系统来实现防火墙、waf、蜜罐等统一的日志收集和分析，并将攻击ip进行统一呈现，我们已经使用了graylog来做这个事情，详细可见我的另外一个文章《利用graylog收集各类安全设备日志实现大屏展示》，同时将攻击ip统一呈现还有一个好处，可以实现自动化的永久封堵，我们是通过脚本将攻击ip入库，然后脚本调用防火墙api，每5分钟实施黑名单永久封堵。

这样的好处是显而易见的，攻击者在没有摸清你的家底之前，只有通过不断的探测来摸底，但是探测过程中被你不断的封堵ip，那么他就知道碰到行家了，按照攻击队找软柿子捏的惯例，他们是不会再一个价值不高的目标花费太大的时间和精力，这个对于勒索、黑产团队也同样适用，黑产团队也是广撒网的方式来攻击，比如攻击是有成本的，只有当安全达到一定基线，那么就能够减少很多不应该的信息安全事件。

如上事情优化完成之后，就进入了安全监控、分析阶段，这个时候需要专家值守，通过全量日志分析系统，提升安全分析效率，输入第三方HW情报、自己的HW发现的问题，及时共享，联动处置。

如上为蓝方HW期间经验总结，其实不只是HW期间，作为常态化安全运营，均需要上述的一些基本优化动作，做完上述动作，基本上HW可以达到70%的不出事情，剩下的30%，一个是对手太强大，0day层出不穷，另外就是我们的应用开发，包括弱口令、运维漏洞、钓鱼邮件等依然存在，有时候我们做了大量工作，一个弱口令，让我们所有做的工作都归零。这些漏洞的解决，也不是一朝一夕，也是需要长期的过程。