Ports öffnen nur über das Dateisystem

[IRDC]

Hallo,
auf meinem Debian Buster Webserver wurden gestern scheinbar Systemdateien beschädigt, dies verhinderte einen Neustart. Ich hatte nur noch Dateizugriff auf ein Recoverysystem. fsck hat angeblich einiges repariert, der Boot funktionierte dennoch nicht. Fehlermeldungen, die mir als Screenshot zugeschickt wurden, zeigten defekte Dateien unter /lib/systemd/system/. Ich habe dann viele Dateien in dem Ordner mit Dateien aus einer frischen Buster Installation überschrieben (ich weiß nicht, wie gut das war). Auf jeden Fall fährt der Server jetzt endlich wieder hoch und kann auf Pings antworten, aber laut Hostersupport sind die meisten Ports geschlossen und ich komme entsprechend per SSH nicht drauf. Mir bleibt nur das Recoverysystem um irgendwie per Dateizugriff die Ports zu öffnen. Erste Suchen nach den Firewalleinstellungen blieben erfolglos. Ist das irgendwie möglich? Zur Not wäre auch eine kurzzeitige vollständige Deaktivierung der Firewall ein Ausweg.

[DeletedUserReAsG]

Üblicherweise startet man dann das Recoverysystem, verbindet sich via ssh dorthin, mountet das kaputte System und führt die Reparaturen durch, bevor man’s dann wieder anstelle des Recoverysystems bootet.

Ports haben nix mit dem Dateisystem zu tun, btw.

[IRDC]

Das ist ja das, was ich getan habe, die Reparaturen an den Dateien via Mount der Platten über das Recoverysystem durchgeführt. Nach dem Boot des eigentlichen Systems sind jetzt aber alle Ports dicht und ich kann mich mit dem richtigen System nicht mehr per SSH verbinden. Daher brauche ich einen Weg, das via Recoverysystem zu korrigieren.

[eggy]

Dann wäre erstmal die Frage, läuft der SSH Dienst nicht oder sind die Ports wegen ner Firewall (iptables etc) dicht?

[IRDC]

Die Befürchtung hatte ich auch schon. Ich weiß leider nicht, wie ich das herausfinden kann.

[DeletedUserReAsG]

Nach dem Boot des eigentlichen Systems sind jetzt aber alle Ports dicht und ich kann mich mit dem richtigen System nicht mehr per SSH verbinden.

Was gibt nmap (von außen) denn aus? Wenn „filtered“, dann hängt wahrscheinlich eine „Firewall“ dazwischen. Wenn „closed“, besteht eine gute Chance, dass du schlicht deinen sshd fehlkonfiguriert hast, oder es vom systemd nicht gestartet wird. In dem Fall sind Ursachen wahrscheinlich im Log/Journal zu finden, erreichbar vom Recoverysystem aus.

[eggy]

Die Befürchtung hatte ich auch schon. Ich weiß leider nicht, wie ich das herausfinden kann.

Man schaut in die Logs. Und wenn man da nichts findet, dann baut man sich das notwendige Logging halt selbst.

Nimm das jetzt bitte nicht übel, aber wer nicht in der Lage ist, herauszubekommen, ob ein Dienst läuft, der sollte vielleicht lieber besser noch keine öffentlich erreichbaren Server betreiben.

Dass jemand bei Dir einbricht, Dir nen Dienst abschaltet oder auf Deiner Kiste nen paar Dateien löscht, ist da noch das angenehme Szenario. Unangehmer wirds, wenn jemand die Kiste benutzt, um andere Leute mit Spam zu belästigen. Noch schlimmer wenn Deine Kiste für Angriffe auf andere missbraucht wird, dann liegt es nämlich an Dir, nachzuweisen, dass das jemand anderes war. Von Störerhaftung mal ganz abgesehn. Aber so richtig schlimm (für Dich, als verantwortlicher Admin des Servers) wirds, wenn Leute Deinen Server als Datenablage für ihren Dreck nehmen und die Staatsanwaltschaft feststellt, dass das Zeug Dir gehört.
Falls Dir 184b (3) nichts sagt, https://dejure.org/gesetze/StGB/184b.html bereits der Besitz von bestimmten Dateien ist strafbar. Gibt im StGB noch nen paar andere Stellen die man als Admin kennen sollte,

Daher lern bitte erstmal die Grundlagen der sicheren Serveradministration. Zu Hause im Lan, wo die Schäden überschaubar bleiben. Erst wenn Du Dir sehr sicher bist, dass Du es wirklich verstanden hast, ist es Zeit für nen öffentlichen Server. Verstanden bedeutet in dem Kontext übrigens nicht "ich hab ein Video bei Youtube gesehen" sondern "mir ist klar, was die von mir gewählten Optionen tun und welche Auswirkungen das auf die Sicherheit des Gesamtsystems hat und wie die einzelnen Komponten in einandergreifen und vorallem was schiefgehen kann und welche Konsequenzen das hat".

[IRDC]

Das syslog und das auth.log haben zuletzt am Donnerstag um 10:52 einen vernünftigen Eintrag geschrieben, danach folgte nur noch eine Reihe von "^@", was mich vermuten lässt, dass der Rechner danach entgegen der Aussagen des Hostinganbieters nie wieder fehlerfrei hochgefahren ist. Habe ich die Möglichkeit ein boot log schreiben zu lassen?

[DeletedUserReAsG]

Habe ich die Möglichkeit ein boot log schreiben zu lassen?

Eigentlich steht das heutzutage standardmäßig im Journal. Vorausgesetzt natürlich, der journald konnte das nach dem Hochfahren wegspeichern.

[IRDC]

Eine Journal Datei konnte ich nur im Recoverysystem finden. Dafür stieß die Suche auf mehr Fehler im Dateisystem. Ich habe mich innerlich wohl schon damit abgefunden, das System komplett neu aufzusetzen

[TomL]

Das syslog und das auth.log haben zuletzt am Donnerstag um 10:52 einen vernünftigen Eintrag geschrieben,

Ich weiss nicht, welche Schlüsse man daraus ziehen kann.... bei mir gibts diese Dateien nicht mal mehr. Das primäre Logging erfolgt seit Jahren durch systemd mit journald. syslog und auth betrachte ich deshalb hierbei nur als redundante Zweitspeicherungen, die möglicherweise unvollständig sind.... also sind sie m.M.n. eigentlich verzichtbar.

Das Problem ist, dass journdald die Logs in /var/log/journal nicht persistent anlegt, man muss das explizit einrichten. Dann hätte man auch über mehrere Laufzeit-Sitzungen sehr aussagefähige Logs.... über alles, was im System passiert ist. Und ein weiteres Problem ist, dass die Logs aus Gründen einer genannten Revisionssicherheit nicht im Klartext gespeichert sind, man kann/muss die mit journalctl lesen... womit sie aber für mich genauso gut handelbar sind, wir früher syslog. Es ist auch möglich die Logs aus einer chroot-Umgebung oder via Pfad-/Dateiname zu lesen.... aber nur, wenn das Journal persistent eingerichtet wurde. Wären sie nicht dauerhaft gespeichert, würde ich via chroot versuchen, an das der laufenden Sitzung zu kommen.... das müsste sicher vorhanden sein.