Erste Schritte mit Raspberry Pi OS Lite

[Brati23]

Hallo zusammen

Ich mache gerade meine ersten Versuche mit Raspberry Pi OS Lite auf einem Pi4 Modell B mit dem Ziel ein site to site VPN aufzubauen.
Das OS installiere ich dabei mit dem Raspberry Pi Imager am Win 10 Rechner auf eine 16GB SD Karte. Ich hab mal im Forum gelesen das der Nachteil vom Imager gegenüber anderen Varianten irgendwas ist mit keinen root Ordner zu haben? Bin nicht sicher ob root oder admin oder irgendsowas. Was hat es damit auf sich? Auf Pi-Hole werde ich vermutlich verzichten da ich eh auf jedem Endgerät einen Adblocker laufen habe und YT-Vanced usw. ja auch noch mit dem Loch benötigt werden.

Nach dem aufsetzen vom OS mache ich in der Reihenfolge:

1. Passwort vom Benutzer Pi ändern.
2. Updates.
3. Neuen Benutzer erstellen und Passwort sowie sudo Rechte vergeben.
4. Benutzer Pi löschen.
5. Failtoban installieren und konfigurieren.
6. Wireguard installieren und konfigurieren.
7. Auto Update / Upgrade installieren und konfigurieren.

Fragen:

1. Nachteil(e) Image mit Pi Imager erstellen?
2. Ist es sinnvoll ssh zusätzlich zu härten? Oder ist es mit Failtoban zu vernachlässigen?
3. Ist es richtig das Failtoban in den Standardeinstellungen aus dem eigenen LAN nicht blockt? Wollte es testen aber da Fritz site to site schon steht bin ich schon im "LAN" Da muss ich wohl mal auf dem Telefon mit WLAN aus oder Fritz VPN kurz ausmachen.
4. Wie sind Eure Erfahrungen mit Auto Update und Diensten die danach nicht mehr richtig funktionieren?
5. Port 22 lassen oder ändern? Ein Portscanner hat das schnell raus oder? Ich frage mich immer ob es viel bringt den zu ändern.
6. Habt Ihr sonst noch Sicherheitsvorkehrungen getroffen oder habe ich etwas essenzielles vergessen?
7. Frei Schnauze.

Danke schonmal für Eure Antworten. Grüsse Brati

 

[G-Red]

Ich habe auf meinem VPS ein ssh Fingerprint eingerichtet und das einloggen als root per ssh unterbunden.
Bin dabei deiser Anleitung gefolgt, zumindest was das erstellen des ssh Fingerprint angeht. Den private Key musst du dann aber gut aufbewahren.

 

[Crumar]

5. Ändern. Es bringt keine echte Sicherheit, aber es reduziert die Flut an fail2ban Emails enorm und reduziert die log size.

Hab auf meinem alten vserver täglich mittlere dreistellige bans erhalten, jetzt mit anderem Port sinds ein paar pro monat

 

[Cokocool]

Neuen Benutzer erstellen und Passwort sowie sudo Rechte vergeben.

Passwörter sind doof Nimm lieber ein SSH Key Paar für die Authentifizierung und du kannst ausstellen, dass man sich per PW über SSH anmelden kann.

 

[Kenny [CH]]

Ich hoffe du hast Raspberry Pi OS Lite installiert - alle anderen OS Versionen sind imho zu aufgeblassen und können Sicherheitsrisiken mitbringen - besonders wenn es e nicht benötigt werden würde - z.B. das Gui! Thema: Weniger installierte Packages => Weniger mögliche Fehlerquellen/Bug für den System zugriff!

Ich würde das herunterladen und z.B. mit BelanaEtcher Flashen:
https://downloads.raspberrypi.org/r...1-12/2021-01-11-raspios-buster-armhf-lite.zip

Ein Linux Root Filesystem hat immer die gleiche minimal Struktur. Es gibt z.B. /dev /run /var /mnt /home /root /etc ... >> Zeig dir doch mal die FileStruktur beim system an mit ls / || oder ls -l /

