Назад | Перейти на главную страницу

Apache 2.2 / CentOS: отказ от плохих ботов

У меня возникают всевозможные проблемы, пытаясь ограничить использование плохих ботов на моем сервере Apache 2.2, и я надеюсь, что кто-нибудь может помочь.

Я бился головой об стену в течение нескольких дней, пытаясь заставить это работать, и использовал несколько разных методов, но ни один, похоже, не работал должным образом.

У меня несколько сайтов на одной машине, и я, конечно, могу отрицать плохих ботов в отдельности. .htaccess файлы для каждого сайта - но это сложно поддерживать. Итак, я хочу ввести ограничения в httpd.conf.

Первый метод, который я использовал (который, как мне казалось, работал), заключался в использовании <Location "/"> раздел, например

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

Однако я обнаружил, что, хотя это действительно блокировало ботов, была проблема, потому что тогда он разрешал скрытые файлы, такие как .htaccess и .htpasswd быть поданным, даже если в httpd.conf чтобы запретить это. Я поигрался с порядком <Files ... блок (который блокирует доступ к файлам) и <Location ... блок, но независимо от того, какой из них имеет приоритет, он по-прежнему позволяет обслуживать скрытые файлы. Если я вытащу <Location ... block, тогда сервер предотвращает обслуживание скрытых файлов, как и должно быть.

Я также пробовал делать переписывание в httpd.conf но это тоже, похоже, не работает (блок находится в основании файлов, но я пробовал его и над разделом виртуальных хостов), например

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

Я не получаю ошибок при использовании обоих методов, но они не делают то, что я хочу. Этот второй метод просто не блокирует ботов.

Я также пробовал такие вещи, также безуспешно:

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

... и

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

... и, по-видимому, любая другая возможная комбинация вещей. Но я все еще могу блокировать ботов только с индивидуальным .htaccess файлы или с <Location "/"> раздел (который позволяет обнаруживать скрытые файлы).

Как можно видеть, одна из строк пользовательского агента, с которой я тестирую, это «Blexbot» и его варианты, поэтому последнее, что я пробовал, - это modsecurity.

Однако мне кажется, что это тоже не работает должным образом: вот пара примеров, которые я пробовал:

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. '"

Если я загляну /var/log/modsec_audit.log тогда я вижу, что modsecurity идентифицирует пользовательский агент и предоставляет запись в журнале об этом эффекте, но на самом деле это не препятствует обслуживанию страниц (что вроде как все).

Замечу, что modsec_audit.log есть записи о Engine-Mode: "DETECTION_ONLY", что может объяснить, что страницы все еще обслуживаются, но я вообще не знаком с большей частью modsecurity, поэтому я не совсем уверен в том, что он делает.

Если кто-то может помочь, я буду очень признателен! Мне просто нужен один метод для работы, но мне нравится идея использовать modsecurity, если я могу это сделать, поскольку кажется, что я могу просто поместить любые записи о плохих ботах в один отдельный файл.

Чтобы запретить страницу, правило перезаписи должно содержать [F] скорее, чем [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]

Вы правы в своем предположении о mod_security. DETECTION_ONLY означает, что на самом деле он ничего не запрещает, просто обнаруживает и регистрирует то, что бы делать. Вы захотите просмотреть свою конфигурацию на предмет SecRuleEngine DetectionOnly и прокомментируйте это.


Проблема с конфигурацией, которая начинается с <Location "/var/www/sites/"> в том, что /var/www/sites - это каталог в файловой системе, а не путь в URL-адресе. <Location> относится к URL-адресам и <Directory> относится к путям файловой системы.

Вы можете использовать:

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

или

<Location "/">

Я не понимаю, как этот первый фрагмент может позволять .ht* файлы. Единственное, что он делает, это запрещает некоторым ботам. Я думаю, вы ошибаетесь, почему эти файлы стали доступными. Вы можете переместить всю конфигурацию со своего .ht* файлы в конфигурацию Apache, чтобы избежать этой проблемы, если вы не можете выяснить проблемы с доступом.

Цель .htaccess files - это предоставить пользователям, у которых нет разрешения на изменение глобальной конфигурации Apache, ограниченный контроль над своими собственными каталогами. Если у вас есть разрешение на редактирование глобальной конфигурации Apache, нет необходимости в .htaccess файлы.