E COMUNICACAO,

VOL. 4, NUMERO

REVISTA DE TECNOLOGIA DA INFORMAC

AO
1, JULHO DE 2014

Detecca o de Ataques de Negaca o de Servico

Utilizando Ferramentas de Monitoramento e Analise
de Trafego
Diego Veras de Queiroz, Janio Carlos Mesquita Vieira e Iguatemi E. Fonseca
Universidade Federal da Paraba - UFPB, Joao Pessoa, Brasil
Email: diego@nti.ufpb.br, janio@nti.ufpb.br, iguatemi@ci.ufpb.br

ResumoEsse artigo tem como objetivo realizar uma analise

de como e possvel identificar ataques de negaca o de servico
utilizando ferramentas que monitoram o estado das conexoes dos
enlaces, baseando-se no comportamento anormal do trafego. Foi
utilizado um cenario de teste, que consiste em maquinas clientes
com trafego legtimo que requisitam acesso a um recurso no
servidor Web e maquinas que realizam ataques a esse servidor.
No meio de comunicaca o entre clientes e servidor encontramse dois roteadores que ligam a rede interna e externa, respectivamente. Utilizando ferramentas de monitoramento e analise
de trafego, como zabbix, tcpdump e iptraf, foi desenvolvida uma
estrategia que, quando configurados os agentes zabbix no servidor
Web e roteadores, possibilitam a identificaca o do momento exato
da ocorrencia do ataque de negaca o de servico. Para isso,
foi identificado um padrao inicial do trafego e demanda de
processamento, e em seguida a alteraca o desse padrao e dos
arquivos de log do servidor Web durante o ataque DDoS. Os
testes experimentais sugeriram que e possvel detectar ataques
DDoS do tipo hping e LOIC a partir do momento em que e
gerado um alerta pelo zabbix, passando pela analise do trafego
com tcpdump e iptraf e das alteraco es do arquivo de log.
Palavras-chaveAtaques de negaca o de servico, analise de
trafego em redes IP, seguranca em redes de computadores,
tecnicas de identificaca o e bloqueio de ataques de negaca o de
servico.

I. I NTRODUC AO
taques de Negaca o de Servico (DoS - Denial of Service), diferentemente da maioria dos ataques na Internet,
nao visam adquirir informaco es confidenciais, alterar essas
informaco es ou disseminar softwares maliciosos pela rede. Seu
foco e tornar indisponveis a usuarios legtimos os servicos
voltados para as redes computacionais.
Desde a popularizaca o do acesso da Internet fora dos
crculos academicos e militares, diversos ataques de caracterstica tecnica se tornaram de conhecimento publico, utilizando falhas em sistemas operacionais, softwares de servidor,
aplicaco es ou limitaco es fsicas para indisponibilizar sistemas
e/ou servicos.
Embora uma serie de ataques de diversos tipos possa ser
utilizada, esse trabalho e focado na negaca o de servico baseada
na inundaca o de pacotes, mais conhecida por seu termo em
ingles: flooding, tambem caracterizada por ataque em nvel de
infraestrutura [1], diferenciada de ataques em nvel de bug de
aplicaca o.

Artigo recebido em 20 de dezembro de 2013. Artigo aceito em

24 de junho de 2014.

Essa tecnica consiste no envio de uma grande quantidade de

pacotes IP, normalmente baseados em TCP, UDP ou ICMP, e
mais recentemente, no HTTP. Alem de ocupar os recursos do
alvo, incluindo processamento, memoria, limite de conexoes
ou conversaco es disponveis, esses ataques normalmente ocupam uma grande quantidade de banda passante para a rede
na qual se localiza o destino, muitas vezes ocupando toda a
banda e inviabilizando toda a comunicaca o daquela rede e
prejudicando, inclusive, o nucleo da rede (backbone) do qual
o host faz parte [2].
Diante do aumento do poder computacional dos servidores,
e cada vez mais difcil negar servico de uma maquina de
destino apenas com uma maquina atacante. Para aumentar a
efetividade do ataque, varias delas podem ser utilizadas em
conjunto com foco no alvo em comum. A essa tecnica da-se
o nome de DDoS (Distributed Denial of Service), ou Negaca o
de Servico Distribuda. A existencia das chamadas botnets
[3], [4] (redes de computadores zumbis, isto e , servidores
e/ou estaco es de trabalho infectados e controlados remotamente por um mestre, propositalmente ou sem autorizaca o de
seus proprietarios) facilita a execuca o de ataques simultaneos
de centenas ou milhares de origens, o que dificulta a sua
identificaca o e o bloqueio.
Ainda como tentativa de dificultar a identificaca o dos
ataques, a inclusao do fator de mascaramento de origem,
chamado de IP Spoofing [5], foi, por muito tempo, motivo de
preocupaca o para administradores de rede. Com as tecnicas
de validaca o de identidade feitas, como e o caso da Filtragem
por Caminho Inverso (Reverse Path Filtering), esses ataques
perderam forca e, atualmente, os ataques direto aos protocolos
de aplicaca o tem estado em evidencia [6].
Ataques de negaca o de servicos distribuda tem se tornado
muito comuns, muitas vezes por motivaco es polticas [7]. De
acordo com o jornal New York Times [8], um grupo antispam chamado Spamhaus, que e utilizado por provedores de
e-mail para estabelecer o que e ou nao spam, inseriu uma
empresa holandesa chamada Cyberbunker na sua lista negra.
O grupo acusou o Cyberbunker de hospedar materiais usados
por spammers e de estar ligado a grupos criminosos do leste
europeu. O Cyberbunker e uma empresa (DataCenter) que
oferece hospedagem para sites de todo tipo. Em retaliaca o, no
mes de marco de 2013 foram realizados ataques de negaca o
de servico aos servidores do Spamhaus, que imediatamente
entrou em comunicaca o com a empresa de seguranca na Web,

 E COMUNICACAO,
