Beiträge von .A.

FreeBSD ist mit Linux zum großen Teil binärkompatibel. Du musst da wohl eher Gameserver suchen, die nicht auf FreeBSD laufen.

Zitat von klobi

Ok wenn ich den Recovery hab was dann?

1. Herausfinden, wie der Server kompromittiert wurde.
2. Policies anpassen, um einen erneuten Angriff zu verhindern.
3. Prüfen, ob und welche Daten noch genutzt werden können bzw. auf welches ältere Backup zurückgegriffen werden muss.
4. Server neu aufsetzen und nur unbedenklichen Daten einspielen.

Zitat von klobi

Dachte vielleicht lass ich den mal laufen ne Nacht mit tshark und gucke rein, aber ist halt net so toll weil tshark ja nciht mitloggt welches programm / prozess das Internet nutzt.

Honeypots sollte nur betreiben, wer sehr genau weiß was er tut.

Zitat von klobi

Was meinst du denn mit Syslog?

Der Port 514 hängt im Netz. Damit konnte jeder Deinem Syslog Daten schicken.

Zitat von klobi

Schnell zum PHP-Code, der ist halt in PHP geschrieben und sollte wenn Apache oder PHP nicht dumm ist und die Rohdatei schickt also vor dem Auswerten dann sollte nix geschehen also Daten sollten nicht eingelesen werden können denke ich, es sei denn man kann irgendwie erzwingen dass der Server einem den PHP-Code schickt , das wäre jedoch sehr schlecht.

Sollte die Unkenntnis des PHP-Codes als Sicherheitsmaßnahme gelten, dann ist mit einiger Wahrscheinlichkeit hier ein Angriff möglich.

Zitat von klobi

Wie mein PHP konfiguriert ist kann ich nicht genau sagen , da es sehr viele Zeilen sind aber hauptsächlich sollte es auf Standard sein mit einigen Anpasungen wie short tags oder max filesize und execution time wegen upload

Du kannst alle Kommentare entfernen. Dann sollten auch nur noch die Werte erscheinen, die vom Standard abweichen.

Zitat von klobi

Mysql ist offen im Netz ? Wieso?

Das frage besser den Systemadministrator.

Zitat von klobi

Eventuell war das alte root passwort per bruteforce knackbar, das könnte es sein und dann kann er ja machen was er will, auch logs löschen oder? aber warum dann nicht die auth.logs gelöscht worden sind weiß ich nicht.

Da der Server als kompromittiert anzusehen ist, musst Du davon ausgehen, dass der Inhalt sämtlicher Log-Dateien auf dem Server manipuliert wurde.

Zitat von klobi

Vielleicht auch eine PHP-Seite die per SSH sich auf den Server einloggt und TS3 startet/stoppt/restartet aber dort konnte man keine eigenen Befehle eingeben da alles vorbereitete Strings waren und nur geprüft wurde welches Item der Liste ausgewählt war.
Es sei denn man kann irgendwie raw-php dateien herunterladen aber wenn das geht wäre das ja voll doof, weiß auch gar nicht wie das gehen sollte.

Diese PHP-Seite klingt sehr verdächtig. Kann man den Code irgendwo einsehen? Wie ist Dein PHP konfiguriert?

Hast Du schon den Mysql- und den Syslog-Server geprüft? Beide hingen nach Deinen Angaben in Thread offen im Netz.

Edit: DNS durch Syslog ersetzt, da zu schnell geschaut...

Du kannst davon ausgehen, dass Dein Server kompromittiert ist. Damit sollte dieser nicht wieder ans Netz genommen werden. Jetzt ist folgendes zu tun:
1. Herausfinden, wie der Server kompromittiert wurde.
2. Policies anpassen, um einen erneuten Angriff zu verhindern.
3. Prüfen, ob und welche Daten noch genutzt werden können bzw. auf welches ältere Backup zurückgegriffen werden muss.
4. Server neu aufsetzen und nur unbedenklichen Daten einspielen.

Zitat von funny13

Ich habe gelesen, dass man bei einer SSD besser auf die SWAP Partition verzichten sollte, ist das richtig?

Für Deinen Einsatzzweck wird grundsätzlich kein Swap benötigt. Ohne Swap-Partition hast Du aber auch im Ausnahmefall keinen Swap. Kommst Du damit zurecht?

Zitat von funny13

/boot 500MB
/(root) 3GB

Das sollte für die gewünschten Programme eigentlich reichen. Hier solltest Du für Dein Betriebssystem prüfen, ob dieses mehr Platz benötigt.

Zitat von funny13

/var Größe?

Betriebssystemabhängig wird hier verschieden viel Platz benötigt.

Zitat von funny13

/var/log 1GB
/var/tmp 1GB

Was soll denn da hin? 100 MB reichen zumeist vollkommen.

Zitat von funny13

/opt 1GB

Was soll da hin? Brauchst Du dort überhaupt Platz?

Zitat von funny13

/home Größe?

Was soll dort hin? Zumeist reichen 100 MB pro System-Benutzer.

Zitat von funny13

/srv Größe?

Was soll hier hin?

