某地产公司信息安全主任
资深安全专家
HW行动,攻击方的专业性越来越高,ATT&CK攻击手段覆盖率也越来越高,这对于防守方提出了更高的要求,HW行动对甲方是一个双刃剑,既极大地推动了公司的信息安全重视度和投入力量,但同时对甲方人员的素质要求有了很大提升,被攻破,轻则批评通报,重则岗位不保;大的金融、央企可能不担心,有很强的防护,很全面的安全值守;但是相当多的二级单位或者中型公司,可能没那么专业,然后听从乙方来忽悠,上一堆设备,上大屏展示,图很酷炫,数字很夸张,每天防守几万次攻击,不是说这些没用,而是首先要立足于将产品和服务用好,比如资产梳理,比如防火墙,waf策略优化,这个应该是甲方最基础的事情,也不应该全部交给乙方,有的单位被忽悠上了态势感知,但是连基本的waf策略也没有优化,报表表面上很客观,实际的攻击含金量很低;作为参与了2年HW的甲方,总结了一些防御尤其是边界防御的基本要素,简单明了,抛砖引玉,给大家参考。
首先在HW期间(其实平时也需要这样),都是战略上藐视敌人、战术上重视敌人,敌暗我明,敌众我寡,这个现实是摆在眼前的,而且我方是一定存在漏洞的,这个也是必然的,兵来将挡水来土掩的方式不再适用于现代化的网络战,基于这样考虑,我们可以做如下假设:
►我方是一定存在漏洞的,攻方也一定存在破绽,高手对决就看谁先露出破绽;
►一次成功的攻击,背后必定有10次以上的失败攻击;
►拥有0day类的核弹、能够一发制敌的绝世高手是很少的;
►将敌人由暗转明,只要发现敌人露出破绽,绝不恋战,立即封堵ip,歼灭敌人有生力量;
►攻击者都是有成本的,也都是检软柿子捏,打不过一定不会投入巨大的时间和人力成本,一定会换目标攻击。
以上的假设也适应于真实的黑客攻击,尤其是勒索类、病毒木马类,这类攻击往往是广撒网,弱者上钩,因为他们不在乎攻击的是啥行业啥客户,最终的目标是经济利益。
基于这样的考虑,我们要作出详细的战术规划动作:
►知己知彼,谁是我们的朋友,谁是我们的敌人,是HW的首要问题,朋友当然指的就是安全设备、安全体系和安全人员,包括监控、分析研判、应急等,谁是我们的敌人,就是指我们要第一时间识别攻击者并作出响应。这个方面还要加一条,就是谁是我们要保护的目标,如果我们连自己的资产都不清楚,就谈不上保护,所以资产摸底,互联网暴露面收窄,一定是我们要做的第一要务;互联网暴露面大,战线拉得过长,仗就不好打,这个道理都懂。
►避敌锋芒、绝不恋战,防守方往往要分兵四处防守,而攻击方只需攻其一处,所以要在有限的时间和有限的空间内反击,该封堵ip绝不手软,该下线系统绝不含糊。
►诱敌深入、攻其薄弱,让攻方露出破绽,立马出局。攻方不按套路出牌,防守方也不能够规规矩矩作战,蜜罐使用的好就是一个非常好用的场景(封IP甚至溯源);能够御敌于国门之外最好(决战于境外),但大多数场景阵地战是打不过的,边界失守时有发生,这时候就靠纵深防御体系来拉锯战了。
►稳扎稳打,有效联动,快速响应,让自己的各种安全设备发挥出最大效能,敌我双方都有漏洞的情况下,就比谁的的响应快谁响应快谁就赢。攻方发现漏洞之后,他们利用漏洞打通一个通往内网的道路也需要时间,而且即使通向了内网进行游弋渗透,也一定会有露出破绽的时候,所以就需要比响应,这个时候就要看安全监控和值守来发挥作用。
上面说的可能还是比较虚,下面就详细描述一些防御细节,首先当然是HW设备套餐,哪些是最基本的,然后将设备策略优化,发挥到极致,极致的关键就是封IP,而且是自动化的封堵,最后就是通过监控类策略,人工介入来弥补防御类设备的不足等等。
在HW前,各种安全公司都会推销花样很多的HW套餐,如果不差钱的主当然是多多益善,但是相当多的企业估计也没那么土豪,所以从自身条件出发选择一个合适的HW套餐,必须的套餐包括:防火墙+WAF+蜜罐+威胁监测系统(流量分析回溯或态势感知类)+安全值守(一个人的信息安全部也得至少7*9小时值班),这个我认为是所有企业必须上的;那么豪华套餐,就包括防火墙+WAF+蜜罐+威胁监测系统(流量分析回溯或态势感知类)+威胁情报+ 主机HIDS +安全服务(渗透测试、安全监控组、分析组、处置组、报告总结组)等。各个企业可以根据自己情况,有针对性的上一些设备,这些设备和服务,不只是为了HW临阵磨枪,而是真的是要常态化运营。
虽然有了这些设备,还是万里长征走完第一步,很多企业啥设备都上,用简单的产品堆叠,最终效果不好,影响了老板对信息安全的看法,会认为信息安全团队能力不行,所以有了设备,还需要响应的策略、配置和服务进行运营好。
对安全设备的策略优化,是一个很细且长期的过程,一般安全设备商,他们的kpi是卖设备,让设备去上线验收,而甲方的kpi是要防止信息安全事件的发生,所以这就是一个矛盾,除非特别有钱的甲方,常驻一个安全团队来进行运营,一般很多公司,都是靠甲方自己去做安全策略的优化,下面我们分这几个维度来分享一下几个经验技巧:
►拦截事件分类
►防火墙拦截策略
►Waf拦截策略
►流量监控类策略
拦截事件分类这块,我们一定要有这么三类:阻止会话、阻止会话并短暂封堵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关键字如下进行拦截,发现即封堵。
常见的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' |
对于部分扫描,在很多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层出不穷,另外就是我们的应用开发,包括弱口令、运维漏洞、钓鱼邮件等依然存在,有时候我们做了大量工作,一个弱口令,让我们所有做的工作都归零。这些漏洞的解决,也不是一朝一夕,也是需要长期的过程。
联系客服