Незнакомый процесс на VDS: как отличить майнер от 1С и PostgreSQL

В top один процесс забирает процессор и ходит на внешний адрес через порт 3333. Этот порт часто используют Stratum-пулы для майнинга. Но сам номер ещё не доказывает взлом: непривычно могут выглядеть PostgreSQL, мониторинг и резервное копирование.

Не завершайте процесс по имени. Сначала соберите цепочку PID → файл → порт → удалённый адрес → способ запуска. Она покажет, что происходит на сервере: работает штатная служба, остался лишний агент или VDS скомпрометирована.

Зафиксируйте PID и путь к файлу

Начните с процесса, который нагружает сервер прямо сейчас:

top

Запишите PID, пользователя, загрузку процессора и команду. Затем выведите подробности по этому PID:

ps -p PID -o pid,ppid,user,lstart,etime,%cpu,%mem,args

Вместо PID подставьте найденное число. Не сравнивайте %cpu из ps с текущей строкой top. По инструкции RUVDS о проверке процессов и соединений, ps делит накопленное процессорное время на весь срок жизни процесса. Мгновенную нагрузку эта цифра не показывает.

Теперь найдите исполняемый файл и параметры запуска:

readlink -f /proc/PID/exe
tr '\0' ' ' < /proc/PID/cmdline
ls -l /proc/PID/exe

Каталог /proc/PID хранит сведения о работающем процессе. Если исполняемый файл удалили с диска, ядро продолжит хранить эти сведения до остановки процесса. В ссылке /proc/PID/exe появится пометка (deleted).

Такая пометка требует проверки, но сама по себе не подтверждает взлом. Например, пакетный менеджер мог заменить файл во время обновления, а службу после этого не перезапустили.

Системные потоки ядра выглядят иначе. В выводе ps их имена заключены в квадратные скобки, а пути к исполняемому файлу нет. Для [kworker], [migration] и других потоков ядра это штатный вид.

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

Найдите родителя и способ запуска

Родительский процесс подскажет, откуда пришла команда:

ps -p PID -o pid,ppid,user,args
ps -p PPID -o pid,ppid,user,args

Если процесс запустил systemd, проверьте его состояние по PID:

systemctl status PID

После этого найдите соответствующую службу и её конфигурацию:

systemctl list-units --type=service --state=running
systemctl list-timers --all

Процесс без службы мог стартовать из cron, пользовательского профиля или стороннего агента. Проверьте задания его пользователя и системные каталоги cron:

crontab -l -u USER
ls -la /etc/cron.d /etc/cron.hourly /etc/cron.daily

Вместо USER подставьте имя пользователя. Не удаляйте задание сразу. Сначала сохраните команду, путь и время запуска — иначе потеряете часть цепочки и не увидите, как процесс появляется снова.

На сервере 1С сравнивайте находку с реальным составом контура. Рядом с платформой могут работать PostgreSQL, резервное копирование и мониторинг. Материал о сопоставлении Linux, PostgreSQL и процессов 1С поможет проверить штатные компоненты по их роли, а не по знакомому имени.

Свяжите PID с портом и удалённым адресом

Сначала выведите слушающие TCP-порты вместе с владельцами:

sudo ss -lntp

Затем посмотрите установленные TCP-соединения:

sudo ss -ntp

По руководству Statuser по сетевой диагностике, ss работает быстрее netstat и обычно уже входит в систему. На старом дистрибутиве может оказаться только netstat из пакета net-tools:

sudo netstat -lntp
sudo netstat -ntp

netstat показывает PID и имя процесса, но не всегда указывает нужный файл или сокет. Точную привязку даст lsof:

sudo lsof -Pan -p PID -i

Порты 3333 и 4444 часто используют Stratum-пулы. Сначала установите владельца соединения и удалённый адрес. Штатная служба на таком порту и неизвестный файл из /tmp — две разные ситуации.

Текущий трафик по процессам покажет nethogs:

sudo nethogs

Инструкция RUVDS описывает nethogs как монитор трафика с группировкой по процессам. Он пригодится, если соединение живёт несколько секунд и исчезает между запусками ss.

Порт сам по себе подозрение не подтверждает. Ищите противоречия: процесса нет в составе контура, происхождение файла неизвестно, а внешний адрес не нужен ни 1С, ни обслуживающим службам.

Если служба нужна, но доступна извне, не удаляйте её. Ограничьте интерфейс или правило межсетевого экрана. Отдельный порядок закрытия путей удалённого входа поможет сохранить доступ сотрудников к 1С.

