red hat enterprise linux 4 guia de segurança -...

Red Hat Enterprise Linux 4

Guia de Segurança

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

Red Hat, Inc.

1801 Varsity Drive Raleigh NC 27606-2072USA 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 ’OpenPublication License’, versão 1.0 ou mais recente (a versão mais recente está disponível emhttp://www.opencontent.org/openpub/).É proibida a distribuição de versões substancialmente modificadas deste documento sem a permissão explícita do titular dosdireitos autorais.É proibida a distribuição total ou parcial do trabalho envolvido neste manual, em qualquer formato de livro (papel), para finscomerciais, 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 [email protected] é:CA 20 86 86 2B D6 9D FC 65 F6 EC C4 21 91 80 CD DB 42 A6 0E

ÍndiceIntrodução ............................................................................................................................................ i

1. Informações específicas da arquitetura ................................................................................. ii2. Convenções de Documentos ................................................................................................. ii3. Ative Sua Assinatura............................................................................................................. v

3.1. Prover um Login para a Red Hat ........................................................................... v3.2. Prover Seu Número de Assinatura ......................................................................... v3.3. Conectar Seu Sistema ............................................................................................ v

4. Mais por vir.......................................................................................................................... vi4.1. Envie-nos Seu Feedback ....................................................................................... vi

I. Uma Introdução Genérica à Segurança ......................................................................................... i1. Visão Geral de Segurança ..................................................................................................... 1

1.1. O que é Segurança em Computadores? ................................................................. 11.2. Controles de Segurança.......................................................................................... 51.3. Conclusão............................................................................................................... 6

2. Atacantes e Vulnerabilidades ................................................................................................ 92.1. Uma Breve História sobre Hackers........................................................................ 92.2. Ameaças à Segurança da Rede ............................................................................ 102.3. Ameaças à Segurança do Servidor....................................................................... 102.4. Ameaças à Segurança da Estação de Trabalho e PC Pessoal............................... 12

II. Configurando o Red Hat Enterprise Linux para Segurança................................................... 153. Atualizações de Segurança ................................................................................................. 17

3.1. Atualizando Pacotes............................................................................................. 174. Segurança da Estação de Trabalho...................................................................................... 23

4.1. Avaliando a Segurança da Estação de Trabalho................................................... 234.2. Segurança do BIOS e do Gestor de Início ........................................................... 234.3. Segurança da Senha ............................................................................................. 254.4. Controles Administrativos ................................................................................... 304.5. Serviços de Rede Disponíveis.............................................................................. 364.6. Firewalls Pessoais ................................................................................................ 394.7. Ferramentas de Comunicação de Segurança Aprimorada ................................... 39

5. Segurança do Servidor ........................................................................................................ 415.1. Protegendo Serviços com TCP Wrappers e xinetd ........................................... 415.2. Protegendo o Portmap.......................................................................................... 445.3. Protegendo o NIS................................................................................................. 455.4. Protegendo o NFS................................................................................................ 475.5. Protegendo o Servidor HTTP Apache ................................................................. 485.6. Protegendo o FTP ................................................................................................ 495.7. Protegendo o Sendmail ........................................................................................ 515.8. Verificando Quais Portas estão Escutando........................................................... 52

6. Redes Privadas Virtuais (Virtual Private Networks) ........................................................... 556.1. VPNs e Red Hat Enterprise Linux ....................................................................... 556.2. IPsec..................................................................................................................... 556.3. Instalação do IPsec............................................................................................... 566.4. Configuração Máquina-a-Máquina do IPsec ....................................................... 566.5. Configuração Rede-a-Rede do IPsec ................................................................... 60

7. Firewalls.............................................................................................................................. 657.1. Netfilter e iptables ........................................................................................... 667.2. Usando o iptables ............................................................................................ 677.3. Filtragem Comum do iptables......................................................................... 687.4. Regras FORWARD e NAT....................................................................................... 697.5. Vírus e Endereços IP Espionados (spoofed)........................................................ 717.6. iptables e Registro de Conexão ....................................................................... 727.7. ip6tables .......................................................................................................... 72

7.8. Recursos Adicionais............................................................................................. 73III. Avaliando Sua Segurança .......................................................................................................... 75

8. Avaliação de Vulnerabilidade ............................................................................................. 778.1. Pensando Como o Inimigo................................................................................... 778.2. Definindo Avaliação e Testes ............................................................................... 788.3. Avaliando as Ferramentas .................................................................................... 79

IV. Intrusões e Resposta a Incidentes ............................................................................................. 839. Detecção de Invasão............................................................................................................ 85

9.1. Definindo Sistemas de Detecção de Intrusão....................................................... 859.2. IDS baseado no servidor ...................................................................................... 869.3. IDS baseado em rede ........................................................................................... 88

10. Resposta ao Incidente ....................................................................................................... 9110.1. Definindo Resposta ao Incidente ....................................................................... 9110.2. Criando um Plano de Resposta ao Incidente...................................................... 9110.3. Implementando o Plano de Resposta ao Incidente ............................................ 9310.4. Investigando o Incidente .................................................................................... 9310.5. Restaurando e Recuperando Recursos ............................................................... 9610.6. Reportando o Incidente ...................................................................................... 97

V. Apêndices ...................................................................................................................................... 99A. Proteção ao Hardware e à Rede ....................................................................................... 101

A.1. Topologias de Rede Segura............................................................................... 101A.2. Segurança de Hardware..................................................................................... 104

B. Exploits e Ataques Comuns ............................................................................................. 107C. Portas Comuns ................................................................................................................. 111

Índice Remissivo.............................................................................................................................. 125Consideraçõ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 RedHat 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 RedHat Enterprise Linux detalha o planejamento e as ferramentas envolvidas na criação de um ambientecomputacional seguro para o centro de dados (data center), ambiente de trabalho e doméstico. Com oconhecimento, vigilância e ferramentas apropriados, os sistemas rodando o Red Hat Enterprise Linuxpodem 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 edeseja mais informações sobre como utilizar o sistema, por favor consulte os seguintes manuais, queabordam os aspectos fundamentais do Red Hat Enterprise Linux de forma mais detalhada que o Guiade 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 detalhadassobre como configurar o Red Hat Enterprise Linux para servir suas necessidades particulares comousuá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 dosusuá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 HatEnterprise 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 RedHat Enterprise Linux para acessar as informações que não estavam disponíveis antes da finalizaçãode 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 arquiteturaExceto 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 (EM64Tda 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 DocumentosAo ler este manual, determinadas palavras estão representadas com fontes, tipos, tamanhos e pesosdiferentes. Este destaque é sistemático; palavras diferentes são representadas no mesmo estilo paraindicar sua inclusão em uma categoria específica. Os tipos de palavras representadas desta maneiraincluem 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 decomandos e pressionar [Enter] para invocar um comando. Às vezes o comando contém palavrasque 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 aquelenome no seu sistema. Exemplos:

O arquivo .bashrc do seu diretório ’home’ contém definições da janela de comandos tipo bashe 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 doservidor Web.

aplicaçãoEste estilo indica que o programa é uma aplicação direcionada ao usuário final (ao contrário dosoftware 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 estaletra.

[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 aoconsole 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 textoexibido neste estilo é usado na identificação de uma tela GUI específica ou um elemento de umatela 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 soliciteuma senha antes de ser desbloqueado.

nível superior de um menu em uma tela ou janela GUIUma 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 avocê 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 exibidoscomo o exemplo a seguir:

Vá para Botão do Menu Principal (no Painel) => Programação => Emacs para iniciar o editorde texto Emacs.

botão em uma tela ou janela GUIEste estilo indica que o texto pode ser encontrado em um botão clicável de uma tela GUI. Porexemplo:

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 erespostas a comandos. Por exemplo:

O comando ls exibe o conteúdo de um diretório:Desktop about.html logs paulwesterberg.pngMail backupfiles mail reports

O output exibido em resposta ao comando (neste caso, o conteúdo do diretório) é apresentadoneste 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árioO texto que o usuário precisa digitar, na linha de comandos ou em uma caixa de texto em umatela 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ãoapresentados neste estilo. No exemplo a seguir, � version-number � é exibido neste estilo:

O diretório da fonte do kernel é /usr/src/ � version-number � /, onde� version-number � é a versão do kernel instalado neste sistema.

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, elassã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 seusistema.

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. Removeroutras partições pode resultar na perda de dados ou num ambiente de sistema corrompido.

3. Ative Sua AssinaturaAntes de poder acessar as informações de manutenção do software e serviços, e a documentação desuporte inclusa em sua assinatura, você deve ativar sua assinautra registrando-a na Red Hat. O registroinclui 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 deregistro na Red Hat usando o Agente de Configuração. Se você seguir os pedidos durante o Agentede 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 requeracesso à 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 HatSe você ainda não possui um login para a Red Hat, pode criá-lo quando for solicitado no Agente deConfiguraçã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) daRed 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 AssinaturaSeu número de assinatura está localizado no pacote que acompanha seu pedido. Caso seu pacote nãoinclua 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 ouvisitando http://www.redhat.com/register/.

vi Introdução

3.3. Conectar Seu SistemaO Cliente de Registro da Red Hat Network auxilia na conexão de seu sistema para que você possaobter 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 hardwaree Enviar lista de pacotes do sistema quando aparecerem.

2. Após completar o Agente de Configuração — No Menu Principal, clique em Ferramentasdo Sistema, e então selecione Red Hat Network.

3. Após completar o Agente de Configuração — Invoque o seguinte na janela de comandos comousuário root:

• /usr/bin/up2date --register

4. Mais por virO Guia de Segurança do Red Hat Enterprise Linux é parte do crescente comprometimento da RedHat 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 paraincluí-las.

4.1. Envie-nos Seu FeedbackSe você encontrar um erro de digitação no Guia de Segurança do Red Hat Enterprise Linux ou sepensar 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 parapodermos 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 emtorno desta questão. Também aborda alguns dos riscos enfrentados por usuários e administradores decomputadores.

Índice1. Visão Geral de Segurança .............................................................................................................. 12. 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 controlede nossas informações pessoais, as indústrias têm sido constituídas com a prática de segurança noscomputadores e nas redes. Empreendimentos têm solicitado o conhecimento e habilidades de peritosem segurança para auditar sistemas apropriadamente e customizar soluções para os requerimentosoperacionais das organizações. Já que a maioria das organizações são dinâmicas por natureza, comfuncionários acessando os recursos de IT da empresa localmente e remotamente, a necessidade deambientes de rede seguros se tornou ainda mais acentuada.

Infelizmente, a maioria das empresas (assim como usuários individuais) encaram a segurança comouma 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 aInternet - é 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çõesdiárias de negócios e acessar informações cruciais, encaram seus dados como uma parte importante deseus recursos. Diversos termos e medidas foram inseridos em nosso cotidiano, tais como custo total depropriedade (total cost of ownership - TCO) e qualidade de serviço (quality of service - QoS). Nestasmedidas, setores calculam aspectos como integridade de dados e alta disponibilidade como parte deseus custos de planejamento e gerenciamento de processos. Em alguns setores, tal como comércioeletrô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 umestudante colegial que invade o supercomputador do Departamento de Defesa dos EUA (Departmentof Defense - DoD), e inadvertidamente causa uma ameaça nuclear. Neste filme, Broderick usa seumodem 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 durantea "guerra fria" entre a ex União Soviética e os EUA e foi considerado um sucesso em seu lançamentoem 1983. A popularidade do filme inspirou muitas pessoas e grupos a começar a implementar algunsdos 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 modemanaló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 (FederalBureau of Investigation) e a ajuda de profissionais de computação em todo o país, o notório crackerKevin 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 comoo maior crime relacionado a computadores na história dos EUA. Ele foi condenado e sentenciado a68 meses de prisão por seus crimes, dos quais serviu 60 meses antes de sua condicional em 21 deJaneiro de 2000. Ele foi proibido de usar computadores ou prestar qualquer consultoria relacionada acomputadores até 2003. Investigadores dizem que Mitnick era perito em engenharia social — utilizarindiví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úblicaspara expor informações pessoais, financeiras e outras informações restritas. Há diversos casos comoo de Mitnick e o de Vladamir Levin (consulte a Seção 1.1.2 para mais informações) que surgiram emempresas de todos os setores para repensar a maneira com que lidam com a transmissão e exposição deinformações. A popularidade da Internet foi um dos aspectos mais importantes que exigiu um esforçointenso na segurança de dados.

Um número cada vez maior de pessoas está utilizando seu computador pessoal para acessar os recursosque a Internet oferece. De pesquisas e recuperação de informações a correspondência eletrônica etransações comerciais, a Internet é considerada um dos desenvolvimentos mais importantes do séculoXX.

A Internet e seus protocolos mais antigos, no entanto, foram desenvolvidos como um sistema baseadona 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-oaberto 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 enos alertam para o fato de que nada é completamente seguro.

1.1.2. Cronologia da Segurança em ComputadoresDiversos 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 dainformaçã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ânicode cifras que converte mensagens puramente texto em um resultado criptografado. Desenvolvidooriginalmente 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 chamadoAlan Turing desenvolve um método para quebrar os códigos da Enigma, possibilitando às forçasaliadas 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-1da 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 PesquisaAvançada (Advanced Research Projects Agency Network - ARPANet), que ganha popularidadeem pesquisas e círculos acadêmicos como um condutor do intercâmbio eletrônico de informaçõese dados. Isto pavimentou o caminho para a criação da rede de transporte conhecida hoje comoInternet.

• Ken Thompson desenvolve o sistema operacional UNIX, amplamente aclamado como o sistemaoperacional 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, DennisRitchie 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 ogoverno e indústria, desenvolve o protocolo Telnet, uma extensão pública da ARPANet. Isto abreportas para o uso público de redes de dados antes restritas a empresas do governo e pesquisadoresacadêmicos. O Telnet, no entanto, também é discutivelmente o protocolo mais inseguro para redespú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 maldososaprenderem a arte do cracking remoto em sistemas, usando hardware de comunicação comum dePC, 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 maisconhecidos 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 arquiteturarelativamente barata que trouxe a computação do escritório para casa. Isto serve para transformar oPC numa ferramenta comum e acessível, que era relativamente poderosa e fácil de usar, ajudando aproliferaçã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 VintCerf, é dividido em duas partes distintas. O Protocolo de Internet (IP) surge desta divisão, e oprotocolo 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 eredes de computadores para uma grande audiência.

• A gang 414 (assim nomeada em função do código de área de onde haqueava) é surpreendida pelasautoridades após nove dias de cracking no qual a gang violou os sistemas de uma localizaçãoaltamente 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 quecomeç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 votadoe transformado em lei pelo congresso americano baseado nos exploits de Ian Murphy, tambémconhecido com Capitão Zap, que violou computadores militares, roubou informações de bancosde dados de pedidos de mercadorias e utilizou os quadros restritos de distribuição de telefone dogoverno 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 colegialque 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 Equipede Resposta a Emergências de Computador (Computer Emergency Response Team - CERT) paraalertar 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.


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. Oamplo desenvolvimento e adoção do Linux se deve, em grande parte, à colaboração e comunicaçãode usuários e desenvolvedores via Internet. Devido às suas raízes no Unix, o Linux é mais popularentre hackers e administradores que o consideram muito útil para elaborar alternativas seguras paraservidores legados que rodam sistemas operacionais proprietários (com código fechado).

• O navegador (browser) gráfico é criado e estimula uma demanda exponencialmente alta por acessopúblico à Internet.

• Vladimir Levin é cúmplice da transfência ilegal de US$10 milhões em fundos para diversas contascrackeando o banco de dados central do CitiBank. Levin é preso pela Interpol e quase todo odinheiro é recuperado.

• Possivelmente, o precursor de todos os crackers é Kevin Mitnick, que hackeou diversos sistemascorporativos roubando tudo - de informações pessoais de celebridades a mais de 20.000 númerosde cartões de crédito e código fonte de software proprietário. Ele é preso, condenado por fraude efica 5 anos na prisão.

• Kevin Poulsen e um cúmplice desconhecido manipulam sistemas de telefonia de uma estação derádio para ganhar carros e prêmios em dinheiro. Ele é condenado por fraude e sentenciado a 5 anosde prisão.

• As histórias de cracking e phreaking se tornam lendas; e muitos crackers em potencial se reúnemna 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 sistemasdo 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. Ogoverno britânico eventualmente se apropria do controle dos satélites.

1.1.3. A Segurança HojeEm 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íveispara 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 programascriados 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 osservidores infectados inundando os sites vítimas e tornando-os indisponíveis. Muitos culparam oataque à obsolescência da maneira como roteadores e protocolos usados são estruturados para aceitartodos 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 ouusaram a Internet ao redor do mundo (Computer Industry Almanac, 2004). Ao mesmo tempo:


• 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 de52.658 em 2001.2

• O impacto econômico am nível mundial dos três vírus mais perigosos da Internet nos últimos trêsanos 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 confiabilidadede seus sistemas, serviços e informações 24 horas por dia, sete dias por semana. Cair nas mãos deusuá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 conhecimentocomplexo de como a empresa encara, usa, manipula e transmite suas informações. Entender a maneiracomo 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çaEmpresas de todos os setores dependem de regulamentações e padrões definidos por associações comoa 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 mesmasidéias valem para a segurança da informação. Muitas consultorias e fabricantes da área de segurançaconcordam 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 estabeleceruma 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 financeirasde um cliente não sejam obtidas por um indivíduo não autorizado para propósitos maldosos comoroubo 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çõesdelicadas.

• 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 edefinido formalmente nos Acordos de Nível de Serviço (Service Level Agreements - SLAs) usadospor provedores de serviços de rede e seus clientes corporativos.

1.2. Controles de SegurançaA segurança em computadores é frequentemente dividida em três categorias principais, comumentereferidas como controles:

1. Fonte: http://www.cert.org2. Fonte: http://www.cert.org/stats/3. Fonte: http://www.newsfactor.com/perl/story/16407.html


• Físicos

• Técnicos

• Administrativos

Estas três categorias abrangentes definem os objetivos principais de uma implementação de segurançaapropriada. Dentre estes controles há sub-categorias que detalham minuciosamente os controles ecomo implementá-los.

1.2.1. Controles FísicosO controle físico é a implementação de medidas de segurança em uma estrutura definida usada paradeter 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 automatizadosusados para reconhecer indivíduos)

1.2.2. Controles TécnicosO controle técnico uitiliza a tecnologia como base para controlar o acesso e o uso de dados delicadosatravés de uma estrutura física e através de uma rede. Os controles técnicos têm um escopo de grandealcance 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 AdministrativosOs controles administrativos definem os fatores humanos da segurança. Envolvem todos os níveis depessoal 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


1.3. ConclusãoAgora que você aprendeu um pouco sobre as origens, razões e aspectos da segurança, pode determinaro curso de ações apropriado em relação ao Red Hat Enterprise Linux. É importante saber quais fatorese condições compoem a segurança para planejar e implementar uma estratégia apropriada. Com estasinformacões em mente, o processo pode ser formalizado e o caminho torna-se mais claro conformevocê aprofundar nas especificidades do processo de segurança.

Capítulo 2.Atacantes e Vulnerabilidades

Para planejar e implementar uma boa estratégia de segurança, primeiramente saiba de algumas dasrazões que motivaram atacantes a explorar e comprometer sistemas. Mas antes de detalhar estasquestões, precisamos definir a terminologia utilizada ao identificar um atacante.

2.1. Uma Breve História sobre HackersO 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 edetalhes complexos. Hacker era o nome usado para os membros do clube que descobriram um novotruque 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çõesdos sistemas e redes de computador com pouco ou nenhum estímulo exterior. Desenvolvedores desoftware open source geralmente consideram seus colegas e a si próprios como hackers e utilizamesta 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 paracom a comunidade. Durante esta missão por conhecimento, alguns hackers se divertem com desafiosacadêmicos em furar controles de segurança em sistemas de computadores. Por esta razão, a imprensacomumente usa o termo hacker para descrever aqueles que acessam sistemas e redes ilicitamente comintenções inescrupulosas, madosas ou criminosas. O termo mais correto para este tipo de hacker decomputador é cracker — um termo criado por hackers em meados dos anos 80 para diferenciar asduas comunidades.

2.1.1. Tonalidades de CinzaHá diversos grupos distintos de indivíduos que encontram e exploram vulnerabilidades em redes esistemas. Eles são descritos pela tonalidade do chapéu que "vestem" ao realizar suas investigações emsegurança, e essa tonalidade indica suas intenções.

O hacker de chapéu branco é aquele que testa redes e sistemas para examinar sua performance edeterminar o quão vulneráveis são às intrusões. Geralmente, hackers de chapéu branco violam seuspró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 dechapéu branco.

Um hacker de chapéu preto é sinônimo de um cracker. Em geral, crackers são menos focados emprogramação e no lado acadêmico de violar sistemas. Eles comumente confiam em programas decracking e exploram vulnerabilidades conhecidas em sistemas para descobrir informações importantespara 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éubranco 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 vesteum 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 violarsistemas 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 RedePráticas ruins ao configurar os seguintes aspectos de uma rede podem aumentar os riscos de um ataque.

2.2.1. Arquiteturas InsegurasUma rede mal configurada é um ponto de entrada básico para usuários não autorizados. Deixar umarede local aberta baseada na confiança e vulnerável à Internet, altamente insegura, é o mesmo quedeixar 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ãoAdministradores de sistemas frequentemente falham em perceber a importância do hardware de redeem 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 dadosatravés da rede para um nódulo receptor, o hub ou roteador envia uma transmissão dos pacotes dedados até que o nódulo receptor receba e processe os dados. Este método é o mais vulnerável paralidar com protocolo de resolução (arp) ou controle de acesso à mídia (media access control - MAC), elidar com spoofing de endereços de ambos - intrusos externos e usuários não autorizados em máquinaslocais.

2.2.1.2. Servidores CentralizadosOutra potencial armadilha na rede é o uso da computação centralizada. Uma forma comum de cortede 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 deservidores múltiplos. No entanto, um servidor centralizado apresenta apenas um ponto único de falhana rede. Se o servidor central for comprometido, pode danificar a rede ou inutilizá-la, um cenáriopropício para a manipulação ou roubo de dados. Nestas situações um servidor central torna-se umaporta aberta, permitindo acesso à toda rede.

2.3. Ameaças à Segurança do ServidorA 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 AbertasUma instalação completa do Red Hat Enterprise Linux contém mais de 1000 aplicações e pacotesde bibliotecas. No entanto, a maioria dos adminstradores de servidor não optam por instalar todosos pacotes da distribuição; preferem, ao invés disso, instalar os pacotes básicos, incluindo diversasaplicações para servidor.

Capítulo 2. Atacantes e Vulnerabilidades 11

Uma ocorrência comum dentre administradores de sistemas é instalar o sistema operacional semprestar atenção em quais pacotes realmente estão sendo instalados. Isto pode ser problemático, poisserviços desnecessários podem ser instalados, configurados com opções default e possivelmenteacionados. Isto pode fazer com que serviços não quistos, como Telnet, DHCP ou DNS, sejamexecutados em um servidor ou estação de trabalho sem que o adminstrador perceba, o que podecausar tráfego indesejado no servidor, ou até mesmo uma via potencial para crackers ao sistema. VejaCapí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 softwaretestadas exaustivamente. Sendo utilizadas em ambientes de produção por muitos anos, seus códigostê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 chegaramrecentemente 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 seremmaneiras efetivas de alertar a comunidade sobre vulnerabilidades de segurança, é responsabilidadedos adminsitradores consertarem seus sistemas prontamente. Isto requer uma atenção especial poisos 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 desistemas requer vigilância, constante rastreamento de erros e manutenção apropriada do sistema paraassegurar 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 DesatentaAdministradores que não consertam seus sistemas apropriadamente são grandes ameaças à segurançade servidores. De acordo com o ’System Administration Network and Security Institute’ (SANS), acausa fundamental da vulnerabilidade na segurança de computadores é "delegar pessoas não treinadaspara 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 outrosfalham em monitorar as mensagens de registro do kernel do sistema ou tráfego de rede. Outro errocomum é deixar senhas ou chaves default de serviços inalteradas. Por exemplo: alguns bancos dedados têm senhas de administração default porque seus desenvolvedores assumem que o adminstradorde sistemas irá alterá-las imediatamente após a instalação. Se um administrador de banco de dadosdeixar de alterar esta senha, mesmo um cracker inexperiente pode utilizar uma senha default conhecidapara obter privilégios administrativos ao banco de dados. Estes são apenas alguns dos exemplos decomo uma administração desatenta pode desencadear no comprometimento de servidores.

2.3.4. Serviços Essencialmente InsegurosAté 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


através de redes confiáveis, mas essa suposição deixa de ser verdadeira a partir do momento em que oserviç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 deusuá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 deataque ’man-in-the-middle’. Neste tipo de ataque um cracker redireciona o tráfego de rede, enganandoum 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 comoum condutor invisível, situado discretamente entre o serviço remoto e o crédulo usuário, capturandoas informações. Desta maneira um cracker consegue obter senhas administrativas e dados sem que oservidor ou o usuário perceba.

Outra categoria de serviços inseguros são sistemas de arquivos de rede e serviços de informação, comoNFS ou NIS, desenvolvidos explicitamente para uso em LANs, mas que, infelizmente, têm seu usoextendido para WANs (para usuários remotos). O NFS não tem, por default, nenhuma autenticaçãoou mecanismos de segurança configurados para prevenir um cracker de montar o compartilhamentodo NFS e acessar qualquer coisa contida nele. O NIS também tem informações vitais que devemser conhecidas por qualquer computador ou rede, incluindo senhas e permissões de arquivo, em umbanco de dados ACSII ou DBM (derivado do ASCII) somente-texto. Um cracker que obtém acessoa este banco de dados poderá acessar qualquer conta de usuário de uma rede, inclusive a conta doadministrador.

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 PessoalEstaçõ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 decrédito, também são alvos de crackers de sistemas. Estações de trabalho também podem ser violadassem 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 osusuários da dor de cabeça de reinstalar o sistema operacional, ou pior, de recuperar-se do roubo dedados.

2.4.1. Senhas RuinsSenhas 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áveisApesar 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çosTelnet 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 detrabalho 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 vezconectado ao servidor, o atacante pode capturar discretamente quaisquer teclas pressionadas e cliquesde mouse efetuados pelo cliente através da rede. Este problema foi consertado na segunda versão doprotocolo SSH, mas depende do usuário monitorar aplicações com tais vulnerabilidades e atualizá-lasquando necessário.

O Capítulo 4 aborda mais detalhadamente os passos que administradores e usuários domésticos devemseguir para limitar a vulnerabilidade de estações de trabalho.

II. Configurando o Red Hat Enterprise Linux paraSegurança

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

Índice3. Atualizações de Segurança........................................................................................................... 174. Segurança da Estação de Trabalho ............................................................................................. 235. Segurança do Servidor ................................................................................................................. 416. Redes Privadas Virtuais (Virtual Private Networks)................................................................. 557. Firewalls......................................................................................................................................... 65

Capítulo 3.Atualizações de Segurança

Conforme as vulnerabilidades de segurança são descobertas, o software afetado deve ser atualizadopara limitar os potenciais riscos de segurança. Se o software é parte de um pacote de uma distribuiçãodo Red Hat Enterprise Linux atualmente suportada, a Red Hat, Inc. está comprometida em lançarpacotes 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 conserteo problema). Este conserto é então aplicado ao pacote Red Hat Enterprise Linux, testado pela equipede 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 mantenedordo software para consertar o problema. Após consertar o problema, o pacote é testado e lançado comouma atualização de errata.

Se for lançada uma atualização de errata para um software utilizado em seu sistema, é altamenterecomendável que você atualize os pacotes afetados assim que possível, para mininmizar o tempodurante o qual seu sistema está potencialmente vulnerável.

3.1. Atualizando PacotesAo atualizar o software de um sistema, é importante fazer o download da atualização de uma fonteconfiá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 depoislançá-lo na Internet. Se isto acontecer, usar medidas de segurança, como checar os arquivos com oRPM original, não detectará o exploit. Portanto, é muito importante que você apenas faça o downloadde RPMs de fontes confiáveis, tais como Red Hat, Inc., e cheque a assinatura do pacote para verificarsua 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 serbaixados somente pela Red Hat Network. Apesar do site de Erratas da Red Hat conter informaçõesatualizadas, não contém os pacotes para download.

3.1.1. Usando a Red Hat NetworkA 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 fontesegura, 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 determinadoperíodo de tempo.

A Red Hat Network requer um Perfil do Sistema para cada máquina a ser atualizada. O Perfil doSistema contém informações de hardware e software do sistema. Essas informações são mantidasconfidenciais 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 seum 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ãoafetados por ela. Para aplicar a atualização, você pode usar o Agente de Atualizações Red Hat ouagendar 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 RedHat 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 deReferência da Red Hat Network (Red Hat Network Reference Guide) disponível emhttp://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 especiaiscontidas no relatório da errata e executá-las. Consulte a Seção 3.1.5 para instruções gerais sobrecomo aplicar as alterações feitas por uma atualização de errata.

3.1.2. Usando o Site de Erratas da Red HatQuando os relatórios de erratas de segurança são lançados, são publicados no site de Erratas da RedHat 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çada Red Hat Enterprise Linux. Se a sinopse de um dos relatórios descreve um pacote usado em seusistema, 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 serexecutadas 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 quevocê crie um novo diretório como /tmp/atualizações e salve todos os pacotes baixados ali.

3.1.3. Verificando Pacotes AssinadosTodos 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 aautenticidade dos arquivos distribuídos. Por exemplo: uma chave privada (chave secreta) mantidapela Red Hat tranca o pacote enquanto a chave pública o destranca e o verifica. Se a chave públicadistribuída pela Red Hat não bate com a chave privada durante a verificação RPM, o pacote pode tersido alterado e, portanto, não é confiável.

O utilitário RPM do Red Hat Enterprise Linux tenta automaticamente verificar a assinatura GPG deum pacote RPM antes de instalá-lo. Se a chave GPG da Red Hat não está instalada, instale-a a partirde 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á-lapara 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 seguintecomando:

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 passoassegura que eles não foram alterados depois do lançamento dos pacotes pela Red Hat, Inc.. Paraverificar 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. Casocontrário, certifique-se de usar a chave pública correta da Red Hat, assim como verificar a fonte doconteúdo. Os pacotes que não passarem na verificação GPG não devem ser instalados, pois podem tersido 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 AssinadosA 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 removidousando o seguinte comando:

rpm -e � old-kernel-package �

No exemplo anterior, substitua � old-kernel-package � pelo nome do RPM do kernel antigo.


Nota

Não é necessário remover o kernel antigo. O gestor de início default, GRUB, permite a instalação dekernels 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 especiaiscontidas no relatório da errata e executá-las. Consulte a Seção 3.1.5 para instruções gerais sobrecomo aplicar as alterações feitas por uma atualização de errata.

3.1.5. Aplicando as AlteraçõesApós fazer o download e instalar as erratas de segurança através da Red Hat Network ou do site deerratas da Red Hat, é importante parar de usar o software antigo e passar a usar o novo. O modo comoisso é feito depende do tipo de software que foi atualizado. A lista a seguir aponta as categorias geraisde 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 umpacote de software é usada; entretanto, esta opção nem sempre está disponível ao administradorde sistemas.

Aplicações

Aplicações em espaço de usuário (user-space) são quaisquer programas que podem ser iniciadospor 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çãono 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 diversasaplicaçõ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 queusam 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 podeser feito usando a Ferramenta de Configuração dos Serviços ou se autenticando a uma janelade 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 deSistemas Red Hat Enterprise Linux para mais informações sobre a Ferramenta de Configuraçãodos Serviços.

Serviços xinetd

Os serviços controlados pelo super serviço xinetd rodam somente quando há uma conexãoativa. 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. Noentanto, 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 oupgrade 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 killallpara 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 pacotese 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 serterminadas com o seguinte comando:kill -9 � PID

No exemplo anterior, substitua PID � pelo número de identificação do processo (encontradona 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 HatEnterprise Linux para informações gerais sobre o xinetd.

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 pessoalou sistema corporativo, uma boa política de segurança começa pelo computador individual. Afinal decontas, uma rede de computadores é tão segura quanto seu nódulo mais vulnerável.

4.1. Avaliando a Segurança da Estação de TrabalhoAo 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 amá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 administrativoeles 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 usadaspara a comunicação entre estações de trabalho e quais devem ser evitadas?

4.2. Segurança do BIOS e do Gestor de InícioA 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áquinacom mídia removível ou obter privilégios root através do modo de usuário simples. Mas as medidasde segurança a tomar para proteger o sistema de ataques deste tipo dependem da sensibilidade dasinformaçõ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 chavesSSH privadas não criptografadas da rede corporativa for deixado nesta mesma feira sem a proteção desenhas, 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 BIOSVeja a seguir as duas razões principais para proteger o BIOS de um computador com senhas1:

1. Impedindo Alterações na Configuração do BIOS — Se um intruso tem acesso ao BIOS, podeconfigurá-lo para ser iniciado por um disquete ou CD-ROM. Isto possibilita que ele entre nomodo de recuperação ou de usuário simples, que por sua vez permite a ele iniciar programasarbitrariamente 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 processode inicialização da máquina com senha. Quando ativado, um atacante é forçado a inserir umasenha 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 desligandoa 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 bateriaCMOS.

4.2.1.1. Protegendo Plataformas Não-x86

Outras arquiteturas usam programas diferentes para executar tarefas de nível baixo, parecidas àquelasdo BIOS em sistemas x86. Por exemplo: computadores baseados no Intel® Itanium™ usam a shellEFI (Extensible Firmware Interface).

Para instruções sobre a proteção através de senha a programas parecidos com o BIOS em outrasarquiteturas, consulte as instruções do fabricante.

4.2.2. Senhas do gestor de InícioVeja 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 nomodo de usuário simples, ele é autenticado automaticamente como o usuário root sem precisarindicar a senha root.

2. Impedindo Acesso ao Console do GRUB — Se a máquina utiliza GRUB como seu gestor deinício, um atacante pode usar a interface de edição do GRUB para alterar sua configuração oupara 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. Parauma visão detalhada do GRUB, consulte o capítulo intitulado O Gestor de Início GRUB no Guia deReferência do Red Hat Enterprise Linux.

4.2.2.1. Senha Protegendo o GRUBVocê 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 ainterface 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 locklogo abaixo dela.

Para um sistema DOS, a estrofe deve começar similarmente a:

title DOSlock

Atenção

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

Para criar uma senha diferente para um kernel ou sistema operacional específico, adicione uma linhalock na estrofe, seguida de uma linha para senha.

Cada estrofe que você proteger com uma senha única deve começar com linhas similares ao exemploseguinte:

title DOSlockpassword --md5 � password-hash �

4.3. Segurança da SenhaSenhas são o método principal usado pelo Red Hat Enterprise Linux para verificar a identidade deusuários. É por isso que a segurança da senha é tão importante para a proteção do usuário, da estaçãode trabalho e da rede.

Por motivos de segurança, o programa de instalação configura o sistema para usar o AlgoritmoMessage-Digest (MD5) e senhas shadow. É altamente recomendável que você não altere estasconfigurações.

Se você desselecionar as senhas MD5 durante a instalação, o antigo formato Padrão de Criptografiade Dados (DES - Data Encryption Standard) é utilizado. Este formato limita as senhas a oito caracteresalfa-numéricos (impedindo o uso de pontuação e outros caracteres especiais) e oferece um nível decriptografia 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 aataques 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.


de cracking neste arquivo. Se houver uma senha desprotegida no arquivo, é apenas uma questão detempo 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çode rede na máquina, como SSH ou FTP. Este tipo de ataque de força bruta é bem mais lento e deixarastros ó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 comsenhas fracas, ele pode obter acesso e editar os arquivos de registro para apagar seus rastros antes daluz do dia.

Além das questões de formato e armazenamento, há também a questão de conteúdo. A coisa maisimportante que um usuário pode fazer para proteger sua conta de cracking de senha é criar uma senhaforte.

4.3.1. Criando Senhas FortesAo 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 umasenha.

Alguns exemplos de senhas inseguras:

• 8675309

• juan

• hackme

• Não Use Palavras Reconhecíveis — Palavras como nomes próprios, palavras de dicionário ouaté termos de shows de televisão ou novelas devem ser evitados, mesmo que sejam finalizadoscom números.


• 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.


• cheguevara

• bienvenido1

• 1dumbKopf


• 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 listasde palavras incluem LEET speak.


• H4X0R

• 1337

• Não Use Informações Pessoais — Fique longe das informações pessoais. Se o atacante souberquem você é, ele terá facilidade em descobrir sua senha. A seguir, veja uma lista de tipos deinformação a evitar na criação de uma senha:


• 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 palavrascomuns, portanto reverter uma senha ruim não a torna mais segura.


• 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 paracada máquina. Desta maneira, se um sistema for comprometido, todas as outras máquinas nãoestarã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 tamanhomáximo (oito caracteres).

• Misture Letras em Caixa Alta e Baixa — O Red Hat Enterprise Linux é sensível a maiúsculase 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ãoapenas no começo e fim), pode aumentar a força da senha.

• Inclua Caracteres Não Alfa-numéricos — Caracteres especiais como &, $ e � podem aumen-tar bastante a força de uma senha (isto não é possível se usar senhas DES).

• Escolha uma Senha que Você Possa Lembrar — A melhor senha do mundo de nada adianta sevocê não conseguir lembrá-la. Então use acrônimos ou outros dispositivos mneumônicos paraajudá-lo a memorizar senhas.


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 senhamemorizável e segura.

4.3.1.1. Metodologia de Criação de Senha SeguraHá 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 boasprárticas para criar e gerenciar senhas de usuários em uma empresa.

4.3.2. Criando Senhas de Usuários Dentro de uma EmpresaSe houver um número significativo de usuários em uma empresa, os administradores de sistemas têmduas 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êmqualidade aceitável.

Criar senhas para os usuários garante que as senhas sejam boas, mas se torna uma tarefa complicadaconforme 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ópriassenhas, mas ativamente verificam se as senhas são boas e, em alguns casos, forçam os usuários atrocarem suas senhas periodicamente conforme sua idade.

4.3.2.1. Forçando Senhas FortesPara proteger a rede de intrusões é uma boa idéia administradores de sistema verificarem se as senhasusadas na empresa são fortes. Quando for pedido aos usuários criar ou alterar senhas, eles podemutilizar 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 ouse é 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ívelem http://www.openwall.com/passwdqc/) ou escrever um módulo novo. Para visualizar uma lista dosmódulos PAM disponíveis, veja http://www.kernel.org/pub/linux/libs/pam/modules.html. Para maisinformações sobre o PAM, veja o capítulo intitulado Módulos Plugáveis de Autenticação (PAM) noGuia de Referência do Red Hat Enterprise Linux.


Note, no entanto, que a verificação executada nas senhas no momento de sua criação não descobresenhas ruins tão efetivamente quanto rodar um programa de cracking de senhas nas senhas da empresainteira.

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 decracking 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 depalavras múltiplas e é capaz de craquear senhas com força bruta. Está disponível online emhttp://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çacontra 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 SenhaIdade da senha é uma outra técnica usada por administradores de sistema para defender uma empresacontra senhas ruins. A idade da senha significa que depois de um determinado tempo (geralmente 90dias) é solicitado ao usuário criar uma nova senha. A teoria por trás disso é se o usuário é forçado atrocar sua senha periodicamente, uma senha crackeada por um intruso será útil somente por um tempolimitado. 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 dasenha, é 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


em uma janela de comandos (num XTerm ou num terminal GNOME, por exemplo). Clique na abaUsuários, selecione o usuário da lista e clique em Propriedades no botão do menu (ou selecioneArquivo => Propriedades no menu suspenso).

Então clique na aba Informações de Senha e insira o número de dias antes da senha expirar, conformemostra 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 comoforç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áriose recursos, consulte o capítulo Gerenciando Contas de Usuário e Acesso a Recursos (ManagingUser Accounts and Resource Access) no Introdução à Administração de Sistemas Red Hat Enter-prise Linux.

4.4. Controles AdministrativosAo administrar um computador caseiro, o usuário deve executar algumas tarefas como usuário rootou 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 dousuário operando o programa. Tais programas são caracterizados por um s em caixa baixa na seçãodo 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 acordocom o nível de acesso administrativo que os usuários, dentro da organização, devem ter em suasmáquinas. Através de um módulo PAM chamado pam_console.so, algumas atividades reservadassomente ao usuário root, como reinicializar e montar mídia removível, são permitidas ao primeirousuá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ódulopam_console.so). Entretanto, outras tarefas importantes da administração de sistemas, como alterarconfiguraçõ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 osusuários de sua rede devem receber.


