Server Sicherheit (VPS)

Betriebssysteme
1

Ich bin gerade dabei einen Server neu aufzusetzen (VPS), da ich mit der Sicherheit meines bestehenden Setup unzufrieden bin. Darauf wird unter anderem Nextcloud, Syncthing, Vaultwarden, ntfy und Send via Docker gehostet. In meiner Recherche bin ich auf folgende Aspekte gestoßen, um einen frisch installierten Linux Server abzusichern:

User erstellen und SSH Absichern
Non Admin User erstellen, RSA Keys generieren und SSH via Passwort verbieten. Port Nr ändern (1024 - 32,767).

Passwort Richtlinien
max. PW Alter, leere PW, usw

Firewall
UFW, Crowdsec, Fail2ban oder integrierte Lösungen wie Cosmos Server

Verschlüsselung & Backups
SSL Zertifikat via Let’s Encrypt.
Festplattenverschlüsselung scheint wenig sinnvoll zu sein, da sie nicht vor Zugriff des Hosting Provider schützt. Für Backups aber sehr wohl nützlich.

Virtualisierung
Docker, KVM, Proxmox

Updates Updates Updates!
Automatische Updates können die Stabilität des Systems beeinträchtigen. Und manuelle Updates vergessen werden. Ist es eigentlich möglich, nur sicherheitskritische Updates automatisch zu aktualisieren?

Monitoring
Grafana, integrierte Dashboards

SIEM (optional)
Wazuh (Intrusion detection, Vulnerabilitätsanalyse)

Server ins offene Internet stellen?
Es ist zu erwarten, dass der Server täglich angegriffen und gescannt wird. IT Sicherheit ist komplex und fordert laufenden Einsatz. Man sollte sich daher überlegen, seine Ports geschlossen zu halten und stattdessen einen VPN oder MeshVPN wie Tailscale für den Zugriff einzusetzen.

Hab ich etwas vergessen? Und was haltet ihr von integrierten Lösungen wie Cosmos Server? Gibt es Linux Distros für Server, die besser abgehärtet sind wie Debian? Welche Setups nutzt ihr?

2

Ich bin aktuell sehr zufrieden mit Debian + fail2ban + wireguard.

Falls ich allerdings auf die Idee komme alles neu zu basteln würde ich gerne mal fedoras coreOS ausprobieren. Klingt vielversprechend.

3

Abhängig vom Hoster wäre ggf. ein vorgeschaltetes IPS möglich. Mein Heimserver (u.a. Nextcloud und Vaultwarden) steht in einer DMZ abgeschottet von einer Hardware-Firewall mit IPS. Im Idealfall blockiert man verdächtigen Traffic so früh wie möglich, d.h. noch bevor dieser am VPS ankommt.

  • Wazuh verwende ich selbst auch und ist definitiv sinnvoll, da es neben Überwachung der Logsfiles auch Systemdateien oder geöffnete Ports auf Veränderungen prüft.
  • Debian ist eine solide Basis, da hohe Verbreitung, größter Support, usw. Alternativ wäre vielleicht Alpine Linux etwas.
  • mit Tools wie Lynis bekommt man einen groben Überblick, was man am Basissystem verbessern könnte (Vorschläge genau prüfen und abwägen).
  • Automatische Systemupdates mag ich persönlich gar nicht. Stattdessen lasse ich mich benachrichtigen, prüfe die release notes und spiel die Updates manuell zeitnah ein.
  • Docker:
    • Images kann man gut mit Watchtower aktuell halten.
    • wenn möglich rootless.
    • falls du Nextcloud AIO einsetzen möchtest: Der Mastercontainer braucht Zugriff auf den Docker Daemon (hat Vor- und Nachteile).
  • ggf. Ciphermail nutzen, um E-Mail Benachrichtigungen des Server Ende-zu-Ende verschlüsseln.
  • Cosmos Server und CrowdSec klingen vielleicht nicht schlecht. Da ich es nicht verwende, nur ein paar Gedanken dazu:
    • Cosmos Server: Lohnt sich vermutlich eher dann, wenn man kein „Konsolen-Fan“ ist. Um Dinge wie DDoS kümmert sich eigentlich der Hoster.
    • CrowdSec: In der kostenfreien Version bekommt man die Blocklisten „nur“ täglich und nicht in Echtzeit. Ob sich eine zusätzliche Software lohnt, müsste man sich genauer überlegen.
    • Ich tendiere eher zu weniger ist mehr (KISS).

