Сканер chkrootkit обнаружил возможный троян KLM

Сегодня я отсканировал свою машину с chkrootkit инструмент, запустив:

sudo chkrootkit

И это было одним из результатов:

Проверка "lkm"... У вас есть
2 процесса скрыты для команды readdir У вас есть 2 процесса скрыты для команды ps chkproc: Предупреждение: возможно, установлен троян LKM chkdirs: ничего не обнаружено

Об этом стоит беспокоиться? И если так, как я могу исправить ситуацию?

Я использую Ubuntu 14.10 и chkrootkit версия 0.49.

Источник

2 ответа

Решение

Об этом стоит беспокоиться?

Нет, это ложный положительный результат и давняя ошибка в chrootkit. Вы увидите сообщение каждый раз, когда проверка lkm сообщает о скрытых процессах, недоступных команде readdir. Если у вас работает что-то вроде ClamAV, MySQL, Exim или MailScanner, вы обязательно увидите это предупреждение.

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

Кстати, rkhunter лучше проверяет lkm.

Некоторые случайные темы об этом сообщении: stackexchange, cpanel.net, Linuxquestions.org и все утверждают, что это фальшивка и ошибка.

Нечто лишнее: команда ./chkproc -v отобразит идентификаторы процесса (PID) для полученного сообщения, и вы можете использовать его, чтобы найти программу, которая связана с этим процессом с cd /proc/{PID}/ && cat cmdline

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

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

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

Во-вторых: есть немного вредоносного ПО для Linux, но оно встречается редко. По той простой причине, что, хотя Linux очень переносим, ​​он не так переносим. Различия между дистрибутивами (хотя и очень маленькими), библиотеками, различными ядрами и компиляторами делают выполнение случайного кода на случайных машинах чрезвычайно трудным. И люди, которые увлекаются вредоносным ПО, используют его для получения финансовой выгоды. Таким образом, они сосредоточены на Windows по очень простым причинам, поскольку она имеет закрытый исходный код, имеет множество дыр, которые зависят от Microsoft, чтобы предпринять действия для их исправления. (упрощенно:))

Теперь для предупреждения вы видите о возможном установленном LKM Trojan. LKM расшифровывается как Linux Kernel Module и является одним из основных модулей в Linux. Модули ядра загружаются в соответствующие ядра, и если эти два элемента не принадлежат друг другу, модули не будут загружаться. Это одна из основных функций безопасности системы Linux, которую вы можете использовать для отслеживания вредоносного кода (1).

Некоторые основные вещи о ядрах (2):

  • uname -r показывает ваше ядро.

  • установленные ядра можно посмотреть в /boot,

    rinzwind@schijfwereld:/boot$ ls abi-3.16.0-22-generic initrd.img-3.16.0-29-generic abi-3.16.0-23-generic initrd.img-3.16.0-30-generic abi-3.16.0-24-generic memtest86+.bin abi-3.16.0-25-generic memtest86+.elf abi-3.16.0-28-generic memtest86+_multiboot.bin abi-3.16.0-29-generic System.map-3.16.0-22-generic abi-3.16.0-30-generic System.map-3.16.0-23-generic config-3.16.0-22-generic System.map-3.16.0-24-generic config-3.16.0-23-generic System.map-3.16.0-25-generic config-3.16.0-24-generic System.map-3.16.0-28-generic config-3.16.0-25-generic System.map-3.16.0-29-generic config-3.16.0-28-generic System.map-3.16.0-30-generic config-3.16.0-29-generic vmlinuz-3.16.0-22-generic config-3.16.0-30-generic vmlinuz-3.16.0-23-generic grub vmlinuz-3.16.0-24-generic initrd.img-3.16.0-22-generic vmlinuz-3.16.0-25-generic initrd.img-3.16.0-23-generic vmlinuz-3.16.0-28-generic initrd.img-3.16.0-24-generic vmlinuz-3.16.0-29-generic initrd.img-3.16.0-25-generic vmlinuz-3.16.0-30-generic initrd.img-3.16.0-28-generic

  • модули ядра установлены в /lib/modules в подкаталоге, соответствующем вашему ядру.

Поэтому, основываясь на (1) и (2), следующим шагом будет перезагрузка в другое ядро. Модуль-нарушитель был скомпилирован с конкретным ядром и не сможет скомпилироваться в другое ядро ​​(просто потому, что заголовки не совпадают).

