Не удается записать файл восстановления php

Обновлено: 21.11.2024

Используется после изменения функции обработчика ошибок с помощью set_error_handler() для возврата к предыдущему обработчику ошибок (который может быть встроенной или определяемой пользователем функцией).

Параметры

Эта функция не имеет параметров.

Возвращаемые значения

Эта функция всегда возвращает значение true .

Примеры

Решите, вызвала ли unserialize() ошибку, затем восстановите исходный обработчик ошибок.

функция unserialize_handler ( $errno , $errstr )
echo "Недопустимое сериализованное значение.\n" ;
>

$serialized = 'foo' ;
set_error_handler ('unserialize_handler');
$original = unserialize ( $serialized );
restore_error_handler ();
?>

Приведенный выше пример выведет:

См. также

error_reporting() – определяет, какие ошибки PHP сообщаются
set_error_handler() — устанавливает определяемую пользователем функцию обработчика ошибок.
restore_exception_handler() — восстанавливает ранее определенную функцию обработчика исключений.
trigger_error() — генерирует сообщение об ошибке/предупреждении/уведомлении на уровне пользователя

Примечания, внесенные пользователями 4 примечания

Изольда немного неправа. Обработчики ошибок складываются с помощью set_error_handler() и извлекаются с помощью restore_error_handler(). Вот пример:

mysql_connect ("несуществующий"); // Генерировать ошибку. Фактический обработчик ошибок установлен по умолчанию

функция foo1 () Ошибка foo1
" ;>
функция foo2 () Ошибка foo2
" ;>
функция foo3 () Ошибка foo3
" ;>

set_error_handler ("foo1"); //текущий обработчик ошибок: foo1
set_error_handler("foo2"); // текущий обработчик ошибок: foo2
set_error_handler ("foo3" ); //текущий обработчик ошибок: foo3

mysql_connect ("несуществующий");
restore_error_handler (); //теперь текущий обработчик ошибок: foo2
mysql_connect ("inexistent");
restore_error_handler (); //теперь текущий обработчик ошибок: foo1
mysql_connect ("inexistent");
restore_error_handler (); //теперь текущий обработчик ошибок: обработчик по умолчанию
mysql_connect ("inexistent");
restore_error_handler (); //теперь текущий обработчик ошибок: обработчик по умолчанию (стек больше не может выталкивать)
?>

Вызов restore_error_handler из обработчика ошибок может привести к неожиданному поведению:

set_error_handler ('handleError1');
trigger_error ('1-stack:h1');

set_error_handler ('handleError2');
trigger_error ('2-stack:h1,h2');

trigger_error ('6-stack:h1,h2');
trigger_error ('7-stack:h1,h2');

функция handleError1 ($code, $message, $file = '', $line = 0, $context = array())
echo __METHOD__. ' ' . $ сообщение . PHP_EOL ;
>

функция handleError2 ($code, $message, $file = '', $line = 0, $context = array())
trigger_error ('3-DEFAULT'); // Это будет использовать обработчик ошибок php по умолчанию

эхо __METHOD__ . ' ' . $ сообщение . PHP_EOL ;

set_error_handler ('handleError3');
trigger_error ('4-stack:h1,h2,h3');

restore_error_handler (); // Это восстановит handleError1 вместо обработчика ошибок по умолчанию
trigger_error ( '5-DEFAULT' );
>

функция handleError3 ($code, $message, $file = '', $line = 0, $context = array())
echo __METHOD__. ' ' . $ сообщение . PHP_EOL ;
>

?>

Приведенный выше код выведет:

handleError1 1-stack:h1
handleError2 2-stack:h1,h2
handleError3 4-stack:h1,h2,h3
handleError1 5-DEFAULT
handleError1 6- стек:h1,h2
handleError1 7-стек:h1,h2

Можно использовать следующий обходной путь:

set_error_handler ('handleError1');
trigger_error ('1-stack:h1');

set_error_handler ('handleError2');
trigger_error ('2-stack:h1,h2');

trigger_error ('6-stack:h1,h2');
trigger_error ('7-stack:h1,h2');

функция handleError1 ($code, $message, $file = '', $line = 0, $context = array())
echo __METHOD__. ' ' . $ сообщение . PHP_EOL ;
>

