Ideen für den Anfang mit Proxmox
- Thread starter PikAss
- Start date
Naja, da sind wir jetzt beim Thema "Abwägungen", im Zweifelsfall ist eine VM besser isoliert als ein LXC-Container, aber eine VM braucht halt auch mehr Ressourcen. Da finde ich es dann sicherer mehrere Dienste als Docker/podman-Container innerhalb einer VM zu betreiben, wenn man nicht die Kapazitäten für eine VM pro Dienst hat, statt ein LXC pro Dienst. Insbesondere wenn es privileged lxcs sind, die werden nämlich von den lxc-Entwicklern als "unsicher by design" betrachtet:
Mit systemd-Sandboxing kann man Dienste übrigens noch weiter verriegeln, auch wenn die nicht als Container laufen:
https://github.com/alegrey91/systemd-service-hardening
https://www.linux-magazin.de/ausgaben/2021/11/systemd-analyze/
Aber bevor man Dienste absichert, sollte man erstmal zusehen, dass nur der Kram von außen erreichbar ist, der das auch wirklich braucht plus ssh mit fail2ban und Abschalten des Passwort-Logins verriegelt werden.
Wenn man die Ressourcen hat, ist es natürlich besser eine VM pro Dienst zu haben, klar.
Also ich für mich folge der Regel, alles was von außen erreichbar ist (ohne VPN) kriegt eine eigene VM, alles andere kann auch ein (privilegierter) LXC sein …
Das ist keine verkehrte Regel, wobei mir das mit einen priviligierten LXC selbst dann noch zu heikel wäre. Man sollte aber im Hinterkopf behalten, dass klassische Perimeter-Sicherheit in Zeitalter der Cloud und mobiler Endgeräte nicht mehr ganz passt, da habe ich letztes Jahr einen netten Vortrag auf einer Tagung in Darmstadt zu gehört:
https://talks.mrmcd.net/2024/talk/8CZJFN/
Cooler Talk, im wesentlichen ist es einfach kleinere "Castels" also Funktionsgruppen in eigenen LANs mit den Identies managed outside. Umgelegt auf eine Homeserver installation (so hab ich den Thread zumindest verstanden) wuerde wie aussehen ? Da wuerde ich den Homeserver schon als kleinstes Castle sehen ... oder hab ich da was noch nicht ganz verstanden? (Bei grossen Firmennetzwerken schon klar, aba im Homeserver Bereich?)
Naja, das kommt natürlich darauf an, wie weit man es treiben möchte. Wenn man z.B. eine Hausautomatisierung oder IoT-Geräte hat, würde es sich ja z.B. anbieten, die in eigene Netze zu packen. Wenn man mit Virtualisierung rumspielt (wie wir hier
) könnte man außerdem die VMs vom eigentlichen Heimnetz zum Surfen trennen. Oder LAN und WLAN und das nochmal in ein Gäste- und Familiennetzwerk Ich mache das zugebenermaßen auch nicht bisher, aber da gibt es schon einige Möglichkeiten. Bietet sich besonders an, wenn man Geräte hat, die keine Securityupdates mehr kriegen, aber "aus Gründen" trotzdem noch betrieben werden (bei mir auf der Arbeit hatten wir noch sehr lange Windows2008 VMs für eine spezielle Anwendung bis wir die endlich losgeworden sind).Das sind auch meine nächsten Pläne. Seperate VLAN`s für diverse Gruppen von Anwendungen / Teilnehmern. Vor allem die Trennung von IoT und Rest meines Netzes.
Ich muss nich meinen Roborock China Cloud Staubsauger in irgendeinem meiner Netze haben.
Genau so ist es das Gast WLAN auf der FB sinnvoll, auch wenn dieses von mir noch nie so strickt umgesetzt wurde. Zukünftig aber schon ;-)
Ich muss nich meinen Roborock China Cloud Staubsauger in irgendeinem meiner Netze haben.
Genau so ist es das Gast WLAN auf der FB sinnvoll, auch wenn dieses von mir noch nie so strickt umgesetzt wurde. Zukünftig aber schon ;-)
Sorry für die lange Pause, aber es hat sich einiges getan.
Ich habe den RAM, das Board und die CPU getauscht.
Neues Setup:
Mainboard: ASUS TUF Gaming B760M Plus
RAM: 2 x 32 GB Kingston Fury Beast
CPU: I5-12400
PCIe: LSI 9300-8i in HBA / IT Mode geflashed
4 x 4 TB SAS HDD (am PCIe Controller)
2x 1 TB M2 SSD -> ZFS Mirror als Datastore für die VM`s
2x 500 GB SATA SSD -> ZFS Mirror als Bootplatte für pve
2x 3 TB SATA HDD -> hängen noch rum und werden wahrscheinlich "LangzeitBackup" oder irgendwann mal in eine extern NAS geschraubt.
Nächste Schritte sind:
Aufgrund der Gegebenheiten muss ich die Netztrennung mit VLANs in separaten Netzbereichen machen. Dazu hätte ich aber noch eine Verständnisfrage:
Ich habe nun eine 2,5 Gbit RJ45 Verbindung im proxmox Server. Diese ist ja standardmäßig als vmbr0 eingerichtet. Ich habe das VLAN Tagging aktiviert, nun versteht das Teil ja VLANs oder?
Wenn ich jetzt den proxmox Server an einen Switch anschließe (auf dem die VLANs konfiguriert sind) muss ich an dem Switch proxmox Port wahrscheinlich alle VLANs konfigurieren.
In proxmox und in den VMs weise ich dann in den Netzwerkeinstellungen einfach die VLAN Tags zu und geben denen entsprechend ihre neuen IP`s und proxmox übernimmt dann das interne Routing oder?
Ist das ... sicher? Also ist es sicher dass proxmox sicherstellt, dass niemand aus seinem VLAN ausbricht?
Beispiel:
Wenn VM1 VLAN10 auf dem Switch eine Route zu VM2 VLAN20 haben sollte (zB irgendeine Anwendung, Portfreigabe wie auch immer), dann kommuniziere die VMs nicht einfach untereinander über den Host sondern gehen wirklich den Weg über den Switch?
Ich habe den RAM, das Board und die CPU getauscht.
Neues Setup:
Mainboard: ASUS TUF Gaming B760M Plus
RAM: 2 x 32 GB Kingston Fury Beast
CPU: I5-12400
PCIe: LSI 9300-8i in HBA / IT Mode geflashed
4 x 4 TB SAS HDD (am PCIe Controller)
2x 1 TB M2 SSD -> ZFS Mirror als Datastore für die VM`s
2x 500 GB SATA SSD -> ZFS Mirror als Bootplatte für pve
2x 3 TB SATA HDD -> hängen noch rum und werden wahrscheinlich "LangzeitBackup" oder irgendwann mal in eine extern NAS geschraubt.
Nächste Schritte sind:
- HTTPS im lokalen Netz
- Alle root Accounts deaktivieren
- System ein wenig härten
Aufgrund der Gegebenheiten muss ich die Netztrennung mit VLANs in separaten Netzbereichen machen. Dazu hätte ich aber noch eine Verständnisfrage:
Ich habe nun eine 2,5 Gbit RJ45 Verbindung im proxmox Server. Diese ist ja standardmäßig als vmbr0 eingerichtet. Ich habe das VLAN Tagging aktiviert, nun versteht das Teil ja VLANs oder?
Wenn ich jetzt den proxmox Server an einen Switch anschließe (auf dem die VLANs konfiguriert sind) muss ich an dem Switch proxmox Port wahrscheinlich alle VLANs konfigurieren.
In proxmox und in den VMs weise ich dann in den Netzwerkeinstellungen einfach die VLAN Tags zu und geben denen entsprechend ihre neuen IP`s und proxmox übernimmt dann das interne Routing oder?
Ist das ... sicher? Also ist es sicher dass proxmox sicherstellt, dass niemand aus seinem VLAN ausbricht?
Beispiel:
Wenn VM1 VLAN10 auf dem Switch eine Route zu VM2 VLAN20 haben sollte (zB irgendeine Anwendung, Portfreigabe wie auch immer), dann kommuniziere die VMs nicht einfach untereinander über den Host sondern gehen wirklich den Weg über den Switch?
So ein Update ohne die unattended-Steuerung kann dann schiefgehen oder anhalten, wenn eine Eingabe erforderlich ist oder eine Abfrage kommt. Da kann man bestimmt Variablen setzen und (weitere) Parameter setzen, es gibt dazu aber auch ein fertiges Debian-Paket (warum auch immer autoupdate kein default ist) und viele Tutorials im Netz, ich mach manchmal sowas wie
Code:
apt-get install -y unattended-upgrades apt-listchanges bsd-mailx apt-config-auto-update
echo 'Unattended-Upgrade::Mail "root";' >> /etc/apt/apt.conf.d/50unattended-upgrades
echo unattended-upgrades unattended-upgrades/enable_auto_updates boolean true | debconf-set-selections
dpkg-reconfigure -f noninteractive unattended-upgradesIm Zeitalter der Side-Channel-Angriffe ist es natürlich noch besser, ein Metall pro Dienst zu haben
SCNR.Genau, das Thema "Abwägungen".
Genau so sehe ich das auch, die Datenströme idealerweise über eine Firewall (nicht "Paketfilter", sondern "Firewall", so mit HTTPS Proxies und so) leiten und auch gern mal reinschauen, wenn möglich oder gleich blocken (aber dann gibt's auch keine Updates - den Krieg haben wir leider verloren).Naja, das kommt natürlich darauf an, wie weit man es treiben möchte. Wenn man z.B. eine Hausautomatisierung oder IoT-Geräte hat, würde es sich ja z.B. anbieten, die in eigene Netze zu packen. Wenn man mit Virtualisierung rumspielt (wie wir hier
Leider sind heute solche Geräte (wie chinesiche IP Kameras) als großer Angriffsvektor zu betrachten und möglichst zu isolieren.
Das kenn ich, da hängt bestimmt irgendwas an einem seriellen Kabel und übersetzt Daten in IP oder so, da den direkten Zugang verhindern (sprich: Internetzugang blocken, Updates gibts ja eh nicht, nur Nutzdatenport(s) erlauben, "137" darf nicht dabei sein usw; ) und gut ist. Wenn an ein unsicheres Windows keiner rankommt und vor allem keiner ein Outlook dadrauf startet, dann passiert ja da auch nichts.
Ich habe da vor Windows 11 Problemen mehr Sorgen; ich wäre über Features wie "sending detailed telemetry data of the home network to improve the user experience" und natürlich ständig neuen Funktionen mit neuen Bugs nicht überrascht, aber zu Hause war ich leider zu faul.
(Ich habe lange Zeit einen Linux-Laptop für's Wichtige und die Arbeit und einen Windows-Laptop für den Rest (Finanzbuchhaltung, ELSTER und so) genutzt, aber dank Zoom und Teams und Sharepoint und vielen weiteren riesigen Angriffsvektoren von Microsoft-Produkten, die im Business kaum vermeidbar sind, sind eh alle wichtigen Daten für Angreifer erreichbar und man kann die Kirche im Dorf lassen. Ich glaube, meine autoupdate-Linux-Container fallen erst lange danach und dann ist's auch egal...)
Ich glaube, das "Perimetersecurity is dead" ist (clickbait oder) eine Übertreibung bzw ein Mißverständnis. Perimetersicherheit war schon in den 90ern zonenbasiert, "DMZ" ist ein sehr alter Begriff, und schon damals hat man auch gern mehrere Zonen gemacht. Das hat sich einfach nur weiterentwickelt. In noch mehr Zonen und dann in maximal-viele-Zonen, bis hin zu 1 Zone pro 1 Dienst, also z.b. 1 Container mit 1-Port-Netzwerk, wo es einfach geht. Oft hab ich aber auch einige Container, die zusammen was darstellen (Webserver, Datenbank, Script), das ist dann auch eine "Zone" mit "Perimetersecurity".
Bei Zerotrust kommen dann gern welche mit Single Sign On, am besten Active Directory, 16 stelliges Zufallspasswort aus 5000 Unicodezeichen, je mindestens ein Groß/Klein/Ziffer/Sonderzeichen/Emote/Rune, Details siehe Policy Seite 1000 bis 1700, und das hat auch einen Stapel ganz eigener Probleme, wie die ganzen ransomware Angriffe zeigen. Und die sieht man selten in Containern. Und wenn, dann ist es meist cloud config.
Wichtig ist, dass man gute Backups hat und die selbst nicht ändern kann (dann, und nur dann, kann der Angreifer das auch nicht). Das einigermaßen gut hinzukriegen ist erstaunlich schwierig und unkomfortabel, aber sollte immer höchste Priorität haben, finde ich.
Hey, das ist ja schick!
die 2x500 GB "boot" hätte ich nicht extra genommen (außer, die lagen eh rum). Aber Speicher hat man eh nie genug
Das geht?
Warum? Traust Du SSH Keys nicht?
Irgendwie musst Du ja administrieren können.
IoT finde ich wichtig, für diese Cloud-Only-Krempel nur Internet (am besten nur über Proxy), aber keinen Zugriff aufs LAN, ggf. Portweise HTTPS oder sowas. Ich nehm da gern eine OPNsense VM.
Auch ggf. china switches würde ich da reintun.
DMZ für zu Hause, cool.
Management Netz macht ja nur Sinn, wenn Du da auch eigene Clients hast, also Dein Management-PC/Laptop nicht im Heimnetz ist, oder?
Getrennte Management Laptops (ohne Outlook, idealerweise ohne Browser, aber das geht heute nicht mehr) sind toll, aber für zu Hause wirkt es etwas overengineered. Du brauchst ja auch zwei Stück (falls einer kaputt geht, muss Du ja noch adminsistrieren können). Obwohl hier ggf. ein Linux Bootstick reicht.
Wie auch immer, es klingt nach einem sehr spaßigen, wunderschönen Heimprojekt, sehr schön!!
Ja, es arbeitet dann mit VLAN tags und braucht (ggf) entsprechend konfigurierten Switch-Port.
Ja genau. BTW: dann schützt der Switch natürlich die VLANs nicht mehr, denn wenn eine Proxmox-VM da rankommt, kommt ein Angreifer, der die kontrolliert, da auch ran. Aber da Du ja nicht *vor* den Containern schützen willst, sondern vor den IoT Geräten, ist das OK. Ansonsten könnte ein Angreifer, der einen Container übernommen hat, natürlich u.U. Wege finden, aus diesem auszubrechen, das Proxmox übernehmen und hat dann Zugriff auf alle VLANs.
Falls man da routet und Proxmox auch jedes VLAN gibt, dann ja, aber das würde man wohl eher nicht wollen, denn dann bräuchte man ja keine VLANs.
VLANs sollen ja "physikalisch getrennte" Netze "emulieren", und wenn man die zusammensteckt, sind sie ja nicht mehr getrennt. Daher würde ich das immer über eine Firewall oder mindestens einen Paketfilter machen.
Eine m.E.n. recht einfache Möglichkeit ist OPNsense.
Hier kann man erstmal OPNsense mit zwei Netzwerkkarten nach Tutorial einrichten.
Dann kann man im Proxmox für jedes VLAN eine weitere Netzwerkkarte auf dem jeweilgen VLAN hinzufügen (dann sieht das OPNsense die VLANs als Netzwerkkarten, wie multi-homed Firewall an non-trunk Switchports). OPNsense kann VLAN, aber ich würde das nicht nutzen, sondern je VLAN eine Netzwerkkarte bereitstellen. Ich mach dann immer die letzte Stelle der MAC-Adresse auf die VLAN-Nummer, dann kann ich die im OPNsense leicht zuordnen und die Regeln dann per WebGUI einrichten. "Von IoT darf DNS, NTP und Proxy, sonst nichts; nach IoT darf ICMP, HTTPS; Management nach IoT darf SSH" usw. Das Aufwändige dabei ist das Zeichen der Datenflußdiagramme <zwinker>
Nein, perfekt "sicher" ist es natürlich nie.
Die Frage ist, wovor man sich schützen will, ob "sicher" heir "secure" und/oder "safe" bedeutet (für "safe" fehlt noch das Backupkonzept), wieviel Datenverlust ist bei einem Feuer im heimischen "Serverraum" verkraftbar, kommt die Frau/Freundin mit einem zwei stündigigen Mediathekausfall klar und muss man von unterwegs aus Playlists und Thermostate konfigurieren können).
Wichtig ist meiner Meinung nach, dass die IoT Geräte nur DNS, NTP und HTTPS dürfen, und ob und wie die Geräte voneinander isoliert sind (was schnell aufwändig wird). Alles in ein IoT ermöglicht sonst ja dem Angreifer der China-Kamera (die man natürlich nur testweise betreibt und eine leere Wand filmen lässt) die Heizung aus. Oder an.
Dann alles Windows isolieren oder rauswerfen (und da hört es dann leider in der Praxis schon oft auf, weil man es braucht; ein Spiele-Windows-PCs wäre ein eigenes IoT-ähnliches Netz, aber meist arbeitet man auf dem, weil es die heiße Kiste ist...).
Bis zu einem gewissen Grad ist das so, aber es kann immer Bugs überall geben, vielleicht ein Kernelbug, der einem Angreifer ermöglicht... was auch immer.
Aber "irgendeine Kröte muss man schlucken", und hier bleibt ja nichts, außer Proxmox zu trauen (immer schön sofort alle Updates einspielen!).
Natürlich wäre es besser, mehrere Geräte zu nehmen und auch mehrere Betriebssysteme (daher nehme ich gern OPNsense, das ist BSD, nicht Linux, und hat hoffentlich nicht zeitgleich den gleichen Bug im IP Stack), aber wenn Du die VLANs schön trennst, bist Du auf sehr hohem Niveau.
Natürlich ist das nicht ganz einfach, irgendwo aus Versehen einen Router falsch konfiguriert, und es geht an der Firewall vorbei oder oder oder
VLAN ist vergleichbar mit einem "virtuellen Kabel". Damit kann man ein Netzwerk isolieren. Man könnte machen:
VLAN10 = 192.168.10.0/24; VLAN11 = 192.168.11.0/24; usw
Das ist "doppelt isoliert"; das VLAN schützt, falls ein Client aus .11. sich einfach eine .10.er IP geben würde.
Ein Switch filtert (normalerweise) nicht, ob in VLAN11 niemand eine .10.er IP nutzt, daher braucht man ne Firewall, oder einen multihomed Router mit VLAN Support und Filterregeln (was ich schlicht Firewall nenne).
Man kann VLAN10 auf VLAN20 switchen lassen, aber dann braucht man ja keine VLANs. Man möchte ja die VLANs nutzen, um die Daten unterscheiden zu können, weil man den IPs nicht vertrauen möchte (wie wahrscheinlich auch immer Angriffe mit falschen IPs sind).
wenn Du ein vmbr0 mit tag 10 (nennen wir das vmbr0.10) einer VM zuweist, kommt deren Traffic mit VLAN 10 getaggt aus dem vmbr0 Basisinterface und wird von anderen ignoriert. Jetzt kann man das in einen trunk port eines Switches stecken und dem Switch sagen, Port 5-9 sind VLAN 10. Dann kommt der VLAN 10 getaggte Traffic vom trunk port an port 5 bis 9 OHNE Vlan tag an. Traffic von Port 5 bis 9 bekommt vom Switch das VLAN 10 verpasst und wird zum Trunk geleitet, wo es dann zu der VM geht. Wenn an Port 4 oder 10 ein VLAN 20 ist, packt der Switch da ein VLAN20 drauf *und die sehen nichts* und werden nicht gesehen. Port 9 und 10 sind voneinander isoliert, als ob es zwei switches mit zwei Kabeln wären.
Auf diesen VLANs muss dann IP laufen. Da kann jedes VLAN alle IPs haben, aber sinnvoll ist es, den VLANs IP Netze zuzuweisen (wie ich oben gemacht habe).
Du kannst eine VM machen, die zwei VLANs über zwei NICs reinbekommt, zb. vmbr0.10 und vmbr0.20, da entsprechende Netzwerke erlaubt (zB. über DHCP ranges vergibt etc) und ausgewählte Verbindungen erlaubt ("routed").
Naja, man kann natürlich sich auch einen User für den Login einrichten und dem dann erlauben nur mit sudo und Eingabe eines Extrapasswords Adminrechte zu kriegen. Ob das dann wirklich sicherer ist, darüber kann man lange streiten
Außerdem funktionieren SSH-Keys und NFS4-Authentifizierung per Kerberos nicht zusammen: NFS4 braucht einen passwort-login, der bei ssh dann ja wegfallen würde. Zugebenermaßen: Wer heutzutage noch NFS4 für /home-Directories o.ä. nutzt, ist eh selbst schuld.
Grundsätzlich finde ich ssh-keys vertrauenswürdig, aber beim Deployment von Handling etwas umständlich, darum will ich schon länger mal versuchen mir was mit ssh-Zertifikaten und smallstep zu bauen, aber der Tag hat halt nur 24 Stunden:
https://smallstep.com/blog/use-ssh-certificates/
https://news.ycombinator.com/item?id=30788544
Für Homelabs (und somit den OP) sollten sie (plus Passwortlogin deaktivieren) aber auf jeden Fall erstmal ausreichen
Genau das war der Punkt des Referenten: Der klassische Ansatz "Internes Netzwerk(Firma) gut, Außenwelt böse" und dazwischen die Firewall zu packen, klappt halt nicht mehr im Zeitalter von nach hause telefonierenden Endgeräten und Nutzung von Cloud-Infrastrukturen.
Ja, ja und ja, PBS und restic haben dazu ja eigene Kapitel in ihren Dokus:
https://pbs.proxmox.com/docs/storage.html#ransomware-protection-recovery
https://restic.readthedocs.io/en/stable/100_references.html#threat-model
Der rest-server (Server für restic) oder S3 (was ja von Veeam, restic und (glaube ich) Borg genutzt werden kann) erlauben (wie PBS) hat ja auch einen Modus, wo keine Veränderungen existierender Backups nötig sind:
https://github.com/restic/rest-server/
Als root auf den Server, wo der Dienst läuft, kann man das natürlich trotzdem, andererseits hat man dann ja eh verloren und sollte für den Fall eh noch ein Backup woanders (z.B. auf externen Laufwerken oder anderen Server/Cloudspeicher) haben.
Last edited:
(Das ist, glaube ich, nur sicherer vor Fehlbedienung und dafür gedacht, war mal irgendeine ubuntu Erziehungsmaßnahme, weil angeblich alle Ex-Windows-User als root gearbeitet haben sollen oder so. Das Passwort bei sudo ist ja das vom User.)Naja, man kann natürlich sich auch einen User für den Login einrichten und dem dann erlauben nur mit sudo und Eingabe eines Extrapasswords Adminrechte zu kriegen. Ob das dann wirklich sicherer ist, darüber kann man lange streiten
Außerdem funktionieren SSH-Keys und NFS4-Authentifizierung per Kerberos nicht zusammen: NFS4 braucht einen passwort-login, der bei ssh dann ja wegfallen würde. Zugebenermaßen: Wer heutzutage noch NFS4 für /home-Directories o.ä. nutzt, ist eh selbst schuld.
Ja, NFS home auf normalen Workstations geht leider gar nicht mehr, weil die Pötterings dieser Welt da ein ~/.tmp und .cache und weiß ich was reintun, und nicht mehr nur der Browser (seit ich glaube Netscape Navigator 4) nicht mehr mit alten Profilen startet (man also überall die gleiche Version haben soll). Ich trauer dem Stand davor ja nach. Einfach irgendwo anmelden und losarbeiten. Neuer Server da, bash drauf, alles geht. Jetzt muss ich meine dotfiles erstmal aus einem Git auschecken.
(In einigen nicht-graphischen Umgebungen habe ich noch NFS, aber local firewalled und per IP access rules, also Linux kann das alles noch, nur der ganze "Desktop"-Kram zickt)
Bei einem PVE ist doch ein (gutes) Root-Passwort kein Problem, muss auch keine 12 Stellen haben. Das muss man nur bei Windows so stark machen, weil das NTLM ja die Passwörter offline prüfbar (offline brute force) macht, da es abgeleitete Daten rausgibt (damit ist der Angriff so schnell wie ein known-hash-Angriff, offline brute force, Fehlversuche hinterlassen keine Spuren, da ja nicht online).Grundsätzlich finde ich ssh-keys vertrauenswürdig, aber beim Deployment von Handling etwas umständlich, darum will ich schon länger mal versuchen mir was mit ssh-Zertifikaten und smallstep zu bauen, aber der Tag hat halt nur 24 Stunden:
https://smallstep.com/blog/use-ssh-certificates/
https://news.ycombinator.com/item?id=30788544
Für Homelabs (und somit den OP) sollten sie (plus Passwortlogin deaktivieren) aber auf jeden Fall erstmal ausreichen
Ein Linuxserver sollte aber den Passworthash von root nicht (und auch nicht irgendwas entsprechendes) rausgeben. Damit kann man nur online brute force machen, schafft nur ganz wenige Versuche pro Sekunde und kann auch 8 Stellen kaum erraten und man siehts im Log (falls man guckt
).Mit deployment meinst Du das Updaten von SSH pub keys in den Servern?
Ich hab da so ein ansible playbook und ich ändere meine SSH keys immer schön alle 10 Jahre. Nee nur Spaß, so lange lebt ja kein algo.
Diesen "Single Zone"-Ansatz gabs aber (hoffentlich) nur in irgendwelchen Windows-Netzen (Microsoft hatte ja in den 90er erklärt, dass alles so einfach ist, dass eine Sekretärin Drucker und Netzwerk einrichten kann, und dann haben die Firmen Leute zu Sekretärinnengehältern eingestellt und entsprechende Netzwerke bekommen :/), oder? Oder wenn der 16-jährige Sohn vom Chef das Netz eingerichtet hat, alles schon gesehen...
Ich hab immer die Windowse weggesperrt, gefühlt kamen immer 9 von 10 Angriffen über Windows.
Ja genau, wichtig ist halt nur, dass der root dann kein auth gegen das Active Directory macht, was der Hacker gerade gebrochen hat
Aber das ist für zu Hause alles ein bisschen fett, da reicht vielleicht ein mv pub/incoming/* readonly/ cron oder sowas auf dem nas.
...und dann die Daumen drücken, dass man nichts vergessen hat...
Jo, ist wie gesagt "Geschmackssache", was man envtl. noch als Vorteil sehen kann, dass man (wenn man das System passend konfiguriert) über die Logs nachvollziehen kann, wenn ein Admin Mist gebaut hat. Kann mir gut vorstellen, dass die Ubuntu-Einstellung aus der Notwendigkeit entstanden ist Leute vor sich selbst zu schützen
Und dabei nehme ich mich nicht aus, mir haben Backups schon oft genug den Tag gerettet.Hm, das Problem verstehe ich nicht. Auch vor der Standardisierung zu ~/.tmp, ~/.cache etc haben Anwendungen schon Caches oder andere temporäre Daten im Homeverzeichnis abgelegt, (Firefox halt unter .mozilla statt .cache/mozilla), da sehe ich nicht warum das NFS kaputt machen sollte?
Das Grundproblem ist doch nicht, dass man keinen Netzwerkstorage mehr nehmen kann (kann man ja immer noch), sondern dass die üblichen Verdächtigen wie NFS nur mit Verrenkungen Authentifizierung und Verschlüsselung unterstützen.
(In einigen nicht-graphischen Umgebungen habe ich noch NFS, aber local firewalled und per IP access rules, also Linux kann das alles noch, nur der ganze "Desktop"-Kram zickt)
Bei einem PVE ist doch ein (gutes) Root-Passwort kein Problem, muss auch keine 12 Stellen haben. Das muss man nur bei Windows so stark machen, weil das NTLM ja die Passwörter offline prüfbar (offline brute force) macht, da es abgeleitete Daten rausgibt (damit ist der Angriff so schnell wie ein known-hash-Angriff, offline brute force, Fehlversuche hinterlassen keine Spuren, da ja nicht online).
Ein Linuxserver sollte aber den Passworthash von root nicht (und auch nicht irgendwas entsprechendes) rausgeben. Damit kann man nur online brute force machen, schafft nur ganz wenige Versuche pro Sekunde und kann auch 8 Stellen kaum erraten und man siehts im Log (falls man guckt
Mit deployment meinst Du das Updaten von SSH pub keys in den Servern?
Exakt, sobald man mehr als eine Hand voll Admins hat und mehrere 100 VMs darüber administrieren muss, skaliert das Deployment der Keys nicht mehr sehr gut. Mit ansible, puppet o.ä. lassen sich die Schmerzen zwar mildern, aber die Grundidee, dass man über ein ablaufenden Zertifikat die Lebenszeit von Anfang an begrenzt, finde ich noch mal deutlich besser. Bringt (wie alles) halt dafür seine eigenen Probleme mit sich, weshalb ich das bisher auch auf "wenn mal Zeit ist" verschoben habe.
Naja, dieser "single zone"-Ansatz entspricht durchaus auch dem, was viele Firmen mit den Teil ihres Netzes machen, der nicht unter Windows läuft. Mir wurde von einen Laden berichtet, der aufgrund technischer Schulden noch EOL-SLES Versionen einsetzte (da man mal propietäre Software eingekauft hat, die unter neueren Systemen nicht läuft) und das auch "ok" fand, weil "ist ja in unseren Netz, das ist vertrauenswürdig".
Die Problematik sich über docker, pip und co Dependencies aus allen möglichen Dependencies samt möglicher supply-chain-Attacken ins Haus zu holen, ist jetzt auch nicht wirklich windows-spezifisch
Das das der Hauptangriffsvektor ist, ist eh klar, aber das liegt, meiner Meinung nicht daran, dass Linuxer per se sicherere Systeme haben oder diese besser abschotten, sondern weil es für Ransomware-Gangs schlicht mehr Profit mit weniger Aufwand gibt ihre Exploits auf Windows zu konzentrieren.
Trotz der stärkeren Verbreitung von Linux im (Web)serverbereich.
Klar, wir haben uns in unserer Debatte schon ein bissel weit vom Ausgangsszenario entfernt
Für den OP reicht es imho den Kram irgendwo hin zu kopieren, wo es nicht einfach verändert werden kann (also externe, normalerweise abgestecke Festplatte + irgendein write-only Cloudspeicher, PBS lässt sich ja auch so konfigurieren).Aber dafür sind sie ja auch daJo, ist wie gesagt "Geschmackssache", was man envtl. noch als Vorteil sehen kann, dass man (wenn man das System passend konfiguriert) über die Logs nachvollziehen kann, wenn ein Admin Mist gebaut hat. Kann mir gut vorstellen, dass die Ubuntu-Einstellung aus der Notwendigkeit entstanden ist Leute vor sich selbst zu schützen
Fehler passieren immer mal. Mist gebaut hätte man IMHO (nur), wenn man kein Backup hat.
Früher (TM) gabs so "dotfiles" aka "rc files" (steht für "runtime config", da sieht man, wie alt das ist
)), wie .vimrc oder .muttrc.Die hatte man im NFS Home und hatte überall seinen vim, mit seinen Tasten usw. Und zwar systemübergreifend, ich hatte das gleiche home unter IRIX, Solaris (SunOS) und Linux.
Mit Netscape Navigator ging das auch ne ganze Weile, aber dann haben die von normalen Files auf so berkley DB oder filesql oder sowas umgestellt. Hat man eine neuere Version gestartet, wurden die automatisch aktualisiert (hat man gar nicht germerkt). Tja und dann ging keine alte Version mehr, weil die Profile ja zu neu waren. Da immer ein Admin von irgendeinem System keine Zeit hatte, einen neuen Navigator zu kompilieren und installieren, hatte man ein Problem und konnte nur noch an bestimmten Workstations surfen.
KDE hatte früher versionierte rc files, sowas wie ~/.kde2/, aber so richtig funktioniert hat das wohl nie. (Daher hatte man dann irgendwelche Wrapperscripte)
(Folgendes enthält Sarkasmus, bitte gern skippen, falls ich zu nervig werde
)Als dann immer mehr undurchsichtiger, kaum menschenlesbarer, komplexer, sich häufig ändernder "freedesktop org" Kram von Linux reinkam, wars mit Wrapperscripten auch (größtenteils) vorbei, selbst wenn man nur Linux hatte (schreib mal ein Konfig-Generator-Script für KDE x GNOME x drölfzig Versionen, die irgendwelches XML patchen). Als Benutzer sind viele Konfigwerte sowas wie "will X ja/nein" oder "Path ist...", aber wenn die Applikation das nicht kompatibel unterstützt, es in einem binary registry hängt oder auch nur komplexes XML ist, ist's halt blöd. Und mit dieser "Standardisierung", also Desktop-Klicki-Bunti-Hacks allen zwangsweise reinzudrücken, selbst wenn man verspricht, nie ein KDE/GNOME/was auch immer zu nutzen, gabs plötzlich ganze Verzeichnisstrukturen mit komischen Dateien, nicht nur konfigs, auch state files und so. Schon allein wenn man ein ~/.local/ hat, sieht man, dass das nicht gut auf ein shared home passt. Und ein Benutzer, ich glaube, der, der sich zuletzt oder zuerst ans X angemeldet hat, konfiguiert für alle Systemresourcen wie DNS.
Ja, und dann gabs welche, die hatten mehrere Workstations und haben sich mehrmals gleichzeitig eingeloggt und plötzlich meckert da ein dbus, dass was auch immer, und irgendwann mäanderte systemd überall rein und dann hatte man plötzlich DNS Probleme, SSH agents gingen nicht mehr richtig und so weiter. Da war dann "friß, oder stirb", NFS home passt in so eine Welt einfach nicht rein.
Ich habe lange Zeit versucht, dass XDG Zeug und das alles zu vermeiden, weil es m.M.n. Unix-Konzepte kaputt macht und ich es nicht wollte, aber unter Linux kam ich da einfach nicht mehr vorbei. Richtig konfigurierbar war das übrigens meiner Meinung nach auch nie, denn die XDG Root auf ~/$(hostname)-xxx/ zu setzen, hat immer irgendwo gehangen, irgendwelche Dateien wurden eben nicht von da gelesen oder irgendeine Applikation hat es anders oder falsch gemacht. Das hat IMHO nur funktioniert, solange man es komplett genommen hat und nichts dran geändert hat oder eigene Wünsche hatte, oder gar auf die Idee kam, ein einzelnes Tool zu ersetzen.
Da funktionierte Linux nur noch so, wie ein Windows. An einem PC sitzt bitte ein Benutzer. PCs mit zwei oder mehr lokalen Arbeitsplätzen (geht ja mit X), oder auch nur remote sessions, werden nicht unterstützt. Schema "Pötterings Laptop", hast was anderes, ist's halt Pech.
Früher hatte ich z.B. einen Test-Name-Resolver. Blöd war, dass der in die glibc musste (später nicht mehr, da konnte man ne .so laden). Der konnte paar feste Namen ändern. War simpler, kleiner C code.
Schreib heute mal einen resolver, der auf ein paar aktuellen Linuxen läuft. Da haste 5 Konzepte je nach systemd Version und viel Spaß beim troubleshooting. Die APIs sind komplex, ändern sich ständig, aktuelle Doku findet sich kaum und vollständig ist sie nie. Debugging geht auch nicht mehr gut, denn alles ist über zehn Prozesse verteilt, von denen jeder anders funktioniert, anders loggt und anders zu konfigurieren ist. Oder schalte man einfach komplett caching aus (portabel)... Ja, Du kriegst ja kaum einen ältere oder neuere systemd Version auf ein systemd System! Linux + Userland selbst bauen macht heute ja auch kaum noch jemand, und wenn, dann mit einem embedded builder (buildroot oder sowas).
NFS ist systemweit gedacht, nicht benutzerweit, ist also nicht das "ein Mensch sitzt an einem Gerät" Konzept (wie bei Windows PCs), sondern "Es g ibt n Benutzer mit m unterschiedlichen Eigenschaften an j Geräten" (klassisches Unix). Daher macht sowas wie "nehme ein Benutzerkennwort für irgendwas am (File-)System" auch so keinen Sinn (und ist eh doof, wie man bei Windows NTLM sieht, was die erst JETZT langsam rauswerfen). Die Kommunikation zur lokalen SSD verschlüsselt man (meistens) ja auch nicht.
In diesem Konzept hat ein Benutzer gar keine Rechte, um Dateisysteme im System zu ändern, denn das könnte ja andere Benutzer stören, und die sind zu isolieren (dafür sind Nutzeraccounts ja da), und zwar auch auf ein- und demselben System und gleichzeitig. Da kann ein Benutzer kein WLAN oder DNS einrichten können oder ein NFS mounten, das muss der Admin tun. Auch das Netzwerk gehört dem System und keinem Benutzer.
Daher macht man z.B. IPSec zum NFS Server, systemweit.
Ja, davon rate ich ab. Das Keymanagement ist IMHO ein größerer Angriffsvektor als ein (jährlich) fester SSH Key. Ich habe wesentlich öfter Störungen durch falsche Systemuhren als Angriffsversuche. Bei X.509 Zertifikaten zb. ist ein DoS Angriff falsche Urzeit und das geht leider öfter, als man möchte. Ich kenne viele, die daher vorschreiben, dass man bei falscher Uhrzeit mit SSH key raufkommen können muss (weil 2FA TOTP ja nicht geht, wenn die Uhr falsch ist, und Zertifikate auch nicht).
Aber klar, dass kann im Einzelfall auch ganz anders aussehen. Ich würde für 100 VMs halt einen SSH key ins Image tun bzw mache ich genau das, aber die VMs kann ich auch recht einfach komplett ersetzen (und damit einen neuen Key reinbringen), das ist in anderen Fällen sicher ganz anders.
Das Windows-Konzept ist schon richtig doof, finde ich. Eine Datenbank für alles (Defective Actory), das gleiche Token für alles (also brauchen Benutzer mehrere Accounts, toll), dann Keys aus Passwörtern abzuleiten ist extrem dämlich, denn so kann jeder im Netzwerk Passwörter "offline" raten und man braucht extrem starke Passwörter, dann werden credentials "gecacht" und zwar wiederverwendbar (siehe mimikatz). Der Tokenansatz geht für fast alles und hat ganz tolle Probleme (siehe Goldticket). Die haben CHAP "verbessern" wollen, MS-CHAP gemacht und es vollkommen zerstört. Dann haben sie MS-CHAPv2 gemacht *und es wieder komplett zerstört*. Das ist schon echt unglaublich. Das ACL basierte Rechte Management ist so kompliziert, dass in großen Firmen es keiner mehr beherrscht (viele Admins wissen nicht einmal, das ACLs beim Kopieren nicht kopiert werden, beim Verschieben aber schon und es gibt 1000 weitere Ausnahmen). Mit einem Druckeraccesstoken kann man Dateien auf allen Servern schreiben und und und
Updates kranken daran, dass man offene Dateien (im Normalfall) nicht überschreiben kann und es gibt einen Stapel Mitigations, aber Updates gehen bis heute weder schnell, noch zeitnah, noch stabil. Dann hat ein Windows schnell sehr viel blöde Funktionen aktiv (MS möchte ja, dass wir von möglichst vielem abhängen), und jedes hat potentiell Lücken. Mach mal bei Windows Server ein Haken bei routing, dann steht's schnell mit aktivem PPTP da und ich kenne etliche Admins, die das nicht mal merken bzw sich nicht dran stören. Zack, hast PPTP an, top. Dann musste so ein Windows erstmal "härten", wobei sich ständig ändert, was man tun soll, auch rückwirkend, und es ist riskant für Production, das ist nicht secure by default (dann könnte man ja nichts "härten"). und so weiter
sorry ich kam ins schwafeln
richtig, und vermutlich kommt der Active Directory Hacker schon deshalb nicht ans Linux, weil da es ein lokales Konto gibt und kein winbind aktiv ist, das hilft meiner Meinung nach schon sehr sehr viel (die ransoms, die ich kenne, gingen alle über AD).Klar, wir haben uns in unserer Debatte schon ein bissel weit vom Ausgangsszenario entfernt
Aber dafür sind sie ja auch da
Fehler passieren immer mal. Mist gebaut hätte man IMHO (nur), wenn man kein Backup hat.
Früher (TM) gabs so "dotfiles" aka "rc files" (steht für "runtime config", da sieht man, wie alt das ist
Ja, ich weiß, aber die hat man doch immer noch? Eine .vimrc funktioniert auch heute noch unter BSD genauso wie unter Linux, MacOS X oder einen der letzten propietären Unixe. Für deren Funktion ist es doch egal, ob die Anwendungen ihr Zeug in ~/.vimrc oder ~/.local/.vimrc ablegen. Genausowie wie es für die Funktion des Browsercaches egal ist, wo genau der nun liegt.
Breaking changes und obskure Datenbankformate (das von Netscape war schlimmer als die von dir genannten und eine Eigenentwicklung morkdb hieß das und war noch sehr lange auch in Mozilla und Thunderbird drin) sind natürlich Mist, aber die haben doch nichts mit Poettering und Co zu tun, das kann doch auch so bei einer Anwendung mal passieren?
Das Problem dabei ist, dass in diversen heutigen Netzen (zum Beispiel Uninetzen, die NFS für die Homeverzeichnisse nehmen) diverse Systeme drin sind, wo prinzipiell nicht vertrauenswürdige Leute lokale Admins sind oder Shellzugriff auf NFS-Clientsysteme haben. Sprich: Sobald die dort einen root-Zugriff haben (sei es weil sie eh die Rechte haben oder weil sie eine Lücke ausnutzen) können sie auch jedes auf dem Client lesbare NFS-Share auslesen, auch für die Daten, wo ihnen eigentlich die Rechte fehlen, weil ein root halt immer ein adduser plus su $userid machen kann. Man merkt da einfach das Alter von NFS, in den 1980ern (als das bei Sun zunächst für interne Zwecke entwickelt wurde) und auch frühen 1990ern war es ja grundsätzlich eine valide Annahme, dass nur die Netzwerkadmins (da identisch mit den Admins der im Netzwerk vorhandenen Server und sonstigen Geräte) auf die Weise sich einen Zugriff verschaffen können und die hatten den ja sowieso schon.
Je nach Szenario kann NFS natürlich trotzdem seinen Sinn haben, etwa als Storage für ProxmoxVE (damit wir nicht mehr ganz so schlimm off topic sind *g*), aber da würde ich dass dan nso einrichten, dass über ein eigenes dezidiertes Netzwerk läuft, wo sonst keiner reinkommt außer eben den PVE-Hosts plus der NFS-Server. Würde man ja für die ZFS-Storage-Replikation oder Ceph im IRegelfall ja auch machen (also mit dezidierten Netzwerk fürs Storage arbeiten). Aber andere Rechner, die VMS/LXCs etc kriegen da dann auf gar keinen Fall den Zugriff.