adminst
Goto Top

Härtungsguidelines Linux Server

Hallo zusammen
Bei uns müssen diverse alte Linux Systeme konsolidiert und auf einen unterstützen Stand gebracht werden.
Es werden zwei Derivate zentral eingesetzt: RedHat und Debian.

Bevor wie wild Systeme hochgezogen werden wurde jetzt definiert wie sie grob aussehen sollen, bevor
sie mit Ansible provisioniert werden.

Wir möchten nun uns vorher noch dem Thema Härtung widmen.

Habt ihr geeignete Härtungsguidlines welche ihr verlinken oder posten könntet?

Danke und Gruss
adminst

Content-Key: 3948571958

Url: https://administrator.de/contentid/3948571958

Ausgedruckt am: 24.09.2022 um 23:09 Uhr

Mitglied: maretz
Lösung maretz 15.09.2022 um 08:08:09 Uhr
Goto Top
naja - ich würde einfach mal bei den üblichen Maßnahmen bleiben:
- nix unnötiges installieren
- keine Dienste starten die nicht wirklich benutzt werden
- Root-Login per SSH deaktivieren, bestenfalls nur key-login für benutzer zulassen
- das ganze hinter ner Firewall packen bzw. &/ ne firewall aufs System packen die alle Ports zumacht die nicht benötigt werden
- Zugriff auf Dienste ggf. nur per SSH-Forwarding (z.B. Datenbank-Login wenn nötig)

Damit hast du dann schonmal ein gutes Grundgerüst... Natürlich kann man noch viel mehr machen oder es geht eben auch nicht immer alles, das kommt auch darauf an was deine Anforderung ist. Ohne die zu kennen könnte man ja auch sagen "Netzwerkkabel rausziehen, Server abschalten" -> DANN ist der sicher vor Angriffen...
Mitglied: commodity
Lösung commodity 15.09.2022 um 08:37:18 Uhr
Goto Top
Hi,

kennst Du sicher schon:
https://www.debian.org/doc/manuals/securing-debian-manual/index.en.html
https://wiki.debian.org/Hardening

Habe das aber nur auf der Read-List. Es kommt ja sehr auf den Einsatzzweck an. Die Linux-Server, die ich bei meinen (KMU-) Kunden betreibe stehen alle hinter einem Firewall-Router und dienen als V-Host ohne externen Zugriff. Administration erfolgt über VPN. SSH mit Keys, unattended-upgrades ist Pflicht. Da kann ich den Kunden die Kosten für's Härten ersparen, denke ich.

Ausnahme: Ich mache OVPN-Zugänge oft über separate Raspis, die haben dann nur den einen Dienst. Dort kommt zusätzlich noch ein fail2ban drauf. Mehr nicht.

Es werden zwei Derivate zentral eingesetzt: RedHat und Debian.
Wenn ich schon konsolidiere, würde ich auf ein einzelnes Derivat umstellen. Sicherheit hat für mich viel mit Einfachheit/Klarheit in den Abläufen zu tun. Beim User, aber auch beim Admin.

Viele Grüße, commodity
Mitglied: 0xFFFF
0xFFFF 15.09.2022 um 08:39:52 Uhr
Goto Top
Hi,

mir persönlich ist fail2ban sehr wichtig, wenn der Server von außen erreichbar ist.

Ansonsten:
  • Rootuser deaktivieren
  • User mit eingeschränkten Rechten inkl. sudo Recht erstellen
  • Firewall
  • Für jede Applikation eigenen eingeschränkten User erstellen (DB, Webserver, ..)
  • SSH: Port ändern (50k +)
  • SSH: Zertifikat only
  • Wenn Webserver, dann diesen ebenfalls härten

Grüße
Mitglied: Dobby
Lösung Dobby 15.09.2022 um 10:29:39 Uhr
Goto Top
Hallo,

Es werden zwei Derivate zentral eingesetzt: RedHat und Debian.
Haben die denn beide Internetkontakt? Für wie viele Leute sind die Server denn in Benutzung?
Was für Services (Dienste) werden denn darüber abgebildet? Was für ein Gesamtkonzept ist
denn dort vor Ort vorhanden?

Also Debian wird bei uns nur als Abteilungsserver (LAN) eingesetzt und RedHat wenn Internetkontakt besteht.

Server direkt:
- Alle Ports schließen bis auf das Admin Interface (Konfiguration)
- Nur Ports öffnen die zu Diensten gehören die auch laufen sollen
- fail2ban und die Servereigene Firewall aktivieren
- Alle Dokumente und Dateien haben einen Benutzer (per Script mit anacron)
- mit Keys den Zugang absichern und/oder nur Zugang per Console vor Ort über KVM Switch

Fachbücher dazu kaufen (lesen) und/oder Schulungen
Kann alles beides auch von der Steuer abgesetzt werden.
Redhat Enterprise Linux Hardening Guide
Red Hat Training