Проверьте VDS с другого узла

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

Запустите Nmap с другой машины:

nmap IP_СЕРВЕРА

Официальное руководство Nmap указывает, что команда без диапазона проверяет более 1660 TCP-портов. Речь идёт о наборе портов Nmap, а не обо всех возможных портах TCP.

Состояние в результате описывает, как порт видит конкретный сканер. Это не постоянное свойство самого порта. В руководстве Nmap приведён пример: 135/tcp открыт при проверке из одной сети, но фильтруется при сканировании из Интернета.

Сопоставьте внешний результат с локальным:

1. Найдите через Nmap неожиданный доступный порт.
2. Установите владельца внутри VDS с помощью ss и lsof.
3. Проверьте локальный и внешний межсетевые экраны.
4. Повторите сканирование из сети, для которой доступ должен быть закрыт.

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

Найдите процесс, который удалил свой файл

Обычный список процессов не поможет, если запущенный файл уже удалили. Найдите открытые файлы, у которых число жёстких ссылок меньше единицы:

sudo lsof +L1

Именно так работает флаг +L1 по описанию в инструкции RUVDS. В выдачу могут попасть штатно обновлённые службы: пакетный менеджер заменил файл, но старый процесс ещё работает. Сверьте путь, владельца, время запуска и сетевые соединения.

Затем сравните список ps с содержимым /proc:

sudo unhide proc

unhide ищет скрытые процессы: сравнивает вывод ps с /proc и перебирает PID. Даже на чистой системе несовпадение сначала нужно объяснить. Удалять файлы по одному результату команды нельзя.

Проверьте подгружаемые библиотеки и системные утилиты

Откройте /etc/ld.so.preload:

sudo ls -l /etc/ld.so.preload
sudo sed -n '1,120p' /etc/ld.so.preload

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

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

rkhunter проверяет контрольные суммы системных команд и ищет типовые файлы руткитов:

sudo rkhunter --check

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

Lynis решает другую задачу:

sudo lynis audit system

По инструкции RUVDS, Lynis проверяет настройки защиты по чек-листу усиления системы. Это не антивирус и не инструмент поиска майнера. Запускайте его после расследования, чтобы найти слабые настройки.

Проверьте неудачные входы и журнал SSH

Команда lastb читает неудачные попытки входа из /var/log/btmp:

sudo lastb

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

В системах семейства RHEL журнал SSH часто находится в /var/log/secure:

sudo grep sshd /var/log/secure

В системах с systemd проверьте журнал службы:

sudo journalctl -u ssh --since today
sudo journalctl -u sshd --since today

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

Для следующей проверки снимков top уже мало. Настройте наблюдение за виртуальной машиной, хранилищем и хостом. График покажет момент появления нагрузки и её связь с работой пользователей.

Когда оставить процесс, ограничить доступ или пересоздать VDS

Оставьте процесс, если совпали все признаки:

• файл относится к установленному пакету или вашей службе;
• пользователь и родитель ожидаемы;
• способ запуска понятен;
• порт нужен приложению;
• удалённый адрес принадлежит вашему провайдеру, резервному хранилищу или мониторингу.

Ограничьте доступ, если служба нужна, но без рабочей причины слушает внешний интерфейс. После изменения правила снова запустите Nmap из внешней сети. Локальный ss может по-прежнему показывать слушающий сокет — это нормально, потому что внешний доступ блокирует другой уровень.

Пересоздавайте VDS из доверенного образа, если совпало несколько следов: скрытый процесс, удалённый исполняемый файл, неизвестная библиотека в /etc/ld.so.preload, неожиданный автозапуск и посторонние входы. Удаление одного видимого файла не возвращает доверие к системе.

Перед пересозданием сохраните журналы, конфигурацию 1С и резервную копию базы. Не переносите в новый образ неизвестные бинарные файлы, системные библиотеки и старые задания cron.

Карточка проверки за один проход

Соберите результат в одном месте:

PID:
Пользователь:
Исполняемый файл:
Родительский процесс:
Способ запуска:
Локальный порт:
Удалённый адрес:
Внешняя доступность:
Время первого появления:
Связанный вход в систему:
Решение:

После переноса создайте эталон AIDE на чистой системе. По инструкции RUVDS, AIDE сравнивает текущее состояние файлов с ранее сохранённой базой. Если создать эталон до очистки, он запомнит уже изменённые файлы и потеряет смысл.

Правило для решения такое: один незнакомый порт требует проверки. Несколько связанных следов требуют изоляции и пересоздания VDS.