Visualização e Ações Tomadas Frente aoAtaque ao Servidor de Portais Web da UFG

Marcello Henrique Dias de MouraMário Augusto da Cruz

Hugo Alexandre Dantas do Nascimento

Centro de Recursos Computacionais, Universidade Federal de Goiás (UFG)Caixa Postal 131, CEP 74.001-970, Goiânia-GO, Brasil

{marcello, mario, diretor}@cercomp.ufg.br

Resumo. Este artigo relata o ataque sofrido pela UFG no seu servidor de Portais Web edescreve as técnicas de visualização de informações, as ferramentas computacionais e assoluções de gerência de redes adotadas pela equipe interna da Universidade para analisare mitigar o problema. O tipo de ataque utilizado é muito comum e difícil de ser contido,sendo que a experiência adquirida serve de apoio para outras instituições de ensino queestão sujeitas a incidentes similares.

Abstract. This papers reports the Internet attack on UFG’s Web site server. It also descri-bes the information visualization techniques, the computational tools and the networkingmanagment solutions that were employed by the University IT team for analysing and miti-gating 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 themay encounter similar situations.

1. Introdução

A infraestrutura para serviços de portal Web da universidade é composta por servidores Webe sistemas gerenciadores de banco de dados, todos virtualizados, os quais mantêm um conjunto demais de 300 sítios para unidades acadêmicas, órgãos administrativos e núcleos de pesquisa e exten-são e mais de 60 projetos não homologados pelo Cercomp [3] utilizando tecnologia PHP. Frente aovolume de sítios, da quantidade de informação disponibilizada ao público interno e externo da UFGe à quantidade de usuários diários, a interrupção, ou mesmo a simples lentidão desse sistema, temimpacto significativos nas atividades adminstrativas da institução.

No início de novembro de 2011, vários setores da UFG começaram a reclamar à unidade deTI sobre a lentidão no acesso aos portais Web. De fato, os serviços Web haviam se tornado tão lentosque cliques dos usuários sobre as páginas dos portais levavam minutos para produzirem uma resposta.Algumas horas depois da reclamação, era preciso reiniciar o servidor para restabelecer o serviço. Noentanto, a lentidão dos portais voltava a ocorrer periodicamente.

Com os serviços funcionando precariamente, o setor de TI responsável pelos servidoresmobilizaram-se para analisar a situação, tendo identificado um ataque intenso de DDoS em interva-los de tempo regulares, seguidos de um fluxo contínuo de trafégo direcionados para alguns domíniosespecíficos.

Várias abordagens foram pensadas e testadas para analisar a natureza do problema e procurarconter o ataque. As próximas seções deste trabalho descrevem as ferramentas e estratégias utilizadasnessa tarefa. Começamos, no entanto, com uma breve introdução sobre DDoS e outras formas comunsde ataque a servidores Web.

������������������:-�;SVOWLST�HI�8-�HEW�-*)7��+SM¥RME�+3������

2. Formas Comuns de Ataque WebUm 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 requisições simultâneasao servidor vítima, deixando-o ocupado atendendo as mesmas, o que provoca lentidão no atendimentodas demais requisições legítimas. Normalmente são utilizadas milhares de máquinas comprometidasou controladas remotamente (zombies) para produzir as requisições do atacante. A percepção para osusuários é de que o site está muito lento para responder ou mesmo inacessível.

Os atuais servidores Web de código aberto (Apache, Lighttpd, Nginx) não possuem mecanis-mos nativos para combater esse tipo de ataque. Eles apenas disponibilizam diretivas de configuraçãopara limitar a quantidade de requisições atendidas, porém, tal recurso não é efetivo frente ao DDoSpois não permite diferenciar requisições do atacante de requisições legítimas, portanto, é necessárioum outro tipo de ferramenta para essa identificação.

O segundo tipo de ataque, conhecido como ZeroWindow [1], explora uma falha de projetodo protocolo TCP (Transmission Control Protocol). Após a conexão TCP ser estabelecida (3-wayhandshake), o atacante envia um pacote com campo window, do cabeçalho, definido com valor zero.Nessa situação o servidor pausa o envio de pacotes para o outro lado, deixando assim o socket aberto,sendo que este consome recursos de memória. Se o atacante repetir esse procedimento milhares devezes, ele consegue com sucesso manter vários sockets abertos no servidor, e assim consumir umaquantidade significativa de memória. Esse tipo de ataque requer poucos recursos do atacante (pode serrodado a partir de uma única máquina) e se mostra efetivo para degradar a performance do servidor.Para piorar a situação, existem também, ferramentas disponíveis na Internet, como Sockstress [12],que facilitam a automatização do ataque.