4.4.1. Permitindo Acesso RootSe os usuários de uma empresa são um grupo confiável e experiente em computadores, permití-losacesso root talvez não seja um problema. Permitir acesso root a usuários significa que questõesmenores, como adicionar serviços ou configurar interfaces de rede, podem ser executadas pelosusuários individuais, deixando os administradores de sistema livres para lidar com a segurança darede 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áquinase 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 FTPou Telnet, em suas máquinas, potencialmente arriscando nomes de usuários e senhas conformetrafegam sem criptografia pela rede.

• Anexando Arquivos em Emails como Root — Apesar de raros, existem vírus de e-mail que afetamo Linux. A única hora em que eles representam uma ameaça, no entanto, é quando são executadospelo usuário root.

4.4.2. Impedindo Acesso RootSe o administrador não estiver confortável em permitir que usuários se autentiquem como root porestas ou por outras razões, a senha de root deve ser guardada secretamente, e o acesso ao nível deexecução um ou ao modo de usuário simples deve ser impedido através da proteção da senha dogestor 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 ashell root.

Edite o arquivo/etc/passwd e altere ashell de /bin/bash para/sbin/nologin.

Impede acesso à shell roote registra a tentativa.Os seguintes programassão impedidos de acessara conta root:� login� gdm� kdm� xdm� su� ssh� scp� sftp