VOL. 4, NUMERO

REVISTA DE TECNOLOGIA DA INFORMAC

AO
1, JULHO DE 2014

CloudFlare, informando do ataque em que foram registrados,

no dia 22 de marco, 120 Gbit/s de trafego. Sem sucesso, os
atacantes direcionaram seu foco para os provedores de quem
o CloudFlare compra banda, que sao de hierarquia do nvel
(Tier) 2. Os provedores de nvel 2 entao compram banda
do nvel 1 para garantir que possam conectar cada ponto da
internet. No nvel 1 estao provedores que possuem cobertura
mundial e sao quem garante que todas as redes na Internet
estejam conectadas. Os ataques DDoS foram direcionados a` s
redes do nvel 2 e refletiram no nvel 1. Foram registrados
aproximadamente 300 Gbit/s de trafego. Como efeito desse
ataque, foi sentida lentidao em alguns sites da Europa, mas ha
registros de terem atingido o mundo inteiro, embora nao fosse
o suficiente para negar totalmente o acesso aos servidores da
Spamhaus.
Esse trabalho tem como foco a detecca o em ambientes
que nao dispoem de recursos especficos de seguranca preconfigurados, nem equipamentos proprios para essa finalidade,
mas de ferramentas que, quando nao ja vem instaladas por
padrao na distribuica o Linux, sao geralmente adicionadas apos
sua instalaca o: o analisador de pacotes tcpdump, o analisador
de trafego iptraf e o utilitario zabbix, ferramenta de monitoramento. A utilizaca o desses programas em si tambem nao e
a finalidade do artigo, mas sim a compreensao dos padroes de
funcionamento que esses demonstram durante a execuca o de
um ataque.
Para o melhor do nosso conhecimento, essa e a primeira vez
que esse conjunto de metricas e utilizado para identificar esses
tipos de ataques DDoS. Ha diversos trabalhos relacionados
com a detecca o de ataques de negaca o de servico distribuda
[2], [3], [9], [10], [22], [31].
Nesse trabalho, a Seca o II possui caracterizados os tipos de
ataques de negaca o de servico, assim como e citado e descrito
o funcionamento das duas ferramentas de ataques utilizadas. A
Seca o III expoe o cenario utilizado para o experimento e seus
resultados. A Seca o IV contem uma discussao dos resultados
e demonstra como e possvel fazer a detecca o do ataque. A
Seca o V traz a conclusao e as sugestoes de contribuica o para
trabalhos futuros.
E F ERRAMENTAS DOS ATAQUES
II. C LASSIFICAC AO
DD O S
Existem varias classificaco es para ataques DDoS [7], [13],
[14], [18]. Uma delas segue pela diferenciaca o entre as camadas nas quais trabalham os ataques [11]. Na camada de
aplicaca o tem sido muito utilizado o ataque do tipo HTTP
Flood [28], alem do HTTPS Flood e FTP Flood. Passando
para a camada de rede e transporte encontram-se os ataques
UDP Flood, ICMP Flood, TCP Flood e TCP SYN Flood,
que tem sido bastante exploradas na literatura [23], [24], [25],
[26], [27].
O ataques citados acima servem de base para outros tipos
de ataque. Outro muito utilizado e o chamado DRDoS (Distributed Reflected Denial of Service) [1] ou Negaca o de Servico
Distribuda Refletida, o qual se utiliza de vitimas secundarias
que refletem o ataque ao destino. Nela, o atacante esconde seu
proprio endereco IP e utiliza o endereco IP do sistema alvo

no cabecalho do pacote IP. Quando as vtimas secundarias

recebem os pacotes, encaminham suas respostas ao sistema
alvo e acabam por esgotar seus recursos.
Na camada de aplicaca o ha um tipo de ataque que tem como
caracterstica uma aca o indireta que explora os mecanismos
de comunicaca o de um servidor proxy para comprometer a
disponibilidade das vtimas [12]. O ataque chamado WPDDoS
(Web proxy-based DDoS), citado inicialmente em [21], pode
ser utilizado em qualquer servidor proxy publico da Internet
e executar passivamente o ataque. Uma vantagem dele e que
ambos os trafegos legtimos e de ataque sao repassados para
o servidor da vtima utilizando a rede hierarquica de proxys
na Internet em vez de seus IPs reais. Nesse ataque, baseado
no protocolo HTTP, um u nico atacante pode simultaneamente
executar requisico es maliciosas a uma gama de servidores
proxy sem necessariamente invadi-los, o que pode tornar sua
detecca o mais difcil. Esse ataque esta ilustrado na Fig. 1.

Figura 1: Ataque utilizando servidor proxy. Adaptada de [12].

No experimento realizado nesse trabalho fez-se uso do
ataque TCP SYN Flood e do HTTP Flood. No primeiro, o
atacante se utiliza de uma caracterstica do protocolo TCP em
que se estabelece o three-way handshake, em que a origem
envia um pacote SYN ao destino, requisitando abertura de conexao. O destino entao, apos receber o pedido, envia a` origem
um pacote SYN/ACK de confirmaca o de recebimento, e essa,
por sua vez, retorna ao destino um pacote de confirmaca o
ACK, estabelecendo assim a conexao. O atacante, ao enviar
requisico es com pacotes SYN ao destino, o faz de maneira que
impossibilite, ao longo do tempo, a vtima de responder a todas
as requisico es, dada a rapidez em que elas sao enviadas e em
grande quantidade. O problema e que recursos sao alocados
para responder a` s requisico es que nunca serao finalizadas,
entao o destino comeca a descartar os pacotes, o que inclui
aqueles enviados por maquinas legitimas, negando assim o
servico a todos. No segundo, o atacante utiliza os metodos
GET ou POST de uma conexao HTTP valida para esgotar os
recursos do servico Web disponibilizado pelo servidor.
Nos testes realizados, ao visualizar o trafego atraves da
ferramenta tcpdump, e mais difcil identificar o ataque HTTP
Flood quando comparado ao TCP SYN Flood, pois a intensidade com que sao enviados pacotes SYN no u ltimo
ataque e claramente perceptvel. No HTTP Flood o trafego
se assemelha a um trafego normal com requisico es de acesso
a uma pagina Web. Esse tipo de ataque e mais perceptvel ao
visualizar o arquivo de log do apache.
Existem varias ferramentas que realizam ataques TCP SYN
Flood e do HTTP Flood. A ferramenta hping e um gerador e
analisador de pacotes IP, TCP, UDP e ICMP, u til para testes
de trafego em redes e firewalls, e ainda pode ser utilizada
para ataques de negaca o de servico. Com ela e possvel gerar

 E COMUNICACAO,
VOL. 4, NUMERO

REVISTA DE TECNOLOGIA DA INFORMAC

AO
1, JULHO DE 2014

Figura 2: Janela de execuca o da ferramenta LOIC, que tem funca o de realizar ataque de negaca o de servico.

fluxo intenso de pacotes para um destino e, dependendo da

intensidade desse fluxo (com varias maquinas, em uma botnet,
por exemplo), inundar a rede de pacotes e indisponibilizar,
temporariamente, o acesso a recursos de um servidor. Tambem
e possvel gerar com essa ferramenta pacotes com IPs de
origens diferentes e simular um ataque de IP Spoofing. Como
essa ferramenta nao e utilizada propriamente para ataques, mas
para testes de disponibilidade, ao criar um fluxo intenso para
um destino, o mesmo e facilmente identificavel pelo firewall
da rede de destino, pois esse ataque possui uma assinatura
especfica. Mesmo que se utilize o ataque de IP Spoofing,
maquinas baseadas no Linux possuem comando no seu kernel
que impedem que o mesmo possa ser realizado [32].
Outra ferramenta, conhecida no mundo hacker, e a chamada
LOIC (Low Orbit Ion Cannon) [28], [29], [30], utilizada e
recomendada pelo grupo Anonymous para uso em botnets nos
ataques de negaca o distribudos. Ela gera grande volume de
trafego UDP, TCP e HTTP e oferece dois modos de operaca o:
no primeiro modo, e usuario insere a localizaca o da vtima
(IP ou URL) e realiza o ataque. No segundo modo, chamado
de HIVEMIND, o usuario conecta o LOIC a um servidor
IRC (Internet Relay Chat) onde usuarios podem escolher alvos
que usuarios conectados a esse servidor irao automaticamente
atacar. A ferramenta esta ilustrada na Fig. 2.
No LOIC e necessario configurar a velocidade do ataque
entre faster (mais rapida) e slower (mais lenta). Na mais lenta
sao feitos aproximadamente dois pedidos por segundo para
cada thread definido na interface grafica. Na mais rapida sao
feitos aproximadamente oito pedidos por segundo por cada
thread. Ha um limite na quantidade de threads estabelecidos
para o ataque, pois tambem depende dos recursos da propria
maquina atacante. Se ultrapassado esse limite, o LOIC pode
gerar uma exceca o e ser fechado inesperadamente. Por padrao,
a quantidade de threads e definida para dez. A requisica o
HTTP que o LOIC faz ao servidor Web vtima tem seu

conteudo ilustrado na Fig. 3.

Figura 3: Cabecalho do pedido ao servidor Web.

Foi desenvolvida uma ferramenta superior baseada no LOIC
chamada HOIC (High Orbit Ion Cannon). A diferenca entre
o LOIC e o HOIC e que a u ltima e uma ferramenta utilizada
somente para ataques de negaca o HTTP Flood, ilustrada na
Fig. 4.
Com relaca o a` detecca o de ataques dessa natureza, existem
alguns estudos a respeito que utilizam metodos por analise de
padroes [33], [34]. Um desses estudos faz uso de metodos
que podem ser trabalhados em conjunto com o chamado
Modelo Oculto de Semi-Markov (Hidden Semi-Markov Model
- HSMM) [6],[15], modelo que e uma extensao do popular
Modelo de Markov. Esse u ltimo e um sistema de transico es
de estados em que a probabilidade de estar em um estado
futuro so depende do estado atual [19]. Se o espaco de estados
pode ser enumeravel, entao o modelo e chamado de Cadeia
de Markov. Entretanto, se ha estados que nao sao totalmente
conhecidos, o modelo e conhecido como Modelo Oculto de
Markov (Hidden Markov Model - HMM). Ja para o HSMM,
considerado como um HMM de duraca o explcito em que cada
estado possui uma duraca o variavel.
Ao acessar um site, o usuario normalmente passa por dois
estados [31]. No pedido de acesso a` pagina ele se encontra no
primeiro estado, identificado pela variavel E1 . Apos obter a
pagina, o navegador a analisa e realiza pedidos em sequencia
(inline) dos arquivos da pagina. Esse e o segundo estado,
identificado pela variavel E2 . O primeiro estado e iniciado
pelo usuario e o segundo e realizado automaticamente pelo

 E COMUNICACAO,
VOL. 4, NUMERO

REVISTA DE TECNOLOGIA DA INFORMAC

AO
1, JULHO DE 2014

Figura 4: Janela de execuca o da ferramenta HOIC. Fonte: [17]

navegador. O conjunto dos dois estados e caracterizado como

E = {E1 , E2 }. Quando o usuario envia varias requisico es
do mesmo tipo, diz-se que o estado nao se modifica; a partir
do momento em que o usuario requisita diferentes tipos de
informaco es, o estado modifica-se. A probabilidade inicial de
o usuario estar no estado a e a probabilidade de transica o do
estado a para o b sao definidos, respectivamente, como
xa = P (r1 = Ea ), Ea E
yab = P (rt+1 = Eb |r1 = Ea ), Ea , Eb E
em que rt e o estado no tempo t.
Um usuario pode requisitar o mesmo tipo de pedido por
varias vezes consecutivamente, o que significa que ele se
encontra no mesmo estado por tempo indeterminado. Para pedidos inline, o estado pode durar por varios eventos, mas pode
ser estabelecida uma duraca o maxima para isso. E possvel
utilizar um algoritmo que verifique o padrao de requisico es ao
servidor do primeiro e segundo estados e valide as mesmas
com o modelo HSMM. Apos obter os parametros do HSMM,
pode-se utiliza-lo para verificar se a sequencia de pedidos
de um usuario especifico e similar a` maioria dos usuarios,
calculando suas probabilidades. Dependendo da analise, podese dizer que o servidor esta ou nao sendo vtima de um ataque
de negaca o de servico.
Como alternativa para detecca o de ataques, existe um
modulo do servidor apache chamado ModSecurity [35] que
trabalha como firewall de aplicaca o e que possibilita o bloqueio de ataques como o Cross-Site Scripting (XSS), SQL
Injection, Command Injection, ASP e PHP Injection, Trojans
e Backdoors Detection, alem de ataques de HTTP Flood [17],
dependendo do modo como e configurado.
Nesse trabalho nao sera realizada detecca o de ataques
atraves do modelo citado nem utilizando o ModSecurity, mas
apenas com as ferramentas listadas para tal.