3. Visualizações e Análise dos Dados do AtaquePara ajudar na análise do problema de lentidão dos servidores e que, inclusive, possibilitou

caracterizar uma de suas causas como um ataque de DDoS, foram utilizadas duas ferramentas deanálise e visualização de dados.

A primeira ferramenta empregada foi a Logstalgia [9], um software livre que produz visua-lizações dinâmicas do tráfego de acesso a um recurso Web. A ferramenta pode trabalhar acopladaao servidor Web sendo que a visualização consiste em mostrar, em tempo real, no lado esquerdo datela, o IP da máquina do usuário que está acessado o portal, enquanto que, no lado direito, aparecea referência à página acessada. As requisições Web e suas respostas são representadas por bolas co-loridas que atravessam a tela partindo da indicação do IP até alcançar o nome da página solicitada eno sentido inverso, respectivamente. Uma barra no lado direito desloca-se verticalmente para colidircom as bolas, assemelhando-se a um jogo eletrônico de ping-pong, mostrando também o código destatus http resultante do atendimento de cada requisição.

A ferramenta Logstalgia foi modificada pelo Cercomp para apresentar apenas as bolas refe-rentes às requisições (atravessando a tela da direita para a esquerda) e não as de resposta, a fim deevitar uma sobrecarga visual de informações. Além disso, um efeito visual de mudança de brilho nomomento de colisão da barra vertical com as bolas foi desativado. O registro de atividades de todosos domínios do servidor foi direcionado para somente um arquivo que serve como entrada para gerara visualização pelo Logstalgia.

A Figura 1(a) demonstra as requisições de páginas Web em uma situação normal, sem lenti-dão do servidor principal de Portais. Já a Figura 1(b) mostra as requisições exatamente no início doataque. É possível verificar, nesta figura, uma massa de requisições simultâneas para diversas páginasao mesmo tempo, vindas de dezenas de máquinas espalhadas pelo mundo. Tal rajada de requisiçõesdurava alguns segundos, logo em seguida, uma sequência de requisições direcionadas por uma quanti-dade menor de máquinas, porém mais constante e com maior intensidade que durava alguns minutos,

como ilustra a Figura 1(c). O ciclo de ataque começando com uma nova rajada de requisições e umasequencia intensa de consultas aos portais repetia-se a cada 45 minutos, aproximadamente.

(a) (b) (c)

Figura 1. Visualização das requisições Web. A imagem (a) mostra as requisições em situaçãonormal. A imagem (b) ilustra a rajada de requisições no início de um ciclo de ataque. Já aimagem (c) mostra a sequência intensa de requisições que completa o ciclo.

O objetivo das requisições excessivas era, não apenas tornar o serviço Web lento pelo volumeinicial de requisições a serem atendidas, mas também fazer com que o servidor Web criasse váriasnovas portas de conexão para tal atendimento. Essas portas eram mantidas abertas, consumindopermanentemente recursos da máquina e reduzindo a possibilidade de atendimento das legítimas re-quisições dos usuários.

A segunda ferramenta utilizada foi o software livre Zabbix [14], configurado para monitoraro consumo de CPU e de memória dos servidores, além do volume de tráfego de rede e a quantidadede processos abertos nas máquinas. A Figura 2 apresenta um gráfico do Zabbix mostrando o usodos recursos do servidor Web principal durante o período do ataque. A imagem confirma o consumoexcessivo de recursos do servidor a cada ciclo de ataque até atingir um limite onde o servidor setornava inoperante, precisando ser reiniciado para restaurar o funcionamento do serviço.

Figura 2. Gráficos do Zabbix de consumo dos recursos do servidor Web.

4. Atuando para Mitigar o Ataque

Após a confirmação que se tratava de um ataque pelas das ferramentas de visualização,iniciou-se a fase de pesquisa e análise para reduzir ou anular o impacto sobre servidor. Na primeiraetapa os esforços foram concentrados em ajustar parâmetros no núcleo do sistema operacional e tam-bém em formas de conter o ingresso de pacotes maliciosos que exploravam o ZeroWindow. Logo emseguida foi feito um trabalho de análise na camada do serviço, com o objetivo de reduzir o tempo deprocessamento no atendimento as requisições para aumentar sua capacidade.

Paralelamente a esses esforços, outra equipe já cumpria um cronograma de reestruturação quecausava intensa mudança na infraestrutura lógica até a arquitetura dos serviços Web. Na subseção 4.2descreve detalhadamente as ações efetuadas.

4.1. Soluções a Nível de Kernel do Sistema Operacional e Redes

