LINUX.ORG.RU

YandexBot и странные обращения к .htaccess в error.log

 , , ,


1

2

Недавно узрел в error.log апача такие сообщения:

[Fri Sep 05 21:35:59 2014] [warn] [client 5.255.253.65] (13)Permission denied: Couldn't read /home/sitecom/.htaccess, closing connection.
[Fri Nov 07 09:38:12 2014] [warn] [client 5.255.253.65] (13)Permission denied: Couldn't read /home/sitecom/.htaccess, closing connection.
[Wed Apr 29 14:46:56 2015] [warn] [client 5.255.253.15] (13)Permission denied: Couldn't read /home/sitecom/.htaccess, closing connection.
[Wed Apr 29 16:09:46 2015] [warn] [client 5.255.253.15] (13)Permission denied: Couldn't read /home/sitecom/.htaccess, closing connection.
[Fri May 01 08:10:35 2015] [warn] [client 5.255.253.15] (13)Permission denied: Couldn't read /home/sitecom/.htaccess, closing connection.
[Wed Jul 22 03:00:24 2015] [warn] [client 178.154.243.111] (13)Permission denied: Couldn't read /home/sitecom/.htaccess, closing connection.
[Sun Jan 17 07:32:17 2016] [warn] [client 141.8.142.30] (13)Permission denied: Couldn't read /home/sitecom/.htaccess, closing connection.

Whois говорит что все вышеперечисленные IP, вызывающие нижеописываемую странность, принадлежат яндексу. Странность заключается в том что при некоторых запросах яндексбота апач почему-то пытается искать .htaccess вне DocumentRoot, причём то же самое время в access.log не наблюдается ничего криминального — сервер в ответ боту отправляет статус 200 и без проблем отдаёт запрашиваемые (по вполне корректным и адекватным URL) ресурсы: html-страницы, картинки и т.п. Вот конфиг этого виртуального хоста:
<VirtualHost *:80>
        ServerName site.com
        ServerAlias www.site.com
        ServerAdmin admin@site.com
        DocumentRoot "/home/sitecom/www"
        LogLevel warn
        LogFormat "%a %l %u [%{%d/%m/%Y %H:%M:%S %z}t] \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" access
        ErrorLog "/home/sitecom/log/error.log"
        CustomLog "/home/sitecom/log/access.log" access
        AssignUserID sitecom sitecom
        php_admin_value open_basedir "/home/sitecom/.:."
        php_admin_value upload_tmp_dir "/home/sitecom/tmp"
        php_admin_value session.save_path "/home/sitecom/tmp"
        php_admin_value include_path "/home/sitecom/www/.:."
        php_admin_value display_errors "Off"
        php_admin_value error_log "/home/sitecom/log/php_error.log"
        DirectoryIndex index.htm index.html index.php index.shtm index.shtml
        <Directory />
                Options -FollowSymLinks +Includes -Indexes
                AllowOverride All
        </Directory>
        <Directory /home/sitecom/tmp>
                Order allow,deny
                Deny from all
                php_flag engine 0
                AddType "text/html" .php .cgi .pl .fcgi .fpl .phtml .shtml .php2 .php3 .php4 .php5 .asp .jsp .inc .class
                Options -FollowSymLinks -Includes -Indexes
                AllowOverride None
        </Directory>
        <Directory /home/sitecom/log>
                Order allow,deny
                Deny from all
                php_flag engine 0
                Options -FollowSymLinks -Includes -Indexes
                AllowOverride None
        </Directory>
        <Files ".*">
                Deny from all
        </Files>
        <Files ~ "\.(bak|cfg|conf|inc)$">
                Deny from all
        </Files>
        <IfModule mod_headers.c>
                Header unset Server
                RequestHeader set Host "site.com"
        </IfModule>
</VirtualHost>

Приведённые выше сообщения в error.log сыпятся лишь при запросах ресурсов сайта яндексботом. Конечно же никакого .htaccess в /home/sitecom/ нету т.к. он лежит в /home/sitecom/www/, как и положено, и запросы от любых других клиентов (в т.ч. спам-ботов и всяческих сканеров, ежедневно посещающих ресурс) такую реакцию у апача не вызывают. Вопрос заключается в том почему апач пытается искать .htaccess вне DocumentRoot, какой запрос/заголовок/etc вызывает данное поведение и как с этим бороться? В интернетах нашёл упоминания точно таких же симптомов при запросах от яндексбота, но нигде нет никакой конкретной информации о причинах этого явления.

Ответ на: комментарий от dhameoelin

.htaccess откуда открываться должен?

Если открываться = находиться и действовать, то из /home/sitecom/www/ конечно же, что он и делает для запросов от любых других клиентов отличных от яндексбота.

h578b1bde ★☆
() автор топика
Ответ на: комментарий от dhameoelin

Я тебе полный путь дал
/home/sitecom/www/.:.

И каким боком путь в php_admin_value связан с .htaccess?
http://php.net/manual/ru/ini.core.php#ini.include-path
Или ты имеешь в виду содержание файла /home/sitecom/www/.htaccess? Там лишь правила для mod_rewrite, набор директив <Files> с правилом Deny from all и задание кодировки по умолчанию.

h578b1bde ★☆
() автор топика
Последнее исправление: h578b1bde (всего исправлений: 1)

Щупает тебя на вшивость

r_asian ★☆☆
()
Ответ на: комментарий от dhameoelin

Я имею ввиду сказать cat'у открыть тот путь, который я указал.

# cat /home/sitecom/www/.:..htaccess
cat: /home/sitecom/www/.:..htaccess: No such file or directory

А что, должно было вывести что-то другое?

h578b1bde ★☆
() автор топика
Ответ на: комментарий от h578b1bde

Две точки, идущие подряд, могли быть обработаны, как управляющая последовательность, при исключении предшествующего им сочетания «точка-двоеточие». Что, собственно, и повлекло бы тогда переход на уровень выше, как в твоих логах. Вопрос, на сколько мои домыслы близки к реальности? Cat в шелле у тебя отработал корректно. За веб-сервер - не скажу.

dhameoelin ★★★★★
()
Ответ на: комментарий от dhameoelin

Две точки, идущие подряд, могли быть обработаны, как управляющая последовательность, при исключении предшествующего им сочетания «точка-двоеточие»

У меня есть сомнения что проблема в этом т.к. настройки с такими сочетаниями (описанными в документации по ссылке выше) должны влиять на поведение лишь интерпретатора PHP а не веб-сервера вообще. Если бы в логах вместо .htaccess был какой-нибудь /home/sitecom/www/.:..index.php и в коде скриптов использовались пути относительно текущего каталога вместо $_SERVER['DOCUMENT_ROOT'] — такое поведение ещё можно было бы понять. Также довольно странно что подобные записи в логе ошибок появляются лишь когда на сайт ломится яндексбот одновременно с вполне обычными запросами к каким-нибудь картинкам от него же в access.log, а от запросов других посетителей/ботов к тем же картинкам ошибок не происходит при том что какой-либо специфической реакции на запросы именно от яндексбота в коде сайта не предполагается.

h578b1bde ★☆
() автор топика
Последнее исправление: h578b1bde (всего исправлений: 1)
Ответ на: комментарий от h578b1bde

Ну, значит, моё предположение не подтвердилось.

dhameoelin ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.