III. E STUDO DE C ASO

A proposta desse trabalho e comparar padroes de trafego em
situaca o normal e sob ataque utilizando ferramentas de codigo
aberto, a fim de desenvolver a capacidade de identificar a partir
de uma analise de uma ou mais metricas o momento em que
a rede esta sofrendo alguma tentativa de negaca o de servico.
Para realizaca o do experimento foi criado um ambiente de
testes, ilustrado na Fig. 5, cujo cenario possui as seguintes
caractersticas:

Dois gateways/roteadores interligando tres redes: uma

rede para os servidores, uma para os clientes e uma
rede intermediaria (Internet) que interligasse os dois
roteadores;
Um segmento de servidores contendo duas maquinas:
servidor (web) apache e servidor zabbix (geraca o de
graficos analticos\ );
Um segmento de clientes contendo seis maquinas: quatro
com funca o de clientes legtimos (usuarios identificados
com a nomenclatura ClienteX), as quais tem a finalidade
de gerar o trafego normal, e duas destinadas a realizar
os ataques (usuarios identificados com a nomenclatura
AtacanteX).

Uma vez feito o levantamento de requisitos e um esboco

da disposica o logica da rede, cujo cenario logico esta demonstrado na Figura 5, a implantaca o foi feita com maquinas
virtualizadas pelo utilitario Virtual Box. Todas, exceto os
atacantes, foram instaladas utilizando a distribuica o Debian
versao 7 (wheezy). Os papeis de rede dos servidores (roteador,
servidor web e servidor de monitoramento - zabbix), rede dos
clientes legtimos (roteador e clientes) e os dois hospedeiros
atacantes foram divididos em quatro ambientes em maquinas
separadas, interligadas por um switch de modelo 3Com 5500SI com portas Gigabit Ethernet (nas quais ficaram as redes
dos servidores e clientes) e Fast-Ethernet (em que ficaram os
atacantes). Para os atacantes foi instalada a distribuica o Kali

 E COMUNICACAO,