Mal abgesehen davon, dass SSH-Tunnel nichts für den produktiven Einsatz sind, hast Du die üblichen Verdächtigen ausgeschlossen: TCPKeepAlive, ServerAliveInterval und alle NATs auf der Strecke?

Wie sieht denn der MBR von /dev/sda aus (z.B. dd if=/dev/sda count=1 | xxd)?

dd macht nur Probleme, wenn die Festplatte auf dem Zielsystem kleiner ist.

Zitat von meisterlampe00

Code

Disk /dev/sda doesn't contain a valid partition table

Bist Du sicher, dass die gewünschten Daten auf /dev/sda vorhanden sind?

Du kannst mit rsync und dd die komplette Festplatte übertragen. Die paar Konfigurationsdateien zu ändern, ist nicht so schwer.

Künftig solltest Du Dir ein Bare-Metal-Recovery bereitlegen (z.B. Relax-and-Recover - Linux Disaster Recovery). Dann sind hier keine Probleme mehr zu erwarten.

Wie sieht die Partitionstabelle aus?

Wenn wir zum Ausgangsthema zurückkehren: Was ist beim OP Mittwoch kurz nach 12 Uhr gelaufen? Dort gibt es für eine längere Zeit einen Unterschied (hohe IOWait bei gleichzeitig erhöhten Durchsatz).

Ist dieser Prozess auch für einige weitere Ausschläge verantwortlich?

Zitat von peng

Kann mir jemand von Euch sagen wie ich hier am besten mit der Fehlersuche starte?

Mit den Logs. Was macht der Server zuletzt vor dem Einfrieren?

Ask the admin which program opened it and stop this/theese program(s).

Could you shut down the tun interfaces and check conectivity again.

Auf solche Messungen wirken sich unterschiedliche Faktoren aus:
a) Caching; zum einen "lokal" innerhalb der virtuellen Maschine, zum anderen extern auf dem Storagesystem
b) Zeitmessung; Bist Du sicher, dass die Zeit korrekt gemessen ist, selbst wenn der Host zwischendrin eine andere virtuelle Maschine rechnen lässt?
c) Dateisystem: Mit Caching werden Daten nicht sofort geschrieben. Aber wenn Daten geschrieben werden, bisweilen mehr als eigentlich an der Reihe wären. Dann hat das Dateisystem aber jeweils verschieden lange Zeit zu erkennen, dass kein Inhalt in Deinen Dateien ist, und die Daten mit Löchern ("wo nichts ist, schreibe ich auch Nichts") oder komprimiert ("beim Lesen hier 84.000.000 Mal '0' ausgeben") zu schreiben.
d) CPU-Affinität: Wie oft wurde die für das Schreiben verantwortliche CPU gewechselt und die neue CPU musste erst den Zwischstand des Vorgangs laden?
e) Zulieferung der Test-Daten: Wurden die zu schreibenden Daten wirklich ausreichend schnell zur Verfügung gestellt (bei /dev/zero eher kein Problem)?
f) Fragmentierung: Muss der virtuelle Gast auf der virtuellen Festplatte erst Platz zusammenstückeln? Muss das Storage-System Platz zusammensuchen?

D.h. mit diesen Messdaten kann man nicht mal erkennen, dass überhaupt ein Flaschenhals besteht. apt-get install ist für die Messung eher nicht geeignet, da es keine typische Aufgabe des Servers ist oder betreibst Du einen Debeian-buildd? Der Debian-Boot-Prozess hat an einigen Stellen sehr lange Wartezyklen drin.

Du hast ohnehin ein Monitoring laufen, damit solltest Du mal eine Langzeitmessung vornehmen: Was dauert bei Websites lang. Gibt es Ausreißer? Wann? Wie viele?

Zitat von Friedel

UsePAM yes
ChallengeResponseAuthentication no

Wenn hier ChallengeResponseAuthentication erlaubt würde, was auch der Standardwert ist, kann sich je nach PAM-Konfiguration root unabhängig von PermitRootLogin anmelden.

Zitat von Friedel

PasswordAuthentication ist auskommentiert (#PasswordAuthentication yes)

Damit steht es auf dem Standardwert yes.

Das war jetzt so mein erster Gedanke, warum root sich trot PermitRootLogin noch anmelden kann. Es gibt noch einige weitere Wege, die aber nicht ganz so geradlinig sind.

Zitat von Friedel

Der Server ist übrigens neu. Ich habe ihn in erster Linie zum lernen.

Ein Server im Internet ist nicht zum Lernen da. Dazu nutzt man eine lokale Maschine.

Wie sind denn die Werte von

UsePAM
ChallengeResponseAuthentication
PasswordAuthentication

Wie ist ggf. PAM konfiguriert?

Zitat von rellik

Stimmt da was mit den DNS einstellungen nicht?

Habe:
@ A ServerIP
mail A ServerIP
@ MX 10 mail.domain.com.

Die letzte Zeile darf nicht auf mail.domain.com. zeigen, sondern muss Deine Domain beinhalten. Am einfachsten gibst Du die Domain relativ an mit

@ IN MX 10 mail