CURSO DE BACHARELADO EM CINCIA DA COMPUTAO

Brunno Jos Fagundes

SNORTIK - UMA INTEGRAO DO IDS SNORT E O SISTEMA DE FIREWALL DO

MIKROTIK ROUTEROS

Santa Cruz do Sul, janeiro de 2016

 CURSO DE BACHARELADO EM CINCIA DA COMPUTAO

Brunno Jos Fagundes

SNORTIK - UMA INTEGRAO DO IDS SNORT E O SISTEMA DE FIREWALL DO

MIKROTIK ROUTEROS

Prof. Me. Charles Varlei Neu

Orientador

Santa Cruz do Sul, janeiro de 2016

 Brunno Jos Fagundes

SNORTIK - UMA INTEGRAO DO IDS SNORT E O SISTEMA DE FIREWALL DO

MIKROTIK ROUTEROS

Trabalho de Concluso II apresentado ao Curso de

Cincia da Computao da Universidade de Santa
Cruz do Sul, como requisito parcial para a obten-
o do ttulo de Bacharel em Cincia da Computa-
o.

Orientador: Prof. Me. Charles Varlei Neu

Santa Cruz do Sul, janeiro de 2016

 H trs mtodos para ganhar sabedoria:
Primeiro, por reflexo, que o mais nobre;
segundo, por imitao, que o mais fcil;
e terceiro, por experincia, que o mais amargo.
C ONFCIO
 AGRADECIMENTOS

Agradeo a todos que, direta ou indiretamente, colaboraram para que eu alcanasse meus
objetivos acadmicos. Todo o trabalho, esforo e dedicao aplicado neste trabalho em reco-
nhecimento ao apoio que tive durante o processo de graduao.

Aos meus professores que, com dedicao, transferiram um pouco de seus conhecimentos.
A todos os professores que tive, registro meu muito obrigado por toda a dedicao, empenho e
boas lembranas que levarei comigo para toda a vida. Muitos de vocs sero lembrados com
saudade, pois alm de meus professores, foram grandes amigos. Meu muito obrigado a todos
vocs. Agradeo ao meu orientador, Charles Neu, por toda a colaborao no desenvolvimento
deste trabalho.

Meu agradecimento aos meus pais, Erli Jos Fagundes, em especial, minha me, Daisi
Magda Antonio, que sempre me incentivou a continuar em frente, porm, infelizmente, no
poderei compartilhar este momento "pessoalmente". Para voc, minha me, dedico muito mais
do que este trabalho, dedico toda minha trajetria de vida.

Meu sincero agradecimento a minha namorada Aline Jssica Mainardi, a qual se manteve
ao meu lado, mesmo separados por 265km. Obrigado por sempre ter incentivado, colaborado da
melhor forma possvel e pela compreenso durante todo esse perodo. No foi fcil administrar
tempo, distncia e compromissos, mas por fim, conseguimos "piu". Te amo!

Aos amigos que souberam entender as limitaes de tempo em decorrncia do desenvol-

vimento deste trabalho. Meu sincero agradecimento a todos, sem citar nomes para no esquecer
ningum. Deixo aqui registrado o meu Muito Obrigado pelo apoio, em todos os momentos,
principalmente nos mais difceis. Tenham certeza que carrego todos vocs comigo, sempre!
 RESUMO

Sistemas de Deteco de Intruso, ou Intrusion Detection System - IDS - so ferramentas

complementares segurana de sistemas operacionais ou de redes de computadores. Estes sis-
temas tm por objetivo identificar tentativas de ataques as estruturas que esto destinados a mo-
nitorar e gerar alertas ao administrador do sistema/rede para que sejam tomadas as providncias
cabveis para a soluo dos problemas. Um IDS pode ainda ser integrado a outros mecanismos
de proteo, como por exemplo, a um sistema de firewall, onde passa a atuar de forma combi-
nada, podendo assim reagir a um ataque. Apesar da possibilidade de integrao com um firewall,
nativamente, isto somente possvel com a utilizao de complementos, tambm conhecidos
como plugins. Essa integrao entre IDS e firewall tambm no algo universal e compatvel
com todo e qualquer sistema de firewall, como o caso do sistema Mikrotik RouterOS. Para
realizar esta integrao, se faz necessrio um sistema intermedirio que possibilite que, as detec-
es de ataques realizadas pelo IDS se transformem em regras de proteo no mdulo de firewall
do sistema Mikrotik RouterOS. O presente trabalho prope a implantao do IDS SNORT como
ferramenta de deteco de ataques e o desenvolvimento de um sistema intermedirio que possibi-
lite transformar os registros de deteco do IDS SNORT em regras de proteo junto ao firewall
do sistema Mikrotik RouterOS. Os resultados mostram que este sistema pode ser utilizado para
automatizar o processo de reao aos ataques identificados pelo IDS SNORT, sem a necessidade
de interveno direta do administrador do sistema, impedindo o acesso de hosts identificados
como suspeitos.

Palavras-chave: Sistema de Deteco de Intruso, SNORT, Mikrotik, Firewall, IDS, Intruso

de redes, Segurana de redes.
 ABSTRACT

Intrusion Detection Systems (IDS) are tools designed to improve security in operating sys-
tems and computer networks. These systems are intended to identify attack attempts to the struc-
ture that they are designed to monitor, and generate alerts to the system/network administrators
so that the appropriate action to solve the problems can be taken. An IDS can also be integrated
with other protection mechanisms, such as a firewall, in order to react to an attack. Although the
possibility of integration with a firewall, natively, it is possible only using addons, also known
as plugins. This integration between IDS and firewall is not something universal and compatible
with any and all firewall system, such as the Mikrotik RouterOS. To accomplish this integration,
an intermediate system is proposed. This work proposes the implementation of SNORT IDS as
an attack detection tool and the development of an intermediate system that uses the logs gener-
ated by SNORT IDS to create protection rules for the Mikrotik RouterOS firewall. The achieved
results show that this system can be used to automate the reaction process to attacks identified
by SNORT without the system administrator intervention, blocking suspect hosts identified.

Keywords: Intrusion Detection System, SNORT, Mikrotik, Firewall, IDS, Integration, Network
intrusion, Network security.
 LISTA DE ILUSTRAES

1 Alguns tipos de Ataques e suas camadas de atuao . . . . . . . . . . . . . . . . . . . 14

2 Modo de operao de um HIDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3 Modo de operao de um NIDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4 Modo de operao de um firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

5 Comparativo entre trabalhos estudados e trabalho proposto . . . . . . . . . . . . . . . 25

6 Fluxo de operao do IDS SNORT . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

7 Dispositivos desenvolvidos pela Mikrotik . . . . . . . . . . . . . . . . . . . . . . . . 30

8 Ferramenta de configurao Winbox da Mikrotik . . . . . . . . . . . . . . . . . . . . 33

9 Fluxo dos processos do sistema desenvolvido . . . . . . . . . . . . . . . . . . . . . . 35

10 Informaes registradas pelo NIDS SNORT . . . . . . . . . . . . . . . . . . . . . . . 37

11 Viso geral do projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

12 Ambiente de teste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

13 Regras elaboradas para deteco do NIDS SNORT . . . . . . . . . . . . . . . . . . . 42

14 Sequncia de tarefas do sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

15 Painel de controle do sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

16 Consultas realizadas para capturar as informaes de registro do IDS SNORT . . . . . 45

17 Base de dados auxiliar utilizada pelo sistema . . . . . . . . . . . . . . . . . . . . . . . 46

18 Regras formatadas para controle do firewall do Mikrotik RouterOS . . . . . . . . . . . 47

19 Conexo para aplicao das regras de controle . . . . . . . . . . . . . . . . . . . . . . 47

20 Regras de controle do sistema de firewall para bloqueio, insero, pesquisa e remoo 48

21 Ambiente desenvolvido para os testes de validao . . . . . . . . . . . . . . . . . . . 51

22 Registros do NIDS, verificao e insero de endereos na tabela de bloqueio . . . . . 53

23 Simulao de PING Flood utilizando ferramenta do Mikrotik RouterOS . . . . . . . . 54

24 Informaes nas tabelas de controle do sistema . . . . . . . . . . . . . . . . . . . . . 54

25 Exemplos de regras disparadas e registro do IDS . . . . . . . . . . . . . . . . . . . . . 55

26 Comparativo: Informaes de registro X Regras firewall . . . . . . . . . . . . . . . . . 56

27 Trigger aplicada tabela de hosts confiveis . . . . . . . . . . . . . . . . . . . . . . . 56

 LISTA DE ABREVIATURAS

API Application Programming Interface

DHCP Dynamic Host Configuration Protocol
DNS Domain Name System
DDoS Distributed Denial of Service
DoS Denial of Service
FPGA Field Programmable Gate Array
FTP File Transfer Protocol
HIDS Host Intrusion Detection System
IDS Intrusion Detection System
IPS Intrusion Prevention System
MPLS Multi Protocol Label Switching
NAT Network Translation Address
NIDS Network Intrusion Detection System
OSI Open System Interconection
PHP Hypertext Preprocessor
PPPoE Point-to-Point Protocol over Ethernet
QoS Quality of Service
SSH Secure Shell
TCP/IP Transmission Control Protocol / Internet Protocol
VPLS Virtual Private LAN Service
VPN Virtual Private Network
 SUMRIO

INTRODUO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

1 FUNDAMENTAO TERICA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.1 Ataques de Intruso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.2 Sistema de Deteco de Intruso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.3 Sistema de firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2 TRABALHOS RELACIONADOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.1 Categorizao do IDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.2 Propostas de otimizao do IDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.3 Integrao de IDS e sistemas de firewall . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.4 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3 TECNOLOGIAS ENVOLVIDAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.1 Sistema de Deteco de Intruso SNORT . . . . . . . . . . . . . . . . . . . . . . . . 26
3.1.1 Modos de Operao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.1.2 Arquitetura de Operao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.2 Mikrotik RouterOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4 TRABALHO DESENVOLVIDO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.1 Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.1.1 Deteco . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.1.2 Extrao e Converso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.1.3 Aplicao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.2 Modelagem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.2.1 Etapa de Deteco . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.2.2 Etapa de Captura de informaes e converso em Regras de proteo . . . . . . . . 43
4.2.3 Etapa de Aplicao das Regras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

5 RESULTADOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.1 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.2 Testes Realizados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.3 Resultados Obtidos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

6 CONCLUSO E CONSIDERAES FINAIS . . . . . . . . . . . . . . . . . . . . . . 58

REFERNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
 INTRODUO

Com a necessidade de dispositivos estabelecerem comunicao entre si para realizar a troca

de informaes ou compartilhamento de recursos, redes de computadores esto sendo ampla-
mente utilizadas e um dos maiores motivos a popularizao do acesso Internet (SOUZA;
LUCA, 2014). Entretanto, da mesma forma que o acesso Internet utilizado de forma adequada
finalidade para a qual foi criada, existem sistemas ou pessoas que promovem a m utilizao
desta rede com objetivo de prejudicar o seu funcionamento, utilizar os recursos disponveis de
forma prejudicial ou ilegal, ou ainda, adquirir informaes sem a devida autorizao (BHUYAN;
BHATTACHARYYA; KALITA, 2014) (HUBBALLI; SURYANARAYANAN, 2014).

Com o objetivo de monitorar, identificar, registrar e informar os administradores destes sis-

temas e/ou redes de computadores quando algum tipo de atividade maliciosa ou suspeita ocorre,
surgiram os sistemas de deteco de intruso ou Intrusion Detection System - IDS (COMER,
1988) (ZAMAN; KARRAY, 2009) (NJOGU et al., 2013). Estes sistemas operam realizando a
leitura de informaes contidas nos pacotes transmitidos pela rede e comparam os dados coleta-
dos com uma coleo de regras que permitem identificar ataques conhecidos (JUNQI; ZHENG-
BING, 2008) (HOQUE et al., 2014). Estas regras podem conter assinaturas de ataques, ou seja,
um conjunto de dados, ou ainda, um comportamento fora das caractersticas normais de operao
da rede/sistema (CHAUDHARI et al., 2010) (ANAND, 2014).

Apesar de realizar a leitura e identificao de ataques em uma rede/sistema, registrar e