функция handleError2 ($code, $message, $file = '', $line = 0, $context = [])
restore_error_handler (); // Это восстановит предыдущий обработчик ошибок
set_error_handler ('count', 0); // Установить фиктивный метод для обработки ошибок, он никогда не будет вызываться, потому что $error_type = 0
try
trigger_error ( '3-DEFAULT' );

эхо __METHOD__ . ' ' . $ сообщение . PHP_EOL ;

set_error_handler ('handleError3');
trigger_error ('4-stack:h1,h2,h3');

restore_error_handler ();
trigger_error ('5-DEFAULT');
>
наконец
restore_error_handler (); // Восстановить предыдущий обработчик ошибок
set_error_handler ('handleError2'); // Снова устанавливаем текущий обработчик ошибок
>
>

функция handleError3 ($code, $message, $file = '', $line = 0, $context = [])
echo __METHOD__. ' ' . $ сообщение .PHP_EOL ;
>
?>

который выведет:

handleError1 1-стек:h1
handleError2 2-стек:h1,h2
handleError3 4-стек:h1,h2,h3
handleError2 6-стек:h1,h2
handleError3 4-stack:h1,h2,h3
handleError2 7-stack:h1,h2
handleError3 4-stack:h1,h2,h3

Как сказано в документации, restore_error_handler() возвращает *предыдущий обработчик ошибок*. даже если это то же самое. Из-за ошибки я дважды установил собственный обработчик ошибок, а позже, когда я вызывал restore_error_handler() для восстановления встроенного обработчика, казалось, ничего не происходит. это озадачило меня на некоторое время!

Локальная история помогает постоянно отслеживать все изменения, внесенные в проект, независимо от контроля версий.

В отличие от систем контроля версий, которые отслеживают только различия между фиксациями, локальная история предлагает гораздо больше. Он автоматически записывает состояние вашего проекта, когда вы редактируете код, запускаете тесты, развертываете приложения и т. д., и поддерживает версии для всех значимых изменений, внесенных как из IDE, так и извне.

Выступая в качестве вашей личной системы контроля версий, локальная история позволяет восстанавливать удаленные файлы, возвращать отдельные изменения или возвращаться к любому состоянию файла, даже если для вашего проекта еще не включен контроль версий или если внесены нежелательные изменения. был сделан после вашего последнего коммита. Он также может служить источником восстановления, если ваш компьютер неожиданно перезагрузится, прежде чем вы сможете предпринять какие-либо действия.

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

Восстановить изменения

Представьте, что вы внесли ряд изменений в файл с момента последней фиксации до того, как поняли, что удалили значимый фрагмент кода. Действие «Отменить» здесь не поможет, потому что это изменение слишком далеко, и вам придется отказаться от других изменений, если вы его используете.

С PhpStorm вы можете восстановить это изменение за пару кликов.

Щелкните правой кнопкой мыши в любом месте редактора и выберите «Местная история | Показать историю из контекстного меню.

В открывшемся диалоговом окне на левой панели отображается список всех сохраненных версий текущего файла с отметками времени. На правой панели отображается средство просмотра различий, в котором отображаются различия между каждой версией и текущим состоянием файла.

Выполните одно из следующих действий:

Чтобы вернуть весь файл или каталог к состоянию этой версии, щелкните его правой кнопкой мыши и выберите "Восстановить" в контекстном меню или щелкните на панели инструментов.

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

Восстановить удаленные файлы

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

Выберите узел, содержащий файл, который вы удалили, в окне инструмента «Проект», щелкните его правой кнопкой мыши и выберите «Локальная история | Показать историю из контекстного меню.

Слева выберите редакцию, содержащую файл, который вы хотите восстановить, щелкните этот файл правой кнопкой мыши и выберите "Отменить выбор" .

Добавить ярлыки к определенным состояниям в локальной истории

Редакции локальной истории обычно помечаются отметками времени, по которым нелегко ориентироваться. Некоторые версии автоматически помечаются метками на основе предопределенных событий: выполнение тестов, развертывание приложений, фиксация изменений и т. д. Вы всегда можете добавить новую метку, чтобы отметить текущее состояние локальной истории, например, прямо перед началом масштабного рефакторинга.

Выберите файл | Краеведение | Поместите ярлык из главного меню.

В открывшемся диалоговом окне введите любое значимое имя для метки и нажмите OK .

Поделиться местной историей

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