VOL. 4, NUMERO

REVISTA DE TECNOLOGIA DA INFORMAC

AO
1, JULHO DE 2014

Figura 7: Trafego normal de sada (aprox. 5 Mbit/s de trafego)

maior que de entrada (aprox. 65 Kbit/s) no Servidor Web com
quatro clientes em 20 minutos.
Figura 5: Cenario de Testes.

Linux, especfica para testes e auditoria de seguranca.

A. Medica o de Trafego Normal
Para simulaca o de trafego normal, quatro hosts virtualizados
faziam requisico es, atraves do utilitario wget, de uma pagina
previamente disponibilizada no servidor Web, com acionamento nao linear, visando obter um grau de similitude com os
padroes de trafego normais. Cada cliente tinha um limitador
logico de 128 KByte/s (aproximadamente 1 Mbit/s).
Como pode ser visto na Fig. 6, o trafego de entrada para
o servidor Web detectado pela ferramenta iptraf, constitudo
basicamente por requisico es TCP, foi de aproximadamente 50
Kbit/s e de cerca de 100 pacotes por segundo. Ja na interface
de sada do servidor para os clientes foi registrado um trafego
de 4 Mbit/s (quatro clientes gerando em torno de 1 Mbit/s)
com 350 pacotes por segundo.

Figura 6: IPTraf do servidor Web.

