Woher weiß ich, ob mein Linux-Server gehackt wurde?

Lösung 1:

1. Bewahren Sie eine unberührte Kopie auf von kritischen Systemdateien (wie ls, ps, netstat, md5sum) irgendwo, mit einer md5sum von ihnen, und vergleiche sie regelmäßig mit den Live-Versionen. Rootkits verändern diese Dateien ausnahmslos. Verwenden Sie diese Kopien, wenn Sie vermuten, dass die Originale manipuliert wurden.
2. Helfer oder Stolperdraht informiert Sie über alle Dateien, die geändert wurden - vorausgesetzt, ihre Datenbanken wurden nicht manipuliert.
3. Konfigurieren Sie Syslog so, dass Ihre Protokolldateien an einen entfernten Protokollserver gesendet werden wo sie nicht von einem Eindringling manipuliert werden können. Überwachen Sie diese Remote-Protokolldateien auf verdächtige Aktivitäten
4. Lesen Sie Ihre Protokolle regelmäßig - verwenden Sie logwatch oder logcheck um die kritischen Informationen zu synthetisieren.
5. Kennen Sie Ihre Server . Wissen, welche Arten von Aktivitäten und Protokollen normal sind.

Lösung 2:

Du nicht.

Ich weiß, ich weiß - aber es ist wirklich die paranoide, traurige Wahrheit;) Es gibt natürlich viele Hinweise, aber wenn das System speziell angegriffen wurde - könnte es unmöglich sein, es zu sagen. Es ist gut zu verstehen, dass nichts jemals vollkommen sicher ist. Aber wir müssen für mehr Sicherheit arbeiten, also werde ich stattdessen auf alle anderen Antworten verweisen;)

Wenn Ihr System kompromittiert wurde, kann keinem Ihrer Systemtools vertraut werden, dass es die Wahrheit preisgibt.

Lösung 3:

Tripwire ist ein häufig verwendetes Tool – es benachrichtigt Sie, wenn sich Systemdateien geändert haben, obwohl Sie es natürlich vorher installiert haben müssen. Ansonsten sind Dinge wie neue Benutzerkonten, die Sie nicht kennen, seltsame Prozesse und Dateien, die Sie nicht erkennen, oder erhöhte Bandbreitennutzung ohne ersichtlichen Grund die üblichen Anzeichen.

Andere Überwachungssysteme wie Zabbix können so konfiguriert werden, dass sie Sie benachrichtigen, wenn Dateien wie /etc/passwd geändert werden.

Lösung 4:

Einige Dinge, die mir in der Vergangenheit einen Tipp gegeben haben:

• Hohe Last auf einem System, das im Leerlauf sein sollte
• Seltsame Segfaults, zB. von Standarddienstprogrammen wie ls (dies kann bei defekten Rootkits passieren)
• Versteckte Verzeichnisse in / oder /var/ (Die meisten Drehbuch-Kiddies sind zu dumm oder zu faul, um ihre Spuren zu verwischen)
• netstat zeigt offene Ports, die nicht da sein sollten
• Daemons in der Prozessliste, von denen Sie normalerweise verschiedene Varianten verwenden (z. B. bind , aber Sie verwenden immer djbdns )

Außerdem habe ich festgestellt, dass es ein zuverlässiges Zeichen dafür gibt, dass eine Box kompromittiert ist:Wenn Sie ein schlechtes Gefühl bezüglich der Sorgfalt (mit Updates usw.) des Admins haben, von dem Sie ein System geerbt haben, behalten Sie es genau im Auge!

Lösung 5:

Es gibt eine Methode, gehackte Server über kill zu überprüfen -

Wenn Sie "kill -0 $PID" ausführen, senden Sie im Wesentlichen ein nop-Signal an die Prozesskennung $PID. Wenn der Prozess ausgeführt wird, wird der Kill-Befehl normal beendet. (FWIW, da Sie ein Nop-Kill-Signal übergeben, wird dem Prozess nichts passieren). Wenn ein Prozess nicht läuft, schlägt der Kill-Befehl fehl (Beendigungsstatus kleiner als Null).

Wenn Ihr Server gehackt / ein Rootkit installiert wird, ist eines der ersten Dinge, die es dem Kernel mitteilt, die betroffenen Prozesse vor den Prozesstabellen usw. zu verbergen. Es kann jedoch alle möglichen coolen Dinge im Kernel-Bereich tun, um damit herumzuspielen Prozesse. Das bedeutet also, dass

a) Diese Prüfung ist keine umfassende Prüfung, da die gut codierten/intelligenten Rootkits sicherstellen, dass der Kernel mit einer „Prozess existiert nicht“-Antwort antwortet, wodurch diese Prüfung überflüssig wird. b) So oder so, wenn ein gehackter Server dies getan hat Wenn ein "schlechter" Prozess läuft, wird seine PID normalerweise nicht unter /proc angezeigt.

Also , wenn Sie bis jetzt hier sind, besteht die Methode darin, jeden verfügbaren Prozess im System mit -0 zu beenden (alles von 1 -> /proc/sys/kernel/pid_max) und zu sehen, ob es Prozesse gibt, die ausgeführt werden, aber nicht gemeldet werden /proz.

Wenn einige Prozesse ausgeführt werden, aber nicht in /proc gemeldet werden, haben Sie wahrscheinlich ein Problem, egal wie Sie es sehen.

Hier ist ein Bash-Skript, das all das implementiert – https://gist.github.com/1032229 . Speichern Sie das in einer Datei und führen Sie es aus. Wenn Sie einen Prozess finden, der nicht gemeldet in proc auftaucht, sollten Sie einen Anhaltspunkt haben, um mit dem Graben zu beginnen.

HTH.