it-swarm.com.de

Wird "apt-get upgrade" von Zeit zu Zeit ausgeführt, um einen Webserver sicher zu halten?

Annahmen:

  • Normaler LAMP-Webserver, auf dem die Web-App ausgeführt wird. (ZB AWS EC2 + Apache2 + MySQL + Php7)
  • Nicht direkt von einem Superhacker oder einer Regierungsorganisation usw. ins Visier genommen.
  • In Bezug auf den obigen Punkt ist kein Social Engineering und die Web-App selbst sicher.

Von wem ins Visier genommen?

Automatisierte Scans und Exploits. Gibt es noch andere

Läuft apt-get update && apt-get upgrade hin und wieder genug, um einen Webserver sicher zu halten?


Wenn nein

Was sollte der "durchschnittliche" Web-App-Programmierer, der sich auch um den Server kümmert, noch tun, um den Webserver für ein Startup-Unternehmen einigermaßen sicher zu halten?.

Es hängt davon ab, ob...

Ja, es kommt immer auf viele Dinge an. Bitte geben Sie Annahmen für die häufigsten Fälle an (Pareto-Prinzip), die dem allgemeinen Web-App-Programmierer möglicherweise bekannt sind oder nicht.

75
MPS

Sie haben viele Probleme beseitigt, 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. Sprechen wir dann über den Rest.

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 verkehrsarme Listen 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 hinweg brutal erzwungen oder ein Wörterbuch angegriffen 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 dies nicht in Ihrem Wartungs- (Zeit-) Budget liegt, sollten Sie sich regelmäßig anmelden, um diese Dinge manuell zu überprüfen.

Obwohl dies traditionell nicht als Teil der Sicherheit betrachtet wird, möchten Sie sicherstellen, dass Sie schnell einen neuen Server starten können. 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. Das ist schade, wenn Sie Ihre Daten nicht regelmäßig gesichert haben.

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

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

  • reduzieren Sie die Angriffsfläche, indem Sie ein minimales System ausführen, d. h. installieren Sie keine unnötige Software
  • reduzieren Sie die Angriffsfläche, indem Sie alle Dienste einschränken, auf die von außen zugegriffen werden kann, d. h. keine kennwortbasierte SSH-Anmeldung zulassen (nur schlüsselbasiert), keine nicht benötigten 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 einer Chroot, einem Gefängnis oder einem Container zugegriffen werden kann
  • protokollieren Sie wichtige Ereignisse wie fehlgeschlagene Anmeldungen, verstehen Sie die Protokolle und analysieren Sie die Protokolle

Die am häufigsten verwendeten anfänglichen Angriffsvektoren sind wahrscheinlich unsichere Webanwendungen wie Wordpress oder ein anderes CMS. Sie gingen jedoch davon aus, dass die Webanwendung vollständig sicher ist, also hoffentlich wirklich.

20
Steffen Ullrich

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 anfällig für Angriffe ist, erheblich verkürzt.

Wie Sie Debian erwähnen, sollten Sie nbeaufsichtigte Upgrades einrichten. RedHat hat Yum-Cron und Suse kann sie durch YaST bekommen.

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.

6
Calimo

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 wird jede Version des Kernels in ein separates Paket gestellt, wobei die Version im Namen enthalten ist. 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, wie im Moment Linux-Image-Generic in Xenial hängt 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 Neuere Kernel nicht installiert - 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, das neue Abhängigkeiten installiert, jedoch niemals Pakete entfernt.

Wenn Sie OpenSSL aktualisieren, müssen Sie mindestens die Dienste neu laden, die diese Bibliothek verwenden. 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.

3
Neith

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 usw.

Dies ist eine gefährliche Perspektive. Viele kleine Organisationen wurden aufgrund von Variationen dieser Kernidee in den Bankrott gezwungen. Sie können wirklich nicht vorhersagen, wer eine Verwendung oder einen Grund für das Hacken Ihres Servers finden könnte. Genau aufgrund dieser Art der zugrunde liegenden Annahme könnte eine Regierung oder ein Superhacker auf Ihr System abzielen. 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.

