:- ;SVOWLST HI 8- HEW -*)7 +SMRME +3

Visualizao e Aes Tomadas Frente ao

Ataque ao Servidor de Portais Web da UFG
Marcello Henrique Dias de Moura
Mrio Augusto da Cruz
Hugo Alexandre Dantas do Nascimento
Centro de Recursos Computacionais, Universidade Federal de Gois (UFG)
Caixa Postal 131, CEP 74.001-970, Goinia-GO, Brasil
{marcello, mario, diretor}@cercomp.ufg.br

Resumo. Este artigo relata o ataque sofrido pela UFG no seu servidor de Portais Web e
descreve as tcnicas de visualizao de informaes, as ferramentas computacionais e as
solues de gerncia de redes adotadas pela equipe interna da Universidade para analisar
e mitigar o problema. O tipo de ataque utilizado muito comum e difcil de ser contido,
sendo que a experincia adquirida serve de apoio para outras instituies de ensino que
esto sujeitas a incidentes similares.
Abstract. This papers reports the Internet attack on UFGs Web site server. It also describes the information visualization techniques, the computational tools and the networking
managment solutions that were employed by the University IT team for analysing and mitigating the problem. Such type of attack is very common and difficult to contain. Therefore,
the experience acquired by dealing with it is usefull for other educational instituitions the
may encounter similar situations.

1. Introduo
A infraestrutura para servios de portal Web da universidade composta por servidores Web
e sistemas gerenciadores de banco de dados, todos virtualizados, os quais mantm um conjunto de
mais de 300 stios para unidades acadmicas, rgos administrativos e ncleos de pesquisa e extenso e mais de 60 projetos no homologados pelo Cercomp [3] utilizando tecnologia PHP. Frente ao
volume de stios, da quantidade de informao disponibilizada ao pblico interno e externo da UFG
e quantidade de usurios dirios, a interrupo, ou mesmo a simples lentido desse sistema, tem
impacto significativos nas atividades adminstrativas da instituo.
No incio de novembro de 2011, vrios setores da UFG comearam a reclamar unidade de
TI sobre a lentido no acesso aos portais Web. De fato, os servios Web haviam se tornado to lentos
que cliques dos usurios sobre as pginas dos portais levavam minutos para produzirem uma resposta.
Algumas horas depois da reclamao, era preciso reiniciar o servidor para restabelecer o servio. No
entanto, a lentido dos portais voltava a ocorrer periodicamente.
Com os servios funcionando precariamente, o setor de TI responsvel pelos servidores
mobilizaram-se para analisar a situao, tendo identificado um ataque intenso de DDoS em intervalos de tempo regulares, seguidos de um fluxo contnuo de trafgo direcionados para alguns domnios
especficos.
Vrias abordagens foram pensadas e testadas para analisar a natureza do problema e procurar
conter o ataque. As prximas sees deste trabalho descrevem as ferramentas e estratgias utilizadas
nessa tarefa. Comeamos, no entanto, com uma breve introduo sobre DDoS e outras formas comuns
de ataque a servidores Web.

2. Formas Comuns de Ataque Web

Um dos tipos de ataque a servidores Web, e que foi utilizado contra a UFG, o Distributed
Denial of Service (DDoS). Um ataque DDoS consiste em fazer milhares de requisies simultneas
ao servidor vtima, deixando-o ocupado atendendo as mesmas, o que provoca lentido no atendimento
das demais requisies legtimas. Normalmente so utilizadas milhares de mquinas comprometidas
ou controladas remotamente (zombies) para produzir as requisies do atacante. A percepo para os
usurios de que o site est muito lento para responder ou mesmo inacessvel.
Os atuais servidores Web de cdigo aberto (Apache, Lighttpd, Nginx) no possuem mecanismos nativos para combater esse tipo de ataque. Eles apenas disponibilizam diretivas de configurao
para limitar a quantidade de requisies atendidas, porm, tal recurso no efetivo frente ao DDoS
pois no permite diferenciar requisies do atacante de requisies legtimas, portanto, necessrio
um outro tipo de ferramenta para essa identificao.
O segundo tipo de ataque, conhecido como ZeroWindow [1], explora uma falha de projeto
do protocolo TCP (Transmission Control Protocol). Aps a conexo TCP ser estabelecida (3-way
handshake), o atacante envia um pacote com campo window, do cabealho, definido com valor zero.
Nessa situao o servidor pausa o envio de pacotes para o outro lado, deixando assim o socket aberto,
sendo que este consome recursos de memria. Se o atacante repetir esse procedimento milhares de
vezes, ele consegue com sucesso manter vrios sockets abertos no servidor, e assim consumir uma
quantidade significativa de memria. Esse tipo de ataque requer poucos recursos do atacante (pode ser
rodado a partir de uma nica mquina) e se mostra efetivo para degradar a performance do servidor.
Para piorar a situao, existem tambm, ferramentas disponveis na Internet, como Sockstress [12],
que facilitam a automatizao do ataque.

