Сервер захвачен / используется как майнер биткойнов - как мне это остановить?

7108
Mud

Я нахожусь в некоторой ситуации, мой сервер был взломан, и, похоже, он вовлечен в операцию майнинга биткойнов.

Мне нужно хотя бы знать, с чего начать, я начинающий системный администратор и до сих пор не сталкивался с этим. Он уносит мою пропускную способность из воды, и мой хостинг-провайдер платит мне 50 центов за ГБ, и из-за этого он подскочил на 255 ГБ -> 301,8 ГБ за один день. Любая помощь приветствуется.

Я нашел много мусора в журналах, относящихся к Stratum, а также в сценариях на внешних IP-адресах, работающих на моем сервере. Затем я смотрю в директорию / tmp и вижу 7 файлов, которые

  • удар
  • cron.d
  • mech.dir
  • ш
  • spamd_full.sock
  • Обновить

Пример содержимого моего журнала ошибок apache:

[Thu Nov 28 16:27:40 2013] [error] [client 173.201.45.104] --2013-11-28 16:27:40-- http://74.208.228.113/sh [Thu Nov 28 16:27:40 2013] [error] [client 173.201.45.104] Connecting to 74.208.228.113:80... [Thu Nov 28 16:27:40 2013] [error] [client 173.201.45.104] connected. [Thu Nov 28 16:27:40 2013] [error] [client 173.201.45.104] HTTP request sent, awaiting response... [Thu Nov 28 16:27:40 2013] [error] [client 173.201.45.104] 200 OK [Thu Nov 28 16:27:40 2013] [error] [client 173.201.45.104] Length: [Thu Nov 28 16:27:40 2013] [error] [client 173.201.45.104] 518288 [Thu Nov 28 16:27:40 2013] [error] [client 173.201.45.104] (506K) [Thu Nov 28 16:27:40 2013] [error] [client 173.201.45.104] [text/plain] [Thu Nov 28 16:27:40 2013] [error] [client 173.201.45.104] Saving to: `sh' [Thu Nov 28 16:27:40 2013] [error] [client 173.201.45.104] [Thu Nov 28 16:27:40 2013] [error] [client 173.201.45.104] 0K [Thu Nov 28 16:27:40 2013] [error] [client 173.201.45.104] [Thu Nov 28 16:27:40 2013] [error] [client 173.201.45.104] . [Thu Nov 28 16:27:40 2013] [error] [client 173.201.45.104] ... .......... .......... 9% 148K 3s [Thu Nov 28 16:27:40 2013] [error] [client 173.201.45.104] 50K ........ [Thu Nov 28 16:27:40 2013] [error] [client 173.201.45.104] .. .......... .......... .......... ..... [Thu Nov 28 16:27:40 2013] [error] [client 173.201.45.104] ..... 19% 172K 3s [Thu Nov 28 16:27:40 2013] [error] [client 173.201.45.104] 100K .......... .......... ...... [Thu Nov 28 16:27:41 2013] [error] [client 173.201.45.104] .... .......... .......... 29% 344K 2s [Thu Nov 28 16:27:41 2013] [error] [client 173.201.45.104] 150K ....... [Thu Nov 28 16:27:41 2013] [error] [client 173.201.45.104] ... .......... .......... .......... .......... 39% 514K 1s [Thu Nov 28 16:27:41 2013] [error] [client 173.201.45.104] 200K ......... [Thu Nov 28 16:27:41 2013] [error] [client 173.201.45.104] . [Thu Nov 28 16:27:41 2013] [error] [client 173.201.45.104] .. [Thu Nov 28 16:27:41 2013] [error] [client 173.201.45.104] . [Thu Nov 28 16:27:41 2013] [error] [client 173.201.45.104] . [Thu Nov 28 16:27:41 2013] [error] [client 173.201.45.104] .. [Thu Nov 28 16:27:41 2013] [error] [client 173.201.45.104] . [Thu Nov 28 16:27:41 2013] [error] [client 173.201.45.104] . [Thu Nov 28 16:27:41 2013] [error] [client 173.201.45.104] .. .......... .......... .......... 49% 347K 1s [Thu Nov 28 16:27:41 2013] [error] [client 173.201.45.104] 250K .......... .......... .......... ........ [Thu Nov 28 16:27:41 2013] [error] [client 173.201.45.104] .. .......... 59% 347K 1s [Thu Nov 28 16:27:41 2013] [error] [client 173.201.45.104] 300K .......... .......... .......... .......... .......... 69% 224M 1s [Thu Nov 28 16:27:41 2013] [error] [client 173.201.45.104] 350K . [Thu Nov 28 16:27:41 2013] [error] [client 173.201.45.104] ......... .......... .......... .......... .......... 79% 347K 0s [Thu Nov 28 16:27:41 2013] [error] [client 173.201.45.104] 400K .......... ... [Thu Nov 28 16:27:41 2013] [error] [client 173.201.45.104] ....... .......... .......... .......... 88% 348K 0s [Thu Nov 28 16:27:41 2013] [error] [client 173.201.45.104] 450K .......... .......... .......... .......... .......... 98% 254M 0s [Thu Nov 28 16:27:41 2013] [error] [client 173.201.45.104] 500K ... [Thu Nov 28 16:27:41 2013] [error] [client 173.201.45.104] ... 100% 64.1K=1.5s [Thu Nov 28 16:27:41 2013] [error] [client 173.201.45.104] [Thu Nov 28 16:27:41 2013] [error] [client 173.201.45.104] 2013-11-28 16:27:41 (328 KB/s) - `sh' saved [518288/518288] [Thu Nov 28 16:27:41 2013] [error] [client 173.201.45.104] [Thu Nov 28 16:27:58 2013] [error] [client 173.201.45.104] kill: usage: kill [-s sigspec | -n signum | -sigspec] pid | jobspec ... or kill -l [sigspec] [Thu Nov 28 16:28:26 2013] [error] [client 173.201.45.104] kill: usage: kill [-s sigspec | -n signum | -sigspec] pid | jobspec ... or kill -l [sigspec] [Thu Nov 28 16:28:26 2013] [error] [client 173.201.45.104] a: line 24: ./bash: No such file or directory [Thu Nov 28 16:28:26 2013] [error] [client 173.201.45.104] chattr [Thu Nov 28 16:28:26 2013] [error] [client 173.201.45.104] : [Thu Nov 28 16:28:26 2013] [error] [client 173.201.45.104] Operation not permitted [Thu Nov 28 16:28:26 2013] [error] [client 173.201.45.104] [Thu Nov 28 16:28:26 2013] [error] [client 173.201.45.104] while setting flags on bash [Thu Nov 28 16:28:26 2013] [error] [client 173.201.45.104] \r [Thu Nov 28 16:28:26 2013] [error] [client 173.201.45.104] chattr [Thu Nov 28 16:28:26 2013] [error] [client 173.201.45.104] : [Thu Nov 28 16:28:26 2013] [error] [client 173.201.45.104] Operation not permitted [Thu Nov 28 16:28:26 2013] [error] [client 173.201.45.104] [Thu Nov 28 16:28:26 2013] [error] [client 173.201.45.104] while setting flags on sh [Thu Nov 28 16:28:26 2013] [error] [client 173.201.45.104] \r [Thu Nov 28 16:28:28 2013] [error] [client 173.201.45.104] [2013-11-28 16:28:28] 2 miner threads started, using 'scrypt' algorithm. [Thu Nov 28 16:28:28 2013] [error] [client 173.201.45.104] [2013-11-28 16:28:28] Starting Stratum on stratum+tcp://216.230.103.42:3333 [Thu Nov 28 16:28:28 2013] [error] [client 173.201.45.104] [2013-11-28 16:28:28] Stratum connection failed: Failed connect to 216.230.103.42:3333; Connection refused [Thu Nov 28 16:28:28 2013] [error] [client 173.201.45.104] [2013-11-28 16:28:28] ...retry after 30 seconds [Thu Nov 28 16:28:33 2013] [error] [client 173.201.45.104] [2013-11-28 16:28:33] Binding thread 1 to cpu 1 [Thu Nov 28 16:28:58 2013] [error] [client 173.201.45.104] [2013-11-28 16:28:58] Stratum connection failed: Failed connect to 216.230.103.42:3333; Connection refused [Thu Nov 28 16:28:58 2013] [error] [client 173.201.45.104] [2013-11-28 16:28:58] ...retry after 30 seconds [Thu Nov 28 16:29:21 2013] [error] [client 173.201.45.104] [2013-11-28 16:29:21] Binding thread 0 to cpu 0 [Thu Nov 28 16:29:28 2013] [error] [client 173.201.45.104] [2013-11-28 16:29:28] Stratum connection failed: Failed connect to 216.230.103.42:3333; Connection refused
2
Вы можете начать с добавления соответствующего IP-адреса или диапазона адресов в черный список брандмауэра. Кроме того, если вы можете определить, какие порты используются, вы можете закрыть их. Это по крайней мере поможет вам лучше изолировать ситуацию. root 10 лет назад 0
Просто несколько пояснений, нет ситуации, когда майнинг должен использовать такую ​​большую пропускную способность. Я знаю, потому что я энтузиаст криптовалюты. Кроме того, майнинг с использованием флага `scrypt` - это не биткойн, а лайткойн или какая-то другая разница. Возможно, вы захотите взглянуть на другие вещи, которые могут быть причиной высокой пропускной способности. Проверьте ваши журналы, чтобы увидеть, как пользователь / бот ssh'd на вашей машине. Никогда не разрешайте вход с правами root и устанавливайте fail2ban. kobaltz 10 лет назад 1
Ну, вы видите строку «сохранение в sh» и предыдущие строки после? Я нашел много таких, которые заканчиваются в 100M, и довольно много из них. Кроме того, сервер - это сервер разработки, который не используется ни для чего, кроме размещения сайтов в производстве. Нет средств массовой информации, доступных для загрузки с любого из этих сайтов, так как они еще не имеют контента, так что я думаю, что это тот парень Mud 10 лет назад 0
Ваш лучший вариант. Ядерный сервер с орбиты. Если это не вариант, начните с обновления каждой работающей службы до текущей версии, измените свой корневой пароль и заблокируйте все IP-адреса в соответствии с указаниями, опубликованными соколом. Ramhound 10 лет назад 1
@ Грязь Одна вещь, которую вы должны спросить себя: какая из служб, которыми я пользуюсь, не совсем актуальна? Исправление этой дыры имеет первостепенное значение, потому что она оставляет вас открытыми только для эксплойтов нулевого дня (или местонахождения), которые, как правило, зарезервированы для целей высокой ценности. MariusMatutiae 10 лет назад 0

