Frage zur vServer-Absicherung

    Hallo,


    ich habe heute meinen neuen vServer in Betrieb genommen und wollte mir mal Tipps holen, was ich zur weiteren Absicherung meines vServer noch unternehmen könnte. Das hab ich bisher schon gemacht:


    • iptables konfiguriert (alle Ports geschlossen, außer: 80, 443, 22 und nach außen noch 53 für DNS-Anfragen)
    • neuenUser angelegt
    • sshd konfiguriert (PermitRootLogin no, AllowUsers neuenUser alles außer RSAAuthentication disabled, Port 22 auf einen anderen geändert)
    • root und neuenUser neue Passwörter zugewiesen


    Geplante habe ich auf den Ports 80 und 443 noch einen nginx-Server lauschen zu lassen und im Hintergrund dann entsprechende Request an einen Artifactory- und TeamCity-Server weiterzuleiten die in einem Tomcat laufen; diese sollen direkt von Außen aber gar nicht erreichbar sind (keine neuen offenen Ports).


    Mich würde jetzt interessieren, was ihr von dem Setup haltet bzw. ob ihr weitere Schritte unternehmen würdet um den vServer weiter abzusichern.


    Viele Grüße,
    u6f6o

    Zitat von Marcoo

    Fail2Ban wäre noch empfehlenswert.

    Ich hab jetzt mal ein bisschen nach nginx + fail2ban gegoogelt und dabei Folgendes gefunden: How to Secure an nginx Server with Fail2Ban - Apache - nginx, fail2ban, filters, configuration, security, throttling


    Kenne mich mit fail2ban leider noch nicht wirklich aus. Machen die Filter auf der angegebenen Seite Sinn oder habt ihr noch einen Link im Speziellen zum Thema ngxing-fail2ban-Konfiguration?

    @SSH


    Gruppe SSHUsers erstellen


    Code
    addgroup --system sshusers



    Benutzer hinzufügen


    Code
    adduser blabla sshusers



    In /etc/ssh/sshd_config


    LoginGraceTime 30
    AllowGroups sshusers
    PermitRootLogin no
    Strictmodes yes


    Öhm dann könntest du noch Key Login einrichten.

    Grundsätzlich alles in Jails (unter FreeBSD) bzw Linux Container (aka LXC, angeblich in Debian 7 brauchbar) bzw Zones (Solaris) sperren, damit ein Exploit (hoffentlich) nicht gleich den ganzen vServer korrumptiert (weil erstmal auf dem Container ausgebrochen werden muss).


    Auf meiner ToDo-Liste steht auch noch "SSH-Login nur mit SSH-Key und Google Authenticator" und "sudo mit Google Authenticator statt Passwort", aber der Host mit meinem vServer ist seit gestern abend down... *grml*


    Zitat von Homwer

    zusätzlich könntest du noch denn GoogleAuthentificator nutzen.


    How to Secure SSH with Google Authenticator’s Two-Factor Authentication


    was soll auf der Maschine überhaupt laufen?
    Die ganze Sicherheit bringt dir ja nicht viel wenn du FTP Benutzer hast die mir schlechten Passwörtern arbeiten oder Wordpress das regelmäßig neue Exploits aufweist.


    Ich hoffe doch, wenn er schon so eine Frage stellt, wird er keine Dienste laufen lassen, bei denen Zugangsdaten in Klartext durchs Netz gehen ;)
    Und mal ehrlich, gibt es irgendeinen sinnvollen Grund, nicht SCP/SFTP statt FTP zu benutzen?

    Zitat von jot-r1

    [...]
    Auf meiner ToDo-Liste steht auch noch "SSH-Login nur mit SSH-Key und Google Authenticator" und "sudo mit Google Authenticator statt Passwort" [...]


    Funktioniert übrigens beides unter FreeBSD 9.2 und vermutlich mit allem anderen, dass OpenSSH 6.2 dabei hat und wo man das passende PAM-Modul installiert/gebaut bekommt.

    Zitat von RayMD

    Was mir noch einfallen würde: IPsec oder alternativ openvpn und iptables anpassen, sodass nur leute via tunnel drauf kommen.


    Jupp, gute Idee. Und dann am besten die darüber erreichbaren Dienste gar nicht auf der öffentlichen IP des Servers lauschen lassen, sondern nur auf einer im VPN.


    Hmmm... was allerdings unpraktisch is, wenn die User im VPN nicht eh deinen DNS-Server nutzen, der innerhalb des VPNs mit anderen/zusätzlichen Adressen antwortet... Ist etwas doof, wenn das öffentliche DNS verrät, dass sich ultrageheimesmitgliederforum.example.com in einem privaten Netz (10.../8, 172.bla/16, 192.168.../24) versteckt und alles andere unter der Domain auf einen bestimmten Server zeigt.


    Hatte nicht vor n paar Jahren ne Behörde, n LKA oder so, damit ungewollt Informationen über die interne Netzwerktopologie öffentlich zugänglich gemacht? ^^


    PS: IPsec ist nicht gerade was, das man auf unbedarfte User loslassen kann. Coole Sache, um damit Infrastruktur abzusichern (private Netze übers Internet sicher verbinden und so), aber nix, was man nem Enduser zumuten kann.