Programas que nãorequerem uma shell, comoclientes FTP, clientes demail e muitos programassetuid.Os seguintes programasnão são impedidos deacessar a conta root:� sudo� clientes FTP� clientes de Email


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

Desativaracessorootatravés dequalquerdisposi-tivo deconsole(tty).

Um arquivo/etc/securetty vazioimpede a autenticação deroot a quaisquerdispositivos atachados aocomputador.

Impede o acesso à contaroot através do console ourede. Os seguintesprogramas são impedidosde acessar a conta root:� login� gdm� kdm� xdm� Outros serviços de redeque abrem uma tty

Programas que não selogam como root, masexecutam tarefasadministrativas através demecanismos setuid ououtros.Os seguintes programasnão são impedidos deacessar a conta root:� su� sudo� ssh� scp� sftp

Desativarautenti-caçõesroot SSH.

Edite o arquivo/etc/ssh/sshd_confige defina o parâmetroPermitRootLogin parano.

Impede o acesso rootatravés do conjunto deferramentas OpenSSH. Osprogramas a seguir sãoimpedidos de acessar aconta root:� ssh� scp� sftp

Isto impede somente oacesso root ao conjunto deferramentas do OpenSSH.

Utilizar oPAMparalimitar oacessoroot aosserviços.

Edite o arquivo para oserviço em questão nodiretório /etc/pam.d/.Assegure quepam_listfile.so sejanecessário para aautenticação.a

Impede o acesso root paraserviços de redenotificados pelo PAM.Os seguintes serviços sãoimpedidos de acessar aconta root:� clientes FTP� clientes de Email� login� gdm� kdm� xdm� ssh� scp� sftp� Quaisquer serviçosnotificados pelo PAM

Programas e serviços quenão são notificados peloPAM.

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 RootPara impedir os usuários de se autenticar diretamente como root, o administrador de sistema podeconfigurar 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.


Importante

Programas que não requerem acesso à shell, como clientes de email ou o comando sudo, aindapodem 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 consoleeditando o arquivo /etc/securetty. Este arquivo lista todos os dispositivos nos quais o usuárioroot pode se autenticar. Se o arquivo não existir, o usuário root pode se autenticar através de qualquerdispositivo 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 senhaem formato texto através da rede. Por default, o arquivo /etc/securetty do Red Hat EnterpriseLinux 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 remotamenteusando 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 dodaemon 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 PAMO PAM, através do módulo /lib/security/pam_listfile.so, permite grande flexibilidade emnegar contas específicas. Isto permite que o administrador aponte o módulo para uma lista de usuáriosque não são permitidos de autenticar. O exemplo abaixo mostra como o módulo é usado para o servidorFTP vsftpd no arquivo de configuração do PAM /etc/pam.d/vsftpd (o caracter \ no final daprimeira 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 listadoacessar o serviço. O administrador é livre para alterar o nome deste arquivo e pode guardar listasseparadas para cada serviço ou usar uma lista geral para negar acesso a múltiplos serviços.


Se o administrador quer negar acesso a múltiplos serviços, uma linha similar pode ser adicionada aosserviços de configuração do PAM, como /etc/pam.d/pop e /etc/pam.d/imap para clientes demail 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) noGuia de Referência do Red Hat Enterprise Linux.

4.4.3. Limitar Acesso RootAo invés de negar completamante acesso ao usuário root, o administrador pode permitir acesso apenasatravé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 janelade comandos.

Uma vez autenticado através do comando su, o usuário é o usuário root e tem acesso administrativoabsoluto ao sistema. Além disso, uma vez que o usuário obteve aceeso root, é possível que ele use ocomando 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 limitarquem tem acesso ao comando.

Uma das maneiras mais simples de fazer isso é adicionar usuários ao grupo administrativo especialchamado wheel. Para fazer isso, digite o seguinte comando como root:

usermod -G wheel � username �

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

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 comandoredhat-config-users numa janela de comandos. Selecione a aba Usuários, selecione ousuá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.


Figura 4-2. Aba Grupos

Em seguida, abra o arquivo de configuração do PAM para su (/etc/pam.d/su) em um editor detexto 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 umusuário confiável precede um comando administrativo com sudo, ele precisa inserir sua própriasenha. 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 ousuário root, como o comando mount.

Importante

Usuários do comando sudo devem tomar cuidado extra para fazer logout antes de deixarem suasmáquinas, já que é possível usar o comando novamente sem precisar indicar a senha, por umperíodo de cinco minutos. Esta configuração pode ser alterada através do arquivo de configuração/etc/sudoers.


O comando sudo permite um grau de flexibilidade maior. Por exemplo: somente os usuários listadosno 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çãobem-sucedida é registrada no arquivo /var/log/messages e o comando submetido junto ao nomedo usuário é registrado no arquivo /var/log/secure.

Outra vantagem do comando sudo é que um administrador pode permitir a diferentes usuários acessoa comandos específicos baseado em suas necessidades.

Administradores que queiram editar o arquivo de configuração do sudo, o /etc/sudoers, devemusar 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 executarqualquer 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 nowdesde 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íveisEnquanto o acessso a controles administrativos é uma questão importante para administradores desistemas dentro de uma empresa, manter controle de quais serviços de rede estão ativos é de sumaimportâ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 umserviç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 sertratado como uma via potencial de ataque.

4.5.1. Riscos aos ServiçosServiços de rede podem apresentar muitos riscos a sistemas Linux. Veja abaixo uma lista com asprincipais questões:

• Ataques Denial of Service (DoS) — Ao inundar um serviço com pedidos, um ataque de denial ofservice 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çõesno lado do servidor, como servidores Web geralmente fazem, um cracker pode montar um ataquecom scripts escritos inapropriadamente. Estes ataques à vulnerabilidade do script podem acarretarna 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


