Форум

[QUOTE] написал:
можно еще блокировать доступ по HTTP ниже 2. никто из нормальных пользователей сейчас не ходит по HTTP/1.1ну и не забыть добавить в исключения нужные сервисы)[/QUOTE]
Что делать с хорошими поисковыми ботами?Сейчас посмотрел: и Yandex и Google — HTTP/1.0 или /1.1

[CODE][28/May/2025:08:02:26 +0300] "GET / HTTP/1.0" 200 208042 "-" "Mozilla/5.0 (compatible; YandexBot/3.0; +http://yandex.com/bots) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.0.0" [User-Agent: Mozilla/5.0 (compatible; YandexBot/3.0; +http://yandex.com/bots) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.0.0]
[28/May/2025:08:32:34 +0300] "GET / HTTP/1.0" 200 153580 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" [User-Agent: Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)][/CODE]

[QUOTE] написал:
if ($_SERVER['REQUEST_METHOD'] == 'POST'){[/QUOTE]
Добавьте дополнительно аналогичную проверку и для GET.
Они в Аспрошные дыры ( через /ajax/js_error.php и /ajax/error_log_logic.php) те же функции пытаются через GET-запрос пропихнуть.

[QUOTE] написал:
вообще по хорошему если есть не обновленные модули то все надо обновить.[/QUOTE]
по хорошему у Битрикс в базе должна стоять защита (или как минимум опция в проактивном фильтре), там все действия хакеров стандартные и максимально нестандартные для обычных пользователей — попытка через GET или POST пропихнуть функции base64_decode, file_put_contents и т.п. В таком случае — бан и в стоп-лист.

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

активно пользуемся вашими модулями, думаю для вашей команды это на вечер задачка )

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

[QUOTE] написал:
плюс появились попытки атак через новые файлы:/bitrix/admin/esol_allimportexport_cron_settings.php/bitrix/admin/esol_import_excel_cron_settings.php/bitrix/admin/esol_export_excel_cron_settings.php/bitrix/admin/kda_import_excel_cron_settings.php/bitrix/admin/kda_export_excel_cron_settings.php[/QUOTE]
вчера вышел патч от разработчика,
там помимо данных файлов еще закрывалась дыра в этом:

[B] /bitrix/admin/esol_massedit_profile.php[/B] — это от другого их модуля

[B]у кого установлен "Массовая обработка элементов инфоблока (товаров)" от ESOL — срочно проверяйте дыру![/B]

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

[CODE]POST /bitrix/admin/esol_massedit_profile.php HTTP/1.0" 403
GET /752a2abf61d7.php HTTP/1.1" 404 [/CODE]

еще один момент,в последнее время попытки атак идут преимущественно с серверов AEZA
сегодня атаковали все сайты по несколько раз с IP — 85.192.30.151 (AEZA RU)


правильно понимаю, что можно смело банить все подсети AEZA?
вероятность, что это реальный посетитель минимальна, разве что кто поднял там собственный VPN и серфит интернет через него


или все сложней? кто вникал в вопрос?
и где можно в онлайне актуальный список всех статей AEZA посмотреть?

UPD.
список подсейтей они сами отдают, ссылку можно через whois посмотреть — [URL=https://aeza.net/static/ipv4_f.csv]https://aeza.net/static/ipv4_f.csv[/URL]

сегодня заметили новое поведение, возможно это началось и ранее:

из старых дыр попытки атак идут только по двум файлам (остальные из логов пропали):
[B][I]/ajax/error_log_logic.php[/I][/B]
[B][I]/ajax/js_error.php[/I][/B]

плюс появились попытки атак через новые файлы:
[B][I]/bitrix/admin/esol_allimportexport_cron_settings.php[/I][/B]
[B][I]/bitrix/admin/esol_import_excel_cron_settings.php[/I][/B]
[B][I]/bitrix/admin/esol_export_excel_cron_settings.php[/I][/B]
[B][I]/bitrix/admin/kda_import_excel_cron_settings.php[/I][/B]
[B][I]/bitrix/admin/kda_export_excel_cron_settings.php[/I][/B]
и
[B][I]/api/parser/index.php[/I][/B] — ???
В основном это файлы от этих разработчиков: [URL=https://marketplace.1c-bitrix.ru/partners/detail.php?ID=1660593.php]esolutions.su[/URL] и [URL=https://marketplace.1c-bitrix.ru/partners/detail.php?ID=1200834.php]mayakit.ru[/URL], так что:
[QUOTE] написал:
эх, аспро[/QUOTE]
аспро в данном случае может и не причем...

чей файл [B][I]/api/parser/index.php[/I][/B] не очень понимаю, если кто знает, напишите.


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

[QUOTE] написал:
Заменить $url_sizes на false??[/QUOTE]
про $url_sizes не подскажу,
но у Аспро в патчере так:
[CODE] 'patch_files' => [
                   '/form/index.php' => [
                       [
                           '<?elseif($form_id == \'TABLES_SIZE\'):?>',
                       ],
                       '<?// Don\'t use it! Update the module!?>'."\n".'<?elseif($form_id == \'TABLES_SIZE\' && false):?>',
                   ],
                   '/ajax/form.php' => [
                       [
                           '<?elseif($form_id === \'TABLES_SIZE\'):?>',
                           '<?elseif($form_id == \'TABLES_SIZE\'):?>',
                       ],
                       '<?// Don\'t use it! Update the module!?>'."\n".'<?elseif($form_id == \'TABLES_SIZE\' && false):?>',
                   ],
               ],[/CODE]и дополнительно проверка, что данные файлы небезопасные:
[CODE]{
                               if (false !== strpos($content, 'file_exists($url_sizes)')) {
                                   break;
                               }[/CODE]типа, если в этих файлах есть код "file_exists($url_sizes)", то файл уже пропатчен и форму можно не отключать.

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

сама дыра была в том, что через эти формы "TABLES_SIZE" можно было загружать инклюду из файла в любой дерриктории, в т.ч. текущей, чем и пользовались негодяи — подгружая js_error.txt из текущей директории,или, возможно как пишете Вы, с удаленного сервера (???).


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

[QUOTE] написал:
Похоже появился третий способ записи в js_error.txt - через Referer ))[/QUOTE]
блин! и интересно и тревожно, поделитесь потом результатами обязательно?

а в файлах /ajax/form.php или /form/index.php
дыра закрыта у Вас была?

вместо:
elseif($form_id === 'TABLES_SIZE'):

так:
elseif($form_id === 'TABLES_SIZE'[B] && false[/B]):

[QUOTE] написал:
Добрый день! А что значит запускать в режиме просмотра?[/QUOTE]
ВАЖНО!
Если патчер спрашивает "запускать в режиме просмотра", то скорее-всего у Вас ранняя версия патчера, он проверяет только дыру с unserialize.

В последней версии патчера такой галочки нет.
Отдельно кнопки:
- Сканировать
- Удалить скрипт
- Исправить выбранные

[QUOTE] написал:
Да, js_error.txt отсутствовал.[/QUOTE]
да, если есть дыра, то его удаляют сами вредоносные команды!
посмотрите лог, там в конце длинных строк идет удаление этого файла:
[CODE]DY1Il0pO319Pz4K%22));unlink($_SERVER[%22DOCUMENT_ROOT%22].%22/ajax/js_error.txt%22);

[/CODE]