AH01797: cliente negado pela configuração do servidor: / usr / share / doc

Question

Desde muito tempo (mais de um mês agora) vejo linhas como as seguintes nos logs do apache:

180.76.15.138 - - [24/Jun/2015:16:13:34 -0400] "GET /manual/de/mod/module-dict.html HTTP/1.1" 403 396 "-" "Mozilla/5.0 (compatible; Baiduspider/2.0; +http://www.baidu.com/search/spider.html)"
180.76.15.159 - - [24/Jun/2015:16:28:34 -0400] "GET /manual/es/mod/mod_cache_disk.html HTTP/1.1" 403 399 "-" "Mozilla/5.0 (compatible; Baiduspider/2.0; +http://www.baidu.com/search/spider.html)"
66.249.75.86 - - [24/Jun/2015:16:18:01 -0400] "GET /manual/es/programs/apachectl.html HTTP/1.1" 403 436 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
[Wed Jun 24 16:13:34.430884 2015] [access_compat:error] [pid 5059] [client 180.76.15.138:58811] AH01797: client denied by server configuration: /usr/share/doc/apache2-doc/manual/de/mod/module-dict.html
[Wed Jun 24 16:18:01.037146 2015] [access_compat:error] [pid 2791] [client 66.249.75.86:56362] AH01797: client denied by server configuration: /usr/share/doc/apache2-doc/manual/es/programs/apachectl.html
[Wed Jun 24 16:28:34.461298 2015] [access_compat:error] [pid 2791] [client 180.76.15.159:25833] AH01797: client denied by server configuration: /usr/share/doc/apache2-doc/manual/es/mod/mod_cache_disk.html

As solicitações parecem realmente vir do Baiduspider e do Googlebot (verificadas usando DNS reverso, conforme explicado aqui ):

user@server:~$ host 66.249.75.86
86.75.249.66.in-addr.arpa domain name pointer crawl-66-249-75-86.googlebot.com.
user@server:~$ host crawl-66-249-75-86.googlebot.com
crawl-66-249-75-86.googlebot.com has address 66.249.75.86

Li perguntas semelhantes sobre este tópico, como this e this , mas para Na verdade, esses erros estão impedindo que o site funcione corretamente. No meu caso, as páginas html que os bots tentam acessar não existem, e este é, portanto, o comportamento esperado do Apache. Apenas aborrecimento, é que o Google parece lento na indexação do meu site, embora as Ferramentas do Google para webmasters não mostrem nenhum erro.

Estou usando o Apache versão 2.4.7 com a seguinte configuração de vhost:

<VirtualHost *:80>
    ServerName example.com
    ServerAlias www.example.com

    DocumentRoot "/var/www/example.com/public"
    <Directory />
        Options None
        AllowOverride None
        Order Deny,Allow
        Deny from all
        Require all denied
    </Directory>
    <Directory "/var/www/example.com/public">
        Options None
        AllowOverride FileInfo Limit Options=FollowSymLinks 
        Order Allow,Deny
        Allow from all
        Require all granted
    </Directory>

    ErrorLog /var/log/apache2/example.com/error.log
    CustomLog /var/log/apache2/example.com/access.log combined
</VirtualHost>

Minhas perguntas são, portanto:

1. por que o Baiduspider e o Googlebot estão repetidamente tentando acessar o conteúdo do meu site que não está lá e não é referenciado por nenhum link do site?
2. como solicitações como GET /manual/de/mod/... são mapeadas para /usr/share/doc/apache2-doc/manual/de/mod/... , enquanto, no meu entender, elas devem ir para /var/www/example.com/public/manual/de/mod/... ?
3. em geral: devo me preocupar com essas linhas como um sinal de configuração incorreta ou há uma explicação para elas?

Answer 1

Desde que algum tempo passou sem qualquer resposta, decidi responder (parcialmente) a minha própria pergunta de acordo com a minha pesquisa até agora.

1. Infelizmente, a pergunta por que o Googlebot e o Baiduspider estão tentando acessar a documentação do Apache através do meu servidor permanece sem resposta.
2. As URLs /manual/... são mapeadas para /usr/share/doc/apache2-doc/manual/... graças a um Alias pré-instalado no Ubuntu: acho que é assim, para facilitar o acesso à documentação. No meu caso, isso não é necessário, então decidi remover o Alias emitindo a2disconf apache2-doc seguido por service apache2 reload .
3. Não há motivo para considerar as entradas de log como sinais de configuração incorreta, pois elas são o comportamento desejado. Antes de remover o Alias, o acesso à documentação foi bloqueado pela configuração vhost, retornando assim um código de status 403 "Proibido". Depois de remover o Alias, o servidor retorna corretamente um código de status 404 "Não encontrado".

Answer 2

In 2.2, access control based on client hostname, IP address, and other characteristics of client requests was done using the directives Order, Allow, Deny, and Satisfy.

In 2.4, such access control is done in the same way as other authorization checks, using the new module mod_authz_host. The old access control idioms should be replaced by the new authentication mechanisms, although for compatibility with old configurations, the new module mod_access_compat is provided.

Parece que você já definiu a nova diretiva Solicitar , portanto, basta remover as diretivas de acesso reprovadas e execute sudo service apache2 reload