Server

Webserver absichern

  • SSL/HTTPS aktivieren

    Sofern auf dem Webserver mit kritischen oder persönlichen Daten der User hantiert wird, sollte die Verbindung zwischen Webbrowser und Webserver verschlüsselt werden. Dies geschieht durch den Erwerb und die Installation eines SSL-Zertifikats.

    Auch für jede andere Website ist die Verwendung von SSL eine gute Idee, weil dadurch der Informationsgehalt mitgeschnittener Verbindungsdaten reduziert wird. Außerdem verleiht das grüne Vorhängeschloss, das im Browser neben der Adressleiste zu sehen ist, dem User ein bisschen mehr Vertrauen.

    Hier ein Beispiel für einen Apache-Virtualhost:

    #Port 80 leitet immer auf Port 443 um
    <VirtualHost *:80>
     ServerName trustedserver.org
     Redirect permanent / https://trustedserver.org/
    </VirtualHost>
    
    <VirtualHost *:443>
     ServerName trustedserver.org
     DocumentRoot /var/www/trustedserver.org/
    
     SSLEngine On
     SSLCertificateFile     /var/www/cert/trustedserver.crt
     SSLCACertificateFile   /var/www/cert/trustedserver_intermediate.crt
     SSLCertificateKeyFile  /var/www/cert/trustedserver.key
    </VirtualHost>
    

    Das Intermediate-Zertifikat sollte dabei nicht vergessen werden. Dies ist für manche Browser wichtig (z.B. unter Android) und wird beim Kauf oftmals nicht automatisch mitgeliefert.

    Da SSL-Zertifikate immer nur zeitlich begrenzt gültig sind, sollte man sich im Kalender markieren, wann es abläuft und rechtzeitig ein neues kaufen, bevor es zu Ausfällen der Site kommt. Wer den Termin für seine Site überprüfen möchte, kann beim Trusted Server SSL-Check seine Adresse eingeben und den Test machen. Man sollte keine Zertifikate kaufen, die länger als 39 Monate gelten. Denn diese werden demnächst aus Sicherheitsgründen von Browsern beanstandet. Außerdem sollte man als Schlüsselllänge mindestens 2048 Bit wählen.

    Zum Generieren der CSR-Datei, die man braucht, um das Zertifikat zu beantragen, braucht man unter Linux eine openssl-Kommandozeile mit diversen Parametern. Diese kann man recht elegant hier generieren. Die Kommandozeile sollte dann noch um den Parameter „-sha256“ ergänzt werden, damit nicht das demnächst ausgemusterte Hash-Verfahren SHA-1 verwendet wird, sondern SHA-2 (256 bit). Es wird dann neben der CSR-Datei auch der Pivate Key generiert, der gut verwahrt werden sollte.

    Allerdings ist es mit der einfachen Installation des Zertifikats noch nicht unbedingt getan. Es muss noch sichergestellt werden, dass die maximale derzeit mögliche Sicherheitsstufe verwendet wird (mehr dazu unter Perfect Forward Secrecy).

  • Perfect Forward Secrecy

    Beim Aufbau einer verschlüsselten Verbindung zwischen Webbrowser und Webserver kommt es zunächst zu einem sogenannten Handshake, bei dem Schlüssel ausgetauscht werden. Mit diesen wird die folgende Kommunikation dann verschlüsselt. Nun ist die aktuell am weitesten verbreitete Methode allerdings nicht unbedingt sicher. Wenn es z.B. der NSA gelänge, den Private Key einer Website in die Hände zu bekommen (z.B. durch Konfiszierung des Server-Rechners), kann sie nachträglich sämtlichen mitgeschnittenen Traffic entschlüsseln.

    Die Lösung für dieses Problem nennt sich Diffie-Hellman-Key-Exchange. Bei diesem Verfahren können sich Client und Server auf einen gemeinsamen Schlüssel einigen, ohne dass ein Man-in-the-middle diesen jemals in die Hände bekommt, obwohl er die komplette Kommunikation belauscht. Das hört sich zunächst unmöglich an, ist aber mathematisch belegt und daher auf jeden Fall die aktuell sicherste Methode.

    Hier eine Apache-Konfiguration, die nur die neuesten SSL-Versionen (ab TLS 1.0) erlaubt und den Diffie-Hellman-Schlüsselaustausch bevorzugt:

    SSLProtocol -All +TLSv1
    SSLHonorCipherOrder On
    SSLCipherSuite EECDH+AES:EDH+AES:-SHA1:EECDH+RC4:EDH+RC4:EECDH+AES256:EDH+AES256:AES256-SHA:!aNULL:!eNULL:!EXP:!LOW:!MD5
    

    Damit kommen eigentlich alle aktuellen Browser klar. Wichtig ist noch, dass auf dem Server mindestens OpenSSL 1.0.1 installiert sein muss. Ob die Einstellungen funktionieren, kann man mit dem Trusted Server SSL-Check prüfen.

    SSH verwendet übrigens seit längerem den Diffie-Hellman-Key-Exchange und unterstützt damit Perfect Forward Secrecy.

  • Web Application Firewall einsetzen

    Eine Web Application Firewall (WAF) ist eine Software, die vor den Webserver geschaltet wird. Sie nimmt alle HTTP-Requests entgegen und versucht Hacker-Angriffe schon zu erkennen, bevor sie den Webserver und damit die Applikation erreichen.

    In Kombination mit Apache kann hierfür mod_security als Apache-Modul verwendet werden. Die Installation ist nicht ganz trivial, da man sich mit den sogenannten corerules auseinandersetzen muss, die definieren, was alles als Angriff auf die Applikation gewertet wird. Wenn man alle Regeln aktiviert, bekommt man doch recht viele Warnhinweise, die möglicherweise aber gar nicht kritisch sind.

    Wichtiger als eine pauschale WAF einzusetzen, ist es aber, in seinem Applikationsdesign die gängigsten Angriffsmethoden zu berücksichtigen. Siehe dazu die Tipps unter Applikation.

  • Patchlevels immer aktuell halten

    Das Betriebssystem und verwendete Serversoftware sowie alle Bibliotheken, die von der Applikation verwendet werden, sollten immer auf aktuellem Stand gehalten werden. So verringert man die Chance, dass ein Exploit für eine Sicherheitslücke verwendet werden kann, die schon länger bekannt ist. Beste Methode, auf dem aktuellen Stand zu bleiben, ist es, regelmäßig IT-News zu lesen und die Newsfeeds der Hersteller zu abonnieren.

    Bei populärer Software wie z.B. WordPress ist besonders auf Plugins aufzupassen. Es hilft nicht, wenn der WordPress-Kern einbruchsicher ist, aber dann ein unsicheres Plugin installiert wird.

  • Offene Ports minimieren

    Es sollten nur die nötigsten Serverdienste von außen erreichbar sein. Port 80 (HTTP) oder besser Port 443 (HTTPS) gehören natürlich dazu. Datenbanken, Suchmaschinen und Applikationsserver sollten am besten nicht von außen erreichbar sein, übliche Ports sind hier 3306 (MySQL), 27017 (MongoDB) oder 8080 (Tomcat). Per SSH sollte man seinen Server ebenfalls erreichen können, damit er administrierbar ist. SSH läuft standardmäßig auf Port 22. Um es Angreifern aber nicht zu leicht zu machen, sollte man ihn ändern, am besten auf eine Zahl über 9000.

    Dies geschieht zumindest unter Ubuntu in der Datei /etc/ssh/sshd_config:

    Port 9377
    

    Es ist ratsam, den neuen SSH-Port zunächst zusätzlich zu Port 22 einzurichten und nach Neustart des Daemons den neuen Port zu testen, bevor man Port 22 entfernt. Möglicherweise wird nämlich der neue durch eine Firewall geblockt und man schließt sich selbst aus dem System aus.

    Die professionellere Variante, seinen SSH-Port zu schützen, wäre die Verwendung eines VPNs. Der Zugriff erfolgt dann nicht direkt aus dem Internet, sondern es wird eine Einwahl in ein VPN vorausgesetzt. Dieses Feature muss allerdings vom Hoster unterstützt und dann eingerichtet werden und kostet mit Sicherheit extra.

  • SSH-Keyfiles anstatt Passwörtern

    Möglicherweise ist es eine gute Idee, für SSH-Logins keine Passwörter zu verwenden, sondern Keyfiles. Es generiert dazu jeder Client ein Public/Private Key Pair. Die Public Keys aller, die auf den Server Zugriff haben sollen, werden dann mit ssh-copy-id zu den authorisierten Keys auf dem Server hinzugefügt.

  • Serverstandort berücksichtigen

    Aufgrund der aktuellen Abhörskandale gilt es, den Standort seines Servers mit Bedacht zu wählen. Möglicherweise ist es eine gute Idee, einen Server mit deutschen Usern auch in Deutschland zu hosten. Es gehen dann mit hoher Wahrscheinlichkeit keine Requests über die Staatsgrenzen hinaus und können nicht im großen Stil von ausländischen Geheimdiensten belauscht werden. Es gibt zwar auch die Möglichkeit, dass in Deutschland ebenfalls Traffic abgegriffen wird, aber durch die Wahl des Serverstandorts minimiert man das Risiko.

  • Server-Signatur abschalten

    Ein Angreifer hat umso bessere Voraussetzungen, je mehr Informationen er über das Ziel hat. Daher sollte man seinen Server so konfigurieren, dass er nicht allzuviel über sich preisgibt. Die meisten Webserver senden aber standardmäßig im HTTP-Header mit, welche Software in welcher Version ihm zugrundeliegt.

    Dies kann bei Apache folgendermaßen in der Konfiguration deaktiviert werden:

    ServerTokens Prod
    ServerSignature Off
    

    ServerTokens Prod sorgt dafür, dass nur „Apache“ im HTTP-Header genannt wird und ServerSignature Off verhindert, dass im Footer von Fehlerseiten nähere Informationen über installierte Module und Versionsnummern angezeigt werden.

    PHP meldet seine Version auch standardmäßig im HTTP-Header-Feld „X-Powered-By“. Das kann und sollte in der php.ini deaktiviert werden, indem man diese Direktive verwendet:

    expose_php = Off
    
  • Rechenzentrum genau prüfen

    Die wenigsten Webmaster betreiben ein eigenes Rechenzentrum. Stattdessen nimmt man die Dienste von Hostern in Anspruch und mietet dort beispielsweise einen Dedicated Server. Bei der Auswahl des Hosters sollte man der Sicherheit willen aber auf ein paar Dinge achten:

    Befindet sich das Rechenzentrum im Inland? Ist das Rechenzentrum nach der Sicherheitsnorm ISO 27001 zertifiziert? Falls nicht, sollte man beim Rechenzentrum direkt nachfragen, welche Maßnahmen es ergreift, um Zugangskontrollen, Videoüberwachungen und ähnliches zu gewährleisten.