IREMAC: Um IPS para Ataques Internos

Abstract

Abstract— The diversity of denial of service attacks create
the need for advances in tools that can reduce impacts on
the inaccessibility of service. These tools use techniques mostly
focused on prevent attack through containment measures. The
work proposed is the creation of an IPS called IREMAC,
responsible for making the restriction of an attacker by IP
and MAC addresses. That restriction is focuses on attacks that
take place within the network. The results demonstrate that
the proposed solution presents a gain in performance on server
response delay after an attack and reduce false positives that
prevent legitimate communications.

Full text

XXXIV SIMP ´
OSIO BRASILEIRO DE TELECOMUNICAC¸ ˜
OES - SBrT2016, 30 DE AGOSTO A 02 DE SETEMBRO, SANTAR ´
EM, PA
IREMAC: Um IPS para Ataques Internos
Camilla Alves Mariano da Silva, J´
essica Alcˆ
antara Gonc¸alves, Vinicius da Silva Faria, Gabriele de Britto Vieira,
Dalbert Matos Mascarenhas
Resumo— A diversidade dos ataques de negac¸ ˜
ao de servic¸o
criam a necessidade de avanc¸os em ferramentas que possam
reduzir os impactos relativos `
a inacessibilidade do servic¸o. Estas
ferramentas em sua maioria objetivam prevenir ataques, atrav´
es
de medidas de contenc¸ ˜
ao. O trabalho proposto, ´
e a criac¸ ˜
ao de um
IPS denominado IREMAC, respons´
avel por fazer a contenc¸ ˜
ao
de ataques com base nos enderec¸os IP e MAC de m´
aquinas
situadas na rede interna. Os resultados demostram que a soluc¸ ˜
ao
proposta apresenta desempenho satisfat´
orio em relac¸ ˜
ao ao tempo
de resposta do servidor ap´
os um ataque e reduc¸ ˜
ao de falsos
positivos que impedem comunicac¸ ˜
oes leg´
ıtimas.
Palavras-Chave—IPS, Seguranc¸a de Redes, DoS.
Abstract— The diversity of denial of service attacks create
the need for advances in tools that can reduce impacts on
the inaccessibility of service. These tools use techniques mostly
focused on prevent attack through containment measures. The
work proposed is the creation of an IPS called IREMAC,
responsible for making the restriction of an attacker by IP
and MAC addresses. That restriction is focuses on attacks that
take place within the network. The results demonstrate that
the proposed solution presents a gain in performance on server
response delay after an attack and reduce false positives that
prevent legitimate communications.
Keywords— IPS, Network Security, DoS.
I. INT ROD UC¸˜
AO
Um dos principais ataques realizados na Internet, ´
e o ataque
de DoS (Denial of Service) [1]. Este ataque, pode comprome-
ter recursos da rede, assim como hospedeiros de aplicac¸ ˜
oes,
como servidores de e-mail e web. Este comprometimento dos
recursos pode prejudicar usu´
arios que deveriam ter acesso aos
recursos da rede. Uma parte consider´
avel de ataques DoS
consistem em estabelecer um grande n´
umero de conex˜
oes TCP
semiabertas ou abertas no hospedeiro-alvo [2]. Desta forma,
o hospedeiro torna-se incapaz de aceitar requisic¸ ˜
oes leg´
ıtimas
devido ao grande n´
umero de conex˜
oes em espera, realizadas
pelo ataque. Ferramentas como Ettercap [3] e t50 [4] s˜
ao
utilizadas para consumir os recursos de uma m´
aquina ser-
vidora. Dentre os recursos consumidos durante um ataque,
al´
em do n´
umero de conex˜
oes em modo de espera, est˜
ao
tamb´
em parte da mem´
oria e do processamento. O consumo
destes recursos por parte do atacante pode gerar problemas
complexos relativos a disponibilidade de servic¸os e conte´
udos
por parte de seus distribuidores.
Atualmente existem diversas ferramentas e formas de ata-
ques DoS. Dentre esses tipos de ataques, existe um que ´
e capaz
Camilla Alves Mariano da Silva, J´
essica Alcˆ
antara Gonc¸ alves,
Vinicius da Silva Faria, Gabriele de Britto Vieira, Dalbert Matos
Mascarenhas¸ Engenharia de Computac¸˜
ao, Centro Federal de
Educac¸ ˜
ao Tecnol´
ogica Celso Suckow da Fonseca (Cefet/RJ) campus
Petr´
opolis, Petr´
opolis-RJ, Brasil, E-mails: calves@e-computacao.com.br,
jalcantara@e-computacao.com.br,vfaria@e-computacao.com.br, gbritto@e-
computacao.com.br, dalbert.mascarenhas@cefet-rj.br.
de mandar diversas requisic¸˜
oes a um determinado servidor ao
mesmo tempo forjando o enderec¸o IP de origem. Esta t´
ecnica
de forjar os enderec¸os de origem introduz um desafio a mais
na detecc¸˜
ao da origem dos ataques de DoS. O problema ´
e que
esses enderec¸os IP, forjados pelo atacante, podem ser inclusive
enderec¸os leg´
ıtimos da pr´
opria rede em que o servidor est´
a
localizado. Desta forma os mecanismos para detecc¸˜
ao e ou
prevenc¸˜
ao desta modalidade de ataque se torna algo crucial.
Os riscos destes ataques n˜
ao se restringem somente a m´
aquinas
que proveem servic¸os na internet, mas tamb´
em a computadores
ou smartfones de usu´
arios. Recentes estudos mostram que at´
e
mesmo autom´
oveis j´
a tiveram seus servic¸os comprometidos
atrav´
es de ataques cibern´
eticos [5].
Dentre os mecanismos de defesa, utilizados contra ataques
de DoS est˜
ao os IPSs (Intrusion Prevention System) [6].
Estes mecanismos, s˜
ao capazes de detectar e bloquear ataques
DoS. As func¸ ˜
oes de seguranc¸a destes mecanismos incorporam
diretivas como a de filtrar o tr´
afego suspeito [7]. Dentre
as ac¸ ˜
oes de restric¸˜
ao de ataques utilizadas pelos IPSs, ´
e
poss´
ıvel bloquear ac¸ ˜
oes indevidas a recursos de um servidor ou
mesmo de uma rede. O IPS ´
e capaz de identificar requisic¸ ˜
oes
anˆ
omalas a um servidor e gerar uma ac¸˜
ao como por exemplo
impedir que pacotes origin´
arios de um poss´
ıvel atacante sejam
encaminhados at´
e o destino. Uma forma de impedir essa ac¸˜
ao ´
e
bloquear o enderec¸o IP que esteja realizando estas requisic¸ ˜
oes.
As ac¸ ˜
oes restritivas de um IPS podem gerar problemas de
impacto nocivos ao pr´
oprio servic¸o disponibilizado, como a
ocorrˆ
encia de falsos positivos na identificac¸˜
ao de poss´
ıveis
atacantes [8]. O falso positivo neste caso pode ter sido gerado
propositalmente pelo atacante, de forma a comprometer a
comunicac¸˜
ao do servidor com usu´
arios ou mesmo outras
m´
aquinas servidoras. Em geral, quando o atacante intenta
realizar uma restric¸˜
ao causada por falso positivo, este pode
forjar seu enderec¸o IP de origem. Esta mudanc¸a de enderec¸o
tem como objetivo fazer com que o IPS restrinja IPs leg´
ıtimos.
Desta forma m´
aquinas n˜
ao maliciosas, at´
e mesmo dentro da
pr´
opria rede, seriam consideradas como potenciais ameac¸as
e portanto teriam suas requisic¸ ˜
oes bloqueadas. Com base no
problema apresentado, este trabalho apresenta um IPS que
al´
em de identificar anomalias com base no IP de origem,
tamb´
em utiliza como base o enderec¸o MAC(Media Access
Control), o identificador ´
unico de cada dispositivo. O objetivo
´
e tornar a detecc¸˜
ao de intrusos mais acurada quando a mesma
ocorrer dentro da pr´
opria rede e consequentemente reduzir
falsos positivos.
A organizac¸˜
ao do trabalho ´
e descrita a seguir. A sec¸˜
ao II
resume os tipos de ataques de negac¸ ˜
ao de servic¸ o e IPS. A
sec¸ ˜
ao III introduz uma vis˜
ao sobre trabalhos que apresentam
uma tem´
atica de atuac¸ ˜
ao na ´
area de prevenc¸ ˜
ao e detecc¸ ˜
ao
de intrusos. A sec¸ ˜
ao IV apresenta a ferramenta proposta
954

XXXIV SIMP ´
OSIO BRASILEIRO DE TELECOMUNICAC¸ ˜
OES - SBrT2016, 30 DE AGOSTO A 02 DE SETEMBRO, SANTAR ´
EM, PA
incluindo detalhes do funcionamento relativos a detecc¸ ˜
ao e a
tomada de decis˜
oes contra poss´
ıveis ataques. Em V, as an´
alises
comparativas entre os diferentes est´
agios da ferramenta e
sua comparac¸ ˜
ao com outra ferramenta s˜
ao demonstrados em
gr´
aficos. A sec¸ ˜
ao VI apresenta o resumo conclusivo das ideias
e considerac¸ ˜
oes propostas, bem como apresenta ideias para
trabalhos futuros.
II. ES CO PO D E ATAQUES E DEFESAS
Os ataques de negac¸ ˜
ao de servic¸ o utilizados neste trabalho,
tem como foco a inundac¸ ˜
ao com requisic¸ ˜
oes objetivando
consumir recursos dos servic¸ os oferecidos. Para estes ataques
´
e utilizado um Sistema de Prevenc¸ ˜
ao de Intrusos (IPS) que
atua em um gateway, destacando-se por um IPS de redes. Um
resumo dos tipos de ataques e IPS ´
e exposto nas sub-sess˜
oes
II-A e II-B respectivamente.
A. Ataques de Negac¸ ˜
ao de Servic¸ o
Um ataque de negac¸ ˜
ao de servic¸ o (DoS) tem por finalidade
tornar os recursos de um determinado sistema indispon´
ıveis.
Em muitos casos esse tipo de ataque tem como alvo servidores
web, afim de impedir que usu´
arios possam ter acesso a um de-
terminado conte´
udo. Segundo [9] existem algumas formas de
negac¸ ˜
ao de servic¸ o, como consumo de recursos e explorac¸˜
ao
de vulnerabilidade. O consumo de recursos ´
e um fator de
extrema importˆ
ancia para um determinado servic¸ o. Devido
ao fato desses recursos como a mem´
oria e o processamento
serem limitados, ´
e poss´
ıvel inundar a m´
aquina v´
ıtima com
um determinado n´
umero de requisic¸ ˜
oes, afim de consumir
esses recursos. Esse tipo de ataque ´
e chamado de ataque
por inundac¸ ˜
ao. Quando esse ataque ocorre, a v´
ıtima ou at´
e
mesmo a rede a qual est´
a localizada fica impossibilitada de
responder requisic¸ ˜
oes oriundas de usu´
arios leg´
ıtimos. Para
este ataque ser realizado com ˆ
exito, ´
e fundamental que as
mensagens geradas por um atacante sejam superiores `
a taxa
que a v´
ıtima suporta. Para v´
ıtimas com alta disponibilidade
de recursos, faz-se necess´
ario um maior esforc¸ o do ataque
DoS. A explorac¸ ˜
ao de vulnerabilidades decorre de falhas na
implementac¸ ˜
ao de um protocolo, aplicac¸ ˜
ao, servic¸ o ou sistema,
e tamb´
em devido a problemas de configurac¸ ˜
ao e administrac¸ ˜
ao
de recursos computacionais [10]. Existe tamb´
em o ataque de
negac¸ ˜
ao de servic¸ o distribu´
ıdo DDoS Distributed DoS, onde
os pacotes s˜
ao enviados de diferentes origens, quando um
atacante sozinho n˜
ao ´
e capaz de consumir completamente os
recursos da v´
ıtima [11].
B. Sistemas de Prevenc¸ ˜
ao de Intrusos
Intrusion Prevention System (IPS) ´
e um sistema de defesa
capaz de prevenir conte´
udos maliciosos dentro do tr´
afego de
rede. Ele detecta e intercepta o tr´
afego, tomando medidas ime-
diatas com o objetivo de impedir ataques [12]. Segundo [13],
um IPS pode tomar diversas ac¸ ˜
oes, como bloqueio de portas
no switch, interac¸ ˜
ao com politicas de firewall externos, regras
dos roteadores, ou, ainda, gerac¸ ˜
ao de tr´
afego na camada de
transporte. Existem dois tipos de sistemas de prevenc¸ ˜
oes de
intrusos atualmente: Host-Based e InLine [14]. O baseado em
host atua como a ´
ultima linha de defesa, onde softwares s˜
ao
instalados em um determinado host que precisa de protec¸ ˜
ao.
Este tamb´
em ´
e chamado de HIPS (Host Intrusion Prevention
System), que consiste em um servidor de gerenciamento e um
agente, que atuar´
a entre a aplicac¸ ˜
ao e o kernel do sistema
operacional. Desta forma o agente tem a possibilidade de
interceptar as chamadas realizadas pelo sistema ao kernel com-
parando com uma lista de controle de acessos definida pelo
HIPS. Esta lista ´
e utilizada para tomar decis˜
oes de permiss˜
ao
do tr´
afego em quest˜
ao. Um IPS baseado em rede como o
NIPS (Network Intrusion Prevention System) ´
e um sistema
localizado no gateway. Aproveitando-se deste posicionamento
o NIPS ir´
a monitorar o tr´
afego da rede afim de detectar e
prevenir incidˆ
encias de conex˜
oes maliciosas.
III. TRA BAL HO S RELAC IO NAD OS
Diversos mecanismos de defesa contra ataques DoS vˆ
em
sido propostos. Em muitos casos, a soluc¸ ˜
ao adotada se d´
a por
diversos fatores, como: confiar em uma determinada lista de
IP’s, realizar o bloqueio de IP’s considerados atacantes, gerar
modelos de tr´
afego, dentre outros. A soluc¸ ˜
ao proposta por [15]
analisa o tr´
afego de entrada e sa´
ıda que chega ao roteador,
afim de manter um hist´
orico com boas conex˜
oes estabelecidas.
Tendo como base essas informac¸ ˜
oes, ´
e gerada uma tabela
de conex˜
oes confi´
aveis, para que em situac¸ ˜
oes de ataque, as
mesmas sejam favorecidas em detrimento `
a conex˜
oes des-
conhecidas ou ileg´
ıtimas. O trabalho de [16], consiste em
interceptar os pacotes maliciosos oriundos de ataques antes
que os mesmos cheguem at´
eam´
aquina alvo. Isto ´
e realizado
atrav´
es de uma soluc¸ ˜
ao de longo prazo incluindo hist´
oricos
de tr´
afego, apelidada de Internet Firewall Approach. Nesta
abordagem utiliza-se uma quantidade de filtros de pacotes afim
de examinar se a origem e o destino procedem de ligac¸ ˜
oes
esperadas. Em [17], um hist´
orico contendo todos os enderec¸ os
IP leg´
ıtimos ´
e armazenado em um roteador de borda. Dessa
forma, quando o mesmo encontra-se sobrecarregado, esse
hist´
orico ´
e utilizado para tomar a decis˜
ao de aceitar ou n˜
ao
um novo pacote IP. Na t´
ecnica proposta por [18], um sistema
distribu´
ıdo ´
e capaz de recolher dados a partir de sensores e
calcular a condic¸ ˜
ao da rede, afim de gerar modelos de tr´
afego.
Se o tr´
afego entrante ´
e considerado anˆ
omalo, s˜
ao gerados
alarmes com graus de prioridade que poder˜
ao descartar os
pacotes maliciosos ou realizar um balanceamento de carga para
outro servidor menos sobrecarregado e de prioridade inferior.
A abordagem feita por [19], prop˜
oe um m´
etodo de minerac¸ ˜
ao
de dados para detectar e prevenir ataques. Os autores utilizam
a combinac¸ ˜
ao do PfSense [20] em conjunto com o Snort [21].
A t´
ecnica utilizada inclui m´
ultiplas formas de classificac¸ ˜
ao de
ataque, afim de alcanc¸ ar um n´
ıvel de precis˜
ao e reduzir falsos
alertas.
IV. IREMAC ( IP S COM RES TRIC¸˜
AO D E END ER EC¸OMAC)
A soluc¸ ˜
ao apresentada nesse trabalho, IREMAC, consiste
em prevenir que um servidor de aplicac¸ ˜
ao, neste caso um
servidor web, tenha o seu servic¸ o interrompido por ataques
DoS. O cen´
ario utilizado possui os servidores de aplicac¸ ˜
ao
dispostos em uma sub-rede distinta dos poss´
ıveis usu´
arios.
955

XXXIV SIMP ´
OSIO BRASILEIRO DE TELECOMUNICAC¸ ˜
OES - SBrT2016, 30 DE AGOSTO A 02 DE SETEMBRO, SANTAR ´
EM, PA
Devido a esta distinc¸ ˜
ao, para que o usu´
ario possa fazer
requisic¸ ˜
oes a estes servidores, faz-se necess´
ario a realizac¸ ˜
ao
de um port-forward, que consiste em mascarar a porta da
rede interna para a rede externa, assim como a interface de
rede, realizando o NAT (Network Address Translation). A
ferramenta criada ´
e um IPS, respons´
avel por identificar e
analisar uma intrus˜
ao e bloquear poss´
ıveis tr´
afegos maliciosos.
O IREMAC ´
e posicionado entre as duas sub-redes, criando
uma ponte entre as mesmas. O motivo desta configurac¸ ˜
ao ´
e
concentrar todo tr´
afego no IREMAC, para que possa analisar
e consequentemente tomar ac¸ ˜
oes quando necess´
ario.
O IREMAC realiza monitoramento constante `
a interface de
rede dos hospedeiros que armazenam os servic¸ os requerentes
de protec¸ ˜
ao. Este monitoramento tamb´
em se d´
a atrav´
es do
envio de requisic¸ ˜
oes de pacotes sonda para a porta do servic¸ o
monitorado. Neste trabalho a porta monitorada foi a HTTP,
pois os alvos de protec¸ ˜
ao s˜
ao servidores WEB. O servidor
web utilizado para a realizac¸ ˜
ao de testes foi o servidor
APACHE [22]. A raz˜
ao por sua escolha est´
a diretamente ligada
`
a popularidade deste servidor para o provimento de servic¸os
de p´
aginas [23].
A arquitetura proposta consiste em utilizar o IREMAC em
conjunto com dois servidores WEB. Estes servidores ser˜
ao
protegidos e monitorados pelo IREMAC. Para descric¸˜
ao da
arquitetura os servidores ser˜
ao chamados aqui de WEB 1
e WEB 2. No primeiro momento, o IREMAC realizar´
a o
encaminhamento de requisic¸ ˜
oes HTTP para o primeiro ser-
vidor, WEB 1. O WEB 2 permanece ativo por´
em sem entrada
de tr´
afego. Sabendo-se que servidores WEB suportam uma
quantidade limitada de conex˜
oes, de forma que, ao excedˆ
e-
las, o servic¸ o provido ficar´
a inacess´
ıvel, o IREMAC conta com
um filtro de pacotes que delimitar´
a a quantidade de conex˜
oes
permitidas a cada usu´
ario. A raz˜
ao para isto est´
a em conter
ataques de DoS, com m´
ultiplas requisic¸ ˜
oes TCP, que sejam
originadas de um mesmo enderec¸ o IP.
A outra forma de monitoramento ´
e baseada no n´
umero
de respostas aos pacotes sondas que IREMAC envia para
os servidores direcionados `
as suas portas de servic¸ os, por
exemplo em um servidor HTTP, porta 80 TCP. Caso o limiar
de respostas `
a estes pacotes sonda sejam excedidos, o IRE-
MAC gerar´
a um alerta de poss´
ıvel ataque e imediatamente
assume que o servidor monitorado est´
a sobre ataque. Paralelo
a esta ac¸ ˜
ao, o IREMAC analisa os logs gerados pela ferra-
menta tcpdump [24]. Nestes logs ´
e feita uma an´
alise afim de
verificar a quantidade de IP’s associados a um determinado
enderec¸ o MAC. Caso um MAC esteja associado a mais de
um enderec¸ o IP, ele ´
e considerado malicioso e ´
e adicionado
a uma lista negra. Os enderec¸os MACs contidos nesta lista
s˜
ao posteriormente bloqueados pelo servidor IREMAC como
medida preventiva. O bloqueio dos MACs considerados como
potenciais ameac¸ as ´
e feito aplicando regras ao IPTABLES [25]
de forma autom´
atica.
Quando o servidor web sofre um ataque de m´
ultiplas
requisic¸ ˜
oes TCP, o mesmo fica sobrecarregado e sem a pos-
sibilidade de estabelecer novas conex˜
oes por um determi-
nado tempo. Este tempo pode variar em func¸ ˜
ao do tipo de
ataque e a continuidade do mesmo. A arquitetura proposta,
consistindo de redundˆ
ancia de servidores, ´
e planejada para
Fig. 1. Fluxograma de funcionamento do IREMAC.
que uma vez comprometido um servidor o IREMAC possa
encaminhar o tr´
afego para o servidor redundante. Este servidor
redundante tem a capacidade de permitir novas conex˜
oes e
consequentemente reduzir o tempo de indisponibilidade do
servic¸ o oferecido. Desta forma, ap´
os o enderec¸ o MAC da
m´
aquina atacante ter sido adicionado `
a lista negra, o IREMAC
faz o redirecionamento do tr´
afego HTTP para o servidor
redundante. Nesta etapa p´
os ataque o servidor redundante atua
como servidor WEB principal assumindo o papel de atender
`
as requisic¸ ˜
oes de p´
aginas dos usu´
arios. Nesse outro momento,
o IREMAC atua de forma mais rigorosa, permitindo um
menor n´
umero de conex˜
oes por usu´
ario e bloqueando conex˜
oes
oriundas das m´
aquinas que foram consideradas atacantes.
A Figura 1 exemplifica o funcionamento do IREMAC
na arquitetura proposta. O primeiro passo est´
a na detecc¸ ˜
ao
de um poss´
ıvel ataque ao servidor WEB1, servidor HTTP
prim´
ario, ap´
os a gerac¸ ˜
ao do alarme o IPS inicia sua ac¸ ˜
ao de
pol´
ıticas mais defensivas. As configurac¸ ˜
oes de defesa ser˜
ao
alteradas para um modo mais restritivo. Os enderec¸os MAC’s
das m´
aquinas atacantes ser˜
ao adicionados `
a lista negra, e
consequentemente ap´
os esta inserc¸ ˜
ao o fluxo de ataque oriundo
destas ´
e bloqueado. Uma vez que o tr´
afego de ataque ´
e mi-
tigado, o redirecionamento do tr´
afego passar´
a para o servidor
WEB 2. Este atua ent˜
ao como novo servidor de p´
aginas
principal. Ap´
os esta etapa o IREMAC continua monitorando
o servidor WEB 2, por´
em com a configurac¸ ˜
ao mais restritiva.
Nesta configurac¸ ˜
ao mais restritiva o n´
umero de conex˜
oes por
956