3. Visualizaes e Anlise dos Dados do Ataque

Para ajudar na anlise do problema de lentido dos servidores e que, inclusive, possibilitou
caracterizar uma de suas causas como um ataque de DDoS, foram utilizadas duas ferramentas de
anlise e visualizao de dados.
A primeira ferramenta empregada foi a Logstalgia [9], um software livre que produz visualizaes dinmicas do trfego de acesso a um recurso Web. A ferramenta pode trabalhar acoplada
ao servidor Web sendo que a visualizao consiste em mostrar, em tempo real, no lado esquerdo da
tela, o IP da mquina do usurio que est acessado o portal, enquanto que, no lado direito, aparece
a referncia pgina acessada. As requisies Web e suas respostas so representadas por bolas coloridas que atravessam a tela partindo da indicao do IP at alcanar o nome da pgina solicitada e
no sentido inverso, respectivamente. Uma barra no lado direito desloca-se verticalmente para colidir
com as bolas, assemelhando-se a um jogo eletrnico de ping-pong, mostrando tambm o cdigo de
status http resultante do atendimento de cada requisio.
A ferramenta Logstalgia foi modificada pelo Cercomp para apresentar apenas as bolas referentes s requisies (atravessando a tela da direita para a esquerda) e no as de resposta, a fim de
evitar uma sobrecarga visual de informaes. Alm disso, um efeito visual de mudana de brilho no
momento de coliso da barra vertical com as bolas foi desativado. O registro de atividades de todos
os domnios do servidor foi direcionado para somente um arquivo que serve como entrada para gerar
a visualizao pelo Logstalgia.
A Figura 1(a) demonstra as requisies de pginas Web em uma situao normal, sem lentido do servidor principal de Portais. J a Figura 1(b) mostra as requisies exatamente no incio do
ataque. possvel verificar, nesta figura, uma massa de requisies simultneas para diversas pginas
ao mesmo tempo, vindas de dezenas de mquinas espalhadas pelo mundo. Tal rajada de requisies
durava alguns segundos, logo em seguida, uma sequncia de requisies direcionadas por uma quantidade menor de mquinas, porm mais constante e com maior intensidade que durava alguns minutos,

como ilustra a Figura 1(c). O ciclo de ataque comeando com uma nova rajada de requisies e uma
sequencia intensa de consultas aos portais repetia-se a cada 45 minutos, aproximadamente.

(a)

(b)

(c)

Figura 1. Visualizao das requisies Web. A imagem (a) mostra as requisies em situao
normal. A imagem (b) ilustra a rajada de requisies no incio de um ciclo de ataque. J a
imagem (c) mostra a sequncia intensa de requisies que completa o ciclo.

O objetivo das requisies excessivas era, no apenas tornar o servio Web lento pelo volume
inicial de requisies a serem atendidas, mas tambm fazer com que o servidor Web criasse vrias
novas portas de conexo para tal atendimento. Essas portas eram mantidas abertas, consumindo
permanentemente recursos da mquina e reduzindo a possibilidade de atendimento das legtimas requisies dos usurios.
A segunda ferramenta utilizada foi o software livre Zabbix [14], configurado para monitorar
o consumo de CPU e de memria dos servidores, alm do volume de trfego de rede e a quantidade
de processos abertos nas mquinas. A Figura 2 apresenta um grfico do Zabbix mostrando o uso
dos recursos do servidor Web principal durante o perodo do ataque. A imagem confirma o consumo
excessivo de recursos do servidor a cada ciclo de ataque at atingir um limite onde o servidor se
tornava inoperante, precisando ser reiniciado para restaurar o funcionamento do servio.

Figura 2. Grficos do Zabbix de consumo dos recursos do servidor Web.

