Пълно ръководство за отстраняване на неизправности при невъзможност на WordPress Wordfence да създаде wordfence-waf.php

Някой спомена, че след инсталирането на Wordfence на уебсайта си, той непрекъснато получава грешки, които казват, че не може да създаде файла wordfence-waf.php в главната директория. Помолих го да ми изпрати екранна снимка; съобщението за грешка беше само един ред, казвайки, че е проблем с разрешенията за достъп до файла.

Замислих се за момент и осъзнах, че съм се сблъсквал с това и преди. Прекарах много време, опитвайки се да го разбера, почти си мислех, че доставчикът на хостинг услуги е намислил нещо. Оказа се, че е проблем с разрешенията и собствеността, но логиката на контролния панел за хостинг може да бъде наистина объркваща.

Нека първо поясня какво представлява този wordfence-waf.php.

Всъщност това е защитният файл на защитната стена на Wordfence, който трябва да бъде записан в главната директория на уебсайта, на същото ниво като wp-config.php.

Без този файл защитната стена не може да стартира; все едно сте инсталирали ключалка, но ключът не може да бъде поставен.

Вариант 1: Промяна на разрешенията с едно щракване чрез контролния панел (BT Panel/)HestiaCP/cPanel)

Ако използвате BT Panel, всъщност е най-лесно. Отидете на уебсайта си, намерете съответния сайт, щракнете върху „Настройки“ (Settings), след което отидете на „Разрешения за директории“ (Directory Permissions). Променете разрешението за главната директория на уебсайта на 755 и разрешението за всички файлове на 644. След това проверете дали работещият потребител е „www“ (www); ако не е, сменете го. Щракнете върху бутона „Поправка на разрешенията“ (Repair Permissions), изчакайте да приключи, обновете Wordfence и опитайте отново.

За HestiaCP, отидете на страницата за редактиране на уебсайта и активирайте опцията, наречена „Разрешаване на достъп за запис до уеб root“. След това изпълнете няколко SSH команди, за да обедините собственика и разрешенията за директорията на уебсайта.

chown -R admin:www-data /home/admin/web/你的域名/public_html
chmod -R 755 /home/admin/web/你的域名/public_html
find /home/admin/web/你的域名/public_html -type f -print0 | xargs -0 chmod 644

cPanel е по-интуитивен. Отворете файловия мениджър, включете „Показване на скрити файлове“ в горния десен ъгъл, щракнете с десния бутон върху директорията и променете разрешенията на 755, променете разрешенията за файлове на 644, а в разширените опции има и функция за фиксиране на собственика на файла.

Вариант 2: Ръчна промяна на разрешенията чрез SSH (общо)Linux)

Ако контролният панел не може да го обработи, използвайте SSH ръчно. След като се свържете със сървъра, първо обединете собствеността. В LNMP/LEMP среда, уеб групата за изпълнение обикновено е www-data или www.

chown -R 你的面板用户:www-data /网站根目录完全路径

След това задайте разрешенията за папките на 755, а за файловете - на 644.

find /网站根目录 -type d -print0 | xargs -0 chmod 755
find /网站根目录 -type f -print0 | xargs -0 chmod 644

След като процесът приключи, върнете се към WP backend-а и активирайте отново защитната стена; това най-вероятно би трябвало да реши проблема.

Вариант 3: Създайте ръчно wordfence-waf.php (отлично решение, когато разрешенията са заключени)

Ако не можете да промените нищо чрез SSH панела, направете го ръчно. Създайте файл с име wordfence-waf.php в главната директория и поставете следния код в него.

<?php
if (!defined('WFWAF_VERSION')) {
    define('WFWAF_VERSION', '7.11.0');
}
$wafConfig = array(
    'wafAutoPrepend' => true,
    'wafFile' => __FILE__,
    'wpContentDir' => dirname(__FILE__) . '/wp-content',
    'wpPluginsDir' => dirname(__FILE__) . '/wp-content/plugins',
    'wafLogDir' => dirname(__FILE__) . '/wp-content/wflogs',
);
require_once $wafConfig['wpPluginsDir'] . '/wordfence/lib/waf/waf.php';

Не забравяйте да замените версия 7.11.0 с текущата версия на Wordfence. Задайте разрешенията за файла на 644 и собственикът трябва да съответства на уебсайта. След това редактирайте wp-config.php и добавете следния ред в самото начало на файла.

require_once 'wordfence-waf.php';

Запазете и обновете Wordfence. Защитната стена ще го разпознае автоматично и вече няма да докладва грешки.

Вариант 4: Проверете правилата, които ограничават достъпа за запис.

Понякога проблемът не е в разрешенията, а по-скоро в конфигурационния файл. Отворете .htaccess файла и изтрийте всички правила, които ограничават достъпа за запис на файлове или предотвратяват създаването на PHP файлове. За Nginx проверете конфигурацията на сайта си за ограничения, като например „root path само за четене“ или „create_file изключен“ и ги премахнете.

Друг сценарий е, че самият виртуален хост или лек облачен хостинг ограничава генерирането на PHP файлове в главната директория. В този случай трябва да се свържете с вашия доставчик на хостинг услуги, за да премахнете ограничението или да превключите режима на защита на Wordfence. Отидете в менюто Wordfence, Всички опции, WAF и променете режима на защитния механизъм на Разширена защита, за да заобиколите създаването на root файлове.

Решение 5: Конфликти на плъгини, причиняващи блокиране

Някои плъгини за кеширане или сигурност може да блокират тази операция. Временно деактивирайте плъгини за кеширане като WP Rocket, W3 Total Cache и LiteSpeed ​​​​Cache, както и плъгини за сигурност като Sucuri и iThemes Security. След това изчистете кеша на сървъра и opcache и рестартирайте PHP услугата.

systemctl restart php8.3-fpm

Бърза последователност за отстраняване на неизправности (препоръчително е да следвате стъпките по ред)

Предлагам ви да следвате този ред, за да избегнете ненужни проблеми. Първо, обединете разрешенията и собствеността; това има най-голяма вероятност да реши проблема. Ако това не помогне, рестартирайте PHP-FPM и обновете backend-а. Ако това все още не помогне, създайте ръчно нов файл и променете wp-config. След това проверете дали конфигурацията на Nginx или Apache блокира създаването на нови PHP файлове в главната директория. Накрая, помислете за смяна на режимите на защитната стена.

Едно нещо, което трябва да ви напомня, е, че никога не трябва да задавате разрешения на 777. Разрешенията за папки трябва да са 755, а за файлове 644; това е стандартът. Задаването на разрешения на 777 ще изложи директно уебсайта ви, което ще представлява изключително висок риск за сигурността. Ако бъдете хакнати, ще бъде твърде късно да съжалявате.

Честно казано, не съм сигурен дали тези решения ще работят за вашата ситуация, но споделих капаните, с които се сблъсках, и методите, които открих. Ако получите други съобщения за грешки, направете екранна снимка и ми я изпратете, за да ги разгледам отново.

След като сте прочели дотук, ако ви е било полезно, моля, харесайте го и го споделете. Ако искате да получавате актуализации първи, можете също да ме последвате!

Благодаря ви, че прочетохте статията ми. Ще се видим следващия път.