alertar os responsveis, originalmente, um IDS no capaz de impedir ou bloquear um ataque.
Da mesma forma, IDSs no so capazes de reparar os danos causados por um ataque, ficando
esta funo sob responsabilidade exclusiva do administrador do sistema/rede (NJOGU et al.,
2013). Por outro lado, sistemas de firewall so responsveis por garantir o controle do acesso
rede ou dispositivo, impedindo ou restringindo o acesso de dispositivos, de acordo com as regras
de controle e polticas de segurana estabelecidas pelo administrador da rede/sistema (JUNQI;
ZHENGBING, 2008).

Dentre as diversas solues de IDSs existentes, desta-se o IDS SNORT (SNORT, 2015).
Este IDS capaz de identificar diversos tipos de ataques, baseado tanto em assinaturas quanto por
anomalias. Alm disso, possibilita, atravs do uso de complementos, isto , sistemas auxiliares
que possibilitam realizar tarefas adicionais, uma integrao com algumas solues de firewall,
como por exemplo o sistema IPTABLES. Contudo, sistemas como IPTABLES no so, por pa-
dro, otimizados para esta tarefa e no possuem um hardware otimizado para tal finalidade, isto
, com um desenvolvimento voltado para a tarefa que se destina, diferente da soluo Mikrotik
RouterOS.

O sistema Mikrotik RouterOS especializado no controle e gerenciamento de redes de

dispositivos desenvolvido pela Mikrotik. Esta soluo executada de forma embarcada, utili-
zando para isso um hardware, tambm desenvolvido pela Mikrotik. Este sistema conta com um
firewall que permite controlar todo o fluxo de dados transmitido pela rede. Contudo, no existe
uma integrao ou complemento que possibilite a integrao entre o IDS SNORT e o sistema de
firewall do Mikrotik RouterOS.

Observando esta lacuna entre as duas ferramentas de segurana, o presente trabalho apre-
senta uma forma de integrao automtica entre as duas solues. Desta forma, possvel con-
verter as deteces realizadas pelo IDS SNORT em regras de proteo junto ao sistema de fi-
rewall do Mikrotik RouterOS, ampliando a capacidade de reao aos ataques em uma rede de
dispositivos, de forma automatizada, utilizando as duas ferramentas.

O restante deste trabalho de concluso est organizado da seguinte maneira: O Captulo 1

apresenta os conceitos necessrios para a correta compreenso do mesmo. O Captulo 2 rene os
trabalhos estudados com relao a classificao dos IDSs, melhorias e propostas de integrao
encontradas na literatura. J o Captulo 3 refere-se as principais tecnologias utilizadas no traba-
lho. O sistema desenvolvido descrito no Captulo 4. O Captulo 5 mostra os testes realizados e
os resultados obtidos. Por fim, a concluso e consideraes finais so apresentadas no Captulo
6.
 1 FUNDAMENTAO TERICA

Neste captulo apresentado o referencial terico com os conceitos necessrios para a

realizao deste trabalho, visto que so fundamentais para a compreenso e desenvolvimento do
mesmo. Alm disso, so apresentadas as tecnologias utilizadas e alguns trabalhos com relao
ao assunto encontrados na literatura.

1.1 Ataques de Intruso

Um ataque de intruso pode ser caracterizado, de acordo com Ahmed et al. (AHMED et al.,
2009), como uma tentativa de utilizar recursos de um sistema de computador ou uma tentativa
de acesso as informaes sem autorizao. Ataques desta natureza tm como objetivo corromper
trs dos componentes bsicos da segurana de informao (BISHOP, 2004) (VACCA, 2013):

Autenticidade: Trata-se da confiabilidade da informao no aspecto de sua veracidade.

Ao afirmar que uma informao ntegra estamos certificando que a mesma oriunda de
uma fonte confivel e o seu contedo no sofreu nenhuma alterao sem autorizao.

Confidencialidade: Consiste em manter a informao sob um determinado domnio de

conhecimento, como por exemplo, restringi-la ao conhecimento de determinada informa-
o ao ambiente de uma instituio.

Disponibilidade: Refere-se capacidade de utilizar um determinado recurso ou informa-

o quando necessrio, desde que haja permisso para esta ao.

Um ataque de intruso pode explorar falhas de segurana de sistemas, aplicaes, protoco-

los ou ainda falhas de configuraes e de segurana. O padro de rede do modelo Transmission
Control Protocol / Internet Protocol - TCP/IP divide-se em quatro camadas: (i) Aplicao (ii)
Transporte (iii) Rede e (iv) Dispositivo de Rede, ou ainda, host rede, sendo que cada uma delas
 14

possui suas funcionalidades e servios (COMER, 1988). Sendo assim, ataques de intruso po-
dem ocorrer nas diferentes camadas do modelo TCP/IP (ZAMAN; KARRAY, 2009) e, de acordo
com a camada que atuam, esses ataques so categorizados em quatro grandes grupos, conforme
apresentado na Figura 1:

Figura 1: Alguns tipos de Ataques e suas camadas de atuao

Explorao: Ataques dessa categoria buscam explorar vulnerabilidades do sistema, apli-

caes instaladas sobre o sistema ou ainda falhas do usurio que permitam esse ataque.

Usurio para Superusurio: Refere-se aos ataques que realizam tentativas de adquirir
privilgios de Superusurios do sistema, possibilitando assim realizar qualquer tipo de
operao.

Negao de Servios ou Denial of Service - DoS: Esse tipo de ataque tem como objetivo
criar uma indisponibilidade de recursos ou sistemas. Para isso, um atacante gera muitas
requisies de modo que os recursos ou os sistemas fiquem sobrecarregados, ao ponto de
no conseguir mais atender as requisies de usurios legtimos, impedindo os acessos aos
recursos ou informaes. Este tipo de ataque pode ainda ser realizado de forma distribuda,
sendo denominado Distributed Denial of Service - DDoS.

Remoto para Usurio: Consiste em ataques que tem por objetivo se apropriar de sis-
tema remotamente, explorando falhas de segurana para obter acesso ao sistema como um
usurio legtimo ou administrador.

Como pode-se observar, os ataques de intruso ocorrem das mais diversas formas e em
todas as camadas do Modelo TCP/IP. Contudo, existem sistemas dedicados a identificar e detectar
esses tipos de ataques: os IDSs.
 15

1.2 Sistema de Deteco de Intruso

Os IDSs tm como objetivo detectar, identificar e registrar essas ocorrncias para que o
administrador do sistema providencie uma soluo para o ataque sofrido (NJOGU et al., 2013).
Em 1987, Denning et al. (DENNING, 1987), apresentou um modelo para IDSs, onde descre-
veu um sistema capaz de identificar ataques independente de plataforma, aplicaes ou tipo de
ataque, sendo considerado um sistema de deteco de propsito geral. Alm disso, o trabalho
desenvolvido por Denning et al. deveria detectar ataques baseados em um perfil, mtricas e mo-
delos estatsticos. Porm, o modelo apresentado era baseado na deteco de intruses para um
dispositivo.

J em 1990, Heberlein et al. (HEBERLEIN et al., 1990) apresenta uma proposta para um
IDS ao nvel de rede de computadores. Este IDS deveria ser capaz de detectar ataques baseados
em um perfil de utilizao da rede, identificando uma utilizao que buscasse violar esse perfil,
comprometendo a segurana. Aps a apresentao destes dois modelos iniciais de IDSs, diversos
outros modelos foram desenvolvidos. Desde ento, observou-se a relevncia do tema para a
segurana das informaes e, a partir deste momento, muitos modelos, inclusive projetos de
interesses comerciais, foram desenvolvidos, como por exemplo, as solues IDS SNORT e Bro
(SNORT, 2015) (BRO, 2015) (PAXSON, 1998).

Um IDS pode ser classificado conforme o escopo de sua rea de atuao, sendo assim, pode
atuar tanto na identificao de ataques contra um dispositivo quanto na identificao de ataques
dentro de uma rede de dispositivos. Desta forma, estes sistemas podem ser classificados em dois
grandes grupos: (AL-JARRAH; ARAFAT, 2014) (BHUYAN; BHATTACHARYYA; KALITA,
2014)

Host Intrusion Detection System HIDS: Como HIDS, o IDS responsvel por monito-
rar a atividade de um dispositivo, isto , busca identificar ataques ou eventos suspeitos que
comprometam a segurana deste dispositivo, analisando apenas as informaes transmiti-
das pela rede destinadas a este dispositivo, conforme ilustra a Figura 2.
 16

Figura 2: Modo de operao de um HIDS

Network Intrusion Detection System NIDS: Como NIDS, o IDS fica responsvel por
analisar o contedo transmitido na rede e busca identificar atividades suspeitas que ocor-
ram. Neste escopo, o IDS responsvel por analisar atividades que envolvam todos os
dispositivos presentes nesta rede, conforme mostra a Figura 3 (AL-JARRAH; ARAFAT,
2014) (BHUYAN; BHATTACHARYYA; KALITA, 2014).

Figura 3: Modo de operao de um NIDS

Um IDS pode ainda ser classificado conforme a camada do modelo TCP/IP que opera.
No trabalho apresentado por Zaman et al. (ZAMAN; KARRAY, 2009), esta classificao pode
 17

ser realizada de acordo com o tipo de ataque pelo qual o IDS ser responsvel, uma vez que os
diferentes tipos de ataques esto presentes em camadas distintas do modelo TCP/IP.

Alm disso, essa classificao justificada pelo fato de que um IDS responsvel por
monitorar ataques especficos. Desta forma, ao monitorar uma camada do modelo TCP/IP em
especfico, o IDS pode ser otimizado para essa tarefa, apresentando resultados mais eficientes do
que outro de propsito geral (ZAMAN; KARRAY, 2009).

Apesar de ser responsvel por monitorar, tanto dispositivos em especfico quanto redes
de dispositivos, um IDS, por padro, limita-se a trs funcionalidades bsicas:(i) monitorar, (ii)
detectar e (iii) registrar os eventos. A responsabilidade de criar mecanismos ou realizar configu-
raes para impedir ou interromper ataques de responsabilidade do administrador do sistema
ou rede. Entretanto, um IDS capaz de reagir a uma ocorrncia, interrompendo ou rejeitando co-
nexes, ou ainda, disparando algum script para impedir o acesso alguma informao (JUNQI;
ZHENGBING, 2008).

A anlise das informaes realizada por um IDS pode ser realizada de duas formas distintas
(SNORT, 2015):

Normal: Quando opera em modo HIDS e analisa apenas as informaes destinadas a um

dispositivo em especfico;

Promscua: Onde o IDS opera como NIDS e analisa todo o contedo transmitido entre os
dispositivos da rede buscando identificar ataques.

No modo de operao promscuo, deve ser observada a capacidade de anlise do IDS, visto
que o volume de informaes processada tende a ser bem maior do que em uma anlise em modo
normal. Para isso importante que o dispositivo responsvel por operar como NIDS tenha um
conjunto de hardware compatvel com sua demanda. Caso contrrio, poder no ser capaz de
processar um volume significativo de informaes, o que, eventualmente, pode acarretar em no
identificar um ataque (SNORT, 2015).

Para identificar um ataque, um IDS pode utilizar duas formas de deteco:

 18

Baseado em Assinaturas: Nesse modo o IDS utiliza-se de uma base de dados de ataques
conhecidos. Para identificar uma tentativa de intruso analisado o contedo de cada pa-
cote em busca de um conjunto de caracteres que permite identificar o ataque. Este conjunto
de caracteres denominado como Assinatura do ataque (SNORT, 2015).

Baseado em Anomalias: Um IDS capaz de identificar um ataque quando a ocorrncia de

algum evento diferente de algum padro considerado normal, por exemplo, alguma apli-
cao realizando uma tentativa de acesso no autorizado a um recurso do sistema (SNORT,
2015).

Quando um ataque identificado, o IDS tem a responsabilidade de registrar essa ocorrn-

cia para alertar o administrador do sistema sobre o ocorrido. Para isso, pode utilizar diversos
mecanismos, como por exemplo, registrar as ocorrncias em arquivos, disparar alertas, enviar
essas informaes para o responsvel, disparar algum script, ou ainda, armazenar essas informa-
es em uma base de dados. Apesar de ter como objetivo principal identificar e registrar ataques,
o IDS pode ainda reagir ao ataque, porm, essa caracterstica reativa no um padro de sua
funcionalidade (SNORT, 2015).

