//
você está lendo...
EDIÇÃO 5

E5SI28 – PERÍCIA FORENSE COMPUTACIONAL: Análise de Malware em Forense computacional utilizando de sistema operacional GNU/Linux

 Alex Sander de Oliveira Toledo[1]
Robert de Souza[2] 

Resumo: O presente trabalho apresenta as boas práticas na coleta, restauração, identificação, preservação, documentação, análise dos dados periciais, apresentação de vestígios, evidências, provas digitais e interpretação aplicadas aos componentes físicos ou dados processados e/ou armazenados nas mídias computacionais, garantindo assim o valor jurídico das provas eletrônicas. 

Palavras-chave: Perícia forense computacional, Malware, Linux.

 

1 Introdução

Segundo Melo (2009), a informação é hoje um dos ativos mais importantes das corporações, sendo de suma importância que sua integridade seja mantida. Em um passado não muito distante um servidor mal configurado representava riscos, mas estes eram confinados dentro dos limites da LAN da corporação.

Com o advento da Internet estas fronteiras foram eliminadas, facilitando muito a ocorrência de crimes eletrônicos, onde o criminoso e a vítima podem encontrar-se em localidades geográficas diferentes, até mesmo em países distintos. O crescimento do número de computadores interconectados (Internet) e o aumento de softwares com finalidades ilícitas de fácil utilização disponíveis na rede aumentaram significativamente o número de ataques.

Ainda Segundo Melo (2009), por mais seguro que seja um Firewall ou um sistema de segurança, os sistemas operacionais estão sempre sujeitos a falhas ainda desconhecidas, por este motivo sugere-se prudência ao afirmar que um sistema está imune a invasões ou invulneráveis.

As técnicas forenses são imprescindíveis para identificar se um computador foi invadido, determinando de que forma foi alterado, estabelecendo critérios para preparar o ambiente visando registrar os dados periciais, facilitar a identificação do invasor e amparar as medidas legais a serem tomadas para caso a resposta seja positiva, pois a invasão constitui crime eletrônico.

O valor jurídico de provas eletrônicas manipuladas de forma incorreta, sem os padrões previstos e devidamente estabelecidos podem ser facilmente contestadas.

Segundo Melo (2009, p. 1), não há padrões internacionais para o tratamento de dados periciais:

“[…] Não há padrões internacionais para o tratamento de dados periciais, embora existam documentos de boas práticas dedicados a classificar respostas a incidentes de segurança e um capítulo da ISO NBR IEC17799:2005 que endereça o assunto [ABNT].”

É importante empregar boas práticas na coleta, restauração, identificação, preservação, documentação, análise dos dados periciais, apresentação de vestígios, evidências, provas digitais e interpretação aplicadas aos componentes físicos ou dados processados e/ou armazenados nas mídias computacionais, garantindo assim o valor jurídico das provas eletrônicas captadas no processo de perícia forense computacional.

Segundo Melo (2009), as principais fontes de dados periciais encontram-se nas estações de trabalho em ambiente computacional distribuído, servidores, locais na internet, em local remoto na Internet, sistemas de informação, e equipamentos eletrônicos programáveis.

Segundo Tanenbaum (2003), existe uma diferença notória entre Sistemas de Ambientes Computacional Distribuído e Sistema de Redes de Computadores, ou seja, não se pode confundir uma unidade de controle (servidor) e vários dispositivos escravos com uma rede. Rede é uma visão conceitual aplicável a um grande computador com terminais e/ou muitos microcomputadores e impressoras conectados.

Um sistema computacional é considerado Distribuído quando a camada de rede não está implementada, ou seja, a interface de rede ativa pode-se comunicar diretamente com todos os demais computadores.

Segundo Melo (2009), devido à evolução dos tipos de Malwares (softwares maliciosos) as soluções de seguranças devem sempre ser revistas, os fabricantes de Sistemas Operacionais e Softwares de Segurança sempre disponibilizam novas soluções.

