Grundabsicherung von Linux-Servern

B

benutzer

Member
Guten Abend,

ich würde mich über ein Howto freuen, welches kurz die Grundabsicherung von Debian/Ubuntu-Servern, CentOS-Servern, ... beschreibt und welche entsprechenden Tools auch über das Webinterface von ISPConfig konfiguriert werden können.
 
B

benutzer

Member
Den SSH Port ändern/absichern, den Einsatz von Fail2Ban, die automtische Benachrichtung vom admin bei einem SSH Login, Einstellung von regelmäßige Systemupdates, Überwachung der Dienste mit Monit...
 
D

darkness_08

Member
Zitat von benutzer:
Reicht das schon...?
Klicke in dieses Feld, um es in vollständiger Größe anzuzeigen.
Hey,
es wird kein "das reicht" geben. Damit hast du ja schon mal eine gute Grundlage. Aber du musst schauen was auf deinem Server alles läuft und wie kannst du es weiter absichern. Es gibt sicher noch weitere Möglichkeiten: Alle Verbindungen verschlüsseln (FTP, Http, usw). Bestimmte Passwortstärke, Firewall, LAN-Kabel ziehen :)
Kommt auch drauf an, was alles auf deinem Server gemacht wird. Wer hat alles Zugriff...
 
B

benutzer

Member
Zitat von darkness_08:
Hey,
es wird kein "das reicht" geben. Damit hast du ja schon mal eine gute Grundlage. Aber du musst schauen was auf deinem Server alles läuft und wie kannst du es weiter absichern. Es gibt sicher noch weitere Möglichkeiten: Alle Verbindungen verschlüsseln (FTP, Http, usw). Bestimmte Passwortstärke, Firewall, LAN-Kabel ziehen :)
Kommt auch drauf an, was alles auf deinem Server gemacht wird. Wer hat alles Zugriff...
Klicke in dieses Feld, um es in vollständiger Größe anzuzeigen.
Was meinst du mit "LAN-Kabel ziehen"?
 
planet_fox

planet_fox

Super-Moderator
Also jeder definiert Sicherheit anders. Einige Dinge wurden schon gesagt, ich schmeisse mal Mod Security in die Runde.
 
JeGr

JeGr

Member
SSH Port ändern/absichern
Klicke in dieses Feld, um es in vollständiger Größe anzuzeigen.
Bringt eigentlich nur etwas gegen sehr stupid geschriebene Bots oder IDS Scans, durch Parallelisierung und dickere Bandbreiten ist es aber heut kein Problem mehr das ganze IPvLegacy (IPv4) Internet (ja das GANZE) innerhalb ein paar Stunden nach ein paar Ports zu durchpflügen und ggf. sogar alle Ports zu scannen (das hat ZMAP schon 2013 locker gemacht). Insofern rate ich von Maßnahmen, die lediglich Security through Obscurity (wir verstecken was und hoffen dass niemand zu genau hinsieht) sind eher ab.
Wie schon geschrieben sind Maßnahmen wie Fail2Ban bspw. wesentlich effektiver ohne gleich andere valide Werkzeuge abzusägen (denen man vielleicht keinen alternativen SSH Port mitgeben kann - auch wenn das an sich schon wieder doof ist ;)).
Allerdings im Kopf behalten, dass Fail2Ban noch immer nichts (leider - *seufz*) mit IPv6 anfangen kann!

Was allerdings zum Thema absichern wirklich was gebracht hat ist bei SSH verschiedene Ciphers und Crypto Verfahren abzuschalten und Authentifizierung zu verschärfen. Da fliegen dann beim Handshake auch schon einige tumbe Bots weg noch vor Fail2Ban zuschlägt, weil sie sich mit alten Methoden oder sogar SSH1 verbinden wollen. Bei neuem OpenSSH (ab 6.6) wirkt auch Abschaltung von DSA und ECDSA und Konzentration auf RSA >=2048 und ED25519 mit Keys. Passwort sollte man nur im Einzelfall aktivieren (bspw. für eine extra Usergruppe die das für SFTP o.ä. braucht).
 
M

mzips

Member
Auch wenn das umlegen des SSH Ports Security through Obscurity ist mache ich es dennoch aus dem Folgenden Grund die auth.log sauber bzw überschaubar zu halten.

Fail2Ban geht mit IPV6

Von Hause aus unterstützt die aktuelle Version von Fail2Ban nur IPv4-Adressen. Durch eine recht kleine Anpassung lässt es sich jedoch auch auf IPv6 erweitern. Im folgenden Abschnitt wird beschrieben welche Anpassungen vorgenommen werden müssen, damit Fail2Ban auch IPv6 Adressen erkennt und ggf. blockiert.

