Técnicas anti-forense para ocultação de dados – Parte 2

Colaboração: Alexandre Stratikopoulos

Nesta segunda parte do artigo sobre técnicas anti-forense, abordaremos algumas opções para ocultação de dados na Camanda de Hardware.

O disco rígido, independente do funcionamento dos sistemas operacionais, parece ser um bom local para ocultar dados confidenciais. O processo investigativo e de análise de um disco deve iniciar-se com a obtenção de informações sobre sua geometria e configuração, seguida pelo processo de geração da imagem bit-a-bit do dispositivo.

A seguir, abordaremos 2 áreas do disco que podem ser usadas para ocultação de dados.
                       MBR
                       ===

Dentre as áreas não acessíveis pelo usuário comum, está a MBR. Como indicado abaixo, é uma prática normal as tabelas de partições (do MBR ou da partição estendidas) começarem na cabeça 0, setor 1 de um cilindro, e o primeiro
setor da primeira particão começar na cabeça 1, setor 1 do cilindro.

A consequência dessa prática é a existência de setores não utilizados entre o setor da tabela de partições e início da primeira partição. Esses setores podem ser utilizados para esconder informações, sem qualquer risco de serem detectadas pelo uso normal do sistema de arquivos.

As informações armazenadas em áreas não acessíveis através de um sistema de arquivos podem ser extraídas por meio de raw I/O, utilizando-se, por exemplo, o comando dd e o device node (ou a imagem em arquivo) correspondente ao disco analisado, como ilustrado a seguir:

 # dd if=/dev/sda of=image.sda bs=512 skip=1 count=62
 62+0 records in
 62+0 records out

No exemplo anterior, o comando dd é usado para extrair o espaço não utilizado entre o MBR (setor 0) e o setor de boot da primeira partição do disco (setor 63). A informação é extraída do disco /dev/sda e é preservada no arquivo binário image.sda. As opções bs, skip e count são utilizadas para instruir o comando dd a copiar 62 setores de 512 bytes, a partir do setor de número 1.

                       MBR
                       ===

A Host Protected Area (HPA) é definida como uma área protegida em um disco rígido, sendo introduzida como um recurso opcional no padrão ATA-4 em 1998 e atualmente, a maioria dos discos rígidos suportam esse recurso.

Este recurso é muito usado por fabricantes de notebook para armazenar imagens do sistema atual, bem como ferramentas de recuperação e diagnóstico. Seu principal objetivo é prover a recuperação do sistema a partir de uma imagem padrão. Se a HPA está sendo utilizada para este propósito, é possível que o investigador forense encontre evidências de dados ocultos nesta área.

Na prática, seu disco tem um espaço maior do que a área utilizada pelo sistema operacional e existem algumas ferramentas gratuítas, como hdat2, que são capazes de acessar e modificar o conteúdo da HPA de um disco.

Para verificar se seu disco tem a HPA habilitada, pode-se utilizar a ferramenta hdat2, como no exemplo abaixo:

No exemplo abaixo, um disco que para o sistema operacional é exibido como sendo de 125G, na verdade tem mais 125G alocado para a HPA.

                       Conclusão
                       =========

Normalmente, quando a informação é armazenada tanto na HPA, ela não é acessível pelo BIOS, sistema operacional, ou pelo usuário. No entanto, algumas ferramentas podem ser usadas para acessar e modificar seu conteúdo.

Dado o potencial de colocar esses dados em áreas escondidas, esta é uma área de preocupação para os peritos computacionais.

Espero que isso não seja mais “grego” para você!!

Artigo publicado originalmente em http://gregoweblog.blogspot.com/2009/11/tecnicas-anti-forense-para-ocultacao-de.html

Fonte: www.dicas-l.com.br

Técnicas anti-forense para ocultação de dados

Colaboração: Alexandre Stratikopoulos

Informações podem ser armazenados em discos rígidos sem a utilização das estruturas e facilidades de um sistema de arquivos. Desse modo, informações consideradas valiosas para um processo de análise forense podem estar armazenadas não somente nos arquivos, mas também em áreas do disco que não são acessíveis através do funcionamento normal de um sistema de arquivos.

