vps: Netzwerk abschalten während Installation ubuntu

  • Hy,

    vielleicht ein etwas naive Anfängerfrage. Ich habe mir einen neu eingerichteten vps Server auf dem ich statt dem debian ubuntu installieren möchte. Wenn ich es richtig sehe ist es ja nur die unter debian laufende Firewall, welche meinen Server vor Netzwerkzugriffen von außen schützt. Wenn ich da nun ubuntu installiere ist er ja erstmal ohne firewall und ich muss diese noch einrichten. Ist es möglich das Netzwerkinterface vorübergehend abzuschalten oder geht dann die Fernwartung des Servers per Console auch nicht mehr?


    Danke


    q8UTo

  • Die Fernwartung per VNC funktioniert. Aber auf der anderen Seite warum? Es laufen noch keine Dienste und bei der Installation gibst du an, das er alle Updates direkt mit installieren soll. Dann erst einmal Minimalinstallation, ssh absichern und die Firewall nur für ssh öffnen.

    In der VNC Console hast du z.B. Probleme mit C&P.

  • […] Ich habe mir einen neu eingerichteten vps Server auf dem ich statt dem debian ubuntu installieren möchte. Wenn ich es richtig sehe ist es ja nur die unter debian laufende Firewall, welche meinen Server vor Netzwerkzugriffen von außen schützt. Wenn ich da nun ubuntu installiere ist er ja erstmal ohne firewall und ich muss diese noch einrichten. Ist es möglich das Netzwerkinterface vorübergehend abzuschalten oder geht dann die Fernwartung des Servers per Console auch nicht mehr?

    Tatsächlich ist diese Frage gar nicht schlecht. Da normalerweise nach der Installation von Diensten diese auch automatisch gestartet werden und ohne vorbereitete Kon­fi­gu­ra­tions­an­passungen/Updates theoretisch eine Gefährdung bestehen könnte, ist eine präventive, temporäre Abschottung des VPS/RS durchaus sinnvoll. (Windows-Server-Versionen verfahren zumindest bis zum Einspielen von Updates bei einer Neuinstallation schon seit einiger Zeit entsprechend.)


    Im SCP lässt sich die primäre Netzwerkschnittstelle leider nicht deaktivieren, entsprechende Vorkehrungen sind derzeit also manuell über das Installations-/Re­pa­ra­tur-Bootmedium (eingebundenes Festplattenabbild/DVD-Abbild) zu treffen. Denkbar wäre hier die Anpassung einer Ubuntu-LiveCD (ein DVD-Abbild), wobei es zunächst ausreicht, alle infrage kommenden Ports gegen Zugriffe von Dritten (=Fremd-IPs) zu schützen, etwa durch das Anlegen eines ausführbaren Scripts /etc/rc.local:

    Code
    #! /bin/bash
    /sbin/iptables -A INPUT -p tcp -s localhost,10.0.0.0/8,172.16.0.0/16,192.168.0.0/16[,<eigene-IPv4_1>[,<eigene-IPv4_2[,…]]] --dport 22 -j ACCEPT
    /sbin/iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
    /sbin/iptables -A INPUT -p tcp -m tcp --dport 22 -j REJECT --reject-with tcp-reset
    /sbin/ip6tables -A INPUT -p tcp -s ::1[,<eigene-IPv6_1>[,<eigene-IPv6_2>[,…]] --dport 22 -j ACCEPT
    /sbin/ip6tables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
    /sbin/ip6tables -A INPUT -p tcp -m tcp --dport 22 -j REJECT --reject-with tcp-reset
    LOCAL_IP="$(/usr/bin/dig +short 0123456789abcdef.myfritz.net)"
    [[ -n "${LOCAL_IP}" ]] && /sbin/iptables -I INPUT -p tcp -s "${LOCAL_IP}" --match multiport --dports 22[,<Port2>[,<Port3>[,…]]] -j ACCEPT
    exit 0

    Anmerkung: Obiges schützt natürlich nur Port 22, man kann hier eine Schleife/Aufzählung von Ports einbauen (vgl. Option "--match multiport" in der letzten Zei­le des vereinfachten Beispiels), wenn die Liste der Dienstports bekannt ist, und ggf. alle anderen Ports sperren. Wenn keine iptables-Kompatibilitätsschicht vor­han­den ist, muss dies bei neueren Installationen via nftables erledigt werden. (Alternativ könnte man auch beim Bootmedium die Aktivierung der Netz­werk­schnitt­stel­le ver­hin­dern, aber dann kommt man zunächst nicht an externe Updates.) Soll dieser Schutz nach einem Reboot der installierten Ubuntu-Installation bei­be­hal­ten wer­den, ist das Script natürlich auf das Installationsmedium zu übertragen.


    Ein Zugriff via SCP über die virtuelle Konsole lässt sich hierdurch nicht vermeiden (und das wäre in der Regel auch nicht gewollt).

    VServer IOPS Comparison Sheet: https://docs.google.com/spreadsheets/d/1w38zM0Bwbd4VdDCQoi1buo2I-zpwg8e0wVzFGSPh3iE/edit?usp=sharing

    Edited 5 times, last by m_ueberall ().

  • Ich halte das Risiko eines unbefugten Eindringens bei einem frisch installierten und aktualisiertem Ubuntu für sehr gering, wenn noch keine zusätzlichen Dienste laufen. Sogar bei erlaubten root-login per ssh, wenn das Passwort ausreichend lang (und sicher) ist.


    Mein Vorgehen immer:

    Ubuntu ("ohne alles", nur openssl) installieren und aktualisieren.

    fail2ban

    ssh-Port verlegen (muss nicht sein)

    Zusätzlichen user (nicht sudo) für ssh login anlegen

    ssh-login für root verbieten.


    Danach mache ich mir erstmal keine Sorgen mehr und installiere in aller Ruhe Firewall, Dienste und Anwendungen.

  • Voll auf der Seite von aRaphael.


    Firewall ist keine magic bullet. Ich habe auf einigen System sogar grundsätzlich keine Firewall laufen. Ich kenne die Dienste und es laufen auch nur genau die Dienste (und Ports) die ich kenne. Der Sicherheitsgewinn einer Firewall ist also eher marginal.


    Ich denke das ist so das typische in der IT Security "du brauchst einen Virensanner und du brauchst eine Firewall"... nee, denke ich eben halt nicht. Etwas mehr Hirn hilft mehr als die beste Firewall der Welt.


    PS: Bitte kein Flamewar :(

  • Außerdem vergehen ja zwischen Fertigstellung der Installation und Konfiguration vom Server keine ewigkeiten. Der frische „offene“ Server muss ja auch erstmal entdeckt und angegriffen werden

  • Ich persönlich nehme ein relativ sicheres Passwort bei der Erstinstallation, im Anschluss wird aber SSH Keys only login aktiviert, daher ist Fail2ban auch nicht unbedingt wichtig

    Wie Sie sehen, sehen Sie nichts.

  • Was ist mit SSH Keys?

    Ist sicher eine gute und praktische Sache.

    Ich persönlich nutze sie aber nicht immer. Bei vielen Servern muss ich von überall aus zugreifen können. Da bin ich mit Passwörtern besser dran.

    Man kann ja leicht auch lange und sichere Passwörter finden, die man sich merken kann. :) (z.B. "#1Netcup!-#2Ente!-#3Badewanne" wird schwer mit brute-force oder Wörterbuch zu knacken sein und ist sicher leichter zu merken als 41!agZH34$h#c4242111Elf ^^ )


    Der frische „offene“ Server muss ja auch erstmal entdeckt und angegriffen werden

    Also das ist bei mir eigentlich fast immer der Fall.

    Wenn ich einen neuen Server habe, gehen die Loginversuche per ssh regelmäßig sofort los.

  • Also das ist bei mir eigentlich fast immer der Fall.

    Wenn ich einen neuen Server habe, gehen die Loginversuche per ssh regelmäßig sofort los.

    Kann ich bestätigen, ist bei Cloud Anbietern (rotes H, Froschschenkel Server) aber meist schlimmer als bei Netcup, meine Theorie ist dass man da halt nicht an Server gebunden ist

    Wie Sie sehen, sehen Sie nichts.

  • Ich persönlich nehme ein relativ sicheres Passwort bei der Erstinstallation, im Anschluss wird aber SSH Keys only login aktiviert, daher ist Fail2ban auch nicht unbedingt wichtig

    Fail2ban schuetzt nicht den SSH-Zugang, sondern es schuetzt den Logfile. Mit Fail2ban braucht ein Angreifer nur laenger, um das Passwort zu erraten, Fail2ban macht das nicht unmoeglich. Aber der Logfile laeuft schnell ueber, wenn man keine maschinellen Brute-Force Angriffe unterbindet. Und eine volle Partition kann unangenehme Folgen haben.

  • Fail2ban schuetzt nicht den SSH-Zugang, sondern es schuetzt den Logfile.

    das meinst du nicht ernst, oder?! :S

    fail2ban reduziert die angriffsfrequenz, nicht mehr und nicht weniger.

    daß dadurch das logfile nicht/später überläuft, ist nur ein bedingter nebeneffekt.

    »Hauptsache BogoMIPS!«

    Anas Ananas

    Edited 4 times, last by Olivetti ().

    Thanks 1
  • das meinst du nicht ernst, oder?! :S

    fail2ban reduziert die angriffsfrequenz, nicht mehr und nicht weniger.

    daß dadurch das logfile nicht/später überläuft, ist nur ein bedingter nebeneffekt.

    Dass fail2ban die Angiffsfrequenz reduziert, heißt ja genau, dass es eben "nur" länger dauert, das Passwort oder in meinem Fall den Key zu knacken. Allerdings macht dieses "nur" eben doch einen gigantischen Unterschied ib der Praxis, also ob zig Versuche pro Sekunde oder einen alle 32 Tage :D;). Das verlangsamt dann auch ein größeres Botnetz ein wenig. Zumal der geknackte Key nur bedeutet, dass die Raterei mit dem Keyphrase weitergeht. Dass ich spätestens den geknackten Key dann aber sofort merke ist eh klar, Da werden entsprechende IPs dann eben endgültig entsorgt und jede mir unbekannte IP mit einem korrekten Key natürlich auch. Dann wird noch in aller Gemütsruhe der Key getauscht.... :D Nächste Runde bitte. Ohne fai2ban würde das stressiger ablaufen.Und ja, das Logfile ist tatsächlich auch etwas leerer.

  • und deswegen schützt fail2ban NICHT den ssh-zugang?! ;(

    Noe, f2b schützt alle Dienste für die du das einrichtest.

    Wenn man ein volllaufendes /var/log verhindern will, dann gibt man den eh eine eigene Partition und konfiguriert logrotate um. vielleicht noch die Logs extern verschieben usw.

  • Die unangenehmsten Angriffsversuche laufen ja sowieso auf Layer 7

    Es nützt die tollste iftables-Konfiguration nichts, wenn das Wordpress-Plugin löchrig ist. ;)

    Wenn ich mir so ansehe, was meine modsecurity-WAF so täglich abfängt... :huh: