注:本文为“小米安全中心”原创,作者: 蓝色di雪球 ,转载请联系“小米安全中心”
指纹识别是扫描器的雷达卫星,能在真正需要的时候准确命中目标,指纹识别不仅仅包括Web服务器,还包括设备资产的指纹,一个IP对应的是一台服务器还是一台个人机还是一台打印机?这意味着安全域是不同的,攻下他需要的武器更是不一样。
Web框架指纹扫描在大型甲方公司其实需求并不是非常迫切,成型的框架比如WordPress,Drupal,Joomla!,Discuz! 等使用并不多,多是官方论坛,某个部门的对外Blog之类,多数是进行了二次开发,这里以WordPress举例指纹扫描:
其实我们更加关心的是开发框架,比如Status2,Laravel,自研开发框架等,由于使用面广,业务线分布密集,出现安全事故的话会导致非常严重的后果,所以会采用Whatweb服务集群或者自研的方式进行扫描,并且该类型指纹只有在网站进行大规模的重构上线的时候会有变化,其他时间不会有频繁的变动,所以在非漏洞爆发阶段,这类指纹扫描间隔可以非常大,不会对服务器造成额外的压力。
大型互联网公司的网络边界越来越模糊,很多服务器存在多种漏洞,并且无限制的连接IDC/办公网,一旦被攻破就是个绝佳的跳板。这种情况越是大公司越是明显,安全的木桶效应。
IP相关信息运维部门会比较了解,部门间进行合作可以拿到全IP对应的相关信息,但是,依然不能保证这份IP就是全IP,这就要从流量镜像入手了,从流量中发现未在IP库中的机器,只要有网络请求,就不愁发现不了。进而扩充安全资产IP库,但是实施的时候会发现由于网络划分的问题其实也并不能全部发现IP。
IP资产信息包括OS,设备信息,端口,服务,这能让你知道这个IP背后到底是交换机还是打印机,上面都跑了什么服务,这些服务的版本(如果有),对应存在的漏洞就能直接进行扫描,可以在漏洞发现的第一时间进行全资产扫描,精准的发现存在漏洞的资产范围,所属部门,并且可以非常快的进行漏洞修复流程。
每一次的漏洞爆发都是和攻击者的一次赛跑,也许,攻击者手中也有一份类似的指纹库。
架构上主要使用Nmap集群服务,Nmap的CPE数据持续更新,要保证我们的设备可以被正确的识别。
由于设备上的服务可能会不断的新增/变更,不能保证每一次的新增/变更都是安全的,所以采用轮询的扫描机制,持续更新IP资产库,尽性能的可能,保证这份IP资产库保持最新。
讲个由此发生的成功入侵的故事:某公司给员工提供了开发机,原本这类开发机的默认安全规则是不对外网开放的,但是这台开发机上个使用者申请开了外网权限,回收的时候出现BUG,并没有取消外网权限,然而新的使用者对此并不知情。
新的开发同学使用了Redis数据库,开放了外连,并且没有密码。被攻击者扫描到以后获取了服务器权限,偏偏服务器上有开发中的代码(这是必然会有的),审计发现了线上服务器的安全漏洞,并得到了其他内网服务的用户名密码,这里面包括了内网用户密码、数据库用户名密码。结果造成了非常严重的安全事件。
由此可见,员工的安全意识完全不可以信任,依然要使用技术手段进行安全管理与识别。
前面说了很多的资产库的问题,引出了甲方安全最头痛的事:资产管理。各位SRC的同学应该深深的明白优秀的资产管理到底有多重要,漏洞审计完了,找不到接口人,有的甚至各个部门都不认,安全工单发不出,愁死人。
资格管理分为:
数据资产可以通过DNS,流量,爬虫,配置管理等部门获取,这个可以比较主动的通过技术的方法拿。
而设备资产除了找相关部门获取以外,技术方面只能通过流量和扫描的方式进行获取,然而比较麻烦的是,由于网络的原因,有可能某些机器的流量是不通过你的交换机或者无法网络不可达,所以技术方式并不能发现所有的设备,导致数据缺失。
业务部门是安全的第一责任人,在安全部门输出安全能力的情况下,可以推动业务部门来推动资产管理和其他安全事项。这样多管齐下,尽可能的完善安全的资产管理体系,方法和思路很多,在此不再赘述。
当然,资产管理不可能做到面面俱到,每台服务器,每个业务100%都能准确的找到负责人,所以这种情况下安全风险必须知会到合适的层级,并得到相应合理的对待。
从各个数据源传输过来的数据要经过一系列的处理,才能最后进入我们的资产库,供各项扫描器调用。
首先URL数据是最为庞大的,未经去重的URL数据(GET请求和部分POST请求)数据,量级极为恐怖,如果不经过处理直接入库,会对后端扫描器和业务方造成极大的压力,所以URL入库前的处理,是扫描器开发的一个难点。
主要思路是数据清洗后再进行相应的预处理,这是大数据处理的基础办法:
(1)URL清洗,首先将完全不需要URL数据进行清洗,包括图片,友好404页面等
(2)URL规范化(注1)
(3)URL全量去重,目前两种简单的实现方法,Redis Hash 或者采用布隆过滤器(注2)
(4)URL分类:分为接口URL类和路径重写类
生成规则为:http://list.mi.com/[0-9]+
对其后所有http://list.mi.com/ 路径深度为2的URL进行正则匹配,成功则认为重复,不成功则认为不重复,进入数据库,并生成新的匹配规则。
URL的完全去重在技术上非常复杂和困难,完全没必要用百度或者谷歌的爬虫策略要求自己,只要在可接受范围内,就算是只进行全量去重也没关系。
注:
1:https://en.wikipedia.org/wiki/URL_normalization
2:https://zh.wikipedia.org/wiki/%E5%B8%83%E9%9A%86%E8%BF%87%E6%BB%A4%E5%99%A8
往期回顾:
文中讲了一个成功入侵的安全事件,如果你是甲方安全负责人,凌晨发现此次事件的入侵报警(核心数据库防脱报警,已经自动阻断,并不会造成数据丢失),你要如何去进行安全应急处理?
本题,可从任意角度进行回答。
参与方式:点击下方“写留言”,回答上面的问题
参与时间:截止至10月16日18:00
【注:本文为“小米安全中心”原创 作者:蓝色di雪球 安全脉搏整理发布】
本文作者:小米SRC
本文为安全脉搏专栏作者发布,转载请注明:https://www.secpulse.com/archives/52464.html