Diversas técnicas são utilizadas para a ocultação de dados, as quais podem ser aplicadas em 3 camadas:

- Camada de Hardware: MBR, HPA, DCO
- Camada do Sistema de Arquivos: Slack Spaces, ADS, Extended Attributes
- Camada de Aplicação: Esteganografia
       File Slack Space
       ================

Neste primeiro post, abordaremos a técnica denominada File Slack Space, que nada mais é do que a utilização dos espaços subaproveitados de um ou mais blocos de um sistema de arquivos para ocultar informações.

Os sistemas de arquivos armazenam as informações em disco utilizando blocos de dados de tamanho fixo (1Kb, 2Kb ou 4Kb). Contudo, os arquivos em um disco podem ter os mais variados tamanhos, dependendo do seu conteúdo. Desta forma, raramente o tamanho de um arquivo é múltiplo do tamanho de um bloco, o que impede seu armazenamento ideal. Sendo assim, é comum que o último bloco associado a um arquivo não seja totalmente utilizado por ele, permitindo que dados excluídos deste e de antigos arquivos possam ser capturados e analisados.

Isso não significa dizer que os slack spaces são espaços livres para armazenamento de dados de forma convencional. Os blocos que contém slack spaces são marcados pelo sistema operacional como utilizados e somente serão sobrescritos pelo sistema de arquivos caso o arquivo que o ocupa for expandido. Para o armazenamento, detecção e recuperação de informações em slack spaces, é preciso utilizar ferramentas especializadas, como por exemplo o bmap para sistemas de arquivos ext2/ext3 ou o slacker para NTFS. Essas ferramentas são necessárias pois o sistema operacional ignora as informações armazenadas em slack spaces, uma vez que não há alteração aparente no checksum ou no MAC

Time dos arquivos envolvidos.

       Bmap
       ====

Bmap é uma ferramenta forense que pode ser obtida de forma gratuíta. Após sua compilação, podemos ocultar ou recuperar alguma informação e/ou arquivo de forma bem simples.

Em primeiro lugar, devemos identificar algum arquivo já gravado que possua slack space. O comando abaixo exibe a espaço utilizado (277 bytes) pelo arquivo /etc/hosts e seu espaço livre (3819 bytes).

 [root@grego ~]# bmap –mode slack /etc/hosts
 getting from block 2148457
 file size was: 277
 slack size: 3819
 block size: 4096

Sabemos que o arquivo /etc/hosts possui 3819 bytes de espaço livre para armazenar informações. Antes de armazenar alguma informação no slack space, vamos extrair o checksum do arquivo:

 [root@grego ~]# md5sum /etc/hosts
 b0627774adcc1129143b2d1d08ecd133  /etc/hosts

Vamos extrair também as informações de MAC Time do arquivo, para compararmos com após a ocultação das informações:

 [root@grego ~]# stat /etc/hosts
 File: `/etc/hosts’
 Size: 277             Blocks: 16         IO Block: 4096   regular file
 Device: fd00h/64768d    Inode: 2131987     Links: 1
 Access: (0644/-rw-r–r–)  Uid: (    0/    root)   Gid: (    0/    root)
 Access: 2009-10-29 01:54:10.000000000 -0200
 Modify: 2009-09-18 12:55:16.000000000 -0300
 Change: 2009-09-18 12:55:16.000000000 -0300

Podemos ocultar um texto, binário ou imagem usando o pipe para direcionar a saída do comando para o programa bmap. O exemplo abaixo ilustra a ocultação de um texto simples:

 [root@grego ~]# echo “Hello World” | bmap –mode putslack /etc/hosts
 getting from block 2148457
 file size was: 277
 slack size: 3819
 block size: 4096

Podemos confirmar que o MAC Time e o checksum não foram alterados:
 [root@grego ~]# md5sum /etc/hosts
 b0627774adcc1129143b2d1d08ecd133  /etc/hosts
 [root@grego ~]# stat /etc/hosts
 File: `/etc/hosts’
 Size: 277             Blocks: 16         IO Block: 4096   regular file
 Device: fd00h/64768d    Inode: 2131987     Links: 1
 Access: (0644/-rw-r–r–)  Uid: (    0/    root)   Gid: (    0/    root)
 Access: 2009-10-29 01:54:10.000000000 -0200
 Modify: 2009-09-18 12:55:16.000000000 -0300
 Change: 2009-09-18 12:55:16.000000000 -0300

