论坛公告:应用容器安全指南(SP800-190)中文版   美国政府宣布禁用卡巴斯基软件   《中华人民共和国网络安全法》讨论帖   新手报到专用帖   【论坛公告】关于本站广告贴泛滥问题的整理通知   

当前时区为 UTC + 8 小时


发表新帖 回复这个主题  [ 5 篇帖子 ] 
作者 内容
 文章标题 : oracle 数据库会话还原
帖子发表于 : 2011-05-12 13:01 
离线
初级用户

注册: 2010-07-07 09:21
最近: 2015-08-07 16:51
拥有: 486.00 安全币

奖励: 0 安全币
在线: 210 点
帖子: 29
从各种技术论坛、各安全厂家都在说自己的数据库审计系统能做到完整的SQL审计、审计结果。还能做到会话还原,
即可以还原出各个SQL、对数据库的操作都是谁做的。
后来经过调研发现,有一些厂家说自己是嗅探做的,有一些说自己是需要数据库自己打开日志,还有甚者在数据库系统上装代理程序。数据库自己打开日志和在数据库服务器上安装代理这种目前很多客户都不会接受的,并且严重影响数据库的性能。很多客户在真正上了贼船才发现,靠!唉~ 会影响性能那,那数据库审计不做了。
现在绝大部分厂家都说自己是通过旁路嗅探的方式抓包获取数据库操作,然后做分析,会话还原的。
我通过嗅探工具进行了基本的分析,发现会话还原,只能还原到TCP级别。
比如ORACLE、SQLSERVER这些应用级别的会话,通过网络协议基本很难分析到。并且网络上对于TNS协议、TDS协议中数据级别的分析也很少。我就想问问论坛里的高手们,数据库应用级别会话还原时怎么做到的?比如可以知道这些所有的操作都是用户A做的。


回到顶部
 奖励本帖 用户资料  
 
 文章标题 : Re: oracle 数据库会话还原
帖子发表于 : 2011-08-10 08:43 
离线
高级用户

关注按钮

注册: 2004-01-24 17:13
最近: 2015-06-04 11:46
拥有: 2,646.20 安全币

奖励: 624 安全币
在线: 4224 点
帖子: 292
地址: 深圳
做协议的还原不难,否则国内不会有那么多旁路的DAM出现

如果agent做的好,我倾向部署agent,旁路的太容易绕过了,当然了,理论上可以结合安全管理、运维审计,访问控制,日志审计来弥补这个短板。只是。。。咱有那么牛逼吗?

1、我在数据库上打个ssh tunnel,然后连数据库。
2、我在数据库上做个socks代理,然后连接数据库。
3、我在数据库上做个VPN,然后连接数据库。
4、我在数据库上做个ssl tunnel,然后连接数据库。

解决方案似乎很简单:
1、强化运维管理规范、上运维堡垒机,发现违规则开除。然后呢?我们能发现人家做代理打隧道吗?真的能吗?
2、强化访问控制,禁止开放白名单之外的端口。反向连接的呢?
3、日志审计。。。这个太YY了。

没出事的时候还可以YY一下咱的管理制度多么完善,要求禁止1234种行为。出事了的时候咱会发现黑客不会遵循我们的管理制度。

我想表达的是,非agent的DAM+各种措施的确可以提高门槛,但是对于真正想犯事的人,还是不够给力。作为DAM的项目负责人,必须暴露该风险。让高管去选择到底是接受被bypass的风险还是agent的风险。

agent的风险:
1、agent不成熟把DB搞挂。<-- 灰度部署,DB高可用。选择成熟产品。
2、agent不成熟把DB搞慢。<-- 性能监控。选择成熟产品。

如果你是高管,你选择哪个?心态不同,选择还真不一样 :)


--------本帖迄今已累计获得32安全币用户奖励--------


回到顶部
 奖励本帖 用户资料  
 
 文章标题 : Re: oracle 数据库会话还原
帖子发表于 : 2011-08-10 08:50 
离线
高级用户

关注按钮

注册: 2004-01-24 17:13
最近: 2015-06-04 11:46
拥有: 2,646.20 安全币

奖励: 624 安全币
在线: 4224 点
帖子: 292
地址: 深圳
补充一句,国内DAM厂商没做agent产品


回到顶部
 奖励本帖 用户资料  
 
 文章标题 : Re: oracle 数据库会话还原
帖子发表于 : 2011-08-10 12:35 
离线
高级用户

注册: 2004-08-03 16:33
最近: 2015-06-25 09:13
拥有: 4,332.10 安全币

奖励: 491 安全币
在线: 8148 点
帖子: 214
perlish 写道:
做协议的还原不难,否则国内不会有那么多旁路的DAM出现

