Sie haben viele Probleme behoben, die Sie normalerweise in Schwierigkeiten bringen (vorausgesetzt, die von Ihnen gehostete App ist vollständig sicher). Aus praktischer Sicht müssen Sie diese unbedingt berücksichtigen.

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

Zu Beginn sollten Sie wahrscheinlich nicht "ab und zu" ein Update ausführen. Die meisten Distributionen betreiben Mailinglisten für Sicherheitsankündigungen, und sobald dort eine Sicherheitsanfälligkeit gemeldet wird, ist diese eher öffentlich (nun, oft schon vorher, aber in Ihrer Situation können Sie nicht wirklich alle Sicherheitslisten der Welt überwachen). Da es sich um Listen mit geringem Datenverkehr handelt, sollten Sie Ihre Distributionen wirklich abonnieren und aktualisieren, wenn Sie Benachrichtigungen von ihr erhalten.

Oft kann ein gelegentlich gewarteter Server über einen langen Zeitraum brutal erzwungen oder ein Wörterbuch angegriffen werden der Zeit, da der Betreuer nicht wirklich nach den Zeichen 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 dies nicht in Ihrem Wartungsbudget (Zeitbudget) liegt, sollten Sie sich regelmäßig anmelden, um diese Dinge manuell zu überprüfen.

Obwohl dies traditionell nicht als Teil der Sicherheit angesehen wird, möchten Sie sicherstellen, dass Sie es mitbringen können schnell einen neuen Server einrichten. Dies bedeutet, dass Serverkonfigurationsskripte (Tools wie Ansible, Chef usw. sind in der Systemadministration sowieso nützlich) und ein von Ihnen getestetes automatisches Sicherungssystem. Wenn Ihr Server beschädigt wurde, müssen Sie davon ausgehen, dass er für immer kompromittiert ist, und ihn einfach löschen. Dies ist zum Kotzen, wenn Sie Ihre Daten nicht regelmäßig gesichert haben.

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

Es wird Sie wahrscheinlich einige Zeit schützen, aber die Sicherheit ist komplex und schnell, sodass Ihr Ansatz wirklich nicht gut ist genug für langfristige Sicherheit . Wenn alle die gleichen Annahmen treffen würden, die Sie in Ihrer Frage gemacht haben, wäre das Internet inzwischen 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 tatsächlich gibt.

• APT (z. B. Ubuntus Repos) deckt nur einen Teil Ihres Software-Stacks ab. Wenn Sie (z. B.) Wordpress oder eine andere beliebte PHP-Bibliothek verwenden und diese nicht repo-gesteuert ist, müssen Sie diese ebenfalls aktualisieren. Die größeren Frameworks verfügen über Mechanismen, um dies zu automatisieren. Stellen Sie jedoch sicher, dass Sie Backups erstellen und den Servicestatus überwachen, da diese nicht immer gut funktionieren.

• Sie haben alles selbst geschrieben, also Sie Denken Sie, Sie sind sicher vor den Drehbuchkindern? Es gibt automatisierte SQL-Injection- und XSS-Exploit-Bots, die herumlaufen und jeden Querystring und jede Form gleichermaßen anstoßen.

  Dies ist tatsächlich einer der Orte, an denen ein gutes Framework zum Schutz vor unzureichenden Programmierern beiträgt, die Nuancen dieser nicht schätzen Anschläge. Wenn ein kompetenter Programmierer den Code prüft, können Sie hier auch Ängste zerstreuen.

• Muss PHP (oder Python oder was auch immer Sie ausführen) wirklich überall schreiben können? Härten Sie Ihre Konfiguration ab und schützen Sie sich vor vielen Angriffen. Im Idealfall kann eine Webanwendung nur eine Datenbank schreiben, und Orte, an denen keine Skripterstellung ausgeführt wird (z. B. eine Nginx-Regel, mit der nur statische Dateien bereitgestellt werden können).

  Die PHP-Standardeinstellungen (zumindest wie sie verwendet werden) ermöglichen es PHP, PHP überall in der Webroot zu lesen und zu schreiben. Dies hat schwerwiegende Auswirkungen, wenn Ihre Website ausgenutzt wird.

  ^{Hinweis: Wenn Sie den Schreibzugriff blockieren, können sich Dinge wie WordPress nicht automatisch aktualisieren. Suchen Sie nach Tools wie wp-cli und lassen Sie sie planmäßig ausführen. Sup>}

