Red Hat Enterprise Linux 3 Guia de Segurança

Transcrição

Red Hat Enterprise Linux 3
Guia de Segurança
Red Hat Enterprise Linux 3: Guia de Segurança
Copyright © 2003 por Red Hat, Inc.
Red Hat, Inc.
1801 Varsity Drive Raleigh NC 27606-2072 USA Telefone: +1 919 754 3700 Telefone: 888 733 4281 Fax: +1 919 754 3701 PO Box 13588 Research 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 ’Open
Publication License’, versão 1.0 ou mais recente (a versão mais recente está disponível em
http://www.opencontent.org/openpub/).
É proibida a distribuição de versões substancialmente modificadas deste documento sem a permissão explícita do titular dos
direitos autorais.
É proibida a distribuição total ou parcial do trabalho envolvido neste manual, em qualquer formato de livro (papel), para fins
comerciais, sem a autorização prévia do titular dos direitos autorais.
Red Hat, 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 Hat
e 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 outros
paí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
Índice
Introdução ............................................................................................................................................ i
1. Convenções de Documentos ................................................................................................. ii
2. Mais por vir.......................................................................................................................... iv
2.1. Envie-nos Seu Feedback ........................................................................................ v
I. Uma Introdução Genérica à Segurança ......................................................................................... i
1. Visão Geral de Segurança ..................................................................................................... 1
1.1. O que é Segurança em Computadores? ................................................................. 1
1.2. Controles de Segurança.......................................................................................... 5
1.3. Conclusão............................................................................................................... 6
2. Atacantes e Vulnerabilidades ................................................................................................ 7
2.1. Uma Breve História sobre Hackers........................................................................ 7
2.2. Ameaças à Segurança da Rede .............................................................................. 8
2.3. Ameaças à Segurança do Servidor......................................................................... 8
2.4. Ameaças à Segurança da Estação de Trabalho e PC Pessoal............................... 10
II. Configurando o Red Hat Enterprise Linux para Segurança................................................... 13
3. Atualizações de Segurança ................................................................................................. 15
3.1. Atualizando Pacotes............................................................................................. 15
4. Segurança da Estação de Trabalho...................................................................................... 21
4.1. Avaliando a Segurança da Estação de Trabalho................................................... 21
4.2. Segurança do BIOS e do Gestor de Início ........................................................... 21
4.3. Segurança da Senha ............................................................................................. 24
4.4. Controles Administrativos ................................................................................... 29
4.5. Serviços de Rede Disponíveis.............................................................................. 35
4.6. Firewalls Pessoais ................................................................................................ 37
4.7. Ferramentas de Comunicação de Segurança Melhorada ..................................... 38
5. Segurança do Servidor ........................................................................................................ 39
5.1. Protegendo Serviços com TCP Wrappers e xinetd ........................................... 39
5.2. Protegendo o Portmap.......................................................................................... 42
5.3. Protegendo o NIS ................................................................................................. 43
5.4. Protegendo o NFS ................................................................................................ 45
5.5. Protegendo o Servidor HTTP Apache ................................................................. 46
5.6. Protegendo o FTP ................................................................................................ 47
5.7. Protegendo o Sendmail ........................................................................................ 49
5.8. Verificando Quais Portas estão Escutando........................................................... 50
6. Redes Privadas Virtuais (Virtual Private Networks) ........................................................... 53
6.1. VPNs e Red Hat Enterprise Linux ....................................................................... 53
6.2. CIPE (Crypto IP Encapsulation).......................................................................... 53
6.3. Por que usar o CIPE? ........................................................................................... 54
6.4. Instalação do CIPE............................................................................................... 55
6.5. Configuração do Servidor CIPE........................................................................... 55
6.6. Configurando Clientes para o CIPE..................................................................... 56
6.7. Personalizando o CIPE ........................................................................................ 58
6.8. Gerenciamento da Chave do CIPE....................................................................... 59
6.9. IPsec..................................................................................................................... 60
6.10. Instalação do IPsec............................................................................................. 60
6.11. Configuração Máquina-a-Máquina do IPsec ..................................................... 61
6.12. Configuração Rede-a-Rede do IPsec ................................................................. 62
7. Firewalls.............................................................................................................................. 67
7.1. Netfilter e IPTables .............................................................................................. 68
7.2. Usando o IPTables ............................................................................................... 69
7.3. Filtragem Comum do iptables ......................................................................... 70
7.4. Regras FORWARD e NAT ....................................................................................... 71
7.5. DMZs e iptables .............................................................................................. 72
7.6. Vírus e Endereços IP Espionados (spoofed)........................................................ 73
7.7. IP6Tables.............................................................................................................. 73
7.8. Recursos Adicionais............................................................................................. 74
III. Avaliando Sua Segurança .......................................................................................................... 75
8. Avaliação de Vulnerabilidade ............................................................................................. 77
8.1. Pensando Como o Inimigo................................................................................... 77
8.2. Definindo Avaliação e Testes ............................................................................... 78
8.3. Avaliando as Ferramentas .................................................................................... 79
IV. Intrusões e Resposta a Incidentes ............................................................................................. 83
9. Detecção de Invasão............................................................................................................ 85
9.1. Definindo Sistemas de Detecção de Intrusão....................................................... 85
9.2. IDS baseado no servidor ...................................................................................... 85
9.3. IDS baseado em rede ........................................................................................... 88
10. Resposta ao Incidente ....................................................................................................... 91
10.1. Definindo Resposta ao Incidente ....................................................................... 91
10.2. Criando um Plano de Resposta ao Incidente...................................................... 91
10.3. Implementando o Plano de Resposta ao Incidente ............................................ 93
10.4. Investigando o Incidente .................................................................................... 93
10.5. Restaurando e Recuperando Recursos ............................................................... 96
10.6. Reportando o Incidente ...................................................................................... 97
V. Apêndices ...................................................................................................................................... 99
A. Proteção ao Hardware e à Rede ....................................................................................... 101
A.1. Topologias de Rede Segura............................................................................... 101
A.2. Segurança de Hardware..................................................................................... 104
B. Exploits Comuns e Ataques ............................................................................................. 107
C. Portas Comuns ................................................................................................................. 111
Índice Remissivo.............................................................................................................................. 125
Considerações finais........................................................................................................................ 131
Introdução
Bem-vindo ao Guia de Segurança do Red Hat Enterprise Linux!
O Guia de Segurança do Red Hat Enterprise Linux é desenvolvido para auxiliar usuários do Red
Hat Enterprise Linux a aprender os processos e práticas para proteger estações de trabalho e servidores de intrusões locais e remotas, exploits e atividades maldosas. O Guia de Segurança do Red
Hat Enterprise Linux detalha o planejamento e as ferramentas envolvidas na criação de um ambiente
computacional seguro para o centro de dados (data center), ambiente de trabalho e doméstico. Com o
conhecimento, vigilância e ferramentas apropriados, os sistemas rodando o Red Hat Enterprise Linux
podem ser totalmente funcionais e protegidos contra os métodos de intrusão e exploit mais comuns.
Este manual aborda detalhadamente diversos tópicos relacionados a segurança, incluindo:
•
Firewalls
•
Criptografia
•
Protegendo Serviços Críticos
•
Redes Privadas Virtuais (Virtual Private Networks)
•
Detecção de Intrusão
O manual é dividido nas partes seguintes:
•
Introdução Genérica à Segurança
•
Configurando o Red Hat Enterprise Linux para Segurança
•
Avaliando Sua Segurança
•
Intrusões e Resposta a Incidentes
•
Apêndice
Nós gostaríamos de agradecer Thomas Rude por suas generosas contribuições a este manual. Ele
escreveu 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 e
deseja mais informações sobre como utilizar o sistema, por favor consulte os seguintes manuais, que
abordam os aspectos fundamentais do Red Hat Enterprise Linux de forma mais detalhada que o Guia
de Segurança do Red Hat Enterprise Linux:
•
O Guia de Instalação do Red Hat Enterprise Linux traz informações sobre a instalação.
•
O Introdução à Administração de Sistemas Red Hat Enterprise Linux contém informações introdutó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 detalhadas
sobre como configurar o Red Hat Enterprise Linux para servir suas necessidades particulares como
usuário. Este manual inclui alguns serviços que são abordados (sob o ponto de vista de segurança)
no Guia de Segurança do Red Hat Enterprise Linux.
•
Guia de Referência do Red Hat Enterprise Linux traz informações detalhadas para a consulta dos
usuários mais experientes quando necessária, ao contrário das instruções passo-a-passo.
As versões HTML, PDF e RPM dos manuais estão disponíveis no CD de Documentação do Red Hat
Enterprise Linux e online: http://www.redhat.com/docs/.
ii
Introdução
Nota
Apesar deste manual refletir as informações mais recentes possíveis, leia as Notas da Versão do Red
Hat Enterprise Linux para acessar as informações que não estavam disponíveis antes da finalização
de nossa documentação. Elas podem ser encontradas no CD 1 do Red Hat Enterprise Linux e online:
http://www.redhat.com/docs/.
1. Convenções de Documentos
Ao ler este manual, determinadas palavras estão representadas com fontes, tipos, tamanhos e pesos
diferentes. Este destaque é sistemático; palavras diferentes são representadas no mesmo estilo para
indicar sua inclusão em uma categoria específica. Os tipos de palavras representadas desta maneira
incluem as seguintes:
comando
Os comandos do Linux (e comandos de outros sistemas operacionais, quando usados) são representados desta maneira. Este estilo indica que você pode digitar a palavra ou frase na linha de
comandos e pressionar [Enter] para invocar um comando. Às vezes o comando contém palavras
que serão exibidas em um estilo diferente por si só (como nomes de arquivos). Nestes casos,
estas são consideradas parte do comando, e então a frase inteira será exibida como um comando.
Por exemplo:
Use o comando cat testfile para visualizar o conteúdo de um arquivo chamado testfile,
no diretório de trabalho atual.
nome do arquivo
Nomes de arquivos, diretórios, localidades de arquivos e nomes de pacotes RPM são representados desta maneira. Este estilo indica que existe um determinado arquivo ou diretório com aquele
nome no seu sistema. Exemplos:
O arquivo .bashrc do seu diretório ’home’ contém definições da janela de comandos tipo bash
e apelidos para seu uso pessoal.
O arquivo /etc/fstab contém informações sobre os dispositivos e sistemas de arquivo diferentes do sistema.
Instale o RPM webalizer se você quiser usar um programa de análise do arquivo de registro do
servidor Web.
aplicação
Este estilo indica que o programa é uma aplicação direcionada ao usuário final (ao contrário do
software do sistema). Por exemplo:
Use o Mozilla para navegar na Web.
[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]. Seu
terminal exibe uma lista dos arquivos contidos no diretório que começam com esta letra.
[tecla]-[combinação]
Uma combinação de sequência de teclas é representada desta maneira. Por exemplo:
A combinação de teclas [Ctrl]-[Alt]-[Espaço] termina sua sessão gráfica, retornando à tela ou ao
console da autenticação gráfica.
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 texto
exibido neste estilo é usado na identificação de uma tela GUI específica ou um elemento de uma
tela GUI (como o texto associado a uma caixa de verificação ou campo). Exemplo:
Selecione a caixa de verificação Solicitar Senha se você deseja que seu protetor de tela solicite
uma senha antes de ser desbloqueado.
nível superior de um menu em uma tela ou janela GUI
Uma palavra neste estilo indica que a palavra está no nível superior de um menu suspenso (pulldown menu). Se você clicar na palavra na tela GUI, o resto do menu deverá aparecer. Por exemplo:
Abaixo de Arquivo em um terminal do GNOME, você verá a opção Nova Aba, que permite a
você abrir diversos prompts de comando na mesma janela.
Se você precisar digitar uma sequência de comandos a partir de um menu GUI, eles são exibidos
como o exemplo a seguir:
Vá para Botão do Menu Principal (no Painel) => Programação => Emacs para iniciar o editor
de texto Emacs.
botão em uma tela ou janela GUI
Este estilo indica que o texto pode ser encontrado em um botão clicável de uma tela GUI. Por
exemplo:
Clique no botão Voltar para retornar à última página web que você visitou.
output do computador
Texto neste estilo indica o texto exibido em uma janela de comandos, como mensagens de erro e
respostas a comandos. Por exemplo:
O comando ls exibe o conteúdo de um diretório:
Desktop
Mail
about.html
backupfiles
logs
mail
paulwesterberg.png
reports
O output exibido em resposta ao comando (neste caso, o conteúdo do diretório) é apresentado
neste estilo.
prompt
Um prompt (ou janela de comandos), uma forma computacional de dizer que o computador está
pronto para você inserir algo (input), será exibido desta maneira. Exemplos:
$
#
[stephen@maturin stephen]$
leopard login:
input do usuário
O texto que o usuário precisa digitar, na linha de comandos ou em uma caixa de texto em uma
tela GUI, é apresentado neste estilo. No exemplo a seguir, text é exibido neste estilo:
Para inicializar seu sistema no programa de instalação em modo texto, você deve digitar o comando 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ão
apresentados neste estilo. No exemplo a seguir, version-number é exibido neste estilo:
O
diretório da fonte do kernel é /usr/src/ version-number /,
version-number é a versão do kernel instalado neste sistema.
onde
Adicionalmente, nós utilizamos diversas estratégias diferentes para chamar sua atenção a determinadas partes da informação. De acordo com o quão crucial as informações são para seu sistema, elas são
apresentadas como uma nota (lembrete), dica, importante, atenção ou um aviso. Por exemplo:
Nota
Lembre-se que o Linux é sensível a maiúsculas e minúsculas. Em outras palavras, uma rosa não é
uma ROSA nem uma rOsA.
Dica
O diretório /usr/share/doc/ contém documentação adicional para os pacotes instalados em seu
sistema.
Importante
Se você modificar o arquivo de configuração do DHCP, as alterações não tomarão efeito até que
você reinicie o daemon do DHCP.
Atenção
Não execute tarefas de rotina como root — use uma conta de usuário comum, a não ser que você
precise usar a conta root para tarefas de administração do sistema.
Aviso
Cuidado para remover somente as partições necessárias do Red Hat Enterprise Linux. Remover
outras partições pode resultar na perda de dados ou num ambiente de sistema corrompido.
Introdução
v
2. Mais por vir
O Guia de Segurança do Red Hat Enterprise Linux é parte do crescente comprometimento da Red
Hat em prover suporte e informações úteis e oportunos para usuários do Red Hat Enterprise Linux.
Conforme novas ferramentas e metodologias de segurança são criadas, este guia será expandido para
incluí-las.
2.1. Envie-nos Seu Feedback
Se você encontrar um erro de digitação no Guia de Segurança do Red Hat Enterprise Linux ou se
pensar numa maneira de aprimorar este manual, nós gostaríamos de saber! Por favor, submeta um
relatório ao Bugzilla (http://bugzilla.redhat.com/bugzilla/) sobre o componente rhelsg.
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 para
podermos 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 em
torno desta questão. Também aborda alguns dos riscos enfrentados por usuários e administradores de
computadores.
Índice
1. Visão Geral de Segurança .............................................................................................................. 1
2. Atacantes e Vulnerabilidades......................................................................................................... 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 controle
de nossas informações pessoais, as indústrias têm sido constituídas com a prática de segurança nos
computadores e nas redes. Empreendimentos têm solicitado o conhecimento e habilidades de peritos
em segurança para auditar sistemas apropriadamente e customizar soluções para os requerimentos
operacionais das organizações. Já que a maioria das organizações são dinâmicas por natureza, com
funcionários acessando os recursos de IT da empresa localmente e remotamente, a necessidade de
ambientes de rede seguros se tornou ainda mais acentuada.
Infelizmente, a maioria das empresas (assim como usuários individuais) encaram a segurança como
uma preocupação em segundo plano, um processo visto em favor de questões de aumento de poder, produtividade e orçamentárias. Implementações de segurança apropriadas são frequentemente
executadas postmortem — após uma intrusão não autorizada já ter ocorrido. Peritos em segurança
concordam 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 processamento de dados. Setores que dependem de sistemas de computador e redes para conduzir transações
diárias de negócios e acessar informações cruciais, encaram em seus dados como uma parte importante de seus recursos. Diversos termos e medidas foram inseridos em nosso cotidiano, tais como custo
total de propriedade (total cost of ownership - TCO) e qualidade de serviço (quality of service - QoS).
Nestas medidas, setores calculam aspectos como integridade de dados e alta disponibilidade como
parte de seus custos de planejamento e gerenciamento de processos. Em alguns setores, tal como comércio eletrônico, a disponibilidade e confiabilidade de dados pode ser a diferença entre sucesso e
fracasso.
1.1.1. Como surgiu a Segurança em Computadores?
Muitos leitores talvez lembrem do filme "Jogos de Guerra," com Matthew Broderick no papel de um
estudante colegial que invade o supercomputador do Departamento de Defesa dos EUA (Department
of Defense - DoD), e inadvertidamente causa uma ameaça nuclear. Neste filme, Broderick usa seu
modem para discar ao computador do DoD (chamado WOPR) e brinca de jogos com o software artificialmente inteligente controlando todos os armazéns de mísseis nucleares. O filme foi lançado durante
a "guerra fria" entre a ex União Soviética e os EUA e foi considerado um sucesso em seu lançamento
em 1983. A popularidade do filme inspirou muitas pessoas e grupos a começar a implementar alguns
dos métodos que o jovem protagonista utilizou para violar sistemas restritos, inclusive o que é conhecido como war dialing — um método de busca de números de telefone para conexões de modem
analógicos em uma combinação de determinado prefixo de área e prefixo de telefone.
Mais de 10 anos depois, após uma busca multi-jurisdição de quatro anos envolvendo o FBI (Federal
Bureau of Investigation) e a ajuda de profissionais de computação em todo o país, o notório cracker
Kevin Mitnick foi preso e processado por 25 fraudes de contas de computador e acesso a dispositivos,
que resultaram em perdas de propriedade intelectual e código-fonte da Nokia, NEC, Sun Microsystems, Novell, Fujitsu e Motorola estimadas em US$80 milhões. Na época, o FBI considerou-o como
o maior crime relacionado a computadores na história dos EUA. Ele foi condenado e sentenciado a
68 meses de prisão por seus crimes, dos quais serviu 60 meses antes de sua condicional em 21 de
Janeiro de 2000. Ele foi proibido de usar computadores ou prestar qualquer consultoria relacionada a
computadores até 2003. Investigadores dizem que Mitnick era perito em engenharia social — utilizar
indivíduos para ganhar acesso a senhas e sistemas usando credenciais falsificadas.
2
Capítulo 1. Visão Geral de Segurança
A segurança da informação evoluiu através dos anos devido à crescente dependência de redes públicas
para expor informações pessoais, financeiras e outras informações restritas. Há diversos casos como
o de Mitnick e o de Vladamir Levin (consulte a Seção 1.1.2 para mais informações) que surgiram em
empresas de todos os setores para repensar a maneira com que lidam com a transmissão e exposição de
informações. A popularidade da Internet foi um dos aspectos mais importantes que exigiu um esforço
intenso em segurança de dados.
Um número cada vez maior de pessoas está utilizando seu computador pessoal para acessar os recursos
que a Internet oferece. De pesquisas e recuperação de informações a correspondência eletrônica e
transações comerciais, a Internet é considerada um dos desenvolvimentos mais importantes do século
XX.
A Internet e seus protocolos mais antigos, no entanto, foram desenvolvidos como um sistema baseado
em confiança. Ou seja, o Protocolo de Internet (IP) não foi desenvolvido para ser intrinsicamente seguro. Não há padrões de segurança aprovados dentro do esquema de comunicação TCP/IP, deixando-o
aberto a usuários maldosos e processos através da rede. O desenvolvimento de modems tornou a comunicação via Internet mais segura, mas ainda há diversos incidentes que ganham atenção nacional e
nos alertam para o fato de que nada é completamente seguro.
1.1.2. Cronologia da Segurança em Computadores
Diversos eventos-chave contribuíram para o nascimento e crescimento da segurança em computadores. Veja a seguir uma lista de alguns dos eventos mais importantes na história da computação e
seguranç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-1
da escola. O grupo evetualmente usa o termo "hacker" no contexto em que é conhecido hoje.
•
O DoD (Departamento de Defesa dos EUA) cria a Rede da Agência de Projetos de Pesquisa
Avançada (Advanced Research Projects Agency Network - ARPANet), que ganha popularidade
em pesquisas e círculos acadêmicos como um condutor do intercâmbio eletrônico de informações
e dados. Isto pavimentou o caminho para a criação da rede de transporte conhecida hoje como
Internet.
•
Ken Thompson desenvolve o sistema operacional UNIX, amplamente aclamado como o sistema
operacional mais "hacker-friendly" devido às suas ferramentas acessíveis a desenvolvedores e compiladores e também à sua comunidade de usuários colaborativos. Quase ao amesmo tempo, Dennis
Ritchie desenvolve a linguagem de programação C, discutivelmente a linguagem hacking mais popular 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 o
governo e indústria, desenvolve o protocolo telnet, uma extensão pública da ARPANet. Isto abre
portas para o uso público de redes de dados antes restrito a empresas do governo e pesquisadores
acadêmicos. O Telnet, no entanto, também é discutivelmente o protocolo mais inseguro para redes
públicas, de acordo com diversos pesquisadores em segurança.
•
Steve Jobs e Steve Wozniak fundaram a Apple Computer e começaram a comercializar o computador pessoal (Personal Computer - PC). O PC é o trampolim para diversos usuários maldosos
aprenderem a arte do cracking remoto em sistemas, usando hardware de comunicação comum de
PC, como modems analógicos e war dialers.
•
3
Jim Ellis e Tom Truscott criam o USENET, sistema de estilo mural (bulletin-board) para comunicação eletrônica entre usuários díspares. O USENET rapidamente se torna um dos meios mais
populares 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 arquitetura
relativamente barata que trouxe a computação do escritório para casa. Isto serve para transformar o
PC numa ferramenta comum e acessível, que era relativamente poderosa e fácil de usar, ajudando a
proliferação deste tipo de hardware nos lares e escritórios de usuários maldosos.
•
O Protocolo de Controle de Transmissão (Transmission Control Protocol), desenvolvido por Vint
Cerf, é dividido em duas partes distintas. O Protocolo de Internet (IP) surge desta divisão, e o
protocolo combinado TCP/IP torna-se o padrão para toda a comunicação via Internet de hoje.
•
Baseada em desenvolvimentos na área de phreaking, ou explorando e hackeando o sitema de telefonia, a revista 2600: The Hacker Quarterly é criada e começa a abordar temas como o cracking e
redes de computadores para uma grande audiência.
•
A gang 414 (assim nomeada em função do código de área de onde ela hackeava) é surpreendida
pelas autoridades após nove dias de cracking no qual a gang violou os sistemas de uma localização
altamente secreta, o Los Alamos National Laboratory, um local de pesquisas de armas nucleares.
•
’The Legion of Doom’ e o ’Chaos Computer Club’ são dois grupos pioneiros de crackers que
começam a explorar as vulnearbilidades em computadores e redes eletrônicas de dados.
•
O Ato de Fraude e Abuso de Computador de 1986 (Computer Fraud and Abuse Act) foi votado
e transformado em lei pelo congresso americano baseado nos exploits de Ian Murphy, também
conhecido com Capitão Zap, que violou computadores militares, roubou informações de bancos
de dados de pedidos de mercadorias e utilizou os quadros restritos de distribuição de telefone do
governo para efetuar ligações telefônicas.
•
Baseado no Ato de Fraude e Abuso de Computador, a côrte pôde condenar Robert Morris, um graduando, 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 abandonou os estudos, que crackeou e fez mal-uso dos sistemas da AT&T e do DoD (Departamento de
Defesa dos EUA).
•
Baseado na preocupação de que a órdea do Morris Worm pudesse ser replicada, é criada a Equipe
de Resposta a Emergências de Computador (Computer Emergency Response Team - CERT) para
alertar usuários das questões de segurança em redes.
•
Clifford Stoll escreve The Cuckoo’s Egg, o resultado de sua investigação sobre crackers que exploraram 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. O
amplo desenvolvimento e adoção do Linux se deve, em grande parte, à colaboração e comunicação
de usuários e desenvolvedores via Internet. Devido às suas raízes no Unix, o Linux é mais popular
entre hackers e administradores que o consideram muito útil para elaborar alternativas seguras para
servidores legados que rodam sistemas operacionais proprietários (com código fechado).
•
O navegador (browser) gráfico é criado e estimula uma demanda exponencialmente alta por acesso
público à Internet.
4
•
Vladimir Levin é cúmplice da transfência ilegal de US$10 milhões em fundos para diversas contas
crackeando o banco de dados central do CitiBank. Levin é preso pela Interpol e quase todo o
dinheiro é recuperado.
•
Possivelmente, o precursor de todos os crackers é Kevin Mitnick, que hackeou diversos sistemas
corporativos roubando tudo - de informações pessoais de celebridades a mais de 20.000 números
de cartões de crédito e código fonte de software proprietário. Ele é preso, condenado por fraude e
fica 5 anos na prisão.
•
Kevin Poulsen e um cúmplice desconhecido manipulam sistemas de telefonia de uma estação de
rádio para ganhar carros e prêmios em dinheiro. Ele é condenado por fraude e sentenciado a 5 anos
de prisão.
•
As histórias de cracking e phreaking se tornam lendas; e muitos crackers em potencial se reúnem
na convenção anual DefCon para celebrar o cracking e trocar idéias entre seus pares.
•
Um estudante israelense de 19 anos é preso e condenado por coordenar várias violações aos sistemas do governo americano durante o conflito no Golfo Pérsico. Oficiais militares o chamam de
"o ataque mais organizado e sistemático" a sistemas de governo na história dos EUA.
•
A Procuradora dos EUA Janet Reno, em resposta às crescentes violações de segurança aos sistemas
do governo, estabelece o Centro de Proteção à Infraestrutura Nacional (National Infrastructure Protection Center).
•
Satélites de comunicação ingleses são tomados e controlados por criminosos desconhecidos. O
governo britânico eventualmente se apropria do controle dos satélites.
1.1.3. A Segurança Hoje
Em Fevereiro de 2000, um ataque 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 controle do yahoo.com, cnn.com, amazon.com, fbi.gov e vários outros sites completamente inacessíveis
para usuários normais, pois bloqueou roteadores por várias horas com transferências de grandes pacotes ICMP, também chamados de ping flood. O ataque foi de autoria desconhecida usando programas
criados especialmente e amplamente disponíveis , que sannearam servidores de rede vulneráveis, instalaram aplicações cliente chamadas trojans nos servidores e marcaram um ataque com todos os servidores infectados inundando os sites vítimas e tornando-os indisponíveis. Muitos culparam o ataque
à obsolescência da maneira como roteadores e protocolos usados são estruturados para aceitar todos
os dados externos, não importando de onde ou para qual propósito os pacotes são enviados.
Isso nos traz ao novo milênio, um tempo em que aproximadamente 400 milhões de pessoas usam ou
usaram a Internet no mundo. Ao mesmo tempo:
•
Em dia qualquer, são estimados 225 grandes incidentes de exploração de vulnerabilidade reportados
ao 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. No
momento da elaboração deste manual, o número de incidentes reportados apenas no primeiro quarto
de 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 dois
anos 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çamentos de IT. Empresas que requerem iontegridade de dados e alta disponibilidade, evocam as habilidades de administradores de sistemas, desenvolvedores e engenheiros para garantir confiabilidade de
seus sistemas, serviços e informações. Cair nas mãos de usuários, processos ou ataques coordenados
maldosos é uma ameaça direta ao sucesso da empresa.
5
Infelizmente, a segurança de sistemas e redes pode ser uma tarefa difícil, que requer o conhecimento
complexo de como a empresa encara, usa, manipula e transmite suas informações. Entender a maneira
como a empresa (e as pessoas que a constituem) conduz os negócios é primordial para a implementação de um plano de segurança apropriado.
1.1.4. Padronizando a Segurança
Empresas de todos os setores dependem de regulamentações e padrões definidos por associações como a Associação Médica Americana (American Medical Association - AMA) ou o Instituto de Engenheiros Elétricos e Eletrônicos (Institute of Electrical and Electronics Engineers - IEEE). As mesmas
idéias valem para a segurança da informação. Muitas consultorias e fabricantes da área de segurança
concordam com o modelo de segurança padrão conhecido como CIA, ou Confidentiality, Integrity,
and Availability (Confidencialidade, Intergridade e Disponibilidade). Esse modelo de três pilares é
um componente geralmente aceito para avaliar riscos às informações delicadas e para estabelecer
uma política de segurança. A explicação a seguir detalha o modelo CIA:
•
Confidencialidade — Informações delicadas devem estar disponíveis apenas para um conjunto prédefinido de indivíduos. A transmissão ou o uso não autorizado de informações devem ser restritos.
Por exemplo: a confidencialidade da informação garante que as informações pessoais ou financeiras
de um cliente não seja obtida por um indivíduo não autorizado para propósitos maldosos como
roubo de identidade ou fraude de crédito.
•
Integridade — As informações não devem ser alteradas de modo a torná-las incompletas ou incorretas. Usuários não autorizados devem ter restrições para modificar ou destruir informações
delicadas.
•
Disponibilidade — As informações devem estar acessíveis a usuários autorizados sempre que precisarem. Disponibilidade é a garantia de que aquela informação pode ser obtida com uma frequencia
e periodicidade pré-definidas. Isto é frequentemente medido em termos de porcentagens e definido
formalmente nos Acordos de Nível de Serviço (Service Level Agreements - SLAs) usados por
provedores de serviços de rede e seus clientes corporativos.
1.2. Controles de Segurança
A segurança em computadores é frequentemente dividida em três categorias principais, comumente
referidas como controles:
•
Física
•
Técnica
•
Administrativa
Estas três categorias abrangentes definem os objetivos principais de uma implementação de segurança
apropriada. Dentre estes controles há sub-categorias que detalham minuciosamente os controles e
como implementá-los.
1.2.1. Controles Físicos
O controle físico é a implementação de medidas de segurança em uma estrutura definida usada para
deter ou evitar acesso não autorizado a material delicado. Alguns exemplos de controles físicos:
•
Câmeras de vigilância de circuito fechado
•
Sistemas de alarme térmicos ou de movimento
6
•
Guardas de segurança
•
Identidades com foto
•
Portas de aço trancadas com fechaduras ’dead-bolt’
1.2.2. Controles Técnicos
O controle técnico uitilizam a tecnologia como base para controlar o acesso e o uso de dados delicados
através de uma estrutura física e através de uma rede. Os controles técnicos têm um escopo de grande
alcance e incluem tecnologias como:
•
Criptografia
•
Cartões inteligentes
•
Autenticação de rede
•
Listas de controle de acesso (Access control lists - ACLs)
•
Software de auditoria de integridade de arquivos
1.2.3. Controles Administrativos
Os controles administrativos definem os fatores humanos da segurança. Envolvem todos os níveis de
pessoal em uma empresa e determinam quais usuários têm acesso a quais recursos e informações,
através dos seguintes meios:
•
Treinamento e conscientização
•
Preparação para desastres e planos de recuperação
•
Recrutamento de pessoal e estratégias de separação
•
Registro e avaliação de pessoal
1.3. Conclusão
Agora que você aprendeu um pouco sobre as origens, razões e aspectos da segurança, pode determinar
o curso de ações apropriado em relação ao Red Hat Enterprise Linux. É importante saber quais fatores
e condições compoem a segurança para planejar e implementar uma estratégia apropriada. Com estas
informacões em mente, o processo pode ser formalizado e o caminho torna-se mais claro conforme
você 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 das
razões que motivaram atacantes a explorar e comprometer sistemas. Mas antes de detalhar estas questões, precisamos definir a terminologia utilizada ao identificar um atacante.
2.1. Uma Breve História sobre Hackers
O significado moderno da palavra hacker tem origem nos anos 60 e no ’Tech Model Railroad Club’
do Instituto de Tecnologia de Massachusetts (MIT), que desenvolveu locomotivas de grande escala e
detalhes complexos. Hacker era o nome usado para os membros do clube que descobriram um novo
truque ou uma nova forma de resolver um problema.
Desde então o termo hacker descreve de tudo, de viciados em computador a programadores talentosos.
Um aspecto comum dentre a maioria dos hackers é a vontade de explorar detalhadamente as funções
dos sistemas e redes de computador com pouco ou nenhum estímulo exterior. Desenvolvedores de
software open source geralmente consideram seus colegas e a si próprios como hackers e utilizam
esta palavra como um termo respeitável.
Tipicamente, os hackers seguem uma espécie de ética do hacker, que dita que a missão por conhecimento e informação é essencial, e compartilhar este conhecimento é dever dos hackers para com a
comunidade. Durante esta missão por conhecimento, alguns hackers se divertem com desafios acadêmicos em furar controles de segurança em sistemas de computadores. Por esta razão, a imprensa
comumente usa o termo hacker para descrever aqueles que acessam sistemas e redes ilicitamente com
intenções inescrupulosas, maléficas ou criminosas. O termo mais correto para este tipo de hacker de
computador é cracker — um termo criado por hackers em meados dos anos 80 para diferenciar as
duas comunidades.
2.1.1. Tonalidades de Cinza
Há diversos grupos distintos de indivíduos que encontram e exploram vulnerabilidades em redes e
sistemas. Eles são descritos pela tonalidade do chapéu que "vestem" ao realizar suas investigações em
segurança, e essa tonalidade indica suas intenções.
O hacker de chapéu branco é aquele que testa redes e sistemas para examinar sua performance e
determinar o quão vulneráveis são às intrusões. Geralmente, hackers de chapéu branco violam seus
próprios sistemas ou sistemas de um cliente que o empregou especificamente para auditar a segurança.
Pesquisadores acadêmicos e consultores profissionais de segurança são dois exemplos de hackers de
chapéu branco.
Um hacker de chapéu preto é sinônimo de um cracker. Em geral, crackers são menos focados em
programação e no lado acadêmico de violar sistemas. Eles comumente confiam em programas de
cracking e exploram vulnerabilidades conhecidas em sistemas para descobrir informações importantes
para ganho pessoal ou para danificar a rede ou sistema alvo.
O hacker de chapéu cinza, por outro lado, tem as habilidades e intenções de um hacker de chapéu
branco na maioria dos casos, mas por vezes utiliza seu conhecimento para propósitos menos nobres.
Um hacker de chapéu cinza pode ser descrito como um hacker de chapéu branco que às vezes veste
um chapéu preto para cumprir sua própria agenda.
Hackers de chapéu cinza tipicamente se enquadram em outro tipo de ética, que diz ser aceitável violar
sistemas desde que o hacker não cometa roubo ou infrinja a confidencialidade. Alguns argumentam,
no entanto, que o ato de violar um sistema por si só já é anti-ético.
8
Capítulo 2. Atacantes e Vulnerabilidades
Independentemente da intenção do intruso, é importante saber das fraquezas que um cracker geralmente tentará explorar. O restante do capítulo foca nestas questões.
2.2. Ameaças à Segurança da Rede
Práticas ruins ao configurar os seguintes aspectos de uma rede podem aumentar os riscos de um ataque.
2.2.1. Arquiteturas Inseguras
Uma rede mal configurada é um ponto de entrada básico para usuários não autorizados. Deixar uma
rede local aberta baseada na confiança e vulnerável à Internet, altamente insegura, é o mesmo que
deixar uma porta entreaberta em uma vizinhança perigosa — talvez nada aconteça por um período,
mas eventualmente alguém explorará a oportunidade.
2.2.1.1. Redes de Transmissão
Administradores de sistemas frequentemente falham em preceber a importância do hardware de rede
em seus esquemas de segurança. Componentes de hardware simples como hubs e roteadores baseiamse no princípio da transmissão ou ’non-switched’, ou seja, sempre que um nódulo transmitir dados
através da rede para um nódulo receptor, o hub ou roteador envia uma transmissão dos pacotes de
dados até que o nódulo receptor receba e processe os dados. Este método é o mais vulnerável para
lidar com protocolo de resolução (arp) ou controle de acesso à mídia (media access control - MAC), e
lidar com spoofing de endereços de ambos - intrusos externos e usuários não autorizados em nódulos
locais.
2.2.1.2. Servidores Centralizados
Outra armadilha de rede em potencial é o uso da computação centralizada. Uma forma comum de
corte de gastos em muitas empresas é consolidar todos os serviços em apenas uma máquina poderosa.
Isto pode ser conveniente, pois é mais fácil de gerenciar e custa bem menos que configurações de
servidores múltiplos. No entanto, um servidor centralizado apresenta apenas um ponto único de falha
na rede. Se o servidor central for comprometido, pode danificar a rede ou inutilizá-la, um cenário
propício para a manipulação ou roubo de dados. Nestas situações um servidor central torna-se uma
porta aberta, permitindo acesso à toda rede.
2.3. Ameaças à Segurança do Servidor
A segurança do servidor é tão importante quanto a segurança da rede porque os servidores frequentemente armazenam grande parte das informações vitais de uma empresa. Se um servidor for comprometido, todo o seu conteúdo pode ficar disponível para o cracker roubar ou manipular como quiser.
As seções a seguir detalham algumas das principais questões.
2.3.1. Serviços Não Usados e Portas Abertas
Uma instalação completa do Red Hat 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 da
distribuição; preferem, ao invés disso, instalar os pacotes básicos, incluindo diversas aplicações para
servidor.
Uma ocorrência comum dentre administradores de sistemas é instalar o sistema operacional sem prestar atenção em quais pacotes realmente estão sendo instalados. Isto pode ser problemático, pois servi-
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 um
servidor ou estação de trabalho sem que o adminstrador perceba, o que pode causar tráfego indesejado no servidor, ou até mesmo uma via potencial para crackers ao sistema. Veja Capítulo 5 para
informações sobre fechar portas e desativar serviços não utilizados.
2.3.2. Serviços Não Consertados (unpatched)
A maioria das aplicações de servidor inclusas em uma instalação default são sólidas, partes de software
testadas exaustivamente. Sendo utilizadas em ambientes de produção por muitos anos, seus códigos
têm sido constantemente refinados e muitos dos erros (bugs) foram encontrados e consertados.
Entretanto, não existe software perfeito e sempre há espaço para mais aprimoramentos. Além disso,
softwares mais novos frequentemente não são rigorosamente testados como se esperaria, porque chegaram recentemente a ambientes de produção ou porque talvez não sejam tão populares quanto outros
softwares de servidor.
Desenvolvedores e administradores de sistemas frequentemente encontram erros exploráveis em aplicações de servidor e publicam a informação em sites de rastreamento de erros e relacionados a segurança, como a lista de discussão ’Bugtraq’ (http://www.securityfocus.com) ou o site do ’Computer
Emergency Response Team’ (CERT) - (http://www.cert.org). Apesar destes mecanismos serem maneiras efetivas de alertar a comunidade sobre vulnerabilidades de segurança, é responsabilidade dos
adminsitradores consertarem seus sistemas prontamente. Isto requer uma atenção especial pois os
crackers têm acesso aos mesmos serviços de rastreamento de vulnerabilidades e utilizarão as informações para violar sistemas não consertados sempre que puderem. Uma boa administração de sistemas
requer vigilância, constante rastreamento de erros e manutenção apropriada do sistema para assegurar
um ambiente computacional mais seguro.
Consulte o Capítulo 3 para mais informações sobre como manter um sistema atualizado.
2.3.3. Administração Desatenta
Administradores que não consertam seus sistemas apropriadamente são grandes ameaças à segurança
de servidores. De acordo com o ’System Administration Network and Security Institute’ (SANS), a causa fundamental da vulnerabilidade na segurança de computadores é "delegar pessoas não treinadas para manter a segurança e não prover nem treinamento nem tempo para que o trabalho seja executado." 1
Isto se aplica tanto para administradores inexperientes quanto para administradores super-confiantes
ou desmotivados.
Alguns administradores falham em consertar seus servidores e estações de trabalho, enquanto outros
falham em monitorar as mensagens de registro do kernel do sistema ou tráfego de rede. Outro erro
comum é deixar senhas ou chaves default de serviços inalteradas. Por exemplo: alguns bancos de
dados têm senhas de administração default porque seus desenvolvedores assumem que o adminstrador
de sistemas irá alterá-las imediatamente após a instalação. Se um administrador de banco de dados
deixar de alterar esta senha, mesmo um cracker inexperiente pode utilizar uma senha default conhecida
para obter privilégios administrativos ao banco de dados. Estes são apenas alguns dos exemplos de
como uma administração desatenta pode desencadear no comprometimento de servidores.
2.3.4. Serviços Essencialmente Inseguros
Até a empresa mais atenta pode ser vítima de vulnerabilidades se os serviços de rede forem essencialmente inseguros. Por exemplo, há muitos serviços desenvolvidos sob a suposição de que são utilizados
através de redes confiáveis, mas essa suposição deixa de ser verdadeira a partir do momento em que o
serviço for disponibilizado através da Internet — que por si só é essencialmente não confiável.
1.
Fonte: http://www.sans.org/newlook/resources/errors.html
10
Um tipo de serviço de rede inseguro são aqueles que requerem nomes de usuário e senha não criptografados para autenticação. Telnet e FTP são dois serviços deste tipo. Se um software de ’sniffing’
de pacotes está monitorando o tráfego entre o usuário remoto e um servidor deste tipo, os nomes de
usuário e senhas podem ser interceptadas facilmente.
Tais serviços tmbém podem ser facilmente enquadrados no que a indústria da segurança chama de ataque ’man-in-the-middle’. Neste tipo de ataque um cracker redireciona o tráfego de rede, enganando
um servidor de nomes crackeado na rede, apontando-o para sua máquina ao invés do servidor pretendido. Quando alguém abrir uma sessão remota para este servidor, a máquina do atacante age como
um condutor invisível, situado discretamente entre o serviço remoto e o crédulo usuário, capturando
informações. Desta maneira um cracker consegue obter senhas administrativas e dados sem que o
servidor ou o usuário perceba.
Outra categoria de serviços inseguros são sistemas de arquivos de rede e serviços de informação, como
NFS ou NIS, desenvolvidos explicitamente para uso em LANs, mas que, infelizmente, têm seu uso
extendido para WANs (para usuários remotos). O NFS não tem, por default, nenhuma autenticação
ou mecanismos de segurança configurados para prevenir um cracker de montar o compartilhamento
do NFS e acessar qualquer coisa contida nele. O NIS também tem informações vitais que devem
ser conhecidas por qualquer computador ou rede, incluindo senhas e permissões de arquivo, em um
banco de dados ACSII ou DBM (derivado do ASCII) somente-texto. Um cracker que obtém acesso
a este banco de dados poderá acessar qualquer conta de usuário de uma rede, inclusive a conta do
administrador.
Por default, a Red Hat desliga tais serviços. No entanto, como administradores frequentemente são
forçados a usá-los, é essencial configurá-los cuidadosamente. Consulte o Capítulo 5 para mais informações sobre como configurar serviços de maneira segura.
2.4. Ameaças à Segurança da Estação de Trabalho e PC Pessoal
Estações de trabalho e PCs pessoais podem não ser tão propensos a ataques quanto redes ou servidores, mas já que estes comumente contêm informações delicadas, tais como dados de cartões de crédito,
também são alvos de crackers de sistemas. Estações de trabalho também podem ser violadas sem o
conhecimento do usuário e utilizadas por atacantes como máquinas "escravas" em ataques coordenados. Por estas razões, saber das vulnerabilidades de uma estação de trabalho pode poupar os usuários
da dor de cabeça de reinstalar o sistema operacional, ou pior, de recuperar-se do roubo de dados.
2.4.1. Senhas Ruins
Senhas ruins são uma das maneiras mais fáceis para um atacante obter acesso a um sistema. Para saber
mais sobre como evitar armadilhas comuns ao criar uma senha, veja a Seção 4.3.
2.4.2. Aplicações Cliente Vulneráveis
Apesar de um administrador poder ter um servidor completamente seguro e consertado, isto não significa que usuários remotos estão seguros ao acessá-lo. Por exemplo, se o servidor oferece os serviços
Telnet e FTP através de uma rede pública, um atacante pode capturar os nomes de usuário e senhas
(somente-texto) ao longo da rede, e então usar as informações da conta para acessar a estação de
trabalho do usuário remoto.
Mesmo ao utilizar protocolos seguros, como o SSH, um usuário remoto pode estar vulnerável a determinados ataques se ele não mantiver suas aplicações cliente atualizadas. Por exemplo, clientes da
versão 1 do SSH são vulneráveis a um ataque ’X-forwarding’ de servidores SSH maléficos. Uma vez
conectado ao servidor, o atacante pode capturar discretamente quaisquer teclas pressionadas e cliques
de mouse efetuados pelo cliente através da rede. Este problema foi consertado na segunda versão do
11
protocolo SSH, mas depende do usuário monitorar aplicações com tais vulnerabilidades e atualizá-las
quando necessário.
Capítulo 4 aborda mais detalhadamente os passos que administradores e usuários domésticos devem
seguir para limitar a vulnerabilidade de estações de trabalho.
12
II. Configurando o Red Hat Enterprise Linux para
Segurança
Esta parte informa e instrui os administradores sobre as técnicas e ferramentas apropriadas a usar para
proteger estações de trabalho e servidores do Red Hat Enterprise Linux e recursos de rede. Também
aborda como criar conexões seguras, bloquear portas e serviços, e como implementar a filtragem ativa
para evitar a intrusão na rede.
Índice
3. Atualizações de Segurança ........................................................................................................... 15
4. Segurança da Estação de Trabalho ............................................................................................. 21
5. Segurança do Servidor ................................................................................................................. 39
6. Redes Privadas Virtuais (Virtual Private Networks)................................................................. 53
7. 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 limitar os riscos de segurança em potencial. Se o software é parte de um pacote de uma distribuição do
Red Hat Linux atualmente suportada, a Red Hat, Inc. está comprometida em lançar pacotes atualizados que consertem as vulnerabilidades assim que possível. Frequentemente, os comunicados de um
exploit de segurança são acompanhados de um conserto (ou código-fonte que conserte o problema).
Este conserto é então aplicado ao pacote do Red Hat Linux, testado pela equipe de controle de qualidade da Red Hat e lançado como uma atualização de errata. Entretanto, se o comunicado não inclui um
conserto, um desenvolvedor da Red Hat Linux trabalhará juntamente ao mantenedor do software para
consertar o problema. Após consertar o problema, o pacote é testado e lançado como uma atualização
de errata.
Se for lançada uma atualização de errata para um software utilizado em seu sistema, é altamente
recomendável que você atualize os pacotes afetados assim que possível, para mininmizar o tempo em
que seu sistema está potencialmente vulnerável.
3.1. Atualizando Pacotes
Ao atualizar o software de um sistema, é importante fazer o download da atualização de uma fonte confiável. Um atacante pode reconstruir facilmente um pacote com a mesma versão daquele que
supostamente resolverá o problema, mas com um exploit de segurança diferente no pacote, e depois
lançá-lo na Internet. Se isto acontecer, usar medidas de segurança, como checar os arquivos com o
RPM original, não detectará o exploit. Portanto, é muito importante que você apenas faça o download
de RPMs de fontes confiáveis, tais como Red Hat, Inc., e cheque a assinatura do pacote para verificar
sua integridade.
A Red Hat oferece duas maneiras de 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 Network
A Red Hat Network permite que você automatize a maior parte do processo de atualização. Ela determina quais pacotes são necessários para seu sistema, faz o download destes a partir de uma fonte
segura, verifica a assinatura RPM, para assegurar que os pacotes não foram corrompidos, e os atualiza.
A instalação do pacote pode ser feita imediatamente ou pode ser agendada durante um determinado
período de tempo.
A Red Hat Network requer um Perfil do Sistema para cada máquina a ser atualizada. O Perfil do
Sistema contém informações de hardware e software do sistema. Essa informação é mantida confidencialmente e não é distribuída para ninguém. É usada somente para determinar quais atualizações
de errata são aplicáveis para cada sistema. Sem o perfil, a Red Hat Network não pode determinar se
seu sistema precisa de atualizações. Quando uma errata de segurança (ou qualquer tipo de errata) é
lançada, a Red Hat Network envia um email com a descrição da errata assim como quais sistemas são
afetados por ela. Para aplicar a atualização, você pode usar o Agente de Atualizações Red Hat ou
agendar a atualização do pacote pelo site http://rhn.redhat.com.
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 sistema
Red 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 de
Referência da Red Hat Network (Red Hat Network Reference Guide) disponível em
http://www.redhat.com/docs/manuals/RHNetwork/ ou visite http://rhn.redhat.com.
Importante
Antes de instalar qualquer errata de segurança, certifique-se de ler todas as instruções especiais
contidas no relatório da errata e executá-las. Consulte a Seção 3.1.3 para instruções gerais sobre
como aplicar as alterações feitas por uma atualização de errata.
3.1.2. Usando o Site de Erratas da Red Hat
Quando relatórios de erratas de segurança são lançados, são publicados no site de Erratas da Red
Hat Linux http://www.redhat.com/apps/support/errata/. A partir desta página, selecione o produto e
versão de seu sistema e então selecione security no topo da página para exibir apenas os Relatórios
de Segurança da Red Hat Enterprise Linux. Se a sinopse de um dos relatórios descreve um pacote
usado em seu sistema, clique na sinopse para ver mais detalhes.
A página de detalhes descreve o exploit de segurança e quaisquer instruções especiais que devem ser
executadas para atualizar o pacote e consertar 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 no
disco rígido. É altamente recomendável que você crie um novo diretório como /tmp/atualizações
e 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.. O
utilitário RPM do Red Hat Enterprise Linux tenta automaticamente verificar a assinatura GPG de um
pacote RPM antes de instalá-lo. Se a chave GPG da Red Hat, Inc. não está instalada, instale-a a partir
de 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á-la
para 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 seguinte
comando:
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 comando anterior, conforme o exemplo:
rpm -qi gpg-pubkey-db42a60e-37ea5438
17
É extremamente importante verificar a assinatura dos arquivos RPM antes de instalá-los. Este passo
assegura que eles não foram alterados depois do lançamento dos pacotes pela Red Hat, Inc.. Para
verificar todos os pacotes do download de uma só vez, submeta o seguinte comando:
rpm -K /tmp/updates/*.rpm
Se a 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), submetendo
o 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 removido
usando o seguinte comando:
rpm -e
old-kernel-package
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 especiais
contidas no relatório da errata e executá-las. Consulte a Seção 3.1.3 para instruções gerais sobre
como aplicar as alterações feitas por uma atualização de errata.
3.1.3. Aplicando as Alterações
Após fazer o download e instalar as erratas de segurança através da Red Hat Network ou do site de
erratas da Red Hat, é importante parar de usar o software antigo e passar a usar o novo. O modo como
isso é feito depende do tipo de software que foi atualizado. A lista a seguir aponta as categorias gerais
de software e oferece instruções para usar as versões atualizadas após uma atualização de pacotes.
18
Nota
Em geral, reinicializar o sistema é a maneira mais certa de garantir que a versão mais recente de um
pacote de software é usada; entretanto, esta opção nem sempre está disponível ao administrador
de sistemas.
Aplicações
Aplicações em espaço de usuário (user-space) são quaisquer programas que podem ser iniciados
por um usuário do sistema. Geralmente, estas aplicações são usadas somente quando um usuário,
um script ou uma funcionalidade de tarefa automatizada as lança, e não persistem por longos
períodos.
Após uma aplicação em espaço de usuário ser atualizada, pare todas as instâncias da aplicação
no sistema e lance o programa novamente a fim de usar a versão atualizada.
Kernel
O kernel é o componente central do software do sistema operacional Red Hat Enterprise Linux.
Ele gerencia o acesso à memória, ao processador e periféricos e também agenda todas as tarefas.
Devido sua função central, o kernel não pode ser reiniciado sem também parar o computador.
Portanto, uma versão atualizada do kernel não pode ser usada até que o sistema seja reinicializado.
Bibliotecas Compartilhadas
Bibliotecas compartilhadas são unidades de código, como a glibc, que são usadas por diversas
aplicações e serviços. As aplicações que utilizam uma biblioteca compartilhada geralmente carregam o código compartilhado quando a aplicação é iniciada, portanto todas as aplicações que
usam a biblioteca compartilhada devem ser paradas e relançadas.
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 wrappers para controle de acesso à máquina. Portanto, quaisquer programas listados devem ser parados 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 pode
ser feito usando a Ferramenta de Configuração dos Serviços ou se autenticando a uma janela
de comandos root e submetendo o comando /sbin/service como no exemplo seguinte:
/sbin/service
service-name
restart
service-name
pelo nome do serviço, como sshd.
Consulte o capítulo intitulado Controlando Acesso aos Serviços no Guia de Administração do
Sistema do Red Hat Enterprise Linux para mais informações sobre a Ferramenta de Configuração dos Serviços.
19
Serviços xinetd
Os serviços controlados pelo super serviço xinetd rodam somente quando há uma conexão
ativa. Exemplos de serviços controlados pelo xinetd incluem Telnet, IMAP 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. No
entanto, se há conexões ativas no momento em que o serviço controlado xinetd é atualizado,
elas são feitas pela versão antiga do software.
Para eliminar instâncias antigas de um serviço controlado xinetd em particular, faça o upgrade
do pacote do serviço e então pare todos os processos sendo executados. Primeiro, determine se
o processo está rodando, usando o comando ps e então use o comando kill ou killall para
parar as instâncias atuais do serviço.
Por exemplo: se os pacotes da errata de segurança imap são lançados, faça o upgrade dos pacotes
e então digite o seguinte comando como root em uma janela de comandos:
ps -aux | grep imap
Este comando retorna todas as sessões IMAP ativas. As sessões individiuais podem então ser
terminadas com o seguinte comando:
kill -9
PID
No exemplo anterioor, substitua
são IMAP.
PID
pelo número de identificação do processo de uma ses-
Para terminar todas as sessões IMAP ativas, submeta o seguinte comando:
killall imapd
Consulte o capítulo intitulado TCP Wrappers e xinetd no Guia de Referência do Red Hat
Enterprise Linux para informações gerais sobre o xinetd.
20
Capítulo 4.
Segurança da Estação de Trabalho
Proteger um ambiente Linux começa pela estação de trabalho. Na proteção de sua máquina pessoal
ou sistema corporativo, uma boa política de segurança começa pelo computador individual. Afinal de
contas, uma rede de computadores é tão segura quanto seu nódulo mais vulnerável.
4.1. Avaliando a Segurança da Estação de Trabalho
Ao avaliar a segurança de uma estação de trabalho Red Hat Enterprise Linux, considere o seguinte:
•
Segurança do BIOS e Gestor de Início — Um usuário não autorizado pode acessar fisicamente a
máquina e inicializá-la como um usuário simples ou no modo de recuperação sem uma senha?
•
Segurança da Senha — Quão seguras são as senhas de conta de usuário na máquina?
•
Controles Administrativos — Quem tem uma conta no sistema e quanto controle admisnitrativo
eles têm?
•
Serviços Disponíveis na Rede — Quais serviços estão escutando por pedidos da rede? Eles realmente 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 usadas
para a comunicação entre estações de trabalho e quais devem ser evitadas?
4.2. Segurança do BIOS e do Gestor de Início
A proteção da senha para o BIOS (ou componente equivalente) e para o gestor de início pode impedir
usuários não autorizados, que tenham acesso físico aos seus sistemas, de inicializar a máquina com
mídia removível ou acessar root através do modo de usuário simples. Mas as medidas de segurança a
tomar para proteger o sistema de ataques deste tipo dependem da sensibilidade das informações que a
estação de trabalho armazena e da localização da máquina.
Por exemplo: se uma máquina é usada 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 chaves
SSH da rede corporativa for deixado nesta mesma feira sem a proteção de senhas, pode ocasionar uma
violação de segurança severa com consequências para a empresa inteira.
Por outro lado, se a estação de trabalho estiver localizada em um lugar onde somente pessoas 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 BIOS
Veja a seguir as duas razões principais para proteger o BIOS de um computador com senhas 1:
1. Impedindo Alterações na Configuração do BIOS — Se um intruso tem acesso ao BIOS, pode
configurá-lo para ser desligado a partir de um disquete ou CD-ROM. Isto possibilita que ele
entre em modo de recuperação ou de usuário simples, que por sua vez permite a ele semear
programas 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 processo
de inicialização da máquina com senha. Quando ativado, um atacante é forçado a inserir uma
senha antes do BIOS lançar o gestor de início.
Como os métodos para definir uma senha para o BIOS variam de acordo com o fabricante do computador, consulte o manual de seu computador para obter instruções específicas.
Se você esquecer a senha do BIOS, ela pode ser restaurada com jumpers na placa-mãe ou desligando
a bateria CMOS. Por esta razão, é aconselhável trancar o compartimento do computador, se possível.
Não obstante, consulte o manual do computador ou da placa-mãe antes de tentar este procedimento.
4.2.1.1. Protegendo Plataformas Não-x86
Outras arquiteturas usam programas diferentes para executar tarefas de nível baixo, parecidas àquelas
do BIOS em sistemas x86. Por exemplo: computadores baseados no Intel® Itanium™ usam a shell
EFI (Extensible Firmware Interface).
Para instruções sobre a proteção através de senha a programas parecidos com o BIOS em outras
arquiteturas, consulte as instruções do fabricante.
4.2.2. Senhas do gestor de Início
Veja a seguir as principais razões para proteger um gestor de início Linux com senha:
1. Impedindo Acesso ao Modo de Usuário Simples — Se um atacante puder iniciar em modo de
usuá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 de
início, um atacante pode usar a interface de edição do GRUB para alterar sua configuração ou
para coletar informações usando o comando cat.
3. Impedindo Acesso a Sistemas Operacionais Não-Seguros — Se for um sistema de boot duplo,
um atacante pode selecionar um sistema operacional na hora da inicialização, tal como o DOS,
que ignora controles de acesso e permissões de arquivo.
Há dois gestores de início distribuídos com o Red Hat Enterprise Linux para a plataforma x86, GRUB
e LILO. Para uma visão detalhada de cada um destes gestores de início, consulte o capítulo entitulado
Gestores 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 adicionando 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
Substitua
2.
password-hash
password-hash
pelo valor retornado pelo /sbin/grub-md5-crypt2.
O GRUB também aceita senhas não-criptografadas, mas é recomendado usar a versão md5 para segurança
adicional.
23
Na próxima vez que inicializar o sistema, o menu do GRUB não deixará você acessar o editor ou a
interface de comando sem que pressione [p] seguida da senha do GRUB.
Infelizmente, esta solução não impede que um atacante inicialize em um sistema operacional nãoseguro em um ambiente de boot duplo. Para isso, você precisa editar uma parte diferente do arquivo
/boot/grub/grub.conf.
Procure pela linha title do sistema operacional não-seguro e adicione uma linha contendo lock
logo abaixo dela.
Para um sistema DOS, a estrofe deve começar similarmente a:
title DOS
lock
Atenção
Você deve ter uma linha password na seção principal do arquivo /boot/grub/grub.conf para que
este método funcione apropriadamente. Caso contrário, um atacante poderá acessar a interface de
edição do GRUB e remover a linha lock.
Para criar uma senha diferente para um kernel ou sistema operacional específico, adicione uma linha
lock na estrofe, seguida de uma linha para senha.
Cada estrofe que você proteger com uma senha única deve começar com linhas similares ao exemplo
seguinte:
title DOS
lock
password --md5
password-hash
4.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. No
entanto, ainda há perigo de um atacante inicializar em modo de usuário simples ou iniciar em um
sistema operacional não-seguro.
A proteção de senha para o LILO pode ser feita adicionando uma diretiva de senha na seção global de
seu 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 para
que as alterações tenham efeito. Se você configurou uma senha e ninguém, a não ser root, pode
ler o arquivo, o LILO será instalado corretamente, mas o alertará que as permissões do arquivo de
configuração estão incorretas.
24
Se você não quer uma senha global, pode adicionar a diretiva de senha a qualquer estrofe correspondente a qualquer kernel ou sistema operacional. Para fazer isso, adicione a diretiva da senha logo
abaixo da linha image. Ao terminar, o início da estrofe protegida por senha se assemelhará a:
image=/boot/vmlinuz- version
password= password
LILO para este kernel.
version
pela versão do kernel e
password
pela senha do
É 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 a
diretiva restricted na linha abaixo da linha da senha, dentro da estrofe. Esta estrofe começa similar
a:
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 Senha
Senhas são o método principal usado pelo Red Hat Enterprise Linux para verificar a identidade de
usuários. É por isso que a segurança da senha é tão importante para a proteção do usuário, da estação
de trabalho e da rede.
Por motivos de segurança, o programa de instalação configura o sistema para usar o Algoritmo
Message-Digest (MD5) e senhas shadow. É altamente recomendável que você não altere estas
configurações.
Se você desselecionar as senhas MD5 durante a instalação, o antigo formato Padrão de Criptografia
de Dados (DES - Data Encryption Standard) é utilizado. Este formato limita as senhas a oito caracteres
alfa-numéricos (impedindo o uso de pontuação e outros caracteres especiais) e oferece um nível de
criptografia modesto 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 a
ataques de cracking offline. Se um intruso puder obter acesso a uma máquina como um usuário comum, ele pode copiar o arquivo /etc/passwd para sua própria máquina e rodar inúmeros programas
de cracking neste arquivo. Se houver uma senha desprotegida no arquivo, é apenas uma questão de
tempo para o cracker descobrí-la.
25
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 serviço de rede na máquina, como SSH ou FTP. Este tipo de ataque de força bruta é bem mais lento e
deixa rastros óbvios, já que centenas de tentativas de autenticação mal-sucedidas são registradas nos
arquivos do sistema. Claro que, se o cracker começar um ataque no meio da noite em um sistema com
senhas fracas, ele pode obter acesso e editar os arquivos de registro para apagar seus rastros antes da
luz do dia.
Além das questões de formato e armazenamento, há também a questão de conteúdo. A única coisa
mais importante que um usuário pode fazer para proteger sua conta de cracking de senha é criar uma
senha forte.
4.3.1. Criando Senhas Fortes
Ao criar uma senha segura, é uma boa idéia seguir estas instruções:
Não faça o seguinte:
•
Não Use Apenas Palavras ou Números — Nunca use somente palavras ou números em uma
senha.
Alguns exemplos de senhas inseguras:
•
•
8675309
•
juan
•
hackme
Não Use Palavras Reconhecíveis — Palavras como nomes próprios, palavras de dicionário ou
até termos de shows de televisão ou novelas devem ser evitados, mesmo que sejam finalizados
com números.
•
•
john1
•
DS-9
•
mentat123
Não Use Palavras em Idiomas Estrangeiros — Programas de cracking de senhas frequentemente checam listas de palavras que incluem dicionários de muitos idiomas. Basear senhas
seguras 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 terminologia de hacker — também chamada l337 (LEET) speak — em sua senha, repense. Muitas listas
de palavras incluem LEET speak.
26
•
•
H4X0R
•
1337
Não Use Informações Pessoais — Fique longe das informações pessoais. Se o atacante souber
quem você é, ele terá facilidade em descobrir sua senha. A seguir, veja uma lista de tipos de
informação a evitar na criação de uma senha:
•
•
Seu nome
•
O nome de animais de estimação
•
O nome de familiares
•
Quaisquer datas de aniversário
•
Seu número de telefone ou código postal
Não Inverta Palavras Reconhecíveis — Bons verificadores de senha sempre revertem palavras
comuns, portanto reverter uma senha ruim não a torna mais segura.
•
R0X4H
•
nauj
•
9-DS
•
Não Anote Sua Senha — Nunca guarde uma senha em um papel. É bem mais seguro
memorizá-la.
•
Não Use a Mesma Senha Para Todas as Máquinas — É importante criar senhas separadas para
cada máquina. Desta maneira, se um sistema for comprometido, todas as outras máquinas não
estarão em risco imediato.
Faça o seguinte:
•
Crie uma Senha de no Mínimo Oito Caracteres — Quanto mais longa a senha, melhor. Se você
estiver usando senhas MD5, deve ter 15 ou mais caracteres. Para senhas DES, use o tamanho
máximo (oito caracteres).
•
Misture Letras em Caixa Alta e Baixa — O Red Hat Enterprise Linux é sensível a maiúsculas
e minúsculas, portanto misture-as para criar uma senha mais forte.
•
Misture Letras e Números — Adicionar números a senhas, especialmente no meio delas (não
apenas no começo e fim), pode aumentar a força da senha.
•
Inclua Caracteres Não Alfa-numéricos — Caracteres especiais como &, $ e
tar bastante a força de uma senha (isto não é possível se usar senhas DES).
•
Escolha uma Senha que Você Possa Lembrar — A melhor senha do mundo de nada adianta se
você não conseguir lembrá-la. Então use acrônimos ou outros dispositivos mneumônicos para
ajudá-lo a memorizar senhas.
podem aumen-
27
Com todas estas regras, parece difícil criar uma senha que siga todos os critérios e evitar as características de um senha ruim. Felizmente, há alguns passos simples a seguir para gerar uma senha
memorizável e segura.
4.3.1.1. Metodologia de Criação de Senha Segura
Há muitos métodos usados para criar senhas seguras. Um dos mais conhecidos envolve acrônimos.
Por exemplo:
•
Pense em uma frase memorável, como:
•
Em seguida, transforme-a num acrônimo (incluindo a pontuação).
•
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 (@):
•
Adicione mais complexidade colocando pelo menos uma das letras em caixa alta, como F.
•
Finalmente, nunca use o exemplo acima em nenhum de seus sistemas.
"o sol da liberdade em raios fúlgidos brilhou no céu da pátria neste instante."
osdlerfbncdpni.
o7r@77w,7ghwg.
o7r@77w,7gHwg.
Criar senhas seguras é imperativo, mas gerenciá-las apropriadamente também é importante, especialmente para administradores de sistemas em empresas maiores. A próxima seção detalha as boas
prárticas para criar e gerenciar senhas de usuários em uma empresa.
4.3.2. Criando Senhas de Usuários Dentro de uma Empresa
Se houver um número significativo de usuários em uma empresa, os adminsitradores de sistemas têm
duas opções básicas para forçar o uso de boas senhas. Eles podem criar senhas para os usuários,
ou podem deixar que os usuários criem suas próprias senhas, enquanto verificam se as senhas têm
qualidade aceitável.
Criar senhas para os usuários garante que as senhas sejam boas, mas se torna uma tarefa complicada
conforme a empresa cresce. Também aumenta o risco dos usuários anotarem suas senhas.
Por estas razões, 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 trocarem
suas senhas periodicamente conforme sua idade.
4.3.2.1. Forçando Senhas Fortes
Para proteger a rede de intrusões é uma boa idéia administradores de sistema verificarem se as senhas
usadas na empresa são fortes. Quando for pedido aos usuários criarem ou alterarem senhas, eles
podem utilizar a aplicação de linha de comando passwd, que é ciente do Gerenciador Plugável de
Autenticação (Pluggable Authentication Manager - PAM) e então checará se a senha é fácil de crackear
ou 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ível
em http://www.openwall.com/passwdqc/) ou escrever um módulo novo. Para visualizar uma lista dos
módulos PAM disponíveis, veja http://www.kernel.org/pub/linux/libs/pam/modules.html. Para mais
informações sobre o PAM, veja o capítulo enitulado Módulos Plugáveis de Autenticação (PAM) no
Guia de Referência do Red Hat Enterprise Linux.
28
Perceba, no entanto, que a verificação executada nas senhas no momento de sua criação não descobre
senhas ruins tão efetivamente quanto rodar um programa de cracking de senhas nas senhas da empresa
inteira.
Há muitos programas de cracking de senhas que rodam no Red Hat Enterprise Linux, porém nenhum
é distribuído junto ao sistema operacional. Abaixo há uma breve lista de alguns dos programas de
cracking de senhas mais conhecidos:
Nota
Nenhuma destas ferramentas é distribuída com o Red Hat Enterprise Linux, portanto não são suportadas pela Red Hat, Inc. de maneira alguma.
•
John The Ripper — Um programa de cracking rápido e flexível. Permite o uso de listas de
palavras múltiplas e é capaz de crackear senhas com força bruta. Está disponível online em
http://www.openwall.com/john/.
•
Crack — Talvez o programa de cracking mais conhecido, o Crack também é muito rápido,
porém não tão fácil de usar quanto o John The Ripper. Pode ser encontrado online:
http://www.crypticide.org/users/alecm/.
•
Slurpie — O Slurpie é similar ao John The Ripper e ao Crack, mas é desenvolvido para rodar
em 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 contras
ataques 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 empresa
contra senhas ruins. Idade da senha significa que depois de um determinado tempo (geralmente 90
dias) é solicitado ao usuário criar uma nova senha. A teoria por trás disso é se o usuário é forçado a
trocar sua senha periodicamente, uma senha crackeada por um intruso será útil somente por um tempo
limitado. A desvantagem desta técnica, no entanto, é que usuários tendem a anotar suas senhas.
Há dois programas principais usados para especificar a idade da senha sob o Red Hat Enterprise Linux:
o comando chage ou a aplicação gráfica Administrador de Usuários (redhat-config-users).
A opção -M do comando chage especifica o número máximo de dias em que a senha é válida. Portanto, se um usuário quer que sua senha expire em 90 dias, deve digitar o seguinte comando:
chage -M 90
username
No comando acima, substitua username pelo nome do usuário. Para desabilitar a expiração da
senha, é comum usar o valor 99999 depois da opção -M (isso equivale a um pouco mais de 273 anos).
A aplicação gráfica Administrador de Usuários também pode ser uasada para criar políticas de
validade de senhas. Para acessar esta aplicação, vá para o Botão do Menu Principal (no Painel) =>
29
Configurações do Sistema => Usuários & Grupos ou digite o comando redhat-config-users
em uma janela de comandos (em um XTerm ou um terminal GNOME, por exemplo). Clique na aba
Usuários, selecione o usuário da lista e clique em Propriedades no botão do menu (ou selecione
Arquivo => Propriedades no menu suspenso).
Então clique na aba Informações de Senha e insira o número de dias antes da senha expirar, conforme
mostra a figura Figura 4-1.
Figura 4-1. Aba Informações de Senha
Para mais informaçõe sobre a configuração do usuário e grupo (inclusive instruções sobre como forçar
as primeiras senhas), veja o capítulo Configuração de Usuário e Grupo do Guia de Administração do
Sistema 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 Accounts
and Resource Access) no Introdução à Administração de Sistemas Red Hat Enterprise Linux.
4.4. Controles Administrativos
Ao adminsitrar um computador caseiro, o usuário deve executar algumas tarefas como usuário root
ou adquirindo privilégios efetivos de root através de um programa setuid, como o sudo ou o su.
Um programa setuid opera com o ID do usuário (UID) do proprietário do programa ao invés do
usuário operando o programa. Tais programas são caracterizados por um s em caixa baixa na seção
do proprietário de uma lista longa, conforme o exemplo a seguir:
-rwsr-xr-x
1 root
root
47324 May
1 08:09 /bin/su
Para os adminsitradores de sistema de uma empresa, no entanto, as escolhas devem ser feitas de acordo com o nível de acesso adminsitrativo que os usuários, dentro da organização, devem ter em suas
máquinas. Através de um módulo PAM chamado pam_console.so, algumas atividades reservadas
somente ao usuário root, como reinicializar e montar mídia removível, são permitidas ao primeiro
usuário que se autenticar no console físico (veja o capítulo entitulado Módulos Plugáveis de Autenticação (PAM) do Guia de Referência do Red Hat Enterprise Linux para saber mais sobre o módulo
pam_console.so). Entretanto, outras tarefas importantes da administração de sistemas, como alterar configurações da rede ou do mouse, ou montar dispositivos de rede, são impossíveis sem o acesso
30
administrativo. Consequentemente, os administradores devem decidir o grau de acesso administrativo
que os ususários de sua rede devem ter.
4.4.1. Permitindo Acesso Root
Se os usuários de uma empresa são um grupo confiável e experiente em computadores, permití-los
acesso root talvez não seja 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 individuais, deixando os adminsitradores de sistema livres para lidar com a segurança da rede e outras
questões importantes.
Por outro lado, permitir acesso root a usuários individuais pode acarretar nas questões a seguir (para
nomear apenas algumas):
•
Má Configuração da Máquina — Usuários com acesso root podem mal-configurar suas máquinas
e pedir assistência ou pior, abrir buracos na segurança sem saber.
•
Rodar Serviços Inseguros — Usuários com acesso root podem rodar serviços inseguros, como FTP
ou Telnet, em suas máquinas, potencialmente arriscando nomes de usuários e senhas conforme
trafegam sem criptografia pela rede.
•
Anexando Arquivos em Emails como Root — Apesar de raros, existem vírus de e-mail que afetam
o Linux. A única hora em que eles representam uma ameaça, no entanto, é quando são executados
pelo usuário root.
4.4.2. Impedindo Acesso Root
Se o adminsitrador não estiver confortável em permitir que usuários se autentiquem como root por
estas ou por outras razões, a senha de root deve ser guardada secretamente, e o acesso ao nível de
execução um ou ao modo de usuário simples deve ser impedido através da proteção de senha do
gestor 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
Alterar a Edite o arquivo
shell root. /etc/passwd e altere a
shell de /bin/bash para
/sbin/nologin.
Efeitos
Não Afeta
Impede acesso à shell root
e registra a tentativa.
Os seguintes programas
são impedidos de acessar
a conta root:
Programas que não
requerem uma shell, como
clientes FTP, clientes de
mail e muitos programas
setuid.
não são impedidos de
acessar a conta root:
!!
!!
!!
!!
login
gdm
kdm
xdm
su
ssh
scp
sftp
!
!!
sudo
clientes FTP
clientes de Email
31
Método
Descrição
Efeitos
Não Afeta
Desativar
acesso
root
através de
qualquer
dispositivo de
console
(tty).
Um arquivo
Impede o acesso à conta
root através do console ou
rede. Os seguintes
programas são impedidos
de acessar a conta root:
Programas que não se
logam como root, mas
executam tarefas
administrativas através de
mecanismos setuid ou
outros.
não são impedidops de
acessar a conta root:
/etc/securetty vazio
impede a autenticação de
root a quaisquer
dispositivos atachados ao
computador.
""
""
login
gdm
kdm
xdm
"
Outros serviços de rede
que abrem uma tty
"
Desativar
autenticações
root SSH.
Edite o arquivo
Impede o acesso root
através do conjunto de
ferramentas OpenSSH. Os
programas a seguir são
impedidos de acessar a
conta root:
/etc/ssh/sshd_config
e defina o parâmetro
PermitRootLogin para
no.
""
Edite o arquivo para o
serviço em questão no
diretório /etc/pam.d/.
Assegure que
pam_listfile.so é
necessário para a
autenticação. Veja a Seção
4.4.2.4 para detalhes.
su
sudo
ssh
scp
sftp
Isto impede somente o
acesso root ao conjunto de
ferramentas do OpenSSH.
ssh
scp
sftp
"
Utilizar o
PAM
para
limitar o
acesso
root aos
serviços.
""
""
Impede o acesso root para
serviços de rede
notificados pelo PAM.
Os seguintes serviços são
impedidos de acessar a
conta root:
clientes FTP
clientes de Email
""
""
""
""
""
Programas e serviços que
não são notificados pelo
PAM.
login
gdm
kdm
xdm
ssh
scp
sftp
Quaisquer serviços
notificados pelo PAM
Tabela 4-1. Métodos para Desativar a Conta Root
4.4.2.1. Desativar a Shell Root
Para impedir os usuários de se autenticar diretamente como root, o administrador de sistema pode
configurar a shell da conta root para /sbin/nologin no arquivo /etc/passwd. Isto impede o acesso
à conta root através de comandos que requerem uma shell, como os comandos su e ssh.
Importante
Programas que não requerem acesso à shell, como clientes de email ou o comando sudo, ainda
podem acessar a conta root.
32
4.4.2.2. Impossibilitando Autenticações Root
Para limitar acesso à conta root, administradores podem desativar autenticações root no console editando o arquivo /etc/securetty. Este arquivo lista todos os dispositivos nos quais o usuário root
pode se autenticar. Se o arquivo não existir, o usuário root pode se autenticar através de qualquer
dispositivo de comunicação no sistema, através do console ou de uma interface de rede bruta. Isto é
perigoso pois um usuário pode acessar o Telnet em sua máquina como root, enviando sua senha em
formato texto através da rede. Por default, o arquivo /etc/securetty do Red Hat Enterprise Linux
permite somente ao usuário root se autenticar no console fisicamente anexo à máquina. Para impedir
que 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 remotamente
usando o conjunto de ferramentas OpenSSH porque o console não é aberto antes da autenticação.
4.4.2.3. Impossibilitando Autenticações Root SSH
Para impedir autenticações do root através do protocolo SSH, edite o arquivo de configuração do
daemon SSH (/etc/ssh/sshd_config). Altere a linha que apresenta:
# PermitRootLogin yes
para o seguinte:
PermitRootLogin no
4.4.2.4. Impossibilitar Root de Usar PAM
O PAM, através do módulo /lib/security/pam_listfile.so, permite grande flexibilidade em
negar contas específicas. Isto permite que o administrador aponte o módulo para uma lista de usuários
que não são permitidos de autenticar. O exemplo abaixo mostra como o módulo é usado para o servidor
FTP vsftpd no arquivo de configuração do PAM /etc/pam.d/vsftpd (o caracter \ no final da
primeira linha no exemplo a seguir não é necessário se a diretiva estiver em apenas uma linha):
auth
required
/lib/security/pam_listfile.so
item=user \
sense=deny file=/etc/vsftpd.ftpusers onerr=succeed
Isto diz ao PAM para consultar o arquivo /etc/vsftpd.ftpusers e negar a qualquer usuário listado
acessar o serviço. O adminsitrador é livre para alterar o nome deste arquivo e pode guardar listas
separadas para cada serviço ou usar uma lista geral para negar acesso a múltiplos serviços.
Se o adminsitrador quer negar acesso a múltiplos serviços, uma linha similar pode ser adicionada aos
serviços de configuração do PAM, como /etc/pam.d/pop e /etc/pam.d/imap para clientes de
mail ou /etc/pam.d/ssh para clientes SSH.
33
Para mais informações sobre o PAM, veja o capítulo Módulos Plugáveis de Autenticação (PAM) no
Guia de Referência do Red Hat Enterprise Linux.
4.4.3. Limitar Acesso Root
Ao invés de negar completamante acesso ao usuário root, o administrador pode permitir acesso apenas
através de programas setuid, como o su ou o sudo.
4.4.3.1. O Comando su
Ao digitar o comando su, é pedida a senha root ao usuário e, após a autenticação, é dada uma janela
de comandos.
Uma vez autenticado através do comando su, o usuário é o usuário root e tem acesso administrativo
absoluto ao sistema. Além disso, uma vez que o usuário obteve aceeso root, é possível que ele use o
comando su para alterar qualquer outro usuário no sistema sem precisar inserir uma senha.
Como este programa é tão poderoso, administradores dentro de uma empresa talvez queiram limitar
quem tem acesso ao comando.
Uma das maneiras mais simples de fazer isso é adicionar usuários ao grupo administrativo especial
chamado wheel. Para fazer isso, digite o seguinte comando como root:
usermod -G wheel
#
username
No comando anterior, substitua
wheel.
$
%
username
&
pelo nome do usuário sendo adicionado ao grupo
Para usar a Administrador de Usuários para este propósito, vá ao Botão do Menu Principal (no Painel) => Configurações do Sistema => Grupos & Usuários ou digite o comando redhat-configusers em uma janela de comandos. Selecione a aba Users, selecione o usuário e clique em Propriedades a partir do menu do botão (ou selecione Arquivo => Propriedades a partir do menu suspenso).
Então selecione a aba Grupos e clique no grupo wheel, conforme mostra Figura 4-2.
Figura 4-2. Aba Grupos
34
Em seguida, abra o arquivo de configuração do PAM para su (/etc/pam.d/su) em um editor de
texto e remova o comentário [#] da seguinte linha:
auth
required /lib/security/pam_wheel.so use_uid
Fazer isso permitirá que somente membros do grupo administrativo wheel usem o programa.
Nota
O usuário root é parte do grupo wheel por default.
4.4.3.2. O Comando sudo
O comando sudo oferece uma outra maneira de dar acesso administrativo a usuários. Quando um
usuário confiável precede um comando administrativo com sudo, ele precisa inserir sua senha. Então,
uma vez autenticado e assumindo que o comando é permitido, o comando administrativo é executado
como se fosse pelo usuário root.
O formato básico do comando sudo é o seguinte:
sudo
'
command
(
)
*
No exemplo acima, command será substituído por um comando normalmente reservado para o
usuário root, como o comando mount.
Importante
Usuários do comando sudo devem tomar cuidado extra para fazer logout antes de deixarem suas
máquinas, já que eles podem usar o comando novamente, sem precisar indicar a senha, por um
período de cinco minutos. Esta configuração pode ser alterada através do arquivo de configuração
/etc/sudoers.
O comando sudo permite um grau de flexibilidade maior. Por exemplo: somente os usuários listados
no arquivo de configuração /etc/sudoers são permitidos a usar o comando sudo e o comando é
executado na shell do usuário, não numa shell root. Isto significa que a shell root pode ser completamente 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 autenticação bem-sucedida é registrada no arquivo /var/log/messages e o comando submetido junto ao
nome do usuário é registrado no arquivo /var/log/secure.
Outra vantagem do comando sudo é que um administrador pode permitir a diferentes usuários acesso
a comandos específicos baseado em suas necessidades.
Adminsitradores que queiram editar o arquivo de configuração do sudo, o /etc/sudoers, devem
usar o comando visudo.
Para dar privilégios administrativos totais a alguém, digite visudo e adicione uma linha similar à
seguinte na seção de especificação de privilégios do usuário:
juan ALL=(ALL) ALL
Este exemplo estabelece que o usuário juan pode usar o sudo em qualquer máquina e executar
qualquer comando.
35
O exemplo abaixo ilustra a granularidade possível ao configurar o sudo:
%users
localhost=/sbin/shutdown -h now
Este exemplo estabelece que qualquer usuário pode submeter o comando /sbin/shutdown -h now
desde que o faça pelo console.
A página man de sudoers tem uma lista detalhada das opções para este arquivo.
4.5. Serviços de Rede Disponíveis
Enquanto o acessso a controles administrativos é uma questão importante para administradores de
sistema dentro de uma empresa, manter controle de quais serviços de rede estão ativos é de suma
importâ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 como
uma via potencial de ataque.
4.5.1. Riscos aos Serviços
Serviços de rede podem apresentar muitos riscos a sistemas Linux. Veja abaixo uma lista com as
principais questões:
•
Ataques de Sobrecarregamento do Buffer (Buffer Overflow) — Serviços que se conectam a portas
numeradas de 0 a 1023 devem ser executados por um usuário administrativo. Se a aplicação tiver um
sobrecarregamento explorável do buffer, um atacante pode obter acesso ao sistema como o usuário
rodando o daemon. Devido à existência de sobrecarregamento explorável do buffer, os crackers
usam ferramentas automatizadas para identificar sistemas com vulnerabilidades, e após obterem
acesso ao sistema, utilizam rootkits automatizados para mantê-lo.
•
Ataques de Denial of Service (DoS) — Ao inundar um serviço com pedidos, um ataque de denial
of service pode trazer ao sistema uma parada terrível ao tentar registrar e responder à cada pedido.
•
Ataques à Vulnerabilidade do Script — Se um servidor estiver usando scripts para executar ações
no lado do servidor, como servidores Web geralmente fazem, um cracker pode montar um ataque
com scripts escritos inapropriadamente. Estes ataques à vulnerabilidade do script podem acarretar
na condição de 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 desligados.
4.5.2. Identificando e Configurando Serviços
Para aumentar a segurança, a maioria dos serviços instalados com o Red Hat Enterprise Linux são
desligados por default. No entanto, há algumas exceções notáveis:
• cupsd
• lpd
— O servidor de impressão default do Red Hat Enterprise Linux.
— Um servidor de impressão alternativo.
• portmap
— Um componente necessário para o NFS, NIS e outros protocolos.
— Um super servidor que controla as conexões para uma máquina de servidores subordinados, como vsftpd, telnet e sgi-fam (necessário para o gerenciador de arquivos Nautilus).
• xinetd
36
— O agente de transporte Sendmail é ativado por default, mas escuta apenas conexões
a partir do localhost.
• sendmail
• 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 pecar
pela precaução. Por exemplo: se uma impressora não está disponível, não deixe o cupsd rodando. O
mesmo vale para o portmap. Se você não monta volumes 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 serviços. Eles são: Ferramenta de Configuração dos Serviços (redhat-config-services), ntsysv
e chkconfig. Para informações sobre o uso destas ferramentas, consulte o capítulo Controlando
Acesso 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ção
dos Serviços tem um campo de descrição, ilustrado na Figura 4-3, que pode lhe ser útil.
Mas verificar quais serviços de rede estão disponíveis para iniciar no momento de ligar a máquina
(boot) não é suficiente. Bons administradores de sistema também devem verificar quais portas estão
abertas e escutando. Veja a Seção 5.8 para mais detalhes sobre o assunto.
4.5.3. Serviços Inseguros
Potencialmente, qualquer rede é insegura. Por este motivo, desligar serviços não usados é tão importante. Exploits de serviços são revelados e consertados rotineiramente. Portanto é importante manter
atualizados os pacotes associados a qualquer serviço de rede. Veja o Capítulo 3 para mais detalhes
sobre este assunto.
Alguns protocolos de rede são essencialmente mais inseguros que outros. Estes incluem quaisquer
serviços que façam o seguinte:
•
Passem Nomes de Usuário e Senha Não Criptografados por uma Rede — Muitos protocolos antigos, como Telnet e FTP, não criptografam a seção de autenticação e devem ser evitados sempre que
possível.
•
37
Passar Dados Importantes por uma Rede Não-Criptografada — Muitos protocolos passam dados
através da rede não-criptografada. Estes protocolos incluem o Telnet, FTP, HTTP e o SMTP. Muitos
sistemas de arquivo de rede, como o NFS e o SMB, também passam informações através da rede
não-criptografada. É responsabilidade do usuário limitar o tipo de dados transmitidos ao utilizar
estes protocolos.
Serviços dump de memória remota, como o netdump, passam o conteúdo da memória não criptografado através da rede. Dumps de memória podem conter senhas ou pior, informações de banco
de dados ou outras informações delicadas.
Outros serviços como finger e rwhod revelam informações sobre os usuários do sistema.
Exemplos de serviços essencialmente inseguros incluem os seguintes:
• rlogin
• rsh
• 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 evitar
problemas. 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 seguintes:
• 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 Pessoais
Uma vez configurados os serviços de rede necessários, é importante implementar um firewall.
Firewalls evitam que pacotes de rede acessem a interface de rede do sistema. Se for feito um pedido a
uma porta sendo bloqueada pelo firewall, este será ignorado. Se o serviço estiver escutando em uma
38
destas portas bloqueadas, não receberá os pacotes e será efetivamente desabilitado. Por este motivo,
tome cuidado ao configurar um firewall para bloquear acesso a portas não usadas, para não bloquear
acesso a portas usadas por serviços configurados.
Para a maioria dos usuários, a melhor ferramenta para configurar um firewall simples é a ferramenta
de configuração gráfica distribuída com o Red Hat Enterprise Linux: a Ferramenta de Configuração
do Nível de Segurança (redhat-config-securitylevel). Esta ferramenta cria regras iptables
abrangentes para um firewall com propósitos genéricos usando uma interface de painel de controle.
Para mais informações sobre o uso desta aplicação e quais opções ela oferece, consulte o capítulo entitulado Configuração Básica do Firewall no Guia de Administração do Sistema do Red Hat Enterprise
Linux.
Para usuários avançados e administradores de servidores, configurar manualmente um firewall com
iptables é provavelmente a melhor opção. Consulte o Capítulo 7 para mais informações. Para acessar um guia compreensivo sobre o comando iptables, consulte o capítulo iptables no Guia de
Referência do Red Hat Enterprise Linux.
4.7. Ferramentas de Comunicação de Segurança Melhorada
Na mesma proporção em que o tamanho e a popularidade da Internet tem crescido, cresceu também
a ameaça da intercepção de comunicações. Através do anos, ferramentas foram desenvolvidas para
criptografar comunicações ao longo de sua transferência pela rede.
O Red Hat Enterprise Linux é distribuído com duas ferramentas básicas que usam algoritmos de alto
nível e baseados em criptografia de chave pública para proteger as informações conforme trafegam
pela rede.
•
OpenSSH — Uma implementação livre do protocolo SSH para criptografar comunicações de rede.
•
Gnu Privacy Guard (GPG) — Uma implementação livre da aplicação de criptografia PGP (Pretty
Good Privacy) para criptografar dados.
OpenSSh é uma maneira mais segura de acessar uma máquina remota e substitui serviços não criptografados como telnet e rsh. OpenSSH inclui um serviço de rede, chamado sshd, e três aplicações
cliente de linha de comandos:
• ssh
— Um cliente de acesso seguro ao console remoto.
• scp
— Um comando seguro de cópia remota.
• sftp
— Um cliente pseudo-ftp seguro que permite seções interativas de transferência de arquivo.
É altamente recomendado que qualquer comunicação remota com sistemas Linux ocorra usando o
protocolo SSH. Para mais informaçõe sobre o OpenSSH, veja o capítulo OpenSSH do Guia de Administraçã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 evitar
ameaç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 enviar
email 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 Gnu
Privacy 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. Por
esta razão solidificar e trancar os serviços é de suma importância para o administrador de sistemas.
Antes de aprofundar em questões específicas, você deve revisar as seguintes dicas gerais para aumentar
a segurança do servidor:
•
Mantenha todos os serviços atualizados para protegê-los contra as ameaças recentes.
•
Use protocolos seguros sempre que possível.
•
Ofereça apenas um tipo de serviço de rede por máquina sempre que possível.
•
Monitore todos os servidores cuidadosamente e atente para atividades suspeitas.
5.1. Protegendo Serviços com TCP Wrappers e xinetd
TCP wrappers oferecem controle de acesso a vários serviços. A maioria dos serviços de rede modernos, como SSH, Telnet e FTP, fazem uso dos TCP wrappers, que fica de guarda entre a entrada de um
pedido e o serviço requisitado.
Os benefícios oferecidos pelos TCP wrappers aumentam quando este é usado junto ao xinetd, um
super serviço que oferece acesso adicional, registro, vinculação, redirecionamento e controle de utilização de recursos.
Dica
É uma boa idéia usar regras de firewall do IPTables juntamente ao TCP wrappers e xinetd para
criar redundância nos controles de acesso do serviço. Consulte o Capítulo 7para mais informações
sobre a implementação de firewalls com comandos do IPTables.
Mais informações sobre a configuração do TCP wrappers e xinetd podem ser encontradas no capítulo 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 de
segurança específicas.
5.1.1. Aumentando a Segurança com TCP Wrappers
TCP wrappers são capazes de muito mais que negar acesso aos serviços. Esta seção ilustra como
eles podem ser utilizados para enviar banners de conexão, alertar ataques em máquinas específicas e
aumentar a funcionalidade de registro. Consulte a página man hosts_options para obter uma lista
completa das funcionalidades e controle de idioma do TCP wrapper.
5.1.1.1. TCP Wrappers e Banners de Conexão
Enviar um banner intimidador para clientes conectando a um serviço é uma boa maneira de disfarçar
em qual sistema o servidor está rodando enquanto informa um atacante potencial que o administrador
de sistemas está vigiando. Para implementar um banner do TCP wrappers para um serviço, use a
opção banner.
40
Capítulo 5. Segurança do Servidor
Este exemplo implementa um banner para vsftpd. Para começar, crie um arquivo de banner. Pode
estar em qualquer lugar do sistema, mas deve levar o mesmo nome que o daemon. Neste exemplo, o
arquivo é chamado /etc/banners/vsftpd.
O conteúdo do arquivo é parecido com o seguinte:
220-Hello, %c
220-All activity on ftp.example.com is logged.
220-Act up and you will be banned.
A expressão %c oferece uma gama de informações do cliente, tais como nome de usuário e nome da
máquina ou nome de usuário e endereço IP, para intimar ainda mais a conexão. O Guia de Referência
do Red Hat Enterprise Linux tem uma lista de outras expressões disponíveis para TCP wrappers.
Para que este banner seja apresentado em futuras conexões, adicione a seguinte linha ao arquivo
/etc/hosts.allow:
vsftpd : ALL : banners /etc/banners/
5.1.1.2. TCP Wrappers e Alertas de Ataque
Se uma determinada máquina ou rede for flagrada atacando o servidor, o TCP wrappers pode ser usado
para alertar o administrador sobre ataques subsequentes desta máquina ou rede através da diretiva
spawn.
Neste exemplo, assuma que um cracker da rede 206.182.68.0/24 foi pêgo tentando atacar o servidor. Ao inserir a seguinte linha no arquivo /etc/hosts.deny, a tentativa de conexão é negada e
registrada em um arquivo especial:
ALL : 206.182.68.0 : spawn /bin/ ’date’ %c %d >> /var/log/intruder_alert
A expressão %d traz o nome do serviço que o atacante estava tentando acessar.
Para permitir a conexão e registrá-la, insira o informativo spawn no arquivo /etc/hosts.allow.
Nota
Já que a diretiva spawn executa qualquer comando de linha, crie um script especial para notificar o
administrador ou para executar uma série de comandos na ocasião em que um determinado cliente
tenta conectar ao servidor.
5.1.1.3. TCP Wrappers e Registro Melhorado
Se determinados tipos de conexões são mais preocupantes que outras, o nível de registro pode ser
elevado para estes serviços através da opção severity.
Neste exemplo, assuma que qualquer um tentando conectar à porta 23 (a porta do Telnet) em um
servidor FTP é um cracker. Para denotar isso, insira um sinal emerg nos arquivos de registro ao invés
do sinal default, info, e negue a conexão.
Para fazer isso, insira a seguinte linha no arquivo /etc/hosts.deny:
in.telnetd : ALL : severity emerg
41
Isto usa a facilidade de registro authpriv default, mas eleva a prioridade do valor default do info
para 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 subordinados. Esta seção foca em como o xinetd pode ser usado para montar um serviço-armadilha e
controlar a quantidade de recursos que qualquer serviço xinetd pode usar para arruinar ataques ’denial of service’. Para obter uma lista mais completa das opções disponíveis, consulte as páginas man
do xinetd e do xinetd.conf.
5.1.2.1. Montando uma Armadilha
Uma importante característica do xinetd é sua habilidade em adicionar máquinas (hosts) a uma
lista de no_access. Às máquinas desta lista são negadas as conexões subsequentes aos serviços
gerenciados pelo xinetd por um determinado período ou até o xinetd ser reiniciado. Isto é feito
usando o atributo SENSOR. Esta técnica e uma maneira fácil de bloquear máquinas que tentarem
scanear o servidor.
O primeiro passo para definir um SENSOR é escolher um serviço que você não planeja utilizar. Neste
exemplo, usamos o Telnet.
Edite o arquivo /etc/xinetd.d/telnet e altere a linha flags para:
flags
= SENSOR
Adicione as seguintes linhas entre os colchetes:
deny_time
= 30
Isto nega a máquina que tentou conectar à porta por 30 minutos. Outros valores aceitáveis para o
atributo deny_time são FOREVER (sempre), que mantém o banimento efetivo até que o xinetd
seja reiniciado, e NEVER (nunca), que permite a conexão e a registra.
Finalmente, 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 recursos
que os serviços sob seu controle podem utilizar.
Ele o faz através das seguintes diretivas:
+
,-+
,
number_of_connections
wait_period — Determina as conexões permitidas
ao serviço por segundo. Esta diretiva aceita apenas valores inteiros.
• cps =
42
.
/
number_of_connections Determina o número total de conexões permitidas
a um serviço. Esta diretiva aceita tanto um valor inteiro como UNLIMITED.
• instances =
.
/
number_of_connections — Determina as conexões permitidas a um
serviço por cada máquina. Esta diretiva aceita tanto um valor inteiro como UNLIMITED.
• per_source =
.
/
number[K|M] — Determina a quantidade de memory address space que o
serviço pode ocupar em kilobytes ou megabytes. Esta diretiva aceita tanto um valor inteiro como
UNLIMITED.
• rlimit_as =
.
/
number_of_seconds — Determina o tempo em segundos durante o qual
um serviço pode ocupar a CPU. Esta diretiva aceita tanto um valor inteiro como UNLIMITED.
• rlimit_cpu =
Usando estas diretivas pode ajudar a prevenir que qualquer serviço xinetd sobrecarregue o sistema,
resultando em recusa de serviço (denial of service).
5.2. Protegendo o Portmap
O serviço portmap é um daemon de porta dinâmica para serviços RPS, como o NIS e o NFS. Tem
mecanismos de autenticação fracos e tem habilidade para delegar uma enorme gama de portas para os
serviços que controla. Por estas razões, é difcícil de proteger.
Se você está rodando serviços RPC, siga estas regras básicas.
5.2.1. Proteja o portmap com TCP Wrappers
É importante usar o TCP wrappers para limitar quais redes ou máquinas têm acesso ao serviço portmap já que este não 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 de
máquinas (hostnames), já que eles podem ser forjados através do ’poisoning’ do DNS e outros métodos.
5.2.2. Proteja o portmap Com IPTables
Para restringir acesso ao serviço portmap futuramente, é uma boa idéia adicionar regras do IPTables
ao servidor, 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 o
serviço sgi_fam usado pelo Nautilus). Todos os outros pacotes são derrubados.
iptables -A INPUT -p tcp -s! 192.168.0.0/24 --dport 111 -j DROP
iptables -A INPUT -p tcp -s 127.0.0.1 --dport 111 -j ACCEPT
Para limitar o tráfego UDP similarmente, use o seguinte comando.
iptables -A INPUT -p udp -s! 192.168.0.0/24
--dport 111 -j DROP
Dica
Consulte o Capítulo 7 para mais informações sobre a implementação de firewalls com comandos do
IPTables.
43
5.3. Protegendo o NIS
NIS significa Serviço de Informações de Rede (Network Information Service). É um serviço RPC chamado ypserv que é usado em conjunto com o portmap e outros serviços relacionados, para distribuir
mapas de nomes de usuário, senhas e outras informações importantes para qualquer computador que
queira estar em seu domínio.
Um servidor NIS é composto de diversas aplicações. Elas incluem as seguintes:
• /usr/sbin/rpc.yppasswdd — Também chamado
a usuários alterarem suas senhas NIS.
de serviço yppasswdd, esse daemon permite
— Também chamado de serviço ypxfrd, esse daemon é responsável
pelas transfências de mapa NIS através da rede.
• /usr/sbin/rpc.ypxfrd
• /usr/sbin/yppush —
Essa aplicação amplia bancos de dados NIS alterados para servidores NIS
• /usr/sbin/ypserv —
Este é o servidor daemon do NIS.
múltiplos.
NIS é bastante inseguro para os padrões de hoje. Não tem mecanismo de autenticação da máquina e
passa toda a sua informação sem criptografia através da rede, incluindo uma gama de senhas. Como
resultado, tenha muito cuidado ao configurar uma rede que usa NIS. Para complicar ainda mais, a
configuração default do NIS é essencialmente insegura.
É recomendado a qualquer um planejando implementar um servidor NIS, primeiro proteger o serviço
portmap conforme descrito na Seção 5.2, e então resolver as seguintes questões.
5.3.1. Planejar Cuidadosamente a Rede
Como o NIS passa informações delicadas sem criptografia através da rede, é importante que o serviço
seja executado por trás de um firewall e numa rede segmentada e segura. Toda vez que informações
do NIS são passadas através de uma rede insegura, seus riscos estão sendo interceptados. Um planejamento 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 NIS
Parecido com uma Senha
Qualquer máquina com um domínio NIS pode usar comandos para extrair informações do servidor
sem autenticação, desde que o usuário saiba o o nome da máquina DNS e o nome de domínio NIS do
servidor.
Por exemplo: se alguém conectar um laptop a uma rede ou violar a rede por fora (e conseguir roubar
um endereço IP), o seguinte comando revela o mapa de /etc/passwd:
0
1
NIS_domain
ypcat -d
0
-h
1
DNS_hostname
passwd
Se este atacante for um usuário root, poderá obter o arquivo /etc/shadow digitando o seguinte
comando:
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.
44
Para dificultar o acesso aos mapas NIS a um atacante, crie uma série randômica de caracteres para o nome da máquina DNS, tal como o7hfawtgmhwg.domain.com. Similarmente, crie um nome
diferente 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áscara de rede/’network pairs’ no arquivo de modo que ypserv somente responda aos pedidos da rede
apropriada.
Veja abaixo um exemplo de entrada de um arquivo /var/yp/securenets:
255.255.255.0
192.168.0.0
Alerta
Nunca inicie um servidor NIS pela primeira vez sem criar o arquivo /var/yp/securenets.
Essa técnica não oferece proteção contra ataque de spoofing de IP, mas pelo menos impõe limites a
quais redes o servidor NIS serve.
5.3.4. Determinar Portas Estáticas e Usar Regras do IPTables
Todos os servidores relacionados ao NIS podem ter portas específicas, exceto o rpc.yppasswdd —
o daemon que permite a usuários alterarem suas senhas de autenticação (login). Determinar portas
para os outros dois daemons do servidor NIS, rpc.ypxfrd e ypserv, permite criar regras de firewall
para proteger futuramente os daemons do servidor NIS contra intrusos.
Para fazer isto, adicione as seguintes linhas a /etc/sysconfig/network:
YPSERV_ARGS="-p 834"
YPXFRD_ARGS="-p 835"
As seguintes regras do IPTables podem ser determinadas para reforçar a qual rede o servidor escuta
para estas portas:
iptables -A INPUT -p ALL -s! 192.168.0.0/24
iptables -A INPUT -p ALL -s! 192.168.0.0/24
--dport 834 -j DROP
--dport 835 -j DROP
Dica
Consulte o Capítulo 7 para mais informações sobre a implementação de firewalls com comandos do
IPTables.
45
5.3.5. Use Autenticação do Kerberos
Uma das desvantagens mais gritantes ao usar NIS para autenticação é que sempre que um usuário
se autentica (log in) 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áfego
de rede, essas misturas de nomes de usuários e senhas podem ser discretamente coletadas. Com tempo
suficiente, um programa de cracking de senha pode adivinhar senhas fáceis e um atacante pode obter
acesso a uma conta válida na rede.
Como o Kerberos usa criptografia de chave secreta, as misturas de senha nunca são enviadas através
da rede, tornando o sistema bem mais seguro. Para saber mais sobre o Kerberos, consulte o capítulo
entitulado Kerberos no Guia de Referência do Red Hat Enterprise Linux.
5.4. Protegendo o NFS
O Sistema de Arquivo de Rede (Network File System ou NFS) é um serviço RPC, usado em conjunto com o portmap e outros serviços relacionados, para oferecer sistemas de arquivo acessíveis para
máquinas-cliente. Para mais informações sobre o funcionamento do NFS, consulte o capítulo entitulado Sistema de Arquivo de Rede (NFS) no Guia de Referência do Red Hat Enterprise Linux. Para
mais informações sobre o NFS, consulte o Guia de Administração do Sistema do Red Hat Enterprise
Linux. As sub-seções a seguir assumem um conhecimento básico do NFS.
Importante
É recomendado que qualquer um planejando implementar um servidor NFS, primeiramente proteja
o serviço portmap, como descrito em Seção 5.2, antes de resolver as seguintes questões.
5.4.1. Planejar Cuidadosamente a Rede
Como o NFS passa todas as informações sem criptografia através da rede, é importante que o serviço
seja executado por trás de um firewall e numa rede segmentada e segura. Toda vez que informações
são passadas através do NFS em uma rede insegura, seus riscos estão sendo interceptados. Um planejamento cuidadoso da rede neste aspecto pode ajudar a prevenir violações à segurança.
5.4.2. Cuidado com Erros de Sintaxe
O servidor NFS determina quais sistemas de arquivo e quais máquinas exportar para estes diretórios
através do arquivo /etc/exports. Cuidado para não adicionar espaços extras ao editar este arquivo.
Por exemplo: a linha a seguir no arquivo /etc/exports compartilha o diretório /tmp/nfs/ com a
máquina bob.example.com com permissões 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áquina
bob.example.com com permissão somente-leitura, e o compartilha com o mundo com permissões
leitura 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 showmount
para checar o que foi compartilhado.
46
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 de
usuário sem privilégios. Desta maneira, todos os arquivos criados por root são de propriedade (owner)
do usuário nfsnobody, o que previne o upload de programas com as informações do conjunto de ids
do usuário.
Se no_root_squash é usado, os usuários root remotos poderão alterar qualquer arquivo do sistema de arquivo compartilhado e deixar aplicações infectadas pelo trojan, para que outros usuários as
executem inadvertidamente.
5.5. Protegendo o Servidor HTTP Apache
O Servidor HTTP Apache é um dos serviços mais estáveis e seguros distribuídos com o Red Hat
Enterprise Linux. Há um número exorbitante de opções e técnicas disponíveis para proteger o Servidor
HTTP Apache — muito numerosos para serem explorados em detalhes aqui.
Ao configurar o Servidor HTTP Apache é importante ler a documentação disponível para a
aplicação. Isto inclui o capítulo entitulado Servidor HTTP Apache do Guia de Referência do Red Hat
Enterprise Linux, o capítulo Configuração do Servidor HTTP Apache do Guia de Administração
do 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 muito
cuidadosos.
5.5.1. FollowSymLinks
Esta diretiva é habilitada por default, portanto cuidado ao criar os links simbólicos no documento root
do servidor Web. Por exemplo: é uma má idéia prover um link simbólico para /.
5.5.2. A Diretiva Indexes
Esta diretiva é habilitada por default, mas pode não ser desejável. Para prevenir que visitantes naveguem 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 conta
de usuário no sistema. Para possibilitar a navegação pelos diretórios do usuário no servidor, use as
seguintes diretivas:
UserDir enabled
UserDir disabled root
Estas diretivas ativam a navegação em todos os diretórios de usuário, exceto no /root. Para adicionar
usuários à lista de contas desativadas, adicione uma lista de usuários delimitada por espaço na linha
UserDir disabled.
47
5.5.4. Não Remova a Diretiva IncludesNoExec
Por default, o lado do servidor inclui módulos que não podem executar comandos. Não é recomendado
alterar esta configuração a não ser que seja absolutamente necessário, já que pode, potencialmente,
possibilitar que um atacante execute comandos no sistema.
5.5.5. Permissões Restritas para Diretórios Executáveis
Certifique-se de conceder permissões de gravação (write) para o usuário root em todos os diretórios
contendo scripts ou CGIs. Isto pode ser feito digitando os seguintes comandos:
44
55
chown root
directory_name
chmod 755
directory_name
Também verifique sempre se todos os scripts rodando no sistema funcionam como planejado antes de
colocá-los em produção.
5.6. Protegendo o FTP
O Protocolo de Transporte de Arquivo (File Transport Protocol - FTP) é um protocolo TCP antigo
desenvolvido para transferir arquivos pela rede. Já que todas as transações com o servidor (inclusive
a autenticação de usuário) são criptografadas, FTP é considerado um protocolo inseguro e deve ser
configurado cuidadosamente.
O Red Hat Enterprise Linux oferece três servidores FTP.
— Um FTP daemon ’kerberizado’ baseado no xinetd que não passa informações de
autenticação através da rede.
• gssftpd
•
Acelerador de Conteúdo Red Hat (tux) — Um servidor Web com capacidades de FTP no espaço
do kernel.
• vsftpd
— Uma implementação auto-suficiente do serviço FTP orientada à segurança.
As orientações de segurança a seguir se referem à configuração do serviço FTP vsftpd.
5.6.1. Banner de Saudação do FTP
Antes de submeter um nome de usuário e senha, é apresentado um banner de saudação a todos os
usuários. Por default, este banner inclui informações da versão úteis para crackers tentando identificar
fraquezas em um sistema.
Para alterar o banner de saudação para o vsftpd, adicione a seguinte diretiva a
/etc/vsftpd/vsftpd.conf:
4
ftpd_banner= insert_greeting_here
Substitua
ção.
6
5
insert_greeting_here
7
na diretiva acima pelo texto de sua mensagem de sauda-
Para banners com muitas linhas, é melhor usar um arquivo de banner. Para simplificar o gerenciamento
de banners múltiplos, coloque todos os banners em um novo diretório chamado /etc/banners/.
O arquivo de banners para conexões FTP, neste exemplo, é /etc/banners/ftp.msg. O exemplo
abaixo mostra como este arquivo se parece:
####################################################
# Hello, all activity on ftp.example.com is logged.#
48
####################################################
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
banner_file=/etc/banners/ftp.msg
Também é possível enviar banners adicionais para conexões entrantes usando TCP wrappers conforme
descrito na Seção 5.1.1.1.
5.6.2. Acesso Anônimo
A presença do diretório /var/ftp/ ativa a conta anônima.
A maneira mais fácil de criar este diretório é instalar o pacote vsftpd. Este pacote define uma árvore
de diretório para usuários anônimos e configura as permissões dos diretórios para somente-leitura para
usuários anônimos.
Por default, a conta do usuário anônimo não pode escrever em nenhum diretório.
Atenção
Se você possibilitar o acesso anônimo a um servidor FTP, tome cuidado onde armazena os dados
importantes.
5.6.2.1. Upload Anônimo
Para permitir que usuários anônimos façam upload, é recomendado criar um diretório
somente-gravação (write-only) em /var/ftp/pub/.
Para fazer isso, digite:
mkdir /var/ftp/pub/upload
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
49
Alerta
Administradores que permitem a usuários anônimos ler e gravar em diretórios, frequentemente percebem que seu servidor se torna um depósito de software roubado.
Adicionalmente, abaixo de vsftpd, adicione a seguinte linha a /etc/vsftpd/vsftpd.conf:
anon_upload_enable=YES
5.6.3. Contas de Usuário
Já que o FTP passa nomes de usuário e senhas não criptografados através de redes inseguras para
autenticação, é uma boa idéia proibir usuários do sistema acessarem o servidor através de suas contas
de usuário.
Para
desativar
contas
de
usuário
em
vsftpd,
adicione
a
seguinte
diretiva
a
local_enable=NO
5.6.3.1. Restringindo Contas de Usuário
A maneira mais fácil de desabilitar um grupo específico de contas, como o usuário root e aqueles com
privilégios sudo, a acessar um servidor FTP, é usar um arquivo de lista PAM conforme descrito na
Seção 4.4.2.4. O arquivo de configuração PAM para o vsftpd é /etc/pam.d/vsftpd.
Também é possível desativar contas de usuário dentro de cada serviço diretamente.
Para desativar contas de usuário específicas em vsftpd, adicione o nome do usuário a
/etc/vsftpd.ftpusers.
5.6.4. Use TCP Wrappers para Controlar Acesso
Use TCP wrappers para controlar o acesso a qualquer daemon do FTP, conforme descrito na Seção
5.1.1.
5.7. Protegendo o Sendmail
Sendmail é um Agente de Transporte de Correspondência (Mail Transport Agent - MTA) que utiliza
o Protocolo de Transporte de Correspondência Simples (Simple Mail Transport Protocol - SMTP)
para entregar mensagens eletrônicas entre outros MTAs e para enviar emails a clientes ou agentes de
entrega. Apesar de muitos MTAs serem capazes de criptografar tráfego entre eles, a maioria não o
faz, portanto enviar email através de qualquer rede pública é considerado uma forma de comunicação
essencialmente insegura.
Para mais informações sobre o funcionamento do e-mail e uma visão geral dos ajustes de configuração comuns, veja o capítulo Email no Guia de Referência do Red Hat Enterprise Linux. Esta seção
assume um conhecimento básico de como gerar um /etc/mail/sendmail.cf válido, editando o
/etc/mail/sendmail.mc e executando o comando m4, conforme explicado no Guia de Referência
do Red Hat Enterprise Linux.
50
É recomendado a qualquer um planejando implementar um servidor Sendmail, resolver as seguintes
questõ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 correspondê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.
— O número de conexões que o servidor pode receber por
segundo. Por default, o Sendmail não limita o número de conexões. Se um limite for definido e
alcançado, conexões futuras terão demora.
• confCONNECTION_RATE_THROTTLE
— O número máximo de processos-filho que podem ser gerados
pelo servidor. Por default, o Sendmail não determina um número limite de processos-filho. Se um
limite for definido e alcançado, conexões futuras terão demora.
• confMAX_DAEMON_CHILDREN
— O número mínimo de blocos livres que devem estar disponíveis para
que o servidor aceite correspondência. O default são 100 blocos.
• confMIN_FREE_BLOCKS
• confMAX_HEADERS_LENGTH — O tamanho
mensagem.
• confMAX_MESSAGE_SIZE —
máximo aceitável (em bytes) para o cabeçalho de uma
O tamanho máximo aceitável (em bytes) para qualquer mensagem.
5.7.2. NFS e Sendmail
Nunca coloque o diretório spool de correspondência, /var/spool/mail/, em um volume NFS compartilhado.
Já que o NFS não mantém controle sobre IDs de usuário e grupo, dois ou mais usuários podem ter o
mesmo UID e portanto receber e ler a correspondência do outro.
5.7.3. Usuários Mail-only
Para ajudar a prevenir exploits locais no servidor Sendmail, é melhor que usuários de mail acessem o
Sendmail usando apenas um programa de email. Contas shell não devem ser permitidas no servidor de
mail e todos os usuários shell do arquivo /etc/passwd devem ser definidos para /sbin/nologin
(com a possível exceção do usuário root).
5.8. Verificando Quais Portas estão Escutando
Após configurar os serviços de rede, é importante atentar para quais portas estão escutando as interfaces de rede do sistema. Quaisquer portas abertas podem ser evidências de uma intrusão.
Há duas formas básicas de listar as portas que estão escutando a rede. A menos confiável é questionar
a lista da rede ao digitar comandos como netstat -an ou lsof -i. Este método é menos confiável
já que estes programas não conectam à máquina pela rede, mas checam o que está sendo executado
no sistema. Por esta razão, estas aplicações são alvos frequentes de substituição por atacantes. Desta
maneira, os crackers tentam cobrir seus passos se abrirem portas de rede não autorizadas.
Uma forma mais confiável de listar quais portas estão escutando a rede é usar um scanner de portas
como o nmap.
O comando a seguir, submetido em um console, determina quais portas estão escutando conexões FTP
pela rede:
51
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
Service
22/tcp
open
ssh
111/tcp
open
sunrpc
515/tcp
open
printer
834/tcp
open
unknown
6000/tcp
open
X11
Remote 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. No
entanto, também há um serviço misterioso na porta 834. Para verificar se a porta está associada à lista
oficial de serviços conhecidos, digite:
cat /etc/services | grep 834
Este comando não retorna nenhum output. Isto indica que enquanto a porta está no intervalo reservado
(de 0 a 1023) e requer acesso root para abrir, não está associada a um serviço conhecido.
Em seguida, verifique as informações sobre a porta usando netstat ou lsof. Para verificar a porta
834 usando netstat, use o seguinte comando:
netstat -anp | grep 834
O comando retorna o seguinte output:
tcp
0
0 0.0.0.0:834
0.0.0.0:*
LISTEN
653/ypbind
A presença da porta aberta em netstat afirma que um cracker que abra clandestinamente uma porta
em 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, a
porta aberta pertence ao ypbind (NIS), que é um serviço RPC administrado juntamente ao serviço
portmap.
O comando lsof revela informações similares já que é capaz de ligar portas abertas a serviços:
lsof -i | grep 834
Veja abaixo a parte relevante do output deste comando:
ypbind
ypbind
ypbind
ypbind
653
655
656
657
0
0
0
0
7u
7u
7u
7u
IPv4
IPv4
IPv4
IPv4
1319
1319
1319
1319
TCP
TCP
TCP
TCP
*:834
*:834
*:834
*:834
(LISTEN)
(LISTEN)
(LISTEN)
(LISTEN)
Estas ferramentas podem revelar muitas informações sobre o estado dos serviços rodando em uma
máquina. Estas ferramentas são flexíveis e podem prover uma riqueza de informações sobre os serviços e configurações da rede. Portanto, recomendamos fortemente que você consulte as páginas man
do lsof, netstat, nmap e services.
52
Capítulo 6.
Redes Privadas Virtuais (Virtual Private
Networks)
Empresas com diversos escirtórios frequentemente se conectam através de linhas dedicadas por motivos de eficiência e proteção de dados sensíveis transitando entre as diferentes localidades. Por exemplo: muitas empresas usam frame relay ou linhas Asynchronous Transfer Mode (ATM) como uma
solução de rede end-to-end para ligar um escritório aos outros. Esta poder ser uma alternativa cara,
especialmente para pequenas e médias empresas que queiram expandir sem arcar com os altos custos
associados a circuitos digitais dedicados, de nível corporativo.
Engenheiros desenvolveram uma solução de baixo custo para este problema na forma de Redes Privadas Virtuais (Virtual Private Networks - VPNs). Seguindo os mesmos princípios funcionais dos
circuitos 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 de
Rede) existentes. Ela difere do frame relay ou do ATM em seu meio de transporte. As VPNs transmitem através de IP usando datagramas (UDP) como a camada de transporte, tornando-o um condutor
seguro através da Internet, para um determinado destino. A maioria das implementações VPN de software livre incorporam o padrão aberto e criptografia open source para mascarar futuramente os dados
em trânsito.
Algumas empresas aplicam soluções VPN de hardware para aumentar a segurança, enquanto outras
usam software ou implementações baseadas em protocolos. Há diversos fabricantes de soluções VPN
de hardware como Cisco, Nortel, IBM e Checkpoint. Existe uma solução VPN baseada em software
gratuito para Linux chamada FreeS/Wan, que utiliza uma implementação padronizada do IPSec (ou
Internet Protocol Security). Estas soluções VPN atuam como roteadores especializados situados entre
as conexões IP de dois escritórios.
Quando um pacote é transmitido de um cliente, é enviado através do roteador ou porta de comunicação (gateway), que então adiciona informações de cabeçalho para roteamento e autenticação, chamado
Cabeçalho de Autenticação (Authentication Header, AH). Os dados são criptografados e agrupados
com instruções para resolução e descriptografia, chamadas Encapsulating Security Payload (ESP). O
roteador VPN receptor depura as informações de cabeçalho e as roteia ao destino pretendido (uma
estação de trabalho ou um nódulo em uma rede). Usando uma conexão rede-a-rede, o nódulo receptor
da rede local recebe os pacotes descriptografados e prontos para processar. O processo de criptografia/descriptografia 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 descriptografar 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 cliente
também devem ter acesso às chaves trocadas para sessões de autenticação. VPNs são um meio seguro
e efetivo para conectar múltiplos nódulos remotos para atuar como uma intranet unificada.
6.1. VPNs e Red Hat Enterprise Linux
Usuários e administradores do Red Hat Enterprise Linux têm várias opções em termos de implementação de soluções de software para conectar e proteger sua WAN. Há, no entanto, dois métodos de
implementaçã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, envolve rodar o OpenSSH como um túnel entre dois nódulos remotos. Esta solução é uma boa alternativa
ao Telnet, rsh e outros métodos de comunicação remota, mas não atende completamente às necessidades de usabilidade de todos os telecomutadores e filiais corporativas. Duas soluções suportadas
inclusas no Red Hat Enterprise Linux mais próximas da definição de uma VPN são CIPE (Crypto IP
Encapsulation) 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 pacotes
IP criptografados que são encapsulados, ou embrulhados, em pacotes de datagrama (UDP). Pacotes
CIPE recebem informações de destino no cabeçalho e são criptografados utilizando o mecanismo
default de criptografia do CIPE. Os pacotes são então transferidos pelo IP como pacotes UDP através
do dispositivo virtual de rede do CIPE (cipcbx) por uma rede de transporte a um nódulo remoto
pretendido. A Figura 6-1 mostra uma configuração típica do CIPE conectando duas redes baseadas no
Linux:
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 atuando
como um nódulo habilitado pelo CIPE. A conexão CIPE atua como um túnel através do qual todos
os dados da Intranet são roteados entre nódulos remotos. Todos os dados são criptografados usando
chaves de 128 bits geradas dinamicamente, e podem ser comprimidos para transferências de arquivos
grandes ou para enviar aplicações do X para uma máquina remota. CIPE pode ser configurado para
comunicação entre duas ou mais máquinas Linux habilitadas pelo CIPE, e tem drivers de rede para
sistemas 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 de
segurança:
•
O Red Hat Enterprise Linux é distribuído com o CIPE, portanto está disponível para todas
as máquinas Red Hat Enterprise Linux de borda (por exemplo: firewalls ou portas de
comunicação/gateways) e clientes individuais que você queira conectar à sua Intranet. O Red Hat
Enterprise Linux também inclui cifras de criptografia suportadas pelo CIPE.
•
CIPE suporta criptografia usando o Blowfish padrão ou algoritmos de criptografia IDEA. Dependendo da regulamentação de exportação de criptografia em seu país, você deve usar o default (Blowfish) para criptografar todo o tráfego do CIPE em sua Intranet.
55
•
Já que o CIPE é baseado em software, qualquer máquina mais antiga ou redundante capaz de rodar o
Red Hat Enterprise Linux, pode se tornar uma porta de comunicação do CIPE, poupando a empresa
do 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 outros firewalls baseados em regras. A aceitação da entrada de pacotes CIPE UDP é a única coisa
necessária para coexistir com regras de firewall existentes.
•
A configuração do CIPE é feita através de arquivos texto, permitindo a administradores configurar
seus servidores e clientes CIPE remotamente, sem a necessidade de ferramentas gráficas pesadas
que podem não funcionar bem através de uma rede. CIPE também pode ser configurado através da
Ferramenta de Administração de Rede.
6.4. Instalação do CIPE
A instalação do CIPE equivale a instalar uma interface de rede sob o Linux. O pacote RPM do
cipe 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 a
interface do CIPE (if*-cipcb), e amostras de arquivos de configuração encontrados em
/usr/share/doc/cipe- version /samples/. Há também uma página com informações
detalhadas sobre o protocolo do CIPE e vários detalhes de implementação.
8
9
O guia a seguir detalha uma amostra de configuração envolvendo uma estação de trabalho cliente que
deseja se conectar seguramente a uma LAN remota com uma porta de comunicação CIPE. A estação
de trabalho usa um endereço IP dinâmico de uma conexão cable modem, enquanto a máquina da porta
de comunicação (gateway) ativada pelo CIPE emprega o intervalo 192.168.1.0/24. Isto é conhecido
como 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 a
Internet como um meio de transmissão do tráfego WAN. A estação de trabalho cliente então transfere
um arquivo através da Internet para o firewall habilitado pelo CIPE, onde cada pacote terá sua data
e hora registrados e lhes serão dados os endereços-par do firewall receptor habilitado pelo CIPE. O
firewall destino então lê as informações de cabeçalho, despe-as, e as envia para o roteador LAN remoto
para serem roteadas para o nódulo de destino. Este processo é simples e completamente transparente
a usuários finais. A maioria das transações são feitas entre pares habilitados pelo CIPE.
6.5. Configuração do Servidor CIPE
Para configurar o servidor CIPE, instale o pacote RPM cipe pelo CD-ROM do Red Hat Enterprise
Linux 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 antiga
do 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 instalado
em 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 mais
de uma conexão CIPE no servidor CIPE) para incluir os endereços da sub-rede de sua LAN e
endereços IP do firewall publicamente roteável. Veja a seguir o arquivo options incluso
no RPM cipe do Red Hat Enterprise Linux que, para este exemplo, foi renomeado como
options.cipbcb0:
56
# 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 address
ptpaddr
6.5.4.3
# our CIPE device’s IP address
ipaddr
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ção
de trabalho. O me é o endereço IP publicamente roteável do cliente que envia os pacotes UDP através
da Internet, e peer é o endereço IP publicamente roteável do servidor CIPE. Note que o endereço
IP da estação de trabalho do cliente é 0.0.0.0 porque utiliza uma conexão dinâmica. O cliente CIPE
manipulará a conexão para a máquina do servidor CIPE. O campo key (representado por x’s; a chave
deve ser secreta) é a chave estática compartilhada. Esta chave deve ser a mesma para ambos os pares
ou a conexão não será possível. Veja a Seção 6.8 para informações sobre como gerar uma chave
estática compartilhada para suas máquinas CIPE.
Aqui está o /etc/cipe/options.cipcb0 editado que a estação de trabalho utilizará:
ptpaddr
ipaddr
me
peer
key
10.0.1.2
10.0.1.1
0.0.0.0
LAN.EXAMPLE.COM:6969
123456ourlittlesecret7890shhhh
Aqui está o arquivo /etc/cipe/options.cipcb0 para o servidor CIPE:
ptpaddr
ipaddr
me
peer
key
10.0.1.1
10.0.1.2
LAN.EXAMPLE.COM:6969
0.0.0.0
123456ourlittlesecret7890shhhh
6.6. Configurando Clientes para o CIPE
Após configurar o servidor CIPE apropriadamente e testar as funcionalidades, você pode extender a
conexão para a máquina cliente.
O cliente CIPE deve poder conectar e desconectar a conexão CIPE de maneira automatizada. Consequentemente, CIPE contém mecanismos próprios para personalizar configurações para usos individuais. Por exemplo: um funcionário remoto pode conectar-se a um dispositivo CIPE na LAN digitando
o seguinte:
/sbin/ifup cipcb0
57
O dispositivo deve aparecer automaticamente. As informações de roteamento e regras de firewall
também devem ser configuradas ao longo da conexão. O funcionário remoto deve poder terminar a
conexão com o seguinte:
/sbin/ifdown cipcb0
Configurar clientes requer a criação de scripts localizados que são executados após o dispositivo ser
carregado. A configuração do dispositivo pode ser feita localmente através de um arquivo, criado pelo usuário, chamado /etc/sysconfig/network-scripts/ifcfg-cipcb0. Este arquivo contém
parâmetros que determinam se a conexão CIPE ocorre no momento de ligar a máquina (boot-time), o
nome do dispositivo do CIPE, entre outras informações. Veja a seguir o arquivo ifcfg-cipcb0 para
um cliente remoto conectando a um servidor CIPE:
DEVICE=cipcb0
ONBOOT=yes
BOOTPROTO=none
USERCTL=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) para
receber um endereço IP para o dispositivo. O campo PEERROUTEDEV determina o nome do dispositivo
do 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 CIPE
na máquina do cliente envie e receba pacotes UDP. Consulte o Capítulo 7 para informações sobre a
configuraçã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 um
arquivo, criado pelo usuário, chamado /etc/cipe/ip-up.local. Os parâmetros locais devem ser
revertidos 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 a
conectividade do CIPE. As regras seguintes permitem transmissões UDP CIPE na máquina do cliente
remoto conectando à LAN. A regra final adiciona o ’mascaramento’ do IP para permitir que o cliente
remoto 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
/sbin/iptables -A INPUT -j ACCEPT -i
/sbin/iptables -t nat -A POSTROUTING
udp -s 10.0.1.1
cipcb0
lo
-s 192.168.1.0/24 -o eth0 -j MASQUERADE
58
Adicione regras de roteamento para que a máquina cliente acesse os nódulos por trás da conexão CIPE
como se estivessem na rede local. Isto pode ser feito rodando o comando route. Neste exemplo, a
estaçã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 -v
if [ -f /etc/sysconfig/network-scripts/ifcfg-$1 ] ; then
. /etc/sysconfig/network-scripts/ifcfg-$1
else
cat
EOT | logger
Cannot find config file ifcfg-$1. Exiting.
EOF
exit 1
fi
:;:
:;:
if [ -n ${PEERROUTEDEV} ]; then
EOT | logger
cat
Cannot find a default route to send cipe packets through!
Punting and hoping for the best.
EOT
# Use routing table to determine peer gateway
export 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 $PEERROUTEDEV
route 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
/sbin/iptables -t nat -A POSTROUTING
udp -s 10.0.1.2
$1
lo
-s 192.168.1.0/24 -o eth0 -j MASQUERADE
6.7. Personalizando o CIPE
O CIPE pode ser configurado de inúmeras maneiras, desde passar parâmetros como argumentos de
linhas de comando ao iniciar o ciped até gerar novas chaves estáticas compartilhadas. Isto proporciona ao adminstrador de segurança a flexibilidade de personalizar as sessões do CIPE para garantir a
segurança assim como para aumentar a produtividade.
59
Nota
Os parâmetros mais comuns devem ser inseridos no arquivo /etc/cipe/options.cipcbx para o
carregamento automático no momento da execução (runtime).
Esteja ciente de que todos os parâmetros passados como opções na linha de comandos
sobrescreverã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
ipup
Escolha um script ip-up alternativo e então o /etc/cipe/ip-up
default
/etc/cipe/ip-down
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 do
proxy
tokey
Define o tempo de vida chave dinâmico. O default são 10 minutos (600
segundos)
tokxc
Valor do tempo limite para intercâmbio de chave compartilhada. Default
são 10 segundos
tokxts
Valor do tempo limite para registro de data e hora do intercâmbio de
chave compartilhada. Default é 0 (sem registro de data e
hora/timestamps)
toping
Valor do tempo limite para pings ’keepalive’. Default é 0
Tabela 6-1. Parâmetros do CIPE
60
6.8. Gerenciamento da Chave do CIPE
Como mencionado anteriormente, o CIPE incorpora uma combinação segura de chaves de ligação
estáticas e tráfego criptografado para criar um túnel seguro através de redes de transporte como a
Internet. O uso de chaves de ligação estáticas provém um ponto de referência comum para que duas
redes ativadas pelo CIPE passem informações de forma segura. Portanto, é imperativo que as duas
portas de comunicação (gateways) de rede ativadas pelo CIPE compartilhem exatamente a mesma
chave, 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. Geradores
alfa-numéricos randômicos não funcionam. As chaves estáticas devem ter conjuntos de 32 caracteres
e 128 bits. Isto pode ser criado executando o seguinte comando, que usa od para criar uma chave
hexadecimal 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. IPsec
O Red Hat Enterprise Linux suporta um protocolo para conectar máquinas e redes remotas entre si
usando um túnel seguro em uma rede de transporte comum, como a Internet. O protocolo, chamado
IPSEC, pode ser implementado usando conexões máquina-a-máquina (uma estação de trabalho conectada a outra) ou rede-a-rede (uma LAN/WAN conectada a outra). A implementação do IPSEC no
Red Hat Enterprise Linux usa IKE (Internet Key Exchange), um protocolo implementado pelo IETF
para 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. O
deamon do chaveiro racoon é responsável pela distribuição e troca de chaves IKE.
6.10. Instalação do IPsec
A implementação do IPsec requer a instalação do pacote RPM ipsec-tools em todas as máquinas
IPsec (se usar uma configuração máquina-a-máquina) ou roteadores IPsec (se usar uma configuração
rede-a-rede). O pacote RPM contém bibliotecas, daemons e arquivos de configuração essenciais para
auxiliar na configuração da conexão IPsec.
— biblioteca que contém a interface socket de gerenciamento da chave de
confiança PF_KEY entre o kernel do Linux e a implementação do IPsec usada no Red Hat Enterprise Linux.
• /lib/libipsec.so
— manipula o gerenciamento da chave e atributos de segurança do IPsec no kernel. Este executável é controlado pelo daemon de gerenciamento da chave racoon. Para mais
informações sobre o setkey, consulte a página man (8) do setkey.
• /sbin/setkey
— o daemon de gerenciamento da chave IKE, usado para administrar e controlar
as associações de segurança e compartilhamento de chaves entre sistemas conectados pelo IPsec.
Este daemon pode ser configurado editando o arquivo /etc/racoon/racoon.conf. Para mais
informações sobre o racoon, consulte a página man (8) do racoon.
• /sbin/racoon
— o arquivo de configuração do daemon do racoon usado para
configurar vários aspectos da conexão IPsec, incluindo métodos de autenticação e algoritmos de
criptografia usados na conexão. Para uma lista completa das diretivas disponíveis, consulte a página
man (5) do racoon.conf.
• /etc/racoon/racoon.conf
A configuração do IPsec no Red Hat Enterprise Linux pode ser feita pela Ferramenta de Administração de Rede ou manualmente editando os arquivos de configuração de rede e do IPsec. Para mais
61
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 uma
LAN/WAN a outra através do IPsec, consulte a Seção 6.12.
6.11. Configuração Máquina-a-Máquina do IPsec
O IPsec pode ser configurado para conectar um computador pessoal ou estação de trabalho a outra
através de uma conexão máquina-a-máquina. Este tipo de conexão utiliza a rede à qual cada máquina
está conectada para criar o túnel seguro entre elas. Os requisitos de uma conexão máquina-a-máquina
são mínimos, já que é a configuração do IPsec em cada máquina. As máquinas precisam somente de
uma conexão dedicada a uma rede de transporte (como a Internet) e do Red Hat Enterprise Linux para
criar a conexão do IPsec.
O primeiro passo para criar uma conexão é coletar as informações de sistemas e de rede de cada
estação de trabalho (workstation). Para uma conexão máquina-a-máquina, você precisa das seguintes
informações:
•
O endereço IP das duas máquinas
•
Um nome único para identificar a conexão IPsec e distinguí-la de outros dispositivos e conexões
(ex.: ipsec0)
•
Uma chave fixa de criptografia ou uma gerada automaticamente pelo racoon
•
Uma chave de autenticação pré-compartilhada, usada para iniciar a conexão e trocar chaves de
criptografia durante a sessão
Por exemplo: suponha que as estações de trabalho A e B queiram se interconectar através de um
túnel IPsec. Pretendem se conectar usando uma chave pré-compartilhada com o valor foobarbaz
e os usuários concordam em deixar que o racoon gere automaticamente e compartilhe uma chave
de autenticação entre cada máquina. Ambos usuários das máquinas decidem nomear suas conexões
como ipsec0.
Veja 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.X
TYPE=IPsec
ONBOOT=yes
IKE_METHOD=PSK
A estação de trabalho A substituirá X.X.X.X pelo endereço IP da estação de trabalho B, enquanto
esta substitui X.X.X.X pelo endereço IP da estação de trabalho A. A conexão é definida para iniciar
na inicialização (boot-up) (ONBOOT=yes) e usa o método de autenticação de chave pré-compartilhada
(IKE_METHOD=PSK).
A seguir, veja o arquivo da chave pré-compartilhada (chamado /etc/sysconfig/networkscripts/keys-ipsec0) que ambas máquinas usam para autenticarem-se entre si. O conteúdo
deste arquivo deve ser idêntico nas duas estações de trabalho, e somente o usuário root deve ser
capaz de acessar ou gravar (read or write) este arquivo.
IKE_PSK=foobarbaz
62
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 estaçõ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 o
túnel IPsec é ativado. Para a estação de trabalho A, X.X.X.X na indicação include é o dendereço
IP da estação de trabalho B. O oposto vale para a estação de trabalho B. Veja a seguir um arquivo
racoon.conf típico quando a conexão IPsec é ativada.
# Racoon IKE daemon configuration file.
# See ’man racoon.conf’ for a description of the format and entries.
path include "/etc/racoon";
path pre_shared_key "/etc/racoon/psk.txt";
path certificate "/etc/racoon/certs";
sainfo anonymous
{
pfs_group 2;
lifetime time 1 hour ;
encryption_algorithm 3des, blowfish 448, rijndael ;
authentication_algorithm hmac_sha1, hmac_md5 ;
compression_algorithm deflate ;
}
include "/etc/racoon/X.X.X.X.conf"
Para iniciar a conexão, reinicialize a estação de trabalho ou execute o seguinte comando, como root,
em cada máquina:
/sbin/ifup ipsec0
Para testar a conexão IPsec, execute o utilitário tcpdump para visualizar os pacotes de rede sendo
transferidos entre as máquinas (ou redes) e verificar se estão criptografadas via IPsec. O pacote deve
incluir um cabeçalho AH e deve ser exibido como pacotes ESP. ESP significa que está criptografado.
Por exemplo:
17:13:20.617872 pinky.example.com > ijin.example.com: \
AH(spi=0x0aaa749f,seq=0x335): ESP(spi=0x0ec0441e,seq=0x335) (DF)
6.12. Configuração Rede-a-Rede do IPsec
O IPsec também pode ser configurado para conectar uma rede inteira (como uma LAN ou WAN) a
uma rede remota através de uma conexão rede-a-rede. Este tipo de conexão requer a configuração
de roteadores IPsec em cada lado das redes conectadas para processar e rotear informações de um
nódulo de uma rede para outro nódulo de uma rede remota. O Figura 6-2 mostra uma conexão IPsec
rede-a-rede passando por um túnel.
63
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 roteadores
IPSEC para autenticar e iniciar uma conexão, usando um túnel seguro através da Internet. Os pacotes
interceptados em trânsito requerem descriptografia muito forte para crackear a cifra protegendo os pacotes entre estas LANs. O processo de comunicação entre um nódulo no intervalo IP 192.168.1.0/24
e outro no 192.168.2.0/24 é completamente transparente aos nódulos, já que o processamento, criptografia/descriptografia e roteamento dos pacotes IPSEC são executados inteiramente pelo roteador
IPSEC.
As informações necessárias para uma conexão rede-a-rede incluem:
•
Os endereços IP externamente acessíveis dos roteadores IPsec dedicados
•
Os intervalos de endereços de rede da LAN/WAN servida pelos roteadores IPsec tal como
192.168.0.0/24 ou 10.0.1.0/24)
•
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 de
criptografia durante a sessão
Por exemplo: suponha que a LAN A (lana.example.com) e LAN B (lanb.example.com) queiram se interconectar através de um túnel IPsec. O endereço de rede da LAN A está no intervalo 192.168.1.0/24,
enquanto a LAN B usa o intervalo 192.168.2.0/24. O endereço IP da porta de comunicação (gateway)
é 192.168.1.254 para a LAN A e 192.168.2.254 para a LAN B. Os roteadores IPSEC estão separados
de cada porta de comunicação da LAN e usam dois dispositivos de rede: à eth0 é atribuído um endereço IP estático acessível externamente, que acessa à Internet, enquanto eth1 atua como um ponto
de roteamento para processar e transmitir pacotes da LAN de um nódulo da rede a outros nódulos da
rede remota.
A conexão IPsec entre as redes usa uma chave pré-compartilhada com o valor r3dh4tl1nux, e os
administradores de A e B concordam em deixar que o racoon gere automaticamente e compartilhe
uma chave de autenticação entre os roteadores IPsec. O administrador da LAN A decide nomear a
conexão IPSEC como ipsec0, enquanto o administrador da LAN B nomeia a conexão IPSEC como
ipsec1.
Veja seguir o arquivo ifcfg para uma conexão IPsec rede-a-rede da LAN A. O nome único para identificar a conexão neste exemplo é ipsec1, portanto o arquivo resultante é nomeado como
/etc/sysconfig/network-scripts/ifcfg-ipsec1.
TYPE=IPsec
ONBOOT=yes
IKE_METHOD=PSK
64
SRCGW=192.168.1.254
DSTGW=192.168.2.254
SRCNET=192.168.1.0/24
DSTNET=192.168.2.0/24
DST=X.X.X.X
A conexão é configurada para iniciar na inicialização da máquina (ONBOOT=yes) e usa o método de autenticação de chave pré-compartilhada (IKE_METHOD=PSK). O administrador da LAN A
indica a porta de comunicação (gateway) de destino, que é a porta de comunicação da LAN B
(DSTGW=192.168.2.254) e também a porta de comunicação de origem, que é o endereço IP da
porta de comunicação da LAN A (SRCGW=192.168.1.254). O administrador então indica a rede de
destino, que é o intervalo de rede da LAN B (DSTNET=192.168.2.0/24) e também a rede de origem
(SRCNET=192.168.1.0/24). Finalmente, o administrador indica o endereço IP de destino, que é o
endereço IP externamente acessível da LAN B (X.X.X.X).
Veja a seguir o arquivo da chave pré-compartilhada (chamado /etc/sysconfig/networkscripts/keys-ipsecX onde X é 0 para a LAN A e 1 para a LAN B) que as duas redes usam para
autenticarem-se entre si. O conteúdos deste arquivo devem ser idênticos e somente o usuário root
pode 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 dois
roteadores 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 que
a linha include na parte inferior do arquivo aparece somente se estiver conectada ao túnel IPsec no
momento, 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 como X.X.X.X.conf (substitua X.X.X.X pelo endereço IP do roteador IPsec remoto). Note que este
arquivo é gerado automaticamente quando o túnel IPsec é ativado e não deve ser editado diretamente.
65
;
remote X.X.X.X
{
exchange_mode aggressive, main;
my_identifier address;
proposal {
encryption_algorithm 3des;
hash_algorithm sha1;
authentication_method pre_shared_key;
dh_group 2 ;
}
}
Antes de iniciar a conexão IPsec, o encaminhamento de IP deve ser habilitado no kernel. Como root,
habilite o encaminhamento de IP numa janela de comandos:
1. Edite /etc/sysctl.conf e defina net.ipv4.ip_forward para 1.
2. Execute o seguinte comando para habilitar a alteração:
sysctl -p /etc/sysctl.conf
Para iniciar a conexão IPsec, reinicialize os roteadores IPsec ou execute o seguinte comando como
root em cada roteador:
/sbin/ifup ipsec0
As conexões são ativadas e as duas LANs, A e B, são capazes de se comunicarem. As rotas são criadas
automaticamente através do script de início invocado pela execução do ifup na conexão IPsec. Para
exibir uma lista de rotas da rede, execute o seguinte comando:
/sbin/ip route list
Para testar a conexão IPsec, execute o utilitário tcpdump no dispositivo externamente roteável (eth0
neste exemplo) para visualizar os pacotes de rede sendo transferidos entre as máquinas (ou redes) e
para verificar se estão criptografados com IPsec. Por exemplo: para verificar a conectividade da LAN
A, digite o seguinte:
tcpdump -n -i eth0 host lana.example.com
O pacote deve incluir um cabeçalho AH e deve ser exibido como um pacote ESP. ESP significa que
está criptografado. Por exemplo (barras invertidas denotam a continuação de uma linha):
12:24:26.155529 lanb.example.com > lana.example.com: AH(spi=0x021c9834,seq=0x358): \
lanb.example.com > lana.example.com: ESP(spi=0x00c887ad,seq=0x358) (DF) \
(ipip-proto-4)
66
Capítulo 7.
Firewalls
A segurança da informação é comumente encarada como um processo e não como um produto. Entretanto, implementações de segurança padronizadas geralmente utilizam alguma forma de mecanismo
dedicado a controlar os privilégios de acesso e a restringir recursos de rede a usuários que são autorizados, identificáveis e rastreáveis. O Red Hat Enterprise Linux inclui muitas ferramentas poderosas
para auxiliar administradores e engenheiros de segurança em questões de controle de acesso em nível
de rede.
Além das soluções VPN, como CIPE ou IPSec (abordados em Capítulo 6), os firewalls são um dos
componentes centrais da implementação de segurança na rede. Diversos fabricantes comercializam
soluções de firewall para suprir todos os nichos do mercado: de usuários domésticos protegendo um
PC até soluções de centro de dados para proteger informações corporativas vitais. Firewalls podem ser
soluções de hardware ligados intermitentemente, como as aplicações de firewall da Cisco, Nokia, e
Sonicwall. Também há soluções de software de firewall proprietárias desenvolvidas para os mercados
doméstico e corporativo por fabricantes como Checkpoint, McAfee e Symantec.
Além das diferenças entre firewalls de hardware e de sotfware, também há diferenças na maneira como
os firewalls funcionam, que separam uma solução da outra. Tabela 7-1 detalha três tipos comuns de
firewalls e como eles funcionam:
Método Descrição
Vantagens
Desvantagens
NAT
Pode ser configurado
transparentemente para
máquinas em uma LAN
Proteção de muitas
máquinas e serviços por
trás de um ou mais
endereços IP externos,
simplificando tarefas de
administração
Restrição de acesso do
usuário de e para a LAN
pode ser configurado
abrindo e fechando portas
no firewall/gateway NAT
Não pode evitar atividades
maldosas uma vez que
usuários se conectam a um
serviço fora do firewall
Tradução do Endereço da
Rede (NAT) insere
sub-redes IP internas
através de um ou um
pequeno grupo de endereços
IP externos, mascarando
todos os pedidos para uma
fonte ao invés de várias
<
<
<
<
68
Capítulo 7. Firewalls
Método Descrição
Vantagens
Desvantagens
Filtro
de
Pacotes
Personalizável através da
funcionalidade front-end
Não pode filtrar pacotes
para conteúdo similar a
firewalls de proxy
Processa pacotes na
camada do protocolo, mas
não pode filtrar pacotes
numa camada de aplicação
Arquiteturas de rede
complexas podem fazer
com que o estabelecimento
de regras de filtragem de
pacotes se torne difícil,
especialmente se for usado
com o mascaramento do IP
ou sub-redes locais e redes
DMZ
Proxy
A filtragem de pacotes lê
cada pacote de dados que
passa dentro e fora de uma
LAN. Pode ler e processar
pacotes pela informação do
cabeçalho e filtra o pacote
baseado em conjuntos de
regras programáveis
implementadas pelo
administrador do firewall. O
kernel do Linux tem a
funcionalidade embutida de
filtragem de pacotes através
do sub-sistema netfilter do
kernel.
Firewalls de proxy filtram
todos os pedidos de um
determinado protocolo ou
tipo dos clientes LAN para
uma máquina proxy, que
então faz estes pedidos à
Internet representando o
cliente local. Uma máquina
proxy atua como um buffer
entre usuários remotos
maldosos e as máquinas dos
clientes internos da rede.
=
=
iptables
Não requer nenhuma
personalização no lado do
cliente, já que todas as
atividades da rede são
filtradas no nível do
roteador ao invés do nível
da aplicação
Já que os pacotes não são
transmitidos através de um
proxy, a performance da
rede é mais rápida devido à
conexão direta do cliente ‘a
máquina remota
=
=
Dá aos administradores o
controle de quais
aplicações e protocolos
funcionam fora da LAN
Alguns servidores proxy
podem armazenar dados
no cache para que clientes
possam acessar dados
frequentemente
requisitados no cache local
ao invés de ter que usar a
conexão Internet para
solicitá-los. Isto é
conveniente para reduzir o
consumo desnecessário de
banda
Serviços proxy podem ser
registrados e monitorados
de perto, permitindo um
controle mais restrito sobre
a utilização de recursos na
rede
=
=
=
=
=
=
Proxies são
frequentemente específicos
às aplicações (HTTP,
telnet, etc.) ou restritos a
protocolos (a maioria dos
proxies funcionam com
serviços conectados por
TCP, somente)
Serviços de aplicação não
podem rodar por trás de
um proxy, portanto seus
servidores de aplicações
devem usar uma forma
separada de segurança em
rede
Proxies podem se tornar um
gargalo na rede, já que
todos os pedidos e
transmissões passam através
de uma mesma fonte ao
invés de passar diretamente
do cliente para as conexões
remotas de serviço
=
Tabela 7-1. Tipos de Firewall
7.1. Netfilter e IPTables
O kernel do Linux apresenta um sub-sistema de rede poderoso chamado netfilter. O sub-sistema netfilter oferece filtragem de pacote ’stateful’ (que guarda o estado das conexões inciadas pelos clientes)
ou ’stateless’ (na qual cada pacote é analisado individualmente, sem levar em conta pacotes anteriores
trocados na mesma conexão), assim como NAT e serviços de mascaramento de IP. Netfilter também
tem a habilidade de danificar as informações do cabeçalho para roteamento avançado e gerenciamento
do estado de conexão. O Netfilter é controlado através da funcionalidade IPTables.
69
7.1.1. Visão geral do IPTables
O poder e flexibilidade do netfilter é implementado através da interface IPTables. Esta ferramenta de
linha de comando é similar em sintaxe ao seu predecessor, o IPChains. No entanto, IPTables usa o
sub-sistema netfilter para melhorar a conexão, inspeção e processamento de rede; enquanto o IPChains
usava conjuntos de regras complexas para filtrar localidades de fonte e destino, assim como portas
de conexão para ambos. IPTables inclui registro avançado, ações pré e pós-roteamento, tradução do
endereço de rede e encaminhamento de porta; tudo em apenas uma interface de linha de comando.
Esta seção oferece uma visão geral do IPTables. Para informações mais detalhadas sobre IPTables,
consulte o Guia de Referência do Red Hat Enterprise Linux.
7.2. Usando o IPTables
O 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 comandos:
service ip6tables stop
chkconfig ip6tables off
Para fazer com que o IPTables inicie por default sempre que a máquina for iniciada, você deve alterar
o status do nível de execução (runlevel) do serviço, usando chkconfig.
chkconfig --level 345 iptables on
A sintaxe do IPTables é separada em camadas. A camada principal é a corrente (chain). Uma corrente
especifica 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 corrente
para uma regra. As três correntes embutidas do IPTables (ou seja, as correntes que afetam todos os
pacotes que trafegam pela rede) são INPUT, OUTPUT e FORWARD. Estas correntes são permanentes
e não podem ser deletadas.
Importante
Ao criar um conjunto de regras do IPTables, é crucial lembrar que a ordem é importante. Por exemplo: uma corrente especifica que todos os pacotes da sub-rede local 192.168.100.0/24 sejam
derrubados. E então a corrente é adicionada (-A), o que permite pacotes do 192.168.100.13 (que
está dentro da sub-rede restrita derrubada); então a regra adicionada é ignorada. Você deve definir
uma regra para permitir 192.168.100.13 primeiro, e então definir uma regra para derrubar na subrede.
Para inserir uma regra arbitrariamente em um conjunto de regras existentes, use -I, seguido pelo
conjunto no qual deseja inserir a regra e pelo número da regra (1,2,3,...,n) onde você deseja que a
regra resida. Por exemplo:
70
iptables -I INPUT 1 -i lo -p all -j ACCEPT
A regra é inserida como a primeira no conjunto INPUT para permitir o tráfego do dispositivo loopback
local.
7.2.1. Normas Básicas de Firewall
Algumas normas básicas estabelecidas desde o começo podem auxiliar na construção de regras detalhadas definidas pelo usuário. O IPTables usa normas (-P) para criar regras default. Administradores
com foco na segurança geralmente escolhem derrubar todos os pacotes como uma norma e só permitem pacotes específicos, analisando-os caso-a-caso. As seguintes regras bloqueiam todos os pacotes
entrando e saindo de uma porta de comunicação (gateway) de rede:
iptables -P INPUT DROP
iptables -P OUTPUT DROP
Adicionalmente, é recomendado que qualquer pacote encaminhado — tráfego de rede roteado do
firewall para seu nódulo de destino — seja negado também, para restringir clientes internos de exposiçã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 lidando
com regras adicionais. REJECT um alvo nega acesso e retorna um erro conexão negada (conexão
negada) para usuários que tentarem se conectar ao serviço. A DROP, como o nome sugere, derruba
os pacotes sem nenhum aviso para usuários do telnet. Administradores podem usar sua própria
prudência ao lidar com estes alvos; entretanto, para evitar a confusão do usuário e tentativas para
continuar 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ça
em particular. As seguintes seções descrevem algumas regras que você talvez queira implementar
enquanto constrói seu firewall IPTables.
7.2.2. Salvando e Restaurando Regras IPTables
Regras de firewall são válidas somente enquanto o computador estiver ligado. Se o sistema for reinicializado, as regras serão automaticamente eliminadas e restauradas. Para salvar as regras de modo
que elas sejam carregadas posteriormente, use o seguinte comando:
/sbin/service iptables save
As regras são armazenadas no arquivo /etc/sysconfig/iptables e são aplicadas sempre que o
serviço é iniciado, reiniciado ou quando a máquina é reinicializada.
71
7.3. Filtragem Comum do iptables
Manter atacantes remotos fora de uma LAN é um aspecto importante da segurança de rede, se não o
mais importante. A integridade de uma LAN deve ser protegida de usuários remotos maldosos, através do uso de regras rígidas de firewall. Entretanto, com uma norma default definida para bloquear
todos os pacotes entrando, saindo e encaminhados, é impossível que o firewall/porta de comunicação
(gateway) e usuários internos da LAN 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 abrir
certas portas para a comunicação.
Por exemplo: para permitir o acesso à porta 80 pelo firewall, adicione a seguinte regra:
iptables -A INPUT -p tcp -m tcp --sport 80 -j ACCEPT
iptables -A OUTPUT -p tcp -m tcp --dport 80 -j ACCEPT
Isto permite a navegação Web normal através de sites que comunicam através da porta 80. Para permitir o acesso a sites seguros (como https://www.example.com/), você deve abrir a porta 443 também.
iptables -A INPUT -p tcp -m tcp --sport 443 -j ACCEPT
iptables -A OUTPUT -p tcp -m tcp --dport 443 -j ACCEPT
Algumas vezes você precisa de acesso remoto à LAN de fora dela. Serviços seguros, tais como SSH
e CIPE, podem ser usados para conexão remota criptografada aos serviços da LAN. Para administradores com recursos baseados em PPP (tais como bancos modernos ou contas ISP volumosas), o
acesso discado pode ser usado para circundar as barreiras do firewall seguramente, já que conexões
via modem ficam tipicamente por trás de um firewall/gateway por serem conexões diretas. Entretanto, casos especiais podem ser elaborados para usuários remotos com conexões de banda larga. Você
pode configurar o IPTables para aceitar conexões de clientes SSH e CIPE remotos. Por exemplo: para
permitir o acesso remoto SSH, as seguintes regras podem ser usadas:
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
iptables -A OUTPUT -p udp --sport 22 -j ACCEPT
Pedidos de conexão CIPE feitas de fora podem ser aceitas com o seguinte comando (substituindo x
pelo número de seu dispositivo):
iptables -A INPUT -p udp -i cipcbx -j ACCEPT
iptables -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 regra
permite a interface cipcb para conexões de fora, ao invés de portas de recurso ou de destino (apesar
de 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 do
Red 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 permitem
que 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 NAT
A maioria das empresas designam um número limitado de endereços IP publicamente roteáveis de
seus ISPs. Devido essa permissão limitada, os administradores devem encontrar maneiras criativas
de compartilhar o acesso aos serviços de Internet sem dar poucos endereços IP para cada nódulo da
LAN. Usar um endereço IP privado é a maneira comum de permitir que todos os nódulos de uma LAN
acessem apropriadamente serviços de rede internamente e externamente. Roteadores de borda (como
72
firewalls) podem receber transmissões de entrada da Internet e rotear os pacotes para o nódulo pretendido na LAN. Ao mesmo tempo, firewall/portasde comunicação (gateways) também podem rotear
pedidos de saída de um nódulo da LAN para o serviço remoto da Internet. Esse encaminhamento de
tráfego de rede pode se tornar perigoso às vezes, especialmente com a disponibilidade de ferramentas
de cracking modernas que podem espionar endereços IP internos e fazer com que a máquina remota
do atacante atue como um nódulo em sua LAN. Para evitar isso, o iptables oferece normas de roteamento e encaminhamento que podem ser implementadas para evitar o uso indevido dos recursos de
rede.
A norma FORWARD permite a um administrador controlar onde os pacotes podem ser roteados em uma
LAN. Por exemplo: para permitir o encaminhamento da LAN inteira (assumindo que o firewall/porta
de comunicação (gateway) tenha um endereço IP interno na eth 1), as seguintes regras podem ser
definidas:
iptables -A FORWARD -i eth1 -j ACCEPT
iptables -A FORWARD -o eth1 -j ACCEPT
Nota
Por default, a norma IPV4 nos kernels do Red Hat Enterprise Linux desabilita o suporte para encaminhamento do IP, o que evita que caixas rodando o Red Hat Enterprise Linux funcionem como
roteadores de borda dedicados. Para habilitar o encaminhamento do IP, execute o seguinte comando:
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 reinicializaçã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 comuniquem
externamente (por exemplo: com a Internet). Para permitir que nódulos da LAN com endereços IP
privados se comuniquem com redes públicas externas, configure o firewall com o mascaramento do
IP, que mascara pedidos de nódulos da LAN com endereços IP do dispositivo externo do firewall
(neste caso, eth0):
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
7.5. DMZs e iptables
Regras também podem definidas para determinadas máquinas, como um servidor dedicado HTTP
ou FTP, preferencialmente um que esteja isolado da rede interna em uma zona desmilitarizada (demilitarized zone - DMZ). Para definir uma regra para rotear todos os pedidos HTTP externos para
um servidor HTTP dedicado no endereço IP 10.0.4.2 e porta 80 (fora do intervalo 192.168.1.0/24 da
LAN), a tradução de endereço de rede (NAT) evoca a tabela PREROUTING para encaminhar os pacotes
para o destino apropriado:
73
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT \
--to-destination 10.0.4.2:80
Com este comando, todas as conexões HTTP para a porta 80 de fora da LAN são roteadas ao servidor
HTTP em uma rede separada do resto da rede interna. Esta forma de segmentação de rede pode ser
mais segura que permitir conexões HTTP para uma máquina na rede. Se o servidor HTTP estiver
configurado para aceitar conexões seguras, então a porta 443 deve ser encaminhada também.
7.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é a
nódulos específicos, dentro de uma LAN. Você também pode restringir que determinados serviços
dúbios, como trojans, vermes, e outros vírus de clientes/servidor, contatem seu servidor. Por exemplo:
há alguns trojans que scaneam redes para serviços nas portas de 31337 a 31340 (chamadas portas
de elite na linguagem dos crackers). Como não há serviços legítimos que comunicam através destas
portas fora do padrão, bloqueá-los pode diminuir efetivamente as chances de nódulos potencialmente
infectados em sua rede se comunicarem independentemente com seus servidores mestres remotos.
iptables -A OUTPUT -o eth0 -p tcp --dport 31337 --sport 31337 -j DROP
iptables -A FORWARD -o eth0 -p tcp --dport 31337 --sport 31337 -j DROP
Você também pode bloquear as conexões externas que tentam espionar intervalos de endereços IP
privados a fim de infiltrarem em sua LAN. Por exemplo: se uma LAN usa o intervalo 192.168.1.0/24,
uma regra pode determinar que o dispositivo de rede que faz a interface com a Internet (eth0, por
exemplo) derrube quaisquer pacotes parta este dispositivo com um endereço do intervalo de IP de sua
LAN. Como norma default, é recomendado rejeitar pacotes encaminhados, portanto qualquer outro
endereço IP espionado ao dispositivo que faz a interface externa (eth0) será rejeitado automaticamente.
iptables -A FORWARD -s 192.168.1.0/24 -i eth0 -j DROP
7.7. IP6Tables
A introdução do Protocolo de Internet de última geração chamado IPv6, vai além do limite de endereços de 32 bits do IPv4 (ou IP). IPv6 suporta endereços de 128 bits e, como tal, redes de transporte
cientes do IPv6 são capazes de lidar com um número maior de endereços roteáveis que o IPv4.
O Red Hat Enterprise Linux suporta regras de firewall IPv6 usando o sub-sistema Netfilter 6 e o
comando IP6Tables. O primeiro passo para usar o IP6Tables é iniciar o serviço IP6Tables. Isto pode
ser feito com o comando:
service ip6tables start
Atenção
Os serviços IPTables devem ser desligados para usar o serviço IP6Tables exclusivamente:
service iptables stop
chkconfig iptables off
Para fazer com que o IP6Tables inicie por default sempre que o sistema for inicializado, altere o status
do nível de execução (runlevel) do serviço usando chkconfig.
74
chkconfig --level 345 ip6tables on
A sintaxe é idêntica à do IPTables em todos os aspectos, exceto pelo fato do IP6Tables suportar
endereços de 128 bits. Por exemplo: conexões SSH em um servidor de rede ciente do IPv6 pode ser
possibilitada pela seguinte regra:
ip6tables -A INPUT -i eth0 -p tcp -s 3ffe:ffff:100::1/128 --dport 22 -j ACCEPT
Para mais informações sobre redes com IPv6, consulte a página de informações sobre o IPv6:
http://www.ipv6.org/.
7.8. Recursos Adicionais
Há diversos aspectos do firewall e do sub-sistema Netfilter do Linux que não foram abordados 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 e
no 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 relacionados à criação e administração do firewall.
•
http://www.iana.org/assignments/port-numbers — A lista oficial de portas de serviços comuns conforme 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 construçã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 Intrusã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 rede
a ferramentas de cracking, um administrador pode aprender mais sobre a proteção de um sistema e de
uma rede, crackeando-os.
Índice
8. Avaliação de Vulnerabilidade....................................................................................................... 77
Capítulo 8.
Avaliação de Vulnerabilidade
Dados o tempo, os recursos e a motivação, um cracker pode violar praticamente qualquer sistema.
No final das contas, todos os procedimentos e tecnologias de segurança atualmente disponíveis não
podem garantir que seus sistemas estão seguros contra uma intrusão. Roteadores podem ajudar a proteger suas portas de comunicação (gateways) com a Internet. Firewalls ajudam a proteger a fronteira da
rede. Redes Privadas Virtuais (Virtual Private Networks - VPNs) podem transferir dados seguramente
através de informações criptografadas. Sistemas de detecção de intrusão podem alertá-lo sobre atividades maléficas. No entanto, o sucesso de cada uma destas tecnologias depende de diversas variáveis,
incluindo:
•
O conhecimento dos funcionários responsáveis pela configuração, monitoramento e manutenção
das tecnologias
•
A habilidade em consertar e atualizar eficiente e rapidamente os serviços e os kernels.
•
A habilidade dos responsáveis em manter vigília constante sobre a rede.
Dado o dinamismo de sistemas e tecnologias de dados, proteger recursos corporativos pode ser bastante complexo. Devido essa complexidade, geralmente é difícil encontrar peritos para todos os seus
sistemas. Enquanto é possível ter pessoal com conhecimento em muitas áreas de segurança da informação em um alto nível, é difícil reter funcionários que são peritos em mais do que algumas áreas.
Isto ocorre principalmente porque cada área da Segurança da Informação requer constante atenção e
foco. A segurança da informação não pára.
8.1. Pensando Como o Inimigo
Suponha que você administre uma rede corporativa. Essas redes são comumente compostas de sistemas operacionais, aplicações, servidores, monitores de rede, firewalls, sistemas de detecção de intrusão e outros. Agora imagine tentar manter-se atualizado com cada um destes. Dada a complexidade
dos softwares e ambientes de rede atuais, exploits e erros são uma certeza. Manter-se informado sobre consertos e atualizações para uma rede inteira pode ser uma tarefa perturbadora em uma grande
empresa com sistemas heterogêneos.
Mesmo combinando os requerimentos de conhecimento com a tarefa de manter-se atual, é inevitável que incidentes adversos ocorram, sistemas sejam violados, dados corrompidos e serviços sejam
interrompidos.
Para aprimorar as tecnologias de segurança e auxiliar na proteção de sistemas, redes e dados, pense
como um cracker e meça a segurança dos sistemas verificando suas fraquezas. Avaliações preventivas
de vulnerabilidade em seus prórprios sistemas e recursos de rede podem revelar questões potenciais a
serem consideradas antes de um cracker explorá-las.
Uma avaliação de vulnerabilidade é uma auditoria interna da segurança de sua rede e sistemas, cujos
resultados indicam a confidencialidade, integridade e disponibilidade de sua rede (conforme explanado na Seção 1.1.4). Uma avaliação de vulnerabilidade tipicamente começará com uma fase de reconhecimento, durante a qual são coletados dados importantes referentes à rede e aos sistemas alvo. Esta
fase levará à fase de prontidão do sistema, onde o alvo é checado em todas as suas vulnerabilidades
conhecidas. A fase de prontidão culmina na fase do relatório, na qual os resultados são classificados
em alto, médio e baixo risco, e métodos são discutidos para melhorar a segurança (ou para minimizar
o risco de vulnerabilidade) do alvo.
Se tivesse que executar uma avaliação de vulnerabilidade da sua casa, você provavelmente verificaria
cada uma das portas para certificar-se de que elas estão fechadas e trancadas. Você também checaria
todas as janelas, assegurando que estão completamente fechadas e corretamente travadas. O mesmo
78
Capítulo 8. Avaliação de Vulnerabilidade
conceito se aplica aos sistemas, redes e dados eletrônicos. Usuários maldosos são os ladrões e vândalos de seus dados. Foque em suas ferramentas, mentalidade e motivações, e você poderá reagir
rapidamente às suas ações.
8.2. Definindo Avaliação e Testes
As avaliações de vulnerabilidade podem ser divididas em dois tipos: Olhando de fora para dentro e
olhando de dentro ao redor.
Ao executar uma avaliação de vulnerabilidade olhando de fora para dentro, você está tentando comprometer seus sistemas de fora. Estando fora de sua empresa lhe proporciona ter o ponto de vista de
um cracker. Você vê o que o cracker vê — endereços IP publicamente roteáveis, sistemas em seu
DMZ, 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 sua
empresa lhe proporciona privilégios — mais elevados que qualquer externo. Ainda hoje em algumas
empresas, a segurança é configurada de modo a manter os intrusos de fora. Muito pouco é feito para
proteger os internos da empresa (tais como firewalls departamentais, controles de acesso em nível de
usuário, procedimentos de autenticação para recursos internos e outros). Geralmente, há muito mais
recursos quando olhamos de dentro ao redor dado que a maioria dos sistemas são internos a uma
empresa. Uma vez que você se coloca fora da empresa, imediatamente terá o status não confiável. Os
sistemas e recursos disponíveis a você externamente são tipicamente mais limitados.
Considere a diferença entre as avaliações de vulnerabilidade e testes de penetração. Pense em uma
avaliação de vulnerabilidade como o primeiro passo de um teste de penetração. As informações obtidas na avaliação serão utilizadas nos testes. Enquanto a avaliação verifica buracos e potenciais vulnerabilidades, 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 e
física, é dinâmica. Executar uma avaliação traz uma visão geral, que pode incluir falsos positivos e
falsos negativos.
Administradores de segurança são tão bons quanto as ferramentas que usam e o conhecimento que
possuem. Pegue qualquer uma das ferramentas de avaliação disponíveis, execute-as em seu sistema, e
é quase certeza que haja pelo menos alguns falsos positivos. O resultado é o mesmo, seja por erro no
programa 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 (falsos
negativos).
Agora que a diferença entre avaliação de vulnerabilidade e teste de penetração está definida, é recomendá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 na
produtividade 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
•
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
79
8.2.1. Estabelece uma Metodologia
Para auxiliar na selação de ferramentas para a avaliação de vulnerabilidade, é útil estabelecer uma metodologia de avaliação de vulnerabilidade. Infelizmente, não há nenhuma metodologia pré-definida ou
aprovada pela indústria no momento, porém bom senso e as melhores práticas podem agir suficientemente 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ão
a 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 Methodology
Manual (O Manual de Metodologia de Testes de Segurança Open Source) - OSSTMM
•
http://www.owasp.org/ — The Open Web Application Security Project (O Projeto Livre de Segurança de Aplicações Web)
8.3. Avaliando as Ferramentas
Uma 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 estejam
rodando. Após localizá-las, examine cada máquina separadamente. Focar nestas máquinas requer um
outro conjunto de ferramentas. Saber quais ferramentas utilizar deve ser o passo mais crucial para
achar vulnerabilidades.
Assim como em qualquer aspecto do cotidiano, há muitas ferramentas que desempenham a mesma
função. Este conceito também se aplica à execução das avaliações de vulnerabilidade. Há ferramentas
específicas para sistemas operacionais, para aplicações e até mesmo para redes (baseadas nos protocolos utilizados). Algumas ferramentas são grátis e outras não. Algumas ferramentas são intuitivas e
fáceis de utiulizar, enquanto outras são obscuras e mal documentadas, mas possuem funcionalidades
que 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 os
pontos fortes e fracos de cada uma. Reveja o arquivo README ou a página man da ferramenta.
Adicionalmente, procure na Internet por mais informações, como artigos, manuais passo-a-passo ou
até mesmo listas de discussão específicas da ferramenta.
As ferramentas explanadas abaixo são apenas uma pequena amostra das ferramentas disponíveis.
8.3.1. Scaneando Máquinas com Nmap
Nmap é uma ferramenta conhecida no Red Hat Enterprise Linux que pode ser usada para determinar
o layout de uma rede. O Nmap está disponível por muitos anos e provavelmente é a ferramenta mais
utilizada na coleta de informações. Foi inclusa uma página man excelente, que oferece uma descrição
detalhada de suas opções e usos. Administradores podem usar o Nmap em uma rede para encontrar
sistemas hospedeiros e portas abertas nestes sistemas.
O Nmap é um primeiro passo eficaz na avalização de vulnerabilidade. Você pode mapear todas as
máquinas dentro de uma rede, e inclusive passar uma opção que a permite tentar identificar o sistema
80
operacional rodando em determinada máquina. O Nmap é uma boa base para estabelecer normas de
uso de serviços seguros e para parar serviços não usados.
8.3.1.1. Usando o Nmap
O Nmap pode ser executado a partir de uma janela de comandos. Em uma janela de comandos, digite
nmap seguido do nome da máquina ou endereço IP da máquina que você deseja scanear.
nmap foo.example.com
Os resultados do scan (que podem levar até alguns minutos, dependendo de onde a m’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
Service
22/tcp
open
ssh
25/tcp
open
smtp
111/tcp
open
sunrpc
515/tcp
open
printer
950/tcp
open
oftep-rpc
6000/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. Nessus
Nessus é um scanner de segurança ’full-service’. A arquitetura plug-in do Nessus permite que usuários personalizem-no para seus sistemas e redes. Assim como qualquer scanner, Nessus é tão bom
quanto a assinatura do banco de dados no qual ele se baseia. Felizmente, Nessus é frequentemente
atualizado. Suas funcionalidades incluem relatório completo, scanning da máquina e busca de vulnerabilidades em tempo real. Lembre-se que pode haver falsos positivos e falsos negativos, mesmo com
uma 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 documento como uma referência para usuários que possam se interessar por esta aplicação tão conhecida.
Para mais informações sobre o Nessus, consulte o site oficial no seguinte endereço:
http://www.nessus.org/
81
8.3.3. Nikto
O Nikto é um scanner CGI excelente. Nikto não tem apenas a capacidade de verificar vulnerabilidades
CGI, mas também de fazê-lo de maneira evasiva, para enganar sistemas de detecção de intrusão.
Acompanha uma documentação excelente que dever ser revisada cuidadosamente antes de executar
o programa. Quando você encontrar seus servidores Web servindo scripts CGI, o Nikto pode ser um
excelente recurso para checar a segurança destes servidores.
Nota
O Nikto não está incluso no Red Hat Enterprise Linux e não é suportado. Foi incluso neste documento como uma referência para usuários que possam se interessar por esta aplicação tão conhecida.
Mais informações sobre o Nikto podem ser encontradas na seguinte URL:
http://www.cirt.net/code/nikto.shtml
8.3.4. VLAD the Scanner
O VLAD é um scanner desenvolvido pela equipe RAZOR da Bindview, Inc., que pode ser usado
para checar vulnerabilidades. Ele procura pela lista das dez questões mais comuns de segurança da
SANS (questões do SNMP, questões de compartilhamento de arquivo, etc). Apesar de não ter tantas
funcionalidades quanto o Nessus, vale a pena investigar o VLAD.
Nota
O VLAD não está incluso no Red Hat Enterprise Linux e não é suportado. Foi incluso neste documento como uma referência para usuários que possam se interessar por esta aplicação tão conhecida.
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 Futuras
Dependendo do seu alvo e recursos, há muitas ferramentas disponíveis. Há ferramentas para redes
sem fio, redes Novell, sistemas Windows, sistemas Linux e outros. Outra parte essencial ao executar
avaliações deve incluir a revisão da segurança física, cobertura de pessoal ou avaliação de rede por
voz/PABX. Conceitos emergentes como o war walking — scanning do perímetro das estruturas físicas
de sua empresa para vulnerabilidades de rede sem fio — podem ser investigados e incorporados às
suas avaliações, se necessário. Imaginação e exposição são os únicos limites para planejar e conduzir
avaliações de vulnerabilidade.
82
IV. Intrusões e Resposta a Incidentes
É inevitável uma rede sofrer intrusões ou o uso maléfico de seus recursos. Esta parte aborda algumas
medidas pró-ativas que um administrador pode tomar para evitar quebras na segurança, tais como
formar uma equipe de resposta a emergências, capaz de responder rápida e efetivamente a questões
de segurança. Além disso, esta parte também detalha os passos a tomar para agupar e analisar as
evidências de uma quebra na segurança após o fato ter ocorrido.
Índice
9. Detecção de Invasão ...................................................................................................................... 85
10. Resposta ao Incidente ................................................................................................................. 91
Capítulo 9.
Detecção de Invasão
Uma propriedade de valor necessita de proteção contra ações de roubo e destruição. Algumas casas
são equipadas com sistemas de alarme capazes de deter ladrões, notificar as autoridades na ocasião de
uma invasão e inclusive alertar o proprietário quando sua casa estiver sendo incendiada. Tais medidas
são necessárias para assegurar a integridade das casas e a segurança de seus proprietários.
A mesma garantia de integridade e segurança também deve ser aplicada a sistemas de dados e computadores. A Internet facilitou o fluxo de informações, tanto pessoais como financeiras. Ao mesmo
tempo, também deu margem a muitos perigos. Usuários maléficos e crackers procuram alvos vulneráveis como sistemas não seguros, sistemas infectados com vírus trojans e redes rodando serviços não
seguros. São necessários alarmes para notificar os administradores e membros da equipe de segurança
que uma intrusão ocorreu para que eles possam agir em tempo real contra tal intrusão. Sistemas de
detecção de intrusão foram elaborados para agirem como este sistema de alerta.
9.1. Definindo Sistemas de Detecção de Intrusão
Um sistema de detecção de intrusão (intrusion detection system, IDS) é um processo ou dispositivo
ativo que analisa as atividades do sistema e da rede e identifica entradas não autorizadas e/ou atividades maléficas. A maneira como um IDS detecta anomalias pode variar amplamente; no entanto, o
objetivo final de qualquer IDS é capturar os infratores na ação antes de realmente danificarem seus
recursos.
Um IDS protege um sistema de ataques, mal-uso e danos. Também pode monitorar as atividades da
rede, auditorar as configurações da rede e do sistema para detectar vulnerabilidades, analisar integridade 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 IDS
Entender 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 os
conceitos por trás dos IDSs, as funcionalidades de cada tipo de IDS e a emergência de IDSs híbridos
que aplicam diversas técnicas de detecção e ferramentas em um pacote.
Alguns IDSs são baseados no conhecimento, que alertam prioritariamente os administradores de segurança antes de uma intrusão ocorrer utilizando um banco de dados de ataques comuns. Alternativamente, há alguns IDS comportamentais que rastreiam todos os usos de recursos para encontrar
anomalias, 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, registrando
quaisquer 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 em
criar um kit de detecção de intrusão poderoso. Avaliar as diferentes técnicas de detecção pode ajudar
a encontrar uma que seja correta para sua organização.
9.2. IDS baseado no servidor
Um IDS baseado na máquina analisa diversas áreas para determinar o mal-uso (atividades maléficas
ou truculentas dentro da rede) ou intrusão (incursões de fora). IDSs baseados na máquina consultam
diversos tipos de arquivos de registro (kernel, sistema, servidor, rede, firewall e outros) e comparam
os registros a um banco de dados interno com assinaturas comuns de ataques conhecidos. IDSs UNIX
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 eventos
registrados por sua severidade (por exemplo: pequenas mensagens de impressão versus sérios alertas
do kernel). O IDS baseado na máquina filtra os registros (que, no caso de alguns eventos da rede e
do kernel, podem ser bastante verbalizados), analisa-os, renomeia as mensagens anômalas com sua
própria classificação de severidade e os agrupa em seu próprio registro especializado para análise do
adminstrador.
IDSs baseados na máquina também podem verificar a integridade dos dados de arquivos importantes
e executáveis. Checam um banco de dados de arquivos importantes (e quaisquer arquivos adicionados
pelo administrador) e criam um checksum de cada arquivo com uma utilidade de verificação de consistência de arquivo de mensagem como a md5sum (algoritmo de 128 bits) ou a sha1sum (algoritmo
de 160bits). Então, o IDS baseado na máquina armazena as consistências em um arquivo somente
texto e compara periodicamente a verificação de consistência aos valores do arquivo texto. Se alguma das consistências não bater, o IDS alerta o administrador via e-mail ou pager do celular. Este é o
procedimento utilizado pelo Tripwire, explanado na Seção 9.2.1.
9.2.1. Tripwire
O Tripwire é o IDS do Linux baseado na máquina mais conhecido. A Tripwire, Inc., empresa dos
desenvolvedores do Tripwire, recentemente divulgou o código-fonte do software para a versão Linux
e o licenciou sob os termos da GNU General Public License. O Tripwire está disponível no site
http://www.tripwire.org/.
Nota
O Tripwire não está incluso no Red Hat Enterprise Linux e não é suportado. Foi incluso neste documento como uma referência para usuários que possam se interessar pelo uso desta aplicação
conhecida.
9.2.2. RPM como um IDS
O Gestor de Pacotes RPM (RPM) é outro programa que pode ser utilizado como um IDS baseado
no servidor. O RPM contém várias opções para investigar pacotes e seus conteúdos. Estas opções de
verificação podem ser muito preciosas para um administrador ao suspeitar que arquivos críticos do
sistema e executáveis foram modificados.
A lista seguinte traz algumas opções para RPMs que podem verificar a integridade de arquivos em
um sistema Red Hat Enterprise Linux. Consulte o Guia de Administração do Sistema do Red Hat
Enterprise Linux para informações completas sobre o uso do RPM.
Importante
Alguns dos comandos da lista seguinte requerem a importação da chave pública GPG da Red Hat
para o chaveiro RPM do sistema. Esta chave verifica se os pacotes instalados em seu sistema
contêm uma assinatura de pacote da Red Hat, o que assegura que seus pacotes foram originados
da 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
87
rpm -V nome_do_pacote
A opção -V verifica os arquivos do pacote instalado chamado nome_do_pacote. Se não exibir
nenhum output e fechar, isto significa que nenhum dos arquivos foi modificado de maneira alguma desde a última vez em que o banco de dados RPM foi atualizado. Se houver algum erro,
como
S.5....T c /bin/ps
então o arquivo foi modificado de alguma maneira e você deve decidir entre guardar o arquivo
(como é o caso de arquivos de configuração modificados no diretório /etc/) ou apagar o arquivo e reinstalar o pacote que o contém. A lista a seguir define os elementos do conjunto de 8
caracteres (S.5....T no exemplo acima) que notifica uma falha de verificação.
• .
— O teste passou esta fase da verificação
— O teste encontrou um arquivo que não pôde ser lido, o que provavelmente é uma questão
de permissão do arquivo
• ?
— O teste encontrou um arquivo menor ou maior do que era ao ser originalmente instalado
no sistema
• S
— O teste encontrou um arquivo cuja verificação de consistência (checksum) md5 não coincide com a consistência original do arquivo instalado pela primeira vez
• 5
• 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 verificação (parecida com a opção -V, só que seu output é mais verbalizado já que está verificando
cada pacote instalado).
rpm -Vf /bin/ls
A opção -Vf verifica arquivos individualmente em um pacote instalado. Ela pode ser útil ao
desempenhar uma verificação rápida em um arquivo suspeito.
rpm -K aplicação-1.0.i386.rpm
A opção -K é útil para checar a consistência (md5 checksum) e a assinatura GPG de um arquivo
de pacote RPM. Pode ser utilizada para verificar se um pacote prestes a ser instalado é assinado
pela Red Hat ou por qualquer organização para a qual você tenha a chave pública GPG importada
para um chaveiro GPG. Um pacote que não tenha sido assinado apropriadamente emitirá uma
mensagem de erro similar à seguinte:
application-1.0.i386.rpm (SHA1) DSA sha1 md5 (GPG) NOT OK
(MISSING KEYS: GPG#897da07a)
Tenha cuidado ao instalar pacotes não assinados já que não são aprovados pela Red Hat, Inc. e
podem conter código maléfico.
O RPM pode ser uma ferramenta poderosa, como evidenciado por suas diversas ferramentas de verificaçã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
88
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 dados
do sistema, já que usuários mal-intencionados podem corromper o banco de dados e desviar seus
resultados.
9.2.3. IDSs baseados em outros servidores
A lista a seguir aborda alguns dos outros sistemas de detecção de intrusão baseados na máquina.
Consulte os sites dos respectivos utilitários para mais informações sobre sua instalação e configuração.
Nota
Estas aplicações não estão inclusas no Red Hat Enterprise Linux e não são suportadas. Elas foram
inclusas neste documento como referência para usuários interessados em avaliá-las.
•
SWATCH http://www.stanford.edu/~atkins/swatch/ — O WATCHer Simples (SWATCH) utiliza arquivos de registro gerados pelo syslog para alertar administradores sobre anomalias baseado em
arquivos de configuração do usuário. SWATCH foi desenvolvido para registrar qualquer evento que
o usuário queira adicionar ao arquivo de configuração; no entanto, tem sido amplamente adotado
como um IDS baseado em servidor.
•
LIDS http://www.lids.org — O Sistema de Detecção de Intrusão Linux (Linux Intrusion Detection
System), LIDS, é um conserto do kernel e uma ferramenta de administração também capaz de
controlar modificações de arquivo com listas de controle de acesso (access control lists), ACLs, e
proteger processos e arquivos, inclusive do usuário root.
9.3. IDS baseado em rede
Sistemas de detecção de intrusão baseados em rede operam de maneira diferente aos IDSs baseados
em servidor. A filosofia de desenvolvimento de um IDS baseado em rede é scanear os pacotes da
rede no nível do servidor ou roteador, auditorando informações de pacotes e registrando quaisquer
pacotes suspeitos em um arquivo de registro especial com informações extras. Baseado nestes pacotes
suspeitos, um IDS baseado em rede pode scanear seu próprio banco de dados de assinaturas de ataques
de rede conhecidas e determinar um nível de severidade para cada pacote. Se os níveis de severidade
forem suficientemente altos, um email de alerta ou mensagem de celular será enviada aos membros
da equipe de segurança para que eles possam investigar a natureza da anomalia.
IDSs baseados em rede tornaram-se populares com o crescimento da Internet em tamanho e tráfego.
IDSs que podem scanear a volumosa quantidade de atividade de rede e nomear com êxito as transmissões suspeitas são bem recebidos na indústria da segurança. Devido à insegurança inerente de
protocolos TCP/IP, tornou-se obrigatório o desenvolvimento de scanners, sniffers e outras ferramentas de auditoria e detecção de rede para prevenir brechas de segurança devido às maléficas ativiidades
de 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
•
89
Ataques ’man-in-the-middle’
A maioria dos IDSs baseados em rede requerem que o dispositivo de rede do servidor do sistema
seja configurado para o modo promíscuo, que permite o dispositivo a capturar todos os pacotes que
passam na rede. O modo promíscuo pode ser configurado através do comando ifconfig, conforme
o seguinte:
ifconfig eth0 promisc
Executando ifconfig sem opções revela que eth0 agora está no modo promíscuo (PROMISC).
eth0
Link encap:Ethernet HWaddr 00:00:D0:0D:00:01
inet addr:192.168.1.50 Bcast:192.168.1.255 Mask:255.255.252.0
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
RX packets:6222015 errors:0 dropped:0 overruns:138 frame:0
TX packets:5370458 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:2505498554 (2389.4 Mb) TX bytes:1521375170 (1450.8 Mb)
Interrupt:9 Base address:0xec80
lo
Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:21621 errors:0 dropped:0 overruns:0 frame:0
TX packets:21621 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1070918 (1.0 Mb) TX bytes:1070918 (1.0 Mb)
Ao utilizar uma ferramenta como o tcpdump (incluso no Red Hat Enterprise Linux), é possível visualizar o tráfego intenso fluindo por uma rede:
tcpdump: listening on eth0
02:05:53.702142 pinky.example.com.ha-cluster > \
heavenly.example.com.860: udp 92 (DF)
02:05:53.702294 heavenly.example.com.860 > \
pinky.example.com.ha-cluster: udp 32 (DF)
02:05:53.702360 pinky.example.com.55828 > dns1.example.com.domain: \
PTR? 192.35.168.192.in-addr.arpa. (45) (DF)
02:05:53.702706 ns1.example.com.domain > pinky.example.com.55828: \
6077 NXDomain* 0/1/0 (103) (DF)
02:05:53.886395 shadowman.example.com.netbios-ns > \
172.16.59.255.netbios-ns: NBT UDP PACKET(137): QUERY; BROADCAST
02:05:54.103355 802.1d config c000.00:05:74:8c:a1:2b.8043 root \
0001.00:d0:01:23:a5:2b pathcost 3004 age 1 max 20 hello 2 fdelay 15
02:05:54.636436 konsole.example.com.netbios-ns > 172.16.59.255.netbios-ns:\
NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
02:05:56.323715 pinky.example.com.1013 > heavenly.example.com.860:\
udp 56 (DF)
02:05:56.323882 heavenly.example.com.860 > pinky.example.com.1013:\
udp 28 (DF)
Note que pacotes não intencionados para a nossa máquina (pinky.example.com) ainda estão sendo
scaneados e registrados pelo tcpdump.
90
9.3.1. Snort
Apesar do tcpdump ser uma ferramenta de auditoria importante, não é considerado um IDS verdadeiro porque não analisa e aponta anomalias nos pacotes. Ao invés disso, o tcpdump exibe todas
as informações dos pacotes na tela de output ou em um arquivo de registro sem análise nenhuma.
Um IDS apropriado analisa os pacotes, aponta ransmissões de pacotes potencialmente maléficas e as
armazena em um registro formatado.
O Snort é um IDS desenvolvido para ser compreensivo e correto em registrar com êxito as atividades
maléficas da rede e notificar os administradores quando potenciais brechas ocorrerem. Snort utiliza a
biblioteca padrão libcap e o tcpdump como um registro especializado de pacotes.
A característica mais premiada do Snort, somada à sua funcionalidade, é o seu sub-sistema flexível
de assinaturas de ataque. Snort tem um banco de dados de ataques constantemente atualizado
que pode ser adicionado à ou atualizado via Internet. Os usuários podem criar assinaturas
baseadas em novos ataques de rede e enviá-las às listas de discussão de assinaturas do Snort
(http://www.snort.org/lists.html), para beneficiar todos os usuários do Snort. Essa ética comunitária
em compartilhar elevou o Snort a um dos IDSs mais atualizados e robustos disponíveis no mercado.
Nota
O Snort não esta incluso no Red Hat Enterprise Linux e não é suportado. Ele foi incluso neste
documento como referência para usuários interessados em avaliá-lo.
Para mais informações sobre o uso do Snort, consulte o site oficial: http://www.snort.org.
Capítulo 10.
Resposta ao Incidente
No caso da segurança de um sistema ter sido comprometida, uma resposta ao incidente se faz necessária. É responsabilidade da equipe de segurança responder ao problema rapida e efetivamente.
10.1. Definindo Resposta ao Incidente
A resposta ao incidente é uma reação expedida a uma questão ou ocorrência de segurança. Pertinente
à segurança da informação, um exemplo seria as ações da equipe de segurança contra um hacker que
penetrou um firewall e está bisbilhotando o tráfego da rede interna. O incidente é uma infração da
segurança. A resposta depende de como a equipe de segurança reage, o que ela faz para mininmizar
os danos e quando recupera os recursos; tudo isso enquanto tenta garantir a integridade dos dados.
Pense na sua empresa e em como quase todos os aspectos dela dependem de tecnologia e sistemas
de computador. Se houver um comprometimento, imagine os resultados potencialmente devastadores.
Além do tempo em que o sistema ficará fora do ar e o roubo de dados, pode haver corrupção de dados,
roubo de identidade (a partir de registros pessoais online), má publicidade, ou até mesmo resultados
financeiros devastadores enquanto clientes e empresas aprendem a reagir negativamente na ocorrência
de comprometimento.
Pesquisas sobre as infrações anteriores na segurança (tanto internas quanto externas) mostram que
algumas empresas podem até ser fechadas como resultado de uma grave infração de segurança. Uma
infração pode tornar recursos indisponíveis e roubar ou corromper dados. Mas é muito difícil estimar
financeiramente os danos como má publicidade. Para ter uma idéia exata do quão importante é uma
resposta eficiente a um incidente, uma empresa deve calcular o custo de uma infração e também os
efeitos financeiros da publicidade negativa, a curto e longo prazo.
10.2. Criando um Plano de Resposta ao Incidente
É importante que um plano de resposta ao incidente seja formulado, apoiado através da empresa e
regularmente testado. Um bom plano de resposta ao incidente pode minimizar não somente os efeitos
de uma infração na segurança, 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 eventuais transações usando um meio de rede não confiável, como a Internet), mas sim, quando uma infração
ocorre. Não pense em um sistema como fraco e vulnerável; é importante perceber que quando há tempo e recursos suficientes alguém violará até mesmo o sistema ou rede mais super-protegido. Não é
necessário consultar nada além do site Security Focus em http://www.securityfocus.com para obter informações detalhadas e atualizadas sobre as recentes infrações e vulnerabilidades de segurança, desde
a destruição frequente de páginas web corporativas até os ataques aos servidores DNS em 2002 1.
O aspecto positivo de perceber a inevitabilidade de uma infração do sistema é que ela permite à equipe
de segurança desenvolver um curso das ações que minimizem qualquer dano potencial. Combinar o
curso das ações com habilidades permite à equipe responder a condições adversas de uma maneira
formal e responsável.
O plano de resposta ao incidente pode ser dividido em quatro fases:
•
Ação imediata para interromper ou minimizar o incidente
•
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 para
erros, é essencial que as práticas de emergência sejam ensaiadas e os tempos de resposta medidos.
Desta maneira, é possível desenvolver uma metodologia que estimule a velocidade e a acuracidade,
minimizando o impacto da indisponibilidade de recursos e os potenciais danos causados pelo comprometimento 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 Computer
Emergency Response Team - CERT)
O termo Equipe de Resposta às Emergências de Computador (Computer Emergency Response Team
- CERT) refere-se a um grupo de peritos internos preparados para agir rapidamente no caso de uma
situação catastrófica com computadores. Encontrar as competências cruciais para uma CERT pode ser
um desafio. O conceito de pessoal apropriado vai além das habilidades técnicas e inclui questões de
logística, como localização, disponibilidade e desejo de colocar a empresa à frente da vida pessoal
quando uma emergência ocorre. Uma emergência nunca é um evento planejado; pode acontecer a
qualquer momento e todos os membros da CERT devem aceitar a responsabilidade de responder a
uma emergência a qualquer hora.
Os típicos integrantes de uma CERT incluem adminsitradores de sistemas e de rede, assim como
peritos em segurança das informações. Os administradores de sistema proverão o conhecimento e
habilidades dos recursos do sistema, inclusive backups de dados, backup de hardware disponível para
uso e outros. Administradores de rede proverão seu conhecimento de protocolos de rede e a habilidade
em redirecionar o tráfego de rede dinamicamente. O pessoal de segurança da informação é útil para
rastrear e investigar detalhadamente as questões de segurança assim como para analisar os sistemas
comprometidos após a ocorrência.
Nem sempre é possível, mas deve haver redundância no pessoal de uma CERT. Se não for viável
ter uma área especializada na empresa, então deve haver treinamento para outras áreas sempre que
possível. Lembre-se que se somente uma pessoa tiver as informações cruciais para a segurança e
integridade dos dados, então a organização inteira ficará desamparada na ausência desta pessoa.
10.2.2. Considerações Legais
Alguns aspectos importantes da resposta ao incidente a considerar são as questões legais. Planos
de segurança devem ser desenvolvidos juntamente aos membros da área jurídica ou algum tipo de
conselho geral. Assim como toda empresa deve ter sua própria política de segurança corporativa, toda
empresa tem sua própria maneira de lidar com incidentes sob a perspectiva legal. Questões regulatórias
em nível local, estadual e federal vão além do escopo deste documento, mas são mencionadas pois
a metodologia de análise post-mortem será ditada, pelo menos em parte (ou em conjunto com), pelo
conselho jurídico. O conselho geral pode alertar o pessoal técnico das ramificações legais das infrações
de segurança, os perigos de registros pessoais, médicos ou financeiros de um cliente vazarem, e a
importância de restaurar os serviços em ambiente críticos como hospitais e bancos.
93
10.3. Implementando o Plano de Resposta ao Incidente
Após um plano de ação ser criado, ele deve ser consentido e implementado ativamente. Qualquer aspecto do plano que seja questionado durante a implementação ativa pode resultar numa resposta lenta
e longo período fora do ar no evento de uma infração. Nestas circunstâncias os exercícios práticos são
muito valiosos. A menos que algo venha à tona antes do plano ser ativamente definido na produção,
a implementação deve ser consentida por todas as partes diretamente relacionadas e executada com
confiança.
Se uma infração for detectada enquanto a CERT estiver presente para rápida reação, as possíveis respostas podem variar. A equipe pode decidir desabilitar as conexões de rede, desligar os sistemas afetados, consertar o exploit e então reconectar rapidamente sem possíveis complicações futuras. A equipe
também pode monitorar os infratores e rastrear suas ações. A equipe pode, inclusive, redirecionar o
infrator para um pote de mel — um sistema ou segmento de rede contendo dados intencionalmente
falsos — para rastrear a invasão de maneira segura e sem interrupção dos recursos de produção.
A resposta a um incidente deve acompanhar também uma coleta de informações sempre que possível. A execução de processos, conexões de rede, arquivos, diretórios e outros devem ser auditados
ativamente em tempo real. Ter uma rápida impressão dos recursos de produção para comparação pode
ser útil ao rastrear serviços ou processos corrompidos. Os integrantes da CERT e os peritos internos
serão ;ótimos recursos para rastrear tais anomalias em um sistema. Administradores de sistemas sabem quais processos devem ou não aparecer ao executar os comandos top ou ps. Administradores
de rede estão cientes de como funciona o tráfego normal de rede ao executar o snort ou até mesmo
tcpdump. Estes integrantes da equipe devem conhecer seus sistemas e serem capazes de apontar uma
anomalia mais rapidamente do que alguém que não esteja familiarizado com a infra-estrutura.
10.4. Investigando o Incidente
Investigar uma infração de computador é como investigar a cena de um crime. Os detetives coletam
evidências, anotam quaisquer pistas estranhas e fazem um inventário de perdas e danos. Uma análise
do comprometimento dos computadores pode ser feita enquanto o ataque ocorre ou post-mortem (após
o ataque).
Apesar de não ser recomendável confiar em nenhum arquivo de registro de um sistema que sofreu
exploit, há outras utilidades forênsicas para auxiliar sua análise. O propósito e funções destas ferramentas variam, mas elas comumente criam pequenos ’arquivos-espelho’ da mídia, relacionam eventos
e processos, exibem informações simples do sistema de arquivo e recuperam arquivos apagados sempre que possível.
Também é recomendado registrar todas as ações investigativas de um sistema corrompido, usando o
comando script, conforme o exemplo a seguir:
script -q
D
B
file-name
C
E
Substitua file-name pelo nome do arquivo de registros do script. Sempre salve o arquivo de
registros em outra mídia que não o disco rígido do sistema comprometido — um disquete é uma boa
opçã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 for
pego.
10.4.1. Coletando uma Imagem Evidencial
Criar um pequeno ’arquivo-espelho’ da mídia é um primeiro passo razoável. Se estiver executando
trabalho forênsico de dados, é um requerimento. É recomendado fazer duas cópias: uma para análise
e investigação, e uma segunda para ser armazenada junto à original como evidência para quaisquer
procedimentos legais.
94
Você pode usar o comando dd, que é parte do pacote fileutils do Red Hat Enterprise Linux, para
criar uma imagem monolítica de um sistema que sofreu exploit como evidência em uma investigação,
ou para comparação com imagens confiáveis. Suponha que haja um único disco rígido no sistema que
você deseja criar a imagem. Anexe este disco como escravo ao sistema e então use o comando dd para
criar o arquivo imagem, conforme mostramos a seguir:
dd if=/dev/hdd bs=1k conv=noerror,sync of=/home/evidence/image1
Este comando cria um único arquivo chamado image1 usando o tamanho de um bloco de 1k para
velocidade. As opções conv=noerror,sync forçam o dd a continuar lendo e descarregando os dados
mesmo se encontrar setores danificados no disco suspeito. Agora é possível estudar o arquivo imagem
resultante ou até tentar recuperar arquivos apagados.
10.4.2. Coletando Informação Pós-Infração
O tópico forênsica e análise digital é bastante abrangente, mas as ferramentas são específicas para a
arquitetura em sua maioria e não podem ser aplicadas genericamente. Entretanto, resposta a indicentes, análise e recuperação são tópicos muito importantes. Utilizando o conhecimento e a experiência
apropriados, o Red Hat Enterprise Linux pode ser uma ótima plataforma para executar estes tipos de
análises já que inclui diversas funcionalidades para realizar a resposta e restauração pós-infração.
Tabela 10-1 descreve alguns comandos para auditoria e gerenciamento de arquivos. Também lista alguns exemplos que podem ser usados para identificar apropriadamente arquivos e seus atributos (tais
como permissões e datas de acesso) para que assim você possa coletar mais evidências ou ítens para
análise. Estas ferramentas, quando combinadas com sistemas de detecção de intrusão, firewalls, serviços seguros e outras medidas de segurança, podem ajudar a reduzir os danos potenciais na ocorrência
de um ataque.
Nota
Para informações detalhadas sobre cada ferramenta, consulte suas respectivas páginas man.
Comando
Função
Exemplo
dd
Cria uma pequena cópia da imagem
(ou disk dump) dos arquivos e
partições. Combinado à verificação
dos md5sums de cada imagem,
administradores podem comparar
uma imagem pré-infração de uma
partição ou arquivo com um sistema
que sofreu uma infração para
verificar se as consistências
coincidem.
dd if=/bin/ls of=ls.dd
|md5sum ls.dd >ls-sum.txt
95
Comando
Função
grep
Encontra trechos de informação
ps auxw |grep /bin
(texto) úteis dentro de arquivos e
diretórios, assim como revela
permissões, alterações de script,
atributos de arquivos e muito mais.
Utilizado na maioria das vezes como
um comando ’casado’ (piped) com
outro, como o ls, ps, ou o
ifconfig.
Exemplo
strings
Imprime os trechos de caracteres
imprimíveis em um arquivo. É mais
útil para examinar anomalias em
arquivos executáveis como
comandos mail para endereços
desconhecidos ou para registrar em
arquivos de registro fora do padrão.
file
Determina as características de
file /bin/ls
arquivos baseado no formato,
código, bibliotecas com as quais está
ligado (se houver) e tipo de arquivo
(binário, texto ou outros). É útil para
determinar se um executável como
/bin/ls foi modificado usando
bibliotecas estáticas, o que é um
sinal certeiro de que o executável foi
substituído por outro instalado por
um usuário maléfico.
find
Busca determinados arquivos em
diretórios. É uma ferramenta útil
para procurar na estrutura do
diretório por palavra-chave, data e
hora de acesso, permissões e outros
critérios. Também pode ser útil para
administradores que executam
auditorias gerais do sistema em
determinados arquivos ou diretórios.
stat
Exibe diversas informações sobre
stat /bin/netstat
um arquivo, inclusive a hora do
último acesso, permissões,
configurações UID (ID do usuário) e
GID (ID do grupo) e outras. Útil
para verificar quando um executável,
de um sistema que sofreu infração,
foi utilizado ou modificado pela
última vez.
strings /bin/ps |grep
’mail’
find -atime +12 -name *log*
-perm u+rw
96
Comando
Função
md5sum
Calcula o checksum (verificação de md5sum /usr/bin/gdm
consistência) de 128 bits usando o
>>md5sum.txt
algoritmo md5 hash. Use este
comando para criar um arquivo texto
que lista todos os executáveis
cruciais que são frequentemente
modificados ou substituídos em um
comprometimento da segurança.
Redirecione as somas para um
arquivo, a fim de criar um simples
banco de dados de consistências, e
então copie o arquivo para uma
mídia somente-leitura como um
CD-ROM.
Exemplo
Tabela 10-1. Ferramentas de Auditoria de Arquivos
10.5. Restaurando e Recuperando Recursos
Enquanto uma resposta ao incidente é executada, a equipe CERT deve investigar e trabalhar na recuperaçã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 de
produção.
É altamente recomendável ter hardware backup da produção pronto para uso, como drives extras, servidores avulsos e outros do gênero. Sistemas prontos devem ter todo o software de produção carregado
e pronto para uso imediato. Somente os dados mais recentes e pertinentes devem ser importados. Este
sistema pronto deve ser mantido separadamente do resto da rede. Se ocorrer um comprometimento e
o sistema de backup for parte da rede, então não há propósito em ter um sistema backup.
A recuperação do sistema pode ser um processo tedioso. Em muitos casos há dois cursos de ações
a escolher. Administradores podem executar uma nova instalação do sistema operacional em cada
sistema afetado, seguida da restauração de todas as aplicações e dados. Alternativamente, os administradores também podem consertar as vulnerabilidades penetradas e trazer o sistema afetado de volta à
produção.
10.5.1. Reinstalando o Sistema
Executar uma nova reinstalação assegura que o sistema afetado será limpo de quaisquer trojans, ’backdoors’ ou processos maléficos. A reinstalação também assegura que quaisquer dados (se recuperados
a partir de um backup confiável) estão livres de qualquer modificação maléfica. A desvantagem da
recuperação total do sistema é o tempo envolvido na reconstrução dos sistemas a partir do zero. No
entanto, se houver um bom sistema de backup disponível para uso, no qual a única ação a tomar é
carregar os dados mais recentes, então o downtime (tempo fora do ar) é reduzido drasticamente.
10.5.2. Consertando o Sistema (patching)
Consertar o sistema afetado é um curso de ações mais perigoso e deve ser executado com muita
atenção. O perigo de consertar um sistema ao invés de reinstalar é determinar se você realmente livrou
o sistema de trojans, buracos da segurança e dados corrompidos. A maioria dos rootkits (programas
97
ou pacotes usados por um cracker para obter acesso root em seu sistema), comandos de sistema trojan
e ambientes de janela de comandos são desenvolvidos para ocultar atividades maléficas de auditorias
superficiais. Se você optar pelo conserto, use somente binários confiáveis (ex.: a partir de um CDROM montado e somente-leitura).
10.6. Reportando o Incidente
A última parte do plano da resposta ao incidente é reportá-lo. A equipe de segurança deve tomar notas
enquanto a resposta estiver ocorrendo para reportar corretamente a questão às organizações, tais como
autoridades locais e federais, ou portais de multi-fabricantes de software, tal como o site ’Common
Vulnerabilities and Exposures’ (CVE) em http://cve.mitre.org. Dependendo do tipo de conselho jurídico aplicado pela sua empresa, uma análise post-mortem pode se fazer necessária. Mesmo se não
for um requisito funcional para uma análise do comprometimento, uma post-mortem pode ser muito
valiosa para entender como um cracker pensa e como seus sistemas estão estruturados, para assim
prevenir futuros comprometimentos.
98
V. Apêndices
Esta parte aborda algumas das maneiras mais comuns usadas por intrusos para quebrar a segurança de
sistemas de computador ou interceptar dados em trânsito. Esta parte também detalha alguns dos serviços mais utilizados e os números de suas portas associadas, que podem ser úteis a um administrador
que pretende atenuar os riscos de ter seus sistemas crackeados.
Índice
A. Proteção ao Hardware e à Rede................................................................................................ 101
B. Exploits Comuns e Ataques....................................................................................................... 107
C. 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 requisitos da maneira mais transparente possível. Já que o objetivo principal do Guia de Segurança do Red
Hat Enterprise Linux é explicar como proteger o Red Hat Enterprise Linux, um exame mais detalhado da segurança do hardware e da rede física está além do escopo deste documento. No entanto, este
capítulo apresenta uma breve visão geral do estabelecimento de políticas de segurança em relação a
hardware e redes físicas. Alguns fatores importantes a considerar incluem como os requisitos computacionais e de conectividade são endereçados na estratégia de segurança. A seguir, uma explicação
detalhada de alguns destes fatores.
•
Computação envolve mais do que somente estações de trabalho rodando software. Empresas modernas requerem um grande poder computacional e serviços de alta disponibilidade, que podem
incluir mainframes, clusters de aplicação ou de computador, estações de trabalho poderosas e aplicações especializadas. Com estes requisitos corporativos, entretanto, aumentou a propensão a falhas
de hardware, desastres naturais e a interfêrencias ou roubo de equipamento.
•
Conectividade é o método através do qual o administrador pretende conectar recursos díspares em
uma rede. Um administrador pode usar a Ethernet (cabeamento CAT-5/RJ-45 de hub ou de comutador), ’token ring’, cabo coaxial 10-base-2 ou mesmo tecnologias sem-fio (802.11x). Dependendo
do meio que o administrador escolher, determinadas mídias e tecnologias de rede requerem tecnologias complementares, como hubs, roteadores, comutadores, estações base e pontos de acesso. Determinar uma arquitetura de rede funcional facilitará o processo administrativo se surgirem questões
de segurança.
A partir destas considerações gerais, os administradores podem obter uma visão melhor da implementação. A estrutura de um ambiente computacional pode ser baseado em ambos, necessidades da
corporação e considerações de segurança — uma implementação que atenda uniformemente aos dois
fatores.
A.1. Topologias de Rede Segura
A fundação de uma LAN é a topologia ou arquitetura de rede. A topologia é o layout físico e lógico de uma LAN em termos de recursos providos, distância entre nódulos e meio de transmissão.
Dependendo das necessidades da empresa a qual a rede serve, há diversas opções disponíveis para a
implementação da rede. Cada topologia tem suas vantagens e questões de segurança que arquitetos de
rede devem considerar ao desenhar o layout de suas redes.
A.1.1. Topologias Físicas
Conforme definido pelo Institute of Electrical and Electronics Engineers (IEEE), há três topologias
comuns para a conexão física de uma LAN.
A.1.1.1. Topologia Ring
A topologia Ring conecta cada nódulo por exatamente duas conexões. Isto cria uma estrutura ring
na qual cada nódulo é acessível ao outro, diretamente por seus nódulos vizinhos fisicamente mais
próximos ou indiretamente através do ring físico. Redes Token Ring, FDDI e SONET são conectadas
desta maneira (com o FDDI usando uma técnica de ring duplo). No entanto, não há conexões Ethernet
comuns 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 (o
backbone). A topologia de canal linear requer um mínimo de cabeamento e equipamento de rede, o
que a torna a topologia de custo mais baixo. No entanto, o canal linear depende do backbone estar
constantemente disponível, tornando-o um ponto único de falha, caso seja necessário colocá-lo offline
ou esteja 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 comunicação é passada. Este ponto central, chamado de hub pode ser transmitido ou comutado. Esta
topologia introduz um ponto único de falha no hardware de rede centralizado que conecta os nódulos.
Entretanto, devido essa centralização, as questões de rede que afetam segmentos da ou a LAN inteira
são facilmente rastreáveis para esta fonte única.
A.1.2. Considerações de Transmissão
Em uma rede de transmissão, um nódulo enviará um pacote que atravessa todos os outros nódulos
até que o receptor aceite o pacote. Cada nódulo da rede pode concebivelmente receber este pacote
de dados até que o receptor processe o pacote. Em uma rede de transmissão, todos os pacotes são
enviados desta maneira.
Em uma rede comutada (switched network), os pacotes não são transmitidos, mas são processados no
hub comutado que, por sua vez, cria uma conexão direta entre os nódulos emissor e receptor, usando
os 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ários
maléficos podem configurar seu dispositivo Ethernet para o modo promíscuo e aceitar todos os pacotes
independentemente se os dados são para estes ou não. Uma vez definido no modo promíscuo, uma
aplicação sniffer pode ser usada para filtrar, analisar e reconstruir pacotes para senhas, dados pessoais
e outros. Aplicações sniffer sofisticadas podem armazenar este tipo de informação em arquivos texto
e, talvez, até enviar as informações para fontes arbitrárias (por exemplo: o enedereço de e-mail do
usuário maléfico).
Uma rede comutada requer um comutador de rede, um componente de hardware especializado que
substitui a função do hub tradicional, ao qual todos os nódulos de uma LAN são conectados. Comutadores armazenam endereços MAC de todos os nódulos em um banco de dados interno, que os utiliza
para seu roteamento direto. Diversos fabricantes, incluindo a Cisco Systems, Linksys e Netgear oferecem vários tipos de comutadores com características como a compatibilidade 10/100-Base-T, suporte
a Ethernet gigabit e suporte ao Acesso Múltiplo de Detecção do Portador e Detecção de Colisão (Carrier Sensing Multiple Access and Collision Detection - CSMA/CD), que é ideal para redes de tráfego
alto porque enfileira as conexões e detecta quando os pacotes colidem em trânsito.
A.1.3. Redes Sem-fio
Uma questão emergente para empresas é a mobilidade. Funcionários remotos, técnicos de campo
e executivos requerem soluções portáteis, como laptops, organizadores pessoais digitais (PDAs) e
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 usado
atualmente é 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 comunicações sem-fio e exercem controle sobre o espectro 2.4GHz de rádio frequência (RF) não licensiado
(a 802.11a usa o espectro de 5GHz). Estas especificações foram aprovadas como padrões pelo IEEE,
e diversos fabricantes comercializam produtos e serviços 802.11x. Os consumidores também adotaram o padrão para as redes em escritórios pequenos ou caseiros. A popularidade também extendeu-se
das LANs às MANs (Redes de Área Metropolitana), especialmente em áreas populosas onde há uma
concentração de pontos de acesso sem-fio (wireless access points - WAPs). Além disso, há provedores
de serviços de Internet sem-fio que servem viajantes frequentes necessitando acesso de banda larga à
Internet, para conduzir seus negóciois remotamente.
As especificações 802.11x permitem conexões par-a-par diretas entre nódulos com NICs sem-fio.
Este agrupamento flexível de nódulos, chamado de rede improvisada, é ideal para compartilhamento
de conexão rápida entre dois ou mais nódulos, mas introduz questões de escalabilidade não adequadas
para conectividade sem-fio dedicada.
Uma solução mais adequada para o acesso sem-fio em estruturas fixas é instalar um ou mais WAPs,
que conectam à rede tradicional e permitem que nódulos sem-fio se conectem ao WAP como se fosse
na rede mediada pela Ethernet. O WAP age efetivamente como uma ponte entre os nódulos conectados
a ele e o resto da rede.
A.1.3.1. Segurança da 802.11x
Apesar da rede sem-fio ser comparável em velocidade e certamente mais conveniente que os meios de
redes com fios, há algumas limitações na especificação que autoriza consideração completa. A mais
importante destas limitações está na sua implementação de segurança.
Com a ansiedade de implantar uma rede 802.11x com sucesso, muitos administradores deixam de
tomar as precauções mais básicas. Desde que toda a rede 802.11x esteja feita usando sinais RF de
banda alta, os dados transmitidos são facilmente acessíveis a qualquer usuário com um NIC compatível, uma ferramenta de scaneamento da rede sem-fio (como o NetStumbler ou o Wellenreiter) e
ferramentas comuns de sniffing (como dsniff e snort). Para impedir este uso indevido das redes
privadas sem-fio, o padrão 802.11b usa o protocolo Wired Equivalency Privacy (WEP), uma chave
criotografada de 64 ou 128 bits baseada no RC-4 e compartilhada entre cada nódulo ou entre a AP e
o nódulo. Esta chave criptografa as transmissões e descriptografa pacotes de entrada dinamicamente e transparentemente. Os administradores frequentemente deixam de implementar este esquema de
criptografia de chave compartilhada por esquecimento ou porque escolheram não fazê-lo devido à degradação do desempenho (especialmente através de distâncias longas). Habilitar o WEP em uma rede
sem-fio pode reduzir drasticamente a possibilidade de intercepção de dados.
O Red Hat Enterprise Linux suporta vários produtos 802.11x de diversos fabricantes. A Ferramenta
de Administração de Rede inclui uma funcionalidade para configurar a segurança de NICs e WEP
sem-fio. Para informações sobre o uso da Ferramenta de Administração de Rede, consulte o 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 determinados
usuários maléficos. Há utilitários especializados desenvolvidos especificamente para crackear o algoritmo RC4 de criptografia do WEP protegendo uma rede sem-fio e expondo a chave compartilhada.
A AirSnort e a WEP Crack são dois exemplos destas aplicações especializadas. Para protegerem-se
destas, os administradores devem aderir a normas restritas em relação ao uso de métodos sem-fio para
o acesso a informações delicadas. Pode-se optar por aumentar a segurança da conectividade sem-fio
restringindo-a somente a conexões SSH ou VPN, que introduz uma camada de criptografia adicional
sobre a criptografia WEP. Ao usar esta norma, um usuário maléfico externo à rede que crackear a
criptografia 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 algoritmos proprietários, ou ainda uma força maior. Os administradores que aplicarem estas normas devem
104
restringir protocolos somente-texto (como Telnet ou FTP), já que senhas e dados podem ser expostos
usando quaisquer dos métodos mencionados anteriormente.
A.1.4. Segmentação de Rede e DMZs
Para administradores que queiram rodar serviços acessíveis externamente (como HTTP, e-mail, FTP
e DNS) é recomendado que estes serviços sejam física e/ou logicamente 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 residem
na mesma rota lógica que o resto da rede. Os serviços acessíveis externamente devem residir no que
a indústria da segurança chama de zona desmilitarizada (DMZ), um segmento da rede lógica onde
o tráfego de entrada da Internet pode acessar somente àqueles serviços e não podem acessar a rede
interna. Isto é efetivo, pois mesmo que um usuário maléfico faça um exploit na DMZ de uma máquina,
o resto da rede interna fica atrás de um firewall em um segmento separado.
A maioria das empresas tem um conjunto limitado de endereços IP publicamente roteáveis, a partir
dos quais pode hospedar serviços externos. Desta forma, os administradores utilizam regras de firewall
elaboradas para aceitar, encaminhar, rejeitar e negar transmissões de pacotes. Regras de firewall implementadas com iptables ou firewalls de hardware dedicado permitem o roteamento complexo e
o encaminhamento de regras, que podem ser usados por administradores para segmentar o tráfego de
entrada para serviços específicos em endereços e portas específicos, assim como para permitir que
somente 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 Hardware
De acordo com um estudo lançado em 2000 pelo FBI e o Computer Security Institute (CSI), mais de
setenta por cento de todos os ataques a dados e recursos delicados reportados por empresas ocorreram
dentro da própria empresa. Implementar normas de segurança interna é tão importante quanto uma
estratégia externa. Esta seção explica algumas das medidas comuns que administradores e usuários
podem tomar para proteger seus sistemas de más práticas internas.
Estações de trabalho de funcionários não são, na maioria dos casos, potenciais alvos de ataques remotos, especialmente aquelas atrás de um firewall configurado apropriadamente. No entanto, há algumas
medidas de proteção que podem ser implementadas para evitar um ataque físico ou interno aos recursos de estações de trabalho individualmente.
Estações de trabalho e PCs caseiros modernos têm BIOSes que controlam recursos do sistema no nível
do hardware. Usuários de estações de trabalho podem determinar senhas administrativas no BIOS para
impedir que usuários maléficos reinicializem o sistema ou acessem/roubem informações armazenadas
no disco rígido.
Mas, se o usuário maléfico roubar o PC (o caso mais comum de roubo entre viajantes que carregam
laptops e outros dispositivos portáteis) e levá-lo a um lugar onde ele pode desmontar o computador,
a senha do BIOS não evita que o atacante remova o disco rígido. Assim, pode instalá-lo em outro
PC sem restrições de BIOS e 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 chassis
do PC e do laptop para evitar roubo, assim como bloqueios de chave no próprio chassis para evitar
acesso interno. Este tipo de hardware é amplamente disponibilizado por fabricantes como Kensington
e Targus.
O hardware de servidor, especialmente servidores de produção, é geralmente montado em racks em
salas de servidores. Armários de servidor comumente possuem portas com trancas; e chassis individu-
105
ais de servidores também estão disponíveis com frentes com trancas para aumentar a segurança contra
o desligamento errôneo (ou intencional).
As empresas também podem usar provedores de co-locação para guardar seus servidores, já ques estes
oferecem banda mais alta, suporte técnico 24h 7 dias por semana e conhecimento em segurança de
sistemas e servidores. Este pode ser um meio efetivo de terceirizar as necessidades de segurança e
conectividade para transações HTTP ou serviços de streaming media. No entanto, a co-locação pode
ter um alto custo, especialmente para pequenas e médias empresas. As estruturas da co-locação são
conhecidas por ser altamente protegidas por seguranças treinados e monitoradas o tempoo todo.
106
Apêndice B.
Exploits Comuns e Ataques
Tabela B-1 detalha alguns dos exploits e pontos de entrada mais comuns usados por intrusos para
acessar recursos de rede de organizações. As explicações de como estes exploits são executados e
como administradores podem proteger sua rede apropriadamente são muito importantes contra tais
ataques.
Exploit
Descrição
Notas
Zero ou Senha
Default
Deixar senhas administrativas em
branco ou usar a senha default provida
pelo fabricante. Isto é mais comum
em hardware, como roteadores e
BIOSes, porém alguns dos serviços
que rodam no Linux podem conter
senhas default de administrador
(apesar do Red Hat Enterprise Linux
não ser distribuído com elas).
Comumente associado a hardware de
rede, como roteadores, firewalls,
VPNs e aplicações de
armazenamento anexo à rede
(network attached storage - NAS);
Comum em muitos sistemas
operacionais legados, especialmente
aqueles que compoem serviços como
UNIX e Windows.
Às vezes, administradores criam
alguns usuários privilegiados com
pressa e deixam a senha vazia, um
ponto de entrada perfeito para
usuários maliciosos que descobrem o
usuário.
Chaves
Compartilhadas
Default
Serviços seguros às vezes empacotam
chaves de seurança default para
desenvolvimento ou para testes de
avaliação. Se estas chaves
permanacerem inalteradas e estiverem
localizadas em um ambiente de
produção na Internet, qualquer
usuário com as mesmas chaves default
tem acesso a este recurso de chave
compartilhada e a quaisquer
informações importantes contidas
neste.
Mais comum em pontos de acesso
sem-fio e aplicações de servidor
seguro pré-configuradas
CIPE (consulte o Capítulo 6) contém
uma amostra de chave estática que
deve ser alterada antes da aplicação
em um ambiente de produção
108
Apêndice B. Exploits Comuns e Ataques
Exploit
Descrição
Notas
Spoofing do IP
(alteração do
endereço IP para
parecer como
outra máquna)
Uma máquina remota age como um
nódulo em sua rede local, encontra
vulnerabilidades em seus servidores e
instala uma programa backdoor ou
trojan para obter controle sobre seus
recursos de rede.
O Spoofing é bem difícil já que
requer que o atacante adivinhe os
números de TCP/IP SYN-ACK para
coordenar uma conexão que almeje
os sistemas, mas há diversas
ferramentas disponíveis para auxiliar
crackers em executá-lo.
Depende de almejar sistemas que
estejam rodando serviços (tais como
rsh, telnet, FTP e outros) que
utilizam técnicas de autenticação
baseadas na fonte, não recomendadas
quando comparadas à PKI ou outras
formas de autenticação criptografada
usadas no ssh ou SSL/TLS.
Eavesdropping
(espionagem do
tráfego de rede)
Coletando dados que trafegam entre
dois nódulos ativos em uma rede
através do eavesdropping na conexão
entre estes dois nódulos.
Este tipo de ataque geralmente
atinge protocolos de transmissão
somente-texto, como Telnet, FTP e
transferências HTTP.
O atacante remoto deve ter accesso a
um sistema comprometido em uma
LAN para poder executar um ataque
deste tipo. Geralmente o cracker
usou um ataque ativo (como um
spoofing de IP ou
’Man-in-the-middle’) para
comprometer um sistema na LAN
Medidas preventivas incluem serviços
com troca de chave criptográfica,
senhas descartáveis ou autenticação
criptografada para impedir snooping
de senha. Também recomenda-se a
alta criptografia durante as
transmissões
109
Exploit
Descrição
Notas
Vulnerabilidades
do Serviço
Um atacante encontra um defeito ou
uma infração em um serviço
executado pela Internet através desta
vulnerabilidade. O atacante
compromete o sistema inteiro e
quaisquer dados que este possa
conter; e também é possível que
comprometa outros sistemas da rede.
Serviços baseados em HTTP, tais
como o CGI, são vulneráveis a
execuções de comandos remotos e
até mesmo a acesso através da janela
de comandos. Mesmo que o serviço
HTTP seja executado por um usuário
não-privilegiado, como "ninguém",
informações como arquivos de
configuração e mapas de rede podem
ser lidas, ou o atacante pode iniciar
um ataque ’denial of service’ que
drena os recursos do sistema ou
torna-os indisponíveis a outros
usuários.
Serviços podem ter vulnerabilidades
que passam desapercebidas durante o
desenvolvimento e testes. Estas
vulnerabilidades (tais como
sobrecarregamentos do buffer, que
possibilitam ao atacante obter acesso
ao preencher a memória endereçável
com uma quantidade além da
aceitável pelo serviço, prejudicam o
serviço e dão ao atacante um prompt
de comando interativo a partir do
qual ele pode executar comandos
arbitrariamente) podem oferecer
controle administrativo completo a
um atacante.
Administradores devem certificar-se
que os serviços não sejam executados
com o usuário root e estar atentos a
atualizações de erratas e consertos
para suas aplicações, de fabricantes ou
empresas de segurança como CERT e
CVE.
110
Exploit
Descrição
Notas
Vulnerabilidades
da Aplicação
Atacantes encontram falhas em
aplicações de compuatdores pessoais
e estações de trabalho como clientes
de e-mail, executam código arbitrário
e implantam trojans para
comprometer ou danificar serviços
futuramente. Exploits podem ocorrer
no futuro se a estação de trabalho
comprometida tiver privilégios
administrativos para o resto da rede.
Estações de trabalho e computadores
pessoais são mais propensos a
exploits porque os funcionários não
têm a mesma habilidade ou
experiência para impedir ou detectar
o comprometimento; é essencial
informar aos indivíduos sobre os
riscos que correm ao instalar
software não autorizado ou abrir
arquivos anexos de e-mails não
solicitados.
Algumas defesas podem ser
implementadas de modo que este
software de cliente de e-mail não abra
ou execute automaticamente arquivos
anexos. Adicionalmente, a atualização
automática do software da estação de
trabalho através da Red Hat Network
ou outros serviços de gerenciamento
de sistemas, podem aliviar a carga de
aplicações de segurança para
multi-usuário.
Ataques Denial of O atacante ou grupo de atacantes
Service (DoS)
coordena um ataque a recursos de
rede ou de servidor de uma empresa
enviando pacotes não autorizados para
a máquina alvo (um servidor, um
roteador ou uma estação de trabalho).
Isto força o recurso a ficar
indisponível aos usuários legítimos.
Tabela B-1. Exploits Comuns
O caso de DoS (denial of service)
ocorrido em 2000 mais reportado.
Diversos sites comerciais e
governamentais de alto tráfego
tornaram-se indisponíveis por um
ataque ’ping flood’ coordenado,
usando vários sistemas
comprometidos com conexões de
banda larga atuando como zumbis,
ou nódulos de transmissão
redirecionados.
Pacotes fonte geralmente são
forjados (e também retransmitidos),
dificultando a investigação da
verdadeira origem do ataque.
Avanços na filtragem do ingresso
(ingress filtering - IETF rfc2267),
usando iptables e IDs de Rede
como snort, ajudam administradores
a rastrear e impedir ataques DoS
distribuídos.
Apêndice C.
Portas Comuns
As tabelas a seguir listam as portas de comunicação mais comuns usadas pelos serviços, daemons
e programas inclusos no Red Hat Enterprise Linux. Esta lista também pode ser encontrada no arquivo /etc/services. Para acessar uma lista oficial das portas Bem Conhecidas (Well Knnown),
Registradas (Registered) e Dinâmicas (Dynamic) conforme designadas pela IANA (Internet Assigned
Numbers Authority), consulte o site:
http://www.iana.org/assignments/port-numbers
Nota
A Camada, quando listada, denota se o serviço ou protocolo usa TCP ou UDP para transporte. Se
não estiver especificada, o serviço/protocolo pode usar ambos, TCP e UDP.
Número da
Nome
Porta / Camada
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 portas
conectadas
13
daytime
Envia data e hora para a máquina requerente
17
qotd
Envia a citação do dia para a máquina conectada
18
msp
Protocolo de Envio de Mensagem
19
chargen
Serviço de Geração de Caractere; envia trechos infinitos
de caracteres
20
ftp-data
Porta de dados do FTP
21
ftp
Porta do Protocolo de Transferência de Arquivos (FTP);
por vezes usada pelo Protocolo de Serviço de Arquivos
(FSP - File Service Protocol)
22
ssh
Serviço Secure Shell (SSH)
23
telnet
O serviço Telnet
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
Número da
Nome
Porta / Camada
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 Acesso
do Terminal para autenticação e acesso baseado no
TCP/IP
50
re-mail-ck
Protocolo de Verificação de Correspondência Remota
53
domain
serviços de nome de domínio (tal como BIND)
63
whois++
WHOIS++, serviços WHOIS extendidos
67
bootps
Serviços do Protocolo de Bootstrap (BOOTP); também
usado pelos serviços do Protocolo de Configuração da
Máquina Dinâmica (Dynamic Host Configuration
Protocol, DHCP)
68
bootpc
Cliente boostrap (BOOTP); também usado por clientes do
Protocolo de Controle da Máquina Dinâmica (DHCP)
69
tftp
Protocolo de Transferência de Arquivos Triviais (TFTP Trivial File Transfer Protocol)
70
gopher
Ferramenta de busca e recuperação de documentos de
Internet Gopher
71
netrjs-1
Serviço de Tarefa Remota
72
netrjs-2
73
netrjs-3
73
netrjs-4
79
finger
Serviço finger para informações de contato do usuário
80
http
Protocolo de Transferência de HíperTexto (HTTP) para
serviços WWW (World Wide Web)
88
kerberos
Sistema de autenticação de rede Kerberos
95
supdup
Extensão do protocolo telnet
101
hostname
Serviços de nomes para máquinas SRI-NIC
102
iso-tsap
Aplicações de rede do Ambiente de Desenvolvimento ISO
(ISODE)
105
csnet-ns
Servidor de nomes da caixa de correspondência; também
usado pelo servidor de nomes CSO
107
rtelnet
Telnet remoto
109
pop2
Versão 2 do Protocolo do Post Office
110
pop3
Versão 3 do Protocolo do Post Office
111
sunrpc
Protocolo da Chamada de Procedimento Remoto (RPC)
para execução de comandos remotos, usado pelo Sistema
de Arquivo de Rede (NFS)
113
Número da
Nome
Porta / Camada
Comentário
113
auth
Protocolos de autenticação e identificação
115
sftp
Serviços do Protocolo de Transferência de Arquivos
Seguros (SFTP)
117
uucp-path
Serviços da Localidade do Protocolo de Cópia
Unix-para-Unix (UUCP - Unix-to-Unix Copy Protocol)
119
nntp
Protocolo de Transferência de Notícias de Rede (Network
News Transfer Protocol, NNTP) para o sistema de
discussão USENET
123
ntp
Protocolo de Hora da Rede (NTP - Network Time
Protocol)
137
netbios-ns
Serviços de Nome do NETBIOS usando no Red Hat
Enterprise Linux pelo Samba
138
netbios-dgm
Serviços de Datagrama do NETBIOS usado no Red Hat
139
netbios-ssn
Serviços de Sessões do NETBIOS usado no Red Hat
143
imap
Protocolo de Acesso à Mensagem via Internet (Internet
Message 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 do
X
178
nextstep
Servidor de janelas do NeXTStep
179
bgp
Protocolo da Porta de Comunicação da Divisa (Border
Gateway 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
114
Número da
Nome
Porta / Camada
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 de
datagrama geralmente usado em ambientes Netware do
Novell
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 - Service
Location 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 do
Photuris
487
saft
Protocolo de Transferência de Arquivos Assíncronos
Simples (SAFT - Simple Asynchronous File Transfer)
488
gss-http
Serviços de Segurança Genérica (Generic Security
Services, GSS) para o HTTP
496
pim-rp-disc
Rendezvous Point Discovery (RP-DISC) para os serviços
do Protocol Independent Multicast (PIM)
500
isakmp
Protocolo de Gerenciamento da Chave e da Associação da
Segurança de Internet (ISAKMP - Internet Security
Association 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)
115
Número da
Nome
Porta / Camada
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 Secure
Sockets 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 - Distributed
Queueing 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 - Distributed
Queueing System)
612
hmmp-ind
Indicação do HMMP / DQS
631
ipp
Protocolo de Impressão da Internet (IPP - Internet Printing
Protocol)
636
ldaps
Protocolo de Acesso ao Diretório Lightweight sobre a SSL
(LDAPS - Lightweight Directory Access Protocol over
Secure Sockets Layer)
674
acap
Protocolo de Acesso à Configuraço da Aplicação (ACAP Application Configuration Access Protocol)
694
ha-cluster
Serviços heartbeat para Clusters de Ata Disponibilidade
749
kerberos-adm
Administração do banco de dados ’kadmin’ do Kerberos
versão 5 (v5)
750
kerberos-iv
Serviços do Kerberos versão 4 (v4)
765
webster
Dicionário da Rede
767
phonebook
Catálogo de Telefones da Rede
873
rsync
serviços de transferência de arquivos rsync
992
telnets
Telnet sobre a Secure Sockets Layer (TelnetS)
993
imaps
Protocolo de Acesso a Mensagens da Internet sobre a SSL
(IMAPS - Internet Message Access Protocol over Secure
Sockets Layer)
994
ircs
Internet Relay Chat sobre Secure Sockets Layer (IRCS)
116
Número da
Nome
Porta / Camada
Comentário
995
Protocolo do Post Office versão 3 sobre SSL (POP3S Post Office Protocol version 3 over Secure Sockets Layer)
pop3s
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 ou
apelido(s) comum(ns).
Número da
Nome
Porta / Camada
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- Routing
Information Protocol)
521
ripng
Protocolo de Informações de Roteamento para o Protocolo
de 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 de
Mensageiro (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
117
Número da
Nome
Porta / Camada
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 o
Protocolo 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 o
registro formal na lista de números de porta.
Número da
Nome
Porta / Camada
Comentário
1080
socks
Serviços proxy da aplicação de rede SOCKS
1236
bvcontrol
[rmtcfg]
Servidor de Configuração Remota de Garcilis Packeten
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 do
Banco de Dados Ingres (DBMS - Database Management
System)
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 arquivos
Kermit
1701
l2tp [l2f]
Protocolo de Tunneling da Camada 2 (LT2P - Layer 2
Tunneling Protocol) / encaminhamento da camada 2 (L2F
- layer 2 forwarding)
1718
h323gatedisc
H.323 telecommunication Gatekeeper Discovery
1719
h323gatestat
H.323 telecommunication Gatekeeper Status
1720
h323hostcall
H.323 telecommunication Host Call setup
1758
tftp-mcast
Multi-transmissão do FTP Trivial
a
118
Número da
Nome
Porta / Camada
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 do
radius
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 de
servidor
2430/tcp
venus
Gerenciador de cache Venus para o sistema de arquivo
Coda (porta codacon)
2430/udp
venus
Gerenciador de cache Venus para o sistema de arquivo
Coda (callback/interface wbc)
2431/tcp
venus-se
efeitos colaterais do Protocolo de Controle de Transmissão
(TCP) Venus
2431/udp
venus-se
Efeitos colaterais do Protocolo de Datagrama de Usuário
Vênus (Venus User Datagram Protocol, UDP)
2432/udp
codasrv
porta do servidor do sistema de arquivo Coda
2433/tcp
codasrv-se
efeitos colaterais do TCP do sistema de arquivo Coda
2433/udp
codasrv-se
efeitos colaterais do SFTP do UDP do sistema de arquivo
Coda
2600
hpstgmgr
[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 de
Roteamento (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)
119
Número da
Nome
Porta / Camada
Comentário
2605
nsc-posa
NSC POSA; daemon do Protocolo da Porta de
Comunicação da Divisa (bgpd)
2606
netmon [ospf6d]
Dell Netmon; OSPF para o dameon do IPv6 (ospf6d)
2809
corbaloc
Common Object Request Broker Architecture (CORBA)
nomeando localizador de serviços
3130
icpv2
Protocolo do Cache da Internet versão 2 (v2); usado pelo
servidor de caching 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ão
4 (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 arquivos
CVSup
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 Rede
Automático Maryland Avançado (Amanda - Advanced
Maryland Automatic Network Disk Archiver)
11371
pgpkeyserver
Pretty Good Privacy (PGP) / servidor de chaves públicas
GNU Privacy Guard (GPG)
120
Número da
Nome
Porta / Camada
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 Rede
Veritas (bpdbm - NetBackup Database Manager)
13722
bpjava-msvc
Veritas NetBackup Java / Protocolo do Microsoft Visual
C++ (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 (e
relacionados)
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’, mas
também é usada pelo servidor de configuração remota de Gracilis Packeten. O nome oficial esta
listado 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 zebra
sem serem registradas. Os nomes principais são os nomes registrados, e os nomes não-registrados
usados pelo zebra são listados como apelidos (aliases)."
c. Nota do /etc/services: "Esta porta é registrada como wnn6, mas também é usada sob o
nome não-registrado ’wnn4’ pelo pacote FreeWnn."
Tabela C-3. Portas Registradas
A Tabela C-4 mostra uma lista das portas relacionadas ao Protocolo de Entrega do Datagrama (DDP)
usado das redes AppleTalk.
Número da
Nome
Porta / Camada
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ão
registradas na IANA.
121
Número da
Nome
Porta / Camada
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 que
podem ser instalados no seu sistema Red Hat Enterprise Linux ou são necessários para a comunicação
entre o Red Hat Enterprise Linux e sistemas rodando outros sistemas operacionais.
Número da
Nome
Porta / Camada
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 Simples
sobre Secure Sockets Layer (SMTPS)
616/tcp
gii
Interface Interativa do Gated (daemon de roteamento)
808
omirr [omirrd]
Serviços de espelhamento de arquivo Online Mirror
(Omirr)
871/tcp
supfileserv
Servidor do Protocolo de Atualização de Software (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 em
Japonês
1313/tcp
xtel
Sistema de informações de texto French Minitel
1529/tcp
suporte [prmsd,
gnatsd]
Sistema de rastreamento de erros GNATS
122
Número da
Nome
Porta / Camada
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 rede
NOCOL (noclogd - NOCOL network operation center
logging daemon)
5355
hostmon
Monitoramento de máquina do centro de operações de
rede NOCOL
5680/tcp
canna
Interface do input dos caracteres Japoneses Canna
6010/tcp
x11-ssh-offset
Secure Shell (SSH) X11 forwarding offset
6667
ircd
Daemon do Internet Relay Chat (ircd)
7100/tcp
xfs
Servidor de Fontes do X (XFS)
7666/tcp
tircproxy
Serviço proxy do IRC Tircproxy
8008
http-alt
Protocolo de Transferência de Hipertexto (HTTP)
alternado
8080
webcache
Serviço de caching da World Wide Web (WWW)
8081
tproxy
Proxy Transparente
9100/tcp
jetdirect [laserjet,
hplj]
Serviço de impressão de rede da Hewlett-Packard (HP)
JetDirect
9359
mandelspawn
[mandelbrot]
Programa de spawning Parallel Mandelbrot para o Sistema
X 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 Sistemas
Integrados (ISDN - Integrated Systems Digital Network)
20012
vboxd
Daemon da caixa de voz da ISDN (vboxd - voice box
dameon)
22305/tcp
wnn4_Kr
Sistema de input Korerano kWnn
22289/tcp
wnn4_Cn
Sistema de input Chinês cWnn
123
Número da
Nome
Porta / Camada
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
124
Índice Remissivo
crackers
definição, 7
cupsd, 35
Símbolos
802.11x, 102
e segurança, 102
ética do hacker, 7
A
atacantes e riscos, 7
atualizações
(Ver erratas de segurança)
auditoria de arquivos
ferramentas, 94
B
BIOS
não-equivalentes ao x86
senhas, 22
segurança, 21
senhas, 21
C
CIPE, 54
instalação, 55
personalizando, 58
coletando evidências
(Ver resposta ao incidente)
ferramentas de auditoria de arquivos, 94
dd, 94
file, 94
find, 94
grep, 94
md5sum, 94
script, 93
stat, 94
strings, 94
considerações de segurança
hardware, 101
redes físicas, 101
sem-fio, 102
transmissão de rede, 102
controles, 5
administrativos, 6
físicos, 5
técnicos, 6
convenções
documentos, ii
cracker
hacker de chapéu preto, 7
D
dd
auditoria de arquivos usando, 94
coletando 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)
E
equipe de resposta a emergências de computador, 92
erratas de segurança, 15
aplicando alterações, 17
através do site de erratas da Red Hat, 16
quando reinicializar, 17
via Red Hat Network, 15
exploits comuns e ataques, 107
tabela, 107
F
Ferramenta de Configuração dos Serviços, 36
ferramentas de comunicação
seguras, 38
GPG, 38
OpenSSH, 38
file
find
firewalls, 67
pessoal, 37
recursos adicionais, 74
tipos, 67
FTP
acesso anônimo, 48
apresentando, 47
banner de saudação, 47
contas de usuário, 49
TCP wrappers e, 49
upload anônimo, 48
vsftpd, 47
126
G
K
gestores de início
GRUB
senha protegendo, 22
LILO
senha protegendo, 23
segurança, 22
grep
Kerberos
NIS, 45
H
M
hacker 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, 7
chapéu cinza, 7
chapéu preto
(Ver cracker)
definição, 7
hardware, 101
e segurança, 104
estações de trabalho, 104
laptops, 104
servidores, 104
md5sum
módulos de autenticação plugáveis (pluggable authentication modules - PAM)
forçando uma senha forte, 27
I
idade da senha, 28
IDS
(Ver sistemas de detecção de invasão)
introdução, i
categorias, usando este manual, i
outros manuais do Red Hat Enterprise Linux, i
tópicos, i
ip6tables, 73
IPsec, 60
configuração, 62
máquina-a-máquina, 61
instalando, 60
rede-a-rede, 62
iptables, 68
e DMZs, 72
usando, 69
L
lpd, 35
lsof, 50
N
Nessus, 80
Netfilter, 68
Netfilter 6, 73
netstat, 50
NFS, 45
e Sendmail, 50
erros de sintaxe, 45
planejamento de rede, 45
Nikto, 81
NIS
apresentando, 43
IPTables, 44
Kerberos, 45
nome de domínio do NIS, 43
planejando a rede, 43
portas estáticas, 44
securenets, 44
nmap, 50, 79
versão linha de comando, 80
O
OpenSSH, 38
scp, 38
sftp, 38
ssh, 38
127
P
plano de resposta ao incidente, 91
portas
comuns, 111
monitorando, 50
portas comuns
tabela, 111
portas de comunicação, 111
portmap, 35
e IPTables, 42
e TCP wrappers, 42
post-mortem, 93
Q
questões legais, 92
R
redes, 101
comutadores, 102
e segurança, 101
hubs, 102
segmentação, 104
sem-fio, 102
zonas desmilitarizadas (de-militarized zones DMZs), 104
Redes Privadas Virtuais (Virtual Private Networks),
53
CIPE, 54
IPsec, 60
configuração, 62
instalando, 60
Redes Wi-Fi
(Ver 802.11x)
reportando o incidente, 97
resposta ao incidente
coletando evidências
usando o dd, 93
coletando informação pós-infração, 94
criando um plano, 91
definição de, 91
e questões legais, 92
equipe de resposta a emergências de computador
(computer emergency response team - CERT), 92
implementação, 93
introduzindo, 91
investigação, 93
post-mortem, 93
reportando o incidente, 97
restaurando e recuperando recursos, 96
restaurando e recuperando recursos, 96
consertando o sistema (patching), 96
reinstalando o sistema, 96
riscos
consertos e erratas, 9
estações de trabalho e PCs, 10, 10
aplicações, 10
portas abertas, 8
redes, 8
arquiteturas, 8
servidores, 8
administração desatenta, 9
serviços inseguros, 9
root, 30
desativar acesso, 30
limitar acesso, 33
com Administrador de Usuários, 33
e o su, 33
e o sudo, 34
métodos de desativação, 30
alterar a shell root, 32
com PAM, 32
impossibilitar autenticações SSH, 32
permitindo acesso, 30
RPM
checar assinatura GPG, 16
e detecção de intrusão, 86
importando a chave GPG, 16
S
segurança da estação de trabalho, 21
avaliando
BIOS, 21
comunicações, 21
controle administrativo, 21
firewalls pessoais, 21
gestores de início, 21
senhas, 21
BIOS, 21
gestores de início
senhas, 22
segurança da senha, 24
e PAM, 27
em uma empresa, 27
ferramentas de auditoria, 28
Crack, 28
John the Ripper, 28
Slurpie, 28
forçando, 27
idade, 28
metodologia, 27
senhas fortes, 25
segurança do servidor
FTP, 47
acesso anônimo, 48
banner de saudação, 47
128
contas de usuário, 49
TCP wrappers e, 49
upload anônimo, 48
vsftpd, 47
NFS, 45
erros de sintaxe, 45
planejamento de rede, 45
NIS, 43
IPTables, 44
Kerberos, 45
nome de domínio do NIS, 43
planejando a rede, 43
portas estáticas, 44
securenets, 44
portas
monitorando, 50
portmap, 42
Sendmail, 49
e NFS, 50
limitando DoS, 50
Servidor HTTP Apache, 46
diretivas, 46
segurança cgi, 47
TCP wrappers, 39
alertas de ataque, 40
banners, 39
registro, 40
visão geral da, 39
xinetd, 41
gerenciando recursos com, 41
prevenindo DoS (recusa de serviço) com, 41
SENSOR armadilha, 41
segurança sem-fio, 102
802.11x, 102
sendmail, 35
apresentando, 49
e NFS, 50
limitando DoS, 50
senhas
dentro de uma empresa, 27
Servidor HTTP Apache
apresentando, 46
diretivas, 46
segurança cgi, 47
serviços, 50
serviços de co-locação, 104
serviços de rede, 35
identificando e configurando, 35
riscos, 35
denial-of-service (negação de serviço), 35
sobrecarregamento do buffer, 35
vulnerabilidade do script, 35
serviços inseguros, 36
rsh, 37
Telnet, 37
vsftpd, 37
Shell EFI
segurança
senhas, 22
sistema básico de input e output
(Ver BIOS)
sistemas de detecção de invasão, 85
baseado em rede, 88
Snort, 90
baseado no servidor, 85
definindo, 85
e arquivos de registro, 85
Gestor de Pacotes RPM (RPM), 86
tipos, 85
Tripwire, 86
Snort, 90
sshd, 35
stat
strings
su
e root, 33
sudo
e root, 34
T
TCP wrappers
alertas de ataque, 40
banners, 39
e FTP, 49
e portmap, 42
registro, 40
tipos de firewall, 67
filtro de pacotes, 67
proxy, 67
tradução do endereço da rede (network address
translation - NAT), 67
topologias de rede, 101
canal linear (linear bus), 101
estrela (star), 101
ring, 101
Tripwire, 86
U
usuário root
(Ver root)
129
V
visão geral, 1
visão geral de segurança, 1
conclusão, 6
controles
(Ver controles)
definindo segurança em computadores, 1
Denial of Service - DoS (Negação de Serviço), 4
evolução da segurança em computadores, 1
vírus, 4
VLAD the Scanner, 81
VPN, 53
vulnerabilidades
avaliando com Nessus, 80
avaliando com Nikto, 81
avaliando com Nmap, 79
avaliando com o VLAD the Scanner, 81
estimativa, 77
definindo, 78
estabelecendo uma metodologia, 79
testes, 78
vírus
trojans, 4
X
xinetd, 35
gerenciando recursos com, 41
prevenindo DoS (recusa de serviço) com, 41
SENSOR armadilha, 41
Z
Zona 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 produzidos usando stylesheets DSSSL personalizadas e scripts jade wrapper personalizados. Os arquivos
SGML do DocBook são escritos em Emacs com o auxílio do modo PSGML.
Garrett LeSage criou as imagens de alerta (nota, dica, importante, atenção e aviso). Elas podem ser
distribuídas livremente com a documentação da Red Hat.
A Equipe de Documentação de Produtos da Red Hat Linux é composto pelas seguintes pessoas:
Sandra A. Moore — Escritora / Mantenedora Principal do Guia de Instalação para as Arquiteturas
x86, Itanium™ e AMD64 do Red Hat Enterprise Linux; Escritora / Mantenedora Principal do Guia de
Instalação para as Arquiteturas IBM® eServer™ iSeries™ e IBM® eServer™ pSeries™ do Red Hat
Enterprise 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 Hat
Enterprise 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 Enterprise Linux; Escritora contribuinte do Guia Passo a Passo do Red Hat Enterprise Linux; Escritora
Principal/Mantenedora dos scripts e stylesheets personalizados do DocBook
Edward C. Bailey — Escritor Principal/Mantenedor do Introdução à Administração de Sistemas Red
Hat Enterprise Linux; Escritor Principal/Mantenedor das Notas de Versão; Escritor contribuinte do
Guia 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 Enterprise
Linux; Co-escritor e co-mantenedor do Guia de Segurança do Red Hat Enterprise Linux; Escritor
contribuinte do Introdução à Administração de Sistemas Red Hat Enterprise Linux
John Ha — Escritor / Mantenedor Principal do Configurando e Administrando um Cluster do Red
Hat Cluster Suite; Escritor / Mantenedor Principal do Glossário da Red Hat; Escritor / Mantenedor
Principal do Guia de Instalação para as Arquiteturas IBM® S/390® e IBM® eServer™ zSeries® do
Red Hat Enterprise Linux; Co-escritor/co-mantenedor do Guia de Segurança do Red Hat Enterprise
Linux; 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
132

Red Hat Enterprise Linux 3 Guia de Segurança

Transcrição

Documentos relacionados

Prática certificada

FORMAÇÃO FEVEREIRO 2014 Porto XD nível 1 e 2 / Linux prático

Red Hat Enterprise Linux 6 Guia de Segurança

Acesso a Cartilha de Segurança elaborada pelo grupo.

migração de aplicações de escritório para o contexto do software

GHS International SDS V5 - Emerald Performance Materials

Como usar os cheats no pokemon fire red

Game Design - Red Dot Award

Sabre renova acordo de tecnologia com o maior grupo de locadoras

Visitantes da Brasil Game Show 2016 poderão participar da

red hat enterprise agreement brazil red hat contrato enterprise brasil