Есть еще варианты: - попробуйте такой же крон запустить на другом сервере, чтобы понять - это вообще не работает или не работает только у TW - попробуйте обратиться в тех.поддержку TimeWeb - возможно что то с путями или еще какие то особенности запуска крона, а у них ТП уже имеет вариант решения
А дальше у меня идет генерация sitemap. Логирование не подключаю - мне оно не нужно. Просто вижу результат работы скрипта - генерятся необходимые мне файлы.
<?
set_time_limit(0);
// Подправим данные в b_search_content, чтобы была корректной дата последней модификации
$result = setCorrectSearchDate();
//подключение модуля поиска
if(CModule::IncludeModule('search'))
{
#!/usr/local/bin/php
<?
$_SERVER["DOCUMENT_ROOT"]="/home/p/mysite/public_html";
$DOCUMENT_ROOT = $_SERVER["DOCUMENT_ROOT"];
define("NO_KEEP_STATISTIC", true);
define("NOT_CHECK_PERMISSIONS", true);
?>
<?require_once($_SERVER["DOCUMENT_ROOT"]."/bitrix/modules/main/include/prolog_before.php");?>
<?
...
// После закрывающей комбинацией ?> не должно быть новой строки! В том числе в середине страницы
?>
<?require_once($_SERVER["DOCUMENT_ROOT"]."/bitrix/modules/main/include/epilog_after.php");?>
Вот так у меня на TimeWeb на кроне работает
Защита административного раздела в модуле "Проактивная защита", Поля IP_START и IP_END в таблице sec_iprule_excl_ip
А вот человек написал простенькое расширение для PHP 8, которое отключает eval: Подробно описано, как это сделано. Может быть поможет кому то (ссылка на git: )
написал: Развернул 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 )
Очистка кэша через директории /bitrix/cache/ и /bitrix/managed_cache/
Полностью безопасно - много раз так делал: заходил в консоль и удалял либо весь кэш, либо кэш конкретного компонента (по названию директорий и содержимому файлов кэша видно, к чему он относится)
.htaccess не реагирует на изменения, убрал строку с 301 редиректом, а редирект всё равно происходит,целый день бьюсь...
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