Zuerst muss die Datei
Code: 
/usr/bin/ip64tables
als Weiche zwischen IPv4 und IPv6 mit folgendem Inhalt erstellt werden:
Code: 
#!/bin/bash
# iptables-Weiche
LINE=$*

RESULT=`echo $LINE | egrep " ([0-9]{1,3}\.){3}[0-9]{1,3}" | wc -l`
RESULT6=`echo $LINE | egrep "(::[A-Fa-f0-9])|((:[A-Fa-f0-9]{1,4}){2,})" | wc -l `

if [ $RESULT -eq "1" ]; then
    # IPv4
    iptables $LINE
    ERRCODE=$?
   
elif [ $RESULT6 -eq "1" ]; then
    # IPv6
    ip6tables $LINE
    ERRCODE=$?
   
else
    # IPv4 und IPv6
    iptables $LINE
    ERRCODE=$?
    ip6tables $LINE
    if [ $? -ge "1" ]; then
        ERRCODE=$?
    fi
   
fi

exit $ERRCODE

Anschließend machen wir die Datei noch ausführbar:
Code: 
root@meinserver~# chmod +x /usr/bin/ip64tables

Quelle: https://crycode.de/wiki/Fail2Ban
 
JeGr

JeGr

Member
Ahoi,
nee sorry. Fail2Ban ist etwas, das von Haus aus sinnvoll(!) mit IPv6 umgehen muss und nicht durch lustige kleine Hacks dazu gebracht werden sollte. Zumal die Anpassung m.E. nichts wirklich bringt, da hier die einzelne v6 Adresse geblockt wird. Das ist denkbar ungünstig, da mit IPv6 PE und anderen Extensions Clients wechselnde und mehrere IPs bekommen. Die alle einzeln zu blocken kann ganz leicht dazu führen, dass deine Liste riesig groß wird - extrem ungut. Deshalb hat man schon länger bei Fail2Ban darüber diskutiert, dann das ganze Prefix zu blocken, je nach Größe bis zu /64 damit auch wirklich Ruhe ist. Im Gegensatz zu v4 wäre es sonst einfach zu simpel mit einem /64er einen Server totzuärgern.

Deshalb warte ich an der Stelle lieber auf https://github.com/fail2ban/fail2ban/pull/1410
Dort wird mit einem 0.10er Branch bereits v6 und andere Fixes vorbereitet für den Ramp-Up Merge in den Main Tree. Die Wochen kann ich gern noch warten :)

Was auth.log angeht - warum sollte die sauber(er) sein, wenn du den Port verlegst? :O Nur weil sich dann weniger Bots connecten? Das ist eher kontraproduktiv, da du damit auch recht leichte Blocks auf IPs oder Ranges verspielst, die später statt SSH dann andere Ports abklopfen. Wenn die gleich geblockt werden, haben Sie danach am ganzen Server nichts mehr zu lachen. Und da halte ich SSH für einen der robustesten Dienste für sowas. Lieber habe ich OpenSSH als "Catcher" für IPs die ich blocke, als dass man an Mail, Web oder SSL rüttelt. Von all den Diensten ist doch SSH noch der, dem ich am Meisten zutraue :)
Zudem kann man sich mit etwas Finetuning und "Gedächtnis" damit auch gut eine Liste mit IPs zaubern, die man problemlos auch länger blockieren kann.
 
T

thommy

Member
auch wenn das ganze recht alt ist... ;)

ich hab fail2ban so koniguriert, dass 1 falscher Loginversuch über ssh erlaubt ist, danach wird die IP für 1 jahr gesperrt.
In diesem Falle sollte man seinen eigenen Login natürlich definitiv kennen ;)

Man kann also mit fail2ban auch spielen und nicht nur diese pauschalen 10min Block machen. Ich hatte schon Fälle, bei denen ein ganzes /23 bei mir angeklopft hat. Die Notifications daraus waren etwas nervig - seither Blocke ich immer direkt längerfristig
 
N

nowayback

Well-Known Member
Zitat von thommy:
auch wenn das ganze recht alt ist... ;)

ich hab fail2ban so koniguriert, dass 1 falscher Loginversuch über ssh erlaubt ist, danach wird die IP für 1 jahr gesperrt.
In diesem Falle sollte man seinen eigenen Login natürlich definitiv kennen ;)

Man kann also mit fail2ban auch spielen und nicht nur diese pauschalen 10min Block machen. Ich hatte schon Fälle, bei denen ein ganzes /23 bei mir angeklopft hat. Die Notifications daraus waren etwas nervig - seither Blocke ich immer direkt längerfristig
Klicke in dieses Feld, um es in vollständiger Größe anzuzeigen.
Wegen mir kann ein /0 Anklopfen... Wenn es keine Passwortauthentifizierung gibt, was soll passieren?
 
Du musst dich einloggen oder registrieren, um hier zu antworten.

Werbung

Top