Protegendo o Oracle – Parte 2
January 12, 2013

Parte 01 – 07_DICTIONARY_ACCESSIBILITY

…

Encontrando os password default

Não é novidade nenhuma que existem várias contas de usuários padrão no banco de dados Oracle, alguns deles até são criados com privilégios administrativos.

Usuários padrão são criados no momento da criação do banco e claro,  são registrados sem uma senha e já vem bloqueado por default, exceto para SYS e SYSTEM que são contas administrativas que quando criadas através do CREATE DATABASE, se não definidas as senhas, elas devem ficar:

SYS : CHANGE_ON_INSTALL)
SYSTEM : MANAGER

Se você acha que os usuários default do Oracle é uma lista pequena, está enganado, aqui é alguns dos usuários padrão que são instalado sempre que um banco ou uma feature do banco é instalada. Por exemplo, o usuário XDB somente é instalado quando o Oracle XMLDB é instalado:

SYS
SYSTEM
SYSMAN
OUTLN
TSMSYS
WKSYS
SCOTT
ADAMS
JONES
WKPROXY
OLAPSYS
OWBSYS
CLARK
BLAKE
HR
OE
SH
DEMO
ANONYMOUS
CSMIG
CTXSYS
DBSNMP
DIP
DMSYS
DSSYS
EXFSYS
LBACSYS
MDSYS
ORACLE_OCM
ORDPLUGINS
ORDSYS
PERFSTAT
XDB
MGMT_VIEW
SI_INFORMTN_SCHEMA

Porém para alguns deles (quase todos), existe uma senha padrão definida, como o famoso usuário SCOTT que possuí a senha padrão definida como TIGER.

Muitos ambientes Oracle tem o usuário SCOTT criado (e provavelmente até com a senha padrão definida), o que deixa o banco de dados muito vulnerável, imagina que com uma senha padrão definida, qualquer um a qualquer momento pode acessar o seu banco, somente acessando essa conta.

Ok, mais como me livro disto? Qual é a maneira de descobrir se os usuários na lista acima está com a senha padrão habilitada?

Somente a view DBA_USERS_WITH_DEFPWD pode te responder isso …

Logado no SQL*Plus com uma conta administrativa, execute a seguinte consulta de encontra a view DBA_USERS_WITH_DEFPWD

SQL> SELECT * FROM DBA_USERS_WITH_DEFPWD;

USERNAME
------------------------------
DIP
OUTLN
ORACLE_OCM
APPQOSSYS

SQL> select username, account_status from dba_users where username in (select username from dba_users_with_defpwd);

USERNAME                       ACCOUNT_STATUS
------------------------------ --------------------------------
APPQOSSYS                      EXPIRED & LOCKED
ORACLE_OCM                     EXPIRED & LOCKED
DIP                            EXPIRED & LOCKED
OUTLN                          OPEN

A primeira consulta, mostra que temos a lista completa dos usuários em que a senha padrão está definida. Na segunda consulta, é informado que apenas o usuário OUTLN que tem uma senha padrão está com o status da conta habilitado.

Mesma com uma conta bloqueada, deixar o usuário com uma senha padrão pode ser muito perigoso, imagina se alguém habilita uma dessas contas sem querer e não troca a senha?

Para mudar a senha não é segredo:

SQL> PASSWORD OUTLN
Changing password for OUTLN
New password: *********
Retype new password: ************
Password changed

São maneiras simples como essa que podem te livrar de uma dor de cabeça incrível. O DBA devem estar atento a tudo, inclusive a pequenos detalhes como este. Nem quero pensar que uma conta dessas caia em mãos erradas, imagina que uma conta dessas com privilégio administrativo, o de create/drop tablespaces por exemplo, esteja com a conta habilitada e password default e algum abelhudo consegue conectar com essa conta, já penso o estrago? …

É! … você pode dar adeus ao seu banco e rezar para ter backup …

Protegendo o Oracle – Parte 1
October 10, 2012

Essa é o início de uma série de artigos sobre proteção e segurança no banco de dados Oracle. Hoje estaremos falando sobre o controle de acesso ao dicionário de dados através do parâmetro de inicialização O7_DICTIONARY_ACCESSIBILITY.

De acordo com a documentação Oracle, esse parâmetro controla as restrições no privilégio de sistema. Caso esse parâmetro esteja habilitado (true) o acesso aos objetos SYS (consequentemente ao dicionário de dados) é permitida.

Vamos a um exemplo, veja que o parâmetro O7_DICTIONARY_ACCESSIBILITY está definido como false (padrão), assim mesmo que o usuário tenha privilégio de SELECT ANY TABLE ele não consegue acessas as tabelas do SYS. O mesmo vale para o privilégio EXECUTE ANY PROCEDURE, que permite executar qualquer procedure exceto as do usuário SYS, caso o parâmetro O7_DICTIONARY_ACCESSIBILITY esteja como false.

FSOARES@dbtst> create user usr1 identified by oracle;

User created.

FSOARES@dbtst> grant connect, resource to usr1;

Grant succeeded.

FSOARES@dbtst> grant select any table to usr1;

Grant succeeded.

FSOARES@dbtst> show parameter o7
NAME                                            TYPE        VALUE
---------------------------------------------- ----------- -------
O7_DICTIONARY_ACCESSIBILITY                    boolean     FALSE