Выберите редакцию в диалоговом окне «Местная история» и нажмите «Создать исправление» на панели инструментов.

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

Изменить срок хранения локальной истории

По умолчанию локальная история настроена на сохранение версий за последние 5 рабочих дней (то есть дней, когда файл был изменен).

В диалоговом окне "Настройки/Настройки" ( Ctrl+Alt+S ) перейдите к разделу "Дополнительные настройки" .

В разделе IDE укажите желаемое значение периода хранения в поле Продолжительность хранения изменений в локальной истории.

Кроме того, вы можете передать параметр localHistory.daysToKeep как свойство Java, настроив параметры JVM. Например, чтобы установить срок хранения 30 дней, добавьте в файл параметров JVM следующую строку:

Если вы хотите полностью отключить локальную историю, установите период хранения равным 0 .

Расположение файлов локальной истории

Локальная история хранится в виде двоичных файлов в подкаталоге LocalHistory в системном каталоге PhpStorm:

В продолжение серии статей о том, как использовать IntelliJ IDEA в 2pro, сегодня мы хотели бы рассказать вам больше о старой доброй функции, которая может оказаться настоящим спасением: Local History.

В отличие от систем контроля версий, которые отслеживают только различия между фиксациями, локальная история предлагает гораздо больше. Он автоматически записывает версии вашего проекта, вызванные различными событиями, когда вы редактируете код, запускаете тесты, развертываете приложения и т. д.

Выступая в качестве вашей личной системы управления версиями, локальная история позволяет вам восстанавливать удаленные файлы, возвращать отдельные изменения или откат к любому состоянию файла, даже если для вашего проекта еще не включено управление версиями или если были внесены нежелательные изменения. был сделан после вашего последнего коммита. Он также может служить источником восстановления, если ваш компьютер неожиданно перезагрузится, прежде чем вы сможете предпринять какие-либо действия.

Срок хранения локальной истории по умолчанию составляет 5 дней, но его можно настроить.

Восстановить изменения

Представьте, что вы внесли массу изменений в файл с момента последней фиксации, прежде чем поняли, что удалили значимый фрагмент кода. Действие отменить здесь не поможет, потому что это изменение слишком далеко, и вам придется отказаться от других изменений, если вы его используете.

Местная история спешит на помощь! Щелкните правой кнопкой мыши в любом месте редактора и выберите Local History | Отобразите историю или нажмите Ctrl+Shift+A в Windows и Linux или ⇧⌘A в macOS, а затем введите «локальная история».

Вы увидите список всех сохраненных версий текущего файла с отметкой времени слева и средство просмотра различий справа, в котором отображаются различия между каждой версией и текущим состоянием файла.

Восстановить удаленные файлы

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

Затем выберите ревизию, содержащую файл, который вы хотите восстановить, щелкните этот файл правой кнопкой мыши и выберите "Вернуть выбранное":

Вы можете узнать больше о местной истории из нашей документации.

Местная история доступна как в IntelliJ IDEA Ultimate, так и в бесплатной версии Community Edition. Загрузите IntelliJ IDEA прямо сейчас, чтобы не потерять ни строчки кода!

Я сделал резервную копию веб-сайта с помощью Duplicator в марте 2020 года. Теперь мне нужно восстановить этот веб-сайт с помощью этой резервной копии. Но это не работает.

Новая база данных установлена на сервере. Данные доступа, помещенные в Dup, верны.

После шага 2 я получаю сообщение

Код сервера: 200
Статус: OK
Ответ:
ОШИБКА УСТАНОВКИ!
ОШИБКА ПРИ СОЗДАНИИ БАЗЫ ДАННЫХ!
Невозможно удалить таблицу из базы данных «db******-2.create_synonym_db».
Удалите все таблицы из этой базы данных и повторите попытку установки. Если в базе данных не отображаются таблицы, удалите базу данных и создайте ее заново.
СООБЩЕНИЕ ОБ ОШИБКЕ:

Я использую «Подключить и удалить все данные» («Создать новую базу данных» не предоставляется услугой хостинга). Когда я выбираю «Проверить базу данных», все выглядит правильно.

Данные доступа в wp-config отсутствуют, я получаю только «пустой» файл. Похоже, что Dup не может записать данные доступа к базе данных в wp-config.

В файле журнала Dup я получаю:

