Ajudei um amigo nessa última madrugada a mitigar um ataque DDoS HTTP em seus 12 WebServers que rodam com Apache, que por um acaso estavam na última release – 2.2.22 — parabéns ao pessoal por estar preocupado com a versão …

O pessoal, galera sem ter muito o que fazer na madruga, tinha escolhido o pobre coitado para cristo e não adiantou em nada mod_qos, mod_reqtimeout, mod_bandwith, mod_security, mod_antiloris, nada. O jeito foi subir 2 servidores Ubuntu com Varnish, tendo 4GB alocados  só para o produto (malloc Varnish) – cada ubuntu estava com 6GB  – e colocá-los como front-end, quer dizer, respondendo na porta 80. Os apaches passaram a responder em portas acima de 1024 – Pegamos a 8080/TCP – sem problemas porque cada servidor rodava em ips diferentes.

Como o ambiente dele é virtual, a instalação correu numa boa. Ele estava desesperado, então partimos para o velho e conhecido apt-get install varnish. Tudo instalado em menos de 2 minutos, vamos à configuração.

Colocamos em cache todos os objetos estáticos – jpeg,jpg,css,html,txt, jsp – sem muitos ajustes ou tuning de cache, time ou POST. O importante era colocar o Varnish no ar e ver com o comando varnishhist quais objetos estavam sendo cacheados . Vejam na imagem abaixo que o que tem um | é que o servidor, o varnish, está respondendo, em resumo objetos cacheados, e em # objetos não cacheados pelo varnish.

 O load dos Varnishs não passava de 0.4, já o dos servidores Apache, que sempre ficava na casa dos 2.2 e no momento do ataque estavam em 45, caiu para 0.5 – O varnish é animal.

Vejam que foi feita uma simples configuração para o Varnish, nada de controle de purge, banning ou a instalação do security.vcl, que é considerado por alguns o Varnish WAF – exagero.

Uma solução ideal para este ambiente será a substituição dos 12 apaches por 4 nginx – sim, isso mesmo, o nginx é muito superior em diversos aspectos, principalmente para otimização e performance quanto ao PHP, chegando ao ponto de necessitar, em muitos dos casos, de 1/4 dos recursos que são necessários para rodar um apache. Mas cuidado, cada caso é um caso e vc não pode tomar isso como regra absoluta e imutável.

E como front-end ele deverá colocar 2 varnish, só para matar o spofponto único de falha, respondendo na TCP/80.

Ponto importante – o Varnish é um servidor de Cache, então não achem que ele irá mitigar todo e qualquer ataque aos seus servidores WEB – ele não foi feito para isso e o security.vcl ajuda, mas não resolve, até porque, não há segurança 100%

Compartilhar:

Este post tem 8 comentários

  1. Muito bom !! ficou animal a solução!

    abs

  2. Bom dia, desculpe minha ignorancia mais o Varnish pode substituir o Squid como cache interno, ou seja permite bloqueio de palavras, sites, etc?

    Obrigado.

  3. Cain, nenhuma pergunta é estúpida e não que eu saiba. O varnish trabalha com outro tipo de cache.

  4. Cain, o Varnish está classificado como Web Cache, e o Squid como Proxy Cache;
    Este é o outro tipo de cache que o Gustavo Lima, está dizendo.

  5. Gustavo, só por curiosidade e aproveitando o assunto, já que estamos falando de cache e etc.
    Já trabalhou ou já viu algo a respeito destes appliance “aceleradores de rede” (como é chamado no mercado) ?
    Na verdade faz o papel de Proxy Cache em uma rede.

    Show de bola a solução!!
    Valeu!

  6. Não sei se é possível, mas seria legal compartilhar o procedimento utilizado. Talvez sirva pra alguém.

  7. Estou fazendo um POC com 3 steelheads da riverbed em 3 sites principais, tive uma otimização de 80% do trafego enviado para a MPLS até o momento, muito bom!.

Deixe uma resposta

Fechar Menu