1、Web 日志安全分析浅谈Web 日志安全分析浅谈一、为什么需要对日志进行分析?随着 Web 技术不断发展，Web 被应用得越来越广泛，所谓有价值的地方就有江湖，网站被恶意黑客攻击的频率和网站的价值一般成正比趋势，即使网站价值相对较小，也会面对“脚本小子”的恶意测试攻击或者躺枪于各种大范围漏洞扫描器，正如安全行业的一句话：“世界上只有两种人,一种是知道自己被黑了的,另外一种是被黑了还不知道的”此时对网站的日志分析就显得特别重要，作为网站管理运维等人员如不能实时的了解服务器的安全状况，则必定会成为“被黑了还不知道的”那一类人，从而造成损失，当然还有一个场景是已经因为黑客攻击造成经济损失，此时我们也
2、会进行日志分析等各种应急措施尽量挽回损失，简而言之日志分析最直接明显的两个目的，一为网站安全自检查，了解服务器上正在发生的安全事件，二为应急事件中的分析取证。二、如何进行日志分析?在说如何进行分析之前，我们先来了解一下 Web 服务器中产生的日志是什么样子.我们以 Nginx 容器为例：随机抽取一条日志：61.144.119.65 - - 29/May/2017:22:01:32 +0800 “GET /page/1 HTTP/1.1“ 200 6403 “http:/“ “Scrapy/1.1.2 (+http:/scrapy.org)“作为 Web 开发或者运维人员，可能对图中的日志信息比
3、较熟悉，如果对日志不那么熟悉也没关系，我们可以查看 Nginx 中关于日志格式的配置，查看nginx.conf 配置文件：可以看到日志格式为：remote_addr - remote_user time_local “request“ status body_bytes_sent “http_referer“ http_user_agent“ “$http_x_forwarded_for“;翻译过来即为：远程 IP - 远程用户 服务器时间 请求主体 响应状态 响应体大小 请求来源 客户端信息 客户端代理 IP通过以上信息，我们可以得知服务器会记录来自客户端的每一个请求，其中有大量来自正常用户
4、的请求，当然也包括来自恶意攻击者的请求，那么我们如何区分正常请求和恶意攻击请求呢?站在攻击者的角度，攻击者对网站进行渗透时，其中包含大量的扫描请求和执行恶意操作的请求，而这两者在日志中都有各自的特征，如扫描请求会访问大量不存在的地址，在日志中体现则为大量的响应状态码为404，而不同的恶意请求都有各自相应的特征，如当有人对服务器进行 SQL 注入漏洞探测时：(图中以“select“为关键字进行过滤)聪明的你肯定想到了，如果此时加上时间条件，状态码等条件就能查询到最近可能成功的 SQL 注入攻击了，当然实际情况中，仅仅只依靠状态码来判断攻击是否成功是不可行的，因为很多时候请求的确成功了，但并不能代
5、表攻击也成功了，如请求一个静态页面或者图片，会产生这样一个请求:/logo.png??attack=test;select/1/from/*/1,此时请求状态码为 200，但是此注入攻击并没有得到执行，实际情况中，还会有更多情况导致产生此类的噪声数据。抛开这类情况不谈，我们来说说在一般应急响应场景中我们分析日志的常规办法。在常规应急响应常见中，一般客户会有这几种被黑情况：1.带宽被占满，导致网站响应速度变慢，用户无法正常访问2.造成已知经济损失，客户被恶意转账、对账发现金额无端流失3.网站被篡改或者添加暗链，常见为黑客黑页、博彩链接等对于这些情况，按照经验，我们会先建议对已知被黑的服务器进行断
6、网，然后开始进行日志分析操作。假设我们面对的是一个相对初级的黑客，一般我们直接到服务器检查是否存有明显的 webshell 即可。检查方式也很简单：1.搜索最近一周被创建、更新的脚本文件 2.根据网站所用语言，搜索对应 webshell 文件常见的关键字找到 webshell 后门文件后，通过查看日志中谁访问了 webshell，然后得出攻击者 IP，再通过 IP 提取出攻击者所有请求进行分析如果不出意外，可能我们得到类似这样一个日志结果：(为清晰呈现攻击路径，此日志为人工撰造)eg:00:01 GET http:/localhost/index.php 9.9.9.9 200 正常请求00:
7、02 GET http:/localhost/index.php?id=1 9.9.9.9 500 疑似攻击00:05 GET http:/localhost/index.php?id=1 and 1=user() or = 9.9.9.9 500 确认攻击00:07 GET http:/localhost/index.php?id=1 and 1=(select top 1 name from userinfo) or = 9.9.9.9 500 确认攻击00:09 GET http:/localhost/index.php?id=1 and 1=(select top 1 pass fro
8、m userinfo) or = 9.9.9.9 500 确认攻击00:10 GET http:/localhost/admin/ 9.9.9.9 404 疑似攻击00:12 GET http:/localhost/login.php 9.9.9.9 404 疑似攻击C00:13 GET http:/localhost/admin.php 9.9.9.9 404 疑似攻击00:14 GET http:/localhost/manager/ 9.9.9.9 404 疑似攻击00:15 GET http:/localhost/admin_login.php 9.9.9.9 404 疑似攻击00:1
9、5 GET http:/localhost/guanli/ 9.9.9.9 200 疑似攻击00:18 POST http:/localhost/guanli/ 9.9.9.9 200 疑似攻击00:20 GET http:/localhost/main.php 9.9.9.9 200 疑似攻击00:20 POST http:/localhost/upload.php 9.9.9.9 200 疑似攻击00:23 POST http:/localhost/webshell.php 9.9.9.9 200 确认攻击00:25 POST http:/localhost/webshell.php 9.
10、9.9.9 200 确认攻击00:26 POST http:/localhost/webshell.php 9.9.9.9 200 确认攻击首先我们通过找到后门文件“webshell.php”，得知攻击者 IP 为 9.9.9.9，然后提取了此 IP 所有请求，从这些请求可以清楚看出攻击者从 00:01 访问网站首页，然后使用了单引号对网站进行 SQL 注入探测，然后利用报错注入的方式得到了用户名和密码，随后扫描到了管理后台进入了登录进了网站后台上传了 webshell文件进行了一些恶意操作。从以上分析我们可以得出，/index.php 这个页面存在 SQL 注入漏洞，后台地址为/guanli
11、.php,/upload.php 可直接上传 webshell 那么很容易就能得出补救方法，修复注入漏洞、更改管理员密码、对文件上传进行限制、限制上传目录的执行权限、删除 webshell。三、日志分析中存在的难题看完上一节可能大家会觉得原来日志分析这么简单，不过熟悉 Web 安全的人可能会知道，关于日志的安全分析如果真有如此简单那就太轻松了。其实实际情况中的日志分析，需要分析人员有大量的安全经验，即使是刚才上节中简单的日志分析，可能存在各种多变的情况导致提高我们分析溯源的难度。对于日志的安全分析，可能会有如下几个问题，不知道各位可否想过。1.日志中 POST 数据是不记录的，所以攻击者如果找
12、到的漏洞点为 POST 请求，那么刚刚上面的注入请求就不会在日志中体现2.状态码虽然表示了响应状态，但是存在多种不可信情况，如服务器配置自定义状态码。如在我经验中，客户服务器配置网站应用所有页面状态码皆为 200，用页面内容来决定响应,或者说服务器配置了 302 跳转，用 302 到一个内容为“不存在页面”(你可以尝试用 curl 访问 http:/ 看看响应体)3.攻击者可能使用多个代理 IP，假如我是一个恶意攻击者，为了避免日后攻击被溯源、IP 被定位，会使用大量的代理 IP 从而增加分析的难度(淘宝上，一万代理 IP 才不到 10 块钱，就不说代理 IP 可以采集免费的了)如果一个攻击者
13、使用了大量不同的 IP 进行攻击，那么使用上面的方法可能就无法进行攻击行为溯源了4.无恶意 webshell 访问记录，刚才我们采用的方法是通过“webshell”这个文件名从日志中找到恶意行为，如果分析过程中我们没有找到这么一个恶意webshell 访问，又该从何入手寻找攻击者的攻击路径呢?5.分析过程中我们还使用恶意行为关键字来对日志进行匹配，假设攻击者避开了我们的关键字进行攻击?比如使用了各种编码，16 进制、Base64 等等编码，再加上攻击者使用了代理 IP 使我们漏掉了分析中攻击者发起的比较重要的攻击请求6.APT 攻击，攻击者分不同时间段进行攻击，导致时间上无法对应出整个攻击行为
14、7.日志数据噪声(这词我也不知道用得对不对)上文提到过，攻击者可能会使用扫描器进行大量的扫描，此时日志中存在大量扫描行为，此类行为同样会被恶意行为关键字匹配出，但是此类请求我们无法得知是否成功扫描到漏洞，可能也无法得知这些请求是扫描器发出的，扫描器可使用代理 IP、可进行分时策略、可伪造客户端特征、可伪造请求来源或伪造成爬虫。此时我们从匹配出的海量恶意请求中很难得出哪些请求攻击成功了四、日志分析工程化之路 探索篇(上一节留下的坑我们留到最后讨论因为我也觉得比较头疼，我们现在来讨论一点让人轻松的)曾经有运维的人员问我们公司的大神，该如何分析日志?大神回答了三个字：“用命令”因为站在安全经验丰富的
15、人角度来看，的确用命令足矣，可是对于安全经验不那么丰富的人来说，可能就不知道从何入手了。但是即使身为一个安全从业人员，我也觉得用命令太过耗时耗力(还有那么多有趣的事情和伟大的事情没做呐，当然还要节约出一点时光来嗨嗨嗨呀，难道每次分析日志我们都用命令一个个给一点点分析?)于是，聪明的黑客们就想到了，将这些步骤流程写成工具，让工具来帮我们分析日志，当然我也想到了，可是在我造这么一个轮子之前，我习惯性的到各大网站上先翻一翻，看看有没有人实现过，还真让我找到一些，见 FAQ 区域。我以“Web 安全日志分析”为关键字，百度&Google 了一番，发现并没有找到自己觉得不错的日志分析工具，难道安全行业就
16、没有大牛写个优秀的日志分析工具出来?年轻时的我如此想到，后来我发现并非如此，而是稍微优秀一点的都跑去做产品了，于是我转战搜寻关于日志安全分析产品，通过各种方式也让我找到了几个，如下：1. 首先是推广做得比较好的:日志易日志易确实像它推广视频里所说的：“国内领先的海量日志搜索分析产品”前段时间，有客户联系到我们，说他们买了日志易的产品，但是其中对安全的监控比较缺乏，让我们能不能在日志易的基础上添加一些安全规则，建立安全告警，他们要投放到大屏幕，然后来实时监控各个服务器的安全状态。然后我就大概看了一遍日志易的产品，安全方面的分析，基本为 0.C但是日志易确实有几个优点：1.日志采集方面相对成熟，已
17、经能针对多种日志格式解析并结构化，还支持用户自定义日志格的辅助解析2.海量日志存储相对完善，可接收来自各个客户端的日志，Saas 服务成熟，能对接各大云主机3.搜索方面技术优秀，千亿级别数据索引只需 60 秒(但是，我要的安全分析啊，其他的再成熟，也始终是个不错的日志分析平台而已，我要的是安全分析、安全分析、安全分析重要的话说三遍)补：(后来我发现，日志易其实有在安全方面进行分析，但是这个如图这个结果，并没有让我觉得眼前一亮，而且其中还有大量的误报)2. 看到一个稍微像那么回事的产品：安全易他们推广做得不那么好，所以在我一开始的搜索中，并没有从搜索引擎找到它，这个产品是可以免费注册并试用的，于
18、是我迫不及待注册了一个账号进去看看，如图：当我试用过安全易这个产品之后，提取出了他们在关于安全方面所做的统计列表，如下：1.威胁时序图2.疑似威胁分析3.疑似威胁漏报分析4.威胁访问流量5.威胁流量占比6.境外威胁来源国家(地区)统计7.境内威胁来源城市统计8.威胁严重度9.威胁响应分析10.恶意 IP11.恶意 URL 分析12.威胁类型分析13.威胁类型分布14.威胁分类计数15.威胁来源热力图16.威胁总数17.威胁日志占比结果似乎挺丰富，至少比我们开始使用命令和工具得到的结果更为丰富，其实在看到这个产品之前，我们内部就尝试使用过各种方法实现过其中大部分视图结果，但是似乎还是缺少点什么
19、攻击行为溯源，也就是我们在第二节中对日志进行简单的分析的过程，得到攻击者的整个攻击路径已经攻击者执行的恶意操作。不过想要将这个过程工程化，难度可比如上 17 个统计视图大多了，难在哪里?请回看第三节虽然安全易的产品并没有满足我对日志分析中的想法，但是也不能说它毫无价值，相反这款产品能辅助运维人员更有效率的监控、检查服务器上的安全事件，甚至他们不用懂得太多的安全知识也能帮助企业更有效率的发现、解决安全问题五、日志分析工程化之路 实践篇在了解了很多分析日志的工具后，也尝试过自己折腾出一个方便分析日志的工具，以便以日常工作中的应急响应场景记得是在半年前左右，我的思路是这样的：1.首先确认日志结构我在
20、 Mysql 中建立了如下结构的一张表来存储日志：日志字段请求时间服务器名称客户端 IP请求方法请求资源服务器端口服务器 IP浏览器信息响应状态码请求来源响应长度请求协议2.给 Web 攻击进行分类攻击类型表攻击类型名称危险等级攻击/扫描3.建立攻击规则表对应不同的攻击类型攻击规则表攻击规则正则表达式攻击发生的位置攻击规则对应的攻击类型 ID此时不得不说一下当时日志是怎么入库的，不知道大家是否知道 awk 命令echo “aa bb cc“ | awk -F print $1我们对日志采用了类似的方式，通过空格分割，然后生成出 Mysql 中可用的insert 语句大约为：INSERT INT
21、O web_log VALUES ($1,$3,$4,.),至于你说其中列数是如何对应到 Mysql 里的表结构的,我们当时是人工核对的，为每一个不同的日志文件进行人工对应(可想而知这活工作量多大)扯回正题，当我们入库完毕后有了这么三张数据表，聪明的童鞋可能已经知道下一步要干什么的，那就是拿着安全规则正则表达式去逐条匹配日志表里面的日志然后得到结果：攻击日志 ID攻击类型 ID攻击规则 ID最后我们只需要写 SQL 语句，就能轻松统计各个攻击类型都分别有多少攻击请求了，如图：最后我们思考了从各个角度来进行查询，得到了如下以下列表中的结果：1.网站受攻击次数排名2.网站高危请求排名3.网站攻击者
22、数量排名4.网站受攻击页面排名5.可疑文件排行6.被攻击时间统计7.攻击来源分布8.高危攻击者排行9.攻击者攻击次数排行10.网站危险系数排行11.攻击者数量统计12.各站点攻击者数量统计13.各扫描器占比14.使用扫描器攻击者统计C由于这是一次针对多个(70+)站点的分析，所以只需突显安全趋势即可，在此次日志分析中，还并未涉及到溯源取证记得当时我们是用 SQL 语句查询出结果，然后将数据填入 Execl，然后进行图标生成，整个日志分析的过程，从日志原文件到入库到匹配到统计到出数据最后到Execl 出统计图表基本都需要人工参与对了，上几张图瞧瞧吧(篇幅原因，其他统计图不贴上来了)可以看出，我们
23、仅仅只是采用了一些安全攻击规则来对日志进行匹配就已经得到了不错的结果，虽然整个过程有点漫长，但是得到的这一份日志分析报告是具有实际意义和价值的，它可以帮我们发现哪些站点受到的攻击行为最多，那一类攻击最为频繁，哪些站点风险系数较高，网站管理和运维人员可以通过这份报告，来着重检查危险系数较高的请求和危险系数较高的站点，从而大大提高效率。但是日志分析工(lan)程(duo)化(hua)之路到此结束了吗?不，远远没有。六、日志分析工程化之路 进阶篇有没有觉得像上面那样折腾太累了，虽然确实能得到一个还不错的结果。于是开始找寻一个较好的日志分析方案，最后采用了开源日志分析平台 ELK,ELK 分别为：El
24、asticsearch 开源分布式搜索引擎Logstash 对日志进行收集、过滤并存储到 Elasticsearch 或其他数据库Kibana 对日志分析友好的 Web 界面,可对 Elasticsearch 中的数据进行汇总、分析、查询因为它开源、免费、高可配，所以是很多初创企业作为日志分析使用率最高的日志分析平台当理清楚 ELK 的搭建方式和使用流程后，我们用 ELK 实现了一遍第五节中的日志分析流程大概如下：1.编写 Logstash 配置文件2.将攻击规则应用于 logstash 的 filter 插件3.利用载入了安全分析插件后的 logstash 进行日志导入4.查询分析结果5.利用 Kibana 进行统计、可视化到这里，所得结果已经比“HanSight 瀚思”安全易这个产品的结果更为丰富了 ，但是日志安全分析之路远远没有结束，最重要也最具有价值的那部分还没有得到实现 攻击行为溯源。七、日志安全分析攻击溯源之路 探索篇