Abhängig vom Anwendungsfall zusätzlich:

  • Geo-Blocking (z.B. nur DE erlaubt)
  • alle Requests die von bestimmten Hostern (Hetzner, OVH, AWS, usw.) und aus dem Tor-Netzwerk kommen blockieren (Grundrauschen nimmt dadurch extrem ab). Hilfreich ist das ASN-Skript.
  • Standard-Ports könnte man ggf. als Honeypot offen lassen und Anfragen bzw. die IP-Adressen sofort sperren.
1 „Gefällt mir“
4
  • Das „wie“. Tools aufzulisten hilft nur bedingt. Es kommt maßgeblich darauf an wie du sie anwendest.
  • Beispiel Docker: da ist je nach Konfiguration alles drin, von trivialem Zugang zu Root bis sehr gut isoliert. Das folgende Script scannt deine Docker-Container nach verbesserungswürdigen Konfigurationen https://github.com/docker/docker-bench-security . Man muss dann aber letztenendes ausprobieren, was der Container benötigt um noch korrekt zu funktionieren und was nicht. Alternativ kann man auch Kata oder gvisor verwenden, welche sehr starke Isolation bieten, aber nicht alle Container sind darin lauffähig.
  • Backups und Ransomwareschutz
  • AV
  • Redundanz
  • Bitfehlersicherheit (ECC-Ram, ZFS-Raid, …)
  • Isolation zwischen den Services
  • Schutz des Heimnetzes (VLANs, Firewall, IDS usw)
  • Mandatory access control

Da solltest du wissen was du tust. Offene Ports und vulnerable Versionen werden von Bots teilweise innerhalb von Minuten entdeckt. Zugriff via VPN macht deinen Server deutlich sicherer und vergibt auch mal Fehlkonfigurationen.

Passwörter regelmäßig zu ändern wird schon lange nicht mehr empfohlen.

Würde lieber auf firewalld setzen. Aber im Endeffekt kommt es auf die Konfiguration an. Achtung: Docker manipuliert die Firewall und kann selbst Ports öffnen, die du nicht explizit freigegeben hast. D.h. du musst die Container so konfigurieren, dass sie nicht ungewollt Ports öffnen. Das machst du, indem du explizit die Localhost-IP vor den Ports in Docker anführen, sonst werden die Ports nach außen zugänglich.

Ja, tun sie aber im Normalfall nicht und sollte nicht vom schnellen Updaten abhalten. Einfach Unattended Updates anmachen und Benachrichtigungen einrichten, falls ein Neustart benötigt wird. Wenn man Ausfallsicherheit benötigt, besser mit Redundanz zusammen mit gestaffelten Updates arbeiten.

Ja, das gibt es. Für Debian weiß ich es aber nicht. Debian ist so konservativ, ich würde einfach immer updaten, sobald eines zur Verfügung steht.

2 „Gefällt mir“
5

Ich habe bisher beruflich auf über 1000 Linux Servern (RHEL, SLES) und eine Hand voll privater Linux Server/Desktops (OpenSUSE, Ubuntu LTS) bisher nie ein Problem damit gehabt. Meiner Meinung nach sind automatische Updates (täglich/wöchenlich zu einer festen Uhrzeit und wenn möglich gestaged, also zuerst Test, dann Produktion) absolut notwendig, wenn man nicht „zu viel Zeit“ hat und das alles manuell machen möchte oder kann.
:question: Warum magst du sie nicht? Schlechte Erfahrung? Bauchgefühl? Habe ich bisher einfach nur Glück gehabt? …?

:+1:
Ergänzend möchte ich anmerken, dass ich nur noch elliptische Kurven (ed25519) statt RSA verwendet und dass ich den root-Login in der sshd.conf verbiete. Ganz „nett“ ist es auch, wenn man User/Gruppen per /etc/security/access.conf zulässt und alle nicht explizit genannten verbietet:

+ : kind1    : ALL
+ : kind2    : ALL
+ : frau     : ALL
+ : mann     : ALL
+ : root     : LOCAL
- : ALL      : ALL
1 „Gefällt mir“
6

Gute Frage :thinking: Ganz am Anfang war es vermutlich reine Neugier. Ich wollte wissen welche Pakete da gerade aktualisiert werden sollen, für was sie da sind, was hat sich geändert. Jetzt möchte ich bestimmen, was sich wann am System ändert und ob bspw. ein bestimmtes Paket überhaupt notwendig ist. Gelegentlich entferne ich Pakete, die dann keine weitere Abhängigkeit haben oder anderweitig gebraucht werden. Probleme gab es bisher auch nur sehr sehr selten. Im Gegensatz dazu, werden Docker Images bei mir automatisiert durch Watchtower aktuell gehalten. Also ja, es geht eher in Richtung Bauchgefühl/Gewohnheit - ohne „technische“ Begründung :sweat_smile:

7

Der Aufwand eventuell doch einmal ungeplant „ausrücken“ zu müssen statt regelmäßig ein oder mehrere Systeme manuell zu aktualisieren ist i.d.R. viel kleiner. Einzig das „ungeplant“ kann halt auch wirklich mal total unpassend sein. Aber die meisten Linuxe kann man doch auch ganz einfach und schnell nach einem vermurksten Update wieder komplett den Update zurückrollen (OpenSUSE per BTRFS-Snapshot-Rollback, yum/dnf redo/rollback irgendwas) oder einzelne Pakete downgraden. Ich habe bisher (seit 2015) nur einmal mein OpenSUSE Leap (in 2016) zuhause per BTRFS zurückrollen müssen, weil ich bei einem Versionssprung Mist gemacht hatte. Das war ausser Zeit kein weiterer Aufwand :slight_smile:

Also ich kann es echt nur empfehlen, das zu einer passenden Zeit (nachts die Server, Desktop am Sonntag morgen, …) automatisch machen zu lassen.

8

Ganz genau. Und eine der einfachsten Dinge die man für OS-Sicherheit selbst tun kann. Ich update seit Jahren alles vom Handy, Homeserver bis hin zum Laptop automatisch. Selbst auf meinem Laptop mit Arch update ich alle paar Tage und wenn das selbst auf Arch über Jahre funktioniert, ist das unter konservativen Distros oder Docker-Containers kein Problem.

ed25519 scheint sich als Standard sowieso immer mehr durchzusetzen. Wenn man Fido2-Security-Keys hat, am Besten ed25519-sk verwenden um es mit dem Security-Key zu verbinden.

Das bringt nicht viel. Wenn du stattdessen einen Account in der Wheel-Gruppe verwendest, ist Privilege-Escalation sowieso einfach, da es viele Möglichkeiten für Angreifer gibt, das Sudo-Passwort bei der nächsten Eingabe abzugreifen.

9

Das stimmt nur teilweise:

Überall da, wo du nicht alleine root bist, möchtest du nicht, dass andere sich mit ihrem SSH-Pubkey in /root/.ssh/authorized_keys eine „Backdoor“ öffnen/offen halten:

  1. Irgendwann soll diese Person vielleicht nicht mehr auf deinem Linux rumturnen können, das kann sie so aber weiterhin - und sogar als root!
  2. Besonders im Firmenumfeld wollen „Auditoren“ und „Wirtschaftsprüfer“ sehr genau wissen, welcher Mensch sich da eingeloggt und z.B. das System runtergefahren hat. Man kann zwar anhand dess SSH-Fingerprints schon herausfinden, welcher SSH-Key da verwendet wurde… aber wenn der nicht (mehr) z.B. in einem SSH-Key-Manager hinterlegt ist, dann könnte es schon schwer mit der Zuordnung werden:

Accepted publickey for … from … port 12345 ssh2: ED25519 SHA256 …

10

