本文地址：https://www.askmaclean.com/archives/%E5%85%B3%E4%BA%8Eoracle-firewall-%E9%98%B2%E7%81%AB%E5%A2%99%E6%8A%80%E6%9C%AF.html
Oracle Database Firewall 5.1
网络攻击
- SQL injection经常会受到攻击
- 信用卡信息等盗窃案件频繁发生
- 一般并不只窃取信息，还会同时伴有其他攻击。例：散播病毒以及受到攻击）
通过SQL injection获得的不正确的访问
- WEB应用的脆弱性，应用没有执行预想的SQL，对数据库进行错误操作，受到攻击
- 受到攻击会怎样？
- 可以自由参考数据库的信息
- 可以自由改写数据库的信息
- 最近的事件
- 2008年3月 包含Sound House的信用卡信息的个人信息泄露
- 2009年8月 从amuse的EC站点中泄露了包含信用卡信息的个人信息
- 2008年10月 Golf Digest Online的Web站点更改
- 2010年1月 Montbell的信用卡信息泄露
- 2010年7月 Koei Tecmo的GAMECITY会员信息泄露
例）SQL injection攻击～应用对数据库的正常查询
例）SQL injection攻击
～利用应用的脆弱性，加入错误的SQL命令
SQL injection的威胁
- SQL injection超过瞄准网站的攻击45%
- 网站受到的两大攻击之一（2010年）
- 数据库中储存的顾客信息以及决策信息，信息泄露对社会的影响较大
- 即使发现其脆弱性，要修复也需要1个月以上的时间
引用: IPA Web Application Firewall (WAF)读本 改订第２版
无法获得根本性的对策
- 对于修复SQL injection的脆弱性，需要进行以下修正
- 需要彻底检查WEB应用的输入值
- 为了使用静态占位符，二进制变量，需要进行相应变更
- 无法直接管理的WEB应用是非常脆弱的
- 提供Rental server 以及 cloud services的Web站点的运营者无法处理应用的脆弱性
- 开发者无法依赖于WEB应用的改写
- 开发供应商已经从开发工作中撤退了，依赖于其他供应商时，修改成本会增大
- WEB应用的修正中不容许的down time
- 对于以网络为中心来展开业务的公司来言，如果长期终止网络业务的话，造成的损失不可估量
数据库监察日志的重要性
数据库的监视日志的巨大竞争
- SQL injection攻击等、获得日志对于
DBA以及开发者等来说非常重要，因为可以较早检测出不必要的访问，
- 但是对大部分用户来说，基本不能获得日志
- 不知道数据库的监视日志的功能
- 对数据库性能的影响 (特别是现有环境)
- 应该获得怎样的日志，无法制成缩小监视条件的设计
- 保存日志的区域扩大
- 仅仅获得日志并不会获得监视链接
Oracle Database Firewall
不正确的访问控制&数据库监视
Oracle Database Firewall
收集/分析位于应用与数据库中间的网络traffic
blocking ：解析SQL，通过对判断为危险的项目进行拦截或者报错，来防止来自外部的攻击从而保护数据库
monitoring ：将已收集的SQL作为日志来记录、管理、报告
防御的First Line
穿透性的
不需要独立构造数据库、应用
正确检测
正确理解SQL语句，搭载检测SQL的语法解析
无遗漏的监视
对数据库的本地连接以及不经DBFW的SQL也可以进行监视
根据用途不同，2种不同的配置
- 监视链接与网络开个一起配置
- 从端口镜像中接收网络traffic，生成日志。
- Blocking直接在应用于数据库之间进行配置
- 接收网络traffic，应用block、pass的政策，生成日志
- (False positives)
- 错误检测
- 指将正确的SQL当成错误的SQL来检测出来的问题
- (False negatives)
- 比如、
- 每秒1000SQL= 一天8600万SQL
- 0.001%错误检测 = 一个月发生27000次的警报
- 0.0001%的遗漏检测 = 每天检测出86次遗漏访问的可能性
无法正确检测到的话，
就会遗漏不正确的访问，甚至导致无法正常使用
模式匹配的极限
TRUE的条件
- 1=1
- 10=10
- 20000=(1000+19000)
- ‘cat’=‘cat’
- ‘dog’=‘dog’
- LEFT(‘catastrophe’, 3)=‘cat’
- SQRT(49) = (8-1)/1
- ‘cat’ <> ‘mouse’
- SIN(45) = COS(45)
- CAST(123) as STR <> 123
- ‘567’<>567<>789
- '' = ''
各种UNION的记录
uni/* */on
u/* */nion
char(117,110,105,111,110)
无法无遗漏地搜索到所有字符串
False positives 以及false negatives增加
Oracle Database Firewall的检测方法
～理解了SQL语法的正确检测
SQL定义了400个keyword以及严格的语法规则 (ISO/IEC 9075)。理解、判断其语法结构
分析SQL，在cluster中集群化
SQL对策的管理对象，以cluster单位来执行
DATA的値即使不同，作为相同的cluster，文法结构也是相同的，就可以无遗漏地应用对策
Cluster 1 : SELECT * FROM certs WHERE cert-type = '18‘
Cluster 1 : SELECT * FROM certs WHERE cert-type = ‘3999‘
Cluster 2: SELECT * FROM certs WHERE cert-type = 'PHE8131' and location = 1
Oracle Database Firewall
白名单方法
对于用户以及应用的访问，定义允许的SQL
通过组合时间、日期、星期、网络、应用等要素，可以定义访问许可
生成允许的SQL的列表，从应用中简要地收集起来
对于定义完成的SQL列表中不存在的事务应该当即拒绝
Oracle Database Firewall
黑名单方法
对于用户以及应用的访问，定义拒绝SQL
通过组合时间、日期、星期、网络、应用等要素，可以定义拒绝访问
可以从文本文件中一次加载所有拒绝的SQL
定义完成的拒绝SQL列表中的事务应该当即拒绝
Oracle Database Firewall 部件的作用
Oracle Database Firewall Server
捕获网络traffic中的SQL，执行blocking monitoring
在AP～DB之间配置的inline方法，利用了镜像端口的Out-of-Band的两种方法
单机结构的情况下，会负责Management Server的所有功能
Oracle Database Firewall Management Server
DBFW的monitoring日志repository服务器
一元化管理、监视所有的DBFW，分析日志并报告
Oracle Database Firewall Analyzer
制成对策的客户端应用
Oracle Database Firewall Server
- OS: Oracle Linux 5 Update 5 (32bit)
- 严格的访问控制
- Repository的数据库为Oracle Database 11gR2
- 两种模式
- DAM (Database Activity Monitoring)
- DPE (Database Policy Enforcement)
- 本地监视器、SPA、URA、实时警报
- 至少需要3个网络端口
- 与Management Server信息交换的节点
- 用2个节点搭桥
- 支持High Availability结构
- 支持的监视对象数据库
- Oracle Database 8i～11gR2
- Microsoft SQL Server 2000,2005,2008
- Sybase ASE 12.5.3～15
- IBM DB2 9.x (Linux, Unix, Windows)
- MySQL 5.0, 5.1, 5.5
1台中可以检测、防御网络整体
- 最多可以使用8个端口进行监视，可以配合blocking使用
- 1个Database Firewall中对应多个不同的网络段
- 可以处理存在多个不同的数据库的环境
Oracle Database Firewall Management Server
- OS: Oracle Linux 5 Update 5 (32bit)
- 严格的访问控制
- repository的数据库为Oracle Database 11gR2
- Database Firewall通信用的节点
- 统一管理对策
- 支持High Availability结构
- PDF、Excel形式的报告
- Monitoring日志的归档、存储
- 日程表功能
- 与syslog服务器的合作，通过 SNMP监视
- 与F5 BIG-IP ASM、ArcSight SIEM的合作
Oracle Database Firewall Analyzer
- Windows用客户端应用
- 设计Database Firewall的对策
- 默认规则（白名单、黑名单）
- 加载规则
- Profile
- 登录/注销对策
- 数据架构
- Cluster、SQL水平中的Pass & Block
- 每个表的访问对策
- 代替SQL
- 例外处理
Local Monitor
- 不通过网络访问数据库获得日志
- 使用触发器机制，无遗漏地获得登录、主线、DDL的日志
- 参考直接SGA、本地直接获得被执行的DML的日志
Local Monitor的机制 (Oracle的情况)
- 如果执行本地监视器用的脚本的话，就会制成以下项目
- DBFW_CONSOLE_ACCESS、DBFW_CONSOLE_ACCESS_QRY用户
- Event 表
- Login、Logoff、DDL触发器
- 执行本地连接的login、logoff、DDL的话，Event表中写入日志的话，DBFW就会每秒都搜索Event表，获得后就需要删除
- 每秒参考一次V$SQL，获得本地连接的DML
Remote Monitor
- 直接监视小规模分散存在的数据库
- 数据库服务器的OS上常驻的，架构不经过网络的SQL
- 联系DBFW Management Server，收集监视日志
Remote Monitor的机制
- 仅仅在Remote Agent时收集日志
- DBFW性能降低时，直到DBFW的信息交换复原为止，都会保存期间的日志
监视日志的生成流程
被捕获的日志会被修复到DAT文件中。每5分钟就会对DAT文件进行一次压缩，加上电子签名。
报告的操作
- 搜索日志是通过已经制成的概要数据以及被压缩的日志文件 (dat.gz)莱执行，命中的各个日志会对各个traffic表插入。
- 只要保存了搜索結果任何时候都可以参考。另外，可以作为在各个报告中输出的信息原数据来使用
monitoring日志的尺寸
生成1200万个Oracle的XML监视日志的情况，总尺寸约为8.4GB
DBFW的圧縮完成(dat.gz)约为172MB
可以保存为日志的50分之一
※日志的尺寸依赖于SQL的种类与长度
DBFW在生成报告时会从dat.gz文件中储存到repositoryDB的Traffic log query results表中
如果生成包含一万件日志的报告的话，就是8MB，如果是10万件的话就是56MB，如果生成100万件的话就是528MB的日志。这些都会插入到表中
Oracle Database Firewall 管理咨询
监视日志的搜索功能
报告
- 20种以上的报告格式
- 以PDF、Excel形式输出报告
- 支持报告的日志表
- 支持cluster报告
默认报告例
- 违反对策的访问
- 数据库的管理访问
- 数据库的访问
- 吞吐量概要
- 一段期间内连接的DB用户列表
- 最后登录的DB用户列表
- 访问过的客户端应用列表
- OS用户信息
- 会话概要 (IP地址）
- 对每个会话执行SQL次数的概要
- 登录失敗
- 已失败的SQL
- 已执行的DDL
- 执行DML (仅限SELECT)
- 执行DML (除SELECT以外)
各模式中对事务的影响
- Out-of-Band对性能没有影响（即使使用监视&警报 (②)也没有影响)
- inline＋monitoring中没有影响
- inline＋blocking的情况，1个SQL平均会花费0.6秒的应用对策过载
- 数据库的负荷 10000SQL/秒
- 1事务=200种类的SQL
- 对策数 1000、登录
|
结构 |
mode |
Policy |
Logging |
1SQL
(毫秒) |
| ① |
没有 |
没有 |
× |
× |
1.02 |
| ② |
Out of Band |
DAM |
× |
○ |
1.02 |
| ③ |
Out of Band |
DAM |
○ |
○ |
1.035 |
| ④ |
in-Line |
DAM |
× |
○ |
1.11 |
| ⑤ |
in-Line |
DPE |
○ |
○ |
1.61 |
基于会话的flag列表对策
基于SQL的白名单机制
SQL base+α的白名单对策
创建访问策略的例子
强化面向BtoB, BtoC的服务安全性
～ Oracle 采用DBFW的例子，某电商
通过Oracle DBFW实现
- 检测所有内部外部访问 (monitoring)
- 防止内部访问（开发者管理者等）（blocking）
- 最终防止外部的不正规访问
DB访问的現状
存在可以对秘密性较高的数据的自由进行内部/外部访问的环境
没有管理数据库的访问历史
海外事例: 某投资银行（大规模DB监视系统）
商业要求:
- 废止传统的manual监视
- 生成满足监视条件的PDF以及Excel报告
- 要获得全年1天24小时内发生1.7亿次的事务
Oracle Database Firewall 的对策:
- 监视超过600个数据库
- 数据中心的文件不可用时，也可以通过 Database Firewall的高可用性功能来报告
- 集中管理Database Firewall Management Server中的报告功能
导入效果:
- Delivery of 20+ audit reports per day to database security team.
- 每天自动向安全部门发送20中监视报告
- 实现10０%的监视
选择Oracle Database Firewall的理由是：可以
同时实现高性能与执行正确的监视
可以全年全天监视超过600个数据库
DB Firewall 最简单的结构
- inline方法
- blocking、monitoring都可以
- 捕获日志保存在DBFW Server中
- 可以分析、报告日志 ※需要不受捕获影响的服务器资源
- 推荐作为功能检验、POC等测试功能来使用
- 许可证方面，Management Server更便宜
DB Firewall 基本结构(inline方法)
在应用与数据库之间进行inline配置
blocking、monitoring都可以
Management Server会定期访问DBFW Server获得捕获日志
DBFW Serverはblocking monitoring、DBFW Management Server因为可以完整地分离报告功能，所以可以更高效地使用服务器资源
DBFW Server的故障中，对应Fail Open NIC
(※电源故障/软件故障时，NIC进入bypass模式，就可以断网换网卡)
inline方法 + 网络冗长化结构
应用～数据库之间，对于冗长化的2个网络路径，各自通过inline配置DBFW Server
DBFW Server一直是Active
DBFW Server的故障，NIC的故障等，无法使用活跃的路径时，请对secondary进行故障转移 (故障转移的操作依赖于NIC以及Switch)
通过1个DBFW Management Server可以同时管理多个DBFW Server
(DBFW Server的捕获日志、对策等集中在DBFW Management Server中)
DB Firewall 基本结构(out of band方法)
out of band方法(从开关的镜像端口获得package)
仅仅监视
捕获日志通过访问Management Server DBFW Server获得
对现有的网络traffic没有影响
DBFW的故障中，对应DBFW的冗长化结构
结构、估计尺寸都非常简单
out of band方法 + DBFW冗长化结构
设定多个开关的镜像端口，使得DBFW Server冗长化
DBFW一般为Active，两边的DBFW Server都可以获得日志
监视时，作为Resilient pair，就会成为Primary以及Secondary的作用
向本地监视器、SPA、URA、Syslog发信息，是通过Primary的DBFW Server来执行
Management Server从Primary以及Secondary接收日志，为了日志不重复，需要仅仅应用
Primary的日志
out of band方法 + 网络冗长化结构
开关多重化时，各自的开关分别在镜像端口中连接DBFW Server
DBFW一般为Active，两边的DBFW Server都可以获得日志
Management Server从Primary以及Secondary接收日志，为了日志不重复，需要仅仅应用
Primary的日志
Proxy 方法
DBFW Server会取代应用来连接到数据库
在端口中将应用的数据库连接信息变更为DBFW Server的IP地址：
DBFW Server中可以指定任意IP地址以及端口
通过和DBFW Management Server的通信端口一起用，所以可以通过一个端口来构成
monitoring、blocking都可以
WAF与Oracle Database Firewall的差异
各自的保护对象——安全性layer不同
|
Web Application Firewall |
Oracle Database Firewall |
| 方法 |
网络配置型
服务器安装型 |
网络配置型 |
| 配置場所 |
DMZ |
内部网络 |
| 对策 |
白名单、黑名单 |
白名单、黑名单 |
| 对策数 |
1000以上 |
50～300程度 |
| 对策設定 |
根据各自的输入要求，进行分别定义 |
对SQL进行Pass/Block |
| 防御対象 |
SQL injection
跨站脚本等 |
外部访问(SQL injection)
内部访问(管理者开发者等) |
| SQL injection
的防御精度 |
70～80%左右 |
100% |
| 特徴 |
可以防御来自外部的各种攻击，、SQL injection可以作为一种攻击来定义
实际上，一般错误检测都过于广泛以及浅薄，WAF自身也难以普及 |
可以完全防御SQL injection。另外，不仅是外部访问，对于内部不正确的访问（管理者与开发者）都可以执行防御检测
数据库中的访问控制器。 |
- H/W
- XXXXXXX
- Intel Xeon X5675 6-core 3.06 GHz processor x1
- 12GB Memory (4GB DIMM x3)
- 300GB 10Krpm Disk x2
- N/W Port: 4
- S/W
DBFW Server (Standard结构)
- H/W
- XXXXXXX
- Intel Xeon X5675 6-core 3.06 GHz processor x2
- 24GB Memory (4GB DIMM x6)
- 300GB 10Krpm Disk x2
- Sun x4 Quad-port Gigabit Ethernet Adapter UTP x1 S/W
- N/W Port: 8
- S/W
- Licence: Oracle Database Firewall
DBFW Management Server
- H/W
- XXXXXXX
- Intel Xeon E5620 4-core 2.4 GHz processor x1
- 12GB Memory (4GB DIMM x3)
- 600GB 10Krpm Disk x 2～
- 因为Management Server是日志最终保存地址，所以需要根据日志保存期间以及部件估计合适的尺寸
- S/W
- Oracle Database Firewall Management Server 2 processor
Oracle Database Firewall 许可证
| Product |
Packaging |
License List |
License Metric |
| Database Firewall |
• Oracle Linux (OEL5 U5)
• Local/Remote Monitor software
• HA deployment of Database
• Supports Oracle and non-Oracle databases
• |
543,500 |
1Processor
监视对象数据库 |
| Database Firewall Management Server |
• Oracle Linux (OEL5 U5)
• Policy Analyzer software (仅限Windows、没有 processor的限制) |
6,250,000 |
1 Processor Database Firewall Management Server |
※即使增强DB Firewall Server、执行冗长化，许可证也没有变化