Para listar o conteúdo armazenado no slack space de um arquivo, o comando abaixo pode ser executado:
 [root@grego ~]# bmap –mode slack /etc/hosts
 getting from block 2148457
 file size was: 277
 slack size: 3819
 block size: 4096
 Hello World

Para apagar o conteúdo armazenado no slack space, preservando o conteúdo original de um arquivo, o comando abaixo pode ser executado:

 [root@grego ~]# bmap –mode wipe /etc/hosts
Para identificar se um arquivo têm seu slack space utilizado, podemos utilizar o comando abaixo:
 [root@grego ~]# bmap –mode checkslack /etc/hosts
 /etc/hosts does not have slack
       Conclusão
       =========

A análise de informações extraídas das áreas não acessíveis através de um sistema de arquivos é, na maioria das vezes, um processo tedioso e demorado já que esses dados geralmente constituem um fluxo de bits sem estrutura alguma aparente. Porém, com o uso de ferramentas adequadas, pode-se obter bons resultados no processo investigativo.

Espero que isso não seja mais “grego” para você!!

Artigo publicado originalmente em http://gregoweblog.blogspot.com/2009/10/tecnicas-anti-forense-para-ocultacao-de.html

Fonte: http://www.dicas-l.com.br

Balanceamento de carga com Iptables

Balanceamento de Carga com Iptables
===================================

Colaboração: Everson de Oliveira

Neste artigo vamos mostrar um modo simples e rapido de balanceamento de carga utilizando regras de IPTABLES.

Cenário:
========
user > Firewall IPTables >

> Server Apache A

> Server Apache B

Obs: Vale lebrar que o conteúdo deverá ser igual nos dois servidores, isto é, caso queira colocar isso em produção.

Vamos ao que interesa. Apenas faça o seguinte:

# Regra 1
$IPTABLES -A PREROUTING -t nat -d 200.xxx.xxx.1 -j DNAT –to 192.168.1.1-192.168.1.2

# Regra 2
$IPTABLES -A POSTROUTING -t nat -s 192.168.1.1 -j SNAT –to 200.xxx.xxx.1

# Regra 3
$IPTABLES -A POSTROUTING -t nat -s 192.168.1.2 -j SNAT –to 200.xxx.xxx.1

Repare que utilizei –to 192.168.1.1-192.168.1.2 (dois hosts). Poderia usar –to 192.168.1.1-192.168.1.10 (que significa que estarei dispondo de um range de 10 hosts no load balance).

Everson de Oliveira é Analista de Redes da Escola do Futuro – USP

Fonte: http://www.dicas-l.com.br/dicas-l/20090915.php

Gerando hash MD5 dos arquivos no linux

Uma forma bastante interessante de se manter um controle sobre os arquivos, principalmente os de sistema, é gerar o hash dos principais arquivos e guardar em uma tabela para futuras pesquisas.

Gerando o hash de um arquivo, se houver qualquer tipo de alteração nele, ao rodar novamente o cálculo do hash MD5, o resultado do hash será diferente do resultado original.

No linux, você pode gerar o hash MD5 de um arquivo digitando o seguinte comando:

md5sum arquivo

Por exemplo, um cálculo de hash em um arquivo ficaria assim o resultado:

md5sum dic.txt

8f1d3d9518b9a09acf68c9db12ef29ac  dic.txt

Vamos alterar esse arquivo, acrescentando uma linha e após salvar, gerando novamente a função hash, teremos um novo resultado:

md5sum dic.txt