Unterstützende Maßnahmen
- Firewall vor die Server setzen
- Reverse-Proxy vor die Server
- Server in Jails in Betracht ziehen
- An eine ordentliche DMZ denken
- OSSec mit auf den Servern laufen lassen
- Bei FTP Servern auf S/FTP oder FTP/S setzen
- Keine Layer3 Switche und VLANs in der DMZ benutzen
- Einen DMZ Snort IPS in die DMZ setzen der per SMS meldet
- Eine Admin-Console (alter Laptop) nur für die DMZ Server und nur in der DMZ
- Ein DMZ Radius Server (Alternativ ein kleiner MikroTik Router mit Usermanager)
- Alle Server mit Internetkontakt hinter eine Firewall und eventuell dort dann die öffentliche
IP Adresse auf eine private IP Adresse umsetzen lassen.

Dobby
Mitglied: it-fraggle
it-fraggle 15.09.2022 um 11:00:04 Uhr
Goto Top
Das BSI und CIS haben dafür ausreichend Baselines, die du als Anregung nutzen kannst.
Mitglied: adminst
adminst 15.09.2022 um 11:21:10 Uhr
Goto Top
Hallo zusammen
Danke für die Anregungen. Es ist richtig, es wird zwei Baselines geben. Eine für DMZ Systeme andere für die LAN Systeme. Es sind viele Inputs gekommen.

Welche BSI Baselines können konkret für dieses Vorhaben herangezogen werden?

Danke und Gruss
adminst
Mitglied: LordGurke
Lösung LordGurke 15.09.2022 aktualisiert um 11:30:49 Uhr
Goto Top
Stehen die Systeme in einem LAN oder im Internet?

Ich setze mal zusätzlich auf die Liste:

  • Beschäftigt euch (bei Redhat-Derivaten) mit SeLinux, statt es abzuschalten. Das bringt wirklich was!

  • Deaktiviert das anlegen von Ceonjobs für alle Nutzerkonten. Normalerweise müssen unpriviligierte Nutzer nicht selbst Cronjobs anlegen, das kann root für sie erledigen. Allerdings kann ein Angreifer, der Schadcode in der Identität eines unpriviligierten Nutzers ausführen kann, sich durch Cronjobs dauerhafter einnisten.

  • Arbeitet auch im lokalen Netzwerk mit der lokalen Firewall. Speziell die Debian-Derivate aktivieren durch Installation von irgendetwas auch die zugehörigen Dienste, was den Server angreifbar machen kann. Wenn der Server im Internet steht und ihr statische IP-Adressen habt, könnt ihr den SSH-Port darauf einschränken, um das Grundrauschen abzustellen. Bei Firewallregeln auch IPv6 berücksichtigen, denn auch die fe80-Adressen sind natürlich angreifbar, wenn auch nur aus dem gleichen Netzwerk.

  • Ob man root komplett deaktiviert, sehe ich ambivalent. Aus meiner Sicht reicht es, den Login für root auf Keys zu beschränken, das macht dann auch Backup-Jobs, die das System per SSH sichern, deutlich einfacher.


Zitat von @0xFFFF:
  • SSH: Port ändern (50k +)
Da rate ich dringend von ab, denn das erzeugt ein schlimmeres Sicherheitsproblem.
Port 22 ist ein priviligierter Port, der nur von root gebunden werden kann — so, wie es ein normaler Systemdienst z.B. macht.
Ports oberhalb von 1024 darf aber jeder Benutzer binden, so dass ein Angreifer, der Code durch einen unpriviligierten Nutzer ausführen kann (Lücke in einer Webanwendung zum Beispiel), einen systemd-Dienst oder @reboot-cronjob erstellen kann, der dann den SSH-Dienst ersetzen kann.
Wenn, nach einem Reboot, der Fake-SSH-Dienst schneller startet als der echte, redest du ab dann mit einem manipulierten Server.
Mitglied: 0xFFFF
0xFFFF 15.09.2022 um 11:31:27 Uhr
Goto Top
Da rate ich dringend von ab, denn das erzeugt ein schlimmeres Sicherheitsproblem.
Sehr spannend. Damit hatte ich immer das von Dir erwähnte "Grundrauschen" abgestellt. Da die meisten Bots eben nur 22 abgrasen. In der Regel nutzen einige Leute die Standardports (1-1024) bei gängigen Portscannern. Soviel Geduld haben vermutlich wenige, alle 65k Ports abzuklappern.

Aber vom Grundsatz her, ein Gedanke, über den ich mir Gedanken mache. Danke dafür.

Grüße
Mitglied: LordGurke
LordGurke 15.09.2022 um 11:39:35 Uhr
Goto Top
Also, das ist natürlich ein extremer Edge-Case und du würdest sowas bemerken, weil die SSH-Keys des Servers nicht mehr stimmen — denn die des echten Servers kann der unpriviligierte Nutzer ja nicht lesen.
Und das Verlegen des Ports ist natürlich weiterhin eine sinnvolle Maßnahme gegen Grundrauschen, keine Frage.
Ein alternativer Ansatz ist, eine spezielle, komplexe IPv6-Adresse für den SSH-Dienst zu benutzen, so dass die Bots nicht 16 Bit Portnummer sondern 64 Bit IP-Adresse durchprobieren müssten.
Dann kannst du nur noch IPv6-Only auf den Server verbinden, was aber in den meisten Fällen kein Problem mehr ist.