sobrecarga explorável do buffer, um atacante pode obter acesso ao sistema como o usuário rodandoo daemon. Devido à existência de sobrecarga explorável do buffer, os crackers usam ferramentasautomatizadas 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 Linuxpelo ExecShield , uma tecnologia de segmentação e proteção da memória executável suportadapelos kernels de mono ou mulit-processadores x86. O ExecShield reduz o risco de sobrecarga dobuffer dividindo a memória virtual em segmentos executáveis e não-executáveis. Qualquer códigode programa que tentar executar fora do segmento executável (como código maldoso de um exploitda 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 epara a tecnologia eXecute Disable (XD) em sistemas Itanium e EM64T da Intel®. Estas tecnologiastrabalham 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 riscode ataques exploits furtivos da sobrecarga do buffer.

Para mais informações sobre as tecnologias do ExecShield, NX ou XD, consulte o documento técnicointitulado New Security Enhancements in Red Hat Enterprise Linux v.3, Update 3, disponível naseguinte 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çosPara aumentar a segurança, a maioria dos serviçosde rede instalados com o Red Hat Enterprise Linuxsã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õesa 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 sensoe pecar pela precaução. Por exemplo: se uma impressora não está disponível, não deixe o cupsdrodando. O mesmo vale para o portmap. Se você não monta volumes NFSv3 ou não usa o NIS (oserviç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.


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çãodos 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ãoabertas e escutando. Veja a Seção 5.8 para mais informações sobre o assunto.

4.5.3. Serviços InsegurosPotencialmente, 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 manteratualizados os pacotes associados a qualquer serviço de rede. Veja o Capítulo 3 para mais detalhessobre este assunto.

Alguns protocolos de rede são essencialmente mais inseguros que outros. Estes incluem quaisquerserviç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 quepossível.

• Passar Dados Importantes por uma Rede Não-Criptografada — Muitos protocolos passam dadosatravés da rede não-criptografada. Estes protocolos incluem o Telnet, FTP, HTTP e o SMTP. Muitossistemas de arquivo de rede, como o NFS e o SMB, também passam informações através da redenão-criptografada. É responsabilidade do usuário limitar o tipo de dados transmitidos ao utilizarestes 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 bancode 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


• telnet

• vsftpd

Todos os programas de autenticação e shell (rlogin, rsh e telnet) devem ser evitados a favor doSSH. (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 evitarproblemas. 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 PessoaisUma 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 pedidoa uma porta sendo bloqueada pelo firewall, este será ignorado. Se o serviço estiver escutando numadestas 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 bloquearacesso a portas usadas por serviços configurados.

Para a maioria dos usuários, a melhor ferramenta para configurar um firewall simples é a ferramentade configuração gráfica distribuída com o Red Hat Enterprise Linux: a Ferramenta de Configuraçãodo Nível de Segurança (system-config-securitylevel). Esta ferramenta cria regras iptablesabrangentes 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ítulointitulado Configuração Básica do Firewall no Guia de Administração de Sistemas Red Hat EnterpriseLinux.

Para usuários avançados e administradores de servidores, configurar manualmente um firewall comiptables é 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.


4.7. Ferramentas de Comunicação de Segurança AprimoradaNa mesma proporção em que o tamanho e a popularidade da Internet tem crescido, cresceu tambéma ameaça da intercepção de comunicações. Através do anos, ferramentas foram desenvolvidas paracriptografar 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 altonível e baseados em criptografia de chave pública para proteger as informações conforme trafegampela 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 (PrettyGood 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çõescliente 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 oprotocolo 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 evitarameaç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 discosrígidos.

Para mais informações sobre o uso do GPG, consulte o apêndice intitulado Guia de Iniciação do GnuPrivacy 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. Poresta 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 aumentara 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 xinetdTCP 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 umpedido e o serviço requisitado.

Os benefícios oferecidos pelos TCP wrappers aumentam quando este é usado junto ao xinetd, umsuper 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 paracriar redundância nos controles de acesso ao serviço. Consulte o Capítulo 7 para mais informaçõessobre 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 desegurança específicas.

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

5.1.1.1. TCP Wrappers e Banners de ConexãoEnviar um banner intimidador para clientes conectando a um serviço é uma boa maneira de disfarçarem qual sistema o servidor está rodando enquanto informa um atacante potencial que o administradorde sistemas está vigiando. Para implementar um banner do TCP wrappers para um serviço, use aopçã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. Podeestar em qualquer lugar do sistema, mas deve levar o mesmo nome que o daemon. Neste exemplo, oarquivo é chamado /etc/banners/vsftpd.

O conteúdo do arquivo é parecido com o seguinte:

220-Hello, %c220-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 damáquina ou nome de usuário e endereço IP, para intimidar ainda mais a conexão. O Guia de Referênciado 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 AtaqueSe uma determinada máquina ou rede for flagrada atacando o servidor, o TCP wrappers pode ser usadopara alertar o administrador sobre ataques subsequentes desta máquina ou rede através da diretivaspawn.

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 eregistrada 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 oadministrador ou para executar uma série de comandos na ocasião em que um determinado clientetenta conectar ao servidor.

5.1.1.3. TCP Wrappers e Registro AprimoradoSe determinados tipos de conexões são mais preocupantes que outras, o nível de registro pode serelevado 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 umservidor FTP é um cracker. Para denotar isso, insira um sinal emerg nos arquivos de registro ao invésdo 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 paraemerg, 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-armadilhae 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áginasman do xinetd e do xinetd.conf.

5.1.2.1. Montando uma ArmadilhaUma importante característica do xinetd é sua habilidade em adicionar máquinas (hosts) a umalista de no_access. Às máquinas desta lista são negadas as conexões subsequentes aos serviçosgerenciados pelo xinetd por um determinado período ou até o xinetd ser reiniciado. Isto é feitousando o atributo SENSOR. Esta técnica é uma maneira fácil de bloquear máquinas que tentaremscanear o servidor.

O primeiro passo para definir um SENSOR é escolher um serviço que você não planeja utilizar. Nesteexemplo, 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 oatributo deny_time são FOREVER (sempre), que mantém o banimento efetivo até que o xinetdseja 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 ServidorOutra característica importante do xinetd é sua habilidade em controlar a quantidade de recursosque 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 permitidasao serviço por segundo. Esta diretiva aceita apenas valores inteiros.


• instances = $ number_of_connections % Determina o número total de conexões permitidasa um serviço. Esta diretiva aceita tanto um valor inteiro como UNLIMITED.

• per_source = $ number_of_connections % — Determina as conexões permitidas a umserviç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 oserviço pode ocupar em kilobytes ou megabytes. Esta diretiva aceita tanto um valor inteiro comoUNLIMITED.

• rlimit_cpu = $ number_of_seconds % — Determina o tempo em segundos durante o qualum 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 PortmapO serviço portmap é um daemon de porta dinâmica para serviços RPC, como o NIS e o NFS. Temmecanismos de autenticação fracos e tem habilidade para delegar uma enorme gama de portas para osserviç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 orequer mais. Se você planeja implementar um servidor NFSv2 ou NFSv3, o portmap é necessário ea 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çoportmap 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 demá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 IPTablesPara restringir acesso ao serviço portmap futuramente, é uma boa idéia adicionar regras do IPTablesao 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 oserviç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 DROPiptables -A INPUT -p tcp -s 127.0.0.1 --dport 111 -j ACCEPT

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


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 doIPTables.

5.3. Protegendo o NISNIS significa Serviço de Informações de Rede (Network Information Service). É um serviço RPCchamado ypserv, usado em conjunto com o portmap e outros serviços relacionados, para distribuirmapas de nomes de usuário, senhas e outras informações importantes para qualquer computador queesteja 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 permitea usuários alterarem suas senhas NIS.

• /usr/sbin/rpc.ypxfrd — Também chamado de serviço ypxfrd, esse daemon é responsávelpelas transferências de mapa do NIS através da rede.

• /usr/sbin/yppush— Essa aplicação amplia bancos de dados NIS alterados para servidores NISmú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áquinae passa toda a sua informação sem criptografia através da rede, incluindo uma gama de senhas. Comoresultado, tenha muito cuidado ao configurar uma rede que usa NIS. Para complicar ainda mais, aconfiguração default do NIS é essencialmente insegura.

É recomendado a qualquer um planejando implementar um servidor NIS, primeiro proteger o serviçoportmap conforme descrito na Seção 5.2, e então resolver as seguintes questões, como planejamentoda rede.

5.3.1. Planejar Cuidadosamente a RedeComo o NIS passa informações delicadas sem criptografia através da rede, é importante que o serviçoseja executado por trás de um firewall e numa rede segmentada e segura. Toda vez que informaçõesdo 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) NISparecido com uma senhaQualquer máquina com um domínio NIS pode usar comandos para extrair informações do servidorsem autenticação, desde que o usuário saiba o o nome da máquina DNS e o nome de domínio NIS doservidor.

Por exemplo: se alguém conectar um laptop a uma rede ou violar a rede por fora (e conseguir roubarum endereço IP interno), o seguinte comando revela o mapa de /etc/passwd:


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

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

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 onome 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áscarade 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 aquais redes o servidor NIS serve.

5.3.4. Determinar Portas Estáticas e Usar Regras do IPTablesTodos 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 portaspara os outros dois daemons do servidor NIS, rpc.ypxfrd e ypserv, permite criar regras de firewallpara 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 escutapara estas portas:

iptables -A INPUT -p ALL -s! 192.168.0.0/24 --dport 834 -j DROPiptables -A INPUT -p ALL -s! 192.168.0.0/24 --dport 835 -j DROP


Dica

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

5.3.5. Use Autenticação do KerberosUma das desvantagens mais gritantes ao usar NIS para autenticação é que sempre que um usuáriose 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 otrá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 umatacante 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ésda rede, tornando o sistema bem mais seguro. Para saber mais sobre o Kerberos, consulte o capítulointitulado Kerberos no Guia de Referência do Red Hat Enterprise Linux.

5.4. Protegendo o NFSO Sistema de Arquivo de Rede (Network File System ou NFS) é um serviço que oferece sistemasde 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 HatEnterprise 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 conhecimentobá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 (aoinvés do UDP) e o requer no uso do NFSv4. O NFSv4 agora inclui a autenticação do Kerberos parausuário e grupo, como parte do módulo RPCSEC_GSS do kernel. As informações sobre o portmapainda são inclusas, já que o Red Hat Enterprise Linux suporta o NFSv2 e NFSv3, que o utilizam.

5.4.1. Planejar Cuidadosamente a RedeAgora que o NFS tem a habilidade de passar todas as informações criptografadas usando o Kerberosatravés da rede, é importante que o serviço seja configurado corretamente se estiver atrás de umfirewall ou numa rede segmentada. O NFSv2 e NFSv3 ainda passam dados inseguramente e seus riscosdevem ser considerados. Um planejamento cuidadoso da rede neste aspecto pode ajudar a prevenirviolações à segurança.

5.4.2. Cuidado com Erros de SintaxeO servidor NFS determina quais sistemas de arquivo e quais máquinas exportar para estes diretóriosatravé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 amáquina bob.example.com com permissões de leitura e escrita (rw).


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

Por outro lado, esta linha do arquivo /etc/exports compartilha o mesmo diretório com a máquinabob.example.com com permissão somente-leitura, e o compartilha com o mundo com permissõesleitura 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 showmountpara 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 deusuá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 idsdo usuário.

Se no_root_squash é usado, os usuários root remotos poderão alterar qualquer arquivo do sistemade arquivo compartilhado e deixar aplicações infectadas pelo trojan, para que outros usuários as exe-cutem inadvertidamente.

5.5. Protegendo o Servidor HTTP ApacheO Servidor HTTP Apache é um dos serviços mais estáveis e seguros distribuídos com o Red HatEnterprise Linux. Há um número exorbitante de opções e técnicas disponíveis para proteger o ServidorHTTP Apache — muito numerosos para serem explorados em detalhes aqui.

Ao configurar o Servidor HTTP Apache é importante ler a documentação disponível paraa aplicação. Isto inclui o capítulo intitulado Servidor HTTP Apache do Guia de Referência doRed Hat Enterprise Linux, o capítulo Configuração do Servidor HTTP Apache do Guia deAdministração de Sistemas Red Hat Enterprise Linux e os manuais do Stronghold, disponíveisonline: http://www.redhat.com/docs/manuals/stronghold/.

Veja abaixo uma lista de opções de configuração para as quais administradores devem ser muitocuidadosos.

5.5.1. FollowSymLinksEsta 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.


5.5.3. A Diretiva UserDir

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

UserDir enabledUserDir disabled root

Estas diretivas ativam a navegação em todos os diretórios de usuário, exceto no /root. Para adicionarusuários à lista de contas desativadas, adicione uma lista de usuários delimitada por espaço na linhaUserDir 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 é recomendadoalterar 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áveisCertifique-se de conceder permissões de gravação (write) para o usuário root em todos os diretórioscontendo scripts ou CGIs. Isto pode ser feito digitando os seguintes comandos:

chown root * directory_name +chmod 755 * directory_name +

Também verifique sempre se todos os scripts rodando no sistema funcionam como planejado antes decolocá-los em produção.

5.6. Protegendo o FTPO Protocolo de Transporte de Arquivo (File Transport Protocol ou FTP) é um protocolo TCP antigodesenvolvido para transferir arquivos pela rede. Já que todas as transações com o servidor (inclusivea autenticação de usuário) são criptografadas, o FTP é considerado um protocolo inseguro e deve serconfigurado 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 deautenticação através da rede.

• Acelerador de Conteúdo Red Hat (tux) — Um servidor Web com capacidades de FTP no espaçodo 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 FTPAntes de submeter um nome de usuário e senha, é apresentado um banner de saudação a todos osusuários. Por default, este banner inclui informações da versão úteis para crackers tentando identificarfraquezas num sistema.


Para alterar o banner de saudação do vsftpd, adicione a seguinte diretiva a/etc/vsftpd/vsftpd.conf:

ftpd_banner= , insert_greeting_here -

Substitua . insert_greeting_here / na diretiva acima pelo texto de sua mensagem desaudação.

Para banners com muitas linhas, é melhor usar um arquivo de banner. Para simplificar o gerenciamentode 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 exemploabaixo 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 aoarquivo /etc/vsftpd/vsftpd.conf:

banner_file=/etc/banners/ftp.msg

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

5.6.2. Acesso AnônimoA 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 árvorede diretório para usuários anônimos e configura as permissões dos diretórios para somente-leitura parausuá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 dadosimportantes.

5.6.2.1. Upload AnônimoPara permitir que usuários anônimos façam upload, é recomendado criar um diretóriosomente-gravação (write-only) em /var/ftp/pub/.

Para fazer isso, digite:

mkdir /var/ftp/pub/upload


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, frequentementepercebem 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árioJá que o FTP passa nomes de usuário e senhas não criptografados através de redes inseguras paraautenticação, é uma boa idéia proibir usuários do sistema acessarem o servidor através de suas contasde 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árioA maneira mais fácil de desabilitar um grupo específico de contas, como o usuário root e aqueles comprivilégios sudo, a acessar um servidor FTP, é usar um arquivo de lista PAM conforme descrito naSeçã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 AcessoUse TCP wrappers para controlar o acesso a qualquer daemon do FTP, conforme descrito na Seção5.1.1.


5.7. Protegendo o SendmailSendmail é um Agente de Transporte de Correspondência (Mail Transport Agent - MTA) que utilizao 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 agentesde entrega. Apesar de muitos MTAs serem capazes de criptografar tráfego entre eles, a maioria não ofaz, portanto enviar email através de qualquer rede pública é considerado uma forma de comunicaçãoessencialmente insegura.

Para mais informações sobre o funcionamento do e-mail e uma visão geral dos ajustes de configuraçãocomuns, veja o capítulo E-mail no Guia de Referência do Red Hat Enterprise Linux. Esta seçãoassume 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ênciado Red Hat Enterprise Linux.

É recomendado a qualquer um planejando implementar um servidor Sendmail, resolver as seguintesquestões.

5.7.1. Limitar um Ataque Denial of ServiceDevido à 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 porsegundo. Por default, o Sendmail não limita o número de conexões. Se um limite for definido ealcançado, conexões futuras terão demora.

• confMAX_DAEMON_CHILDREN — O número máximo de processos-filho que podem ser geradospelo servidor. Por default, o Sendmail não determina um número limite de processos-filho. Se umlimite 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 paraque 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 umamensagem.

• confMAX_MESSAGE_SIZE — O tamanho máximo aceitável (em bytes) para qualquer mensagem.

5.7.2. NFS e SendmailNunca 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áriospodem ter o mesmo UID, e portanto receber e ler a correspondência do outro. Isso não ocorre com oNFSv4 usando Kerberos, já que o módulo SECRPC_GSS do kernel não utiliza a autenticação baseadano UID.

5.7.3. Usuários Mail-onlyPara ajudar a prevenir exploits locais no servidor Sendmail, é melhor que usuários de mail acessem oSendmail usando apenas um programa de email. Contas shell não devem ser permitidas no servidor demail 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).


5.8. Verificando Quais Portas estão EscutandoApó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 é questionara lista da rede ao digitar comandos como netstat -an ou lsof -i. Este método é menos confiáveljá que estes programas não conectam à máquina pela rede, mas checam o que está sendo executadono sistema. Por esta razão, estas aplicações são alvos frequentes de substituição por atacantes. Destamaneira, 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 portascomo o nmap.

O comando a seguir, submetido em um console, determina quais portas estão escutando conexões FTPpela 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 EDTInteresting ports on localhost.localdomain (127.0.0.1):(The 1653 ports scanned but not shown below are in state: closed)PORT STATE SERVICE22/tcp open ssh25/tcp open smtp111/tcp open rpcbind113/tcp open auth631/tcp open ipp834/tcp open unknown2601/tcp open zebra32774/tcp open sometimes-rpc11Device type: general purposeRunning: Linux 2.4.X|2.5.X|2.6.XOS 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. Noentanto, também há um serviço misterioso na porta 834. Para verificar se a porta está associada à listaoficial 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 porta834 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 portanum 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


porta aberta pertence ao ypbind (NIS), que é um serviço RPC administrado juntamente ao serviçoportmap.

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 umamáquina. Estas ferramentas são flexíveis e podem prover uma riqueza de informações sobre osserviços e configurações da rede. Portanto, recomendamos fortemente que você consulte as páginasman do lsof, netstat, nmap e services.

Capítulo 6.Redes Privadas Virtuais (Virtual PrivateNetworks)

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 umasoluçã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 custosassociados 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 diferedo frame relay ou do ATM em seu meio de transporte. As VPNs transmitem através de IP usandodatagramas como a camada de transporte, tornando-o um condutor seguro através da Internet, paraum determinado destino. A maioria das implementações VPN de software livre incorporam métodosde 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 outrasusam software ou implementações baseadas em protocolos. Há diversos fabricantes de soluções VPNde hardware como Cisco, Nortel, IBM e Checkpoint. Existe uma solução VPN baseada em softwaregratuito para Linux chamada FreeS/Wan, que utiliza uma implementação padronizada do IPSec (ouInternet Protocol Security). Estas soluções VPN, independentemente de serem baseadas em hardwareou 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, chamadoCabeçalho de Autenticação (Authentication Header, AH). Os dados são criptografados e agrupadoscom instruções para resolução e descriptografia, chamadas Encapsulating Security Payload (ESP). Oroteador VPN receptor depura as informações de cabeçalho, descriptografa os dados e os roteia aodestino 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. Oprocesso de criptografia/descriptografia numa conexão VPN rede-a-rede é transparente para o nódulolocal.

Com um nível tão elevado de segurança, não basta ao cracker interceptar o pacote, mas tambémdescriptografar o pacote. Intrusos que aplicarem um ataque man-in-the-middle entre um servidor e ocliente 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 efetivopara conectar múltiplos nódulos remotos para atuar como uma intranet unificada.

6.1. VPNs e Red Hat Enterprise LinuxOs usuários do Red Hat Enterprise Linux têm várias opções em termos de implementação de umasoluçã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. IPsecO Red Hat Enterprise Linux suporta o IPsec para conectar máquinas e redes remotas entre si usandoum túnel seguro em uma rede de transporte comum, como a Internet. O IPsec pode ser implementadousando 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 usaTroca 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 entresistemas conectados.

Uma conexão IPsec é dividida em duas fases lógicas. Na fase 1, um nódulo do IPsec inicia a conexãocom o nódulo ou rede remota. O nódulo/rede remota verifica as credenciais do nódulo pedinte e ambaspartes negociam o método de autenticação da conexão. Nos sistemas Red Hat Enterprise Linux, umaconexão IPsec usa o método de chave pré-compartilhada (pre-shared key) para autenticação do nóduloIPsec. Numa conexão IPsec com chave pré-compartilhada, ambas máquinas devem usar a mesmachave 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 deconfiguraçã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. Odeamon do chaveiro racoon é responsável pela distribuição e troca de chaves IKE.

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

• /lib/libipsec.so — biblioteca que contém a interface socket de gerenciamento da chave deconfianç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 maisinformaçõ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 controlaras 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 maisinformaçõ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 paraconfigurar vários aspectos da conexão IPsec, incluindo métodos de autenticação e algoritmos decriptografia usados na conexão. Para uma lista completa das diretivas disponíveis, consulte a páginaman (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 maisinformaçõ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 umaLAN/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 IPsecO IPsec pode ser configurado para conectar um computador pessoal ou estação de trabalho a outraatravés de uma conexão máquina-a-máquina. Este tipo de conexão utiliza a rede à qual cada máquinaestá conectada para criar o túnel seguro entre elas. Os requisitos de uma conexão máquina-a-máquinasão mínimos, já que é a configuração do IPsec em cada máquina. As máquinas precisam somente deuma conexão dedicada a uma rede de transporte (como a Internet) e do Red Hat Enterprise Linux paracriar a conexão do IPsec.

O primeiro passo para criar uma conexão é coletar as informações de sistemas e de rede de cadaestação de trabalho (workstation). Para uma conexão máquina-a-máquina, você precisa das seguintesinformaçõ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 decriptografia durante a sessão

Por exemplo: suponha que as estações de trabalho A e B queiram se interconectar através de umtúnel IPsec. Pretendem se conectar usando uma chave pré-compartilhada com o valor foobarbaze os usuários concordam em deixar que o racoon gere automaticamente e compartilhe uma chavede autenticação entre cada máquina. Ambos usuários das máquinas decidem nomear suas conexõescomo ipsec0.

Veja o arquivo ifcfg da estação de trabalho (workstation) A para uma conexão IPsecmáquina-a-máquina com a estação de trabalho B (o nome único para identificar aconexão neste exemplo é ipsec0, portanto o arquivo resultante é nomeado como/etc/sysconfig/network-scripts/ifcfg-ipsec0).

DST=X.X.X.XTYPE=IPSECONBOOT=yesIKE_METHOD=PSK

A estação de trabalho A substituirá X.X.X.X pelo endereço IP da estação de trabalho B, enquantoesta deve substituir X.X.X.X pelo endereço IP da estação de trabalho A. A conexão é definidapara 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 paraautenticarem-se entre si. O conteúdo deste arquivo deve ser idêntico nas duas estações de trabalho, esomente 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


Para alterar a chave de autenticação a qualquer momento, edite o arquivo keys-ipsec0 nas duasestaçõ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 roteadorIPsec remoto). Note que este arquivo é gerado automaticamente quando o túnel IPsec é ativado e nãodeve 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 asseguintes 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 aonó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çãoagressivo, que reduz a sobrecarga da conexão enquanto permite a configuração de diversasconexõ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 EnterpriseLinux 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 EncryptionStandard (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 HatEnterprise 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.


Os arquivos /etc/racoon/racoon.conf devem ser idênticos em todos os nódulos IPsec, excetopela 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çãoinclude é o endereço IP da estação de trabalho B. O oposto vale para a estação de trabalho B. Vejaa 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, arquivosde chaves pré-compartilhadas e certificados. Os campos sainfo anonymous descrevem a SA dafase 2 entre os nódulos IPsec — a natureza da conexão IPsec (incluindo os algoritmos suportados decriptografia 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 IPseccoincidam.

pfs_group 2

Define o protocolo Diffie-Hellman de troca de chaves, o que determina o método através do qualos nódulos do IPsec estabelecem uma chave de sessão temporária mútua para a segunda faseda conectividade IPsec. Por default, a implementação IPsec do Red Hat Enterprise Linux usa ogrupo 2 (ou modp1024) dos grupos de troca de chave criptográfica Diffie-Hellman. O grupo 2 usauma exponenciação modular de 1024 bits, evitando que atacantes descriptografem transmissõesIPsec 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 bytesde 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 suporta3DES, 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 deautenticação de mensagem sha1 e md5 hashed (HMAC).


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õeslentas.

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 sendotransferidos entre as máquinas (ou redes) e verificar se estão criptografadas via IPsec. O pacote deveincluir 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 IPsecO IPsec também pode ser configurado para conectar uma rede inteira (como uma LAN ou WAN) auma rede remota através de uma conexão rede-a-rede. Este tipo de conexão requer a configuraçãode roteadores IPsec em cada lado das redes conectadas para processar e rotear transparentementeinformações de um nódulo de uma LAN para outro nódulo de uma LAN remota. A Figura 6-1 mostrauma 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 paraautenticar 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 pacotesentre estas LANs. O processo de comunicação entre um nódulo no intervalo IP 192.168.1.0/24 eoutro 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 roteadorIPSEC.

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 como192.168.0.0/24 ou 10.0.1.0/24)


• 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 criptografiadurante 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 separadosde 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 pontode roteamento para processar e transmitir pacotes da LAN de um nódulo da rede a outros nódulos darede remota.

A conexão IPsec entre as redes usa uma chave pré-compartilhada com o valor r3dh4tl1nux, e osadministradores de A e B concordam em deixar que o racoon gere automaticamente e compartilheuma chave de autenticação entre cada um dos roteadores IPsec. O administrador da LAN A decidenomear a conexão IPsec como ipsec0, enquanto o administrador da LAN B nomeia a conexão IPseccomo ipsec1.

Veja o conteúdo do arquivo ifcfg para uma conexão IPsec rede-a-rede da LAN A. O nome únicopara identificar a conexão neste exemplo é ipsec1, portanto o arquivo resultante é nomeado como/etc/sysconfig/network-scripts/ifcfg-ipsec1.

TYPE=IPSECONBOOT=yesIKE_METHOD=PSKSRCGW=192.168.1.254DSTGW=192.168.2.254SRCNET=192.168.1.0/24DSTNET=192.168.2.0/24DST=X.X.X.X

A conexão é configurada para iniciar na inicialização da máquina (ONBOOT=yes) e usa o métodode autenticação de chave pré-compartilhada (IKE_METHOD=PSK). O administrador da LAN Aindica 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 daporta de comunicação da LAN A (SRCGW=192.168.1.254). O administrador então indica a rede dedestino, que é o intervalo de rede da LAN B (DSTNET=192.168.2.0/24) e também a rede deorigem (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 paraa LAN B), que as duas redes usam para autenticarem-se entre si. O conteúdo destes arquivos deve seridê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:


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

Para alterar a chave de autenticação a qualquer momento, edite o arquivo keys-ipsecX nos doisroteadores 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. Noteque a linha include na parte inferior do arquivo é automaticamente gerada e aparece somente se otú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 é nomeadocomo X.X.X.X.conf (substitua X.X.X.X pelo endereço IP do roteador IPsec remoto). Note queeste 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 comoroot em cada roteador:

/sbin/ifup ipsec0


As conexões são ativadas e as duas LANs, A e B, são capazes de comunicar entre si. As rotas sãocriadas automaticamente através do script de início invocado pela execução do ifup na conexãoIPsec. 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 (eth0neste exemplo) para visualizar os pacotes de rede sendo transferidos entre as máquinas (ou redes) epara verificar se estão criptografados com IPsec. Por exemplo: para verificar a conectividade da LANA, 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 queestá 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)

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 mecanismodedicado 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 poderosaspara auxiliar administradores e engenheiros de segurança em questões de controle de acesso em nívelde rede.

Juntamente às soluções VPN, como CIPE ou IPSec (abordados no Capítulo 6), os firewalls são um doscomponentes centrais da implementação de segurança na rede. Diversos fabricantes comercializamsoluções de firewall para suprir todos os nichos do mercado: de usuários domésticos protegendo umPC até soluções de centro de dados para proteger informações corporativas vitais. Firewalls podemser soluções de hardware ligados intermitentemente, como as aplicações de firewall da Cisco, Nokia eSonicwall. Também há soluções de software de firewall proprietárias desenvolvidas para os mercadosdomé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 comoos firewalls funcionam, que separam uma solução da outra. A Tabela 7-1 detalha três tipos comuns defirewalls e como eles funcionam:

Método Descrição Vantagens Desvantagens

NAT Tradução do Endereço daRede (Network AddressTranslation, NAT) inseresub-redes IP internas portrás de um ou um pequenogrupo de endereços IPpúblicos, mascarando todosos pedidos para uma fonteao invés de várias.

0 Pode ser configuradotransparentemente paramáquinas em uma LAN0 A proteção de muitasmáquinas e serviços portrás de um ou maisendereços IP externossimplifica tarefas deadministração0 A restrição de acesso dousuário de e para a LANpode ser configuradaabrindo e fechando portasno firewall/gateway da NAT

0 Não pode evitar atividadesmaldosas uma vez queusuários se conectam a umserviço fora do firewall

66 Capítulo 7. Firewalls

Método Descrição Vantagens Desvantagens

FiltrodePacotes

Um firewall de filtragem depacotes lê cada pacote dedados que passa por dentroe por fora de uma LAN.Pode ler e processar pacotespela informação docabeçalho e filtrar o pacotebaseado em conjuntos deregras programáveisimplementadas peloadministrador do firewall. Okernel do Linux tem afuncionalidade embutida defiltragem de pacotes atravésdo sub-sistema Netfilter dokernel.

1 Personalizável através dafuncionalidade front-endiptables1 Não requer nenhumapersonalização no lado docliente, já que todas asatividades da rede sãofiltradas no nível doroteador ao invés do nívelda aplicação1 Já que os pacotes não sãotransmitidos através de umproxy, o desempenho darede é mais rápido devido àconexão direta do cliente àmáquina remota

1 Não pode filtrar pacotespara conteúdo similar afirewalls de proxy1 Processa pacotes nacamada do protocolo, masnão pode filtrar pacotesnuma camada de aplicação1 Arquiteturas de redecomplexas podem fazercom que o estabelecimentode regras de filtragem depacotes se torne difícil,especialmente se for usadocom o mascaramento do IPou sub-redes locais e redesDMZ

Proxy Firewalls de proxy filtramtodos os pedidos de umdeterminado protocolo outipo dos clientes LAN parauma máquina proxy, queentão faz estes pedidos àInternet representando ocliente local. Uma máquinaproxy atua como um bufferentre usuários remotosmaldosos e as máquinas dosclientes internos da rede.

1 Dá aos administradores ocontrole de quaisaplicações e protocolosfuncionam fora da LAN1 Alguns servidores proxypodem armazenar dadosfrequentemente acessadosno cache localmente, aoinvés de ter que usar aconexão Internet parasolicitá-los, o que éconveniente para reduzir oconsumo desnecessário debanda1 Os serviços proxy podemser registrados emonitorados de perto,permitindo um controlemais restrito sobre autilização de recursos narede

1 Proxies sãofrequentemente específicosàs aplicações (HTTP,Telnet, etc.) ou restritos aprotocolos (a maioria dosproxies funcionam comserviços conectados porTCP, somente)1 Serviços de aplicação nãopodem rodar por trás deum proxy, portanto seusservidores de aplicaçõesdevem usar uma formaseparada de segurança emrede1 Proxies podem se tornarum gargalo na rede, já quetodos os pedidos etransmissões passam atravésde uma mesma fonte aoinvés de passar diretamentedo cliente para um serviçoremoto

Tabela 7-1. Tipos de Firewall

7.1. Netfilter e iptablesO kernel do Linux apresenta um sub-sistema de rede poderoso chamado Netfilter. O sub-sistemaNetfilter oferece filtragem de pacote de estado (que guarda o estado das conexões inciadas pelosclientes) ou sem estado/’stateless’ (na qual cada pacote é analisado individualmente, sem levar emconta pacotes anteriores trocados na mesma conexão), assim como NAT e serviços de mascaramentode IP. O Netfilter também tem a habilidade de danificar as informações do cabeçalho para roteamentoavançado e gerenciamento do estado de conexão. O Netfilter é controlado através da funcionalidadeiptables.

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 derede; enquanto o ipchains usava conjuntos de regras complexas para filtrar localidades de fonte edestino, 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 umainterface de linha de comando.

Esta seção oferece uma visão geral do iptables. Para informações mais detalhadas sobre oiptables, consulte o Guia de Referência do Red Hat Enterprise Linux.

7.2. Usando o iptablesO 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 stopchkconfig ip6tables off

Para fazer com que o iptables inicie por default sempre que a máquina for inicializada, você devealterar 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 nomeda corrente para uma regra. As três correntes embutidas do iptables (ou seja, as correntes queafetam todos os pacotes que trafegam pela rede) são INPUT, OUTPUT e FORWARD. Estas correntessão permanentes e não podem ser apagadas. A opção -j target (alvo) especifica a localidade noconjunto de regras do iptables onde essa regra específica deve pular. Alguns alvos embutidos sãoACCEPT, DROP e REJECT.

Correntes novas (também chamadas de correntes definidas pelo usuário) podem ser criadas usando aopção -N. Criar uma corrente nova é útil para personalizar ou elaborar regras.

7.2.1. Normas Básicas de FirewallEstabelecer normas básicas de firewall é a base para criar outras regras detalhadas definidas pelousuá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


específicos, analisando-os caso-a-caso. As seguintes regras bloqueiam todos os pacotes entrando esaindo de uma porta de comunicação (gateway) de rede:

iptables -P INPUT DROPiptables -P OUTPUT DROP

Adicionalmente, é recomendado que qualquer pacote encaminhado — tráfego de rede roteado dofirewall para seu nódulo de destino — seja negado também, para restringir os clientes internos daexposiçã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 desegurança em particular. As seguintes seções descrevem algumas regras que você talvez implementeenquanto 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 sistemafor reinicializado, as regras serão automaticamente eliminadas e restauradas. Para salvar as regras demodo 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 oserviço é iniciado, reiniciado ou quando a máquina é reinicializada.

7.3. Filtragem Comum do iptablesManter atacantes remotos fora de uma LAN é um aspecto importante da segurança de rede, senãoo 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 bloqueartodos 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 permitira usuários executar funções relacionadas à rede e a usar aplicações de rede, os administradores devemabrir 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 ACCEPTiptables -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 ACCEPTiptables -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ãoderrubados e uma outra corrente é adicionada (-A) para permitir pacotes do 192.168.100.13 (que


está dentro da sub-rede restrita derrubada), então a regra adicionada é ignorada. Você deve definiruma 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 pelacorrente na qual deseja inserir a regra e o número da regra (1,2,3,...,n) onde você deseja que aregra 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 loopbacklocal.

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 comrecursos baseados em PPP (tais como bancos de modem ou contas ISP volumosas), o acesso discadopode ser usado para circundar as barreiras do firewall seguramente, já que conexões via modem ficamtipicamente por trás de um firewall/gateway por serem conexões diretas. Entretanto, casos especiaispodem ser elaborados para usuários remotos com conexões de banda larga. Você pode configurar oiptables para aceitar conexões de clientes SSH remotos. Por exemplo: para permitir o acesso SSHremoto, as seguintes regras podem ser usadas:

iptables -A INPUT -p tcp --dport 22 -j ACCEPTiptables -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 doRed 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 conectadodiretamente à Internet ou firewall/porta de comunicação (gateway). No entanto, não permitem que osnódulos por trás do firewall/porta de comunicação acessem estes serviços. Para permitir o acesso LANa estes serviços, você pode usar o NAT com regras de filtragem do iptables.

7.4. Regras FORWARD e NATA maioria das empresas designam um número limitado de endereços IP publicamente roteáveis deseus ISPs. Devido essa permissão limitada, os administradores devem encontrar maneiras criativas decompartilhar o acesso aos serviços de Internet sem dar endereços IP limitados para cada nódulo daLAN. Usar um endereço IP privado é a maneira comum de permitir que todos os nódulos de uma LANacessem 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 naLAN. Ao mesmo tempo, o firewall/portas de comunicação (gateways) também podem rotear pedidosde saída de um nódulo da LAN para o serviço remoto da Internet. Esse encaminhamento de tráfego derede pode se tornar perigoso às vezes, especialmente com a disponibilidade de ferramentas de crackingmodernas que podem espionar endereços IP internos e fazer com que a máquina remota do atacanteatue como um nódulo em sua LAN. Para evitar isso, o iptables oferece normas de roteamento eencaminhamento 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 emuma 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 serdefinidas:

iptables -A FORWARD -i eth1 -j ACCEPTiptables -A FORWARD -o eth1 -j ACCEPT


Essa regra da acesso para a rede interna aos sistemas por trás do firewall/porta de comunicação. Aporta de comuncação roteia os pacotes de um nódulo da LAN para o seu nódulo pretendido, passandotodos 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 comoroteadores 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ódulosda 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úblicasexternas, configure o firewall com o mascaramento do IP, que mascara pedidos de nódulos da LANcom 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 IPprivado 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 oalvo -j DNAT da corrente PREROUTING na NAT para especificar um endereço IP e porta de destinopara onde encaminhar os pacotes de entrada requisitando uma conexão. Por exemplo: se você desejaencaminhar os pedidos HTTP de entrada para seu servidor Servidor HTTP Apache dedicado para172.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 encaminharpacotes 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 parapermitir o encaminhamento de pedidos HTTP de entrada para possibilitar o roteamento do destinoda NAT. Para fazer isso, submeta o seguinte comando:


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 destinopretendido 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 localespecial dedicada a prover serviços num meio público como a Internet. Por exemplo: para definir umaregra 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 tabelaPREROUTING 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 servidorHTTP em uma rede separada do resto da rede interna. Esta forma de segmentação de rede pode sermais segura que permitir conexões HTTP para uma máquina na rede. Se o servidor HTTP estiverconfigurado 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é anódulos específicos, dentro de uma LAN. Você também pode restringir que determinados serviçosdú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 deelite na terminologia dos crackers). Como não há serviços legítimos que comunicam através destasportas fora do padrão, bloqueá-los pode diminuir efetivamente as chances de nódulos potencialmenteinfectados em sua rede se comunicarem independentemente com seus servidores mestres remotos.

iptables -A OUTPUT -o eth0 -p tcp --dport 31337 --sport 31337 -j DROPiptables -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 IPprivados 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, porexemplo) derrube quaisquer pacotes parta este dispositivo com um endereço do intervalo de IP de suaLAN. Como norma default, é recomendado rejeitar pacotes encaminhados, portanto qualquer outroendereç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 comregras adicionais. REJECT um alvo nega acesso e retorna um erro connection refused (conexãonegada) para usuários que tentarem se conectar ao serviço. A ação DROP (derrubar) um alvo, comoo nome sugere, derruba os pacotes sem nenhum aviso. Administradores podem usar sua própriaprudência ao lidar com estes alvos; entretanto, para evitar a confusão do usuário e tentativas paracontinuar conectando, a REJECT alvo é recomendada.