49526713e47393a7ffcb532fcff8fe9a  dic.txt

Ou seja, dessa forma, você poderá fazer um hash md5 de seus arquivos e quando precisar, verificar o hash para saber se ocorreu alguma alteração.

Como montar uma pasta compartilhada do windows 2003 no diretório /media no linux

Passei por uma situação que precisei montar uma pasta compartilhada, localizada no servidor Windows 2003, dentro do diretório “/media/srv” no meu linux Ubuntu, para rodar o comando ‘wipe’, por linha de comando.

Para tanto, após várias tentativas frustradas, recorri ao meu network para auxiliar em minha necessidade pontual. Dito e feito. Consegui o resultado esperado, mediante a sugestão de executar o seguinte comando:

sudo mount -t cifs //IPSERVIDOR/PASTACOMPARTILHADA -o username=LOGIN_WINDOWS,password=SENHA /media/srv

Como o servidor é um Windows Server 2003, tinha que montar com o tipo de sistema “cifs”. o Username e Password tem que ser a conta que tenha permissão de acesso a pasta.

Agradeço as sugestões dos amigos Marcos Lisboa e, em especial, do Carlos Renato, que com o comando sugerido acima, consegui montar a pasta compartilhada e permitir a execução do wipe, por linha de comando.

Problema no wireless após atualização do Kernel no Ubuntu 9.04

Eu tive um sério problema no meu notebook, depois que me “aventurei” na atualização do mais novo Kernel para o Ubuntu 9.04, a versão 2.6.28-13-generic.

A primeira consequência, nada agradável, foi a imediata parada no funcionamento da minha wireless. Ao rebootar a máquina, percebi que meu wireless lia os drivers, o Kernel atribuia o Firmware corretamente conforme o módulo do meu Bradcom43, mas não conseguia detectar as redes wireless.

De posse dos logs (syslog e message – ambos em /var/log), verifiquei que quando meu noteboot tentava conectar a rede da minha empresa e em minha casa, ambas configurações eu utilizo WPA2 – PKS, acontecia um erro, conforme listado abaixo:

