邬晓磊:基于关键词的大型红蓝对抗经验分享

admin 2021年3月29日14:49:18评论84 views字数 9747阅读32分29秒阅读模式

邬晓磊:基于关键词的大型红蓝对抗经验分享


【活动主题】基于关键词的大型红蓝对抗经验分享

【分享嘉宾】邬晓磊

【嘉宾简介】东方证券系统运行总部信息安全总监,CISSP、CISP、CISA、ISO27001 LA,20年信息安全从业经验。

【活动时间】3月24日本周三晚上19:00-20:00 。


【活动形式】群内分享。嘉宾通过文字形式,在金融业企业安全建设实践群「企业安全建设实践群,就“基于关键词的大型红蓝对抗经验分享”进行同步直播,约40钟,之后是互动问答时间,约20分钟,共计60分钟。


--------------------------------------


以下为实录:


感谢君哥和郭威总的推荐,让我有这个机会和大家分享一些HW中的心得体会。这次分享主要是挑选了一些HW中的关键词,着眼在防守方视角,特别是防守方的准备阶段,内容更多的是管理、流程和一些关键点,不会涉及太深入的技术内容。有理解不到位的地方欢迎大家指正。


之所以选择这些内容,一是群里面技术大佬太多,讲技术的内容是班门弄斧。另外就是流量NTA、蜜罐、HIDS、威胁情报等HW利器,大家应该也听过很多介绍,为了避免审美疲劳,所以今天主要介绍内部准备中的一些侧重点。


另一个原因是作为企业安全从业者,我个人觉得HW对企业的积极意义是能够将其作为一个契机,推动企业安全水平的提升。短期的应试工作虽然也要做,但是还应该乘这个机会推动一下内部安全问题的整改。


我觉得超过半数的防守单位的人员团队,日常的工作重点是安全运维管理,缺乏对抗经验,加上演练对抗覆盖的技术点有太多,因此无法在技术能力上面面俱到。而且一般准备时间不长,因此在技术上弱于攻击队是很正常的事情。


所以,如何以较少的人员在较短的时间内完成对规模庞大的信息资产安全水平的提升,考验的是组织协调能力和重点工作安排的能力。正如郭威总2019年HW之后的分享中有提到,小目标是不出现低级错误,其实2020年我们也是按照这个目标去准备的。


之前有小伙伴在问关键词到底是什么,其实我发出来大家应该就明白了。今天分享的关键词包括:


一、组织

二、资料库

三、弱口令

四、任意门

五、隐秘的角落

六、运维坏习惯

七、社工

八、自动化


以下介绍的问题,都是我们准备过程中真实发现了,可能大家也会遇到。


一、组织


我个人认为顺利完成HW任务,组织架构是第一位的。HW组织有两个要素:


一个是高,就是组长级别要高,一般要达到公司副总裁、IT分管领导的级别,这样才能够比较顺利的协调资源。需要协调的包括组内关键人员、子公司和业务部门、预算和商务等。有了大领导的关注,其他参与部门才有动力配合,准备工作才能够顺利开展。


二是要全,就是组织范围要全,除了要包括执行部门的领导,如IT、行政等等,还要包括被关注部门的领导,特别是子公司和有独立IT建设权的业务部门。因为子公司和业务部门建设的信息系统,通常弱点较多,是攻击队最喜欢利用的点,需要重点关注和整改。


下面这张图是准备阶段的组织架构:


邬晓磊:基于关键词的大型红蓝对抗经验分享


下面这张图实际演习阶段的工作小组架构:


邬晓磊:基于关键词的大型红蓝对抗经验分享


另外,一般会准备两套组织架构,一套是准备阶段的工作小组架构,工作是推进准备和整改工作,同时做好后勤保障的准备工作。一套是正式演习是防守架构,包括监控、研判、处置、对外联络、后勤保障。


二、资料库


完备的资料库是HW准备整改阶段和正式防守阶段都必备的东西。资料库包括这些内容:


1、基础CMDB;

2、高阶CMDB数据;

3、攻击面关系;

4、数据流梳理;

5、第三方IP;


下面分别介绍下:


1、基础CMDB:IP、用途、系统、负责人。这是最基础的资产信息,大部分企业应该都有,要注意可能会有缺失的情况,需要结合扫描结果或资产发现结果进行补全。