Como primeira forma de minimizar os problemas causados pelos ataques foi feita uma análisedos parâmetros do kernel que poderiam ser configurados para melhorar o desempenho da pilha TCP(utilizado pelo protocolo HTTP - Hypertext Transfer Protocol) do sistema operacional. Os parâmetrosque foram alterados encontram-se no Registro 1:�

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

Registro 1. Parâmetros do kernel que foram alterados.

Em seguida, a análise foi voltada para a camada de rede objetivando impedir ou reduzir omáximo possível a entrada de pacotes com a característica do ZeroWindow. Através de pesquisasem listas de discussão chegou-se a um conjunto de regras de firewall que efetuavam a contenção depacotes TCP que possuem o campo window com valor zero, com uma taxa pré-determinada. Essasregras foram configuradas com o utilitário iptables [7] conforme o Registro 2:�

iptables -N ZERO_WINDOW_RECENTiptables -A -m u32 --u32 "6&0xFF=0x6 && 4&0x1FFF=0 && 0>>22&0x3C@12&0xFFFF=0x0000" -j

ZERO_WINDOW_RECENTiptables -A ZERO_WINDOW_RECENT -m recent --set --name ZERO_WINDOWiptables -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 períodos de ataque a quantidade de entradas na tabela deconexões do servidor crescia muito rápido. Esse comportamento estava associado ao mecanismode funcionamento do ataque ZeroWindow que provocava um grande número de conexões pendentes.Exemplos dessas entradas podem ser vistas no Registro 3:�...tcp 0 1711 200.xxx.xxx.xxx:80 188.143.xxx.xxx:57148 ULTIMO_ACK - emtcp 0 12241 200.xxx.xxx.xxx:80 189.27.xxx.xxx:49310 ULTIMO_ACK - emtcp 0 8890 200.xxx.xxx.xxx:80 189.93.xxx.xxx:49706 ESPERA_FIN1 - emtcp 0 181 200.xxx.xxx.xxx:80 189.74.xxx.xxx:1333 ESPERA_FIN1 - emtcp 0 36301 200.xxx.xxx.xxx:80 201.14.xxx.xxx:1230 ULTIMO_ACK - emtcp 0 0 200.xxx.xxx.xxx:80 201.24.xxx.xxx:49523 TIME_WAIT - timewaittcp 0 441 200.xxx.xxx.xxx:80 157.55.xxx.xxx:45227 ESPERA_FIN1 - emtcp 0 0 200.xxx.xxx.xxx:80 163.231.xxx.xxx:20399 TIME_WAIT - timewaittcp 0 0 200.xxx.xxx.xxx:80 163.231.xxx.xxx:20438 TIME_WAIT - timewait...� �

Registro 3. Entradas na tabela de conexões do servidor.

4.2. Soluções a Nível de Servidor Web

No período do ataque, a máquina servidora de Portais contava com a instalação do ServidorHTTP Apache-2.2.16 - modelo tradicional sem “threads” - para servir páginas Web, além dos mó-dulos de proxy, rewrite e PHP 5 habilitados. Para cada requisição de entrada era criado um processono sistema operacional. Como os recursos de processamento e memória são reduzidos, também eranecessário limitar a quantidade de conexões permitidas.

Após avaliação do ataque no sistema de monitoramento Zabbix, notamos que os limites deconexões permaneciam constantemente sobrecarregados. As inúmeras tentantivas de solução menci-onadas anteriormente não foram eficazes, fucionando apenas como paliativo. Para solucinar definiti-vamente o problema, foi decidido alterar o servidor Web para outro que suportasse muitas conexõesconcorrentes.

A equipe de redes já tinha boa experiência com o uso do Lighttpd [8] no portal principal dauniversidade. Isso motivou a equipe a avaliar também o Nginx [10], usado por grandes projetos comoDropbox [4], Wordpress [13], Facebook [5], Github [6] e em mais de quarenta milhões de domínio portoda a Internet. O Lighttpd e o Nginx são similares tanto em desempenho quanto em funcionalidades.Ambos se propõem a resolver o problema C10K [2], o qual consiste em atender mais de dez milconexões simultâneas. Em função da sintaxe legível e agradável, optou-se pelo uso do Nginx. Asolução Nginx implementa, além disso, uma arquitetura guiada a eventos assíncronos, ao invés de“threads”, sendo, por essa característica, muito utilizado como um proxy reverso e balanceador decarga eficiente.

O servidor Web já tinha suporte às linguagens de programação PHP e Ruby. Para atendi-mento a essas demandas, os novos serviços foram divididos de acordo com a linguagem de forma quepudessem ser usados concomitantemente, ou seja, um não atrapalhando o outro.

4.2.1. Atendimento das requisições PHP

Para disponibilizar, bem como para otimizar, as requisições PHP no novo servidor, foi utili-zado o “FastCGI Process Manager” (PHP-FPM [11]) como alternativa ao FastCGI puro. Algumasde suas funcionalidade são:

