Разработчикам

Юрий (Все сообщения пользователя)

Заражение сайтов

Посетитель

Сообщений: 41 Баллов: 6 Регистрация: 11.03.2021

31.08.2025 08:52:09

Цитата
написал: Белые списки IP для админки это хорошо, но полностью проблемы не решает

Истину глаголите, закрыть по ip /bitrix/admin/ недостаточно, дабы защититься от угроз следует на уровне сервера полностью закрывать извне доступ к каталогу /bitrix/, оставив только доступ сервисам Битрикса

Перейти

Взломаны сайты в честь дня конституции украины

Пользователь 4265440

Посетитель

Сообщений: 41 Баллов: 6 Регистрация: 11.03.2021

03.07.2025 02:00:32

Цитата
написал: Вы предлагаете мне создать еще одну форму авторизации

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

Цитата
написал: А дальше вообще лес, который отменяет вообще надобность всех танцев с IP адресами - палюбому надо давать доступ внешним сервисам

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

Цитата
написал: Вы реализуете внутренний сервер без доступа в сеть

Исходящий трафик не блокируется, блокируется входящий и только к тем каталогам которые пытаются ломать, в частности админирастивный раздел, и это логично, зачем кому то кроме админа в этот раздел лазить?

Цитата
написал: И вот тут, кстати, интересен такой вопрос - а как быть с интернет-магазинами? Те же компоненты Аспро лежат именно в системной папке...

У меня инет-магазин Deluxe, часть его лежит по пути /bitrix/wizards/ , никаких проблем у покупателей не замечаю, по Аспро ничего не могу сказать, надо индивидуально тестировать, и кстати глянул сообщения о взломах Аспро, хакеры лезли по путям /bitrix/templates/ , /bitrix/components/ которые можно было закрыть и не допустить взлома

Цитата
написал: каждый IP внешнего сервиса надо отловить и размещать руками

Есть такое, и если ip сменятся то внейшний сервис отвалится, но я заморочился, смотрел логи и выявлял ip с которых идут обращения от сервисов Битрикса, уточнял в поддержке насчет статики, в случае положительного ответа вносил ip в белый список, в случае динамики открывал доступ, к счастью в моем случае такой файл один оказался, довольно рутинная замечу работа, но дала свои ощутимые плоды!

Перейти

Взломаны сайты в честь дня конституции украины

Пользователь 4265440

Посетитель

Сообщений: 41 Баллов: 6 Регистрация: 11.03.2021

02.07.2025 23:41:01

Цитата

написал:
у меня на проекте, назовем его так, 15 человек в четырех городах, которые заходят в админку с компа, с телефона, с планшета, а далее, из офиса, из кафе, просто с улицы, с аэропорта и т.д. Как мне ограничить доступ по IP? это просто невероятная задача

Делов минут на 10, поднять прокси с авторизацией, адрес прокси (если прокси не на том же сервере что и сайт) прописать в конфиг nginx в разрешенные и вуаля

Цитата
написал: есть еще внешние сервисы, типа телеги и всяких маркетплейсов.

Если ip не статика, то выяснить какие файлы проекта отвечают за коммуникацию с внешними сервисами и завернуть трафик на прокси, ну или на свой страх и риск на крайняк дать им доступ с любых ip

Цитата
написал: Закрыться как черепаха в панцире можно

Нужно, превинтивно закрыть доступ к файлам с еще не выявленными ошибками это лучшее что можно придумать, ИМХО конечно!

Перейти

Взломаны сайты в честь дня конституции украины

Пользователь 4265440

Посетитель

Сообщений: 41 Баллов: 6 Регистрация: 11.03.2021

02.07.2025 21:21:06

Цитата
написал: за исключением локального сервера и локального использования

В этом как раз таки и есть мораль - отсечь от внешней сети, то куда обычному пользователю нет необходимости лазить, вот разве обычному пользователю в отличии от хакера необходим доступ к примеру в каталоги /bitrix/tools/..., /bitrix/wizards/... и прочим? Нет, от слова совсем, так для чего эти каталоги словно кишки вспоротой свиньи торчат наружу? Для полноценного функционирования Битрикса доступ к данным каталогам можно смело ограничивать по ip

Цитата
написал: не работает это на практике, нет возможности позакрывать всё

Если нет возможности закрыть 100%, то можно закрыть 99,99 %, и защитить на эти самые 99,99% свой сайт, выше привел кусок конфига nginx который отсекает все попытки хакеров получить доступ к файлам каталога /bitrix/, я почти каждый день смjтрю логи nginx и как это приятно видеть когда хакер лезет в каталог /bitrix/admin/... или /bitrix/tools/... и т.д. и получат ответ 444... не относитесь скептически, а возьмите и попробуйте, фича реально работает, проверно!

Цитата
написал: как Вы думаете, почему тема массовой регистрации ботов в админке до сих пор толком не представлена хоть одним нормальным решением

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

Перейти

Взломаны сайты в честь дня конституции украины

Пользователь 4265440

Посетитель

Сообщений: 41 Баллов: 6 Регистрация: 11.03.2021

16.06.2025 23:18:32

Цитата
Юрий, если б все было так просто. в папке битрикс куча файлов, в том числе системных, к которым нужен доступ

Для работы функционала всё не надо открывать, для обеспечения работоспособности интеграции с внешними сервисами таким файлам, как например /bitrix/admin/user_options.php можно оставить доступ, а остальные файлы зачем в web вываливать? Какая в этом сакральная цель? Хакеров соблазнять? Не баловства ради задался данным вопросом, а после того как закрыл доступ по ip ко всем подкаталогам папки /bitrix, и видя что это работает у меня и возник сей вопрос - почему ни лекари ни разработчики не дают рекомендаций закрыть чувствительные каталоги от злодеев? Или деньги не пахнут и кому то выгодно чтобы сайты заражали? Ниже код для nginx с решением затронутого вопроса, как минимум доступ следует открыть ip сетевого адаптера сервера и ip удаленного компа с которого администрируется сайт

Код

   location ~ /bitrix/(activities|admin|blocks|cache|catalog_export|components|crontab|css|fonts|gadgets|html_pages|images|js|legal|managed_cache|modules|otp|panel|php_interface|services|sounds|stack_cache|template|templates|themes|tmp|tools|updates|wizards)/.+\.php$ {
      try_files $uri =404;
      include fastcgi_params;
      fastcgi_pass unix:/var/run/php/php8.2-fpm.sock;
      fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
      fastcgi_param SCRIPT_NAME $fastcgi_script_name;
      fastcgi_param REMOTE_USER $http_authorization;
      allow 34.206.204.40;
      allow 54.220.87.80;
      deny all;
   }

Перейти

Взломаны сайты в честь дня конституции украины

Пользователь 4265440

Посетитель

Сообщений: 41 Баллов: 6 Регистрация: 11.03.2021

15.06.2025 10:32:30

Цитата
написал: устранять возможность взлома следует на уровне сервера

Прочитал статьи от разных рода студий касающиеся лечений и предотвращения заражений, и нигде не увидел подобной рекомендации, все рекомендации шаблонные, сводятся к обновлению платформы, но рекомендаций закрыть доступ к системным файлам сайта от хакеров не высказывается ... что это, ограниченность мышления или стремление к наживе на лечении зараженных сайтов? И ладно если бы дело касалось лишь меркантильности "лекарей", так и официалы не дают внятных пояснений почему все потроха сайта непременно должны быть вывалены наружу и доступны хакерам? Как это состояние мышления назвать?!!!

Перейти

Взломаны сайты в честь дня конституции украины

Пользователь 4265440

Посетитель

Сообщений: 41 Баллов: 6 Регистрация: 11.03.2021

13.06.2025 20:55:07

Цитата
написал: Вот куда эта тварь ломится

