Meine Server-ToDos: grundlegende Einrichtung von Sicherheitfeatures, Backups, Updates und Weiteres

Wenn Du das Video unterstützen willst, dann gib bitte eine Bewertung ab, und schreibe einen Kommentar. Vielen Dank!
Links:
-Github Servereinrichtung: github.com/Jean28518/linux-gu...
-SSH-Schlüssel: • SSH auf Linux Server s...
-SSH-Schlüssel in KeePassXC: • KeepassXC SSH-Agent: S...
-KeePassXC allgemein: • Passwortmanager KeePas...
-BackUp System einrichten: • BackUp System einricht...
- Linux-Guides Merch*: linux-guides.myspreadshop.de/
- Linux-Support: www.linuxguides.de/linux-supp...
- Hauptkanal: / @linuxguides
- Projekt-Webseite: www.linuxguides.de/
- Jeans Webseite: www.jf-vogelbacher.de/
- Jeans Github-Account: github.com/Jean28518
Inhalt:
-------------------------------------
0:00 Begrüßung
0:25 Secure Shell (SSH) Zugang
2:49 Aktualisieren
4:01 Server umbenennen
5:32 SSH-Schlüssel hinzufügen und Passwort deaktivieren
7:46 fail2ban
8:32 Automatische Sicherheitsupdates
9:35 Firewall
10:28 Automatische Reboots
13:11 log-limit setzen
14:22 Automatische Backups
15:28 Automatische Backups manuell einrichten
22:20 Einschub Mail einrichten (zur Backup-Bestätigung)
26:00 Backups einrichten (Fortsetzung)
29:54 Backups wiederherstellen
32:14 Verabschiedung
Haftungsausschluss:
-------------------------------------
Das Video dient lediglich zu Informationszwecken. Wir übernehmen keinerlei Haftung für in diesem Video gezeigte und / oder erklärte Handlungen. Es entsteht in keinem Moment Anspruch auf Schadensersatz oder ähnliches.
*) Werbung

[@Green15344]

Gut, das ich das gleiche mache. Danke, dass du das anderen so schön erklärst. Was backups angeht nehme ich lieber restic statt borge aber das ist ja ssehr subjectiv und zum Glück haben wir im Open Source Bereich viele verschiedene Lösungen.

[@BigSmoke_GTA]

sehr interessant. Hab das mal zum üben auf einem Proxmox LXC nachgemacht.

[@DieterFrueh-cp1go]

Mit hostname gibt es einen trick bzw der befehl macht meistens den hostname nur zur ansicht... Wenn man das komplett ändern will hab ich es immer über die files gemacht

[@DrCox-xx8tu]

Schade, dass du gerade das mit der Mail nur kurz anreißt und nicht die funktionierende config (wenn auch mit geblurrten Daten) zeigst. Genau der Mailversand zickt bei mir nämlich immer rum. Habe z.B. auch den Fehler wie bei dir, dass `mail -a` die Mail nicht rausschickt sondern das Terminal zerschießt.

[@recalion]

Was ist mit Crowdsec als neue Alternative zu fail2ban?

[@DieterFrueh-cp1go]

Mails als benachrichtigungssystem finde ich persönlich bisschen outdatet

[@user-zk2st6nx1p]

Ergänzung: Windows kann auch nativ SSH!

[@chris23tr]

als dauer root würde ich nicht machen, auch mit der cert anmeldung

[@mikeeisenberg8244]

Lässt sich darüber streiten. Wenn jemand deine Public-Key-Authentifizierung umgehen kann, dann wird für ihn auch kein bruteforce des root passwords eine Hürde sein. Während du als Administrator sich dauerhaft den extra Weg über Sudo gehen musst. Und wenn du einen reinen Serverbetrieb hast, dann musst du dich zwangläufig eh immer als Root Authentifizierung, damit ist die Sicherheit in gewissermaßen auch hinfällig. Anders natürlich, wenn du einen Desktop hast auf dem du aktiv arbeitest / webbrowsing machst. Sinnvoller meiner Meinung nach ist eine 2-Faktor-Authentifizierung via TOTP.

[@maxmustermann9858]

Bringt eigentlich wenig, du brauchst ja Root um irgendwas zu machen. Auch wenn du nen sudo User hast kann der theoretisch einfach den Root Login wieder aktivieren. Lieber den ssh Server vernünftig absichern da gibt’s einiges womit man spielen kann. Man kann glaube den Root Login auch nur von bestimmten IPs erlauben, dann noch nen Rate Limit und ganz wichtig nur sicherer Algorithmen aktivieren.

[@chris23tr]

@@maxmustermann9858 eigentlich sollte man nur mit root arbeiten, wenn man es unbedingt braucht, und Anwendungen sowieso nur mit niedrigen rechte und als extra user

[@LinuxGuidesAdmin]

Ja das mit permit root-Login ist so eine Sache, worüber man lange drüber streiten kann. Für mich ist das eine zusätzliche geringe Hürde, die mich in Anbetracht des viel umständlicheren Handlings nicht unbedingt überzeugt. Wenn man nämlich das Passwort für den lokalen Root-Login an gleicher Stelle, wie den SSH-Key abspeichert, haben wir auch nicht viel dazugewonnen. (Ganz zu schweigen von den zahlreichen weiteren Sicherheitslücken in der Vergangenheit, die angemeldeten Usern dennoch Administrator-Zugriff gewährt haben) (Natürlich immer die Annahme, das Passwort login per SSH grundsätzlich deaktiviert ist) Am Ende vertraue ich der Pyhsik und der Mathematik hinter RSA und darauf, dass das SSH-Login per Schlüssel sicher und erprobt ist. Sollte eines dieser Dinge nicht gegeben sein, haben wir sowieso ein ganz anderes Problem.. Ich denke man kann in dieser Domäne TOTP mit disabled Root-Login gleichsetzen. Am Ende ist das TOTP auch nur ein "längeres Passwort", welches Zeit-abhängige Codes ausspuckt. Natürlich nochmal eine zusätzliche Hürde, die man gerne aktivieren kann, wenn man möchte. Dafür würde ich aber auch den TOTP Key an einem ganz anderen Ort abspeichern, sonst ist unter meiner obigen Annahme die zusätzliche Sicherheit dafür auch gleich 0. Zusatz: Natürlich, wenn man in dieser Hinsicht mit den zusätzlichen Hürden alles richtig macht, erhöht sich die potentielle Sicherheit nochmal gewaltig. Aber ob es der zusätzliche Aufwand für einen generischen Webserver einem wirklich wert ist, muss jeder für sich selber entscheiden. Und beherbergt man auf diesem Server hochkritische Dienste/Daten, dann würde ich sowieso zuerst evaluieren, ob ich überhaupt SSH von außen zugängig mache.

Fail2ban ist auf jeden Fall sinnig. Port Änderung wäre auch noch möglich.