Как я сражался на сервере с вирусом-криптомайнером, маскирующимся под PostgreSQL

1 mo. ago

Целая детективная история разыгралась на моём сервере.

Дано: небольшой арендуемый у хостера сервер с Debian 12 и последней PostgreSQL 16. Постгрес стоит без всяких докеров.

Месяц назад начал тормозить сервак. Думаю, что за ерунда, захожу по SSH, ввожу:

top

и вверху поверх всякой мелочи вижу это:

 PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
2251 postgres  20   0 2445140   2,3g      4 S 400,7  14,7   6:20.66 kswapd0

Жрёт все ресурсы, процессор загружен полностью.
Зарождается слабая мысль о криптомайнерах, но пока не понимаю, как вирус проник на сервер. Пароль у рута сложный, да и тут про постгрес написано.

В общем, думаю - ну, заглючил PostgreSQL, наверное. Убиваю процесс и перезагружаю сервак (это всегда полезно):

kill 2251
reboot

Захожу по SSH снова - чисто. Ну, думаю, всё ок.

Потом опять тормоза через некоторое время. Смотрю - эта хрень опять запущена. И странно как-то всё, причём тут юзер postgres?

Полез гуглить. Про этот kswapd и нагрузку на проц много разрозненных сообщений. Народ про него пишет и 2013, и в 2017, а у меня вообще-то 2024 на дворе, а ведь в те годы не было ещё криптовалют.
Может это не криптомайнер, а что-то другое?

Пытаюсь понять, кто запускает процесс. Делаю:

ls -l /proc/2251/exe

выводит:

lrwxrwxrwx 1 postgres postgres 0 июл 23 13:12 /proc/2251/exe -> /var/lib/postgresql/.configrc5/a/kswapd0

Такс... Находится в каталоге postgresql. А вдруг это важная часть сервера базы данных? Названо ведь так "по-умному" - configrc5.

Решаю просто переименовать каталог:

kill 2251
cd /var/lib/postgresql
mv .configrc5 _renamed_.configrc5
reboot

После этого всё хорошо... но только пару недель :)

Через эти пару недель опять веселуха с загрузкой всех ядер процессора.
Смотрю - каталог снова создан. Значит точно криптовалютный вирус. Но как зараза проникла на сервер?

Наконец-то до моей глупой головы дошло посмотреть логи SSH:

journalctl -t sshd

Опытные линуксоиды знают, что так смотреть не имеет смысла. Там толпы кул-хацкеров пытаются подключиться к серверу, но обламываются.
Фильтрую только логи успешного входа по SSH:

journalctl -t sshd --since "2024-08-01" --until "2024-08-16 10:00:00" | grep "Accepted "

И там среди моих заходов вижу эту падлюку:

Jul 06 11:40:07 debian sshd[589266]: Accepted password for postgres from 103.94.113.2 port 33482 ssh2
Jul 10 08:18:00 debian sshd[723300]: Accepted publickey for postgres from 162.217.64.26 port 60366 ssh2: RSA SHA256:MkYY9qiVsFGBC5WkjoClCkwEFW5iSjcGQF7m4n4H7Cw
Aug 02 07:45:44 debian sshd[258599]: Accepted publickey for postgres from 206.189.36.236 port 47140 ssh2: RSA SHA256:MkYY9qiVsFGBC5WkjoClCkwEFW5iSjcGQF7m4n4H7Cw
Aug 02 07:50:53 debian sshd[258915]: Accepted publickey for postgres from 157.245.42.37 port 50478 ssh2: RSA SHA256:MkYY9qiVsFGBC5WkjoClCkwEFW5iSjcGQF7m4n4H7Cw
Aug 14 10:23:08 debian sshd[99132]: Accepted publickey for postgres from 82.165.79.77 port 40086 ssh2: RSA SHA256:MkYY9qiVsFGBC5WkjoClCkwEFW5iSjcGQF7m4n4H7Cw
Aug 14 10:47:37 debian sshd[99723]: Accepted publickey for postgres from 103.146.52.138 port 55110 ssh2: RSA SHA256:MkYY9qiVsFGBC5WkjoClCkwEFW5iSjcGQF7m4n4H7Cw