2、高阶CMDB数据:基础CMDB-关联-应用、中间件、数据库。基础CMDB已设备为视角,高阶CMDB以应用系统为视角将资产串联起来,对于理解流向和行为的合理性更有帮助。应用层和中间件漏洞也可以更快的关联到项目组,加速整改。


这是我们不断完善中的CMDB信息:


邬晓磊:基于关键词的大型红蓝对抗经验分享

邬晓磊:基于关键词的大型红蓝对抗经验分享


3、数据流梳理:前端转发、中间件、数据库。和第二点类似,有助于理解应用数据流,配合NTA产品可指定行为基线和误报加白。


4、攻击面关系:域名、互联网IP、内部IP、各种PIP。最重要的梳理内容,争取做到每个互联网系统整个资产、数据流、安全策略等都梳理清除。有做反向代理的设备和系统,如CDN、WAF、SLB等,都要将源IP打上X-Forwarded-For标记,对于部署的NTA设备要进行调优,正确识别X-Forwarded-For,有利正确告警和后续的封禁动作。


5、第三方IP:子公司、机构、银行间、证联网等。很多第三方IP都不是常规的保留IP,会被安全设备识别为互联网(比如美国、非洲)IP,进而伴随一些不规范的应用访问产生误报。将整理好的第三方IP导入NTA设备或态势感知平台、日志管理平台,在产生告警时可以区别处理,正确的判断访问事件的来源。


三、弱口令


弱口令是企业中普遍存在的安全问题,也是对抗演习中被利用的比较多弱点。


首先,如何发现弱口令。流量和HIDS都是较好的方式。如果非加密协议,那么流量可以直接发现弱口令用户。但要注意的是NTA产品无法对所有应用的登录成功行为都进行准确判断,可能会出现误报,因此需要一个不断调优的过程。


而HIDS由于是直接读取系统文件,能够直接发现操作系统、包括域控的弱口令用户,准确度较高,但是无法直接发现应用系统的弱口令用户。而且HIDS需要在主机上部署,覆盖面是一个问题。因此,根据企业自身情况,两者结合才能从多角度发现存在的弱口令用户。远程枚举方式不作为推荐,太暴力。


对于弱口令的整改,我们的实践经验是不光要给出规范要求,还要给出示例。很多系统由于本身对口令复杂度的判断较为简单,用户修改时为方便记忆,会出现强口令中的弱口令,也就是符合口令强度要求但又有一定规律的口令,容易被猜测到。反复要求用户修改,又会遭到用户的挑战,影响整改工作推进。如果系统支持第三方认证,最好接入统一的第三方认证,避免维护多套口令体系,顾此失彼。对于VPN、堡垒主机或其他集权系统,尽量采用双因素认证,提高认证门槛。


四、任意门


任意门是哆啦A梦中的道具,是可以去往任何地方的捷径。而在很多系统网络中就存在这样的任意门。


很多集权系统就是任意门,例如堡垒主机。堡垒主机通常有多张网卡,连接多个网络区域,可以访问大量主机,还可能设置了密码代填。如果获得了堡垒主机权限,内网将沦陷一大批资产。因此在准备过程中,应尽量将堡垒主机升级到最新版本。有些厂商提供HW特殊版本,除了修复漏洞外,还对特权账户进行了登录限制,并可能将系统后台的敏感动作通过日志输出。大家可以咨询自己的堡垒主机厂商。


另外如自动化运维系统,虽然不能直接跨安全域访问,但也具备很多特权,而且可以通过级联的方式下发指令,也需要在特殊时期对管理端的访问进行更严格的限制。


第二类任意门是特权主机。有些企业中会因为方便操作的原因,设置一些特权的主机,作用类似堡垒主机,但是是专人使用的,比如网管、安全管理员、DBA等等。这些特权主机需要进行重点加固,有条件的可以部署HIDS做重点监控,并在特殊时期缩小他们的特权。


还有一类特权主机,是因为某些应用或运维用途,部署的多网卡主机,这类主机也需要梳理出来,并采用类似特权主机的要求进行加固和监控。但是多网卡主机的网络权限限制实施起来比较普通的特权主机更难,需要网络部分的同事投入更多的精力配合。


