UNIVERSIDADE LUTERANA DO BRASIL
CURSO DE CIÊNCIA DA COMPUTAÇÃO
CÂMPUS CANOAS
SISTEMA PARA GRUPOS DE
RESPOSTAS A INCIDENTES DE
SEGURANÇA EM
COMPUTADORES
Cristiano Reinaldo Itapoan da Costa
Monografia desenvolvida durante a disciplina de Trabalho
de Conclusão de Curso II e apresentada ao Curso de
Ciência da Computação da Universidade Luterana do
Brasil, câmpus Canoas, como pré-requisito para a
obtenção do título de Bacharel em Ciência da
Computação.
Orientador: Prof. Stanley Loh
Canoas, novembro de 2004.
2
Universidade Luterana do Brasil – ULBRA
Curso de Ciência da Computação – Câmpus Canoas
Reitor:
Pastor Ruben Eugen Becker
Vice-Reitor:
Eng. Leandro Eugênio Becker
Diretor da Faculdade de Informática:
Prof. Gilberto Fernandes Marchioro
Coordenador de Curso (Câmpus Canoas):
Prof. Gilberto Fernandes Marchioro
Coordenador das Disciplinas de Trabalho de Conclusão de Curso (Câmpus Canoas):
Prof. Denise Salvadori Virti
Banca Avaliadora composta por:
Prof. Stanley Loh (Orientador)
Prof. André Peres
Prof. Luis Fernando da Silva
Data da entrega:24/11/2004.
CIP – Catalogação na Publicação
Itapoan da Costa, Cristiano Reinaldo
Sistema de resposta a incidentes de segurança em computadores /
Cristiano Reinaldo Itapoan da Costa; [orientado por] Stanley Loh –
Canoas: 2004.
72 p.: il.
Trabalho de Conclusão de Curso (Graduação em Ciência da
Computação). Universidade Luterana do Brasil, 2004.
1. Computadores. 2. Incidentes. 3. Segurança. I. Loh, Stanley.
II. Sistema para grupos de resposta a incidentes de segurança em
computadores.
Endereço:
Universidade Luterana do Brasil – Câmpus Canoas
Av. Miguel Tostes, 101 – Bairro São Luís
CEP 92420-280 Canoas – RS – Brasil
3
“Se você conhece o inimigo e conhece a si mesmo, você
não precisa temer o resultado de uma centena de batalhas.”
Sun Tzu
4
Dedico este trabalho especialmente ao meu filho Lucas
que em muitos momentos, nos últimos cinco anos, me
serviu como fonte de inspiração e motivação para encarar
os desafios da vida.
5
AGRADECIMENTOS
Em especial, agradeço a Deus por ter me dado esta oportunidade e aos meus pais por
terem me apoiado durante todos estes anos de minha educação.
Agradeço aos amigos que me deram força nos momentos difíceis de minha vida, pois
são nestes momentos que se destacam as grandes amizades.
Agradeço aos meus professores, pelo conhecimento repassado a mim durante o curso,
pois o conhecimento é o único bem que não pode ser tirado de um homem a não ser que este
homem queira repassá-lo.
Agradeço também ao professor Stanley Loh por confiar e aceitar a orientação de meu
trabalho de conclusão de curso.
E por fim, agradeço aos professores André Peres e Luís Fernando da Silva, por
avaliarem meu trabalho.
SUMÁRIO
LISTA DE FIGURAS .......................................................................................................... 8
LISTA DE QUADROS ........................................................................................................ 9
LISTA DE ABREVIATURAS E SIGLAS ........................................................................ 10
RESUMO ........................................................................................................................... 11
ABSTRACT ....................................................................................................................... 12
1 INTRODUÇÃO ............................................................................................................. 13
2 INCIDENTES DE SEGURANÇA EM COMPUTADORES....................................... 16
3 REPOSTA A INCIDENTES DE SEGURANÇA EM COMPUTADORES ................ 19
3.1 POLÍTICA DE SEGURANÇA ........................................................................................ 19
3.2 POLÍTICA DE USO ACEITÁVEL ................................................................................... 19
3.3 USO ABUSIVO DA REDE ............................................................................................ 20
3.4 VULNERABILIDADES ............................................................................................... 20
3.5 FIREWALL ............................................................................................................... 21
3.6 SISTEMAS DE DETECÇÃO DE INTRUSÃO ..................................................................... 22
3.6.1 Sistema de detecção de intrusos de rede........................................................... 22
3.6.2 Sistema de detecção de intrusos de host........................................................... 22
3.6.3 Assinaturas...................................................................................................... 23
3.6.4 Alertas............................................................................................................. 23
3.6.5 Sensor ............................................................................................................. 23
3.7 SISTEMA DE MONITORAMENTO DE REDE ................................................................... 24
3.8 SISTEMA DE CONTROLE DE REQUISIÇOES PARA REPOSTA A INCIDENTES ..................... 24
3.9 REGISTROS DE ATIVIDADES OU EVENTOS .................................................................. 25
3.10 FALSOS POSITIVOS .................................................................................................. 26
3.11 NOTIFICAÇÕES DE INCIDENTES E ABUSOS ................................................................. 26
3.12 COMPLEXIDADES DE ATAQUES................................................................................. 28
3.13 COMPLEXIDADE DE PREVENÇÃO E RECUPERAÇÃO .................................................... 28
4 GRUPOS DE REPOSTA A INCIDENTES DE SEGURANÇA EM
COMPUTADORES....................................................................................................... 29
4.1 TAMANHO DE UM GRUPO DE RESPOSTA A INCIDENTES............................................... 29
4.2 MODELOS DE UTILIZAÇÃO PARA ORGANIZAÇÕES ...................................................... 30
4.3 RAZÕES PARA SE UTILIZAR UM GRUPO DE RESPOSTA A INCIDENTES .......................... 30
4.3.1 Habilidade para coordenar ............................................................................... 30
4.3.2 Especialização................................................................................................. 30
7
4.3.3
4.3.4
4.3.5
4.3.6
Eficiência ........................................................................................................ 31
Habilidade para trabalhar de forma pró-ativa ................................................... 31
Atingir os requisitos desejados pelas agências ou corporações ......................... 31
Servir como elo de ligação............................................................................... 31
5 DESCRIÇÃO DO SISTEMA........................................................................................ 32
5.1 IPTABLES ................................................................................................................ 32
5.2 SNORT .................................................................................................................... 32
5.3 NESSUS ................................................................................................................... 33
5.4 NAGIOS................................................................................................................... 33
5.5 RTIR...................................................................................................................... 33
5.6 INTEGRAÇÃO DAS FERRAMENTAS............................................................................. 34
5.6.1 Analise das vulnerabilidades............................................................................ 38
5.6.2 Analise dos registros de eventos do firewall..................................................... 38
5.6.3 Analise dos registros de eventos do IDS .......................................................... 38
5.6.4 Alertas do sistema de monitoramento .............................................................. 39
5.6.5 Registros dos casos no sistema de controle de requisições ............................... 39
5.6.6 Classificações dos tíquetes no sistema de requisições ...................................... 40
5.6.7 Utilização do sistema de requisições pelos membros do grupo de respostas a
incidentes ........................................................................................................ 40
6 TESTES ......................................................................................................................... 43
6.1 DESCRIÇÃO DO AMBIENTE DE TESTES ....................................................................... 43
6.1.1 Programas ....................................................................................................... 43
6.1.2 Equipamentos.................................................................................................. 44
6.1.3 Topologias ...................................................................................................... 45
6.2 CENÁRIOS ............................................................................................................... 46
6.2.1 Cenário 1 – Varredura externa de portas .......................................................... 46
6.2.2 Cenário 2 – Analise de um relatório de registros do Snort com atividades
suspeitas.......................................................................................................... 48
6.2.3 Cenário 3 – Incidentes reportados por usuários ................................................ 49
6.2.4 Cenário 4 – Notificação de parada de servidor ou serviço pelo Nagios............. 49
7 CONCLUSÃO ............................................................................................................... 52
ANEXO A – MODELO DE POLÍTICA DE SEGURANÇA ........................................... 54
ANEXO B – MODELO DE POLÍTICA DE USO ACEITÁVEL .................................... 59
ANEXO C – EXEMPLO DE RELATÓRIO DE VULNERABILIDADES ..................... 61
ANEXO D – EXEMPLO DE RELATÓRIO DE ANALISE DOS REGISTROS DO
FIREWALL.................................................................................................................... 64
ANEXO E – EXEMPLO DE RELATÓRIO DE ANALISE DOS REGISTROS DO
DETECTOR DE INTRUSOS ....................................................................................... 65
ANEXO F – MODELO DE FORMULÁRIO PARA RESPOSTA A INCIDENTES DE
SEGURANÇA EM COMPUTADORES ...................................................................... 69
REFERÊNCIAS................................................................................................................. 71
LISTA DE FIGURAS
Figura 3.1 – Exemplos de assinaturas de ataques utilizados na configuração do Snort .......... 23
Figura 5.1 – Troca de mensagens e processos realizados para a integração........................... 35
Figura 5.2 – Situação pró-ativa de utilização do sistema....................................................... 36
Figura 5.3 – Situação reativa de utilização do sistema .......................................................... 37
Figura 6.1 – Topologia de rede utilizada nos testes............................................................... 45
Figura 6.2 – Topologia sugerida para utilização em organizações comerciais ou grandes
corporações .................................................................................................................. 45
Figura 6.3 – Detalhes do tíquete criados na fila Blocks......................................................... 47
Figura 6.4 – Tíquetes de bloqueio e desbloqueio criados na fila Blocks ................................ 48
Figura 6.5 – Criação manual de um tíquete na fila Incidents................................................ 50
Figura 6.6 – Resolução do tíquete para o problema no serviço VNC ..................................... 51
LISTA DE QUADROS
Quadro 1 – Os adversários e seus objetivos conforme Tanembaum (2003)........................... 16
LISTA DE ABREVIATURAS E SIGLAS
CA
CERT/CC
CSIRT
CGI
DARPA
FBI
GRISC
Gb
HIDS
IDS
IP
IRC
Mb
MHz
MRI
MTA
NBSO
NIDS
SANS
SMB
SNMP
SGRIS
TCP
VNC
UDP
CERT Advisory
Computer Emergency Response Team / Coordinator Center
Computer Incident Reponse Team
Common Gateway Interface
Defense Advanced Research Projects Agency
Federal Bureal of Investigation
Grupo de Repostas a Incidentes de Segurança em Computadores
Gigabyte
Host Intrusion Detection System
Intrusion Detection System
Internet Protocol
Internet Relay Chat
Megabyte
Megahertz
Mecanismo de Resposta a Incidentes
Mail Transport Agent
NIC BR Security Office
Network Intrusion Detection System
SysAdmin, Audit, Network, Security
Short Message Protocol
Simple Network Management Protocol
Sistema para Grupo de Repostas a Incidentes de Segurança
Transport Control Protocol
Virtual Network Computing
User Datagrama Protocol
11
RESUMO
Com a complexidade das infra-estruturas de redes de computadores e o desafio da
administração destas redes interconectadas, fica difícil gerenciar corretamente a segurança
deste ambiente. Os administradores de redes e de sistemas não têm pessoais suficientes e
práticas de segurança para se defender de ataques e minimizar os danos. Com isto as
organizações reconhecem que é necessária uma estratégia de segurança formada por várias
camadas, uma das camadas que vem sendo incluída nas estratégias de segurança de diversas
organizações é a criação de um grupo de reposta a incidentes de segurança em computadores.
Quando os incidentes de segurança em computador ocorrem, as organizações devem
responder rapidamente e eficazmente. Quanto mais rapidamente uma organização reconhece,
analisa, e responde a um incidente, menor serão os custos do aprendizado e recuperação dos
danos. Estabelecer um grupo de resposta a incidentes de segurança em computadores (do
inglês Computer Security Reponse Team - CSIRT) é uma boa maneira de fornecer esta
potencialidade de resposta rápida, assim como ajuda a impedir os futuros incidentes. Este
trabalho tem como objetivo integrar um sistema de acompanhamento de requisições, com
ênfase em respostas a incidentes, às principais ferramentas de segurança para Linux existentes
atualmente nas áreas de varredura de vulnerabilidades, detecção de intrusos, filtro de pacotes
e monitoramento de servidores e serviços de rede.
Palavras-chaves: Computadores; Incidentes; Segurança.
ABSTRACT
Title: “System for Computer Security Incidents Response Teams”
With the complexity of infrastructures of computer networks and the challenge
of the administration of these interconnected nets, is getting difficult to correctly manage
the security of this environment. The administrators of nets and systems don’t have enough
staff and practical of security to defend itself of attacks to minimize the damages. With this the
organizations recognize the necessity to construct a strategy of security formed for
some layers, one of them has been included in the security strategies of many organizations,
that is the creation of a security response incidents group, for guard the computers. The faster
an organization recognizes, analyzes and response a incident, minor will be the
costs of learning an recovery the damages. When the incidents of security guard in computer
occur, the organizations must answer quickly and efficiently. To establish a group of
computer security incident response team (CSIRT) is a good way to supply this potentiality of
fast reply, as well as aid to hinder the futures incidents. This paper has the goal to integrate a
request tracker system, which emphasis in incidents reports, with the main Linux security
tools that currently exists in the areas of scanner vulnerability, intrusion detection, packet
filtering and network servers and services monitoring.
Key-words: Computers; Incidents; Security.
1 INTRODUÇÃO
Segundo Shinder (2002), atualmente vivemos e trabalhamos em um mundo conectado
globalmente, onde podem ser trocadas simples mensagens de texto ou transações
multimilionárias podem ser feitas entre pessoas de todo mundo de forma rápida e barata. O
aumento do número de computadores pessoais, a proliferação da Internet e um mercado de
comunicações que cada dia conecta mais e mais pessoas têm modificado a maneira de viver
das pessoas, a forma como elas gastam seu dinheiro e seu tempo de lazer.
Conseqüentemente a forma pela qual os criminosos cometem seus delitos também esta
mudando. O fácil acesso ao mundo digital possibilita novas oportunidades para estas pessoas.
Muito dinheiro é gasto para investigar os crimes cometidos por estas pessoas através dos
computadores. Na pior das hipóteses um computador pode ser utilizado para prejudicar
vítimas ou para violentos ataques, inclusive para gerenciar e executar atividades terroristas
que ameaçam a vida de milhares de pessoas. Infelizmente em muitos casos a justiça tem
ficado para trás destes criminosos, pois não possuem a tecnologia e o pessoal apropriado para
tratar estas recentes e crescentes ameaças, que podem ser denominadas de crime digital ou
cybercrime.
Atualmente a maioria dos profissionais de tecnologia da informação não tem interesse
e consciência no fenômeno do cybercrime. Muitas vezes os oficiais de justiça não têm o
equipamento apropriado para tratar estes crimes; as leis antigas não servem completamente
para estes crimes; as novas leis não têm compreendido toda esta nova realidade que esta
acontecendo, pois havia poucos precedentes para serem tomados como exemplo. Além disso,
polêmicas sobre a privacidade também têm atrasado os oficiais de justiça na capacidade de
juntar evidências necessárias para levar a juízo estes novos casos.
Existia uma certa quantia de antipatia – ou pelo menos, falta de confiança – entre os
dois mais importantes personagens em qualquer luta efetiva contra o cybercrime: oficiais de
justiça e profissionais da computação. Obviamente uma cooperação intensa entre os dois é
crucial para controlar o problema do cybercrime e fazer da Internet um lugar seguro para seus
usuários.
O pessoal da lei compreende a intenção criminosa e sabe o básico para estar reunindo
evidências e trazendo estes ofensores para a justiça. O pessoal de tecnologia da informação
compreende os computadores e redes, como eles funcionam e como capturar informações
neles. Cada um tem metade da chave para derrotar o crime digital.
A capacidade de responder a um incidente de segurança de computador esta se
tornando cada vez mais importante no mundo de hoje. A eficiência da reposta de uma
empresa a um incidente é que faz a diferença entre um ataque frustrado e a manchete nos
jornais. Mas o problema é que geralmente as empresas não têm conhecimento do fato até que
14
seja tarde demais. Então essa falta pode ser prevenida com um modelo pró-ativo de resposta a
incidentes. Fazer diretivas e procedimentos de resposta a incidentes de segurança previamente
podem evitar muitos problemas e também economizar tempo e dinheiro. (ANÔNIMO, 2001).
A necessidade do mundo real de resposta a incidentes de computador é anterior aos
computadores em mais de um século. No caso de um cofre, por exemplo, ele deve ser testado
para que as pessoas possam saber quanto tempo um criminoso pode levar para arrombar o
mesmo. Este tempo é importante para ter uma expectativa de quanto tempo uma empresa tem
para responder a um ataque levando em conta que este cofre esteja sendo monitorado por
câmeras, se alguém estiver observando as imagens obtidas pelas câmeras fica óbvio
identificar quando o cofre esta sendo atacado e o criminoso também sabe que tem um tempo
limite para completar sua tarefa. No meio digital esta situação é mais complexa, pois os
criminosos que fazem seus ataques pela rede têm tempo ilimitado para invadir um sistema,
uma vez que o sistema tenha sido invadido, no caso do cofre itens são removidos, mas nos
casos de crimes digitais os itens podem ser copiados, deixando os originais intactos, a menos
quando o motivo do crime é político e não financeiro.
Para que possam ser eficazes na reposta a incidentes de segurança, as empresas
necessitam combinar tecnologia com disciplina. No estado atual o cenário da segurança
avança rapidamente e não espera por ninguém. Sem dominar os princípios básicos e formar
um modelo de segurança preventivo, as empresas ficaram num eterno jogo de correr atrás dos
avanços desta área e sempre acabar perdendo a corrida.
Este trabalho apresenta um sistema que é uma integração de uma ferramenta de
controle de requisições para respostas a incidentes às principais ferramentas de segurança de
redes em Linux existentes atualmente. Este sistema recebe periodicamente a análise dos
registros e as notificações destas ferramentas, buscando prevenir ataques, reduzir o tempo de
conhecimento de um incidente, orientar e agilizar as ações que deverão ser tomadas, baseadas
nas ações registradas para cada incidente, por isto os primeiros incidentes que a ferramenta
reconhecer e que forem respondidos pelos membros poderão servir como referência para os
futuros incidentes.
O sistema de requisições estará integrado com uma ferramenta de varredura de
vulnerabilidades, que irá fazer a analise dos servidores indicados e gerar um relatório com as
vulnerabilidades encontradas. Este relatório será enviado ao sistema para que os membros do
grupo de respostas façam uma analise, as devidas correções, caso sejam necessárias, e o
registro destas ações dentro da requisição.
Na forma pró-ativa um sistema NIDS fará o reconhecimento dos ataques, podendo
bloqueá-los e notificar o sistema de requisições sobre este bloqueio, para que os membros do
grupo tenham fácil conhecimento destes bloqueios e possam tomar as devidas ações.
Na forma reativa um sistema de monitoramento de rede irá notificar o sistema de
requisições que um problema ocorreu em um host ou serviço, e uma requisição será criada no
sistema para que um membro do grupo possa tomar as ações necessárias com relação ao
problema.
Ainda na forma reativa poderão ser abertas requisições manualmente ou através do
envio de mensagem eletrônica pelos usuários do sistema para que incidentes de segurança,
que não podem ser identificados pelo sistema de monitoramento de rede e o sistema NIDS,
possam ser respondidos.
Também serão enviados periodicamente ao sistema de requisições, relatórios com
informações encontradas nos registros do sistema de detecção de intrusos e nos registros do
15
sistema de filtro de pacotes, para que os membros do grupo de resposta a incidentes tenham
informações mais detalhadas dos eventos que ocorrem periodicamente na rede, facilitando a
analise dos registros destas ferramentas para a criação de incidentes de segurança baseados
nestas analises.
Este sistema pode beneficiar as empresas em geral que estão interligadas a grande rede
mundial de computadores e possuem informações confidências ou prestam serviços de missão
crítica, pois poderá prevenir ou no mínimo reduzir o tempo de conhecimento de um incidente
e nos casos em que os incidentes forem respondidos, será armazenada uma base de
conhecimento com todo o histórico dos incidentes e as ações que foram tomadas o que pode
ajudar muito na agilização da resolução de futuros incidentes.
No capítulo 2 é descrito o conceito de incidentes de segurança em computadores, no
capítulo 3 é descrito o conceito para resposta a incidentes de segurança em computadores, no
capítulo 4 é descrito o que são os grupos de resposta a incidentes de segurança em
computadores, pra que eles servem e como podem atuar. No capítulo 5 são brevemente
apresentadas as principais ferramentas utilizadas e descrito como é feita a integração do
sistema de requisições de resposta a incidentes as ferramentas de varredura de
vulnerabilidades, detecção de intrusos, filtro de pacotes e monitoramento de servidores e
serviços de rede. Também neste capítulo é especificado como os membros do grupo devem
utilizar este sistema. No capítulo 6 são descritos os programas e os equipamentos utilizados
nos testes e alguns cenários utilizados para a realização destes. No capítulo 7 é apresentada a
conclusão obtida sobre o assunto abordado neste trabalho.
16
2 INCIDENTES DE SEGURANÇA EM COMPUTADORES
Segundo Tanembaum (2003), a maioria dos problemas de segurança são de fato
causados por pessoas mal intencionadas tentando se beneficiar, ganhar atenção, ou prejudicar
alguém. Um pouco dos criminosos mais comuns são mostrados no Quadro 1. Deve ficar claro
nesta lista que fazer a segurança de uma rede envolve muito mais do que apenas ficar livre
dos erros de programação. Isto envolve adversários que enganam de maneiras muito
inteligentes, que são muito dedicados, e bem financiados. Também deve ficar claro que as
medidas para obstruir adversários casuais podem ter um pequeno impacto para os adversários
realmente sérios. Registros da polícia mostram que a maioria dos ataques não é cometida por
criminosos de fora de uma organização através de uma linha telefônica, mas pelos internos
com inveja ou antipatia. Conseqüentemente, os sistemas de segurança devem ser desenhados
com estes fatos em mente.
Quadro 1 – Os adversários e seus objetivos conforme Tanembaum (2003)
Adversários
Objetivos
Estudante
Ler as mensagens de correio eletrônico das
outras pessoas.
Cracker
Testar a segurança de um sistema; roubar
informações.
Representante de vendas
Representar toda a Europa, não só Barcelona
Diretor de uma empresa
Descobrir o planejamento estratégico do
concorrente.
Ex-empregado
Se vingar por ter sido demitido.
Contador
Fraudar o dinheiro de uma empresa.
Corretor
Negar uma promessa feita a um cliente por
correio eletrônico.
Vigarista
Roubar números de cartões de crédito para
vender.
Espião
Aprender segredos militares de um inimigo ou
segredos industriais.
Terrorista
Infiltrar-se na fonte dos segredos de uma
guerra.
Segundo Schweitzer (2003), os incidentes podem ser entendidos por ameaças à
segurança em sistemas de computação e redes de computadores. Eventos incluem qualquer
fato considerável que acontece em um computador ou rede. Eventos são ações como conectar
17
a outros sistemas através de uma rede, acessar arquivos, o encerramento de um sistema
operacional, e outros. Eventos adversos são quebras no sistema, sobrecarga de pacotes dentro
de uma rede, uso não autorizado de outra conta de usuário, uso não autorizado de privilégios
do sistema, desfiguração de uma ou mais páginas da web, e execução de códigos maliciosos
que destroem dados. Outros eventos adversos incluem inundações de pacotes, interrupção
elétrica, e excessivo calor que causam problemas no sistema. Incidentes como desastres
naturais e interrupções relacionadas à força elétrica podem não ser considerados dependendo
do contexto.
Segundo Shultz e Shumway (2001), tradicionalmente, a segurança das informações e
de computadores tem seu esforço focado na confidencialidade (de informações que precisam
ser protegidas), integridade (de informações, sistemas e serviços), e disponibilidade (de
informações, aplicações, serviços, sistemas e redes). Muitos incidentes que ocorreram no
passado têm se adequado bem a este modelo. Considerando, por exemplo, as muitas tentativas
de invasão aos sistemas do Pentágono pela Argentina no final dos anos 90. Estes ataques
foram planejados para obter informações militares dos Estados Unidos ou, em outras palavras,
para comprometer a confidencialidade destas informações. Preocupações com relação à
integridade podem ser ocasionadas por incidentes em que o atacante tenha instalado
programas de controle remoto em sistemas Windows, por exemplo.
Segundo Shultz e Shumway (2001), em um incidente publicado em 2000, um laptop
de um funcionário da Microsoft foi comprometido desta maneira enquanto o laptop estava
fora das dependências da Microsoft; após o laptop estar conectado diretamente a rede interna,
então o criminoso utilizou isto para ganhar acesso aos recursos dentro da rede e enviar cópias
para sistemas fora de rede. Com isto a confidencialidade e a integridade foram
comprometidas. Finalmente, um bom exemplo da necessidade de disponibilidade é a série de
ataques distribuídos de negação de serviço contra companhias de comércio eletrônico em
2000 que parou muitas centenas de sistemas, causando imensas perdas financeiras para estas
companhias.
Uma crescente proporção de profissionais na arena da segurança da informação e
computadores estão adotando o conceito de confidencialidade, integridade e disponibilidade.
Adicionalmente, novos tipos de incidentes têm aparecido dentro dos últimos 10 anos; estes
incidentes são muitas vezes de uma natureza originalmente diferente das antigas, incidentes
mais “tradicionais”. Podemos considerar os seguintes tipos de incidentes: Ataques de
reconhecimento, renúncia, moléstia, extorsão, tráfico de material pornográfico, atividades de
crime organizado, subversão, trotes ou boatos.
Segundo Chuvakin e Peikari (2004), uma Reposta a Incidente é um processo de
identificação, contenção, erradicação e recuperação de um incidente de computador, realizado
pelo time de segurança responsável. Vale a pena lembrar que uma equipe de segurança pode
ser constituída de apenas uma pessoa, que pode responder a incidentes apenas parte do tempo.
Quem quer que seja que participe do tratamento de conseqüências de incidentes se transforma
em parte do time de resposta a incidente, mesmo que o time não exista como uma unidade
definida dentro da organização. Uma resposta de segurança é definida como uma resposta de
incidente compreendendo um largo contexto. Segurança estende muito além de um processo
de resposta incidente que é ativado quando um ataque de negação de serviço atinge o servidor
web ou um hacker mal intencionado viola o perímetro de uma rede. Uma grande parte da
segurança está respondendo a eventos diários de segurança, lançamentos de logs e alertas que
podem ou não desenvolver uma larga escala de incidentes. Dessa forma resposta de segurança
é a reação de uma organização para os eventos de segurança, apontando desde uma nova linha
18
em um arquivo de registro de eventos, até espionagem corporativa ou grandes ataques
distribuídos de negação de serviço.
Um caso de incidente é uma coleção de evidências e esta associado bem próximo a um
incidente de segurança. Assim, o caso é uma história do que aconteceu e o que foi feito, com a
evidência suportando. O caso de incidente pode incluir vários documentos como relatórios,
dados, resultados de entrevistas de áudio, arquivos de imagens, e mais. O relatório de
incidente é um documento preparado depois de uma investigação de um caso de incidente.
Um relatório de incidente pode ser assinado criptograficamente ou ter outras garantias de sua
integridade. Muitas investigações de incidentes resultam em um relatório que é submetido
para as autoridades apropriadas (tanto interna ou externa a companhia), contendo alguns ou
todos os dados associados com o caso. Note que o termo evidência é utilizado para indicar
qualquer dado descoberto no processo de reposta a incidente, não apenas os dados coletados
que são admitidos no tribunal de justiça.
19
3 REPOSTA A INCIDENTES DE SEGURANÇA EM
COMPUTADORES
Segundo a NBSO (2003), um incidente de segurança pode ser definido como qualquer
evento adverso, confirmado ou sob suspeita, relacionado à segurança de sistemas de
computação ou de redes de computadores.
Um incidente de segurança pode ser ocasionado por tentativas de ganhar acesso não
autorizado a sistemas ou dados; ataques de negação de serviço; uso ou acesso não autorizado
a um sistema; modificações em um sistema, sem o conhecimento, instruções ou
consentimento prévio do dono do sistema; desrespeito à política de segurança ou à política de
uso aceitável de uma empresa ou provedor de acesso.
3.1
POLÍTICA DE SEGURANÇA
Segundo a NBSO (2003), a política de segurança atribui direitos e principalmente
responsabilidades às pessoas que de alguma forma lidam com os recursos computacionais de
uma instituição e com as informações neles contidos. Na política de segurança também são
definidas as atribuições de cada pessoa com relação à segurança dos recursos com os quais
trabalham.
Uma política de segurança também deve prever o que pode ou não ser feito na rede da
instituição e o que será considerado inaceitável. Tudo o que descumprir a política de
segurança é considerado um incidente de segurança.
Na política de segurança também são definidas as penalidades às quais estão sujeitos
aqueles que não cumprirem a política.
Um modelo de uma política de segurança foi colocado no anexo A e pode ser utilizada
para formular a política de segurança de uma organização.
3.2
POLÍTICA DE USO ACEITÁVEL
Segundo a NBSO (2003), a política de uso aceitável é um documento que define como
podem ser utilizados os recursos computacionais de uma instituição, também define os
direitos e responsabilidades dos usuários.
No caso dos provedores de acesso à Internet, a política de uso aceitável normalmente
fica disponível em suas páginas. As empresas costumam dar conhecimento da política de uso
aceitável no momento da contratação ou quando o funcionário começa a utilizar os recursos
20
computacionais da empresa. Foi incluído neste trabalho um exemplo de política de uso
aceitável no anexo B.
3.3
USO ABUSIVO DA REDE
Segundo a NBSO (2003), existem algumas situações que ocorrem internamente nas
empresas ou instituições que caracterizam o uso abusivo da rede e geralmente estão definidas
na política de uso aceitável. Na Internet, comportamentos como envio de spam, envio de
correntes de felicidade e de correntes para ganhar dinheiro fácil e rápido, cópia e distribuição
não autorizada de material protegido por direitos autorais, utilização da Internet para fazer
calúnias, ameaças e difamações, tentativas de ataques a outros computadores,
comprometimento de computadores ou redes, são geralmente considerados como uso abusivo.
3.4
VULNERABILIDADES
Esse termo refere-se a qualquer fraqueza em qualquer sistema, seja de software ou de
hardware, que permite que um invasor ganhe acesso não autorizado ou torne um serviço
indisponível. É também conhecido como brecha.
Com o grande número de vulnerabilidades sendo anunciadas diariamente na rede, as
organizações tem a difícil tarefa de descobrir as brechas de segurança que possam permitir a
invasão ou negação de serviço de seus sistemas. Na tentativa de auxiliar nessa missão em
contínuo progresso, muitas iniciativas proprietárias e de código fonte aberto surgiram para
automatizar este processo de varredura das vulnerabilidades. Essas ferramentas ficaram
conhecidas como scanners de vulnerabilidades.
Segundo Lucas e Moller (2003), profissionais de segurança de várias organizações têm
trabalhado juntos para estabelecer uma lista com as vulnerabilidades mais comumente
exploradas. Esta lista é mantida pelo instituto SysAdmin, Audit, Network, Security (SANS) e
mantida em seu sítio na rede (http://www.sans.org). O desenvolvimento desta lista inclui
entradas do FBI, CERT/CC, e muitas outras organizações e indivíduos. A lista original foi
postada em 2000 e incluía as 10 vulnerabilidades mais freqüentemente exploradas na Internet.
A lista foi expandida para as top 20 vulnerabilidades em 2001. A lista top 20 é atualmente
uma combinação de duas listas top 10 – as dez vulnerabilidades mais associadas com UNIX e
as dez vulnerabilidades mais associadas com sistemas operacionais Windows. Contra a
vontade de muitos profissionais de segurança, esta lista combinada ainda responsabiliza-se
pelas vulnerabilidades mais freqüentemente exploradas.
Estabelecido em 1998, o CERT/CC – Computer Emergency Reponse
Team/Coordination Center – é um centro de desenvolvimento e pesquisa fundado na
universidade de Carnegie Mellon em Pittsburg, Pensilvânia. Seguindo o incidente provocado
pelo worm de Morris, que causou a parada de 10 porcento dos sistemas da Internet em
novembro de 1988, a Defense Advanced Research Projects Agency (DARPA) decidiu formar
o centro para coordenar a comunicação entre especialistas durante emergências de segurança
e para ajudar a prevenir futuros incidentes. Atualmente o CERT/CC continua respondendo
incidentes de segurança e analisando as vulnerabilidades de sistemas e produtos. Além disso,
atualmente o CERT/CC oferece treinamentos e certificações para resposta a incidentes de
segurança. O CERT/CC tem uma grande base de conhecimento de vulnerabilidades e conta
com o auxilio de todos, solicitando que as pessoas informem as vulnerabilidades encontradas
para que eles possam colocar em sua base e publicar estas vulnerabilidades para que se
21
tornem conhecidas dos usuários da Internet e dos profissionais de segurança da informação.
Estas
informações
podem
ser
acessadas
no
sítio
do
CERT/CC
em
http://www.cert.org/advisories/, nesta página uma vulnerabilidade é identificada pelo prefixo
CA (de CERT Advisor), mais o ano em que foi descoberto, um número seqüencial e uma
breve descrição, por exemplo “CA-2004-02 Email-borne Viruses”, foi a segunda
vulnerabilidade publicada neste ano e “CA-2003-28 :Buffer Overflow in Windows
Workstation Service”, esta foi a última vulnerabilidade publicada em 2003, o CERT/CC tem
em um sua base, vulnerabilidades desde 1988. Nestes avisos do CERT/CC são colocadas
informações importantíssimas sobre as vulnerabilidades como descrição, impacto e solução.
Para fazer o levantamento das vulnerabilidades dos servidores é utilizado o Nessus,
que é uma poderosa ferramenta para varredura de vulnerabilidades, esta ferramenta
disponibiliza relatórios com as vulnerabilidades encontradas e as classifica quanto ao fator de
risco, que pode ser baixo, médio, alto, muito alto. Um exemplo de relatório é mostrado no
Anexo C.
3.5
FIREWALL
Segundo Chapman e Zwicky (1995), um firewall é um dispositivo utilizado para
prevenir que intrusos ganhem acesso a uma rede de computadores fazendo a filtragem dos
pacotes de dados que entram ou saem em um host ou em uma rede. Este dispositivo
geralmente é uma combinação de software e hardware. Porém o componente mais importante
não é o software, nem o hardware, mas sim a atenção da pessoa que o constrói. Um firewall é
muito mais um conceito do que um produto. É o planejamento atencioso de quem e o que será
permitido que acesse uma rede de computadores. Por esta razão construir um firewall uni a
percepção, a inteligência e a lógica.
Existem diferentes tipos de firewall, cada tipo tem suas vantagens e desvantagens. Os
firewalls podem ser aplicados a um host ou a uma rede. Os firewalls de host filtram todo o
tráfego de dados que entram e saem de uma máquina, enquanto que os firewalls de rede
filtram todo o tráfego de dados que entram e saem de uma rede.
O tipo mais comum é o firewall baseado em roteamento, mais conhecido como
firewall de rede. Estes firewalls utilizam regras que dizem quem e o que podem acessar uma
determinada rede, verificando o endereço IP e porta, de origem e destino, de um pacote de
dados. Este esquema á aplicado no nível de roteamento e é chamado de filtro de pacotes.
Um filtro de pacotes é um software que analisa o cabeçalho (header) dos pacotes
enquanto eles passam, e decide o destino do pacote como um todo. Ele pode decidir entre
descartar (drop) o pacote (descartando-o como se nunca o tivesse recebido), aceitar (accept) o
pacote (deixar o pacote seguir seu caminho), ou algo mais específico e complexo do que isso.
No Linux, filtragem de pacotes está implementada diretamente no cerne (como um
módulo ou diretamente compilado), e há várias coisas interessantes que podem ser feitas com
os pacotes, mas o princípio geral é analisar o cabeçalho dos pacotes e decidir o que ser feito
com o pacote.
Um outro tipo de firewall bem comum é o gateway de aplicação ou application-Proxy
firewall, estes trabalham um pouco diferente do filtro de pacotes. Os gateways de aplicação
são baseados em software. Quando um usuário remoto contata uma rede onde esta rodando
um gateway de aplicação, este bloqueia a conexão remota ao invés de permitir que a conexão
continue, então verifica vários campos da requisição. Se estes campos combinarem com um
22
conjunto de regras pré-definidas, o gateway de aplicação cria uma ponte (bridge) entre o host
remoto e o host local. Os pacotes IP não são repassados para a rede interna. Ao contrário disto
um tipo de tradução ocorre, ficando o gateway de aplicação encarregado de conduzir e
interpretar as requisições remotas. A vantagem do gateway de aplicação é a ausência de
retransmissão do pacote IP para a rede interna. E o mais importante é que mais controle pode
ser feito sobre esta conexão. Como em cada conexão todo o tráfego de pacotes é aceito,
negociado, traduzido e repassado, esta implementação pode ser mais lenta do que a do filtro
de pacotes. A outra desvantagem é a necessidade de se criar um gateway de aplicação para
cada serviço que se deseja disponibilizar.
Segundo Chapman, Cooper e Zwicky (2000), um firewall é um foco para decisões de
segurança, pode forçar uma política de segurança, pode registrar a atividade da internet
eficientemente, pode limitar a exposição a ataques, um firewall não protege a rede de ataques
internos, não pode controlar conexões que não passam por ele, não protege contra ameaças
totalmente novas, não protege completamente uma rede contra vírus, não pode se configurar
da maneira ideal sozinho.
Neste trabalho é utilizado o Netfilter para fazer a filtragem dos pacotes e o Firewall
Builder para fazer o gerenciamento das regras, pois possui uma interface gráfica muito
intuitiva.
3.6
SISTEMAS DE DETECÇÃO DE INTRUSÃO
Segundo Rehman (2003), sistemas de detecção de intrusão ou IDS são software,
hardware ou uma combinação de ambos utilizados para detectar atividades de intrusos. Um
IDS pode ter capacidades diferentes dependendo quão complexos e sofisticados são seus
componentes. Equipamentos IDS são uma combinação de hardware e software que são
disponibilizados no mercado por diversas empresas. Um IDS pode utilizar assinaturas,
técnicas baseadas em anomalias ou ambas.
3.6.1
Sistema de detecção de intrusos de rede
NIDS são sistemas de detecção de intrusos que capturam pacotes de dados que estão
passando pelos meios de rede (cabos, ondas de rádio) e comparam-nos a um banco de dados
de assinaturas. Dependendo de como um pacote é casado com uma assinatura de ataque, um
alerta é gerado ou o pacote é registrado em um arquivo ou banco de dados.
3.6.2
Sistema de detecção de intrusos de host
Os sistemas de detecção de intrusos baseados em host ou HIDS são instalados como
agentes em um host. Estes sistemas de detecção de intrusos podem observar dentro do sistema
arquivos de logs de aplicações para detectar por atividades de intrusão. Alguns destes
sistemas são reativos, significando que ele pode informar alguém apenas quando alguma coisa
acontece. Alguns HIDS são pró-ativos. Eles podem capturar o tráfego de rede vindo para um
host em particular no qual o HIDS está instalado e fazer um alerta em tempo real.
23
3.6.3
Assinaturas
Assinaturas são padrões que são observados dentro de um pacote de dados. Uma
assinatura é utilizada para detectar um ou múltiplos tipos de ataques. Por exemplo, a presença
de um “script/iisadmin” em um pacote indo para um servidor de páginas web pode indicar
uma atividade de intrusão.
Assinaturas podem estar presentes em diferentes partes de um pacote de dados
dependendo a natureza do ataque. Por exemplo, uma assinatura pode ser encontrada em um
cabeçalho IP, em um cabeçalho da camada de transporte (cabeçalho TCP ou UDP) e/ou no
cabeçalho da camada de aplicação ou no próprio dado útil do pacote. Geralmente o IDS
depende da assinatura para encontrar algo sobre a atividade intrusiva. Alguns IDS de
fabricantes específicos necessitam de atualizações de seu fabricante para que novas
assinaturas sejam adicionadas quando novos tipos de ataque são descobertos. Em outros IDS,
como o Snort, o usuário pode fazer as atualizações das assinaturas. Abaixo, na figura 3.1, são
mostradas algumas regras do IDS Snort, onde pode ser observado o campo content que são a
assinatura do ataque.
alert ip $EXTERNAL_NET $SHELLCODE_PORTS -> $HOME_NET any (msg:"SHELLCODE
SGI NOOP"; content:"|03 E0 F8|%|03 E0 F8|%|03 E0 F8|%|03 E0 F8|%";
reference:arachnids,356; classtype:shellcode-detect; sid:638; rev:5;)
alert ip $EXTERNAL_NET $SHELLCODE_PORTS -> $HOME_NET any (msg:"SHELLCODE
SGI NOOP"; content:"|24 0F 12|4|24 0F 12|4|24 0F 12|4|24 0F 12|4";
reference:arachnids,357; classtype:shellcode-detect; sid:639; rev:5;)
alert ip $EXTERNAL_NET $SHELLCODE_PORTS -> $HOME_NET any (msg:"SHELLCODE
AIX NOOP"; content:"O|FF FB 82|O|FF FB 82|O|FF FB 82|O|FF FB 82|";
classtype:shellcode-detect; sid:640; rev:6;)
Figura 3.1 – Exemplos de assinaturas de ataques utilizados na configuração do Snort
3.6.4
Alertas
Alertas são qualquer tipo de notificação feita ao usuário de uma atividade intrusiva.
Quando um IDS detecta um invasor, ele tem que informar o administrador de segurança sobre
isto utilizando alertas. Alertas podem ser registros para uma console, envio de e-mails e
outros. Alertas também são armazenados em arquivos de registro ou banco de dados onde
podem ser visualizados posteriormente por especialistas de segurança. O Snort pode gerar
alertas de várias maneiras, os alertas são controlados por plug-ins de saída. O Snort pode
enviar o mesmo alerta para múltiplos destinatários. Por exemplo, é possível registrar alertas
em um banco de dados e gerar traps SNMP simultaneamente. Alguns módulos podem
também modificar a configuração do firewall para que hosts ofensivos sejam bloqueados no
nível do firewall ou roteador.
3.6.5
Sensor
A máquina na qual um sistema de detecção de intrusão esta rodando é também
chamado de sensor na literatura porque ele é utilizado para “sentir” a rede. Em grandes
estruturas de rede podem ser espalhados vários sensores que são gerenciados por uma console
central, para qual também podem reportar seus alertas.
24
3.7
SISTEMA DE MONITORAMENTO DE REDE
Sistemas deste tipo são projetados para informar os administradores sobre problemas
de rede em hosts ou serviços. Geralmente existe um processo que central que executa
checagens intermitentes nos hosts e serviços que foram especificados na configuração.
Quando problemas com estes hosts ou serviços ocorrem o processo de monitoramento envia
notificações para os contatos administrativos.
A identificação de ataques em uma rede pode ser feita de diversas maneiras, quando
um sistema está publicado na Internet o firewall pode registrar em arquivo todas as tentativas
de acesso que foram negadas e permitidas, porém quando um firewall permite que o acesso a
um serviço que esteja publicado na internet seja feito de qualquer lugar, fica quase impossível
diferenciar um ataque que esteja sendo feito neste serviço de um acesso realmente legítimo,
portanto se um ataque for realmente feito neste recurso, isto não vai ser percebido pelo
firewall. Caso ainda não exista uma assinatura para este ataque no NIDS ou por algum motivo
não foi feita a atualização das assinaturas a tempo, o NIDS também não vai perceber o ataque.
Se este ataque prejudicar de alguma forma este serviço deixando-o indisponível, então um
sistema de monitoramento de rede que esteja configurado para monitorar este recurso pode
fazer o alerta do problema.
Este tipo de situação pode ser chamado de reativa, pois o ataque só vai ser identificado
se o host ou serviço ficarem indisponíveis. Além disso, também podem ser monitorados
alguns indicadores do host como utilização do processador, memória e espaço em disco.
3.8
SISTEMA
DE
CONTROLE
DE
REQUISIÇOES
PARA
REPOSTA
A
INCIDENTES
O sistema RT, do inglês Request Tracker, foi adotado neste trabalho porque é um
sistema que possibilita o gerenciamento de tarefas, problemas e requisições por um grupo de
pessoas, de forma inteligente e eficiente, submetidas por uma comunidade de usuários. Este
sistema já está em desenvolvimento desde 1996, e é utilizado por administradores de sistemas,
equipes de suporte a clientes, gerentes de TI e desenvolvedores em muitos lugares do mundo
(BP, 2004).
Escrito na linguagem orientada a objetos Perl, o RT é um sistema independente de
plataforma que facilita a colaboração dentro de organizações, pois o RT gerencia tarefas
chaves como identificação, priorização, designação, resolução e notificação, que são fatores
requeridos por aplicações de missão crítica dentro das organizações.
O RT foi criado pela empresa Best Practical, esta empresa foi fundada para agregar
valor à base instalada de usuários do RT, provendo desenvolvimentos específicos e suporte
aos usuários do RT. Esta empresa esta comprometida em fornecer suporte ao RT como uma
tecnologia de código aberto, e ao mesmo tempo fornecendo qualidade no desenvolvimento e o
suporte necessário para operações em organizações comerciais e corporações.
Como complemento do RT, para atender as necessidades dos grupos de resposta a
incidentes, foi desenvolvido o RTIR, do inglês Request Tracker for Incident Response. O
RTIR foi desenvolvido em cooperação com o grupo de resposta a incidentes JANET (JANET
é uma rede de educação e pesquisa no Reino Unido). Este grupo estava interessado no RT,
mas precisa de mais algumas características especificas para resposta a incidentes, fez suas
contribuições e agora o RTIR esta disponível para quem quiser utilizar (BP, 2004).
25
A principal característica adicionada pelo RTIR após sua instalação é a criação de
quatro filas, dentro do RT, para o controle de incidentes. Estas filas são: Incident Reports,
Incidents, Investigations and Blocks. Estas filas formam um pequeno fluxo que deve ser
seguido durante a utilização do RTIR.
• Incidents Reports é a fila onde novos incidentes reportados devem aparecer.
Quando um usuário envia uma mensagem de correio eletrônico, para o endereço
configurado no sistema, reportando um incidente, um tíquete é criado nesta fila.
A prioridade e o prazo deste tíquete podem ser ajustados automaticamente
conforme as regras de nível de serviço da organização.
• Assim que um novo incidente reportado é considerado válido por algum membro
do grupo, um tíquete pode ser criado na fila Incidents referenciado o incidente
reportado. Ou o incidente reportado pode ser ligado a um tíquete já existente na
fila Incidents. Se vários incidentes reportados são sobre o mesmo problema ou
assunto, todos estes incidentes reportados pode ser ligados a um incidente (tíquete
na fila Incidents).
• Na fila Blocks são criados tíquetes para controlar os bloqueios feitos no(s)
firewall(s) de uma rede. Estes tíquetes também podem ser criados a partir de
tíquetes da fila Incidents.
• De um incidente existente, podem ser iniciadas investigações para entidades
externas, com a criação de tíquetes na fila Investigations, pedindo a estas
entidades que observem ou resolvam um determinado assunto ou problema.
3.9
REGISTROS DE ATIVIDADES OU EVENTOS
Segundo o NBSO (2003), logs são registros de atividades gerados por programas de
computador. No caso de logs relativos a incidentes de segurança, eles normalmente são
gerados por firewalls ou por sistemas de detecção de intrusão.
Os firewalls, dependendo de como foram configurados, podem gerar logs quando
alguém tenta acessar um computador e este acesso é barrado pelo firewall. Sempre que um
firewall gera um log informando que um determinado acesso foi barrado, isto pode ser
considerado uma tentativa de ataque, mas também pode ser um falso positivo.
Já os sistemas de detecção de intrusão podem gerar logs tanto para casos de tentativa
de ataques, quanto para casos em que um ataque teve sucesso. Apenas uma análise detalhada
pode dizer se uma atividade detectada por um IDS foi um ataque com sucesso. Assim como
os firewalls, os sistemas de detecção de intrusão também podem gerar falsos positivos.
Segundo o NBSO (2003), os logs relativos a ataques recebidos pela rede, em geral,
possuem as seguintes informações:
• Data e horário em que ocorreu uma determinada atividade;
• Endereço IP de origem e destino da atividade;
• Portas envolvidas;
Dependendo do grau de refinamento da ferramenta que gerou o log ele também pode
conter informações como:
• O timezone do horário do log;
• Protocolo utilizado (TCP, UDP, ICMP, etc).
• Os dados completos que foram enviados para o computador ou rede.
26
3.10 FALSOS POSITIVOS
Segundo o NBSO (2003), o termo "falso positivo" é utilizado para designar uma
situação em que um firewall ou IDS aponta uma atividade como sendo um ataque, quando na
verdade esta atividade não é um ataque.
Um exemplo clássico de falso positivo ocorre no caso de usuários que costumam se
conectar em servidores de IRC e que possuem um firewall pessoal. Atualmente boa parte dos
servidores de IRC possui uma política de uso que define que um usuário, para se conectar em
determinados servidores, não deve possuir em sua máquina pessoal nenhum programa que
atue como proxy. Para verificar se um usuário tem algum programa deste tipo, ao receberem
uma solicitação de conexão por parte de um cliente, os servidores enviam para a máquina do
cliente algumas conexões que checam pela existência destes programas. Se o usuário possuir
um firewall é quase certo que estas conexões serão apontadas como um ataque.
Outro caso comum de falso positivo ocorre quando o firewall não está devidamente
configurado e indica como ataques respostas a solicitações feitas pelo próprio usuário.
3.11 NOTIFICAÇÕES DE INCIDENTES E ABUSOS
Segundo o NBSO (2003), um ataque lançado contra uma máquina ou uma rede
normalmente tem uma destas duas origens:
• um programa malicioso que está fazendo um ataque de modo automático, como
por exemplo um worm;
• uma pessoa que pode estar ou não utilizando ferramentas que automatizam
ataques.
Quando o ataque parte de uma máquina que foi vítima de um worm, reportar este
incidente para os responsáveis pela máquina que originou o ataque vai ajudá-los a identificar
o problema e resolvê-lo.
Se este não for o caso, a pessoa que está atacando o seu computador pode estar
violando a política de uso aceitável da rede que utiliza ou, pior ainda, pode ter invadido uma
máquina e a estar utilizando para atacar outros computadores. Neste caso, avisar os
responsáveis pela máquina de onde parte o ataque pode alertá-los para o mau comportamento
de um usuário ou para uma invasão que ainda não havia sido detectada.
Segundo o NBSO (2003), os incidentes ocorridos devem ser notificados para os
responsáveis pela máquina que originou a atividade e também para os grupos de resposta a
incidentes e abusos das redes envolvidas. De modo geral a lista de pessoas/entidades a serem
notificadas inclui:
• os responsáveis pela rede que originou o incidente, incluindo o grupo de
segurança e abusos, se existir um para aquela rede;
• o grupo de segurança e abusos da rede em que se está conectado (seja um
provedor, empresa, universidade ou outro tipo de instituição);
Caso algum dos sítios envolvidos seja brasileiro mantenha o NBSO ([email protected]) na
cópia da mensagem.
O NIC BR Security Office (NBSO) é o grupo responsável por coordenar as ações entre
sítios no caso de incidentes de segurança em computadores envolvendo redes conectadas à
Internet brasileira. (NBSO, 2003).
27
O NBSO também mantém estatísticas sobre os incidentes a ele reportados e
desenvolve documentação de apoio para usuários e administradores de redes Internet. (NBSO,
2003).
Manter o NBSO nas cópias das notificações de incidentes de segurança é importante
para permitir que:
• as estatísticas geradas reflitam os incidentes ocorridos na Internet brasileira;
• o NBSO escreva documentos direcionados para as necessidades dos usuários da
Internet no Brasil;
• o NBSO possa correlacionar dados relativos a vários incidentes, identificar
ataques coordenados, novos tipos de ataques, etc.
Na Internet são mantidas diversas bases de dados com as informações a respeito dos
responsáveis por cada bloco de endereços IP existente. Estas bases de dados estão nos
chamados "Servidores de Whois".
Segundo o NBSO servidor de whois para os endereços IP alocados ao Brasil pode ser
consultado em http://registro.br/. Para os demais países e continentes existem diversos outros
servidores. O sítio http://whois.geektools.com/cgi-bin/proxy.cgi aceita consultas referentes a
qualquer número IP e redireciona estas consultas para os servidores de Whois apropriados.
Os passos para encontrar os dados dos responsáveis incluem:
• Acessar o sítio http://registro.br/ e fazer uma pesquisa pelo número IP ou pelo
nome de domínio da máquina de onde partiu a atividade;
• Se o IP da máquina estiver alocado para o Brasil, os dados dos responsáveis serão
exibidos;
• Se aparecer a mensagem: "Não alocado para o Brasil", significa que o IP está
alocado
para
algum
outro
país.
Uma
consulta
no
sítio
http://whois.geektools.com/cgi-bin/proxy.cgi pode retornar os e-mails dos
responsáveis.
Vale lembrar que os e-mails que são encontrados a partir destas consultas não são
necessariamente os e-mails da pessoa que praticou um incidente de segurança. Estes e-mails
são dos responsáveis pela rede onde a máquina está conectada, ou seja, podem ser os
administradores da rede, sócios da empresa, ou qualquer outra pessoa que foi designada para
cuidar da conexão da instituição com a Internet.
Segundo o NBSO, para que os responsáveis pela rede de onde partiu o incidente
possam identificar a origem da atividade é necessário que a notificação contenha dados que
permitam esta identificação.
São dados essenciais a serem incluídos em uma notificação:
• logs completos;
• data, horário e timezone dos logs ou da ocorrência da atividade sendo notificada;
• dados completos do incidente ou qualquer outra informação que tenha sido
utilizada para identificar a atividade.
No Anexo E é mostrado um modelo de formulário para resposta incidentes
disponibilizado pelo CERT/CC em http://www.cert.org/reporting/incident_form.txt .
28
3.12 COMPLEXIDADES DE ATAQUES
Segundo Schiffman (2002), a complexidade de um ataque pode ser baseada na
habilidade técnica de quem faz o ataque. Obviamente quanto mais complexo e seguro for um
ambiente, será mais complexo para um atacante comprometer este ambiente.
Ataques de complexidade baixa são ataques geralmente disparados por script-kids. O
atacante apenas executa um script de ataque, compila algum código malicioso de fácil acesso,
ou utiliza um método publicamente conhecido para fazer um ataque e normalmente mostram
poucas inovações.
Quando um atacante utiliza um método publicamente conhecido, mas expande o
ataque ou inova alguma coisa além do já conhecido, então a complexidade pode ser
considerada como média. Isto pode ser feito através de pequenas modificações de um ataque
conhecido para fazer algumas coisas além do normal.
Os ataques de complexidade alta são feitos por pessoas habilidosas e especializadas. O
método de ataque pode ou não, ser conhecido e o atacante provavelmente escreveu seu
próprio código.
Os ataques de maior complexidade são classificados como altíssimos, onde o atacante
realmente mostra extrema especialização, empregando ataques não conhecidos ou de
tecnologia de ponta. Nestes casos o atacante geralmente é forçado a inventar um grande
negócio e se for adequado pode encobrir os seus passos ou pistas e deixar uma porta de
reentrada. Estes ataques normalmente não são percebidos, exceto por experientes
administradores de segurança ou por uma casualidade.
3.13 COMPLEXIDADE DE PREVENÇÃO E RECUPERAÇÃO
Segundo Schiffman (2002), a complexidade de prevenção é o nível de complexidade
que deve ser requerida em uma organização para prevenir que um incidente aconteça. A
complexidade de recuperação é o nível requerido para suavizar ao máximo o impacto de um
incidente a infra-estrutura de uma organização.
A complexidade é baixa quando prevenir ou suavizar um problema pode ser simples
como uma pequena atualização de software, ou a adição de uma regra ao firewall. Estas
modificações geralmente são tarefas simples e não envolve um grande esforço para serem
feitas.
Quando a prevenção ou recuperação envolve uma complexa atualização de software, a
reinstalação de um sistema infectado ou alguma mudança de infra-estrutura é necessária a
classificação é média.
Se uma série de atualizações em muitas máquinas, combinadas com maiores
mudanças na infra-estrutura, então a complexidade é alta. Este nível pode conter
vulnerabilidades que em geral são extremamente difíceis de ser completamente prevenidas ou
suavizadas.
29
4 GRUPOS DE REPOSTA A INCIDENTES DE SEGURANÇA
EM COMPUTADORES
Segundo Shultz e Shumway (2004), muitas vezes podem ser encontrado o termo
reposta a incidentes equacionado ao termo grupo de respostas a incidentes, isto pode parecer
superficialmente lógico, mas quando estes conceitos são trazidos para a realidade as coisas
podem ser diferentes. Pessoas que não conhecem o processo de reposta a incidentes podem
estar envolvidas em lidar com incidentes relacionados a segurança. Os usuários são um
exemplo clássico.
Supondo que um vírus tenha infectado diversos sistemas em uma organização. Os
usuários podem colaborar com informações do que está ocorrendo e até mesmo no combate
ao vírus, mas dificilmente poderiam ser chamados de um grupo de resposta, pois não tem a
capacidade de dar uma conclusão a um possível ou real incidente de segurança. Um grupo de
resposta a incidentes possui uma série de obrigações relacionadas a levar cada incidente de
segurança a uma conclusão, de acordo com os objetivos da organização que ele serve. A
grande diferença entre indivíduos que lidam com um incidente e um grupo de respostas a
incidentes é a missão designada a cada um, em termos de responsabilidades de sua função de
trabalho. Os indivíduos podem, algumas vezes, vir a se envolver no tratamento de um
incidente, mas para um grupo de resposta a incidentes é designada a responsabilidade de lidar
com incidentes em uma grande parte ou de todas as descrições das tarefas dos indivíduos
envolvidos.
4.1
TAMANHO DE UM GRUPO DE RESPOSTA A INCIDENTES
Segundo Shultz e Shumway (2004), o número de componentes de um grupo de
resposta a incidentes está relacionado com o tamanho da organização para qual trabalham,
podendo ser formado por apenas uma pessoa. Em alguns casos o independente do tamanho da
organização o grupo de respostas a incidentes é formando por uma pessoa que tem a
responsabilidade de efetivamente coordenar os esforços de um número de pessoas. Quando os
esforços para tratar um incidente estão encerrados, os outros indivíduos envolvidos no
incidente são dispensados de qualquer responsabilidade que eles possam ter recebido no
tratamento de um incidente. Mas o membro do grupo tem a responsabilidade diária de
acompanhar o tratamento dos incidentes e deverá coordenar os esforços para lidar com os
próximos incidentes que ocorrerem.
Alguns grupos de resposta a incidentes possuem muitos membros, cada um com uma
função específica, por exemplo, o CERT/CC possui membros em sua equipe engajados nas
operações diárias, como receber os relatórios de incidentes e tentar identificar o tipo, origem,
30
impacto, e outras observações de um incidente de segurança que foi relatado. Outros tentam
negociar com fabricantes para que vulnerabilidades conhecidas sejam fechadas em sistemas
operacionais, aplicações e assim por diante. Ainda existem outros que examinam dados para
identificar e projetar as tendências dos incidentes, algo mais relacionado à pesquisa.
4.2
MODELOS DE UTILIZAÇÃO PARA ORGANIZAÇÕES
Uma organização pode ter o seu próprio grupo de resposta a incidentes ou contratar
uma empresa especializada para providenciar o suporte à resposta de incidentes, para ambos
os modelos existem vantagens e desvantagens. A principal vantagem de contratar uma
empresa especializada em resposta a incidentes é que o custo total no tratamento de incidentes
relacionados a segurança seja provavelmente menor, pois o pessoal de resposta a incidentes
precisa lidar apenas com incidentes que ocorrem. A menos que haja um grande número de
incidentes, não existe a necessidade de manter um pessoal fixo para ficar esperando que um
incidente aconteça. Adicionalmente algumas empresas de segurança de informações
usualmente oferecem tipos diferentes de especialidades que muitas vezes podem não estar
presente nas organizações.
A principal vantagem de manter um grupo de respostas a incidentes internamente a
organização é que todos os esforços para o tratamento dos incidentes são feitos baseados na
política e na cultura da organização. Os incidentes de segurança são potencialmente muito
sensíveis e políticos; um grupo interno seria provavelmente a maneira mais vantajosa para a
organização na condição, óbvia, de que os indivíduos dentro deste grupo entendam a cultura e
a política da organização.
4.3
RAZÕES PARA SE
UTILIZAR UM GRUPO DE RESPOSTA A INCIDENTES
Existem várias questões que justificam a formação de um grupo de resposta a
incidentes e segundo Shultz e Shumway (2004), as principais são a habilidade de coordenar, a
especialização dos indivíduos, eficiência, a habilidade para trabalhar de forma pró-ativa,
atingir os requisitos desejados por agências ou corporações e ter um meio de ligação de
credibilidade com outras organizações. Estas questões serão explicadas a seguir:
4.3.1
Habilidade para coordenar
É mais fácil coordenar os esforços de indivíduos que fazem parte de um grupo de
resposta a incidentes porque geralmente os indivíduos se reportam a um líder, que irá designar
para cada membro do grupo uma atividade em particular para ser executada.
4.3.2
Especialização
Os incidentes de segurança da informação estão cada vez mais complexos e por isto
especialistas no tratamento de incidentes são cada vez mais necessários nas organizações.
Técnicos muitos especializados são úteis quando um incidente ocorrer, mas somente
especialidade técnica não é suficiente para muitos incidentes. É importante ter ajudado em
muitos incidentes anteriores e ter o conhecimento de quais políticas devem ser consideradas e
quais procedimentos devem ser seguidos.
31
4.3.3
Eficiência
Geralmente um grupo constrói uma base de conhecimento, o que implica no aumento
de eficiência. Um indivíduo sozinho pode facilmente desviar do caminho correto quando
estiver lidando com um incidente, porém a inteligência coletiva acumulada dentro de um
grupo pode ajudar nos esforços de responder um incidente a retornar ao caminho correto.
Com um time, ao contrário de um indivíduo ou poucos indivíduos independentes, é mais
provável o desenvolvimento e o cumprimento de procedimentos para responder incidentes,
algumas vezes isto ajuda muito na eficiência.
4.3.4
Habilidade para trabalhar de forma pró-ativa
Ser pró-ativo é uma das chaves para ter sucesso no esforço de responder incidentes.
Treinar usuários e administradores de sistemas para reconhecer sintomas de incidentes e o que
se deve fazer, bem como o que não se deve fazer é um bom exemplo que esforço pró-ativo.
Tendo um grupo de respostas a incidentes pode-se ter a luxuria de ter pessoas diferentes,
especializadas em funções específicas, especialistas em atividades pró-ativas. Adicionalmente
os esforços pró-ativos de sucesso são subprodutos da colaboração pelos grupos; indivíduos
4.3.5
Atingir
corporações
os
requisitos
desejados
pelas
agências
ou
A principal razão é que um time tem indivíduos que são direcionados a uma mesma
missão. É importante lembrar que algumas agências governamentais e corporações vão um
passo a frente em suas exigências na qual, através de uma decisão gerencial ou política
estabelecida, exigem que um grupo de respostas a incidentes seja formado.
4.3.6
Servir como elo de ligação
Grupos de resposta a incidentes são melhores para servir como elo de ligação, do que
indivíduos, porque para entidades externas não estão motivadas a tratar com indivíduos.
Tendo a identidade de um grupo, provavelmente uma visibilidade externa é fornecida, bem
como credibilidade, ambos os quais satisfazem mais a função de ligação. Além do mais, em
muitos aspectos, um grupo controla um certo grau de legitimidade dentro de organizações
internas e externas.
32
5 DESCRIÇÃO DO SISTEMA
Este trabalho apresenta uma integração das principais ferramentas de segurança de
sistemas em software de código fonte aberto nas áreas de filtro de pacotes, detecção de
intrusos, varredura de vulnerabilidades e monitoramento de servidores e serviços de rede, com
um sistema também em código fonte aberto focado no controle de requisições para reposta a
incidentes de segurança em computadores.
5.1
IPTABLES
Para fazer a filtragem de pacotes é utilizado o framework do núcleo do sistema
operacional Linux, presente nas versões 2.4 e 2.6, chamado de Netfilter, também conhecido
como Iptables. Este framework possibilita também a tradução de endereços e portas de rede e
outras manipulações de pacotes. Para auxiliar o gerenciamento de regras e objetos de rede é
utilizada a interface gráfica Fwbuilder, essa interface facilita muita a configuração de um
firewall em Linux. Uma boa documentação do Fwbuilder esta disponível no sítio do projeto
em http://www.fwbuilder.org.
O Netfilter é um conjunto de ganchos dentro do núcleo do Linux que possibilita que
módulos do núcleo registrem funções de rechamada na pilha de rede. Uma função de
rechamda registrada é então chamada novamente para cada pacote que atravessa o respectivo
gancho dentro da pilha de rede.
Iptables é uma estrutura genérica de tabelas para definição de um conjunto de regras.
Cada regra dentro de uma tabela IP consiste em um número de regras de classificação e uma
ação de conexão (iptables target).
Netfilter, Iptables e os subsistemas de controle de conexões bem como o de tradução
de endereços, juntos completam o framework. Mais informações podem ser obtidas no sítio
do projeto http://www.netfilter.org.
5.2
SNORT
O Snort é um sistema com código aberto para detecção de intrusos capaz de fazer a
análise em tempo real e registro de pacotes em redes IP. Pode fazer análise de protocolo,
busca de conteúdo e pode ser utilizado para detectar uma variedade de ataques e tentativas,
como estouro de pilhas, varredura de portas, ataques por CGI, sondagens SMB , tentativas de
identificação de sistema operacional, e muito mais. Mais detalhes sobre o Snort podem ser
encontrados no sítio http://www.snort.org.
33
O sistema de detecção de intrusos utilizado é o Snort compilado com o patch para o
SnortSam, que é um módulo para o Snort capaz de adicionar automaticamente regras de
bloqueio ao firewall para eventos detectados pelo IDS, mas somente aos eventos que nos
quais foram adicionadas as ações de bloqueio na base de regras de detecção de eventos do
IDS.
5.3
NESSUS
O projeto Nessus tem como objetivo prover para a comunidade da Internet um
varredor remoto de brechas de segurança, livre, poderoso, atualizável e fácil de usar.
O Nessus é um software que pode fazer remotamente uma auditoria em uma
determinada rede e informar quando alguém ou um vírus de computador podem explorar
brechas de segurança, ou utilizá-las de uma forma indevida. O Nessus é muito rápido,
confiável e tem uma arquitetura modular que possibilita ajustar as necessidades. A
documentação completa do Nessus pode ser encontrada no sítio http://www.nessus.org.
A varredura de vulnerabilidades é feita pelo scanner Nessus, este programa é muito
utilizado para fazer auditorias em sistema ligados em rede, pois tem uma ampla base de
assinatura de vulnerabilidades que é atualizada periodicamente e disponibilizada na Internet.
O Nessus produz relatórios com detalhes das vulnerabilidades encontradas, bem como suas
descrições, seus fatores de risco e possíveis soluções.
5.4
NAGIOS
O monitor de servidores e serviços de rede Nagios foi desenhado para informar os
problemas de rede antes dos clientes, usuários ou gerentes. Foi desenhado para funcionar
sobre o sistema operacional Linux. O processo de monitoramento executa checagens
intermitentes em servidores e serviços especificados na configuração, utilizando módulos
externos que retornam as informações de estados para o Nagios. (Quando problemas são
encontrados, o processo pode enviar notificações para contatos administrativos em diferentes
formas como correio eletrônico, mensagem instantânea, SMS, etc. No sítio do projeto
localizado em http://www.nagios.org existe uma ampla documentação sobre seu
funcionamento, características e contribuições da comunidade que utiliza esta ferramenta.
O Nagios é capaz de monitorar uma ampla variedade de serviços de rede TCP,
gerando notificações que são enviadas por mensagens de correio eletrônico. Também possui
uma interface gráfica que pode ser acessada através de um navegador de Internet, nesta
interface o usuário pode verificar o estado de todos os sistemas que estão sendo monitorados,
os registros das notificações e dos problemas detectados. Ainda nesta interface é possível
adicionar informações extras aos serviços como classificações quanto a confidencialidade,
disponibilidade e integridade, observações e outras mais.
5.5
RTIR
Para fazer o controle de requisições para repostas a incidentes foi adotado o sistema
RTIR, neste sistema é possível a criação de tíquetes através do envio de mensagens de correio
eletrônico, estes tíquetes são criados dentro de filas que podem ser acessadas pelos membros
do grupo de repostas dependendo das permissões atribuídas a eles.
34
O RTIR é uma expansão para o sistema RT focado em atender as necessidades de um
grupo de respostas a incidentes. O RT é um sistema desenhado para fazer o controle de
requisições, solicitações, projetos de uma maneira muito objetiva e intuitiva de utilizar.
Através do RT os usuários de uma rede podem fazer solicitações de manutenção de
equipamento, instalação e configuração de programas e também reportar problemas e
dificuldades. O acesso a sua interface é feita através de um navegador Internet e pode ser
configurado para utilizar bancos de dados como Mysql até versão 4.0.13 ou mais antiga com
suporte InnoDB, Postgresql versão 7.2, Oracle na versão 9iR2. Mas o recomendado na
documentação é o Mysql.
O interpretador de comandos utilizado para o funcionamento do RTIR é o Perl na
versão 5.8.3 ou superior, uma ampla documentação deste projeto como manuais de instalação,
configuração, utilização e padronização podem ser encontrados no sítio
http://wiki.bestpractical.com/.
5.6
INTEGRAÇÃO DAS FERRAMENTAS
O principal mecanismo utilizado para a integração das ferramentas de segurança com
o sistema de controle de requisições são os envios de mensagens de correio eletrônico para o
sistema RTIR. Na maioria dos casos são agendados roteiros no sistema operacional para que
executem pequenos programas que fazem a analise dos registros destas ferramentas e quando
concluída a analise, os relatórios gerados são enviados para o sistema de controle requisições
através de mensagens correio eletrônico para uma fila especifica dentro deste sistema. No
caso do sistema de monitoramento, toda vez que este detecta alguma falha em um servidor ou
serviço monitorado, uma mensagem de correio eletrônico também é enviada para o sistema de
controle de requisições para uma fila especifica como pode ser observado na figura 5.1.
35
Figura 5.1 – Troca de mensagens e processos realizados para a integração
O sistema atua de forma pró-ativa e reativa em relação ao tratamento dos eventos. Na
forma pró-ativa, mostrada na figura 5.2, atuam as ferramentas Iptables, Nessus e Snort, que
ficam coletando informações importantes para o grupo de respostas e estas informações são
inseridas no RTIR para tratamento pelos membros do grupo de respostas.
36
Figura 5.2 – Situação pró-ativa de utilização do sistema
Na forma reativa apresentada na figura 5.3, a ferramenta Nagios, quando detecta a
parada de algum servidor ou serviço de rede, envia uma notificação através de uma mensagem
de correio eletrônico para o sistema de controle de requisições. Nesta forma também se
enquadram os problemas reportados por usuários através da criação de tíquetes na fila
Incindent Reports, estes tíquetes podem ser criados pelos usuários através do envio de
37
mensagens de correio eletrônico para o RTIR ou através de sua interface utilizando um
navegador Internet.
Figura 5.3 – Situação reativa de utilização do sistema
38
5.6.1
Analise das vulnerabilidades
Os relatórios de analises das vulnerabilidades são gerados pela ferramenta chamada de
Nessus. Um roteiro para Linux fica agendado no sistema operacional para iniciar os testes e
gerar um relatório que é enviado por correio eletrônico para o sistema de controle de
requisições para fila Nessus onde é criado um tíquete, sendo que os tíquetes criados nesta fila
são classificados inicialmente de forma automática com uma prioridade média. Neste relatório
são apresentadas informações como:
• Falhas, alertas e informações de segurança de rede para um ou mais endereços de
Internet testados.
• O fator de risco das vulnerabilidades encontradas
• Listagem das portas abertas em um endereço IP
• Possível solução para correção da vulnerabilidade
Nem sempre são encontradas falhas de segurança em um endereço IP, assim como
nem sempre é dada uma solução pela ferramenta, nesses casos o responsável pelo sistema ou
software deve procurar obter estas informações com especialistas de segurança do sistema ou
software em questão ou com o fabricante do mesmo. Um modelo do relatório criado pela
ferramenta Nessus pode ser consultado no anexo C.
5.6.2
Analise dos registros de eventos do firewall
Através de um roteiro agendado no sistema operacional para executar o analisador de
registros do Iptables, chamado de Fwlogwatch, determinadas vezes por dia ou por hora,
conforme a necessidade do ambiente, um relatório é gerado e enviado por correio eletrônico
ao sistema de controle de requisições para a fila Iptables, onde é criado um tíquete que é
automaticamente classificado inicialmente com uma prioridade média, sendo que este
relatório também pode ser disponibilizado em um endereço na rede que é informado no
tíquete. Neste relatório são mostrados os registros com número de ocorrência de pelo menos
vinte e cinco vezes. Cada registro possui o número da regra do firewall que a registrou e qual
ação foi tomada pelo firewall, o número de vezes que o registro ocorreu (número de pacotes),
o endereço IP e porta de origem da conexão e o endereço IP e porta de destino da conexão.
Exemplo: RULE 1 -- ACCEPT eth0 216 tcp packets from 217.199.184.34
(ns.futuremms.com) to 200.176.46.191 (cm-net-poa-C8B02EBF.brdterra.com.br) port 22
(ssh)
Com estas informações podem ser realizadas pesquisas para determinar
comportamentos de endereços específicos, também excluir falsos positivos e cruzar dados
com outros relatórios. Um modelo do relatório criado pela ferramenta Fwlogwatch pode ser
consultado no anexo D.
5.6.3
Analise dos registros de eventos do IDS
O detector de intrusos Snort está integrado ao sistema de controle de requisições
através de um analisador de seus registros. Este analisador é um roteiro em linguagem Perl
chamado de Snortalog, ele fica agendado no sistema operacional para ser executado
determinada vezes por dia e depois de feita a análise, um relatório é gerado e enviado por
correio eletrônico ao sistema de controle de requisições para a fila snort, nesta fila os tíquetes
são classificados automaticamente com uma prioridade média. Nos relatórios do Snortalog
39
podem ser observados dados estatísticos gerais e específicos dos eventos registrados, listados
a seguir:
•
Dados estatísticos gerais
- Distribuição de eventos por hora
- Distribuição de eventos por dia
- Popularidade dos endereços de origem
- Popularidade dos endereços de destino
- Distribuição de eventos por porta de destino
- Distribuição de eventos por protocolo
- Distribuição de eventos por tipo de registro
•
Dados estatísticos específicos
- Eventos de um endereço IP para qualquer endereço utilizando o mesmo
método
- Eventos para um endereço IP de qualquer endereço utilizando o mesmo
método
- Eventos de um endereço para um endereço
- Eventos para uma porta agrupados por ataque
- Distribuição por modos de ataque
- Distribuição por modos de classificação
- Distribuição por de eventos por severidade
- Eventos por hora
Um modelo do relatório criado pela ferramenta Snortalog pode ser consultado no
anexo E.
5.6.4
Alertas do sistema de monitoramento
O sistema de monitoramento Nagios está integrado ao sistema de controle de
requisições de problemas através de notificações de problemas encontrados por ele em algum
serviço de rede ou servidor, durante o monitoramento. Essas notificações são enviadas por
mensagens de correio eletrônico para uma fila específica no sistema de controle de
requisições, chamada de Nagios. Nesta fila os tíquetes são criados com uma prioridade alta,
pois na maioria dos casos as notificações do Nagios são para problemas críticos como um
serviço de rede que parou de funcionar ou um servidor que parou de responder a testes de
envio e recebimento de pacotes de dados pela rede.
Além de serviços de rede, o Nagios pode monitorar também recursos de um servidor
como espaço em disco, utilização de memória, utilização do processador e utilização da
interface de rede. Porém neste trabalho a ferramenta esta configurada para monitorar serviços
TCP e a comunicação com servidores em rede.
5.6.5
Registros dos casos no sistema de controle de requisições
A criação e classificação de tíquetes no sistema podem ser feitas de forma manual por
um membro do grupo de respostas, dessa maneira podem ser registrados incidentes do tipo:
utilização imprópria de direitos garantidos a um usuário, uso indevido de recursos
40
computacionais da empresa, cópias ilegais de programas ou informações por usuários e outros
incidentes que possam violar as políticas de segurança ou uso aceitável.
Os acompanhamentos nos tíquetes abertos de forma automática, pelas ferramentas de
segurança, devem ser registrados manualmente pelos membros do grupo de respostas. Nestes
registros podem ser alterados dados como prioridade do tíquete, dono, fila e outras
informações que o membro responsável por ele achar pertinente.
Foram adicionados mais campos aos tíquetes da fila Incidents, para seguir o modelo de
formulário de resposta a incidente, sugerido pelo CERT/CC e mostrado no anexo F. O
membro do grupo que criar um tíquete de incidente nesta fila deve preencher estes campos da
maneira mais detalhada possível para que o incidente fique bem documentado dentro do
sistema e possa ser enviado a entidades externas caso exista essa necessidade.
5.6.6
Classificações dos tíquetes no sistema de requisições
O sistema de tíquetes adotado neste trabalho, conhecido como RT, utiliza o conceito
de filas. A classificação dos tíquetes é inicialmente atribuída de forma automática conforme a
fila em que é criado. Quando uma fila é criada dentro do sistema de tíquete é possível
configurar a prioridade inicial dos tíquetes criados dentro dela.
A classificação da prioridade de um tíquete é dada por um valor inteiro, quanto mais
alto este valor, maior a prioridade do tíquete. Neste trabalho foi adotada uma escala de valores
para definição das classificações. Se um tíquete possuir um valor de prioridade entre zero e
trinta a classificação é baixa, se o valor estiver entre o intervalo de 31 a 60, então a
classificação é média. Se estiver entre 61 e 90 a classificação é alta e de 91 a 100 é muito alta
a classificação. Os membros do grupo devem dar mais atenção e tentar responder mais
rapidamente aos incidentes com maior prioridade, sempre buscando a resolução dos tíquetes
mais antigos.
Um membro do grupo pode alterar a prioridade de um tíquete se achar necessário.
Essa alteração fica registrada no tíquete indicando qual foi o usuário que a realizou, assim
como a data e o horário.
5.6.7
Utilização do sistema de requisições pelos membros do
grupo de respostas a incidentes
O sistema de tíquetes ou controle de requisições pode ser acessado através de um
navegador em uma estação da rede privada da organização ou da rede pública se este acesso
for liberado no firewall. Os tíquetes podem ser criados através do envio de mensagens de
correio eletrônico pelos usuários do sistema para um endereço definido previamente. Assim
como o acesso ao sistema os tíquetes pode ser feito da rede pública, também podem ser
criados tíquetes a partir desta rede desde que o sistema de correio eletrônico esteja
configurado para aceitar estas mensagens, neste caso é importante que o sistema de correio
eletrônico verifique a veracidade destas mensagens de alguma forma, podendo ser através de
configurações específicas do sistema de correio utilizado ou da utilização de algum sistema
anti-spam. Neste trabalho esta sendo utilizado o sistema de correio eletrônico Postfix e o
sistema anti-spam MailScanner para fazer esta verificação.
41
Em uma corporação que esteja o utilizando o sistema descrito neste trabalho, os
membros do grupo podem estar observando o sistema regularmente com o objeto de estarem
sempre dando o tratamento adequado aos tíquetes abertos no RT.
Além das filas criadas pelo RTIR, citadas no item 3.8, foram criadas mais quatro filas,
uma para cada ferramenta, onde são reportados os relatórios de analises de seus respectivos
registros de eventos e notificações.
A fila nagios recebe as notificações da ferramenta de monitoramento Nagios, nesta fila
os tíquetes são criados com uma prioridade alta devido ao fato de que as notificações enviadas
por esta ferramenta informam problemas de paradas em servidores ou serviços que estão
sendo monitorados. Dentro do tíquete criado estão as informações do problema detectado
como nome do servidor ou serviço, endereço de rede, comando utilizado para realizar o teste,
tipo da notificação, date e horário da notificação. Os membros do grupo devem estar atentos a
esta fila, pois geralmente os tíquetes criados nesta fila são incidentes. Então a partir de um
tíquete desta fila pode ser criado um tíquete na fila Incindents e fluxo citado no item 3.8 pode
ser seguido.
Para a ferramenta Nessus foi criada a fila nessus, nesta fila são criados tíquetes com
prioridade média, os tíquetes criados nesta fila apresentam o relatório de vulnerabilidades
encontradas nos servidores testados pelo Nessus. Os membros do grupo devem observar estes
tíquetes e corrigir as vulnerabilidades apresentadas nos relatórios de vulnerabilidades contidos
neles. Um tíquete criado na fila Incidents para um servidor ou serviço pode estar ligado a um
tíquete criado na fila nessus, se o servidor ou serviço apresentar alguma vulnerabilidade no
relatório.
O Iptables tem a analise de seus registros de eventos enviadas para a fila iptables,
conseqüentemente os tíquetes abertos nestas filas possuem informações dos eventos mais
freqüentes registrados pelo Iptables. Os tíquetes desta fila têm uma prioridade média e devem
ser freqüentemente observados pelos membros do grupo, pois se estes tíquetes apresentarem
informações que um membro do grupo observar como um incidente, então um tíquete pode
ser criado fila Incindents e ligado ao tíquete da fila iptables no qual foi observado o incidente.
O detector de intrusões Snort também tem uma analise de seus registros que é enviada
para fila que foi criada com o nome de snort. Os membros do grupo devem analisar
freqüentemente os tíquetes criados nesta fila, que possuem uma prioridade média. Com base
nas informações do relatório contido no tíquete, pode ser criado um tíquete de incidente na
fila Incindents e seguido o fluxo do item 3.8. Quando o Snortsam, cria uma regra de bloqueio
no firewall, automaticamente uma mensagem de correio eletrônico é enviada para o RTIR e
está endereçada para a fila Blocks. Os tíquetes nesta fila devem ser sempre bem observados
pelos membros do grupo para que saibam quem são os últimos endereços que foram
bloqueados no filtro de pacotes.
Qualquer membro do grupo de reposta a incidentes de segurança pode criar um
tíquete de incidente na fila Incidents quando achar necessário, este tíquete pode estar ligado a
um outro tíquete das filas nagios, nessus, snort, iptables e Incident Reports. O membro que
estiver abrindo já pode dar continuação ao fluxo descrito no item 3.8, ou designar o tíquete
para que outro membro do grupo dê continuidade ao fluxo de resposta a incidente para o
tíquete. Os usuários de uma rede em uma organização também podem ter permissão no
sistema RTIR para criar tíquetes na fila Incident Reports, bem como podem ter permissão para
acompanhar os registros feitos no tíquete e também registrar comentários nele. Quando um
registro é feito em um tíquete, os dados contidos nele podem ser enviados para o requisitante
logo após que o registro foi concluído.
42
As principais vantagens encontradas na utilização deste sistema são o registro
constante das informações de segurança dos sistemas em um sistema centralizado que
disponibiliza fácil consulta a estas informações contidas nos tíquetes e o histórico dos eventos
e assuntos registrados nos tíquetes. O fluxo proposto também agiliza e organiza o processo de
reposta a incidentes, mas é de extrema importância que os membros do grupo o tenham a
responsabilidade de seguir o mesmo.
43
6 TESTES
6.1
DESCRIÇÃO DO AMBIENTE DE TESTES
No ambiente de testes foram utilizadas duas máquinas, uma para servir como gateway
da rede e outra como servidor de terminal de serviços remoto para acesso através de rede
publica, no gateway foram configuradas todas as ferramentas e sistemas utilizadas neste
trabalho. Porém esta não é a prática mais indicada e só foi utilizada com fins de testes de
funcionalidade e analises de funcionamento para definição de uma forma de utilização dos
recursos disponibilizados, pois o recomendado é que no gateway da rede esteja configurado
apenas o firewall e em alguns casos um sensor de IDS também, as demais ferramentas podem
ser distribuídas em pelo menos mais duas máquinas que estariam localizadas na rede interna
ou privada. Uma outra recomendação seria a utilização de criptografia na troca das
mensagens, mas não foi empregada nesta pesquisa pela limitação de tempo e pela
complexidade das outras tarefas executadas e desta também, o que poderia inviabilizar a
conclusão deste trabalho, mas é utilizada criptografia na comunicação do navegador Internet
com o sistema de controle de requisições.
A seguir serão apresentados os programas e os equipamentos utilizados no
desenvolvimento deste trabalho.
6.1.1
testes:
Programas
Os seguintes programas foram utilizados no servidor gateway para a elaboração dos
Sistema operacional: Fedora Core 1
Sistema de detecção de intrusos: Snort 2.3.0 com módulo SnortSam para bloqueio de
endereços com o Iptables.
Sistema de varredura de vulnerabilidades: Nessus 2.0.12
Sistema de monitoramento: Nagios 1.2
Sistema de controle de requisições: RT 3.2.1 com RTIR 1.0.5
Sistema de banco de dados: MySQL 3.23
Servidor http: Apache 2.0.47
Interpretador de comando Perl 5.8.3 e linguagem PHP 4.3.3
44
Analisador de registros para Snort: Snortalog 2.2.1
Analisador de registros para Iptables: Fwlogwatch 1.0
Na estação de trabalho foram utilizados o sistema operacional Windows XP e os
serviços de acesso remoto VNC e Terminal Server.
É importante observar que por motivos de facilidade de instalação, facilidade de
integração com os sistemas utilizados e limitação de tempo foi utilizado o banco de dados
MySQL 3.23, mas outros bancos mais robustos e mais seguros como Postgresql e Oracle
também poderiam ser utilizados para a mesma finalidade.
6.1.2
Equipamentos
O ambiente formado para os testes e a execução da integração das ferramentas ao
sistema de controle de requisições não é o ambiente ideal, pois todas as ferramentas estão
sendo executadas no mesmo servidor, o que em certos momentos causa sobrecarga de
processamento e muita utilização de memória.
Como um todo o ambiente ficou simples, devido à pequena quantidade de serviços e
servidores monitorados, apesar desta característica do ambiente, mesmo assim foi possível
verificar as funcionalidades das ferramentas utilizadas e os resultados da integração.
Abaixo segue a descrição das máquinas utilizadas nos testes.
-
Servidor Gateway
Processador: Pentium III 1GHz
Memória RAM: 192 Mb
Disco Rígido: 80 Gb IDE
2 Interfaces de rede FastEthernet 10/100 Mbps/s
-
Servidor de Terminal de Acesso Remoto
Processador: Atlhon XP 2GHz
Memória RAM: 256 Mb
Disco Rígido: 80 Gb IDE
1 Interface de rede FastEthernet 10/100 Mbps/s
-
Conexão com a Internet
Velocidade: 256 Kbps/s
Provedor: Cable Modem Net Virtua
Modem: Motorola SB5100i
45
O ideal para que esta solução seja implantada em um ambiente corporativo seria a
utilização de pelo menos três servidores como o descrito acima para distribuir os serviços.
Podendo ser um deles firewall e IDS; um outro seria utilizado fazer a varredura de
vulnerabilidades, hospedar o sistema de requisições e o banco de dados; e o terceiro seria
utilizado para fazer o monitoramento dos servidores e serviços de rede.
6.1.3
Topologias
Abaixo, na figura 6.1, pode ser observada a topologia utilizada para o
desenvolvimento do trabalho e testes.
Figura 6.1 – Topologia de rede utilizada nos testes
A seguir, na figura 6.2, a topologia sugerida para um ambiente corporativo, podendo
inclusive ser adicionados mais sensores para a detecção de intrusos nesta topologia.
Figura 6.2 – Topologia sugerida para utilização em organizações comerciais ou grandes
corporações
46
6.2
CENÁRIOS
Neste capítulo serão descritos 4 cenários para demonstrar o funcionamento das
ferramentas de detecção de intrusos, filtro de pacotes, varredura de vulnerabilidades e
monitoramento de servidores e serviços integrados ao sistema de controle de requisições.
6.2.1
Cenário 1 – Varredura externa de portas
Este cenário demonstra o que ocorre quando uma varredura de portas é feita por uma
máquina a partir da Internet para o endereço externo utilizado no ambiente de testes.
1.
A máquina externa dispara uma varredura de portas para coletar informações
sobre o alvo, que neste caso é o ambiente de testes utilizado neste trabalho,
para que o atacante no passo seguinte possa planejar a exploração de alguma
vulnerabilidade de alguma porta aberta encontrada durante a varredura. O
comando utilizado pelo atacante foi:
hacker:~# nmap –v –sS –O matx.no-ip.org
2.
O gateway do ambiente de testes que possui um sensor do Snort, detecta a
varredura através de uma regra que esta configurada para bloquear o
endereço de origem. A seguinte entrada adicionada no arquivo de registros
do Snort:
Nov 30 00:05:08 metacortex snort: [1:0:0] TCP port scan <eth0> {TCP}
200.187.148.42:62526 -> 200.176.46.191:965
3.
Neste ponto uma regra de bloqueio temporário para o endereço 200.187.x.y
é criada no conjunto de regras do filtro de pacotes Iptables no gateway,
através do SnortSam que é um módulo do Snort que possui esta finalidade.
A seguinte entrada é adicionada no arquivo de registros do SnortSam:
2004/11/30, 00:05:08, -, 3, iptables, Info: Command /sbin/iptables -D FORWARD
-i eth0 -s 200.187.148.42 -j DROP Executed Successfully
2004/11/30, 00:05:08, -, 3, iptables, Info: Command /sbin/iptables -D INPUT -i eth0
-s 200.187.148.42 -j DROP Executed Successfully
4.
Depois de criada a regra de bloqueio com sucesso, uma mensagem de
notificação do bloqueio é enviada para o endereço de correio da fila Blocks,
do sistema de controle de requisições e um tíquete é criado nesta fila com as
informações do bloqueio, como mostra a figura 6.3.
5.
Um membro do grupo de repostas deve se apropriar do tíquete criado na fila
Blocks, e criar um novo tíquete na fila Incindents ligado ao tíquete da fila
Blocks e registrar o caso de incidente.
6.
Então o membro do grupo de repostas deve criar um novo tíquete na fila
Investigations ligado ao tíquete criado na fila Incidents para registrar as
informações obtidas sobre o endereço bloqueado, estas informações podem
ser obtidas através de uma consulta do mesmo endereço em um servidor de
whois. As formas de ligar um tíquete a outro estão disponíveis para consulta
em http://wiki.bestpractical.com/index.cgi?Relationships.
47
Figura 6.3 – Detalhes do tíquete criados na fila Blocks
7.
O próximo passo será registrar as ações tomadas, que podem ser, por
exemplo: a notificação do responsável pela rede onde se originou a
varredura ou até mesmo a criação de uma regra no firewall para o bloqueio
definitivo deste endereço.
8.
Então depois de tomadas as devidas ações, estes tíquetes devem ter seus
estados alterados para resolvido.
Para a execução deste teste foi utilizada uma máquina externa e logo após o início da
varredura de portas, esta máquina já estava bloqueada no firewall. A notificação por correio
eletrônico é feita exatamente na hora da criação da regra e o tíquete demora cerca de dois
minutos para ser criado, mas a razão deste tempo é devido à sobrecarga do servidor gateway
que está executando todos as ferramentas e pelo fato de o serviço de correio também fazer
uma verificação nas mensagens em busca de vírus e de conteúdo inapropriado. Com o tíquete
criado no RTIR, como mostra a figura 6.4, as seqüências de passos descritas acima nos itens
cinco em diante foram concluídas sem problemas. A regra criada no firewall foi removida
assim que o tempo determinado na configuração do Snort passou e outro tíquete informando o
desbloqueio foi criado na fila Blocks como também é mostrado na figura 6.4.
48
Tíquete de
Tíquete de
desbloqueio
bloqueio
Figura 6.4 – Tíquetes de bloqueio e desbloqueio criados na fila Blocks
6.2.2
Cenário 2 – Analise de um relatório de registros do Snort
com atividades suspeitas
Neste cenário é demonstrada uma atividade diária de um membro do grupo de
respostas onde o mesmo tem que se apropriar de um tíquete criado na fila snort e verificar se
alguma atividade anormal foi apresentada no relatório. Caso alguma atividade anormal for
realmente encontrada, o membro do grupo deve seguir o fluxo descrito no item 3.8. Caso não
exista atividade anormal no relatório o tíquete deve ter seu estado alterado para resolvido e o
membro do grupo deve registrar no tíquete que nenhuma atividade anormal foi encontrada.
1. Um membro do grupo de resposta a incidentes se apropria de um tíquete mais
antigo da fila snort.
2. O membro identifica uma atividade anormal no relatório e cria um novo tíquete na
fila Incidents ligado ao tíquete criado na fila snort.
3. O próximo passo do membro do grupo pode ser iniciar uma investigação para ter
mais informações do endereço de origem para poder notificar o responsável pela
rede onde se originou o ataque ou a atividade suspeita, para isso ele deve criar um
tíquete na fila Investigations ligado ao tíquete criado no passo anterior na fila
Incidents. Neste tíquete devem ser registradas as informações obtidas sobre o
endereço de origem da atividade suspeita.
49
4. Uma vez concluída a investigação o membro do grupo deve registrar as ações
tomadas, que podem ser, por exemplo: a notificação do responsável pela rede onde
se originou a varredura ou até mesmo a criação de uma regra no firewall para o
bloqueio definitivo deste endereço.
5. Então depois de tomadas as devidas ações, estes tíquetes devem ter seus estados
alterados para resolvido.
Durante a realização deste cenário, foram realmente encontrados tíquetes criados na
fila snort, que foram enviados pelo roteiro encarregado desta tarefa, com registros de
atividades suspeitas como ataques de exploração através de shellcode. Os passos descritos
acima foram seguidos sem problemas. Este cenário é muito semelhante à atividade de analise
de um relatório de registros do Iptables.
6.2.3
Cenário 3 – Incidentes reportados por usuários
Neste cenário é simulada a criação de um tíquete por um usuário na fila Incident
Report, onde o mesmo reporta um incidente ocorrido em sua estação de trabalho. Este
incidente consiste na contaminação da estação do usuário por um vírus, onde o usuário ficou
sabendo desta informação porque foi alertado pelo sistema antivírus instalado em sua estação.
1.
Usuário envia uma mensagem de correio eletrônico para o endereço que
aponta para a fila Incident Report, nesta mensagem ele informa que recebeu
uma notificação do sistema antivírus instalado em sua maquina, informando
que a estação esta infectada pelo vírus Worm_Bagle.
2.
Um membro do grupo se apropria do tíquete criado pelo usuário na fila
Incident Reports e cria um novo tíquete ligado a este na fila Incident.
3.
É passado para o usuário através de registro no tíquete, feito pelo membro
do grupo, o procedimento que deve ser seguido para a remoção deste vírus
utilizando a ferramenta antivírus que está instalada na estação do usuário.
4.
O usuário pode comentar o tíquete do incidente através da interface do RTIR
ou informar o membro do grupo que a remoção do vírus foi feita com
sucesso.
5.
O membro do grupo poderia abrir um tíquete na fila Investigations, caso
fosse necessário investigar o motivo pela qual a máquina foi infectada e
registrar neste tíquete os resultados da investigação.
6.
O membro do grupo então muda o estado dos dois tíquetes criados neste
caso para resolvido.
Os passos acima foram seguidos sem nenhum problema.
6.2.4
Cenário 4 – Notificação de parada de servidor ou serviço
pelo Nagios
Este cenário apresenta a simulação de uma parada no serviço VNC para que o Nagios
identifique o problema e envie uma mensagem de correio eletrônico para um endereço que
aponta para a fila nagios dentro do RTIR.
1.
O serviço VNC é interrompido propositalmente, simulando a sua falha.
50
2.
O Nagios identifica o problema no serviço e após três checagens indicando
que a conexão foi recusada, ele inicia o processo de notificação enviando
uma mensagem de correio eletrônico para o responsável pela administração
do serviço e outro para o endereço que aponta para a fila nagios dentro do
RTIR e nesta fila é criado um tíquete.
3.
Um membro do grupo que esta observando o sistema RTIR, verifica que um
novo tíquete foi criado na fila nagios e se apropria do tíquete.
4.
O membro do grupo então entra em contato com o administrador do servidor
e o mesmo informa que já esta ciente do problema, pois já foi notificado
pelo Nagios, e já esta solucionando o problema que ocorreu devido a uma
falha de alocação de memória pelo sistema operacional.
5.
O membro do grupo abre um tíquete na fila Incindent ligado ao tíquete
criado na fila nagios e registra neste tíquete as informações passadas pelo
administrador, como mostra a figuras 6.5.
Figura 6.5 – Criação manual de um tíquete na fila Incidents
6.
O administrador coloca o VNC para funcionar reiniciando o seu processo.
7.
O Nagios identifica a recuperação do serviço VNC e envia uma notificação
para o administrador e para o RTIR na fila nagios, informando que o serviço
VNC voltou a funcionar.
8.
O membro do grupo que está aguardando a criação do tíquete de Recovery
que deve ser enviado pelo Nagios percebe que o mesmo foi criado e então
ele se apropria deste tíquete, faz a ligação dele com o tíquete da fila Incident
51
que referencia o problema e muda o estado destes três tíquetes para
resolvido. Um exemplo de um destes tíquetes é mostrado na figura 6.6.
Figura 6.6 – Resolução do tíquete para o problema no serviço VNC
O resultado deste teste foi satisfatório uma vez que o sistema cumpriu com as tarefas
propostas, fazendo as notificações e criando o tíquete para o problema dentro do sistema. Os
passos descritos acima ocorreram sem problemas.
7 CONCLUSÃO
Neste trabalho foi feita a descrição dos principais contextos para o processo de
resposta a incidentes de segurança em computadores, os incidentes são o início da corrente, o
segundo elo seriam as respostas a incidentes que por sua vez estão ligadas e precisam do
terceiro elo que é um grupo de resposta a incidentes para que sejam eficazes.
Com a pesquisa realizada foi possível identificar uma forma de automatizar o processo
de respostas a incidentes com o auxílio de sistemas de código fonte aberto que rodam em
sistema operacional Linux e possibilitam a realização de tarefas importantes neste processo,
porém a principal dificuldade para a classificação automática de um incidente de segurança é
a complexidade em definir o quanto um ataque pode ser perigoso ou não. Um ataque pode ser
feito através de diversas técnicas diferentes e isto é o que dificulta a sua classificação. Então a
forma encontrada para fazer esta classificação que será a importância do incidente, foi
atribuindo uma classificação inicial aos incidentes reportados pelas ferramentas, esta
classificação está atrelada a fila em que o tíquete é criado. Dependendo da fila o tíquete pode
ter uma classificação maior ou menor, mas ainda é importante a analise de um especialista no
assunto para que a correta classificação seja atribuída.
Outra questão que é muito importante salientar é que um sistema de reposta a
incidentes, por mais automático que seja, sempre vai precisar da intervenção de pessoas e
estas pessoas devem estar preparadas para lidar com incidentes da melhor forma possível,
devem ter pelo menos a noção da política de segurança e da política de uso aceitável da
organização. Por isto estarão disponíveis no sistema estas duas informações importantes da
organização.
Sem dúvidas a eficiência de uma reposta a um incidente de segurança vai depender do
grupo de respostas a incidentes de segurança em computadores. Este sistema poderá ajudar
em muito no aumento desta eficiência na medida que o mesmo disponibiliza informações
importantes para o processo de respostas a incidentes e faz uma classificação automática dos
incidentes. Com o sistema também será mais fácil de gerenciar a resposta a incidentes e com o
armazenamento destas informações uma base de conhecimento é constituída, que pode servir
como referência para futuros incidentes.
Com as informações armazenadas também poderão ser elaborados relatórios com
dados estatísticos que podem ser utilizados como fonte de pesquisa para o planejamento de
atividades pró-ativas pelo grupo de resposta a incidentes de segurança em computadores.
Não pode ficar de fora desta conclusão a notável contribuição das comunidades de
desenvolvedores de sistemas de código aberto, pois a evolução destes sistemas nos últimos
anos tem sido muito grande, principalmente na área de segurança da informação, surgindo
assim diversas alternativas aos sistemas proprietários, e com isto possibilitando a integração
53
destes sistemas devido a grande quantidade de documentação de qualidade disponível e
também a possibilidade de agregação de valores, onde estudantes e desenvolvedores podem
estar contribuindo com melhorias e novas funcionalidades na integração destes sistemas,
como no caso do sistema proposto neste trabalho.
Como trabalhos futuros poderiam ainda ser acrescentada uma lista de endereços de
redes bloqueados pelo módulo SnortSam do detector de intrusos, pois os bloqueios são
temporários. Também seria interessante existir um cadastro de recursos da organização como
servidores, sistemas críticos, documentos eletrônicos importantes e outros mais, dentro do
sistema RTIR. Pois apesar de o Nagios possuir as informações dos servidores e serviços, estas
informações acabam ficando em um sistema diferente do utilizado para controlar as
requisições, o que da um pouco mais de trabalho na hora da consulta e também pelo fato de
não poderem ser cadastras informações como documentos no Nagios.
ANEXO A – MODELO DE POLÍTICA DE SEGURANÇA
Sumário
Prefácio
1. Introdução
1.1 O que é Informação?
1.2 O que é segurança da informação?
1.3 O que é uma política de segurança?
1.4 A empresa e a política de segurança
1.5 O não cumprimento dessas políticas
2. Educação e segurança
2.1 Autenticação
2.1.1 Política de senhas
2.2 E-mails
2.2.1 Política de e-mails
2.3 Internet
2.3.1 Política de Internet
3. Estações de trabalho
3.1 Política de uso de estações de trabalho
4. Social
5. Vírus e códigos maliciosos
6. Continuidade de negócios
Prefácio
Esse documento tem caráter particular e secreto, não podendo ou devendo ser redistribuído sem
prévia autorização e supervisão dos responsáveis pelo departamento de segurança, sendo a infração
passível de punição pelas regras internas, bem como ações legais (7).
1. Introdução
A segurança é um dos assuntos mais importantes dentre as preocupações de qualquer empresa.
Confidencialidade, integridade e disponibilidade da informação estão diretamente ligados à
segurança.
Temos nesse documento um conjunto de instruções e procedimentos para normatizar e melhorar
nossa visão e atuação em segurança.
1.1 O que é informação?
A Informação é um ativo que, como qualquer outro importante para os negócios, tem um valor para a
organização e conseqüentemente necessita ser adequadamente protegida.
A informação pode existir de diversas formas. Ela pode ser impressa ou escrita em papel,
armazenada eletronicamente, transmitida pelo correio ou através de meios eletrônicos, mostrada em
filmes, ou falada em conversas. Seja qual for a forma pela qual a mesma é apresentada, transmitida,
armazenada ou compartilhada, é recomendado que a mesma seja protegida adequadamente.
55
1.2 O que é segurança da informação?
A Segurança da Informação protege a Informação de diversas ameaças para garantir a continuidade
dos negócios, a integridade e a disponibilidade da mesma.
1.3 O que é uma Política de Segurança?
Política de Segurança é uma série de normas internas padronizadas pela empresa que devem ser
seguidas à risca para que todas as possíveis ameaças sejam minimizadas e combatidas
eficientemente pela equipe de segurança.
1.4 A empresa e a política de segurança
Todas as normas aqui estabelecidas serão seguidas à risca por todos os funcionários, parceiros e
prestadores de serviços. Ao receber essa cópia da Política de Segurança, o/a sr/sra comprometeu-se
a respeitar todos os tópicos aqui abordados e está ciente de que seus e-mails e navegação na
internet/intranet podem estar sendo monitorados. A equipe de segurança encontra-se a total
disposição para saneamento de dúvidas e auxílio técnico.
1.5 O não cumprimento dessa política
O não comprimento dessas políticas acarretará em <INSIRA AQUI AS PENAS>
2. Educação e segurança
Todo funcionário deve ser treinado adequadamente para as questões de segurança. Nenhum prérequisito técnico é necessário, visto que o treinamento abordará o contexto comportamental do
usuário, e não os aspectos técnicos, os quais serão delegadas as equipes especializadas.
2.1 Autenticação
A autenticação nos sistemas de informática pode ser baseada nos seguintes aspectos:
* Algo que você sabe;
Ou seja, uma senha.
* Algo que você tem;
Normalmente são pequenos dispositivos conhecidos como TOKENS. Podem ser smart-cards,
cartões magnéticos, java-rings, etc.
* Algo que você é;
Conhecido também como identificação biométrica. Podemos citar como exemplo a leitura de
impressão digital ou íris.
Em mais de 90% dos casos, atualmente, a autenticação é feita por meio de algo que você sabe. Esse
meio é muito utilizado por sua facilidade de implantação e manutenção e por seu baixíssimo custo.
Infelizmente esse meio também é o mais inseguro.
Senhas como nome do usuário, combinações simples (abc123), substantivos (casa, meia, cadeira,
brasil), datas (11092001) e outros são extremamente fáceis de descobrir. As senhas citadas acima,
por exemplo, podem ser quebradas em menos de 30 segundos por um potencial invasor.
2.1.1 Política de senhas
Uma senha segura deverá conter no mínimo 6 caracteres alfanuméricos (letras e números) com
diferentes caixas.
Para facilitar a memorização das senhas, utilize padrões mnemônicos.
Por exemplo:
eSus6C (eu SEMPRE uso seis 6 CARACTERES)
9SSgianc (9 Senhas Seguras garantem integridade a nossa corporação)
s3Nh45 (palavra senha onde o 3 substitui o E, o 4 o A e o 5 o S)
As senhas terão um tempo de vida útil pré-determinado pela equipe de segurança, devendo o mesmo
ser respeitado, caso contrário o usuário ficará sem acesso.
Todas as senhas serão testadas diariamente pela equipe de segurança em busca de fragilidades.
LEMBRE-SE:
56
- Sua senha não deve ser jamais passada a ninguém, nem mesmo da equipe de segurança. Caso
desconfie que sua senha não está mais segura, sinta-se à vontade para mudá-la, mesmo antes do
prazo determinado de validade.
- Tudo que for executado com a sua senha será de sua inteira responsabilidade, por isso tome todas
as precauções possíveis para que fique secreta.
2.2 E-mails
Grande parte de nossa comunicação do dia-a-dia passa através de e-mails. Mas é importante
também lembrar que grande parte das pragas eletrônicas atuais chega por esse meio.
Devemos lembrar que os vírus atuais são mandados automaticamente. Isso significa que um e-mail
de um cliente, parceiro ou amigo NÃO FOI MANDADO NECESSARIAMENTE PELO MESMO.
2.2.1 Política de e-mail
Nossos servidores de e-mail encontram-se protegidos contra vírus e códigos maliciosos, mas
algumas atitudes do usuário final são requeridas:
- Não abra anexos com as extensões .bat, .exe, .src, .lnk e .com se não tiver certeza absoluta de que
solicitou esse e-mail
- Desconfie de todos os e-mails com assuntos estranhos e/ou em inglês. Alguns dos vírus mais
terríveis dos últimos anos tinham assuntos como: ILOVEYOU, Branca de neve pornô, etc.
- Não reenvie e-mails do tipo corrente, aviso de vírus, avisos da Microsoft/AOL/Symantec, criança
desaparecida, criança doente, pague menos em alguma coisa , não pague alguma coisa, etc.
- Não utilize o e-mail da empresa para assuntos pessoais.
- Não mande e-mails para mais de 10 pessoas de uma única vez (to, cc, bcc)
- Evite anexos muito grandes
- Utilize sempre sua assinatura criptográfica para troca interna de e-mails e quando necessário para
os e-mails externos também
2.3 Internet
A internet é indiscutivelmente nossa mais poderosa ferramenta de trabalho. Devemos encará-la
dessa forma somente dentro da empresa.
O uso recreativo da internet não deverá se dar no horário de expediente.
2.3.1 Política de Internet
O uso e acesso à internet serão restritos aos seguintes tópicos:
- Somente navegação de sites é permitida. Casos específicos que exijam outros protocolos deverão
ser solicitados diretamente a equipe de segurança com prévia autorização do supervisor do
departamento local.
- Acesso a sites com conteúdo pornográfico, jogos, bate-papo, apostas e assemelhados estará
bloqueado e monitorado
- É proibido o uso de ferramentas P2P (kazaa, Morpheus, etc)
- É proibido o uso de IM (Instant messengers) não homologados/autorizados pela equipe de
segurança
Lembrando novamente que o uso da internet estará sendo auditado constantemente e o usuário
poderá vir a prestar contas de seu uso.
3. Estações de trabalho
Cada estação de trabalho tem códigos internos que permitem que ela seja identificada na rede, e
cada indivíduo possui sua própria estação de trabalho. Isso significa que tudo que venha a ser
executado de sua estação acarretará em responsabilidade sua. Por isso sempre que sair da frente de
sua estação, tenha certeza que efetuou logoff ou travou o console.
57
3.1 Política de uso de estação de trabalho
Lembramos que sua estação é sua ferramenta de trabalho, mas também é um importante
componente de segurança. Por isso observe as seguintes orientações:
- Não instale nenhum tipo de software / hardware sem autorização da equipe técnica ou de segurança
- Não tenha MP3, filmes, fotos e softwares com direitos autorais ou qualquer outro tipo de pirataria
- Mantenha na sua estação somente o que for supérfluo ou pessoal. Todos os dados relativos à
empresa devem ser mantidos no servidor, onde existe um sistema de backup diário e confiável. Caso
não saiba como fazer isso, entre em contato com a equipe técnica.
4. Social
Como seres humanos, temos a grande vantagem de sermos sociáveis, mas muitas vezes quando
decorremos sobre segurança, isso é uma desvantagem. Por isso observe os seguintes tópicos:
- Não fale sobre a política de segurança da empresa com terceiros ou em locais públicos.
- Não diga sua senha para ninguém. Nossa equipe técnica jamais irá pedir sua senha.
- Não digite suas senhas ou usuários em máquinas de terceiros, especialmente fora da empresa.
- Somente aceite ajuda técnica de um membro de nossa equipe técnica previamente apresentado e
identificado.
- Nunca execute procedimentos técnicos cujas instruções tenham chego por e-mail.
- Relate a equipe de segurança pedidos externos ou internos que venham a discordar dos tópicos
anteriores.
5. Vírus e códigos maliciosos
São os maiores geradores de problemas de segurança. Somente no ano de 2002, geraram prejuízos
da ordem de 53 bilhões de dólares. Alguns procedimentos simples podem evitar grandes transtornos:
- Mantenha seu antivírus atualizado. Provavelmente nossa equipe técnica irá se encarregar disso,
mas caso não tenha sido feito ou você perceba que a atualização não está funcional, entre em
contato com a mesma para que a situação possa ser corrigida.
- Não traga disquetes ou CDs de fora da empresa. Caso isso seja extremamente necessário,
encaminhe o mesmo para a equipe técnica, onde passará por uma descontaminação
- Reporte atitudes suspeitas em seu sistema à equipe técnica, para que possíveis vírus possam ser
identificados no menor espaço de tempo possível.
- Suspeite de softwares que "você clica e não acontece nada"
6. Continuidade de negócios
De nada adianta uma informação segura se a mesma estiver indisponível para quem necessita dela.
Por isso nossas equipes técnicas e de segurança contam com a sua colaboração para manter nossa
empresa como líder de mercado. Entre em contato conosco sempre que julgar necessário.
6.1 Membros da equipe técnica
Nome
Fulano
E-mail
Ramal
Celular
[email protected]
123
9999-9991
Beltrano
[email protected]
124
9999-9992
6.2 Membros da equipe de segurança
58
Nome
Ciclano
Irmano
E-mail
Ramal
Celular
[email protected]
911
9999-0911
[email protected]
912
9999-0912
59
ANEXO B – MODELO DE POLÍTICA DE USO ACEITÁVEL
Política de uso aceitável
A <nome da organização> não autoriza o uso de suas redes de computadores para os seguintes fins:
• transmitir ou divulgar ameaças, pornografia infantil, material racista, discriminatório ou qualquer
outro que viole a legislação em vigor no Brasil;
• propagar vírus de computador ou qualquer programa de computador que possa causar danos
permanentes ou temporários em equipamentos de terceiros;
• transmitir tipos ou quantidades de dados que possam causar falhas em serviços ou equipamentos
na rede da <nome da organização> ou de terceiros;
• utilizar computadores ou a rede de computadores da <nome da organização> para efetuar
levantamento de informações não autorizado (SCAN) na rede de computadores da <nome da
organização> ou de terceiros;
• uso da rede de computadores da <nome da organização> para o trânsito de mensagens de e-mail
com cabeçalhos inválidos ou alterados, de forma a dificultar ou impedir a identificação da sua origem,
ou mensagens enviadas através de servidores de e-mail de terceiros, sem a autorização dos
respectivos responsáveis (relaying);
• usar a rede para tentar e/ou realizar acesso não autorizado a dispositivos de comunicação,
informação ou computação;
• utilização dos computadores e redes de computadores da <nome da organização> para a coleta de
endereços de e-mail dos seus clientes.
• forjar endereços Internet de máquinas, de rede ou de correio eletrônico, na tentativa de
responsabilizar terceiros ou ocultar a identidade ou autoria;
• destruir ou corromper dados e informações de terceiros;
• violar a privacidade de terceiros;
• distribuir, via correio eletrônico, grupos de discussão, fóruns e formas similares de comunicação
mensagens não solicitadas do tipo 'corrente' e mensagens em massa, comerciais ou não;
• enviar grande quantidade de mensagens idênticas ao mesmo destinatário por correio eletrônico
(mail bombing);
• transmitir, distribuir ou armazenar materiais protegidos por direito autoral ou quaisquer outros
direitos de propriedade intelectual;
60
• quaisquer outros usos que violem a legislação vigente no Brasil.
A violação destas normas poderá resultar em suspensão temporária ou cancelamento dos serviços
prestados, além das demais medidas necessárias, incluindo, mas não se limitando à remoção de
dados, desativação de servidores e implementação de filtros.
Obedecendo as práticas definidas para a Internet, serão mantidos os endereços
[email protected] e [email protected] para servirem de canais de reclamação de
práticas abusivas vindas da rede de computadores da <nome da organização>. As pessoas que se
sentirem prejudicadas por pacotes de dados vindos de nossa rede devem denunciar a prática
enviando um e-mail para esses endereços com informações detalhadas, inclusive registros de
computadores (logs), sobre a prática abusiva.
61
ANEXO C – EXEMPLO DE RELATÓRIO DE
VULNERABILIDADES
Nessus Scan Report
-----------------SUMMARY
- Number of hosts which were alive during the test : 1
- Number of security holes found : 1
- Number of security warnings found : 3
- Number of security notes found : 7
TESTED HOSTS
192.168.1.1 (Security holes found)
DETAILS
+ 192.168.1.1 :
. List of open ports :
o netbios-ssn (139/tcp) (Security notes found)
o microsoft-ds (445/tcp) (Security notes found)
o pptp (1723/tcp) (Security notes found)
o ms-term-serv (3389/tcp) (Security warnings found)
o general/udp (Security notes found)
o netbios-ns (137/udp) (Security warnings found)
o unknown (4662/tcp) (Security warnings found)
o general/tcp (Security notes found)
o general/icmp (Security hole found)
. Information found on port netbios-ssn (139/tcp)
An SMB server is running on this port
. Information found on port microsoft-ds (445/tcp)
A CIFS server is running on this port
. Information found on port microsoft-ds (445/tcp)
It was possible to log into the remote host using a NULL session.
The concept of a NULL session is to provide a null username and
a null password, which grants the user the 'guest' access
To prevent null sessions, see MS KB Article Q143474 (NT 4.0) and
62
Q246261 (Windows 2000).
Note that this won't completely disable null sessions, but will
prevent them from connecting to IPC$
Please see http://msgs.securepoint.com/cgi-bin/get/nessus-0204/50/1.html
All the smb tests will be done as ''/'' in domain MATX
CVE : CAN-1999-0504, CAN-1999-0506, CVE-2000-0222, CAN-1999-0505,
CAN-2002-1117
BID : 494, 990, 11199
. Information found on port microsoft-ds (445/tcp)
The remote native lan manager is : Windows 2000 LAN Manager
The remote Operating System is : Windows 5.1
The remote SMB Domain Name is : MATX
. Information found on port pptp (1723/tcp)
A PPTP server is running on this port
Firmware Revision:2600
Host name:
Vendor string:Microsoft Windows NT
. Warning found on port ms-term-serv (3389/tcp)
The Terminal Services are enabled on the remote host.
Terminal Services allow a Windows user to remotely obtain
a graphical login (and therefore act as a local user on the
remote host).
If an attacker gains a valid login and password, he may
be able to use this service to gain further access
on the remote host. An attacker may also use this service
to mount a dictionnary attack against the remote host to try
to log in remotely.
Note that RDP (the Remote Desktop Protocol) is vulnerable
to Man-in-the-middle attacks, making it easy for attackers to
steal the credentials of legitimates users by impersonating the
Windows server.
Solution : Disable the Terminal Services if you do not use them, and
do not allow this service to run across the internet
Risk factor : Medium
CVE : CVE-2001-0540
BID : 3099, 7258
. Information found on port general/udp
For your information, here is the traceroute to 192.168.1.1 :
192.168.1.100
192.168.1.1
. Warning found on port netbios-ns (137/udp)
The following 4 NetBIOS names have been gathered :
METADEX
= This is the computer name registered for workstation
63
services by a WINS client.
METADEX
= Computer name
MATX
= Workgroup / Domain name
MATX
= Workgroup / Domain name (part of the Browser elections)
The remote host has the following MAC address on its adapter :
00:0e:a6:3b:2c:18
If you do not want to allow everyone to find the NetBios name
of your computer, you should filter incoming traffic to this port.
Risk factor : Medium
CVE : CAN-1999-0621
. Warning found on port unknown (4662/tcp)
eDonkey might be running on this port. This peer to peer
software is used to share files.
1. This may be illegal.
2. You may have access to confidential files
3. It may eat too much bandwidth
* Note: This script only checks if ports 4661-4663 are open
*
and are unknown services.
Solution: disable it
Risk factor : Medium
. Information found on port general/tcp
The remote host is running Microsoft Windows XP
. Vulnerability found on port general/icmp :
The remote host is vulnerable to an 'Etherleak' the remote ethernet driver seems to leak bits of the
content of the memory of the remote operating system.
Note that an attacker may take advantage of this flaw
only when its target is on the same physical subnet.
See also : http://www.atstake.com/research/advisories/2003/a010603-1.txt
Solution : Contact your vendor for a fix
Risk factor : High
CVE : CAN-2003-0001
BID : 6535
64
ANEXO D – EXEMPLO DE RELATÓRIO DE ANALISE DOS
REGISTROS DO FIREWALL
fwlogwatch summary
Generated Sunday November 21 12:00:07 BRST 2004 by root.
3946 of 4164 entries in 2 input files are packet logs, 691 have unique characteristics.
2 entries were excluded by configuration.
First packet log entry: Nov 21 00:16:03, last: Nov 21 11:59:56.
All entries were logged by the same host: "metacortex".
All entries have the same target: "-".
Only entries with a count of at least 25 are shown.
Rule 9 - Catch all rule eth1 104 udp packets from 192.168.1.100 (-) to 192.168.1.255 (-) port 137
(netbios-ns)
Rule 9 - Catch all rule eth1 282 udp packets from 192.168.1.100 (-) to 192.168.1.255 (-) port 138
(netbios-dgm)
Rule 9 - Catch all rule eth1 926 udp packets from 200.176.46.191 (cm-net-poaC8B02EBF.brdterra.com.br) to 192.168.1.255 (-) port 138 (netbios-dgm)
Rule 9 - Catch all rule eth0 54 tcp packets from 64.169.95.46 (adsl-64-169-9546.dsl.snfc21.pacbell.net) to 200.176.46.191 (cm-net-poa-C8B02EBF.brdterra.com.br) port 31041 (-)
Rule 9 - Catch all rule eth0 46 tcp packets from 65.71.231.253 (adsl-65-71-231253.dsl.rcsntx.swbell.net [forward lookup failed]) to 200.176.46.191 (cm-net-poaC8B02EBF.brdterra.com.br) port 31041 (-)
Rule 9 - Catch all rule eth0 26 tcp packets from 67.127.253.239 (adsl-67-127-253239.dsl.irvnca.pacbell.net) to 200.176.46.191 (cm-net-poa-C8B02EBF.brdterra.com.br) port 31041 (-)
Rule 9 - Catch all rule eth0 30 tcp packets from 68.79.205.252 (adsl-68-79-205252.dsl.emhril.ameritech.net) to 200.176.46.191 (cm-net-poa-C8B02EBF.brdterra.com.br) port 31041
(-)
Rule 9 - Catch all rule eth0 48 tcp packets from 69.177.209.81 (81.adsl.snet.net) to 200.176.46.191
(cm-net-poa-C8B02EBF.brdterra.com.br) port 31041 (-)
65
ANEXO E – EXEMPLO DE RELATÓRIO DE ANALISE DOS
REGISTROS DO DETECTOR DE INTRUSOS
subject: IDS Statistics generated on Sun Nov 21 12:15:18 2004
The logs begins from: Nov 21 00:16:56
The log ends at: Nov 21 12:14:10
Total of Lines in log file: 626
Total of Logs Dropped: 2 ( 0.32%)
Total events in table: 633
Source IP recorded: 28
Destination IP recorded: 30
NIDS recorded: 1 with 1 interface(s)
Signatures recorded: 12
Classification recorded: 6
Severity recorded: 4
Portscan recorded: 0
The distribution of event by protocols
==================================================
### 2 of 2 ###
% No
Protocols
==================================================
80.25 508 tcp
19.75 125
The distribution of severity
================================================================================================
### 4 of 4 ###
% No
Severity Graph
================================================================================================
79.46 503 high ###########################################################################
19.75 125
##################
0.63 4
medium
0.16 1
low
The distribution of attack by hour
===============================================================================================
### 13 of 13 ###
Hour No
% Graph
===============================================================================================
0h 7
1.11 #######
1h 3
0.47 ###
2h 43
6.79 #############################################
3h 56
8.85 ###########################################################
4h 65
10.27 ####################################################################
5h 56
8.85 ###########################################################
6h 67
10.58 ######################################################################
7h 57
9.00 ############################################################
8h 64
10.11 ###################################################################
9h 47
7.42 #################################################
10h 71
11.22 ##########################################################################
11h 51
8.06 #####################################################
12h 46
7.27 ################################################
66
Distribution of event by destination port
==============================
### 117 of 117 ###
% No
Port
==============================
34.91 221 4242
19.75 125
3.79 24
1863
2.53 16
1645
2.53 16
4662
2.37 15
5555
1.90 12
6699
0.79 5
1555
0.79 5
3106
0.63 4
80
0.63 4
1081
0.63 4
2387
0.63 4
2577
To see the popularity of one source host
======================================
### 28 of 28 ###
% No
IP source
======================================
44.08 279 200.176.46.191
19.75 125
9.79 62
24.110.206.222
6.00 38
201.8.190.38
4.27 27
217.84.136.235
2.53 16
207.46.108.76
2.53 16
62.158.55.11
1.74 11
81.67.106.10
1.58 10
82.125.6.114
1.58 10
83.114.117.125
1.42 9
68.122.0.53
Percentage and number of attacks from one host to any with same method
==============================================================================================
### 35 of 35 ###
% No
IP source
Attack
Severity
==============================================================================================
35.55 225 200.176.46.191 P2P eDonkey transfer {tcp}
high
19.75 125
(http_inspect) BARE BYTE UNICODE ENCODING
9.79 62
24.110.206.222 P2P eDonkey transfer {tcp}
high
6.00 38
201.8.190.38 P2P eDonkey transfer {tcp}
high
4.27 27
200.176.46.191 P2P Napster Client Data {tcp}
high
4.27 27
217.84.136.235 P2P eDonkey transfer {tcp}
high
2.84 18
200.176.46.191 CHAT MSN message {tcp}
high
2.53 16
207.46.108.76 CHAT MSN message {tcp}
high
2.53 16
62.158.55.11 P2P eDonkey transfer {tcp}
high
1.74 11
81.67.106.10 P2P Napster Client Data {tcp}
high
1.58 10
83.114.117.125 P2P eDonkey transfer {tcp}
high
1.42 9
68.122.0.53
P2P Napster Client Data {tcp}
high
0.63 4
221.139.83.165 P2P eDonkey transfer {tcp}
high
0.63 4
207.46.108.86 CHAT MSN message {tcp}
high
0.47 3
200.176.46.191 CHAT MSN user search {tcp}
high
0.47 3
83.27.171.124 P2P Napster Client Data {tcp}
high
0.47 3
200.176.46.191 CHAT MSN login attempt {tcp}
high
0.32 2
217.81.133.46 P2P Napster Client Data {tcp}
high
0.16 1
64.49.252.85 ATTACK-RESPONSES 403 Forbidden {tcp}
medium
0.16 1
200.176.46.191 WEB-IIS fpcount access {tcp}
medium
To see the popularity of one destination host
======================================
### 30 of 30 ###
% No
IP destination
======================================
36.18 229 200.176.46.191
19.75 125
13.11 83
24.110.206.222
7.42 47
201.8.190.38
6.79 43
217.84.136.235
67
2.69
1.90
1.74
1.58
1.58
1.42
0.79
0.79
0.63
17
12
11
10
10
9
5
5
4
207.46.108.76
62.158.55.11
81.67.106.10
82.125.6.114
83.114.117.125
68.122.0.53
221.139.83.165
82.207.76.195
211.207.195.228
Percentage and number of attacks to one host from any with same method
=======================================================================================
### 38 of 38 ###
% No
IP destination Attack
Severity
=======================================================================================
28.28 179 200.176.46.191 P2P eDonkey transfer {tcp}
high
19.75 125
(http_inspect) BARE BYTE UNICODE ENCODING
13.11 83
24.110.206.222 P2P eDonkey transfer {tcp}
high
7.42 47
201.8.190.38 P2P eDonkey transfer {tcp}
high
6.79 43
217.84.136.235 P2P eDonkey transfer {tcp}
high
4.27 27
200.176.46.191 P2P Napster Client Data {tcp}
high
3.16 20
200.176.46.191 CHAT MSN message {tcp}
high
2.53 16
207.46.108.76 CHAT MSN message {tcp}
high
1.90 12
62.158.55.11 P2P eDonkey transfer {tcp}
high
1.74 11
81.67.106.10 P2P Napster Client Data {tcp}
high
1.58 10
83.114.117.125 P2P eDonkey transfer {tcp}
high
1.58 10
82.125.6.114 P2P eDonkey transfer {tcp}
high
1.42 9
68.122.0.53
P2P Napster Client Data {tcp}
high
0.79 5
221.139.83.165 P2P eDonkey transfer {tcp}
high
0.79 5
82.207.76.195 P2P eDonkey transfer {tcp}
high
0.63 4
211.207.195.228 P2P eDonkey transfer {tcp}
high
0.47 3
83.27.171.124 P2P Napster Client Data {tcp}
high
0.32 2
217.81.133.46 P2P Napster Client Data {tcp}
high
high
The number of attacks from same host to same destination using same method
=============================================================================
### 58 of 58 ###
% No
IP source
IP destination Attack
=============================================================================
19.75 125
(http_inspect) BARE BYTE UNICODE ENCODING
13.11 83
200.176.46.191 24.110.206.222 P2P eDonkey transfer {tcp}
9.79 62
24.110.206.222 200.176.46.191 P2P eDonkey transfer {tcp}
7.42 47
200.176.46.191 201.8.190.38 P2P eDonkey transfer {tcp}
6.79 43
200.176.46.191 217.84.136.235 P2P eDonkey transfer {tcp}
6.00 38
201.8.190.38 200.176.46.191 P2P eDonkey transfer {tcp}
4.27 27
217.84.136.235 200.176.46.191 P2P eDonkey transfer {tcp}
2.53 16
200.176.46.191 207.46.108.76 CHAT MSN message {tcp}
2.53 16
207.46.108.76 200.176.46.191 CHAT MSN message {tcp}
2.53 16
62.158.55.11 200.176.46.191 P2P eDonkey transfer {tcp}
1.90 12
200.176.46.191 62.158.55.11 P2P eDonkey transfer {tcp}
1.74 11
200.176.46.191 81.67.106.10 P2P Napster Client Data {tcp}
1.74 11
81.67.106.10 200.176.46.191 P2P Napster Client Data {tcp}
1.58 10
200.176.46.191 83.114.117.125 P2P eDonkey transfer {tcp}
1.58 10
83.114.117.125 200.176.46.191 P2P eDonkey transfer {tcp}
The distribution of attack methods
=================================================================================================
### 12 of 12 ###
% No
Attack
Priority Severity
=================================================================================================
63.82 404 P2P eDonkey transfer {tcp}
1 high
19.75 125 (http_inspect) BARE BYTE UNICODE ENCODING
0
8.53 54
P2P Napster Client Data {tcp}
1 high
6.00 38
CHAT MSN message {tcp}
1 high
0.47 3
CHAT MSN login attempt {tcp}
1 high
0.47 3
CHAT MSN user search {tcp}
1 high
0.16 1
WEB-MISC robots.txt access {tcp}
2 medium
0.16 1
WEB-IIS fpcount attempt {tcp}
1 high
0.16 1
WEB-FRONTPAGE /_vti_bin/ access {tcp}
2 medium
0.16 1
WEB-IIS fpcount access {tcp}
2 medium
0.16 1
ATTACK-RESPONSES 403 Forbidden {tcp}
2 medium
0.16 1
INFO web bug 0x0 gif attempt {tcp}
3 low
68
The distribution of classification method
==============================================================================================
### 6 of 6 ###
% No
Classification
Severity
==============================================================================================
79.30 502 Potential Corporate Privacy Violation
high
19.75 125 http_inspect
0.47 3
access to a potentially vulnerable web application
medium
0.16 1
Web Application Attack
high
0.16 1
Misc activity
low
0.16 1
Attempted Information Leak
medium
Percentage and number of attacks by hour
=================================================================================================
### 44 of 44 ###
% No
Heure Attack
=================================================================================================
7.74 49
4h P2P eDonkey transfer {tcp}
7.58 48
10h P2P eDonkey transfer {tcp}
7.11 45
6h P2P eDonkey transfer {tcp}
6.95 44
8h P2P eDonkey transfer {tcp}
6.48 41
7h P2P eDonkey transfer {tcp}
6.16 39
5h P2P eDonkey transfer {tcp}
6.00 38
3h P2P eDonkey transfer {tcp}
5.37 34
11h P2P eDonkey transfer {tcp}
5.06 32
12h CHAT MSN message {tcp}
4.58 29
9h P2P eDonkey transfer {tcp}
4.11 26
2h P2P eDonkey transfer {tcp}
2.21 14
10h (http_inspect) BARE BYTE UNICODE ENCODING
2.21 14
3h (http_inspect) BARE BYTE UNICODE ENCODING
2.21 14
8h (http_inspect) BARE BYTE UNICODE ENCODING
2.05 13
5h (http_inspect) BARE BYTE UNICODE ENCODING
1.90 12
9h (http_inspect) BARE BYTE UNICODE ENCODING
1.90 12
6h (http_inspect) BARE BYTE UNICODE ENCODING
1.90 12
7h (http_inspect) BARE BYTE UNICODE ENCODING
1.74 11
12h P2P eDonkey transfer {tcp}
1.74 11
11h (http_inspect) BARE BYTE UNICODE ENCODING
Percentage and number of attacks to one destination port
=================================================================================================
### 122 of 122 ###
% No
Port Attack
=================================================================================================
34.91 221 4242 P2P eDonkey transfer {tcp}
19.75 125
(http_inspect) BARE BYTE UNICODE ENCODING
2.84 18
1863 CHAT MSN message {tcp}
2.53 16
1645 CHAT MSN message {tcp}
2.53 16
4662 P2P eDonkey transfer {tcp}
2.37 15
5555 P2P Napster Client Data {tcp}
1.90 12
6699 P2P Napster Client Data {tcp}
0.79 5
3106 P2P eDonkey transfer {tcp}
0.79 5
1555 P2P eDonkey transfer {tcp}
0.63 4
1081 CHAT MSN message {tcp}
0.63 4
2387 P2P eDonkey transfer {tcp}
0.63 4
2577 P2P eDonkey transfer {tcp}
0.47 3
4305 P2P eDonkey transfer {tcp}
0.47 3
2437 P2P eDonkey transfer {tcp}
0.47 3
1794 P2P eDonkey transfer {tcp}
Number of occurrences by type of log
=====================================================
### 2 of 2 ###
% No
Type
=====================================================
80.25 508 snort_signature
19.75 125 snort_processor
Version: 2.2.1
Jeremy CHARTIER, [email protected]
Date: 2004/04/30 17:19:00
69
ANEXO F – MODELO DE FORMULÁRIO PARA RESPOSTA
A INCIDENTES DE SEGURANÇA EM COMPUTADORES
!" " # $% " " &(')
*
+%,-/. !
0
" . 12
43 &1-
*5 !
41 1-
"" &!
" . 0$ "
416*!" # 1+7
8(9 (7
8! 0
%( !
$ " :
33;
8
(! $% !" 78
$%* " &(" . 1-*59
<3; # 17
8
"
9
(7
8!( (! $% " :
98
" . !
(!=8
" :
0
*!
" >
$%" ?@$
" A&
B " " . !
"
8 $%7C C" D
!
7C 416*!" 0$ 16 $C" 7%8E " $<1- " !
8
%+3;
$
(7
8
*( % (" ;
!
" . !"
F
<12A*!" 3;8
! $ !" !
7+169
!
$DC
)$
**(" C78 . !%;0;" . # $ "
" &;'E
*
G+ !
(
(78E$0**;0" H" >
$%" ?@$
" A&
I 890*; "0" . J1-*K" >
$" ?/$" &
# 17%8!(8
!9 " %(
*! :416!4LM" . +16*5" >NPOQ
O
R
SRT0ST
70
U 8
E$
" !
$"!
(
&!0 V%!" !
41-*(!" O
!
* >
&!
V!" !
* >
W $" " 7 8
$ . !
C9!
D &:
8
$!" 0:
&
7
8
9
$H!41-" 7 >
Q
*(! !
% >
" . 8*9
>
R
" . >
1 120$" X(!$ . 8 $%!" 1-
!
$ .. " Y . " !*(!
# G+ >
S
" *
V
>
T
8 %%1-80$" (41" . . " !
(9
!
C 0$ 16 $
!
9 >
I 8
$ <1" . " " !0$D
8 $%!" 1-
!
$ .. " O
. " !
* # G >
O
O" *
V
>
O
9
( $%" !
$" Z >
O W " *(!" $%"41 . !
&
$ " 1D%43( >
O
Q[\$ " 41+" . ( $ 0" $ 80;0!" 0:
*" . 041
" 8
:
" 8
" C :
%41-" 3!(%% !
!" $ . :0 " 8
" %8" 8" :
" ! C<1
8 !9
" <L " :
8$(41!
" " !
$D%:!
7
" . !"0 <12
*!
" 0 >
7 & . "
W !0& (X
;]\ " 7
REFERÊNCIAS
ANÔNIMO. Segurança Máxima. Rio de Janeiro: Ed. Campus, 2001. 686 p.
BP – Best Practical Solutions LLC. RT: Request Tracker. Sommerville, 2004. Disponivel
em: http://www.bestpractical.com
CHAPMAN, Brent e Zwicky, Elizabeth D. Building Internet Firewalls. Sebastopol:
O'Reilly & Associates, 1995. 517 p.
CHAPMAN, D. Brent, COOPER, Simon e ZWICKY, Elizabeth D. Building Internet
Firewalls, Second Edition. Sebastopol: O'Reilly & Associates, 2000. 890 p.
CHUVAKIN, Anthon; PEIKARI, Cyrus. Security Warrior. Sebastopol: O’Reilly &
Associates, 2004. 552 p.
LUCAS, Julie, MOELLER, Brian. The Effective Incident Response Team. Boston:
Addison Wesley, 2003. 336 p.
NIC BR Security Office. Cartilha de Segurança para Internet. Brasília: NBSO, 2003.
Disponível em: http://www.nbso.nic.br/docs/cartilha . Acesso em: 17 de abril, 2004.
OSBORNE, Tia R. Building an Incident Response Program To Suit Your Business.
Maryland: The Sans Institute, 2001.
REHMAN, Rafeeq Ur. Intrusion Detection Systems with Snort. New Jersey: Prentice Hall,
2003. 275 p.
SCHIFFMAN, Mike. Hacker’s Challenge: Test Your Incident Reposnse Skill Using 20
Scenarios. New York: MacGraw-Hill/Osborne, 2002. 355 p.
SCHULTZ, Dr. Eugene E., SHUMWAY, Russell. Incident Response: A Strategic Guide to
Handling System and Network Security. Indianapolis: New Riders Publishing, 2001. 400 p.
SCHWEITZER, Douglas. Incident Response: Computer Forensics Toolkit. New York:
Wiley Publishing, Inc., 2003. 362 p.
SHINDER, Debra L. Scene of the Cybercrime: Computer Forensic Handbook. Rockland:
Syngress Publishing, Inc., 2002. 718 p.
72
TANEMBAUM, Andrews S. Computer Networks, Fourth Edition. New Jersey: Prentice
Hall, 2003. 384 p.