Wie sichere ich einen vServer richtig ab.

  • Da Sicherheit bei einem Server kein uninteressantes Thema sein sollte, ist es für Admins sehr wichitg ein gewisses Grundwissen zu haben, bzw sich anzueigenen da man ja bekantlicherweil in einem gewissen Bereich für seinen Server haftbar gemacht weredn kann.


    Ich möchte hier einmal eine Anleitung erarbeiten wie man seinen Server grundsätzlich absichern sollte um ungewünschte Hackerangriffe abzuwehren.


    Diese ist keinenfalls als vollständig anzusehen, aber mit Sicherheit ein guter Anfang.
    Dies ist nicht alles auf meinem Mist gewachsen, sondern ist eine Sammlung von Informationen

    Einleitung:


    Zunächst solltet man sein System immer aktuell halten:


    Bei Debiandistributionen:


    Quote

    apt-get update dann apt-get (dist-)upgrade

    Die Firewall (im V-Server Controll Panel) sollte so konfiguriert sein, dass nur die Ports erreichbar (offen) sind, die man wirklich braucht. D.h. man Sperrt alle Ports außer SSH*, FTP*, Web, POP/SMTP Ports.


    Quote

    * Der SSH-Port sowie der FTP Port kann auch gesperrt werden, da man ihn bei Bedarf innerhalb vion 30 Sekunden entsperren kann

    Sichere Passwörter verwenden:


    ein sicheres Passwort ist nicht:

    Quote

    test123

    ein sicheres passwort wäre:

    Quote

    !<t31!carolin77>&<t83!werner75>!

    Natürlich ist das schwer zu merken, dafür aber auch schwer zu knacken.


    Weitere Informationen über Linux und Serveradministration die man sich auf jeden Fall durchlesen sollte findet ihr hier:



    So nun aber zum eigentlichen Tutorial



    1. Regelmäßige Prüfung eurer Log Files.


    Eure Logs findet ihr meist unter /var ,weitere unter /var/log
    Diese müssen regelmäßig, am besten täglich auf irgendwelche Auffälligkeiten hin geprüft werden.


    Man kann sich auch die Logfile per Mail zusenden lassen (=> Google)


    2. Rootlogin verbieten und SSH-Port ändern


    2.1 SSH Port ändern


    Obwohl das ändern des SSH Ports nur eine Scheinsicherheit ist, lassen sich damit jedoch sehr gut automatisierte angriffe abwehren, den den Hackbots ist es zu viel Aufwand jeden Port zu scannen.
    Ich persönlich empfehle Ports ab 40000.

    2.2 Rootlogin


    Dieser sollte nicht für Root erlaubt sein, sondern für einen unpreviligierten User, mit einem vernünftigen Passwort, eventuell einem Key, der auf dem lokalen Rechner liegt


    Man verbietet den Root Login indem man in der /etc/ssh/sshd_config die option

    Quote

    PermitRootLogin yes


    auf no setzt.


    Schaut dabei auch gleich ob ihr in der sshd_conf euer SSH auf
    Protokoll 2 gestellt habt.
    (Das ist bei Netcup eigentlich automatisch der Fall)


    Ein weiterer Punkt wäre den SSH-Port per Firewall zu sperren, wenn man ihn nicht benötigt.



    3. Der Mailserver


    Dieser sollte kein offenes Relay darstellen. Bei einem offenen Relay kann jeder über deinen Server irgendwas verschicken, eben auch Spam.


    Ausserdem sollten die bestehenden Zugänge vernünftig abgesichert werden, und die Passwörter sauber gesetzt werden.


    Zum Schluss kann man sich überlegen, ob man den Zugang nur noch über SSL erlauben will, denn sonst könnte jemand den gesammten Netzwerkverkehr mitlesen.


    Wie das funktioniert, ist bei den einzelnen Mail-Servern unterschiedlich.
    Hier mal ein Beispiel für den meist verbreiteten MailServer Postfix


    Quote

    Hier findet ihr alles was dazu notwenig ist.


    Überprüfen sollte man abschließend ob ein offenes Relay existiert. Das kann an auf folgender Website machen:


    http://www.abuse.net/relay.html


    Sollte das der Fall sein, ist eurer Server auf dem besten Weg dazu eine Spamschleuder zu werden. Also alle offenen Relays sofort schließen



    3. Der Webserver


    Hier sollten die Zugriffsrechte für Verzeichnisse sauber gesetzt sein, so dass man nicht einfach irgendwohin auf dem Server gelangen kann.


    Des Weiteren sollten wichtige Bereiche, wie Adminbereiche, SysCP oder phpmyAdmin, mit einem Passwort geschützt werden; Stichwort HtAccess.
    http://de.selfhtml.org/servercgi/server/htaccess.htm
    Eine Weitere Möglichkeit besteht in der
    Änderung eurer Konfigurationsdatei des Webservers. Indem man einen Alias in der Config setzt und einen ungewöhnlichen Namen benutzt, wird PHPmyAdmin deutlich schwerer zu erreichen.

    Ausserdem sollte man darauf achten, dass einzelne Skriptsprache wie bespielsweise PHP richtig abgesichert sind.
    Hier gibt es Konfigurationen die das System nicht wirklich sicher machen.


    Bei PHP beispielsweile sollten folgende Punkte in der PHP.ini folgendermaßen konfigueriert sein:


    Quote

    disable_functions = show_source, exec, shell_exec, system, popen, proc_open, proc_nice, ini_restore, passthru, dl
    register_globals = Off
    allow_url_fopen = Off
    display_errors = Off
    open_basedir = [path to the directory of the web server / virtual host]
    safe_mode = On


    Safe_Mode ist immer eine kritische Sache!, ich zitiere hier jetzt einfach mal killerbees19:


    Quote

    Der Safe Mode bietet eigentlich nur eine halbe Sicherheit und verursacht mehr Probleme als er bringt. Denn in vielen Modulen ist er falsch oder unvollständig integriert. Mit PHP 6 wird er übrigens auch entfernt werden, nicht ohne Grund...
    Empfehlenswert ist auf jeden Fall die Fehlerausgaben von PHP so hoch wie möglich zu stellen (E_STRICT wäre ja ideal :p )


    hier möchte ich noch den folgenden Link mit anhängen:


    http://www.strassenprogrammier…hern-hacker_tipp_497.html




    3.1 MySQL Server


    Ich persönlich habe den MySQL Port von außen per Firewall gesperrt. Ich denke das ist die einfachste Lösung. Wichtig ist hier wieder die korrekte Konfiuration von Webserver und PHP, denn durch Fehleinstellungen, gelangt der Angreifer sehr schnell an eure MySQL Zugangsdaten und kann beispielsweise eine Datenbank mit Kinderpornolinks anlegen.
    Das würde euch mit Sicherheit nicht gefallen.




    4. FTP-Server


    Ich persönlich empfehle hier vsftp. Ein einfacher uns sicherer FTP-Server
    Was wichtig ist, Wenn ihr den FTP nicht braucht sperrt eueren FTP Port (21) per Firewall.


    [B]Richtige Konfiguration:[/B] sftpd ist von Haus aus so konfiguriert, dass anonyme Benutzer sich einloggen dürfen. Sie dürfen in der Standardkonfiguration jedoch nur in /home/ftp lesen. Sie dürfen dieses Verzeichnis nicht verlassen und auch nirgends schreiben. Möchte man anonyme Logins komplett deaktivieren, so müsste man hier

    Code
    1. # Allow anonymous FTP? (Beware - allowed by default if you comment this out).
    2. anonymous_enable=YES

    das YES in NO ändern.


    Als nächstes sollte man Lokalen Benutzern den Login erlauben:

    Code
    1. local_enable=YES

    Damit geschrieben werden kann ist diese Zeile hier wichtig:

    Code
    1. write_enable=YES

    Die letzte wichtige Option wäre es die lokalen Benutzer auf ihr Homeverzeichnis - also /home/benutzername - zu beschränken.
    Dies macht man folgendermaßen:


    Code
    1. chroot_local_user=YES

    Bitte auch hier noch weiterlesen: http://wiki.ubuntuusers.de/vsftpd






    5. Nützliche Tools
    Das System sollte regelmäsig geupdatet werden, und immer auf dem neuesten Stand sein.


    Nützlich kann immer sein:





    6. Die Programme am besten per Cronjob ausführen


    Es ist wichitg, dass Ihr so früh wie möglich von einer Infektion erfahrt und darauf reagieren könnt.
    Dieses Skript (Ursprung) führt ClamAV aus (der dann die Verzeichnisse /root, /home und /tmp scannt), chkrootkit und rkhunter -- und mailt Euch dann die Logfiles.


    --> E-Mail Adresse ersetzen, und ggf. die Logfile Pfade ändern. Der Ordner muss exisitieren, die Dateien selbst werden dann erstellt, wenn das Script ausgeführt wird (nach Datum sortiert).



    7. Keine schlecht programmierte unsichere Scripte verwenden




    So. Ich denke mit diesen Informationen ist für jeden der ein bisschen bereit ist weiterzulesen und Interesse hat möglich seinen vServer ersteinmal eine gewisse Grundsicherheit zu geben. Einwas muss man sich jedoch bewusst sein. Ein Server kann nie 100% sicher sein, das wurde erst in den letzten Tagen wieder deutlich.



  • Netter Beitrag, trotzdem mal ein paar Anregungen:


    Scaleo;4978 wrote:

    Debian: apt-get update dann apt-get (dist-)upgrade
    Das kann man auch schön automatisieren: (=>Google)


    Zumindestens hier sollte man vielleicht auf die Automatisierung verzichten. Update Benachrichtigung ist in Ordnung, aber Installation ohne Nachfrage - egal ob man das Update jetzt will, aus welchem Grund auch immer - ist nicht nicht empfehlenswert. ;)


    Scaleo;4978 wrote:

    2. Rootlogin verbieten und SSH-Port ändern


    Es kann auch Sinn machen den SSH Port komplett über die Firewall zu sperren und wen man am vServer arbeitet nur seine aktuelle IP dafür freizugeben.


    Scaleo;4978 wrote:

    Bei PHP beispielsweile sollten folgende Punkte in der PHP.ini folgendermaßen konfigueriert sein:


    Der Safe Mode bietet eigentlich nur eine halbe Sicherheit und verursacht mehr Probleme als er bringt. Denn in vielen Modulen ist er falsch oder unvollständig integriert. Mit PHP 6 wird er übrigens auch entfernt werden, nicht ohne Grund... ;)


    Scaleo;4978 wrote:

    (z.B. über prepend_file in der php.ini), das sicher dann nochmal ab. Kann ja nix schaden.


    Naja, das wäre dann wieder eine Pseudo Sicherheit. Man kann niemals alles bereinigen was der Programmierer im Script vllt anrichtet. Empfehlenswert ist auf jeden Fall die Fehlerausgaben von PHP so hoch wie möglich zu stellen (E_STRICT wäre ja ideal :p ), die Ausgaben muss man ja nicht einmal anzeigen lassen, reicht ja wenn sie geloggt werden ;)



    MfG Christian

  • Was mir noch einfällt: Scripte/Programme verwenden die bestimmte Logs automatisch täglich durchsuchen und potenzielle Angreifer bannen (je nach Dienst unterschiedlich, wie man sie dann bannt). :)


    Man kann die IP's auch direkt in der Firewall per Script sperren lassen: http://forum.netcup.de/showthread.php?t=425&page=2#post2751



    MfG Christian

  • Ich habe auch noch eine kleine Anregung...bei meinem vServer habe ich die ssh-Anmeldung per Passwort noch unterbunden und arbeite ausschließlich mit Public-Keys (root-Anmeldung ist abgeschaltet und der Port verlegt...)



    edit: das wichtigste Habe ich vergessen^^ Sehr schöner Beitrag, Gefällt mir sehr gut

  • Dankeschön.


    Ich sag mal so ich halte es für sehr wichtig, dass es solche Beiträge gibt: Als ich damals meinen ersten Server hatte, hatte ich keine Ahnung von der Materie. Heutzutage empfinde ich das als gröbst fahrlässig. Ich würde nie mehr so anfangen. Aber es gibt genug die es machen. Ich war ja schließlich auch so doof.


    Mein einziger Vorteil war, das ich ein System mit Confixx hatte bei einem anderen Hoster der zwar einen scheiß support hatte aber dafür eine sehr gute Grundkonfiguration zur Verfügung gestellt aht.


    Heute mag ich Confixx nicht mehr, da es mir zu viel im System verändert.
    Wie gesagt. Ich will mit diesem Thread einfach Neuadmins davor bewahren aufgrund einer unüberlegten Handlung (Anmietung eines Servers) sich ihr Leben zu versauen, weil sie riesige Summen Strafe zahlen müssen.


    Ich hatte selbst das Glück, dass mir soetwas nie passiert ist, aber dieses Glück hat sicherlich nicht jeder.

  • Scaleo;4987 wrote:

    Ich will mit diesem Thread einfach verrückte Leute davor bewahren aufgrund einer unüberlegten Handlung (Anmietung eines Servers) sich ihr Leben zu versauen, weil sie riesige Summen Strafe zahlen müssen.


    Der Grundgedanke ist gut, aber die erwähnten Leute schauen sich weder davor noch danach in Foren um, um sich zu informieren. Falls überhaupt ein Forum aufgesucht wird, dann meistens nur, wenn das Kind schon im Brunnen liegt; sprich nichts mehr geht, Fehlermeldungen auftreten, usw.



    Zum eigentlichen Thema möchte ich noch anmerken das ...

    Scaleo wrote:

    Achtet also darauf, dass Ihr sauber programmiert, alle Benutzereingaben abfangt und ggf. von Schadcode bereinigt.


    ...eigentlich niemals versucht werden sollte unsaubere Eingaben oder Attacken zu "korrigieren", sondern die Scriptausführung sofort abzubrechen und eine Meldung ausgeben. Zu leicht könnte man etwas übersehen beim säubern oder stößt auf eine bis dato unbekannte Attacke. In dem Fall ist es immer besser mit einer Whitelist zu arbeiten und alles andere gnadenlos abzulehnen.
    Das bezieht sich aber eher auf PHP und Konsorten und hat nicht direkt etwas mit dem Absichern eines vServers zu tun.


    Ansonsten sollte man unbedingt noch SysCP und phpMyAdmin absichern, z.B. indem man einen Alias in der Apache Config setzt und einen ungewöhnlichen Namen benutzt. Zusätzlich den Zugriff per .htaccess absichern.

  • Quote

    Der Grundgedanke ist gut, aber die erwähnten Leute schauen sich weder davor noch danach in Foren um, um sich zu informieren. Falls überhaupt ein Forum aufgesucht wird, dann meistens nur, wenn das Kind schon im Brunnen liegt; sprich nichts mehr geht, Fehlermeldungen auftreten, usw.


    Ja das ist ja das Traurige.




    Gute Idee werde ich mit in das Tutorial einfügen.


    Ich denke wenn noch mehr so gute Ideen kommen wird das Ding richtig brauchbar.

  • Quote

    Der Grundgedanke ist gut, aber die erwähnten Leute schauen sich weder davor noch danach in Foren um, um sich zu informieren. Falls überhaupt ein Forum aufgesucht wird, dann meistens nur, wenn das Kind schon im Brunnen liegt; sprich nichts mehr geht, Fehlermeldungen auftreten, usw.


    dann störts hoffentlich keinen das ich erst im forum nerv bevor ich nach dem prinzip learning by doing vorgehe :D
    ahjo und
    isn sehr geiles tut damit kann man eigentlich garnix mehr falsch


    Danke dafür

  • Danke für diesen Beitrag, einige Tipps fand ich sehr gut, die ich auch umsetzen werde.


    Die Firewall muss ich durch netcup freischalten lassen oder? Warum ist die eigentlich nicht von vornerein an?

  • japs die muß vom support freigeschaltet werden und wennde mich jetz fragst wieso die nich von vorneherein an is hmm jute frage aber solang netcup das verwaltet kannst dir wenigstens FAST sicher sein das keine unntigen ports offen sind........jedenfalls bei mir der fall das alles so schon dicht is aussa das was isch will halt ^^

  • KaaN;6445 wrote:

    Die Firewall muss ich durch netcup freischalten lassen oder? Warum ist die eigentlich nicht von vornerein an?


    sugersgroer;6446 wrote:

    japs die muß vom support freigeschaltet werden und wennde mich jetz fragst wieso die nich von vorneherein an is hmm jute frage aber solang netcup das verwaltet kannst dir wenigstens FAST sicher sein das keine unntigen ports offen sind........jedenfalls bei mir der fall das alles so schon dicht is aussa das was isch will halt ^^



    So sieht's aus. Die Firewall in der Hand von unerfahrenen Usern kann ein ernsthaftes Sicherheitsrisiko, für den eigenen vServer und in Folge dessen auch für Node-Nachbarn, darstellen. Etwas übertrieben vielleicht vergleichbar mit der Situation, einem 5-jährigen Kind den Schlüssel zum Waffenschrank zum spielen zu geben. ;)

  • koweto;6449 wrote:

    So sieht's aus. Die Firewall in der Hand von unerfahrenen Usern kann ein ernsthaftes Sicherheitsrisiko, für den eigenen vServer und in Folge dessen auch für Node-Nachbarn, darstellen.


    Stehe ich heute auf der Leitung oder verstehe ich dich gerade wirklich nicht? Was soll daran ein Sicherheitsrisiko für andere User am Node sein?



    MfG Christian

  • koweto;6449 wrote:

    So sieht's aus. Die Firewall in der Hand von unerfahrenen Usern kann ein ernsthaftes Sicherheitsrisiko, für den eigenen vServer und in Folge dessen auch für Node-Nachbarn, darstellen. Etwas übertrieben vielleicht vergleichbar mit der Situation, einem 5-jährigen Kind den Schlüssel zum Waffenschrank zum spielen zu geben. ;)


    Ich hatte eigentlich vor so ziemlich alle Ports zu schliessen ^^ (also auch meinen SSH, FTP etc.). Hätte es einfacher gefunden die Ports per VCP zu schliessen als mit iptables rumzuhantieren. Das zweitere ist sogar Fehleranfälliger und somit unsicherer behaupte ich mal.

  • Quote

    Ich hatte eigentlich vor so ziemlich alle Ports zu schliessen ^^ (also auch meinen SSH, FTP etc.). Hätte es einfacher gefunden die Ports per VCP zu schliessen als mit iptables rumzuhantieren. Das zweitere ist sogar Fehleranfälliger und somit unsicherer behaupte ich mal.


    Iptables is garnet verfügbar auf den vservern soweit ich weiß^^ hatte das problem auch schonmal und wollte bissl was dicht machen aber okay ^^


    wieso willst du eigentlich nen ssh port und den ftp port schließen?? also tu was du nich lassen kannst aber solltest vielleicht dran denken die ports vorher zu ändern das du selber überhaupt noch auf dein server kommst ^^

  • sugersgroer;6471 wrote:

    Iptables is garnet verfügbar auf den vservern soweit ich weiß^^ hatte das problem auch schonmal und wollte bissl was dicht machen aber okay ^^


    wieso willst du eigentlich nen ssh port und den ftp port schließen?? also tu was du nich lassen kannst aber solltest vielleicht dran denken die ports vorher zu ändern das du selber überhaupt noch auf dein server kommst ^^


    Warum denn nicht? Die Ports kann ich ja wieder aufmachen, wenn ich den Zugriff brauche. Mit iptables wäre es natürlich blödsinn den SSH Port dicht zu machen aber bei den restlichen Diensten geht das schon klar und über VCP erst recht. Aber gut zu wissen, dass iptables überhaupt nicht funktioniert, werde ich wohl ein Ticket aufmachen.