五、隐秘的角落


2020年大火的电视剧的名字。其实在很多企业,包括我们的网络中,都会存在这样隐秘的角落。这些隐秘的角落如果不妥善处理,在HW可能会成为大的隐患。


第一种是被遗忘的设备。可能原先都有计划下线了,但是由于某些原因实际设备并未关闭,网线也连接着,但是就这么被遗忘了。其中风险最大的是被遗忘的防火墙和网络设备。因为这些设备连接着网络,被遗忘后通路仍然存在,但是在HW准备梳理中会被漏过,相当于在网络中存在一个不设防的入口。因此,准备过程中设备的清点一定要到位,下线的设备要确认关机、断电、拔除网线。


第二种是全通策略。当然我相信现在大部分企业都不会故意设置全通策略。但是可能由于曾经的搬迁、设备替换、割接等原因,为了不影响应用,会开通临时的全通策略,位于正常策略后面作为保底。时间长了就会被遗忘,形成另外一种不设防。而且一般由于先入为主的意识,自我检查很难发现这些策略,最好请第三方通过在网络内部进行对抗的方式进行发现,并及时整改。


第三种是平行于业务网络的其他网络层面。如监控网、备份网。这些网络和前面提到的多网卡主机有关。可能业务网络在不同区域的主机会共用一张监控网或者备份网,而一旦某个主机失陷,通过这第二第三网可以轻松的绕过网络访问策略,访问的其他区域的主机,进行进一步跨区域攻击。因此,建议在监控网或备份网增加网络交换机策略,仅允许需要用到的监控或备份端口,或禁用远程管理或访问类的端口。这就是前面所说的,需要网络同事大力配合的工作。


邬晓磊:基于关键词的大型红蓝对抗经验分享


六、运维坏习惯


运维坏习惯有很多,大部分都是为了方便运维工作,但同时会带来安全隐患。比如,服务器当操作机用。不推荐这样使用的原因是,服务器因为部署应用的原因,应用层风险较高,容易被利用。而当作操作机以后,跳转登录会留存大量其他主机的信息,一旦失陷,更容易作为攻击跳板。如有操作机需要,应单独部署,上面不部署应用系统,操作系统加固后,可实现风险最小化。


服务器上保存运维手册和口令,这也是常见的为了方便的坏习惯。但方便自己的同时,也方便的攻击者。如果失陷,攻击者等于获得了一本网络使用说明书。因此,需要请运维团队自查和清理服务器上保存的运维手册和用户名口令等文档。


跳转登录并且不及时关闭。即使是专用操作机,跳转登录其他机器后,用完也要及时关闭,否则也会增加被直接利用的风险。


浏览器记住密码。这和第二点效果类似,但是方式不同。主机失陷后,攻击者可以通过浏览器收藏夹和记住的密码,直接登录各种应用后台或运维管理系统。这一点也需要个运维团队自查。


邮件发送设备清单及口令。这种情况相信也比较常见。运维人员将设备清单和用户名口令,未加密就直接通过邮件发送。如果邮件保存在服务器上没删除,而邮件系统又由于各种漏洞或弱口令被攻破,那么攻击者将又一次拿到一份宝藏手册。因此要对运维人员强调几点,设备清单和口令不用一起发送,发送时文件要进行加密,还需要对邮件系统上还存在的邮件进行排查或自查,发现类似邮件全部删除。


七、社工


社工也是对抗中大量使用的方法。


最常见的社工是邮件钓鱼,简单、高效。我个人体会,对于邮件钓鱼,技术手段都是辅助的,最终觉得钓鱼防范水平的还是人员的意识。因此,定期进行钓鱼邮件测试是提升意识的利器。


钓鱼邮件测试的效果,和测试的拟真度有关。拟真度越高效果越好。当然,拟真度高了会有个副作用,就是可能会被公司员工投诉。比如,我们去年准备期间的钓鱼邮件测试,采用的主题是“关于进行2020年度员工体验的通知”,测试进行之后投诉很多,但是效果非常好,中招的人绝对印象深刻。这时候,就需要有企业高层领导的支持,这也是前面提到的组织要有高层牵头。


邬晓磊:基于关键词的大型红蓝对抗经验分享