Количество каталогов и файлов, которые могут быть затронуты, когда у вас есть руткит, ограничено (руткит нужно откуда-то запустить). Есть 2 каталога и группа файлов, которые будут нацелены...

  1. /etc/init.d/

    Сделать ls -ltr /etc/init.d (он перечислит их в порядке их последнего изменения) и проверит наличие неизвестных сервисов. У нормальных служб будут вменяемые имена. Эти сервисы могут быть запущены системой или вручную.

    rinzwind@schijfwereld:/etc/init.d$ ls acpid hwclock.sh reboot alsa-utils irqbalance resolvconf anacron kerneloops rsync apparmor killprocs rsyslog apport kmod saned atieventsd lightdm sendsigs avahi-daemon lvm2 single bluetooth mountall-bootclean.sh skeleton bootmisc.sh mountall.sh smartmontools brltty mountdevsubfs.sh speech-dispatcher cgmanager mountkernfs.sh sslh cgproxy mountnfs-bootclean.sh sudo checkfs.sh mountnfs.sh thermald checkroot-bootclean.sh networking udev checkroot.sh network-manager udev-finish console-setup ondemand ufw cron php5-fpm umountfs cups pppd-dns umountnfs.sh cups-browsed procps umountroot dbus pulseaudio unattended-upgrades dns-clean rc urandom grub-common rc.local uuidd halt rcS x11-common hostname.sh README

  2. /etc/rc*/

    Скрипты запуска и уничтожения находятся в /etc/rc[0-5,S].d, Как правило, файлы здесь имеют номера и вменяемое описание (эти файлы выполняются в алфавитном порядке при запуске и в обратном порядке во время уничтожения. Следите за сценариями, состоящими из случайных чисел и букв. Вот список (это допустимые сценарии),

    rinzwind@schijfwereld:/etc$ ls rc*/ rc0.d/: K01alsa-utils K01lightdm K01unattended-upgrades K05umountnfs.sh K01atieventsd K01php5-fpm K01urandom K06networking K01bluetooth K01pulseaudio K01uuidd K07umountfs K01cgmanager K01resolvconf K02avahi-daemon K08umountroot K01cgproxy K01speech-dispatcher K03sendsigs K09halt K01cups-browsed K01sslh K04rsyslog README K01irqbalance K01thermald K05hwclock.sh

    rc1.d/: K01alsa-utils K01irqbalance K01speech-dispatcher README K01atieventsd K01kerneloops K01sslh S01dns-clean K01bluetooth K01lightdm K01thermald S01killprocs K01cgmanager K01php5-fpm K01ufw S01pppd-dns K01cgproxy K01pulseaudio K01uuidd S02single K01cups K01saned K02avahi-daemon K01cups-browsed K01smartmontools K04rsyslog

    rc2.d/: README S01uuidd S02kerneloops S04cups S01apport S02acpid S02rsync S04cups-browsed S01cgmanager S02anacron S02smartmontools S04pulseaudio S01dns-clean S02atieventsd S02speech-dispatcher S04saned S01php5-fpm S02cgproxy S02thermald S05grub-common S01pppd-dns S02cron S03avahi-daemon S05ondemand S01rsyslog S02dbus S03bluetooth S05rc.local S01sslh S02irqbalance S03lightdm

    rc3.d/: README S01uuidd S02kerneloops S04cups S01apport S02acpid S02rsync S04cups-browsed S01cgmanager S02anacron S02smartmontools S04pulseaudio S01dns-clean S02atieventsd S02speech-dispatcher S04saned S01php5-fpm S02cgproxy S02thermald S05grub-common S01pppd-dns S02cron S03avahi-daemon S05ondemand S01rsyslog S02dbus S03bluetooth S05rc.local S01sslh S02irqbalance S03lightdm

    rc4.d/: README S01uuidd S02kerneloops S04cups S01apport S02acpid S02rsync S04cups-browsed S01cgmanager S02anacron S02smartmontools S04pulseaudio S01dns-clean S02atieventsd S02speech-dispatcher S04saned S01php5-fpm S02cgproxy S02thermald S05grub-common S01pppd-dns S02cron S03avahi-daemon S05ondemand S01rsyslog S02dbus S03bluetooth S05rc.local S01sslh S02irqbalance S03lightdm

    rc5.d/: README S01uuidd S02kerneloops S04cups S01apport S02acpid S02rsync S04cups-browsed S01cgmanager S02anacron S02smartmontools S04pulseaudio S01dns-clean S02atieventsd S02speech-dispatcher S04saned S01php5-fpm S02cgproxy S02thermald S05grub-common S01pppd-dns S02cron S03avahi-daemon S05ondemand S01rsyslog S02dbus S03bluetooth S05rc.local S01sslh S02irqbalance S03lightdm

    rc6.d/: K01alsa-utils K01lightdm K01unattended-upgrades K05umountnfs.sh K01atieventsd K01php5-fpm K01urandom K06networking K01bluetooth K01pulseaudio K01uuidd K07umountfs K01cgmanager K01resolvconf K02avahi-daemon K08umountroot K01cgproxy K01speech-dispatcher K03sendsigs K09reboot K01cups-browsed K01sslh K04rsyslog README K01irqbalance K01thermald K05hwclock.sh

    rcS.d/: README S03udev S08checkroot-bootclean.sh S01console-setup S04brltty S08kmod S02alsa-utils S04mountdevsubfs.sh S08urandom S02apparmor S04procps S09mountall.sh S02hostname.sh S04udev-finish S09networking S02mountkernfs.sh S05hwclock.sh S10mountall-bootclean.sh S02resolvconf S05lvm2 S10mountnfs.sh S02ufw S06checkroot.sh S11mountnfs-bootclean.sh S02x11-common S07checkfs.sh S12bootmisc.sh

  3. скрипт запуска.

    В общем, Ubuntu использует bash в терминале и dash при загрузке. echo $SHELL покажет вам, какая оболочка используется. Для bash скрытые файлы, чтобы проверить странные сценарии или странные строки кода...

    /etc/profile 
/etc/bashrc
/etc/bash.bashrc

~/.profile
~/.bash_profile

    Это 5 самых распространенных. Любая машина может иметь больше, хотя. Помимо этого вы также можете включить

    /etc/crontab
crontab

    Последний для вашего пользователя и делать sudo su, "crontab" вы можете перечислить с crontab -l, Следите за сценариями, которые не являются общими для Linux или созданы вами.

Если вам случится иметь вторую систему, жизнь станет намного проще: вы можете просто сравнить все файлы выше со второй машиной.

Источник

Я знаю, что уже есть принятый ответ, но я хочу показать другой способ его отладки, который может помочь кому-то еще в будущем. Это помогло мне понять, что это действительно было ложным срабатыванием. Я также наткнулся на такой вывод в Ubuntu 20.04, используя v0.53.

      Checking `lkm'...                                           You have    12 process hidden for readdir command
You have    12 process hidden for ps command
chkproc: Warning: Possible LKM Trojan installed

Отметим, что количество 12менялся каждый раз, когда я запускал его. Поэтому для дальнейшей отладки я запускал (обычно в /usr/lib/chkrootkit/), что дает следующий вывод:

      PID 277881(/proc/277881): not in readdir output
PID 277881: not in ps output
You have     1 process hidden for readdir command
You have     1 process hidden for ps command

Обратите внимание, что это также менялось каждый раз, когда я его запускал (разный PID, разное количество). Таким образом, казалось, что некоторые (неопознанные) недолговечные процессы возились с , который является известным источником ложных срабатываний, см . http://www.chkrootkit.org/faq/. Чтобы вынести окончательное решение, мне нужно было идентифицировать эти недолговечные процессы, и для этого я могу только порекомендовать использовать , который может отслеживать историю процессов с течением времени, чтобы он мог сказать вам, какие процессы были активны в течение определенного периода времени.

Итак, чтобы отладить все это, вот что вам нужно сделать:

  1. Запустить в одной оболочке и запустить в другой оболочке.
  2. Когда вернет вам некоторый PID, дождитесь обновления его вывода и затем приостановите его (обычно zключ).
  3. Посмотрите на нижнюю половину вывода, где вы найдете список процессов, начиная с активных в данный момент процессов и заканчивая теми, которые завершились в течение последнего периода записи. Такие процессы будут отмечены <>в самой правой колонке.
  4. Попробуйте найти PID, который вы только что видели в chkproc -vс шага 1. Если его там нет, возможно, вы приостановили atopслишком рано, поэтому попробуйте еще раз в этом случае. Если вы можете найти PID, посмотрите на его CMDа также RUIDзапись столбца. Это должно дать вам хороший намек на то, что это был за процесс , и, надеюсь, должно дать вам представление о том, является ли это ложным срабатыванием или нет.

Наконец, я могу упомянуть, что я нашел много таких короткоживущих процессов (например, множество sleep), которые оказались контейнерами Docker, запускающими веб-приложения в моей системе. Чтобы убедиться, что я временно остановил все контейнеры Docker и все эти недолговечные процессы исчезли и chkprocтак же как chkrootkitснова были счастливы, ничего не найдя.

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

Источник
Другие вопросы по тегам