A ferramenta zabbix confirma esses numeros em graficos
como na Fig. 7, com a vantagem de mostrar o progresso dos
valores obtidos ao longo do tempo. Outra metrica interessante
fornecida pelo zabbix e a carga dos nucleos do processador,
a qual permaneceu em patamares considerados normais para
um servidor com poucas requisico es.
Outra ferramenta importante na analise do trafego foi o
tcpdump. Observando o trafego normal, ilustrado na Fig. 8,
verificou-se uma predominancia de pacotes TCP do tipo ACK,

usados na transferencia propriamente dita dos dados. Alem

disso, e possvel notar que as portas dos clientes se modificam
com pouca frequencia, uma vez que varias requisico es podem
ser feitas pela mesma conexao gracas ao recurso de conexao
persistente presente na versao 1.1 do protocolo HTTP.

Figura 8: Trafego normal com diferentes clientes.

B. Medica o de Trafego de Ataque

A partir do momento em que o ataque foi gerado, inicialmente com a ferramenta hping na sua versao 3 (hping3)
e com os parametros flood (envia pacotes o mais rapido
possvel sem se preocupar em mostrar as respostas de entrada)
e -S (Envia pacotes com flag SYN ativada), caracterizando
o ataque TCP SYN Flood, os graficos tomaram um rumo
inverso ao trafego normal. E possvel ver na Fig. 9 que o
trafego de entrada no servidor Web, a partir do tempo 16:37,
aumentou, e aproximadamente a` s 16:40 superou o trafego de
sada, sugerindo que havia muitos pedidos mas poucos estavam
sendo atendidos. O que se pode notar e que, nesse cenario,
as requisico es dos clientes se tornaram lentas o suficiente
para que o servidor demorasse a responde-las, dedicando
seus recursos a` negativa das requisico es de ataque TCP SYN
Flood. Em outros testes realizados no mesmo ambiente, a
taxa de sada nao caiu durante o ataque como no experimento
realizado na Fig. 9, mas ainda assim a taxa de entrada superou
a de sada. Com relaca o a` carga do processador durante o
ataque notou-se um aumento de 0,30 em media para proximo
dos 6,0.
E possvel que, durante alguns segundos, o trafego se torne
anormal, mas pode se tratar de trafego legtimo dos robos de

 E COMUNICACAO,
VOL. 4, NUMERO

REVISTA DE TECNOLOGIA DA INFORMAC

AO
1, JULHO DE 2014

rastreamento da web (tambem chamados de indexadores\ ). ximadamente para 34,43, como esta ilustrado na Fig. 12.
Durante o rastreamento desses robos, carga do processador do Visualizando seu trafego com tcpdump e possvel perceber a
grande quantidade de pacotes com flag PUSH para a porta 80,
servidor nao sofreu significativas alteraco es.
ilustrado na Fig. 13. Essa flag nao e muito utilizada em uma
comunicaca o normal entre cliente e servidor para acesso a uma
pagina Web. Um exemplo de sua utilizaca o [20] e quando um
programa aplicativo remetente precisa receber resposta rapida
do destinatario por ter executado algum comando antes que
outros dados sejam enviados. Entao ele envia ao destinatario
uma operaca o push e espera uma resposta rapida do destino.

Figura 9: Trafego de ataque utilizando hping. Numero

de pacotes de entrada (linha em ascensao) maior que a
sada/processada (linha em declnio\ ).
Alem dos graficos mostrarem um padrao anormal para o
trafego, ao analisar o trafego do servidor Web com tcpdump
na Fig. 10, percebe-se que o atacante envia varias requisico es
em curto espaco de tempo ao servidor Web com flag do tipo
SYN e recebe pacotes com flag do tipo RESET, comportamento
considerado anormal para os padroes. Essa u ltima flag indica
a intenca o da origem de abortar imediatamente a conexao
existente.
Figura 12: Carga do processador e instancias do apache
durante HTTP Flood.

Figura 10: Analise do trafego de ataque TCP SYN Flood.

Apos o primeiro experimento com ataque TCP SYN Flood,
um novo experimento foi realizado, ainda utilizando a ferramenta hping, mas incluindo os parametros -S e rand-source,
que caracteriza ataque com IP Spoofing. E possvel visualizar
alteraco es na captura do trafego onde surgem varios IPs requisitando recursos do servidor Web. O ataque possui comportamento parecido com o anterior, diferenciando apenas nos IPs
de origem, como ilustrado na Fig. 11. No cenario em questao
foi possvel bloquear esse tipo de ataque ativando no kernel
do Linux a proteca o contra IP Spoofing atribuindo o valor 1
ao arquivo rp filter localizado em /proc/sys/net/ipv4/conf/all.

Figura 11: Ataque de IP Spoofing.

Ja para o ataque HTTP Flood utilizando o LOIC foi possvel
identifica-lo pois a carga do processador saltou de 0,30 apro-

Figura 13: Flag PUSH sendo gerada pelo atacante.

C. Discussao
Os ataques gerados pela ferramenta hping3 geraram um
grande numero de pacotes por segundo (chegaram a cerca de
80 mil) e de consumo de banda (em torno de 40 Mbit/s), por
cada atacante. A carga de processamento do Servidor Web
(Apache) variou de 2 a 4, dependendo do momento do ataque.
Apesar do servidor Apache estar configurado para suportar ate
256 clientes, o ataque TCP SYN Flood com hping3 direcionado
a` porta 80 fez o servidor utilizar apenas 8 instancias. Um
so atacante, usando a ferramenta em modo faster ou flood,
conseguiu fazer o servidor negar servico, tanto pela interface
principal (que recebeu o ataque) quanto por uma interface alternativa que estava com trafego praticamente exclusivo a essa
tentativa. Esses dois modos tiveram desempenhos parecidos
no experimento, com uma leve superioridade (pouco acima de
10%) nos requisitos de pacotes por segundo e consumo de
banda para o modo faster.
A ferramenta LOIC gerou um trafego modesto quando
comparado ao hping3. Foi possvel perceber que ele gera
um trafego menor mas exige mais recursos do processador

 E COMUNICACAO,
