Обработка Error 404 в WordPress

Очень полезная вещь! Что это? Какие-то таинственные заклинания?

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

Суть проблемы ошибки 404 в WordPress.

Все ошибки 404 (нет запрошенной страницы) WordPress обрабатывает самостоятельно. Это здорово придумано, можно делать свою красивую страницу 404 – и будет счастье.

Но в интернете развелось очень много желающих сломать Ваш сайт и постоянно роботы (сетевые боты) делают проверки вида:

• domen,ru/pass.php
• domen,ru/login.php
• domen,ru/administrator.php

и прочая ахинея

Обратите на временной интервал подборщиков:

• 6:44
• 6:46
• 6:48
• 6:49
• 6:50
• 6:51

и на каждое такое обращение WP генерирует страницу 404…

Можно поискать плагин, который пишет ошибки не в базу, а в файл на сервере (пока не нашел, напишу сам). При наличии файла на сервере – можно подключить fail2ban (и скормить ему этот файл) и блочить тупых ботов по IP после трех-пяти ошибок 404.

Плюс часть “умных” утащили с Вашего сервера картинки себе на сайт методом “copypaste” – т.е. картинки на чужом сайта по-прежнему загружаются с Вашего сервера (и дополнительно его используют).

И  после того, как Вы переделали свою исходную статью и картинки к ней (часть удалили, например) – Ваш WordPress начнет генерировать ошибку 404 на каждую отсутствующую картинку! Причем по одной странице 404 на каждую картинку!

Жесть какая, да? Нам нужно оставить генерацию 404 средствами WordPress только для отсутствующих страниц.

Возвращаем управление Error 404 серверу Apache

В WopdPress принудительно сделана передача себе обработки 404. Нужно изменить файл .htaccess, что бы движок обрабатывал только отсутствующие страницы (а не файлы).

Вот собственно код для модуля  mod_rewrite.c (поделились добрые люди)

# BEGIN WordPress

<IfModule mod_rewrite.c>
RewriteEngine On 
RewriteBase / 
RewriteRule ^index\.php$ - [L] 
 
RewriteCond %{REQUEST_FILENAME} !-f 
RewriteCond %{REQUEST_URI} \.(php|s?html?|css|js|jpe?g|png|gif|ico|txt|pdf)(/?\?.*)?$ 
RewriteRule . - [R=404,L] 

RewriteCond %{REQUEST_FILENAME} !-f 
RewriteCond %{REQUEST_FILENAME} !-d 
RewriteRule . /index.php [L] 
</IfModule>

# END WordPress

Синим цветом – от WordPress, красным – в центре добавлены изменения:

• запрос файла
• проверка расширения
• действие -> 404

Этот код полностью переключит всю обработку 404 на Apache для соответствующих расширений файлов.

Обратите внимание на регулярное выражение s?html? – это означает целый набор расширений файлов:

• shtml
• shtm
• html
• htm

Знак вопрос в регулярном выражении разрешает повторение предыдущего символа 0 или 1 раз. Конструкция jpe?g работает аналогично – это или jpg или jpeg

Если Вам надо оставить обработку файлов .html на WordPress, а все остальные варианты htm отдать Apache – можно сделать так

s?htm|shtml – т.е. отдаем Apache три варианта (вертикальная черта означает “или”)

• shtm
• htm
• shtml

Можно еще добавить расширений файлов, которые любят роботы-подборщики

• yml – Yandex Market Language – для загрузки прайс-листов в Маркет
• swp – файл обмена виртуальной памяти
• bak – архивные файлы чего-либо
• xml – разметка xml
• env – настройка переменных среды Unix
• sql – дамп базы данных MySql
• dat – файл хранения необработанных данных
• new – не знаю почему, но роботы пробуют
• zip, gzip,rar – файлы архивов
• log – файлы логов
• suspected – расширение, которое присваивает антивирус хостера для зараженных файлов (index.php -> index.php.suspected)
• 7z – файл архива
• gz – файл архива
• tar – файл архива

И еще для особо продвинутых (любопытных) ботов надо запретить:

• тильду на конце расширения файла – т.е. вот такой вариант domen.ru/abcd.php~ (тильда в некоторых ОС используется как временно сохраненная версия)
• и слеш в конце – т.е. вот такой вариант тоже не должен обрабатываться 404  в WP – domen.ru/abcd.php/

Добавляем после скобки с расширениями файлов еще скобку (\/?~?) – принцип тот же (символ на конце может быть а может и не быть) – это и /? и ~?

Лишний бэкслеш нужен для экранирования обычного слеша – т.к. он является системным символом.

Исключаем robots.txt из обработки Apahce

ВАЖНО: использование txt в списке расширений отключит генерацию виртуального файла robots.txt средствами WordPress (при отсутствии физического файла robots.txt на сервере). Просто запрос domen.ru/robots.txt не дойдет до сервера PHP.

Для исключение файла /robots.txt из обработки ошибки 404 средствами Apache – его надо добавить в условие (исключить ТОЛЬКО robots.txt)

RewriteCond %{REQUEST_URI} !^/robots\.txt$

• символ ! означает отрицание
• символ ^ означает, что проверяется совпадение с начала строки
• символ \ означает, что следующий символ является просто символом, а не управляющим символом (наша точка перед txt) – в данном случае не критично (в regex точка означает одиночное совпадение с любым символом, в т.ч. и с точкой)
• символ $ означает (без доллара никуда…), что мы не только слева проверяем наличие robots.txt, но и справа. Символы txt справа – они последние в проверке. Без $ мы заодно исключим варианты для обработки Apache (а оно нам надо?)
  • robots.txt~
  • robots.txt/ 
  • и так далее

