O squid é um poderoso e conhecido proxy. É comum encontrarmos empresas que o utilizam para controlar o acesso dos funcionários à Internet, exigindo autenticação, além de implementar uma série listas de controle de acesso (ACL – Access Control Lists) sobre quais grupos de funcionários podem ver quais páginas.

Porém, um recurso que nem sempre é utilizado é a personalização das páginas de erro do Squid. As páginas que vem por padrão em geral estão em inglês, deixando os funcionários confusos acerca do que aconteceu, o que acaba sobrecarregando o suporte. Além disso, mesmo que utilizadas as páginas traduzidas que o Squid também fornece em alguns empacotamentos, o design é muito simples. As vezes a empresa acha interessante não só traduzir as mensagens, mas também formatar as páginas no padrão da sua Intranet, inserindo o logotipo, links para páginas úteis, ou outras informações relevantes.

É possível até mesmo criar páginas de erro únicas e personalizadas para cada ACL, para ser exibida caso a permissão de acesso àquela ACL seja negada.

Mão na massa

Alterar as páginas existentes

Quando o Squid é instalado via pacote, em geral ele já possui um diretório padrão onde as páginas de erro são armazenadas. Por exemplo, no Debian, elas ficam em /usr/share/squid/errors/English. Em outros empacotamentos, elas podem estar em /etc/squid/errors. De qualquer forma, é possível escolher qual o diretório que lhe agrada, procurando no squid.conf pelo parâmetro error_directory, alterando-o se desejar.

Estas páginas são arquivos html com nomes em maíusculas correspondente ao erro que as carregará. Por exemplo, quando o acesso for negado ao usuário, o conteúdo da página ERR_ACCESS_DENIED será exibido.

Após alterar as páginas, formatando-as a seu gosto, é preciso reiniciar o Squid para que as mudanças passem a vigorar.

Criar páginas únicas

Para criar uma página de erro que deve ser exibida em caso de uma ACL falhar é preciso procurar no squid.conf o parâmetro deny_info. O formato de uso para este parâmetro, conforme podemos ver na ajuda do squid.conf é:

  deny_info pagina_de_erro acl

ou

  deny_info http://URL acl

Exemplo

  deny_info erro_endereco_pornografia porn

Onde erro_endereco_pornografia é uma página HTML de erro, criada por você, explicando que aquele endereço que o usuário tentou acessar é de uma possível página pornográfica e porn é a ACL que lista os sites pornográficos. Se optar por ativar este parâmetro, não esqueça de criar a página erro_endereco_pornografia, colocá-la no diretório das páginas de erro e então reiniciar o Squid. Além disso, é possível, em vez de mostrar uma página de erro criada por você, redirecionar o usuário para um endereço web qualquer, substituindo erro_endereco_pornografia pelo endereço desejado.

Sistema Básico de permissões

O sistema básico de permissões é dado em três níveis principais: dono do arquivo (user, em inglês), grupo de usuários ao qual pertence o arquivo (group) e o restante (others). Dos termos em inglês utilizaremos u para representar o dono do arquivo, g para grupo e o para os outros.

Cada nível pode ter, por sua vez, três tipos de permissões: leitura (read, representado pela letra r), escrita (write, w) e execução (execute, representado pela letra x). A nomenclatura ugo e rwx, derivadas dos nomes em inglês para os níveis e permissões é comumente usada na Internet e será adotada neste tutorial.

O sistema garante o acesso de leitura, gravação ou execução dependendo do valor de um bit associado ao arquivo. Cada bit pode ter o valor de 0 ou 1. Existem então 9 bits para representar as permissões, pois são três níveis (ugo) vezes três permissões possíveis (rwx).

Vamos observar o as permissões de um arquivo de exemplo:

  $ ls -l index.html
  -rw-r--r--  1 daniduc webmasters 4632 2004-12-17 13:39 index.html
  $

Repare no -rw-r–r–. Essas são as permissões do arquivo. As três primeiras são para o dono do arquivo (daniduc), as três seguintes representam os direitos do grupo (webmasters) e as três últimas os dos demais usuários. Vamos destrinchá-las.

Os três primeiros bits são -rw. O traço representa o bit inativo (valor zero) e a letra o bit ativo (valor 1). Então vemos que o dono tem permissão de ler e escrever no arquivo, mas não executá-lo. Veja um teste:

  $ ./index.html
  bash: ./index.html: Permissão negada
  $

O sistema avisou que não há permissão para executar o arquivo, como esperado.

Assim, concluímos que o arquivo pode ser lido e escrito pelo seu dono e pelos membros do grupo que o possui, e os demais apenas podem lê-lo.

Agora veremos como alterar essas permissões. Para isso, é preciso entender como se referir numericamente à essas permissões. A teoria é muito simples. Vamos montar uma tabela de valores possíveis para os bits de leitura, gravação e execução, que podem estar desligados ( representados por 0) ou ligados (1)

  rwx
  000
  001
  010
  011
  100
  101
  110
  111

Ora, podemos converter os valores binários em decimais, e então a tabela ficaria assim:

  rwx - Valor octal
  000 - 0
  001 - 1
  010 - 2
  011 - 3
  100 - 4
  101 - 5
  110 - 6
  111 - 7

Assim fica fácil visualizar o valor numérico que representa nossa escolha de permissões. Se queremos que um arquivo tenha permissão de leitura, gravação mas não de escrita teremos o primeiro e o segundo bits ligados e o terceiro desligado, ou seja, 110, que em octal é 6. Agora basta aplicar o mesmo sistema para cada um dos níveis. Para representar as permissões do nosso arquivo de exemplo (rw-, rw-, r–) ficaria 110, 110, 100, ou seja 664.

Agora, suponha que eu queira dar a permissão de escrita para todo mundo no arquivo index.html. Bastaria dar o comando:

  $ chmod 666 index.html

Veja como fica:

  $ ls -l index.html
  -rw-rw-rw-  1 daniduc webmasters 4632 2004-12-17 13:39 index.html

Para retirar a permissão de escrita de todos e do grupo fica:

  $ chmod 644 index.html
  $ ls -l index.html
  -rw-r--r--  1 daniduc webmasters 4632 2004-12-17 13:39 index.html

Diretórios

Um diretório deve ter permissão de execução para que se possa entrar nele. Além disso, as permissões de um diretório tem precedência sobre as dos arquivos que ele contém. Veja um exemplo:

Primeiro temos um diretório pertencente ao usuário daniduc

  $ ls -ld /dir/
  drwxr-xr-x  2 daniduc daniduc 72 2005-04-19 03:14 /dir/
  $

Agora o usuário daniduc cria um arquivo dentro de /dir e em seguida dá à ele permissões totais para todos os usuários:

  daniduc $ cd /dir
  daniduc $ touch teste
  daniduc $ ls -l teste
  -rw-r--r--  1 daniduc daniduc 0 2005-04-19 03:14 teste
  daniduc $ chmod 777 teste
  daniduc $ ls -l teste
  -rwxrwxrwx  1 daniduc daniduc 0 2005-04-19 03:14 teste