————————————
НАСТРОЙКА АРХИВА
—————————————
ИМЯ________________: «2020_03_23_*** ***_5d61f52bca741afd3999_20200323103159_archive.zip”
РАЗМЕР________________: 100,06 МБ

НАЧАТЬ ИЗВЛЕЧЕНИЕ ZIP-ФАЙЛА SHELLEXEC >>>
>>> Запуск Shell-Exec Unzip:
Команда: unzip -o -qq '/is/htdocs/wp******_QKIXQKEYR9/ www/2020_03_23_******_5d61f52bca741afd3999_20200323103159_archive.zip' -d '/is/htdocs/wp******_QKIXQKEYR9/www' 2>&1
——————————— —–
ПОСТЭКСТАКТНЫЕ ПРОВЕРКИ
—————————————
ОБНОВЛЕНИЯ РАЗРЕШЕНИЙ:
-DIRS: '755'
- ФАЙЛЫ: '644'

ШАГ 1 ЗАВЕРШЕН в 11:34:27 – ВРЕМЯ ВЫПОЛНЕНИЯ: 5,7864 сек.

****************************************************** *********************************
* ДОПОЛНИТЕЛЬНЫЙ ЖУРНАЛ УСТАНОВКИ
* ШАГ -2 START @ 11:35:25
* ВНИМАНИЕ: НЕ размещайте сообщения на публичных сайтах и форумах!!
****************************************************** **********************************
ПОЛЬЗОВАТЕЛЬСКИЕ ВВОДЫ
РЕЖИМ ПРОСМОТРА___________: «базовый»
ДЕЙСТВИЕ БД___________: «пусто»
ХОСТ БД_____________: «**ЗАТЕМНЕН**»
ИМЯ БД_____________: «**ЗАТЕМНЕН**»
ПАРОЛЬ БД_____________: «**ЗАТЕМНЕН*» *»
ПОРТ БД_____________: «**ЗАТЕМНЕН**»
НЕРАЗРЫВНЫЕ ПРОБЕЛЫ_: false
РЕЖИМ MYSQL__________: «ПО УМОЛЧАНИЮ»
ОПЦИИ РЕЖИМА MYSQL_____: «»
CHARSET_____________: «utf8»
COLLATE_____________: «utf8_general_ci»
COLLATE FB__________: false
ПРОСМОТР СОЗДАНИЯ_____: true
СОХРАНЕННАЯ ПРОЦЕДУРА____: true
******** ******************************************************* **********************

————————————
БАЗЫ ДАННЫХ-СРЕДА
—————————————
ВЕРСИЯ MYSQL: Этот сервер: 8.0.19 — Сервер сборки: 5.6.47
РАЗМЕР ФАЙЛА: dup-database__5d61f52-23103159.sql (2,92 МБ)
TIMEOUT: 5000
MAXPACK: 33554432
SQLMODE: ONLY_FULL_GROUP_BY, STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION
НОВЫЙ ФАЙЛ SQL: [/is/htdocs/wp******_QKIXQKEYR9/www/dup-installer/dup-installer-data__5d61f52-23103159.sql]
/>COLLATE FB: Off
[PHP ERR][WARN] MSG:count(): параметр должен быть массивом или объектом, который реализует Countable [CODE:2|FILE:/is/htdocs/wp*** ***_QKIXQKEYR9/www/dup-installer/ctrls/ctrl.s2.dbinstall.php|LINE:386]
[PHP ERR][NOTICE] MSG:Неопределенная переменная: err [CODE:8|FILE:/ находится/htdocs/wp******_QKIXQKEYR9/www/dup-installer/ctrls/ctrl.s2.dbinstall.php|LINE:410]

(Некоторые данные были удалены мной)

Являются ли проблемы разными версиями mySQL?

Или можно вручную вставить данные доступа в wp-config и продолжить установку с этого места?

Итак, в течение последнего месяца или около того у меня были проблемы с вредоносными файлами. Сначала все началось с того, что хост полностью заблокировал мою учетную запись из-за наличия вредоносных/опасных файлов на сайте. Бывает, конечно, что я удалил почти весь сайт и базу данных, поэтому начинаю заново с нуля. Это относительно простой сайт, 5 страниц, без комментариев, без поиска, без пользователей.
Поскольку первоначальный инцидент принял дополнительные меры, на самом сайте и хосте, пароль хоста был изменен на случайно сгенерированный, все входы в WordPress на случайно сгенерированные 20-символьные пароли, все пароли FTP и т. д.

