Годные замечания. Юрий Олейников, спасибо!
|
Разработчикам |
Заражение сайтов
Заражение сайтов
|
|
|
|
|
|
|
Юрий Олейников, интересно.
|
|
|
|
|
|
Правда сейчас довольно много народу под VPN сидят... Их можно потерять
|
|
|
|
|
 у меня такой же был в логах, забанил через iptablesНарод и все-таки по вопросу расположения секций. Вот для примера скидывали тут конфиг: в нем сначала идёт секция location / {...} а уже за ней location ^~ /bitrix/modules { internal; } location ^~ /bitrix/php_interface { internal; } location ^~ /bitrix/updates { internal; } и т.д. но, как я писал ранее, в моем случае игнорировались директивы после location / {..} после переноса их ДО location / {..} они начали работать. у меня прописано: location / { try_files $uri $uri/ @bitrix; } и далее блоки location ~ \.php$ { try_files $uri @bitrix; include fastcgi_params; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_pass $php_sock; } location @bitrix { rewrite ^/(.+[^/])$ /$1/ permanent; include conf.d/settings.sub; include fastcgi_params; fastcgi_param SCRIPT_FILENAME $document_root/bitrix/urlrewrite.php; fastcgi_pass $php_sock; } и т.д. получается, что запрос /bitrix/modules/name.module/script.php в моём случае попадает в location / {..}, а в примере по ссылке - нет? |
|||
|
|
|
|
|||||||
|
|
|
|
Посмотрел сейчас логи атак:
192.145.30.64 - - [19/May/2025:11:01:28 +0300] "GET /bitrix/wizards/nextype/magnet/css/styles.css 192.145.30.64 - - [19/May/2025:11:01:28 +0300] "GET /bitrix/wizards/nextype/alpha/css/styles.css 192.145.30.64 - - [19/May/2025:15:43:07 +0300] "GET /bitrix/templates/concept_hameleon/ajax/cart/cart.php И видно что пытаются ломать , , |
|
|
|
|
|
В четверг обнаружили вирус, который обошел все блокираторы и создал в каждой папке в корне кучу файлов и папок.
fine.php b_user.json tfm2.php robotss.php .46b3931b.php Все вычистили, но в субботу утром получили вместо главной - заглушку с хохляцким бредом. Стоит Ammina - пофигу. |
|
|
|
|
|
|||
|
|
|
Проверьте файлы (на всех сайтах) /local/php_interface/init.php - должна быть конструкция в начале файла
Если нет конструкции в каком-то из init.php -добавьте
|
|
|||||||
|
|
|
В веб-сервере: стоит блокировка автоиндекса? стоит блокировка от php и sql инъекций, в часности от любимого хакерами eval(base64_decode("...")) ? стоит блокировка от доступа к отдельным каталогам по пути /вашсайт/bitrix/... ? |
|||
|
|
|
|
|||||
|
|
|
+модуль не защитит, если у вас открытые файлы без подключения пролога битрикса с опасным кодом - это через сканер троянов можно выявить. Таких файлов априори не должно быть в общем доступе (это эквивалентно транспаранту для хакеров "Добро пожаловать"). В остальном модуль перехватит и заблокирует опасные действия
|
|
|||||||
|
|
|
|
Есть еще одна интерсная вещь, кто использует модуль Let’s Encrypt то наверняка видели что он правит конфиг nginx на свой лад, и ладно бы прописывал бы только пути к своим файлам, так он еще создает для 80 порта отдельную серцию server в которой отродясь никаких фильтров не было, я это заметил по запросам которые принимал и на которые отвечал сервер, а не должен был, снес вторую секцию, прописал 80 и 443 порты в основную серцию, прописал преадресацию с http и https и вуаля, в логах зловред стал получать 444, а не как раньше 200
И что заметно по логам атакующих - сами файлы битрикса хакеры не пытаются ломать, уроверь програмистов битрикса видать не дает им пороть косяки, атаки идут исключительно на продукты парнеров, которые зачастую пишут люди далекие от безопасности... отсюда мораль - на уровне сервера закрывать доступ к каталогам с установленными решениями, но есть такие каталоги как /, например которые увы без поломки функционалала битрикса просто так не закрыть... вариант вижу лишь один - на уровне nginx ограничить доступ к системным каталогам по ip, по мне это самое лучшее решение, которое обезопасит от известных и еще не выявленных угроз |
|
|
|
|
Решил воспользоваться вашей инструкцией, но вначале уточнил у техподдержки, подойдет ли она. Вот, что ответили ****** На вашем сервере установлена ОС CentOS 7, в которой используется пакетный менеджер yum, а не apt. В его репозиториях нет пакета nginx-full: Мы не обладаем информацией, насколько эта разница критична в вашем случае. Также конфигурация виртуальных хостов на вашем сервере находится не в /etc/nginx/nginx.conf, а в большом количестве отдельных для каждого сайта файлов, расположенных в директориях /etc/nginx/vhosts-includes/, /etc/nginx/vhosts-resources/ и /etc/nginx/vhosts/. Рекомендуем уточнить критичность этого момента у составителя инструкции. Дополнительно отмечу, что nginx на вашем VPS установлен посредством ispmanager и управляется им. В случае некорректного изменения конфигурации может пропасть возможность изменять параметры сайтов через панель управления. Также файлы веб-серверов синхронизируются с информацией в базе данных ispmanager. Правки по этой причине необходимо вносить особенно осторожно. |
|||
|
|
|
|
|||||
|
|
|
|
|||
|
|
|
|
Рекомендую решение на Debian+ISPConfig из этого сообщества
Либо более продвинутое на докере из этого На обоих решениях крутятся серьезные проекты на продакшене - полёт нормальный. |
|
|
|
|
|
|||
|
|
|
Не насоздавал файлов, а сделал вставки кода с редиректом и заменил половину базы данных на повторяющиеся сообщения. Пока точку входа разработчики не нашли, ищут дальше. |
|||
|
|
|
|
жесть какая ...
Анна Иванова, отпишите плиз как найдёте точку входа |
|
|
|
|
|
|||||
|
|
|
закрыть доступ к системным каталогам и заблокировать разного рода инъекции, так же на уровне сервера дать доступ в каталог admin только с доверенных ip, переименовать каталоги с решениями всех!!! партнёров и в обязательном порядке запретить автоиндексацию сайта, дабы хакеры не могли найти переименованные каталоги Кстати есть неплохой сервис который покажет что надо защитить, если в журнале вторжений появится множество записей то сервер решето... |
|||
|
|
|
|
||||
|
|
|
|||