XXXIV SIMP ´
OSIO BRASILEIRO DE TELECOMUNICAC¸ ˜
OES - SBrT2016, 30 DE AGOSTO A 02 DE SETEMBRO, SANTAR ´
EM, PA
enderec¸ o ´
e reduzido e as m´
aquinas suspeitas de ataque s˜
ao
adicionadas a lista negra.
V. RES ULTAD OS
Os testes do IREMAC foram realizados em um laborat´
orio
com 20 m´
aquinas atuando na mesma rede e utilizando o IPS
IREMAC como ponte para acesso aos servidores WEB. Foram
realizados 10 testes para cada configurac¸ ˜
ao e os resultados
apresentam as m´
edias. Foram utilizadas m´
aquinas com o Intel
Core i5 3.40GHz com 4GiB de mem´
oria, com o sistema opera-
cional Ubuntu 15.04. Os testes aplicados ao IREMAC tamb´
em
foram replicados ao PfSense+Snort. Este ´
ultimo foi escolhido
devido a sua ampla utilizac¸ ˜
ao no segmento de seguranc¸a da
informac¸ ˜
ao [19]. Nos testes o conjunto PfSense+Snort foi
instalado com a configurac¸ ˜
ao de IPS e com as regras padr˜
ao do
Snort para ataques de DoS. Desta forma o IPS PfSense+Snort
atuou como uma soluc¸ ˜
ao comparativa com o IPS IREMAC.
O n´
umero de m´
aquinas que realizam ataques simultˆ
aneos foi
alterado para que fosse poss´
ıvel identificar a relac¸ ˜
ao entre
m´
aquinas atacantes e o comprometimento dos recursos dos
servidores WEB.
A Figura 2 demostra o tempo necess´
ario para realizar a
mudanc¸ a de um servidor web para o outro. Nestes testes foram
feitas requisic¸ ˜
oes ao servidor web, por m´
aquinas que simula-
vam requisic¸ ˜
oes leg´
ıtimas utilizando a ferramenta wget. As
p´
aginas s˜
ao requisitadas obedecendo um limiar de requisic¸ ˜
ao
sucessiva. Nos primeiros testes este limiar foi de 20s e o tempo
total decorrido entre as retransmiss˜
oes para adquirir a p´
agina
foi de aproximadamente 28,5s. Reduzindo o limiar para 5s o
tempo total para adquirir uma p´
agina foi reduzido para 7,3s.
Estes tempos representam uma requisic¸ ˜
ao no per´
ıodo de troca
de tr´
afego entre o servidor principal e o secund´
ario. Este tempo
representou um fator positivo ao objetivo de reduzir o tempo
de indisponibilidade do servic¸ o.
Fig. 2. Atraso m´
edio para transic¸ ˜
ao entre servidores WEB.
A Figura 3 apresenta os resultados dos ataques utilizando a
ferramenta t50. Os ataques aconteceram em est´
agios em que
apenas uma m´
aquina atacava por vez e posteriormente esse
n´
umero foi aumentando at´
e trˆ
es atacantes simultˆ
aneos. Os
resultados do IREMAC com a configurac¸ ˜
ao B´
asica, ou seja
menos restritiva, apresentam uma diferenc¸a significativa com
relac¸ ˜
ao ao tempo total decorrido para que uma p´
agina fosse
adquirida por m´
aquinas que n˜
ao eram atacantes. Quando a
m´
aquina sofre o ataque de apenas uma m´
aquina o atraso na
resposta `
a requisic¸ ˜
ao ´
e de aproximadamente 0,01s. No entanto
aumentando o n´
umero de computadores participando de forma
simultˆ
anea no ataque o atraso aumenta para 0,35s. Utilizando a
configurac¸ ˜
ao Restritiva do IREMAC o atraso foi reduzido para
0,0062s. Os atrasos relativos ao PfSense+Snort foram mais
elevados devido aos falsos positivos em que IPs leg´
ıtimos eram
usados no DoS. Para estes testes o T50 foi configurado para
operar em modo mais agressivo. Apesar desta configurac¸ ˜
ao
agressiva, observa-se que atrav´
es dos registros a ferramenta
cria uma grande variedade de IPs pertencentes `
a redes diferen-
tes das quais os IPSs estavam. Isto consequentemente facilitou
o descarte de pacotes oriundos de redes que n˜
ao condiziam
com a rede na qual a interface dos IPSs estavam.
Fig. 3. Atrasos de requisic¸ ˜
ao de p´
agina sob ataque da ferramenta
T50.
Os resultados utilizando a ferramenta de ataque DoS, Et-
tercap, s˜
ao apresentados na Figura 4. Nos testes o IREMAC
utilizando a configurac¸ ˜
ao B´
asica apresentou o pior desempe-
nho, incluindo o consumo de processamento apresentado na
Figura 5. Mesmo com apenas uma m´
aquina atacante o servidor
WEB ´
e comprometido pelo ataque, o que impossibilita que
seja carregada a p´
agina em tempo h´
abil. Este fator se deve
ao Ettercap ter enviado mais pacotes em um curto espac¸o de
tempo e tamb´
em a possibilidade de utilizar IPs falsos que per-
tencessem a mesma rede das m´
aquinas de usu´
arios leg´
ıtimos.
O IREMAC atuando em modo Restritivo, ou seja quando o
mesmo reage a um ataque, apresentou um tempo de reposta `
a
requisic¸ ˜
ao de p´
aginas mais satisfat´
orio. Este tempo ficou em
aproximadamente 0,01s. O PfSense+Snort obteve novamente
um maior atraso devido aos IPs que foram sorteados nos
ataques do Ettercap. Os resultados demonstram que apesar do
modo de configurac¸ ˜
ao B´
asico do IREMAC funcionar apenas
em um cen´
ario onde ainda n˜
ao existe ataque, este apresenta
alta vulnerabilidade aos ataques da ferramenta Ettercap. Esta
vulnerabilidade n˜
ao ´
e verificada quando o IREMAC reage com
sua configurac¸ ˜
ao mais restritiva.
Entretanto o PfSense/Snort apresentou falsos positivos
quando os ataques de DoS s˜
ao feitos variando os IPs da
mesma rede onde est˜
ao as m´
aquinas de usu´
arios leg´
ıtimos.
O motivo pelo qual isto aconteceu se deve ao modo de
funcionamento do PfSense/Snort `
a ataques de DoS. Nes-
tes ataques o PfSense/Snort bloqueia os IPs que considera
957