Caso um invasor utilize de técnicas clássicas, como armazenar, manter, e ou esconder ferramentas anti-forense durante sua ação em diretórios clássicos como /tmp, um perito pode facilmente localizar evidências atuando apenas com binários compilados estaticamente, neste caso imagina-se que rootkits baseados em técnicas arrojadas de LKM (Loadable Kernel Module) não sejam utilizadas.

Segundo Melo (2009, p. 67) em relação à técnicas mais arrojadas:

“Caso seja constatado o uso de técnicas mais arrojadas, os dados levantados durante uma Live Análise são facilmente contestadas. Somente durante a Post Mortem Análise, os resultados são realmente confiáveis, pois durante a Live Analise possivelmente as chamadas ao sistema podem ser interceptadas.”

Segundo Farmer e Venema (2007, p. 174-175), os passos para coleta de dados são:

“(…) O(s) computador(es) em questão deve(m) ser colocado(s) off-line. Há alguns potenciais problemas com isso, porque o sistema talvez espere estar on-line. Portanto, colocar a máquina off-line poderia destruir vestígios à medida que o sistema gera erros, repetidamente tenta novas conexões ou, em geral, altera seu estado. Alternativamente, você poderia tentar cortar a conexão da máquina com o roteador e mantê-la em uma rede local, mas os serviços de DNS e serviços de rede e outros sistemas na mesma área de rede ainda podem causar problemas.

À medida que você avança, é necessário monitorar tudo o que você digita ou faz. Em geral é uma situação do tipo “coletar primeiro, analisar mais tarde”. Anote as configurações de hardware, software, sistemas e rede que estão definidas.”

O autor aponta estas considerações devido à divergência de opiniões sobre o assunto, pois alguns peritos consideram o fato de desligar a máquina um grave erro, já que alguns invasores podem utilizar de técnicas mais arrojadas e plantar bombas para que caso a máquina seja retirada da rede ou desligada, executem comandos, e desta forma eliminem vários vestígios e destrua provas que seriam de grande valor no laudo pericial.

 

2 Identificação e descrição dos malwares

“Malware pode ser definido como Malicious Software ou Software Malicioso, ou seja é um termo genérico que engloba todos os tipos de programas especificamente desenvolvidos para executar ações maliciosas em um computador. O Malware contém ameaças reais de vários tipos e propósitos.” (MELO, 2009, p.10).

Segundo Brian, James e George (2003, p.194) a respeito dos Cavalos de Tróia:

“Os cavalos de troia são programas criados para contornar a segurança da sua máquina, mas disfarçados como algo benigno. Assim como a criação grega, um cavalo de Tróia do computador não pode fazer nada sozinho, mas precisa contar com o usuário ajudando-o a cumprir seu destino. Existe três usos principais da palavra troiano no linguajar moderno do computador:

Programa de cavalo de Tróia: um programa malicioso que se disfarça de uma coisa, mas contorna sua segurança em segredo. Esse é o uso mais comum da palavra.

Código-fonte troiano: uma cópia do código-fonte do programa que foi modificada para conter alguma porta dos fundos ou brecha na segurança.

Binários troianos: Após uma invasão um atacante pode substituir binários do sistema por versões que contêm postar dos fundos ou que ocultam suas atividades.”

Segundo MELO (2009, p. 10), define-se Vírus:

“Programa que pode atuar como um binário independente ou alojar-se em um programa executável, tornando-o um arquivo binário infectado. Em sua engenharia, não é definido um vetor de transmissão automatizado. Depende da execução do programa, do arquivo hospedeiro ou de um meio, como um cliente de correio, para que possa voltar a propagar e dar continuidade ao processo de infecção.”