2 ответа на вопрос

1
falconspy

I'd first block the connection to the external addresses using the iptables

iptables -A OUTPUT -d IP_Address -j DROP

Once you've made sure all the IP Addresses are being blocked, save the iptables: # /sbin/service iptables save then clean up the files placed by the hijacker.

You may want to look at /etc/var/log/messages and /etc/var/log/secure to see if there are any entries left by the hijacker that may indicate how he/she may have grabbed a foothold on your server.

If you are running a website, make sure you don't have any web pages that allow users to upload files like PHP shells.

This should get you started. You can also ask your hosting provider to perform an antivirus scan to look for any scripts / files that allow access.

Спасибо, я попробую. Я видел, что было много запросов для несуществующих файлов, а также они продолжали работать с папкой php-cgi. Это похоже на бота, но потом я увидел строку "Stratum" в ошибках и последовал за этим потоком. Mud 10 лет назад 0
hmm / sbin / service iptables save возвращает: -bash: / sbin / service: такого файла или каталога нет Mud 10 лет назад 0
введите `which iptables` в окне терминала. Он будет отображать местоположение двоичного файла falconspy 10 лет назад 0
Боже - / sbin / iptables :) Спасибо Mud 10 лет назад 0
Нет проблем! Если вы хотите, я также могу выполнить базовое сканирование безопасности вашего сервера позже, если хотите. Вы также можете сделать это самостоятельно (рекомендуется). Отличным инструментом для использования является Nessus, который встроен в Backtrack / Kali falconspy 10 лет назад 0
Спасибо falconspy, я могу предложить вам это предложение - в настоящее время я просто создаю резервные копии всех наших данных разработки и собираюсь стереть сервер и переустановить ОС. Я был бы признателен, если бы вы могли помочь мне установить некоторые стандарты безопасности. Когда серверы были изначально куплены и настроены - с ними ничего не было поделано. Я первый системный администратор, который на самом деле выполнял работу системного администратора. Так что мы сидим здесь с широко расставленными ногами в течение долгого времени, и я хотел бы положить этому конец. Mud 10 лет назад 0
Конечно, если хотите, отправьте мне электронное письмо на aluvshis@outlook.com falconspy 10 лет назад 0
0
user280772

Your bots miners aren't connecting, so it keeps re-running the exploit and downloading the miners over and over and over.

We recently saw an exploit attempt of bad cgi-bin settings that looks related.

It was attempting to download

74.208.228.113 / a

and execute that as a shell script.

That script does a few things when we looked at it, it wiped out the crontab entry and replaced it with an attempt to run a script pulled from

74.208.228.113 / update

It also places the same script in /etc/cron.hourly

That script does a 'ps x' and greps for a successful miner connection. If it doesn't see it, it downloads the a script again and re-runs.

At the very end of the a script, it grabs

74.208.228.113 / clamav

and 

74.208.228.113 / sh

which look to be differently compiled versions of minerd. It renames the clamav to bash and then launches both mining at 216.230.103.42.

So, if you were exploited in a similar manner, you need to:

  1. disable cgi-bin

  2. check the crontab for whatever user runs httpd (likely root or apache) and delete the "update" entry

  3. check /etc/cron.hourly/ for a file called update and see if it references the 216.230.103.42 that the miners cannot connect to. Delete that one to

It's those update entries that are using the bandwidth. The crontab one is running once a minute, every minute.

However, I think a better answer is to nuke it from orbit. If your cgi-bin is set to allow remote exploits that run scripts, there's no guarantee

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