Алексей Вдовин (Все сообщения пользователя)

врят ли за Вас кто-то будет проводить эту аналитическую работу

именно поэтому я и написал

имхо тогда смысла мало латать - в старых движках очень много дыр
а если сайт ломанули, там скорее всего бэкдоров везде и всюду понапихали

в самое начало вставьте, но я чёт сильно сомневаюсь в корректности такого совета по отношению к этим файлам

грубо говоря для всех этих файлов POST запросы будут заблокированы

если у Вас движек актуален дополнительно ничего делать не нужно

Антон Иванов, обновления движка актуальны?

это чего такое?  /bitrix/admin/on.php

похоже штатным аплоадером fileman_file_upload.php загрузили бэкдор - вопрос почему ему доступ был предоставлен, тут нужно изучать ...

в fileman_file_upload.php первая же строчка
$USER->CanDoOperation('fileman_upload_files')
т.е. при обращени юзер был авторизован

в скрипте пролог сначала подрубается, получается если сайт ранее был взломан, инъекцию могли добавить в любое место, где цепляется

require_once($_SERVER["DOCUMENT_ROOT"]."/bitrix/modules/main/include/prolog_admin_before.php");
require_once($_SERVER["DOCUMENT_ROOT"]."/bitrix/modules/fileman/prolog.php");

а это очень много куда можно прицепиться ... например, банально опрос какого нить заголовка и $USER->autorize(); если он есть

ещё вариант - утащили авторизационные данные, либо сессионные данные т.е. запрос изначально штатно авторизованный прилетел

в ХЛ блоках та же проблема

понятно, значит надо будет что-то велосипедить самому

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

если нужно реализовать дерево элементов ХЛ блока - есть решение?

какая подобная ситуация? что ничего не находит я думаю у всех так должно быть

если серъезно, то указанный код односигнатурный, т.е. ищет только одну заразу, а их может быть очень много
к тому же тут по md5 ищет, т.е. любая минимальная модификация и всё - уже не найдёт

вторая строчка просто найдёт файлы содержащие Bitrix/public_html и изменённые за последний месяц (вроде так, сильно не вникал), это вообще могут быть и не вирусы, а то наудаляете не разобравшись

и вообще я бы удалять не торопился, куда нить лучше вне document_root перекинуть для изучения

добавлю - сущности я создал ORM генератором, но связи нужно добавлять вручную

есть 2 сущности "очереди" RECEIPT_QUEUE и "календари"  RECEIPT_CALENDAR - обе ХЛ блок
связь в одну сторону - в очередях добавлено множественное свойство типа ссылка на элементы ХЛ блока

как её описать?

подробнее:

то что в доке https://dev.1c-bitrix.ru/learning/course/index.php?COURSE_ID=43&LESSON_ID=11741  вообще сюда никак не клеется


я думаю все эти связки из документации работать не будут т.к. они рассчитаны на ManyToMany двух кастомных сущностей с использованием собственной таблицы 'receipt_queue_calendar'
          'RECEIPT_CALENDAR' => (new ManyToMany(
              'RECEIPT_CALENDAR',
              ReceiptCalendarTable::class
          ))->configureTableName('receipt_queue_calendar'),

в таблице receipt_queue_calendar пусто !!! - ни одной записи, поэтому ничего и не будет работать!

на самом деле календари - это множественное свойство в ХЛ блоке (я его в админке и создавал)

система сама автоматически создала таблицу

receipt_queue_uf_receipt_calendar  с полями ID и VALUE
сейчас там как раз есть данные для связки, и они явно используются в самой админке

то есть какой то другой подход должен быть ...

я похоже сильно что-то "не догоняю" с этой таблицей для связки

когда я создал в ХЛ блоке очередей множественное свойство календарь, система сама автоматически создала таблицу
receipt_queue_uf_receipt_calendar
с полями ID и VALUE
сейчас там как раз есть данные для связки