Ломятся потому что могут, если у движка и приложений все "кишки" смотрят в инет, то взлом через 0-day уязвимости лишь дело времени, и последующие лечения устраняют лишь обнаруженную дыру, но никак не возможность взлома, устранять возможность взлома следует на уровне сервера - во первых поставить фильтра от разного рода инъекций, а во вторых закрыть весь каталог /bitrix от доступа извне, оставив лишь доступ локальным ip, доверенным ip, в том числе сервисам мониторинга Битрикса, nginx с этим справляется на ура

Перейти

Заражение сайтов

Пользователь 4265440

Посетитель

Сообщений: 41 Баллов: 6 Регистрация: 11.03.2021

11.06.2025 23:03:05

Цитата
написал: по всей видимости брутят пароль или просто подбирают по словарям либо же по открытым источникам

Подскажите, а штатный механизм защиты административного раздела /bitrix/admin/security_iprule_admin.php был задействован?

Перейти

Заражение сайтов

Пользователь 4265440

Посетитель

Сообщений: 41 Баллов: 6 Регистрация: 11.03.2021

07.06.2025 01:45:03

Интерсный запрос вчера в логе словил
138.124.31.112 - - [06/Jun/2025:08:33:32 +0300] "GET /bitrix/tools/composite_data.php HTTP/1.1"

А немногим позже обращение к трояну
138.124.31.112 - - [06/Jun/2025:11:42:02 +0300] "GET /6940ecae5880.php HTTP/1.1"

Интерсно то что через /bitrix/tools/composite_data.php уже ломились, года три этак назад, тогда выкатили обновление и лазейку прикрыли, а сейчас хакеры видать что то поменяли и снова ломятся в ту же дверь...

Перейти

Заражение сайтов

Пользователь 4265440

Посетитель

Сообщений: 41 Баллов: 6 Регистрация: 11.03.2021

01.06.2025 21:28:18

Цитата
написал: новые попытки взлома через /bitrix/services/main/ajax.php

После закрытия доступа по ip к /bitrix/services/ nginx при попытке обращения к данному файлу отдает 403 Forbidden, рекомендую

Перейти

Заражение сайтов

Пользователь 4265440

Посетитель

Сообщений: 41 Баллов: 6 Регистрация: 11.03.2021

01.06.2025 20:07:32

Цитата
написал: и по хорошему бы лучше не ограничиваться лишь одним /bitrix/admin/, а закрыть на уровне сервера по ip все возможные подкаталоги в /bitrix/

Ограничил досуп по ip к php файлам во всех подкаталогах каталога /bitrix/, каких то эксцесов в работе с клиентской частью не заметил, по видимому годное решение, можно дальше идти по этому пути закрывая другие каталоги

Код

# bitrix admin
location ~ /bitrix/(activities|admin|blocks|cache|catalog_export|components|crontab|css|fonts|gadgets|html_pages|images|js|legal|managed_cache|modules|otp|panel|php_interface|services|sounds|stack_cache|template|templates|themes|tmp|tools|updates|wizards)/.+\.php$ {
   try_files $uri =403;
   include fastcgi_params;
   fastcgi_pass unix:/var/run/php/php8.2-fpm.sock;
   fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
   fastcgi_param SCRIPT_NAME $fastcgi_script_name;
   fastcgi_param REMOTE_USER $http_authorization;
   allow 192.168.0.2;
   allow 192.168.0.3;
   deny all;
}

Перейти

Заражение сайтов

Пользователь 4265440

Посетитель

Сообщений: 41 Баллов: 6 Регистрация: 11.03.2021

31.05.2025 08:27:20

Цитата
написал: Толку нет от закрытия /bitrix/admin/

Не могу согласиться, если току нет, то зачем хакеры долбят по путям где находятся файлы модулей от партнеров, такие как /bitrix/admin/, /bitrix/modules/, /bitrix/wizards/, /bitrix/templates/, и т.д.? Вот кусок лога с моего сервера с попытками произвести php-инъекцию по пути /bitrix/admin/:

194.190.153.24 - - [18/May/2025:21:11:17 +0300] "POST /bitrix/admin/esol_import_excel_cron_settings.php
194.190.153.24 - - [18/May/2025:21:11:17 +0300] "POST /bitrix/admin/esol_export_excel_cron_settings.php
194.190.153.24 - - [18/May/2025:21:11:17 +0300] "POST /bitrix/admin/esol_import_xml_cron_settings.php
194.190.153.24 - - [18/May/2025:21:11:18 +0300] "POST /bitrix/admin/esol_export_xml_cron_settings.php
194.190.153.24 - - [18/May/2025:21:11:19 +0300] "POST /bitrix/admin/kda_import_excel_cron_settings.php
194.190.153.24 - - [18/May/2025:21:11:20 +0300] "POST /bitrix/admin/kda_export_excel_cron_settings.php
194.190.153.24 - - [18/May/2025:21:11:20 +0300] "POST /bitrix/admin/esol_allimportexport_cron_settings.php
194.190.153.24 - - [18/May/2025:21:11:23 +0300] "POST /bitrix/admin/esol_massedit_profile.php
194.190.153.24 - - [18/May/2025:21:11:24 +0300] "GET /6940ecae5880.php

Если все кишки модулей торчат наружу и доступны из веба, то только на уровне сервера можно закрыть уязвимые места от известных и еще не вывыявленных уязвимостей, это лучшее что можно придумать, и по хорошему бы лучше не ограничиваться лишь одним /bitrix/admin/, а закрыть на уровне сервера по ip все возможные подкаталоги в /bitrix/ явно не влияющие на клиентский функционал

Перейти

Заражение сайтов

Пользователь 4265440

Посетитель

Сообщений: 41 Баллов: 6 Регистрация: 11.03.2021

30.05.2025 21:32:12

Если кто хочет поэксприментировать с закрытием /bitrix/admin/ приложу небольшой мануал, применительно к Debian с nginx + php-fpm, ip 192.168.0.2 и версию php-fpm поменять на свои, в секции server выше location ~ \.php$ ... добавить location

Код

# bitrix admin
location ~ /bitrix/admin.+\.php$ {
   try_files $uri =403;
   include fastcgi_params;
   fastcgi_pass unix:/var/run/php/php8.2-fpm.sock;
   fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
   fastcgi_param SCRIPT_NAME $fastcgi_script_name;
   fastcgi_param REMOTE_USER $http_authorization;
   allow 192.168.0.2;
   deny all;
}

Перейти

Заражение сайтов

Пользователь 4265440

Посетитель

Сообщений: 41 Баллов: 6 Регистрация: 11.03.2021

30.05.2025 13:50:17

Цитата
написал: Оптимально будет /bitrix/admin/ закрыть по белым спискам IP

Данное решение лучшее что может быть, оно убережет от изветных и еще не выявленных уязвимостей, в свое время пытался так поступить, но в каталоге /bitrix/admin/ довольно много php файлов к которым напрямую обращаются сервера Битрикса, такие как /bitrix/admin/bitrixcloud_monitoring_admin.php и подобные, закрывая к ним доступ отваливается часть функционала... найти бы инфу что в исключения кинуть... как вариант логи поковырять и выяснить к чему обращаются сервера Битрикса...

Перейти

Заражение сайтов

Пользователь 4265440

Посетитель

Сообщений: 41 Баллов: 6 Регистрация: 11.03.2021

30.05.2025 10:18:23

Цитата
написал: Уязвимость в плагинах Bitrix Экспорт/Импорт товаров в Excel https://alekseycheremnykh.ru/post/uyazvimost-v-plaginah-bitrix-eksportimport-tovarov-v-excel/

Инфа увы не полная, в частности уязвимости модулей esol от 0.6.8 до 1.1.6 версий, модуль до сих пор уязвим, на своем сервере лично в середине марта наблюдал взлом модуля версии 1.49 через инъекцию в php файл, поскольку модуль необходим в работе закрыл индексацию файлов сайта, поставил в nginx блок на инъекции вида eval (base64_decode и от греха подальше дабы исключить взлом по шаблону еще и переименовал сам модуль, поскольку как показали сообщения пользователей ломают не Битрикс, а модули партнеров

Перейти

Заражение сайтов

Пользователь 4265440

Посетитель

Сообщений: 41 Баллов: 6 Регистрация: 11.03.2021

29.05.2025 09:27:38

Цитата
написал: новые попытки взлома через /bitrix/services/main/ajax.php

Не видел еще в логах такого, хотел было забокировать доступ к каталогу /bitrix/services/ , но увы перестал работать сервис Поиск троянов...

Дело прошлое, пытался ограничить извне доступ к содержимому каталога /bitrix/, по очереди блокировал доступ к подкаталогам, но увы то одно отвалится то другое, на кой хрен разаработчики решили что к системным каталогам должен быть доступ извне не понимаю... для пущей заботы о клиенте? Так это же медвежья услуга, которая не дает превентивно уберечься от еще не выявленных уязвимостей...

Перейти

Заражение сайтов

Пользователь 4265440

Посетитель

Сообщений: 41 Баллов: 6 Регистрация: 11.03.2021

28.05.2025 21:14:25

Цитата
написал: чёт не очень понял, почему упали

Насколько я понимаю судя по логам хакерский софт в силу специфики использует преимущественно не защищенные соединения по протоколу HTTP/1.0 или HTTP/1.1, а современные браузеры наоборот никаких претензий к HTTP/2 не имеют, поэтому блокировав протоколы HTTP/1.0 и HTTP/1.1 можно в некой мере оградиться от примитивных хакерских вторжений

Цитата
написал: а роботы всякие полезные нормально HTTP2 скушают при блокировке HTTP1?

Поглядел, на странице посетителей сайта /bitrix/admin/guest_list.php User Agent от ботов увы не увидел, зато список точек выхода такой красивый, что отродясь не было, все заходы через браузеры и только на страницы сайта без попыток залезть в системные каталоги, все это хорошо, но видать для того же Яндекс-бота и прочих хороших ботов надо делать исключения...

Походил по сайтам озона, валбериса, ситилинка, днс и прочих крупных магазинов и HTTP Indicator показал что они все используют HTTP2, было бы что то не так, то не использовали, так что тропинка верная

В догонку, вот сегодня обнаружил в посетителях сайта: Mozilla/5.0 (compatible; YandexUserproxy; robot; +http://yandex.com/bots) так что Яндекс нормально понимает HTTP/2

Перейти

Заражение сайтов

Пользователь 4265440

Посетитель

Сообщений: 41 Баллов: 6 Регистрация: 11.03.2021

28.05.2025 15:16:22

Цитата
написал: listen 80 http2; listen 443 ssl http2;

Потестил, доходящие до Битрикса запросы прям в разы упали, рекомендую всем для уменьшения разной гадости!

Приложение для хрома HTTP Indicator , наглядко покажет версию HTTP на сервере

Перейти

Заражение сайтов

Пользователь 4265440

Посетитель

Сообщений: 41 Баллов: 6 Регистрация: 11.03.2021

28.05.2025 13:15:34

Цитата
написал: можно еще блокировать доступ по HTTP ниже 2

Хорошее предложение, прописал в nginx

listen 80 http2;
listen 443 ssl http2;

И понаблюдаю в логах за пауками

Цитата
написал: ну и не забыть добавить в исключения нужные сервисы

Это да, надо глянуть как Certbot себя поведет

Перейти

Заражение сайтов

Пользователь 4265440

Посетитель

Сообщений: 41 Баллов: 6 Регистрация: 11.03.2021

27.05.2025 12:07:01

Цитата
написал: Все эти "переименовать решения" и прочие действия и особенно ошибки, которые привели к тому что вообще можно заразить сайты, мне напоминают вот это видео про Ниву

Ну так выбора иного нет, Бирикс русским по белому пишет, что не несет ответственности за решения партнёров, представленных в его магазине, а партнерам пофиг на безопасность клиента, шевелиться начинают, когда массово ломать их решения начинают, поэтому клиентам и приходится водить хоровод с танцами и бубном лепя заплатки то там, то сям…

Кстати, насчет заплаток, наблюдая за логами атакующих заметил что атакуют в своей массе из за рубежа и по http, поэтому тем кто не хочет жестко блочить клиентов из за бугра можно в iptables создать правило блокировать все запросы к 80 порту не из России, обращения реальных клиентов идет по https к 443 порту, поэтому реальный клиент ни коим образом не пострадает от блокировки, а хакеры получат отлуп

Перейти

Заражение сайтов

Пользователь 4265440

Посетитель

Сообщений: 41 Баллов: 6 Регистрация: 11.03.2021

27.05.2025 10:00:59

Цитата
написал: переименовать каталоги с решениями всех!!! партнёров

Это для того что ломают по шаблону

Перейти

Заражение сайтов

Пользователь 4265440

Посетитель

Сообщений: 41 Баллов: 6 Регистрация: 11.03.2021

27.05.2025 09:59:38

Цитата
написал: При попытке удалить вставленный кусок кода из шаблона Ammina заблокировала меня, а вот вирус вставку сделал спокойно без проблем

Что создано одним человеком другой может обойти или поломать… на мой взгляд самый лучший вариант не уповать на Ammina, а на уровне сервера
закрыть доступ к системным каталогам и заблокировать разного рода инъекции, так же на уровне сервера дать доступ в каталог admin только с доверенных ip, переименовать каталоги с решениями всех!!! партнёров и в обязательном порядке запретить автоиндексацию сайта, дабы хакеры не могли найти переименованные каталоги

Кстати есть неплохой сервис https://immuniweb.com/websec/ который покажет что надо защитить, если в журнале вторжений появится множество записей то сервер решето...

Перейти

Заражение сайтов

Пользователь 4265440

Посетитель

Сообщений: 41 Баллов: 6 Регистрация: 11.03.2021

27.05.2025 09:47:06

Цитата
написал: Пока точку входа разработчики не нашли

А у вашего сайта случаем по соседству нет другого или других сайтов? Если в одной папке на сервере находятся две и более папок под сайты, например /var/www/вашсайт и /var/www/сайт соседа, то в случае заражения соседа хакер получает доступ ко всем соседним сайтам

Цитата
написал: заменил половину базы данных на повторяющиеся сообщения

Резервные копии делали?

Перейти

Заражение сайтов

Пользователь 4265440

Посетитель

Сообщений: 41 Баллов: 6 Регистрация: 11.03.2021

26.05.2025 10:40:14

Цитата
написал: ISPConfig

А панель зачем? Это же стороннее ПО, к которому создатели операциооной системы не имеют отношения, мало того что панель это потенциальная дыра в безопасности, так еще панели предоставляют доступ к настройкам сервера из браузера, тем самым предоставляют серьёзную угрозу для всего, что есть на сервере, доступ к серверу должен быть только по ssh и только по сертифкату

Перейти

Заражение сайтов

Пользователь 4265440

Посетитель

Сообщений: 41 Баллов: 6 Регистрация: 11.03.2021

25.05.2025 19:52:29

Цитата
написал: Насколько легко можно адаптировать вашу инструкцию для ОС CentOS 7 ?

У специалиста вообще никаких трудностей не возникнет, еще можно организовать фильтр через Iptables, если вдруг упретесь в трудности с панелью, в Iptables вообще одну строчку надо в конфиг добавить и базы так же доступны

Перейти

Юрий (Все сообщения пользователя)

Продукты

Управление сайтом

Битрикс24

Интернет-магазин + CRM

Решения

Для интернет-магазинов

Каталог готовых решений

Внедрение

Выбрать партнера

Проверить партнера

Стать партнером