Wichitig hier /root ist das Home Verzeichnis des Root Users
/home sind die Home Verzeichnise der angelegten User

Ein Linux System ohne "root Ordner" würde nicht starten.

Zu deinem Vorgehen - Ich finde es ja eignetlich RICHTIG toll, dass du dein Pi Passwort änderst als Step 1, aber ist ziemlich Unötig, wenn du eh einen neuen User erstellts und den alten User löschst.

SSH und FailToBan kann man machen, mache ich in der Regel nicht - auch die Port änderung mache ich @Default nicht. Port von SSH würde ich auch nur dann ändern, wenn der Pi direkt von Aussen per SSH bedient werden soll. Wenn du SSH nur von Intern oder via VPN erlaubst, kann da fast nichts passieren.

Auto Update/Upgrade sind meistens recht unproblemtatisch, solange du in release updatest (also keine Dist Upgrades etc) machst, sollte in den meisten Fällen das ordentlich Funktionieren. Kenne viele Sysadmins, welche Linux im Rechenzentrum über diese mechanismen jeden abend oder alle paar Tage updaten.

Zu den Sicherheitsvorkehrungen: Da gäbe es einiges, was man noch machen könnte. Eine Möglichkeit die du hast, wäre das OverlayFS zu aktivieren. via Raspberry Pi Configuration -> Performance -> Overlay file system -> Configure --> was macht das? Einfach gesagt, es nihmt dein Root Filesystem und mount dies Komplett als Read-Only, es können keine Changes mehr auf die Disk geschrieben werden und alle changes die gemacht werden werden nur im tmpfs (RAM) zwischen gespeichert - reboot und alle changes sind weg.
Das wird die Lebensdauer der SD Karte Massiv verlängern, benötigt aber für jedes Update einen Reboot, da das OverlayFS erst entfernt werden muss.

Wenn dir Sicherheit super super wichtig ist, kannst du / könntest du auch ein Squashfs als Filesystem mit Live Boot verwenden (Stell dir einfach eine Installer CD vor, das Prinzip wäre das gleiche mit Squashfs). Dies benötigt aber einiges an Setup und hier würde ich empfehlen das Image selbst zu erstellen und nicht auf dem Stock Rasbian aufzubauen. (viel zu Aufwändig und sehr schwer, besonders wenn du ein Squashfs erzeugen möchtest von dem laufenden System -> let me tell you das ist Krebs!)
Wichtig beim Einsatz mit Squashfs - Squashfs ist READ-Only Immer es gibt keine Möglichkeit einfach ein Update einzuspielen in das Squashfs. Es muss quasi eine Updates Squash kreiert werden und von diesem gebootet werden, unsquashen, chroot und wieder squashen würde gehen. Oder du lässt dir von Live System gewisse OverlayFS / Mounts etc anlegen (mehr unten)

Immer noch Paranoid aber kein Bock auf Squashfs weil zu viel hassle? Ein eigener Build kann da immer noch gemacht werden, dann hast du ganz genau unter Kontrolle was du installierst und was nicht. Auch das Pi User Löschen entfällt, da du es in der Hand hast wie der User heisst. (Zusätzlich, kann man den eigenen Build auch gleich mit LVM - Logical Volume Manager - Konfigurieren. IMHO: LVM > Old School Partitions)

Was für themen müsstest du dir anschauen für einen eigenen Build?
- qemu-debootstrap

Mit LVM (zusätzlich):

• lvm2 (natürlich )
• initramfs

Mit squashfs (zusätzlich zu allem oben):

• Live-Boot # Configs Scripts für den Live Boot - laded Squashfs ins ram mit dem Initramfs
• Live-Config # Config Möglichkeiten, zB on Boot kann SSH umgestellt werden das ein Zert vorhanden ist auf dem Pi sonst gibt es keine Verbindugn
• persistance.config # erlaubt dir das Mounten der Physischen Disk auf das Live gestartete Squashfs - kann z.B. Updates ermöglichen oder die möglichkeit ein persistentes Home Directory zu haben.