Ёлы-палы! Сначала чувак вошёл по паролю, а потом уже входил по ключу.

Ради интереса проверил айпишники:
103.94.113.2 - India
162.217.64.26 - USA
206.189.36.236 - Singapore
103.146.52.138 - Hong Kong
Целый ботнет. Или VPN-ы. Не знаю, да и это не важно.

Начинаю вспоминать, что когда ставил PostgreSQL, создавал примитивный пароль. Или вообще не задавал его - точно не помню.

Срочно меняю пароль юзеру postgres:

passwd postgres

и ставлю запрет входа SSH для определённых юзеров:

nano /etc/ssh/sshd_config

DenyUsers postgres no-reply blah

В идеале, конечно вообще всем запретить, а оставить только для разрешённых.

Перезагружаем SSH демона:

systemctl restart sshd

Кстати, это зараза прописала SSH-ключ в:

/var/lib/postgresql/.ssh/authorized_keys

ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQEArDp4cun2lhr4KUhBGE7VvAcwdli2a8dbnrTOrbMz1+5O73fcBOx8NVbUT0bUanUV9tJ2/9p7+vD0EpZ3Tz/+0kX34uAx1RV/75GVOmNx+9EuWOnvNoaJe0QXxziIg9eLBHpgLMuakb5+BgTFB+rKJAw9u9FSTDengvS8hX1kNFS4Mjux0hJOK8rvcEmPecjdySYMb66nylAKGwCEE6WEQHmd1mUPgHwGQ0hWCwsQk13yCGPK5w6hYp5zYkFnvlC8hGmd4Ww+u97k6pfTGTUbJk14ujvcD9iUKQTTWYYjIIu5PmUux5bsZ0R4WFwdIe6+i6rBLAsPKgAySVKPRK+oRw== mdrfckr

Разумеется это надо сразу удалять.

Вирусняк прописывал себя и в крон.

А вот содержимое каталога:

Если запустить бинарник (я это по неосторожности сделал :)), то автоматически прописываются ключи в authorized_keys и криптомайнер заново запускается.

Какой из этого можно сделать вывод? Не будь дураком :)
Порты закрыть - это только часть дела. Сложные пароли нужно иметь у всех юзеров. Особенно у тех, у которых есть запуск шелла при логине.

Смотрим файл:

cat /etc/passwd

Там будет примерно такое:

games:x:5:60:games:/usr/games:/usr/sbin/nologin
man:x:6:12:man:/var/cache/man:/usr/sbin/nologin
lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin
mail:x:8:8:mail:/var/mail:/usr/sbin/nologin

Так вот, /usr/sbin/nologin или /bin/false в конце - это значит шелл не запустится при логине.
А вот если есть такое:

postgres:x:114:122:PostgreSQL administrator,,,:/var/lib/postgresql:/bin/bash

то в случае успешного входа под юзером у него запускается шелл. Да, там не рут-права, но гадить можно.

После всего этого я стал чуть больше красноглазиком.

компьютерный вирус

Linux

Debian

SSH

PostgreSQL

криптовалюты

dima

1 mo. ago

Негодяйский негодяй пытается войти на сервак :)

connected2u

9 days ago

Не все понял, но очень интересно :)

Передача по ссылке и передача по значению в JavaScript

dima

28 days ago

Насколько хорошо вы знаете JavaScript?
Как в JS передаются значения - по ссылке или по значению? Не спешите, подумайте даже если вы "мидл" или синьор-помидор.

let str1 = 'Famabara';
let str2 = str1; // Тут копия или новая строка?

let obj1 = { name: 'Famabara' };
let obj2 = obj1; // Тут копия или новый объект?

Можете в опросе ответить:

Как передаются значения при присвоении в переменную или в свойство объекта?

Всё передаётся по ссылке

Всё передаётся по значению (т.е. объекты тоже копируются)

Примитивы копируются, объекты передаются по ссылке (копируется ссылка на объект)