Ao registrar uma ocorrncia, um IDS armazena uma coleo de informaes referentes ao

ataque, como por exemplo:

Endereo IP de origem do atacante;

Endereo IP do alvo;

Protocolo de comunicao utilizado;

Porta de comunicao utilizada;

Conjunto de caracteres da assinatura do ataque;

Data e hora da ocorrncia;

Classificao do ataque e sugestes de soluo do problema.

Com esse conjunto de informaes, um administrador capaz de identificar os disposi-

tivos envolvidos, quais as possveis consequncias deste ataque e como solucionar o problema
 19

e evitar novos incidentes. Contudo, essa anlise do contedo dos registros, identificao dos
dispositivos e o tipo de ataque realizado um processo, por padro, dependente da interveno
humana. Existem ainda sistemas complementares aos IDSs que permitem uma organizao e
apresentao destas informaes de forma mais prtica, inclusive transformando-as em dados
estatsticos.

Um IDS pode ser utilizado em conjunto com sistemas de controle de acesso rede, isto ,
sistemas de firewall (JUNQI; ZHENGBING, 2008). A combinao destas duas ferramentas de
proteo, distintas e complementares, possibilita reagir aos ataques detectados. Entretanto, essa
integrao no universal entre todos os IDSs e todos os sistemas de firewall. As funcionalida-
des de um sistema de firewall sero abordadas na Seo 1.3.

1.3 Sistema de firewall

Um sistema de firewall pode ser comparado, de acordo com Tanenbaum et al. (TANEN-
BAUM; WETHERALL, 2010), com uma adaptao moderna das tcnicas de segurana da Era
Medieval, onde eram escavados fossos ao redor de castelos, restando apenas um ponto de pas-
sagem. Assim, os seguranas poderiam controlar o acesso, tanto de entrada quanto de sada do
castelo, bem como restringir o acesso ao seu domnio, vistoriando cargas, pessoas, etc.

Em sistemas computacionais, um firewall tem a mesma funo: controle das informaes,

permisses de acesso as redes de computadores, controlar o fluxo das informaes, dentre outras
funcionalidades (TANENBAUM; WETHERALL, 2010). Em uma rede de computadores, para
buscar um certo grau de segurana, recomenda-se que estes sistemas sejam a nica porta de
entrada e sada. Desta forma o controle do acesso e aplicao de polticas de utilizao da rede
so controladas pelo firewall. Assim, busca-se garantir que todo o fluxo de informaes ser
analisado e apenas o contedo considerado autorizado, seguro e confivel seja permitido.

A questo de controle e segurana das informaes est diretamente relacionado s pol-

ticas de cada entidade ou organizao. Assim, o firewall tem como objetivo assegurar que estas
sejam respeitadas. Bishop (2004) define o sistema de firewall como um mediador no acesso
rede, o qual permite ou no certos tipos de acesso a ela baseando-se em polticas de segurana
devidamente configuradas (BISHOP, 2004). A Figura 4 ilustra a utilizao de um sistema de
 20

firewall.

Figura 4: Modo de operao de um firewall

De acordo com Tanenbaum et al. (TANENBAUM; WETHERALL, 2010), a maioria das

empresas possuem grande quantidade de dados confidenciais e o vazamento ou perda destas
informaes podem comprometer seus negcios. Alm disso, existe o risco do uso no ma-
licioso, mas sim, descuidado da rede, o que pode permitir o acesso de aplicaes maliciosas
que comprometem a segurana das informaes e outros recursos. Para que eventos como estes
no ocorram, o firewall uma das ferramentas utilizadas para garantir que essas polticas sejam
respeitadas (TANENBAUM; WETHERALL, 2010).

Aps estudados os conceitos necessrios para o entendimento deste trabalho, no Captulo

2, so apresentados diferentes projetos e propostas encontrados na literatura que possuem relao
com este projeto.
 2 TRABALHOS RELACIONADOS

Este captulo apresenta trabalhos encontrados na literatura relacionados aos IDS, suas apli-
caes e propostas de categorizar estes sistemas de acordo com a sua camada de atuao, consi-
derando o modelo TCP/IP. Alm disso, relaciona trabalhos onde a utilizao combinada de IDS
e sistemas de firewall so abordadas como solues complementares de segurana, bem como
algumas propostas de integrao entre estas duas solues.

2.1 Categorizao do IDS

Dentre os trabalhos encontrados na literatura, o trabalho apresentado por Zaman et al.

(ZAMAN; KARRAY, 2009) traz uma abordagem sobre sistemas de deteco de intruso e sua
relao com o modelo TCP/IP. Este trabalho refere-se a um estudo sobre a classificao dos IDSs
de acordo com os tipos de ataques que iro monitorar e em qual camada do modelo TCP/IP eles
ocorrem.

Zaman et al. destacam que, de acordo com a camada e tipos de ataques pelo qual o sistema
ser responsvel por detectar e identificar, o IDS utiliza diferentes critrios para restringir o
trfego. O autor prope que, se o IDS for utilizado exclusivamente para detectar ataques em uma
das camadas proposta pelo modelo TCP/IP, este pode ser otimizado para essas deteces e ainda,
pode-se ter uma reduo da carga computacional, resultando em ganho de performance em sua
capacidade de deteco e escalabilidade, comparando a um IDS de propsito geral que atue em
diferentes camadas (ZAMAN; KARRAY, 2009).

Entretanto, apesar de apresentar propostas para categorizar os IDSs quanto a sua camada
de atuao e propor que possvel desta forma uma otimizao para estes sistemas aumentando
suas performances no que diz respeito a capacidade de deteco, o autor no prope nenhuma
forma de integrao destes sistemas aos firewalls. importante ressaltar que Zaman et al. (ZA-
MAN; KARRAY, 2009) cita que IDSs podem ser utilizados como uma segunda linha de defesa.
Sugere tambm que sua aplicao seja aps um sistema de firewall e recomenda a combinao
 22

entre essas duas solues.

No trabalho de Chaudhari et al. (CHAUDHARI et al., 2010) proposta uma classificao

dos ataques de forma semi-supervisionada. Os autores apresentam um estudo onde classifica,
atravs de um algoritmo especialista, os ataques identificados em dois grupos: maliciosos e
normais. Ao classificar o ataque como malicioso, o algoritmo apresentado por Chaudhari et al.
realiza a incluso das informaes do ataque base de assinaturas do IDS.

Apesar de propor uma melhoria para os IDSs e destacar seus principais objetivos, Chaudhari
et al. tambm no apresenta nenhum tipo de integrao com algum tipo de sistema de proteo.

2.2 Propostas de otimizao do IDS

J o trabalho proposto por Valgenti et al. (VALGENTI; SUN; KIM, 2014) refere-se a um
filtro de tempo real para ser aplicada ao trfego da rede. Esse filtro tem por objetivo separar
o trfego seguro do trfego considerado potencialmente suspeito, antes de ser encaminhado para
anlise do IDS.

Atravs desta abordagem, Valgenti et al. busca uma reduo do volume de pacotes enca-
minhados para o IDS, aumentando a sua disponibilidade, reduzindo o nmero de pacotes descar-
tados e aumentando o percentual de informaes potencialmente suspeitas analisadas.

No que diz respeito a otimizar deteces, o trabalho proposto por Raghunath et al. (RAGHU-
NATH; MAHADEO, 2008) sugere um modelo de minerao de dados para detectar compor-
tamentos anormal em uma rede, isto , um comportamento com caractersticas e parmetros
diferentes da operao normal. O autor prope uma abordagem onde, atravs de tcnicas de mi-
nerao de dados, possvel identificar comportamentos associados a padres de redes de forma
automatizada.

Ainda sobre otimizao de sistemas de deteco, pertinente citar o trabalho desenvolvido

por Lee et al. (LEE et al., 2007), onde apresentada uma abordagem ao IDS implementado em
Field Programmable Gate Array - FPGA. Com esta abordagem, Lee et al. propem que IDSs
implementados em FPGA podem obter um melhor desempenho de deteco do que solues im-
 23

plementadas em software, porm seu desempenho fica limitado capacidade de processamento

do hardware. Nesta abordagem, o sistema proposto foi, inclusive, comparado ao desempenho do
IDS SNORT.

Por fim, relevante destacar a abordagem realizada por Sherry et al. (SHERRY et al.,
2015), ao problema de deteco de intruso baseado em assinaturas quando o contedo est
criptografado. Sherry et al. apresenta um sistema que opera na identificao de assinaturas
mesmo tendo o contedo dos pacotes criptografados.

Para isso, o sistema realiza a comparao do contedo destes pacotes com assinaturas de
ataques tambm criptografadas, utilizando diferentes esquemas de criptografia, buscando por
expresses regulares nesse contedo. Assim, o sistema no realiza a quebra do sigilo destas
informaes e ao mesmo tempo permite a identificao de ataques.

Contudo, da mesma forma que os demais trabalhos estudados, os apresentados nesta seo
no propem uma soluo para integrar as melhorias e otimizaes aplicadas na fase de deteco
a um sistema de proteo. Assim, mesmo que sejam atingidas estas melhorias na identificao
de ataques, ainda existe a ausncia de uma integrao com um sistema que controle e proteja a
rede de novos incidentes.

2.3 Integrao de IDS e sistemas de firewall

O trabalho proposto por Huang et al. (HUANG; WANG; ZHU, 2010) apresenta uma in-
tegrao entre um IDS e um sistema de firewall. O autor justifica esta integrao quando deixa
explcito as diferenas entre os sistemas, seus propsitos e suas limitaes, mostrando que os
sistemas, de fato, se complementam.

Huang et al. destaca que um sistema de firewall opera geralmente nas camadas de Enlace e
Rede do Modelo Open System Interconection OSI e no tem a capacidade de reconhecer con-
tedo malicioso e comportamentos em outras camadas. J o IDS, tradicionalmente, escuta o
trfego da rede buscando por comportamento suspeitos ou por ataques previamente identificados
por assinaturas.
 24

Porm, apesar de apresentar uma abordagem integrao entre os IDS ( inclusive utili-
zando o IDS SNORT como ferramenta de deteco) e um sistema de firewall no especificado,
este trabalho no contempla a integrao ao sistema de firewall do Mikrotik RouterOS. Alm
disso, o sistema apresentado por Huang et al. prope modificaes no IDS para que seja possvel
esta integrao. Ainda, os autores sugerem uma soluo implementada em um mesmo disposi-
tivo, onde compartilha recursos de hardware para realizar todas as funcionalidades de deteco e
proteo.

Tal proposta no se aplica no caso do firewall do sistema Mikrotik RouterOS pelo fato de
no ser possvel implementar no mesmo dispositivo o IDS SNORT. Isso por que o sistema Mi-
krotik RouterOS, apesar de ser baseado no sistema operacional Linux, uma soluo proprietria
e customizada.

Ainda sobre propostas de integrao de IDS e sistemas de firewall, o trabalho de Lei-Jun

et al. (LEI-JUN; HONG, 2010) apresenta uma proposta de integrao, de fato, entre estas duas
solues de segurana (firewall e IDS), apontando suas vantagens, desvantagens e desafios.

Contudo, no menciona nenhum sistema em especfico e conclui afirmando que este

ainda um modelo terico. O trabalho proposto por Lei-Jun et al. sugere tambm que os dois
sistemas se adaptem ao ambiente de rede. Entretanto, os autores afirmam que para alcanar esta
integrao e adaptao da soluo ao ambiente, ser necessrio muita investigao e estudo sobre
o assunto (LEI-JUN; HONG, 2010).

2.4 Objetivos

Considerando os trabalhos estudados na literatura, observou-se que o foco principal de

estudo da maioria destes est relacionado a melhoria na deteco dos ataques. Apesar de alguns
mencionarem que o IDS e o sistema de firewall se complementam, poucos tratam sobre esta
integrao, conforme mostra a Figura 5.
 25

Figura 5: Comparativo entre trabalhos estudados e trabalho proposto

