web-dev-qa-db-fra.com

AH01797: Client refusé par la configuration du serveur: / USR / Share / Doc

Depuis un certain temps (plus d'un mois maintenant), je vois des lignes comme les suivantes dans les journaux 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

Les demandes semblent vraiment provenir de BaidusPider et de Googlebot (cochées à l'aide de DNS inverse comme expliqué ici ):

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

J'ai lu des questions similaires sur ce sujet comme -- ceci et ceci , mais pour ceux-ci, ces erreurs empêchent le site de fonctionner correctement. Dans mon cas à la place, les pages HTML que les robots tentent d'accéder n'existent pas, ce qui est donc le comportement attendu d'Apache. Seule la contrariété, est que Google semble lent à l'indexation de mon site, bien que les outils Google Webmaster ne montrent aucune erreur.

J'utilise la version 2.4.7 Apache avec la configuration Vhost suivante:

<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>

Mes questions sont donc:

  1. pourquoi BaidusPider et Googlebot tentent-ils à plusieurs reprises d'accéder au contenu sur mon site qui n'est pas là et non référé par des liens sur le site?
  2. comment les demandes comme GET /manual/de/mod/... être mappé sur /usr/share/doc/Apache2-doc/manual/de/mod/... tandis que, à ma compréhension, ils devraient aller à /var/www/example.com/public/manual/de/mod/...?
  3. en général: Devrais-je m'inquiéter de ces lignes comme un signe de mauvaise configuration ou y a-t-il une explication pour eux?
apache-2.4googlebot
6
matpen

Depuis quelque temps, j'ai passé sans réponse, j'ai décidé de répondre à ma propre question selon mes recherches jusqu'à présent.

  1. Malheureusement, la question de savoir pourquoi Googlebot et BaidusPider tentent d'accéder à la documentation Apache via mon serveur reste sans réponse.
  2. Les /manual/... Les URL sont mappées sur /usr/share/doc/Apache2-doc/manual/... Grâce à un alias préinstallé sur Ubuntu: Je suppose que cela en est ainsi, afin de rendre cela pratique d'accéder à la documentation. Dans mon cas, cela n'est pas nécessaire, j'ai donc décidé de supprimer l'alias en émettant a2disconf Apache2-doc suivie par service Apache2 reload.
  3. Il n'y a aucune raison de considérer les entrées de journal comme des signes de mauvaise configuration, car ils sont plutôt le comportement souhaité. Avant de retirer l'alias, l'accès à la documentation a été bloqué par la configuration VHOST, renvoyant ainsi un code d'état 403 "interdit". Après avoir retiré l'alias, le serveur renvoie correctement un code d'état 404 "non trouvé" 404.
2
matpen

En 2.2, le contrôle d'accès basé sur le nom d'hôte client, l'adresse IP et d'autres caractéristiques des demandes des clients ont été effectués à l'aide de la commande de directives, permettent, nier et satisfaire.

En 2.4, ce contrôle d'accès est effectué de la même manière que les autres contrôles d'autorisation, à l'aide du nouveau module mod_authz_host. Les anciens idioms de contrôle d'accès doivent être remplacés par les nouveaux mécanismes d'authentification, bien que la compatibilité avec les anciennes configurations, le nouveau module mod_access_compat est fourni.

On dirait que vous avez déjà défini la nouvelle directive exiger , alors supprimez simplement les directives d'accès obsolète et exécutez Sudo service Apache2 reload

2
Cees Timmerman