Примерно каждые 3 дня загружается вредоносный файл, представляющий собой запутанный файл .ico, который затем обычно связывается через wp-config, wp-settings, index.php каждый раз, когда я отменяю любые изменения и удаляю вредоносные файлы ( буквально для того, чтобы они вернулись через несколько дней).

Что касается WordPress, он обновлен до версии 5.2.2, все плагины обновлены, используется только несколько плагинов, большинство из которых используется более чем 100 000 установок:
Скоро появится страница и режим обслуживания от SeedProd
Easy Facebook Likebox
Elementor
Loginizer
UpdraftPlus – резервное копирование/восстановление
WebDefender Security – только недавно установил это
Wordfence Security
Журнал аудита безопасности WP
WPForms Lite

Что касается темы, опять же из коробки, на сайте установлена только 1 тема Twenty Nineteen, и все они обновлены.

Я просмотрел Усиление WordPress, защищенную папку wp-includes, полностью отключил редактирование файлов через WordPress, просканировал все машины, которые используются для доступа к сайту (их всего 2). Сайт также настроен через CloudFlare.
С точки зрения хоста сайт размещается на стандартном общем хостинге. Поддержка относительно бесполезна, так как каждый раз они просто блокируют сайт до тех пор, пока файлы не будут удалены, а не помогают с какими-либо журналами. Максимум, что мне удалось из них выудить, так это то, что вредоносные файлы не загружались по FTP, так как их логов не было.

На данном этапе я думаю, что застрял, просто выдергивая волосы, поскольку пытался сделать все, что мог, но это бьется головой о стену. Есть советы или идеи?

Вы пытались изменить пароль для входа в учетную запись FTP (даже если не было журналов загрузки FTP)?

На самом деле, в вашем случае, если все плагины, включая ядро wordpress, обновлены, но такая проблема все еще существует, я бы посоветовал вам сменить веб-хостинг.

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

CloudFlare хорош, но не очень помогает, если кто-то уже знает IP-адрес вашего исходного сервера или имеет что-то против вашего веб-хостинга.

Я запускаю WordFence и iThemesSecurity вместе с установленным SucuriScanner, отключенным, но готовым к запуску на случай, если возникнут проблемы.

Убедитесь, что вы не настроили публикацию по электронной почте так, чтобы кто-то мог ее использовать.

Вы уверены, что сайт вообще взломали?

Если у вас включены комментарии или pingback/trackback, запустите Akismet просто для того, чтобы несколько замедлить нарушителей «исходного мусора».

Если бы я был на общем хосте и знал, что мои соседи могут быть проблематичными, я бы, вероятно, взял и переехал. Если проверка сайта/проверка работоспособности кричит о проблемах с обновлением PHP или MySQL, я бы тоже взял и перенес.

Большую часть времени я почти ни во что не вовлекаю свой хост(ы)… Я полагаюсь на них, чтобы мой сервер был подключен и просачивался, но они не получают от меня много «дополнительного» взаимодействия .

Этот ответ был изменен 2 года и 7 месяцев назад автором JNashHawkins.

У меня было что-то похожее на то, что произошло на вашем сайте: измененные файлы, обычно файлы .ico, которые WordFence подхватывал, но я все равно получал повторное заражение после очистки зараженных файлов с помощью WordFence.

Попробуйте установить и запустить Anti-Malware Security и Brute-Force Firewall. Этот плагин обнаружил все экземпляры вредоносного вируса и удалил их из моих файлов.

@websprout Ранее я дважды менял все пароли FTP, но это не дало никакого эффекта 🙁

@jnashhawkins Я отправил ссылку в вашем направлении. Я не пробовал с iThemesSecurity, но я попробую и установлю его, чтобы посмотреть, подберет ли он что-нибудь.

Из того, что я вижу, отправка сообщений по электронной почте отключена, аналогичным образом отключены комментарии и обратные ссылки / ping. Из того, что я вижу, в настоящее время он работает на php 7.1, версия сервера MySQL — 5.6.