Como pode-se observar na Figura 5, mesmo aqueles que apresentam uma proposta de in-
tegrao entre as duas ferramentas, no contemplam o sistema Mikrotik RouterOS. Desta forma,
percebe-se a ausncia de uma soluo que integre deteco e proteo utilizando estas duas fer-
ramentas. Neste sentido, apresentada uma abordagem de integrao do sistema de deteco de
intruso SNORT e o um sistema de proteo utilizando o firewall do sistema Mikrotik RouterOS.

Alm disso, a proposta deste trabalho busca desenvolver uma soluo que realize as tare-
fas de forma automatizada, sem a interveno do administrador, para realizar a verificao dos
registros do NIDS SNORT e para criao das regras de proteo junto ao sistema de firewall do
Mikrotik RouterOS.

Com este objetivo, este trabalho prope um sistema intermedirio que utiliza os registros de
deteco do IDS SNORT como fonte de informao para gerar regras de proteo em um sistema
de firewall do sistema Mikrotik RouterOS. O desenvolvimento deste trabalho apresentado no
Captulo 4, bem como o ambiente de desenvolvimento, arquitetura do projeto e a modelagem
aplicada ao projeto.
 3 TECNOLOGIAS ENVOLVIDAS

Este captulo apresenta as tecnologias utilizadas para desenvolver este trabalho. Na Seo
3.1 abordado o sistema de deteco de intruso utilizado e sua operao. J a Seo 3.2 refere-
se ao sistema Mikrotik RouterOS, suas caractersticas e funcionalidades.

3.1 Sistema de Deteco de Intruso SNORT

O sistema SNORT foi criado por Martin Roesch e considerado o IDS Open Source mais
difundido, de acordo com o site oficial do projeto, com mais de 4 milhes de downloads realiza-
dos e aproximadamente 500.000 usurios registrados em sua comunidade web (SNORT, 2015).
interessante ressaltar que o IDS SNORT referenciado e utilizado em grande parte dos traba-
lhos estudados para desenvolver este trabalho, como por exemplo nos trabalhos de Al-Jarrah et
al., Valgenti et al. e Lee et al. (AL-JARRAH; ARAFAT, 2014) (VALGENTI; SUN; KIM, 2014)
(LEE et al., 2007).

Alm disso, conta com uma base de dados de regras de deteco com mais de 36.500 re-
gras. Essa base de dados tambm pode ser utilizada por outras solues, como por exemplo,
o sistema Bro Network Security Monitor, desenvolvido e mantido por Vern Paxson em parceria
com o International Computer Science Institute e National Center for Supercomputing Appli-
cations (BRO, 2015) (PAXSON, 1998). Apesar disso, a soluo SNORT possui uma grande e
vasta documentao disponvel e uma ampla variedade de complementos, o que aumenta a sua
integrao com outras solues e viabiliza a integrao com o sistema proposto.

importante destacar que atualmente, o projeto do IDS SNORT conta com um grupo
de pesquisa denominado TALOS, que tem por objetivo trabalhar de forma proativa para des-
cobrir e solucionar problemas relacionados malwares, vulnerabilidades, ataques de intruso
e atividades hacking. Este grupo composto por membros renomados na rea de segurana
de redes e conceituadas empresas da rea de segurana, conforme apresentado no prprio site
do projeto. Maiores detalhes sobre este grupo de pesquisa podem ser encontradas no endereo
 27

https://www.snort.org/talos (SNORT, 2015).

3.1.1 Modos de Operao

O IDS SNORT pode operar tanto como um HIDS quanto como NIDS. Em ambos os casos
o sistema analisa os pacotes que so trafegados na rede de computadores, comparando o con-
tedo encontrado com uma base de assinaturas de ataques ou atravs de identificao de alguma
anomalia na operao da rede. Estas assinaturas so conjuntos de informaes/caracteres que
permitem ao IDS identificar pacotes que fazem parte de uma tentativa de intruso. Atravs do
comparativo do contedo destes pacotes com as informaes contidas em sua base de assinaturas,
possvel identificar com preciso possveis tentativas de ataques rede de computadores ou aos
dispositivos . J as anomalias so comportamentos de operao de uma rede fora de um limite
aceitvel, comparada aos parmetros de operao normal da rede, como por exemplo volume de
dados trafegado ou nmero de pacotes transmitidos (SNORT, 2015).

3.1.2 Arquitetura de Operao

A operao do IDS SNORT realizada em etapas, ou seja, necessrio: (i) capturar um

pacote de dados na rede, (ii) abrir (decodificar) este pacote, (iii) analisar as informaes contidas
neste pacote, (iv) comparar estas informaes com as assinaturas de ataques existentes na base
de dados do IDS e, caso detectado um ataque, (v) realizar o registro e (vi) alertar o administrador
do sistema. Para realizar este processo o IDS SNORT divide sua operao em 3 subsistemas
primrios, conforme apresenta a Figura 6 (SNORT, 2015).
 28

Figura 6: Fluxo de operao do IDS SNORT

Cada etapa ilustrada na Figura 6 "prepara" as informaes a serem processadas pela etapa
seguinte. Para realizar este processo, o IDS SNORT opera da seguinte forma:

Decodificador de Pacotes: responsvel por decodificar os pacotes capturados de acordo

com a camada do Protocolo TCP/IP que se encontram. Alm disso, tambm encarre-
gado de inserir ponteiros nos pacotes decodificados para que estes sejam analisados pelo
subsistema de deteco;

Engenharia de Deteco: Tem como objetivo analisar as informaes dos pacotes e

compar-las s assinaturas dos ataques conhecidos pelo IDS SNORT. Caso seja detectado
um ataque, disparado o subsistema de registro e alerta;

Subsistema de registro e Alertas: encarregado por registrar os eventos e disparar os

alertas configurados no sistema. O IDS SNORT permite registrar os eventos em arquivo
texto, em formato syslog ou ainda em banco de dados. Os dados inseridos nesses regis-
tros podem conter informaes bsicas, como por exemplo, apenas endereos de origem e
destino e tipo de ataque identificado, ou ento completas, podendo conter inclusive infor-
maes do contedo do pacote analisado pelo sistema.

Apesar de identificar eventos de ataques com eficincia, o IDS SNORT no est imune
 29

a problemas no processo de deteco. Um dos principais problemas que podemos encontrar

o caso de deteco de falsos positivos e falsos negativos. Identificar um falso positivo
significa reconhecer um acesso legtimo como uma intruso. J o falso negativo quando
a ferramenta permite um ataque e no o identifica considerando que o mesmo uma acesso
legtimo, quando na verdade est ocorrendo um ataque ao sistema (SNORT, 2015) (HUBBALLI;
SURYANARAYANAN, 2014).

No que diz respeito compatibilidade, o IDS SNORT compatvel com diversos sistemas
operacionais, podendo ser utilizado em sistemas Windows, MAC, Linux, Solaris, UNIX e de-
rivados UNIX. Considerando as formas possveis de registro, pode-se considerar uma soluo
multi-plataforma, a qual permite uma interao entre os diferentes sistemas (SNORT, 2015).

importante salientar que, atravs da utilizao de complementos, alm dos formatos

de registro mencionados, possvel armazenar as informaes de registro de eventos em base
de dados, como por exemplo, MySQL e PostgreSQL, aumentando o poder de anlise sobre os
dados registrados (SNORT, 2015).

No que diz respeito deteco, permite ainda que o usurio do sistema desenvolva suas
prprias regras de deteco. Isso permite ao administrador do sistema uma customizao ou
personalizao de acordo com as caractersticas do ambiente em que est operando, ampliando
ou refinando o poder de deteco do IDS (SNORT, 2015).

Apesar de ter como especialidade a deteco, o IDS SNORT permite ainda ser configurado
para reagir aos ataques. Para isso, o sistema configurado em modo de Preveno de Intruso
ou Intrusion Prevention System - IPS. Desta forma, o IDS, quando identifica algum ataque, reage
enviando, por exemplo, respostas de REJECT para o endereo que originou o ataque (SNORT,
2015).

Contudo, vale ressaltar que apesar de ser capaz de reagir a um ataque, este modo de ope-
rao pode permitir ocorrncias de falsos positivos e falsos negativos, o que pode impactar di-
retamente no desempenho da rede se no houver nenhum tipo de tratamento para evitar estas
ocorrncias. Alm disso, pertinente recordar que o IDS possui uma capacidade limitada de ana-
lisar o contedo transmitido pela rede (SNORT, 2015) (BULAJOUL; JAMES; PANNU, 2013).
Neste caso, seu desempenho pode vir a ser reduzido, pois acumula tambm a funo de reagir ao
 30

ataque, a qual no sua especialidade.

Tais caractersticas combinadas com as diversas formas possveis de registrar os eventos

mostram-se compatveis com a proposta de integrao deste projeto. Vale ainda mencionar que
os complementos disponveis para melhor armazenamento das informaes de registro do IDS
SNORT viabilizam este trabalho. Devido a todas estas caractersticas, popularidade e flexibili-
dade de aplicao do IDS SNORT, este sistema foi eleito como ferramenta de deteco para o
desenvolvimento deste projeto.

3.2 Mikrotik RouterOS

Mikrotik RouterOS um sistema operacional desenvolvido e mantido pela Mikrotik (MI-

KROTIK, 2015), uma empresa fundada em 1995, sediada em Riga, capital da Letnia. O Mi-
krotik RouterOS um sistema dedicado a realizar gerenciamento e controle de redes de com-
putadores. Para isso, dispe de diversos recursos, como por exemplo, roteamento de redes de
computadores, controle e filtro de trfego e contedo e sistema de proteo para estas redes.
Alm de recursos para controle e gesto de redes, o Mikrotik RouterOS o sistema operacional
embarcado no hardware desenvolvido pela Mikrotik, denominado RouterBOARD. A Figura 7
apresenta alguns dispositivos e componentes desenvolvidos pela Mikrotik.

Figura 7: Dispositivos desenvolvidos pela Mikrotik

Fonte: Mikrotik

Na Figura 7 pode-se observar (a) um carto de expanso de conexo sem fio de tecnologia
 31

802.11 a/n ou 802.11 b/g/n utilizado em conjunto com a (b) Routerboard RB 493, composta por
slots de expanso para cartes sem fio e ainda, 8 interfaces ethernet Gigabit e outras. J a imagem
(c) apresenta um adaptador para conexes pticas, que pode ser utilizada nos dispositivos (d) e
(e). A imagem (d) apresenta uma RouterBOARD de alto desempenho com suporte a 72 unidades
de processamento e 8 portas pticas de 10 Gigabits. Por fim, a imagem (e) apresentado um
modelo composto por conexes de rede se fio, redes ethernet Gigabit e conexes de fibra ptica
em um mesmo dispositivo, todos gerenciados pelo mesmo sistema RouterOS, demonstrando a
flexibilidade e robustez deste sistema.

No que diz respeito ao hardware desenvolvido pela Mikrotik, uma RouterBOARD pode
suportar processadores com mltiplos ncleos de processamento ou por mltiplas unidade de
processamento no mesmo hardware. No que tange a conectividade, uma RouterBOARD pode
suportar, por exemplo, em um mesmo dispositivo, as recentes interfaces de rede de 10 Gigabits,
interfaces de rede sem fio compatveis com os padres 802.11 a/b/g/n e ainda o recente padro
a/c (MIKROTIK, 2015).

O sistema Mikrotik RouterOS dispe de um firewall que permite filtrar os pacotes trans-
mitidos pela rede, fornecendo funes de segurana. O firewall suporta a funo de Network
Translation Address NAT, o que previne o acesso no autorizado direto redes conectadas
em um mesmo roteador. O firewall do RouterOS permite ainda marcao de pacotes de acordo
com parmetros estabelecidos pelo administrador e tratamento destes pacotes de forma diferenci-
ada pelo sistema, como por exemplo, transmisso com prioridades diferenciadas, velocidades de
transmisso diferenciada, ou tratamento de rotas especficas deste contedo (MIKROTIK, 2015).

O firewall do Mikrotik RouterOS conta tambm com um filtro de contedo baseado em en-
dereos de destino e origem especficos, lista de endereos IP, podendo ser esttica ou dinmica,
filtro por padro em seu contedo e/ ou ainda, expresses regulares. Alm destes parmetros, o
firewall do Mikrotik RouterOS pode ainda aplicar filtros baseados em portas especficas ou en-
tre um escopo de portas. Esses recursos permitem uma ampla granularidade de proteo rede
de computadores, permitindo o controle de acesso atravs da utilizao de diversos parmetros
(MIKROTIK, 2015).

