Reicht es, ab und zu apt-get upgrade auszuführen, um einen Webserver sicher zu halten?

Sie haben viele Probleme beseitigt, die Sie normalerweise in Schwierigkeiten bringen (nämlich unter der Annahme, dass die von Ihnen gehostete App vollständig sicher ist). Aus praktischer Sicht müssen Sie diese unbedingt berücksichtigen.

Aber da Sie sich dessen bewusst sind, haben Sie vermutlich einige Schutzmaßnahmen getroffen. Lassen Sie uns dann über den Rest sprechen.

Zunächst sollten Sie wahrscheinlich nicht „von Zeit zu Zeit“ ein Update durchführen. Die meisten Distributionen betreiben Mailinglisten für Sicherheitsankündigungen, und sobald eine Schwachstelle dort bekannt gegeben wird, ist sie ziemlich öffentlich (na ja, oft schon vorher, aber in Ihrer Situation können Sie nicht wirklich alle Sicherheitslisten der Welt überwachen). Dies sind Low-Traffic-Listen, daher sollten Sie Ihre Distributionen wirklich abonnieren und aktualisieren, wenn Sie Benachrichtigungen davon erhalten.

Oft kann ein gelegentlich gewarteter Server über einen langen Zeitraum Brute-Force- oder Wörterbuchangriffen ausgesetzt werden, da der Betreuer nicht wirklich nach den Anzeichen sucht. Es ist dann eine gute Idee, die üblichen Gegenmaßnahmen anzuwenden – keine ssh-Passwortauthentifizierung, fail2ban auf ssh und Apache – und idealerweise Überwachungswarnungen einzurichten, wenn verdächtige Aktivitäten auftreten. Wenn das Ihr Budget für Wartung (Zeit) übersteigt, machen Sie es sich zur Gewohnheit, sich regelmäßig anzumelden, um diese Dinge manuell zu überprüfen.

Obwohl dies traditionell nicht als Teil der Sicherheit angesehen wird, möchten Sie sicherstellen, dass Sie schnell einen neuen Server einrichten können. Das bedeutet Serverkonfigurationsskripte (Tools wie Ansible, Chef usw. sind sowieso nützlich in der Systemadministration) und ein automatisches Backup-System, das Sie getestet haben. Wenn Ihr Server verletzt wurde, müssen Sie davon ausgehen, dass er für immer kompromittiert ist, und ihn einfach löschen, und das ist scheiße, wenn Sie keine regelmäßigen Sicherungskopien Ihrer Daten erstellt haben.

Nein. Das ist nicht genug, um Sie zu schützen.

Es wird Sie wahrscheinlich einige Zeit schützen, aber Sicherheit ist komplex und schnelllebig, sodass Ihr Ansatz wirklich nicht gut genug für langfristige Sicherheit ist . Wenn jeder die gleichen Annahmen treffen würde wie Sie in Ihrer Frage, wäre das Internet jetzt ein einziges großes Botnetz.

Also nein, beschränken wir diese Frage nicht auf Pakete. Betrachten wir die Serversicherheit ganzheitlich, damit jeder, der dies liest, eine Vorstellung davon bekommt, wie viele bewegliche Teile es wirklich gibt.

• APT (z. B. die Repos von Ubuntu) deckt nur einen Teil Ihres Software-Stacks ab. Wenn Sie (zB) Wordpress oder eine andere gängige PHP-Bibliothek verwenden und diese nicht Repo-gesteuert ist, müssen Sie auch diese aktualisieren. Die größeren Frameworks verfügen über Mechanismen, um dies zu automatisieren, aber stellen Sie sicher, dass Sie Backups erstellen und den Dienststatus überwachen, da sie nicht immer gut laufen.

• Du hast alles selbst geschrieben, also denkst du, du bist vor den Drehbuch-Kiddies sicher? Es laufen automatisierte SQL-Injection- und XSS-Exploit-Bots herum, die jede Abfragezeichenfolge und jedes Formular gleichermaßen durchbohren.

  Dies ist tatsächlich einer der Orte, an denen ein gutes Framework zum Schutz vor unzureichenden Programmierern beiträgt, die die Nuancen dieser Angriffe nicht zu schätzen wissen. Ein kompetenter Programmierer, der den Code prüft, hilft auch hier, Ängste zu zerstreuen.

• Muss PHP (oder Python oder was auch immer Sie ausführen) wirklich überall schreiben können? Festigen Sie Ihre Konfiguration und Sie werden gegen viele Angriffe gemildert. Idealerweise sind die einzigen Orte, an denen eine Webanwendung fähig ist zu schreiben sind eine Datenbank und Orte, an denen niemals Scripting ausgeführt wird (z. B. eine Nginx-Regel, die nur das Bereitstellen statischer Dateien erlaubt).

  Die PHP-Standardeinstellungen (zumindest so, wie die Leute sie verwenden) erlauben es PHP, PHP überall im Webroot zu lesen und zu schreiben. Das hat schwerwiegende Folgen, wenn Ihre Website missbraucht wird.