7.6. iptables e Registro de ConexãoO iptables inclui um módulo que permite aos administradores inspecionar e restringir conexões aserviços disponíveis numa rede interna, usando um método chamado registro de conexão (connectiontracking). O registro de conexão armazena as conexões numa tabela, que permite aos administradorespermitir 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 umaconexão existente, como conexões FTP passivas, nas quais a porta de conexão é 20, mas a porta detransferê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 registrodas 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 aseguir mostra uma regra que usa o registro de conexão para encaminhar somente os pacotes associadosa uma conexão estabelecida:

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

7.7. ip6tablesA 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 transportecientes 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 ocomando ip6tables. O primeiro passo para usar o ip6tables é iniciar o serviço ip6tables. Istopode 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 stopchkconfig iptables off

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

chkconfig --level 345 ip6tables on


A sintaxe é idêntica à do iptables em todos os aspectos, exceto pelo fato do ip6tables suportarendereços de 128 bits. Por exemplo: as conexões SSH em um servidor de rede ciente do IPv6 podemser 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 AdicionaisHá diversos aspectos do firewall e do sub-sistema Netfilter do Linux que não foram abordados nestecapí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 eno 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 acriação de firewalls de rede e servidores usando tecnologia de filtragem open source como Netfiltere iptables. Inclui tópicos como a análise de registros de firewalls, criação de regras de firewall ea 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ópicosadicionais de segurança, como questões de acesso remoto e sistemas de detecção de intrusão tam-bém são abordados.

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 redea ferramentas de cracking, um administrador pode aprender mais sobre a proteção de um sistema e deuma rede, crackeando-os.

Índice8. 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ãopodem garantir que seus sistemas estão seguros contra uma intrusão. Os roteadores ajudam a protegersuas portas de comunicação (gateways) com a Internet. Firewalls ajudam a proteger a fronteira darede. Redes Privadas Virtuais (Virtual Private Networks - VPNs) podem transferir dados seguramenteatravé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çãodas 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 seussistemas. 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 efoco. A segurança da informação não para.

8.1. Pensando Como o InimigoSuponha 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 complexidadedos 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 grandeempresa 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çossejam interrompidos.

Para aprimorar as tecnologias de segurança e auxiliar na proteção de sistemas, redes e dados, você devepensar como um cracker e medir a segurança de seus sistemas verificando suas fraquezas. Avaliaçõespreventivas de vulnerabilidades em seus próprios sistemas e recursos de rede podem revelar questõespotenciais 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 dereconhecimento, 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ãoclassificados em alto, médio e baixo risco, e métodos são discutidos para melhorar a segurança (oupara minimizar o risco de vulnerabilidade) do alvo.

Se tivesse que executar uma avaliação de vulnerabilidade da sua casa, você provavelmente verificariacada uma das portas para certificar-se de que elas estão fechadas e trancadas. Você também checariatodas 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á reagirrapidamente às suas ações.

8.2. Definindo Avaliação e TestesAs avaliações de vulnerabilidade podem ser divididas em dois tipos: Olhando de fora para dentro eolhando 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 deum cracker. Você vê o que o cracker vê — endereços IP publicamente roteáveis, sistemas em suaDMZ, 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, talcomo 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 suaempresa lhe proporciona privilégios — mais elevados que qualquer externo. Ainda hoje em algumasempresas, a segurança é configurada de modo a manter os intrusos fora. Muito pouco é feito paraproteger os internos da empresa (tais como firewalls departamentais, controles de acesso no nível deusuário, procedimentos de autenticação para recursos internos e outros). Geralmente, há muito maisrecursos quando olhamos de dentro ao redor dado que a maioria dos sistemas são internos a umaempresa. Uma vez que você se coloca fora da empresa, imediatamente terá o status não confiável. Ossistemas 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 umaavaliaçã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 vulnerabilidadespotenciais, 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 efísica, é dinâmica. Executar uma avaliação traz uma visão geral, que pode incluir falsos positivos efalsos negativos.