Alm dos recursos mencionados anteriormente, conta com recursos de Servidor Web-
Proxy, Quality of Service-QoS, Servio de Hotspot, Dynamic Host Configuration Protocol-
 32

DHCP, Point-to-Point Protocol over Ethernet -PPPoE, Virtual Private Network-VPN, Multi Pro-
tocol Label Switching-MPLS, Virtual Private LAN Service-VPLS, etc. Como pode-se observar,
o RouterOS um sistema completo para finalidade que se destina, podendo ser amplamente
utilizado para as mais diversas funcionalidade de controle, gerncia e proteo de redes de com-
putadores de pequeno, mdio e grande porte (MIKROTIK, 2015).

O sistema RouterOS conta ainda com uma lista de ferramentas para auxiliar o administra-
dor do sistema, como por exemplo, teste de resposta (PING), ferramenta para testar a largura de
banda entre dois pontos, analisador de pacotes (Sniffer), analisador de conexes (Torch), agen-
dador de tarefas para execuo automtica de script, entre outras (MIKROTIK, 2015).

O sistema Mikrotik RouterOS acompanha nativamente os dispositivos RouterBOARD.

Apesar de contar com uma hardware dedicado, otimizado e desenvolvido para esta finalidade,
pode ser instalado em um dispositivo com arquitetura PC(x86), transformando um simples com-
putador em um poderoso sistema de roteamento e controle de redes de computadores. Uma das
principais caractersticas dos produtos Mikrotik a capacidade de combinar diferentes tecnolo-
gias de transmisso em um mesmo dispositivo, permitindo, por exemplo, adicionar cartes de
diferentes tecnologias de transmisso sem fio a um mesmo dispositivo sendo todos gerenciados
pelo mesmo sistema (MIKROTIK, 2015).

Para configurao e administrao do sistema, o Mikrotik RouterOS dispe de uma fer-

ramenta fornecida pela prpria Mikrotik para realizar a configurao do sistema, denominada
Winbox. Alm do acesso via ferramenta WINBOX, permite sua configurao do acesso via Tel-
net e Secure Shell - SSH, onde disponibiliza um console para execuo de comandos de modo
em linha de comando. Alm destes modos de acesso, o Mikrotik RouterOS conta com uma inter-
face web, muito eficiente e de fcil utilizao, disponibilizando grande parte das configuraes
disponveis em outros modos. A Figura 8 apresenta a tela de configurao do sistema utilizando
a ferramenta WINBOX (MIKROTIK, 2015).
 33

Figura 8: Ferramenta de configurao Winbox da Mikrotik

Nesta tela pode-se observar um grfico de acompanhamento da interfaces (selecionvel),

bem como uma apresentao de todas as interfaces do tipo ethernet disponveis para uso no hard-
ware no caso uma RouterBoard 1100 AHX2). O Winbox ainda permite monitorar em tempo real
informaes sobre utilizao do processador, memria de acesso randmico disponvel, tempo
que o equipamento est ligado e data/hora do sistema. esquerda apresentado o menu com as
opes de configurao e funcionalidades do sistema.

Alm da interface grfica e acesso via console (SSH e TELNET) existe ainda uma Appli-
cation Programming Interface - API de integrao, disponvel em diversas linguagens de pro-
gramao, inclusive em Hypertext Preprocessor - PHP, PERL, C#, Python, Java, entre outras.
Esta API tem o mesmo poder de configurao do acesso via console, entretanto, permite inte-
grar outros sistemas ao Mikrotik RouterOS de forma automatizada e simplificada (MIKROTIK,
2015).

Comparado s outras solues de firewall, como por exemplo o sistema IPTABLES e

IPFW, o sistema Mikrotik RouterOS se mostra como uma soluo eficaz por se tratar de uma
proposta de hardware e software desenvolvidos buscando aproveitar ao mximo o potencial um
do outro. No caso da soluo da Mikrotik, tanto o software quanto o hardware so especialmente
 34

desenvolvidos para um propsito especfico e suas arquiteturas so otimizadas para tais tarefas
(MIKROTIK, 2015).

Ainda, as solues desenvolvidas pela Mikrotik podem ser aplicadas em diversos cen-
rios. Pode-se tanto utilizar solues Mikrotik para redes domsticas quanto, por exemplo, para
solues para gerenciamento e controle de provedores de acesso internet. Alm disso, estas
solues podem desempenhar a grande maioria das funcionalidades de solues que apresentam
um custo mais elevado, como por exemplo, solues da lder de mercado Cisco e seu maior
concorrente, a Juniper.

importante destacar que sistemas como o IPTABLES so solues que dependem, em

geral, de um sistema operacional de propsito geral para operarem. Alm disso, sua instalao
realizada, por padro, sobre um hardware tambm de propsito geral, diferentemente da soluo
da Mikrotik.

Ainda traando um comparativo entre a soluo Mikrotik e outras solues de proteo e

controle, relevante lembrar que este sistema, diferente das demais aplicaes apresentadas que
tratam exclusivamente da funo de firewall, uma soluo especialista, completa e aplicada as
mais diversas finalidades de gesto de redes. (MIKROTIK, 2015)
 4 TRABALHO DESENVOLVIDO

A operao do sistema foi dividida em trs etapas. A primeira delas refere-se a deteco
dos ataques. Esta tarefa responsabilidade do IDS SNORT, operando como NIDS, o qual tem
como principal funcionalidade identificar, registrar e notificar o administrador do sistema. A se-
gunda refere-se ao sistema intermedirio, foco deste trabalho, o qual tem a finalidade de capturar
os registros do NIDS SNORT, extrair as informaes e utiliz-las na formatao das regras de
proteo. E por fim, a terceira trata da aplicao das regras criadas pelo sistema intermedirio no
sistema de firewall do sistema Mikrotik RouterOS.

4.1 Arquitetura

A arquitetura desenvolvida para este sistema est distribuda em trs etapas, conforme
mencionado anteriormente. Desta forma, o sistema est dividido em (i) Deteco, (ii) Extrao e
Converso e (iii) Aplicao, conforme apresenta a Figura 9, onde ilustrado o fluxo dos proces-
sos do sistema. Cada uma destas etapas detalhada na seo 4.2. Contudo, esta seo refere-se
as funcionalidades de cada uma destas etapas.

Figura 9: Fluxo dos processos do sistema desenvolvido

 36

4.1.1 Deteco

A fase de deteco responsvel por identificar os ataques. Para isso, utiliza-se o NIDS
SNORT para avaliar o trfego transmitido pela rede com o objetivo de identificar atividades sus-
peitas, ou ainda, ataques rede. Sempre que identificado um incidente com tais caractersticas,
realizado o registro desta ocorrncia, onde so armazenadas informaes, como por exemplo, os
endereos IPs de origem e de destino. Neste registro, pode-se ainda inserir informaes sobre a
assinatura do ataque e/ou porta utilizada, bem como tipo de protocolo utilizado.

Para cada ocorrncia o NIDS SNORT gera um registro. Com isso, todas as atividades
consideradas como suspeitas ficam devidamente armazenadas em um arquivo de texto ou em
banco de dados. Para o desenvolvimento deste trabalho, foram utilizados complementos que
permitiram que estas informaes fossem armazenadas em uma base de dados, melhorando con-
sideravelmente o acesso e processamento destas informaes. Esta base de dados utilizada
pela prxima etapa como fonte de conhecimento, isto , de onde extrado todo o contedo
necessrio para operao das prximas fases do processo.

Para que fosse possvel identificar ataques ou acessos no permitidos, primeiramente foi
necessrio estabelecer uma "poltica de utilizao da rede". Para isso, foram elaboradas regras de
deteco onde o NIDS SNORT pudesse identificar situaes que desrespeitassem estas polticas,
as quais estabelecem as seguintes restries:

Usurios da rede interna no podem acessar websites via porta TCP 80, tanto no ambiente
interno quanto externo;

Utilizar o servio de Domain Name System - DNS para resoluo de nomes, via porta UDP
53;

No utilizar servios de File Transfer Protocol - FTP;

No permitir acesso externo a servios de website, tambm via porta TCP 80;

No permitir conexes externas repetitivas e conexes internas ao servidor de base de

dados MySQL, via porta TCP 3306;
 37

Alm de identificar hosts que desrespeitem essas polticas, foi elaborada uma regra que
permitisse ao NIDS SNORT identificar ataques externos de PING Flood, isto , onde um atacante
envia inmeras requisies de PING sem aguardar resposta, com o intuito de sobrecarregar o
sistema e atingir a indisponibilidade de recursos e servios do host atacado.

Para cada situao descrita nestas polticas foi criada uma regra de deteco junto ao NIDS
SNORT. Cada regra, quando infringida dispara automaticamente um alerta. Ao disparar este
alerta, o NIDS SNORT registra a ocorrncia e os endereos IP dos hosts envolvidos, fornecendo
informaes para a prxima fase, descrita na Seo 4.1.2.

4.1.2 Extrao e Converso

Aps o NIDS SNORT identificar e registrar os ataques contra a rede, necessrio utilizar
estas informaes para proteger a rede. Na segunda etapa da operao do sistema, realizada a
leitura dos registros realizados pelo NIDS SNORT, a extrao das informaes e formatao das
regras de proteo que sero aplicadas ao mdulo de firewall do sistema Mikrotik RouterOS. A
Figura 10 apresenta a estrutura de registro de deteco do IDS SNORT, onde possvel verificar
as informaes possveis de serem extradas, relevantes criao de regras de controle para o
firewall do Mikrotik RouterOS.

Figura 10: Informaes registradas pelo NIDS SNORT

Neste arquivo possvel identificar o endereo que originou o ataque e qual o host de
destino do ataque. Da mesma forma, pode-se identificar a regra que gerou o alerta e quando o
ataque ocorreu. Ainda possvel identificar o protocolo e as portas utilizadas no ataque.

Com estas informaes j possvel a criao de regras que impeam o acesso deste host
de origem rede, prevenindo novos ataques descritos nas regras utilizadas. Nesta etapa o sistema
intermedirio captura estas informaes do registro das ocorrncias e realiza a identificao dos
atributos necessrios para elaborar as regras de proteo, como por exemplo, endereo IP de
origem utilizado para realizar o ataque.

As informaes extradas do registro de ocorrncias do NIDS SNORT so aplicadas na

 38

criao das regras de proteo do sistema de firewall do Mikrotik RouterOS e servem para po-
pular uma lista de hosts classificados como suspeitos junto ao sistema Mikrotik RouterOS.
Os endereos de IP identificados como origem do ataque so inseridos nesta lista e tero o seu
acesso rede negado pelo firewall permanentemente at que o administrador remova-os desta
lista de controle. Com esta abordagem, busca-se minimizar problemas de deteco do tipo falso
negativo, isto , permitir acesso rede aos hosts identificados como "suspeitos".

Contudo, necessrio realizar uma validao destes endereos de origem. Os endereos IP

identificados como origem no sero registrados na lista de suspeitos antes de uma validao,
isto , caso estejam registrados em outra lista: a lista de hosts confiveis. Esta lista mantida
pelo administrador da rede e identifica os hosts que no devem ter o acesso rede bloqueado,
mesmo que identificados como origem de um possvel ataque pelo NIDS SNORT.

Esta abordagem busca evitar o bloqueio de ocorrncias de falsos positivos, isto , quando
acessos legtimos rede so identificados como ataques. Ambas as listas podem ainda ser ma-
nipuladas pelo administrador do sistema de forma manual atravs de um painel de gerncia do
sistema. prudente mencionar que para evitar falhas do sistema, o administrador tome as medi-
das de segurana cabveis para evitar que, de fato, um dispositivo inserido como "confivel" no
seja vtima de um ataque e realize ataques contra sua estrutura de rede.

Aps identificar e gerar as regras de proteo, necessrio aplic-las ao sistema de proteo

da rede, isto , ao sistema de firewall. A seo seguinte apresenta como o sistema realiza a
aplicao das regras geradas no mdulo de firewall do Mikrotik RouterOS, efetivando a proteo
contra os atacantes.

4.1.3 Aplicao