Veja que criamos um usuário chamado usr1 e definimos a ele a permissão de SELECT ANY TABLE, porém o parâmetro O7_DICTIONARY_ACCESSIBILITY está definido como false, veja o que acontece caso o usuário USR1 tente selecionar qualquer tabela do usuário SYS.


USR1@dbtst> select name, password from sys.user$;
select name, password from sys.user$
                               *
ERROR at line 1:
ORA-00942: table or view does not exist

Mesmo com o privilégio SELECT ANY TABLE o usuário USR1 não consegue acessar as informações do schema SYS.

Vamos agora, inverter os papéis agora. Com o parâmetro O7_DICTIONARY_ACCESSIBILITY como true vamos ver o que acontece com as permissões no dicionário de dados:

SQL> alter system set O7_DICTIONARY_ACCESSIBILITY=TRUE scope=spfile;

System altered.

SQL> shut immediate
Database closed.
Database dismounted.
ORACLE instance shut down.

SQL> startup
ORACLE instance started.

Total System Global Area  845348864 bytes
Fixed Size		    1348216 bytes
Variable Size		  465571208 bytes
Database Buffers	  373293056 bytes
Redo Buffers		    5136384 bytes
Database mounted.
Database opened.

SQL> show parameter O7_DICTIONARY_ACCESSIBILITY

NAME				     TYPE	 VALUE
------------------------------------ ----------- -----
O7_DICTIONARY_ACCESSIBILITY	     boolean	 TRUE

USR1@dbtst> select name, password from sys.user$;

NAME                           PASSWORD
------------------------------ --------------------
SYS                            8A8F025737A9097A
PUBLIC
CONNECT
RESOURCE
DBA
SYSTEM                         2D594E86F93B17A1
SELECT_CATALOG_ROLE
EXECUTE_CATALOG_ROLE
DELETE_CATALOG_ROLE
OUTLN                          4A3BA55E08595C81
EXP_FULL_DATABASE
IMP_FULL_DATABASE
LOGSTDBY_ADMINISTRATOR
DBFS_ROLE
DIP                            CE4A36B8E06CA59C
AQ_ADMINISTRATOR_ROLE
AQ_USER_ROLE
DATAPUMP_EXP_FULL_DATABASE
DATAPUMP_IMP_FULL_DATABASE
ADM_PARALLEL_EXECUTE_TASK
GATHER_SYSTEM_STATISTICS
JAVA_DEPLOY
ORACLE_OCM                     5A2E026A9157958C
..
HR                             6399F3B38EDF3288
OE                             9C30855E7E0CB02D
IX                             2BE6F80744E08FEB
SH                             9793B3777CD3BD1A
PM                             72E382A52E89575A
BI                             FA1D2B85B70213F3
FSOARES                        3B789FED9DDFE9B9
USR1                           8FFA74CCAD48CE21
USR2                           6102DC4A88E79D5A

Com a conclusão dos testes acima, fica claro a grande necessidade de deixar o parâmetro O7_DICTIONARY_ACCESSIBILITY sempre como false, permitindo que qualquer sessão não pode obter informações sigilosas que são destinadas apenas ao Oracle e do DBA.

Movendo a tabela AUD$
October 10, 2012

Dependendo do nível e da quantidade de auditoria habilitada no banco de dados, os registros criados pelos audit trail, que geralmente são armazenados no banco através da tabela AUD$ pertencente ao schema SYS que consequentemente pertence ao tablespace SYSTEM, pode levar a números exorbitantes no tamanho desse tablespace.

Para mais informações precisas de auditoria, o Oracle fornece um controle ainda maior através do “Fine Grained Auditing” feature disponível para o Oracle 11g (estarei falando dela em breve). Com esse tipo de auditoria disponível um outra tabela é utilizada para armazenar as ações auditadas que é a FGA_LOG$ disponível também sobre o schema SYS.

Um procedimento muito interessante, antes da tabelas AUD$ e FGA_LOG$ do schema SYS começarem crescerem, recomendasse muda-lás para um outro tablespace de dados qualquer.

Esse metodo se faz interessante, já que se o tablespace SYSTEM crescer por causa dessas tabelas de auditoria o seu banco de dados pode parar caso o tablespace não encontre mais espaço para estender. Já com as tabelas de auditória fora do tablespace SYSTEM esse risco diminui.

Uma outra vantagem é a manutenção, já que caso alguma atividade (como shrink, move, etc …) seja necessária, ela será muito mais simples de ser executada caso for fora do tablepsace SYSTEM.

Segue o passo a passo para mudar a tabela AUD$ de tablespace:

oracle@oracle11g ~]$ sqlplus / as sysdba

SQL*Plus: Release 11.2.0.3.0 Production on Tue Oct 9 23:42:18 2012

Copyright (c) 1982, 2011, Oracle.  All rights reserved.

Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQ> create tablespace "AUDIT" datafile '/u01/app/oracle/oradata/dbtst/audit_01.dbf' size 1G;

Tablespace created.

SQL> create table audx tablespace "AUDIT" 
  2  storage (initial 50k next 50k pctincrease 0)
  3  as select * from aud$ where 1 = 2; 

Table created.

SQL> rename AUD$ to AUD$$;

Table renamed.

SQL> rename audx to aud$;

Table renamed.

SQL> create index i_aud2
  2  on aud$(sessionid, ses$tid)
  3  tablespace "AUDIT" storage(initial 50k next 50k pctincrease 0);

Index created.

SQL> select tablespace_name from dba_tables where owner='SYS' and table_name='AUD$';

TABLESPACE_NAME
------------------------------
AUDIT