• Und Ihr Update-Zeitplan ist aktiv schädlich. Was um alles in der Welt ist "ab und zu"? Kritische Remote-Sicherheitslücken haben eine kurze Halbwertszeit, aber es gibt bereits eine Verzögerung zwischen 0 Tagen und Patch-Verfügbarkeit, und einige Exploits werden auch von Patches rückgängig gemacht (um die langsamen Stöße zu erkennen).

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

• 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 ersten Veröffentlichung Zeit. Innerhalb dieser Zeit werden zwei weitere LTS-Versionen herauskommen, die Ihnen Optionen bieten.

  Wenn Sie sich auf einem "NEWER IS BETTER" -Rampage befanden und beim Einrichten Ihres Servers 16.10 gewählt haben, haben Sie 9 Monate . Ja. Dann müssen Sie ein Upgrade bis 17.04, 17.10 durchführen, bevor Sie sich auf 18.04 LTS entspannen können.

  Wenn Ihre Ubuntu-Version ausfällt, können Sie den ganzen Tag über 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 Sie müssen Ihre SSH-Konfiguration sichern: Nur SSH-Schlüssel verwenden, Kennwörter deaktivieren, den Port umleiten, Root-Anmeldungen deaktivieren, Brute-Versuche überwachen und mit fail2ban blockieren .
  • Firewall von allen anderen Diensten mit ufw (et alii).
  • Stellen Sie die Datenbank niemals offen (es sei denn, Sie benötigen / em> to und sperren Sie dann die eingehende IP in der Firewall.
  • Lassen Sie keine zufälligen PHP-Skripte installiert, sonst werden Sie sie vergessen gehackt werden.

Ich mache seit ~ 15 Jahren Devops und es ist etwas, das Sie können Lernen Sie am Arbeitsplatz, aber es ist wirklich nur eine Verletzung erforderlich - ein Teenager, ein Bot -, um einen gesamten Server zu ruinieren und wochenlange Arbeit zu verursachen, um das Arbeitsprodukt zu desinfizieren.

Nur bewusst Wenn Sie wissen, was läuft und was angezeigt wird, können Sie bessere Entscheidungen darüber treffen, was Sie tun. Ich hoffe nur, dass dies jemandem hilft, den Prozess der Überwachung seines Servers zu starten.

Aber wenn Sie - der durchschnittliche Web-App-Programmierer eines jeden Menschen - nicht bereit sind, sich mit solchen Dingen zu befassen, sollten Sie überhaupt einen Server betreiben? Das ist eine ernste Frage. Ich werde Ihnen nicht sagen, dass Sie das unbedingt nicht tun sollten, aber was passiert mit Ihnen, wenn Sie dies alles ignorieren, Ihr Server gehackt wird, Ihr Kunde Geld verliert und Sie persönliche Kundeninformationen (z. B. Rechnungsdaten) offenlegen und verklagt werden ? Sind Sie für dieses Verlust- und Haftungsrisiko versichert?

Aber ja, deshalb kosten Managed Services so viel mehr als dumme Server.

Aufgrund von Backups ...

Eine vollständige Systemsicherung ist möglicherweise das Schlimmste, was Sie aufbewahren können - aus Sicherheitsgründen -, da Sie versucht sind, sie zu verwenden, 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ückgesetzt werden. Jetzt sind noch mehr Fehler in Ihrem Stapel erkennbar, und es gibt noch mehr Exploits für das Loch, das Sie dazu gebracht hat. Wenn Sie diesen Server wieder online stellen, können Sie sofort gehackt werden. Sie können den eingehenden Datenverkehr abfeuern und ein Paket-Upgrade durchführen, und das kann Ihnen helfen, aber an diesem Punkt Ich weiß immer noch nicht, was dich gebracht hat oder wann es dich gebracht hat. Sie stützen alle Ihre Annahmen auf ein Symptom, das Sie gesehen haben (Anzeigeninjektion auf Ihren Seiten, Spam, der in Ihrer Mailq zurückgeschickt wird). Der Hack hätte Monate vorher sein können.

Sie sind offensichtlich besser als nichts und in Ordnung, wenn eine Festplatte stirbt, aber sie sind Müll für die Sicherheit

Sie möchten etwas - nur ein Dokument in einfacher Sprache oder etwas Technisches wie eine Routine von Ansible / Puppet / Chef -, das jemanden zur Wiederherstellung des gesamten Dokuments führen kann Website zu einem brandneuen Server. Zu beachtende Punkte:

• Eine Liste der zu installierenden Pakete
• Eine Liste der durchzuführenden Konfigurationsänderungen
• Wiederherstellen der Website-Quelle aus der Versionskontrolle .
• So stellen Sie den Datenbankspeicherauszug * 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, weil dies auch dient als persönliches Backup . Meine Kunden wissen, dass sie, wenn ich sterbe, einen getesteten Plan haben, um ihre Websites auf Hardware wiederherzustellen, die sie direkt steuern.

Eine gute Wiederherstellung mit Skripten sollte erforderlich sein nicht mehr als 5 Minuten. Selbst das Zeitdelta zwischen einer skriptbasierten Wiederherstellung und der Wiederherstellung eines Festplattenabbilds ist minimal.

^{* Hinweis : Auch Datenbank-Dumps müssen überprüft werden. Stellen Sie sicher, dass sich in Ihrem System keine neuen Administratorbenutzer oder zufällige Skriptblöcke befinden. Dies ist genauso wichtig wie das Überprüfen der Quelldateien, sonst werden Sie einfach erneut gehackt. Sup>}

Die Wahrscheinlichkeit ist hoch, dass Sie den Server meistens sicher halten, wenn Sie Updates häufig ausführen (d. h. mindestens täglich, anstatt nur "von Zeit zu Zeit").

Von Zeit zu Zeit treten jedoch kritische Fehler auf, wie Shellshock oder ImageTragick. Auch eine unsichere Serverkonfiguration kann Angriffe ermöglichen. Dies bedeutet, dass Sie auch mehr Maßnahmen ergreifen sollten, als nur regelmäßige Updates auszuführen, wie z. B.:

• Reduzieren Sie die Angriffsfläche, indem Sie ein minimales System ausführen, dh installieren Sie keine unnötige Software
• Stellen Sie sicher, dass Sie die Auswirkungen von verstehen Kritische Updates
• erwarten, dass das System angegriffen wird, und versuchen, die Auswirkungen zu verringern, indem beispielsweise Dienste ausgeführt werden, auf die von außen in einem Chroot, Gefängnis oder Container zugegriffen werden kann.
• protokollieren wichtige Ereignisse wie Fehlgeschlagene Anmeldungen, Verständnis der Protokolle und tatsächliche Analyse der Protokolle

Die am häufigsten verwendeten anfänglichen Angriffsmethoden sind wahrscheinlich unsichere Webanwendungen wie Wordpress oder andere CMS. Sie gingen jedoch davon aus, dass die Webanwendung vollständig sicher ist. Hoffentlich ist dies wirklich der Fall.

Die meisten modernen Linux-Distributionen verfügen über eine automatische Update-Lösung. Sie sollten es auf Ihren Servern aktivieren. Dadurch wird die Zeit, in der Ihr Server für Angriffe anfällig ist, erheblich verkürzt.

Wie Sie Debian erwähnen, sollten Sie in Betracht ziehen, unbeaufsichtigte Upgrades einzurichten. RedHat hat yum-cron und Suse kann sie über YaST erhalten.

Diese Upgrades sind normalerweise auf Sicherheitspatches beschränkt und es ist unwahrscheinlich, dass Ihr System beschädigt wird. Dies ist jedoch nicht völlig unmöglich. Letztendlich liegt es an Ihnen, das Risiko und den Nutzen dieses Ansatzes abzuwägen.

apt-get upgrade Installieren Sie nur neuere Versionen bereits installierter Pakete. Es werden keine Pakete installiert, die derzeit nicht installiert sind, und es wird kein bereits installiertes Paket aktualisiert, wenn die neuere Version von einem Paket abhängt, das derzeit nicht installiert ist.

In Debian und Ubuntu jede Kernelversion wird in einem separaten Paket abgelegt, dessen Name die Version enthält. Außerdem gibt es ein virtuelles Paket, das immer vom neuesten verfügbaren Kernel abhängt, wobei die Abhängigkeit mit jeder Version geändert wird. Zum Beispiel hängt linux-image-generic in xenial derzeit von linux-image-4.4.0-63-generic ab. Mit diesem Schema können alte Kernelversionen installiert bleiben, und falls sich herausstellt, dass die neueren nicht mit Ihrer Hardware kompatibel sind.

Dies bedeutet jedoch, dass apt-get upgrade nicht installiert wird neuere Kernel - dafür benötigen Sie apt-get dist-upgrade . Viele Leute vermeiden es jedoch, es automatisch zu verwenden, da es auch Pakete entfernen kann. In neueren Versionen von Ubuntu können Sie apt upgrade verwenden, wodurch neue Abhängigkeiten installiert werden, jedoch niemals Pakete entfernt werden.

Wenn Sie OpenSSL aktualisieren, müssen Sie mindestens das neu laden Dienste, die diese Bibliothek nutzen; In Ubuntu bittet das System nur um einen Neustart, um auf der sicheren Seite zu bleiben, und viele Leute haben auch Vorbehalte gegen automatische Neustarts.

Hier gibt es bereits einige gute Antworten. Ich wollte jedoch einige Lücken schließen und auf einige Dinge hinweisen, die in einigen der vorhandenen Antworten nicht angesprochen zu werden scheinen.

Nicht direkt von einem Superhacker oder einer Regierungsorganisation angesprochen etc

Dies ist eine gefährliche Perspektive. Viele kleine Organisationen wurden aufgrund von Variationen dieser Kernidee zum Bankrott gezwungen. Sie können wirklich nicht vorhersagen, wer eine Verwendung oder einen Grund für das Hacken Ihres Servers findet. Es ist genau auf diese Art der zugrunde liegenden Annahme zurückzuführen, dass eine Regierung oder ein Superhacker auf Ihr System abzielen könnte. Sie sind möglicherweise nicht an Ihrer Anwendung oder Ihren Daten interessiert. Sie möchten möglicherweise nur, dass ein unschuldiger Startpunkt als Teil eines größeren oder komplexeren Hacks auf ein wertvolleres Ziel verwendet wird.

Normales LAMP-Web -Server mit Web-App. (ZB AWS EC2 + Apache2 + MySQL + Php7)

Seien Sie vorsichtig bei "normal". Ihr Setup ist möglicherweise nicht so normal wie Sie denken. Viel hängt davon ab, was Sie installiert haben und von welchen Repositorys das Paket stammt. Einige der zu beachtenden Variationen sind:

• Verteilungstyp. Zum Beispiel gibt es einen großen Unterschied zwischen Ubuntu LTS- und Nicht-LTS-Distributionen. Als Faustregel gilt, dass Nicht-LTS-Distributionen in der Regel häufiger aktualisiert werden und es wichtig ist, Aktualisierungen (oder Überprüfungen - siehe unten) häufiger durchzuführen.

• Repository-Typ. Die meisten Distributionen, einschließlich Ubuntu, haben verschiedene Arten von Repositorys. Es gibt die von Ubuntu verwalteten Kern-Repositorys, die normalerweise ziemlich robuste Testzyklen durchlaufen und die Updates ziemlich zeitnah erhalten. Dann gibt es Repositories vom Typ "Contrib", die nicht vom Kernvertriebsteam verwaltet werden. Dies können Partner von Drittanbietern oder andere Benutzer oder Entwicklungsgruppen sein. Welche Betonung auf diese Speicher gelegt wird, kann sehr unterschiedlich sein. Manchmal haben sie einen hohen Fokus auf Sicherheit und ein geringerer Fokus auf Stabilität, andere werden sich auf Stabilitätsübersicherheit konzentrieren. Es ist wichtig, die Repositorys zu kennen / zu verstehen, von denen Sie Software installiert haben.

• Wissen, was installiert ist. Allzu oft hören Sie von einem System, das nur kompromittiert wurde, um festzustellen, dass der Kompromiss in einem übersehenen Paket aufgetreten ist - entweder eines, das standardmäßig installiert ist oder das vom LAMP-Stack benötigt wird, aber eine tief vergrabene oder subtile Abhängigkeit ist, die Sie nicht kannten von. Stellen Sie sicher, dass Sie alle unnötigen Pakete entfernt haben (was schwer zu bestimmen sein kann, insbesondere da einige Pakete ungewöhnliche Abhängigkeiten aufweisen).

• Hilfsbibliotheken. Es ist üblich, zusätzliche Bibliotheken zu übersehen, die installiert wurden, aber nicht vom apt-Ökosystem verwaltet werden. Beispielsweise wurde eine PHP-Bibliothek für einen bestimmten Zweck benötigt, der entweder nicht in der Standardlast der Verteilung enthalten war oder aufgrund anderer Abhängigkeiten auf dem System erstellt werden musste. Ein häufiges Beispiel sind PHP-Datenbanktreiber für kommerzielle Datenbanken. Während sich die Dinge wahrscheinlich verbessert haben, seit ich das letzte Mal einen PHP-basierten Stack verwaltet habe, kann ich mich an eine Zeit erinnern, als Sie den PHP-Treiber für Oracle erstellen mussten. Während der Prozess relativ trivial war, mussten Sie diesen Treiber nach dem Upgrade abhängiger Bibliotheken neu erstellen, um sicherzustellen, dass die Bibliothek mit der gepatchten Version verknüpft war. Dies kann auch ein Problem bei Dingen wie openSSL sein. Eine Distribution installiert möglicherweise eine aktualisierte Version der gemeinsam genutzten Bibliothek. Möglicherweise müssen Sie jedoch zusätzliche Maßnahmen ergreifen, um sicherzustellen, dass Ihre Anwendung tatsächlich die aktualisierte Bibliothek und nicht die alte Bibliothek mit einer bekannten Sicherheitsanfälligkeit verwendet.

Sie sollten täglich nach Updates suchen und diese Updates dann überprüfen, um festzustellen, ob sie wichtig sind und Ihr System beschädigen können. Während Ubuntus Adapt-Update-Prozess ziemlich robust ist und nur selten Probleme verursacht, geschieht dies von Zeit zu Zeit. Aufgrund der Betonung der Stabilität, insbesondere für LTS Bei Versionen ist der Aktualisierungsprozess in der Regel konservativ. Sie müssen daher das apt-get-Upgrade überprüfen und nicht nur ausführen. Zum Beispiel müssen Sie aufgrund möglicher Abhängigkeitsprobleme und der Möglichkeit, Instabilität oder Bruch einzuführen, manchmal ein 'dist-Upgrade' durchführen. Ubuntu wird dies absichtlich tun, um deutlich zu machen, dass Sie vorsichtig sein müssen, d. H. Ein apt-get-Upgrade kann als vertrauenswürdig eingestuft werden, um die Dinge nicht zu beschädigen, installiert jedoch möglicherweise nicht alle Sicherheitsupdates. apt-get dist-upgrade wird härter arbeiten, um sicherzustellen, dass alle Sicherheitsupdates angewendet werden, aber möglicherweise Probleme verursachen. Der Administrator muss daher mehr Sorgfalt walten lassen.

Das Unglückliche ist, dass es hier keine wirklichen Abkürzungen gibt. Die Realität ist Ihre in einer unvollkommenen Situation, in der Sie ein Entwickler sind, der für ein kleines Unternehmen arbeitet, das es sich nicht leisten kann, sowohl einen Entwickler als auch einen dedizierten Administrator zu beschäftigen. Sie müssen Ihre begrenzten Ressourcen so einsetzen, dass die Risiken für das Unternehmen minimiert werden und das Unternehmen die Risiken kennt und die Wahrscheinlichkeiten und Konsequenzen versteht. Sie müssen in einer informierten Position sein und wissen, dass sie die Entscheidung auf informierter Basis getroffen haben. Hoffe auf das Beste, aber stelle sicher, dass du das Schlechte geplant hast. Haben Sie zuverlässige und getestete Backups. Informieren Sie sich über die Funktionsweise eines Updates, bevor Sie das Update anwenden. Überwachen Sie Sicherheitslisten, um sich über neue und aufkommende Bedrohungen im Klaren zu sein und in der Lage zu sein, Ihre Gefährdung zu bewerten und Protokolle zu überprüfen, um Ihre Annahmen zu bestätigen. Täglich nach Updates suchen. Es ist durchaus legitim, sich dafür zu entscheiden, die Updates nicht täglich anzuwenden, sondern erst, nachdem Sie beurteilt haben, was sie sind und was sie patchen und in der Lage sind, die Entscheidung auf informierter Basis zu treffen.

In Bezug auf den obigen Punkt ist kein Social Engineering und die Web-App selbst sicher.

Zu glauben, dass Sie wissen und wissen, kann Welten voneinander entfernt sein. Ich habe die Anzahl der Male verloren, bei denen eine Sicherheitsbewertung Schwachstellen aufgedeckt hat, von denen ich nichts wusste. Es ist sehr wahrscheinlich, dass es Schwachstellen in PHP (oder anderen) gibt betroffene Schicht), die noch nicht entdeckt wurden - oder schlimmer noch -, von den falschen Leuten entdeckt wurden und noch nicht allgemein bekannt geworden sind. Wenn Sicherheitsexperten eine Anwendung bewerten, geben sie niemals an, dass sie sicher ist. Sie werden sagen, dass keine Schwachstellen erkannt wurden, dies jedoch nicht bedeutet.