• gerenciador de processos, com capacidade de iniciar e parar processos, caso necessário;• habilidade para iniciar processos com diferentes configurações de ambiente (uid/gid/chroot) e

diferentes arquivos de configuração php.ini;• registro de atividades;• reinicialização automática em caso de acidente ou travamento;• aceleração de recebimento de arquivos;• suporte para registro de lentidão de processos;• escalabilidade, podendo criar mais processos de acordo com a demanda;• e outros.

A funcionalidade de registro de lentidão de processos é extremamente útil. Pode ser definidoum tempo limite. Caso excedido tal tempo, as operações executadas são registradas, inclusive suasfunções, para fins de análise e futura correção pelos desenvolvedores. Esses problemas são difíceisde identificar e reportar sem o auxílio de um ferramenta adequada.

É indiscutível a utilidade dessa funcionalidade, por permitir conhecer possíveis pontos defalha nas aplicações, além de servir como direcionador para os pontos críticos encontrados. Comoexemplo, o Registro 4 mostra o histórico de uma aplicação que rodou por mais de 20 segundos. Seunome foi suprimido para evitar identificação.�

[13-Mar-2012 14:55:27] [pool www] pid 31266script_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. Funções responsáveis pela lentidão do programa.

Como observado no registro, há uma demora considerável no script“monta_busca_rapida.php” na linha 229, o que, provavelmente, caracteriza uma consulta aobanco que não foi otimizada.

4.2.2. Atendimento de requisições Rails

A Equipe Web do Cercomp utiliza um gerenciador de conteúdo Web (CMS) desenvolvidoin house para gerir seus quase 400 portais Web de unidades acadêmicas e órgãos administrativos. Aprimeira versão dessa ferramenta, chamada This, foi desenvolvida em PHP. Já a atual, chamada Weby,usa Ruby como linguagem de programação e framework Rails.

A mudança de tecnologia da aplicação de portal Web já era planejada como forma de permitira padronização de código, a melhoria na lógica de programação e a utilização de novas metodologiasconsolidadas de desenvolvimento de “software” como o desenvolvimento guiado a testes e o uso decamadas de abstração para conexão com a base de dados. No entanto, essa mudança foi antecipada,frente aos ataques, como forma também de aumentar a capacidade de atendimento das requisiçõesaos serviços web.

Foi escolhido o interpretador Ruby denomindado Thin para ser integrado ao Nginx. Umcomparativo gráfico entre os melhores interpretadores Ruby é demonstrado na Figura 3.

Figura 3. Comparação entre servidores de páginas para Ruby com base no número de requi-sições por segundos. O Rótulo c req. representa o nível de concorrência, ou seja, o númerode requisições simultâneas.

As requisições dos usuários são gerenciadas pelo Nginx e direcionadas através de proxy parao Thin. Configuramos e rodamos 3 processos do Thin, cada um escutando em um porta distinta, paraaumentar a disponibilidade do serviço.

5. ConclusãoNeste 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 lentidão einterrupção dos serviços web, tendo prejudicado quase 400 Portais Web da instituição. Ferramentascomputacionais para análise de dados de rede e do consumo dos recursos dos servidores, com técnicasde visualização de informações, foram importantes para estudar e identificar a causa do problema,bem como, para verificar a eficácia das soluções adotadas pelas equipes do Cercomp.

O ataque durou ao todo quase 3 meses de forma contínua, tendo parado somente em janeirode 2012. Durante esse período, foram realizadas modificações nas configurações básicas de rede,

no sistema operacional e nas aplicações do servidor Web, as quais anularam o impacto dos ataques.No atual momento, os portais Web estão funcionando normalmente, com capacidade suficiente paraatender o acentuado crescimento de demandas nesta área.

Outra solução que acreditamos ser eficiente para ataques distribuídos como o que foi presen-ciado é ter recursos de infraestrutura, também distribuídos e que possam ser estendidos de formadinâmica, ou seja, de acordo com a necessidade. Os esforços estão sendo guiados nesse sentido eestudos de configurações de hardware e software para implementar essa solução é um trabalho futuroa ser desenvolvido.

Referências[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 – Serviço 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 – Utilitário para configurar regras de firewall no kernel do linux. http://www.

netfilter.org/, 2012. 4[8] Lighttpd – Servidor de páginas de alto desempenho. http://www.lighttpd.net, 2012.

5[9] Logstalgia – Ferramenta de visualização de tráfego Web. http://code.google.com/p/

logstalgia/, 2012. 2[10] Nginx – Servidor de páginas 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 tráfego. http://www.zabbix.com, 2012. 3