desenvolvimento de um software web para …pericas/orientacoes/gerenciasnort2012.pdf · ids. snort....
TRANSCRIPT
UNIVERSIDADE REGIONAL DE BLUMENAU
CENTRO DE CIÊNCIAS EXATAS E NATURAIS
CURSO DE SISTEMAS DE INFORMAÇÃO – BACHARELADO
DESENVOLVIMENTO DE UM SOFTWARE WEB PARA
CONFIGURAR O SISTEMA DE DETECÇÃO DE INTRUSÃO
SNORT
EDUARDO DA SILVA MAES
BLUMENAU 2012
2012/1-04
EDUARDO DA SILVA MAES
DESENVOLVIMENTO DE UM SOFTWARE WEB PARA
CONFIGURAR O SISTEMA DE DETECÇÃO DE INTRUSÃO
SNORT
Trabalho de Conclusão de Curso submetido à Universidade Regional de Blumenau para a obtenção dos créditos na disciplina Trabalho de Conclusão de Curso II do curso de Sistemas de Informação — Bacharelado.
Prof. Francisco Adell Péricas - Orientador
BLUMENAU 2012
2012/1-04
DESENVOLVIMENTO DE UM SOFTWARE WEB PARA
CONFIGURAR O SISTEMA DE DETECÇÃO DE INTRUSÃO
SNORT
Por
EDUARDO DA SILVA MAES
Trabalho aprovado para obtenção dos créditos na disciplina de Trabalho de Conclusão de Curso II, pela banca examinadora formada por:
______________________________________________________ Presidente: Prof. Francisco Adell Péricas – Orientador, FURB
______________________________________________________ Membro: Prof. Paulo Fernando da Silva, Mestre - FURB
______________________________________________________ Membro: Prof. Mauro Marcelo Mattos, Doutor – FURB
Blumenau, 05 de julho de 2012.
Dedico este trabalho a minha família, amigos e todos que me ajudaram ao longo deste desafio.
AGRADECIMENTOS
A Deus, pelo seu imenso amor e graça.
À minha família, que esteve sempre presente.
Aos meus amigos, que contribuíram de alguma forma para a conclusão deste trabalho.
Ao meu orientador, Francisco Adell Péricas, por ter acreditado na conclusão deste
trabalho.
Aos professores do Departamento de Sistemas e Computação da Universidade
Regional de Blumenau por suas contribuições durante os semestres letivos.
Se enxerguei longe, foi porque me apoiei nos ombros de gigantes.
Isaac Newton
RESUMO
Este trabalho apresenta o desenvolvimento de um software com interface web para configurar
o software de detecção de intrusão Snort. Esta aplicação tem como objetivo permitir ao
administrador da rede maior facilidade no que diz respeito à configuração do Snort,
unificando as configurações do sistema em um único ambiente. Foi desenvolvido na
linguagem Ruby utilizando o framework Rails e banco de dados MySQL para armazenamento
das informações. Como resultado destaca-se a possibilidade do acompanhamento das
tentativas de intrusões na rede através de e-mails enviados ao administrador, permitindo assim
um acompanhamento em tempo real das ameaças detectadas.
Palavras-chave: Segurança. Invasão. Ameaças. IDS. Snort.
ABSTRACT
This paper presents the software development with a web interface for managing the Snort
software intrusion detection. This application aims to allow the most easiness network
administrator with respect to the management software Snort intrusion detection, centralizing
system settings in a single environment. It was developed in Ruby using the Rails framework
and MySQL database for storing the information. As a result destached it the possibility of
centralized monitoring of the network intrusion attempts, thus providing a real-time
monitoring.
Key-words: Security. Invasion. Threats. IDS. Snort.
LISTA DE ILUSTRAÇÕES
Figura 1: Fluxo de funcionamento do Snort.............................................................................21
Figura 2: Modo em Linha.........................................................................................................22
Figura 3: Modo Espelhamento de Porta ...................................................................................23
Figura 4: Exemplo do arquivo de configuração do Snort.........................................................24
Figura 5: Exemplo do arquivo de alertas do Snort ...................................................................25
Figura 6: Exemplo dos comandos para iniciar e parar o serviço do Snort ...............................25
Figura 7 – Diagrama de Entidade Relacionamento padrão do Snort .......................................26
Quadro 1: Requisitos funcionais...............................................................................................29
Quadro 2: Requisitos não funcionais........................................................................................30
Figura 8 – Caso de Uso ............................................................................................................31
Figura 9 – Diagrama de Atividade – Alterar Status Regra.......................................................31
Figura 10 – Diagrama de Atividade – Alterar Status Serviço Snort ........................................32
Figura 11 - Diagrama de Atividade – Adicionar/Remover Regra............................................33
Figura 12 – Criando estrutura MVC para Regras.....................................................................34
Figura 13 – Trecho do código fonte do controller de Configurações ......................................35
Figura 14 – Tela de login..........................................................................................................35
Figura 15 – Tela principal do software.....................................................................................36
Figura 16 – Tela de configurações de IP ..................................................................................36
Figura 17 – Tela de configurações de portas............................................................................37
Figura 18 – Tela de configurações avançadas ..........................................................................37
Figura 19 – Tela de gerenciamento do serviço Snort ...............................................................38
Figura 20 – Tela do gerenciamento de regras...........................................................................39
Figura 21 – Tela de gerenciamento de usuários .......................................................................39
Figura 22 – Tela de eventos......................................................................................................40
Quadro 3 – Comparativo entre o software desenvolvido e os demais sistemas.......................41
Quadro 4 - Caso de uso definir parâmetros de configuração do Snort.....................................46
Quadro 5 – Caso de uso adicionar/remover regras...................................................................47
LISTA DE SIGLAS
DAQ - Data Acquisition API
HIDS – Host Intrusion Detection System
HTTP – Hypertext Transfer Protocol
IDS – Intrusion Detection System
NIDS – Network Intrusion Detection System
IP – Internet Protocol
IPS – Intrusion Prevention System
OISF - Open Information Security Foundation
WAN – Wide Area Network
WEB – World Wide Web
SUMÁRIO
1 INTRODUÇÃO..................................................................................................................12
1.1 OBJETIVOS DO TRABALHO ........................................................................................13
1.2 ESTRUTURA DO TRABALHO......................................................................................13
2 FUNDAMENTAÇÃO TEÓRICA....................................................................................14
2.1 SEGURANÇA DA INFORMAÇÃO................................................................................14
2.2 SISTEMA DE DETECÇÃO DE INTRUSÃO..................................................................15
2.2.1 Assinaturas ......................................................................................................................17
2.2.2 Anomalias .......................................................................................................................18
2.2.3 Detecção Baseada em Especificação ..............................................................................19
2.3 SNORT..............................................................................................................................20
2.3.1 Captura de Pacotes ..........................................................................................................21
2.3.2 Pré-Processadores ...........................................................................................................23
2.3.3 Sistema de detecção ........................................................................................................23
2.3.4 Módulos de Extensão de Saída .......................................................................................24
2.4 INSTALAÇÃO PADRÃO DO SNORT ...........................................................................24
2.5 TRABALHOS CORRELATOS........................................................................................26
3 DESENVOLVIMENTO....................................................................................................28
3.1 LEVANTAMENTO DE INFORMAÇÕES......................................................................28
3.2 ESPECIFICAÇÃO ............................................................................................................29
3.2.1 Requisitos Funcionais .....................................................................................................29
3.2.2 Requisitos não funcionais ...............................................................................................29
3.2.3 Casos de uso....................................................................................................................30
3.2.4 Diagramas de atividades .................................................................................................31
3.3 IMPLEMENTAÇÃO ........................................................................................................33
3.3.1 Técnicas e ferramentas utilizadas....................................................................................33
3.3.2 Operacionalidade da implementação ..............................................................................35
3.4 RESULTADOS E DISCUSSÃO ......................................................................................40
4 CONCLUSÕES..................................................................................................................42
4.1 EXTENSÕES ....................................................................................................................42
REFERÊNCIAS BIBLIOGRÁFICAS .................................................................................44
APÊNDICE A – Descrição dos Principais Casos de Uso ....................................................46
12
1 INTRODUÇÃO
As informações são essenciais para o funcionamento dos negócios. Segundo Campos
(2006), a informação é um ativo da organização, ou seja, um bem que deve ser tão protegido
quanto os bens físicos, tendo em vista a sua importância para a própria existência da
organização.
São inúmeras as ameaças virtuais que têm como foco obter acesso a informações
corporativas. Segundo Stanger e Lane (2002), talvez a melhor maneira de garantir a segurança
do sistema seja fazer com que o sistema ou a rede informem sobre certas alterações.
O monitoramento é uma das formas para manter a integridade da rede e dos sistemas.
Cheswick, Bellovin e Rubin (2005) afirmam que é importante colocar sentinelas próximas às
coisas que se deseja proteger e um sistema de detecção de intrusão ajuda nessa função.
A definição de detecção de intrusão, segundo Anônimo (2000), é a prática de utilizar
ferramentas automatizadas e inteligentes para detectar tentativas de invasão em tempo real.
Essas ferramentas são chamadas de Sistemas de Detecção de Intrusão (Intrusion Detection
System - IDS).
Segundo Pimentel e Fagundes (2009), os sistemas de detecção de intrusão são
divididos em Host-Based Intrusion Detection System (HIDS) e Network-Based Intrusion
Detection System (NIDS). O HIDS é responsável pela proteção do sistema onde está
instalado, já o NIDS atua na proteção da rede.
Segundo Stanger e Lane (2002), um IDS pode enviar alertas ou tomar providências
apropriadas predefinidas para ajudar na proteção da rede.
Desta forma, este trabalho consiste em uma solução para unificar as configurações do
sistema de detecção de intrusão Snort. Trata de um software em plataforma web que facilita a
administração e a visualização das respostas obtidas através do monitoramento da rede, bem
como avisa através de envio de e-mail caso alguma ameaça seja detectada.
13
11..11 OOBBJJEETTIIVVOOSS DDOO TTRRAABBAALLHHOO
O objetivo geral do trabalho é apresentar um software com interface web para
configurar de forma unificada o sistema de detecção de intrusão Snort.
Os objetivos específicos do trabalho proposto são:
a) disponibilizar um sistema para configuração do IDS Snort;
b) permitir ativar e desativar regras de monitoramento;
c) notificar através de e-mails o administrador de rede caso alguma ameaça seja
detectada.
11..22 EESSTTRRUUTTUURRAA DDOO TTRRAABBAALLHHOO
Este trabalho está organizado em quatro capítulos, sendo que, no primeiro tem-se a
introdução, justificativa do trabalho, o objetivo geral e objetivos específicos, e como o
trabalho está estruturado.
No segundo capítulo é apresentada a fundação teórica bem como os assuntos que
serviram de base para o desenvolvimento do trabalho e a apresentação de trabalhos correlatos.
No terceiro capítulo está descrito o desenvolvimento do aplicativo, as técnicas e
ferramentas utilizadas bem como a elaboração de alguns diagramas para auxiliar na
compreensão do aplicativo, a operacionalidade, resultados e discussões.
No capítulo quatro apresenta-se a conclusão e extensão do trabalho.
14
2 FUNDAMENTAÇÃO TEÓRICA
Este capítulo aborda assuntos a serem apresentados nas seções a seguir, tais como,
Segurança da Informação, Sistema de Detecção de Intrusão, Snort e trabalhos correlatos.
22..11 SSEEGGUURRAANNÇÇAA DDAA IINNFFOORRMMAAÇÇÃÃOO
Segundo Wendt (2011), a Internet trouxe melhorias na comunicação e na interação
social jamais imagináveis. Com esse advento, também vieram as situações incidentes, de
vulnerabilidades de segurança e exploração de suas falhas. Grande parte dos serviços
essenciais estão disponíveis graças às redes de computadores, interligados e gerenciados
remotamente. A vulnerabilidade desses serviços frente à insegurança virtual é uma
preocupação, somente combatida com ações pró-ativas e de controle e monitoramento por
meio de análise de inteligência.
Segundo Dias (2000), na sociedade da informação, ao mesmo tempo que as
informações são consideradas o principal patrimônio de uma organização, elas estão também
sob constante risco como nunca estiveram antes. Com isso, a segurança de informações
tornou-se um ponto crucial para a sobrevivência das instituições.
Oliveira (2003) afirma que toda a informação tem valor e precisa ser protegida contra
acidentes e contra ataques de cibercriminosos, estes por sua vez estão cada vez mais
evidentes.
É comum a Segurança da Informação ser tratada como sendo responsabilidade
somente das grandes empresas. Segundo Fontes (2000), proteger a informação é uma
obrigação de toda organização, independente do seu tamanho.
A definição de Segurança da Informação, segundo Izquierdo (2007), é garantir que as
informações estejam protegidas contra o acesso por pessoas não autorizadas, estejam sempre
disponíveis quando necessárias, e que sejam confiáveis.
Partindo desde principio, pode-se afirmar que a Segurança da Informação baseia-se em
três principais pilares, que segundo Bon (2006) são:
a) confidencialidade: proteção das informações contra o acesso e uso não-
15
autorizados;
b) integridade: precisão, inteireza e pontualidade das informações;
c) disponibilidade: as informações devem ser acessíveis em qualquer ocasião
acordada. Essa acessibilidade depende da continuidade proporcionada pelos
sistemas de processamento de informações.
Também se deve considerar os aspectos secundários, que incluem a privacidade
(confidencialidade e integridade das informações que se referem a indivíduos), o anonimato e
a verificação (ser capaz de verificar se a informação é usada corretamente e se as medidades
de segurança são eficazes).
No contexto de gerir a segurança da informação, segundo Peixoto (2006), deve-se
levar em conta que os ativos têm que ser encarados minuciosamente como ponto chave para o
efetivo sucesso de administrar por onde passam, com quem passam e até onde chega essa
informação.
Os valores gastos com prejuízos ligados a segurança da informação estão cada vez
maiores. Segundo Paula (2011), uma pesquisa recente divulgada pela empresa Symantec
relata que o cibercrime tem causado prejuízos da ordem de US$ 300 bilhões por ano, sendo
que destes, 80% correspondem ao custo causado às vítimas dos crimes cibernéticos para se
recuperarem dos ataques e fraudes. E isto ocorre, visto que algumas organizações ainda
acham mais barato ressarcir as vítimas, do que investir de forma eficaz no setor de segurança
da informação.
Portanto, cada vez mais são necessárias medidas para combater as ameaças virtuais, e
prevenir que os sistemas administrados sejam comprometidos. Uma das medidas que se faz
necessária é a utilização de constante monitoramento, para que seja possível se antecipar aos
danos causados por ataques.
22..22 SSIISSTTEEMMAA DDEE DDEETTEECCÇÇÃÃOO DDEE IINNTTRRUUSSÃÃOO
Segundo Silva e Julio (2011), registros de invasões são notados diariamente aos
milhares por toda a Internet, assim como em redes locais cabeadas ou sem fio. Com a
constância no crescimento e na dependência dos ambientes computacionais de produção, das
mais diversas áreas, pela interligação de sistemas e acesso/armazenamento de dados de forma
16
segura, é necessário agir de forma a evitar a invasão de intrusos à rede. Porém, esta premissa
pode nem sempre ser verdadeira, o que faz do Sistema de Detecção de Intrusão uma
importante ferramenta no auxílio ao escopo de segurança da rede como um todo, uma vez que
age após a constatação de uma provável invasão.
Dias (2000) afirma que o monitoramento dos sistemas por meios de registros, trilhas
de auditoria ou outros mecanismos de detecção de invasão são essenciais à equipe responsável
pela segurança, já que é praticamente impossível eliminar por completo todos os riscos de
invasão pela identificação e autenticação de usuários.
Em empresas de pequeno e médio porte ainda é comum o administrador de rede ser
responsável também pelas tarefas pertencentes à área de Segurança da Informação. Por ter
que prestar serviços em duas áreas, administrar a rede e apoiar de certa forma o que diz
respeito a segurança da informação, é de grande importância a utilização de softwares para
auxiliar o processo de proteção ao perímetro administrado.
Segundo Batista e Pereira (2010), o funcionamento de um IDS é semelhante a um
sistema de detecção de ladrões usado em residências. Esse sistema é configurado para
especificar o que monitorar (janelas, portas, movimento) e para quem deve direcionar o alerta
(polícia, donos da casa, central de segurança eletrônica) em caso de entrada de um ladrão.
Com esta simples analogia pode-se assimilar de forma fácil o funcionamento básico de um
IDS, visto que basicamente atua de forma semelhante ao exemplo citado.
Deve-se ressaltar também que o IDS trata de um mecanismo de segunda linha de
defesa. Isto quer dizer que, somente quando há evidências de uma intrusão é que seus
mecanismos são utilizados. A primeira linha defensiva é aquela que tentará limitar ou impedir
o acesso ao ambiente, o que pode ser feito, por exemplo, por um firewall.
Segundo Pimentel e Fagundes (2009), os sistemas de detecção de intrusão são
classificados como Host-Based Intrusion Detection System (HIDS) e Network-Based
Intrusion Detection System (NIDS). O HIDS atua na proteção do sistema da máquina onde
está instalado e o NIDS atua na proteção da rede que a máquina está conectada.
Guimarães, Lins e Oliveira (2006) afirmam que os IDSs são excelentes mecanismos
que podem ser adicionados na arquitetura de defesa em profundidade de uma rede. Eles
podem ser utilizados para identificar fraquezas em seus dispositivos de proteção de perímetro,
como por exemplo, firewall e roteadores.
Dentre os sistemas de detecção de intrusão existentes no mercado, os mais conhecidos
são:
a) Suricata: um recente NIDS de código fonte aberto, desenvolvido pela Open
17
Information Security Foundation (OISF) e lançado inicialmente em 2010;
b) Prelude: é um framework desenvolvido pela CS Group caracterizado por atuar
como IDS híbrido que pode interoperabilizar as funções de um NIDS com um
HIDS, sendo em sua essência um NIDS. Tem a capacidade de encontrar ameaças
na rede em conjunto com outros tipos de sensores.
Tão importante quanto os demais, existe também o IDS Snort, que é o software base
para o funcionamento do aplicativo desenvolvido neste trabalho e será abordado adiante.
Conforme Silva e Julio (2011), o processo de detecção pode ser baseado em três
categorias: assinatura ou mau uso, anomalias, detecção baseada em especificação;
2.2.1 Assinaturas
Detectores deste tipo analisam as atividades do sistema procurando por eventos ou
conjuntos de eventos que correspondam a padrões pré-definidos de ataques e outras atividades
maliciosas.
Estes padrões são conhecidos como assinaturas. Segundo Silva e Julio (2011), cada
assinatura geralmente corresponde a um ataque ou outra atividade específica. É natural e
simples pensar em um exemplo típico deste tipo de evidência, onde o atacante tenta se
autenticar no sistema por meio de um acesso remoto, como por exemplo, o Secure Shell
(SSH), e erra a senha por mais de três vezes. Por meio de uma assinatura encontrada nos
registros do sistema, ou seja, a linha correspondente ao erro de autenticação, é então emitido
ao administrador um alerta.
A seguir são listadas as vantagens e desvantagens da utilização da detecção por
assinaturas ou mau uso:
a) vantagens:
são muito eficientes na detecção (comparando-se com a detecção baseada em
anomalias) sem gerar grande número de alarmes falsos;
a. podem diagnosticar o uso de uma ferramenta ou técnica específica de ataque;
b) desvantagens:
estes tipos de detectores somente podem detectar ataques conhecidos, ou seja, que
estão incluídos no conjunto de assinaturas que o IDS possui, necessitando assim de
constante atualização;
a maioria destes detectores possui assinaturas muito específicas, não detectando
18
dessa forma as variantes de um mesmo ataque.
2.2.2 Anomalias
Detectores baseados em anomalias identificam comportamentos não usuais em um
computador ou na rede. Eles funcionam a partir do pressuposto que ataques são diferentes da
atividade normal e assim podem ser detectados por sistemas que identificam estas diferenças.
Este tipo de detecção constrói um perfil que representa o comportamento normal de
usuário, nós e conexões de rede. Silva e Julio (2011) afirmam que este perfil é construído a
partir de dados coletados em um período de operação considerado normal, geralmente sob a
supervisão do administrador da rede em questão. Estes detectores monitoram a rede e usam
uma variedade de medidas para determinar quando os dados monitorados estão fora do
normal, ou seja, desviando do perfil.
Um exemplo a este tipo de detecção é quando um usuário específico utiliza sempre o
acesso à Internet durante certo período do dia, no horário comercial, por exemplo.
Este IDS passou uma semana analisando o comportamento e então criou o perfil deste
usuário e, a partir do último dia daquela semana, emprega seu perfil como mandatário ao
horário permitido de utilização da Internet. Certo dia, após a detecção estar ativa, o usuário
deseja utilizar o acesso à Internet durante a madrugada para entregar um relatório de última
hora, nada usual conforme o perfil criado. A resposta a esta detecção realizada pelo IDS
baseado em anomalia é o bloqueio do acesso à Internet para aquele usuário, que poderia ser
uma verdade se não houvesse esta exceção, porém foi tratada na verdade como um falso
positivo.
Infelizmente este tipo de detecção geralmente produzirá um grande número de
alarmes falsos, pois o comportamento de usuários e sistemas pode variar amplamente. Apesar
desta desvantagem, pesquisadores afirmam que a detecção baseada em anomalias pode
identificar novas formas de ataques, coisa que a detecção baseada em assinatura não pode
fazer. Além disso, algumas formas de detecção baseadas em anomalias produzem uma saída
que pode ser usada como fonte de informações para detectores baseados em assinaturas.
Por exemplo, um detector baseado em anomalias pode gerar um número que
representa a quantidade normal de arquivos acessados por um usuário particular, com isso um
detector baseado em assinaturas pode possuir uma assinatura que gera um alarme quando esse
19
número excede 10%, por exemplo.
Ainda que alguns IDSs comerciais incluam formas limitadas de detecção de
anomalias, poucos, se nenhum, confiam somente nesta tecnologia. As detecções de anomalias
existentes em sistemas comerciais geralmente giram em torno da detecção de scanners de
rede ou portas.
A seguir são listadas as vantagens e desvantagens da utilização da detecção por
anomalia:
a) vantagens:
detecta comportamentos não usuais, logo possui a capacidade de detectar sintomas
de ataques sem um conhecimento prévio deles;
produz informações que podem ser usadas na definição de assinaturas para
detectores baseados em assinaturas;
b) desvantagens:
geralmente produz um grande número de alarmes falsos devido ao comportamento
imprevisível de usuários e sistemas;
requer muitas sessões para coleta de amostra de dados do sistema, de modo a
caracterizar os padrões de comportamento normais.
2.2.3 Detecção Baseada em Especificação
Define um modelo muito mais complexo que os anteriores, já que sua análise pode ser
realizada nas camadas abaixo da camada de aplicação da pilha de protocolos da Internet ou no
nível de controle do sistema operacional. Segundo Julio e Silva (2011), ela se restringe à
operação correta de um programa ou protocolo, e monitora a execução do programa com
respeito à definição estipulada. Essa técnica pode fornecer a descoberta de ataques
previamente desconhecidos, com isso potencializando sua atividade, além de apresentar taxas
muito baixas de falsos positivos. Este modelo de detecção não é tão amplamente divulgado
como os demais, especialmente por sua maior complexidade de desenvolvimento e restrição à
aplicação que se destina, uma vez que ele visa, por exemplo, uma única aplicação.
Pode-se pensar em um exemplo para este modelo de detecção onde será realizada uma
pré-análise das chamadas de um servidor de FTP ao núcleo do sistema operacional. Todas as
chamadas, e principalmente as consideradas críticas ao sistema, são analisadas a fim de se
20
observar possíveis alterações posteriores com objetivos maliciosos. Este tipo de detecção é
considerado de mais baixo nível do que os demais, o que também requer um conhecimento
muito mais profundo das ações realizadas pelo programa a ser analisado assim como do
sistema operacional e das funções de rede.
22..33 SSNNOORRTT
Snort é um IDS de código-fonte aberto, desenvolvido na linguagem de programação C
e atua efetuando o monitoramento na rede (NIDS) podendo identificar ameaças através da
leitura do tráfego dos pacotes. Sua eficácia se faz também pelo envio de alerta em tempo real,
seja ele salvo em um arquivo, ou enviado a outro computador da rede, além de estar
disponível para várias plataformas. Foi criado inicialmente por Martin Roesch, e, segundo
Pimentel e Fagundes (2009), é conhecido por sua flexibilidade nas configurações de regras e
constante atualização frente às novas técnicas de invasão. Hoje o Snort é desenvolvido
oficialmente pela empresa SourceFire, criada por Roesch.
O recurso mais interessante do Snort, segundo Cheswick, Bellovin e Rubin (2005), é a
sua capacidade de definir um conjunto de regras que reconhece certos padrões de tráfego,
sendo que novas regras também podem ser encontradas na internet.
A Figura 1 ilustra o fluxo básico de funcionamento do Snort, desde a aquisição da
informação até a geração de um alerta. Estes passos estão descritos nas sessões seguintes.
21
Fonte: adaptado de Montoro (2012).
Figura 1: Fluxo de funcionamento do Snort
2.3.1 Captura de Pacotes
Atualmente o Snort utiliza o Data Acquisition API (DAQ) para aquisição de pacotes. O
DAQ substitui as chamadas diretas em bibliotecas de captura de pacotes como PCAP com
uma camada de abstração que tornam mais fácil integrar um software adicional ou
implementações de hardware de captura de pacotes. Segundo Montoro (2012), é importante
salientar que o local onde será instalado o IDS (aquisição dos pacotes) na topologia da rede é
o primeiro passo para o sucesso da implantação da ferramenta. Antes de instalá-lo é
necessário atentar-se para alguns pontos:
a) é de extrema importância saber o que se quer monitorar, visto que um sensor
dificilmente conseguirá monitorar tudo o que trafega na rede. Ou filtra-se o que
monitorar, ou opta-se por instalar mais de um sensor na topologia de rede;
b) a máquina (computador/servidor ou appliance) responsável pela coleta e leitura
dos pacotes deve ser escolhida de acordo com o fluxo de dados que trafega na
rede. Ou seja, quanto maior a quantidade de dados, maior desempenho deve
22
possuir o hardware responsável pela execução do Snort;
c) faz-se necessário saber quais protocolos monitorar para não desperdiçar ciclos de
processamento do Snort;
d) existem alguns meios de se copiar o tráfego da rede para o sensor, nos quais os
mais conhecidos são:
sensor em linha: o tráfego de rede passará pelo sensor antes de seguir adiante. A
Figura 2 demonstra a topologia deste cenário;
Figura 2: Modo em Linha
espelhamento de porta: os switchs gerenciáveis oferecem essa opção, que tem a
capacidade de copiar o tráfego de todas as portas e replicá-los para a porta onde
está conectado o sensor. A Figura 3 demonstra a topologia deste cenário.
23
Figura 3: Modo Espelhamento de Porta
network TAP - equipamento responsável por efetuar a cópia dos pacotes sem ter a
necessidade de utilizar recursos do switch para este fim. Segundo Montoro (2012),
este é o modelo mais indicado.
2.3.2 Pré-Processadores
Os pré-processadores basicamente são responsáveis por remontar os pacotes
capturados de maneira correta, para que através destes, caso o ataque utilize alguma técnica
para tentar burlar o monitoramento do IDS, seja possível diminuir falsos-negativos no
momento da comparação das assinaturas, trazendo assim maior confiabilidade a todo o
processo de detecção. O Snort possui dezenas de pré-processadores. Alguns deles são o
http_inspec, o stream5, o frag3, o dcerpc2, o ip_reputation.
2.3.3 Sistema de detecção
O sistema de detecção é responsável pela comparação dos dados tratados pelos pré-
processadores com as regras que são adquiridas através de compra, download da internet ou
criadas por conta própria. Nesta fase os dados reais já estarão separados do resto do pacote e
normalizados para comparar com as regras.
24
2.3.4 Módulos de Extensão de Saída
Os módulos de extensão de saída são ferramentas que podem ser utilizadas para enviar
alertas para outros recursos ou salvá-los em arquivo. Vários módulos podem ser ativados
simultaneamente para executar diferentes funções. Estes por sua vez devem ser bem
configurados para não interferirem no desempenho do IDS.
22..44 IINNSSTTAALLAAÇÇÃÃOO PPAADDRRÃÃOO DDOO SSNNOORRTT
O IDS Snort é instalado em um computador e configurado para monitorar a rede local.
A configuração do IDS Snort é feito através de edição de arquivos, onde estão os parâmetros
de configuração, como o caminho do diretório das regras, quais regras são carregadas para
monitoramento, quais as portas usadas para os principais serviços rodando na rede, qual parte
da rede será monitorada, dentre outras.
A Figura 4 demonstra uma parte do arquivo de configuração onde estão listadas as
regras a serem utilizadas, sendo que as que recebem o caractere “#” no início não são
iniciadas.
Figura 4: Exemplo do arquivo de configuração do Snort
A interação com o sistema é feita através de comandos disparados através do terminal
e a leitura dos registros salvos tem de ser feita manualmente, visualizando-se um arquivo que
25
contém os alertas através de um editor de texto ou então no próprio terminal através de um
comando para leitura de arquivo.
A Figura 5 demonstra uma parte do arquivo de alertas onde são salvos os registros das
detecções de ameaças feitas pelo sistema.
Figura 5: Exemplo do arquivo de alertas do Snort
Para interagir com o serviço do Snort também é necessário inserir comandos no
terminal, e assim, é possível parar ou iniciar o serviço responsável pelo seu funcionamento,
conforme mostra a Figura 6.
Figura 6: Exemplo dos comandos para iniciar e parar o serviço do Snort
Através destes comandos é possível recarregar regras e novas configurações, estas
também feitas manualmente conforme mostrado nas imagens anteriores.
A Figura 7 demonstra o diagrama de entidade relacionamento padrão do Snort. Este
schema acompanha os arquivos de instalação para ser importado para o banco de dados
durante este processo.
26
Fonte: adaptado de Danyliw (2001).
Figura 7 – Diagrama de Entidade Relacionamento padrão do Snort
22..55 TTRRAABBAALLHHOOSS CCOORRRREELLAATTOOSS
Existem alguns sistemas que fazem integração com o sistema de detecção de intrusão
Snort, porém, eles atuam na organização e apresentação dos registros de intrusões salvos, ou
diretamente no bloqueio das ameaças de intrusão, que são classificados como Intrusion
Prevention System (IPS).
Um exemplo de sistema que organiza os registros é o Snorby. Segundo Conrado
(2010), o Snorby é um front-end utilizado para visualizar os alertas gerados pelo Snort, que
também apresenta estatísticas dos alertas coletados através de gráficos. Possui uma interface
bastante intuitiva e moderna.
Neste mesmo modelo existe também o Basic Analysis and Security Engine (BASE),
que segundo Monte (2008), é uma ferramenta de navegação para análise de dados, construída
utilizando a linguagem de programação PHP. E o Barnyard, que segundo Flores (2004), é um
pós-processador dos registros gerados pelo snort no formato UNIFIED.
Em relação aos sistemas que atuam no bloqueio das ameaças de intrusão, há o
27
Guardian, que segundo Santos (2010), gera automaticamente regras de firewall para bloquear
os endereços de origem que estão atacando um servidor. E ele dá suporte a vários tipos de
firewalls, como por exemplo, o iptables. Este pode ser integrado ao Snort e através dos alertas
gerados, executa funções pré-definidas para conter de forma automática os ataques.
Ler os registros de forma manual não é uma maneira efetiva de realizar a segurança da
rede, portanto, além de permitir a consulta dos registros, o software desenvolvido neste
trabalho também dispõe de uma função de enviar os alertas via e-mail para um endereço pré-
configurado.
28
3 DESENVOLVIMENTO
Neste capítulo são apresentadas as características do aplicativo desenvolvido, através
de fluxogramas, especificações de requisitos funcionais e não-funcionais, o diagrama de caso
de uso e os principais diagramas de atividades. São descritas também as técnicas e
ferramentas utilizadas no processo de implementação, a operacionalidade do software e os
resultados obtidos.
33..11 LLEEVVAANNTTAAMMEENNTTOO DDEE IINNFFOORRMMAAÇÇÕÕEESS
O software consiste em uma solução web para auxiliar a administração do sistema de
detecção de intrusão, fazendo com que não seja necessária a edição de arquivos e o envio de
comandos via terminal. O administrador acessa o sistema via navegador através de uma
conexão segura autenticada por um usuário e uma senha, e através dele poderá visualizar e
editar os parâmetros de configuração, podendo assim alterar opções como endereços de IP da
rede interna e externa, para, por exemplo, informar ao IDS quais as rede devem ser
monitoradas. O software por sua vez deverá filtrar as entradas fornecidas pelo administrador,
e retornar erros caso não estejam no padrão esperado pelo Snort.
O software também deverá fornecer ao administrador a opção de parar e iniciar o
serviço do Snort, bem como as regras que entrarão em vigor para monitorar as ameaças da
rede, podendo ativá-las e desativá-las, oferecendo assim a alternativa de registrar somente as
informações pertinentes a sua necessidade.
Os registros salvos pelo Snort deverão ser mostrados de forma clara, facilitando o
entendimento dos alertas ao administrador e eliminando a necessidade de acesso a arquivos
externos.
Como terá uma interface web, será possível acessá-lo de qualquer computador que
esteja na mesma rede e possua um navegador, ou se o servidor estiver habilitado para receber
acessos externos, de qualquer computador com acesso a internet e que tenha um navegador
instalado.
29
33..22 EESSPPEECCIIFFIICCAAÇÇÃÃOO
Nesta seção são apresentados os principais requisitos funcionais (RF), requisitos não-
funcionais (RNF), casos de uso e diagramas de atividades. A descrição dos casos de uso pode
ser visualizada no Apêndice A.
3.2.1 Requisitos Funcionais
No Quadro 1 são apresentados os requisitos funcionais do aplicativo.
Requisitos Funcionais Caso de Uso
RF01: o software deverá controlar o acesso através de autenticação
usuário/senha.
UC01
RF02: o software deverá permitir ao administrador definir os
parâmetros de configuração do SNORT.
UC02
RF03: o software deverá permitir ao administrador iniciar/parar o
serviço do SNORT.
UC03
RF04: o software deverá permitir ao administrador ativar/desativar
regras de monitoramento.
UC04
RF05: o software deverá permitir ao administrador adicionar regras no
padrão esperado pelo Snort, e remove-las.
UC05
RF06: o software deverá permitir ao administrador visualizar os
registros de tentativas de intrusão.
UC06
RF07: o software deverá enviar e-mail ao administrador quando
identificar alguma intrusão.
UC07
Quadro 1: Requisitos funcionais
3.2.2 Requisitos não funcionais
O Quadro 2 lista os requisitos não-funcionais do aplicativo.
30
Requisitos Não Funcionais
RNF01: o software deverá rodar no sistema operacional Debian Linux versão 6.0.
RNF02: o software deverá utilizar o banco de dados MySQL versão 5.5.
RNF03: o software deverá utilizar o sistema de detecção de intrusão Snort integrado ao pós-
processador Barnyard.
RNF04: o software deverá ser implementado utilizando a linguagem de desenvolvimento
Ruby versão 1.9.3 sobre o framework Rails versão 3.2.3.
RNF05: o servidor HTTP deverá ser executado por um usuário do Linux com permissões
sobre os arquivos referentes ao Snort.
Quadro 2: Requisitos não funcionais
3.2.3 Casos de uso
Na Figura 8 pode-se verificar os casos de uso demonstrando a utilização do software.
O ator envolvido nestes casos de uso é o administrador, que tem acesso a todas as
funcionalidades do sistema. Os cenários dos casos de uso são apresentados no Apêndice A.
31
Figura 8 – Caso de Uso
3.2.4 Diagramas de atividades
Na Figura 9 pode-se verificar o diagrama de atividades demonstrando a alteração do
status de uma regra de monitoramento.
Figura 9 – Diagrama de Atividade – Alterar Status Regra
32
O diagrama acima demonstra o fluxo de atividade representando a ativação ou
desativação de uma das regras utilizadas pelo Snort. Ao acessar a tela de regras o cliente tem
a opção de selecioná-las e mudar os status.
Na Figura 10 pode-se verificar o diagrama de atividade demonstrando a alteração do
estado do serviço do Snort.
Figura 10 – Diagrama de Atividade – Alterar Status Serviço Snort
O diagrama acima demonstra o fluxo de atividade representando a alteração do status
do serviço do Snort. Caso o serviço do IDS esteja em execução, o software irá enviar um
comando ao sistema operacional para pará-lo. Em caso contrário o comando será para iniciar
o serviço.
Na Figura 11 pode-se verificar o diagrama de atividade demonstrando a adição e
remoção de uma regra.
33
Figura 11 - Diagrama de Atividade – Adicionar/Remover Regra
O diagrama acima demonstra o fluxo de atividade representando a adição de uma nova
regra, ou a remoção de uma regra já existente.
33..33 IIMMPPLLEEMMEENNTTAAÇÇÃÃOO
A seguir são mostradas as técnicas e ferramentas utilizadas e a operacionalidade da
implementação.
3.3.1 Técnicas e ferramentas utilizadas
O software foi desenvolvido utilizando a linguagem Ruby sobre o framework Rails.
Esse por sua vez permite a integração de módulos chamados de gem, sendo estes
desenvolvidos e escritos pela equipe de desenvolvimento do framework e também pela
comunidade e disponibilizados na internet.
Para implementação do software foi utilizado o editor de texto Gedit e o próprio
34
terminal do sistema operacional para interagir com o framework Ruby on Rails.
Para o armazenamento de dados foi utilizado o gerenciador de banco de dados
MySQL. Para aumentar a eficiência na gravação dos registros, foi utilizado o pós-processador
Barnyard, que é responsável por processar todos os registros gerados pelo Snort e armazená-
los em uma base de dados MySQL, fazendo com que o Snort foque somente na análise dos
pacotes gerados pelo tráfego na rede, reduzindo a carga do sistema e evitando a perda destes
pacotes.
Na Figura 12 visualiza-se a janela do terminal onde um comando do framework Rails
gerou alguns arquivos contendo partes padrões de códigos utilizando os conceitos de Model-
view-controller (MVC). Esses arquivos são responsáveis pelo funcionamento inicial das telas
de exibição e criação das regras de monitoramento.
Figura 12 – Criando estrutura MVC para Regras
Na Figura 13 visualiza-se o trecho do código fonte referente ao controller
“configurações”, responsável pela abertura do arquivo de configuração do Snort (snort.conf) e
a identificação das variáveis para exibição nos formulários existentes na tela “configurações”.
35
Figura 13 – Trecho do código fonte do controller de Configurações
3.3.2 Operacionalidade da implementação
Nesta sub-seção são apresentadas as telas do aplicativo e trechos de códigos relevantes.
O aplicativo possui somente um perfil de usuário, esse que dá direito de interagir com todas as
funcionalidades propostas pelo software desenvolvido.
A operacionalidade do aplicativo é inicialmente apresentada pela tela de login, onde o
administrador deve preencher o campo de e-mail e senha, como é apresentado na Figura 14.
Figura 14 – Tela de login
36
Após realizar o login, o usuário é redirecionado para tela principal, sendo que esta tela
pode ser visualizada na Figura 15.
Figura 15 – Tela principal do software
A Figura 14 possui na parte superior direita a informação de qual usuário está logado
ao sistema, identificando-o pelo e-mail utilizado na tela de login, e ao lado um botão de Sair
com a função de efetuar logoff do sistema. No centro da tela estão dispostas opções de menus
que redirecionam o administrador para cada opção desejada. A opção Sair do menu tem a
mesma função do botão sair informado anteriormente. Para acessar o formulário com as
configurações do Snort, deve-se clicar no botão “configurações” conforme demonstrado na
Figura 15. Ao clicar neste botão a tela da Figura 16 será exibida.
Figura 16 – Tela de configurações de IP
37
Nesta tela é possível editar as principais variáveis de configuração que serão
armazenadas no arquivo de configuração “snort.conf” e interpretadas pelo IDS. Na primeira
aba “configurações de ip” temos as definições de IPs utilizados pelos principais serviços que
podem estar rodando na rede, conforme já demonstrado na Figura 16. Ao clicar na segunda
aba “configurações de portas” será exibida a Figura 17.
Figura 17 – Tela de configurações de portas
Nesta tela é possível definir as portas padrões utilizadas pelos protocolos dos serviços
que rodam na rede.
Ao clicar na terceira aba “configurações avançadas” será exibida a Figura 18.
Figura 18 – Tela de configurações avançadas
38
Nesta tela é possível editar o arquivo de configuração “snort.conf” manualmente, caso
seja necessário mudar alguma variável protegida, ou seja, aquelas que não são aconselháveis
alterar, pois podem comprometer o funcionamento do IDS.
Após efetuar as alterações necessárias, deve-se clicar no botão “salvar”, localizado na
parte inferior da tela. Este processo altera as informações no arquivo de configuração do
Snort. Caso o botão cancelar seja pressionado, o usuário é redirecionado para a tela inicial do
sistema.
Para que as alterações entrem em vigor, deve-se reiniciar o serviço do Snort através da
opção “parar/iniciar serviço” mostrada na Figura 19. Esta opção está localizada na tela
“serviço”, que pode ser acessada através do botão com o mesmo nome na tela principal,
mostrada na Figura 15.
Figura 19 – Tela de gerenciamento do serviço Snort
Na Figura 20 é exibida a tela “regras”, que pode ser acessada através da opção do
menu com o mesmo nome localizado na tela inicial mostrado na Figura 15. Nesta tela é
possível visualizar a lista de regras utilizadas pelo Snort. Nas opções ao final de cada linha
pode-se ativar ou desativar, e também excluir as regras. Para inserir uma nova regra basta
clicar no botão “nova regra” localizado na parte superior da tela.
39
Figura 20 – Tela do gerenciamento de regras
Na Figura 21 é mostrada a tela “usuários”. Nesta tela são listados os usuários que tem
permissão para acessar o sistema, sendo possível editar suas informações e também adicionar
um novo usuário através do botão “novo usuário” localizado na parte superior da tela.
Figura 21 – Tela de gerenciamento de usuários
Na Figura 22 é mostrada a tela “eventos”. Nesta tela é possível visualizar os registros
de tentativas de intrusão coletados pelo Snort e salvos no banco de dados pelo pós-
processador Barnyard. Na parte superior da tela está o campo de filtro, onde é possível buscar
registros por informações específicas, como data, código da assinatura.
40
Figura 22 – Tela de eventos
33..44 RREESSUULLTTAADDOOSS EE DDIISSCCUUSSSSÃÃOO
O objetivo deste trabalho, de desenvolver um software para configurar o sistema de
detecção de intrusão Snort, foi alcançado. O software implementado unifica as principais
tarefas de configuração e utilização do IDS Snort, possibilitando maior facilidade e agilidade
nas necessidades envolvidas para administrá-lo. Através do aplicativo desenvolvido é possível
configurar o IDS de qualquer computador ligado à mesma rede do servidor em que ele está
rodando, dispensando a necessidade de editar vários arquivos de configuração ou ler arquivos
de registro. Com a centralização das informações e a facilidade de acesso, o software
possibilita também o monitoramento de forma ativa por parte do responsável pela
administração da rede, visto que, com o sistema de envio de e-mail em caso de detecção de
possível ameaça, não se tem a necessidade de ficar acompanhando os registros em tempo
integral.
Este software utiliza a linguagem de desenvolvimento Ruby, rodando sobre o
framework Rails para interagir com os alertas gerados pelo pós-processador Barnyard que
processa os registros de saída do Snort e os salva em uma base de dados MySQL. Todas essas
tecnologias e ferramentas são livres, o que implica que não existe a necessidade de adquirir de
licenças de utilização ou realizar qualquer tipo de pagamento. O aplicativo necessita de uma
máquina hospedeira, sendo ela física ou virtual, independente de qualquer outra ferramenta,
para poder processar todo o tráfego da rede.
41
Em relação aos trabalhos correlatos, verificam-se semelhanças com os sistemas
mencionados no decorrer deste trabalho, porém, além de listar os registros em questão, o
software também permite interação com o IDS. Estas comparações podem ser visualizadas no
Quadro 3.
Funcionalidades \ Softwares Snorby BASE Guardian Software Desenvolvido
Exibir Ameaças x x x
Quantificar Ameaças x x
Editar arquivo de configuração do
Snort
x
Adicionar/Remover regras do
Snort
x
Parar/Iniciar regras do Snort x
Parar/Iniciar o serviço do Snort x
Enviar e-mail de notificação x
Bloquear ameaças x
Quadro 3 – Comparativo entre o software desenvolvido e os demais sistemas
Desta forma este trabalho foi feito buscando permitir ao administrador da rede maior
agilidade no que diz respeito às tarefas relacionadas ao Snort.
42
4 CONCLUSÕES
Após as pessoas, a informação hoje é o bem mais precioso de uma organização. Com o
aumento das ameaças virtuais, sejam elas arquivos maliciosos, ou até mesmo ataques
cibernéticos direcionados, é de extrema importância que os responsáveis pela administração
dos ativos que armazenam essas informações tomem todas as medidas cabíveis para conter ou
minimizar de forma expressiva o impacto negativo em caso de comprometimento dos
sistemas. O extravio ou até mesmo a exposição destas informações pode acarretar um prejuízo
inestimável.
Este software foi desenvolvido tendo em vista automatizar um processo que antes era
feito por meio de edição manual de arquivos de configuração. Pode-se dizer que os objetivos
foram alcançados, pois graças ao desenvolvimento deste software existe a possibilidade de
configurar o IDS Snort de forma simples e unificada sem a necessidade de conhecer os
diversos comandos do sistema operacional que o hospeda.
A forma de acesso ao sistema através de um navegador, permite que o administrador
configure o Snort de qualquer computador ligado a mesma rede de dados.
A funcionalidade de enviar e-mails ao administrador em caso de detecção de possíveis
intrusões facilita o acompanhamento dos registros sem ser necessário acompanhar os retornos
do IDS em tempo integral.
Como maior dificuldade destaca-se a criação da interface, pois ao se tratar de um
software web é necessário desenvolver também o design do layout. Em relação ao
desenvolvimento, vários conceitos aprendidos nos semestres anteriores foram utilizados. Já
outros assuntos necessitaram de pesquisa com o intuito de encontrar soluções para os
problemas que apareceram durante o desenvolvimento.
Conclui-se que a realização deste trabalho incrementou o conhecimento na parte
técnica garantindo assim um desenvolvimento pessoal valioso para futuros trabalhos.
44..11 EEXXTTEENNSSÕÕEESS
Dando continuidade ao projeto, seria interessante que a próxima versão o software
pudesse centralizar várias instâncias do IDS Snort, estando elas na mesma rede local ou até
43
mesmo em redes remotas. Essa alteração permitiria que o software desenvolvido pudesse ser
utilizado em redes com imenso tráfego de dados, onde se faz necessário mais de uma
instância do Snort, ou até mesmo em empresas com sites remotos.
44
REFERÊNCIAS BIBLIOGRÁFICAS
ANÔNIMO. Segurança máxima para Linux. 2. Ed. Rio de Janeiro: Campus, 2000.
BATISTA, Thais; PEREIRA, Lucas. Segurança em redes de computadores. Natal, 2010. Disponível em < http://www.metropoledigital.ufrn.br/aulas_avancado/web/disciplinas/seg_redes/aula_09.html >. Acesso em: 05 nov 2011.
BON, Jan Van. Fundamentos do Gerenciamento de Serviços em TI baseado no Itil. 1. Ed. Amersfoort: Van Haren Publishing, 2006.
CAMPOS, André L. N. Sistema de segurança da informação: Controlando os Riscos. 1. Ed. Florianópolis: Visual Books Ltda, 2006.
CHESWICK, William R.; BELLOVIN, Steven M.; RUBIN, Aviel D. Firewalls e segurança na internet: Repelindo o Hacker Ardiloso. 2. Ed. Porto Alegre: Bookman, 2005.
CONRADO, Leonardo Couto. Snorby - instalação do frontend para Snort. Salvador, 2010. Disponível em < http://conteudoopensource.blogspot.com/2010/06/snorby-instalacao-do-frontend-para.html >. Acesso em: 16 set 2011.
DANYLIW, Roman. ACID: Database (v100-103) ER Diagram. New Orleans, 2001. Disponível em: < http://www.andrew.cmu.edu/user/rdanyliw/snort/acid_db_er_v102.html >. Acesso em: 22 mai 2012.
DIAS, Cláudia. Segurança e auditoria da tecnologia da informação. 1. Ed. Rio de Janeiro: Axcel Books do Brasil, 2000.
FLORES, Alejandro. Implementando o Barnyard com SNORT. Recife, 2004. Disponível em: < http://www.triforsec.com.br/novo/doc_copiar.php?id=5 >. Acesso em: 05 mar 2012.
FONTES, Edison. Vivendo a segurança da informação - Orientações práticas para pessoas e organizações. 1. Ed. São Paulo: Sicurezza : Brasiliano e Associados, 2000.
GUIMARÃES, Alexandre Guedes; LINS, Rafael Dueire; OLIVEIRA, Raimundo Correa de. Segurança com redes privadas virtuais VPNs. 1. Ed. Rio de Janeiro: Brasport, 2006.
IZQUIERDO, Victor Antônio. Afinal o que é segurança da informação? Joinville, 2007. Disponível em < http://www.relacionamentodigital.com/afinal-o-que-e-seguranca-da-informacao >. Acesso em: 15 set 2011.
MONTE, Silvio do. Snort em 15 minutos!. Recife, 2008. Disponível em: < http://sophosnet.com.br/blog/?page_id=14 >. Acesso em: 02 mar 2012.
45
MONTORO, Rodrigo. Introdução ao Snort - Serie Snortando (Parte 1). São Paulo, 2012. Disponível em: < http://spookerlabs.blogspot.com.br/2012/01/introducao-ao-snort-serie-snortando.html >. Acesso em: 05 mar 2012.
OLIVEIRA, Wilson. Técnicas para hackers - soluções para segurança. 2. Ed. Lisboa: Centro Atlântico, 2003.
PAULA, Anchises de. Os custos exorbitantes do cyber crime. São Paulo, 2011. Disponível em < http://anchisesbr.blogspot.com/2011/09/seguranca-os-custos-exorbitantes-do.html >. Acesso em: 16 set 2011.
PEIXOTO, Mário C. P. Engenharia social e segurança da informação na gestão corporativa. 1. Ed. Rio de Janeiro: Brasport Livros e Multimídia Ltda, 2006.
PIMENTEL, Jean Fellipe de Almeida; FAGUNDES, Pedro Correia. Snort sistemas distribuídos. Juiz de Fora, 2009. Disponível em < http://www.jeanpimentel.com.br/67/snort >. Acesso em: 15 set 2011.
SANTOS, Douglas Q. dos. IDS com Snort + Guardian + Debian Lenny. São José dos Pinhais, 2010. Disponível em < http://www.vivaolinux.com.br/artigo/IDS-com-Snort-+-Guardian-+-Debian-Lenny?pagina=8 >. Acesso em: 16 set 2011.
SILVA, Edelberto Franco; JULIO, Eduardo Pagani. Sistemas de Detecção de Intrusão. Rio de Janeiro, 2011. Disponível em: < http://www.devmedia.com.br/revista-infra-magazine-1/20816 >. Acesso em: 05 nov 2011.
STANGER, James; LANE, Patrick T. Rede segura Linux. 1. Ed. Rio de Janeiro: Alta Books, 2002.
WENDT, Emerson. Ciberguerra, inteligência cibernética e segurança virtual. Revista Brasileira de Inteligência, Brasília, n. 6 – 2011. Disponível em: < www.abin.gov.br/modules/mastop_publish/files/files_4e3ae31e2c097.pdf >. Acesso em: 05 mar 2012.
46
APÊNDICE A – Descrição dos Principais Casos de Uso
No Quadro 4 verifica-se o caso de uso “Definir parâmetros de configuração do Snort”. UC02 - Definir parâmetros de configuração do Snort Ator: Administrador Objetivo: Consultar e se necessário alterar os parâmetros de configuração do sistema de detecção de intrusão Snort. Pré-condições: O sistema de detecção de intrusão Snort deve estar devidamente instalado. Pós-condições: Os parâmetros das regras de configuração foram alterados. O IDS passa a funcionar atendendo as novas configurações. Cenário Principal: 1. Administrador solicita visualizar os parâmetros de configuração; 2. O sistema apresenta tela com os parâmetros de configuração; 3. O administrador opta por alterar os parâmetros de configuração ou encerra o caso de uso. Cenário Alternativo: No passo 3, o administrador opta por alterar um parâmetro: 3.1. O administrador altera os dados de uma opção já existente e seleciona Salvar; 3.2. O software valida as informações; 3.3. O software grava as informações. Exceção: No passo 3, caso os dados do parâmetro alterado não sejam válidos, apresenta mensagem “Parâmetro incorreto!”
Quadro 4 - Caso de uso definir parâmetros de configuração do Snort
No Quadro 5 verifica-se o caso de uso “Adicionar/Remover regras”
UC05 - Adicionar/Remover regras Ator: Administrador Objetivo: Adicionar novas regras que ainda não fazem parte do IDS para que o monitoramento possa procurar também por assinaturas das novas regras, ou, remover as regras existentes que apresentem alguma interferência no funcionamento do sistema de detecção de intrusão. Pré-condições: O sistema de detecção de intrusão Snort deve estar devidamente instalado. Pós-condições: Regras foram adicionadas ou removidas do sistema. O IDS passará a monitorar o tráfego de rede na busca por ameaças incluindo as novas assinaturas, ou removendo as assinaturas das regras excluídas. Cenário Principal: 1. Administrador solicita visualizar as regras de monitoramento; 2. O software apresenta tela com as regras de monitoramento existentes; 3. O administrador opta por adicionar uma nova regra de monitoramento; 4. O administrador opta por remover uma regra ou encerra o caso de uso. Cenário Alternativo: No passo 3, o administrador opta por adicionar uma nova regra de monitoramento: 3.1. O administrador insere as informações referentes a nova regra e clica em Adicionar
47
3.2. O software valida a regra 3.3. O software adiciona a nova regra, mas não a ativa Cenário Alternativo: No passo 4, o administrador opta por remover uma regra de monitoramento: 4.1. O administrador escolhe a regra e clica em Excluir 4.2. O software remove a regra Exceção: No passo 3, caso a nova regra não atenda aos requisitos de estrutura de regras do sistema de detecção de intrusão Snort, apresenta mensagem “Regra inválida!”
Quadro 5 – Caso de uso adicionar/remover regras