有关IDS日志分析的讨论   来自华安论坛    帖子地址:http://bbs.cisps.org/viewtopic.php?f=42&t=25157&start=15

ynhu99  文章标题 : IDS日志分析的困惑   帖子发表于 : 2010-08-03 10:22   一楼

IDS作为***行为检测的重要手段,往往因为海量日志使人无法分析,经过努力我们已经做到将IDS日志过滤到每日可分析的级别。但是有一个问题却始终困扰着我,每当有***事件发生时,单纯依靠IDS日志无法确定***者是否获得了他想要的信息,是否已经***成功了。还有一个比较大的问题就是,在做IDS事件分析过程中,要解释某个事件到底是如何上报的,什么行为触发了该事件。一般的处理过程是定位源地址和目的地址,然后根据源地址和目的地址的业务系统推测事件是如何产生的,其实这样是没有事实依据的,不知道大家在分析过程中是否有同感。有好的思路大家可以一起讨论。
====================================================================================================================
yfy59  文章标题 : Re: IDS日志分析的困惑  帖子发表于 : 2010-08-03 10:42  二楼

楼主啊,我跟你也有同样的困惑,我跟你交流下我的做法,然后让坛子里的大牛也指点下:我负责三台IDS的监控和日志分析工作,由于是在运营商的承载网上,日志量非常大,如果不做策略限制,any to any的话,一天就几百万条事件了,我也是层层过滤,筛到了现在的结果:
1. 调整策略为any to protected targets,只记录针对业务系统自身的***,对于业务系统对外的安全事件不予告警记录。这样子,能cut掉20%多的事件。
2. 不记录业务系统之间的安全事件,这样子肯定不好,但是内部有防火墙和其他安全设备做安全域隔离,所以不是重点关注区域,这样子,cut掉了30%的事件。
3. 对高风险安全事件进行告警和记录,中、低风险只做记录,不进行告警,这样子,在统计数据时,也只重点统计高风险事件,这样子,又cut掉将近20%的事件。
以上方法全部筛完,省下了30%的安全事件,但事件量还是很大,怎么办呢,在人工分析提交报告时,再只针对重点系统,如DNS等几个比较重要的业务系统,对这些系统的高危***进行统计分析,源和目的地址统计(TOP10),高危事件(TOP10),蠕虫、病毒、***统计TOP10,供上级参考。但我感觉粒度还是不够细,可是想不出更好的方法了,请各位大牛指点。

====================================================================================================================
selinux  文章标题 : Re: IDS日志分析的困惑  帖子发表于 : 2010-08-03 10:55  三楼

1 IDS的策略如果全开的话,报警会很多,但是这也不是没办法,你需要根据具体的环境来做,比如服务器区可能只有linux系统,那你就直接选linux策略,应用到这个区域就可以了,可以减少很大的误报。比如绿盟的ids支持vids,可以针对不同的业务区域,制定不同的策略规则。
2 要想知道IDS报的警报中是否已经***成功了,单靠IDS是不能确定***者是否获得了他想要的信息,是否已经***成功了,ids只会检测***时的***特征,至于成没成功,没法判断,但我想这个IDS厂商也可以做,例如***了存在漏洞的IOS版本,IDS可以后续抓取telnet的数据包,看看 telnet里面的信息,就能判断是否***成功。

====================================================================================================================
ynhu99    文章标题 : Re: IDS日志分析的困惑   帖子发表于 : 2010-08-03 11:00  四楼 回复二楼话题

你的这个问题我们是这样处理的,经过你的1、2、3后剩下的30%的安全事件,特征事件按照TOP排名每天分析1到3个,分析的重点是事件产生的原因、事件对我们监控的对象有没有影响。如果最后得出的结论是某个事件是正常的业务系统触发的或者正常的网管事件并且对我们监控的对象没有影响,那么就可以过滤掉改事件了。还有一种情况是如果你监控的对象是linux,你也可以过滤掉目的地址是你监控的对象事件类型是 windows的事件,这样只要坚持,事件会越来越少,最后达到可处理的级别。希望对你有帮助。

====================================================================================================================
ynhu99    文章标题 : Re: IDS日志分析的困惑  帖子发表于 : 2010-08-03 11:07   五楼  回复 三楼话题

你的第二点估计也是厂商的困惑,我知道的目前市场上的IDS还没有一家能判断出***的结果,所以我们想到了引进一种应用层的会话记录设备,类似于 sniffer,这种设备一方面可以存储网络上的所有的数据包,还有一方面可以按照我们的规则呈现出异常事件的会话记录或者数据包。因为会话是双向的,有了这些会话记录或者数据包,在做事件分析的时候就有事实依据了,在结合IDS的特征库,应该可以说明某个事件到底是怎么触发的。也可以根据返回的会话判断***有没有成功。

====================================================================================================================
terry_yu     文章标题 : Re: IDS日志分析的困惑  帖子发表于 : 2010-08-03 12:08  六楼  回复三楼话题

1.少开了策略漏报的概率就增加了,还是建议在IDS性能允许的前提下把可能相关的策略都打开(针对性+适度放宽)
2.从IDS日志可以判断出一部分***成功,但很多是难以判断的,对IDS要求太高,事倍功半。要判断是否***成功,最直接的方法莫过于自己登录到控制台进行人工审查,HIDS也是一个很好辅助工具。