Все подключаемые модули безопасности, которые я использовал до сих пор, помечают файлы, Worfrence помечает их как:
Тип проблемы: Подозрительный:PHP/commentencoding.6371
Описание: Подозрительные комментарии внедряется в использование функций для запутывания поведения.
Глядя на FTP, файл был загружен сегодня в 07:14, так что там определенно есть что-то, через что загружается этот файл.

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

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

Хотя у меня есть предчувствие, что пришло время посмотреть на другие хосты.

Скажи мне, братан, ты решил свою проблему? @ворнанк

@marouane91 Мне так и не удалось докопаться до сути. Я сменил хост, с тех пор не было ни одной проблемы.

Спасибо за ответ, братан. Могу я спросить, на каком хосте вы были и на какой вы мигрировали?

@marouane91 не беспокойтесь! Конечно, раньше я работал с Siteground, потом перешел на Virtono, небольшую румынскую хостинговую компанию. Проблем не было, сайты работают как часы и достаточно быстро.

Большое спасибо, братан, за ценную информацию.

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

В любом случае, это действительно полезно знать, я буду иметь это в виду.

Еще раз спасибо за помощь 🙂

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

То, как работала их служба поддержки, было интересным: первый первоначальный ответ всегда был почти мгновенным, но на любые последующие ответы требовалось время, от нескольких часов до суток. Они утверждали, что рассылались спам-письма, когда я попросил копию, они приложили электронное письмо от мая, которое было законным электронным письмом…
В конце концов дошло до того, что я подходил к ним и говорил: «Эй, файлы вернулись, можете ли вы предоставить больше журналов о том, как они вернулись », после чего, как обычно, они избегают отвечать на вопрос и снова приостанавливают работу веб-сайта…
У них не было никаких полезных журналов, кроме того, мы действительно не знаем, как файлы попали туда, это было не через FTP. Я даже установил плагин, который будет регистрировать любую активность WordPress, чтобы увидеть, не регистрирует ли он что-нибудь — ничего. Таким образом, их поддержка была абсолютно бесполезна, кроме приостановки работы веб-сайта каждый раз, что снова было бесполезно. Проблема была, но у них не было ничего, чем они могли бы помочь или предоставить, так как я являюсь конечным пользователем, доступ к журналам относительно ограничен.

Надеюсь, вы докопались до сути 🙂

Большое спасибо @vornanc

Ваши слова, безусловно, воодушевили меня, а ваш общий опыт действительно помог разобраться в этом!

В моем случае был заражен весь сервер со всеми веб-сайтами, вот что я сделал:

– Я обнаружил, что все файлы в корневой папке WordPress имеют права доступа 0755, я изменил их на 0644.
– Очистил htaccess
– Обнаружил несколько неизвестных php-файлов внутри папки загрузки и папок кеша, которые были скрыты, они были названы как-то вроде .qsdf87897.php, поэтому я их удалил
– Обнаружено несколько неизвестных пользователей у пользователей FTP и WP также удалено!
– Изменен пароль пользователя mysql.
– Заменены wp-include и wp-admin на новые (в них тоже были вредоносные файлы).
– Я установил WEBdefender, антивирус, wordfence и cerber security (они не замедляйте работу моего веб-сайта), и я просканировал с их помощью файлы моего веб-сайта, и они обнаружили некоторые файлы, которые я не смог найти вручную.

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

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

Еще раз спасибо за помощь 🙂

Этот ответ был изменен 2 года 5 месяцев назад автором kuro .

Точно такая же проблема возникает и у меня, и это сводит меня с ума. Я делал новые установки WordPress несколько раз… Я не могу понять, в чем причина. Каждые несколько дней загружается какой-нибудь файл ico, и сканирование моего хост-провайдера отключает все мои wp-config, wp-settings и index phps…

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

Таким образом, у вас должен быть уязвимый веб-сайт, с которого он отправляет окно для этого взлома, проверьте, есть ли у вас какие-либо старые плагины, файлы ядра WordPress или темы, в основном это либо темы, либо плагины. Возможно, у вас есть устаревшие веб-сайты!

Также удалите все свои ftp-аккаунты (будьте осторожны, не удаляйте папки).

Проверьте базы данных, если есть какие-то, которые вы не узнаете, и, что наиболее важно, пользователи MySQL, их может быть две для одной базы данных или несколько пользователей WordPress для сайта.

Итак, проверьте все эти вещи, мне приходилось иметь дело с такими делами раньше!