4. Atuando para Mitigar o Ataque

Aps a confirmao que se tratava de um ataque pelas das ferramentas de visualizao,
iniciou-se a fase de pesquisa e anlise para reduzir ou anular o impacto sobre servidor. Na primeira
etapa os esforos foram concentrados em ajustar parmetros no ncleo do sistema operacional e tambm em formas de conter o ingresso de pacotes maliciosos que exploravam o ZeroWindow. Logo em
seguida foi feito um trabalho de anlise na camada do servio, com o objetivo de reduzir o tempo de
processamento no atendimento as requisies para aumentar sua capacidade.

Paralelamente a esses esforos, outra equipe j cumpria um cronograma de reestruturao que

causava intensa mudana na infraestrutura lgica at a arquitetura dos servios Web. Na subseo 4.2
descreve detalhadamente as aes efetuadas.
4.1. Solues a Nvel de Kernel do Sistema Operacional e Redes
Como primeira forma de minimizar os problemas causados pelos ataques foi feita uma anlise
dos parmetros do kernel que poderiam ser configurados para melhorar o desempenho da pilha TCP
(utilizado pelo protocolo HTTP - Hypertext Transfer Protocol) do sistema operacional. Os parmetros
que foram alterados encontram-se no Registro 1:

net.ipv4.tcp_fin_timeout = 20
net.ipv4.tcp_max_orphans = 5000
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_tw_reuse = 1

Registro 1. Parmetros do kernel que foram alterados.

Em seguida, a anlise foi voltada para a camada de rede objetivando impedir ou reduzir o
mximo possvel a entrada de pacotes com a caracterstica do ZeroWindow. Atravs de pesquisas
em listas de discusso chegou-se a um conjunto de regras de firewall que efetuavam a conteno de
pacotes TCP que possuem o campo window com valor zero, com uma taxa pr-determinada. Essas
regras foram configuradas com o utilitrio iptables [7] conforme o Registro 2:

iptables -N ZERO_WINDOW_RECENT
iptables -A -m u32 --u32 "6&0xFF=0x6 && 4&0x1FFF=0 && 0>>22&0x3C@12&0xFFFF=0x0000" -j
ZERO_WINDOW_RECENT
iptables -A ZERO_WINDOW_RECENT -m recent --set --name ZERO_WINDOW
iptables -A ZERO_WINDOW_RECENT -m recent --update --seconds 60 --hitcount 2 --name ZERO_WINDOW -j
LOG --log-level info --log-prefix "Zero size Window DoS blocked: "
iptables -A ZERO_WINDOW_RECENT -m recent --update --seconds 60 --hitcount 2 --name ZERO_WINDOW -j
DROP

Registro 2. Regras de iptables para pacotes ZeroWindow.

Outro aspecto notado, foi que nos perodos de ataque a quantidade de entradas na tabela de
conexes do servidor crescia muito rpido. Esse comportamento estava associado ao mecanismo
de funcionamento do ataque ZeroWindow que provocava um grande nmero de conexes pendentes.
Exemplos dessas entradas podem ser vistas no Registro 3:

...
tcp
tcp
tcp
tcp
tcp
tcp
tcp
tcp
tcp
...

0
0
0
0
0
0
0
0
0

1711
12241
8890
181
36301
0
441
0
0

200.xxx.xxx.xxx:80
200.xxx.xxx.xxx:80
200.xxx.xxx.xxx:80
200.xxx.xxx.xxx:80
200.xxx.xxx.xxx:80
200.xxx.xxx.xxx:80
200.xxx.xxx.xxx:80
200.xxx.xxx.xxx:80
200.xxx.xxx.xxx:80

188.143.xxx.xxx:57148
189.27.xxx.xxx:49310
189.93.xxx.xxx:49706
189.74.xxx.xxx:1333
201.14.xxx.xxx:1230
201.24.xxx.xxx:49523
157.55.xxx.xxx:45227
163.231.xxx.xxx:20399
163.231.xxx.xxx:20438

ULTIMO_ACK
ULTIMO_ACK
ESPERA_FIN1
ESPERA_FIN1
ULTIMO_ACK
TIME_WAIT
ESPERA_FIN1
TIME_WAIT
TIME_WAIT

em
em
em
em
em
timewait
em
timewait
timewait


Registro 3. Entradas na tabela de conexes do servidor.