Aps a extrao e elaborao das regras de controle de acesso aos hosts identificados e
validados como "suspeitos" necessrio executar a insero destas regras no sistema de firewall
para que se tornem ativas. Desta forma, o sistema estabelece uma conexo atravs da API dis-
ponibilizada pela Mikrotik, utilizando a linguagem PHP, e realiza a execuo do conjunto de
comandos necessrios para registro destas informaes, efetivando sua aplicao.
 39

Primeiramente, aps a conexo com o sistema Mikrotik, realizada a criao de bloqueio

total de acesso para todos os hosts que sero inseridos na lista de "suspeitos". Aps, realizada a
insero dos endereos identificados como origem do ataque na lista de hosts suspeitos. Assim,
o acesso rede totalmente negado a estes hosts, impedindo novos ataques atravs da regra de
firewall. vlido destacar que, ao passo que se restringe o acesso de hosts potencialmente
perigosos rede, reduz-se tambm o volume de dados maliciosos, permitindo ao NIDS SNORT
dedicar recursos computacionais identificao de outros ataques com origens diferentes dos
hosts j identificados. A Figura 11 mostra uma viso geral do projeto.

Figura 11: Viso geral do projeto

importante salientar que este trabalho no tem foco na identificao dos ataques, mas sim
na proteo da rede, utilizando-se dos registros de deteco. Assim, toda e qualquer melhoria
aplicada fase de deteco do NIDS SNORT tende a ser refletida em melhorias no sistema de
proteo. Desta forma, o sistema desenvolvido trata-se de um automatizador de tarefas de res-
ponsabilidade do administrador. Assim, o sistema possibilita transformar registros de deteco
em regras de proteo, reduzindo a interveno do administrador do sistema na realizao des-
tas tarefas atravs da automatizao destas atividades.

Esta seo apresentou as funcionalidades e organizao de cada etapa do sistema interme-

dirio desenvolvido e responsvel pela integrao das duas ferramentas de proteo, isto , o
NIDS SNORT e o firewall do sistema Mikrotik RouterOS. A seguir, a seo 4.2 apresenta em
detalhes a estruturao, fluxo de operaes e aes executadas pelo sistema em cada uma das
 40

etapas.

4.2 Modelagem

Esta seo detalha a operao das trs etapas em que o sistema foi dividido. A etapa de
deteco apresentada na subseo 4.2.1. J a etapa de captura das informaes e extrao dos
dados abordada na subseo 4.2.2. Por fim, na subseo 4.2.3 refere-se a aplicao das regras
de proteo, isto , a etapa em que as informaes extradas dos registros de deteco do NIDS
SNORT so transformadas em regras de firewall do sistema Mikrotik RouterOS.

4.2.1 Etapa de Deteco

A etapa de deteco realizada exclusivamente pelo NIDS SNORT, o qual responsvel

por analisar o contedo dos pacotes de dados que so transmitidos pela rede. Caso identificada
alguma atividade maliciosa, realizado o registro deste evento, gravando as seguintes informa-
es em uma base de dados:

Data e hora da ocorrncia

Endereo de origem do ataque

Endereo de destino do ataque

Regra que disparou o alerta

ID do registro

Assinatura do ataque

Protocolo utilizado

Porta utilizada

Essa estrutura de dados utilizada para registrar todos os ataques identificados pelo NIDS.
Essa operao de registro contnua e executada enquanto o NIDS SNORT estiver em operao.
 41

As informaes contidas nesta base de dados sero utilizadas pela prxima etapa do sistema,
apresentada na subseo 4.2.2, onde detalhada a etapa de captura destes dados e transformao
destas informaes em regras de proteo que sero aplicadas ao firewall do sistema Mikrotik
RouterOS, conforme descrito na seo 4.2.3. A Figura 12 apresenta o ambiente de teste da
aplicao.

Figura 12: Ambiente de teste

A Figura 12 apresenta o ambiente utilizado para realizao dos testes e validao da apli-
cao desenvolvida. Para que fosse possvel realizar a anlise dos dados, o dispositivo com o
sistema NIDS SNORT foi conectado a uma RouterBOARD modelo 1100, a qual responsvel
por interconectar todos os demais dispositivos da rede. Contudo, foi necessrio realizar uma
configurao especial nesta RouterBOARD, denominada Interface Mirror. Desta forma, foi pos-
svel "espelhar" todo o trfego transmitido pela rede, isto , encaminhar uma cpia de todas as
informaes transmitidas pela rede, para interface de conexo do NIDS.

Aps, foi necessrio habilitar o NIDS SNORT para operar em modo promscuo, isto ,
para que ele capturasse todo o contedo que fosse direcionado para sua interface de rede. Assim,
combinando a configurao de Interface Mirror e o modo promscuo de operao, foi possvel
analisar o contedo transmitido pela rede a todos os dispositivos.

Para que fosse possvel identificar atividades que desrespeitassem as polticas estabeleci-
das pelo administrador da rede, foram elaboradas um conjunto de regras para cada situao, e
adicionalmente, uma regra para identificar um ataque de PING Flood.

Com base neste conjunto de regras de deteco, sempre que o NIDS SNORT identificar
 42

algum tipo de atividade com este perfil, automaticamente so identificados os hosts envolvidos
e as informaes de conexo entre eles. Feito isso, o NIDS SNORT realiza um registro na base
de dados de ocorrncias, inserindo informaes referentes ao ataque. A Figura 13 apresenta este
conjunto de regras e as respectivas funcionalidades.

Figura 13: Regras elaboradas para deteco do NIDS SNORT

Aps essa etapa de deteco, necessrio transformar essas informaes em regras de

proteo, com o objetivo de impedir novos ataques rede. Essa etapa do processo apresentada
na subseo 4.2.2.
 43

4.2.2 Etapa de Captura de informaes e converso em Regras de proteo

Esta seo apresenta a fase de captura dos dados dos registros do NIDS SNORT e extrao
das informaes necessrias para elaborar regras de proteo, impedindo, atravs do sistema de
firewall do Mikrotik RouterOS, o acesso de hosts identificados como origem de ataques rede
de computadores.

Esta etapa contempla o ncleo do sistema desenvolvido, pois neste momento que ocorre a
transformao das informaes contidas nos registros em regras de proteo. Para isso, o sistema
intermedirio desenvolvido opera em momentos distintos: (i) leitura das informaes de registro
do NIDS SNORT, (ii) identificao dos endereos de IP que originaram o ataque, (iii) validao
dos endereos de IP, (iv) a formatao das regras de bloqueio utilizando as informaes extradas
e (v) a aplicao destas regras ao sistema de firewall. A Figura 14 apresenta a sequncia desta
operao.

Figura 14: Sequncia de tarefas do sistema

A Figura 14 apresenta o fluxo das informaes dentro do sistema e cada etapa de operao.
 44

Ilustra ainda, o momento em que o sistema valida as informaes, buscado reduzir ocorrncias
dos falsos positivos e negativos, respeitando as listas de hosts suspeitos e confiveis.

Para facilitar a utilizao do sistema, foi desenvolvido uma interface de controle, na qual o
administrador pode facilmente adicionar e remover os endereos de IP, tanto da lista de confiveis
quando da lista de suspeitos. Esse painel de controle do sistema apresentado pela Figura 15.

Figura 15: Painel de controle do sistema

Alm das funcionalidade de controle das listas, possvel adicionar uma lista de dispositi-
vos que devero receber as regras, caso existam mais sistemas de firewall sob a responsabilidade
do administrador. Isso permite prevenir ataques de hosts j conhecidos.
 45

O painel de controle permite tambm que o administrador determine o intervalo de tempo

para realizar a verificao das informaes e aplicao das regras. Permite ainda que o admi-
nistrador coloque o sistema em "modo de espera", isto , em um modo que o sistema apenas
mantenha sua execuo sem realizar nenhum tipo de verificao ou controle.

Entretanto, para realizar as tarefas disponveis atravs do painel de controle e tambm as

tarefas de capturar e elaborar as regras de controle, o sistema utiliza de um script desenvolvido
utilizando a linguagem PHP e utilizando recursos da API, tambm desenvolvida em PHP, dis-
ponibilizada pela Mikrotik, o qual executado em segundo plano. Esse modo de execuo
possvel, pois, aps inicializado o sistema, sua execuo cclica, sem a necessidade da inter-
veno direta do administrador. Contudo, a sua operao pode ser suspensa pelo administrador
via painel de controle.

Para realizar a captura das informaes de registro, o sistema estabelece uma conexo com
a base de dados auxiliar "midle_db" onde esto armazenadas estas informaes e, realiza uma
srie de consultas e inseres ou remoes, conforme apresentado na Figura 16.

Figura 16: Consultas realizadas para capturar as informaes de registro do IDS SNORT

Na consulta denominada "query_insert_blacklist", o sistema realiza uma insero de va-

lores na tabela referente aos hosts suspeitos, denominada "ip_blacklist", pertencente a base de
dados auxiliar "midle_db". A estrutura desta base de dados auxiliar apresentada pela Figura
17.
 46

Figura 17: Base de dados auxiliar utilizada pelo sistema

Estes valores referem-se a todos os endereos de IP de origem, da tabela de registro de ocor-

rncias mantida pelo IDS SNORT, que, no esto presentes na lista de confiveis (ip_whitelist) e
que ainda no foram inseridos na tabela de suspeitos (ip_blacklist). Com essa abordagem, evita-
se duplicidade de valores na tabela de suspeitos, bem como, a criao de regras de bloqueio para
endereos definidos como confiveis, mesmo que o IDS detecte como possvel atacante.

Em seguida, a consulta "query_load_blacklist" responsvel por retornar informaes de

todos os endereos contidos na tabela "ip_blacklist" com "status=0", isto , que ainda no fo-
ram processados. J a consulta "query_system" responsvel por retornar as informaes de
operao do sistema. E, por fim, a consulta "query_check_rules" responsvel por retornar os
endereos de IP que foram removidos da tabela "ip_blacklist". Esses motivos podem ser por
que (i) o administrador inseriu o endereo de IP como confivel ou (ii) o administrador removeu
manualmente o endereo de IP da lista de suspeitos.

Para ambas as situaes, buscando garantir a integridade das regras, disparado automa-
ticamente um processo (trigger). No caso (i), todo endereo adicionado lista de confiveis
automaticamente removido da lista de suspeitos. Em consequncia disso, no caso (ii), todo
endereo de IP removido da tabela de suspeito, deve ter suas regras removidas tambm do sis-
tema de proteo do firewall do Mikrotik RouterOS. Por isso, os endereos removidos da tabela
"ip_blacklist" so automaticamente inseridos na tabela "check_rules", responsvel por realizar
 47

esta manuteno.

Com as informaes necessrias para elaborar as regras de proteo, o sistema passa a

operar na formatao das regras de controle que sero aplicadas ao sistema de firewall. A Figura
18, apresenta as regras utilizadas para inserir as informaes j processadas, utilizando a API de
controle da Mikrotik.

Figura 18: Regras formatadas para controle do firewall do Mikrotik RouterOS

A Figura 18 apresenta o conjunto de aes utilizadas para controlar o firewall do sistema

Mikrotik RouterOS. As aes apresentadas so responsveis por inserir uma regra global de
bloqueio para todos os hosts identificados, adicionar os endereos IPs a uma lista de bloqueio,
pesquisar endereos na lista de IP bloqueados e remover estes endereos desta lista. Entretanto,
aps capturar as informaes necessrio aplic-las junto ao sistema de firewall do Mikrotik
RouterOS.

4.2.3 Etapa de Aplicao das Regras

Aps a captura de todas as informaes necessrias para elaborao das regras de controle,
fundamental inserir estas regras no sistema de firewall do Mikrotik RouterOS para que elas
sejam executadas. Para isso, o sistema executa as instrues da API Mikrotik que realizam a
conexo com o sistema Mikrotik RouterOS e possibilita a execuo das instrues necessrias
para criao das regras de controle do firewall, conforme mostra a Figura 19.

Figura 19: Conexo para aplicao das regras de controle

Aps estabelecer conexo, a aplicao executa a instruo para criar uma regra global, que
 48

utilizar a lista de endereos, denominada SNORT DETECTION, para efetuar o bloqueio de

todo contedo originrio dos endereos contidos nesta lista.

