написал: 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
Да, можете. Отключаете не используемые модули, удаляете их физически с диска. Оставляете только те, которые входят в требуемую редакцию сайта (в данном случае "Старт"). Потом обращаетесь в тех.поддержку с просьбой понизить редакцию и сможете дальше обновляться уже на условиях под новой редакцией.
Так было раньше. Сейчас, перед всеми работами, на всякий случай, уточните в тех.поддержке, вдруг что поменялось, но почти уверен, что у вас все получится.
В robots.txt запрещаете индексирование Disallow: /*&showall_1= и /*?showall_1=. В header ставите <link href="https:// ваш_домен.ру/ваш_адрес_страницы" rel="canonical" />, тогда пусть хоть 1000 одних и тех же страниц с разными параметрами, поисковики будут индексировать только нужные версии. Ну и совсем уж хардовый варианты - для "лишних" страниц ставьте в header <meta name="robots" content="noindex, nofollow" /> Все изменения в header придется писать самостоятельно - нет штатных механизмов.
Посмотрел со своих компьютеров - все нормально. Еще можно попробовать заархивировать сайт, скачать на свою машину, развернуть его и поиском попробовать найти, где этот телефон сидит (если уверены, что это скрипт). Конечно, если это какой то хитрый скрипт, то поиском не найдете. Но, скорее всего, это просто ошибка - разработчики оставили какой то старую/отладочную информацию.
Это не битрикс. Какой то плагин в хроме на том компьютере стоит или вирусы. Проверяйте, чистите этот особый компьютер. Попробуйте adwcleaner запустить - почистит немного с последующей перезагрузкой.
Алексей Пустоутов, не слушайте ни кого, делайте, да воздастся вам благодарными пользователями! Уверен, спустя какое то время Docker-контейнеры будут уже стандартным дистрибутивом Битркса
Только нагрузку создают, возможно, еще, парсят ваш сайт. Смотрите логи доступа access.log. Выбирайте ботов и баньте их в своем .htaccess. Например: # hacker deny from 95.30.30.13 # Hetzner - подсетка deny from 95.216.0.0/15
Или # баним бота по части user-agent RewriteCond %{HTTP_USER_AGENT} MJ12bot [NC,OR] # баним бот по рефереру (реф-спам). Обратите внимение на последнее условие [NC] - оно последнее, перед действием, поэтому не [NC,OR] RewriteCond %{HTTP_REFERER} ^http://.*darodar\.com/ [NC]
RewriteRule ^.* - [F,L]
После этого такие посетители будут видеть 403 ошибку. Только не забаньте ботов Яндекса и гугла
В реальности проблем будет куча, даже если все рекомендации Bitrix выполнялись. Например, у меня, при обновлении с 12.5 на 16 правильно не обновился двиг, в админке пропала куча функций (большое количество служебных *.js не обновилось автоматически). Лечилось копированием всех служебных директорий Битрикса из текущего дистрибутива, затем проверки, исправления БД штатными средствами. Так что нужно готовиться к проблемам. Лучше всего, обновить свой отладочный сервер, затем после всех исправлений выложить на рабочий.