Segundo Melo (2009), o Worm é um tipo de Malware capaz de se propagar automaticamente por meio de redes enviando copias de si mesmo para outros computadores, esta propagação está prevista em sua engenharia, e se dá por meio da exploração de vulnerabilidades existentes ou falhas nas configurações de softwares instalados nos computadores, criando um cenário em que não é necessário ser executado para se propagar, podendo propagar-se em qualquer tipo de sistema operacional.

Ainda Segundo MELO (2009, p. 12) sobre Rootkits e Spywares:

“Rootkit – Tipo de Malware muito arrojado, sua engenharia normalmente prevê a instalação de binários, módulos, bibliotecas que disponibilizam os mais variados recursos como: Backdoors, Cleanlogs, Keyloggers.

Usa técnicas para esconder processos e outras informações inerentes ao mecanismo, o que dificulta sua identificação, além de sua instalação se dar de forma automatizada.

Normalmente são instalados logo após o comprometimento de um computador por um invasor.

Spyware – Uma categoria muito peculiar de Malware, que usufrui as capacidades dos browsers em executar aplicações. A maioria quase absoluta desse tipo de Malware é escrita tendo como alvo sistemas Microsoft.”

Portanto estes Malwares colocam em risco os princípios básicos da segurança (integridade, disponibilidade e confiabilidade) estas ameaças podem trazer diversos prejuízos às organizações, prejuízos não só financeiros, mas também de perda parcial ou total de seus ativos da Tecnologia da Informação e Comunicação (TIC).

3 Descoberta do malware

Quando é descoberto o Malware em um sistema, há muitas decisões e ações que devem ser tomadas. Para melhor estruturarmos o processo de investigação e análise de Malwares, o dividiremos em cinco fases: Preservação e análise de dados voláteis, Análise de memória, Análise de discos, Análise estática de Malware e Análise dinâmica de Malware.

3.1 Preservação e análise de dados voláteis

Segundo Farmer e Venema (2007), em uma análise post-mortem, tem-se pouco tempo para coletar informações enquanto a máquina comprometida permanece em execução, para uma coleta eficaz os autores utilizam a ferramenta grave-robber (ladrão de túmulos) do Coroner’s Toolkit, que é otimizada para este cenário.

A grave-robber captura informações voláteis sobre processos e conexões de rede, atributos de arquivo como registros de data/hora de acesso, arquivos de configuração, log e outros tipos de arquivos. O resultado é armazenando em um banco de dados que deve ser transferido para um sistema de análise.

Esta abordagem captura o estado volátil do processo, mas há desvantagens, se o kernel foi subvertido, as informações podem estar incompletas ou corrompidas.  

Segundo MELO (2009, p. 36), quanto ao cuidado na execução das ferramentas de análise Live Forense:

O conjunto de ferramentas selecionadas deve ser compilado estaticamente para compor o ferramental de Resposta de Incidente que deverá ser utado na Live Forense. A compilação da ferramenta no modo estático a partir do código fonte gera um binário que não utiliza as bibliotecas dinâmicas do sistema. Adotando-se essa precaução o binário alojado em CDROM se torna imune a tentativas de inoculação de código por programas maliciosos.

 

3.2 Análise de memória

Segundo Farmer e Venema (2007), todos os sistemas operacionais modernos utilizam memória virtual como uma abstração para tratar combinações da RAM, espaço de troca, ROM, NVRAM e outros recursos de memória. O gerenciador de memória que executa no kernel, trata a alocação e desalocação da memória em um computador.

Segundo Melo (2009), a memória principal contém todo tipo de informação volátil, como informações de processos que estejam em execução, dados que estão sendo manipulados e que, muitas vezes ainda não foram salvos em disco e informações no sistema operacional.

O autor ainda exemplifica a coleta de evidência da memória RAM, destacando os arquivos /dev/kmem que têm as informações de memória da área de kernel e /dev/mem, que é toda a memória da máquina:

# /cdrom/dd if=/dev/mem | cdrom/nc <ip> <porta>

# /cdrom/dd if=/dev/kmem | cdrom/nc <ip> <porta>