除去邮件钓鱼、IM、短信、电话方式的社工也经常用到。比如,去年的内部演练中,我们就有员工被套取了VPN短信认证码,从而被获取了该员工的VPN权限。这些社工手段,很难用技术措施解决,更多的需要靠教育和不断的对抗演练来提升。真实的演练就是最好的教育。


八、自动化 


由于人员和系统规模的不对等,安全自动化是必须的。当然,我们目前实现的自动化还比较简陋,分享一下看看对大家有没有帮助。


一是漏洞修复流程的自动化,主要是将漏洞扫描、漏洞情报、资产库信息等数据打通和关联。在发现漏洞和漏洞通报时,能快速定位或筛选出相关的设备、应用系统、运维负责人、应用负责人,通过自动或半自动的手段发送通知给相关人员,安排进行修复。然后定期进行修复结果的统计反馈。


邬晓磊:基于关键词的大型红蓝对抗经验分享


二是IP封禁的自动化。大家都知道IP封禁在以往的对抗中效果都非常好。但是我们去年的时候还没用类似SOAR的系统。因此,去年在准备期间我们自己开发一套小程序,实现IP自动封禁。简单的架构可以看下图。


邬晓磊:基于关键词的大型红蓝对抗经验分享


开发过程中遇到过几个坑,大家可以参考下。一是不同设备的处理方式不同,新设备基本都有API,实现较容易。老设备不支持API,需要模拟SSH,同时会有执行效率问题。因此最好不同类型的设备分线程单独处理。


涉及到白名单的,分支机构、合作伙伴可以提前让他们提交,避免误封。CDN厂商也需要提供节点IP用于添加白名单。对于CDN,NTA产品要正确识别源IP,避免无效封禁。


要有快速解封机制,能够快速查询是否在封禁名单中,能够快速解封单个IP或批量解封。这对于误封处理非常有帮助。否则业务层面投诉可能会比较多。


移动网络的IP是浮动的,因此移动网络的IP不适合长时间封禁。


好了,以上就是我今天要分享的内容,谢谢大家的参与,欢迎大家多多交流。


---------------------------------------------


问答环节:


Q1:有一个问题,资产管理如何保障全面性呢?与运维的资产管理联通吗?


A:资产管理全面性的问题我们的方法是多维度的去发现,外部服务商,安全团队,网络团队,运维团队的内容拼起来才是完整的,扫描结果和CDMB、网管的IP库交叉比对。


---------------------------------------------


Q2:通篇看下来主要是在网络、运维层面查缺补漏,准备工作较多,特别接地气。其中提到全通策略的梳理,请第三方进行对抗发现,针对这一点那自身需要做哪些准备吗?


A:直接让第三方在网络内靠互联网侧的区域发起攻击,他们会找出弱点的。


---------------------------------------------


Q3:防火墙anyanyany策略用的什么工具梳理?以前碰到过外联单位一年才用一次的业务,导致遗漏。


A:如果有使用防火墙统一策略管理平台话,只要防火墙策略接入,是可以一次性输出结果的。


---------------------------------------------


Q4:我有三个小问题:1、员工的上网办公终端在HW期间安全管控有什么好的实践?2、安全管理会下沉到营业部吗?3、如何技术和管理隔离这部分风险?


A:我们营业部外网和内网是隔离的,员工终端也是通过NTA监控,并且控制DNS解析,对于员工终端的socket通讯专门安排人跟踪分析,确认是否为正常应用。


---------------------------------------------


Q5:邮件客户端没有配置加密协议,导致网络流量检测中发现大量的明文账号密码,有什么好的解决办法吗?办公终端比较多,挨个配置邮件客户端和收件邮件效果不太好。


A:我们是通过邮件网关实现加密协议收发,逐步禁止非加密协议的使用。


---------------------------------------------


Q6:有两个问题:1. 请问如何高效梳理好数据流?主要手段有哪些?2. 如何做到抓取全网东西向和南北向的流量,每秒大几十G。


A:数据流我们是和网络团队一起分析的,正好我们要搬数据中心,所以就顺便做了。但是我们也没有在一个时间接入所有流量,都是按照系统,或按照边界逐步采集分析的。


---------------------------------------------


