Aquisição de dados através da rede

Na computação forense, a aquisição de dados é a cópia dos dados armazenados em um dispositivo que está sendo examinado. Esta cópia pode ser física, onde se realiza uma clonagem fiel de toda a unidade de armazenamento, gerando um arquivo imagem, ou pode ser lógica, onde se realiza a cópia arquivo por arquivo de toda a unidade de armazenamento.

Sempre, a cópia é realizada à uma outra unidade de armazenamento para que o examinador possa trabalhar sem prejudicar a evidência. Esta conduta serve para garantir o conteúdo da prova.

Em situações adversas, o examinador poderá encontrar uma máquina onde não se é possível retirar o disco rígido, seja por razões judiciais ou pela tecnologia aplicada no hardware, por exemplo, a tecnologia RAID. Nestes casos, será necessário iniciar esta máquina com algum sistema forense e assim realizar a aquisição dos dados para uma unidade de armazenamento externa. A distribuição DEFT Linux LiveCD (http://www.deftlinux.net/) pode ser usada para isso.

Se o examinador possui um dispositivo de armazenamento externo, poderá copiar os dados pela própria máquina suspeita. Se possui um computador portátil, poderá estabelecer uma rede entre as máquinas e realizar a aquisição pela rede. É neste segundo cenário que este artigo se aplica, em uma rede cabeada, para uma cópia física de todo o dispositivo. Será utilizado o DEFT Linux na máquina suspeita e um notebook com a distro Fedora. Conecte um cabo crossover entre as placas de rede.

Primeiramente vamos preparar o terreno, configurando a rede com IP estático no Fedora e no DEFT. Digamos que o Fedora, que está no computador portátil do examinador, esteja usando o NetworkManager para gerenciar a rede. Vamos desativá-lo para usar neste processo de coleta o serviço de rede tradicional do Linux.

Execute o script do NetworkManager com o parâmetro "stop":

# /etc/init.d/NetworkManager stop

Em seguida edite o arquivo de configuração do dispositivo de rede:

# vi /etc/sysconfig/network-scripts/ifcfg-eth0

Usando este conteúdo na configuração (adapte se necessário):

DEVICE="eth0"
ONBOOT="yes"
BOOTPROTO=static
IPADDR=192.168.1.10
NETMASK=255.255.255.0
GATEWAY=192.168.1.1

Inicie o serviço de rede:

# /etc/init.d/network start

O comando 'ifconfig' nos mostra se a rede está ativa corretamente. No exemplo a interface "eth0". Ainda no Fedora, é necessário liberar uma porta no firewall. Edite o arquivo de configuração do iptables, adicionando a linha para a porta 2222 e reinicie o serviço iptables:

# vi /etc/sysconfig/iptables

-A INPUT -m state --state NEW -m tcp -p tcp --dport 2222 -j ACCEPT

# /etc/init.d/iptables restart

Com o DEFT operando na máquina suspeita, precisa-se também configurar uma rede com IP estático. O DEFT Linux é compatível com a distro Debian, possui uma ligeira diferença na configuração em relação ao Fedora. Edite o arquivo de configuração da interface de rede, usando o conteúdo abaixo e reinicie o serviço de rede:

# vi /etc/network/interfaces

auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
address 192.168.1.11
netmask 255.255.255.0
network 192.168.1.0
broadcast 192.168.1.255
gateway 192.168.1.1

# /etc/init.d/networking restart

Mais uma vez, o comando 'ifconfig' nos mostra se a rede está ativa corretamente. Os endereços IPs escolhidos nas duas configurações serão usados nos exemplos dos comandos de aquisição. A máquina com Fedora recebeu o IP 192.168.1.10 e a máquina suspeita, rodando o com DEFT, recebeu o IP 192.168.1.11.

Existem duas ferramentas para estabelecer uma conexão de rede e assim transferir dados: nc e ssh.

A ferramenta 'nc' (netcat) é capaz de abrir uma conexão TCP, enviar pacotes UDP e ouvir em uma porta arbitrária. Esta ferramenta será executada nos dois computadores que irão "conversar" pela rede.

Sinopse:

nc [opção]... [endereço] [porta]

Primeiramente, executa-se o 'nc' na máquina que vai receber, no nosso caso, no Fedora. Escolha uma das linhas de comandos abaixo, de acordo com a ferramenta "diskdump" de sua preferência:

$ nc -l 2222 | bunzip2 | dd of=Tempo/sda.dd
$ nc -l 2222 | bunzip2 | dc3dd of=Tempo/sda.dd
$ nc -l 2222 | bunzip2 | dcfldd of=Tempo/sda.dd

A opção -l define que o 'nc' vai ficar "ouvindo" pela porta 2222.

Depois, executar o 'nc' na máquina que vai enviar, no nosso caso, no DEFT. Use a respectiva linha de comando de acordo com a ferramenta "diskdump" usada acima:

# dd if=/dev/sda1 | bzip2 -c | nc 192.168.1.10 2222
# dc3dd if=/dev/sda1 | bzip2 -c | nc 192.168.1.10 2222
# dcfldd if=/dev/sda1 | bzip2 -c | nc 192.168.1.10 2222

O comando 'nc' vai enviar o fluxo de dados para o endereço e porta especificado.


Outro procedimento é utilizar a ferramenta 'ssh', para enviar o fluxo de dados à um arquivo em uma máquina remota. Considerando que o servidor sshd esteja em execução no computador portátil, com o Fedora, execute na máquina suspeita, com o DEFT, o comando para enviar o arquivo imagem. Escolha uma das linhas de comandos:

# dd if=/dev/sda | bzip2 -c | ssh usuario@192.168.1.10 dd of=/home/usuario/imagem.dd.bz2
# dc3dd if=/dev/sda | bzip2 -c | ssh usuario@192.168.1.10 dd of=/home/usuario/imagem.dd.bz2
# dcfldd if=/dev/sda | bzip2 -c | ssh usuario@192.168.1.10 dd of=/home/usuario/imagem.dd.bz2

Neste procedimento não é necessário executar qualquer comando na máquina que vai receber os dados, no nosso caso o notebook com Fedora, apenas o servidor sshd deve estar ativo e utilize uma conta de usuário do sistema Fedora. Será solicitada a senha deste usuário.


Como visto, é relativamente simples a aquisição de dados pela rede. Muitas vezes até compensa em relação a desmontar a máquina suspeita para a retirada do disco rígido. Os computadores portáteis costumam dar trabalho desta desmontagem. O único inconveniente pode ser a velocidade de transmissão, de acordo com a tecnologia da rede, pois uma rede de 100 Mbits a velocidade máxima teórica é 12,5 MB/s.

Prioridades entre os repositórios no Yum

Nas distribuições Linux que usam o gerenciador de pacotes Yum, isto inclui o Fedora e o CentOS, existe um plugin para o Yum que permite ordenar em prioridade os repositórios de pacotes. Esta extensão para o Yum faz com que um pacote de repositório com baixa prioridade não substitua o pacote instalado de um repositório com alta prioridade, mesmo que seja de uma versão maior.

No CentOS este plugin passa a ser bem interessante, porque nesta distribuição são necessários muitos repositórios de terceiros para complementar a oferta de softwares e é comum o conflito de pacotes entre eles. Como a distro Fedora está bem servida com o repositório RPM Fusion, não é tão necessário mais repositórios, reduzindo o risco de conflitos. O pacote yum-plugin-priorities é fornecido pelos repositórios oficiais destas duas distros.

Para instalar o pacote deste plugin, execute o comando:

# yum install yum-plugin-priorities

A configuração do plugin se dá pelo arquivo "/etc/yum/pluginconf.d/priorities.conf", basicamente com a edição da linha "enabled = 1", onde o valor 1 habilita a ação do plugin. Em seguida é preciso editar cada arquivo .repo, localizados em "/etc/yum.repos.d/", incluindo a seguinte linha em cada seção:

priority=N

No lugar de N coloca-se um valor entre 1 (maior prioridade) a 99 (menor prioridade). Usualmente classifica-se os repositórios oficiais com prioridade maior e os repositórios de terceiros com prioridade menor. O importante é não dar a mesma prioridade para repositórios que onde ocorram conflito de pacotes, principalmente entre os repositórios de terceiros. Escolha um para prevalecer, faça uma distribuição dos valores.

Um exemplo de um trecho do arquivo "/etc/yum.repos.d/CentOS-Base.repo", editado com as linhas "priority=N":

[base]
name=CentOS-$releasever - Base
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=os
#baseurl=http://mirror.centos.org/centos/$releasever/os/$basearch/
gpgcheck=1
gpgkey=http://mirror.centos.org/centos/RPM-GPG-KEY-centos4
priority=1

[updates]
name=CentOS-$releasever - Updates
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=updates
#baseurl=http://mirror.centos.org/centos/$releasever/updates/$basearch/
gpgcheck=1
gpgkey=http://mirror.centos.org/centos/RPM-GPG-KEY-centos4
priority=1

Este controle de prioridades é importante pois o Yum sempre atualiza o pacote por uma versão maior, independente de qual repositório está vindo este novo pacote. E um pacote fornecido por terceiro pode não estar plenamente compatível com os demais pacotes instalados. Por isso a prioridade deve ser dos pacotes oficiais e de repositórios não conflitantes.

Quake II no Fedora 15 64 bits

O Quake II é um jogo de tiro em primeira pessoa, desenvolvido pela Id Software, lançado em 1997. A série Quake foi uma grande inovação na época para o gênero de jogos em 3D. Foi um sucesso total.

De lá pra cá, com a popularidade crescente do Linux, foram desenvolvidos alguns "ports" do executável do Quake para o sistema Linux. Assim foi possível jogar sem problemas em uma plataforma além da Microsoft.

Surpreendentemente, até hoje é possível executar o Quake nas máquinas e sistemas atuais. Vou demonstrar o caminho para a instalação do Quake II em um Linux Fedora 15 de 64 bits.

Existe uma equipe denominada LIFLG (Linux Installer For Linux Gamers) com o website no endereço http://www.liflg.org/ que desenvolve instaladores para alguns jogos da plataforma Windows. Dentre eles está o Quake II.

Baixando o arquivo "quake2_3.21-r0.16.1-english.run" e acrescentando alguns arquivos do CD original do Quake II, o jogo estará completo para a execução no sistema Linux.

Este instalador e os executáveis disponibilizados pela LIFLG ainda estão em 32 bits, então para um sistema 64 bits é necessário ter as bibliotecas 32 bits instaladas, em especial o gtk+ 1.2 e o SDL 1.2. No Fedora 15 64 bits os pacotes que fornecem os requisitos são (versões até a data deste artigo):

gtk+-1.2.10-71.fc15.i686
glib-1.2.10-34.fc15.i686
SDL-1.2.14-11.fc15.i686
SDL_gfx-2.0.17-4.fc15.i686
SDL_mixer-1.2.11-5.fc15.i686
SDL_sound-1.0.3-6.fc15.i686
SDL_ttf-2.0.10-2.fc15.i686
libmikmod-3.2.0-12.beta2.fc15.i686
libmodplug-0.8.8.3-3.fc15.i686
physfs-1.0.2-3.fc15.i686
speex-1.2-0.13.rc1.fc15.i686

Instale-os caso não estejam e também suas respectivas dependências se necessário. Com as dependências resolvidas o instalador do Quake II pode ser executado, em uma linha de comando como a seguir:

$ linux32 ./quake2_3.21-r0.16.1-english.run

A ferramenta linux32 é necessária pois o instalador do Quake II da LIFLG não tem suporte nativo 64 bits.

Uma janela do instalador é aberta no ambiente gráfico do X para que especifique os parâmetros da instalação. É possível copiar automaticamente os arquivos do CD original ou, se desejar, copiá-los manualmente depois.

Os arquivos necessários originais do jogo, já em seus respectivos destinos, são:

(digamos que o diretório de instalação seja ~/quake2/ e incluindo os arquivos do update 3.20)

~/quake2/baseq2/pak0.pak
~/quake2/baseq2/pak1.pak
~/quake2/baseq2/pak2.pak
~/quake2/baseq2/players/*/*
~/quake2/baseq2/video/idlog.cin

Com tudo realizado, para iniciar o jogo basta executar o arquivo quake2 ou sdlquake2, a partir do diretório de instalação, ou por algum atalho que porventura tenha sido criado na instalação.

Qualquer dúvida existe uma FAQ no website da LIFLG. Aproveite a nostalgia!

YUM através de servidor proxy

O YUM é um gerenciador de pacotes interativo do Fedora. Por padrão, o YUM acessa repositórios de rede com HTTP. Para que o YUM, acesse a Internet através de um servidor proxy e, se for o caso, com autenticação de usuário, é necessário especificar os detalhes do servidor proxy no arquivo '/etc/yum.conf'.

Basicamente, adicione estas três opções na seção [main] do arquivo '/etc/yum.conf':

proxy=http://endereço:porta
proxy_username=usuário
proxy_password=senha

Por exemplo:

proxy=http://10.78.0.254:8080
proxy_username=fulano
proxy_password=1234

Com a configuração do proxy em '/etc/yum.conf', todos os usuários conectarão ao servidor proxy com essas informações quando usarem o YUM.

Todas as operações HTTP do YUM usam HTTP/1.1 e são compatíveis com servidores proxy que suportam esse padrão. As configurações do HTTP podem ser modificadas para compatibilidade com servidores proxy não padrões. Outra alternativa é configurar o YUM para usar um servidor proxy FTP e acessar repositórios que suportam FTP. Os repositórios do Fedora suportam tanto HTTP quanto FTP. Para configurações específicas, consulte a página manual do yum.conf.

Adicionando o repositório Fusion no Fedora

O Fedora, em sua instalação, já traz pré-configurado os seus repositórios oficiais de pacotes originais e de atualização. Contudo, é possível adicionar repositórios extras na ferramenta YUM e assim tornar disponível outros softwares para instalação.

O principal repositório extra de software para o Fedora é o RPM Fusion (http://rpmfusion.org/), mantido por voluntários. O RPM Fusion fornece os softwares que o Projeto Fedora ou a Red Hat não tem interesse em fornecê-los. É uma extensão ao repositório oficial do Fedora.

Os softwares são fornecidos em pacotes RPM pré-compilados para todas as versões ativas do Fedora. O RPM Fusion é uma fusão dos repositórios Dribble, Freshrpms, e Livna. Seu objetivo é simplificar a localização dos softwares para um único lugar.

O RPM Fusion divide os softwares em duas categorias: gratuitos e não gratuitos. Os softwares gratuitos são os 100% livres, por exemplo os softwares com licença GPL. Os softwares não gratuitos são os softwares de licença proprietária mas que podem ser distribuídos, por exemplo alguns drivers de placas de vídeo.

Para instalar no Fedora, de uma única vez, com um único comando, as configurações do RPM Fusion no YUM, execute o comando abaixo:

# yum localinstall --nogpgcheck http://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-stable.noarch.rpm http://download1.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-stable.noarch.rpm

Lançamento do Fedora 14

Ontem, dia 2/11, foi lançado o Fedora 14. O Fedora é uma distribuição do sistema operacional Linux patrocinada pela empresa Red Hat, desenvolvido pelo Projeto Fedora.

O Projeto Fedora nasceu em 2003 quando a Red Hat decidiu entregar para a comunidade livre o desenvolvimento de sua distribuição voltada ao público.

Antigamente a Red Hat mantinha duas distribuições do seu sistema Linux, uma livre para o público e outra restrita ao meio corporativo, o Red Hat Enterprise Linux. A Red Hat decidiu então dedicar-se somente a distribuição corporativa e criou o Projeto Fedora para a comunidade livre. O anúncio da versão 1.0 do Fedora deu-se em 6 de Novembro de 2003.

O Fedora é uma distribuição Linux completa, de uso geral, contendo todas as novidades do mundo do software livre. É uma distribuição sempre moderna e atualizada com a mais alta tecnologia do software livre. Na distribuição Fedora, as versões dos softwares contidos estão, em sua grande parte, entre as últimas versões lançadas.

O Fedora manteve basicamente as mesmas características do antigo Red Hat Linux, com o gerenciamento de pacotes pela ferramenta RPM. Entretanto atualmente, o Fedora possui um sistema de gerenciamento de pacotes bastante eficiente e evoluído. O Fedora faz uso o delta RPM, o qual em uma atualização de pacotes, o gerenciador efetua o download apenas das partes que diferem da versão instalada. Isto gera uma grande economia na questão da banda consumida. No momento pouquíssimas distribuições utilizam o delta RPM, entre elas Fedora, Mandriva e OpenSUSE.

A diversidade de softwares disponíveis para o Fedora é grande. Existem vários repositórios de softwares livres que disponibilizam pacotes para o Fedora. O principal é o RPM Fusion (http://rpmfusion.org/). É comum também as desenvolvedoras de softwares proprietários, as que possuam versões para o sistema Linux, disponibilizarem pacotes compatíveis com o Fedora.

Uma versão do Red Hat Enterprise Linux é sempre lançada após o lançamento de uma versão do Fedora. Assim a Red Hat aproveita as características positivas do Fedora em sua distribuição corporativa.

De acordo com o site DistroWatch, o Fedora é a segunda distribuição mais popular, atrás apenas do Ubuntu. Informação checada em Novembro de 2010.

Mais informações em:

http://fedoraproject.org/

http://distrowatch.com/table.php?distribution=fedora

http://www.redhat.com/archives/fedora-announce-list/2003-November/msg00000.html

Configurando Serviços no Linux

Os serviços são programas (daemons) que são iniciados e mantidos em execução em segundo plano, ficam monitorando o computador e respondem às mudanças. Por exemplo o servidor Apache possui um daemon chamado httpd (o d é de daemon) que fica escutando a porta 80 do computador e quando ele recebe uma requisição por uma página, ele envia os dados apropriados para a máquina cliente.

Muitos serviços ficam em execução na maioria do tempo entretanto muitos podem ser seguramente desligados por razões de segurança como também por razões de desempenho. Pode não ser muita a diferença mas o computador é iniciado um pouco mais rápido quando há menos serviços para iniciar.

Existem dois comandos que são usados para controlar os serviços:

/sbin/chkconfig - Este controla quais serviços serão iniciados durante a inicialização da máquina. As mudanças aplicadas por este programa não alterará o estado do serviço imediatamente, apenas deixará marcada a configuração para a próxima inicialização da máquina.

/sbin/service - Este controla o início ou o fim da execução dos serviços imediatamente durante a seção atual, não mantendo para a próxima inicialização da máquina.

Antes vamos conhecer como o sistema Linux organiza o controle dos serviços. Muitas variantes do Unix System V, e isto inclui diversas distribuições do Linux, usam scripts nos diretórios "/etc/rcN.d/" para controlar quais serviços serão iniciados dentre os níveis de execução. Se um serviço deve ser iniciado no nível de execução 5 então é colocado o seu script em "/etc/rc5.d/".

Entretanto este modelo envolve em existir múltiplas cópias do mesmo script em diretórios diferentes, então foi adotado o padrão de colocar todos os scripts de controle dos serviços no diretório "/etc/init.d/", e usar ligações simbólicas para estes scripts nos vários diretórios "/etc/rcN.d/". Isto permitiu a inovação com o comando "chkconfig".

Na distribuição Fedora Linux as ligações e os scripts estão nos diretórios "/etc/rc.d/rcN.d/" e "/etc/rc.d/init.d/", porém é mantido no diretório "/etc/" as ligações simbólicas para estes diretórios, imitando a origem vinda do Unix System V.

Para o comando "chkconfig" poder operar adequadamente, os arquivos dos scripts de controle devem ter seus nomes refletindo o nome do serviço o qual eles controlam. E no inicio de cada script deve existir um cabeçalho com algumas linhas que fazem com que o "chkconfig" entenda que pode controlar a execução.

A principal linha deste cabeçalho é a que especifica os níveis de execução e a ordem de execução dos scripts. Esta linha é semelhante a mostrada abaixo:

# chkconfig: 2345 55 25

O primeiro conjunto de números "2345" indica os níveis no qual o script será executado e "55" e "25" representam a ordem em que o script será executado e parado no nível de execução.

Para adicionar um script e ativar o controle do serviço pelo gerenciamento do "chkconfig" primeiro é preciso colocar o script no diretório "/etc/rc.d/init.d/" e então executar no prompt do terminal o comando "chkconfig --add nome_do_serviço". A partir deste ponto basta executar o comando "chkconfig nome_do_serviço on" para que a devida ligação simbólica seja criada nos diretórios "/etc/rc.d/rcN.d/" especificados no cabeçalho do script. Com a execução do comando "chkconfig nome_do_serviço off" estas ligações são removidas. Do mesmo modo, pode-se remover o controle do serviço pelo gerenciamento do "chkconfig" executando o comando "chkconfig --del nome_do_serviço".

Estas ligações simbólicas existentes dos diretórios "/etc/rc.d/rcN.d/" seguem um padrão em seus nomes. Os nomes iniciam com os caracteres "S" ou "K" (de Start e Kill) seguido do número da ordem de execução (aqueles do cabeçalho), semelhante a algo como por exemplo "S85httpd" ou "K30proftpd".

O comando "chkconfig --list" retorna uma listagem de todos os serviços disponíveis junto com suas respectivas configurações para a inicialização da máquina. Um retorno mais específico pode ser obtido com o comando "chkconfig --list nome_do_serviço". E é possível alterar os níveis definidos no cabeçalho diretamente na linha do comando, por exemplo se no cabeçalho do script estão definidos os níveis 2345 e a linha de comando for "chkconfig --level 35 nome_do_serviço on", somente será criada as ligações simbólicas nos diretórios "/etc/rc.d/rc3.d/" e "/etc/rc.d/rc5.d/".

Estes scripts usualmente atendem aos argumentos "start", "stop", "status" e "restart", do mesmo modo os comandos que controlam os serviços. A execução imediata do serviço pode ser feita com a chamada do próprio script pela linha de comando, em algo como "/etc/rc.d/init.d/nome_do_serviço start". Ou também utilizando o comando "service" em algo como "service nome_do_serviço start". Lembrando que estas formas só funcionam para a seção atual, não mantendo para a próxima inicialização da máquina. O argumento "stop" para o serviço, o argumento "status" mostra a situação atual do serviço e o argumento "restart" reinicia o serviço. O comando "service" pode ir mais além, executando o comando "service --status-all" ele retorna o estado de todos os serviços instalados no sistema.

Uma alternativa para o comando "chkconfig" é o utilitário "ntsysv", que é uma simples interface para configurar os serviços nos níveis de execução. Por padrão ele configura somente no nível de execução atual e para configurar também para algum outro nível é necessário executá-lo com o argumento "--level NNN", por exemplo "ntsysv --level 35" edita os níveis 3 e 5.

Estes comandos são o padrão na distribuição Fedora. As outras distros poderão ter comandos ligeiramente diferentes.