Bloquear IPs que tentam explorar vulnerabilidades comuns de webapp

2

Existe um aplicativo que passa pelos logs do nginx e bloqueia os IPs que fizeram solicitações de vulnerabilidades comuns de webapp?

Eu tenho um servidor web nginx que serve apenas conteúdo estático. Recebo solicitações de GET /db/websql/main.php ou GET /db/phpMyAdmin2/main.php rotineiramente. Esses são sinais claros de alguém verificando vulnerabilidades. Existe um aplicativo que pode passar pelos logs do nginx, reconhecer essas tentativas de explorar vulnerabilidades comuns e bloquear os IPs ofensivos? Minha idéia é que, mesmo que eu não esteja vulnerável a essas explorações, os mesmos IPs podem se envolver em outros tipos de ataques na mesma caixa ou em outras caixas da minha rede: SMTP, SSH, outros servidores da web com aplicativos da web. Bloqueá-los enquanto são pegos com as mãos no pote de biscoitos parece uma boa abordagem para mim.

O Fail2ban faz algo semelhante para o SSH e para tentativas de autenticação HTTP. Talvez ele possa ser usado com uma configuração que inclua uma lista de endereços conhecidos usados para vulnerabilidades. Existe tal configuração disponível?

    
por gioele 30.09.2011 / 11:02

4 respostas

2

Nos fóruns do gotroot.com :

You can use nginx with our rules by putting a reverse proxy apache with mod_security in front of nginx. Thats actually very lightweight and something we will be adding post 3.0 as an option for sites running alternative web servers like nginx, etc. As Scott said, nginx does not have any WAF module or capability, so theres no way you can do anything like modsecurity inside nginx.

People have requested the nginx team add a WAF, and I know lightspeed is working on full modsec support, but so far I havent seen anything for nginx. So if you use nginx, and you want a WAF to protect it, you will need to put a WAF in front of it.

And as I said, this works great so I highly recommend you do that. We've got a bunch of customers running all sorts of non-apache webservers with apache reverse proxies and mod_security in front of them. And as I mentioned, we will be adding this into ASL post 3.0 release as an option for non-Apache web servers.

(Gotroot.com é bem conhecido por sua lista de regras mod_security que eles fornecem.)

Outra coisa que você pode experimentar é o naxsi que é um módulo do Firewall de Aplicação Web para o Nginx, embora ainda esteja em alpha versão. Mais

    
por 30.09.2011 / 12:14
2

Sim, você pode usar o fail2ban para bloquear IPs enviando solicitações incorretas e verificando seu servidor:

  • Existe um filtro pré-criado no fail2ban chamado nginx-botsearch que já pode fazer o que você está procurando. Apenas tome cuidado para que os pedidos ruins sejam registrados pelo nginx, então o fail2ban pode encontrá-los nos registros do nginx.

  • Eu gosto do novo fail2ban v11 (mesmo que ele não seja usado para produção, ainda, como dizem os desenvolvedores. Mas já está funcionando muito bem para mim.). Ele possui um recurso chamado bantime.increment , em que o fail2ban armazena IPs proibidos em seu próprio banco de dados e pode, então, aumentar automaticamente a bantime por meio de uma fórmula para cada proibição de um IP inválido conhecido. Isso significa que você pode ter tempos de banimento iniciais muito baixos e o fail2ban cuida do resto.

  • Também é possível proibir IPs IPv6 com o fail2ban desde a v10. (Use a transação do iptables já que a proibição do UFW ainda tem problemas para banir os IPs do IPv6.)

Além disso, você pode:

  • Instale o UFW com algumas configurações padrão, como descartar pacotes inválidos.

  • Regularmente (talvez uma vez por dia) faça o download de uma lista de bloqueio com IPs ruins conhecidos e bloqueie esses IPs diretamente no iptables. Um bom ponto de partida pode ser um script como este script . (Role para baixo nessa página para obter a versão aprimorada usando ipset .)

por 13.02.2018 / 02:37
0

Como você está detectando essas solicitações ilegais ... se puder vê-las, o fail2ban poderá vê-las. É apenas um caso de adicionar regras no jail.conf para identificá-las e banir esses usuários.

Crie uma cópia do código apache-httpd no fail2ban e tenha uma reprodução com ele. Basicamente, você precisa descobrir a regex para corresponder a cada erro recebido e, então, informar ao fail2ban o que fazer sobre isso.

    
por 30.09.2011 / 12:59
0

Eu coloquei armadilhas para eles. Um ataque comum é anexar autor = 1 para ver o nome de usuário admin do WordPress. Se a minha home page detectar isso, isso proibirá esse endereço IP. Outro truque é criar um diretório que seu site não esteja usando, como / admin. Não coloque links para isso. Coloque uma regra no seu robots.txt dizendo ao google.com para não indexá-lo. Coloque uma página da Web nessa pasta que executa um programa para proibir seu endereço IP, se eles visitarem essa página. Para as páginas que você mencionou, coloque páginas web reais naquelas localizações que adicionarão seu endereço IP ao firewall banido pelo iptables.

Isso funciona no meu Raspberry Pi executando uma versão do Linux e do PHP.

Para executar o iptables a partir do php, adicione o seguinte ao / etc / sudoers

www-data ALL=(ALL) NOPASSWD: /sbin/iptables

Algumas pessoas não gostam de dar acesso a www-data para o iptables. Eles dizem que é um risco de segurança. Mas acho que está tudo bem porque acabaram de ser banidos. Aqui está o código que eu uso:

<?php
// Get the ip address of the client.
$remote_addr = $_SERVER['REMOTE_ADDR'];
// Ban them.
if (is_ip($remote_addr)) {
    ban_ip($remote_addr);
    // Save the banned IP address.
    $logfile = '/run/shm/banned.txt';
    file_put_contents($logfile,$remote_addr."\n",FILE_APPEND);
}
// Returns true if $ip is a valid ip address.
function is_ip($ip)
{
    $count = strlen($ip);
    $valid = '0123456789.:';
    for($loop=0;$loop<$count;$loop++) {
        if (strpos($valid,substr($ip,$loop,1))===false) {
            return false;
        }
    }
    return true;
}
// Bans an ip address.
function ban_ip($ip)
{
    $cmd = 'sudo /sbin/iptables -A INPUT -s ' . $ip . ' -j DROP';
    exec($cmd);
    return;
}
?>
    
por 02.02.2018 / 16:55