Dann muss man aber ganz anders vorgehen und z.B ein MAC mit RBAC wie Selinux-Rollen ( webadm_r, logadm_r, usw) verwenden, mit denen du auch Root einschränken kannst. Ich denke mal der OP hat im Rahmen der Verwendung im Privatbereich gefragt und nicht in einem professionell gemanagten Umfeld. Wenn er sich statt als Root, als Nutzer der Wheel-Gruppe mit SSH einloggt und sudo verwendet, kann er auch Zugriffslogs überschreiben, und für einen Angreifer macht das in diesem Fall keinen Unterschied zwischen Wheel-Gruppen-Benutzer und Root, da er einfach das Sudo-PW beim nächste eingeben abgreifen kann, z.b. über preload-Attacken.

11

Ich begrenze zusätzlich die Algorithmen.

KexAlgorithms curve25519-sha256@libssh.org
HostKeyAlgorithms ssh-ed25519
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com
MACs hmac-sha2-512-etm@openssh.com
PubkeyAcceptedKeyTypes ssh-ed25519

Unmengen an Login-Versuchen prallen so schon ab, bevor überhaupt eine Verbindung zustande kommt:

May 02 15:22:02 <hostname> sshd[1665248]: Unable to negotiate with 218.92.0.118 port 18441: no matching key exchange method found. Their offer: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 [preauth]
May 02 15:22:44 <hostname> sshd[1665291]: Unable to negotiate with 218.92.0.24 port 23080: no matching key exchange method found. Their offer: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 [preauth]
May 02 15:25:27 <hostname> sshd[1665412]: Unable to negotiate with 180.101.88.196 port 14119: no matching key exchange method found. Their offer: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 [preauth]
2 „Gefällt mir“
12

Danke für den Tipp, sieht echt „sexy“ aus! Ich werde es mal ausprobieren sobald ich Zeit hab. Ist aber halt sehr restriktiv und ein anderer Workflow mit dem Provisioning via Ignition. Kann mir aber vorstellen, dass CoreOS im laufenden Betrieb dann viel weniger Wartung benötigt.

Nices Setup! Ich spiele mit dem Gedanken mir ein Protectli Gerät zuzulegen. Bis dahin muss wohl meine Fritzbox mit Netzwerkisolierung via GastLAN ausreichen.

Genau sowas hab ich gesucht, danke!

Das hab ich tatsächlich vor. Der Zugriff auf den Docker Socket birgt zwar Risiken, aber ich erspare mir dadurch ( hoffentlich ; ) Wartungszeit durch die sauber konfigurierte Nextcloud AIO. Ich wundere ob sich AIO und Cosmos Server in die Wege kommen, da beide auf den Docker Socket zugreifen und AIO potentiell mit Cosmos als Reverse Proxy nicht klar kommt.

Mit einer Firewall Regel, die alle IPs, die auf Port XY zugreifen zur Blocklist hinzufügt? Is das in der Praxis effektiv für einen Privatserver? Also im Gegensatz zu Ports sperren und PortNR ändern?

Macht sinn! Ich werde es mal ausprobieren.

Das trifft sich gut, meine Nitrokeys sind soeben angekommen, danke für den Hinweis!

Genial, das kommt gleich in meine SSH config :smiley:

13

Nur der Mastercontainer hat Zugriff auf den Socket, da er die anderen verwalten muss. AIO hat übrigens ein paar Limitationen. Bspw unterstützt es nur Hosting über die Standardports 443 und 80. Zusätzliches Hardening der Container ist auch nicht ohne weiteres möglich. Der Vorteil ist, dass man als Anfänger weniger Raum für Konfigurationsfehler hat.

14

Ja, in Verbindung mit Fail2ban (siehe z.B. hier oder hier)

Auf den Standardports lauschen dann keine echten Dienste, d.h. SSH, VPN, usw. legt man auf andere Ports. Nur die IP-Adressen, die dann auf einen dieser Standardports zugreifen möchten, könnte man anschließend für alle Ports sperren. Ob an den Standardports dann viele Anfragen ankommen, kommt ganz darauf an, was noch geplant ist (z.B. Geo-Blocking, Tor- und/oder ganze Hoster blockieren, usw.). Je weniger man von vornherein ausschließen kann, umso eher tendiere ich zu Honeypots.

15

Ich kenne Leute, die sich privat einen VPS/Cloudserver/VM „teilen“, aber irgendwann einmal kann ja der Tag kommen, an dem man nicht mehr alle auf demselben Linux Server als Root rumturnen lassen will…