====================================================================================================================
selinux    文章标题 : Re: IDS日志分析的困惑  帖子发表于 : 2010-08-03 12:55   七楼

少开是可能漏报很多,但是那些并不是针对本业务内的,也没必要去看,因为不会有什么危害。这个主要是看用户打算怎么使用ids了,如果是想看看目前网络的***行为,那就全开,如果是只关注某业务系统,可以有针对性的开。当然也不乏有人想,我检测到其他的***行为,起码能意识到有人在***我,是这样的。这主要看你怎么取舍了。

====================================================================================================================
eric.v     文章标题 : Re: IDS日志分析的困惑    帖子发表于 : 2010-08-06 08:58   11楼

楼上各位提出的如何减少ids日志的方式是行之有效的,其实这个话题延伸开来就是SIEM了,如果单一安全设备的日志不能满足我们的安全分析,那就要关联其他设备的安全日志了,比如边界防火墙,ids/ips,操作系统日志,***目标的应用日志等等。以源IP或者目的IP为参照点,再加入某种***方式产生的日志特征做筛选,效果要比分析单个日志好多了。话说回来,没有SIEM设备怎么办,只能是手动+工具去分析各类日志源了。

====================================================================================================================
eric.v     文章标题 : Re: IDS日志分析的困惑  帖子发表于 : 2010-08-06 09:03      12楼

这个是安全事件关键日志复查核查表,有兴趣的可以看一下。
通用方法
1. 确认哪些日志源和自动化工具在分析过程中可以使用。
2. 将日志记录拷贝到你可以进行复查的地方。
3. 在确认日志不处于严重级别之后,通过移除常规、重复的日志记录来降噪。
4. 考虑到时区的不同,决定是否信赖日志的时间戳。
5. 关注你环境中最近的变更、失败、错误、状态变化、访问和管理事件,以及其他的异常事件。
6. 从现在开始回溯来重现事件发生前后的动作。
7. 通过不同的日志来关联动作从而得到一幅综合的画面。
8. 根据理论知识来判断发生了什么,并通过研究日志来确认或否定它们。


可能的安全日志源

服务器或工作站操作系统日志

应用日志(如WEB服务器、数据库服务器)

安全工具日志(如反病毒、变更探测、IDS/IPS等)

边界代理日志和终端应用日志

记住考虑其他,与安全事件有关的非日志源

典型日志位置

Linux操作系统和关键应用:/var/log

Windows操作系统和关键应用:Windows Event Log (Security, System, Application)

网络设备:通常通过syslog方式记录:某些使用私有位置和格式。

Linux下查看什么
Successful user login
用户登陆成功 “Accepted password”,
“Accepted publickey”,
"session opened”
Failed user login
用户登录失败 “authentication failure”,
“failed password”
User log-off(用户登出) “session closed”
User account change or deletion
用户账户变更或删除 “password changed”,
“new user”,
“delete user”
Sudo actions
SUDO动作 “sudo: … COMMAND=…”
“FAILED su”
Service failure(服务失败) “failed” or “failure”


Windows下查看什么

Windows 2000/XP/2003的事件ID如下所示, Vista/7 /2008的事件ID需要加上4096.

以下是安全日志中的绝大部分事件,部分仅仅是域控制器的记录。
User logon/logoff events
用户登入/登出事件 Successful logon 528, 540; failed logon 529-537, 539; logoff 538, 551, etc
User account changes
用户账户变更 Created 624; enabled 626; changed 642; disabled 629; deleted 630
Password changes
密码变更 To self: 628; to others: 627
Service started or stopped
服务启动或停止 7035, 7036, etc.
Object access denied (if auditing enabled)
访问对象拒绝 560, 567, etc

网络设备下查看什么

寻找同时包含进站和出站的活动
以思科设备为例
Traffic allowed on firewall
FW允许通过 “Built … connection”,
“access-list … permitted”
Traffic blocked on firewall
FW拒绝通过 “access-list … denied”,
“deny inbound”,
“Deny … by”
Bytes transferred (large files?)
字节转移 “Teardown TCP connection … duration … bytes …”
Bandwidth and protocol usage
带宽和协议使用 “limit … exceeded”,
“CPU utilization”
Detected attack activity
监测到***活动 “attack from”
User account changes
用户账户变更 “user added”,
“user deleted”,
“User priv level changed”
Administrator access
管理员访问 “AAA user …”,
“User … locked out”,
“login failed”

WEB服务器下查看什么

频繁尝试访问不存在的文件

URL里边存在(SQL/HTML)代码

访问你没有使之生效的扩展服务

WEB服务停止/启动/出错的消息

访问到允许用户输入的威胁页面

查看负载均衡集群中的所有机器的日志

文件中存在不属于自己的错误代码200

失败用户认证 Error code 401, 403

非法请求 Error code 400

内部服务器错误 Error code 500

====================================================================================================================
eric.v     文章标题 : Re: IDS日志分析的困惑  帖子发表于 : 2010-08-06 09:17   15楼

上面的是发生安全事件后的安全日志的复查表,实际上是提供了一个如何来对日志进行分析的简单思路。你分析IDS日志的目的是确

认你的受保护资产是否发生安全事件,所以联动起来分析会比较有效。