# /cdrom/dd if=/dev/rswap | cdrom/nc <ip> <porta>

# /cdrom/dd if=/dev/kcore | cdrom/nc <ip> <porta>

No exemplo acima o “#” informa que o usuário logado é o root (super usuário do sistema), o “/cdrom” o diretório onde o ferramental de resposta a incidente foi instalado para a utilização em “Live Forense”, o comando “dd if=/dev/mem | /cdrom/nc <ip> <porta> transfere uma imagem do conteúdo da memória RAM, área de kernel, e swap para a máquina do perito através do ip e da porta estipulada nos comandos citados.

3.3 Análise de disco

Segundo Farmer e Venema (2007), há diversas maneiras de se duplicar as informações sobre o sistema de arquivos. Qual método estará disponível dependerá da situação, os dois autores já capturaram informações efetuando o login em uma máquina comprometida, listando os arquivos para o terminal e registrando essa sessão com um programa emulador de terminal. Veremos a seguir alguns métodos para capturar estas informações.

3.4 Cópia de arquivos individuais

Segundo Farmer e Venema (2007), essa é a abordagem menos precisa, porque só captura o conteúdo dos arquivos. Nenhuma meta-informação é capturada, exceto talvez o tamanho do arquivo. Todas as demais meta-informações são perdidas, como posse do arquivo, datas/horas de acesso, permissões etc.

Estas informações só não são perdidas quando salvas usando outro meio. Por exemplo, o utilitário grave-robber do Coroner’s Toolkit que copia os arquivos selecionados (como arquivos de configuração e registros em log) depois de salvar suas meta-informações em um arquivo chamado body.

3.4.1Backup

Ainda segundo Farmer e Venema (2007), dependendo do software de backup utilizado, esse método preserva algumas meta-informações como posse, informações sobre links físicos e a última data/hora da modificação, mas não captura a data/hora do último acesso de leitura. Utilitários UNIX comumente utilizados são tar, cpio e dump. A desvantagem de fazer um backup é que o que você vê é tudo o que você obtém. Backups não capturam as informações de arquivos excluídos

3.4.2 Cópia de partições de discos individuais

Segundo Farmer e Venema (2007, p. 55), a respeito da cópia de partições: 

Esse método cria uma cópia idêntica bit a bit de cada sistema de arquivos, incluindo todas as meta-informações e todas as informações que permanecem em um espaço não-alocado no fim dos arquivos, entre os arquivos, nos blocos de inode não-alocados e assim por diante. Isso em geral é feito com o comando dd.

Um benefício importa dessa abordagem é que ela é neutra em relação ao sistema de arquivos. Por exemplo, a mesma técnica pode ser utilizada para copiar tanto partições UNIX quanto partições Windows. A desvantagem é que os dados armazenados entre e fora das partições não são analisados. Os fragmentos de comando a seguir lêem a primeira partição UNIX no primeiro disco.

Linux             #dd if=/dev/hda1 bs=100k . . .

Freebsd         #dd if=/dev/da0s1a bs=100k . . .

Solaris           #dd if=/dev/dsk/c0t0d0s0 bs=100k . . .

 

3.4.3 Copiar disco inteiro

Segundo Farmer e Venema (2007), o resultado é uma cópia idêntica bit a bit de todas as informações acessíveis no disco, incluindo o espaço de armazenamento antes e depois das partições de disco. Isso pode ser necessário quando há suspeitas de que os dados poderiam permanecer ocultos fora das partições de disco. Mais uma vez o “dd” é o comando ideal para realizar esta cópia.

Este método possui limitações, ele não lerá os blocos de disco que contém erros e que o hardware silenciosamente remapeou para os chamados blocos sobressalentes. Esse método também não fornecerá acesso aos blocos sobressalentes não utilizados, porque eles residem fora da área normalmente acessível ao disco. Os fragmentos de comando a seguir lêem todos os blocos acessíveis no primeiro disco:

Linux             #dd if=/dev/hda bs=100k . . .

Freebsd         #dd if=/dev/da0 bs=100k . . .

Solaris           #dd if=/dev/c0t0d0s2 bs=100k . . .

Ainda segundo Farmer e Venema (2007), a exatidão das informações capturadas aumenta na medida em que dependemos menos da integridade do sistema comprometido. Por exemplo, quando arquivos individuais são capturados enquanto ainda estão conectados à máquina da vítima, o aplicativo subvertido ou o software de kernel subvertido pode distorcer esse resultado. A subversão é muito menos provável quando utilizamos um procedimento de baixo nível de geração de imagens de disco, com a unidade de disco conectada a uma máquina confiável.

3.5 Análise estática de Malware

Segundo Farmer e Venema (2007, p. 120), sobre as técnicas de análise estática: 

“[…] Desassemblagem de programa (converter um arquivo de programa em uma listagem de intrusões de linguagem de máquina), descompilação de programa (converter instruções de linguagem de máquina no código-fonte equivalente da linguagem de nível mais alto) e análise estática (examinar um programa sem realmente executá-lo)” 

A desassemblagem de programa é um recurso padrão de todo programa depurador importante, entretanto ferramentas que descompilam programas em linguagem de alto nível como C só existem para ambientes limitados. A ameaça da engenharia reversa também apresenta um problema para programadores de aplicativos Java.

A preocupação com o furto de propriedade intelectual talvez tenha muito a ver com essa disponibilidade limitada de descompiladores.

3.6 Análise dinâmica de Malware

Segundo Farmer e Venema (2007, p. 104), sobre os perigos da análise dinâmica: 

“Uma maneira de descobri o propósito de um programa desconhecido é simplesmente executá-lo e ver o que acontece. Há vários problemas potenciais com essa abordagem. O programa poderia executar de uma maneira confusa e destruir todas as informações na máquina [..]”

“Em vez de executar um programa desconhecido em uma ambiente onde eles podem causar danos, é mais seguro executar esse programa em uma caixa de areia. O termo caixa de areia (sandbox) foi emprestado da balística, na qual as pessoas testam armas atirando em uma caixa de areia de modo que as balas não possam causar nenhum dano. Uma caixa de areia de software é um ambiente controlado para executar o software.” 

Ainda segundo Farmer e Venema (2007), as caixas de areia podem ser implementadas de diversas maneiras, a abordagem mais simples é o de cordeiro sacrificial, uma máquina real, mas descartável, com acesso limitado à rede ou simplesmente sem acesso à rede.

 

4 Coleta do malwere 

Segundo Melo (2009), um perito forense, ao iniciar uma perícia no sistema que teve uma segurança violada, busca evidências que caracterizem e possibilitem identificar como e o quanto a violação afetou as informações e o próprio Sistema Operacional.

Ainda segundo MELO (2009, p. 33), a coleta de evidências pode ser dividida, de forma macro, em três etapas:

A primeira etapa consiste na coleta de evidências antes do desligamento do sistema da fonte elétrica, que tem por objetivo registrar o estado do sistema, e a segunda etapa, após o desligamento.

A segunda etapa, pelo termo oriundo do inglês, Network Forensic, que consiste na coleta de análise de informações de atividade de rede, tanto do servidor em questão, como dos demais ativos de redes que tenham informações pertinentes.

E por último, a etapa em que todas as informações reunidas nas etapas anteriores são cruzadas com informações identificadas na análise das imagens de mídias coletadas. Essa última fase é tecnicamente conhecida como Post Mortem Analysis.

Tanto na Live Analysis, na Network Forensic como na Post Mortem Analysis, o objetivo é a coleta do máximo de evidências digitais. O termo Dado pericial digital (pode ser um vestígio, evidência ou mesmo se consolidar em prova durante uma perícia) refere-se a toda e qualquer informação digital capaz de demonstrar que ocorreu um incidente de segurança ou mesmo um crime, dentro do contexto da Perícia Computacional.

