Попробуйте установить плагин WordPress «wordfence». Я часто его использую, так как он не только отслеживает живой трафик, вы можете блокировать IP-адреса, он также будет отправлять вам электронные письма об отсутствующих обновлениях безопасности для плагинов (включая его самого) и всей установки WordPress.

Он также может сканировать файлы WP и сообщать вам о подозрительном содержании.

Вы также можете вручную запускать команды head и tail в Linux для файлов WordPress или grep их всех, вы хотите следить за любым base64 в файлах. Эта часть была больше для очистки, хотя wordfence также идентифицирует такие вещи

Кажется, что не существует какой-либо регистрации вызовов функций PHP, но существует способ перехватить и зарегистрировать любой HTTP-запрос POST, который получает веб-сайт, и ведение журнала включает данные POST. Таким образом, вы получаете журналы еще до вызова fopen, поэтому вы легко обнаружите скомпрометированный файл. Стратегия такова:

1. включить регистрацию данных POST
2. дождитесь появления вредоносных файлов
3. просмотрите журналы, чтобы найти скомпрометированные скрипты PHP

Теперь по каждому пункту подробно.

1) Включить ведение журнала данных POST

Прежде всего вам понадобится PHP-скрипт, который при вызове регистрирует данные HTTP POST. Написать его с нуля несложно, но еще проще использовать существующий который я немного изменил, чтобы сделать его более читабельным и безопасным:

<?php 
if ( isset($_POST) && is_array($_POST) && count($_POST) > 0 ) 
{ 
  $log_dir = dirname( __FILE__ ) . '/logs/'; 
  $log_name = "posts-" . $_SERVER['REMOTE_ADDR'] . "-" . date("Y-m-d-H") . ".log"; 
  $log_entry = gmdate('r') . "\t (local time: " . date('r') . ")\t" . $_SERVER['REQUEST_URI'] . "\n";
  foreach ($_POST as $k => $v) 
  { 
    if ( $k == "pwd" || $k == "passwd" || $k == "password" || $k == "pass" || $k == "secret" )
    {
      $v = "*******";
    }
    $log_entry .= $k." => ".$v."\n------\n"; 
  }
  $log_entry .= "\n///////////// END OF POST DATA /////////////\n\n\n";
  $fp=fopen( $log_dir . $log_name, 'a' );
  fputs($fp, $log_entry); 
  fclose($fp); 
  chmod($log_dir . $log_name, 0600);
} 
?>

Создайте два каталога в корневой папке вашего веб-сайта, например postdata/logs, сохраните сценарий как postdata/logger.php и установите владельцев и разрешения, соответствующие вашему серверу:

root@myserver:/home/user/htdocs/www.example.com# mkdir -p postdata/logs
root@myserver:/home/user/htdocs/www.example.com# vi postdata/logger.php 
root@myserver:/home/user/htdocs/www.example.com# chown -R user postdata
root@myserver:/home/user/htdocs/www.example.com# chmod -R a-rw postdata
root@myserver:/home/user/htdocs/www.example.com# chmod -R u+r postdata
root@myserver:/home/user/htdocs/www.example.com# chmod u+w postdata/logs

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

php_value auto_prepend_file /home/user/htdocs/www.example.com/postdata/logger.php

на ваш сайт .htaccess файл, но, поскольку я запускаю PHP-FPM, который игнорирует .htaccess, Вместо этого я добавляю эту конфигурацию в свой пул PHP-FPM:

echo 'php_value[auto_prepend_file] = /home/user/htdocs/www.example.com/postdata/logger.php' >> /etc/php/7.1/fpm/pool.d/user.conf

а затем перезапускаю демон PHP-FPM.

2) Подождите, пока появятся вредоносные файлы

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

$ find . -mtime -1 -iname \*.php

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

3) Поищите в журналах скомпрометированные скрипты PHP.

cd /home/user/htdocs/www.example.com/postdata/logs
less posts-10.7.33.101-2018-05-01-00.log

Если записанные данные POST выглядят странно, вероятно, это сообщение в скомпрометированный скрипт. Вы можете найти имя скрипта в первой строке файла журнала:

$ head -n 1 posts-10.7.33.101-2018-05-01-00.log
Mon, 30 Apr 2018 22:28:40 +0000 /wp-content/plugins/one-page-navigator/admin/bsf-core/irclzkpf.php

Бинго! В моем случае это был вредоносный сценарий. Я не уверен, что на веб-сайте нет других вредоносных или оригинальных, но скомпрометированных сценариев, но я просто оставляю шаг 1 на месте, а все остальное - кусок пирога.

Обратите внимание, что удаления / редактирования этого сценария недостаточно, потому что к настоящему времени злоумышленник уже использовал его для компрометации других сценариев на сайте. Однако их довольно легко найти, выполнив поиск base64_decode вызовы функций или \\x.*\\x.*\\x.*\\x.*\\x.*\\x последовательности символов. Я думаю, что даже функция сканирования WordFence может их найти, на всякий случай, если вы используете Wordpress, как я.

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

Ответ @ lucio-crusca путем регистрации данных POST очень интересен.

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

Вот команда для поиска всех исполняемых файлов в каталоге:

find /var/www/my-wordpress  -executable -type f

Вы можете переименовать эти файлы (в целях оценки) или просто удалить их.

#Rename
find /var/www/my-wordpress  -executable -type f -exec mv {} /tmp/wp/{}_back \;

#Delete
find /var/www/my-wordpress  -executable -type f -exec rm {} \;

Я предпочитаю переместить его в / tmp, потому что я удаляю файл из веб-приложения, но сохраняю его только на случай, если я удалил не тот файл или просто хочу знать, как создается файл.

Более того, очень важно установить правильные разрешения. Я один из тех, кто думает, что пользователь apache (httpd, www-data, apache ...) не должен иметь возможность ничего писать на сервере но wp-content/uploads или любой другой публичный каталог, который вы настроили. Это предотвращает изменение плагинов или ядра злоумышленником, если злоумышленник обращается к вашему серверу с пользователем apache. Я люблю использовать этот сценарий для установки разрешений Wordpress.

Разрешение www-data писать в общедоступных каталогах, например wp-content/uploads не мешайте злоумышленнику написать файл php и вызвать его извне. В этом случае, используя apache2 в качестве веб-сервера, вы можете добавить файл .htaccess в свой общедоступный каталог, чтобы отключить выполнение php. Здесь файл .htaccess которые я помещаю в wp-content / upload, чтобы избежать выполнения php в общедоступных каталогах.