stuff.mit.edu · ˝ndice Introduçªo...

Red Hat Enterprise Linux 3

Guia de Segurança

Red Hat Enterprise Linux 3: Guia de SegurançaCopyright © 2003 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_BR)-3-Print-RHI (2003-07-25T17:12)Copyright © 2003 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, Red Hat Network, o logo "Shadow Man" da Red Hat, RPM, Maximum RPM, o logo RPM, Linux Library,PowerTools, Linux Undercover, RHmember, RHmember More, Rough Cuts, Rawhide e todas as marcas baseadas na Red Hate logos são marcas registradas ou marcas registradas da Red Hat, Inc. nos Estados Unidos da América e em outros países.Linux é uma marca registrada de Linus Torvalds.Motif e UNIX são marcas registradas do The Open Group.Intel e Pentium são marcas registradas da Intel Corporation. Itanium e Celeron são marcas da Intel Corporation.AMD, Opteron, Athlon, Duron e K6 são marcas registradas da Advanced Micro Devices, Inc.Netscape é uma marca registrada da Netscape Communications Corporation nos Estados Unidos da América e em outrospaíses.Windows é uma marca registrada da Microsoft Corporation.SSH e Secure Shell são marcas da SSH Communications Security, Inc.FireWire é uma marca da Apple Computer Corporation.IBM, AS/400, OS/400, RS/6000, S/390 e zSeries são marcas registradas da International Business Machines Corporation.eServer, iSeries e pSeries são marcas da International Business Machines Corporation.Todas as outras marcas e direitos autorais referidos 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. Convenções de Documentos ................................................................................................. ii2. Mais por vir.......................................................................................................................... iv

2.1. Envie-nos Seu Feedback ........................................................................................ vI. Uma Introdução Genérica à Segurança ......................................................................................... i

1. Visão Geral de Segurança ..................................................................................................... 11.1. O que é Segurança em Computadores? ................................................................. 11.2. Controles de Segurança.......................................................................................... 51.3. Conclusão............................................................................................................... 6

2. Atacantes e Vulnerabilidades ................................................................................................ 72.1. Uma Breve História sobre Hackers........................................................................ 72.2. Ameaças à Segurança da Rede .............................................................................. 82.3. Ameaças à Segurança do Servidor......................................................................... 82.4. Ameaças à Segurança da Estação de Trabalho e PC Pessoal............................... 10

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

3.1. Atualizando Pacotes............................................................................................. 154. Segurança da Estação de Trabalho...................................................................................... 21

4.1. Avaliando a Segurança da Estação de Trabalho................................................... 214.2. Segurança do BIOS e do Gestor de Início ........................................................... 214.3. Segurança da Senha ............................................................................................. 244.4. Controles Administrativos ................................................................................... 294.5. Serviços de Rede Disponíveis.............................................................................. 354.6. Firewalls Pessoais ................................................................................................ 374.7. Ferramentas de Comunicação de Segurança Melhorada ..................................... 38

5. Segurança do Servidor ........................................................................................................ 395.1. Protegendo Serviços com TCP Wrappers e xinetd ........................................... 395.2. Protegendo o Portmap.......................................................................................... 425.3. Protegendo o NIS................................................................................................. 435.4. Protegendo o NFS................................................................................................ 455.5. Protegendo o Servidor HTTP Apache ................................................................. 465.6. Protegendo o FTP ................................................................................................ 475.7. Protegendo o Sendmail ........................................................................................ 495.8. Verificando Quais Portas estão Escutando........................................................... 50

6. Redes Privadas Virtuais (Virtual Private Networks) ........................................................... 536.1. VPNs e Red Hat Enterprise Linux ....................................................................... 536.2. CIPE (Crypto IP Encapsulation).......................................................................... 536.3. Por que usar o CIPE? ........................................................................................... 546.4. Instalação do CIPE............................................................................................... 556.5. Configuração do Servidor CIPE........................................................................... 556.6. Configurando Clientes para o CIPE..................................................................... 566.7. Personalizando o CIPE ........................................................................................ 586.8. Gerenciamento da Chave do CIPE....................................................................... 596.9. IPsec..................................................................................................................... 606.10. Instalação do IPsec............................................................................................. 606.11. Configuração Máquina-a-Máquina do IPsec ..................................................... 616.12. Configuração Rede-a-Rede do IPsec ................................................................. 62

7. Firewalls.............................................................................................................................. 677.1. Netfilter e IPTables .............................................................................................. 687.2. Usando o IPTables ............................................................................................... 697.3. Filtragem Comum do iptables......................................................................... 707.4. Regras FORWARD e NAT....................................................................................... 717.5. DMZs e iptables .............................................................................................. 72

7.6. Vírus e Endereços IP Espionados (spoofed)........................................................ 737.7. IP6Tables.............................................................................................................. 737.8. Recursos Adicionais............................................................................................. 74

III. Avaliando Sua Segurança .......................................................................................................... 758. Avaliação de Vulnerabilidade ............................................................................................. 77

8.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 ...................................................................................... 859.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 Comuns e Ataques ............................................................................................. 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. Eleescreveu os capítulos Avaliações de Vulnerabilidade e Resposta ao Incidente. Muito obrigado!

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 do Sistema do 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.

• 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. 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 apelidos para seu uso pessoal.

O arquivo /etc/fstab contém informações sobre os dispositivos e sistemas de arquivo diferen-tes 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.

[tecla]

Uma tecla do teclado é exibida neste estilo. Por exemplo:

Para usar a tecla complementar [Tab], digite um caracter e então pressione a tecla [Tab]. Seuterminal exibe uma lista dos arquivos contidos no diretório que começam com esta letra.

[tecla]-[combinação]

Uma combinação de sequência de teclas é representada desta maneira. Por exemplo:

A combinação de teclas [Ctrl]-[Alt]-[Espaço] termina sua sessão gráfica, retornando à tela ou aoconsole da autenticação gráfica.

Introdução iii

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:

$

#

[stephen@maturin stephen]$

leopard login:

input do usuário

O texto que o usuário precisa digitar, na linha de comandos ou em uma caixa de texto em 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:.

iv Introdução

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 determina-das partes da informação. De acordo com o quão crucial as informações são para seu sistema, elas sãoapresentadas 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 tomarão efeito até quevocê 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.

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.

Introdução v

2. 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 oportunos 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.

