Grundabsicherung von Linux-Servern

Dieses Thema im Forum "Ideen für neue Howtos" wurde erstellt von benutzer, 9. Mai 2016.

  1. benutzer

    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.
     
  2. robotto7831a

    robotto7831a Member

    Was verstehst Du unter Grundabsicherung?
     
  3. benutzer

    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...
     
  4. robotto7831a

    robotto7831a Member

    Da hast Du doch schon mal einen bunten Blumenstrauß an Maßnahmen.

    Root Login über SSH verbieten.
     
  5. benutzer

    benutzer Member

    Reicht das schon...?
     
  6. nowayback

    nowayback Well-Known Member

    und ssh verbindung mit passwort verbieten ;)
     
  7. darkness_08

    darkness_08 Member

    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...
     
  8. benutzer

    benutzer Member

    Was meinst du mit "LAN-Kabel ziehen"?
     
  9. planet_fox

    planet_fox Super-Moderator

    Also jeder definiert Sicherheit anders. Einige Dinge wurden schon gesagt, ich schmeisse mal Mod Security in die Runde.
     
  10. darkness_08

    darkness_08 Member

    Das war ironisch gemeint :D
     
  11. nowayback

    nowayback Well-Known Member

    du musst auch noch tastatur und maus abziehen um layer 8 fehler zu vermeiden
     
    sebastianh gefällt das.
  12. JeGr

    JeGr Member

    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).
     
  13. mzips

    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
     
  14. 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.
     

Diese Seite empfehlen