VOL. 4, NUMERO

REVISTA DE TECNOLOGIA DA INFORMAC

AO
1, JULHO DE 2014

do atacante e da vtima para gerar e processar no destino

esse trafego do que com hping3. A quantidade de threads
para serem abertos vai depender do limite que a maquina
atacante suporte. Mesmo abrindo 120 threads, o trafego nao
superou os 400 Kbit/s nem os pacotes por segundo chegaram
a 700 (por atacante). Durante o ataque, o servidor atingiu o
limite de 256 instancias e a carga de processamento chegou a
superar o valor de 40. Para negar acesso dos clientes ao recurso
disponibilizado no servidor Web seria necessario mais de dois
atacantes realizando a mesma funca o. A ferramenta LOIC
nao suportou trabalhar com mais threads (quando configurado
valores de 130 ou superiores, nos dois atacantes, o programa
gerou algumas exceco es e encerrou sua execuca o).
Os volumes de trafego gerados pelo LOIC pouco diferiram
das taxas de clientes legtimos, sendo inviavel a identificaca o
do ataque por meio do analisador iptraf. Quando em modo
HTTP, esse ataque estabelece a conexao TCP (negociando
normalmente o three-way-handshake), fazendo as requisico es
e finalizando a sessao. Dessa forma, o fluxo de pacotes capturado no tcpdump tambem pareceu similar a um fluxo normal.
O ataque pode ser identificado pela carga de processamento,
que passou de valores em torno de 0,10 para mais de 40. O
numero de instancias do processo do Apache tambem subiu,
sendo outro indicativo importante. A anatomia do ataque,
dependendo da quantidade de origens, define se a negaca o de
servico sera ou nao concretizada. Outro fator interessante e que
o LOIC nao causou impacto significativo no processamento
do roteador, contrastando com o grande impacto causado pelo
hping.

Figura 14: Arquivo de log do Apache durante ataque HTTP

Flood.
Um ponto crucial para a identificaca o das origens do
ataque LOIC e a identificaca o do respectivo emissor foi a
analise e identificaca o de padrao nos pacotes gerados por
essa ferramenta. Para tal, dois metodos foram utitlizados:
analisar o conteudo dos pacotes (em nvel de aplicaca o do
modelo TCP/IP) e os registros de eventos (logs) do servico
HTTP. Nota-se que, independente da URL, os pacotes sempre
surgem com a mesma requisica o (GET / HTTP/1.1200
682 -Mozilla/5.0), conforme ilustrado na Fig. 14. Mesmo
alterando para diferentes URLs como alvo, o cabecalho da
requisica o nao se modificou. Comparando com o padrao de
logs nas transaco es legtimas como na Fig. 15, percebe-se
nitidamente a diferenca. Uma busca pela sequencia supracitada
nos logs resultou apenas em pacotes oriundos do atacante, o
que fornece subsdios para bloqueios no proprio servidor ou
em um firewall entre esse e o atacante (soluca o preferencial).
Do ponto de vista de efetividade, o ataque com hping3 con-

Figura 15: Arquivo de log do Apache durante trafego normal.