• Und Ihr Update-Zeitplan ist aktiv schädlich. Was in aller Welt ist "von Zeit zu Zeit"? Kritische Remote-Sicherheitsfehler haben eine kurze Halbwertszeit, aber es gibt bereits eine Verzögerung zwischen dem 0-Tag und der Patch-Verfügbarkeit, und einige Exploits werden auch von Patches zurückentwickelt (um die Slow-Pokes abzufangen).

  Wenn Sie nur einmal im Monat Updates anwenden, besteht eine sehr hohe Wahrscheinlichkeit, dass Sie ausnutzbare Software in freier Wildbahn ausführen. TL;DR:Automatische Updates verwenden.

• Versionen von Distributionen halten nicht ewig. Wenn Sie vernünftig waren und sich für eine LTS-Version von Ubuntu entschieden haben, haben Sie 5 Jahre ab der Erstveröffentlichung. Zwei weitere LTS-Versionen werden innerhalb dieser Zeit herauskommen und das gibt Ihnen Optionen.

  Wenn Sie bei der Einrichtung Ihres Servers auf "NEWER IS BETTER" und 16.10 gegangen sind, haben Sie 9 Monate . Ja. Dann müssen Sie bis 17.04, 17.10 upgraden, bevor Sie sich auf 18.04 LTS entspannen können.

  Wenn Ihre Ubuntu-Version abläuft, können Sie den ganzen Tag ein Dist-Upgrade durchführen, Sie erhalten jedoch keine Sicherheits-Upgrades.

• Und der LAMP-Stack selbst ist nicht der einzige Angriffsvektor auf einen Standard-Webserver.

  • Sie müssen Härten Sie Ihre SSH-Konfiguration:nur Verwenden Sie SSH-Schlüssel, deaktivieren Sie Passwörter, umgehen Sie den Port, deaktivieren Sie Root-Anmeldungen, überwachen Sie Brute-Versuche und blockieren Sie sie mit fail2ban .
  • Firewallieren Sie alle anderen Dienste mit ufw (et al.).
  • Stellen Sie niemals die Datenbank bereit (es sei denn, Sie brauchen zu, und sperren Sie dann die eingehende IP in der Firewall).
  • Lassen Sie keine zufälligen PHP-Skripte installiert, sonst werden Sie es tun vergiss sie und sie werden gehackt werden.

• In Ihrer Beschreibung steht keine Überwachung. Du bist blind. Wenn dort etwas vorkommt und Sie anfangen, Spam zu verbreiten, Ihre Webseiten zu infizieren usw., wie können Sie feststellen, dass etwas Schlimmes passiert ist? Prozessüberwachung. Geplanter Dateivergleich mit Git (stellen Sie sicher, dass der Server nur Lesezugriff hat).

• Berücksichtigen Sie die Sicherheit (physisch und remote) Ihres ISP. Investieren die Dime-a-Dutzend-"Hosts" (alias CPanel-Piraten) – die 2 $/Monat unbegrenzte Hosting-Pläne ausgeben – die gleichen Ressourcen in die Sicherheit wie eine dedizierte Servereinrichtung? Erkundigen Sie sich und untersuchen Sie die Historie von Datenschutzverletzungen.

• Und dann gibt es Sie . Die Sicherheit des Computers, auf dem Sie all diese Dinge programmieren, ist fast so wichtig wie der Server. Wenn Sie dieselben Passwörter verwenden, sind Sie haftbar. Sichern Sie Ihre SSH-Schlüssel mit einem physischen FIDO-UF2-Schlüssel.

Ich mache Devops seit ungefähr 15 Jahren und es ist etwas, das man bei der Arbeit lernen kann, aber es braucht wirklich nur einen Verstoß – einen Teenager, einen Bot – um einen ganzen Server zu ruinieren und wochenlange Arbeit für die Desinfizierung von Arbeitsergebnissen zu verursachen.

Einfach bewusst sein Informationen darüber, was läuft und was offengelegt wird, hilft Ihnen, bessere Entscheidungen darüber zu treffen, was Sie tun. Ich hoffe nur, dass dies jemandem hilft, den Prozess der Überprüfung seines Servers zu beginnen.