Durante sua operao, o sistema tambm realiza a insero de todos os endereos contidos
na tabela "ip_blacklist" na lista de endereos que sero bloqueados pela regra geral aplicada ao
firewall. Alm disso, quando necessria a remoo de algum endereo da lista de bloqueados,
seja por remoo manual deste endereo IP por parte do administrador ou por insero deste
endereo IP na lista de confiveis, o sistema realiza uma busca na lista de bloqueados e realiza
a remoo desta regra. Com esta abordagem, o objetivo manter a integridade das polticas de
acesso estabelecidas pelo administrador. As instrues de controle do sistema de firewall so
apresentadas pela Figura 20.

Figura 20: Regras de controle do sistema de firewall para bloqueio, insero, pesquisa e remoo

Ao adotar o bloqueio total, o objetivo impedir que um host de origem de um ataque

realize novos ataques ou explore alguma outra vulnerabilidade do sistema. Da mesma forma, ao
eliminar todo e qualquer acesso de host definido como suspeito, evita-se que o sistema permita a
ocorrncia de falsos negativos.

Esta captulo apresentou a modelagem aplicada ao projeto desenvolvido e as funcionalida-

des de cada etapa do processo. Detalhou ainda, todas as operaes fundamentais do sistema e
como estas esto interligadas entre si. Os teste realizados e a metodologia aplicada para validar
este trabalho apresentada no Captulo 5.
 5 RESULTADOS

Para validar este trabalho, foi elaborado um ambiente para testar e validar este trabalho,
bem como um conjunto de regras que permitissem ao NIDS SNORT identificar atividades que
desrespeitassem a poltica de utilizao definida para a rede e/ou ataques rede. Estas regras
foram criadas para identificar hosts em um ambiente de rede laboratorial, conforme apresentado
no captulo anterior.

5.1 Metodologia

Esta Seo apresentado o ambiente elaborado para realizao dos teste, os dispositivos
utilizados e tecnologias aplicadas no projeto. Com o objetivo de validar este trabalho foi desen-
volvido o seguinte cenrio:

Para desenvolver o ambiente de teste deste projeto foi utilizado uma RouterBOARD mo-
delo 1100, com sistema Mikrotik embarcado operando na verso 6.28, como dispositivo de rede
para interconectar todos os demais dispositivos. Este dispositivo conta com um processador de
rede PowerPC de 800MHz e 512Mb de memria RAM. Alm disso, esta RouterBOARD com-
posta por 13 portas ethernet com velocidade de 1 gigabit cada, totalmente configurvel, sendo
que as 5 primeiras portas ethernet fazem parte de um switch gerenciado. Tal caracterstica per-
mitiu realizar a configurao de Port Mirror, permitindo com que o contedo transmitido pelas
demais portas de rede fosse tambm encaminhado para interface de conexo do NIDS SNORT,
permitindo com que esse contedo fosse analisado pelo sistema.

Como dispositivo denominado "Servidor IDS", responsvel por dar suporte ao sistema
NIDS SNORT e demais complementos, bem como a base de dados Mysql utilizada para regis-
trar as ocorrncias, foi utilizado um computador tipo PC, com processador Intel Core 2 Duo de
2.0 GHz e 3Gb de memria RAM, utilizando um disco com capacidade de at 1 Tb, operando a
7.200 rotaes por minuto. Este equipamento utiliza uma interface de rede tambm com veloci-
dade de 1 gigabit para comunicao. Como sistema operacional, foi utilizado o Ubuntu Server,
 50

devidamente atualizado, em sua verso 14, por questes de compatibilidade e estabilidade do

sistema para operar com o NIDS SNORT.

Para realizar a troca de informao, simulando estaes de trabalho, foram utilizados 3

computadores pessoais, de uso convencional, utilizando sistema operacional Windows 8. Estes
dispositivos foram conectados RouterBOARD e o contedo transmitidos pelas suas respectivas
interfaces de conexo, foram "espelhados" para a porta de conexo do NIDS SNORT.

Para identificar e registrar as ocorrncias, foi utilizado a verso 2.9.7 do IDS SNORT,
configurado para operar em modo NIDS. Para validao do trabalho, no foram aplicadas as
regras disponibilizadas pela comunidade do projeto, pois, conforme estudos realizados, para
obter o melhor desempenho do NIDS, as regras de deteco devem ser ajustadas conforme o
ambiente de aplicao. Como o objetivo deste trabalho no est na deteco de atividade suspeita,
mas sim na integrao das duas solues, foram utilizadas regras especficas para o ambiente de
teste, levando em considerao as polticas estabelecidas. importante salientar que toda e
qualquer melhoria na etapa de deteco resultar em uma maior proteo atravs da integrao
proposta.

Para desenvolver esse trabalho foi utilizada a linguagem de programao PHP, pela compa-
tibilidade, documentao e suporte API da Mikrotik. Tal linguagem foi definida tambm pela
sua flexibilidade de desenvolver aplicaes web, permitindo com que o sistema seja utilizado em
diferentes plataformas.

5.2 Testes Realizados

Para simular os acessos na rede de teste foram utilizados computadores que receberam seus
endereos de IP dinamicamente atravs de um servidor DHCP configurado na RouterBOARD.
Aps, foram realizados diferentes tipos de acessos aos servios que infringissem politica de
utilizao da rede, conforme representado pela Figura 21.
 51

Figura 21: Ambiente desenvolvido para os testes de validao

O Ambiente ilustrado pela Figura 21 apresenta o ambiente de teste desenvolvido, onde so

identificados os hosts capazes de realizar algum tipo de atividade que desrespeite as polticas
impostas rede. Tais atividades podem ocorrer contra qualquer outro elemento da rede. Da
mesma forma que os ataques podem ocorrer tanto dentro do mesmo ambiente de rede quanto
podem ser originados de fora do ambiente de rede.

Para validar a regra de deteco de acessos aos servios que utilizam a porta 80, foram
realizados acessos aos websites que utilizam o protocolo Hypertext Transfer Protocol, que por
padro utiliza a porta TCP para sua comunicao. Ainda foram realizados acessos ao servidor
de pginas configurado junto ao NIDS SNORT, o que tambm no permitido de acordo com
politica estabelecida. Ao acessar estas pginas, automaticamente, atravs da resoluo de nomes,
tambm foi validada a deteco para o servio de DNS, o qual utiliza por padro a porta UDP
53.

Para verificar a regra que trata da porta TCP 3306, padro para conexes com base de dados
Mysql, foram realizados acessos de uma rede externa base de dados instalada junto ao servidor
NIDS SNORT. Da mesma forma, foram realizados acessos, internamente rede, a mesma base,
o que tambm contraria as regras de deteco.

Ainda sobre os testes de deteco, foi simulada uma tentativa de PING Flood, utilizando
a ferramenta disponvel pelo sistema Mikrotik RouterOS. Neste teste foram enviadas 1000 re-
quisies de PING, com intervalo de 1 milissegundo entre elas, contra o NIDS SNORT (IP
 52

10.1.1.254).

J no que diz respeito a funcionalidades do sistema, o intervalo de tempo de verificaes

foi alterado do valor padro de 10 segundos para 30 segundos e observado a operao do sistema.
Da mesma forma, que a funcionalidade de suspenso do servio, que foi ativada e desativada,
buscando validar este recurso.

Aps, foram realizados testes para validar os recursos de controle de listas de endereos
IP, onde foram adicionados endereos lista de confiveis e verificado o tratamento do sistema
estes endereos. Da mesma forma, foram realizadas a remoo destes endereos da lista de
confiveis e observado se o sistema tornava a considerar estes endereos para criao das regras
de proteo.

Os resultados obtidos atravs dos testes realizados so abordados e ilustrados na seo 5.3,
onde so detalhadas estas informaes.

5.3 Resultados Obtidos

Os resultados obtidos atravs da anlise da utilizao da rede foram os esperados. O sis-

tema NIDS SNORT conseguiu, atravs das regras elaboradas, identificar os testes realizados e
registrar as informaes referentes estas ocorrncias com sucesso.

No caso do acesso websites utilizando a porta TCP 80, o NIDS SNORT identificou e
registrou as ocorrncias, as quais foram utilizadas pelo sistema para a gerao das regras de
proteo. Da mesma forma que o sistema desenvolvido foi capaz de ler as informaes do regis-
tro do NIDS SNORT e realizar a insero destas informaes tabela auxiliar, responsvel por
armazenar os endereos de IP que tero seu aceso bloqueado (midle_db.ip_blaclist), conforme
ilustra a Figura 22.
 53

Figura 22: Registros do NIDS, verificao e insero de endereos na tabela de bloqueio

Na Figura 22.a identificada a regra de deteco (1000991) responsvel pelo registro apre-
sentado pela figura 22.b, que exibe os valores referentes regra de deteco que gerou o registro,
o protocolo utilizado, endereo de origem e destino e a porta de comunicao, respectivamente.
Por fim, a figura 22.c mostra o endereo de IP de origem desta deteco (10.1.1.251) inserido na
tabela midle_db.ip_blacklist, a qual responsvel por armazenar as informaes dos hosts que
devem ser bloqueados.

No que diz respeito simulao de ataque de PING Flood, utilizando a ferramenta dis-
ponvel pelo sistema Mikrotik, o sistema NIDS SNORT foi capaz de identificar e registrar este
ataque. A Figura 23.a ilustra a utilizao da ferramenta e apresenta, na Figura 23.b o registro
gerado pelo NIDS SNORT fazendo referncia regra de deteco desenvolvida.
 54

Figura 23: Simulao de PING Flood utilizando ferramenta do Mikrotik RouterOS

Apesar de ter simulado o ataque de PING Flood atravs da RouterBOARD Mikrotik, a qual
estava utilizando o endereo IP 10.1.1.1, este foi apenas detectado, sem a insero do mesmo na
lista de bloqueio. Isto por que este endereo IP est presente na lista de confiveis, conforme
mostra a Figura 24. Esse resultado apresentado, valida com sucesso operao do sistema res-
peitando a lista de confiveis, evitando o bloqueio do acesso aos hosts e reduzindo a ocorrncia
de falsos positivos.

Figura 24: Informaes nas tabelas de controle do sistema

A Figura 24.a mostra as informaes presentes na tabela midle_db.ip_blacklist, isto , os

endereos de IP que devem ser bloqueados. J a Figura 24.b apresenta as informaes de hosts
confiveis, ou seja, os endereos de IP registrados que mesmo que detectado, no tero regras de
bloqueio geradas. Por fim, a Figura 24.c ilustra todos os endereos de IP detectados pelo NIDS
SNORT.
 55

Sobre os testes de acesso base de dados Mysql utilizando a porta TCP 3306, o NIDS
SNORT foi capaz de identific-los com sucesso. Tambm identificou as tentativas de comunica-
o com servidores DNS utilizando a porta UDP 53. A Figura 25 apresenta as regras responsveis
por essa deteco e os registros realizados pelo NIDS SNORT.

Figura 25: Exemplos de regras disparadas e registro do IDS

A Figura 25.a exibe a regra de deteco referente deteco de acessos base Mysql e o
respectivo registro do IDS quando esta regra disparada. Por sua vez, a Figura 25.b apresenta a
regra referente requisies DNS e o respectivo registro realizado. Em ambos os casos possvel
observar nos registros as informaes de endereos IP de origem e destino, a regra que se refere,
cdigo do protocolo utilizado e portas de comunicao, respectivamente.

Atravs dos alertas gerados pelo NIDS SNORT, o sistema desenvolvido tambm conseguiu
identificar os endereos de IP de origem dos ataques e bloquear o acesso destes dispositivos
rede, atravs da insero deste endereos de IP na lista de endereos do firewall do Mikrotik
RouterOS, respeitando a lista de hosts confiveis.

Foram verificados se os endereos de IP registrados como suspeitos, isto , aqueles que

devem ter regras de bloqueio junto ao firewall do Mikrotik RouterOS, de fato, estavam inseridos
na lista de bloqueio SNORT_DETECTION do firewall. A Figura 26.a apresenta os endereos
inseridos na tabela midle_db.ip_blacklist. J a imagem 26.b a lista gerada no sistema de firewall,
com todos os endereos devidamente inseridos.
 56

Figura 26: Comparativo: Informaes de registro X Regras firewall

