Härtungsguidelines Linux Server

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.

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

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

Hallo,

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

Das BSI und CIS haben dafür ausreichend Baselines, die du als Anregung nutzen kannst.

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.

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.

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