如果agent做的好,我倾向部署agent,旁路的太容易绕过了,当然了,理论上可以结合安全管理、运维审计,访问控制,日志审计来弥补这个短板。只是。。。咱有那么牛逼吗?

1、我在数据库上打个ssh tunnel,然后连数据库。
2、我在数据库上做个socks代理,然后连接数据库。
3、我在数据库上做个VPN,然后连接数据库。
4、我在数据库上做个ssl tunnel,然后连接数据库。

解决方案似乎很简单:
1、强化运维管理规范、上运维堡垒机,发现违规则开除。然后呢?我们能发现人家做代理打隧道吗?真的能吗?
2、强化访问控制,禁止开放白名单之外的端口。反向连接的呢?
3、日志审计。。。这个太YY了。

没出事的时候还可以YY一下咱的管理制度多么完善,要求禁止1234种行为。出事了的时候咱会发现黑客不会遵循我们的管理制度。

我想表达的是,非agent的DAM+各种措施的确可以提高门槛,但是对于真正想犯事的人,还是不够给力。作为DAM的项目负责人,必须暴露该风险。让高管去选择到底是接受被bypass的风险还是agent的风险。

agent的风险:
1、agent不成熟把DB搞挂。<-- 灰度部署,DB高可用。选择成熟产品。
2、agent不成熟把DB搞慢。<-- 性能监控。选择成熟产品。

如果你是高管,你选择哪个?心态不同,选择还真不一样 :)

有个疑问
关于通过强化运维管理规范、上运维堡垒机,发现违规则开除。然后呢?我们能发现人家做代理打隧道吗?真的能吗?这一点
为什么不能发现代理打隧道??能具体解释一下吗


回到顶部
 奖励本帖 用户资料  
 
 文章标题 : Re: oracle 数据库会话还原
帖子发表于 : 2011-08-16 08:04 
离线
高级用户

关注按钮

注册: 2004-01-24 17:13
最近: 2015-06-04 11:46
拥有: 2,646.20 安全币

奖励: 624 安全币
在线: 4224 点
帖子: 292
地址: 深圳
klompe 写道:
perlish 写道:
做协议的还原不难,否则国内不会有那么多旁路的DAM出现

如果agent做的好,我倾向部署agent,旁路的太容易绕过了,当然了,理论上可以结合安全管理、运维审计,访问控制,日志审计来弥补这个短板。只是。。。咱有那么牛逼吗?

1、我在数据库上打个ssh tunnel,然后连数据库。
2、我在数据库上做个socks代理,然后连接数据库。
3、我在数据库上做个VPN,然后连接数据库。
4、我在数据库上做个ssl tunnel,然后连接数据库。

解决方案似乎很简单:
1、强化运维管理规范、上运维堡垒机,发现违规则开除。然后呢?我们能发现人家做代理打隧道吗?真的能吗?
2、强化访问控制,禁止开放白名单之外的端口。反向连接的呢?
3、日志审计。。。这个太YY了。

没出事的时候还可以YY一下咱的管理制度多么完善,要求禁止1234种行为。出事了的时候咱会发现黑客不会遵循我们的管理制度。

我想表达的是,非agent的DAM+各种措施的确可以提高门槛,但是对于真正想犯事的人,还是不够给力。作为DAM的项目负责人,必须暴露该风险。让高管去选择到底是接受被bypass的风险还是agent的风险。

agent的风险:
1、agent不成熟把DB搞挂。<-- 灰度部署,DB高可用。选择成熟产品。
2、agent不成熟把DB搞慢。<-- 性能监控。选择成熟产品。

如果你是高管,你选择哪个?心态不同,选择还真不一样 :)

有个疑问
关于通过强化运维管理规范、上运维堡垒机,发现违规则开除。然后呢?我们能发现人家做代理打隧道吗?真的能吗?这一点
为什么不能发现代理打隧道??能具体解释一下吗


不用解释,你找个人演习一下就知道了,看下能不能发现。比如甲扮演黑客在一周内的某个时间,在服务器上做个socks,vpn或ssh tunnel,乙扮演审计人员看能否及时发现及定位。


回到顶部
 奖励本帖 用户资料  
 
显示帖子 :  排序  
发表新帖 回复这个主题  [ 5 篇帖子 ] 

当前时区为 UTC + 8 小时


在线用户

正在浏览此版面的用户:没有注册用户 和 1 位游客


不能 在这个版面发表主题
不能 在这个版面回复主题
不能 在这个版面编辑帖子
不能 在这个版面删除帖子
不能 在这个版面提交附件

前往 :  
cron
华安信达(CISPS.org) ©2003 - 2012