4.2. Solues a Nvel de Servidor Web

No perodo do ataque, a mquina servidora de Portais contava com a instalao do Servidor
HTTP Apache-2.2.16 - modelo tradicional sem threads - para servir pginas Web, alm dos mdulos de proxy, rewrite e PHP 5 habilitados. Para cada requisio de entrada era criado um processo
no sistema operacional. Como os recursos de processamento e memria so reduzidos, tambm era
necessrio limitar a quantidade de conexes permitidas.

Aps avaliao do ataque no sistema de monitoramento Zabbix, notamos que os limites de

conexes permaneciam constantemente sobrecarregados. As inmeras tentantivas de soluo mencionadas anteriormente no foram eficazes, fucionando apenas como paliativo. Para solucinar definitivamente o problema, foi decidido alterar o servidor Web para outro que suportasse muitas conexes
concorrentes.
A equipe de redes j tinha boa experincia com o uso do Lighttpd [8] no portal principal da
universidade. Isso motivou a equipe a avaliar tambm o Nginx [10], usado por grandes projetos como
Dropbox [4], Wordpress [13], Facebook [5], Github [6] e em mais de quarenta milhes de domnio por
toda a Internet. O Lighttpd e o Nginx so similares tanto em desempenho quanto em funcionalidades.
Ambos se propem a resolver o problema C10K [2], o qual consiste em atender mais de dez mil
conexes simultneas. Em funo da sintaxe legvel e agradvel, optou-se pelo uso do Nginx. A
soluo Nginx implementa, alm disso, uma arquitetura guiada a eventos assncronos, ao invs de
threads, sendo, por essa caracterstica, muito utilizado como um proxy reverso e balanceador de
carga eficiente.
O servidor Web j tinha suporte s linguagens de programao PHP e Ruby. Para atendimento a essas demandas, os novos servios foram divididos de acordo com a linguagem de forma que
pudessem ser usados concomitantemente, ou seja, um no atrapalhando o outro.
4.2.1. Atendimento das requisies PHP
Para disponibilizar, bem como para otimizar, as requisies PHP no novo servidor, foi utilizado o FastCGI Process Manager (PHP-FPM [11]) como alternativa ao FastCGI puro. Algumas
de suas funcionalidade so:
gerenciador de processos, com capacidade de iniciar e parar processos, caso necessrio;
habilidade para iniciar processos com diferentes configuraes de ambiente (uid/gid/chroot) e
diferentes arquivos de configurao php.ini;
registro de atividades;
reinicializao automtica em caso de acidente ou travamento;
acelerao de recebimento de arquivos;
suporte para registro de lentido de processos;
escalabilidade, podendo criar mais processos de acordo com a demanda;
e outros.
A funcionalidade de registro de lentido de processos extremamente til. Pode ser definido
um tempo limite. Caso excedido tal tempo, as operaes executadas so registradas, inclusive suas
funes, para fins de anlise e futura correo pelos desenvolvedores. Esses problemas so difceis
de identificar e reportar sem o auxlio de um ferramenta adequada.
indiscutvel a utilidade dessa funcionalidade, por permitir conhecer possveis pontos de
falha nas aplicaes, alm de servir como direcionador para os pontos crticos encontrados. Como
exemplo, o Registro 4 mostra o histrico de uma aplicao que rodou por mais de 20 segundos. Seu
nome foi suprimido para evitar identificao.

[13-Mar-2012 14:55:27] [pool www] pid 31266

script_filename = [...]/php/resultadoFrame.php
[0x0000000001766dc0] fgets() [...]/libphp/nusoap.php:2267
[0x0000000001766928] getResponse() [...]/libphp/nusoap.php:1974
[0x00000000017656b0] send() [...]/libphp/nusoap.php:6082
[0x0000000001762d60] send() [...]/libphp/nusoap.php:5981
[0x000000000175f230] call() [...]/php/monta_busca_rapida.php:229
[0x000000000175dc98] +++ dump failed

Registro 4. Funes responsveis pela lentido do programa.

Como observado no registro,

