Евгений Смолин (Все сообщения пользователя)

А вот человек написал простенькое расширение для PHP 8, которое отключает eval: https://geekjob.gatsbyjs.io/disable-evil-eval-in-php-8/ Подробно описано, как это сделано. Может быть поможет кому то (ссылка на git: https://github.com/frontdevops/php-evil)

Этого файла, оказывается, нет и в старых редакциях : проверил архивы за несколько лет - ни где в архивах такого файла нет. Проверял на -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 года, когда выполнялось последнее обновление. Так что его наличие или отсутствие ни о чем не свидетельствует - это файл стандартного компонента. А вот если в нем были недавно изменения, возможно в него добавили код зловреда

У меня используются абсолютно самописные шаблоны, которые делал сам еще бог знает как давно. (2 из 3х заразились) Так что дело точно не в шаблонах. По хостам - просто обмениваемся информацией - а вдруг. Если и на других хостах, значит дело не в хосте

У меня на 2х из 3х сайтах были обнаружены следы взлома. Все 3 - Timeweb

Еще смотрим
/public_html/bitrix/js/main/core/core.js - в конце закодированное строка
/public_html/bitrix/modules/main/include/prolog.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>

нет, д.б. так (у вас в начале немного мусора):

Еще немножко информации:

188.72.203.9 - - [20/Jun/2022:23:50:34 +0300] "GET /bitrix/tools/composite_data.php HTTP/1.0" 200 214 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/99.0.4844.82 Safari/537.36 Edg/99.0.1150.36"
188.72.203.9 - - [20/Jun/2022:23:50:35 +0300] "POST /bitrix/tools/html_editor_action.php HTTP/1.0" 200 383 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/99.0.4844.82 Safari/537.36 Edg/99.0.1150.36"
188.72.203.9 - - [20/Jun/2022:23:50:35 +0300] "POST /bitrix/tools/html_editor_action.php HTTP/1.0" 200 1 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/99.0.4844.82 Safari/537.36 Edg/99.0.1150.36"
188.72.203.9 - - [20/Jun/2022:23:50:36 +0300] "GET /bitrix/tools/sale_print.php HTTP/1.0" 200 30 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/99.0.4844.82 Safari/537.36 Edg/99.0.1150.36"

После этого оказалась создана директория на сайте:
/upload/tmp/BXTEMP-2022-06-21/11/bxu/main/8cb4fb53.......1afff015d10d791c6/
с файлами (права на все rw-rw-rw):
.log
1.log
default
pindex101.package

Любопытно содержимое файла .log:
a:8:{s:4:"hash";s:1:".";s:2:"id";s:1:".";s:12:"uploadStatus";s:8:"uploaded";s:13:"executeStatus";s:8:"executed";s:4:"name";N;s:4:"type";N;s:4:"size";N;s:5:"files";a:1:{s:7:"default";a:9:{s:4:"size";i:8445;s:8:"tmp_name";s:122:"/home/u/account/name-account/public_html/upload/tmp/BXTEMP-2022-06-21/11/bxu/main/8......d10d791c6/default";s:4:"type";s:10:"image/jpeg";s:4:"name";N;s:4:"code";s:7:"default";s:12:"uploadStatus";s:8:"uploaded";s:3:"url";s:133:"https : //мойсайт-ру/bitrix/tools/html_editor_action.php?bxu_info[CID]=1&bxu_info[mode]=vie... КБ";}}}

файл default представлен как тиа image/jpeg и содержит что от закодированное

Интересно, что попытки обращения с одного адреса были на /bitrix/tools/html_editor_action.php (POST)  и (GET) на  /bitrix/tools/sale_print.php и  /bitrix/tools/composite_data.php (в логах за весь день ни кто другой не обращался ни к композиту, ни к sale_print )

Полностью безопасно - много раз так делал: заходил в консоль и удалял либо весь кэш, либо кэш конкретного компонента (по названию директорий и содержимому файлов кэша видно, к чему он относится)

Может быть браузер закешировал результат? Попробуйте проверить работу в анонимном режиме браузера (Ctrl+Shift+N)

As for escaping the "#", try \%23 with an [NE,L] flag on the rule.

Может рестартануть apache2/nginx нужно после изменений?

VisualStudioCode + плагины, SublimeText без оплаты + плагины, evolution версия PHPStorm - все бесплатно

Может проще на utf-8 перейти? Это не так сложно, а решает массу проблем сразу. К тому же что там дальше будет с cp-1251 одному богу известно.

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

ага, нет cp1251

- запускаем  dpkg-reconfigure locales
 выбираем из списка:
ru_RU.CP1251 CP1251
ru_RU.UTF-8 UTF-8

на следующей странице по умолчанию выбираем ru_RU.UTF-8 UTF-8 (UTF-8 сайтов просто физически больше, да и дебиан настроен на UTF-8 в консоле)

дальше система все ставит и настраивает сама.

- в /bitrix/php_interface/dbconn.php добавляем:

setlocale(LC_ALL, 'ru_RU.CP1251');
setlocale(LC_NUMERIC,'C');

- перезапускаем веб-сервер (в моем случае только Apache): /etc/init.d/apache2 restart
(или service apache2 restart)

Проверяем: Тестирование системы -> Полное тестирование системы

Ошибка ушла!
При этом в системе все нормально работает и с UTF-8 сайтами в других каталогах

 

Честно, я не знаю как просто и быстро определить тип лицензии, кроме плясок с бубном

Хм, ну тогда читаем список модулей и на основе анализа определяем тип лицензии.
Список модулей, в зависимости от версии: https://www.1c-bitrix.ru/products/cms/license.php  

\bitrix\modules\main\classes\general\version.php определяет константу SM_VERSION с текущей версией системы и дату SM_VERSION_DATE

Да, можете. Отключаете не используемые модули, удаляете их физически с диска. Оставляете только те, которые входят в требуемую редакцию сайта (в данном случае "Старт"). Потом обращаетесь в тех.поддержку с просьбой понизить редакцию и сможете дальше обновляться уже на условиях под новой редакцией.

Так было раньше. Сейчас, перед всеми работами, на всякий случай, уточните в тех.поддержке, вдруг что поменялось, но почти уверен, что у вас все получится.

Посмотрите вот это : https://dev.1c-bitrix.ru/support/forum/forum6/topic29679/   - может поможет?