Professional Documents
Culture Documents
Resumo
Este documento tem por objetivo ser uma referência ao aprendizado do usuário e um guia
de consulta, operação e configuração de sistemas Linux (e outros tipos de *ix). A última ver-
são deste guia pode ser encontrada na Página Oficial do Foca GNU/Linux (http://www.
guiafoca.org). Novas versões são lançadas com uma freqüência mensal e você pode rece-
ber avisos de novos lançamentos deste guia preenchendo um formulário na página Web.
Nota de Copyright
Sumário
1 Introdução 1
1.1 Considerações sobre o nível Avançado . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Pré-requisitos para a utilização deste guia . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 O Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3.1 Algumas Características do Linux . . . . . . . . . . . . . . . . . . . . . . . 5
2 Explicações Básicas 9
2.1 Monitorando os logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1.1 Destruindo arquivos/partições de forma segura . . . . . . . . . . . . . . . 9
2.2 Curingas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3 Hardware 13
3.1 Placa de expansão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2 Nomes de dispositivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.3 Configuração de Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.3.1 IRQ - Requisição de Interrupção . . . . . . . . . . . . . . . . . . . . . . . . 15
3.3.2 DMA - Acesso Direto a Memória . . . . . . . . . . . . . . . . . . . . . . . . 17
3.3.3 I/O - Porta de Entrada/Saída . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.4 Hardwares configuráveis por jumpers, dip-switches, jumperless e Plug-and-Play. 19
3.4.1 Jumpers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.4.2 Dip-Switches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.4.3 Jumperless (sem jumper) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.4.4 Plug-and-Play . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.5 Listando as placas e outros hardwares em um computador . . . . . . . . . . . . . 21
SUMÁRIO ii
4 Rede 41
4.1 O que é uma rede . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.2 Protocolo de Rede . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.3 Endereço IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.3.1 Classes de Rede IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.3.2 Referência rápida de máscara de redes . . . . . . . . . . . . . . . . . . . . . 43
SUMÁRIO iii
4.3.3 Para instalar uma máquina usando o Linux em uma rede existente . . . . 44
4.3.4 Endereços reservados para uso em uma rede Privada . . . . . . . . . . . . 44
4.4 Interface de rede . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.4.1 A interface loopback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.4.2 Atribuindo um endereço de rede a uma interface (ifconfig) . . . . . . . . . 46
4.5 Roteamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.5.1 Configurando uma rota no Linux . . . . . . . . . . . . . . . . . . . . . . . . 47
4.6 Resolvedor de nomes (DNS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.6.1 O que é um nome? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.6.2 Arquivos de configuração usados na resolução de nomes . . . . . . . . . . 49
4.6.3 Executando um servidor de nomes . . . . . . . . . . . . . . . . . . . . . . . 52
4.7 Serviços de Rede . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.7.1 Serviços iniciados como Daemons de rede . . . . . . . . . . . . . . . . . . 52
4.7.2 Serviços iniciados através do inetd . . . . . . . . . . . . . . . . . . . . . . . 52
4.8 Segurança da Rede e controle de Acesso . . . . . . . . . . . . . . . . . . . . . . . . 55
4.8.1 /etc/ftpusers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.8.2 /etc/securetty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.8.3 O mecanismo de controle de acessos tcpd . . . . . . . . . . . . . . . . . . . 56
4.8.4 Firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.9 Outros arquivos de configuração relacionados com a rede . . . . . . . . . . . . . . 61
4.9.1 /etc/services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.9.2 /etc/protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.10 Camadas de Rede . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.11 RFCs de referência sobre protocolos de rede . . . . . . . . . . . . . . . . . . . . . . 62
8 Personalização do Sistema 93
8.1 Variáveis de Ambientes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
8.2 Modificando o Idioma usado em seu sistema . . . . . . . . . . . . . . . . . . . . . 93
SUMÁRIO v
8.3 alias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
8.4 Arquivo /etc/profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
8.5 Arquivo .bash_profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
8.6 Arquivo .bashrc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
8.7 Arquivo .hushlogin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
8.8 Arquivo /etc/environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
8.9 Diretório /etc/skel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
9 Impressão 99
9.1 Portas de impressora . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
9.2 Imprimindo diretamente para a porta de impressora . . . . . . . . . . . . . . . . . 99
9.3 Imprimindo via spool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
9.4 Impressão em modo gráfico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
9.4.1 Ghost Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
9.5 Magic Filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
9.5.1 Instalação e configuração do Magic Filter . . . . . . . . . . . . . . . . . . . 103
9.5.2 Outros detalhes técnicos sobre o Magic Filter . . . . . . . . . . . . . . . . . 104
9.6 Impressão remota . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
9.6.1 Dando permissão para impresão remota via lpd/lprng . . . . . . . . . . . 105
9.6.2 Impressão via rlpr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
9.6.3 Impressão via printcap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
12 Apache 171
12.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
12.1.1 Versão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
12.1.2 Um resumo da História do Apache . . . . . . . . . . . . . . . . . . . . . . . 172
12.1.3 Enviando Correções/Contribuindo com o projeto . . . . . . . . . . . . . . 172
12.1.4 Características do Apache . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
12.1.5 Ficha técnica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
12.1.6 Requerimentos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
12.1.7 Arquivos de log criados pelo Apache . . . . . . . . . . . . . . . . . . . . . 174
SUMÁRIO ix
12.10.13Anonymous_LogEmail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
12.10.14CookieLog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
12.10.15Relatório gráfico de acesso ao sistema . . . . . . . . . . . . . . . . . . . . . 204
12.11Configurando o Apache como servidor proxy . . . . . . . . . . . . . . . . . . . . . 204
12.11.1 Controlando o acesso ao servidor proxy . . . . . . . . . . . . . . . . . . . . 206
12.11.2 Redirecionamento de conexões no Apache . . . . . . . . . . . . . . . . . . 207
12.12Virtual Hosts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
12.12.1 Virtual hosts baseados em IP . . . . . . . . . . . . . . . . . . . . . . . . . . 208
12.12.2 Virtual hosts baseados em nome . . . . . . . . . . . . . . . . . . . . . . . . 209
12.12.3 Segurança no uso de IP’s em Virtual Hosts . . . . . . . . . . . . . . . . . . 211
12.13Uso de criptografia SSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
12.13.1 Servidor apache com suporte a ssl . . . . . . . . . . . . . . . . . . . . . . . 212
12.13.2 Instalando o suporte a módulo SSL no Apache . . . . . . . . . . . . . . . . 212
12.13.3 Gerando um certificado digital . . . . . . . . . . . . . . . . . . . . . . . . . 213
12.13.4 Exemplo de configuração do módulo mod-ssl . . . . . . . . . . . . . . . . 213
12.13.5 Autorizando acesso somente a conexões SSL . . . . . . . . . . . . . . . . . 215
12.13.6 Iniciando o servidor Web com suporte a SSL . . . . . . . . . . . . . . . . . 215
12.14Exemplo comentado de um arquivo de configuração do Apache . . . . . . . . . . 216
12.14.1 httpd.conf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
12.14.2 srm.conf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
12.14.3 access.conf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
12.15Códigos HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
17 CVS 275
17.1 Introdução ao CVS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
17.1.1 Versão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276
17.1.2 História . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276
17.1.3 Contribuindo com o CVS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276
17.1.4 Características . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276
17.1.5 Ficha técnica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
17.1.6 Requerimentos de Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . 277
17.1.7 Arquivos de log criados pelo CVS . . . . . . . . . . . . . . . . . . . . . . . 278
17.1.8 Instalação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
17.1.9 Iniciando o servidor/reiniciando/recarregando a configuração . . . . . . 278
17.1.10 Opções de linha de comando . . . . . . . . . . . . . . . . . . . . . . . . . . 278
17.2 Servidor de CVS - configurando métodos de acesso ao repositório . . . . . . . . . 279
17.2.1 local . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
17.2.2 fork . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280
17.2.3 ext . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280
17.2.4 pserver (password server) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
17.2.5 Configurando um servidor pserver . . . . . . . . . . . . . . . . . . . . . . 282
17.2.6 gssapi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285
17.3 Criando projetos para serem usados no CVS . . . . . . . . . . . . . . . . . . . . . 285
17.3.1 Repositório . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285
17.3.2 Criando um repositório . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286
17.3.3 Logando no servidor de CVS via pserver . . . . . . . . . . . . . . . . . . . 286
17.3.4 Encerrando uma seção de CVS . . . . . . . . . . . . . . . . . . . . . . . . . 287
17.3.5 Baixando arquivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
17.3.6 Adicionando um novo projeto . . . . . . . . . . . . . . . . . . . . . . . . . 288
17.3.7 Sincronizando a cópia remota com a cópia local . . . . . . . . . . . . . . . 288
17.3.8 Enviando as mudanças para o servidor remoto . . . . . . . . . . . . . . . . 289
17.3.9 Adicionando um arquivo ao módulo CVS do servidor . . . . . . . . . . . 289
17.3.10 Adicionando um diretório ao módulo CVS do servidor . . . . . . . . . . . 289
17.3.11 Removendo um arquivo do módulo CVS remoto . . . . . . . . . . . . . . 290
SUMÁRIO xiv
18 SAMBA 299
18.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
18.1.1 Versão documentada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300
18.1.2 História . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300
18.1.3 Contribuindo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300
18.1.4 Características . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301
18.1.5 Ficha técnica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302
18.1.6 Requerimentos de Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . 302
SUMÁRIO xv
21 Apêndice 419
21.1 Sobre este guia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419
SUMÁRIO xx
Capítulo 1
Introdução
Bem vindo ao guia Foca GNU/Linux. O nome FOCA significa FOnte de Consulta e
Aprendizado. Este guia é dividido em 3 níveis de aprendizado e versão que esta lendo agora
contém:
• Avançado
Entre o conteúdo do guia, você encontrará:
• Principais tipos de ataques para descoberta de senhas e alguns métodos de como evita-
las (‘Senhas fáceis de adivinhar e escolha de boas senhas’ on page 164).
• Integrar máquinas Windows e Linux em uma mesma rede compartilhando dados entre
si e impressão (‘SAMBA’ on page 299).
• Servidor de acesso para permitir o acesso a distância a seu computador com criptografia
usando o ssh (‘Servidor ssh’ on page 251).
• Montagem de um servidor pop3 para que suas estações de rede possam acessar o email
na máquina servidor Linux usando programas como Outlook, Communicator, Mutt,
sylpheed e outros que utilizem o protocolo pop3 (‘Servidor pop3’ on page 269).
• Uso de grupos dos sistema para restrições de acesso (‘Restrições de acesso a progra-
mas/diretórios/arquivos usando grupos’ on page 384).
• Restrições de acesso via hardware: BIOS, disquete, placa com boot via rede, LILO, disco
rígido (‘Restrições no hardware do sistema’ on page 401).
• Manipulações de variáveis no bash (TMOUT, PS1, PS2, PS3, PS4, HISTORY, etc).
• Montagem de shell básico restrito (‘Restrições básicas do shell bash com bash -r/–
restricted, rbash’ on page 376).
Capítulo 1. Introdução 3
• Uso do sudo para dar privilégio de execução de programas como root a determinados
usuários (‘Dando poderes de root para executar determinados programas’ on page 386).
Caso tiver alguma sugestão, correção, crítica para a melhoria deste guia, envie um e-mail para
<gleydson@guiafoca.org>.
O Foca GNU/Linux é atualizado freqüentemente, por este motivo recomendo que preencha a
ficha do aviso de atualizações na página web em Página Oficial do guia Foca GNU/Linux
(http://www.guiafoca.org) no fim da página principal. Após preencher a ficha do aviso
de atualizações, você receberá um e-mail sobre o lançamento de novas versões do guia e o
que foi modificado, desta forma você poderá decidir em copia-la caso a nova versão contenha
modificações que considera importantes.
Tenho recebido elegios de pessoas do Brasil (e de paises de fora também) elogiando o trabalho e
a qualidade da documentação. Agradeço a todos pelo apoio, tenham certeza que este trabalho
é desenvolvido pensando em repassar um pouco do conhecimento que adquiri ao começar o
uso do Linux.
Também venho recebendo muitos e-mails de pessoas que passaram na prova LPI nível 1 e 2
após estudar usando o guia Foca GNU/Linux. Fico bastante feliz por saber disso, pois nunca
tive a intenção de tornar o guia uma referência livre para estudo da LPI e hoje é usado para
estudo desta difícil certificação que aborda comandos, serviços, configurações, segurança, em-
pacotamento, criptografia, etc.
Este guia foi compilado incluindo o nível Avançado do guia FOCA GNU/Linux, ele não tem
a intenção de focar na configuração de serviços, servidores, aplicativos, nem garantia que ele
atenderá a determinada finalidade específica do usuário (principalmente de uma rede, que
depende de uma perfeita compreensão para adaptação de acordo com os requisitos de uma in-
stalação local). Seu foco principal é a instalação do serviço, abordando considerações voltadas
a segurança, e exemplos de configuração e seu funcionamento.
Com relação a capítulos sobre servidores, é importante observar qual versão é documentada
no guia e se confere com a instalada em seu sistema, a fim de que tudo funcione corretamente.
Entretanto, na maioria dos casos, as explicações relacionadas a uma versão de um programa
são inteiramente válidas em uma nova versão.
Capítulo 1. Introdução 4
É assumido que você ja tenha experiência na configuração de sistemas Linux, conheça boa
parte dos comandos e sua utilização, tenha noções de rede e saiba como procurar documen-
tação para complementar o que vem aprendendo. Enfim, requer que se tiver interesse em se
aprofundar em determinada área, que utilize os métodos de busca de documentação sugeridos
no guia para complementação do aprendizado. O guia não contém todos os materiais para que
a pessoa se torne um expert no assunto, mas contém as referências para documentações mais
específicas sobre determinadas áreas do sistema.
Este guia não cobre a instalação do sistema. Para detalhes sobre instalação, consulte a docu-
mentação que acompanha sua distribuição GNU/Linux.
1.3 O Linux
e sendo completamente suportados pelo sistema operacional). Este é um ponto forte para
empresas que desejam manter seus micros em funcionamento e pretendem investir em avanços
tecnológicos com as máquinas que possui.
O Linux é desenvolvido por milhares de pessoas espalhadas pelo mundo, cada uma fazendo
sua contribuição ou mantendo alguma parte do kernel gratuitamente. Linus Torvalds ainda
trabalha em seu desenvolvimento e na coordenação dos grupos de trabalho do kernel.
O suporte ao sistema também se destaca como sendo o mais eficiente e rápido do que qualquer
programa comercial disponível no mercado. Existem milhares de consultores e empresas espe-
cializadas no suporte e treinamento espalhados ao redor do mundo. Outra opção de suporte
é através da comunidade Linux; você pode se inscrever em uma lista de discussão e relatar
sua dúvida ou alguma falha, e sua mensagem será vista por centenas de usuários na Internet
e algum irá te ajudar ou avisará as pessoas responsáveis sobre a falha encontrada para devida
correção.
Capítulo 2
Explicações Básicas
Esta seção tem a intenção de conscientizar o administrador do uso devido de técnicas para
garantir que dados sensíveis sejam apagados de forma um pouco mais segura em seu sistema.
Quando um arquivo é apagado, apenas a entrada na tabela de inodes é mexida, e ele pode
ainda ser recuperado com o debugfs e um pouco de paciência e engenharia. O mesmo acon-
tece com as partições, que podem ser recuperadas com facilidade (isto é explicado no nível
Intermediário do guia). Esta recuperação é proporcionada pelas regras de funcionamento do
sistema de arquivos e do esquema de particionamento, ou seja, são permitidas pelo SO.
Vou um pouco mais além: O disco rígido é uma mídia magnética e opera de forma mecânica
para ler/gravar dados. Quando um arquivo é apagado, seja por qualquer motivo, ainda é
Capítulo 2. Explicações Básicas 10
possível recupera-lo. O que permite isto é porque o HD nem sempre tem a precisão de gravar
exatamente no mesmo lugar (pois a cabeça é movida mecanicamente), gravando em trilhas
microscópicamente vizinhas a anterior. Então a imagem do arquivo que foi apagada continua
lá. Segundo ouvi falar, a NASA possui recursos para recuperar até 60 regravações posteriores
no disco. É claro que isto pode ocorrer em pouco tempo, dependendo do tamanho de sua
partição e se esta for uma /var/spool em um servidor de e-mails :-)
Baseado nesta teoria, você poderá apagar os dados de forma destrutiva usando o programa
shred, que regrava o arquivo repetidamente com dados aleatórios. Sua sintaxe é a seguinte:
shred -n 70 -v -u arquivo
Isto faz com que ele regrava o conteúdo do arquivo 70 vezes com dados aleatórios. O -u
trunca e remove o arquivo após concluído.
Note que o uso de dados aleatórios serve para destruir as possibilidades de uma recuperação
simples, este é o motivo de se recomendar sempre o uso de /dev/urandom ao invés de /dev
/zero para destruição de arquivos.
OBS1: Saiba exatamente o que está fazendo pois estes procedimentos servem para dificultar
ao máximo a recuperação de dados.
OBS2: Devido as tecnologias de sistemas que utilizam journaling (XFS, EXT3, EXT4, JFS e
ReiserFS) e sistemas RAID, o shred não funcionará. O shred também não funcionará com
sistemas de arquivos via rede (NFS, SMB, etc.). Se procura alguma forma de proteger seus
dados, mesmo que apagados, utilize um método de criptografia como o DM-CRYPTO, crypto-
loop, gpg, etc.
OBS3: Caso esteja usando um sistema de arquivos criptografado, estes procedimentos são
quase desnecessários (dependendo do nível de segurança e algorítmos que você utiliza).
2.2 Curingas
Curingas (ou referência global) é um recurso usado para especificar um ou mais arquivos ou
diretórios do sistema de uma só vez. Este é um recurso permite que você faça a filtragem do
que será listado, copiado, apagado, etc. São usados 4 tipos de curingas no GNU/Linux:
O que diferencia este método de expansão dos demais é que a existência do arquivo/diretório
é opcional para geração do resultado. Isto é útil para a criação de diretórios. Lembrando que os
4 tipos de curingas (“*”, “?”, “[]”, “{}”) podem ser usados juntos. Para entender melhor vamos
a prática:
Vamos dizer que tenha 5 arquivo no diretório /usr/teste: teste1.txt,teste2.txt,
teste3.txt,teste4.new,teste5.new.
Caso deseje listar todos os arquivos do diretório /usr/teste você pode usar o coringa “*”
para especificar todos os arquivos do diretório:
cd /usr/teste e ls * ou ls /usr/teste/*.
Não tem muito sentido usar o comando ls com “*” porque todos os arquivos serão listados se
o ls for usado sem nenhum Coringa.
Agora para listar todos os arquivos teste1.txt,teste2.txt,teste3.txt com excessão
de teste4.new, teste5.new, podemos usar inicialmente 3 métodos:
1 Usando o comando ls *.txt que pega todos os arquivos que começam com qualquer
nome e terminam com .txt.
2 Usando o comando ls teste?.txt, que pega todos os arquivos que começam com
o nome teste, tenham qualquer caracter no lugar do coringa ? e terminem com
.txt. Com o exemplo acima teste*.txt também faria a mesma coisa, mas se tam-
bém tivéssemos um arquivo chamado teste10.txt este também seria listado.
3 Usando o comando ls teste[1-3].txt, que pega todos os arquivos que começam
com o nome teste, tenham qualquer caracter entre o número 1-3 no lugar da 6a letra
e terminem com .txt. Neste caso se obtém uma filtragem mais exata, pois o coringa ?
especifica qualquer caracter naquela posição e [] especifica números, letras ou intervalo
que será usado.
Agora para listar somente teste4.new e teste5.new podemos usar os seguintes métodos:
1 ls *.new que lista todos os arquivos que terminam com .new
2 ls teste?.new que lista todos os arquivos que começam com teste, contenham qual-
quer caracter na posição do coringa ? e terminem com .new.
3 ls teste[4,5].* que lista todos os arquivos que começam com teste contenham
números de 4 e 5 naquela posição e terminem com qualquer extensão.
Existem muitas outras formas de se fazer a mesma coisa, isto depende do gosto de cada um. O
que pretendi fazer aqui foi mostrar como especificar mais de um arquivo de uma só vez. O uso
Capítulo 2. Explicações Básicas 12
de curingas será útil ao copiar arquivos, apagar, mover, renomear, e nas mais diversas partes
do sistema. Alias esta é uma característica do GNU/Linux: permitir que a mesma coisa possa
ser feita com liberdade de várias maneiras diferentes.
13
Capítulo 3
Hardware
Hardware é tudo que diz respeito a parte física do computador. Nesta seção serão abordados
assuntos relacionados com a configuração de hardwares, escolha de bons hardwares, disposi-
tivos for Windows, etc.
É um circuito eletrônico encaixado na placa mãe que tem por objetivo adicionar novas fun-
cionalidades ao computador. Esta placa pode ser uma:
• placa de som - para fazer o computador emitir sons, músicas, ligar um joystick, etc.
• Placa de vídeo 3D - Para obter imagens mais rápidas para jogos e ambientes de
desktop 3 dimensões
• fax-modem - para enviar/receber fax, conectar-se a internet, acesso remoto, bina, etc.
• rede - para permitir a comunicação com outros computadores em uma rede interna
O encaixe da placa mãe que recebe as placas de expansão são chamados de Slots.
Capítulo 3. Hardware 14
Seria terrível se ao configurar CADA programa que utilize o mouse ou o modem precisássemos
nos se referir a ele pela IRQ, I/O, etc. . . para evitar isso são usados os nomes de dispositivos.
Os nomes de dispositivos no sistema GNU/Linux são acessados através do diretório /dev. Após
configurar corretamente o modem, com sua porta I/O 0x2F8 e IRQ 3, ele é identificado auto-
maticamente por /dev/ttyS1 (equivalente a COM2 no DOS). Daqui para frente basta se referir
a /dev/ttyS1 para fazer alguma coisa com o modem.
Você também pode fazer um link de /dev/ttyS1 para um arquivo chamado /dev/modem
usando: ln -s /dev/ttyS1 /dev/modem, faça a configuração dos seus programas usando
/dev/modem ao invés de /dev/ttyS1 e se precisar reconfigurar o seu modem e a porta serial
mudar para /dev/ttyS3, será necessário somente apagar o link /dev/modem antigo e criar
um novo apontando para a porta serial /dev/ttyS3.
Não será necessário reconfigurar os programas que usam o modem pois eles estão usando
/dev/modem que está apontando para a localização correta. Isto é muito útil para um bom
gerenciamento do sistema.
Abaixo uma tabela com o nome do dispositivo no GNU/Linux, portas I/O, IRQ, DMA e nome
do dispositivo no DOS (os nomes de dispositivos estão localizados no diretório /dev):
Dispos. Dispos.
Linux DOS IRQ DMA I/O
Dispositivos PCI, PCI Express, AMR, CNR possuem configuração automática de recursos de
hardware, podendo apenas ser ligados na máquina para serem reconhecidos pela placa mãe.
Após isso deverá ser feita a configuração do módulo do kernel para que o hardware funcione
corretamente.
Os parâmetros dos módulos do kernel usados para configurar dispositivos de hardware são
a IRQ, DMA e I/O. Para dispositivos plug and play, como hardwares PCI, basta carregar o
módulo para ter o hardware funcionando.
Existem dois tipos básicos de interrupções: as usadas por dispositivos (para a comunicação
com a placa mãe) e programas (para obter a atenção do processador). As interrupções de software
são mais usadas por programas, incluindo o sistema operacional e interrupções de hardware mais
usado por periféricos. Daqui para frente será explicado somente detalhes sobre interrupções
de hardware.
Os antigos computadores 8086/8088 (XT) usavam somente 8 interrupções de hardware
operando a 8 bits. Com o surgimento do AT foram incluídas 8 novas interrupções, operando a
16 bits. Os computadores 286 e superiores tem 16 interrupções de hardware numeradas de 0
a 15. No kernel 2.4 e superiores do Linux, a função APIC (Advanced Programmable Interruption
Controller) permite gerenciar de forma avançada mais de 15 interrupções no sistema opera-
cional. Estas interrupções oferecem ao dispositivo associado a capacidade de interromper o
que o processador estiver fazendo, pedindo atenção imediata.
As interrupções do sistema podem ser visualizadas no kernel com o comando cat
/proc/interrupts. Abaixo um resumo do uso mais comum das 16 interrupções de hard-
ware:
01 Teclado - Fixa
08 Relógio em tempo real do CMOS - Não pode ser usado por nenhum
outro dispositivo.
09 Esta é uma ponte para IRQ2 e deve ser a última IRQ a ser
utilizada. No entanto pode ser usada por dispositivos.
Dispositivos ISA, VESA, EISA, SCSI não permitem o compartilhamento de uma mesma IRQ,
talvez isto ainda seja possível caso não haja outras opções disponíveis e/ou os dois dispositivos
não acessem a IRQ ao mesmo tempo, mas isto é uma solução precária.
Conflitos de IRQ ocorriam nesse tipo de hardware acima ocasionando a parada ou mal
funcionamento de um dispositivo e/ou de todo o sistema. Para resolver um conflito de
IRQs, deve-se conhecer quais IRQs estão sendo usadas por quais dispositivos (usando cat
/proc/interrupts) e configurar as interrupções de forma que uma não entre em conflito
com outra. Isto normalmente é feito através dos jumpers de placas ou através de software (no
caso de dispositivos jumperless ou plug-and-play).
Dispositivos PCI, PCI Express são projetados para permitir o compartilhamento de inter-
Capítulo 3. Hardware 17
rupções. Se for necessário usar uma interrupção normal, o chipset (ou BIOS) mapeará a in-
terrupção para uma interrupção normal do sistema (normalmente usando alguma interrupção
entre a IRQ 9 e IRQ 12) ou usando APIC (se estiver configurado).
Cada IRQ no sistema tem um número que identifica a prioridade que será atendida pelo pro-
cessador. Nos antigos sistemas XT as prioridades eram identificadas em seqüência de acordo
com as interrupções existentes:
IRQ 0 1 2 3 4 5 6 7 8
PRI 1 2 3 4 5 6 7 8 9
IRQ 0 1 2 (9 10 11 12 13 14 15) 3 4 5 6 7 8
PRI 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Note que a prioridade segue em seqüência através da ponte da IRQ 2 para IRQ 9. Os disposi-
tivos com prioridade mais baixa são atendidos primeiro, mas é uma diferença de desempenho
praticamente imperceptível de ser notada nos sistemas atuais.
A DMA é usada para permitir a transferência de dados entre dispositivos I/O e a memória
sem precisar do processador para fazê-lo. Ele livra esta carga do processador e resulta em uma
rápida transferência de dados.
O PC padrão tem dois controladores de DMA. O primeiro controla os canais 0, 1, 2, 3 e
o segundo os canais 4, 5, 6, 7, assim temos 8 canais. No entanto, o canal 4 é perdido
porque é usado pelo controlador de acesso direto a memória. Os canais 0-3 são chamados de canais
baixos porque podem somente mover um byte (8 bits) por transferência enquanto canais altos
movem 2 bytes (16 bits) por transferência.
Os dados movidos usando a DMA não são movidos através do controlador de DMA. Isto ofer-
ece uma limitação porque a DMA somente podem mover dados entre os dispositivos (portas
I/O) e a memória. Não é possível mover dados entre as portas ou entre a memória.
Existem dois controladores de DMA nos computadores AT e superiores. Ao contrário do que
acontece com os dois controladores de IRQ, o primeiro controlador é ligado ao segundo e não
o segundo ao primeiro. Os canais de DMA altos (5 ao 7) somente podem ser acessados por
dispositivos de 16 bits (aqueles que utilizam a segunda parte do slot AT). Como resultado
temos 8 canais de DMA, de 0 a 7, sendo que a DMA 4 é usada como ligação entre eles.
Os canais de DMA em uso no sistema podem ser visualizados com cat /proc/dma. Abaixo
uma listagem de uso mais comum dos canais de DMA.
Capítulo 3. Hardware 18
Somente dispositivos ISA e derivados dele, como o EISA e VESA, usam os canais de DMA
padrão. Os atuais dispositivos de alta taxa de transferência (normalmente PCI) possuem seu
próprio controlador de DMA embutido, muito mais rápido do que a DMA padrão. Este con-
trolador de DMA é chamado de Bus Mastering e muito usado nos discos rígidos atuais e pode
atingir taxas de 33,3MB/s (no modo 2) e 66MB/s (no modo 4 - requer um cabo IDE com ater-
ramento para evitar interferências de ruídos externos).
Conflitos de DMA
Um canal de DMA não pode ser compartilhado entre dispositivos. Ainda é possível configurar
dois dispositivos para usarem um mesmo canal de DMA, desde que ele não seja usado ao
mesmo tempo. Isto acontece com Scanners paralelos que compartilham a mesma porta paralela
com a impressora. Se você for uma pessoa que explora os recursos de multitarefa de seu Linux
e seu desempenho, evite estes tipos de dispositivos, prefira aqueles que utilizam seus próprios
recursos.
Quando ocorre um conflito de DMA, os dados podem ser misturados e ocorrerem coisas es-
tranhas até o travamento total do sistema. Este tipo de conflito é difícil de se diagnosticar, a não
ser que o técnico seja experiente o bastante e tenha desconfiado do que o problema se trata. . .
Entrada/Saída ou uma faixa de endereços. Por exemplo, uma placa de som padrão usa as
portas 0x220, 0x330 e 0x388, respectivamente audio digital, midi e opl3.
As placas de rede normalmente transferem grandes quantidades de dados, assim ocupam uma
faixa de endereços. Uma NE2000, por exemplo, ocupa a faixa de endereços 0x260 a 0x27F
(0x260-0x27F). O tamanho da faixa de endereços varia de acordo com o tipo de dispositivo.
Os endereços de I/O em uso no sistema podem ser visualizados com o comando cat
/proc/ioports.
Endereços das portas de entrada/saída não podem ser compartilhados
3.4.1 Jumpers
Hardwares configuráveis por jumpers (pinos metálicos protegidos por uma capa plástica) tem
sua configuração alterada através da colocação, retirada ou mudança de posição física do pino.
Este tipo de hardware, antigamente presente em placas ISA e VESA, não é mais usado atual-
mente devido a configuração Plug and Play de dispositivos PCI, PCI express, etc.
As disposição dos jumpers são normalmente definidas em fechado/aberto e multi-posição. Na
disposição fechado/aberto, o jumper pode ou não ser colocado, definindo a configuração do
dispositivo:
::|::
obtendo um excelente manual de instruções. Nesta hora a experiência conta mais que o uso de
programas de diagnóstico.
3.4.2 Dip-Switches
É a mesma coisa que os hardwares configuráveis por jumpers exceto que são usados dip-
switches no lugar de jumpers. O dip-switches é um conjunto de chaves numeradas que po-
dem ser colocadas para cima ou para baixo (como um disjuntor ou vários interruptores
LIGA/DESLIGA colocados um ao lado do outro) para se modificar a configuração do disposi-
tivo.
A maioria das placas jumperless podem funcionar também como Plug-and-Play. Existem
muitas placas de rede, fax-modem, scanner jumperless no mercado.
3.4.4 Plug-and-Play
Veja a próxima seção para entender como funciona o arquivo de configuração isapnp.conf
e assim poder ativar seu dispositivo Plug-and-Play.
Capítulo 3. Hardware 21
Ocorre quando um ou mais dispositivos usam a mesma IRQ, I/O ou DMA. Um sistema com
configurações de hardware em conflito tem seu funcionamento instável, travamentos con-
stantes, mal funcionamento de um ou mais dispositivos e até mesmo, em casos mais graves,
a perda de dados. Conflitos geralmente ocorriam em placas ISA, VESA onde era necessário
conhecer e usar uma tabela de valores padrões para a configuração de periféricos (como a
mostrada no inicio desse capítulo).
Para resolver conflitos de hardware é necessário conhecer a configuração de cada dispos-
itivo em seu sistema. Os comandos cat /proc/interrupts, cat /proc/dma e cat
/proc/ioports podem ser úteis para se verificar as configurações usadas.
3.7 Barramento
O tipo de slot varia de acordo com o barramento usado no sistema, que pode ser um(s) do(s)
seguinte(s):
ISA 8 Bits Industry Standard Architecture - É o padrão mais antigo, encontrado em
computadores PC/XT.
ISA 16 Bits Evolução do padrão ISA 8 Bits, possui um conector maior e permite a conexão de
placas de 8 bits. Sua taxa de transferência chega a 2MB/s.
VESA Video Electronics Standard Association - É uma interface feita inicialmente
para placas de vídeo rápidas. O barramento VESA é basicamente um ISA com um en-
caixe extra no final. Sua taxa de transferência pode chegar a 132MB/s.
Capítulo 3. Hardware 22
Placas on-board são embutidas na placa mãe (motherboard). Placas off-board são placas externas
encaixadas nos slots de expansão da placa mãe.
No inicio da era do PC/XT todos as placas eram embutidas na placa mãe (na época eram
somente a placa de vídeo e controladora). Com o surgimento do padrão AT, diversas empresas
de informática desenvolveram dispositivos concorrentes e assim o usuário tinha a liberdade
de escolha de qual dispositivo colocar em sua placa mãe (ou o mais barato ou o de melhor
qualidade e desempenho), isto permitiu a adição de periféricos de qualidade sem romper com
seu orçamento pessoal (comprando uma placa de som, depois uma de fax-modem, placa de
vídeo melhor, etc).
Atualmente parece que voltamos ao ponto de partida e tudo vem embutido na placa mãe
(on-board) e o usuário não tem como escolher qual dispositivo usar em seu computador. É
muito difícil (praticamente impossível) encontrar uma placa mãe que satisfaça completamente
as necessidades do usuário ou recomendações de um bom técnico de informática (a não ser
que seja um técnico experiente e encontre alguma alternativa).
Certamente o único dispositivo que funciona melhor se embutido na placa mãe é a placa con-
troladora de periféricos. Esta placa é usada para se conectar unidades de disquete, discos rígidos,
CD-ROM, portas seriais, paralelas, joystick ao computador. Os HDs conectados em uma con-
troladora embutida conseguem ter um desempenho muito maior do que em placas conectadas
externamente, sem causar nenhum tipo de problema.
Hardwares embutidos na placa mãe (como fax-modem, vídeo, som) são em média 30% mais
baratos que os vendidos separadamente mas quase sempre são usados dispositivos de baixo
desempenho e qualidade para reduzir o preço da placa mãe e quase sempre usados hardwares
For Windows.
Hoje em dia por causa do preço da placa mãe, é comum encontrar pessoas que verificam so-
mente o preço e sequer procuram saber ou conhecem a qualidade das placas embutidas na
placa mãe. Pior ainda é encontrar vendedores despreparados que sequer sabem explicar o
porque que uma placa de som Sound Blaster 128 é mais cara que uma de modelo genérico. . .
Geralmente dispositivos on-board trazem problemas caso tal dispositivo queime e geralmente
é colocado um hardware de baixa qualidade para baratear o custo de placas mãe, que na maio-
ria das vezes também oferece grande dificuldade para ser configurada no Linux.
Outro periférico que traz problemas e carga para o processador é o fax-modem for Windows,
HSP, AMR, micromodem, etc. utilizando o processador do sistema para realizar seu trabalho
e algumas vezes não trazem nem mesmo o chip UART. Isso resulta em perda de qualidade na
conexão e maior consumo telefônico.
Se você estiver em uma situação destas, certamente os computadores de menor potência e com
hardwares inteligentes (que possuem seus próprios chips de controle e processamento) não
terão o desempenho comprometido. O preço pode ser maior mas você estará pagando por um
dispositivo de melhor qualidade e que certamente trará benefícios a você e ao seu sistema.
Consulte um técnico em informática experiente para te indicar uma placa mãe de bom preço e
de qualidade. É muito comum encontrar falta de profissionalismo em pessoas que não sabem
Capítulo 3. Hardware 24
distinguir as características, funções e vantagens entre uma placa de boa qualidade e um hard-
ware for Windows a não ser o preço mais barato.
Esta seção foi retirada do manual de instalação da Debian GNU/Linux. Uma tendência que
perturba é a proliferação de Modens e impressoras específicos para Windows. Em muitos
casos estes são especialmente fabricados para operar com o Sistema Operacional Microsoft
Windows e costumam ter a legenda WinModem, for Windows, ou Feito especialmente
para computadores baseados no Windows.
Geralmente estes dispositivos são feitos retirando os processadores embutidos daquele hard-
ware e o trabalho deles são feitos por drivers do Windows que são executados pelo processador
principal do computador. Esta estratégia torna o hardware menos caro, mas o que é poupado
não é passado para o usuário e este hardware pode até mesmo ser mais caro quanto disposi-
tivos equivalentes que possuem inteligência embutida.
Você deve evitar o hardware baseado no Windows por duas razões:
1 O primeiro é que aqueles fabricantes não tornam os recursos disponíveis para criar um
driver para Linux. Geralmente, o hardware e a interface de software para o dispositivo
é proprietária, e a documentação não é disponível sem o acordo de não revelação, se ele
estiver disponível. Isto impede seu uso como software livre, desde que os escritores de
software grátis descubram o código fonte destes programas.
2 A segunda razão é que quando estes dispositivos tem os processadores embutidos re-
movidos, o sistema operacional deve fazer o trabalho dos processadores embutidos, fre-
qüentemente em prioridade de tempo real, e assim a CPU não esta disponível para exe-
cutar programas enquanto ela esta controlando estes dispositivos.
Assim o usuário típico do Windows não obtém um multi-processamento tão intensivo
como um usuário do Linux, o fabricante espera que aquele usuário do Windows sim-
plesmente não note a carga de trabalho que este hardware põe naquela CPU. No entanto,
qualquer sistema operacional de multi-processamento, até mesmo Windows 9X, XP e
Vista, são prejudicados quando fabricantes de periféricos retiram o processador embu-
tido de suas placas e colocam o processamento do hardware na CPU.
Você pode ajudar a reverter esta situação encorajando estes fabricantes a lançarem a documen-
tação e outros recursos necessários para nós desenvolvermos drivers para estes hardwares,
mas a melhor estratégia é simplesmente evitar estes tipos de hardwares até que ele esteja lis-
tado no HOWTO de hardwares compatíveis com Linux.
Note que hoje já existem muitos drivers para WinModems e outros hardwares for Windows
para o Linux. Veja a lista de hardwares compatíveis no HARDWARE-HOWTO ou procure o
driver no site do fabricante de seu dispositivo. Mesmo assim a dica é evitar hardwares for
Windows e comprar hardwares inteligentes onde cada um faz sua função sem carregar a CPU.
Capítulo 3. Hardware 25
Esta seção foi retirada do manual de instalação da Debian GNU/Linux. Existem diversos
vendedores, agora, que vendem sistemas com a Debian ou outra distribuição do GNU/Linux
pré-instaladas. Você pode pagar mais para ter este privilégio, mas compra um nível de
paz de mente, desde então você pode ter certeza que seu hardware é bem compatível com
GNU/Linux. Praticamente todas as placas que possuem processadores próprios funcionam
sem nenhum problema no Linux (algumas placas da Turtle Beach e mwave tem suporte de
som limitado).
Se você tiver que comprar uma máquina com Windows instalado, leia cuidadosamente a li-
cença que acompanha o Windows; você pode rejeitar a licença e obter um desconto de seu
vendedor.
Se não estiver comprando um computador com GNU/Linux instalado, ou até mesmo um com-
putador usado, é importante verificar se os hardwares existentes são suportados pelo kernel
do GNU/Linux. Verifique se seu hardware é listado no Hardware Compatibility HOWTO, na
documentação do código fonte do kernel no diretório Documentation/sound ou consulte
um técnico de GNU/Linux experiente.
Deixe seu vendedor (se conhecer) saber que o que está comprando é para um sistema
GNU/Linux. Desta forma isto servirá de experiência para que ele poderá recomendar o mesmo
dispositivo a outras pessoas que procuram bons dispositivos para sistemas GNU/Linux. Apóie
vendedores de hardwares amigos do GNU/Linux.
OSS é o presente por padrão desde que o suporte a som foi incluído no kernel. Para configurar
uma placa de som para usar este sistema de som, primeiro compile seu kernel com o suporte ao
módulo de sua placa de som. Caso seja uma placa ISA, você provavelmente terá que habilitar
a seção “Open Sound System” para ver as opções disponíveis (entre elas, a Sound Blaster e
compatíveis). Uma olhada na ajuda de cada módulo deve ajuda-lo a identificar quais placas
cada opção do kernel suporta.
Caso seu kernel seja o padrão de uma distribuição Linux, provavelmente terá o suporte a
todas as placas de som possíveis. Siga o passo a passo abaixo para configurar sua placa de som
no sistema:
Capítulo 3. Hardware 27
1 Primeiro descubra se sua placa de som é ISA. Caso seja, verifique se os seus recursos
estão alocados corretamente (veja ‘Conflitos de hardware’ on page 21). Caso seja PCI,
AMR, execute o comando lspci, procure pela linha “Multimedia” e veja o nome da
placa. Você também poderá executar o comando lshw para descobrir qual placa você
possui (veja ‘Listando as placas e outros hardwares em um computador’ on page 21)
para detalhes.
2 Carregue o módulo da placa de som com o comando modprobe módulo . Na Debian,
você pode executar o comando modconf para navegar visualmente entre os módulos
disponíveis e carregar os módulos necessários. Algumas placas (principalmente ISA)
requerem que seja especificado o recurso de hardware sejam passados para seu módulo,
ou simplesmente você quer especificar isto para manter o uso de hardware sobre seu
controle. Alguns dos parâmetros mais usados em placas Sound Blaster são os seguintes:
modprobe sb io=0x220 irq=5 dma=1 dma16=5 mpu_io=0x330
Para evitar ter que passar estes parâmetros todas as vezes para o módulo, você poderá
coloca-los no arquivo /etc/modules.conf da seguinte forma:
options sb io=0x220 irq=5 dma=1 dma16=5 mpu_io=0x330
Assim, quando der o comando modprobe sb ele será carregado com as opções acima.
Na distribuição Debian, você deverá criar um arquivo chamado /etc/modutils/sb
contendo a linha acima, depois execute o update-modules para “juntar” todos os ar-
quivos do /etc/modutils e criar o /etc/modules.conf.
3 Após carregar o módulo correto de sua placa de som, seu sistema de som deverá estar
funcionando. Se você utiliza uma distribuição Linux, os dispositivos de som como /dev
/audio, /dev/dsp, /dev/mixer estarão criados e então poderá passar para o próximo
passo. Caso não existam, entre no diretório /dev e execute o comando MAKEDEV audio.
4 O próximo passo consiste em instalar um programa para controle de volume, tonali-
dade e outros recursos de sua placa de som. O recomendado é o aumix por ser simples,
pequeno e funcional, e permitindo restaurar os valores dos níveis de volumes na inicial-
ização (isso evita que tenha que ajustar o volume toda vez que iniciar o sistema). Caso o
aumix apareça na tela, sua placa de som já está funcionando! Caso acesse o sistema como
usuário, não se esqueça de adicionar seu usuário ao grupo audio para ter permissão de
usar os dispositivos de som: adduser usuario audio .
Caso seu gravador seja IDE, veja ‘Configurando o suporte a um gravador IDE’ on this page
caso seja um autêntico gravador com barramento SCSI, vá até ‘Configurando o suporte a um
gravador SCSI’ on the next page.
Caso tenha um gravador IDE e use um kernel 2.6 ou superior, não é necessário fazer qual-
quer configuração, pois seu gravador já está pronto para ser usado, sendo acessado através
de seu dispositivo tradicional (/dev/hdc, /dev/hdd, etc). De qualquer forma, você poderá
Capítulo 3. Hardware 28
realizar a configuração da unidade IDE com emulação SCSI, assim como utilizava no kernel
2.4 e inferiores seguindo as instruções abaixo.
Para configurar seu gravador de CD/DVD IDE para ser usado no Linux usando o método
para o kernel 2.4 e inferiores, siga os seguintes passos:
1 Tenha certeza que compilou o suporte as seguintes características no kernel:
Em "ATA/IDE/MFM/RLL support" marque as opções:
* Include IDE/ATAPI CDROM support
* SCSI emulation support
Caso tenha um autentico gravador SCSI, não será preciso fazer qualquer configuração de em-
ulação, a unidade estará pronta para ser usada, desde que seu suporte esteja no kernel. As
seguintes opções do kernel são necessárias para funcionamento de gravadores SCSI:
Capítulo 3. Hardware 29
Além disso, deve ser adicionado o suporte EMBUTIDO no kernel a sua controladora SCSI. Se
o seu disco rígido também é SCSI, e seu CD está ligado na mesma controladora SCSI, ela já está
funcionando e você poderá seguir para o passo ‘Testando o funcionamento’ on this page. Caso
contrário carregue o suporte da sua placa adaptadora SCSI antes de seguir para este passo.
Testando o funcionamento
Para testar se o seu gravador, instale o pacote wodim e execute o comando: wodim -scanbus
para verificar se sua unidade de CD-ROM é detectada.
Você deverá ver uma linha como:
scsibus0:
0,0,0 0) ’CREATIVE’ ’CD-RW RWXXXX ’ ’1.00’ Removable CD-ROM
0,1,0 1) *
0,2,0 2) *
O que significa que sua unidade foi reconhecida perfeitamente pelo sistema e já pode ser usada
para gravação. Note que gravadores IDE nativos, não são listados com esse comando.
O APM (Advanced Power Management - Gerenciamento Avançado de Energia) permite que sistemas
gerenciem características relacionadas com o uso e consumo de energia do computador. Ele
opera a nível de BIOS e tenta reduzir o consumo de energia de várias formas quando o sistema
não estiver em uso (como reduzindo o clock da CPU, desligar o HD, desligar o monitor, etc.).
O uso de advanced power management também permite que computadores com fonte de
alimentação ATX sejam desligados automaticamente quando você executa o comando halt.
Caso sua máquina tenha suporte a ACPI, este deverá ser usado como preferência ao invés
do APM por ter recursos mais sofisticados (veja ‘Configurando o gerenciamento de energia
usando ACPI’ on the next page).
Para ativar o suporte a APM no Linux, compile seu kernel com o suporte embutido a APM
e também a “Advanced Power Management” (senão sua máquina não desligará sozinha no
halt). Caso deseje compilar como módulo, basta depois carregar o módulo apm adicionando no
arquivo /etc/modules. Depois disso instale o daemon apmd para gerenciar as características
deste recurso no sistema.
Você pode desativar o uso de APM de 3 formas: removendo seu suporte do kernel, passando
o argumento apm=off (quando compilado estaticamente no kernel) ou removendo o nome do
Capítulo 3. Hardware 30
módulo do arquivo /etc/modules (quando compilado como módulo). Depois disso remova
o daemon apmd.
Algumas placas mãe ATX possuem suporte a este interessante recurso, que permite sua
máquina ser ligada através de uma rede. Isto é feito enviando-se uma seqüência especial de
pacotes diretamente para o MAC (endereço físico) da placa de rede usando um programa es-
pecial.
Capítulo 3. Hardware 31
Para usar este recurso, seu sistema deverá ter as seguintes características:
• Placa mãe ATX
• Fonte de alimentação ATX compatível com o padrão 2.0, com fornecimento de pelo
menos 720ma de corrente na saída +3v.
• Placa de rede com suporte a WakeUP-on-Lan (WOL), você poderá confirmar isto vendo
um conector branco de 3 terminais instalado na placa que é o local onde o cabo wake-up
é conectado.
• Suporte na BIOS também deverá ter a opção para WakeUP-on-Lan.
Com todos esses ítens existentes, instale em uma máquina da rede o pacote etherwake. De-
pois disso, pegue o MAC address a placa de rede da máquina que tem o wakeup on lan e na
máquina da rede onde instalou o pacote execute o seguinte comando:
ether-wake AA:BB:CC:DD:EE:FF
3.12 Aterramento
O aterramento correto da instalação elétrica é essencial para garantir a proteção de seu micro-
computador (e outros aparelhos que requerem isto). Muitos usuários simplesmente removem
o pino central da tomada de seu computador, ou ligam o terra junto ao neutro da rede elétrica,
isto é errado e pode trazer sérias conseqüências. O computador possui componentes sensíveis
que geram descargas estáticas durante seu funcionamento (fonte, discos, placas, etc), estas
descargas e ruídos são absorvidas pelo sistema de aterramento (que é ligado no gabinete do
computador e outros componentes internos). Sem aterramento o seu gabinete passará a dar
choques elétricos (teste com uma chave de testes, ela acenderá indicando a circulação de cor-
rente elétrica) e a corrente acumulada poderá queimar componentes internos sensíveis (placa
mãe, HD, memórias, placas expansoras).
A ligação do terra ao neutro da rede é menos perigosa em condições normais, mas se um raio
cair na rede elétrica as conseqüências poderão ser piores. Mesmo a rede de iluminação pública
tendo aterramento em cada poste isto pode não ser o suficiente para reduzir a carga de um raio
que caia nas proximidades.
O sistema de aterramento residencial para PC deve ser feito com uma estaca de cobre com no
mínimo 2 metros de altura. O cobre é um ótimo condutor de eletricidade, perdendo somente
para a prata (veja ‘Condutores de eletricidade’ on the following page). Cave um buraco no solo
com a ajuda de uma cavadeira (hehe, nunca ouviu falar nisso? :-), se estiver com dificuldades
para cavar por causa de solo ressecado, molhe a terra para facilitar as coisas. Com a estaca
enterrada, prenda um cabo elétrico em sua extremidade.
Capítulo 3. Hardware 32
O ideal para testar este sistema de aterramento seria ter um equipamento chamado
terrômetro (medidor de aterramento), mas utilizaremos 2 alternativas mais acessíveis:
• Ligue uma lâmpada incandescente de 100W em um bocal com uma ponta ligada na ex-
tremidade positiva da rede elétrica (fase) e a outra ponta no fio da barra de cobre. O ater-
ramento está bem feito quando a lâmpada acender quase em sua potência total. Ligue o
fio do aterramento no pino central da tomada de seu computador. OBS: Cuidado para
não tomar um baita choque durante esta operação em alguns casos pode ser fatal. Utilize
sandalhas ou sapatos de borracha (materiais isolantes) isto evitará tomar o choque caso
aconteça.
• Ligue a outra extremidade do fio que vem da barra de cobre no pino central da tomada
de seu computador e ligue-o. Consiga um multímetro (analógico ou digital) e coloque
para medir em escala DC 10V. Coloque a ponta negativa (preta) no neutro da rede elétrica
e encoste a ponta positiva (vermelha) no gabinete de seu computador. O aterramento
estará aprovado caso o valor medido seja de no máximo 2.5 volts.
Caso algo ocorra errado, cheque novamente os passos acima. Se desconfiar das condições do
solo, use uma barra maior ou ligue 2 barras de cobre juntas.
A tabela abaixo está classificada em ordem do material que possui melhor condução de eletri-
cidade (elétrons com circulaçãos livres) baseada no fator mm2/m. (da mais condutora para a
menos condutora).
1 Prata - 0,0164
2 Cobre - 0,0172
3 Ouro - 0,0230
4 Alumínio - 0,0283
5 Zinco - 0,0600
6 Platina - 0,0950
7 Ferro - 0,1200
8 Chumbo - 0,2100
9 mercúrio - 0,9680
3.13 Tomadas
As tomadas elétricas de 127V ou 220V AC 60Hz de três pinos, pelas normas técnicas da ABNT,
no. ABNT 6147 devem ficar distantes no máximo a 1,5 metro dos equipamentos e com terceiro
pino ligado à terra. É interessante que a tensão das tomadas esteja identificada nas mesmas,
em caso de mais de uma voltagem fornecida no local, evitando a queima de equipamentos.
Segue abaixo um exemplo de tomada fêmea e a recomendação para sua montagem. Note
que a entrada para o pino terra é voltado para cima, pois o caimento dos fios da maioria dos
equipamentos fabricados estarão desta forma voltados para baixo.
127v 220v
Capítulo 3. Hardware 33
+-----------+ +-----------+
Terra ---+----(_) | Terra ---+----(_) |
| _ _ | | _ _ |
| _| | | |_ | | _| | | |_ |
Fase ---+(_ | | _)+--- Neutro Fase ---+(_ | | _)+--- Fase
| |_| |_| | | |_| |_| |
| _ | | _ |
+-----------+ +-----------+
Como comentando anteriormente, não utilize como ponto de terra os sistemas de aterramento
das companhias de eletricidade, telefonia, ar condicionado e sistema de pára-raios.
É a energia que se acumula durante o choque das moléculas de ar seco ou atrito com outros ob-
jetos. Pode acontecer de em dias secos você tomar um “choque” ao abrir seu carro ou tocar em
algum objeto metálico, isto é uma descarga estática. Na realidade você não tomou um choque,
ao tocar em um objeto metálico esta energia é descarregada violentamente. Esta energia pode
chegar na ordem de 5 mil volts quando acumulada (assustador não?).
É por este motivo que caminhões que transportam combustível arrastam uma corrente no
chão, esta corrente funciona como um aterramento (veja ‘Aterramento’ on page 31) eliminando
descargas estáticas que possam gerar faíscas e causar um desastre. Pulseiras, cordões, objetos
metálicos podem ser usados para eliminar descargas estáticas de pessoas. O contato freqüente
com o solo é um método muito útil. Existem casos em que um colar salvou a vida de pessoas
atingidas por raio, justamente pelas explicações acima. O colar derrete com a drenagem da
eletricidade do raio mas a pessoa tem mais chances de sair viva.
Em indivíduos realmente sensíveis, uma chapinha de metal pode ser colocada no sapato
fazendo contato com o calcanhar drenando constantemente estas descargas, isto é eficaz e bem
melhor que sair arrastando correntes por ai :-)
Se você trabalha com hardwares ou é apenas mais um fuçador de PCs, agora você entenderá
porque é recomendável sempre tocar em partes metálicas do computador antes de mexer em
qualquer placa e porque aquele seu amigo disse que a placa dele queimou depois que resolveu
limpar seus contatos.
3.15.1 Particionamento
Para um melhor desempenho, os dados que são solicitados constantemente deverão ser ar-
mazenados em uma partição no inicio do disco rígido. Esta área é a mais rápida e checa a ser
60% mais rápida que o final do HD (em alguns modelos). Em especial, a partição de boot, swap
Capítulo 3. Hardware 34
e binários do sistema poderão ser armazenados nesta partição para aumentar a velocidade da
carga de programas e não prejudicar a performance do sistema quando o uso da partição de
troca (swap) for necessária.
Em discos rígidos grandes (6GB ou maiores) é recomendável criar no mínimo uma partição
pequena para /boot, outra para /, outra para swap e outra para /usr. Ficando distribuídas
da seguinte maneira no disco rígido:
BBRRRRRRRRRRRRRRRRRRRRR
RRRRRRRRRRRRRRRRRRRRRRR
SSSSSSSSSSUUUUUUUUUUUUU
UUUUUUUUUUUUUUUUUUUUUUU
UUUUUUUUUUUUUUUUUUUUUUU
UUUUUUUUUUUUUUUUUUUUUUU
UUUUUUUUUUUUUUUUUUUUUUU
UUUUUUUUUUUUUUUUUUUUUUU
UUUUUUUUUUUUUUUUUUUUUUU
B - /boot
R - Raíz /
S - Swap
U - /usr
Mas a swap não ficaria ainda mais rápida sendo a primeira partição no disco? Sim e não:
Realmente fica rápida (na teoria conforme explicado acima), mas levando em consideração
que o deslocamento das cabeças de leitura/gravação do disco rígido leva certo tempo, é mais
vantajoso mantê-la entre as 2 partições mais acessadas, isto diminui o tempo de acesso caso
um programa esteja fazendo uso constante de / ou /usr e precisar trocar dados na partição
swap.
Além do mais, a partição / geralmente é pequena (no máximo 800M) deixando a swap em
uma área muito próxima do inicio do disco rígido. Com base nisto, você poderá ter uma
melhor visão técnica para a construção de suas partições dependendo da função do sistema.
3.15.2 Spindles
Em sistemas que utilizam um disco rígido dedicado para fazer swap, a ligação deste em uma
placa controladora independente aumentará bastante a performance do sistema, pois enquanto
o disco principal ligado em sua controladora estiver fazendo uma operação de leitura, o outro
poderá estar fazendo sua operação de swap simultaneamente. O mesmo não acontece quando
dois discos rígidos IDE estão ligados no mesmo cabo (isto não acontece no SCSI).
/dev/hdb:
multcount = 0 (off)
I/O support = 0 (16-bit)
unmaskirq = 0 (off)
using_dma = 1 (off)
keepsettings = 0 (off)
nowerr = 0 (off)
readonly = 0 (off)
readahead = 8 (on)
OBS: Se o Linux resetar o disco rígido, a maioria das configurações retornarão ao seu valor
padrão. Isto ocorre devido a opções mau utilizadas no hdparm, não suportadas pelo disco
rígido ou por problemas no HD/controladora.
Exemplos:
Toda vez que acessamos um arquivo ou diretório da máquina Linux a data/hora é atualizada.
Em máquinas normais isto é OK mas em servidores onde o acesso a arquivos é constante (como
no diretório /var/spool em servidores de e-mail ou /usr/ em servidores diskless) é re-
comendável desativar esta característica. Isto reduzirá a quantidade de buscas das cabeças do
disco rígido para a atualização deste atributo e conseqüentemente aumentará a performance
na gravação de arquivos (o disco rígido usa o sistema mecânico para ler/gravar dados, muito
mais lento que a memória RAM eletrônica).
chattr -R +A /var/spool
Hardwares SATA (Serial ATA) representam a próxima geração em tecnologia usada para a
transferência de dados em alta velocidade a baixo custo. Hoje está se tornando o padrão de
indústria a utilização de dispositivos SATA em micros em substituição a dispositivos IDE.
Dispositivos IDE tradicionais são chamados de PATA (parallel ATA, ou ATA paralelo).
Estes dispositivos são classificados em 2 tipos:
• SATA I - Esta se tornando alternativa a discos IDE (PATA). Possui taxa de transferência
de até 150Mb/s
• SATA II - Esta se tornando alternativa a discos IDE (PATA). Possui taxa de transferência
de até 300Mb/s
Um cabo SATA tende a ter o mesmo comprimento de um cabo IDE, raramente excedendo 50
centimetros.
Hardwares SCSI (Small Computer System Interfaces) representam a tecnologia ideal para a
transferência de dados em alta velocidade e ligação de vários periféricos. A taxa de transfer-
ência especificada para dispositivos SCSI é sempre a padrão se comparada a dispositivos IDE
(quando uma taxa de 66Mb/s quase nunca é atingida).
Estes dispositivos são classificados em 3 categorias:
• SCSI I - Usa um cabo de 25 condutores para a ligação de periféricos. Normalmente
usado em scanners, impressoras e outros dispositivos. A taxa de transferência não é
muito alta se comparado aos outros tipos SCSI.
• SCSI II - Também chamado de Fast SCSI. Usa um cabo de 50 condutores para a ligação
de periféricos. Permite que sejam ligados até 7 periféricos em uma mesma controladora
(veja ‘Configurando uma SCSI ID e terminação’ on the facing page). É o mais comum
encontrado hoje em dia, mas vem perdendo espaço aos poucos para a tecnologia SCSI
III.
• SCSI III - Também chamado de Fast SCSI SE ou LVD. Usa um cabo de 68 condutores
para ligação de periféricos (veja ‘Configurando uma SCSI ID e terminação’ on the next
page). Permite que sejam ligados até 16 periféricos em uma mesma controladora.
• SATA I - Esta se tornando alternativa a discos IDE (PATA). Possui taxa de transferência
de até 150Mb/s
• SATA II - Esta se tornando alternativa a discos IDE (PATA). Possui taxa de transferência
de até 300Mb/s
Um cabo SCSI pode ter o comprimento de até 5 metros de extensão. Os periféricos SCSI são
identificados através de números chamados de identificador SCSI ou SCSI ID. Estes números
vão de 0 a 6 para o padrão SCSI 2 e de 0 a 15 para o padrão SCSI 3.
Placas SCSI como a Adaptec UV 19160 permitem a ligação de periféricos SCSI 2 e SCSI 3 na
mesma placa com a taxa de transmissão de 160 MB/s por periférico, além de possuir um
“setup” próprio para configurar as opções dos dispositivos da placa e a operação da própria.
A tecnologia SCSI é algo realmente rápido para a transferência de dados e cara também, seu
Capítulo 3. Hardware 39
uso é muito recomendado em servidores críticos. Os próprios dispositivos SCSI como discos
rígidos, gravadores de CD, cd-rom, etc. são construídos de tal forma que tem a durabilidade
maior que periféricos comuns, garantindo a máxima confiança para operação/armazenamento
de dados em longos períodos de operação.
+--------------------------------------------
|
|
|
|SCSI ID
| |
| _____ TERM
| | | | |
| o o o o o o
| o o o o o o
| 1 2 4 T
|
+---------------------------------------------
Capítulo 4
Rede
Este capítulo descreve o que é uma rede, os principais dispositivos de rede no GNU/Linux,
a identificação de cada um, como configurar os dispositivos, escolha de endereços IP, rotea-
mento.
Parte deste capítulo, uns 70% pelo menos, é baseado no documento NET3-4-HOWTO. (seria
perda de tempo reescrever este assunto pois existe um material desta qualidade já disponível).
Rede é a conexão de duas ou mais máquinas com o objetivo de compartilhar recursos entre
uma máquina e outra. Os recursos podem ser:
• Compartilhamento do conteúdo de seu disco rígido (ou parte dele) com outros usuários.
Os outros usuários poderão acessar o disco como se estivesse instalado na própria
máquina). Também chamado de servidor de arquivos.
• Compartilhamento de uma impressora com outros usuários. Os outros usuários poderão
enviar seus trabalhos para uma impressora da rede. Também chamado de servidor de
impressão.
• Compartilhamento de acesso a Internet. Outros usuários poderão navegar na Internet,
pegar seus e-mails, ler noticias, bate-papo no IRC, ICQ através do servidor de acesso
Internet. Também chamado de servidor Proxy.
• Servidor de Internet/Intranet. Outros usuários poderão navegar nas páginas Internet
localizadas em seu computador, pegar e-mails, usar um servidor de IRC para chat na
rede, servidor de ICQ, etc
Com os ítens acima funcionando é possível criar permissões de acesso da rede, definindo quem
terá ou não permissão para acessar cada compartilhamento ou serviço existente na máquina
(www, ftp, irc, icq, etc), e registrando/avisando sobre eventuais tentativas de violar a segu-
rança do sistema, firewalls, pontes, etc.
Entre outras ilimitadas possibilidades que dependem do conhecimento do indivíduo no am-
biente GNU/Linux, já que ele permite muita flexibilidade para fazer qualquer coisa funcionar
em rede.
Capítulo 4. Rede 42
4.3 Endereço IP
O endereço IP são números que identificam seu computador em uma rede. Inicialmente você
pode imaginar o IP como um número de telefone. O IP é compostos por quatro bytes e a
convenção de escrita dos números é chamada de “notação decimal pontuada”. Por convenção,
cada interface (placa usada p/ rede) do computador ou roteador tem um endereço IP. Também
é permitido que o mesmo endereço IP seja usado em mais de uma interface de uma mesma
máquina mas normalmente cada interface tem seu próprio endereço IP.
As Redes do Protocolo Internet são seqüências contínuas de endereços IP’s. Todos os endereços
dentro da rede tem um número de dígitos dentro dos endereços em comum. A porção dos en-
dereços que são comuns entre todos os endereços de uma rede são chamados de porção da rede.
Os dígitos restantes são chamados de porção dos hosts. O número de bits que são compartilhados
por todos os endereços dentro da rede são chamados de netmask (máscara da rede) e o papel
da netmask é determinar quais endereços pertencem ou não a rede. Por exemplo, considere o
seguinte:
----------------- ---------------
Endereço do Host 192.168.110.23
Máscara da Rede 255.255.255.0
Porção da Rede 192.168.110.
Porção do Host .23
----------------- ---------------
Endereço da Rede 192.168.110.0
Endereço Broadcast 192.168.110.255
----------------- ---------------
Qualquer endereço que é finalizado em zero em sua netmask, revelará o endereço da rede que
pertence. O endereço e rede é então sempre o menor endereço numérico dentro da escalas de
endereços da rede e sempre possui a porção host dos endereços codificada como zeros.
Capítulo 4. Rede 43
O endereço de broadcast é um endereço especial que cada computador em uma rede “escuta”
em adição a seu próprio endereço. Este é um endereço onde os datagramas enviados são
recebidos por todos os computadores da rede. Certos tipos de dados como informações de
roteamento e mensagens de alerta são transmitidos para o endereço broadcast, assim todo com-
putador na rede pode recebe-las simultaneamente.
Existe dois padrões normalmente usados para especificar o endereço de broadcast. O mais am-
plamente aceito é para usar o endereço mais alto da rede como endereço broadcast. No
exemplo acima este seria 192.168.110.255. Por algumas razões outros sites tem adotado a con-
venção de usar o endereço de rede como o endereço broadcast. Na prática não importa
muito se usar este endereço, mas você deve ter certeza que todo computador na rede esteja
configurado para escutar o mesmo endereço broadcast.
Por razões administrativas após algum pouco tempo no desenvolvimento do protocolo IP al-
guns grupos arbitrários de endereços foram formados em redes e estas redes foram agrupadas
no que foram chamadas de classes. Estas classes armazenam um tamanho padrão de redes que
podem ser usadas. As faixas alocadas são:
+--------------------------------------------------------+
| Classe | Máscara de | Endereço da Rede |
| | Rede | |
+--------------------------------------------------------+
| A | 255.0.0.0 | 0.0.0.0 - 127.255.255.255 |
| B | 255.255.0.0 | 128.0.0.0 - 191.255.255.255 |
| C | 255.255.255.0 | 192.0.0.0 - 223.255.255.255 |
|Multicast| 240.0.0.0 | 224.0.0.0 - 239.255.255.255 |
+--------------------------------------------------------+
O tipo de endereço que você deve utilizar depende exatamente do que estiver fazendo.
A tabela abaixo faz referência as máscaras de rede mais comuns e a quantidade de máquinas
máximas que ela atinge. Note que a especificação da máscara tem influência direta na classe
de rede usada:
Classe A:
/8 /255.0.0.0 16,777,215
Capítulo 4. Rede 44
Classe B:
/16 /255.255.0.0 65,535
/17 /255.255.128.0 32,767
/18 /255.255.192.0 16,383
/19 /255.255.224.0 8,191
/20 /255.255.240.0 4,095
/21 /255.255.248.0 2,047
/22 /255.255.252.0 1,023
/23 /255.255.254.0 511
Classe C
/24 /255.255.255.0 255
/25 /255.255.255.128 127
/26 /255.255.255.192 63
/27 /255.255.255.224 31
/28 /255.255.255.240 15
/29 /255.255.255.248 7
/30 /255.255.255.252 3
/32 /255.255.255.255 1
Qualquer outra máscara fora desta tabela (principalmente para a classe A), deverá ser redimen-
sionada com uma calculadora de IP para chegar a um número aproximado de redes/máquinas
aproximados que deseja.
4.3.3 Para instalar uma máquina usando o Linux em uma rede existente
Se você quiser instalar uma máquina GNU/Linux em uma rede TCP/IP existente então você
deve contactar qualquer um dos administradores da sua rede e perguntar o seguinte:
• Endereço IP de sua máquina
• Endereço IP da rede
• Endereço IP de broadcast
• Máscara da Rede IP
• Endereço do Roteador
• Endereço do Servidor de Nomes (DNS)
Você deve então configurar seu dispositivo de rede GNU/Linux com estes detalhes. Você não
pode simplesmente escolhe-los e esperar que sua configuração funcione.
Se você estiver construindo uma rede privada que nunca será conectada a Internet, então você
pode escolher qualquer endereço que quiser. No entanto, para sua segurança e padronização,
existem alguns endereços IP’s que foram reservados especificamente para este propósito. Eles
estão especificados no RFC1597 e são os seguintes:
Capítulo 4. Rede 45
+---------------------------------------------------------+
| ENDEREÇOS RESERVADOS PARA REDES PRIVADAS |
+---------------------------------------------------------+
| Classe | Máscara de | Endereço da Rede |
| de Rede | Rede | |
+---------+---------------+-------------------------------+
| A | 255.0.0.0 | 10.0.0.0 - 10.255.255.255 |
| B | 255.255.0.0 | 172.16.0.0 - 172.31.255.255 |
| C | 255.255.255.0 | 192.168.0.0 - 192.168.255.255 |
+---------------------------------------------------------+
Você deve decidir primeiro qual será a largura de sua rede e então escolher a classe de rede
que será usada.
A interface loopback é um tipo especial de interface que permite fazer conexões com você
mesmo. Todos os computadores que usam o protocolo TCP/IP utilizam esta interface e ex-
istem várias razões porque precisa fazer isto, por exemplo, você pode testar vários programas
de rede sem interferir com ninguém em sua rede. Por convenção, o endereço IP 127.0.0.1 foi
Capítulo 4. Rede 46
escolhido especificamente para a loopback, assim se abrir uma conexão telnet para 127.0.0.1,
abrirá uma conexão para o próprio computador local.
A configuração da interface loopback é simples e você deve ter certeza que fez isto (mas note
que esta tarefa é normalmente feita pelos scripts padrões de inicialização existentes em sua
distribuição).
ifconfig lo 127.0.0.1
Caso a interface loopback não esteja configurada, você poderá ter problemas quando tentar
qualquer tipo de conexão com as interfaces locais, tendo problemas até mesmo com o comando
ping.
Após configurada fisicamente, a interface precisa receber um endereço IP para ser identificada
na rede e se comunicar com outros computadores, além de outros parâmetros como o endereço
de broadcast e a máscara de rede. O comando usado para fazer isso é o ifconfig (interface
configure).
Para configurar a interface de rede Ethernet (eth0) com o endereço 192.168.1.1, máscara de
rede 255.255.255.0, podemos usar o comando:
O comando acima ativa a interface de rede. A palavra up pode ser omitida, pois a ativação
da interface de rede é o padrão. Para desativar a mesma interface de rede, basta usar usar o
comando:
Digitando ifconfig são mostradas todas as interfaces ativas no momento, pacotes enviados,
recebidos e colisões de datagramas. Para mostrar a configuração somente da interface eth0,
use o comando: ifconfig eth0 Em sistemas Debian, o arquivo correto para especificar os
dados das interfaces é o /etc/network/interfaces .
Para mais detalhes, veja a página de manual do ifconfig ou o NET3-4-HOWTO.
4.5 Roteamento
Roteamento é quando uma máquina com múltiplas conexões de rede decide onde entregar os
pacotes IP que recebeu, para que cheguem ao seu destino.
Capítulo 4. Rede 47
Pode ser útil ilustrar isto com um exemplo. Imagine um simples roteador de escritório, ele
pode ter um link intermitente com a Internet, um número de segmentos ethernet alimen-
tando as estações de trabalho e outro link PPP intermitente fora de outro escritório. Quando
o roteador recebe um datagrama de qualquer de suas conexões de rede, o mecanismo que usa
determina qual a próxima interface deve enviar o datagrama. Computadores simples também
precisam rotear, todos os computadores na Internet tem dois dispositivos de rede, um é a in-
terface loopback (explicada acima) o outro é um usado para falar com o resto da rede, talvez
uma ethernet, talvez uma interface serial PPP ou SLIP.
OK, viu como o roteamento funciona? cada computador mantém uma lista de regras especiais
de roteamento, chamada tabela de roteamento. Esta tabela contém colunas que tipicamente con-
tém no mínimo três campos, o primeiro é o endereço de destino, o segundo é o nome da interface
que o datagrama deve ser roteado e o terceiro é opcionalmente o endereço IP da outra máquina
que levará o datagrama em seu próximo passo através da rede. No GNU/Linux você pode ver
a tabela de roteamento usando um dos seguintes comandos:
cat /proc/net/route
route -n
netstat -r
A configuração da rota é feita através da ferramenta route. Para adicionar uma rota para a
rede 192.168.1.0 acessível através da interface eth0 basta digitar o comando:
Para apagar a rota acima da tabela de roteamento, basta substituir a palavra add por del. A
palavra net quer dizer que 192.168.1.0 é um endereço de rede (lembra-se das explicações em
‘Endereço IP’ on page 42?)) para especificar uma máquina de destino, basta usar a palavra
-host. Endereços de máquina de destino são muito usadas em conexões de rede apenas entre
dois pontos (como ppp, plip, slip). Por padrão, a interface é especificada como último argu-
mento. Caso a interface precise especifica-la em outro lugar, ela deverá ser precedida da opção
-dev.
Para adicionar uma rota padrão para um endereço que não se encontre na tabela de rotea-
mento, utiliza-se o gateway padrão da rede. Através do gateway padrão é possível especificar um
Capítulo 4. Rede 48
computador (normalmente outro gateway) que os pacotes de rede serão enviados caso o en-
dereço não confira com os da tabela de roteamento. Para especificar o computador 192.168.1.1
como gateway padrão usamos:
O gateway padrão pode ser visualizado através do comando route -n e verificando o campo
gateway. A opção gw acima, especifica que o próximo argumento é um endereço IP (de uma
rede já acessível através das tabelas de roteamento).
O computador gateway está conectado a duas ou mais redes ao mesmo tempo. Quando seus
dados precisam ser enviados para computadores fora da rede, eles são enviados através do
computador gateway e o gateway os encaminham ao endereço de destino. Desta forma, a re-
sposta do servidor também é enviada através do gateway para seu computador (é o caso de
uma típica conexão com a Internet).
A nossa configuração ficaria assim:
DNS significa Domain Name System (sistema de nomes de domínio). O DNS converte os
nomes de máquinas para endereços IPs que todas as máquinas da Internet possuem. Ele faz
o mapeamento do nome para o endereço e do endereço para o nome e algumas outras coisas.
Um mapeamento é simplesmente uma associação entre duas coisas, neste caso um nome de
computador, como www.cipsga.org.br, e o endereço IP desta máquina (ou endereços) como
200.245.157.9.
O DNS foi criado com o objetivo de tornar as coisas mais fáceis para o usuário, permitindo
assim, a identificação de computadores na Internet ou redes locais através de nomes (é como
se tivéssemos apenas que decorar o nome da pessoa ao invés de um número de telefone).
A parte responsável por traduzir os nomes como www.nome.com.br em um endereço IP é
chamada de resolvedor de nomes.
O resolvedor de nomes pode ser um banco de dados local (controlador por um arquivo ou pro-
grama) que converte automaticamente os nomes em endereços IP ou através de servidores DNS
que fazem a busca em um banco de dados na Internet e retornam o endereço IP do computador
desejado. Um servidor DNS mais difundido na Internet é o bind.
Através do DNS é necessário apenas decorar o endereço sem precisar se preocupar com o
endereço IP (alguns usuários simplesmente não sabem que isto existe. . . ). Se desejar mais
detalhes sobre DNS, veja o documento DNS-HOWTO.
Capítulo 4. Rede 49
Você deve estar acostumado com o uso dos nomes de computadores na Internet, mas pode
não entender como eles são organizados. Os nomes de domínio na Internet são uma estrutura
hierárquica, ou seja, eles tem uma estrutura semelhante aos diretórios de seu sistema.
Um domínio é uma família ou grupo de nomes. Um domínio pode ser colocado em um sub-
domínio. Um domínio principal é um domínio que não é um sub-domínio. Os domínios princi-
pais são especificados na RFC-920. Alguns exemplos de domínios principais comuns são:
• COM - Organizações Comerciais
• EDU - Organizações Educacionais
• GOV - Organizações Governamentais
• MIL - Organizações Militares
• ORG - Outras Organizações
• NET - Organizações relacionadas com a Internet
• Identificador do País - São duas letras que representam um país em particular.
Cada um dos domínios principais tem sub-domínios. Os domínios principais baseados no
nome do país são freqüentemente divididos em sub-domínios baseado nos domínios .com,
.edu, .gov, .mil e .org. Assim, por exemplo, você pode finaliza-lo com: com.au e gov.au
para organizações comerciais e governamentais na Austrália; note que isto não é uma re-
gra geral, as organizações de domínio atuais dependem da autoridade na escolha de nomes
de cada domínio. Quando o endereço não especifica o domínio principal, como o endereço
www.unicamp.br, isto quer dizer que é uma organização acadêmica.
O próximo nível da divisão representa o nome da organização. Subdomínios futuros variam
em natureza, freqüentemente o próximo nível do sub-domínio é baseado na estrutura depar-
tamental da organização mas ela pode ser baseada em qualquer critério considerado razoável
e significantes pelos administradores de rede para a organização.
A porção mais a esquerda do nome é sempre o nome único da máquina chamado hostname,
a porção do nome a direita do hostname é chamado nome de domínio e o nome completo é
chamado nome do domínio completamente qualificado (Fully Qualified Domain Name).
Usando o computador www.debian.org.br como exemplo:
• br - País onde o computador se encontra
• org - Domínio principal
• debian - Nome de Domínio
• www - Nome do computador
A localização do computador www.debian.org.br através de servidores DNS na Inter-
net obedece exatamente a seqüência de procura acima. Os administradores do domínio
debian.org.br podem cadastrar quantos sub-domínios e computadores quiserem (como
www.non-us.debian.org.br ou cvs.debian.org.br).
/etc/resolv.conf
domain maths.wu.edu.au
search maths.wu.edu.au wu.edu.au
nameserver 192.168.10.1
nameserver 192.168.12.1
Este exemplo especifica que o nome de domínio a adicionar ao nome não qualificado (i.e.
hostnames sem o domínio) é maths.wu.edu.au e que se o computador não for encontrado
naquele domínio então a procura segue para o domínio wu.edu.au diretamente. Duas linhas
de nomes de servidores foram especificadas, cada uma pode ser chamada pelo código resolve-
dor de nomes para resolver o nome.
/etc/host.conf
O arquivo /etc/host.conf é o local onde é possível configurar alguns ítens que gerenciam
o código do resolvedor de nomes. O formato deste arquivo é descrito em detalhes na página
de manual resolv+. Em quase todas as situações, o exemplo seguinte funcionará:
order hosts,bind
multi on
Este arquivo de configuração diz ao resolvedor de nomes para checar o arquivo /etc/hosts
(parâmetro hosts) antes de tentar verificar um servidor de nomes (parâmetro bind) e retornar
um endereço IP válido para o computador procurado e multi on retornará todos os endereços
IP resolvidos no arquivo /etc/hosts ao invés do primeiro.
Os seguintes parâmetros podem ser adicionados para evitar ataques de IP spoofing:
nospoof on
spoofalert on
O parâmetro nospoof on ativa a resolução reversa do nome da biblioteca resolv (para checar se
o endereço pertence realmente àquele nome) e o spoofalert on registra falhas desta operação no
syslog.
Capítulo 4. Rede 51
/etc/hosts
# /etc/hosts
127.0.0.1 localhost loopback
192.168.0.1 maquina.dominio.com.br
Você pode especificar mais que um nome de computador por linha como demonstrada pela
primeira linha, a que identifica a interface loopback. Certifique-se de que a entrada do nome
de domínio neste arquivo aponta para a interface de rede e não para a interface loopback, ou
terá problema com o comportamento de alguns serviços.
OBS: Caso encontre problemas de lentidão para resolver nomes e até para executar os aplica-
tivos (como o mc, etc), verifique se existem erros neste arquivo de configuração.
Estes sintomas se confundem com erros de memória ou outro erro qualquer de configuração
de hardware, e somem quando a interface de rede é desativada (a com o IP não loopback). Isto
é causados somente pela má configuração do arquivo /etc/hosts. O bom funcionamento
do Unix depende da boa atenção do administrador de sistemas para configurar os detalhes de
seu servidor.
/etc/networks
O arquivo /etc/networks tem uma função similar ao arquivo /etc/hosts. Ele contém um
banco de dados simples de nomes de redes contra endereços de redes. Seu formato se difere
por dois campos por linha e seus campos são identificados como:
Nome_da_Rede Endereço_da_Rede
loopnet 127.0.0.0
localnet 192.168.1.0
amprnet 44.0.0.0
Quando usar comandos como route, se um destino é uma rede e esta rede se encontra no
arquivo /etc/networks, então o comando route mostrará o nome da rede ao invés de seu
endereço.
Capítulo 4. Rede 52
Se você planeja executar um servidor de nomes, você pode fazer isto facilmente. Por favor veja
o documento DNS-HOWTO e quaisquer documentos incluídos em sua versão do BIND (Berkeley
Internet Name Domain).
Serviços de rede é o que está disponível para ser acessado pelo usuário. No TCP/IP, cada serviço
é associado a um número chamado porta que é onde o servidor espera pelas conexões dos
computadores clientes. Uma porta de rede pode se referenciada tanto pelo número como pelo
nome do serviço.
Abaixo, alguns exemplos de portas padrões usadas em serviços TCP/IP:
• 21 - FTP (transferência de arquivos)
• 23 - Telnet (terminal virtual remoto)
• 25 - Smtp (envio de e-mails)
• 53 - DNS (resolvedor de nomes)
• 79 - Finger (detalhes sobre usuários do sistema)
• 80 - http (protocolo www - transferência de páginas Internet)
• 110 - Pop-3 (recebimento de mensagens)
• 119 - NNTP (usado por programas de noticias)
O arquivo padrão responsável pelo mapeamento do nome dos serviços e das portas mais uti-
lizadas é o /etc/services (para detalhes sobre o seu formato, veja a ‘/etc/services’ on
page 61).
Serviços de rede iniciados como daemons ficam residente o tempo todo na memória esperando
que alguém se conecte (também chamado de modo standalone). Um exemplo de daemon é o
servidor proxy squid e o servidor web Apache operando no modo daemon.
Alguns programas servidores oferecem a opção de serem executados como daemons ou através
do inetd. É recomendável escolher daemon se o serviço for solicitado freqüentemente (como é o
caso dos servidores web ou proxy).
Para verificar se um programa está rodando como daemon, basta digitar ps ax e procurar o
nome do programa, em caso positivo ele é um daemon.
Normalmente os programas que são iniciados como daemons possuem seus próprios recursos
de segurança/autenticação para decidir quem tem ou não permissão de se conectar.
Serviços iniciados pelo inetd são carregados para a memória somente quando são solicitados.
O controle de quais serviços podem ser carregados e seus parâmetros, são feitos através do
Capítulo 4. Rede 53
arquivo /etc/inetd.conf.
Um daemon chamado inetd lê as configurações deste arquivo e permanece residente na
memória, esperando pela conexão dos clientes. Quando uma conexão é solicitada, o
daemon inetd verifica as permissões de acesso nos arquivos /etc/hosts.allow e /etc
/hosts.deny e carrega o programa servidor correspondente no arquivo /etc/inetd.conf.
Um arquivo também importante neste processo é o /etc/services que faz o mapeamento
das portas e nomes dos serviços.
Alguns programas servidores oferecem a opção de serem executados como daemons ou através
do inetd. É recomendável escolher inetd se o serviço não for solicitado freqüentemente (como é
o caso de servidores ftp, telnet, talk, etc).
/etc/inetd.conf
automaticamente desativado pelo inetd e uma mensagem será mostrada no log do sis-
tema avisando sobre o fato. Para reativar o serviço interrompido, reinicie o inetd com:
killall -HUP inetd. O valor padrão é 40.
usuário Este campo descreve que conta de usuário usuário no arquivo /etc/passwd será
escolhida como dono do daemon de rede quando este for iniciado. Isto é muito útil se
você deseja diminuir os riscos de segurança. Você pode ajustar o usuário de qualquer
item para o usuário nobody, assim se a segurança do servidor de redes é quebrada, a
possibilidade de problemas é minimizada. Normalmente este campo é ajustado para
root, porque muitos servidores requerem privilégios de usuário root para funcionarem
corretamente.
caminho_servidor Este campo é o caminho para o programa servidor atual que será execu-
tado.
argumentos_servidor Este campo inclui o resto da linha e é opcional. Você pode colocar neste
campo qualquer argumento da linha de comando que deseje passar para o daemon servi-
dor quando for iniciado.
Uma dica que pode aumentar significativamente a segurança de seu sistema é comentar (colo-
car uma #no inicio da linha) os serviços que não serão utilizados.
Abaixo um modelo de arquivo /etc/inetd.conf usado em sistemas Debian:
Deixe-me iniciar esta seção lhe alertando que a segurança da rede em sua máquina e ataques
maliciosos são uma arte complexa. Uma regra importante é: “Não ofereça serviços de rede que
não deseja utilizar”.
Muitas distribuições vem configuradas com vários tipos de serviços que são iniciados auto-
maticamente. Para melhorar, mesmo que insignificantemente, o nível de segurança em seu
sistema você deve editar se arquivo /etc/inetd.conf e comentar (colocar uma “#”) as lin-
has que contém serviços que não utiliza.
Bons candidatos são serviços tais como: shell, login, exec, uucp, ftp e serviços de infor-
mação tais como finger, netstat e sysstat.
Existem todos os tipos de mecanismos de segurança e controle de acesso, eu descreverei os
mais importantes deles.
4.8.1 /etc/ftpusers
4.8.2 /etc/securetty
O arquivo /etc/securetty lhe permite especificar que dispositivos tty que o usuário root
pode se conectar. O arquivo /etc/securetty é lido pelo programa login (normalmente /bin
/login). Seu formato é uma lista de dispositivos tty onde a conexão é permitida, em todos
os outros, a entrada do usuário root é bloqueada.
O programa tcpd que você deve ter visto listado no mesmo arquivo /etc/inetd.conf,
oferece mecanismos de registro e controle de acesso para os serviços que esta configurado
para proteger. Ele é um tipo de firewall simples e fácil de configurar que pode evitar tipos
indesejados de ataques e registrar possíveis tentativas de invasão.
Quando é executado pelo programa inetd, ele lê dos arquivos contendo regras de acesso e
permite ou bloqueia o acesso ao servidor protegendo adequadamente.
Ele procura nos arquivos de regras até que uma regra confira. Se nenhuma regra conferir, então
ele assume que o acesso deve ser permitido a qualquer um. Os arquivos que ele procura em
seqüência são: /etc/hosts.allow e /etc/hosts.deny. Eu descreverei cada um destes
arquivos separadamente.
Para uma descrição completa desta facilidade, você deve verificar a página de manual apro-
priada (hosts_access (5) é um bom ponto de partida).
/etc/hosts.allow
# /etc/hosts.allow
#
# lista de serviços: lista de hosts : comando
lista de serviços É uma lista de nomes de serviços separados por vírgula que esta regra se
aplica. Exemplos de nomes de serviços são: ftpd, telnetd e fingerd.
lista de hosts É uma lista de nomes de hosts separada por vírgula. Você também pode usar
endereços IP’s aqui. Adicionalmente, você pode especificar nomes de computadores
ou endereço IP usando caracteres coringas para atingir grupos de hosts. Exemplos
incluem: gw.vk2ktj.ampr.org para conferir com um endereço de computador es-
pecífico, .uts.edu.au para atingir qualquer endereço de computador finalizando com
aquele string. Use 200.200.200. para conferir com qualquer endereço IP iniciando com
estes dígitos. Existem alguns parâmetros especiais para simplificar a configuração, al-
guns destes são: ALL atinge todos endereços, LOCAL atinge qualquer computador que
não contém um “.” (ie. está no mesmo domínio de sua máquina) e PARANOID atinge
qualquer computador que o nome não confere com seu endereço (falsificação de nome).
Existe também um último parâmetro que é também útil: o parâmetro EXCEPT lhe per-
mite fazer uma lista de exceções. Isto será coberto em um exemplo adiante.
comando É um parâmetro opcional. Este parâmetro é o caminho completo de um comando
que deverá ser executado toda a vez que esta regra conferir. Ele pode executar um co-
mando para tentar identificar quem esta conectado pelo host remoto, ou gerar uma men-
sagem via E-Mail ou algum outro alerta para um administrador de rede que alguém está
tentando se conectar. Existem um número de expansões que podem ser incluídas, alguns
exemplos comuns são: %h expande o endereço do computador que está conectado ou
endereço se ele não possuir um nome, %d o nome do daemon sendo chamado.
Se o computador tiver permissão de acessar um serviço através do /etc/hosts.allow, então
o /etc/hosts.deny não será consultado e o acesso será permitido.
Como exemplo:
# /etc/hosts.allow
#
# Permite que qualquer um envie e-mails
in.smtpd: ALL
# Permitir telnet e ftp somente para hosts locais e myhost.athome.org.au
in.telnetd, in.ftpd: LOCAL, myhost.athome.org.au
# Permitir finger para qualquer um mas manter um registro de quem é
in.fingerd: ALL: (finger @%h | mail -s "finger from %h" root)
/etc/hosts.deny
# /etc/hosts.deny
#
# Bloqueia o acesso de computadores com endereços suspeitos
ALL: PARANOID
#
# Bloqueia todos os computadores
ALL: ALL
A entrada PARANOID é realmente redundante porque a outra entrada nega tudo. Qualquer
uma destas linhas pode fazer uma segurança padrão dependendo de seu requerimento em
particular.
Tendo um padrão ALL: ALL no arquivo /etc/hosts.deny e então ativando especificamente os
serviços e permitindo computadores que você deseja no arquivo /etc/hosts.allow é a con-
figuração mais segura.
Qualquer modificação no arquivo /etc/hosts.deny entrará em ação após reiniciar o dae-
mon inetd. Isto pode ser feito com o comando kill -HUP [pid do inetd], o pid do inetd
pode ser obtido com o comando ps ax|grep inetd.
/etc/hosts.equiv e /etc/shosts.equiv
O primeiro campo especifica se o acesso será permitido ou negado caso o segundo e terceiro
campo confiram. Por razões de segurança deve ser especificado o FQDN no caso de nomes de
máquinas. Grupos de rede podem ser especificados usando a sintaxe “+@grupo”.
Para aumentar a segurança, não use este mecanismo e encoraje seus usuários a também não
usar o arquivo .rhosts.
ATENÇÃO O uso do sinal “+” sozinho significa permitir acesso livre a qualquer pessoa de
qualquer lugar. Se este mecanismo for mesmo necessário, tenha muita atenção na especificação
de seus campos.
Capítulo 4. Rede 59
Evita também A TODO CUSTO uso de nomes de usuários (a não ser para negar o acesso),
pois é fácil forjar o login, entrar no sistema tomar conta de processos (como por exemplo do
servidor Apache rodando sob o usuário www-data ou até mesmo o root), causando enormes
estragos.
ALL: 127.0.0.1
in.talkd, in.ntalkd: ALL
in.fingerd: 192.168.1. EXCEPT 192.168.1.30
ALL: ALL
Vamos aos testes, digitando: “tcpdmatch in.fingerd 127.0.0.1” (verificar se o endereço 127.0.0.1
tem acesso ao finger):
Ok, temos acesso garantido com especificado pela linha 1 do hosts.allow (a primeira linha
que confere é usada). Agora “tcpdmatch in.fingerd 192.168.1.29”:
Capítulo 4. Rede 60
Ok, na linha 2 qualquer computador pode te chamar para conversar via talk na rede, mas
para o endereço DNS conferir com um IP especificado, o GNU/Linux faz a resolução DNS,
convertendo o endereço para IP e verificando se ele possui acesso.
No lugar do endereço também pode ser usado a forma daemon@computador ou
cliente@computador para verificar respectivamente o acesso de daemons e cliente de de-
terminados computadores aos serviços da rede.
Como pode ver o TCPD ajuda a aumentar a segurança do seu sistema, mas não confie nele
além do uso em um sistema simples, é necessário o uso de um firewall verdadeiro para contro-
lar minuciosamente a segurança do seu sistema e dos pacotes que atravessam os protocolos,
roteamento e as interfaces de rede. Se este for o caso aprenda a trabalhar a fundo com firewalls
e implemente a segurança da sua rede da forma que melhor planejar.
4.8.4 Firewall
geral do Administrador de redes, a segurança de sua rede e seus dados dependem da escolha
do profissional correto, que entenda a fundo o TCP/IP, roteamento, protocolos, serviços e out-
ros assuntos ligados a rede.
Freqüentemente tem se ouvido falar de empresas que tiveram seus sistemas invadidos, em
parte isto é devido a escolha do sistema operacional indevido mas na maioria das vezes o
motivo é a falta de investimento da empresa em políticas de segurança, que algumas simples-
mente consideram a segurança de seus dados e sigilo interno como uma despesa a mais.
Um bom firewall que recomendo é o ipchains, Sinus e o TIS. Particularmente gosto muito
de usar o ipchains e o Sinus e é possível fazer coisas inimagináveis programando scripts
para interagirem com estes programas. . .
4.9.1 /etc/services
name Uma palavra simples que representa o nome do serviço sendo descrito.
porta/protocolo Este campo é dividido em dois sub-campos.
• porta - Um número que especifica o número da porta em que o serviço estará
disponível. Muitos dos serviços comuns tem designados um número de serviço.
Estes estão descritos no RFC-1340.
• protocolo - Este sub-campo pode ser ajustado para tcp ou udp. É importante notar
que o item 18/tcp é muito diferente do item 18/udp e que não existe razão técnica
porque o mesmo serviço precisa existir em ambos. Normalmente o senso comum
prevalece e que somente se um serviço esta disponível em ambos os protocolos tcp
e udp, você precisará especificar ambos.
apelidos Outros nomes podem ser usados para se referir a entrada deste serviço.
comentário Qualquer texto aparecendo em uma linha após um caracter “#” é ignorado e
tratado como comentário.
4.9.2 /etc/protocols
como tcpdump permitindo-os mostrar nomes ao invés de números em sua saída. A sintaxe geral
deste arquivo é:
São organizações do protocolo TCP/IP que visam organizar e simplificar seu padrão e imple-
mentação pelos desenvolvedores.
• Um padrão TCP é o conjunto de regras que devem ser seguidas para garantir a homo-
geneidade da comunicação entre diversos sistemas de diversos fabricantes (por exemplo,
Mac com Windows, Windows com Linux, etc.).
• A implementação é o código escrito por cada desenvolvedor para integração ao sistema op-
eracional seguindo as regras do padrão para garantir a comunicação entre as máquinas,
portanto, a implementação do protocolo TCP varia de fabricante para fabricante.
Existem dois tipos de padrões TCP: Darpa e OSI. O padrão Darpa é dividido em 4 camadas e
ainda é o padrão atualmente utilizado. O padrão OSI é mais recente, dividido em 7 camadas,
mas ainda não se tornou um padrão como o Darpa.
Segue abaixo os padrões e a descrição de cada uma das camadas:
Darpa • Aplicação - www, ftp, dns, etc. Fazem interface com as aplicações do sistema.
• Transporte - Protocolo tcp e udp. Cuidam da parte de transporte dos dados do
sistema.
• Rede - IP, icmp, igmp, arp. Cuida de levar o pacote para seu destino (rotas) e
condições de transmissão.
• Interface de Rede - Ethernet, FDDI, Token Ring. Define qual o método que a
mensagem transmitida será encapsulada para envio ao seu destino.
Apesar dos padrões Darpa e OSI, o protocolo TCP/IP é oficialmente independente destas ca-
madas.
Como referência de pesquisa, segue abaixo a listagem de números de RFCs para protocolos de
rede mais utilizados:
IP http://www.rfc-editor.org/rfc/rfc791.txt
ICMP http://www.rfc-editor.org/rfc/rfc792.txt
TCP http://www.rfc-editor.org/rfc/rfc793.txt
UDP http://www.rfc-editor.org/rfc/rfc768.txt
63
Capítulo 5
Este capítulo descreve alguns tipos de configurações que podem ser feitas em rede utilizando
os recursos disponíveis do Linux. Aqui não estão todas as aplicações, pois o sistema é bastante
flexível e o próprio time de desenvolvimento do kernel não demonstrou limitações quanto as
formas de se construir uma rede :-)
5.1 IP Alias
Este recurso permite configurar uma interface de rede para responder por um ou mais IPs,
que não precisam pertencer a mesma faixa. Para usuários externos, a impressão é que a rede
tem “muitas” máquinas, quando na realidade apenas uma responde por todos estes endereços
virtuais. Podemos citar algumas utilizações úteis deste recurso:
• Simular uma rede com diversas máquinas
• Construir virtual hosts baseados em IP
• Definir endereçamentos secundários para fins de análise e depuração de pacotes (princi-
palmente como armadilhas para trojans)
• Colocação de serviços com operação restritas a interfaces em funcionamento através de
faixas específicas usando as configurações da interface virtual
• Transição de IP de servidores de forma transparente
• Entre muitas outras. A idéia aqui é mostrar a simplicidade de se configurar este recurso
e entender o processo, que é bastante simples.
Para configurar o recurso de IP Alias é necessário apenas que a opção IP Aliasing Support seja
habilitada no kernel (como módulo ou embutida). Em nosso exemplo abaixo, temos uma rede
com a interface eth0 configurada com o IP 192.168.1.1 (classe C privada) e queremos adi-
cionar uma interface virtual que atenda pelo IP 172.16.0.1 (classe B privada) e depois seguir os
seguintes passos:
1 Ative a interface de rede com ifconfig ou ifup (caso esteja usando a Debian).
2 Crie uma interface virtual usando o comando ifconfig eth0:0 172.16.0.1. Isto
criará uma nova interface chamada eth0:0 que passará a responder pelo IP 172.6.0.1.
É permitido o uso de nomes para especificar a interface virtual, como: eth0:rede1,
eth0:rede2, eth0:escritório.
Capítulo 5. Configurações especiais de Rede 64
3 Digite ifconfig para ver as configurações de sua nova interface de rede. Use o ping
também para vê-la: ping 172.16.0.1.
eth0 Encapsulamento do Link: Ethernet Endereço de HW 00:80:AE:B3
inet end.: 192.168.1.1 Bcast:192.168.1.255 Masc:255.255.255
UP BROADCASTRUNNING MULTICAST MTU:1500 Métrica:1
RX packets:979 errors:0 dropped:0 overruns:0 frame:0
TX packets:1228 errors:0 dropped:0 overruns:0 carrier:0
colisões:1 txqueuelen:100
RX bytes:71516 (69.8 Kb) TX bytes:1146031 (1.0 Mb)
IRQ:10 Endereço de E/S:0x300
auto eth0
iface eth0 inet static
address 192.168.1.1
netmask 255.255.255.0
network 192.168.1.0
broadcast 192.168.1.255
auto eth0:0
iface eth0:0 inet static
address 172.16.0.1
netmask 255.255.0.0
network 172.16.0.1
broadcast 172.16.255.255
OBS1: Quando você desativa uma interface física (eth0), todas as interfaces virtuais também
são desativadas.
OBS2: Caso utilize um firewall (principalmente com a política padrão permissiva), esteja
atento as modificações que precisa realizar para não comprometer a segurança de sua máquina.
Capítulo 5. Configurações especiais de Rede 65
Caso tenha dados considerados seguros em sua máquina e esteja em dúvida sobre as impli-
cações de segurança do IP Alias em sua máquina, consulte seu administrador de redes.
OBS3: Note que somente os 4 primeiros caracteres serão mostrados na saída do ifconfig,
desta forma procure utilizar no máximo esta quantidade de caracteres para evitar problemas
durante uma futura administração do servidor, no caso de esquecimento do nome completo
da interface virtual).
5.2 Bridge
Uma bridge é uma interface de rede lógica composta por uma ou mais interfaces de rede física
operando em nível 2 (enviando pacotes através de MAC adresses, veja ‘Camadas de Rede’ on
page 62).
Sua operação é transparente na rede, podendo ser usada como um switch/firewall, estação
de monitoração, etc. Aqui descreverei como montar uma bridge simples e uma aplicação de
firewall simples. As possibilidades são diversas e uma configuração bem feita pode detectar
ataques, protocolos desconhecidos até vírus complexos de rede.
Nos exemplos abaixo, eu assumirei a utilização do nome de dispositivo br0 para se referir a
bridge no sistema. Siga estes passos para configurar uma bridge em sistemas Debian:
Capítulo 5. Configurações especiais de Rede 66
A bridge permite ainda definir prioridade para utilização de interfaces, além de outras fun-
cionalidades que lhe permitem ajustar a performance da máquina de acordo com sua rede.
Um bom exemplo, é quando você deseja criar 2 bridges em uma mesma máquina envolvendo
interfaces de rede específicas, uma atendendo a rede 192.168.0.x e outra a rede 192.168.1.x:
auto br0
iface br0 inet static
address 192.168.0.2
network 192.168.0.0
netmask 255.255.255.0
broadcast 192.168.0.255
gateway 192.168.0.1
bridge_ports eth0 eth1
auto br1
iface br1 inet static
address 192.168.1.2
network 192.168.1.0
Capítulo 5. Configurações especiais de Rede 67
netmask 255.255.255.0
broadcast 192.168.1.255
gateway 192.168.0.1
bridge_ports eth2 eth3 eth4
No exemplo acima, as interfaces eth0 e eth1 fazem parte da bridge br0 e as demais (eth2,
eth3 e eth4 da bridge br1.
O comando acima ativa uma bridge simples, como o primeiro exemplo. Tenha certeza que as
interfaces físicas de rede estão desativadas antes de executar este comando.
Outros parâmetros que podem ser usados com o brctl:
setbridgeprio [bridge [prioridade]] Define a prioridade da bridge, o valor deve estar entre 0
e 65536 (16 bits). Valores menores definem uma prioridade maior.
setfd [bridge [tempo]] Ajusta o delay da bridge especificada em [tempo] segundos.
setmaxage [bridge [tempo]] Ajusta o tempo máximo de vida da bridge para [tempo] segun-
dos.
setportprio [bridge [interface] [prioridade]] Ajusta a prioridade da [interface] especificada na
[bridge]. O valor de prioridade deve estar entre 0 e 255 (8 bits). Quanto menor o valor
maior a prioridade. Isto é útil para otimizações o volume de tráfego em máquinas que
possuem diversas interfaces configuradas fazendo parte da bridge.
A construção de um firewall em uma bridge não tem maiores segredos, basta referir-se a inter-
face lógica da bridge para construir suas regras (tendo em mente como uma bridge funciona e
como os pacotes atravessarão as interfaces).
Caso aplique o patch bridge nf, será possível referir-se as interfaces locais de rede e também a da
bridge. Neste caso a interface da bridge será identificada como interface IN ou OUT PHYSIN
e as interfaces físicas como PHYSOUT:
Mesmo que a bridge não necessite de ip_forward ativado para redirecionar os pacotes através
das interfaces, isto será necessário para habilitar o uso do firewall para controlar o tráfego que
atravessa as interfaces.
O Linux é bastante poderoso quando se trata de métodos para se conectar duas ou mais
máquinas em rede. Uma brincadeira que é levada a sério é que qualquer coisa que ligue uma
máquina a outra possui um controlador desenvolvido por alguém para fazer uma rede :)
Usando o plip (Parallel Line Internet Protocol) permite criar uma interface de rede para a
porta paralela que utiliza todos os recursos de uma rede normal. Esta interface será identifi-
cada por plip?, onde ? é o número da porta paralela, recém configurada.
A rede via porta paralela pode atingir até 1Mb/s e mesmo esta velocidade parecer aparente-
mente baixa apresenta diversas vantagens por sua escalabilidade e pode lhe salvar em muitas
situações de problemas. Algumas características deste tipo de rede:
• Pode ser configurado em qualquer máquina, pois sempre haverá uma porta paralela.
Capítulo 5. Configurações especiais de Rede 69
• É útil para fazer instalação de Linux em máquinas sem CD-ROM. No momento da in-
stalação é preciso somente alternar para um console, executar os passos descritos aqui e
continuar com o processo de instalação normal :)
• É uma boa solução quando as duas máquinas estão próximas
• O custo para montagem desta rede é extremamente baixo, bastando um cabo Lap Link
Paralelo que custa no máximo R$20,00 o de 1,5M ou se gosta de eletrônica, montar seu
próprio cabo usando o esquema que descrevo em ‘Construindo um cabo LapLink Par-
alelo’ on the following page.
• Você poderá fazer qualquer coisa que faria em uma rede normal (incluindo MAS-
QUERADING, roteamento entre redes, etc) sendo bastante interessante para testes práti-
cos dos exemplos do Foca Linux Avançado ;-)
• Ficará admirado com as capacidade de rede existente no Linux e feliz por ter colocado
mais uma configuração em funcionamento :)
Agora, os contras da conexão via porta paralela:
• A porta paralela não estará disponível para ser usada em impressoras, conexão de
câmeras.
• O cabo não pode ter mais de 4,5 metros. Acima dessa comprimento, você pode colo-
car sua controladora em risco além da perda de sinal. Por segurança, o tamanho re-
comendável é 2,5 metros.
• Quando toda a banda do cabo é utilizada, algumas CPUs se tornam extremamente lentas.
Para configurar uma conexão via cabo paralelo (plip) entre duas máquinas, vamos assumir que
a primeira máquina terá o IP 192.168.1.1 e a segunda máquina 192.168.1.2:
1 Conecte o cabo Lap Link em cada uma das portas de impressora. Caso saiba fazer
conexões eletrônicas ou goste do assunto, veja ‘Construindo um cabo LapLink Paralelo’
on the next page.
2 Verifique se o seu kernel está compilado com o suporte a rede plip. Caso não esteja, a
configuração da interface plip falhará no passo do ifconfig.
3 Se o sistema executa algum daemon de impressão, interrompa antes de usar a porta
paralela. Alguns tipos de serviços de impressão interferem no funcionamento do plip.
4 Configure o módulo parport_pc passando o parâmetro irq=7 (a IRQ que sua porta de
impressora utiliza). Esta configuração é necessária pois em algumas máquinas isso faz
que o plip não funcione ou aconteçam somente timeouts de transmissão.
5 Execute o comando ifconfig plip0 192.168.1.1. Verifique se a interface foi ati-
vada com o comando ifconfig plip0.
6 Nesse ponto a interface está ativa, mas a nossa máquina não conhece nada sobre a
rede ou como alcançar a máquina 192.168.1.2. Como a conexão é ponto a ponto, pre-
cisamos adicionar uma rota direta para esta máquina com o comando: route add
-host 192.168.1.2 plip0. Este comando diz para criar uma rota com o destino
192.168.1.2 usando a interface plip0.
7 Configure a outra máquina seguindo os passos acima, apenas invertendo os 2 endereços
IPs usados.
Pronto, agora verifique se cada uma das máquinas se comunica com a outra usando o comando
ping 192.168.1.x. Se ocorrer um erro de timeout na transmissão, leia atentamente os pas-
sos acima e refaça a configuração em ambas as máquinas. Ainda não funcionando, verifique se
existe um firewall bloqueando os pacotes da nova interface e se o cabo Lap Link está em bom
estado, o problema pode estar ai.
Capítulo 5. Configurações especiais de Rede 70
O número máximo de interfaces plip? está limitado ao número máximo suportado pela
máquina. O padrão em sistemas padrão IBM/PC é de 3 (plip0, plip1, plip2).
Para desativar uma rede plip, utilize o comando ifconfig plip0 down, remova o módulo
plip (rmmod plip). Após isto, a porta paralela será liberada para uso por outros aplicativos.
Se você tem experiência com eletrônica, poderá construir seu próprio cabo LapLink Paralelo
para fazer os testes desta seção. Os materiais necessários são:
• 2 Conectores DB25 macho
• 2 Capas para os conectores acima.
• Fio para ligação dos conectores (15 ligações). No meu caso utilizei 2 metros de um rolo
de cabo SCSI de 50 vias para fazer as ligações, que é uma boa alternativa para manter o
cabo bonito e os fios juntos.
Este é o conector macho DB25 (a tomada que liga no computador) visto por trás (minha
namorada já disse que não sou bom em arte ASCII). Bom, não custa tentar de novo:
-------------------------------
13 \ o o o o o o o o o o o o o / 1
25 \ o o o o o o o o o o o o / 14
-------------------------
A figura acima mostra a posição dos pinos como referência para a soldagem dos terminais. A
tabela abaixo mostra a ligação dos fios nos cabos das 2 pontas do cabo:
+---------+---------+
| Ponta 1 | Ponta 2 |
+---------+---------+
| 1 | 1 |
| 2 | 15 |
| 3 | 13 |
| 4 | 12 |
| 5 | 10 |
| 6 | 11 |
| 10 | 5 |
| 11 | 6 |
| 12 | 4 |
| 13 | 3 |
| 14 | 14 |
| 15 | 2 |
| 16 | 16 |
| 17 | 17 |
| 25 | 25 |
+---------+---------+
Capítulo 5. Configurações especiais de Rede 71
Este método permite criar uma rede ponto a ponto usando a porta serial da máquina, que
funcionará de forma semelhante a mostrada em ‘Conectando dois computadores usando a
porta paralela’ on page 68.
O método que irei descrever é bastante simples e utiliza o slattach e o protocolo slip para co-
municação entre as duas máquinas, mas nada impede que seja usado o ppp para comunicação,
apenas acrescentará um pouco mais de complexibilidade para esta configuração para obter o
mesmo resultado.
Usando o método descrito, será criada uma interface chamada sl? (interface SLIP, onde ? é o
número da interface recém configurada).
A rede via porta serial pode atingir em média 115.200kbps/s mas é prático quando não tem
outras opções para fazer uma rede ponto a ponto. Segue algumas características deste tipo de
rede:
• Pode ser configurado em qualquer máquina, pois sempre haverá uma porta serial
disponível.
• É possível fazer a instalação de Linux em máquinas sem CD-ROM e acesso a rede, onde
não é possível gerar disquetes para instalar o resto dos pacotes necessários, embora seja
limitado a 11Kb/s. No momento da instalação é preciso somente alternar para um con-
sole, executar os passos descritos aqui e continuar com o processo de instalação normal
:)
• É uma boa solução quando as duas máquinas até em ambientes próximos.
• O custo para montagem desta rede é extremamente baixo, bastando um cabo Lap Link
Serial custa em média R$20,00 o cabo de 4 metros. Se você também é um amante da
eletrônica, estou descrevendo o esquema de montagem do cabo em ‘Construindo um
cabo LapLink Serial’ on the next page.
• Você poderá fazer qualquer coisa que faria em uma rede normal (incluindo roteamento
entre redes, MASQUERADING, etc)
• É mais uma prova das capacidades de rede que é possível usando o Linux.
Agora, os contras da conexão via porta serial:
• A porta serial não estará disponível para ser usada para conexão de mouses, impressoras
seriais, dispositivos eletrônicos e inteligentes, etc.
• O comprimento máximo do cabo é de 15 metros. Acima dessa comprimento, você pode
colocar sua controladora em risco além da perda de sinal. Por segurança, o tamanho
máximo recomendável é 13 metros
Para configurar uma conexão via cabo serial entre duas máquinas, vamos assumir que a
primeira máquina terá o IP 192.168.2.1 e a segunda máquina 192.168.2.2:
1 Conecte o cabo Lap Link serial em cada uma das portas seriais.
2 Verifique se o seu kernel está compilado com o suporte a rede slip e também com su-
porte a cslip (slip compactado, que melhora a taxa de transferência dependendo dos
dados sendo transmitidos). Caso não tenha o suporte a slip, você poderá usar o ppp nas
duas pontas do link fazendo algumas adaptações para usar a interface ppp?, como é
simples não será descrito neste guia :) (veja o manual do slattach)
3 Interrompa qualquer programa que esteja usando a porta serial.
Capítulo 5. Configurações especiais de Rede 72
Se você é uma pessoa que sabe mexer com eletrônica, poderá construir seu próprio cabo
LapLink serial para fazer os testes desta seção. Os materiais necessários são:
• 2 - Conectores seriais DB9 fêmea
• 2 - Capas para os conectores acima.
• Fios para ligação dos conectores. Uma forma que utilizei para montar este cabo foi
aproveitar um carretel de cabo SCSI aproveitando 10 metros desfiando somente 9 dos
50 fios que acompanha o cabo (deixei um fio extra no caso de algum outro se romper).
• Ferro de solda e solda para as ligações.
• Concentração e paciência para a confecção correta dos cabos.
Este é o conector fêmea DB9 (tomada que liga na máquina) visto por trás (hora de mostrar
novamente meu talento com arte ASCII :))
--------------
1 \ o o o o o / 5
6 \ o o o o / 9
----------
Capítulo 5. Configurações especiais de Rede 73
A figura acima mostra a posição dos pinos como referência para a soldagem dos terminais. A
tabela abaixo mostra a ligação dos fios nos cabos das 2 pontas. Note que cada ponta pode ter a
opção da serial de 9 ou 25 pinos (ou as duas):
+--------+--------+---------+
|Ponta 1 | | Ponta 2|
+---+----+--------+----+----+
| 9 | 25 | | 25 | 9 |
+---+----+--------+----+----+
| 5 | 7 | | 7 | 5 |
| 3 | 2 | | 3 | 2 |
| 7 | 4 | | 5 | 8 |
| 6 | 6 | | 20 | 4 |
| 2 | 3 | | 2 | 3 |
| 8 | 5 | | 4 | 7 |
| 4 | 20 | | 6 | 6 |
+---+----+--------+----+----+
Capítulo 5. Configurações especiais de Rede 74
75
Capítulo 6
A atividade dos programas são registradas em arquivos localizados em /var/log . Estes ar-
quivos de registros são chamados de logs e contém a data, hora e a mensagem emitida pelo
programa (violações do sistema, mensagens de erro, alerta e outros eventos) entre outros cam-
pos. Enfim, muitos detalhes úteis ao administrador tanto para acompanhar o funcionamento
do seu sistema, comportamento dos programas ou ajudar na solução e prevenção de proble-
mas.
Alguns programas como o Apache, exim, ircd e squid criam diversos arquivos de log e por
este motivo estes são organizados em sub-diretórios (a mesma técnica é usada nos arquivos de
configuração em /etc, conforme a padrão FHS atual).
Data|Hora|Máquina|daemon|mensagem
O campo máquina é o nome do computador que registrou a mensagem (a máquina pode atuar
como um servidor de logs registrando mensagens de diversos computadores em sua rede). O
campo daemon indica qual programa gravou a mensagem.
O uso dos utilitários do console pode ajudar muito na pesquisa e monitoração dos logs, por
exemplo, para obter todas as mensagens do daemon kernel da estação de trabalho wrk1,
eliminando os campos “wrk1” e “kernel”:
Os parâmetros “$1”, “$2” do comando awk indica que campos serão listados, (omitimos $4 e
$5 que são respectivamente “wrk1” e “kernel”). Um bom utilitário para monitoração de logs
está documentado em ‘logcheck’ on page 81.
Capítulo 6. Arquivos e daemons de Log 76
6.2.1 syslogd
facilidade.nível destino
Capítulo 6. Arquivos e daemons de Log 77
A facilidade e nível são separadas por um “.” e contém parâmetros que definem o que será
registrado nos arquivos de log do sistema:
• facilidade - É usada para especificar que tipo de programa está enviando a men-
sagem. Os seguintes níveis são permitidos (em ordem alfabética):
– auth - Mensagens de segurança/autorização (é recomendável usar authpriv ao in-
vés deste).
– authpriv - Mensagens de segurança/autorização (privativas).
– cron - Daemons de agendamento (cron e at).
– daemon - Outros daemons do sistema que não possuem facilidades específicas.
– ftp - Daemon de ftp do sistema.
– kern - Mensagens do kernel.
– lpr - Subsistema de impressão.
– local0 a local7 - Reservados para uso local.
– mail - Subsistema de e-mail.
– news - Subsistema de notícias da USENET.
– security - Sinônimo para a facilidade auth (evite usa-la).
– syslog - Mensagens internas geradas pelo syslogd.
– user - Mensagens genéricas de nível do usuário.
– uucp - Subsistema de UUCP.
– * - Confere com todas as facilidades.
Mais de uma facilidade pode ser especificada na mesma linha do syslog.conf
separando-as com “,”.
• nível - Especifica a importância da mensagem. Os seguintes níveis são permitidos (em
ordem de importância invertida; da mais para a menos importante):
– emerg - O sistema está inutilizável.
– alert - Uma ação deve ser tomada imediatamente para resolver o problema.
– crit - Condições críticas.
– err - Condições de erro.
– warning - Condições de alerta.
– notice - Condição normal, mas significante.
– info - Mensagens informativas.
– debug - Mensagens de depuração.
– * - Confere com todos os níveis.
– none - Nenhuma prioridade.
Além destes níveis os seguintes sinônimos estão disponíveis:
– error - Sinônimo para o nível err.
– panic - Sinônimo para o nível emerg.
– warn - Sinônimo para o nível warning.
• destino - O destino das mensagens pode ser um arquivo, um pipe (se iniciado por um
“|”), um computador remoto (se iniciado por uma “@”), determinados usuários do sis-
tema (especificando os logins separados por vírgula) ou para todos os usuários logados
via wall (usando “*”).
Todas as mensagens com o nível especificado e superiores a esta especificadas no
syslog.conf serão registradas, de acordo com as opções usadas. Conjuntos de facilidades
e níveis podem ser agrupadas separando-as por “;”.
Capítulo 6. Arquivos e daemons de Log 78
OBS1: Sempre use TABS ao invés de espaços para separar os parâmetros do syslog.conf.
OBS2: Algumas facilidades como security, emitem um beep de alerta no sistema e enviam
uma mensagem para o console, como forma de alerta ao administrador e usuários logados no
sistema.
Existem ainda 4 caracteres que garantes funções especiais: “*”, “=”, “!” e “-”:
• “*” - Todas as mensagens da facilidade especificada serão redirecionadas.
• “=” - Somente o nível especificado será registrado.
• “!” - Todos os níveis especificados e maiores NÃO serão registrados.
• “-” - Pode ser usado para desativar o sync imediato do arquivo após sua gravação.
Os caracteres especiais “=” e “!” podem ser combinados em uma mesma regra.
Exemplo: Veja abaixo um exemplo de um arquivo /etc/syslog.conf padrão de sistemas
Debian
#
# Primeiro alguns arquivos de log padrões. Registrados por facilidade
#
auth,authpriv.* /var/log/auth.log
*.*;auth,authpriv.none -/var/log/syslog
cron.* /var/log/cron.log
daemon.* -/var/log/daemon.log
kern.* -/var/log/kern.log
lpr.* -/var/log/lpr.log
mail.* /var/log/mail.log
user.* -/var/log/user.log
uucp.* -/var/log/uucp.log
#
# Registro de logs do sistema de mensagens. Divididos para facilitar
# a criação de scripts para manipular estes arquivos.
#
mail.info -/var/log/mail.info
mail.warn -/var/log/mail.warn
mail.err /var/log/mail.err
#
# Alguns arquivos de registro "pega-tudo".
# São usadas "," para especificar mais de uma prioridade (por
Capítulo 6. Arquivos e daemons de Log 79
#
# Emergências são enviadas para qualquer um que estiver logado no sistema. Ist
# é feito através da especificação do "*" como destino das mensagens e são
# enviadas através do comando wall.
#
*.emerg *
#
# Eu gosto de ter mensagens mostradas no console, mas somente em consoles que
# não utilizo.
#
#daemon,mail.*;\
# news.=crit;news.=err;news.=notice;\
# *.=debug;*.=info;\
# *.=notice;*.=warn /dev/tty8
6.2.2 klogd
Este daemon controla o registro de mensagens do kernel. Ele monitora as mensagens do kernel
e as envia para o daemon de monitoramento syslogd, por padrão.
klogd [opções]
opções
-d Ativa o modo de depuração do daemon
-f [arquivo ] Envia as mensagens do kernel para o arquivo especificado ao invés de enviar ao
daemon do syslog
-i Envia um sinal para o daemon recarregar os símbolos de módulos do kernel.
-I Envia um sinal para o daemon recarregar os símbolos estáticos e de módulos do kernel.
-n Evita a operação em segundo plano. Útil se iniciado pelo init
-k [arquivo ] Especifica o arquivo que contém os símbolos do kernel. Exemplos deste arquivo
estão localizados em /boot/System.map-xx.xx.xx.
-o Faz com que o daemon leia e registre todas as mensagens encontradas nos buffers do kernel,
após isto o daemon é encerrado.
-p Ativa o modo paranóia. Isto fará o klogd somente carregar detalhes sobre os módulos
quando os caracteres Oops forem detectados nas mensagens do kernel. É recomendável
ter sempre a última versão do klogd e evitar a utilização desta opção em ambientes críti-
cos.
-s Força a utilização da interface de chamadas do sistema para comunicação com o kernel.
-x Esconde tradução EIP, assim ele não lê o arquivo /boot/System.map-xx-xx-xx.
A especificação de um arquivo com a opção -k é necessária se desejar que sejam mostradas a
tabela de símbolos ao invés de endereços numéricos do kernel.
6.3 logger
Este comando permite enviar uma mensagem nos log do sistema. A mensagem é enviada aos
logs via daemon syslogd ou via soquete do sistema, é possível especificar a prioridade, nível,
um nome identificando o processo, etc. Seu uso é muito útil em shell scripts ou em outros
eventos do sistema.
logger [opções] [mensagem]
Onde:
mensagem Mensagem que será enviada ao daemon syslog
opções
-i Registra o PID do processo
-s Envia a mensagem ambos para a saída padrão (STDOUT) e syslog.
-f [arquivo ] Envia o conteúdo do arquivo especificado como mensagem ao syslog.
-t [nome ] Especifica o nome do processo responsável pelo log que será exibido antes do PID
na mensagem do syslog.
-p [prioridade ] Especifica a prioridade da mensagem do syslog, especificada como
facilidade.nível. Veja os tipos de prioridade/níveis em ‘Arquivo de configuração
syslog.conf’ on page 76. O valor padrão prioridade.nível é user.notice
Capítulo 6. Arquivos e daemons de Log 81
6.4.1 logcheck
6.4.2 logrotate
Usado para fazer backups dos logs atuais do sistema (programado via cron, ou outro dae-
mon com a mesma função) e criando novos arquivos de logs que serão usados pelo sistema.
Opcionalmente os arquivos de logs antigos serão compactados para diminuir a utilização de
espaço em disco ou enviados por e-mail ao administrador. A rotação dos arquivos de logs
proporciona maior agilidade quando precisamos encontrar algum detalhe útil (que seria mais
difícil de se achar em um arquivo de log de 10MB ou maior).
A rotação de logs é feita de acordo com o tamanho do arquivo de logs especificado, mas a
opção -f pode ser usada para “forçar” a rotação de logs. A opção -d fornece mais detalhes
sobre o que o logrotate está fazendo. Seu arquivo principal de configuração é o /etc
/logrotate.conf. Um modelo deste tipo de arquivo é o seguinte:
weekly
# Erros de não existência dos logs são enviados para o usuário root
mail root
missingok
monthly
create 0664 root utmp
rotate 1
}
rotate 7
}
As mensagens das máquinas de sua rede podem ser centralizadas em uma única máquina,
isto facilita o gerenciamento, análise e solução de problemas que ocorrem nas máquinas da
rede. Mais importante ainda é que qualquer invasão a estação de trabalho não será registrada
localmente (podendo ser apagada posteriormente pelo invasor, isso é comum).
Configurando o servidor de logs Adicione a opção -r ao iniciar o daemon syslogd para
aceitar logs enviados das máquinas clientes. Na distribuição Debian modifique o ar-
quivo /etc/init.d/sysklogd colocando a opção -r na variável SYSLOGD e reini-
cie o serviço usando ./sysklogd restart. Adicionalmente poderão ser usadas as
opções -l máquina (é um “L” minúsculo não uma letra “I”) para registrar o nome FQDN
da máquina e -h para redirecionar conexões a outros servidores de logs (veja ‘syslogd’ on
page 76).
Configurando máquinas cliente Modifique o arquivo /etc/syslogd.conf (veja ‘Arquivo
de configuração syslog.conf’ on page 76 colocando o nome do computador seguido
de “@” para redirecionar as mensagens dos logs:
auth,authpriv.* @servlog
.
* * ;auth,authpriv.none @servlog
cron.* @servlog
daemon.* @servlog
kern.* -/var/log/kern.log
kern.* @servlog
lpr.* @servlog
mail.* /var/log/mail.log
Capítulo 6. Arquivos e daemons de Log 85
user.* -/var/log/user.log
user.* @servlog
uucp.* -/var/log/uucp.log
E reinicie o daemon syslogd da máquina cliente para re-ler o arquivo de configuração:
killall -HUP syslogd ou /etc/init.d/sysklogd restart.
OBS1: Mantenha o relógio do servidor de logs sempre atualizado (use o chrony ou outro
daemon de sincronismo NTP para automatizar esta tarefa).
OBS2: É interessante compilar um daemon syslogd personalizado modificando o nome e
localização do arquivo /etc/syslog.conf para enganar possíveis invasores. Isto pode ser
modificado no arquivo syslogd.c na linha:
Use a imaginação para escolher um nome de arquivo e localização que dificulte a localização
deste arquivo.
OBS3: Em uma grande rede, é recomendável configurar um computador dedicado como servi-
dor de log (desativando qualquer outro serviço) e configurar o iptables para aceitar somente
o tráfego indo para a porta UDP 514 (syslogd):
Capítulo 7
Este capítulo traz algumas características sobre a distribuição Debian GNU/Linux, progra-
mas de configuração e particularidades. A maioria dos trechos aqui descritos, também se apli-
cam a distribuições baseadas na Debian, como o Kurumin e o Ubuntu.
Você deve estar se perguntando mas porque um capítulo falando sobre a
distribuição Debian se eu uso outra?. Bem, a partir da versão Intermediário
do Foca Linux existem algumas partes que são especificas de algumas distribuições Linux e
que não se aplicam a outras, como a localização dos arquivos de configuração, nomes dos
programas de configuração e outros detalhes específicos e esta versão é a baseada na Debian.
Pegue na página do Foca Linux (http://www.guiafoca.org) uma versão Intermediário
/Avançado do guia específico para sua distribuição.
cd /etc/init.d
./networking restart
Capítulo 7. A distribuição Debian GNU/Linux 89
Os Níveis de execução (run levels) são diferentes modos de funcionamento do GNU/Linux com
programas, daemons e recursos específicos. Em geral, os sistemas GNU/Linux possuem sete
níveis de execução numerados de 0 a 6. O daemon init é o primeiro programa executado no
GNU/Linux (veja através do ps ax|grep init) e responsável pela carga de todos daemons
de inicialização e configuração do sistema.
O nível de execução padrão em uma distribuição GNU/Linux é definido através do arquivo
de configuração do /etc/inittab através da linha
id:2:initdefault:
Os nível de execução atual do sistema pode ser visualizado através do comando runlevel e
modificado através dos programas init ou telinit. Quando é executado, o runlevel lê o
arquivo /var/run/utmp e adicionalmente lista o nível de execução anterior ou a letra N em
seu lugar (caso ainda não tenha ocorrido a mudança do nível de execução do sistema).
Na Debian, os diretórios /etc/rc0.d a /etc/rc6.d contém os links simbólicos para ar-
quivos em /etc/init.d que são acionados pelo nível de execução correspondente.
Por exemplo, o arquivo S10sysklogd em /etc/rc2.d, é um link simbólico para /etc
/init.d/sysklogd.
O que aconteceria se você removesse o arquivo /etc/rc2.d/S10sysklogd? Simplesmente
o daemon sysklogd deixaria de ser executado no nível de execução 2 do sistema (que é o
padrão da Debian).
A Debian segue o seguinte padrão para definir se um link simbólico em /etc/rc[0-6].d
iniciará ou interromperá a execução de um serviço em /etc/init.d, que é o seguinte:
• Se um link é iniciado com a letra K (kill), quer dizer que o serviço será interrompido
naquele nível de execução. O que ele faz é executar o daemon em /etc/init.d seguido
de stop.
• Se um link é iniciado com a letra S (start), quer dizer que o serviço será iniciado naquele
nível de execução (é equivalente a executar o daemon seguido de start).
Primeiro os links com a letra K são executado e depois os S. A ordem que os links são executa-
dos dependem do valor numérico que acompanha o link, por exemplo, os seguintes arquivos
são executados em seqüência:
S10sysklogd
S12kerneld
S20inetd
S20linuxlogo
S20logoutd
S20lprng
Capítulo 7. A distribuição Debian GNU/Linux 90
S89cron
S99xdm
Note que os arquivos que iniciam com o mesmo número (S20*) são executados alfabetica-
mente. O nível de execução do sistema pode ser modificado usando-se o comando init ou
telinit. Os seguinte níveis de execução estão disponíveis na Debian:
• 0 - Interrompe a execução do sistema. todos os programas e daemons finalizados. É
acionado pelo comando shutdown -h
• 1 - Modo monousuário, útil para manutenção dos sistema.
• 2 - Modo multiusuário (padrão da Debian)
• 3 - Modo multiusuário
• 4 - Modo multiusuário
• 5 - Modo multiusuário com login gráfico
• 6 - Reinicialização do sistema. Todos os programas e daemons são encerrados e o sis-
tema é reiniciado. É acionado pelo comando shutdown -r e o pressionamento de
CTRL+ALT+DEL.
Por exemplo, para listar o nível de execução atual do sistema digite: runlevel. O runlevel
deverá listar algo como:
N 2
Agora para mudar para o nível de execução 1, digite: init 3. Agora confira a mudança
digitando: runlevel. Você deverá ver este resultado:
2 3
É o sistema para relatar bugs e enviar sugestões sobre a distribuição. Para relatar um bug
primeiro você deve saber inglês (é a língua universal entendida pelos desenvolvedores) e ver-
ificar se o bug já foi relatado. O Debian Bug tracking system pode ser acessado pelo endereço:
http://bugs.debian.org/.
Para relatar uma falha/sugestão, envie um e-mail para: <submit@bugs.debian.org>, com
o assunto referente a falha/sugestão que deseja fazer e no corpo da mensagem:
Capítulo 7. A distribuição Debian GNU/Linux 91
Package: pacote
Severity: normal/grave/wishlist
Version: versão do pacote
E o relato do problema
O bug será encaminhado diretamente ao mantenedor do pacote que verificará o problema re-
latado. Os campos Package e Severity são obrigatórios para definir o nome do pacote (para
endereçar o bug para a pessoa correta) e versão do pacote (esta falha pode ter sido relatada e
corrigida em uma nova versão).
Capítulo 8
Personalização do Sistema
Este capítulo ensina como personalizar algumas características de seu sistema GNU/Linux.
O idioma usado em seu sistema pode ser modificado facilmente através das variáveis de ambi-
ente. Atualmente a maioria dos programas estão sendo localizados. A localização é um recurso
que especifica arquivos que contém as mensagens do programas em outros idiomas. Você
Capítulo 8. Personalização do Sistema 94
pode usar o comando locale para listar as variáveis de localização do sistema e seus re-
spectivos valores. As principais variáveis usadas para determinar qual idioma os programas
localizados utilizarão são:
• LANG - Especifica o idioma_PAIS local. Podem ser especificados mais de um idioma na
mesma variável separando-os com :, desta forma caso o primeiro não esteja disponível
para o programa o segundo será verificado e assim por diante. A língua Inglesa é iden-
tificada pelo código C e usada como padrão caso nenhum locale seja especificado. Por
exemplo: export LANG=pt_BR, export LANG=pt_BR:pt_PT:C
• LC_MESSAGES - Especifica o idioma que serão mostradas as mensagens dos programas.
Seu formato é o mesmo de LANG.
• LC_ALL - Configura todas as variáveis de localização de uma só vez. Seu formato é o
mesmo de LANG.
8.3 alias
Permite criar um apelido a um comando ou programa. Por exemplo, se você gosta de digitar
(como eu) o comando ls --color=auto para ver uma listagem longa e colorida, você pode
usar o comando alias para facilitar as coisas digitando: alias ls=’ls --color=auto’
(não se esqueça da meia aspa ’para identificar o comando’). Agora quando você digitar ls, a
listagem será mostrada com cores.
Se você digitar ls -la, a opção -la será adicionada no final da linha de comando do alias:
ls --color=auto -la, e a listagem também será mostrada em cores.
Se quiser utilizar isto toda vez que entrar no sistema, veja ‘Arquivo .bash_profile’ on the
following page e ‘Arquivo .bashrc’ on the next page.
Este arquivo contém comandos que são executados para todos os usuários do sistema no mo-
mento do login. Somente o usuário root pode ter permissão para modificar este arquivo.
Este arquivo é lido antes do arquivo de configuração pessoal de cada usuário (.profile(root)
e .bash_profile).
Quando é carregado através de um shell que requer login (nome e senha), o bash procura
estes arquivos em seqüência e executa os comandos contidos, caso existam:
1 /etc/profile
2 ~/.bash_profile
3 ~/.bash_login
4 ~/.profile
Ele interrompe a pesquisa assim que localiza o primeiro arquivo no diretório do usuário
(usando a sequência acima). Por exemplo, se você tem o arquivo ~/.bash_login e ~
/.bash_profile em seu diretório de usuário, ele processará o /etc/profile e após
isto o ~/.bash_profile, mas nunca processará o ~/.bash_login (a menos que o ~
/.bash_profile seja apagado ou renomeado).
Caso o bash seja carregado através de um shell que não requer login (um terminal no X, por
exemplo), o seguinte arquivo é executado: ~/.bashrc.
Observação: Nos sistemas Debian, o profile do usuário root está configurado no arquivo
/root/.profile. A razão disto é porque se o bash for carregado através do comando sh,
ele fará a inicialização clássica deste shell lendo primeiro o arquivo /etc/profile e após o
~/.profile e ignorando o .bash_profile e .bashrc que são arquivos de configuração
Capítulo 8. Personalização do Sistema 96
usados somente pelo Bash. Exemplo, inserindo a linha mesg y no arquivo /etc/profile
permite que todos os usuários do sistema recebam pedidos de talk de outros usuários. Caso
um usuário não quiser receber pedidos de talk, basta somente adicionar a linha mesg n no
arquivo pessoal .bash_profile.
Este arquivo reside no diretório pessoal de cada usuário. É executado por shells que usam
autenticação (nome e senha). .bash_profile contém comandos que são executados para o
usuário no momento do login no sistema após o /etc/profile. Note que este é um arquivo
oculto pois tem um “.” no inicio do nome.
Por exemplo colocando a linha: alias ls=’ls --colors=auto’ no .bash_profile,
cria um apelido para o comando ls -colors=auto usando ls, assim toda vez que você
digitar ls será mostrada a listagem colorida.
Possui as mesmas características do .bash_profile mas é executado por shells que não
requerem autenticação (como uma seção de terminal no X).
Os comandos deste arquivo são executados no momento que o usuário inicia um shell com as
características acima. Note que este é um arquivo oculto pois tem um “.” no inicio do nome.
Deve ser colocado no diretório pessoal do usuário. Este arquivo faz o bash pular as mensagens
do /etc/motd, número de e-mails, etc. Exibindo imediatamente o aviso de comando após a
digitação da senha.
Armazena as variáveis de ambiente que são exportadas para todo o sistema. Uma variável
de ambiente controla o comportamento de um programa, registram detalhes úteis durante a
seção do usuário no sistema, especificam o idioma das mensagens do sistema, etc.
Exemplo do conteúdo de um arquivo /etc/environment:
LANG=pt_BR
LC_ALL=pt_BR
LC_MESSAGES=pt_BR
Capítulo 8. Personalização do Sistema 97
Este diretório contém os modelos de arquivos .bash_profile e .bashrc que serão copiados
para o diretório pessoal dos usuários no momento que for criada uma conta no sistema. Desta
forma você não precisará configurar estes arquivos separadamente para cada usuário.
Capítulo 8. Personalização do Sistema 98
99
Capítulo 9
Impressão
Este capitulo descreve como imprimir em seu sistema GNU/Linux e as formas de impressão
via spool, rede, gráfica, etc.
Antes de seguir os passos descritos neste capítulo, tenha certeza que seu kernel foi compilado
com o suporte a impressora USB e/ou paralela ativado, caso contrário até mesmo a impressão
direta para a porta de impressora falhará. .
Uma porta de impressora é o local do sistema usado para se comunicar com a impressora. Em
sistemas GNU/Linux, a porta de impressora paralela é identificada como lp0,lp1,lp2 no di-
retório /dev, caso a impressora seja USB, o dispositivo será o mesmo, mas estará disponível no
diretório /dev/usb. Os dispositivos lp0,lp1elp2 correspondem respectivamente a LPT1,
LPT2 e LPT3 no DOS e Windows. Recomendo que o suporte a porta paralela esteja compilado
como módulo no kernel.
Isto é feito direcionando a saída ou o texto com > diretamente para a porta de impressora no
diretório /dev.
Supondo que você quer imprimir o texto contido do arquivo trabalho.txt e a porta de
impressora em seu sistema é /dev/usb/lp0, você pode usar os seguintes comandos:
• cat trabalho.txt >/dev/usb/lp0 - Direciona a saída do comando cat para a im-
pressora USB conectada em lp0.
• cat <trabalho.txt >/dev/usb/lp0. Faz a mesma coisa que o acima.
• cat -n trabalho.txt >/dev/usb/lp0 - Numera as linhas durante a impressão.
• head -n 30 trabalho.txt >/dev/usb/lp0 - Imprime as 30 linhas iniciais do ar-
quivo.
Capítulo 9. Impressão 100
A impressão via spool (fila de impressão) tem por objetivo liberar logo o programa do serviço
que está fazendo a impressão deixando um outro programa especifico tomar conta.
Este programa é chamado de daemon de impressão, normalmente é o lpr ou o lprng (recomen-
dado) em sistemas GNU/Linux.
Logo após receber o arquivo que será impresso, o programa de spool gera um arquivo tem-
porário (normalmente localizado em /var/spool/lpd) que será colocado em fila para a im-
pressão (um trabalho será impresso após o outro, em seqüência). O arquivo temporário gerado
pelo programa de spool é apagado logo após concluir a impressão.
Antes de se imprimir qualquer coisa usando os daemons de impressão, é preciso configurar
os parâmetros de sua impressora no arquivo /etc/printcap. Um arquivo /etc/printcap
para uma impressora local padrão se parece com o seguinte:
É possível também compartilhar a impressora para a impressão em sistemas remotos, isto será
visto em uma seção separada neste guia.
Usando os exemplos anteriores da seção Imprimindo diretamente para uma porta
de impressora, vamos acelerar as coisas:
• cat trabalho.txt |lpr - Direciona a saída do comando cat para o programa de
spool lpr.
Capítulo 9. Impressão 101
A impressão em modo gráfico requer que conheça a marca e modelo de sua impressora e
os métodos usados para imprimir seus documentos. Este guia abordará somente a segunda
recomendação :-)
O método mais usados pelos aplicativos do GNU/Linux para a impressão de gráficos do Ghost
Script. O Ghost Script (chamado de gs) é um interpretador do formato Pos Script (arquivos
.ps) e pode enviar o resultado de processamento tanto para a tela como impressora. Ele está
disponível para diversas plataformas e sistema operacionais além do GNU/Linux, inclusive o
DOS, Windows, OS/2, etc.
O formato .ps esta se tornando uma padronização para a impressão de gráficos em
GNU/Linux devido a boa qualidade da impressão, liberdade de configuração, gerenciamento
de impressão feito pelo gs e por ser um formato universal, compatíveis com outros sistemas
operacionais.
Para imprimir um documento via Ghost Script, você precisará do pacote gs, gsfonts (para
a distribuição Debian e distribuições baseadas, ou outros de acordo com sua distribuição
Linux) e suas dependências. A distribuição Debian vem com vários exemplos Pos Script no
diretório /usr/share/doc/gs/example que são úteis para o aprendizado e testes com o
Ghost Script.
Hora da diversão:
Capítulo 9. Impressão 102
entendido por impressoras epson e poderá ser impresso com o comando cat
arquivo.epson >/dev/lp0. Uma curiosidade útil: É possível imprimir este
arquivo em outros sistemas operacionais, tal como o DOS digitando: copy /b
arquivo.eps prn (lembre-se que o DOS tem um limite de 8 letras no nome
do arquivo e 3 na extensão. Você deve estar compreendendo a flexibilidade que
o GNU/Linux e suas ferramentas permitem, isso é só o começo.
* impressao%d.epson - Nome do arquivo que receberá o resultado do
processamento. Cada página será gravada em arquivos separados como
impressao1.epson, impressao2.epson. Os arquivos podem ser impres-
sos usando os mesmos métodos acima.
* /dev/lp0 para uma impressora em /dev/lp0
* - para redirecionar a saída de processamento do gs para a saída padrão. É útil
para usar o gs com pipes |.
* \|lpr - Envia a saída do Ghost Script para o daemon de impressão. O objetivo
é deixar a impressão mais rápida.
Se você é curioso ou não esta satisfeito com as opções mostradas acima, veja a página
de manual do gs.
O Magic Filter é um filtro de impressão inteligente. Ele funciona acionado pelo spool de im-
pressão (mais especificamente o arquivo /etc/printcap) e permite identificar e imprimir
arquivos de diversos tipos diretamente através do comando lpr arquivo.
É um ótimo programa e ALTAMENTE RECOMENDADO se você deseja apenas clicar no
botão imprimir e deixar os programas fazerem o resto :-) A intenção do programa é justamente
automatizar os trabalhos de impressão e spool.
A maioria dos programas para ambiente gráfico X11, incluindo o Netscape, Word Perfect,
Gimp e Star Office trabalham nativamente com o magicfilter.
:if=/etc/magicfilter/epson9-filter
Não tenho nenhum contrato de divulgação com a epson :-) estou usando esta marca de impres-
sora porque é a mais tradicional e facilmente encontrada. A linha que começa com :if no
magicfilter identifica um arquivo de filtro de impressão.
O arquivo /etc/magicfilter/epson9-filter é criado usando o formato do magicfilter,
e não é difícil entender seu conteúdo e fazer algumas modificações:
#! /usr/sbin/magicfilter
#
# Magic filter setup file for 9-pin Epson (or compatible) printers
#
# This file is in the public domain.
#
# This file has been automatically adapted to your system.
#
# wild guess: native control codes start with ESC
0 \033 cat
# PostScript
0 %! filter /usr/bin/gs -q -dSAFER -dNOPAUSE -r120x72 -sDEVICE=epson -sOutputF
0 \004%! filter /usr/bin/gs -q -dSAFER -dNOPAUSE -r120x72 -sDEVICE=epson -sOut
# PDF
0 %PDF fpipe /usr/bin/gs -q -dSAFER -dNOPAUSE -r120x72 -sDEVICE=epson -sOutput
# TeX DVI
0 \367\002 fpipe /usr/bin/dvips -X 120 -Y 72 -R -q -f
# compress’d data
0 \037\235 pipe /bin/gzip -cdq
Capítulo 9. Impressão 105
# troff documents
0 .\?\?\040 fpipe ‘/usr/bin/grog -Tps $FILE‘
0 .\\\" fpipe ‘/usr/bin/grog -Tps $FILE‘
0 ’\\\" fpipe ‘/usr/bin/grog -Tps $FILE‘
0 ’.\\\" fpipe ‘/usr/bin/grog -Tps $FILE‘
0 \\\" fpipe ‘/usr/bin/grog -Tps $FILE‘
Você deve ter notado que para cada tipo de arquivo existe o respectivo programa que é execu-
tado, basta você modificar as opções usadas nos programas neste arquivo (como faria na linha
de comando) para afetar o comportamento da impressão.
Por exemplo, modificando a resolução para -r240x72 no processamento de arquivos Pos Script
(gs), a impressora passará a usar esta resolução.
Aqui será explicado como fazer seu sistema Linux atuar como um servidor de impressão para
outras máquinas de sua rede.
As máquinas autorizadas a usar a impressora local deverão ter seus nomes incluídos no ar-
quivo /etc/hosts.lpd (para o daemon lpd padrão) ou /etc/lprng/lpd.perms (para o
daemon lpd do pacote lprng).
O arquivo /etc/lprng/lpd.perms do lprng é mais configurável (e complexo), uma linha
como:
aceitará os serviços (SERVICE) de conexão (X), lpr (R), impressão de trabalhos (P), lpq (Q),
lprm (M) e lpc (C) da máquina estacao1.dominio.org. Veja os comentários neste arquivo
para entender o funcionamento de suas opções ou a página de manual do lpd.perms.
Capítulo 9. Impressão 106
Através deste método, a impressão será tratada através do spool remoto (lpd ou lprng) e
enviada ao servidor de impressão. Para que isto funcione, utilize a seguinte configuração no
seu arquivo /etc/printcap:
lp:Impressora remota:\
:sd=/var/spool/lpd/lp:\
:rm=impr.meudominio.org:\
:rp=hp:\
:sh:
Então quando for executado o comando lpr na máquina remota, o lprng en-
viará a impressão para a impressora hp (rp=hp) na máquina impr.meudominio.org
(rm=impr.meudominio.org).
Caso você tenha a opção de imprimir tanto para uma impressora local quando para uma re-
mota, você poderá usar uma configuração como a seguinte:
lp|hp|Impressora Local:\
:lp=/dev/lp0:\
:sd=/var/spool/lpd/hp:\
:sh:\
:pw#80:\
:pl#66: \
:px#1440:\
:mx#0:\
:if=/etc/magicfilter/dj930c-filter:\
Capítulo 9. Impressão 107
:af=/var/log/lp-acct:\
:lf=/var/log/lp-errs:
hp-r|Impressora Remota:\
:sd=/var/spool/lpd/lp:\
:rm=impr.meudominio.org:\
:rp=hp:\
:sh:
Para selecionar qual impressora será usada, adicione a opção -Pimpressora na linha de comando
dos utilitários lpr, lpq, lprm (por exemplo, lpr -Php-r relatorio.txt. Quando a
opção -P é especificada, a impressora lp será usada por padrão.
OBS Lembre-se de reiniciar seu daemon de impressão toda vez que modificar o arquivo /etc
/printcap.
Capítulo 9. Impressão 108
109
Capítulo 10
Firewall iptables
10.1 Introdução
O Firewall é um programa que como objetivo proteger a máquina contra acessos indesejados,
tráfego indesejado, proteger serviços que estejam rodando na máquina e bloquear a passagem
de coisas que você não deseja receber (como conexões vindas da Internet para sua segura rede
local, evitando acesso aos dados corporativos de uma empresa ou a seus dados pessoais). No
kernel do Linux 2.4, foi introduzido o firewall iptables (também chamado de netfilter) que
substitui o ipchains dos kernels da série 2.2. Este novo firewall tem como vantagem ser
muito estável (assim como o ipchains e ipfwadm), confiável, permitir muita flexibilidade
na programação de regras pelo administrador do sistema, mais opções disponíveis ao ad-
ministrador para controle de tráfego, controle independente do tráfego da rede local/entre
redes/interfaces devido a nova organização das etapas de roteamento de pacotes.
O iptables é um firewall em nível de pacotes e funciona baseado no endereço/porta de
origem/destino do pacote, prioridade, etc. Ele funciona através da comparação de regras para
saber se um pacote tem ou não permissão para passar. Em firewalls mais restritivos, o pacote é
bloqueado e registrado para que o administrador do sistema tenha conhecimento sobre o que
está acontecendo em seu sistema.
Ele também pode ser usado para modificar e monitorar o tráfego da rede, fazer NAT (mas-
querading, source nat, destination nat), redirecionamento de pacotes, marcação de pacotes,
modificar a prioridade de pacotes que chegam/saem do seu sistema, contagem de bytes, di-
vidir tráfego entre máquinas, criar proteções anti-spoofing, contra syn flood, DoS, etc. O
tráfego vindo de máquinas desconhecidas da rede pode também ser bloqueado/registrado
através do uso de simples regras. As possibilidades oferecidas pelos recursos de filtragem
iptables como todas as ferramentas UNIX maduras dependem de sua imaginação, pois ele
garante uma grande flexibilidade na manipulação das regras de acesso ao sistema, precisando
Capítulo 10. Firewall iptables 110
apenas conhecer quais interfaces o sistema possui, o que deseja bloquear, o que tem acesso
garantido, quais serviços devem estar acessíveis para cada rede, e iniciar a construção de seu
firewall.
O iptables ainda tem a vantagem de ser modularizável, funções podem ser adicionadas
ao firewall ampliando as possibilidades oferecidas. Usei por 2 anos o ipchains e afirmo que
este é um firewall que tem possibilidades de gerenciar tanto a segurança em máquinas isoladas
como roteamento em grandes organizações, onde a passagem de tráfego entre redes deve ser
minuciosamente controlada.
Um firewall não funciona de forma automática (instalando e esperar que ele faça as coisas
por você), é necessário pelo menos conhecimentos básicos de rede tcp/ip, roteamento e portas
para criar as regras que farão a segurança de seu sistema. A segurança do sistema depende do
controle das regras que serão criadas por você, as falhas humanas são garantia de mais de 95%
de sucesso nas invasões.
Enfim o iptables é um firewall que agradará tanto a pessoas que desejam uma segurança
básica em seu sistema, quando administradores de grandes redes que querem ter um controle
minucioso sobre o tráfego que passam entre suas interfaces de rede (controlando tudo o que
pode passar de uma rede a outra), controlar o uso de tráfego, monitoração, etc.
10.1.1 Versão
É assumido que esteja usando a versão 1.2.3 do iptables e baseadas nas opções do kernel
2.4.16 (sem o uso de módulos experimentais). As explicações contidas aqui podem funcionar
para versões posteriores, mas é recomendável que leia a documentação sobre modificações no
programa (changelog) em busca de mudanças que alterem o sentido das explicações fornecidas
aqui.
O iptables é um código de firewall das versões 2.4 do kernel, que substituiu o ipchains
(presente nas séries 2.2 do kernel). Ele foi incluído no kernel da série 2.4 em meados de
Junho/Julho de 1999.
A história do desenvolvimento (desde o porte do ipfw do BSD para o Linux até o
iptables (que é a quarta geração de firewalls do kernel) está disponível no documento,
Netfilter-howto.
• Tratamento de tráfego dividido em chains (para melhor controle do tráfego que entra/sai
da máquina e tráfego redirecionado.
• Permite um número ilimitado de regras por chain
• Muito rápido, estável e seguro
• Possui mecanismos internos para rejeitar automaticamente pacotes duvidosos ou mal
formados.
• Suporte a módulos externos para expansão das funcionalidades padrões oferecidas pelo
código de firewall
• Suporte completo a roteamento de pacotes, tratadas em uma área diferente de tráfegos
padrões.
• Suporte a especificação de tipo de serviço para priorizar o tráfego de determinados tipos
de pacotes.
• Permite especificar exceções para as regras ou parte das regras
• Suporte a detecção de fragmentos
• Permite enviar alertas personalizados ao syslog sobre o tráfego aceito/bloqueado.
• Redirecionamento de portas
• Masquerading
• Suporte a SNAT (modificação do endereço de origem das máquinas para um único IP ou
faixa de IP’s).
• Suporte a DNAT (modificação do endereço de destino das máquinas para um único IP
ou fixa de IP’s)
• Contagem de pacotes que atravessaram uma interface/regra
• Limitação de passagem de pacotes/conferência de regra (muito útil para criar proteções
contra, syn flood, ping flood, DoS, etc).
Pacote: iptables
• iptables - Sistema de controle principal para protocolos ipv4
• ip6tables - Sistema de controle principal para protocolos ipv6
• iptables-save - Salva as regras atuais em um arquivo especificado como argumento.
Este utilitário pode ser dispensado por um shell script contendo as regras executado na
inicialização da máquina.
• iptables-restore - Restaura regras salvas pelo utilitário iptables-save.
10.1.5 Requerimentos
É necessário que o seu kernel tenha sido compilado com suporte ao iptables (veja ‘Habil-
itando o suporte ao iptables no kernel’ on page 115. O requerimento mínimo de memória
necessária para a execução do iptables é o mesmo do kernel 2.4 (4MB). Dependendo do
tráfego que será manipulado pela(s) interface(s) do firewall ele poderá ser executado com folga
em uma máquina 386 SX com 4MB de RAM.
Como as configurações residem no kernel não é necessário espaço extra em disco rígido para
a execução deste utilitário.
Capítulo 10. Firewall iptables 112
Todo tráfego que for registrado pelo iptables é registrado por padrão no arquivo /var/log
/kern.log.
10.1.7 Instalação
O iptables faz parte da nova geração de firewalls que acompanha o kernel 2.4, mas o su-
porte ao ipchains e ipfwadm ainda será mantido através de módulos de compatibilidade do
kernel até 2004. Seria uma grande falta de consideração retirar o suporte a estes firewalls do
kernel como forma de obrigar a “aprenderem” o iptables (mesmo o suporte sendo removido
após este período, acredito que criarão patches “externos” para futuros kernels que não trarão
mais este suporte). Se precisa do suporte a estes firewalls antes de passar em definitivo para o
iptables leia ‘Habilitando o suporte ao iptables no kernel’ on page 115.
Se você é um administrador que gosta de explorar todos os recursos de um firewall, usa todos
os recursos que ele oferece ou mantém uma complexa rede corporativa, tenho certeza que
gostará do iptables.
• nível de pacotes - Este tipo de firewall toma as decisões baseadas nos parâmetros do
pacote, como porta/endereço de origem/destino, estado da conexão, e outros parâmet-
ros do pacote. O firewall então pode negar o pacote (DROP) ou deixar o pacote passar
(ACCEPT). O iptables é um excelente firewall que se encaixa nesta categoria. Firewall
em nível de pacotes é o assunto explicado nesta seção do guia mas será apresentada uma
explicação breve sobre o funcionamento de análise de strings do iptables.
Os dois tipos de firewalls podem ser usados em conjunto para fornecer uma camada dupla de
segurança no acesso as suas máquinas/máquinas clientes.
As regras são como comandos passados ao iptables para que ele realize uma determi-
nada ação (como bloquear ou deixar passar um pacote) de acordo com o endereço/porta
de origem/destino, interface de origem/destino, etc. As regras são armazenadas dentro dos
chains e processadas na ordem que são inseridas.
As regras são armazenadas no kernel, o que significa que quando o computador for reiniciado
tudo o que fez será perdido. Por este motivo elas deverão ser gravadas em um arquivo para
serem carregadas a cada inicialização.
Um exemplo de regra: iptables -A INPUT -s 123.123.123.1 -j DROP.
Os Chains são locais onde as regras do firewall definidas pelo usuário são armazenadas para
operação do firewall. Existem dois tipos de chains: os embutidos (como os chains INPUT,
OUTPUT e FORWARD) e os criados pelo usuário. Os nomes dos chains embutidos devem ser
especificados sempre em maiúsculas (note que os nomes dos chains são case-sensitive, ou seja,
o chain input é completamente diferente de INPUT).
Tabelas são os locais usados para armazenar os chains e conjunto de regras com uma deter-
minada característica em comum. As tabelas podem ser referenciadas com a opção -t tabela e
existem 3 tabelas disponíveis no iptables:
• nat - Usada para dados que gera outra conexão (masquerading, source nat, destination
nat, port forwarding, proxy transparente são alguns exemplos). Possui 3 chains padrões:
– PREROUTING - Consultado quando os pacotes precisam ser modificados logo que
chegam. É o chain ideal para realização de DNAT e redirecionamento de portas
(‘Fazendo DNAT’ on page 138).
– OUTPUT - Consultado quando os pacotes gerados localmente precisam ser modifi-
cados antes de serem roteados. Este chain somente é consultado para conexões que
se originam de IPs de interfaces locais.
Capítulo 10. Firewall iptables 115
• mangle - Utilizada para alterações especiais de pacotes (como modificar o tipo de serviço
(TOS) ou outros detalhes que serão explicados no decorrer do capítulo. Possui 2 chains
padrões:
– INPUT - Consultado quando os pacotes precisam ser modificados antes de serem
enviados para o chain INPUT da tabela filter.
– FORWARD - Consultado quando os pacotes precisam ser modificados antes de serem
enviados para o chain FORWARD da tabela filter.
– PREROUTING - Consultado quando os pacotes precisam ser modificados antes de
ser enviados para o chain PREROUTING da tabela nat.
– POSTROUTING - Consultado quando os pacotes precisam ser modificados antes de
serem enviados para o chain POSTROUTING da tabela nat.
– OUTPUT - Consultado quando os pacotes precisam ser modificados antes de serem
enviados para o chain OUTPUT da tabela nat.
Veja ‘A tabela mangle’ on page 139 para mais detalhes sobre a tabela mangle.
Para usar toda a funcionalidade do firewall iptables, permitindo fazer o controle do que tem
ou não permissão de acessar sua máquina, fazer Masquerading/NAT em sua rede, etc., você
precisará dos seguintes componentes compilados em seu kernel (os módulos experimentais
fora ignorados intencionalmente):
*
* Network Options:
*
e na Subseção:
*
* IP: Netfilter Configuration
*
Connection tracking (required for masq/NAT) (CONFIG_IP_NF_CONNTRACK) [M/n/y/?]
FTP protocol support (CONFIG_IP_NF_FTP) [M/n/?]
IRC protocol support (CONFIG_IP_NF_IRC) [M/n/?]
IP tables support (required for filtering/masq/NAT) (CONFIG_IP_NF_IPTABLES) [Y
limit match support (CONFIG_IP_NF_MATCH_LIMIT) [Y/m/n/?]
MAC address match support (CONFIG_IP_NF_MATCH_MAC) [M/n/y/?]
netfilter MARK match support (CONFIG_IP_NF_MATCH_MARK) [M/n/y/?]
Capítulo 10. Firewall iptables 116
Esta configuração permite que você não tenha problemas para iniciar o uso e configuração do
seu firewall iptables, ela ativa os módulos necessários para utilização de todos os recursos do
firewall iptables. Quando conhecer a função de cada um dos parâmetros acima (durante o
decorrer do texto), você poderá eliminar muitas das opções desnecessárias para seu estilo de
firewall ou continuar fazendo uso de todas ;-)
OBS1: A configuração acima leva em consideração que você NÃO executará os códi-
gos antigos de firewall ipfwadm e ipchains. Caso deseje utilizar o ipchains ou o
ipfwadm, será preciso responder com “M” a questão “IP tables support (required for fil-
tering/masq/NAT) (CONFIG_IP_NF_IPTABLES)”. Será necessário carregar manualmente o
módulo correspondente ao firewall que deseja utilizar (modprobe iptables_filter.o no
caso do iptables).
Não execute mais de um tipo de firewall ao mesmo tempo!!!
OBS2: É recomendável ativar o daemon kmod para carga automática de módulos, caso con-
trário será necessário compilar todas as partes necessárias embutidas no kernel, carregar os
módulos necessários manualmente ou pelo iptables (através da opção –modprobe=módulo).
Se a sua intenção (como da maioria dos usuários) é conectar sua rede interna a Internet de
forma rápida e simples, leia ‘Fazendo IP masquerading (para os apressados)’ on page 135 ou
‘Fazendo SNAT’ on page 136. Um exemplo prático de configuração de Masquerading deste
tipo é encontrado em ‘Conectando sua rede interna a Internet’ on page 156.
Após configurar o masquerading, você só precisará especificar o endereço IP da máquina
masquerading (servidor) como Gateway da rede. No Windows 9x/NT/2000 isto é feito no
Painel de Controle/Rede/Propriedades de Tcp/IP. No Linux pode ser feito com route add
default gw IP_do_Servidor.
Capítulo 10. Firewall iptables 117
O iptables trabalha com uma tabela de regras que é analisada uma a uma até que a última
seja processada. Por padrão, se uma regra tiver qualquer erro, uma mensagem será mostrada
e ela descartada. O pacote não conferirá e a ação final (se ele vai ser aceito ou rejeitado) depen-
derá das regras seguintes.
As opções passadas ao iptables usadas para manipular os chains são SEMPRE em maiús-
culas. As seguintes operações podem ser realizadas:
Como exemplo vamos criar uma regra que bloqueia o acesso a nosso própria máquina
(127.0.0.1 - loopback). Primeiro daremos um ping para verificar seu funcionamento:
#ping 127.0.0.1
PING 127.0.0.1 (127.0.0.1): 56 data bytes
64 bytes from 127.0.0.1: icmp_seq=0 ttl=255 time=0.6 ms
64 bytes from 127.0.0.1: icmp_seq=1 ttl=255 time=0.5 ms
Ok, a máquina responde, agora vamos incluir uma regra no chain INPUT (-A INPUT) que
bloqueie (-j DROP) qualquer acesso indo ao endereço 127.0.0.1 (-d 127.0.0.1):
iptables -t filter -A INPUT -d 127.0.0.1 -j DROP
Agora verificamos um novo ping:
#ping 127.0.0.1
PING 127.0.0.1 (127.0.0.1): 56 data bytes
Desta vez a máquina 127.0.0.1 não respondeu, pois todos os pacotes com o destino 127.0.0.1 (-d
127.0.0.1) são rejeitados (-j DROP). A opção -A é usada para adicionar novas regras no final do
chain. Além de -j DROP que serve para rejeitar os pacotes, podemos também usar -j ACCEPT
para aceitar pacotes. A opção -j é chamada de alvo da regra ou somente alvo pois define o
destino do pacote que atravessa a regra (veja ‘Especificando um alvo’ on page 130). Bem vindo
a base de um sistema de firewall :-)
OBS1: - O acesso a interface loopback não deve ser de forma alguma bloqueado, pois muitos
aplicativos utilizam soquetes tcp para realizarem conexões, mesmo que você não possua uma
rede interna.
Capítulo 10. Firewall iptables 118
OBS2: - A tabela filter será usada como padrão caso nenhuma tabela seja especificada através
da opção -t.
O comando iptables -L INPUT -n tem o mesmo efeito, a diferença é que são mostrados
números ao invés de nomes:
#iptables -L INPUT -n
#iptables -L INPUT -n -v
Chain INPUT (policy ACCEPT 78 packets, 5820 bytes)
pkts bytes target prot opt in out source destinatio
2 194 DROP icmp -- * * 0.0.0.0/0 127.0.0.1
chain INPUT será automaticamente apagada (confira listando o chain com a opção “-L”).
Caso o chain possua várias regras semelhantes, somente a primeira será apagada. OBS:
Não é possível apagar os chains defaults do iptables (INPUT, OUTPUT. . . ).
Precisamos que o tráfego vindo de 192.168.1.15 não seja rejeitado pelo nosso firewall. Não
podemos adicionar uma nova regra (-A) pois esta seria incluída no final do chain e o tráfego
seria rejeitado pela primeira regra (nunca atingindo a segunda). A solução é inserir a nova
regra antes da regra que bloqueia todo o tráfego ao endereço 127.0.0.1 na posição 1:
iptables -t filter -I INPUT 1 -s 192.168.1.15 -d 127.0.0.1 -j ACCEPT
Após este comando, temos a regra inserida na primeira posição do chain (repare no número
1 após INPUT) e a antiga regra número 1 passa a ser a número 2. Desta forma a regra acima
será consultada, se a máquina de origem for 192.168.1.15 então o tráfego estará garantido, caso
contrário o tráfego com o destino 127.0.0.1 será bloqueado na regra seguinte.
Após criar nossa regra, percebemos que a nossa intenção era somente bloquear os pings com
o destino 127.0.0.1 (pacotes ICMP) e não havia necessidade de bloquear todo o tráfego da
máquina. Existem duas alternativas: apagar a regra e inserir uma nova no lugar ou modificar
diretamente a regra já criada sem afetar outras regras existentes e mantendo a sua ordem no
chain (isso é muito importante). Use o seguinte comando:
iptables -R INPUT 2 -d 127.0.0.1 -p icmp -j DROP
O número 2 é o número da regra que será substituída no chain INPUT, e deve ser especificado.
O comando acima substituirá a regra 2 do chain INPUT (-R INPUT 2) bloqueando (-j DROP)
qualquer pacote icmp (-p icmp) com o destino 127.0.0.1 (-d 127.0.0.1).
Em firewalls organizados com um grande número de regras, é interessante criar chains in-
dividuais para organizar regras de um mesmo tipo ou que tenha por objetivo analisar um
tráfego de uma mesma categoria (interface, endereço de origem, destino, protocolo, etc) pois
podem consumir muitas linhas e tornar o gerenciamento do firewall confuso (e conseqüente-
mente causar sérios riscos de segurança). O tamanho máximo de um nome de chain é de 31
caracteres e podem conter tanto letras maiúsculas quanto minúsculas.
iptables [-t tabela] [-N novochain]
Para criar o chain internet (que pode ser usado para agrupar as regras de internet) usamos o
seguinte comando:
Para inserir regras no chain internet basta especifica-lo após a opção -A:
‘INPUT’ ‘internet’
---------------------------- -----------------------------
| Regra1: -s 192.168.1.15 | | Regra1: -s 200.200.200.200|
|--------------------------| |---------------------------|
| Regra2: -s 192.168.1.1 | | Regra2: -d 192.168.1.1 |
|--------------------------| -----------------------------
| Regra3: -j DROP |
----------------------------
_______________________________________
v / v
/-------------------------|-\ / /-------------------------------------|-\
| Regra1: -s 192.168.1.15 | | / | Regra1: -s 200.200.200.200 -j DROP \___
|-------------------------|-| / |---------------------------------------|
| Regra2: -s 192.168.1.1 | | / | Regra2: -d 200.200.200.202 -j DROP |
|-------------------------|-|/ \---------------------------------------/
| Regra3: -j internet /|
|---------------------------| No chain internet, a primeira regra confe
| Regra4: -j DROP | com o endereço de origem 200.200.200.200
\---------------------------/ o pacote é bloqueado.
Se por algum motivo precisar renomear um chain criado por você na tabela filter, nat ou mangle,
isto poderá ser feito usando a opção -E do iptables:
Use o comando cat /proc/net/ip_tables_names para fazer isto. É interessante dar uma
olhada nos arquivos dentro do diretório /proc/net, pois os arquivos existentes podem lhe
interessar para outras finalidades.
chain Chain que desejamos limpar. Caso um chain não seja especificado, todos os chains da
tabela serão limpos.
Este comando zera o campo pkts e bytes de uma regra do iptables. Estes campos podem ser
visualizados com o comando iptables -L -v. A seguinte sintaxe é usada:
iptables [-t tabela] [-Z chain] [-L]
Onde:
tabela Nome da tabela que contém o chain que queremos zerar os contadores de bytes e pa-
cotes.
chain Chain que deve ter os contadores zerados. Caso não seja especificado, todos os chains da
tabela terão os contadores zerados. Note que as opções -Z e -L podem ser usadas juntas,
assim o chain será listado e imediatamente zerado. Isto evita a passagem de pacotes
durante a listagem de um chain.
A política padrão determina o que acontecerá com um pacote quando ele chegar ao final das
regras contidas em um chain. A política padrão do iptables é “ACCEPT” mas isto pode ser
alterado com o comando:
Capítulo 10. Firewall iptables 124
# iptables -L INPUT
No exemplo acima, a política padrão de INPUT é ACCEPT (policy ACCEPT), o que significa
que qualquer pacote que não seja rejeitado pela regra do chain, será aceito. Para alterar a
política padrão deste chain usamos o comando:
+---------------------+--------------------------------+
TABELA | CHAIN | INTERFACE |
| +----------------+---------------+
| | ENTRADA (-i) | SAÍDA (-o) |
+---------+---------------------+----------------+---------------+
| | INPUT | SIM | NÃO |
| filter | OUTPUT | NÃO | SIM |
| | FORWARD | SIM | SIM |
+---------+---------------------+----------------+---------------+
| | PREROUTING | SIM | NÃO |
| nat | OUTPUT | NÃO | SIM |
| | POSTROUTING | NÃO | SIM |
+---------+---------------------+----------------+---------------+
| | PREROUTING | SIM | NÃO |
| mangle | | | |
| | OUTPUT | NÃO | SIM |
+---------+---------------------+----------------+---------------+
O caminho do pacote na interface será determinado pelo tipo da interface e pela posição dos
chains nas etapas de seu roteamento. O chain OUTPUT da tabela filter somente poderá conter
a interface de saída (veja a tabela acima). O chain FORWARD da tabela filter é o único que
aceita a especificação de ambas as interfaces, este é um ótimo chain para controlar o tráfego
que passa entre interfaces do firewall.
Por exemplo para bloquear o acesso do tráfego de qualquer máquina com o endereço
200.123.123.10 vinda da interface ppp0 (uma placa de fax-modem):
Capítulo 10. Firewall iptables 126
O sinal de “+” funciona como um coringa, assim a regra terá efeito em qualquer interface de
ppp0 a ppp9. As interfaces ativas no momento podem ser listadas com o comando ifconfig,
mas é permitido especificar uma regra que faz referência a uma interface que ainda não existe,
isto é interessante para conexões intermitentes como o PPP. Para bloquear qualquer tráfego
local para a Internet:
Para bloquear a passagem de tráfego da interface ppp0 para a interface eth1 (de uma de nossas
redes internas):
A opção -p (ou –protocol) é usada para especificar protocolos no iptables. Podem ser es-
pecificados os protocolos tcp, udp e icmp. Por exemplo, para rejeitar todos os pacotes UDP
vindos de 200.200.200.200:
As portas de origem/destino devem ser especificadas após o protocolo e podem ser precedidas
por uma das seguintes opções:
• --source-port ou --sport - Especifica uma porta ou faixa de portas de origem.
• --destination-port ou --dport - Especifica uma porta ou faixa de portas de des-
tino.
Uma faixa de portas pode ser especificada através de PortaOrigem:PortaDestino:
Caso a PortaOrigem de uma faixa de portas não seja especificada, 0 é assumida como padrão,
caso a Porta Destino não seja especificada, 65535 é assumida como padrão. Caso precise es-
pecificar diversas regras que envolvam o tratamento de portas diferentes, recomendo da uma
olhada em ‘Especificando múltiplas portas de origem/destino’ on page 143, antes de criar um
grande número de regras.
O protocolo ICMP não possui portas, mas é possível fazer um controle maior sobre o tráfego
ICMP que entra/sai da rede através da especificação dos tipos de mensagens ICMP. Os tipos
de mensagens devem ser especificados com a opção “–icmp-type CódigoICMP” logo após a
especificação do protocolo icmp:
A regra acima rejeitará mensagens ICMP do tipo “time-exceeded” (tempo de requisição exce-
dido) que venham do endereço 200.123.123.10 através da interface ppp+.
Alguns tipos de mensagens ICMP são classificados por categoria (como o próprio “time-
exceeded”), caso a categoria “time-exceeded” seja especificada, todas as mensagens daquela
categoria (como “ttl-zero-during-transit”, “ttl-zero-during-reassembly”) conferirão na regra es-
pecificada.Os tipos de mensagens ICMP podem ser obtidos com o comando iptables -p
icmp -h:
echo-reply (pong)
destination-unreachable
network-unreachable
host-unreachable
protocol-unreachable
port-unreachable
fragmentation-needed
source-route-failed
network-unknown
host-unknown
network-prohibited
host-prohibited
TOS-network-unreachable
TOS-host-unreachable
communication-prohibited
host-precedence-violation
precedence-cutoff
source-quench
redirect
network-redirect
host-redirect
Capítulo 10. Firewall iptables 128
TOS-network-redirect
TOS-host-redirect
echo-request (ping)
router-advertisement
router-solicitation
time-exceeded (ttl-exceeded)
ttl-zero-during-transit
ttl-zero-during-reassembly
parameter-problem
ip-header-bad
required-option-missing
timestamp-request
timestamp-reply
address-mask-request
address-mask-reply
Pacotes syn são usados para iniciarem uma conexão, o uso da opção –syn serve para especificar
estes tipos de pacotes. Desta maneira é possível bloquear somente os pacotes que iniciam uma
conexão, sem afetar os pacotes restantes. Para que uma conexão ocorra é necessário que a
máquina obtenha a resposta a pacotes syn enviados, caso ele seja bloqueado a resposta nunca
será retornada e a conexão não será estabelecida.
A regra acima bloqueia (-j DROP) qualquer tentativa de conexão (–syn) vindas da interface
ppp+ ao telnet (–dport 23) da máquina local, conexões já efetuadas ão são afetadas por esta
regra. A opção –syn somente pode ser especificada para o protocolo tcp.
ATENÇÃO: - A situação de passagem de pacotes durante deve ser levada em conta durante
a inicialização do firewall, bloqueando a passagem de pacotes durante o processo de configu-
ração, criando regras que bloqueiam a passagem de pacotes (exceto para a interface loopback)
até que a configuração do firewall esteja completa, pode ser uma solução eficiente.
Outra alternativa segura é configurar as regras de firewall antes das interfaces de rede se
tornarem ativas (usando a opção “pre-up comando_firewall” no arquivo de configuração /etc
/network/interfaces em sistemas Debian.
Capítulo 10. Firewall iptables 129
A opção “-f” (ou –fragment) permite especificar regras que confiram com fragmentos. Frag-
mentos são simplesmente um pacote maior dividido em pedaços para poder ser transmitido
via rede TCP/IP para remontagem do pacote pela máquina de destino.
Somente o primeiro fragmento possui detalhes de cabeçalho para ser processado, os segundos
e seguintes somente possuem alguns cabeçalhos necessários para dar continuidade ao processo
de remontagem do pacote no destino.
Uma regra como
Diz para rejeitar todos os pacotes EXCETO os que vem do endereço 200.200.200.10.
Diz para bloquear todos os pacotes EXCETO os que iniciam conexões (! –syn), EXCETO para
pacotes vindos pela interface eth0 (! -i eth0).
O alvo (-j) é o destino que um pacote terá quando conferir com as condições de uma regra, um
alvo pode dizer para bloquear a passagem do pacote (-j DROP), aceitar a passagem do pacote
(-j ACCEPT), registrar o pacote no sistema de log (-j LOG), rejeitar o pacote (-j REJECT), redi-
recionar um pacote -j REDIRECT, retornar ao chain anterior sem completar o processamento
no chain atual (-j RETURN), passar para processamento de programas externos (-j QUEUE),
fazer source nat (-j SNAT), destination nat (-j DNAT), etc. Podem existir mais alvos, pois o
iptables é modularizável, e módulos que acrescentam mais funções podem ser carregados
em adição aos já existentes no kernel.
Nos exemplos anteriores vimos o uso de diversos alvos como o DROP e o ACCEPT. Apenas
farei uma breve referência sobre os alvos mais usados em operações comuns dos chains. Os
alvos REDIRECT, SNAT e DNAT serão explicados em uma seção seguinte:
ACCEPT O pacote é ACEITO e o processamento das regras daquele chains é concluído. Pode
ser usado como alvo em todos os chains de todas as tabelas do iptables e também pode
ser especificado na política padrão das regras do firewall (veja ‘Especificando a política
padrão de um chain - P’ on page 123).
DROP Rejeita o pacote e o processamento das regras daquele chain é concluído. Pode ser
usado como alvo em todos os chains de todas as tabelas do iptables e também pode
ser especificado na política padrão das regras do firewall (veja ‘Especificando a política
padrão de um chain - P’ on page 123).
REJECT Este é um módulo opcional que faz a mesma função do alvo DROP com a diferença
de que uma mensagem ICMP do tipo “icmp-port-unreachable” (TCP/UDP) ou “host-
unreachable” (ICMP) é retornada para a máquina de origem. Pode ser usado como alvo
somente nos chains da tabela (não como política padrão).
LOG Este módulo envia uma mensagem ao syslog caso a regra confira, o processamento
continua normalmente para a próxima regra (o pacote não é nem considerado ACEITO
ou REJEITADO).
RETURN Retorna o processamento do chain anterior sem processar o resto do chain atual.
QUEUE Passa o processamento para um programa a nível de usuário.
Alvo REJECT
Para ser usado, o módulo ipt_REJECT deve ser compilado no kernel ou como módulo.
Este alvo rejeita o pacote (como o DROP) e envia uma mensagem ICMP do tipo “icmp-port-
unreachable” como padrão para a máquina de origem.
É um alvo interessante para bloqueio de portas TCP, pois em alguns casos da a impressão que
a máquina não dispõe de um sistema de firewall (o alvo DROP causa uma parada de muito
tempo em alguns portscanners e tentativas de conexão de serviços, revelando imediatamente
o uso de um sistema de firewall pela máquina). O alvo REJECT vem dos tempos do ipchains
e somente pode ser usado na tabela filter. Quando um pacote confere, ele é rejeitado com a
mensagem ICMP do tipo “port unreachable”, é possível especificar outro tipo de mensagem
ICMP com a opção –reject-with tipo_icmp.
Capítulo 10. Firewall iptables 131
OBS: REJECT pode ser usado somente como alvo na tabela filter e não é possível especifica-lo
como política padrão do chain filter (como acontecia no ipchains. Uma forma alternativa
é inserir como última regra uma que pegue todos os pacotes restantes daquele chain e tenha
como alvo REJECT (como iptables -A INPUT -j REJECT), desta forma ele nunca atin-
girá a política padrão do chain.
Este alvo é usado para registrar a passagem de pacotes no syslog do sistema. É um alvo muito
interessante para ser usado para regras que bloqueiam determinados tráfegos no sistema (para
que o administrador tome conhecimento sobre tais tentativas), para regras de fim de chain
(quando você tem um grande conjunto de regras em um firewall restritivo e não sabe onde
suas regras estão sendo bloqueadas), para satisfazer sua curiosidade, etc.
Note que no exemplo anterior a regra que registra o pacote (-j LOG) deve aparecer antes da
regra que REJEITA (-j REJECT), caso contrário a regra de LOG nunca funcionará. A regra que
REJEITA poderia também ser trocada por uma regra que ACEITA, caso queira registrar um
pacote que deve ser aceito (se a política padrão do seu firewall for restritiva (-P DROP). A
única coisa que muda nas regras de log é o alvo da regra, isto facilita a implementação de
grandes conjuntos de regras de firewall.
A regra acima mostrará a seguinte saída no syslog do sistema:
Agora você sabe o que aconteceu com o pacote (Rejeitado). A padronização de mensagens de
firewall é também importante para a criação de scripts de análise que poderão fazer a análise
dos logs do seu firewall (para criação de estatísticas que podem servir como base para a criação
de novas regras de firewall ou eliminação de outras).
OBS: Se você sente falta da função “-l” do ipchains que combina o alvo e log na mesma regra
você pode criar um alvo como o seguinte:
iptables -N log-drop
iptables -A log-drop -j LOG
iptables -A log-drop -j DROP
E usar “log-drop” como alvo em suas regras. Mesmo assim esta solução é “limitada” em re-
lação a “-l” do ipchains porque o iptables não inclui detalhes de qual chain bloqueou o
pacote/qual pacote foi bloqueado, assim é necessário a especificação da opção –log-prefix para
as mensagens se tornarem mais compreensíveis. Esta limitação pode ser contornada utilizando
um firewall feito em linguagem shell script, desta forma você terá um controle maior sobre o
seu programa usando funções e integração com outros utilitários.
Quando um pacote com o endereço www.debian.org tentando acessar a porta www (80)
de nossa máquina através da internet (via interface ppp0), o chain número 1 confere, então o
processamento continua no chain número 4, o chain número 4 confere então o processamento
volta para a regra número 2, que diz para aceitar o pacote.
Agora se um pacote vem com o endereço www.dominio.com.br tentando acessar a porta
www *80) de nossa máquina através da internet (via interface ppp0), o chain número 1 confere,
então o processamento continua no chain número 4, que não confere. O mesmo acontece com
os chains 5, 6 e 7. O chain número 8 confere, então o acesso é bloqueado.
Como pode notou, o alvo RETURN facilita bastante a construção das regras do seu firewall,
caso existam máquinas/redes que sejam exceções as suas regras. Se ela não existisse, seria
necessário especificar diversas opções -s, -d, etc para poder garantir o acesso livre a determi-
nadas máquinas.
As regras que você está trabalhosamente criando e testando manualmente enquanto manipula
o iptables podem ser salvas de 2 formas; uma delas é escrevendo um shell script que tenha
todos os comandos, um por linha. Isto é recomendado quando tem um firewall grande e que
exige uma boa padronização de regras, bem como sua leitura, comentários. O script shell
também permite o uso de funções presente no interpretador de comando, portanto se você é
uma pessoa que gosta de interagir com as funções do shell e deixar as coisas mais flexíveis,
prefira esta opção.
A outra forma é usando as ferramentas iptables-save e iptables-restore baseada na
idéia do ipchains-save e ipchains-restore. O iptables-save deve ser usado sempre
que modificar regras no firewall iptables da seguinte forma:
iptables-save >/dir/iptables-regras
Uma das vantagens do uso do iptables-save é ele também salvar os contadores de chains,
ou seja, a quantidade de pacotes que conferiram com a regra. Isto também pode ser feito
com algumas regras adicionais em seu shell script, caso tenha interesse nesses contadores para
estatísticas ou outros tipos de relatórios.
Para restaurar as regras salvas, utilize o comando:
iptables-restore </dir/iptables-regras
A tabela nat serve para controlar a tradução dos endereços que atravessam o código de
roteamento da máquina Linux. Existem 3 chains na tabela nat: PREROUTING, OUTPUT e
POSTROUTING (veja ‘O que são tabelas?’ on page 114 para maiores detalhes).
Capítulo 10. Firewall iptables 135
O procedimento para criação de um novo chain nesta tabela é o mesmo descrito em ‘Criando
um novo chain - N’ on page 120 será necessário somente especificar a tabela nat (-t nat) para
que o novo chain não seja criado na tabela padrão (-t filter).
Que criará o chain chamado intra-inter na tabela nat. Para inserir regras neste chain será
necessário especificar a opção “-t nat”.
Você precisará de um kernel com suporte ao iptables (veja ‘Habilitando o suporte ao iptables
no kernel’ on page 115 e ip_forward e então digitar os dois comandos abaixo para habilitar
o masquerading para todas as máquinas da rede 192.168.1.*:
A configuração do servidor Linux está completa, agora os clientes da rede precisarão ser
configurados para usar o endereço IP do servidor Linux como gateway. É recomendável
instalar um servidor proxy e DNS na máquina Linux para acelerar o desempenho das req-
uisições/resolução de nomes das máquinas em rede. A utilização de bits TOS também pode
trazer um grande aumento de velocidade para os diferentes serviços da rede (veja ‘Especifi-
cando o tipo de serviço’ on page 139).
Capítulo 10. Firewall iptables 136
SNAT (source nat - nat no endereço de origem) consiste em modificar o endereço de origem
das máquinas clientes antes dos pacotes serem enviados. A máquina roteadora é inteligente
o bastante para lembrar dos pacotes modificados e reescrever os endereços assim que obter a
resposta da máquina de destino, direcionando os pacotes ao destino correto. Toda operação de
SNAT é feita no chain POSTROUTING.
É permitido especificar endereços de origem/destino, protocolos, portas de origem/destino,
interface de entrada/saída (dependendo do chain), alvos, etc. É desnecessário especificar frag-
mentos na tabela nat, pois eles serão remontados antes de entrar no código de roteamento.
O SNAT é a solução quando você tem acesso a internet através de um único IP e deseja fazer
que sua rede tenha acesso a Internet através da máquina Linux. Nenhuma máquina da Inter-
net poderá ter acesso direto as máquinas de sua rede interna via SNAT.
OBS: A observação acima não leva em conta o controle de acesso externo configurado na
máquina que estiver configurando o iptables, uma configuração mau realizada pode ex-
por sua máquina a acessos externos indesejados e comprometer sua rede interna caso alguém
consiga acesso direto ao servidor.
É necessário especificar SNAT como alvo (-j SNAT) quando desejar que as máquinas de sua
rede interna tenha acesso a Internet através do IP fixo da máquina Linux (para conexões inter-
mitentes como PPP, veja ‘Fazendo IP Masquerading’ on the facing page). O parâmetro --to
IP:portas deve ser usado após o alvo SNAT. Ele serve para especificar um endereço IP, faixa
de endereços e opcionalmente uma porta ou faixa de portas que será substituída. Toda a oper-
ação de SNAT é realizada através do chain POSTROUTING:
Os pacotes indo para a Internet (nossa conexão é feita via eth1, nossa interface externa) vindo
do endereço 192.168.1.2, são substituídos por 200.241.200.40 e enviados para fora. Quando a
resposta a requisição é retornada, a máquina com iptables recebe os pacotes e faz a oper-
ação inversa, modificando o endereço 200.241.200.40 novamente para 192.168.1.2 e enviando
a resposta a máquina de nossa rede interna. Após definir suas regras de NAT, execute o co-
mando echo “1” >/proc/sys/net/ipv4/ip_forward para habilitar o suporte a redire-
cionamento de pacotes no kernel.
Também é possível especificar faixas de endereços e portas que serão substituídas:
Modifica o endereço IP de origem de todas as máquinas da rede 192.168.1.0/24 que tem o des-
tino a interface eth0 para 200.241.200.40 a 200.241.200.50. O endereço IP selecionado é escolhido
de acordo com o último IP alocado.
Capítulo 10. Firewall iptables 137
Idêntico ao anterior, mas faz somente substituições na faixa de portas de origem de 1 a 1023.
Fazendo IP Masquerading
O IP Masquerading é um tipo especial de SNAT usado para conectar a sua rede interna a
internet quando você recebe um IP dinâmico de seu provedor (como em conexões ppp). Todas
as operações de IP Masquerading são realizadas no chain POSTROUTING. Se você tem um IP
fixo, deve ler ‘Fazendo SNAT’ on the preceding page.
Para fazer IP Masquerading de uma máquina com o IP 192.168.1.2 para ter acesso a Internet,
use o comando:
Após definir a regra para fazer Masquerading (SNAT), execute o comando echo “1”
>/proc/sys/net/ipv4/ip_forward para habilitar o suporte a redirecionamento de pa-
cotes no kernel.
Capítulo 10. Firewall iptables 138
Também é possível especificar faixas de endereços e portas que serão substituídas no DNAT:
Idêntico ao anterior, mas faz somente substituições na faixa de portas de destino de 1024 a
5000. A operação acima é a mesma realizada pelo ipmasqadm dos kernels da série 2.2.
OBS1: Se por algum motivo não for possível mapear uma conexão NAT, ela será derrubada.
OBS2: Não se esqueça de conferir se o ip_forward está ajustado para 1: echo “1”
>/proc/sys/net/ipv4/ip_forward.
Redirecionamento de portas
O redirecionamento de portas permite a você repassar conexões com destino a uma porta para
outra porta na mesma máquina. O alvo REDIRECT é usado para fazer esta operação, junto com
o argumento –to-port especificando a porta que será redirecionada. Este é o método DNAT es-
pecífico para se para fazer proxy transparente (para redirecionamento de endereços/portas,
veja ‘Fazendo DNAT’ on this page). Todas as operações de redirecionamento de portas é real-
izada no chain PREROUTING e OUTPUT da tabela nat.
Redireciona as conexões indo para a porta 80 para a porta 81 (rodando squid) no firewall.
ATENÇÃO: O squid possui suporte a proxy transparente, e poderá atender as requisições
acima da regra acima.
Capítulo 10. Firewall iptables 139
A tabela mangle serve para especificar ações especiais para o tratamento do tráfego que atrav-
essa os chains. Nesta tabela existem cincos chains: PREROUTING, POSTROUTING, INPUT,
OUTPUT e FORWARD (veja ‘O que são tabelas?’ on page 114 para maiores detalhes).
Em geral, cada um deste chain é processado antes do chain correspondente na tabela filter e
nat para definir opções especiais para o tráfego (por exemplo, o chain PREROUTING da tabela
mangle é processado antes do PREROUTING da tabela nat). O chain OUTPUT da tablea mangle
corresponde ao OUTPUT da tabela nat. Opções como o Tipo de Serviço (TOS) é especificado
nesta tabela para classificar e aumentar consideravelmente a velocidade de tráfego consid-
erados em tempo real. Mesmo após o tráfego ser estabelecido, os chains da tabela mangle
continuam ativos para garantir que as opções especiais relacionadas com a conexão continuem
fazendo efeito (veja os exemplos de ‘Caminho percorrido pelos pacotes nas tabelas e chains’
on page 147).
O tipo de serviço é um campo existente no cabeçalho de pacotes do protocolo ipv4 que tem a
função especificar qual é a prioridade daquele pacote. A prioridade é definida usando o algo-
ritmo FIFO do próprio kernel, sendo uma das alternativas de controle/priorização de tráfego
das mais simples e rápidas.
Uma das vantagens da utilização do tipo de serviço é dar prioridade ao tráfego de pacotes
interativos (como os do ICQ, IRC, servidores de chat), etc. Com o TOS especificado, mesmo
que esteja fazendo um download consumindo toda a banda de sua interface de rede, o tráfego
com prioridade interativa será enviado antes, aumentando a eficiência do uso de serviços em
sua máquina.
Em testes realizados em minha conexão de 56K, o uso de regras TOS aumentou bastante o de-
sempenho em tráfego interativo (em torno de 300%), durante o uso total da banda da interface
ppp em grande consumo de banda.
Usamos o alvo TOS (-j TOS) para especificar a modificação do tipo de serviço nos pacotes que
atravessam as regras do firewall, acompanhada do argumento –set-tos TOS que define a nova
prioridade dos pacotes. Os valores aceitos são os seguintes:
Espera Mínima É especificado através de Minimize-Delay, 16 ou 0x10
Máximo Processamento É especificado através de Maximize-Throughput, 8, ou 0x08.
Máxima Confiança É especificado através de Maximize-Reliability, 4 ou 0x04.
Custo mínimo Especificado através de Minimize-Cost, 2 ou 0x02.
Prioridade Normal Especificado através de Normal-Service, 0 ou 0x00.
Capítulo 10. Firewall iptables 140
Os pacotes vem por padrão com o valor TOS ajustado como prioridade normal (bits tos ajus-
tados para 0x00). O tipo Mínima Espera é o de maior prioridade, recomendado para tráfego
interativo.
Este é o mais usado, pois prioriza o tráfego que sai da máquina (com destino a Internet, por
exemplo). Sua operação é realizada através do chain OUTPUT ou POSTROUTING.
Para priorizar todo o tráfego de IRC de nossa rede interna indo para a interface ppp0:
O bit TOS é ajustado para Espera mínima e será enviado antes dos pacotes com prioridade
normal para fora. Para priorizar a transmissão de dados ftp saindo da rede:
Existem muitas outras otimizações que podem ser feitas, só depende dos requerimentos e
análise de cada serviço da rede pelo administrador.
OBS: - Os pacotes que atravessam o alvo TOS somente tem os bits tipo do serviço modificados,
eles não serão de qualquer forma rejeitados.
Este prioriza o tráfego que entra da máquina. Sua operação é realizada no chain INPUT ou
PREROUTING. Não faz muito sentido o uso deste chain dentro de uma rede pequena/média,
pois o tráfego que recebermos será priorizado pelo chain de saída de outras máquinas da in-
ternet/outras redes antes de chegar a nossa (desde que elas também estejam usando TOS).
Para priorizar o processamento do tráfego interativo vindo de servidores IRC para nossa rede:
Modifica o tipo de serviço para mínima espera de todo o tráfego enviado por servidores de IRC
vindo da interface eth0.
OBS: - Os pacotes que atravessam o alvo TOS somente tem os bits tipo do serviço modificados,
eles não serão de qualquer forma rejeitados. \
Capítulo 10. Firewall iptables 141
Os módulos do iptables são especificados com a opção -m módulo ou –match módulo e permitem
expandir a funcionalidade do firewall através de novas conferências e recursos de filtragem
adicionais, como limitar a conferência de regras do firewall (um método útil de limitar ping
floods, syn floods, etc).
Este módulo permite especificar regras de acordo com o estado da conexão do pacote, isto
é feito através da interpretação da saída do módulo ip_conntrack. O parâmetro –state
OPÇÕES deve acompanhar este módulo. As opções permitidas são as seguintes:
• RELATED - Confere com pacotes relacionados indiretamente a uma conexão, como men-
sagens de erro icmp, etc.
• INVALID - Confere com pacotes que não puderam ser identificados por algum motivo.
Como respostas de conexões desconhecidas.
Caso seja necessário especificar mais de uma opções estas devem ser separadas por vírgulas.
A opção -m limit permite especificar o número de vezes que uma regra conferirá quando todas
as outras condições forem satisfeitas. O número padrão de conferência é de 3 por hora, a não
ser que seja modificado através dos argumentos aceitos pelo limit:
– h - Hora
– d - Dia
Assim uma regra como iptables -A INPUT -m limit --limit 5/m -j
ACCEPT permitirá que a regra acima confira apenas 5 vezes por minuto (–limit
2/s). Este limite pode ser facilmente adaptado para uma regra de log que confere
constantemente não causar uma avalanche em seus logs. O valor padrão é 3/h.
• --limit-burst num - Especifica o número inicial máximo de pacotes que irão conferir,
este número é aumentado por 1 a cada vez que o parâmetro –limit acima não for atingido.
O valor padrão é 5.
A regra abaixo pode tomada como base para proteção contra ping flood:
A regra acima limita em 1 vez por segundo (–limit 1/s) a passagem de pings (echo requests)
para a máquina Linux.
Limita respostas a pings (echo reply) vindos da interface ppp0 (-i ppp0) a 1 por segundo.
ATENÇÃO: O exemplo acima é somente para a criação de suas próprias regras com limitações,
caso um pacote não confira ele será bloqueado pela próxima regra. Se uma regra como esta for
colocada no chain INPUT sem modificações, ela não terá o efeito desejado, podendo colocar
em risco a sua instalação pela falsa impressão de segurança. Portanto, é recomendável sempre
testar as modificações para ter certeza que elas tem efeito.
servidores que possuem um grande número de acessos para não ter problemas que afetem seu
clientes.
ATENÇÃO: Os exemplos acima devem são somente exemplos para criação de suas próprias
regras com limitações, caso um pacote não confira com a regra ele será bloqueado pela próxima
regra. Se uma regra como esta for colocada no chain INPUT sem modificações, ela não terá o
efeito desejado, podendo colocar em risco a sua instalação pela falsa impressão de segurança.
Portanto, é recomendável sempre testar as modificações para ter certeza que elas tem efeito.
A especificação de endereços de origem/destino junto com a interface de rede pode ser usado
como um detector de ataques spoofing. A lógica é que todos os endereços que NUNCA devem
vir da interface X devem ser negados imediatamente. As regras abaixo são colocadas no inicio
do chain INPUT para detectar tais ataques:
A primeira regra diz para bloquear todos os endereços da faixa de rede 192.168.1.* que NÃO
vem da interface eth0, a segunda regra diz para bloquear todos os endereços que não sejam
192.168.1.* vindos da interface eth0. O símbolo “!” serve para especificar exceções (veja ‘Es-
pecificando uma exceção’ on page 129. O kernel do Linux automaticamente bloqueia a pas-
sagem de pacotes que dizem ser de 127.0.0.1 e não está vindo da interface loopback.
O método preferido para controlar o ip spoofing é através do código de roteamento do kernel
(a não ser que esteja usando algum tipo de roteamento de origem assimétrico necessário por
alguns programas especiais):
for i in /proc/sys/net/ipv4/conf/*/rp_filter; do
echo 1 >$i
done
Desta forma qualquer endereço dizendo ser 192.168.1.5 vindo de ppp0 será imediatamente
rejeitado. Uma checagem adicional contra IP spoofing pode ser feita no arquivo /etc
/host.conf (veja ‘/etc/host.conf’ on page 50).
O módulo multiport permite que seja especificado múltiplas portas para um alvo. Podem
ser especificadas até 15 portas em um único parâmetro e basta que uma porta confira para
que a regra entre em ação, pois a comparação é feita usando condições “or”. O parâmetro
multiport deve ser acompanhado de um dos argumentos abaixo:
Capítulo 10. Firewall iptables 144
Bloqueia todos os pacotes vindo de ppp0 para as portas 21 (ftp), 23 (telnet), 25 (smtp), 80
(www), 110 (pop3), 113 (ident), 6667 (irc).
O módulo mac serve para conferir com o endereço Ethernet dos pacotes de origem. Somente
faz sentido se usado nos chains de PREROUTING (da tabela nat) ou INPUT (da tabela filter).
Aceita como argumento a opção –mac-source endereço. O símbolo “!” pode ser usado para
especificar uma exceção.
Este módulo confere com o usuário que iniciou a conexão. É somente válido no chain OUTPUT
da tabela filter. Os seguintes argumentos são válidas para este módulo:
• --uid-owner UID - Confere se o pacote foi criado por um processo com o UID especi-
ficado. Até o momento somente UID numéricos são aceitos.
• --gid-owner GID - Confere se o pacote foi criado por um usuário pertencente ao grupo
GID. Até o momento somente GID numéricos são aceitos.
• --pid-owner PID - Confere se o pacote foi criado por um processo com o PID especi-
ficado.
OBS: - Lembre-se que pacotes que não possuem detalhes suficientes de cabeçalho nunca con-
ferirão!
Capítulo 10. Firewall iptables 145
Rejeita um conexões indo para portas UDP de pacotes criados pelo usuários pertencentes ao
grupo 100.
# Não permite que dados confidenciais sejam enviados para fora da empresa
# e registra o ocorrido.
iptables -A OUTPUT -m string --string "conta" -j LOG --log-prefix "ALERTA: dad
iptables -A OUTPUT -m string --string "conta" -j DROP
# Somente permite a passagem de pacotes que não contém ".exe" em seu conteúdo
iptables -A INPUT -m string --string ! ".exe" -j ACCEPT
O módulo ttl pode ser usado junto com as seguintes opções para conferir com o tempo de
vida (TTL) de um pacote:
• --ttl-eq [num]
• --ttl-lt [num]
• --ttl-gq [num]
Capítulo 10. Firewall iptables 146
# Confere com todos os pacotes que tem o TTL maior que 100
iptables -A INPUT -m ttl --ttl-gt 100 -j LOG --log-prefix "TTL alto"
OBS: Tenha um especial cuidado durante a programação de regras que usem TTL, como elas
estão especialmente associadas com o estado da comunicação estabelecida entre as duas pon-
tas e o tipo de protocolo, cuidados especiais devem ser tomados para que seu firewall não
manipule de forma incorreta tráfego válido.
O módulo rpc permite um controle especial sobre o tráfego RPC que chega até a sua máquina.
Um uso útil é restringir a chamada a determinados números RPC e permitir outros (por exem-
plo, permitindo somente o serviço keyserv e bloqueando outros como o ypserv ou portmapper).
As seguintes opções podem ser usadas com o módulo nfs:
• --rpcs [procedimentos] - Confere com a lista de chamadas RPC especificadas.
Mais de um procedimento RPC pode ser especificado como nome ou número separando-
os com vírgulas. Um arquivo útil que contém esta lista é o /etc/rpc.
• --strict - Ignora serviços RPC que não contenham a chamada get do portmapper. Em
situações normais, o inicio de qualquer solicitação RPC.
Veja alguns exemplos:
O módulo pkttype permite identificar um pacote do tipo unicast (direcionado a você), broad-
cast (direcionado a uma determinada rede, definida pela netmask) ou multicast (destinado a
grupos de redes) e desta forma realizar ações em cima destes. O tipo de pacote é identificado
logo após a opção –pkt-type. Veja alguns exemplos:
# Como deve ter notado, é possível fazer a associação com diversas especificaç
# de módulos, bastando apenas especificar uma opção "-m" para cada módulo
# adicional:
# Permite a passagem de pacotes broadcast de uma rede para outra com
# limitação de 5/s.
iptables -A FORWARD -i eth0 -o eth0 -m pkttype --pkt-type broadcast -m limit -
O tamanho do pacote pode ser usado como condição de filtragem através do módulo length.
O tamanho do pacote é especificado através da opção –length e o argumento segue a mesma
sintaxe da especificação de portas no iptables sendo separados por :. Veja alguns exemplos:
É MUITO importante entender a função de cada filtro e a ordem de acesso dos chains de acordo
com o tipo de conexão e interface de origem/destino. Esta seção explica a ordem que as regra
são atravessadas, isso lhe permitirá planejar a distribuição das regras nos chains, e evitar erros
de localização de regras que poderia deixar seu firewall com sérios problemas de segurança,
ou um sistema de firewall totalmente confuso e sem lógica.
Nos exemplos abaixo assumirei a seguinte configuração:
• A máquina do firewall com iptables possui o endereço IP 192.168.1.1 e conecta a
rede interna ligada via interface eth0 a internet via a interface ppp0.
• Rede interna com a faixa de endereços 192.168.1.0 conectada ao firewall via interface
eth0
• Interface ppp0 fazendo conexão com a Internet com o endereço IP 200.217.29.67.
• A conexão das máquinas da rede interna (eth0) com a rede externa (ppp0) é feita via
Masquerading.
Também utilizarei a sintaxe CHAIN-tabela para fazer referência aos chains e tabelas dos blocos
ASCII: INPUT-filter - chain INPUT da tabela filter.
ATENÇÃO: A ordem de processamento das regras do iptables, é diferente do ipchains
devido a inclusão do novo sistema de nat e da tabela mangle.
Quando damos o ping (echo request) os pacotes seguem o caminho em SAÍDA DE PACOTES
percorrendo os chains na ordem especificada e retornam via ENTRADA DOS PACOTES (echo
reply). No envio da resposta da requisição de ping, o caminho de saída do pacote ignora os
chains OUTPUT-nat e POSTROUTING-nat (já que não é necessário nat) mas sempre processa
os chains correspondentes da tabela mangle na ordem indicada acima.
OBS1: Para conexões com destinos na própria máquina usando um endereço IP das interfaces
locais, a interface será ajustada sempre para lo (loopback).
OBS2: Em qualquer operação de entrada/saída de pacotes, os dois chains da tabela mangle são
sempre os primeiros a serem acessados. Isto é necessário para definir a prioridade e controlar
outros aspectos especiais dos pacotes que atravessam os filtros.
OBS3: O chain OUTPUT da tabela filter é consultado sempre quando existem conexões se
originando em endereços de interfaces locais.
A requisição ftp passa através dos chains especificados em SAÍDA DOS PACOTES e retorna por
ENTRADA DE PACOTES. Após a conexão ser estabelecida, o caminho de SAÍDA DE PACOTES
será:
pois os dados de entrada que vem da interface externa, são passados diretamente a máquina do
firewall, não necessitando de tratamento SNAT (os chains OUTPUT-nat e POSTROUTING-nat
são processado somente uma vez a procura de regras que conferem, principalmente para fazer
SNAT). Note novamente que mesmo não sendo necessário NAT, o chain POSTROUTING-
mangle é checado.
OBS1: Para conexões com destinos na própria máquina usando um endereço IP das interfaces
locais, a interface será ajustada sempre para lo (loopback).
OBS2: Em qualquer operação de entrada/saída de pacotes, os dois chains da tabela mangle são
sempre os primeiros a serem acessados. Isto é necessário para definir a prioridade e controlar
outros aspectos especiais dos pacotes que atravessam os filtros.
A requisição ftp passa através dos chains especificados em SAÍDA DOS PACOTES com o des-
tino 192.168.1.4 porta 21 e retorna por ENTRADA DE PACOTES para 192.168.1.1 porta
1405. Após a conexão ser estabelecida, o caminho de SAÍDA DE PACOTES será:
pois os dados não precisam de tratamento SNAT (os chains OUTPUT-nat e POSTROUTING-
nat são processado somente uma vez a procura de regras que conferem, principalmente para
fazer SNAT).
OBS: Em qualquer operação de entrada/saída de pacotes, os dois chains da tabela mangle são
sempre os primeiros a serem acessados. Isto é necessário para definir a prioridade e controlar
outros aspectos especiais dos pacotes que atravessam os filtros.
A requisição ftp passa através dos chains especificados em SAÍDA DOS PACOTES com o des-
tino 200.198.129.162 porta 21 (após a resolução DNS de www.debian.org.br) e retorna
por ENTRADA DE PACOTES para 200.217.29.67 porta 1407. Após a conexão ser estab-
elecida, o caminho de saída de pacotes é:
pois os dados não precisam de tratamento SNAT (os chains OUTPUT-nat e POSTROUTING-
nat são processado somente uma vez a procura de regras que conferem, principalmente para
fazer SNAT).
E após a conexão estabelecida, o caminho de entrada de pacotes passa a ser:
Quando damos o ping (echo request) os pacotes seguem o caminho em ENTRADA DE PACOTES
percorrendo os chains na ordem especificada e retornam via SAÍDA DOS PACOTES (echo reply).
OBS1: Para qualquer operação de entrada/saída de pacotes, os dois chains da tabela man-
gle são sempre os primeiros a serem acessados. Isto é necessário para definir a prioridade e
controlar outros aspectos especiais dos pacotes que atravessam os filtros.
A requisição ftp passa através dos chains especificados em ENTRADA DOS PACOTES com o
destino 192.168.1.1 porta 21 e retorna por SAÍDA DE PACOTES para 192.168.1.4 porta
1030. Após a conexão ser estabelecida, o caminho de entrada de pacotes é:
A requisição ftp passa através dos chains especificados em SAÍDA DOS PACOTES com o des-
tino 200.198.129.162 porta 21 (após a resolução DNS de ftp.debian.org.br) e retorna
por ENTRADA DE PACOTES para 192.168.1.4 porta 1032.
Note que o Masquerading regrava os pacotes; para a máquina 200.198.129.162 a
conexão está sendo feita para 200.217.29.67. As respostas de conexões vindas de
200.198.129.162 e indo para 200.217.29.67 são regravadas no firewall com o destino
192.168.1.4 e enviadas para a máquina correspondente. Após a conexão ser estabelecida, o
caminho de saída de pacotes para 200.198.129.163 é:
Isto acontece porque após feita a conexão Masquerading (via PREROUTING-nat), o firewall
já sabe como reescrever os pacotes para realizar a operação de Masquerading, reescrevendo
todos os pacotes que chegam de www.debian.org.br para 192.168.1.4.
Capítulo 10. Firewall iptables 154
OBS: As conexões Masquerading feitas através da rede interna, são enviadas para
200.198.129.162 tem o endereço de origem ajustado para 200.217.29.67 que é o IP de
nossa interface ppp0. Quando as respostas atravessam o firewall, os pacotes são checados pra
saber se são uma resposta a uma conexão masquerading e fará a regravação dos pacotes sub-
stituindo o endereço de destino para 192.168.1.4. Caso uma operação de Masquerading
falhe, os pacotes serão Bloqueados.
A requisição ftp passa através dos chains especificados em ENTRADA DOS PACOTES com
o destino 200.217.29.67 (nossa interface ppp0 local) porta 21 e retorna por SAÍDA DE
PACOTES para 200.198.129.162 porta 3716 (também via ppp0). Após a conexão ser esta-
belecida, o caminho de entrada de pacotes é:
Isto acontece porque após feita a análise do chain PREROUTING (para necessidade de DNAT),
a máquina já saberá tomar a decisão apropriada para gerenciar aquela conexão.
acima poderão ser facilmente comparados com as etapas abaixo para compreender a estrutura
do iptables.
Exemplo de como bloquear todas as conexões para a máquina do firewall permitindo somente
conexões da máquina Linux para fora.
As regras a seguir servem para bloquear tentativas de conexões da interface de Internet (ppp0)
a sua rede sem bloquear o tráfego de conexões já iniciadas. O tráfego de outras interfaces não
é afetado com as regras a seguir:
Este acima é mais simples e possui o mesmo efeito: Pacotes SYN são usados para ini-
ciar conexões, derrubando pacotes deste tipo significa bloquear novas conexões. Pacotes de
conexões já estabelecidas ainda são permitidos.
Estas regras acima servem para quem não deseja NENHUM acesso indevido a sua máquina.
Existem outras formas de bloquear conexões de modo mais seletivo usando chains específicos,
endereços de origem/destino, portas, etc., este tipo de configuração é muito usada caso precise
fornecer algum tipo de serviço que seja acessível externamente e protegendo outros.
Capítulo 10. Firewall iptables 156
As regras abaixo alertam sobre a tentativa de conexão dos trojans “For Win” mais conhecidos.
Coloquei isto aqui por curiosidade de algumas pessoas, pois máquinas Linux são imunes a
este tipo de coisa:
#!/bin/sh
TROJAN_PORTS="12345 31336 31337 31338 3024 4092 5714 5742 2583 8787 5556 5557"
A primeira linha do iptables cria o chain trojans-in dentro da tabela filter que usaremos para
armazenar nossas regras de firewall. A segunda (dentro do laço for) faz uma regra de LOG
para registrar as tentativas de acesso de trojans em nosso sistema, a terceira rejeita o acesso. A
quarta regra do iptables cria de todo o tráfego vindo da interface ppp0 pra o chain trojans-in
(queremos que só o tráfego vindo da internet seja analisado pelo chain trojans-in).
Muitas das portas especificadas na variável TROJAN_PORTS são antigas conhecidas de quem
já brincou ou sofreram com o Back Orifice, Win Crack, NetBus (quem nunca passou pela
fase de ter uma lista com mais de 100 netmasks e conseguir encontrar centenas de máquinas
por dia infectadas pelo BO? :-).
No código acima a única coisa que precisa fazer para adicionar mais portas é inseri-las na
variável TROJAN_PORTS e executar o programa. O laço do for executará as 2 regras para
cada porta processada (economizando linhas e linhas de regras, me livrando de uma LER e
poupando muitos bytes neste guia ;-).
Dependendo do número de portas alvo, este código pode ser muito simplificado usando o
recurso multiport do iptables (veja ‘Especificando múltiplas portas de origem/destino’ on
page 143 para detalhes).
O seguinte exemplo permite ligar sua rede interna com a faixa de IP’s 192.168.1.* a internet
(usando uma conexão discada do tipo ppp):
Esta seção possui um exemplo mais elaborado de firewall que servirá para máquinas conec-
tadas via ppp com uma rede interna conectada via Masquerading. Este exemplo não é tão
complexo e cobre as expectativas mais comuns de pessoas que gostam de explorar os potenci-
ais de rede no Linux ou satisfazer sua curiosidade. Ele poderá ser facilmente adaptado para
atender outro tipo de necessidade. A configuração assumida é a seguinte:
1 Máquina do firewall com 2 interfaces de rede, uma é eth0 com o IP 192.168.1.1 que
serve de ligação a sua rede Interna, a outra é ppp0 que é a interface Internet.
2 Qualquer acesso externo a máquinas da rede interna é bloqueado.
3 Os usuários da rede local tem acesso livre ao servidor Linux.
4 Qualquer acesso externo a máquina do firewall é bloqueado, exceto conexões para o
serviço Apache (httpd). Outras tentativas de conexões devem ser explicitamente reg-
istradas nos logs do sistema para conhecimento do administrador.
5 Todos os usuários possuem acesso livre a Internet via Masquerading, exceto que o acesso
para o serviço www deve ser obrigatoriamente feito via squid, e o servidor smtp a ser
usado deverá ser o do firewall Linux.
6 Prioridades serão estabelecidas para os serviços de telnet, IRC,talk e DNS.
#!/bin/sh
# Modelo de configuração de firewall
# Autor: Gleydson M. Silva
# Data: 05/09/2001
# Descrição: Produzido para ser distribuído livremente, acompanha o guia
# Foca GNU/Linux. http://www.guiafoca.org
#
# É assumido um sistema usando kmod para carga automática dos módulos usados p
# esta configuração do firewall:
# ipt_filter
# ipt_nat
# ipt_conntrack
# ipt_mangle
# ipt_TOS
# ipt_MASQUERADE
# ipt_LOG
# Se você tem um kernel modularizado que não utiliza o kmod, será necessário
# carregar estes módulos via modprobe, insmod ou iptables --modprobe=modulo
###############################################################
# Tabela filter #
###############################################################
# Primeiro aceitamos o tráfego vindo da Internet para o serviço www (porta 80)
iptables -A ppp-input -p tcp --dport 80 -j ACCEPT
#######################################################
# Tabela nat #
#######################################################
Capítulo 10. Firewall iptables 160
# Não queremos que usuários tenham acesso direto a www e smtp da rede externa,
# squid e smtpd do firewall devem ser obrigatoriamente usados. Também registra
# as tentativas para monitorarmos qual máquina está tentando conectar-se diret
iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o ppp+ -p tcp --dport 80 -j
iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o ppp+ -p tcp --dport 25 -j
iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o ppp+ -p tcp --dport 25 -j
iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o ppp+ -p tcp --dport 80 -j
# É feito masquerading dos outros serviços da rede interna indo para a interfa
# ppp0
iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o ppp+ -j MASQUERADE
# Qualquer outra origem de tráfego desconhecida indo para eth0 (conexões vinda
# de ppp+) são bloqueadas aqui
iptables -t nat -A POSTROUTING -o eth0 -d 192.168.1.0/24 -j LOG --log-prefix "
iptables -t nat -A POSTROUTING -o eth0 -d 192.168.1.0/24 -j DROP
# Quando iniciamos uma conexão ppp, obtermos um endereço classe A (10.x.x.x) e
# estabelecida a conexão real, este endereço é modificado. O tráfego indo para
# a interface ppp não deverá ser bloqueado. Os bloqueios serão feitos no
# chain INPUT da tabela filter
iptables -t nat -A POSTROUTING -o ppp+ -j ACCEPT
###############################################
# Tabela mangle #
###############################################
Capítulo 11
Este capítulo traz explicações e comandos úteis para o gerenciamento de contas e proteção de
senhas de usuários em sistemas Linux. Também explica os principais métodos usados para
quebra de senha usando diversos métodos como engenharia social, brute force, etc., bem como
dicas de como escolher boas senhas para você e seus usuários e métodos automatizados de
checagem de senhas vulneráveis.
Estes métodos são explicados para que você entenda, se previna destes tipos de ataques além
de entender a importância de políticas de proteção de senhas.
11.1 Introdução
A criação de uma conta em uma máquina Linux pode expor seu sistema (ou todas suas redes)
a crackers simplesmente com a falta de treinamento e políticas de segurança. Uma invasor com
um simples acesso a uma conta de usuário pode conseguir acesso a áreas que contém dados
importantes expondo seu sistema a ataques ou roubo de dados.
Um firewall não pode fazer muito em uma situação dessas, um acesso através de uma conta
de sistema válida é difícil de ser auditado e descoberto, a não ser que o usuário monitore seus
acesso via lastlog e o administrador conheça os hábitos de seus usuários para notar o uso
estranho de contas em determinados dias/horários. Evitar situações como esta depende mais
de conscientização e treinamento tanto do administrador como dos usuários das contas para
não expor o sistema a um ataque direto. Este capítulo do guia explicará as situações mais
comuns e alguns exemplos de como tais ataques acontecem.
ATENÇÃO: - Os dados aqui disponibilizados são puramente para fins didáticos e compreen-
são de como tais situações funcionam para se criar mecanismos de defesa personalizados de
acordo com o que deseja proteger.
Capítulo 11. Gerenciamento de contas e cuidados para a proteção de senhas 162
Para adicionar uma conta de usuário ao sistema é simples, basta um comando adduser
[usuário] e alguns poucos segundos para responder as questões do programa. Quando
criamos contas para outros usuários temos 2 alternativas: deixarmos a senha em branco ou
escolher uma senha que será passada ao usuário para que ele possa fazer a troca mais tarde.
A primeira alternativa é muito perigosa, pois uma pessoa com acesso a /etc/passwd poderá
facilmente descobrir sua lista de usuários (principalmente em uma grande empresa quando
conhecemos as políticas de criação de novas contas). Um funcionário notaria a presença do no-
vato e poderia aproveitar esta oportunidade para tentar incriminar este usando a conta recém
criada ou tentar outras coisas para obter benefício próprio através do descuido de outros.
O segundo método de senha inicial é um pouco mais seguro e de preferência a senha deve ser
escolhida pelo usuário para que pessoas que conhecem o estilo de senhas iniciais escolhidas
pelo administrador não possam deduzir a nova senha criada. É comum vermos senhas como
“novo1234”, “123456”, “abcdef”, “a1b3c3”, o “nome do usuário” como senhas iniciais, pois é
fácil de lembrar. Senhas deste tipo são as primeiras a ser tentadas por crackers e programas
específicos para este fim. Mas se o o usuário esquecer de trocar sua senha provisória?
O programa chage e passwd possui recursos que permitem definir limites mínimos e máximo
do tempo para troca de senha de acesso, número máximo de dias após expirar o tempo de
troca da senha em que a conta será permanentemente desabilitada (até que o administrador a
reative) e o período mínimo entre troca de senhas. Alguns exemplos:
passwd -x 10 -w 3 teste
A senha do usuário teste expirará após 10 dias (-x 10) e ele será avisado com 3 dias de ante-
cedência (-w 3) para trocar sua senha. Após o período máximo o usuário será obrigado a trocar
a senha.
Quando o usuário efetuar o login receberá a seguinte mensagem: Warning: your
password will expire in 3 days.
passwd -x 10 -w 3 -i 2 teste
A senha do usuário teste expirará após 10 dias (-x 10) e ele será avisado com 3 dias de ante-
cedência (-w 3) para trocar sua senha, após a expiração da senha, o usuário tem 2 dias antes da
conta ser desativada (-i 2). Se o período expirar e o usuário tentar um novo login será mostrada
a mensagem:
Your account has expired: Please contact your system administrator
Para reativar a conta acima, remova totalmente o bloqueio da conta do usuário teste com
passwd -x 0 teste, passwd -x 99999 -w 7 -i 0 teste ou especifique um período
de dias maior em adição àqueles especificados para que ele possa trocar a senha.
Por exemplo, caso tenha passado 3 dias desde que a conta acima expirou e deseje dar mais 2
dias para o usuário trocar a conta: passwd -x 17 -i 0 teste A conta será reativada por
Capítulo 11. Gerenciamento de contas e cuidados para a proteção de senhas 163
mais 2 dias dando a oportunidade do usuário trocar a senha. Preste atenção neste exemplo
para entender bem a situação e prazos.
passwd -x 90 -n 60 -w 15 -i 0 teste
A senha do usuário teste expirará após 90 dias (-x 90), ele será avisado para trocar sua senha
com 15 dias antes do prazo final (-w 15) e a conta será imediatamente desativada caso o prazo
máximo para troca da senha expire (-i 0). O usuário também não poderá trocar sua senha
durante os primeiros 60 dias desde a última troca de senha (-n 60).
Em sistemas onde precisa adicionar restrições a muitos usuários na criação da conta, é re-
comendável seguir os métodos descritos em ‘Definindo valores padrões de restrição’ on the
current page.
OBS1: Em sistemas com senhas ocultas ativadas (veja ‘Shadow Passwords’ on page 169) as
restrições acima serão especificadas no arquivo /etc/shadow, isto garante que só o usuário
root tenha acesso aos detalhes fornecidos neste arquivo.
OBS2: A -d do passwd serve para remover a senha do usuário especificado ou seja somente
será necessário fornecer o nome de usuário para ter acesso ao sistema.
OBS3: Leve em consideração que o uso do recursos de senhas de grupo é um risco de segu-
rança, pois a mesma senha será compartilhada entre diversas pessoas.
OBS4: O programa useradd combina as funções do adduser e passwd para garantir que
a conta seja criada com as restrições apropriadas. O único inconveniente é que o useradd
quebra o Debian Policy e precisa de todos todos os parâmetros para a criação correta da conta
(como o diretório home, senha criptografada, e UID numérico). Seu uso é indicado em shell
scripts que cuidam automaticamente da tarefa de adicionar usuários ao sistema.
Isto é muito útil quando precisa criar diversos usuários com as mesmas restrições de contas,
isto tornará o gerenciamento do sistema muito mais prático (tudo em Unix é feito para ser
mais prático, só devemos saber onde mexer). O arquivo /etc/defaults/useradd contém
valores padrões que serão usados pelo useradd e adduser para definir valores de restrições
de contas. Estes valores são gerados usando a opção -D em combinação com as seguintes
opções do useradd:
• -b [home] - Especificar o diretório home de usuário. O padrão é /home.
• -e [data] - Data padrão de expiração de contas, especificada no formato AnoMesDia.
Por exemplo, 20010920.
• -f [dias] - Número máximo de dias que a conta permanece válida após a data de
expiração até ser desativada.
• -g [gid/grupo] - ID do grupo ou nome do grupo que o usuário pertencerá inicial-
mente.
• -s [shell] - Shell do usuário. O padrão é /bin/bash.
OBS: Note que nem todas as opções acima terão efeito com o adduser (principalmente as
opções -f, -g e -s que são especificadas no seu arquivo de configuração /etc/adduser.conf).
Capítulo 11. Gerenciamento de contas e cuidados para a proteção de senhas 164
A senha lhe identifica como o verdadeiro dono de uma conta em um sistema para garantir
acesso a seus recursos. A senha de um sistema é tão importante quanto uma senha de sua
conta bancária, caso caia em mãos erradas as conseqüências poderão ser catastróficas, todo
cuidado é pouco na hora de escolher uma senha.
Senhas fáceis de adivinhar são o primeiro motivo de sucesso de crackers no acesso a sistemas
de computadores (veja ‘Dedução’ on page 166 e ‘Engenharia Social’ on page 166), o admin-
istrador pode forçar o usuário a fazer trocas periódicas de senhas através dos recursos citados
em ‘Criação, monitoramento e segurança de contas’ on page 162, mas quem vai garantir que
ele esteja escolhendo boas senhas para que ninguém as descubra com facilidade? Abaixo uma
lista de senhas ruins (que deverá evitar a todo custo usa-las) e boas:
Senhas Ruins
• O uso da palavra senha como senha! Isto parece idiota mais existe. . .
• Senhas com o mesmo nome do login (joao/joao).
• Compostas por letras ou números em seqüencia crescente ou decrescente (abcdef, 123456,
654321, etc, etc). Este tipo de senha pode ser adivinhada por dedução e são uma das
primeiras combinações que crackers usam para acertar senhas.
• palavras relacionadas com o gosto pessoal. Por exemplo “escort”, “vectra”, “subaru” se
a pessoa é amante de carros.
• Nome da esposa, filhos, familiares, animal de estimação, time de futebol, ídolo da
TV/filmes ou qualquer coisa relacionada a familiares ou indiretamente ao usuário.
• Idade, data de aniversário, data de casamento, número de identidade, título de eleitor,
placa de carro ou qualquer coisa que seja característica do usuário.
• Palavras existentes. Um ataque de dicionário poderá descobrir facilmente sua senha.
• Senhas com menos de 8 letras
• Senhas apenas em minúsculas ou MAIÚSCULAS.
Senhas Boas
• Uma boa senha nunca deverá ser lida mas fácil de lembrar. Por exemplo pense em uma
frase importante para você “meu sistema operacional preferido é o Linux” e pegue a
primeira letra de cada palavra: “msopeol”. PRONTO esta escolhida uma boa senha que
é fácil de se lembrar e difícil de ser quebrada por ataques de dicionário!
• Uma boa senha deve conter números e letras. A senha acima poderia ser modificada para
“msopeol1”
• Conter letras maiúsculas e minúsculas. “msopeoL1”.
• Conter 8 caracteres sempre que possível. Isto aumenta bastante o número de combi-
nações necessárias para se quebrar uma senha em um ataque brute force (veja ‘Brute
Force’ on page 168). Mesmo que a senha escolhida não chegue a 8 caracteres mínimos,
você poderá combina-la com números.
Com as dicas acima, a possibilidade de alguém conseguir quebrar uma senha criptografada em
seu sistema usando os ataques descritos em ‘Tipos de ataques mais comuns para se conseguir
uma senha.’ on page 166 é praticamente nula! Para os paranóicos de plantão, o utilitário
makepasswd pode criar uma senha com caracteres completamente aleatórios:
makepasswd --chars 8
Capítulo 11. Gerenciamento de contas e cuidados para a proteção de senhas 165
4y0sBdwM
Este comando retorna uma string com 8 caracteres (–chars 8) “4y0sBdwM”. Se você entendeu
boa parte deste guia tenho certeza que 1 ou 2 dias de treino e se acostuma com uma senha
como esta ;-)
OBS: NUNCA NUNCA dê pistas sobre sua senha! Para você isto pode ser um desafio lançado
a outras pessoas quase impossível de ser resolvido, mas não se esqueça que muita gente é
especializada neste tipo de dedução.
O programa chpasswd é usado para tal operação. Deve ser especificado um arquivo que
contém os campos usuário:senha por linha. Caso as senhas estejam encriptadas deverá ser
especificada a opção -e ao programa.
chpasswd -e /localadmin/contas/contas.db
11.3.1 Dedução
O cracker se aproveita da ingenuidade de usuários que deixam senhas em branco, usam senhas
simples como o próprio nome, “abcdef”, “asdfg”, “123456”, e outros tipos de senhas comuns
para tentar obter acesso ao sistema. Senhas deduzidas são geralmente senhas muito simples
e muito usadas. . . Uma situação comum para a escolha de uma senha deste tipo é o medo de
esquecer a senha (quando não se consegue pensar em algo mais difícil e ao mesmo tempo que
seja fácil de lembrar) e quando o usuário é pego desprevenido e não se sabe o que usar como
senha (como na assinatura de um provedor Internet, muito comum essa situação).
Geralmente é muito rápido e muito eficaz dependendo das habilidades do atacante dispõe.
Ataques por engenharia social são feitos através de pesquisa de dados pessoais e outras carac-
terísticas relacionadas ao usuário (time de futebol, data de nascimento dele, da esposa, filhos,
nome da atriz predileta, etc) e usando estes dados coletados para auxiliar na descoberta da
senha. Este ataque requer uma pesquisa sobre os hábitos, gostos, etc. Mas existem outros tipos
de ataque baseados em engenharia social, inclusive com o cracker passando-se pelo usuário.
Para diminuir as possibilidades deste tipo de ataque entenda e siga os procedimentos da parte
“Senhas Boas” na ‘Senhas fáceis de adivinhar e escolha de boas senhas’ on page 164 e continue
lendo esta seção.
Outro detalhe importante para diminuir as possibilidades de um ataque deste tipo bem suce-
dido é permitir somente o acesso do serviço de finger a redes confiáveis (locais onde uns
conhecem os outros). Os detalhes fornecidos pelo finger podem ser suficientes para garantir
sucesso deste tipo de ataque:
#finger joao
Login: joao Name: Joao P. M.
Directory: /home/joao Shell: /bin/bash
Office: Sala 400 Andar 2, 123-4567 Home: 123-7654
Last login Fri Aug 25 21:20 (AMT) on tty3
No mail.
Grupo de cadastramento.
As últimas linhas da saída do finger são os dados contidos nos arquivos .plan e .project
do diretório de usuário. O cracker com base nos dados fornecidos acima pelo finger poderia
inventar uma situação em que necessitaria de troca de senha por algum motivo. Abaixo uma
situação onde o cracker sabe que não existe identificador de chamadas na empresa e conhece
as fragilidades:
• Cracker: Disca para o CPD?
• Vitima: CPD?
Capítulo 11. Gerenciamento de contas e cuidados para a proteção de senhas 167
• Cracker: Oi, eu sou o Joao P. M. do grupo de cadastramento aqui do segundo andar, estou
tentando entrar no sistema mas por algum motivo ele não aceita minha senha (fazendo-se
de ignorante no assunto).
• Vitima: Por favor Sr. verifique se o Caps Lock do seu teclado está ativado, letras em
maiúsculas/minúsculas fazem diferença em nossos sistemas.
• Cracker: Ok vou checar (espera um tempo). Não, esta tudo Ok, você poderia agilizar isto
de alguma maneira, preciso lançar algumas fichas no sistema.
• Vitima: Posso modificar sua senha para um nome qualquer, depois você poderá trocar
por si próprio.
• Cracker: Ok, por mim tudo bem.
• Vitima: Humm, modifiquei para “cad1234”, basta você usa-la e terá acesso ao sistema.
Após isso execute o utilitário passwd para troca-la para algo que desejar.
• Cracker: Ok, muito obrigado. Tenha um bom dia.
Este é um exemplo simples de ataque por engenharia social. Dependendo do objetivo, este
tipo de ataque pode levar semanas e as vezes requer contatos com diversas empresas criando
diversas situações para obter detalhes necessários para atingir o objetivo.
As políticas de segurança de senhas minimizam riscos deste tipo. Como este é um caso que o
requisitante é um funcionário próximo do departamento de informática, o mais adequado seria
o administrador se deslocar ao setor (ou enviar um técnico do setor treinado para tal situação)
para saber se quem diz ser quem é está realmente no local enfrentando aquela situação. O
contato com o responsável do setor (conhecido do técnico) também pode ser uma alternativa
antes de entregar uma senha a um desconhecido.
Para casos externos (principalmente para empresas que mantém determinados serviços em
funcionamento em nosso servidor, como servidores de páginas), o procedimento correto seria
passar uma nova senha por e-mail (de preferência criptografado com pgp) ao invés de telefone.
Isto garantirá que a senha não caia nas mãos erradas.
OBS1: Qualquer detalhe sobre a política de criação de senhas, trocas de senhas, etc. poderá ter
muito valor para um cracker obter acesso ao seu sistema.
OBS2: Dificulte as maneiras para se obter acesso root ao sistema via conta de usuário comum.
É de extrema importância utilizar conexões de dados criptografadas quando for necessário
acesso externo ao seu sistema.
OBS3: Nunca use uma mesma senha para fazer tudo (banco, acessar seu sistema, conectar-se
ao seu provedor, senha de root). Você estará em sérios apuros caso alguém tenha acesso a esta
senha. É difícil lembrar de várias senhas, mas você pode aditar uma senha e criar modificações
a partir dela para utilização em outros locais, por exemplo: “wekpdm” => “Bwekpdm1” =>
“3wekpdmS”, etc.
De posse do arquivo de senhas /etc/passwd, o cracker utiliza um arquivo que contém di-
versas palavras que serão tentadas como senha. Este trabalho é feito automaticamente por
ferramentas dedicadas a este tipo de tarefa e pode levar dias dependendo da lista de senhas
do cracker e quantidades de usuários existentes no arquivo de senha.
Capítulo 11. Gerenciamento de contas e cuidados para a proteção de senhas 168
Note que o uso de criptografia md5 e senhas ocultas dificultam bastante ao arquivo de senhas e
o sucesso de um ataque bem sucedido (veja ‘Shadow Passwords’ on the next page e ‘Senhas
MD5’ on the facing page).
De posse do arquivo de senhas /etc/passwd o cracker utiliza uma ferramenta que tenta
diversas combinações de letras seqüencialmente na tentativa de descobrir uma senha. Este
ataque geralmente é usado como último recurso após um ataque por dicionário, e leva muito
tempo para descobrir uma senha.
Este ataque é muito comum em sistemas DOS e Windows, um programa é instalado sem o
conhecimento do usuário que grava todos os toques do teclado em um arquivo escondido pelo
cracker. Após certo tempo o cracker obtém acesso ao arquivo e aos dados que ele contém. Este
tipo de ataque é muito perigoso e pode capturar senhas não só do sistema como números de
cartão de crédito digitados (caso o usuário tenha feito compras on-line), conta bancária+senha
e tudo mais que for digitado pelo teclado.
Esta é uma forma rápida de se conseguir acesso a um sistema. É criada uma tela de login
idêntica a original do sistema, só que ao digitar nome e senha, estes são gravados em um
arquivo (que será mais tarde recuperado pelo cracker para obter acesso ao sistema) e uma
mensagem de erro será exibida pelo sistema.
Naturalmente o usuário pensará que digitou o nome/senha incorretamente e fará uma nova
tentativa, a segunda ocorrerá com sucesso (fazendo este pensar que errou *mesmo* a senha).
Sua atenção é muito importante para evitar este tipo de ataque, caso desconfie de algo errado,
entra no sistema e dê um find --type f -cmin -3 para localizar os arquivos modificados
nos últimos 3 minutos e localizar possíveis bancos de dados de senhas.
Outra alternativa é realmente digitar uma senha inválida intencionalmente (e diferente da cor-
reta) e na segunda tentativa lançar a senha válida (normalmente sistemas deste tipo bem elab-
orados chamam o verdadeiro sistema de login na segunda tentativa).
Capítulo 11. Gerenciamento de contas e cuidados para a proteção de senhas 169
O sistema de criptografia usado pelas senhas MD5 é mais seguro que o padrão Crypto e per-
mitem o uso de senhas maiores do que 8 caracteres.
O uso de senhas MD5 é recomendado para aumentar o nível de proteção da senha. Não use
caso estiver executando um serviço de NIS. OBS: Caso utilize senhas MD5 em um sistema com
PAM, inclua a palavra md5 na linha de configuração do método de autenticação password do
módulo pam_unix.so:
Capítulo 12
Apache
12.1 Introdução
12.1.1 Versão
É assumido que esteja usando a versão 1.3.22 do apache. As explicações contidas aqui podem
funcionar para versões posteriores, mas é recomendável que leia a documentação sobre modifi-
Capítulo 12. Apache 172
cações no programa (changelog) em busca de mudanças que alterem o sentido das explicações
fornecidas aqui.
O Apache tem como base o servidor web NCSA 1.3 (National Center of Supercomputing Applica-
tions), que foi desenvolvido por Rob McCool. Quando Rob deixou o NCSA, o desenvolvimento
foi interrompido, assim muitos desenvolvedores buscaram personalizar sua própria versão do
NCSA ou adicionar mais características para atender as suas necessidades. Neste momento
começa a história do Apache com Brian Behlendorf e Cliff Skolnick abrindo uma lista de dis-
cussão para interessados no desenvolvimento, conseguindo espaço em um servidor doado
pela HotWired e trocando patches corrigindo problemas, adicionando recursos e discutindo
idéias com outros desenvolvedores e hackers interessados neste projeto.
A primeira versão oficial do Apache foi a 0.6.2, lançada em Abril de 1995 (neste período a
NCSA retomava o desenvolvimento de seu servidor web, tendo como desenvolvedores Bran-
don Long e Beth Frank que também se tornaram membros especiais do grupo Apache, compar-
tilhando idéias sobre seus projetos).
Nas versões 2.x do Apache, a escalabilidade do servidor foi ampliada suportando as platafor-
mas Win32 (não obtendo o mesmo desempenho que em plataformas UNIX mas sendo melho-
rado gradativamente).
Abaixo estão algumas características que fazem esse servidor web o preferido entre os admin-
istradores de sistemas:
• Possui suporte a scripts cgi usando linguagens como Perl, PHP, Shell Script, ASP, etc.
• Suporte a autorização de acesso podendo ser especificadas restrições de acesso separada-
mente para cada endereço/arquivo/diretório acessado no servidor.
• Autenticação requerendo um nome de usuário e senha válidos para acesso a alguma
página/sub-diretório/arquivo (suportando criptografia via Crypto e MD5).
• Negociação de conteúdo, permitindo a exibição da página Web no idioma requisitado
pelo Cliente Navegador.
• Suporte a tipos mime.
Capítulo 12. Apache 173
• Personalização de logs.
• Mensagens de erro.
• Suporte a virtual hosting (é possível servir 2 ou mais páginas com endereços/ portas
diferentes através do mesmo processo ou usar mais de um processo para controlar mais
de um endereço).
• Suporte a IP virtual hosting.
• Suporte a name virtual hosting.
• Suporte a servidor Proxy ftp e http, com limite de acesso, caching (todas flexivelmente
configuráveis).
• Suporte a proxy e redirecionamentos baseados em URLs para endereços Internos.
• Suporte a criptografia via SSL,Certificados digitais
• Módulos DSO (Dynamic Shared Objects) permitem adicionar/remover funcionalidades
e recursos sem necessidade de recompilação do programa.
Pacote: apache
Utilitários:
• apache - Servidor Web Principal
• apachectl - Shell script que faz interface com o apache de forma mais amigável
• apacheconfig - Script em Perl para configuração interativa básica do Apache
• htpasswd - Cria/Gerencia senhas criptografadas Crypto/MD5
• htdigest - Cria/Gerencia senhas criptografadas Crypto/MD5
• dbmmanage - Cria/Gerencia senhas em formato DBM (Perl)
• logresolve - Faz um DNS reverso dos arquivos de log do Apache para obter o en-
dereço de hosts com base nos endereços IP’s.
• ab - Apache Benchmarcking - Ferramenta de medida de desempenho do servidor Web
Apache.
Por padrão, os arquivos de configuração do Apache residem no diretório /etc/apache:
httpd.conf Arquivo de configuração principal do Apache, possui diretivas que controlam a
operação do daemon servidor. Um arquivo de configuração alternativo pode ser especi-
ficado através da opção “-f” da linha de comando.
srm.conf Contém diretivas que controlam a especificação de documentos que o servidor ofer-
ece aos clientes. O nome desse arquivo pode ser substituído através da diretiva Resource-
Config no arquivo principal de configuração.
access.conf Contém diretivas que controlam o acesso aos documentos. O nome desse arquivo
pode ser substituído através da diretiva AccessConfig no arquivo principal de configu-
ração.
O servidor Web lê os arquivos acima na ordem que estão especificados (httpd.conf,
srm.conf e access.conf). As configurações também podem ser especificadas direta-
mente no arquivo httpd.conf. Note que não é obrigatório usar os arquivos srm.conf e
access.conf, mas isto proporciona uma melhor organização das diretivas do servidor, prin-
cipalmente quando se tem um grande conjunto de diretivas. Um exemplo comentado destes
três arquivos de configuração é encontrado em ‘Exemplo comentado de um arquivo de config-
uração do Apache’ on page 216.
Capítulo 12. Apache 174
12.1.6 Requerimentos
A máquina mínima para se rodar um servidor Apache para atender a uma rede padrão
10MB/s é um Pentium 90, 24MB de RAM, um HD com um bom desempenho e espaço em
disco considerável de acordo com o tamanho projetado de seu servidor web (considerando
seu crescimento).
Uma configuração mais rápida para redes 100MB/s teria como processador um Cyrix MX
ou Intel Pentium MMX como plataforma mínima (Cyrix é o recomendado pelo alto desem-
penho no processamento de strings), barramento de HD SCSI com uma boa placa controladora
(Adaptec 19160 ou superior) com 64MB de RAM no mínimo.
O servidor httpd grava seus arquivos de log geralmente em /var/log/apache, não é pos-
sível descrever os arquivos de logs usados porque tanto seus nomes como conteúdo podem
ser personalizados no arquivo httpd.conf. Mesmo assim, os arquivos de logs encontrados
na instalação padrão do Apache são os seguintes:
• access.log - Registra detalhes sobre o acesso as páginas do servidor httpd.
• error.log - Registra detalhes saber erros de acesso as páginas ou erros internos do
servidor.
• agent.log - Registra o nome do navegador do cliente (campo UserAgent do cabeçalho
http).
Mais referências podem ser encontradas em ‘Sistema de Log do Apache’ on page 199. Um bom
programa para geração de estatísticas de acesso com gráficos é o ‘Relatório gráfico de acesso
ao sistema’ on page 204.
12.1.8 Instalação
O Apache pode ser executado tanto como um servidor Inetd ou como um Daemon. A inicial-
ização de programas pelo Inetd é uma boa estratégia quando você precisa de um controle de
acesso básico (o fornecido pelo tcpd), e o serviço é pouco usado na máquina.
A segurança de um serviço iniciado pelo inetd pode ser substituída e melhorada por um
firewall bem configurado, garantindo facilidades extras como um relatório de tráfego para a
porta do servidor web, por exemplo. Mesmo assim se o servidor Apache estiver rodando
Capítulo 12. Apache 175
como daemon e estiver ocioso, ele será movido para swap liberando a memória RAM para a
execução de outros programas.
Neste capítulo será assumido seu funcionamento do Apache como Daemon, que é o método
de funcionamento recomendado para sites de grande tráfego onde ele é freqüentemente req-
uisitado e considerado um serviço crítico.
O método padrão para iniciar programas como daemons na Debian é através dos di-
retórios /etc/rc?.d. Cada diretório deste contém os programas que serão executa-
dos/interrompidos no nível de execução “?” (rc1.d/, rc2.d/ . . . ). O conteúdo destes di-
retórios são links para os scripts originais em /etc/init.d/programa, o nosso programa
alvo é /etc/init.d/apache. O /etc/init.d/apache aceita os seguintes parâmetros:
• start - Inicia o Apache
• stop - Finaliza o Apache
• restart - Reinicia o Apache, efetuando uma pausa de 5 segundos entre a interrupção
do seu funcionamento e reinicio.
• reload - Recarrega os arquivos de configuração do Apache, as alterações entram em
funcionamento imediatamente.
• reload-modules - Recarrega os módulos. Basicamente é feito um restart no servidor.
• force-reload - Faz a mesma função que o reload
Para reiniciar o Apache usando o /etc/init.d/apache, digite:
./etc/init.d/apache restart
ou
cd /etc/init.d;./apache restart
Na realidade, o que o /etc/init.d/apache faz é interagir diretamente com o shell script
apachectl.
O apachectl recebe os parâmetros enviados pelo usuário e converte para sinais que serão
enviados para o binário apache. Da mesma forma ele verifica os códigos de saída do apache
e os transforma em mensagens de erro legíveis para o usuário comum. Os seguintes comandos
são aceitos pelo apachectl:
• httpd-server/start - Inicia o Apache
• stop - Finaliza o Apache (enviando um sinal TERM)
• restart - Reinicia o Apache (enviando um sinal HUP)
• graceful - Recarrega os arquivos de configuração do Apache (enviando um sinal
USR1)
• fullstatus - Mostra o status completo do servidor Apache (requer o lynx e o módulo
mod_status carregado).
• status - Mostra o status do processo do servidor Apache (requer o lynx e o módulo
mod_status carregado).
• configtest - Verifica se a sintaxe dos arquivos de configuração está OK (executa um
apache -t).
Use a diretiva Port para configurar a porta padrão que o Apache receberá requisições por
padrão. A diretiva Listen também é usada para ajustar o endereço/portas alternativas (us-
adas também em Virtual Hosts) e substituirá as definições de Port(veja ‘Especificando en-
dereços/portas adicionais (a diretiva Listen)’ on page 178 para detalhes).
OBS:: Somente uma diretiva Port e um argumento poderão ser especificados. Para mais cont-
role sobre as portas do sistema use a diretiva Listen.
Existem dois tipos de páginas que podem ser adicionadas ao Apache: a página raíz e sub-
páginas.
Página Raíz A página raíz é especificada através da diretiva DocumentRoot e será mostrada
quando se entrar no domínio principal, como http: //www.guiafoca.org. Na con-
figuração padrão do Apache, DocumentRoot aponta para o diretório /var/www. Este
diretório será assumido como raíz caso os diretórios não sejam iniciados por uma /:
• home/focalinux - Aponta para /var/www/home/focalinux
• /home/focalinux - Aponta para /home/focalinux
Este diretório deve conter um arquivo de índice válido (especificado pela diretiva Docu-
mentIndex no srm.conf) e permissões de acesso válidas no arquivo access.conf para
autorizar o acesso as páginas em /var/www (veja ‘Restrições de Acesso’ on page 182 para
detalhes).
Sub-páginas Sub páginas são armazenadas abaixo do diretório da Página raíz, como http: /
/www.guiafoca.org/download. Elas podem ser um subdiretório da página principal
Capítulo 12. Apache 177
Pode ser necessário permitir o acesso a nova página caso o servidor tenha uma con-
figuração restritiva por padrão (veja ‘Restrições de Acesso’ on page 182 para detalhes).
Após isto, faça o servidor httpd re-ler os arquivos de configuração ou reinicia-lo. Após
isto, a página /home/focalinux/download/iniciante estará acessível via http:
//www.guiafoca.org/iniciante.
OBS: Caso inclua uma / no diretório que será acessível via URL, o endereço somente
estará disponível caso você entre com / no final da URL:
A diretiva BindAddress é usada para especificar endereços IP das interfaces ou endereços FQDN
que o Apache responderá requisições. Mais de um endereço podem ser especificados separa-
dos por espaços. Caso não seja definido, o Apache assumirá o valor “*” (atenderá requisições
vindas de qualquer interface).
OBS1: - É permitido usar somente uma diretiva BindAddress. A diretiva Listen deverá ser usada
se desejar mais controle sobre as portas do servidor web. Veja ‘Especificando endereços/portas
adicionais (a diretiva Listen)’ on the following page para detalhes.
OBS2: - As interfaces especificadas pela diretiva Listen substituirá as especificadas em BindAd-
dress.
Exemplo:
• BindAddress 192.168.1.1 - Especifica que os usuários da faixa de rede
192.168.1.* terão acesso ao servidor httpd. Isto assume que a máquina possui o
endereço 192.168.1.1 em sua interface de rede interna.
• BindAddress * - Atenderá requisições vindas de qualquer interface de rede.
Capítulo 12. Apache 178
A diretiva Listen é usada para se ter um controle maior sobre a especificação de en-
dereços/portas alternativas que o servidor web esperará por requisições externas. Esta di-
retiva é muito usada na construção de Virtual Hosts. Esta diretiva pode substituir comple-
tamente as diretivas Port e BindAddress. Podem ser usados o número da porta, ou o par
endereço:porta:
Listen 192.168.1.1:80
Listen 192.168.7.1:81
Listen 60000
O endereço que deverá ser usado é o da interface de rede (assim como na diretiva BindAddress).
No exemplo acima, o servidor httpd esperará por requisições vindas de 192.168.1.* na
porta 80 e também 60000, e requisições vindas de 192.168.7.1 na porta 81 e também 60000.
As opções de restrição podem tanto ser especificadas nas diretivas <Directory>, <Location>
ou <Files> quanto nos arquivos .htaccess (ou outro nome de arquivo de controle de acesso
especificado pela opção AccessFileName do arquivo de configuração do Apache). Cada diretiva
de acesso é especificada entre <tags> e devem ser fechadas com </tag> (como na linguagem
HTML). As seguintes diretivas de acesso são válidas no Apache:
<Directory /var/www>
Order deny,allow
deny from all
allow from 10.1.0.1
<Directory>
DirectoryMatch Funciona como a diretiva <Directory> mas trabalha com expressões regu-
lares como argumento. Por exemplo:
<DirectoryMatch "^/www/.*">
Order deny,allow
deny from all
<DirectoryMatch>
Capítulo 12. Apache 179
Files As restrições afetarão os arquivos do disco que conferem com o especificado. É possível
usar os coringas ? e * como no shell. Também podem ser usadas expressões regulares
especificando um “~” após Files e antes da expressão. Por exemplo:
<Files *.txt>
Order deny,allow
deny from all
</Files>
<Files ~ "\.(gif|jpe?g|bmp|png)$">
Order deny,allow
</Files>
<FilesMatch "\.(gif|jpe?g|bmp|png)$">
Order deny,allow
</FilesMatch>
Location As restrições afetarão o diretório base especificado na URL e seus sub-diretórios. Por
exemplo:
<Location /security>
Order allow,deny
</Location>
LocationMatch Idêntico a diretiva <Location> mas trabalha com expressões regulares. Por
exemplo:
<LocationMatch "/(extra|special)/data">
Order deny,allow
deny from all
</LocationMatch>
Capítulo 12. Apache 180
O uso das diretivas <Directory> e <Files> é apropriada quando você deseja trabalhar com
permissões a nível de diretórios/arquivos no disco local (o controle do proxy também é feito
via <Directory>), o uso da diretiva <Location> é adequado para trabalhar com permissões a
nível de URL. A ordem de processamento das diretivas de acesso são processadas é a seguinte:
1 A diretiva <Directory> (com exceção de <DirectoryMatch>) e os arquivos .htaccess
são processados simultaneamente. As definições dos arquivos .htaccess substituem
as de <Directory>)
2 Expressões regulares de <DirectoryMatch>, <Directory>.
3 <Files> e <FilesMatch> são processados simultaneamente.
4 <Location> e <LocationMatch> são processados simultaneamente.
Normalmente é encontrado a opção Options dentro de uma das diretivas acima, a função desta
diretiva é controlar os seguintes aspectos da listagem de diretórios:
All Todas as opções são usadas exceto a MultiViews. É a padrão caso a opção Options não
seja especificada.
ExecCGI Permite a execução de scripts CGI.
FollowSymLinks O servidor seguirá links simbólicos neste diretório (o caminho não é modi-
ficado). Esta opção é ignorada caso apareça dentro das diretivas <Location>, <Location-
Match> e <DirectoryMatch>.
Includes É permitido o uso de includes no lado do servidor.
IncludesNOEXEC É permitido o uso de includes do lado do servidor, mas o comando #exec
e #include de um script CGI são desativados.
Indexes Se não existir um arquivo especificado pela diretiva <DirectoryIndex> no diretório
especificado, o servidor formatará automaticamente a listagem ao invés de gerar uma
resposta de acesso negado.
MultiViews Permite o uso da Negociação de conteúdo naquele diretório. A negociação de
conteúdo permite o envio de um documento no idioma requisitado pelo navegador do
cliente.
SymLinksIfOwnerMatch O servidor somente seguirá links simbólicos se o arquivo ou di-
retório alvo tiver como dono o mesmo user ID do link. Esta opção é ignorada caso
apareça dentro das diretivas <Location>, <LocationMatch> e <DirectoryMatch>.
Múltiplos parâmetros para Options podem ser especificados através de espaços.
OBS1: A opção Options não tem efeito dentro da diretiva FILES.
OBS2: Tanto faz usar maiúsculas quanto minúsculas nas diretivas de configuração, opções e
parâmetros de configuração do Apache, a capitalização apenas ajuda a leitura e interpretação:
SymLinksIfOwnerMatch (LinksSimbólicosSeDonoConferir).
As opções especificadas para o diretório afetam também seus sub-diretórios, a não ser que
sejam especificadas opções separadas para o sub-diretório:
<Directory /var/www>
Options Indexes FollowSymLinks
</Directory>
Capítulo 12. Apache 181
<Directory /var/www>
Options Indexes FollowSymLinks
</Directory>
<Directory /var/www/focalinux>
Options Includes
</Directory>
<Directory /var/www>
Options Indexes FollowSymLinks
</Directory>
<Directory /var/www/focalinux>
Options +Includes -Indexes
</Directory>
As opções Indexes e FollowSymLinks são definidas para o diretório /var/www, então as permis-
sões do diretório /var/www/focalinux serão FollowSymLinks (do diretório /web/docs) e
Includes (adicionada) e o parâmetro Indexes não terá efeito neste diretório.
É permitido fazer um aninhamento das diretivas <Directory> e <Files>:
<Directory /var/www>
Order allow,deny
allow from all
<Files LEIAME-DONO.txt>
Order deny,allow
deny from all
</Files>
</Directory>
Se a diretiva <Files> for usada fora de uma estrutura <Directory>, ela terá efeito em todos os
arquivos disponibilizados pelo servidor. Este é excelente método para proteger os arquivos de
acesso, senhas e grupos, conforme será explicado mais adiante.
Qualquer outro tipo de aninhamento de diretivas resultará em um erro de configuração ao se
tentar carregar/recarregar o Apache. Um exemplo de diretiva incorreta:
<Directory /var/www>
Options Indexes FollowSymLinks
<Directory /var/www/focalinux>
Options +Includes -Indexes
</Directory>
</Directory>
O correto é:
<Directory /var/www>
Options Indexes FollowSymLinks
</Directory>
<Directory /var/www/focalinux>
Options +Includes -Indexes
</Directory>
que seja passado nome e senha para garantir acesso a página. Os métodos de Autorização e
Autenticação podem ser combinados como veremos mais adiante.
12.7.1 Autorização
A restrição de acesso por autorização (controlado pelo módulo mod_access), permite ou não
o acesso ao cliente de acordo com o endereço/rede especificada. As restrições afetam tam-
bém os sub-diretórios do diretório alvo. Abaixo um exemplo de restrição de acesso que blo-
queia o acesso de qualquer host que faz parte do domínio .spammers.com.br a URL http: /
/servidor/teste:
<Location /teste>
Option Indexes
Order allow,deny
allow from all
deny from .spammers.com.br
</Location>
A opção Option foi explicada acima, seguem as explicações das outras diretivas:
Order Especifica em que ordem as opções de acesso allow/deny serão pesquisadas. Caso não
seja especificada, o padrão será deny/allow. Note que a ordem de pesquisa de allow e deny
é a inversa da especificada. A diretiva Order aceita os seguintes valores:
• deny,allow - Esta é a padrão, significa um servidor mais restritivo; a diretiva allow
é processada primeiro e somente depois a diretiva deny. Caso nenhuma diretiva al-
low e deny forem especificadas ou não conferirem, PERMITE TUDO como padrão.
• allow,deny - Significa um servidor mais permissivo, a opção deny é processada
primeiro e somente depois a opção allow. Caso nenhuma diretiva allow e deny for
especificadas ou não conferirem, BLOQUEIA TUDO como padrão.
• mutual-failure - Somente permite o acesso se o usuário receber autorização
através da opção allow e NÃO ser bloqueado pela opção deny, caso uma das checa-
gens falhe, o acesso é imediatamente negado. É uma opção interessante quando
você quer somente pessoas de um determinado endereço/rede acessando o seu sis-
tema e não estejam em sua lista negra :-)
ATENÇÃO: É importante saber se a página será permissiva ou restritiva para escolher
a ordem mais adequada ao seu caso, também leve em consideração a possibilidade do
processamento cair na diretiva de acesso padrão, caso nem a diretiva allow e deny con-
feriram e estiver usando a ordem de acesso “allow,deny” ou “deny,allow”. Um sistema
mal configurado neste aspecto poderá trazer sérias conseqüências. É comum em páginas
permissivas se definir a seguinte configuração:
Order allow,deny
allow from all
O motivo é que em um grande site, se forem adicionadas mais restrições nesta página (de-
vido a alguns domínios que tem usuários mal comportados, bloqueio de acesso a rede do
concorrente, potenciais atacantes, etc. . . ), estas deverão ser lidas antes da diretiva “allow
Capítulo 12. Apache 184
• O servidor Web não tem permissões para acessar/abrir o diretório da página. Certifique-
se que o dono e grupo do processo Apache (especificado pela diretiva User e Group) pos-
suem permissões de acesso àquele diretório.
• Quando quer fazer uma listagem de arquivos do diretório e não especifica a opção
Option Indexes como opção de listagem.
• Quando não está usando Option Indexes para impedir a listagem de conteúdo do
diretório e o não foi encontrado um arquivo de índice válido dentre os existentes na
diretiva DirectoryIndex no diretório atual.
<Directory /var/www>
Options SymLinksIfOwnerMatch Indexes MultiViews
Order allow,deny
allow from all
</Directory>
Permite o acesso a de qualquer usuário de qualquer lugar (allow from all), permite também a
visualização da listagem formatada de arquivos caso nenhum arquivo especificado na diretiva
DirectoryIndex seja encontrado (Indexes), permite negociação de conteúdo (MultiViews) e seguir
links caso o dono do arquivo confira com o nome do link (SymLinksIfOwnerMatch).
<Directory /var/www>
Options SymLinksIfOwnerMatch Indexes MultiViews
</Directory>
Tem o mesmo significado da diretiva acima por métodos diferentes; quando nenhuma opção
Order é especificada, deny,allow é definido como padrão, e como nenhuma opção de acesso al-
low/deny foi especificada, o padrão “Order deny,allow” é usado e permite TUDO como padrão.
<Directory /var/www>
Options Indexes
Order deny,allow
deny from all
</Directory>
Esta regra acima não tem muita lógica pois restringe o acesso de todos os usuários ao diretório
/var/www, ao menos se esta for sua intenção. . .
<Location /focalinux>
Options All
Order allow,deny
allow from all
</Location>
<Files .htaccess>
Order deny,allow
deny from all
</Files>
<Files ~ "leiame-(arm|alpha|m68k|sparc|powerpc)\.txt">
Order deny,allow
deny from all
</Files>
<Directory /var/www>
Options Indexes
Order mutual-failure
allow from .dominio.com.br
deny from lammer.dominio.com.br
</Directory>
<Directory /var/www>
Options Indexes MultiViews
Order allow,deny
deny from .com .com.br
allow from all
</Directory>
<Directory /var/www>
Options None
Order deny,allow
allow from 192.168.1. .guiafoca.org .debian.org
deny from 200.200.123.
</Directory>
<Directory /var/www>
Options None
Order allow,deny
allow from 192.168.1. .cipsga.org.br .debian.org
deny from 200.200.123.
</Directory>
A regra acima é idêntica a anterior somente com a mudança da opção Order. Bloqueia o acesso
de máquinas da rede 200.200.123.* e permite o acesso de máquinas da rede 192.168.1.*,
do domínio *.cipsga.org.br e *.debian.org.
Note que a máquina 192.168.4.10 terá acesso BLOQUEADO a regra acima, pois não con-
ferirá nem com allow nem com deny, então o processamento cairá na diretiva padrão de al-
low,deny que neste caso bloqueia o acesso.
12.7.2 Autenticação
O arquivo de senhas pode ser criado e mantido através do uso de 3 utilitários: htpasswd,
htdigest e dbmmanage:
htpasswd Este é usado para criar o arquivo de senhas. Para criar um banco de dados com o
nome senhas para o usuário convidado, é usada a seguinte sintaxe:
htpasswd -c -m senhas convidado
Você será perguntado por uma senha para o usuário convidado e para redigita-la. A opção
“-c” indica que deverá ser criado um arquivo, a opção “-m” indica a utilização de senhas crip-
tografadas usando o algoritmo MD5, que garante maior segurança que o método Crypto. A
senha pode ser especificada diretamente na linha de comando através da opção “-b” (isto é um
ótimo recurso para utilização em shell scripts ou programas CGI de integração com o naveg-
ador).
htpasswd -b -d senhas chefe abcdef
No exemplo acima, uma senha de alta segurança será introduzida no banco de dados senhas
tornando impossível o acesso a página do usuário :-)
Note que esta senha foi cadastrada usando o algoritmo de criptografia Crypto (opção -d). O
algoritmo SHA também pode ser usado como alternativa, através da opção “-s”. Para modi-
ficar a senha do usuário convidado, basta usar a mesma sintaxe (sem a opção “-c” que é usada
para criar um novo arquivo):
Capítulo 12. Apache 188
Através deste método é possível especificar que usuários terão acesso ao recurso definido, us-
ando senhas de acesso individuais criptografadas usando um dos utilitários da seção anterior.
Para restringir o acesso ao endereço http: //servidor.org/teste:
<Location /teste>
AuthName "Acesso a página do Foca Linux"
AuthType basic
AuthUserFile /home/gleydson/SenhaUsuario
# AuthGroupFile /home/users/SenhaGrupo
Require valid-user
</Location>
Ao tentar acessar o endereço http: //servidor/teste, será aberta uma janela no nave-
gador com o título Enter username for Acesso a página do Foca Linux at servidor.org, a diretiva
Require valid-user definem que o usuário e senha digitados devem existir no arquivo especi-
ficado por AuthUserFile para que o acesso seja garantido. Uma explicação de cada opção de
acesso usado na autenticação:
AuthName Será o nome que aparecerá na janela de autenticação do seu navegador indicando
qual área restrita está solicitando senha (podem existir várias no servidor, bastando es-
pecificar várias diretivas de restrições).
AuthType Especifica o método de que o nome e senha serão passados ao servidor. Este
método de autenticação pode ser Basic ou Digest
• Basic - Utiliza a codificação base64 para encodificação de nome e senha, enviando o
resultado ao servidor. Este é um método muito usado e pouco seguro, pois qualquer
sniffer instalado em um roteador pode capturar e descobrir facilmente seu nome e
senha.
Capítulo 12. Apache 189
• Digest - Transmite os dados de uma maneira que não pode ser facilmente decod-
ificada, incluindo a codificação da área protegida (especificada pela diretiva Auth-
Name) que possui a seqüencia de login/senha válida. A diferença deste método é
que você precisará de arquivos de senhas diferentes para cada área protegida es-
pecificada por AuthName (também chamada de Realm).
AuthUserFile É o arquivo gerado pelo utilitário htpasswd que contém a senha correspon-
dente ao usuário
AuthGroupFile É um arquivo texto que contém o nome do grupo, dois pontos (“:”) e o nome
dos usuários que podem ter acesso ao recurso, separados por vírgulas. No exemplo
acima ele se encontra comentado, mas a seguir encontrará exemplos que explicam em
detalhes o funcionamento desta diretiva.
Require Especifica que usuários podem ter acesso ao diretório. Podem ser usadas uma das 3
sintaxes:
• Require user usuário1 usuário2 usuário3 - Somente os usuários especi-
ficados são considerados válidos para ter acesso ao diretório.
• Require group grupo1 grupo2 grupo3 - Somente os usuários dos grupos es-
pecificados são considerados válidos para terem acesso ao diretório. Esta diretiva
é útil quando deseja que somente alguns usuários de determinado grupo tenham
acesso ao recurso (por exemplo, usuários do grupo admins).
• Require valid-user - Qualquer usuário válido no banco de dados de senhas
pode acessar o diretório. É bem útil quando as opções de acesso especificadas por
Require user são muito longas. A opção Require deve ser acompanhado das direti-
vas AuthName, AuthType e as diretivas AuthUserFile e AuthGroupFile para funcionar
adequadamente.
OBS: É necessário reiniciar o Apache depois de qualquer modificação em seu arquivo de con-
figuração (apachectl restart), ou recarregar os arquivos de configuração (apachectl
graceful). Note que o apachectl é somente um shell script para interação mais amigável
com o servidor web apache, retornando mensagens indicando o sucesso/falha no comando
ao invés de códigos de saída.
Alguns exemplos para melhor assimilação:
<Location /teste>
AuthName "Acesso a página do Foca Linux"
AuthType basic
AuthUserFile /home/gleydson/SenhaUsuario
Require user gleydson
</Location>
As explicações são idênticas a anterior, mas somente permite o acesso do usuário gleydson a
URL http: //servidor.org/teste, bloqueando o acesso de outros usuários contidos no
arquivo AuthUserFile.
<Location /teste>
AuthName "Acesso a página do Foca Linux"
Capítulo 12. Apache 190
AuthType basic
AuthUserFile /home/gleydson/SenhaUsuario
Require user gleydson usuario1 usuario2
</Location>
<Location /teste>
AuthName "Acesso a página do Foca Linux"
AuthType basic
AuthUserFile /home/gleydson/SenhaUsuario
Require user gleydson
Require user usuario1
Require user usuario2
</Location>
Há casos onde existem usuários de um arquivo de senhas que devem ter acesso a um diretório
e outros não, neste caso a diretiva valid-user não pode ser especificada (porque permitiria o
acesso de todos os usuários do arquivo de senha ao diretório) e uma grande lista de usuários
ficaria bastante complicada de ser gerenciada com vários usuários na diretiva Require user.
Quando existe esta situação, é recomendado o uso de grupos de usuários. Para fazer uso
desse recurso, primeiro deverá ser criado um arquivo quer armazenará o nome do grupo e dos
usuários pertencente àquele grupo usando a seguinte sintaxe (vamos chamar este arquivo de
SenhaGrupo):
Agora adaptamos o exemplo anterior para que somente os usuários especificados no grupo
admins do arquivo criado acima:
<Location /teste>
AuthName "Acesso a página do Foca Linux"
AuthType basic
AuthUserFile /home/gleydson/SenhaUsuario
AuthGroupFile /home/gleydson/SenhaGrupo
Require group admins
</Location>
Capítulo 12. Apache 191
Agora somente os usuários pertencentes ao grupo admins (gleydson e usuario2) poderão ter
acesso ao diretório /teste.
OBS1: Verifique se o servidor Web possui acesso a leitura no arquivo de senhas de usuários e
grupos, caso contrário será retornado um código “500 - Internal Server Error”. Este tipo de erro
é caracterizado por tudo estar OK na sintaxe dos arquivos de configuração após checagem com
“apache -t” e todas as diretivas de controle de acesso apontam para os diretórios e arquivos
corretos.
OBS2:: Sempre use espaços para separar os nomes de usuários pertencentes a um grupo.
OBS3: NUNCA coloque os arquivos que contém senhas e grupos em diretórios de acesso
público onde usuários podem ter acesso via o servidor Web. Tais localizações são /var/www,
/home/"usuario"/public_html e qualquer outro diretório de acesso público que defina
em seu sistema.
É recomendável também ocultar estes arquivos através da diretiva <Files> evitando possíveis
riscos de segurança com usuários acessando os arquivos de senha e grupo.
Na distribuição Debian, qualquer arquivo iniciando com .ht* será automaticamente ocul-
tado pelo sistema, pois já existe uma diretiva <Files ~ “\.ht”>. Tal diretiva pode também ser
especificada no arquivo de acesso .htaccess. Assim um arquivo .htsenha e .htgroup são
bons nomes se estiver desejando ocultar dados de olhos curiosos. . .
Os métodos de autorização e autenticação podem ser usados ao mesmo tempo dentro de qual-
quer uma das diretivas de controle de acesso. As diretivas de autorização são processadas
primeiro (mod_access) e depois as diretivas de autenticação (mod_auth). Segue um exemplo:
<Directory /var/www>
Options Indexes
Order deny,allow
allow from .dominiolocal.com.br
deny from all
AuthName "Acesso ao diretório do servidor Web"
AuthType basic
AuthUserFile /var/cache/apache/senhas
Require valid-user
</Directory>
Para ter acesso ao diretório /var/www, primeiro o computador deve fazer parte do domínio
.dominiolocal.com.br, assim ela passa pelo teste de autorização, depois disso será
necessário fornecer o login e senha para acesso a página, digitando o login e senha corre-
tos, o teste de autenticação será completado com sucesso e o acesso ao diretório /var/www
autorizado.
Capítulo 12. Apache 192
<Directory /var/www>
Options Indexes
Order mutual-failure
allow from .dominiolocal.com.br
deny from lammer.dominiolocal.com.br
AuthName "Acesso ao diretório do servidor Web"
AuthType basic
AuthUserFile /var/cache/apache/senhas
AuthGroupFile /var/cache/apache/grupos
Require group admins
</Directory>
É interessante permitir usuários fazendo conexões de locais confiáveis terem acesso direto sem
precisar fornecer nome e senha e de locais inseguros acessarem somente após comprovarem
quem realmente são. Como é o caso de permitir usuários de uma rede privada terem acesso
completo aos recursos e permitir o acesso externo ao mesmo recurso somente através de senha.
Isto pode ser feito com o uso da diretiva Satisfy junto ao bloco de autorização/autenticação. Vamos
tomar como base o exemplo anterior:
<Directory /var/www>
Options Indexes
Order mutual-failure
allow from .dominiolocal.com.br
deny from lammer.dominiolocal.com.br
AuthName "Acesso ao diretório do servidor Web"
AuthType basic
AuthUserFile /var/cache/apache/senhas
AuthGroupFile /var/cache/apache/grupos
Require group admins
Satisfy any
</Directory>
Note que o exemplo é o mesmo com a adição da diretiva Satisfy any no final do bloco do
arquivo. Quando a opção Satisfy não é especificada, ela assumirá “all” como padrão, ou seja, o
usuário deverá passar no teste de autorização e autenticação para ter acesso.
Capítulo 12. Apache 193
<Directory /var/www>
Options Indexes
AuthName "Acesso ao diretório do servidor Web"
AuthType basic
AuthUserFile /var/cache/apache/senhas
AuthGroupFile /var/cache/apache/grupos
Require group admins
Satisfy any
</Directory>
O arquivo .htaccess deve ser colocado no diretório da página que deverá ter suas permis-
sões de acesso/listagem controladas. A vantagem em relação a inclusão direta de diretivas de
acesso dentro do arquivo de configuração do Apache, é que o controle de acesso poderá ser
definido pelo próprio webmaster da página, sem precisar ter acesso direto a configuração do
Apache, que requerem privilégios de root.
Outro ponto fundamental é que não há necessidade de reiniciar o servidor Web, pois este
arquivo é lido no momento de cada acesso ao diretório que controla. O nome do arquivo
OverRide pode ser definido através da diretiva AccessFileName no arquivo de configuração do
Apache, .htaccess é usado como padrão.
O controle de que opções estarão disponíveis no .htaccess são definidas na diretiva Al-
lowOverride que pode conter o seguintes parâmetros:
Capítulo 12. Apache 194
<Directory />
AllowOverride none
</Directory>
<Directory /var/www>
AllowOverride limit authconfig indexes
</Directory>
Order deny,allow
allow from 192.168.1.0/24
deny from all
AuthName "Acesso a página Web principal da Empresa"
AuthType basic
AuthUserFile /var/cache/apache/senhas
Require valid-user
Satisfy any
Note que a sintaxe é exatamente a mesma das usadas na diretivas de acesso, por este motivo
vou dispensar explicações detalhadas a respeito.
ATENÇÃO: A diretiva Options Indexes deverá ser especificada no AllowOverRide e não no ar-
quivo .htaccess. Agora você já sabe o que fazer se estiver recebendo erros 500 ao tentar
acessar a página (Erro interno no servidor). . .
Se o Navegador (campo User-Agent do cabeçalho http) usado para acessar a página for o
Internet Explorer, a variável EXPLODER será criada e terá o valor verdadeiro (porque
a expressão de SetEnvIf conferiu com a expressão).
Note o uso de “deny from env=VARIÁVEL”. Neste caso se o navegador for o Internet
Explorer, o acesso será bloqueado (pois o navegador conferiu, assim a variável EXPLODER
recebeu o valor verdadeiro).
É permitido especificar as diretivas de acesso normais junto com especificação de variáveis
de ambiente, basta separa-los com espaços. Uma descrição completa dos cabeçalhos HTTP,
conteúdo e parâmetros aceitos por cada um são descritos na RFC 2068.
Capítulo 12. Apache 196
Esta diretiva é semelhante a <Directory> mas trabalha com métodos HTTP (como GET, PUT,
POST, etc) ao invés de diretórios. A diretiva <Limit> pode ser usada dentro da diretiva de
acesso <Directory>, <Location>, mas nenhuma diretiva de controle de acesso pode ser colo-
cada dentro de <Limit>.
Os métodos HTTP válidos são: GET, POST, PUT DELETE, CONNECT, OPTIONS, TRACE,
PATCH, PROPFIND, PROPPATCH, MKCOL, COPY, MOVE, LOCK e UNLOCK. Note que os
métodos são case-sensitive. Por exemplo:
<Directory /var/www>
Option Indexes
<Limit POST PUT DELETE>
Order deny,allow
allow from 192.168.1.0/24
deny from all
</Limit>
</Directory>
Somente permitem o uso dos métodos POST, PUT, DELETE de máquinas da rede interna.
OBS1: Se o método GET é bloqueado, o cabeçalho HTTP também será bloqueado.
OBS2: A diretiva de acesso <Limit> somente terá efeito na diretiva <Location> se for especi-
ficada no arquivo de configuração do servidor web. A diretiva <Location> simplesmente é
ignorada nos arquivos .htaccess. . .
Este abaixo é usado por padrão na distribuição Debian para restringir para somente leitura o
acesso aos diretórios de usuários acessados via módulo mod_userdir:
<Directory /home/*/public_html>
AllowOverride FileInfo AuthConfig Limit
Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec
<Limit GET POST OPTIONS PROPFIND>
Order allow,deny
Allow from all
</Limit>
<Limit PUT DELETE PATCH PROPPATCH MKCOL COPY MOVE LOCK UNLOCK>
Order deny,allow
Deny from all
</Limit>
</Directory>
Esta diretiva é semelhante a <Limit>, mas atinge todos os métodos HTTP, menos os especifi-
cados.
Capítulo 12. Apache 197
<IfModule mod_userdir.c>
UserDir disabled root
UserDir public_html
</IfModule>
Nas linhas acima, as diretivas UserDir somente serão executadas se o módulo mod_userdir.c
estiver carregado através da diretiva LoadModule.
Segue abaixo uma lista de módulos padrões que acompanham do Apache, os módulos mar-
cados com “*” são ativados por padrão:
Criação de Ambiente • * mod_env - Ajusta variáveis de ambiente para scripts CGI/SSI
• * mod_setenvif - Ajusta variáveis de ambiente de acordo com cabeçalhos http
• mod_unique_id - Gera identificadores únicos para requisições
Decisão de tipo de conteúdo de arquivos • * mod_mime - Determinação de
tipo/encodificação do conteúdo (configurado)
• mod_mime_magic - Determinação de tipo/encodificação do conteúdo (automático)
• * mod_negotiation - Seleção de conteúdo baseado nos cabeçalhos “HTTP Ac-
cept*”
Mapeamento de URL • * mod_alias - Tradução e redirecionamento de URL simples
• mod_rewrite - Tradução e redirecionamento de URL avançado
• * mod_userdir - Seleção de diretórios de recursos por nome de usuário
• mod_speling - Correção de URLs digitadas incorretamente
• mod_vhost_alias - Suporte para virtual hosts dinamicamente configurados em
massa.
Capítulo 12. Apache 199
O Apache é bem flexível na especificação do que será registrado em seus arquivos de log,
possibilitando utilizar um arquivo de log único, diversos arquivos de logs registrando cada
evento ocorrido no sistema (conexão, navegador, bloqueio de acesso, erros, etc) incluindo os
campos que deseja em cada arquivo e a ordem dos campos em cada um deles.
Enfim qualquer coisa pode ser especificada de forma que atenda as suas necessidades particu-
lares de logging.
Capítulo 12. Apache 200
12.10.1 AgentLog
12.10.2 ErrorLog
12.10.3 CustomLog
Permite especificar onde os logs serão gravados para os arquivos de logs personalizados. Esta
diretiva também aceita apelidos definidos pela diretiva LogFormat.
CustomLog [arquivo/pipe] [formato/nome]
Onde:
arquivo/pipe Arquivo de log personalizado ou pipe.
formato/nome Especifica o formato do arquivo de log (da mesma forma que o especificado
na opção LogFormat). Deverá ser especificado entre “aspas” caso tiver espaços. Veja
‘LogFormat’ on page 202 para detalhes.
Ao invés de especificar o formato, também é possível usar um apelido definido pela opção
LogFormat (‘LogFormat’ on page 202), neste caso os parâmetros definidos pelo LogFormat para
“nome” serão atribuídos a diretiva CustomLog.
Exemplos:
• CustomLog /var/log/apache/common.log “%h %l %u %t \”%r\“ %>s %b”
• CustomLog /var/log/apache/common.log common
12.10.4 RefererLog
12.10.5 RewriteLog
12.10.6 RewriteLogLevel
12.10.7 ScriptLog
12.10.8 ScriptLogBuffer
12.10.9 ScriptLogLength
12.10.10 LogFormat
LogFormat: Define os campos padrões do arquivo gerado pela opção TransferLog. O seu
formato é o seguinte:
LogFormat [formato] [nome]
Quando o formato não é especificado, assume o valor padrão %h %l %u %t \”%r\“ %s
%b. A especificação do [nome] permite que você utilize o formato especificado em uma opção
CustomLog ou outra diretiva LogFormat, facilitando a especificação do formato do log.
Os seguintes formatos são válidos:
• %b - Bytes enviados, excluindo cabeçalhos HTTP.
• %f - Nome do arquivo.
• %{FOOBAR}e - O conteúdo da variável de ambiente FOOBAR.
• %h - Máquina cliente.
• %a - Endereço IP da máquina cliente.
• %A - Endereço IP local. Muito útil em virtual hostings.
• %{Foobar}i - O conteúdo de Foobar: linhas de cabeçalho na requisição enviada ao
servidor.
• %l - O nome de login remoto enviado pelo identd (se fornecido).
• %{Foobar}n - O conteúdo de ”FooBar“ de outro módulo.
• %{Foobar}o: - O conteúdo de Foobar: linhas de cabeçalho na resposta.
• %p - A porta do servidor servindo a requisição.
• %P - A identificação do processo filho que serviu a requisição.
• %r - A primeira linha da requisição.
• %s - Status. Para requisições que foram redirecionadas. internamente. Este é o status de
uma requisição *original*. Use %s para a última.
• %t - Hora, no formato do arquivo de log (formato inglês padrão).
• %{format}t - Hora, no formato definido por strftime.
• %T - O tempo necessário para servir a requisição, em segundos.
• %u - Usuário remoto (através do auth, pode ser falso se o status de retorno (%s) for 401).
• %U - O caminho da URL requisitada.
• %v - O nome canônico definido por ServerName que serviu a requisição.
• %V - O nome do servidor de acordo com a configuração de UseCanonicalName.
Exemplos:
12.10.11 TransferLog
12.10.12 LogLevel
Define o nível de alerta das mensagens que serão gravadas no arquivo especificado pela di-
retiva ErrorLog. Quando não é especificado, assume o nível ”error“ como padrão. Abaixo os
parâmetros aceitos em sua respectiva ordem de importância:
• emerg - O sistema está inutilizável.
• alert - A ação deve ser tomada imediatamente.
• crit - Condições críticas.
• error - Condições de erro.
• warn - Condições de alerta.
• notice - Condição normal mas significante.
• info - Mensagens informativas.
• debug - Mensagens do nível de depuração.
Note que os níveis são os mesmos usados pelo syslog. Quando um nível particular é especi-
ficado, as mensagens de todos os níveis de maior importância também serão registrados. Por
exemplo, se o nível ”info“ for especificado, as mensagens com os níveis de ”notice“ e ”warn“
também serão registradas. É recomendado o uso de um nível de no mínimo crit.
12.10.13 Anonymous_LogEmail
Se estiver como ”on“ a senha digitada será registrada no arquivo especificado por ErrorLog.
Esta diretiva é ativada por padrão.
Exemplo: Anonymous_LogEmail off
Capítulo 12. Apache 204
12.10.14 CookieLog
O programa webalizer poderá ser instalado para gerar um relatório gráfico com a estatísti-
cas de visitas por ano/mes/dia/hora usando os dados do access.log. Outra interessante
característica são as estatísticas de códigos http (veja ‘Códigos HTTP’ on page 238), onde é pos-
sível saber a quantidade de links quebrados existentes em nosso servidor (estes poderão ser
detectados usando o pacote de análise de sites linbot). O webalizer também é compatível
com os formatos de log do squid e proftpd. Na distribuição Debian ele pode ser instalado
a partir do pacote webalizer e gera um relatório geral quando é executado sem opções.
O Apache pode ser configurado para funcionar como servidor proxy transparente para sua
rede interna, possibilitando inclusive o uso de cache de disco. É possível se fazer conexões
HTTP (incluindo SSL) e FTP. Através desta característica também é possível usar uma das
características mais interessante desse servidor web: o redirecionamento de conexões para
uma determinada URL para uma outra máquina, que pode ser um outro host remoto ou uma
máquina da rede interna (não acessível diretamente via Internet).
O primeiro passo é ativar o módulo de proxy no arquivo httpd.conf, basta descomentar a
linha:
O seguinte bloco pode ser colocado no final do arquivo httpd.conf para configurar um servi-
dor proxy para realizar conexões diretas (sem o uso de cache) e permitir o uso de servidores
proxy em sua rede:
# Suporte a Proxy
#
<IfModule mod_proxy.c>
Capítulo 12. Apache 205
ProxyRequests off
ProxyRemote * http://debian:3128
ProxyBlock microsoft.com microsoft.com.br
NoProxy 192.168.1.0/24
ProxyDomain .gms.com.br
CacheForceCompletion 70
CacheSize 5
CacheGcInterval 3
CacheDefaultExpire 5
CacheMaxExpire 300
NoCache 192.168.1.0/24 a_domain.com outrodomínio.com.br outro.dominio.net
Incluir o bloco abaixo no arquivo access.conf para definir o acesso dos serviços de proxy
nas redes desejadas (se a sua configuração for aberta como padrão isto pode ser opcional):
Para explicações sobre o processo de bloqueio acima, veja ‘Autorização’ on page 183.
Este recurso do Apache é interessante para criar clusters de servidores em sua rede interna.
O que ele faz é pegar uma requisição a um determinado endereço e redireciona-lo a outra
máquina e as respostas são repassadas ao servidor web (para o cliente a mesma máquina esta
atendendo a requisição, para você o processamento das requisições esta sendo distribuído in-
ternamente na rede).
As seguintes diretivas são usadas para realizar o redirecionamento de conexões: ProxyPass e
ProxyPassReverse
ProxyPass [diretório_da_url [outro_servidor:/diretório ] A ProxyPass permite que a URL seja
redirecionada para o servidor local e diretório especificado. Por exemplo, assumindo que
o endereço principal de nosso servidor é http: //www.guiafoca.org e desejamos
que a URL http: //www.guiafoca.org/download seja atendida por uma máquina
localizada na nossa rede privada com o endereço http: //192.168.1.54. Basta in-
cluir a linha:
ProxyPass /download http://192.168.1.54
Qualquer requisição externa a http: //www.guiafoca.org/download
/iniciante será atendida por http: //192.168.1.54/iniciante.
ProxyPassRemote [diretório_da_url [outro_servidor:/diretório ] Esta diretiva permite modi-
ficar o cabeçalho Location nas mensagens de respostas de redirecionamento enviadas
pelo Apache. Isto permite que o endereço retornado seja o do servidor (que faz a inter-
face externa com o cliente) e não da máquina do redirecionamento.
ProxyPass /download http://192.168.1.54
ProxyPassReverse /download http://192.168.1.54
Se a máquina 192.168.1.54 redirecionar a URL para http: //192.168.1.54
/download/iniciante, a resposta será modificada para http: /
/www.guiafoca.org/download/iniciante antes de ser retornada ao cliente.
\
Virtual Hosts (sites virtuais) é um recurso que permite servir mais de um site no mesmo servi-
dor. Podem ser usadas diretivas específicas para o controle do site virtual, como nome do
administrador, erros de acesso a página, controle de acesso e outros dados úteis para person-
alizar e gerenciar o site. Existem 2 métodos de virtual hosts:
• Virtual Hosts baseados em IP - Requer um endereço IP diferente para cada site.
Este poderá ser um IP real (da interface de rede) ou um apelido (veja ‘IP Alias’ on
page 63), o que interessa é que deve haver um endereço IP diferente para cada site. O
número de sites servidos estará limitado a quantidade de endereços IP disponíveis em
sua classe de rede. Veja ‘Virtual hosts baseados em IP’ on the following page para de-
talhes de como construir um virtual host deste tipo. O apache foi um dos primeiros
Capítulo 12. Apache 208
Existem duas maneiras de rodar este tipo de host virtual: Através de daemons httpd separa-
dos ou em um único daemon httpd usando a diretiva <VirtualHost>.
As vantagens do uso de daemons separados para servir requisições é a proteção sob UID
e GID diferente dos outros servidores, assim o administrador do site1 não terá acesso ao
httpd.conf, página do site2 (porque ele estará rodando sob uma UID e GID diferentes
e o acesso é restrito). Para usar este método, especifique a opção -f [arquivo_cfg] para utilizar
um arquivo de configuração personalizado e a diretiva Listen endereço:porta para dizer onde o
servidor aguardará as requisições.
As vantagens do uso de um mesmo daemon para servir as requisições são: quando não há prob-
lema se os administradores de outros sites tenham acesso ao mesmo arquivo de configuração
ou quando há a necessidade de servir muitas requisições de uma só vez (quanto menos servi-
dores web estiverem em execução, melhor o desempenho do sistema). Abaixo um exemplo de
configuração de virtual hosts servindo os sites www.site1.com.br e www.site2.com.br:
ServerAdmin webmaster@site.com.br
<VirtualHost www.site1.com.br>
ServerName www.site1.com.br
ServerAdmin site1@site1.com.br
DocumentRoot /var/www/www_site1_com_br
TransferLog /var/log/apache/site1/access.log
ErrorLog /var/log/apache/site1/error.log
User www-data
Group www-data
</VirtualHost>
<VirtualHost www.site2.com.br>
ServerName www.site2.com.br
DocumentRoot /var/www/www_site2_com_br
CustomLog /var/log/apache/site2/access.log combined
ErrorLog /var/log/apache/site2/error.log
</VirtualHost>
Capítulo 12. Apache 209
Qualquer diretiva dentro de <VirtualHost> controlarão terão efeito no site virtual especificado.
Quando uma diretiva não for especificada dentro de <VirtualHost>, serão usados os valores
padrões especificados no arquivo de configuração do Apache (como a diretiva ServerAdmin
webmaster@site.com.br que será usado como padrão na configuração de www.site2.com.br).
Digite apache -S para ver suas configurações de virtual hosts atual.
OBS1: Desative a diretiva UseCanonicalName off quando utilizar o recurso de máquinas
virtuais, esta diretiva faz que o nome do servidor retornado usando o valor em ServerName
quando o cliente digita um endereço qualquer.
OBS2: Utilize sempre que possível endereços IP em configurações críticas, assim os serviços
não serão tão vulneráveis a possíveis falsificações ou erros. Veja ‘/etc/host.conf’ on page 50 e
‘Proteção contra IP spoofing’ on page 143. Leia também a seção ‘Segurança no uso de IP’s em
Virtual Hosts’ on page 211.
OBS3: Não permita que outros usuários a não ser o root e o dono do processo Apache (es-
pecificado pela diretiva User) tenham acesso de gravação aos logs gerados pelo servidor, pois
os dados podem ser apagados ou criados links simbólicos para binários do sistema que serão
destruídos quando o Apache gravar dados. Alguns binários e bibliotecas são essenciais para
o funcionamento do sistema.
NameVirtualHost 200.200.200.10:80
<VirtualHost 200.200.200.10>
ServerName www.site1.com.br
ServerAdmin admin1@site1.com.br
DocumentRoot /var/www/www_site1_com_br
TransferLog /var/log/apache/site1/access.log
ErrorLog /var/log/apache/site1/error.log
</VirtualHost>
<VirtualHost 200.200.200.10>
Capítulo 12. Apache 210
ServerName www.site2.com.br
ServerAdmin admin2@site2.com.br
DocumentRoot /var/www/www_site2_com_br
TransferLog /var/log/apache/site2/access.log
ErrorLog /var/log/apache/site2/error.log
</VirtualHost>
A diretiva NameVirtualHost diz que será usado virtual hosts baseados em nome servidos pela
máquina com IP 200.200.200.10. Os parâmetros dentro do bloco das diretivas <Virtual-
Host > são específicas somente no site virtual especificado, caso contrário os valores padrões
definidos no arquivo de configuração serão usados. Caso nenhum virtual host confira com a
configuração, o virtualhost _default_ será usado.
Digite apache -S para ver suas configurações de virtual hosts atual. Se sua intenção é criar
um grande número de virtual hosts que serão servidos pela mesma máquina, o uso da expan-
são %0 e diretivas VirtualDocumentRoot e VirtualScriptAlias são recomendados:
NameVirtualHost 200.200.200.10:80
<VirtualHost 200.200.200.10>
VirtualDocumentRoot /var/www/%0
VirtualScriptAlias /var/www/%0/cgi-bin
TransferLog log/apache/site1/access.log
ErrorLog log/apache/site1/error.log
</VirtualHost>
OBS1: Utilize sempre que possível endereços IP em configurações críticas, assim os serviços
não serão tão vulneráveis a possíveis falsificações ou erros. Veja ‘/etc/host.conf’ on page 50 e
‘Proteção contra IP spoofing’ on page 143. Leia também a seção ‘Segurança no uso de IP’s em
Virtual Hosts’ on the next page.
OBS2: Não permita que outros usuários a não ser o root e o dono do processo Apache (es-
pecificado pela diretiva User) tenha acesso de gravação aos logs gerados pelo servidor. Pois
os dados podem ser apagados ou criados links para binários do sistema que serão destruídos
quando o apache gravar dados para os logs. Alguns binários e bibliotecas são essenciais para
o funcionamento do sistema.
Capítulo 12. Apache 211
Quando você está colocando um nome na diretiva de configuração do seu virtual hosts,
está assumindo que ele resolverá o endereço IP corretamente (como www.site1.com.br =>
200.200.200.10). Se por algum motivo o servidor DNS for modificado (por outra pessoa
que tem acesso a isto), o endereço IP resolvido para o site www.site1.com.br poderá ser
modificado para 200.200.200.20, isto redirecionará as requisições para outra máquina ao
invés da máquina correta. Este tipo de ataque é chamado ”DNS Spoofing“ e o uso de endereço
IP (ao invés de nomes) praticamente evita que isto aconteça. Esta situação pode acontecer com
a diretiva abaixo:
<VirtualHost www.gms.com.br>
ServerName www.gms.com.br
ServerAdmin gleydson@guiafoca.org
DocumentRoot /var/www/www_gms_com_br
</VirtualHost>
Outra situação, que impede o funcionamento do servidor Web, é quando o servidor DNS está
em manutenção ou por algum outro motivo não pode resolver o endereço IP de um nome
especificado (como www.site1.com.br). O apache precisa saber qual é o seu endereço IP
para ser executado. Veja a próxima modificação:
<VirtualHost 192.168.1.1>
ServerName www.gms.com.br
ServerAdmin gleydson@guiafoca.org
DocumentRoot /var/www/www_gms_com_br
</VirtualHost>
desviando o tráfego para seu próprio servidor web. Se isto não for possível, siga as dicas
abaixo para diminuir possíveis problemas.
3 Utilize endereços IP na diretiva <VirtualHost>.
4 Use endereços IP na diretiva Listen.
5 Use um endereço IP na diretiva BindAddress.
6 Sempre utilize o parâmetro ServerName em todas as diretivas <VirtualHost>, isto evita o
retorno incorreto de nomes (que pode evitar/revelar fraudes).
7 Quando utilizar virtual hosts, crie uma diretiva <VirtualHost _default_L:*> usando uma
diretiva DocumentRoot que não aponte para lugar algum. Esta diretiva será acessada
quando nenhuma diretiva VirtualHost servir a requisição, conferindo com o endereço/ip.
Esta seção é uma referência rápida para configuração e uso do módulo apache-ssl com o
servidor Apache. Este módulo realiza a comunicação segura de dados (criptografada) via
porta 443 (que é usada como padrão quando especificamos uma url iniciando com https://).
A transmissão criptografada de dados é importante quanto temos dados confidenciais que
precisamos transmitir como movimentação bancária, senhas, número de cartões de crédito,
fazer a administração remota do servidor, etc. SSL significa Secure Sockets Layer (camada segura
de transferência) e TLS Transport Layer Security (camada segura de Transporte).
A intenção aqui é fornecer explicações práticas para colocar um servidor Apache com suporte
a SSL funcionando no menor tempo possível. Detalhes sobre funcionamento de certificados,
métodos de criptografia, assinatura, etc. deverão ser buscados na documentação deste módulo
ou em sites especializados (é um assunto muito longo).
Ao invés de utilizar o módulo mod_ssl, você poderá usar o pacote apache-ssl, ele nada
mais é que um servidor Apache com o suporte SSL já incluso e não interfere no servidor
Apache padrão, porque é executado somente na porta 443.
Se você tem um grande site com configurações de acesso personalizadas, ele trará mais tra-
balho de administração, pois as configurações e diretivas de restrições de acesso deverão ser
copiadas para este servidor web. No entanto, ele é indicado para máquinas que serão servi-
dores SSL dedicados ou quando não possui configurações especiais em seu servidor web prin-
cipal.
Esta seção tem por objetivo a instalação do suporte ao módulo SSL (mod_ssl) no servidor
Apache padrão.
Depois, gere um certificado digital ssl com o programa mod-ssl-makecert. Ele será ar-
mazenado por padrão nos diretórios em /etc/apache/ssl.??? e seu uso explicado no
resto desta seção.
O certificado digital é a peça que garante a transferência segura de dados. Ele contém detalhes
sobre a empresa que fará seu uso e quem o emitiu. Para gerar ou modificar um certificado dig-
ital, execute o comando mod-ssl-makecert e siga as instruções. O método de criptografia
usado pelo certificado digital é baseado no conceito de chave pública/privada, a descrição
sobre o funcionamento deste sistema de criptografia é feito em ‘Usando pgp (gpg)para crip-
tografia de arquivos’ on page 408.
OBS Não utilize acentos nos dados de seu certificado.
Abaixo uma configuração rápida para quem deseja ter um servidor com suporte a SSL funcio-
nando em menor tempo possível (ela é feita para operar em todas as instalações e não leva em
consideração o projeto de segurança de sua configuração atual do Apache). Note que todas as
diretivas relacionadas com o módulo mod_ssl começam com o nome ”SSL“:
# Certificado do servidor
SSLCertificateFile /etc/apache/ssl.crt/server.crt
</VirtualHost>
</IfModule>
##############################################################################
# Adicionalmente poderão ser especificadas as seguintes opções para modificar
# o comportamento da seção SSL (veja mais detalhes na documentação do mod-ssl)
##############################################################################
SSLSessionCacheTimeout 300
Algumas diretivas deste módulo podem fazer parte tanto da configuração global do servidor
como diretivas de acesso (Directory, Location, .htaccess, veja a opção ”Context“ na
documentação do mod_ssl).
Existem casos que precisa restringir o uso de conexões normais e permitir somente conexões
via SSL (como por exemplo, dentro da diretiva de acesso que controla seu acesso a uma página
com listagem de clientes). A opção SSLRequereSSL é usada para tal e deve ser usada dentro das
diretivas de controle acesso:
<Directory /var/www/secure/clientes>
Options Indexes
Order deny,allow
Deny from evil.cracker.com
SSLRequireSSL
</Directory>
A diretiva acima requer que sejam feitas conexões SSL (porta 443 - https://) para acesso ao
diretório /var/www/secure/clientes, qualquer conexão padrão não criptografada (feita
na porta 80) será rejeitada com o erro 403.
OBS: A diretiva SSLRequireSSL podia ser colocada entre as condicionais ”IfModule mod_ssl.c“
mas o servidor web permitiria conexões não criptografadas se por algum motivo esse módulo
não estivesse carregado. Na configuração acima, ocorrerá um erro e impedirá o funcionamento
do servidor web caso ocorra algum problema com o mod_ssl.
Verifique se a configuração do Apache está ok com apache -t. Caso positivo, reinicie o servi-
dor usando um dos métodos descritos em ‘Iniciando o servidor/reiniciando/recarregando a
Capítulo 12. Apache 216
configuração’ on page 174. O servidor web lhe pedirá a FraseSenha para descriptografar a
chave privada SSL (esta senha foi escolhida durante o processo de criação do certificado).
Esta senha garante uma segurança adicional caso a chave privada do servidor seja copiada de
alguma forma. Somente quem tem conhecimento da FraseSenha poderá iniciar o servidor com
suporte a transferência segura de dados. Verifique se o virtual host está servindo as requisições
na porta 443 com apache -S.
O único método para fazer o servidor web evitar de pedir a senha para descriptografar a chave
privada é colocando uma senha em branco. Isto só é recomendado em ambientes seguros e
o diretório que contém a chave privada deverá ter somente permissões para o dono/grupo
que executa o servidor Web. Qualquer outra permissão poderá por em risco a segurança da
instalação caso a chave privada seja roubada. Depois disso, execute o comando:
Digite a senha quando pedido. A chave original (com senha) estará gravada no arquivo
server.key-Csenha e poderá ser restaurada se necessário. Reinicie o servidor Apache,
desta vez ele não pedirá a senha.
OBS1: Tire uma cópia de segurança da chave privada original antes de executar esta operação.
OBS2: Não se esqueça de ajustar as permissões de acesso no diretório /etc/apache
/ssl.key caso não utilize senha para proteger seu certificado digital.
O exemplo abaixo foi retirado da distribuição Debian GNU/Linux, fiz sua tradução, mod-
ificações e inclui alguns comentários sobre as diretivas para deixa-lo mais de acordo com o
conteúdo abordado pelo guia e mais auto-explicativo.
A configuração do Apache está distribuída nos arquivos httpd.conf, srm.conf e
access.conf e podem ser usados como modelo para a construção da configuração de seu
servidor.
12.14.1 httpd.conf
##
## httpd.conf -- Arquivo de configuração do servidor httpd Apache
##
Capítulo 12. Apache 217
#
# Baseado nos arquivos de configuração originais do servidor NCSA por Rob McCo
# Modificado para distribuição junto ao guia Foca GNU/Linux Avançado
# http://focalinux.cipsga.org.br/ <gleydson@guiafoca.org>
#
# Este é o arquivo de configuração principal do servidor Apache. Ele contém as
# diretivas de configuração que dão ao servidor suas instruções.
# Veja <http://www.apache.org/docs/> para informações detalhadas sobre as
# diretivas.
#
# NÃO leia simplesmente as instruções deste arquivo sem entender o que signifi
# e o que fazem, se não tiver certeza do que está fazendo consulte a documenta
# on-line ou leia as seções apropriadas do guia. Você foi avisado.
#
# Após este arquivo ser processado, o servidor procurará e processará o arquiv
# /etc/apache/srm.conf e então /etc/apache/access.conf
# a não ser que você tenha modificado o nome dos arquivos acima através das
# diretivas ResourceConfig e/ou AccessConfig neste arquivo.
#
# Configuração e nomes de arquivos de log: Se os nomes de arquivos que
# especificar para os arquivos de controle do servidor iniciam com uma
# "/", o servidor usará aquele caminho explicitamente. Se os nomes *não*
# iniciarem com uma "/", o valor de ServerRoot é adicionado -- assim
# "logs/foo.log" com ServerRoot ajustado para "/usr/local/apache" será
# interpretado pelo servidor como "/usr/local/apache/logs/foo.log".
#
# Originalmente por Rob McCool
# modificado por Gleydson Mazioli da Silva para o guia Foca GNU/Linux
#
# ServerType pode ser inetd, ou standalone. O modo Inetd somente é suportado
# plataformas Unix. O modo standalone inicia o servidor como um daemon.
#
ServerType standalone
# Port: A porta que o servidor standalone escutará. Para portas < 1023, será
Capítulo 12. Apache 218
Port 80
#
# HostnameLookups: Registra os nomes DNS dos clientes ou apenas seus endereços
# IP’s
# ex., www.apache.org (on) ou 204.62.129.132 (off).
# O valor padrão é off porque permitirá menos tráfego na rede. Ativando
# esta opção significa que cada acesso de um cliente resultará em
# NO MÍNIMO uma requisição de procura ao servidor de nomes (DNS).
#
HostnameLookups off
# Caso desejar que o servidor http seja executado como um usuário ou grupo dif
# você deve executar o httpd inicialmente como root e ele modificará sua ID pa
# especificada.
User www-data
Group www-data
#
# ServerRoot: O topo da árvore de diretórios onde os arquivos de configuração
# servidor, erros, e log são mantidos.
#
# NOTA: Se tiver a intenção de colocar isto em um sistema de arquivos montado
# em um servidor NFS (ou outra rede) então por favor leia a documentação do
# LockFile
# (disponível em <http://www.apache.org/docs/mod/core.html#lockfile>);
# e se salvará de vários problemas.
#
# Não adicione uma barra no fim do caminho do diretório.
#
ServerRoot /etc/apache
Capítulo 12. Apache 219
BindAddress *
#
# Suporte a Objetos Compartilhados Dinamicamente (DSO - Dynamic Shared Object)
#
# Para ser capaz de usar a funcionalidade de um módulo que foi compilado como
# um módulo DSO, você terá que adicionar as linhas ’LoadModule’ correspondente
# nesta localização, assim as diretivas contidas nela estarão disponíveis
# _antes_ de serem usadas. Por favor leia o arquivo README.DSO na distribuição
# 1.3 do Apache para mais detalhes sobre o mecanismo DSO e execute o comando
# "apache -l" para a lista de módulos já compilados (estaticamente linkados e
# assim sempre disponíveis) em seu binário do Apache.
#
# Please keep this LoadModule: line here, it is needed for installation.
# LoadModule vhost_alias_module /usr/lib/apache/1.3/mod_vhost_alias.so
# LoadModule env_module /usr/lib/apache/1.3/mod_env.so
LoadModule config_log_module /usr/lib/apache/1.3/mod_log_config.so
# LoadModule mime_magic_module /usr/lib/apache/1.3/mod_mime_magic.so
LoadModule mime_module /usr/lib/apache/1.3/mod_mime.so
LoadModule negotiation_module /usr/lib/apache/1.3/mod_negotiation.so
LoadModule status_module /usr/lib/apache/1.3/mod_status.so
# LoadModule info_module /usr/lib/apache/1.3/mod_info.so
# LoadModule includes_module /usr/lib/apache/1.3/mod_include.so
LoadModule autoindex_module /usr/lib/apache/1.3/mod_autoindex.so
LoadModule dir_module /usr/lib/apache/1.3/mod_dir.so
LoadModule php3_module /usr/lib/apache/1.3/libphp3.so
LoadModule cgi_module /usr/lib/apache/1.3/mod_cgi.so
# LoadModule asis_module /usr/lib/apache/1.3/mod_asis.so
# LoadModule imap_module /usr/lib/apache/1.3/mod_imap.so
# LoadModule action_module /usr/lib/apache/1.3/mod_actions.so
# LoadModule speling_module /usr/lib/apache/1.3/mod_speling.so
LoadModule userdir_module /usr/lib/apache/1.3/mod_userdir.so
LoadModule alias_module /usr/lib/apache/1.3/mod_alias.so
LoadModule rewrite_module /usr/lib/apache/1.3/mod_rewrite.so
LoadModule access_module /usr/lib/apache/1.3/mod_access.so
LoadModule auth_module /usr/lib/apache/1.3/mod_auth.so
# LoadModule anon_auth_module /usr/lib/apache/1.3/mod_auth_anon.so
# LoadModule dbm_auth_module /usr/lib/apache/1.3/mod_auth_dbm.so
# LoadModule db_auth_module /usr/lib/apache/1.3/mod_auth_db.so
# LoadModule proxy_module /usr/lib/apache/1.3/libproxy.so
Capítulo 12. Apache 220
#
# ExtendedStatus: Controla de o Apache gerará detalhes completos de status
# (ExtendedStatus On) ou apenas detalhes básicos (ExtendedStatus Off) quando o
# manipulador (handler) "server-status" for usado. O padrão é Off.
#
ExtendedStatus on
#
# ErrorLog: A localização do arquivo de log de erros.
# Se não estiver especificando a diretiva ErrorLog dentro de <VirtualHost>,
# as mensagens de erros relativas aos hosts virtuais serão registradas neste
# arquivo. Se definir um arquivo de log de erros para <VirtualHost>, as
# mensagens relativas ao servidor controlados por ela serão registradas lá e
# não neste arquivo.
#
ErrorLog /var/log/apache/error.log
#
# LogLevel: Controla o número de mensagens registradas no ErrorLog.
# Facilidades possíveis incluem: debug, info, notice, warn, error, crit,
# alert, emerg.
# Veja as facilidades na seção do guia sobre o syslog para detalhes
#
LogLevel warn
# As seguintes diretivas definem alguns formatos de nomes que serão usadas com
# diretiva CustomLog (veja abaixo).
#
# A localização e formato do arquivo de log de acesso (definida pela diretiva
# LogFormat acima).
# Se não definir quaisquer arquivos de log de acesso dentro de um
# <VirtualHost>, elas serão registradas aqui. Se for definida dentro
# de <VirtualHost> o arquivo de log de acesso será registrado no
# arquivo especificado na diretiva e não aqui.
#
#CustomLog /var/log/apache/access.log common
# Se você desejar ter um arquivo de log separado para o agent (navegador usado
# e referer, descomente as seguintes diretivas.
#
# Incluir uma linha contendo a versão do servidor e um nome de host virtual
# para as páginas geradas pelo servidor (documentos de erro, listagens
# de diretórios FTP, saída dos módulos mod_status e mod_info, etc., exceto
# para documentos gerados via CGI). Use o valor "EMail" para também incluir
# um link mailto: para o ServerAdmin. Escolha entre "On", "Off" ou "EMail".
#
ServerSignature On
#
# PidFile: O arquivo que o servidor gravará os detalhes sobre seu PID quando
# iniciar.
#
PidFile /var/run/apache.pid
#
# ScoreBoardFile: Arquivo usado para armazenar detalhes do processo interno do
# servidor. Nem todas as arquiteturas requerem esta diretiva, mas se a sua
# requerer (você saberá porque este arquivo será criado quando executar o
Capítulo 12. Apache 222
# Apache) então você *deverá* ter certeza que dois processos do Apache não
# utilizam o mesmo arquivo ScoreBoardFile.
#
ScoreBoardFile /var/run/apache.scoreboard
#
# Na configuração padrão, o servidor processará este arquivo, o
# srm.conf e o access.conf neste ordem. Você pode fazer o servidor
# ignorar estes arquivos usando "/dev/null".
#
ResourceConfig /etc/apache/srm.conf
AccessConfig /etc/apache/access.conf
#
# A diretiva LockFile define o caminho do lockfile usado quando o servidor
# Apache for compilado com a opção USE_FCNTL_SERIALIZED_ACCEPT ou
# USE_FLOCK_SERIALIZED_ACCEPT. Esta diretiva normalmente deve ser deixada em s
# valor padrão. A razão principal de modifica-la é no caso do diretório de log
# for montado via um servidor NFS< pois o arquivo especificado em LockFile
# DEVE SER ARMAZENADO EM UM DISCO LOCAL. O PID do processo do servidor princip
# é automaticamente adicionado neste arquivo.
#
LockFile /var/run/apache.lock
ServerName debian.meudominio.org
#CacheNegotiatedDocs
Timeout 300
# KeepAlive: Se vai permitir ou não conexões persistentes (mais que uma requis
# por conexão). Mude para "Off" para desativar.
KeepAlive On
MaxKeepAliveRequests 100
KeepAliveTimeout 15
MinSpareServers 5
MaxSpareServers 10
# Número de servidores que serão iniciados --- deve conter um valor razoável.
StartServers 5
Capítulo 12. Apache 224
MaxClients 150
#
# MaxRequestsPerChild: O número de requisições que cada processo tem permissão
# de processar antes do processo filho ser finalizado. O filho será finalizado
# para evitar problemas após uso prolongado quando o Apache (e talvez as
# bibliotecas que utiliza) tomar memória e outros recursos. Na maioria dos
# sistemas, isto realmente não é necessário, exceto para alguns (como o
# Solaris) que possuem ponteiros notáveis em suas bibliotecas. Para estas
# plataformas, ajuste para algo em torno de 10000 ou algo assim; uma
# configuração de 0 significa ilimitado.
#
# NOTA: Este valor não inclui requisições keepalive após a requisição
# inicial por conexão. Por exemplo, se um processo filho manipula
# uma requisição inicial e 10 requisições "keptalive" subseqüentes,
# ele somente contará 1 requisição neste limite.
#
MaxRequestsPerChild 30
#Listen 3000
#Listen 12.34.56.78:80
#<VirtualHost host.some_domain.com>
#ServerAdmin webmaster@host.some_domain.com
#DocumentRoot /var/www/host.some_domain.com
#ServerName host.some_domain.com
#ErrorLog /var/log/apache/host.some_domain.com-error.log
Capítulo 12. Apache 225
#TransferLog /var/log/apache/host.some_domain.com-access.log
#</VirtualHost>
#
# Se desejar usar hosts virtuais baseados em nome, será necessário definir no
# mínimo um endereço IP (e número de porta) para eles.
#
#NameVirtualHost 12.34.56.78:80
#NameVirtualHost 12.34.56.78
#
# Exemplo de um Host Virtual:
# Praticamente qualquer diretiva do Apache pode entrar na condicional
# VirtualHost.
#
#<VirtualHost ip.address.of.host.some_domain.com>
# ServerAdmin webmaster@host.some_domain.com
# DocumentRoot /www/docs/host.some_domain.com
# ServerName host.some_domain.com
# ErrorLog logs/host.some_domain.com-error.log
# CustomLog logs/host.some_domain.com-access.log common
#</VirtualHost>
#<VirtualHost _default_:*>
#</VirtualHost>
12.14.2 srm.conf
# exceto links simbólicos e aliases que podem ser usados para apontar para
# outras localizações no sistema de arquivos.
DocumentRoot /var/www
#
# UserDir: O nome do diretório que será adicionado ao diretório home do usuári
# caso uma requisição ~usuário for recebida.
#
<IfModule mod_userdir.c>
# Linha abaixo por recomendação de segurança do manual do Apache
UserDir disabled root
UserDir public_html
</IfModule>
#
# DirectoryIndex: Nome do arquivo ou arquivos que serão usados como índice do
# diretório. Especifique mais de um arquivos separados por espaços ao invés
# de um só um nome (como "index") para aumentar a performance do servidor.
#
<IfModule mod_dir.c>
DirectoryIndex index.html index.htm index.shtml index.cgi
</IfModule>
#
# Diretivas que controlam a exibição de listagem de diretórios geradas pelo se
#
<IfModule mod_autoindex.c>
#
# FancyIndexing: se você deseja o padrão fancy index ou padrão para a inde
# de arquivos no diretório. Usando FancyIndexing o servidor
# apache gerará uma listagem de arquivos que poderá ser
# ordenada, usar tipos de ícones e encoding, etc. Veja as
# próximas opções
IndexOptions FancyIndexing
#
# As diretivas AddIcon* dizem ao servidor que ícone mostrar para um determ
# arquivo ou extensão de arquivos. Estes somente são mostrados para os
# diretórios classificados através da opção FancyIndexing.
#
AddIconByEncoding (CMP,/icons/compressed.gif) x-compress x-gzip
AddIcon /icons/back.gif ..
AddIcon /icons/hand.right.gif README
AddIcon /icons/folder.gif ^^DIRECTORY^^
AddIcon /icons/blank.gif ^^BLANKICON^^
# DefaultIcon é o ícone que será mostrado para aplicativos que não tiverem
# ícone explicitamente definido.
DefaultIcon /icons/unknown.gif
#
# AddDescription: isto lhe permite colocar uma curta descrição após um arq
# nos índices gerados pelo servidor. Estes somente são mostrados para dire
# com índices organizados usando a opção FancyIndexing.
# Formato: AddDescription "descrição" extensão
#
#AddDescription "GZIP compressed document" .gz
#AddDescription "tar archive" .tar
#AddDescription "GZIP compressed tar archive" .tgz
#
# O servidor procurará primeiro por nome.html, incluído se ele for encontr
# e então procurará pelo nome e incluirá ele como texto plano se encontrad
ReadmeName README
#
# IndexIgnore: um conjunto de nomes de arquivos que a listagem de diretóri
# deve ignorar e não incluir na listagem. É permitido o uso de coringas
# como no interpretador de comandos.
#
IndexIgnore .??* *~ *# HEADER* README* RCS CVS *,v *,t
</IfModule>
AccessFileName .htaccess
#
# DefaultType é o tipo MIME padrão que o servidor utilizará para um documento
# caso ele não possa determinar seu conteúdo, como através de extensões
# de arquivos. Se o servidor contém em sua maioria texto ou documentos em HTML
# "text/plain" é um bom valor. Caso a maioria do conteúdo seja binários, tal
# como aplicativos ou fotos, o tipo mais adequado ao seu caso poderá ser
# "application/octet-stream" para evitar que navegadores tentem exibir
# aplicativos binários como se fossem texto.
# Se desejar uma referência rápida sobre tipos mime, consulte o arquivo
# /etc/mime.types
#
Capítulo 12. Apache 229
DefaultType text/plain
#
# Document types.
#
<IfModule mod_mime.c>
AddEncoding x-compress Z
AddEncoding x-gzip gz tgz
#
# AddLanguage: permite especificar o idioma do documento. Você pode
# então usar a negociação de conteúdo para dar ao navegador um
# arquivo no idioma solicitado.
#
# Nota 1: O sufixo não precisa ser o mesmo da palavra chave do
# idioma --- estes com o documento em Polonês (no qual o
# código padrão da rede é pl) pode desejar usar "AddLanguage pl .po"
# para evitar confusão de nomes com a extensão comum de scripts
# scripts em linguagem Perl.
#
# Nota 2: As entradas de exemplos abaixo mostram que em alguns casos
# as duas letras de abreviação do ’Idioma’ não é idêntico as duas letras
# do ’País’ para seu país, como ’Danmark/dk’ versus ’Danish/da’.
#
# Nota 3: No caso de ’ltz’ nós violamos a RFC usando uma especificação de
# três caracteres. Mas existe um ’trabalho em progresso’ para corrigir ist
# e obter os dados de referência para limpar a RFC1766.
#
# Danish (da) - Dutch (nl) - English (en) - Estonian (ee)
# French (fr) - German (de) - Greek-Modern (el)
# Italian (it) - Portugese (pt) - Luxembourgeois* (ltz)
# Spanish (es) - Swedish (sv) - Catalan (ca) - Czech(cz)
# Polish (pl) - Brazilian Portuguese (pt-br) - Japanese (ja)
#
AddLanguage da .dk
AddLanguage nl .nl
AddLanguage en .en
AddLanguage et .ee
AddLanguage fr .fr
Capítulo 12. Apache 230
AddLanguage de .de
AddLanguage el .el
AddLanguage it .it
AddLanguage ja .ja
# AddCharset ISO-2022-JP .jis
AddLanguage pl .po
# AddCharset ISO-8859-2 .iso-pl
AddLanguage pt .pt
AddLanguage pt-br .pt-br
AddLanguage ltz .lu
AddLanguage ca .ca
AddLanguage es .es
AddLanguage sv .se
AddLanguage cz .cz
#
# AddType permite modificar o mime.types sem editar o arquivo, ou fazer
# a associação de arquivos a certos tipos de conteúdo.
#
# Por exemplo, o módulo PHP 3.x (que não faz parte da distribuição do
# Apache - veja http://www.php.net) tipicamente utiliza isto:
#
#AddType application/x-httpd-php3 .php3
#AddType application/x-httpd-php3-source .phps
#
# E para arquivos PHP 4.x use:
#
#AddType application/x-httpd-php .php
#AddType application/x-httpd-php-source .phps
# hdml
AddType text/x-hdml .hdml
Capítulo 12. Apache 231
#
# AddHandler permite mapear certas extensões de arquivos a programas
# "manipuladores" adequados a seu conteúdo. Estes podem ser construídos
# no servidor ou adicionados com o comando Action (veja abaixo).
#
# Se desejar usar includes no lado do servidor, ou servir diretórios
# com scripts CGI para fora, descomente as seguintes linhas.
#
# Para usar scripts CGI:
#
#AddHandler cgi-script .cgi .sh .pl
#
# Para usar arquivos html gerados através do servidor
#
#AddType text/html .shtml
#AddHandler server-parsed .shtml
#
# Descomente as seguintes linhas para ativar a características de arquivos
# send-asis HTTP do servidor Apache
#
#AddHandler send-as-is asis
#
# Se desejar usar arquivos de mapas de imagens processadas no servidor, us
#
#AddHandler imap-file map
#
# Para ativar tipo de mapas, você poderá usar
#
#AddHandler type-map var
</IfModule>
# Fim dos tipos de documentos
AddDefaultCharset on
AddDefaultCharsetName iso-8859-1
# Redirect permite dizer aos clientes que documentos não existem mais no seu s
# e a nova localização do documento.
# Format: Redirect nomeurl url
Capítulo 12. Apache 232
# Aliases: Inclua aqui quantos apelidos você desejar (sem limite) o formato é:
# Alias nomeurl nomereal
# "nomeurl" é o caminho especificado na url e "nomereal" é a localização
# do documento no sistema de arquivos local
#
# Action: permite definir os tipos de mídia que executarão um script quando um
# arquivo que conferir for chamado. Isto elimina a necessidade de caminhos de
# repetidas para processadores de arquivos CGI freqüentemente usados.
# Format: Action media/type /cgi-script/location
# Format: Action handler-name /cgi-script/location
#
#
# MetaDir: especifica o nome do diretório no qual o apache procurará arquivos
# detalhes do módulo mod_cern_meta. Os módulos meta contém cabeçalhos HTTP
# adicionais que serão incluídos durante o envio do documento.
#
#MetaDir .web
#
# Resposta de erros personalizada (no estilo do Apache)
# estas podem ser 3 tipos:
#
# 1) texto plano
#ErrorDocument 500 "O servidor fez boo boo.
# n.b. a aspa (") marca como texto, ela não será exibida
#
# 2) redirecionamentos locais
Capítulo 12. Apache 233
#
# O módulo mod_mime_magic permite o servidor usar várias dicas através do cont
# do arquivo para determinar o seu tipo. A diretiva MIMEMagicFile diz ao módul
# onde as definições de dicas estão localizadas. O módulo mod_mime_magic não é
# parte do servidor padrão Apache (você precisará adiciona-lo manualmente com
# uma linha LoadModule (veja o parágrafo DSO na seção Ambiente Global no
# arquivo httpd.conf), ou recompile o servidor e inclua mod_mime_magic como
# parte de sua configuração), por este motivo ele está entre as condicionais
# <IfModule>. Isto significa que a diretiva MIMEMagicFile somente será process
# caso o módulo estiver ativo no servidor.
#
<IfModule mod_mime_magic.c>
MIMEMagicFile conf/magic
</IfModule>
<IfModule mod_setenvif.c>
#
# As seguintes diretivas modificam o funcionamento da resposta normal do
# servidor HTTP.
# A primeira diretiva desativa o keepalive para o Netscape 2.x e navegador
# as falsificam. Existem problemas conhecidos com estas implementações de
# navegadores. A segunda diretiva é para o MS IE 4.0b2 que tem uma impleme
# defeituosa do HTTP/1.1 e não suporta adequadamente o keepalive quando el
# utiliza as respostas de redirecionamento 301 e 302.
#
BrowserMatch "Mozilla/2" nokeepalive
BrowserMatch "MSIE 4\.0b2;" nokeepalive downgrade-1.0 force-response-1.0
#
# As seguintes diretivas desativam as respostas HTTP/1.1 para navegadores
# violam a especificação HTTP/1.0 não sendo capaz de enviar uma resposta
# 1.1 básica.
#
BrowserMatch "RealPlayer 4\.0" force-response-1.0
Capítulo 12. Apache 234
12.14.3 access.conf
# Cada diretório que o Apache possui acesso, pode ser configurado respectivame
# com quais serviços e características que podem ser permitidas e/ou bloqueada
# no diretório (e seus subdiretórios).
#
# Primeiro a configuração restringe uma série de permissões
<Directory />
Options SymLinksIfOwnerMatch
AllowOverride None
# Order deny,allow
# Deny from all
</Directory>
# Esta parte deve ser modificada para a localização do documento raíz do servi
<Directory /var/www>
# Esta opção controla que opções os arquivos .htaccess nos diretórios podem se
# substituídas. Pode também conter "All", ou qualquer combinação de "Options",
# "FileInfo", "AuthConfig", e "Limit"
AllowOverride None
# Controla quem pode obter materiais deste servidor. Leia a seção adequada no
# guia para mais explicações sobre a ordem de acesso, padrões e valores permit
order allow,deny
allow from all
</Directory>
#
# O diretório "/usr/lib/cgi-bin" deve ser modificado para o diretório que
# possuem seus scripts CGI, caso tenha configurado o suporte a CGI’s no
# servidor.
#
<Directory /usr/lib/cgi-bin/>
AllowOverride None
Options ExecCGI
Order allow,deny
Allow from all
</Directory>
#
# Permite ver relatórios de status e funcionamento do servidor web e
# processos filhos, através da URL http://servidor/server-status
# isto requer o módulo status_module (mod_status.c) carregado no arquivo
# httpd.conf
#
#<Location /server-status>
# SetHandler server-status
# Order deny,allow
# Deny from all
# Allow from .meudominio.org
#</Location>
#
# Permite relatório de configuração remota do servidor, através da URL
# http://servername/server-info
Capítulo 12. Apache 236
<Directory /usr/doc>
Options Indexes FollowSymLinks
order deny,allow
deny from all
allow from 192.168.1.10/24
</Directory>
#
# As seguintes linhas previnem os arquivos .htaccess de serem mostrados nos
# clientes Web. Pois os arquivos .htaccess freqüentemente contém detalhes
# de autorização, o acesso é desabilitado por razões de segurança. Comente
# estas linhas se desejar que seus visitantes vejam o conteúdo dos arquivos
# .htaccess. Se modificar a diretiva AccessFileName acima, tenha certeza de
# fazer as modificações correspondentes aqui.
#
# As pessoas também tendem a usar nomes como .htpasswd nos arquivos de senhas
# a diretiva abaixo os protegerá também.
#
Capítulo 12. Apache 237
<Files ~ "^\.ht">
Order allow,deny
Deny from all
</Files>
#
# Controla o acesso a diretórios UserDir. As seguintes diretivas são um exempl
# para um site onde estes diretórios estão restritos a somente-leitura. Veja
# detalhes sobre as opções de acesso, e limites na seção sobre controle
# de acesso do guia
#
<Directory /home/*/public_html>
AllowOverride FileInfo AuthConfig Limit
Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec
<Limit GET POST OPTIONS PROPFIND>
Order allow,deny
Allow from all
</Limit>
<Limit PUT DELETE PATCH PROPPATCH MKCOL COPY MOVE LOCK UNLOCK>
Order deny,allow
Deny from all
</Limit>
</Directory>
#
# As vezes ocorrem relatos de pessoas tentando abusar de uma falha antiga nos
# dias do Apache 1.1 (muitas páginas na Net documentam isso). Esta falha envol
# um script CGI distribuído como parte do Apache. Descomentando estas linhas v
# poderá redirecionar estes ataques a um script de registro em phf.apache.org.
# poderá gravar em sua própria máquina, usando o script support/phf_abuse_log.
#
#<Location /cgi-bin/phf*>
# Deny from all
# ErrorDocument 403 http://phf.apache.org/phf_abuse_log.cgi
#</Location>
Esta seção pode ser uma interessante referência para a programação e configuração da diretiva
ErrorDocument, etc.
2xx - Sucesso • 200 OK
• 201 Criado
• 202 Aceito
Capítulo 12. Apache 239
Capítulo 13
Servidor ident
O servidor identd escolhido para ser descrito nesta seção do guia foi o oidentd.
13.1 Introdução
O ident (identidade) é um servidor que permite identificar qual o usuário efetuou determinada
conexão e o sistema operacional usado. Ele opera na porta 113 por padrão e retorna nomes de
usuários localmente válidos, e é consultado por serviços conhecidos como IRC, alguns servi-
dores ftp, smtp e outros. Outro benefício é a utilização de mecanismos de restrições de acesso
baseadas em usuários/endereçoIP (o tcpd é um exemplo de serviço que permite esta carac-
terística). A sintaxe usada para fazer tal restrição é universal: usuário@endereçoIP onde normal-
mente aparece o endereçoIP que é usado para bloquear/permitir o acesso.
13.1.1 Versão
É assumido que esteja usando a versão 1.7 do oidentd. As explicações contidas aqui podem
funcionar para versões posteriores, mas é recomendável que leia a documentação sobre modifi-
cações no programa (changelog) em busca de mudanças que alterem o sentido das explicações
fornecidas aqui.
Capítulo 13. Servidor ident 242
13.1.2 Contribuindo
13.1.3 Características
Características do oidentd:
• Pode ser executado tanto como daemon quanto via inetd (este último é indicado para sis-
temas com pouca memória onde o serviço é pouco solicitado).
• Pode mapear identificações de usuário via IP Masquerading, tornando este servidor
muito versátil podendo ser usado tanto em máquina individuais como em servidores
proxy/roteadores.
• Pode fazer forwarding de conexões para outras máquinas da rede local, quando não é
executado no proxy/roteador.
• Spoofing de nomes: é possível mapear um nome de usuário para outra identificação;
por exemplo, o usuário root poderá ser mapeado para outra conta de usuário antes da
identificação ser enviada.
Pacote: oidentd
Utilitários:
• oidentd - Servidor identd
Arquivos de configuração do oidentd:
identd.spoof Controla o spoof (falsificação) de nomes de usuários. O formato deste arquivo
são dois campos separados por ”:“, o primeiro contendo a identificação original do
usuário e o segundo o nome que será enviado pelo identd. O segundo campo pode ser
omitido, neste caso a resposta de identificação é lida através do arquivo ~/.ispoof. Este
arquivo deve ter como dono o usuário do primeiro campo do identd.spoof e a iden-
tificação retornada será a contida no arquivo. Esteja certo que o daemon oidentd tem
permissões para acessar este arquivo, caso contrário nenhum spoof de identidade será re-
alizado. Para o spoof ser habilitado, o serviço oidentd deverá ser iniciado com a opção
-s ou -S (veja mais detalhes ‘Opções de linha de comando’ on page 244). OBS: Certifique-
se de colocar as permissões adequadas para que somente o daemon oidentd tenha acesso
a este arquivo (de acordo com o usuário e grupo usado para executar o oidentd), os
detalhes de mapeamento de nomes podem ser perigosos em mãos erradas, e garantir o
sucesso de uma conexão indesejável.
oidentd.users Mapeamento de nomes de usuários efetuando conexões via Masquerading. O
formato deste arquivo é o seguinte:
#EndereçoIP/máscara Usuário Sistema
192.168.1.1 john WINDOWS
192.168.1.2 usuario1 WINDOWS
192.168.1.1/32 usuario2 UNIX
Capítulo 13. Servidor ident 243
O oidentd requer pouca memória e pode ser executado sem problemas em um sistema com
o mínimo de memória necessária para rodar o kernel do Linux (2 MB para 2.2 e 4MB para
as séries 2.4 do kernel). Mesmo assim é interessante considerar 1 MB a mais que o mínimo
requerido pelo kernel para uma folga na execução do serviço de identificação junto a outros
do sistema.
Mensagens informativas, erros, e outras sobre execuções do serviço oidentd são enviadas ao
syslog do sistema.
13.1.7 Instalação
Por padrão o serviço é instalado para ser executado como daemon, para executa-lo através do
inetd siga os passos em ‘Instalação via Inetd’ on the current page. O serviço será executado
sob o usuário nobody e grupo nogroup por motivos de segurança, alterações de nome/grupo
que executará o oidentd podem ser feitas no arquivo /etc/defaults/oidentd ou /etc
/init.d/oidentd.
‘Opções de linha de comando’ on the current page). Aqui foi definido um parâmetro
máximo de 40 requisições por minuto (típico de um serviço poucos usado no sistema),
caso este limite seja ultrapassado o serviço será desativado na seção atual do inetd). Os
outros campos são descritos em ‘/etc/inetd.conf’ on page 53.
2 Interrompa a execução do daemon do oidentd atual dando um
./etc/init.d/oidentd stop.
3 Remova os links dos runlevels em /etc/rc?.d que iniciam/interrompem a execução
do daemon com o comando: update-rc.d -f oidentd remove. Neste ponto o
daemon oidentd não será mais iniciado. Para reverter esta ação, execute o comando:
udpate-rc.d oidentd defaults.
4 De um comando killall -HUP inetd para fazer o serviço inetd recarregar o ar-
quivo de configuração /etc/inetd.conf. O serviço de identd já estará funcionando.
OBS: A configuração da distribuição Debian permite detectar quando o serviço ident (auth)
está sendo executado no /etc/inetd.conf através de seus scripts de inicialização. Você
poderá fazer as coisas manualmente baseado nisso se desejar.
13.1.12 Exemplos
Não faz muito sentido exemplos de arquivo de configuração do oidentd por estes serem
muito simples e estarem bem explicados em ‘Ficha técnica’ on page 242. No entanto acho inter-
essante mostrar alguns exemplos de configurações do hosts.allow e hosts.deny fazendo
uso dos recursos de restrições baseadas em usuário@endereço :
# Arquivo hosts.allow
#
# Permite requisições talk de qualquer lugar
in.ntalkd: ALL
in.talkd: ALL
#
# Permite que o usuário john acesse os serviços de ftp de qualquer máquina da
Capítulo 13. Servidor ident 246
# rede 191.168.1.*
in.ftpd: john@192.168.1.
#
# O serviço telnet está permitido somente para john conectando de 192.168.1.1
in.telnetd: john@192.168.1.1
# Todos podem acessar os serviços samba (nomes e compartilhamentos) exceto
# o usuário evil conectando de qualquer host com o endereço cracker.com.*
smbd, nmbd: ALL EXCEPT evil@cracker.com.
# Arquivo hosts.deny
# Qualquer finger é bloqueado exceto vindos do usuário admin feitos em qualque
# máquina da rede 192.168.1.*
in.fingerd: ALL EXCEPT admin@192.168.1.
# Qualquer outra coisa é bloqueada
ALL: ALL
247
Capítulo 14
Servidor telnet
Este capítulo ensina como instalar, configurar, usar e fazer restrições de acesso ao servidor
telnet. Também é explicada a utilização do cliente telnet e o suporte a criptografia (ssl).
14.1 Introdução
O serviço telnet é oferece o login remoto em seu computador, que lhe permite trabalhar conec-
tado a distância como se estivesse em frente a ela. Ele substitui o rlogin e possui muitas
melhorias em relação a ele, como o controle de acesso, personalização de seção e controle de
terminal.
14.1.1 Versão
É assumido que esteja usando a versão 0.17.16 do telnet. As explicações contidas aqui po-
dem funcionar para versões posteriores, mas é recomendável que leia a documentação sobre
modificações no programa (changelog) em busca de mudanças que alterem o sentido das ex-
plicações fornecidas aqui.
14.1.2 Características
• Conexão rápida (não utiliza transmissão de dados criptografada), recomendado para am-
bientes seguros.
• Possui uma versão com suporte a criptografia via ssl.
• Possui controle de acesso tcpd (usando /etc/hosts.allow e /etc/hosts.deny).
• A maioria dos sistemas operacionais trazem este utilitário por padrão como sistema de
acesso remoto a máquinas UNIX.
• Suporte a terminais ANSI (cores e códigos de escape especiais para o console) e uma
grande variedade de outros terminais.
Capítulo 14. Servidor telnet 248
Pacotes:
• telnet - Cliente telnet com suporte a autenticação.
• telnetd - Servidor telnet com suporte a autenticação.
• telnet-ssl - Cliente telnet com suporte a autenticação e ssl. Também suporta conexão
a servidores telnet padrão quando o servidor não suporta ssl. Por padrão é tentada a
conexão usando ssl, se esta falhar será assumida a transmissão em texto plano.
• telnetd-ssl - Servidor telnet com suporte a autenticação e ssl. Também suporta
conexão de clientes telnet padrão (sem suporte a ssl).
Utilitários:
• in.telnetd - Servidor telnet
• telnet - Cliente telnet padrão (quando o pacote telnet-ssl está instalado, é simples-
mente um link para telnet-ssl).
• telnet-ssl - Cliente telnet com suporte a ssl.
Normalmente o servidor telnet é carregado via inetd, o que permite sua utilização em uma
máquina com a quantidade mínima de memória RAM requerida para o funcionamento do
kernel: 2 MB para kernels da série 2.2 e 4MB para kernels da série 2.4.
Mensagens do servidor telnet relacionadas com seções são enviadas para /var/log
/daemon.log. Adicionalmente, as mensagens sobre autenticação (serviços de login) são reg-
istradas pelos módulos PAM em /var/log/auth.log.
14.1.6 Instalação
14.3 Recomendações
O serviço telnet utiliza texto plano para seção (exceto nas versões cliente/servidor ”-ssl“). Os
dados transmitidos por serviços que utilizam texto plano podem ser capturados por sniffers e
trazer perigo ao seu sistema (veja ‘Sniffer’ on page 403).
Capítulo 14. Servidor telnet 250
Use o comando: telnet [endereço] [porta] para realizar conexões com uma máquina
rodando o servidor telnet.
Adicionalmente as seguintes opções podem ser usadas:
• -l [usuario] - Envia o nome de usuário ao computador remoto. Muito útil com o
telnet-ssl.
• -E - Desativa o caracter de escape
• -a - Tenta fazer o login automático usando o nome de usuário local. Se o login falhar, será
solicitado o nome de usuário. Esta opção é usada por padrão com o cliente telnet-ssl.
• -r - Emula o comportamento do programa rlogin.
Exemplos:
Capítulo 15
Servidor ssh
Ambas as versões 1 e 2 do ssh são documentadas neste capítulo. Opções específicas do proto-
colo 1 ou 2 do ssh serão destacadas.
15.1 Introdução
O serviço de ssh permite fazer o acesso remoto ao console de sua máquina, em outras palavras,
você poderá acessar sua máquina como se estivesse conectado localmente ao seu console (sub-
stituindo o rlogin e rsh). A principal diferença com relação ao serviço telnet padrão,
rlogin e rsh é que toda a comunicação entre cliente/servidor é feita de forma encriptada
usando chaves públicas/privadas RSA para criptografia garantindo uma transferência segura
de dados.
A velocidade do console remoto conectado via Internet é excelente (melhor que a obtida pelo
telnet e serviços r*) dando a impressão de uma conexão em tempo real (mesmo em links
discados de 9.600 KB/s), a compactação dos dados também pode ser ativada para elevar ainda
mais a velocidade entre cliente-servidor ssh. Além do serviço de acesso remoto, o scp possi-
bilita a transferência/recepção segura de arquivos (substituindo o rcp).
Em conexões sem criptografia (rsh, rlogin) os dados trafegam de forma desprotegida e caso
exista algum sniffer instalado em sua rota com a máquina destino, todo o que fizer poderá ser
capturado (incluindo senhas).
Capítulo 15. Servidor ssh 252
15.1.1 Versão
É assumido que esteja usando a versão 2.0 do ssh. As explicações contidas aqui podem fun-
cionar para versões posteriores, mas é recomendável que leia a documentação sobre modifi-
cações no programa (changelog) em busca de mudanças que alterem o sentido das explicações
fornecidas aqui.
15.1.2 História
15.1.3 Contribuindo
15.1.4 Características
Pacote: ssh
Utilitários:
• ssh - Cliente ssh (console remoto).
• slogin - Link simbólico para o programa ssh.
Capítulo 15. Servidor ssh 253
É recomendado no mínimo 6MB de memória RAM para a execução do serviço ssh mais o ker-
nel do Linux. Este limite deve ser redimensionado para servidores de acesso dedicado, uma
quantidade de 64MB deve ser confortável para centenas de usuários conectados simultanea-
mente (o que raramente acontece).
Veja também ‘Restrições de acesso, recursos e serviços’ on page 375 para configuração de re-
strições usando PAM. O ssh que acompanha a distribuição Debian vem com o suporte a tcp
wrappers compilado por padrão.
Detalhes sobre a execução do servidor sshd (como inicio, autenticação e término) são enviadas
ao syslog do sistema. A prioridade e nível são definidos no arquivo de configuração /etc/ssh
/sshd_config (veja ‘Exemplo de sshd_config com explicações das diretivas’ on page 263).
Por padrão o servidor sshd é instalado como daemon, também é possível executa-lo via
inetd mas isto não é aconselhável porque o servidor gera uma chave aleatória de seção toda
vez que é iniciado, isto podendo levar vários segundos (quando é usada a versão 1 do proto-
colo ssh, veja ‘Diferenças nas versões do protocolo’ on page 262).
Capítulo 15. Servidor ssh 254
O arquivo que controla o funcionamento do daemon do ssh é controlado pelo arquivo /etc
/init.d/ssh.
A execução do ssh através de inetd é automática quando é feita uma requisição para a porta
22.
15.2.1 ssh
ssh usuario@ip/nome_do_servidor_ssh
Caso o nome do usuário seja omitido, seu login atual do sistema será usado. O uso da opção
-C é recomendado para ativar o modo de compactação dos dados (útil em conexões lentas).
A opção -l usuário pode ser usada para alterar a identificação de usuário (quando não é us-
ada, o login local é usado como nome de usuário remoto). Uma porta alternativa pode ser
especificada usando a opção -p porta (a 22 é usada por padrão).
Na primeira conexão, a chave pública do servidor remoto será gravada em ~/.ssh
/know_hosts ou ~/.ssh/know_hosts2 (dependendo da versão do servidor ssh remoto,
veja ‘Diferenças nas versões do protocolo’ on page 262), e verificada a cada conexão como
checagem de segurança para se certificar que o servidor não foi alvo de qualquer ataque ou
modificação não autorizada das chaves. Por padrão, o cliente utilizará o protocolo ssh versão
1, a opção -2 permite usar o protocolo versão 2.
Variáveis de ambiente personalizadas para o ssh poderão ser definidas no arquivo ~/.ssh
/environment. Comandos que serão executados somente na conexão ssh em ~/.ssh/rc e
/etc/ssh/sshrc caso contrário será executado o xauth por padrão.
OBS: Para utilizar autenticação Rhosts/Rhosts+RSA (arquivos ~/.rhosts/~/.shosts) o
programa ssh deverá ter permissões SUID root e conectará usando portas baixas (menores
que 1024).
Exemplos:
# Conecta-se ao servidor remoto usando o login do usuário atual
Capítulo 15. Servidor ssh 256
ssh ftp.sshserver.org
Redirecionamento de conexões do X
Port 22
Protocol 2
Cipher blowfish
# CheckHostIP yes
# RhostsAuthentication no
# RhostsRSAAuthentication yes
# RSAAuthentication yes
# FallBackToRsh no
# UseRsh no
# BatchMode no
# StrictHostKeyChecking yes
# IdentityFile ~/.ssh/identity
# IdentityFile ~/.ssh/id_dsa
# IdentityFile ~/.ssh/id_rsa1
# IdentityFile ~/.ssh/id_rsa2
# EscapeChar ~
O putty é um cliente ssh Win32 que possui suporte aos protocolos versão 1 e 2 do ssh,
aceita compactação além de funcionar também como cliente telnet. Seu tamanho é pe-
queno, apenas um executável e requer 220KB de espaço em disco. Ele pode ser baixado de
http://www.chiark.greenend.org.uk/~sgtatham/putty/.
Outra alternativa é o MindTerm, este é baseado em Java e pode inclusive ser executado como
um applet em uma página web. Este programa é encontrado em http://www.mindbright.
se/mindterm/.
15.2.2 scp
Permite a cópia de arquivos entre o cliente/servidor ssh. A sintaxe usada por este comando é
a seguinte:
Capítulo 15. Servidor ssh 258
Exemplos:
# Para copiar um arquivo local chamado /pub/teste/script.sh para
# meu diretório pessoal em ftp.sshserver.org
scp -C /pub/teste/script.sh gleydson@ftp.sshserver.org:~/
O pscp faz a tarefa equivalente ao scp no windows, e pode ser baixado de http://www.
chiark.greenend.org.uk/~sgtatham/putty/.
15.2.3 sftp
Permite realizar transferência de arquivos seguras através do protocolo ssh. A conexão e trans-
ferências são realizadas através da porta 22 (ainda não é possível modificar a porta padrão). A
sintaxe para uso deste comando é a seguinte:
sftp usuario@host_remoto
Capítulo 15. Servidor ssh 259
Compactação pode ser especificada através da opção -C. Um arquivo contendo os comandos
usados na seção sftp poderá se especificado através da opção -b arquivo para automatizar
tarefas.
OBS1: Para desativar o servidor sftp, remova a linha SubSystem sftp
/usr/lib/sftp-server (que inicializa o sub-sistema ftp) do arquivo /etc/ssh
/sshd_config e reinicie o servidor sshd.
OBS2: O suporte ao programa sftp somente está disponível ao protocolo ssh versão 2 e su-
periores.
OBS3: Algumas opções comuns do cliente ftp padrão (como mget) ainda não estão
disponíveis ao sftp. Veja a página de manual para detalhe sobre as opções disponíveis.
15.3.1 sshd
Este é o daemon de controle da conexão encriptada via protocolo ssh, transferência de arquivos
e shell interativo. As opções de linha de comando estão disponíveis em ‘Opções de linha de
comando’ on page 254. Seu arquivo de configuração principal é /etc/ssh/sshd_config,
um exemplo e descrição das opções deste arquivo é encontrada em ‘Exemplo de sshd_config
com explicações das diretivas’ on page 263.
OBS1: É recomendável que o arquivo /etc/ssh/sshd_config seja lido somente pelo
dono/grupo, por conter detalhes de acesso de usuários, grupos e intervalo entre a geração
de chave de seção.
OBS2: Se estiver ocorrendo falhas no acesso ao servidor ssh, verifique as permissões nos
arquivos /etc/hosts.allow e /etc/hosts.deny (o nome do serviço é sshd). Mesmo
operando como daemon, o servidor utiliza estes arquivos para fazer um controle de acesso
adicional.
Este método de autenticação utiliza o par de chaves pública (que será distribuído nas máquinas
que você conecta) e outra privada (que ficará em seu diretório pessoal) para autenticação. A
encriptação e decriptação são feitas usando chaves separadas e não é possível conseguir a
Capítulo 15. Servidor ssh 260
chave de decriptação usando a chave de encriptação. É possível inclusive gerar uma chave sem
senha para efetuar o logon em um sistema ou execução de comandos remotos (este esquema é
um pouco mais seguro que os arquivos ~/.rhosts e ~/.shosts).
Siga os seguintes passos para se autenticar usando RSA 1 - usada na versão 1 do ssh:
1 Gere um par de chaves pública/privada usando o comando:
ssh-keygen
Um par de chaves RSA versão 1 será gerado com o tamanho de 1024 bits por padrão,
garantindo uma boa segurança/performance, e salvas no diretório ~/.ssh com o nome
identity e identity.pub. Para alterar o tamanho da chave use a opção -b tamanho.
Depois de gerar a chave, o ssh-keygen pedirá uma frase-senha (é recomendável
ter um tamanho maior que 10 caracteres e podem ser incluídos espaços). Se não quiser
digitar uma senha para acesso ao sistema remoto, tecle <Enter> quando perguntado.
Mude as permissões do diretório ~/.ssh para 750. A opção -f especifica o diretório e
nome das chaves. A chave pública terá a extensão .pub adicionada ao nome especifi-
cado. ATENÇÃO Nunca distribua sua chave privada, nem armazene-a em servidores de
acesso públicos ou outros métodos que permitem outros terem acesso a ela. Se precisar
de uma cópia de segurança, faça em disquetes e guarde-a em um lugar seguro.
2 Instale a chave pública no servidor remoto que deseja se conectar, por exemplo,
www.sshserver.org:
ssh-copy-id -i ~/.ssh/identity gleydson@www.servidorssh.org
A função do utilitário acima é entrar no sistema remoto e adicionar a chave pública local
~/.ssh/identity.pub no arquivo /home/gleydson/.ssh/authorized_keys do
sistema remoto www.sshserver.org. O mesmo processo poderá ser feito manual-
mente usando os métodos tradicionais (ssh/scp). Caso o arquivo remoto /home
/gleydson/.ssh/authorized_keys não existe, ele será criado. Seu formato é idên-
tico ao ~/.ssh/know_hosts e contém uma chave pública por linha.
3 Agora utilize o ssh para entrar no sistema remoto usando o método de chave
pública/privada. Entre com a senha que usou para gerar o par de chaves
público/privado (ele entrará diretamente caso não tenha digitado uma senha).
Para autenticar em uma versão 2 do ssh (usando chave RSA 2 ou DSA):
1 Gere um par de chaves pública/privada usando o comando:
ssh-keygen -t rsa -f ~/.ssh/id_rsa
ou
com:
scp ~/.ssh/id_rsa.pub usuario@servidorremoto:~/.ssh/authorized_keys2
ou
scp ~/.ssh/id_dsa.pub usuario@servidorremoto:~/.ssh/authorized_keys2
(caso tenha gerado a chave com a opção -t dsa)
Caso o arquivo remoto /home/gleydson/.ssh/authorized_keys2 não existe, ele
será criado. Seu formato é idêntico ao ~/.ssh/know_hosts2 e contém uma chave
pública por linha.
3 Agora utilize o ssh para entrar no sistema remoto usando o método de chave
pública/privada. Entre com a senha que usou para gerar o par de chaves
público/privado (ele entrará diretamente caso não tenha digitado uma senha).
OBS: Deverá ser levado em consideração a possibilidade de acesso físico ao seu diretório pes-
soal, qualquer um que tenha posse de sua chave privada poderá ter acesso ao sistema remoto.
O tipo de chave criada por padrão é a rsa1 (compatível com as versões 1 e 2 do ssh). A opção
-t [chave] poderá ser usada (ao gerar a chave) para selecionar o método de criptografia:
• rsa1 - Cria uma chave rsa compatível com a versão 1 e 2 do ssh (esta é a padrão).
• rsa - Cria uma chave rsa compatível somente com a versão 2 do ssh.
• dsa - Cria uma chave dsa compatível somente com a versão 2 do ssh.
Para trocar a senha utilize o comando: ssh-keygen -p -t tipo_chave -f
~/.ssh/identity - será pedida sua senha antiga e a nova senha (no mesmo es-
tilo do passwd). Opcionalmente você pode utilizar a sintaxe: ssh-keygen -p -f
~/.ssh/identity -P senha_antiga -N senha_nova, que troca a senha em um único
comando (útil para ser usado em scripts junto com a opção -q para evitar a exibição de
mensagens de saída do ssh-keygen).
Com o uso de chaves também é possível o uso do ssh para execução de comandos específicos
em máquinas remotas, isto é possível com os novos recursos da versão 3 do ssh. Para fazer
isto, siga os passos ‘Usando autenticação RSA/DSA - chave pública/privada’ on page 259 para
gerar um par de chaves DSA (o par RSA não aceita execução de comandos específicos) e copiar
para authorized_keys2. Após isto, entre no servidor remoto e edite a chave, inserindo o
comando que deverá ser executado antes da linha dds, por exemplo:
Com este método é possível restringir a execução de alguns comandos/serviços além de outras
possibilidades como a mudança de variáveis específicas para o comando:
no-port-forwarding,no-X11-forwarding,no-agent-forwarding,command="ls / -la" ss
Imagine quando você deseja ter acesso a uma máquina de sua rede interna que esteja atrás
de um gateway, isto é possível usando os recursos explicados em ‘Execução de comandos
Capítulo 15. Servidor ssh 262
Isto o acesso do usuário ser redirecionado automaticamente quando efetuar o logon. Caso
tenha definido uma senha para a chave DSA, o usuário deverá fornecer a senha para entrar no
gateway e outra para acessar sua estação de trabalho.
OBS: Não estou levando em conta as considerações de segurança que este exemplo tem em sua
rede, bem como o que pode ou não ser redirecionado. A intenção foi manter a simplicidade
para entender sem dificuldades como isto é feito.
Aplicações remotas podem ser abertas localmente com o uso desta técnica. Você poderá usar
para acessar portas que estariam disponíveis somente através do endereço remoto, realizar
conexões criptografadas ou com compactação (garantindo uma boa taxa de transferência para
protocolos que usem mais texto).
Por exemplo, para redirecionar o tráfego da porta 80 do servidor remoto para a porta 2003
local:
O sleep 60 tem a função de apenas deixar o tunel aberto por 60 segundos, tempo suficiente
para realizarmos nossa conexão. Agora, entre no seu navegador local e acesse a porta 2003:
http://localhost:2003
A opção -C também pode ser especificada junto ao ssh para usar compactação dos dados
da conexão. Como notou, este recurso também é útil para fazer a administração remota de
máquinas, porque o que está realizando a conexão será o IP do servidor remoto, não o seu. Da
mesma forma, você poderá ter problemas caso não tenha uma boa política de distribuição de
contas de máquinas em sua rede. Veja ‘Gerenciamento de contas e cuidados para a proteção
de senhas’ on page 161 para detalhes .
Protocolo SSH versão 1 Cada servidor possui uma chave RSA específica (1024 bits por
padrão) usada para identifica-lo. Quando o sshd inicia, ele gera uma chave RSA do
Capítulo 15. Servidor ssh 263
servidor (768 bits por padrão, valor definido por ServerKeyBits) que é recriada a cada
hora (modificado por KeyRegenerationInterval no sshd_config) e permanece sempre
residente na RAM.
Quando um cliente se conecta o sshd responde com sua chave pública da máquina e
chaves do servidor. O cliente ssh compara a chave RSA com seu banco de dados (em ~
/.ssh/know_hosts) para verificar se não foi modificada.
Estando tudo OK, o cliente gera um número aleatório de 256 bits, o encripta usando am-
bas as chaves de máquina e chave do servidor e envia este número ao servidor. Ambos os
lados então usam este número aleatório como chave de seção que é usado para encriptar
todas as comunicações seguintes na seção.
O resto da seção usa um método de embaralhamento de dados convencional, atualmente
Blowfish ou 3DES (usado como padrão). O cliente seleciona o algoritmo de criptografia
que será usado de um destes oferecidos pelo servidor. Após isto o servidor e cliente
entram em um diálogo de autenticação. O cliente tenta se autenticar usando um dos
seguintes métodos de autenticação:
• ~/.rhosts ou ~/.shosts (normalmente desativada).
• ~/.rhosts ou ~/.shosts combinado com autenticação RSA (normalmente de-
sativada).
• Autenticação RSA por resposta de desafio.
• Autenticação baseada em senha.
A autenticação usando Rhosts normalmente é desativada por ser muito insegura mas
pode ser ativada no arquivo de configuração do servidor se realmente necessário. A
segurança do sistema não é melhorada a não ser que os serviços rshd, rlogind, rexecd
e rexd estejam desativados (assim, o rlogin e rsh serão completamente desativados
na máquina).
Protocolo SSH versão 2 A versão 2 funciona de forma parecida com a 1: Cada máquina possui
uma chave RSA/DSA específica usada para se identificar. A diferença é que quando o
sshd inicia, ele não gera uma chave de servidor. A segurança de redirecionamento é ofer-
ecida através da concordância do uso de uma chave Diffie-Hellman. Esta concordância
de chave resulta em uma seção com chave compartilhada. O resto da seção é encriptada
usando um algoritmo simétrico, como Blowfish, 3DES, CAST128, Arcfour, 128 bit AES,
ou 256 bit AES.
O cliente que seleciona o algoritmo de criptografia que será usado entre os oferecidos
pelo servidor. A versão 2 também possui integridade de seção feita através de um código
de autenticação de mensagem criptográfica (hmac-sha1 ou hmac-md5). A versão 2 do
protocolo oferece um método de autenticação baseado em chave pública (PubkeyAu-
thentication) e o método de autenticação convencional usando senhas.
Abaixo segue um exemplo deste arquivo que poderá ser adaptado ao seu sistema. O objetivo
é ser ao mesmo tempo útil para sua configuração e didático:
Capítulo 15. Servidor ssh 264
# Porta padrão usada pelo servidor sshd. Múltiplas portas podem ser
# especificadas separadas por espaços.
Port 22
HostKey /etc/ssh/ssh_host_key
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
# Mostra (yes) ou não (no) a mensagem de último login do usuário. O padrão é "
PrintLastLog no
# pelo daemon sshd. O valor padrão é 10. Valores aleatórios podem ser
# especificados usando os campos "inicio:taxa:máximo". Por exemplo,
# 5:40:15 rejeita até 40% das tentativas de autenticação que excedam o
# limite de 5 até atingir o limite máximo de 15 conexões, quando
# nenhuma nova autenticação é permitida.
MaxStartups 10
#MaxStartups 10:30:60
Capítulo 16
Servidor pop3
16.1 Introdução
16.1.1 Versão
É assumido que esteja usando a versão 4.0.3 do qpopper. As explicações contidas aqui podem
funcionar para versões posteriores, mas é recomendável que leia a documentação sobre modifi-
cações no programa (changelog) em busca de mudanças que alterem o sentido das explicações
fornecidas aqui.
16.1.2 Contribuindo
16.1.3 Características
• Simples de configurar.
• Possui um timeout padrão de 30 segundos ao invés de 10 minutos do protocolo pop3
padrão.
• O protocolo pop3 é mais simples e consome menos recursos no servidor que o IMAP.
• Suporte a envio de boletins aos usuários do sistema.
• Inclui suporte a TLS/SSL.
• Suporte a senhas ocultas (shadow passwords).
• Suporta PAM.
• Suporte a autenticação via APOP.
• Alta performance.
Pacote: qpopper.
Utilitários:
• in.qpopper - Servidor pop3.
• popauth - Manipula os bancos de dados de autorização quando é usado o método de
autenticação APOP.
Arquivos de configuração:
• /etc/popper.allow - Contém a lista de usuários autorizados a usar o serviço pop3.
• /etc/popper.deny - Contém uma lista de usuários NÃO autorizados a usar o serviço
pop3.
• /etc/pop.auth - Contém dados de autenticação criados pelo programa popauth.
O servidor qpopper requer no mínimo 6MB de memória para rodar e espaço em disco sufi-
ciente para acomodar os e-mails de usuários.
Mensagens sobre a execução do qpopper são enviadas aos seguintes arquivos em /var/log:
• mail.info - Detalhes sobre autenticação de usuários e mensagens.
• mail.warn - Erros e avisos diversos ocorridos na seção pop3.
• syslog e daemon.log - Mensagens sobre a execução do servidor qpopper.
• auth.log - Mensagens de autenticação gerados pelo PAM.
16.1.7 Instalação
O serviço é executado por padrão via inetd e utiliza o controle de acesso tcpd (veja ‘O mecan-
ismo de controle de acessos tcpd’ on page 56). Adicionalmente você pode definir que usuários
terão/não acesso ao serviço pop3 nos arquivos /etc/popper.allow e popper.deny. Por
padrão, o acesso é garantido para qualquer usuário.
Após instalar o servidor pop3 instalado, resta configurar o cliente para conectar ao servidor
pop3 do servidor. O nome de usuário e senha são os usados no arquivo /etc/passwd.
Um simples teste consiste em usar o telnet conectando a porta pop3 (110): telnet
127.0.0.1 110:
Connected to 127.0.0.1.
Escape character is ’^]’.
+OK Qpopper (version 4.0.3) at server.org starting. <2122.11132222@server.org
-c Modifica a senha para caracteres minúsculos antes de autenticar, permitindo que clientes
conectem com a senha em MAIÚSCULAS ou caracteres mIsTurados.
-f [arquivo ] Especifica um arquivo de configuração para o servidor qpopper. Veja a página
de manual para detalhes sobre as opções. Recomendo usar as opções de linha de co-
mando exceto se for requerida configurações especiais para modificar o comportamento
do servidor pop3.
-l [num ] Modifica as opções de criptografia TLS/SSL usada no transporta da seção. Os
seguintes valores são aceitos:
• 0 - Desativa TLS/SSL. É o padrão.
• 1 - Ativa o suporte a TLS/SSL. Se o cliente não suportar criptografia, os dados serão
transmitidos usando a forma padrão.
• 2 - Tenta ativar uma conexão TLS quando o cliente conecta ao servidor usando uma
porta alternativa.
-p [num ] Seleciona como a senha em texto plano será manipulada. O servidor deverá estar
compilado com suporte a outras formas de autenticação (como APOP) ao invés de texto
plano. As seguintes opções são suportadas.
• 0 - Senhas em texto plano podem ser usadas para usuários não cadastrados no ar-
quivo /etc/pop.auth (gerenciado pelo popauth. Este é o padrão.
• 1 - Somente permite acesso de usuários cadastrados no arquivo /etc/pop.auth.
Qualquer acesso usando texto plano é negado.
• 2 - Permite autenticação usando texto plano como preferência, até mesmo para
usuários que estejam no /etc/pop.auth). É útil para clientes que não suportam
autenticação usando texto plano.
• 3 - Somente usuários conectando da mesma máquina (127.0.0.1) podem usar auten-
ticação em texto plano.
• 4 - Permite autenticação usando texto plano somente se uma conexão criptográfica
foi estabelecida usando TLS ou SSL.
-R Desativa a resolução reversa de endereços IP de clientes.
-s Registra dados de inicio da seção, nome de usuário, número de bytes/mensagens apagadas,
número de mensagens deixadas no servidor e fim da seção. Estes detalhes são registrados
pelo syslogd. Seu uso é recomendável para ter controle sobre o que está acontecendo
em seu servidor.
-S Ativa o modo daemon. Útil para servidores pop3 com grande número de acessos.
-T [num ] Tempo máximo em segundos para finalização da seção quando o cliente não envia
nenhuma resposta ou comando. Valores pequenos (como 20) podem ser especificados
para servidores que possuem poucos usuários e um link rápido. Para grande quantidade
de usuários ou conexão feita via links lentos (como ppp, slip, plip, etc.) use valores como
600 (10 minutos) ou mais. O valor padrão é 120 segundos (2 minutos).
-u Lê o arquivo ~/.qpopper.options no diretório do usuário em busca de opções adi-
cionais para o servidor. Este arquivo é lido após o processo de autenticação e deve ter per-
missões leitura/gravação para o dono. Isto não é recomendável em servidores seguros,
a criptografia ou método de autenticação podem ser desativados sem o conhecimento do
administrador comprometendo a segurança dos dados.
-U Idêntica a opção acima, mas o arquivo deve residir no diretório de spool (/var/spool
/pop) e ter o formato:
.usuario.qpopper-options
Capítulo 16. Servidor pop3 273
Este arquivo deve ter como dono o administrador ou dono do servidor pop3. Esta alter-
nativa é mais segura que a anterior porque o usuário não terá acesso ou desativar opções
específicas.
-y [facilidade ] Permite modificar o nível facilidade que as mensagens são registradas no
syslogd (veja ‘Arquivo de configuração syslog.conf’ on page 76).
Este recurso é muito útil para enviar alertas ou avisos para todos os usuários em seu sistema
de uma só vez. A mensagem é escrita no diretório /var/spool/popbull seguindo um for-
mato especial e quando o usuário pop3 se conecta para pegar seus e-mails receberá também
uma cópia do boletim. O controle de boletins já recebido pelo usuário é feito no arquivo ~
/.popbull. Siga os passos a seguir para configurar este sistema:
3 A primeira linha do boletim deve conter a palavra ”From“ e um espaço e deve ser com-
pletada com um nome e data, seguido de campos essenciais para o envio da mensagem:
OBS: Quando incluir novos usuários no sistema, somente os últimos 10 boletins serão envia-
dos.
Crie o diretório de spool /var/mail em uma partição separada e ative o sistema de quota do
Linux nela. Leia as instruções em ‘Limitando o uso de espaço em disco (quotas)’ on page 392.
Capítulo 16. Servidor pop3 274
O controle de acesso de conexões é feito via método tcpd usando o daemon in.qpopper (veja
‘O mecanismo de controle de acessos tcpd’ on page 56). O controle de acesso dos usuários
é feito através do arquivos /etc/popper.allow e /etc/popper.deny, respectivamente
contém os nomes de usuários que podem e não podem ter acesso ao servidor qpopper. Por
motivos de segurança é recomendável redirecionar os e-mails do usuário root para outra
conta (no arquivo /etc/aliases e bloquear o acesso do usuário root ao pop3 no arquivo
/etc/popper.deny.
Se a máquina servidora pop3 não for utilizada para acesso remoto, é recomendável desativar
os serviços de login (veja ‘Desabilitando serviços de shell para usuários’ on page 377).
275
Capítulo 17
CVS
Não tome-o como uma referência completa ao uso e configuração do cvs, a pesquisa de sua
info page é muito importante.
O CVS (Concurrent Version Software) permite que se organizem grupos de trabalho para de-
senvolvimento de projetos colaborativos. Um projeto pode ser desde um programa em C,
documentação em equipe, etc. O uso do CVS é recomendado para qualquer desenvolvimento
de projeto que tenha vários envolvidos trabalhando ao mesmo tempo.
Para cada mudança feita no programa, é pedido uma descrição dos trabalhos realizados e o
sistema registra todas as modificações realizadas ao longo do desenvolvimento, permitindo
voltar a uma versão anterior ou ver as mudanças entre elas facilmente.
Imagine uma situação onde você está desenvolvendo um programa de computador e após a
última modificação ele para de funcionar. Com o CVS é possível ver o que foi modificado e
voltar até a versão que estava funcionando para consertar o problema. No desenvolvimento
de documentação e tradução o CVS também desempenha um papel importante, pois com ele
o tradutor pode ver o que foi modificado entre a versão do documento original que ele usou
para tradução e uma versão recente, traduzindo apenas as diferenças.
Uma seção de cvs é feita de modo interativo através do comando cvs. Por exemplo:
• logar no sistema - cvs login
• baixar um projeto - cvs checkout projeto
Cada comando do cvs será explicado em detalhes no decorrer deste capítulo.
Capítulo 17. CVS 276
17.1.1 Versão
A versão do CVS documentada no guia é a 1.11.1. As explicações aqui certamente serão com-
patíveis com versões posteriores deste programa.
17.1.2 História
O CVS é uma substituição do sistema RCS (Revision Control System) ele possui mais recursos
e foi criado sendo compatível com o RCS.
A história do CVS (extraída de sua info page) é que ele foi iniciado a partir de um con-
junto de scripts shell escritos por Dick Grune que foram postados ao grupo de notícias
comp.sources.unix no volume 6 de Dezembro de 1986. Na versão atual não estão mais
presentes shell scripts porque muitos dos conflitos de resolução de algorítmos vem deles.
Em Abril de 1989, Brian Berliner fez o design e programou o CVS. Mais tarde, Jeff Polk ajudou
Brian com o design do módulo CVS.
Através da lista de discussão info-cvs. Para se inscrever envie uma mensagem com o subject
”subscribe“ para info-cvs-request@gnu.org. Outra alternativa é através do grupo de
noticias (newsgroup) da Usenet comp.software.config-mgm.
17.1.4 Características
Abaixo uma lista de características que tornam o CVS útil no gerenciamento de trabalhos em
grupo:
• Lock de arquivos, permitindo que somente uma determinada pessoa modifique o ar-
quivo durante o desenvolvimento do projeto.
• Histórico de todas as mudanças feitas, isto permite voltar a uma versão anterior em caso
de problemas, e ver o que houve de errado com o código.
• Podem ser criados diversas equipes de trabalho para cada repositórios, e definidos quem
terá ou não acesso ao repositório individualmente. O desenvolvedor gleydson, por
exemplo, podem ter acesso ao projeto x_beta e não ter acesso a projeto secret_y.
• É possível criar um usuário com acesso anônimo sem dar uma conta no sistema.
• Permite utilizar diversos ”métodos“ de acesso ao servidor: local, pserver, ext, etc. Cada
um destes métodos será descrito a seguir.
• Permite o acesso via ssh para usuários que já possuam conta na máquina servidora. Este
método garante segurança no envio da senha criptografada (veja ‘Sniffer’ on page 403
para detalhes).
• Permite visualizar facilmente o que foi modificado entre duas versões de um arquivo.
OBS: O CVS possui algumas limitações e falhas, uma delas que mais me faz falta é um suporte
a protocolo pserver via ssh que resolveria o problema de tráfego em texto plano e gerencia-
mento de grupos com permissões diferenciadas.
Pacote: cvs
Utilitários:
• cvs - Servidor/ferramenta cliente.
• cvsbug - Envia um bug sobre o CVS para a equipe de suporte.
• rcs2log - Converte arquivos de log do formato usado pelo RCS para o CVS. Utilizado
na migração desta ferramenta para o CVS.
• cvsconfig - Usado pela Debian para ativar/desativar o servidor pserver. Pode tam-
bém ser usado o dpkg-reconfigure cvs para desativar o servidor pserver e suas
características.
• cvs-makerepos - Script da Debian que lê a lista de repositórios de /etc
/cvs-pserver.conf, cria os repositórios no local apropriado, corrige as permissões
do diretório e adiciona os repositórios no servidor pserver.
• cvs-pserver - Script da Debian responsável por fazer uma inicialização mais in-
teligente do servidor de CVS via pserver, leitura e processamento de repositórios, etc.
Normalmente ele é chamado a partir do arquivo /etc/inetd.conf.
Para executar o CVS é requerido pelo menos 3 vezes mais memória que o tamanho do maior ar-
quivo usado pelo projeto (para realização de diffs entre as atualizações) e uma boa quantidade
de espaço em disco.
Na realidade os requerimentos sobre o CVS dependem muito da aplicação que será desen-
volvida. É recomendável que a máquina tenha memória suficiente para evitar o uso de swap,
que degrada bastante a performance do sistema.
Capítulo 17. CVS 278
17.1.8 Instalação
A única configuração requerida é quando o CVS é executado via pserver. Para isto, é
necessária a seguinte linha no arquivo /etc/inetd.conf
Note que o parâmetro ”200“ indica quantas vezes o processo CVS poderá ser executado
por minuto no sistema. Caso esse número seja excedido, o serviço será desabilitado e será
necessário reiniciar o servidor inetd com o comando killall -HUP inetd para reativar
o servidor CVS pserver (veja ‘/etc/inetd.conf’ on page 53 capítulo do inetd para detalhes).
Ajuste este valor de forma adequada ao seu servidor!
Veja o script cvs-pserver sendo executado no final da linha. Ele foi desenvolvido para lidar
de forma mais inteligente com a configuração do servidor CVS pserver.
O CVS é uma aplicação cliente/servidor, possuindo diversas maneiras de fazer o acesso seu
repositório (veja ‘Repositório’ on page 285 repositórios). Estes métodos são os seguintes:
• local (‘local’ on the current page).
• ext (‘ext’ on the following page).
• pserver (‘pserver (password server)’ on page 281).
• fork (‘fork’ on the following page).
• GSSAPI (‘gssapi’ on page 285).
Eles são explicados em detalhes nas sub-seções a seguir.
17.2.1 local
Acessa o diretório do repositório diretamente no disco local. A vantagem deste método é que
não é requerido nem nome nem senha para acesso (você precisa apenas ter permissões para
acesso aos arquivos que deseja trabalhar) e também não é preciso nenhuma conexão de rede.
Este método é ideal para trabalhar na máquina local ou com os arquivos administrativos do
CVS existentes no diretório CVSROOT do repositório. É muito útil também para configurar
outros métodos de acesso, como o pserver.
Para criar seu repositório, veja ‘Criando um repositório’ on page 286.
Para utilizar o método de acesso local, basta definir a variável CVSROOT da seguinte forma
(assumindo que o repositório esteja instalado em /var/lib/cvs):
export CVSROOT=/var/lib/cvs
ou
Capítulo 17. CVS 280
export CVSROOT=local:/var/lib/cvs
Depois disso, basta utilizar os comandos normais do cvs sem precisar se autenticar no sistema.
Veja os detalhes de utilização dos comandos de CVS após o login na seção ‘Clientes de CVS’
on page 293.
17.2.2 fork
Este método é semelhante ao local, mas ele ”simula“ uma conexão de rede com o servidor. É
muito usado para fins de testes.
Para utilizar o método de acesso fork, basta definir a variável CVSROOT da seguinte forma
(assumindo que o repositório esteja instalado em /var/lib/cvs):
export CVSROOT=fork:/var/lib/cvs
Depois disso, basta utilizar os comandos normais do cvs, sem precisar se autenticar no sis-
tema. Veja os detalhes de utilização dos comandos do CVS após o login em ‘Clientes de CVS’
on page 293.
17.2.3 ext
Este método de acesso lhe permite especificar um programa externo que será usado para fazer
uma conexão remota com o servidor cvs.Este programa é definido na variável CVS_RSH e
caso não ela seja especificada o padrão é rsh.
Este método requer que o usuário possua um login/senha no banco de dados de autenticação
/etc/passwd do servidor de destino. Suas permissões de acesso ao CVS (leitura/gravação)
serão as mesmas definidas neste arquivo.
O uso do acesso criptografado via ssh é possível definindo o programa ssh na variável
CVS_RSH. Veja os exemplos a seguir em ‘Configurando o método ext’ on the current page.
Para criar seu repositório, veja ‘Criando um repositório’ on page 286.
Defina a variável CVSROOT da seguinte forma para utilizar este método de acesso (assumindo
/var/lib/cvs como repositório):
Capítulo 17. CVS 281
export CVSROOT=:ext:conta@servidor.org.br:/var/lib/cvs
cvs login
A ”conta“ é uma conta de usuário existente no servidor remoto (por exemplo, gleydson)
seguido do nome do servidor remoto (separado por uma ”@“). Por exemplo para acessar o
servidor cvs.cipsga.org.br usando a conta michelle:
export CVSROOT=:ext:michelle@cvs.cipsga.org.br:/var/lib/cvs
cvs checkout
OBS: A senha via método de acesso ”ext“ será pedida somente uma vez quando for necessário
o primeiro acesso ao servidor remoto. Veja os detalhes de utilização dos comandos de CVS
após o login na seção ‘Clientes de CVS’ on page 293. O uso mais freqüente do ext é para
conexões seguras feitas via ssh, feita da seguinte forma:
export CVS_RSH=ssh
export CVSROOT=:ext:michelle@cvs.cipsga.org.br:/var/lib/cvs
cvs checkout
export CVSROOT=:ext:michelle:senha@cvs.cipsga.org.br:/var/lib/cvs
Entretanto isto não é recomendado, pois os processos da máquina poderão capturar facilmente
a senha (incluindo usuários normais, caso a máquina não esteja com patches de restrições de
acesso a processos configurada, que é o padrão em quase todas as distribuições de Linux).
Este é um método de acesso remoto que utiliza um banco de dados de usuários senhas para
acesso ao repositório. A diferença em relação ao método de acesso ext é que o pserver roda
através de um servidor próprio na porta 2401. O acesso dos usuários (leitura/gravação) no
repositório pode ser feita tanto através do banco de dados de usuários do sistema (/etc
/passwd) como através de um banco de dados separado por repositório.
Capítulo 17. CVS 282
A grande vantagem deste segundo método é que cada projeto poderá ter membros com acessos
diferenciados; o membro x poderá ter acesso ao projeto sgml mas não ao projeto focalinux;
ou o usuário y poderá ter acesso de gravação (para trabalhar no projeto focalinux) mas
somente acesso de leitura ao projeto sgml.
Este é o método de acesso preferido para a criação de usuários anônimos (uma vez que o
administrador de um servidor que hospede muitos projetos não vai querer abrir um acesso
anônimo via ext para todos os projetos).
Também existe a vantagem que novos membros do projeto e tarefas administrativas são feitas
por qualquer pessoa que possua acesso de gravação aos arquivos do repositório.
Para ativar o pserver (caso ainda não o tenha feito). Execute o comando dpkg-reconfigure
cvs e selecione a opção Ativar o servidor pserver. Uma maneira de fazer isso auto-
maticamente é modificando o arquivo /etc/inetd.conf adicionando a seguinte linha:
# na Debian
cvspserver stream tcp nowait.400 root /usr/sbin/tcpd /usr/sb
# em outras Distribuições
cvspserver stream tcp nowait root /usr/bin/cvs cvs -f --allow-root=/var/l
export CVSROOT=:pserver:michelle@cvs.cipsga.org.br:/var/lib/cvs
cvs login
Capítulo 17. CVS 283
Será pedido a senha da usuária michelle. Entrando com a senha correta, o sistema retornará
para o aviso de comando. Uma mensagem será mostrada caso a senha entrada seja incor-
reta. Daqui em diante, o resto da seção CVS é normal e você terá as permissões de acesso ao
repositório de acordo com as suas permissões de acesso naquele diretório.
OBS1: A senha poderá ser passada junto com o login da mesma forma como o ftp. Veja a
observação em ‘Configurando o método ext’ on page 280.
OBS2: A desvantagem do método pserver padrão é que a seção é feita em texto plano, desta
forma, alguns cuidados podem ser tomados para tornar o sistema um pouco mais seguro.
Um deles é dar /bin/false como shell de usuário (para desativar o login no sistema) ou
usar o método de acesso descrito em ‘Servidor pserver usando autenticação do sistema’ on the
preceding page em combinação com este. Tenha conciencia das influências disso se a máquina
for usada para outras tarefas, como um servidor ”pop3“ por exemplo.
Esta forma de acesso armazena os usuários em um banco de dados próprio, não requerendo a
criação de contas locais no arquivo /etc/passwd. Para criar um servidor deste tipo siga os
seguintes procedimentos:
1 Exporte a variável CVSROOT apontando para o repositório que deseja configu-
rar o acesso. Como isto é uma configuração administrativa, assumo o método
de acesso local sendo usada pelo usuário administrador do servidor: export
CVSROOT=/var/lib/cvs.
2 Crie um diretório para trabalhar nos arquivos administrativos do repositório: mkdir
/tmp/repos
3 Entre no diretório criado acima e execute o comando: cvs checkout .
4 Quando terminar de baixar os arquivos, entre no subdiretório CVSROOT, os arquivos
de configuração do repositório se encontram lá (para detalhes sobre cada um destes ar-
quivos, veja ‘Arquivos administrativos em CVSROOT’ on page 292.
5 Edite o arquivo config e mude a variável SystemAuth para no. Isto diz ao servidor
pserver não usar os arquivos de autenticação do sistema, mas a invés disso usar seu banco
de dados próprio. Em algumas instalações, caso exista o arquivo passwd no repositório,
o pserver automaticamente o utiliza ao invés do /etc/passwd.
6 Crie um arquivo passwd no diretório CVSROOT o formato deste arquivo é:
usuario:senha:usuario_local
Onde:
usuario Nome da conta de usuário que fará acesso ao CVS.
senha Senha que será usada pelo usuário. Ela deverá ser criptografada usando o al-
goritmo crypt. O comando mkpasswd senha pode ser usado para gerar a senha
criptografada. Caso este campo seja deixado em branco, nenhuma senha de usuário
será utilizada. O utilitário mkpasswd está presente no pacote whois na Debian.
usuario_local Usuário local que terá suas permissões mapeadas ao usuário do CVS.
Como a conta de usuário do cvs não existe no sistema, é necessário que o sistema
tenha uma maneira de saber que nível de acesso este usuário terá. Caso não crie este
usuário ou ele seja inválido, você terá erros do tipo ”: no such user“ no momento
Capítulo 17. CVS 284
que fizer o ”cvs login“. Uma forma segura de se fazer isto, é criar uma conta de
usuário *somente* com acesso aos arquivos do CVS, sem shell e senha. Isto permi-
tirá mapear a UID/GID do usuário criado com o acesso do CVS sem comprometer a
segurança do sistema de arquivos. Isto pode ser feito através do seguinte comando:
adduser --disabled-password --disabled-login usuario
É necessário especificar um diretório home do usuário, pois o servidor cvs precisa
ter acesso ao arquivo /home/do/cvs/.cvsignore. OBS1: Mais uma vez: Leve
sempre em conta a forma que os outros serviços em sua máquina estão configu-
rados (como eles fazem acesso, permissões de acesso, diretórios onde gravam ar-
quivos, são algumas delas) antes de escolher como um serviço novo na máquina
funcionará. Isto poderá modificar ou deixar vulnerável a segurança de sua insta-
lação. OBS2: Permita que os usuários somente tenham acesso a máquina via CVS.
OBS3: Certifique-se sempre que o dono/grupo do repositório seja root.src (ou
outro grupo que tenha criado) adicione somente usuários de confiança no grupo
src para criar novos projetos. Exemplos:
gleydsonm:K32dk1234k:cvsuser
anonymous::pooruser
O usuário cvs gleydsonm quando logar no cvs, terá as permissões de acesso do
usuário cvsuser do sistema. OBS1: Certifique-se que o usuário local possui per-
missões de gravação no diretório do CVS, caso contrário ele não poderá fazer com-
mits. Lembre-se que as permissões de leitura/gravação do usuário serão contro-
ladas através de arquivos do próprio pserver, mas também é necessária a permissão
de gravação do usuário no repositório. Isto poderá ser feito através de grupos de
sistema e garante uma dupla camada de segurança. OBS2: Caso tenha preferido
usar o pserver sob um usuário diferente de root e esteja obtendo a mensagem
setgid failed: Operation not permitted, significa que o servidor CVS
não consegue mudar para o grupo referente ao usado no diretório do repositório.
Verifique se as permissões estão adequadas e se o grupo do usuário CVS no /etc
/passwd é o mesmo que especificou para acesso ao repositório.
7 Para dar direito de leitura ao repositório, crie um arquivo chamado readers e adicione
os nomes de usuários que terão acesso ao repositório (um por linha). O nome que deverá
ser usado é o nome do usuário de CVS e não do sistema (usuário gleydsonm, segundo
o exemplo). Exemplo:
gleydsonm
anonymous
8 Para dar direito de gravação ao repositório, crie um arquivo chamado writers. Seu
formato é idêntico ao arquivo readers. Exemplo:
gleydsonm
macan
otavio
hmh
kov
9 Pronto, o acesso a CVS usando um banco de dados próprio está pronto! basta dar o com-
mit nos arquivos, adicionar os arquivos readers, writers e passwd no repositório
(veja ‘Adicionando um arquivo ao módulo CVS do servidor’ on page 289) para o servidor
de CVS para te-lo funcionando. Note que em versões mais novas do CVS, não é possível
Capítulo 17. CVS 285
transferir o arquivo passwd via rede, então será necessário cria-lo manualmente dentro
do repositório do servidor. OBS: O arquivo passwd não é transferido pelo commit por
motivos de segurança, pois ele contém senhas que podem ser capturadas e usada por pes-
soas maliciosas. Será necessário transferi-lo manualmente para o repositório do servidor
remoto (você terá que ser o usuário root ou ter permissões adequadas). O recomendável
é utilizar o scp (‘scp’ on page 257) para realizar transferências seguras. .
O método de acesso do CVS aos arquivos readers e writers é restritiva, portanto se um
nome de usuário existir no arquivo readers e writers o que valerá será o menor nível de
acesso. Vendo os exemplos acima, os usuários gleydsonm e anonymous terão somente acesso a
leitura do repositório e macan, otavio, hmh, kov acesso de leitura e gravação.
17.2.6 gssapi
Quando o CVS é compilado com o suporte a Kerberos 5, ele tenta estabelecer automaticamente
uma conexão segura usando este método. Este método funciona somente se o CVS estiver
compilado com o suporte a Kerberos (opção --with-gssapi).
Esta seção descreve todos os passos necessários para colocação de um projeto para ser desen-
volvido através do CVS, os comandos do cvs, considerações a respeito dos comandos e sua
utilização através de exemplos didáticos.
17.3.1 Repositório
var/lib
|
+- cvs
|- CVSROOT
|- projeto1
+- projeto2
Capítulo 17. CVS 286
Nas seções seguintes serão explicados cada um dos comandos usados para trabalhar com um
projeto no cvs.
Quando é usado o método de acesso pserver (‘pserver (password server)’ on page 281), é
necessário fazer para ter acesso ao repositório. Por exemplo, para acessar o repositório /var
/lib/cvs no servidor servidor.org.br:
export CVSROOT=:pserver:anonymous@servidor.org.br:/var/lib/cvs
cvs login
ou
Então será solicitada a senha para ter acesso ao sistema. Note que toda a seção de cvs ocorre
por comandos interativos que logo após concluídos retornam para o interpretador de coman-
dos. O restante desta seção descreverá estes comandos e como utiliza-los de maneira eficiente.
OBS: O uso da variável CVSROOT torna a utilização bastante prática, assim não precisamos
especificar o repositório, método de acesso, etc. toda vez que usar um comando do cvs.
Embora que não seja necessário, após o uso do cvs é recomendável executar o logout do servi-
dor para encerrar sua conexão com a máquina remota.
ou
OBS: Para os paranóicos é importante encerrar uma seção de CVS, pois ele possui alguns bugs
e um spoofing pode tornar possível o uso de uma seção deixada aberta.
O comando checkout (ou ”co“) é usado para fazer isto. Para utilizá-lo seguindo os exemplos
anteriores:
mkdir /tmp/cvs
cd /tmp/cvs
cvs checkout modulo
cvs -d :pserver:anonymous@servidor.org.br:/var/lib/cvs
Será criado um subdiretório chamado modulo que contém todos os arquivos do servidor de
CVS remoto. É necessário apenas que tenha acesso de leitura ao servidor de CVS para executar
este comando. Você pode usar a opção -z [num] para ativar a compactação na transferência
dos arquivos, isso acelera bastante a transferência em conexões lentas: cvs -z 3 checkout
modulo.
Também é possível especificar apenas subdiretórios de um módulo para baixa-lo via CVS e a
estrutura de diretórios criada localmente será idêntica ao do servidor remoto.
Capítulo 17. CVS 288
Use o comando cvs import para adicionar um novo projeto ao CVS. As entradas nos ar-
quivos administrativos serão criadas e o projeto estará disponível para utilização dos usuários.
A sintaxe básica do comando import é a seguinte:
cvs import [opções] [dir_modulo] [tag] start
Para adicionar o projeto focalinux que reside em /usr/src/focalinux ao cvs:
cd /usr/src/focalinux
cvs import documentos/focalinux tag_modulo start
Por padrão o import sempre utiliza a máscara * para fazer a importação dos ar-
quivos do diretório atual. O projeto focalinux será acessado através de $CVS-
ROOT/documentos/focalinux (cvs checkout documentos/focalinux), ou seja, /var
/lib/cvs/documentos/focalinux no servidor CVS terá a cópia do focalinux.
tag_modulo define o nome que será usado como identificador nas operações com os arquivos
do CVS (pode ser usado ”focalinux“ em nosso exemplo). O parâmetro ”start“ diz para criar o
módulo.
OBS: Por segurança, o diretório que contém os arquivos deverá ser sempre um caminho rel-
ativo na estrutura de diretórios, ou seja, você precisará entrar no diretório pai (como /usr
/src/projeto) para executar o cvs import. Não é permitido usar / ou .., isto proíbe a
descida em diretórios de nível mais altos e sérios incidentes de segurança em servidores CVS
mal configurados pelo Administrador.
Este comando sincroniza a cópia remota do CVS (ou arquivo) com a cópia local que está trabal-
hando em sua máquina. Quando se trabalha nativamente no CVS em equipe é recomendado
a utilização deste comando pois alguém pode ter modificado o arquivo antes de você, então
uma incompatibilidade entre sua versão e a nova poderia causar problemas.
Supondo que tenha acabado de modificar o arquivo main.c do módulo cvsproj, então antes
de fazer o commit (‘Enviando as mudanças para o servidor remoto’ on the facing page) use o
update:
ou
Após alguns segundos, sua cópia local ficará sincronizada com a cópia remota. Caso ele mostre
alguma mensagem de saída, verifique o arquivo para solucionar qualquer conflito e então
envie o arquivo para o servidor remoto (‘Enviando as mudanças para o servidor remoto’ on
the current page).
Você pode fazer o update de mais arquivos usando referências globais (*, ? ou []).
O comando ”commit“ (ou ”ci“), envia as mudanças feitas nos arquivos locais para o servidor
remoto. Um exemplo de commit no arquivo main.c:
cvs commit *
O editor padrão do sistema será aberto e pedirá uma descrição das modificações para o com-
mit. Esta descrição será usada como referência sobre as atualizações feitas em cada etapa do de-
senvolvimento. A mensagem também pode ser especificada usando a opção ”-m mensagem“,
principalmente quando o texto explicando as alterações é pequeno.
Para mudar o editor de texto padrão que será usado pelo cvs, altere a variável de ambiente
EDITOR ou especifique o editor que deseja usar na linha de comando com a opção ”-e editor“:
Após criar/copiar o arquivo para seu diretório de trabalho, use o comando add para fazer isto.
O arquivo será enviado ao servidor, bastando apenas executa o commit para salvar o arquivo:
Os dois primeiros comandos agendam o diretório teste e fazem o commit no diretório re-
moto. Os dois últimos, enviam os arquivos existentes dentro deste diretório para o servidor
remoto.
O comando para fazer isto é o ”remove“. Primeiro use o rm para remover o arquivo/diretório
de sua cópia local, depois execute o remove seguido de commit para confirmar a remoção do
arquivo:
Para remover um diretório, primeiro remova todos os arquivos existentes dentro dele com o
comando rm e salve para o servidor (seguindo os métodos descritos em ‘Removendo um ar-
quivo do módulo CVS remoto’ on the current page). O CVS não remove diretamente diretórios
vazios, uma maneira de contornar isto é usar o update ou commit seguido da opção -P para
ignorar diretórios vazios. Então a cópia remota do diretório será removida do servidor:
rm -f teste/*
cvs remove teste/.
cvs commit teste/.
cd ..
cvs checkout modulo
O comando ”release“ faz esta função. Ele não é requerido, mas caso você tenha feito mod-
ificações que ainda não foram salvas no servidor de cvs (commit), ele alertará de arquivos
modificados e perguntará se deseja continuar. Registrando também o abandono das modi-
ficações no histórico do cvs. O comando pode ser acompanhado de ”-d“ para remover o
módulo anteriormente baixado com o ”commit“:
Capítulo 17. CVS 291
O release retorna os seguintes códigos quando verifica que as duas cópias (local e remota)
não estão sincronizadas:
U ou P Existe uma versão nova do arquivo no repositório. Para corrigir isso, execute o co-
mando ”update“.
A O arquivo não foi adicionado ainda ao repositório remoto. Se apagar o repositório local,
este arquivo não será adicionado. Para corrigir isto, executa o comando ”add“ do cvs.
R O arquivo foi removido localmente, mas não foi removido do servidor remoto. Use os pro-
cedimentos em ‘Removendo um arquivo do módulo CVS remoto’ on the facing page
para corrigir a situação.
M O arquivo está modificado localmente e não foi salvo ainda no servidor. Use os procedi-
mentos em ‘Sincronizando a cópia remota com a cópia local’ on page 288 e ‘Enviando as
mudanças para o servidor remoto’ on page 289 para salvar o arquivo.
? O arquivo está em seu diretório de trabalho mas não tem referências no repositório remoto
e também não está na lista de arquivos ignorados do CVS.
Com o comando ”diff“ é possível visualizar que diferenças o arquivo que está sendo editado
possui em relação ao arquivo do repositório remoto. Outra funcionalidade útil do ”diff“ é
comparar 2 versões de arquivos do mesmo repositório CVS. Exemplos:
cvs diff main.c Verifica as diferenças entre o arquivo main.c local e remoto.
cvs diff -u -r 1.1 -r 1.2 main.c Mostra as diferenças em formato unificado para mostrar as
diferenças entre as versões 1.1 e 1.2 do arquivo main.c.
O comando ”status“ permite verificar que versões do arquivo especificado está disponível lo-
calmente, remotamente, qual a versão inicial do arquivo no repositório, sticky tag. Exemplos:
cvs status main.c Verifica o status do arquivo main.c.
cvs status -v main.c Mostra o status do arquivo main.c, adicionalmente mostra também as
tags existentes no arquivo (versão inicial, versão do repositório).
Além dos comandos do cvs descritos aqui, existem comandos no pacote cvsutils que aux-
iliam desde quem está aprendendo a utilizar o CVS (com o comando cvsdo para simular
algumas operações de adição/remoção de arquivos) até profissionais que usam o programa
no dia a dia (cvsu, cvsco, cvschroot).
Capítulo 17. CVS 292
Esta seção descreve a função de cada um dos arquivos administrativos, isto pode ser útil na
configuração e personalização do CVS e de seu repositório.
Para não alongar muito o capítulo, procurei colocar uma breve descrição da função de cada
um deles, o comentários e exemplos existentes nos arquivos oferecem uma boa compreensão
do seu conteúdo.
17.4.1 config
Este arquivo é segue os padrões do arquivos de configuração e possui alguns parâmetros que
controlam o comportamento do CVS. Segue uma lista deles:
SystemAuth Define se será utilizado a autenticação via /etc/passwd quando o método
pserver for utilizado. Note que se o arquivo passwd for criado no CVSROOT, o SystemAuth
será definido automaticamente para no. Exemplo: SystemAuth=yes.
LockDir Especifica o diretório onde serão gravados os arquivos de lock. Caso não seja especi-
ficado, será usado o diretório do CVS. Exemplo: LockDir=/var/lock/cvs
TopLevelAdmin Permite criar ou não um diretório chamado CVS no root do diretório de tra-
balho durante o cvs checkout.
LogHistory Utiliza opções para especificar o que será registrado nos arquivos de log do CVS.
• TOFEWGCMAR ou all Registra todas as operações nos logs do cvs.
• TMAR Registra todas as operações que modificam os arquivos ",v"
17.4.2 modules
Especifica opções e programas externos que serão usados durante a execução de comandos no
repositório CVS.
17.4.3 cvswrappers
Este arquivo define ações de controle de características de arquivos, de acordo com seu nome.
Pode ser também definidas ações através de arquivos .cvswrappers.
17.4.4 commitinfo
Define programas para fazer uma checagem baseada no diretório e dizer se o commit é permi-
tido.
17.4.5 verifymsg
17.4.6 loginfo
Programa que é executado após o commit. Ele pode ser usado para tratar a mensagem de log
e definir onde ela será gravada/enviada, etc.
17.4.7 cvsignore
Tudo que constar neste arquivo não será gravado (commit) no cvs. Referências globais podem
ser usadas para especificar estes arquivos. Veja a info page do cvs para detalhes sober seu
formato.
Pode também ser especificado através de arquivos .cvsignore.
17.4.8 checkoutlist
Especifica os arquivos que deseja manter sobre o controle do CVS que se encontram em
CVSROOT. Se adicionar um script adicional, ou qualquer outro arquivo no diretório CVSROOT
ele deverá constar neste arquivo.
17.4.9 history
17.5.1 cvs
Este é o cliente Unix padrão, bastante poderoso e que opera em modo texto. As explicações
neste capítulo do guia assumem este cliente de cvs, então as explicações sobre sua utilização
se encontra em ‘Criando projetos para serem usados no CVS’ on page 285 e os parâmetros de
linha de comando em ‘Opções de linha de comando’ on page 278
É altamente recomendável a leitura caso deseje utilizar um cliente de cvs gráfico, pois os
conceitos são os mesmos.
Capítulo 17. CVS 294
Este é um cliente CVS em GTK+Python para Linux que interage externamente com o cliente
cvs externo, todas as opções do cvs estão disponíveis através de checkboxes nas telas de co-
mando, incluindo suporte a compactação, visualizador gráfico da árvore de releases, histórico,
diffs, etc.
Sua instalação é bastante fácil, instale o programa com apt-get install gcvs e execute
o programa através do menu do sistema ou do terminal. Utilize os seguintes procedimentos
para configurar e utilizar o programa:
1 Defina o repositório CVSROOT através do menu Admin/Preferences. Selecione o método
de acesso, entre com o login, servidor e repositório.
Exemplo: :pserver:anonymous@servidor:/var/lib/cvs
O formato deve ser EXATAMENTE como o usado na variável CVSROOT no shell, in-
cluindo os ”:“. Caso tenha erros de login, verifique o valor de CVSROOT cuidadosamente
antes de contactar o administrador de sistemas!
2 Agora faça o login no sistema em: Admin, Login. Note que o status de todas as operações
do cvs são mostradas na janela de status que fica na parte inferior da tela.
3 Crie um diretório que será usado para armazenar os fontes baixados do CVS, por exem-
plo: mkdir ~/projetos
4 Acesse o menu Create, Checkout Module para baixar o projeto do CVS para sua máquina
local. Ele irá te pedir o nome de diretório para onde o código fonte do servidor CVS será
baixado. Digite ~/projetos ou outro diretório que foi criado no passo anterior. OBS:
Não utilize o nome "cvs" para o diretório local, pois o gcvs oculta automaticamente
pois os arquivos administrativos de controle ficam neste local.
5 Altere o diretório padrão do gcvs para o diretório onde baixou o projeto (~
/projetos)clicando no botão ”set“ no topo da coluna esquerda do gcvs.
6 Para enviar um arquivo modificado de volta ao servidor, selecione os arquivos, clique
em Modify, Commit Selection, entre com a mensagem descrevendo as alterações e clique
em ”OK“. Note que os arquivos modificados serão identificados por um ícone vermelho
e seu status será ”Mod. File“ (arquivo modificado).
7 Se desejar adicionar um novo projeto no CVS, entre em Create, Import Module, entre no
diretório que deseja adicionar como um projeto no servidor de CVS. Após isto será feita
uma checagem e mostrada uma tela de possíveis problemas que podem ocorrer durante
a importação do novo projeto. Na próxima tela, digite o nome do módulo e caminho no
servidor remoto no primeiro campo, no segundo campo a mensagem de log para adi-
cionar o projeto ao servidor. Em ”Vendor tag“ especifique o nome do projeto e sua ver-
são logo abaixo. Clique em ”OK“ e aguarde a transferência dos arquivos para o servidor.
Para maiores detalhes sobre a criação de novos projetos no servidor de CVS, veja ‘Adi-
cionando um novo projeto’ on page 288. OBS: Você deverá ter permissão de gravação
para criar um novo projeto no servidor CVS.
8 A partir de agora você poderá explorar as funções do programa e fazer uso das funções
habituais do CVS. Todas as funções de operação e opções extras do CVS estão disponíveis
na interface gráfica, basta se acostumar com sua utilização.
Após isto, explore bastante as opções do programa. Todas as funcionalidades do CVS estão
organizadas entre os menus do programa. Caso não entenda bem as funções do programa,
Capítulo 17. CVS 295
leia atentamente ‘Criando projetos para serem usados no CVS’ on page 285 e também não
deixe de consultar detalhes na info page do cvs.
Este é um cliente CVS em Python para Windows equivalente ao gcvs para Linux. Suas
funcionalidades e recomendações são idênticas aos do gcvs. Este cliente pode ser baix-
ado de: http://telia.dl.sourceforge.net/sourceforge/cvsgui/WinCvs13b13.
zip e o Python para Windows de http://starship.python.net/crew/mhammond/
downloads/win32all-153.exe.
Para sua utilização, as explicações em ‘gcvs - Linux’ on the preceding page são totalmente
válidas.
17.5.5 viewcvs
Este é um visualizador de repositórios CVS via web, ele precisa apenas de um servidor web
instalado com suporte a CGI. Para instalar, execute o comando apt-get install viewcvs
e siga os passos para configurar programa. Para adequar melhor o viewcvs ao seu sistema,
edite o arquivo /etc/viewcvs/viewcvs.conf.
O viewcvs possui uma interface que se parece com a navegação de um diretório de ftp, recur-
sos como a extração de diffs coloridos entre versões de um arquivo selecionado, visualização
de commits (com data, log do commit, usuário, etc.), classificação da listagem exibida.
OBS:Leve em consideração as implicações de segurança impostas por aplicativos cgi sendo
executados em seu sistema. Veja ‘Apache’ on page 171 para entender melhor o assunto.
Nota: este exemplo é apenas didático, não foi feita nenhuma modificação real no conteúdo do
repositório do dillo :-)
# Definir o CVSROOT
export CVSROOT=:pserver:gleydson@ima.cipsga.org.br:/var/lib/cvs
# entrar no servidor
gleydson@host:/tmp/teste$ cvs login
Capítulo 17. CVS 296
Logging in to :pserver:gleydson@ima.cipsga.org.br:2401/var/lib/cvs
CVS password: <password>
gleydson@oberon:/tmp/teste$
U dillo/dillo/doc/Dw.txt
U dillo/dillo/doc/DwImage.txt
U dillo/dillo/doc/DwPage.txt
...
gleydson@host:/tmp/teste
# Saimos do sistema
cvs logout
Capítulo 17. CVS 298
299
Capítulo 18
SAMBA
Uma seção foi especialmente separada para os mais paranóicos (como eu) conhecerem, combi-
nar e aplicar as restrições de forma mais adequada a configuração da máquina.
18.1 Introdução
Na lógica da rede Windows o NetBEUI é o protocolo e o NETBIOS define a forma com que
os dados são transportados. Não é correto dizer que o NetBIOS é o protocolo, como muitos
fazem.
Com o SAMBA, é possível construir domínios completos, fazer controle de acesso a nível de
usuário, compartilhamento, montar um servidor WINS, servidor de domínio, impressão, etc.
Na maioria dos casos o controle de acesso e exibição de diretórios no samba é mais minucioso
e personalizável que no próprio Windows.
O guia Foca GNU/Linux documentará como instalar e ter as máquinas Windows de difer-
entes versões (Win3.11, Win95, Win95OSR/2, Win98, XP, WinNT, W2K) acessando e
comunicando-se entre si em uma rede NetBEUI. Estas explicações lhe poderão ser indispen-
sáveis para solucionar problemas, até mesmo se você for um técnico especialista em redes
Windows e não tem ainda planos de implementar um servidor SAMBA em sua rede.
Capítulo 18. SAMBA 300
18.1.2 História
Andrew Tridgell - Desenvolveu o samba porque precisava montar um volume Unix em sua
máquina DOS. Inicialmente ele utilizava o NFS, mas um aplicativo precisava de suporte Net-
BIOS. Andrew então utilizou um método muito avançado usado por administradores para
detectar problemas: escreveu um sniffer de pacotes que atendesse aos requerimentos para ter
uma única função: analisar e auxilia-lo a interpretar todo o tráfego NetBIOS da rede.
Ele escreveu o primeiro código que fez o servidor Unix aparecer como um servidor de arquivos
Windows para sua máquina DOS que foi publicado mais ou menos em meados de 1992 quando
também começou a receber patches. Satisfeito com o funcionamento de seu trabalho, deixou
seu trabalho de lado por quase 2 anos. Um dia, ele resolveu testar a máquina Windows de
sua esposa com sua máquina Linux, e ficou maravilhado com o funcionamento do programa
que criou e veio a descobrir que o protocolo era documentado e resolveu levar este trabalho a
fundo melhorando e implementando novas funções.
Sua configuração pode receber ajustes finos pelo administrador nos soquetes TCP de transmis-
são, recepção, cache por compartilhamento, configurações físicas que afetam a performance
de rede. Seu código vem sendo melhorado constantemente por hackers, obtendo excelente
performance com hardwares mais obsoletos. O guia tem por objetivo abordar estes temas e
permitir que você configure seu sistema com uma performance batendo a mesma alcançada
em um servidor NT dedicado.
18.1.3 Contribuindo
Caso encontre um bug no programa, ele poderá ser relatado se inscrevendo na lista de
discussão samba-technical-request@lists.samba.org. Após responder a mensagem de confir-
mação, envie um relato detalhado do problema encontrado no programa.
Capítulo 18. SAMBA 301
18.1.4 Características
Pacote samba
Outros utilitários importantes para a operação do clientes samba.
• smbclient - Ferramenta para navegação e gerenciamento de arquivos, diretórios e im-
pressoras compartilhados por servidores Windows ou samba.
• smbfs - Pacote que possui ferramentas para o mapeamento de arquivos e diretórios com-
partilhados por servidores Windows ou samba em um diretório local.
• winbind - Daemon que resolve nomes de usuários e grupo através de um servidor
NT/SAMBA e mapeia os UIDs/GIDs deste servidor como usuários locais.
Processador 386 ou superior, 15 MB de espaço em disco (não levando em conta os logs gerados
e espaço para arquivos de usuários, aplicativos, etc.), 8 MB de memória RAM.
18.1.8 Instalação
Digite apt-get install samba smbclient smbfs para instalar o conjunto de aplica-
tivos samba. O pacote samba é o servidor samba e os pacotes smbclient e smbfs fazem parte
dos aplicativos cliente. Caso deseje apenas mapear compartilhamentos remotos na máquina
Linux, instale somente os 2 últimos pacotes.
O servidor samba pode ser executado tanto via inetd como daemon:
inetd No modo inetd, o servidor de nomes nmbd será carregado assim que for feita a primeira
requisição de pesquisa e ficará residente na memória. No caso de acesso a um compar-
tilhamento, o smbd será carregado e lerá a configuração em smb.conf a cada acesso do
cliente a um compartilhamento. Quando o samba opera via inetd, ele não usa o controle
Capítulo 18. SAMBA 303
Este capítulo documenta como configurar o seu servidor SAMBA permitindo o acesso a com-
partilhamento de arquivos e impressão no sistema.
Toda a máquina em uma rede NetBEUI é identificada por um nome, este nome deve ser único
na rede e permite que outras máquinas acessem os recursos disponibilizados ou que sejam
enviadas mensagens para a máquina. Este nome é composto de 16 caracteres, sendo 15 que
identificam a máquina e o último o tipo de serviço que ela disponibiliza. O tipo de serviço é as-
sociado com o nome da máquina e registrado em servidores de nomes confirme a configuração
da máquina (você verá isto mais adiante).
Capítulo 18. SAMBA 304
O nome de máquina é especificado nas diretivas netbios name e netbios aliases (veja ‘Nomes e
grupos de trabalho’ on page 307) para detalhes.
redes
gleydson
tecnico
marcelo
henrique
michelle
rh
mrpaoduro
web
web1
web2
web3
comunicacao
comunic1
comunic2
comunic3
18.2.3 Domínio
Domain Controller) deverá ter todas as contas de acesso que serão utilizadas pelo usuário para
acessar os recursos existentes em outras máquinas, script de logon que poderá ser executado
em cada máquina para fazer ajustes, sincronismo, manutenção ou qualquer outra tarefa pro-
gramada pelo administrador do sistema.
Estas características para configuração de máquinas em domínio são documentadas passo a
passo em ‘Uma breve introdução a um Domínio de rede’ on page 325.
18.2.4 Compartilhamento
18.2.5 Mapeamento
Esta função é controlada pelo nmbd que fica ativo o tempo todo disponibilizando os recursos
da máquina na rede, participando de eleições NetBIOS (‘Níveis de sistema para eleição de rede’
on page 314), fazer logon de máquinas no domínio (‘Uma breve introdução a um Domínio de
rede’ on page 325), etc.
Capítulo 18. SAMBA 306
Toda a configuração relacionada com nomes, grupo de trabalho, tipo de servidor, log, compar-
tilhamento de arquivos e impressão do samba é colocada no arquivo de configuração /etc
/samba/smb.conf. Este arquivo é dividido em seções e parâmetros.
Uma seção no arquivo de configuração do samba (smb.conf) é definido por um nome entre
”[ ]“. As seções tem o objetivo de organizar os parâmetros pra que tenham efeito somente
em algumas configurações de compartilhamento do servidor (exceto os da seção [global]
que não especificam compartilhamentos, mas suas diretivas podem ser válidas para todas os
compartilhamentos do arquivo de configuração). Alguns nomes de seções foram reservados
para configurações específicas do samba, eles são os seguintes:
[global] Define configurações que afetam o servidor samba como um todo, fazendo efeito
em todos os compartilhamentos existentes na máquina. Por exemplo, o grupo de tra-
balho, nome do servidor, página de código, restrições de acesso por nome, etc. Veja
‘Seção [global]’ on the next page.
[homes] Especifica opções de acesso a diretórios homes de usuários. O diretório home
é disponibilizado somente para seu dono, após se autenticar no sistema. Veja ‘Seção
[homes]’ on page 312.
[printers] Define opções gerais para controle das impressoras do sistema. Este compar-
tilhamento mapeia os nomes de todas as impressoras encontradas no /etc/printcap.
Configurações especiais podem ser feitas separadamente. Veja ‘Seção [printers]’ on
page 313.
[profile] Define um perfil quando o servidor samba é usado como PDC de domínio. Veja
‘Configurando perfis de usuários’ on page 332.
Qualquer outro nome de [seção] no arquivo smb.conf que não sejam as acima, são tratadas
como um compartilhamento ou impressora.
Um parâmetro é definido no formato nome = valor. Para um exemplo prático, veja um exemplo
de arquivo smb.conf em ‘Exemplos de configuração do servidor SAMBA’ on page 367. Na
configuração de booleanos, a seguinte sintaxe pode ser usada:
• 0 ou 1
• yes ou no
• true ou false
Assim, as seguintes configurações são equivalentes
master browse = 0
Capítulo 18. SAMBA 307
master browse = no
master browse = false
Todos significam ”NÃO ser o navegador principal de domínio“. A escolha fica a gosto do
administrador. Durante a configuração, você notará o poder da flexibilidade oferecida pelo
samba na configuração de um servidor SMB :-)
Linhas iniciadas por # ou ; são tratadas como comentário. Quebras de linha pode ser especi-
ficadas com uma \ no final da linha.
Os parâmetros especificados nesta seção tem efeito em todo o servidor samba incluindo os
compartilhamentos. Caso o parâmetro seja novamente especificado para o compartilhamento,
o valor que valerá é o do compartilhamento.
Por exemplo, se guest user = nobody for usado na seção [global] e o guest user =
foca for usado no compartilhamento [focalinux], o usuário que fará acesso público a
todos os compartilhamentos do servidor será o nobody, exceto para o compartilhamento
[focalinux], que será feito pelo usuário foca. Veja ‘Compartilhamento de arquivos e di-
retórios’ on page 316 para obter uma lista e descrição dos principais parâmetros de compartil-
hamentos existentes. Uma lista completa pode ser obtida na página de manual do smb.conf.
Irei descrever alguns parâmetros utilizados nesta seção, organizado de forma didática e sim-
plificada.
netbios name = [nome do servidor ] Especifica o nome NetBIOS primário do servidor samba.
Caso não seja ajustado, ele usará o hostname de sua máquina como valor padrão. Ex.:
netbios name = focasamba.
workgroup = [grupo de trabalho/domínio ] Diz qual o nome do grupo de trabalho/domínio
que a máquina samba pertencerá. Ex.: workgroup = focalinux.
netbios aliases = [nomes alternativos ao sistema ] Permite o uso de nomes alternativos ao
servidor, separados por espaços. Ex.: teste1 teste2.
server string = [identificação ] Identificação enviada do servidor samba para o ambiente de
rede. A string padrão é Samba %v (%v é substituída pela versão do samba, para
maiores detalhes, veja ‘Variáveis de substituição’ on page 315). Ex: server string
= Servidor Samba versão %v.
name resolve order = [ordem ] Define a ordem de pesquisa para a resolução de nomes no
samba. A ordem padrão é: lmhosts host wins bcast, que é a melhor para res-
olução rápida e que tente gerar menos tráfego broadcast possível. Veja ‘Resolução de
nomes de máquinas no samba’ on page 321 para uma explicação mais detalhada.
Capítulo 18. SAMBA 308
Uma das partes essenciais após colocar o SAMBA em funcionamento, é configurar a página de
código para que os caracteres sejam gravados e exibidos corretamente no cliente. A primeira
coisa que precisa verificar é se seu kernel possui o suporte a página de código local. Caso não
tenha, baixe o fonte do kernel e siga os seguintes passos na configuração:
• Dentro da opção ”File Systems“, ”Network File Systems“ defina como ”Default Remote
NLS Option“ a iso8859-1. Esta opção permite ao smbmount montar os volumes locais
usando os caracteres corretos.
• Entre na opção ”File Systems“, ”Native Language Support“. Na opção ”Default NLS
Option“ coloque ”iso8859-1“. Ative também o suporte as páginas de código 437, 850 e
860 e também ao conjunto de caracteres iso8859-1 e UTF8.
Note que esta ordem pode variar dependendo da versão do seu kernel, basta que as entenda
para fazer as modificações apropriadas.
character set = [conjunto_caracteres ] Seleciona o conjunto de caracteres dos arquivos ex-
ibidos pelo servidor samba. Para os idiomas de língua latina, sempre utilize iso8859-1.
Ex.: character set = iso8859-1.
client code page = [pagina_de_codigo ] Seleciona a página de código do servidor samba para
tratar os caracteres. Para os idiomas de língua latina, sempre utilize 850. Ex.: client
code page = 850.
preserve case = Seleciona se arquivos com nomes extensos criados serão criados com os car-
acteres em maiúsculas/minúsculas definidos pelo cliente (no) ou se será usado o valor
de default case (caso seja especificado yes).
short preserve case = Seleciona se os arquivos com nomes curtos (formato 8.3) serão criados
com os caracteres mixtos enviados pelo cliente (no) ou se será usando o valor de default
case (caso seja especificado yes).
default case = [lower/upper ] Define se os arquivos criados terão seus nomes todos em minús-
culas (lower) ou maiúsculas (upper).
valid chars = [caracteres ] Define caracteres válidos nos nomes de arquivos: valid chars
=á:Á é:É í:Í ó:Ó ú:Ú â:Â ê:Ê ô:Ô ã:Ã õ:Õ à:À ò:Ò. Este parâmetro DEV-
ERÁ ser sempre especificado depois do client code page, pois caso contrário, eles
serão substituídos por estes.
guest account = [conta] Define a conta local de usuário que será mapeada quando um
usuário se conectar sem senha (usuário guest). Veja mais detalhes em ‘Descrição de
parâmetros usados em compartilhamento’ on page 317.
invalid users Define uma lista de usuários que não terão acesso aos recursos do servidor
ou compartilhamento. É seguro restringir o acesso samba a usuários com grande poder
no sistema (como o root). Veja mais detalhes em ‘Restringindo o acesso por usuários’
on page 346.
valid users Semelhante a opção invalid users mas permite que somente os usuários
especificados tenham acesso ao sistema. Veja mais detalhes em ‘Restringindo o acesso
por usuários’ on page 346.
Capítulo 18. SAMBA 309
default service = nome Caso o serviço que o usuário deseja se conectar não for encon-
trado no servidor, o SAMBA mapeará o serviço especificado nesta diretiva como alterna-
tiva. A variável ”%S“ e o caracter ”_“ podem ser interessantes em algumas alternativas
de configuração. A opção default é um sinônimo para esta opção. Caso utilize esta
opção, crie o compartilhamento em modo somente leitura e com acesso público, caso con-
trário (dependendo do planejamento de partições e segurança do sistema de arquivos) a
máquina poderá ser derrubada sem dificuldades.
username map = [arquivo] Especifica um arquivo que faz o mapeamento entre nomes
fornecidos por clientes e nomes de contas Unix locais. Veja ‘Mapeamento de nomes de
usuários’ on page 354 para mais detalhes de como configurar este recurso.
obey pam restrictions = yes Indica se as restrições do usuário nos módulos PAM terão efeito
também no SAMBA.
Níveis de autenticação
(esta seção contém algumas explicações que dependem do resto do conteúdo do guia, caso não
entenda de imediato a fundo as explicações, recomendo que a leia novamente mais tarde).
Define o nível de segurança do servidor. Os seguintes valores são válidos:
• share - Usada principalmente quando apenas a senha é enviada por compartil-
hamento acessado para o servidor, caso muito típico em sistemas Lan Manager e
Windows for Workgroups. Mesmo assim o samba tenta mapear para um UID
de usuário local do sistema usando os seguintes métodos (retirado da página de
manual do samba):
1 Se o parâmetro guest only é usado no compartilhamento junto com o guest
ok, o acesso é imediatamente permitido, sem verificar inclusive a senha.
2 Caso um nome de usuário seja enviado junto com a senha, ele é utilizado para
mapear o UID e aplicar as permissões deste usuário (como acontece no nível de
segurança user).
3 Se ele usou um nome para fazer o logon no Windows este nome será usado
como usuário local do SAMBA. Caso ele seja diferente, você deverá usar o ma-
peamento de nomes para associar o nome remoto do nome local (veja ‘Mapea-
mento de nomes de usuários’ on page 354)
4 O nome do serviço é tentado como nome de usuário.
5 O nome da máquina NetBios é tentada como nome de usuário
6 Os usuários especificados na opção user do compartilhamentos são utilizados
(veja ‘Descrição de parâmetros usados em compartilhamento’ on page 317).
7 Caso nenhum destes métodos acima for satisfeito, o acesso é NEGADO.
Hoje em dia, o uso do nível de acesso share é raramente usado, porque todos os
sistemas a partir do Windows 95 e acima enviam o nome de usuário ao acessar
um compartilhamento (caindo na segunda checagem do nível share), sendo equiv-
alente a usar o nível user. Entretanto, o nível de segurança share é recomendado
para servidores onde TODO o conteúdo deve ter acesso público (seja leitura ou
gravação) e o parâmetro guest shares também funciona nativamente. As sen-
has criptografadas (encrypt passwords = 1) NÃO funcionarão no nível share,
lembre-se deste detalhe.
Capítulo 18. SAMBA 310
• user - Este é o padrão. O usuário precisa ter uma conta de usuário no Linux para
acessar seus compartilhamentos. A mesma conta de usuário/senha deverá ser us-
ada no Windows para acessar seus recursos ou realizado um mapeamento de nomes
de usuários (veja ‘Mapeamento de nomes de usuários’ on page 354). Este é o padrão
do SAMBA. No nível de acesso user o usuário precisa ser autenticado de qualquer
forma, inclusive se for usado o parâmetro guest only ou user. Os seguintes
passos são usados para autorizar uma conexão usando o nível user (retirado da doc-
umentação do SAMBA):
– É tentada a validação usando o nome/senha passados pelo cliente. Se tudo
estiver OK, a conexão é permitida.
– Caso já tenha se autenticado anteriormente para acessar o recurso e forneceu a
senha correta, o acesso é permitido.
– O nome NetBIOS da máquina do cliente e qualquer nome de usuário que foi
usado é novamente tentado junto com a senha para tentar permitir o acesso ao
recurso compartilhado.
– Caso o cliente tenha validado o nome/senha com o servidor e o cliente enviou
novamente o token de validação, este nome de usuário é usado.
– É tentada a checagem com o parâmetro user no compartilhamento (veja ‘De-
scrição de parâmetros usados em compartilhamento’ on page 317.
– É verificado se o serviço é público, então a conexão é feita usando o usuário
guest account e ignorando a senha (veja ‘Criando um compartilhamento
para acesso sem senha’ on page 347).
• domain - Neste nível, o acesso só será permitido quando a máquina for adicionada
ao domínio com o smbpasswd (‘Linux’ on page 364). Neste nível de acesso, a conta
de usuário será validada em um servidor PDC (controlador de domínio) e o acesso
aos recursos das máquinas que fazem parte do domínio será feito a partir do PDC.
Veja ‘Linux’ on page 364 para detalhes.
• server - A máquina samba tentara autenticar o usuário em outro servidor NT (ou
samba). No caso da autenticação falhar, será usado o nível de acesso user na base
de usuários local (será necessário o arquivo de senhas criptografado do samba para
que a autenticação local funcione, veja ‘Ativando o suporte a senhas criptografadas’
on page 334). Este nível é bastante usado quando configuramos um servidor de
perfis de usuários ou logon separado do PDC.
Log de acessos/serviços
log file= [arquivo ] Define a localização e nome do arquivo de log gerado pelo samba. As
variáveis de expansão podem ser usadas caso o administrador queira ter um mel-
hor controle dos logs gerados (veja ‘Variáveis de substituição’ on page 315). Ex.:
/var/log/samba/samba-log-%m. OBS: Se possível coloque uma extensão no ar-
quivo de log gerado pelo SAMBA (como .log). O motivo disto é porque se estes logs
forem rotacionados pelo logrotate você terá problemas de recompactação múltiplas
caso utilize um coringa samba-log-*, gerando arquivos como .gz.gz.gz.., lotando
a tabela de arquivos do diretório e deixando sua máquina em um loop de compactação.
max log size = [tamanho ] Especifica o tamanho máximo em Kb do arquivo de log gerado
Capítulo 18. SAMBA 311
este valor para yes, verifique se existem outros servidores NetBIOS em sua rede que
tem preferência para se tornar o master principal, pois poderá ocorrer um tráfego alto de
broadcasting causado pelas eleições solicitadas pelas outras máquinas.
Esta seção tem a função especial de disponibilizar o diretório home do usuário. Quando
o usuário envia seu nome de login como compartilhamento é feita uma busca no arquivo
smb.conf procurando por um nome de compartilhamento que confira. Caso nenhum seja
encontrado, é feita uma busca por um nome de usuário correspondente no arquivo /etc
/passwd, se um nome conferir e a senha enviada também, o diretório de usuário é disponi-
bilizado como um compartilhamento com o mesmo nome do usuário local. O diretório home
do usuário poderá ser modificado com o uso de mapeamento de nomes, veja ‘Mapeamento de
nomes de usuários’ on page 354. Quando o caminho do compartilhamento não for especifi-
cado, o SAMBA utilizará o diretório home do usuário (no /etc/passwd).
Para maior segurança da instalação, principalmente porque o diretório home do usuário não
é um requerimento para a autenticação de usuário, recomendo usar a variável de substituição
%S apontando para um diretório com as permissões apropriadas configuradas em seu sistema,
por exemplo:
[homes]
comment = Diretórios de Usuários
path=/pub/usuarios/%S
Você apenas terá o trabalho extra de criar os diretórios de usuários que farão acesso ao sistema.
Isto não será nenhum problema após você programar um shell script simples que verifique os
nomes de contas em /etc/passwd e crie os diretórios com as permissões/grupos adequados
(isso não será abordado por este capítulo do guia, embora não seja complicado). Se deseja,
existem exemplos em ‘Exemplos de configuração do servidor SAMBA’ on page 367 sobre a
seção [homes] no arquivo de configuração.
Os parâmetros aceitos em [homes] aqui são os mesmos usados para compartilhamentos normais
(veja ‘Descrição de parâmetros usados em compartilhamento’ on page 317). Abaixo segue mais
um exemplo de seção [homes]:
[homes]
comment = Diretório home de usuários
writable = yes
Capítulo 18. SAMBA 313
public = no
invalid users = root nobody @adm
follow symlinks = no
create mode = 0640
directory mode = 0750
Esta seção tem a função de disponibilizar as impressoras existentes no sistema (lp, lp1, lp2,
etc) existentes no /etc/printcap como compartilhamento de sistemas Windows. O método
que os nomes de impressoras são pesquisados é idêntico a forma feita para a seção [homes]:
Primeiro o nome do compartilhamento é pesquisado como um nome de serviço, depois se ele
é um nome de usuário (tentando mapear o serviço disponibilizado em [homes]), depois será
verificado a seção [printers].
Ao invés de usar este recurso, se preferir você poderá compartilhar as impressoras individual-
mente. Para detalhes, veja ‘Configurando o Linux como um servidor de impressão Windows’
on page 343.
OBS:É importante lembrar que a seção [printers] DEVE ser definida como printable us-
ando o parâmetro printable = yes para funcionar. O utilitário testparm poderá ser usado para
verificar problemas no arquivo cd configuração do SAMBA (veja ‘Buscando problemas na con-
figuração’ on this page).
A saída acima indica que está tudo OK com todas as configurações que foram realizadas
no servidor. É possível especificar um outro arquivo de configuração do SAMBA usando
testparm /etc/samba/smb2.conf.
Também é permitido simular o nome NetBIOS que fará acesso a máquina usando o parâmetro
-L nome (que será substituído na variável %L).
Para selecionar qual sistema NetBIOS será o local master browse ou domain master browse, é
usado um método bastante interessante: o de eleições.
Quando uma nova máquina entra na rede NetBIOS, ela solicita quem é o Local Master Browser,
caso nenhuma responda, ela força uma eleição na rede através de uma requisição Broadcast-
ing especial. Vence a eleição quem tiver o ***maior número***, chamado de OS Level (nível
de sistema operacional). Caso duas máquinas empatem, o desempate é feito usando outros
critérios.
Se você for a única máquina de um workgroup, automaticamente você será o Local Master
Browser. De meia em meia hora uma nova eleição é feita, forçando mais tráfego broadcasting
na rede. Durante este novo processo de eleição, a lista de computadores é atualizada; as novas
máquinas são adicionadas e as desligadas saem da lista após 36 minutos. Este é o motivo
porque as máquinas Windows continuam aparecendo no ambiente de rede por algum tempo
mesmo depois que desligadas ou porque elas não aparecem de imediato.
O OS Level é um número que é característico de cada sistema operacional ficando entre 0 (mais
baixo) e 255. Os níveis de acessos dos sistemas operacionais são os seguintes:
SAMBA 32
O valor padrão do OS Level do SAMBA é 32, entretanto ele é bastante flexível para permitir
sua mudança através do parâmetro ”os level“ (veja ‘Navegação no servidor/tipo de servidor’
on page 311), isto garante que o SAMBA sempre vença as eleições da rede sobre qualquer outro
sistema operacional.
No caso de um servidor que estiver configurado para ser o navegador de rede, assim que for
iniciado ele solicitará uma eleição de rede. As regras são as mesmas, vence o que tiver o *maior*
número. Este número pode ser configurado facilmente no SAMBA para que ele sempre vença
as eleições de rede, tomando conta da lista de máquinas. Isto é especialmente interessante por
causa da estabilidade do servidor Linux, quando migramos de servidor NT ou para fornecer
mais serviços de navegação, como servidor WINS.
OBS: Nunca deixe um servidor NT configurado para ser o Local Browser ou Domain Master
Browser competir com o SAMBA. Mesmo que o SAMBA ganhe, o NT é um péssimo perdedor
e convoca uma nova eleição para tentar novamente se eleger, gerando um *extremo* tráfego
broadcasting em redes grandes.
Esta seção foi baseada nos dados da página de manual do samba, com adições que não estavam
presentes na versão original e exemplos. Existem variáveis especiais que podem ser usadas no
arquivo de configuração do samba e são substituídas por parâmetros especiais no momento
da conexão do usuário. Um exemplo de utilização de variáveis de substituição seria mudar a
localização do diretório home do usuário:
[homes]
comment = Diretório home do usuário
path = /home/usuarios/%u
%u O nome de usuário do serviço atual, se aplicável. Esta variável é bastante útil para pro-
gramação de scripts e também para criar arquivos de log personalizados, etc.
Capítulo 18. SAMBA 316
%U O nome de usuário da seção (o nome de usuário solicitado pelo cliente, não é uma regra
que ele será sempre o mesmo que ele recebeu).
%v A versão do Samba.
%m O nome NetBIOS da máquina do cliente. Isto é muito útil para log de conexões personal-
izados e outras coisas úteis.
%L O nome NetBIOS do servidor. Como o servidor pode usar mais de um nome no samba
(aliases), você poderá saber com qual nome o seu servidor está sendo acessado e pos-
sivelmente torna-lo o nome primário de sua máquina.
%N O nome do seu servidor de diretórios home NIS. Este parâmetro é obtido de uma
entrada no seu arquivo auto.map. Se não tiver compilado o SAMBA com a opção
--with-automount então este valor será o mesmo de %L.
%R O nível de protocolo selecionado após a negociação. O valor retornado pode ser CORE,
COREPLUS, LANMAN1, LANMAN2 ou NT1.
em serviços do SAMBA, mas nada impede que também sejam colocado na seção [global] do
arquivo de configuração, principalmente quando isto é válido para diversos serviços compar-
tilhados (veja ‘Seção [global]’ on page 307).
Abaixo o guia traz algumas das opções que podem ser usadas para controlar o comportamento
do compartilhamento de arquivos por serviços no servidor SAMBA:
path Indica o diretório que será compartilhado. Lembre-se que o usuário terá as permissões
de acesso que ele teria caso estivesse logado no sistema como um usuário UNIX normal,
exceto se estiver fazendo mapeamento para outros nomes de usuários (veja ‘Mapeamento
de nomes de usuários’ on page 354). Ex: path=/pub - Compartilha o diretório local
/pub. OBS: Quando não é definido um path, o diretório /tmp é usado como padrão.
comment Descrição do compartilhamento que será mostrada na janela de procura de rede
ou no smbclient -L maquina. Ex: comment=Pasta de conteúdo público do
sistema.
browseable Define se o compartilhamento será ou não exibido na janela de procura de rede.
Mesmo não sendo exibido, o compartilhamento poderá ser acessado. Veja ‘Criando
um compartilhamento invisível’ on page 351 para uma explicação mais detalhada. Ex:
browseable=yes - Lista o compartilhamento na janela de pesquisa de servidores.
guest account Conta que será usada para fazer acesso sem senha (convidado) quando o
parâmetro guest ok ou public forem usados em um compartilhamento. Por padrão
ela é mapeada para o usuário nobody. É importante especificar uma nome de usuário
guest (convidado), principalmente porque seu UID será usado para fazer várias oper-
ações no SAMBA, como exibir os recursos disponíveis na máquina para a rede. Por mo-
tivos claros, é recomendável que este usuário não tenha acesso login ao sistema. Caso
não tenha a intenção de ocultar o SAMBA na lista de máquinas da rede (fazendo apenas
acesso direto aos recursos), especifique um valor para esta opção. Ex: guest account
= sambausr - Mapeia os usuário se conectando sem senha para o usuário sambausr,
desde que o acesso guest seja permitido pela opção public.
public Permitem aos usuários usuários se conectarem ao compartilhamento sem fornecer uma
senha usando o usuário guest. O UID que o usuário guest será mapeado é especificado
pelo parâmetro guest account). Veja ‘Criando um compartilhamento para acesso sem
senha’ on page 347. O parâmetro guest ok é equivalente a public. Ex: public = no
- Não permite
guest only Permite somente conexões guest ao recurso. O UID do usuário é mapeado para
guest, mesmo que forneça uma senha correta. O valor padrão é no. Ex: guest only =
no.
write list Lista de usuários separados por espaço ou vírgula que poderão ler e gravar no com-
partilhamento. Caso o nome for iniciado por ”@“, o nome especificado será tratado
como um grupo UNIX (/etc/group) e todos os usuários daquele grupo terão acesso
de gravação. O uso deste parâmetro ignora o read only = yes. Veja ‘Excessão de
acesso na permissão padrão de compartilhamento’ on page 350 para mais detalhes.
Ex: write list = gleydson, @usuarios - Permite acesso gravação somente do
usuário gleydson e todos os usuários pertencentes ao grupo @usuarios. OBS: - O
Capítulo 18. SAMBA 318
significado de ”@“ nos parâmetros ”invalid users“/”valid users“ é diferente das opções
write list e read list.
read list Lista de usuários separados por espaço ou vírgula que poderão apenas ler o compar-
tilhamento. O caracter ”@“ pode ser especificado para fazer referência a grupos, como
no write list. O uso deste parâmetro ignora o read only = no. Veja ‘Excessão
de acesso na permissão padrão de compartilhamento’ on page 350 para mais detalhes.
Ex: read list = nobody, system, operador, @usuarios - Permite acesso de
leitura somente do usuário nobody, system, operador e todos os usuários perten-
centes ao grupo @usuarios.
user Especifica um ou mais nomes de usuários ou grupos (caso o nome seja seguido de ”@“)
para checagem de senha. Quando o cliente somente fornece uma senha (especialmente
na rede Lan Manager, Windows for Workgroups e primeira versão do Windows
95) ela será validada no banco de dados de senhas usando o usuário especificado nesta
opção. Ex: user = john @usuariosrede
only user Especifica se somente serão permitidas conexões vindas de usuários da diretiva
user. O padrão é no. Caso deseje restringir o acesso a determinados usuários, o certo
é faze-lo usando valid users e invalid users (veja ‘Restringindo o acesso por
usuários’ on page 346). O uso de only user é apropriado quando é necessário um
controle específico de acesso sobre a diretiva user. Ex: only user = no.
locking Permite ao SAMBA fazer um lock real de arquivo ou apenas simular. Caso seja es-
pecificado como ”0“, o arquivo não é bloqueado para acesso exclusivo no servidor mas
uma resposta positiva de lock é retornada ao cliente. Se definido como ”1“, um lock real
é feito. O padrão é yes. Ex: locking = yes
available Faz o SAMBA ignorar o compartilhamento (como se tivesse retirado do servidor).
O valor padrão é ”no“.
follow symlinks Permite o uso de links simbólicos no compartilhamento (veja também a
opção wide links). A desativação desta opção diminui um pouco a performance
de acesso aos arquivos. Como é restrita a compartilhamento, o impacto de segurança
depende dos dados sendo compartilhados. O valor padrão desta opção é ”YES“. Ex:
follow symlinks = yes
wide links Permite apontar para links simbólicos para fora do compartilhamento exportada
pelo SAMBA. O valor padrão esta opção é ”YES“. Ex: wide links = yes. OBS: - A
desativação desta opção causa um aumento na performance do servidor SAMBA, evi-
tando a chamada de funções do sistema para resolver os links. Entretanto, diminui a
segurança do seu servidor, pois facilita a ocorrência de ataques usando links simbóli-
cos. Lembre-se mais uma vez que a segurança do seu sistema começa pela política e
uma instalação bem configurada, isso já implica desde a escolha de sua distribuição até
o conhecimento de permissões e planejamento na implantação do servidor de arquivos.
dont descend Não mostra o conteúdo de diretórios especificados. Ex: dont descend
= /root, /proc, /win/windows, ”/win/Arquivos de Programas“,
”/win/program files“.
printable Especifica se o compartilhamento é uma impressora (yes) ou um compartilhamento
de arquivo/diretório (no). O padrão é ”no“.
read only Especifica se o compartilhamento é somente para leitura (yes) ou não (no) para to-
dos os usuários. O parâmetro writable é um antônimo equivalente a este parâmetro,
só que utiliza as opções invertidas. Por segurança, o valor padrão é somente leitura. Veja
Capítulo 18. SAMBA 319
A configuração grupo de trabalho é o método mais simples para compartilhar recursos em uma
rede e também é indicado quando se possui uma rede pequena (até 30 máquinas) pois o geren-
ciamento não é tão complicado. Acima deste número, é recomendada a utilização da configu-
ração de domínio para definição de políticas de acesso mais precisas pelo administrador e para
manter o controle sobre os recursos da rede (veja ‘Configurando um servidor PDC no SAMBA’
on page 327).
A configuração do nível de acesso por grupo de trabalho tem como características principais
essa simplicidade na configuração e o controle de acesso aos recursos sendo feito pela máquina
Capítulo 18. SAMBA 320
[global]
netbios name = servidor
workgroup = focalinux
security = user
obey pam restrictions = yes
encrypt passwords = no
os level = 30
guest account = nobody
server string = servidor da rede
local master = true
domain master = false
[homes]
comment = Diretórios de usuários
create mask= 0700
directory mask = 0700
browseable = no
[tmp]
path = /tmp
comment = Diretório temporário do sistema
read only = yes
valid users = gleydson
public = no
Digite a senha de usuário quando solicitado. O comando deverá listar os recuros da máquina,
indicando que a configuração está funcionando corretamente. Se você é paranóico e está
preocupado com a segurança da máquina, recomendo ler a ‘Controle de acesso ao servidor
SAMBA’ on page 343.
O Samba pode utiliza os seguintes métodos para resolução de nomes de máquinas na rede
(‘Nome de máquina (nome NetBios)’ on page 303). Eles estão listados em ordem de prioridade
do mais para o menos recomendável:
• lmhosts - Pesquisa primeiro o arquivo /etc/samba/lmhosts (veja ‘Arquivo /etc
/samba/lmhosts’ on the current page para detalhes sobre este arquivo).
• host - Faz a pesquisa no arquivo /etc/hosts e no DNS em busca do nome da máquina.
• wins - Pesquisa no servidor WINS especificado pelo parâmetro wins server do smb.conf
(veja ‘WINS’ on page 323).
• bcast - Envia um pacote para o endereço de broadcast de sua configuração de rede. Este
geralmente deve ser o último método por gerar tráfego excessivo em uma rede com um
considerável número de computadores.
A ordem que a resolução de nomes é feita pelo samba, pode ser modificada usando o
parâmetro ”name resolve order = [ordem]“ no arquivo de configuração do samba (ex. name
resolve order = lmhosts host wins bcast).
Este arquivo é um banco de dados que mapeia o endereço IP com o nome NetBIOS de uma
máquina, semelhante ao formato do /etc/hosts. Este arquivo é útil quando temos servi-
dores que são acessados com freqüência, quando servidores de rede estão em segmentos sep-
arados e não temos um servidor WINS entre os dois pontos para resolução de nomes, para
definir máquinas WINS que serão acessados pela internet, etc. Para ter certeza da localiza-
ção do arquivo lmhosts em sua máquina, digite smbclient -d 3 -L localhost e veja
o diretório de pesquisa deste arquivo. Veja um exemplo de arquivo lmhosts em ‘Exemplo de
lmhosts do UNIX’ on the next page.
O uso do arquivo lmhosts evita o excesso de broadcasting na rede, pois a ordem padrão
usada para a resolução de nomes do samba, procura primeiro resolver o nome procurando em
arquivos lmhosts, depois usando dns, wins e broadcast. Dependendo do projeto de sua rede e
como as máquinas resolvem os nomes, ele pode ser uma camada a mais de segurança contra
um simples hijacking de servidor através de NetBEUI ou WINS (isso é evitado com o uso de
domínios, veja ‘Configurando um servidor PDC no SAMBA’ on page 327).
OBS: Note que em clientes Windows que estejam em outra subrede, é necessário o arquivo
\windows\lmhosts apontando para um servidor PDC mesmo que ele esteja apontando para
o servidor WINS, caso contrário, a máquina não efetuará o logon.
Capítulo 18. SAMBA 322
O exemplo abaixo mapeia o endereço IP das máquinas (primeira coluna) com o respectivo
nome de máquina (segunda coluna):
172.16.0.34 servarq
172.16.0.30 serverdom
192.168.5.2 servwins
172.16.0.3 servpdc
172.16.0.1 gateway
O arquivo possui uma sintaxe idêntica a do lmhosts do UNIX, mas alguns parâmetros es-
peciais são especificados para ajudar o Windows resolver algumas coisas que não consegue
fazer sozinho (principalmente com relação a identificação de função de máquinas em redes
segmentadas):
192.168.0.5 servarq
192.168.0.1 serverpdc #PRE #DOM:dominio
192.168.0.2 "serverwins \0x1e" #PRE
#INCLUDE \\serverpdc\lmhosts
código hexadecimal que identifica o serviço de rede (veja ‘nmblookup’ on page 360 para ver a
lista de serviços e sua respectiva função).
OBS: Caso crie este arquivo em um editor de textos do Linux, não se esqueça de converter o
arquivo para que contenha o CR+LF no final das linhas.
18.5.2 WINS
Este é um serviço de resolução de nomes que funciona de forma semelhante ao DNS, só que
voltado para o NetBIOS. Quando uma máquina cliente NetBIOS entra na rede, o servidor
WINS pega seu nome e IP e inclui em uma tabela para futura consulta pelos clientes da rede.
Esta tabela consultada toda vez que um cliente NetBIOS solicita um nome de máquina, com-
ponentes do grupo de trabalho ou domínio na rede. Uma outra aplicação importante de um
servidor WINS é permitir a resolução de nomes em pontos de redes que requerem roteamento,
a simplicidade de um protocolo não roteável como o NetBIOS fica limitada a simplicidade
das instalações de rede. Um servidor WINS pode ser instalado em cada ponta da rede e eles
trocarem dados entre si e atualizar suas tabelas de nomes/grupos de trabalhos/IPs.
A resolução de nomes de máquinas será feita consultando diretamente a máquina WINS ao
invés de broadcasting (que geram um tráfego alto na rede).
Para ativar o servidor WINS no samba, inclua as seguinte linha na seção [global] do seu
arquivo /etc/samba/smb.conf:
[global]
wins support = yes
wins proxy = no
dns proxy = no
max wins ttl = 518400
O parâmetro wins proxy pode ser necessário para alguns clientes antigos que tenham prob-
lemas no envio de suas requisições WINS. O dns proxy permite que o servidor WINS faça a
pesquisa no DNS para localização de nomes de máquinas caso não exista no cache. Ambas as
opções wins support, wins proxy e dns proxy tem como valor padrão não. Pronto, seu
servidor samba agora suporta WINS. Fácil, prático e rápido :-)
Se estiver configurando uma subrede com masquerade para acesso a um PDC ou um servidor
WINS, você terá que mexer no gateway central para apontar uma rota para o gateway mas-
querade. O motivo disto é porque o masquerade do Linux atua somente nos cabeçalhos, mas o
IP da estação é enviada e processada pelo PDC para retornar uma resposta. Da mesma forma,
este IP é registrado no servidor WINS para uso das estações de trabalho. Isto só vai ser re-
solvido quando for escrito um módulo de conntrack para conexões SAMBA (até o lançamento
do kernel 2.4.22, isso ainda não ocorreu).
Capítulo 18. SAMBA 324
Para os clientes da rede (Linux, Windows, OS/2, etc.) fazer uso das vantagens da res-
olução de nomes usando o WINS, é necessário configurar para que eles o utilizem para resolver
os nomes de máquinas. Isto é feito da seguinte forma em cada um dos sistemas operacionais:
Linux Adicione a linha wins server = ip_do_servidor_WINS na seção global do ar-
quivo /etc/samba/smb.conf:
[global]
wins server = 192.168.1.1
Após isto, reinicie o servidor samba. Caso esteja executando o servidor via inetd, digite:
killall -HUP nmbd. Se estiver rodando através de daemons: /etc/init.d/samba
restart. Não é necessário reiniciar o computador!
Windows 9x Clique com o botão direito sobre o ícone Ambiente de Rede e selecione pro-
priedades. Na janela de configuração de rede clique na aba Configuração. Na lista que
aparece selecione o protocolo TCP/IP equivalente a sua placa de rede local e clique em
Propriedades. Na tela de Propriedades TCP/IP clique em Configurações WINS e marque a
opção Ativar resolução WINS. Digite o endereço do servidor WINS e clique em Adicionar.
OBS: Se utilizar um servidor DHCP em sua rede local e o endereço do servidor WINS
também é oferecido através dele, você poderá marcar a opção Usar DHCP para resolução
WINS. Note que esta opção somente estará disponível se escolher a opção Obter um en-
dereço IP automaticamente na tab Endereços IP. Clique em OK até fechar todas as telas e
reinicie quando o computador perguntar :-)
O samba pode atuar como um servidor de data/hora ajustando o horário de suas estações de
trabalho com o servidor da rede.
As estações clientes poderão executar o comando net para sincronizar seu relógio durante a
inicialização do Windows, ou durante o logon da rede através do script de logon, caso tenha
configurado o servidor samba para logon em domínios NT.
Para configurar o samba para atuar como servidor de data/hora de sua rede, adicione o
seguinte parâmetro na seção global do arquivo de configuração /etc/samba/smb.conf:
[global]
time server = yes
Capítulo 18. SAMBA 325
Para sincronizar a data/hora das estações de trabalho usando o servidor samba, veja ‘Sin-
cronizando a data/hora no Cliente’ on this page. Caso o seu servidor SAMBA também seja o
servidor de autenticação PDC da rede, a melhor forma de se fazer isto é colocar o comando
net time \\servidor_SAMBA /set /yes em um script que será executado pela estação.
OBS É recomendável instalar um cliente ntp para manter o relógio do servidor sempre atual-
izado, conseqüentemente mantendo a data/hora das estações também em sincronismo . .
Um local interessante para colocação deste comando é na pasta Iniciar da estação Windows,
pois todos os comandos que estejam nesta pasta são executados quando o sistema é iniciado.
Exemplos:
• net time \\linux /set /yes - Sincroniza a hora com o servidor ”\\linux“ e não
pede confirmação (/yes).
• net time \\linux /WORKGROUP:pinguim /set /yes - Sincroniza a hora com o
servidor ”\\linux“ do grupo de trabalho pinguim (/WORKGROUP:pinguim) e não
pede confirmação (/yes).
Esta seção descreve todos os passos necessários para configurar um servidor de domínio PDC
(Primary Domain Control) com perfis móveis e outros recursos que tornam úteis e seguras a
administração de uma rede NetBEUI.
Um domínio de rede consiste em uma máquina central chamada de PDC, que mantém o cont-
role de todas as contas de usuários/grupos e permissões para acesso a rede NetBEUI. O acesso
desta forma é centralizado, como vantagem disto você pode usar o nível de acesso por usuários
nas máquinas, definindo quais usuários ou grupos terão acesso de leitura/gravação.
É permitido criar scripts de logon, assim comandos programados pelo administrador serão
executados nas máquinas clientes durante o logon no domínio (veja ‘Criando Scripts de logon’
on page 330).
O nome da máquina é protegido contra hijacking através de contas de máquinas que fazem
parte do domínio (veja ‘Contas de máquinas de domínio’ on page 328). Isto só é possível em
clientes Linux, Windows NT, Windows 2000 e Windows XP.
Capítulo 18. SAMBA 326
Você poderá usar perfis móveis, copiando todas as personalizações do seu desktop para qual-
quer máquina na rede que você faça o logon. Para o administrador, ele poderá definir políti-
cas com o Poledit e outros programas que serão salvas junto com o perfil do usuário, val-
endo para qualquer máquina que ele se autentique na rede (veja ‘Criando Scripts de logon’ on
page 330).
Se você deseja iniciar logo a configuração do seu domínio, siga até ‘Configurando um servidor
PDC no SAMBA’ on the facing page.
É a máquina que ganhou a eleição no segmento local de rede (veja ‘Níveis de sistema para
eleição de rede’ on page 314). Logo que é declarada o local master browser, ela começa a rece-
ber via broadcasting a lista de recursos compartilhados por cada máquina para montar a lista
principal que será retornada para outras máquinas do grupo de trabalho ou outras subredes
que solicite os recursos compartilhados por aquele grupo.
Uma nova eleição é feita a cada 36 minutos ou quando a máquina escolhida é desligada.
Quando o local master browse é eleito no segmento de rede, uma consulta é feita ao servidor
WINS para saber quem é o Domain Master Browse da rede para enviar a lista de compartil-
hamentos. A máquina escolhida como Local Master Browse envia pacotes para a porta UDP
138 do Domain Master e este responde pedindo a lista de todos os nomes de máquinas que o
local master conhece, e também o registra como local master para aquele segmento de rede.
Caso tenha configurado sua máquina para ser o domain master browser da rede (também
chamado de controlador principal de domínio ou PDC), ela tentará se tornar a máquina que terá
a lista completa de recursos enviados pelos locais master browsers de cada segmento de rede.
Um PDC também é o local master browse de seu próprio segmento de rede.
É possível ter mais de um domain master browse, desde que cada um controle seu próprio
domínio, mas não é possível ter 2 domain master browsers em um mesmo domínio. Caso
utilize um servidor WINS em sua rede, o PDC fará consultas constantes em sua base de dados
para obter a lista de domínios registrados. O domínio é identificado pelo caracter 1b na rede
(veja ‘nmblookup’ on page 360).
OBS: O Windows NT configurado como PDC sempre tenta se tornar o domain master browser
em seu grupo de trabalho. Não sendo possível retirar o Windows NT configurado como PDC
do domínio (por alguma outra razão), a única forma será deixar ele ser o domain master
browser. Se este for o caso, você poderá continuar lendo este documento para aprender mais
sobre NetBIOS e talvez ainda mudar de idéia sobre manter o NT na rede após ver as caracterís-
ticas do SAMBA ;-)
Capítulo 18. SAMBA 327
Esta é a parte interessante do guia, a prática. Para os administradores que conhecem através
da experiência própria os problemas e definições do SAMBA, grande parte do guia foi apenas
uma revisão (por favor, se faltou algo que acha interessante, me notifiquem que incluirei na
próxima versão e colocarei uma nota no lançamento e na página com os devidos créditos :-))
Para configurar uma máquina para ser o PDC (Controladora Principal de Domínio ou Primary
Domain Control), siga esta seqüência:
• Habilite o suporte a senhas criptografadas. Caso ainda não tenha feito isso, leia a seção
‘Ativando o suporte a senhas criptografadas’ on page 334.
• Na seção [global], insira/modifique os seguintes parâmetros:
; Identificação da máquina e domínio
netbios name = gleydson
workgroup = focalinux
; senhas criptografadas
encrypt passwords = yes
smb passwd file = /etc/samba/smbpasswd.db
Onde os parâmetros significam:
– netbios name = gleydson - Nome do computador. Este também será o nome
usado pelas outras máquinas clientes quando for configurar o PDC (controlador de
domínio).
– workgroup = focalinux - Nome do domínio que está criando. Todas as
máquinas que pertencerem a este domínio, terão o nível de acesso definido pelo
PDC. Note que o parâmetro workgroup também é usado ao especificar o nome do
grupo de trabalho quando se é usado a configuração grupo de trabalho (‘Configuração
em Grupo de Trabalho’ on page 319).
– security = user - Requerido para controle de acesso por domínio, já que é uti-
lizado o controle de acesso local usando usuários e grupos locais.
– domain master = yes - Especifica se está máquina está sendo configurada para
ser o PDC da rede. OBS: Por favor, certifique-se que não existe outro PDC
no domínio. Veja ‘Domain Master Browser’ on the preceding page. prefered
master = yes - Força uma eleição com algumas vantagens para seu servidor ser
eleito sempre como o controlador de domínio. Isto garante que a máquina SAMBA
sempre seja o PDC. Veja ‘Navegação no servidor/tipo de servidor’ on page 311.
local master = yes - Define se a máquina será o controlador principal do
grupo de trabalho local que ela pertence.
Pronto, agora teste se existem erros em sua configuração executando o comando testparm
(‘Buscando problemas na configuração’ on page 313) e corrija-os se existir. Resta agora reiniciar
Capítulo 18. SAMBA 328
o servidor nmbd para que todas as suas alterações tenham efeito. Para adicionar seus clientes a
um domínio, veja ‘Contas de máquinas de domínio’ on this page e ‘Configurando clientes em
Domínio’ on page 361.
Uma conta de máquina de domínio garante que nenhum outro computador possa utilizar o
mesmo nome de uma máquina confiável e assim utilizar os compartilhamentos que ela tem
permissão. Os clientes Windows NT, Windows XP e Windows 2000 precisam de uma conta
de máquina para ter acesso ao domínio e seus recursos. A criação de uma conta de máquina é
bastante semelhante a criação da conta de um usuário normal no domínio.
Existe uma coisa que precisa sempre ter em mente quando estiver configurando uma conta de
máquina de domínio: Quando você cria uma conta para a máquina, ela entra e altera sua senha
no próximo logon usando um ”segredo“ entre ela e o PDC, este segredo a identifica sempre
como dona daquele nome NetBIOS, ou seja, até o primeiro logon no NT, outra máquina com
o mesmo nome NetBIOS poderá ser a dona do netbios naquele domínio caso faça o logon no
domínio. A única forma de se evitar isto é logar imediatamente no domínio NT assim que criar
as contas de máquinas.
Existem duas formas para criação de contas de máquinas: manual e automática.
Para criar uma conta de domínio para a máquina master, siga estes 2 passos:
1 Crie uma conta de máquina no arquivo /etc/passwd:
useradd -g domainmac -c "Maquina de Dominio" -s /bin/false -d /dev/null
O comando acima cria uma conta para a máquina master$ e torna ela parte do grupo
domainmac. É necessário especificar o caracter $ após o nome da máquina para criar
uma conta de máquina no domínio, caso contrário o próximo passo irá falhar. Acredito
que nas próximas versões do SAMBA seja desnecessário o uso do arquivo /etc/passwd
para a criação de contas de máquina.
2 Crie uma conta de máquina no arquivo /etc/samba/smbpasswd:
smbpasswd -m -a master
Isto cria uma conta de máquina para o computador master no arquivo /etc/samba
/smbpasswd. Note que a criação de uma conta de máquina é muito semelhante a cri-
ação de um usuário apenas precisa adicionar a opção -m. Quando for criar uma conta
com o smbpasswd Não é necessário especificar $ no final do nome da máquina. O mais
importante: Entre IMEDIATAMENTE no domínio após criar a conta de máquina us-
ando a conta de administrador de domínio criada no SAMBA (veja ‘Criando uma conta
de administrador de domínio’ on the facing page)! como a máquina ainda não se auten-
ticou pela primeira vez, qualquer máquina que tenha o mesmo nome e entre no domínio,
poderá alocar o nome recém criado. A única forma de resolver este problema, é apagando
a conta de máquina e criando-a novamente no domínio. Siga os passos de acordo com
o sistema operacional em ‘Configurando clientes em Domínio’ on page 361 para colocar
seus clientes em domínio.
Capítulo 18. SAMBA 329
Através deste método, as máquinas clientes terão sua conta criada automaticamente assim que
seja feita a entrada no domínio usando a conta do administrador de domínio no SAMBA. Este
é o método recomendável de colocação de máquinas no domínio por ser mais prática ao invés
do método manual. Note que normalmente isto funciona para o WinXP e Win2000 mas não
funciona em redes com o NT4, devendo ser criadas contas de máquinas usando o método
manual.
Para fazer a configuração automática, coloque a seguinte linha no arquivo smb.conf na seção
[global]:
Assim, a conta de máquina será automaticamente criada quando o administrador fizer sua con-
figuração no domínio (veja ‘Criando uma conta de administrador de domínio’ on this page).
No SAMBA 3.0, a opção add machine script deverá ser usada no lugar de add user
script para adicionar uma máquina no domínio.
A conta de administrador do domínio é a conta que tem permissões para realizar operações
de manutenção e administração de máquinas que compõem o domínio de rede. Com ela é
possível, entre outras coisas, adicionar e remover máquina que compõem o domínio. Para es-
pecificar que contas de usuários do arquivo /etc/samba/smbpasswd que terão poderes ad-
ministrativos, utilize a opção domain admin group ou admin users na seção [global]
do arquivo /etc/samba/smb.conf.
O parâmetro admin users permite que todas as operações realizadas pelo usuário sejam
feitas com poderes de usuário root. Isto é necessário porque o arquivo smbpasswd (usado
para ajustar as contas de máquinas) normalmente tem permissões de leitura/gravação so-
mente para root. O domain admin group permite que usuários específicos ou usuários do grupo
especificado sejam parte do grupo de administradores do domínio para adicionar máquinas,
etc. Por exemplo, para tornar o usuário gleydson com privilégios para adicionar/remover
máquinas no domínio:
Capítulo 18. SAMBA 330
[global]
...
admin users = gleydson
ou
domain admin group = @admins gleydson
Uma dos recursos mais úteis em um domínio é a possibilidade de se executar comandos nas
máquinas cliente quando fazem o logon no domínio. Desta forma, é possível instalar pro-
gramas, executar anti-vírus, mapear compartilhamentos automaticamente no clientes, etc. A
programação de scripts de logon é feita usando a linguagem em lote do DOS, com possibili-
dades de usar variáveis de ambiente, cópia de arquivos entre servidores, etc. O guia não irá
abordar a programação em linguagem de lote, mas isto é simples de se encontrar na internet e
mesmo a documentação que acompanha o próprio Windows é útil.
Para habilitar o recurso de scripts de logon na máquina, adicione os seguintes parâmetros no
arquivo smb.conf:
[global]
domain logons = yes
logon script = logon.cmd
[netlogon]
path = /pub/samba/netlogon
read only = yes
write list = ntadmin
Segue a descrição de cada parâmetro com detalhes importantes para a configuração e fun-
cionamento do recurso de logon:
Capítulo 18. SAMBA 331
• domain logons - Deve ser definido para yes para ativar o recurso de logon scripts do
SAMBA.
• logon drive é a unidade de disco que terá o homedir do usuário mapeado. Isto so-
mente é usado por máquinas NT/2000/XP.
• logon script - Define qual é o script que será executado na máquina cliente quando
fizer o logon. Ele deve ser gravado no diretório especificado pela opção path do com-
partilhamento [netlogon] (/pub/samba/netlogon no exemplo). Os scripts de lo-
gon podem ser tanto em formato .bat ou .cmd. Se for programar um script universal,
é recomendável o uso do formato .bat por ser compatível tanto com Win9X e WinNT.
Um detalhe que deve ser lembrado durante a programação do script de logon é que ele DEVE
seguir o formato DOS, ou seja, ter os caracteres CR+LF como finalizador de linhas. Para utilizar
editores do UNIX para escrever este script, será necessário executar o programa flip (flip
-m -b arquivo) ou unix2dos no arquivo para converte-lo em formato compatível com o
DOS.
Segue abaixo um exemplo de script de logon que detecta quando o cliente é Windows 95/NT,
ajusta a hora com o servidor e mapeia 2 unidades de disco:
@echo off
cls
rem Logon Script desenvolvido por Gleydson Mazioli
rem da Silva como modelo para o guia Foca GNU/Linux
rem
rem Este script pode ser utilizado para fins didáticos
rem e distribuído livremente de acordo com os termos
rem da GPL
rem
echo "Aguarde enquanto sua máquina efetua"
echo "o logon na rede do domínio focalinux."
rem
if %OS%==Windows_NT goto NT-2000
rem
echo "--------------------------------"
echo "SO: %OS%"
echo "Usuário: %USERNAME%"
echo "Grupo de Trabalho: %LANGROUP%"
echo "Servidor: %DOMINIO%"
echo "--------------------------------"
echo "Recuperando compartilhamentos"
rem mapeia o compartilhamento publico definido no servidor
net use e: \\gleydson\publico
echo "Sincronizando data/hora"
rem sincroniza a data/hora com o servidor
Capítulo 18. SAMBA 332
Note no exemplo acima que não podem haver linhas em branco, você deverá utilizar a palavra
rem (comentário em arquivos em lote) em seu lugar. Note que existem diferenças entre o
comando net do Windows 9x/ME e do NT, as variáveis também possuem um significado
diferente entre estes 2 sistemas, isto explica a necessidade de se incluir um bloco separado
detectando a existência de qual sistema está sendo efetuado o logon.
A lista completa de variáveis disponíveis para cada sistema operacional pode ser obtida
colocando-se set >c:\vars.txt que gravará uma lista de variáveis disponíveis durante
o logon no arquivo c:\vars.txt da máquina cliente.
OBS: Caso especifique um computador que contém o script de login, lembre-se de faze-lo
sempre com \ ao invés de / para não ter incompatibilidade com o Windows 95/3.11.
ATENÇÃO: Lembre-se que copiar e colar pode não funcionar para este script. Leia novamente
esta seção do guia se estiver em dúvidas.
Os profiles permitem que os clientes utilizem o mesmo perfil em qualquer máquina que ele
se autentique na rede. Isto é feito após a autenticação copiando os arquivos que contém os
dados de personalização de usuários (user.dat, NTuser.dat) para a máquina local. Este
processo também inclui a cópia de papéis de parede, links da área de trabalho, cache do IE,
etc. Para configurar o recurso de perfis móveis no domínio, é necessário adicionar os seguintes
parâmetros no seu arquivo smb.conf:
[global]
Capítulo 18. SAMBA 333
security = user
encrypt passwords = yes
domain logons = yes
logon drive = H:
logon path = \\%N\profilesNT\%u
logon home = \\%N\profiles\%u
preserve case = yes
short preserve case = yes
case sensitive = no
[profiles]
path = /pub/profiles
read only = no
create mask = 0600
directory mask = 0700
[profilesNT]
path = /pub/profilesNT
read only = no
create mask = 0600
directory mask = 0700
Um usuário do Windows NT (ou versões baseadas neste) pode modificar as permissões dos
arquivos/diretórios que tem acesso através da caixa de diálogo de listas de acesso do NT,
lembrando que estas permissões nunca substituirão as definidas pelo administrador local.
A opção ”nt acl support“ deverá estar definida para ”yes“ na seção [global] do arquivo de
configuração, caso contrário você não terá acesso para mudar as permissões através de caixas
de diálogo do NT. \
O uso de senhas criptografadas é um requisito quando você deseja configurar o SAMBA para
ser um servidor PDC ou um cliente de um domínio. Quando utiliza senhas criptografadas, elas
trafegam em formato seguro através da rede, dificultando a captura por outras pessoas. Em
versões mais recentes do Windows (a partir da OSR/2 e NT 4 service pack3) o suporte a senhas
criptografadas vem habilitado como padrão para login e utilização de serviços da rede. Não
é recomendável desativar o uso de senhas criptografadas, mas se mesmo assim for necessário
veja ‘Senhas criptografadas ou em texto puro?’ on page 353.
Quando usamos senhas criptografadas, elas são armazenadas no arquivo /etc/samba
/smbpasswd ao invés do /etc/passwd, isto permite que possamos controlar as permissões
de usuários separadamente das do sistema e diferenciar os logins do domínio dos logins do
sistema (usuários que possuem shell). Caso tenha um servidor que já possua muitas contas
de usuários acessando em texto plano, recomendo ler ‘Migrando de senhas texto plano para
criptografadas’ on page 336 para facilitar o processo de migração de contas.
O utilitário smbpasswd é o programa utilizado para gerenciar este arquivo de senhas e tam-
bém o status de contas de usuários/máquinas do domínio. Siga estes passos para ativar o uso
de senhas criptografadas no SAMBA:
1 Edite o arquivo /etc/samba/smb.conf e altere as seguintes linhas na seção [global]
para adicionar o suporte a senhas criptografadas:
[global]
encrypt passwords = true
smb passwd file =/etc/samba/smbpasswd
A linha encrypt passwords = true diz para usar senhas criptografadas e
que o arquivo /etc/samba/smbpasswd contém as senhas (smb passwd file
=/etc/samba/smbpasswd). Caso sua máquina seja apenas um cliente de rede (e não
Capítulo 18. SAMBA 335
um PDC), você pode pular para o passo onde o SAMBA é reiniciado (no final dessa lista),
não é necessária a criação do arquivo de senhas para autenticação pois os usuários serão
validados no servidor.
2 Execute o comando mksmbpasswd </etc/passwd >/etc/samba/smbpasswd. Ele
pega toda a base de usuários do /etc/passwd e gera um arquivo /etc/samba
/smbpasswd contendo as contas destes usuários. Por padrão, todas as contas são DE-
SATIVADAS por segurança quando este novo arquivo é criado. O novo arquivo terá o
seguinte formato:
gleydson:1020:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:XXXXXXXXXXXXXXXXXXXXXXXX
geovani:1004:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:XXXXXXXXXXXXXXXXXXXXXXXXX
Os campos são separados por ”:“ e cada campo possui o seguinte significado:
1 O primeiro é o nome de usuário
2 UID do usuário no sistema UNIX que a conta será mapeada.
3 Senha Lan Manager codificada em hex 32 criado usando criptografia DES usada
pelo Windows 95/98/ME.
4 Senha hash criada em formato do NT codificada em hex 32. Esta senha é criada
pegando a senha do usuário, convertendo-a para maiúsculas, adicionados 5 bytes
de caracteres nulos e aplicando o algoritmo md4.
5 Opções da conta criada no smbpasswd:
• U - Especifica que a conta é uma conta de usuário normal (veja ‘Adicionando
usuários no smbpasswd’ on the following page)
• D - Significa que a conta foi desativada com a opção -d (veja ‘Desabilitando uma
conta no smbpasswd’ on page 337).
• W - Especifica que a conta é uma conta de máquina criada com a opção -m (veja
‘Contas de máquinas de domínio’ on page 328).
• N - A conta não possui senha (veja ‘Definindo acesso sem senha para o usuário’
on page 338).
Os caracteres ”XXXXXXXXXXXXXXX“ no campo da senha, indica que a conta foi recém
criada, e portanto está desativada. O próximo passo é ativar a conta para ser usada pelo
SAMBA. ATENÇÃO: O método de criptografia usado neste arquivo não é totalmente
seguro. Recomendo manter o arquivo de senhas smbpasswd em um diretório com a
permissão de leitura somente pelo root.
3 Para ativar a conta do usuário gleydson, usamos o comando:
smbpasswd -U gleydson
Digite a senha do usuário e repita para confirmar. Assim que a senha for definida, a conta
do usuário é ativada. Você também pode especificar a opção ”-s“ para entrar com a senha
pela entrada padrão (muito útil em scripts). Apenas tenha cuidado para que esta senha
não seja divulgada em seus arquivos/processos.
4 Reinicie o processo do SAMBA (veja ‘Iniciando o servidor/reiniciando/recarregando a
configuração’ on page 302).
5 Verifique se o suporte a senhas criptografadas está funcionando com o comando:
smbclient -L localhost -U gleydson
Substitua localhost pelo IP do servidor e gleydson pelo usuário. Caso obtenha a
mensagem session setup failed: NT_STATUS_LOGON_FAILURE significa que
a senha informada está incorreta.
Capítulo 18. SAMBA 336
Como administrador, pode ser necessário que precise desativar temporariamente uma conta
de usuário por alguma situação qualquer (má utilização de recursos, dúvida se a conta está
sendo usada, para que ele ligue reclamando de autenticação para ter aquela desejada conversa
(hehe), etc.). Remover uma conta e novamente adiciona-la então não é uma situação muito
prática. Utilize então o seguinte comando para desativar uma conta de usuário:
smbpasswd -d usuario
Quando a conta de usuário é desativada, uma flag ”D“ é adicionada às opções do usuário
(junto com as opções ”UX“). Veja ‘Habilitando uma conta no smbpasswd’ on the current page
para reativar a conta.
Uma conta desativada com o uso do comando smbpasswd -d pode ser novamente ativada
usando:
smbpasswd -e usuario
O utilitário smbpasswd pode ser usado tanto para alterar a senha de usuários locais do SAMBA
ou de uma conta em um servidor remoto (seja SAMBA, NT, W2K). Para alterar a senha de um
usuário local, digite:
smbpasswd -U usuario
Lhe será pedida a antiga senha, a nova senha e a confirmação. Caso seja o usuário root,
somente a nova senha e a confirmação. Isto é mecanismo de proteção para usuários que esque-
cem a senha ;-)
Para alterar a senha de um usuário remoto, utilize:
Note que apenas foi adicionada a opção -r servidor comparado com a opção anterior. A
diferença é que a senha antiga do usuário sempre será solicitada para troca (pois o root das 2
máquinas pode não ser o mesmo).
Capítulo 18. SAMBA 338
smbpasswd -n usuario
Esta forma de autenticação é enviada por implementações NetBIOS antigas, como a encontrada
no Lan Manager, Windows for Workgroups e Windows 95 OSR1. As versões mais no-
vas destas implementações enviam a senha em formato criptografado, sendo necessário tam-
bém usar o formato criptografado no SAMBA para que possa se autenticar (veja ‘Ativando o
suporte a senhas criptografadas’ on page 334).
Em ‘Senhas criptografadas ou em texto puro?’ on page 353 é feita uma comparação entre
o uso de autenticação usando senhas em texto plano e senhas criptografadas. Em geral, o
administrador prefere a utilização da autenticação usando texto plano quando deseja usar o
/etc/passwd para autenticação e está usando grupos de trabalho é necessário usar senhas
criptografadas para autenticação).
Para configurar o SAMBA para utilizar senhas em texto, modifique o parâmetro encrypt
passwords para no:
[global]
encrypt passwords = no
Esta seção descreve como configurar clientes para acessar o servidor SAMBA usando autenti-
cação em texto plano. Atualmente o guia cobre os seguintes clientes:
• ‘Lan Manager’ on the next page
• ‘Windows for Workgroups’ on the facing page
• ‘Windows 95 / Windows 95A’ on the next page
• ‘Windows 95B’ on the facing page
• ‘Windows 98/98SE’ on the next page
Capítulo 18. SAMBA 339
Lan Manager
Cliente NetBIOS para DOS. Ele trabalha somente com senhas em texto plano.
Este é o padrão de autenticação do Windows for Workgroups caso não tenha feito nen-
huma alteração específica (mas desconheço algo que faça-o trabalhar com senhas crip-
tografadas).
O Windows 95 até a release ”A“, utiliza texto plano como padrão para autenticação (veja qual
a release clicando com o botão direito em Meu Computador e Propriedades.
Windows 95B
REGEDIT4
[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\VNETSUP]
"EnablePlainTextPassword"=dword:00000001
Windows 98/98SE
Windows ME
Windows NT Server/WorkStation
REGEDIT4
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Rdr\Parameters]
"EnablePlainTextPassword"=dword:00000001
Windows 2000
REGEDIT4
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkStation\Parame
"EnablePlainTextPassword"=dword:00000001
Linux
O mapeamento de usuários do servidor remoto com a máquina local é usado quando você
deseja controlar o acesso aos arquivos/diretórios a nível de usuário. No Windows isto per-
mite que cada arquivo/diretório tenha o acesso leitura/gravação somente para os usuários
definidos e autenticados no controlador de domínio. No Linux as permissões de arquivos e
diretórios podem ser definidas para o usuário do PDC, garantindo o mesmo nível de controle
de acesso.
Esta seção explica como configurar o mapeamento de UID/GID entre o servidor PDC SAMBA
e seus clientes NetBIOS Windows e Linux.
Para o Windows utilizar os usuários remotos do servidor para fazer seu controle de acesso por
nível de usuário, siga os seguintes passos:
Windows 9X Entre no Painel de Controle/Propriedades de Rede e clique na tab Controle de Acesso.
Marque a opção Controle de acesso a nível de usuário e coloque o nome da máquina PDC na
caixa de diálogo de onde os usuários/grupos serão obtidos. Você também pode colocar
o nome do grupo de trabalho, neste caso a máquina fará uma busca pelo PDC ou outra
máquina de onde pode obter os nomes de usuários/grupos. OBS: Para fazer isto, você
deverá estar autenticado no domínio.
A associação de UIDs de usuários de um domínio com usuários locais no Linux é feita pelo
programa winbind. Ele utiliza o mecanismo nsswitch para obter outras fontes de dados de
usuários e os associa nas ferramentas de gerenciamento de contas existentes no sistema. Siga
estes passos para fazer sua instalação e configuração do Winbind em um servidor Linux:
• Instale o programa winbind: apt-get install winbind.
• Modifique o arquivo smb.conf adicionando as seguintes linhas na seção [global]:
winbind separator = +
winbind cache time = 30
winbind uid = 10000-15000
winbind gid = 10000-12000
winbind enum users = yes
winbind enum groups = yes
template homedir = /home/winbind/%D/%U
template shell = /bin/false
Onde
winbind separator Separador usado para separar o nome dos grupos do nome de
domínio. Este parâmetro somente tem sentido quando usado em conjunto com um
PDC Windows ou quando os módulos pam_winbind.so e nss_winbind.so es-
tão sendo utilizados.
Capítulo 18. SAMBA 342
getent group
Caso isto não aconteça, revise suas configurações e veja os logs procurando por erros
quando o winbind tenta obter a lista de usuários/grupos do domínio.
Agora você deve ser capaz de criar diretórios/arquivos locais usando os nomes de
usuários/grupos do domínio. Lembre-se de reiniciar sempre o winbind quando reiniciar o
SAMBA por alguma modificação for feita (ao mesmo que saiba que não afeta o winbind), as-
sim como entrar novamente no domínio, caso contrário o mapeamento deixará de funcionar.
OBS: Atualmente, o winbind não oferece suporte a restrições por data/hora de logon para
estações de trabalho. Isto deverá ser implementado em uma futura versão
Este capítulo documenta como configurar o seu servidor samba para permitir o acesso a com-
partilhamento de arquivos e impressão no sistema.
Será necessário ter o pacote samba instalado e adicionar as seguintes linhas no seu arquivo
/etc/samba/smb.conf:
[hp-printer]
path = /tmp
printer name=HP DeskJet 690C
printable = yes
print command = lpr -r -h -P %p %s
valid users = winuser winuser2
create mode = 0700
Esta restrição pode ser feita pelos parâmetros allow hosts e deny hosts tanto em serviços indi-
viduais ou em todo o servidor. Os parâmetros hosts allow e hosts deny são equivalentes a estes
acima. O allow hosts permite o acesso a máquina especificadas como argumento. São permiti-
dos os seguintes métodos para permitir o acesso a uma máquina/rede:
• 192.168.1.1 - IP da máquina
• servidor - Nome da máquina
• 192.168.1.0/255.255.255.0 - IP com máscara de rede
• 192.168.1.0/24 - IP com máscara de rede octal
• 192.168.1. - Porção de rede sem o host (como no hosts.allow e hosts.deny.
• @nome - Pesquisa por máquinas no grupo NIS.
É permitido usar mais de um endereço IP separando-os por vírgulas ou espaços. A palavra
chave EXCEPT pode ser usada para fazer excessão de um ou mais endereços IPs, por exemplo:
Que permite o acesso a toda as máquinas da faixa de rede 192.168.1.0/24 exceto para a
192.168.1.20.
O deny hosts possui a mesma sintaxe do allow hosts mas bloqueia o acesso das máquinas es-
pecificadas como argumento. Quando o allow hosts e deny hosts são usados juntos, as máquinas
em allow hosts terão prioridade (processa primeiro as diretivas em allow hosts e depois em deny
hosts).
OBS: O endereço de loopback (127.0.0.1) nunca é bloqueado pelas diretivas de acesso.
Provavelmente deve ter notado porque o endereço de loopback não pode ser bloqueado e
as conseqüências disto para o SAMBA.
Se você está executando o SAMBA via inetd, os arquivos hosts.allow e hosts.deny são
verificados antes do controle e acesso allow hosts e deny hosts para controle de acesso ao smbd.
Caso estiver usando o SAMBA viainetd e deseja restringir o acesso usando TCP Wrappers, veja
‘O mecanismo de controle de acessos tcpd’ on page 56.
OBS: Lembre-se de usar o testparm para verificar a sintaxe do arquivo smb.conf sempre
que desconfiar de problemas (veja ‘Buscando problemas na configuração’ on page 313).
Capítulo 18. SAMBA 345
Um método interessante e útil para testar se a nossa configuração vai bloquear o acesso a
serviços é usando o testparm da seguinte forma:
Você precisará dizer para o testparm qual é o arquivo de configuração que está usando e
o endereço IP/nome de host que fará a simulação de acesso. Este método não falsifica o
endereço IP para testes, apenas usa os valores em allow hosts e deny hosts para checagem. Por
exemplo, para verificar o acesso vindo do IP 192.168.1.50:
Esta restrição de acesso permite que façamos o SAMBA responder requisições somente para a
interfaces indicadas. O método de segurança descrito em ‘Restringindo o acesso por IP/rede’
on the preceding page serão analisadas logo após esta checagem.
Para restringir o serviço SAMBA a interfaces, primeiro será necessário ativar o parâmetro bind
interfaces only usando 1, yes ou true (o padrão é desativado). Depois, definir que
interfaces serão servidas pelo samba com o parâmetro interfaces. Os seguintes formatos de
interfaces são permitidos:
• eth0, sl0, plip0, etc - Um nome de interface local. É permitido o uso de * para
fazer o SAMBA monitorar todas as interfaces que iniciam com aquele nome (por exem-
plo, eth*).
• 192.168.1.1, 192.168.1.2, etc - Um endereço IP de interface local.
• 192.168.1.2/24, 192.168.1.2/255.255.255.0 - Um par de endereço/máscara
de rede.
Mais de uma interface pode ser usada separando-as com vírgula ou espaços. A escolha do
uso de nome da interface ou do IP é feita de acordo com a configuração da máquina. Em
uma máquina DHCP por exemplo, é recomendado o uso do nome da interface. Quando bind
interfaces only estiver ativado, o padrão é esperar conexões em todas as interfaces que permitem
broadcast exceto a loopback.
Capítulo 18. SAMBA 346
Exemplo:
Permite que você controle quem poderá ou não acessar o compartilhamento da máquina. Este
controle é feito pelos parâmetros valid users e invalid users.
O invalid users lista de usuário que NÃO terão acesso ao compartilhamento. Se o nome for
iniciado por ”+“ o parâmetro será tratado como um nome de grupo UNIX (/etc/group). O
caracter ”&“ faz ele pesquisar o nome de grupo no banco de dados NIS. O caracter ”@“ permite
fazer a busca do grupo primeiro no banco de dados NIS e caso ele não seja encontrado, no
arquivo de grupos do sistema (/etc/group).
É possível usar a combinação de caracteres ”+&“ e ”&+“ para alternar a ordem de busca enter
o /etc/group e o NIS.
Exemplos:
invalid users = junior, marcio, +badusers Não permite que os usuários especificados e os
usuários do grupo +badusers tenham acesso ao compartilhamento.
invalid users = &;semacesso Bloqueia o acesso de todos os usuários NIS que pertençam ao
grupo semacesso.
invalid users = bruno, henrique, +@users, Bloqueia o acesso dos usuários bruno, henrique
e de todos os usuários que pertençam ao grupo users. A pesquisa de grupo é feita
primeiro no /etc/group e em seguida no NIS.
invalid users = @semacesso Bloqueia o acesso dos usuários que pertencem ao grupo
”semacesso“. A pesquisa é feita primeiro no NIS e depois no /etc/group (equivalente
ao uso de ”&+“).
O valid users possui a mesma sintaxe de funcionamento do invalid users, mas permite
somente o acesso para os usuários/grupos listados. Caso a opção valid users não seja
especificada ou a lista esteja vazia, o acesso é permitido. Se um mesmo nome de usuário
estiver na lista valid users e invalid users, o padrão é ser mais restritivo, negando o
acesso.
A segurança deste método de acesso depende muito da forma de autenticação dos nomes antes
de passar o controle para o SAMBA, pois uma autenticação fraca põe em risco a segurança da
sua máquina.
Capítulo 18. SAMBA 347
Este parâmetro permite que máquinas tenham acesso sem senha a um servidor. Isto pode se
tornar um *ENORME* buraco na segurança do seu sistema, pois mesmo usando uma senha
inválida, a máquina poderá ter acesso a todos os recursos do compartilhamento e não é com-
plicado fazer um ataque usando DNS spoofing.
Se realmente deseja fazer isto, tenha em mente os dados que poderão ser acessados daquela
máquina, se realmente não existe nenhuma outra forma de disponibilizar o acesso de forma
que mantenha o controle de restrições (usando todos os outros métodos), restrinja o acesso
usando MAC Address com o iptables ou o arp (veja ‘Restrições por MAC Address/IP’ on
page 388). O padrão é não usar nenhum arquivo hosts.equiv.
O parâmetro null passwords é usado na seção [global] permitindo que contas de usuários
sem senha tenham acesso permitido ao servidor. ISTO É TOTALMENTE INSEGURO e deve
ser sempre evitado. Caso você tenha feito uma bela restrição em sua máquina e deseja que o
seu shell script de cópia de arquivos funcione usando este método, você está jogando toda a
segurança do seu sistema por ralo abaixo.
Não existe motivo para usar senhas em branco em um controle de acesso por usuário, a não
ser que precise testar algo realmente temporário e que depurando algo no SAMBA.
[global]
guest account = nobody
Capítulo 18. SAMBA 348
..
..
[download]
path = /downloads
comment = Espaço público para abrigar downloads de Usuários
guest ok = yes (aqui poderá ser também "public = yes").
writable = yes
follow symlinks = false
Esta proteção é útil quando não desejamos que pessoas alterem o conteúdo de um compartil-
hamento. Isto pode ser feito de duas formas: negando o acesso de gravação para todo o com-
partilhamento ou permitindo leitura somente para algumas pessoas. O parâmetro usado para
fazer a restrição de acesso somente leitura é o read only = yes ou seu antônimo writable
= no. Abaixo seguem os dois exemplos comentados:
[teste]
comment = Acesso a leitura para todos
path = /tmp
read only = yes
public = yes
No exemplo acima, o diretório /tmp (path = /tmp) foi compartilhado com o nome teste
([teste]), de forma pública (acesso sem senha - public = yes), e todos podem apenas ler seu
conteúdo read only = yes).
[teste]
comment = Acesso a gravação para todos com excessões
Capítulo 18. SAMBA 349
path = /tmp
read only = no
read list = @users, gleydson
invalid users = root
Neste, o mesmo compartilhamento teste ([teste]) foi definido como acesso leitura/gravação
para todos (read only = no), mas os usuários do grupo @users e o usuário gleydson terão sempre
acesso leitura (read list = @users, gleydson). Adicionalmente foi colocada uma proteção para que
o superusuário não tenha acesso a ele (invalid users = root). Esta forma de restrição é explicada
melhor em ‘Excessão de acesso na permissão padrão de compartilhamento’ on the following
page).
[teste]
comment = Acesso de gravação para todos.
path = /tmp
writable = yes
public = yes
No exemplo acima, o diretório /tmp (path = /tmp) foi compartilhado com o nome teste
([teste]), de forma pública (acesso sem senha - public = yes) e todos podem ler/gravar dentro
dele (writable = yes).
[teste]
comment = Acesso a leitura para todos com excessões
path = /tmp
writable = no
write list = @users, gleydson
Neste, o mesmo compartilhamento teste ([teste]) foi definido como acesso de leitura para
todos (writable = no), mas os usuários do grupo @users e o usuário gleydson serão os únicos
que terão também acesso a gravação (write list = @users, gleydson). Esta forma de restrição é
explicada melhor em ‘Excessão de acesso na permissão padrão de compartilhamento’ on the
next page).
Capítulo 18. SAMBA 350
[temporario]
comment = Diretório temporário
path = /tmp
writable = yes
read list = gleydson, root
browseable = no
available = yes
[temporario]
comment = Diretório temporário
path = /tmp
writable = no
write list = gleydson, @operadores
browseable = yes
É seguro restringir os serviços IPC$ e ADMIN$ para acesso somente pelas faixas de rede de
confiança. Isto pode ser feito através da mesma forma que a restrição em outros compartil-
hamentos. Os efeitos desta restrição serão que somente as redes autorizadas possam obter a
lista de máquinas, se autenticar no domínio e realizar tarefas administrativas gerais:
Capítulo 18. SAMBA 351
[IPC$]
read only = yes
allow from 192.168.1.0/24
[ADMIN$]
read only = yes
allow from 192.168.1.0/24
O exemplo acima permite que os serviços IPC$ e ADMIN$ sejam acessados de qualquer
máquina na faixa de rede 192.168.1.0/24. Para forçar a autenticação para acesso a estes
serviços:
[IPC$]
invalid users = nobody
valid users = gleydson michelle
read only = yes
allow from 192.168.1.0/24
[ADMIN$]
invalid users = nobody
valid users = gleydson michelle
read only = yes
allow from 192.168.1.0/24
Os exemplos acima são similares ao de antes, mas o acesso a listagem dos compartilhamentos
é restringida (invalid users = nobody), pois o usuário nobody (usado para mostrar o compartil-
hamento) tem o acesso negado. Somente os usuários gleydson e michelle (valid users =
gleydson michelle) podem listar seu conteúdo.
OBS: Mesmo que estejam restritos, os serviços IPC$ e ADMIN$ sempre poderão ser acessados
de 127.0.0.1, ou teríamos problemas com o funcionamento do SAMBA. Assim não é necessário
colocar 127.0.0.1 na lista de IPs autorizados.
[teste]
path = /tmp
comment = Diretório temporário
read only = yes
browseable = no
Capítulo 18. SAMBA 352
Neste exemplo, o diretório /tmp (path = /tmp) foi compartilhado através de teste ([teste]) com
acesso somente leitura (read only = yes) e ele não será mostrado na listagem de compartilhamen-
tos do ambiente de rede do Windows (browseable = no).
Note que o compartilhamento continua disponível, porém ele poderá ser acessado da estação
Windows, especificando a \\maquina\compartilhamento. Para acessar o compartilhamento
do exemplo acima:
Ao contrário das máquinas Windows onde é necessário adicionar um ”$“ do nome de compar-
tilhamento para criar um compartilhamento oculto (como teste$) o SAMBA cria um com-
partilhamento realmente oculto, não aparecendo mesmo na listagem do smbclient.
Este recurso oferece uma infinidade de soluções que podem resolver desde problemas de prati-
cidade até segurança usando as opções preexec e postexec. Por exemplo, imagine que es-
teja compartilhando 4 unidades de CD-Rom de um servidor na rede, e deseje que estes CDs
estejam sempre disponíveis mesmo que algum operador engraçadinho tenha ejetado as gave-
tas de propósito, podemos fazer a seguinte configuração:
[cdrom]
path = /cdrom
comment = Unidade de CD-ROM 1
read only = yes
preexec = /bin/mount /cdrom
preexec close = yes
postexec = /bin/umount /cdrom
Na configuração acima, o CD-ROM será compartilhado como cdrom ([cdrom]), somente leitura
(red only = yes), quando o usuário acessar o compartilhamento ele ”fechará“ a gaveta do CD
(preexec = /bin/mount /cdrom) e desmontará o drive de CD assim que o compartilhamento for
fechado (postexec = /bin/umount /cdrom). Adicionalmente, caso o comando mount da opção
preexec tenha retornado um valor diferente de 0, a conexão do compartilhamento é fechada
(preexec close = yes).
A UID do processo do preexec e postexec será o mesmo do usuário que está acessando o
compartilhamento, por este motivo ele deverá ter permissões para montar/desmontar o CD-
ROM no sistema. Caso precise executar comandos como usuário root, utilize a variante root
preexec e root postexec. Apenas tenha consciência que os programas sendo executados
são seguros o bastante para não comprometer o seu sistema.
Capítulo 18. SAMBA 353
Usando a mesma técnica, é possível que o sistema lhe envie e-mails alertando sobre acesso
a compartilhamentos que em conjunto com um debug level 2 e logs configurados indepen-
dentes por máquina, você possa ver o que a máquina tentou acessar (e foi negado) e o que ela
conseguiu acesso.
Como bom administrador, você poderá criar scripts que façam uma checagem de segurança
no compartilhamento e encerre automaticamente a conexão caso seja necessário, montar um
”honney pot“ para trojans, etc.
Como deve estar notando, as possibilidades do SAMBA se extendem além do simples compar-
tilhamento de arquivos, se integrando com o potencial dos recursos do sistema UNIX.
Este parâmetro permite que você acesso um compartilhamento sem fornecer uma senha, ou
seja, que o usuário não esteja autenticado. NÃO utilize o parâmetro ”public = yes“ (ou um de
seus sinônimos) no compartilhamento [homes], pois abrirá brechas para que possa acessar o
diretório home de qualquer usuário e com acesso a gravação (que é o padrão adotado pelos
administradores para permitir o acesso ao seu diretório home remoto).
Recomendo utilizar o parâmetro public = yes somente em compartilhamentos onde é real-
mente necessário, como o [netlogon] ou outras áreas de acesso público onde as permissões do
sistema de arquivos local estejam devidamente restritas. Outra medida é não utilizar a opção
follow symlinks, que poderá lhe causar problemas com usuários mal intencionados que
tenham acesso shell.
OBS: Tenha em mente todas as considerações de segurança abordadas neste capítulo, bem
como as permissões de acesso ao sistema Unix e como elas funcionam. A disponibilidade de
arquivos em uma rede é simples, simples também pode ser o acesso indevido a eles caso não
saiba o que está fazendo.
Como regra geral, prefira sempre utilizar senhas criptografadas. Aqui alguns motivos:
• A senha é enviada de uma forma que dificulta sua captura por pessoas maliciosas.
• O NT não permite que você navegue no ambiente de rede em um sistema SAMBA com
nível de acesso por usuário autenticando usando senhas em texto plano.
• Será solicitada sempre a senha para reconexão em cada compartilhamento da máquina.
• Todas as versões de Windows NT 4 a partir SP3 e Windows 95 OSR/2 utilizam senhas
criptografadas como padrão. É possível faze-lo utilizar senhas em texto plano modifi-
cando chaves no registro das máquinas clientes (veja ‘Ativando o suporte a senhas em
texto plano’ on page 338 para detalhes).
As vantagens da utilização da autenticação usando texto plano:
• A senha utilizada será a mesma do /etc/passwd (servindo para ftp, login, etc)
• O servidor PDC pode ser usado para logon desde que os clientes estejam usando senhas
em texto plano.
Capítulo 18. SAMBA 354
Este recurso faz a mapeamento (tradução) de nomes de usuários usados no momento do acesso
para contas de acesso locais, bastante útil quando o nome de usuário enviado pela máquina
não confere com NENHUMA conta local do sistema (um exemplo é quando o login do usuário
no Windows é diferente de seu Login no Linux). Outro vantagem de seu uso é permitir que
uma categoria de usuários utilizem um mesmo nível de acesso no sistema.
Seu formato é o seguinte: username map = arquivo.
As seguintes regras são usadas para construir o arquivo de mapeamento de nomes:
• Um arquivo de múltiplas linhas onde o sinal de ”=“ separa os dois parâmetros princi-
pais. O arquivo é processado linha por linha da forma tradicional, a diferença é o que
o processamento do arquivo continua mesmo que uma condição confira. Para que o
processamento do resto do arquivo seja interrompido quando um mapeamento confira,
coloque o sinal ”¡‘ na frente do nome local.
• O parâmetro da esquerda é a conta Unix local que será usada para fazer acesso ao com-
partilhamento. Somente uma conta Unix poderá ser utilizada.
• O parâmetro da direita do sinal de ”=“ pode conter um ou mais nomes de usuários sep-
arados por espaços que serão mapeados para a conta Unix local. O parâmetro ”@grupo“
permite que usuários pertencentes ao grupo Unix local sejam mapeados para a conta de
usuário do lado esquerdo. Outro caracter especial é o ”*“ e indica que qualquer usuário
será mapeado.
Você pode utilizar comentários na mesma forma que no arquivo de configuração smb.conf.
Alguns exemplos:
# Mapeia qualquer nome de usuário que pertença ao grupo smb-users para o usuár
# samba.
samba = @smb-users
Capítulo 18. SAMBA 355
Esta seção trará algumas formas de otimização do servidor SAMBA que fazem diferença
quando os valores adequados são utilizados: A primeira é a ativação de um cache de
gravação/leitura de arquivos. Este cache é feito pela opção write cache size e funciona
fazendo o cache dos arquivos que serão lidos/gravados. Ele é esvaziado assim que o arquivo
for fechado ou quando estiver cheio. O valor especificado nesta opção é em bytes e o padrão
é ”0“ para não causar impacto em sistemas com pouca memória (ou centenas de compartil-
hamentos). Exemplo:
[publico]
path = /pub
comment = Diretório de acesso público
read only = yes
public = yes
write cache size = 384000
Compartilha o diretório /pub (path = /pub) como compartilhamento de nome publico ([pub-
lico]), seu acesso será feito como somente leitura (read only = yes) e o tamanho do cache de
leitura/gravação reservado de 384Kb (write cache size = 384000).
Deixar a opção para seguir links simbólicos ativada (follow symlinks) garante mais per-
formance de acesso a arquivos no compartilhamento. A desativação da opção wide links
em conjunto com o uso de cache nas chamadas getwd (getwd cache) permite aumentar a
segurança e tem um impacto perceptível na performance dos dados.
A desativação da opção global nt smb support também melhora a performance de acesso dos
compartilhamentos. Esta é uma opção útil para detectar problemas de negociação de protocolo
e por padrão, ela é ativada.
Caso utiliza um valor de depuração de log muito alto (debug level), o sistema ficará mais lento
pois o servidor sincroniza o arquivo após cada operação. Em uso excessivo do servidor de
arquivos, isso apresenta uma degradação perceptível de performance.
A opção prediction permite que o SAMBA faça uma leitura adiante no arquivo abertos
como somente-leitura enquanto aguarda por próximos comandos. Esta opção associada com
bons valores de write cache size pode fazer alguma diferença. Note que o valor de leitura nunca
ultrapassa o valor de ”read size“.
Capítulo 18. SAMBA 356
A opção read size permite obter um sincronismo fino entre a leitura e gravação do disco com o
envio/recebimento de dados da rede. O valor é dependente da instalação local, levando em
consideração a velocidade de disco rígido, rede, etc. O valor padrão é 16384.
Em casos onde um NFS montado ou até mesmo leitura em discos locais é compartilhada, o
parâmetro strict locking definido para yes pode fazer alguma diferença de performance. Note
que nem todos os sistemas ganham performance com o uso desta opção e não deve ser usada
em aplicativos que não requisitam o estado do lock de arquivo ao servidor.
Caso você possua aplicativos que fazem o lock corretamente de arquivos, você poderá usar
o share modes = no, isto significa que futuras aberturas de arquivo podem ser feitas em em
modo leitura/gravação. Caso utiliza um aplicativo muito bem programado que implementa
de forma eficiente de lock, você poderá desativar esta opção.
O uso de oplocks yes em compartilhamentos aumenta a performance de acesso a arquivos em
até 30%, pois utiliza um código de cache no cliente. Tenha certeza do que está fazendo antes
de sair usando oplocks em tudo que é lugar. A desativação de kernel oplocks é necessária para
que isto funcione.
A opção read raw e write raw devem ter seus valores experimentados para ver se faz diferença
na performance da sua rede, pois é diretamente dependente do tipo de cliente que sua rede
possui. Alguns clientes podem ficar mais lentos em modo de leitura raw.
O tipo de sistema de arquivos adotado na máquina e suas opções de montagem tem um im-
pacto direto na performance do servidor, principalmente com relação a atualização de status
dos arquivos no sistema de arquivos (hora de acesso, data, etc).
O cache de leitura adiante de abertura de arquivos em modo somente leitura aumenta a per-
formance com o uso do oplocks nível 2. Para isto, ajuste a opção level2 oplocks para yes.
A recomendação deste tipo de oplock é o mesmo do nível 1.
Como o SAMBA faz o transporte NetBEUI via TCP/IP, ajustes no socket fazem diferença nos
dados que trafegam na rede. Como isso é dependente de rede você precisará usar técnicas
de leitura/gravação para determinar quais são as melhores que se encaixam em seu caso. A
opção socket options é usada para fazer tais ajustes, por exemplo:
de domínio e como a configuração é compatível entre Linux e Windows, estas explicações são
perfeitamente válidas para configurar clientes que acessem servidores Windows.
Sistemas com implementações NetBIOS mais antigos, como o Windows for Workgroups
(Windows 3.11) e o Lan Manager (DOS), enviam somente a senha para acesso ao compar-
tilhamento, desta forma, para o acesso ser autorizado pelo samba, você deverá especificar a
diretiva user = usuario para que a senha confira com o usuário local do sistema. A senha envi-
ada também é em formato texto plano. Este problema não ocorre no Windows 95 e superiores,
que enviam o nome de usuário que efetuou o logon junto com a respectiva senha.
Se a segurança do seu samba depende de senhas criptografadas, será necessário utilizar a dire-
tiva ”include = outro_arquivo_de_configuração.%m para definir configurações es-
pecíficas de acesso para estas máquinas.
Outro detalhe que deve ser lembrado é que o Windows for Workgroups envia sempre
a senha em MAIÚSCULAS, então é preciso configurar o SAMBA para tentar combinações
de maiúsculas/minúsculas usando o parâmetro mangle case e default case na seção global do
smb.conf.
Para configurar o cliente para fazer parte de um grupo de trabalho, é necessário apenas que
tenha em mãos o nome do grupo de trabalho (workgroup) que os clientes farão parte e
o nome de uma outra máquina que faz parte do mesmo grupo (para testes iniciais). Com estes
dados em mãos, selecione na lista abaixo o nome do cliente que deseja configurar para incluir
no grupo de trabalho:
• ‘Windows 9X’ on the current page
• ‘Windows XP Home Edition’ on the following page
• ‘Windows XP Professional Edition’ on the next page
• ‘Windows XP Server Edition’ on the following page
• ‘Windows NT WorkStation’ on page 359
• ‘Windows NT Server’ on page 359
• ‘Windows 2000 Professional’ on page 359
• ‘Windows 2000 Server’ on page 359
• ‘Linux’ on page 359
Windows 9X
Estas configurações são válidas para clientes Windows 95, Windows 95OSR/2, Windows 98.
Caso utilize o Windows 95 (qualquer uma das séries) é aconselhável atualizar a stack TCP/IP
e NetBEUI para corrigir alguns problemas que podem deixar sua máquina vulnerável na ver-
são que acompanha o WinSock do Windows 95.
Para tornar uma máquina parte do grupo de trabalho, siga os seguintes passos:
Capítulo 18. SAMBA 358
Windows NT WorkStation
Windows NT Server
• Clique no item Rede do painel de controle.
• Na tab Serviços, confira se os serviços Estação de trabalho, Interface de
NetBIOS e Serviços TCP/IP simples estão instalados. Caso não estejam, faça sua
instalação usando o botão Adicionar nesta mesma janela.
• Na tab Protocolos, verifique se os protocolos NetBEUI e TCP/IP estão instalados. Caso
não estejam, faça sua instalação clicando no botão Adicionar nesta mesma janela.
• Na tab identificação, clique no botão Alterar
• Na janela que se abrirá, coloque o nome do computador no campo Nome do
Computador
• Clique em Grupo de trabalho e escreva o nome do grupo de trabalho em frente.
• Clique em OK até voltar.
• Pronto, seu computador agora faz parte do grupo de trabalho.
Linux
Os aplicativos smbclient e smbmount são usados para navegação e montagem dos discos e
impressoras compartilhadas em máquinas Linux. Se você procura programas de navegação
Capítulo 18. SAMBA 360
gráficos, como o Ambiente de Rede do Windows ou mais poderosos, veja ‘Programas de naveg-
ação gráficos’ on page 366. Como complemento, também é explicado o programa nmblookup
para resolução de endereços NetBIOS em IP e vice-versa e a forma que as funções de máquinas
são definidas em uma rede NetBEUI.
nmblookup Esta é uma ferramenta usada para procurar nomes de cliente usando o endereço
IP, procurar um IP usando o nome e listar as características de cada cliente. Veja alguns exem-
plos:
nmblookup -A 127.0.0.1 Lista o nome e as opções usadas pelo servidor 127.0.0.1
nmblookup servidor Resolve o endereço IP da máquina servidor.
A listagem exibida pela procura de IP do nmblookup possui códigos hexadecimais e cada um
deles possui um significado especial no protocolo NetBEUI. Segue a explicação de cada um:
Identificação da máquina • COMPUTADOR<00>= O serviço NetBEUI está sendo execu-
tado na máquina.
• COMPUTADOR<03> = Nome genérico da máquina (nome NetBIOS).
• COMPUTADOR<20> = Serviço LanManager está sendo executado na máquina.
Identificação de grupos/domínio • GRUPO_TRABALHO<1d> - <GRUPO> = Navegador
Local de Domínio/Grupo.
• GRUPO_TRABALHO<1b> = Navegador Principal de Domínio.
• GRUPO_TRABALHO<03> - <GRUPO> = Nome Genérico registrado por todos os
membros do grupo de trabalho.
• GRUPO_TRABALHO<1c> - <GRUPO> = Controladores de Domínio / Servidores
de logon na rede.
• GRUPO_TRABALHO<1e> - <GRUPO> = Resolvedores de Nomes Internet (WINS).
Estes códigos podem lhe ser úteis para localizar problemas mais complicados que possam
ocorrer durante a configuração de um servidor.
Para configurar qualquer um dos cliente abaixo para fazer parte de um domínio de rede, é
necessário apenas que tenha em mãos os seguintes dados:
• Nome do controlador de domínio PDC
• Nome do domínio
• Nome de usuário e senha que foram cadastrados no servidor.
• Acesso administrador no SERVIDOR PDC (SAMBA, NT, etc).
• Cria uma conta de máquina no domínio (no caso da máquina ser um Windows NT, Win-
dows XP, Windows 2k ou Linux). Veja ‘Contas de máquinas de domínio’ on page 328
para maiores detalhes.
Como o Windows 3.11, Windows 95, Windows 98, Windows ME não possuem uma conta de
máquina, eles nunca serão um membro real de um domínio, podendo sofrer um name spoofing
e terem a identidade roubada. Mesmo assim, eles terão pleno acesso aos recursos do domínio
e uma configuração mais fácil que os demais clientes. Com estes dados em mãos, selecione na
lista abaixo o nome do cliente que deseja integrar no grupo de trabalho:
• ‘Windows 9X’ on page 357
• ‘Windows XP Home Edition’ on page 358
• ‘Windows XP Professional Edition’ on page 358
• ‘Windows XP Server Edition’ on page 358
• ‘Windows NT WorkStation’ on page 359
• ‘Windows NT Server’ on page 359
• ‘Windows 2000 Professional’ on page 359
Capítulo 18. SAMBA 362
Windows 9X
Estas configurações são válidas para clientes Windows 95, Windows 95OSR/2, Windows 98.
Caso utilize o Windows 95 (qualquer uma das séries) é aconselhável atualizar a stack TCP/IP
e NetBEUI para corrigir alguns problemas que podem deixar sua máquina vulnerável na ver-
são que acompanha o WinSock do Windows 95.
Para tornar uma máquina parte do domínio, siga os seguintes passos:
• Entre nas propriedades de rede no Painel de Controle
• Instale o Cliente para redes Microsoft (caso não esteja instalado).
• Instale o Protocolo TCP/IP. Você também pode instalar o protocolo NetBIOS, mas uti-
lizaremos o suporte NetBIOS sobre TCP/IP que é o usado pelo SAMBA além de ter um
melhor desempenho, permitir integração com servidores WINS, etc.
• Clique em “Cliente para redes Microsoft”, marque a opção “Efetuar logon no domínio do
Windows NT”. Coloque o nome do domínio que irá configurar o cliente para fazer parte
na caixa “Domínio do Windows NT” (por exemplo, “suporte”). Na parte de baixo da
caixa de diálogo, você poderá escolher como será o método para restaurar as conexões
de rede. Inicialmente, recomendo que utilize a “Efetuar logon e restaurar as conexões
de rede” que é mais útil para depurar problemas (possíveis erros serão mostrados logo
que fizer o logon no domínio). Adeque esta configuração as suas necessidades quando
estiver funcionando :)
• Clique em “Protocolo TCP/IP” e em Propriedades. Clique na tab “NetBIOS” e marque
a opção “Desejo ativar o NetBIOS através do TCP/IP”. Caso esta caixa esteja em cinza,
então está tudo certo também.
• Clique na tab “Identificação” e coloque lá o nome que identificará o computador (até 15
caracteres).
• Digite o nome de um grupo de trabalho que a máquina fará parte no campo “Grupo de
Trabalho” (por exemplo “workgroup”, “suporte”, etc). Este campo somente será usado
caso o logon no domínio NT não seja feito com sucesso. No campo “Descrição do Com-
putador”, coloque algo que identifique a máquina na rede (por exemplo, “Computador
da área de suporte”).
• Clique na tab “Controle de Acesso” e marque o “Controle de acesso a nível de usuário
e especifique o nome da máquina que serve a lista de usuários, que normalmente é a
mesma do PDC.
• Clique em OK até reiniciar o computador.
Quando for mostrada a tela pedindo o nome/senha, preencha com os dados da conta de
usuário que criou no servidor. No campo domínio, coloque o domínio que esta conta de
usuário pertence e tecle <Enter>. Você verá o script de logon em ação (caso esteja configurado)
e a máquina cliente agora faz parte do domínio! Tente acessar um outro computador da rede
e navegar através do ambiente de rede. Caso a lista de máquinas demore em aparecer, tente
Capítulo 18. SAMBA 363
Não é possível fazer o Windows XP Home Edition ser parte de um domínio, por causa de
limitações desta versão.
• Primeiro, siga todos os passos para ingressar a máquina em um grupo de trabalho como
documentado em ‘Windows XP Professional Edition’ on page 358.
• Atualize o registro para permitir a entrada no domínio:
1 Copie o seguinte conteúdo para o arquivo WinXP-Dom.reg:
REGEDIT4
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\netlogon\para
"RequireSignOrSeal"=dword:00000000
"SignSecureChannel"=dword:00000000
2 Execute o comando regedit WinXP-Dom.reg no cliente XP.
• Entre nos ítens (em seqüencia) Painel de controle/Ferramentas Administrativas/ Política
de segurança local/políticas locais e depois em ”opções de segurança“. Na janela de
opções de segurança, desative as opções ”Encriptar digitalmente ou assinar um canal
seguro (sempre)“, ”Desativar modificações de senha na conta de máquina“ e ”Requer
chave de seção forte (Windows 2000 ou superior).“
• Reinicie a máquina.
• Após reiniciar a máquina, volte na tela de alteração de identificação de máquina na rede.
• Clique com o mouse em ”Domínio“ e digite o nome do domínio na caixa de diálogo.
• Na tela seguinte, será lhe pedido o nome de usuário e senha com poderes administrativos
que podem inserir/remover máquinas do domínio.
• Clique em OK e aguarde a mensagem confirmando sua entrada no domínio. Será
necessário reiniciar a máquina após concluir este passo.
Windows NT WorkStation
Windows NT Server
• Primeiro, siga todos os passos para ingressar a máquina em um grupo de trabalho como
documentado em ‘Windows 2000 Server’ on page 359.
• Após reiniciar a máquina, volte na tela de alteração de identificação de máquina na rede.
• Clique com o mouse em ”Domínio“ e digite o nome do domínio na caixa de diálogo.
• Na tela seguinte, será lhe pedido o nome de usuário e senha com poderes administrativos
que podem inserir/remover máquinas do domínio.
• Clique em OK e aguarde a mensagem confirmando sua entrada no domínio. Será
necessário reiniciar a máquina após concluir este passo.
Caso não consiga trocar a senha do Windows 2000 no servidor PDC, desative a opção unix
password sync.
Linux
[global]
workgroup = nome_domínio
security = domain
password server = nome_pdc nome_bdc
encrypt passwords = true
Onde:
– workgroup - Nome do domínio que deseja fazer parte.
– security - Nível de segurança. Nesta configuração, utilize ”domain“.
– password server - Nome da máquina PDC, BDC. Também poderá ser usado *,
assim o SAMBA tentará descobrir o servidor PDC e BDC automaticamente, da mesma
forma usada pelo Windows.
– encrypt passwords - Diz se as senhas serão encriptadas ou não. Sempre utilize
senhas criptografadas para colocar uma máquina em um domínio.
Reinicie o servidor SAMBA após estas modificações.
• Execute o comando: smbpasswd -j domínio -r PDC/BDC -U usuario_admin.
Onde:
– domínio - Domínio que deseja fazer o logon
– PDC/BDC - Nome da máquina PDC/BDC do domínio. Em alguns casos, pode ser
omitido.
– usuario_admin - Usuário com poderes administrativos para ingressara a máquina
no domínio.
• Se tudo der certo, após executar este comando, você verá a mensagem:
Joined domain "domínio".
Se sua configuração não funcionou, revise com atenção todos os ítens acima. Verifique se a
conta de máquina foi criada no servidor e se o SAMBA na máquina cliente foi reiniciado. De
também uma olhada em ‘Erros conhecidos durante o logon do cliente’ on this page.
OBS:O SAMBA envia primeiramente um usuário/senha falso para verificar se o servidor re-
jeita o acesso antes de enviar o par de nome/senha corretos. Por este motivo, seu usuário
pode ser bloqueado após um determinado número de tentativas em alguns servidores mais
restritivos. Para acessar os recursos compartilhados, veja ‘Linux’ on page 359. Note que não
é obrigatório realizar as configurações acima para acessar os recursos de uma máquina em
domínio, basta apenas que autentique com seu nome de usuário/senha no domínio e que ela
seja autorizada pelo PDC.
Esta seção contém os erros mais comuns e a forma de correção da maioria dos problemas que
ocorrem quando um cliente SAMBA tenta entrar em domínio.
• error creating domain user: NT_STATUS_ACCESS_DENIED - A conta de
máquina no domínio não foi criada. Veja ‘Contas de máquinas de domínio’ on page 328
para mais detalhes.
• NT_STATUS_NO_TRUST_SAM_ACCOUNT - Não existe conta de máquina no Windows
NT para autenticar uma máquina no domínio. Esta mensagem é mostrada quando a
máquina SAMBA é cliente de um domínio NT.
Capítulo 18. SAMBA 366
linneighborhood
Cliente SAMBA baseado em GTK, muito leve e possibilita a navegação entre os grupos
máquinas em forma de árvore. Ele também permite a montagem de compartilhamentos re-
motos. Caso precise de recursos mais complexos e autenticação, recomendo o ‘TkSmb’ on this
page.
TkSmb
Cliente SAMBA baseado em TCL/TK. Seu ponto forte é a navegação nos recursos da máquina
ao invés da rede completa, possibilitando autenticação em domínio/grupo de trabalho, mon-
tagem de recursos, etc.
São ferramentas que permitem a configuração do samba usando a interface gráfica. Isto facilita
bastante o processo, principalmente se estiver em dúvidas em algumas configurações, mas
como todo bom administrador UNIX sabe, isto não substitui o conhecimento sobre o funciona-
mento de cada opção e ajustes e organização feita diretamente no arquivo de configuração.
Capítulo 18. SAMBA 367
gnosamba
Ferramenta de configuração gráfica usando o GNOME. Com ele é possível definir configu-
rações localmente. Ele ocupa pouco espaço em disco, e se você gosta de GTK, este é o re-
comendado.
As opções do SAMBA são divididas em categorias facilitando sua localização e uso.
swat
Ferramenta de administração via web do samba. Este é um daemon que opera na porta 901 da
máquina onde o servidor samba foi instalado. A configuração é feita através de qualquer nave-
gador acessando http://ip_do_servidor:901 e logando-se como usuário root (o único
com poderes para escrever no arquivo de configuração).
Esta ferramenta vem evoluindo bastante ao decorrer dos meses e é a recomendada para a
configuração do servidor SAMBA remotamente. Seu modo de operação divide-se em básico e
avançado. No modo básico, você terá disponível as opções mais comuns e necessárias para
compartilhar recursos na rede. O modo avançado apresenta praticamente todos os parâmet-
ros aceitos pelo servidor samba (restrições, controle de acesso, otimizações, etc.).
Os exemplos existentes nesta seção cobrem diferentes tipos de configuração do servidor, tanto
em modo de compartilhamento com acesso público ou um domínio restrito de rede. Todos os
exemplos estão bem comentados e explicativos, apenas pegue o que se enquadre mais em sua
situação para uso próprio e adaptações.
Este exemplo pode ser usado de modelo para construir uma configuração baseada no controle
de acesso usando o nível de segurança share e quando possui compartilhamentos de acesso
público. Esta configuração é indicada quando necessita de compatibilidade com softwares
NetBIOS antigos.
[global]
# nome da máquina na rede
netbios name = teste
# nome do grupo de trabalho que a máquina pertencerá
workgroup = focalinux
# nível de segurança share permite que clientes antigos mantenham a compatibi
# enviando somente a senha para acesso ao recurso, determinando o nome de usu
# de outras formas
security = share
# O recurso de senhas criptografadas não funciona quando usamos o nível share
# de segurança. O motivo disto é porque automaticamente é assumido que você
# está selecionando este nível por manter compatibilidade com sistemas antigo
# ou para disponibilizar compartilhamentos públicos, onde
encrypt passwords = false
# Conta que será mapeada para o usuário guest
guest account = nobody
# Como todos os compartilhamentos desta configuração são de acesso público
# coloquei este parâmetro na seção [global], assim esta opção afetará todos
# os compartilhamentos.
guest ok = 1
# Conjunto de caracteres utilizados para acessar os compartilhamentos. O padr
# para o Brasil e países de língua latina é o ISO 8859-1
character set = ISO8859-1
O exemplo abaixo descreve uma configuração a nível de segurança por usuário onde exis-
tem compartilhamentos que requerem login e usuários específicos, e restrições de IPs e inter-
face onde o servidor opera. Esta configuração utiliza senhas em texto claro para acesso dos
usuários, mas pode ser facilmente modificada para suportar senhas criptografadas.
[global]
# nome da máquina na rede
netbios name = teste
# nome do grupo de trabalho que a máquina pertencerá
workgroup = focalinux
# nível de segurança user somente aceita usuários autenticados após o envio
# de login/senha
security = user
# É utilizada senhas em texto claro nesta configuração
encrypt passwords = false
# Conta que será mapeada para o usuário guest
guest account = nobody
# Permite restringir quais interfaces o SAMBA responderá
bind interfaces only = yes
# Faz o samba só responder requisições vindo de eth0
interfaces = eth0
# Supondo que nossa interface eth0 receba conexões roteadas de diversas
# outras redes, permite somente as conexões vindas da rede 192.168.1.0/24
hosts allow = 192.168.1.0/24
# A máquina 192.168.1.57 possui gateway para acesso interno, como medida
Capítulo 18. SAMBA 370
18.15.3 Domínio
[global]
# nome da máquina na rede
netbios name = teste
# nome do grupo de trabalho que a máquina pertencerá
workgroup = focalinux
# String que será mostrada junto com a descrição do servidor
server string = servidor PDC principal de testes
# nível de segurança user somente aceita usuários autenticados após o envio
# de login/senha
security = user
# Utilizamos senhas criptografadas nesta configuração
encrypt passwords = true
smb passwd file = /etc/samba/smbpasswd
# Conta que será mapeada para o usuário guest
guest account = nobody
# Permite restringir quais interfaces o SAMBA responderá
bind interfaces only = yes
# Faz o samba só responder requisições vindo de eth0
interfaces = eth0
Capítulo 19
Este capítulo documenta diversos métodos de fazer restrições de contas, limitação de acesso
interno/externo, de recursos por usuários/grupos, login, tempo máximo ocioso, e outros mo-
dos para limitar o uso de recursos do sistema. Também são descritos métodos para aumentar a
segurança do acesso físico a seu servidor e maneiras de restringir o uso de serviços disponíveis
no sistema.
Se você deseja restringir o acesso de máquinas na rede ou portas específicas em sua máquina ,
veja também ‘Firewall iptables’ on page 109 .
Variáveis exportadas na forma comum podem ser modificadas a qualquer momento pelo
usuário, e isso pode trazer problemas de acordo com o tipo de sistema que administramos.
A definição da variável como somente leitura (readonly) evita a maioria destes problemas:
readonly TESTE="123"
A variável TESTE não poderá ser modificada ou excluída. Com isto o administrador pode
”bloquear“ a modificação de variáveis que controlam o funcionamento de determinados re-
cursos do interpretador de comandos (alguns deles serão vistos ainda nesta seção).
OBS2: Variáveis exportadas como somente leitura em shell scripts são mantidas até a finaliza-
ção do script e depois liberadas.
Capítulo 19. Restrições de acesso, recursos e serviços 376
O controle de acesso a diretórios de usuários é importante quando desejamos que outras pes-
soas não tenham acesso ao diretório de outros usuários, violando a privacidade do mesmo
e obtendo acesso a partes indesejáveis, principalmente do usuário root. É recomendado re-
stringir o acesso somente ao dono e grupo do usuário, bloqueando o acesso a outros tipos de
usuários:
Isto garantirá que o servidor Apache continue servindo as requisições dentro do diretório
/home/usuario, com acesso garantido via grupo. O mesmo principio pode ser aplicado em
outros programas, apenas leve em consideração que se um cracker tomar conta do processo
que tem acesso ao seu diretório home restrito, ele certamente também terá acesso.
Quando o bash é iniciado com o parâmetro -r, --restricted ou como rbash, o shell re-
stringe o uso dos seguintes recursos em sua seção:
• Usar o comando cd para mudar de diretório.
• Definindo, modificar ou apagar a variáveis SHELL, PATH, ENV, BASH_ENV.
• Nomes de comandos que contém /
• Especificar um nome de arquivo contendo uma / como argumento para o comando
builtin (embutido no interpretador de comandos).
• Especificar uma / como argumento a opção -p no comando hash (embutido no interpre-
tador de comandos).
• Importar a definição de funções do ambiente do shell atual.
Capítulo 19. Restrições de acesso, recursos e serviços 377
A variável TMOUT determina o tempo de inatividade de um shell para que ele seja terminado.
export TMOUT=600
Terminará o bash caso nenhum comando seja executado no período de 600 segundos (5 minu-
tos). Veja ‘Uso do comando readonly para exportar variáveis’ on page 375 como complemento.
Todos os comandos que digitamos em uma seção do shell são registrados no arquivo ~
/.bash_history, as seguintes variáveis fazem seu controle:
• HISTFILE - Nome do arquivo que armazenará o histórico de comandos. O padrão é ~
/.bash_history. Caso não seja especificado, os comandos não serão gravados após
finalizar o shell.
• HISTSIZE - Define o número de comandos que o arquivo de histórico poderá armazenar,
o padrão é 500.
• HISTFILESIZE - Define o número máximo de linhas no arquivo de histórico.
Se você possui muitos usuários em seu sistema, é recomendado ajustar estas variáveis como
somente leitura para que o usuário não desative o logging por qualquer motivo (veja ‘Uso do
comando readonly para exportar variáveis’ on page 375).
Existem casos onde o usuário precisa estar cadastrado no sistema mas não precisa ter acesso
a uma conta de login válida (como um sistema servidor de e-mail ou outros serviços). Neste
caso a desabilitação dos serviços de shell aumentará um pouco a segurança do sistema, mesmo
conseguindo acesso a conta/senha estará impedido de entrar no sistema (pelo menos terá um
pouco mais dificuldade para conseguir isso).
Um programa que é muito usado para desabilitar o shell exibindo uma mensagem ao usuário
que fez a tentativa é o falselogin. Ele deve ser colocado como o ”shell padrão“ no arquivo
Capítulo 19. Restrições de acesso, recursos e serviços 378
ldd [programa]
Por exemplo:
ldd /bin/login
Caso a biblioteca libpam for listada, o programa tem suporte a PAM compilado. Programas
que não possuem suporte a PAM deverão ter o código fonte modificado inserindo as funções
para tratamento dos módulos de autenticação.
• Terceiro campo - Lista de terminais (tty - na forma listada pelo ttyname), nomes de
máquinas, nomes de domínios (começando com ”.“), endereços IP ou FQDN, porção de
rede (finalizando com um ”.“). As palavras chave ALL (todos) e LOCAL (máquinas na
mesma rede) também podem ser usadas.
OBS1: - A configuração padrão do access.conf é garantir o acesso a todos os usuários,
através de qualquer lugar (permissiva).
OBS2:: Mesmo se existir uma regra autorizando o acesso ao usuário, as restantes serão ver-
ificadas em busca de uma que bloqueie o acesso do usuário. Se nenhuma regra conferir, o
usuário terá acesso garantido.
OBS3: - O nome de grupo somente é checado quando nenhum nome de usuário confere com
nenhum usuário logado no sistema.
OBS4: - Grupos/usuários NIS podem ser especificados precedendo o nome do usuário ou
grupo por uma ”@“.
Abaixo uma configuração restrita de /etc/security/access.conf:
#
# Desabilita o login de todos os usuários EXCETO o root no terminal tty1
-:ALL EXCEPT root:tty1
A restrição de acesso a usuário root pelo PAM funciona permitindo que somente alguns
usuários que pertençam a um grupo criado pelo administrador possam se tornar o supe-
rusuário usando o comando su. Esta restrição funciona até mesmo para os usuários que pos-
suem a senha correta de root, retornando uma mensagem de login ou senha incorretos. Isto é
extremamente útil para restrições de acesso.
Um outro ponto positivo é caso ocorra um possível acesso não autorizado em seu sistema ou
um daemon seja corrompido e o atacante cair em um shell, ele não poderá obter root na
máquina pois o UID do daemon provavelmente não terá autorização. A distribuição Debian,
em especial, possui grupos e nomes de usuários organizados de forma a permitir segurança e
separação total caso utilize este mecanismo.
Capítulo 19. Restrições de acesso, recursos e serviços 381
Este recurso se mostra bem eficiente para proteger a integridade da máquina até mesmo no
comprometimento de máquinas que possui a senha semelhante, somente se usado em conjunto
com as restrições de acesso de outros serviços remotos (como o ssh, ftp, etc). O guia Foca
documenta as formas de restrição e seu impacto na segurança da máquina nos capítulos do
nível Avançado (veja o índice para buscar o capítulo correspondente ao que deseja proteger).
Para configurar esta restrição, siga os seguintes passos:
• Crie um grupo onde os usuários cadastrados terão acesso root. Por exemplo,
usuarios-su (ou algo mais discreto).
• Edite o arquivo /etc/pam.d/su. Insira a seguinte linha (caso não existir) no arquivo de
configuração:
auth required pam_wheel.so group=usuarios-su
O que ela faz é usar o módulo pam_wheel.so requerendo que os usuários pertençam
ao grupo usuarios-su. Salve e saia do editor.
• Ainda como usuário root, adicione os usuários que terão acesso a root no grupo
usuarios-su. Recomendo que adicione seu usuário primeiro, principalmente se es-
tiver fazendo acesso remoto, pois se acontecer uma queda no link não ficará sem acesso
root por cair na restrição :-)
• Tente pegar o root com outros usuários que não pertençam ao grupo usuarios-su
estes simplesmente terão o acesso negado.
• Primeiro campo - Nome do serviço PAM que será controlado (um dos serviços conti-
dos em /etc/pam.d).
• Segundo campo - Lista de nomes de terminais que a regra que aplicará. O sinal ”&“
tem a função and, ”|“ tem a função or e ”¡‘ especifica uma exceção.
• Terceiro campo - Nome de usuários afetados pela regra. O sinal ”&“ tem a função
and, ”|“ tem a função or e ”¡‘ especifica uma exceção.
OBS: O ”*“ poderá ser usado somente no primeiro, segundo ou terceiro campo em uma
mesma regra.
Por padrão o acesso é garantido a todos os usuários. Abaixo um exemplo de restrições usando
o /etc/security/time.conf:
OBS1: Mesmo se existir uma regra autorizando o acesso ao usuário, as restantes serão verifi-
cadas em busca de uma que bloqueie o acesso do usuário. Se nenhuma regra conferir, o usuário
terá acesso garantido.
OBS2: Quando as restrições de tempo são ativadas no /etc/security/time.conf, o dae-
mon logoutd poderá ser ativado manualmente (através de /etc/init.d/logoutd) para
monitora as restrições neste arquivo, forçando o logout de usuário de acordo com as configu-
rações do /etc/security/time.conf. Isto ocorrerá automaticamente na próxima vez que
iniciar o sistema (a distribuição detecta a presença de restrições de tempo no arquivo /etc
/security/time.conf para decidir se deve ou não carregar este daemon).
Quando não está em execução, os limites de tempo são verificados somente no login do
usuário, ele poderá ultrapassar este tempo sem ser desconectado do sistema.
de serviços PAM baseados em dia/hora’ on page 381. O 5o campo contém um ou mais grupos
(separados por espaços ou vírgulas) que serão adicionados aos grupos do usuário quando as
condições dos campos anteriores conferirem.
OBS: Se o usuário escrever um programa que chama um interpretador de comandos e der
a permissão SGID (chmod g+s programa), ele terá acesso àquele grupo na hora que quiser.
Restrinja o uso de grupos somente a usuários de confiança ou crie grupos específicos para
evitar problemas.
Exemplo de configuração do arquivo /etc/security/group.conf:
# Permite que o usuário gleydson tenha acesso ao grupo floppy efetuando o logi
# entre 08:00 da manha e 19:00 da noite
login;tty*;gleydson;Al0800-1900;floppy
# Todos os usuários podem ter acesso ao grupo games e sound aos sábados e domi
login;tty*;*;SaSu0000-2400;sound games
# Todos os usuários podem ter acesso ao grupo games e sound todos os dias
# de 18:00 as 05:00 da manhã (fora do horário de expediente ;-)
login;tty*;*;Al1800-0500;sound,games
OBS1: Mesmo que uma regra confira com o usuário, as outras também serão verificadas para
garantir acesso grupos extras.
OBS2: O padrão na maioria das distribuições é limitar o número máximo de grupos do usuário
para 32. Caso precise aumentar este limite, será necessário recompilar o kernel (e também a
glibc, se necessário) para aceitar um número maior modificando a variável ngroup.
Quando somente o limite ”hard“ (rígido) é especificado, o limite suave assume o mesmo
valor.
* soft core 0
* hard rss 10000
@student hard nproc 20
@faculty soft nproc 20
@faculty hard nproc 50
ftp hard nproc 0
@student - maxlogins 4
gleydson - maxlogins 2
OBS: Estas permissões passam a ter efeito no momento que o usuário se conecta ao sistema, e
não quando elas são modificadas no arquivo /etc/security/limits.conf.
fazer tarefas como conexão com internet, utilização da placa de som, modem, etc. e as vezes
nem sabem que isso pode ser feito através do mesmo usuário adicionando este a um grupo
específico.
Esta tarefa pode ser feita com o comando adduser usuário grupo ou editando manual-
mente os arquivos /etc/group e /etc/gshadow. Podemos ter as seguintes situações facili-
tadas com o uso de grupos:
• Usar a placa de som. Os dispositivos usados pela placa de som como /dev/audio,
/dev/dsp, /dev/sndstat, etc. normalmente tem permissão leitura/gravação para o
usuário root e grupo audio (cheque com o comando ls -la /dev/audio). Para
autorizar determinados usuários usar a placa de som basta adiciona-los neste grupo:
adduser usuario audio.
• Conectar a Internet. Normalmente o utilitário ppp tem as permissões SUID root e grupo
dip. Adicionamos o usuário a este grupo: adduser usuario dip. Agora ele poderá
conectar/desconectar a internet sem a intervenção do usuário root. OBS Certamente
o usuário terá acesso aos arquivos de configuração da discagem do ppp e conseqüente-
mente a senha de conexão internet, e esta senha é a mesma usada no e-mail primário
do provedor (com o mesmo nome da conta). Esta mesma situação pode acontecer com
outros programas que autorize o acesso a grupos, é importante que conheça bem as per-
missões do programa e entender se existem riscos.
• Utilizar o modem. Um bom grupo para permitir a utilização do modem é dialout. O
dispositivo utilizado pelo modem (não seu link) deve ter permissões leitura/gravação
para o usuário root e grupo dialout. Cadastrando o usuário neste grupo autorizará a
utilização do modem: adduser usuario dialout.
• Permitir que diversos usuários compartilhem um mesmo diretório. Isto é útil quando
muitas pessoas estão desenvolvendo um mesmo projeto. Siga estes passos:
– Crie um novo grupo no sistema: groupadd gp1, a opção -g permite selecionar
manualmente a GID. Opcionalmente você poderá usar um grupo já existente no
sistema (veja o arquivo /etc/group).
– Crie o diretório que será usado para armazenar os arquivos deste grupo de usuários:
mkdirprojeto1).
– Mude o dono/grupo do diretório: chown root.gp1 projeto1/
– De permissões de leitura/gravação para o dono/grupo do diretório, vamos também
incluir a permissão SGID para que todos os arquivos criados dentro deste diretório
pertençam ao mesmo grupo e não ao grupo primário do usuário, assim todos os
usuários terão acesso: chmod 2770 projeto1
– Agora cadastre os usuários que deverão ter acesso ao diretório projeto1/ no
grupo gp1, somente estes usuários e o root terão acesso ao diretório (permissões
2770).
– É interessante também mudar a ”umask“ do usuário de 022 para 002 (ou equiv-
alente) para que os novos arquivos criados tenham permissão de leitura/gravação
para o grupo gp1. Caso contrário, lembre-se de modificar as permissões de seus
arquivos manualmente. Um ótimo comando para fazer isso (sem afetar diretórios)
é: find . -type f -user usuario1 -exec chmod 0660 \{\} \;. Este
comando parece estranho mas é excelente! um chmod -R 0660 afetaria até os di-
retórios, imagine o caos.
Capítulo 19. Restrições de acesso, recursos e serviços 386
A maioria das distribuições Linux vem com uma boa política de grupos para permitir um
controle eficaz de recurso. Se você quer saber quais arquivos em seu sistema pertencem a
determinado grupo (útil para saber o que o usuário terá acesso se adiciona-lo àquele grupo)
execute o comando:
A ferramenta ideal para isto é o sudo. Através dela é possível permitir um usuário comum
executar um comando como root e registrar quando isto foi feito. É possível selecionar os
usuários/grupos que terão acesso e quais aplicativos que poderão ser usados, estas configu-
rações são feitas no arquivo /etc/sudoers.
Por exemplo, para o usuário ”john“ usar o comando shutdown para desligar o computador:
sudo shutdown -h now.
O sudo é um programa muito completo, tomaria muitos Kilobytes neste guia. Recomendo dar
uma lida na página de manual para entender como as variáveis do arquivo de configuração
funcionam. Mesmo assim aqui vai um exemplo simples deste arquivo para iniciar rapidamente
o uso do sudo:
# arquivo sudoers.
#
# Edite este arquivo com o comando ’visudo’ como root
#
#
Edite este arquivo com o comando visudo, ele faz algumas checagens para detectar problemas
de configuração. Para listar os comandos disponíveis para o usuário no sudo, utilize a opção
-l, ex: sudo -l.
Restrições de acesso através de grupos, bloqueio de acesso, acesso direto sem senha, etc. po-
dem ser aplicados ao sudo via seu arquivo de configuração PAM /etc/pam.d/su. Abaixo
um exemplo explicativo deste arquivo:
# Membros do grupo acima não precisam fornecer senha, temos confiança neles.
# auth sufficient pam_wheel.so trust
# Usuário que pertencem ao grupo "nosu" nunca deverão ter acesso ao ’su’
# auth required pam_wheel.so deny group=nosu
O serviço identd permite identificar os usuários que estão realizando conexões TCP, adi-
cionalmente esta característica é usada por programas para fazer restrições para usuários
em adição ao endereço de origem/destino. A sintaxe usada nas diretivas de acesso é es-
pecificada na forma usuário@endereço. O ‘Servidor ident’ on page 241 explica a configu-
ração/utilização/vulnerabilidades e recomendações sobre este serviço.
Diversos programas que possuem controle de acesso baseado em IP’s/hosts aceitam esta es-
pecificação, como o exim, ircd, e o conhecido tcpd.
Segue um exemplo da utilização do identd com o arquivo hosts.allow:
Note que a utilização do identd torna a utilização do serviço um pouco mais restrita, somente
conhecendo os ”logins“ de quem tem acesso ao serviço, um cracker conseguirá ter acesso ao
mesmo serviço naquele sistema (este é um dos motivos que é recomendado sempre divulgar o
mínimo detalhes possíveis sobre o sistema para minimizar riscos de ataques).
Veja mais detalhes sobre o uso do identd em ‘Servidor ident’ on page 241.
Esta proteção oferece uma barreira maior se segurança contra IPs spoofing evitando que pes-
soas mal intencionadas façam um IP spoofing da máquina para obter acessos privilegiados que
somente o detentor original do MAC/IP teria. Recomendo não levar em consideração que isto
seja a solução definitiva contra IP spoofing, pois é possível falsificar o MAC address de uma
interface para tomar outra identidade.
Este método poderá ser aplicado para fornecer um maior laço de confiança por hardware en-
tre as máquinas que compõem uma rede de servidores. Ele também evita mesmo que uma
máquina configurada de forma errônea tenha acesso indevido ao servidor ou em uma situação
extrema, se torne o gateway da rede.
Capítulo 19. Restrições de acesso, recursos e serviços 389
Para restringir as conexões para uma máquina Linux por MAC address, utilize o firewall
iptables. Com ele será permitido fazer a restrição por serviços, criando uma barreira bas-
tante chata para crackers tentarem se conectar a um serviço. Como referência, leia a seção
‘Especificando o endereço MAC da interface’ on page 144.
Outra situação é a restrição por par MAC/IP usando o próprio cache arp da máquina, us-
ando entradas estáticas de endereços. Um exemplo deste uso é quando você é extremamente
paranóico ou quando uma rede que utiliza algum método de autenticação baseado no rhosts
(como é o caso do sistema de backup do Amanda), então é importante dizer para as máquinas
servidoras, qual o MAC address/IP privilegiado que terá o acesso ao usuário para conexão
sem senha.
O local padronizado para definir um MAC estático (e bastante desconhecido da maioria dos
administradores de sistemas) é o /etc/ethers. O formato deste arquivo é o MAC Address e
IP separados por espaço, cada linha com uma nova entrada de MAC Address. Veja o exemplo:
00:03:47:AA:AA:AB www.focalinux.org.br
00:03:47:BB:AA:BA www2.focalinux.org.br
00:03:47:BB:AA:BB 192.168.0.1
Caso não conheça o formato do endereço de MAC Address, os três primeiros 3 campos definem
o fabricante da placa de rede, e os 3 últimos é uma identificação única do fabricante para a
Placa, ou seja, NENHUMA placa de rede fabricada tem o mesmo MAC Address físico.
Para que o comando arp crie as entradas estáticas no seu cache ARP, será necessário executar
o comando arp -f /etc/ethers. Este comando poderá ser colocado em algum script ou
diretório de inicialização de sua distribuição para que seja executado automaticamente (como
por exemplo, no /etc/rc.boot da Debian). Digitando arp você verá as linhas definidas no
arquivo /etc/ethers marcadas com as opção (flag) M (manual/permanente). Outra forma
de verificar, é usando o arp -a máquina ou somente arp -a. As máquinas especificadas
estaticamente (manualmente) terão o nome PERM listados (cache arp permanente).
OBS: Como deve ter notado, a restrição por MAC Address implica em um aumento no tra-
balho de gerenciamento das configurações. Assim, planeje-se para que esta tarefa não seja
desgastante, crie programas para realizar atualizações dinâmicas estudando a estrutura de sua
rede e como suas máquinas se comunicam para não ter problemas obscuros quando tiver que
fazer uma simples modificação em uma interface de rede :)
Uma boa configuração restritiva requer análise sobre os impactos na rede.
Desative todos os serviços que não serão utilizados no arquivo /etc/inetd.conf, isto
diminui bastante as possibilidades de ataques em seu sistema. Os nomes de serviços são os
parâmetros especificados na primeira coluna do arquivo /etc/inetd.conf (por exemplo,
talk, ircd, pop3, auth, smtp).
Capítulo 19. Restrições de acesso, recursos e serviços 390
Para desativar serviços neste arquivo, ponha o símbolo ”#“ no inicio das linhas que deseja co-
mentar e execute um killall -HUP inetd. Alternativamente, o comando update-inetd
pode ser usado para facilitar esta tarefa:
update-inetd --disable
Este comando envia automaticamente o sinal de reinicio (HUP) ao inetd. O serviço poderá ser
novamente ativado substituindo a opção –disable por –enable ou retirando o trecho ”#<off>#“
no começo da linha do serviço do /etc/inetd.conf.
maquina1.dominio.com.br usuario1
maquina2.dominio.com.br usuario2
O uso destes dois mecanismos e dos serviços ”r*“ são desencorajados! (o último por usar trans-
ferência de dados não criptografadas). Veja ‘Servidor ssh’ on page 251 para uma alternativa
melhor. Utilize estes dois mecanismos somente se deseja facilidade no gerenciamento e se sua
rede seja absolutamente confiável e a segurança de dados não seja prioridade pra você. . .
Por padrão todos que tem acesso ao console do sistema podem efetuar o reinicio do computa-
dor pressionando CTRL+ALT+DEL. Estas teclas de combinação são definidas pela linha
ca:12345:ctrlaltdel:/sbin/shutdown -r now
Capítulo 19. Restrições de acesso, recursos e serviços 391
O patch restricted proc fs é um dos melhores para realizar esta tarefa. Restringindo o acesso ao
sistema de arquivos /proc evita que o usuário normal tenha acesso aos detalhes sobre proces-
sos de outros (com ps aux) ou acesso a detalhes de processos de outros usuários existentes
nos subdiretórios numéricos (equivalentes a PID) em /proc. Abaixo algumas características
do patch restricted proc fs:
• É pequeno, rápido e faz poucas modificações no fonte do kernel.
• Seu método de funcionamento é baseado nas restrições de dono/grupo (nativas de am-
biente Unix).
• Restringe a visualização de processos só dos usuários. Adicionalmente será especificada
uma GID para o diretório /proc, qualquer usuário que pertença ao grupo especificado
poderá visualizar todos os processos e entrar em qualquer diretório do kernel (sem re-
strições, como se não tivesse o patch).
• Muito estável e confiável.
Este patch deve ser baixado de http://noc.res.cmu.edu/proc, existem versões para os
kernels da série 2.2 e 2.4, baixe e aplique o patch, na configuração do kernel ative a opção
Restricted Proc fs support. Compile e instale seu kernel.
No arquivo /etc/fstab inclua um grupo para a montagem do sistema de arquivos /proc
(vamos usar o grupo adm com a GID 4):
Após reiniciar o sistema, execute o comando ls -lad /proc note que o grupo do diretório
/proc será modificado para adm. Agora entre como um usuário e execute um ps aux, so-
mente seus processos serão listados. Para autorizar um usuário específico ver todos os pro-
cessos (ter acesso novamente ao diretório /proc), inclua este no grupo que usou no arquivo
/etc/fstab:
Capítulo 19. Restrições de acesso, recursos e serviços 392
Após efetuar o usuário já estará pertencendo ao grupo adm (confira digitando groups), e
poderá ver novamente os processos de todos os usuários com o comando ps aux.
OBS1: Incluir um usuário no grupo adm É PERIGOSO, porque este usuário poderá ter acesso
a arquivo/diretórios que pertençam a este grupo, como os arquivos/diretórios em /var/log.
Se esta não é sua intenção, crie um grupo independente como restrproc para controlar quem
terá acesso ao diretório /proc: addgroup restrproc.
OBS2: Se a opção gid não for especificada para a montagem de /proc no /etc/fstab,
o grupo root será usado como padrão. NUNCA adicione usuários ao grupo root, use o
método da observação acima para permitir outros usuários ver todos os processos em exe-
cução.
OBS3 Caso o servidor identd esteja sendo usado na máquina servidora, será necessário roda-
lo com a mesma GID do diretório /proc para que continue funcionando. Se ele é executado
como daemon, adicione a opção -g GRUPO no script que inicia o serviço em /etc/init.d
e reinicie o daemon. Caso ele seja iniciado via inetd, faça a seguinte modificação no arquivo
/etc/inetd.conf (assumindo o uso do oidentd):
Veja ‘Servidor ident’ on page 241 para detalhes sobre este serviço.
tição.
7 Agora resta ativar o suporte as quotas de disco em todas as partições (-a) com recurso de
quota especificado (no /etc/mtab):
quotaon -augv
As opções possuem o mesmo significado do comando quotacheck. O utilitário
quotaoff serve para desativar quotas de usuários e usa as mesmas opções do quotaon.
Estes três utilitários somente podem ser usados pelo usuário root. As opções de quota
podem ser especificadas independente para cada sistema de arquivos:
# Ativa o suporte a quota em /pub (somente grupos de usuários no moment
quotaon -gv /pub
O programa edquota é usado pelo root para editar as quotas de usuários/grupos. Por
padrão, todos os usuários/grupos do sistema não possuem quotas. Sua sintaxe é a seguinte
edquota [opções] [usuário/grupo]
As opções podem ser:
-t Permite modificar o valor de tolerância dos limites que ultrapassam soft até que sejam blo-
queados. Durante o tempo de tolerância, serão enviados somente avisos sobre a quota
ultrapassada sem bloquear totalmente a gravação de arquivos (até que o limite hard seja
atingido ou o tempo de tolerância seja ultrapassado).
Quando a quota soft do usuário/grupo é estourada, a mensagem ”warning: user disk quota
excedeed“ será exibida. Quando a quota hard é ultrapassada, a gravação atual é interrompida
e a mensagem ”write failed, user disk limit reatched“ é mostrada ao usuário. Nenhuma nova
gravação que ultrapasse a quota hard é permitida Por exemplo, para modificar a quota do
usuário gleydson: edquota gleydson
O editor de textos usado poderá ser modificado através da variável $EDITOR. Abaixo a expli-
cação destes campos:
• Filesystem - Sistema de arquivos que terá a quota do usuário/grupo editada. As re-
strições se aplicam individualmente de acordo com o sistema de arquivos.
• blocks - Número máximo de blocos (especificado em Kbytes) que o usuário possui
atualmente. O usuário gleydson está usando atualmente 504944 Kbytes.
– soft - Restrição mínima de espaço em disco usado. Atualmente 500100 Kb.
– hard - Limite máximo aceitável de uso em disco para o usuário/grupo sendo ed-
itado. 600000 Kb atualmente. O sistema de quotas nunca deixará este limite ser
ultrapassado.
• inodes - Número máximo de arquivos que o usuário possui atualmente na partição
especificada. O usuário gleydson possui atualmente 10868 arquivos na partição /pub.
– soft - Restrição mínima de número de arquivos que o usuário/grupo possui no
disco. Atualmente em 15.000.
– hard - Restrição máxima de número de arquivos que o usuário/grupo possui no
disco. Atualmente em 20.000.
Para desativar as restrições coloque ”0“ no campo soft ou hard. Quando o limite soft é atingido,
o usuário é alertado por ter ultrapassado sua quota com a mensagem ”warning: user quota ex-
cedeed“ (quota do usuário excedida). O programa setquota é uma programa não-interativo
para edição de quotas para ser usado diretamente na linha de comando ou em shell scripts.
Após ultrapassar o limite soft, começa a contagem do tempo para que este passe a valer como
limite hard (o máximo aceitável e que nunca poderá ser ultrapassado). O comando edquota
-t serve para modificar estes valores na partição especificada:
Editar manualmente a quota de cada usuário é uma tarefa trabalhosa quando se está instalando
quotas e possui muitos usuários, existe uma maneira mais fácil de fazer isso usando o próprio
edquota e um usuário com a quota já definida. Por exemplo, instalamos quota em nosso
sistema e queremos que todos os 300 usuários tenham a quota de usuário de 10MB e de grupo
de 15MB:
1 Criamos um usuário com esta quota usando o edquota (como descrito em ‘Edi-
tando quotas de usuários/grupos’ on page 394). Como exemplo usaremos o usuário
teste_user. Use o comando quota teste_user para verificar se as quotas para este
usuário está correta.
2 Criamos um script que modifique a quota padrão de todos os usuários do sistema de
uma só vez:
Capítulo 19. Restrições de acesso, recursos e serviços 397
#!/bin/sh
cd /home
for USUARIO in *
do
edquota -u ${USUARIO} -p teste_user
done
Pronto, verifique a quota de todos os usuários com o comando repquota -a.
quota
quota -u usuario
quota -g users
Por motivos de segurança, você não poderá visualizar as quotas de outros usuários e grupos
que não pertence (exceto para o usuário root).
repquota -aug
Avisos sobre quota ultrapassada podem ser enviadas automaticamente a todos os usuários
pelo utilitário warnquota. Ele poderá ser executado periodicamente através do cron
(por padrão isto é feito diariamente na distribuição Debian pelo script /etc/cron.daily
/quota). Dados adicionais sobre o envio das mensagens devem ser especificados no arquivo
/etc/warnquota.conf seu formato é o seguinte:
O e-mail é enviado aos usuários (e usuários que pertencem a grupos com a quota excedida)
com o seguinte formato:
From: root@localhost
To: gleydson@debian.gms.com.br
Cc: root@localhost
Reply-To: root@localhost
Subject: Quota Excedida
Date: Sat, 22 Sep 2001 14:27:38 -0400
Hi,
We hope that you will cleanup before your grace period expires.
Basically, this means that the system thinks you are using more disk space
on the above partition(s) than you are allowed. If you do not delete files
and get below your quota before the grace period expires, the system will
prevent you from creating new files.
As restrições descritas aqui são úteis para diminuir as chances de um ataque por acesso físico
ser realizado com sucesso no sistema que desejamos proteger.
Ter um sistema totalmente seguro é praticamente impossível, mas existem diversas maneiras
de se dificultar as coisas.
Algumas restrições podem ser configuradas na para diminuir as chances de se obter acesso
root (usando métodos conhecidos de recuperação via disquete/CD inicializável) ou simples-
mente aumentar nossa confiança no sistema:
• Coloque uma senha para entrada no Setup da máquina, compartilhe esta senha somente
com as pessoas que tem poder de root (ou seja, pessoal de confiança que administra a
máquina).
• Mude a seqüencia de partida para somente sua unidade de disco rígido que contém o
sistema operacional. As BIOS trazem convenções de DOS para especificar o método de
partida, então Only C quer dizer somente o primeiro disco rígido, SCSI tentar disposi-
tivos SCSI primeiro, etc. Isso pode variar de acordo com o modelo de sua BIOS.
Com os dois ítens acima qualquer um ficará impedido de inicializar o sistema a partir de um
disco de recuperação ou entrar no Setup para modificar a ordem de procura do sistema opera-
cional para dar a partida via disquetes.
Como não é seguro confiar nas restrições de senha da BIOS (qualquer um com conhecimentos
de hardware e acesso físico a máquina pode abrir o gabinete e dar um curto na bateria que
mantém os dados na CMOS ou aterrar o pino de sinal da CMOS), a retirada da unidade de
disquetes é recomendada, isso dificultará bastante as coisas.
Evite a utilização de placas de rede com recursos de boot via EPROM no servidor, um servidor
dhcp/bootp/tftp poderá ser configurado sem problemas por um cracker na rede (caso a BIOS
esteja com a ordem inadequada de procura de discos) e o ataque se dar com mais ”sofisticação“
e rapidez.
Capítulo 19. Restrições de acesso, recursos e serviços 402
A opção passwd=senha e restricted poderão ser usadas na seção da imagem que desejamos pro-
teger. Respectivamente pedem uma senha para a inicialização do sistema e caso argumentos
como root=single sejam usados para conseguir acesso root sem fornecer senha.
E deixe somente as permissões de acesso ao usuário root (caso contrário sua senha poderá
ser vista por qualquer usuário) e modifique os atributos deste arquivo para imutável para que
nem mesmo o root possa modifica-lo: chattr +i /etc/lilo.conf.
O disco rígido do servidor poderá se retirado como alternativa para se ter acesso aos dados
armazenados. Isto poderá ser dificultado com o uso de lacres de disco ou outras maneiras de
dificultar mais esta tarefa (mais parafusos, armazenamento em partes de difícil manipulação
do HD, etc) qualquer coisa que possa lhe fazer ganhar tempo e despertar suspeitas para evitar
o sucesso desta alternativa (ousada).
Dados importantes ou confidenciais poderão ser armazenados em um sistema de arquivos
criptografados e serem montados somente pelos administradores que possuem acesso físico
ao sistema. O algoritmo Serpent é muito forte na proteção de dados além de possuir um ótimo
desempenho. Patches de criptografia poderão ser aplicados no kernel para ativação deste re-
curso (veja ‘Sistemas de arquivos criptográfico’ on page 406) para detalhes.
Sensores podem ser ligados na carcaça do HD como forma de disparar um pequeno alarme
embutido no gabinete do servidor, se você gosta de eletrônica poderá montar um destes facil-
mente para chamar a atenção alimentado por fonte/baterias em um circuito de emergência, e
poderá acomodar sua caixa em uma segunda ”carcaça de fonte“ apenas para desviar suspeitas.
Um circuito interno de câmeras também é uma boa alternativa para monitorar a movimen-
tação.
Esquemas de segurança dependendo do porte da organização e dos dados que se desejam
proteger deverão ser elaborados e postos em prática. Todos os métodos imagináveis deverão
ser considerados de acordo com as possibilidades do ambiente.
403
Capítulo 20
Este capítulo explica como dados transmitidos em uma rede pode ser capturados, isto ajudará
a entender a vulnerabilidade de serviços comuns que não utilizam criptografia para a transmis-
são de dados e alternativas/programas equivalentes que fazem transmissão de dados usando
métodos criptográficos para deixar a mensagem somente legível para origem e destino.
20.1 Introdução
Quando enviamos um tráfego de nossa máquina para outra (e-mails, mensagens de ICQ, nave-
gação, ftp, etc) os dados passam por várias máquinas até atingir o seu destino (isto se chama
roteamento). Se algum cracker instalou algum capturador de pacotes (sniffer) em alguma das
máquinas de nossa rota os dados poderão facilmente visualizados.
Crackers normalmente configuram estes programas a procura de campos como ”passwd“ e
outras expressões que sejam úteis para acesso ao seu sistema ou espionagem. Quem gosta
de ter sua privacidade violada? A internet definitivamente é uma rede insegura e nem todos
os administradores de servidores são responsáveis o suficiente para fazer uma configuração
restrita para evitar acesso de pessoas mal intencionadas.
Este capítulo mostra (na prática) como um sniffer funciona para captura de pacotes, isto aju-
dará a entender como serviços que enviam seus dados em forma texto plano são vulneráveis a
isto e alternativas para transmissão segura de dados. Este capítulo tem a intenção de mostrar
alternativas seguras de proteção dos dados que trafegam em sua rede e a segurança de suas
instalações.
20.2 Sniffer
obtenção de detalhes úteis para solução de problemas em rede (quando usado com boas in-
tenções pelo administrador do sistema) ou para ataques ao sistema (quando usado pelo cracker
para obter nomes/senhas e outros detalhes úteis para espionagem).
Os sniffers mais conhecidos para sistemas Linux são tcpdump, ethereal. Este último ap-
resenta uma interface gráfica GTK para fácil operação em máquinas que executam o servidor
X. Para explicar o funcionamento de um sniffer, vou assumir o ethereal instalado (ele não
requer modificações no sistema além de ser fácil de executar e fazer pesquisa de expressões
específicas). Instale o ethereal com o comando apt-get install ethereal.
Agora vamos a prática para entender como o sniffer funciona e a importância da criptografia
de dados (só assim mesmo, não da para entender falando muita teoria :-):
1 Conecte-se a Internet
2 Execute o ethereal como usuário root.
3 Pressione CTRL+K para abrir a tela de captura de pacotes. Em Interface selecione sua
interface de internet. Nesta tela clique no botão ”FILE“ e coloque um nome de arquivo
que a captura será gravada. Opcionalmente marque a opção ”Update list of packets in
real time“ para monitorar a passagem de pacotes em tempo real.
4 Clique em ”OK“. A captura de pacotes será iniciada
5 Conecte-se a um site ftp qualquer (digamos ftp.debian.org.br). Entre com o usuário
”anonymous“ e senha ”minhasenha@segura.com.br“
6 Finalize a captura de pacotes clicando no botão ”STOP“
Agora vá em ”File“/”Open“ e abra o arquivo capturado. Ele está no formato usado pelo sniffer
tcpdump como padrão. Procure no campo ”INFO“ a linha ”Request: USER anonymous“, logo
abaixo você verá a senha digitada pelo usuário. Entendeu agora a importância da criptografia
na transferência segura de dados? não só o nome/senha pode ser capturado mas toda a seções
feitas pelo usuário. Scanners como o tcpdump e ethereal são flexivelmente configuráveis
para procurar por dados específicos nas conexões e salva-los para posterior recuperação.
Uma característica comum de sniffers é mudar o modo de operação das interfaces monitoradas
para o ”Modo Promíscuo“ com o objetivo de analisar todo o tráfego que passa por aquele
segmento de rede (mesmo não sendo destinados para aquela máquina).
A entrada/saída de interfaces no modo promíscuo é monitorada nos logs do sistema:
O logcheck monitora estas atividades e classificam esta mensagem como prioridade ”Vio-
lação“ (dependendo da configuração dos seus filtros em /etc/logcheck. Veja ‘logcheck’ on
page 81 para detalhes sobre este programa.
OBS: A utilização de switches dificulta a captura de pacotes em redes distribuídas porque
somente os dados destinados a máquina onde o sniffer está instalado poderão ser capturados.
Capítulo 20. Introdução ao uso de criptografia para transmissão/armazenamento de dados405
20.3.1 http
A alternativa mais segura é a utilização do protocolo IMAP com suporte a ssl. Nem todos os
clientes de e-mail suportam este protocolo.
Ao invés do ftp, use o scp ou o sftp para transferência segura de arquivos. Veja ‘scp’ on
page 257 e ‘sftp’ on page 258. Uma outra alternativa é a configuração de uma VPN entre redes
para garantir não só a transferência de arquivos, mas uma seção em cima de um tunel seguro
entre duas pontas.
Ao invés do uso do rlogin, telnet e rsh utilize o ssh (veja ‘ssh’ on page 255) ou o telnet
com suporte a ssl (veja ‘Instalação’ on page 248).
O programa SILC (Secure Internet Live Conference) realiza a criptografia de dados durante o
bate papo entre diversos usuários conectados via rede.
O protocolo ICQ trabalha de forma plana para transmissão de suas mensagens, inclusive as
senhas. Clientes anteriores ainda usavam o UDP (até a versão 7) para envio de mensagens,
piorando um pouco mais a situação e deixando o cliente mais vulnerável a falsificações de
pacotes. Outro ponto fraco é que se alguma coisa acontecer com os pacotes UDP, eles serão
simplesmente descartados perdendo a mensagem.
Ao invés do ICQ, você poderá usar algum cliente do protocolo Jabber (como o gaim, gaber
ou gossip) ou o LICQ mais atual com suporte a ssl compilado. O problema do LICQ com ssh,
é que as duas pontas deverão ter este suporte compilado e funcionando.
Esta é uma forma excelente para armazenamento seguro de seus dados, pois estarão crip-
tografados e serão somente acessados após fornecer uma senha que só você conhece. O sistema
usado é a montagem de um arquivo comum como um sistema de arquivos via loopback você
pode escolher um nome de arquivo discreto para dificultar sua localização (use a imaginação)
e poderá ser armazenado até mesmo em partições não-ext2. Siga estes passos para criar seu
sistema de arquivos criptografado (baseado no Loopback-Encripted-Filesystem):
Capítulo 20. Introdução ao uso de criptografia para transmissão/armazenamento de dados407
Monte o sistema de arquivos Crie um diretório que será usado para montagem do seu sis-
tema de arquivos, se preferir monta-lo dentro de seu diretório pessoal para armazenar
seus arquivos, crie um diretório com as permissões ”0700“.
mount /pub/swap-fs /pub/criptofs -t ext2 -o loop
Agora poderá gravar seus arquivos dentro deste diretório normalmente como qualquer
outro. O comando df -hT listará a partição loop como uma partição do tipo ext2 co-
mum.
Desmontando/Protegendo os dados Após usar o sistema de arquivos criptográfico,
desmonte-o e desative o dispositivo loopback:
umount /pub/criptofs
losetup -d /dev/loop0
Será pedida a senha que escolheu e seu sistema de arquivos será montado em /pub
/swap-fs.
Com este sistema, seus dados estarão protegidos mesmo do usuário root.
O gpg (GNU pgp, versão livre da ferramenta pgp) permite encriptar dados, assim somente
o destinatário terá acesso aos dados, adicionalmente poderá verificar se a origem dos da-
dos é confiável (através da assinatura de arquivos). O sistema PGP se baseia no con-
ceito de chave pública e privada: Sua chave pública é distribuída para as pessoas que de-
seja trocar dados/mensagens e a chave privada fica em sua máquina (ela não pode ser dis-
tribuída). As chaves públicas e privadas são armazenadas nos arquivos pubring.gpg e
secring.gpg respectivamente, dentro do subdiretório ~/.gnupg. Veja ‘Criando um par de
chaves pública/privada’ on the next page para criar este par de chaves.
Os dados que recebe de outra pessoa são criptografados usando sua chave pública e somente
você (de posse da chave privada) poderá desencriptar os dados. Quando assina um arquivo
usando o pgp, ele faz isto usando sua chave privada, o destinatário de posse da chave pública
poderá então confirmar que a origem dos dados é confiável.
O gpg vem largamente sendo usado para transmissão segura de dados via internet. Muitos
programas de e-mails como o mutt e sylpheed incluem o suporte a pgp embutido para envio
de mensagens assinadas/encriptadas (MIME não tem uma codificação segura e não garante
que a mensagem vem de quem realmente diz ser). Um servidor de e-mail no Linux config-
urado como as mesmas configurações/endereços do provedor da vítima pode enganar com
sucesso um usuário passando-se por outro.
Capítulo 20. Introdução ao uso de criptografia para transmissão/armazenamento de dados409
Para gerar um par de chaves pessoais use o comando gpg --gen-key. Ele executará os
seguintes passos:
1 Chave criptográfica - Selecione DSA e ELGamal a não ser que tenha necessidades
específicas.
2 Tamanho da chave - 1024 bits traz uma boa combinação de proteção/velocidade.
3 Validade da chave - 0 a chave não expira. Um número positivo tem o valor de dias,
que pode ser seguido das letras w (semanas), m (meses) ou y (anos). Por exemplo, ”7m“,
”2y“, ”60“. Após a validade, a chave será considerada inválida.
4 Nome de usuário - Nome para identificar a chave
5 E-mail - E-mail do dono da chave
6 comentário - Uma descrição sobre a chave do usuário.
7 Confirmação - Tecle ”O“ para confirmar os dados ou uma das outras letras para modi-
ficar os dados de sua chave.
8 Digite a FraseSenha - Senha que irá identificá-lo(a) como proprietário da chave pri-
vada. É chamada de FraseSenha pois pode conter espaços e não há limite de carac-
teres. Para alterá-la posteriormente, siga as instruções em ‘Mudando sua FraseSenha’
on page 412.
9 Confirme e aguarde a geração da chave pública/privada.
gpg -e arquivo.txt
Será pedida a identificação de usuário, digite o nome que usou para criar a chave. O arquivo
criado será encriptado usando a chave pública do usuário (~/.gnupg/pubring.gpg) e terá a
extensão .gpg adicionada (arquivo.txt.gpg). Além de criptografado, este arquivo é com-
pactado (recomendável para grande quantidade de textos). A opção -a é usada para criar um
arquivo criptografado com saída ASCII 7 bits:
gpg -e -a arquivo.txt
O arquivo gerado terá a extensão .asc acrescentada (arquivo.txt.asc) e não será com-
pactado. A opção -a é muito usada para o envio de e-mails.
Capítulo 20. Introdução ao uso de criptografia para transmissão/armazenamento de dados410
Para criptografar o arquivo para ser enviado a outro usuário, você deverá ter a chave pública
do usuário cadastrado no seu chaveiro (veja ‘Adicionando chaves públicas ao seu chaveiro pes-
soal’ on the next page) e especificar a opção -r seguida do nome/e-mail/ID da chave pública:
O exemplo acima utiliza a chave pública de kov para encriptar o arquivo arquivo.txt (so-
mente ele poderá decriptar a mensagem usando sua chave privada).
OBS: É recomendável especificar o nome de arquivo sempre como último argumento.
Agora vamos fazer a operação reversa da acima, a opção -d é usada para decriptar os dados
usando a chave privada:
Assinar um arquivo é garantir que você é a pessoa que realmente enviou aquele arquivo. Use
a opção -s para assinar arquivos usando sua chave privada:
gpg -s arquivo.txt
A ”FraseSenha“ será pedida para assinar os dados usando sua chave privada. Será gerado
um arquivo arquivo.txt.gpg (assinado e compactado). Adicionalmente a opção –clearsign
poderá ser usada para fazer uma assinatura em um texto plano, este é um recurso muito usado
por programas de e-mails com suporte ao gpg:
Será criado um arquivo chamado arquivo.txt.asc contendo o arquivo assinado e sem com-
pactação.
Capítulo 20. Introdução ao uso de criptografia para transmissão/armazenamento de dados411
A checagem de assinatura consiste em verificar que quem nos enviou o arquivo é realmente
quem diz ser e se os dados foram de alguma forma alterados. Você deverá ter a chave pública
do usuário no seu chaveiro para fazer esta checagem (veja ‘Adicionando chaves públicas ao
seu chaveiro pessoal’ on this page). Para verificar os dados assinados acima usamos a opção
–verify:
Se a saída for ”Assinatura Correta“, significa que a origem do arquivo é segura e que ele não
foi de qualquer forma modificado.
Se a saída for ”Assinatura INCORRETA“ significa que ou o usuário que enviou o arquivo não
confere ou o arquivo enviado foi de alguma forma modificado.
Sua chave pública deve ser distribuída a outros usuários para que possam enviar dados crip-
tografados ou checar a autenticidade de seus arquivos. Para exportar sua chave pública em
um arquivo que será distribuído a outras pessoas ou servidores de chaves na Internet, use a
opção –export:
Ao invés do nome do usuário, poderá ser usado seu e-mail, ID da chave, etc. A opção -a
permite que os dados sejam gerados usando bits ASCII 7.
Use o comando gpg --list-keys para listar as chaves pública do seu chaveiro. O comando
gpg --list-secret-keys lista suas chaves privadas.
Quando uma chave pública é modificada ou por qualquer outro motivo deseja retira-la do seu
chaveiro público, utilize a opção –delete-key:
Pode ser especificado o nome de usuário, e-mail IDchave ou qualquer outro detalhe que confira
com a chave pública do usuário. Será pedida a confirmação para excluir a chave pública.
OBS: A chave privada pode ser excluída com a opção –delete-secret-key. Utilize-a com o máximo
de atenção para excluir chaves secretas que não utiliza (caso use mais de uma), a exclusão
acidental de sua chave secreta significa é como perder a chave de um cofre de banco: você não
poderá descriptografar os arquivos enviados a você e não poderá enviar arquivos assinados.
Mesmo assim se isto acontecer acidentalmente, você poderá recuperar o último backup da
chave privada em ~/.gnupg/secring.gpg~.
A assinatura de chaves é um meio de criar laços de confiança entre usuários PGP. Assinar uma
chave de alguém é algo sério, você deve ter noção do que isto significa e das conseqüências
que isto pode trazer antes de sair assinando chaves de qualquer um.
O próprio teste para desenvolvedor da distribuição Debian requer como primeiro passo a
identificação do candidato, caso sua chave pgp seja assinada por algum desenvolvedor desta
distribuição, imediatamente o teste de identificação é completado. A partir disso você deve ter
uma noção básica do que isto significa. Para assinar uma chave siga os seguintes passos:
1 Importe a chave pública do usuário (veja ‘Adicionando chaves públicas ao seu chaveiro
pessoal’ on the previous page).
Capítulo 20. Introdução ao uso de criptografia para transmissão/armazenamento de dados413
Execute o comando gpg --list-sigs para listas todas as assinaturas existentes no seu
chaveiro. Opcionalmente pode ser especificado um parâmetro para fazer referência a assi-
natura de um usuário:gpg --list-sigs usuario.
O comando gpg --check-sigs adicionalmente faz a checagem de assinaturas.
Este texto foi divulgado por uma pessoa que pediu para permanecer anônima na lista
<debian-user-portuguese@lists.debian.org> explicando os procedimentos de se-
gurança para a troca de chaves públicas individuais e em grupo de usuários. Ele é um pouco
longo mas a pessoa é especializada no assunto, e seu foco é a segurança na troca de chaves
e o que isto significa. Após consulta ao autor do texto, o texto foi reproduzido na íntegra,
mantendo os padrões de formatação da mensagem.
1. Assinaturas digitais
2. Chaves digitais e a teia de confiança
3. Trocando assinaturas de chaves digitais com um grupo de pessoas
1. Assinaturas digitais
Existe uma relação direta entre uma assinatura e informação que ela assina.
Se uma das duas for modificada, elas passam a não mais "combinar" uma com a
a outra. Um programa de computador pode detectar isso, e avisar que a
assinatura é "inválida".
Chaves digitais são fáceis de falsificar, você só precisa criar uma chave
nova no nome de sicrano, por um endereço de e-mail novinho em folha daqueles
que você consegue nesses webmail da vida, e pronto. Agora é só espalhar
essa chave por aí que os bestas vão usá-la pensando que é de sicrano.
A menos que os "bestas" não sejam tão bestas assim, tenham lido o manual do
seu software de criptografia, e saibam usar assinaturas e a teia de
confiança para verificar se a tal chave é de sicrano mesmo.
Se todo mundo fizer isso direitinho (ou seja, não sair assinando a chave de
qualquer um, só porque a outra pessoa pediu por e-mail, ou numa sala de
chat), cria-se a chamada teia de confiança.
Numa teia de confiança, você confia na palavra de honra dos outros para
tentar verificar se uma chave digital é legítima, ou se é uma "pega-bobo".
Suponha que Marcelo tenha assinado a chave de Cláudia, e que Roberto, que
conhece Marcelo pessoalmente e assinou a chave de Marcelo, queira falar com
Cláudia.
Roberto sabe que Marcelo leu o manual do programa de criptografia, e que ele
não é irresponsável. Assim, ele pode confiar na palavra de honra de Marcelo
que aquela chave digital da Cláudia é da Cláudia mesmo, e usar a chave pra
combinar um encontro com Cláudia.
Por outro lado, Roberto não conhece Cláudia (ainda), e não sabe que tipo de
pessoa ela é. Assim, rapaz prevenido, ele não confia que Cláudia seja uma
pessoa responsável que verifica direitinho antes de assinar chaves.
O uso da assinatura feita por alguém cuja chave você assinou, para validar
a chave digital de um terceiro, é um exemplo de uma pequena teia de
confiança.
Lembre-se: ao assinar uma chave digital, você está empenhando sua palavra de
honra que toda a informação que você assinou naquela chave é verdadeira até
onde você pode verificar, _e_ que você tentou verificar direitinho.
Sim, é sério desse jeito mesmo. Você pode ficar muito "queimado" em certos
círculos se você assinar uma chave falsa, pensando que é verdadeira: a sua
assinatura mal-verificada pode vir a prejudicar outros que confiaram em
você.
Bom, já que o assunto é sério, como juntar um grupo de pessoas numa sala, e
trocar assinaturas de chaves entre si? Particularmente se são pessoas que
você nunca viu antes? Siga o protocolo abaixo, passo a passo, e sem pular ou
violar nenhum dos passos.
3 - Pronto. Podem ir embora, porque o resto dos passos deve ser feito com
calma, em casa. Lembre-se que você não vai estar efetuando nenhum
julgamento moral a respeito de quem você assinar a chave. Você só irá
afirmar que a chave de sicrano é realmente aquela, e mais nada.
4 - Para cada uma das chaves que você marcou no papel que "posso assinar":
4.2 - As informações não bateram, por isso você não deve assinar a
chave. Se quiser, envie um e-mail avisando que não poderá
assinar a chave. Não aceite tentativas de retificação por
e-mail ou telefone. Um outro encontro face-à-face, refazendo
todos os passos 2.1 e 2.2 é o único jeito de retificar
o problema.
Capítulo 21
Apêndice
O guia Foca foi criado em 12 de Novembro de 1999. A versão que está lendo tem o obje-
tivo de servir como referência a usuários Avançados que já dominam grande parte do sis-
tema operacional e procuram aprender mais sobre os seus detalhes e configurações especi-
ais ou com referência de consulta rápida. Uma versão que abrange um diferente nível de
aprendizado ou mais completa pode ser baixada de Página Oficial do guia Foca GNU/Linux
(http://www.guiafoca.org).
A versão que esta lendo agora foi gerada com as seguintes opções:
• Descrição detalhada de comandos
• Opções usadas em comandos e programas
• Observações sobre comandos e configurações
• Exemplos para a melhor compreensão do assunto discutido.
e contém o(s) nível(is) de aprendizado (Iniciante, Intermediário e Avançado):
• Avançado
O Foca GNU/Linux é atualizado frequentemente, por este motivo recomendo que assine um
dos canais de comunicação para ser informado de novas versões:
• Assinar o Twitter do focalinux <@focalinux>
• Assinar o RSS presente na página do guia e atualizações.
• A ficha do aviso de atualizações na página web em Página Oficial do guia Foca
GNU/Linux (http://www.guiafoca.org) no fim da página principal. Após
preencher a ficha do aviso de atualizações, eu te enviarei um e-mail sobre o lançamento
de novas versões do guia e o que foi modificado, desta forma você poderá decidir em
copia-la caso a nova versão contém modificações que considera importantes.
Versões diferentes deste guia podem ser geradas a partir do código fonte SGML ou obtidas
através da home page principal (para detalhes veja ‘Onde encontrar a versão mais nova do
guia?’ on page 421).
Capítulo 21. Apêndice 420
Gleydson Mazioli da Silva é Capixaba, nascido em Vila Velha. Amante de eletrônica desde
criança, foi atraido para a informática através da curiosidade em funcionamento e reparo de
hardware.
Se dedica ao sistema Linux desde 1997. determinado na realização de testes de ferramentas e
sistemas avaliando pontos fortes e fracos de cada uma. Logo que iniciou em Linux passou a
estudar exaustivamente aspectos técnicos de distribuições e rede em Linux/BSD.
Entre coisas que gosta de fazer/implementar em Linux: possibilidade de pesquisa e atual-
ização de conhecimento constante, automatização e tomada inteligente de decisões, níveis de
segurança da informação (tanto físico e lógico), firewalls, virtualização, redes virtuais, inte-
gração de sistemas, forense computacional, documentação de processos, desenvolvimento de
ferramentas GPL para a comunidade, depuração, desenvolvimento de documentações, etc.
Um dos desenvolvedores da distribuição Liberdade, CAETECT, Debian-BR e desenvolvedor ofi-
cial da distribuição Debian. Atuou como tradutor do LDP-BR, traduzindo vários HOW-TOs im-
portantes para a comunidade Linux Brasileira. É um dos administradores do projeto CIPSGA,
cuidando de uma infinidade de serviços que o projeto oferece a comunidade que deseja estru-
tura para hospedar, fortalecer e manter projetos em software livre.
Trabalhou para algumas empresas do Espírito Santo, no Governo Federal e de estados na im-
plantação de sistemas em software livre. Atualmente atua como gerente de tecnologia da Spirit
Linux, uma empresa focada na inovação, avaliação e integração de ferramentas de código
aberto junto a seus clientes.
Concorda com certificações, mas destaca que o mais importante é aproveitar a oportunidade
dada pela certificação para estudo e auto avaliação de seus pontos fracos e assim procurar
melhora-los. Possui certificação LPI nível 3 e um ISO9001 internacional em Administração
Linux, como primeiro no ranking Brasileiro.
E-mail: E-mail: <gleydson@guiafoca.org>, Twitter: <@gleydsonmazioli>.
• As seções do nível avançado foram construídas com base em testes e usando metodologia
própria com o objetivo de oferecer uma documentação objetiva e clara ao administrador
de rede, auxiliando-o na tomada de decisões para solução de problemas. Partes extraidas
de outras documentações no nível Avançado terão as referências explicitamente citadas
em seus respectivos capítulos.
• Manual de Instalação da Debian GNU/Linux - Os capítulos contendo materiais extraídos
do manual de instalação da Debian são muito úteis e explicativos, seria desnecessário
reescrever um material como este. O texto é claro e didaticamente organizado, o docu-
mento aborda detalhes técnicos úteis sobre hardwares em geral e o Linux ausentes nos
manuais de outras distribuições Linux.
Novas versões deste guia, avisos de lançamento, outros níveis de aprendizado (Iniciante, In-
termediário e Avançado), versões para outras distribuições Linux podem ser encontradas em:
Página Oficial do guia Foca GNU/Linux (http://www.guiafoca.org).
Se quiser receber notificações de novas versões, use uma das formas a seguir:
• por E-Mail: envie uma mensagem para <gleydson@guiafoca.org> pedindo para ser
incluído na lista de atualizações do guia ou preencha o formulário encontrado no final
da Home Page do guia.
• Twitter: Assine o Twitter do guia Foca: @focalinux
• RSS: Assine o RSS na página oficial do guia (citado acima) para receber atualizações e
novidades.
Todas as marcas registradas citadas neste guia são propriedades de seus respectivos autores.
• Entre outros ítens que venho estudando para verificar se encaixam no perfil do guia.
Esta é uma futura implementação que venho estudando para acompanhar o crescimento do
guia. Sugestões são bem vindas e podem ser enviadas para <gleydson@guiafoca.org>.
Capítulo 21. Apêndice 423
Chaves PGP são usadas para criptografar arquivos, e-mails ou qualquer outra coisa que
desejamos que somente uma pessoa tenha acesso. O PGP segue o padrão de chave
pública/privada; a chave pública é distribuída a todos e a chave privada permanece na posse
do criador para que ele seja o único a ter acesso aos dados criptografados após digitar a ”frase
de acesso“ correta.
Minha chave PGP segue abaixo, ela também pode ser encontrada em http://pgp.ai.mit.
edu. Se você deseja saber mais sobre o PGP, recomendo um excelente documento encontrado
na seção Apostilas em http://www.cipsga.org.br/
mQGiBDl7WYgRBACsQNtIozvf8XId+xEpF2D1x7nqgFdJyn1QA2VzXg0/OZ9DewXj
qr7ChEIoyyzAmxBSubE/jdtkAb9+2LsE9+OXgzJvBc4luYpv+HG2IXlMPujI9drO
ubLlK6xqPiakBgqBTS74rp/ZEEAGQsr0sug7b8nsXHMk+spyGkjsU8pPWwCgltai
4vfmBDMZMqBYvUoksVxbaKcD/ApAMghgE53KAAKFtwXI0o7K1DJmdZBufCvGDbEB
Y3MVS4BI+aXxoP5zQpEmQ5+lYOZ8RjPL9pNUJa9nOQtjf7Kiw/41BPDtlZXCeRR5
OcQTit0lYRCLGam7FZ22uliwh0h/3lpf4olMff3qeLqv1DECbo8Qsdn6yxynLihE
OA9kA/9K1sqiIl/+gXM3/Sjz8EcrwQNklV3MoaETbDmukbXcOEUjdqfFr1xARM5W
8SKoVrWO5y1oa1e9XcQuK6g8c7KeJsK/GEWYiRwX2X2AqdBC2ZzVfJSmgpguZJHn
ltMdYZhPwZaCsNPdQSlem3UrGupL0pbpT7PqkvyAHBH2itB9X7RKR2xleWRzb24g
TWF6aW9saSBkYSBTaWx2YSAoQ2hhdmUgUEdQIFBlc3NvYWwpIDxnbGV5ZHNvbkBl
c2NlbHNhbmV0LmNvbS5icj6IVgQTEQIAFgUCOXtZiAQLCgQDAxUDAgMWAgECF4AA
CgkQpWvD35hbooFdwgCfQijPTW5VH+Cep1HIBvyuw9uMg7wAoI/RYW0tkjjnhrgH
8+Zqx6AgGlQ/iEYEEBECAAYFAjnlrPAACgkQoUSye+uc2tWZPgCfVgR4lbd8XPBm
bjPupLzB3EYAPI8AoJomkfsgz+NuUZy1mD6pI1Ptc/fDiEYEEBECAAYFAjm4FfUA
CgkQco65AkzGCoF34gCgsVcH4b3s6kfCtjD7iMMhkubnDnUAoL2UiorB3Z/m3f9A
RZiRMhQUclMRiEYEEBECAAYFAjm4ITAACgkQt1anjIgqbEupXgCg1/NjvT562Hgt
/ft5JETOf3yOFywAn1SmK3unyhMU5GU9d49MNM3fNgBtiEYEEBECAAYFAjnFWrYA
CgkQORwuc54x+1t8VQCeMZTCla98rrI60EnlkAvb9AaScm4AnA4V795vcVlr3ix9
f6fcl5YGamKciEYEEBECAAYFAjvSF6sACgkQUZATEoypqPVQ7wCbBTRiSGGMzMTd
KJotfRKf5aoUAr0AoIAX0oE5XEEFm7Ea0IQqG91T9TvXtDtHbGV5ZHNvbiBNYXpp
b2xpIGRhIFNpbHZhIChEZXZlbG9wZXIpIDxnbGV5ZHNvbkBkZWJpYW4ub3JnPohX
BBMRAgAXBQI7BR7fBQsHCgMEAxUDAgMWAgECF4AACgkQpWvD35hbooESRACcCliY
yxR02KEBYs8cxKav9L0wlzwAn2Z9DWAbqi9Mv4fqPqZ7mViSMRbeiEYEEBECAAYF
AjsauX0ACgkQt1anjIgqbEvBEACffJxYfK22YPQ8ZkcjIc85BCiPLuUAnRq1EE9i
ukdUHPUo0vzHBeiN355miEYEEBECAAYFAjxEY28ACgkQGERS+iaKCE2fgwCeNGNV
Mpa1EWgXF+Hj15gidVjaVCAAn187X6eATJAVzspveNSf/Ny1iuFnuQENBDl7WasQ
BACxhBiSFOGa8tv7MOn0XVa6WCViBuQs9QJx2ZnMrx/KssRHMsNXnps+i+zVENqr
1Lz5zPpP7eWgrUy6B7/V9R4LV8nwHC1lZrR/1xyJ6G5j9RLSbYInZCLIAFUMlAar
iTThMhvXM+Pf7SXPj+ivrP9EYPSLxqTs1K/dWAbrDK/QiwADBQP9Hgc3EOw+7luB
/bXWssQp70bF9yvZLCGOgIE/rZIbOXumXkPlV7FTDgv+h47Bgcj2KDPEM98LUyxG
Capítulo 21. Apêndice 424
GcJAmrC9gWH7mYEUFNn1bGD+qHRwJ7+xj45NXBJDOBbHzTDS8QhacCRGW1CvRVgP
8ycPDOv/hmGfAJEzqzUkSO1uBcPmmXSIRgQYEQIABgUCOXtZqwAKCRCla8PfmFui
gQHnAJ4kDKHKvG9s9OjGV6RvszTDGE51igCcCZn0rO/Si0ek97bTCIusQzJF/pA=
=bvnT
-----END PGP PUBLIC KEY BLOCK-----