Red Hat Enterprise Linux 4 Guia de Segurança

Transcrição

Red Hat Enterprise Linux 4
Guia de Segurança
Red Hat Enterprise Linux 4: Guia de Segurança
Copyright © 2005 por Red Hat, Inc.
Red Hat, Inc.
1801 Varsity Drive Raleigh NC 27606-2072 USA Telefone: +1 919 754 3700 Telefone: 888 733 4281 Fax: +1 919 754 3701 PO Box 13588 Research Triangle Park NC 27709 USA
rhel-sg(PT)-4-Impressão-RHI (2004-09-30T17:12)
Copyright © 2005 Red Hat, Inc. Este material pode ser distribuído somente sob os termos e condições definidos na ’Open
Publication License’, versão 1.0 ou mais recente (a versão mais recente está disponível em
http://www.opencontent.org/openpub/).
É proibida a distribuição de versões substancialmente modificadas deste documento sem a permissão explícita do titular dos
direitos autorais.
É proibida a distribuição total ou parcial do trabalho envolvido neste manual, em qualquer formato de livro (papel), para fins
comerciais, sem a autorização prévia do titular dos direitos autorais.
Red Hat e o logo "Shadow Man" da Red Hat são marcas registradas da Red Hat, Inc. nos EUA e em outros países.
Todas as outras marcas referidas neste são de propriedade de seus respectivos titulares.
O número do código de segurança GPG em [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. Informações específicas da arquitetura ................................................................................. ii
2. Convenções de Documentos ................................................................................................. ii
3. Ative Sua Assinatura............................................................................................................. v
3.1. Prover um Login para a Red Hat ........................................................................... v
3.2. Prover Seu Número de Assinatura ......................................................................... v
3.3. Conectar Seu Sistema ............................................................................................ v
4. Mais por vir.......................................................................................................................... vi
4.1. Envie-nos Seu Feedback ....................................................................................... vi
I. Uma Introdução Genérica à Segurança ......................................................................................... i
1. Visão Geral de Segurança ..................................................................................................... 1
1.1. O que é Segurança em Computadores? ................................................................. 1
1.2. Controles de Segurança.......................................................................................... 5
1.3. Conclusão............................................................................................................... 6
2. Atacantes e Vulnerabilidades ................................................................................................ 9
2.1. Uma Breve História sobre Hackers........................................................................ 9
2.2. Ameaças à Segurança da Rede ............................................................................ 10
2.3. Ameaças à Segurança do Servidor....................................................................... 10
2.4. Ameaças à Segurança da Estação de Trabalho e PC Pessoal............................... 12
II. Configurando o Red Hat Enterprise Linux para Segurança................................................... 15
3. Atualizações de Segurança ................................................................................................. 17
3.1. Atualizando Pacotes............................................................................................. 17
4. Segurança da Estação de Trabalho...................................................................................... 23
4.1. Avaliando a Segurança da Estação de Trabalho................................................... 23
4.2. Segurança do BIOS e do Gestor de Início ........................................................... 23
4.3. Segurança da Senha ............................................................................................. 25
4.4. Controles Administrativos ................................................................................... 30
4.5. Serviços de Rede Disponíveis.............................................................................. 36
4.6. Firewalls Pessoais ................................................................................................ 39
4.7. Ferramentas de Comunicação de Segurança Aprimorada ................................... 39
5. Segurança do Servidor ........................................................................................................ 41
5.1. Protegendo Serviços com TCP Wrappers e xinetd ........................................... 41
5.2. Protegendo o Portmap.......................................................................................... 44
5.3. Protegendo o NIS ................................................................................................. 45
5.4. Protegendo o NFS ................................................................................................ 47
5.5. Protegendo o Servidor HTTP Apache ................................................................. 48
5.6. Protegendo o FTP ................................................................................................ 49
5.7. Protegendo o Sendmail ........................................................................................ 51
5.8. Verificando Quais Portas estão Escutando........................................................... 52
6. Redes Privadas Virtuais (Virtual Private Networks) ........................................................... 55
6.1. VPNs e Red Hat Enterprise Linux ....................................................................... 55
6.2. IPsec..................................................................................................................... 55
6.3. Instalação do IPsec............................................................................................... 56
6.4. Configuração Máquina-a-Máquina do IPsec ....................................................... 56
6.5. Configuração Rede-a-Rede do IPsec ................................................................... 60
7. Firewalls.............................................................................................................................. 65
7.1. Netfilter e iptables ........................................................................................... 66
7.2. Usando o iptables ............................................................................................ 67
7.3. Filtragem Comum do iptables ......................................................................... 68
7.4. Regras FORWARD e NAT ....................................................................................... 69
7.5. Vírus e Endereços IP Espionados (spoofed)........................................................ 71
7.6. iptables e Registro de Conexão ....................................................................... 72
7.7. ip6tables .......................................................................................................... 72
7.8. Recursos Adicionais............................................................................................. 73
III. Avaliando Sua Segurança .......................................................................................................... 75
8. Avaliação de Vulnerabilidade ............................................................................................. 77
8.1. Pensando Como o Inimigo................................................................................... 77
8.2. Definindo Avaliação e Testes ............................................................................... 78
8.3. Avaliando as Ferramentas .................................................................................... 79
IV. Intrusões e Resposta a Incidentes ............................................................................................. 83
9. Detecção de Invasão............................................................................................................ 85
9.1. Definindo Sistemas de Detecção de Intrusão....................................................... 85
9.2. IDS baseado no servidor ...................................................................................... 86
9.3. IDS baseado em rede ........................................................................................... 88
10. Resposta ao Incidente ....................................................................................................... 91
10.1. Definindo Resposta ao Incidente ....................................................................... 91
10.2. Criando um Plano de Resposta ao Incidente...................................................... 91
10.3. Implementando o Plano de Resposta ao Incidente ............................................ 93
10.4. Investigando o Incidente .................................................................................... 93
10.5. Restaurando e Recuperando Recursos ............................................................... 96
10.6. Reportando o Incidente ...................................................................................... 97
V. Apêndices ...................................................................................................................................... 99
A. Proteção ao Hardware e à Rede ....................................................................................... 101
A.1. Topologias de Rede Segura............................................................................... 101
A.2. Segurança de Hardware..................................................................................... 104
B. Exploits e Ataques Comuns ............................................................................................. 107
C. Portas Comuns ................................................................................................................. 111
Índice Remissivo.............................................................................................................................. 125
Considerações finais........................................................................................................................ 131
Introdução
Bem-vindo ao Guia de Segurança do Red Hat Enterprise Linux!
O Guia de Segurança do Red Hat Enterprise Linux é desenvolvido para auxiliar usuários do Red
Hat Enterprise Linux a aprender os processos e práticas para proteger estações de trabalho e 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, Thomas!
Este manual assume que você tem um conhecimento avançado do Red Hat Enterprise Linux. Se você
for um novo usuário ou tiver conhecimento básico a intermediário do Red Hat Enterprise Linux e
deseja mais informações sobre como utilizar o sistema, por favor consulte os seguintes manuais, que
abordam os aspectos fundamentais do Red Hat Enterprise Linux de forma mais detalhada que o Guia
de Segurança do Red Hat Enterprise Linux:
•
O Guia de Instalação do Red Hat Enterprise Linux traz informações sobre a instalação.
•
O Introdução à Administração de Sistemas Red Hat Enterprise Linux contém informações introdutórias para novos administradores de sistemas Red Hat Enterprise Linux.
•
O Guia de Administração de Sistemas Red Hat Enterprise Linux oferece informações detalhadas
sobre como configurar o Red Hat Enterprise Linux para servir suas necessidades particulares como
usuário. Este manual inclui alguns serviços que são abordados (sob o ponto de vista de segurança)
no Guia de Segurança do Red Hat Enterprise Linux.
•
O Guia de Referência do Red Hat Enterprise Linux traz informações detalhadas para a consulta dos
usuários mais experientes quando necessária, ao contrário das instruções passo-a-passo.
As versões HTML, PDF e RPM dos manuais estão disponíveis no CD de Documentação do Red Hat
Enterprise Linux e online: http://www.redhat.com/docs/.
ii
Introdução
Nota
Apesar deste manual refletir as informações mais recentes possíveis, leia as Notas da Versão do Red
Hat Enterprise Linux para acessar as informações que não estavam disponíveis antes da finalização
de nossa documentação. Elas podem ser encontradas no CD 1 do Red Hat Enterprise Linux e online:
http://www.redhat.com/docs/.
1. Informações específicas da arquitetura
Exceto quando informado, todas as informações contidas neste manual se aplicam somente ao processador x86 e aos processadores com as tecnologias Intel® Extended Memory 64 Technology (EM64T
da Intel®) e AMD64. Para obter informações de arquiteturas específicas, consulte o Guia de Instalação do Red Hat Enterprise Linux.
2. Convenções de Documentos
Ao ler este manual, determinadas palavras estão representadas com fontes, tipos, tamanhos e pesos
diferentes. Este destaque é sistemático; palavras diferentes são representadas no mesmo estilo para
indicar sua inclusão em uma categoria específica. Os tipos de palavras representadas desta maneira
incluem as seguintes:
comando
Os comandos do Linux (e comandos de outros sistemas operacionais, quando usados) são 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 codenomes 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.
Introdução
iii
[tecla]
Uma tecla do teclado é exibida neste estilo. Por exemplo:
Para usar a tecla complementar [Tab] num terminal, digite um caractere e então pressione a tecla
[Tab]. Seu terminal exibe uma lista dos arquivos contidos no diretório que começam com esta
letra.
[tecla]-[combinação]
Uma combinação de sequência de teclas é representada desta maneira. Por exemplo:
A combinação de teclas [Ctrl]-[Alt]-[Espaço] termina sua sessão gráfica, retornando à tela ou ao
console da autenticação gráfica.
texto exibido em uma interface GUI (gráfica)
Um título, palavra ou frase na tela ou janela da interface GUI é exibida neste estilo. O texto
exibido neste estilo é usado na identificação de uma tela GUI específica ou um elemento de uma
tela GUI (como o texto associado a uma caixa de verificação ou campo). Exemplo:
Selecione a caixa de verificação Solicitar Senha se você deseja que seu protetor de tela solicite
uma senha antes de ser desbloqueado.
nível superior de um menu em uma tela ou janela GUI
Uma palavra neste estilo indica que a palavra está no nível superior de um menu suspenso (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:
$
#
iv
Introdução
[stephen@maturin stephen]$
leopard login:
input do usuário
O texto que o usuário precisa digitar, na linha de comandos ou em uma caixa de texto em uma
tela GUI, é apresentado neste estilo. No exemplo a seguir, text é exibido neste estilo:
Para inicializar seu sistema no programa de instalação em modo texto, você deve digitar o comando text no prompt boot:.
substituível
Texto usado para exemplos que devem ser subtituídos com dados providos pelo usuário são
apresentados neste estilo. No exemplo a seguir, version-number é exibido neste estilo:
O
diretório da fonte do kernel é /usr/src/ version-number /,
version-number é a versão do kernel instalado neste sistema.
onde
Adicionalmente, nós utilizamos diversas estratégias diferentes para chamar sua atenção a 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 terão efeito até que você
reinicie o daemon do DHCP.
Atenção
Não execute tarefas de rotina como root — use uma conta de usuário comum, a não ser que você
precise usar a conta root para tarefas de administração do sistema.
Introdução
v
Aviso
Cuidado para remover somente as partições necessárias do Red Hat Enterprise Linux. Remover
outras partições pode resultar na perda de dados ou num ambiente de sistema corrompido.
3. Ative Sua Assinatura
Antes de poder acessar as informações de manutenção do software e serviços, e a documentação de
suporte inclusa em sua assinatura, você deve ativar sua assinautra registrando-a na Red Hat. O registro
inclui estes passos simples:
•
Prover um login para a Red Hat
•
Prover um número para a assinatura
•
Conectar seu sistema
Na primeira vez que iniciar a instalação de seu Red Hat Enterprise Linux, você verá o pedido de
registro na Red Hat usando o Agente de Configuração. Se você seguir os pedidos durante o Agente
de Configuração, poderá completar os passos do registro e ativar sua assinatura.
Se você não puder completar o registro durante o Agente de Configuração (que requer
acesso à rede), pode, alternativamente, completar o processo de registro da Red Hat online:
http://www.redhat.com/register/.
3.1. Prover um Login para a Red Hat
Se você ainda não possui um login para a Red Hat, pode criá-lo quando for solicitado no Agente de
Configuração ou online em:
https://www.redhat.com/apps/activate/newlogin.html
Um login da Red Hat habilita seu acesso a:
•
Atualizações, erratas e manutenção do software através da Red Hat Network
•
Recursos do suporte técnico, documentação e base de dados de conhecimento (knowledgebase) da
Red Hat
Se você esqueceu seu login da Red Hat, pode fazer uma busca online em:
https://rhn.redhat.com/help/forgot_password.pxt
3.2. Prover Seu Número de Assinatura
Seu número de assinatura está localizado no pacote que acompanha seu pedido. Caso seu pacote não
inclua um número de assinatura, sua assinautra já foi ativada e, portanto, você pode pular este passo.
Você pode prover seu número de assinatura ao ser solicitado durante o Agente de Configuração ou
visitando http://www.redhat.com/register/.
vi
Introdução
3.3. Conectar Seu Sistema
O Cliente de Registro da Red Hat Network auxilia na conexão de seu sistema para que você possa
obter as atualizações e efetuar a administração de sistemas. Há três maneiras para conectar:
1. Durante o Agente de Configuração — Selecione as opções Enviar informações de hardware
e Enviar lista de pacotes do sistema quando aparecerem.
2. Após completar o Agente de Configuração — No Menu Principal, clique em Ferramentas
do Sistema, e então selecione Red Hat Network.
3. Após completar o Agente de Configuração — Invoque o seguinte na janela de comandos como
usuário root:
• /usr/bin/up2date --register
4. Mais por vir
O Guia de Segurança do Red Hat Enterprise Linux é parte do crescente comprometimento da Red
Hat em prover suporte e informações úteis e oportunas para usuários do Red Hat Enterprise Linux.
Conforme novas ferramentas e metodologias de segurança são criadas, este guia será expandido para
incluí-las.
4.1. Envie-nos Seu Feedback
Se você encontrar um erro de digitação no Guia de Segurança do Red Hat Enterprise Linux ou se
pensar numa maneira de aprimorar este manual, nós gostaríamos de saber! Por favor, submeta um relatório ao Bugzilla (http://bugzilla.redhat.com/bugzilla/) sobre o componente rhel-sg.
Certifique-se de mencionar o identificador do manual:
rhel-sg(PT)-4-Impressão-RHI (2004-09-30T17:12)
Ao mencionar o identificador, nós saberemos exatamente qual versão do manual você possui.
Se você tiver alguma sugestão para melhorar a documentação, tente ser o mais específico possível.
Se encontrou um erro, por favor inclua o número da seção e trechos de texto próximo ao erro para
podermos encontrá-lo facilmente.
I. Uma Introdução Genérica à Segurança
Esta parte traz a definição de segurança da informação, sua história e o setor que foi desenvolvido em
torno desta questão. Também aborda alguns dos riscos enfrentados por usuários e administradores de
computadores.
Índice
1. Visão Geral de Segurança .............................................................................................................. 1
2. Atacantes e Vulnerabilidades......................................................................................................... 9
Capítulo 1.
Visão Geral de Segurança
Devido ao crescente suporte de computadores de rede poderosos para fazer negócios e manter controle
de nossas informações pessoais, as indústrias têm sido constituídas com a prática de segurança nos
computadores e nas redes. Empreendimentos têm solicitado o conhecimento e habilidades de peritos
em segurança para auditar sistemas apropriadamente e customizar soluções para os requerimentos
operacionais das organizações. Já que a maioria das organizações são dinâmicas por natureza, com
funcionários acessando os recursos de IT da empresa localmente e remotamente, a necessidade de
ambientes de rede seguros se tornou ainda mais acentuada.
Infelizmente, a maioria das empresas (assim como usuários individuais) encaram a segurança como
uma preocupação em segundo plano, um processo visto em favor de questões de aumento de poder,
produtividade e orçamentárias. Implementações de segurança apropriadas são frequentemente 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 tentativas de intrusão.
1.1. O que é Segurança em Computadores?
Segurança em computadores é um termo geral que abrange uma grande área da computação e 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 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 na segurança de dados.
Um número cada vez maior de pessoas está utilizando seu computador pessoal para acessar os recursos
que a Internet oferece. De pesquisas e recuperação de informações a correspondência eletrônica e
transações comerciais, a Internet é considerada um dos desenvolvimentos mais importantes do século
XX.
A Internet e seus protocolos mais antigos, no entanto, foram desenvolvidos como um sistema baseado
na confiança. Ou seja, o Protocolo de Internet (IP) não foi desenvolvido para ser intrinsicamente 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. A cronologia a seguir lista alguns dos eventos mais importantes da computação e segurança da
informação, e suas importâncias hoje.
1.1.2.1. Os Anos 30 e 40
•
Criptógrafos poloneses inventam a máquina Enigma em 1918, um dispositivo rotor eletromecânico
de cifras que converte mensagens puramente texto em um resultado criptografado. Desenvolvido
originalmente para proteger comunicações bancárias, o exército alemão vê no dispositivo o potencial de proteger as comunicações durante a 2a Guerra Mundial. Um matemático brilhante chamado
Alan Turing desenvolve um método para quebrar os códigos da Enigma, possibilitando às forças
aliadas desenvolver a Colossus, uma máquina que recebeu créditos por findar a guerra um ano antes.
1.1.2.2. Os Anos 60
•
Estudantes do Massachusetts Institute of Technology (MIT) formaram o Tech Model Railroad Club
(TMRC), que começou a explorar e programar o sistema de computadores de grande porte PDP-1
da escola. O grupo evetualmente usa o termo "hacker" no contexto em que é conhecido hoje.
•
O DoD (Departamento de Defesa dos EUA) cria a Rede da Agência de Projetos de Pesquisa
Avançada (Advanced Research Projects Agency Network - ARPANet), que ganha popularidade
em pesquisas e círculos acadêmicos como um condutor do intercâmbio eletrônico de informações
e dados. Isto pavimentou o caminho para a criação da rede de transporte conhecida hoje como
Internet.
•
Ken Thompson desenvolve o sistema operacional UNIX, amplamente aclamado como o sistema
operacional mais "hacker-friendly" devido às suas ferramentas acessíveis a desenvolvedores e 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.
3
1.1.2.3. Os Anos 70
•
Bolt, Beranek e Newman, uma empresa de pesquisa e desenvolvimento em computadores para o
governo e indústria, desenvolve o protocolo Telnet, uma extensão pública da ARPANet. Isto abre
portas para o uso público de redes de dados antes restritas a empresas do governo e pesquisadores
acadêmicos. O Telnet, no entanto, também é discutivelmente o protocolo mais inseguro para redes
públicas, de acordo com diversos pesquisadores em segurança.
•
Steve Jobs e Steve Wozniak fundaram a Apple Computer e começaram a comercializar o 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.
•
Jim Ellis e Tom Truscott criam o USENET, um sistema de estilo mural (bulletin-board) para comunicação eletrônica entre usuários díspares. O USENET torna-se rapidamente um dos meios mais
conhecidos de intercâmbio de idéias em computação, redes e, obviamente, cracking.
1.1.2.4. Os Anos 80
•
A IBM desenvolve e comercializa PCs baseados no microprocessador Intel 8086, uma arquitetura
relativamente barata que trouxe a computação do escritório para casa. Isto serve para transformar o
PC numa ferramenta comum e acessível, que era relativamente poderosa e fácil de usar, ajudando a
proliferação deste tipo de hardware nos lares e escritórios de usuários maldosos.
•
O Protocolo de Controle de Transmissão (Transmission Control Protocol), desenvolvido por Vint
Cerf, é dividido em duas partes distintas. O Protocolo de Internet (IP) surge desta divisão, e o
protocolo combinado TCP/IP torna-se o padrão para toda a comunicação via Internet de hoje.
•
Baseada em desenvolvimentos na área de phreaking, ou explorando e hackeando o sitema de 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 haqueava) é surpreendida pelas
autoridades após nove dias de cracking no qual a gang violou os sistemas de uma localização
altamente secreta, o Los Alamos National Laboratory, um local de pesquisas de armas nucleares.
•
’The Legion of Doom’ e o ’Chaos Computer Club’ são dois grupos pioneiros de crackers que
começam a explorar as vulnearbilidades em computadores e redes eletrônicas de dados.
•
O Ato de Fraude e Abuso de Computador de 1986 (Computer Fraud and Abuse Act) foi votado
e transformado em lei pelo congresso americano baseado nos exploits de Ian Murphy, também
conhecido com Capitão Zap, que violou computadores militares, roubou informações de bancos
de dados de pedidos de mercadorias e utilizou os quadros restritos de distribuição de telefone do
governo para efetuar ligações telefônicas.
•
Baseado no Ato de Fraude e Abuso de Computador, a côrte condena Robert Morris, um graduando,
por distribuir o vírus Morris Worm para mais de 6.000 computadores vulneráveis conectados à 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.
4
1.1.2.5. Os Anos 90
•
A ARPANet é desativada. O tráfego desta rede é transferido para a Internet.
•
Linus Torvalds desenvolve o kernel do Linux para utilização com o sistema operacional GNU. O
amplo desenvolvimento e adoção do Linux se deve, em grande parte, à colaboração e comunicação
de usuários e desenvolvedores via Internet. Devido às suas raízes no Unix, o Linux é mais popular
entre hackers e administradores que o consideram muito útil para elaborar alternativas seguras para
servidores legados que rodam sistemas operacionais proprietários (com código fechado).
•
O navegador (browser) gráfico é criado e estimula uma demanda exponencialmente alta por acesso
público à Internet.
•
Vladimir Levin é cúmplice da transfência ilegal de US$10 milhões em fundos para diversas contas
crackeando o banco de dados central do CitiBank. Levin é preso pela Interpol e quase todo o
dinheiro é recuperado.
•
Possivelmente, o precursor de todos os crackers é Kevin Mitnick, que hackeou diversos sistemas
corporativos roubando tudo - de informações pessoais de celebridades a mais de 20.000 números
de cartões de crédito e código fonte de software proprietário. Ele é preso, condenado por fraude e
fica 5 anos na prisão.
•
Kevin Poulsen e um cúmplice desconhecido manipulam sistemas de telefonia de uma estação de
rádio para ganhar carros e prêmios em dinheiro. Ele é condenado por fraude e sentenciado a 5 anos
de prisão.
•
As histórias de cracking e phreaking se tornam lendas; e muitos crackers em potencial se reúnem
na convenção anual DefCon para celebrar o cracking e trocar idéias entre seus pares.
•
Um estudante israelense de 19 anos é preso e condenado por coordenar várias violações aos 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 Denial of Service Distribuído (Distributed Denial of Service DDoS) foi espalhado a vários servidores de sites de maior tráfego na Internet. O ataque tomou 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 945 milhões de pessoas usam ou
usaram a Internet ao redor do mundo (Computer Industry Almanac, 2004). Ao mesmo tempo:
5
•
Num dia qualquer, são estimados 225 grandes incidentes de exploração de vulnerabilidades reportados ao Centro de Coordenação da CERT na Universidade Carnegie Mellon. 1
•
Em 2003, o número de incidentes reportados à CERT pulou para 137.529 de 82.094 em 2002 e de
52.658 em 2001.2
•
O impacto econômico am nível mundial dos três vírus mais perigosos da Internet nos últimos três
anos foi estimado em US$13.2 bilhões.3
A segurança em computadores tornou-se uma despesa quantificável e justificável em todos os orçamentos de TI. Empresas que requerem integridade 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 24 horas por dia, sete dias por semana. Cair nas mãos de
usuários, processos ou ataques maldosos coordenados é uma ameaça direta ao sucesso da empresa.
Infelizmente, a segurança de sistemas e redes pode ser uma tarefa difícil, que requer o conhecimento
complexo de como a empresa encara, usa, manipula e transmite suas informações. Entender a maneira
como a empresa (e as pessoas que a constituem) conduz os negócios é primordial para a 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 sejam obtidas por um indivíduo não autorizado para propósitos maldosos como
roubo de identidade ou fraude de crédito.
•
Integridade — As informações não devem ser alteradas de modo a torná-las incompletas ou 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. A disponibilidade é a garantia de que aquela informação pode ser obtida com uma frequência e periodicidade pré-definidas. Isto é frequentemente medido em termos de porcentagens e
definido formalmente nos Acordos de Nível de Serviço (Service Level Agreements - SLAs) usados
por provedores de serviços de rede e seus clientes corporativos.
1.2. Controles de Segurança
A segurança em computadores é frequentemente dividida em três categorias principais, comumente
referidas como controles:
1.
2.
3.
Fonte: http://www.cert.org
Fonte: http://www.cert.org/stats/
Fonte: http://www.newsfactor.com/perl/story/16407.html
6
•
Físicos
•
Técnicos
•
Administrativos
Estas três categorias abrangentes definem os objetivos principais de uma implementação de segurança
apropriada. Dentre estes controles há sub-categorias que detalham minuciosamente os controles e
como implementá-los.
1.2.1. Controles Físicos
O controle físico é a implementação de medidas de segurança em uma estrutura definida usada para
deter ou evitar acesso não autorizado a material delicado. Alguns exemplos de controles físicos:
•
Câmeras de vigilância de circuito fechado
•
Sistemas de alarme térmicos ou de movimento
•
Guardas de segurança
•
Identidades com foto
•
Portas de aço trancadas com fechaduras ’dead-bolt’
•
Biométrica (inclui impressão digital, voz, rosto, íris, manuscrito e outros métodos automatizados
usados para reconhecer indivíduos)
1.2.2. Controles Técnicos
O controle técnico uitiliza a tecnologia como base para controlar o acesso e o uso de dados delicados
através de uma estrutura física e através de uma rede. Os controles técnicos têm um escopo de grande
alcance e incluem tecnologias como:
•
Criptografia
•
Cartões inteligentes
•
Autenticação de rede
•
Listas de controle de acesso (Access control lists - ACLs)
•
Software de auditoria de integridade de arquivos
1.2.3. Controles Administrativos
Os controles administrativos definem os fatores humanos da segurança. Envolvem todos os níveis de
pessoal em uma empresa e determinam quais usuários têm acesso a quais recursos e informações,
através dos seguintes meios:
•
Treinamento e conscientização
•
Preparação para desastres e planos de recuperação
•
Recrutamento de pessoal e estratégias de separação
•
Registro e avaliação de pessoal
7
1.3. Conclusão
Agora que você aprendeu um pouco sobre as origens, razões e aspectos da segurança, pode determinar
o curso de ações apropriado em relação ao Red Hat Enterprise Linux. É importante saber quais fatores
e condições compoem a segurança para planejar e implementar uma estratégia apropriada. Com estas
informacões em mente, o processo pode ser formalizado e o caminho torna-se mais claro conforme
você aprofundar nas especificidades do processo de segurança.
8
Capítulo 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, madosas ou criminosas. O termo mais correto para este tipo de hacker de
computador é cracker — um termo criado por hackers em meados dos anos 80 para diferenciar as
duas comunidades.
2.1.1. Tonalidades de Cinza
Há diversos grupos distintos de indivíduos que encontram e exploram vulnerabilidades em redes e
sistemas. Eles são descritos pela tonalidade do chapéu que "vestem" ao realizar suas investigações em
segurança, e essa tonalidade indica suas intenções.
O hacker de chapéu branco é aquele que testa redes e sistemas para examinar sua performance e
determinar o quão vulneráveis são às intrusões. Geralmente, hackers de chapéu branco violam seus
próprios sistemas ou sistemas de um cliente que o empregou especificamente para auditar a segurança.
Pesquisadores acadêmicos e consultores profissionais de segurança são dois exemplos de hackers de
chapéu branco.
Um hacker de chapéu preto é sinônimo de um cracker. Em geral, crackers são menos focados em
programação e no lado acadêmico de violar sistemas. Eles comumente confiam em programas de
cracking e exploram vulnerabilidades conhecidas em sistemas para descobrir informações importantes
para ganho pessoal ou para danificar a rede ou sistema alvo.
O hacker de chapéu cinza, por outro lado, tem as habilidades e intenções de um hacker de chapéu
branco na maioria dos casos, mas por vezes utiliza seu conhecimento para propósitos menos nobres.
Um hacker de chapéu cinza pode ser descrito como um hacker de chapéu branco que às vezes veste
um chapéu preto para cumprir sua própria agenda.
Hackers de chapéu cinza tipicamente se enquadram em outro tipo de ética, que diz ser aceitável violar
sistemas desde que o hacker não cometa roubo ou infrinja a confidencialidade. Alguns argumentam,
no entanto, que o ato de violar um sistema por si só já é anti-ético.
10
Capítulo 2. Atacantes e Vulnerabilidades
Independentemente da intenção do intruso, é importante saber das fraquezas que um cracker 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 perceber 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 máquinas
locais.
2.2.1.2. Servidores Centralizados
Outra potencial armadilha na rede é o uso da computação centralizada. Uma forma comum de corte
de gastos em muitas empresas é consolidar todos os serviços em apenas uma máquina poderosa.
Isto pode ser conveniente, pois é mais fácil de gerenciar e custa bem menos que configurações de
servidores múltiplos. No entanto, um servidor centralizado apresenta apenas um ponto único de falha
na rede. Se o servidor central for comprometido, pode danificar a rede ou inutilizá-la, um cenário
propício para a manipulação ou roubo de dados. Nestas situações um servidor central torna-se uma
porta aberta, permitindo acesso à toda rede.
2.3. Ameaças à Segurança do Servidor
A segurança do servidor é tão importante quanto a segurança da rede porque os servidores 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 Enterprise Linux contém mais de 1000 aplicações e pacotes
de bibliotecas. No entanto, a maioria dos adminstradores de servidor não optam por instalar todos
os pacotes da distribuição; preferem, ao invés disso, instalar os pacotes básicos, incluindo diversas
aplicações para servidor.
11
Uma ocorrência comum dentre administradores de sistemas é instalar o sistema operacional sem
prestar atenção em quais pacotes realmente estão sendo instalados. Isto pode ser problemático, pois
serviços desnecessários podem ser instalados, configurados com opções default e possivelmente
acionados. Isto pode fazer com que serviços não quistos, como Telnet, DHCP ou DNS, sejam
executados em um servidor ou estação de trabalho sem que o adminstrador perceba, o que pode
causar tráfego indesejado no servidor, ou até mesmo uma via potencial para crackers ao sistema. Veja
Capítulo 5 para informações sobre fechar portas e desativar serviços não utilizados.
2.3.2. Serviços Não Consertados (unpatched)
A maioria das aplicações de servidor inclusas em uma instalação default são sólidas, partes de software
testadas exaustivamente. Sendo utilizadas em ambientes de produção por muitos anos, seus códigos
têm sido constantemente refinados e muitos dos erros (bugs) foram encontrados e consertados.
Entretanto, não existe software perfeito e sempre há espaço para mais aprimoramento. Além disso,
software mais novos frequentemente não são rigorosamente testados como se espera, porque chegaram
recentemente a ambientes de produção ou porque talvez não sejam tão populares quanto outros software 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 superconfiantes 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
1.
Fonte: http://www.sans.org/newlook/resources/errors.html
12
através de redes confiáveis, mas essa suposição deixa de ser verdadeira a partir do momento em que o
serviço for disponibilizado através da Internet — que por si só é essencialmente não confiável.
Um tipo de serviço de rede inseguro são aqueles que requerem nomes de usuário e senha não 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 também podem ser facilmente enquadrados no que a indústria da segurança chama de
ataque ’man-in-the-middle’. Neste tipo de ataque um cracker redireciona o tráfego de rede, enganando
um servidor de nomes crackeado na rede, apontando-o para sua máquina ao invés do servidor 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
as informações. Desta maneira um cracker consegue obter senhas administrativas e dados sem que o
servidor ou o usuário perceba.
Outra categoria de serviços inseguros são sistemas de arquivos de rede e serviços de informação, como
NFS ou NIS, desenvolvidos explicitamente para uso em LANs, mas que, infelizmente, têm seu uso
extendido para WANs (para usuários remotos). O NFS não tem, por default, nenhuma autenticação
ou mecanismos de segurança configurados para prevenir um cracker de montar o compartilhamento
do NFS e acessar qualquer coisa contida nele. O NIS também tem informações vitais que devem
ser conhecidas por qualquer computador ou rede, incluindo senhas e permissões de arquivo, em um
banco de dados ACSII ou DBM (derivado do ASCII) somente-texto. Um cracker que obtém acesso
a este banco de dados poderá acessar qualquer conta de usuário de uma rede, inclusive a conta do
administrador.
Por default, o Red Hat Enterprise Linux é lançado com todos estes serviços desligados. No entanto,
como administradores frequentemente são forçados a usá-los, é essencial configurá-los 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 representam uma das maneiras mais fáceis para um atacante obter acesso a um sistema.
Para saber mais sobre como evitar armadilhas comuns ao criar uma senha, veja a Seção 4.3.
2.4.2. Aplicações Cliente Vulneráveis
Apesar de um administrador poder ter um servidor completamente seguro e consertado, isto não 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
13
versão 1 do SSH são vulneráveis a um ataque ’X-forwarding’ de servidores SSH maléficos. Uma vez
conectado ao servidor, o atacante pode capturar discretamente quaisquer teclas pressionadas e cliques
de mouse efetuados pelo cliente através da rede. Este problema foi consertado na segunda versão do
protocolo SSH, mas depende do usuário monitorar aplicações com tais vulnerabilidades e atualizá-las
quando necessário.
O Capítulo 4 aborda mais detalhadamente os passos que administradores e usuários domésticos devem
seguir para limitar a vulnerabilidade de estações de trabalho.
14
II. Configurando o Red Hat Enterprise Linux para
Segurança
Esta parte informa e instrui os administradores sobre as técnicas e ferramentas apropriadas a usar
para proteger estações de trabalho e servidores Red Hat Enterprise Linux e recursos de rede. Também
aborda como criar conexões seguras, bloquear portas e serviços, e como implementar a filtragem ativa
para evitar a intrusão na rede.
Índice
3. Atualizações de Segurança ........................................................................................................... 17
4. Segurança da Estação de Trabalho ............................................................................................. 23
5. Segurança do Servidor ................................................................................................................. 41
6. Redes Privadas Virtuais (Virtual Private Networks)................................................................. 55
7. Firewalls......................................................................................................................................... 65
Capítulo 3.
Atualizações de Segurança
Conforme as vulnerabilidades de segurança são descobertas, o software afetado deve ser atualizado
para limitar os potenciais riscos de segurança. Se o software é parte de um pacote de uma distribuição
do Red Hat Enterprise Linux atualmente suportada, a Red Hat, Inc. está comprometida em lançar
pacotes atualizados que consertem as vulnerabilidades assim que possível. Frequentemente, os 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 Red Hat Enterprise Linux, testado pela equipe
de controle de qualidade da Red Hat e lançado como uma atualização de errata. Entretanto, se o comunicado não inclui um conserto, um desenvolvedor da Red Hat trabalha juntamente ao mantenedor
do software para consertar o problema. Após consertar o problema, o pacote é testado e lançado como
uma atualização de errata.
Se for lançada uma atualização de errata para um software utilizado em seu sistema, é altamente
recomendável que você atualize os pacotes afetados assim que possível, para mininmizar o tempo
durante o qual seu sistema está potencialmente vulnerável.
3.1. Atualizando Pacotes
Ao atualizar o software de um sistema, é importante fazer o download da atualização de uma fonte
confiável. Um atacante pode reconstruir facilmente um pacote com a mesma versão daquele que 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 encontrar informações sobre as atualizações de errata:
1. Listadas e disponíveis para download na Red Hat Network
2. Listadas e não linkadas no site de Erratas da Red Hat
Nota
Começando pela linha de produtos Red Hat Enterprise Linux, os pacotes atualizados podem ser
baixados somente pela Red Hat Network. Apesar do site de Erratas da Red Hat conter informações
atualizadas, não contém os pacotes para download.
3.1.1. Usando a Red Hat Network
A Red Hat Network permite que você automatize a maior parte do processo de atualização. Ela 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. Essas informações são mantidas
confidenciais e não são distribuídas a ninguém. São usadas somente para determinar quais atualizações
18
Capítulo 3. Atualizações de Segurança
de errata são aplicáveis para cada sistema. Sem o perfil, a Red Hat Network não pode determinar se
um sistema precisa de atualizações. Quando uma errata de segurança (ou qualquer tipo de errata) é
lançada, a Red Hat Network envia um email com a descrição da errata assim como quais sistemas são
afetados por ela. Para aplicar a atualização, você pode usar o Agente de Atualizações Red Hat ou
agendar a atualização do pacote pelo site http://rhn.redhat.com.
Dica
O Red Hat Enterprise Linux inclui a Ferramenta de Notificação de Alerta da Red Hat Network,
um ícone conveniente no painel que exibe alertas quando há uma atualização para um sistema Red
Hat Enterprise Linux registrado. Consulte a seguinte URL para mais informações sobre o applet:
http://rhn.redhat.com/help/basic/applet.html
Para saber mais sobre os benefícios da Red Hat Network, consulte o Guia de
Referência da Red Hat Network (Red Hat Network Reference Guide) disponível em
http://www.redhat.com/docs/manuals/RHNetwork/ ou visite http://rhn.redhat.com.
Importante
Antes de instalar qualquer errata de segurança, certifique-se de ler todas as instruções especiais
contidas no relatório da errata e executá-las. Consulte a Seção 3.1.5 para instruções gerais sobre
como aplicar as alterações feitas por uma atualização de errata.
3.1.2. Usando o Site de Erratas da Red Hat
Quando os relatórios de erratas de segurança são lançados, são publicados no site de Erratas da Red
Hat http://www.redhat.com/security/. A partir desta página, selecione o produto e versão de seu 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 a brecha na segurança.
Para fazer o download do(s) pacote(s) atualizado(s), clique no link para se logar na Red Hat Network,
depois clique no(s) nome(s) do(s) pacote(s) e salve-os no disco rígido. É altamente recomendável que
você crie um novo diretório como /tmp/atualizações e salve todos os pacotes baixados ali.
3.1.3. Verificando Pacotes Assinados
Todos os pacotes do Red Hat Enterprise Linux são assinados com a chave GPG da Red Hat, Inc..
GPG significa GNU Privacy Guard, ou GnuPG, um pacote de software livre usado para garantir a
autenticidade dos arquivos distribuídos. Por exemplo: uma chave privada (chave secreta) mantida
pela Red Hat tranca o pacote enquanto a chave pública o destranca e o verifica. Se a chave pública
distribuída pela Red Hat não bate com a chave privada durante a verificação RPM, o pacote pode ter
sido alterado e, portanto, não é confiável.
O utilitário RPM do Red Hat Enterprise Linux tenta automaticamente verificar a assinatura GPG de
um pacote RPM antes de instalá-lo. Se a chave GPG da Red Hat não está instalada, instale-a a partir
de uma localidade segura e estática, como um CD-ROM do Red Hat Enterprise Linux.
19
Assumindo que o CD-ROM esteja montado em /mnt/cdrom, use o seguinte comando para importá-la
para o chaveiro (um banco de dados do sistema com chaves confiáveis):
rpm --import /mnt/cdrom/RPM-GPG-KEY
Para exibir uma lista com todas as chaves instaladas para verificação de RPM, execute o seguinte
comando:
rpm -qa gpg-pubkey*
Para a chave da Red Hat, o output inclui o seguinte:
gpg-pubkey-db42a60e-37ea5438
Para exibir detalhes sobre uma chave específica, use o comando rpm -qi seguido do output do comando anterior, conforme o exemplo:
rpm -qi gpg-pubkey-db42a60e-37ea5438
É extremamente importante verificar a assinatura dos arquivos RPM antes de instalá-los. Este passo
assegura que eles não foram alterados depois do lançamento dos pacotes pela Red Hat, Inc.. Para
verificar todos os pacotes do download de uma só vez, submeta o seguinte comando:
rpm -K /tmp/updates/*.rpm
Se a chave GPG for verificada com sucesso, o comando retorna gpg OK para cada pacote. Caso
contrário, certifique-se de usar a chave pública correta da Red Hat, assim como verificar a fonte do
conteúdo. Os pacotes que não passarem na verificação GPG não devem ser instalados, pois podem ter
sido alterados por terceiros.
Após verificar as chaves GPG e fazer o download de todos os pacotes associados ao relatório da errata,
instale os pacotes como root em uma janela de comandos.
3.1.4. Instalando Pacotes Assinados
A instalação da maioria dos pacotes pode ser feita com segurança (exceto pacotes do kernel), submetendo o seguinte comando:
rpm -Uvh /tmp/updates/*.rpm
Para pacotes do kernel, use o seguinte comando:
rpm -ivh /tmp/updates/ kernel-package
kernel-package
No exemplo anterior, substitua
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.
20
Nota
Não é necessário remover o kernel antigo. O gestor de início default, GRUB, permite a instalação de
kernels múltiplos, dos quais escolhemos um no menu de inicialização da máquina.
Importante
Antes de instalar qualquer errata de segurança, certifique-se de ler todas as instruções especiais
contidas no relatório da errata e executá-las. Consulte a Seção 3.1.5 para instruções gerais sobre
como aplicar as alterações feitas por uma atualização de errata.
3.1.5. Aplicando as Alterações
Após fazer o download e instalar as erratas de segurança através da Red Hat Network ou do site de
erratas da Red Hat, é importante parar de usar o software antigo e passar a usar o novo. O modo como
isso é feito depende do tipo de software que foi atualizado. A lista a seguir aponta as categorias gerais
de software e oferece instruções para usar as versões atualizadas após uma atualização de pacotes.
Nota
Em geral, reinicializar o sistema é a maneira mais certa de garantir que a versão mais recente de um
pacote de software é usada; entretanto, esta opção nem sempre está disponível ao administrador
de sistemas.
Aplicações
Aplicações em espaço de usuário (user-space) são quaisquer programas que podem ser iniciados
por um usuário do sistema. Geralmente, estas aplicações são usadas somente quando um usuário,
um script ou um utilitário de tarefa automatizada as lança, e não persistem por longos períodos.
Após uma aplicação em espaço de usuário ser atualizada, pare todas as instâncias da aplicação
no sistema e lance o programa novamente a fim de usar a versão atualizada.
Kernel
O kernel é o componente central do software do sistema operacional Red Hat Enterprise Linux.
Ele gerencia o acesso à memória, ao processador e periféricos e também agenda todas as tarefas.
Devido sua função central, o kernel não pode ser reiniciado sem também parar o computador.
Portanto, uma versão atualizada do kernel não pode ser usada até que o sistema seja 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.
21
Para determinar quais aplicações estão relacionadas a uma determinada 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 persistentes de servidor lançados durante o processo de inicialização. Exemplos de serviços SysV incluem sshd, vsftpd e xinetd.
Como estes programas geralmente persistem na memória enquanto a máquina é reinicializada,
cada serviço SysV atualizado deve ser parado e relançado após o upgrade do pacote. Isto pode
ser feito usando a Ferramenta de Configuração dos Serviços ou se autenticando a uma janela
de comandos root e submetendo o comando /sbin/service como no exemplo seguinte:
/sbin/service
service-name
restart
service-name
pelo nome do serviço, como sshd.
Consulte o capítulo intitulado Controlando Acesso aos Serviços no Guia de Administração de
Sistemas Red Hat Enterprise Linux para mais informações sobre a Ferramenta de Configuração
dos Serviços.
Serviços xinetd
Os serviços controlados pelo super serviço xinetd rodam somente quando há uma conexão
ativa. Exemplos de serviços controlados pelo xinetd incluem Telnet, IMAP e POP3.
Como novas instâncias destes serviços são lançadas pelo xinetd cada vez que um novo pedido é
recebido, as conexões que ocorrem depois de um upgrade são feitas pelo software atualizado. No
entanto, se há conexões ativas no momento em que o serviço controlado xinetd é atualizado,
elas são feitas pela versão antiga do software.
Para terminar instâncias antigas de um serviço em particular controlado pelo xinetd, faça o
upgrade do pacote do serviço e então pare todos os processos sendo executados. Primeiro, 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 anterior, substitua PID pelo número de identificação do processo (encontrado
na segunda coluna do comando ps) de uma sessão IMAP.
Para terminar todas as sessões IMAP ativas, submeta o seguinte comando:
killall imapd
Consulte o capítulo intitulado TCP Wrappers e xinetd no Guia de Referência do Red Hat
Enterprise Linux para informações gerais sobre o xinetd.
22
Capítulo 4.
Segurança da Estação de Trabalho
Proteger um ambiente Linux começa pela estação de trabalho. Na proteção de sua máquina pessoal
ou sistema corporativo, uma boa política de segurança começa pelo computador individual. Afinal de
contas, uma rede de computadores é tão segura quanto seu nódulo mais vulnerável.
4.1. Avaliando a Segurança da Estação de Trabalho
Ao avaliar a segurança de uma estação de trabalho Red Hat Enterprise Linux, considere o seguinte:
•
Segurança do BIOS e Gestor de Início — Um usuário não autorizado pode acessar fisicamente a
máquina e inicializá-la como um usuário simples ou no modo de recuperação sem uma senha?
•
Segurança da Senha — Quão seguras são as senhas de conta de usuário na máquina?
•
Controles Administrativos — Quem tem uma conta no sistema e quanto controle administrativo
eles têm?
•
Serviços Disponíveis na Rede — Quais serviços estão escutando por pedidos da rede? Eles realmente devem estar rodando?
•
Firewalls Pessoais — Qual o tipo de firewall necessário (caso haja)?
•
Ferramentas de Comunicação para Segurança Aprimorada — Quais ferramentas devem ser usadas
para a comunicação entre estações de trabalho e quais devem ser evitadas?
4.2. Segurança do BIOS e do Gestor de Início
A proteção da senha para o BIOS (ou componente equivalente) e para o gestor de início pode 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 obter privilégios root através do modo de usuário simples. Mas as medidas
de segurança a tomar para proteger o sistema de ataques deste tipo dependem da sensibilidade das
informações que a estação de trabalho armazena e da localização da máquina.
Por exemplo: se uma máquina é usada numa exposição ou feira e não contém informações delicadas,
então não deve ser crítico impedir tais ataques. Entretanto, se um laptop de um funcionário com chaves
SSH privadas não criptografadas da rede corporativa for deixado nesta mesma feira sem a proteção de
senhas, pode ocasionar uma violação de segurança severa com consequências para a empresa inteira.
Por outro lado, se a estação de trabalho estiver localizada em um lugar onde somente pessoas 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 iniciado por um disquete ou CD-ROM. Isto possibilita que ele entre no
modo de recuperação ou de usuário simples, que por sua vez permite a ele iniciar programas
arbitrariamente no sistema ou copiar informações delicadas.
1.
Como BIOSes de sistemas diferem entre fabricantes, alguns talvez não suportem proteção de senhas de
nenhum tipo, enquanto outros podem suportar um tipo e outro não.
24
Capítulo 4. Segurança da Estação de Trabalho
2. Impedindo a Inicialização do Sistema — Alguns BIOSes permitem que você proteja o processo
de inicialização da máquina com senha. Quando ativado, um atacante é forçado a inserir uma
senha antes do BIOS lançar o gestor de início.
Como os métodos para definir uma senha para o BIOS variam de acordo com o fabricante do 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 desligar a bateria
CMOS.
4.2.1.1. Protegendo Plataformas Não-x86
Outras arquiteturas usam programas diferentes para executar tarefas de nível baixo, parecidas àquelas
do BIOS em sistemas x86. Por exemplo: computadores baseados no Intel® Itanium™ usam a shell
EFI (Extensible Firmware Interface).
Para instruções sobre a proteção através de senha a programas parecidos com o BIOS em outras
arquiteturas, consulte as instruções do fabricante.
4.2.2. Senhas do gestor de Início
Veja a seguir as principais razões para proteger um gestor de início Linux com senha:
1. Impedindo Acesso ao Modo de Usuário Simples — Se um atacante puder inicializar o sistema no
modo de usuário simples, ele é autenticado automaticamente como o usuário root sem precisar
indicar a senha root.
2. Impedindo Acesso ao Console do GRUB — Se a máquina utiliza GRUB como seu gestor de
início, um atacante pode usar a interface de edição do GRUB para alterar sua configuração ou
para coletar informações usando o comando cat.
3. Impedindo Acesso a Sistemas Operacionais Não-Seguros — Se for um sistema de boot duplo,
um atacante pode selecionar um sistema operacional na hora da inicialização, tal como o DOS,
que ignora controles de acesso e permissões de arquivo.
O gestor de início GRUB é distribuído com o Red Hat Enterprise Linux para a plataforma x86. Para
uma visão detalhada do GRUB, consulte o capítulo intitulado O Gestor de Início GRUB no Guia de
Referência do Red Hat Enterprise Linux.
4.2.2.1. Senha Protegendo o GRUB
Você pode configurar o GRUB para resolver as primeiras duas questões listadas na Seção 4.2.2 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
password-hash
Substitua
password-hash
25
pelo valor retornado pelo /sbin/grub-md5-crypt2.
Na próxima vez que inicializar o sistema, o menu do GRUB não deixará você acessar o editor ou a
interface de comando sem que pressione [p] seguida da senha do GRUB.
Infelizmente, esta solução não impede que um atacante inicialize em um sistema operacional nã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.3. Segurança da Senha
Senhas são o método principal usado pelo Red Hat Enterprise Linux para verificar a identidade de
usuários. É por isso que a segurança da senha é tão importante para a proteção do usuário, da estação
de trabalho e da rede.
Por motivos de segurança, o programa de instalação configura o sistema para usar o Algoritmo
Message-Digest (MD5) e senhas shadow. É altamente recomendável que você não altere estas
configurações.
Se você desselecionar as senhas MD5 durante a instalação, o antigo formato Padrão de Criptografia
de Dados (DES - Data Encryption Standard) é utilizado. Este formato limita as senhas a oito caracteres
alfa-numéricos (impedindo o uso de pontuação e outros caracteres especiais) e oferece um nível de
criptografia modesto de 56 bits.
Se você desselecionar as senhas shadow durante a instalação, todas as senhas são armazenadas como
’one-way hash’ em um arquivo /etc/passwd legível por todos, o que torna o sistema vulnerável a
ataques de cracking offline. Se um intruso puder obter acesso a uma máquina como um usuário comum, ele pode copiar o arquivo /etc/passwd para sua própria máquina e rodar inúmeros programas
2.
O GRUB também aceita senhas não-criptografadas, mas é recomendado usar a versão md5 para segurança
adicional.
26
de cracking neste arquivo. Se houver uma senha desprotegida no arquivo, é apenas uma questão de
tempo para o cracker descobrí-la.
Senhas shadow eliminam a ameaça deste tipo de ataque, armazenando as senhas hash (misturadas)
em um arquivo /etc/shadow, legível somente pelo usuário root.
Isto força um atacante potencial a tentar craquear a senha remotamente se autenticando em um serviço
de rede na máquina, como SSH ou FTP. Este tipo de ataque de força bruta é bem mais lento e deixa
rastros óbvios, já que centenas de tentativas de autenticação mal-sucedidas são registradas nos 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 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. Confiar em idiomas estrangeiros para proteger senhas não é seguro.
•
cheguevara
•
bienvenido1
•
1dumbKopf
•
27
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.
•
•
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 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-
28
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 administradores de sistemas têm
duas opções básicas para forçar o uso de boas senhas. Eles podem criar senhas para os usuários,
ou podem deixar que os usuários criem suas próprias senhas, enquanto verificam se as senhas têm
qualidade aceitável.
Criar senhas para os usuários garante que as senhas sejam boas, mas se torna uma tarefa complicada
conforme a empresa cresce. Também aumenta o risco dos usuários anotarem suas senhas.
Por estas razões, a maioria dos administradores de sistema prefere que os usuários criem suas próprias
senhas, mas ativamente verificam se as senhas são boas e, em alguns casos, forçam os usuários a
trocarem suas senhas periodicamente conforme sua idade.
4.3.2.1. Forçando Senhas Fortes
Para proteger a rede de intrusões é uma boa idéia administradores de sistema verificarem se as senhas
usadas na empresa são fortes. Quando for pedido aos usuários criar ou alterar senhas, eles podem
utilizar a aplicação de linha de comando passwd, que é ciente do Gerenciador Plugável de Autenticação (Pluggable Authentication Manager - PAM). Então, verificar se a senha é fácil de craquear ou
se é muito curta, através do módulo pam_cracklib.so do PAM. Como o PAM é personalizável, é
possível adicionar outros verificadores de integridade de senhas, como pam_passwdqc (disponível
em http://www.openwall.com/passwdqc/) ou escrever um módulo novo. Para visualizar uma lista dos
módulos PAM disponíveis, veja http://www.kernel.org/pub/linux/libs/pam/modules.html. Para mais
informações sobre o PAM, veja o capítulo intitulado Módulos Plugáveis de Autenticação (PAM) no
Guia de Referência do Red Hat Enterprise Linux.
29
Note, no entanto, que a verificação executada nas senhas no momento de sua criação não descobre
senhas ruins tão efetivamente quanto rodar um programa de cracking de senhas nas senhas da empresa
inteira.
Há muitos programas de cracking de senhas que rodam no Red Hat Enterprise Linux, porém nenhum
é distribuído junto ao sistema operacional. Abaixo há uma breve lista de alguns dos programas de
cracking de senhas mais conhecidos:
Nota
Nenhuma destas ferramentas é provida junto ao Red Hat Enterprise Linux, portanto não são suportadas pela Red Hat, Inc. de maneira nenhuma.
•
John The Ripper — Um programa de cracking rápido e flexível. Permite o uso de listas de
palavras múltiplas e é capaz de craquear senhas com força bruta. Está disponível online em
http://www.openwall.com/john/.
•
Crack — Talvez o programa de cracking mais conhecido, o Crack também é muito rápido,
porém não tão fácil de usar quanto o John The Ripper. Pode ser encontrado online:
http://www.crypticide.com/users/alecm/.
•
Slurpie — O Slurpie é similar ao John The Ripper e ao Crack, mas é desenvolvido para 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
contra ataques distribuídos, em http://www.ussrback.com/distributed.htm.
Atenção
Sempre obtenha autorizações escritas antes de tentar craquear senhas dentro de uma empresa.
4.3.2.2. Idade da Senha
Idade da senha é uma outra técnica usada por administradores de sistema para defender uma empresa
contra senhas ruins. A idade da senha significa que depois de um determinado tempo (geralmente 90
dias) é solicitado ao usuário criar uma nova senha. A teoria por trás disso é se o usuário é forçado a
trocar sua senha periodicamente, uma senha crackeada por um intruso será útil somente por um tempo
limitado. A desvantagem desta técnica, no entanto, é que usuários tendem a anotar suas senhas.
Há dois programas principais usados para especificar a idade da senha sob o Red Hat Enterprise Linux:
o comando chage ou a aplicação gráfica Administrador de Usuários (redhat-config-users).
A opção -M do comando chage especifica o número máximo de dias em que a senha é válida. 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 usada para criar normas de validade de senhas. Para acessar esta aplicação, vá para o botão do Menu Principal (no Painel) =>
Configurações do Sistema => Usuários & Grupos ou digite o comando redhat-config-users
30
em uma janela de comandos (num XTerm ou num terminal GNOME, por exemplo). Clique na aba
Usuários, selecione o usuário da lista e clique em Propriedades no botão do menu (ou selecione
Arquivo => Propriedades no menu suspenso).
Então clique na aba Informações de Senha e insira o número de dias antes da senha expirar, conforme
mostra a figura Figura 4-1.
Figura 4-1. Aba Informações de Senha
Para mais informações sobre a configuração do usuário e grupo (inclusive instruções sobre como
forçar as primeiras senhas), veja o capítulo Configuração de Usuário e Grupo do Guia de Administração de Sistemas Red Hat Enterprise Linux. Para uma visão geral da administração de usuários
e recursos, consulte o capítulo Gerenciando Contas de Usuário e Acesso a Recursos (Managing
User Accounts and Resource Access) no Introdução à Administração de Sistemas Red Hat Enterprise Linux.
4.4. Controles Administrativos
Ao administrar um computador caseiro, o usuário deve executar algumas tarefas como usuário root
ou adquirindo privilégios efetivos de root através de um programa setuid, como o sudo ou o su.
Um programa setuid opera com o ID do usuário (UID) do proprietário do programa ao invés do
usuário operando o programa. Tais programas são caracterizados por um s em caixa baixa na seção
do proprietário de uma lista longa, conforme o exemplo a seguir:
-rwsr-xr-x
1 root
root
47324 May
1 08:09 /bin/su
Para os administradores de sistema de uma empresa, no entanto, as escolhas devem ser feitas de acordo
com o nível de acesso administrativo que os usuários, dentro da organização, devem ter em suas
máquinas. Através de um módulo PAM chamado pam_console.so, algumas atividades reservadas
somente ao usuário root, como reinicializar e montar mídia removível, são permitidas ao primeiro
usuário que se autenticar no console físico (veja o capítulo intitulado Módulos Plugáveis de 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 os privilégios administrativos. Consequentemente, os administradores devem decidir o grau de acesso que os
usuários de sua rede devem receber.
31
4.4.1. Permitindo Acesso Root
Se os usuários de uma empresa são um grupo confiável e experiente em computadores, permití-los
acesso root talvez não seja um problema. Permitir acesso root a usuários significa que questões
menores, como adicionar serviços ou configurar interfaces de rede, podem ser executadas pelos
usuários individuais, deixando os administradores de sistema livres para lidar com a segurança da
rede e outras questões mais importantes.
Por outro lado, permitir acesso root a usuários individuais pode acarretar nas questões a seguir:
•
Má Configuração da Máquina — Usuários com acesso root podem mal-configurar suas máquinas
e pedir assistência ou pior, abrir buracos na segurança sem saber.
•
Rodar Serviços Inseguros — Usuários com acesso root podem rodar serviços inseguros, como FTP
ou Telnet, em suas máquinas, potencialmente arriscando nomes de usuários e senhas conforme
trafegam sem criptografia pela rede.
•
Anexando Arquivos em Emails como Root — Apesar de raros, existem vírus de e-mail que afetam
o Linux. A única hora em que eles representam uma ameaça, no entanto, é quando são executados
pelo usuário root.
4.4.2. Impedindo Acesso Root
Se o administrador não estiver confortável em permitir que usuários se autentiquem como root por
estas ou por outras razões, a senha de root deve ser guardada secretamente, e o acesso ao nível de
execução um ou ao modo de usuário simples deve ser impedido através da proteção da senha do
gestor de início (veja a Seção 4.2.2 para mais informações sobre este tópico).
A Tabela 4-1 mostra as maneiras de um administrador garantir que autenticações root estão impedidas:
Método
Descrição
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
32
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 impedidos 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 seja
necessário para a
autenticação.a
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
Notas:
a. Consulte a Seção 4.4.2.4 para mais detalhes.
Tabela 4-1. Métodos para Desativar a Conta Root
4.4.2.1. Desativar a Shell Root
Para impedir os usuários de se autenticar diretamente como root, o administrador de sistema pode
configurar a shell da conta root para /sbin/nologin no arquivo /etc/passwd. Isto impede o acesso
à conta root através de comandos que requerem uma shell, como os comandos su e ssh.
33
Importante
Programas que não requerem acesso à shell, como clientes de email ou o comando sudo, ainda
podem acessar a conta root.
4.4.2.2. Impossibilitando Autenticações Root
Para limitar acesso à conta root, os administradores podem desativar autenticações root no console
editando o arquivo /etc/securetty. Este arquivo lista todos os dispositivos nos quais o usuário
root pode se autenticar. Se o arquivo não existir, o usuário root pode se autenticar através de qualquer
dispositivo de comunicação no sistema, seja através do console ou de uma interface de rede bruta.
Isto é perigoso pois um usuário pode acessar o Telnet em sua máquina como root, enviando sua senha
em formato texto através da rede. Por default, o arquivo /etc/securetty do Red Hat Enterprise
Linux permite somente ao usuário root se autenticar no console fisicamente conectado à máquina.
Para impedir que root se autentique, remova o conteúdo deste arquivo digitando o seguinte comando:
echo > /etc/securetty
Atenção
Um arquivo /etc/securetty em branco não impede o usuário root de se autenticar remotamente
usando o conjunto de ferramentas OpenSSH porque o console não é aberto antes da autenticação.
4.4.2.3. Impossibilitando Autenticações Root SSH
Para impedir autenticações do root através do protocolo SSH, edite o arquivo de configuração do
daemon SSH (/etc/ssh/sshd_config). Altere a linha que apresenta:
# PermitRootLogin yes
para o seguinte:
PermitRootLogin no
4.4.2.4. Impossibilitar Root de Usar PAM
O PAM, através do módulo /lib/security/pam_listfile.so, permite grande flexibilidade em
negar contas específicas. Isto permite que o administrador aponte o módulo para uma lista de usuários
que não são permitidos de autenticar. O exemplo abaixo mostra como o módulo é usado para o servidor
FTP vsftpd no arquivo de configuração do PAM /etc/pam.d/vsftpd (o caracter \ no final da
primeira linha no exemplo a seguir não é necessário se a diretiva estiver em apenas uma linha):
auth
required
/lib/security/pam_listfile.so
item=user \
sense=deny file=/etc/vsftpd.ftpusers onerr=succeed
Isto diz ao PAM para consultar o arquivo /etc/vsftpd.ftpusers e negar a qualquer usuário listado
acessar o serviço. O administrador é livre para alterar o nome deste arquivo e pode guardar listas
separadas para cada serviço ou usar uma lista geral para negar acesso a múltiplos serviços.
34
Se o administrador quer negar acesso a múltiplos serviços, uma linha similar pode ser adicionada aos
serviços de configuração do PAM, como /etc/pam.d/pop e /etc/pam.d/imap para clientes de
mail ou /etc/pam.d/ssh para clientes SSH.
Para mais informações sobre o PAM, veja o capítulo Módulos Plugáveis de Autenticação (PAM) no
Guia de Referência do Red Hat Enterprise Linux.
4.4.3. Limitar Acesso Root
Ao invés de negar completamante acesso ao usuário root, o administrador pode permitir acesso apenas
através de programas setuid, como o su ou o sudo.
4.4.3.1. O Comando su
Ao digitar o comando su, é pedida a senha root ao usuário e, após a autenticação, é dada uma janela
de comandos.
Uma vez autenticado através do comando su, o usuário é o usuário root e tem acesso administrativo
absoluto ao sistema. Além disso, uma vez que o usuário obteve aceeso root, é possível que ele use o
comando su para alterar qualquer outro usuário no sistema sem precisar inserir uma senha.
Como este programa é tão poderoso, administradores dentro de uma empresa talvez queiram limitar
quem tem acesso ao comando.
Uma das maneiras mais simples de fazer isso é adicionar usuários ao grupo administrativo especial
chamado wheel. Para fazer isso, digite o seguinte comando como root:
usermod -G wheel
username
No comando anterior, substitua
wheel.
username
pelo nome do usuário sendo adicionado ao grupo
Para usar o Administrador de Usuários para este propósito, clique no Botão do Menu Principal
(no Painel) => Configurações do Sistema => Grupos & Usuários ou digite o comando
redhat-config-users numa janela de comandos. Selecione a aba Usuários, selecione o
usuário da lista e clique em Propriedades a partir do menu do botão (ou selecione Arquivo =>
Propriedades a partir do menu suspenso).
Então selecione a aba Grupos e clique no grupo wheel, conforme mostra Figura 4-2.
35
Figura 4-2. Aba Grupos
Em seguida, abra o arquivo de configuração do PAM para su (/etc/pam.d/su) em um editor de
texto e remova o comentário [#] da seguinte linha:
auth
required /lib/security/$ISA/pam_wheel.so use_uid
Fazer isso permitirá que somente membros do grupo administrativo wheel usem o programa.
Nota
O usuário root é parte do grupo wheel por default.
4.4.3.2. O Comando sudo
O comando sudo oferece uma outra maneira de dar acesso administrativo a usuários. Quando um
usuário confiável precede um comando administrativo com sudo, ele precisa inserir sua própria
senha. Então, uma vez autenticado e assumindo que o comando é permitido, o comando 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 é possível usar o comando novamente sem precisar indicar a senha, por um
período de cinco minutos. Esta configuração pode ser alterada através do arquivo de configuração
/etc/sudoers.
36
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 mostramos na Seção 4.4.2.1.
O comando sudo também oferece um registro detalhado da sequência de eventos. Cada autenticação
bem-sucedida é registrada no arquivo /var/log/messages e o comando submetido junto ao nome
do usuário é registrado no arquivo /var/log/secure.
Outra vantagem do comando sudo é que um administrador pode permitir a diferentes usuários acesso
a comandos específicos baseado em suas necessidades.
Administradores que queiram editar o arquivo de configuração do sudo, o /etc/sudoers, devem
usar o comando visudo.
Para dar privilégios administrativos totais a alguém, digite visudo e adicione uma linha similar à
seguinte na seção de especificação de privilégios do usuário:
juan ALL=(ALL) ALL
Este exemplo estabelece que o usuário juan pode usar o sudo em qualquer máquina e executar
qualquer comando.
O exemplo abaixo ilustra a granularidade possível ao configurar o sudo:
%users
localhost=/sbin/shutdown -h now
Este exemplo estabelece que qualquer usuário pode submeter o comando /sbin/shutdown -h now
desde que o faça pelo console.
A página man de sudoers tem uma lista detalhada das opções para este arquivo.
4.5. Serviços de Rede Disponíveis
Enquanto o acessso a controles administrativos é uma questão importante para administradores de
sistemas dentro de uma empresa, manter controle de quais serviços de rede estão ativos é de suma
importância para qualquer um que administrar e operar um sistema Linux.
Muitos serviços comportam-se como servidores de rede sob o Red Hat Enterprise Linux. Se um
serviço de rede estiver rodando em uma máquina, então uma aplicação de servidor chamada 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 Denial of Service (DoS) — Ao inundar um serviço com pedidos, um ataque de denial of
service pode trazer ao sistema uma parada terrível ao tentar registrar e responder à cada pedido.
•
Ataques à Vulnerabilidade do Script — Se um servidor estiver usando scripts para executar ações
no lado do servidor, como servidores Web geralmente fazem, um cracker pode montar um ataque
com scripts escritos inapropriadamente. Estes ataques à vulnerabilidade do script podem acarretar
na condição de sobrecarga do buffer ou permitir que o atacante altere arquivos no sistema.
•
Ataques de Sobrecarga do Buffer (Buffer Overflow) — Serviços que se conectam a portas numeradas de 0 a 1023 devem ser executados por um usuário administrativo. Se a aplicação tiver uma
37
sobrecarga explorável do buffer, um atacante pode obter acesso ao sistema como o usuário rodando
o daemon. Devido à existência de sobrecarga explorável do buffer, os crackers usam ferramentas
automatizadas para identificar sistemas com vulnerabilidades, e após obterem acesso ao sistema,
utilizam rootkits automatizados para mantê-lo.
Nota
A ameaça das vulnerabilidades da sobrecarga do buffer é amenizada no Red Hat Enterprise Linux
pelo ExecShield , uma tecnologia de segmentação e proteção da memória executável suportada
pelos kernels de mono ou mulit-processadores x86. O ExecShield reduz o risco de sobrecarga do
buffer dividindo a memória virtual em segmentos executáveis e não-executáveis. Qualquer código
de programa que tentar executar fora do segmento executável (como código maldoso de um exploit
da sobrecarga do buffer) aciona uma falha na segmentação e é terminado.
O Execshield também inclui suporte para a tecnologia No eXecute (NX) nas plataformas AMD64 e
para a tecnologia eXecute Disable (XD) em sistemas Itanium e EM64T da Intel®. Estas tecnologias
trabalham em conjunto com o ExecShield para impedir que código maldoso rode na porção executável da memória virtual com uma granularidade de 4kb de código executável, diminuindo o risco
de ataques exploits furtivos da sobrecarga do buffer.
Para mais informações sobre as tecnologias do ExecShield, NX ou XD, consulte o documento técnico
intitulado New Security Enhancements in Red Hat Enterprise Linux v.3, Update 3, disponível na
seguinte URL:
http://www.redhat.com/solutions/info/whitepapers/
Para limitar a exposição a ataques através da rede, todos os serviços não utilizados devem ser desligados.
4.5.2. Identificando e Configurando Serviços
Para aumentar a segurança, a maioria dos serviçosde rede instalados com o Red Hat Enterprise Linux
são desligados por default. No entanto, há algumas exceções notáveis:
• cupsd
• lpd
— O servidor de impressão default do Red Hat Enterprise Linux.
— Um servidor de impressão alternativo.
— Um super servidor que controla as conexões para uma máquina de servidores subordinados, como vsftpd e telnet.
• xinetd
— O agente de transporte Sendmail é ativado por default, mas escuta apenas conexões
a partir da máquina local (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 o bom senso
e pecar pela precaução. Por exemplo: se uma impressora não está disponível, não deixe o cupsd
rodando. O mesmo vale para o portmap. Se você não monta volumes NFSv3 ou não usa o NIS (o
serviço ypbind), então o portmap deve ser desativado.
O Red Hat Enterprise Linux é distribuído com três programas desenvolvidos para ligar e desligar serviços. Eles são: Ferramenta de Configuração dos Serviços (system-config-services),
ntsysv e chkconfig. Para informações sobre o uso destas ferramentas, consulte o capítulo Controlando Acesso aos Serviços do Guia de Administração de Sistemas Red Hat Enterprise Linux.
38
Figura 4-3. Ferramenta de Configuração dos Serviços
Se você não está certo sobre o propósito de um serviço específico, a Ferramenta de Configuração
dos Serviços tem um campo de descrição, ilustrado na Figura 4-3, que pode lhe ser útil.
Mas verificar quais serviços de rede estão disponíveis para iniciar no momento de ligar a máquina
(boot) não é suficiente. Bons administradores de sistema também devem verificar quais portas estão
abertas e escutando. Veja a Seção 5.8 para mais informações sobre o assunto.
4.5.3. Serviços Inseguros
Potencialmente, qualquer rede é insegura. Por este motivo, desligar serviços não usados é tão 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.
•
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
39
• telnet
• vsftpd
Todos os programas de autenticação e shell (rlogin, rsh e telnet) devem ser evitados a favor do
SSH. (Veja a Seção 4.7 para mais informações sobre o sshd).
O FTP não é essencialmente tão perigoso à segurança do sistema quanto janelas de comando (shells)
remotas, mas os servidores FTP devem ser configurados e monitorados cuidadosamente para evitar
problemas. Veja a Seção 5.6 para mais informações sobre a proteção de servidores FTP.
Aqui estão alguns dos serviços que devem ser implementados cuidadosamente e por trás de um firewall:
• finger
• identd
• netdump
• netdump-server
• nfs
• rwhod
• sendmail
• smb
(Samba)
• yppasswdd
• ypserv
• ypxfrd
Você pode consultar mais informações sobre a proteção de serviços de rede no Capítulo 5.
A próxima seção aborda as ferramentas disponíveis para configurar um firewall simples.
4.6. Firewalls Pessoais
Uma vez configurados os serviços de rede necessários, é importante implementar um firewall.
Firewalls evitam que pacotes de rede acessem a interface de rede do sistema. Se for feito um pedido
a uma porta sendo bloqueada pelo firewall, este será ignorado. Se o serviço estiver escutando numa
destas portas bloqueadas, não receberá os pacotes e será efetivamente desabilitado. Por este motivo,
tome cuidado ao configurar um firewall para bloquear acesso a portas não usadas, para não bloquear
acesso a portas usadas por serviços configurados.
Para a maioria dos usuários, a melhor ferramenta para configurar um firewall simples é a ferramenta
de configuração gráfica distribuída com o Red Hat Enterprise Linux: a Ferramenta de Configuração
do Nível de Segurança (system-config-securitylevel). Esta ferramenta cria regras iptables
abrangentes para um firewall com propósitos genéricos usando uma interface de painel de controle.
Para mais informações sobre o uso desta aplicação e das opções ela oferece, consulte o capítulo
intitulado Configuração Básica do Firewall no Guia de Administração de Sistemas Red Hat Enterprise
Linux.
Para usuários avançados e administradores de servidores, configurar manualmente um firewall com
iptables é provavelmente a melhor opção. Consulte o Capítulo 7 para mais informações. Para acessar um guia detalhado sobre o comando iptables, consulte o capítulo iptables no Guia de Refer-
ência do Red Hat Enterprise Linux.
40
4.7. Ferramentas de Comunicação de Segurança Aprimorada
Na mesma proporção em que o tamanho e a popularidade da Internet tem crescido, cresceu também
a ameaça da intercepção de comunicações. Através do anos, ferramentas foram desenvolvidas para
criptografar comunicações ao longo de sua transferência pela rede.
O Red Hat Enterprise Linux é distribuído com duas ferramentas básicas que usam algoritmos de alto
nível e baseados em criptografia de chave pública para proteger as informações conforme trafegam
pela rede.
•
OpenSSH — Uma implementação livre do protocolo SSH para criptografar comunicações de rede.
•
Gnu Privacy Guard (GPG) — Uma implementação livre da aplicação de criptografia PGP (Pretty
Good Privacy) para criptografar dados.
OpenSSh é uma maneira mais segura de acessar uma máquina remota e substitui serviços não 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 de Sistemas Red Hat Enterprise Linux. Para mais informações sobre o Protocolo SSH,
veja o capítulo Protocolo SSH no Guia de Referência do Red Hat Enterprise Linux.
Importante
Apesar do serviço sshd ser essencialmente seguro, ele deve ser mantido atualizado para evitar
ameaças de segurança. Veja o Capítulo 3 para mais informações sobre esta questão.
GPG é uma maneira de garantir a privacidade da comunicação por e-mail. Pode ser usado para enviar email com dados delicados através de redes públicas e para proteger dados delicados em discos
rígidos.
Para mais informações sobre o uso do GPG, consulte o apêndice intitulado Guia de Iniciação do Gnu
Privacy Guard do Guia Passo a Passo do Red Hat Enterprise Linux.
Capítulo 5.
Segurança do Servidor
Quando um sistema é usado como um servidor em um rede pública, torna-se um alvo de ataques. Por
esta razão solidificar e trancar os serviços é de suma importância para o administrador de sistemas.
Antes de aprofundar em questões específicas, você deve revisar as seguintes dicas gerais para aumentar
a segurança do servidor:
•
Mantenha todos os serviços atualizados para protegê-los contra as ameaças recentes.
•
Use protocolos seguros sempre que possível.
•
Ofereça apenas um tipo de serviço de rede por máquina sempre que possível.
•
Monitore todos os servidores cuidadosamente e atente para atividades suspeitas.
5.1. Protegendo Serviços com TCP Wrappers e xinetd
TCP wrappers oferecem controle de acesso a vários serviços. A maioria dos serviços de rede modernos, como SSH, Telnet e FTP, utilizam os TCP wrappers, que ficam de guarda entre a entrada de um
pedido e o serviço requisitado.
Os benefícios oferecidos pelos TCP wrappers aumentam quando este é usado junto ao xinetd, um
super serviço que oferece acesso adicional, registro, vinculação, redirecionamento e controle de 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 ao serviço. Consulte o Capítulo 7 para mais informações
sobre a implementação de firewalls com comandos do IPTables.
Mais informações sobre a configuração do TCP wrappers e xinetd podem ser encontradas no capítulo intitulado TCP Wrappers e xinetd do Guia de Referência do Red Hat Enterprise Linux;.
As sub-seções seguintes assumem um conhecimento básico de cada tópico e focam nas opções de
segurança específicas.
5.1.1. Aumentando a Segurança com TCP Wrappers
TCP wrappers são capazes de muito mais que negar acesso aos serviços. Esta seção ilustra como
eles podem ser utilizados para enviar banners de conexão, alertar ataques em máquinas específicas e
aprimorar a funcionalidade de registro. Consulte a página man hosts_options para obter uma lista
completa das funcionalidades e controle de idioma do TCP wrapper.
5.1.1.1. TCP Wrappers e Banners de Conexão
Enviar um banner intimidador para clientes conectando a um serviço é uma boa maneira de disfarçar
em qual sistema o servidor está rodando enquanto informa um atacante potencial que o administrador
de sistemas está vigiando. Para implementar um banner do TCP wrappers para um serviço, use a
opção banner.
42
Capítulo 5. Segurança do Servidor
Este exemplo implementa um banner para vsftpd. Para começar, crie um arquivo de banner. Pode
estar em qualquer lugar do sistema, mas deve levar o mesmo nome que o daemon. Neste exemplo, o
arquivo é chamado /etc/banners/vsftpd.
O conteúdo do arquivo é parecido com o seguinte:
220-Hello, %c
220-All activity on ftp.example.com is logged.
220-Act up and you will be banned.
A expressão %c oferece uma gama de informações do cliente, tais como nome de usuário e nome da
máquina ou nome de usuário e endereço IP, para intimidar ainda mais a conexão. O Guia de Referência
do Red Hat Enterprise Linux tem uma lista de outras expressões disponíveis para TCP wrappers.
Para que este banner seja apresentado em futuras conexões, adicione a seguinte linha ao arquivo
/etc/hosts.allow:
vsftpd : ALL : banners /etc/banners/
5.1.1.2. TCP Wrappers e Alertas de Ataque
Se uma determinada máquina ou rede for flagrada atacando o servidor, o TCP wrappers pode ser usado
para alertar o administrador sobre ataques subsequentes desta máquina ou rede através da diretiva
spawn.
Neste exemplo, assuma que um cracker da rede 206.182.68.0/24 foi pego tentando atacar o 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 Aprimorado
Se determinados tipos de conexões são mais preocupantes que outras, o nível de registro pode ser
elevado para estes serviços através da opção severity.
Neste exemplo, assuma que qualquer um tentando conectar à porta 23 (a porta do Telnet) em um
servidor FTP é um cracker. Para denotar isso, insira um sinal emerg nos arquivos de registro ao invés
do sinal default, info, e negue a conexão.
Para fazer isso, insira a seguinte linha no arquivo /etc/hosts.deny:
in.telnetd : ALL : severity emerg
43
Isto usa a facilidade de registro authpriv default, mas eleva a prioridade do valor default info para
emerg, o que envia mensagens de registro diretamente ao console.
5.1.2. Aumentando a Segurança com o xinetd
O super servidor xinetd é uma outra ferramenta útil para controlar o acesso a seus serviços 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 é uma maneira fácil de bloquear máquinas que tentarem
scanear o servidor.
O primeiro passo para definir um SENSOR é escolher um serviço que você não planeja utilizar. Neste
exemplo, usamos o Telnet.
Edite o arquivo /etc/xinetd.d/telnet e altere a linha flags para:
flags
= SENSOR
Adicione as seguintes linhas entre os colchetes:
deny_time
= 30
Isto nega a máquina que tentou conectar à porta por 30 minutos. Outros valores aceitáveis para o
atributo deny_time são FOREVER (sempre), que mantém o banimento efetivo até que o xinetd
seja reiniciado, e NEVER (nunca), que permite a conexão e a registra.
Finalmente, a última linha deve ser:
disable
= no
Apesar de usar o SENSOR ser uma boa maneira de detectar e parar conexões de máquinas periogosas,
há duas desvantagens:
•
Não funciona contra scans secretos.
•
Um atacante ciente de que você está rodando o SENSOR pode montar um ataque ’denial of service’
contra determinadas máquinas forjando seus endereços IP e conectando à porta proibida.
5.1.2.2. Controlando Recursos de Servidor
Outra característica importante do xinetd é sua habilidade em controlar a quantidade de recursos
que os serviços sob seu controle podem utilizar.
Ele o faz através das seguintes diretivas:
!
"#!
"
number_of_connections
wait_period — Determina as conexões permitidas
ao serviço por segundo. Esta diretiva aceita apenas valores inteiros.
• cps =
44
$
%
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 RPC, como o NIS e o NFS. Tem
mecanismos de autenticação fracos e tem habilidade para delegar uma enorme gama de portas para os
serviços que controla. Por estas razões, é difcícil de proteger.
Nota
Proteger o portmap afeta somente as implementações do NFSv2 e NFSv3, já que o NFSv4 não o
requer mais. Se você planeja implementar um servidor NFSv2 ou NFSv3, o portmap é necessário e
a seção seguinte é válida.
Se você está rodando serviços RPC, siga estas regras básicas.
5.2.1. Proteja o portmap com TCP Wrappers
É importante usar o TCP wrappers para limitar quais redes ou máquinas têm acesso ao serviço
portmap já que este não possui uma forma de autenticação própria (built-in).
Futuramente, use somente endereços IP ao limitar acesso para o serviço. Evite usar estes nomes de
máquinas (hostnames), já que eles podem ser forjados através do ’poisoning’ do DNS e outros mé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 e restringir o acesso a redes específicas.
Abaixo há dois exemplos de comandos do IPTables que permitem conexões TCP ao serviço portmap
(escutando na porta 111) a partir da rede 192.168.0/24 e da máquina local (que é necessária para o
serviço sgi_fam usado pelo Nautilus). Todos os outros pacotes são derrubados.
iptables -A INPUT -p tcp -s! 192.168.0.0/24 --dport 111 -j DROP
iptables -A INPUT -p tcp -s 127.0.0.1 --dport 111 -j ACCEPT
Para limitar o tráfego UDP similarmente, use o seguinte comando.
iptables -A INPUT -p udp -s! 192.168.0.0/24
45
--dport 111 -j DROP
Dica
Consulte o Capítulo 7 para mais informações sobre a implementação de firewalls com comandos do
IPTables.
5.3. Protegendo o NIS
NIS significa Serviço de Informações de Rede (Network Information Service). É um serviço RPC
chamado ypserv, usado em conjunto com o portmap e outros serviços relacionados, para distribuir
mapas de nomes de usuário, senhas e outras informações importantes para qualquer computador que
esteja em seu domínio.
Um servidor NIS é composto de diversas aplicações. Elas incluem as seguintes:
• /usr/sbin/rpc.yppasswdd — Também chamado
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 transferências de mapa do 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.
O NIS é bastante inseguro para os padrões de hoje. Não tem mecanismo de autenticação da máquina
e passa toda a sua informação sem criptografia através da rede, incluindo uma gama de senhas. Como
resultado, tenha muito cuidado ao configurar uma rede que usa NIS. Para complicar ainda mais, a
configuração default do NIS é essencialmente insegura.
É recomendado a qualquer um planejando implementar um servidor NIS, primeiro proteger o serviço
portmap conforme descrito na Seção 5.2, e então resolver as seguintes questões, como planejamento
da rede.
5.3.1. Planejar Cuidadosamente a Rede
Como o NIS passa informações delicadas sem criptografia através da rede, é importante que o serviço
seja executado por trás de um firewall e numa rede segmentada e segura. Toda vez que informações
do NIS são passadas através de uma rede insegura, seus riscos estão sendo interceptados. Um 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) NIS
parecido com uma senha
Qualquer máquina com um domínio NIS pode usar comandos para extrair informações do servidor
sem autenticação, desde que o usuário saiba o o nome da máquina DNS e o nome de domínio NIS do
servidor.
Por exemplo: se alguém conectar um laptop a uma rede ou violar a rede por fora (e conseguir roubar
um endereço IP interno), o seguinte comando revela o mapa de /etc/passwd:
46
&
'
NIS_domain
ypcat -d
&
'
DNS_hostname
-h
passwd
Se este atacante for um usuário root, poderá obter o arquivo /etc/shadow digitando o seguinte
comando:
ypcat -d
&
NIS_domain
'
-h
&
DNS_hostname
'
shadow
Nota
Se o Kerberos for usado, o arquivo /etc/shadow não estará armazenado em um mapa NIS.
Para dificultar o acesso aos mapas NIS a um atacante, crie uma série randômica de caracteres para o
nome da máquina DNS, tal como o7hfawtgmhwg.domain.com. Similarmente, crie um nome diferente de domínio NIS randomizado . Isto dificulta bastante o acesso de um atacante ao servidor NIS.
5.3.3. Edite o Arquivo /var/yp/securenets
O NIS escuta todas as redes caso o arquivo /var/yp/securenets esteja em branco ou não exista
(como é o caso após uma instalação default). Uma das primeiras coisas a fazer é colocar pares máscara
de rede/rede no arquivo de modo que o ypserv responda somente aos pedidos da rede apropriada.
Veja abaixo um exemplo de entrada de um arquivo /var/yp/securenets:
255.255.255.0
192.168.0.0
Alerta
Nunca inicie um servidor NIS pela primeira vez sem criar o arquivo /var/yp/securenets.
Essa técnica não oferece proteção contra ataque de spoofing de IP, mas pelo menos impõe limites a
quais redes o servidor NIS serve.
5.3.4. Determinar Portas Estáticas e Usar Regras do IPTables
Todos os servidores relacionados ao NIS podem ter portas específicas, exceto o rpc.yppasswdd —
o daemon que permite a usuários alterarem suas senhas de autenticação (login). Determinar portas
para os outros dois daemons do servidor NIS, rpc.ypxfrd e ypserv, permite criar regras de firewall
para proteger futuramente os daemons do servidor NIS contra intrusos.
Para fazer isto, adicione as seguintes linhas a /etc/sysconfig/network:
YPSERV_ARGS="-p 834"
YPXFRD_ARGS="-p 835"
As seguintes regras do IPTables podem ser determinadas para reforçar a qual rede o servidor escuta
para estas portas:
iptables -A INPUT -p ALL -s! 192.168.0.0/24
iptables -A INPUT -p ALL -s! 192.168.0.0/24
--dport 834 -j DROP
--dport 835 -j DROP
47
Dica
Consulte o Capítulo 7 para mais informações sobre a implementação de firewalls com comandos do
IPTables.
5.3.5. Use Autenticação do Kerberos
Uma das desvantagens mais gritantes ao usar NIS para autenticação é que sempre que um usuário
se autentica (log in) numa máquina, uma senha com caracteres misturados é enviada do mapa
/etc/shadow através da rede. Se um intruso obtiver acesso a um domínio NIS e bisbilhotar o
tráfego de rede, essas misturas de nomes de usuários e senhas podem ser discretamente coletadas.
Com tempo suficiente, um programa de cracking de senha pode adivinhar senhas fáceis e um
atacante pode obter acesso a uma conta válida na rede.
Como o Kerberos usa criptografia de chave secreta, as misturas de senha nunca são enviadas através
da rede, tornando o sistema bem mais seguro. Para saber mais sobre o Kerberos, consulte o capítulo
intitulado Kerberos no Guia de Referência do Red Hat Enterprise Linux.
5.4. Protegendo o NFS
O Sistema de Arquivo de Rede (Network File System ou NFS) é um serviço que oferece sistemas
de arquivo acessíveis para máquinas cliente. Para mais informações sobre o funcionamento do NFS,
consulte o capítulo intitulado Sistema de Arquivo de Rede (NFS) no Guia de Referência do Red Hat
Enterprise Linux. Para mais informações sobre a configuração do NFS, consulte o Guia de Administração de Sistemas Red Hat Enterprise Linux. As sub-seções a seguir assumem um conhecimento
básico do NFS.
Importante
A versão do NFS inclusa no Red Hat Enterprise Linux, NFSv4, não requer mais o serviço portmap,
conforme abordado na Seção 5.2. O tráfego do NFS agora utiliza TCP em todas as versões (ao
invés do UDP) e o requer no uso do NFSv4. O NFSv4 agora inclui a autenticação do Kerberos para
usuário e grupo, como parte do módulo RPCSEC_GSS do kernel. As informações sobre o portmap
ainda são inclusas, já que o Red Hat Enterprise Linux suporta o NFSv2 e NFSv3, que o utilizam.
5.4.1. Planejar Cuidadosamente a Rede
Agora que o NFS tem a habilidade de passar todas as informações criptografadas usando o Kerberos
através da rede, é importante que o serviço seja configurado corretamente se estiver atrás de um
firewall ou numa rede segmentada. O NFSv2 e NFSv3 ainda passam dados inseguramente e seus riscos
devem ser considerados. Um planejamento cuidadoso da rede neste aspecto pode ajudar a prevenir
violações à segurança.
5.4.2. Cuidado com Erros de Sintaxe
O servidor NFS determina quais sistemas de arquivo e quais máquinas exportar para estes diretórios
através do arquivo /etc/exports. Cuidado para não adicionar espaços extras ao editar este arquivo.
Por exemplo: a linha a seguir no arquivo /etc/exports compartilha o diretório /tmp/nfs/ com a
máquina bob.example.com com permissões de leitura e escrita (rw).
48
/tmp/nfs/
bob.example.com(rw)
Por outro lado, esta linha do arquivo /etc/exports compartilha o mesmo diretório com a máquina
bob.example.com com permissão somente-leitura, e o compartilha com o mundo com permissões
leitura e escrita devido um único caractere de espaço após o nome da máquina (hostname).
/tmp/nfs/
bob.example.com (rw)
É bom praticar a verificação de todos os compartilhamentos do NFS usando o comando showmount
para checar o que foi compartilhado.
showmount -e
(
hostname
)
5.4.3. Não Use a Opção no_root_squash
Por default, as partilhas do NFS alteram o usuário root para o usuário nfsnobody, uma conta de
usuário sem privilégios. Desta maneira, todos os arquivos criados por root são de propriedade (owner)
do usuário nfsnobody, o que previne o upload de programas com as informações do conjunto de ids
do usuário.
Se no_root_squash é usado, os usuários root remotos poderão alterar qualquer arquivo do sistema
de arquivo compartilhado e deixar aplicações infectadas pelo trojan, para que outros usuários as 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 intitulado Servidor HTTP Apache do Guia de Referência do
Red Hat Enterprise Linux, o capítulo Configuração do Servidor HTTP Apache do Guia de
Administração de Sistemas Red Hat Enterprise Linux e os manuais do Stronghold, disponíveis
online: http://www.redhat.com/docs/manuals/stronghold/.
Veja abaixo uma lista de opções de configuração para as quais administradores devem ser muito
cuidadosos.
5.5.1. FollowSymLinks
Esta diretiva é habilitada por default, portanto cuidado ao criar os links simbólicos na raiz do documento 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.
49
5.5.3. A Diretiva UserDir
A diretiva UserDir é desabilitada por default porque esta pode confirmar a presença de uma conta
de usuário no sistema. Para possibilitar a navegação pelos diretórios do usuário no servidor, use as
seguintes diretivas:
UserDir enabled
UserDir disabled root
Estas diretivas ativam a navegação em todos os diretórios de usuário, exceto no /root. Para adicionar
usuários à lista de contas desativadas, adicione uma lista de usuários delimitada por espaço na linha
UserDir disabled.
5.5.4. Não Remova a Diretiva IncludesNoExec
Por default, o lado do servidor inclui módulos que não podem executar comandos. Não é recomendado
alterar esta configuração a não ser que seja absolutamente necessário, já que pode, potencialmente,
possibilitar que um atacante execute comandos no sistema.
5.5.5. Permissões Restritas para Diretórios Executáveis
Certifique-se de conceder permissões de gravação (write) para o usuário root em todos os diretórios
contendo scripts ou CGIs. Isto pode ser feito digitando os seguintes comandos:
**
++
directory_name
chown root
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 ou FTP) é um protocolo TCP antigo
desenvolvido para transferir arquivos pela rede. Já que todas as transações com o servidor (inclusive
a autenticação de usuário) são criptografadas, o FTP é considerado um protocolo inseguro e deve ser
configurado cuidadosamente.
O Red Hat Enterprise Linux oferece três servidores FTP.
— 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 num sistema.
50
Para
alterar
o
banner
de
/etc/vsftpd/vsftpd.conf:
saudação
,
ftpd_banner= insert_greeting_here
Substitua
saudação.
.
-
insert_greeting_here
/
do
vsftpd,
adicione
a
seguinte
diretiva
a
na diretiva acima pelo texto de sua mensagem de
Para banners com muitas linhas, é melhor usar um arquivo de banner. Para simplificar o gerenciamento
de banners múltiplos, coloque todos os banners em um novo diretório chamado /etc/banners/.
O arquivo de banners para conexões FTP, neste exemplo, é /etc/banners/ftp.msg. O exemplo
abaixo mostra como este arquivo se parece:
####################################################
# Hello, all activity on ftp.example.com is logged.#
####################################################
Nota
Não é necessário começar cada linha do arquivo com 220, conforme especificado na Seção 5.1.1.1.
Para referenciar este arquivo de banners de saudação do vsftpd, adicione a seguinte diretiva ao
arquivo /etc/vsftpd/vsftpd.conf:
banner_file=/etc/banners/ftp.msg
Também é possível enviar banners adicionais para conexões entrantes usando TCP wrappers conforme
descrito na Seção 5.1.1.1.
5.6.2. Acesso Anônimo
A presença do diretório /var/ftp/ ativa a conta anônima.
A maneira mais fácil de criar este diretório é instalar o pacote vsftpd. Este pacote define uma árvore
de diretório para usuários anônimos e configura as permissões dos diretórios para somente-leitura para
usuários anônimos.
Por default, a conta do usuário anônimo não pode escrever em nenhum diretório.
Atenção
Se você possibilitar o acesso anônimo a um servidor FTP, tome cuidado onde armazena os dados
importantes.
5.6.2.1. Upload Anônimo
Para permitir que usuários anônimos façam upload, é recomendado criar um diretório
somente-gravação (write-only) em /var/ftp/pub/.
Para fazer isso, digite:
mkdir /var/ftp/pub/upload
51
Depois altere as permissões para que usuários anônimos não possam ver o que está no diretório,
digitando:
chmod 730 /var/ftp/pub/upload
Uma lista do diretório em formato longo deve se parecer com o seguinte:
drwx-wx---
2 root
ftp
4096 Feb 13 20:05 upload
Alerta
Administradores que permitem a usuários anônimos ler e gravar em diretórios, frequentemente
percebem que seu servidor se torna um depósito de software roubado.
Adicionalmente,
abaixo
de
vsftpd,
adicione
a
seguinte
linha
ao
arquivo
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.
52
5.7. Protegendo o Sendmail
Sendmail é um Agente de Transporte de Correspondência (Mail Transport Agent - MTA) que utiliza
o Protocolo de Transporte de Correspondência Simples (Simple Mail Transport Protocol - SMTP)
para entregar mensagens eletrônicas entre outros MTAs e para enviar e-mails a clientes ou agentes
de entrega. Apesar de muitos MTAs serem capazes de criptografar tráfego entre eles, a maioria não o
faz, portanto enviar email através de qualquer rede pública é considerado uma forma de comunicação
essencialmente insegura.
Para mais informações sobre o funcionamento do e-mail e uma visão geral dos ajustes de configuração
comuns, veja o capítulo E-mail no Guia de Referência do Red Hat Enterprise Linux. Esta seção
assume um conhecimento básico de como gerar um /etc/mail/sendmail.cf válido, editando o
/etc/mail/sendmail.mc e executando o comando m4, conforme explicado no Guia de Referência
do Red Hat Enterprise Linux.
É recomendado a qualquer um planejando implementar um servidor Sendmail, resolver as seguintes
questões.
5.7.1. Limitar um Ataque Denial of Service
Devido à natureza do e-mail, um determinado atacante pode facilmente lotar o servidor com 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.
Como o NFSv2 e o NFSv3 não mantêm controle sobre IDs de usuário e grupo, dois ou mais usuários
podem ter o mesmo UID, e portanto receber e ler a correspondência do outro. Isso não ocorre com o
NFSv4 usando Kerberos, já que o módulo SECRPC_GSS do kernel não utiliza a autenticação baseada
no UID.
5.7.3. Usuários Mail-only
Para ajudar a prevenir exploits locais no servidor Sendmail, é melhor que usuários de mail acessem o
Sendmail usando apenas um programa de email. Contas shell não devem ser permitidas no servidor de
mail e todos os usuários shell do arquivo /etc/passwd devem ser definidos para /sbin/nologin
(com a possível exceção do usuário root).
53
5.8. Verificando Quais Portas estão Escutando
Após configurar os serviços de rede, é importante atentar para quais portas estão escutando as 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:
nmap -sT -O localhost
O output deste comando se parece com o seguinte:
Starting nmap 3.55 ( http://www.insecure.org/nmap/ ) at 2004-09-24 13:49 EDT
Interesting ports on localhost.localdomain (127.0.0.1):
(The 1653 ports scanned but not shown below are in state: closed)
PORT
STATE SERVICE
22/tcp
open ssh
25/tcp
open smtp
111/tcp
open rpcbind
113/tcp
open auth
631/tcp
open ipp
834/tcp
open unknown
2601/tcp open zebra
32774/tcp open sometimes-rpc11
Device type: general purpose
Running: Linux 2.4.X|2.5.X|2.6.X
OS details: Linux 2.5.25 - 2.6.3 or Gentoo 1.2 Linux 2.4.19 rc1-rc7)
Uptime 12.857 days (since Sat Sep 11 17:16:20 2004)
Nmap run completed -- 1 IP address (1 host up) scanned in 5.190 seconds
Este output mostra que o sistema está rodando o portmap devido à presença do serviço sunrpc. No
entanto, também há um serviço misterioso na porta 834. Para verificar se a porta está associada à lista
oficial de serviços conhecidos, digite:
cat /etc/services | grep 834
Este comando não retorna nenhum output. Isto indica que enquanto a porta está no intervalo reservado
(de 0 a 1023) e requer acesso root para abrir, não está associada a um serviço conhecido.
Em seguida, verifique as informações sobre a porta usando netstat ou lsof. Para verificar a porta
834 usando netstat, use o seguinte comando:
netstat -anp | grep 834
O comando retorna o seguinte output:
tcp
0
0 0.0.0.0:834
0.0.0.0:*
LISTEN
653/ypbind
A presença da porta aberta em netstat afirma que um cracker que abrir clandestinamente uma porta
num sistema hackeado provavelmente não permitirá que esta seja revelada através deste comando.
A opção [p] também revela o id do processo (PID) do serviço que abriu a porta. Neste caso, a
54
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.
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.
Para atender a esta necessidade, foram desenvolvidas as 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 Rede de Área Ampla (Wide Area Network - WAN) a partir de Redes de Áreas Locais (LANs) existentes. Ela difere
do frame relay ou do ATM em seu meio de transporte. As VPNs transmitem através de IP usando
datagramas como a camada de transporte, tornando-o um condutor seguro através da Internet, para
um determinado destino. A maioria das implementações VPN de software livre incorporam métodos
de criptografia de padrão aberto para mascarar futuramente os dados em trânsito.
Algumas empresas aplicam soluções VPN de hardware para aumentar a segurança, enquanto outras
usam software ou implementações baseadas em protocolos. Há diversos fabricantes de soluções VPN
de hardware como Cisco, Nortel, IBM e Checkpoint. Existe uma solução VPN baseada em software
gratuito para Linux chamada FreeS/Wan, que utiliza uma implementação padronizada do IPSec (ou
Internet Protocol Security). Estas soluções VPN, independentemente de serem baseadas em hardware
ou software, atuam como roteadores especializados situados entre as conexões IP de dois escritórios.
Quando um pacote é transmitido de um cliente, é enviado através do roteador ou porta de comunicação
(gateway), que então adiciona informações de cabeçalho para roteamento e autenticação, chamado
Cabeçalho de Autenticação (Authentication Header, AH). Os dados são criptografados e agrupados
com instruções para resolução e descriptografia, chamadas Encapsulating Security Payload (ESP). O
roteador VPN receptor depura as informações de cabeçalho, descriptografa os dados e os roteia ao
destino pretendido (uma estação de trabalho ou um nódulo em uma rede). Usando uma conexão redea-rede, o nódulo receptor da rede local recebe os pacotes descriptografados e prontos para processar. O
processo de criptografia/descriptografia numa conexão VPN rede-a-rede é transparente para o nódulo
local.
Com um nível tão elevado de segurança, não basta ao cracker interceptar o pacote, mas também
descriptografar o pacote. Intrusos que aplicarem um ataque man-in-the-middle entre um servidor e o
cliente também devem ter acesso à pelo menos uma das chaves privadas para sessões de autenticação.
Como aplicam diversas camadas de autenticação e criptografia, as VPNs são um meio seguro e efetivo
para conectar múltiplos nódulos remotos para atuar como uma intranet unificada.
6.1. VPNs e Red Hat Enterprise Linux
Os usuários do Red Hat Enterprise Linux têm várias opções em termos de implementação de uma
solução de software para conectar à sua WAN com segurança. A Segurança do Protocolo de Internet,
ou IPsec, é a implementação VPN suportada pelo Red Hat Enterprise Linux que atende às necessidades de usabilidade de empresas com filiais ou usuários remotos.
56
Capítulo 6. Redes Privadas Virtuais (Virtual Private Networks)
6.2. IPsec
O Red Hat Enterprise Linux suporta o IPsec para conectar máquinas e redes remotas entre si usando
um túnel seguro em uma rede de transporte comum, como a Internet. O IPsec pode ser implementado
usando uma conexão máquina-a-máquina (uma estação de trabalho conectada a outra) ou rede-a-rede
(uma LAN/WAN conectada a outra). A implementação do IPsec no Red Hat Enterprise Linux usa
Troca de Chave de Internet (Internet Key Exchange, IKE), um protocolo implementado pelo IETF
(Internet Engineering Task Force) para ser usado em autenticação mútua e proteger associações entre
sistemas conectados.
Uma conexão IPsec é dividida em duas fases lógicas. Na fase 1, um nódulo do IPsec inicia a conexão
com o nódulo ou rede remota. O nódulo/rede remota verifica as credenciais do nódulo pedinte e ambas
partes negociam o método de autenticação da conexão. Nos sistemas Red Hat Enterprise Linux, uma
conexão IPsec usa o método de chave pré-compartilhada (pre-shared key) para autenticação do nódulo
IPsec. Numa conexão IPsec com chave pré-compartilhada, ambas máquinas devem usar a mesma
chave para prosseguir à segunda fase da conexão IPsec.
Durante a fase 2 de uma conexão IPsec é criada uma associação de segurança (security association,
SA) entre os nódulos IPsec. Essa fase estabelece um banco de dados de SAs com informações de
configuração, como o método de criptografia, parâmetros de troca de chaves de sessões secretas,
dentre outras. Essa fase administra a conexão IPsec entre nódulos e redes remotas.
A implementação do IPsec usa IKE para compartilhar chaves entre máquinas ao longo da Internet. O
deamon do chaveiro racoon é responsável pela distribuição e troca de chaves IKE.
6.3. Instalação do IPsec
A implementação do IPsec requer a instalação do pacote RPM ipsec-tools em todas as máquinas
IPsec (se usar uma configuração máquina-a-máquina) ou roteadores IPsec (se usar uma configuração
rede-a-rede). O pacote RPM contém bibliotecas, daemons e arquivos de configuração essenciais para
auxiliar na configuração da conexão IPsec, incluindo:
— 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
informaçõe sobre o uso da Ferramenta de Administração de Rede, consulte o Guia de Administração de Sistemas Red Hat Enterprise Linux.
Para conectar duas máquinas em rede através do IPsec, consulte a Seção 6.4. Para conectar uma
LAN/WAN a outra através do IPsec, consulte a Seção 6.5.
57
6.4. Configuração Máquina-a-Máquina do IPsec
O IPsec pode ser configurado para conectar um computador pessoal ou estação de trabalho a outra
através de uma conexão máquina-a-máquina. Este tipo de conexão utiliza a rede à qual cada máquina
está conectada para criar o túnel seguro entre elas. Os requisitos de uma conexão máquina-a-máquina
são mínimos, já que é a configuração do IPsec em cada máquina. As máquinas precisam somente de
uma conexão dedicada a uma rede de transporte (como a Internet) e do Red Hat Enterprise Linux para
criar a conexão do IPsec.
O primeiro passo para criar uma conexão é coletar as informações de sistemas e de rede de cada
estação de trabalho (workstation). Para uma conexão máquina-a-máquina, você precisa das seguintes
informações:
•
O endereço IP das duas máquinas
•
Um nome único para identificar a conexão IPsec e distinguí-la de outros dispositivos e conexões
(ex.: ipsec0)
•
Uma chave fixa de criptografia ou uma gerada automaticamente pelo racoon
•
Uma chave de autenticação pré-compartilhada, usada para iniciar a conexão e trocar chaves de
criptografia durante a sessão
Por exemplo: suponha que as estações de trabalho A e B queiram se interconectar através de um
túnel IPsec. Pretendem se conectar usando uma chave pré-compartilhada com o valor foobarbaz
e os usuários concordam em deixar que o racoon gere automaticamente e compartilhe uma chave
de autenticação entre cada máquina. Ambos usuários das máquinas decidem nomear suas conexões
como ipsec0.
Veja o arquivo ifcfg da estação de trabalho (workstation) A para uma conexão IPsec
máquina-a-máquina com a estação de trabalho B (o nome único para identificar a
conexão neste exemplo é ipsec0, portanto o arquivo resultante é nomeado como
/etc/sysconfig/network-scripts/ifcfg-ipsec0).
DST=X.X.X.X
TYPE=IPSEC
ONBOOT=yes
IKE_METHOD=PSK
A estação de trabalho A substituirá X.X.X.X pelo endereço IP da estação de trabalho B, enquanto
esta deve substituir X.X.X.X pelo endereço IP da estação de trabalho A. A conexão é definida
para iniciar na inicialização (boot-up) (ONBOOT=yes) e usa o método de autenticação de chave précompartilhada (IKE_METHOD=PSK).
A
seguir,
veja
o
conteúdo
do
arquivo
da
chave
pré-compartilhada
(chamado
/etc/sysconfig/network-scripts/keys-ipsec0) que ambas máquinas precisam para
autenticarem-se entre si. O conteúdo deste arquivo deve ser idêntico nas duas estações de trabalho, e
somente o usuário root deve ser capaz de acessar ou gravar (read or write) este arquivo.
IKE_PSK=foobarbaz
Importante
Para alterar o arquivo keys-ipsec0 para que somente o usuário root possa acessá-lo ou editá-lo,
execute o seguinte comando após criar o arquivo:
chmod 600 /etc/sysconfig/network-scripts/keys-ipsec0
58
Para alterar a chave de autenticação a qualquer momento, edite o arquivo keys-ipsec0 nas duas
estações de trabalho. As duas chaves devem ser idênticas para que a conexão funcione apropriadamente.
O próximo exemplo mostra a configuração específica para a conexão da fase 1 à máquina remota.
O arquivo é nomeado como X.X.X.X.conf (X.X.X.X é substituído pelo endereço IP do roteador
IPsec remoto). Note que este arquivo é gerado automaticamente quando o túnel IPsec é ativado e não
deve ser editado diretamente.
;
remote X.X.X.X
{
exchange_mode aggressive, main;
my_identifier address;
proposal {
encryption_algorithm 3des;
hash_algorithm sha1;
authentication_method pre_shared_key;
dh_group 2 ;
}
}
O arquivo de configuração default da fase 1, criado quando uma conexão IPsec é iniciada, contém as
seguintes asserções usadas pela implementação IPsec do Red Hat Enterprise Linux:
remote X.X.X.X
Especifica que as asserções subsequentes deste arquivo de configuração aplicam-se somente ao
nódulo remoto identificado pelo endereço IP X.X.X.X.
exchange_mode aggressive
A configuração default do IPsec no Red Hat Enterprise Linux usa um método de autenticação
agressivo, que reduz a sobrecarga da conexão enquanto permite a configuração de diversas
conexões IPsec com máquinas múltiplas.
my_identifier address
Define o método de identificação a ser usado na autenticação dos nódulos. O Red Hat Enterprise
Linux usa endereços IP para identificar os nódulos.
encryption_algorithm 3des
Define a cifra de criptografia usada durante a autenticação. Por default, o Triple Data Encryption
Standard (3DES) é usado.
Especifica o algoritmo hash usado durante a negociação entre nódulos da fase 1. Por default,
usa-se o Secure Hash Algorithm versão 1.
authentication_method pre_shared_key
Define o método de autenticação usado durante a negociação dos nódulos. Por default, o Red Hat
Enterprise Linux usa chaves pré-compartilhadas para autenticação.
dh_group 2
Especifica o número do grupo Diffie-Hellman para estabelecer chaves de sessões geradas dinamicamente. Por default, o grupo de 1024 bits é usado.
59
Os arquivos /etc/racoon/racoon.conf devem ser idênticos em todos os nódulos IPsec, exceto
pela asserção include "/etc/racoon/X.X.X.X.conf". Esta asserção (e o arquivo que referencia) é gerada quando o túnel IPsec é ativado. Para a estação de trabalho A, X.X.X.X na asserção
include é o endereço IP da estação de trabalho B. O oposto vale para a estação de trabalho B. Veja
a seguir um arquivo racoon.conf típico quando a conexão IPsec é ativada.
# Racoon IKE daemon configuration file.
# See ’man racoon.conf’ for a description of the format and entries.
path include "/etc/racoon";
path pre_shared_key "/etc/racoon/psk.txt";
path certificate "/etc/racoon/certs";
sainfo anonymous
{
pfs_group 2;
lifetime time 1 hour ;
encryption_algorithm 3des, blowfish 448, rijndael ;
authentication_algorithm hmac_sha1, hmac_md5 ;
compression_algorithm deflate ;
}
include "/etc/racoon/X.X.X.X.conf"
Este arquivo racoon.conf default inclui localidades definidas para a configuração do IPsec, arquivos
de chaves pré-compartilhadas e certificados. Os campos sainfo anonymous descrevem a SA da
fase 2 entre os nódulos IPsec — a natureza da conexão IPsec (incluindo os algoritmos suportados de
criptografia usados) e o método de troca de chaves. A lista a seguir define os campos da fase 2:
sainfo anonymous
Denota que a SA pode iniciar anonimamente com qualquer par desde que as credenciais IPsec
coincidam.
pfs_group 2
Define o protocolo Diffie-Hellman de troca de chaves, o que determina o método através do qual
os nódulos do IPsec estabelecem uma chave de sessão temporária mútua para a segunda fase
da conectividade IPsec. Por default, a implementação IPsec do Red Hat Enterprise Linux usa o
grupo 2 (ou modp1024) dos grupos de troca de chave criptográfica Diffie-Hellman. O grupo 2 usa
uma exponenciação modular de 1024 bits, evitando que atacantes descriptografem transmissões
IPsec anteriores, mesmo que uma chave privada seja comprometida.
lifetime time 1 hour
Este parâmetro especifica o ciclo de vida de uma SA e pode ser quantificado por hora ou bytes
de dados. A implementação IPsec do Red Hat Enterprise Linux especifica o tempo de uma hora.
encryption_algorithm 3des, blowfish 448, rijndael
Especifica as cifras de criptografia suportadas para a fase 2. O Red Hat Enterprise Linux suporta
3DES, 448-bit Blowfish e Rijndael (a cifra usada no Advanced Encryption Standard ou AES).
authentication_algorithm hmac_sha1, hmac_md5
Lista os algoritmos hash suportados para autenticação. Os modos suportados são os códigos de
autenticação de mensagem sha1 e md5 hashed (HMAC).
60
compression_algorithm deflate
Define o algoritmo Deflate de compressão para suporte à IP Payload Compression (IPCOMP),
que permite a transmissão potencialmente mais rápida de datagramas IP através de conexões
lentas.
Para iniciar a conexão, reinicialize a estação de trabalho ou execute o seguinte comando, como root,
em cada máquina:
/sbin/ifup ipsec0
Para testar a conexão IPsec, execute o utilitário tcpdump para visualizar os pacotes de rede sendo
transferidos entre as máquinas (ou redes) e verificar se estão criptografadas via IPsec. O pacote deve
incluir um cabeçalho AH e deve ser exibido como pacotes ESP. ESP significa que está criptografado.
Por exemplo:
17:13:20.617872 pinky.example.com > ijin.example.com: \
AH(spi=0x0aaa749f,seq=0x335): ESP(spi=0x0ec0441e,seq=0x335) (DF)
6.5. Configuração Rede-a-Rede do IPsec
O IPsec também pode ser configurado para conectar uma rede inteira (como uma LAN ou WAN) a
uma rede remota através de uma conexão rede-a-rede. Este tipo de conexão requer a configuração
de roteadores IPsec em cada lado das redes conectadas para processar e rotear transparentemente
informações de um nódulo de uma LAN para outro nódulo de uma LAN remota. A Figura 6-1 mostra
uma conexão IPsec rede-a-rede passando por um túnel.
Figura 6-1. Uma conexão IPSec Rede-a-rede passando por um túnel
O diagrama mostra duas LANs separadas pela Internet. Estas LANs usam roteadores IPSEC para
autenticar e iniciar uma conexão, usando um túnel seguro através da Internet. Os pacotes interceptados em trânsito requerem descriptografia muito forte para craquear a cifra protegendo os pacotes
entre estas LANs. O processo de comunicação entre um nódulo no intervalo IP 192.168.1.0/24 e
outro no 192.168.2.0/24 é completamente transparente aos nódulos, já que o processamento, 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)
61
•
Os endereços IP dos dispositivos da porta de comunicação (gateway) que roteia os dados dos nódulos da rede para a Internet
•
Um nome único para identificar a conexão IPsec e distinguí-la de outros dispositivos e conexões
(ex.: ipsec0)
•
Uma chave fixa de criptografia ou uma gerada automaticamente pelo racoon
•
Uma chave de autenticação pré-compartilhada, que inicia a conexão e troca chaves de criptografia
durante a sessão
Por exemplo: suponha que a LAN A (lana.example.com) e LAN B (lanb.example.com) queiram se 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 cada um dos roteadores IPsec. O administrador da LAN A decide
nomear a conexão IPsec como ipsec0, enquanto o administrador da LAN B nomeia a conexão IPsec
como ipsec1.
Veja o conteúdo do arquivo ifcfg para uma conexão IPsec rede-a-rede da LAN A. O nome único
para identificar a conexão neste exemplo é ipsec1, portanto o arquivo resultante é nomeado como
/etc/sysconfig/network-scripts/ifcfg-ipsec1.
TYPE=IPSEC
ONBOOT=yes
IKE_METHOD=PSK
SRCGW=192.168.1.254
DSTGW=192.168.2.254
SRCNET=192.168.1.0/24
DSTNET=192.168.2.0/24
DST=X.X.X.X
A conexão é configurada para iniciar na inicialização da máquina (ONBOOT=yes) e usa o método
de autenticação de chave pré-compartilhada (IKE_METHOD=PSK). O administrador da LAN A
indica a porta de comunicação (gateway) de destino, que é a porta de comunicação da LAN B
(DSTGW=192.168.2.254) e também a porta de comunicação de origem, que é o endereço IP da
porta de comunicação da LAN A (SRCGW=192.168.1.254). O administrador então indica a rede de
destino, que é o intervalo de rede da LAN B (DSTNET=192.168.2.0/24) e também a rede de
origem (SRCNET=192.168.1.0/24). Finalmente, o administrador indica o endereço IP de destino,
que é o endereço IP externamente acessível da LAN B (X.X.X.X).
Veja
o
conteúdo
do
arquivo
da
chave
pré-compartilhada,
chamado
/etc/sysconfig/network-scripts/keys-ipsecX onde X (onde X é 0 para a LAN A e 1 para
a LAN B), que as duas redes usam para autenticarem-se entre si. O conteúdo destes arquivos deve ser
idêntico e somente o usuário root pode ser capaz de acessar ou gravar este arquivo.
IKE_PSK=r3dh4tl1nux
Importante
Para alterar o arquivo keys-ipsecX para que somente o usuário root possa acessá-lo ou editá-lo,
execute o seguinte comando após criar o arquivo:
62
chmod 600 /etc/sysconfig/network-scripts/keys-ipsec1
Para alterar a chave de autenticação a qualquer momento, edite o arquivo keys-ipsecX nos dois
roteadores IPsec. As duas chaves devem ser idênticas para que a conexão funcione apropriadamente.
Veja o conteúdo do arquivo de configuração /etc/racoon/racoon.conf da conexão IPsec. Note
que a linha include na parte inferior do arquivo é automaticamente gerada e aparece somente se o
túnel IPsec está rodando.
# Racoon IKE daemon configuration file.
# See ’man racoon.conf’ for a description of the format and entries.
path include "/etc/racoon";
path pre_shared_key "/etc/racoon/psk.txt";
path certificate "/etc/racoon/certs";
sainfo anonymous
{
pfs_group 2;
lifetime time 1 hour ;
encryption_algorithm 3des, blowfish 448, rijndael ;
authentication_algorithm hmac_sha1, hmac_md5 ;
compression_algorithm deflate ;
}
include "/etc/racoon/X.X.X.X.conf"
Veja a seguir o arquivo de configuração específico da conexão à rede remota. O arquivo é nomeado
como X.X.X.X.conf (substitua X.X.X.X pelo endereço IP do roteador IPsec remoto). Note que
este arquivo é gerado automaticamente quando o túnel IPsec é ativado e não deve ser editado diretamente.
;
remote X.X.X.X
{
exchange_mode aggressive, main;
my_identifier address;
proposal {
encryption_algorithm 3des;
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
63
As conexões são ativadas e as duas LANs, A e B, são capazes de comunicar entre si. As rotas são
criadas automaticamente através do script de início invocado pela execução do ifup na conexão
IPsec. Para visualizar uma lista de rotas da rede, execute o seguinte comando:
/sbin/ip route list
Para testar a conexão IPsec, execute o utilitário tcpdump no dispositivo externamente roteável (eth0
neste exemplo) para visualizar os pacotes de rede sendo transferidos entre as máquinas (ou redes) e
para verificar se estão criptografados com IPsec. Por exemplo: para verificar a conectividade da LAN
A, digite o seguinte:
tcpdump -n -i eth0 host lana.example.com
O pacote deve incluir um cabeçalho AH e deve ser exibido como um pacote ESP. ESP significa que
está criptografado. Por exemplo (barras invertidas denotam a continuação de uma linha):
12:24:26.155529 lanb.example.com > lana.example.com: AH(spi=0x021c9834,seq=0x358): \
lanb.example.com > lana.example.com: ESP(spi=0x00c887ad,seq=0x358) (DF) \
(ipip-proto-4)
64
Capítulo 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.
Juntamente às soluções VPN, como CIPE ou IPSec (abordados no Capítulo 6), os firewalls são um dos
componentes centrais da implementação de segurança na rede. Diversos fabricantes comercializam
soluções de firewall para suprir todos os nichos do mercado: de usuários domésticos protegendo um
PC até soluções de centro de dados para proteger informações corporativas vitais. Firewalls podem
ser soluções de hardware ligados intermitentemente, como as aplicações de firewall da Cisco, Nokia e
Sonicwall. Também há soluções de software de firewall proprietárias desenvolvidas para os mercados
doméstico e corporativo por fabricantes como Checkpoint, McAfee e Symantec.
Além das diferenças entre hardware e software de firewall, também há diferenças na maneira como
os firewalls funcionam, que separam uma solução da outra. A Tabela 7-1 detalha três tipos comuns de
firewalls e como eles funcionam:
Método Descrição
Vantagens
NAT
Pode ser configurado
Não pode evitar atividades
transparentemente para
maldosas uma vez que
máquinas em uma LAN
usuários se conectam a um
serviço fora do firewall
A proteção de muitas
máquinas e serviços por
trás de um ou mais
endereços IP externos
simplifica tarefas de
administração
A restrição de acesso do
usuário de e para a LAN
pode ser configurada
abrindo e fechando portas
no firewall/gateway da NAT
Tradução do Endereço da
Rede (Network Address
Translation, NAT) insere
sub-redes IP internas por
trás de um ou um pequeno
grupo de endereços IP
públicos, mascarando todos
os pedidos para uma fonte
ao invés de várias.
0
0
0
Desvantagens
0
66
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
Um firewall de filtragem de
pacotes lê cada pacote de
dados que passa por dentro
e por fora de uma LAN.
Pode ler e processar pacotes
pela informação do
cabeçalho e filtrar 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.
1
1
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, o desempenho da
rede é mais rápido devido à
conexão direta do cliente à
máquina remota
1
1
Dá aos administradores o
controle de quais
aplicações e protocolos
funcionam fora da LAN
Alguns servidores proxy
podem armazenar dados
frequentemente acessados
no cache localmente, ao
invés de ter que usar a
conexão Internet para
solicitá-los, o que é
conveniente para reduzir o
consumo desnecessário de
banda
Os serviços proxy podem
ser registrados e
monitorados de perto,
permitindo um controle
mais restrito sobre a
utilização de recursos na
rede
1
1
1
1
1
1
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 um serviço
remoto
1
1
Tabela 7-1. Tipos de Firewall
7.1. Netfilter e iptables
O kernel do Linux apresenta um sub-sistema de rede poderoso chamado Netfilter. O sub-sistema
Netfilter oferece filtragem de pacote de estado (que guarda o estado das conexões inciadas pelos
clientes) ou sem estado/’stateless’ (na qual cada pacote é analisado individualmente, sem levar em
conta pacotes anteriores trocados na mesma conexão), assim como NAT e serviços de mascaramento
de IP. O Netfilter também tem a habilidade de danificar as informações do cabeçalho para roteamento
avançado e gerenciamento do estado de conexão. O Netfilter é controlado através da funcionalidade
iptables.
67
7.1.1. Visão geral do iptables
O poder e flexibilidade do Netfilter é implementado através da interface do iptables. Esta ferramenta de linha de comando é similar em sintaxe ao seu predecessor, o ipchains. No entanto,
iptables usa o sub-sistema do Netfilter para melhorar a conexão, inspeção e processamento de
rede; enquanto o ipchains usava conjuntos de regras complexas para filtrar localidades de fonte e
destino, assim como portas de conexão para ambos. O iptables inclui registro avançado, ações pré
e pós-roteamento, tradução do endereço de rede e encaminhamento de porta; tudo em apenas uma
interface de linha de comando.
Esta seção oferece uma visão geral do iptables. Para informações mais detalhadas sobre o
iptables, consulte o Guia de Referência do Red Hat Enterprise Linux.
7.2. Usando o iptables
O primeiro passo para usar o iptables é iniciá-lo. Isto pode ser feito com o comando:
service iptables start
Atenção
Os serviços ip6tables devem ser desligados para usar o serviço iptables com os seguintes comandos:
service ip6tables stop
chkconfig ip6tables off
Para fazer com que o iptables inicie por default sempre que a máquina for inicializada, você deve
alterar o status do nível de execução (runlevel) do serviço usando chkconfig.
chkconfig --level 345 iptables on
A sintaxe do iptables é separada em camadas. A camada principal é a corrente (chain). Uma corrente especifica o estado no qual um pacote é manipulado. O uso é o seguinte:
iptables -A chain -j target
O -A acrescenta uma regra no fim de um conjunto de regras existente. A corrente é o nome
da corrente para uma regra. As três correntes embutidas do iptables (ou seja, as correntes que
afetam todos os pacotes que trafegam pela rede) são INPUT, OUTPUT e FORWARD. Estas correntes
são permanentes e não podem ser apagadas. A opção -j target (alvo) especifica a localidade no
conjunto de regras do iptables onde essa regra específica deve pular. Alguns alvos embutidos são
ACCEPT, DROP e REJECT.
Correntes novas (também chamadas de correntes definidas pelo usuário) podem ser criadas usando a
opção -N. Criar uma corrente nova é útil para personalizar ou elaborar regras.
7.2.1. Normas Básicas de Firewall
Estabelecer normas básicas de firewall é a base para criar outras regras detalhadas definidas pelo
usuário. O iptables usa normas (-P) para criar regras default. Administradores com foco em segurança geralmente escolhem derrubar todos os pacotes como uma norma e só permitem pacotes
68
específicos, analisando-os caso-a-caso. As seguintes regras bloqueiam todos os pacotes entrando e
saindo de uma porta de comunicação (gateway) de rede:
iptables -P INPUT DROP
iptables -P OUTPUT DROP
Adicionalmente, é recomendado que qualquer pacote encaminhado — tráfego de rede roteado do
firewall para seu nódulo de destino — seja negado também, para restringir os clientes internos da
exposição inadvertida à Internet. Para fazer isso, use a seguinte regra:
iptables -P FORWARD DROP
Após definir as normas de correntes, você pode criar novas regras para a sua rede e seus requisitos de
segurança em particular. As seguintes seções descrevem algumas regras que você talvez implemente
enquanto constrói seu firewall iptables.
7.2.2. Salvando e Restaurando Regras do iptables
As regras de firewall são válidas somente enquanto o computador estiver ligado. Portanto, se o sistema
for reinicializado, as regras serão automaticamente eliminadas e restauradas. Para salvar as regras de
modo que elas sejam carregadas posteriormente, use o seguinte comando:
/sbin/service iptables save
As regras são armazenadas no arquivo /etc/sysconfig/iptables e são aplicadas sempre que o
serviço é iniciado, reiniciado ou quando a máquina é reinicializada.
7.3. Filtragem Comum do iptables
Manter atacantes remotos fora de uma LAN é um aspecto importante da segurança de rede, senão
o mais importante. A integridade de uma LAN deve ser protegida de usuários remotos maldosos,
através do uso de regras rígidas de firewall. Entretanto, com uma norma default definida para bloquear
todos os pacotes entrando, saindo e encaminhados, é impossível que o firewall/porta de comunicação
(gateway) e usuários internos da LAN comuniquem-se entre si ou com recursos externos. Para permitir
a usuários executar funções relacionadas à rede e a usar aplicações de rede, os administradores devem
abrir certas portas para a comunicação.
Por exemplo: para permitir o acesso à porta 80 pelo firewall, adicione a seguinte regra:
iptables -A INPUT -p tcp -m tcp --sport 80 -j ACCEPT
iptables -A OUTPUT -p tcp -m tcp --dport 80 -j ACCEPT
Isto permite a navegação Web normal através de sites que comunicam através da porta 80. Para 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
Importante
Ao criar um conjunto de regras do iptables, é crucial lembrar que a ordem é importante. Por exemplo: se uma corrente especifica que todos os pacotes da sub-rede local 192.168.100.0/24 são
derrubados e uma outra corrente é adicionada (-A) para permitir pacotes do 192.168.100.13 (que
69
está dentro da sub-rede restrita derrubada), então a regra adicionada é ignorada. Você deve definir
uma regra para permitir 192.168.100.13 primeiro, e então definir uma regra para derrubar na subrede.
Para inserir uma regra arbitrariamente num conjunto de regras existentes, use -I, seguido pela
corrente na qual deseja inserir a regra e o número da regra (1,2,3,...,n) onde você deseja que a
regra resida. Por exemplo:
iptables -I INPUT 1 -i lo -p all -j ACCEPT
A regra é inserida como a primeira no conjunto INPUT para permitir o tráfego do dispositivo loopback
local.
Algumas vezes você precisa de acesso remoto à LAN de fora dela. Serviços seguros, como SSH,
podem ser usados para conexão remota criptografada aos serviços da LAN. Para administradores com
recursos baseados em PPP (tais como bancos de modem ou contas ISP volumosas), o acesso discado
pode ser usado para circundar as barreiras do firewall seguramente, já que conexões via modem ficam
tipicamente por trás de um firewall/gateway por serem conexões diretas. Entretanto, casos especiais
podem ser elaborados para usuários remotos com conexões de banda larga. Você pode configurar o
iptables para aceitar conexões de clientes SSH remotos. Por exemplo: para permitir o acesso SSH
remoto, as seguintes regras podem ser usadas:
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
iptables -A OUTPUT -p udp --sport 22 -j ACCEPT
Há outros serviços para os quais você talvez precise definir regras. Consulte o Guia de Referência do
Red Hat Enterprise Linux para informações detalhadas sobre o iptables e suas várias opções.
Estas regras permitem o acesso de entrada e saída para um único sistema, como um PC conectado
diretamente à Internet ou firewall/porta de comunicação (gateway). No entanto, não permitem que os
nódulos por trás do firewall/porta de comunicação acessem estes serviços. Para permitir o acesso LAN
a estes serviços, você pode usar o NAT com regras de filtragem do iptables.
7.4. Regras FORWARD e NAT
A maioria das empresas designam um número limitado de endereços IP publicamente roteáveis de
seus ISPs. Devido essa permissão limitada, os administradores devem encontrar maneiras criativas de
compartilhar o acesso aos serviços de Internet sem dar endereços IP limitados para cada nódulo da
LAN. Usar um endereço IP privado é a maneira comum de permitir que todos os nódulos de uma LAN
acessem apropriadamente serviços de rede internos e externos. Roteadores de borda (como firewalls)
podem receber transmissões de entrada da Internet e rotear os pacotes para o nódulo pretendido na
LAN. Ao mesmo tempo, o firewall/portas de comunicação (gateways) também podem rotear pedidos
de saída de um nódulo da LAN para o serviço remoto da Internet. Esse encaminhamento de tráfego de
rede pode se tornar perigoso às vezes, especialmente com a disponibilidade de ferramentas de cracking
modernas que podem espionar endereços IP internos e fazer com que a máquina remota do atacante
atue como um nódulo em sua LAN. Para evitar isso, o iptables oferece normas de roteamento e
encaminhamento que podem ser implementadas para evitar o uso indevido dos recursos de rede.
A norma FORWARD permite a um administrador controlar onde os pacotes podem ser roteados em
uma LAN. Por exemplo: para permitir o encaminhamento para a LAN inteira (assumindo que o firewall/porta de comunicação tenha um endereço IP interno na eth 1), as seguintes regras podem ser
definidas:
iptables -A FORWARD -i eth1 -j ACCEPT
iptables -A FORWARD -o eth1 -j ACCEPT
70
Essa regra da acesso para a rede interna aos sistemas por trás do firewall/porta de comunicação. A
porta de comuncação roteia os pacotes de um nódulo da LAN para o seu nódulo pretendido, passando
todos os pacotes através de seu dispositivo eth1.
Nota
Por default, a norma IPV4 nos kernels do Red Hat Enterprise Linux desabilita o suporte para 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
Aceitar pacotes encaminhados através do dispositivo IP interno do firewall permite que os nódulos
da LAN comuniquem-se entre si; mas não permite que comuniquem-se externamente com a Internet.
Para permitir que nódulos da LAN com endereços IP privados comuniquem-se com redes públicas
externas, configure o firewall com o mascaramento do IP, que mascara pedidos de nódulos da LAN
com endereços IP do dispositivo externo do firewall (neste caso, eth0):
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
A regra usa a tabela de pacotes coincidentes da NAT (-t nat) e especifica a corrente POSTROUTING embutida para a NAT (-A POSTROUTING) no dispositivo de rede externa do firewall (-o eth0).
O POSTROUTING (pós-roteamento) permite que os pacotes sejam alterados conforme deixam o dispositivo externo do firewall. O alvo -j MASQUERADE é especificado para mascarar o endereço IP
privado de um nódulo com o endereço IP externo do firewall/porta de comunicação.
Se você tem um servidor em sua rede interna que deseja disponibilizar externamente, pode usar o
alvo -j DNAT da corrente PREROUTING na NAT para especificar um endereço IP e porta de destino
para onde encaminhar os pacotes de entrada requisitando uma conexão. Por exemplo: se você deseja
encaminhar os pedidos HTTP de entrada para seu servidor Servidor HTTP Apache dedicado para
172.31.0.23, submeta o seguinte comando:
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT \
--to 172.31.0.23:80
Esta regra especifica que a tabela NAT usa a corrente PREROUTING embutida para encaminhar
pacotes HTTP de entrada exclusivamente para o endereço IP 172.31.0.23 listado.
Nota
Se você tem uma norma default DROP na sua corrente FORWARD, deve adicionar uma regra para
permitir o encaminhamento de pedidos HTTP de entrada para possibilitar o roteamento do destino
da NAT. Para fazer isso, submeta o seguinte comando:
71
iptables -A FORWARD -i eth0 -p tcp --dport 80 -d 172.31.0.23 -j ACCEPT
Esta regra permite o encaminhamento de pedidos de entrada HTTP do firewall para seu destino
pretendido no Servidor HTTP Apache por trás do firewall.
7.4.1. DMZs e iptables
As regras do iptables também podem definidas para rotear tráfego para determinadas máquinas,
como um servidor dedicado HTTP ou FTP, numa zona desmilitarizada (DMZ) — uma sub-rede local
especial dedicada a prover serviços num meio público como a Internet. Por exemplo: para definir uma
regra para rotear os pedidos HTTP externos para um servidor HTTP dedicado no endereço IP 10.0.4.2
(fora do intervalo 192.168.1.0/24 da LAN), a tradução de endereço de rede (NAT) evoca uma tabela
PREROUTING para encaminhar os pacotes ao destino apropriado:
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT \
--to-destination 10.0.4.2:80
Com este comando, todas as conexões HTTP para a porta 80 de fora da LAN são roteadas ao servidor
HTTP em uma rede separada do resto da rede interna. Esta forma de segmentação de rede pode ser
mais segura que permitir conexões HTTP para uma máquina na rede. Se o servidor HTTP estiver
configurado para aceitar conexões seguras, então a porta 443 deve ser encaminhada também.
7.5. Vírus e Endereços IP Espionados (spoofed)
Outras regras elaboradas podem ser criadas para controlar o acesso a sub-redes específicas, ou até a
nódulos específicos, dentro de uma LAN. Você também pode restringir que determinados serviços
dúbios, como trojans, vermes, e outros vírus de clientes/servidor, contatem seu servidor. Por exemplo:
há alguns trojans que scaneam redes para serviços nas portas de 31337 a 31340 (chamadas portas de
elite na terminologia dos crackers). Como não há serviços legítimos que comunicam através destas
portas fora do padrão, bloqueá-los pode diminuir efetivamente as chances de nódulos potencialmente
infectados em sua rede se comunicarem independentemente com seus servidores mestres remotos.
iptables -A OUTPUT -o eth0 -p tcp --dport 31337 --sport 31337 -j DROP
iptables -A FORWARD -o eth0 -p tcp --dport 31337 --sport 31337 -j DROP
Você também pode bloquear as conexões externas que tentam espionar intervalos de endereços IP
privados a fim de infiltrarem em sua LAN. Por exemplo: se uma LAN usa o intervalo 192.168.1.0/24,
uma regra pode determinar que o dispositivo de rede que faz a interface com a Internet (eth0, por
exemplo) derrube quaisquer pacotes parta este dispositivo com um endereço do intervalo de IP de sua
LAN. Como norma default, é recomendado rejeitar pacotes encaminhados, portanto qualquer outro
endereço IP espionado ao dispositivo que faz a interface externa (eth0) é rejeitado automaticamente.
iptables -A FORWARD -s 192.168.1.0/24 -i eth0 -j DROP
Nota
Há uma distinção entre DROP (derrubar) e REJECT (rejeitar) um alvo quando estamos lidando com
regras adicionais. REJECT um alvo nega acesso e retorna um erro connection refused (conexão
negada) para usuários que tentarem se conectar ao serviço. A ação DROP (derrubar) um alvo, como
o nome sugere, derruba os pacotes sem nenhum aviso. Administradores podem usar sua própria
prudência ao lidar com estes alvos; entretanto, para evitar a confusão do usuário e tentativas para
continuar conectando, a REJECT alvo é recomendada.
72
7.6. iptables e Registro de Conexão
O iptables inclui um módulo que permite aos administradores inspecionar e restringir conexões a
serviços disponíveis numa rede interna, usando um método chamado registro de conexão (connection
tracking). O registro de conexão armazena as conexões numa tabela, que permite aos administradores
permitir ou negar acesso baseado nos seguintes estados de conexão:
• NEW
(nova) — Um pacote requisitando uma nova conexão, como um pedido HTTP.
• ESTABLISHED (estabelecida)
— Um pacote que é parte de uma conexão existente.
(relacionado) — Um pacote solicitando uma nova conexão, mas que é parte de uma
conexão existente, como conexões FTP passivas, nas quais a porta de conexão é 20, mas a porta de
transferência pode ser qualquer uma (de 1024 para cima) não usada.
• RELATED
• INVALID (inválido)
das conexões.
— Um pacote que não faz parte de nenhuma das conexões da tabela de registro
Você pode usar a funcionalidade de estado do registro de conexões do iptables com qualquer protocolo de rede, mesmo que o próprio protocolo seja sem estado/’stateless’ (como o UDP). O exemplo a
seguir mostra uma regra que usa o registro de conexão para encaminhar somente os pacotes associados
a uma conexão estabelecida:
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ALLOW
7.7. ip6tables
A introdução do Protocolo de Internet de última geração chamado IPv6, vai além do limite de 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 é inicializado, altere o
estado do nível de execução (runlevel) do serviço usando chkconfig.
chkconfig --level 345 ip6tables on
73
A sintaxe é idêntica à do iptables em todos os aspectos, exceto pelo fato do ip6tables suportar
endereços de 128 bits. Por exemplo: as conexões SSH em um servidor de rede ciente do IPv6 podem
ser possibilitadas pela seguinte regra:
ip6tables -A INPUT -i eth0 -p tcp -s 3ffe:ffff:100::1/128 --dport 22 -j ACCEPT
Para mais informações sobre redes com IPv6, consulte a página de informações sobre o IPv6:
http://www.ipv6.org/.
7.8. Recursos Adicionais
Há diversos aspectos do firewall e do sub-sistema Netfilter do Linux que não foram abordados neste
capítulo. Para mais informações, consulte os seguintes recursos.
7.8.1. Documentação Instalada
•
O Guia de Referência do Red Hat Enterprise Linux inclui um capítulo detalhado sobre o iptables,
incluindo as definições de todas as opções de comandos.
•
A página man do iptables também contém um breve resumo das várias opções.
•
Uma lista dos serviços mais comuns e seus números de porta pode ser encontrada no Apêndice C e
no arquivo /etc/services.
7.8.2. Websites Úteis
•
http://www.netfilter.org/ — O site oficial do Netfilter e do projeto iptables.
•
http://www.tldp.org/ — O Projeto de Documentação do Linux contém diversos guias úteis 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
•
Red Hat Linux Firewalls, de Bill McCarty; Red Hat Press — uma referência detalhada para a
criação de firewalls de rede e servidores usando tecnologia de filtragem open source como Netfilter
e iptables. Inclui tópicos como a análise de registros de firewalls, criação de regras de firewall e
a personalização de seu firewall com ferramentas gráficas como lokkit.
•
Linux Firewalls, de Robert Ziegler; New Riders Press. — contém muitas informações sobre a criação de firewalls usando o ipchains do kernel 2.2, assim como o Netfilter e iptables. Tópicos
adicionais de segurança, como questões de acesso remoto e sistemas de detecção de intrusão também são abordados.
74
III. Avaliando Sua Segurança
Esta parte oferece uma visão geral da teoria e prática da avaliação de segurança. De monitores de rede
a ferramentas de cracking, um administrador pode aprender mais sobre a proteção de um sistema e de
uma rede, crackeando-os.
Índice
8. Avaliação de Vulnerabilidade....................................................................................................... 77
Capítulo 8.
Avaliação de Vulnerabilidade
Dados o tempo, os recursos e a motivação, um cracker pode violar praticamente qualquer sistema.
No final das contas, todos os procedimentos e tecnologias de segurança atualmente disponíveis não
podem garantir que seus sistemas estão seguros contra uma intrusão. Os roteadores ajudam a proteger
suas portas de comunicação (gateways) com a Internet. Firewalls ajudam a proteger a fronteira da
rede. Redes Privadas Virtuais (Virtual Private Networks - VPNs) podem transferir dados seguramente
através de informações criptografadas. Sistemas de detecção de intrusão podem alertá-lo sobre 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 para.
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 atualizado, é 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, você deve
pensar como um cracker e medir a segurança de seus sistemas verificando suas fraquezas. Avaliações
preventivas de vulnerabilidades em seus próprios sistemas e recursos de rede podem revelar questões
potenciais a serem consideradas antes de um cracker explorá-las.
Uma avaliação de vulnerabilidade é uma auditoria interna da segurança de sua rede e sistemas, 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 sua
DMZ, interfaces externas de seu firewall e mais. DMZ significa "demilitarized zone" (zona desmilitarizada), que corresponde a um computador ou uma sub-rede pequena situada entre a rede interna, tal
como uma LAN privada corporativa, e uma rede externa não-confiável, como a Internet pública. Tipicamente, a DMZ contém dispositivos acessíveis ao tráfego da Internet, como servidores web (HTTP),
servidores FTP, servidores SMTP (e-mail) e servidores DNS.
Ao executar uma avaliação de vulnerabilidade de dentro olhando ao redor, você está, de certa maneira,
em vantagem já que você é interno e seu status é elevado a confiável. Esse é o ponto de vista que você
e seus colegas de trabalho têm ao se autenticarem em seus sistemas. Você vê servidores de impressão,
servidores de arquivos, bancos de dados e outros recursos.
Há diferenças notáveis entre estes dois tipos de avaliação de vulnerabilidade. Ser interno em sua
empresa lhe proporciona privilégios — mais elevados que qualquer externo. Ainda hoje em algumas
empresas, a segurança é configurada de modo a manter os intrusos fora. Muito pouco é feito para
proteger os internos da empresa (tais como firewalls departamentais, controles de acesso no nível de
usuário, procedimentos de autenticação para recursos internos e outros). Geralmente, há muito mais
recursos quando olhamos de dentro ao redor dado que a maioria dos sistemas são internos a uma
empresa. Uma vez que você se coloca fora da empresa, imediatamente terá o status não confiável. Os
sistemas e recursos disponíveis a você externamente são frequentemente muito limitados.
Considere a diferença entre as avaliações de vulnerabilidade e testes de penetração. Pense em uma
avaliação de vulnerabilidade como o primeiro passo de um teste de penetração. As informações obtidas na avaliação serão utilizadas nos testes. Enquanto a avaliação verifica buracos e vulnerabilidades
potenciais, os testes de penetração tentam explorar os resultados.
Avaliar a infra-estrutura da rede é um processo dinâmico. A segurança de ambos, da informação e
física, é dinâmica. Executar uma avaliação traz uma visão geral, que pode incluir falsos positivos e
falsos negativos.
Administradores de segurança são tão bons quanto as ferramentas que usam e o conhecimento que
possuem. Pegue qualquer uma das ferramentas de avaliação disponíveis, execute-as em seu sistema, e
é quase certeza que haja pelo menos alguns falsos positivos. O resultado é o mesmo, seja por erro do
programa ou do usuário. A ferramenta pode encontrar vulnerabilidades que na realidade não existem
(falsos positivos) ou, pior ainda, ela pode não detectar vulnerabilidades que realmente existem (falsos
negativos).
Agora que a diferença entre avaliação de vulnerabilidade e teste de penetração está definida, é recomendável revisar os resultados da avaliação cuidadosamente antes de conduzir um teste de penetração, como parte de sua nova tática para as melhores práticas.
Atenção
Tentar explorar vulnerabilidades dos recursos de produção pode resultar em efeitos adversos na
produtividade e eficiência de seus sistemas e rede.
79
A lista a seguir examina alguns dos benefícios em executar avaliações de vulnerabilidade.
•
Cria foco pró-ativo na segurança da informação
•
Encontra exploits potenciais antes que os crackers os encontrem
•
Resulta em sistemas sendo mantidos atualizados e consertados
•
Promove o crescimento e ajuda a desenvolver as habilidades dos funcionários
•
Reduz perdas financeiras e publicidade negativa
8.2.1. Estabeleça uma Metodologia
Para auxiliar na selação de ferramentas para a avaliação de vulnerabilidade, é útil estabelecer uma
metodologia de avaliação de vulnerabilidade. Infelizmente, não há nenhuma metodologia pré-definida
ou aprovada pelo setor no momento, porém bom senso e as melhores práticas podem agir suficientemente como guias.
Qual é o alvo? Nós estamos verificando um servidor, ou verificando nossa rede inteira e tudo que há
nesta rede? Somos internos ou externos à empresa? As respostas a estas questões são importantes,
pois ajudam a determinar não apenas quais ferramentas selecionar, mas também a maneira como são
utilizadas.
Para aprender mais sobre o estabelecimento de metodologias, consulte os seguintes websites:
•
http://www.isecom.org/projects/osstmm.htm — The Open Source Security Testing Methodology
Manual (O Manual de Metodologia de Testes de Segurança Open Source) - OSSTMM
•
http://www.owasp.org/ — The Open Web Application Security Project (O Projeto Livre de Segurança de Aplicações Web)
8.3. Avaliando as Ferramentas
Uma avaliação pode começar com o uso de alguma forma de ferramenta de coleta de informações. Ao
avaliar a rede inteira, primeiramente mapeie o layout para encontrar máquinas que estejam rodando.
Após localizá-las, examine cada máquina separadamente. Focar nestas máquinas requer um outro
conjunto de ferramentas. Saber quais ferramentas utilizar deve ser o passo crucial para encontrar
vulnerabilidades.
Assim como em qualquer aspecto do cotidiano, há muitas ferramentas diferentes que desempenham
a mesma função. Este conceito também se aplica à execução das avaliações de vulnerabilidade. Há
ferramentas específicas para sistemas operacionais, para aplicações e até mesmo para redes (baseadas
nos protocolos utilizados). Algumas ferramentas são grátis e outras não. Algumas ferramentas são
intuitivas e fáceis de utilizar, enquanto outras são obscuras e mal documentadas, mas possuem funcionalidades que outras não possuem.
Encontrar as ferramnentas corretas pode ser uma tarefa difícil, mas no final das contas, a experiênca
conta. Se possível, monte um laboratório de testes e experimente quantas ferramentas puder, anotando
os pontos fortes e fracos de cada uma. Reveja o arquivo README ou a página man da ferramenta.
Adicionalmente, procure na Internet por mais informações, como artigos, manuais passo-a-passo ou
até mesmo listas de discussão específicas da ferramenta.
As ferramentas explanadas abaixo são apenas uma pequena amostra das ferramentas disponíveis.
80
8.3.1. Scaneando Máquinas com Nmap
Nmap é uma ferramenta conhecida que pode ser usada no Red Hat Enterprise Linux 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. Há uma página man excelente, que oferece uma descrição
detalhada de suas opções e usos. Administradores podem usar o Nmap em uma rede para encontrar
sistemas hospedeiros e portas abertas nestes sistemas.
O Nmap é um primeiro passo eficaz na avaliação de vulnerabilidade. Você pode mapear todas as
máquinas dentro de uma rede, e inclusive passar uma opção que a permite ao Nmap tentar identificar
o sistema operacional rodando numa determinada máquina. O Nmap é uma boa base para estabelecer
normas de uso de serviços seguros e para parar serviços não usados.
8.3.1.1. Usando o Nmap
O Nmap pode ser executado a partir de uma janela de comandos, digitando nmap seguido do nome da
máquina ou endereço IP da máquina que você deseja scanear.
nmap foo.example.com
Os resultados do scan (que podem levar até alguns minutos, dependendo de onde a máquina está
localizada) devem se parecer com o seguinte:
Starting nmap V. 3.50 ( www.insecure.org/nmap/ )
Interesting ports on localhost.localdomain (127.0.0.1):
(The 1591 ports scanned but not shown below are in state: closed)
Port
State
Service
22/tcp
open
ssh
25/tcp
open
smtp
111/tcp
open
sunrpc
443/tcp
open
https
515/tcp
open
printer
950/tcp
open
oftep-rpc
6000/tcp
open
X11
Nmap run completed -- 1 IP address (1 host up) scanned in 71.825 seconds
O Nmap testa as portas de comunicação mais comuns numa rede para escutar ou esperar serviços.
Esse conhecimento pode ser útil a um administrador que deseja encerrar serviços desnecessários ou
não-usados.
Para mais informações sobre o uso do Nmap, consulte o site oficial no endereço:
http://www.insecure.org/
8.3.2. Nessus
O Nessus é um scanner de segurança ’full-service’. A arquitetura plug-in do Nessus permite que
usuários personalizem-no para seus sistemas e redes. Assim como qualquer scanner, o Nessus é tão
bom quanto o banco de dados de assinatura no qual ele se baseia. Felizmente, o Nessus é frequentemente atualizado. Suas funcionalidades incluem relatório completo, scanning da máquina e buscas de
vulnerabilidades em tempo real. Lembre-se que pode haver falsos positivos e falsos negativos, mesmo
numa ferramenta tão poderosa e atualizada como o Nessus.
81
Nota
O 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 endereço:
http://www.nessus.org/
8.3.3. Nikto
O Nikto é um scanner de script CGI excelente. Nikto não tem apenas a capacidade de verificar 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. Se você tem servidores Web servindo scripts CGI, o Nikto pode ser um excelente
recurso para checar a segurança destes servidores.
Nota
O Nikto não está incluso no Red Hat Enterprise Linux e não é suportado. Foi incluso neste documento como uma referência para usuários que possam se interessar por esta aplicação.
Mais informações sobre o Nikto podem ser encontradas na seguinte URL:
http://www.cirt.net/code/nikto.shtml
8.3.4. VLAD the Scanner
O VLAD é um scanner de vulnerabilidades desenvolvido pela equipe RAZOR da Bindview, Inc., que
verifica a lista das dez questões mais comuns de segurança da SANS (questões do SNMP, questões de
compartilhamento de arquivo, etc). Apesar de não ter tantas funcionalidades quanto o Nessus, vale a
pena investigar o VLAD.
Nota
O VLAD não está incluso no Red Hat Enterprise Linux e não é suportado. Foi incluso neste documento como uma referência para usuários que possam se interessar por esta aplicação.
Mais informações sobre o VLAD podem ser encontradas no site da equipe RAZOR na seguinte URL:
http://www.bindview.com/Support/Razor/Utilities/
82
8.3.5. Antecipando Suas Necessidades Futuras
Dependendo do seu alvo e recursos, há muitas ferramentas disponíveis. Há ferramentas para redes
sem fio, redes Novell, sistemas Windows, sistemas Linux e outros. Outra parte essencial ao executar
avaliações deve incluir a revisão da segurança física, cobertura de pessoal ou avaliação da rede de
voz/PABX. Conceitos novos como o war walking — scanning do perímetro das estruturas físicas de
sua empresa para encontrar vulnerabilidades da rede sem fio — são conceitos emergentes que você
pode investigar e, se necessário, incorporá-los às suas avaliações. Imaginação e exposição são os
únicos limites para planejar e conduzir avaliações de vulnerabilidade.
IV. Intrusões e Resposta a Incidentes
É inevitável uma rede sofrer intrusões ou o uso maléfico de seus recursos. Esta parte aborda algumas
medidas pró-ativas que um administrador pode tomar para evitar quebras na segurança, tais como
formar uma equipe de resposta a emergências, capaz de responder rápida e efetivamente a questões
de segurança. Além disso, esta parte também detalha os passos a tomar para agupar e analisar as
evidências de uma quebra na segurança após o fato ter ocorrido.
Índice
9. Detecção de Invasão ...................................................................................................................... 85
10. Resposta ao Incidente ................................................................................................................. 91
Capítulo 9.
Detecção de Invasão
Uma propriedade de valor necessita de proteção contra ações de roubo e destruição. Algumas casas
são equipadas com sistemas de alarme capazes de deter ladrões, notificar as autoridades na ocasião de
uma invasão e inclusive alertar o proprietário quando sua casa estiver sendo incendiada. Tais medidas
são necessárias para assegurar a integridade das casas e a segurança de seus proprietários.
A mesma garantia de integridade e segurança também deve ser aplicada a sistemas de dados e 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 agir como este sistema de alerta.
9.1. Definindo Sistemas de Detecção de Intrusão
Um sistema de detecção de intrusão (intrusion detection system, IDS) é um processo ou dispositivo
ativo que analisa as atividades do sistema e da rede e identifica entradas não autorizadas e/ou 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 IDSs
Entender o que é um IDS e as funcionalidades que oferece é essencial para determinar qual será o tipo
apropriado para incluir em suas normas de segurança em informática. Esta seção aborda os conceitos
por trás dos IDSs, as funcionalidades de cada tipo de IDS e a emergência de IDSs híbridos que aplicam
diversas técnicas de detecção e ferramentas em um pacote.
Alguns IDSs são baseados no conhecimento, que alertam prioritariamente os administradores de segurança antes de uma intrusão ocorrer utilizando um banco de dados de ataques comuns. Alternativamente, há alguns IDSs comportamentais que rastreiam todos os usos de recursos para encontrar
anomalias, que normalmente são sinais positivos de atividades maldosas. Alguns IDSs são serviços
isolados (standalone) que trabalham por trás do cenário e monitoram passivamente as atividades,
registrando quaisquer pacotes suspeitos vindos de fora. Outros IDSs combinam ferramentas padrão
de sistema, configurações alteradas e registro de palavras, juntamente à intuição do administrador e
sua experiência em criar um kit de detecção de intrusão poderoso. Avaliar as diferentes técnicas de
detecção pode ajudar a encontrar uma que seja correta para sua organização.
Os tipos mais comuns de IDSs mencionados no campo da segurança são conhecidos como IDSs
baseados na máquina e baseados na rede. Um IDS baseado na máquina é o mais detalhado dos
dois, envolvendo a implementação de um sistema de detecção em cada máquina separadamente. Independente do ambiente de rede no qual a máquina reside, ela está protegida. Um IDS baseado na
rede afunila pacotes através de um único dispositivo antes de enviá-los a máquinas específicas. IDSs
baseados na rede são frequentemente encarados como menos detalhados, já que muitas máquinas num
ambiente móvel impossibilitam uma filtragem e proteção confiável dos pacotes na rede.
86
Capítulo 9. Detecção de Invasão
9.2. IDS baseado no servidor
Um IDS baseado na máquina analisa diversas áreas para determinar o mal-uso (atividades maléficas
ou truculentas dentro da rede) ou intrusão (incursões de fora). IDSs baseados na máquina consultam
diversos tipos de arquivos de registro (kernel, sistema, servidor, rede, firewall e outros) e comparam
os registros a um banco de dados interno com assinaturas comuns de ataques conhecidos. IDSs UNIX
e Linux baseados na máquina fazem uso constante do syslog e sua habilidade em separar eventos
registrados por sua severidade (por exemplo: pequenas mensagens de impressão versus sérios alertas
do kernel). O comando syslog é disponibilizado ao instalar o pacote sysklogd, inclulso no Red Hat
Enterprise Linux. Este pacote oferece registros do sistema e isolamento das mensagens do kernel. O
IDS baseado na máquina filtra os registros (que, no caso de alguns eventos da rede e do kernel, podem
ser bastante verbalizados), analisa-os, renomeia as mensagens anômalas com sua própria classificação
de severidade e os agrupa em seu próprio registro especializado para análise do adminstrador.
Um IDS baseado na máquina também pode verificar a integridade dos dados de arquivos importantes
e executáveis. Checa um banco de dados de arquivos importantes (e quaisquer arquivos adicionados
pelo administrador) e cria um checksum de cada arquivo com um utilitário de digestão do arquivo de
mensagem como o md5sum (algoritmo de 128 bits) ou o sha1sum (algoritmo de 160 bits). Então, o
IDS baseado na máquina armazena as consistências em um arquivo somente texto e compara 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 num
sistema Red Hat Enterprise Linux. Consulte o Guia de Administração de Sistemas Red Hat Enterprise
Linux para informações completas sobre o uso do RPM.
Importante
Alguns dos comandos da lista seguinte requerem a importação da chave pública GPG da Red Hat
para o chaveiro RPM do sistema. Esta chave verifica se os pacotes instalados em seu sistema
contêm uma assinatura de pacote da Red Hat, o que assegura que seus pacotes foram originados
2
3
87
da Red Hat. A chave pode ser importada atribuindo o seguinte comando como root (substituindo
version pela versão do RPM instalado no sistema):
rpm --import /usr/share/doc/rpm-
4
version
5
/RPM-GPG-KEY
rpm -V nome_do_pacote
A opção -V verifica os arquivos do pacote instalado chamado nome_do_pacote. Se não exibir
nenhum output e fechar, isto significa que nenhum dos arquivos foi modificado de maneira 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)
88
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
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 na máquina.
•
LIDS http://www.lids.org — O Sistema de Detecção de Intrusão Linux (Linux Intrusion Detection
System), LIDS, é um conserto do kernel e uma ferramenta de administração também capaz de
controlar modificações de arquivo com listas de controle de acesso (access control lists - ACLs), e
proteger processos e arquivos, inclusive do usuário root.
9.3. IDS baseado em rede
Sistemas de detecção de intrusão baseados em rede operam de maneira diferente dos IDSs baseados
na máquina. A filosofia de desenvolvimento de um IDS baseado em rede é scanear os pacotes da
rede no nível da máquina ou roteador, auditorando informações de pacotes e registrando quaisquer
pacotes suspeitos em um arquivo de registro especial com informações extras. Baseado nestes pacotes
suspeitos, um IDS baseado em rede pode scanear seu próprio banco de dados de assinaturas de ataques
de rede conhecidos e determinar um nível de severidade para cada pacote. Se os níveis de severidade
forem suficientemente altos, um email de alerta ou mensagem de celular será enviada aos membros
da equipe de segurança para que eles possam investigar a natureza da anomalia.
IDSs baseados em rede tornaram-se populares com o crescimento da Internet em tamanho e tráfego.
IDSs que podem scanear a volumosa quantidade de atividade de rede e nomear com êxito as 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 atividades maldosas
na rede como:
•
Spoofing do IP (alteração do endereço IP para parecer como outra máquina)
•
ataques denial-of-service
•
poisoning do cache arp (danificação do protocolo)
•
Corrupção do domínio DNS
•
ataques man-in-the-middle
89
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 num arquivo de registro sem análise nenhuma. Um IDS
apropriado analisa os pacotes, aponta transmissões de pacotes potencialmente maléficas e as armazena
num registro formatado.
O Snort é um IDS desenvolvido para ser detalhado e correto ao registrar com êxito as atividades
maléficas da rede e notificar os administradores quando potenciais brechas ocorrerem. Snort utiliza a
biblioteca padrão libcap e o tcpdump como um registro especializado de pacotes.
A característica mais premiada do Snort, somada à sua funcionalidade, é o seu sub-sistema flexível
de assinaturas de ataque. Snort tem um banco de dados de ataques constantemente atualizado
que pode ser adicionado à ou atualizado via Internet. Os usuários podem criar assinaturas
baseadas em novos ataques de rede e enviá-las às listas de discussão de assinaturas do Snort
(http://www.snort.org/lists.html), para beneficiar todos os usuários do Snort. Essa ética comunitária
em compartilhar elevou o Snort a um dos IDSs mais atualizados e robustos disponíveis no mercado.
Nota
O Snort não está incluso no Red Hat Enterprise Linux e não é suportado. Ele foi incluso neste
documento como referência para usuários interessados em avaliá-lo.
Para mais informações sobre o uso do Snort, consulte o site oficial: http://www.snort.org.
Capítulo 10.
Resposta ao Incidente
No caso da segurança de um sistema ter sido comprometida, uma resposta ao incidente se faz
necessária. É responsabilidade da equipe de segurança responder ao problema rápida e efetivamente.
10.1. Definindo Resposta ao Incidente
A resposta ao incidente é uma reação expedida a uma questão ou ocorrência de segurança. Pertinente
à segurança da informação, um exemplo seria as ações da equipe de segurança contra um hacker que
penetrou um firewall e está bisbilhotando o tráfego da rede interna. O incidente é uma infração da
segurança. A resposta depende de como a equipe de segurança reage, o que ela faz para mininmizar
os danos e quando recupera os recursos; tudo isso enquanto tenta garantir a integridade dos dados.
Pense na sua empresa e em como quase todos os aspectos dela dependem de tecnologia e sistemas
de computador. Se houver um comprometimento, imagine os resultados potencialmente devastadores.
Além do tempo em que o sistema ficará fora do ar e o roubo de dados, pode haver corrupção de dados,
roubo de identidade (a partir de registros pessoais online), má publicidade, ou até mesmo resultados
financeiros devastadores enquanto clientes e empresas aprendem a reagir negativamente na ocorrência
de comprometimento.
Pesquisas sobre as infrações anteriores na segurança (tanto internas quanto externas) mostram que
algumas empresas podem até ser fechadas como resultado de uma grave infração de segurança. Uma
infração pode tornar recursos indisponíveis e roubar ou corromper dados. Mas é muito difícil estimar
financeiramente os danos como má publicidade. Para ter uma idéia exata do quão importante é uma
resposta eficiente a um incidente, uma empresa deve calcular o custo de uma infração e também os
efeitos financeiros da publicidade negativa, a curto e longo prazo.
10.2. Criando um Plano de Resposta ao Incidente
É importante que um plano de resposta ao incidente seja formulado, apoiado através da empresa e
regularmente testado. Um bom plano de resposta ao incidente pode minimizar não somente os efeitos
de uma infração na segurança, mas também reduzir a publicidade negativa.
Sob a perspectiva de uma equipe de segurança, não importa se a infração ocorre (como parte das
eventuais transações usando um meio de rede não confiável, como a Internet), mas sim, quando uma
infração ocorre. Não pense em um sistema como fraco e vulnerável; é importante perceber que quando
há tempo e recursos suficientes alguém violará até mesmo o sistema ou rede mais super-protegido.
Não é necessário consultar nada além do site Security Focus, http://www.securityfocus.com, para obter
informações detalhadas e atualizadas sobre as recentes infrações e vulnerabilidades de segurança,
como a destruição frequente de páginas web corporativas até os ataques aos servidores DNS root em
20021.
O aspecto positivo de perceber a inevitabilidade de uma infração do sistema é que ela permite à equipe
de segurança desenvolver um curso das ações que minimizem qualquer dano potencial. Combinar o
curso das ações com habilidades permite à equipe responder a condições adversas de uma maneira
formal e responsável.
O plano de resposta ao incidente pode ser dividido em quatro fases:
•
1.
Ação imediata para interromper ou minimizar o incidente
http://www.gcn.com/21_32/web/20404-1.html
92
Capítulo 10. Resposta ao Incidente
•
Investigação do Incidente
•
Restauração dos recursos afetados
•
Reportando o indicente aos canais apropriados
Uma resposta a um incidente deve ser decisiva e executada rapidamente. Como há pouco espaço para
erros, é essencial que as práticas de emergência sejam ensaiadas e os tempos de resposta medidos.
Desta maneira, é possível desenvolver uma metodologia que estimule a velocidade e a acuracidade,
minimizando o impacto da indisponibilidade de recursos e os potenciais danos causados pelo 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/alta gerência
•
Um plano de ação factível e testado
•
Recursos físicos, como armazenamento redundante, sistemas de standby e serviços de backup
10.2.1. A Equipe de Resposta a Emergências de Computador (The Computer
Emergency Response Team - CERT)
O termo Equipe de Resposta às Emergências de Computador (Computer Emergency Response Team
- CERT) refere-se a um grupo de peritos internos preparados para agir rapidamente no caso de uma
situação catastrófica com computadores. Encontrar as competências cruciais para uma CERT pode ser
um desafio. O conceito de pessoal apropriado vai além das habilidades técnicas e inclui questões de
logística, como localização, disponibilidade e desejo de colocar a empresa à frente da vida pessoal
quando uma emergência ocorre. Uma emergência nunca é um evento planejado; pode acontecer a
qualquer momento e todos os membros da CERT devem aceitar a responsabilidade de responder a
uma emergência a qualquer hora.
As equipes típicas de uma CERT incluem adminsitradores de sistemas e de rede, assim como peritos
em segurança da informação. Os administradores de sistema provêm o conhecimento e habilidades
dos recursos do sistema, inclusive backups de dados, backup de hardware disponível para uso e outros.
Administradores de rede provêm seu conhecimento de protocolos de rede e a habilidade em 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 post-mortem (após o ataque).
Nem sempre é possível, mas deve haver redundância no pessoal de uma CERT. Se não for viável
ter uma área especializada na empresa, então deve haver treinamento para outras áreas sempre que
possível. Lembre-se que se somente uma pessoa tiver as informações cruciais para a segurança e
integridade dos dados, então a organização inteira ficará desamparada na ausência desta pessoa.
10.2.2. Considerações Legais
Alguns aspectos importantes da resposta ao incidente a considerar incluem as questões legais. Planos
de segurança devem ser desenvolvidos juntamente aos membros da área jurídica ou algum tipo de
conselho geral. Assim como toda empresa deve ter sua própria política de segurança corporativa, toda
empresa tem sua própria maneira de lidar com incidentes sob a perspectiva legal. Questões regulatórias
em nível local, estadual e federal vão além do escopo deste documento, mas são mencionadas pois
a metodologia de análise post-mortem será ditada, pelo menos em parte (ou em conjunto com), pelo
conselho jurídico. O conselho geral pode alertar o pessoal técnico das ramificações legais das infrações
93
de segurança, os perigos de registros pessoais, médicos ou financeiros de um cliente vazarem, e a
importância de restaurar os serviços em ambiente críticos como hospitais e bancos.
10.3. Implementando o Plano de Resposta ao Incidente
Após um plano de ação ser criado, ele deve ser consentido e implementado ativamente. Qualquer aspecto do plano que seja questionado durante a implementação ativa pode resultar numa resposta lenta
e num período fora do ar no evento de uma infração. Nestas circunstâncias os exercícios práticos são
muito valiosos. A menos que algo venha à tona antes do plano ser ativamente definido na produção,
a implementação deve ser consentida por todas as partes diretamente relacionadas e executada com
confiança.
Se uma infração for detectada enquanto a CERT estiver presente para rápida reação, as possíveis 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
8
6
file-name
7
9
Substitua file-name pelo nome do arquivo de registros do script. Sempre salve o arquivo de
registros em outra mídia que não o disco rígido do sistema comprometido — um disquete ou CD-ROM
são boas opções para este propósito.
Ao registrar todas as suas ações, cria-se um rastro de auditoria que pode ser valioso se o atacante for
pego.
94
10.4.1. Coletando uma Imagem Evidencial
Criar um pequeno ’arquivo-espelho’ da mídia é um primeiro passo razoável. Se estiver executando
trabalho forênsico de dados, é um requerimento. É recomendado fazer duas cópias: uma para análise
e investigação, e uma segunda para ser armazenada junto à original como evidência para quaisquer
procedimentos legais.
Você pode usar o comando dd, que é parte do pacote fileutils do Red Hat Enterprise Linux, para
criar uma imagem monolítica de um sistema que sofreu exploit como evidência de uma investigação,
ou para comparação com imagens confiáveis. Suponha que haja um único disco rígido no sistema no
qual você deseja criar a imagem. Conecte este disco como escravo ao sistema e então use o comando
dd para criar o arquivo imagem, conforme mostramos a seguir:
dd if=/dev/hdd bs=1k conv=noerror,sync of=/home/evidence/image1
Este comando cria um único arquivo chamado image1 usando o tamanho de um bloco de 1k para
velocidade. As opções conv=noerror,sync forçam o dd a continuar lendo e descarregando os dados
mesmo se encontrar setores danificados no disco suspeito. Agora é possível estudar o arquivo imagem
resultante ou até tentar recuperar arquivos apagados.
10.4.2. Coletando Informação Pós-Infração
O tópico forênsica e análise digital é bastante abrangente, mas as ferramentas são específicas para a 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.
A Tabela 10-1 descreve alguns comandos para auditoria e gerenciamento de arquivos. Também lista
alguns exemplos que podem ser usados para identificar apropriadamente arquivos e seus atributos
(tais como permissões e datas de acesso) para que assim você possa coletar mais evidências ou ítens
para análise. Estas ferramentas, quando combinadas com sistemas de detecção de intrusão, firewalls,
serviços seguros e outras medidas de segurança, podem ajudar a reduzir os danos potenciais na 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
Exemplo
grep
Encontra trechos de informação
(texto) úteis dentro de arquivos e
diretórios, assim como revela
permissões, alterações de script,
atributos de arquivos e muito mais.
Utilizado principalmente como um
comando ’casado’ (piped) com
outro, como o ls, ps ou o
ifconfig.
ps auxw |grep /bin
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.
strings /bin/ps |grep
’mail’
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.
find -atime +12 -name *log*
-perm u+rw
stat
Exibe informações sobre o status de
um arquivo, inclusive a hora do
último acesso, permissões,
configurações UID e GID e outras.
Útil para verificar quando um
sistema que sofreu infração foi
utilizado ou modificado pela última
vez.
stat /bin/netstat
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 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
97
o sistema de trojans, buracos na segurança e dados corrompidos. A maioria dos rootkits (programas
ou pacotes usados por um cracker para obter acesso root em seu sistema), comandos de sistema trojan
e ambientes de janela de comandos são desenvolvidos para ocultar atividades maléficas de auditorias
superficiais. Se você optar pelo conserto, use somente binários confiáveis (ex.: a partir de um 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 e Ataques Comuns....................................................................................................... 107
C. Portas Comuns ........................................................................................................................... 111
Apêndice A.
Proteção ao Hardware e à Rede
A melhor prática antes de empregar uma máquina em um ambiente de produção ou conectar sua rede
à Internet é determinar as necessidades de sua empresa, e como a segurança pode atender a estes 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.
•
A computação envolve mais do que somente estações de trabalho rodando software. Empresas
modernas requerem um grande poder computacional e serviços de alta disponibilidade, que 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 no ou roubo do equipamento.
•
Conectividade é o método através do qual o administrador pretende conectar recursos díspares a
uma rede. Um administrador pode usar a Ethernet (cabeamento CAT-5/RJ-45 de hub ou de 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 à qual a rede serve, há diversas opções disponíveis para a
implementação da rede. Cada topologia tem suas vantagens e questões de segurança que arquitetos de
rede devem considerar ao desenhar o layout de suas redes.
A.1.1. Topologias Físicas
Conforme definido pelo Institute of Electrical and Electronics Engineers (IEEE), há três topologias
comuns para a conexão física de uma LAN.
A.1.1.1. Topologia Ring
A topologia Ring conecta cada nódulo usando exatamente duas conexões. Isto cria uma estrutura ring
na qual cada nódulo é acessível ao outro, diretamente por seus nódulos vizinhos fisicamente mais
próximos ou indiretamente através do ring físico. Redes Token Ring, FDDI e SONET são conectadas desta maneira (com o FDDI usando uma técnica de ring duplo). No entanto, não há conexões
102
Apêndice A. Proteção ao Hardware e à Rede
Ethernet comuns usando esta topologia física, então os rings não são comumente empregados, exceto em configurações legadas ou institucionais com uma grande base de nódulos instalados (em uma
universidade, por exemplo).
A.1.1.2. Topologia de Canal Linear (Linear Bus)
A topologia de canal linear consiste de nódulos conectados a um cabo linear principal terminado (o
backbone). A topologia de canal linear requer um mínimo de cabeamento e equipamento de rede, o
que a torna a topologia de custo mais baixo. No entanto, o canal linear depende do backbone estar
constantemente disponível, tornando-o um ponto único de falha, caso seja necessário colocá-lo offline
ou esteja separado. Topologias de canal linear são comumente usadas em LANs par-a-par (peer-topeer) usando cabeamento coaxial e terminadores de 50-93 ohm nas duas extremidades do canal.
A.1.1.3. Topologia Estrela
A topologia Estrela (Star) incorpora um ponto central onde os nódulos se conectam e através do qual
a comunicação é passada. Este ponto central, chamado de hub pode ser transmitido ou comutado. Esta
topologia introduz um ponto único de falha no hardware de rede centralizado que conecta os nódulos.
Entretanto, devido essa centralização, as questões de rede que afetam segmentos ou a LAN inteira são
facilmente rastreáveis para esta fonte única.
A.1.2. Considerações de Transmissão
A Seção A.1.1.3 introduziu o conceito de rede transmitida e comutada. Há diversos fatores a considerar ao avaliar o tipo de hardware adequado e seguro o suficiente para seu ambiente de rede. Veja a
seguir a distinção entre estas duas formas de rede.
Em uma rede de transmissão, um nódulo enviará um pacote que é recebido por todos os outros nódulos
até que o receptor pretendido aceite o pacote. Cada nódulo da rede pode concebivelmente receber este
pacote de dados até que o receptor processe o pacote. Em uma rede de transmissão, todos os pacotes
são enviados desta maneira.
Em uma rede comutada (switched network), os pacotes não são transmitidos, mas processados no hub
comutado que, por sua vez, cria uma conexão direta entre os nódulos emissor e receptor. Isto elimina
a necessidade de transmitir pacotes a cada nódulo, assim diminuindo o tráfego operante.
A rede comutada também evita que os pacotes sejam interceptados por usuários ou nódulos maléficos.
Em uma rede de transmissão, onde cada nódulo recebe o pacote no caminho de seu destino, usuários
maléficos podem configurar seu dispositivo Ethernet para o modo promíscuo e aceitar todos os pacotes
independentemente dos dados serem destinados a eles ou não. Uma vez definida no modo promíscuo,
uma aplicação sniffer pode ser usada para filtrar, analisar e reconstruir pacotes para senhas, dados 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, D-Link, SMC e Netgear,
oferecem vários tipos de comutadores com características como a compatibilidade 10/100-Base-T,
suporte a Ethernet gigabit e networking IPv6.
103
A.1.3. Redes Sem-fio
Uma questão emergente para as empresas é a mobilidade. Funcionários remotos, técnicos de campo
e executivos requerem soluções portáteis, como laptops, organizadores pessoais digitais (PDAs) e
acesso sem-fio a recursos de rede. O IEEE estabeleceu normas para a especificação sem-fio 802.11,
que dita padrões para a comunicação de dados sem-fio para todos os setores. O padrão corrente
aprovado pelo IEEE é a especificação 802.11g para redes sem-fio, enquanto 802.11a e 802.11b são
padrões legados. O padrão 802.11g é compatível com o 802.11b, mas não com o 802.11a.
As especificações 802.11b e 802.11g são, na verdade, um grupo de padrões que governam as 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 baseada na Ethernet. O WAP age efetivamente como uma ponte entre os nódulos conectados
a ele e o resto da rede.
A.1.3.1. Segurança da 802.11x
Apesar da rede sem-fio ser comparável em velocidade e certamente mais conveniente que os meios de
redes com fios, há algumas limitações na especificação que autoriza consideração completa. A mais
importante destas limitações está na sua implementação de segurança.
Com a ansiedade de implantar uma rede 802.11x com sucesso, muitos administradores deixam de
tomar as precauções de segurança mais básicas. Desde que toda a rede 802.11x esteja feita usando
sinais RF de banda alta, os dados transmitidos são facilmente acessíveis a qualquer usuário com um
NIC compatível, uma ferramenta de scanning da rede sem-fio (como o NetStumbler ou o 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
WAP e o nódulo. Esta chave criptografa as transmissões e descriptografa pacotes de entrada dinâmica
e transparentemente. Os administradores frequentemente deixam de implementar este esquema de
criptografia de chave compartilhada por esquecimento ou porque escolheram não fazê-lo devido à
degradação do desempenho (especialmente através de distâncias longas). No entanto, ativar o WEP
em uma rede sem-fio pode reduzir drasticamente a possibilidade de intercepção de dados.
O Red Hat Enterprise Linux suporta vários produtos 802.11x de diversos fabricantes. A Ferramenta
de Administração de Rede inclui uma funcionalidade para configurar a segurança de NICs e WEP
sem-fio. Para informações sobre o uso da Ferramenta de Administração de Rede, consulte o Guia
de Administração de Sistemas Red Hat Enterprise Linux.
Confiar no WEP, entretanto, ainda não é o suficiente em termos de proteção contra determinados
usuários maléficos. Há utilitários especializados desenvolvidos especificamente para craquear o 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
104
sobre a criptografia WEP. Ao usar esta norma, um usuário maléfico externo à rede que craquear a
criptografia WEP, também terá que craquear a criptografia VPN ou SSH. Dependendo do método,
pode-se empregar até criptografia de algoritmo DES de 168 bits de força tripla (3DES), ou algoritmos
proprietários com força ainda maior. Os administradores que aplicarem estas normas devem restringir
protocolos somente-texto (como Telnet ou FTP), já que senhas e dados podem ser expostos usando
quaisquer dos ataques mencionados anteriormente.
Um método recente de segurança e autenticação, adotado por fabricantes de equipamento de rede,
é o Wi-fi Protected Acces (Acesso Sem-fio Protegido - WPA). Os administradores podem configurar
o WPA em sua rede usando um servidor de autenticação que administra as chaves de clientes que
acessam a rede sem-fio. O WPA é melhor que a criptografia WEP pois usa o Temporal Key Integrity
Protocol (Protocolo de Integridade da Chave Temporal - TKIP), um método de usar uma chave compartilhada e associá-la ao endereço MAC da placa da rede sem-fio instalada no sistema cliente. Os
valores da chave compartilhada e do endereço MAC então são processados por um vetor de inicialização (IV), que é usado para gerar uma chave que criptografa cada pacote de dados. O IV altera a
chave cada vez que um pacote é transferido, prevenindo os ataques mais comuns às redes sem-fio.
No entanto, o WPA usando o TKIP é tido como uma solução temporária. Soluções usando cifras
de criptografia mais fortes (como AES) estão sob desenvolvimento e têm o potencial de aumentar a
segurança da rede sem-fio no âmbito corporativo.
Para mais informações sobre os padrões 802.11, consulte a seguinte URL:
http://standards.ieee.org/getieee802/802.11.html
A.1.4. Segmentação de Rede e DMZs
Para administradores que queiram rodar serviços acessíveis externamente (como HTTP, e-mail, FTP
e DNS) é recomendado que estes serviços sejam física e/ou logicamente separados da rede interna.
Firewalls e a proteção de máqunas e aplicações são maneiras efetivas de detectar intrusões casuais.
Entretanto, alguns crackers podem encontrar vias à rede interna se os serviços que craquearam residem
no mesmo segmento da rede. Os serviços acessíveis externamente devem residir no que a indústria
da segurança chama de zona desmilitarizada (DMZ), um segmento da rede lógica onde o tráfego de
entrada da Internet pode acessar somente àqueles serviços e não pode acessar a rede interna. Isto é
efetivo, pois mesmo que um usuário maléfico faça um exploit na DMZ de uma máquina, o resto da
rede interna fica atrás de um firewall num segmento separado.
A maioria das empresas tem um conjunto limitado de endereços IP publicamente roteáveis, a partir
dos quais pode hospedar serviços externos. Desta forma, os administradores utilizam regras de 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. Os administradores podem usar estas normas para segmentar o tráfego
de entrada para serviços específicos em endereços e portas específicos, enquanto permitir que somente
a LAN acesse os serviços internos, o que pode evitar exploits de spoofing de IP. Para mais informações
sobre a implementação do iptables, consulte o Capítulo 7.
A.2. Segurança de Hardware
De acordo com um estudo lançado em 2000 pelo FBI e o Computer Security Institute (CSI), mais de
setenta por cento de todos os ataques a dados e recursos delicados reportados por empresas ocorreram
dentro da própria empresa. Implementar normas de segurança interna é tão importante quanto uma
estratégia externa. Esta seção explica algumas das medidas comuns que administradores e usuários
podem tomar para proteger seus sistemas de exploits internos.
105
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 usam um BIOS que controla os recursos do sistema
no nível do hardware. Usuários de estações de trabalho podem determinar senhas administrativas
no BIOS para impedir que usuários maléficos acessem ou inicializem o sistema. Senhas do BIOS
impedem que usuários maléficos inicializem o sistema de todas as maneiras, detendo o usuário de
acessar rapidamente ou roubar as informações armazenadas no disco rígido.
Mas, se o usuário maléfico roubar o PC (o caso mais comum de roubo entre viajantes que carregam
laptops e outros dispositivos portáteis) e levá-lo a um lugar onde ele pode desmontar o computador,
a senha do BIOS não evita que o atacante remova o disco rígido. Assim, pode instalá-lo em outro PC
sem restrições de BIOS e acessar o disco rígido para ler seu conteúdo. Nestes casos, é recomendado
que estações de trabalho tenham bloqueios para restringir o acesso ao hardware interno. Dispositivos
especiais de segurança, como cabos de aço com cadeados, podem ser ligados ao chassis do PC e do
laptop para evitar roubo, assim como bloqueios de chave no próprio chassis para evitar acesso interno.
Este tipo de hardware é amplamente disponibilizado por fabricantes como Kensington e Targus.
O hardware de servidor, especialmente servidores de produção, é geralmente montado em racks em
salas de servidores. Armários de servidor comumente possuem portas com trancas; e chassis individuais de servidores também estão disponíveis com trancas na frente para aumentar a segurança contra
o desligamento errôneo (ou intencional).
As empresas também podem usar provedores de co-locação para guardar seus servidores, já ques estes
oferecem banda mais alta, suporte técnico 24h 7 dias por semana e conhecimento em segurança de
sistemas e servidores. Este pode ser um meio efetivo de terceirizar as necessidades de segurança e
conectividade para transações HTTP ou serviços de streaming media. No entanto, a co-locação pode
ter um alto custo, especialmente para pequenas e médias empresas. As estruturas de co-locação são
conhecidas por ser altamente protegidas por seguranças treinados e monitoradas o ininterruptamente.
106
Apêndice B.
Exploits e Ataques Comuns
A Tabela B-1 detalha alguns dos exploits e pontos de entrada mais comuns usados por intrusos para
acessar recursos de rede de organizações. As explicações de como estes exploits são executados e
como administradores podem proteger sua rede apropriadamente são muito importantes contra tais
ataques.
Exploit
Descrição
Notas
Senha em branco
ou default
Deixar senhas administrativas em
branco ou usar a senha default provida
pelo fabricante. Isto é mais comum em
hardware, como roteadores e firewalls,
porém alguns dos serviços que rodam
no Linux podem conter senhas default
de administrador (apesar do Red Hat
Enterprise Linux não distribuí-las).
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
algumas contas de usuários
privilegiados com pressa e deixam a
senha vazia, um ponto de entrada
perfeito para usuários maldosos que
descobrem a conta.
Chaves
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 e Ataques Comuns
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 um programa backdoor ou
trojan horse 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 a executá-lo.
Depende de almejar sistemas que
estejam rodando serviços (tais como
rsh, telnet, FTP e outros) que
utilizam técnicas de autenticação
baseadas na fonte, não recomendadas
quando comparadas à PKI ou outras
formas de autenticação criptografada
usadas no ssh ou SSL/TLS.
Eavesdropping
(espionagem do
tráfego de rede)
Coleta de 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
funciona com protocolos de
transmissão somente-texto, como
transferências Telnet, FTP e HTTP.
O atacante remoto deve ter accesso a
um sistema comprometido em uma
LAN para poder executar um ataque
deste tipo. Geralmente o cracker usa
um ataque ativo (como um spoofing
de IP ou ’man-in-the-middle’) para
comprometer um sistema na LAN
Medidas preventivas incluem serviços
com troca de chave criptográfica,
senhas descartáveis ou autenticação
criptografada para impedir snooping
de senha. Também recomenda-se a
alta criptografia durante as
transmissões
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",
as informações como arquivos de
configuração e mapas de rede podem
ser lidas, ou o atacante pode iniciar
um ataque ’denial of service’ que
drena os recursos do sistema ou
torna-os indisponíveis a outros
usuários.
Às vezes, os serviços podem ter
vulnerabilidades que passam
desapercebidas durante o
desenvolvimento e testes. Estas
vulnerabilidades (tais como
sobrecarregamentos do buffer, nos
quais o atacante derruba um serviço
usando valores arbitrários que
preenchem o buffer da memória de
uma aplicação, oferecendo ao
atacante uma janela de comandos
interativa, a partir da qual ele pode
executar qualquer comando) podem
oferecer controle administrativo
completo a um atacante.
Administradores devem certificar-se
que os serviços não sejam executados
com o usuário root e estar atentos a
atualizações de erratas e consertos
para suas aplicações, de fabricantes ou
empresas de segurança como CERT e
CVE.
110
Exploit
Descrição
Notas
Vulnerabilidades
da Aplicação
Atacantes encontram falhas em
aplicações de computadores pessoais
e estações de trabalho (como clientes
de e-mail) e executam código
arbitrário, implantando trojans para
comprometer ou danificar os sistemas
futuramente. Exploits podem ocorrer
no futuro se a estação de trabalho
comprometida tiver privilégios
administrativos sobre 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 um
ambiente 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.
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.
Tabela B-1. Exploits Comuns
Apêndice C.
Portas Comuns
As tabelas a seguir listam as portas de comunicação mais comuns usadas pelos serviços, daemons
e programas inclusos no Red Hat Enterprise Linux. Esta lista também pode ser encontrada no 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.
A Tabela C-1 lista as Portas Conhecidas (Well Known Ports) conforme definidas pela IANA e são
usadas pelo Red Hat Enterprise Linux como as portas de comunicação default para vários serviços,
incluindo FTP, SSH e Samba.
Número da
Nome
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
112
Apêndice C. Portas Comuns
Número da
Nome
Porta / Camada
Comentário
25
smtp
Protocolo de Transferência de Correspondência Simples
(SMTP- Simple Mail Transfer Protocol)
37
time
Protocolo de Hora
39
rlp
Protocolo de Localidade de Recursos
42
nameserver
Serviço de Nomes da Internet
43
nicname
Serviço do diretório WHOIS
49
tacacs
Sistema de Controle de Acesso do Controlador de 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/tcp
iso-tsap
Aplicações de rede do Ambiente de Desenvolvimento ISO
(ISODE)
105
csnet-ns
Servidor de nomes da caixa de correspondência; também
usado pelo servidor de nomes CSO
107
rtelnet
Telnet remoto
109
pop2
Versão 2 do Protocolo do Post Office
Número da
Nome
Porta / Camada
113
Comentário
110
pop3
Versão 3 do Protocolo do Post Office
111
sunrpc
Protocolo da Chamada de Procedimento Remoto (RPC)
para execução de comandos remotos, usado pelo Sistema
de Arquivo de Rede (NFS)
113
auth
Protocolos de autenticação e identificação
115
sftp
Serviços do Protocolo de Transferência de Arquivos
Seguros (SFTP)
117
uucp-path
Serviços da Localidade do Protocolo de Cópia
Unix-para-Unix (UUCP - Unix-to-Unix Copy Protocol)
119
nntp
Protocolo de Transferência de Notícias de Rede (Network
News Transfer Protocol, NNTP) para o sistema de
discussão USENET
123
ntp
Protocolo de Hora da Rede (NTP - Network Time
Protocol)
137
netbios-ns
Serviço de Nome do NETBIOS usado no Red Hat
Enterprise Linux pelo Samba
138
netbios-dgm
Serviço de Datagrama do NETBIOS usado no Red Hat
139
netbios-ssn
Serviço 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 Administração de Rede Simples (SNMP Simple Network Management Protocol)
162
snmptrap
Armadilhas SNMP
163
cmip-man
Protocolo de Informações de Administração Comum
(CMIP - Common Management Information Protocol)
164
cmip-agent
Protocolo de Informações de Administração Comum
(CMIP - Common Management Information Protocol)
174
mailq
fila de transporte de e-mail MAILQ
177
xdmcp
Protocolo de Controle da Administração de Exibição do X
(XDMCP)
178
nextstep
Servidor de janelas do NeXTStep
179
bgp
Protocolo da Porta de Comunicação da Divisa (Border
Gateway Protocol)
191
prospero
Serviços de sistema de arquivo distribuídos Prospero
194
irc
Internet Relay Chat (IRC)
199
smux
Multiplexador UNIX para SNMP
201
at-rtmp
Roteamento do AppleTalk
114
Número da
Nome
Porta / Camada
Comentário
202
at-nbp
Ligação de nomes do AppleTalk
204
at-echo
Eco do AppleTalk
206
at-zis
Informações da zona do AppleTalk
209
qmtp
Protocolo de Transferência de Correspondência Rápida
(QMTP - Quick Mail Transfer Protocol)
210
z39.50
Banco de dados NISO Z39.50
213
ipx
Troca de Pacotes entre Redes (Internetwork Packet
Exchange, IPX), um protocolo de datagrama geralmente
usado em ambientes Netware do Novell
220
imap3
Protocolo de Acesso a Mensagens via Internet versão 3
245
link
LINK / Serviço iQuery 3-DNS
347
fatserv
Servidor de administração de fita e arquivos FATMEN
363
rsvp_tunnel
Túnel RSVP
369
rpc2portmap
Portmapper do sistema de arquivo Coda
370
codaauth2
Serviços de autenticação do sistema de arquivo Coda
372
ulistproc
UNIX LISTSERV
389
ldap
Protocolo de Acesso ao Diretório Lightweight (LDAP Lightweight Directory Access Protocol)
427
svrloc
Protocolo de Localização do Serviço (SLP - Service
Location Protocol)
434
mobileip-agent
Agente do Protocolo de Internet (IP)
435
mobilip-mn
Administrador do Protocolo de Internet (IP) Móvel
443
https
Protocolo de Transferência de Hypertexto Seguro (HTTPS
- Secure Hypertext Transfer Protocol)
444
snpp
Protocolo de Paging de Rede Simples
445
microsoft-ds
Server Message Block (SMB) sobre TCP/IP
464
kpasswd
Serviços de alteração da senha e chave do Kerberos
468
photuris
Protocolo de administração da chave da sessão do Photuris
487
saft
Protocolo de Transferência de Arquivos Assíncronos
Simples (SAFT - Simple Asynchronous File Transfer)
488
gss-http
Serviços de Segurança Genérica (Generic Security
Services, GSS) para o HTTP
496
pim-rp-disc
Rendezvous Point Discovery (RP-DISC) para os serviços
do Protocol Independent Multicast (PIM)
500
isakmp
Protocolo de Administração da Chave e da Associação da
Segurança de Internet (ISAKMP - Internet Security
Association and Key Management Protocol)
Número da
Nome
Porta / Camada
115
Comentário
535
iiop
Protocolo Internet Inter-Orb (IIOP)
538
gdomap
Mapeador de Objetos Distribuídos do GNUstep
(GDOMAP - GNUstep Distributed Objects Mapper)
546
dhcpv6-client
Protocolo de Configuração da Máquina Dinâmica (DHCP
- Dynamic Host Configuration Protocol) versão 6 cliente
547
dhcpv6-server
Protocolo de Configuração da Máquina Dinâmica (DHCP
- Dynamic Host Configuration Protocol) versão 5 Serviço
554
rtsp
Protocolo de Controle do Stream em Tempo Real (RTSP Real Time Stream Control Protocol)
563
nntps
Protocolo de Transporte de Notícias de Rede sobre a SSL
(NNTPS - Network News Transport Protocol over Secure
Sockets Layer)
565
whoami
lista whoami de IDs de usuários
587
submissão
Agente de Submissão da Mensagem de Correio (MSA Mail Message Submission Agent)
610
npmp-local
Protocolo de Administração dos Periféricos de Rede
(NPMP - Network Peripheral Management Protocol) local
/ Sistema de Ordenação Distribuída (DQS - Distributed
Queueing System)
611
npmp-gui
Protocolo de Administração dos Periféricos de Rede
(NPMP - Network Peripheral Management Protocol) GUI
/ Sistema de Ordenação Distribuída (DQS - Distributed
Queueing System)
612
hmmp-ind
Indicação do Protocolo de Administração do HyperMedia
(HMMP) / DQS
631
ipp
Protocolo de Impressão da Internet (IPP - Internet Printing
Protocol)
636
ldaps
Protocolo de Acesso ao Diretório Lightweight sobre a SSL
(LDAPS - Lightweight Directory Access Protocol over
Secure Sockets Layer)
674
acap
Protocolo de Acesso à Configuraço da Aplicação (ACAP Application Configuration Access Protocol)
694
ha-cluster
Serviços heartbeat para Clusters de Alta Disponibilidade
749
kerberos-adm
Administração do banco de dados kadmin do Kerberos
versão 5 (v5)
750
kerberos-iv
Serviços do Kerberos versão 4 (v4)
765
webster
Dicionário da Rede
767
phonebook
Catálogo de Telefones da Rede
873
rsync
serviços de transferência de arquivos rsync
992
telnets
Telnet sobre a Secure Sockets Layer (TelnetS)
116
Número da
Nome
Porta / Camada
Comentário
993
imaps
Protocolo de Acesso a Mensagens da Internet sobre a SSL
(IMAPS - Internet Message Access Protocol over Secure
Sockets Layer)
994
ircs
Internet Relay Chat sobre Secure Sockets Layer (IRCS)
995
pop3s
Protocolo do Post Office versão 3 sobre SSL (POP3S Post Office Protocol version 3 over Secure Sockets Layer)
Tabela C-1. Portas Bem Conhecidas
A Tabela C-2 lista as portas específicas do UNIX e abrange os serviços desde e-mail a autenticação,
dentre outros. Os nomes entre colchetes (ex.: [serviço]) são nomes de daemons do serviço ou
codenome(s) comuns.
Número da
Nome
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]
daemon whod de autenticação do usuário
514/tcp
shell [cmd]
shell remota (rshell) e cópia remota (rcp) sem autenticação
514/udp
syslog
Serviço de autenticação do sistema UNIX
515
printer [spooler]
spooler da impressora em linha (lpr)
517/udp
talk
Serviço e cliente de chamada remota talk
518/udp
ntalk
Cliente e Serviço do Network talk (ntalk) remote calling
519
utime [unixtime]
Protocolo de hora do UNIX (utime)
520/tcp
efs
Servidor de Nomes Extendidos de Arquivo (EFS Extended Filename Server)
520/udp
router [route,
routed]
Protocolo de Informações de Roteamento (RIP- 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
Número da
Nome
Porta / Camada
117
Comentário
532
netnews
Serviço de newsgroup Netnews
533/udp
netwall
Netwall para transmissões de emergência
540/tcp
uucp [uucpd]
Serviços de cópia UNIX-para-UNIX
543/tcp
klogin
Autenticação remota do Kerberos versão 5 (v5)
544/tcp
kshell
Shell remota do Kerberos versão 5 (v5)
548
afpovertcp
Protocolo de Arquivamento do Appletalk (AFP) sobre 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, a fim
de registrá-las formalmente:
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 dos comutadores de
rede Gracilis Packetena
1300
h323hostcallsc
H.323 telecommunication Host Call Secure
1433
ms-sql-s
Sefrvidor do Microsoft SQL
1434
ms-sql-m
Monitor do Microsoft SQL
1494
ica
Cliente Citrix ICA
1512
wins
Servidor de Nomes Internet do Microsoft Windows
1524
ingreslock
Serviços de bloqueio do Sistema de Administração do
Banco de Dados Ingres (DBMS - Database Management
System)
1525
prospero-np
Prospero não-privilegiado
1645
datametrics
[old-radius]
Datametrics / entrada do radius antigo
1646
sa-msg-port
[oldradacct]
sa-msg-port / entrada do radacct antigo
1649
kermit
Serviço de administração e transferência de arquivos
Kermit
1701
l2tp [l2f]
Protocolo de Tunneling da Camada 2 (LT2P - Layer 2
Tunneling Protocol) / Encaminhamento da Camada 2 (L2F
- layer 2 forwarding)
1718
h323gatedisc
H.323 telecommunication Gatekeeper Discovery
118
Número da
Nome
Porta / Camada
Comentário
1719
h323gatestat
H.323 telecommunication Gatekeeper Status
1720
h323hostcall
H.323 telecommunication Host Call setup
1758
tftp-mcast
Multi-transmissão do FTP Trivial
1759/udp
mtftp
FTP Trivial de Multi-transmissão (MTFTP)
1789
hello
Protocolo de comunicação do roteador hello
1812
radius
Serviços de autenticação e contabilidade da discagem do
radius
1813
radius-acct
Contabilidade do Radius
1911
mtp
Protocolo de Transporte Multimídia das Redes Starlight
(MTP)
1985
hsrp
Protocolo do Roteador Standby do Cisco Hot
1986
licensedaemon
Daemon da Administração de Licensa Cisco
1997
gdp-port
Protocolo da Descoberta da Porta de Comunicação Cisco
(GDP)
2049
nfs [nfsd]
Sistema de Arquivo de Rede (NFS)
2102
zephyr-srv
Servidor de mensagens distribuídas Zephyr
2103
zephyr-clt
cliente Zephyr
2104
zephyr-hm
Administrador da máquina Zephyr
2401
cvspserver
Concurrent Versions System (CVS) cliente/operações de
servidor
2430/tcp
venus
Administrador de cache Venus para o sistema de arquivo
Coda (porta codacon)
2430/udp
venus
Administrador de cache Venus para o sistema de arquivo
Coda (callback/interface wbc)
2431/tcp
venus-se
efeitos colaterais do Protocolo de Controle de Transmissão
(TCP) Venus
2431/udp
venus-se
Efeitos colaterais do Protocolo de Datagrama de Usuário
Vênus (Venus User Datagram Protocol, UDP)
2432/udp
codasrv
porta do servidor do sistema de arquivo Coda
2433/tcp
codasrv-se
efeitos colaterais do TCP do sistema de arquivo Coda
2433/udp
codasrv-se
efeitos colaterais do SFTP do UDP do sistema de arquivo
Coda
2600
hpstgmgr
[zebrasrv]
Roteamento do Zebrab
2601
discp-client
[zebra]
cliente discp; shell integrada do Zebra
2602
discp-server
[ripd]
servidor discp; daemon do Protocolo de Informações de
Roteamento (ripd)
119
Número da
Nome
Porta / Camada
Comentário
2603
servicemeter
[ripngd]
Medidor do Serviço; daemon do RIP para IPv6
2604
nsc-ccs [ospfd]
NSC CCS; daemon do Open Shortest Path First (ospfd)
2605
nsc-posa
NSC POSA; daemon do Protocolo da Porta de
Comunicação da Divisa (bgpd)
2606
netmon [ospf6d]
Dell Netmon; OSPF para o dameon do IPv6 (ospf6d)
2809
corbaloc
Common Object Request Broker Architecture (CORBA)
nomeando localizador de serviços
3130
icpv2
Protocolo do Cache da Internet versão 2 (v2); usado pelo
servidor de caching do proxy Squid
3306
mysql
Serviço de banco de dados MySQL
3346
trnsprntproxy
Proxy transparente
4011
pxe
serviço do Ambiente de Pré-execução (PXE Pre-execution Environment)
4321
rwhois
Serviço remoto Whois (rwhois)
4444
krb524
tradutor de ticket do Kerberos versão 5 (v5) para a versão
4 (v4)
5002
rfe
Sistema de transmissão de áudio Radio Free Ethernet
(RFE)
5308
cfengine
Mecanismo de Configuração (Cfengine - Configuration
Engine)
5999
cvsup [CVSup]
ferramenta de atualização e transferência de arquivos
CVSup
6000/tcp
x11 [X]
Serviços do Sistema X Window
7000
afs3-fileserver
Servidor de arquivos do Sistema de Arquivo Andrew (AFS
- Andrew File System)
7001
afs3-callback
porta AFS para callbacks do administrador do cache
7002
afs3-prserver
banco de dados dos grupos e usuários do AFS
7003
afs3-vlserver
banco de dados da localização de volumes do AFS
7004
afs3-kaserver
serviço de autenticação do Kerberos para o AFS
7005
afs3-volser
Servidor de administração dos volumes do AFS
7006
afs3-errors
Serviço de interpretação de erros do AFS
7007
afs3-bos
processo de supervisão básica do AFS
7008
afs3-update
atualizador servidor-para-servidor do AFS
7009
afs3-rmtsys
serviço de administração do cache remoto do AFS
9876
sd
Diretor de Sessão para conferências multi-transmissão de
IPs
120
Número da
Nome
Porta / Camada
Comentário
10080
amanda
serviços de backup do Arquivador de Disco de Rede
Automático Maryland Avançado (Amanda - Advanced
Maryland Automatic Network Disk Archiver)
11371
pgpkeyserver
Pretty Good Privacy (PGP) / servidor de chaves públicas
GNU Privacy Guard (GPG)
11720
h323callsigalt
H.323 Call Signal Alternate
13720
bprd
Daemon dos Pedidos de Backup de Rede Veritas (bprd NetBackup Request Daemon)
13721
bpdbm
Administrador do Banco de Dados de Backup de Rede
Veritas (bpdbm - NetBackup Database Manager)
13722
bpjava-msvc
Java do Backup de Rede Veritas / Protocolo do Microsoft
Visual C++ (MSVC)
13724
vnetd
Utilitário de rede Veritas
13782
bpcd
tBackupde Rede Veritas
13783
vopied
Daemon de autenticação de VOPIE Veritas
22273
wnn6 [wnn4]
Sistema de conversão Kana/Kanjic
26000
quake
servidores de jogos multi-jogadores do Quake (e
relacionados)
26208
wnn6-ds
Wnn6 Kana/Servidor Kanji
33434
traceroute
ferramenta de rastreamento da rede Traceroute
Notas:
a. Comentário do /etc/services: "A porta 1236 está registrada como ‘bvcontrol’, mas
também é usada pelo servidor de configuração remota Gracilis Packeten. O nome oficial está
listado como o nome principal, e o nome não-registrado como codenome."
b. Comentário do /etc/services: "As portas numeradas de 2600 a 2606 são usadas pelo
pacote zebra sem serem registradas. Os nomes primários são nomes registrados e os nomes
não-registrados usados pelo zebra estão listados como codenomes (aliases)."
c. Nota do /etc/services: "Esta porta é registrada como wnn6, mas também é usada sob o
nome não-registrado ’wnn4’ pelo pacote FreeWnn."
Tabela C-3. Portas Registradas
A Tabela C-4 lista as portas relacionadas ao Protocolo de Entrega do Datagrama (DDP) usadas em
redes AppleTalk.
Número da
Nome
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
121
Número da
Nome
Porta / Camada
Comentário
6/ddp
Protocolo de Informações da Zona
zip
Tabela C-4. Portas do Protocolo de Entrega do Datagrama
A Tabela C-5 é uma lista das portas relacionadas ao protocolo de autenticação de rede Kerberos.
Onde estiver indicado, v5 refere-se ao protocolo do Kerberos versão 5. Note que estas portas não são
registradas na IANA.
Número da
Nome
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)
Já a Tabela C-6 é uma lista de portas não-registradas que são usadas por serviços e protocolos que
podem ser/estar instalados no seu sistema Red Hat Enterprise Linux ou são necessários para a comunicação entre o Red Hat Enterprise Linux e 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)
465/tcp
smtps
Protocolo de Transferência de Correspondência Simples
sobre Secure Sockets Layer (SMTPS)
616/tcp
gii
Interface Interativa do Gated (daemon de roteamento)
808
omirr [omirrd]
Serviços de espelhamento de arquivo Online Mirror
(Omirr)
871/tcp
supfileserv
Servidor do Protocolo de Atualização de Software
(Software Upgrade Protocol, SUP)
901/tcp
swat
Ferramenta de Administração Web do Samba (SWAT Samba Web Administration Tool)
122
Número da
Nome
Porta / Camada
Comentário
953
rndc
Ferramenta de configuração remota Berkeley Internet
Name Domain versão 9 (BIND 9)
1127/tcp
supfiledbg
Depuração do Protocolo de Atualização de Software (SUP
- Software Upgrade Protocol)
1178/tcp
skkserv
Kana Simples para Kanji (SKK) servidor de input em
Japonês
1313/tcp
xtel
Sistema de informações de texto French Minitel
1529/tcp
suporte [prmsd,
gnatsd]
Sistema de rastreamento de erros GNATS
2003/tcp
cfinger
Finger do GNU
2150
ninstall
Serviço de Instalação de Rede
2988
afbackup
sistema de backup cliente-servidor afbackup
3128/tcp
squid
Cache de proxy Squid Web
3455
prsvp
porta RSVP
5432
postgres
Banco de dados PostgreSQL
4557/tcp
fax
Serviço de transmissão de FAX (serviço antigo)
4559/tcp
hylafax
Protocolo cliente-servidor HylaFAX (serviço novo)
5232
sgi-dgl
Biblioteca Gráfica Distribuída SGI
5354
noclog
Daemon de autenticação do centro de operações de 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
123
Número da
Nome
Porta / Camada
Comentário
10082/tcp
amandaidx
Servidor de índice Amanda
10083/tcp
amidxtape
Serviços de fita Amanda
20011
isdnlog
Sistema de autenticação da Rede Digital de Serviços
Integrados (ISDN - Integrated Systems Digital Network)
20012
vboxd
Daemon da caixa de voz da ISDN (vboxd - voice box
dameon)
22305/tcp
wnn4_Kr
Sistema de input Coreano kWnn
22289/tcp
wnn4_Cn
Sistema de input Chinês cWnn
22321/tcp
wnn4_Tw
Sistema de input Chinês tWnn (Taiwan)
24554
binkp
Daemon de correspondência Binkley TCP/IP Fidonet
27374
asp
Protocolo de Busca de Endereços
60177
tfido
Serviço de correspondência compatível ao FidoNet Ifmail
60179
fido
Rede de notícias e correspondência eletrônica FidoNet
Tabela C-6. Portas Não-registradas
124
Índice Remissivo
cupsd, 37
Símbolos
D
802.11x, 103
e segurança, 103
ética do hacker, 9
dd
A
atacantes e riscos, 9
ative sua assinatura, v
atualizações
(Ver erratas de segurança)
auditoria de arquivos
ferramentas, 94
B
BIOS
não-equivalentes ao x86
senhas, 24
segurança, 23
senhas, 23
auditoria de arquivos usando, 94
coletando evidências com, 94
Denial of Service - DoS (Negação de Serviço)
distribuídos, 4
DMZ
(Ver Zona Desmilitarizada (Demilitarized Zone))
(Ver networks)
E
equipe de resposta a emergências de computador, 92
erratas de segurança, 17
aplicando alterações, 20
através do site de erratas da Red Hat, 18
quando reinicializar, 20
via Red Hat Network, 17
exploits e ataques comuns, 107
tabela, 107
F
C
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, 103
transmissão de rede, 102
controles, 5
administrativos, 6
físicos, 6
técnicos, 6
convenções
documentos, ii
cracker
hacker de chapéu preto, 9
crackers
definição, 9
Ferramenta de Configuração dos Serviços, 37
ferramentas de comunicação
seguras, 40
GPG, 40
OpenSSH, 40
file
find
firewalls, 65
de estado, 72
e registro de conexão, 72
e vírus, 71
iptables, 66
normas, 67
pessoal, 39
recursos adicionais, 73
tipos, 65
FTP
acesso anônimo, 50
apresentando, 49
banner de saudação, 49
contas de usuário, 51
TCP wrappers e, 51
upload anônimo, 50
vsftpd, 49
126
G
inspeção de estado, 72
estados, 72
normas, 67
registro de conexão, 72
estados, 72
regras, 68
comum, 68
encaminhamento (forwarding), 69
NAT, 70, 71
restaurando, 68
salvando, 68
usando, 67
gestores de início
GRUB
senha protegendo, 24
segurança, 24
grep
H
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, 9
chapéu cinza, 9
chapéu preto
(Ver cracker)
definição, 9
hardware, 101
e segurança, 104
estações de trabalho, 104
laptops, 104
servidores, 104
I
idade da senha, 29
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, 72
IPsec, 56
configuração, 60
máquina-a-máquina, 57
fases, 56
instalando, 56
rede-a-rede, 60
iptables, 66
correntes, 67
FORWARD, 69
INPUT, 68
OUTPUT, 68
POSTROUTING (pós-roteamento), 70
PREROUTING (pré-roteamento), 70, 71
e DMZs, 71
e vírus, 71
K
Kerberos
NIS, 47
L
lpd, 37
lsof, 53
M
md5sum
módulos de autenticação plugáveis (pluggable authentication modules - PAM)
forçando uma senha forte, 28
N
NAT
(Ver Tradução do Endereço de Rede (Network Address Translation - NAT))
Nessus, 80
Netfilter, 66
Netfilter 6, 72
netstat, 53
NFS, 47
e Sendmail, 52
erros de sintaxe, 47
planejamento de rede, 47
Nikto, 81
NIS
apresentando, 45
IPTables, 46
Kerberos, 47
nome de domínio do NIS, 45
planejando a rede, 45
portas estáticas, 46
127
securenets, 46
nmap, 53, 80
versão linha de comando, 80
O
OpenSSH, 40
scp, 40
sftp, 40
ssh, 40
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
P
plano de resposta ao incidente, 91
portas
comuns, 111
monitorando, 53
portas comuns
tabela, 111
portas de comunicação, 111
portmap, 37
e IPTables, 44
e TCP wrappers, 44
post-mortem, 93
Q
questões legais, 92
R
redes, 101
comutadores, 102
e segurança, 101
hubs, 102
segmentação, 104
sem-fio, 103
zonas desmilitarizadas (de-militarized zones DMZs), 104
Redes Privadas Virtuais (Virtual Private Networks),
55
IPsec, 56
configuração, 60
instalando, 56
Redes Wi-Fi
(Ver 802.11x)
registre sua assinatura, v
registro da assinatura, v
reportando o incidente, 97
resposta ao incidente
coletando evidências
usando o dd, 94
coletando informação pós-infração, 94
reportando o incidente, 97
restaurando e recuperando recursos, 96
restaurando e recuperando recursos, 96
consertando o sistema (patching), 96
reinstalando o sistema, 96
riscos
consertos e erratas, 11
estações de trabalho e PCs, 12, 12
aplicações, 12
portas abertas, 10
redes, 10
arquiteturas, 10
servidores, 10
administração desatenta, 11
serviços inseguros, 11
root, 31
desativar acesso, 31
limitar acesso, 34
com Administrador de Usuários, 34
e o su, 34
e o sudo, 35
métodos de desativação, 31
alterar a shell root, 33
com PAM, 33
impossibilitar autenticações SSH, 33
permitindo acesso, 31
RPM
e detecção de intrusão, 86
importando a chave GPG, 18
verificando pacotes assinados, 18, 19
128
S
segurança da estação de trabalho, 23
avaliando
BIOS, 23
comunicações, 23
controle administrativo, 23
firewalls pessoais, 23
gestores de início, 23
senhas, 23
BIOS, 23
gestores de início
senhas, 24
segurança da senha, 25
e PAM, 28
em uma empresa, 28
ferramentas de auditoria, 29
Crack, 29
John the Ripper, 29
Slurpie, 29
forçando, 28
idade, 29
metodologia, 28
senhas fortes, 26
segurança do servidor
FTP, 49
acesso anônimo, 50
banner de saudação, 49
contas de usuário, 51
TCP wrappers e, 51
upload anônimo, 50
vsftpd, 49
NFS, 47
erros de sintaxe, 47
planejamento de rede, 47
NIS, 45
IPTables, 46
Kerberos, 47
nome de domínio do NIS, 45
planejando a rede, 45
portas estáticas, 46
securenets, 46
portas
monitorando, 53
portmap, 44
Sendmail, 52
e NFS, 52
limitando DoS, 52
Servidor HTTP Apache, 48
diretivas, 48
segurança cgi, 49
TCP wrappers, 41
alertas de ataque, 42
banners, 41
registro, 42
visão geral da, 41
xinetd, 43
gerenciando recursos com, 43
prevenindo DoS (recusa de serviço) com, 43
SENSOR armadilha, 43
segurança sem-fio, 103
802.11x, 103
sendmail, 37
apresentando, 52
e NFS, 52
limitando DoS, 52
senhas
dentro de uma empresa, 28
Servidor HTTP Apache
apresentando, 48
diretivas, 48
segurança cgi, 49
serviços, 53
serviços de co-locação, 104
serviços de rede, 36
identificando e configurando, 37
riscos, 36
denial-of-service (negação de serviço), 36
sobrecarga do buffer, 36
vulnerabilidade do script, 36
sobrecarga do buffer
ExecShield, 37
serviços inseguros, 38
rsh, 38
Telnet, 38
vsftpd, 38
Shell EFI
segurança
senhas, 24
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, 86
definindo, 85
e arquivos de registro, 86
Gestor de Pacotes RPM (RPM), 86
tipos, 85
Tripwire, 86
Snort, 90
sshd, 37
stat
strings
su
e root, 34
sudo
e root, 35
129
T
X
TCP wrappers
alertas de ataque, 42
banners, 41
e FTP, 51
e portmap, 44
registro, 42
tipos de firewall, 65
filtro de pacotes, 65
proxy, 65
tradução do endereço da rede (network address
translation - NAT), 65
topologias de rede, 101
canal linear (linear bus), 101
estrela (star), 101
ring, 101
Tradução do Endereço de Rede (Network Address
Translation - NAT), 69
com iptables, 69
Tripwire, 86
xinetd, 37
gerenciando recursos com, 43
prevenindo DoS (recusa de serviço) com, 43
SENSOR armadilha, 43
U
usuário root
(Ver root)
V
visão geral, 1
visão geral de segurança, 1
conclusão, 7
controles
(Ver controles)
definindo segurança em computadores, 1
Denial of Service - DoS (Negação de Serviço), 4
evolução da segurança em computadores, 1
vírus, 4
VLAD the Scanner, 81
VPN, 55
vulnerabilidades
avaliando com Nessus, 80
avaliando com Nikto, 81
avaliando com Nmap, 80
avaliando com o VLAD the Scanner, 81
estimativa, 77
definindo, 78
estabelecendo uma metodologia, 79
testes, 78
vírus
trojans, 4
Z
Zona Desmilitarizada (Demilitarized Zone), 71
Considerações finais
Os manuais são escritos no formato DocBook SGML versão 4.1. Os formatos HTML e PDF são 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 é composta pelas seguintes pessoas:
Sandra A. Moore — Autora Principal/Mantenedora do Red Hat Enterprise Linux Guia de Instalação
para sistemas x86, Itanium™, AMD64 e Intel® Extended Memory 64 Technology (EM64T da Intel®);
Autora Principal/Mantenedora do Red Hat Enterprise Linux Guia de Instalação para Arquitetura
POWER da IBM®; Autora Principal/Mantenedora do Red Hat Enterprise Linux Guia de Instalação
para as Arquiteturas IBM® S/390® e IBM® eServer™ zSeries®
John Ha — Autor Principal/Mantenedor do Configurando e Administrando um Cluster do Red Hat
Cluster Suite; Co-autor/Co-mantenedor do Guia de Segurança do Red Hat Enterprise Linux; Mantenedor dos stylesheets e scripts DocBook personalizados
Edward C. Bailey — Autor Principal/Mantenedor do Introdução à Administração de Sistemas Red Hat
Enterprise Linux; Autor Principal/Mantenedor das Notas de Versão; Autor contribuinte do Guia de
Instalação para sistemas x86, Itanium™, AMD64 e Intel® Extended Memory 64 Technology (EM64T
da Intel®) do Red Hat Enterprise Linux
Karsten Wade — Autora Principal/Mantenedora do Red Hat SELinux Guia do Desenvolvimento de
Aplicações; Autora Principal/Mantenedora do Red Hat SELinux Guia das Normas de Escrita
Andrius Benokraitis — Autor Principal/Mantenedor do Guia de Referência do Red Hat Enterprise
Linux; Co-autor/Co-mantenedor do Guia de Segurança do Red Hat Enterprise Linux; Autor Contribuinte do Guia de Administração de Sistemas Red Hat Enterprise Linux
Paul Kennedy — Autor Principal/Mantenedor do Guia do Administrador do Red Hat GFS; Autor
Contribuinte do Configurando e Administrando um Cluster do Red Hat Cluster Suite
Mark Johnson — Autor Principal/Mantenedor do Guia de Administração e Configuração do Desktop
Red Hat Enterprise Linux
Melissa Goldin — Autora Principal/Mantenedora do Guia Passo a Passo do Red Hat Enterprise Linux
A Equipe de Internacionalização da Red Hat é composta pelas seguintes pessoas:
Amanpreet Singh Alam — traduções para Punjabi
Jean-Paul Aubry — traduções para o Francês
David Barzilay — traduções para o Português Brasileiro
Runa Bhattacharjee — traduções para Bengali
Chester Cheng — traduções para o Chinês Tradicional
Verena Fuehrer — traduções para o Alemão
Kiyoto Hashida — traduções para o Japonês
N. Jayaradha — traduções para Tamil
Michelle Jiyeen Kim — traduções para o Coreano
Yelitza Louze — traduções para o Espanhol
Noriko Mizumoto — traduções para o Japonês
Ankitkumar Rameshchandra Patel — traduções para Gujarati
Rajesh Ranjan — traduções para Hindi
132
Nadine Richter — traduções para o Alemão
Audrey Simons — traduções para o Francês
Francesco Valente — traduções para o Italiano
Sarah Wang — traduções para o Chinês Simplificado
Ben Hung-Pin Wu — traduções para o Chinês Tradicional

Red Hat Enterprise Linux 4 Guia de Segurança

Transcrição

Documentos relacionados

Assunto: : Aplicativos

Prática certificada

Adoção do Linux na atual crise financeira global

Red Hat Enterprise Linux 5 Deployment Guide

Fogo do Chão Tinto / Fogo do Chão Red

Bloco da ale gria Oficina de for ma ta ção Top

An ncio Desespero

Rafaelle Magella de Santiago - PMI-CE

Apresentação - PHLC Development Blog

7 - Fundamentos de T.I