Você está na página 1de 144

Red Hat Enterprise Linux 4

Guia de Segurança
Red Hat Enterprise Linux 4: Guia de Segurança
Copyright © 2005 por Red Hat, Inc.

Red Hat, Inc.

1801 Varsity Drive Raleigh NC 27606-2072 USA Telefone: +1 919 754 3700 Telefone: 888 733 4281 Fax: +1 919 754 3701 PO Box 13588 Re-
search Triangle Park NC 27709 USA

rhel-sg(PT)-4-Impressão-RHI (2004-09-30T17:12)
Copyright © 2005 Red Hat, Inc. Este material pode ser distribuído somente sob os termos e condições definidos na ’Open
Publication License’, versão 1.0 ou mais recente (a versão mais recente está disponível em
http://www.opencontent.org/openpub/).
É proibida a distribuição de versões substancialmente modificadas deste documento sem a permissão explícita do titular dos
direitos autorais.
É proibida a distribuição total ou parcial do trabalho envolvido neste manual, em qualquer formato de livro (papel), para fins
comerciais, sem a autorização prévia do titular dos direitos autorais.
Red Hat e o logo "Shadow Man" da Red Hat são marcas registradas da Red Hat, Inc. nos EUA e em outros países.
Todas as outras marcas referidas neste são de propriedade de seus respectivos titulares.
O número do código de segurança GPG em security@redhat.com é:
CA 20 86 86 2B D6 9D FC 65 F6 EC C4 21 91 80 CD DB 42 A6 0E
Índice
Introdução ............................................................................................................................................ i
1. Informações específicas da arquitetura ................................................................................. ii
2. Convenções de Documentos ................................................................................................. ii
3. Ative Sua Assinatura............................................................................................................. v
3.1. Prover um Login para a Red Hat ........................................................................... v
3.2. Prover Seu Número de Assinatura ......................................................................... v
3.3. Conectar Seu Sistema ............................................................................................ v
4. Mais por vir.......................................................................................................................... vi
4.1. Envie-nos Seu Feedback ....................................................................................... vi
I. Uma Introdução Genérica à Segurança ......................................................................................... i
1. Visão Geral de Segurança ..................................................................................................... 1
1.1. O que é Segurança em Computadores? ................................................................. 1
1.2. Controles de Segurança.......................................................................................... 5
1.3. Conclusão............................................................................................................... 6
2. Atacantes e Vulnerabilidades ................................................................................................ 9
2.1. Uma Breve História sobre Hackers........................................................................ 9
2.2. Ameaças à Segurança da Rede ............................................................................ 10
2.3. Ameaças à Segurança do Servidor....................................................................... 10
2.4. Ameaças à Segurança da Estação de Trabalho e PC Pessoal............................... 12
II. Configurando o Red Hat Enterprise Linux para Segurança................................................... 15
3. Atualizações de Segurança ................................................................................................. 17
3.1. Atualizando Pacotes............................................................................................. 17
4. Segurança da Estação de Trabalho...................................................................................... 23
4.1. Avaliando a Segurança da Estação de Trabalho................................................... 23
4.2. Segurança do BIOS e do Gestor de Início ........................................................... 23
4.3. Segurança da Senha ............................................................................................. 25
4.4. Controles Administrativos ................................................................................... 30
4.5. Serviços de Rede Disponíveis.............................................................................. 36
4.6. Firewalls Pessoais ................................................................................................ 39
4.7. Ferramentas de Comunicação de Segurança Aprimorada ................................... 39
5. Segurança do Servidor ........................................................................................................ 41
5.1. Protegendo Serviços com TCP Wrappers e xinetd ........................................... 41
5.2. Protegendo o Portmap.......................................................................................... 44
5.3. Protegendo o NIS ................................................................................................. 45
5.4. Protegendo o NFS ................................................................................................ 47
5.5. Protegendo o Servidor HTTP Apache ................................................................. 48
5.6. Protegendo o FTP ................................................................................................ 49
5.7. Protegendo o Sendmail ........................................................................................ 51
5.8. Verificando Quais Portas estão Escutando........................................................... 52
6. Redes Privadas Virtuais (Virtual Private Networks) ........................................................... 55
6.1. VPNs e Red Hat Enterprise Linux ....................................................................... 55
6.2. IPsec..................................................................................................................... 55
6.3. Instalação do IPsec............................................................................................... 56
6.4. Configuração Máquina-a-Máquina do IPsec ....................................................... 56
6.5. Configuração Rede-a-Rede do IPsec ................................................................... 60
7. Firewalls.............................................................................................................................. 65
7.1. Netfilter e iptables ........................................................................................... 66
7.2. Usando o iptables ............................................................................................ 67
7.3. Filtragem Comum do iptables ......................................................................... 68
7.4. Regras FORWARD e NAT ....................................................................................... 69
7.5. Vírus e Endereços IP Espionados (spoofed)........................................................ 71
7.6. iptables e Registro de Conexão ....................................................................... 72
7.7. ip6tables .......................................................................................................... 72
7.8. Recursos Adicionais............................................................................................. 73
III. Avaliando Sua Segurança .......................................................................................................... 75
8. Avaliação de Vulnerabilidade ............................................................................................. 77
8.1. Pensando Como o Inimigo................................................................................... 77
8.2. Definindo Avaliação e Testes ............................................................................... 78
8.3. Avaliando as Ferramentas .................................................................................... 79
IV. Intrusões e Resposta a Incidentes ............................................................................................. 83
9. Detecção de Invasão............................................................................................................ 85
9.1. Definindo Sistemas de Detecção de Intrusão....................................................... 85
9.2. IDS baseado no servidor ...................................................................................... 86
9.3. IDS baseado em rede ........................................................................................... 88
10. Resposta ao Incidente ....................................................................................................... 91
10.1. Definindo Resposta ao Incidente ....................................................................... 91
10.2. Criando um Plano de Resposta ao Incidente...................................................... 91
10.3. Implementando o Plano de Resposta ao Incidente ............................................ 93
10.4. Investigando o Incidente .................................................................................... 93
10.5. Restaurando e Recuperando Recursos ............................................................... 96
10.6. Reportando o Incidente ...................................................................................... 97
V. Apêndices ...................................................................................................................................... 99
A. Proteção ao Hardware e à Rede ....................................................................................... 101
A.1. Topologias de Rede Segura............................................................................... 101
A.2. Segurança de Hardware..................................................................................... 104
B. Exploits e Ataques Comuns ............................................................................................. 107
C. Portas Comuns ................................................................................................................. 111
Índice Remissivo.............................................................................................................................. 125
Considerações finais........................................................................................................................ 131
Introdução
Bem-vindo ao Guia de Segurança do Red Hat Enterprise Linux!
O Guia de Segurança do Red Hat Enterprise Linux é desenvolvido para auxiliar usuários do Red
Hat Enterprise Linux a aprender os processos e práticas para proteger estações de trabalho e servi-
dores de intrusões locais e remotas, exploits e atividades maldosas. O Guia de Segurança do Red
Hat Enterprise Linux detalha o planejamento e as ferramentas envolvidas na criação de um ambiente
computacional seguro para o centro de dados (data center), ambiente de trabalho e doméstico. Com o
conhecimento, vigilância e ferramentas apropriados, os sistemas rodando o Red Hat Enterprise Linux
podem ser totalmente funcionais e protegidos contra os métodos de intrusão e exploit mais comuns.
Este manual aborda detalhadamente diversos tópicos relacionados a segurança, incluindo:

• Firewalls
• Criptografia
• Protegendo Serviços Críticos
• Redes Privadas Virtuais (Virtual Private Networks)
• Detecção de Intrusão
O manual é dividido nas partes seguintes:

• Introdução Genérica à Segurança


• Configurando o Red Hat Enterprise Linux para Segurança
• Avaliando Sua Segurança
• Intrusões e Resposta a Incidentes
• Apêndice
Nós gostaríamos de agradecer Thomas Rude por suas generosas contribuições a este manual. Ele es-
creveu os capítulos Avaliações de Vulnerabilidade e Resposta ao Incidente. Muito obrigado, Thomas!
Este manual assume que você tem um conhecimento avançado do Red Hat Enterprise Linux. Se você
for um novo usuário ou tiver conhecimento básico a intermediário do Red Hat Enterprise Linux e
deseja mais informações sobre como utilizar o sistema, por favor consulte os seguintes manuais, que
abordam os aspectos fundamentais do Red Hat Enterprise Linux de forma mais detalhada que o Guia
de Segurança do Red Hat Enterprise Linux:

• O Guia de Instalação do Red Hat Enterprise Linux traz informações sobre a instalação.
• O Introdução à Administração de Sistemas Red Hat Enterprise Linux contém informações intro-
dutórias para novos administradores de sistemas Red Hat Enterprise Linux.
• O Guia de Administração de Sistemas Red Hat Enterprise Linux oferece informações detalhadas
sobre como configurar o Red Hat Enterprise Linux para servir suas necessidades particulares como
usuário. Este manual inclui alguns serviços que são abordados (sob o ponto de vista de segurança)
no Guia de Segurança do Red Hat Enterprise Linux.
• O Guia de Referência do Red Hat Enterprise Linux traz informações detalhadas para a consulta dos
usuários mais experientes quando necessária, ao contrário das instruções passo-a-passo.
As versões HTML, PDF e RPM dos manuais estão disponíveis no CD de Documentação do Red Hat
Enterprise Linux e online: http://www.redhat.com/docs/.
ii Introdução

Nota
Apesar deste manual refletir as informações mais recentes possíveis, leia as Notas da Versão do Red
Hat Enterprise Linux para acessar as informações que não estavam disponíveis antes da finalização
de nossa documentação. Elas podem ser encontradas no CD 1 do Red Hat Enterprise Linux e online:
http://www.redhat.com/docs/.

1. Informações específicas da arquitetura


Exceto quando informado, todas as informações contidas neste manual se aplicam somente ao proces-
sador x86 e aos processadores com as tecnologias Intel® Extended Memory 64 Technology (EM64T
da Intel®) e AMD64. Para obter informações de arquiteturas específicas, consulte o Guia de Insta-
lação do Red Hat Enterprise Linux.

2. Convenções de Documentos
Ao ler este manual, determinadas palavras estão representadas com fontes, tipos, tamanhos e pesos
diferentes. Este destaque é sistemático; palavras diferentes são representadas no mesmo estilo para
indicar sua inclusão em uma categoria específica. Os tipos de palavras representadas desta maneira
incluem as seguintes:

comando
Os comandos do Linux (e comandos de outros sistemas operacionais, quando usados) são rep-
resentados desta maneira. Este estilo indica que você pode digitar a palavra ou frase na linha de
comandos e pressionar [Enter] para invocar um comando. Às vezes o comando contém palavras
que serão exibidas em um estilo diferente por si só (como nomes de arquivos). Nestes casos,
estas são consideradas parte do comando, e então a frase inteira será exibida como um comando.
Por exemplo:
Use o comando cat testfile para visualizar o conteúdo de um arquivo chamado testfile,
no diretório de trabalho atual.

nome do arquivo
Nomes de arquivos, diretórios, localidades de arquivos e nomes de pacotes RPM são representa-
dos desta maneira. Este estilo indica que existe um determinado arquivo ou diretório com aquele
nome no seu sistema. Exemplos:
O arquivo .bashrc do seu diretório ’home’ contém definições da janela de comandos tipo bash
e codenomes para seu uso pessoal.
O arquivo /etc/fstab contém informações sobre os dispositivos e sistemas de arquivo difer-
entes do sistema.
Instale o RPM webalizer se você quiser usar um programa de análise do arquivo de registro do
servidor Web.

aplicação
Este estilo indica que o programa é uma aplicação direcionada ao usuário final (ao contrário do
software do sistema). Por exemplo:
Use o Mozilla para navegar na Web.
Introdução iii

[tecla]
Uma tecla do teclado é exibida neste estilo. Por exemplo:
Para usar a tecla complementar [Tab] num terminal, digite um caractere e então pressione a tecla
[Tab]. Seu terminal exibe uma lista dos arquivos contidos no diretório que começam com esta
letra.

[tecla]-[combinação]
Uma combinação de sequência de teclas é representada desta maneira. Por exemplo:
A combinação de teclas [Ctrl]-[Alt]-[Espaço] termina sua sessão gráfica, retornando à tela ou ao
console da autenticação gráfica.

texto exibido em uma interface GUI (gráfica)


Um título, palavra ou frase na tela ou janela da interface GUI é exibida neste estilo. O texto
exibido neste estilo é usado na identificação de uma tela GUI específica ou um elemento de uma
tela GUI (como o texto associado a uma caixa de verificação ou campo). Exemplo:
Selecione a caixa de verificação Solicitar Senha se você deseja que seu protetor de tela solicite
uma senha antes de ser desbloqueado.

nível superior de um menu em uma tela ou janela GUI


Uma palavra neste estilo indica que a palavra está no nível superior de um menu suspenso (pull-
down menu). Se você clicar na palavra na tela GUI, o resto do menu deverá aparecer. Por exem-
plo:
Abaixo de Arquivo em um terminal do GNOME, você verá a opção Nova Aba, que permite a
você abrir diversos prompts de comando na mesma janela.
Se você precisar digitar uma sequência de comandos a partir de um menu GUI, eles são exibidos
como o exemplo a seguir:
Vá para Botão do Menu Principal (no Painel) => Programação => Emacs para iniciar o editor
de texto Emacs.

botão em uma tela ou janela GUI


Este estilo indica que o texto pode ser encontrado em um botão clicável de uma tela GUI. Por
exemplo:
Clique no botão Voltar para retornar à última página web que você visitou.

output do computador
Texto neste estilo indica o texto exibido em uma janela de comandos, como mensagens de erro e
respostas a comandos. Por exemplo:
O comando ls exibe o conteúdo de um diretório:
Desktop about.html logs paulwesterberg.png
Mail backupfiles mail reports
O output exibido em resposta ao comando (neste caso, o conteúdo do diretório) é apresentado
neste estilo.

prompt
Um prompt (ou janela de comandos), uma forma computacional de dizer que o computador está
pronto para você inserir algo (input), será exibido desta maneira. Exemplos:
$
#
iv Introdução

[stephen@maturin stephen]$
leopard login:

input do usuário
O texto que o usuário precisa digitar, na linha de comandos ou em uma caixa de texto em uma
tela GUI, é apresentado neste estilo. No exemplo a seguir, text é exibido neste estilo:
Para inicializar seu sistema no programa de instalação em modo texto, você deve digitar o co-
mando text no prompt boot:.

substituível


Texto usado para exemplos que devem ser subtituídos com dados providos pelo usuário são
apresentados neste estilo. No exemplo a seguir, version-number é exibido neste estilo:
O
 
diretório da fonte do kernel é /usr/src/ version-number /,
version-number é a versão do kernel instalado neste sistema.
 onde

Adicionalmente, nós utilizamos diversas estratégias diferentes para chamar sua atenção a determi-
nadas partes da informação. De acordo com o quão crucial as informações são para seu sistema, elas
são apresentadas como uma nota (lembrete), dica, importante, atenção ou um aviso. Por exemplo:

Nota
Lembre-se que o Linux é sensível a maiúsculas e minúsculas. Em outras palavras, uma rosa não é
uma ROSA nem uma rOsA.

Dica
O diretório /usr/share/doc/ contém documentação adicional para os pacotes instalados em seu
sistema.

Importante
Se você modificar o arquivo de configuração do DHCP, as alterações não terão efeito até que você
reinicie o daemon do DHCP.

Atenção
Não execute tarefas de rotina como root — use uma conta de usuário comum, a não ser que você
precise usar a conta root para tarefas de administração do sistema.
Introdução v

Aviso
Cuidado para remover somente as partições necessárias do Red Hat Enterprise Linux. Remover
outras partições pode resultar na perda de dados ou num ambiente de sistema corrompido.

3. Ative Sua Assinatura


Antes de poder acessar as informações de manutenção do software e serviços, e a documentação de
suporte inclusa em sua assinatura, você deve ativar sua assinautra registrando-a na Red Hat. O registro
inclui estes passos simples:

• Prover um login para a Red Hat


• Prover um número para a assinatura
• Conectar seu sistema
Na primeira vez que iniciar a instalação de seu Red Hat Enterprise Linux, você verá o pedido de
registro na Red Hat usando o Agente de Configuração. Se você seguir os pedidos durante o Agente
de Configuração, poderá completar os passos do registro e ativar sua assinatura.
Se você não puder completar o registro durante o Agente de Configuração (que requer
acesso à rede), pode, alternativamente, completar o processo de registro da Red Hat online:
http://www.redhat.com/register/.

3.1. Prover um Login para a Red Hat


Se você ainda não possui um login para a Red Hat, pode criá-lo quando for solicitado no Agente de
Configuração ou online em:

https://www.redhat.com/apps/activate/newlogin.html

Um login da Red Hat habilita seu acesso a:

• Atualizações, erratas e manutenção do software através da Red Hat Network


• Recursos do suporte técnico, documentação e base de dados de conhecimento (knowledgebase) da
Red Hat
Se você esqueceu seu login da Red Hat, pode fazer uma busca online em:

https://rhn.redhat.com/help/forgot_password.pxt

3.2. Prover Seu Número de Assinatura


Seu número de assinatura está localizado no pacote que acompanha seu pedido. Caso seu pacote não
inclua um número de assinatura, sua assinautra já foi ativada e, portanto, você pode pular este passo.
Você pode prover seu número de assinatura ao ser solicitado durante o Agente de Configuração ou
visitando http://www.redhat.com/register/.
vi Introdução

3.3. Conectar Seu Sistema


O Cliente de Registro da Red Hat Network auxilia na conexão de seu sistema para que você possa
obter as atualizações e efetuar a administração de sistemas. Há três maneiras para conectar:

1. Durante o Agente de Configuração — Selecione as opções Enviar informações de hardware


e Enviar lista de pacotes do sistema quando aparecerem.
2. Após completar o Agente de Configuração — No Menu Principal, clique em Ferramentas
do Sistema, e então selecione Red Hat Network.
3. Após completar o Agente de Configuração — Invoque o seguinte na janela de comandos como
usuário root:
• /usr/bin/up2date --register

4. Mais por vir


O Guia de Segurança do Red Hat Enterprise Linux é parte do crescente comprometimento da Red
Hat em prover suporte e informações úteis e oportunas para usuários do Red Hat Enterprise Linux.
Conforme novas ferramentas e metodologias de segurança são criadas, este guia será expandido para
incluí-las.

4.1. Envie-nos Seu Feedback


Se você encontrar um erro de digitação no Guia de Segurança do Red Hat Enterprise Linux ou se
pensar numa maneira de aprimorar este manual, nós gostaríamos de saber! Por favor, submeta um re-
latório ao Bugzilla (http://bugzilla.redhat.com/bugzilla/) sobre o componente rhel-sg.
Certifique-se de mencionar o identificador do manual:

rhel-sg(PT)-4-Impressão-RHI (2004-09-30T17:12)

Ao mencionar o identificador, nós saberemos exatamente qual versão do manual você possui.
Se você tiver alguma sugestão para melhorar a documentação, tente ser o mais específico possível.
Se encontrou um erro, por favor inclua o número da seção e trechos de texto próximo ao erro para
podermos encontrá-lo facilmente.
I. Uma Introdução Genérica à Segurança

Esta parte traz a definição de segurança da informação, sua história e o setor que foi desenvolvido em
torno desta questão. Também aborda alguns dos riscos enfrentados por usuários e administradores de
computadores.

Índice
1. Visão Geral de Segurança .............................................................................................................. 1
2. Atacantes e Vulnerabilidades......................................................................................................... 9
Capítulo 1.
Visão Geral de Segurança
Devido ao crescente suporte de computadores de rede poderosos para fazer negócios e manter controle
de nossas informações pessoais, as indústrias têm sido constituídas com a prática de segurança nos
computadores e nas redes. Empreendimentos têm solicitado o conhecimento e habilidades de peritos
em segurança para auditar sistemas apropriadamente e customizar soluções para os requerimentos
operacionais das organizações. Já que a maioria das organizações são dinâmicas por natureza, com
funcionários acessando os recursos de IT da empresa localmente e remotamente, a necessidade de
ambientes de rede seguros se tornou ainda mais acentuada.
Infelizmente, a maioria das empresas (assim como usuários individuais) encaram a segurança como
uma preocupação em segundo plano, um processo visto em favor de questões de aumento de poder,
produtividade e orçamentárias. Implementações de segurança apropriadas são frequentemente execu-
tadas postmortem — após uma intrusão não autorizada já ter ocorrido. Peritos em segurança concor-
dam que as medidas corretas, tomadas antes de conectar um site a uma rede não confiável - como a
Internet - é um meio efetivo de impedir a maioria das tentativas de intrusão.

1.1. O que é Segurança em Computadores?


Segurança em computadores é um termo geral que abrange uma grande área da computação e proces-
samento de dados. Setores que dependem de sistemas de computador e redes para conduzir transações
diárias de negócios e acessar informações cruciais, encaram seus dados como uma parte importante de
seus recursos. Diversos termos e medidas foram inseridos em nosso cotidiano, tais como custo total de
propriedade (total cost of ownership - TCO) e qualidade de serviço (quality of service - QoS). Nestas
medidas, setores calculam aspectos como integridade de dados e alta disponibilidade como parte de
seus custos de planejamento e gerenciamento de processos. Em alguns setores, tal como comércio
eletrônico, a disponibilidade e confiabilidade de dados pode ser a diferença entre sucesso e fracasso.

1.1.1. Como surgiu a Segurança em Computadores?


Muitos leitores talvez lembrem do filme "Jogos de Guerra," com Matthew Broderick no papel de um
estudante colegial que invade o supercomputador do Departamento de Defesa dos EUA (Department
of Defense - DoD), e inadvertidamente causa uma ameaça nuclear. Neste filme, Broderick usa seu
modem para discar ao computador do DoD (chamado WOPR) e brinca de jogos com o software artifi-
cialmente inteligente controlando todos os armazéns de mísseis nucleares. O filme foi lançado durante
a "guerra fria" entre a ex União Soviética e os EUA e foi considerado um sucesso em seu lançamento
em 1983. A popularidade do filme inspirou muitas pessoas e grupos a começar a implementar alguns
dos métodos que o jovem protagonista utilizou para violar sistemas restritos, inclusive o que é con-
hecido como war dialing — um método de busca de números de telefone para conexões de modem
analógicos em uma combinação de determinado prefixo de área e prefixo de telefone.
Mais de 10 anos depois, após uma busca multi-jurisdição de quatro anos envolvendo o FBI (Federal
Bureau of Investigation) e a ajuda de profissionais de computação em todo o país, o notório cracker
Kevin Mitnick foi preso e processado por 25 fraudes de contas de computador e acesso a dispositivos,
que resultaram em perdas de propriedade intelectual e código-fonte da Nokia, NEC, Sun Microsys-
tems, Novell, Fujitsu e Motorola estimadas em US$80 milhões. Na época, o FBI considerou-o como
o maior crime relacionado a computadores na história dos EUA. Ele foi condenado e sentenciado a
68 meses de prisão por seus crimes, dos quais serviu 60 meses antes de sua condicional em 21 de
Janeiro de 2000. Ele foi proibido de usar computadores ou prestar qualquer consultoria relacionada a
computadores até 2003. Investigadores dizem que Mitnick era perito em engenharia social — utilizar
indivíduos para ganhar acesso a senhas e sistemas usando credenciais falsificadas.
2 Capítulo 1. Visão Geral de Segurança

A segurança da informação evoluiu através dos anos devido à crescente dependência de redes públicas
para expor informações pessoais, financeiras e outras informações restritas. Há diversos casos como
o de Mitnick e o de Vladamir Levin (consulte a Seção 1.1.2 para mais informações) que surgiram em
empresas de todos os setores para repensar a maneira com que lidam com a transmissão e exposição de
informações. A popularidade da Internet foi um dos aspectos mais importantes que exigiu um esforço
intenso na segurança de dados.
Um número cada vez maior de pessoas está utilizando seu computador pessoal para acessar os recursos
que a Internet oferece. De pesquisas e recuperação de informações a correspondência eletrônica e
transações comerciais, a Internet é considerada um dos desenvolvimentos mais importantes do século
XX.
A Internet e seus protocolos mais antigos, no entanto, foram desenvolvidos como um sistema baseado
na confiança. Ou seja, o Protocolo de Internet (IP) não foi desenvolvido para ser intrinsicamente se-
guro. Não há padrões de segurança aprovados dentro do esquema de comunicação TCP/IP, deixando-o
aberto a usuários maldosos e processos através da rede. O desenvolvimento de modems tornou a co-
municação via Internet mais segura, mas ainda há diversos incidentes que ganham atenção nacional e
nos alertam para o fato de que nada é completamente seguro.

1.1.2. Cronologia da Segurança em Computadores


Diversos eventos-chave contribuíram para o nascimento e crescimento da segurança em computa-
dores. A cronologia a seguir lista alguns dos eventos mais importantes da computação e segurança da
informação, e suas importâncias hoje.

1.1.2.1. Os Anos 30 e 40

• Criptógrafos poloneses inventam a máquina Enigma em 1918, um dispositivo rotor eletromecânico


de cifras que converte mensagens puramente texto em um resultado criptografado. Desenvolvido
originalmente para proteger comunicações bancárias, o exército alemão vê no dispositivo o poten-
cial de proteger as comunicações durante a 2a Guerra Mundial. Um matemático brilhante chamado
Alan Turing desenvolve um método para quebrar os códigos da Enigma, possibilitando às forças
aliadas desenvolver a Colossus, uma máquina que recebeu créditos por findar a guerra um ano antes.

1.1.2.2. Os Anos 60

• Estudantes do Massachusetts Institute of Technology (MIT) formaram o Tech Model Railroad Club
(TMRC), que começou a explorar e programar o sistema de computadores de grande porte PDP-1
da escola. O grupo evetualmente usa o termo "hacker" no contexto em que é conhecido hoje.
• O DoD (Departamento de Defesa dos EUA) cria a Rede da Agência de Projetos de Pesquisa
Avançada (Advanced Research Projects Agency Network - ARPANet), que ganha popularidade
em pesquisas e círculos acadêmicos como um condutor do intercâmbio eletrônico de informações
e dados. Isto pavimentou o caminho para a criação da rede de transporte conhecida hoje como
Internet.
• Ken Thompson desenvolve o sistema operacional UNIX, amplamente aclamado como o sistema
operacional mais "hacker-friendly" devido às suas ferramentas acessíveis a desenvolvedores e com-
piladores e também à sua comunidade de usuários colaborativos. Quase ao amesmo tempo, Dennis
Ritchie desenvolve a linguagem de programação C, discutivelmente a linguagem hacking mais pop-
ular da história dos computadores.
Capítulo 1. Visão Geral de Segurança 3

1.1.2.3. Os Anos 70

• Bolt, Beranek e Newman, uma empresa de pesquisa e desenvolvimento em computadores para o


governo e indústria, desenvolve o protocolo Telnet, uma extensão pública da ARPANet. Isto abre
portas para o uso público de redes de dados antes restritas a empresas do governo e pesquisadores
acadêmicos. O Telnet, no entanto, também é discutivelmente o protocolo mais inseguro para redes
públicas, de acordo com diversos pesquisadores em segurança.
• Steve Jobs e Steve Wozniak fundaram a Apple Computer e começaram a comercializar o com-
putador pessoal (Personal Computer - PC). O PC é o trampolim para diversos usuários maldosos
aprenderem a arte do cracking remoto em sistemas, usando hardware de comunicação comum de
PC, como modems analógicos e war dialers.
• Jim Ellis e Tom Truscott criam o USENET, um sistema de estilo mural (bulletin-board) para comu-
nicação eletrônica entre usuários díspares. O USENET torna-se rapidamente um dos meios mais
conhecidos de intercâmbio de idéias em computação, redes e, obviamente, cracking.

1.1.2.4. Os Anos 80

• A IBM desenvolve e comercializa PCs baseados no microprocessador Intel 8086, uma arquitetura
relativamente barata que trouxe a computação do escritório para casa. Isto serve para transformar o
PC numa ferramenta comum e acessível, que era relativamente poderosa e fácil de usar, ajudando a
proliferação deste tipo de hardware nos lares e escritórios de usuários maldosos.
• O Protocolo de Controle de Transmissão (Transmission Control Protocol), desenvolvido por Vint
Cerf, é dividido em duas partes distintas. O Protocolo de Internet (IP) surge desta divisão, e o
protocolo combinado TCP/IP torna-se o padrão para toda a comunicação via Internet de hoje.
• Baseada em desenvolvimentos na área de phreaking, ou explorando e hackeando o sitema de tele-
fonia, a revista 2600: The Hacker Quarterly é criada e começa a abordar temas como o cracking e
redes de computadores para uma grande audiência.
• A gang 414 (assim nomeada em função do código de área de onde haqueava) é surpreendida pelas
autoridades após nove dias de cracking no qual a gang violou os sistemas de uma localização
altamente secreta, o Los Alamos National Laboratory, um local de pesquisas de armas nucleares.
• ’The Legion of Doom’ e o ’Chaos Computer Club’ são dois grupos pioneiros de crackers que
começam a explorar as vulnearbilidades em computadores e redes eletrônicas de dados.
• O Ato de Fraude e Abuso de Computador de 1986 (Computer Fraud and Abuse Act) foi votado
e transformado em lei pelo congresso americano baseado nos exploits de Ian Murphy, também
conhecido com Capitão Zap, que violou computadores militares, roubou informações de bancos
de dados de pedidos de mercadorias e utilizou os quadros restritos de distribuição de telefone do
governo para efetuar ligações telefônicas.
• Baseado no Ato de Fraude e Abuso de Computador, a côrte condena Robert Morris, um graduando,
por distribuir o vírus Morris Worm para mais de 6.000 computadores vulneráveis conectados à In-
ternet. O próximo caso mais proeminente julgado sob este ato foi o de Herbert Zinn, um colegial
que abandonou os estudos, que crackeou e fez mal-uso dos sistemas da AT&T e do DoD (Departa-
mento de Defesa dos EUA).
• Baseado na preocupação de que a órdea do Morris Worm pudesse ser replicada, é criada a Equipe
de Resposta a Emergências de Computador (Computer Emergency Response Team - CERT) para
alertar usuários das questões de segurança em redes.
• Clifford Stoll escreve The Cuckoo’s Egg, o resultado de sua investigação sobre crackers que explo-
raram seu sistema.
4 Capítulo 1. Visão Geral de Segurança

1.1.2.5. Os Anos 90

• A ARPANet é desativada. O tráfego desta rede é transferido para a Internet.


• Linus Torvalds desenvolve o kernel do Linux para utilização com o sistema operacional GNU. O
amplo desenvolvimento e adoção do Linux se deve, em grande parte, à colaboração e comunicação
de usuários e desenvolvedores via Internet. Devido às suas raízes no Unix, o Linux é mais popular
entre hackers e administradores que o consideram muito útil para elaborar alternativas seguras para
servidores legados que rodam sistemas operacionais proprietários (com código fechado).
• O navegador (browser) gráfico é criado e estimula uma demanda exponencialmente alta por acesso
público à Internet.
• Vladimir Levin é cúmplice da transfência ilegal de US$10 milhões em fundos para diversas contas
crackeando o banco de dados central do CitiBank. Levin é preso pela Interpol e quase todo o
dinheiro é recuperado.
• Possivelmente, o precursor de todos os crackers é Kevin Mitnick, que hackeou diversos sistemas
corporativos roubando tudo - de informações pessoais de celebridades a mais de 20.000 números
de cartões de crédito e código fonte de software proprietário. Ele é preso, condenado por fraude e
fica 5 anos na prisão.
• Kevin Poulsen e um cúmplice desconhecido manipulam sistemas de telefonia de uma estação de
rádio para ganhar carros e prêmios em dinheiro. Ele é condenado por fraude e sentenciado a 5 anos
de prisão.
• As histórias de cracking e phreaking se tornam lendas; e muitos crackers em potencial se reúnem
na convenção anual DefCon para celebrar o cracking e trocar idéias entre seus pares.
• Um estudante israelense de 19 anos é preso e condenado por coordenar várias violações aos sis-
temas do governo americano durante o conflito no Golfo Pérsico. Oficiais militares o chamam de
"o ataque mais organizado e sistemático" a sistemas de governo na história dos EUA.
• A Procuradora dos EUA Janet Reno, em resposta às crescentes violações de segurança aos sistemas
do governo, estabelece o Centro de Proteção à Infraestrutura Nacional (National Infrastructure Pro-
tection Center).
• Satélites de comunicação ingleses são tomados e controlados por criminosos desconhecidos. O
governo britânico eventualmente se apropria do controle dos satélites.

1.1.3. A Segurança Hoje


Em Fevereiro de 2000, um ataque Denial of Service Distribuído (Distributed Denial of Service -
DDoS) foi espalhado a vários servidores de sites de maior tráfego na Internet. O ataque tomou con-
trole do yahoo.com, cnn.com, amazon.com, fbi.gov e vários outros sites completamente inacessíveis
para usuários normais, pois bloqueou roteadores por várias horas com transferências de grandes pa-
cotes ICMP, também chamados de ping flood. O ataque foi de autoria desconhecida usando programas
criados especialmente e amplamente disponíveis , que sannearam servidores de rede vulneráveis, in-
stalaram aplicações cliente chamadas trojans nos servidores e marcaram um ataque com todos os
servidores infectados inundando os sites vítimas e tornando-os indisponíveis. Muitos culparam o
ataque à obsolescência da maneira como roteadores e protocolos usados são estruturados para aceitar
todos os dados externos, não importando de onde ou para qual propósito os pacotes são enviados.
Isso nos traz ao novo milênio, um tempo em que aproximadamente 945 milhões de pessoas usam ou
usaram a Internet ao redor do mundo (Computer Industry Almanac, 2004). Ao mesmo tempo:
Capítulo 1. Visão Geral de Segurança 5

• Num dia qualquer, são estimados 225 grandes incidentes de exploração de vulnerabilidades repor-
tados ao Centro de Coordenação da CERT na Universidade Carnegie Mellon. 1
• Em 2003, o número de incidentes reportados à CERT pulou para 137.529 de 82.094 em 2002 e de
52.658 em 2001.2
• O impacto econômico am nível mundial dos três vírus mais perigosos da Internet nos últimos três
anos foi estimado em US$13.2 bilhões.3
A segurança em computadores tornou-se uma despesa quantificável e justificável em todos os orça-
mentos de TI. Empresas que requerem integridade de dados e alta disponibilidade, evocam as habil-
idades de administradores de sistemas, desenvolvedores e engenheiros para garantir confiabilidade
de seus sistemas, serviços e informações 24 horas por dia, sete dias por semana. Cair nas mãos de
usuários, processos ou ataques maldosos coordenados é uma ameaça direta ao sucesso da empresa.
Infelizmente, a segurança de sistemas e redes pode ser uma tarefa difícil, que requer o conhecimento
complexo de como a empresa encara, usa, manipula e transmite suas informações. Entender a maneira
como a empresa (e as pessoas que a constituem) conduz os negócios é primordial para a implemen-
tação de um plano de segurança apropriado.

1.1.4. Padronizando a Segurança


Empresas de todos os setores dependem de regulamentações e padrões definidos por associações como
a Associação Médica Americana (American Medical Association - AMA) ou o Instituto de Engen-
heiros Elétricos e Eletrônicos (Institute of Electrical and Electronics Engineers - IEEE). As mesmas
idéias valem para a segurança da informação. Muitas consultorias e fabricantes da área de segurança
concordam com o modelo de segurança padrão conhecido como CIA, ou Confidentiality, Integrity,
and Availability (Confidencialidade, Intergridade e Disponibilidade). Esse modelo de três pilares é
um componente geralmente aceito para avaliar riscos às informações delicadas e para estabelecer
uma política de segurança. A explicação a seguir detalha o modelo CIA:

• Confidencialidade — Informações delicadas devem estar disponíveis apenas para um conjunto pré-
definido de indivíduos. A transmissão ou o uso não autorizado de informações devem ser restritos.
Por exemplo: a confidencialidade da informação garante que as informações pessoais ou financeiras
de um cliente não sejam obtidas por um indivíduo não autorizado para propósitos maldosos como
roubo de identidade ou fraude de crédito.
• Integridade — As informações não devem ser alteradas de modo a torná-las incompletas ou in-
corretas. Usuários não autorizados devem ter restrições para modificar ou destruir informações
delicadas.
• Disponibilidade — As informações devem estar acessíveis a usuários autorizados sempre que pre-
cisarem. A disponibilidade é a garantia de que aquela informação pode ser obtida com uma fre-
quência e periodicidade pré-definidas. Isto é frequentemente medido em termos de porcentagens e
definido formalmente nos Acordos de Nível de Serviço (Service Level Agreements - SLAs) usados
por provedores de serviços de rede e seus clientes corporativos.

1.2. Controles de Segurança


A segurança em computadores é frequentemente dividida em três categorias principais, comumente
referidas como controles:

1. Fonte: http://www.cert.org
2. Fonte: http://www.cert.org/stats/
3. Fonte: http://www.newsfactor.com/perl/story/16407.html
6 Capítulo 1. Visão Geral de Segurança

• Físicos
• Técnicos
• Administrativos
Estas três categorias abrangentes definem os objetivos principais de uma implementação de segurança
apropriada. Dentre estes controles há sub-categorias que detalham minuciosamente os controles e
como implementá-los.

1.2.1. Controles Físicos


O controle físico é a implementação de medidas de segurança em uma estrutura definida usada para
deter ou evitar acesso não autorizado a material delicado. Alguns exemplos de controles físicos:

• Câmeras de vigilância de circuito fechado


• Sistemas de alarme térmicos ou de movimento
• Guardas de segurança
• Identidades com foto
• Portas de aço trancadas com fechaduras ’dead-bolt’
• Biométrica (inclui impressão digital, voz, rosto, íris, manuscrito e outros métodos automatizados
usados para reconhecer indivíduos)

1.2.2. Controles Técnicos


O controle técnico uitiliza a tecnologia como base para controlar o acesso e o uso de dados delicados
através de uma estrutura física e através de uma rede. Os controles técnicos têm um escopo de grande
alcance e incluem tecnologias como:

• Criptografia
• Cartões inteligentes
• Autenticação de rede
• Listas de controle de acesso (Access control lists - ACLs)
• Software de auditoria de integridade de arquivos

1.2.3. Controles Administrativos


Os controles administrativos definem os fatores humanos da segurança. Envolvem todos os níveis de
pessoal em uma empresa e determinam quais usuários têm acesso a quais recursos e informações,
através dos seguintes meios:

• Treinamento e conscientização
• Preparação para desastres e planos de recuperação
• Recrutamento de pessoal e estratégias de separação
• Registro e avaliação de pessoal
Capítulo 1. Visão Geral de Segurança 7

1.3. Conclusão
Agora que você aprendeu um pouco sobre as origens, razões e aspectos da segurança, pode determinar
o curso de ações apropriado em relação ao Red Hat Enterprise Linux. É importante saber quais fatores
e condições compoem a segurança para planejar e implementar uma estratégia apropriada. Com estas
informacões em mente, o processo pode ser formalizado e o caminho torna-se mais claro conforme
você aprofundar nas especificidades do processo de segurança.
8 Capítulo 1. Visão Geral de Segurança
Capítulo 2.
Atacantes e Vulnerabilidades
Para planejar e implementar uma boa estratégia de segurança, primeiramente saiba de algumas das
razões que motivaram atacantes a explorar e comprometer sistemas. Mas antes de detalhar estas
questões, precisamos definir a terminologia utilizada ao identificar um atacante.

2.1. Uma Breve História sobre Hackers


O significado moderno da palavra hacker tem origem nos anos 60 e no ’Tech Model Railroad Club’
do Instituto de Tecnologia de Massachusetts (MIT), que desenvolveu locomotivas de grande escala e
detalhes complexos. Hacker era o nome usado para os membros do clube que descobriram um novo
truque ou uma nova forma de resolver um problema.
Desde então o termo hacker descreve de tudo, de viciados em computador a programadores talentosos.
Um aspecto comum dentre a maioria dos hackers é a vontade de explorar detalhadamente as funções
dos sistemas e redes de computador com pouco ou nenhum estímulo exterior. Desenvolvedores de
software open source geralmente consideram seus colegas e a si próprios como hackers e utilizam
esta palavra como um termo respeitável.
Tipicamente, os hackers seguem uma espécie de ética do hacker, que dita que a missão por con-
hecimento e informação é essencial, e compartilhar este conhecimento é dever dos hackers para
com a comunidade. Durante esta missão por conhecimento, alguns hackers se divertem com desafios
acadêmicos em furar controles de segurança em sistemas de computadores. Por esta razão, a imprensa
comumente usa o termo hacker para descrever aqueles que acessam sistemas e redes ilicitamente com
intenções inescrupulosas, madosas ou criminosas. O termo mais correto para este tipo de hacker de
computador é cracker — um termo criado por hackers em meados dos anos 80 para diferenciar as
duas comunidades.

2.1.1. Tonalidades de Cinza


Há diversos grupos distintos de indivíduos que encontram e exploram vulnerabilidades em redes e
sistemas. Eles são descritos pela tonalidade do chapéu que "vestem" ao realizar suas investigações em
segurança, e essa tonalidade indica suas intenções.
O hacker de chapéu branco é aquele que testa redes e sistemas para examinar sua performance e
determinar o quão vulneráveis são às intrusões. Geralmente, hackers de chapéu branco violam seus
próprios sistemas ou sistemas de um cliente que o empregou especificamente para auditar a segurança.
Pesquisadores acadêmicos e consultores profissionais de segurança são dois exemplos de hackers de
chapéu branco.
Um hacker de chapéu preto é sinônimo de um cracker. Em geral, crackers são menos focados em
programação e no lado acadêmico de violar sistemas. Eles comumente confiam em programas de
cracking e exploram vulnerabilidades conhecidas em sistemas para descobrir informações importantes
para ganho pessoal ou para danificar a rede ou sistema alvo.
O hacker de chapéu cinza, por outro lado, tem as habilidades e intenções de um hacker de chapéu
branco na maioria dos casos, mas por vezes utiliza seu conhecimento para propósitos menos nobres.
Um hacker de chapéu cinza pode ser descrito como um hacker de chapéu branco que às vezes veste
um chapéu preto para cumprir sua própria agenda.
Hackers de chapéu cinza tipicamente se enquadram em outro tipo de ética, que diz ser aceitável violar
sistemas desde que o hacker não cometa roubo ou infrinja a confidencialidade. Alguns argumentam,
no entanto, que o ato de violar um sistema por si só já é anti-ético.
10 Capítulo 2. Atacantes e Vulnerabilidades

Independentemente da intenção do intruso, é importante saber das fraquezas que um cracker geral-
mente tentará explorar. O restante do capítulo foca nestas questões.

2.2. Ameaças à Segurança da Rede


Práticas ruins ao configurar os seguintes aspectos de uma rede podem aumentar os riscos de um ataque.

2.2.1. Arquiteturas Inseguras


Uma rede mal configurada é um ponto de entrada básico para usuários não autorizados. Deixar uma
rede local aberta baseada na confiança e vulnerável à Internet, altamente insegura, é o mesmo que
deixar uma porta entreaberta em uma vizinhança perigosa — talvez nada aconteça por um período,
mas eventualmente alguém explorará a oportunidade.

2.2.1.1. Redes de Transmissão


Administradores de sistemas frequentemente falham em perceber a importância do hardware de rede
em seus esquemas de segurança. Componentes de hardware simples como hubs e roteadores baseiam-
se no princípio da transmissão ou ’non-switched’, ou seja, sempre que um nódulo transmitir dados
através da rede para um nódulo receptor, o hub ou roteador envia uma transmissão dos pacotes de
dados até que o nódulo receptor receba e processe os dados. Este método é o mais vulnerável para
lidar com protocolo de resolução (arp) ou controle de acesso à mídia (media access control - MAC), e
lidar com spoofing de endereços de ambos - intrusos externos e usuários não autorizados em máquinas
locais.

2.2.1.2. Servidores Centralizados


Outra potencial armadilha na rede é o uso da computação centralizada. Uma forma comum de corte
de gastos em muitas empresas é consolidar todos os serviços em apenas uma máquina poderosa.
Isto pode ser conveniente, pois é mais fácil de gerenciar e custa bem menos que configurações de
servidores múltiplos. No entanto, um servidor centralizado apresenta apenas um ponto único de falha
na rede. Se o servidor central for comprometido, pode danificar a rede ou inutilizá-la, um cenário
propício para a manipulação ou roubo de dados. Nestas situações um servidor central torna-se uma
porta aberta, permitindo acesso à toda rede.

2.3. Ameaças à Segurança do Servidor


A segurança do servidor é tão importante quanto a segurança da rede porque os servidores frequente-
mente armazenam grande parte das informações vitais de uma empresa. Se um servidor for compro-
metido, todo o seu conteúdo pode ficar disponível para o cracker roubar ou manipular como quiser.
As seções a seguir detalham algumas das principais questões.

2.3.1. Serviços Não Usados e Portas Abertas


Uma instalação completa do Red Hat Enterprise Linux contém mais de 1000 aplicações e pacotes
de bibliotecas. No entanto, a maioria dos adminstradores de servidor não optam por instalar todos
os pacotes da distribuição; preferem, ao invés disso, instalar os pacotes básicos, incluindo diversas
aplicações para servidor.
Capítulo 2. Atacantes e Vulnerabilidades 11

Uma ocorrência comum dentre administradores de sistemas é instalar o sistema operacional sem
prestar atenção em quais pacotes realmente estão sendo instalados. Isto pode ser problemático, pois
serviços desnecessários podem ser instalados, configurados com opções default e possivelmente
acionados. Isto pode fazer com que serviços não quistos, como Telnet, DHCP ou DNS, sejam
executados em um servidor ou estação de trabalho sem que o adminstrador perceba, o que pode
causar tráfego indesejado no servidor, ou até mesmo uma via potencial para crackers ao sistema. Veja
Capítulo 5 para informações sobre fechar portas e desativar serviços não utilizados.

2.3.2. Serviços Não Consertados (unpatched)


A maioria das aplicações de servidor inclusas em uma instalação default são sólidas, partes de software
testadas exaustivamente. Sendo utilizadas em ambientes de produção por muitos anos, seus códigos
têm sido constantemente refinados e muitos dos erros (bugs) foram encontrados e consertados.
Entretanto, não existe software perfeito e sempre há espaço para mais aprimoramento. Além disso,
software mais novos frequentemente não são rigorosamente testados como se espera, porque chegaram
recentemente a ambientes de produção ou porque talvez não sejam tão populares quanto outros soft-
ware de servidor.
Desenvolvedores e administradores de sistemas frequentemente encontram erros exploráveis em apli-
cações de servidor e publicam a informação em sites de rastreamento de erros e relacionados a se-
gurança, como a lista de discussão ’Bugtraq’ (http://www.securityfocus.com) ou o site do ’Com-
puter Emergency Response Team’ (CERT) - (http://www.cert.org). Apesar destes mecanismos serem
maneiras efetivas de alertar a comunidade sobre vulnerabilidades de segurança, é responsabilidade
dos adminsitradores consertarem seus sistemas prontamente. Isto requer uma atenção especial pois
os crackers têm acesso aos mesmos serviços de rastreamento de vulnerabilidades e utilizarão as in-
formações para violar sistemas não consertados sempre que puderem. Uma boa administração de
sistemas requer vigilância, constante rastreamento de erros e manutenção apropriada do sistema para
assegurar um ambiente computacional mais seguro.
Consulte o Capítulo 3 para mais informações sobre como manter um sistema atualizado.

2.3.3. Administração Desatenta


Administradores que não consertam seus sistemas apropriadamente são grandes ameaças à segurança
de servidores. De acordo com o ’System Administration Network and Security Institute’ (SANS), a
causa fundamental da vulnerabilidade na segurança de computadores é "delegar pessoas não treinadas
para manter a segurança e não prover nem treinamento nem tempo para que o trabalho seja exe-
cutado."1 Isto se aplica tanto para administradores inexperientes quanto para administradores super-
confiantes ou desmotivados.
Alguns administradores falham em consertar seus servidores e estações de trabalho, enquanto outros
falham em monitorar as mensagens de registro do kernel do sistema ou tráfego de rede. Outro erro
comum é deixar senhas ou chaves default de serviços inalteradas. Por exemplo: alguns bancos de
dados têm senhas de administração default porque seus desenvolvedores assumem que o adminstrador
de sistemas irá alterá-las imediatamente após a instalação. Se um administrador de banco de dados
deixar de alterar esta senha, mesmo um cracker inexperiente pode utilizar uma senha default conhecida
para obter privilégios administrativos ao banco de dados. Estes são apenas alguns dos exemplos de
como uma administração desatenta pode desencadear no comprometimento de servidores.

2.3.4. Serviços Essencialmente Inseguros


Até a empresa mais atenta pode ser vítima de vulnerabilidades se os serviços de rede forem essencial-
mente inseguros. Por exemplo, há muitos serviços desenvolvidos sob a suposição de que são utilizados

1. Fonte: http://www.sans.org/newlook/resources/errors.html
12 Capítulo 2. Atacantes e Vulnerabilidades

através de redes confiáveis, mas essa suposição deixa de ser verdadeira a partir do momento em que o
serviço for disponibilizado através da Internet — que por si só é essencialmente não confiável.
Um tipo de serviço de rede inseguro são aqueles que requerem nomes de usuário e senha não crip-
tografados para autenticação. Telnet e FTP são dois serviços deste tipo. Se um software de ’sniffing’
de pacotes está monitorando o tráfego entre o usuário remoto e um servidor deste tipo, os nomes de
usuário e senhas podem ser interceptadas facilmente.
Tais serviços também podem ser facilmente enquadrados no que a indústria da segurança chama de
ataque ’man-in-the-middle’. Neste tipo de ataque um cracker redireciona o tráfego de rede, enganando
um servidor de nomes crackeado na rede, apontando-o para sua máquina ao invés do servidor pre-
tendido. Quando alguém abrir uma sessão remota para este servidor, a máquina do atacante age como
um condutor invisível, situado discretamente entre o serviço remoto e o crédulo usuário, capturando
as informações. Desta maneira um cracker consegue obter senhas administrativas e dados sem que o
servidor ou o usuário perceba.
Outra categoria de serviços inseguros são sistemas de arquivos de rede e serviços de informação, como
NFS ou NIS, desenvolvidos explicitamente para uso em LANs, mas que, infelizmente, têm seu uso
extendido para WANs (para usuários remotos). O NFS não tem, por default, nenhuma autenticação
ou mecanismos de segurança configurados para prevenir um cracker de montar o compartilhamento
do NFS e acessar qualquer coisa contida nele. O NIS também tem informações vitais que devem
ser conhecidas por qualquer computador ou rede, incluindo senhas e permissões de arquivo, em um
banco de dados ACSII ou DBM (derivado do ASCII) somente-texto. Um cracker que obtém acesso
a este banco de dados poderá acessar qualquer conta de usuário de uma rede, inclusive a conta do
administrador.
Por default, o Red Hat Enterprise Linux é lançado com todos estes serviços desligados. No entanto,
como administradores frequentemente são forçados a usá-los, é essencial configurá-los cuidadosa-
mente. Consulte o Capítulo 5 para mais informações sobre como configurar serviços de maneira se-
gura.

2.4. Ameaças à Segurança da Estação de Trabalho e PC Pessoal


Estações de trabalho e PCs pessoais podem não ser tão propensos a ataques quanto redes ou servi-
dores, mas já que estes comumente contêm informações delicadas, tais como dados de cartões de
crédito, também são alvos de crackers de sistemas. Estações de trabalho também podem ser violadas
sem o conhecimento do usuário e utilizadas por atacantes como máquinas "escravas" em ataques co-
ordenados. Por estas razões, saber das vulnerabilidades de uma estação de trabalho pode poupar os
usuários da dor de cabeça de reinstalar o sistema operacional, ou pior, de recuperar-se do roubo de
dados.

2.4.1. Senhas Ruins


Senhas ruins representam uma das maneiras mais fáceis para um atacante obter acesso a um sistema.
Para saber mais sobre como evitar armadilhas comuns ao criar uma senha, veja a Seção 4.3.

2.4.2. Aplicações Cliente Vulneráveis


Apesar de um administrador poder ter um servidor completamente seguro e consertado, isto não sig-
nifica que usuários remotos estão seguros ao acessá-lo. Por exemplo, se o servidor oferece os serviços
Telnet e FTP através de uma rede pública, um atacante pode capturar os nomes de usuário e senhas
(somente-texto) ao longo da rede, e então usar as informações da conta para acessar a estação de
trabalho do usuário remoto.
Mesmo ao utilizar protocolos seguros, como o SSH, um usuário remoto pode estar vulnerável a de-
terminados ataques se ele não mantiver suas aplicações cliente atualizadas. Por exemplo, clientes da
Capítulo 2. Atacantes e Vulnerabilidades 13

versão 1 do SSH são vulneráveis a um ataque ’X-forwarding’ de servidores SSH maléficos. Uma vez
conectado ao servidor, o atacante pode capturar discretamente quaisquer teclas pressionadas e cliques
de mouse efetuados pelo cliente através da rede. Este problema foi consertado na segunda versão do
protocolo SSH, mas depende do usuário monitorar aplicações com tais vulnerabilidades e atualizá-las
quando necessário.
O Capítulo 4 aborda mais detalhadamente os passos que administradores e usuários domésticos devem
seguir para limitar a vulnerabilidade de estações de trabalho.
14 Capítulo 2. Atacantes e Vulnerabilidades
II. Configurando o Red Hat Enterprise Linux para
Segurança

Esta parte informa e instrui os administradores sobre as técnicas e ferramentas apropriadas a usar
para proteger estações de trabalho e servidores Red Hat Enterprise Linux e recursos de rede. Também
aborda como criar conexões seguras, bloquear portas e serviços, e como implementar a filtragem ativa
para evitar a intrusão na rede.

Índice
3. Atualizações de Segurança ........................................................................................................... 17
4. Segurança da Estação de Trabalho ............................................................................................. 23
5. Segurança do Servidor ................................................................................................................. 41
6. Redes Privadas Virtuais (Virtual Private Networks)................................................................. 55
7. Firewalls......................................................................................................................................... 65
Capítulo 3.
Atualizações de Segurança
Conforme as vulnerabilidades de segurança são descobertas, o software afetado deve ser atualizado
para limitar os potenciais riscos de segurança. Se o software é parte de um pacote de uma distribuição
do Red Hat Enterprise Linux atualmente suportada, a Red Hat, Inc. está comprometida em lançar
pacotes atualizados que consertem as vulnerabilidades assim que possível. Frequentemente, os comu-
nicados de um exploit de segurança são acompanhados de um conserto (ou código-fonte que conserte
o problema). Este conserto é então aplicado ao pacote Red Hat Enterprise Linux, testado pela equipe
de controle de qualidade da Red Hat e lançado como uma atualização de errata. Entretanto, se o co-
municado não inclui um conserto, um desenvolvedor da Red Hat trabalha juntamente ao mantenedor
do software para consertar o problema. Após consertar o problema, o pacote é testado e lançado como
uma atualização de errata.
Se for lançada uma atualização de errata para um software utilizado em seu sistema, é altamente
recomendável que você atualize os pacotes afetados assim que possível, para mininmizar o tempo
durante o qual seu sistema está potencialmente vulnerável.

3.1. Atualizando Pacotes


Ao atualizar o software de um sistema, é importante fazer o download da atualização de uma fonte
confiável. Um atacante pode reconstruir facilmente um pacote com a mesma versão daquele que su-
postamente resolverá o problema, mas com um exploit de segurança diferente no pacote, e depois
lançá-lo na Internet. Se isto acontecer, usar medidas de segurança, como checar os arquivos com o
RPM original, não detectará o exploit. Portanto, é muito importante que você apenas faça o download
de RPMs de fontes confiáveis, tais como Red Hat, Inc., e cheque a assinatura do pacote para verificar
sua integridade.
A Red Hat oferece duas maneiras de encontrar informações sobre as atualizações de errata:

1. Listadas e disponíveis para download na Red Hat Network


2. Listadas e não linkadas no site de Erratas da Red Hat

Nota
Começando pela linha de produtos Red Hat Enterprise Linux, os pacotes atualizados podem ser
baixados somente pela Red Hat Network. Apesar do site de Erratas da Red Hat conter informações
atualizadas, não contém os pacotes para download.

3.1.1. Usando a Red Hat Network


A Red Hat Network permite que você automatize a maior parte do processo de atualização. Ela de-
termina quais pacotes são necessários para seu sistema, faz o download destes a partir de uma fonte
segura, verifica a assinatura RPM, para assegurar que os pacotes não foram corrompidos, e os atualiza.
A instalação do pacote pode ser feita imediatamente ou pode ser agendada durante um determinado
período de tempo.
A Red Hat Network requer um Perfil do Sistema para cada máquina a ser atualizada. O Perfil do
Sistema contém informações de hardware e software do sistema. Essas informações são mantidas
confidenciais e não são distribuídas a ninguém. São usadas somente para determinar quais atualizações
18 Capítulo 3. Atualizações de Segurança

de errata são aplicáveis para cada sistema. Sem o perfil, a Red Hat Network não pode determinar se
um sistema precisa de atualizações. Quando uma errata de segurança (ou qualquer tipo de errata) é
lançada, a Red Hat Network envia um email com a descrição da errata assim como quais sistemas são
afetados por ela. Para aplicar a atualização, você pode usar o Agente de Atualizações Red Hat ou
agendar a atualização do pacote pelo site http://rhn.redhat.com.

Dica
O Red Hat Enterprise Linux inclui a Ferramenta de Notificação de Alerta da Red Hat Network,
um ícone conveniente no painel que exibe alertas quando há uma atualização para um sistema Red
Hat Enterprise Linux registrado. Consulte a seguinte URL para mais informações sobre o applet:
http://rhn.redhat.com/help/basic/applet.html

Para saber mais sobre os benefícios da Red Hat Network, consulte o Guia de
Referência da Red Hat Network (Red Hat Network Reference Guide) disponível em
http://www.redhat.com/docs/manuals/RHNetwork/ ou visite http://rhn.redhat.com.

Importante
Antes de instalar qualquer errata de segurança, certifique-se de ler todas as instruções especiais
contidas no relatório da errata e executá-las. Consulte a Seção 3.1.5 para instruções gerais sobre
como aplicar as alterações feitas por uma atualização de errata.

3.1.2. Usando o Site de Erratas da Red Hat


Quando os relatórios de erratas de segurança são lançados, são publicados no site de Erratas da Red
Hat http://www.redhat.com/security/. A partir desta página, selecione o produto e versão de seu sis-
tema e então selecione security no topo da página para exibir apenas os Relatórios de Segurança
da Red Hat Enterprise Linux. Se a sinopse de um dos relatórios descreve um pacote usado em seu
sistema, clique na sinopse para ver mais detalhes.
A página de detalhes descreve o exploit de segurança e quaisquer instruções especiais que devem ser
executadas para atualizar o pacote e consertar a brecha na segurança.
Para fazer o download do(s) pacote(s) atualizado(s), clique no link para se logar na Red Hat Network,
depois clique no(s) nome(s) do(s) pacote(s) e salve-os no disco rígido. É altamente recomendável que
você crie um novo diretório como /tmp/atualizações e salve todos os pacotes baixados ali.

3.1.3. Verificando Pacotes Assinados


Todos os pacotes do Red Hat Enterprise Linux são assinados com a chave GPG da Red Hat, Inc..
GPG significa GNU Privacy Guard, ou GnuPG, um pacote de software livre usado para garantir a
autenticidade dos arquivos distribuídos. Por exemplo: uma chave privada (chave secreta) mantida
pela Red Hat tranca o pacote enquanto a chave pública o destranca e o verifica. Se a chave pública
distribuída pela Red Hat não bate com a chave privada durante a verificação RPM, o pacote pode ter
sido alterado e, portanto, não é confiável.
O utilitário RPM do Red Hat Enterprise Linux tenta automaticamente verificar a assinatura GPG de
um pacote RPM antes de instalá-lo. Se a chave GPG da Red Hat não está instalada, instale-a a partir
de uma localidade segura e estática, como um CD-ROM do Red Hat Enterprise Linux.
Capítulo 3. Atualizações de Segurança 19

Assumindo que o CD-ROM esteja montado em /mnt/cdrom, use o seguinte comando para importá-la
para o chaveiro (um banco de dados do sistema com chaves confiáveis):

rpm --import /mnt/cdrom/RPM-GPG-KEY

Para exibir uma lista com todas as chaves instaladas para verificação de RPM, execute o seguinte
comando:

rpm -qa gpg-pubkey*

Para a chave da Red Hat, o output inclui o seguinte:

gpg-pubkey-db42a60e-37ea5438

Para exibir detalhes sobre uma chave específica, use o comando rpm -qi seguido do output do co-
mando anterior, conforme o exemplo:

rpm -qi gpg-pubkey-db42a60e-37ea5438

É extremamente importante verificar a assinatura dos arquivos RPM antes de instalá-los. Este passo
assegura que eles não foram alterados depois do lançamento dos pacotes pela Red Hat, Inc.. Para
verificar todos os pacotes do download de uma só vez, submeta o seguinte comando:

rpm -K /tmp/updates/*.rpm

Se a chave GPG for verificada com sucesso, o comando retorna gpg OK para cada pacote. Caso
contrário, certifique-se de usar a chave pública correta da Red Hat, assim como verificar a fonte do
conteúdo. Os pacotes que não passarem na verificação GPG não devem ser instalados, pois podem ter
sido alterados por terceiros.
Após verificar as chaves GPG e fazer o download de todos os pacotes associados ao relatório da errata,
instale os pacotes como root em uma janela de comandos.

3.1.4. Instalando Pacotes Assinados


A instalação da maioria dos pacotes pode ser feita com segurança (exceto pacotes do kernel), subme-
tendo o seguinte comando:

rpm -Uvh /tmp/updates/*.rpm

Para pacotes do kernel, use o seguinte comando:


rpm -ivh /tmp/updates/ kernel-package 
No exemplo anterior, substitua  kernel-package  pelo nome do RPM do kernel.
Após reinicializar a máquina com segurança usando o novo kernel, o kernel antigo deve ser removido
usando o seguinte comando:

rpm -e  old-kernel-package 
No exemplo anterior, substitua  old-kernel-package  pelo nome do RPM do kernel antigo.
20 Capítulo 3. Atualizações de Segurança

Nota
Não é necessário remover o kernel antigo. O gestor de início default, GRUB, permite a instalação de
kernels múltiplos, dos quais escolhemos um no menu de inicialização da máquina.

Importante
Antes de instalar qualquer errata de segurança, certifique-se de ler todas as instruções especiais
contidas no relatório da errata e executá-las. Consulte a Seção 3.1.5 para instruções gerais sobre
como aplicar as alterações feitas por uma atualização de errata.

3.1.5. Aplicando as Alterações


Após fazer o download e instalar as erratas de segurança através da Red Hat Network ou do site de
erratas da Red Hat, é importante parar de usar o software antigo e passar a usar o novo. O modo como
isso é feito depende do tipo de software que foi atualizado. A lista a seguir aponta as categorias gerais
de software e oferece instruções para usar as versões atualizadas após uma atualização de pacotes.

Nota
Em geral, reinicializar o sistema é a maneira mais certa de garantir que a versão mais recente de um
pacote de software é usada; entretanto, esta opção nem sempre está disponível ao administrador
de sistemas.

Aplicações
Aplicações em espaço de usuário (user-space) são quaisquer programas que podem ser iniciados
por um usuário do sistema. Geralmente, estas aplicações são usadas somente quando um usuário,
um script ou um utilitário de tarefa automatizada as lança, e não persistem por longos períodos.
Após uma aplicação em espaço de usuário ser atualizada, pare todas as instâncias da aplicação
no sistema e lance o programa novamente a fim de usar a versão atualizada.

Kernel
O kernel é o componente central do software do sistema operacional Red Hat Enterprise Linux.
Ele gerencia o acesso à memória, ao processador e periféricos e também agenda todas as tarefas.
Devido sua função 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 reinicial-
izado.

Bibliotecas Compartilhadas
Bibliotecas compartilhadas são unidades de código, como a glibc, que são usadas por diversas
aplicações e serviços. As aplicações que utilizam uma biblioteca compartilhada geralmente car-
regam o código compartilhado quando a aplicação é iniciada, portanto todas as aplicações que
usam a biblioteca compartilhada devem ser paradas e relançadas.
Capítulo 3. Atualizações de Segurança 21

Para determinar quais aplicações estão relacionadas a uma determinada biblioteca, use o co-
mando lsof, conforme o exemplo a seguir:
lsof /usr/lib/libwrap.so*
Este comando retorna uma lista de todos os programas sendo executados, que usam TCP wrap-
pers para controle de acesso à máquina. Portanto, quaisquer programas listados devem ser para-
dos e relançados se o pacote tcp_wrappers for atualizado.

Serviços SysV
Serviços SysV são programas persistentes de servidor lançados durante o processo de inicializa-
ção. Exemplos de serviços SysV incluem sshd, vsftpd e xinetd.
Como estes programas geralmente persistem na memória enquanto a máquina é reinicializada,
cada serviço SysV atualizado deve ser parado e relançado após o upgrade do pacote. Isto pode
ser feito usando a Ferramenta de Configuração dos Serviços ou se autenticando a uma janela


de comandos root e submetendo o comando /sbin/service como no exemplo seguinte:



/sbin/service service-name restart
No exemplo anterior, substitua service-name pelo nome do serviço, como sshd.
Consulte o capítulo intitulado Controlando Acesso aos Serviços no Guia de Administração de
Sistemas Red Hat Enterprise Linux para mais informações sobre a Ferramenta de Configuração
dos Serviços.

Serviços xinetd
Os serviços controlados pelo super serviço xinetd rodam somente quando há uma conexão
ativa. Exemplos de serviços controlados pelo xinetd incluem Telnet, IMAP e POP3.
Como novas instâncias destes serviços são lançadas pelo xinetd cada vez que um novo pedido é
recebido, as conexões que ocorrem depois de um upgrade são feitas pelo software atualizado. No
entanto, se há conexões ativas no momento em que o serviço controlado xinetd é atualizado,
elas são feitas pela versão antiga do software.
Para terminar instâncias antigas de um serviço em particular controlado pelo xinetd, faça o
upgrade do pacote do serviço e então pare todos os processos sendo executados. Primeiro, deter-
mine se o processo está rodando, usando o comando ps e então use o comando kill ou killall
para parar as instâncias atuais do serviço.
Por exemplo: se os pacotes da errata de segurança imap são lançados, faça o upgrade dos pacotes
e então digite o seguinte comando como root em uma janela de comandos:
ps -aux | grep imap
Este comando retorna todas as sessões IMAP ativas. As sessões individiuais podem então ser


terminadas com o seguinte comando:



kill -9 PID
No exemplo anterior, substitua PID pelo número de identificação do processo (encontrado
na segunda coluna do comando ps) de uma sessão IMAP.
Para terminar todas as sessões IMAP ativas, submeta o seguinte comando:
killall imapd
Consulte o capítulo intitulado TCP Wrappers e xinetd no Guia de Referência do Red Hat
Enterprise Linux para informações gerais sobre o xinetd.
22 Capítulo 3. Atualizações de Segurança
Capítulo 4.
Segurança da Estação de Trabalho
Proteger um ambiente Linux começa pela estação de trabalho. Na proteção de sua máquina pessoal
ou sistema corporativo, uma boa política de segurança começa pelo computador individual. Afinal de
contas, uma rede de computadores é tão segura quanto seu nódulo mais vulnerável.

4.1. Avaliando a Segurança da Estação de Trabalho


Ao avaliar a segurança de uma estação de trabalho Red Hat Enterprise Linux, considere o seguinte:

• Segurança do BIOS e Gestor de Início — Um usuário não autorizado pode acessar fisicamente a
máquina e inicializá-la como um usuário simples ou no modo de recuperação sem uma senha?
• Segurança da Senha — Quão seguras são as senhas de conta de usuário na máquina?
• Controles Administrativos — Quem tem uma conta no sistema e quanto controle administrativo
eles têm?
• Serviços Disponíveis na Rede — Quais serviços estão escutando por pedidos da rede? Eles real-
mente devem estar rodando?
• Firewalls Pessoais — Qual o tipo de firewall necessário (caso haja)?
• Ferramentas de Comunicação para Segurança Aprimorada — Quais ferramentas devem ser usadas
para a comunicação entre estações de trabalho e quais devem ser evitadas?

4.2. Segurança do BIOS e do Gestor de Início


A proteção da senha para o BIOS (ou componente equivalente) e para o gestor de início pode im-
pedir usuários não autorizados, que tenham acesso físico aos seus sistemas, de inicializar a máquina
com mídia removível ou obter privilégios root através do modo de usuário simples. Mas as medidas
de segurança a tomar para proteger o sistema de ataques deste tipo dependem da sensibilidade das
informações que a estação de trabalho armazena e da localização da máquina.
Por exemplo: se uma máquina é usada numa exposição ou feira e não contém informações delicadas,
então não deve ser crítico impedir tais ataques. Entretanto, se um laptop de um funcionário com chaves
SSH privadas não criptografadas da rede corporativa for deixado nesta mesma feira sem a proteção de
senhas, pode ocasionar uma violação de segurança severa com consequências para a empresa inteira.
Por outro lado, se a estação de trabalho estiver localizada em um lugar onde somente pessoas con-
fiáveis e autorizadas têm acesso, então proteger o BIOS ou o gestor de início pode não ser necessário.

4.2.1. Senhas do BIOS


Veja a seguir as duas razões principais para proteger o BIOS de um computador com senhas 1:

1. Impedindo Alterações na Configuração do BIOS — Se um intruso tem acesso ao BIOS, pode


configurá-lo para ser iniciado por um disquete ou CD-ROM. Isto possibilita que ele entre no
modo de recuperação ou de usuário simples, que por sua vez permite a ele iniciar programas
arbitrariamente no sistema ou copiar informações delicadas.

1. Como BIOSes de sistemas diferem entre fabricantes, alguns talvez não suportem proteção de senhas de
nenhum tipo, enquanto outros podem suportar um tipo e outro não.
24 Capítulo 4. Segurança da Estação de Trabalho

2. Impedindo a Inicialização do Sistema — Alguns BIOSes permitem que você proteja o processo
de inicialização da máquina com senha. Quando ativado, um atacante é forçado a inserir uma
senha antes do BIOS lançar o gestor de início.
Como os métodos para definir uma senha para o BIOS variam de acordo com o fabricante do com-
putador, consulte o manual de seu computador para obter instruções específicas.
Se você esquecer a senha do BIOS, ela pode ser restaurada com jumpers na placa-mãe ou desligando
a bateria CMOS. Por esta razão, é aconselhável trancar o compartimento do computador, se possível.
Não obstante, consulte o manual do computador ou da placa-mãe antes de tentar desligar a bateria
CMOS.

4.2.1.1. Protegendo Plataformas Não-x86


Outras arquiteturas usam programas diferentes para executar tarefas de nível baixo, parecidas àquelas
do BIOS em sistemas x86. Por exemplo: computadores baseados no Intel® Itanium™ usam a shell
EFI (Extensible Firmware Interface).
Para instruções sobre a proteção através de senha a programas parecidos com o BIOS em outras
arquiteturas, consulte as instruções do fabricante.

4.2.2. Senhas do gestor de Início


Veja a seguir as principais razões para proteger um gestor de início Linux com senha:

1. Impedindo Acesso ao Modo de Usuário Simples — Se um atacante puder inicializar o sistema no


modo de usuário simples, ele é autenticado automaticamente como o usuário root sem precisar
indicar a senha root.
2. Impedindo Acesso ao Console do GRUB — Se a máquina utiliza GRUB como seu gestor de
início, um atacante pode usar a interface de edição do GRUB para alterar sua configuração ou
para coletar informações usando o comando cat.
3. Impedindo Acesso a Sistemas Operacionais Não-Seguros — Se for um sistema de boot duplo,
um atacante pode selecionar um sistema operacional na hora da inicialização, tal como o DOS,
que ignora controles de acesso e permissões de arquivo.
O gestor de início GRUB é distribuído com o Red Hat Enterprise Linux para a plataforma x86. Para
uma visão detalhada do GRUB, consulte o capítulo intitulado O Gestor de Início GRUB no Guia de
Referência do Red Hat Enterprise Linux.

4.2.2.1. Senha Protegendo o GRUB


Você pode configurar o GRUB para resolver as primeiras duas questões listadas na Seção 4.2.2 adicio-
nando uma diretiva de senha ao seu arquivo de configuração. Para fazer isso, primeiro decida a senha,
abra uma janela de comandos, logue-se como root e digite:

/sbin/grub-md5-crypt

Quando solicitada, digite a senha do GRUB e pressione [Enter]. Isto retornará um hash MD5 da senha.
Em seguida, edite o arquivo de configuração do GRUB /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


Capítulo 4. Segurança da Estação de Trabalho 25

Substitua  password-hash  pelo valor retornado pelo /sbin/grub-md5-crypt2.


Na próxima vez que inicializar o sistema, o menu do GRUB não deixará você acessar o editor ou a
interface de comando sem que pressione [p] seguida da senha do GRUB.
Infelizmente, esta solução não impede que um atacante inicialize em um sistema operacional não-
seguro em um ambiente de boot duplo. Para isso, você precisa editar uma parte diferente do arquivo
/boot/grub/grub.conf.
Procure pela linha title do sistema operacional não-seguro e adicione uma linha contendo lock
logo abaixo dela.
Para um sistema DOS, a estrofe deve começar similarmente a:

title DOS
lock

Atenção
Você deve ter uma linha password na seção principal do arquivo /boot/grub/grub.conf para que
este método funcione apropriadamente. Caso contrário, um atacante poderá acessar a interface de
edição do GRUB e remover a linha lock.

Para criar uma senha diferente para um kernel ou sistema operacional específico, adicione uma linha
lock na estrofe, seguida de uma linha para senha.
Cada estrofe que você proteger com uma senha única deve começar com linhas similares ao exemplo
seguinte:

title DOS
lock
password --md5  password-hash 

4.3. Segurança da Senha


Senhas são o método principal usado pelo Red Hat Enterprise Linux para verificar a identidade de
usuários. É por isso que a segurança da senha é tão importante para a proteção do usuário, da estação
de trabalho e da rede.
Por motivos de segurança, o programa de instalação configura o sistema para usar o Algoritmo
Message-Digest (MD5) e senhas shadow. É altamente recomendável que você não altere estas
configurações.
Se você desselecionar as senhas MD5 durante a instalação, o antigo formato Padrão de Criptografia
de Dados (DES - Data Encryption Standard) é utilizado. Este formato limita as senhas a oito caracteres
alfa-numéricos (impedindo o uso de pontuação e outros caracteres especiais) e oferece um nível de
criptografia modesto de 56 bits.
Se você desselecionar as senhas shadow durante a instalação, todas as senhas são armazenadas como
’one-way hash’ em um arquivo /etc/passwd legível por todos, o que torna o sistema vulnerável a
ataques de cracking offline. Se um intruso puder obter acesso a uma máquina como um usuário co-
mum, ele pode copiar o arquivo /etc/passwd para sua própria máquina e rodar inúmeros programas

2. O GRUB também aceita senhas não-criptografadas, mas é recomendado usar a versão md5 para segurança
adicional.
26 Capítulo 4. Segurança da Estação de Trabalho

de cracking neste arquivo. Se houver uma senha desprotegida no arquivo, é apenas uma questão de
tempo para o cracker descobrí-la.
Senhas shadow eliminam a ameaça deste tipo de ataque, armazenando as senhas hash (misturadas)
em um arquivo /etc/shadow, legível somente pelo usuário root.
Isto força um atacante potencial a tentar craquear a senha remotamente se autenticando em um serviço
de rede na máquina, como SSH ou FTP. Este tipo de ataque de força bruta é bem mais lento e deixa
rastros óbvios, já que centenas de tentativas de autenticação mal-sucedidas são registradas nos ar-
quivos do sistema. Claro que, se o cracker começar um ataque no meio da noite em um sistema com
senhas fracas, ele pode obter acesso e editar os arquivos de registro para apagar seus rastros antes da
luz do dia.
Além das questões de formato e armazenamento, há também a questão de conteúdo. A coisa mais
importante que um usuário pode fazer para proteger sua conta de cracking de senha é criar uma senha
forte.

4.3.1. Criando Senhas Fortes


Ao criar uma senha segura, é uma boa idéia seguir estas instruções:

Não faça o seguinte:

• Não Use Apenas Palavras ou Números — Nunca use somente palavras ou números em uma
senha.
Alguns exemplos de senhas inseguras:
• 8675309
• juan
• hackme

• Não Use Palavras Reconhecíveis — Palavras como nomes próprios, palavras de dicionário ou
até termos de shows de televisão ou novelas devem ser evitados, mesmo que sejam finalizados
com números.
Alguns exemplos de senhas inseguras:
• john1
• DS-9
• mentat123

• Não Use Palavras em Idiomas Estrangeiros — Programas de cracking de senhas frequente-


mente checam listas de palavras que incluem dicionários de muitos idiomas. Confiar em id-
iomas estrangeiros para proteger senhas não é seguro.
Alguns exemplos de senhas inseguras:
• cheguevara
• bienvenido1
• 1dumbKopf
Capítulo 4. Segurança da Estação de Trabalho 27

• Não Use Terminologia de Hacker — Se você se acha parte de uma elite por utilizar terminolo-
gia de hacker — também chamada l337 (LEET) speak — em sua senha, repense. Muitas listas
de palavras incluem LEET speak.
Alguns exemplos de senhas inseguras:
• H4X0R
• 1337

• Não Use Informações Pessoais — Fique longe das informações pessoais. Se o atacante souber
quem você é, ele terá facilidade em descobrir sua senha. A seguir, veja uma lista de tipos de
informação a evitar na criação de uma senha:
Alguns exemplos de senhas inseguras:
• Seu nome
• O nome de animais de estimação
• O nome de familiares
• Quaisquer datas de aniversário
• Seu número de telefone ou código postal

• Não Inverta Palavras Reconhecíveis — Bons verificadores de senha sempre revertem palavras
comuns, portanto reverter uma senha ruim não a torna mais segura.
Alguns exemplos de senhas inseguras:
• R0X4H
• nauj
• 9-DS

• Não Anote Sua Senha — Nunca guarde uma senha em papel. É bem mais seguro memorizá-la.
• Não Use a Mesma Senha Para Todas as Máquinas — É importante criar senhas separadas para
cada máquina. Desta maneira, se um sistema for comprometido, todas as outras máquinas não
estarão em risco imediato.

Faça o seguinte:

• Crie uma Senha de no Mínimo Oito Caracteres — Quanto mais longa a senha, melhor. Se você
estiver usando senhas MD5, deve ter 15 ou mais caracteres. Para senhas DES, use o tamanho
máximo (oito caracteres).
• Misture Letras em Caixa Alta e Baixa — O Red Hat Enterprise Linux é sensível a maiúsculas
e minúsculas, portanto misture-as para criar uma senha mais forte.
• Misture Letras e Números — Adicionar números a senhas, especialmente no meio delas (não
apenas no começo e fim), pode aumentar a força da senha.
• Inclua Caracteres Não Alfa-numéricos — Caracteres especiais como &, $ e
tar bastante a força de uma senha (isto não é possível se usar senhas DES).
 podem aumen-

• Escolha uma Senha que Você Possa Lembrar — A melhor senha do mundo de nada adianta se
você não conseguir lembrá-la. Então use acrônimos ou outros dispositivos mneumônicos para
ajudá-lo a memorizar senhas.
28 Capítulo 4. Segurança da Estação de Trabalho

Com todas estas regras, parece difícil criar uma senha que siga todos os critérios e evitar as carac-
terísticas de um senha ruim. Felizmente, há alguns passos simples a seguir para gerar uma senha
memorizável e segura.

4.3.1.1. Metodologia de Criação de Senha Segura


Há muitos métodos usados para criar senhas seguras. Um dos mais conhecidos envolve acrônimos.
Por exemplo:

• Pense em uma frase memorável, como:


"o sol da liberdade em raios fúlgidos brilhou no céu da pátria neste instante."
• Em seguida, transforme-a num acrônimo (incluindo a pontuação).
osdlerfbncdpni.
• Adicione complexidade substituindo letras por números e símbolos no acrônimo. Por exemplo:
substitua n por 9 e a letra d pelo símbolo arrouba (@):
o7r@77w,7ghwg.
• Adicione mais complexidade colocando pelo menos uma das letras em caixa alta, como F.
o7r@77w,7gHwg.
• Finalmente, nunca use o exemplo acima em nenhum de seus sistemas.
Criar senhas seguras é imperativo, mas gerenciá-las apropriadamente também é importante, espe-
cialmente para administradores de sistemas em empresas maiores. A próxima seção detalha as boas
prárticas para criar e gerenciar senhas de usuários em uma empresa.

4.3.2. Criando Senhas de Usuários Dentro de uma Empresa


Se houver um número significativo de usuários em uma empresa, os administradores de sistemas têm
duas opções básicas para forçar o uso de boas senhas. Eles podem criar senhas para os usuários,
ou podem deixar que os usuários criem suas próprias senhas, enquanto verificam se as senhas têm
qualidade aceitável.
Criar senhas para os usuários garante que as senhas sejam boas, mas se torna uma tarefa complicada
conforme a empresa cresce. Também aumenta o risco dos usuários anotarem suas senhas.
Por estas razões, a maioria dos administradores de sistema prefere que os usuários criem suas próprias
senhas, mas ativamente verificam se as senhas são boas e, em alguns casos, forçam os usuários a
trocarem suas senhas periodicamente conforme sua idade.

4.3.2.1. Forçando Senhas Fortes


Para proteger a rede de intrusões é uma boa idéia administradores de sistema verificarem se as senhas
usadas na empresa são fortes. Quando for pedido aos usuários criar ou alterar senhas, eles podem
utilizar a aplicação de linha de comando passwd, que é ciente do Gerenciador Plugável de Autenti-
cação (Pluggable Authentication Manager - PAM). Então, verificar se a senha é fácil de craquear ou
se é muito curta, através do módulo pam_cracklib.so do PAM. Como o PAM é personalizável, é
possível adicionar outros verificadores de integridade de senhas, como pam_passwdqc (disponível
em http://www.openwall.com/passwdqc/) ou escrever um módulo novo. Para visualizar uma lista dos
módulos PAM disponíveis, veja http://www.kernel.org/pub/linux/libs/pam/modules.html. Para mais
informações sobre o PAM, veja o capítulo intitulado Módulos Plugáveis de Autenticação (PAM) no
Guia de Referência do Red Hat Enterprise Linux.
Capítulo 4. Segurança da Estação de Trabalho 29

Note, no entanto, que a verificação executada nas senhas no momento de sua criação não descobre
senhas ruins tão efetivamente quanto rodar um programa de cracking de senhas nas senhas da empresa
inteira.
Há muitos programas de cracking de senhas que rodam no Red Hat Enterprise Linux, porém nenhum
é distribuído junto ao sistema operacional. Abaixo há uma breve lista de alguns dos programas de
cracking de senhas mais conhecidos:

Nota
Nenhuma destas ferramentas é provida junto ao Red Hat Enterprise Linux, portanto não são supor-
tadas pela Red Hat, Inc. de maneira nenhuma.

• John The Ripper — Um programa de cracking rápido e flexível. Permite o uso de listas de
palavras múltiplas e é capaz de craquear senhas com força bruta. Está disponível online em
http://www.openwall.com/john/.
• Crack — Talvez o programa de cracking mais conhecido, o Crack também é muito rápido,
porém não tão fácil de usar quanto o John The Ripper. Pode ser encontrado online:
http://www.crypticide.com/users/alecm/.
• Slurpie — O Slurpie é similar ao John The Ripper e ao Crack, mas é desenvolvido para ro-
dar em computadores múltiplos simultaneamente, criando um ataque de cracking de senha dis-
tribuído. Pode ser encontrado online, juntamente a outras ferramentas de avaliação de segurança
contra ataques distribuídos, em http://www.ussrback.com/distributed.htm.

Atenção
Sempre obtenha autorizações escritas antes de tentar craquear senhas dentro de uma empresa.

4.3.2.2. Idade da Senha


Idade da senha é uma outra técnica usada por administradores de sistema para defender uma empresa
contra senhas ruins. A idade da senha significa que depois de um determinado tempo (geralmente 90
dias) é solicitado ao usuário criar uma nova senha. A teoria por trás disso é se o usuário é forçado a
trocar sua senha periodicamente, uma senha crackeada por um intruso será útil somente por um tempo
limitado. A desvantagem desta técnica, no entanto, é que usuários tendem a anotar suas senhas.
Há dois programas principais usados para especificar a idade da senha sob o Red Hat Enterprise Linux:
o comando chage ou a aplicação gráfica Administrador de Usuários (redhat-config-users).
A opção -M do comando chage especifica o número máximo de dias em que a senha é válida. Por-
tanto, se um usuário quer que sua senha expire em 90 dias, deve digitar o seguinte comando:

chage -M 90  username 
 
No comando acima, substitua username pelo nome do usuário. Para desabilitar a expiração da
senha, é comum usar o valor 99999 depois da opção -M (isso equivale a um pouco mais de 273 anos).
A aplicação gráfica Administrador de Usuários também pode ser usada para criar normas de val-
idade de senhas. Para acessar esta aplicação, vá para o botão do Menu Principal (no Painel) =>
Configurações do Sistema => Usuários & Grupos ou digite o comando redhat-config-users
30 Capítulo 4. Segurança da Estação de Trabalho

em uma janela de comandos (num XTerm ou num terminal GNOME, por exemplo). Clique na aba
Usuários, selecione o usuário da lista e clique em Propriedades no botão do menu (ou selecione
Arquivo => Propriedades no menu suspenso).
Então clique na aba Informações de Senha e insira o número de dias antes da senha expirar, conforme
mostra a figura Figura 4-1.

Figura 4-1. Aba Informações de Senha

Para mais informações sobre a configuração do usuário e grupo (inclusive instruções sobre como
forçar as primeiras senhas), veja o capítulo Configuração de Usuário e Grupo do Guia de Adminis-
tração de Sistemas Red Hat Enterprise Linux. Para uma visão geral da administração de usuários
e recursos, consulte o capítulo Gerenciando Contas de Usuário e Acesso a Recursos (Managing
User Accounts and Resource Access) no Introdução à Administração de Sistemas Red Hat Enter-
prise Linux.

4.4. Controles Administrativos


Ao administrar um computador caseiro, o usuário deve executar algumas tarefas como usuário root
ou adquirindo privilégios efetivos de root através de um programa setuid, como o sudo ou o su.
Um programa setuid opera com o ID do usuário (UID) do proprietário do programa ao invés do
usuário operando o programa. Tais programas são caracterizados por um s em caixa baixa na seção
do proprietário de uma lista longa, conforme o exemplo a seguir:

-rwsr-xr-x 1 root root 47324 May 1 08:09 /bin/su

Para os administradores de sistema de uma empresa, no entanto, as escolhas devem ser feitas de acordo
com o nível de acesso administrativo que os usuários, dentro da organização, devem ter em suas
máquinas. Através de um módulo PAM chamado pam_console.so, algumas atividades reservadas
somente ao usuário root, como reinicializar e montar mídia removível, são permitidas ao primeiro
usuário que se autenticar no console físico (veja o capítulo intitulado Módulos Plugáveis de Auten-
ticação (PAM) do Guia de Referência do Red Hat Enterprise Linux para saber mais sobre o módulo
pam_console.so). Entretanto, outras tarefas importantes da administração de sistemas, como alterar
configurações da rede ou do mouse, ou montar dispositivos de rede, são impossíveis sem os privilé-
gios administrativos. Consequentemente, os administradores devem decidir o grau de acesso que os
usuários de sua rede devem receber.
Capítulo 4. Segurança da Estação de Trabalho 31

4.4.1. Permitindo Acesso Root


Se os usuários de uma empresa são um grupo confiável e experiente em computadores, permití-los
acesso root talvez não seja um problema. Permitir acesso root a usuários significa que questões
menores, como adicionar serviços ou configurar interfaces de rede, podem ser executadas pelos
usuários individuais, deixando os administradores de sistema livres para lidar com a segurança da
rede e outras questões mais importantes.
Por outro lado, permitir acesso root a usuários individuais pode acarretar nas questões a seguir:

• Má Configuração da Máquina — Usuários com acesso root podem mal-configurar suas máquinas
e pedir assistência ou pior, abrir buracos na segurança sem saber.
• Rodar Serviços Inseguros — Usuários com acesso root podem rodar serviços inseguros, como FTP
ou Telnet, em suas máquinas, potencialmente arriscando nomes de usuários e senhas conforme
trafegam sem criptografia pela rede.
• Anexando Arquivos em Emails como Root — Apesar de raros, existem vírus de e-mail que afetam
o Linux. A única hora em que eles representam uma ameaça, no entanto, é quando são executados
pelo usuário root.

4.4.2. Impedindo Acesso Root


Se o administrador não estiver confortável em permitir que usuários se autentiquem como root por
estas ou por outras razões, a senha de root deve ser guardada secretamente, e o acesso ao nível de
execução um ou ao modo de usuário simples deve ser impedido através da proteção da senha do
gestor de início (veja a Seção 4.2.2 para mais informações sobre este tópico).
A Tabela 4-1 mostra as maneiras de um administrador garantir que autenticações root estão impedidas:

Método Descrição Efeitos Não Afeta


Alterar a Edite o arquivo Impede acesso à shell root Programas que não
shell root. /etc/passwd e altere a e registra a tentativa. requerem uma shell, como
shell de /bin/bash para Os seguintes programas clientes FTP, clientes de
/sbin/nologin. são impedidos de acessar mail e muitos programas

a conta root:
login
setuid.
Os seguintes programas
 gdm
kdm
não são impedidos de

acessar a conta root:
 xdm
su

sudo
clientes FTP


ssh clientes de Email
scp
sftp
32 Capítulo 4. Segurança da Estação de Trabalho

Método Descrição Efeitos Não Afeta


Desativar Um arquivo Impede o acesso à conta Programas que não se
acesso /etc/securetty vazio root através do console ou logam como root, mas
root impede a autenticação de rede. Os seguintes executam tarefas
através de root a quaisquer programas são impedidos administrativas através de
qualquer
disposi-
dispositivos atachados ao
computador. 
de acessar a conta root:
login
mecanismos setuid ou
outros.
tivo de
console  gdm
kdm
Os seguintes programas
não são impedidos de
(tty).
 xdm
Outros serviços de rede 
acessar a conta root:
su
que abrem uma tty
 sudo
ssh

 scp
sftp
Desativar Edite o arquivo Impede o acesso root Isto impede somente o
autenti- /etc/ssh/sshd_config através do conjunto de acesso root ao conjunto de
cações e defina o parâmetro ferramentas OpenSSH. Os ferramentas do OpenSSH.
root SSH. PermitRootLogin para programas a seguir são
no. impedidos de acessar a

conta root:
ssh

 scp
sftp
Utilizar o Edite o arquivo para o Impede o acesso root para Programas e serviços que
PAM serviço em questão no serviços de rede não são notificados pelo
para diretório /etc/pam.d/. notificados pelo PAM. PAM.
limitar o Assegure que Os seguintes serviços são
acesso pam_listfile.so seja impedidos de acessar a
root aos
serviços.
necessário para a
autenticação.a 
conta root:
clientes FTP

clientes de Email
login

 gdm
kdm

 xdm
ssh


scp
sftp
Quaisquer serviços
notificados pelo PAM
Notas:
a. Consulte a Seção 4.4.2.4 para mais detalhes.
Tabela 4-1. Métodos para Desativar a Conta Root

4.4.2.1. Desativar a Shell Root


Para impedir os usuários de se autenticar diretamente como root, o administrador de sistema pode
configurar a shell da conta root para /sbin/nologin no arquivo /etc/passwd. Isto impede o acesso
à conta root através de comandos que requerem uma shell, como os comandos su e ssh.
Capítulo 4. Segurança da Estação de Trabalho 33

Importante
Programas que não requerem acesso à shell, como clientes de email ou o comando sudo, ainda
podem acessar a conta root.

4.4.2.2. Impossibilitando Autenticações Root


Para limitar acesso à conta root, os administradores podem desativar autenticações root no console
editando o arquivo /etc/securetty. Este arquivo lista todos os dispositivos nos quais o usuário
root pode se autenticar. Se o arquivo não existir, o usuário root pode se autenticar através de qualquer
dispositivo de comunicação no sistema, seja através do console ou de uma interface de rede bruta.
Isto é perigoso pois um usuário pode acessar o Telnet em sua máquina como root, enviando sua senha
em formato texto através da rede. Por default, o arquivo /etc/securetty do Red Hat Enterprise
Linux permite somente ao usuário root se autenticar no console fisicamente conectado à máquina.
Para impedir que root se autentique, remova o conteúdo deste arquivo digitando o seguinte comando:

echo > /etc/securetty

Atenção
Um arquivo /etc/securetty em branco não impede o usuário root de se autenticar remotamente
usando o conjunto de ferramentas OpenSSH porque o console não é aberto antes da autenticação.

4.4.2.3. Impossibilitando Autenticações Root SSH


Para impedir autenticações do root através do protocolo SSH, edite o arquivo de configuração do
daemon SSH (/etc/ssh/sshd_config). Altere a linha que apresenta:

# PermitRootLogin yes

para o seguinte:

PermitRootLogin no

4.4.2.4. Impossibilitar Root de Usar PAM


O PAM, através do módulo /lib/security/pam_listfile.so, permite grande flexibilidade em
negar contas específicas. Isto permite que o administrador aponte o módulo para uma lista de usuários
que não são permitidos de autenticar. O exemplo abaixo mostra como o módulo é usado para o servidor
FTP vsftpd no arquivo de configuração do PAM /etc/pam.d/vsftpd (o caracter \ no final da
primeira linha no exemplo a seguir não é necessário se a diretiva estiver em apenas uma linha):

auth required /lib/security/pam_listfile.so item=user \


sense=deny file=/etc/vsftpd.ftpusers onerr=succeed

Isto diz ao PAM para consultar o arquivo /etc/vsftpd.ftpusers e negar a qualquer usuário listado
acessar o serviço. O administrador é livre para alterar o nome deste arquivo e pode guardar listas
separadas para cada serviço ou usar uma lista geral para negar acesso a múltiplos serviços.
34 Capítulo 4. Segurança da Estação de Trabalho

Se o administrador quer negar acesso a múltiplos serviços, uma linha similar pode ser adicionada aos
serviços de configuração do PAM, como /etc/pam.d/pop e /etc/pam.d/imap para clientes de
mail ou /etc/pam.d/ssh para clientes SSH.
Para mais informações sobre o PAM, veja o capítulo Módulos Plugáveis de Autenticação (PAM) no
Guia de Referência do Red Hat Enterprise Linux.

4.4.3. Limitar Acesso Root


Ao invés de negar completamante acesso ao usuário root, o administrador pode permitir acesso apenas
através de programas setuid, como o su ou o sudo.

4.4.3.1. O Comando su
Ao digitar o comando su, é pedida a senha root ao usuário e, após a autenticação, é dada uma janela
de comandos.
Uma vez autenticado através do comando su, o usuário é o usuário root e tem acesso administrativo
absoluto ao sistema. Além disso, uma vez que o usuário obteve aceeso root, é possível que ele use o
comando su para alterar qualquer outro usuário no sistema sem precisar inserir uma senha.
Como este programa é tão poderoso, administradores dentro de uma empresa talvez queiram limitar
quem tem acesso ao comando.
Uma das maneiras mais simples de fazer isso é adicionar usuários ao grupo administrativo especial
chamado wheel. Para fazer isso, digite o seguinte comando como root:

usermod -G wheel  username 


No comando anterior, substitua
wheel.
 username  pelo nome do usuário sendo adicionado ao grupo

Para usar o Administrador de Usuários para este propósito, clique no Botão do Menu Principal
(no Painel) => Configurações do Sistema => Grupos & Usuários ou digite o comando
redhat-config-users numa janela de comandos. Selecione a aba Usuários, selecione o
usuário da lista e clique em Propriedades a partir do menu do botão (ou selecione Arquivo =>
Propriedades a partir do menu suspenso).
Então selecione a aba Grupos e clique no grupo wheel, conforme mostra Figura 4-2.
Capítulo 4. Segurança da Estação de Trabalho 35

Figura 4-2. Aba Grupos

Em seguida, abra o arquivo de configuração do PAM para su (/etc/pam.d/su) em um editor de


texto e remova o comentário [#] da seguinte linha:

auth required /lib/security/$ISA/pam_wheel.so use_uid

Fazer isso permitirá que somente membros do grupo administrativo wheel usem o programa.

Nota
O usuário root é parte do grupo wheel por default.

4.4.3.2. O Comando sudo


O comando sudo oferece uma outra maneira de dar acesso administrativo a usuários. Quando um
usuário confiável precede um comando administrativo com sudo, ele precisa inserir sua própria
senha. Então, uma vez autenticado e assumindo que o comando é permitido, o comando adminis-
trativo é executado como se fosse pelo usuário root.
O formato básico do comando sudo é o seguinte:

sudo  command 

No exemplo acima, command será substituído por um comando normalmente reservado para o
usuário root, como o comando mount.

Importante
Usuários do comando sudo devem tomar cuidado extra para fazer logout antes de deixarem suas
máquinas, já que é possível usar o comando novamente sem precisar indicar a senha, por um
período de cinco minutos. Esta configuração pode ser alterada através do arquivo de configuração
/etc/sudoers.
36 Capítulo 4. Segurança da Estação de Trabalho

O comando sudo permite um grau de flexibilidade maior. Por exemplo: somente os usuários listados
no arquivo de configuração /etc/sudoers são permitidos a usar o comando sudo e o comando é
executado na shell do usuário, não numa shell root. Isto significa que a shell root pode ser completa-
mente impossibilitada, conforme mostramos na Seção 4.4.2.1.
O comando sudo também oferece um registro detalhado da sequência de eventos. Cada autenticação
bem-sucedida é registrada no arquivo /var/log/messages e o comando submetido junto ao nome
do usuário é registrado no arquivo /var/log/secure.
Outra vantagem do comando sudo é que um administrador pode permitir a diferentes usuários acesso
a comandos específicos baseado em suas necessidades.
Administradores que queiram editar o arquivo de configuração do sudo, o /etc/sudoers, devem
usar o comando visudo.
Para dar privilégios administrativos totais a alguém, digite visudo e adicione uma linha similar à
seguinte na seção de especificação de privilégios do usuário:

juan ALL=(ALL) ALL

Este exemplo estabelece que o usuário juan pode usar o sudo em qualquer máquina e executar
qualquer comando.
O exemplo abaixo ilustra a granularidade possível ao configurar o sudo:

%users localhost=/sbin/shutdown -h now

Este exemplo estabelece que qualquer usuário pode submeter o comando /sbin/shutdown -h now
desde que o faça pelo console.
A página man de sudoers tem uma lista detalhada das opções para este arquivo.

4.5. Serviços de Rede Disponíveis


Enquanto o acessso a controles administrativos é uma questão importante para administradores de
sistemas dentro de uma empresa, manter controle de quais serviços de rede estão ativos é de suma
importância para qualquer um que administrar e operar um sistema Linux.
Muitos serviços comportam-se como servidores de rede sob o Red Hat Enterprise Linux. Se um
serviço de rede estiver rodando em uma máquina, então uma aplicação de servidor chamada dae-
mon está escutando conexões em uma ou mais portas de rede. Cada um destes servidores deve ser
tratado como uma via potencial de ataque.

4.5.1. Riscos aos Serviços


Serviços de rede podem apresentar muitos riscos a sistemas Linux. Veja abaixo uma lista com as
principais questões:

• Ataques Denial of Service (DoS) — Ao inundar um serviço com pedidos, um ataque de denial of
service pode trazer ao sistema uma parada terrível ao tentar registrar e responder à cada pedido.
• Ataques à Vulnerabilidade do Script — Se um servidor estiver usando scripts para executar ações
no lado do servidor, como servidores Web geralmente fazem, um cracker pode montar um ataque
com scripts escritos inapropriadamente. Estes ataques à vulnerabilidade do script podem acarretar
na condição de sobrecarga do buffer ou permitir que o atacante altere arquivos no sistema.
• Ataques de Sobrecarga do Buffer (Buffer Overflow) — Serviços que se conectam a portas numer-
adas de 0 a 1023 devem ser executados por um usuário administrativo. Se a aplicação tiver uma
Capítulo 4. Segurança da Estação de Trabalho 37

sobrecarga explorável do buffer, um atacante pode obter acesso ao sistema como o usuário rodando
o daemon. Devido à existência de sobrecarga explorável do buffer, os crackers usam ferramentas
automatizadas para identificar sistemas com vulnerabilidades, e após obterem acesso ao sistema,
utilizam rootkits automatizados para mantê-lo.

Nota
A ameaça das vulnerabilidades da sobrecarga do buffer é amenizada no Red Hat Enterprise Linux
pelo ExecShield , uma tecnologia de segmentação e proteção da memória executável suportada
pelos kernels de mono ou mulit-processadores x86. O ExecShield reduz o risco de sobrecarga do
buffer dividindo a memória virtual em segmentos executáveis e não-executáveis. Qualquer código
de programa que tentar executar fora do segmento executável (como código maldoso de um exploit
da sobrecarga do buffer) aciona uma falha na segmentação e é terminado.
O Execshield também inclui suporte para a tecnologia No eXecute (NX) nas plataformas AMD64 e
para a tecnologia eXecute Disable (XD) em sistemas Itanium e EM64T da Intel®. Estas tecnologias
trabalham em conjunto com o ExecShield para impedir que código maldoso rode na porção exe-
cutável da memória virtual com uma granularidade de 4kb de código executável, diminuindo o risco
de ataques exploits furtivos da sobrecarga do buffer.
Para mais informações sobre as tecnologias do ExecShield, NX ou XD, consulte o documento técnico
intitulado New Security Enhancements in Red Hat Enterprise Linux v.3, Update 3, disponível na
seguinte URL:
http://www.redhat.com/solutions/info/whitepapers/

Para limitar a exposição a ataques através da rede, todos os serviços não utilizados devem ser desliga-
dos.

4.5.2. Identificando e Configurando Serviços


Para aumentar a segurança, a maioria dos serviçosde rede instalados com o Red Hat Enterprise Linux
são desligados por default. No entanto, há algumas exceções notáveis:

• cupsd — O servidor de impressão default do Red Hat Enterprise Linux.


• lpd — Um servidor de impressão alternativo.
• xinetd — Um super servidor que controla as conexões para uma máquina de servidores subordi-
nados, como vsftpd e telnet.
• sendmail — O agente de transporte Sendmail é ativado por default, mas escuta apenas conexões
a partir da máquina local (localhost).
• sshd — O servidor OpenSSH, um substituto seguro para o Telnet.
Ao determinar se estes serviços devem ou não ser deixados rodando, é melhor usar o bom senso
e pecar pela precaução. Por exemplo: se uma impressora não está disponível, não deixe o cupsd
rodando. O mesmo vale para o portmap. Se você não monta volumes NFSv3 ou não usa o NIS (o
serviço ypbind), então o portmap deve ser desativado.
O Red Hat Enterprise Linux é distribuído com três programas desenvolvidos para ligar e desli-
gar serviços. Eles são: Ferramenta de Configuração dos Serviços (system-config-services),
ntsysv e chkconfig. Para informações sobre o uso destas ferramentas, consulte o capítulo Con-
trolando Acesso aos Serviços do Guia de Administração de Sistemas Red Hat Enterprise Linux.
38 Capítulo 4. Segurança da Estação de Trabalho

Figura 4-3. Ferramenta de Configuração dos Serviços

Se você não está certo sobre o propósito de um serviço específico, a Ferramenta de Configuração
dos Serviços tem um campo de descrição, ilustrado na Figura 4-3, que pode lhe ser útil.
Mas verificar quais serviços de rede estão disponíveis para iniciar no momento de ligar a máquina
(boot) não é suficiente. Bons administradores de sistema também devem verificar quais portas estão
abertas e escutando. Veja a Seção 5.8 para mais informações sobre o assunto.

4.5.3. Serviços Inseguros


Potencialmente, qualquer rede é insegura. Por este motivo, desligar serviços não usados é tão impor-
tante. Exploits de serviços são revelados e consertados rotineiramente. Portanto é importante manter
atualizados os pacotes associados a qualquer serviço de rede. Veja o Capítulo 3 para mais detalhes
sobre este assunto.
Alguns protocolos de rede são essencialmente mais inseguros que outros. Estes incluem quaisquer
serviços que façam o seguinte:

• Passem Nomes de Usuário e Senha Não Criptografados por uma Rede — Muitos protocolos anti-
gos, como Telnet e FTP, não criptografam a seção de autenticação e devem ser evitados sempre que
possível.
• Passar Dados Importantes por uma Rede Não-Criptografada — Muitos protocolos passam dados
através da rede não-criptografada. Estes protocolos incluem o Telnet, FTP, HTTP e o SMTP. Muitos
sistemas de arquivo de rede, como o NFS e o SMB, também passam informações através da rede
não-criptografada. É responsabilidade do usuário limitar o tipo de dados transmitidos ao utilizar
estes protocolos.
Serviços dump de memória remota, como o netdump, passam o conteúdo da memória não crip-
tografado através da rede. Dumps de memória podem conter senhas ou pior, informações de banco
de dados ou outras informações delicadas.
Outros serviços como finger e rwhod revelam informações sobre os usuários do sistema.
Exemplos de serviços essencialmente inseguros incluem os seguintes:

• rlogin

• rsh
Capítulo 4. Segurança da Estação de Trabalho 39

• telnet
• vsftpd

Todos os programas de autenticação e shell (rlogin, rsh e telnet) devem ser evitados a favor do
SSH. (Veja a Seção 4.7 para mais informações sobre o sshd).
O FTP não é essencialmente tão perigoso à segurança do sistema quanto janelas de comando (shells)
remotas, mas os servidores FTP devem ser configurados e monitorados cuidadosamente para evitar
problemas. Veja a Seção 5.6 para mais informações sobre a proteção de servidores FTP.
Aqui estão alguns dos serviços que devem ser implementados cuidadosamente e por trás de um fire-
wall:

• finger
• identd

• netdump
• netdump-server
• nfs
• rwhod

• sendmail
• smb (Samba)
• yppasswdd

• ypserv
• ypxfrd
Você pode consultar mais informações sobre a proteção de serviços de rede no Capítulo 5.
A próxima seção aborda as ferramentas disponíveis para configurar um firewall simples.

4.6. Firewalls Pessoais


Uma vez configurados os serviços de rede necessários, é importante implementar um firewall.
Firewalls evitam que pacotes de rede acessem a interface de rede do sistema. Se for feito um pedido
a uma porta sendo bloqueada pelo firewall, este será ignorado. Se o serviço estiver escutando numa
destas portas bloqueadas, não receberá os pacotes e será efetivamente desabilitado. Por este motivo,
tome cuidado ao configurar um firewall para bloquear acesso a portas não usadas, para não bloquear
acesso a portas usadas por serviços configurados.
Para a maioria dos usuários, a melhor ferramenta para configurar um firewall simples é a ferramenta
de configuração gráfica distribuída com o Red Hat Enterprise Linux: a Ferramenta de Configuração
do Nível de Segurança (system-config-securitylevel). Esta ferramenta cria regras iptables
abrangentes para um firewall com propósitos genéricos usando uma interface de painel de controle.
Para mais informações sobre o uso desta aplicação e das opções ela oferece, consulte o capítulo
intitulado Configuração Básica do Firewall no Guia de Administração de Sistemas Red Hat Enterprise
Linux.
Para usuários avançados e administradores de servidores, configurar manualmente um firewall com
iptables é provavelmente a melhor opção. Consulte o Capítulo 7 para mais informações. Para aces-
sar um guia detalhado sobre o comando iptables, consulte o capítulo iptables no Guia de Refer-
ência do Red Hat Enterprise Linux.
40 Capítulo 4. Segurança da Estação de Trabalho

4.7. Ferramentas de Comunicação de Segurança Aprimorada


Na mesma proporção em que o tamanho e a popularidade da Internet tem crescido, cresceu também
a ameaça da intercepção de comunicações. Através do anos, ferramentas foram desenvolvidas para
criptografar comunicações ao longo de sua transferência pela rede.
O Red Hat Enterprise Linux é distribuído com duas ferramentas básicas que usam algoritmos de alto
nível e baseados em criptografia de chave pública para proteger as informações conforme trafegam
pela rede.

• OpenSSH — Uma implementação livre do protocolo SSH para criptografar comunicações de rede.
• Gnu Privacy Guard (GPG) — Uma implementação livre da aplicação de criptografia PGP (Pretty
Good Privacy) para criptografar dados.
OpenSSh é uma maneira mais segura de acessar uma máquina remota e substitui serviços não crip-
tografados como telnet e rsh. OpenSSH inclui um serviço de rede, chamado sshd, e três aplicações
cliente de linha de comandos:

• ssh — Um cliente de acesso seguro ao console remoto.


• scp — Um comando seguro de cópia remota.
• sftp — Um cliente pseudo-ftp seguro que permite seções interativas de transferência de arquivo.
É altamente recomendado que qualquer comunicação remota com sistemas Linux ocorra usando o
protocolo SSH. Para mais informaçõe sobre o OpenSSH, veja o capítulo OpenSSH do Guia de Ad-
ministração de Sistemas Red Hat Enterprise Linux. Para mais informações sobre o Protocolo SSH,
veja o capítulo Protocolo SSH no Guia de Referência do Red Hat Enterprise Linux.

Importante
Apesar do serviço sshd ser essencialmente seguro, ele deve ser mantido atualizado para evitar
ameaças de segurança. Veja o Capítulo 3 para mais informações sobre esta questão.

GPG é uma maneira de garantir a privacidade da comunicação por e-mail. Pode ser usado para en-
viar email com dados delicados através de redes públicas e para proteger dados delicados em discos
rígidos.
Para mais informações sobre o uso do GPG, consulte o apêndice intitulado Guia de Iniciação do Gnu
Privacy Guard do Guia Passo a Passo do Red Hat Enterprise Linux.
Capítulo 5.
Segurança do Servidor
Quando um sistema é usado como um servidor em um rede pública, torna-se um alvo de ataques. Por
esta razão solidificar e trancar os serviços é de suma importância para o administrador de sistemas.
Antes de aprofundar em questões específicas, você deve revisar as seguintes dicas gerais para aumentar
a segurança do servidor:

• Mantenha todos os serviços atualizados para protegê-los contra as ameaças recentes.


• Use protocolos seguros sempre que possível.
• Ofereça apenas um tipo de serviço de rede por máquina sempre que possível.
• Monitore todos os servidores cuidadosamente e atente para atividades suspeitas.

5.1. Protegendo Serviços com TCP Wrappers e xinetd


TCP wrappers oferecem controle de acesso a vários serviços. A maioria dos serviços de rede moder-
nos, como SSH, Telnet e FTP, utilizam os TCP wrappers, que ficam de guarda entre a entrada de um
pedido e o serviço requisitado.
Os benefícios oferecidos pelos TCP wrappers aumentam quando este é usado junto ao xinetd, um
super serviço que oferece acesso adicional, registro, vinculação, redirecionamento e controle de uti-
lização de recursos.

Dica
É uma boa idéia usar regras de firewall do IPTables juntamente ao TCP wrappers e xinetd para
criar redundância nos controles de acesso ao serviço. Consulte o Capítulo 7 para mais informações
sobre a implementação de firewalls com comandos do IPTables.

Mais informações sobre a configuração do TCP wrappers e xinetd podem ser encontradas no capí-
tulo intitulado TCP Wrappers e xinetd do Guia de Referência do Red Hat Enterprise Linux;.
As sub-seções seguintes assumem um conhecimento básico de cada tópico e focam nas opções de
segurança específicas.

5.1.1. Aumentando a Segurança com TCP Wrappers


TCP wrappers são capazes de muito mais que negar acesso aos serviços. Esta seção ilustra como
eles podem ser utilizados para enviar banners de conexão, alertar ataques em máquinas específicas e
aprimorar a funcionalidade de registro. Consulte a página man hosts_options para obter uma lista
completa das funcionalidades e controle de idioma do TCP wrapper.

5.1.1.1. TCP Wrappers e Banners de Conexão


Enviar um banner intimidador para clientes conectando a um serviço é uma boa maneira de disfarçar
em qual sistema o servidor está rodando enquanto informa um atacante potencial que o administrador
de sistemas está vigiando. Para implementar um banner do TCP wrappers para um serviço, use a
opção banner.
42 Capítulo 5. Segurança do Servidor

Este exemplo implementa um banner para vsftpd. Para começar, crie um arquivo de banner. Pode
estar em qualquer lugar do sistema, mas deve levar o mesmo nome que o daemon. Neste exemplo, o
arquivo é chamado /etc/banners/vsftpd.
O conteúdo do arquivo é parecido com o seguinte:

220-Hello, %c
220-All activity on ftp.example.com is logged.
220-Act up and you will be banned.

A expressão %c oferece uma gama de informações do cliente, tais como nome de usuário e nome da
máquina ou nome de usuário e endereço IP, para intimidar ainda mais a conexão. O Guia de Referência
do Red Hat Enterprise Linux tem uma lista de outras expressões disponíveis para TCP wrappers.
Para que este banner seja apresentado em futuras conexões, adicione a seguinte linha ao arquivo
/etc/hosts.allow:

vsftpd : ALL : banners /etc/banners/

5.1.1.2. TCP Wrappers e Alertas de Ataque


Se uma determinada máquina ou rede for flagrada atacando o servidor, o TCP wrappers pode ser usado
para alertar o administrador sobre ataques subsequentes desta máquina ou rede através da diretiva
spawn.
Neste exemplo, assuma que um cracker da rede 206.182.68.0/24 foi pego tentando atacar o servi-
dor. Ao inserir a seguinte linha no arquivo /etc/hosts.deny, a tentativa de conexão é negada e
registrada em um arquivo especial:

ALL : 206.182.68.0 : spawn /bin/ ’date’ %c %d >> /var/log/intruder_alert

A expressão %d traz o nome do serviço que o atacante estava tentando acessar.


Para permitir a conexão e registrá-la, insira o informativo spawn no arquivo /etc/hosts.allow.

Nota
Já que a diretiva spawn executa qualquer comando de linha, crie um script especial para notificar o
administrador ou para executar uma série de comandos na ocasião em que um determinado cliente
tenta conectar ao servidor.

5.1.1.3. TCP Wrappers e Registro Aprimorado


Se determinados tipos de conexões são mais preocupantes que outras, o nível de registro pode ser
elevado para estes serviços através da opção severity.
Neste exemplo, assuma que qualquer um tentando conectar à porta 23 (a porta do Telnet) em um
servidor FTP é um cracker. Para denotar isso, insira um sinal emerg nos arquivos de registro ao invés
do sinal default, info, e negue a conexão.
Para fazer isso, insira a seguinte linha no arquivo /etc/hosts.deny:

in.telnetd : ALL : severity emerg


Capítulo 5. Segurança do Servidor 43

Isto usa a facilidade de registro authpriv default, mas eleva a prioridade do valor default info para
emerg, o que envia mensagens de registro diretamente ao console.

5.1.2. Aumentando a Segurança com o xinetd


O super servidor xinetd é uma outra ferramenta útil para controlar o acesso a seus serviços sub-
ordinados. Esta seção foca em como o xinetd pode ser usado para montar um serviço-armadilha
e controlar a quantidade de recursos que qualquer serviço xinetd pode usar para arruinar ataques
’denial of service’. Para obter uma lista mais completa das opções disponíveis, consulte as páginas
man do xinetd e do xinetd.conf.

5.1.2.1. Montando uma Armadilha


Uma importante característica do xinetd é sua habilidade em adicionar máquinas (hosts) a uma
lista de no_access. Às máquinas desta lista são negadas as conexões subsequentes aos serviços
gerenciados pelo xinetd por um determinado período ou até o xinetd ser reiniciado. Isto é feito
usando o atributo SENSOR. Esta técnica é uma maneira fácil de bloquear máquinas que tentarem
scanear o servidor.
O primeiro passo para definir um SENSOR é escolher um serviço que você não planeja utilizar. Neste
exemplo, usamos o Telnet.
Edite o arquivo /etc/xinetd.d/telnet e altere a linha flags para:

flags = SENSOR

Adicione as seguintes linhas entre os colchetes:

deny_time = 30

Isto nega a máquina que tentou conectar à porta por 30 minutos. Outros valores aceitáveis para o
atributo deny_time são FOREVER (sempre), que mantém o banimento efetivo até que o xinetd
seja reiniciado, e NEVER (nunca), que permite a conexão e a registra.
Finalmente, a última linha deve ser:

disable = no

Apesar de usar o SENSOR ser uma boa maneira de detectar e parar conexões de máquinas periogosas,
há duas desvantagens:

• Não funciona contra scans secretos.


• Um atacante ciente de que você está rodando o SENSOR pode montar um ataque ’denial of service’
contra determinadas máquinas forjando seus endereços IP e conectando à porta proibida.

5.1.2.2. Controlando Recursos de Servidor


Outra característica importante do xinetd é sua habilidade em controlar a quantidade de recursos
que os serviços sob seu controle podem utilizar.
Ele o faz através das seguintes diretivas:

• cps = ! number_of_connections "#! "


wait_period — Determina as conexões permitidas
ao serviço por segundo. Esta diretiva aceita apenas valores inteiros.
44 Capítulo 5. Segurança do Servidor

• instances = $ %
number_of_connections Determina o número total de conexões permitidas
a um serviço. Esta diretiva aceita tanto um valor inteiro como UNLIMITED.
• per_source = $ %
number_of_connections — Determina as conexões permitidas a um
serviço por cada máquina. Esta diretiva aceita tanto um valor inteiro como UNLIMITED.
• rlimit_as = $ %
number[K|M] — Determina a quantidade de "memory address space" que o
serviço pode ocupar em kilobytes ou megabytes. Esta diretiva aceita tanto um valor inteiro como
UNLIMITED.
• rlimit_cpu = $ %
number_of_seconds — Determina o tempo em segundos durante o qual
um serviço pode ocupar a CPU. Esta diretiva aceita tanto um valor inteiro como UNLIMITED.
Usando estas diretivas pode ajudar a prevenir que qualquer serviço xinetd sobrecarregue o sistema,
resultando em recusa de serviço (denial of service).

5.2. Protegendo o Portmap


O serviço portmap é um daemon de porta dinâmica para serviços RPC, como o NIS e o NFS. Tem
mecanismos de autenticação fracos e tem habilidade para delegar uma enorme gama de portas para os
serviços que controla. Por estas razões, é difcícil de proteger.

Nota
Proteger o portmap afeta somente as implementações do NFSv2 e NFSv3, já que o NFSv4 não o
requer mais. Se você planeja implementar um servidor NFSv2 ou NFSv3, o portmap é necessário e
a seção seguinte é válida.

Se você está rodando serviços RPC, siga estas regras básicas.

5.2.1. Proteja o portmap com TCP Wrappers


É importante usar o TCP wrappers para limitar quais redes ou máquinas têm acesso ao serviço
portmap já que este não possui uma forma de autenticação própria (built-in).
Futuramente, use somente endereços IP ao limitar acesso para o serviço. Evite usar estes nomes de
máquinas (hostnames), já que eles podem ser forjados através do ’poisoning’ do DNS e outros méto-
dos.

5.2.2. Proteja o portmap Com IPTables


Para restringir acesso ao serviço portmap futuramente, é uma boa idéia adicionar regras do IPTables
ao servidor e restringir o acesso a redes específicas.
Abaixo há dois exemplos de comandos do IPTables que permitem conexões TCP ao serviço portmap
(escutando na porta 111) a partir da rede 192.168.0/24 e da máquina local (que é necessária para o
serviço sgi_fam usado pelo Nautilus). Todos os outros pacotes são derrubados.

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

Para limitar o tráfego UDP similarmente, use o seguinte comando.


Capítulo 5. Segurança do Servidor 45

iptables -A INPUT -p udp -s! 192.168.0.0/24 --dport 111 -j DROP

Dica
Consulte o Capítulo 7 para mais informações sobre a implementação de firewalls com comandos do
IPTables.

5.3. Protegendo o NIS


NIS significa Serviço de Informações de Rede (Network Information Service). É um serviço RPC
chamado ypserv, usado em conjunto com o portmap e outros serviços relacionados, para distribuir
mapas de nomes de usuário, senhas e outras informações importantes para qualquer computador que
esteja em seu domínio.
Um servidor NIS é composto de diversas aplicações. Elas incluem as seguintes:

• /usr/sbin/rpc.yppasswdd — Também chamado de serviço yppasswdd, esse daemon permite


a usuários alterarem suas senhas NIS.
• /usr/sbin/rpc.ypxfrd — Também chamado de serviço ypxfrd, esse daemon é responsável
pelas transferências de mapa do NIS através da rede.
• /usr/sbin/yppush — Essa aplicação amplia bancos de dados NIS alterados para servidores NIS
múltiplos.
• /usr/sbin/ypserv — Este é o servidor daemon do NIS.
O NIS é bastante inseguro para os padrões de hoje. Não tem mecanismo de autenticação da máquina
e passa toda a sua informação sem criptografia através da rede, incluindo uma gama de senhas. Como
resultado, tenha muito cuidado ao configurar uma rede que usa NIS. Para complicar ainda mais, a
configuração default do NIS é essencialmente insegura.
É recomendado a qualquer um planejando implementar um servidor NIS, primeiro proteger o serviço
portmap conforme descrito na Seção 5.2, e então resolver as seguintes questões, como planejamento
da rede.

5.3.1. Planejar Cuidadosamente a Rede


Como o NIS passa informações delicadas sem criptografia através da rede, é importante que o serviço
seja executado por trás de um firewall e numa rede segmentada e segura. Toda vez que informações
do NIS são passadas através de uma rede insegura, seus riscos estão sendo interceptados. Um plane-
jamento cuidadoso da rede neste aspecto pode ajudar a prevenir sérias violações à segurança.

5.3.2. Use um Nome de Domínio e Nome da Máquina (hostname) NIS


parecido com uma senha
Qualquer máquina com um domínio NIS pode usar comandos para extrair informações do servidor
sem autenticação, desde que o usuário saiba o o nome da máquina DNS e o nome de domínio NIS do
servidor.
Por exemplo: se alguém conectar um laptop a uma rede ou violar a rede por fora (e conseguir roubar
um endereço IP interno), o seguinte comando revela o mapa de /etc/passwd:
46 Capítulo 5. Segurança do Servidor

ypcat -d & NIS_domain ' -h & DNS_hostname ' passwd

Se este atacante for um usuário root, poderá obter o arquivo /etc/shadow digitando o seguinte
comando:

ypcat -d & NIS_domain ' -h & DNS_hostname ' shadow

Nota
Se o Kerberos for usado, o arquivo /etc/shadow não estará armazenado em um mapa NIS.

Para dificultar o acesso aos mapas NIS a um atacante, crie uma série randômica de caracteres para o
nome da máquina DNS, tal como o7hfawtgmhwg.domain.com. Similarmente, crie um nome difer-
ente de domínio NIS randomizado . Isto dificulta bastante o acesso de um atacante ao servidor NIS.

5.3.3. Edite o Arquivo /var/yp/securenets


O NIS escuta todas as redes caso o arquivo /var/yp/securenets esteja em branco ou não exista
(como é o caso após uma instalação default). Uma das primeiras coisas a fazer é colocar pares máscara
de rede/rede no arquivo de modo que o ypserv responda somente aos pedidos da rede apropriada.
Veja abaixo um exemplo de entrada de um arquivo /var/yp/securenets:

255.255.255.0 192.168.0.0

Alerta
Nunca inicie um servidor NIS pela primeira vez sem criar o arquivo /var/yp/securenets.

Essa técnica não oferece proteção contra ataque de spoofing de IP, mas pelo menos impõe limites a
quais redes o servidor NIS serve.

5.3.4. Determinar Portas Estáticas e Usar Regras do IPTables


Todos os servidores relacionados ao NIS podem ter portas específicas, exceto o rpc.yppasswdd —
o daemon que permite a usuários alterarem suas senhas de autenticação (login). Determinar portas
para os outros dois daemons do servidor NIS, rpc.ypxfrd e ypserv, permite criar regras de firewall
para proteger futuramente os daemons do servidor NIS contra intrusos.
Para fazer isto, adicione as seguintes linhas a /etc/sysconfig/network:

YPSERV_ARGS="-p 834"
YPXFRD_ARGS="-p 835"

As seguintes regras do IPTables podem ser determinadas para reforçar a qual rede o servidor escuta
para estas portas:

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
Capítulo 5. Segurança do Servidor 47

Dica
Consulte o Capítulo 7 para mais informações sobre a implementação de firewalls com comandos do
IPTables.

5.3.5. Use Autenticação do Kerberos


Uma das desvantagens mais gritantes ao usar NIS para autenticação é que sempre que um usuário
se autentica (log in) numa máquina, uma senha com caracteres misturados é enviada do mapa
/etc/shadow através da rede. Se um intruso obtiver acesso a um domínio NIS e bisbilhotar o
tráfego de rede, essas misturas de nomes de usuários e senhas podem ser discretamente coletadas.
Com tempo suficiente, um programa de cracking de senha pode adivinhar senhas fáceis e um
atacante pode obter acesso a uma conta válida na rede.
Como o Kerberos usa criptografia de chave secreta, as misturas de senha nunca são enviadas através
da rede, tornando o sistema bem mais seguro. Para saber mais sobre o Kerberos, consulte o capítulo
intitulado Kerberos no Guia de Referência do Red Hat Enterprise Linux.

5.4. Protegendo o NFS


O Sistema de Arquivo de Rede (Network File System ou NFS) é um serviço que oferece sistemas
de arquivo acessíveis para máquinas cliente. Para mais informações sobre o funcionamento do NFS,
consulte o capítulo intitulado Sistema de Arquivo de Rede (NFS) no Guia de Referência do Red Hat
Enterprise Linux. Para mais informações sobre a configuração do NFS, consulte o Guia de Admin-
istração de Sistemas Red Hat Enterprise Linux. As sub-seções a seguir assumem um conhecimento
básico do NFS.

Importante
A versão do NFS inclusa no Red Hat Enterprise Linux, NFSv4, não requer mais o serviço portmap,
conforme abordado na Seção 5.2. O tráfego do NFS agora utiliza TCP em todas as versões (ao
invés do UDP) e o requer no uso do NFSv4. O NFSv4 agora inclui a autenticação do Kerberos para
usuário e grupo, como parte do módulo RPCSEC_GSS do kernel. As informações sobre o portmap
ainda são inclusas, já que o Red Hat Enterprise Linux suporta o NFSv2 e NFSv3, que o utilizam.

5.4.1. Planejar Cuidadosamente a Rede


Agora que o NFS tem a habilidade de passar todas as informações criptografadas usando o Kerberos
através da rede, é importante que o serviço seja configurado corretamente se estiver atrás de um
firewall ou numa rede segmentada. O NFSv2 e NFSv3 ainda passam dados inseguramente e seus riscos
devem ser considerados. Um planejamento cuidadoso da rede neste aspecto pode ajudar a prevenir
violações à segurança.

5.4.2. Cuidado com Erros de Sintaxe


O servidor NFS determina quais sistemas de arquivo e quais máquinas exportar para estes diretórios
através do arquivo /etc/exports. Cuidado para não adicionar espaços extras ao editar este arquivo.
Por exemplo: a linha a seguir no arquivo /etc/exports compartilha o diretório /tmp/nfs/ com a
máquina bob.example.com com permissões de leitura e escrita (rw).
48 Capítulo 5. Segurança do Servidor

/tmp/nfs/ bob.example.com(rw)

Por outro lado, esta linha do arquivo /etc/exports compartilha o mesmo diretório com a máquina
bob.example.com com permissão somente-leitura, e o compartilha com o mundo com permissões
leitura e escrita devido um único caractere de espaço após o nome da máquina (hostname).

/tmp/nfs/ bob.example.com (rw)

É bom praticar a verificação de todos os compartilhamentos do NFS usando o comando showmount


para checar o que foi compartilhado.

showmount -e ( hostname )
5.4.3. Não Use a Opção no_root_squash
Por default, as partilhas do NFS alteram o usuário root para o usuário nfsnobody, uma conta de
usuário sem privilégios. Desta maneira, todos os arquivos criados por root são de propriedade (owner)
do usuário nfsnobody, o que previne o upload de programas com as informações do conjunto de ids
do usuário.
Se no_root_squash é usado, os usuários root remotos poderão alterar qualquer arquivo do sistema
de arquivo compartilhado e deixar aplicações infectadas pelo trojan, para que outros usuários as exe-
cutem inadvertidamente.

5.5. Protegendo o Servidor HTTP Apache


O Servidor HTTP Apache é um dos serviços mais estáveis e seguros distribuídos com o Red Hat
Enterprise Linux. Há um número exorbitante de opções e técnicas disponíveis para proteger o Servidor
HTTP Apache — muito numerosos para serem explorados em detalhes aqui.
Ao configurar o Servidor HTTP Apache é importante ler a documentação disponível para
a aplicação. Isto inclui o capítulo intitulado Servidor HTTP Apache do Guia de Referência do
Red Hat Enterprise Linux, o capítulo Configuração do Servidor HTTP Apache do Guia de
Administração de Sistemas Red Hat Enterprise Linux e os manuais do Stronghold, disponíveis
online: http://www.redhat.com/docs/manuals/stronghold/.
Veja abaixo uma lista de opções de configuração para as quais administradores devem ser muito
cuidadosos.

5.5.1. FollowSymLinks
Esta diretiva é habilitada por default, portanto cuidado ao criar os links simbólicos na raiz do docu-
mento do servidor Web. Por exemplo: é uma má idéia prover um link simbólico para /.

5.5.2. A Diretiva Indexes


Esta diretiva é habilitada por default, mas pode não ser desejável. Para prevenir que visitantes naveg-
uem pelos arquivos no servidor, remova esta diretiva.
Capítulo 5. Segurança do Servidor 49

5.5.3. A Diretiva UserDir


A diretiva UserDir é desabilitada por default porque esta pode confirmar a presença de uma conta
de usuário no sistema. Para possibilitar a navegação pelos diretórios do usuário no servidor, use as
seguintes diretivas:

UserDir enabled
UserDir disabled root

Estas diretivas ativam a navegação em todos os diretórios de usuário, exceto no /root. Para adicionar
usuários à lista de contas desativadas, adicione uma lista de usuários delimitada por espaço na linha
UserDir disabled.

5.5.4. Não Remova a Diretiva IncludesNoExec


Por default, o lado do servidor inclui módulos que não podem executar comandos. Não é recomendado
alterar esta configuração a não ser que seja absolutamente necessário, já que pode, potencialmente,
possibilitar que um atacante execute comandos no sistema.

5.5.5. Permissões Restritas para Diretórios Executáveis


Certifique-se de conceder permissões de gravação (write) para o usuário root em todos os diretórios
contendo scripts ou CGIs. Isto pode ser feito digitando os seguintes comandos:

chown root
chmod 755 **
directory_name
directory_name ++
Também verifique sempre se todos os scripts rodando no sistema funcionam como planejado antes de
colocá-los em produção.

5.6. Protegendo o FTP


O Protocolo de Transporte de Arquivo (File Transport Protocol ou FTP) é um protocolo TCP antigo
desenvolvido para transferir arquivos pela rede. Já que todas as transações com o servidor (inclusive
a autenticação de usuário) são criptografadas, o FTP é considerado um protocolo inseguro e deve ser
configurado cuidadosamente.
O Red Hat Enterprise Linux oferece três servidores FTP.

• gssftpd — Um FTP daemon ’kerberizado’ baseado no xinetd que não passa informações de
autenticação através da rede.
• Acelerador de Conteúdo Red Hat (tux) — Um servidor Web com capacidades de FTP no espaço
do kernel.
• vsftpd — Uma implementação auto-suficiente do serviço FTP orientada à segurança.
As orientações de segurança a seguir se referem à configuração do serviço FTP vsftpd.

5.6.1. Banner de Saudação do FTP


Antes de submeter um nome de usuário e senha, é apresentado um banner de saudação a todos os
usuários. Por default, este banner inclui informações da versão úteis para crackers tentando identificar
fraquezas num sistema.
50 Capítulo 5. Segurança do Servidor

Para alterar o banner de saudação do vsftpd, adicione a seguinte diretiva a


/etc/vsftpd/vsftpd.conf:

,
ftpd_banner= insert_greeting_here -
Substitua
saudação.
. insert_greeting_here / na diretiva acima pelo texto de sua mensagem de

Para banners com muitas linhas, é melhor usar um arquivo de banner. Para simplificar o gerenciamento
de banners múltiplos, coloque todos os banners em um novo diretório chamado /etc/banners/.
O arquivo de banners para conexões FTP, neste exemplo, é /etc/banners/ftp.msg. O exemplo
abaixo mostra como este arquivo se parece:

####################################################
# Hello, all activity on ftp.example.com is logged.#
####################################################

Nota
Não é necessário começar cada linha do arquivo com 220, conforme especificado na Seção 5.1.1.1.

Para referenciar este arquivo de banners de saudação do vsftpd, adicione a seguinte diretiva ao
arquivo /etc/vsftpd/vsftpd.conf:

banner_file=/etc/banners/ftp.msg

Também é possível enviar banners adicionais para conexões entrantes usando TCP wrappers conforme
descrito na Seção 5.1.1.1.

5.6.2. Acesso Anônimo


A presença do diretório /var/ftp/ ativa a conta anônima.
A maneira mais fácil de criar este diretório é instalar o pacote vsftpd. Este pacote define uma árvore
de diretório para usuários anônimos e configura as permissões dos diretórios para somente-leitura para
usuários anônimos.
Por default, a conta do usuário anônimo não pode escrever em nenhum diretório.

Atenção
Se você possibilitar o acesso anônimo a um servidor FTP, tome cuidado onde armazena os dados
importantes.

5.6.2.1. Upload Anônimo


Para permitir que usuários anônimos façam upload, é recomendado criar um diretório
somente-gravação (write-only) em /var/ftp/pub/.
Para fazer isso, digite:

mkdir /var/ftp/pub/upload
Capítulo 5. Segurança do Servidor 51

Depois altere as permissões para que usuários anônimos não possam ver o que está no diretório,
digitando:

chmod 730 /var/ftp/pub/upload

Uma lista do diretório em formato longo deve se parecer com o seguinte:

drwx-wx--- 2 root ftp 4096 Feb 13 20:05 upload

Alerta
Administradores que permitem a usuários anônimos ler e gravar em diretórios, frequentemente
percebem que seu servidor se torna um depósito de software roubado.

Adicionalmente, abaixo de vsftpd, adicione a seguinte linha ao arquivo


/etc/vsftpd/vsftpd.conf:

anon_upload_enable=YES

5.6.3. Contas de Usuário


Já que o FTP passa nomes de usuário e senhas não criptografados através de redes inseguras para
autenticação, é uma boa idéia proibir usuários do sistema acessarem o servidor através de suas contas
de usuário.
Para desativar contas de usuário em vsftpd, adicione a seguinte diretiva a
/etc/vsftpd/vsftpd.conf:

local_enable=NO

5.6.3.1. Restringindo Contas de Usuário


A maneira mais fácil de desabilitar um grupo específico de contas, como o usuário root e aqueles com
privilégios sudo, a acessar um servidor FTP, é usar um arquivo de lista PAM conforme descrito na
Seção 4.4.2.4. O arquivo de configuração PAM para o vsftpd é /etc/pam.d/vsftpd.
Também é possível desativar contas de usuário dentro de cada serviço diretamente.
Para desativar contas de usuário específicas em vsftpd, adicione o nome do usuário a
/etc/vsftpd.ftpusers.

5.6.4. Use TCP Wrappers para Controlar Acesso


Use TCP wrappers para controlar o acesso a qualquer daemon do FTP, conforme descrito na Seção
5.1.1.
52 Capítulo 5. Segurança do Servidor

5.7. Protegendo o Sendmail


Sendmail é um Agente de Transporte de Correspondência (Mail Transport Agent - MTA) que utiliza
o Protocolo de Transporte de Correspondência Simples (Simple Mail Transport Protocol - SMTP)
para entregar mensagens eletrônicas entre outros MTAs e para enviar e-mails a clientes ou agentes
de entrega. Apesar de muitos MTAs serem capazes de criptografar tráfego entre eles, a maioria não o
faz, portanto enviar email através de qualquer rede pública é considerado uma forma de comunicação
essencialmente insegura.
Para mais informações sobre o funcionamento do e-mail e uma visão geral dos ajustes de configuração
comuns, veja o capítulo E-mail no Guia de Referência do Red Hat Enterprise Linux. Esta seção
assume um conhecimento básico de como gerar um /etc/mail/sendmail.cf válido, editando o
/etc/mail/sendmail.mc e executando o comando m4, conforme explicado no Guia de Referência
do Red Hat Enterprise Linux.
É recomendado a qualquer um planejando implementar um servidor Sendmail, resolver as seguintes
questões.

5.7.1. Limitar um Ataque Denial of Service


Devido à natureza do e-mail, um determinado atacante pode facilmente lotar o servidor com corre-
spondência e causar um ataque ’denial of service’. Ao determinar limites para as diretivas a seguir em
/etc/mail/sendmail.mc, a efetividade de ataques deste tipo é limitada.

• confCONNECTION_RATE_THROTTLE — O número de conexões que o servidor pode receber por


segundo. Por default, o Sendmail não limita o número de conexões. Se um limite for definido e
alcançado, conexões futuras terão demora.
• confMAX_DAEMON_CHILDREN — O número máximo de processos-filho que podem ser gerados
pelo servidor. Por default, o Sendmail não determina um número limite de processos-filho. Se um
limite for definido e alcançado, conexões futuras terão demora.
• confMIN_FREE_BLOCKS — O número mínimo de blocos livres que devem estar disponíveis para
que o servidor aceite correspondência. O default são 100 blocos.
• confMAX_HEADERS_LENGTH — O tamanho máximo aceitável (em bytes) para o cabeçalho de uma
mensagem.
• confMAX_MESSAGE_SIZE — O tamanho máximo aceitável (em bytes) para qualquer mensagem.

5.7.2. NFS e Sendmail


Nunca coloque o diretório spool de correspondência, /var/spool/mail/, em um volume NFS com-
partilhado.
Como o NFSv2 e o NFSv3 não mantêm controle sobre IDs de usuário e grupo, dois ou mais usuários
podem ter o mesmo UID, e portanto receber e ler a correspondência do outro. Isso não ocorre com o
NFSv4 usando Kerberos, já que o módulo SECRPC_GSS do kernel não utiliza a autenticação baseada
no UID.

5.7.3. Usuários Mail-only


Para ajudar a prevenir exploits locais no servidor Sendmail, é melhor que usuários de mail acessem o
Sendmail usando apenas um programa de email. Contas shell não devem ser permitidas no servidor de
mail e todos os usuários shell do arquivo /etc/passwd devem ser definidos para /sbin/nologin
(com a possível exceção do usuário root).
Capítulo 5. Segurança do Servidor 53

5.8. Verificando Quais Portas estão Escutando


Após configurar os serviços de rede, é importante atentar para quais portas estão escutando as inter-
faces de rede do sistema. Quaisquer portas abertas podem ser evidências de uma intrusão.
Há duas formas básicas de listar as portas que estão escutando a rede. A menos confiável é questionar
a lista da rede ao digitar comandos como netstat -an ou lsof -i. Este método é menos confiável
já que estes programas não conectam à máquina pela rede, mas checam o que está sendo executado
no sistema. Por esta razão, estas aplicações são alvos frequentes de substituição por atacantes. Desta
maneira, os crackers tentam cobrir seus passos se abrirem portas de rede não autorizadas.
Uma forma mais confiável de listar quais portas estão escutando a rede é usar um scanner de portas
como o nmap.
O comando a seguir, submetido em um console, determina quais portas estão escutando conexões FTP
pela rede:

nmap -sT -O localhost

O output deste comando se parece com o seguinte:

Starting nmap 3.55 ( http://www.insecure.org/nmap/ ) at 2004-09-24 13:49 EDT


Interesting ports on localhost.localdomain (127.0.0.1):
(The 1653 ports scanned but not shown below are in state: closed)
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.4.X|2.5.X|2.6.X
OS details: Linux 2.5.25 - 2.6.3 or Gentoo 1.2 Linux 2.4.19 rc1-rc7)
Uptime 12.857 days (since Sat Sep 11 17:16:20 2004)

Nmap run completed -- 1 IP address (1 host up) scanned in 5.190 seconds

Este output mostra que o sistema está rodando o portmap devido à presença do serviço sunrpc. No
entanto, também há um serviço misterioso na porta 834. Para verificar se a porta está associada à lista
oficial de serviços conhecidos, digite:

cat /etc/services | grep 834

Este comando não retorna nenhum output. Isto indica que enquanto a porta está no intervalo reservado
(de 0 a 1023) e requer acesso root para abrir, não está associada a um serviço conhecido.
Em seguida, verifique as informações sobre a porta usando netstat ou lsof. Para verificar a porta
834 usando netstat, use o seguinte comando:

netstat -anp | grep 834

O comando retorna o seguinte output:

tcp 0 0 0.0.0.0:834 0.0.0.0:* LISTEN 653/ypbind

A presença da porta aberta em netstat afirma que um cracker que abrir clandestinamente uma porta
num sistema hackeado provavelmente não permitirá que esta seja revelada através deste comando.
A opção [p] também revela o id do processo (PID) do serviço que abriu a porta. Neste caso, a
54 Capítulo 5. Segurança do Servidor

porta aberta pertence ao ypbind (NIS), que é um serviço RPC administrado juntamente ao serviço
portmap.
O comando lsof revela informações similares já que é capaz de ligar portas abertas a serviços:

lsof -i | grep 834

Veja abaixo a parte relevante do output deste comando:

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)

Estas ferramentas podem revelar muitas informações sobre o estado dos serviços rodando em uma
máquina. Estas ferramentas são flexíveis e podem prover uma riqueza de informações sobre os
serviços e configurações da rede. Portanto, recomendamos fortemente que você consulte as páginas
man do lsof, netstat, nmap e services.
Capítulo 6.
Redes Privadas Virtuais (Virtual Private
Networks)
Empresas com diversos escirtórios frequentemente se conectam através de linhas dedicadas por mo-
tivos de eficiência e proteção de dados sensíveis transitando entre as diferentes localidades. Por ex-
emplo: muitas empresas usam frame relay ou linhas Asynchronous Transfer Mode (ATM) como uma
solução de rede end-to-end para ligar um escritório aos outros. Esta poder ser uma alternativa cara,
especialmente para pequenas e médias empresas que queiram expandir sem arcar com os altos custos
associados a circuitos digitais dedicados, de nível corporativo.
Para atender a esta necessidade, foram desenvolvidas as Redes Privadas Virtuais (Virtual Private Net-
works - VPNs). Seguindo os mesmos princípios funcionais dos circuitos dedicados, as VPNs per-
mitem a comunicação digital protegida entre duas partes (ou redes), criando uma Rede de Área Am-
pla (Wide Area Network - WAN) a partir de Redes de Áreas Locais (LANs) existentes. Ela difere
do frame relay ou do ATM em seu meio de transporte. As VPNs transmitem através de IP usando
datagramas como a camada de transporte, tornando-o um condutor seguro através da Internet, para
um determinado destino. A maioria das implementações VPN de software livre incorporam métodos
de criptografia de padrão aberto para mascarar futuramente os dados em trânsito.
Algumas empresas aplicam soluções VPN de hardware para aumentar a segurança, enquanto outras
usam software ou implementações baseadas em protocolos. Há diversos fabricantes de soluções VPN
de hardware como Cisco, Nortel, IBM e Checkpoint. Existe uma solução VPN baseada em software
gratuito para Linux chamada FreeS/Wan, que utiliza uma implementação padronizada do IPSec (ou
Internet Protocol Security). Estas soluções VPN, independentemente de serem baseadas em hardware
ou software, atuam como roteadores especializados situados entre as conexões IP de dois escritórios.
Quando um pacote é transmitido de um cliente, é enviado através do roteador ou porta de comunicação
(gateway), que então adiciona informações de cabeçalho para roteamento e autenticação, chamado
Cabeçalho de Autenticação (Authentication Header, AH). Os dados são criptografados e agrupados
com instruções para resolução e descriptografia, chamadas Encapsulating Security Payload (ESP). O
roteador VPN receptor depura as informações de cabeçalho, descriptografa os dados e os roteia ao
destino pretendido (uma estação de trabalho ou um nódulo em uma rede). Usando uma conexão rede-
a-rede, o nódulo receptor da rede local recebe os pacotes descriptografados e prontos para processar. O
processo de criptografia/descriptografia numa conexão VPN rede-a-rede é transparente para o nódulo
local.
Com um nível tão elevado de segurança, não basta ao cracker interceptar o pacote, mas também
descriptografar o pacote. Intrusos que aplicarem um ataque man-in-the-middle entre um servidor e o
cliente também devem ter acesso à pelo menos uma das chaves privadas para sessões de autenticação.
Como aplicam diversas camadas de autenticação e criptografia, as VPNs são um meio seguro e efetivo
para conectar múltiplos nódulos remotos para atuar como uma intranet unificada.

6.1. VPNs e Red Hat Enterprise Linux


Os usuários do Red Hat Enterprise Linux têm várias opções em termos de implementação de uma
solução de software para conectar à sua WAN com segurança. A Segurança do Protocolo de Internet,
ou IPsec, é a implementação VPN suportada pelo Red Hat Enterprise Linux que atende às necessi-
dades de usabilidade de empresas com filiais ou usuários remotos.
56 Capítulo 6. Redes Privadas Virtuais (Virtual Private Networks)

6.2. IPsec
O Red Hat Enterprise Linux suporta o IPsec para conectar máquinas e redes remotas entre si usando
um túnel seguro em uma rede de transporte comum, como a Internet. O IPsec pode ser implementado
usando uma conexão máquina-a-máquina (uma estação de trabalho conectada a outra) ou rede-a-rede
(uma LAN/WAN conectada a outra). A implementação do IPsec no Red Hat Enterprise Linux usa
Troca de Chave de Internet (Internet Key Exchange, IKE), um protocolo implementado pelo IETF
(Internet Engineering Task Force) para ser usado em autenticação mútua e proteger associações entre
sistemas conectados.
Uma conexão IPsec é dividida em duas fases lógicas. Na fase 1, um nódulo do IPsec inicia a conexão
com o nódulo ou rede remota. O nódulo/rede remota verifica as credenciais do nódulo pedinte e ambas
partes negociam o método de autenticação da conexão. Nos sistemas Red Hat Enterprise Linux, uma
conexão IPsec usa o método de chave pré-compartilhada (pre-shared key) para autenticação do nódulo
IPsec. Numa conexão IPsec com chave pré-compartilhada, ambas máquinas devem usar a mesma
chave para prosseguir à segunda fase da conexão IPsec.
Durante a fase 2 de uma conexão IPsec é criada uma associação de segurança (security association,
SA) entre os nódulos IPsec. Essa fase estabelece um banco de dados de SAs com informações de
configuração, como o método de criptografia, parâmetros de troca de chaves de sessões secretas,
dentre outras. Essa fase administra a conexão IPsec entre nódulos e redes remotas.
A implementação do IPsec usa IKE para compartilhar chaves entre máquinas ao longo da Internet. O
deamon do chaveiro racoon é responsável pela distribuição e troca de chaves IKE.

6.3. Instalação do IPsec


A implementação do IPsec requer a instalação do pacote RPM ipsec-tools em todas as máquinas
IPsec (se usar uma configuração máquina-a-máquina) ou roteadores IPsec (se usar uma configuração
rede-a-rede). O pacote RPM contém bibliotecas, daemons e arquivos de configuração essenciais para
auxiliar na configuração da conexão IPsec, incluindo:

• /lib/libipsec.so — biblioteca que contém a interface socket de gerenciamento da chave de


confiança PF_KEY entre o kernel do Linux e a implementação do IPsec usada no Red Hat Enter-
prise Linux.
• /sbin/setkey — manipula o gerenciamento da chave e atributos de segurança do IPsec no ker-
nel. Este executável é controlado pelo daemon de gerenciamento da chave racoon. Para mais
informações sobre o setkey, consulte a página man (8) do setkey.
• /sbin/racoon — o daemon de gerenciamento da chave IKE, usado para administrar e controlar
as associações de segurança e compartilhamento de chaves entre sistemas conectados pelo IPsec.
Este daemon pode ser configurado editando o arquivo /etc/racoon/racoon.conf. Para mais
informações sobre o racoon, consulte a página man (8) do racoon.
• /etc/racoon/racoon.conf — o arquivo de configuração do daemon do racoon usado para
configurar vários aspectos da conexão IPsec, incluindo métodos de autenticação e algoritmos de
criptografia usados na conexão. Para uma lista completa das diretivas disponíveis, consulte a página
man (5) do racoon.conf.
A configuração do IPsec no Red Hat Enterprise Linux pode ser feita pela Ferramenta de Adminis-
tração de Rede ou manualmente editando os arquivos de configuração de rede e do IPsec. Para mais
informaçõe sobre o uso da Ferramenta de Administração de Rede, consulte o Guia de Adminis-
tração de Sistemas Red Hat Enterprise Linux.
Para conectar duas máquinas em rede através do IPsec, consulte a Seção 6.4. Para conectar uma
LAN/WAN a outra através do IPsec, consulte a Seção 6.5.
Capítulo 6. Redes Privadas Virtuais (Virtual Private Networks) 57

6.4. Configuração Máquina-a-Máquina do IPsec


O IPsec pode ser configurado para conectar um computador pessoal ou estação de trabalho a outra
através de uma conexão máquina-a-máquina. Este tipo de conexão utiliza a rede à qual cada máquina
está conectada para criar o túnel seguro entre elas. Os requisitos de uma conexão máquina-a-máquina
são mínimos, já que é a configuração do IPsec em cada máquina. As máquinas precisam somente de
uma conexão dedicada a uma rede de transporte (como a Internet) e do Red Hat Enterprise Linux para
criar a conexão do IPsec.
O primeiro passo para criar uma conexão é coletar as informações de sistemas e de rede de cada
estação de trabalho (workstation). Para uma conexão máquina-a-máquina, você precisa das seguintes
informações:

• O endereço IP das duas máquinas


• Um nome único para identificar a conexão IPsec e distinguí-la de outros dispositivos e conexões
(ex.: ipsec0)
• Uma chave fixa de criptografia ou uma gerada automaticamente pelo racoon
• Uma chave de autenticação pré-compartilhada, usada para iniciar a conexão e trocar chaves de
criptografia durante a sessão
Por exemplo: suponha que as estações de trabalho A e B queiram se interconectar através de um
túnel IPsec. Pretendem se conectar usando uma chave pré-compartilhada com o valor foobarbaz
e os usuários concordam em deixar que o racoon gere automaticamente e compartilhe uma chave
de autenticação entre cada máquina. Ambos usuários das máquinas decidem nomear suas conexões
como ipsec0.
Veja o arquivo ifcfg da estação de trabalho (workstation) A para uma conexão IPsec
máquina-a-máquina com a estação de trabalho B (o nome único para identificar a
conexão neste exemplo é ipsec0, portanto o arquivo resultante é nomeado como
/etc/sysconfig/network-scripts/ifcfg-ipsec0).

DST=X.X.X.X
TYPE=IPSEC
ONBOOT=yes
IKE_METHOD=PSK

A estação de trabalho A substituirá X.X.X.X pelo endereço IP da estação de trabalho B, enquanto


esta deve substituir X.X.X.X pelo endereço IP da estação de trabalho A. A conexão é definida
para iniciar na inicialização (boot-up) (ONBOOT=yes) e usa o método de autenticação de chave pré-
compartilhada (IKE_METHOD=PSK).
A seguir, veja o conteúdo do arquivo da chave pré-compartilhada (chamado
/etc/sysconfig/network-scripts/keys-ipsec0) que ambas máquinas precisam para
autenticarem-se entre si. O conteúdo deste arquivo deve ser idêntico nas duas estações de trabalho, e
somente o usuário root deve ser capaz de acessar ou gravar (read or write) este arquivo.

IKE_PSK=foobarbaz

Importante
Para alterar o arquivo keys-ipsec0 para que somente o usuário root possa acessá-lo ou editá-lo,
execute o seguinte comando após criar o arquivo:

chmod 600 /etc/sysconfig/network-scripts/keys-ipsec0


58 Capítulo 6. Redes Privadas Virtuais (Virtual Private Networks)

Para alterar a chave de autenticação a qualquer momento, edite o arquivo keys-ipsec0 nas duas
estações de trabalho. As duas chaves devem ser idênticas para que a conexão funcione apropriada-
mente.
O próximo exemplo mostra a configuração específica para a conexão da fase 1 à máquina remota.
O arquivo é nomeado como X.X.X.X.conf (X.X.X.X é substituído pelo endereço IP do roteador
IPsec remoto). Note que este arquivo é gerado automaticamente quando o túnel IPsec é ativado e não
deve ser editado diretamente.

;
remote X.X.X.X
{
exchange_mode aggressive, main;
my_identifier address;
proposal {
encryption_algorithm 3des;
hash_algorithm sha1;
authentication_method pre_shared_key;
dh_group 2 ;
}
}

O arquivo de configuração default da fase 1, criado quando uma conexão IPsec é iniciada, contém as
seguintes asserções usadas pela implementação IPsec do Red Hat Enterprise Linux:

remote X.X.X.X
Especifica que as asserções subsequentes deste arquivo de configuração aplicam-se somente ao
nódulo remoto identificado pelo endereço IP X.X.X.X.

exchange_mode aggressive
A configuração default do IPsec no Red Hat Enterprise Linux usa um método de autenticação
agressivo, que reduz a sobrecarga da conexão enquanto permite a configuração de diversas
conexões IPsec com máquinas múltiplas.

my_identifier address
Define o método de identificação a ser usado na autenticação dos nódulos. O Red Hat Enterprise
Linux usa endereços IP para identificar os nódulos.

encryption_algorithm 3des
Define a cifra de criptografia usada durante a autenticação. Por default, o Triple Data Encryption
Standard (3DES) é usado.

hash_algorithm sha1;
Especifica o algoritmo hash usado durante a negociação entre nódulos da fase 1. Por default,
usa-se o Secure Hash Algorithm versão 1.

authentication_method pre_shared_key
Define o método de autenticação usado durante a negociação dos nódulos. Por default, o Red Hat
Enterprise Linux usa chaves pré-compartilhadas para autenticação.

dh_group 2
Especifica o número do grupo Diffie-Hellman para estabelecer chaves de sessões geradas di-
namicamente. Por default, o grupo de 1024 bits é usado.
Capítulo 6. Redes Privadas Virtuais (Virtual Private Networks) 59

Os arquivos /etc/racoon/racoon.conf devem ser idênticos em todos os nódulos IPsec, exceto


pela asserção include "/etc/racoon/X.X.X.X.conf". Esta asserção (e o arquivo que referen-
cia) é gerada quando o túnel IPsec é ativado. Para a estação de trabalho A, X.X.X.X na asserção
include é o endereço IP da estação de trabalho B. O oposto vale para a estação de trabalho B. Veja
a seguir um arquivo racoon.conf típico quando a conexão IPsec é ativada.

# Racoon IKE daemon configuration file.


# See ’man racoon.conf’ for a description of the format and entries.

path include "/etc/racoon";


path pre_shared_key "/etc/racoon/psk.txt";
path certificate "/etc/racoon/certs";

sainfo anonymous
{
pfs_group 2;
lifetime time 1 hour ;
encryption_algorithm 3des, blowfish 448, rijndael ;
authentication_algorithm hmac_sha1, hmac_md5 ;
compression_algorithm deflate ;
}
include "/etc/racoon/X.X.X.X.conf"

Este arquivo racoon.conf default inclui localidades definidas para a configuração do IPsec, arquivos
de chaves pré-compartilhadas e certificados. Os campos sainfo anonymous descrevem a SA da
fase 2 entre os nódulos IPsec — a natureza da conexão IPsec (incluindo os algoritmos suportados de
criptografia usados) e o método de troca de chaves. A lista a seguir define os campos da fase 2:

sainfo anonymous
Denota que a SA pode iniciar anonimamente com qualquer par desde que as credenciais IPsec
coincidam.

pfs_group 2
Define o protocolo Diffie-Hellman de troca de chaves, o que determina o método através do qual
os nódulos do IPsec estabelecem uma chave de sessão temporária mútua para a segunda fase
da conectividade IPsec. Por default, a implementação IPsec do Red Hat Enterprise Linux usa o
grupo 2 (ou modp1024) dos grupos de troca de chave criptográfica Diffie-Hellman. O grupo 2 usa
uma exponenciação modular de 1024 bits, evitando que atacantes descriptografem transmissões
IPsec anteriores, mesmo que uma chave privada seja comprometida.

lifetime time 1 hour


Este parâmetro especifica o ciclo de vida de uma SA e pode ser quantificado por hora ou bytes
de dados. A implementação IPsec do Red Hat Enterprise Linux especifica o tempo de uma hora.

encryption_algorithm 3des, blowfish 448, rijndael


Especifica as cifras de criptografia suportadas para a fase 2. O Red Hat Enterprise Linux suporta
3DES, 448-bit Blowfish e Rijndael (a cifra usada no Advanced Encryption Standard ou AES).

authentication_algorithm hmac_sha1, hmac_md5


Lista os algoritmos hash suportados para autenticação. Os modos suportados são os códigos de
autenticação de mensagem sha1 e md5 hashed (HMAC).
60 Capítulo 6. Redes Privadas Virtuais (Virtual Private Networks)

compression_algorithm deflate
Define o algoritmo Deflate de compressão para suporte à IP Payload Compression (IPCOMP),
que permite a transmissão potencialmente mais rápida de datagramas IP através de conexões
lentas.
Para iniciar a conexão, reinicialize a estação de trabalho ou execute o seguinte comando, como root,
em cada máquina:

/sbin/ifup ipsec0

Para testar a conexão IPsec, execute o utilitário tcpdump para visualizar os pacotes de rede sendo
transferidos entre as máquinas (ou redes) e verificar se estão criptografadas via IPsec. O pacote deve
incluir um cabeçalho AH e deve ser exibido como pacotes ESP. ESP significa que está criptografado.
Por exemplo:

17:13:20.617872 pinky.example.com > ijin.example.com: \


AH(spi=0x0aaa749f,seq=0x335): ESP(spi=0x0ec0441e,seq=0x335) (DF)

6.5. Configuração Rede-a-Rede do IPsec


O IPsec também pode ser configurado para conectar uma rede inteira (como uma LAN ou WAN) a
uma rede remota através de uma conexão rede-a-rede. Este tipo de conexão requer a configuração
de roteadores IPsec em cada lado das redes conectadas para processar e rotear transparentemente
informações de um nódulo de uma LAN para outro nódulo de uma LAN remota. A Figura 6-1 mostra
uma conexão IPsec rede-a-rede passando por um túnel.

Figura 6-1. Uma conexão IPSec Rede-a-rede passando por um túnel

O diagrama mostra duas LANs separadas pela Internet. Estas LANs usam roteadores IPSEC para
autenticar e iniciar uma conexão, usando um túnel seguro através da Internet. Os pacotes intercep-
tados em trânsito requerem descriptografia muito forte para craquear a cifra protegendo os pacotes
entre estas LANs. O processo de comunicação entre um nódulo no intervalo IP 192.168.1.0/24 e
outro no 192.168.2.0/24 é completamente transparente aos nódulos, já que o processamento, crip-
tografia/descriptografia e roteamento dos pacotes IPSEC são executados inteiramente pelo roteador
IPSEC.
As informações necessárias para uma conexão rede-a-rede incluem:

• Os endereços IP externamente acessíveis dos roteadores IPsec dedicados


• Os intervalos de endereços de rede da LAN/WAN servida pelos roteadores IPsec, tal como
192.168.0.0/24 ou 10.0.1.0/24)
Capítulo 6. Redes Privadas Virtuais (Virtual Private Networks) 61

• Os endereços IP dos dispositivos da porta de comunicação (gateway) que roteia os dados dos nó-
dulos da rede para a Internet
• Um nome único para identificar a conexão IPsec e distinguí-la de outros dispositivos e conexões
(ex.: ipsec0)
• Uma chave fixa de criptografia ou uma gerada automaticamente pelo racoon
• Uma chave de autenticação pré-compartilhada, que inicia a conexão e troca chaves de criptografia
durante a sessão
Por exemplo: suponha que a LAN A (lana.example.com) e LAN B (lanb.example.com) queiram se in-
terconectar através de um túnel IPsec. O endereço de rede da LAN A está no intervalo 192.168.1.0/24,
enquanto a LAN B usa o intervalo 192.168.2.0/24. O endereço IP da porta de comunicação (gateway)
é 192.168.1.254 para a LAN A e 192.168.2.254 para a LAN B. Os roteadores IPsec estão separados
de cada porta de comunicação da LAN e usam dois dispositivos de rede: à eth0 é atribuído um en-
dereço IP estático acessível externamente, que acessa à Internet, enquanto eth1 atua como um ponto
de roteamento para processar e transmitir pacotes da LAN de um nódulo da rede a outros nódulos da
rede remota.
A conexão IPsec entre as redes usa uma chave pré-compartilhada com o valor r3dh4tl1nux, e os
administradores de A e B concordam em deixar que o racoon gere automaticamente e compartilhe
uma chave de autenticação entre cada um dos roteadores IPsec. O administrador da LAN A decide
nomear a conexão IPsec como ipsec0, enquanto o administrador da LAN B nomeia a conexão IPsec
como ipsec1.
Veja o conteúdo do arquivo ifcfg para uma conexão IPsec rede-a-rede da LAN A. O nome único
para identificar a conexão neste exemplo é ipsec1, portanto o arquivo resultante é nomeado como
/etc/sysconfig/network-scripts/ifcfg-ipsec1.

TYPE=IPSEC
ONBOOT=yes
IKE_METHOD=PSK
SRCGW=192.168.1.254
DSTGW=192.168.2.254
SRCNET=192.168.1.0/24
DSTNET=192.168.2.0/24
DST=X.X.X.X

A conexão é configurada para iniciar na inicialização da máquina (ONBOOT=yes) e usa o método


de autenticação de chave pré-compartilhada (IKE_METHOD=PSK). O administrador da LAN A
indica a porta de comunicação (gateway) de destino, que é a porta de comunicação da LAN B
(DSTGW=192.168.2.254) e também a porta de comunicação de origem, que é o endereço IP da
porta de comunicação da LAN A (SRCGW=192.168.1.254). O administrador então indica a rede de
destino, que é o intervalo de rede da LAN B (DSTNET=192.168.2.0/24) e também a rede de
origem (SRCNET=192.168.1.0/24). Finalmente, o administrador indica o endereço IP de destino,
que é o endereço IP externamente acessível da LAN B (X.X.X.X).
Veja o conteúdo do arquivo da chave pré-compartilhada, chamado
/etc/sysconfig/network-scripts/keys-ipsecX onde X (onde X é 0 para a LAN A e 1 para
a LAN B), que as duas redes usam para autenticarem-se entre si. O conteúdo destes arquivos deve ser
idêntico e somente o usuário root pode ser capaz de acessar ou gravar este arquivo.

IKE_PSK=r3dh4tl1nux

Importante
Para alterar o arquivo keys-ipsecX para que somente o usuário root possa acessá-lo ou editá-lo,
execute o seguinte comando após criar o arquivo:
62 Capítulo 6. Redes Privadas Virtuais (Virtual Private Networks)

chmod 600 /etc/sysconfig/network-scripts/keys-ipsec1

Para alterar a chave de autenticação a qualquer momento, edite o arquivo keys-ipsecX nos dois
roteadores IPsec. As duas chaves devem ser idênticas para que a conexão funcione apropriadamente.
Veja o conteúdo do arquivo de configuração /etc/racoon/racoon.conf da conexão IPsec. Note
que a linha include na parte inferior do arquivo é automaticamente gerada e aparece somente se o
túnel IPsec está rodando.

# Racoon IKE daemon configuration file.


# See ’man racoon.conf’ for a description of the format and entries.

path include "/etc/racoon";


path pre_shared_key "/etc/racoon/psk.txt";
path certificate "/etc/racoon/certs";

sainfo anonymous
{
pfs_group 2;
lifetime time 1 hour ;
encryption_algorithm 3des, blowfish 448, rijndael ;
authentication_algorithm hmac_sha1, hmac_md5 ;
compression_algorithm deflate ;
}
include "/etc/racoon/X.X.X.X.conf"

Veja a seguir o arquivo de configuração específico da conexão à rede remota. O arquivo é nomeado
como X.X.X.X.conf (substitua X.X.X.X pelo endereço IP do roteador IPsec remoto). Note que
este arquivo é gerado automaticamente quando o túnel IPsec é ativado e não deve ser editado direta-
mente.

;
remote X.X.X.X
{
exchange_mode aggressive, main;
my_identifier address;
proposal {
encryption_algorithm 3des;
hash_algorithm sha1;
authentication_method pre_shared_key;
dh_group 2 ;
}
}

Antes de iniciar a conexão IPsec, o encaminhamento de IP deve ser habilitado no kernel. Como root,
habilite o encaminhamento de IP numa janela de comandos:

1. Edite /etc/sysctl.conf e defina net.ipv4.ip_forward para 1.


2. Execute o seguinte comando para habilitar a alteração:
sysctl -p /etc/sysctl.conf
Para iniciar a conexão IPsec, reinicialize os roteadores IPsec ou execute o seguinte comando como
root em cada roteador:

/sbin/ifup ipsec0
Capítulo 6. Redes Privadas Virtuais (Virtual Private Networks) 63

As conexões são ativadas e as duas LANs, A e B, são capazes de comunicar entre si. As rotas são
criadas automaticamente através do script de início invocado pela execução do ifup na conexão
IPsec. Para visualizar uma lista de rotas da rede, execute o seguinte comando:

/sbin/ip route list

Para testar a conexão IPsec, execute o utilitário tcpdump no dispositivo externamente roteável (eth0
neste exemplo) para visualizar os pacotes de rede sendo transferidos entre as máquinas (ou redes) e
para verificar se estão criptografados com IPsec. Por exemplo: para verificar a conectividade da LAN
A, digite o seguinte:

tcpdump -n -i eth0 host lana.example.com

O pacote deve incluir um cabeçalho AH e deve ser exibido como um pacote ESP. ESP significa que
está criptografado. Por exemplo (barras invertidas denotam a continuação de uma linha):

12:24:26.155529 lanb.example.com > lana.example.com: AH(spi=0x021c9834,seq=0x358): \


lanb.example.com > lana.example.com: ESP(spi=0x00c887ad,seq=0x358) (DF) \
(ipip-proto-4)
64 Capítulo 6. Redes Privadas Virtuais (Virtual Private Networks)
Capítulo 7.
Firewalls
A segurança da informação é comumente encarada como um processo e não como um produto. Entre-
tanto, implementações de segurança padronizadas geralmente utilizam alguma forma de mecanismo
dedicado a controlar os privilégios de acesso e a restringir recursos de rede a usuários que são autor-
izados, identificáveis e rastreáveis. O Red Hat Enterprise Linux inclui muitas ferramentas poderosas
para auxiliar administradores e engenheiros de segurança em questões de controle de acesso em nível
de rede.
Juntamente às soluções VPN, como CIPE ou IPSec (abordados no Capítulo 6), os firewalls são um dos
componentes centrais da implementação de segurança na rede. Diversos fabricantes comercializam
soluções de firewall para suprir todos os nichos do mercado: de usuários domésticos protegendo um
PC até soluções de centro de dados para proteger informações corporativas vitais. Firewalls podem
ser soluções de hardware ligados intermitentemente, como as aplicações de firewall da Cisco, Nokia e
Sonicwall. Também há soluções de software de firewall proprietárias desenvolvidas para os mercados
doméstico e corporativo por fabricantes como Checkpoint, McAfee e Symantec.
Além das diferenças entre hardware e software de firewall, também há diferenças na maneira como
os firewalls funcionam, que separam uma solução da outra. A Tabela 7-1 detalha três tipos comuns de
firewalls e como eles funcionam:

Método Descrição Vantagens Desvantagens

NAT Tradução do Endereço da 0


Pode ser configurado 0
Não pode evitar atividades
Rede (Network Address transparentemente para maldosas uma vez que
Translation, NAT) insere
sub-redes IP internas por 0
máquinas em uma LAN
A proteção de muitas
usuários se conectam a um
serviço fora do firewall
trás de um ou um pequeno máquinas e serviços por
grupo de endereços IP trás de um ou mais
públicos, mascarando todos endereços IP externos
os pedidos para uma fonte simplifica tarefas de
ao invés de várias.
0administração
A restrição de acesso do
usuário de e para a LAN
pode ser configurada
abrindo e fechando portas
no firewall/gateway da NAT
66 Capítulo 7. Firewalls

Método Descrição Vantagens Desvantagens

Filtro Um firewall de filtragem de 1Personalizável através da 1


Não pode filtrar pacotes
de pacotes lê cada pacote de funcionalidade front-end para conteúdo similar a
Pacotes dados que passa por dentro
e por fora de uma LAN. 1
iptables
Não requer nenhuma 1
firewalls de proxy
Processa pacotes na
Pode ler e processar pacotes personalização no lado do camada do protocolo, mas
pela informação do cliente, já que todas as não pode filtrar pacotes
cabeçalho e filtrar o pacote
baseado em conjuntos de
atividades da rede são
filtradas no nível do 1numa camada de aplicação
Arquiteturas de rede
regras programáveis roteador ao invés do nível complexas podem fazer
implementadas pelo
administrador do firewall. O 1da aplicação
Já que os pacotes não são
com que o estabelecimento
de regras de filtragem de
kernel do Linux tem a transmitidos através de um pacotes se torne difícil,
funcionalidade embutida de proxy, o desempenho da especialmente se for usado
filtragem de pacotes através rede é mais rápido devido à com o mascaramento do IP
do sub-sistema Netfilter do conexão direta do cliente à ou sub-redes locais e redes

1 1
kernel. máquina remota DMZ
Proxy Firewalls de proxy filtram Dá aos administradores o Proxies são
todos os pedidos de um controle de quais frequentemente específicos
determinado protocolo ou aplicações e protocolos às aplicações (HTTP,
tipo dos clientes LAN para
uma máquina proxy, que 1
funcionam fora da LAN
Alguns servidores proxy
Telnet, etc.) ou restritos a
protocolos (a maioria dos
então faz estes pedidos à podem armazenar dados proxies funcionam com
Internet representando o frequentemente acessados serviços conectados por
cliente local. Uma máquina
proxy atua como um buffer
no cache localmente, ao
invés de ter que usar a 1
TCP, somente)
Serviços de aplicação não
entre usuários remotos conexão Internet para podem rodar por trás de
maldosos e as máquinas dos solicitá-los, o que é um proxy, portanto seus
clientes internos da rede. conveniente para reduzir o servidores de aplicações
consumo desnecessário de devem usar uma forma
1banda
Os serviços proxy podem
1
separada de segurança em
rede
ser registrados e Proxies podem se tornar
monitorados de perto, um gargalo na rede, já que
permitindo um controle todos os pedidos e
mais restrito sobre a transmissões passam através
utilização de recursos na de uma mesma fonte ao
rede invés de passar diretamente
do cliente para um serviço
remoto
Tabela 7-1. Tipos de Firewall

7.1. Netfilter e iptables


O kernel do Linux apresenta um sub-sistema de rede poderoso chamado Netfilter. O sub-sistema
Netfilter oferece filtragem de pacote de estado (que guarda o estado das conexões inciadas pelos
clientes) ou sem estado/’stateless’ (na qual cada pacote é analisado individualmente, sem levar em
conta pacotes anteriores trocados na mesma conexão), assim como NAT e serviços de mascaramento
de IP. O Netfilter também tem a habilidade de danificar as informações do cabeçalho para roteamento
avançado e gerenciamento do estado de conexão. O Netfilter é controlado através da funcionalidade
iptables.
Capítulo 7. Firewalls 67

7.1.1. Visão geral do iptables


O poder e flexibilidade do Netfilter é implementado através da interface do iptables. Esta fer-
ramenta de linha de comando é similar em sintaxe ao seu predecessor, o ipchains. No entanto,
iptables usa o sub-sistema do Netfilter para melhorar a conexão, inspeção e processamento de
rede; enquanto o ipchains usava conjuntos de regras complexas para filtrar localidades de fonte e
destino, assim como portas de conexão para ambos. O iptables inclui registro avançado, ações pré
e pós-roteamento, tradução do endereço de rede e encaminhamento de porta; tudo em apenas uma
interface de linha de comando.
Esta seção oferece uma visão geral do iptables. Para informações mais detalhadas sobre o
iptables, consulte o Guia de Referência do Red Hat Enterprise Linux.

7.2. Usando o iptables


O primeiro passo para usar o iptables é iniciá-lo. Isto pode ser feito com o comando:

service iptables start

Atenção
Os serviços ip6tables devem ser desligados para usar o serviço iptables com os seguintes co-
mandos:

service ip6tables stop


chkconfig ip6tables off

Para fazer com que o iptables inicie por default sempre que a máquina for inicializada, você deve
alterar o status do nível de execução (runlevel) do serviço usando chkconfig.

chkconfig --level 345 iptables on

A sintaxe do iptables é separada em camadas. A camada principal é a corrente (chain). Uma cor-
rente especifica o estado no qual um pacote é manipulado. O uso é o seguinte:

iptables -A chain -j target

O -A acrescenta uma regra no fim de um conjunto de regras existente. A corrente é o nome


da corrente para uma regra. As três correntes embutidas do iptables (ou seja, as correntes que
afetam todos os pacotes que trafegam pela rede) são INPUT, OUTPUT e FORWARD. Estas correntes
são permanentes e não podem ser apagadas. A opção -j target (alvo) especifica a localidade no
conjunto de regras do iptables onde essa regra específica deve pular. Alguns alvos embutidos são
ACCEPT, DROP e REJECT.
Correntes novas (também chamadas de correntes definidas pelo usuário) podem ser criadas usando a
opção -N. Criar uma corrente nova é útil para personalizar ou elaborar regras.

7.2.1. Normas Básicas de Firewall


Estabelecer normas básicas de firewall é a base para criar outras regras detalhadas definidas pelo
usuário. O iptables usa normas (-P) para criar regras default. Administradores com foco em se-
gurança geralmente escolhem derrubar todos os pacotes como uma norma e só permitem pacotes
68 Capítulo 7. Firewalls

específicos, analisando-os caso-a-caso. As seguintes regras bloqueiam todos os pacotes entrando e


saindo de uma porta de comunicação (gateway) de rede:

iptables -P INPUT DROP


iptables -P OUTPUT DROP

Adicionalmente, é recomendado que qualquer pacote encaminhado — tráfego de rede roteado do


firewall para seu nódulo de destino — seja negado também, para restringir os clientes internos da
exposição inadvertida à Internet. Para fazer isso, use a seguinte regra:

iptables -P FORWARD DROP

Após definir as normas de correntes, você pode criar novas regras para a sua rede e seus requisitos de
segurança em particular. As seguintes seções descrevem algumas regras que você talvez implemente
enquanto constrói seu firewall iptables.

7.2.2. Salvando e Restaurando Regras do iptables


As regras de firewall são válidas somente enquanto o computador estiver ligado. Portanto, se o sistema
for reinicializado, as regras serão automaticamente eliminadas e restauradas. Para salvar as regras de
modo que elas sejam carregadas posteriormente, use o seguinte comando:

/sbin/service iptables save

As regras são armazenadas no arquivo /etc/sysconfig/iptables e são aplicadas sempre que o


serviço é iniciado, reiniciado ou quando a máquina é reinicializada.

7.3. Filtragem Comum do iptables


Manter atacantes remotos fora de uma LAN é um aspecto importante da segurança de rede, senão
o mais importante. A integridade de uma LAN deve ser protegida de usuários remotos maldosos,
através do uso de regras rígidas de firewall. Entretanto, com uma norma default definida para bloquear
todos os pacotes entrando, saindo e encaminhados, é impossível que o firewall/porta de comunicação
(gateway) e usuários internos da LAN comuniquem-se entre si ou com recursos externos. Para permitir
a usuários executar funções relacionadas à rede e a usar aplicações de rede, os administradores devem
abrir certas portas para a comunicação.
Por exemplo: para permitir o acesso à porta 80 pelo firewall, adicione a seguinte regra:

iptables -A INPUT -p tcp -m tcp --sport 80 -j ACCEPT


iptables -A OUTPUT -p tcp -m tcp --dport 80 -j ACCEPT

Isto permite a navegação Web normal através de sites que comunicam através da porta 80. Para per-
mitir o acesso a sites seguros (como https://www.example.com/), você deve abrir a porta 443 também.

iptables -A INPUT -p tcp -m tcp --sport 443 -j ACCEPT


iptables -A OUTPUT -p tcp -m tcp --dport 443 -j ACCEPT

Importante
Ao criar um conjunto de regras do iptables, é crucial lembrar que a ordem é importante. Por ex-
emplo: se uma corrente especifica que todos os pacotes da sub-rede local 192.168.100.0/24 são
derrubados e uma outra corrente é adicionada (-A) para permitir pacotes do 192.168.100.13 (que
Capítulo 7. Firewalls 69

está dentro da sub-rede restrita derrubada), então a regra adicionada é ignorada. Você deve definir
uma regra para permitir 192.168.100.13 primeiro, e então definir uma regra para derrubar na sub-
rede.
Para inserir uma regra arbitrariamente num conjunto de regras existentes, use -I, seguido pela
corrente na qual deseja inserir a regra e o número da regra (1,2,3,...,n) onde você deseja que a
regra resida. Por exemplo:

iptables -I INPUT 1 -i lo -p all -j ACCEPT

A regra é inserida como a primeira no conjunto INPUT para permitir o tráfego do dispositivo loopback
local.

Algumas vezes você precisa de acesso remoto à LAN de fora dela. Serviços seguros, como SSH,
podem ser usados para conexão remota criptografada aos serviços da LAN. Para administradores com
recursos baseados em PPP (tais como bancos de modem ou contas ISP volumosas), o acesso discado
pode ser usado para circundar as barreiras do firewall seguramente, já que conexões via modem ficam
tipicamente por trás de um firewall/gateway por serem conexões diretas. Entretanto, casos especiais
podem ser elaborados para usuários remotos com conexões de banda larga. Você pode configurar o
iptables para aceitar conexões de clientes SSH remotos. Por exemplo: para permitir o acesso SSH
remoto, as seguintes regras podem ser usadas:

iptables -A INPUT -p tcp --dport 22 -j ACCEPT


iptables -A OUTPUT -p udp --sport 22 -j ACCEPT

Há outros serviços para os quais você talvez precise definir regras. Consulte o Guia de Referência do
Red Hat Enterprise Linux para informações detalhadas sobre o iptables e suas várias opções.
Estas regras permitem o acesso de entrada e saída para um único sistema, como um PC conectado
diretamente à Internet ou firewall/porta de comunicação (gateway). No entanto, não permitem que os
nódulos por trás do firewall/porta de comunicação acessem estes serviços. Para permitir o acesso LAN
a estes serviços, você pode usar o NAT com regras de filtragem do iptables.

7.4. Regras FORWARD e NAT


A maioria das empresas designam um número limitado de endereços IP publicamente roteáveis de
seus ISPs. Devido essa permissão limitada, os administradores devem encontrar maneiras criativas de
compartilhar o acesso aos serviços de Internet sem dar endereços IP limitados para cada nódulo da
LAN. Usar um endereço IP privado é a maneira comum de permitir que todos os nódulos de uma LAN
acessem apropriadamente serviços de rede internos e externos. Roteadores de borda (como firewalls)
podem receber transmissões de entrada da Internet e rotear os pacotes para o nódulo pretendido na
LAN. Ao mesmo tempo, o firewall/portas de comunicação (gateways) também podem rotear pedidos
de saída de um nódulo da LAN para o serviço remoto da Internet. Esse encaminhamento de tráfego de
rede pode se tornar perigoso às vezes, especialmente com a disponibilidade de ferramentas de cracking
modernas que podem espionar endereços IP internos e fazer com que a máquina remota do atacante
atue como um nódulo em sua LAN. Para evitar isso, o iptables oferece normas de roteamento e
encaminhamento que podem ser implementadas para evitar o uso indevido dos recursos de rede.
A norma FORWARD permite a um administrador controlar onde os pacotes podem ser roteados em
uma LAN. Por exemplo: para permitir o encaminhamento para a LAN inteira (assumindo que o fire-
wall/porta de comunicação tenha um endereço IP interno na eth 1), as seguintes regras podem ser
definidas:

iptables -A FORWARD -i eth1 -j ACCEPT


iptables -A FORWARD -o eth1 -j ACCEPT
70 Capítulo 7. Firewalls

Essa regra da acesso para a rede interna aos sistemas por trás do firewall/porta de comunicação. A
porta de comuncação roteia os pacotes de um nódulo da LAN para o seu nódulo pretendido, passando
todos os pacotes através de seu dispositivo eth1.

Nota
Por default, a norma IPV4 nos kernels do Red Hat Enterprise Linux desabilita o suporte para en-
caminhamento do IP, o que evita que caixas rodando o Red Hat Enterprise Linux funcionem como
roteadores de borda dedicados. Para habilitar o encaminhamento do IP, execute o seguinte co-
mando:

sysctl -w net.ipv4.ip_forward=1

Se este comando for submetido em uma janela shell, a configuração não é lembrada após uma reini-
cialização da máquina. Você pode definir o encaminhamento permanentemente, editando o arquivo
/etc/sysctl.conf. Encontre e edite a linha a seguir, substituindo 0 por 1:

net.ipv4.ip_forward = 0

Execute o seguinte comando para ativar a alteração do arquivo sysctl.conf:

sysctl -p /etc/sysctl.conf

Aceitar pacotes encaminhados através do dispositivo IP interno do firewall permite que os nódulos
da LAN comuniquem-se entre si; mas não permite que comuniquem-se externamente com a Internet.
Para permitir que nódulos da LAN com endereços IP privados comuniquem-se com redes públicas
externas, configure o firewall com o mascaramento do IP, que mascara pedidos de nódulos da LAN
com endereços IP do dispositivo externo do firewall (neste caso, eth0):

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

A regra usa a tabela de pacotes coincidentes da NAT (-t nat) e especifica a corrente POSTROUT-
ING embutida para a NAT (-A POSTROUTING) no dispositivo de rede externa do firewall (-o eth0).
O POSTROUTING (pós-roteamento) permite que os pacotes sejam alterados conforme deixam o dis-
positivo externo do firewall. O alvo -j MASQUERADE é especificado para mascarar o endereço IP
privado de um nódulo com o endereço IP externo do firewall/porta de comunicação.
Se você tem um servidor em sua rede interna que deseja disponibilizar externamente, pode usar o
alvo -j DNAT da corrente PREROUTING na NAT para especificar um endereço IP e porta de destino
para onde encaminhar os pacotes de entrada requisitando uma conexão. Por exemplo: se você deseja
encaminhar os pedidos HTTP de entrada para seu servidor Servidor HTTP Apache dedicado para
172.31.0.23, submeta o seguinte comando:

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT \


--to 172.31.0.23:80

Esta regra especifica que a tabela NAT usa a corrente PREROUTING embutida para encaminhar
pacotes HTTP de entrada exclusivamente para o endereço IP 172.31.0.23 listado.

Nota
Se você tem uma norma default DROP na sua corrente FORWARD, deve adicionar uma regra para
permitir o encaminhamento de pedidos HTTP de entrada para possibilitar o roteamento do destino
da NAT. Para fazer isso, submeta o seguinte comando:
Capítulo 7. Firewalls 71

iptables -A FORWARD -i eth0 -p tcp --dport 80 -d 172.31.0.23 -j ACCEPT

Esta regra permite o encaminhamento de pedidos de entrada HTTP do firewall para seu destino
pretendido no Servidor HTTP Apache por trás do firewall.

7.4.1. DMZs e iptables


As regras do iptables também podem definidas para rotear tráfego para determinadas máquinas,
como um servidor dedicado HTTP ou FTP, numa zona desmilitarizada (DMZ) — uma sub-rede local
especial dedicada a prover serviços num meio público como a Internet. Por exemplo: para definir uma
regra para rotear os pedidos HTTP externos para um servidor HTTP dedicado no endereço IP 10.0.4.2
(fora do intervalo 192.168.1.0/24 da LAN), a tradução de endereço de rede (NAT) evoca uma tabela
PREROUTING para encaminhar os pacotes ao destino apropriado:

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT \


--to-destination 10.0.4.2:80

Com este comando, todas as conexões HTTP para a porta 80 de fora da LAN são roteadas ao servidor
HTTP em uma rede separada do resto da rede interna. Esta forma de segmentação de rede pode ser
mais segura que permitir conexões HTTP para uma máquina na rede. Se o servidor HTTP estiver
configurado para aceitar conexões seguras, então a porta 443 deve ser encaminhada também.

7.5. Vírus e Endereços IP Espionados (spoofed)


Outras regras elaboradas podem ser criadas para controlar o acesso a sub-redes específicas, ou até a
nódulos específicos, dentro de uma LAN. Você também pode restringir que determinados serviços
dúbios, como trojans, vermes, e outros vírus de clientes/servidor, contatem seu servidor. Por exemplo:
há alguns trojans que scaneam redes para serviços nas portas de 31337 a 31340 (chamadas portas de
elite na terminologia dos crackers). Como não há serviços legítimos que comunicam através destas
portas fora do padrão, bloqueá-los pode diminuir efetivamente as chances de nódulos potencialmente
infectados em sua rede se comunicarem independentemente com seus servidores mestres remotos.

iptables -A OUTPUT -o eth0 -p tcp --dport 31337 --sport 31337 -j DROP


iptables -A FORWARD -o eth0 -p tcp --dport 31337 --sport 31337 -j DROP

Você também pode bloquear as conexões externas que tentam espionar intervalos de endereços IP
privados a fim de infiltrarem em sua LAN. Por exemplo: se uma LAN usa o intervalo 192.168.1.0/24,
uma regra pode determinar que o dispositivo de rede que faz a interface com a Internet (eth0, por
exemplo) derrube quaisquer pacotes parta este dispositivo com um endereço do intervalo de IP de sua
LAN. Como norma default, é recomendado rejeitar pacotes encaminhados, portanto qualquer outro
endereço IP espionado ao dispositivo que faz a interface externa (eth0) é rejeitado automaticamente.

iptables -A FORWARD -s 192.168.1.0/24 -i eth0 -j DROP

Nota
Há uma distinção entre DROP (derrubar) e REJECT (rejeitar) um alvo quando estamos lidando com
regras adicionais. REJECT um alvo nega acesso e retorna um erro connection refused (conexão
negada) para usuários que tentarem se conectar ao serviço. A ação DROP (derrubar) um alvo, como
o nome sugere, derruba os pacotes sem nenhum aviso. Administradores podem usar sua própria
prudência ao lidar com estes alvos; entretanto, para evitar a confusão do usuário e tentativas para
continuar conectando, a REJECT alvo é recomendada.
72 Capítulo 7. Firewalls

7.6. iptables e Registro de Conexão


O iptables inclui um módulo que permite aos administradores inspecionar e restringir conexões a
serviços disponíveis numa rede interna, usando um método chamado registro de conexão (connection
tracking). O registro de conexão armazena as conexões numa tabela, que permite aos administradores
permitir ou negar acesso baseado nos seguintes estados de conexão:

• NEW (nova) — Um pacote requisitando uma nova conexão, como um pedido HTTP.
• ESTABLISHED (estabelecida) — Um pacote que é parte de uma conexão existente.
• RELATED (relacionado) — Um pacote solicitando uma nova conexão, mas que é parte de uma
conexão existente, como conexões FTP passivas, nas quais a porta de conexão é 20, mas a porta de
transferência pode ser qualquer uma (de 1024 para cima) não usada.
• INVALID (inválido) — Um pacote que não faz parte de nenhuma das conexões da tabela de registro
das conexões.
Você pode usar a funcionalidade de estado do registro de conexões do iptables com qualquer proto-
colo de rede, mesmo que o próprio protocolo seja sem estado/’stateless’ (como o UDP). O exemplo a
seguir mostra uma regra que usa o registro de conexão para encaminhar somente os pacotes associados
a uma conexão estabelecida:

iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ALLOW

7.7. ip6tables
A introdução do Protocolo de Internet de última geração chamado IPv6, vai além do limite de en-
dereços de 32 bits do IPv4 (ou IP). IPv6 suporta endereços de 128 bits e, como tal, redes de transporte
cientes do IPv6 são capazes de lidar com um número maior de endereços roteáveis que o IPv4.
O Red Hat Enterprise Linux suporta regras de firewall IPv6 usando o sub-sistema Netfilter 6 e o
comando ip6tables. O primeiro passo para usar o ip6tables é iniciar o serviço ip6tables. Isto
pode ser feito com o comando:

service ip6tables start

Atenção
Os serviços iptables devem ser desligados para usar o serviço ip6tables exclusivamente:

service iptables stop


chkconfig iptables off

Para fazer com que o ip6tables inicie por default sempre que o sistema é inicializado, altere o
estado do nível de execução (runlevel) do serviço usando chkconfig.

chkconfig --level 345 ip6tables on


Capítulo 7. Firewalls 73

A sintaxe é idêntica à do iptables em todos os aspectos, exceto pelo fato do ip6tables suportar
endereços de 128 bits. Por exemplo: as conexões SSH em um servidor de rede ciente do IPv6 podem
ser possibilitadas pela seguinte regra:

ip6tables -A INPUT -i eth0 -p tcp -s 3ffe:ffff:100::1/128 --dport 22 -j ACCEPT

Para mais informações sobre redes com IPv6, consulte a página de informações sobre o IPv6:
http://www.ipv6.org/.

7.8. Recursos Adicionais


Há diversos aspectos do firewall e do sub-sistema Netfilter do Linux que não foram abordados neste
capítulo. Para mais informações, consulte os seguintes recursos.

7.8.1. Documentação Instalada

• O Guia de Referência do Red Hat Enterprise Linux inclui um capítulo detalhado sobre o iptables,
incluindo as definições de todas as opções de comandos.
• A página man do iptables também contém um breve resumo das várias opções.
• Uma lista dos serviços mais comuns e seus números de porta pode ser encontrada no Apêndice C e
no arquivo /etc/services.

7.8.2. Websites Úteis

• http://www.netfilter.org/ — O site oficial do Netfilter e do projeto iptables.


• http://www.tldp.org/ — O Projeto de Documentação do Linux contém diversos guias úteis rela-
cionados à criação e administração do firewall.
• http://www.iana.org/assignments/port-numbers — A lista oficial de portas de serviços comuns con-
forme definição da ’Internet Assigned Numbers Authority’.

7.8.3. Documentação Relacionada

• Red Hat Linux Firewalls, de Bill McCarty; Red Hat Press — uma referência detalhada para a
criação de firewalls de rede e servidores usando tecnologia de filtragem open source como Netfilter
e iptables. Inclui tópicos como a análise de registros de firewalls, criação de regras de firewall e
a personalização de seu firewall com ferramentas gráficas como lokkit.
• Linux Firewalls, de Robert Ziegler; New Riders Press. — contém muitas informações sobre a cri-
ação de firewalls usando o ipchains do kernel 2.2, assim como o Netfilter e iptables. Tópicos
adicionais de segurança, como questões de acesso remoto e sistemas de detecção de intrusão tam-
bém são abordados.
74 Capítulo 7. Firewalls
III. Avaliando Sua Segurança

Esta parte oferece uma visão geral da teoria e prática da avaliação de segurança. De monitores de rede
a ferramentas de cracking, um administrador pode aprender mais sobre a proteção de um sistema e de
uma rede, crackeando-os.

Índice
8. Avaliação de Vulnerabilidade....................................................................................................... 77
Capítulo 8.
Avaliação de Vulnerabilidade
Dados o tempo, os recursos e a motivação, um cracker pode violar praticamente qualquer sistema.
No final das contas, todos os procedimentos e tecnologias de segurança atualmente disponíveis não
podem garantir que seus sistemas estão seguros contra uma intrusão. Os roteadores ajudam a proteger
suas portas de comunicação (gateways) com a Internet. Firewalls ajudam a proteger a fronteira da
rede. Redes Privadas Virtuais (Virtual Private Networks - VPNs) podem transferir dados seguramente
através de informações criptografadas. Sistemas de detecção de intrusão podem alertá-lo sobre ativi-
dades maléficas. No entanto, o sucesso de cada uma destas tecnologias depende de diversas variáveis,
incluindo:

• O conhecimento dos funcionários responsáveis pela configuração, monitoramento e manutenção


das tecnologias
• A habilidade em consertar e atualizar eficiente e rapidamente os serviços e os kernels.
• A habilidade dos responsáveis em manter vigília constante sobre a rede.
Dado o dinamismo de sistemas e tecnologias de dados, proteger recursos corporativos pode ser bas-
tante complexo. Devido essa complexidade, geralmente é difícil encontrar peritos para todos os seus
sistemas. Enquanto é possível ter pessoal com conhecimento em muitas áreas de segurança da infor-
mação em um alto nível, é difícil reter funcionários que são peritos em mais do que algumas áreas.
Isto ocorre principalmente porque cada área da Segurança da Informação requer constante atenção e
foco. A segurança da informação não para.

8.1. Pensando Como o Inimigo


Suponha que você administre uma rede corporativa. Essas redes são comumente compostas de sis-
temas operacionais, aplicações, servidores, monitores de rede, firewalls, sistemas de detecção de in-
trusão e outros. Agora imagine tentar manter-se atualizado com cada um destes. Dada a complexidade
dos softwares e ambientes de rede atuais, exploits e erros são uma certeza. Manter-se informado so-
bre consertos e atualizações para uma rede inteira pode ser uma tarefa perturbadora em uma grande
empresa com sistemas heterogêneos.
Mesmo combinando os requerimentos de conhecimento com a tarefa de manter-se atualizado, é in-
evitável que incidentes adversos ocorram, sistemas sejam violados, dados corrompidos e serviços
sejam interrompidos.
Para aprimorar as tecnologias de segurança e auxiliar na proteção de sistemas, redes e dados, você deve
pensar como um cracker e medir a segurança de seus sistemas verificando suas fraquezas. Avaliações
preventivas de vulnerabilidades em seus próprios sistemas e recursos de rede podem revelar questões
potenciais a serem consideradas antes de um cracker explorá-las.
Uma avaliação de vulnerabilidade é uma auditoria interna da segurança de sua rede e sistemas, cu-
jos resultados indicam a confidencialidade, integridade e disponibilidade de sua rede (conforme ex-
planado na Seção 1.1.4). Uma avaliação de vulnerabilidade tipicamente começará com uma fase de
reconhecimento, durante a qual são coletados dados importantes referentes à rede e aos sistemas alvo.
Esta fase levará à fase de prontidão do sistema, onde o alvo é checado em todas as suas vulnera-
bilidades conhecidas. A fase de prontidão culmina na fase do relatório, na qual os resultados são
classificados em alto, médio e baixo risco, e métodos são discutidos para melhorar a segurança (ou
para minimizar o risco de vulnerabilidade) do alvo.
Se tivesse que executar uma avaliação de vulnerabilidade da sua casa, você provavelmente verificaria
cada uma das portas para certificar-se de que elas estão fechadas e trancadas. Você também checaria
todas as janelas, assegurando que estão completamente fechadas e corretamente travadas. O mesmo
78 Capítulo 8. Avaliação de Vulnerabilidade

conceito se aplica aos sistemas, redes e dados eletrônicos. Usuários maldosos são os ladrões e vân-
dalos de seus dados. Foque em suas ferramentas, mentalidade e motivações, e você poderá reagir
rapidamente às suas ações.

8.2. Definindo Avaliação e Testes


As avaliações de vulnerabilidade podem ser divididas em dois tipos: Olhando de fora para dentro e
olhando de dentro ao redor.
Ao executar uma avaliação de vulnerabilidade olhando de fora para dentro, você está tentando com-
prometer seus sistemas de fora. Estando fora de sua empresa lhe proporciona ter o ponto de vista de
um cracker. Você vê o que o cracker vê — endereços IP publicamente roteáveis, sistemas em sua
DMZ, interfaces externas de seu firewall e mais. DMZ significa "demilitarized zone" (zona desmilita-
rizada), que corresponde a um computador ou uma sub-rede pequena situada entre a rede interna, tal
como uma LAN privada corporativa, e uma rede externa não-confiável, como a Internet pública. Tipi-
camente, a DMZ contém dispositivos acessíveis ao tráfego da Internet, como servidores web (HTTP),
servidores FTP, servidores SMTP (e-mail) e servidores DNS.
Ao executar uma avaliação de vulnerabilidade de dentro olhando ao redor, você está, de certa maneira,
em vantagem já que você é interno e seu status é elevado a confiável. Esse é o ponto de vista que você
e seus colegas de trabalho têm ao se autenticarem em seus sistemas. Você vê servidores de impressão,
servidores de arquivos, bancos de dados e outros recursos.
Há diferenças notáveis entre estes dois tipos de avaliação de vulnerabilidade. Ser interno em sua
empresa lhe proporciona privilégios — mais elevados que qualquer externo. Ainda hoje em algumas
empresas, a segurança é configurada de modo a manter os intrusos fora. Muito pouco é feito para
proteger os internos da empresa (tais como firewalls departamentais, controles de acesso no nível de
usuário, procedimentos de autenticação para recursos internos e outros). Geralmente, há muito mais
recursos quando olhamos de dentro ao redor dado que a maioria dos sistemas são internos a uma
empresa. Uma vez que você se coloca fora da empresa, imediatamente terá o status não confiável. Os
sistemas e recursos disponíveis a você externamente são frequentemente muito limitados.
Considere a diferença entre as avaliações de vulnerabilidade e testes de penetração. Pense em uma
avaliação de vulnerabilidade como o primeiro passo de um teste de penetração. As informações obti-
das na avaliação serão utilizadas nos testes. Enquanto a avaliação verifica buracos e vulnerabilidades
potenciais, os testes de penetração tentam explorar os resultados.
Avaliar a infra-estrutura da rede é um processo dinâmico. A segurança de ambos, da informação e
física, é dinâmica. Executar uma avaliação traz uma visão geral, que pode incluir falsos positivos e
falsos negativos.
Administradores de segurança são tão bons quanto as ferramentas que usam e o conhecimento que
possuem. Pegue qualquer uma das ferramentas de avaliação disponíveis, execute-as em seu sistema, e
é quase certeza que haja pelo menos alguns falsos positivos. O resultado é o mesmo, seja por erro do
programa ou do usuário. A ferramenta pode encontrar vulnerabilidades que na realidade não existem
(falsos positivos) ou, pior ainda, ela pode não detectar vulnerabilidades que realmente existem (falsos
negativos).
Agora que a diferença entre avaliação de vulnerabilidade e teste de penetração está definida, é re-
comendável revisar os resultados da avaliação cuidadosamente antes de conduzir um teste de pene-
tração, como parte de sua nova tática para as melhores práticas.

Atenção
Tentar explorar vulnerabilidades dos recursos de produção pode resultar em efeitos adversos na
produtividade e eficiência de seus sistemas e rede.
Capítulo 8. Avaliação de Vulnerabilidade 79

A lista a seguir examina alguns dos benefícios em executar avaliações de vulnerabilidade.

• Cria foco pró-ativo na segurança da informação


• Encontra exploits potenciais antes que os crackers os encontrem
• Resulta em sistemas sendo mantidos atualizados e consertados
• Promove o crescimento e ajuda a desenvolver as habilidades dos funcionários
• Reduz perdas financeiras e publicidade negativa

8.2.1. Estabeleça uma Metodologia


Para auxiliar na selação de ferramentas para a avaliação de vulnerabilidade, é útil estabelecer uma
metodologia de avaliação de vulnerabilidade. Infelizmente, não há nenhuma metodologia pré-definida
ou aprovada pelo setor no momento, porém bom senso e as melhores práticas podem agir suficiente-
mente como guias.
Qual é o alvo? Nós estamos verificando um servidor, ou verificando nossa rede inteira e tudo que há
nesta rede? Somos internos ou externos à empresa? As respostas a estas questões são importantes,
pois ajudam a determinar não apenas quais ferramentas selecionar, mas também a maneira como são
utilizadas.
Para aprender mais sobre o estabelecimento de metodologias, consulte os seguintes websites:

• http://www.isecom.org/projects/osstmm.htm — The Open Source Security Testing Methodology


Manual (O Manual de Metodologia de Testes de Segurança Open Source) - OSSTMM
• http://www.owasp.org/ — The Open Web Application Security Project (O Projeto Livre de Segu-
rança de Aplicações Web)

8.3. Avaliando as Ferramentas


Uma avaliação pode começar com o uso de alguma forma de ferramenta de coleta de informações. Ao
avaliar a rede inteira, primeiramente mapeie o layout para encontrar máquinas que estejam rodando.
Após localizá-las, examine cada máquina separadamente. Focar nestas máquinas requer um outro
conjunto de ferramentas. Saber quais ferramentas utilizar deve ser o passo crucial para encontrar
vulnerabilidades.
Assim como em qualquer aspecto do cotidiano, há muitas ferramentas diferentes que desempenham
a mesma função. Este conceito também se aplica à execução das avaliações de vulnerabilidade. Há
ferramentas específicas para sistemas operacionais, para aplicações e até mesmo para redes (baseadas
nos protocolos utilizados). Algumas ferramentas são grátis e outras não. Algumas ferramentas são
intuitivas e fáceis de utilizar, enquanto outras são obscuras e mal documentadas, mas possuem fun-
cionalidades que outras não possuem.
Encontrar as ferramnentas corretas pode ser uma tarefa difícil, mas no final das contas, a experiênca
conta. Se possível, monte um laboratório de testes e experimente quantas ferramentas puder, anotando
os pontos fortes e fracos de cada uma. Reveja o arquivo README ou a página man da ferramenta.
Adicionalmente, procure na Internet por mais informações, como artigos, manuais passo-a-passo ou
até mesmo listas de discussão específicas da ferramenta.
As ferramentas explanadas abaixo são apenas uma pequena amostra das ferramentas disponíveis.
80 Capítulo 8. Avaliação de Vulnerabilidade

8.3.1. Scaneando Máquinas com Nmap


Nmap é uma ferramenta conhecida que pode ser usada no Red Hat Enterprise Linux para determi-
nar o layout de uma rede. O Nmap está disponível por muitos anos e provavelmente é a ferramenta
mais utilizada na coleta de informações. Há uma página man excelente, que oferece uma descrição
detalhada de suas opções e usos. Administradores podem usar o Nmap em uma rede para encontrar
sistemas hospedeiros e portas abertas nestes sistemas.
O Nmap é um primeiro passo eficaz na avaliação de vulnerabilidade. Você pode mapear todas as
máquinas dentro de uma rede, e inclusive passar uma opção que a permite ao Nmap tentar identificar
o sistema operacional rodando numa determinada máquina. O Nmap é uma boa base para estabelecer
normas de uso de serviços seguros e para parar serviços não usados.

8.3.1.1. Usando o Nmap


O Nmap pode ser executado a partir de uma janela de comandos, digitando nmap seguido do nome da
máquina ou endereço IP da máquina que você deseja scanear.

nmap foo.example.com

Os resultados do scan (que podem levar até alguns minutos, dependendo de onde a máquina está
localizada) devem se parecer com o seguinte:

Starting nmap V. 3.50 ( www.insecure.org/nmap/ )


Interesting ports on localhost.localdomain (127.0.0.1):
(The 1591 ports scanned but not shown below are in state: closed)
Port State Service
22/tcp open ssh
25/tcp open smtp
111/tcp open sunrpc
443/tcp open https
515/tcp open printer
950/tcp open oftep-rpc
6000/tcp open X11

Nmap run completed -- 1 IP address (1 host up) scanned in 71.825 seconds

O Nmap testa as portas de comunicação mais comuns numa rede para escutar ou esperar serviços.
Esse conhecimento pode ser útil a um administrador que deseja encerrar serviços desnecessários ou
não-usados.
Para mais informações sobre o uso do Nmap, consulte o site oficial no endereço:
http://www.insecure.org/

8.3.2. Nessus
O Nessus é um scanner de segurança ’full-service’. A arquitetura plug-in do Nessus permite que
usuários personalizem-no para seus sistemas e redes. Assim como qualquer scanner, o Nessus é tão
bom quanto o banco de dados de assinatura no qual ele se baseia. Felizmente, o Nessus é frequente-
mente atualizado. Suas funcionalidades incluem relatório completo, scanning da máquina e buscas de
vulnerabilidades em tempo real. Lembre-se que pode haver falsos positivos e falsos negativos, mesmo
numa ferramenta tão poderosa e atualizada como o Nessus.
Capítulo 8. Avaliação de Vulnerabilidade 81

Nota
O Nessus não está incluso no Red Hat Enterprise Linux e não é suportado. Foi incluso neste doc-
umento como uma referência para usuários que possam se interessar por esta aplicação tão con-
hecida.

Para mais informações sobre o Nessus, consulte o site oficial no endereço:


http://www.nessus.org/

8.3.3. Nikto
O Nikto é um scanner de script CGI excelente. Nikto não tem apenas a capacidade de verificar vul-
nerabilidades CGI, mas também de fazê-lo de maneira evasiva, para enganar sistemas de detecção de
intrusão. Acompanha uma documentação excelente que dever ser revisada cuidadosamente antes de
executar o programa. Se você tem servidores Web servindo scripts CGI, o Nikto pode ser um excelente
recurso para checar a segurança destes servidores.

Nota
O Nikto não está incluso no Red Hat Enterprise Linux e não é suportado. Foi incluso neste docu-
mento como uma referência para usuários que possam se interessar por esta aplicação.

Mais informações sobre o Nikto podem ser encontradas na seguinte URL:


http://www.cirt.net/code/nikto.shtml

8.3.4. VLAD the Scanner


O VLAD é um scanner de vulnerabilidades desenvolvido pela equipe RAZOR da Bindview, Inc., que
verifica a lista das dez questões mais comuns de segurança da SANS (questões do SNMP, questões de
compartilhamento de arquivo, etc). Apesar de não ter tantas funcionalidades quanto o Nessus, vale a
pena investigar o VLAD.

Nota
O VLAD não está incluso no Red Hat Enterprise Linux e não é suportado. Foi incluso neste docu-
mento como uma referência para usuários que possam se interessar por esta aplicação.

Mais informações sobre o VLAD podem ser encontradas no site da equipe RAZOR na seguinte URL:
http://www.bindview.com/Support/Razor/Utilities/
82 Capítulo 8. Avaliação de Vulnerabilidade

8.3.5. Antecipando Suas Necessidades Futuras


Dependendo do seu alvo e recursos, há muitas ferramentas disponíveis. Há ferramentas para redes
sem fio, redes Novell, sistemas Windows, sistemas Linux e outros. Outra parte essencial ao executar
avaliações deve incluir a revisão da segurança física, cobertura de pessoal ou avaliação da rede de
voz/PABX. Conceitos novos como o war walking — scanning do perímetro das estruturas físicas de
sua empresa para encontrar vulnerabilidades da rede sem fio — são conceitos emergentes que você
pode investigar e, se necessário, incorporá-los às suas avaliações. Imaginação e exposição são os
únicos limites para planejar e conduzir avaliações de vulnerabilidade.
IV. Intrusões e Resposta a Incidentes

É inevitável uma rede sofrer intrusões ou o uso maléfico de seus recursos. Esta parte aborda algumas
medidas pró-ativas que um administrador pode tomar para evitar quebras na segurança, tais como
formar uma equipe de resposta a emergências, capaz de responder rápida e efetivamente a questões
de segurança. Além disso, esta parte também detalha os passos a tomar para agupar e analisar as
evidências de uma quebra na segurança após o fato ter ocorrido.

Índice
9. Detecção de Invasão ...................................................................................................................... 85
10. Resposta ao Incidente ................................................................................................................. 91
Capítulo 9.
Detecção de Invasão
Uma propriedade de valor necessita de proteção contra ações de roubo e destruição. Algumas casas
são equipadas com sistemas de alarme capazes de deter ladrões, notificar as autoridades na ocasião de
uma invasão e inclusive alertar o proprietário quando sua casa estiver sendo incendiada. Tais medidas
são necessárias para assegurar a integridade das casas e a segurança de seus proprietários.
A mesma garantia de integridade e segurança também deve ser aplicada a sistemas de dados e com-
putadores. A Internet facilitou o fluxo de informações, tanto pessoais como financeiras. Ao mesmo
tempo, também deu margem a muitos perigos. Usuários maléficos e crackers procuram alvos vul-
neráveis como sistemas não seguros, sistemas infectados com vírus trojans e redes rodando serviços
não seguros. São necessários alarmes para notificar os administradores e membros da equipe de segu-
rança que uma intrusão ocorreu para que eles possam agir em tempo real contra tal intrusão. Sistemas
de detecção de intrusão foram elaborados para agir como este sistema de alerta.

9.1. Definindo Sistemas de Detecção de Intrusão


Um sistema de detecção de intrusão (intrusion detection system, IDS) é um processo ou dispositivo
ativo que analisa as atividades do sistema e da rede e identifica entradas não autorizadas e/ou ativi-
dades maléficas. A maneira como um IDS detecta anomalias pode variar amplamente; no entanto, o
objetivo final de qualquer IDS é capturar os infratores na ação antes de realmente danificarem seus
recursos.
Um IDS protege um sistema de ataques, mal-uso e danos. Também pode monitorar as atividades da
rede, auditorar as configurações da rede e do sistema para detectar vulnerabilidades, analisar inte-
gridade de dados e muito mais. Dependendo dos métodos de detecção que você escolher aplicar, há
diversos benefícios diretos e casuais em utilizar um IDS.

9.1.1. Tipos de IDSs


Entender o que é um IDS e as funcionalidades que oferece é essencial para determinar qual será o tipo
apropriado para incluir em suas normas de segurança em informática. Esta seção aborda os conceitos
por trás dos IDSs, as funcionalidades de cada tipo de IDS e a emergência de IDSs híbridos que aplicam
diversas técnicas de detecção e ferramentas em um pacote.
Alguns IDSs são baseados no conhecimento, que alertam prioritariamente os administradores de se-
gurança antes de uma intrusão ocorrer utilizando um banco de dados de ataques comuns. Alterna-
tivamente, há alguns IDSs comportamentais que rastreiam todos os usos de recursos para encontrar
anomalias, que normalmente são sinais positivos de atividades maldosas. Alguns IDSs são serviços
isolados (standalone) que trabalham por trás do cenário e monitoram passivamente as atividades,
registrando quaisquer pacotes suspeitos vindos de fora. Outros IDSs combinam ferramentas padrão
de sistema, configurações alteradas e registro de palavras, juntamente à intuição do administrador e
sua experiência em criar um kit de detecção de intrusão poderoso. Avaliar as diferentes técnicas de
detecção pode ajudar a encontrar uma que seja correta para sua organização.
Os tipos mais comuns de IDSs mencionados no campo da segurança são conhecidos como IDSs
baseados na máquina e baseados na rede. Um IDS baseado na máquina é o mais detalhado dos
dois, envolvendo a implementação de um sistema de detecção em cada máquina separadamente. In-
dependente do ambiente de rede no qual a máquina reside, ela está protegida. Um IDS baseado na
rede afunila pacotes através de um único dispositivo antes de enviá-los a máquinas específicas. IDSs
baseados na rede são frequentemente encarados como menos detalhados, já que muitas máquinas num
ambiente móvel impossibilitam uma filtragem e proteção confiável dos pacotes na rede.
86 Capítulo 9. Detecção de Invasão

9.2. IDS baseado no servidor


Um IDS baseado na máquina analisa diversas áreas para determinar o mal-uso (atividades maléficas
ou truculentas dentro da rede) ou intrusão (incursões de fora). IDSs baseados na máquina consultam
diversos tipos de arquivos de registro (kernel, sistema, servidor, rede, firewall e outros) e comparam
os registros a um banco de dados interno com assinaturas comuns de ataques conhecidos. IDSs UNIX
e Linux baseados na máquina fazem uso constante do syslog e sua habilidade em separar eventos
registrados por sua severidade (por exemplo: pequenas mensagens de impressão versus sérios alertas
do kernel). O comando syslog é disponibilizado ao instalar o pacote sysklogd, inclulso no Red Hat
Enterprise Linux. Este pacote oferece registros do sistema e isolamento das mensagens do kernel. O
IDS baseado na máquina filtra os registros (que, no caso de alguns eventos da rede e do kernel, podem
ser bastante verbalizados), analisa-os, renomeia as mensagens anômalas com sua própria classificação
de severidade e os agrupa em seu próprio registro especializado para análise do adminstrador.
Um IDS baseado na máquina também pode verificar a integridade dos dados de arquivos importantes
e executáveis. Checa um banco de dados de arquivos importantes (e quaisquer arquivos adicionados
pelo administrador) e cria um checksum de cada arquivo com um utilitário de digestão do arquivo de
mensagem como o md5sum (algoritmo de 128 bits) ou o sha1sum (algoritmo de 160 bits). Então, o
IDS baseado na máquina armazena as consistências em um arquivo somente texto e compara peri-
odicamente a verificação de consistência aos valores do arquivo texto. Se alguma das consistências
não bater, o IDS alerta o administrador via e-mail ou pager do celular. Este é o procedimento utilizado
pelo Tripwire, explanado na Seção 9.2.1.

9.2.1. Tripwire
O Tripwire é o IDS do Linux baseado na máquina mais conhecido. A Tripwire, Inc., empresa dos
desenvolvedores do Tripwire, recentemente divulgou o código-fonte do software para a versão Linux
e o licenciou sob os termos da GNU General Public License. O Tripwire está disponível no site
http://www.tripwire.org/.

Nota
O Tripwire não está incluso no Red Hat Enterprise Linux e não é suportado. Foi incluso neste doc-
umento como uma referência para usuários que possam se interessar pelo uso desta aplicação
conhecida.

9.2.2. RPM como um IDS


O Gestor de Pacotes RPM (RPM) é outro programa que pode ser utilizado como um IDS baseado
no servidor. O RPM contém várias opções para investigar pacotes e seus conteúdos. Estas opções de
verificação podem ser muito preciosas para um administrador ao suspeitar que arquivos críticos do
sistema e executáveis foram modificados.
A lista seguinte traz algumas opções para RPMs que podem verificar a integridade de arquivos num
sistema Red Hat Enterprise Linux. Consulte o Guia de Administração de Sistemas Red Hat Enterprise
Linux para informações completas sobre o uso do RPM.

Importante
Alguns dos comandos da lista seguinte requerem a importação da chave pública GPG da Red Hat
para o chaveiro RPM do sistema. Esta chave verifica se os pacotes instalados em seu sistema
contêm uma assinatura de pacote da Red Hat, o que assegura que seus pacotes foram originados
Capítulo 9. Detecção de Invasão 87

2 3
da Red Hat. A chave pode ser importada atribuindo o seguinte comando como root (substituindo
version pela versão do RPM instalado no sistema):

rpm --import /usr/share/doc/rpm- 4 version 5 /RPM-GPG-KEY

rpm -V nome_do_pacote
A opção -V verifica os arquivos do pacote instalado chamado nome_do_pacote. Se não exibir
nenhum output e fechar, isto significa que nenhum dos arquivos foi modificado de maneira al-
guma desde a última vez em que o banco de dados RPM foi atualizado. Se houver algum erro,
como
S.5....T c /bin/ps
então o arquivo foi modificado de alguma maneira e você deve decidir entre guardar o arquivo
(como é o caso de arquivos de configuração modificados no diretório /etc/) ou apagar o ar-
quivo e reinstalar o pacote que o contém. A lista a seguir define os elementos do conjunto de 8
caracteres (S.5....T no exemplo acima) que notifica uma falha de verificação.
• . — O teste passou esta fase da verificação
• ? — O teste encontrou um arquivo que não pôde ser lido, o que provavelmente é uma questão
de permissão do arquivo
• S — O teste encontrou um arquivo menor ou maior do que era ao ser originalmente instalado
no sistema
• 5 — O teste encontrou um arquivo cuja verificação de consistência (checksum) md5 não co-
incide com a consistência original do arquivo instalado pela primeira vez
• M — O teste detectou um erro na permissão ou no tipo do arquivo
• D — O teste encontrou um conflito em número maior/menor no arquivo de dispositivo
• L — O teste encontrou um link simbólico que foi alterado para outra localização de arquivo
• U — O teste encontrou um arquivo que teve sua propriedade de usuário alterada
• G — O teste encontrou um arquivo que teve sua propriedade de grupo alterada
• T — O teste encontrou erros de verificação mtime no arquivo

rpm -Va
A opção -Va verifica todos os pacotes instalados e procura qualquer falha em seus testes de ver-
ificação (parecida com a opção -V, só que seu output é mais verbalizado já que está verificando
cada pacote instalado).

rpm -Vf /bin/ls


A opção -Vf verifica arquivos individualmente em um pacote instalado. Ela pode ser útil ao
desempenhar uma verificação rápida em um arquivo suspeito.

rpm -K aplicação-1.0.i386.rpm
A opção -K é útil para checar a consistência (md5 checksum) e a assinatura GPG de um arquivo
de pacote RPM. Pode ser utilizada para verificar se um pacote prestes a ser instalado é assinado
pela Red Hat ou por qualquer organização para a qual você tenha a chave pública GPG importada
para um chaveiro GPG. Um pacote que não tenha sido assinado apropriadamente emitirá uma
mensagem de erro similar à seguinte:
application-1.0.i386.rpm (SHA1) DSA sha1 md5 (GPG) NOT OK
(MISSING KEYS: GPG#897da07a)
88 Capítulo 9. Detecção de Invasão

Tenha cuidado ao instalar pacotes não assinados já que não são aprovados pela Red Hat, Inc. e
podem conter código maléfico.
O RPM pode ser uma ferramenta poderosa, como evidenciado por suas diversas ferramentas de veri-
ficação de pacotes instalados e arquivos de pacotes RPM. É altamente recomendado que você faça
backup dos conteúdos do diretório do banco de dados RPM (/var/lib/rpm/) para uma mídia
somente-leitura (como um CD-ROM) após instalar o Red Hat Enterprise Linux. Ao fazê-lo, é pos-
sível verificar arquivos e pacotes com o banco de dados somente-leitura, ao invés do banco de dados
do sistema, já que usuários mal intencionados podem corromper o banco de dados e desviar seus
resultados.

9.2.3. IDSs baseados em outros servidores


A lista a seguir aborda alguns dos outros sistemas de detecção de intrusão baseados na máquina.
Consulte os sites dos respectivos utilitários para mais informações sobre sua instalação e configuração.

Nota
Estas aplicações não estão inclusas no Red Hat Enterprise Linux e não são suportadas. Elas foram
inclusas neste documento como referência para usuários interessados em avaliá-las.

• SWATCH http://www.stanford.edu/~atkins/swatch/ — O WATCHer Simples (SWATCH) utiliza ar-


quivos de registro gerados pelo syslog para alertar administradores sobre anomalias baseado em
arquivos de configuração do usuário. SWATCH foi desenvolvido para registrar qualquer evento que
o usuário queira adicionar ao arquivo de configuração; no entanto, tem sido amplamente adotado
como um IDS baseado na máquina.
• LIDS http://www.lids.org — O Sistema de Detecção de Intrusão Linux (Linux Intrusion Detection
System), LIDS, é um conserto do kernel e uma ferramenta de administração também capaz de
controlar modificações de arquivo com listas de controle de acesso (access control lists - ACLs), e
proteger processos e arquivos, inclusive do usuário root.

9.3. IDS baseado em rede


Sistemas de detecção de intrusão baseados em rede operam de maneira diferente dos IDSs baseados
na máquina. A filosofia de desenvolvimento de um IDS baseado em rede é scanear os pacotes da
rede no nível da máquina ou roteador, auditorando informações de pacotes e registrando quaisquer
pacotes suspeitos em um arquivo de registro especial com informações extras. Baseado nestes pacotes
suspeitos, um IDS baseado em rede pode scanear seu próprio banco de dados de assinaturas de ataques
de rede conhecidos e determinar um nível de severidade para cada pacote. Se os níveis de severidade
forem suficientemente altos, um email de alerta ou mensagem de celular será enviada aos membros
da equipe de segurança para que eles possam investigar a natureza da anomalia.
IDSs baseados em rede tornaram-se populares com o crescimento da Internet em tamanho e tráfego.
IDSs que podem scanear a volumosa quantidade de atividade de rede e nomear com êxito as trans-
missões suspeitas são bem recebidos na indústria da segurança. Devido à insegurança inerente de
protocolos TCP/IP, tornou-se obrigatório o desenvolvimento de scanners, sniffers e outras ferramen-
tas de auditoria e detecção de rede para prevenir brechas de segurança devido às atividades maldosas
na rede como:
Capítulo 9. Detecção de Invasão 89

• Spoofing do IP (alteração do endereço IP para parecer como outra máquina)


• ataques denial-of-service
• poisoning do cache arp (danificação do protocolo)
• Corrupção do domínio DNS
• ataques man-in-the-middle
A maioria dos IDSs baseados em rede requerem que o dispositivo de rede do servidor do sistema
seja configurado para o modo promíscuo, que permite o dispositivo a capturar todos os pacotes que
passam na rede. O modo promíscuo pode ser configurado através do comando ifconfig, conforme
o seguinte:

ifconfig eth0 promisc

Executando ifconfig sem opções revela que eth0 agora está no modo promíscuo (PROMISC).

eth0 Link encap:Ethernet HWaddr 00:00:D0:0D:00:01


inet addr:192.168.1.50 Bcast:192.168.1.255 Mask:255.255.252.0
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
RX packets:6222015 errors:0 dropped:0 overruns:138 frame:0
TX packets:5370458 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:2505498554 (2389.4 Mb) TX bytes:1521375170 (1450.8 Mb)
Interrupt:9 Base address:0xec80

lo Link encap:Local Loopback


inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:21621 errors:0 dropped:0 overruns:0 frame:0
TX packets:21621 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1070918 (1.0 Mb) TX bytes:1070918 (1.0 Mb)

Ao utilizar uma ferramenta como o tcpdump (incluso no Red Hat Enterprise Linux), é possível visu-
alizar o tráfego intenso fluindo por uma rede:

tcpdump: listening on eth0


02:05:53.702142 pinky.example.com.ha-cluster > \
heavenly.example.com.860: udp 92 (DF)
02:05:53.702294 heavenly.example.com.860 > \
pinky.example.com.ha-cluster: udp 32 (DF)
02:05:53.702360 pinky.example.com.55828 > dns1.example.com.domain: \
PTR? 192.35.168.192.in-addr.arpa. (45) (DF)
02:05:53.702706 ns1.example.com.domain > pinky.example.com.55828: \
6077 NXDomain* 0/1/0 (103) (DF)
02:05:53.886395 shadowman.example.com.netbios-ns > \
172.16.59.255.netbios-ns: NBT UDP PACKET(137): QUERY; BROADCAST
02:05:54.103355 802.1d config c000.00:05:74:8c:a1:2b.8043 root \
0001.00:d0:01:23:a5:2b pathcost 3004 age 1 max 20 hello 2 fdelay 15
02:05:54.636436 konsole.example.com.netbios-ns > 172.16.59.255.netbios-ns:\
NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
02:05:56.323715 pinky.example.com.1013 > heavenly.example.com.860:\
udp 56 (DF)
02:05:56.323882 heavenly.example.com.860 > pinky.example.com.1013:\
udp 28 (DF)

Note que pacotes não intencionados para a nossa máquina (pinky.example.com) ainda estão sendo
scaneados e registrados pelo tcpdump.
90 Capítulo 9. Detecção de Invasão

9.3.1. Snort
Apesar do tcpdump ser uma ferramenta de auditoria importante, não é considerado um IDS ver-
dadeiro porque não analisa e aponta anomalias nos pacotes. Ao invés disso, o tcpdump exibe todas as
informações dos pacotes na tela de output ou num arquivo de registro sem análise nenhuma. Um IDS
apropriado analisa os pacotes, aponta transmissões de pacotes potencialmente maléficas e as armazena
num registro formatado.
O Snort é um IDS desenvolvido para ser detalhado e correto ao registrar com êxito as atividades
maléficas da rede e notificar os administradores quando potenciais brechas ocorrerem. Snort utiliza a
biblioteca padrão libcap e o tcpdump como um registro especializado de pacotes.
A característica mais premiada do Snort, somada à sua funcionalidade, é o seu sub-sistema flexível
de assinaturas de ataque. Snort tem um banco de dados de ataques constantemente atualizado
que pode ser adicionado à ou atualizado via Internet. Os usuários podem criar assinaturas
baseadas em novos ataques de rede e enviá-las às listas de discussão de assinaturas do Snort
(http://www.snort.org/lists.html), para beneficiar todos os usuários do Snort. Essa ética comunitária
em compartilhar elevou o Snort a um dos IDSs mais atualizados e robustos disponíveis no mercado.

Nota
O Snort não está incluso no Red Hat Enterprise Linux e não é suportado. Ele foi incluso neste
documento como referência para usuários interessados em avaliá-lo.

Para mais informações sobre o uso do Snort, consulte o site oficial: http://www.snort.org.
Capítulo 10.
Resposta ao Incidente
No caso da segurança de um sistema ter sido comprometida, uma resposta ao incidente se faz
necessária. É responsabilidade da equipe de segurança responder ao problema rápida e efetivamente.

10.1. Definindo Resposta ao Incidente


A resposta ao incidente é uma reação expedida a uma questão ou ocorrência de segurança. Pertinente
à segurança da informação, um exemplo seria as ações da equipe de segurança contra um hacker que
penetrou um firewall e está bisbilhotando o tráfego da rede interna. O incidente é uma infração da
segurança. A resposta depende de como a equipe de segurança reage, o que ela faz para mininmizar
os danos e quando recupera os recursos; tudo isso enquanto tenta garantir a integridade dos dados.
Pense na sua empresa e em como quase todos os aspectos dela dependem de tecnologia e sistemas
de computador. Se houver um comprometimento, imagine os resultados potencialmente devastadores.
Além do tempo em que o sistema ficará fora do ar e o roubo de dados, pode haver corrupção de dados,
roubo de identidade (a partir de registros pessoais online), má publicidade, ou até mesmo resultados
financeiros devastadores enquanto clientes e empresas aprendem a reagir negativamente na ocorrência
de comprometimento.
Pesquisas sobre as infrações anteriores na segurança (tanto internas quanto externas) mostram que
algumas empresas podem até ser fechadas como resultado de uma grave infração de segurança. Uma
infração pode tornar recursos indisponíveis e roubar ou corromper dados. Mas é muito difícil estimar
financeiramente os danos como má publicidade. Para ter uma idéia exata do quão importante é uma
resposta eficiente a um incidente, uma empresa deve calcular o custo de uma infração e também os
efeitos financeiros da publicidade negativa, a curto e longo prazo.

10.2. Criando um Plano de Resposta ao Incidente


É importante que um plano de resposta ao incidente seja formulado, apoiado através da empresa e
regularmente testado. Um bom plano de resposta ao incidente pode minimizar não somente os efeitos
de uma infração na segurança, mas também reduzir a publicidade negativa.
Sob a perspectiva de uma equipe de segurança, não importa se a infração ocorre (como parte das
eventuais transações usando um meio de rede não confiável, como a Internet), mas sim, quando uma
infração ocorre. Não pense em um sistema como fraco e vulnerável; é importante perceber que quando
há tempo e recursos suficientes alguém violará até mesmo o sistema ou rede mais super-protegido.
Não é necessário consultar nada além do site Security Focus, http://www.securityfocus.com, para obter
informações detalhadas e atualizadas sobre as recentes infrações e vulnerabilidades de segurança,
como a destruição frequente de páginas web corporativas até os ataques aos servidores DNS root em
20021.
O aspecto positivo de perceber a inevitabilidade de uma infração do sistema é que ela permite à equipe
de segurança desenvolver um curso das ações que minimizem qualquer dano potencial. Combinar o
curso das ações com habilidades permite à equipe responder a condições adversas de uma maneira
formal e responsável.
O plano de resposta ao incidente pode ser dividido em quatro fases:

• Ação imediata para interromper ou minimizar o incidente

1. http://www.gcn.com/21_32/web/20404-1.html
92 Capítulo 10. Resposta ao Incidente

• Investigação do Incidente
• Restauração dos recursos afetados
• Reportando o indicente aos canais apropriados
Uma resposta a um incidente deve ser decisiva e executada rapidamente. Como há pouco espaço para
erros, é essencial que as práticas de emergência sejam ensaiadas e os tempos de resposta medidos.
Desta maneira, é possível desenvolver uma metodologia que estimule a velocidade e a acuracidade,
minimizando o impacto da indisponibilidade de recursos e os potenciais danos causados pelo com-
prometimento do sistema.
Um plano de resposta ao incidente tem diversos requisitos, inclusive:

• Um time de peritos internos (uma Equipe de Resposta às Emergências de Computador)


• Um estratégia aprovada e juridicamente revista
• Suporte financeiro da empresa
• Suporte executivo/alta gerência
• Um plano de ação factível e testado
• Recursos físicos, como armazenamento redundante, sistemas de standby e serviços de backup

10.2.1. A Equipe de Resposta a Emergências de Computador (The Computer


Emergency Response Team - CERT)
O termo Equipe de Resposta às Emergências de Computador (Computer Emergency Response Team
- CERT) refere-se a um grupo de peritos internos preparados para agir rapidamente no caso de uma
situação catastrófica com computadores. Encontrar as competências cruciais para uma CERT pode ser
um desafio. O conceito de pessoal apropriado vai além das habilidades técnicas e inclui questões de
logística, como localização, disponibilidade e desejo de colocar a empresa à frente da vida pessoal
quando uma emergência ocorre. Uma emergência nunca é um evento planejado; pode acontecer a
qualquer momento e todos os membros da CERT devem aceitar a responsabilidade de responder a
uma emergência a qualquer hora.
As equipes típicas de uma CERT incluem adminsitradores de sistemas e de rede, assim como peritos
em segurança da informação. Os administradores de sistema provêm o conhecimento e habilidades
dos recursos do sistema, inclusive backups de dados, backup de hardware disponível para uso e outros.
Administradores de rede provêm seu conhecimento de protocolos de rede e a habilidade em redire-
cionar o tráfego de rede dinamicamente. O pessoal de segurança da informação é útil para rastrear
e investigar detalhadamente as questões de segurança assim como para analisar os sistemas compro-
metidos post-mortem (após o ataque).
Nem sempre é possível, mas deve haver redundância no pessoal de uma CERT. Se não for viável
ter uma área especializada na empresa, então deve haver treinamento para outras áreas sempre que
possível. Lembre-se que se somente uma pessoa tiver as informações cruciais para a segurança e
integridade dos dados, então a organização inteira ficará desamparada na ausência desta pessoa.

10.2.2. Considerações Legais


Alguns aspectos importantes da resposta ao incidente a considerar incluem as questões legais. Planos
de segurança devem ser desenvolvidos juntamente aos membros da área jurídica ou algum tipo de
conselho geral. Assim como toda empresa deve ter sua própria política de segurança corporativa, toda
empresa tem sua própria maneira de lidar com incidentes sob a perspectiva legal. Questões regulatórias
em nível local, estadual e federal vão além do escopo deste documento, mas são mencionadas pois
a metodologia de análise post-mortem será ditada, pelo menos em parte (ou em conjunto com), pelo
conselho jurídico. O conselho geral pode alertar o pessoal técnico das ramificações legais das infrações
Capítulo 10. Resposta ao Incidente 93

de segurança, os perigos de registros pessoais, médicos ou financeiros de um cliente vazarem, e a


importância de restaurar os serviços em ambiente críticos como hospitais e bancos.

10.3. Implementando o Plano de Resposta ao Incidente


Após um plano de ação ser criado, ele deve ser consentido e implementado ativamente. Qualquer as-
pecto do plano que seja questionado durante a implementação ativa pode resultar numa resposta lenta
e num período fora do ar no evento de uma infração. Nestas circunstâncias os exercícios práticos são
muito valiosos. A menos que algo venha à tona antes do plano ser ativamente definido na produção,
a implementação deve ser consentida por todas as partes diretamente relacionadas e executada com
confiança.
Se uma infração for detectada enquanto a CERT estiver presente para rápida reação, as possíveis re-
spostas podem variar. A equipe pode decidir desabilitar as conexões de rede, desligar os sistemas
afetados, consertar o exploit e então reconectar rapidamente sem possíveis complicações futuras. A
equipe também pode monitorar os infratores e rastrear suas ações. A equipe pode, inclusive, redi-
recionar o infrator para um pote de mel — um sistema ou segmento de rede contendo dados inten-
cionalmente falsos — para rastrear a invasão de maneira segura e sem interrupção dos recursos de
produção.
A resposta a um incidente deve acompanhar também uma coleta de informações sempre que possível.
A execução de processos, conexões de rede, arquivos, diretórios e outros devem ser auditados ativa-
mente em tempo real. Ter uma rápida impressão dos recursos de produção para comparação pode ser
útil ao rastrear serviços ou processos corrompidos. Os integrantes da CERT e os peritos internos serão
ótimos recursos para rastrear tais anomalias em um sistema. Administradores de sistemas sabem quais
processos devem ou não aparecer ao executar os comandos top ou ps. Administradores de rede estão
cientes de como funciona o tráfego normal de rede ao executar o snort ou até mesmo tcpdump.
Estes integrantes da equipe devem conhecer seus sistemas e serem capazes de apontar uma anomalia
mais rapidamente do que alguém que não esteja familiarizado com a infra-estrutura.

10.4. Investigando o Incidente


Investigar uma infração de computador é como investigar a cena de um crime. Os detetives coletam
evidências, anotam quaisquer pistas estranhas e fazem um inventário de perdas e danos. Uma análise
do comprometimento dos computadores pode ser feita enquanto o ataque ocorre ou post-mortem (após
o ataque).
Apesar de não ser recomendável confiar em nenhum arquivo de registro de um sistema que sofreu
exploit, há outras utilidades forênsicas para auxiliar sua análise. O propósito e funções destas ferra-
mentas variam, mas elas comumente criam pequenos ’arquivos-espelho’ da mídia, relacionam eventos
e processos, exibem informações simples do sistema de arquivo e recuperam arquivos apagados sem-
pre que possível.
Também é recomendado registrar todas as ações investigativas de um sistema corrompido, usando o
comando script, conforme o exemplo a seguir:

script -q 6 file-name 7
8 9
Substitua file-name pelo nome do arquivo de registros do script. Sempre salve o arquivo de
registros em outra mídia que não o disco rígido do sistema comprometido — um disquete ou CD-ROM
são boas opções para este propósito.
Ao registrar todas as suas ações, cria-se um rastro de auditoria que pode ser valioso se o atacante for
pego.
94 Capítulo 10. Resposta ao Incidente

10.4.1. Coletando uma Imagem Evidencial


Criar um pequeno ’arquivo-espelho’ da mídia é um primeiro passo razoável. Se estiver executando
trabalho forênsico de dados, é um requerimento. É recomendado fazer duas cópias: uma para análise
e investigação, e uma segunda para ser armazenada junto à original como evidência para quaisquer
procedimentos legais.
Você pode usar o comando dd, que é parte do pacote fileutils do Red Hat Enterprise Linux, para
criar uma imagem monolítica de um sistema que sofreu exploit como evidência de uma investigação,
ou para comparação com imagens confiáveis. Suponha que haja um único disco rígido no sistema no
qual você deseja criar a imagem. Conecte este disco como escravo ao sistema e então use o comando
dd para criar o arquivo imagem, conforme mostramos a seguir:

dd if=/dev/hdd bs=1k conv=noerror,sync of=/home/evidence/image1

Este comando cria um único arquivo chamado image1 usando o tamanho de um bloco de 1k para
velocidade. As opções conv=noerror,sync forçam o dd a continuar lendo e descarregando os dados
mesmo se encontrar setores danificados no disco suspeito. Agora é possível estudar o arquivo imagem
resultante ou até tentar recuperar arquivos apagados.

10.4.2. Coletando Informação Pós-Infração


O tópico forênsica e análise digital é bastante abrangente, mas as ferramentas são específicas para a ar-
quitetura em sua maioria e não podem ser aplicadas genericamente. Entretanto, resposta a indicentes,
análise e recuperação são tópicos muito importantes. Utilizando o conhecimento e a experiência apro-
priados, o Red Hat Enterprise Linux pode ser uma ótima plataforma para executar estes tipos de
análises já que inclui diversas funcionalidades para realizar a resposta e restauração pós-infração.
A Tabela 10-1 descreve alguns comandos para auditoria e gerenciamento de arquivos. Também lista
alguns exemplos que podem ser usados para identificar apropriadamente arquivos e seus atributos
(tais como permissões e datas de acesso) para que assim você possa coletar mais evidências ou ítens
para análise. Estas ferramentas, quando combinadas com sistemas de detecção de intrusão, firewalls,
serviços seguros e outras medidas de segurança, podem ajudar a reduzir os danos potenciais na ocor-
rência de um ataque.

Nota
Para informações detalhadas sobre cada ferramenta, consulte suas respectivas páginas man.

Comando Função Exemplo


dd Cria uma pequena cópia da imagem dd if=/bin/ls of=ls.dd
(ou disk dump) dos arquivos e |md5sum ls.dd >ls-sum.txt
partições. Combinado à verificação
dos md5sums de cada imagem,
administradores podem comparar
uma imagem pré-infração de uma
partição ou arquivo com um sistema
que sofreu uma infração para
verificar se as consistências
coincidem.
Capítulo 10. Resposta ao Incidente 95

Comando Função Exemplo


grep Encontra trechos de informação ps auxw |grep /bin
(texto) úteis dentro de arquivos e
diretórios, assim como revela
permissões, alterações de script,
atributos de arquivos e muito mais.
Utilizado principalmente como um
comando ’casado’ (piped) com
outro, como o ls, ps ou o
ifconfig.
strings Imprime os trechos de caracteres strings /bin/ps |grep
imprimíveis em um arquivo. É mais ’mail’
útil para examinar anomalias em
arquivos executáveis como
comandos mail para endereços
desconhecidos ou para registrar em
arquivos de registro fora do padrão.
file Determina as características de file /bin/ls
arquivos baseado no formato,
código, bibliotecas com as quais está
ligado (se houver) e tipo de arquivo
(binário, texto ou outros). É útil para
determinar se um executável, como
/bin/ls, foi modificado usando
bibliotecas estáticas, o que é um
sinal certeiro de que o executável foi
substituído por outro instalado por
um usuário maléfico.
find Busca determinados arquivos em find -atime +12 -name *log*
diretórios. É uma ferramenta útil -perm u+rw
para procurar na estrutura do
diretório por palavra-chave, data e
hora de acesso, permissões e outros
critérios. Também pode ser útil para
administradores que executam
auditorias gerais do sistema em
determinados arquivos ou diretórios.

stat Exibe informações sobre o status de stat /bin/netstat


um arquivo, inclusive a hora do
último acesso, permissões,
configurações UID e GID e outras.
Útil para verificar quando um
sistema que sofreu infração foi
utilizado ou modificado pela última
vez.
96 Capítulo 10. Resposta ao Incidente

Comando Função Exemplo


md5sum Calcula o checksum (verificação de md5sum /usr/bin/gdm
consistência) de 128 bits usando o >>md5sum.txt
algoritmo md5 hash. Use este
comando para criar um arquivo texto
que lista todos os executáveis
cruciais que são frequentemente
modificados ou substituídos em um
comprometimento da segurança.
Redirecione as somas para um
arquivo, a fim de criar um simples
banco de dados de consistências, e
então copie o arquivo para uma
mídia somente-leitura como um
CD-ROM.
Tabela 10-1. Ferramentas de Auditoria de Arquivos

10.5. Restaurando e Recuperando Recursos


Enquanto uma resposta ao incidente é executada, a equipe CERT deve investigar e trabalhar na recu-
peração dos dados e do sistema. Infelizmente, a natureza da infração é que dita o curso da recuper-
ação. É muito importante ter sistemas redundantes, backup ou offline, durante este período.
Para recuperar os sistemas, a equipe de resposta deve trazer de volta quaisquer sistemas ou aplicações
fora do ar, como servidores de autenticação, servidores de banco de dados, e outros recursos de pro-
dução.
É altamente recomendável ter hardware backup da produção pronto para uso, como drives extras,
servidores avulsos e outros do gênero. Sistemas prontos devem ter todo o software de produção car-
regado e pronto para uso imediato. Somente os dados mais recentes e pertinentes devem ser impor-
tados. Este sistema pronto deve ser mantido separadamente do resto da rede. Se ocorrer um com-
prometimento e o sistema de backup for parte da rede, então não há propósito em ter um sistema
backup.
A recuperação do sistema pode ser um processo tedioso. Em muitos casos há dois cursos de ações
a escolher. Administradores podem executar uma nova instalação do sistema operacional em cada
sistema afetado, seguida da restauração de todas as aplicações e dados. Alternativamente, os admin-
istradores também podem consertar as vulnerabilidades penetradas e trazer o sistema afetado de volta
à produção.

10.5.1. Reinstalando o Sistema


Executar uma reinstalação assegura que o sistema afetado será limpo de quaisquer trojans, backdoors
ou processos maléficos. A reinstalação também assegura que quaisquer dados (se recuperados a partir
de um backup confiável) estão livres de qualquer modificação maléfica. A desvantagem da recuper-
ação total do sistema é o tempo envolvido na reconstrução dos sistemas a partir do zero. No entanto,
se houver um bom sistema de backup disponível para uso, no qual a única ação a tomar é carregar os
dados mais recentes, então o downtime (tempo fora do ar) é reduzido drasticamente.

10.5.2. Consertando o Sistema (patching)


Consertar o sistema afetado é um curso de ações mais perigoso e deve ser executado com muita
atenção. O perigo de consertar um sistema ao invés de reinstalar é determinar se você realmente livrou
Capítulo 10. Resposta ao Incidente 97

o sistema de trojans, buracos na segurança e dados corrompidos. A maioria dos rootkits (programas
ou pacotes usados por um cracker para obter acesso root em seu sistema), comandos de sistema trojan
e ambientes de janela de comandos são desenvolvidos para ocultar atividades maléficas de auditorias
superficiais. Se você optar pelo conserto, use somente binários confiáveis (ex.: a partir de um CD-
ROM montado e somente-leitura).

10.6. Reportando o Incidente


A última parte do plano da resposta ao incidente é reportá-lo. A equipe de segurança deve tomar no-
tas enquanto a resposta estiver ocorrendo para reportar corretamente a questão às organizações, tais
como autoridades locais e federais, ou portais de multi-fabricantes de software, tal como o site Com-
mon Vulnerabilities and Exposures (CVE) em http://cve.mitre.org. Dependendo do tipo de conselho
jurídico aplicado pela sua empresa, uma análise post-mortem pode se fazer necessária. Mesmo se não
for um requisito funcional para uma análise do comprometimento, uma post-mortem pode ser muito
valiosa para entender como um cracker pensa e como seus sistemas estão estruturados, para assim
prevenir futuros comprometimentos.
98 Capítulo 10. Resposta ao Incidente
V. Apêndices

Esta parte aborda algumas das maneiras mais comuns usadas por intrusos para quebrar a segurança
de sistemas de computador ou interceptar dados em trânsito. Esta parte também detalha alguns dos
serviços mais utilizados e os números de suas portas associadas, que podem ser úteis a um admin-
istrador que pretende atenuar os riscos de ter seus sistemas crackeados.

Índice
A. Proteção ao Hardware e à Rede................................................................................................ 101
B. Exploits e Ataques Comuns....................................................................................................... 107
C. Portas Comuns ........................................................................................................................... 111
Apêndice A.
Proteção ao Hardware e à Rede
A melhor prática antes de empregar uma máquina em um ambiente de produção ou conectar sua rede
à Internet é determinar as necessidades de sua empresa, e como a segurança pode atender a estes req-
uisitos da maneira mais transparente possível. Já que o objetivo principal do Guia de Segurança do
Red Hat Enterprise Linux é explicar como proteger o Red Hat Enterprise Linux, um exame mais de-
talhado da segurança do hardware e da rede física está além do escopo deste documento. No entanto,
este capítulo apresenta uma breve visão geral do estabelecimento de políticas de segurança em relação
a hardware e redes físicas. Alguns fatores importantes a considerar incluem como os requisitos com-
putacionais e de conectividade são endereçados na estratégia de segurança. A seguir, uma explicação
detalhada de alguns destes fatores.

• A computação envolve mais do que somente estações de trabalho rodando software. Empresas
modernas requerem um grande poder computacional e serviços de alta disponibilidade, que po-
dem incluir mainframes, clusters de aplicação ou de computador, estações de trabalho poderosas e
aplicações especializadas. Com estes requisitos corporativos, entretanto, aumentou a propensão a
falhas de hardware, desastres naturais e a interfêrencias no ou roubo do equipamento.
• Conectividade é o método através do qual o administrador pretende conectar recursos díspares a
uma rede. Um administrador pode usar a Ethernet (cabeamento CAT-5/RJ-45 de hub ou de comuta-
dor), token ring, cabo coaxial 10-base-2 ou mesmo tecnologias sem-fio (802.11x). Dependendo do
meio que o administrador escolher, determinadas mídias e tecnologias de rede requerem tecnologias
complementares, como hubs, roteadores, comutadores, estações base e pontos de acesso. Determi-
nar uma arquitetura de rede funcional facilitará o processo administrativo se surgirem questões de
segurança.
A partir destas considerações gerais, os administradores podem obter uma visão melhor da imple-
mentação. A estrutura de um ambiente computacional pode ser baseado em ambos — necessidades
da corporação e considerações de segurança — uma implementação que atenda uniformemente aos
dois fatores.

A.1. Topologias de Rede Segura


A fundação de uma LAN é a topologia ou arquitetura de rede. A topologia é o layout físico e lógico
de uma LAN em termos de recursos providos, distância entre nódulos e meio de transmissão. De-
pendendo das necessidades da empresa à qual a rede serve, há diversas opções disponíveis para a
implementação da rede. Cada topologia tem suas vantagens e questões de segurança que arquitetos de
rede devem considerar ao desenhar o layout de suas redes.

A.1.1. Topologias Físicas


Conforme definido pelo Institute of Electrical and Electronics Engineers (IEEE), há três topologias
comuns para a conexão física de uma LAN.

A.1.1.1. Topologia Ring


A topologia Ring conecta cada nódulo usando exatamente duas conexões. Isto cria uma estrutura ring
na qual cada nódulo é acessível ao outro, diretamente por seus nódulos vizinhos fisicamente mais
próximos ou indiretamente através do ring físico. Redes Token Ring, FDDI e SONET são conec-
tadas desta maneira (com o FDDI usando uma técnica de ring duplo). No entanto, não há conexões
102 Apêndice A. Proteção ao Hardware e à Rede

Ethernet comuns usando esta topologia física, então os rings não são comumente empregados, ex-
ceto em configurações legadas ou institucionais com uma grande base de nódulos instalados (em uma
universidade, por exemplo).

A.1.1.2. Topologia de Canal Linear (Linear Bus)


A topologia de canal linear consiste de nódulos conectados a um cabo linear principal terminado (o
backbone). A topologia de canal linear requer um mínimo de cabeamento e equipamento de rede, o
que a torna a topologia de custo mais baixo. No entanto, o canal linear depende do backbone estar
constantemente disponível, tornando-o um ponto único de falha, caso seja necessário colocá-lo offline
ou esteja separado. Topologias de canal linear são comumente usadas em LANs par-a-par (peer-to-
peer) usando cabeamento coaxial e terminadores de 50-93 ohm nas duas extremidades do canal.

A.1.1.3. Topologia Estrela


A topologia Estrela (Star) incorpora um ponto central onde os nódulos se conectam e através do qual
a comunicação é passada. Este ponto central, chamado de hub pode ser transmitido ou comutado. Esta
topologia introduz um ponto único de falha no hardware de rede centralizado que conecta os nódulos.
Entretanto, devido essa centralização, as questões de rede que afetam segmentos ou a LAN inteira são
facilmente rastreáveis para esta fonte única.

A.1.2. Considerações de Transmissão


A Seção A.1.1.3 introduziu o conceito de rede transmitida e comutada. Há diversos fatores a consid-
erar ao avaliar o tipo de hardware adequado e seguro o suficiente para seu ambiente de rede. Veja a
seguir a distinção entre estas duas formas de rede.
Em uma rede de transmissão, um nódulo enviará um pacote que é recebido por todos os outros nódulos
até que o receptor pretendido aceite o pacote. Cada nódulo da rede pode concebivelmente receber este
pacote de dados até que o receptor processe o pacote. Em uma rede de transmissão, todos os pacotes
são enviados desta maneira.
Em uma rede comutada (switched network), os pacotes não são transmitidos, mas processados no hub
comutado que, por sua vez, cria uma conexão direta entre os nódulos emissor e receptor. Isto elimina
a necessidade de transmitir pacotes a cada nódulo, assim diminuindo o tráfego operante.
A rede comutada também evita que os pacotes sejam interceptados por usuários ou nódulos maléficos.
Em uma rede de transmissão, onde cada nódulo recebe o pacote no caminho de seu destino, usuários
maléficos podem configurar seu dispositivo Ethernet para o modo promíscuo e aceitar todos os pacotes
independentemente dos dados serem destinados a eles ou não. Uma vez definida no modo promíscuo,
uma aplicação sniffer pode ser usada para filtrar, analisar e reconstruir pacotes para senhas, dados pes-
soais e outros. Aplicações sniffer sofisticadas podem armazenar este tipo de informação em arquivos
texto e, talvez, até enviar as informações para fontes arbitrárias (por exemplo: o enedereço de e-mail
do usuário maléfico).
Uma rede comutada requer um comutador de rede, um componente de hardware especializado que
substitui a função do hub tradicional, ao qual todos os nódulos de uma LAN são conectados. Comuta-
dores armazenam endereços MAC de todos os nódulos em um banco de dados interno, que os utiliza
para seu roteamento direto. Diversos fabricantes, incluindo a Cisco Systems, D-Link, SMC e Netgear,
oferecem vários tipos de comutadores com características como a compatibilidade 10/100-Base-T,
suporte a Ethernet gigabit e networking IPv6.
Apêndice A. Proteção ao Hardware e à Rede 103

A.1.3. Redes Sem-fio


Uma questão emergente para as empresas é a mobilidade. Funcionários remotos, técnicos de campo
e executivos requerem soluções portáteis, como laptops, organizadores pessoais digitais (PDAs) e
acesso sem-fio a recursos de rede. O IEEE estabeleceu normas para a especificação sem-fio 802.11,
que dita padrões para a comunicação de dados sem-fio para todos os setores. O padrão corrente
aprovado pelo IEEE é a especificação 802.11g para redes sem-fio, enquanto 802.11a e 802.11b são
padrões legados. O padrão 802.11g é compatível com o 802.11b, mas não com o 802.11a.
As especificações 802.11b e 802.11g são, na verdade, um grupo de padrões que governam as comuni-
cações sem-fio e exercem controle sobre o espectro 2.4GHz de rádio frequência (RF) não licensiado
(a 802.11a usa o espectro de 5GHz). Estas especificações foram aprovadas como padrões pelo IEEE, e
diversos fabricantes comercializam produtos e serviços 802.11x. Os consumidores também adotaram
o padrão para as redes em escritórios pequenos ou caseiros. A popularidade também extendeu-se das
LANs às MANs (Redes de Área Metropolitana), especialmente em áreas populosas onde há uma con-
centração de pontos de acesso sem-fio (wireless access points - WAPs). Além disso, há provedores
de serviços de Internet sem-fio que servem viajantes frequentes necessitando acesso de banda larga à
Internet, para conduzir seus negóciois remotamente.
As especificações 802.11x permitem conexões par-a-par diretas entre nódulos com NICs sem-fio.
Este agrupamento flexível de nódulos, chamado de rede improvisada, é ideal para compartilhamento
de conexão rápida entre dois ou mais nódulos, mas introduz questões de escalabilidade não adequadas
para conectividade sem-fio dedicada.
Uma solução mais adequada para o acesso sem-fio em estruturas fixas é instalar um ou mais WAPs,
que conectam à rede tradicional e permitem que nódulos sem-fio se conectem ao WAP como se fosse
na rede baseada na Ethernet. O WAP age efetivamente como uma ponte entre os nódulos conectados
a ele e o resto da rede.

A.1.3.1. Segurança da 802.11x


Apesar da rede sem-fio ser comparável em velocidade e certamente mais conveniente que os meios de
redes com fios, há algumas limitações na especificação que autoriza consideração completa. A mais
importante destas limitações está na sua implementação de segurança.
Com a ansiedade de implantar uma rede 802.11x com sucesso, muitos administradores deixam de
tomar as precauções de segurança mais básicas. Desde que toda a rede 802.11x esteja feita usando
sinais RF de banda alta, os dados transmitidos são facilmente acessíveis a qualquer usuário com um
NIC compatível, uma ferramenta de scanning da rede sem-fio (como o NetStumbler ou o Wellenre-
iter) e ferramentas comuns de sniffing (como dsniff e snort). Para impedir este uso indevido das
redes privadas sem-fio, o padrão 802.11b usa o protocolo Wired Equivalency Privacy (WEP), uma
chave criotografada de 64 ou 128 bits baseada no RC-4 e compartilhada entre cada nódulo ou entre a
WAP e o nódulo. Esta chave criptografa as transmissões e descriptografa pacotes de entrada dinâmica
e transparentemente. Os administradores frequentemente deixam de implementar este esquema de
criptografia de chave compartilhada por esquecimento ou porque escolheram não fazê-lo devido à
degradação do desempenho (especialmente através de distâncias longas). No entanto, ativar o WEP
em uma rede sem-fio pode reduzir drasticamente a possibilidade de intercepção de dados.
O Red Hat Enterprise Linux suporta vários produtos 802.11x de diversos fabricantes. A Ferramenta
de Administração de Rede inclui uma funcionalidade para configurar a segurança de NICs e WEP
sem-fio. Para informações sobre o uso da Ferramenta de Administração de Rede, consulte o Guia
de Administração de Sistemas Red Hat Enterprise Linux.
Confiar no WEP, entretanto, ainda não é o suficiente em termos de proteção contra determinados
usuários maléficos. Há utilitários especializados desenvolvidos especificamente para craquear o algo-
ritmo RC4 de criptografia do WEP protegendo uma rede sem-fio e expondo a chave compartilhada.
A AirSnort e a WEP Crack são dois exemplos destas aplicações especializadas. Para protegerem-se
destas, os administradores devem aderir a normas restritas em relação ao uso de métodos sem-fio para
o acesso a informações delicadas. Pode-se optar por aumentar a segurança da conectividade sem-fio
restringindo-a somente a conexões SSH ou VPN, que introduz uma camada de criptografia adicional
104 Apêndice A. Proteção ao Hardware e à Rede

sobre a criptografia WEP. Ao usar esta norma, um usuário maléfico externo à rede que craquear a
criptografia WEP, também terá que craquear a criptografia VPN ou SSH. Dependendo do método,
pode-se empregar até criptografia de algoritmo DES de 168 bits de força tripla (3DES), ou algoritmos
proprietários com força ainda maior. Os administradores que aplicarem estas normas devem restringir
protocolos somente-texto (como Telnet ou FTP), já que senhas e dados podem ser expostos usando
quaisquer dos ataques mencionados anteriormente.
Um método recente de segurança e autenticação, adotado por fabricantes de equipamento de rede,
é o Wi-fi Protected Acces (Acesso Sem-fio Protegido - WPA). Os administradores podem configurar
o WPA em sua rede usando um servidor de autenticação que administra as chaves de clientes que
acessam a rede sem-fio. O WPA é melhor que a criptografia WEP pois usa o Temporal Key Integrity
Protocol (Protocolo de Integridade da Chave Temporal - TKIP), um método de usar uma chave com-
partilhada e associá-la ao endereço MAC da placa da rede sem-fio instalada no sistema cliente. Os
valores da chave compartilhada e do endereço MAC então são processados por um vetor de inicial-
ização (IV), que é usado para gerar uma chave que criptografa cada pacote de dados. O IV altera a
chave cada vez que um pacote é transferido, prevenindo os ataques mais comuns às redes sem-fio.
No entanto, o WPA usando o TKIP é tido como uma solução temporária. Soluções usando cifras
de criptografia mais fortes (como AES) estão sob desenvolvimento e têm o potencial de aumentar a
segurança da rede sem-fio no âmbito corporativo.
Para mais informações sobre os padrões 802.11, consulte a seguinte URL:

http://standards.ieee.org/getieee802/802.11.html

A.1.4. Segmentação de Rede e DMZs


Para administradores que queiram rodar serviços acessíveis externamente (como HTTP, e-mail, FTP
e DNS) é recomendado que estes serviços sejam física e/ou logicamente separados da rede interna.
Firewalls e a proteção de máqunas e aplicações são maneiras efetivas de detectar intrusões casuais.
Entretanto, alguns crackers podem encontrar vias à rede interna se os serviços que craquearam residem
no mesmo segmento da rede. Os serviços acessíveis externamente devem residir no que a indústria
da segurança chama de zona desmilitarizada (DMZ), um segmento da rede lógica onde o tráfego de
entrada da Internet pode acessar somente àqueles serviços e não pode acessar a rede interna. Isto é
efetivo, pois mesmo que um usuário maléfico faça um exploit na DMZ de uma máquina, o resto da
rede interna fica atrás de um firewall num segmento separado.
A maioria das empresas tem um conjunto limitado de endereços IP publicamente roteáveis, a partir
dos quais pode hospedar serviços externos. Desta forma, os administradores utilizam regras de fire-
wall elaboradas para aceitar, encaminhar, rejeitar e negar transmissões de pacotes. Regras de firewall
implementadas com iptables ou firewalls de hardware dedicado permitem o roteamento complexo
e o encaminhamento de regras. Os administradores podem usar estas normas para segmentar o tráfego
de entrada para serviços específicos em endereços e portas específicos, enquanto permitir que somente
a LAN acesse os serviços internos, o que pode evitar exploits de spoofing de IP. Para mais informações
sobre a implementação do iptables, consulte o Capítulo 7.

A.2. Segurança de Hardware


De acordo com um estudo lançado em 2000 pelo FBI e o Computer Security Institute (CSI), mais de
setenta por cento de todos os ataques a dados e recursos delicados reportados por empresas ocorreram
dentro da própria empresa. Implementar normas de segurança interna é tão importante quanto uma
estratégia externa. Esta seção explica algumas das medidas comuns que administradores e usuários
podem tomar para proteger seus sistemas de exploits internos.
Apêndice A. Proteção ao Hardware e à Rede 105

Estações de trabalho de funcionários não são, na maioria dos casos, potenciais alvos de ataques remo-
tos, especialmente aquelas atrás de um firewall configurado apropriadamente. No entanto, há algumas
medidas de proteção que podem ser implementadas para evitar um ataque físico ou interno aos recur-
sos de estações de trabalho individualmente.
Estações de trabalho e PCs caseiros modernos usam um BIOS que controla os recursos do sistema
no nível do hardware. Usuários de estações de trabalho podem determinar senhas administrativas
no BIOS para impedir que usuários maléficos acessem ou inicializem o sistema. Senhas do BIOS
impedem que usuários maléficos inicializem o sistema de todas as maneiras, detendo o usuário de
acessar rapidamente ou roubar as informações armazenadas no disco rígido.
Mas, se o usuário maléfico roubar o PC (o caso mais comum de roubo entre viajantes que carregam
laptops e outros dispositivos portáteis) e levá-lo a um lugar onde ele pode desmontar o computador,
a senha do BIOS não evita que o atacante remova o disco rígido. Assim, pode instalá-lo em outro PC
sem restrições de BIOS e acessar o disco rígido para ler seu conteúdo. Nestes casos, é recomendado
que estações de trabalho tenham bloqueios para restringir o acesso ao hardware interno. Dispositivos
especiais de segurança, como cabos de aço com cadeados, podem ser ligados ao chassis do PC e do
laptop para evitar roubo, assim como bloqueios de chave no próprio chassis para evitar acesso interno.
Este tipo de hardware é amplamente disponibilizado por fabricantes como Kensington e Targus.
O hardware de servidor, especialmente servidores de produção, é geralmente montado em racks em
salas de servidores. Armários de servidor comumente possuem portas com trancas; e chassis individ-
uais de servidores também estão disponíveis com trancas na frente para aumentar a segurança contra
o desligamento errôneo (ou intencional).
As empresas também podem usar provedores de co-locação para guardar seus servidores, já ques estes
oferecem banda mais alta, suporte técnico 24h 7 dias por semana e conhecimento em segurança de
sistemas e servidores. Este pode ser um meio efetivo de terceirizar as necessidades de segurança e
conectividade para transações HTTP ou serviços de streaming media. No entanto, a co-locação pode
ter um alto custo, especialmente para pequenas e médias empresas. As estruturas de co-locação são
conhecidas por ser altamente protegidas por seguranças treinados e monitoradas o ininterruptamente.
106 Apêndice A. Proteção ao Hardware e à Rede
Apêndice B.
Exploits e Ataques Comuns
A Tabela B-1 detalha alguns dos exploits e pontos de entrada mais comuns usados por intrusos para
acessar recursos de rede de organizações. As explicações de como estes exploits são executados e
como administradores podem proteger sua rede apropriadamente são muito importantes contra tais
ataques.

Exploit Descrição Notas


Senha em branco Deixar senhas administrativas em Comumente associado a hardware de
ou default branco ou usar a senha default provida rede, como roteadores, firewalls,
pelo fabricante. Isto é mais comum em VPNs e aplicações de
hardware, como roteadores e firewalls, armazenamento anexo à rede
porém alguns dos serviços que rodam (network attached storage - NAS);
no Linux podem conter senhas default Comum em muitos sistemas
de administrador (apesar do Red Hat operacionais legados, especialmente
Enterprise Linux não distribuí-las). aqueles que compoem serviços
(como UNIX e Windows).
Às vezes, administradores criam
algumas contas de usuários
privilegiados com pressa e deixam a
senha vazia, um ponto de entrada
perfeito para usuários maldosos que
descobrem a conta.
Chaves Serviços seguros às vezes empacotam Mais comum em pontos de acesso
Compartilhadas chaves de seurança default para sem-fio e aplicações de servidor
Default desenvolvimento ou para testes de seguro pré-configuradas
avaliação. Se estas chaves CIPE (consulte o Capítulo 6) contém
permanacerem inalteradas e estiverem uma amostra de chave estática que
localizadas em um ambiente de deve ser alterada antes da aplicação
produção na Internet, qualquer em um ambiente de produção
usuário com as mesmas chaves default
tem acesso a este recurso de chave
compartilhada e a quaisquer
informações importantes contidas
neste.
108 Apêndice B. Exploits e Ataques Comuns

Exploit Descrição Notas


Spoofing do IP Uma máquina remota age como um O Spoofing é bem difícil já que
(alteração do nódulo em sua rede local, encontra requer que o atacante adivinhe os
endereço IP para vulnerabilidades em seus servidores e números de TCP/IP SYN-ACK para
parecer como instala um programa backdoor ou coordenar uma conexão que almeje
outra máquna) trojan horse para obter controle sobre os sistemas, mas há diversas
seus recursos de rede. ferramentas disponíveis para auxiliar
crackers a executá-lo.
Depende de almejar sistemas que
estejam rodando serviços (tais como
rsh, telnet, FTP e outros) que
utilizam técnicas de autenticação
baseadas na fonte, não recomendadas
quando comparadas à PKI ou outras
formas de autenticação criptografada
usadas no ssh ou SSL/TLS.
Eavesdropping Coleta de dados que trafegam entre Este tipo de ataque geralmente
(espionagem do dois nódulos ativos em uma rede funciona com protocolos de
tráfego de rede) através do eavesdropping na conexão transmissão somente-texto, como
entre estes dois nódulos. transferências Telnet, FTP e HTTP.
O atacante remoto deve ter accesso a
um sistema comprometido em uma
LAN para poder executar um ataque
deste tipo. Geralmente o cracker usa
um ataque ativo (como um spoofing
de IP ou ’man-in-the-middle’) para
comprometer um sistema na LAN
Medidas preventivas incluem serviços
com troca de chave criptográfica,
senhas descartáveis ou autenticação
criptografada para impedir snooping
de senha. Também recomenda-se a
alta criptografia durante as
transmissões
Apêndice B. Exploits e Ataques Comuns 109

Exploit Descrição Notas


Vulnerabilidades Um atacante encontra um defeito ou Serviços baseados em HTTP, tais
do Serviço uma infração em um serviço como o CGI, são vulneráveis a
executado pela Internet através desta execuções de comandos remotos e
vulnerabilidade. O atacante até mesmo a acesso através da janela
compromete o sistema inteiro e de comandos. Mesmo que o serviço
quaisquer dados que este possa HTTP seja executado por um usuário
conter; e também é possível que não-privilegiado, como "ninguém",
comprometa outros sistemas da rede. as informações como arquivos de
configuração e mapas de rede podem
ser lidas, ou o atacante pode iniciar
um ataque ’denial of service’ que
drena os recursos do sistema ou
torna-os indisponíveis a outros
usuários.
Às vezes, os serviços podem ter
vulnerabilidades que passam
desapercebidas durante o
desenvolvimento e testes. Estas
vulnerabilidades (tais como
sobrecarregamentos do buffer, nos
quais o atacante derruba um serviço
usando valores arbitrários que
preenchem o buffer da memória de
uma aplicação, oferecendo ao
atacante uma janela de comandos
interativa, a partir da qual ele pode
executar qualquer comando) podem
oferecer controle administrativo
completo a um atacante.
Administradores devem certificar-se
que os serviços não sejam executados
com o usuário root e estar atentos a
atualizações de erratas e consertos
para suas aplicações, de fabricantes ou
empresas de segurança como CERT e
CVE.
110 Apêndice B. Exploits e Ataques Comuns

Exploit Descrição Notas


Vulnerabilidades Atacantes encontram falhas em Estações de trabalho e computadores
da Aplicação aplicações de computadores pessoais pessoais são mais propensos a
e estações de trabalho (como clientes exploits porque os funcionários não
de e-mail) e executam código têm a mesma habilidade ou
arbitrário, implantando trojans para experiência para impedir ou detectar
comprometer ou danificar os sistemas o comprometimento; é essencial
futuramente. Exploits podem ocorrer informar aos indivíduos sobre os
no futuro se a estação de trabalho riscos que correm ao instalar
comprometida tiver privilégios software não autorizado ou abrir
administrativos sobre o resto da rede. arquivos anexos de e-mails não
solicitados.
Algumas defesas podem ser
implementadas de modo que este
software de cliente de e-mail não abra
ou execute automaticamente arquivos
anexos. Adicionalmente, a atualização
automática do software da estação de
trabalho através da Red Hat Network
ou outros serviços de gerenciamento
de sistemas, podem aliviar a carga de
aplicações de segurança para um
ambiente multi-usuário.
Ataques Denial of O atacante ou grupo de atacantes O caso de DoS (denial of service)
Service (DoS) coordena um ataque a recursos de ocorrido em 2000 mais reportado:
rede ou de servidor de uma empresa diversos sites comerciais e
enviando pacotes não autorizados para governamentais de alto tráfego
a máquina alvo (um servidor, um tornaram-se indisponíveis por um
roteador ou uma estação de trabalho). ataque ’ping flood’ coordenado,
Isto força o recurso a ficar usando vários sistemas
indisponível aos usuários legítimos. comprometidos com conexões de
banda larga atuando como zumbis,
ou nódulos de transmissão
redirecionados.
Pacotes fonte geralmente são
forjados (e também retransmitidos),
dificultando a investigação da
verdadeira origem do ataque.
Avanços na filtragem do ingresso
(ingress filtering - IETF rfc2267),
usando iptables e IDs de Rede
como snort, ajudam administradores
a rastrear e impedir ataques DoS
distribuídos.
Tabela B-1. Exploits Comuns
Apêndice C.
Portas Comuns
As tabelas a seguir listam as portas de comunicação mais comuns usadas pelos serviços, daemons
e programas inclusos no Red Hat Enterprise Linux. Esta lista também pode ser encontrada no ar-
quivo /etc/services. Para acessar uma lista oficial das portas Bem Conhecidas (Well Knnown),
Registradas (Registered) e Dinâmicas (Dynamic) conforme designadas pela IANA (Internet Assigned
Numbers Authority), consulte o site:
http://www.iana.org/assignments/port-numbers

Nota
A Camada, quando listada, denota se o serviço ou protocolo usa TCP ou UDP para transporte. Se
não estiver especificada, o serviço/protocolo pode usar ambos, TCP e UDP.

A Tabela C-1 lista as Portas Conhecidas (Well Known Ports) conforme definidas pela IANA e são
usadas pelo Red Hat Enterprise Linux como as portas de comunicação default para vários serviços,
incluindo FTP, SSH e Samba.

Número da Nome Comentário


Porta / Camada

1 tcpmux Multiplexador do serviço da porta do TCP


5 rje Entrada de Tarefa Remota
7 echo Serviço Echo
9 descartar Serviço zero para teste de conexão
11 systat Serviço de Estado do Sistema para listar as portas
conectadas
13 daytime Envia data e hora para a máquina requerente
17 qotd Envia a citação do dia para a máquina conectada
18 msp Protocolo de Envio de Mensagem
19 chargen Serviço de Geração de Caractere; envia trechos infinitos
de caracteres
20 ftp-data Porta de dados do FTP
21 ftp Porta do Protocolo de Transferência de Arquivos (FTP);
por vezes usada pelo Protocolo de Serviço de Arquivos
(FSP - File Service Protocol)
22 ssh Serviço Secure Shell (SSH)
23 telnet O serviço Telnet
112 Apêndice C. Portas Comuns

Número da Nome Comentário


Porta / Camada

25 smtp Protocolo de Transferência de Correspondência Simples


(SMTP- Simple Mail Transfer Protocol)
37 time Protocolo de Hora
39 rlp Protocolo de Localidade de Recursos
42 nameserver Serviço de Nomes da Internet
43 nicname Serviço do diretório WHOIS
49 tacacs Sistema de Controle de Acesso do Controlador de Acesso
do Terminal para autenticação e acesso baseado no
TCP/IP
50 re-mail-ck Protocolo de Verificação de Correspondência Remota
53 domain serviços de nome de domínio (tal como BIND)
63 whois++ WHOIS++, serviços WHOIS extendidos
67 bootps Serviços do Protocolo de Bootstrap (BOOTP); também
usado pelos serviços do Protocolo de Configuração da
Máquina Dinâmica (Dynamic Host Configuration
Protocol, DHCP)
68 bootpc Cliente boostrap (BOOTP); também usado por clientes do
Protocolo de Controle da Máquina Dinâmica (DHCP)
69 tftp Protocolo de Transferência de Arquivos Triviais (TFTP -
Trivial File Transfer Protocol)
70 gopher Ferramenta de busca e recuperação de documentos de
Internet Gopher
71 netrjs-1 Serviço de Tarefa Remota
72 netrjs-2 Serviço de Tarefa Remota
73 netrjs-3 Serviço de Tarefa Remota
73 netrjs-4 Serviço de Tarefa Remota
79 finger Serviço finger para informações de contato do usuário
80 http Protocolo de Transferência de HíperTexto (HTTP) para
serviços WWW (World Wide Web)
88 kerberos Sistema de autenticação de rede Kerberos
95 supdup Extensão do protocolo telnet
101 hostname Serviços de nomes para máquinas SRI-NIC
102/tcp iso-tsap Aplicações de rede do Ambiente de Desenvolvimento ISO
(ISODE)
105 csnet-ns Servidor de nomes da caixa de correspondência; também
usado pelo servidor de nomes CSO
107 rtelnet Telnet remoto
109 pop2 Versão 2 do Protocolo do Post Office
Apêndice C. Portas Comuns 113

Número da Nome Comentário


Porta / Camada

110 pop3 Versão 3 do Protocolo do Post Office


111 sunrpc Protocolo da Chamada de Procedimento Remoto (RPC)
para execução de comandos remotos, usado pelo Sistema
de Arquivo de Rede (NFS)
113 auth Protocolos de autenticação e identificação
115 sftp Serviços do Protocolo de Transferência de Arquivos
Seguros (SFTP)
117 uucp-path Serviços da Localidade do Protocolo de Cópia
Unix-para-Unix (UUCP - Unix-to-Unix Copy Protocol)
119 nntp Protocolo de Transferência de Notícias de Rede (Network
News Transfer Protocol, NNTP) para o sistema de
discussão USENET
123 ntp Protocolo de Hora da Rede (NTP - Network Time
Protocol)
137 netbios-ns Serviço de Nome do NETBIOS usado no Red Hat
Enterprise Linux pelo Samba
138 netbios-dgm Serviço de Datagrama do NETBIOS usado no Red Hat
Enterprise Linux pelo Samba
139 netbios-ssn Serviço de Sessões do NETBIOS usado no Red Hat
Enterprise Linux pelo Samba
143 imap Protocolo de Acesso à Mensagem via Internet (Internet
Message Access Protocol, IMAP)
161 snmp Protocolo de Administração de Rede Simples (SNMP -
Simple Network Management Protocol)
162 snmptrap Armadilhas SNMP
163 cmip-man Protocolo de Informações de Administração Comum
(CMIP - Common Management Information Protocol)
164 cmip-agent Protocolo de Informações de Administração Comum
(CMIP - Common Management Information Protocol)
174 mailq fila de transporte de e-mail MAILQ
177 xdmcp Protocolo de Controle da Administração de Exibição do X
(XDMCP)
178 nextstep Servidor de janelas do NeXTStep
179 bgp Protocolo da Porta de Comunicação da Divisa (Border
Gateway Protocol)
191 prospero Serviços de sistema de arquivo distribuídos Prospero
194 irc Internet Relay Chat (IRC)
199 smux Multiplexador UNIX para SNMP
201 at-rtmp Roteamento do AppleTalk
114 Apêndice C. Portas Comuns

Número da Nome Comentário


Porta / Camada

202 at-nbp Ligação de nomes do AppleTalk


204 at-echo Eco do AppleTalk
206 at-zis Informações da zona do AppleTalk
209 qmtp Protocolo de Transferência de Correspondência Rápida
(QMTP - Quick Mail Transfer Protocol)
210 z39.50 Banco de dados NISO Z39.50
213 ipx Troca de Pacotes entre Redes (Internetwork Packet
Exchange, IPX), um protocolo de datagrama geralmente
usado em ambientes Netware do Novell
220 imap3 Protocolo de Acesso a Mensagens via Internet versão 3
245 link LINK / Serviço iQuery 3-DNS
347 fatserv Servidor de administração de fita e arquivos FATMEN
363 rsvp_tunnel Túnel RSVP
369 rpc2portmap Portmapper do sistema de arquivo Coda
370 codaauth2 Serviços de autenticação do sistema de arquivo Coda
372 ulistproc UNIX LISTSERV
389 ldap Protocolo de Acesso ao Diretório Lightweight (LDAP -
Lightweight Directory Access Protocol)
427 svrloc Protocolo de Localização do Serviço (SLP - Service
Location Protocol)
434 mobileip-agent Agente do Protocolo de Internet (IP)
435 mobilip-mn Administrador do Protocolo de Internet (IP) Móvel
443 https Protocolo de Transferência de Hypertexto Seguro (HTTPS
- Secure Hypertext Transfer Protocol)
444 snpp Protocolo de Paging de Rede Simples
445 microsoft-ds Server Message Block (SMB) sobre TCP/IP
464 kpasswd Serviços de alteração da senha e chave do Kerberos
468 photuris Protocolo de administração da chave da sessão do Photuris

487 saft Protocolo de Transferência de Arquivos Assíncronos


Simples (SAFT - Simple Asynchronous File Transfer)
488 gss-http Serviços de Segurança Genérica (Generic Security
Services, GSS) para o HTTP
496 pim-rp-disc Rendezvous Point Discovery (RP-DISC) para os serviços
do Protocol Independent Multicast (PIM)
500 isakmp Protocolo de Administração da Chave e da Associação da
Segurança de Internet (ISAKMP - Internet Security
Association and Key Management Protocol)
Apêndice C. Portas Comuns 115

Número da Nome Comentário


Porta / Camada

535 iiop Protocolo Internet Inter-Orb (IIOP)


538 gdomap Mapeador de Objetos Distribuídos do GNUstep
(GDOMAP - GNUstep Distributed Objects Mapper)
546 dhcpv6-client Protocolo de Configuração da Máquina Dinâmica (DHCP
- Dynamic Host Configuration Protocol) versão 6 cliente
547 dhcpv6-server Protocolo de Configuração da Máquina Dinâmica (DHCP
- Dynamic Host Configuration Protocol) versão 5 Serviço
554 rtsp Protocolo de Controle do Stream em Tempo Real (RTSP -
Real Time Stream Control Protocol)
563 nntps Protocolo de Transporte de Notícias de Rede sobre a SSL
(NNTPS - Network News Transport Protocol over Secure
Sockets Layer)
565 whoami lista whoami de IDs de usuários
587 submissão Agente de Submissão da Mensagem de Correio (MSA -
Mail Message Submission Agent)
610 npmp-local Protocolo de Administração dos Periféricos de Rede
(NPMP - Network Peripheral Management Protocol) local
/ Sistema de Ordenação Distribuída (DQS - Distributed
Queueing System)
611 npmp-gui Protocolo de Administração dos Periféricos de Rede
(NPMP - Network Peripheral Management Protocol) GUI
/ Sistema de Ordenação Distribuída (DQS - Distributed
Queueing System)
612 hmmp-ind Indicação do Protocolo de Administração do HyperMedia
(HMMP) / DQS
631 ipp Protocolo de Impressão da Internet (IPP - Internet Printing
Protocol)
636 ldaps Protocolo de Acesso ao Diretório Lightweight sobre a SSL
(LDAPS - Lightweight Directory Access Protocol over
Secure Sockets Layer)
674 acap Protocolo de Acesso à Configuraço da Aplicação (ACAP -
Application Configuration Access Protocol)
694 ha-cluster Serviços heartbeat para Clusters de Alta Disponibilidade
749 kerberos-adm Administração do banco de dados kadmin do Kerberos
versão 5 (v5)
750 kerberos-iv Serviços do Kerberos versão 4 (v4)
765 webster Dicionário da Rede
767 phonebook Catálogo de Telefones da Rede
873 rsync serviços de transferência de arquivos rsync
992 telnets Telnet sobre a Secure Sockets Layer (TelnetS)
116 Apêndice C. Portas Comuns

Número da Nome Comentário


Porta / Camada

993 imaps Protocolo de Acesso a Mensagens da Internet sobre a SSL


(IMAPS - Internet Message Access Protocol over Secure
Sockets Layer)
994 ircs Internet Relay Chat sobre Secure Sockets Layer (IRCS)
995 pop3s Protocolo do Post Office versão 3 sobre SSL (POP3S -
Post Office Protocol version 3 over Secure Sockets Layer)

Tabela C-1. Portas Bem Conhecidas

A Tabela C-2 lista as portas específicas do UNIX e abrange os serviços desde e-mail a autenticação,
dentre outros. Os nomes entre colchetes (ex.: [serviço]) são nomes de daemons do serviço ou
codenome(s) comuns.

Número da Nome Comentário


Porta / Camada

512/tcp exec Autenticação para execução do processo remoto


512/udp biff [comsat] Cliente de Mail (biff) e serviço (comsat) assíncronos
513/tcp login Autenticação Remota (rlogin)
513/udp who [whod] daemon whod de autenticação do usuário
514/tcp shell [cmd] shell remota (rshell) e cópia remota (rcp) sem autenticação

514/udp syslog Serviço de autenticação do sistema UNIX


515 printer [spooler] spooler da impressora em linha (lpr)
517/udp talk Serviço e cliente de chamada remota talk
518/udp ntalk Cliente e Serviço do Network talk (ntalk) remote calling
519 utime [unixtime] Protocolo de hora do UNIX (utime)
520/tcp efs Servidor de Nomes Extendidos de Arquivo (EFS -
Extended Filename Server)
520/udp router [route, Protocolo de Informações de Roteamento (RIP- Routing
routed] Information Protocol)
521 ripng Protocolo de Informações de Roteamento para o Protocolo
de Internet versão 6 (IPv6)
525 timed Daemon de hora (timed)
[timeserver]
526/tcp tempo [newdate] Tempo
530/tcp courier [rpc] Protocolo de Chamada do Processo Remoto de
Mensageiro (RPC - Remote Procedure Call)
531/tcp conference [chat] Internet Relay Chat
Apêndice C. Portas Comuns 117

Número da Nome Comentário


Porta / Camada

532 netnews Serviço de newsgroup Netnews


533/udp netwall Netwall para transmissões de emergência
540/tcp uucp [uucpd] Serviços de cópia UNIX-para-UNIX
543/tcp klogin Autenticação remota do Kerberos versão 5 (v5)
544/tcp kshell Shell remota do Kerberos versão 5 (v5)
548 afpovertcp Protocolo de Arquivamento do Appletalk (AFP) sobre o
Protocolo de Controle da Transmissão (TCP)
556 remotefs Sistema de Arquivo Remoto de Brunhoff (RFS)
[rfs_server, rfs]
Tabela C-2. Portas Específicas do UNIX

A Tabela C-3 lista as portas submetidas pela rede e pela comunidade do software para o IANA, a fim
de registrá-las formalmente:

Número da Nome Comentário


Porta / Camada

1080 socks Serviços proxy da aplicação de rede SOCKS


1236 bvcontrol Servidor de Configuração Remota dos comutadores de
[rmtcfg] rede Gracilis Packetena
1300 h323hostcallsc H.323 telecommunication Host Call Secure
1433 ms-sql-s Sefrvidor do Microsoft SQL
1434 ms-sql-m Monitor do Microsoft SQL
1494 ica Cliente Citrix ICA
1512 wins Servidor de Nomes Internet do Microsoft Windows
1524 ingreslock Serviços de bloqueio do Sistema de Administração do
Banco de Dados Ingres (DBMS - Database Management
System)
1525 prospero-np Prospero não-privilegiado
1645 datametrics Datametrics / entrada do radius antigo
[old-radius]
1646 sa-msg-port sa-msg-port / entrada do radacct antigo
[oldradacct]
1649 kermit Serviço de administração e transferência de arquivos
Kermit
1701 l2tp [l2f] Protocolo de Tunneling da Camada 2 (LT2P - Layer 2
Tunneling Protocol) / Encaminhamento da Camada 2 (L2F
- layer 2 forwarding)
1718 h323gatedisc H.323 telecommunication Gatekeeper Discovery
118 Apêndice C. Portas Comuns

Número da Nome Comentário


Porta / Camada

1719 h323gatestat H.323 telecommunication Gatekeeper Status


1720 h323hostcall H.323 telecommunication Host Call setup
1758 tftp-mcast Multi-transmissão do FTP Trivial
1759/udp mtftp FTP Trivial de Multi-transmissão (MTFTP)
1789 hello Protocolo de comunicação do roteador hello
1812 radius Serviços de autenticação e contabilidade da discagem do
radius
1813 radius-acct Contabilidade do Radius
1911 mtp Protocolo de Transporte Multimídia das Redes Starlight
(MTP)
1985 hsrp Protocolo do Roteador Standby do Cisco Hot
1986 licensedaemon Daemon da Administração de Licensa Cisco
1997 gdp-port Protocolo da Descoberta da Porta de Comunicação Cisco
(GDP)
2049 nfs [nfsd] Sistema de Arquivo de Rede (NFS)
2102 zephyr-srv Servidor de mensagens distribuídas Zephyr
2103 zephyr-clt cliente Zephyr
2104 zephyr-hm Administrador da máquina Zephyr
2401 cvspserver Concurrent Versions System (CVS) cliente/operações de
servidor
2430/tcp venus Administrador de cache Venus para o sistema de arquivo
Coda (porta codacon)
2430/udp venus Administrador de cache Venus para o sistema de arquivo
Coda (callback/interface wbc)
2431/tcp venus-se efeitos colaterais do Protocolo de Controle de Transmissão
(TCP) Venus
2431/udp venus-se Efeitos colaterais do Protocolo de Datagrama de Usuário
Vênus (Venus User Datagram Protocol, UDP)
2432/udp codasrv porta do servidor do sistema de arquivo Coda
2433/tcp codasrv-se efeitos colaterais do TCP do sistema de arquivo Coda
2433/udp codasrv-se efeitos colaterais do SFTP do UDP do sistema de arquivo
Coda
2600 hpstgmgr Roteamento do Zebrab
[zebrasrv]
2601 discp-client cliente discp; shell integrada do Zebra
[zebra]
2602 discp-server servidor discp; daemon do Protocolo de Informações de
[ripd] Roteamento (ripd)
Apêndice C. Portas Comuns 119

Número da Nome Comentário


Porta / Camada

2603 servicemeter Medidor do Serviço; daemon do RIP para IPv6


[ripngd]
2604 nsc-ccs [ospfd] NSC CCS; daemon do Open Shortest Path First (ospfd)
2605 nsc-posa NSC POSA; daemon do Protocolo da Porta de
Comunicação da Divisa (bgpd)
2606 netmon [ospf6d] Dell Netmon; OSPF para o dameon do IPv6 (ospf6d)
2809 corbaloc Common Object Request Broker Architecture (CORBA)
nomeando localizador de serviços
3130 icpv2 Protocolo do Cache da Internet versão 2 (v2); usado pelo
servidor de caching do proxy Squid
3306 mysql Serviço de banco de dados MySQL
3346 trnsprntproxy Proxy transparente
4011 pxe serviço do Ambiente de Pré-execução (PXE -
Pre-execution Environment)
4321 rwhois Serviço remoto Whois (rwhois)
4444 krb524 tradutor de ticket do Kerberos versão 5 (v5) para a versão
4 (v4)
5002 rfe Sistema de transmissão de áudio Radio Free Ethernet
(RFE)
5308 cfengine Mecanismo de Configuração (Cfengine - Configuration
Engine)
5999 cvsup [CVSup] ferramenta de atualização e transferência de arquivos
CVSup
6000/tcp x11 [X] Serviços do Sistema X Window
7000 afs3-fileserver Servidor de arquivos do Sistema de Arquivo Andrew (AFS
- Andrew File System)
7001 afs3-callback porta AFS para callbacks do administrador do cache
7002 afs3-prserver banco de dados dos grupos e usuários do AFS
7003 afs3-vlserver banco de dados da localização de volumes do AFS
7004 afs3-kaserver serviço de autenticação do Kerberos para o AFS
7005 afs3-volser Servidor de administração dos volumes do AFS
7006 afs3-errors Serviço de interpretação de erros do AFS
7007 afs3-bos processo de supervisão básica do AFS
7008 afs3-update atualizador servidor-para-servidor do AFS
7009 afs3-rmtsys serviço de administração do cache remoto do AFS
9876 sd Diretor de Sessão para conferências multi-transmissão de
IPs
120 Apêndice C. Portas Comuns

Número da Nome Comentário


Porta / Camada

10080 amanda serviços de backup do Arquivador de Disco de Rede


Automático Maryland Avançado (Amanda - Advanced
Maryland Automatic Network Disk Archiver)
11371 pgpkeyserver Pretty Good Privacy (PGP) / servidor de chaves públicas
GNU Privacy Guard (GPG)
11720 h323callsigalt H.323 Call Signal Alternate
13720 bprd Daemon dos Pedidos de Backup de Rede Veritas (bprd -
NetBackup Request Daemon)
13721 bpdbm Administrador do Banco de Dados de Backup de Rede
Veritas (bpdbm - NetBackup Database Manager)
13722 bpjava-msvc Java do Backup de Rede Veritas / Protocolo do Microsoft
Visual C++ (MSVC)
13724 vnetd Utilitário de rede Veritas
13782 bpcd tBackupde Rede Veritas
13783 vopied Daemon de autenticação de VOPIE Veritas
22273 wnn6 [wnn4] Sistema de conversão Kana/Kanjic
26000 quake servidores de jogos multi-jogadores do Quake (e
relacionados)
26208 wnn6-ds Wnn6 Kana/Servidor Kanji
33434 traceroute ferramenta de rastreamento da rede Traceroute
Notas:
a. Comentário do /etc/services: "A porta 1236 está registrada como ‘bvcontrol’, mas
também é usada pelo servidor de configuração remota Gracilis Packeten. O nome oficial está
listado como o nome principal, e o nome não-registrado como codenome."
b. Comentário do /etc/services: "As portas numeradas de 2600 a 2606 são usadas pelo
pacote zebra sem serem registradas. Os nomes primários são nomes registrados e os nomes
não-registrados usados pelo zebra estão listados como codenomes (aliases)."
c. Nota do /etc/services: "Esta porta é registrada como wnn6, mas também é usada sob o
nome não-registrado ’wnn4’ pelo pacote FreeWnn."
Tabela C-3. Portas Registradas

A Tabela C-4 lista as portas relacionadas ao Protocolo de Entrega do Datagrama (DDP) usadas em
redes AppleTalk.

Número da Nome Comentário


Porta / Camada

1/ddp rtmp Protocolo de Administração da Tabela de Roteamento


2/ddp nbp Protocolo de Ligação de Nomes (Name Binding Protocol)

4/ddp echo Protocolo Echo do AppleTalk


Apêndice C. Portas Comuns 121

Número da Nome Comentário


Porta / Camada

6/ddp zip Protocolo de Informações da Zona


Tabela C-4. Portas do Protocolo de Entrega do Datagrama

A Tabela C-5 é uma lista das portas relacionadas ao protocolo de autenticação de rede Kerberos.
Onde estiver indicado, v5 refere-se ao protocolo do Kerberos versão 5. Note que estas portas não são
registradas na IANA.

Número da Nome Comentário


Porta / Camada

751 kerberos_master autenticação do Kerberos


752 passwd_server Servidor de Senha do Kerberos (kpasswd)
754 krb5_prop Propagação do Kerberos v5 escravo
760 krbupdate [kreg] registro do Kerberos
1109 kpop Protocolo Post Office do Kerberos (KPOP)
2053 knetd Des-multiplexador do Kerberos
2105 eklogin autenticação remota criptografada do Kerberos v5 (rlogin)

Tabela C-5. Portas do Kerberos (Projeto Athena/MIT)

Já a Tabela C-6 é uma lista de portas não-registradas que são usadas por serviços e protocolos que
podem ser/estar instalados no seu sistema Red Hat Enterprise Linux ou são necessários para a comu-
nicação entre o Red Hat Enterprise Linux e outros sistemas operacionais.

Número da Nome Comentário


Porta / Camada

15/tcp netstat Estado da Rede (netstat)


98/tcp linuxconf Ferramenta de Administração do Linux Linuxconf
106 poppassd Daemon de alteração da Senha do Protocolo Post Office
(POPPASSD)
465/tcp smtps Protocolo de Transferência de Correspondência Simples
sobre Secure Sockets Layer (SMTPS)
616/tcp gii Interface Interativa do Gated (daemon de roteamento)
808 omirr [omirrd] Serviços de espelhamento de arquivo Online Mirror
(Omirr)
871/tcp supfileserv Servidor do Protocolo de Atualização de Software
(Software Upgrade Protocol, SUP)
901/tcp swat Ferramenta de Administração Web do Samba (SWAT -
Samba Web Administration Tool)
122 Apêndice C. Portas Comuns

Número da Nome Comentário


Porta / Camada

953 rndc Ferramenta de configuração remota Berkeley Internet


Name Domain versão 9 (BIND 9)
1127/tcp supfiledbg Depuração do Protocolo de Atualização de Software (SUP
- Software Upgrade Protocol)
1178/tcp skkserv Kana Simples para Kanji (SKK) servidor de input em
Japonês
1313/tcp xtel Sistema de informações de texto French Minitel
1529/tcp suporte [prmsd, Sistema de rastreamento de erros GNATS
gnatsd]
2003/tcp cfinger Finger do GNU
2150 ninstall Serviço de Instalação de Rede
2988 afbackup sistema de backup cliente-servidor afbackup
3128/tcp squid Cache de proxy Squid Web
3455 prsvp porta RSVP
5432 postgres Banco de dados PostgreSQL
4557/tcp fax Serviço de transmissão de FAX (serviço antigo)
4559/tcp hylafax Protocolo cliente-servidor HylaFAX (serviço novo)
5232 sgi-dgl Biblioteca Gráfica Distribuída SGI
5354 noclog Daemon de autenticação do centro de operações de rede
NOCOL (noclogd - NOCOL network operation center
logging daemon)
5355 hostmon Monitoramento de máquina do centro de operações de
rede NOCOL
5680/tcp canna Interface do input dos caracteres Japoneses Canna
6010/tcp x11-ssh-offset Secure Shell (SSH) X11 forwarding offset
6667 ircd Daemon do Internet Relay Chat (ircd)
7100/tcp xfs Servidor de Fontes do X (XFS)
7666/tcp tircproxy Serviço proxy do IRC Tircproxy
8008 http-alt Protocolo de Transferência de Hipertexto (HTTP)
alternado
8080 webcache Serviço de caching da World Wide Web (WWW)
8081 tproxy Proxy Transparente
9100/tcp jetdirect [laserjet, Serviço de impressão de rede da Hewlett-Packard (HP)
hplj] JetDirect
9359 mandelspawn Programa de spawning Parallel Mandelbrot para o Sistema
[mandelbrot] X Window
10081 kamanda Serviço de backup Amanda sobre o Kerberos
Apêndice C. Portas Comuns 123

Número da Nome Comentário


Porta / Camada

10082/tcp amandaidx Servidor de índice Amanda


10083/tcp amidxtape Serviços de fita Amanda
20011 isdnlog Sistema de autenticação da Rede Digital de Serviços
Integrados (ISDN - Integrated Systems Digital Network)
20012 vboxd Daemon da caixa de voz da ISDN (vboxd - voice box
dameon)
22305/tcp wnn4_Kr Sistema de input Coreano kWnn
22289/tcp wnn4_Cn Sistema de input Chinês cWnn
22321/tcp wnn4_Tw Sistema de input Chinês tWnn (Taiwan)
24554 binkp Daemon de correspondência Binkley TCP/IP Fidonet
27374 asp Protocolo de Busca de Endereços
60177 tfido Serviço de correspondência compatível ao FidoNet Ifmail
60179 fido Rede de notícias e correspondência eletrônica FidoNet
Tabela C-6. Portas Não-registradas
124 Apêndice C. Portas Comuns
Índice Remissivo cupsd, 37

Símbolos D
802.11x, 103 dd
e segurança, 103 auditoria de arquivos usando, 94
ética do hacker, 9 coletando evidências com, 94
Denial of Service - DoS (Negação de Serviço)
distribuídos, 4
A DMZ
(Ver Zona Desmilitarizada (Demilitarized Zone))
atacantes e riscos, 9 (Ver networks)
ative sua assinatura, v
atualizações
(Ver erratas de segurança) E
auditoria de arquivos
ferramentas, 94 equipe de resposta a emergências de computador, 92
erratas de segurança, 17
aplicando alterações, 20
B através do site de erratas da Red Hat, 18
quando reinicializar, 20
BIOS via Red Hat Network, 17
não-equivalentes ao x86 exploits e ataques comuns, 107
senhas, 24 tabela, 107
segurança, 23
senhas, 23
F
C Ferramenta de Configuração dos Serviços, 37
ferramentas de comunicação
coletando evidências
seguras, 40
(Ver resposta ao incidente)
GPG, 40
ferramentas de auditoria de arquivos, 94
OpenSSH, 40
dd, 94
file
file, 94
auditoria de arquivos usando, 94
find, 94
find
grep, 94
auditoria de arquivos usando, 94
md5sum, 94
firewalls, 65
script, 93
stat, 94 de estado, 72
strings, 94 e registro de conexão, 72
considerações de segurança e vírus, 71
hardware, 101 iptables, 66
redes físicas, 101 normas, 67
sem-fio, 103 pessoal, 39
transmissão de rede, 102 recursos adicionais, 73
controles, 5 tipos, 65
administrativos, 6 FTP
físicos, 6 acesso anônimo, 50
técnicos, 6 apresentando, 49
convenções banner de saudação, 49
documentos, ii contas de usuário, 51
cracker TCP wrappers e, 51
hacker de chapéu preto, 9 upload anônimo, 50
crackers vsftpd, 49
definição, 9
126

G inspeção de estado, 72
estados, 72
gestores de início
normas, 67
GRUB
recursos adicionais, 73
senha protegendo, 24
registro de conexão, 72
segurança, 24
estados, 72
grep regras, 68
auditoria de arquivos usando, 94 comum, 68
encaminhamento (forwarding), 69
NAT, 70, 71
H restaurando, 68
hacker de chapéu b ranco salvando, 68
(Ver hackers) usando, 67
hacker de chapéu cinza
(Ver hackers)
hacker de chapéu preto K
(Ver crackers) Kerberos
hackers NIS, 47
chapéu branco, 9
chapéu cinza, 9
chapéu preto L
(Ver cracker)
definição, 9 lpd, 37
hardware, 101 lsof, 53
e segurança, 104
estações de trabalho, 104
laptops, 104 M
servidores, 104 md5sum
auditoria de arquivos usando, 94
módulos de autenticação plugáveis (pluggable authen-
I tication modules - PAM)
idade da senha, 29 forçando uma senha forte, 28
IDS
(Ver sistemas de detecção de invasão)
introdução, i N
categorias, usando este manual, i NAT
outros manuais do Red Hat Enterprise Linux, i (Ver Tradução do Endereço de Rede (Network Ad-
tópicos, i dress Translation - NAT))
ip6tables, 72 Nessus, 80
IPsec, 56 Netfilter, 66
configuração, 60 recursos adicionais, 73
máquina-a-máquina, 57 Netfilter 6, 72
fases, 56 netstat, 53
instalando, 56 NFS, 47
máquina-a-máquina, 57 e Sendmail, 52
rede-a-rede, 60 erros de sintaxe, 47
iptables, 66 planejamento de rede, 47
correntes, 67 Nikto, 81
FORWARD, 69 NIS
INPUT, 68 apresentando, 45
OUTPUT, 68 IPTables, 46
POSTROUTING (pós-roteamento), 70 Kerberos, 47
PREROUTING (pré-roteamento), 70, 71 nome de domínio do NIS, 45
e DMZs, 71 planejando a rede, 45
e vírus, 71 portas estáticas, 46
127

securenets, 46 criando um plano, 91


nmap, 53, 80
definição de, 91
versão linha de comando, 80
e questões legais, 92
equipe de resposta a emergências de computador
O (computer emergency response team - CERT), 92
OpenSSH, 40 implementação, 93
scp, 40
introduzindo, 91
sftp, 40
ssh, 40 investigação, 93
post-mortem, 93

P reportando o incidente, 97
restaurando e recuperando recursos, 96
plano de resposta ao incidente, 91
portas restaurando e recuperando recursos, 96
comuns, 111
consertando o sistema (patching), 96
monitorando, 53
portas comuns reinstalando o sistema, 96
tabela, 111 riscos
portas de comunicação, 111
portmap, 37 consertos e erratas, 11
e IPTables, 44 estações de trabalho e PCs, 12, 12
e TCP wrappers, 44
aplicações, 12
post-mortem, 93
portas abertas, 10
redes, 10
Q
arquiteturas, 10
questões legais, 92
servidores, 10
administração desatenta, 11
R serviços inseguros, 11
redes, 101 root, 31
comutadores, 102
e segurança, 101 desativar acesso, 31
hubs, 102 limitar acesso, 34
segmentação, 104
com Administrador de Usuários, 34
sem-fio, 103
zonas desmilitarizadas (de-militarized zones - e o su, 34
DMZs), 104 e o sudo, 35
Redes Privadas Virtuais (Virtual Private Networks),
55 métodos de desativação, 31
IPsec, 56 alterar a shell root, 33
configuração, 60
com PAM, 33
instalando, 56
máquina-a-máquina, 57 impossibilitar autenticações SSH, 33
Redes Wi-Fi
permitindo acesso, 31
(Ver 802.11x)
registre sua assinatura, v RPM
registro da assinatura, v e detecção de intrusão, 86
reportando o incidente, 97
resposta ao incidente importando a chave GPG, 18
coletando evidências verificando pacotes assinados, 18, 19
usando o dd, 94
coletando informação pós-infração, 94
128

S xinetd, 43
gerenciando recursos com, 43
segurança da estação de trabalho, 23
prevenindo DoS (recusa de serviço) com, 43
avaliando
SENSOR armadilha, 43
BIOS, 23
segurança sem-fio, 103
comunicações, 23
802.11x, 103
controle administrativo, 23
sendmail, 37
firewalls pessoais, 23
apresentando, 52
gestores de início, 23
e NFS, 52
senhas, 23
limitando DoS, 52
BIOS, 23
senhas
gestores de início
dentro de uma empresa, 28
senhas, 24
Servidor HTTP Apache
segurança da senha, 25
apresentando, 48
e PAM, 28
diretivas, 48
em uma empresa, 28
segurança cgi, 49
ferramentas de auditoria, 29
serviços, 53
Crack, 29
John the Ripper, 29 serviços de co-locação, 104
Slurpie, 29 serviços de rede, 36
forçando, 28 identificando e configurando, 37
idade, 29 riscos, 36
metodologia, 28 denial-of-service (negação de serviço), 36
senhas fortes, 26 sobrecarga do buffer, 36
segurança do servidor vulnerabilidade do script, 36
FTP, 49 sobrecarga do buffer
acesso anônimo, 50 ExecShield, 37
banner de saudação, 49 serviços inseguros, 38
contas de usuário, 51 rsh, 38
TCP wrappers e, 51 Telnet, 38
upload anônimo, 50 vsftpd, 38
vsftpd, 49 Shell EFI
NFS, 47 segurança
erros de sintaxe, 47 senhas, 24
planejamento de rede, 47 sistema básico de input e output
NIS, 45 (Ver BIOS)
IPTables, 46 sistemas de detecção de invasão, 85
Kerberos, 47 baseado em rede, 88
nome de domínio do NIS, 45 Snort, 90
planejando a rede, 45 baseado no servidor, 86
portas estáticas, 46 definindo, 85
securenets, 46 e arquivos de registro, 86
portas Gestor de Pacotes RPM (RPM), 86
monitorando, 53 tipos, 85
portmap, 44 Tripwire, 86
Sendmail, 52 Snort, 90
e NFS, 52 sshd, 37
limitando DoS, 52 stat
Servidor HTTP Apache, 48 auditoria de arquivos usando, 94
diretivas, 48 strings
segurança cgi, 49 auditoria de arquivos usando, 94
TCP wrappers, 41 su
alertas de ataque, 42 e root, 34
banners, 41 sudo
registro, 42 e root, 35
visão geral da, 41
129

T X
TCP wrappers xinetd, 37
alertas de ataque, 42 gerenciando recursos com, 43
banners, 41 prevenindo DoS (recusa de serviço) com, 43
e FTP, 51 SENSOR armadilha, 43
e portmap, 44
registro, 42
tipos de firewall, 65
Z
filtro de pacotes, 65 Zona Desmilitarizada (Demilitarized Zone), 71
proxy, 65
tradução do endereço da rede (network address
translation - NAT), 65
topologias de rede, 101
canal linear (linear bus), 101
estrela (star), 101
ring, 101
Tradução do Endereço de Rede (Network Address
Translation - NAT), 69
com iptables, 69
Tripwire, 86

U
usuário root
(Ver root)

V
visão geral, 1
visão geral de segurança, 1
conclusão, 7
controles
(Ver controles)
definindo segurança em computadores, 1
Denial of Service - DoS (Negação de Serviço), 4
evolução da segurança em computadores, 1
vírus, 4
VLAD the Scanner, 81
VPN, 55
vulnerabilidades
avaliando com Nessus, 80
avaliando com Nikto, 81
avaliando com Nmap, 80
avaliando com o VLAD the Scanner, 81
estimativa, 77
definindo, 78
estabelecendo uma metodologia, 79
testes, 78
vírus
trojans, 4
Considerações finais
Os manuais são escritos no formato DocBook SGML versão 4.1. Os formatos HTML e PDF são pro-
duzidos usando stylesheets DSSSL personalizadas e scripts jade wrapper personalizados. Os arquivos
SGML do DocBook são escritos em Emacs com o auxílio do modo PSGML.
Garrett LeSage criou as imagens de alerta (nota, dica, importante, atenção e aviso). Elas podem ser
distribuídas livremente com a documentação da Red Hat.
A Equipe de Documentação de Produtos da Red Hat Linux é composta pelas seguintes pessoas:
Sandra A. Moore — Autora Principal/Mantenedora do Red Hat Enterprise Linux Guia de Instalação
para sistemas x86, Itanium™, AMD64 e Intel® Extended Memory 64 Technology (EM64T da Intel®);
Autora Principal/Mantenedora do Red Hat Enterprise Linux Guia de Instalação para Arquitetura
POWER da IBM®; Autora Principal/Mantenedora do Red Hat Enterprise Linux Guia de Instalação
para as Arquiteturas IBM® S/390® e IBM® eServer™ zSeries®
John Ha — Autor Principal/Mantenedor do Configurando e Administrando um Cluster do Red Hat
Cluster Suite; Co-autor/Co-mantenedor do Guia de Segurança do Red Hat Enterprise Linux; Man-
tenedor dos stylesheets e scripts DocBook personalizados
Edward C. Bailey — Autor Principal/Mantenedor do Introdução à Administração de Sistemas Red Hat
Enterprise Linux; Autor Principal/Mantenedor das Notas de Versão; Autor contribuinte do Guia de
Instalação para sistemas x86, Itanium™, AMD64 e Intel® Extended Memory 64 Technology (EM64T
da Intel®) do Red Hat Enterprise Linux
Karsten Wade — Autora Principal/Mantenedora do Red Hat SELinux Guia do Desenvolvimento de
Aplicações; Autora Principal/Mantenedora do Red Hat SELinux Guia das Normas de Escrita
Andrius Benokraitis — Autor Principal/Mantenedor do Guia de Referência do Red Hat Enterprise
Linux; Co-autor/Co-mantenedor do Guia de Segurança do Red Hat Enterprise Linux; Autor Con-
tribuinte do Guia de Administração de Sistemas Red Hat Enterprise Linux
Paul Kennedy — Autor Principal/Mantenedor do Guia do Administrador do Red Hat GFS; Autor
Contribuinte do Configurando e Administrando um Cluster do Red Hat Cluster Suite
Mark Johnson — Autor Principal/Mantenedor do Guia de Administração e Configuração do Desktop
Red Hat Enterprise Linux
Melissa Goldin — Autora Principal/Mantenedora do Guia Passo a Passo do Red Hat Enterprise Linux
A Equipe de Internacionalização da Red Hat é composta pelas seguintes pessoas:
Amanpreet Singh Alam — traduções para Punjabi
Jean-Paul Aubry — traduções para o Francês
David Barzilay — traduções para o Português Brasileiro
Runa Bhattacharjee — traduções para Bengali
Chester Cheng — traduções para o Chinês Tradicional
Verena Fuehrer — traduções para o Alemão
Kiyoto Hashida — traduções para o Japonês
N. Jayaradha — traduções para Tamil
Michelle Jiyeen Kim — traduções para o Coreano
Yelitza Louze — traduções para o Espanhol
Noriko Mizumoto — traduções para o Japonês
Ankitkumar Rameshchandra Patel — traduções para Gujarati
Rajesh Ranjan — traduções para Hindi
132

Nadine Richter — traduções para o Alemão


Audrey Simons — traduções para o Francês
Francesco Valente — traduções para o Italiano
Sarah Wang — traduções para o Chinês Simplificado
Ben Hung-Pin Wu — traduções para o Chinês Tradicional