Q7:请教下,堡垒机是直接访问操作系统和网络设备,还是在堡垒机上配置专用操作机,通过操作机去访问?


A:看需求,对于服务器没有特殊需求我们是建议堡垒主机直连服务器的。


---------------------------------------------


Q8:请教邬总,假如攻击队是从分支机构突破的,1.如何快速定位攻击设备(所属营业部,IP等),总部告警看到的来自分支机构的攻击IP都是总部防火墙nat后的地址,且分支机构办公电脑都是DHCP分配的IP;2.分支机构无线网络采取了哪些安全加固措施?


A;如果有NAT,只能结合防火墙日志,根据时间和访问目的进行排查了。分支DHCP的话可能更头疼一点,需要DHCP日志,但是分支的DHCP日志收集可能是一个问题。HW的时候我们把分支的无线都关了,同时下发通知给营业部,要求保安加强物理管控,墙上不用的口全封掉。补充下,我们分支的无线控制器是在总部的。


---------------------------------------------


Q9:感谢邬总分享,回看了记录,很接地气,看着每个关键词都是很大的工作量,不知邬总这边是投入了多少人力,又是怎么协调的?


A:这些事情肯定不是我们6个人能完成的,主要是领导重视,动员了信息条线的各个团队配合,网络、运维、DBA、应用都配合推进了。


---------------------------------------------


Q10:想请教下邬总,数据流梳理具体是怎么做的,全网东西南北向的流量都抓取分析吗?现在有些业务调用关系复杂,连开发运维人员都讲不清楚到底多少地方调用,出现安全问题很难快速响应。


A:数据流我们原先系统上线的时候就要求项目组都填写了基本情况,后期根据掌握的信息顺藤摸瓜,主要是互联网系统,顺着互联网域名和IP摸进来。


---------------------------------------------


Q11:谢谢分享,刚爬完楼,还想再请教下问题。1、hw的组织架构这块,在实战期间,如果子公司层级多、人数多(就我们而言,需要把产险、寿险子公司的二三四级机构都纳入进来),是统一都在一个业务联络组里,还是每个子公司单独按照您这个架构单独成立一个hw组织(我想知道实际工作中哪个沟通效率更高)?2、cmdb这块,如何让cmdb系统中的信息能更快更准的跟真实线上业务保持一致?3、对于互联网暴漏的敏感信息这块,我感觉很难用用一两次就能发现全部的敏感信息,比如网盘上一搜就有上百页的结果链接有待验证,你们具体的做法还能说下吗?


A:有层级的组织,我们是采用责任逐级下放的方式,子公司对下属企业负责。CMDB不准一是老旧资产,二是上线变更流程不规范。我们网络层面靠扫描发现比对后完善,主机应用层面靠运维或安全的监控软件。


---------------------------------------------


Q12:关于运维坏习惯,除了自查之外,安全这边有什么方式去做检验和复核,因为有些自查可能并不是运维故意不做,而是因为他们挖坑太多,自己都给忘记了,这个有没有一些经验可分享下?


A:这个目前确实没有太好的自动化技术方法,主要靠自查,责任下放。


---------------------------------------------


Q13:感谢邬总分享,想咨询下HIDS在实际使用中,都有什么好的经验或者心得?


A:HIDS主要看诉求,合适的是最好的,我们目前HIDS不追求处置,还是以发现为主,发现应用资产、中间件、组件,发现webshell、异常执行、账户变动等等。


---------------------------------------------


Q14:对于弱口令问题我想大家都有些痛点,但比如测试环境的弱口令、或者普通应用的弱口令,提到给开发或者业务,他们会说又没啥敏感数据,如果每次安全部门都深入的利用其成本也挺高的。这些修复把控邬总那边是怎么做的?


A:测试环境管到了操作系统,应用系统的弱口令还没精力管,但是测试环境严格限制互联网访问,HW时期不允许互联网访问测试环境。


---------------------------------------------


Q15:邬总好,请问下 在对NTA告警研判分析上,主要是关于如何判定一条告警为有效告警(很多都是域名报毒),您有什么经验可以分享吗?


A:有效告警一般是分析payload,对于互联网访问更严格一些,HW期间宁可错杀。对于内部访问,可以分析的仔细些,可以通过响应判断是否为正常应用访问。分析最好让专业研判人员来,分析源IP,经过代理,IP头部会变成代理服务器IP。