Normaler LAMP-Webserver, auf dem die Web-App ausgeführt wird. (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 Variationen, die Sie beachten sollten, sind:

  • Verteilungsart. 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 häufiger durchzuführen (oder Aktualisierungen zu überprüfen - siehe unten).

  • 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 Aktualisierungen ziemlich zeitnah erhalten. Dann gibt es Repositorys 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 Repositories gelegt wird, kann sehr unterschiedlich sein. Manchmal konzentrieren sie sich stark auf Sicherheit und weniger auf Stabilität, andere konzentrieren sich auf Stabilität über Sicherheit. 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 waren bewusst. 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. Zum Beispiel eine PHP - Bibliothek, die für einen bestimmten Zweck benötigt wird, der entweder nicht in der Standardlast der Distribution enthalten war oder aufgrund anderer Abhängigkeiten auf dem System erstellt werden musste. Ein häufiges Beispiel ist PHP Datenbanktreiber für kommerzielle Datenbanken. Während sich die Dinge wahrscheinlich verbessert haben, seit ich das letzte Mal einen PHP basierten) Stack verwalten musste, kann ich mich an eine Zeit erinnern, als Sie erstellen mussten Der PHP -Treiber für Oracle. Während der Prozess relativ trivial war, mussten Sie daran denken, diesen Treiber nach dem Upgrade abhängiger Bibliotheken neu zu erstellen, um sicherzustellen, dass die Bibliothek mit der gepatchten Version verknüpft war. Dies kann auch sein Ein Problem mit Dingen wie openSSL. 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 dann überprüfen, um festzustellen, ob sie wichtig sind und möglicherweise Ihr System beschädigen. Während Ubuntus apt-update-Prozess ziemlich robust ist und selten Dinge kaputt macht, passiert er von Zeit zu Zeit. Aufgrund der Betonung der Stabilität, insbesondere für LTS-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 der Einführung von Instabilität oder Bruch 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 keine Probleme zu verursachen, installiert jedoch möglicherweise nicht alle Sicherheitskorrekturen. apt-get dist-upgrade arbeitet härter, um sicherzustellen, dass alle Sicherheitsupdates angewendet werden, kann jedoch zu Problemen führen. Daher muss der Administrator mehr Sorgfalt walten lassen.

Das Unglückliche ist, dass es hier keine wirklichen Abkürzungen gibt. Die Realität ist, dass Sie sich in einer unvollständigen Situation befinden, 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 über neue und aufkommende Bedrohungen informiert zu sein, und können Sie Ihre Gefährdung beurteilen und Protokolle überprüfen, um Ihre Annahmen zu bestätigen. Täglich nach Updates suchen. Es ist durchaus legitim, 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 trennen. Ich habe nicht gezählt, wie oft eine Sicherheitsbewertung Sicherheitslücken aufgedeckt hat, die mir nicht bekannt waren. Es ist sehr wahrscheinlich, dass es Schwachstellen in PHP (oder einer anderen beteiligten Ebene) gibt, die noch nicht entdeckt wurden - oder schlimmer noch, von den falschen Personen entdeckt wurden und noch nicht allgemein bekannt sind. Wenn Sicherheitsexperten eine Anwendung bewerten, geben sie niemals an, dass sie sicher ist. Sie sagen, dass keine Schwachstellen erkannt wurden, dies bedeutet jedoch nicht, dass keine vorhanden sind.

2
Tim X

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 zu prüfen 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 härten Sie dann alle installierten Dienste/Pakete wie MySQL, Apache usw. speziell ab.

Wenn während der Bereitstellung das Betriebssystem und alle Dienste speziell gemäß den Best Practices ausgeführt wurden, müssen Sie möglicherweise nur noch Patches anwenden.

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.

0
Thomas Carlisle

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 dafür entscheiden, den Server offline zu schalten, falls sie entscheiden, dass dies erforderlich ist, um eine aktuelle Bedrohung zu beseitigen, wobei Sicherheit, nicht Verfügbarkeit - Vorrang 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 an anderer Stelle 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 in einem gemeinsamen Lagerraum kam, in dem man Platz auf dem Quadratmeter schaffen 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 Fernangriffe 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, manche 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 angegeben, nicht als Tatsache in der Frage des OP (im Gegensatz zu der Aussage, dass die Webanwendung selbst sicher ist - dies ist wahrscheinlich der Fall Halten Sie uns davon ab, alle unsere Kriegsgeschichten über SQL-Injection zu diskutieren.

0
Klaws