Dies ist definitiv eine gute Vorgehensweise und sollte Teil Ihrer Serversicherheitsroutine sein. Ob Ihr Sicherheitsplan mehr als diese eine Praxis benötigt, ist schwer zu sagen, aber ich habe noch nie gute Sicherheitspläne gesehen, die dies nicht als Grundlage haben.

Das Nicht-Patchen installierter Software und Dienste stellt ein hohes Sicherheitsrisiko dar, da die in diesen Paketen entdeckten Fehler und Schwachstellen häufig zu einem vollständigen Zugriff auf die Box durch Ausnutzen führen können. Dies ist eines der ersten, wenn nicht das erste, was ein Angreifer versuchen wird.

Systemfehlkonfigurationen sind jedoch auch eine der wichtigsten Möglichkeiten, wie Angreifer Systeme kompromittieren. Das Patchen der Software allein korrigiert nicht unbedingt Fehlkonfigurationen. Manchmal passiert das, aber das liegt daran, dass die Fehlkonfiguration durch die ursprüngliche Installation der App verursacht wurde.

Eine Sache, die Sie überprüfen sollten, ist, ob einer Ihrer Dienste als Root ausgeführt wird. Es gibt nicht viele Fälle, in denen dies eine gute Idee ist, aber es kommt vor, dass ein Dienst als Root ausgeführt wird, weil die Person, die ihn installiert hat, es entweder nicht besser wusste oder ihn nicht zum Laufen bringen konnte. Root-Benutzer. Das ist nur ein Beispiel.

