Punkt 4.Cyberciti hat auch einen Guide für allgemeine Absicherung von Linux, geht nicht sehr tief, aber damit sind schon mal die low hanging fruits erschlagen:
https://www.cyberciti.biz/tips/linux-security.html
Punkt 4.Cyberciti hat auch einen Guide für allgemeine Absicherung von Linux, geht nicht sehr tief, aber damit sind schon mal die low hanging fruits erschlagen:
https://www.cyberciti.biz/tips/linux-security.html
Punkt 4.
One Network Service Per System or VM Instance
Ist ja mein reden ;-)
Unprivileged Containers
Unprivileged containers use a new kernel feature called user namespaces. The root UID 0 inside the container is mapped to an unprivileged user outside the container. This means that most security issues (container escape, resource abuse, etc.) in these containers will affect a random unprivileged user, and would be a generic kernel security bug rather than an LXC issue. The LXC team thinks unprivileged containers are safe by design.
This is the default option when creating a new container.
Note If the container uses systemd as an init system, please be aware the systemd version running inside the container should be equal to or greater than 220.
Privileged Containers
Security in containers is achieved by using mandatory access control AppArmor restrictions, seccomp filters and Linux kernel namespaces. The LXC team considers this kind of container as unsafe, and they will not consider new container escape exploits to be security issues worthy of a CVE and quick fix. That’s why privileged containers should only be used in trusted environments.
https://pve.proxmox.com/wiki/Linux_Container#pct_settings
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 …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:
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: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 …
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).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?)
We use essential cookies to make this site work, and optional cookies to enhance your experience.