Segundo Farmer e Venema (2007), a sabedoria tradicional da computação forense, conta com métodos muito conservadores, raramente nada além de desligar um computador e fazer uma cópia de disco. Caso seja necessário assegurar que os dados coletados sejam otimizados para poderem ser aceitos em um tribunal e só conseguir capturar parte deles, então uma metodologia mais cautelosa pode ser a melhor opção em alguns casos.

Ainda segundo Farmer e Venema (2007, p. 172), sobre as técnicas conservadoras:

“Infelizmente, essas técnicas conservadoras não têm uma grande quantidade de informações potencialmente úteis sobre a situação, como processos em execução e kernels, estado de rede, dados na RAM e muito mais. Somente um entendimento limitado pode surgir do exame de um disco morto. E, embora informações dinâmicas talvez sejam um pouco mais voláteis e, portanto suspeitas, quaisquer condenações com base em uma única série de leituras dos dados também são suspeitas.[…]”

 

5 Análise do arquivo 

Segundo Farmer e Venema (2007), pequenos programas podem gerar muitos problemas, como observado abaixo, o código de um programa de backdoor recuperado após um ataque:

scanf (“%s”, buffer);

if (strcmp(password, buffer)==0){

puts(“.”);

setuid(0);

setgid(0);

execl(“/bin/sh”,“sh”,(char *)0);

}

return (0);

Com exceção da chamada de função de comparação de string strcmp(), nenhuma chamada de função é testada quanto a retornos de erro. Se uma operação falhar o programa simplesmente prossegue. Erro de leitura de entrada a partir de scanf(), caso todas as operações falhem o programa termina silenciosamente.

 

6 Laboratório 

Um cenário de análise de servidor foi montado para exemplificar a perícia forense computacional na busca por Malwares em servidores Linux, a ferramenta utilizada para a perícia é o Sistema Operacional Back Track.

Conforme os autores mencionados neste trabalho, parto do princípio que todas as atividades para manter o sistema integro e com o mínimo possível de perda de dados voláteis tenham sido realizadas como: a decisão de remover o cabo de rede ou não do servidor que sofreu a intrusão, se houve alguma intervenção por parte de outro profissional após a identificação do problema e se este realizou alguma atividade e quais, que a cópia dos dados da memória tenham sido realizadas em local seguro e fora da máquina periciada, que uma imagem bit a bit do disco tenha sido efetuada.

O chkrootkit é um detector de presença de  de rootkits em sistemas baseados em Unix. O software  utiliza cerca de nove tipos de análise para detectar traços de atividade ou presença de rootkits na máquina e atualmente é capaz de identificas mais de 60 tipos de ameaças diferentes como rootkits, worms, trojans, dentre outros. 

Iniciando o chkrootkit o sistema informa os parâmetros que podem ser utilizados na detecção de Malwares.

Neste ponto fazemos uma varredura em busca de Malwares alojados na máquina.

Executando o chkrootkit ele checa o sistema em busca de Malwares e já exibe o resultado na tela informando se o arquivo está ou não infectado.

Com esta atividade conseguimos identificar a presença ou não do Malware no sistema operacional.

O rkhunter é outra ferramenta de grande importância na detecção de rootkits no sistema, este avisa caso haja arquivos suspeitos no sistema.

Um dos parâmetros do rkhunter é o “–update”, que atualiza sua base de dados de Malwares.

Sua execução se da através do comando “rkhunter –check”. 

Os arquivos que contiverem a cor verde – not found e ok – estão normais. Já aqueles que forem marcados como “Warning” estão comprometidos e serão exibidos na cor vermelha, sendo assim deve-se proceder a remoção do rootkit.