NetworkManager: nm_setting_802_1x_get_pkcs11_engine_path: assertion `NM_IS_SETTING_802_1X (setting)’ failed

Pesquisando na internet, o problema era em respeito a um bug no NetworkManager sobre o módulo que gerencia as conexões wireless com criptografia WAP.

Solução:

Basta instalar o pacote “linux-backports-modules-jaunty” com o apt-get e depois, reiniciar o computador.  Digite o comando:

sudo apt-get install linux-backports-modules-jaunty

Pronto, minha rede wireless com WPA voltou a funcionar normalmente.

Até a próxima.

Rootkits de kernel e de biblioteca

No mundo forense computacional, é importante antes de iniciarmos uma investigação propriamente dita, recorrer a um planejamento prévio sobre o ambiente encontrado, as possibilidades e caminhos a serem percorridos para que tenhamos sucesso na empreitada.

Quando um Perito Forense é destacado para periciar um computador, ele deverá observar se o equipamento em questão que será periciado, está com o seu sistema de arquivos intacto ou modificado por algum tipo de ferramenta que “manipula” o sistema operacional de modo que as informações passadas no momento da perícia estejam comprometidas, objetivo este das ferramentas do mundo “Underground” conhecidas como “RootKits”.

Um rootkit é um conjunto de ferramentas que quando instalado no computador, pode comprometer todo o sistema operacional, alterando as permissões de acesso de arquivos de sistema, que originalmente eram somente leitura e agora passam a ter permissão de escrita.

Quando o RootKit é instalado com o objetivo de alterar os módulos que são carregados durante a iniciação do Kernel, chamamos de RootKit de Kernel, no qual ele compromete determinados módulos do núcleo do kernel, fazendo com que a máquina já esteja comprometida desde o boot do sistema operacional.

No caso de comprometimento de determinados comandos de sistemas somente, como os comandos de listagem em tela, impressão, etc, onde o conjunto de ferramentas se preocupam com os arquivos de sistemas, chamamos de RootKits de Biblioteca, normalmente no linux encontramos no arquivo libproc.

Contudo, um bom perito, deve conhecer sobre RootKit, identificar e analisar as suas atividades no computador comprometido, senão, as informações colhidas e repassadas para um laudo pericial forense, não terão validade jurídica e assim, estará fadado aos questonamentos inerentes a perícia e as informações apresentadas não fidedígnas do sistema operacional, visto que o equipamento em questão, está comprometido com o rootkit instalado.

Mapeamento passivo no Linux: p0f

Achei interessante um capítulo do Livro “Segurança em rede sem fios” de Nelson Rufino, no tocante ao assunto de mapeamento passivo. Existem várias ferramentas para visualizar as movimentações de dados pela rede, sem necessariamente está autenticado à rede alvo.

Testei e gostei muito da ferramenta “p0f” (letra P, número zero, letra F). Tem no repositório do ubuntu e para instalar, basta digitar o seguinte comando como root:

apt-get install p0f

Para executar a ferramenta, basta digitar o comando abaixo, logado como root:

p0f

Ou se preferir, pode informar em qual interface você quer “escutar” a rede alvo:

p0f -i wlanO

Essa técnica é muito interessante quando se quer observar os possíveis alvos, sem ser notado.

Roney Médice

Analista de Sistemas e Bacharel em Direito

Como remover servicos do boot no linux

Estava configurando um servidor proxy no  linux (Squid), com autenticação no AD (Windows Server) através do Winbind. Verificando os serviços que estavam sendo iniciados no servidor linux, observei que um daemon ‘Bluetooth” estava sendo inicializado também no boot de forma desnecessária, porque eu não uso nenhum device (dipositivo) de bluetooth no servidor.

Com isso, tentei alterar as configurações de iniciação desse serviço com o seguinte comando (logado como root):

chkconfig –level 35 bluetooth off

Ou seja, tentei setar para que ao inciar o linux com o boot na opção do init em nivel 3 ou 5, esse daemon estaria desligado (off) e não seria carregado o módulo.

Porém, ao executar esse comando, apresentou a seguinte lista de erros:

insserv: warning: script ‘S01linux-restricted-modules-common’ missing LSB tags and overrides
insserv: warning: script ‘K01gdm’ missing LSB tags and overrides
insserv: warning: script ‘K20acpi-support’ missing LSB tags and overrides
insserv: warning: script ‘S10powernowd.early’ missing LSB tags and overrides
insserv: warning: script ‘S28NetworkManager’ missing LSB tags and overrides
insserv: warning: script ‘S10xserver-xorg-input-wacom’ missing LSB tags and overrides
insserv: warning: script ‘S05vbesave’ missing LSB tags and overrides
insserv: warning: script ‘S10udev’ missing LSB tags and overrides
insserv: warning: script ‘S08loopback’ missing LSB tags and overrides
insserv: warning: script ‘S37udev-finish’ missing LSB tags and overrides
insserv: warning: script ‘vbesave’ missing LSB tags and overrides
insserv: warning: script ‘NetworkManager’ missing LSB tags and overrides
insserv: warning: script ‘udev’ missing LSB tags and overrides
insserv: warning: script ‘acpi-support’ missing LSB tags and overrides
insserv: warning: script ‘udev-finish’ missing LSB tags and overrides
insserv: warning: script ‘xserver-xorg-input-wacom’ missing LSB tags and overrides
insserv: warning: script ‘loopback’ missing LSB tags and overrides
insserv: warning: script ‘powernowd.early’ missing LSB tags and overrides
insserv: warning: script ‘linux-restricted-modules-common’ missing LSB tags and overrides
insserv: warning: script ‘gdm’ missing LSB tags and overrides
insserv: There is a loop between service mountall and checkfs
insserv:  loop involving service checkfs at depth 8
insserv:  loop involving service checkroot at depth 7
insserv: There is a loop between service mountall and checkfs
insserv:  loop involving service mtab at depth 8
insserv: There is a loop between service udev and hwclockfirst
insserv:  loop involving service hwclockfirst at depth 7
insserv:  loop involving service mountdevsubfs at depth 6
insserv:  loop involving service networking at depth 2
insserv:  loop involving service mountall at depth 1
insserv:  loop involving service hwclock at depth 15
insserv:  loop involving service udev at depth 22
insserv: exiting without changing boot order!
/sbin/insserv failed, exit code 1

Resultado, parti para o meio mais radical, e executei o seguinte comando (logado como root):

update-rc.d -f bluetooth remove

Quanta tranquilidade!! Na hora, resolveu o meu problema:

Removing any system startup links for /etc/init.d/bluetooth …
/etc/rc0.d/K74bluetooth
/etc/rc1.d/K74bluetooth
/etc/rc2.d/S25bluetooth
/etc/rc3.d/S25bluetooth
/etc/rc4.d/S25bluetooth
/etc/rc5.d/S25bluetooth
/etc/rc6.d/K74bluetooth

Espero ter ajudado aos desesperados com mais essa solução resolutiva.

Roney Médice

Analista de Sistemas e Bacharel em Direito

Fazendo rotate do Squid automaticamente

Fazendo rotate do Squid automaticamente
==============================

=========

Colaboração: Sérgio Abrantes

Data de Publicação: 09 de April de 2009

Mostrarei como fazer um rodízio dos arquivos de log do Squid que crescem
enormemente ao final de todo o mês, colocando-os na crontab para fazer esse
trabalhinho sujo. : D

O arquivo de log do Squid (access.log) cresce enormemente devido aos acessos
externos. O próprio Squid tem sistema de rotacionamento dos logs através
do comando “squid -k rotate”. Com esse comando, os arquivos vão ficando no
seguinte formato:

access.log.0
access.log.1
…

A idéia é fazer um rotacionamento ao final de todo o mês, criando um arquivo
de log com o mês e gerar um relatório mensal utilizando o SARG.

Porque fazer isso? Assim tiramos um relatório com o acesso de todo o mês
e geramos um arquivo com os acessos daquele mês. Caso seja necessário um
relatório de todo o mês, basta apenas juntar os logs e gerar.

Crontab
=======

Devemos inserir as datas e o script na crontab para realizar a tarefa. Segue
abaixo o conteúdo da crontab:

# Faz um logrotate do Squid
59 23 31 1 * /home/bkp_server/scripts/rotate_squid
59 23 28 2 * /home/bkp_server/scripts/rotate_squid
59 23 31 3 * /home/bkp_server/scripts/rotate_squid
59 23 30 4 * /home/bkp_server/scripts/rotate_squid
59 23 31 5 * /home/bkp_server/scripts/rotate_squid
59 23 30 6 * /home/bkp_server/scripts/rotate_squid
59 23 31 7 * /home/bkp_server/scripts/rotate_squid
59 23 31 8 * /home/bkp_server/scripts/rotate_squid
59 23 30 9 * /home/bkp_server/scripts/rotate_squid
59 23 31 10 * /home/bkp_server/scripts/rotate_squid
59 23 30 11 * /home/bkp_server/scripts/rotate_squid
59 23 31 12 * /home/bkp_server/scripts/rotate_squid

Ele executará o script que está em /home/bkp_server/scripts/rotate_squid ao
final do último dia de cada mês.

Script rotate_squid
===================

Segue o conteúdo do script:

#!/bin/bash
data=`date +%m`
ano=`date +%y`

if [ $data == "01" ] ;then
/usr/bin/sarg -f /usr/local/sarg/sarg.conf -d 01/01/$ano-31/01/$ano
cp -p /var/log/squid/access.log /var/log/squid/access.log-janeiro
cp -p /var/log/squid/cache.log /var/log/squid/cache.log-janeiro
cp -p /var/log/squid/store.log /var/log/squid/store.log-janeiro
cat /dev/null > /var/log/squid/access.log
cat /dev/null > /var/log/squid/cache.log
cat /dev/null > /var/log/squid/store.log

fi

if [ $data == "02" ] ;then
/usr/bin/sarg -f /usr/local/sarg/sarg.conf -d 01/02/$ano-28/02/$ano
cp -p /var/log/squid/access.log /var/log/squid/access.log-fevereiro
cp -p /var/log/squid/cache.log /var/log/squid/cache.log-fevereiro
cp -p /var/log/squid/store.log /var/log/squid/store.log-fevereiro
cat /dev/null > /var/log/squid/access.log
cat /dev/null > /var/log/squid/cache.log
cat /dev/null > /var/log/squid/store.log

fi

if [ $data == "03" ] ;then
/usr/bin/sarg -f /usr/local/sarg/sarg.conf -d 01/03/$ano-31/03/$ano
cp -p /var/log/squid/access.log /var/log/squid/access.log-marco
cp -p /var/log/squid/cache.log /var/log/squid/cache.log-marco
cp -p /var/log/squid/store.log /var/log/squid/store.log-marco
cat /dev/null > /var/log/squid/access.log
cat /dev/null > /var/log/squid/cache.log
cat /dev/null > /var/log/squid/store.log

fi
if [ $data == "04" ] ;then
/usr/bin/sarg -f /usr/local/sarg/sarg.conf -d 01/04/$ano-30/04/$ano
cp -p /var/log/squid/access.log /var/log/squid/access.log-abril
cp -p /var/log/squid/cache.log /var/log/squid/cache.log-abril
cp -p /var/log/squid/store.log /var/log/squid/store.log-abril
cat /dev/null > /var/log/squid/access.log
cat /dev/null > /var/log/squid/cache.log
cat /dev/null > /var/log/squid/store.log

fi

if [ $data == "05" ] ;then
/usr/bin/sarg -f /usr/local/sarg/sarg.conf -d 01/05/$ano-31/05/$ano
cp -p /var/log/squid/access.log /var/log/squid/access.log-maio
cp -p /var/log/squid/cache.log /var/log/squid/cache.log-maio
cp -p /var/log/squid/store.log /var/log/squid/store.log-maio
cat /dev/null > /var/log/squid/access.log
cat /dev/null > /var/log/squid/cache.log
cat /dev/null > /var/log/squid/store.log

fi

if [ $data == "06" ] ;then
/usr/bin/sarg -f /usr/local/sarg/sarg.conf -d 01/06/$ano-30/06/$ano
cp -p /var/log/squid/access.log /var/log/squid/access.log-junho
cp -p /var/log/squid/cache.log /var/log/squid/cache.log-junho
cp -p /var/log/squid/store.log /var/log/squid/store.log-junho
cat /dev/null > /var/log/squid/access.log
cat /dev/null > /var/log/squid/cache.log
cat /dev/null > /var/log/squid/store.log

fi

if [ $data == "07" ] ;then
/usr/bin/sarg -f /usr/local/sarg/sarg.conf -d 01/07/$ano-31/07/$ano
cp -p /var/log/squid/access.log /var/log/squid/access.log-julho
cp -p /var/log/squid/cache.log /var/log/squid/cache.log-julho
cp -p /var/log/squid/store.log /var/log/squid/store.log-julho
cat /dev/null > /var/log/squid/access.log
cat /dev/null > /var/log/squid/cache.log
cat /dev/null > /var/log/squid/store.log

fi
if [ $data == "08" ] ;then
/usr/bin/sarg -f /usr/local/sarg/sarg.conf -d 01/08/$ano-31/08/$ano
cp -p /var/log/squid/access.log /var/log/squid/access.log-agosto
cp -p /var/log/squid/cache.log /var/log/squid/cache.log-agosto
cp -p /var/log/squid/store.log /var/log/squid/store.log-agosto
cat /dev/null > /var/log/squid/access.log
cat /dev/null > /var/log/squid/cache.log
cat /dev/null > /var/log/squid/store.log

fi

if [ $data == "09" ] ;then
/usr/bin/sarg -f /usr/local/sarg/sarg.conf -d 01/09/$ano-30/09/$ano
cp -p /var/log/squid/access.log /var/log/squid/access.log-setembro
cp -p /var/log/squid/cache.log /var/log/squid/cache.log-setembro
cp -p /var/log/squid/store.log /var/log/squid/store.log-setembro
cat /dev/null > /var/log/squid/access.log
cat /dev/null > /var/log/squid/cache.log
cat /dev/null > /var/log/squid/store.log

fi

if [ $data == "10" ] ;then
/usr/bin/sarg -f /usr/local/sarg/sarg.conf -d 01/10/$ano-31/10/$ano
cp -p /var/log/squid/access.log /var/log/squid/access.log-outubro
cp -p /var/log/squid/cache.log /var/log/squid/cache.log-outubro
cp -p /var/log/squid/store.log /var/log/squid/store.log-outubro
cat /dev/null > /var/log/squid/access.log
cat /dev/null > /var/log/squid/cache.log
cat /dev/null > /var/log/squid/store.log

fi

if [ $data == "11" ] ;then
/usr/bin/sarg -f /usr/local/sarg/sarg.conf -d 01/11/$ano-30/11/$ano
cp -p /var/log/squid/access.log /var/log/squid/access.log-novembro
cp -p /var/log/squid/cache.log /var/log/squid/cache.log-novembro
cp -p /var/log/squid/store.log /var/log/squid/store.log-novembro
cat /dev/null > /var/log/squid/access.log
cat /dev/null > /var/log/squid/cache.log
cat /dev/null > /var/log/squid/store.log

fi
if [ $data == "12" ] ;then
/usr/bin/sarg -f /usr/local/sarg/sarg.conf -d 01/12/$ano-31/12/$ano
cp -p /var/log/squid/access.log /var/log/squid/access.log-dezembro
cp -p /var/log/squid/cache.log /var/log/squid/cache.log-dezembro
cp -p /var/log/squid/store.log /var/log/squid/store.log-dezembro
cat /dev/null > /var/log/squid/access.log
cat /dev/null > /var/log/squid/cache.log
cat /dev/null > /var/log/squid/store.log

fi

Logs
====

Agora veremos como os LOGs ficam após serem rotacionados.

# cd /var/log/squid
# ls -lrth
total 1.2G
-rwxr-xr-x 1 nobody users 22K 2008-02-28 16:35 cache.log-fevereiro*
-rwxr-xr-x 1 nobody users 111M 2008-02-28 22:59 store.log-fevereiro*
-rwxr-xr-x 1 nobody users 109M 2008-02-28 22:59 access.log-fevereiro*
-rwxr-xr-x 1 nobody users 46K 2008-03-31 16:50 cache.log-marco*
-rwxr-xr-x 1 nobody users 136M 2008-03-31 22:59 store.log-marco*
-rwxr-xr-x 1 nobody users 121M 2008-03-31 22:59 access.log-marco*
-rwxr-xr-x 1 nobody users 64K 2008-04-30 18:12 cache.log-abril*
-rwxr-xr-x 1 nobody users 160M 2008-04-30 23:58 store.log-abril*
-rwxr-xr-x 1 nobody users 102M 2008-04-30 23:58 access.log-abril*
-rwxr-xr-x 1 nobody users 229M 2008-06-12 17:17 store.log*
-rwxr-xr-x 1 nobody users 42K 2008-06-12 17:17 cache.log*
-rwxr-xr-x 1 nobody users 184M 2008-06-12 17:17 access.log*

Assim fica mais tranquilo para o SARG trabalhar também e os teus logs mais
organizados. : )

Conclusão
=========

Cuidar dos logs sempre é triste. Os scripts vão surgindo conforme a necessidade
de administração do servidor.

Esta foi uma alternativa que achei mais interessante para o meu caso. Caso
tentam sugestões de melhoria ou outras alternativas para solucionar este caso,
todas serão bem vindas.

Vivendo e aprendendo!

Fonte:   http://www.Dicas-L.com.br/dicas-l/

Roney Médice

Analista de Sistemas e Bacharel em Direito