Neuen Root Server einrichgten - Was muss ich beachten?

Alles was in keine andere Systemkategorie passt
Pagefreak
Posts: 1
Joined: 2015-07-09 22:17

Neuen Root Server einrichgten - Was muss ich beachten?

Post by Pagefreak » 2015-07-09 22:27

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!

User avatar
daemotron
Administrator
Administrator
Posts: 2800
Joined: 2004-01-21 17:44

Re: Neuen Root Server einrichgten - Was muss ich beachten?

Post by daemotron » 2015-07-11 19:31

Schau Dir mal folgenden Post an: viewtopic.php?f=63&t=43539#p273494
“Some humans would do anything to see if it was possible to do it. If you put a large switch in some cave somewhere, with a sign on it saying 'End-of-the-World Switch. PLEASE DO NOT TOUCH', the paint wouldn't even have time to dry.” — Terry Pratchett, Thief of Time

derRalfBausP
Posts: 2
Joined: 2015-05-14 19:39

Re: Neuen Root Server einrichgten - Was muss ich beachten?

Post by derRalfBausP » 2015-08-10 21:41

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

User avatar
Joe User
Project Manager
Project Manager
Posts: 11599
Joined: 2003-02-27 01:00
Location: Hamburg

Re: Neuen Root Server einrichgten - Was muss ich beachten?

Post by Joe User » 2015-08-10 22:20

Welche Anleitung hast Du denn da gefunden?
PayPal.Me/JoeUserFreeBSD Remote Installation
Wings for LifeWings for Life World Run

„If there’s more than one possible outcome of a job or task, and one
of those outcomes will result in disaster or an undesirable consequence,
then somebody will do it that way.“ -- Edward Aloysius Murphy Jr.

derRalfBausP
Posts: 2
Joined: 2015-05-14 19:39

Re: Neuen Root Server einrichgten - Was muss ich beachten?

Post by derRalfBausP » 2015-08-11 22:52

Joe User wrote: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!

User avatar
daemotron
Administrator
Administrator
Posts: 2800
Joined: 2004-01-21 17:44

Re: Neuen Root Server einrichgten - Was muss ich beachten?

Post by daemotron » 2015-08-12 00:48

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.
“Some humans would do anything to see if it was possible to do it. If you put a large switch in some cave somewhere, with a sign on it saying 'End-of-the-World Switch. PLEASE DO NOT TOUCH', the paint wouldn't even have time to dry.” — Terry Pratchett, Thief of Time