Итоговая конструкция (которая в середине файла .htaccess) будет иметь вид

RewriteCond %{REQUEST_FILENAME} !-f 
RewriteCond %{REQUEST_URI} !^/robots\.txt$
RewriteCond %{REQUEST_URI} \.(php|asp|suspected|log|xml|s?htm|shtml|css|js|yml|swp|bak|env|new|sql|dat|zip|gzip|rar|7z|tar|gz|jpe?g|svg|png|gif|ico|txt|pdf)(\/?~?)$
RewriteRule . - [R=404,L]

Решение этого вопроса на WordPress (вариант и для Nginx)

How do I skip wordpress’s 404 handling and redirect all 404 errors for static files to 404.html?

https://wordpress.stackexchange.com/questions/24587/how-do-i-skip-wordpresss-404-handling-and-redirect-all-404-errors-for-static-fi

Вносим корректировки в .htaccess 

ВАЖНО:  ручная корректировка файла .htaccess не поможет, WordPress контролирует его содержимое и периодически возвращает свои исходные настройки в блоке, выделенному тэгами 

# BEGIN WordPress

# Директивы (строки) между `BEGIN WordPress` и `END WordPress`
# созданы автоматически и подлежат изменению только через фильтры WordPress.
# Сделанные вручную изменения между этими маркерами будут перезаписаны.

# END WordPress

Используйте плагин, которые умеет его редактировать и перехватывает управление WP, например

Плагин All in One SEO Pack

Вот его раздела “Редактор файлов”

Или через использование хуков и функций WordPress

Вот в этой статье подробно написано, как это сделать

Вред от страницы 404 в WordPress или не загружаем страницу 404, если это файл

ВАЖНО: разработчики WordPress периодически что-то изменяют – обратите внимание на появление в WoprdPress 5.6 новой  инструкции

RewriteRule .* – [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]

Поэтому можно вообще сделать отдельным блоком до модуля Вордпресса

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} !^/robots\.txt$
RewriteCond %{REQUEST_URI} \.(php|asp|suspected|log|xml|s?htm|shtml|css|js|yml|swp|bak|env|new|sql|dat|zip|gzip|rar|7z|tar|gz|jpe?g|svg|png|gif|ico|txt|pdf)(\/?~?)$
RewriteRule . - [R=404]
</IfModule>
# BEGIN WordPress
# Директивы (строки) между `BEGIN WordPress` и `END WordPress`
# созданы автоматически и подлежат изменению только через фильтры WordPress.
# Сделанные вручную изменения между этими маркерами будут перезаписаны.
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Обязательно в нашем правиле RewriteRule убираем флаг L (который Last – т.е. последнее перенаправление). Иначе часть инструкций ниже от WP работать не будет.

И конструкцию <IfModule mod_rewrite.c></IfModule> тоже крайне желательно использовать – она дает серверу исполнять инструкции внутри, если уставлен mod_rewrite.c для Apache.  У 99% хостеров он установлен по умолчанию – но на всякий случай пусть будет.

Результат обработки 404 со стороны Apache

ВАЖНО: весь этот список файлов (по их расширениям) не блокируется Apache – мы просто ему возвращаем управление ошибкой 404 при отсутствии какого-либо файла с этим расширением. Если  файл есть или расширение не запрещенное (в данном случае html разрешено) – Apache пропускает url в обработку WordPress.

Раз

Два

Три

Красота же :)

Нагрузка на сервер PHP падает на 50% – теперь ему не нужно обрабатывать 404 в ответ на тупые подборы…

Оставим только медиа для APACHE

Вроде всё хорошо, и Апач быстрый – но b “мамкиных” хакеров много.

Вот такое безобразие может быть

https://site.ru/site.php71
https://site.ru/site.php72
https://site.ru/site.php73
https://site.ru/site.php74
https://site.ru/site.php75

Причем скрипт подборщика делает это 60 раз в минуту (и в user agent = python) – т.е. APACHE занят полностью и никто к Вам на сайт из живых людей не зайдет.

Имеет смысл оставить 404 ошибку через APACHE только для медиафайлов – а всё остальное пропускать в WordPress. Делать лог и баннить :)

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} !^/robots\.txt$
RewriteCond %{REQUEST_URI} \.(jpe?g|svg|png|gif|ico)(\/?~?)$
#media only
RewriteRule . - [R=404]
</IfModule>
# BEGIN WordPress
# Директивы (строки) между `BEGIN WordPress` и `END WordPress`
# созданы автоматически и подлежат изменению только через фильтры WordPress.
# Сделанные вручную изменения между этими маркерами будут перезаписаны.
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Далее php-скриптом формируем лог ошибок 404 на сервере и отдаем в блокировку fail2ban.

В результате IP такого вредителя блокируется на уровне сервера (NetFilter)  на 1 неделю – 1 месяц.

В принципе обработку 404 ошибки в логе можно оставить и в APACHE, но не удобно:

• это не ошибка вебсервера – это отсутствие URL
• все ответы сервера 200…400…500 пишутся в лог доступа, а в не лог ошибок
• если сайтов несколько – будут отдельные логи для каждого сайта

Плюс достаточно сложная логика обработки статуса 404:

• это могут быть боты поисковых систем – их не надо блокировать
• это могут быть ошибки реальных пользователей
• вообще кто угодно и что угодно может набрать в строке браузера

Проще всю логику сделать на PHP, чем на регулярных выражениях при настройке fail2ban.