XXXIV SIMP ´
OSIO BRASILEIRO DE TELECOMUNICAC¸ ˜
OES - SBrT2016, 30 DE AGOSTO A 02 DE SETEMBRO, SANTAR ´
EM, PA
Fig. 4. Atrasos de requisic¸ ˜
ao de p´
agina sob ataque da ferramenta
Ettercap.
Fig. 5. Consumo de processamento na m´
aquina servidora sob ataque
da ferramenta Ettercap.
oriundos das m´
aquinas atacantes. Este bloqueio de IPs, que
em determinados casos eram de m´
aquinas leg´
ıtimas, mas
que foram forjados pela ferramenta de ataque impediu as
requisic¸ ˜
oes leg´
ıtimas. Estas requisic¸ ˜
oes foram bloqueadas pois
o PfSense/Snort adicionou os IPs das m´
aquinas n˜
ao atacantes
`
a sua lista negra. Utilizando o IREMAC isto n˜
ao acontece,
pois o bloqueio n˜
ao ´
e feito pelo enderec¸ o IP mas sim pelo
enderec¸ o MAC. Desta forma o IPS IREMAC apresenta um
ganho quando utilizado como IPS para protec¸ ˜
ao de servidores
dentro de redes internas.
VI. CO NCLUS ˜
OE S
Este trabalho apresentou uma forma de defesa contra ata-
ques DoS oriundos da rede interna. A arquitetura apresentada
demonstra que o IREMAC pode ser utilizado em conjunto
com servidores redundantes, de forma a reduzir o tempo de
inacessibilidade p´
os ataque. A troca do servidor que est´
a sobre
ataque por outro se mostrou eficaz quando comparado ao
tempo de resposta ap´
os um ataque bem sucedido. O bloqueio
de m´
aquinas atacantes por MAC apresentou uma reduc¸ ˜
ao nos
falsos positivos de enderec¸os IPs de m ´
aquinas que realizam
requisic¸ ˜
oes leg´
ıtimas. Em trabalhos futuros ser´
a analisado a
criac¸ ˜
ao de m´
odulos adicionais para controle de redes sem fio
de forma distribu´
ıda. Pretende-se tamb´
em realizar um controle
de lista negra, vinculado aos servidores de autenticac¸ ˜
ao como
RADIUS e consequentemente obter mais detalhes sobre a
m´
aquina que est´
a realizando o ataque.
REF ER ˆ
EN CI AS
[1] T. Peng, C. Leckie, and K. Ramamohanarao, “Survey of network-based
defense mechanisms countering the dos and ddos problems,” ACM
Computing Surveys (CSUR), vol. 39, no. 1, p. 3, 2007.
[2] J. F. Kurose, K. W. Ross, A. S. Marques, and W. L. Zucchi, Redes de
Computadores e a Internet: uma abordagem top-down. Pearson, 2010.
[3] A. Ornaghi and M. Valleri, “Ettercap,” 2005.
[4] A. L. R. Corrˆ
ea and H. P. Martins, “Monitoramento de ataques de
negac¸ ˜
ao de servic¸ o: Um caso pr´
atico utilizando slowloris.”
[5] J. Petit and S. E. Shladover, “Potential cyberattacks on automated
vehicles,” Intelligent Transportation Systems, IEEE Transactions on,
vol. 16, no. 2, pp. 546–556, 2015.
[6] P. S. Kenkre, A. Pai, and L. Colaco, “Real time intrusion detection and
prevention system,” in Proceedings of the 3rd International Conference
on Frontiers of Intelligent Computing: Theory and Applications (FICTA)
2014. Springer, 2015, pp. 405–411.
[7] R. Zuech, T. M. Khoshgoftaar, and R. Wald, “Intrusion detection and
big heterogeneous data: A survey,” Journal of Big Data, vol. 2, no. 1,
pp. 1–41, 2015.
[8] I. Butun, S. D. Morgera, and R. Sankar, “A survey of intrusion
detection systems in wireless sensor networks,” Communications Surveys
& Tutorials, IEEE, vol. 16, no. 1, pp. 266–282, 2014.
[9] R. P. Laufer, I. M. Moraes, P. B. Velloso, M. D. Bicudo, M. E. M.
Campista, D. d. O. Cunha, L. Costa, and O. Duarte, “Negac¸ ao de servic¸ o:
Ataques e contramedidas,” Livro Texto dos Mini-cursos do V Simp´
osio
Brasileiro de Seguranc¸a da Informac¸ ˜
ao e de Sistemas Computacionais,
2005.
[10] E. T. Nakamura and P. L. Geus, Seguranc¸a de redes. Berkeley, 2002.
[11] R. P. Laufer, “Rastreamento de pacotes ip contra ataques de negac¸ ˜
ao de
servic¸ o,” Ph.D. dissertation, UNIVERSIDADE FEDERAL DO RIO DE
JANEIRO, 2005.
[12] M. I. Shafi, M. Akram, S. Hayat, and I. Sohail, “Effectiveness of
intrusion prevention systems (ips) in fast networks,” arXiv preprint
arXiv:1006.4546, 2010.
[13] E. Coser, “Automatizac¸˜
ao do processo de contenc¸ ˜
ao de ameac¸ as baseada
em ferramenta de ids/ips (sistema de detecc¸ ˜
ao e prevenc¸ ˜
ao de intrus˜
ao),”
2012.
[14] S. V. B. Evangelista, “Sistemas de detecc¸ ˜
ao de intrusos e sistemas de
prevenc¸ ˜
ao de intrusos: Princ´
ıpios e aplicac¸ ˜
ao de entropia,” Petr´
opolis:
Instituto Superior de Tecnologia em Ci ˆ
encia da Computac¸ ˜
ao, 2008.
[15] E. Oliveira, R. Aschoff, B. Lins, E. Feitosa, and D. Sadok, “Avaliac¸ ˜
ao
de protec¸ ˜
ao contra ataques de negac¸ ˜
ao de servic¸ o distribu´
ıdos (ddos)
utilizando lista de ips confi´
aveis,” VII Simp´
osio Brasileiro em Seguranc¸a
da Informac¸ ˜
ao e de Sistemas Computacionais, 2007.
[16] R. K. Chang, “Defending against flooding-based distributed denial-of-
service attacks: a tutorial,” Communications Magazine, IEEE, vol. 40,
no. 10, pp. 42–51, 2002.
[17] T. Peng, C. Leckie, and K. Ramamohanarao, “Protection from distributed
denial of service attacks using history-based ip filtering,” in Communica-
tions, 2003. ICC’03. IEEE International Conference on, vol. 1. IEEE,
2003, pp. 482–486.
[18] S. Mohiuddin, S. Hershkop, R. Bhan, and S. Stolfo, “Defending against
a large scale denial-of-service attack,” in Proc. 2002 IEEE Workshop on
Information Assurance and Security. Citeseer, 2002.
[19] M. Tabash and T. Barhoom, “An approach for detecting and preventing
dos attacks in lan,” International Journal of Computer Trends and
Technology IJCTT Vol 18 number 6.
[20] C. M. Buechler, J. Pingle, and J. Reed, PfSense: The Definitive Guide:
the Definitive Guide to the PfSense Open Source Firewall and Router
Distribution. Reed Media Services, 2009.
[21] M. Roesch et al., “Snort: Lightweight intrusion detection for networks.”
in LISA, vol. 99, no. 1, 1999, pp. 229–238.
[22] R. T. Fielding and G. Kaiser, “The apache http server project,” Internet
Computing, IEEE, vol. 1, no. 4, pp. 88–90, 1997.
[23] Y. Diao, J. L. Hellerstein, S. Parekh, and J. P. Bigus, “Managing web
server performance with autotune agents,” IBM Systems Journal, vol. 42,
no. 1, pp. 136–149, 2003.
[24] V. Jacobson, C. Leres, and S. McCanne, “The tcpdump manual page,”
Lawrence Berkeley Laboratory, Berkeley, CA, 1989.
[25] D. Hoffman, D. Prabhakar, and P. Strooper, “Testing iptables,” in
Proceedings of the 2003 conference of the Centre for Advanced Studies
on Collaborative research. IBM Press, 2003, pp. 80–91.
958