Teoricamente, outro usuário poderia remover esse arquivo. Mas vamos ver que o usuário carla não consegue isso:

  carla $ ls -l teste
  -rwxrwxrwx  1 daniduc daniduc 0 2005-04-19 03:14 teste
  carla $ rm -f teste
  rm: impossível remover `teste': Permissão negada
  carla $

Isso se dá por causa das permissões do diretório no qual o arquivo teste está contido:

  drwxr-xr-x  2 daniduc daniduc 72 2005-04-19 03:14 /dir/

Vamos alterar as permissões do diretório para que todos tenham controle sobre ele, mas manter o arquivo teste exatamente igual:

  daniduc $ chmod 777 /dir
  daniduc $ -> ls -ld /dir
  drwxrwxrwx  2 daniduc daniduc 72 2005-04-19 03:14 /dir/
  daniduc $

Vamos ver agora se a carla consegue seu intento:

  carla $ ls -l teste
  -rwxrwxrwx  1 daniduc daniduc 0 2005-04-19 03:14 teste
  carla $ rm -f teste
  carla $ ls -l teste
  ls: teste: Arquivo ou diretório não encontrado
  carla $

Bits extras

Sticky Bit

Além dos bits básicos já vistos até agora, há ainda mais dois extras. O primeiro deles é o “sticky bit”, associado à diretórios e representado pela letra t. Caso este bit esteja ativado (com valor 1), o diretório não pode ser removido, mesmo que com permissão 777. Além disso, os arquivos criados dentro desse diretório só podem ser apagados pelo seu dono. Isso é muito útil em diretórios temporários, como o tmp, onde todos podem escrever:

  $ ls -ld /tmp/
  drwxrwxrwt    9 root     root        45056 2005-04-19 04:04 /tmp/
  $

Para ativar o sticky bit utiliza-se o valor 1 À frente das permissões já vistas:

  daniduc $ chmod 1777 /dir/
  daniduc $ ls -ld /biboca/
  drwxrwxrwt  2 daniduc daniduc 48 2005-04-19 03:30 /dir/
  daniduc $

SUID

Normalmente quando um arquivo é executado ele roda com os privilégios do usuário que o está executando. Mas há momentos em que isso precisa ser contornado. Por exemplo, para um usuário alterar sua senha ele chama o comando passwd. Esse comando precisa remover a senha antiga e inserir a senha nova no arquivo /etc/shadow. Porém, esse arquivo normalmente só pode ser alterado pelo root. Como fazer isso, se o passwd foi chamado pelo usuário comum?

A resposta é ativar o bit SUID. Com esse bit ativado o programa passa a rodar com as permissões do usuário dono do arquivo, e não mais de quem o invocou. O bit SUID é representado pela letra s logo após a área de permissões do usuário. Veja:

  daniduc $ ls -l /usr/bin/passwd
  -rwsr-xr-x  1 root root 26616 2004-11-02 19:51 /usr/bin/passwd
  daniduc $

Para se ativar o bit SUID com o comando chmod utiliza-se o valor 4 á frente das permissões básicas (ugo):

  daniduc $ touch teste
  daniduc $ ls -l teste
  -rw-r--r--  1 daniduc daniduc 0 2005-04-19 03:50 teste
  daniduc $ chmod 4755 teste
  daniduc $ ls -l teste
  -rwsr-xr-x  1 daniduc daniduc 0 2005-04-19 03:50 teste
  daniduc $

SGID

Similarmente ao BIT SUID, o SGID faz com que o arquivo seja executado com os privilégios do grupo ao qual pertence e não do usuário que o executa. O bit SGID é representado pela letra s logo após o conjunto de permissões do grupo. Para ativar o SGID, utilize o 2 no comando chmod:

  daniduc $ touch teste
  daniduc $ ls -l teste
  -rw-r--r--  1 daniduc daniduc 0 2005-04-19 04:06 teste
  daniduc $ chmod 2755 teste
  daniduc $ ls -l teste
  -rwxr-sr-x  1 daniduc daniduc 0 2005-04-19 04:06 teste
  daniduc $

ATENÇÃO: Não é aconselhável, por questões de segurança, ativar os bits SUID e GID em novos arquivos, especialmente se eles pertencerem ao root.

MÁSCARA

Quando criamos um arquivo ele é criado com permissões totais, ou seja, 666. Note que eles jamais são criados com permissão de execução. Isso em geral não é seguro, claro. Esse modo de criação pode ser alterado com o comando umask. Similarmente ao chmod, no qual se especifica quais bits devem ser desligados, o comando umask determina quais bits devem ser desligados.

Se você quer que os arquivos sejam criados sem permissão de escrita para o grupo e para os outros, então o comando ficaria assim:

  umask 022

Nenhum bit foi desligado para o dono, e o bit de escrita (010, ou 2 em octal) desligado para grupo e outros.

Esse comando está em geral incluído no arquivo /etc/profile ou arquivo equivalente que determina o ambiente para todos os usuários.

O nmon é um software free, disponibilizado pela IBM para análise de performance de servidores AIX. Ele coleta dados de performance que podem ser visualizados run time no prórpio servidor em modo texto, e, também pode realizar a coleta de dados para um arquivo que pode ser analizado posteriormente.

Além do agente de coleta, o nmon possui um analyser, que é uma planilha no formato excel, com macros já programadas que geram um arquivo excel, a partir do arquivo gerado na coleta, com tabelas e gráficos dos dados coletados.

Instalando o Nmon:

O software se encontra disponível em:

http://www-106.ibm.com/developerworks/eserver/downloads/nmon9a.tar.Z

O software se encontra disponível em um arquivo no formato .tar.Z.

Salve o arquivo .tar.Z em algum diretório no servidor em que se deseja instalar:

Descompacte o arquivo com o comando uncompress::

  # uncompress  nmon9a.tar

Extraia o conteúdo do arquivo::

  # tar -xvf nmon9a.tar
  x README.txt, 52572 bytes, 103 media blocks.
  x nmon32, 133748 bytes, 262 media blocks.
  x nmon64, 130462 bytes, 255 media blocks.
  x nmon_aix415, 116709 bytes, 228 media blocks.
  x nmon_aix420, 116907 bytes, 229 media blocks.
  x nmon_aix432, 119751 bytes, 234 media blocks.
  x nmon_aix433, 139715 bytes, 273 media blocks.
  x nmon_linux_pentium, 128402 bytes, 251 media blocks.
  x nmon_linux_power, 141404 bytes, 277 media blocks.
  x nmonnfs, 42959 bytes, 84 media blocks.
  x nmon2rrd, 41043 bytes, 81 media blocks.
  x nmon2rrd.c, 36741 bytes, 72 media blocks.
  #

O arquivo tar já contém os binários do nmon para kernel 32 e 64 bits do AIX 5 e os binários para as versões anteriores do AIX.

OBS: Podemos ver acima, que o arquivo tar, contém dois arquivos para linux. Não testei a ferramenta em linux mas pode ser que funcione também neste sistema operacional.

Copie os binários para um diretório de sua preferência (Ex: /usr/local/bin ou /usr/local/nmon/)

Crie um link simbólico chamado nmon apontando para o nmon que for utilizar.

Ex: utilizando o nmon32 em /usr/local/bin:

  # ln –s /usr/local/bin/nmon32 /usr/local/bin/nmon

Se o diretório que vc utilizou não estiver configurado no PATH, inclua-o::

  # PATH=$PATH:<diretorio do nmon>:.

Acompanhando desempenho do servidor runtime

Para acompanhar o desempenho de performance run time no servidor::

  # nmon

  nmon v7a [H for help]  Hostname=servidorX  Refresh=2.0secs  12:30.14

   ------------------------------       For help type H or ...
   #    #  #    #   ####   #    #        nmon -?  - hint
   ##   #  ##  ##  #    #  ##   #        nmon -h  - full
   # #  #  # ## #  #    #  # #  #
   #  # #  #    #  #    #  #  # #       To start the same way every time
   #   ##  #    #  #    #  #   ##        set the NMON ksh variable
   #    #  #    #   ####   #    #
   ------------------------------

   Use these keys to toggle statistics on/off:
      c = CPU             l = Long-term CPU         - = Faster screen updates
      m = Memory          k = Kernel Stats          + = Slower screen updates
      d = Disks           a = Adapters (disk only)  v = Verbose hints
      r = RS6000/pSeries  n = Network               U = command arguments
      j = JFS             t = Top-processes (1, 2 or 3 - different data)
      e = ESS Disks       . = show only busy disks/processes

      h =more options

Selecione a opção desejada e veja os dados de CPU, memória, etc.

Coletando dados para um arquivo

Para coletar os dados gerados pelo nmon num arquivo para análise posterior, exeute o seguinte comando::

  nmon -F <nomedoarquivo.nmon> -r <titulodentrodoarquivo> \
  -s <intervalo da coleta em seg> -c <qtde de coletas>

Exemplo:

Coletar por 2 horas, com intervalo de 1 minuto::

  nmon –F coleta.nmon –r ServidorX –s 60 –c 120

Ele ficará sendo executado em background até que as coletas finalizem.:

  # ps -ef |grep nmon
  root 46538 1 0 11:00:01 -  0:01 nmon -F /arquivo.nmon -r ServidorX -s 60 -c 420
    root  87418 159052   1 13:01:15 pts/13  0:00 grep nmon

  #

Para analisar os dados gerados pelo nmon com o Analyser:

1. – O nmon-analyser se encontra disponível em:http://www-106.ibm.com/developerworks/eserver/downloads/nmon_analyser.zip
2. – Fazer o download do arquivo para sua estação de trabalho e extrair o arquivo .zip em um diretório de sua preferência.

No servidor:

1. - Converter o arquivo gerado pelo nmon para .csv utilizando o script nmon2csv, obtido junto ao arquivo .zip do analyser::

     #./nmon2csv nomedoarquivo.nmon
     Saving ./nomedoarquivo.nmon.csv
     #
   

2. - Transferir o arquivo .csv para a estação de trabalho
3. - Abrir a planilha nmon_analyser_v301.xls no excel, habilitar as macros, clicar em “Analyse nmon data” e selecionar a planilha .csv de coletas. Após feito isso será gerada um planilha excel com os dados em tabelas e os gráficos gerados, podendo-se salvar a planilha de análise.

Links:

Nmon:

http://www-106.ibm.com/developerworks/eserver/articles/analyze_aix/

Os termos de licença podem ser visualizados em:

http://www-106.ibm.com/developerworks/eserver/articles/analyze_aix/agree_down.html

Nmon-Analyser:

http://www-106.ibm.com/developerworks/eserver/articles/nmon_analyser/#5

Os termos de licença podem ser visualizados em:

http://www-106.ibm.com/developerworks/eserver/articles/nmon_analyser/agree_down.html

Mas… IPs não são como casas, são mais como prédios: A Law & Order está no 1° andar do prédio da Paulista 452 e minha casa esta no 10° andar. Você pode ir ao Consulado Japonês, que também está no 452 da Paulista, mas no 7° andar.

Então o endereço IP é como se fosse o endereço do prédio (Av. Paulista, 452) e o andar, ou conjunto é como se fossem as portas TCP.

Então uma conexão TCP/IP entre seu micro e a UOL, para pegar a página web deles, resumidamente, seria assim:

  | seu micro  |                                  | home.uol.com.br|
  | ip 1.2.3.4 |                                  | ip 200.221.2.51|
  | porta 1025 |------- pedido de conexão web --->| porta 80 (web) |

Ai a uol responde:

  | seu micro  |                                  | home.uol.com.br|
  | ip 1.2.3.4 |                                  | ip 200.221.2.51|
  | porta 1025 |<------- ta, recebi seu pedido ---| porta 80 (web) |

continua:

  | seu micro  |                                  | home.uol.com.br|
  | ip 1.2.3.4 |                                  | ip 200.221.2.51|
  | porta 1025 |------- entao manda os dados ---->| porta 80 (web) |

Então vai a página:

  | seu micro  |                                  | home.uol.com.br|
  | ip 1.2.3.4 |                                  | ip 200.221.2.51|
  | porta 1025 |<--------- pagina da uol ---------| porta 80 (web) |

Existem 65535 portas tcp. Se convencionou que serviços em geral estariam escutando (esperando conexões) nas portas ditas baixas, abaixo de 1024, e as portas de retorno, as que receberiam respostas a pedidos de conexão, seriam acima de 1024. Mas isso é só uma convenção, existe um monte de serviços que ouve em porta alta. Se convencionou também colocar certos serviços escutando em certas portas. Se você quer paginas web, você vai se conectar direto na porta 80 do servidor. Nada te impede de colocar um servidor web escutando na porta 1234, porém o cara que iniciar a conexão terá que especificar essa porta pra poder conectar. Caso contrário o browser irá se conectar direto na porta 80, que é a padrão. Isto explica as URLs no formato http://www.lala.com:1234/. O “:1234″ da URL é o que especifica a porta em que o servidor web está esperando conexões, porque o browser não tem como adivinhar que você, no mundo, encanou de colocar seu web server na porta 1234.

Vamos pro proxy. Proxy, em inglês, quer dizer muitas coisas, inclusive procurador.

Então, o proxy fica num servidor e intermedia as conexões web para seus clientes, ou seja:

Em vez de você pedir a página pra uol.com.br como normalmente acontece:

  | seu micro |------------------->| home.uol.com.br |
  |           |<-------------------|                 |

Você pede pro proxy, que pede pra uol, que devolve pro proxy, que devolve pra você, assim:

| seu micro |------->| proxy |-------->| home.uol.com.br |
|           |<-------|       |<--------|                 |

E pra que isso? Uma serie de motivos vem a mente.

• Economia de banda: você só precisa do link do proxy. E uma vez que ele armazena uma cópia da página que voce pediu antes de te entregar, caso 3 segundos depois o seu colega, o qual também está usando proxy, pedir a mesma página, não precisa baixar da uol, o proxy entrega a cópia local, sendo muito mais rápido e consumindo menos banda.
• Controle: Se você só deixa o seu proxy navegar (via firewall), as pessoas são obrigadas a pedir todas as páginas pro proxy. E ai você pode controlar quem está acessando o que, e quem pode acessar o que. Em empresas isso é muito requisitado.

Enfim, você configura seu browser pra usar o proxy e esse esquema funciona. Além disso existe o famoso proxy transparente! Ou seja, voce não configura nada no seu browser e acha que está pedindo a página pra uol, mas não está! Sua conexão com a uol foi interceptada, sem você saber, pelo proxy, que intermedia a transação. É o que fez a Telefônica no Speedy, por exemplo.

Existem na internet os proxys abertos, ou “open proxys”. São micros que agem como proxy, porém para qualquer um que quiser usar. Assim qualquer um pode configurar o seu browser para navegar usando um “open proxy” que estja, por exemplo, na Tailândia. O site web que receber a conexão vai achar que você está vindo da Tailândia, porque quem está intermediando a sua navegação é o open proxy. E assim é possível mascarar o seu endereço IP de origem para o site que você está visitando. Por isso open proxys são considerados grandes riscos de segurança por alguns ou como instrumento útil de privacidade por outros, dependendo de como encaram a coisa.

Este é o básico de conexões TCP e proxys.

Nesse tópico será discutido um pouco sobre o sistema Linux, porém será abordado com mais profundidade a filosofia da qual é fruto direto e uma das grandes responsáveis pelo seu sucesso: O Free Software, ou Software Livre. Neste texto me refiro à FSF, ou seja, a Free Software Foundation. Apesar da FSF ser, até onde eu saiba, criadora e líder do movimento Software Livre, não é a única a propô-lo e software livre não é sinônimo de FSF. Alguns dos links que passo ao longo do texto estão em inglês.

A Origem

Em 1984, Richard M. Stallman descobriu que software proprietário fazia vítimas diretas, quando ele mesmo se tornou uma delas. A partir daí, resolveu fundar a Free Software Foundation, do qual o Linux é filho direto. Vamos ver como foi:

A história começou no laboratório em que Richard trabalhava (Artificial Intelligence Lab, no MIT) com uma impressora Laser, doada pela Xerox. A impressora era um presente caro e legal, mas tinha um problema: não era estável. Freqüentemente o papel travado e as impressões paravam. Ai, quando o usuário vinha buscar a impressão que ele estava esperando há meia hora, descobria que a impressora tinha travado há 27 minutos! Assim, ele arrumava a impressora e voltava pro seu micro e esperava mais outra hora e descobria que a impressora tinha funcionado por mais 2 minutos e parado de novo! Isso era profundamente irritante para os usuários.

Agora, a impressora que eles tinham antes desta também era instável. O que eles faziam antes para lidar com o problema? Bem, como eles não conseguiam melhorar o hardware da impressora, então adicionaram funções ao seu driver. Uma delas fazia com que aparecesse um aviso na tela de todos os usuários que aguardavam uma impressão dizendo quando esta estava pronta ou que o papel tinha enguiçado novamente. Quando havia problemas, alguém sempre aparecia para resolver, e ensinava aos outros que tinham ido como fazê-lo. E sempre se sabia quando a impressão estava pronta, de modo que ninguém esperava a mais. Mas então porque eles não fizeram o mesmo com o driver da impressora nova? Porque o driver era proprietário da Xerox, e só estava disponível de forma binária. Para que seja possível modificar um programa é necessário seu código fonte, que é o programa em uma linguagem que um humano entende (a forma binária é a forma que uma máquina entende e executa, mas um humano não consegue decifrar). Sem o código fonte eles estavam impotentes para mudar algo que os atrapalhava no serviço!!

Quando soube que um colega de outra universidade tinha o fonte para esse driver, ele foi até lá e pediu. E o colega negou. Seu colega tinha assinado um acordo de não divulgação, que o impedia legalmente de compartilhar essa informação com quem quer que fosse! Nesse ponto, os softwares com que o laboratório trabalhava tinham sido extintos, pois estavam obsoletos. Stallman precisaria trabalhar com softwares novos. E para fazer isso ele teria que assinar um acordo igual ao ao de seu colega. Como tinha sido uma vítima desse acordo, ele não poderia assinar um desses! Chegou a um impasse, pois todos os novos softwares requeriam assinar um acordo deste tipo. Ele tinha algumas opções: assinar, pegar o dinheiro e se divertir escrevendo softwares, sem pensar em mais nada, ou desistir de ser programador e fazer outra coisa. Mas isso seria muito pouco divertido pra ele, além de desperdiçar suas habilidades de programador. Sua decisão foi sair da MIT e fazer Free Software Foundation, com a proposta de lutar para que as pessoas pudessem ter acesso a softwares livres, com direito a olhar seu código fonte, modificar e distribuir os programas livremente, promovendo o livre fluxo de idéias na área de softwares. O objetivo da FSF era deixar o poder na mão das pessoas e não apenas das corporações.

Isso deve ser feito de uma maneira que a liberdade sempre exista e não possa ser negada em momento algum. Foi criado um conceito novo de copyright, o copyleft, como veremos mais adiante. Mas primeiro, vamos definir o que é um software livre.

Free Software – Software livre – O que é?

A FSF acredita que todo o software deve ser livre. Livre não quer dizer necessariamente grátis, atenção! Sim, você programador deve ser pago pelo seu programa. Eles dizem também que há 4 níveis de liberdade de software. Vejamos:

A liberdade de rodar o programa para qualquer fim (liberdade 0).

Liberdade para estudar como o programa funciona e adaptá-lo às suas necessidades. (liberdade 1). Acesso ao código fonte é um pré-requisito para isto.

A liberdade de distribuir cópias, de modo que possa ajudar seu próximo (liberdade 2).

Liberdade de melhorar o programa e liberar essas melhorias ao público, de maneira que toda a comunidade possa se beneficiar disso. (Liberdade 3). Acesso ao código fonte é um pré-requisito para isto.

(traduzido de: http://www.fsf.org/philosophy/free-sw.html )

O software livre permite a liberdade de ajudar a si mesmo a ao seu próximo sem ser chamado de pirata, ladrão, ou ser considerado fora da lei e ameaçado de prisão e multa. Ajudar a si mesmo e à sua comunidade sem prejudicar ninguém é um impulso normal que deve ser encorajado, e as empresas de Software Proprietário vão contra esse impulso. Elas o fazem ao não permitir a existência dessas liberdades em seus softwares. Elas insistem em aplicar a mesma lógica de objetos materiais e livros ao uso de software, quando são coisas diferentes. A existência dessas liberdades não prejudica a empresa produtora de software! Isso é discutido um pouco melhor no tópico Software livre: idealismo prático, mas aconselho fortemente a ler esse artigo .

Mantendo a liberdade no software

Mas o que impede de você escrever o seu código e vir um espertinho, usar ele e não divulgar novamente as mudanças que ele, espertinho, fez? Para isso a FSF criou um novo conceito de copyright: o copyleft. Copyleft é um trocadilho (right pode ser direito ou direita, left quer dizer esquerda =).

O copyleft diz que se você usa qualquer parte de um código que era copyleft antes o seu novo código deve ser, necessáriamente, copylefted também. Ou seja, se eu uso código livre no meu novo programa, meu novo programa também tem que ser livre tanto quanto o original era! Eu não posso pegar a idéia de um software livre, fazer meia dúzia de alterações e fechar o código! Liberdade requer regras, não é mesmo? =) A mais famosa das licenças de software livre é a GNU GPL, a GNU General Public License, ou Licença Geral Pública da GNU. Você pode achá-la em: http://www.fsf.org/copyleft/gpl.html

Existem outras!

Software livre: idealismo prático

Agora a liberdade de ajudar a você mesmo e ao seu próximo dessa maneira não é, de modo algum, incompatível com o fato das pessoas ganharem dinheiro. Nem as empresas.

a) Bom, digamos que a sua concorrente vai lá e pega seu programa e usa para fazer um programa que concorre com o seu.

Isso não é problema! Afinal, ele vai ter que liberar o código dele também (veja o tópico “Mantendo a liberdade no software”, acima) e o inverso é verdadeiro: você pode pegar o código dele e melhorar o seu! daremos um exemplo prático, antes de teorias: A Red Hat pegou o que o Linus Torvalds tinha feito e fez sua distribuição de Linux. Ela acrescentou o rpm, uma tecnologia de gerenciamento de pacotes. A Conectiva foi lá e pegou o que a Red Hat tinha feito e se tornou sua concorrente direta. Assim como a SuSE e a Mandrake. E nem por isso a Red Hat faliu ou perdeu milhões. Ao contrário, seus donos ficaram bilionários. Porque o software dela continuou evoluindo e melhorando, e competindo com seus filhotes, no melhor estilo capitalista! Gerando receita sem cercear a liberdade de ninguém. Agora, veja: a Conectiva pegou o apt da Debian e adaptou ao rpm, tornado a tecnologia criada pela Red Hat muito melhor. E agora a Red Hat pode pegar isso e usar e tornar sua distribuição ainda melhor!

b) Ah, mas se é de graça ninguém vai querer comprar o meu software. Ai não vou ganhar dinheiro!

Bem, isso simplesmente não é verdade. Em primeiro lugar, software livre não é de graça necessariamente. A própria GNU vende softwares e aliás bem caro para os meus padrões. A Conectiva e a Red Hat vendem CD’s em caixinhas bonitas. E com preços nada simbólicos. Mas você pode pegar a distribuição da Conectiva e/ou da Red Hat até de uma empresa que ganha dinheiro vendendo os CD’s mais baratos (US$2,00) ou até de graça no ftp delas. Por que essas empresas estão tão ricas? Porque muita gente quer comprar a caixinha da Red Hat ou da Conectiva. Elas gostam do manual, por exemplo. Elas querem garantia na mídia. Elas acham muito caro ou chato esperar horas de download de um ftp. Faça o teste (eu já fiz): Vá numa empresa que te contratou para instalar Linux e leve seu cd gravado de casa. Você verá que o gerente vai preferir gastar 220 reais na caixinha, porque ele quer os manuais. Diga para ele que os CD’s são iguais e que não é crime usar o seu gravado de casa. Ele vai preferir a caixinha. Eu já fiz esse teste em pelo menos 10 empresas. E tem a questão do suporte. Muitas pessoas não querem aprender, tem dúvidas, enfim precisam de ajuda com seu software livre. Elas querem pagar por essa ajuda. Quem elas irão chamar para dar suporte? Quem melhor do que fez esse software?? E se você não quiser dar suporte. Digamos que uma empresa quer um novo feature no seu programa livre, específico pra ela… Quem ela irá chamar? Quem fez o original, na maioria dos casos. De qualquer forma, os caminhos para se ganhar dinheiro são muitos, e eu não estou empilhando teorias, estou empilhando exemplos reais de companhias que vivem disso e tem muito dinheiro. A Red Hat é um exemplo.

O movimento Free Software está tão forte que até as grandes do mercado estão aderindo. Ou você acha que Intel, IBM, SUN são pequenas? Só para citar alguns poucos exemplos.

(IBM: http://www2.uol.com.br/info/aberto/infonews/032001/13032001-13.shl) (SUN: liberou o StarOffice como software livre, sob a GNU GPL: http://www.openoffice.org) (Intel: http://www.stti-usa.com/VentureC.htm , olhe na parte em que a Intel investe!)

c) Ah, eu não consigo usar Free Software, não tem nada lá para mim!

Bem, este pode ser um estado em que o Free Software não atende ainda suas necessidades diretas. É uma pena, e isso é culpa direta de empresas que renegam a ética nos negócios e prendem você nos grilhões do software proprietário! Mas não deixe esse estado de coisas te desanimar! Apoie o software livre em todas as suas formas, para que este estado de coisas evolua ate você ter escolhas múltiplas, ou seja, liberdade! Então Free Software tem algo para você: liberdade!

E o Linux? Como entra? Por que GNU/Linux?

Bom, quando Richard Stallman resoveu sair do MIT e fundar a Free Software resolveu começar fazendo um sistema operacional livre. Sem um Sistema Operacional um computador não consegue operar! Então era básico ter um SO livre. Para isso ele decidiu algumas coisas. Uma delas é que o Sistema Operacional deveria ser compatível com um Sistema da época, de modo que os usuários tivessem menos trabalho para mudar. E ele optou, por uma série de razões, pelo UNIX para ser compatível. Como o UNIX era modular, era só ir escrevendo os componentes e ir substituindo os do UNIX pelos do novo sistema operacional. Esse sistema ficou conhecido como GNU. GNU é uma sigla recursiva, seguindo um costume entre os programadores que é de criar nomes engraçadinhos. GNU quer dizer GNU’s Not UNIX, ou seja GNU Não é UNIX. =)

Aos poucos as peças do GNU foram sendo feitas e desenvolvidas até que em 1991 eles tinha quase todas as peças, menos uma peça muito importante! O kernel! O kernel é o cerne, o coração do sistema operacional. Pode-se dizer que o kernel é o Sistema Operacional em si, sendo que as outras peças são ferramentas para o sistema ou para o usuário. Neste ponto entra o Linux. Em 1991/92 Linus Torvalds desenvolveu um kernel bastante bom, chamado Linux. E registrou ele sob a licença do GNU, a GNU-GPL. Mas um kernel sozinho não faz nada sem as outras ferramentas para torná-lo usável! E quando foram buscar, acharam as ferramentas da GNU.

Assim colocaram o kernel Linux no sistema GNU, crinado o GNU/Linux, embora muita gente chame só de Linux. Richard Stallman faz questão de chamá-lo GNU/Linux, explicitamente, mas eu não sou tão radical, embora acredite que você pode se beneficiar ao saber da história do Software Livre e como o Linux se encaixa nessa história. Por isso fiz essa página =P Caso você tenha curiosidade, a FSF está desenvolvendo um kernel próprio que está começando a ficar usável, o HURD. Já existe uma distribuição de GNU/HURD, feita pela Debian.

Mais sobre em: http://www.fsf.org/gnu/why-gnu-linux.html

Como Contribuir

Bom, a maneira mais lógica e óbvia de contribuir é, se você é um programador, criar software livre, e registra-lo com um copyleft, como a GNU GPL, por exemplo. Se você não programa, você pode escrever documentação sobre software livre. Você pode usar software livre. Isso já é uma grande contribuição. Se não existe software livre que atenda as suas necessidades, mas existe software proprietário, você pode pedir para sua companhia fazer versões livres do software que você usa e gosta. Isso não é utopia, ( “Ah, eles nunca vão liberar” ), isso se chama pressão de mercado. Você não está sozinho!! 1 usuário não faz verão, mas 100.000 fazem, é só começar. Faça pressão e propaganda para que outros façam pressão também. Não acredita? A SUN começou a liberar o fonte do Solaris por causa da pressão de mercado. (http://www.sun.com/solaris/source/ )

Ainda não é software livre, inclusive tem uma taxa para acessar o código, mas é um passo nessa direção. Antes isso era impensável! Você acha que o movimento Software Livre não teve nada a ver com isso? =) Ela liberou o Star Office, suíte de aplicativos Office como software livre!

Divulgue a idéia, isso já é uma GRANDE contribuição. O principal é acreditar que as coisas podem mudar.! Discuta a idéia com seus amigos. Mas *não* seja chato, xiita, nem fanático. Fanatismo mata novas idéias. Dê uma força ou uma dica a um amigo. Mas não seja doutrinário, apenas divulgue algo que você acredita ser relevante, sem ser chato. Isso vale para política, ecologia ou outros assuntos =)

Fontes consultadas e links

Eu usei várias fontes nessa página.

Tirei referências especialmente de Richard Stallman e seu site da Free Software Foundation, e com Rubens Queiróz em seu artigo “Porque usar Software Livre”. Eduardo Maçan também me esclareceu vários conceitos em seus artigos!

Filosofia do software livre, segundo a FSF

História do projeto GNU

Artigo do qual tirei muitas idéias e argumentos, Por que usar software livre? , de Rubens Queiroz

Texto muito bom, bem humorado e curto, de Eduardo Maçan sobre Software Livre

Software Livre no Brasil

A maioria desses links tem mais links, muito legais também. Se você puder ler só um texto ou dois, leia os Do Queiroz e do Maçan! Valem o seu tempo!

O suporte de segundo nível lida com pessoas que também são da área de suporte, então é toda uma outra história, embora também seja estressante.

Em primeiro lugar, o seu usuário final quase nunca está calmo. Isso é obvio: ele tem um problema, as coisas não estão funcionando como ele supõe que deveriam estar: é por isso que ele está chamando suporte. (Às vezes há o caso de usuário carentes, que só querem alguém para conversar, mas é preciso saber se livrar destes).

Então você tem que estar calmo e preparado para ouvir alguém que está nervoso.

Nunca assuma uma atitude de que o usuário na verdade não tem um problema. Sim, ele tem, mesmo que o problema seja na verdade um procedimento errado ou má interpretação do sistema por parte dele. O usuário não saber usar o sistema e usar pensando que sabe é um problema real, e é o trabalho do suporte resolvê-lo. Isso é muito importante, porque eu já vi muito a atitude de “ah, um usuário fez besteira e me ligou enchendo o saco, e era tudo culpa dele”. Os usuários fazem besteiras, e é precisamente por isso que eles precisam de suporte. Ele não ligou te enchendo o saco, é seu trabalho ajudá-lo! Se os usuário fossem capazes de ler a documentação técnica e entender sozinhos o que eles estavam fazendo de errado, eles não precisariam de suporte! Problemas causados por bugs no sistema são minoria. Não é para lidar com estes problemas apenas que um time de suporte existe!

Outra parte importante é que os usuário freqüentemente não saberão descrever o problema adequadamente, simplesmente porque como usuário eles não sabem como o sistema funciona. É o seu trabalho saber, não o deles. Você tem que extrair do usuário o que ele está fazendo, aonde, qual o resultado que ele está obtendo e qual o resultado que ele esperava obter. Quase nunca um usuário irá ligar com estas informações claras e organizadas. As vezes ele irá dizer que “não fez nada e simplesmente parou de funcionar”. As vezes ele irá fazer uma suposição incorreta sobre o funcionamento do sistema e irá ligar reportando o problema onde ele supõe que está, não aonde está realmente. Ajude-o a lhe dar a informações que importam: o que ele está fazendo, aonde, qual o resultado que ele está obtendo e qual o resultado que ele esperava obter.

Jamais suponha que, por que o problema é intermitente, ou o usuário não consegue reproduzi-lo, que o problema não existe, é pura imaginação do usuário. Lembre-se: jamais assuma que o usuário não tem um problema. Ele sempre tem um problema, senão porque ele estaria te chamando?

Uma mente analítica é essencial para um analista de suporte. Formular hipóteses, isolá-las e testá-las são ferramentas fundamentais.

O trabalho de um analista de suporte de primeiro nível não e resolver os problemas do sistema. O trabalho dele é resolver os problemas do usuário com o sistema. é muito diferente, e essa diferença é muito importante.

Um bom analista de suporte também é um bom psicólogo, porque não basta saber como sistemas funcionam, mas principalmente como pessoas funcionam.

Existem muitas alternativas de backups destinadas a todos os tamanhos de rede e bolso, e o Amanda é sempre citado como uma alternativa livre e gratuita.

Porém o Amanda é comumente utilizado para realizar backups em fita, o que nem é sempre econômico, já que hoje em dia HDs são muito baratos e certamente mais práticos para uma pequena empresa utilizar.

É perfeitamente possível ter um amanda realizando backups no disco rígido, e como realizar isso é a que nos propomos neste artigo.

Do que você irá precisar

Escolha uma máquina para ser o servidor de arquivos. Este tutorial considera que se utilizará como sistema operacional desse servidor o Debian GNU/Linux atualizado, porém pode perfeitamente servir de base para que a mesma tarefa seja realizada em outras distribuições.

É muito interessante que esta máquina tenha bastante espaço em disco e se possível um HD dedicado somente ao backup.

Essa máquina deve estar conectada à rede das outras máquinas que terão seus dados salvos.

Estratégia de backups e definições

Iremos criar no HD 14 fitas “virtuais”, que serão diretórios no HD. O Amanda considera que será rodado uma vez por dia.

O amanda pode realizar backups completos (full) e incrementais. Você pode decidir a freqüência e a retenção (por quanto tempo ficarão armazenados) desses backups.

Nesse artigo escolhemos realizar um backup completo uma vez por semana e incrementais seis vezes por semana, criando um ciclo semanal.

A retenção é feita por duas semanas, com uma fita virtual por backup.

Esse parâmetros podem ser alterados no /etc/amanda/DailySet1/amanda.conf, na seção:

  dumpcycle 7 days
  tapecycle 14

Se quiser realizar dois backups completos em uma semana, por exemplo, altere para:

  dumpcycle 3 days
  tapecycle 14

As fitas virtuais ficarão em /backups e o usuário com que o amanda irá rodar é o padrão do Debian, “backup”. Este usuário já existe na Debian, porém pode variar em outras distribuições.

Resta agora decidir o tamanho que cada fita virtual terá. Nesse exemplo escolhemos 10 GB por fita, o que dá um espaço alocado de 140 GB para backups.

Instalação e Configuração: Servidor

No servidor instale o amanda. É muito importante que seu Debian esteja com a versão atualizada do sistema, pois a versão do amanda que está na Stable não suporta backup para disco rígido. A versão 2.4.4p3-2 foi utilizada neste tutorial:

  apt-get install amanda-server

Após feita a instalação, vamos configurá-lo:

  cd /etc/amanda/DailySet1/

Salve uma cópia do arquivo original, se quiser:

  cp /etc/amanda/DailySet1/amanda.conf{,-ori}

Agora edite o arquivo /etc/amanda/DailySet1/amanda.conf, apague seu conteúdo e coloque o seguinte, lembrando que o que vem depois do sinal # é considerado comentário e será ignorado pelo Amanda:

  org "DailySet1"                # Nome descritivo para as mensagens
  mailto "sysadmin@dominio.com"  # Email de quem irá receber os logs
  dumpuser "backup"              # Usuário dono dos backups
  inparallel 1                   # Procesos em paralelo
  netusage  10                   # Uso máximo de banda em Kbps

  dumpcycle 7 days               # Número de dias de um ciclo completo
  tapecycle 14              # Número de "fitas"

  runtapes     1                 # Quantas fitas usar por ciclo
  tpchanger "chg-multi"          # Script controlador de fitas
  changerfile "/etc/amanda/DailySet1/changer.conf" # Configuração das fitas

  tapetype HARD-DISK              # Tipo de armazenamento
  labelstr "^HISS[0-9][0-9]*$"    # Expressão regular das etiquetas das fitas

  infofile "/var/lib/amanda/DailySet1/curinfo"    # Diretório de datos
  logfile  "/var/log/amanda/DailySet1/log"        # Diretório de log

  indexdir "/var/lib/amanda/DailySet1/index"   # Diretório de índice

  amrecover_changer "chg-multi"  # Seleciona as fitas automaitcamente no restore

  # definição de arquivamento com dump
  define dumptype hard-disk-dump {
    comment "Backup no HD - usando dump"
    holdingdisk no
    index yes
    options compress-fast, index, exclude-list "/etc/amanda/exclude.gtar"
    priority high
  }

  # Definição do armazenamento com tar
  define tapetype HARD-DISK {
    comment "HD"
    length 10000 mbytes  # 10 GB de espaço
  }

  # Definição de armazenamento com 'tar'
  define dumptype hard-disk-tar {
    program "GNUTAR"
    hard-disk-dump
    comment "Backup para disco - usando tar"
  }

Edite o arquivo /etc/amanda/DailySet1/changer.conf para definir as características das “fitas” e coloque o seguinte:

  multieject 0
  gravity 0
  needeject 0
  ejectdelay 0

  statefile /var/lib/amanda/DailySet1/changer-status

  firstslot 1
  lastslot 14

  slot 1 file:/backups/tape01
  slot 2 file:/backups/tape02
  slot 3 file:/backups/tape03
  slot 4 file:/backups/tape04
  slot 5 file:/backups/tape05
  slot 6 file:/backups/tape06
  slot 7 file:/backups/tape07
  slot 8 file:/backups/tape08
  slot 9 file:/backups/tape09
  slot 10 file:/backups/tape10
  slot 11 file:/backups/tape11
  slot 12 file:/backups/tape12
  slot 13 file:/backups/tape13
  slot 14 file:/backups/tape14

Agora a vez é do /etc/amanda/DailySet1/disklist, que irá definir quais máquinas terão quais diretórios armazenados:

  # O nome da máquina deve ser o que está no DNS (ou no /etc/hosts)
  cliente.dominio.com /home hard-disk-tar
  cliente.dominio.com /var hard-disk-tar
  cliente.dominio.com /etc hard-disk-tar

  cliente2.dominio.com /home         hard-disk-tar
  cliente2.dominio.com /usr/local hard-disk-tar

Os nomes das máquinas clientes devem estar definidas no seu /etc/hosts ou no seu DNS.

A seguir iremos criar os diretórios das fitas virtuais:

  mkdir /backups

Então, os sub-diretórios:

  mkdir -p /backups/tape01/data
  mkdir -p /backups/tape02/data
  [...]
  mkdir -p /backups/tape14/data

Acerte a permissão de modo que o usuário de backup possa escrever nesses diretórios:

  chown -R backup:backup /backups

Vamos editar o agendador de tarefas (cron) para realizar os backups às 5:00 da manhã. Edite o /etc/crontab e acrescente a seguinte linha:

  00 5    * * *   backup      /usr/sbin/amdump DailySet1

Edite o /etc/amandahosts para permitir o acesso do usuário que irá realizar a restauração de arquivos, no caso o root. Acrescente essas linhas:

  #servidor usuário
  servidor  root

É necessário iniciar os serviços de rede do Amanda, para que o backup e os restores possam ser feitos. Isso é definido através do super-servidor inet ou seu substituto, o xinet. Iremos mostrar como configurar os dois. Primeiro o inetd. Descomente ou insira as seguintes linhas no seu /etc/inetd.conf :

  amanda dgram udp wait backup /usr/sbin/tcpd /usr/lib/amanda/amandad
  amandaidx stream tcp nowait backup /usr/sbin/tcpd /usr/lib/amanda/amindexd
  amidxtape stream tcp nowait backup /usr/sbin/tcpd /usr/lib/amanda/amidxtaped

Reincie o inetd:

  /etc/init.d/inetd restart

Caso possua xinetd, inclua no arquivo ‘/etc/xinetd.conf’:

  service amanda
   {
        socket_type     = dgram
        protocol        = udp
        wait            = yes
        user            = backup
        server          = /usr/lib/amanda/amandad
   }

  service amandaidx
   {
        socket_type     = stream
        protocol        = tcp
        wait            = no
        user            = backup
        server          = /usr/lib/amanda/amindexd
   }

  service amidxtape
   {
        socket_type     = stream
        protocol        = tcp
        wait            = no
        user            = backup
        server          = /usr/lib/amanda/amidxtaped
   }

Os próximos comandos serão dados como o usuário backup:

  su - backup

Crie o arquivo de lista de tapes, que será posteriormente preenchido pelo Amanda:

  touch /etc/amanda/DailySet1/tapelist

Agora vamos etiquetar as fitas virtuais, para uso do Amanda:

  /usr/sbin/amlabel DailySet1 HISS01 slot 1
  /usr/sbin/amlabel DailySet1 HISS02 slot 2
  /usr/sbin/amlabel DailySet1 HISS03 slot 3
  [...]
  /usr/sbin/amlabel DailySet1 HISS14 slot 14

Instalação e Configuração: Clientes

A configuração no servidor está completa. Agora iremos para um cliente Linux, que pode ser o desktop de alguém ou seu Servidor Web, por exemplo. Caso esse cliente também esteja rodando Debian:

  apt-get install amanda-client

Ou instale o cliente do amanda da sua distribuição.

Agora, edite o ‘/etc/amandahosts’:

  # nome da maquina usuario
  servidor.dominio.com        backup

Note que o nome do servidor deve estar definido no /etc/hosts do cliente ou no seu DNS interno. O mais fácil é definir no /etc/hosts, nesse formato:

  192.168.1.110     servidor.dominio.com      servidor

Estamos quase lá. É preciso que o seu cliente esteja escutando na rede para que, quando o servidor se conectar, ele consiga transferir os dados. Como explicado anteriormente, isso pode ser feito via inet ou xinet. Vamos ver os dois casos.

No Debian, quando se instala o amanda-server ele insere a seguinte linha no seu /etc/inetd.conf :

  amanda dgram udp wait backup /usr/sbin/tcpd /usr/lib/amanda/amandad

Se não estiver lá, insira manualmente a linha. Em qualquer dos casos reinicie o inetd.conf:

  /etc/init.d/inetd.conf restart

Caso você utilize o xinetd porém, basta editar o /etc/xinetd.conf e colocar assim:

  service amanda
   {
        socket_type     = dgram
        protocol        = udp
        wait            = yes
        user            = backup
        server          = /usr/lib/amanda/amandad
   }

Reinicie o xinetd:

  /etc/init.d/xinetd restart

E a configuração está pronta!

Restaure os backups!

O seu backup foi realizado com sucesso às 5:00 da manhã e tudo está certo. É hora de aprender a restaurar os backups enquanto tudo está tranquilo e ninguém esta desesperado gritando com você pelos seus dados preciosos.

Existe algumas maneiras de fazer isso. Uma é utilizando o amrecover, como root. Essa opção é a que iremos utilizar, por ser a mais poderosa.

Na máquina servidora, como root, crie um diretório de restore:

  mkdir /restore
  cd /restore

Agora, chame o programa de recuperação:

  amrecover

Dê o comando que determina a data que você quer restaurar, no formato AAAA-MM-DD, onde AAAA é o ano com quatro dígitos, MM é o mês com dois dígitos e DD é o dia com dois dígitos:

  amrecover> setdate 2004-11-06
  200 Working date set to 2004-11-06.

Aqui você determina de qual cliente você quer restaurar o backup:

  amrecover> sethost cliente
  200 Dump host set to cliente.

A seguir você determina de qual “disco” você irá restaurar o backup. Se você especificou para ser feito o backup do diretório /home do cliente ponha /home. Mesmo que você vá restaurar somente um diretório ou somente um arquivo. Veja abaixo como extrair somente um arquivo do diretório /home/daniduc :

  amrecover> setdisk /home
  200 Disk set to /home.

Aqui você navega até o diretório:

  amrecover> cd daniduc
  /home/daniduc

O próximo passo é adicionar o arquivo a ser restaurado. Lembre-se que você pode usar coringas, como o * para adicionar todos os arquivos, ou pode adicionar um diretório:

  amrecover> add .bash_history
  Added /daniduc/.bash_history

Continue adicionando diretórios e arquivos, conforme o necessário.

Aqui você pede para o Amanda selecionar a fita virtual automaticamente:

  amrecover> settape chg-multi
  Using tape "chg-multi" from server localhost.

E finalmente, só resta extrair os arquivos:

  amrecover> extract
  Extracting files using tape drive chg-multi on host localhost.
  The following tapes are needed: HISS06

  Restoring files into directory /restore
  Continue [?/Y/n]? y

  Extracting files using tape drive chg-multi on host localhost.
  Load tape HISS06 now
  Continue [?/Y/n/s/t]? y
  ./daniduc/.bash_history
  amrecover> exit

Pronto, foi feita a restauração do arquivo dentro do diretório /restore! Sua empresa já pode dormir tranqüila, sabendo que possui backups eficientes a um custo extremamente acessível.

Esta documentação foi escrita a partir de uma implementação de um servidor ftp com o Proftp. O Proftp foi escolhido pela flexibilidade e diversidade de configuração que ele permite. O Proftp foi instalado numa máquina RISC IBM com o sistema operacional AIX.

Os problemas que ocorreram durante a implementação desta solução estão documentados na sessão “Resolução de Problemas”, que pode ser útil caso eles voltem a ocorrer.

Também estão documentados um exemplo do arquivo de configuração (proftpd.conf) e a man page do proftp.

Há no decorrer da documentação links para páginas contendo informações mais completas.

Informações sobre o Proftp podem ser encontradas em: http://www.proftpd.org

Instalando o servidor proftp

Instalando o proftp

Instalar o binário do proftp para AIX:

• Fazer o download em: http://freeware.bull.net/download/aix43/proftpd-1.2.1.0.exe
• Criar um diretório e copiar o arquivo proftpd-1.2.1.0.exe para este diretório.
• Executar o arquivo::

                  # ./proftpd-1.2.1.0.exe
  

Ele vai gerar os seguintes arquivos::

                [root@máquina_i] proftp_binario> ls -la
                total 3416
                drwxr-xr-x 2 root system 512 Jan 11 13:51 .
                drwxr-xr-x 7 root system 512 Jan 11 13:28 ..
                -rw-r--r-- 1 root system 502 Dec 27 16:47 .toc
                -rw-r--r-- 1 root system 1280000 Aug 02 04:51 proftpd-1.2.1.0.bff
                -rw-r--r-- 1 root system 2481 Aug 02 04:52 proftpd-1.2.1.0.bff.asc
                -rwxr-x--x 1 root system 442862 Dec 27 16:47 proftpd-1.2.1.0.exe
                -rw-r--r-- 1 root system 3720 Dec 27 16:51 status_instalacao.txt
                [root@máquina_i] proftp_binario>

• Instalar através do smitty:

                  # smitty install_latest
  

Configurando o proftp

A configuração do proftpd é feita através de parâmetros no arquivo proftpd.conf. Ver no final desta dica um modelo do arquivo de configuração.

Localização: /etc/proftpd/proftpd.conf

Alguns parâmetros importantes

O proftp permite uma série de configurações. Diversos parâmetros podem ser configurados no arquivo proftpd.conf.

Todas as flags de configuração estão documentadas em:

http://www.proftpd.org/docs/directives/linked/by-name.html

Exemplos:

Segue abaixo exemplos de alguns parâmetros do arquivo proftpd.conf:

Para que o HOME do usuário seja o diretório raíz:

Pode se desejar que o usuário ao se logar por ftp, não tenha acesso a nenhum diretório da máquina que não seja o seu diretório HOME.. Para isso acrescentamos a seguinte linha no arquivo de configuração::

                DefaultRoot

Doc: http://www.proftpd.org/docs/directives/linked/config_ref_DefaultRoot.html

Para o proftp autenticar no NIS:

Se no seu ambiente a autenticação de usuário for feita através do NIS, é preciso colocar a seguinte linha de configuração, para que o Proftp autentique os usuários::

                PersistentPasswd off

Doc: http://www.proftpd.org/docs/directives/linked/config_ref_PersistentPasswd.html

Para o proftp aceitar conexões apenas dos usuários pertencentes a um determinado grupo::

                <Limit LOGIN>
                DenyAll
                AllowGroup          Nome do Grupo
                </Limit>

Doc: http://www.proftpd.org/docs/directives/linked/config_ref_DenyAll.html

http://www.proftpd.org/docs/directives/linked/config_ref_All

Para restringir e liberar acessos a diretórios

Negando acesso a todos os diretórios a partir da raiz (/):

                <Directory/*>
                        <Limit READ WRITE DIRS>
                        DenyAll
                        </Limit>
                </Directory>

Liberando acesso ao diretório /tmp somente aos grupos grupo1, grupo2, grupo3:

                <Directory /tmp>
                        <Limit READ WRITE DIRS>
                                AllowGroup       grupo1
                                AllowGroup       grupo2
                                AllowGroup       grupo3
                                </Limit>
                </Directory>

Doc: http://www.proftpd.org/docs/configuration.html#Directory

Gerando Logs

Para segurança e maior controle da ação dos usuários que se utilizam do serviço de ftp, é desejável gerar logs. O proftp pode gerar diversos tipos de log. É possível determinarmos quais ações queremos logar e os tipos de log que o proftp irá gerar também é definido no arquivo /etc/proftpd/proftpd.conf.

Alguns tipos de logs possíveis de configurar: (/etc/proftpd/proftpd.conf):

                SystemLog /usr/local/var/proftpd/proftpsys.log
                TransferLog /usr/local/var/proftpd/proftptransf.log
                ExtendedLog /usr/local/var/proftpd/proftp.log

Doc:http://www.proftpd.org/docs/directives/linked/config_ref_SystemLog.html http://www.proftpd.org/docs/directives/linked/config_ref_TransferLog.html http://www.proftpd.org/docs/directives/linked/config_ref_ExtendedLog.html

A seguir estão listados exemplos dos logs gerados, de um login feito pelo usuário teste, que se logou as 12:49 e fechou a sessão de ftp as 12:50.

SystemLog

O SystemLog gera logs de login e logout do usuário.

/usr/local/var/proftpd/proftpsys.log:

 Jan 14 12:49:46 máquina_i proftpd[164830] máquina_i (10.1.1.56[10.1.1.56]): USER teste: Login successful.Jan 14 12:50:48 máquina_i proftpd[164830] máquina_i (10.1.1.56[10.1.1.56]): FTP session closed.

TransferLog

O TransferLog gera os logs apenas das transferências de arquivos realizadas pelo usuário.

/usr/local/var/proftpd/proftptransf.log:

       Mon Jan 14 12:50:42 2002 0 10.1.1.56 1270 /home/unix/teste/proftpd.conf b _ o r teste ftp 0 * c

ExtendedLog

O ExtendedLog, sem especificação, loga todas as ações do usuário. É possível filtrar e logar apenas as ações desejadas, especificando a classe de comando (ver detalhes na documentação). A interpretação desse Log também está na documentação citada acima.

/usr/local/var/proftpd/proftp.log:

                10.1.1.56 UNKNOWN root [14/Jan/2002:12:49:43 -0300] "USER teste" 331 -
                10.1.1.56 UNKNOWN teste [14/Jan/2002:12:49:46 -0300] "PASS (hidden)" 230
                10.1.1.56 UNKNOWN teste [14/Jan/2002:12:49:46 -0300] "SYST " 215 -
                10.1.1.56 UNKNOWN teste [14/Jan/2002:12:49:52 -0300] "PORT 10,1,1,56,6,32" 200 -
                10.1.1.56 UNKNOWN teste [14/Jan/2002:12:49:52 -0300] "LIST " 226 928
                10.1.1.56 UNKNOWN teste [14/Jan/2002:12:49:54 -0300] "PWD " 257 -
                10.1.1.56 UNKNOWN teste [14/Jan/2002:12:50:11 -0300] "CWD diversos" 250
                10.1.1.56 UNKNOWN teste [14/Jan/2002:12:50:13 -0300] "PORT 10,1,1,56,6,33" 200 -
                10.1.1.56 UNKNOWN teste [14/Jan/2002:12:50:13 -0300] "LIST " 226 815
                10.1.1.56 UNKNOWN teste [14/Jan/2002:12:50:16 -0300] "CWD .." 250
                10.1.1.56 UNKNOWN teste [14/Jan/2002:12:50:17 -0300] "PORT 10,1,1,56,6,34" 200 -
                10.1.1.56 UNKNOWN teste [14/Jan/2002:12:50:17 -0300] "LIST " 226 928
                10.1.1.56 UNKNOWN teste [14/Jan/2002:12:50:23 -0300] "CWD santos" 250
                10.1.1.56 UNKNOWN teste [14/Jan/2002:12:50:24 -0300] "PORT 10,1,1,56,6,35" 200 -
                10.1.1.56 UNKNOWN teste [14/Jan/2002:12:50:24 -0300] "LIST " 226 133
                10.1.1.56 UNKNOWN teste [14/Jan/2002:12:50:42 -0300] "TYPE I" 200 -
                10.1.1.56 UNKNOWN teste [14/Jan/2002:12:50:42 -0300] "PORT 10,1,1,56,6,36" 200 -
                10.1.1.56 UNKNOWN teste [14/Jan/2002:12:50:42 -0300] "RETR proftpd.conf" 226 1270
                10.1.1.56 UNKNOWN teste [14/Jan/2002:12:50:45 -0300] "TYPE A" 200 -
                10.1.1.56 UNKNOWN teste [14/Jan/2002:12:50:45 -0300] "PORT 10,1,1,56,6,37" 200 -
                10.1.1.56 UNKNOWN teste [14/Jan/2002:12:50:45 -0300] "LIST " 226 133
                LIST (comando ls)
                CWD (comando cd)
                RETR (comando get)

Executando o proftp

Linha de comando

Para executar o proftpd através de linha de comando é preciso que o parâmentro ServerType esteja configurado como standalone no proftpd.conf::

                ServerType       standalone

Estando como standalone basta na linha de comando::

                # usr/local/bin/proftpd -p enable

OBS:

Para a autenticação no NIS, é preciso iniciar o proftpd com a opção -p enable para que a configuração PersistentPasswd off seja interpretada. Para mais detalhes veja Man page em anexo.

inetd.conf

Antes de colocar o proftpd para ser executado pelo inetd é preciso alterar o parâmetro ServerType no proftpd.conf de standalone para inetd.

No /etc/proftpd/proftpd.conf:

Antes::: ServerType standalone Depois::: ServerType inetd

No /etc/inetd.conf:

Substituir a linha::

     ftp stream tcp6 nowait root /usr/sbin/ftpd ftpd

Pela linha de inicialização do proftp::

     ftp stream tcp nowait root /usr/local/bin/proftpd proftpd -p enable

Localização Principais arquivos

• binário:

                  /usr/local/bin/proftpd
  

• arquivo de configuração:

                  /etc/proftpd/proftd.conf
  

• arquivos de log:

                  /usr/local/var/proftpd/
                            proftp.log
                            proftpsys.log
                            proftptransf.log
  

Resolução de problemas

**Problemas na autenticação do usuário**

Apresenta o seguinte erro no log::

                Jan 11 15:32:00 máquina_i proftpd[27532]: Fatal: User: Unknown user 'teste'.
                Jan 11 15:32:06 máquina_i proftpd[187240] máquina_i (10.1.5.53[10.1.5.53]): FTP session opened.
                Jan 11 15:32:12 máquina_i proftpd[187240] máquina_i (10.1.5.53[10.1.5.53]): USER teste (Login failed): Invalid shell.
                Jan 11 15:37:06 máquina_i proftpd[187240] máquina_i (10.1.5.53[10.1.5.53]): FTP login timed out, disconnected.

Notar que o log aponta para Invalid shell do usuário teste.

Solução:

verificar no arquivo /etc/shells se a shell do usuário está cadastrada.

No AIX o /bin é um link simbólico para /usr/bin, ainda assim, é preciso cadastrar no shells, /usr/bin/ksh.

**Erro de serviço indisponível**

Verificar se o parâmetro ServerType está configurado corretamente:

standalone -> iniciar via linha de comando inetd -> iniciar via inetd.conf

**Erro na execução de comandos**:

                [carla@kenobi procedimentos_a_documentar]$ ftp máquina
                Connected to máquina.lalala.br.
                220 ProFTPD 1.2.1 Server (ProFTPD TEST Installation) [máquina_i]
                Name (máquina:teste): teste 331 Password required for teste.
                Password:
                230 User teste logged in.
                Remote system type is UNIX.
                Using binary mode to transfer files.
                ftp> ls
                500 Illegal PORT command.
                ftp: bind: Address already in use
                ftp> pwd
                257 "/" is current directory.
                ftp> ls
                500 Illegal PORT command.
                ftp> ls -l
                500 Illegal PORT command.
                ftp> get smit.log
                local: smit.log remote: smit.log
                500 Illegal PORT command.
                ftp> bye
                221 Goodbye.

Esse erro estava sendo ocasionado por ter colocado tcp6 ao invés de tcp no inetd.conf.

O problema foi resolvido substituindo tcp6 por tcp.

Pesquisando o erro na internet foi encontrada a seguinte URL, um email da lista de discussão do proftpd.org, que abordava esse erro:

http://www.proftpd.org/proftpd-devel-archive/00-10/msg00174.html

Arquivo proftpd.conf

Este é um exemplo de um arquivo de configuração do proftp.:

                #This ProFTPD configuration is intended for unprivileged TESTING ONLY.
                #See Step 4 in INSTALL.

                ServerName "ProFTPD"
                ServerType inetd
                DefaultServer on

                #Caso se desejasse fazer com que cada usuario ficasse restrito
                #ao seu $HOME no uso do ftp
                #DefaultRoot ~

                SystemLog /usr/local/var/proftpd/proftpsys.log
                TransferLog /usr/local/var/proftpd/proftptransf.log
                ExtendedLog /usr/local/var/proftpd/proftp.log

                # Use a non-privileged port, rather than the standard ftp port (21).
                # The ftpd-data port will be one less.
                Port 21

                User                   root
                Group                 system

                #Disable some checks.
                #Para que o proftp autentique no NIS

                PersistentPasswd                 off

                # Umask 022 is a good standard umask to prevent new dirs and files
                # from being group and world writable.
                Umask                               022

                # To prevent DoS attacks, set the maximum number of child processes to 5.
                MaxInstances                     20

                # Normally, we want files to be overwriteable.

                <Directory /*>
                      AllowOverwrite        on
                </Directory>

                # Restricoes de acesso a diretorios

                # Negado acesso a todos os diretorios a partir da raiz (/)

                <Directory /*>
                <Limit READ WRITE DIRS>
                            DenyAll
                      </Limit>
                </Directory>

                # Liberado acesso de alguns diretorios para alguns grupos, de acordo com
                # a necessidade de cada um

                <Directory ~>
                      <Limit READ WRITE DIRS>
            AllowGroup dba
            AllowGroup unix
            AllowGroup user_ftp
      </Limit>
                </Directory>

                <Directory /tmp>
                      <Limit READ WRITE DIRS>
                            AllowGroup dba
                            AllowGroup unix
                            AllowGroup operacao
                      </Limit>
                </Directory>

                <Directory /extdba>
                      <Limit READ WRITE DIRS>
                            AllowGroup dba
                            AllowGroup unix
                       </Limit>
                </Directory>

                <Directory /dbms>
                      <Limit READ WRITE DIRS>
                            AllowGroup dba
                            AllowGroup unix
                      </Limit>
                </Directory>

                <Directory /trabalho>
                      <Limit READ WRITE DIRS>
                            AllowGroup unix
                             AllowGroup dba
                            AllowGroup operacao
                       </Limit>
                </Directory>

                # Limitacao de login ftp. Liberado apenas para alguns grupos do ambiente.

                <Limit LOGIN>
                            DenyAll
                AllowGroup              user_ftp
                            AllowGroup              operacao
                            AllowGroup              unix
                            AllowGroup              dba
                </Limit>

Man Page – proftp

(/usr/local/man/man8/proftpd.8):

                proftpd 8 "July 2000"

                Process with
                groff -man -Tascii proftpd.1

                NAME
                proftpd \- Professional configurable, secure file transfer protocol server
                SYNOPSIS

                proftpd

                -hlntv

                -d " debuglevel"

                -c " config\-file"

                -p " 0|1"

                DESCRIPTION

                proftpd
                is the Professional File Transfer Protocol (FTP) server daemon. The server
                may be invoked by the Internet "super-server" inetd(8) each time a
                connection to the FTP service is made, or alternatively it can be run as a
                stand-alone daemon.

                When proftpd is run in standalone mode and it receives a SIGHUP then it will reread its config file. When run in standalone mode without the -n option, the main proftpd daemon writes its process ID to /var/run/proftpd.pid to make it easy to know which process to SIGHUP.

                OPTIONS

                -h,--help
                Display a short usage description, including all available options.

                -n,--nodaemon
                Runs the proftpd process in standalone mode (must be configured as such in the configuration file), but does not background the process or disassociate it from the controlling tty. Additionally, all output (log or debug messages) are sent to stdout, rather than the syslog mechanism. Most often used with the \fB-d option\fP for debugging.

                -v,--version
                Displays the version number of ProFTPD to stdout.

                -d,--debug " debuglevel"
                Sets proftpd's internal debug level (normally 0). The debugleve should be an integer value from 0 to 5, with higher numbers producing more debug output. Normally, debug messages are sent to syslog using the DEBUG facility, however if the -n option is used, all such output is sent to stdout.

                -c,--config " config\-file"
                Specifies an alternate \fIconfig\-file\fP to be parsed at startup, rather than the default (typically found in \fB/etc/proftpd.conf\fP).

                -t,--configtest
                Read the configuration file, report any syntax errors, and exit. -p,--persistent " 0|1" Disables (0) or enables (1) the default persistent password support, which is determined at configure time for each platform. This option only affects the default support, it can still be overridden at run-time with the PersistentPasswd directive.

                -l,--list
                Lists all modules compiled into proftpd.

                /usr/sbin/proftpd

                /usr/bin/ftpwho

                /usr/bin/ftpcount

                /usr/sbin/ftpshut

                /var/log/xferlog

                /var/run/proftpd-[pid]

                /var/run/proftpd.pid

                /var/run/proftpd-inetd

                AUTHORS

                ProFTPD was originally written by Floody. It is currently written and maintained by MacGyver (aka Habeeb J. Dihu) <macgyver@tos.net> http://www.macgyver.org.

                SEE ALSO
                inetd(8), ftp(1), ftpwho(1), ftpcount(1), ftpshut(8)

                Full documentation on ProFTPD, including configuration and FAQs is available at

http://www.proftpd.net.

                Report bugs at http://bugs.proftpd.net
                For help/support, try the ProFTPD mailing list at proftpd@proftpd.net (see http://www.proftpd.net/lists.html for more information).

1 – Processo de auditoria

O processo de auditoria consiste num sistema que registra em logs binários as ações realizadas por todos os usuários do sistema operacional, conforme configuração definida.

Antes de iniciar a configuração da auditoria deve-se definir o local onde os logs serão armazenados e criar um filesystem específico para isso. É importante tomar o cuidado de configurar as permissões de acesso a este diretório de modo que apenas os administradores do sistema possam acessá-lo.

Após criado o filesystem, o próximo passo é configurar os arquivos que se encontram no diretório /etc/security/audit. Para configurar a auditoria precisa-se definir o que será auditado, quais usuários serão auditados e de que forma os logs serão armazenados.

2 – O que pode ser monitorado?

A seguir temos a descrição de alguns itens que podem ser utilizados para monitoria:

USER_SU	Utilização do comando su

PASSWORD_Change - Utilização do comando passwd

FILE_Rename     - Alteração de nome de arquivos

FS_Rmdir        - Remoção de diretório

AUD_Bin_Def     - Audit bin configuration

AUD_Lost_Recs   - Notificação caso haja registros perdidos

FILE_Write      - Registra a escrita em arquivos (pode-se especificar quais arquivos sofrerão
                  esta monitoria configurando o arquivo objects, conforme descrito no item 4
                  deste documento).
.
FILE_Owner      - Alteração de permissão de arquivos: OWNER

FILE_Mode       - Mudança de permissão (chmod)

FILE_Acl        - Alteração de permissão de arquivos: utilizando ACL

FILE_Privilege  - Mudança de características de owner (chown)

AT_JobRemove    - Remoção de um Job da Crontab ou At

CRON_JobRemove  - Lista qual usuário removeu um job da cron e quando ele removeu

CRON_JobAdd     - Lista qual usuário adicionou um job da cron e quando ele removeu

LVM_DeletePV    - Remoção de PV (Physical Volume)

LVM_DeleteVGSA  - Remoção da Volume Group Status Area

LVM_DeleteVG    - Remoção de VG (Volume Group)

LVM_DeleteLV    - Remoção de LV (Logical Volume)

LVM_VaryoffVG   - Colocação de VG em status offline

3 – Configurando e habilitando a AUDITORIA:

A auditoria é configurada através da edição de arquivos de configuração que se encontram no diretório /etc/security/audit/.

3.1 – Arquivos de configuração no diretório /etc/security/audit/

No diretório /etc/security/audit encontramos os seguintes arquivos:

# ls -l
total 136
-rw-r-----   1 root     audit         37 Sep 16 2002  bincmds
-rw-rw----   1 root     audit       1092 Nov 16 12:24 config
-rw-rw----   1 root     audit      14208 Oct 09 15:37 events
-rw-r-----   1 root     audit        340 Sep 16 2002  objects
-rw-rw----   1 root     audit       1107 Nov 16 12:23 oconfig
-rw-r-----   1 root     audit         54 Sep 16 2002  streamcmds
#

A função destes arquivos é:

bincmds    - Arquivo onde estão os comandos para monitoração no modo binmode
config     - Arquivo de configuração da auditoria onde são especificadas as
             características do processo de audit o que será monitorado
events     - Arquivo onde estão definidos os eventos que podem ser monitorados
objects    - Arquivo onde estão definidos os objetos a serem monitorados
streamcmds - Arquivo onde estão os comandos para monitoração no modo
             streammode

Para habilitar a auditoria no AIX, normalmente configuramos os seguintes arquivos:

- config
- objects
- events

3.1.1 - Configuração do /etc/security/audit/config

Segue no quadro a seguir, um exemplo de configuração do arquivo config, o principal arquivo de configuração, onde definimos “como”, “o que” e “quem” serão auditados.

Neste arquivo definimos:

O método de geração de logs (bin ou stream)

O diretório onde os logs serão gerados: /{filesystemcriado}

Os processos que serão monitorados (descritos no próximo ítem: USER_SU, etc)

Quais usuários serão monitorados

Segue um modelo do arquivo config:

start:
        binmode = on
        streammode = off

bin:
        trail = /{filesystemcriado}/trail
        bin1 = /{filesystemcriado}/bin1
        bin2 = /{filesystemcriado}/bin2
        binsize = 10240
        cmds = /etc/security/audit/bincmds
        freespace = 65536

stream:
        cmds = /etc/security/audit/streamcmds

classes:
        personalizada = USER_SU,PASSWORD_Change,FILE_Rename,FS_Rmdir,AUD_Bin_Def,AUD_Lost_Recs,FILE_Write,\
                        FILE_Rename,FILE_Owner,FILE_Mode,FILE_Acl,FILE_Privilege,AT_JobAdd,AT_JobRemove,\
                        CRON_JobAdd,CRON_JobRemove,LVM_DeletePV,LVM_DeleteVGSA,LVM_DeleteVG,\
                        LVM_DeleteLV,LVM_VaryoffVG

users:
        usuarioA = personalizada
        usuarioB = personalizada
        usuarioC = personalizada

3.1.2 - Configuração do /etc/security/audit/objects

O arquivo objects permite que personalizemos a relação dos objetos que são monitorados. Podemos incluir os arquivos do /etc, do /home, etc, conforme desejarmos.

Abaixo podemos ver como incluir todos os arquivos abaixo do /etc para serem monitorados.

Basta executar na linha de comando:

# find /etc -type f | awk '{printf("%s:\n\tw = FILE_Write\n\n",$1)}' >> objects

3.1.3 – Configuração do /etc/security/audit/events

O arquivo events contém o que cada ação auditada faz. Podemos personalizar, por exemplo, que a ação FILE_Write registre o nome do arquivo editado adicionado file: %s , conforme mostrado a seguir.

Exemplo:

Original:

FILE_Write = printf "file descriptor = %d"

Modificado:

FILE_Write = printf "file descriptor = %d file: %s"

4 – Automatizando a inclusão de novos usuários no sistema de auditoria.

Uma vez implementado o processo de auditoria, para que os usuários criados já sejam adicionados no sistema de auditoria, deve-se configurar o arquivo: /usr/lib/security/mkuser.default:

#more mkuser.default

user:
        auditclasses = personalizada
        pgrp = staff
        groups = staff
        shell = /usr/bin/ksh
        home = /home/$USER

admin:
        pgrp = system
        groups = system
        shell = /usr/bin/ksh
        home = /home/$USER

5 - Administração do sistema de auditoria

5.1 - Ativação/Desativação do sistema de auditoria

Iniciar o processo de auditoria

# audit start

Parar o processo de auditoria:

# audit shutdown

Daemon do processo de auditoria ativo:

# ps -ef |grep audit
    root  315630       1   0 11:48:16      -  0:00 auditbin
    root 3489980 4378874   1 13:02:52  pts/1  0:00 grep audit
#

Para que a auditoria seja iniciada em caso de boot do servidor, deve-se incluir uma linha no arquivo /etc/inittab:

Exemplo:

audit:2:once:/usr/sbin/audit start > /dev/console 2>&1

5.2 - Leitura dos registros de auditoria

Para ler os registros de auditoria, utilizar o comando auditpr:

auditpr < bin1

auditpr –v < bin1

No diretório definido para os logs de auditoria:

# ls -l
total 448
-rw-------   1 root     system            0 Nov 16 11:48 auditb
-rw-rw----   1 root     system         6785 Nov 16 13:09 bin1
-rw-rw----   1 root     system            0 Nov 16 12:23 bin2
drwxr-xr-x   2 root     system          256 Oct 27 11:52 lost+found
-rw-r-----   1 root     system       221005 Nov 16 12:23 trail

6 - Resolução de problemas com AUDIT:

Problema 1:

Caso o audit apresente o seguinte erro ao tentar iniciar o audit:

# /usr/sbin/audit start

AUDITBIN: ** failed backend command /usr/sbin/auditcat -p -o /{filesystemcriado}/trail -r /{filesystemcriado}/bin1
#

Para resolver, pode-se renomear os arquivos /{filesystemcriado}/trail e /{filesystemcriado}/bin1 e reiniciar o audit.

# /usr/sbin/audit start

# ps -ef |grep audit
    root 2515120       1   0 16:06:28      -  0:00 auditbin
    root 3981322 2478182   0 16:06:35  pts/2  0:00 grep audit

# ls -lrt
total 10328
drwxr-xr-x   2 root     system          256 Apr 15 16:27 lost+found
-rw-r-----   1 root     system      5255750 Apr 29 00:25 trail.old
-rw-rw----   1 root     system        10202 Jun 01 16:02 bin1.old
-rw-------   1 root     system            0 Jun 01 16:06 auditb
-rw-r-----   1 root     system         2819 Jun 01 16:06 trail
-rw-rw----   1 root     system            0 Jun 01 16:06 bin2
-rw-rw----   1 root     system         2320 Jun 01 16:06 bin1

A solução foi encontrada neste link:

http://www.aplawrence.com/Security/mdgiac.html

Segue o trecho que descreve o erro e a solução:

Error message:
auditbin: ** failed backend command
/etc/auditcat -p -o /{filesystemcriado}/trail -r /{filesystemcriado}/bin1
This error can be corrected by removing or renaming the BIN files. It is sometimes helpful to run audit shutdown again
and then to retry audit start.

7 - Referência

Audit Command

http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.aix.security/doc/security/auditing.htm

Configurando Auditoria http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.aix.security/doc/security/setting_up_auditing.htm