Ehrlich gesagt verstehe ich den Zweck des Ganzen nicht wirklich. Also statt dem User Root haben wir jetzt einen anderen User mit Root-Rechten. Das verhindert doch unterm Strich nur, dass jemand es mit root@server versucht sich einzuloggen. Ich würde eher den Zugang mit Username und Passwort zum Server generell deaktivieren und nur noch die Anmeldung per Keypair zulassen.
Danke für deinen konstruktiven Kommentar. Das habe ich ja versucht im Video zu erklären. Es geht darum, Angriffe per automatisierte Attacken zu minimieren. Hier wird als Standardbenutzer entweder ''root oder 'admin' im Script hinterlegt. Bei dem Zugang per Schlüsselpaar bin ich ganz deiner Meinung und kommt ja auch im nächsten Video als Thema. Ich kann die Schritte der Absicherung eines Linux-Servers zeitlich nicht in einem Video unterbringen, weil sich das keiner bis Ende anschauen wird. Beste Grüße Marcel
@@secure_bits Ja aber ganz ehrlich wenn sich dein (Root) User Bruteforcen lässt dann hast du eindeutig mehr Probleme als den Usernamen. Dann hattest du ein wirklich schlechtes Passwort und offensichtlich kein Fail2Ban oder generell irgendeinen IP-Filter aktiv. Im schlimmsten Fall könnte man sogar behaupten, dein Video ist kontraproduktiv, da deine Methode jetzt eine Form der Sicherheit vermittelt die eigentlich gar nicht gegeben ist. Statt den Schlüssel unter der Fußmatte zu verstecken, liegt er jetzt unterm Blumentopf... Also warum nicht gleich bessere Sicherheitspraktiken erklären?
In der Einleitung des Videos habe ich ja gesagt, dass dieses Video Teil einer neuen Tutorial-Serie ist mit dem Thema 'Linux-Server absichern'. Die Playlist und die dazugehörigen Blog-Posts sind in der Beschreibung verlinkt und in den Blog-Beiträgen sind die Schritte erklärt, inklusive Firewall-Regeln erstellen, automatische Updates konfigurieren, Fail2Ban usw. Es gibt zum Beispiel auch eine Playlist für die Konfiguration der UFW-Firewall hier auf diesem Kanal. Mein Ziel mit dieser Tutorial-Serie ist es, gerade Laien, eine Möglichkeit zu geben, ihre öffentlich erreichbaren Dienste sicher zu betreiben. Daher versuche ich diese Themen auch ausführlich in meinen Videos zu beschreiben. Erfahrene Nutzer wie Administratoren, etc. sollte ich diese Schritte nicht erklären müssen und sind auch hier in dieser Video-Serie nicht meine Zielgruppe. Beste Grüße Marcel
Ich würde ja gerne das bitwarden Derivat Vaultwarden lokal auf meinem Pi hosten und auch von draußen drauf zugreifen, aber ich scheitere an der installation von reverse proxy dingsies, weil ich ja null ahnung hab :D und wenn ich da weiter fummel, dann is am end alles offen wie ein scheunentor, also lass ich das besser sein
Hallo Gordon und Danke für deinen Kommentar! Hierzu werde ich demnächst auch ein Video machen. Aber du hast die richtige Einstellung, wenn es um das Thema Sicherheit geht! Wenn mal alle so handeln würden... ;) Viele Grüße Marcel
Hallo ich bin neu in der Welt von Raspberry Pi etc. Danke für deine Videos, hab gleich mal ein Abo und ein Like dagelassen. Ich bin noch etwas verwirrt da es bei mir etwas anders aussieht mit der Lite Version von Bookworm. Den User Pi gibt es nicht und der User root löst sich nicht löschen. Ich konnte mich auch nicht mit dem root User anmelden. Bei der Installation vom Raspberry Pi OS auf die SD-Karte konnte ich allerdings bereits ein User erstellen welcher auch gleich root Berechtigung hat. Ich hoffe das passt auch so? Ich freue mich auf deine weiteren Videos. Grüsse aus der Schweiz
Hallo Manuel. Vielen Dank für deinen netten Kommentar! Früher war es immer so, dass auf dem Raspberry Pi OS immer 'pi' der Standarduser war. Das ist heute zum Glück anders und man kann das im Imager gleich ändern. Schaue dir auch mal gerne meine anderen Videos zum Thema 'Linux-Server absichern' an, dann weißt du auch, wie du es vermeiden kannst, wie eine Anmeldung gleich mit erhöhten Rechten (root) vermieden werden kann. Ich habe da auch ausführlich einige Beiträge zum Thema auf meinem Blog geschrieben (Links sollten in der Beschreibung sein). Viele Grüße Marcel
Hi Marcel, warum installierst du sudo? Ich lasse auf meinen Systemen sudo komplett weg. Wenn ich administrative Tätigkeiten vornehmen möchte (manuell oder automatisch) mache ich das als root. Das Paket "sudo" ist ausch schon in die Jahre gekommen, hat deutlich zuviel Quellcode und ist in den meisten Fällen nicht wirklich erforderlich. Der schnelle Wechsel vom USer zu root geht dann halt mit "su -" - dürfte so auch in deine Reihe der Systemhärtung passen (ich habe dein zweites Video hierzu als erstes gesehen). Cooles Video - mein Abo hast du 🙂
Hi Markus und Danke für dein Kommentar. Generell bin ich hier bei dir! Aber ich möchte das hier so aufbauen, dass auch im Falle mehrere Benutzer ihrer Privilegien entsprechend am Server arbeiten können. Hat einfach den Hintergrund, dass ich ja nicht weiß wozu sich ein Zuschauer den Server einrichtet und ich damit so sicher gehen kann, dass nur User der entsprechenden Gruppen, entsprechende Rechte auf dem System haben. Wird zum Beispiel ein Nutzer aus der Gruppe 'sudo' entfernt, brauche ich den verbleibenden User kein neues root-Passwort verteilen, da jeder 'hoffentlich' sein eigenes Passwort nutzt (nicht dem root-Passwort entsprechend). Ich hoffe, dass ist irgendwie verständlich erklärt?! ;) Beste Grüße Marcel
Ehrlich gesagt verstehe ich den Zweck des Ganzen nicht wirklich. Also statt dem User Root haben wir jetzt einen anderen User mit Root-Rechten. Das verhindert doch unterm Strich nur, dass jemand es mit root@server versucht sich einzuloggen.
Ich würde eher den Zugang mit Username und Passwort zum Server generell deaktivieren und nur noch die Anmeldung per Keypair zulassen.
Danke für deinen konstruktiven Kommentar.
Das habe ich ja versucht im Video zu erklären. Es geht darum, Angriffe per automatisierte Attacken zu minimieren. Hier wird als Standardbenutzer entweder ''root oder 'admin' im Script hinterlegt.
Bei dem Zugang per Schlüsselpaar bin ich ganz deiner Meinung und kommt ja auch im nächsten Video als Thema.
Ich kann die Schritte der Absicherung eines Linux-Servers zeitlich nicht in einem Video unterbringen, weil sich das keiner bis Ende anschauen wird.
Beste Grüße Marcel
@@secure_bits Ja aber ganz ehrlich wenn sich dein (Root) User Bruteforcen lässt dann hast du eindeutig mehr Probleme als den Usernamen. Dann hattest du ein wirklich schlechtes Passwort und offensichtlich kein Fail2Ban oder generell irgendeinen IP-Filter aktiv.
Im schlimmsten Fall könnte man sogar behaupten, dein Video ist kontraproduktiv, da deine Methode jetzt eine Form der Sicherheit vermittelt die eigentlich gar nicht gegeben ist. Statt den Schlüssel unter der Fußmatte zu verstecken, liegt er jetzt unterm Blumentopf...
Also warum nicht gleich bessere Sicherheitspraktiken erklären?
In der Einleitung des Videos habe ich ja gesagt, dass dieses Video Teil einer neuen Tutorial-Serie ist mit dem Thema 'Linux-Server absichern'.
Die Playlist und die dazugehörigen Blog-Posts sind in der Beschreibung verlinkt und in den Blog-Beiträgen sind die Schritte erklärt, inklusive Firewall-Regeln erstellen, automatische Updates konfigurieren, Fail2Ban usw.
Es gibt zum Beispiel auch eine Playlist für die Konfiguration der UFW-Firewall hier auf diesem Kanal.
Mein Ziel mit dieser Tutorial-Serie ist es, gerade Laien, eine Möglichkeit zu geben, ihre öffentlich erreichbaren Dienste sicher zu betreiben.
Daher versuche ich diese Themen auch ausführlich in meinen Videos zu beschreiben.
Erfahrene Nutzer wie Administratoren, etc. sollte ich diese Schritte nicht erklären müssen und sind auch hier in dieser Video-Serie nicht meine Zielgruppe.
Beste Grüße Marcel
Super Video 👍👍
Vielen Dank! :)
supi Danke Marci Darci 🤣
Gerne!
Ich würde ja gerne das bitwarden Derivat Vaultwarden lokal auf meinem Pi hosten und auch von draußen drauf zugreifen, aber ich scheitere an der installation von reverse proxy dingsies, weil ich ja null ahnung hab :D und wenn ich da weiter fummel, dann is am end alles offen wie ein scheunentor, also lass ich das besser sein
Hallo Gordon und Danke für deinen Kommentar!
Hierzu werde ich demnächst auch ein Video machen.
Aber du hast die richtige Einstellung, wenn es um das Thema Sicherheit geht! Wenn mal alle so handeln würden... ;)
Viele Grüße Marcel
Hallo ich bin neu in der Welt von Raspberry Pi etc. Danke für deine Videos, hab gleich mal ein Abo und ein Like dagelassen. Ich bin noch etwas verwirrt da es bei mir etwas anders aussieht mit der Lite Version von Bookworm. Den User Pi gibt es nicht und der User root löst sich nicht löschen. Ich konnte mich auch nicht mit dem root User anmelden. Bei der Installation vom Raspberry Pi OS auf die SD-Karte konnte ich allerdings bereits ein User erstellen welcher auch gleich root Berechtigung hat. Ich hoffe das passt auch so? Ich freue mich auf deine weiteren Videos. Grüsse aus der Schweiz
Hallo Manuel.
Vielen Dank für deinen netten Kommentar!
Früher war es immer so, dass auf dem Raspberry Pi OS immer 'pi' der Standarduser war. Das ist heute zum Glück anders und man kann das im Imager gleich ändern.
Schaue dir auch mal gerne meine anderen Videos zum Thema 'Linux-Server absichern' an, dann weißt du auch, wie du es vermeiden kannst, wie eine Anmeldung gleich mit erhöhten Rechten (root) vermieden werden kann. Ich habe da auch ausführlich einige Beiträge zum Thema auf meinem Blog geschrieben (Links sollten in der Beschreibung sein).
Viele Grüße Marcel
@@secure_bits Klar ich bleib dran und schaue mal was ich alles umsetzen werde. Mach weiter so, echt gut erklährt😉
Hi Marcel, warum installierst du sudo? Ich lasse auf meinen Systemen sudo komplett weg. Wenn ich administrative Tätigkeiten vornehmen möchte (manuell oder automatisch) mache ich das als root. Das Paket "sudo" ist ausch schon in die Jahre gekommen, hat deutlich zuviel Quellcode und ist in den meisten Fällen nicht wirklich erforderlich. Der schnelle Wechsel vom USer zu root geht dann halt mit "su -" - dürfte so auch in deine Reihe der Systemhärtung passen (ich habe dein zweites Video hierzu als erstes gesehen). Cooles Video - mein Abo hast du 🙂
Hi Markus und Danke für dein Kommentar.
Generell bin ich hier bei dir!
Aber ich möchte das hier so aufbauen, dass auch im Falle mehrere Benutzer ihrer Privilegien entsprechend am Server arbeiten können. Hat einfach den Hintergrund, dass ich ja nicht weiß wozu sich ein Zuschauer den Server einrichtet und ich damit so sicher gehen kann, dass nur User der entsprechenden Gruppen, entsprechende Rechte auf dem System haben.
Wird zum Beispiel ein Nutzer aus der Gruppe 'sudo' entfernt, brauche ich den verbleibenden User kein neues root-Passwort verteilen, da jeder 'hoffentlich' sein eigenes Passwort nutzt (nicht dem root-Passwort entsprechend). Ich hoffe, dass ist irgendwie verständlich erklärt?! ;)
Beste Grüße Marcel
"Who am I" spricht man das aus xd
🤣🙈 Danke dir und ist das peinlich! 😂