Теперь посмотрим, что нам говорит learn.javascript.ru - очень популярный в рунете учебник JavaScript:

А теперь давайте запустим в NodeJS такой код:

const arr = [];

for (let i = 0; i < 1200200; i++) {
  arr.push('0123456789'.repeat(1000 * 1000));
}

while (true) {
}

После запуска смотриим программой top потребление ресурсов:

39858 dima      20   0 2026180   1,0g  37824 R 100,0   3,2   0:21.44 node

На моей Кубунте сожрано 1 Гб оперативки. Ух ты.

Теперь изменим немного код:

const arr = [];
const text = '0123456789'.repeat(1000 * 1000);

for (let i = 0; i < 1200200; i++) {
  arr.push(text);
}

while (true) {
}

Смотрим ещё раз через top:

40267 dima      20   0 1066148  73796  37440 R  99,7   0,2   0:12.27 node

Программа потребила всего 73 Мб вместо 1 Гб. Согласно популярной теории о копировании примитивов такого быть не должно. ;)

В чем разница между двумя примерами кода? В первом случае мы всякий раз создаём новую строку, а а во втором - пихаем в массив ту же самую строку из созданной переменной. Если вы вдруг подумали, что во втором случае надо предварительно поместить значение в переменную-посредник, а потом уже пушить в массив, то нет - это не поможет, оперативка жраться всё равно не будет.

Кстати, на ноде в Windows 10 аналогичное поведение - около 1 Гб потребление против менее 100.

Ну, а теперь главный секрет! :)
В JavaScript всё передаётся/копируется по ссылке!

JavaScript

Эффективность использования всех ядер процессора в NodeJS с помощью cluster

dima

14 days ago

Для повышения производительности приложений на NodeJS во всех материалах рекомендуется использовать нодовский встроенный модуль cluster. Все статьи повторяют одно и то же, что и так написано в документации.
Вот официальный пример из доки:

import cluster from 'node:cluster';
import http from 'node:http';
import { availableParallelism } from 'node:os';
import process from 'node:process';

const numCPUs = availableParallelism();

if (cluster.isPrimary) {
  console.log(`Primary ${process.pid} is running`);

  // Fork workers.
  for (let i = 0; i < numCPUs; i++) {
    cluster.fork();
  }

  cluster.on('exit', (worker, code, signal) => {
    console.log(`worker ${worker.process.pid} died`);
  });
} else {
  // Workers can share any TCP connection
  // In this case it is an HTTP server
  http.createServer((req, res) => {
    res.writeHead(200);
    res.end('hello world\n');
  }).listen(8000);

  console.log(`Worker ${process.pid} started`);
}

А теперь поделюсь своими исследованиями и расскажу, что не так в этом примере и как это можно улучшить.

Во-первых, некорректен нейминг переменной numCPUs. На моём компьютере, на котором тестировал производительность, стоит процессор Intel i7-13700, в нём всего 16 ядер. Сайт Intel так и пишет:

Node.js

JavaScript

производительность

Как запустить Elasticsearch из-под рута

dima

1 mo. ago

Elasticsearch не разрешает запускать себя из-под пользователя root, это намеренно сделанное ограничение. Если нужно оставаться под рутом по тем или иным причинам, а запустить Elasticsearch нужно, то есть обходное решение.

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

useradd elastic

Далее делаем этого юзера владельцем каталога c Эластиком:

chown -R elastic:elastic ./elasticsearch-8.14.3

И наконец используем программу runuser для запуска Elasticsearch из-под другого юзера:

runuser -u elastic -- /elasticsearch-8.14.3/bin/elasticsearch -d -p pid.txt

Эластиксёрч будет запущен, рут-юзер сможет к нему подключаться.

Напоминаю, что runuser может использоваться только root-пользователем.

Elasticsearch

Linux

Как я сражался на сервере с вирусом-криптомайнером, маскирующимся под PostgreSQL

Популярность Vue.js в 2024

Передача по ссылке и передача по значению в JavaScript

Эффективность использования всех ядер процессора в NodeJS с помощью cluster

Как запустить Elasticsearch из-под рута