Apache 2.2 / CentOS: Negando Bad Bots

3

Estou com todos os tipos de problemas tentando restringir bots ruins no meu servidor Apache 2.2, e espero que alguém possa ajudar.

Eu bati minha cabeça na parede por dias tentando fazer com que isso funcionasse, e usei vários métodos diferentes, mas nenhum parece funcionar corretamente.

Eu tenho vários sites em uma máquina, e eu poderia, é claro, negar bots ruins em arquivos .htaccess individuais para cada site - mas isso é difícil de manter. Então, quero colocar as restrições em httpd.conf .

O primeiro método que eu estava usando (que eu achei que estava funcionando) era usar uma seção <Location "/"> , por exemplo

<Location "/"> 
SetEnvIfNoCase User-Agent "lwp-trivial" bad_bot 
SetEnvIfNoCase User-Agent "libwww" bad_bot 
SetEnvIfNoCase User-Agent "Wget" bad_bot 
Deny from env=bad_bot 
</Location>

No entanto, descobri que, embora isso tenha bloqueado os bots, houve um problema porque permitiu que arquivos ocultos, como .htaccess e .htpasswd , fossem exibidos, mesmo que haja código em httpd.conf para proibir isso. Eu brinquei com a ordem do <Files ... block (que bloqueia o acesso ao arquivo) e o <Location ... block, mas não importa qual tenha precedência, ele ainda permite que arquivos ocultos sejam exibidos. Se eu tirar o bloco <Location ... , o servidor impedirá que os arquivos ocultos sejam exibidos, como deveria.

Eu também tentei reescrever em httpd.conf , mas isso também não parece funcionar (o bloco está no pé dos arquivos, mas eu tentei acima da seção de hosts virtuais também), por exemplo.

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} AhrefsBot [NC,OR]
RewriteCond %{HTTP_USER_AGENT} AlphaBot [NC,OR]
RewriteCond %{HTTP_USER_AGENT} Baiduspider [NC,OR]
RewriteRule ^(.*)$ - [L,R=403] 
</IfModule>

Não recebo erros usando nenhum método, mas eles não estão fazendo o que eu quero. Este segundo método simplesmente não parece bloquear os bots.

Eu também experimentei coisas como as seguintes, também sem sucesso:

<Location "/var/www/sites/">
SetEnvIf User-Agent BLEXBot GoAway
Order allow,deny
Allow from all
Deny from env=GoAway
</Location>

... e

RewriteCond %{HTTP_USER_AGENT} "blexbot" [nocase]
RewriteRule ^.*$ – [forbidden,last]

... e aparentemente todas as outras combinações de coisas possíveis. Mas eu ainda posso bloquear apenas bots com arquivos .htaccess individuais ou com a seção <Location "/"> (que permite a revelação de arquivos ocultos).

Como pode ser visto, uma das strings do user-agent que estou testando é "Blexbot" e variações dela, e então a última coisa que eu tentei é com o modsecurity.

No entanto, não consigo que isso funcione corretamente: a seguir, alguns exemplos que testei:

SecRule REQUEST_HEADERS:User-Agent "BLEXBot" "deny,status:403,id:5000218,msg:'Badbot test for Blexbot'"
SecRule REQUEST_HEADERS:User-Agent "@pmFromFile badbots.txt" "id:350001,rev:1,severity:2,log,msg:'BAD BOT - Detected and Blocked. '"

Se eu olhar em /var/log/modsec_audit.log , posso ver que o modsecurity identifica o user-agent e fornece uma entrada de log para esse efeito, mas na verdade não impede que as páginas sejam exibidas (o que é meio que o todo ponto).

Eu noto que o modsec_audit.log tem entradas de Engine-Mode: "DETECTION_ONLY" , o que pode explicar as páginas ainda sendo exibidas, mas eu não estou familiarizado com grande parte da modsecurity, então eu não tenho certeza sobre o que é fazendo.

Se alguém puder ajudar, seria realmente apreciado! Eu só preciso de um único método para funcionar, mas eu meio que gosto da idéia de usar o modsecurity se eu puder fazer, já que parece que eu posso colocar qualquer entrada do bad-bot em um único arquivo separado.

    
por Cheddar 25.11.2017 / 00:53

1 resposta

1

Para proibir uma página, uma regra de reconfiguração deve conter [F] em vez de [R=403] .

RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} AhrefsBot [NC,OR]
RewriteCond %{HTTP_USER_AGENT} AlphaBot [NC,OR]
RewriteCond %{HTTP_USER_AGENT} Baiduspider [NC]
RewriteRule ^ - [L,F]

Você está correto em sua suposição sobre o mod_security. DETECTION_ONLY significa que não irá realmente proibir nada, apenas detecte e registre o que faria . Você vai querer olhar através de sua configuração para SecRuleEngine DetectionOnly e comentar.

O problema com a configuração que começa com <Location "/var/www/sites/"> é que /var/www/sites é um diretório no sistema de arquivos, em vez de ser um caminho na URL. <Location> refere-se a URLs e <Directory> refere-se a caminhos do sistema de arquivos.

Você pode usar:

<Directory "/var/www/sites/">

ou

<Location "/">

Não consigo ver como o primeiro snippet poderia permitir .ht* arquivos. A única coisa que faz é negar alguns bots. Eu acho que você está enganado sobre o que fez com que esses arquivos estivessem acessíveis. Você pode mover toda a configuração de seus arquivos .ht* para a configuração do Apache para evitar esse problema se não conseguir descobrir os problemas de acesso.

A finalidade dos arquivos .htaccess é permitir que os usuários que não têm permissão para alterar a configuração global do Apache tenham uma medida limitada de controle sobre seus próprios diretórios. Se você tiver permissão para editar a configuração global do Apache, não há necessidade de .htaccess arquivos.

    
por 30.11.2017 / 12:59