Wie sichere ich einen vServer richtig ab.

  • hätte dazuschreiben müssen, dass ich den Server nur für mich verwende, also sicher nie mehr als 3 Verbindungen benötigt werden. Der Wert ist natürlich von jedem an seine Bedürfnisse anzupassen.

  • Zitat von moses;29305

    Eine weitere erwähnenswerte Sache ist die LIMIT-Regel bei der VCP-Firewall.


    Danke, jetzt ist endlich geklärt, welches Limit dort eingetragen gehört :)



    MfG Christian

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

  • Zitat von moses;29815

    hätte dazuschreiben müssen, dass ich den Server nur für mich verwende, also sicher nie mehr als 3 Verbindungen benötigt werden. Der Wert ist natürlich von jedem an seine Bedürfnisse anzupassen.


    Wenn man ein kleinen Vorschlag machen darf. Wenn du das ehe nur für dich verwendest, dann würde ich nur den Port für SSH offen lassen. Den über public key auth sichern. Wenn man noch static IPs oder eine IP, die mehrere Wochen gleich ist, wie bei UM hat, kann man die auch reinsetzen. Den Rest, also alle anderen Services, über einen SSH Tunnel machen.

  • Ich muss auch sagen, danke für diese schöne Zusammenfassung... aber ich habe noch ein paar kleine Anmerkungen:


    1. wäre es fantastisch, wenn ein (V)Server den man sich bei Netcup mietet, standardmäßig _aus_ wäre. Aus dem einfachen Grund, dass die Kiste, bis man dann mal die e-Mail gelesen hat dass der Server bereit ist, ein großes offenes Scheunentor mit Netzwerkanschluss ist. Ich konnte gar nicht schnell genug alle Daemons aus machen und nen Public-Key für's Login erstellen bevor der erste Bot schon einen Portscan gemacht hat.
    2. Finde ich es gut dass sich scheinbar doch viele Sorgen um die Sicherheit ihres Servers machen. Leider wird auch hier im Forum immer wieder auf die Firewall verwiesen. "Leider" weil leicht der Eindruck entstehen kann, diese Firewall würde in irgendeiner Weise die Sicherheit des Servers erhöhen. Zugegeben das war jetzt etwas ketzerisch. Aber der Grundgedanke dahinter ist einfach der, dass ich oft erlebt habe dass die leute nachlässig werden. "Ich hab 'ne Firewall, also bin ich sicher!"


    NEIN!


    Meistens kommt es dann doch so:
    Die Firewall ist aktiv und blockiert jeden Zugriff und lässt nur die Verbindungen zu Ports zu, an denen auch wirklich ein Daemon lauscht.


    Das ganze hat aber einen einfachen Denkfehler. Es bringt nix da zu blocken wo sowieso keiner Lauscht! D.h. eine solche Firewall ist schlichtweg sinnlos.


    Viel wichtiger ist es zu ganz sicher zu wissen welche Dienste überhaupt laufen, wo sie lauschen und wie ich diese absichern kann. Es ist niemandem geholfen wenn ich in der Firewall alles außer Port 80 blocke und auf Port 80 lauscht dann ein Apache mit allen aktivierten Modulen, hübsch PHP und Perl und was-weiß-ich-Code-Ausführer und einer unangepassten Standard-Config.


    Daher möchte ich noch auf einige Hilfreiche Webseiten verweisen:
    APACHE:
    Securing Apache 2: Step-by-Step | Symantec Connect Community
    20 ways to Secure your Apache Configuration


    PHP:
    Securing PHP: Step-by-Step | Symantec Connect Community
    Checklist for Securing PHP Configuration | Ayman Hourieh
    Apache2 Worker mit PHP und fcgid (FastCGI) SuExec auf Debian Lenny » Debian Root


    Ähnliche Anleitungen findet man auch für Postfix/Dovecot etc.


    Und nicht vergessen... am schönsten wäre es wenn jeder Dienst in einem eigenen chroot-jail laufen würde. Leider kenne ich keine Möglichkeit das für jeden Dienst um zu setzen ... aber mindestens für den Apachen (auch mit php und sql) geht das.


    Und ein zum Schluss: Firewall sind wirklich ein tolles Werkzeug, gerade um den Zugriff auf den Server nur von einer IP zu ermöglichen usw. ... aber sie sind halt kein Zaubermittel.

  • Und nicht vergessen... am schönsten wäre es wenn jeder Dienst in einem eigenen chroot-jail laufen würde. Leider kenne ich keine Möglichkeit das für jeden Dienst um zu setzen ... aber mindestens für den Apachen (auch mit php und sql) geht das.


    chroot-jail - Da bekomme ich ja Gänsehaut wenn du das als Sicherheitsfeature verkaufen willst. chroot hat nichts mit Sicherheit zu tun.

    "Security is like an onion - the more you dig in the more you want to cry"

  • Nein... nicht als Sicherheit... aber wenn schon was schief geht dann wird damit nicht ganz so viel mit gerissen. Dass das nicht die Sicherheit an sich erhöht stimmt.
    Oder irre mich da?

  • Was hat chroot mit root zu tun? Ok, root kann es auch benutzen, aber?


    Wenn du mehr Sicherheit haben willst, dann hau den Leuten die Finger ab, die Anleitungen folgender Machart anbieten/empfehlen: Java 7 installieren - Debian - "HowTo für wie installiere ich eine veraltete, unsichere Version einer Software so am System vorbei das es niemand merkt" :evil:

    "Security is like an onion - the more you dig in the more you want to cry"

  • Ich war auch ganz verwundert als mir mal wer sagte: Du brauchst keine Firewall, denn wo nix lauscht da kann nix rein. Hat damals meine ganze Welt zusammengehauen - ist aber wahr hab ich mittlerweile festgestellt :)

  • Naja, es gibt aber auch genügend Programme mit Funktionen, die man nicht unbedingt nutzt. Wenn ich z.B. einen Game-Server nicht von aussen steuern möchte, dann brauch ich auch nicht den Port dafür freigeben. Wird bspw. auch gerne für Server-Viewer genutzt. Und auch sonst gibt es evtl. Ports hinter denen ein Dienst lauscht, den ich aber (erstmal) nicht nutzen möchte. Bei mir ist z.B. FTP die ganze Zeit zu.

    9 von 10 Stimmen in meinem Kopf sagen ich bin nicht verrückt, die letzte summt ständig die Melodie von Tetris.

  • Wer erzählt so etwas? Steht das nicht im Widerspruch zu http://en.wikipedia.org/wiki/Shellcode?

    Muss sagen, von dem habe ich noch nie was gehört, aber genau deswegen finde ich den Thread so interessant, vielen dank für deinen Beitrag!


    Soweit ich mich da jetzt eingelesen habe, kann ein solcher Angriff nur durchgeführt werden, wenn ein Zugriff auf die Maschine besteht bzw. wenn eine verwendete Software einen Fehler aufweist und einen Exploit ausführen kann. Das stimmt soweit oder?


    Natürlich ist es in diesem Fall hilfreich, wenn ein untentdeckter Fehler ausgenützt wird. Dann wird dieser durch die Firewall blockiert.

  • Richtig, der Angreifer muss eine Sicherheitslücke ausnutzen können. Davon gibt es heutzutage ja scheinbar immer mehr und das Ausnutzen ist auch nicht so schwer. Siehe hierzu Metasploit Project - Wikipedia, the free encyclopedia (man beachte seit wann das Programm verfügbar ist) bzw. bei metasploit | Suche (primär aufs Datum schauen, wie häufig das Programm genannt wird).

    "Security is like an onion - the more you dig in the more you want to cry"