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

Во первых - логи. А логи это уже постфактум.
Во вторых тело POST запроса не логируется.

Тут важнее во-первых.

глянул я модуль, я в "обсуждение" на маркетплейсе уже написал
имхо такие сигнатуры, причём прибитые хардкодом на боевом сайте выглядят очень рисковано
к примеру - 'echo' может легко в качестве подстроки в теле какого нить полезного post запроса присутствовать

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

в идеале придумать бы как анализировать тело POST запросов где нить пораньше - например на уровне nginx и блочить на уровне фаервола с занесением в блэклист - сейчас модуль сработает только с уже подключенным прологом Битрикса

На днях лечил сайтик с Аспро - такого количества бэкдоров я ещё не видел!

Причём сама лицензия на Битрикс актуальна - движек отностительно недавно обновлен, а вот на решение клиент денежек видимо зажал.

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

Паблик скриптики можно и вручную "пройти", со стороны движка вся надежда на инструмент "файлы ядра не модифицировались".
Ну и надеюсь в Аспро кроме того, что пофиксил больше ничего не дыряво.

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

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

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

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

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

грубо говоря для всех этих файлов 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% !
может быть и хуже
на сколько я помню Украинские хакеры после начала СВО сносили контент - как в БД так и в файлах