Я столкнулся с некоторыми проблемами вредоносного ПО на моем веб-сервере.
Я обновил стороннее программное обеспечение, такое как Wordpress, до последней версии, отключил вход в систему root и пароль моих пользователей достаточно сложный, но все же кто-то или что-то меняет index.php файлы, добавив код, который вызывает предупреждения о вредоносных программах во многих браузерах посетителей.
Поскольку я не могу понять, кто или что это делает, я думаю о просмотре одного из index.php файлы, которые периодически меняются, чтобы я мог видеть, кто к ним обращается.
Я хотел бы знать, какая программа и какой пользователь обращается к нему. Есть ли возможность это сделать? Я проверил inotify-tools, но мне кажется, что он просто говорит мне об изменениях, а не о том, кто это меняет, я прав?
У меня был довольно хороший опыт работы с пакетом auditd (найдено в кв.). Это полноценный демон ведения журнала аудита. Единственная возможная проблема здесь в том, что вам обязательно нужен root-доступ для его установки.
Некоторые основные инструкции можно найти на http://www.cyberciti.biz/tips/linux-audit-files-to-see-who-made-changes-to-a-file.html
Если это окно Windows, вы можете включить аудит в этом каталоге.
Сервер 2008 и GPO: http://social.technet.microsoft.com/Forums/en-US/winserverfiles/thread/da689e43-d51d-4005-bc48-26d3c387e859/
но не кто это меняет, я прав?
На самом деле, нет.
Скорее всего, сайт эксплуатируется удаленно через запущенные на нем скрипты php (AFAIK the ток версия Wordpress достаточно безопасна, но есть много сторонних плагинов, пронизанных уязвимостями). Если это так, то все, что вы увидите, - это uid, под которым работает ваш PHP - затем вам нужно будет согласовать его с журналами вашего веб-сервера, чтобы увидеть, откуда могла взяться атака. Но помогает ли это решить проблему? Думаю, нет. (также сверяясь с журналом wtmp).
Частичное решение может заключаться в том, чтобы все файлы не могут быть записаны с помощью uid PHP. Что обеспечивает некоторую защиту - но вы потеряете любую видимость того, как файлы изменяются.
Если бы это был я, я бы использовал подход согласования inotify / log, но я бы хотел найти уязвимость и устранить ее.