RootForum Community

Morgähn,

nun ist es passiert, irgendwelche *** haben unseren Rootserver bei 1und1 gehakt.

Als wir es gemerkt haben lief gerade irgendein Pack-Porgramm.

Der Server hatte Suse 10 und Plesk drauf, allerdings hat das Rückspielen des BAckups leider nicht funktioniert. Keine Ahnung warum, bin da leider Laie. Unser Dienstleister wird jetzt das System komplett neu aufsetzen und wir spielen die Daten manuell aus dem Backup ein. Ist zwar langwierig, aber bevor wir noch nen weiteren tag offline sind... [-o< #-o

Wir haben nach dem Einbruch auch nochmal ein Backup gemacht - meint Ihr es macht Sinn hier Strafanzeige zu stellen oder ist das eher sinnlos?

matzewe01 hat Recht, Ihr solltet zumindest herausfinden wie der Angreifer auf das System gelangt ist um hier gegebenenfalls die Sicherheitslücke zu schließen.
Naja, die Spezialisten bei der Kripo sind meist leider nicht so gut ausgebildet wie man denkt.

guenni81 wrote:matzewe01 hat Recht, Ihr solltet zumindest herausfinden wie der Angreifer auf das System gelangt ist um hier gegebenenfalls die Sicherheitslücke zu schließen.

Richtig, das Wie ist das Wichtigste, der Rest ist optional.

guenni81 wrote:Naja, die Spezialisten bei der Kripo sind meist leider nicht so gut ausgebildet wie man denkt.

Leider trifft das noch auf viele Kriminalpolizeidienststellen zu, aber nicht auf alle. Spätestens bei der jeweiligen Landeskriminalpolizei findet man durchaus fähige Spezialisten, nur die bearbeiten (glücklicherweise) nicht jeden "Kleinkram".

Woran stellt ihr fest, dass ein Server gehackt worden ist?

Ich schreib mal was mir einfällt und worauf ich prüfen würde.

Analyse der Logfiles

• /var/log/auth.log
  -> bruteforce auf diverse Dienste
• /var/log/syslog
  -> Firewall Log (falls entsprechende Log Regeln in iptables implementiert wurden)

Welche (potentielle) Einfallswege (außer veraltete Software, für die Exploits existieren) gibt es noch und wie bekommt man sie heraus?

Und vielleicht noch eine Liste möglicher Sicherheitsmaßnahmen:

• iptables (firewall)
  • Vielleicht als kleine Erweiterung knockd :)
• Sichere Konfiguration
  • wohlbedachte Konfiguration von Diensten
• Dateizugriffsrechte
• SSH
  • RSA/DSA Keys statt manuelle Passworteingabe
  • PermitRootLogin = no
  • Für ganz Harte: Zugriff von * abweisen. Stattdessen via VPN darauf verbinden...
• Für jeden Dienst ein eigenen Jail einrichten (BSD/Solaris), Jails abschotten. Alternative für Linux: OpenVZ

Gibt's noch mehr? :)

mightyalex wrote:Woran stellt ihr fest, dass ein Server gehackt worden ist?

...
- Monitoring der Log-Dateien (z.B. logwatch)
- Intrusion-Detection (z.B. tripwire, snort, ...)
- Monitoring des Systems (z.B. nagios, zabbix, ...)

mightyalex wrote:Welche (potentielle) Einfallswege [...] gibt es noch und wie bekommt man sie heraus?

- schlechte Passwörter, bruteforce
- unverschlüsselte Datenübertragung bzw. man in the middle
- phishing, ...

mightyalex wrote:Und vielleicht noch eine Liste möglicher Sicherheitsmaßnahmen:

- sichere Passwörter
- regelmäßige Updates
- PAX, GRSecurity, SElinux, AppAmor, ... (gehärtete Linux-Distributionen, OpenBSD, ...)
- Intrusion Detection
- Proxy, Application Firewall
- Pentesting der eigenen Systeme

Wie kann man von jeder Datei auf dem System eine Prüfsumme speichern, versionieren und den Zustand zweier "Dateisystemzustände" vergleichen?

Und wie heißt das Programm (es ist in Python geschrieben), das eine iptable rule setzt nach dreimaligen fehlerhaften Login? (Die Dienste, die gemonitored werden, konnten via conf erweitert werden)

Zunächst sollte man sich darüber klar werden, welche Dienste und Applikationen man zwingend benötigt. Alles was darüber hinaus geht, hat auf dem System nichts zu suchen.
Als Nächstes speckt man die benötigten Dienste und Apps auf das absolut Nötigste ab und sorgt für eine saubere, lesbare und sichere Konfiguration. Dann überlegt man sich ob und wie diese Dienste und Apps überwacht werden müssen (ein sauber konfigurierter SSHd muss zum Beispiel nicht extern überwacht werden, standard-logging reicht in der Regel).
Nun muss man eigentlich nur noch für ein geeinetes Auswerten der Überwachungsdaten sorgen und eventuellen Abnormalitäten zeitnah nachgehen.

Hört sich einach an, oder? Pustekuchen!

Fangen wir mal als Gruppenarbeit mit einem einfachen Beispiel an:
Es soll ein vollfunktionierendes phpBB3-Vanilla für eine kleine Community angeboten werden.

Welche Dienste und Applikationen werden benötigt?
Welches Betriebssystem bietet die günstigste Basis?

...

All das macht auch gleich das nächste Problem auf: Das hier beschriebene Wissen über den eigenen Server ist mit GUI-Tools a la Webmin,Plesk & Co nicht zu erreichen, wenn man das gleiche nicht auch auf der Konsole einrichten könnte.

Mein ehemaliger Arbeitgeber nutzte (und nutzt es wahrscheinlich heute noch) das günstigste vServer Paket. Gerade mal genug Platz für das Betriebssystem vorhanden und einige PHP Scripts. (Ich war leider nur Azb. FISI)

Da die GUI (Plesk) nicht laufend aktualisiert wurde mussten ältere Distributionen (SuSE) eingesetzt werden, die dann irgendwann out of life war.

Backups sollte man schon realisieren. Aber

1. Nicht auf dem gleichen Host! (Festplattencrash???, versehentliches Überspeichern)
2. GUI = Pfui. Auf Webmin, Plesk etc. sollte verzichtet werden...

Das Ende vom Lied war sogar, dass Plesk die Config in eine MySQL-DB speicherte. Der geringe Platz war dann zu klein als der Admin auf die Idee kam ein Backup zu machen, Plesk startete nicht mehr und das Backup mit Plesk konnte nicht eingespielt werden, da Plesk nicht mehr da war. \:D/


Danke für die Tipps um ein System sicherer zu machen. Gerade lese ich ein wunderschönes Buch über Snort, Acid & Co. :)


Vielleicht sollte man irgendwie aus den Infos ein Sticky machen. "Möglichkeiten zur Absicherung eines *NIX Systems"
Das Posting dafür mach ich gerne, soll ich?

Ich hab da mal ein bisschen was gemacht. http://www.rootforum.org/wiki/Security :)