Fedora: Verschlüsselter VPS seltsamer Reboot

[CyberNation_RX]

Hallo zusammen,

heute morgen habe ich bemerkt, dass ich mich nicht mehr in meinen VPN einloggen konnte. Grund dafür war, das mein VPS neugestartet war (Fedora Server 24). Die komplette HDD des VServer ist verschlüsselt mit LUKS, entschlüsselt wird diese über einen dropbear SSH server.
https://github.com/mk-fg/dracut-crypt-sshd

Nach dem entschlüsseln konnte ich keine Zeichen eines Reboots in den Logs finden:
/var/log/boot.log
/var/log/messages
/var/log/secure
/var/log/wtmp

Die Logs 'messages' und 'secure' enden abrupt mit fehlgeschlagen ssh-login versuchen. Kann- es sein, dass der Anbieter meines VPS versucht hat einzudringen und das initramfs Modul zu manipulieren um an das Passwort der verschlüsselten Partition zu kommen? In diesem Fall hätte er nämlich jetzt dieses. Ich hätte wirklich trapwire installieren sollen

Hat jemand Tipps wie ich weiter vorgehen soll?

 

[Ozzy83]

Erst mal logische analysen betreiben. Nach wie vielen Versuchen blockt der login? Wurde danach weiter probiert? Wem gehören die IPs ? Usw.

 

[CyberNation_RX]

@Ozzy83
Ich gehe nicht vom einem Angriff über SSH aus, es sind zwar in den letzten Wochen über 100.000 fehlgeschlagene Logins, aber mein Passwort und Keyfiles sollten sehr sicher sein. Sollte den SSH-Server trotzdem mal auf einen anderen Port setzen. Habe natürlich trotzdem auf neue User und ausfällige Änderungen gecheckt, laut 'last' ist aber auch alles okay.

Meine Befürchtung ist, dass der Anbieter meines VPS versucht auf meine Daten zuzugreifen und deshalb die unverschlüsselte Bootpartition manipuliert hat um an das Passwort für LUKS zu kommen.
Mir ist natürlich klar das er noch deutlich mehr Angriffsmöglichkeiten hat, wenn er RAM und CPU kontrolliert. Allerdings sollte es bei LUKS selbst mit einem Speicherabbild nicht so leicht sein an die Passphrase zu kommen.

 

[Snowiron]

Ich wüsste nicht, wieso er erst die Bootpartition manipulieren sollte. Du hast das Speicherabbild ja schon bereits angesprochen. Das kann er Ruckzuck machen und den entsprechenden AES-Key auslesen mittels entsprechender Software. Kann natürlich sein, dass er solche Software nicht zur Verfügung hat, da sie ihm zuviel kostet. Interessant wäre sonst zu wissen, welcher Anbieter und welche Art von Daten sich darauf befinden. Sofern Ermittlungsbehörden hinter den Daten her sind, würden die denke ich einfach ein komplettes Abbild vom Livesystem bekommen und lesen mit entsprechender, forensischer Software den passenden Key aus dem RAM aus.

 

[CyberNation_RX]

@Snowiron,
soweit ich weiß, ist das gar nicht so einfach den Key aus dem RAM zu lesen, wenn entsprechende Sicherheitsfunktionen aktiv sind. Aber ich denke du hast Recht es wäre in diesem Fall vermutlich die beste Angriffsmöglichkeit.

Trotzdem würde ich gerne wissen, was letztendlich den Neustart verursacht hat. Es muss doch irgendwie Möglichkeiten geben, die Ursache zu trennen oder? Selbst beim harten Reboot, müsste er ja das Journal des FS abarbeiten oder?