D4rkst3r/d4rk_media
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: der Server steht im Rechenzentrum -- das dreht die Bewertung um

Browse Source 
Ich hatte "gleiches Haus" geschrieben und damit die Platte am Router als
halben Schritt abgetan. Falsch: der Rechner ist ein Windows-Root-Server im
Rechenzentrum, bedient von zu Hause ueber mRemoteNG. Ein Ziel beim Betreiber
daheim sind also zwei Gebaeude, zwei Netze, zwei Stromkreise, zwei Anbieter --
besser wird ein Sicherungsziel kaum.

Gemessen, was dafuer schon dasteht:

    sshd        Running, Automatic, 0.0.0.0:22 und [::]:22
    Firewall    "OpenSSH SSH Server (sshd)" -> Allow
    sshd_config Subsystem sftp sftp-server.exe
    je Nacht    d4rk_media 335,9 MB + d4rkbot 0,9 MB = 336,9 MB

Auf der Serverseite fehlt nichts ausser einem Konto, das nur lesen darf. Der
Rest ist ein Skript auf dem Heimrechner, das HOLT statt zu bekommen -- ein
Ziel, in das der Server schreiben darf, ist auch eines, das ein uebernommener
Server loeschen kann.

Fund am Rande: in sshd_config steht kein PasswordAuthentication no. Der
OpenSSH-Standard ist yes -- auf Port 22, offen ins Internet, mit AllowGroups
einschliesslich administrators.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
D4rkst3r
2026-08-12 15:40:31 +02:00
co-authored by Claude Opus 5
parent 6bd1c7a55e
commit 3a89acaa41
2 changed files with 51 additions and 17 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/ideen.md
+42 -15
View File
@@ -138,28 +138,55 @@ die Oberfläche sie nicht ein zweites Mal hinschreibt.
Bei 910 GB frei ist das heute keine Grenze, sondern eine Zusicherung: der
Papierkorb kann nicht mehr unbemerkt zur zweiten Ablage werden.
### Ein Ziel AUSSERHALB dieser Maschine — offen
### Ein Ziel AUSSERHALB dieser Maschine — offen, aber der Weg steht fest
Nachgemessen am 12.08.2026: **es verlässt heute nichts diesen Rechner.** Auch
die Nextcloud nicht — sie läuft hier, in denselben Docker-Volumes, auf
derselben Platte 0 wie die Daten. Details in der ROADMAP.
die Nextcloud nicht — sie läuft hier, in denselben Docker-Volumes, auf derselben
Platte 0 wie die Daten. Details in der ROADMAP.
Gegen einen Plattenausfall ist gesorgt (`D:` ist eine eigene NVMe). Gegen
Feuer, Diebstahl oder eine verschlüsselte Maschine ist es nicht.
Kandidaten, mit dem, was sie wirklich können:
**Wo dieser Rechner steht, ist dabei der entscheidende Punkt**, und er ist mir
zuerst durchgerutscht: es ist ein Windows-Root-Server **im Rechenzentrum**. Der
Betreiber sitzt zu Hause und ist per mRemoteNG verbunden. Das dreht die
Bewertung um — eine Platte zu Hause ist nicht „dasselbe Haus", sondern zwei
Gebäude, zwei Netze, zwei Stromkreise, zwei Anbieter. Besser wird ein
Sicherungsziel kaum.
| Weg | deckt ab | Haken |
|---|---|---|
| **Private PC holt ab** (`robocopy`/`rsync` vom PC aus) | Rechner tot, Server kompromittiert | PC muss laufen, wenn geholt wird |
| **5-TB-Platte am Router** | Rechner tot | gleiches Haus; der Server darf schreiben, also erreicht Ransomware sie auch |
| **5-TB-Platte am Server** | Plattenausfall | dritte Platte im selben Gehäuse, kein Gewinn gegen Feuer |
| **Discord-Kanal** (nur der Bot, 993 KB/Tag) | Haus tot | 9 MB je Datei — für d4rk_media mit 336 MB unbrauchbar |
| **Rechner zu Hause holt ab** | Platte, Rechner, Rechenzentrum, übernommener Server | muss laufen, wenn geholt wird |
| **5-TB-Platte am Router**, vom Heimrechner beschrieben | dasselbe | Router-USB ist langsam; für 337 MB je Nacht reicht es |
| **Discord-Kanal** (nur der Bot) | dasselbe | 9 MB je Datei — für d4rk_media mit 336 MB unbrauchbar |
| 5-TB-Platte **am Server** | nur Plattenausfall | dritte Platte im selben Gehäuse — `D:` kann das schon |
**Die Eigenschaft, auf die es ankommt, ist HOLEN statt SCHICKEN.** Ein Ziel, in
das der Server selbst schreiben darf, ist auch ein Ziel, das ein übernommener
Server löschen kann. Wer die Sicherung vom anderen Ende abholt, hält keine
Zugangsdaten auf der Maschine, die geschützt werden soll.
### Warum HOLEN und nicht SCHICKEN
Ein Ziel, in das der Server selbst schreiben darf, ist auch eines, das ein
übernommener Server löschen kann. Wer vom anderen Ende abholt, hält **keine
Zugangsdaten auf der Maschine, die geschützt werden soll**. Das ist der eine
Unterschied, der im Ernstfall zählt.
### Was dafür schon dasteht
```
sshd Running, Automatic, lauscht auf 0.0.0.0:22 und [::]:22
Firewall "OpenSSH SSH Server (sshd)" -> Allow
sshd_config Subsystem sftp sftp-server.exe
AllowGroups administrators "openssh users" sshusers
AuthorizedKeysFile .ssh/authorized_keys
je Nacht d4rk_media 335,9 MB + d4rkbot 0,9 MB = 336,9 MB
```
**Auf der Serverseite fehlt also nichts** außer einem Konto, das nur lesen darf.
Der Rest ist ein Skript auf dem Heimrechner, das per SFTP zieht und N Stände
behält.
### Ein Fund am Rande, der dazugehört
In `sshd_config` steht **kein** `PasswordAuthentication no`. Der Standard von
OpenSSH ist `yes` — auf Port 22, offen ins Internet, auf einem Server, dessen
`AllowGroups` die **Administratoren** einschließt. Wer ohnehin ein
Sicherungskonto mit Schlüssel anlegt, sollte bei der Gelegenheit auf
Schlüssel-only umstellen.
---