Unabhängig davon, welches Betriebssystem verwendet wird, gibt es bewährte Methoden zum Härten des Betriebssystems. Beginnen Sie dort und sichern Sie dann alle installierten Dienste / Pakete wie MySQL, Apache usw.

Wenn während der Bereitstellung das Betriebssystem und alle Dienste speziell gemäß den Best Practices ausgeführt wurden, können anschließend Patches angewendet werden das einzige was du tun musst.

Ich sage vielleicht, weil es immer noch keine Gewissheit ist. Dies hängt von den Änderungsprozessen ab und davon, ob die Prozesse die Aufrechterhaltung einer angemessenen Sicherheit abdecken. Werden die vorgeschlagenen Änderungen auf Sicherheit geprüft? Enthalten die Kassen sicherheitsspezifische Tests? Die Antwort auf diese Fragen lautet normalerweise Nein. Daher können Fehler durch einen Administrator auftreten und nicht abgefangen werden.

Grundsätzlich können Sie einen Webserver nicht sicher halten. Es gibt 0-Tage-Exploits, die möglicherweise innerhalb weniger Stunden nach der Entdeckung behoben werden, aber bis dahin bereits ausgenutzt wurden. Ein gutes Hosting-Unternehmen kann möglicherweise sehr zeitnah auf solche Bedrohungen reagieren. Ein verwalteter Server ist jedoch teuer (vorausgesetzt, das Managementpersonal des Hosters ist alles wert). Sie können sich jedoch entscheiden, den Server offline zu schalten, falls sie entscheiden, dass dies erforderlich ist, um eine aktuelle Bedrohung zu beseitigen, wobei Sicherheit Vorrang vor Verfügbarkeit hat - was möglicherweise falsch ist Art der Sicherheit, wenn Sie die Box benötigen, um jederzeit reagieren zu können. Wie viel Geld und wie viele Leben verlieren Sie pro Stunde Ausfall?