т.е. мне в ORM надо затащить manyToMany не каких то кастомных своих сущностей, а вот эту конкретную связь 2х ХЛ блоков  очередь и календарь

сделал в верхнем - не помогло, в коллекции множественного поля возвращает пустой массив а должно быть 2 элемента

При запуске этого кода, такую ошибку получаю:

Ответ MySQL: Документация
#1215 - Невозможно добавить ограничения внешнего ключа


в итоге без этих строк (CONSTRAINT...) запустил  - прошло нормально, таблица создалась
но ManyToMany не заработало

а это чего?

почему в FK_developer речь идёт о region и наоборот в FK_region о developer ?

Поддержка по экзаменам,  проверка "Имя"

проверка "Цитирования"

такое лучше в саппорте спросить

бесплатно?
если да, то вообще супер-вариант!

вот я тут сильно сомневаюсь, что закрыты - я когда "наискосок" посмотрел "bitrix attack" (90% конечно не понял, уж больно всё на "заумном"), но понял одно - если внутри ядра не поправлено, то "достучаться" можно не только через явно указанные дыры

и первое, что нужно сделать это актуализировать движек, потом всё в гит и вылавливать дыры
в некоторых случаях (например в Вашем) наверное проще перетащить контент на свежеустановленный движек, потом гит и режим наблюдения, иначе можно задолбаться вычищать

это что-то новенькое


при файловом доступе авторизация вообще не проблема


100% !
может быть и хуже
на сколько я помню Украинские хакеры после начала СВО сносили контент - как в БД так и в файлах

Ну да - смена всех паролей это вообще первое, что нужно сделать при обнаружении взлома.
SSH, FTP и от админки тоже

Шаред хостинг в принципе не рекомендую - виртуалки имхо понадёжнее.
Раньше было много кейсов по взлому "соседей", сейчас не знаю как там дела обстоят.

* сделать бэкап текущего состояния сайта,  скопировать логи для дальнейшего изучения

* удалить сайт по умолчанию в /home/bitrix/www, если он не нужен. Проверить отсутствие установочных скриптов bitrixsetup.php и restore.php

* проверить, нет ли каких-то служб в systemctl или задач в crontab, которые вы не создавали, удалить лишнее и подозрительное

* сменить все пароли - ssh, ftp, все админские учетные записи на сайте

* воспользоваться штатными средствами Проактивная защита
 начать с поиска троянов /bitrix/admin/xscan_worker.php?lang=ru

* воспользоваться сторонними средствами ( aibolit и т.п.)

* поискать по файлам вручную (самое быстрое в консоли по ssh), довольно много сингатур публиковались в этой ветке - конкретный пост не подскажу, давненько было дело - нужно искать. Я по ним много раз находил заразу.

* посмотреть агентов  - чтобы лишних не было (если зараза в агентах, то смысла в файловой системе искать нет -  всё равно будет заново создано)

* так же в памяти не помешает глянуть (или ребутнуть аппача), бывает зараза сидит в памяти и при удалении сама себя сразу же восстанавливает

* добавить код сайта в гит (будете изменения быстро вылавливать, а так же контролировать новые файловые изменения)

* поставить какой нибудь скриптик по отлову изменений (например, при изменении сразу письмо на электронку)

так по горячим следам гораздо проще анализировать логи (например за последние сутки)

* по логам вычислить заразу и прибить

* после чистки - режим наблюдения (скрипт изменений + гит либо просто регулярно git status в ручном режиме)

* регулярное резервное копирование (желательно не сюда же - в облако или стороннее хранилище, при наличии гита можно бэкапить только БД)


как то так ...

P.S.

так же можно обратиться в саппорт Битрикса - есть случаи когда саппорт помогал найти и устранить уязвимость

пока не догадаетесь, так и будет всякая зараза на сайте

значит у Вас либо открытая уязвимость (версия движка актуальная?)
либо бэкдор, который подсунули в момент когда уязвимость ещё была не защищена

нужно проанализировать логи - найти эту дыру и залатать