Red Hat Training
A Red Hat training course is available for Red Hat Enterprise Linux
Guia de Segurança
Um Guia para Proteger o Red Hat Enterprise Linux
Edição 1.5
Red Hat Inc.
Resumo
Capítulo 1. Visão Geral da Segurança
Nota
/lib
. Se estiver usando os sistemas 64 bits, alguns dos arquivos mencionados podem estar localizados no /lib64
.
1.1. Introdução à Segurança
1.1.1. O que é Segurança de Computadores?
1.1.1.1. Como a Segurança de Computadores começou?
1.1.1.2. A Segurança Hoje
- Em qualquer dia, existem aproximadamente 225 importantes incidências de brecha de segurança reportadas ao CERT Coordination Center at Carnegie Mellon University.[6]
- O número de incidentes reportados no CERT pulou de 52,658 em 2001, 82,094 em 2002 e para 137,529 em 2003.[7]
- De acordo com o FBI, crimes relacionados à computadores custou às empresas americanas $67.2 bilhões de dólares em 2006.[8]
- Apenas 23% dos que responderam possuem políticas para o uso das tecnologias de Web 2.0. Estas tecnologias, como Twitter, Facebook e LinkedIn podem oferecer uma maneira conveniente para empresas e individuais se comunicarem e colaborar, entretanto elas abrem novas vulnerabilidades, primariamente o vazamento de dados confidenciais.
- Mesmo durante a recente crise financeira de 2009, a pesquisa constatou que os orçamentos com segurança estavam no mesmo nível ou em crescimento em relação aos anos anteriores (aproximadamente 2 de cada 3 participantes esperam aumentar ou manter o mesmo nível). Isto é uma boa notícia e reflete a importância que organizações estão dando na segurança da informação hoje.
1.1.1.3. Padronização da Segurança
- Confidencialidade — Informações sensíveis devem estar disponíveis somente para um conjunto de indivíduos pré definidos. Transmissão não autorizada e uso da informação devem ser restritos. Por exemplo, a confidencialidade da informação garante que uma informação pessoal ou financeira não seja obtida por um indivíduo não autorizado para propósitos maliciosos tais como roubo de identidade ou fraude de crédito.
- Integridade — As informações não devem ser alteradas de modo a torna-las incompletas ou incorretas. Usuários não autorizados devem ser restritos da possibilidade de modificar ou destruir informações sensíveis.
- Disponibilidade — As informações devem ser acessíveis a usuários autorizados em qualquer momento que seja necessário. Disponibilidade é uma garantia que a informação pode ser obtida com acordos de frequência e pontualidade. Isto é frequentemente medido em termos de porcentagens e definido formalmente em Acordos de Nível de Serviço (SLAs) usados por provedores de serviços de redes e seus clientes corporativos.
1.1.2. SELinux
1.1.3. Controles de Segurança
- Físico
- Técnico
- Administrativo
1.1.3.1. Controles Físicos
- Cameras de vigilância de circuito interno
- Sistemas de alarmes térmicos ou de movimento
- Guardas de Segurança
- IDs com fotos
- Portas de aço bloqueadas com parafusos sem cabeça
- Biometria (inclui impressão digital, voz, rosto, íris, manuscrito e outros métodos automatizados usados para reconhecer indivíduos)
1.1.3.2. Controles Técnicos
- Criptografia
- Cartões Smart
- Autenticação de rede
- Listas de Controle de Acesso (ACLs)
- Software de auditoria de integridade de arquivos
1.1.3.3. Controles Administrativos
- Treinamento e conscientização
- Prevenção de desastres e planos de recuperação
- Estratégias de recrutamento de pessoal e de separação
- Registro de pessoal e de contabilidade
1.1.4. Conclusão
1.2. Avaliação de Vulnerabilidade
- A perícia do pessoal responsável pela configuração, monitoramento e manutenção das tecnologias.
- A habilidade de corrigir e atualizar serviços e kernels rapidamente e eficientemente.
- A habilidade daqueles responsáveis em manter constante vigilância sobre a rede.
1.2.1. Pensando Como o Inimigo
1.2.2. Definindo a Avaliação e Testes
Atenção
- Cria um foco pró ativo na segurança da informação
- Encontra potenciais explorações antes que os invasores as encontrem
- Resulta em sistemas sendo atualizados e corrigidos
- Promove o crescimento e ajuda no desenvolvimento das habilidades dos funcionários
- Reduz perdas financeiras e publicidade negativa
1.2.2.1. Estabelece uma Metodologia
- http://www.isecom.org/osstmm/ The Open Source Security Testing Methodology Manual (OSSTMM)
- http://www.owasp.org/ The Open Web Application Security Project
1.2.3. Avaliando as Ferramentas
1.2.3.1. Escaneando Hosts com o Nmap
1.2.3.1.1. Usando o Nmap
nmap
seguido pelo nome do host ou endereço de IP da máquina a ser escaneada.
nmap foo.example.com
Interesting ports on foo.example.com: Not shown: 1710 filtered ports PORT STATE SERVICE 22/tcp open ssh 53/tcp open domain 80/tcp open http 113/tcp closed auth
1.2.3.2. Nessus
Nota
1.2.3.3. Nikto
1.2.3.4. Antecipar Suas Futuras Necessidades
1.3. Invasores e Vulnerabilidades
1.3.1. Uma Rápida História sobre Hackers
1.3.1.1. Tons de cinza
1.3.2. Ameaças à Segurança de Rede
1.3.2.1. Arquiteturas Inseguras
1.3.2.1.1. Redes de Transmissão
1.3.2.1.2. Servidores Centralizados
1.3.3. Ameaças à Segurança do Servidor
1.3.3.1. Serviços não usados e Portas Abertas
1.3.3.2. Serviços sem Correção
1.3.3.3. Administração Desatenta
1.3.3.4. Serviços Essencialmente Inseguros
1.3.4. Ameaças à Estação de Trabalho e Segurança no PC doméstico.
1.3.4.1. Senhas Ruins
1.3.4.2. Aplicações Clientes Vulneráveis
1.4. Explorações Comuns e Ataques
Tabela 1.1. Explorações Comuns
Exploração | Descrição | Notas | |||
---|---|---|---|---|---|
Senhas Nulas ou Padrão | Deixar as senhas administrativas em branco ou usar um conjunto de senhas padrões definidas pelo fabricante do produto. Isto é mais comum em hardwares como routers e firewalls, embora alguns serviços aplicados no LInux possam conter senhas de administração padrão (embora o Red Hat Enterprise Linux não é distribuído com eles). |
| |||
Chaves Compartilhadas Padrão | Serviços seguros as vezes empacotam chaves de segurança padrão para o desenvolvimento ou avaliação para propósitos de testes. Se estas chaves são deixadas como estão e colocadas em um ambiente de produção na Internet, todos os usuários com as mesmas chaves padrões possuem acesso ao recurso de chave compartilhada e qualquer informação confidencial que ele contenha. |
| |||
IP Spoofing | Uma máquina remota que age como um nó em sua rede local, encontra vulnerabilidades em seus servidores e instala um programa de backdoor (porta-dos-fundos) ou um trojan horse para obter controle sob seus recursos de rede. |
| |||
Eavesdropping (Interceptação) | Uma coleta dos dados que passam entre dois nós ativos em uma rede, interceptando a conexão entre os dois nós. |
| |||
Vulnerabilidades de Serviços | Um atacante encontra um defeito ou um furo em um serviço executado sob a Internet; através desta vulnerabilidade, o atacante compromete todo o sistema e qualquer dado que ele possa conter, e pode possivelmente comprometer outros sistemas na rede. |
| |||
Vulnerabilidades de Aplicativos | Atacantes encontram falhas em desktops e aplicativos de estações de trabalho (tal como clientes de email) e executam códigos arbitrários, implementam trojan horses para comprometimento futuro ou quebra de sistemas. Explorações futuras podem ocorrer se a estação de trabalho comprometida possui privilégios administrativos no resto da rede. |
| |||
Ataques Denial of Service (DoS) | O atacante ou grupo de atacantes coordenam contra uma rede de uma empresa ou recursos de servidor enviando pacotes não autorizados ao host alvo (tanto o servidor, router ou estação de trabalho). Isto força o recurso a se tornar indisponível para usuários legítimos. |
|
1.5. Atualizações de Segurança
1.5.1. Atualizando Pacotes
Nota
1.5.2. Verificando Pacotes Assinados
/mnt/cdrom
, use o seguinte comando para importa-lo ao keyring (um banco de dados de chaves confiáveis no sistema):
rpm --import /mnt/cdrom/RPM-GPG-KEY
rpm -qa gpg-pubkey*
gpg-pubkey-db42a60e-37ea5438
rpm -qi
seguido do resultado do comando anterior, como neste exemplo:
rpm -qi gpg-pubkey-db42a60e-37ea5438
rpm -K /tmp/updates/*.rpm
gpg OK
. Se caso não, tenha certeza que está usando a chave pública Red Hat correta e também verificar a fonte do conteúdo. Pacotes que não passam verificações GPG não devem ser instalados, já que podem ter sido alterados por um terceiro.
1.5.3. Instalando Pacotes Assinados
rpm -Uvh /tmp/updates/*.rpm
rpm -ivh /tmp/updates/<kernel-package>
rpm -e <old-kernel-package>
Nota
Importante
1.5.4. Aplicando as Mudanças
Nota
- Aplicativos
- Aplicativos do espaço do usuário são quaisquer programas que podem ser iniciados por um usuário do sistema. Tipicamente, tais aplicativos são usados somente quando um usuário, script ou tarefa automatizada os rodam e estes não persistem por longos períodos de tempo.Uma vez que determinado aplicativo de espaço de usuário é atualizado, pare quaisquer instâncias do aplicativo no sistema e rode o programa de novo para usar a versão atualizada.
- Kernel
- O kernel é o componente de software principal do sistema operacional Red Hat Enterprise Linux. Ele gerencia o acesso à memória, ao processador e aos periféricos e também a todas as tarefas agendadas.Por causa de seu papel central, o kernel não pode ser reiniciado sem também parar o computador. Portanto, uma versão atualizada do kernel não pode ser usada até que o sistema seja reinicializado.
- Bibliotecas Compartilhadas
- Bibliotecas compartilhadas são unidades de códigos, como o
glibc
, que são usados por um número de aplicações e serviços. Aplicações utilizando uma biblioteca compartilhada tipicamente carrega o código compartilhado quando a aplicação é inicializada, então quaisquer aplicações usando a biblioteca atualizada deve ser parada e reiniciada.Para determinar quais aplicativos em execução se ligam a uma determinada biblioteca, use o comandolsof
como no exemplo seguinte:lsof /lib/libwrap.so*
Este comando retorna uma lista de todas os programas que usam os TCP Wrappers para controle de acesso ao host. Portanto, qualquer programa listado deve ser parado e reiniciado se o pacotetcp_wrappers
estiver atualizado. - Serviços SysV
- Serviços SysV são programas de servidores persistentes iniciados durante o processo de boot. Exemplos de serviços SysV incluem o
sshd
,vsftpd
, exinetd
.Pela razão que estes programas normalmente persistem na memória pelo tempo que a máquina é inicializada, cada serviço de atualização SysV deve ser parado e reiniciado depois que o pacote é atualizado. Isto pode ser feito usando Services Configuration Tool (Ferramenta de Configuração de Serviços) ou se autenticando no shell root e digitando o comando/sbin/service
conforme no exemplo seguinte:/sbin/service <service-name> restart
No exemplo anterior, substitua o <service-name> com o nome do serviço, como osshd
. - Serviços
xinetd
- Serviços controlados pelo super serviço
xinetd
somente roda quando há uma conexão ativa. Exemplos de serviços controlados peloxinetd
incluem o Telnet, IMAP e POP3.Pela razão que novas instâncias destes serviços são iniciadas peloxinetd
cada vez que um novo pedido é recebido, as conexões que ocorrem depois de uma atualização são manuseadas pelo software atualizado. Entretanto se existem conexões ativas no momento que o serviço controlado peloxinetd
é atualizado, eles são atendidos pela versão antiga do software.Para terminar as instâncias antigas de um determinado serviço controlado peloxinetd
, atualize o pacote para o serviço e então pare todos os processos atualmente em execução. Para determinar se o processo está rodando, use o comandops
e então okill
oukillall
para parar instâncias atuais do serviço.Por exemplo, se uma errata de segurança dos pacotesimap
é lançada, atualize os pacotes e então digite o seguinte comando como root no prompt do shell:ps aux | grep imap
Este comando retorna todas sessões ativas do IMAP. Sessões individuais podem então ser terminadas digitando o seguinte comando:kill <PID>
Se isto falhar para terminar a sessão, use o seguinte comando então:kill -9 <PID>
Nos exemplos anteriores, substitua o <PID> com o número de identificação do processo (encontrado na segunda coluna do comandops
) para uma sessão de IMAP.Para terminar todas as sessões IMAP ativas, digite o seguinte comando:killall imapd
Capítulo 2. Protegendo sua Rede
2.1. Segurança da Estação de Trabalho
2.1.1. Avaliando a Segurança da Estação de Trabalho
- Segurança da BIOS e do carregador de Boot — É possível que um usuário não autorizado acesse a máquina fisicamente e inicialize como um usuário único ou modo de recuperação sem uma senha?
- Segurança da Senha — Quão seguros estão as senhas das contas de usuários na máquina?
- Controles Administrativos — Quem possuirá uma conta no sistema e quanto controle administrativo possuirão?
- Serviços de Redes Disponíveis — Quais serviços estão escutando por pedidos da rede e eles deveriam estar rodando?
- Firewalls Pessoais — Qual tipo de firewall seria necessário?
- Ferramentas de Comunicação com Segurança Avançada — Quais ferramentas devem ser usadas para se comunicar entre estações de trabalho e quais deveriam ser evitadas?
2.1.2. Segurança da BIOS e do Carregador de Boot
2.1.2.1. Senhas da BIOS
- Prevenindo Mudanças às Configurações da BIOS — Se um invasor possui acesso à BIOS, ele pode configura-la para fazer o boot de um disquete ou CD-ROM. Sendo possível entrar no modo de recuperação ou modo de usuário único, que permite iniciar processos arbitrários no sistema ou copiar dados sensíveis.
- Prevenindo Inicialização do Sistema — Algumas BIOS permitem proteção por senha do processo de boot. Quando ativados, um invasor é forçado a entrar com uma senha antes que a BIOS inicie o carregador de boot.
2.1.2.1.1. Protegendo Plataformas que não são X86
2.1.2.2. Senhas do Carregador de Boot
- Impedir Acesso ao Modo de Usuário Único — Se invasores podem inicializar o sistema no modo de usuário único, eles são logados automaticamente como root sem serem questionados pela senha root.
- Impedir Acesso ao Console GRUB — Se a máquina usa o GRUB como seu carregador de boot, um invasor pode usar a interface do editor GRUB para mudar sua configuração ou pegar informações usando o comando
cat
. - Impedir Acesso à Sistemas Operacionais Inseguros — Se o sistema possui sistema de boot duplo, um invasor pode selecionar um sistema operacional no momento do boot (por exemplo, o DOS), que ignora controles de acesso e permissões de arquivos.
2.1.2.2.1. Protegendo o GRUB com senha
/sbin/grub-md5-crypt
/boot/grub/grub.conf
. Abra o arquivo e abaixo da linha timeout
na seção principal do documento, adicione a seguinte linha:
password --md5 <password-hash>
/sbin/grub-md5-crypt
[12].
/boot/grub/grub.conf
deve ser editada.
title
do sistema operacional que você quer proteger e adicione uma linha com a diretiva lock
imediatamente embaixo dela.
title DOS lock
Atenção
password
deve estar presente na seção principal do arquivo /boot/grub/grub.conf
para este método para funcionar propriamente. Caso contrário, um invasor pode acessar a interface do editor GRUB e remover a linha bloqueada.
lock
à estrofe, seguida pela linha da senha.
title DOS lock password --md5 <password-hash>
2.1.3. Segurança da Senha
/etc/passwd
, que faz o sistema vulnerável à ataques de quebra de senhas offline. Se um invasor pode ter acesso à máquina como um usuário normal, ele pode copiar o arquivo /etc/passwd
para sua própria máquina e rodar quaisquer programas de quebra de senha. Se houver uma senha insegura no arquivo, é somente um questão de tempo até que o invasor a descubra.
/etc/shadow
, que pode ser lido somente pelo usuário root.
2.1.3.1. Criando Senhas Fortes
- Não Use Somente Palavras ou Números — Nunca use somente números ou palavras em uma senha.Alguns exemplos inseguros incluem o seguinte:
- 8675309
- juan
- hackme
- Não Use Palavras Reconhecíveis — Palavras como nomes próprios, palavras de dicionário ou mesmo termos de programas de televisão ou novelas devem ser evitados, mesmo se finalizados com números.Alguns exemplos inseguros incluem o seguinte:
- john1
- DS-9
- mentat123
- Não Use Palavras em Línguas Estrangeiras — Programas de quebra de senha muitas vezes tentam listas de palavras que incluem dicionários de muitas línguas. Contar com línguas estrangeiras para senhas não é seguro.Alguns exemplos inseguros incluem o seguinte:
- cheguevara
- bienvenido1
- 1dumbKopf
- Não Use Terminologia Hacker — Se você acha que é elite porque você usa terminologia hacker — também conhecida como a escrita l337 (LEET) — em sua senha, pense novamente. Muitas listas de palavras incluem a escrita LEET.Alguns exemplos inseguros incluem o seguinte:
- H4X0R
- 1337
- Não Use Informações Pessoais — Evite usar qualquer informação pessoal em suas senhas. Se o invasor conhece sua identidade, a tarefa em adivinhar sua senha se torna mais fácil. A seguir está uma lista de tipos de informações a serem evitadas quando criar uma senha:Alguns exemplos inseguros incluem o seguinte:
- Seu Nome
- Nomes de animais de estimação
- Os nomes dos membros da família
- Qualquer data de aniversário
- Seu número de telefone ou código postal
- Não Inverta Palavras Reconhecíveis — Verificadores de senhas bons sempre invertem as palavras comuns, então inverter uma senha fraca não a faz mais segura.Alguns exemplos inseguros incluem o seguinte:
- R0X4H
- nauj
- 9-DS
- Não Escreva Sua Senha — Nunca guarde sua senha em papel. É mais seguro memoriza-la.
- Não Use a Mesma Senha para Todas as Máquinas — É importante fazer senhas separadas para cada máquina. Desta maneira se um sistema é comprometido, todas suas máquinas não estarão imeditatamente em risco.
- Faça a Senha com no Mínimo 8 Dígitos — Quanto mais longa a senha, melhor. Se usar senhas MD5, ela deve ser de 15 ou mais dígitos . Com senha DES, use a extensão máxima (oito caracteres).
- Misture Maiúsculas e Minúsculas — O Red Hat Enterprise Linux diferencia maiúsculas de minúsculas, então misture as letras para aumentar a força da senha.
- Misture Letras e Números — Adicionar números às senhas, especialmente quando adicionados no meio (não só no início ou no final), pode aumentar a força da senha.
- Inclua Caracteres Não Alfa Numéricos — Caracteres especiais como &, $, e > podem melhorar muito a força de uma senha (isto não é possível se usar senhas DES).
- Escolha uma Senha que Você pode se Lembrar — A melhor senha do mundo não faz nada se você não lembra-la; use acrônimos ou outros dispositivos mnemônicos para ajudar a memorizar senhas.
2.1.3.1.1. Metodologia para Criação de Senhas Seguras
- Pense em uma frase fácil de se lembrar, como esse em inglês:"over the river and through the woods, to grandmother's house we go."
- Depois, transforme a frase em um acrônimo (incluindo a pontuação).
otrattw,tghwg.
- Adicione complexidade substituindo números e símbolos por letras no acrônimo. Por exemplo, substitua
7
pelot
e o símbolo (@
) peloa
:o7r@77w,7ghwg.
- Adicione mais complexidade colocando em maiúsculo pelo menos uma letra, tal como
H
.o7r@77w,7gHwg.
- Finalmente, não use o exemplo da senha acima em qualquer sistema, nunca.
2.1.3.2. Criando Senhas de Usuários Dentro de Uma Organização
2.1.3.2.1. Forçando Senhas Fortes
passwd
, que é o Pluggable Authentication Modules (PAM) checando se a senha é muito curta ou de outra maneira fácil de quebrar. Esta verificação é realizada usando o modulo PAM pam_cracklib.so
. Já que o PAM é personalizável, é possível adicionar mais de um verificador de integridade de senhas, como pam_passwdqc
(disponível em http://www.openwall.com/passwdqc/) ou escrever um módulo novo. Para uma lista de módulos PAM disponíveis, consulte o http://www.kernel.org/pub/linux/libs/pam/modules.html. Para mais informações sobre o PAM, consulte Gerenciando Sign-On Únicos e Cartões Smart.
- John The Ripper — Um rápido de flexível programa de quebra de senhas. Permite o uso de múltiplas listas de palavras e é capaz de quebrar senhas por força bruta. Está disponível online em http://www.openwall.com/john/.
- Crack — Talvez o mais conhecido programa de quebra de senhas, o Crack é também muito rápido, embora não tão fácil de usar como o John The Ripper. Pode ser encontrado em http://www.crypticide.com/alecm/security/crack/c50-faq.html.
- Slurpie — O Slurpie é similar ao John The Ripper e o Crack, mas é desenhado para rodar em múltiplos computadores simultaneamente, criando um ataque de quebra de senhas distribuído. Ele pode ser encontrado online junto com uma série de outras ferramentas de avaliação de ataque à segurança em http://www.ussrback.com/distributed.htm.
Atenção
2.1.3.2.2. Frases Secretas
2.1.3.2.3. Expiração de Senha
chage
ou a aplicação User Manager (system-config-users
).
-M
do comando chage
especifica o número máximo de dias que a senha é válida. Por exemplo, para definir que a senha de um usuário expire em 90 dias, use o seguinte comando:
chage -M 90 <username>
99999
depois da opção -M
(isto é equivale a mais ou menos 273 anos).
chage
em modo interativo para modificar múltiplas expirações de senhas e detalhes de conta. Use o comando seguinte para entrar no modo interativo:
chage <username>
[root@myServer ~]# chage davido Changing the aging information for davido Enter the new value, or press ENTER for the default Minimum Password Age [0]: 10 Maximum Password Age [99999]: 90 Last Password Change (YYYY-MM-DD) [2006-08-18]: Password Expiration Warning [7]: Password Inactive [-1]: Account Expiration Date (YYYY-MM-DD) [1969-12-31]: [root@myServer ~]#
- Clique no menu System (Sistema) no painel, depois em Administration (Administração) e então clique em Users and Groups (Usuários e Grupos) para exibir o Gerenciador de Usuários. Alternativamente, digite o comando
system-config-users
no shell. - Clique na aba Users (Usuários) e selecione o usuário requerido na lista de usuários.
- Clique em Properties (Propriedades) na barra de ferramentas para exibir as caixa de diálogo das Propriedades do Usuário (ou escolha Properties (Propriedades) no menu File (Arquivo)).
- Clique na aba Password Info (Informações de Senha) e marque a caixa de verificação Enable password expiration (Ativar expiração de senha).
- Digite o valor requerido no campo Days before change required (Dias antes da mudança requerida) e clique OK.

Figura 2.1. Especificando as opções de expiração de senha
2.1.4. Controles Administrativos
sudo
ou su
. Um programa setuid é um que opera com a ID de usuário (UID) do proprietário do programa em vez do usuário operar o programa. Tais programas são denotados por um s
na seção proprietário de uma lista de formato longo, como no exemplo a seguir:
-rwsr-xr-x 1 root root 47324 May 1 08:09 /bin/su
Nota
s
pode ser maiúsculo ou minusculo. Se aparecer como maiúsculo, significa que o bit de permissão subjacente não foi definido.
pam_console.so
, algumas atividades normalmente reservadas somente para o usuário root, como reinicialização e montagem de mídia removíveis são permitidas para o primeiro usuário que logar no console físico (consulte Gerenciando Sign-On Únicos e Cartões Smart para mais informações sobre o módulo pam_console.so
). Entretanto, outras tarefas importantes de administração do sistema, como alterar definições de rede, configurar um mouse novo ou montar dispositivos de rede não são possíveis sem privilégios administrativos. Como resultado, administradores de sistema devem decidir quanta acessibilidade os usuários em sua rede devem receber.
2.1.4.1. Permitindo Acesso Root
- Desconfiguração da Máquina — Usuários com acesso root pode desconfigurar suas máquinas e necessitar de assistência para resolver o problema. Ainda pior, eles podem abrir brechas de segurança sem perceber.
- Executando Serviços Inseguros — Usuários com acesso root podem rodar servidores inseguros em suas máquinas, como FTP ou Telnet, colocando nomes de usuários e senhas potencialmente em risco. Estes serviços transmitem estas informações pela a rede em texto puro.
- Executar Anexos de Email como Root — Ainda que raro, vírus em e-mails que afetam o Linux existem. O único momento entretanto que eles são uma ameaça é quando eles são executados pelo usuário root.
2.1.4.2. Desabilitando Acesso ao Root
Tabela 2.1. Métodos para Desabilitar a Conta Root
Método | Descrição | Efeitos | Não afeta | |||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Alternado o shell do root. | Edite o arquivo /etc/passwd e mude o shell de /bin/bash para /sbin/nologin . |
|
| |||||||||||||||
Desativar o acesso root por qualquer dispositivo de console (tty). | Um arquivo /etc/securetty impede o login de root em quaisquer dispositivos anexados ao computador. |
|
| |||||||||||||||
Desativando logins root SSH. | Edite o arquivo /etc/ssh/sshd_config e defina o parâmetro PermitRootLogin para no . |
|
| |||||||||||||||
Use o PAM para limitar acesso root aos serviços. | Edite o arquivo para o serviço alvo no diretório /etc/pam.d/ . Tenha certeza que o pam_listfile.so é requerido para autenticação. [a] |
|
| |||||||||||||||
[a]
Consulte a Seção 2.1.4.2.4, “Desativando o Root de usar o PAM” para detalhes.
|
2.1.4.2.1. Desativando o Shell do Root
/sbin/nologin
no arquivo /etc/passwd
. Isso impede o acesso à conta root através de comando que requerem um shell, como os comandos su
e o ssh
Importante
sudo
, podem ainda acessar a conta root.
2.1.4.2.2. Desativando Logins Root
/etc/securetty
. Este arquivo lista todos os dispositivos em que o usuário root é permitido logar. Se o arquivo não existir, o usuário root pode se autenticar através de qualquer dispositivo de comunicação no sistema, seja pelo console ou uma interface de rede bruta. Isto é perigoso, porque um usuário pode se autenticar em sua máquina pela rede. Por padrão, o arquivo /etc/securetty
do Red Hat Enterprise Linux somente permite ao usuário root se autenticar no console fisicamente anexado à máquina. Para impedir o root de se autenticar, remova o conteúdo deste arquivo, digitando o seguinte comando:
echo > /etc/securetty
Atenção
/etc/securetty
não impede o usuário root de se autenticar remotamente usando a suíte de ferramentas OpenSSH porque o console não é aberto até depois da autenticação.
2.1.4.2.3. Desativando Logins Root SSH
/etc/ssh/sshd_config
). Mude a linha que contém:
PermitRootLogin yes
PermitRootLogin no
kill -HUP `cat /var/run/sshd.pid`
2.1.4.2.4. Desativando o Root de usar o PAM
/lib/security/pam_listfile.so
, permite uma grande flexibilidade em negar contas específicas. O administrador pode usar este módulo para referenciar uma lista de usuários que não estão permitidos de se autenticar. Abaixo está um exemplo de como o módulo é usado pelo servidor FTP vsftpd
no arquivo de configuração do PAM /etc/pam.d/vsftpd
, o caractere \
no final da primeira linha no exemplo seguinte não é necessário se a diretiva está em uma linha):
auth required /lib/security/pam_listfile.so item=user \ sense=deny file=/etc/vsftpd.ftpusers onerr=succeed
/etc/vsftpd.ftpusers
e negar acesso ao serviço para qualquer usuário listado. O administrador pode mudar o nome deste arquivo e manter listas separadas para cada serviço ou usar uma lista central para negar acesso à múltiplos serviços.
/etc/pam.d/pop
e o /etc/pam.d/imap
para clientes de e-mail ou o /etc/pam.d/ssh
para cliente SSH.
2.1.4.3. Limitando o Acesso Root
su
ou sudo
.
2.1.4.3.1. O Comando su
su
, ele é questionado pela senha root e depois da autenticação, recebe a linha de comando do root.
su
, o usuário se torna o usuário root e possui acesso administrativo absoluto ao sistema[13]. Além disso, uma vez que um usuário se tornou root, é possível para ele usar o comando su
para mudar para qualquer outro usuário no sistema sem ser questionado por uma senha.
usermod -G wheel <username>
wheel
.
- Clique no menu System (Sistema) no painel, depois em Administration (Administração) e então clique em Users and Groups (Usuários e Grupos) para exibir o Gerenciador de Usuários. Alternativamente, digite o comando
system-config-users
no shell. - Clique na aba Users (Usuários) e selecione o usuário requerido na lista de usuários.
- Clique em Properties (Propriedades) na barra de ferramentas para exibir as caixa de diálogo das Propriedades do Usuário (ou escolha Properties (Propriedades) no menu File (Arquivo)).
- Clique na aba Groups (Grupos), marque a caixa de seleção para o grupo wheel, e então clique em OK. Veja a Figura 2.2, “Adicionando usuários ao grupo "wheel".”

Figura 2.2. Adicionando usuários ao grupo "wheel".
su
(/etc/pam.d/su
) em um editor de textos e remova o comentário # na seguinte linha:
auth required /lib/security/$ISA/pam_wheel.so use_uid
wheel
podem usar este programa.
Nota
wheel
por padrão.
2.1.4.3.2. O Comando sudo
sudo
oferece outra abordagem para dar aos usuários o acesso administrativo. Quando usuários confiáveis precedem um comando administrativo com o sudo
, eles são questionados pela própria senha. Então, quando eles são autenticados e assumindo que o comando é permitido, o comando administrativo é executado como se ele fosse o usuário root.
sudo
é como a seguir:
sudo <command>
mount
.
Importante
sudo
devem ter cuidade e sair do comando antes de deixar a máquina, já que o sudo pode executar o comando novamente sem ter a senha pedida dentro de um período de cinco minutos. Esta configuração pode ser alterada pelo arquivo de configuração, /etc/sudoers
.
sudo
permite um alto grau de flexibilidade. Por exemplo, somente usuários listados no arquivo de configuração /etc/sudoers
são permitidos usar o comando sudo
e o comando é executado no shell do usuário, não no shell do root. Isto significa que o shell do root pode ser completamente desativado, como mostrado na Seção 2.1.4.2.1, “Desativando o Shell do Root”.
sudo
também fornece um registro de auditoria abrangente. Cada autenticação feita é registrada no arquivo /var/log/messages
e o comando digitado junto com o nome do usuário é registrado no arquivo /var/log/secure
.
sudo
é que um administrador pode permitir usuários diferentes acessar comandos especificos baseados em suas necessidades.
sudo
, /etc/sudoers
, devem usar o comando visudo
.
visudo
e adicione uma linha similar à seguinte na seção de especificação de privilégio do usuário:
juan ALL=(ALL) ALL
juan
, pode usar sudo
de qualquer host e executar qualquer comando.
sudo
:
%users localhost=/sbin/shutdown -h now
/sbin/shutdown -h now
desde que ele seja emitido a partir do console.
sudo
possui uma lista detalhada de opções para este arquivo.
2.1.5. Serviços de Rede Disponíveis
2.1.5.1. Riscos ao Serviços
- Denial of Service Attacks (DoS) — Inunda um serviço com pedidos, um ataque de negação de serviço pode fazer um sistema inutilizável conforme ele tenta registrar e responder cada pedido.
- Distributed Denial of Service Attack (DDoS) — Um tipo de ataque DoS que usa múltiplas máquinas comprometidas (muitas vezes milhares ou mais) para direcionar um ataque coordenado à um serviço, inundando com pedidos e fazendo o serviço inutilizável.
- Script Vulnerability Attacks — Se um servidor estiver usando scripts para executar ações dentro do servidor, como servidores web geralmente fazem, um invasor pode atacar os scripts impropriamente. Estes ataques de vulnerabilidade de script podem levar à uma condição de buffer overflow ou permitir ao invasor alterar arquivos no sistema.
- Buffer Overflow Attacks — Serviços que conectam às portas numeradas de 0 a 1023 devem rodar como um usuário administrativo. Se a aplicação tiver um buffer overflow explorável, um invasor poderia ganhar acesso ao sistema como o usuário executando o deaemon. Pela razão que buffer overflow existe, os crackers usam ferramentas automatizadas para identificar sistemas com vulnerabilidades e uma vez que ganharam acesso, eles usam rootkits automatizados para manter o acesso ao sistema.
Nota
Importante
2.1.5.2. Identificando e Configurando Serviços
cupsd
— O servidor de impressão do Red Hat Enterprise Linux.lpd
— Um servidor de impressão alternativo.xinetd
— Um super servidor que controla conexões de uma variedade de servidores subordinados, tais comogssftp
etelnet
.sendmail
— O Sendmail Mail Transport Agent (MTA) é ativado por padrão, mas somente escuta por conexões do localhost.sshd
— O servidor OpenSSH que é um substituto seguro para o Telnet.
cupsd
rodando. O mesmo é verdadeiro para o portmap
. Se você não montar os volumes NFSv3 ou usar o NIS (o serviço ypbind
), então o portmap
deve ser desativado.

Figura 2.3. Ferramentas de Configuração de Serviços
2.1.5.3. Serviços Inseguros
- Transmitir Nomes de Usuários e Senhas Sobre uma Rede Sem Encriptação — Muitos protocolos antigos, como Telnet e FTP não fazem encriptação da sessão de autenticação e deveriam ser evitados sempre que possível.
- Transmitir Dados Sensíveis Sobre uma Rede Sem Encriptação — Muitos protocolos transmitem dados sobre uma rede sem encriptação. Estes protocolos incluem Telnet, FTP, HTTP e SMTP. Muitos sistemas de arquivos de rede, como NFS e SMB também transmitem informações sobre a rede sem encriptação. É a responsabilidade do usuário limitar quais tipos de dados são transmitidos quando usar estes protocolos.Serviços de Dump de Memória Remota, como o
netdump
, transmitem os conteúdos de memória sobre a rede sem encriptação. Dumps de memória podem conter senhas ou, ainda pior, entradas de banco de dados e outras informações sensíveis.Outros serviços como ofinger
erwhod
revelam informações sobre os usuários do sistema.
rlogin
, rsh
, telnet
e vsftpd
.
rlogin
, rsh
, e telnet
) devem ser evitados em favor do SSH. Consulte a Seção 2.1.7, “Ferramentas de Comunicação Avançadas de Segurança” para mais informações sobre o sshd
.
finger
authd
(este era chamadoidentd
em versões anteriores do Red Hat Enterprise Linux.)netdump
netdump-server
nfs
rwhod
sendmail
smb
(Samba)yppasswdd
ypserv
ypxfrd
2.1.6. Firewalls Pessoais
Importante
system-config-firewall
) . Esta ferramenta cria regras abrangentes de iptables
para um firewall de uso geral usando uma interface de painel de controle.
iptables
é provavelmente a melhor opção. Consulte a Seção 2.5, “Firewalls” para mais informações. Consulte a Seção 2.6, “IPTables” para um guia compreensivo do comando iptables
.
2.1.7. Ferramentas de Comunicação Avançadas de Segurança
- OpenSSH — Uma implementação grátis do protocolo SSH para encriptação de comunicação de rede.
- Gnu Privacy Guard (GPG) — Uma implementação grátis da aplicação de encriptação PGP (Pretty Good Privacy) para dados.
telnet
e rsh
. O OpenSSH inclui um serviço de rede chamado sshd
e três aplicações clientes de linha de comando:
ssh
— Um cliente de acesso remoto de console seguro.scp
— Um comando de cópia remota seguro.sftp
— Um cliente de pseudo ftp seguro que permite sessões de transferência de arquivos seguros.
Importante
sshd
ser inerentemente seguro, o serviço deve ser mantido atualizado para impedir ameaças de segurança. Consulte a Seção 1.5, “Atualizações de Segurança” para mais informações.
2.2. Segurança do Servidor
- Mantém todos os serviços atualizados, para protege-los contra as últimas ameaças.
- Use protocolos seguros sempre que possível.
- Sirva somente um tipo de serviço de rede por máquina sempre que possível.
- Monitore todos os servidores cuidadosamente por atividades suspeitas.
2.2.1. Assegure os Serviços com TCP Wrappers e xinetd
xinetd
, um super servidor que fornece acesso adicional, registro de logs, associação, redirecionamento e controle de utilização de recursos.
Nota
xinetd
para criar redundância dentro dos controles de acesso de serviço. Consulte a Seção 2.5, “Firewalls” para mais informações sobre implementar firewalls com comandos iptables.
2.2.1.1. Aumentando a Segurança com TCP Wrappers
hosts_options
para informações sobre a funcionalidade dos TCP Wrappers e idioma de controle. Consulte a página man xinetd.conf
disponível online em http://linux.die.net/man/5/xinetd.conf para os sinalizadores disponíveis, que agem como opções que você pode aplicar em um serviço.
2.2.1.1.1. TCP Wrappers e Banners de Conexão
banner
.
vsftpd
. Para iniciar, crie um arquivo de banner. Ele pode estar em qualquer lugar no sistema, mas ele deve ter o mesmo nome como o daemon. Para este exemplo, este arquivo é chamado /etc/banners/vsftpd
e contém a seguinte linha:
220-Hello, %c 220-All activity on ftp.example.com is logged. 220-Inappropriate use will result in your access privileges being removed.
%c
fornece uma variedade de informações sobre o cliente, tais como o nome de usuário e hostname ou nome de usuário e endereço de IP para fazer a conexão ainda mais intimidadora.
/etc/hosts.allow
:
vsftpd : ALL : banners /etc/banners/
2.2.1.1.2. TCP Wrappers e Avisos de Ataques
spawn
.
/etc/hosts.deny
para negar quaisquer tentativas de conexão dessa rede, e registrar as tentativas em log em um arquivo especial:
ALL : 206.182.68.0 : spawn /bin/echo `date` %c %d >> /var/log/intruder_alert
%d
fornece o nome do serviço que o invasor estava tentando acessar.
spawn
no arquivo /etc/hosts.allow
.
Nota
spawn
executa qualquer comando shell, é uma boa idéia criar um script especial para notificar o administrador ou executar uma cadeia de comandos no evento de um determinado cliente tentar se conectar ao servidor.
2.2.1.1.3. Os TCP Wrappers e Registro de Log Avançado
severity
.
emerg
nos arquivos de log em vez do sinalizador padrão, info
e negue a conexão.
/etc/hosts.deny
:
in.telnetd : ALL : severity emerg
authpriv
, mas eleva a prioridade do valor padrão de info
para emerg
, que posta mensagens de log diretamente ao console.
2.2.1.2. Aumentando a Segurança com o xinetd
xinetd
para definir um serviço de interceptação (trap) e usa-lo para controlar os níveis de recursos disponíveis para qualquer serviço xinetd
dado. Definindo limites de recursos disponíveis para serviços pode ajudar impedir ataques DoS (Denial of Service ). Consulte as páginas man do xinetd
e do xinetd.conf
para uma lista de opções disponíveis.
2.2.1.2.1. Configurando uma Interceptação (Trap)
xinetd
é sua habilidade de adicionar hosts à uma lista no_access
global. Hosts nesta lista são conexões subsequentes negadas a serviços gerenciados pelo xinetd
por um período especificado ou até que o xinetd
seja reiniciado. Você pode fazer isto usando o atributo SENSOR
. Esta é uma fácil maneira de bloquear hosts tentando escanear as portas neste servidor.
SENSOR
é escolher um serviço que você não planeja usar. Para este exemplo, o Telnet é usado.
/etc/xinetd.d/telnet
e mude as linhas das flags
(sinalizadores) para:
flags = SENSOR
deny_time = 30
deny_time
são o FOREVER, que mantém o banimento em efeito até que o xinetd
seja reiniciado, e o NEVER, que permite a conexão e registra isso em log.
disable = no
SENSOR
é uma boa maneira para detectar e parar conexões de hosts indesejáveis, ela possui desvantagens:
- Não funciona contra escaneamentos stealth.
- Um invasor que sabe que o
SENSOR
está rodando pode montar um ataque Dos (Denial of Service) contra determinados hosts, falsificando seus endereços IP e se conectando à porta proibida.
2.2.1.2.2. Controlando Recursos de Servidor
xinetd
é a habilidade de configurar limites de serviços sobre seu controle.
cps = <number_of_connections> <wait_period>
— Limita a taxa de conexões de entrada. Esta diretiva leva dois argumentos:<number_of_connections>
— O número de conexões por segundo para manuseio. Se a taxa de conexões de entrada é maior que isso, o serviço é temporariamente desativado. O valor padrão é cinquenta (50).<wait_period>
— O número de segundos para esperar antes da reativação do serviço depois que ele foi desativado. O intervalo padrão é dez (10) segundos.
instances = <number_of_connections>
— Especifica o número total de conexões permitidas a um serviço. Esta diretiva aceita tanto um valor de número inteiro ouUNLIMITED
(ilimitado).per_source = <number_of_connections>
— Especifica o número de conexões permitidas a um serviço por cada host. Esta diretiva aceita tanto um valor de número ouUNLIMITED
(ilimitado).rlimit_as = <number[K|M]>
— Especifica a quantidade de espaço de endereço de memória que o serviço pode ocupar em kilobytes ou megabytes. Esta diretiva aceita tanto um valor de número inteiro ouUNLIMITED
.rlimit_cpu = <number_of_seconds>
— Especifica o período de tempo em segundos que um serviço pode ocupar na CPU. Esta diretiva aceita tanto um integrador de número inteiro ouUNLIMITED
(limitado).
xinetd
único de sobrecarregar o sistema, resultando em um DoS (denial of service).
2.2.2. Protegendo o Portmap
portmap
é um daemon de atribuição de porta dinâmica para serviços RPC como NIS e NFS. Ele possui uma mecanismo de autenticação fraco e possui a habilidade de atribuir uma grande variedade de portas para os serviços que controla. Por estas razões, ele é difícil de proteger.
Nota
portmap
somente afeta as implementações NFSv2 e NFSv3, já que o NFSv4 não o requer mais. Se você planeja implementar um servidor NFSv2 ou NFSv3, então o portmap
é requerido e as seguintes seções se aplicam.
2.2.2.1. Proteja o portmap com TCP Wrappers
portmap
desde que ele não possua uma forma de autenticação embutida.
2.2.2.2. Proteger o portmap com o iptables
portmap
, é uma boa idéia adicionar regras de iptables ao servidor e restringir acesso às redes especificas.
portmap
) da rede 192.168.0.0/24. A segunda permite conexões TCP à mesma porta do local host. Isto é necessário para o serviço sgi_fam
usado pelo Nautilus. Todos os outros pacotes são largados.
iptables -A INPUT -p tcp ! -s 192.168.0.0/24 --dport 111 -j DROP iptables -A INPUT -p tcp -s 127.0.0.1 --dport 111 -j ACCEPT
iptables -A INPUT -p udp ! -s 192.168.0.0/24 --dport 111 -j DROP
Nota
2.2.3. Protegendo o NIS
ypserv
, que é usado em conjunto com o portmap
e outros serviços relacionados para distribuir mapas de nomes de usuários, senhas e outras informações sensíveis a qualquer computador alegando estar dentro do domínio.
/usr/sbin/rpc.yppasswdd
— Também chamado serviçoyppasswdd
, este daemon permite usuários alterar suas senhas NIS./usr/sbin/rpc.ypxfrd
— Também chamado serviçoypxfrd
, este daemon é responsável por transferências de mapas NIS pela rede./usr/sbin/yppush
— Esta aplicação propaga bancos de dados NIS para múltiplos servidores NIS./usr/sbin/ypserv
— Este é o daemon do servidor NIS.
portmap
conforme descrito na Seção 2.2.2, “Protegendo o Portmap”, em seguida, aborde as seguintes questões, como planejar a rede.
2.2.3.1. Planeje a Rede Cuidadosamente
2.2.3.2. Use um Nome de Domínio NIS e Hostname como se fosse uma Senha.
/etc/passwd
:
ypcat -d <NIS_domain> -h <DNS_hostname> passwd
/etc/shadow
digitando o seguinte comando:
ypcat -d <NIS_domain> -h <DNS_hostname> shadow
Nota
/etc/shadow
não é armazenado dentro de um mapa NIS.
o7hfawtgmhwg.domain.com
. Da mesma maneira, crie um nome de domínio NIS aleatório diferente. Isto deixa mais difícil para um invasor acessar o servidor NIS.
2.2.3.3. Edite o Arquivo /var/yp/securenets
/var/yp/securenets
está em branco ou não existe (como é o caso depois da instalação padrão), o NIS escuta todas as redes. Uma das primeiras coisas a fazer é colocar os pares de mascara de rede/rede no arquivo para que o ypserv
somente responda aos pedidos da rede apropriada.
/var/yp/securenets
:
255.255.255.0 192.168.0.0
Atenção
/var/yp/securenets
.
2.2.3.4. Atribua Portas Estáticas e Use Regras iptables
rpc.yppasswdd
— o daemon que permite usuários mudar suas senhas de login. Atribuir portas aos outros dois daemons do servidor NIS rpc.ypxfrd
and ypserv
, permite a criação de regras de firewall para proteger ainda mais o daemons do servidor NIS de invasores.
/etc/sysconfig/network
:
YPSERV_ARGS="-p 834" YPXFRD_ARGS="-p 835"
iptables -A INPUT -p ALL ! -s 192.168.0.0/24 --dport 834 -j DROP iptables -A INPUT -p ALL ! -s 192.168.0.0/24 --dport 835 -j DROP
Nota
2.2.3.5. Use a Autenticação Kerberos
/etc/shadow
é enviado pela rede. Se um invasor ganha acesso a um domínio NIS e intercepta o tráfego de rede, ele pode coletar nomes de usuários e senhas hash. Com tempo suficiente, um programa de quebra de senha pode adivinhar senhas fracas e um invasor pode ter acesso a uma conta válida na rede.
2.2.4. Protegendo o NFS
Importante
portmap
conforme explicado na Seção 2.2.2, “Protegendo o Portmap”. O tráfego de NFS agora utiliza o TCP em todas as versões, em vez do UDP, e requer isso quando usar o NFSv4. O NFSv4 agora inclui o usuário Kerberos e a autenticação de grupo como parte do módulo do kernel RPCSEC_GSS
. Informações sobre o portmap
é ainda incluída, desde que o Red Hat Enterprise Linux 6 suporta o NFSv2 e o NFSv3, e ambos utilizam o portmap
.
2.2.4.1. Planeje a Rede Cuidadosamente
2.2.4.2. Atenção aos Erros de Sintaxe
/etc/exports
. Cuidado para não adicionar espaços fora de lugar quando editar este arquivo.
/etc/exports
compartilha o diretório /tmp/nfs/
ao host bob.example.com
com permissões de leitura/escrita.
/tmp/nfs/ bob.example.com(rw)
/etc/exports
, por outro lado, compartilha o mesmo diretório do host bob.example.com
com permissões de leitura somente e compartilha com o world com permissões de leitura/escrita devido ao carácter espaço único depois do hostname.
/tmp/nfs/ bob.example.com (rw)
showmount
para verificar o que está sendo compartilhado:
showmount -e <hostname>
2.2.4.3. Não Use a Opção no_root_squash
nfsnobody
, uma conta de usuário sem previlégios. Isto muda o proprietário de todos os arquivos criados pelo root para nfsnobody
, que impede o upload de programas com o setuid definido.
no_root_squash
é usado, os usuários root remotos são capazes de mudar quaisquer arquivos no sistema de arquivos compartilhados e deixar aplicações infectadas por trojans para que outros usuários as executem sem saber.
2.2.4.4. Configuração de Firewall NFS
MOUNTD_PORT
— Porta UDP e TCP para o mountd (rpc.mountd)STATD_PORT
— Porta UDP e TCP para o status (rpc.statd)LOCKD_TCPPORT
— Porta TCP para o nlockmgr (rpc.lockd)LOCKD_UDPPORT
— Porta UDP para o nlockmgr (rpc.lockd)
rpcinfo -p
no servidor NFS para ver quais portas e programas RPC estão sendo usados.
2.2.5. Protegendo o Servidor HTTP Apache
chown root <directory_name>
chmod 755 <directory_name>
/etc/httpd/conf/httpd.conf
):
FollowSymLinks
- Esta diretiva está ativada por padrão, então seja cauteloso quando criar links simbólicos ao documento root do Servidor Web. Por exemplo, não é uma boa idéia fornecer um link simbolico para o
/
. Indexes
- Esta diretiva está ativada por padrão, mas pode não ser desejável. Para impedir visitantes de navegar pelos arquivos do servidor, remova esta diretiva.
UserDir
- A diretiva
UserDir
está desativada por padrão por causa que ela pode confirmar a presença de uma conta de usuário no sistema. Para ativar a navegação de diretórios no servidor, use as seguintes diretivas:UserDir enabled UserDir disabled root
Estas diretivas ativam a navegação de diretórios de usuários para todos os diretórios de usuários menos o/root/
. Para adicionar usuários na lista de contas desativadas, adicione um lista separada por espaços dos usuários na linhaUserDir disabled
.
Importante
IncludesNoExec
. Por padrão, o módulo Server-Side Includes (SSI) não pode executar comandos. É recomendado que você não mude estas definições a menos que seja absolutamente necessário, já que poderia potencialmente ativar um invasor para executar comandos no sistema.
2.2.6. Protegendo o FTP
gssftpd
— Um daemon de FTP baseado emxinetd
e atento ao Kerberos que não transmite informações de autenticação na rede.- Red Hat Content Accelerator (
tux
) — Um servidor Web do kernel com capacidades de FTP. vsftpd
— Um implementação orientada à segurança, autônoma do serviço de FTP.
vsftpd
2.2.6.1. Banner de Saudação do FTP
vsftpd
, adicione a seguinte diretiva ao arquivo /etc/vsftpd/vsftpd.conf
:
ftpd_banner=<insert_greeting_here>
/etc/banners/
. O arquivo de banner para conexões FTP neste exemplo é o /etc/banners/ftp.msg
. Abaixo está um exemplo de como o arquivo deve ser:
######### # Hello, all activity on ftp.example.com is logged. #########
Nota
220
como especificado na Seção 2.2.1.1.1, “TCP Wrappers e Banners de Conexão”.
vsftpd
, adicione a seguinte diretiva ao arquivo /etc/vsftpd/vsftpd.conf
:
banner_file=/etc/banners/ftp.msg
2.2.6.2. Acesso Anônimo
/var/ftp/
ativa a conta anônima.
vsftpd
. Este pacote estabelece uma árvore de diretórios para usuários anônimos e configura as permissões nos diretórios para somente leitura para os usuários anônimos.
Atenção
2.2.6.2.1. Upload Anônimo
/var/ftp/pub/
.
mkdir /var/ftp/pub/upload
chmod 730 /var/ftp/pub/upload
drwx-wx--- 2 root ftp 4096 Feb 13 20:05 upload
Atenção
vsftpd
, adicione a seguinte linha ao arquivo /etc/vsftpd/vsftpd.conf
:
anon_upload_enable=YES
2.2.6.3. Contas de Usuários
vsftpd
, adicione a seguinte diretiva ao /etc/vsftpd/vsftpd.conf
:
local_enable=NO
2.2.6.3.1. Restringindo Contas de Usuários
sudo
, a maneira mais fácil para usar um arquivo de lista PAM conforme descrito na Seção 2.1.4.2.4, “Desativando o Root de usar o PAM”. O arquivo de configuração PAM para o vsftpd
é /etc/pam.d/vsftpd
.
vsftpd
, adicione o nome de usuário ao /etc/vsftpd/ftpusers
2.2.6.4. Usar o TCP Wrappers para Controla Acesso
2.2.7. Protegendo o Sendmail
2.2.7.1. Limitando um DoS (Denial of Service Attack)
/etc/mail/sendmail.mc
, a efetividade do tais ataques é limitada.
confCONNECTION_RATE_THROTTLE
— O número de conexões que o servidor pode receber por segundo. Por padrão, o Sendmail não limita o número de conexões. Se um limite é definido e alcançado, as próximas conexões são atrasadas.confMAX_DAEMON_CHILDREN
— O número máximo de processos filhos que podem ser gerados pelo servidor. Por padrão, o Sendmail não atribui um limite ao número de processos filhos. Se um limite é definido e alcançado, as próximas conexões são atrasadas.confMIN_FREE_BLOCKS
— O número mínimo de blocos livres que devem estar disponíveis para o servidor para aceitar mail. O padrão é 100 blocos.confMAX_HEADERS_LENGTH
— O tamanho máximo aceitável (em bytes) para um cabeçalho de mensagens.confMAX_MESSAGE_SIZE
— O tamanho máximo aceitável (em bytes) para uma mensagem única.
2.2.7.2. O NFS e Sendmail
/var/spool/mail/
, em um volume NFS compartilhado.
Nota
SECRPC_GSS
não utiliza uma autenticação baseada em UID. Entretanto, é ainda considerado uma boa prática não colocar o diretório de mail spool em volumes NFS não compartilhados.
2.2.7.3. Usuários somente de Mail
/etc/passwd
devem ser definidos para /sbin/nologin
(com a exceção possível do usuário root).
2.2.8. Verificando Quais Portas Estão Escutando
netstat -an
ou lsof -i
. Este método é menos confiável desde que estes programas não se conectam à máquina a partir da rede, mas é melhor verificar para ver o que está rodando no sistema. Por esta razão, estas aplicações são alvos frequentes de substituições por invasores. Crackers tentam cobrir seus rastros se eles abrirem portas de rede não autorizadas substituindo o netstat
e o lsof
com suas próprias, versões modificadas.
nmap
.
nmap -sT -O localhost
Starting Nmap 4.68 ( http://nmap.org ) at 2009-03-06 12:08 EST Interesting ports on localhost.localdomain (127.0.0.1): Not shown: 1711 closed ports PORT STATE SERVICE 22/tcp open ssh 25/tcp open smtp 111/tcp open rpcbind 113/tcp open auth 631/tcp open ipp 834/tcp open unknown 2601/tcp open zebra 32774/tcp open sometimes-rpc11 Device type: general purpose Running: Linux 2.6.X OS details: Linux 2.6.17 - 2.6.24 Uptime: 4.122 days (since Mon Mar 2 09:12:31 2009) Network Distance: 0 hops OS detection performed. Please report any incorrect results at http://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 1.420 seconds
portmap
por causa da presença do serviço sunrpc
. Entretanto, há também um serviço misterioso na porta 834. Para checar se a porta é associada com o a lista oficial de serviços conhecidos, digite:
cat /etc/services | grep 834
netstat
ou lsof
. Para verificar pela porta 834 usando o netstat
, use o seguinte comando:
netstat -anp | grep 834
tcp 0 0 0.0.0.0:834 0.0.0.0:* LISTEN 653/ypbind
netstat
é animadora por causa que se um cracker abrir uma porta clandestinamente em um sistema hackeado, não é susceptível de permitir que esta seja revelada através deste comando. Também, a opção [p]
revela o ID do processo (PID) do serviço que abriu a porta. Neste caso, a porta aberta pertence ao ypbind
(NIS), que é um serviço RPC manuseado em conjunto com o serviço portmap
.
lsof
revela informações similares ao netstat
já que ele é também capaz de ligar portas abertas à serviços:
lsof -i | grep 834
ypbind 653 0 7u IPv4 1319 TCP *:834 (LISTEN) ypbind 655 0 7u IPv4 1319 TCP *:834 (LISTEN) ypbind 656 0 7u IPv4 1319 TCP *:834 (LISTEN) ypbind 657 0 7u IPv4 1319 TCP *:834 (LISTEN)
lsof
, netstat
, nmap
, e services
para mais informações.
2.3. TCP Wrappers e xinetd
iptables
filtra pacotes de rede indesejados dentro da pilha de rede do kernel. Para serviços de rede que os utilizam, os TCP Wrappers adicionam uma camada a mais de proteção definindo quais hosts são ou não são permitidos conectar aos serviços de rede "envolvidos (wrapped)". Um tipo de serviço de rede wrapped é o xinetd
super server. O serviço é chamado super server porque ele controla conexões de um subconjunto de serviços de rede e refina ainda mais o controle de acesso.

Figura 2.4. Controle de Acesso para Serviços de Rede
xinetd
no controle de acesso aos serviços de rede e revisa como estas ferramentas podem ser usadas para melhorar tanto a autenticação e gerenciamento de utilização. Consulte a Seção 2.6, “IPTables” para informações sobre usar firewalls com iptables
.
2.3.1. TCP Wrappers
tcp_wrappers
e tcp_wrappers-libs
) são instalados por padrão e fornecem controle de acesso baseado no host para serviços de rede. O componente mais importante do pacote é a biblioteca /lib/libwrap.a
ou /lib64/libwrap.a
. Em termos gerais, um serviço TCP wrapped é um que foi compilado para a biblioteca libwrap.a
.
/etc/hosts.allow
e /etc/hosts.deny
) para determinar se o cliente é permitido ou não se conectar. Na maioria dos casos, ele então usa o syslog daemon (syslogd
) para gravar o nome do cliente solicitante e do serviço solicitado em /var/log/secure
ou /var/log/messages
.
libwrap.a
. Algumas dessas aplicações incluem /usr/sbin/sshd
, /usr/sbin/sendmail
, and /usr/sbin/xinetd
.
Nota
libwrap.a
, digite o seguinte comando como usuário root:
ldd <binary-name> | grep libwrap
libwrap.a
.
/usr/sbin/sshd
está ligado ao libwrap.a
:
[root@myServer ~]# ldd /usr/sbin/sshd | grep libwrap libwrap.so.0 => /lib/libwrap.so.0 (0x00655000) [root@myServer ~]#
2.3.1.1. Vantagens do TCP Wrappers
- Transparências tanto aos clientes e serviços de rede wrapped — Ambos clientes em conexão e o serviço de rede wrapped não estão atentos que os TCP Wrappers estão em uso. Usuários legítimos são autenticados e conectados ao serviço solicitado enquanto conexões de clientes banidos falham.
- Gerenciamento Centralizado de múltiplos protocolos — Os TCP Wrappers operam separadamente dos serviços de rede que protegem, permitindo muitas aplicações de servidor compartilhar um conjunto comum de arquivos de configurações de controle de acesso, para um gerenciamento mais simples.
2.3.2. Arquivos de Configuração dos TCP Wrappers
/etc/hosts.allow
/etc/hosts.deny
- Ele faz referencia ao
/etc/hosts.allow
— O serviço TCP wrapper analisa sequencialmente o arquivo/etc/hosts.allow
e aplica a primeira regra especificada para aquele serviço. Se ele encontra uma regra correspondente, ele permite a conexão. Se não, vai para o próximo passo. - Ele faz referência ao
/etc/hosts.deny
— O serviço TCP wrapper analisa sequencialmente o arquivo/etc/hosts.deny
. Se ele encontrar uma regra correspondente, ele nega a conexão. Se não, garante acesso ao serviço.
- Como as regras de acesso no
hosts.allow
são aplicadas primeiro, elas têm preferência sobre as regras especificadas nohosts.deny
. Portanto, se o acesso a um serviço é permitido nohosts.allow
, uma regra negando acesso ao mesmo serviçohosts.deny
é ignorado. - As regras em cada arquivo são lidas de cima para baixo e a primeira regra correspondente para um determinado serviço é a única aplicada. A ordem das regras é extremamente importante.
- Se nenhuma regra para o serviço é encontrada em qualquer arquivo ou nenhum arquivo existe, acesso ao serviço é garantido.
- Os serviços TCP wrappers não fazem cache das regras dos arquivos de acesso dos hosts, então quaisquer mudanças no
hosts.allow
ouhosts.deny
acontecem imediatamente, sem reiniciar os serviços de rede.
Atenção
/var/log/messages
ou /var/log/secure
. Isto é também o caso para uma regra que se extende por múltiplas linhas sem usar a barra invertida. O seguinte exemplo ilustra a porção relevante de uma mensagem de log para uma falha de regra devido a uma dessas circunstâncias:
warning: /etc/hosts.allow, line 20: missing newline or line too long
2.3.2.1. Formatando Regras de Acesso
/etc/hosts.allow
e /etc/hosts.deny
são idênticos. Cada regra deve estar em sua própria linha. Linhas em branco ou linhas que iniciam com um hash (#) são ignoradas.
<daemon list>: <client list> [: <option>: <option>: ...]
- <daemon list> — Uma lista separada por vírgula de nomes de processos (não os nomes dos serviços) ou o carácter coringa
ALL
. A lista daemon também aceita operadores (consulte a Seção 2.3.2.1.4, “Operadores”) para permitir maior flexibilidade. - <client list> — Uma lista separada por vígula de nomes de host, endereços IP de host, modelos especiais ou carácteres coringa que identificam os hosts afetados pela regra. A lista de clientes também aceita operadores listados na Seção 2.3.2.1.4, “Operadores” para permitir maior flexibilidade.
- <option> — Uma ação opcional ou lista separada por dois pontos de ações realizadas quando a regra é acionada. Campos opcionais suportam expansões, dão inicio à comandos shell, permitem ou negam acesso e alteram o comportamento de logging.
Nota
vsftpd : .example.com
vsftpd
) de qualquer host no domínio example.com
. Se esta regra aparecer no hosts.allow
, a conexão é aceita. Se esta regra aparecer no hosts.deny
, a conexão é rejeitada.
sshd : .example.com \ : spawn /bin/echo `/bin/date` access denied>>/var/log/sshd.log \ : deny
sshd
) é tentada a partir de um host no domínio example.com
, executa o comando echo
para anexar a tentativa ao arquivo de log especial e nega a conexão. Pelo motivo que a diretiva opcional deny
é usada, esta linha nega o acesso mesmo se ele aparecer no arquivo hosts.allow
. Consulte a Seção 2.3.2.2, “Campos de Opção” para uma visão mais detalhada das opções disponíveis.
2.3.2.1.1. Carácteres Coringa (wildcards)
ALL
— Corresponde a tudo. Ele pode ser usado para ambas listas de daemons e lista de clientes.LOCAL
— Corresponde a qualquer host que não contém um ponto (.), como o localhost.KNOWN
— Corresponde a qualquer host onde o hostname e endereço de host são conhecidos ou onde o usuário é conhecido.UNKNOWN
— Corresponde a qualquer host onde o hostname ou endereço de host são desconhecidos ou onde o usuário é desconhecido.PARANOID
— Corresponde a qualquer host onde o hostname não corresponde ao endereço de host.
Importante
KNOWN
, UNKNOWN
e PARANOID
devem ser usados com cuidado, por causa que eles dependem em um servidor DNS em funcionamento para que a operação seja correta. Qualquer disruptura na resolução de nome pode impedir usuários legítimos de ganhar acesso ao serviço.
2.3.2.1.2. Modelos
- Hostname iniciando com ponto (.) — Colocar um ponto no início de um hostname corresponde a todos os hosts compartilhando os componentes listados do nome. O exemplo a seguir se aplica a qualquer host dentro do domínio
example.com
:ALL : .example.com
- Endereço de IP terminando com um ponto (.) — Colocar um ponto no final do endereço IP corresponde a todos os hosts compartilhando os grupos numéricos iniciais de um endereço de IP. O exemplo seguinte se aplica a qualquer host dentro da rede
192.168.x.x
:ALL : 192.168.
- endereço de IP /par máscara de rede — Expressões de máscara de rede podem também ser usadas como um modelo para controlar acesso a um grupo particular de endereços IP. O exemplo seguinte se aplica a qualquer host com uma variação de endereço de
192.168.0.0
até192.168.1.255
:ALL : 192.168.0.0/255.255.254.0
Importante
Quando trabalhar com espaço de endereço IPv4, a extensão do endereço/prefixo (prefixlen) declarações de par (notação CIDR) não são suportadas. Somente regras IPv6 podem usar este formato. - [endereço IPv6]/par prefixlen — pares [net]/prefixlen podem também ser usados como um modelo para controlar acesso a um grupo particular de endereços IPv6. O exemplo seguinte se aplicaria a qualquer host com uma faixa de
3ffe:505:2:1::
até3ffe:505:2:1:ffff:ffff:ffff:ffff
:ALL : [3ffe:505:2:1::]/64
- O asterisco (*) — Asteriscos podem ser usados para corresponder grupos inteiros de hostnames ou endereços de IP, desde que eles não sejam misturados em uma lista de clientes contendo outros tipos de modelos. O exemplo seguinte se aplicaria a qualquer host dentro do domínio
example.com
:ALL : *.example.com
- A barra (/) — Se uma lista de clientes iniciar com uma barra (/), ela é tratada como um nome de arquivo. Isto é útil se regras especificando números grandes de hosts são necessárias. O exemplo seguinte se refere aos TCP Wrappers para o arquivo
/etc/telnet.hosts
para todas as conexões Telnet:in.telnetd : /etc/telnet.hosts
hosts_access
para mais informações.
Atenção
2.3.2.1.3. Portmap e TCP Wrappers
Portmap
de TCP Wrappers não suporta busca de hosts, que siginifca que o portmap
não pode usar hostnames para identificar hosts. Consequentemente, regras de controle de acesso para portmap no hosts.allow
ou hosts.deny
devem usar endereços de IP ou a palavra chave ALL
, para especificar os hosts.
portmap
podem não ter efeito imediatamente. Você pode necessitar reiniciar o serviço portmap
.
portmap
para operar, então esteja atento à estas limitações.
2.3.2.1.4. Operadores
EXCEPT
. Ele pode ser usado em ambas listas daemon e listas clientes para uma regra.
EXCEPT
permite exceções específicas para abranger correspondências com a mesma regra.
hosts.allow
, todos os hosts example.com
são permitidos se conectarem a todos os serviços, exceto cracker.example.com
:
ALL: .example.com EXCEPT cracker.example.com
hosts.allow
, clientes da rede 192.168.0.x
podem usar todos os serviços exceto para o FTP:
ALL EXCEPT vsftpd: 192.168.0.
Nota
EXCEPT
. Isto permite a outros administradores rapidamente escanear os arquivos apropriados para ver quais hosts tem acesso permitido ou negado aos serviços sem ter de classificar operadores EXCEPT
.
2.3.2.2. Campos de Opção
2.3.2.2.1. Registro de Logs
severity
.
example.com
são registradas à facilidade authpriv
syslog
(por causa que nenhum valor de facilidade é especificado) com uma prioridade de emerg
:
sshd : .example.com : severity emerg
severity
. O seguinte exemplo registra em log qualquer tentativa de conexão SSH por hosts do domínio example.com
à facilidade local0
com a prioridade de alert
:
sshd : .example.com : severity local0.alert
Nota
syslogd
) esteja configurado para registrar no log a facilidade local0
. Consulte a página man syslog.conf
para informações sobre configurar facilidades de log personalizadas.
2.3.2.2.2. Controle de Acesso
allow
ou deny
como a opção final.
client-1.example.com
, mas negam conexões do client-2.example.com
:
sshd : client-1.example.com : allow sshd : client-2.example.com : deny
hosts.allow
ou hosts.deny
. Alguns administratores consideram isso uma maneira fácil de organizar regras de acesso.
2.3.2.2.3. Comandos Shell
spawn
— Realiza um comando shell como um processo filho. Esta diretiva pode realizar tarefas como usar o/usr/sbin/safe_finger
para obter mais informações sobre o cliente solicitante ou criar arquivos especiais de log usando o comandoecho
.No exemplo seguinte, clientes que tentam acessar os serviços Telnet a partir do domínioexample.com
são silenciosamente registrados ao log de um arquivo especial:in.telnetd : .example.com \ : spawn /bin/echo `/bin/date` from %h>>/var/log/telnet.log \ : allow
twist
— Substitui o serviço solicitado com o comando especificado. Esta diretiva é frequentemente usada para configurar armadilhas para invasores (também chamados "honey pots" (potes de mel). Ele também pode ser usado para enviar mensagens para clientes em conexão. A diretivatwist
deve ocorrer no final da linha da regra.No exemplo seguinte, clientes que tentam acessar os serviços FTP do domínioexample.com
recebem uma mensagem usando o comandoecho
:vsftpd : .example.com \ : twist /bin/echo "421 This domain has been black-listed. Access denied!"
hosts_options
.
2.3.2.2.4. Expansões
spawn
e twist
, fornecem informações sobre o cliente, servidor e processos envolvidos.
%a
— Retorna o endereço IP do cliente.%A
— Retorna o endereço IP do servidor.%c
— Retorna uma variedade de informações dos clientes, como o nome de usuário e hostname ou o nome de usuário e endereço IP.%d
— Retorna o nome do processo daemon.%h
— Retorna o hostname do cliente (ou endereço IP, se o hostname estiver indisponível).%H
— Retorna o hostname do servidor (ou endereço IP, se o hostname estiver indisponível).%n
— Retorna o hostname do cliente. Se indisponível,unknown
é mostrado. Se o hostname do cliente e endereço de host não correpondem,paranoid
é mostrado.%N
— Retorna o hostname do servidor. Se indisponível,unknown
é mostrado. Se o hostname do servidor e endereço de host não correspondem,paranoid
é mostrado.%p
— Retorna o ID do processo daemon.%s
— Retorna vários tipos de informações do servidor, como processo daemon e o host ou endereço IP do servidor.%u
— Retorna o nome de usuário. Se indisponível,unknown
é mostrado.
spawn
para identificar o host do cliente em um arquivo de log personalizado.
sshd
) são tentadas de um host no domínio example.com
, execute o comando echo
para registrar as tentativas, incluindo o hostname do cliente (usando a expansão %h
), a um arquivo especial:
sshd : .example.com \ : spawn /bin/echo `/bin/date` access denied to %h>>/var/log/sshd.log \ : deny
example.com
são informados que eles foram banidos do servidor:
vsftpd : .example.com \ : twist /bin/echo "421 %h has been banned from this server!"
hosts_access
(man 5 hosts_access
) e a página man para hosts_options
.
2.3.3. xinetd
xinetd
é um super serviço do TCP Wrapper que controla acesso de um sub conjuntos de serviços de redes populares, incluindo FTP, IMAP e Telnet. Ele também fornece opções de configuração especificas de serviço para controle de acesso, registro de log melhorados, vinculação, redirecionamento, e controle de utilização de recursos.
xinetd
, o super serviço recebe o pedido e verifica por quaisquer regras de controle de acesso dos TCP Wrappers.
xinetd
verifica que a conexão é permitida sobre suas próprias regras de acesso para esse serviço. Ele também verifica que o serviço é capaz de ter mais recursos atribuídos a ele e não quebra nenhuma das regras definidas.
xinetd
então inicia uma instância do serviço solicitado e passa o controle da conexão à ele. Depois da conexão ter sido estabelecida, o xinetd
não faz mais parte da comunicação entre o cliente e o servidor.
2.3.4. Arquivos de Configuração xinetd
xinetd
são como a seguir:
/etc/xinetd.conf
— O arquivo de configuração global doxinetd
./etc/xinetd.d/
— O diretório contendo todos os arquivos especificos do serviço.
2.3.4.1. O arquivo /etc/xinetd.conf
/etc/xinetd.conf
contém definições de configurações gerais que afetam todos os serviços sob o controle do xinetd
. Ele é lido quando o serviço xinetd
é primeiramente iniciado, então para as mudanças de configuração terem efeito, você precisa reiniciar o serviço xinetd
. O seguinte é um modelo do arquivo /etc/xinetd.conf
:
defaults { instances = 60 log_type = SYSLOG authpriv log_on_success = HOST PID log_on_failure = HOST cps = 25 30 } includedir /etc/xinetd.d
xinetd
:
instances
— Especifica o número máximo de pedidos simultâneos que oxinetd
pode processar.log_type
— Configura oxinetd
para usar a facilidade de logauthpriv
, que grava entradas no log para o arquivo/var/log/secure
. Adicionar uma diretiva comoFILE /var/log/xinetdlog
criaria um arquivo de log personalizado chamadoxinetdlog
no diretório/var/log/
.log_on_success
— Configura oxinetd
para registrar no log tentativas de conexão com sucesso. Por padrão, o endereço IP do host remoto e o ID de processo do servidor que processo o pedido são gravados,log_on_failure
— Configura oxinetd
para logar tentativas de conexão com falhas ou se a conexão foi negada.cps
— Configura oxinetd
para permitir não mais que 25 conexões por segundo para qualquer serviço dado. Se este limite é excedido, o serviço é suspenso por 30 segundos.includedir
/etc/xinetd.d/
— Inclui opções declaradas nos arquivos de configuração de serviço específico localizados no diretório/etc/xinetd.d/
. Consulte a Seção 2.3.4.2, “O Diretório /etc/xinetd.d/” para mais informações.
Nota
log_on_success
e log_on_failure
no /etc/xinetd.conf
são também modificadas nos arquivos de configuração de serviços específicos. Mais informações podem entretanto aparecer no arquivo de log do serviço do que o /etc/xinetd.conf
pode indicar. Consulte a Seção 2.3.4.3.1, “Opções de Registro de Log” para mais informações.
2.3.4.2. O Diretório /etc/xinetd.d/
/etc/xinetd.d/
contém os arquivos de configuração para cada serviço gerenciado pelo xinetd
e os nomes dos arquivos são correlacionados ao serviço. Como ocorre com o xinetd.conf
, este diretório é somente leitura quando o serviço é iniciado. Para quaisquer mudanças terem efeito, o administrador deve reiniciar o serviço xinetd
.
/etc/xinetd.d/
usam as mesmas convenções como o /etc/xinetd.conf
. A razão primária que a configuração para cada serviço é armazenada em um arquivo separado é fazer a personalização mais fácil e menos suscetíveis de afetar outros serviços.
/etc/xinetd.d/krb5-telnet
:
service telnet { flags = REUSE socket_type = stream wait = no user = root server = /usr/kerberos/sbin/telnetd log_on_failure += USERID disable = yes }
telnet
:
service
— Especifica o nome do serviço, normalmente um dos listados no arquivo/etc/services
.flags
— Define um número qualquer de atributos para a conexão. OREUSE
instrui oxinetd
para reusar p socket para a conexão Telnet.Nota
O sinalizadorREUSE
está obsoleto. Todos os serviços agora usam implicitamente o sinalizadorREUSE
.socket_type
— Define o tipo de socket de rede parastream
.wait
— Especifica se o serviço é single-threaded (yes
) ou multi-threaded (no
).user
— Especifica qual ID de usuário o processo o rodará.server
— Especifica qual binário executável a dar início.log_on_failure
— Especifica os parâmetros de registro de log para olog_on_failure
além daqueles já definidos emxinetd.conf
.disable
— Especifica se o serviço está inativo (yes
) ou ativo (no
).
xinetd.conf
para mais informações sobre estas opções e seu uso.
2.3.4.3. Aterando Arquivos de Configuração xinetd
xinetd
. Esta seção destaca algumas das opções mais comumente usadas.
2.3.4.3.1. Opções de Registro de Log
/etc/xinetd.conf
e os arquivos específicos de serviço dentro do diretório /etc/xinetd.d/
.
ATTEMPT
— Registra em log que uma tentativa com falha foi feita (log_on_failure
).DURATION
— Registra em log o período de tempo que o serviço é usado por um sistema remoto (log_on_success
).EXIT
— Registra em log o estado de saída ou sinal de término do serviço (log_on_success
).HOST
— Registra em log o endereço de IP do host remoto (log_on_failure
elog_on_success
).PID
— Registra em log o ID do processo do servidor recebendo o pedido (log_on_success
).USERID
— Registra em log o usuário remoto usando o método definido em RFC 1413 para todos os serviços de stream multi-threaded (log_on_failure
elog_on_success
).\n\t\n
xinetd.conf
.
2.3.4.3.2. Opções de Controle de Acesso
xinetd
podem escolher usar as regras de acesso de hosts TCP Wrappers, fornecer controle de acesso pelos arquivos de configuração xinetd
ou uma mistura de ambos. Consulte a Seção 2.3.2, “Arquivos de Configuração dos TCP Wrappers” para mais informações sobre os arquivos de controle de acesso de hosts TCP Wrappers.
xinetd
para controlar o acesso aos serviços.
Nota
xinetd
reiniciar o serviço xinetd
.
xinetd
somente afeta serviços controlados pelo xinetd
.
xinetd
difere do método usado pelos TCP Wrappers. Enquanto os TCP Wrappers colocam toda a configuração de acesso dentro de dois arquivos /etc/hosts.allow
e /etc/hosts.deny
, o controle de acesso do xinetd
é encontrado em cada um dos arquivos de configuração do serviço no diretório /etc/xinetd.d/
.
xinetd
:
only_from
— Permite somente os hosts especificados usarem o serviço.no_access
— Bloqueia os hosts listados de usar o serviço.access_times
— Especifica o período de tempo quando um determinado serviço pode ser usado. O período de tempo deve ser declarado no formato 24 horas, HH:MM-HH:MM.
only_from
e no_access
podem usar uma lista de endereços de IP ou nomes de host, ou pode especificar uma rede inteira. Como os TCP Wrappers, combinar o controle de acesso xinetd
com a configuração de log avançada pode aumentar a segurança bloqueando pedidos dos hosts banidos enquanto grava a verbosidade de cada tentativa de conexão.
/etc/xinetd.d/telnet
pode ser usado para bloquear o acesso Telnet de um grupo de rede particular e restringe o intervalo de tempo de total que mesmo usuários permitidos podem se logar:
service telnet { disable = no flags = REUSE socket_type = stream wait = no user = root server = /usr/kerberos/sbin/telnetd log_on_failure += USERID no_access = 172.16.45.0/24 log_on_success += PID HOST EXIT access_times = 09:45-16:15 }
172.16.45.0/24
, como 172.16.45.2
, tenta acessar o serviço Telnet, ele recebe a seguinte mensagem:
Conexão fechada por um host externo.
/var/log/messages
conforme a seguir:
Sep 7 14:58:33 localhost xinetd[5285]: FAIL: telnet address from=172.16.45.107 Sep 7 14:58:33 localhost xinetd[5283]: START: telnet pid=5285 from=172.16.45.107 Sep 7 14:58:33 localhost xinetd[5283]: EXIT: telnet status=0 pid=5285 duration=0(sec)
xinetd
, é importante entender o relacionamento entre os dois mecanismos de controle de acesso.
xinetd
quando um cliente solicita uma conexão:
- O daemon
xinetd
acessa as regras de acesso de hosts do TCP Wrappers usando uma chamada da bibliotecalibwrap.a
. Se uma regra de negação corresponde ao cliente, a conexão é passada para oxinetd
. - O daemon
xinetd
verifica suas próprias regras de controle de acesso tanto para o serviçoxinetd
e o serviço solicitado. Se uma regra de negação corresponde ao cliente, a conexão é despejada. Caso contrário , oxinetd
inicia uma instância do serviço solicitado e passa o controle da conexão a esse serviço.
Importante
xinetd
. Um erro de configuração pode causar efeitos indesejáveis,
2.3.4.3.3. Opções de Associação e Redirecionamento
xinetd
suporta a associação do serviço a um endereço de IP e redireciona pedidos de entrada desse serviço para outro endereço IP, hostname ou porta.
bind
nos arquivos de configuração de serviço específicos e liga o serviço a um endereço IP no sistema. Quando este é configurado, a opção bind
somente permite pedidos ao endereço de IP correto para acessar o serviço. Você pode usar este método para associar diferentes serviços à interfaces de redes diferentes baseadas em requerimentos.
redirect
aceita um endereço IP ou hostname seguido por um número de porta. Ela configura o serviço para redirecionar quaisquer pedidos para este serviço ao host e número de porta especificados. Este recurso pode ser usado para apontar para um outro número de porta no mesmo sistema, redirecionar o pedido para um endereço IP diferente na mesma máquina, deslocar o pedido para um sistema e número de porta totalmente diferentes, ou qualquer combinação destas opções. Um usuário conectando a um certo serviço em um sistema pode portanto ser reencaminhado a um outro sistema sem ruptura.
xinetd
é capaz de realizar este redirecionamento reproduzindo um processo que permanece vivo pela duração da conexão entre a máquina cliente solicitante e o host que fornece o serviço, transferindo dados entre os dois sistemas.
bind
e redirect
são mais claramente evidentes quando elas são usadas em conjunto. Associando um serviço à um endereço IP determinado em um sistema e então redirecionar os pedidos para este serviço a uma segunda máquina que somente a primeira máquina pode ver, um sistema interno pode ser usado para fornecer serviços para uma rede totalmente diferente. Alternativamente, estas opções podem ser usadas para limitar a exposição de um determinado serviço em uma máquina multihome para endereços IP conhecidos, tanto quanto redireciona quaisquer pedidos para esse serviço para uma outra máquina especialmente configurada para este propósito.
service telnet { socket_type = stream wait = no server = /usr/kerberos/sbin/telnetd log_on_success += DURATION USERID log_on_failure += USERID bind = 123.123.123.123 redirect = 10.0.1.13 23 }
bind
e redirect
neste arquivo garantem que o serviço Telnet nesta máquina é ligado a um endereço IP externo (123.123.123.123
), o que está na internet. Além disso, qualquer pedido pelo serviço Telnet enviado ao 123.123.123.123
é redirecionado pelo segundo adaptador de rede para um endereço Ip interno (10.0.1.13
) que somente o firewall e sistemas internos podem acessar. O firewall então envia a comunicação entre os dois sistemas e o sistema em conexão pensa que está conectado ao 123.123.123.123
quando na verdade está conectado a uma máquina diferente.
xinetd
são configurados com as opções bind
e redirect
, a máquina gateway pode agir como uma proxy entre sistemas do lado de fora e uma máquina interna particular configurada para fornecer o serviço. Além disso, os vários controles de acesso xinetd
e opções de log estão também disponíveis para proteção adicional.
2.3.4.3.4. Opções de Gerenciamento de Recursos
xinetd
pode adicionar um nível básico de proteção contra ataques Dos (Denial of Service). A seguir está uma lista de diretivas que podem auxiliar na limitação da efetividade desses ataques:
per_source
— Define o número máximo de instâncias de um serviço por endereço IP de origem. Ele aceita somente números inteiros como um argumento e pode ser usado em ambosxinetd.conf
e nos arquivos de configuração de serviço específicos no diretórioxinetd.d/
.cps
— Define o número máximo de conexões por segundo. Esta diretiva leva dois argumentos de números inteiros separados por um espaço em branco. O primeiro argumento é o número máximo de conexões permitidas para o serviço por segundo. O segunto argumento é o número de segundos que oxinetd
deve esperar antes de re ativar o serviço. Ele aceita somente números inteiros como argumentos e pode ser usado tanto no arquivoxinetd.conf
ou nos arquivos de configuração de serviço específicos no diretórioxinetd.d/
.max_load
— Define o uso de CPU ou limite da média de carregamento para um serviço. Ele aceita um argumento de número de ponto flutuante.A média de carregamento é uma medida aproximada de quantos processos estão ativos em um determinado momento. Veja os comandosuptime
,who
, eprocinfo
para mais informações sobre a média de carregamento.
xinetd
. Consulte a página man xinetd.conf
para maiores informações.
2.3.5. Recursos Adicionais
xinetd
estão disponíveis na documentação dos sistemas e na internet.
2.3.5.1. Documentação Instalada dos TCP Wrappers
xinetd
e o controle de acesso.
/usr/share/doc/tcp_wrappers-<version>/
— Este diretório contém um arquivoREADME
que discute como os TCP Wrappers funcionam e os riscos variados de spoofing do hostname e endereço de host existentes./usr/share/doc/xinetd-<version>/
— Este diretório contém um arquivoREADME
que discute aspectos de controle de acesso e um arquivosample.conf
com várias idéias para modificar os arquivos de configuração de serviço específicos no diretório/etc/xinetd.d/
.- As páginas man relacionadas dos TCP Wrappers e
xinetd
— Uma variedade de páginas man existem para várias aplicações e arquivos de configuração envolvidos com os TCP Wrappers exinetd
. A seguir estão algumas das mais importantes das páginas man:- Aplicações do Servidor
man xinetd
— A página man para oxinetd
.
- Arquivos de Configurações
man 5 hosts_access
— A página man para os arquivos de controle de acesso ao host dos TCP Wrappers.man hosts_options
— A página man para os campos de opções dos TCP Wrappers.man xinetd.conf
— A página man que lista as opções de configuração doxinetd
.
2.3.5.2. Web sites úteis sobre TCP Wrappers
- http://www.docstoc.com/docs/2133633/An-Unofficial-Xinetd-Tutorial — Um tutorial completo que discute as diferentes maneiras de otimizar os arquivos de configuração do
xinetd
para atender objetivos de segurança específicos.
2.3.5.3. Livros Relacionados
- Hacking Linux Exposed por Brian Hatch, James Lee, and George Kurtz; Osbourne/McGraw-Hill — Uma excelente fonte sobre segurança com informações sobre TCP Wrappers e
xinetd
.
2.4. Redes Privadas Virtuais (VPNs)
2.4.1. Como uma VPN funciona?
2.4.2. Openswan
2.4.2.1. Visão Geral
O Openswan é uma implementação de código aberto, no nível de kernel IPsec, disponível no Red Hat Enterprise Linux. Ele emprega protocolos de estabelecimento de chave IKE (Internet Key Exchange) v1 e v2, implementados como daemons no nível de usuário. O estabelecimento de chave manual é também possível via comandos ip xfrm
, entretanto isto não é recomendado.
O Openswan possui uma biblioteca embutida de criptografia, entretanto também suporta uma biblioteca NSS (Network Security Services) , que é totalmente suportada e requerida para cumprimento de segurança FIPS. Mais informações sobre o FIPS (Federal Information Processing Standard) pode ser encontrado na Seção 7.2, “Federal Information Processing Standard (FIPS)”.
Rode o comando yum install openswan
para instalar o Openswan.
2.4.2.2. Configuração
Este seção lista e explica diretórios e arquivos importantes usados para configurar o Openswan.
/etc/ipsec.d
- diretório principal. Armazena os arquivos relacionados do Openswan./etc/ipsec.conf
- arquivo de configuração principal. Mais arquivos de configuração*.conf
podem ser criados no/etc/ipsec.d
para configurações individuais./etc/ipsec.secrets
- arquivos secretos principais. Mais arquivos*.secrets
podem ser criados no/etc/ipsec.d
para configurações individuais./etc/ipsec.d/cert*.db
- Arquivos de banco de dados certificados. O padrão antigo do arquivo de banco de dados NSS écert8.db
. A partir do Red Hat Enterprise Linux 6 em diante, o banco de dados NSS sqlite são usados no arquivocert9.db
./etc/ipsec.d/key*.db
- Arquivos de banco de dados chave. O padrão antigo do banco de dados NSS ékey3.db
. A partir do Red Hat Enterprise Linux 6 em diante, os bancos de dados sqlite NSS são usados no arquivokey4.db
./etc/ipsec.d/cacerts
- Localização dos Certificate Authority (CA)./etc/ipsec.d/certs
- Localização dos certificados do usuário. Não necessário quando usar o NSS./etc/ipsec.d/policies
- Políticas dos grupos. As políticas podem ser definidas como block, clear, clear-or-private, private, private-or-clear./etc/ipsec.d/nsspassword
- O arquivo de senha NSS. Este arquivo não existe por padrão e é requerido se o banco de dados NSS em uso é criado com uma senha.
Esta seção lista algumas das opções de configuração disponíveis, a maioria escritas em /etc/ipsec.conf
.
protostack
- define qual pilha de protocolo é usada. A opção padrão no Red Hat Enterprise Linux 6 é netkey. Outros valores válidos são auto, klips e mast.nat_traversal
- define se a solução NAT para conexões é aceita. O padrão é não.dumpdir
- define a localização para despejo dos arquivos core.nhelpers
- Quando usar o NSS, define o número de segmentos usados para criptografar operações. Quando não estiver usando o NSS, define o número de processos usados para operações de criptografia.virtual_private
- sub-redes permitidas para a conexão cliente. A faixa que pode existir por detrás de um roteador NAT a que um cliente se conecta.plutorestartoncrash
- definido para sim por padrão.plutostderr
- caminho para o log de erro do pluto. Aponta para a localização do syslog por padrão.connaddrfamily
- pode ser definido tanto para ipv4 ou ipv6.
ipsec.conf(5)
.
2.4.2.3. Comandos
Nota
service ipsec start/stop
é o método recomendado para mudar o estado do serviço ipsec. Isto é também a técnica recomendada para iniciar e parar todos os outros serviços no Red Hat Enterprise Linux 6.
- Iniciando e parando o Openswan:
ipsec setup start/stop
service ipsec start/stop
- Adicionar/Deletar uma conexão:
ipsec auto --add/delete <connection name>
- Estabelecer/quebrar uma conexão
ipsec auto --up/down <connection-name>
- Gerando chaves RSA:
ipsec newhostkey --configdir /etc/ipsec.d --password password --output /etc/ipsec.d/<name-of-file>
- Checando políticas ipsec no Kernel:
ip xfrm policy
ip xfrm state
- Criando certificados auto assinados:
certutil -S -k rsa -n <ca-cert-nickname> -s "CN=ca-cert-common-name" -w 12 -t "C,C,C" -x -d /etc/ipsec.d
- Criando um certificado de usuário assinado pelo CA anterior:
certutil -S -k rsa -c <ca-cert-nickname> -n <user-cert-nickname> -s "CN=user-cert-common-name" -w 12 -t "u,u,u" -d /etc/ipsec.d
2.4.2.4. Recursos Openswan
- O pacote Openswan-doc: HTML, exemplos, README.*
- README.nss
2.5. Firewalls
Tabela 2.2. Tipos de Firewall
Método | Descrição | Vantagens | Desvantagens | ||||||
---|---|---|---|---|---|---|---|---|---|
NAT | Network Address Translation (NAT) coloca sub-redes IP privadas atrás de um ou pequeno grupo de endereços IP, mascarando todas as requisições em uma fonte ao invés de diversas. O kernel do Linux possui a funcionalidade NAT embutida através do subsistema do kernel Netfilter. |
|
| ||||||
Filtro de Pacote | Um firewall de filtro de pacote lê cada pacote de dados que passa por uma LAN. Ele pode ler e processar os pacotes por informações de cabeçalho e filtra o pacote baseado em conjuntos de regras programáveis implementada por um administrador de firewall. O kernel do Linux possui uma funcionalidade de filtro de pacotes embutida através do subsistema do kernel, o Netfilter. |
|
| ||||||
Proxy | Os firewalls de proxy filtram todas as requisições de um certo protocolo ou tipo de clientes LAN para uma máquina de proxy, que então faz essas requisições para a Internet em nome do cliente local. Uma máquina proxy age como um buffer entre os usuários remotos mal-intencionados e as máquinas clientes de rede internas. |
|
|
2.5.1. Netfilter e IPTables
iptables
.
2.5.1.1. Visão Geral do IPTables
iptables
, uma ferramenta de linha de comando semelhante à sintaxe de seu precedente, ipchains
, o qual o Netfilter/iptables substituiu no kernel 2.4 e posteriores do Linux.
iptables
usa o subsistema do Netfilter para aprimorar a conexão de rede, inspeção e processamento. O iptables
apresenta autenticação avançada, ações pré e pós roteamento, tradução de endereço de rede e encaminhamento de porta, todos em uma interface de linha de comando.
iptables
. Para mais informações detalhadas, consulte a Seção 2.6, “IPTables”.
2.5.2. Configuração de Firewall Básica
2.5.2.1. Firewall Configuration Tool
[root@myServer ~] # system-config-firewall

Figura 2.5. Firewall Configuration Tool
Nota
iptables
.
2.5.2.2. Habilitando e desabilitando o Firewall
- Disabled — Desabilitar o firewall fornece acesso completo ao seu sistema e não faz verificação de segurança. Isto deve ser selecionado somente se você estiver executando em uma rede confiável (não a Internet) ou precisar configurar um firewall padronizado usando a ferramenta de linha de comando iptables.
Atenção
As configurações do Firewall e quaisquer regras de firewall padronizada é armazenada no arquivo/etc/sysconfig/iptables
. Se você escolher Disabled e clicar em OK, estas configurações e regras do firewall serão perdidas. - Enabled — Esta opção configura o sistema para rejeitar conexões de entrada que não estão em reposta com requisições externas, tais como respostas de DNS ou requisições de DHCP. Se for necessário o acesso à serviços vindos desta máquina, você poderá escolher permitir serviços específicos através do firewall.Se você estiver conectando seu sistema à Internet, mas não planeja executar um servidor, esta é a escolha mais rápida.
2.5.2.3. Serviços Confiáveis
- WWW (HTTP)
- O protocolo HTTP é usado pelo Apache (e outros servidores da Web) para servir as páginas da Web. Se você planeja tornar seu servidor publicamente disponível, selecione esta caixa. Esta opção não é necessária para visualizar páginas localmente ou para desenvolver páginas da Web. Este serviço requer que o pacote
httpd
seja instalado.Habilitar o WWW (HTTP) não abrirá uma porta para o HTTPS, a versão SSL do HTTP. Se este serviço for necessário, selecione o item Secure WWW (HTTPS). - FTP
- O protocolo FTP é usado para transferir arquivos entre máquinas em uma rede. Se você planeja tornar seu FTP publicamente disponível, selecione este item. Este serviço requer que o pacote
vsftpd
seja instalado. - SSH
- Secure Shell (SSH) é um conjunto de ferramentas para se autenticar e executar comandos em uma máquina remota. Para permitir acesso remoto à esta máquina via ssh, selecione este item. Este serviço requer que o pacote
openssh-server
seja instalado. - Telnet
- A Telnet é um protocolo para autenticação em máquinas remotas. As comunicações da Telnet são descriptografadas e não fornecem nenhuma segurança contra o snooping de rede. Permitir acesso de entrada da Telnet não é recomendado. Para permitir acesso remoto à máquina via telnet, selecione este item. Este serviço requer que o pacote
telnet-server
seja instalado. - Mail (SMTP)
- O SMTP é um protocolo que permite hosts remotos se conectarem diretamente à sua máquina para a entrega de correio. Você não precisa habilitar este serviço se você coletar seu correio de um servidor ISP usando o POP3 ou IMAP, ou se você utilizar uma ferramenta como o
fetchmail
. Para permitir a entrega de correio para sua máquina, selecione esta caixa. Note que um servidor SMTP configurado inadequadamente pode permitir máquinas remotas usar seu servidor para enviar spam. - NFS4
- O Network File System (NFS) é um protocolo de compartilhamento de arquivos geralmente usado em sistemas *NIX. A Versão 4 deste protocolo é mais segura do que seus precedentes. Se você quiser compartilhar arquivos ou diretórios em seu sistema com outros usuários de rede, selecione esta caixa.
- Samba
- O Samba é uma implementação do protocolo de rede SMB de propriedade da Microsoft. Se você precisar compartilhar arquivos, diretórios ou impressoras conectadas localmente com máquinas Microsoft Windows, selecione esta caixa.
2.5.2.4. Outras Portas
iptables
. Por exemplo, para permitir que o IRC e protocolo de impressora da internet (IPP) passe pelo firewall, adicione o seguinte para a seção Other ports:
194:tcp,631:tcp
2.5.2.5. Salvando Configurações
iptables
e gravadas no arquivo /etc/sysconfig/iptables
. O serviço iptables
também é iniciado para que o firewall seja ativado imediatamente após salvar as opções selecionadas. Se o Disable firewall foi selecionado, o arquivo /etc/sysconfig/iptables
será removido e o serviço iptables
será interrompido imediatamente.
/etc/sysconfig/system-config-firewall
para que as configurações possam ser restauradas na próxima vez que o aplicativo for iniciado. Não edite este arquivo manualmente.
iptables
não é configurado para iniciar automaticamente durante a inicialização. Consulte a Seção 2.5.2.6, “Ativando o Serviço IPTables.” para mais informações.
2.5.2.6. Ativando o Serviço IPTables.
iptables
estiver em execução. Para iniciar manualmente o serviço, use o seguinte comando:
[root@myServer ~] # service iptables restart
iptables
inicia-se quando o sistema é inicializado, use o seguinte comando:
[root@myServer ~] # chkconfig --level 345 iptables on
2.5.3. Usando IPTables
iptables
é iniciar o serviço iptables
. Use o seguinte comando para iniciar o serviço iptables
:
[root@myServer ~] # service iptables start
Nota
ip6tables
pode ser delisgado se você desejar usar somente o serviço iptables
. Se desativar o ip6tables
lembre-se de desativar a rede IPv6 também. Nunca deixe um dispositivo de rede ativo sem um firewall.
iptables
a iniciar por default quando o sistema for inicializado, use o seguinte comando:
[root@myServer ~] # chkconfig --level 345 iptables on
iptables
a iniciar sempre que o sistema inicializar em runlevel 3, 4, ou 5.
2.5.3.1. Sintaxe de Comandos do IPTables
iptables
ilustra a sintaxe de comando básica:
[root@myServer ~ ] # iptables -A <chain> -j <target>
-A
especifica a regra a ser adicionada ao <chain>. Cada corrente é comprimida em um ou mais regras, e é portanto também conhecida como um ruleset.
-j <target>
especifica o alvo da regra; ex: o que fazer se o pacote coincide com a regra. Exemplos de alvos embutidos são ACCEPT, DROP e REJECT.
iptables
para mais informações sobre as correntes disponíveis, opções e alvos.
2.5.3.2. Políticas de Firewall Básicas
iptables
contém uma política padrão e zero ou mais regras que funcionam em conjunto com a política padrão para definir o conjunto de regras (ruleset) geral para o firewall.
[root@myServer ~ ] # iptables -P INPUT DROP [root@myServer ~ ] # iptables -P OUTPUT DROP
[root@myServer ~ ] # iptables -P FORWARD DROP
2.5.3.3. Salvando e Restaurando as Regras IPTables
iptables
são transitórias; se o sistema for reinicializado ou se o serviço iptables
for reiniciado, as regras serão removidas automaticamente e redefinidas. Para salvar as regras para que sejam carregadas quando o serviço iptables
é iniciado, use o seguinte comando:
[root@myServer ~ ] # service iptables save
/etc/sysconfig/iptables
e são aplicadas sempre que o serviço é iniciado ou quando a máquina é reinicializada.
2.5.4. Filtros de IPTables Comuns
[root@myServer ~ ] # iptables -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
[root@myServer ~ ] # iptables -A INPUT -p tcp -m tcp --dport 443 -j ACCEPT
Importante
iptables
, a ordem é importante.
-I
. Por exemplo:
[root@myServer ~ ] # iptables -I INPUT 1 -i lo -p all -j ACCEPT
iptables
para aceitar conexões de clientes remotos SSH. Por exemplo, as regras a seguir permitem acesso SSH remoto:
[root@myServer ~ ] # iptables -A INPUT -p tcp --dport 22 -j ACCEPT [root@myServer ~ ] # iptables -A OUTPUT -p tcp --sport 22 -j ACCEPT
iptables
.
2.5.5. FORWARD
e Regras NAT
iptables
fornece políticas de roteação e encaminhamento que podem ser implementadas para impedir o uso anormal dos recursos de rede.
FORWARD
permite que um administrador controle onde os pacotes podem ser roteados dentro de uma LAN. Por exemplo, para permitir o encaminhamento de uma LAN inteira (considerando-se que o firewall/gateway receba um endereço IP na eth1), use as regras a seguir:
[root@myServer ~ ] # iptables -A FORWARD -i eth1 -j ACCEPT [root@myServer ~ ] # iptables -A FORWARD -o eth1 -j ACCEPT
eth1
.
Nota
[root@myServer ~ ] # sysctl -w net.ipv4.ip_forward=1
/etc/sysctl.conf
como a seguir:
net.ipv4.ip_forward = 0
net.ipv4.ip_forward = 1
sysctl.conf
:
[root@myServer ~ ] # sysctl -p /etc/sysctl.conf
2.5.5.1. Postrouting e Mascaramento de IP
[root@myServer ~ ] # iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
-t nat
) e especifica a corrente POSTROUTING embutida para o NAT (-A POSTROUTING
) no dispositivo de rede externo do firewall (-o eth0
).
-j MASQUERADE
é especificado para mascarar o endereço IP de um nó com o endereço IP externo do firewall/gateway.
2.5.5.2. Pre roteamento
-j DNAT
da corrente PREROUTING no NAT para especificar um endereço IP de destino e porta para onde pacotes de entrada requisitando uma conexão para seu serviço interno possam ser encaminhados
[root@myServer ~ ] # iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT --to 172.31.0.23:80
Nota
[root@myServer ~ ] # iptables -A FORWARD -i eth0 -p tcp --dport 80 -d 172.31.0.23 -j ACCEPT
2.5.5.3. DMZs e IPTables
iptables
para rotear o tráfego para certas máquinas, tal como o servidor dedicado HTTP ou FTP, em um demilitarized zone (DMZ). Um DMZ é uma sub-rede local especial dedicada para fornecer serviços em uma portador público, tal como a Internet.
PREROUTING
para encaminhar os pacotes para o destino apropriado:
[root@myServer ~ ] # iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT --to-destination 10.0.4.2:80
2.5.6. Softwares Maliciosos e Spoof de Endereços IP
[root@myServer ~ ] # iptables -A OUTPUT -o eth0 -p tcp --dport 31337 --sport 31337 -j DROP [root@myServer ~ ] # iptables -A FORWARD -o eth0 -p tcp --dport 31337 --sport 31337 -j DROP
[root@myServer ~ ] # iptables -A FORWARD -s 192.168.1.0/24 -i eth0 -j DROP
Nota
DROP
e alvos REJECT
ao lidar com as regras adicionadas.
REJECT
nega acesso e retorna um erro de conexão negada
para usuários que tentam se conectar ao serviço. O alvo DROP
, como o nome implica, despeja o pacote sem qualquer aviso.
REJECT
é recomendado.
2.5.7. IPTables e Rastreamento de Conexão
iptables
usa um método chamado rastreamento de conexão para armazenar informações sobre conexões de entrada. Você pode permitir ou negar acesso baseado nos seguintes estados de conexão:
NEW
— Um pacote que requer uma nova conexão, tal como uma requisição HTTP.ESTABLISHED
— Um pacote que é parte de uma conexão existente.RELATED
— Um pacote que está requisitando uma nova conexão mas é parte de uma conexão existente. Por exemplo, o FTP usa a porta 21 para estabelecer uma conexão, mas os dados são transferidos em uma porta diferente (geralmente a porta 20).INVALID
— Um pacote que não é parte de nenhuma conexão na tabela de rastreamento de conexão.
iptables
rastreando com qualquer protocolo de rede, até mesmo se o próprio protocolo é stateless (sem estado) assim como o UDP. O exemplo a seguir mostra uma regra que usa o rastreamento de conexão para enviar somente os pacotes que são associados com uma conexão estabelecida:
[root@myServer ~ ] # iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
2.5.8. IPv6
ip6tables
. No Red Hat Enterprise Linux 6, ambos serviços IPv4 e IPv6 são habilitados por padrão.
ip6tables
é idêntica ao iptables
em todos os aspectos exceto que ele suporta os endereços 128 bits. Por exemplo, use o seguinte comando para habilitar as conexões SSH em um servidor de rede consciente do IPv6:
[root@myServer ~ ] # ip6tables -A INPUT -i eth0 -p tcp -s 3ffe:ffff:100::1/128 --dport 22 -j ACCEPT
2.5.9. Recursos Adicionais
2.5.9.1. Documentação de Firewall Instalada
- Consulte a Seção 2.6, “IPTables” para mais informações detalhadas sobre o comando
iptables
incluindo definições para diversas opções de comando. - A página man do
iptables
contém um breve sumário de diversas opções.
2.5.9.2. Websites de Firewall Úteis
- http://www.netfilter.org/ — A homepage oficial do Netfilter e do projeto
iptables
. - http://www.tldp.org/ — O Projeto de Documentação do Linux contém diversos guias úteis relacionados à criação de firewall e administração.
- http://www.iana.org/assignments/port-numbers — A lista oficial de portas de serviços comuns e registrados atribuídos pelo Internet Assigned Numbers Authority.
2.5.9.3. Documentação Relacionada
- Red Hat Linux Firewalls, by Bill McCarty; Red Hat Press — uma referência compreensiva para construção de redes e firewalls de servidor usando uma tecnologia de filtro de pacote de código aberto como o Netfilter e o
iptables
. Ele inclui tópicos que cobrem análise de logs de firewall, desenvolvimento de regras de firewall e padronização de seu firewall usando diversas ferramentas gráficas. - Linux Firewalls, by Robert Ziegler; New Riders Press — Contém informações ricas sobre a construção de firewalls usando o 2.2 kernel
ipchains
, como também o Netfilter eiptables
. Também são tratados tópicos de segurança adicionais como os problemas de acesso remoto e sistemas de detecção de intrusão.
2.6. IPTables
ipchains
para filtragem de pacotes e usavam listas de regras aplicadas ao pacote em cada passo do processo de filtragem. O kernel 2.4 introduziu o iptables
(também chamado de netfilter), o qual é semelhante ao ipchains
mas expande o alcance e controle disponíveis para filtrar pacotes de rede.
iptables
, e explica como regras de filtragem podem ser preservadas entre as reinicializações de sistema.
iptables
e instalar um firewall baseado nestas regras.
Importante
iptables
, mas o iptables
não pode ser usado se o ipchains
já estiver sendo executado. Se o ipchains
estiver presente durante a inicialização, o kernel emite um erro e não inicia o iptables
.
ipchains
não foi afetada por estes erros.
2.6.1. Filtro de Pacote
filter
— A tabela padrão para manipular pacotes de rede.nat
— Usado para alterar pacotes que criam uma nova conexão e usado para o Network Address Translation (NAT).mangle
— Usado para tipos específicos de alteração de pacote.
netfilter
.
filtragem
são estas:
- INPUT — Se aplica aos pacotes de rede que são direcionados para o host.
- OUTPUT — Se aplica ao pacotes de rede gerados localmente.
- FORWARD — Se aplica aos pacotes de rede roteados no host.
nat
são estas:
- PREROUTING — Altera os pacotes de rede quando chegam.
- OUTPUT — Altera os pacotes de rede gerados localmente antes de serem enviados..
- POSTROUTING — Altera pacotes de rede antes de serem enviados.
mangle
são estas:
- INPUT — Altera pacotes de rede alvo para a máquina.
- OUTPUT — Altera os pacotes de rede gerados localmente antes de serem enviados..
- FORWARD — Altera pacotes de rede roteados pela máquina.
- PREROUTING — Altera pacotes de entrada antes de serem roteados.
- POSTROUTING — Altera pacotes de rede antes de serem enviados.

Nota
/etc/sysconfig/iptables
ou /etc/sysconfig/ip6tables
.
iptables
inicia antes dos serviços relacionados ao DNS quando um sistema Linux é inicializado. Isto significa que as regras do firewall podem somente fazer referência à endereços de IP numéricos (por exemplo, 192.168.0.1). Nomes do domínio (por exemplo, host.example.com) em tais regras, produzem erros.
ACCEPT
para um pacote coincidente, o pacote pula o restante das verificações de regras e é permitido que continue com seu destino. Se uma regra especifica um alvo DROP
, aquele pacote é recusado ter acesso ao sistema e nada é retornado ao host que enviou ou pacote. Se uma regra especifica um alvo QUEUE
, o pacote é passado ao espaço de usuário. Se uma regra especifica o alvo opcional REJECT
, o pacote é despejado, mas um pacote de erro é enviado ao originador do pacote.
ACCEPT
, DROP
, REJECT
, ou QUEUE
. Se nenhuma destas regras na corrente se aplicar ao pacote, então o pacote será lidado de acordo com a política padrão.
iptables
configura estas tabelas, assim como instala tabelas se necessário.
2.6.2. Opções de Comando para IPTables.
iptables
. Se os aspectos a seguir de um pacote são usados geralmente como um critério:
- Packet Type — Especifica os tipos de pacotes que o comando filtra.
- Packet Source/Destination — Especifica quais pacotes o comando filtra baseado na fonte ou destino do pacote.
- Target — Especifica qual ação é tomada nos pacotes que coincidem com o critério acima.
iptables
específicas devem ser agrupadas de forma lógica, baseadas no propósito e condições da regra geral, para a regra ser válida. O restante desta seção explica opções mais utilizadas para o comando iptables
.
2.6.2.1. Estrutura das Opções do Comando IPTables
iptables
possuem a seguinte estrutura:
iptables [-t <table-name>] <command> <chain-name> \ <parameter-1> <option-1> \ <parameter-n> <option-n>
filter
será usada.
iptables
pode mudar de forma significante, dependendo do seu propósito.
iptables -D <chain-name> <line-number>
iptables
, é importante lembrar que alguns parâmetros e opções requerem mais parâmetros e opções para construir uma regra válida. Isto pode produzir um efeito cascata, com os parâmetros adicionais que requerem ainda mais parâmetros. Até que cada parâmetro e opção que requerem outro conjunto de opções sejam atendidos, a regra não é válida.
iptables -h
para visualizar uma lista compreensiva de estruturas de comando iptables
.
2.6.2.2. Opções de Comando
iptables
a realizar uma ação específica. Somente uma opção de comando é permitida por comando iptables
. Com a exceção do comando help, todos os comandos são escritos em letras maiúsculas.
iptables
são:
-A
— Adiciona a regra ao final da corrente especificada. Oposto à opçao-I
descrita abaixo, esta opção não toma um argumento inteiro. Ele sempre adiciona a regra ao final da corrente especificada.-D <integer> | <rule>
— Remove uma regra em uma corrente específica pelo número (como o5
para a quinta regra em uma corrente), ou por uma especificação de regra. A especificação de regra deve coincidir exatamente uma regra existente.-E
— Renomeia uma corrente definida por usuário. Uma corrente definida por usuário é qualquer corrente exceto as padrões, correntes pré-existentes. (consulte a opção-N
abaixo para informações sobre como criar correntes definidas por usuário). Isto é uma mudança de aparência e não afeta a estrutura da tabela.Nota
Se você tentar renomear uma das correntes padrões, o sistema irá reportar um erro deCorrespondência não encontrada
(Match not found). Você não poderá renomear correntes padrões.-F
— Libera a corrente selecionada, o qual remove efetivamente todas as regras na corrente. Se não for especificada nenhuma corrente, este comando liberará todas as regras de cada corrente.-h
— Fornece uma lista de estruturas de comando, assim como um sumário rápido de parâmetros de comando e opções.-I [<integer>]
— Insere a regra na corrente especificada em um ponto especificado por um argumento inteiro definido por um usuário. Se nenhum argumento é especificado a regra é inserida no topo da corrente.Importante
Como notado acima, a ordem de regras em uma corrente determina quais regras se aplicam à quais pacotes. Isto é importante lembrar quando adicionar regras usando tanto a opção-A
ou-I
.Isto é especialmente importante ao adicionar regras usando o-I
com um argumento inteiro. Se você especificar um número existente ao adicionar uma regra em uma corrente, oiptables
adiciona a nova regra antes (ou acima) da regra existente.-L
— Lista todas as regras na corrente especificada após o comando. Para listar todas as regras em todas as correntes na tabela defiltragem
padrão, não especifica uma corrente ou tabela. Caso contrário a sintaxe deve ser usada para listar as regras em uma corrente específica em uma tabela específica:iptables -L <chain-name> -t <table-name>
Opções adicionais para a opção de comando-L
, que fornece números de regra e permite mais verbosidade nas descrições da regra, são descritas na Seção 2.6.2.6, “Opções de Listagem”.-N
— Cria uma nova corrente com um nome de usuário específico. O nome de corrente deve ser único, caso contrário uma mensagem de erro é exibida.-P
— Estabelece a política padrão para a corrente especificada, para que quando pacotes passam por uma corrente inteira sem coincidir uma regra, eles são enviados para o alvo especificado, tal como ACCEPT ou DROP.-R
— Substitui uma regra na corrente especificada. O número de regra deve ser especificado após o nome da corrente. A primeira regra em uma corrente corresponde à regra número um.-X
— Remove uma corrente de usuário específico. Você não pode remover uma corrente embutida.-Z
— Estabelece os contadores de byte e pacote em todas as correntes para uma tabela para zero.
2.6.2.3. Opções de Parâmetro de IPTables
iptables
, incluindo aqueles usados para adicionar, remover, inserir ou substituir regras dentro de uma corrente específica, requer diversos parâmetros para construir uma regra de filtro de pacote.
-c
— Redefine os contadores para uma regra específica. Este parâmetro aceita as opçõesPKTS
eBYTES
para especificar quais contadores redefinir.-d
— Estabelece o hostname de destino, endereço IP, ou rede de um pacote que coincide a regra. Quando coincidir uma rede, o seguinte formato de endereço IP/netmasks são suportados:N.N.N.N/M.M.M.M
— Onde N.N.N.N é a classe de endereço IP e M.M.M.M é o netmask.N.N.N.N/M
— Onde N.N.N.N é o endereço IP e M é o bitmask.
-f
— Aplique estas regras somente à pacotes fragmentados.Você pode usar este caractere de ponto de exclamação (!
) antes deste parâmetro para especificar que somente os pacotes desfragmentados são coincidentes.Nota
Distinguir entre os pacotes fragmentados e desfragmentados é uma boa prática, apesar dos pacotes fragmentados serem uma parte padrão do protocolo IP.Inicialmente criado para permitir que pacotes IP viajem sob redes com tamanhos de estruturas diferentes, estas fragmentações de dias são mais usadas para gerar ataques de DoS usando pacotes mal-formados. Também vale notar que a fragmentação retira totalmente a permissão.-i
— Define a interface de rede de entrada, comoeth0
ouppp0
. Com oiptables
, este parâmetro opcional pode ser usado somente com as correntes INPUT e FORWARD quando usado com a tabelafilter
e a corrente PREROUTING com as tabelasnat
emangle
.Este parâmetro também suporta as seguintes opções especiais:- Caractere de ponto de exclamação (
!
) — Reverte a diretiva, o que significa que qualquer interface especificada é excluída desta regra. - Caractere de mais (
+
) — Um caractere curinga usado para coincidir todas as interfaces que coincidem com a faixa especificada. Por exemplo, o parâmetro-i eth+
aplicaria esta regra à qualquer interface de Ethernet mas excluiria qualquer outra interface, tal comoppp0
.
Se o parâmetro-i
é usado mas nenhuma interface é especificada, então todas as interfaces são afetadas pela regra.-j
— Pula para o alvo especificado quando um pacote coincide uma regra particular.Os alvos padrões sãoACCEPT
,DROP
,QUEUE
, eRETURN
.Opções estendidas também estão disponíveis através de módulos carregados pelo padrão com o Red Hat Enterprise Linuxiptables
pacote RPM. Alvos válidos nestes módulos incluemLOG
,MARK
, eREJECT
, entre outros. Consulte a página maniptables
para obter mais informações sobre estes e outros alvos.Esta opção também pode ser usada para direcionar um pacote que coincide com uma regra em particular para uma corrente definida por um usuário fora da corrente atual, então outras regras possam ser aplicadas ao pacote.Se não for especificado nenhum alvo, o pacote passa pela regra sem nenhuma ação. O contador para esta regra, no entanto, aumenta por um.-o
— Define a interface de rede de saída para uma regra. Esta opção é válida somente para correntes OUTPUT e FORWARD na tabelafilter
, e a corrente POSTROUTING nas tabelasnat
emangle
. Este parâmetro aceita as mesmas opções que o parâmetro de interface de rede de entrada (-i
).-p <protocol>
— Define o protocolo IP afetado pela regra. Este pode ser tanto oicmp
,tcp
,udp
, ouall
, ou pode ser um valor numérico, representando um destes ou um protocolo diferente. Você pode usar qualquer protocolo listado no arquivo/etc/protocols
.O protocolo "all
" significa que a regra se aplica à todos os protocolos suportados. Se nenhum protocolo for listado com esta regra, ele se torna retorna ao padrão "all
".-s
— Define a fonte para um pacote específico usando a mesma sintaxe como parâmetro de destino (-d
).
2.6.2.4. Opções de Coincidência de IPTables
iptables
. Por exemplo, -p <protocol-name>
habilita as opções para o protocolo especificado. Note que você também pode usar o ID de protoloco, ao invés do nome do protocolo. Consulte os seguintes exemplos, cada dos quais tem o mesmo efeito:
iptables -A INPUT -p icmp --icmp-type any -j ACCEPT
iptables -A INPUT -p 5813 --icmp-type any -j ACCEPT
/etc/services
. Para definição legível, recomenda-se que você use os nomes de serviços ao invés dos números de porta.
Atenção
/etc/services
para prevenir edição não autorizada. Se este arquivo for editável, invasores podem usá-lo para habilitar portas em sua máquina que você tenha fechado. Para proteger este arquivo, digite os seguintes comandos como usuário root:
[root@myServer ~]# chown root.root /etc/services [root@myServer ~]# chmod 0644 /etc/services [root@myServer ~]# chattr +i /etc/services
2.6.2.4.1. Protocolo TCP
-p tcp
):
--dport
— Define a porta de destino para o pacote.Para configurar esta opção, use um nome de serviço de rede (tal como o www ou smtp); um número de porta; ou uma classe de números de porta.Para especificar uma classe de números de porta, separe os dois números com dois pontos (:
). Por exemplo:-p tcp --dport 3000:3200
. A classe válida maior é0:65535
.Use um ponto de exclamação (!
) antes da opção--dport
para coincidir todos os pacotes que não usam aquele serviço ou porta de rede.Para navegar pelos nomes e aliases de serviços de rede e números de porta que eles usam, visualize o arquivo/etc/services
.A opção de coincidência do--destination-port
é sinônima da--dport
.--sport
— Define a porta fonte do pacote usando as mesmas opções que--dport
. A opção de coincidência--source-port
é sinônimo da--sport
.--syn
— Se aplica à todos os pacotes TCP criados para iniciar a comunicação, geralmente chamada de pacotes SYN. Quaisquer pacotes que carreguem um bloco de dados não são tocados.Use um ponto de exclamação (!
) antes da opção--syn
para coincidir com todos os pacotes que não são SYN.--tcp-flags <tested flag list> <set flag list>
— Permite que pacotes TCP que possuem específicos bits (sinalizadores) definidos, coincidirem com uma regra.A opção de coincidência--tcp-flags
aceita dois parâmetros. O primeiro parâmetro é a máscara; uma lista separada por vírgula de sinalizadores a serem examinados no pacote. O segundo parâmetro é uma lista separada por vírgula de sinalizadores que devem ser definidos para a regra que coincidir.Os possíveis sinalizadores são:ACK
FIN
PSH
RST
SYN
URG
ALL
NONE
Por exemplo, uma regraiptables
que contenha a seguinte especificação somente coincide com pacotes TCP que possuem o sinalizador SYN definido e os sinalizadores ACK e FIN não definidos:--tcp-flags ACK,FIN,SYN SYN
Use o ponto de exclamação (!
) antes do--tcp-flags
para reverter o efeito da opção de coincidência.--tcp-option
— Tenta coincidir com as opções de TCP específicas que podem ser definidas dentro de um pacote particular. Esta opção coincidente também pode ser revertida com o ponto de exclamação (!
).
2.6.2.4.2. Protocolo UDP
-p udp
):
--dport
— Especifica a porta de destino do pacote UDP, usando o nome de serviço, número de porta ou classe de número de portas. A opção de coincidência--destination-port
é sinônima de--dport
.--sport
— Especifica a porta fonte do pacote UDP, usando o nome de serviço, número de porta, ou classe de números de porta. A opção coincidente--source-port
é sinônima com--sport
.
--dport
e --sport
, para especificar uma classe de números de portas, separe os dois números com dois pontos (:). Por exemplo: -p tcp --dport 3000:3200
. A maior classe válida aceitável é 0:65535.
2.6.2.4.3. Protocolo ICMP
-p icmp
):
--icmp-type
— Define o nome e número do tipo de ICMP para coincidir com a regra. Uma lista de nomes ICMP válidos pode ser recuperada digitando o comandoiptables -p icmp -h
.
2.6.2.4.4. Módulos de Opção de Coincidência Adicional
iptables
.
-m <module-name>
, onde <module-name> é o nome do módulo.
- módulo
limit
— Coloca limites em quantos pacotes são coincididos em uma regra específica.Quando usado em conjunto com o alvoLOG
, o módulolimit
pode evitar uma inundação de pacotes coincidentes de encher o log do sistema com mensagens repetitivas ou usar os recursos do sistema.Consulte a Seção 2.6.2.5, “Opções de Alvo” para mais informações sobre o alvoLOG
.O módulolimit
habilita as seguintes opções:--limit
— Define o número máximo de coincidências para um período de tempo específico, especificado como um par<value>/<period>
. Por exemplo, usando o--limit 5/hour
permite-se cinco coincidências de regras por hora.Períodos podem ser especificados em segundos, minutos, horas ou dias.Se um modificador de número e tempo não forem utilizados, o valor padrão de3/hour
é assumido.--limit-burst
— Define um limite em um número de pacotes capazes de coincidir uma regra em uma vez.Esta opção é especificada como um número inteiro e deve ser usada em conjunto com a opção--limit
.Se não for especificado nenhum valor, o valor padrão de cinco (5) será assumido.
- módule
state
— Habilita coincidência de estado.O módulostate
habilita as seguintes opções:--state
— coincide um pacote com os seguintes estados de conexões:ESTABLISHED
— O pacote coincidente é associado com outros pacotes em uma conexão estabelecida. Você precisa aceitar este estado se você quiser manter uma conexão entre um cliente e um servidor.INVALID
— O pacote coincidente não pode ser ligado à uma conexão conhecida.NEW
— O pacote coincidente está tanto criando uma nova conexão ou é parte de uma conexão de duas vias ainda não vista. Você precisa aceitar este estado se você quiser permitir novas conexões para um serviço.RELATED
— O pacote coincidente inicia uma nova conexão relacionada de alguma forma a uma conexão existente. Um exemplo disto é o FTP que usa uma conexão para o controle de tráfego (porta 21), e uma conexão separada para a transferência de dados (porta 20).
Estes estados de conexão podem ser usados em conjunto um com o outro separando-os com com vírgulas, tais como-m state --state INVALID,NEW
.
mac
module — Habilita coincidência do endereço MAC de hardware.O módulomac
habilita a seguinte opção:--mac-source
— Coincide um endereço MAC de placa de interface de rede que enviou o pacote. Para excluir um endereço MAC de uma regra, coloque um ponto de exclamação (!
) antes da opção de coincidência--mac-source
.
iptables
para mais opções de coincidência disponíveis através de módulos.
2.6.2.5. Opções de Alvo
<user-defined-chain>
— Uma corrente definida pelo usuário dentro da tabela. Nomes de correntes definidas pelo usuário devem ser únicas. Este alvo passa o pacote à corrente especificada.ACCEPT
— Permite o pacote passar para seu destino ou para outra corrente.DROP
— Despeja o pacote sem responder ao requisitante. O sistema que enviou o pacote não é notificado da falha.QUEUE
— O pacote é enfileirado para manuseio por um aplicativo do espaço de usuário.RETURN
— Para a verificação de pacote contra as regras na corrente atual. Se o pacote com um alvoRETURN
coincide com uma regra em uma corrente chamada de outra corrente, o pacote é retornado à primeira corrente para retomar a verificação de regra onde ele parou. Se a regraRETURN
for usada em uma corrente embutida e o pacote não puder mover para sua corrente anterior, o alvo padrão para a corrente atual será usado.
LOG
— Registra em log todos os pacotes que coincidem com esta regra. Como os pacotes são autenticados pelo kernel, o arquivo/etc/syslog.conf
determina onde estas entradas de log são escritas. Por padrão, elas são colocadas no arquivo/var/log/messages
.Opções adicionais podem ser usadas após o alvoLOG
para especificar a forma na qual a autenticação ocorre:--log-level
— Define o nível de prioridade de um evento de log. Consulte a página mansyslog.conf
para obter uma lista de níveis de prioridade.--log-ip-options
— Registra em log qualquer opção definida no cabeçalho de um pacote IP.--log-prefix
— Coloca uma faixa de até 29 caracteres antes da linha do log quando ela é escrita. Isto é útil para escrever filtros de syslog para usar em conjunto com registro em log dos pacotes.Nota
Devido à um problema com esta opção, você precisa adicionar um espaço à direita ao valor log-prefix .--log-tcp-options
— Registra em log qualquer opção definida no cabeçalho de um pacote de TCP.--log-tcp-sequence
— Escreve o número sequencial de TCP para o pacote no log.
REJECT
— Envia um pacote de erro de volta ao sistema remoto e despeja o pacote.O alvoREJECT
aceita--reject-with <type>
(onde <type> é o tipo de rejeição) permitindo mais informações detalhadas a serem retornadas com pacote de erro. A mensagemport-unreachable
é o tipo de erro padrão dado se nenhuma opção for utilizada. Consulte a página maniptables
para obter uma lista completa de opções<type>
.
nat
, ou com a alteração do pacote usando a tabela mangle
, podem ser encontradas na página man do iptables
.
2.6.2.6. Opções de Listagem
iptables -L [<chain-name>]
, fornece uma visão geral básica das correntes atuais. As opções adicionais fornecem mais informações:
-v
— Exibe resultado de verbosidade, tal como o número de pacotes e bytes que cada corrente processou, o número de pacotes e bytes que cada regra coincidiu e quais as interfaces que se aplicam à regra específica.-x
— Expande números para seus valores exatos. Em um sistema ocupado, o número de pacotes e bytes processados por uma corrente específica ou regra pode ser abreviada paraKilobytes
,Megabytes
(Megabytes) ouGigabytes
. Esta opção força o número completo a ser exibido.-n
— Exibe os endereços IP e os números de porta em formato numérico, ao invés do hostname padrão e o formato de serviço de rede.--line-numbers
— Lista regras em cada corrente próxima à ordem numérica na corrente. Esta opção é útil para quando tentar remover a regra específica em uma corrente ou localizar onde inserir uma regra dentro de uma corrente.-t <table-name>
— Especifica um nome de tabela. Se omitido, torna-se tabela de filtro por padrão.
2.6.3. Salvando Regras de IPTables
iptables
são armazenadas na memória. Se o sistema for reiniciado antes de salvar o conjunto de regras do iptables
, todas as regras serão perdidas. Para as regras do netfilter persistirem através da inicialização do sistema, elas precisam ser salvas. Para salvar as regras netfilter, digite o seguinte comando como root:
/sbin/service iptables save
iptables
que roda o programa /sbin/iptables-save
e escreve a configuração do iptables
atual em /etc/sysconfig/iptables
. O arquivo /etc/sysconfig/iptables
existente é salvo como /etc/sysconfig/iptables.save
.
iptables
reaplica as regras salvas no /etc/sysconfig/iptables
usando o comando /sbin/iptables-restore
.
iptables
antes de submetê-la ao arquivo /etc/sysconfig/iptables
, por outro lado é possível copiar as regras iptables
para o arquivo a partir de outra versão do sistema deste arquivo. Isto fornece uma forma rápida de distribuir conjuntos de regras iptables
para multiplicar máquinas.
[root@myServer ~]# iptables-save > <filename>
where <filename>é um nome de usuário definido para seu conjunto de regras.
Importante
/etc/sysconfig/iptables
à outras máquinas, digite /sbin/service iptables restart
para as novas regras tomarem efeito.
Nota
iptables
(,/sbin/iptables
), o qual é usado para manipular as tabelas e correntes que constituem a funcionalidade do iptables
e o serviço iptables
, (/sbin/service iptables
), o qual é usado para habilitar e desabilitar o próprio serviço iptables
.
2.6.4. Scripts de Controle de IPTables
iptables
no Red Hat Enterprise Linux:
- Firewall Configuration Tool (
system-config-firewall
) — Uma interface gráfica para criar, ativar e salvar regras de firewall básicas. Consulte a Seção 2.5.2, “Configuração de Firewall Básica” para mais informações. /sbin/service iptables <option>
— Usado para manipular diversas funções deiptables
usando seu initscript. As seguintes opções estão disponíveis:start
— se um firewall é configurado (ou seja, o/etc/sysconfig/iptables
existe), todos osiptables
em execução são interrompidos completamente e depois iniciados usando o comando/sbin/iptables-restore
. Esta opção funciona somente se o módulo do kernelipchains
não for carregado. Para verificar se o módulo foi carregado, digite o seguinte comando como usuário root:[root@MyServer ~]# lsmod | grep ipchains
Se este comando retornar nenhum resultado, significa que o módulo não foi carregado. Se necessário, use o comando/sbin/rmmod
para remover o módulo.stop
— Se o firewall estiver rodando, as suas regras na memória serão liberadas e todos os módulos do iptables e auxiliares serão descarregados.Se a diretivaIPTABLES_SAVE_ON_STOP
no arquivo de configuração do/etc/sysconfig/iptables-config
é modificado de seu valor padrão parayes
,as regras atuais serão salvas em/etc/sysconfig/iptables
e quaisquer regras existentes serão movidas para o arquivo/etc/sysconfig/iptables.save
.Refer to Seção 2.6.4.1, “Arquivo de Configuração de Scripts de Controle do IPTables” para mais informações sobre o arquivoiptables-config
.restart
— Se um firewall estiver sendo executado, as regras do firewall na memória serão liberadas, e o firewall será iniciado novamente se estiver configurado no/etc/sysconfig/iptables
. Esta opção funciona somente se o módulo do kernelipchains
não for carregado.\n\t\nSe a diretivaIPTABLES_SAVE_ON_RESTART
no arquivo de configuração/etc/sysconfig/iptables-config
for modificada de seu valor padrão parayes
, as regras atuais serão salvas em/etc/sysconfig/iptables
e quaisquer regras existentes serão movidas para o arquivo/etc/sysconfig/iptables.save
.Refer to Seção 2.6.4.1, “Arquivo de Configuração de Scripts de Controle do IPTables” para mais informações sobre o arquivoiptables-config
.status
— Exibe o status do firewall e lista todas as regras ativas.A configuração padrão para esta opção exibe os endereços IP em cada regra. Para exibir as informações do domínio e hostname, edite o arquivo/etc/sysconfig/iptables-config
e mude o valor deIPTABLES_STATUS_NUMERIC
parano
. Consulte a Seção 2.6.4.1, “Arquivo de Configuração de Scripts de Controle do IPTables” para obter mais informações sobre o arquivoiptables-config
.panic
— Ribera todas as regras do firewall. A política de todas as tabelas configuradas está definida paraDROP
.Esta opção pode ser útil se um servidor estiver comprometido. Ao invés de desconectar fisicamente da rede ou fechar o sistema, você pode usar esta opção para interromper todos os tráfegos de rede futuros mas deixar a máquina em um estado pronto para análise ou outros investigações.save
— Salva as regras do firewall em/etc/sysconfig/iptables
usandoiptables-save
. Consulte a Seção 2.6.3, “Salvando Regras de IPTables” para mais informações.
Nota
ip6tables
pelo iptables
nos comandos /sbin/service
listados nesta seção. Para mais informações sobre o IPv6 e netfilter, consulte a Seção 2.6.5, “IPTables e IPv6”.
2.6.4.1. Arquivo de Configuração de Scripts de Controle do IPTables
iptables
é controlado pelo arquivo de configuração /etc/sysconfig/iptables-config
. Esta é uma lista das diretivas contidas neste arquivo:
IPTABLES_MODULES
— Especifica uma lista separada por espaços dos módulos deiptables
adicionais para carregar quando um firewall é ativado. Estes podem incluir a conexão de rastreamento e auxiliares do NAT.IPTABLES_MODULES_UNLOAD
— Descarrega módulos na reinicialização e pára. Esta diretiva aceita os seguintes valores:yes
— O valor padrão. Esta opção deve ser definida para alcançar um estado correto para um reinício ou parada de firewall.no
— Esta opção deve ser somente definida se existirem problemas para descarregar os módulos do netfilter.
IPTABLES_SAVE_ON_STOP
— Salva as regras atuais do firewall em/etc/sysconfig/iptables
quando um firewall é interrompido. Esta diretiva aceita os seguintes valores:yes
— Salva as regras existentes em/etc/sysconfig/iptables
quando o firewall é interrompido, movendo a versão anterior para o arquivo/etc/sysconfig/iptables.save
.no
— O valor padrão. Não salva regras existentes quando o firewall for interrompido.
IPTABLES_SAVE_ON_RESTART
— Salva regras atuais de firewall quando o firewall é reinicializado. Esta diretiva aceita os seguintes valores:yes
— Salva as regras existentes em/etc/sysconfig/iptables
quando o firewall é reiniciado, movendo a versão anterior para o arquivo/etc/sysconfig/iptables.save
.no
— O valor padrão. Não salva regras existentes quando o firewall é reiniciado.
IPTABLES_SAVE_COUNTER
— Salva e recupera todos os pacotes e contadores de bytes em todas as correntes e regras. Esta diretiva aceita os seguintes valores:yes
— Salva os valores do contador.no
— O valor default. Não salva os valores do contador.
IPTABLES_STATUS_NUMERIC
— Fornece resultado de endereços IP em forma númerica ao invés do domínio ou hostnames. Esta diretiva aceita os seguintes valores:yes
— O valor padrão. Retorna somente os endereços IP dentro do resultado do status.no
— Retorna o domínio ou hostnames dentro do resultado do status.
2.6.5. IPTables e IPv6
iptables-ipv6
estiver instalado, o netfilter no Red Hat Enterprise Linux pode filtrar a próxima geração de protocolo de Internet IPv6. O comando usado para manipular o netfilter do IPv6 é ip6tables
.
iptables
, exceto a tabela nat
que não é suportada ainda. Isto significa que ainda não é possível realizar a tarefa de tradução do endereços de rede IPv6, tal como o mascaramento e encaminhamento de porta.
ip6tables
são salvas no arquivo /etc/sysconfig/ip6tables
. Regras anteriores salvas pelos initscripts ip6tables
são salvas no arquivo /etc/sysconfig/ip6tables.save
.
ip6tables
estão armazenadas no /etc/sysconfig/ip6tables-config
, e os nomes para cada diretiva variam muito pouco dos equivalentes do iptables
.
iptables-config
IPTABLES_MODULES
: o equivalente no arquivo ip6tables-config
é IP6TABLES_MODULES
.
2.6.6. Recursos Adicionais
iptables
.\n\t\n
- Seção 2.5, “Firewalls” — Contém um capítulo sobre o papel de firewalls dentro da estratégia de segurança geral assim como as estratégias para construir as regras do firewall.
2.6.6.1. Documentação instaladas da IP Tables
man iptables
— Contém uma descrição doiptables
assim como uma lista compreensiva de alvos, opções e extensões coincidentes.
2.6.6.2. Websites de IPtables Úteis
- http://www.netfilter.org/ — O home do projeto netfilter/iptables. Contém informações diversas sobre o
iptables
, incluindo guias FAQ de Rusty Russell, o mantedor do firewall Linux IP. Os documentos HOWTO neste site tratam sobre tais conceitos de rede básicos, filtro de pacote de kernel e configurações do NAT. - http://www.linuxnewbie.org/nhf/Security/IPtables_Basics.html — Uma introdução para a forma que pacotes se movem através do kernel do Linux, mais uma introdução para construção básica de comandos
iptables
.
Capítulo 3. Criptografia
3.1. Dados parados
3.2. Criptografia de Disco Cheio
3.3. Criptografia baseado em Arquivo
3.4. Dados Ativos
3.5. Virtual Private Networks (Rede Privada Virtual)
3.6. Secure Shell (Shell Segura)
3.7. OpenSSL PadLock Engine
Nota
/etc/pki/tls/openssl.cnf
e adicione o seguinte no início de cada arquivo:
openssl_conf = openssl_init
[openssl_init] engines = openssl_engines [openssl_engines] padlock = padlock_engine [padlock_engine] default_algorithms = ALL dynamic_path = /usr/lib/openssl/engines/libpadlock.so init = 1
# openssl engine -c -tt
# openssl speed aes-128-cbc
# dd if=/dev/zero count=100 bs=1M | ssh -c aes128-cbc localhost "cat >/dev/null"
3.8. LUKS Disk Encryption
3.8.1. Implementação do LUKS no Red Hat Enterprise Linux
cryptsetup --help
) é aes-cbc-essiv:sha256 (ESSIV - Encrypted Salt-Sector Initialization Vector). Note que o programa de instalação, Anaconda, usa o modo XTS por padrão (aes-xts-plain64). O tamanho da chave padrão para o LUKS é 256 bits. O tamanho da chave padrão para o LUKS com o Anaconda (XTS mode) é 512 bits. Cífras que estão disponíveis são:
- AES - Advanced Encryption Standard - FIPS PUB 197
- Twofish (A 128-bit Block Cipher)
- Serpent
- cast5 - RFC 2144
- cast6 - RFC 2612
3.8.2. Criptografando Diretórios Manualmente
Atenção
3.8.3. Instruções Passo-a-Passo
- entre no runlevel 1:
telinit 1
- desmonte seu /home existente:
umount /home
- Se isto falhar, use o
fuser
para encontrar e eliminar processos se apoderando do /home:fuser -mvk /home
- verifique se o /home não está mais montado:
cat /proc/mounts | grep home
- Preencha sua partição com dados aleatórios:
dd if=/dev/urandom of=/dev/VG00/LV_home
Este processo leva horas para ser concluído.Importante
O processo, no entanto, é crucial para ter uma boa proteção contra tentativas de quebrar a criptografia. Deixe executando durante a noite. - inicialize sua partição:
cryptsetup --verbose --verify-passphrase luksFormat /dev/VG00/LV_home
- abra o dispositivo criptografado recentemente:
cryptsetup luksOpen /dev/VG00/LV_home home
- confirme que se encontra lá:
ls -l /dev/mapper | grep home
\n\t\n - crie um sistema de arquivos:
mkfs.ext3 /dev/mapper/home
\n\t\n - monte-o:
mount /dev/mapper/home /home
- verifique sua visibilidade:
df -h | grep home
- adicione o seguinte ao /etc/crypttab:
home /dev/VG00/LV_home none
- edite seu /etc/fstab, removendo a entrada antiga para /home e adicionando
/dev/mapper/home /home ext3 defaults 1 2
- restaure o conteúdo de segurança SELinux:
/sbin/restorecon -v -R /home
- reinicialize:
shutdown -r now
- A entrada em /etc/crypttab faz com que seu computador solicite sua senha
luks
na inicialização - Autentique-se como root e recupere seu backup
3.8.4. O que você acaba de concluir.
3.8.5. Links de interesse
3.9. Usando o GNU Privacy Guard (GnuPG)
3.9.1. Criando chaves GPG no GNOME
Sistema > Administração > Adicionar/Remover Software
e aguarde pelo PackageKit iniciar. Digite Seahorse
na caixa de texto e selecione Buscar. Marque a caixa próxima ao pacote "seahorse" e selecione "Aplicar" para adicionar o software. Você pode também instalar o Seahorse
na linha de comando com o comando su -c "yum install seahorse"
.
Seahorse
. Do menu "Arquivo" selecione "Novo" então "Chave PGP". Então clique em "Continuar". Digite o nome inteiro, endereço de email e um comentário opcional descrevendo quem você é (exemplo: (e.g.: John C. Smith, jsmith@example.com, O cara). Clique "Criar". Uma janela é mostrada pedindo a frase secreta para a chave. Escolha uma frase secreta forte mas também fácil de lembrar. Clque "Ok" e a chave será criada.
Atenção
3.9.2. Criando Chaves GPG no KDE
KGpg
.
Atenção
3.9.3. Criando chaves GPG Usando a Linha de Comando
gpg --gen-key
Enter
para atribuir um valor padrão se quiser. A primeira questão pede para você selecionar o tipo de chave que você prefere:
1y
, por exemplo, faz a chave válida por 1 ano. (Você pode alterar essa data de expiração depois que a chave é gerada, se você mudar de idéia).
gpg
perguntar por informações de assinatura, a seguinte pergunta aparece: Está correto (s/n)?
Digite s
para terminar o processo.
gpg
pede para você digitar sua frase secreta duas vezes para assegurar que não houve erros de digitação.
gpg
gera dados aleatórios para fazer sua chave a mais única possível. Mova seu mouse, digite chaves aleatórias ou realize outras tarefas no sistema durante este passo para acelerar o processo. Uma vez que este passo estiver terminado, suas chaves estão completas e prontas para uso:
pub 1024D/1B2AFA1C 2005-03-31 John Q. Doe <jqdoe@example.com> Key fingerprint = 117C FE83 22EA B843 3E86 6486 4320 545E 1B2A FA1C sub 1024g/CEA4B22E 2005-03-31 [expires: 2006-03-31]
gpg --fingerprint jqdoe@example.com
Atenção
3.9.4. Sobre Criptografia de Chave Pública
Capítulo 4. Princípios Gerais da Segurança de Informação
- criptografar todos os dados transmitidos via rede para ajudar a prevenir os ataques man-in-the-middle e eavesdropping. É importante criptografar as informações de autenticação, como senhas.
- minimizar a quantidade de software instalado e serviços de execução.
- use software de melhoria de segurança e ferramentas, por exemplo, Security-Enhanced Linux (SELinux) for Mandatory Access Control (MAC), Netfilter iptables para filtragem de pacotes (firewall), e GNU Privacy Guard (GnuPG) para arquivos criptografados.
- se possível, execute cada serviço de rede em um sistema separado para minimizar o risco de um serviço comprometido sendo usado para comprometer outros serviços.
- manter contas de usuário: criar e reforçar uma política de senha forte; remover contas de usuários sem uso.
- reveja o sistema diariamente e logs de aplicativos. Por padrão, os logs de sistema relevante a segurança são gravados em
/var/log/secure
e/var/log/audit/audit.log
. Nota: o envio de logs ao servidor de log dedicado ajuda a prevenir atacantes de modificar com facilidade logs locais para evitar a detecção. - nunca autentique-se como usuário root, a menos que absolutamente necessário. Recomenda-se que os administradores usem o
sudo
para executar comandos como root quando requerido. Os usuários capazes de executar osudo
são especificados em/etc/sudoers
. Use o utilitáriovisudo
para editar o/etc/sudoers
.
4.1. Dicas, Guias e Ferramentas
Nota
Capítulo 5. Instalação Segura
5.1. Partições de Disco
5.2. Use a Criptografia da Partição LUKS
Capítulo 6. Manutenção do Software
6.1. Instale o Mínimo de Software
6.2. Planeje e Configure Atualizações de Segurança
6.3. Ajustando Atualizações Automáticas
System -> Preferences -> Software Updates
. No KDE está localizado em Applications -> Settings -> Software Updates
.
6.4. Instale Pacotes Assinados de Repositórios Bem Conhecidos
Capítulo 7. Padrões Federais e Regulamentação
7.1. Introdução
7.2. Federal Information Processing Standard (FIPS)
- Nível 1 - O Nível de Segurança 1 fornece o nível mais baixo de segurança. Os requerimentos de segurança básicos são especificados por um módulo criptográfico (ex.: deve ser usado ao menos um algorítimo aprovado ou função de segurança Aprovada). Não é requerido nenhum mecanismo de segurança física específica em um módulo criptográfico de Segurança Nível 1, além dos requerimentos básicos para os componentes de grau de produção. Um exemplo de um Nível 1 de Segurança de módulo criptográfico é a placa de criptografia de um computador pessoal (PC).
- Nível 2 - O Nível de Segurança 2 aumenta os mecanismos de segurança física de um módulo criptográfico de Nível de Segurança 1, adicionando os requerimentos para cobertura ou selo tamper-evident ou para bloqueios pick-resistant em coberturas removíveis ou portas do módulo. A cobertura ou selo tamper-evident são colocadas em um módulo criptográfico para que a cobertura ou selo dese quebrada para obter acesso físico às chaves criptográficas de texto simples e parâmetros de segurança críticos (CSPs) dentro do módulo. Os selos tamper-evident ou bloqueios pick-resistant são colocados em coberturas ou portas para proteger contra acesso físico não autorizado.
- Nível 3 - Além dos mecanismos de segurança físicos tamper-evident requeridos no Nível de Segurança 2, o Nível de Segurança 3 tenta prevenir o intruso de obter acesso so CSPs mantido dentro do módulo criptográfico. Os mecanismos de segurança física requeridos no Nível de Segurança 3 podem ter alta possiblidade de detectar e responder à tentativas contra acesso físico, uso ou modificação de módulo criptográfico. Os mecanismos de segurança física podem incluir o uso de conteúdo forte e detecção de intromissão/ circuito de reposta que zera todos os CSPs de texto simples quando a cobertura/portas removíveis de módulo criptográfico estiverem abertos.
- Nível 4 - Nível de Segurança 4 fornece alto nível de segurança, definido neste padrão. Neste nível de segurança, os mecanismos de segurança física fornece um envelope completo de proteção ao redor de módulo criptográfico com a intenção de detectar e responder à todas as tentativas de acesso físico não autorizados. A penetração do conteúdo de módulo criptografico de qualquer direção possui uma alta probabilidade de ser detectado, resultando em zeroização de todos os CSPs de texto simples. Os módulos criptográficos de Nível de Segurança 4 são úteis para a operação em ambientes fisicamente desprotegidos.
7.3. National Industrial Security Program Operating Manual (NISPOM)
7.4. Payment Card Industry Data Security Standard (PCI DSS)
7.5. Guia de Implementação Técnico de Segurança
Capítulo 8. Referências
Livros
- SELinux by Example
- Mayer, MacMillan, and CaplanPrentice Hall, 2007
Tutorial e Ajuda
- Entendendo e Padronizando o Apache HTTP SELinux Policy
- Tutorial e conversas com Russel Coker
- Generic Writing SELinux policy HOWTO
- Base de Conhecimento Red Hat
Informações Gerais
- Website Principal do NSA SELinux
- NSA SELinux FAQ
- Fedora SELinux FAQ
- SELinux NSA's Open Source Security Enhanced Linux
Tecnologia
- Uma Visão Geral de Classes de Objetos e Permissões
- Integrando Suporte Flexível para Políticas de Segurança no Sistema Operacional Linux (um histórico de Implementação do Flask no linux)
- Implementando o SELinux como um Linux Security Module
- Uma configuração de política para o Linux Security-Enhanced
Comunidade
- Guia de Usuário do Fedora SELinux
- Fedora SELinux Managing Confined Services Guide
- Página da Comunidade do SELinux
- IRC
- irc.freenode.net, #selinux, #fedora-selinux, #security
HIstórico
- Histórico breve do Flask
- Histórico completo do Fluke
Apêndice A. Padrões de Criptografia
A.1. Criptografia Sincronizada
A.1.1. Advanced Encryption Standard - AES
A.1.1.1. Uso do AES
A.1.1.2. Histórico do AES
A.1.2. Data Encryption Standard - DES
A.1.2.1. Uso do DES
A.1.2.2. Histórico do DES
A.2. Criptografia de chave Pública
A.2.1. Diffie-Hellman
A.2.1.1. Histórico do Diffie-Hellman
A.2.2. RSA
A.2.3. DSA
A.2.4. SSL/TLS
A.2.5. Cramer-Shoup Cryptosystem
A.2.6. ElGamal Encryption
Apêndice B. Histórico de Revisão
Histórico de Revisões | |||
---|---|---|---|
Revisão 1.5-3.35.402 | Fri Oct 25 2013 | Rüdiger Landmann | |
| |||
Revisão 1.5-3.35 | August 7 2012 | Ruediger Landmann | |
| |||
Revisão 1.5-3 | 2012-07-18 | Anthony Towns | |
| |||
Revisão 1.5-1 | Apr 19 2010 | Scott Radvan | |
| |||
Revisão 1.4-1 | Mar 5 2010 | Scott Radvan | |
| |||
Revisão 1.3-1 | Feb 19 2010 | Scott Radvan | |
|