h uma demora considervel no script
monta_busca_rapida.php na linha 229, o que, provavelmente, caracteriza uma consulta ao
banco que no foi otimizada.
4.2.2. Atendimento de requisies Rails
A Equipe Web do Cercomp utiliza um gerenciador de contedo Web (CMS) desenvolvido
in house para gerir seus quase 400 portais Web de unidades acadmicas e rgos administrativos. A
primeira verso dessa ferramenta, chamada This, foi desenvolvida em PHP. J a atual, chamada Weby,
usa Ruby como linguagem de programao e framework Rails.
A mudana de tecnologia da aplicao de portal Web j era planejada como forma de permitir
a padronizao de cdigo, a melhoria na lgica de programao e a utilizao de novas metodologias
consolidadas de desenvolvimento de software como o desenvolvimento guiado a testes e o uso de
camadas de abstrao para conexo com a base de dados. No entanto, essa mudana foi antecipada,
frente aos ataques, como forma tambm de aumentar a capacidade de atendimento das requisies
aos servios web.
Foi escolhido o interpretador Ruby denomindado Thin para ser integrado ao Nginx. Um
comparativo grfico entre os melhores interpretadores Ruby demonstrado na Figura 3.

Figura 3. Comparao entre servidores de pginas para Ruby com base no nmero de requisies por segundos. O Rtulo c req. representa o nvel de concorrncia, ou seja, o nmero
de requisies simultneas.

As requisies dos usurios so gerenciadas pelo Nginx e direcionadas atravs de proxy para
o Thin. Configuramos e rodamos 3 processos do Thin, cada um escutando em um porta distinta, para
aumentar a disponibilidade do servio.

5. Concluso
Neste trabalho, comentamos sobre a tentativa de derrubar o servidor de portais Web da UFG
caracterizada por ataques do tipo DDoS e ZeroWindow. Os ataques, de fato, causaram lentido e
interrupo dos servios web, tendo prejudicado quase 400 Portais Web da instituio. Ferramentas
computacionais para anlise de dados de rede e do consumo dos recursos dos servidores, com tcnicas
de visualizao de informaes, foram importantes para estudar e identificar a causa do problema,
bem como, para verificar a eficcia das solues adotadas pelas equipes do Cercomp.
O ataque durou ao todo quase 3 meses de forma contnua, tendo parado somente em janeiro
de 2012. Durante esse perodo, foram realizadas modificaes nas configuraes bsicas de rede,

no sistema operacional e nas aplicaes do servidor Web, as quais anularam o impacto dos ataques.
No atual momento, os portais Web esto funcionando normalmente, com capacidade suficiente para
atender o acentuado crescimento de demandas nesta rea.
Outra soluo que acreditamos ser eficiente para ataques distribudos como o que foi presenciado ter recursos de infraestrutura, tambm distribudos e que possam ser estendidos de forma
dinmica, ou seja, de acordo com a necessidade. Os esforos esto sendo guiados nesse sentido e
estudos de configuraes de hardware e software para implementar essa soluo um trabalho futuro
a ser desenvolvido.

Referncias
[1] US-CERT Vulnerabilidade TCP ZeroWindow. http://www.kb.cert.org/vuls/id/
723308, 2011. 2
[2] C10K Problem. http://www.kegel.com/c10k.html, 2012. 5
[3] CERCOMP Centro de Recursos Computacionais da UFG. http://www.cercomp.ufg.
br, 2012. 1
[4] Dropbox Servio de compartilhamento de arquivos. http://www.dropbox.com, 2012.
5
[5] Facebook Aplicativo para redes sociais. http://www.facebook.com, 2012. 5
[6] Github Gerenciador de projetos. http://www.github.com, 2012. 5
[7] iptables Utilitrio para configurar regras de firewall no kernel do linux. http://www.
netfilter.org/, 2012. 4
[8] Lighttpd Servidor de pginas de alto desempenho. http://www.lighttpd.net, 2012.
5
[9] Logstalgia Ferramenta de visualizao de trfego Web. http://code.google.com/p/
logstalgia/, 2012. 2
[10] Nginx Servidor de pginas de alto desempenho. http://www.nginx.org, 2012. 5
[11] PHP-FPM FastCGI Process Manager. http://php-fpm.org, 2012. 5
[12] Sockstress Ferramenta automatizada para ataque ZeroWindow. http://en.wikipedia.
org/wiki/Sockstress, 2012. 2
[13] Wordpress Gerenciador de Blogs. http://www.wordpress.org, 2012. 5
[14] Zabbix Ferramenta de monitoramento de trfego. http://www.zabbix.com, 2012. 3