Administradores de segurança são tão bons quanto as ferramentas que usam e o conhecimento quepossuem. 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 doprograma 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 (falsosnegativos).

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 naprodutividade 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 MetodologiaPara auxiliar na selação de ferramentas para a avaliação de vulnerabilidade, é útil estabelecer umametodologia de avaliação de vulnerabilidade. Infelizmente, não há nenhuma metodologia pré-definidaou 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ãoutilizadas.

Para aprender mais sobre o estabelecimento de metodologias, consulte os seguintes websites:

• http://www.isecom.org/projects/osstmm.htm — The Open Source Security Testing MethodologyManual (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 FerramentasUma avaliação pode começar com o uso de alguma forma de ferramenta de coleta de informações. Aoavaliar 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 outroconjunto de ferramentas. Saber quais ferramentas utilizar deve ser o passo crucial para encontrarvulnerabilidades.

Assim como em qualquer aspecto do cotidiano, há muitas ferramentas diferentes que desempenhama 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 (baseadasnos protocolos utilizados). Algumas ferramentas são grátis e outras não. Algumas ferramentas sãointuitivas 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êncaconta. Se possível, monte um laboratório de testes e experimente quantas ferramentas puder, anotandoos 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 ouaté mesmo listas de discussão específicas da ferramenta.

As ferramentas explanadas abaixo são apenas uma pequena amostra das ferramentas disponíveis.


8.3.1. Scaneando Máquinas com NmapNmap é 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 ferramentamais utilizada na coleta de informações. Há uma página man excelente, que oferece uma descriçãodetalhada de suas opções e usos. Administradores podem usar o Nmap em uma rede para encontrarsistemas hospedeiros e portas abertas nestes sistemas.

O Nmap é um primeiro passo eficaz na avaliação de vulnerabilidade. Você pode mapear todas asmáquinas dentro de uma rede, e inclusive passar uma opção que a permite ao Nmap tentar identificaro sistema operacional rodando numa determinada máquina. O Nmap é uma boa base para estabelecernormas de uso de serviços seguros e para parar serviços não usados.

8.3.1.1. Usando o NmapO Nmap pode ser executado a partir de uma janela de comandos, digitando nmap seguido do nome damá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 Service22/tcp open ssh25/tcp open smtp111/tcp open sunrpc443/tcp open https515/tcp open printer950/tcp open oftep-rpc6000/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 ounã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. NessusO Nessus é um scanner de segurança ’full-service’. A arquitetura plug-in do Nessus permite queusuários personalizem-no para seus sistemas e redes. Assim como qualquer scanner, o Nessus é tãobom 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 devulnerabilidades em tempo real. Lembre-se que pode haver falsos positivos e falsos negativos, mesmonuma 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. NiktoO 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 deintrusão. Acompanha uma documentação excelente que dever ser revisada cuidadosamente antes deexecutar o programa. Se você tem servidores Web servindo scripts CGI, o Nikto pode ser um excelenterecurso 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 ScannerO VLAD é um scanner de vulnerabilidades desenvolvido pela equipe RAZOR da Bindview, Inc., queverifica a lista das dez questões mais comuns de segurança da SANS (questões do SNMP, questões decompartilhamento de arquivo, etc). Apesar de não ter tantas funcionalidades quanto o Nessus, vale apena 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/


8.3.5. Antecipando Suas Necessidades FuturasDependendo do seu alvo e recursos, há muitas ferramentas disponíveis. Há ferramentas para redessem fio, redes Novell, sistemas Windows, sistemas Linux e outros. Outra parte essencial ao executaravaliações deve incluir a revisão da segurança física, cobertura de pessoal ou avaliação da rede devoz/PABX. Conceitos novos como o war walking — scanning do perímetro das estruturas físicas desua 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 algumasmedidas pró-ativas que um administrador pode tomar para evitar quebras na segurança, tais comoformar uma equipe de resposta a emergências, capaz de responder rápida e efetivamente a questõesde segurança. Além disso, esta parte também detalha os passos a tomar para agupar e analisar asevidências de uma quebra na segurança após o fato ter ocorrido.

Índice9. Detecção de Invasão ...................................................................................................................... 8510. 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 casassão equipadas com sistemas de alarme capazes de deter ladrões, notificar as autoridades na ocasião deuma invasão e inclusive alertar o proprietário quando sua casa estiver sendo incendiada. Tais medidassã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 mesmotempo, 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çosnã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. Sistemasde detecção de intrusão foram elaborados para agir como este sistema de alerta.

9.1. Definindo Sistemas de Detecção de IntrusãoUm sistema de detecção de intrusão (intrusion detection system, IDS) é um processo ou dispositivoativo 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, oobjetivo final de qualquer IDS é capturar os infratores na ação antes de realmente danificarem seusrecursos.