Datenlecks können auch anderswo auftreten. Sind die Backups sicher gespeichert? (Sicher gegen Remote- und physischen Zugriff; in einem Fall konnte ich die Datenexfiltration nicht von der Live-Website, sondern von den Backups demonstrieren.) Wie leicht kann jemand in den Serverraum eindringen? Es ist nicht nötig, dass ein Superkrimineller wie Lex Luthor Sie direkt angreift (schließlich ist er kurz nach den 40 Kuchen), aber Sie können Kollateralschaden verursachen. Und ja, ich habe geheime Serverfarmen gesehen (Fall 1: versehentlich die falsche Tür geöffnet, die anscheinend ein Idiot vergessen hatte, zu verschließen, und ein anderer Idiot hatte beschlossen, außen einen Türgriff zu haben, Fall 2: wollte es herausfinden warum es so viel verdammte Hitze gab, die hinter der Spanplatte hervorkam, in einem gemeinsamen Speicher, in dem man Quadratmeter platzieren konnte). Theoretisch von professionellen Unternehmen betrieben, in der Praxis ... na ja. Man könnte die Gelegenheit nutzen, ein paar Server oder Laufwerke hochheben, sie bei eBay verkaufen und danach viel Glück haben.

Oft übersehen werden auch Remote-Angriffe auf die Infrastruktur. Genau genommen hat dies nichts mit der Sicherheitsstufe des Servers zu tun, aber wenn jemand die Verwaltungsinfrastruktur oder den Proxy angreift, der die Softwarepakete für Ihre apt-get-Updates bereitstellt, wird die Sicherheit immer noch irgendwie ... beeinträchtigt. Ja, einige Leute machen solche Dinge zum Spaß.

Ich würde annehmen, dass AWS EC2 in Bezug auf solche Szenarien einigermaßen sicher ist, aber AWS EC2 wird nur als Beispiel geliefert, nicht als Tatsache in den OPs Frage (im Gegensatz zu der Aussage, dass die Webanwendung selbst sicher ist - dies soll uns wahrscheinlich davon abhalten, alle unsere Kriegsgeschichten über SQL-Injection usw. zu diskutieren).