Aber wenn Sie – der durchschnittliche Programmierer von Webanwendungen – nicht bereit sind, sich mit solchen Dingen zu beschäftigen, sollten Sie überhaupt einen Server betreiben? Das ist eine ernsthafte Frage. Ich werde Ihnen nicht sagen, dass Sie das absolut nicht tun sollten, aber was passiert mit Ihnen, wenn Sie all dies ignorieren, Ihr Server gehackt wird, Ihr Kunde Geld verliert und Sie persönliche Kundeninformationen (z. B. Rechnungsdaten) preisgeben und verklagt werden ? Sind Sie für dieses Verlust- und Haftungsrisiko versichert?

Aber ja, deshalb kosten verwaltete Dienste so viel mehr als dumme Server.

Über die Kraft von Backups...

Ein vollständiges System-Backup ist möglicherweise das Schlimmste, was Sie behalten können – aus Sicherheitsgründen – weil Sie versucht sein werden, es zu benutzen, wenn Sie gehackt werden. Ihr einziger Ort ist die Wiederherstellung nach einem Hardwarefehler.

Das Problem bei der Verwendung in Hacks besteht darin, dass Sie auf einen noch früheren Zeitpunkt zurücksetzen. Noch mehr Fehler in Ihrem Stack sind jetzt offensichtlich, es gibt noch mehr Exploits für das Loch, das Sie erwischt hat. Wenn Sie diesen Server wieder online schalten, könnten Sie sofort gehackt werden. Sie könnten eingehenden Datenverkehr per Firewall abschalten und ein Paket-Upgrade durchführen, und das vielleicht helfen, aber zu diesem Zeitpunkt wissen Sie immer noch nicht, was Sie erwischt hat oder wann es Sie erwischt hat. Sie stützen alle Ihre Annahmen auf ein Symptom, das Sie gesehen haben (Anzeigeninjektion auf Ihren Seiten, Spam, der in Ihrem Mailq zurückgesendet wird). Der Hack hätte Monate davor liegen können.

Sie sind offensichtlich besser als nichts und in Ordnung für den Fall, dass eine Festplatte stirbt, aber noch einmal, sie sind Müll für die Sicherheit .

Gute Backups sind Rezepte

Sie möchten etwas – nur ein Dokument in einfacher Sprache oder etwas Technisches wie eine Ansible/Puppet/Chef-Routine – das jemanden durch die Wiederherstellung der gesamten Website auf einem brandneuen Server führen kann. Dinge zu beachten:

• Eine Liste der zu installierenden Pakete
• Eine Liste der vorzunehmenden Konfigurationsänderungen
• So stellen Sie die Website-Quelle aus der Versionskontrolle wieder her.
• So stellen Sie den Datenbank-Dump* und alle anderen statischen Dateien wieder her, für die Sie möglicherweise keine Versionskontrolle haben.

Je ausführlicher Sie hier sein können, desto besser, denn dies dient auch als persönliches Backup . Meine Kunden wissen, dass wenn ich sterben, haben sie einen getesteten planen, ihre Sites auf Hardware wiederherzustellen, die sie direkt kontrollieren.

Eine gute Wiederherstellung per Skript sollte nicht länger als 5 Minuten dauern. Daher ist sogar das Zeit-Delta zwischen einer Skript-Wiederherstellung und der Wiederherstellung eines Disk-Images minimal.

Die Chance ist hoch, dass Sie den Server meistens behalten sicher, wenn Sie häufig Updates durchführen (d. h. mindestens täglich, statt nur „ab und zu“).

Aber von Zeit zu Zeit treten kritische Fehler auf, wie Shellshock oder ImageTragick. Auch eine unsichere Serverkonfiguration kann Angriffe ermöglichen. Das bedeutet, dass Sie auch mehr Maßnahmen ergreifen sollten, als nur regelmäßige Updates durchzuführen, wie zum Beispiel:

• Reduzieren Sie die Angriffsfläche, indem Sie ein minimales System ausführen, d. h. keine unnötige Software installieren
• Reduzieren Sie die Angriffsfläche, indem Sie alle von außen zugänglichen Dienste einschränken, d. h. keine passwortbasierte SSH-Anmeldung zulassen (nur schlüsselbasiert), keine unnötigen Dienste ausführen usw.
• Stellen Sie sicher, dass Sie die Auswirkungen kritischer Updates verstehen
• Erwarten Sie, dass das System angegriffen wird, und versuchen Sie, die Auswirkungen zu verringern, indem Sie beispielsweise Dienste ausführen, auf die von außen in einem Chroot, Jail oder Container zugegriffen werden kann
• wichtige Ereignisse wie fehlgeschlagene Anmeldungen protokollieren, die Protokolle verstehen und die Protokolle tatsächlich analysieren

Dennoch sind die am häufigsten verwendeten Angriffsvektoren wahrscheinlich unsichere Webanwendungen wie Wordpress oder andere CMS. Aber Sie gingen davon aus, dass die Webanwendung vollständig sicher ist, also hoffen wir, dass sie es wirklich ist.