Um IDS protege um sistema de ataques, mal-uso e danos. Também pode monitorar as atividades darede, 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 IDSsEntender o que é um IDS e as funcionalidades que oferece é essencial para determinar qual será o tipoapropriado para incluir em suas normas de segurança em informática. Esta seção aborda os conceitospor trás dos IDSs, as funcionalidades de cada tipo de IDS e a emergência de IDSs híbridos que aplicamdiversas 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 encontraranomalias, que normalmente são sinais positivos de atividades maldosas. Alguns IDSs são serviçosisolados (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ãode sistema, configurações alteradas e registro de palavras, juntamente à intuição do administrador esua experiência em criar um kit de detecção de intrusão poderoso. Avaliar as diferentes técnicas dedetecçã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 IDSsbaseados na máquina e baseados na rede. Um IDS baseado na máquina é o mais detalhado dosdois, 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 narede afunila pacotes através de um único dispositivo antes de enviá-los a máquinas específicas. IDSsbaseados na rede são frequentemente encarados como menos detalhados, já que muitas máquinas numambiente 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 servidorUm IDS baseado na máquina analisa diversas áreas para determinar o mal-uso (atividades maléficasou truculentas dentro da rede) ou intrusão (incursões de fora). IDSs baseados na máquina consultamdiversos tipos de arquivos de registro (kernel, sistema, servidor, rede, firewall e outros) e comparamos registros a um banco de dados interno com assinaturas comuns de ataques conhecidos. IDSs UNIXe Linux baseados na máquina fazem uso constante do syslog e sua habilidade em separar eventosregistrados por sua severidade (por exemplo: pequenas mensagens de impressão versus sérios alertasdo kernel). O comando syslog é disponibilizado ao instalar o pacote sysklogd, inclulso no Red HatEnterprise Linux. Este pacote oferece registros do sistema e isolamento das mensagens do kernel. OIDS baseado na máquina filtra os registros (que, no caso de alguns eventos da rede e do kernel, podemser bastante verbalizados), analisa-os, renomeia as mensagens anômalas com sua própria classificaçãode 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 importantese executáveis. Checa um banco de dados de arquivos importantes (e quaisquer arquivos adicionadospelo administrador) e cria um checksum de cada arquivo com um utilitário de digestão do arquivo demensagem como o md5sum (algoritmo de 128 bits) ou o sha1sum (algoritmo de 160 bits). Então, oIDS 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ênciasnão bater, o IDS alerta o administrador via e-mail ou pager do celular. Este é o procedimento utilizadopelo Tripwire, explanado na Seção 9.2.1.

9.2.1. TripwireO Tripwire é o IDS do Linux baseado na máquina mais conhecido. A Tripwire, Inc., empresa dosdesenvolvedores do Tripwire, recentemente divulgou o código-fonte do software para a versão Linuxe o licenciou sob os termos da GNU General Public License. O Tripwire está disponível no sitehttp://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çãoconhecida.

9.2.2. RPM como um IDSO Gestor de Pacotes RPM (RPM) é outro programa que pode ser utilizado como um IDS baseadono servidor. O RPM contém várias opções para investigar pacotes e seus conteúdos. Estas opções deverificação podem ser muito preciosas para um administrador ao suspeitar que arquivos críticos dosistema e executáveis foram modificados.

A lista seguinte traz algumas opções para RPMs que podem verificar a integridade de arquivos numsistema Red Hat Enterprise Linux. Consulte o Guia de Administração de Sistemas Red Hat EnterpriseLinux 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 Hatpara o chaveiro RPM do sistema. Esta chave verifica se os pacotes instalados em seu sistemacontê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

da Red Hat. A chave pode ser importada atribuindo o seguinte comando como root (substituindo2 version 3 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 exibirnenhum 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,comoS.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 8caracteres (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ãode permissão do arquivo

• S — O teste encontrou um arquivo menor ou maior do que era ao ser originalmente instaladono 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á verificandocada pacote instalado).

rpm -Vf /bin/ls

A opção -Vf verifica arquivos individualmente em um pacote instalado. Ela pode ser útil aodesempenhar 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 arquivode pacote RPM. Pode ser utilizada para verificar se um pacote prestes a ser instalado é assinadopela Red Hat ou por qualquer organização para a qual você tenha a chave pública GPG importadapara um chaveiro GPG. Um pacote que não tenha sido assinado apropriadamente emitirá umamensagem de erro similar à seguinte:application-1.0.i386.rpm (SHA1) DSA sha1 md5 (GPG) NOT OK

(MISSING KEYS: GPG#897da07a)


Tenha cuidado ao instalar pacotes não assinados já que não são aprovados pela Red Hat, Inc. epodem 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çabackup dos conteúdos do diretório do banco de dados RPM (/var/lib/rpm/) para uma mídiasomente-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 dadosdo sistema, já que usuários mal intencionados podem corromper o banco de dados e desviar seusresultados.

9.2.3. IDSs baseados em outros servidoresA 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 foraminclusas 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 emarquivos de configuração do usuário. SWATCH foi desenvolvido para registrar qualquer evento queo usuário queira adicionar ao arquivo de configuração; no entanto, tem sido amplamente adotadocomo um IDS baseado na máquina.

• LIDS http://www.lids.org — O Sistema de Detecção de Intrusão Linux (Linux Intrusion DetectionSystem), LIDS, é um conserto do kernel e uma ferramenta de administração também capaz decontrolar modificações de arquivo com listas de controle de acesso (access control lists - ACLs), eproteger processos e arquivos, inclusive do usuário root.

9.3. IDS baseado em redeSistemas de detecção de intrusão baseados em rede operam de maneira diferente dos IDSs baseadosna máquina. A filosofia de desenvolvimento de um IDS baseado em rede é scanear os pacotes darede no nível da máquina ou roteador, auditorando informações de pacotes e registrando quaisquerpacotes suspeitos em um arquivo de registro especial com informações extras. Baseado nestes pacotessuspeitos, um IDS baseado em rede pode scanear seu próprio banco de dados de assinaturas de ataquesde rede conhecidos e determinar um nível de severidade para cada pacote. Se os níveis de severidadeforem suficientemente altos, um email de alerta ou mensagem de celular será enviada aos membrosda 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 deprotocolos 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 maldosasna 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 sistemaseja configurado para o modo promíscuo, que permite o dispositivo a capturar todos os pacotes quepassam na rede. O modo promíscuo pode ser configurado através do comando ifconfig, conformeo 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:01inet addr:192.168.1.50 Bcast:192.168.1.255 Mask:255.255.252.0UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1RX packets:6222015 errors:0 dropped:0 overruns:138 frame:0TX packets:5370458 errors:0 dropped:0 overruns:0 carrier:0collisions:0 txqueuelen:100RX bytes:2505498554 (2389.4 Mb) TX bytes:1521375170 (1450.8 Mb)Interrupt:9 Base address:0xec80

lo Link encap:Local Loopbackinet addr:127.0.0.1 Mask:255.0.0.0UP LOOPBACK RUNNING MTU:16436 Metric:1RX packets:21621 errors:0 dropped:0 overruns:0 frame:0TX packets:21621 errors:0 dropped:0 overruns:0 carrier:0collisions:0 txqueuelen:0RX 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 eth002: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; BROADCAST02: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 1502:05:54.636436 konsole.example.com.netbios-ns > 172.16.59.255.netbios-ns:\NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST02: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 sendoscaneados e registrados pelo tcpdump.


9.3.1. SnortApesar 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 asinformações dos pacotes na tela de output ou num arquivo de registro sem análise nenhuma. Um IDSapropriado analisa os pacotes, aponta transmissões de pacotes potencialmente maléficas e as armazenanum registro formatado.

O Snort é um IDS desenvolvido para ser detalhado e correto ao registrar com êxito as atividadesmaléficas da rede e notificar os administradores quando potenciais brechas ocorrerem. Snort utiliza abiblioteca 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ívelde assinaturas de ataque. Snort tem um banco de dados de ataques constantemente atualizadoque pode ser adicionado à ou atualizado via Internet. Os usuários podem criar assinaturasbaseadas 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áriaem 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 nestedocumento 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 faznecessária. É responsabilidade da equipe de segurança responder ao problema rápida e efetivamente.

10.1. Definindo Resposta ao IncidenteA 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 quepenetrou um firewall e está bisbilhotando o tráfego da rede interna. O incidente é uma infração dasegurança. A resposta depende de como a equipe de segurança reage, o que ela faz para mininmizaros 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 sistemasde 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 resultadosfinanceiros devastadores enquanto clientes e empresas aprendem a reagir negativamente na ocorrênciade comprometimento.

Pesquisas sobre as infrações anteriores na segurança (tanto internas quanto externas) mostram quealgumas empresas podem até ser fechadas como resultado de uma grave infração de segurança. Umainfração pode tornar recursos indisponíveis e roubar ou corromper dados. Mas é muito difícil estimarfinanceiramente os danos como má publicidade. Para ter uma idéia exata do quão importante é umaresposta eficiente a um incidente, uma empresa deve calcular o custo de uma infração e também osefeitos 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 eregularmente testado. Um bom plano de resposta ao incidente pode minimizar não somente os efeitosde 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 daseventuais transações usando um meio de rede não confiável, como a Internet), mas sim, quando umainfração ocorre. Não pense em um sistema como fraco e vulnerável; é importante perceber que quandohá 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 obterinformaçõ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 em20021.

O aspecto positivo de perceber a inevitabilidade de uma infração do sistema é que ela permite à equipede segurança desenvolver um curso das ações que minimizem qualquer dano potencial. Combinar ocurso das ações com habilidades permite à equipe responder a condições adversas de uma maneiraformal 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 paraerros, é 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 ComputerEmergency 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 umasituação catastrófica com computadores. Encontrar as competências cruciais para uma CERT pode serum desafio. O conceito de pessoal apropriado vai além das habilidades técnicas e inclui questões delogística, como localização, disponibilidade e desejo de colocar a empresa à frente da vida pessoalquando uma emergência ocorre. Uma emergência nunca é um evento planejado; pode acontecer aqualquer momento e todos os membros da CERT devem aceitar a responsabilidade de responder auma emergência a qualquer hora.

As equipes típicas de uma CERT incluem adminsitradores de sistemas e de rede, assim como peritosem segurança da informação. Os administradores de sistema provêm o conhecimento e habilidadesdos 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 rastreare 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ávelter uma área especializada na empresa, então deve haver treinamento para outras áreas sempre quepossível. Lembre-se que se somente uma pessoa tiver as informações cruciais para a segurança eintegridade dos dados, então a organização inteira ficará desamparada na ausência desta pessoa.

10.2.2. Considerações LegaisAlguns aspectos importantes da resposta ao incidente a considerar incluem as questões legais. Planosde segurança devem ser desenvolvidos juntamente aos membros da área jurídica ou algum tipo deconselho geral. Assim como toda empresa deve ter sua própria política de segurança corporativa, todaempresa tem sua própria maneira de lidar com incidentes sob a perspectiva legal. Questões regulatóriasem nível local, estadual e federal vão além do escopo deste documento, mas são mencionadas poisa metodologia de análise post-mortem será ditada, pelo menos em parte (ou em conjunto com), peloconselho 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 aimportância de restaurar os serviços em ambiente críticos como hospitais e bancos.

10.3. Implementando o Plano de Resposta ao IncidenteApó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 lentae num período fora do ar no evento de uma infração. Nestas circunstâncias os exercícios práticos sãomuito 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 comconfianç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 sistemasafetados, consertar o exploit e então reconectar rapidamente sem possíveis complicações futuras. Aequipe 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 deproduçã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 quaisprocessos devem ou não aparecer ao executar os comandos top ou ps. Administradores de rede estãocientes 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 anomaliamais rapidamente do que alguém que não esteja familiarizado com a infra-estrutura.

10.4. Investigando o IncidenteInvestigar uma infração de computador é como investigar a cena de um crime. Os detetives coletamevidências, anotam quaisquer pistas estranhas e fazem um inventário de perdas e danos. Uma análisedo comprometimento dos computadores pode ser feita enquanto o ataque ocorre ou post-mortem (apóso ataque).

Apesar de não ser recomendável confiar em nenhum arquivo de registro de um sistema que sofreuexploit, 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 eventose 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 ocomando script, conforme o exemplo a seguir:

script -q 6 file-name 7

Substitua 8 file-name 9 pelo nome do arquivo de registros do script. Sempre salve o arquivo deregistros em outra mídia que não o disco rígido do sistema comprometido — um disquete ou CD-ROMsã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 forpego.


10.4.1. Coletando uma Imagem EvidencialCriar um pequeno ’arquivo-espelho’ da mídia é um primeiro passo razoável. Se estiver executandotrabalho forênsico de dados, é um requerimento. É recomendado fazer duas cópias: uma para análisee investigação, e uma segunda para ser armazenada junto à original como evidência para quaisquerprocedimentos legais.

Você pode usar o comando dd, que é parte do pacote fileutils do Red Hat Enterprise Linux, paracriar 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 noqual você deseja criar a imagem. Conecte este disco como escravo ao sistema e então use o comandodd 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 paravelocidade. As opções conv=noerror,sync forçam o dd a continuar lendo e descarregando os dadosmesmo se encontrar setores danificados no disco suspeito. Agora é possível estudar o arquivo imagemresultante ou até tentar recuperar arquivos apagados.

10.4.2. Coletando Informação Pós-InfraçãoO 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 deaná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 listaalguns 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 ítenspara 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(ou disk dump) dos arquivos epartições. Combinado à verificaçãodos md5sums de cada imagem,administradores podem compararuma imagem pré-infração de umapartição ou arquivo com um sistemaque sofreu uma infração paraverificar se as consistênciascoincidem.

dd if=/bin/ls of=ls.dd|md5sum ls.dd >ls-sum.txt



grep Encontra trechos de informação(texto) úteis dentro de arquivos ediretórios, assim como revelapermissões, alterações de script,atributos de arquivos e muito mais.Utilizado principalmente como umcomando ’casado’ (piped) comoutro, como o ls, ps ou oifconfig.

ps auxw |grep /bin

strings Imprime os trechos de caracteresimprimíveis em um arquivo. É maisútil para examinar anomalias emarquivos executáveis comocomandos mail para endereçosdesconhecidos ou para registrar emarquivos de registro fora do padrão.

strings /bin/ps |grep’mail’

file Determina as características dearquivos baseado no formato,código, bibliotecas com as quais estáligado (se houver) e tipo de arquivo(binário, texto ou outros). É útil paradeterminar se um executável, como/bin/ls, foi modificado usandobibliotecas estáticas, o que é umsinal certeiro de que o executável foisubstituído por outro instalado porum usuário maléfico.

file /bin/ls

find Busca determinados arquivos emdiretórios. É uma ferramenta útilpara procurar na estrutura dodiretório por palavra-chave, data ehora de acesso, permissões e outroscritérios. Também pode ser útil paraadministradores que executamauditorias gerais do sistema emdeterminados arquivos ou diretórios.

find -atime +12 -name *log*-perm u+rw

stat Exibe informações sobre o status deum arquivo, inclusive a hora doúltimo acesso, permissões,configurações UID e GID e outras.Útil para verificar quando umsistema que sofreu infração foiutilizado ou modificado pela últimavez.

stat /bin/netstat



md5sum Calcula o checksum (verificação deconsistência) de 128 bits usando oalgoritmo md5 hash. Use estecomando para criar um arquivo textoque lista todos os executáveiscruciais que são frequentementemodificados ou substituídos em umcomprometimento da segurança.Redirecione as somas para umarquivo, a fim de criar um simplesbanco de dados de consistências, eentão copie o arquivo para umamídia somente-leitura como umCD-ROM.

md5sum /usr/bin/gdm>>md5sum.txt

Tabela 10-1. Ferramentas de Auditoria de Arquivos

10.5. Restaurando e Recuperando RecursosEnquanto 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çõesfora 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 sistemabackup.

A recuperação do sistema pode ser um processo tedioso. Em muitos casos há dois cursos de açõesa escolher. Administradores podem executar uma nova instalação do sistema operacional em cadasistema 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 SistemaExecutar uma reinstalação assegura que o sistema afetado será limpo de quaisquer trojans, backdoorsou processos maléficos. A reinstalação também assegura que quaisquer dados (se recuperados a partirde 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 osdados 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 muitaatenção. O perigo de consertar um sistema ao invés de reinstalar é determinar se você realmente livrou


o sistema de trojans, buracos na segurança e dados corrompidos. A maioria dos rootkits (programasou pacotes usados por um cracker para obter acesso root em seu sistema), comandos de sistema trojane ambientes de janela de comandos são desenvolvidos para ocultar atividades maléficas de auditoriassuperficiais. 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 IncidenteA ú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, taiscomo 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 conselhojurídico aplicado pela sua empresa, uma análise post-mortem pode se fazer necessária. Mesmo se nãofor um requisito funcional para uma análise do comprometimento, uma post-mortem pode ser muitovaliosa para entender como um cracker pensa e como seus sistemas estão estruturados, para assimprevenir futuros comprometimentos.

V. Apêndices

Esta parte aborda algumas das maneiras mais comuns usadas por intrusos para quebrar a segurançade sistemas de computador ou interceptar dados em trânsito. Esta parte também detalha alguns dosserviç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.

ÍndiceA. Proteção ao Hardware e à Rede................................................................................................ 101B. Exploits e Ataques Comuns....................................................................................................... 107C. 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 doRed 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çãoa 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çãodetalhada de alguns destes fatores.

• A computação envolve mais do que somente estações de trabalho rodando software. Empresasmodernas 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 eaplicações especializadas. Com estes requisitos corporativos, entretanto, aumentou a propensão afalhas 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 auma 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 domeio que o administrador escolher, determinadas mídias e tecnologias de rede requerem tecnologiascomplementares, 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 deseguranç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 — necessidadesda corporação e considerações de segurança — uma implementação que atenda uniformemente aosdois fatores.

A.1. Topologias de Rede SeguraA fundação de uma LAN é a topologia ou arquitetura de rede. A topologia é o layout físico e lógicode 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 aimplementação da rede. Cada topologia tem suas vantagens e questões de segurança que arquitetos derede devem considerar ao desenhar o layout de suas redes.

A.1.1. Topologias FísicasConforme definido pelo Institute of Electrical and Electronics Engineers (IEEE), há três topologiascomuns para a conexão física de uma LAN.

A.1.1.1. Topologia RingA topologia Ring conecta cada nódulo usando exatamente duas conexões. Isto cria uma estrutura ringna qual cada nódulo é acessível ao outro, diretamente por seus nódulos vizinhos fisicamente maispró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 umauniversidade, 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 (obackbone). A topologia de canal linear requer um mínimo de cabeamento e equipamento de rede, oque a torna a topologia de custo mais baixo. No entanto, o canal linear depende do backbone estarconstantemente disponível, tornando-o um ponto único de falha, caso seja necessário colocá-lo offlineou 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 EstrelaA topologia Estrela (Star) incorpora um ponto central onde os nódulos se conectam e através do quala comunicação é passada. Este ponto central, chamado de hub pode ser transmitido ou comutado. Estatopologia 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ãofacilmente rastreáveis para esta fonte única.

A.1.2. Considerações de TransmissãoA 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 aseguir 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ódulosaté que o receptor pretendido aceite o pacote. Cada nódulo da rede pode concebivelmente receber estepacote de dados até que o receptor processe o pacote. Em uma rede de transmissão, todos os pacotessão enviados desta maneira.

Em uma rede comutada (switched network), os pacotes não são transmitidos, mas processados no hubcomutado que, por sua vez, cria uma conexão direta entre os nódulos emissor e receptor. Isto eliminaa 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áriosmaléficos podem configurar seu dispositivo Ethernet para o modo promíscuo e aceitar todos os pacotesindependentemente 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 arquivostexto e, talvez, até enviar as informações para fontes arbitrárias (por exemplo: o enedereço de e-maildo usuário maléfico).

Uma rede comutada requer um comutador de rede, um componente de hardware especializado quesubstitui 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 utilizapara 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-fioUma questão emergente para as empresas é a mobilidade. Funcionários remotos, técnicos de campoe executivos requerem soluções portáteis, como laptops, organizadores pessoais digitais (PDAs) eacesso 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 correnteaprovado pelo IEEE é a especificação 802.11g para redes sem-fio, enquanto 802.11a e 802.11b sãopadrõ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, ediversos fabricantes comercializam produtos e serviços 802.11x. Os consumidores também adotaramo padrão para as redes em escritórios pequenos ou caseiros. A popularidade também extendeu-se dasLANs à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á provedoresde 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 compartilhamentode conexão rápida entre dois ou mais nódulos, mas introduz questões de escalabilidade não adequadaspara 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 fossena rede baseada na Ethernet. O WAP age efetivamente como uma ponte entre os nódulos conectadosa ele e o resto da rede.

A.1.3.1. Segurança da 802.11xApesar da rede sem-fio ser comparável em velocidade e certamente mais conveniente que os meios deredes com fios, há algumas limitações na especificação que autoriza consideração completa. A maisimportante 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 detomar as precauções de segurança mais básicas. Desde que toda a rede 802.11x esteja feita usandosinais RF de banda alta, os dados transmitidos são facilmente acessíveis a qualquer usuário com umNIC 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 dasredes privadas sem-fio, o padrão 802.11b usa o protocolo Wired Equivalency Privacy (WEP), umachave criotografada de 64 ou 128 bits baseada no RC-4 e compartilhada entre cada nódulo ou entre aWAP e o nódulo. Esta chave criptografa as transmissões e descriptografa pacotes de entrada dinâmicae transparentemente. Os administradores frequentemente deixam de implementar este esquema decriptografia 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 WEPem 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 Ferramentade Administração de Rede inclui uma funcionalidade para configurar a segurança de NICs e WEPsem-fio. Para informações sobre o uso da Ferramenta de Administração de Rede, consulte o Guiade Administração de Sistemas Red Hat Enterprise Linux.

Confiar no WEP, entretanto, ainda não é o suficiente em termos de proteção contra determinadosusuá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-sedestas, os administradores devem aderir a normas restritas em relação ao uso de métodos sem-fio parao acesso a informações delicadas. Pode-se optar por aumentar a segurança da conectividade sem-fiorestringindo-a somente a conexões SSH ou VPN, que introduz uma camada de criptografia adicional


sobre a criptografia WEP. Ao usar esta norma, um usuário maléfico externo à rede que craquear acriptografia 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 algoritmosproprietários com força ainda maior. Os administradores que aplicarem estas normas devem restringirprotocolos somente-texto (como Telnet ou FTP), já que senhas e dados podem ser expostos usandoquaisquer 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 configuraro WPA em sua rede usando um servidor de autenticação que administra as chaves de clientes queacessam a rede sem-fio. O WPA é melhor que a criptografia WEP pois usa o Temporal Key IntegrityProtocol (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. Osvalores 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 achave 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 cifrasde criptografia mais fortes (como AES) estão sob desenvolvimento e têm o potencial de aumentar aseguranç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 DMZsPara administradores que queiram rodar serviços acessíveis externamente (como HTTP, e-mail, FTPe 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 residemno mesmo segmento da rede. Os serviços acessíveis externamente devem residir no que a indústriada segurança chama de zona desmilitarizada (DMZ), um segmento da rede lógica onde o tráfego deentrada 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 darede 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 partirdos 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 firewallimplementadas com iptables ou firewalls de hardware dedicado permitem o roteamento complexoe o encaminhamento de regras. Os administradores podem usar estas normas para segmentar o tráfegode entrada para serviços específicos em endereços e portas específicos, enquanto permitir que somentea LAN acesse os serviços internos, o que pode evitar exploits de spoofing de IP. Para mais informaçõessobre a implementação do iptables, consulte o Capítulo 7.

A.2. Segurança de HardwareDe acordo com um estudo lançado em 2000 pelo FBI e o Computer Security Institute (CSI), mais desetenta por cento de todos os ataques a dados e recursos delicados reportados por empresas ocorreramdentro da própria empresa. Implementar normas de segurança interna é tão importante quanto umaestratégia externa. Esta seção explica algumas das medidas comuns que administradores e usuáriospodem 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á algumasmedidas 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 sistemano nível do hardware. Usuários de estações de trabalho podem determinar senhas administrativasno BIOS para impedir que usuários maléficos acessem ou inicializem o sistema. Senhas do BIOSimpedem que usuários maléficos inicializem o sistema de todas as maneiras, detendo o usuário deacessar 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 carregamlaptops 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 PCsem restrições de BIOS e acessar o disco rígido para ler seu conteúdo. Nestes casos, é recomendadoque estações de trabalho tenham bloqueios para restringir o acesso ao hardware interno. Dispositivosespeciais de segurança, como cabos de aço com cadeados, podem ser ligados ao chassis do PC e dolaptop 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 emsalas 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 contrao desligamento errôneo (ou intencional).

As empresas também podem usar provedores de co-locação para guardar seus servidores, já ques estesoferecem banda mais alta, suporte técnico 24h 7 dias por semana e conhecimento em segurança desistemas e servidores. Este pode ser um meio efetivo de terceirizar as necessidades de segurança econectividade para transações HTTP ou serviços de streaming media. No entanto, a co-locação podeter um alto custo, especialmente para pequenas e médias empresas. As estruturas de co-locação sãoconhecidas por ser altamente protegidas por seguranças treinados e monitoradas o ininterruptamente.

Apêndice B.Exploits e Ataques Comuns

A Tabela B-1 detalha alguns dos exploits e pontos de entrada mais comuns usados por intrusos paraacessar recursos de rede de organizações. As explicações de como estes exploits são executados ecomo administradores podem proteger sua rede apropriadamente são muito importantes contra taisataques.

Exploit Descrição Notas

Senha em brancoou default

Deixar senhas administrativas embranco ou usar a senha default providapelo fabricante. Isto é mais comum emhardware, como roteadores e firewalls,porém alguns dos serviços que rodamno Linux podem conter senhas defaultde administrador (apesar do Red HatEnterprise Linux não distribuí-las).

Comumente associado a hardware derede, como roteadores, firewalls,VPNs e aplicações dearmazenamento anexo à rede(network attached storage - NAS);Comum em muitos sistemasoperacionais legados, especialmenteaqueles que compoem serviços(como UNIX e Windows).

Às vezes, administradores criamalgumas contas de usuáriosprivilegiados com pressa e deixam asenha vazia, um ponto de entradaperfeito para usuários maldosos quedescobrem a conta.

ChavesCompartilhadasDefault

Serviços seguros às vezes empacotamchaves de seurança default paradesenvolvimento ou para testes deavaliação. Se estas chavespermanacerem inalteradas e estiveremlocalizadas em um ambiente deprodução na Internet, qualquerusuário com as mesmas chaves defaulttem acesso a este recurso de chavecompartilhada e a quaisquerinformações importantes contidasneste.

Mais comum em pontos de acessosem-fio e aplicações de servidorseguro pré-configuradas

CIPE (consulte o Capítulo 6) contémuma amostra de chave estática quedeve ser alterada antes da aplicaçãoem um ambiente de produção

108 Apêndice B. Exploits e Ataques Comuns


Spoofing do IP(alteração doendereço IP paraparecer comooutra máquna)

Uma máquina remota age como umnódulo em sua rede local, encontravulnerabilidades em seus servidores einstala um programa backdoor outrojan horse para obter controle sobreseus recursos de rede.

O Spoofing é bem difícil já querequer que o atacante adivinhe osnúmeros de TCP/IP SYN-ACK paracoordenar uma conexão que almejeos sistemas, mas há diversasferramentas disponíveis para auxiliarcrackers a executá-lo.

Depende de almejar sistemas queestejam rodando serviços (tais comorsh, telnet, FTP e outros) queutilizam técnicas de autenticaçãobaseadas na fonte, não recomendadasquando comparadas à PKI ou outrasformas de autenticação criptografadausadas no ssh ou SSL/TLS.

Eavesdropping(espionagem dotráfego de rede)

Coleta de dados que trafegam entredois nódulos ativos em uma redeatravés do eavesdropping na conexãoentre estes dois nódulos.

Este tipo de ataque geralmentefunciona com protocolos detransmissão somente-texto, comotransferências Telnet, FTP e HTTP.O atacante remoto deve ter accesso aum sistema comprometido em umaLAN para poder executar um ataquedeste tipo. Geralmente o cracker usaum ataque ativo (como um spoofingde IP ou ’man-in-the-middle’) paracomprometer um sistema na LAN

Medidas preventivas incluem serviçoscom troca de chave criptográfica,senhas descartáveis ou autenticaçãocriptografada para impedir snoopingde senha. Também recomenda-se aalta criptografia durante astransmissões

Apêndice B. Exploits e Ataques Comuns 109


Vulnerabilidadesdo Serviço

Um atacante encontra um defeito ouuma infração em um serviçoexecutado pela Internet através destavulnerabilidade. O atacantecompromete o sistema inteiro equaisquer dados que este possaconter; e também é possível quecomprometa outros sistemas da rede.

Serviços baseados em HTTP, taiscomo o CGI, são vulneráveis aexecuções de comandos remotos eaté mesmo a acesso através da janelade comandos. Mesmo que o serviçoHTTP seja executado por um usuárionão-privilegiado, como "ninguém",as informações como arquivos deconfiguração e mapas de rede podemser lidas, ou o atacante pode iniciarum ataque ’denial of service’ quedrena os recursos do sistema outorna-os indisponíveis a outrosusuários.Às vezes, os serviços podem tervulnerabilidades que passamdesapercebidas durante odesenvolvimento e testes. Estasvulnerabilidades (tais comosobrecarregamentos do buffer, nosquais o atacante derruba um serviçousando valores arbitrários quepreenchem o buffer da memória deuma aplicação, oferecendo aoatacante uma janela de comandosinterativa, a partir da qual ele podeexecutar qualquer comando) podemoferecer controle administrativocompleto a um atacante.

Administradores devem certificar-seque os serviços não sejam executadoscom o usuário root e estar atentos aatualizações de erratas e consertospara suas aplicações, de fabricantes ouempresas de segurança como CERT eCVE.

110 Apêndice B. Exploits e Ataques Comuns


Vulnerabilidadesda Aplicação

Atacantes encontram falhas emaplicações de computadores pessoaise estações de trabalho (como clientesde e-mail) e executam códigoarbitrário, implantando trojans paracomprometer ou danificar os sistemasfuturamente. Exploits podem ocorrerno futuro se a estação de trabalhocomprometida tiver privilégiosadministrativos sobre o resto da rede.

Estações de trabalho e computadorespessoais são mais propensos aexploits porque os funcionários nãotêm a mesma habilidade ouexperiência para impedir ou detectaro comprometimento; é essencialinformar aos indivíduos sobre osriscos que correm ao instalarsoftware não autorizado ou abrirarquivos anexos de e-mails nãosolicitados.

Algumas defesas podem serimplementadas de modo que estesoftware de cliente de e-mail não abraou execute automaticamente arquivosanexos. Adicionalmente, a atualizaçãoautomática do software da estação detrabalho através da Red Hat Networkou outros serviços de gerenciamentode sistemas, podem aliviar a carga deaplicações de segurança para umambiente multi-usuário.

Ataques Denial ofService (DoS)

O atacante ou grupo de atacantescoordena um ataque a recursos derede ou de servidor de uma empresaenviando pacotes não autorizados paraa máquina alvo (um servidor, umroteador ou uma estação de trabalho).Isto força o recurso a ficarindisponível aos usuários legítimos.

O caso de DoS (denial of service)ocorrido em 2000 mais reportado:diversos sites comerciais egovernamentais de alto tráfegotornaram-se indisponíveis por umataque ’ping flood’ coordenado,usando vários sistemascomprometidos com conexões debanda larga atuando como zumbis,ou nódulos de transmissãoredirecionados.Pacotes fonte geralmente sãoforjados (e também retransmitidos),dificultando a investigação daverdadeira origem do ataque.

Avanços na filtragem do ingresso(ingress filtering - IETF rfc2267),usando iptables e IDs de Redecomo snort, ajudam administradoresa rastrear e impedir ataques DoSdistribuí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, daemonse 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 AssignedNumbers 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. Senã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ãousadas pelo Red Hat Enterprise Linux como as portas de comunicação default para vários serviços,incluindo FTP, SSH e Samba.

Número daPorta / Camada

Nome Comentário

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 portasconectadas

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 infinitosde 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


Nome Comentário

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 Acessodo Terminal para autenticação e acesso baseado noTCP/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émusado pelos serviços do Protocolo de Configuração daMáquina Dinâmica (Dynamic Host ConfigurationProtocol, DHCP)

68 bootpc Cliente boostrap (BOOTP); também usado por clientes doProtocolo 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 deInternet Gopher

71 netrjs-1 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) paraserviç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émusado 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


Nome Comentário

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 Sistemade Arquivo de Rede (NFS)

113 auth Protocolos de autenticação e identificação

115 sftp Serviços do Protocolo de Transferência de ArquivosSeguros (SFTP)

117 uucp-path Serviços da Localidade do Protocolo de CópiaUnix-para-Unix (UUCP - Unix-to-Unix Copy Protocol)

119 nntp Protocolo de Transferência de Notícias de Rede (NetworkNews Transfer Protocol, NNTP) para o sistema dediscussão USENET

123 ntp Protocolo de Hora da Rede (NTP - Network TimeProtocol)

137 netbios-ns Serviço de Nome do NETBIOS usado no Red HatEnterprise Linux pelo Samba

138 netbios-dgm Serviço de Datagrama do NETBIOS usado no Red HatEnterprise Linux pelo Samba

139 netbios-ssn Serviço de Sessões do NETBIOS usado no Red HatEnterprise Linux pelo Samba

143 imap Protocolo de Acesso à Mensagem via Internet (InternetMessage 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 (BorderGateway 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



Nome Comentário

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 PacketExchange, IPX), um protocolo de datagrama geralmenteusado 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 - ServiceLocation 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íncronosSimples (SAFT - Simple Asynchronous File Transfer)

488 gss-http Serviços de Segurança Genérica (Generic SecurityServices, GSS) para o HTTP

496 pim-rp-disc Rendezvous Point Discovery (RP-DISC) para os serviçosdo Protocol Independent Multicast (PIM)

500 isakmp Protocolo de Administração da Chave e da Associação daSegurança de Internet (ISAKMP - Internet SecurityAssociation and Key Management Protocol)



Nome Comentário

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 SecureSockets 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 - DistributedQueueing 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 - DistributedQueueing 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 PrintingProtocol)

636 ldaps Protocolo de Acesso ao Diretório Lightweight sobre a SSL(LDAPS - Lightweight Directory Access Protocol overSecure 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 Kerberosversã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)



Nome Comentário

993 imaps Protocolo de Acesso a Mensagens da Internet sobre a SSL(IMAPS - Internet Message Access Protocol over SecureSockets 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 oucodenome(s) comuns.


Nome Comentário

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,routed]

Protocolo de Informações de Roteamento (RIP- RoutingInformation Protocol)

521 ripng Protocolo de Informações de Roteamento para o Protocolode Internet versão 6 (IPv6)

525 timed[timeserver]

Daemon de hora (timed)

526/tcp tempo [newdate] Tempo

530/tcp courier [rpc] Protocolo de Chamada do Processo Remoto deMensageiro (RPC - Remote Procedure Call)

531/tcp conference [chat] Internet Relay Chat



Nome Comentário

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 oProtocolo de Controle da Transmissão (TCP)

556 remotefs[rfs_server, rfs]

Sistema de Arquivo Remoto de Brunhoff (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 fimde registrá-las formalmente:


Nome Comentário

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

1236 bvcontrol[rmtcfg]

Servidor de Configuração Remota dos comutadores derede 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 doBanco de Dados Ingres (DBMS - Database ManagementSystem)

1525 prospero-np Prospero não-privilegiado

1645 datametrics[old-radius]

Datametrics / entrada do radius antigo

1646 sa-msg-port[oldradacct]

sa-msg-port / entrada do radacct antigo

1649 kermit Serviço de administração e transferência de arquivosKermit

1701 l2tp [l2f] Protocolo de Tunneling da Camada 2 (LT2P - Layer 2Tunneling Protocol) / Encaminhamento da Camada 2 (L2F- layer 2 forwarding)

1718 h323gatedisc H.323 telecommunication Gatekeeper Discovery



Nome Comentário

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 doradius

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 deservidor

2430/tcp venus Administrador de cache Venus para o sistema de arquivoCoda (porta codacon)

2430/udp venus Administrador de cache Venus para o sistema de arquivoCoda (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árioVê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 arquivoCoda

2600 hpstgmgr[zebrasrv]

Roteamento do Zebrab

2601 discp-client[zebra]

cliente discp; shell integrada do Zebra

2602 discp-server[ripd]

servidor discp; daemon do Protocolo de Informações deRoteamento (ripd)



Nome Comentário

2603 servicemeter[ripngd]

Medidor do Serviço; daemon do RIP para IPv6

2604 nsc-ccs [ospfd] NSC CCS; daemon do Open Shortest Path First (ospfd)

2605 nsc-posa NSC POSA; daemon do Protocolo da Porta deComunicaçã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 peloservidor 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ão4 (v4)

5002 rfe Sistema de transmissão de áudio Radio Free Ethernet(RFE)

5308 cfengine Mecanismo de Configuração (Cfengine - ConfigurationEngine)

5999 cvsup [CVSup] ferramenta de atualização e transferência de arquivosCVSup

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 deIPs



Nome Comentário

10080 amanda serviços de backup do Arquivador de Disco de RedeAutomático Maryland Avançado (Amanda - AdvancedMaryland Automatic Network Disk Archiver)

11371 pgpkeyserver Pretty Good Privacy (PGP) / servidor de chaves públicasGNU 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 RedeVeritas (bpdbm - NetBackup Database Manager)

13722 bpjava-msvc Java do Backup de Rede Veritas / Protocolo do MicrosoftVisual 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 (erelacionados)

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’, mastambé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 pelopacote zebra sem serem registradas. Os nomes primários são nomes registrados e os nomesnã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 onome 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 emredes AppleTalk.


Nome Comentário

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



Nome Comentário

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ãoregistradas na IANA.


Nome Comentário

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 quepodem 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.


Nome Comentário

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 Simplessobre 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)



Nome Comentário

953 rndc Ferramenta de configuração remota Berkeley InternetName 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 emJaponês

1313/tcp xtel Sistema de informações de texto French Minitel

1529/tcp suporte [prmsd,gnatsd]

Sistema de rastreamento de erros GNATS

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 redeNOCOL (noclogd - NOCOL network operation centerlogging daemon)

5355 hostmon Monitoramento de máquina do centro de operações derede 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,hplj]

Serviço de impressão de rede da Hewlett-Packard (HP)JetDirect

9359 mandelspawn[mandelbrot]

Programa de spawning Parallel Mandelbrot para o SistemaX Window

10081 kamanda Serviço de backup Amanda sobre o Kerberos



Nome Comentário

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çosIntegrados (ISDN - Integrated Systems Digital Network)

20012 vboxd Daemon da caixa de voz da ISDN (vboxd - voice boxdameon)

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

Índice Remissivo

Símbolos802.11x, 103

e segurança, 103ética do hacker, 9

Aatacantes e riscos, 9ative sua assinatura, vatualizações

(Ver erratas de segurança)auditoria de arquivos

ferramentas, 94

BBIOS

não-equivalentes ao x86senhas, 24

segurança, 23senhas, 23

Ccoletando evidências

(Ver resposta ao incidente)ferramentas de auditoria de arquivos, 94

dd, 94file, 94find, 94grep, 94md5sum, 94script, 93stat, 94strings, 94

considerações de segurançahardware, 101redes físicas, 101sem-fio, 103transmissão de rede, 102

controles, 5administrativos, 6físicos, 6técnicos, 6

convençõesdocumentos, ii

crackerhacker de chapéu preto, 9

crackersdefinição, 9

cupsd, 37

Ddd

auditoria de arquivos usando, 94coletando evidências com, 94

Denial of Service - DoS (Negação de Serviço)distribuídos, 4

DMZ(Ver Zona Desmilitarizada (Demilitarized Zone))(Ver networks)

Eequipe de resposta a emergências de computador, 92erratas de segurança, 17

aplicando alterações, 20através do site de erratas da Red Hat, 18quando reinicializar, 20via Red Hat Network, 17

exploits e ataques comuns, 107tabela, 107

FFerramenta de Configuração dos Serviços, 37ferramentas de comunicação

seguras, 40GPG, 40OpenSSH, 40

fileauditoria de arquivos usando, 94

findauditoria de arquivos usando, 94

firewalls, 65de estado, 72e registro de conexão, 72e vírus, 71iptables, 66normas, 67pessoal, 39recursos adicionais, 73tipos, 65

FTPacesso anônimo, 50apresentando, 49banner de saudação, 49contas de usuário, 51TCP wrappers e, 51upload anônimo, 50vsftpd, 49

126

Ggestores de início

GRUBsenha protegendo, 24

segurança, 24grep

auditoria de arquivos usando, 94

Hhacker de chapéu b ranco

(Ver hackers)hacker de chapéu cinza

(Ver hackers)hacker de chapéu preto

(Ver crackers)hackers

chapéu branco, 9chapéu cinza, 9chapéu preto

(Ver cracker)definição, 9

hardware, 101e segurança, 104estações de trabalho, 104laptops, 104servidores, 104

Iidade da senha, 29IDS

(Ver sistemas de detecção de invasão)introdução, i

categorias, usando este manual, ioutros manuais do Red Hat Enterprise Linux, itópicos, i

ip6tables, 72IPsec, 56

configuração, 60máquina-a-máquina, 57

fases, 56instalando, 56máquina-a-máquina, 57rede-a-rede, 60

iptables, 66correntes, 67

FORWARD, 69INPUT, 68OUTPUT, 68POSTROUTING (pós-roteamento), 70PREROUTING (pré-roteamento), 70, 71

e DMZs, 71e vírus, 71

inspeção de estado, 72estados, 72

normas, 67recursos adicionais, 73registro de conexão, 72

estados, 72regras, 68

comum, 68encaminhamento (forwarding), 69NAT, 70, 71restaurando, 68salvando, 68

usando, 67

KKerberos

NIS, 47

Llpd, 37lsof, 53

Mmd5sum

auditoria de arquivos usando, 94módulos de autenticação plugáveis (pluggable authen-tication modules - PAM)

forçando uma senha forte, 28

NNAT

(Ver Tradução do Endereço de Rede (Network Ad-dress Translation - NAT))

Nessus, 80Netfilter, 66

recursos adicionais, 73Netfilter 6, 72netstat, 53NFS, 47

e Sendmail, 52erros de sintaxe, 47planejamento de rede, 47

Nikto, 81NIS

apresentando, 45IPTables, 46Kerberos, 47nome de domínio do NIS, 45planejando a rede, 45portas estáticas, 46

127

securenets, 46nmap, 53, 80

versão linha de comando, 80

OOpenSSH, 40

scp, 40sftp, 40ssh, 40

Pplano de resposta ao incidente, 91portas

comuns, 111monitorando, 53

portas comunstabela, 111

portas de comunicação, 111portmap, 37

e IPTables, 44e TCP wrappers, 44

post-mortem, 93

Qquestões legais, 92

Rredes, 101

comutadores, 102e segurança, 101hubs, 102segmentação, 104sem-fio, 103zonas desmilitarizadas (de-militarized zones -DMZs), 104

Redes Privadas Virtuais (Virtual Private Networks),55

IPsec, 56configuração, 60instalando, 56máquina-a-máquina, 57

Redes Wi-Fi(Ver 802.11x)

registre sua assinatura, vregistro da assinatura, vreportando o incidente, 97resposta ao incidente

coletando evidênciasusando o dd, 94

coletando informação pós-infração, 94

criando um plano, 91

definição de, 91

e questões legais, 92

equipe de resposta a emergências de computador(computer emergency response team - CERT), 92

implementação, 93

introduzindo, 91

investigação, 93

post-mortem, 93

reportando o incidente, 97

restaurando e recuperando recursos, 96

restaurando e recuperando recursos, 96

consertando o sistema (patching), 96

reinstalando o sistema, 96

riscos

consertos e erratas, 11

estações de trabalho e PCs, 12, 12

aplicações, 12

portas abertas, 10

redes, 10

arquiteturas, 10

servidores, 10

administração desatenta, 11

serviços inseguros, 11

root, 31

desativar acesso, 31

limitar acesso, 34

com Administrador de Usuários, 34

e o su, 34

e o sudo, 35

métodos de desativação, 31

alterar a shell root, 33

com PAM, 33

impossibilitar autenticações SSH, 33

permitindo acesso, 31

RPM

e detecção de intrusão, 86

importando a chave GPG, 18

verificando pacotes assinados, 18, 19

128

Ssegurança da estação de trabalho, 23

avaliandoBIOS, 23comunicações, 23controle administrativo, 23firewalls pessoais, 23gestores de início, 23senhas, 23

BIOS, 23gestores de início

senhas, 24segurança da senha, 25

e PAM, 28em uma empresa, 28ferramentas de auditoria, 29

Crack, 29John the Ripper, 29Slurpie, 29

forçando, 28idade, 29metodologia, 28senhas fortes, 26

segurança do servidorFTP, 49

acesso anônimo, 50banner de saudação, 49contas de usuário, 51TCP wrappers e, 51upload anônimo, 50vsftpd, 49

NFS, 47erros de sintaxe, 47planejamento de rede, 47

NIS, 45IPTables, 46Kerberos, 47nome de domínio do NIS, 45planejando a rede, 45portas estáticas, 46securenets, 46

portasmonitorando, 53

portmap, 44Sendmail, 52

e NFS, 52limitando DoS, 52

Servidor HTTP Apache, 48diretivas, 48segurança cgi, 49

TCP wrappers, 41alertas de ataque, 42banners, 41registro, 42

visão geral da, 41

xinetd, 43gerenciando recursos com, 43prevenindo DoS (recusa de serviço) com, 43SENSOR armadilha, 43

segurança sem-fio, 103802.11x, 103

sendmail, 37apresentando, 52e NFS, 52limitando DoS, 52

senhasdentro de uma empresa, 28

Servidor HTTP Apacheapresentando, 48diretivas, 48segurança cgi, 49

serviços, 53serviços de co-locação, 104serviços de rede, 36

identificando e configurando, 37riscos, 36

denial-of-service (negação de serviço), 36sobrecarga do buffer, 36vulnerabilidade do script, 36

sobrecarga do bufferExecShield, 37

serviços inseguros, 38rsh, 38Telnet, 38vsftpd, 38

Shell EFIsegurança

senhas, 24sistema básico de input e output

(Ver BIOS)sistemas de detecção de invasão, 85

baseado em rede, 88Snort, 90

baseado no servidor, 86definindo, 85e arquivos de registro, 86Gestor de Pacotes RPM (RPM), 86tipos, 85Tripwire, 86

Snort, 90sshd, 37stat

auditoria de arquivos usando, 94strings

auditoria de arquivos usando, 94su

e root, 34sudo

e root, 35

129

TTCP wrappers

alertas de ataque, 42banners, 41e FTP, 51e portmap, 44registro, 42

tipos de firewall, 65filtro de pacotes, 65proxy, 65tradução do endereço da rede (network addresstranslation - NAT), 65

topologias de rede, 101canal linear (linear bus), 101estrela (star), 101ring, 101

Tradução do Endereço de Rede (Network AddressTranslation - NAT), 69

com iptables, 69Tripwire, 86

Uusuário root

(Ver root)

Vvisão geral, 1visão geral de segurança, 1

conclusão, 7controles

(Ver controles)definindo segurança em computadores, 1Denial of Service - DoS (Negação de Serviço), 4evolução da segurança em computadores, 1vírus, 4

VLAD the Scanner, 81VPN, 55vulnerabilidades

avaliando com Nessus, 80avaliando com Nikto, 81avaliando com Nmap, 80avaliando com o VLAD the Scanner, 81estimativa, 77

definindo, 78estabelecendo uma metodologia, 79testes, 78

vírustrojans, 4

Xxinetd, 37

gerenciando recursos com, 43prevenindo DoS (recusa de serviço) com, 43SENSOR armadilha, 43

ZZona Desmilitarizada (Demilitarized Zone), 71

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 arquivosSGML 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 serdistribuí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çãopara 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 ArquiteturaPOWER da IBM®; Autora Principal/Mantenedora do Red Hat Enterprise Linux Guia de Instalaçãopara as Arquiteturas IBM® S/390® e IBM® eServer™ zSeries®

John Ha — Autor Principal/Mantenedor do Configurando e Administrando um Cluster do Red HatCluster 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 HatEnterprise Linux; Autor Principal/Mantenedor das Notas de Versão; Autor contribuinte do Guia deInstalação para sistemas x86, Itanium™, AMD64 e Intel® Extended Memory 64 Technology (EM64Tda Intel®) do Red Hat Enterprise Linux

Karsten Wade — Autora Principal/Mantenedora do Red Hat SELinux Guia do Desenvolvimento deAplicaçõ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 EnterpriseLinux; 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; AutorContribuinte 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 DesktopRed 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

red hat enterprise linux 4 guia de segurança -...

Documents