Поддержка по экзаменам, проверка "Имя"
13.04.2024 05:36:41
проверка "Цитирования" |
|||
|
21.02.2024 10:46:02
такое лучше в саппорте спросить |
|||
|
13.02.2024 07:18:42
бесплатно? если да, то вообще супер-вариант! |
|||
|
13.02.2024 07:11:56
вот я тут сильно сомневаюсь, что закрыты - я когда "наискосок" посмотрел "bitrix attack" (90% конечно не понял, уж больно всё на "заумном"), но понял одно - если внутри ядра не поправлено, то "достучаться" можно не только через явно указанные дыры и первое, что нужно сделать это актуализировать движек, потом всё в гит и вылавливать дыры в некоторых случаях (например в Вашем) наверное проще перетащить контент на свежеустановленный движек, потом гит и режим наблюдения, иначе можно задолбаться вычищать |
|||
|
13.02.2024 07:05:15
это что-то новенькое
при файловом доступе авторизация вообще не проблема
100% ! может быть и хуже на сколько я помню Украинские хакеры после начала СВО сносили контент - как в БД так и в файлах |
|||||||
|
12.02.2024 18:43:14
Ну да - смена всех паролей это вообще первое, что нужно сделать при обнаружении взлома. SSH, FTP и от админки тоже Шаред хостинг в принципе не рекомендую - виртуалки имхо понадёжнее. Раньше было много кейсов по взлому "соседей", сейчас не знаю как там дела обстоят. |
|||
|
12.02.2024 12:34:45
* сделать бэкап текущего состояния сайта, скопировать логи для дальнейшего изучения * удалить сайт по умолчанию в /home/bitrix/www, если он не нужен. Проверить отсутствие установочных скриптов bitrixsetup.php и restore.php * проверить, нет ли каких-то служб в systemctl или задач в crontab, которые вы не создавали, удалить лишнее и подозрительное * сменить все пароли - ssh, ftp, все админские учетные записи на сайте * воспользоваться штатными средствами Проактивная защита начать с поиска троянов /bitrix/admin/xscan_worker.php?lang=ru * воспользоваться сторонними средствами ( aibolit и т.п.) * поискать по файлам вручную (самое быстрое в консоли по ssh), довольно много сингатур публиковались в этой ветке - конкретный пост не подскажу, давненько было дело - нужно искать. Я по ним много раз находил заразу. * посмотреть агентов - чтобы лишних не было (если зараза в агентах, то смысла в файловой системе искать нет - всё равно будет заново создано) * так же в памяти не помешает глянуть (или ребутнуть аппача), бывает зараза сидит в памяти и при удалении сама себя сразу же восстанавливает * добавить код сайта в гит (будете изменения быстро вылавливать, а так же контролировать новые файловые изменения) * поставить какой нибудь скриптик по отлову изменений (например, при изменении сразу письмо на электронку) так по горячим следам гораздо проще анализировать логи (например за последние сутки) * по логам вычислить заразу и прибить * после чистки - режим наблюдения (скрипт изменений + гит либо просто регулярно git status в ручном режиме) * регулярное резервное копирование (желательно не сюда же - в облако или стороннее хранилище, при наличии гита можно бэкапить только БД) как то так ... P.S. так же можно обратиться в саппорт Битрикса - есть случаи когда саппорт помогал найти и устранить уязвимость |
|||
|
12.02.2024 12:27:31
пока не догадаетесь, так и будет всякая зараза на сайте значит у Вас либо открытая уязвимость (версия движка актуальная?) либо бэкдор, который подсунули в момент когда уязвимость ещё была не защищена нужно проанализировать логи - найти эту дыру и залатать |
|||
|
12.02.2024 09:06:46
походил по каталогу - не моделируется |
|||
|
10.02.2024 04:37:04
Ну вот - и движек то не при делах. Хорошая новость. |
|||
|
07.02.2024 10:43:42
Ну так то для дебага совсем не обязательно VirtualBox + VScode. Я например юзаю VMWare + PHPStorm, реже Docker + PHPStorm. Вообще да - дебаг самое надёжное решение для любой возможной ситуации. |
|||
|
07.02.2024 04:22:59
на попытки забейте - это нормальная история, ищите "не попытки", всё что 404 смысла нет смотреть (имхо)
Вы же понимаете, что фронт без бэка сам выполняться не начнёт - ищите откуда "ноги растут" и результат плс в студию |
|||||
|
06.02.2024 11:09:56
и именно поэтому повышенный интерес к взлому |
|||
|
05.02.2024 18:59:54
Кстати, как с соседями - один сайт на виртуалке? |
|||
|
05.02.2024 18:58:24
да вот как показывет практика - bitrix обычно в исключения ставят, а зараза как раз любит именно туда зацепиться поэтому, не думаю, что сильно намного проще вот наличие читых бэкапов - это здорово, я бы восстановил с бэкапа, обновился до актуального и уже спокойно искал заразу ну и анализ логов, анализ логов, анализ логов |
|||
|
05.02.2024 18:55:02
ну коли бэкапы есть, можно рядышком развернуть, накидать скрипт сравнения и найти разницу в файлах но думаю у Вас и в БД чё нить нагадили ... по крайней мере в агентах я бы сразу посмотрел, любят туда запихать заразу в любом случае текущую версию я бы сразу удалять не стал, для анализа и поиска дыры оставьте даже если есть свежие бэкапы |
|||||||
|
05.02.2024 18:51:23
у Вас как логирование настроено - что выводится после кода ответа и длинны ответа? т.е. вот это интересует "https://***.ru/f195bf25c3b0.php" звёздочками забито - это домен сайта? |
|||
|
05.02.2024 18:46:19
ну да, если в админке - явно уже в движке зараза ... по системным файлам можно проверку сделать на изменения - где то в админке видел по паблику - я так понимаю проект не в гите? ну и как с бэкапами дела обстоят? |
|||
|
05.02.2024 17:03:15
подключение gtm - если не Ваше, ищите как подключается |
|||
|
05.02.2024 16:52:45
никакого криминала не видно - в основном 404 т.е. дёргают бэкдоры, но по факту не находят ну а с фронтом разбирайтесь - откуда этот js вообще прикрепился попробуйте методом исключения - сначала чистый шаблон выведите потом шапку из старого подцепите, подвал, тело |
|||
|
05.02.2024 16:49:34
и что? это же штатный функционал Битры - он и должен 200 отвечать другой вопрос дело вычистили оттуда уязвимость или нет |
|||
|