由于17年到18年现在陆陆续续接到了不少新老客户的Oracle database受此类恶意脚本的攻击，我们也积累了一些防范此类问题的措施，在此篇中简单介绍2种容易的被动防御方法：
1.创建此类攻击脚本的对象名称进行占用（最简单最笨的方法）
DBMS_SUPPORT_INTERNAL DBMS_SYSTEM_INTERNAL DBMS_CORE_INTERNAL
对这三个对象名称进行占用处理。
2.对创建触发器的操作进行主动阻止
对主要的dba用户进行DDL操作的阻止，类似写法不再描述。
Access control
建议关注11g数据库password_life_time
Oracle 11g 之前默认的用户时是没有密码过期的限制的，在Oracle 11g 中default的profile启用了密码过期时间是180天,也就是password_life_time值为180,虽然是个小细节,但是很多客户在迁移到11g后有规律性的都在半年后出现了密码错误无法登陆的问题.
如下：
select * from dba_profiles where profile='DEFAULT' and resource_name='PASSWORD_LIFE_TIME'; PROFILE RESOURCE_NAME RESOURCE LIMIT ------------ -------------------- -------- ------- DEFAULT PASSWORD_LIFE_TIME PASSWORD 180
当过期时候系统会报错ORA-28002.当遭遇这个问题时候可以通过以下方式解决:
-
1.新建profile,对用户指定新的profile.
2.通过对用户重设密码(密码可以和原来一样).
命令为:
alter user username identified by password.
3.针对默认的profile的password_life_time设置为unlimited
命令为:
alter profile default limit PASSWORD_LIFE_TIM 180.
以下是profile里的关于password的设置类目解释:
-
FAILED_LOGIN_ATTEMPTS
设定登录到Oracle 数据库时可以失败的次数。一旦某用户尝试登录数据库的达到该值时，该用户的帐户就被锁定，只能由DBA能解锁。
PASSWORD_LIFE_TIME
设定口令的有效时间（天数），一旦超过这一时间，必须重新设口令。缺省为180天（11g，10gUNLIMITED）.
PASSWORD_REUSE_TIME
许多系统不许用户重新启用过去用过的口令。该资源项设定了一个失效口令要经过多少天，用户才可以重新使用该口令。缺省为UNLIMITED.
PASSWORD_REUSE_MAX
重新启用一个先前用过的口令前必须对该口令进行重新设置的次数（重复用的次数）。
PASSWORD_LOCK_TIME
设定帐户被锁定的天数（当登录失败达到FAILED_LOGIN_ATTEMPTS时）。
PASSWORD_GRACE_TIME
设定在口令失效前，给予的重新设该口令的宽限天。当口令失效之后回，在登录时会出现警告信息显示该天数。如果没有在宽限天内修改口令，口令将失效。
PASSWORD_VERITY_FUNCTION
该资源项允许调用一个PL/SQL 来验证口令。Oracle公司已提供该应用 的脚本，但是只要愿意的话，用户可以制定自己的验证脚本。该参数的设定就是PL/SQL函数的名称。缺省为NULL.
简便的数据刷选安全控制方式以及不可避免的ORA-01039错误
对于一些使用Oracle或者其他数据库（比如mysql，sql server，sybase，db2等）的企业或者单位，在涉及到一些数据交涉（可能是多级单位之间的数据交换获取）过程中，经常会碰到一些不愿意被对方看到的数据，那么这个时候就需要相关的表数据做刷选再传递给对方，刷选的方式有不少，比如dmg，rls，ols（rls的升级版），fgac，身份验证，role control等，更甚者会用dbv，这些都是oracle在安全方面所做的支持，每一种的设置都有自己优势和弊端，到这里你一定以为我会选择上面的一种方式来实现，哈哈~这里我要介绍的是采用view或者synonym的方式来控制，这里以Oracle数据库中来限制数据访问的最简单的方式为例子，在Oracle中如果相关数据规模不大，或者相关的业务执行频率可控，而且要做dml的限制，那么首先建议就是是采用view或者synonym，反之如果对dml有要求，要么在评估性能的基础上选择上面介绍的方式外，还有物化视图的方式。
具体如下：
我们先提出需求，用户a要求查询b下的b.t1表的关于id=100的数据，但是b用户不希望a用户在能看到t1表下id=100之外的数据，采用view的方式就会如下：
一.测试环境搭建：
create user a identified by ludatoua;
create user b identified by ludatoub;
grant resource,connect to ludatoua;
grant resource,connect to lidatoub;
grant select any dictionary to ludatoua; — 必须要的
grant select any dictionary to ludatoub; — 必须要的
grant select on v_$session to ludatoua;
grant select on v_$sesstat to ludatoua;
grant select on v_$statname to ludatoua;
B用户下：
create table t1 as select * from all_objects; –记得要现有权限
alter table t1 add rn number;
update t1 set rn=300;
update t1 set rn=100 where rownum < 5;
二.根据要求，通过建立view的方式刷选数据：
B用户下：
create view xh$t1 as select * from t1 where id=100;
grant select on ludatoub.xh$t1 to ludatoua;
A用户下操作：
view方式限制：
create synonym t1 for ludatoub.xh$t1;
synonym方式限制：
create synonym t1 for ludatoub.xh$t1;
到了这里我们要做简单的数据刷选（数据访问限制）已经完成了，但是有一个问题是不能被忽略的，ORA – 01039错误（在看执行计划的时候产生导致无法对这个view的执行计划进行观测）， insufficient privileges on underlying objects of the view。错误的解释是相关对象的视图没有权限去访问定义的基表。这样的错误很多人都碰到过，但是都没有一个很好的解决方案，网上公布得最多的是grant select any dictionary to user的方式来解决，但是这个只能解决本身用户的，在我们这的情况下（在ludatoua）用户下，这种方式就起不到左右了。有兴趣的同学可以使用10053或者46去看在看执行计划时候到哪一步报错没权限，我这里就不列出了。
问题的原因在与view的嵌套视图的基础对象，ludatoua用户是没有对ludatoub下的对象select权限的，因为我们需要控制ludatoua不能直接访问ludatoub的t1表。在我们的案例中就是ludatoua用户无法对ludatoub的t1对象进行select才导致了这里看执行计划时候报错 ORA – 01039。这是采用view方式的一种弊端，所以时候时候还是需要权衡（个人使用过程影响不大，调优都是对view的刷选语句进行）。
这里在选择view或者synonym方式的时候就需要对view相关sql的性能进行了解，避免糟糕的性能对业务引起的不必要的影响，而view方式的调优都都在view本身这层。
