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

Если веб-сервер не может считать файл, Вы получите эту проблему. Удостоверьтесь, что веб-сервер может считать файл путем установки владения и полномочий на .htaccess соответственно.

5
задан 31 May 2014 в 01:33
6 ответов

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

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

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

8
ответ дан 3 December 2019 в 00:54

According to the perl script presented by you, your server has been compromised. I would strongly recommend to install chrootkit (yum install chrootkit) and have a check of the filesystem. I also recommend disabling that cronjob, so the rootkit is not updated.

2
ответ дан 3 December 2019 в 00:54

I was just compromised by this on my server. I can see in my logs that I was being hit on an old wordpress site, and then seconds later they had the cron jobs running over and over. Interesting that I've had this site for quite some time now, and it only happened when I changed over to nginx and php-fpm, is your setup the same?

I'm hoping that all that happened is that they were able to install these cron jobs through a vulnerability in php/wordpress basically they:

  • Got shell access and execute crontab -e to get the cron jobs firing
  • The cron job puts the script in /tmp/abc.txt.1 and executes it
  • The script downloads the litecoin miner in /etc/.ice-unix renames it kernelupdates and starts it
  • They ensure that the miner stays put from there by firing that cron job over and over

Also note that the litecoin username is slightly variable between spdrman.2 and spdrman.10.

One thing, please check your /etc/passwd for your apache user. I had my shell stupidly set to /bin/bash this is probably safer to be set as /bin/false

Also if possible ensure that your apache user cannot execute commands like crontab, wget, or curl to stop this from happening again. Those commands seem to be at the core of what they did when they got in.

As a precaution I'm changing my ssh port again, I've double checked and I've set PermitRootLogin no in sshd settings so I'm pretty sure they couldn't have gotten in directly as root

3
ответ дан 3 December 2019 в 00:54

Та же проблема на сервере 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), который используется для создания динамической библиотеки.

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

0
ответ дан 3 December 2019 в 00:54

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

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

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

3
ответ дан 3 December 2019 в 00:54

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

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

Это отключит кронтаб для пользователя www-data

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

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

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

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

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

3
ответ дан 3 December 2019 в 00:54

Теги

Похожие вопросы