O sistema tambm foi capaz de realizar a remoo dos endereos de IP da lista de blo-
queio do Mikrotik RouterOS, quando estes endereos de IP foram adicionados lista de hosts
confiveis. Desta forma garantiu-se as configuraes estabelecidas pelo administrador. Essa fun-
cionalidade validou o controle das tabelas do sistema e a aplicao da trigger, apresentada pela
Figura 27, responsvel por manter a integridade destas regras.

Figura 27: Trigger aplicada tabela de hosts confiveis

Para avaliar o tempo de processamento e fornecer valores de referncia ao que diz respeito
ao desempenho do sistema foram aferidos valores para o tempo de processamento das informa-
es e consumo de recursos do sistema.

Tempo de leitura para os 6 endereos de IP identificados: 0.012 milissegundos.

importante destacar que neste cenrio a aplicao, o NIDS e base de dados operam no
mesmo dispositivo;

Tempo para processamento: apresentou variao de 0,12 ao mximo de 0,36 milisse-

gundos, considerando como tempo de processamento o intervalo de tempo necessrio para
realizar a leitura, validao dos 6 registros e insero e/ou remoo no sistema de firewall
do Mikrotik RouterOS;

Ciclo total: consiste no tempo para processamento adicionado do tempo de latncia at o

dispositivo que receber as regras. Este tempo de latncia depende diretamente da distri-
buio fsica do dispositivo Mikrotik. Nos testes realizados o dispositivo estava conectado
 57

diretamente ao dispositivo do NIDS SNORT, com tempo de resposta inferior a um milis-

segundo;

Consumo de memria do sistema: O sistema em operao contnua, no ultrapassou o

consumo mximo de 4,7 Megabytes de memria, operando na maioria das vezes com um
consumo estvel de 4,6 Megabytes;

Uso de processador: Ao que se refere utilizao do processador, no foi possvel aferir

valores significativos, permanecendo em 0% durante toda a execuo.

Com base nestes valores o administrador do sistema pode estimar o tempo de processa-
mento e o volume mximo de dados processado em um ciclo, o que possibilita a ele ajustar o
tempo de ciclo conforme a demanda de seu sistema.

Finalizando, possvel afirmar que, dentro do ambiente testado, o NIDS SNORT foi capaz
de identificar ataques baseado nas regras desenvolvidas. Da mesma forma o sistema proposto
cumpriu com seu objetivo e realizou o bloqueio do acesso dos hosts identificados como sus-
peitos. Para realizar esse bloqueio, o sistema utilizou-se dos registros de deteco, atravs de
regras inseridas automaticamente no sistema de firewall do Mikrotik RouterOS, formando uma
ferramenta reagente aos ataques.
 6 CONCLUSO E CONSIDERAES FINAIS

Os resultados obtidos atravs dos testes realizados com o trabalho desenvolvido permitem
afirmar que a integrao entre o IDS SNORT e o sistema de firewall do Mikrotik RouterOS foi
possvel. Tais resultados demonstraram que o sistema intermedirio implementado foi capaz de
aplicar, de forma automatizada, regras de controle de acesso ao sistema de firewall e impedir o
acesso de hosts identificados como suspeitos.

Desta forma, o trabalho apresentado mostra que o processo de automatizao de reao

aos ataques identificados pelo IDS SNORT possvel e independente da interveno direta do
administrador do sistema. vlido ressaltar que o sistema proposto ainda no totalmente auto-
matizado, sendo dependente da interveno do administrador para configuraes de inicializao,
tempo de ciclo do processo e de insero de hosts estabelecidos como confiveis.

Como melhorias possveis aplicveis ao sistema desenvolvido, pode-se mencionar a pos-

sibilidade de integrao do presente trabalho com outros sistemas de IDS e outros sistemas de
firewall. Contudo, estas novas integraes demandam estudos mais aprofundados sobre mtodos
possveis de comunicao entre estes sistemas e padres de registro das informaes dos IDSs.

Outro ponto que pode ser estudado com ateno diz respeito ao tempo timo de ciclo de
leitura das informaes de registro, isto , o menor tempo de ciclo necessrio para processar estas
informaes, possibilitando ao sistema repetir o processo com menos tempo ocioso possvel. Ao
mesmo tempo, passvel de estudos especficos, o tema que trata sobre a performance do IDS
caso o registro de ocorrncias seja realizado em uma base de dados instalada em outro dispositivo
e a aplicao de regras em dispositivos geograficamente distribudos. Esse tema pode implicar
diretamente no clculo do tempo timo do ciclo de leitura das informaes.

Outra rotina que pode ser implementa e testada no que diz respeito integrao e insero
de regras em um conjunto de dispositivos Mikrotik. O sistema apresenta uma implementao
inicial desta funcionalidade, porm esta etapa no foi testada e avaliada. Pontos como o tempo
 59

necessrio para realizar um ciclo de inseres e como tratar casos onde existe um volume grande
de regras para realizar as suas aplicaes podem ser foco de estudos futuros, uma vez que este
trabalho considerou um dispositivo Mikrorik e um baixo volume de regras para serem aplicadas.

Por fim, alm das melhorias sugeridas, importante destacar que otimizaes aplicadas
fase de deteco do IDS automaticamente so refletidas na gerao de regras de proteo. Desta
forma, o desenvolvimento de novos algoritmos e mtodos de deteco, bem como tambm, o
aprimoramento dos existentes, so uma boa direo para pesquisas futuras.
 REFERNCIAS

AHMED, M.; PAL, R.; HOSSAIN, M.; BIKAS, M.; HASAN, M. NIDS: a network based
approach to intrusion detection and prevention. In: COMPUTER SCIENCE AND
INFORMATION TECHNOLOGY - SPRING CONFERENCE, 2009. IACSITSC 09.
INTERNATIONAL ASSOCIATION OF, 2009. p.141144.

AL-JARRAH, O.; ARAFAT, A. Network Intrusion Detection System using attack behavior
classification. In: INFORMATION AND COMMUNICATION SYSTEMS (ICICS), 2014 5TH
INTERNATIONAL CONFERENCE ON, 2014. p.16.

ANAND, Vijay. Intrusion Detection: tools, techniques and strategies. In: ND ANNUAL ACM
SIGUCCS CONFERENCE ON USER SERVICES, 42., 2014, New York, NY, USA. ACM,
2014. p.6973.

BHUYAN, M.; BHATTACHARYYA, D.; KALITA, J. Network Anomaly Detection: methods,

systems and tools. Communications Surveys Tutorials, IEEE, v.16, n.1, 2014. p.303336.

BISHOP, Matt. Introduction to Computer Security. Addison-Wesley Professional, 2004.

BRO. The Bro Network Security Monitor. Disponvel em: <https://www.bro.org/>. Acesso em:
Dezembro de 2015.

BULAJOUL, W.; JAMES, A.; PANNU, M. Network Intrusion Detection Systems in

High-Speed Traffic in Computer Networks. In: IEEE 10TH INTERNATIONAL
CONFERENCE ON E-BUSINESS ENGINEERING, 2013., 2013, Washington, DC, USA.
IEEE Computer Society, 2013. p.168175.

CHAUDHARI, N.; TIWARI, A.; THAKAR, U.; THOMAS, J. Semi-supervised classification

for intrusion Detection System in networks. In: CYBERNETICS AND INTELLIGENT
SYSTEMS (CIS), 2010 IEEE CONFERENCE ON, 2010. p.120125.

COMER, Douglas. Internetworking with TCP/IP: principles, protocols, and architecture. Upper
Saddle River, NJ, USA: Prentice-Hall, Inc., 1988.

DENNING, D.E. An Intrusion-Detection Model. Software Engineering, IEEE Transactions on,

Fevereiro de 1987. v.SE-13, n.2, p.222232.
 61

HEBERLEIN, L.; DIAS, G.; LEVITT, K.; MUKHERJEE, B.; WOOD, J.; WOLBER, D. A
network security monitor. In: RESEARCH IN SECURITY AND PRIVACY, 1990.
PROCEEDINGS., 1990 IEEE COMPUTER SOCIETY SYMPOSIUM ON, 1990. p.296304.

HOQUE, N.; BHUYAN, M. H.; BAISHYA, R.; BHATTACHARYYA, D.; KALITA, J. Network
Attacks. J. Netw. Comput. Appl., London, UK, UK, Abril de 2014. v.40, n.C, p.307324.

HUANG, X.; WANG, X.; ZHU, S. Study on Intelligent Firewall System Combining Intrusion
Detection and Egress Access Control. In: INTELLIGENT SYSTEM DESIGN AND
ENGINEERING APPLICATION (ISDEA), 2010 INTERNATIONAL CONFERENCE ON,
2010. v.2, p.456459.

HUBBALLI, N.; SURYANARAYANAN, V. Review: false alarm minimization techniques in

signature-based intrusion detection systems: a survey. Comput. Commun., Amsterdam, The
Netherlands, The Netherlands, Agosto de 2014. v.49, p.117.

JUNQI, W.; ZHENGBING, H. Study of Intrusion Detection Systems (IDSs) in Network

Security. In: WIRELESS COMMUNICATIONS, NETWORKING AND MOBILE
COMPUTING, 2008. WICOM 08. 4TH INTERNATIONAL CONFERENCE ON, 2008. p.14.

LEE, J.; HWANG, S. H.; PARK, N.; LEE, S.-W.; JUN, S.; KIM, Y. S. A High Performance
NIDS Using FPGA-based Regular Expression Matching. In: ACM SYMPOSIUM ON
APPLIED COMPUTING, 2007. p.11871191.

LEI-JUN, L.; HONG, P. A Defense Model Study Based on IDS and Firewall Linkage. In:
INFORMATION SCIENCE AND MANAGEMENT ENGINEERING (ISME), 2010
INTERNATIONAL CONFERENCE OF, 2010. v.2, p.9194.

MIKROTIK. Mikrotik. Disponvel em: <http://www.mikrotik.com/>. Acesso em: Dezembro

de 2015.

NJOGU, H. W.; JIAWEI, L.; KIERE, J. N.; HANYURWIMFURA, D. A Comprehensive

Vulnerability Based Alert Management Approach for Large Networks. Future Gener. Comput.
Syst., Amsterdam, The Netherlands, The Netherlands, Janeiro de 2013. v.29, n.1, p.2745.

PAXSON, Vern. Bro: a system for detecting network intruders in real-time. In: CONFERENCE
ON USENIX SECURITY SYMPOSIUM - VOLUME 7, 7., 1998, Berkeley, CA, USA.
USENIX Association, 1998. p.33.
 62

RAGHUNATH, B. R.; MAHADEO, S. N. Network Intrusion Detection System (NIDS).

Emerging Trends in Engineering & Technology, International Conference on, Los Alamitos,
CA, USA, v.0, 2008. p.12721277

SHERRY, J.; LAN, C.; POPA, R. A.; RATNASAMY, S. BlindBox: deep packet inspection over
encrypted traffic. SIGCOMM Comput. Commun. Rev., New York, NY, USA, Agosto de 2015.
v.45, n.5, p.213226.

SNORT. The Snort Project. Disponvel em: <http://www.snort.org/>. Acesso em: Dezembro
de 2015.

SOUZA, L. D. F.; LUCA, G. G. de. Lei 12.965 de 2014: democratizao da internet e efeitos do
marco civil na sociedade da informao. In: REVISTA PARADIGMA, 2014. p.7696.

TANENBAUM, A. S.; WETHERALL, D. J. Computer Networks. 5th.ed. Upper Saddle River,

NJ, USA: Prentice Hall Press, 2010.

VACCA, John R. Computer and Information Security Handbook, Second Edition. 2nd.ed. San
Francisco, CA, USA: Morgan Kaufmann Publishers Inc., 2013.

VALGENTI, V.; SUN, H.; KIM, M. S. Protecting Run-Time Filters for Network Intrusion
Detection Systems. In: ADVANCED INFORMATION NETWORKING AND
APPLICATIONS (AINA), 2014 IEEE 28TH INTERNATIONAL CONFERENCE ON, 2014.
p.116122.

ZAMAN, S.; KARRAY, F. TCP/IP Model and Intrusion Detection Systems. In: ADVANCED
INFORMATION NETWORKING AND APPLICATIONS WORKSHOPS, 2009. WAINA 09.
INTERNATIONAL CONFERENCE ON, 2009. p.9096.