Sicherheit im Webserver

Heute ist Stammtischzeit:
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)
  • Hallo liebe Nutzer,
    Ich bin neu hier und habe mir überlegt wie man mehr Sicherheit auf seinem Webserver erreichen kann. Ich probiere nämlich eine kleine Wordpress Seite auf meinem Pi aufzubauen. Ich habe natürlich schon gegoogelt, aber das Ergebnis war nur sehr mager. Das Passwort und den Namen war das einzige was ich gefunden hab :/. Habe mir überlegt, dass es sinnvoll wäre jeden Tag automatisch nach Updates zu suchen und diese zu installieren. Wie könnte dieser Cron Job bzw. das Skript dafür aussehen und habt ihr andere Möglichkeiten die Sicherheit auf einem Webserver zu erhöhen?
    Danke für die Antworten schon mal im Voraus schon mal und einen schönen Abend.
    MFG

  • Allein die Sicherheit des Webservers zu erhöhen reicht nicht aus. Das ganze Paket Server muss von der Konfiguration stimmen. Das beginnt bei einem Paketfilter und endet bei dem setzen der richtigen Rechte auf Datei- und Verzeichnisebene usw.

    Hast du deinen Raspberry an einem DSL Anschluss zu hängen ?

    Einmal editiert, zuletzt von AWOHille (23. Januar 2017 um 21:38)

  • Eigentlich gibt es soviele Angriffspunkte bei Webservern mit ausführbaren Skripten, dass man da keine allgemeingültige Strichliste weitergeben kann. Man kann nur Stichpunkte aufzählen und diese möglichst konsequent in allen Punkten durchführen. Ich für meinen Teil bin da etwas "paranoid" (lieber zuviel als zuwenig) und habe z.B. meinen Webserver so konfiguriert:

    • Webserver als eingeschränkter User ("www-data" bei Raspbian, "http" bei Archlinux) laufenlassen. Idealerweise in einer Sandbox, falls möglich.
    • Dasselbe gilt für Schnittstellen zu Skriptsprachen, z.B. bei PHP-FPM. Ebenfalls idealerweise in einer Sandbox. PHP so konfigurieren, dass es nur vom localhost/127.0.0.1 erreichbar sein darf. Idealerweise ist der Zugriff nur über Socket-Dateien möglich, die der eingeschränkte User garnicht erreichen kann (sehr beliebt bei Nginx-Konfigurationen).
    • Bei Allem Dito bei verwendeten Datenbanken; Sicherheitshalber Standardpasswörter ändern!
    • Standardport bei privaten Webservices, die nur von einem selbst genutzt werden, würde ich grundsätzlich ändern. Damit hat man schonmal gefühlt 98% aller automatisierten Angriffe ausgeschaltet. (Funfact auf meinem Webserver, der auf einem Standardport läuft: In den Logs finde ich überraschend viele Zugriffe auf die Wordpress-Adminoberfläche. Natürlich ein automatischer Scan und in meinem Fall auch nutzlos, da ich kein Wordpress installiert habe - trotzdem scannt derzeit wenigstens eine IP-Adresse täglich nach "/wordpress//wp-login.php" bevor die IP automatisiert von mir abgeschossen wird^^)
    • SSH-Zugriffe idealerweise nur per Zertifikat zulassen, und bloß nicht auf dem Standardport liegen! (Wenn ihr nicht erweiterte Sicherheitseinstellungen vornehmt.) Andernfalls füllen sich die Logdateien relativ rasch aufgrund automatisierter Angriffe.
    • Jedwege Debug-Informationen vom Webserver sperren lassen. Keiner braucht beim Aufruf einer fehlerhaften Seite erfahren, welche Apache-/lighttp-/Nginx-Version auf dem Server läuft.
    • Rechtzeitige Sperren bei zuvielen Zugriffen einbauen, um ein "Absuchen" durch automatisierte Scanner so weit wie möglich zu unterbinden. Sowohl vom Webserver (falls der das unterstützt; Nginx z.B. kann das) als auch unabhängig davon mit IPTables. Leider ist gerade IPTables ein großes Thema für sich, über das man sehr viel schreiben kann^^.
    • HTTPS verwenden! Andernfalls werden sämtliche Daten, die von Außerhalb übers Internet auf euren Webserver geschickt wird, unverschlüsselt übertragen und kann ggf. mitgelesen werden. Das dürfte so ziemlich der wichtigste Tipp sein^^. (Nicht umsonst will Google für Chrome irgendwann den normalen Zugriff auf unverschlüsselte HTTP-Inhalte erschweren und dabei andere Browser-Hersteller mitziehen lassen, aber das ist ein anderes Thema...)
    • Je nach genutzter Anwendung nur ausgewählte PHP-Befehle erlauben. In meinem Fall verwende ich Dokuwiki, das kommt mit "HEAD", "GET" und "POST" aus; alles andere bekommt Fehlerseiten von mir^^.
    • Zugegeben schon ein extremer Fall bei mir: Der Webserver liegt in einer anderen Partition, die mit "nosuid,noexec,nodev" gemountet wurde^^. (Wobei das vermutlich nicht bei allen Webanwendungen geht; bei Dokuwiki funktioniert es jedoch einwandfrei^^.)
    • Je nach Anwendungszweck GeoIP nutzen. Meine Owncloud (auf einem anderen RPi) ist nur von Deutschland aus erreichbar^^.
    • Auch fail2ban ist sehr empfehlenswert, um auf Logdateien basierend Sperren einzurichten. Wird z.B. gerne in Kombination mit Owncloud benutzt, weil es fehlerhafte Loginversuche protokolliert, aber leider nicht sperrt bei zuvielen Versuchen - das kann man mit fail2ban nachrüsten.
    • Last but not least: Logdateien und Verzeichnisse regelmäßig überprüfen, um etwaige Angriffe zumindest rechtzeitig zu erkennen und entsprechend zu handeln. Regelmäßige Updates von allen Komponenten sind selbstverständlich durchzuführen, das gilt auch für die verwendete Webanwendung (z.B. eben Wordpress)! Die Prozesse sollten regelmäßig kontrolliert werden; wenn plötzlich ein IRC-Server auf eurem Pi läuft und eine CPU konstant ausgelastet ist, solltet ihr die SD-Karte vom Pi gleich komplett neu bespielen^^. (Erlebt bei einem Kumpel, der meinte er müsse ein Jahr lang nichts tun, nachdem er einen Webserver aufgesetzt hatte...)
    • Ein Punkt in die Kategorie "wenn der Admin nichts zu tun hat": Ich hab mir ein kleines Skript geschrieben, das in regelmäßigen Abständen die MD5- und SHA-1-Checksum von den wichtigsten Linuxtools (ls, df, dh, top, php-fpm, nginx, index.php und ein paar mehr...) überprüft und mich bei Änderung informiert. Genannte Dateien werden sehr gerne von Hackern, die Root-Zugriff erhalten haben, mit manipulierten Versionen ersetzt, damit dem Admin bei Benutzung nicht sofort auffällt, dass sein System kompromittiert wurde...
    • EDIT: Selbstverständlich den Webserver gemäß der genutzten Webanwendung konfigurieren, also z.B. keinen Zugriff auf gewisse Verzeichnisse zulassen. Dokuwiki z.B. liefert standardmäßig .htaccess-Dateien mit, damit keiner "von Außen" auf den "conf"-Ordner zugreifen kann - bei anderen Webservern, die kein .htaccess unterstützen, muss das explizit konfiguriert werden.

    Ich möchte nochmal betonen, dass ich zu dem Thema eine recht "paranoide" Einstellung habe^^. Vermutlich ist Vieles übertrieben, aber ich schlafe bei sowas einfach besser, erst recht wenn die Website sonst über einen Standardport erreichbar sein muss^^...

    Einmal editiert, zuletzt von Astorek86 (23. Januar 2017 um 22:59)


  • Ich möchte nochmal betonen, dass ich zu dem Thema eine recht "paranoide" Einstellung habe^^. Vermutlich ist Vieles übertrieben, aber ich schlafe bei sowas einfach besser, erst recht wenn die Website sonst über einen Standardport erreichbar sein muss^^...

    Ich finde diese Einstellung sehr gut :thumbs1: . Denn wenn jemand den Webserver übernommen hat ist er auch gleich im lokalen Netz - ausser Du hast eine wirkliche DMZ. Aber das hat wohl kaum einer :no_sad:

    • Ein Punkt in die Kategorie "wenn der Admin nichts zu tun hat": Ich hab mir ein kleines Skript geschrieben, das in regelmäßigen Abständen die MD5- und SHA-1-Checksum von den wichtigsten Linuxtools (ls, df, dh, top, php-fpm, nginx, index.php und ein paar mehr...) überprüft und mich bei Änderung informiert. Genannte Dateien werden sehr gerne von Hackern, die Root-Zugriff erhalten haben, mit manipulierten Versionen ersetzt, damit dem Admin bei Benutzung nicht sofort auffällt, dass sein System kompromittiert wurde...

    Warum schreibt man sowas fehlerträchtig noch selbst? tripwire, samhain, aide, ossec etc. existieren.
    jm2c

    Wenn du nichts zu sagen hast, sag einfach nichts.


  • Eigentlich gibt es soviele Angriffspunkte bei Webservern mit ausführbaren Skripten, dass man da keine allgemeingültige Strichliste weitergeben kann. Man kann nur Stichpunkte aufzählen und diese möglichst konsequent in allen Punkten durchführen. Ich für meinen Teil bin da etwas "paranoid" (lieber zuviel als zuwenig) und habe z.B. meinen Webserver so konfiguriert:

    • Webserver als eingeschränkter User ("www-data" bei Raspbian, "http" bei Archlinux) laufenlassen. Idealerweise in einer Sandbox, falls möglich.
    • Dasselbe gilt für Schnittstellen zu Skriptsprachen, z.B. bei PHP-FPM. Ebenfalls idealerweise in einer Sandbox. PHP so konfigurieren, dass es nur vom localhost/127.0.0.1 erreichbar sein darf. Idealerweise ist der Zugriff nur über Socket-Dateien möglich, die der eingeschränkte User garnicht erreichen kann (sehr beliebt bei Nginx-Konfigurationen).
    • Bei Allem Dito bei verwendeten Datenbanken; Sicherheitshalber Standardpasswörter ändern!
    • Standardport bei privaten Webservices, die nur von einem selbst genutzt werden, würde ich grundsätzlich ändern. Damit hat man schonmal gefühlt 98% aller automatisierten Angriffe ausgeschaltet. (Funfact auf meinem Webserver, der auf einem Standardport läuft: In den Logs finde ich überraschend viele Zugriffe auf die Wordpress-Adminoberfläche. Natürlich ein automatischer Scan und in meinem Fall auch nutzlos, da ich kein Wordpress installiert habe - trotzdem scannt derzeit wenigstens eine IP-Adresse täglich nach "/wordpress//wp-login.php" bevor die IP automatisiert von mir abgeschossen wird^^)
    • SSH-Zugriffe idealerweise nur per Zertifikat zulassen, und bloß nicht auf dem Standardport liegen! (Wenn ihr nicht erweiterte Sicherheitseinstellungen vornehmt.) Andernfalls füllen sich die Logdateien relativ rasch aufgrund automatisierter Angriffe.
    • Jedwege Debug-Informationen vom Webserver sperren lassen. Keiner braucht beim Aufruf einer fehlerhaften Seite erfahren, welche Apache-/lighttp-/Nginx-Version auf dem Server läuft.
    • Rechtzeitige Sperren bei zuvielen Zugriffen einbauen, um ein "Absuchen" durch automatisierte Scanner so weit wie möglich zu unterbinden. Sowohl vom Webserver (falls der das unterstützt; Nginx z.B. kann das) als auch unabhängig davon mit IPTables. Leider ist gerade IPTables ein großes Thema für sich, über das man sehr viel schreiben kann^^.
    • HTTPS verwenden! Andernfalls werden sämtliche Daten, die von Außerhalb übers Internet auf euren Webserver geschickt wird, unverschlüsselt übertragen und kann ggf. mitgelesen werden. Das dürfte so ziemlich der wichtigste Tipp sein^^. (Nicht umsonst will Google für Chrome irgendwann den normalen Zugriff auf unverschlüsselte HTTP-Inhalte erschweren und dabei andere Browser-Hersteller mitziehen lassen, aber das ist ein anderes Thema...)
    • Je nach genutzter Anwendung nur ausgewählte PHP-Befehle erlauben. In meinem Fall verwende ich Dokuwiki, das kommt mit "HEAD", "GET" und "POST" aus; alles andere bekommt Fehlerseiten von mir^^.
    • Zugegeben schon ein extremer Fall bei mir: Der Webserver liegt in einer anderen Partition, die mit "nosuid,noexec,nodev" gemountet wurde^^. (Wobei das vermutlich nicht bei allen Webanwendungen geht; bei Dokuwiki funktioniert es jedoch einwandfrei^^.)
    • Je nach Anwendungszweck GeoIP nutzen. Meine Owncloud (auf einem anderen RPi) ist nur von Deutschland aus erreichbar^^.
    • Auch fail2ban ist sehr empfehlenswert, um auf Logdateien basierend Sperren einzurichten. Wird z.B. gerne in Kombination mit Owncloud benutzt, weil es fehlerhafte Loginversuche protokolliert, aber leider nicht sperrt bei zuvielen Versuchen - das kann man mit fail2ban nachrüsten.
    • Last but not least: Logdateien und Verzeichnisse regelmäßig überprüfen, um etwaige Angriffe zumindest rechtzeitig zu erkennen und entsprechend zu handeln. Regelmäßige Updates von allen Komponenten sind selbstverständlich durchzuführen, das gilt auch für die verwendete Webanwendung (z.B. eben Wordpress)! Die Prozesse sollten regelmäßig kontrolliert werden; wenn plötzlich ein IRC-Server auf eurem Pi läuft und eine CPU konstant ausgelastet ist, solltet ihr die SD-Karte vom Pi gleich komplett neu bespielen^^. (Erlebt bei einem Kumpel, der meinte er müsse ein Jahr lang nichts tun, nachdem er einen Webserver aufgesetzt hatte...)
    • Ein Punkt in die Kategorie "wenn der Admin nichts zu tun hat": Ich hab mir ein kleines Skript geschrieben, das in regelmäßigen Abständen die MD5- und SHA-1-Checksum von den wichtigsten Linuxtools (ls, df, dh, top, php-fpm, nginx, index.php und ein paar mehr...) überprüft und mich bei Änderung informiert. Genannte Dateien werden sehr gerne von Hackern, die Root-Zugriff erhalten haben, mit manipulierten Versionen ersetzt, damit dem Admin bei Benutzung nicht sofort auffällt, dass sein System kompromittiert wurde...
    • EDIT: Selbstverständlich den Webserver gemäß der genutzten Webanwendung konfigurieren, also z.B. keinen Zugriff auf gewisse Verzeichnisse zulassen. Dokuwiki z.B. liefert standardmäßig .htaccess-Dateien mit, damit keiner "von Außen" auf den "conf"-Ordner zugreifen kann - bei anderen Webservern, die kein .htaccess unterstützen, muss das explizit konfiguriert werden.

    Ich möchte nochmal betonen, dass ich zu dem Thema eine recht "paranoide" Einstellung habe^^. Vermutlich ist Vieles übertrieben, aber ich schlafe bei sowas einfach besser, erst recht wenn die Website sonst über einen Standardport erreichbar sein muss^^...

    Danke für die umfassende Antwort!
    Allerdings bin ich noch ein ziemlicher Anfänger und verstehe nicht mal die Hälfte von deinen Punkten :/. Ich probiere mich mit dieser Website an die ganze Thematik heranzutasten. Trotzdem möchte ich doch eine Gewisse Sicherheit erreichen. Wenn du Zeit hast, mir einen Crash Kurs zu geben und mir die wichtigsten Dinge zu erklärst wäre ich dir sehr sehr dankbar! :danke_ATDE:
    Mit freundlichen Grüßen

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!