Neuen Root Server einrichgten - Was muss ich beachten?

[Pagefreak]

Hallo liebe Community,

ich habe mir vorhin einen Root Server bestellt. Ich habe bereits mehrere Server gehabt jedoch ist das schon ne Weile her. Nun wollt ich fragen was ich beachten sollte und wie ich den Server richtig absicher. Zunächst wollte ich erstmal den SSH Port umändern und den Login auf Keyfile umstellen. Anschließend habe ich vor Fail2Ban zu installieren und zu konfigurieren. Was muss ich noch beachten und habt ihr noch Sicherheitstipps für mich?

Vielen Dank im vorraus!

[daemotron]

Schau Dir mal folgenden Post an: viewtopic.php?f=63&t=43539#p273494

[derRalfBausP]

Stand vor ein paar Tagen vor genau dem selben Problem. Falls du noch suchst, habe ich eine super Anleitung gefunden!

[Joe User]

Welche Anleitung hast Du denn da gefunden?

[derRalfBausP]

Welche Anleitung hast Du denn da gefunden?

Bin durch Zufall drauf gestoßen als ich nach der Einrichtung von Linux Servern gegoogelt hab.

https://www.accelerated.de/de/tutorials/server-security

Da ist kurz und bündig erklärt wie man Fail2ban installiert. Unter den Tutorials sind auch noch andere interessante Sachen, die eventuell nützlich sein könnten!

Hab bei mir nen kleinen Linux Server aufgesetzt als FileServer und Apache Server zum testen. Das ganze hab ich dann per Fritzbox nach aussen verfügbar gemacht um ein bisschen Webpages zu basteln ohne mir gleich Webspace mieten zu müssen. Jetzt läuft es aber dennoch drauf raus, dass ich wohl mieten werde. Die Upload Performance von DSL 16000 ist nicht ganz so prickelnd wie ich feststellen musste ^^

Hoffe dir bringt der Link etwas!

[daemotron]

Hab's eben mal überflogen. IMO sind einige der dort gesagten Dinge mit Vorsicht zu genießen:

SSH
[technisch] DSA Schlüssel sollten heute auf öffentlich erreichbaren Servern nicht mehr verwendet werden. Erste Wahl wäre Ed25519, RSA dann zweite Wahl. Außerdem sollte das neuere Format für private Schlüsseldateien genutzt werden (bei RSA muss das über -o erzwungen werden, bei Ed25519 wird es automatisch genutzt).

[Verständnis] Aus dem Text geht nicht eindeutig und klar hervor, dass die Schlüsselerzeugung auf einem sicheren lokalen System erfolgen muss und nur der öffentliche Schlüssel auf den Server kopiert werden darf.

mod_security
Kann eine gute Idee sein, kann aber auch schwere Nebenwirkungen haben, die im Text leider nicht erwähnt werden. mod_security hilft (bei entsprechend gutem Regelwerk) recht gut gegen URL injection Angriffe, und eingeschränkt auch gegen XSS. Allerdings kostet das Filtern jedes Requests auch zusätzliche Ressourcen; die Seitenauslieferung wird messbar verzögert. Einige Applikationen funktionieren mit dem Standard-Regelwerk nicht mehr, da sie POST oder GET Daten etwas zu nachlässig handhaben. Das spricht natürlich nicht für die Qualität diese Anwendungen, aber man hat ja nicht immer eine Wahl...

Suhosin
wurde eine ganze Weile lang nicht weiterentwickelt und flog deshalb u. a. bei Debian und OpenSUSE raus. Der Suhosin Patch selbst ist nur für nicht mehr unterstützte Versionen verfügbar (die letzte unterstützte Version ist 5.3.9, aktuell unterstützte Zweige sind 5.4, 5.5 und 5.6 - 7.0 ist schon im Beta-Stadium). Mittlerweile scheint Stefan Esser aber die Arbeit an der Suhosin Erweiterung wieder aufgenommen zu haben.

Portknocking
Da fehlt ein deutlicher Warnhinweis, dass man sich auch ganz gut selbst damit aussperren kann (z. B. bei Fehlfunktion des Paketfilters)

fail2ban
Automatische Intrusion Prevention ist nicht ganz ungefährlich - gerade bei typischen RootServern würde ich davon abraten, wenn man selbst aus einem dynamischen IP Pool auf den Server zugreift. Es besteht immerhin die Chance, dass ein Angreifer oder ein Bot zufällig denselben Pool nutzt - oder ein böswilliger Angreifer per Spoofing eine IP aus dem Bereich Deines Providers vortäuscht, um Dich gezielt auszusperren. Wenn man schon automatisiert sperrt, dann bitte auch automatisiert gesperrte Adressen nach Ablauf einer Karenzzeit wieder freigeben!

rkhunter
Ist grundsätzlich eine gute Idee, aber hier schlecht gemacht: Wird rkhunter wie dort beschrieben eingesetzt, ist es nicht viel mehr als eine Beruhigungspille für den Admin. Wer zu solchen Tools greift, tut das, weil er in Betracht zieht, dass das System bereits kompromittiert wurde und ggf. Binaries manipuliert wurden. Das erste Binary, dass ich als Angreifer manipulieren würde, wäre rkhunter (so es denn auf dem System vorhanden ist). Effektiv kann man mit rkhunter also nur dann nach Rootkits suchen, wenn es aus einer manipulationssicheren Quelle stammt. Am besten baut man sich zu Hause (ggf. in einer virtuellen Maschine) ein statisches Binary und lädt das bei Bedarf hoch - das minimiert die Chance eines manipulierten rkhunter Binaries.

A propos Rootkit: klassische Rootkits sind sowas von 90er (und ein bisschen 2000er) - spätestens seit Blue Pill kennen Angreifer eine ganz andere Form von Rootkit, denen mit Tools à la rkhunter nicht beizukommen ist (das heißt aber leider nicht, dass klassische Rootkits ausgestorben sind - es gibt halt auch Retro-Cyberkriminelle...)

Insgesamt
bleibt die Geschichte recht oberflächlich. Da werden ein paar grundlegende Dinge angerissen und dann unten im Text von "umfangreicher Absicherung" gesprochen. Vielleicht war der Zusammenhang so vom Autor gar nicht gewollt; potenziell kann die Botschaft dennoch so ankommen. Umfangreiche Absicherung sieht jedoch definitiv anders aus - hier geht es dann um auf Systemebene um erweitertes Berechtigungsmanagement (incl. MAC und ACL), Tuning von sicherheitsrelevanten Parametern (z. B. sysctl), Sandboxing kritischer Prozesse (z. B. mittels grsecurity chroot), Monitoring, fortgeschrittene Intrusion Detection (z. B. mittels Audit, Accounting, etc.), etc. Auf Prozessebene dann um Sicherheitsmanagement, Patching Policies, Backup-Strategien, Reaktionskonzepte für den Fall der Fälle, Untersetzungskonzepte in der Abwehr bestimmter Angriffsformen, Identifikation möglicher Angriffe durch Audits, Verfolgung aktueller Entwicklungen rund um Sicherheit und die entsprechende Reaktion durch Anpassung von Software, Konfiguration oder Abläufen - kurz, da geht es um eine spezielle Form von Risikomanagement.