Fals jemand Interesse an dem create your own Pi Version, mit Nur LVM und oder mit Squash - ich hätte da einige Ressourcen (Links, Script parts), welche ich Sharen könnte.

 

[netzgestaltung]

5. Ändern. Es bringt keine echte Sicherheit, aber es reduziert die Flut an fail2ban Emails enorm und reduziert die log size.

Hab auf meinem alten vserver täglich mittlere dreistellige bans erhalten, jetzt mit anderem Port sinds ein paar pro monat

ev kann auch nur das Port-Forwarding am Router so geändert werden, das von aussen ein anderer Port auf den 22er intern weiterleitet. Das erleichtert Interne Anfragen, hängt aber davon ab ob Intern auch "Vertrauenswürdig" ist.

 

[ModellbahnerTT]

Habt Ihr sonst noch Sicherheitsvorkehrungen getroffen oder habe ich etwas essenzielles vergessen?

Das Passwort des Nutzers root ändern und den Port 22 ändern.

 

[Kenny [CH]]

Das Passwort des Nutzers root ändern und den Port 22 ändern.

Standard Mässig hat der Root User "kein Passwort", ohne Passwort kann der sich auch nicht via SSH anmelden. Wenn du dem Root User ein Passwort gibst, kann er sich im aber am SSH Anmelden. Dann müsste man dies bei SSH verhindern (SSH Zugriff mit Root Account ist ein absulutes NOGO). Da der Root User nicht wirklich benötigt wird, sudo command oder wenn sudo -i um in die root shell/root privileges zu wechseln, würde ich hier nichts Ändern.

Einziger grund ein Root PW zu setzten (sudo passwd root), wäre für den Notfall, wenn man das System zerschossen hat. Da würde ich aber eher empfehlen entweder ein neues Image zu laden und zu installieren, Backup wiederherzustellen oder via anderen PC (Linux) das Root FS zu reparieren.

 

[Brati23]

Vielen Dank für die vielen Antworten und Tipps!

Ich habe auf meinem VPS ein ssh Fingerprint eingerichtet und das einloggen als root per ssh unterbunden.

Passwörter sind doof Nimm lieber ein SSH Key Paar für die Authentifizierung und du kannst ausstellen, dass man sich per PW über SSH anmelden kann.

Gut zu wissen. Danke für die Infos und den Link. So kann sich nur noch der Rechner mit dem passenden Key anmelden richtig?

5. Ändern. Es bringt keine echte Sicherheit, aber es reduziert die Flut an fail2ban Emails enorm und reduziert die log size.

Port von SSH würde ich auch nur dann ändern, wenn der Pi direkt von Aussen per SSH bedient werden soll. Wenn du SSH nur von Intern oder via VPN erlaubst, kann da fast nichts passieren.

Ich Depp! Ich brauche ja den Port 51820 für Wireguard und nicht 22 für ssh. Bin dann ja im VPN. Trotzdem eine gute Info dass es die Zugriffe zu reduzieren scheint wenn nicht der Standard-Port genutzt wird.

Wenn du SSH nur von Intern oder via VPN erlaubst, kann da fast nichts passieren.

Ergo einfach keine Portfreigabe?

Auto Update/Upgrade sind meistens recht unproblemtatisch, solange du in release updatest (also keine Dist Upgrades etc) machst, sollte in den meisten Fällen das ordentlich Funktionieren.

Danke für die Info. Wie oft sollten die Dist Upgrades manuell gemacht werden? Je nach erscheinen?

Zu den Sicherheitsvorkehrungen: Da gäbe es einiges, was man noch machen könnte.

Das werde ich am Wochenende mal testen. Klingt aber nicht ganz einfach!

Das wird die Lebensdauer der SD Karte Massiv verlängern,

Interessant. Mit was für einer Lebensdauer ist in etwa zu rechnen?

 

[G-Red]

Gut zu wissen. Danke für die Infos und den Link. So kann sich nur noch der Rechner mit dem passenden Key anmelden richtig?

