написал: Развернул bitrixlabs - действительно в свежих редакциях нет этого файла. Поискал grep -r "MainController" /www/ - ничего не найдено.
Этого файла, оказывается, нет и в старых редакциях : проверил архивы за несколько лет - ни где в архивах такого файла нет. Проверял на -5 лет назад до текущего состояния. Илья правильно указал на то, что хакеры назначают файлу дату и время соседних файлов из этой же директории (меня и смутила верная дата для файла). Поискал измененные файлы и директории с помощью find ~/public_html -type f -mtime -30 ! -mtime -1 -printf '%TY-%Tm-%Td %TT %p\n' | sort -r find ~/public_html -type d -mtime -30 ! -mtime -1 -printf '%TY-%Tm-%Td %TT %p\n' | sort -r - больше не было пока изменений
написал: Повторюсь, этого файла не должно быть в незараженной установке БУС. Значит у вас не обновляемый с 2019г сайт тоже взломан, что не удивительно. Надо обновляться, иначе так и будут ломать.
Хм, а похоже вы правы - только что проверил резервные копии за прошлые года - нет такого файла. Дата изменения директории - вчерашний день. Получается, взломы продолжаются
написал: Странно, судя по дате последних изменений, файл /bitrix/components/bitrix/main.file.input/main.php присутствует давно, а проблема возникла недавно.
Этот файл на не обновляемом сайте присутствует с 2019 года, когда выполнялось последнее обновление. Так что его наличие или отсутствие ни о чем не свидетельствует - это файл стандартного компонента. А вот если в нем были недавно изменения, возможно в него добавили код зловреда
написал: Может совпадение, но оба проблемных сайта используют студийные темы шаблоны, один Аспро:NEXT, второй: Электросила.
У меня используются абсолютно самописные шаблоны, которые делал сам еще бог знает как давно. (2 из 3х заразились) Так что дело точно не в шаблонах. По хостам - просто обмениваемся информацией - а вдруг. Если и на других хостах, значит дело не в хосте
написал: find /home/ПУТЬ К ВАШЕЙ ПАПКЕ/public_html -type f -mtime -30 ! -mtime -1 -printf '%TY-%Tm-%Td %TT %p\n' | sort -r
Еще смотрим /public_html/bitrix/js/main/core/core.js - в конце закодированное строка /public_html/bitrix/modules/main/include/prolog.php - в конце закодированная строка А еще все это и в кэш попало - чистим кэш
Я правильно понял, что дело в загрузке файла и открытие его не понятно каким образом на исполнение php скрипта. Тогда вот костыль что только админ может загружать файл.
Что будет при попытке создания файла кэша? А если в кроне?
Благодарность за выкладку изменений! Хм, у меня нет такого модуля, а на 2х из 3х сайтах в upload появились какие то лишние файлы. Значит правка только в файлах модуля vote будет не достаточна для закрытия дыры. P.s. - зачем до сегодняшних проблем было обновлять битрикс, если все работало отлично на небольших информационных сайтах P.s.P.s. Подумываю о переносе сайтjd с битрикса на что то другое (да хотя бы на WP)
Правила можно дополнить разрешеннымы адресами (аналогично для всех остальных): <Files ~ "^(site_checker)\.php$> Order Deny,Allow deny from all # Здесь указать разрешенный адрес или адрес сетки с маской Allow from XX.XXX.0.0/16 </Files>
После этого оказалась создана директория на сайте: /upload/tmp/BXTEMP-2022-06-21/11/bxu/main/8cb4fb53.......1afff015d10d791c6/ с файлами (права на все rw-rw-rw): .log 1.log default pindex101.package
файл default представлен как тиа image/jpeg и содержит что от закодированное
Интересно, что попытки обращения с одного адреса были на /bitrix/tools/html_editor_action.php (POST) и (GET) на /bitrix/tools/sale_print.php и /bitrix/tools/composite_data.php (в логах за весь день ни кто другой не обращался ни к композиту, ни к sale_print )
Полностью безопасно - много раз так делал: заходил в консоль и удалял либо весь кэш, либо кэш конкретного компонента (по названию директорий и содержимому файлов кэша видно, к чему он относится)
bin-log нужен для репликации и восстановления данных в InnoDB-движке (при сбое). Если репликация не используется, незачем хранить binlog в несколько суток. Да и вообще, незачем его такой громадный хранить.
expire_logs_days = 2 - ограничить время хранения 2мя днями (сколько не жалко) max-bin-log-size = 500M - ограничим размер в 500М (или сколько вам не жалко. Учитывайте, что InnoDB не сразу может писать данные в базу, т.к. является транзакионным движком. Но уж за пару минут-то запишет)
Еще можно попробовать добавить: binlog-cache-size = 128K max-binlog-cache-size = 100M - макс. размер кеша бинлога
Пробуйте.
Естественно, после добавления или изменения настроек, перезапустить сервер MySQL
Для своего случая (Debian 9, PHP 7.1.33, только Apache, кодировка нужного сайта CP1251, другие сайты - UTF-8 ) решил проблему так: - проверяем установленные локали на сервере: locale -a C C.UTF-8 POSIX
Да, можете. Отключаете не используемые модули, удаляете их физически с диска. Оставляете только те, которые входят в требуемую редакцию сайта (в данном случае "Старт"). Потом обращаетесь в тех.поддержку с просьбой понизить редакцию и сможете дальше обновляться уже на условиях под новой редакцией.
Так было раньше. Сейчас, перед всеми работами, на всякий случай, уточните в тех.поддержке, вдруг что поменялось, но почти уверен, что у вас все получится.