<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 – 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 – 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 – 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 – - [26/Apr/2011:17:01:00 -0300] “GET /?WWW.ATARDE.COM.BR HTTP/1.0″ 400 415 “-” “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)”
</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 – 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 ‘{print “iptables -A INPUT -s “$1″ -j REJECT”}’ | sh &
</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 — 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 – 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 – Algumas horas depois… ModSecurity e tunning do Apache</strong></p>
<p>Vocês devem estar fazendo o seguinte questionamento: “Sim. E onde entra o Ossec nisso tudo????”</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 “@eq 5″ “phase:1,pass,nolog,setvar:ip.block=1,expirevar:ip.block=5,setvar:ip.blocks=+1,expirevar:ip.blocks=3600″</p>
<p># if user was blocked more than 5 times (var blocks>5), log and return http 403<br />
SecRule ip:blocks “@ge 5″ “phase:1,deny,nolog,logdata:’req/sec: %{ip.requests}, blocks: %{ip.blocks}’,status:403″</p>
<p># if user is blocked (var block=1), log and return http 403<br />
SecRule ip:block “@eq 1″ “phase:1,deny,nolog,logdata:’req/sec: %{ip.requests}, blocks: %{ip.blocks}’,status:403″</p>
<p>SecRule REQUEST_LINE “^GET?\WWW\.ATARDE\.COM\.BR$ HTTP”\<br />
“nolog,deny,setvar:ip.ddos=+1,deprecatevar:ip.ddos=100/10″<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 “^GET?\WWW\.ATARDE\.COM\.BR$ HTTP”\ “nolog,deny,setvar:ip.ddos=+1,deprecatevar:ip.ddos=100/10″</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&lang=pt-br" class="crp_title">Hardening do Apache</a></li><li><a href="http://blog.alexos.com.br/?p=2320&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&lang=pt-br" class="crp_title">Apache2 + PHTML + Firefox</a></li><li><a href="http://blog.alexos.com.br/?p=1480&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&lang=pt-br" class="crp_title">LAMP++ – Implementando um servidor LAMP seguro ( Atualizado )</a></li></ul></div>
Case – Bloqueando um HTTP DDoS com ModSecurity, Ossec e Iptables
30 de Abril de 2011, 0:00 - sem comentários ainda | Ninguém está seguindo este artigo ainda.
Visualizado 1019 vezes
0sem comentários ainda