Genau, du kannst dich aber nur von dem Rechner anmelden, wo sich der private key befindet. Diesen kannst du dir kopieren (was ich aus backup gründen sowieso machen würde) und bei Notwendigkeit auf einem weiteren Rechner verwendet.

 

[Kenny [CH]]

Ergo einfach keine Portfreigabe?

Diese Frage kann ich dir nicht beantworten, da ich Wireguard nicht kenne. Wenn das Package eine SSH Verbindung via Port 51820 zulässt musste dieser evtl Freigeschaltet werden. Aber da wirst du in einem Guide (how to install Wireguard) sicher alle Informationen finden, also welche Ports freigeschaltet werden müssen.
IdR. kann man aber sagen, SSH, RemoteDesktop etc (also alle Remote Connections Tools) solllten wenn möglich nicht direkt vom Internet erreichbar sein. Man soll nur auf die Hardware kommen, wenn man ein VPN Verbindung hat (so machen es die meisten Firmen).

Danke für die Info. Wie oft sollten die Dist Upgrades manuell gemacht werden? Je nach erscheinen?

Das ist auch eine Frage, auf die man nicht eine Antwort geben kann - it depends - jenach Installierter Packages und use case kann es Sinn machen nicht immer (on release) ein Dist-Upgrade zu machen und zu warten. Es könnnen auch die einen oder andere Probleme auftretten.

Das werde ich am Wochenende mal testen. Klingt aber nicht ganz einfach!

Interessant. Mit was für einer Lebensdauer ist in etwa zu rechnen?

So wie ich deine Antwort lese, würde ich dir eher empfehlen mit dem standard OverlayFS zu arbeiten und nicht eine eigene Version zu erstellen (ich glaube - korrigier mich wenn ich falsch liege - deine Linux Kentnisse sind nicht genug tief für eine custom Version). Gemäss meinen google search skillz, sollte OverlayFS mitlerweile im standard Image enthalten sein (https://pigeoncomputers.com/documentation/tips-and-tricks/overlay-file-system/) und ist damit relativ einfach zum aktivieren/deaktivieren.

Zu der Lebensdauer (auch hier it depends ) - eine SD Karte ist im Grunde genommen gleich wie eine SSD. Die Chips können halt nur eine limitierte Anzahl an Schreibvorgänge machen und dann sind diese defekt.
Also wäre meine Antwort: Umso mehr auf die Karte geschrieben wird umso schneller sind die Schreibvorgänge aufgebraucht. (Siehe z.B. Tesla welche bei den ersten Modelen mit den Logs die interne Flash Memory "zerstört" haben https://www.tomshardware.com/news/f...r-teslas-due-to-excessive-data-logging-report)
Beim Raspberry Pi werden auch viele Logs/Daten geschrieben und bei einem System (24/7 Online) können das auch einige GB werden. Wenn du nach "raspberry pi wear out sd card" suchst, findest du z.B. einige Einträge von Usern die das Problem hatten / verhindern wollen.
Swap und Logging deaktivieren - oder Logging auf Tmpfs (in RAM) werden da oft als Lösung vorgeschlagen. Das kann man aber auch mit OverlayFS lösen und hier muss nur das Swap deaktiviert werden.

SWAP muss/sollte aber immer deaktiviert werden (Hoffentlich hast du den Pi4 mit 4 oder 8GB RAM gekauft) auch mit OverlayFS - Es macht ja kein Sinn, dass wenn dein RAM fast voll ist, dass das System beginnt zu Swapen in das RAM.

Gute Erklärung zu OverlayFS: https://www.linux-magazin.de/ausgaben/2017/06/kern-technik/1/ (Bitte folge nicht dieser Anleitung, die ist veraltet und es hat sich einiges geändert. Z.B. Overlay muss nicht mehr in das initrd hinzugefügt werden - die neuen RaspberryPi Kernel haben das Modul bereits im Kernel!)

Das TLDR ist:
Deine SD Karte ist readonly gemounted (heist lowerdir im OverlayFS)
Dein upperdir / workdir liegen meistens in einem tmpfs - also im RAM alle changes werden nur im RAM gemacht und nach eine Reboot sind sie weg.