Antes de executar a remoção o Malware deve ser isolado em um dispositivo de armazenamento que seja externo ao disco da máquina comprometida, onde não possa mais gerar danos e possibilite uma análise posterior, talvez até mesmo sua execução em ambiente fechado e preparado para tal. 

  

O Malware deve ser removido do sistema operacional e a vulnerabilidade que permitiu sua inserção deve ser tratada, para que esta falha não seja explorada novamente por um atacante. 

O relatório final da execução e da análise do Malware fica registrada em /var/log/rkhunter.log.

O Malware encontrado é um Backdoor que permite um acesso do atacante à máquina comprometida de forma rápida sem a necessidade de realizar todos os passos para sua intrusão, este código mantém uma porta de comunicação aberta entre o atacante e a máquina comprometida.

Abaixo um trecho do código da Backdoor utilizada para o acesso do atacante à máquina através de uma falha de segurança do PHP:

<?php

.passthru(“date”);

.echo “Iniciando via NETCAT da Backdoor”;

.passthru (“nc –l –p 65321 –e /Bin/sh”);

.echo “Backdoor Instalada!!!>;-)”;

.echo “Passaporte para sistema disponível!!! >;-)”;

?>

 

7 Conclusão 

A perícia forense computacional é um instrumento imprescindível para identificar se um sistema computacional foi invadido, e de que forma foi alterado, estabelecendo critérios para preparar o ambiente visando registrar os dados periciais, facilitar a identificação do invasor e amparar as medidas legais a serem tomadas diante da intrusão.

O valor jurídico de provas eletrônicas manipuladas de forma incorreta, sem os padrões previstos e devidamente estabelecidos pode ser facilmente contestado, e toda atividade do perito deve ser acompanhada por um ou mais profissionais da TIC da empresa que o contratou para a perícia, isso para assegurar a integridade não só da coleta dos dados, mas também para resguardar o perito, evitando assim que de perito torne-se réu.

Enfim, a utilização de ferramentas que auxiliam e dão suporte à investigação é de suma importância, pois estas conseguem garimpar informações de forma eficaz e ágil, primando pela integridade e minimizando os riscos da perda de dados voláteis.

A partir deste trabalho discutimos e demonstramos as técnicas e procedimentos da perícia forense computacional que auxiliam na análise de sistemas computacionais comprometidos, apontando as melhores práticas na atualidade e metodologias a serem aplicadas na descoberta, coleta e análise de Malwares.


8 Referências Bibliográficas 

FARMER, Dan; VENEMA, Wietse. Perícia Forense Computacional: Teoria e prática aplicada. São Paulo: Pearson Prentice Hall, 2007. 

MELO, Sandro. Computação Forense com Software Livre: Conceitos, técnicas, ferramentas e estudos de casos. 1. ed. Rio de Janeiro: Alta Books. 2009. 

TANENBAUM, Andrew S. Redes de Computadores. 4. ed. Campus (Elsevier), 2003.

HATCH, Brian; B. LEE, James; KURTZ, George. Segurança contra Hackers Linux. 2. ed. São Paulo: Futura, 2003. 

FILHO, João Eriberto Mota. Forense computacional utilizando ferramentas GNU/Linux. Brasília: Serpro, 10 de Novembro de 2009. Palestra ministrada no CISL – Comitê Técnico de Implantação de Software livre, 10/11/2011. Forense computacional utilizando ferramentas GNU/LINUX. Disponível em: http://streaming.serpro.gov.br/cisl/forense.html.


[1] Coordenador e Professor do Curso de Bacharelado em Sistemas de Informação do Centro Universitário Newton Paiva 

[2] Graduando em Bacharelado em Sistemas de Informação do Centro Universitário Newton Paiva

Discussão

Os comentários estão desativados.

Núcleo de Publicações Acadêmicas Newton Paiva

A PÓS EM REVISTA é uma publicação da Pós-Graduação e desenvolvida pelo Núcleo de Publicações Acadêmicas do Centro Universitário Newton Paiva