Case – Bloqueando um HTTP DDoS com ModSecurity, Ossec e Iptables

<p><a href="http://blog.alexos.com.br/wp-content/uploads/2011/04/ddos.jpg"><img class="alignright size-medium wp-image-2525" title="ddos" src="http://blog.alexos.com.br/wp-content/uploads/2011/04/ddos-300x200.jpg" height="200" alt="" width="300" /></a><br /> Recentemente tive uma experiência pra lá de interessante e estressante. Num dia que aparentava estar muito tranquilo me avisam que detectaram uma lentidão muito grande ao acessar o site de um cliente.</p> <p>Verificando algumas informações do sistema detectei cerca de 14000 conexões na porta 80 o que me deixou um pouco espantando porque era uma situação totalmente atipica</p> <blockquote><p> netstat awt | grep 80 | wc -l<br /> 14345 </p></blockquote> <p>Isto estava causando um crash no servidor de banco porque ele não estava conseguindo dar vazão a tantas tentativas ocorrendo simultaneamente. </p> <p><strong>1a ação &#8211; Parar o serviço respirar fundo e tentar isolar o problema.</strong></p> <p>Como neste mesmo servidor existiam outros sites inicialmente tive que detectar qual era o site alvo, após alguns testes encontrei o infame.</p> <p><strong>2a ação &#8211; Mover o site para outro servidor e substituir o ip.</strong></p> <p>Movi o site para outra máquina evitando que os outros sites fossem afetados, porém quando liberei a porta 80 para o mundo o inferno começou novamente. O load average do servidor conseguiu chegar a 300 em questão de minutos.</p> <p><strong>3a ação &#8211; Estudar o log e tomar as medidas cabiveis</strong></p> <p>Numa rápida olhada no log do apache detectei a assinatura do ataque</p> <blockquote><p> 111.111.111.111 &#8211; - [26/Apr/2011:17:01:00 -0300] &#8220;GET /?WWW.ATARDE.COM.BR HTTP/1.0&#8243; 400 415 &#8220;-&#8221; &#8220;User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; Creative AutoUpdate v1.40.02)&#8221; </p></blockquote> <p>O IDS da rede detectou este ataque como DOUBLE USER-AGENT attack, como ele vinha de várias origens dinamicamente, bloquear os ips era uma tarefa árdua então tive que resolver no servidor mesmo.</p> <p><img src="http://t1.gstatic.com/images?q=tbn:ANd9GcSMhp5WEXr8RWtnaAc7hz1BP90Dygf7XF8WaWSXL5bAcbYc7hpjvQ" alt="iptables" /></p> <p><strong>4a ação &#8211; Medidas emergenciais</strong></p> <p>Como o tempo para raciocinar era muito pouco realizei algumas tentativas não tão eficazes porém contornava um pouco essa situação</p> <p>Como a assinatura do ataque não mudava foi fácil criar uma regra de iptables através de expressão regular. Ela não é de minha autoria, sou péssimo nesse quesito</p> <blockquote><p> tail -f /var/log/apache2/www.hackme.com.br-access.log | grep [aA][Tt][aA][rR][dD][eE] | awk &#8216;{print &#8220;iptables -A INPUT -s &#8220;$1&#8243; -j REJECT&#8221;}&#8217; | sh &#038; </p></blockquote> <p>Usar o REJECT não é muito elegante em se tratando de regras de firewall porque ele aumenta o consumo de memória porém o DROP não estava funcionando.</p> <p>Exemplo de uma origem ( zumbi ) bloqueada:</p> <blockquote><p> REJECT all &#8212; 1-48.94.187.totvs.com.br anywhere reject-with icmp-port-unreachable </p></blockquote> <p>Com isso tive que fazer um upgrade de memória poque o iptables estava brocando tudo.</p> <p><img src="http://t2.gstatic.com/images?q=tbn:ANd9GcSN5e-Heo0rWOE-IbMXivdOxWSVixzddh7NIiAEf1mHfcHDhZ17" alt="snort" /></p> <p><strong>5a ação &#8211; Medidas emergenciais ( Snort+FWsnort )</strong></p> <p>Resolvi por o snort em conjunto com o fwsnort para bloquear os ataques, da um pouco de trabalho mas ele conseguiu pegar algumas origens, o problema é que o próprio ataque já estava exaurindo os recursos da máquina juntamente com o iptables e eu ainda jogo o snort+mysql+fwsnort. Ai lascou tudo, tive que voltar a prancheta.</p> <p><img src="https://www.feistyduck.com/images/modsecurity-logo.png" alt="modsecurity" /></p> <p><strong>6a. ação &#8211; Algumas horas depois&#8230; ModSecurity e tunning do Apache</strong></p> <p>Vocês devem estar fazendo o seguinte questionamento: &#8220;Sim. E onde entra o Ossec nisso tudo????&#8221;</p> <p>O Ossec estava bloqueando porém como a assinatura do ataque era um pouco específica ele não estava bloqueando todas as origens. Tentei criar uma personal rule mas já era 03:00 da madruga e eu não estava enxergando nem raciocinando.</p> <p>Com certeza com a criação da regra baseada na assinatura do ataque ele seria muito mais efetivo. Como isso não era possível no momento parti para a guerra fazendo um tunning do Apache e usando o Modsecurity.</p> <p>Tunning</p> <blockquote><p> vim /etc/apache2/apache2.conf </p></blockquote> <blockquote><p> ServerLimit 4000<br /> MaxClients 4000 </p></blockquote> <p>ModSecurity</p> <blockquote><p> aptitude install libapache2-mod-security2 </p></blockquote> <blockquote><p> vim /etc/apache2/conf.d/modsecurity.conf </p></blockquote> <blockquote><p> </p> <p>SecRuleEngine On</p> <p>SecDebugLog /var/log/apache2/modsec_debug.log<br /> SecDebugLogLevel 0</p> <p># Serial audit log<br /> SecAuditEngine RelevantOnly<br /> SecAuditLogRelevantStatus ^5<br /> SecAuditLogParts ABIFHZ<br /> SecAuditLogType Serial<br /> SecAuditLog /var/log/apache2/modsec_audit.log</p> <p># if there where more than 5 requests per second for this IP<br /> # set var block to 1 (expires in 5 seconds) and increase var blocks by one (expires in an hour)<br /> SecRule ip:requests &#8220;@eq 5&#8243; &#8220;phase:1,pass,nolog,setvar:ip.block=1,expirevar:ip.block=5,setvar:ip.blocks=+1,expirevar:ip.blocks=3600&#8243;</p> <p># if user was blocked more than 5 times (var blocks>5), log and return http 403<br /> SecRule ip:blocks &#8220;@ge 5&#8243; &#8220;phase:1,deny,nolog,logdata:&#8217;req/sec: %{ip.requests}, blocks: %{ip.blocks}&#8217;,status:403&#8243;</p> <p># if user is blocked (var block=1), log and return http 403<br /> SecRule ip:block &#8220;@eq 1&#8243; &#8220;phase:1,deny,nolog,logdata:&#8217;req/sec: %{ip.requests}, blocks: %{ip.blocks}&#8217;,status:403&#8243;</p> <p>SecRule REQUEST_LINE &#8220;^GET?\WWW\.ATARDE\.COM\.BR$ HTTP&#8221;\<br /> &#8220;nolog,deny,setvar:ip.ddos=+1,deprecatevar:ip.ddos=100/10&#8243;<br /> </p></blockquote> <p>A regra abaixo foi a que bloqueou os ataques. As outras foram só para encher linguiça. </p> <blockquote><p> <strong>SecRule REQUEST_LINE &#8220;^GET?\WWW\.ATARDE\.COM\.BR$ HTTP&#8221;\ &#8220;nolog,deny,setvar:ip.ddos=+1,deprecatevar:ip.ddos=100/10&#8243;</strong> </p></blockquote> <p>As referências abaixo me ajudaram muito:</p> <p>http://blog.cherouvim.com/simple-dos-protection-with-mod_security/</p> <p>http://spamcleaner.org/en/misc/flood-http-mod_security.html</p> <p>http://www.howtoforge.com/apache2_mod_security_debian_etch</p> <p>Às 04:00 da madruga as coisas se estabilizaram, o acesso ao site foi normalizado e o load não passava de 1.00. Com certeza essa não foi a forma mais elegante de bloquear este tipo de ataque, acredito que um IPS na borda ajudaria muito na resolução e prevenção, porém temos que trabalhar com as ferramentas disponíveis e usar a criatividade.</p> <div><h3>See:</h3><ul><li><a href="http://blog.alexos.com.br/?p=515&amp;lang=pt-br" class="crp_title">Hardening do Apache</a></li><li><a href="http://blog.alexos.com.br/?p=2320&amp;lang=pt-br" class="crp_title">Protegendo seu WebServer contra o Slowloris HTTP DoS</a></li><li><a href="http://blog.alexos.com.br/?p=814&amp;lang=pt-br" class="crp_title">Apache2 + PHTML + Firefox</a></li><li><a href="http://blog.alexos.com.br/?p=1480&amp;lang=pt-br" class="crp_title">Infraestrutura para Aplicações Web Seguras parte 3 – Aplicação</a></li><li><a href="http://blog.alexos.com.br/?p=2200&amp;lang=pt-br" class="crp_title">LAMP++ &#8211; Implementando um servidor LAMP seguro ( Atualizado )</a></li></ul></div>