---------------------------------------------


Q16:邬总好,感谢分析,请问下 公司邮箱邮件数量巨大,有什么好的方式或手段对以往的邮件进行核查或控制?


A:邮件核查要看哪方面,恶意邮件靠沙箱,敏感内容靠邮件DLP或邮件归档。


---------------------------------------------


Q17:邬总好,hvv网结束后领导一般要求安全部门整理总结报告,咱们会从哪些方面进行向上汇报或管理?


A:汇报的话,基本上会整理HW成绩成果,准备工作、人员和经费投入,对公司网络安全的提升作用等等。


---------------------------------------------


Q18:对于高阶CMDB数据流和攻击面梳理这块历史数据缺失的系统,有好的自动化发现的方案么?


A:高阶CMDB数据流和攻击面梳理,需要运维和网络团队一起配合。目前我们用到的攻击是网络扫描、HIDS、zabbix及其他运维监控系统的信息整合,但也需要大量人工工作。


---------------------------------------------


Q19:如何借助HW来持续提升日常企业安全能力,而不是一阵阶段性运动,借助外部力量和产品提升能力,HW结束后能力减弱。能否给些建议?


A:我觉得提升日常能力,首先需要在准备汇报的时候就给领导这个概念,不是应试工作。而且要将一些工作和责任分派给其他团队,成为大家的目标和任务。


---------------------------------------------


Q20:请问内网终端/服务器打补丁方面有什么建议吗?特别是windows终端和服务器方面?


A:我们目前还是WSUS,终端是自动安装自动重启,WSUS直接从官网同步的,不过Windows10现在的补丁体系也比较麻烦。


---------------------------------------------


Q21:“第二种是全通策略。当然我相信现在大部分企业都不会故意设置全通策略。但是可能由于曾经的搬迁、设备替换、割接等原因,为了不影响应用,会开通临时的全通策略,位于正常策略后面作为保底。时间长了就会被遗忘,形成另外一种不设防。而且一般由于先入为主的意识,自我检查很难发现这些策略,最好请第三方通过在网络内部进行对抗的方式进行发现,并及时整改。”——邬总好,请问如何保证第三方能更全面的发现这些问题?


A:不能完全保证,但是一般有经验的第三方发现的概率还是很大的,比较自己人好,自己人会有思维定式。当然最好是通过防火墙策略管理系统进行梳理。内部组织的对抗,让第三方从网络内靠互联网侧的区域起步。


---------------------------------------------


Q22:请问在WAF,防火墙,IDS等安全设备组成的边界防护前提下,互联网停火区应用操作系统打补丁是否还有意义,或者说优先级是否不高了。


A:个人理解,操作系统补丁肯定不用全打,关键高危的还是要打的。前面说了不犯低级错误。


---------------------------------------------


Q23:感谢分享,请问大家如果监测到攻击源是我们自己的CDN地址,如何确定真实攻击源,如何处置呢?


A:CDN来的请求里,真实源会打标的,提取即可。有些WAF可以对这个真实源进行封禁,也可以调用CDN API进行封禁。


---------------------------------------------


——群内分享往期精彩——


邬晓磊:基于关键词的大型红蓝对抗经验分享

邬晓磊:基于关键词的大型红蓝对抗经验分享

邬晓磊:基于关键词的大型红蓝对抗经验分享

邬晓磊:基于关键词的大型红蓝对抗经验分享

邬晓磊:基于关键词的大型红蓝对抗经验分享


--------------------------------------


邬晓磊:基于关键词的大型红蓝对抗经验分享

本文始发于微信公众号(君哥的体历):邬晓磊:基于关键词的大型红蓝对抗经验分享

  • 左青龙
  • 微信扫一扫
  • weinxin
  • 右白虎
  • 微信扫一扫
  • weinxin
admin
  • 本文由 发表于 2021年3月29日14:49:18
  • 转载请保留本文链接(CN-SEC中文网:感谢原作者辛苦付出):
                   邬晓磊:基于关键词的大型红蓝对抗经验分享http://cn-sec.com/archives/311619.html

发表评论

匿名网友 填写信息