Lato Sensu em Perícia Digital
FORENSE EM BANCO DE DADOS: FERRAMENTAS DE
PERÍCIA DIGITAL APLICADA A BANCO DE DADOS ORACLE
Brasília - DF
2010
Autor: Marco Antônio de Souza Barretto
Orientador: Paulo Roberto Corrêa Leão
FORENSE EM BANCO DE DADOS: FERRAMENTAS DE PERÍCIA DIGITAL APLICADA A BANCO DE DADOS ORACLE
Artigo apresentado ao curso de pós-graduação em Perícia Digital da Universidade Católica de Brasília, como requisito parcial para obtenção do Título de Especialista em Perícia Digital. Orientador: Prof. Msc. Paulo Roberto Corrêa Leão
Brasília 2010
Artigo de autoria de Marco Antônio de Souza Barretto, intitulado ―FORENSE EM BANCO DE DADOS: FERRAMENTAS DE PERÍCIA DIGITAL APLICADA A BANCO DE DADOS ORACLE‖, apresentado como requisito parcial para obtenção do grau de Especialista em Perícia Digital da Universidade Católica de Brasília, em 12/11/2010, defendido e aprovado pela banca examinadora abaixo assinada:
______________________________________________ Prof. Msc. Paulo Roberto Corrêa Leão
Orientador
Pós-Graduação em Perícia Digital – Universidade Católica de Brasília - UCB
______________________________________________ Prof. Msc Laerte Peotta
Pós-Graduação em Perícia Digital – Universidade Católica de Brasília - UCB
Brasília 2010
MARCO ANTONIO DE SOUZA BARRETTO FORENSE EM BANCO DE DADOS ORACLE
Resumo:
Atualmente, todas as organizações possuem grande volume de dados e informações que precisam ser armazenadas com segurança. Qualquer empresa que pretenda garantir um controle efetivo sobre todo o seu negócio tem obrigatoriamente de recorrer a um sistema gerenciador de banco de dados – SGDB – e garantir a consistência e confiabilidade dos dados. Este artigo tem como objetivo relacionar as principais ferramentas de perícia digital que podem ser aplicadas na segurança de um SGBD Oracle.
Palavras-chave: Perícia Digital. Forense Oracle. Ferramentas de Pericia aplicadas a banco de dados.
1. INTRODUÇÃO
Para proteger um dos recursos mais vitais de uma empresa – seus dados – um administrador de banco de dados (DBA) precisa estar ciente da maneira como o banco de dados protege os dados corporativos e as diferentes ferramentas e mecanismo que podem ser utilizados para recuperar dados perdidos e alterados.
Os sistemas gerenciadores de banco de dados (SGBD) são peças fundamentais em um ambiente que provê informações. Estes sistemas conjuntamente com os sistemas operacionais devem prover segurança às informações de uma empresa.
O SGDB não depende somente de si mesmo para garantir integridade e consistência dos dados armazenados. Se o acesso ao sistema operacional não for seguro ou o hardware físico não estiver em uma localização segura, toda a segurança implementada no SGBD estará comprometida.
Visando proteger os dados armazenados em um SGBD, o trabalho proposto tem como objetivo elencar as diversas ferramentas em perícia digital que podem ser utilizadas para assegurar a confiabilidade dos dados armazenados em um servidor de banco de dados oracle.
Todas as ferramentas serão usadas na implementação da segurança e na coleta de evidências em um SGBD Oracle residido em um Sistema Operacional Linux.
1.1. METODOLOGIA
Com base em um Sistema Gerenciador de Banco de Dados - SGBD - Oracle foi feito um levantamento dos componentes onde poderiam ser encontradas evidências de prática de um delito criminal. De acordo com a pesquisa foi definido as seguintes estruturas que compõem um servidor de banco de dados oracle: Logs do sistema operacional, logs do Listener, Logs do SQL NET, logs de auditoria do Banco, arquivos de dados, arquivos de Redo Log, arquivos de Redo Log Arquivados, arquivos de controle, views Internas do SGBD e estruturas de memória do servidor. Para o desenvolvimento e o embasamento teórico do trabalho, recorreu-se ao método de pesquisa bibliográfica, mediante informações contidas em
livros e artigos publicados, além de consultas aos sites disponíveis na internet que tratam do assunto.
O artigo esta dividido em duas partes: Funcionamento da Arquitetura Oracle e componentes que podem ser periciados com ferramentas de perícia digital.
O primeiro capítulo destina-se a apresentar, de modo geral, o funcionamento do SGBD Oracle e sua arquitetura, a fim de complementar o entendimento sobre as estruturas que podem ser
periciadas. O segundo capítulo apresenta a utilização de ferramentas para coleta de informações em um SGBD Oracle.
Com base nas estruturas contidas em um servidor de banco de dados oracle será feito uma análise de qual ferramenta pode ser usada para extrair as informações necessárias que sirvam como evidência em uma investigação pericial.
2. REFERENCIAL TEÓRICO
2.1. ENTENDENDO A ARQUITETURA DE UM SGBD ORACLE
Um Sistema Gerenciador de Banco de Dados Oracle (SGBD) é formado basicamente por dois termos que são usados muitas vezes como se fossem estruturas idênticas, mas que são entidades muito distintas. O SGBD Oracle é composto de uma instância e de um banco de dados, como apresenta a Figura 1.
Figura 1 – Componentes de um SGBD Oracle 10g.
2.1.1. Instância Oracle
A instância Oracle é formada pela SGA (System Global Area) e os processos de segundo plano. A SGA é uma parte alocada na memória do servidor que juntamente com os processos de segundo plano interagem com os arquivos de banco de dados. Quando uma instância Oracle é iniciada, a memória é alocada para a SGA com base nos valores contidos no arquivo de parâmetro.
A instância Oracle é composta de:
a) Processos de segundo plano: que é o canal entre a memória e as estruturas físicas: Os processos de segundo plano obrigatórios: SMON, PMON, DBW0, LGWR
e CHKP:
SMON – System Monitor. Em caso de uma queda de sistema ou falha na instância devido a falta de energia ou problemas na CPU, o processo realiza a recuperação após a falha, aplicando as entradas nos arquivos de redo log on-line aos arquivos de dados;
PMON – Process Monitor. Se uma conexão do usuário for descartada, ou caso o processo de usuário falhe, o pmon fará o trabalho de reverter a transação que estava sendo feita, remover os bloqueio sobre as linhas usadas na tabela, remover o ID do processo dos usuários fornecer informações sobre o status da instância para solicitações de conexão entrantes;
DBW0 – grava os buffers sujos do Buffer Cache do banco de dados nos arquivos de dados. Ele garante que um número suficiente de buffers livres esteja disponível no Buffer Cache de buffer. O desempenho do banco de dados é melhorado, porque os processos de servidor efetuam alterações somente no cache de buffer (Estrutura de Memória da SGA). O LGWR – executa gravações seqüenciais do buffer de redo log
(estrutura de memória da SGA) no arquivo de redo log nas situações a seguir:
- Quando uma transação efetua commit; - Quando 1/3 do buffer de redo log está cheio;
- Quando há mais de um megabyte de alterações registradas no buffer de redo log;
- Antes de o DBW0 gravar blocos modificados do cache de buffer do banco de dados nos arquivos de dados; e
- Como o redo é necessário para a recuperação, o LGWR confirma o COMMIT somente após o redo estar gravado em disco;
CHKP – no processo de check point vários buffers de banco de dados sujos incluídos no log que está sendo submetido a um checkpoint são gravados nos arquivos de dados pelo DBWn. O processo CKPT atualiza os cabeçalhos de todos os arquivos de dados e arquivos de controle para que reflitam a conclusão com êxito. Ele faz com que os arquivos de dados, controle e redo fiquem sincronizados com o mesmo SCN (System Change Number). O SCN é um número gerado internamente pelo Oracle para controlar a consistência dos arquivos. Um arquivo que não esteja com o mesmo SCN dos demais, torna-se um arquivo corrompido.
Os processos de segundo plano facultativos : ARCn, LMDn, RECO, CJQ0, LMON, Snnn, Dnnn, Pnnn, LCKn, QMNn:
A área de memória alocada à SGA (System Global Area): ela é alocada na inicialização da instância e representa um componente fundamental de uma instância Oracle. É constituída de várias áreas da memória:
A área de memória compartilhada;
O cache dos buffers do banco de dados;
O buffer de log;
A área de memória alocada à PGA (Program Global Area): ela é alocada no início do processo do servidor. Ela é reservada a todos os processos do usuário que se conecte ao banco de dados Oracle e liberada, no fim do processo;
Processo do Usuário: é o processo que requer uma interação com o banco de dados, iniciando uma conexão. Ele só se comunica com o processo do servidor correspondente;
Processo do servidor: representa o programa que entra em interação, diretamente, com o servidor Oracle. Ele responde a todas as consultas (ou pedidos) e retorna os resultados. Ele pode ser dedicado a um servidor cliente ou compartilhado entre vários;
2.1.2. Banco de dados Oracle
Um banco de dados – BD - é uma coleção de dados armazenados em disco e formado por um ou mais arquivos em um servidor de banco de dados que tem como objetivo coletar e gerenciar as informações relacionadas. O BD possui uma estrutura lógica e física.
2.1.3. Estrutura lógica
O SGBD Oracle possui diversos componentes que formam a estrutura lógica de um SGBD Oracle que são denominados Objetos do Banco de Dados. As principais estruturas lógicas são:
Tabela – é a unidade básica de armazenamento em um SGBD Relacional. É formada por linhas e colunas, onde as linhas representam os registros e as colunas os campos da tabela. Sem a existência de tabelas, um banco de dados não terá nenhum valor para uma empresa;
Índice – Quando criamos índices para uma tabela, especificando uma coluna, a tabela é classificada de uma forma que, sempre que for executada uma consulta (query), o sistema usará o índice para ter acesso direto e mais rápido aos dados desejados;
Tablespace – é um objeto de gerenciamento de espaço lógico que guarda os arquivos de dados no Banco de dados Oracle. Os tablespaces ajudam a reduzir a disputa de I/O em disco e a gerenciar o espaço em disco. O SGBD Oracle gerencia os arquivos de dados agrupando-os em um ou mais tablespace;
Segmentos – Os objetos do banco de dados, como tabelas e índices, são armazenados nos tablespaces como segmentos. Cada segmento contém uma ou mais extensões. Uma extensão consiste em blocos de dados contíguos, ou seja, cada extensão somente pode existir em um arquivo de dados. Os blocos de dados representam a menor unidade de entrada/saída no banco de dados;
Usuários e esquemas – o acesso a banco de dados é concedida a uma conta de banco de dados que é chamado de usuário. Entretanto, se o usuário criar e possuir objetos no BD esses objetos farão parte de um esquema. Um esquema pode possuir qualquer tipo de objeto no banco de dados: tabelas, índices, procedures, views, etc. O proprietário ou DBA pode conceder acesso para esses objetos a outros usuários; e
Perfis ou profiles – é um conjunto de limites de recursos atribuídos a um ou mais usuários.
2.1.4. Estrutura física
A estrutura física de um banco de dados Oracle é formada por arquivos de banco de dados e arquivos de externos. O arquivo de banco de dados contém dado e metadados; e o externo contém parâmetros de inicialização, informações de log de registro, etc.
Os arquivos internos são:
Arquivos de controle – é um arquivo onde fica armazenado o status e a estrutura física de um banco de dados. O arquivo de controle é obrigatório para o funcionamento de um SGBD Oracle;
Arquivos de dados - é um arquivo físico armazenado no sistema operacional, onde são estão localizados as tabelas, índices, views, procedures e esquemas do usuário;
Arquivos de redo logs – é um arquivo que armazena as mudanças efetuadas no banco de dados para possibilitar a recuperação dos dados em caso de falhas. Um banco de dados Oracle deve possuir no mínimo dois arquivos de redo log; Os arquivos externos: arquivos de parâmetro, arquivos de senha, arquivos de
alert, arquivos de rastreamento, arquivos de redo log arquivados; e
Arquivos de parâmetro – contém informações dos parâmetros de inicialização de um banco.
2.2. ESTRUTURAS DO SGBD ORACLE PARA COLETA DE EVIDÊNCIAS
2.2.1. Arquivos de dados
O arquivo de dados é um binário onde são armazenado os dados (Tabelas, índices, views, etc). Cada banco de dados oracle deve ter pelo menos um arquivo de dados. Ele corresponde a um arquivo físico armazenado no sistema operacional. Todos os arquivos de dados que compõem um servidor devem estar sincronizados com o mesmo SCN (System Change Number) que serve para controlar a integridade do arquivo com os demais existentes.
A falta de sincronismo entre os arquivos faz com o que o servidor de banco de dados não funcione adequadamente, tornando o arquivo de dados corrompido.
2.2.2. Arquivos de controle
Cada servidor Oracle possui pelo menos um arquivo de controle que mantém os metadados da estrutura física do banco de dados. Ele contém o nome do banco de dados, a data de criação do banco de dados, os nomes e localização de todos os arquivos de dados e arquivos de redo log. Além disso, o arquivo de controle contém as informações utilizadas pelo Recovery Manager - RMAN - (ferramenta Oracle usada para gerenciar os backups de um servidor). O arquivo de controle é crucial para o funcionamento do banco de dados. E esta associado a apenas uma instância do SGBD.
2.2.3. Arquivos de redo log arquivados
Os arquivos de redo log online armazenam os registros de cada transação efetuada no banco de dados. O SGBD Oracle registra de forma sequencial até que ele esteja totalmente preenchido e em seguida passa para outro arquivo de redo log online.
Quando o servidor Oracle esta sendo executado no modo ARCHIVELOG (padrão para banco de dados de produção) o servidor faz uma cópia de cada arquivo de redo log online após ele estar preenchido, arquivando-o em um dispositivo de disco, caso seja necessário fazer uma recuperação pontual em um BD.
2.2.4. Listener
O listener é um processo executado no Servidor Oracle. O processo recebe solicitações de conexão e gerencia o tráfico das requisições no servidor de banco de dados. A falta do processo ouvinte (listener) impede que um cliente estabeleça conexão com o servidor. Toda requisição do cliente é verificado pelo listener, O arquivo de configuração é chamado listener.ora e está localizado por default no diretório $ORACLE_HOME/network/admin.
O arquivo de configuração contém as seguintes informações: O nome do listener;
O endereço do listener;
Os bancos de dados que utilizam o listener; O protocolo de endereçamento;
O diretório que será gravado o arquivo de log do listener (caso não seja informado a localização, o servidor Oracle assume o valor padrão que é $ORACLE_HOME/network/log); e
Entre outros parâmetros. .
2.2.4.1 Arquivo de log do Listener
O arquivo de log do listener contém informações de todas as solicitações enviadas do cliente para acesso ao servidor de banco de dados. No arquivo podemos encontrar os seguintes dados:
Nome da Instância acessada;
Nome do programa cliente que efetuou a conexão; Nome do host que executou o programa;
Protocolo usado na conexão; IP usado pelo cliente;
Porta do cliente; e Resultado da conexão.
Exemplo de um arquivo de log de listener: 24-SEP-2010 18:52:22 * (CONNECT_DATA=(SID=THOR2)(CID=(PROGRAM=D:\orant\BIN\ifrun60.EXE) (HOST=MET-DAMIAO)(USER=dorinha))) * (ADDRESS=(PROTOCOL=tcp)(HOST=192.168.99.69)(PORT=1977)) * establish * THOR2 * 0 2.2.5. SQL NET
Net8 (chamado antes do Oracle versão 8) é um produto de camada intermediária que oferece conexão de forma transparente entre aplicações cliente com o banco de dados ou conexão entre dois banco de dados.
A principal função do Net8 é estabelecer uma sessão entre o cliente e o servidor e transferir dados entre eles. Uma vez estabelecida a sessão o Net8 gerencia a transferência de dados entre o banco e o cliente.
O serviço Oracle Net gera informações para entender e diagnosticar problemas de rede, através de arquivos de log e rastreamento.
Qualquer falha de conexão é inserida nos arquivos de log, e contém o numero do erro e a descrição do erro. Com isso é possível descobrir se é um erro de software, sistema operacional ou rede. Testando as várias camadas de rede em muitos casos, é possível descobrir qualquer problema de rede. É possível descobrir tentativas de conexões não sucedidas de um cliente e com isso detectar uma tentativa de invasão ao banco de dados.
2.2.6. Logs de Alerta
É um arquivo de log que contém informações cronológicas de erros e ações efetuadas pelo usuário SYSDBA. Algumas das informações contidas nos log de alerta são: data e hora da inicialização/desativação do banco, erros internos do Oracle, arquivos de dados deletados ou corrompidos, criação de novos arquivos de dados, alteração na estrutura do banco de dados.
Os arquivos de alerta são criados pelo SGBD quando o mesmo for deletado ou movido do local que reside. Em um arquivo de alert podemos encontrar dados referentes a:
Inicialização e desativação de uma instância Oracle; Erros que geram arquivos de rastreamento;
Criação, Alterações e deleção de banco de dados, tablespaces e segmentos de rollback;
Erros internos da Oracle (ora-00600); e Erros de corrupção de blocos.
Em uma perícia de banco de dados, podemos analisar o arquivo de alert e saber, por exemplo, se os dados foram apagados (deleção de um tablespace) ou se o banco de dados foi desativado para alguma alteração que comprometa a integridade dos dados.
2.2.7. Os Logs do Sistema Operacional
Os logs do sistema operacional geralmente são arquivos texto (ASCII) que contém informações importantes para uma investigação.
No linux por padrão os logs estão localizados no diretório /var/log. Mais fácil, porém, é a analise de /etc/syslog.conf, arquivo de configuração dos logs do Sistema Operacional, que indica onde os arquivos de log estão armazenados. Ainda em /etc/passwd é possível identificar se o invasor criou alguma conta não conhecida pelo administrador de rede
Para efeito de uma perícia em banco de dados, deve-se saber quais serviços, além do banco de dados é usado no servidor. A partir desse levantamento podemos identificar os logs em que pode-se encontrar evidências.
Os principais logs contidos no S.O. são:
/var/log/messages = Contém registros de acesso ao sistema e em alguns casos registros do IPTABLES;
/var/log/samba/log.smbd = Contém os logs do Servidor de Arquivos SAMBA; /var/log/httpd/(access, error ou agent.log) = Logs do Servidor Web Apache;. /var/log/lpr.log = Informações de acesso às impressoras; e
/etc/mail/maillog = Arquivo que registra os logs do Servidor de E-mails.
3. PERÍCIA DIGITAL APLICADAS NO SGBD ORACLE
3.1. FERRAMENTAS
O perito digital é o profissional que tem o objetivo de coletar evidências em equipamentos eletrônicos a fim de comprovar alguma invasão e comprometimento dos serviços informatizados de uma empresa. As ferramentas descritas neste trabalho são capazes de auxiliar na recuperação de informações, além de informar quando, onde e como os fatos ocorreram.
3.1.1 Openvas
Vulnerabilidade é definida como uma falha no projeto, implementação ou configuração de um software ou sistema operacional que, quando explorada por um atacante, resulta na violação da segurança de um computador.
Existem casos onde um software ou sistema operacional instalado em um computador pode conter uma vulnerabilidade que permite sua exploração remota, ou seja, através da rede. Portanto, um atacante conectado à Internet, ao explorar tal vulnerabilidade, pode obter acesso não autorizado ao computador vulnerável.
Em um ambiente de servidor de banco de dados, faz-se necessário checar as vulnerabilidades contidas não só no servidor de banco de dados, mas em todas as aplicações usadas para acesso de usuário e no sistema operacional usado pelo SGBD.
OPENVAS é uma ferramenta de varredura de vulnerabilidade que inclui uma interface gráfica de usuário e várias aplicações de segurança de terceiros. Com o uso do OPENVAS podemos garantir a segurança tanto no nível de banco de dados, sistema operacional e aplicações que acessam o SGBD.
Openvas pode ser aplicado em uma perícia em banco de dados checando vulnerabilidades do sistema operacional em que reside o SGBD, as vulnerabilidades do próprio SGBD e as aplicações usadas para se conectar com o banco (servidor web, servidor de aplicações). Openvas é formado por três componentes principais:
OpenVAS Server — é um scanner que executa testes de vulnerabilidade em redes. Ele usa om protocolo de comunicação específico para isso. Os testes são implementados em forma de plugins que podem ser atualizados para cobrir falhas de segurança descobertas recentemente;
A versão OpenVAS-Client traz um terminal e uma aplicação GUI client application for both OpenVAS and Nessus.
Ele implementa o Nessus Transfer Protocol (NTP). A GUI é implementada usando GTK+ 2.4 e permite gerenciar as sessões de escaneamento de vulnerabilidades. OpenVAS-Client é um sucessor do NessusClient 1.X; e
O OpenVAS NVT Feed – este é um public feed do Network Vulnerability Tests (NVTS). Ele contém somente a assinatura dos arquivos e somente suporta NVT families e suas dependências.
Os plug-ins do OPENVAS são escritos normalmente em NASL (Nessus Attack Scripting Language), linguagem nativa do nessus, desenvolvida especificamente para testes de vulnerabilidade. Cada NVT é específico para uma determinada vulnerabilidade conhecida ou para testar as melhores práticas do mercado. Os NVTs efetuam o teste através do envio de um código específico para o alvo, comparando os resultados com as vulnerabilidades armazenadas e conhecidas por este plug-in. Além do NASL existem scripts em C e Perl com finalidades específicas que não podem ser feitas facilmente utilizando o NASL.
Isto não quer dizer que você está limitado a lista de plug-ins existentes, podendo escrever um plug-in específico para sua empresa utilizando o NASL. Os plug-ins do OPENVAS são semelhantes às definições da maioria dos antivírus e o update deve ser feito com freqüência, visto que novas vulnerabilidades são descobertas todos os dias.
3.1.2 Logminer
Nem todo banco de dados tem uma política de segurança com informações referentes a alterações realizadas no banco de dados. Com isso não podemos contar com recursos de auditoria, pois estes muitas vezes não estão ativados.
O LogMiner é uma ferramenta importante em situações que seja necessário obter informações de alguma alteração realizada na base de dados. Esse recurso permite que sejam recuperados os comandos DDL e DML que foram executados na base e ainda fornece algumas informações históricas desses comandos. As informações das alterações efetuadas
ficam armazenadas nos arquivos de REDO e nos arquivos de ARCHIVE (registros mais antigos). Esses arquivos fazem parte de um SGBD Oracle e de uso obrigatório.
A funcionalidade LogMiner está disponível através de uma interface de linha de comando ou através do Oracle LogMiner Viewer interface gráfica do usuário (GUI).
Os arquivos de REDO contem todas as informações necessárias para rastrear qualquer DML e DDL executadas no banco de dados, a ordem em que elas foram executadas, e quem as executou servindo como evidência precisa em uma investigação pericial.
3.1.3. GREP
Grep é um binário encontrado na maioria das distribuições Linux. Grep é um comando utilitário de linha de pesquisa de texto originalmente escrito para Unix. O nome foi tirado das primeiras letras da expressão global/regular expression/print. O comando grep procura arquivos ou a entrada padrão para as linhas que combinam com uma determinada expressão regular, e os imprime na saída padrão do programa.
Este programa é uma ferramenta poderosa para uma investigação forense. Através desse comando podemos fazer buscas textuais em um arquivo e com os variados parâmetros encontrar indícios que estejam sendo procurados.
Um exemplo que podemos citar é a busca de um IP suspeito no arquivo listener.log: more $ORACLE_HOME/network/log/listener.log|grep 192.168.99.145|grep PORT=4277 13-AUG-2010 11:45:50 * (CONNECT_DATA=(SID=prodB)(SERVER=DEDICATED)(CID=(PROGRAM=C :\Arquivos de programas\Oracle\jre\1.1.8\bin\jrew.exe)(HOST=DPINF111)(USER=Administrado r))) * (ADDRESS=(PROTOCOL=tcp)(HOST=192.168.99.145)(PORT=4277)) * establish * prodB * 0 3.1.4. Strings
O comando strings faz parte do pacote bin-utils do linux. Este programa pode ser utilizado em análise de dump de memória. Seu principal uso é para extrair texto de arquivos binários (arquivos, ou seja, não-texto). Por exemplo, os caracteres utilizados pelo idioma Português constituída pelas letras do alfabeto, números, sinais de pontuação e uma variedade de símbolos. caracteres imprimíveis são aqueles que realmente mostram na tela de um monitor, ao contrário daqueles que executam outras funções, tais como indicar uma nova linha ou uma tabulação. Uma string é qualquer seqüência finita de caracteres.
A sintaxe básica do comando strings é
strings [options] nome_do_arquivo_binário
Ele faz buscas por conjuntos de caracteres em um arquivo binário e em conjunto com o comando grep torna-se uma ferramenta robusta para coletar evidências nos arquivos de dados e nos arquivos de controle.
3.1.5. Sleuth Kit
Sleuth Kit é um conjunto de ferramentas que podem ser utilizadas em qualquer ambiente Unix e Linux. Através dela podemos recuperar arquivos deletados ou sobrescritos parcialmente.
Apesar de a ferramenta ser usada em ambiente Unix e Linux, podemos fazer análise de uma imagem de sistema operacional Windows (NTFS/FAT).
Para recuperar um arquivo, é preciso descobrir o inode correspondente ao arquivo que se deseja recuperar. Se não for possível descobrir o inode, talvez possa ser recuperadas apenas partes do arquivo. Existem também ferramentas que varrem o disco inteiro em busca de informações sobre arquivos apagados. Em último caso é possível varrer o disco com ferramentas que buscam por sequências de bits (em hexadecimal).
Para recuperar um arquivo que não tenha sido sobrescrito, o procedimento é o seguinte:
Encontrar o inode onde o arquivo estava armazenado. O comando abaixo lista todos os arquivos da imagem que foram removidos. Dessa forma podemos encontrar o inode do arquivo que interessa.
fls -adpr imagem_comprometida.iso
Descubrir mais informações sobre o arquivo. Com o inode, podemos utilizar o comando istat para descobrir os blocos onde este arquivo está armazenado.
istat imagem_comprometida.iso 43121
Encontrar o nome original do arquivo. Com o ffind podemos descobrir o nome original do arquivo, caso ele tenha sido realocado.
ffind -a imagem_comprometida.iso 43121
Recuperar o arquivo armazenado no inode encontrado. Através do arquivo icat pode-se recuperar o arquivo original
icat imagem_comprometida.iso 43121 > tnsnames.log
Para recuperar o arquivo, primeiramente precisamos diminuir a região onde vamos procurar pelas partes do arquivo. Como ele foi removido, é muito provável que o arquivo está armazenado nos blocos não alocados do disco. Isto é feito através do comando dls, que extrai o espaço não alocado da imagem original:
dls -f linux-ext2 imagem_comprometida.iso > imagem_comprometida.iso.dls Depois, é necessário procurar o conteúdo que interessa. Para isto podemos
utilizar uma ferramenta como o grep, conforme exemplo: grep -ab "rm -fr" imagem_comprometida.iso.dls
Após descobrir a posição na imagem de dados desalocados, utilizamos o dcalc para encontrar a posição na imagem original:
echo $((66511837/4096)) 16238
dcalc -u 16238/imagem_comprometida.iso
Caso o bloco não seja alocado por nenhum inode, podemos recuperar os blocos de dados que conseguirmos através do comando:
- ifind -a -d 39342 imagem_comprometida.iso
Se o ifind não encontrar nenhum inode apontando para este bloco de disco, será necessário recuperar bloco a bloco, até conseguir toda informação possível do arquivo. Em alguns casos, é possível identificar o tipo do arquivo, e baseado na assinatura do arquivo,
encontrar o início e o fim do mesmo.
Vale lembrar que o sistema operacional normalmente tenta alocar blocos consecutivos para um arquivo. Por isso é possível recuperar um arquivo ao recuperar os blocos. Porém, caso o arquivo esteja armazenado em blocos não consecutivos, talvez não seja possível recuperar o arquivo inteiro.
3.2. Utilização das ferramentas
As ferramentas citadas foram usadas em um ambiente de testes configurado com o Oracle Enterprise Server 10g e sistema operacional Red Hat Entreprise Server 5.1.
O camando grep foi testado em buscas textuais em arquivos de logs do sistema operacional, logs de listener, log de alerta, log SQL NET e log tnsnames.
Os arquivos de dados e arquivo de controle foram usados o comando grep em junto com o comando strings, pois os mesmos são arquivos binários mantidos pelo SGBD Oracle. O pacote Sleuth Kit foi útil na procura de arquivos físicos armazenados no servidor que foram apagados do disco.
Openvas foi importante para a manutenção preventiva do ambiente, mostrando as vulnerabilidades das aplicações contidas no servidor, permitindo com isso a aplicação dos patches (correções) de segurança disponibilizados pelos fabricantes dos softwares utilizados.
3.3. Auditoria em banco de dados Oracle.
O SGBD Oracle usa diferentes métodos de auditoria para monitorar quais tipos de privilégios são utilizados e quais objetos foram acessados.
Os tipos de auditoria em um banco de dados Oracle 10g são:
Auditoria de Instruções – audita as instruções SQL pelo tipo de instrução independente dos objetos de esquema que estão sendo acessados;
Auditoria de privilégios – audita os privilégios concedidos a um ou mais usuário;
Auditoria de objetos de esquemas – audita as instruções que operam em um específico objeto; e
Auditoria refinada – Audita o acesso à tabela e privilégios sobre a tabela com base no conteúdo de objetos que estão sendo acessados.
Todos os tipos de auditoria utilizam o comando audit para ativar a auditoria e noaudit para desativar. Às vezes, queremos auditar ações bem sucedidas, para esse fim usamos a clausula whenever sucessfull. Outras vezes, só nos importa as instruções que falharam. Para estes usamos a clausula whenever not sucessfull.
O resultado de uma auditoria é encontrado na visão de dicionário de dados DBA_AUDIT_TRAIL. Nesta view encontramos as seguintes informações: usuário auditado, data do evento, objeto acessado, ação do usuário, instrução sql executada.
As Views de dicionário de dados relacionadas à auditoria estão descritas no Quadro 1.
Quadro 1 - Views de dicionário de dados
View de dicionário de dados Descrição
AUDIT_ACTIONS contém informações para os códigos do tipo de ação como: INSERT, DROP VIEW, DELETE, LOGON e
DBA_AUDIT_OBJECTS Registros da trilha de auditoria referentes a objetos do banco de dados.
DBA_AUDIT_POLICIES Diretivas de auditoria refinada no banco de dados DBA_AUDIT_SESSION Todos os registros da trilha de auditoria relacionado a
CONNECT e DISCONNECT
DBA_AUDIT_STATEMENT Entradas na trilha de auditoria referentes a comandos
GRANT, REVOKE, AUDIT, NOADUDIT e ALTER SYSTEM
DBA_AUDIT_TRAIL Contém entradas na trilha de auditoria padrão. USER_AUDIT_TRAIL contém as linhas de auditoria somente para usuários conectados
Fonte: Oracle 10g – Manual do DBA
4. CONCLUSÃO
O crescimento no uso de programas corporativos tem impulsionado a preocupação com a segurança dos dados. Vazamento de informações sigilosas em sistemas corporativos governamentais e privados tem acarretado enormes prejuízos para sociedade e isso é cada vez mais comum.
Os profissionais Oracle são desafiados a cada dia que passa a proteger os dados corporativos de uma empresa, mais e mais, contra os vários tipos de ameaças. A utilização de ferramentas de perícia assegura uma maior confiabilidade e segurança para as empresas que depende de um banco de dados, no caso desta pesquisa ―SGBD Oracle‖ – para manter e disponibilizar os seus dados, evitando com isso a parada dos serviços informatizados, inconsistência dos dados e perda ou roubo de informação.
Como visto, este artigo elencou o uso de diferentes ferramentas de perícia digital aplicadas em um SGBD Oracle, subsidiando possíveis interessados em sua utilização.
É necessária uma maior divulgação destas ferramentas, que apesar de serem em sua maioria gratuitas, pois são de grande valia para os administradores de banco de dados que possa através de seu uso aumentar a proteção dos dados contra violações, roubos e ataques externos.
4.1. TRABALHOS FUTUROS
Como proposta de trabalhos futuros, indico a busca de novas ―ferramentas‖ para agregar às estruturas que compõem o SGBD Oracle e assim apoiar a coleta de evidências. Com as novas versões da Oracle, inclusão de novas funcionalidades e o surgimento de novas ferramentas de perícia digital é necessário a atualização do artigo. Além disso, pode-se, também, ser usada a metodologia aplicada neste artigo para outros SGBD visto que grande parte das ferramentas está associada a arquivos binários e arquivos texto. Bastando apenas ter um conhecimento aprofundado da arquitetura e do funcionamento da tecnologia a ser periciada.
FORENSICS IN ORACLE DATABASE
Abstract:
Today, all organizations have large volumes of data and information that must be stored safely. Any company seeking to ensure effective control over your entire business is required
to use a system manager database - DBMS - and ensure consistency and reliability of data. This article aims at connecting the main tools of digital expertise that can be applied in the security of an Oracle DBMS.
Keywords: Oracle Forensics, forensics tools on Oracle database, forensic evidence on database
5. REFERENCIAS
BRYLA, Kevin Loney, Bob – Oracle Database 10g Manual do DBA – Rio de Janeiro: Elsevier Editora, 2005.
BAYLIS, Ruth – Oracle Database Administrator’s Guide, 10g Release 1 – Oracle Corporation, 2003.
KORTH, Henry; SILBERSCHATZ, Abraham. Sistema de Banco de Dados. Makron Books, segunda edição, 1993
ORACLE Support – Architecture SGBD ORACLE https://support.oracle.com Acesso em 19/10/2010