seguiu melhores resultados no sentido de fazer o servidor negar
servico e, principalmente, de inundar a rede de destino como
um todo. Quando se trata de comprometer o processamento,
o LOIC foi mais efetivo.
Quanto a` detecca o dos ataques, ponto-chave desse trabalho,
o hping foi detectado facilmente pela alteraca o nos ndices de
trafego (numero de pacotes e quantidade de banda passante),
tanto no tcpdump quanto no zabbix. Uma analise no tcpdump
tambem mostrou a repetica o anomala e sequencial de pacotes
TCP SYN, no caso do ataque de SYN Flood, ou TCP RST
(padrao do hping para ataques TCP). O ataque utilizando a
tecnica de mascaramento de origem (IP Spoofing) foi efetiva
quanto a` nao identificaca o da origem. Esse ataque pode ser
bloqueado com o uso do recurso de rp filter, uma vez que
o atacante que disfarca o endereco de origem nao recebe os
pacotes de resposta do servidor e nao tem como responde-los.
Ainda assim, o ataque causa grandes transtornos. Nesse caso,
a identificaca o de um padrao (porta de origem ou destino e/ou
endereco de origem ou destino) pode fornecer informaco es
para um bloqueio, normalmente atraves da criaca o de uma
ou mais rotas nulas, descartando tanto pacotes maliciosos
quanto legtimos, mas dando a` rede atacada algum nvel de
conectividade.
Ainda sobre detecca o, o ataque LOIC nao foi facilmente
identificado pelo iptraf e nem inicialmente pelo tcpdump
apenas analisando os sockets (relaca o de endereco e porta)
envolvidos. Apenas o aumento da carga de processamento e
do numero de instancias do Servidor Web foram indicativos
de ataque. Entretanto, uma analise mais meticulosa nos logs,
assim como no conteudo dos pacotes, permitiu o isolamento
do padrao de ataque por repetica o de uma mesma sequencia de
caracteres, o que permite identificar e bloquear os atacantes.
Porem, como atualmente existem botnets com milhares de
computadores zumbis (especula-se que possa haver botnets
com milhoes de participantes), o bloqueio individual pode
nao ser uma alternativa viavel. Nesse caso, o bloqueio geral
e a liberaca o de algumas origens pode manter um nvel
aceitavel de conectividade para localidades mais importantes
como enderecos de outras filiais, de parceiros ou para o
mesmo estado ou pas, desde que se tenha uma precisa lista
de exceco es.

IV. C ONCLUS AO
De acordo com o experimento realizado, foi possvel constatar que a ferramenta LOIC, quando utilizada em conjunto
com outras maquinas, incluindo uma botnet, e mais efetiva no
sentido de travar a execuca o da maquina de destino. O LOIC e
uma ferramenta desenvolvida exatamente para negar o servico
de uma maquina. O hping3 pode tambem ser utilizado em uma
botnet, mas nao existe na aplicaca o configuraca o especfica
para esse fim.
O que se pode perceber e que, em ambos os ataques, e
possvel identifica-los com as ferramentas disponveis antes

 E COMUNICACAO,
VOL. 4, NUMERO

REVISTA DE TECNOLOGIA DA INFORMAC

AO
1, JULHO DE 2014

que esgote todos os recursos da maquina de destino, pois

utilizam padroes especficos e geram trafego fora do normal.
Seria necessario, antes de tudo, estudar como se da o trafego
normal e assim configurar a ferramenta zabbix para gerar os
alertas.
Como sugestoes para trabalhos futuros, podem ser estudadas
mais profundamente a ferramenta HOIC e os mecanismos
de defesa ModSecurity e de algum sistema de detecca o
e/ou prevenca o de intrusao (IDS/IPS), como o sistema Snort.
Tambem podem ser avaliados os metodos de alertas dessas ferramentas e ate mesmo as do proprio Zabbix, que possibilitam
que um eventual ataque seja detectado e os administradores do
sistema avisados antes que os proprios usuarios prejudicados
comecem a reportar a falha no servico.
AGRADECIMENTOS
Esse trabalho teve o apoio do Nucleo de Tecnologia
da Informaca o (NTI) da Gerencia de Redes da UFPB, da
Coordenaca o de Aperfeicoamento de Pessoal de Nvel Superior (CAPES) e do Conselho Nacional de Desenvolvimento
Cientfico e Tecnologico (CNPQ).
R EFER E NCIAS
[1] Hakem Beitollahi, Geert Deconinck, Analyzing well-known countermeasures against distributed denial of service attacks, Computer Communications, Volume 35, Issue 11, 15 June 2012, Pages 1312-1332, ISSN
0140-3664.
[2] Chen, Yonghong, Ma, Xinlei, Wu, Xinya, DDoS Detection Algorithm
Based on Preprocessing Network Traffic Predicted Method and Chaos
Theory, Communications Letters, IEEE , vol.17, no.5, pp.1052,1054, May
2013.
[3] J. Liu, Y. Xiao, K. Ghaboosi, H. Deng, and J. Zhang, Botnet: Classification, Attacks, Detection, Tracing and Preventive Measures, EURASIP J.
Wireless Communications and Networking, vol. 2009, Article ID 692654,
11 pages, 2009.
[4] Al-Duwairi, B, Al-Qudah, Z, Govindarasu, M 2013, A Novel Scheme
for Mitigating Botnet-Based DDoS Attacks, Journal Of Networks, 8, 2,
pp. 297-306, Computers and Applied Sciences Complete, EBSCOhost,
viewed 11 December 2013.
[5] V.Shyamaladevi, Dr. R.S.D. WahidaBanu, Detection of Spoofing Attacks
Using Intrusive Filters For DDoS, IJCSNS International Journal of
Computer Science and Network Security, VOL.8 No.10, October 2008.
[6] Yi Xie, Shun-zheng Yu, Monitoring the Application-Layer DDoS Attacks
for Popular Websites, Networking, IEEE/ACM Transactions on , vol.17,
no.1, pp.15,25, Feb. 2009.
[7] Zargar, S.T., Joshi, J., Tipper, D., A Survey of Defense Mechanisms
Against Distributed Denial of Service (DDoS) Flooding Attacks, Communications Surveys and Tutorials, IEEE, vol.15, no.4, pp.2046,2069,
Fourth Quarter, 2013.
[8] The New York Times, How the Cyberattack on Spamhaus Unfolded, [online], http://www.nytimes.com/interactive/2013/03/30/technology/howthe-cyberattack-on-spamhaus-unfolded.html (acessado em 20 de
novembro de 2013).
[9] Sang Min Lee, Dong Seong Kim, Je Hak Lee, Jong Sou Park, Detection of
DDoS attacks using optimized traffic matrix, Computers and Mathematics
with Applications, Volume 63, Issue 2, January 2012, Pages 501-510,
ISSN 0898-1221.
[10] Francois, J., Aib, I., Boutaba, R., FireCol: A Collaborative Protection
Network for the Detection of Flooding DDoS Attacks, Networking,
IEEE/ACM Transactions on , vol.20, no.6, pp.1828,1841, Dec. 2012.
[11] Almeida, Leandro Cavalcanti, Ferramenta Computacional para
Identificaca o e Bloqueio de Ataques de Negaca o de Servico em Aplicaco es
Web, Dissertaca o, Centro de Informatica, UFPB, 2013.
[12] Y. Xie, S. Tang, and X. Huang, Detecting latent attack behavior from
aggregated Web traffic, Computer Communications, no. 5, pp. 895907,
2013.
[13] J. Mirkovic, P. Reiher, A taxonomy of DDoS attack and DDoS defense
mechanisms, ACM SIGCOMM Computer Communications Review, vol.
34, no. 2, pp. 39-53, April 2004.

[14] Christos Douligeris, Aikaterini Mitrokotsa, DDoS attacks and defense

mechanisms: classification and state-of-the-art, Computer Networks, Volume 44, Issue 5, 5 April 2004, Pages 643-666, ISSN 1389-1286.
[15] Yu, Shun-Zheng. Hidden semi-Markov models. Elsevier. Artificial Intelligence, Vol.174(2), pp. 215-243, February, 2010.
[16] Yu, S., Tian, Y., Guo, S., Wu, D., Can We Beat DDoS Attacks in Clouds?,
Parallel and Distributed Systems, IEEE Transactions on , vol.PP, no.99,
pp.1,1, 0.
[17] Barnett, Ryan C., Web Application Defenders Cookbook Battling Hackers and Protecting Users, Wiley Publishing, Inc., pp. 20,21,402-411.
[18] Manish Saxena, Jameel Hashmi, Dr. D.B.Singh, Classification of DDoS
Attacks and their Defence Techniques using Intrusion Prevention System,
IJCSCN Volume 2, Issue 5, October-November 2012.
[19] Dimuro, G.P, Reiser, R. H. S, Costa, A. C. R, Sousa, P. L. R., Modelos
de Markov e Aplicaco es. VI Oficina de Inteligencia Artificial, Pelotas.
Anais da VI OIA. Pelotas: Educat, 2002. p. 37-59.
[20] Forouzan, Behrouz A. Protocolo TCP/IP. 3a edica o, pp. 288,289, Ed.
Bookman, 2009.
[21] Z.L. Chen Zhonghua, W. Xiaoming, Research on detection methods of
CC attack, Telecommunication Science (2009) 6265.
[22] Hamza Rahmani, Nabil Sahli, Farouk Kamoun, DDoS flooding attack
detection scheme based on F-divergence, Computer Communications,
Volume 35, Issue 11, 15 June 2012, Pages 1380-1391, ISSN 0140-3664.
[23] S.Gavaskar, R.Surendiran, Dr. E.Ramaraj, Three Counter Defense Mechanism for TCP SYN Flooding Attacks, International Journal of Computer Applications (0975 8887), Volume 6 No.6, September 2010.
[24] Sirisha Surisetty, Sanjeev Kumar, McAfee Security Center Evaluation
under DDoS Attack Traffic, Journal of Information Security, 2011, 2,
113-121.
[25] Laxmi Bala, A K Vatsa, Quality based Bottom-up-Detection and Prevention Techniques for DDOS in MANET. International Journal of Computer
Applications 55(2):12-19, October 2012.
[26] Hang, B., Hu, R., Shi, W, An enhanced SYN cookie defense method for
TCP DDoS attack, Journal of Networks, 2011, Vol.6(8), pp.1206-121.
[27] Safa, Haida, Chouman, Mohamad, Artail, Hassan, Karam, Marcel, A
collaborative defense mechanism against SYN flooding attacks in IP networks, Journal of Network and Computer Applications, 2008, Vol.31(4),
pp.509-534.
[28] Steve Mansfield-Devine, DDoS: threats and mitigation, Network Security, Volume 2011, Issue 12, December 2011, Pages 5-12, ISSN 13534858.
[29] Steve Mansfield-Devine, Anonymous: serious threat or mere annoyance?, Network Security, Volume 2011, Issue 1, January 2011, Pages
4-10, ISSN 1353-4858.
[30] Molly Sauter, LOIC Will Tear Us Apart: The Impact of Tool Design
and Media Portrayals in the Success of Activist DDOS Attacks, American
Behavioral Scientist, 2013 57: 983 published online 15 March 2013.
[31] Lu, Wei-Zhou, Yu, Shun-Zheng, An HTTP Flooding Detection Method
Based on Browser Behavior, International Conference on Computational
Intelligence and Security (Vol. 2), pp. 1151-1154, 3-6 Nov. 2006.
[32] Janowski, Davis D., Oliver Kaven. Small-business security: for cashstrapped, IT-barren companies, all-in-one security appliances offer affordable protection. Heres how to make one work for your network, PC
Magazine 2 Mar. 2004: 113+.
[33] Thapngam, Theerasak and Yu, Shui and Zhou, Wanlei and Makki,
S.Kami, Distributed Denial of Service (DDoS) detection by traffic pattern
analysis, Peer-to-Peer Networking and Applications, ISSN 1936-6442,
2012, pp. 1-13.
[34] Kuochen Wang, Chun-Ying Huang, Shang-Jyh Lin, Ying-Dar Lin, A
fuzzy pattern-based filtering algorithm for botnet detection, Computer
Networks, Volume 55, Issue 15, 27 October 2011, Pages 3275-3286, ISSN
1389-1286.
[35] TrustWave SpiderLab, (Updated) ModSecurity Advanced Topic of
the Week: Mitigating Slow HTTP DoS Attacks, Jul. 13, 2011,
[online] http://blog.spiderlabs.com/2011/07/advanced-topic-of-the-weekmitigating-slow-http-dos-attacks.html (acessado em 11 de dezembro de
2013)

All in-text references underlined in blue are linked to publications on ResearchGate, letting you access and read them immediately.