2.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 umrelatório ao Bugzilla (http://bugzilla.redhat.com/bugzilla/) sobre o componente rhel-sg.

Certifique-se de mencionar o identificador do manual:

rhel-sg(PT_BR)-3-Print-RHI (2003-07-25T17: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.

vi Introdução

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

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 po-der, produtividade e orçamentárias. Implementações de segurança apropriadas são frequentementeexecutadas postmortem — após uma intrusão não autorizada já ter ocorrido. Peritos em segurançaconcordam que as medidas corretas, tomadas antes de conectar um site a uma rede não confiável -como a Internet - é um meio efetivo de impedir a maioria das tentaivas 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 em seus dados como uma parte importan-te de seus recursos. Diversos termos e medidas foram inseridos em nosso cotidiano, tais como custototal de propriedade (total cost of ownership - TCO) e qualidade de serviço (quality of service - QoS).Nestas medidas, setores calculam aspectos como integridade de dados e alta disponibilidade comoparte de seus custos de planejamento e gerenciamento de processos. Em alguns setores, tal como co-mércio eletrônico, a disponibilidade e confiabilidade de dados pode ser a diferença entre sucesso efracasso.

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 é co-nhecido 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 em 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 baseadoem 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. Veja a seguir uma lista de alguns dos eventos mais importantes na história da computação esegurança da informação e sua importância hoje.

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

1.1.2.2. 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 restrito 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.

Capítulo 1. Visão Geral de Segurança 3

• Jim Ellis e Tom Truscott criam o USENET, sistema de estilo mural (bulletin-board) para comu-nicação eletrônica entre usuários díspares. O USENET rapidamente se torna um dos meios maispopulares de intercâmbio de idéias em computação, redes, e, obviamente, cracking.

1.1.2.3. 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 ela hackeava) é surpreendidapelas autoridades 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 pôde condenar Robert Morris, um grad-uando, por distribuir o vírus Morris Worm para mais de 6.000 computadores conectados à Internet.O próximo caso mais proeminente julgado sob este ato foi o de Herbert Zinn, um colegial que aban-donou os estudos, que crackeou e fez mal-uso dos sistemas da AT&T e do DoD (Departamento deDefesa 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.4. 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 Distribuído Denial of Service (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 paco-tes 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, ins-talaram aplicações cliente chamadas trojans nos servidores e marcaram um ataque com todos os ser-vidores infectados inundando os sites vítimas e tornando-os indisponíveis. Muitos culparam o ataqueà obsolescência da maneira como roteadores e protocolos usados são estruturados para aceitar todosos 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 400 milhões de pessoas usam ouusaram a Internet no mundo. Ao mesmo tempo:

• Em dia qualquer, são estimados 225 grandes incidentes de exploração de vulnerabilidade reportadosao Centro de Coordenação da CERT na Universidade Carnegie Mellon [fonte: http://www.cert.org]

• Em 2002, o número de incidentes reportados à CERT pulou para 82.094, de 52.658 em 2001. Nomomento da elaboração deste manual, o número de incidentes reportados apenas no primeiro quartode 2003 é de 42.586. [fonte: http://www.cert.org]

• O impacto econômico em nível mundial dos três vírus mais perigosos da Internet nos últimos doisanos foi estimado em US$13.2 bilhões. [fonte: http://www.newsfactor.com/perl/story/16407.html]

A segurança em computadores se tornou uma despesa quantificável e justificável em todos os orça-mentos de IT. Empresas que requerem iontegridade de dados e alta disponibilidade, evocam as habili-dades de administradores de sistemas, desenvolvedores e engenheiros para garantir confiabilidade deseus sistemas, serviços e informações. Cair nas mãos de usuários, processos ou ataques coordenadosmaldosos é uma ameaça direta ao sucesso da empresa.

Capítulo 1. Visão Geral de Segurança 5

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 implementa-çã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 co-mo a Associação Médica Americana (American Medical Association - AMA) ou o Instituto de Enge-nheiros 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 seja obtida 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. Disponibilidade é a garantia de que aquela informação pode ser obtida com uma frequenciae periodicidade pré-definidas. Isto é frequentemente medido em termos de porcentagens e definidoformalmente nos Acordos de Nível de Serviço (Service Level Agreements - SLAs) usados porprovedores 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:

• Física

• Técnica

• Administrativa

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’

1.2.2. Controles TécnicosO controle técnico uitilizam 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ê aprofunda 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 estas ques-tõ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 conhe-cimento e informação é essencial, e compartilhar este conhecimento é dever dos hackers para com acomunidade. Durante esta missão por conhecimento, alguns hackers se divertem com desafios aca-dê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, maléficas 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.

8 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ão

Administradores de sistemas frequentemente falham em preceber 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 nóduloslocais.

2.2.1.2. Servidores Centralizados

Outra armadilha de rede em potencial é o uso da computação centralizada. Uma forma comum decorte de gastos em muitas empresas é consolidar todos os serviços em apenas uma máquina poderosa.Isto pode ser conveniente, pois é mais fácil de gerenciar e custa bem menos que configurações 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 Linux contém até 1200 aplicações e pacotes de bibliotecas.No entanto, a maioria dos adminstradores de servidor não optam por instalar todos os pacotes dadistribuição; preferem, ao invés disso, instalar os pacotes básicos, incluindo diversas aplicações paraservidor.

Uma ocorrência comum dentre administradores de sistemas é instalar o sistema operacional sem pres-tar atenção em quais pacotes realmente estão sendo instalados. Isto pode ser problemático, pois servi-

Capítulo 2. Atacantes e Vulnerabilidades 9

ços desnecessários podem ser instalados, configurados com opções default e possivelmente acionados.Isto pode fazer com que serviços não quistos, como Telnet, DHCP ou DNS, sejam executados em umservidor ou estação de trabalho sem que o adminstrador perceba, o que pode causar tráfego inde-sejado no servidor, ou até mesmo uma via potencial para crackers ao sistema. Veja Capítulo 5 parainformaçõ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 aprimoramentos. Além disso,softwares mais novos frequentemente não são rigorosamente testados como se esperaria, porque che-garam recentemente a ambientes de produção ou porque talvez não sejam tão populares quanto outrossoftwares 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 ’ComputerEmergency Response Team’ (CERT) - (http://www.cert.org). Apesar destes mecanismos serem ma-neiras efetivas de alertar a comunidade sobre vulnerabilidades de segurança, é responsabilidade dosadminsitradores consertarem seus sistemas prontamente. Isto requer uma atenção especial pois oscrackers têm acesso aos mesmos serviços de rastreamento de vulnerabilidades e utilizarão as informa-ções para violar sistemas não consertados sempre que puderem. Uma boa administração de sistemasrequer vigilância, constante rastreamento de erros e manutenção apropriada do sistema para assegurarum 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), a cau-sa fundamental da vulnerabilidade na segurança de computadores é "delegar pessoas não treinadas pa-ra manter a segurança e não prover nem treinamento nem tempo para que o trabalho seja executado."1

Isto se aplica tanto para administradores inexperientes quanto para administradores super-confiantesou 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 utilizadosatravé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.

1. Fonte: http://www.sans.org/newlook/resources/errors.html


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 tmbém podem ser facilmente enquadrados no que a indústria da segurança chama de ata-que ’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 preten-dido. 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, capturandoinformaçõ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, a Red Hat desliga tais serviços. No entanto, como administradores frequentemente sãoforçados a usá-los, é essencial configurá-los cuidadosamente. Consulte o Capítulo 5 para mais infor-mações sobre como configurar serviços de maneira segura.

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 servido-res, mas já que estes comumente contêm informações delicadas, tais como dados de cartões de crédito,também são alvos de crackers de sistemas. Estações de trabalho também podem ser violadas sem oconhecimento do usuário e utilizadas por atacantes como máquinas "escravas" em ataques coordena-dos. Por estas razões, saber das vulnerabilidades de uma estação de trabalho pode poupar os usuáriosda dor de cabeça de reinstalar o sistema operacional, ou pior, de recuperar-se do roubo de dados.

2.4.1. Senhas RuinsSenhas ruins são uma das maneiras mais fáceis para um atacante obter acesso a um sistema. Para sabermais 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 daversã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 do

Capítulo 2. Atacantes e Vulnerabilidades 11

protocolo SSH, mas depende do usuário monitorar aplicações com tais vulnerabilidades e atualizá-lasquando necessário.

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 usar paraproteger estações de trabalho e servidores do 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........................................................................................................... 154. Segurança da Estação de Trabalho ............................................................................................. 215. Segurança do Servidor ................................................................................................................. 396. Redes Privadas Virtuais (Virtual Private Networks)................................................................. 537. Firewalls......................................................................................................................................... 67

Capítulo 3.

Atualizações de Segurança

Conforme as vulnerabilidades de segurança são descobertas, o software deve ser atualizado para li-mitar os riscos de segurança em potencial. Se o software é parte de um pacote de uma distribuição doRed Hat Linux atualmente suportada, a Red Hat, Inc. está comprometida em lançar pacotes atualiza-dos que consertem as vulnerabilidades assim que possível. Frequentemente, os comunicados de umexploit de segurança são acompanhados de um conserto (ou código-fonte que conserte o problema).Este conserto é então aplicado ao pacote do Red Hat Linux, testado pela equipe de controle de qualida-de da Red Hat e lançado como uma atualização de errata. Entretanto, se o comunicado não inclui umconserto, um desenvolvedor da Red Hat Linux trabalhará juntamente ao mantenedor do software paraconsertar o problema. Após consertar o problema, o pacote é testado e lançado como uma atualizaçãode 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 tempo emque 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 fon-te confiável. Um atacante pode reconstruir facilmente um pacote com a mesma versão daquele quesupostamente 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 recuperar atualizações de erratas de segurança:

1. Fazer o download pela Red Hat Network.

2. Fazer o download do site de Erratas da Red Hat.

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. Essa informação é mantida confi-dencialmente e não é distribuída para ninguém. É usada somente para determinar quais atualizaçõesde errata são aplicáveis para cada sistema. Sem o perfil, a Red Hat Network não pode determinar seseu 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.

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

Dica

O Red Hat Enterprise Linux inclui o Ferramenta de Notificação de Alerta da Red Hat Network,um ícone conveniente do painel que exibe alertas quando há uma atualização para um sistemaRed Hat Enterprise Linux. 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.3 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 relatórios de erratas de segurança são lançados, são publicados no site de Erratas da RedHat Linux http://www.redhat.com/apps/support/errata/. A partir desta página, selecione o produto eversão de seu sistema e então selecione security no topo da página para exibir apenas os Relatóriosde Segurança da Red Hat Enterprise Linux. Se a sinopse de um dos relatórios descreve um pacoteusado em seu sistema, clique na sinopse para ver mais detalhes.

A página de detalhes descreve o exploit de segurança e quaisquer instruções especiais que devem serexecutadas para atualizar o pacote e consertar o buraco na segurança.

Para fazer o download do(s) pacote(s) atualizado(s), clique no(s) nome(s) do(s) pacote(s) e salve-os nodisco rígido. É altamente recomendável que você crie um novo diretório como /tmp/atualizaçõese salve todos os pacotes do download ali.

Todos os pacotes do Red Hat Enterprise Linux são assinados com a chave GPG da Red Hat, Inc.. Outilitário RPM do Red Hat Enterprise Linux tenta automaticamente verificar a assinatura GPG de umpacote RPM antes de instalá-lo. Se a chave GPG da Red Hat, Inc. não está instalada, instale-a a partirde uma localidade segura e estática, como um CD-ROM do Red Hat Enterprise Linux.

Assumindo que o CD-ROM esteja montado em /mnt/cdrom, use o seguinte comando para importá-lapara o chaveiro:

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, Inc., 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

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

É 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 verificação da chave GPG for bem-sucedida, o comando retorna o output gpg OK.

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.

Isto pode ser feito com segurança para a maioria dos pacotes (exceto pacotes do kernel), submetendoo seguinte comando:

rpm -Uvh /tmp/updates/*.rpm

Para pacotes do kernel, é recomendado usar 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 é um requisito remover o kernel antigo.

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.3 para instruções gerais sobrecomo aplicar as alterações feitas por uma atualização de errata.

3.1.3. 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 uma funcionalidade de tarefa automatizada as lança, e não persistem por longosperí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 reinicializa-do.

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.

Para determinar quais aplicações estão relacionadas a uma biblioteca, use o comando 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 de servidor persistentes 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 doSistema do Red Hat Enterprise Linux para mais informações sobre a Ferramenta de Configu-ração dos Serviços.

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

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

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 eliminar instâncias antigas de um serviço controlado xinetd em particular, faça o upgradedo pacote do serviço e então pare todos os processos sendo executados. Primeiro, determine seo processo está rodando, usando o comando ps e então use o comando kill ou killall paraparar 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 anterioor, substitua � PID � pelo número de identificação do processo de uma ses-sã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 admisnitrativoeles 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 Melhorada — 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 impedirusuários não autorizados, que tenham acesso físico aos seus sistemas, de inicializar a máquina commídia removível ou acessar root através do modo de usuário simples. Mas as medidas de segurança atomar para proteger o sistema de ataques deste tipo dependem da sensibilidade das informações que aestação de trabalho armazena e da localização da máquina.

Por exemplo: se uma máquina é usada em uma 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 da rede corporativa for deixado nesta mesma feira sem a proteção de senhas, pode ocasionar umaviolaçã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 confiá-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 desligado a partir de um disquete ou CD-ROM. Isto possibilita que eleentre em modo de recuperação ou de usuário simples, que por sua vez permite a ele semearprogramas corruptos no sistema ou copiar dados sensíveis.

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.

22 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 compu-tador, 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 este procedimento.

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 iniciar em modo deusuário simples, ele se torna o usuário 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.

Há dois gestores de início distribuídos com o Red Hat Enterprise Linux para a plataforma x86, GRUBe LILO. Para uma visão detalhada de cada um destes gestores de início, consulte o capítulo entituladoGestores de Início (Boot Loaders) no Guia de Referência do Red Hat Enterprise Linux.

4.2.2.1. Senha Protegendo o GRUB

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

/sbin/grub-md5-crypt

Quando solicitada, digite a senha do GRUB e pressione [Enter]. Isto retornará um hash MD5 da senha.

Em seguida, edite o arquivo de configuração do GRUB /boot/grub/grub.conf. Abra o arquivo e,abaixo da linha timeout na seção principal do documento, adicione a seguinte linha:

password --md5 � password-hash �

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

2. O GRUB também aceita senhas não-criptografadas, mas é recomendado usar a versão md5 para segurança

adicional.

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

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.2.2.2. Senha Protegendo o LILO

O LILO é um gestor de início bem mais simples que o GRUB e não oferece uma interface de comando,portanto um atacante não pode obter acesso interativo ao sistema antes do kernel ser carregado. Noentanto, ainda há perigo de um atacante inicializar em modo de usuário simples ou iniciar em umsistema operacional não-seguro.

A proteção de senha para o LILO pode ser feita adicionando uma diretiva de senha na seção global deseu arquivo de configuração. Para fazer isso, abra uma janela de comando, logue-se como root e edite/etc/lilo.conf. Antes da primeira estrofe image adicione uma diretiva de senha similar a:

password= � password �

Na diretiva acima, substitua � password � pela senha do LILO.

Importante

Quando editar o arquivo /etc/lilo.conf, você deve executar o comando /sbin/lilo -v -v paraque as alterações tenham efeito. Se você configurou uma senha e ninguém, a não ser root, podeler o arquivo, o LILO será instalado corretamente, mas o alertará que as permissões do arquivo deconfiguração estão incorretas.


Se você não quer uma senha global, pode adicionar a diretiva de senha a qualquer estrofe corres-pondente a qualquer kernel ou sistema operacional. Para fazer isso, adicione a diretiva da senha logoabaixo da linha image. Ao terminar, o início da estrofe protegida por senha se assemelhará a:

image=/boot/vmlinuz- � version �password= � password �

No exemplo anterior, substitua � version � pela versão do kernel e � password � pela senha doLILO para este kernel.

É possível permitir a inicialização de um kernel ou sistema operacional sem verificação de senha,enquanto impedir que usuários especifiquem argumentos sem uma senha. Para fazer isso, adicione adiretiva restricted na linha abaixo da linha da senha, dentro da estrofe. Esta estrofe começa similara:

image=/boot/vmlinuz- � version �password= � password �restricted

Substitua � version � pela versão do kernel e � password � pela senha do LILO para este kernel.

Se você usar a diretiva restricted, deve também ter uma linha de senha dentro da estrofe.

Atenção

O arquivo /etc/lilo.conf é legível por todos. Se você estiver protegendo o LILO com senha, éessencial permitir somente a root ler e editar o arquivo, já que todas as senhas são somente-texto.Para fazer isso, digite o seguinte comando como root:

chmod 600 /etc/lilo.conf

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 a 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 programasde 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 crackear a senha remotamente se autenticando em um ser-viço de rede na máquina, como SSH ou FTP. Este tipo de ataque de força bruta é bem mais lento edeixa rastros óbvios, já que centenas de tentativas de autenticação mal-sucedidas são registradas nosarquivos 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 única coisamais importante que um usuário pode fazer para proteger sua conta de cracking de senha é criar umasenha forte.

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. Basear senhasseguras em idiomas estrangeiros não é eficiente.


• 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 um papel. É bem mais seguromemorizá-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 Segura

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

• Pense em uma frase memorável, como:

"o sol da liberdade em raios fúlgidos brilhou no céu da pátria neste instante."

• Em seguida, transforme-a num acrônimo (incluindo a pontuação).

osdlerfbncdpni.

• Adicione complexidade substituindo letras por números e símbolos no acrônimo. Por exemplo:substitua n por 9 e a letra d pelo símbolo arrouba (@):

o7r@77w,7ghwg.

• Adicione mais complexidade colocando pelo menos uma das letras em caixa alta, como F.

o7r@77w,7gHwg.

• Finalmente, nunca use o exemplo acima em nenhum de seus sistemas.

Criar senhas seguras é imperativo, mas gerenciá-las apropriadamente também é importante, especi-almente 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 adminsitradores 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, os administradores de sistema preferm que os usuários criem suas próprias senhas,mas ativamente verificam se as senhas são boas e, em alguns casos, forçam os usuários a trocaremsuas senhas periodicamente conforme sua idade.

4.3.2.1. Forçando Senhas Fortes

Para proteger a rede de intrusões é uma boa idéia administradores de sistema verificarem se as senhasusadas na empresa são fortes. Quando for pedido aos usuários criarem ou alterarem senhas, elespodem utilizar a aplicação de linha de comando passwd, que é ciente do Gerenciador Plugável deAutenticação (Pluggable Authentication Manager - PAM) e então checará se a senha é fácil de crackearou se é muito curta através do módulo PAM pam_cracklib.so. Como 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 enitulado Módulos Plugáveis de Autenticação (PAM) noGuia de Referência do Red Hat Enterprise Linux.


Perceba, 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 é distribuída com o Red Hat Enterprise Linux, portanto não são su-portadas pela Red Hat, Inc. de maneira alguma.

• John The Ripper — Um programa de cracking rápido e flexível. Permite o uso de listas depalavras múltiplas e é capaz de crackear 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.org/users/alecm/.

• Slurpie — O Slurpie é similar ao John The Ripper e ao Crack, mas é desenvolvido para rodarem computadores múltiplos simultaneamente, criando um ataque de cracking de senha distribuído.Pode ser encontrado online juntamente a outras ferramentas de avaliação de segurança contrasataques distribuídos em http://www.ussrback.com/distributed.htm.

Atenção

Sempre pegue autorizações escritas antes de tentar crackear senhas dentro de uma empresa.

4.3.2.2. Idade da Senha

Idade da senha é uma outra técnica usada por administradores de sistema para defender uma empresacontra senhas ruins. 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 uasada para criar políticas devalidade 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-usersem uma janela de comandos (em um XTerm ou um 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çõe sobre a configuração do usuário e grupo (inclusive instruções sobre como forçaras primeiras senhas), veja o capítulo Configuração de Usuário e Grupo do Guia de Administração doSistema do Red Hat Enterprise Linux. Para uma visão geral da administração de usuários e recursos,consulte o capítulo Gerenciando Contas de Usuário e Acesso a Recursos (Managing User Accountsand Resource Access) no Introdução à Administração de Sistemas Red Hat Enterprise Linux.

4.4. Controles AdministrativosAo adminsitrar 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 adminsitradores de sistema de uma empresa, no entanto, as escolhas devem ser feitas de acor-do com o nível de acesso adminsitrativo 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 entitulado 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 alte-rar configurações da rede ou do mouse, ou montar dispositivos de rede, são impossíveis sem o acesso


administrativo. Consequentemente, os administradores devem decidir o grau de acesso administrativoque os ususários de sua rede devem ter.

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 má idéia. Permitir acesso root a usuários significa que questões menores,como adicionar serviços ou configurar interfaces de rede, podem ser executadas pelos usuários indi-viduais, deixando os adminsitradores de sistema livres para lidar com a segurança da rede e outrasquestões importantes.

Por outro lado, permitir acesso root a usuários individuais pode acarretar nas questões a seguir (paranomear apenas algumas):

• 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 adminsitrador 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 de senha dogestor de início (veja a Seção 4.2.2 para mais informações sobre este tópico).

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 impedidops 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 énecessário para aautenticação. Veja a Seção4.4.2.4 para detalhes.

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.

Tabela 4-1. Métodos para Desativar a Conta Root

4.4.2.1. Desativar a Shell Root

Para impedir os usuários de se autenticar diretamente como root, o administrador de sistema 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, administradores podem desativar autenticações root no console edi-tando o arquivo /etc/securetty. Este arquivo lista todos os dispositivos nos quais o usuário rootpode se autenticar. Se o arquivo não existir, o usuário root pode se autenticar através de qualquerdispositivo de comunicação no sistema, através do console ou de uma interface de rede bruta. Isto éperigoso pois um usuário pode acessar o Telnet em sua máquina como root, enviando sua senha emformato texto através da rede. Por default, o arquivo /etc/securetty do Red Hat Enterprise Linuxpermite somente ao usuário root se autenticar no console fisicamente anexo à máquina. Para impedirque root se logue, 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 PAM

O 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 adminsitrador é 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 adminsitrador 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 a Administrador de Usuários para este propósito, vá ao Botão do Menu Principal (no Pai-nel) => Configurações do Sistema => Grupos & Usuários ou digite o comando redhat-config-users em uma janela de comandos. Selecione a aba Users, selecione o usuário e clique em Proprie-dades 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/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 senha. Então,uma vez autenticado e assumindo que o comando é permitido, o comando administrativo é executadocomo 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 eles podem 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 mostrado em Seção 4.4.2.1.

O comando sudo também oferece um registro compreensivo da sequência de eventos. Cada autenti-cação bem-sucedida é registrada no arquivo /var/log/messages e o comando submetido junto aonome do 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.

Adminsitradores 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 desistema dentro de uma empresa, manter controle de quais serviços de rede estão ativos é de sumaimportância para qualquer um que instalar e operar um sistema Linux.

Muitos serviços comportam-se como servidores de rede sob o Red Hat Enterprise Linux. Se um servi-ço de rede estiver rodando em uma máquina, então uma aplicação de servidor chamada daemon estáescutando conexões em uma ou mais portas de rede. Cada um destes servidores deve ser tratado comouma 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 de Sobrecarregamento do Buffer (Buffer Overflow) — Serviços que se conectam a portasnumeradas de 0 a 1023 devem ser executados por um usuário administrativo. Se a aplicação tiver umsobrecarregamento explorável do buffer, um atacante pode obter acesso ao sistema como o usuáriorodando o daemon. Devido à existência de sobrecarregamento explorável do buffer, os crackersusam ferramentas automatizadas para identificar sistemas com vulnerabilidades, e após obteremacesso ao sistema, utilizam rootkits automatizados para mantê-lo.

• Ataques de Denial of Service (DoS) — Ao inundar um serviço com pedidos, um ataque de denialof service pode trazer ao sistema uma parada terrível ao tentar registrar e responder à cada pedido.

• Ataques à Vulnerabilidade do Script — Se um servidor estiver usando scripts para executar açõ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 sobrecarregamento do buffer ou permitir que o atacante altere arquivos no sistema.

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ços instalados com o Red Hat Enterprise Linux sãodesligados 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.

• portmap — Um componente necessário para o NFS, NIS e outros protocolos.

• xinetd — Um super servidor que controla as conexões para uma máquina de servidores subordi-nados, como vsftpd, telnet e sgi-fam (necessário para o gerenciador de arquivos Nautilus).


• sendmail — O agente de transporte Sendmail é ativado por default, mas escuta apenas conexõesa partir do 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 bom senso e pecarpela precaução. Por exemplo: se uma impressora não está disponível, não deixe o cupsd rodando. Omesmo vale para o portmap. Se você não monta volumes NFS ou usa o NIS (o serviço ypbind),então o portmap deve ser desativado.

O Red Hat Enterprise Linux é distribuído com três programas desenvolvidos para ligar e desligar ser-viços. Eles são: Ferramenta de Configuração dos Serviços (redhat-config-services), ntsysve chkconfig. Para informações sobre o uso destas ferramentas, consulte o capítulo ControlandoAcesso aos Serviços do Guia de Administração do Sistema do 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 detalhes 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 cripto-grafado 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 login e shell (rlogin, rsh e telnet) devem ser evitados em favor do SSH.(Veja a Seção 4.7 para mais informações sobre o sshd).

O FTP não é essencialmente tão perigoso à segurança do sistema quanto janelas de comando (shells)remotas, mas os servidores FTP devem ser configurados e monitorados cuidadosamente para evitarproblemas. Veja a Seção 5.6 para mais informações sobre a proteção de servidores FTP.

Serviços que devem ser implementados cuidadosamente e por trás de um firewall incluem os seguin-tes:

• finger

• identd

• netdump

• netdump-server

• nfs

• portmap

• rwhod

• sendmail

• smb (Samba)

• yppasswdd

• ypserv

• ypxfrd

Você pode consultar mais informações sobre a proteção de serviços de rede em 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 pedido auma porta sendo bloqueada pelo firewall, este será ignorado. Se o serviço estiver escutando em uma


destas portas bloqueadas, não receberá os pacotes e será efetivamente desabilitado. Por este motivo,tome cuidado ao configurar um firewall para bloquear acesso a portas não usadas, para não 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 (redhat-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 quais opções ela oferece, consulte o capítulo enti-tulado Configuração Básica do Firewall no Guia de Administração do Sistema do 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 compreensivo sobre o comando iptables, consulte o capítulo iptables no Guia deReferência do Red Hat Enterprise Linux.

4.7. Ferramentas de Comunicação de Segurança MelhoradaNa 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 cripto-grafados 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 do Sistema do 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 excelente maneira de manter a privacidade de dados delicados. Pode ser usado para enviaremail com dados delicados através de redes públicas e para proteger dados sensíveis em discos rígidos.

Para mais informações sobre o uso do GPG, consulte o apêndice entitulado Guia de Iniciação do GnuPrivacy Guard do Guia de Administração do Sistema do Red Hat Enterprise Linux.

Capítulo 5.

Segurança do Servidor

Quando um sistema é usado com 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 xinetd

TCP wrappers oferecem controle de acesso a vários serviços. A maioria dos serviços de rede moder-nos, como SSH, Telnet e FTP, fazem uso dos TCP wrappers, que fica 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 utili-zaçã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 do serviço. Consulte o Capítulo 7para 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 entitulado 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 eaumentar 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ão

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

40 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 intimar 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 Ataque

Se 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 pêgo 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 Melhorado

Se 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 41

Isto usa a facilidade de registro authpriv default, mas eleva a prioridade do valor default do infopara emerg, 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 subor-dinados. Esta seção foca em como o xinetd pode ser usado para montar um serviço-armadilha econtrolar a quantidade de recursos que qualquer serviço xinetd pode usar para arruinar ataques ’de-nial of service’. Para obter uma lista mais completa das opções disponíveis, consulte as páginas mando xinetd e do xinetd.conf.

5.1.2.1. Montando uma Armadilha

Uma importante característica do xinetd é sua habilidade em adicionar máquinas (hosts) a 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 e 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, na última linha deve-se ler:

disable = no

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

• Não funciona contra scans secretos.

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

5.1.2.2. Controlando Recursos de Servidor

Outra característica importante do xinetd é sua habilidade em controlar a quantidade de 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 RPS, 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.

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

5.2.1. Proteja o portmap com TCP WrappersÉ importante usar o TCP wrappers para limitar quais redes ou máquinas têm acesso ao serviço port-map já que este não possue 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, restringindo 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 RPC cha-mado ypserv que é 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 quequeira estar 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 transfências de mapa 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.

NIS é bastante inseguro para os padrões de hoje. Não tem mecanismo de autenticação da máquina epassa 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.

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) do 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), o seguinte comando revela o mapa de /etc/passwd:

ypcat -d 0 NIS_domain 1 -h 0 DNS_hostname 1 passwd

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

ypcat -d 0 NIS_domain 1 -h 0 DNS_hostname 1 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 pa-ra o nome da máquina DNS, tal como o7hfawtgmhwg.domain.com. Similarmente, crie um nomediferente de domínio NIS randomizado . Isto dificulta bastante um atacante de acessar o 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 uma más-cara de rede/’network pairs’ no arquivo de modo que ypserv somente responda aos pedidos da redeapropriada.

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) em uma máquina, uma senha com caracteres misturados é enviada do mapa/etc/shadow através da rede. Se um intruso obtiver acesso a um domínio NIS e bisbilhotar o tráfegode rede, essas misturas de nomes de usuários e senhas podem ser discretamente coletadas. Com temposuficiente, um programa de cracking de senha pode adivinhar senhas fáceis e um atacante pode obteracesso 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ítuloentitulado 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 RPC, usado em conjun-to com o portmap e outros serviços relacionados, para oferecer sistemas de arquivo acessíveis paramáquinas-cliente. Para mais informações sobre o funcionamento do NFS, consulte o capítulo entitu-lado Sistema de Arquivo de Rede (NFS) no Guia de Referência do Red Hat Enterprise Linux. Paramais informações sobre o NFS, consulte o Guia de Administração do Sistema do Red Hat EnterpriseLinux. As sub-seções a seguir assumem um conhecimento básico do NFS.

Importante

É recomendado que qualquer um planejando implementar um servidor NFS, primeiramente protejao serviço portmap, como descrito em Seção 5.2, antes de resolver as seguintes questões.

5.4.1. Planejar Cuidadosamente a RedeComo o NFS passa todas as informações 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çõessão passadas através do NFS em uma rede insegura, seus riscos estão sendo interceptados. Um plane-jamento cuidadoso da rede neste aspecto pode ajudar a prevenir violaçõ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 leitura e escrita.

/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 caracter 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 2 hostname 3

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 siste-ma de arquivo compartilhado e deixar aplicações infectadas pelo trojan, para que outros usuários asexecutem 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 para aaplicação. Isto inclui o capítulo entitulado Servidor HTTP Apache do Guia de Referência do Red HatEnterprise Linux, o capítulo Configuração do Servidor HTTP Apache do Guia de Administraçãodo Sistema do Red Hat Enterprise Linux e os manuais do Stronghold, disponíveis online:http://www.redhat.com/docs/manuals/stronghold/.

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

5.5.1. FollowSymLinksEsta diretiva é habilitada por default, portanto cuidado ao criar os links simbólicos no documento rootdo 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 nave-guem 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 4 directory_name 5chmod 755 4 directory_name 5

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 - 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, 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 em um sistema.

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

ftpd_banner= 4 insert_greeting_here 5

Substitua 6 insert_greeting_here 7 na diretiva acima pelo texto de sua mensagem de sauda-çã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 para o vsftpd, adicione a seguinte diretiva a/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ônimo

Para 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, frequentemente per-cebem que seu servidor se torna um depósito de software roubado.

Adicionalmente, abaixo de vsftpd, adicione a seguinte linha a /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ário

A 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 emails a clientes ou agentes deentrega. 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-ção comuns, veja o capítulo Email 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 Ataque de Proibição de Serviço (Denial of Service Attack)Devido à natureza do email, um determinado atacante pode facilmente lotar o servidor com corres-pondê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.

Já que o NFS não mantém controle sobre IDs de usuário e grupo, dois ou mais usuários podem ter omesmo UID e portanto receber e ler a correspondência do outro.

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 V. 3.00 ( www.insecure.org/nmap/ )Interesting ports on localhost.localdomain (127.0.0.1):(The 1596 ports scanned but not shown below are in state: closed)Port State Service22/tcp open ssh111/tcp open sunrpc515/tcp open printer834/tcp open unknown6000/tcp open X11Remote OS guesses: Linux Kernel 2.4.0 or Gentoo 1.2 Linux 2.4.19 rc1-rc7)

Nmap run completed -- 1 IP address (1 host up) scanned in 5 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 abra clandestinamente uma portaem um 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, aporta 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 os servi-ços e configurações da rede. Portanto, recomendamos fortemente que você consulte as páginas mando 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 moti-vos de eficiência e proteção de dados sensíveis transitando entre as diferentes localidades. Por exem-plo: 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.

Engenheiros desenvolveram uma solução de baixo custo para este problema na forma de Redes Pri-vadas Virtuais (Virtual Private Networks - VPNs). Seguindo os mesmos princípios funcionais doscircuitos dedicados, as VPNs permitem a comunicação digital protegida entre duas partes (ou redes),criando uma Ampla Área de Rede (Wide Area Network - WAN) a partir de LANs (Áreas Locais deRede) existentes. Ela difere do frame relay ou do ATM em seu meio de transporte. As VPNs transmi-tem através de IP usando datagramas (UDP) como a camada de transporte, tornando-o um condutorseguro através da Internet, para um determinado destino. A maioria das implementações VPN de soft-ware livre incorporam o padrão aberto e criptografia open source para mascarar futuramente os dadosem 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 atuam como roteadores especializados situados entreas 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 e as roteia ao destino pretendido (umaestação de trabalho ou um nódulo em uma rede). Usando uma conexão rede-a-rede, o nódulo receptorda rede local recebe os pacotes descriptografados e prontos para processar. O processo de criptogra-fia/descriptografia em uma conexão VPN rede-a-rede é transparente para o nódulo local.

Com um nível tão alto de segurança, não basta ao cracker interceptar o pacote, mas também descrip-tografar o pacote (a maioria das VPNs geralmente aplica a cifra tripla ’Data Encryption Standard’[3DES] de 168 bits). Intrusos que aplicarem o ataque man-in-the-middle entre um servidor e o clientetambém devem ter acesso às chaves trocadas para sessões de autenticação. VPNs são um meio seguroe efetivo para conectar múltiplos nódulos remotos para atuar como uma intranet unificada.

6.1. VPNs e Red Hat Enterprise LinuxUsuários e administradores do Red Hat Enterprise Linux têm várias opções em termos de implemen-tação de soluções de software para conectar e proteger sua WAN. Há, no entanto, dois métodos deimplementação de conexões VPN equivalentes atualmente suportadas pelo Red Hat Enterprise Linux.Uma solução equivalente, que pode ser usada como um substituto seguro ao uso de um VPN, envol-ve rodar o OpenSSH como um túnel entre dois nódulos remotos. Esta solução é uma boa alternativaao Telnet, rsh e outros métodos de comunicação remota, mas não atende completamente às neces-sidades de usabilidade de todos os telecomutadores e filiais corporativas. Duas soluções suportadasinclusas no Red Hat Enterprise Linux mais próximas da definição de uma VPN são CIPE (Crypto IPEncapsulation) e IPSEC (Internet Protocol Security).

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

6.2. CIPE (Crypto IP Encapsulation)CIPE é uma implementação do VPN desenvolvida primariamente para o Linux. CIPE utiliza pacotesIP criptografados que são encapsulados, ou embrulhados, em pacotes de datagrama (UDP). PacotesCIPE recebem informações de destino no cabeçalho e são criptografados utilizando o mecanismodefault de criptografia do CIPE. Os pacotes são então transferidos pelo IP como pacotes UDP atravésdo dispositivo virtual de rede do CIPE (cipcbx) por uma rede de transporte a um nódulo remotopretendido. A Figura 6-1 mostra uma configuração típica do CIPE conectando duas redes baseadas noLinux:

Figura 6-1. Uma Rede e um Cliente Remoto Conectados pelo CIPE

Esse diagrama mostra uma rede rodando CIPE no firewall e uma máquina cliente remota atuandocomo um nódulo habilitado pelo CIPE. A conexão CIPE atua como um túnel através do qual todosos dados da Intranet são roteados entre nódulos remotos. Todos os dados são criptografados usandochaves de 128 bits geradas dinamicamente, e podem ser comprimidos para transferências de arquivosgrandes ou para enviar aplicações do X para uma máquina remota. CIPE pode ser configurado paracomunicação entre duas ou mais máquinas Linux habilitadas pelo CIPE, e tem drivers de rede parasistemas operacionais baseados no Win32.

6.3. Por que usar o CIPE?Há muitas razões para o CIPE ser uma escolha inteligente para administradores de sistemas e desegurança:

• O Red Hat Enterprise Linux é distribuído com o CIPE, portanto está disponível para todasas máquinas Red Hat Enterprise Linux de borda (por exemplo: firewalls ou portas decomunicação/gateways) e clientes individuais que você queira conectar à sua Intranet. O Red HatEnterprise Linux também inclui cifras de criptografia suportadas pelo CIPE.

• CIPE suporta criptografia usando o Blowfish padrão ou algoritmos de criptografia IDEA. Depen-dendo da regulamentação de exportação de criptografia em seu país, você deve usar o default (Blow-fish) para criptografar todo o tráfego do CIPE em sua Intranet.

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

• Já que o CIPE é baseado em software, qualquer máquina mais antiga ou redundante capaz de rodar oRed Hat Enterprise Linux, pode se tornar uma porta de comunicação do CIPE, poupando a empresado alto custo de aquisição de hardware dedicado a VPN, para conectar duas LANs seguramente.

• O CIPE é ativamente desenvolvido para trabalhar em conjunto com iptables, ipchains e out-ros firewalls baseados em regras. A aceitação da entrada de pacotes CIPE UDP é a única coisanecessária para coexistir com regras de firewall existentes.

• A configuração do CIPE é feita através de arquivos texto, permitindo a administradores configurarseus servidores e clientes CIPE remotamente, sem a necessidade de ferramentas gráficas pesadasque podem não funcionar bem através de uma rede. CIPE também pode ser configurado através daFerramenta de Administração de Rede.

6.4. Instalação do CIPEA instalação do CIPE equivale a instalar uma interface de rede sob o Linux. O pacote RPM docipe contém arquivos de configuração encontrados em /etc/cipe/, o daemon do CIPE(/usr/sbin/ciped-cb), scripts de rede que carregam o módulo do kernel e ativam/desativam ainterface do CIPE (if*-cipcb), e amostras de arquivos de configuração encontrados em/usr/share/doc/cipe- 8 version 9 /samples/. Há também uma página com informaçõesdetalhadas sobre o protocolo do CIPE e vários detalhes de implementação.

O guia a seguir detalha uma amostra de configuração envolvendo uma estação de trabalho cliente quedeseja se conectar seguramente a uma LAN remota com uma porta de comunicação CIPE. A estaçãode trabalho usa um endereço IP dinâmico de uma conexão cable modem, enquanto a máquina da portade comunicação (gateway) ativada pelo CIPE emprega o intervalo 192.168.1.0/24. Isto é conhecidocomo uma configuração CIPE "típica". Figura 6-1 ilustra a configuração típica do CIPE.

Instalar o CIPE entre o cliente e o servidor CIPE permite uma conexão par-a-par protegida usando aInternet como um meio de transmissão do tráfego WAN. A estação de trabalho cliente então transfereum arquivo através da Internet para o firewall habilitado pelo CIPE, onde cada pacote terá sua datae hora registrados e lhes serão dados os endereços-par do firewall receptor habilitado pelo CIPE. Ofirewall destino então lê as informações de cabeçalho, despe-as, e as envia para o roteador LAN remotopara serem roteadas para o nódulo de destino. Este processo é simples e completamente transparentea usuários finais. A maioria das transações são feitas entre pares habilitados pelo CIPE.

6.5. Configuração do Servidor CIPEPara configurar o servidor CIPE, instale o pacote RPM cipe pelo CD-ROM do Red Hat EnterpriseLinux ou através da Red Hat Network.

Importante

Se você estiver usando uma versão antiga do Red Hat Enterprise Linux e/ou tem uma versão antigado CIPE, deve atualizar para a versão mais recente.

O próximo passo é copiar as amostras de arquivos de configuração de/usr/share/doc/cipe-version/samples/ (onde version é a versão do CIPE instaladoem seu sistema) para /etc/cipe/. Uma vez copiados, você precisa editar o arquivo/etc/cipe/options.cipcbx (x é crescente começando do 0, para aqueles que quiserem ter maisde uma conexão CIPE no servidor CIPE) para incluir os endereços da sub-rede de sua LAN eendereços IP do firewall publicamente roteável. Veja a seguir o arquivo options inclusono RPM cipe do Red Hat Enterprise Linux que, para este exemplo, foi renomeado comooptions.cipbcb0:


# Surprise, this file allows comments (but only on a line by themselves)# This is probably the minimal set of options that has to be set# Without a "device" line, the device is picked dynamically

# the peer’s IP addressptpaddr 6.5.4.3

# our CIPE device’s IP addressipaddr 6.7.8.9

# my UDP address. Note: if you set port 0 here, the system will pick# one and tell it to you via the ip-up script. Same holds for IP 0.0.0.0.me bigred.inka.de:6789

# ...and the UDP address we connect to. Of course no wildcards here.peer blackforest.inka.de:6543

# The static key. Keep this file secret!# The key is 128 bits in hexadecimal notation.key xxxxxxxxxxxxxxxxxxxxxxxxxxxxx

O ptpaddr é o endereço do CIPE da LAN remota. O ipaddr é o endereço IP do CIPE da estaçãode trabalho. O me é o endereço IP publicamente roteável do cliente que envia os pacotes UDP atravésda Internet, e peer é o endereço IP publicamente roteável do servidor CIPE. Note que o endereçoIP da estação de trabalho do cliente é 0.0.0.0 porque utiliza uma conexão dinâmica. O cliente CIPEmanipulará a conexão para a máquina do servidor CIPE. O campo key (representado por x’s; a chavedeve ser secreta) é a chave estática compartilhada. Esta chave deve ser a mesma para ambos os paresou a conexão não será possível. Veja a Seção 6.8 para informações sobre como gerar uma chaveestática compartilhada para suas máquinas CIPE.

Aqui está o /etc/cipe/options.cipcb0 editado que a estação de trabalho utilizará:

ptpaddr 10.0.1.2ipaddr 10.0.1.1me 0.0.0.0peer LAN.EXAMPLE.COM:6969key 123456ourlittlesecret7890shhhh

Aqui está o arquivo /etc/cipe/options.cipcb0 para o servidor CIPE:

ptpaddr 10.0.1.1ipaddr 10.0.1.2me LAN.EXAMPLE.COM:6969peer 0.0.0.0key 123456ourlittlesecret7890shhhh

6.6. Configurando Clientes para o CIPEApós configurar o servidor CIPE apropriadamente e testar as funcionalidades, você pode extender aconexão para a máquina cliente.

O cliente CIPE deve poder conectar e desconectar a conexão CIPE de maneira automatizada. Conse-quentemente, CIPE contém mecanismos próprios para personalizar configurações para usos individu-ais. Por exemplo: um funcionário remoto pode conectar-se a um dispositivo CIPE na LAN digitandoo seguinte:

/sbin/ifup cipcb0


O dispositivo deve aparecer automaticamente. As informações de roteamento e regras de firewalltambém devem ser configuradas ao longo da conexão. O funcionário remoto deve poder terminar aconexão com o seguinte:

/sbin/ifdown cipcb0

Configurar clientes requer a criação de scripts localizados que são executados após o dispositivo sercarregado. A configuração do dispositivo pode ser feita localmente através de um arquivo, criado pe-lo usuário, chamado /etc/sysconfig/network-scripts/ifcfg-cipcb0. Este arquivo contémparâmetros que determinam se a conexão CIPE ocorre no momento de ligar a máquina (boot-time), onome do dispositivo do CIPE, entre outras informações. Veja a seguir o arquivo ifcfg-cipcb0 paraum cliente remoto conectando a um servidor CIPE:

DEVICE=cipcb0ONBOOT=yesBOOTPROTO=noneUSERCTL=no

# This is the device for which we add a host route to our CIPE peer through.# You may hard code this, but if left blank, we will try to guess from# the routing table in the /etc/cipe/ip-up.local file.PEERROUTEDEV=

# We need to use internal DNS when connected via cipe.DNS=192.168.1.254

O dispositivo do CIPE é chamado cipcb0. Este dispositivo é carregado no momento de inicializar(configurado através do campo ONBOOT) e não utiliza um protocolo boot (DHCP, por exemplo) parareceber um endereço IP para o dispositivo. O campo PEERROUTEDEV determina o nome do dispositivodo servidor CIPE que conecta ao cliente. Se não for especificado nenhum dispositivo neste campo,algum será determinado após o dispositivo ser carregado.

Se suas redes internas estiverem atrás de um firewall, defina regras para permitir que a interface CIPEna máquina do cliente envie e receba pacotes UDP. Consulte o Capítulo 7 para informações sobre aconfiguração do firewall. Neste exemplo de configuração, as regras iptables são implementadas.

Nota

Clientes devem ser configurados de maneira que todos os parâmetros locais sejam inseridos em umarquivo, criado pelo usuário, chamado /etc/cipe/ip-up.local. Os parâmetros locais devem serrevertidos quando a sessão CIPE for finalizada, usando o /etc/cipe/ip-down.local.

Firewalls devem ser configurados nas máquinas cliente para aceitar pacotes CIPE UDP encapsulados.As regras podem variar amplamente, mas a aceitação trivial de pacotes UDP é necessária para aconectividade do CIPE. As regras seguintes permitem transmissões UDP CIPE na máquina do clienteremoto conectando à LAN. A regra final adiciona o ’mascaramento’ do IP para permitir que o clienteremoto se comunique à LAN e à Internet.

/sbin/modprobe iptables/sbin/service iptables stop/sbin/iptables -P INPUT DROP/sbin/iptables -F INPUT/sbin/iptables -A INPUT -j ACCEPT -p udp -s 10.0.1.1/sbin/iptables -A INPUT -j ACCEPT -i cipcb0/sbin/iptables -A INPUT -j ACCEPT -i lo/sbin/iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o eth0 -j MASQUERADE


Adicione regras de roteamento para que a máquina cliente acesse os nódulos por trás da conexão CIPEcomo se estivessem na rede local. Isto pode ser feito rodando o comando route. Neste exemplo, aestação de trabalho do cliente precisa ter a seguinte rota de rede:

route add -net 192.168.1.0 netmask 255.255.255.0 gw 10.0.1.2

Veja a seguir o script final /etc/cipe/ip-up.local para a estação de trabalho do cliente:

#!/bin/bash -vif [ -f /etc/sysconfig/network-scripts/ifcfg-$1 ] ; then

. /etc/sysconfig/network-scripts/ifcfg-$1else

cat :;: EOT | loggerCannot find config file ifcfg-$1. Exiting.EOF

exit 1fi

if [ -n ${PEERROUTEDEV} ]; thencat :;: EOT | logger

Cannot find a default route to send cipe packets through!Punting and hoping for the best.EOT

# Use routing table to determine peer gatewayexport PEERROUTEDEV=‘/sbin/route -n | grep ^0.0.0.0 | head -n 1 \

| awk ’{ print $NF }’‘

fi

##################################################### Add The routes for the remote local area network #####################################################

route add -host 10.0.1.2 dev $PEERROUTEDEVroute add -net 192.168.1.0 netmask 255.255.255.0 dev $1

##################################################### IP TABLES Rules to restrict traffic #####################################################

/sbin/modprobe iptables/sbin/service iptables stop/sbin/iptables -P INPUT DROP/sbin/iptables -F INPUT/sbin/iptables -A INPUT -j ACCEPT -p udp -s 10.0.1.2/sbin/iptables -A INPUT -j ACCEPT -i $1/sbin/iptables -A INPUT -j ACCEPT -i lo/sbin/iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o eth0 -j MASQUERADE

6.7. Personalizando o CIPEO CIPE pode ser configurado de inúmeras maneiras, desde passar parâmetros como argumentos delinhas de comando ao iniciar o ciped até gerar novas chaves estáticas compartilhadas. Isto proporci-ona ao adminstrador de segurança a flexibilidade de personalizar as sessões do CIPE para garantir asegurança assim como para aumentar a produtividade.


Nota

Os parâmetros mais comuns devem ser inseridos no arquivo /etc/cipe/options.cipcbx para ocarregamento automático no momento da execução (runtime).

Esteja ciente de que todos os parâmetros passados como opções na linha de comandossobrescreverão os respectivos parâmetros definidos no arquivo de configuração/etc/cipe/options.cipcbx.

A Tabela 6-1 detalha alguns dos parâmetros de linha de comandos ao rodar o daemon do ciped.

Parâmetros Descrição

arg Passa argumentos ao script de inicialização /etc/cipe/ip-up

cttl Define o valor do TTL (Carrier Time To Live). O valor recomendado é 64

debug Valor boleano para permitir o depuramento de erros

device Nomeia o dispositivo do CIPE

ipaddr Endereço IP publicamente roteável da máquina CIPE

ipdown Escolha um script alternativo ip-down e então o default/etc/cipe/ip-down

ipup Escolha um script ip-up alternativo e então o /etc/cipe/ip-updefault

key Especifica uma chave estática compartilhada para a conexão CIPE

maxerr Número de erros permitidos antes de terminar o daemon do CIPE

me Endereço UDP da máquina CIPE

mtu Define a unidade máxima de transferência do dispositivo

nokey Não use criptografia

peer O endereço UDP do par do CIPE

ping Define o intervalo ping ’keepalive’ específico do CIPE (não ICMP)

socks Endereço IP e número da porta do servidor SOCKS para conexões doproxy

tokey Define o tempo de vida chave dinâmico. O default são 10 minutos (600segundos)

tokxc Valor do tempo limite para intercâmbio de chave compartilhada. Defaultsão 10 segundos

tokxts Valor do tempo limite para registro de data e hora do intercâmbio dechave compartilhada. Default é 0 (sem registro de data ehora/timestamps)

toping Valor do tempo limite para pings ’keepalive’. Default é 0

Tabela 6-1. Parâmetros do CIPE


6.8. Gerenciamento da Chave do CIPEComo mencionado anteriormente, o CIPE incorpora uma combinação segura de chaves de ligaçãoestáticas e tráfego criptografado para criar um túnel seguro através de redes de transporte como aInternet. O uso de chaves de ligação estáticas provém um ponto de referência comum para que duasredes ativadas pelo CIPE passem informações de forma segura. Portanto, é imperativo que as duasportas de comunicação (gateways) de rede ativadas pelo CIPE compartilhem exatamente a mesmachave, caso contrário a comunicação pelo CIPE não será possível.

Gerar chaves do CIPE requer o conhecimento de quais tipos de chaves são compatíveis. Geradoresalfa-numéricos randômicos não funcionam. As chaves estáticas devem ter conjuntos de 32 caracterese 128 bits. Isto pode ser criado executando o seguinte comando, que usa od para criar uma chavehexadecimal usando o dispositivo de número randômico /dev/random:

od -N 16 /dev/random -t x4 | awk ’{print $2 $3 $4 $5}’

Insira o output no arquivo /etc/cipe/options.cipcb0 para todos os servidores e clientes CIPE.

6.9. IPsecO Red Hat Enterprise Linux suporta um protocolo para conectar máquinas e redes remotas entre siusando um túnel seguro em uma rede de transporte comum, como a Internet. O protocolo, chamadoIPSEC, pode ser implementado usando conexões máquina-a-máquina (uma estação de trabalho co-nectada a outra) ou rede-a-rede (uma LAN/WAN conectada a outra). A implementação do IPSEC noRed Hat Enterprise Linux usa IKE (Internet Key Exchange), um protocolo implementado pelo IETFpara ser usado para autenticação mútua e proteger associações entre sistemas conectados.

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

• /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 mais


informaçõe sobre o uso da Ferramenta de Administração de Rede, consulte o Guia de Administra-ção do Sistema do Red Hat Enterprise Linux.

Para conectar duas máquinas em rede através do IPsec, consulte a Seção 6.11. Para conectar umaLAN/WAN a outra através do IPsec, consulte a Seção 6.12.

6.11. 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 a seguir o arquivo ifcfg para a conexão IPsec máquina-a-máquina da estação de trabalho A.O nome único para identificar a conexão neste exemplo é ipsec0, portanto o arquivo resultante énomeado como /etc/sysconfig/network-scripts/ifcfg-ipsec0.

DST=X.X.X.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 substitui X.X.X.X pelo endereço IP da estação de trabalho A. A conexão é definida para iniciarna 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 arquivo da chave pré-compartilhada (chamado /etc/sysconfig/network-scripts/keys-ipsec0) que ambas máquinas usam para autenticarem-se entre si. O conteúdodeste arquivo deve ser idêntico nas duas estações de trabalho, e somente o usuário root deve sercapaz 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 duas es-tações de trabalho. As duas chaves devem ser identicas para que a conexão funcione apropriadamente.

O arquivo /etc/racoon/racoon.conf deve ser idêntico, exceto pela indicação include"/etc/racoon/X.X.X.X.conf". Esta indicação (e o arquivo que referencia) é gerada quando otúnel IPsec é ativado. Para a estação de trabalho A, X.X.X.X na indicação include é o dendereçoIP da estação de trabalho B. O oposto vale para a estação de trabalho B. Veja a seguir um arquivoracoon.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"

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.12. 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 informações de umnódulo de uma rede para outro nódulo de uma rede remota. O Figura 6-2 mostra uma conexão IPsecrede-a-rede passando por um túnel.


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

O diagrama mostra duas LANs (lan0 e lan1) separadas pela Internet. Estas redes usam roteadoresIPSEC para autenticar e iniciar uma conexão, usando um túnel seguro através da Internet. Os pacotesinterceptados em trânsito requerem descriptografia muito forte para crackear a cifra protegendo os pa-cotes entre estas LANs. O processo de comunicação entre um nódulo no intervalo IP 192.168.1.0/24e outro no 192.168.2.0/24 é completamente transparente aos nódulos, já que o processamento, crip-tografia/descriptografia e roteamento dos pacotes IPSEC são executados inteiramente pelo 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, usada para iniciar a conexão e trocar chaves decriptografia durante a sessão

Por exemplo: suponha que a LAN A (lana.example.com) e LAN B (lanb.example.com) queiram se in-terconectar através de um túnel IPsec. O endereço de rede da LAN A está no intervalo 192.168.1.0/24,enquanto a LAN B usa o intervalo 192.168.2.0/24. O endereço IP da porta de comunicação (gateway)é 192.168.1.254 para a LAN A e 192.168.2.254 para a LAN B. Os roteadores IPSEC estão 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 os roteadores IPsec. O administrador da LAN A decide nomear aconexão IPSEC como ipsec0, enquanto o administrador da LAN B nomeia a conexão IPSEC comoipsec1.

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

TYPE=IPsecONBOOT=yesIKE_METHOD=PSK


SRCGW=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éto-do de 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 de origem(SRCNET=192.168.1.0/24). Finalmente, o administrador indica o endereço IP de destino, que é oendereço IP externamente acessível da LAN B (X.X.X.X).

Veja a seguir o arquivo da chave pré-compartilhada (chamado /etc/sysconfig/network-scripts/keys-ipsecX onde X é 0 para a LAN A e 1 para a LAN B) que as duas redes usam paraautenticarem-se entre si. O conteúdos deste arquivo devem ser idênticos e somente o usuário rootpode ser capaz de acessar ou gravar este arquivo.

IKE_PSK=r3dh4tl1nux

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-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 a seguir o arquivo de configuração /etc/racoon/racoon.conf da conexão IPsec. Note quea linha include na parte inferior do arquivo aparece somente se estiver conectada ao túnel IPsec nomomento, porque é automaticamente gerada cada vez que 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"

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


;remote X.X.X.X{

exchange_mode aggressive, main;my_identifier address;proposal {

encryption_algorithm 3des;hash_algorithm sha1;authentication_method pre_shared_key;dh_group 2 ;

}}

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 se comunicarem. As rotas são criadasautomaticamente através do script de início invocado pela execução do ifup na conexão IPsec. Paraexibir 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 auto-rizados, 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.

Além das soluções VPN, como CIPE ou IPSec (abordados em 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 podem sersoluçõ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 firewalls de hardware e de sotfware, também há diferenças na maneira comoos firewalls funcionam, que separam uma solução da outra. 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 (NAT) inseresub-redes IP internasatravés de um ou umpequeno grupo de endereçosIP externos, mascarandotodos os pedidos para umafonte ao invés de várias

< Pode ser configuradotransparentemente paramáquinas em uma LAN< Proteção de muitasmáquinas e serviços portrás de um ou maisendereços IP externos,simplificando tarefas deadministração< Restrição de acesso dousuário de e para a LANpode ser configuradoabrindo e fechando portasno firewall/gateway NAT

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

68 Capítulo 7. Firewalls

Método Descrição Vantagens Desvantagens

FiltrodePacotes

A filtragem de pacotes lêcada pacote de dados quepassa dentro e fora de umaLAN. Pode ler e processarpacotes pela informação docabeçalho e filtra 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.

= Personalizável através dafuncionalidade front-endiptables= 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ção= Já que os pacotes não sãotransmitidos através de umproxy, a performance darede é mais rápida devido àconexão direta do cliente ‘amáquina remota

= Não pode filtrar pacotespara conteúdo similar afirewalls de proxy= Processa pacotes nacamada do protocolo, masnão pode filtrar pacotesnuma camada de aplicação= 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.

= Dá aos administradores ocontrole de quaisaplicações e protocolosfuncionam fora da LAN= Alguns servidores proxypodem armazenar dadosno cache para que clientespossam acessar dadosfrequentementerequisitados no cache localao invés de ter que usar aconexão Internet parasolicitá-los. Isto éconveniente para reduzir oconsumo desnecessário debanda= Serviços proxy podem serregistrados e monitoradosde perto, permitindo umcontrole mais restrito sobrea utilização de recursos narede

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

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-sistema net-filter oferece filtragem de pacote ’stateful’ (que guarda o estado das conexões inciadas pelos clientes)ou ’stateless’ (na qual cada pacote é analisado individualmente, sem levar em conta pacotes anteriorestrocados na mesma conexão), assim como NAT e serviços de mascaramento de IP. Netfilter tambémtem a habilidade de danificar as informações do cabeçalho para roteamento avançado e gerenciamentodo estado de conexão. O Netfilter é controlado através da funcionalidade IPTables.

Capítulo 7. Firewalls 69

7.1.1. Visão geral do IPTablesO poder e flexibilidade do netfilter é implementado através da interface IPTables. Esta ferramenta delinha de comando é similar em sintaxe ao seu predecessor, o IPChains. No entanto, IPTables usa osub-sistema netfilter para melhorar a conexão, inspeção e processamento de rede; enquanto o IPChainsusava conjuntos de regras complexas para filtrar localidades de fonte e destino, assim como portasde conexão para ambos. IPTables inclui registro avançado, ações pré e pós-roteamento, tradução doendereço de rede e encaminhamento de porta; tudo em apenas uma interface de linha de comando.

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

7.2. Usando o IPTablesO primeiro passo para usar o serviç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 coman-dos:

service ip6tables stopchkconfig ip6tables off

Para fazer com que o IPTables inicie por default sempre que a máquina for iniciada, você deve alteraro 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 correnteespecifica o estado no qual um pacote será manipulado. O uso é o seguinte:

iptables -A chain -j target

O -A acrescenta uma regra no fim de um conjunto de regras existentes. A chain é o nome da correntepara uma regra. As três correntes embutidas do IPTables (ou seja, as correntes que afetam todos ospacotes que trafegam pela rede) são INPUT, OUTPUT e FORWARD. Estas correntes são permanentese não podem ser deletadas.

Importante

Ao criar um conjunto de regras do IPTables, é crucial lembrar que a ordem é importante. Por ex-emplo: uma corrente especifica que todos os pacotes da sub-rede local 192.168.100.0/24 sejamderrubados. E então a corrente é adicionada (-A), o que permite pacotes do 192.168.100.13 (queestá 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 em um conjunto de regras existentes, use -I, seguido peloconjunto no qual deseja inserir a regra e pelo 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.

7.2.1. Normas Básicas de FirewallAlgumas normas básicas estabelecidas desde o começo podem auxiliar na construção de regras deta-lhadas definidas pelo usuário. O IPTables usa normas (-P) para criar regras default. Administradorescom foco na segurança geralmente escolhem derrubar todos os pacotes como uma norma e só permi-tem pacotes específicos, analisando-os caso-a-caso. As seguintes regras bloqueiam todos os pacotesentrando e saindo 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 clientes internos de expo-sição inadvertida à Internet. Para fazer isso, use a seguinte regra:

iptables -P FORWARD DROP

Nota

Há uma distinção entre as ações REJECT (rejeitar) e DROP (derrubar) um alvo quando estamos lidandocom regras adicionais. REJECT um alvo nega acesso e retorna um erro conexão negada (conexãonegada) para usuários que tentarem se conectar ao serviço. A DROP, como o nome sugere, derrubaos pacotes sem nenhum aviso para usuários do telnet. Administradores podem usar sua própriaprudência ao lidar com estes alvos; entretanto, para evitar a confusão do usuário e tentativas paracontinuar a conexão, a REJECT alvo é recomendada.

Após definir os cojuntos de normas, crie novas regras para a sua rede e seu requisitos de segurançaem particular. As seguintes seções descrevem algumas regras que você talvez queira implementarenquanto constrói seu firewall IPTables.

7.2.2. Salvando e Restaurando Regras IPTablesRegras de firewall são válidas somente enquanto o computador estiver ligado. Se o sistema for rei-nicializado, as regras serão automaticamente eliminadas e restauradas. Para salvar as regras de modoque 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 iptables

Manter atacantes remotos fora de uma LAN é um aspecto importante da segurança de rede, se não omais importante. A integridade de uma LAN deve ser protegida de usuários remotos maldosos, atra-vé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 se comuniquem entre si ou externamente. Para permitir a usuá-rios executar funções relacionadas à rede e a usar aplicações de rede, os administradores devem abrircertas 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

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

iptables -A INPUT -p tcp --dport 22 -j ACCEPTiptables -A OUTPUT -p udp --sport 22 -j ACCEPT

Pedidos de conexão CIPE feitas de fora podem ser aceitas com o seguinte comando (substituindo xpelo número de seu dispositivo):

iptables -A INPUT -p udp -i cipcbx -j ACCEPTiptables -A OUTPUT -p udp -o cipcbx -j ACCEPT

Já que o CIPE usa seu próprio dispositivo virtual que transmite pacotes de datagramas (UDP), a regrapermite a interface cipcb para conexões de fora, ao invés de portas de recurso ou de destino (apesarde poderem ser usadas no lugar das opções de dispositivos). Para informações sobre o uso do CIPE,consulte o Capítulo 6.

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 IPTables e suas várias opções.

Estas regras permitem o acesso a serviços regulares e seguros pelo firewall; entretanto, não permitemque os nódulos por trás do firewall acessem estes serviços. Para permitir o acesso LAN a estes serviços,você pode usar o NAT com regras de filtragem do IPTables.

7.4. Regras FORWARD e 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 criativasde compartilhar o acesso aos serviços de Internet sem dar poucos endereços IP 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 internamente e externamente. Roteadores de borda (como


firewalls) podem receber transmissões de entrada da Internet e rotear os pacotes para o nódulo pre-tendido na LAN. Ao mesmo tempo, firewall/portasde comunicação (gateways) também podem rotearpedidos de saída de um nódulo da LAN para o serviço remoto da Internet. Esse encaminhamento detráfego de rede pode se tornar perigoso às vezes, especialmente com a disponibilidade de ferramentasde cracking modernas que podem espionar endereços IP internos e fazer com que a máquina remotado atacante atue como um nódulo em sua LAN. Para evitar isso, o iptables oferece normas de rote-amento e encaminhamento que podem ser implementadas para evitar o uso indevido dos recursos derede.

A norma FORWARD permite a um administrador controlar onde os pacotes podem ser roteados em umaLAN. Por exemplo: para permitir o encaminhamento da LAN inteira (assumindo que o firewall/portade comunicação (gateway) 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

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

isto permite que os nódulos da LAN se comuniquem entre si; mas não permite que se comuniquemexternamente (por exemplo: com a Internet). Para permitir que nódulos da LAN com endereços IPprivados se comuniquem com redes públicas externas, configure o firewall com o mascaramento doIP, que mascara pedidos de nódulos da LAN com endereços IP do dispositivo externo do firewall(neste caso, eth0):

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

7.5. DMZs e iptables

Regras também podem definidas para determinadas máquinas, como um servidor dedicado HTTPou FTP, preferencialmente um que esteja isolado da rede interna em uma zona desmilitarizada (de-militarized zone - DMZ). Para definir uma regra para rotear todos os pedidos HTTP externos paraum servidor HTTP dedicado no endereço IP 10.0.4.2 e porta 80 (fora do intervalo 192.168.1.0/24 daLAN), a tradução de endereço de rede (NAT) evoca a tabela PREROUTING para encaminhar os pacotespara o 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.6. 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 portasde elite na linguagem 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) será rejeitado automaticamente.

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

7.7. IP6TablesA introdução do Protocolo de Internet de última geração chamado IPv6, vai além do limite de ende-reç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. Isto podeser 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 for inicializado, altere o statusdo 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: conexões SSH em um servidor de rede ciente do IPv6 pode serpossibilitada 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 aqui.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 do manual sobre 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/ — a homepage oficial do projeto Netfilter/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

• Linux Firewalls, de Robert Ziegler; New Riders Press. — contém muitas informações sobre a con-strução de firewalls usando ambos - IPChains do kernel 2.2 assim como o Netfilter e IPTables.Tópicos adicionais de segurança, como questões de acesso remoto e Sistemas de Detecção de In-trusão també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. Roteadores podem ajudar a pro-teger suas 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 pára.

8.1. Pensando Como o InimigoSuponha que você administre uma rede corporativa. Essas redes são comumente compostas de siste-mas operacionais, aplicações, servidores, monitores de rede, firewalls, sistemas de detecção de intru-sã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 atual, é inevitá-vel que incidentes adversos ocorram, sistemas sejam violados, dados corrompidos e serviços sejaminterrompidos.

Para aprimorar as tecnologias de segurança e auxiliar na proteção de sistemas, redes e dados, pensecomo um cracker e meça a segurança dos sistemas verificando suas fraquezas. Avaliações preventivasde vulnerabilidade em seus prórprios sistemas e recursos de rede podem revelar questões potenciais aserem consideradas antes de um cracker explorá-las.

Uma avaliação de vulnerabilidade é uma auditoria interna da segurança de sua rede e sistemas, cujosresultados indicam a confidencialidade, integridade e disponibilidade de sua rede (conforme explana-do na Seção 1.1.4). Uma avaliação de vulnerabilidade tipicamente começará com uma fase de reco-nhecimento, durante a qual são coletados dados importantes referentes à rede e aos sistemas alvo. Estafase levará à fase de prontidão do sistema, onde o alvo é checado em todas as suas vulnerabilidadesconhecidas. A fase de prontidão culmina na fase do relatório, na qual os resultados são classificadosem alto, médio e baixo risco, e métodos são discutidos para melhorar a segurança (ou para minimizaro 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 seuDMZ, interfaces externas de seu firewall e mais.

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 de fora. Muito pouco é feito paraproteger os internos da empresa (tais como firewalls departamentais, controles de acesso em 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 tipicamente mais 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 potenciais vulne-rabilidades, os testes de penetração tentam explorar os resultados.

Avaliar a instra-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 noprograma ou do usuário. A ferramenta pode encontrar vulnerabilidades que na realidade não existem(falsos positivos) ou, ainda pior, 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, é reco-mendável revisar os resultados da avaliação cuidadosamente antes de conduzir um teste de penetração.

Atenção

Tentar explorar vulnerabilidades dos recursos de produção pode resultar em efeitos adversos naprodutividade e eficiência de seus sistemas e rede.

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

• Foco pró-ativo em segurança da informação

• Encontrar exploits potenciais antes que crackers as encontrem

Capítulo 8. Avaliação de Vulnerabilidade 79

• Tipicamente resulta em sistemas sendo mantidos atualizados e consertados

• Promove o crescimento e ajuda a desenvolver as habilidades dos funcionários

• Redução nas perdas financeiras e publicidade negativa

8.2.1. Estabelece uma MetodologiaPara auxiliar na selação de ferramentas para a avaliação de vulnerabilidade, é útil estabelecer uma me-todologia de avaliação de vulnerabilidade. Infelizmente, não há nenhuma metodologia pré-definida ouaprovada pela indústria no momento, porém bom senso e as melhores práticas podem agir suficiente-mente como guias.

Qual é o alvo? Nós estamos checando um servidor, ou nossa rede inteira e tudo que há nesta rede?Somos internos ou externos à empresa? As respostas a estas questões são importantes, pois te ajudarãoa determinar não apenas quais ferramentas selecionar, mas também a maneira como utilizá-las.

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 típica pode começar com o uso de alguma forma de ferramenta de coleta de informa-ções. Ao acessar a rede inteira, primeiramente mapeie o layout para encontrar máquinas que estejamrodando. Após localizá-las, examine cada máquina separadamente. Focar nestas máquinas requer umoutro conjunto de ferramentas. Saber quais ferramentas utilizar deve ser o passo mais crucial paraachar vulnerabilidades.

Assim como em qualquer aspecto do cotidiano, há muitas ferramentas que desempenham a mesmafunção. Este conceito também se aplica à execução das avaliações de vulnerabilidade. Há ferramentasespecíficas para sistemas operacionais, para aplicações e até mesmo para redes (baseadas nos proto-colos utilizados). Algumas ferramentas são grátis e outras não. Algumas ferramentas são intuitivas efáceis de utiulizar, enquanto outras são obscuras e mal documentadas, mas possuem funcionalidadesque outras não possuem.

Encontrar as ferramnentas corretas pode ser uma tarefa difícil. No final das contas a experiênca conta.Se possível, monte um laboratório de testes e experimente quantas ferramentas puder, anotando ospontos 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 no Red Hat Enterprise Linux que pode ser usada para determinaro layout de uma rede. O Nmap está disponível por muitos anos e provavelmente é a ferramenta maisutilizada na coleta de informações. Foi inclusa 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 avalização de vulnerabilidade. Você pode mapear todas asmáquinas dentro de uma rede, e inclusive passar uma opção que a permite tentar identificar o sistema


operacional rodando em determinada máquina. O Nmap é uma boa base para estabelecer normas deuso de serviços seguros e para parar serviços não usados.

8.3.1.1. Usando o Nmap

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

nmap foo.example.com

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

Starting nmap V. 3.00 ( 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 sunrpc515/tcp open printer950/tcp open oftep-rpc6000/tcp open X11

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

O Nmap testa as portas de comunicação mais comuns em uma rede para escutar ou esperar serviços.Esse conhecimento pode ser útil a um administrador que deseja encerrar serviços desnecessários.

Para mais informações sobre o uso do Nmap, consulte o site oficial no endereço:

http://www.insecure.org/

8.3.2. NessusNessus é um scanner de segurança ’full-service’. A arquitetura plug-in do Nessus permite que usuá-rios personalizem-no para seus sistemas e redes. Assim como qualquer scanner, Nessus é tão bomquanto a assinatura do banco de dados no qual ele se baseia. Felizmente, Nessus é frequentementeatualizado. Suas funcionalidades incluem relatório completo, scanning da máquina e busca de vulne-rabilidades em tempo real. Lembre-se que pode haver falsos positivos e falsos negativos, mesmo comuma ferramenta tão poderosa e atualizada como o Nessus.

Nota

Nessus 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 tão con-hecida.

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

http://www.nessus.org/

Capítulo 8. Avaliação de Vulnerabilidade 81

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

Nota

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

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 desenvolvido pela equipe RAZOR da Bindview, Inc., que pode ser usadopara checar vulnerabilidades. Ele procura pela lista das dez questões mais comuns de segurança daSANS (questões do SNMP, questões de compartilhamento de arquivo, etc). Apesar de não ter tantasfuncionalidades quanto o Nessus, vale a pena investigar o VLAD.

Nota

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

Mais informações sobre o VLAD podem ser encontradas no site da equipe RAZOR na seguinte URL:

http://razor.bindview.com/tools/vlad/index.shtml

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 de rede porvoz/PABX. Conceitos emergentes como o war walking — scanning do perímetro das estruturas físicasde sua empresa para vulnerabilidades de rede sem fio — podem ser investigados e incorporados àssuas avaliações, se necessário. Imaginação e exposição são os únicos limites para planejar e conduziravaliaçõ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 vulnerá-veis como sistemas não seguros, sistemas infectados com vírus trojans e redes rodando serviços nãoseguros. São necessários alarmes para notificar os administradores e membros da equipe de segurançaque uma intrusão ocorreu para que eles possam agir em tempo real contra tal intrusão. Sistemas dedetecção de intrusão foram elaborados para agirem 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 IDSEntender o que é um IDS e as funçionalidades que ele oferece é essencial para determinar qual seráo tipo apropriado para incluir em suas normas de segurança em informática. Esta seção aborda osconceitos por trás dos IDSs, as funcionalidades de cada tipo de IDS e a emergência de IDSs híbridosque aplicam diversas técnicas de detecção e ferramentas em um pacote.

Alguns IDSs são baseados no conhecimento, que alertam prioritariamente os administradores de se-gurança antes de uma intrusão ocorrer utilizando um banco de dados de ataques comuns. Alterna-tivamente, há alguns IDS comportamentais que rastreiam todos os usos de recursos para encontraranomalias, que normalmente são sinais positivos de atividades de maléficas. Alguns IDSs são servi-ços isolados que trabalham por trás do cenário e monitoram passivamente as atividades, registrandoquaisquer pacotes suspeitos vindos de fora. Outros IDSs combinam ferramentas de sistema padrão,configurações alteradas e registro verbal, juntamente à intuição do administrador e sua experiência emcriar um kit de detecção de intrusão poderoso. Avaliar as diferentes técnicas de detecção pode ajudara encontrar uma que seja correta para sua organizaçã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 UNIX

86 Capítulo 9. Detecção de Invasão

e Linux baseados na máquina fazem uso constante do syslog e sua habiliadade em separar eventosregistrados por sua severidade (por exemplo: pequenas mensagens de impressão versus sérios alertasdo kernel). O IDS baseado na máquina filtra os registros (que, no caso de alguns eventos da rede edo kernel, podem ser bastante verbalizados), analisa-os, renomeia as mensagens anômalas com suaprópria classificação de severidade e os agrupa em seu próprio registro especializado para análise doadminstrador.

IDSs baseados na máquina também podem verificar a integridade dos dados de arquivos importantese executáveis. Checam um banco de dados de arquivos importantes (e quaisquer arquivos adicionadospelo administrador) e criam um checksum de cada arquivo com uma utilidade de verificação de con-sistência de arquivo de mensagem como a md5sum (algoritmo de 128 bits) ou a sha1sum (algoritmode 160bits). Então, o IDS baseado na máquina armazena as consistências em um arquivo somentetexto e compara periodicamente a verificação de consistência aos valores do arquivo texto. Se algu-ma das consistências não bater, o IDS alerta o administrador via e-mail ou pager do celular. Este é oprocedimento utilizado pelo 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 emum sistema Red Hat Enterprise Linux. Consulte o Guia de Administração do Sistema do Red HatEnterprise Linux para informações completas sobre o uso do RPM.

Importante

Alguns dos comandos da lista seguinte requerem a importação da chave pública GPG da Red 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 originadosda Red Hat. A chave pode ser importada atribuindo o seguinte comando como root (substituindo>versão ? pela versão do RPM instalado no sistema):

rpm --import /usr/share/doc/rpm- @ version A /RPM-GPG-KEY

Capítulo 9. Detecção de Invasão 87

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 ve-rificação de pacotes instalados e arquivos de pacotes RPM. É altamente recomendado que você fa-ça backup dos conteúdos do diretório do banco de dados RPM (/var/lib/rpm/) para uma mídia


somente-leitura (como um CD-ROM) após instalar o Red Hat Enterprise Linux. Ao fazê-lo é possí-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 em servidor.

• 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 aos IDSs baseadosem servidor. A filosofia de desenvolvimento de um IDS baseado em rede é scanear os pacotes darede no nível do servidor 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 conhecidas 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 maléficas ativiidadesde rede como:

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

• Ataques Denial-of-service

• arp cache poisoning (danificação do protocolo)

• Corrupção do domínio DNS

Capítulo 9. Detecção de Invasão 89

• 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 verda-deiro porque não analisa e aponta anomalias nos pacotes. Ao invés disso, o tcpdump exibe todasas informações dos pacotes na tela de output ou em um arquivo de registro sem análise nenhuma.Um IDS apropriado analisa os pacotes, aponta ransmissões de pacotes potencialmente maléficas e asarmazena em um registro formatado.

O Snort é um IDS desenvolvido para ser compreensivo e correto em 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 esta 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 faz neces-sária. É responsabilidade da equipe de segurança responder ao problema rapida 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, mais também reduzir a publicidade negativa.

Da perspectiva de uma equipe de segurança, não importa se a infração ocorre (como parte das eventu-ais transações usando um meio de rede não confiável, como a Internet), mas sim, quando uma infraçãoocorre. Não pense em um sistema como fraco e vulnerável; é importante perceber que quando há tem-po 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 em http://www.securityfocus.com para obter in-formações detalhadas e atualizadas sobre as recentes infrações e vulnerabilidades de segurança, desdea destruição frequente de páginas web corporativas até os ataques aos servidores DNS em 20021.

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

• Investigação do Incidente

1. http://www.gcn.com/21_32/web/20404-1.html

92 Capítulo 10. Resposta ao 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 da diretoria

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

Os típicos integrantes de uma CERT incluem adminsitradores de sistemas e de rede, assim comoperitos em segurança das informações. Os administradores de sistema proverão o conhecimento ehabilidades dos recursos do sistema, inclusive backups de dados, backup de hardware disponível parauso e outros. Administradores de rede proverão seu conhecimento de protocolos de rede e a habilidadeem redirecionar o tráfego de rede dinamicamente. O pessoal de segurança da informação é útil pararastrear e investigar detalhadamente as questões de segurança assim como para analisar os sistemascomprometidos após a ocorrência.

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 são 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çõesde 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.

Capítulo 10. Resposta ao Incidente 93

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 longo 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 res-postas podem variar. A equipe pode decidir desabilitar as conexões de rede, desligar os sistemas afeta-dos, consertar o exploit e então reconectar rapidamente sem possíveis complicações futuras. A equipetambém pode monitorar os infratores e rastrear suas ações. A equipe pode, inclusive, redirecionar oinfrator para um pote de mel — um sistema ou segmento de rede contendo dados intencionalmentefalsos — para rastrear a invasão de maneira segura e sem interrupção dos recursos de produção.

A resposta a um incidente deve acompanhar também uma coleta de informações sempre que possí-vel. A execução de processos, conexões de rede, arquivos, diretórios e outros devem ser auditadosativamente em tempo real. Ter uma rápida impressão dos recursos de produção para comparação podeser útil ao rastrear serviços ou processos corrompidos. Os integrantes da CERT e os peritos internosserão ;ótimos recursos para rastrear tais anomalias em um sistema. Administradores de sistemas sa-bem quais processos devem ou não aparecer ao executar os comandos top ou ps. Administradoresde rede estão cientes de como funciona o tráfego normal de rede ao executar o snort ou até mesmotcpdump. Estes integrantes da equipe devem conhecer seus sistemas e serem capazes de apontar umaanomalia mais 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 B file-name C

Substitua D file-name E 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 é uma boaopção 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 em uma investigação,ou para comparação com imagens confiáveis. Suponha que haja um único disco rígido no sistema quevocê deseja criar a imagem. Anexe este disco como escravo ao sistema e então use o comando dd paracriar 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 aarquitetura em sua maioria e não podem ser aplicadas genericamente. Entretanto, resposta a indicen-tes, análise e recuperação são tópicos muito importantes. Utilizando o conhecimento e a experiênciaapropriados, 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.

Tabela 10-1 descreve alguns comandos para auditoria e gerenciamento de arquivos. Também lista al-guns exemplos que podem ser usados para identificar apropriadamente arquivos e seus atributos (taiscomo permissões e datas de acesso) para que assim você possa coletar mais evidências ou ítens paraaná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 ocorrênciade 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 na maioria das vezes comoum comando ’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 diversas informações sobreum arquivo, inclusive a hora doúltimo acesso, permissões,configurações UID (ID do usuário) eGID (ID do grupo) e outras. Útilpara verificar quando um executável,de um sistema que sofreu infração,foi utilizado ou modificado pelaúltima vez.

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 recupe-ração dos dados e do sistema. Infelizmente, a natureza da infração é que dita o curso da recuperação. Émuito importante ter sistemas redundantes, backup ou offline, durante este período.

Para recuperar os sistemas, a equipe de resposta deve trazer de volta quaisquer sistemas ou aplica-ções fora do ar, como servidores de autenticação, servidores de banco de dados, e outros recursos deprodução.

É altamente recomendável ter hardware backup da produção pronto para uso, como drives extras, ser-vidores avulsos e outros do gênero. Sistemas prontos devem ter todo o software de produção carregadoe pronto para uso imediato. Somente os dados mais recentes e pertinentes devem ser importados. Estesistema pronto deve ser mantido separadamente do resto da rede. Se ocorrer um comprometimento eo sistema de backup for parte da rede, então não há propósito em ter um sistema backup.

A recuperação do sistema pode ser um processo tedioso. Em muitos casos há dois cursos de açõ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 adminis-tradores também podem consertar as vulnerabilidades penetradas e trazer o sistema afetado de volta àprodução.

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

10.5.2. Consertando o Sistema (patching)Consertar o sistema afetado é um curso de ações mais perigoso e deve ser executado com muitaatenção. O perigo de consertar um sistema ao invés de reinstalar é determinar se você realmente livrouo sistema de trojans, buracos da segurança e dados corrompidos. A maioria dos rootkits (programas


ou pacotes usados por um cracker para obter acesso root em seu sistema), comandos de sistema 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 notasenquanto a resposta estiver ocorrendo para reportar corretamente a questão às organizações, tais comoautoridades locais e federais, ou portais de multi-fabricantes de software, tal como o site ’CommonVulnerabilities and Exposures’ (CVE) em http://cve.mitre.org. Dependendo do tipo de conselho ju-rí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ça desistemas de computador ou interceptar dados em trânsito. Esta parte também detalha alguns dos ser-viços mais utilizados e os números de suas portas associadas, que podem ser úteis a um administradorque pretende atenuar os riscos de ter seus sistemas crackeados.

ÍndiceA. Proteção ao Hardware e à Rede................................................................................................ 101B. Exploits Comuns e Ataques....................................................................................................... 107C. Portas Comuns ........................................................................................................................... 111

Apêndice A.

Proteção ao Hardware e à Rede

A melhor prática antes de aplicar 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 requi-sitos da maneira mais transparente possível. Já que o objetivo principal do Guia de Segurança do RedHat Enterprise Linux é explicar como proteger o Red Hat Enterprise Linux, um exame mais detalha-do da segurança do hardware e da rede física está além do escopo deste documento. No entanto, estecapítulo apresenta uma breve visão geral do estabelecimento de políticas de segurança em relação ahardware 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.

• Computação envolve mais do que somente estações de trabalho rodando software. Empresas mod-ernas requerem um grande poder computacional e serviços de alta disponibilidade, que podemincluir mainframes, clusters de aplicação ou de computador, estações de trabalho poderosas e apli-cações especializadas. Com estes requisitos corporativos, entretanto, aumentou a propensão a falhasde hardware, desastres naturais e a interfêrencias ou roubo de equipamento.

• Conectividade é o método através do qual o administrador pretende conectar recursos díspares emuma rede. Um administrador pode usar a Ethernet (cabeamento CAT-5/RJ-45 de hub ou de comu-tador), ’token ring’, cabo coaxial 10-base-2 ou mesmo tecnologias sem-fio (802.11x). Dependendodo meio que o administrador escolher, determinadas mídias e tecnologias de rede requerem tecnolo-gias complementares, como hubs, roteadores, comutadores, estações base e pontos de acesso. De-terminar uma arquitetura de rede funcional facilitará o processo administrativo se surgirem questõesde segurança.

A partir destas considerações gerais, os administradores podem obter uma visão melhor da imple-mentação. A estrutura de um ambiente computacional pode ser baseado em ambos, necessidades dacorporação e considerações de segurança — uma implementação que atenda uniformemente aos doisfatores.

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ó-gico de uma LAN em termos de recursos providos, distância entre nódulos e meio de transmissão.Dependendo das necessidades da empresa a 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 Ring

A topologia Ring conecta cada nódulo por 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 conectadasdesta maneira (com o FDDI usando uma técnica de ring duplo). No entanto, não há conexões Ethernetcomuns usando esta topologia física, então os rings não são comumente aplicados, exceto em confi-

102 Apêndice A. Proteção ao Hardware e à Rede

gurações legadas ou institucionais com uma grande base de nódulos instalados (em uma universidade,por exemplo).

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

A topologia de canal linear consiste de nódulos conectados a um cabo linear principal terminado (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 servido. Topologias de canal linear são comumente usadas em LANs par-a-par (peer-to-peer)usando cabeamento coaxial e terminadores de 50-93 ohm nas duas extremidades do canal.

A.1.1.3. Topologia Estrela

A topologia Estrela incorpora um ponto central onde os nódulosconectam e através do qual a co-municaçã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 da ou a LAN inteirasão facilmente rastreáveis para esta fonte única.

A.1.2. Considerações de TransmissãoEm uma rede de transmissão, um nódulo enviará um pacote que atravessa todos os outros nódulosaté que o receptor aceite o pacote. Cada nódulo da rede pode concebivelmente receber este pacotede dados até que o receptor processe o pacote. Em uma rede de transmissão, todos os pacotes sãoenviados desta maneira.

Em uma rede comutada (switched network), os pacotes não são transmitidos, mas são processados nohub comutado que, por sua vez, cria uma conexão direta entre os nódulos emissor e receptor, usandoos princípios da transmissão unicast. Isto elimina a necessidade de transmitir pacotes a cada nódulo,assim diminuindo o tráfego operante.

A rede comutada também evita que os pacotes sejam interceptados por usuários ou nódulos maléficos.Em uma rede de transmissão, onde cada nódulo recebe o pacote no caminho de seu destino, usuáriosmaléficos podem configurar seu dispositivo Ethernet para o modo promíscuo e aceitar todos os pacotesindependentemente se os dados são para estes ou não. Uma vez definido no modo promíscuo, umaaplicação sniffer pode ser usada para filtrar, analisar e reconstruir pacotes para senhas, dados pessoaise outros. Aplicações sniffer sofisticadas podem armazenar este tipo de informação em arquivos textoe, talvez, até enviar as informações para fontes arbitrárias (por exemplo: o enedereço de e-mail dousuá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, Linksys e Netgear ofere-cem vários tipos de comutadores com características como a compatibilidade 10/100-Base-T, suportea Ethernet gigabit e suporte ao Acesso Múltiplo de Detecção do Portador e Detecção de Colisão (Car-rier Sensing Multiple Access and Collision Detection - CSMA/CD), que é ideal para redes de tráfegoalto porque enfileira as conexões e detecta quando os pacotes colidem em trânsito.

A.1.3. Redes Sem-fioUma questão emergente para empresas é a mobilidade. Funcionários remotos, técnicos de campoe executivos requerem soluções portáteis, como laptops, organizadores pessoais digitais (PDAs) e

Apêndice A. Proteção ao Hardware e à Rede 103

acesso sem-fio a recursos de rede. O IEEE estabeleceu normas para a especificação sem-fio 802.11,que dita padrões para a comunicaçõa de dados sem-fio para todos os setores. O padrão corrente usadoatualmente é a especificação 802.11b.

As especificações 802.11b e 802.11g são, na verdade, um grupo de padrões que governam as comuni-cações sem-fio e exercem controle sobre o espectro 2.4GHz de rádio frequência (RF) não licensiado(a 802.11a usa o espectro de 5GHz). Estas especificações foram aprovadas como padrões pelo IEEE,e diversos fabricantes comercializam produtos e serviços 802.11x. Os consumidores também adota-ram o padrão para as redes em escritórios pequenos ou caseiros. A popularidade também extendeu-sedas LANs às MANs (Redes de Área Metropolitana), especialmente em áreas populosas onde há umaconcentraçã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 mediada pela 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.11x

Apesar 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 mais básicas. Desde que toda a rede 802.11x esteja feita usando sinais RF debanda alta, os dados transmitidos são facilmente acessíveis a qualquer usuário com um NIC compa-tível, uma ferramenta de scaneamento da rede sem-fio (como o NetStumbler ou o Wellenreiter) eferramentas comuns de sniffing (como dsniff e snort). Para impedir este uso indevido das redesprivadas sem-fio, o padrão 802.11b usa o protocolo Wired Equivalency Privacy (WEP), uma chavecriotografada de 64 ou 128 bits baseada no RC-4 e compartilhada entre cada nódulo ou entre a AP eo nódulo. Esta chave criptografa as transmissões e descriptografa pacotes de entrada dinamicamen-te e transparentemente. Os administradores frequentemente deixam de implementar este esquema decriptografia de chave compartilhada por esquecimento ou porque escolheram não fazê-lo devido à de-gradação do desempenho (especialmente através de distâncias longas). Habilitar o WEP em uma redesem-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 capí-tulo Configuração de Rede do Guia de Administração do Sistema do 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 crackear 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 adicionalsobre a criptografia WEP. Ao usar esta norma, um usuário maléfico externo à rede que crackear acriptografia WEP, também terá que crackear 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 algorit-mos proprietários, ou ainda uma força maior. Os administradores que aplicarem estas normas devem


restringir protocolos somente-texto (como Telnet ou FTP), já que senhas e dados podem ser expostosusando quaisquer dos métodos mencionados anteriormente.

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 segmentados 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 crackearam residemna mesma rota lógica que o resto da rede. Os serviços acessíveis externamente devem residir no quea indústria da segurança chama de zona desmilitarizada (DMZ), um segmento da rede lógica ondeo tráfego de entrada da Internet pode acessar somente àqueles serviços e não podem acessar a redeinterna. Isto é efetivo, pois mesmo que um usuário maléfico faça um exploit na DMZ de uma máquina,o resto da rede interna fica atrás de um firewall em um 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 firewallelaboradas para aceitar, encaminhar, rejeitar e negar transmissões de pacotes. Regras de firewall im-plementadas com iptables ou firewalls de hardware dedicado permitem o roteamento complexo eo encaminhamento de regras, que podem ser usados por administradores para segmentar o tráfego deentrada para serviços específicos em endereços e portas específicos, assim como para permitir quesomente a LAN acesse os serviços internos. Estas medidas podem evitar exploits de spoofing de IP.Para mais informações sobre a implementação de 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 más práticas internas.

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 têm BIOSes que controlam recursos do sistema no níveldo hardware. Usuários de estações de trabalho podem determinar senhas administrativas no BIOS paraimpedir que usuários maléficos reinicializem o sistema ou acessem/roubem informações armazenadasno 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 outroPC sem restrições de BIOS e montá-lo para acessar quaisquer dados contidos nele. Nestes casos, érecomendado que estações de trabalho tenham bloqueios para restringir o acesso ao hardware interno.Medidas especiais de segurança, como cabos de aço com cadeados, podem ser ligados ao chassisdo PC e do laptop para evitar roubo, assim como bloqueios de chave no próprio chassis para evitaracesso interno. Este tipo de hardware é amplamente disponibilizado por fabricantes como Kensingtone 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 individu-

Apêndice A. Proteção ao Hardware e à Rede 105

ais de servidores também estão disponíveis com frentes com trancas 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 da co-locação sãoconhecidas por ser altamente protegidas por seguranças treinados e monitoradas o tempoo todo.

Apêndice B.

Exploits Comuns e Ataques

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

Zero ou SenhaDefault

Deixar senhas administrativas embranco ou usar a senha default providapelo fabricante. Isto é mais comumem hardware, como roteadores eBIOSes, porém alguns dos serviçosque rodam no Linux podem contersenhas default de administrador(apesar do Red Hat Enterprise Linuxnão ser distribuído com elas).

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 comoUNIX e Windows.

Às vezes, administradores criamalguns usuários privilegiados compressa e deixam a senha vazia, umponto de entrada perfeito parausuários maliciosos que descobrem ousuário.

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 Comuns e Ataques


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 uma programa backdoor outrojan para obter controle sobre seusrecursos 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 em 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)

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

Este tipo de ataque geralmenteatinge protocolos de transmissãosomente-texto, como Telnet, FTP etransferências HTTP.O atacante remoto deve ter accesso aum sistema comprometido em umaLAN para poder executar um ataquedeste tipo. Geralmente o crackerusou um ataque ativo (como umspoofing de 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 Comuns e Ataques 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",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.Serviços podem ter vulnerabilidadesque passam desapercebidas durante odesenvolvimento e testes. Estasvulnerabilidades (tais comosobrecarregamentos do buffer, quepossibilitam ao atacante obter acessoao preencher a memória endereçávelcom uma quantidade além daaceitável pelo serviço, prejudicam oserviço e dão ao atacante um promptde comando interativo a partir doqual ele pode executar comandosarbitrariamente) podem oferecercontrole administrativo completo aum 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 Comuns e Ataques


Vulnerabilidadesda Aplicação

Atacantes encontram falhas emaplicações de compuatdores pessoaise estações de trabalho como clientesde e-mail, executam código arbitrárioe implantam trojans paracomprometer ou danificar serviçosfuturamente. Exploits podem ocorrerno futuro se a estação de trabalhocomprometida tiver privilégiosadministrativos para 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 paramulti-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.

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

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

112 Apêndice C. Portas Comuns


Nome Comentário

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

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)

Apêndice C. Portas Comuns 113


Nome Comentário

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ços de Nome do NETBIOS usando no Red HatEnterprise Linux pelo Samba

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

139 netbios-ssn Serviços 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 Gerenciamento de Rede Simples (SNMP -Simple Network Management Protocol)

162 snmptrap Armadilhas SNMP

163 cmip-man Protocolo de Informações de Gerenciamento Comum(CMIP - Common Management Information Protocol)

164 cmip-agent Protocolo de Informações de Gerenciamento Comum(CMIP - Common Management Information Protocol)

174 mailq MAILQ

177 xdmcp Protocolo de Controle do Gerenciamento de Exibição doX

178 nextstep Servidor de janelas do NeXTStep

179 bgp Protocolo da Porta de Comunicação da Divisa (BorderGateway Protocol)

191 prospero Serviços Prospero de Cliffod Neuman

194 irc Internet Relay Chat (IRC)

199 smux Multiplexador UNIX para SNMP

201 at-rtmp Roteamento do AppleTalk

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

204 at-echo Eco do AppleTalk

206 at-zis Informações da zona do AppleTalk



Nome Comentário

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 Internetwork Packet Exchange (IPX), um protocolo dedatagrama geralmente usado em ambientes Netware doNovell

220 imap3 Protocolo de Acesso a Mensagens via Internet versão 3

245 link LINK

347 fatserv Servidor 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 Servidor de Listas do UNIX

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 Gerenciador 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 gerenciamento da chave da sessão doPhoturis

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 Gerenciamento da Chave e da Associação daSegurança de Internet (ISAKMP - Internet SecurityAssociation and Key Management Protocol)

535 iiop Protocolo Internet Inter-Orb (IIOP)

538 gdomap Mapeador de Objetos Distribuídos do GNUstep(GDOMAP - GNUstep Distributed Objects Mapper)



Nome Comentário

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 whoami

587 submissão Agente de Submissão da Mensagem de Correio (MSA -Mail Message Submission Agent)

610 npmp-local Protocolo de Gerenciamento 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 Gerenciamento 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 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 Ata 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)

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)



Nome Comentário

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

As portas seguintes são específicas do UNIX e abrangem diversos serviços, de e-mail a autentica-ção. Os nomes entre colchetes ([serviço], por exemplo) são nomes de daemons para o serviço ouapelido(s) comum(ns).


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] lista de usuários autenticados

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 do talk remote calling

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

532 netnews Notícias de Rede

533/udp netwall Netwall para transmissões de emergência

540/tcp uucp [uucpd] Serviços de cópia Unix-para-Unix



Nome Comentário

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 para oregistro formal na lista de números de porta.


Nome Comentário

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

1236 bvcontrol[rmtcfg]

Servidor de Configuração Remota de Garcilis Packeten a

1300 h323hostcallsc H.323 teleconferencing Host Call Secure

1433 ms-sql-s Microsoft SQL Server

1434 ms-sql-m Microsoft SQL Monitor

1494 ica Cliente Citrix ICA

1512 wins Microsoft Windows Internet Name Server

1524 ingreslock Serviços de bloqueio do Sistema de Gerenciamento doBanco de Dados Ingres (DBMS - Database ManagementSystem)

1525 prospero-np Prospero não-privelegiado

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

1719 h323gatestat H.323 telecommunication Gatekeeper Status

1720 h323hostcall H.323 telecommunication Host Call setup

1758 tftp-mcast Multi-transmissão do FTP Trivial



Nome Comentário

1759 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 accounting da discagem doradius

1813 radius-acct Accounting 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 do Gerenciamento 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 entrega e transporte de avisos Zephyr

2103 zephyr-clt conexão do Zephyr serv-hm

2104 zephyr-hm Administrador da máquina Zephyr

2401 cvspserver Concurrent Versions System (CVS) cliente/operações deservidor

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

2430/udp venus Gerenciador 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]

HPSTGMGR; 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)

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)



Nome Comentário

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 Squid Proxy

3306 mysql Serviço de banco de dados MySQL

3346 trnsprntproxy Proxy Trnsprnt

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 Motor de Configuração (Cfengine - Configuration Engine)

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

6000 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 da Sessão

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)



Nome Comentário

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 da RedeVeritas (bpdbm - NetBackup Database Manager)

13722 bpjava-msvc Veritas NetBackup Java / Protocolo do Microsoft VisualC++ (MSVC)

13724 vnetd Utilitário de Rede Veritas

13782 bpcd Backup de Rede Veritas

13783 vopied Protocolo VOPIED Veritas

22273 wnn6 [wnn4] Sistema de conversão Kana/Kanjic

26000 quake servidores de jogos multi-jogadores do Quake (erelacionados)

26208 wnn6-ds

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 de Gracilis Packeten. O nome oficial estalistado como o nome principal, e o nome não-registrado como apelido."b. Nota do /etc/services: "As portas numeradas de 2600 a 2606 são usadas pelo pacote zebrasem serem registradas. Os nomes principais são os nomes registrados, e os nomes não-registradosusados pelo zebra são listados como apelidos (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 mostra uma lista das portas relacionadas ao Protocolo de Entrega do Datagrama (DDP)usado das redes 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

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

A Tabela C-6 é uma lista de portas não-registradas que são usadas por serviços e protocolos quepodem ser instalados no seu sistema Red Hat Enterprise Linux ou são necessários para a comunicaçãoentre o Red Hat Enterprise Linux e sistemas rodando 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 - Post Office Protocol Password

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 (SUP -Software Upgrade Protocol)Transfer

901/tcp swat Ferramenta de Administração Web do Samba (SWAT -Samba Web Administration Tool)

953 rndc Berkeley Internet Name Domain versão 9 (BIND 9)ferramenta de configuração do daemon de nome remoto

1127 sufiledbg 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



Nome Comentário

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

10082/tcp amandaidx Serviços de backup Amanda

10083/tcp amidxtape Serviços de backup Amanda

20011 isdnlog Sistema de autenticação da Rede Digital de SistemasIntegrados (ISDN - Integrated Systems Digital Network)

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

22305/tcp wnn4_Kr Sistema de input Korerano kWnn

22289/tcp wnn4_Cn Sistema de input Chinês cWnn



Nome Comentário

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, 102

e segurança, 102ética do hacker, 7

Aatacantes e riscos, 7atualizações

(Ver erratas de segurança)auditoria de arquivos

ferramentas, 94

BBIOS

não-equivalentes ao x86senhas, 22

segurança, 21senhas, 21

CCIPE, 54

instalação, 55personalizando, 58

coletando evidências(Ver resposta ao incidente)

ferramentas de auditoria de arquivos, 94dd, 94file, 94find, 94grep, 94md5sum, 94script, 93stat, 94strings, 94

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

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

convençõesdocumentos, ii

crackerhacker de chapéu preto, 7

crackersdefinição, 7

cupsd, 35

Ddd

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

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

DMZ(Ver Zona Desmilitarizada (De-Militarized Zone))(Ver networks)

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

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

exploits comuns e ataques, 107tabela, 107

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

seguras, 38GPG, 38OpenSSH, 38

fileauditoria de arquivos usando, 94

findauditoria de arquivos usando, 94

firewalls, 67pessoal, 37recursos adicionais, 74tipos, 67

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

126

Ggestores de início

GRUBsenha protegendo, 22

LILOsenha protegendo, 23

segurança, 22grep

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, 7chapéu cinza, 7chapéu preto

(Ver cracker)definição, 7

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

Iidade da senha, 28IDS

(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, 73IPsec, 60

configuração, 62máquina-a-máquina, 61

instalando, 60máquina-a-máquina, 61rede-a-rede, 62

iptables, 68e DMZs, 72recursos adicionais, 74usando, 69

KKerberos

NIS, 45

Llpd, 35lsof, 50

Mmd5sum

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

forçando uma senha forte, 27

NNessus, 80Netfilter, 68

recursos adicionais, 74Netfilter 6, 73netstat, 50NFS, 45

e Sendmail, 50erros de sintaxe, 45planejamento de rede, 45

Nikto, 81NIS

apresentando, 43IPTables, 44Kerberos, 45nome de domínio do NIS, 43planejando a rede, 43portas estáticas, 44securenets, 44

nmap, 50, 79versão linha de comando, 80

OOpenSSH, 38

scp, 38sftp, 38ssh, 38

127

Pplano de resposta ao incidente, 91portas

comuns, 111monitorando, 50

portas comunstabela, 111

portas de comunicação, 111portmap, 35

e IPTables, 42e TCP wrappers, 42

post-mortem, 93

Qquestões legais, 92

Rredes, 101

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

Redes Privadas Virtuais (Virtual Private Networks),53

CIPE, 54IPsec, 60

configuração, 62instalando, 60máquina-a-máquina, 61

Redes Wi-Fi(Ver 802.11x)

reportando o incidente, 97resposta ao incidente

coletando evidênciasusando o dd, 93

coletando informação pós-infração, 94criando um plano, 91definição de, 91e questões legais, 92equipe de resposta a emergências de computador(computer emergency response team - CERT), 92implementação, 93introduzindo, 91investigação, 93post-mortem, 93reportando o incidente, 97restaurando e recuperando recursos, 96

restaurando e recuperando recursos, 96consertando o sistema (patching), 96

reinstalando o sistema, 96riscos

consertos e erratas, 9estações de trabalho e PCs, 10, 10

aplicações, 10portas abertas, 8redes, 8

arquiteturas, 8servidores, 8

administração desatenta, 9serviços inseguros, 9

root, 30desativar acesso, 30limitar acesso, 33

com Administrador de Usuários, 33e o su, 33e o sudo, 34

métodos de desativação, 30alterar a shell root, 32com PAM, 32impossibilitar autenticações SSH, 32

permitindo acesso, 30RPM

checar assinatura GPG, 16e detecção de intrusão, 86importando a chave GPG, 16

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

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

BIOS, 21gestores de início

senhas, 22segurança da senha, 24

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

Crack, 28John the Ripper, 28Slurpie, 28

forçando, 27idade, 28metodologia, 27senhas fortes, 25

segurança do servidorFTP, 47

acesso anônimo, 48banner de saudação, 47

128

contas de usuário, 49TCP wrappers e, 49upload anônimo, 48vsftpd, 47

NFS, 45erros de sintaxe, 45planejamento de rede, 45

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

portasmonitorando, 50

portmap, 42Sendmail, 49

e NFS, 50limitando DoS, 50

Servidor HTTP Apache, 46diretivas, 46segurança cgi, 47

TCP wrappers, 39alertas de ataque, 40banners, 39registro, 40

visão geral da, 39xinetd, 41

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

segurança sem-fio, 102802.11x, 102

sendmail, 35apresentando, 49e NFS, 50limitando DoS, 50

senhasdentro de uma empresa, 27

Servidor HTTP Apacheapresentando, 46diretivas, 46segurança cgi, 47

serviços, 50serviços de co-locação, 104serviços de rede, 35

identificando e configurando, 35riscos, 35

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

serviços inseguros, 36rsh, 37Telnet, 37vsftpd, 37

Shell EFIsegurança

senhas, 22sistema básico de input e output

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

baseado em rede, 88Snort, 90

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

Snort, 90sshd, 35stat

auditoria de arquivos usando, 94strings

auditoria de arquivos usando, 94su

e root, 33sudo

e root, 34

TTCP wrappers

alertas de ataque, 40banners, 39e FTP, 49e portmap, 42registro, 40

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

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

Tripwire, 86

Uusuário root

(Ver root)

129

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

conclusão, 6controles

(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, 53vulnerabilidades

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

definindo, 78estabelecendo uma metodologia, 79testes, 78

vírustrojans, 4

Xxinetd, 35

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

ZZona Desmilitarizada (De-Militarized Zone), 72

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 é composto pelas seguintes pessoas:

Sandra A. Moore — Escritora / Mantenedora Principal do Guia de Instalação para as Arquiteturasx86, Itanium™ e AMD64 do Red Hat Enterprise Linux; Escritora / Mantenedora Principal do Guia deInstalação para as Arquiteturas IBM® eServer™ iSeries™ e IBM® eServer™ pSeries™ do Red HatEnterprise Linux; Escritora contribuinte do Guia Passo a Passo do Red Hat Enterprise Linux

Tammy Fox — Escritora Principal/Mantenedora do Guia de Administração do Sistema do Red HatEnterprise Linux; Escritora contribuinte do Guia de Instalação para as Arquiteturas x86, Itanium™e AMD64 do Red Hat Enterprise Linux; Escritora contribuinte do Guia de Segurança do Red Hat En-terprise Linux; Escritora contribuinte do Guia Passo a Passo do Red Hat Enterprise Linux; EscritoraPrincipal/Mantenedora dos scripts e stylesheets personalizados do DocBook

Edward C. Bailey — Escritor Principal/Mantenedor do Introdução à Administração de Sistemas RedHat Enterprise Linux; Escritor Principal/Mantenedor das Notas de Versão; Escritor contribuinte doGuia de Instalação para as Arquiteturas x86, Itanium™ e AMD64 do Red Hat Enterprise Linux

Johnray Fuller — Escritor / Mantenedor Principal do Guia de Referência do Red Hat EnterpriseLinux; Co-escritor e co-mantenedor do Guia de Segurança do Red Hat Enterprise Linux; Escritorcontribuinte do Introdução à Administração de Sistemas Red Hat Enterprise Linux

John Ha — Escritor / Mantenedor Principal do Configurando e Administrando um Cluster do RedHat Cluster Suite; Escritor / Mantenedor Principal do Glossário da Red Hat; Escritor / MantenedorPrincipal do Guia de Instalação para as Arquiteturas IBM® S/390® e IBM® eServer™ zSeries® doRed Hat Enterprise Linux; Co-escritor/co-mantenedor do Guia de Segurança do Red Hat EnterpriseLinux; Escritor contribuinte do Introdução à Administração de Sistemas Red Hat Enterprise Linux;Escritor contribuinte do Guia Passo a Passo do Red Hat Enterprise Linux

A Equipe de Internacionalização da Red Hat é composta pelas seguintes pessoas:

Jean-Paul Aubry — traduções para o Francês

David Barzilay — traduções para o Português Brasileiro

Bernd Groh — traduções para o Alemão

James Hashida — traduções para o Japonês

Michelle Ji-yeen Kim — traduções para o Coreano

Yelitza Louze — traduções para o Espanhol

Noriko Mizumoto — traduções para o Japonês

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

Audrey Simons — traduções para o Francês

Francesco Valente — traduções para o Italiano

Sarah Saiying Wang — traduções para o Chinês Simplificado

Ben Hung-Pin Wu — traduções para o Chinês Tradicional

stuff.mit.edu · ˝ndice Introduçªo...

Documents

Transcript of stuff.mit.edu · ˝ndice Introduçªo...