У меня была эта постоянная проблема, и я поделился ею с ИТ-командой на своем сервере. Мне не удалось его остановить, поэтому я написал процедуру для сканирования всех файлов .ico, начинающихся с точки, и ежедневного удаления их в задании cron. Я записываю удаленные файлы в файл журнала. Хакеры сбрасывают их каждый день.

В другой процедуре (cron) я также очищаю индексные файлы (используется раздел комментариев) и восстанавливаю wp-config.php и wp-settings.php в корневом каталоге. Я также запускаю плагин WordPress для мониторинга изменений файлов, чтобы поймать случайно сброшенные php-файлы, найти которые может быть сложнее.

Мой код удаления ico нельзя назвать элегантным, но он работает, пока не будет найдено лучшее решение. Он выполняет рекурсивный поиск файлов, начинающихся с расширения . и заканчивается на .ico. Вы должны проверить это в папке и подпапке и добавить к ним несколько файлов .97404570,ico. Это не удалит ваши файлы favicon.ico. Если файл журнала не существует, он будет создан и дополнен. Используя абсолютные пути, вы можете добавить файл php в задание cron. Примечание. Я также пытаюсь получить адрес IP-сервера, но он не отображается в файле журнала. Не уверен, почему.
Всего хорошего.
—————————————
//echo «starting dir»;
$dir = ‘/home/ВАША АККАУНТ/public_html’;
//echo "начальный каталог

“;
// файл журнала
$myfile = fopen("/home/ВАША АККАУНТ/public_html/ВАША ПАПКА/icolog.txt", "a+") или die("Невозможно открыть файл!");
echo fwrite($myfile,"Сегодня ” .date("Г/м/д") . "\n");
fclose($myfile);
функция findfile($location=",$fileregex=") if (!$location или !is_dir($location) или !$fileregex) //echo "false";
вернуть ложь;
>

$all = opendir($location);
в то время как ($file = readdir($all)) if (is_dir($location.'/'.$file) и $file <> ".." и $file <> ".") $subdir_matches = findfile($location.'/'.$file,$fileregex);
$matchedfiles = array_merge($matchedfiles,$subdir_matches);
отменить($файл);
>
elseif (!is_dir($location.'/'.$file)) if (preg_match($fileregex,$file)) // здесь добавляем файл в массив
array_push ($matchedfiles,$location.'/'.$file);
//echo("собираюсь удалить файл в… ");
//echo($location.’/’.$file);
// открыть файл журнала
$myfile = fopen("/home/ВАША АККАУНТ/public_html/ВАША ПАПКА/icolog.txt", "a+") или die("Невозможно открыть файл!");
echo fwrite($myfile,$_SERVER[‘REMOTE_ADDR’].”\n”);
echo fwrite($myfile,$location.’/’.$file.»\n\n»);
// это удаляет файл
unlink($location.’/’.$file);
fclose($myfile);
>
>
>
closedir($all);
сбросить($все);

вернуть $matchedfiles;
>
// здесь вызов и строка регулярного выражения для поиска файлов ico, начинающихся с точки
$ico2files = findfile($dir,'/^\..+\.ico/' );
//print_r($ico2files);
?>
—————————
Вот фрагмент очистки файлов index.php. Это просто замена файла.Вам нужно найти в вашем public_html эти зараженные файлы index.php и добавить их в эту процедуру. Сюда входят wp-config.php и wp-settings.php.
—————————

/* здесь повторно используйте тот же файл */
$fileold = '/home/ВАША АККАУНТ/public_html/FOLDERWITHGOODFILES/index-no.php';
//echo "file-no.php is ", $fileold;
chmod($fileold, 0644);
$newfile = ‘/home/ВАША АККАУНТ/public_html/INFECTEDFOLDER/.quarantine/index.php’;
if (!copy($fileold, $newfile)) echo «не удалось скопировать .quarantine $fileold…\n»;
>
chmod($newfile, 0644);
$newfile = '/home/ВАША АККАУНТ/public_html/INFECTEDFOLDER/.tmb/index.php';
if (!copy($fileold, $newfile)) echo «не удалось скопировать .tmb $fileold…\n»;
>

// продолжайте делать это и сделайте это заданием cron

Извините, нужно было использовать кнопку кода, это лучший формат

Читайте также: