Muitos que trabalham com suporte à servidores WEB ou HTTP server sabem da capacidade e da performance do Nginx, um servidor HTTP criado por um russo que nada mais, nada menos, consegue ser até 400% mais rápido que um Apache – o nosso querido índio velho.

Isso porque ele simplesmente não tem a porrada de coisas que o Apache tem, estou me referindo aos milhares de módulos, mas os módulos são o segredo do sucesso do Apache, grande ironia não ? Já participei de alguns projetos onde tivemos que criar alguns módulos pro velho índio.

A instalação de um servidor com Nginx, a sua configuração e até mesmo o seu hardening é uma das coisas mais simples de serem executadas – eu já levei um pouco mais do que 15 minutos para colocar um Nginx para rodar e com o PHP como FASTCGI – já o apache demora um bocado a mais de tempo.

Um dos maiores descontentamentos da galera que trabalha com segurança e com o mundo Web era a falta de um Web Application Firewall para o Nginx – digo que era, pois há poucos meses foi anunciado um projeto, bem promissor, denominado Naxsi. Juro que tinha lido à respeito, mas não tinha testado.

Saiu a versão 0.41 e fiquei animado para vê-lo em funcionamento – po, ter um WAF para Nginx é coisa nova! – bem que já rolou um papo do pessoal que cuida do mod_security de criar/compatibilizar o próprio para Nginx, mas eu nunca ouvi ou li mais nada a respeito.

Falando do Naxsi, ele é bem simples de instalar e configurar, mas eu tive um pequeno probleminha: O Naxsi só foi liberado como .deb, ou seja, Debian e Ubuntu na cabeça, nada contra em, só que alguns dos meus VPS rodam com CentOS

Pensei em usar o alien, mas lembrei que ele só converte pacotes RPM para .deb e não o inverso.

Eu sou xereta e comecei a analisar o Naxsi e percebi que o pessoal que o criou fez algumas alterações no Nginx versão 1.08 (ele já está na versão 1.09) e liberou um único pacote com os dois produtos – Nginx+Naxsi. Até aí nada de mais, porém isso pode ferrar muita gente que tiver que reinstalar todo o seu parque de servidores com Nginx só para instalar este módulo – irão pensar 10 vezes antes de fazer isso.

Acredito que este problema será resolvido em breve. Vejam os resultados de testes feitos com o Nginx+Naxsi em funcionamento versus alguns tipos de ataques.

Notinha rápida: Eu sou completamente contra utilizar o yum / apt-get / aptitude e o dpkg  para instalar pacotes e produtos para o mundo Linux, isso porque eles, na sua grande maioria, trabalham com repositórios que demoram e muito para serem atualizados, tirando raríssimos casos onde você paga pelo suporte, como acontece com a RedHat e você tem acesso a pacotes mais recentes.

Eu gosto de instalar o nginx com uma pequena linha de comando:

./configure --user=nginx --group=nginx --prefix=/usr/share/nginx --sbin-path=/usr/sbin/nginx --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --http-client-body-temp-path=/var/lib/nginx/tmp/client_body --http-proxy-temp-path=/var/lib/nginx/tmp/proxy --http-fastcgi-temp-path=/var/lib/nginx/tmp/fastcgi --pid-path=/var/run/nginx.pid --lock-path=/var/lock/subsys/nginx --with-http_ssl_module --with-http_realip_module --with-http_addition_module --with-http_sub_module --with-http_dav_module --with-http_flv_module --with-http_gzip_static_module --with-http_stub_status_module --with-http_perl_module --with-mail --with-mail_ssl_module --with-openssl=/root/openssl-0.9.8o --with-pcre --with-pcre=/root/pcre-8.10 --with-zlib=/root/zlib-1.2.5 --with-http_geoip_module; make && make install

 

Para quem não sabe, todos os grandes portais brasileiros de conteúdo utilizam o Nginx+Varnish – quando eles precisam de algo em específico e que só o apache consegue fazer, o velho índio fica atrás dos dois. Varnish – Nginx – Apache.

Muito gente vai comentar “e o bloqueio de ataques, o Varnish e o Nginx seguram a onda ?”. Sim galera e muito, para vocês terem ideia, o Varnish + Nginx bem configurados podem segurar diversos tipos de ataques DDoS (HTTP Fragmentation com certeza) – não se esqueçam que são 25 – mas para aguentar a onda mesmo, quero dizer, os ataques, você precisará de bastante memória, já que o Varnish fica altamente performática quando configurado com o malloc – configure o start do Varnish com o seguinte parâmetro -smalloc,<quantidade de memória ram disponível no seu server>G.

Esqueci de mencionar – jamais, eu digo, jamais deixe o parâmetro para utilização de memória do malloc igual ou maior que a quantidade de memória ram utilizado no server – a máquina não será mais sua.

Há também algumas regras no próprio Varnish que vocês poderão adicionar para inibir alguns alguns ataques by DDoS, como demonstrado abaixo, mas cuidado, cada configuração dependerá do funcionamento da aplicação que o seu ambiente irá suportar.

sub vcl_hash {
 if (req.http.X-rate-ok != "1") {
     # uncomment next line to rate limit based on IP address
     # set req.hash += client.ip;
     # uncomment next line to rate limit based on query parameter ('key' in this case)
     # set req.hash += regsub(regsub(req.url, ".+(\?|\&)key=", ""), "\&.*" ,"");
 } else {
     ### these 2 entries are the default ones used for vcl.
     set req.hash += req.url;
     set req.hash += req.http.host;
 }
 return(hash);
}
sub vcl_fetch {
 if (req.http.X-rate-ok != "1") {
   # first pass - only cache 400s (rate limited) responses
   if (beresp.status == 400) {
     set beresp.cacheable = true;
     return(deliver);
   } else {
     # not a rate limited response, so restart using normal hash function
     set req.http.X-rate-ok = "1";
     restart;
   }
 }
 # non-rate limited fetch
 return(deliver);
}

P.S.: Já teve gente comentando “Pq que vc não tinha colocado um Varnish no seu blog ?”, simples, eu não tinha memória suficiente para suportar um Varnish do jeito que eu queria – eu não tinha 🙂

P.S.S.: Saiu o código do fonte do naxsi para download – dentro de estantes, eu irei testá-lo – quero ver o a sua compilação e por fim, o seu funcionamento.