中国IDC圈1月12日,2015年1月7-9日,第九届中国IDC产业年度大典(IDCC2014)(http://www.idcquan.com/Special/idcc2014/live/)在北京国家会议中心隆重举行。本次大会由工信部通信发展司、中国信息通信研究院(工信部电信研究院)、云计算发展与政策论坛、数据中心联盟指导,中国IDC产业年度大典组委会主办,中国IDC圈承办,作为国内IDC行业规模大、具权威性和影响力的盛会,此次大会再创辉煌,三天的会议参会人数超过8000人次。

从1月7日到9日连续三天,工信部相关领导、IDC企业、电信运营商、互联网企业、设备厂商等各行业精英齐聚一堂,以"大变革 新生态"为主题煮酒论道。其中京东网银在线架构师刘斐然应邀出席本次大会并发表了"入侵检测系统搭建与优化"的演讲。

22

京东网银在线架构师刘斐然

以下为刘斐然演讲实录:

刘斐然:各位下午好,我先做个自我介绍,我是刘斐然,最早在人人,后来去过P2P或者是众筹的互联网金融公司,现在是在网银在线。一直以来我的工作都是在安全方面的技术工作,一直工作在第一线。今天由我来为大家分享一些入侵检测系统,是比较实在的东西,可能这个涉及一些技术的点。

首先说一下我们的目标,首先要检测Web应用安全事件,这是最基本的事件。第二是检测用户异常操作,比如类似于EDI被登录,第三HTTP的日志存储,这个需求很简单,我们查到异常的IP,但是我们想知道这个IP之后做了什么,所以在这个系统中查询,而且需要提供实时查询的功能。第四对用户敏感操作做提取、存储、查询的功能,比如说登录、修改绑定的手机这些操作。做这个的目的,我们查到一个IP去扫号,查到来的登录的请求,比如说以前试过哪些帐号?哪些帐号失败了?哪些帐号成功了?接下来就是预警,这是最基本的功能,还有会话阻断,这是非常重要的功能,是我们安全的防止事态扩大的手段,比如说我们发现线上业务有漏洞,这个时候我们通过业务去改,在业务改完上线的阶段之间,有可能造成很大的影响,我们有了会话阻断的手段会立刻把涉及到危险的业务直接阻断掉,直到业务修改成功把这个功能再关掉,这样不但给业务提供了修改的时间,而且也保证了我们线上服务的安全,还有最后一点是从部署成本来说,需要成本少。尽可能的少的涉及到我们安全设备,就是我们线上服务器的改动。另外扩展性强,我们流量增加了一倍或者十倍要通过增加机器或者是扩带宽就能达到系统分析的需求。

有了那么几个要求,这是我们系统网络架构图,很简单,首先是业内比较普遍采用的方法,这个蓝色是线上正常的服务器。我们通过从核心交换设备,把流量到我们检测中心进行安全检测,这是主题部分。下面是可选部分,在每台应用服务器,做HIDS的分析。可以看到,因为设计成这样,如果仅搭建好这一部分,我们主题部分已经搭建好了,最主要的功能已经完善了,所以说改动的非常少,我们只需要把网络交换设备或者网络设备镜像到我们整个集群中,可以做整个安全工作。这是系统逻辑结构图。

首先流量镜像,大体上分四个模块,信息收集与提取,信息分析,商业步骤汲取的信息做一个安全分析,输出是做一数据存储,另外我们做的一个安全响应,中间有分布式消息队列,进行把各个部分组件联起来,接下来我会详细介绍这四个部分。

首先信息收集与提取,第一个比较主要是流量解析,现在很多涉及到HTTP加密,如果一个系统检测不了入侵检测系统会很失败,我们之前也尝试过用软件的方式实现,但是实现起来效率很低,可能完全不满足线上业务的需求,所以我们用的是硬件的实现方案。第二个是镜像流量重组,我们从流量中从底层到应用层把我们需要的信息组出来,组出来的信息,这是包括IP端口或者里面的一些方法,URL、UA、服务应答状态和时间,我们组出来的是非常全的日志。这是从应用服务器上取得的,因为这里面有很多信息应用服务器上是提取不到的,比如说UA,这个在安全分析中这些信息是非常重要的。最后一点是将重组后的HTTP日志打入消息队列,为下一步做安全分析。

信息分析,主要是两部分。一部分是普通的流量,就是我们没有处理的流浪,直接应用到安全事件检测Surieata,这是大家在工作中也用到的,能够检测XSS一系列的文件包含或者是文件包,服务端的漏洞攻击事态。我们还原HTTP日志,实时分析集群STORM.其实是对Suricata的一个补充,做应用层的分析是Suricata做不到的,比如说频率检测,是不是有异常的IP访问你的关键业务,关键字检测,这就是对Suricata的补充,是不是有一些渗透,之前没有检测到,还有平行权限检测、后门检测,一旦发现一个攻击,分析出攻击的行为特征,还有关键字可以直接配置检测的漏洞。最后做用户异常行为分析,这个稍候会讲到怎么做,有些信息在白名单里头提到的,有些信息在黑名单里。

重点说一下异常行为分析部分。这个部分有点复杂,尽量少的和业务交互,因为如果哪个业务做的交互多可能以后改版很困难,我们提炼出这么几个基本功能。通过Cookie确定具体用户,第二通过访问的URL量确定具体业务,第三通过参数确定具体行为,第四分析服务器应答,最后数据库存储。对于这些都是通过业务提供的接口去做的,通过这些我们可以检测恶意攻击、作弊、钓鱼、业务逻辑漏洞,扫号、盗号。这是在传统Suricata当中检测不到的。

说完检测说一下数据存储,我们把数据分为四种数据,有三种存储方式。首先普通流量,是全流量记录的方式PCAP包存到Hadoop或者分布式文件系统中,当然这个肯定是短期的,流量太大了不可能存长期的数据。还原HTTP日志分布式全文检索,因为ES本身是分布式的,而且只要输入关键字可以很快的把关键字符合的日志全部检测出来,这是中长期存储。下一步关键操作和报警信息,这个信息相对于上面还是很少的,我们直接存到数据库Mysql里面。最后对于关键操作和报警信息会全部存储,不强调存储的流通。这是ES的界面,因为直接提供前端,所以直接有图表,省得我们再去做二次开发,图表很全。包括统计一些流量、省份的分布,返回的对应情况,访问运营的饼图。下面是实时刷新的访问的情况。

说一下响应,分三步,一个是预警,预警是邮件预警、短信预警;黑名单这是给业务做的,比如我们会提供维护IP黑名单或者异常用户名单这么一个库、通知业务部门做一个参考;另外还有阻断功能,旁路阻断,这是直接用Serfat功能。刚才提到了只是一个基本的平行检测的架构,但是实际上搭建完之后可能这个系统的性能或者是各方面检测的体系内容都是不太理想,该怎么优化?这里面四个部分提了四组优化方法。首先信息收集与提取部分,捕包效率,如果用系统自带的捕包只能做到千兆,可能千兆还不全,那么万兆更别提了,所以我们优化是原先比较常用的,我们用业内常用的PRM,目前没有买他的许可,因为目前我们用PI直接做到捕包效率完全是够用的。

第二信息分析,Suricata检测准确度;数据存储存储与检索效率,对数据库优化数据效率,另外响应Suricata旁路阻断我们做了一个优化,之前默认强制设备双向阻断。如果一个恶意用户访问一个已经标明的,之前是直接给员工发IC包,我们感觉还是双向的,是既给用户也给服务器发一些包。

接下来主要讲Suricata检测准确度优化,这个优化一直想该怎么做?现在有一套实施起来比较简单的方案跟大家分享一下。首先说一下使用中的问题,导致两个,首先第一个无法智能判断服务器是否存在漏洞,这是最关键的问题;第二大量的安全预警,安全人员无法处理。一般一天报几万个报警是正常的,而且报警有人拿扫描扫你或者是想去渗透你,你要做这条规则不能下掉。第二个很难通过人工去确认。因为Suricata和Smolband只记攻击的,不会对服务器厂商做分析,你要人工去做分析你只能重放,重放一个没问题,你要重放一千个,而且要对服务器应答进行判断,你可能很头疼。这个其实在我使用过程中也亲身经历过,我收到报警,我就想是不是有这个服务,但是是使用场景不一样,这个用户自己的产品够用他可以会触发这个东西,因为业务逻辑很复杂,你用你的身份登录可能处罚不了这个。

接下来说一下我们怎么做的,一直想优化这个,能达到什么程度?可能有两点。第一个最简单的你来渗透我,你来测试我。第二点一旦当你渗透成功,当你验证服务器有漏洞我和你是同时发现的,我觉得这是检测最终的一个版本。之前考虑了好多方法,比如改Suricata的原码,或者在Suricata上做研究,但是后来发现这部分内容技术含量很高,而且成本也很高,而且Suricata是不断发展。现在是2.0.5,可能过段时间是2.1.几的版本。但是如果你停留在一个版本上不开发是不行的,而且你一个版本一个版本开发是非常耗费精力的工作,所以现在做了一层包装,把它的报警重新判断一下,有一个UVE,首先读出报警,它的格式量,包括几个关键字段。我们首先可以通过这三个做广义的开发,比如你不接受危害度,危害度1是高的,你不接受2或者以下的危害度你可以做一个这个问题,接下来是不是报警?或者非运营产品有没有Web Server?当然还有一些其他的规则,是不是Web server你可以做基本的。这是第一步,第二步排查好之后我们要利用PCAP文件中,刚才报警中还原整个HTTP,包括整个原件,服务器洞察哪些东西,其实一般如果用开源的或者商业扫描器扫描一下一次链接有二十多个请求,这只是举了第一个请求。可以看到请求了Log.txt.然后有了AWS,传统的报警到这儿就没了,这个人访问了一下,安全人员不知道到底你服务器上有没有这个软件,接下来你看这里可以放心了,直接跳转,说明报了个错就没有这个文件。

接下来我们有了整个HTTP交互流量以后,比如说攻击者测试过,而且服务器应答过,接下来用同样的方法去测,服务器返回同样的应答,这个不会再报警。做法是从HTTP会话中去除IP信息,这些有特定含义的指标,接下来是检查此哈希的数量及时间。最后有一个危险度判定,通过刚才去除和会话判断到底这次渗透概率是多少,我们可以根据返回码,比如说有一次他尝试后台的操作,如果返回码是404或者是一些其他错误那说明没有这个漏洞,如果返回200或者301说明有服务器后台暴露。所以对于这种通过访问码可以确定服务器到底有没有漏洞?另外具体应答内容是否包含特定关键字,你要整理,你的服务器应答里包含哪些字段?证明有用的概率是多少?这里比较复杂一些。然后阈值,概率达到多少以后报警。

这是通过系统优化后的设定,首先邮件预警,是一个攻击视图,这儿有很多,24个请求,有很多尝试。首先这是403,服务器返回的403、服务器返回564,这是一个Post请求。这是他的请求,包括所有的内容。其实一般传统的IDC提供商可能去试一下,但是实际上报警还有后面部分,服务器应答。403直接返回,这是服务器应答的内容,所以可以直接忽略掉这个报警了。其实优化部分重要的讲的是这一点,接下来看一下HIDS,很多大的公司因为入侵检测做不到精准分析,所以他们最后一道防线是HIDS,是最重要的。

首先文件系统监控,这是Linux的监控,包括你改了什么?另外这个文件是不是一个后门,是不是一个原码,在这里做一个文件系统访问。另外进程监控,检测建立进程的用户是否合法,监控进程创建,一旦发现这种行为肯定有入侵发生。检测父进程是否合理,下面是敏感进程,服务器一系列的操作。第三个关键行为监控,这是我们通过日志分析方法做的,ssh等服务的登录登出。第四机器性能监控,通过流量异常监控出来的。这些异常我们可以把它报警直接恢复到之前的那套东西,比如说我发现一个用户有一个上传的请求,在我服务器端出现了问题,这可能是传输端出了问题,谢谢大家。

关注中国IDC圈官方微信:idc-quan 我们将定期推送IDC产业最新资讯

查看心情排行你看到此篇文章的感受是:


  • 支持

  • 高兴

  • 震惊

  • 愤怒

  • 无聊

  • 无奈

  • 谎言

  • 枪稿

  • 不解

  • 标题党
2019-10-15 14:30:39
市场情报 异常行为持续监控分析:发现未知威胁策略
据说,在17世纪之前,欧洲人认为天鹅都是白色的。但随着人们在澳大利亚看到第一只黑天鹅的出现,这个不可动摇的信念随之崩塌了。 <详情>