Kürzlich (aber es ist auch eine wiederkehrende Frage) haben wir 3 interessante Themen über Hacking und Sicherheit gesehen:

Wie gehe ich mit einem kompromittierten Server um? .
Finden, wie ein gehackter Server gehackt wurde
Fragen zu Dateiberechtigungen

Der letzte ist nicht direkt verwandt, zeigt jedoch, wie einfach es ist, sich mit einer Webserververwaltung herumzuschlagen.

Da es mehrere Dinge gibt, die getan werden können, bevor etwas Schlimmes passiert, möchte ich Ihre Vorschläge in Bezug auf bewährte Verfahren zur Begrenzung der Rückwirkungen eines Angriffs und zur Reaktion im traurigen Fall haben.

Es geht nicht nur um die Sicherung des Servers und des Codes, sondern auch um die Prüfung, Protokollierung und Gegenmaßnahmen.

Haben Sie eine Liste bewährter Verfahren oder verlassen Sie sich lieber auf Software oder Experten, die Ihre Webserver kontinuierlich analysieren (oder gar nichts)?

Wenn ja, können Sie Ihre Liste und Ihre Ideen / Meinungen teilen?

AKTUALISIEREN

Ich habe einige gute und interessante Rückmeldungen erhalten.

Ich hätte gerne eine einfache Liste, die sowohl für die IT-Sicherheitsadministratoren als auch für die Web- Factotum- Master nützlich sein kann .

Selbst wenn alle gute und korrekte Antworten gaben, bevorzuge ich im Moment die von Robert als die einfachste, klarste und prägnanteste und die von sysadmin1138 als die vollständigste und präziseste.

Aber niemand berücksichtigt die Benutzerperspektive und -wahrnehmung. Ich denke, es ist die erste, die berücksichtigt werden muss.

Was der Benutzer denken wird, wenn er meine gehackte Site besucht, viel mehr, wenn Sie vernünftige Daten über sie besitzen. Es geht nicht nur darum, wo Daten gespeichert werden, sondern auch darum, verärgerte Benutzer zu beruhigen.

Was ist mit Daten, Medien, Behörden und Wettbewerbern?

Es gibt zwei große Bereiche, auf die man sich konzentrieren muss:

1. Es ist schwer einzusteigen.
2. Erstellen von Richtlinien und Verfahren, um ruhig und effizient mit dem Ereignis umzugehen, dass jemand in den letzten Punkt 1 gerät.

Es ist schwer einzusteigen

Dies ist ein sehr komplexes Thema, und ein Großteil davon konzentriert sich darauf, sicherzustellen, dass Sie über genügend Informationen verfügen, um herauszufinden, ob WTF nachträglich aufgetreten ist. Die abstrakten Punkte zeigen der Einfachheit halber:

• Protokolle führen (siehe auch Sicherheitsinformations-Ereignisverwaltung)
  • Alle erfolgreichen und fehlgeschlagenen Autorisierungsversuche, vorzugsweise mit intakten Quellinformationen.
  • Firewall-Zugriffsprotokolle (dies muss möglicherweise Firewalls pro Server enthalten, falls verwendet).
  • Webserver-Zugriffsprotokolle
  • Authentifizierungsprotokolle des Datenbankservers
  • Anwendungsspezifische Verwendungsprotokolle
  • Wenn möglich, kann das SIEM Warnungen zu verdächtigen Mustern auslösen.
• Erzwingen Sie ordnungsgemäße Zugriffskontrollen
  • Stellen Sie sicher, dass die Rechte überall richtig eingestellt sind, und vermeiden Sie nach Möglichkeit "faule Rechte" ("Oh, geben Sie einfach allen das Lesen").
  • Regelmäßige Überprüfungen von ACLs, um sicherzustellen, dass die Verfahren tatsächlich befolgt werden, und vorübergehende Schritte zur Fehlerbehebung ("Alle lesen, prüfen, ob sie dann funktionieren") wurden nach Abschluss der Fehlerbehebung korrekt entfernt.
  • Alle Firewall-Pass-Through-Regeln müssen begründet und regelmäßig überprüft werden.
  • Die Zugriffskontrollen für Webserver müssen ebenfalls überwacht werden, sowohl für Webserver- als auch für Dateisystem-ACLs.
• Änderungsmanagement erzwingen
  • Änderungen an der Sicherheitsumgebung müssen zentral von mehr als einer Person verfolgt und überprüft werden.
  • Patches sollten in diesen Prozess einbezogen werden.
  • Ein gemeinsames Betriebssystem (Vorlage) vereinfacht die Umgebung und erleichtert das Nachverfolgen und Anwenden von Änderungen.
• Deaktivieren Sie Gastkonten.
• Stellen Sie sicher, dass nicht alle Kennwörter auf die Standardeinstellungen eingestellt sind.
  • Standardanwendungen können Benutzer mit vordefinierten Kennwörtern einrichten. Ändere sie.
  • Viele IT-Appliances werden mit sehr bekannten Benutzer- / Kennwortpaaren geliefert. Ändern Sie diese, auch wenn Sie sich nur einmal im Jahr bei diesem Ding anmelden.
• Übe das geringste Privileg. Geben Sie den Benutzern den Zugriff, den sie tatsächlich benötigen.
  • Für Administratorbenutzer ist eine Einrichtung mit zwei Konten sinnvoll. Ein reguläres Konto wird für E-Mail- und andere Büroaufgaben verwendet, ein zweites für Arbeiten mit erhöhten Rechten. VMs erleichtern das Leben.
  • Ermutigen Sie NICHT zur regelmäßigen Verwendung generischer Administrator- / Root-Konten. Es ist schwierig zu verfolgen, wer was wann getan hat.

Erstellen von Richtlinien und Verfahren, um das Ereignis eines Einstiegs ruhig und effizient zu bewältigen

Eine Sicherheitsereignisrichtlinie ist ein Muss für alle Organisationen. Es reduziert die Reaktionsphase "Mit abgeschnittenen Köpfen herumlaufen" erheblich, da Menschen bei solchen Ereignissen irrational werden. Eingriffe sind große, beängstigende Angelegenheiten. Die Schande, ein Eindringen zu erleiden, kann dazu führen, dass ansonsten besonnene Sysadmins falsch reagieren.

Alle Ebenen der Organisation müssen die Richtlinien kennen. Je größer der Vorfall ist, desto wahrscheinlicher wird das obere Management in irgendeiner Weise involviert sein, und die Festlegung von Verfahren für den Umgang mit Dingen wird wesentlich dazu beitragen, "Hilfe" von oben abzuwehren. Es bietet auch eine Deckung für die Techniker, die direkt an der Reaktion auf Vorfälle beteiligt sind, in Form von Verfahren, mit denen das mittlere Management mit dem Rest der Organisation in Kontakt treten kann.

Im Idealfall hat Ihre Disaster Recovery Politik bereits festgelegt , wie lange bestimmte Leistungen vor der DR Politik Tritte in nicht verfügbar sein kann. Dies wird die Reaktion auf Vorfälle helfen, da diese Arten von Veranstaltungen sind Katastrophen. Wenn es sich um ein Ereignis handelt, bei dem das Wiederherstellungsfenster NICHT erfüllt wird (Beispiel: Eine Hot-Backup-DR-Site erhält einen Echtzeit-Feed mit geänderten Daten, und die Eindringlinge haben eine Reihe von Daten gelöscht, die zuvor auf die DR-Site repliziert wurden Daher müssen Verfahren zur Wiederherstellung nach Erkältung angewendet werden. Dann muss das obere Management in die Gespräche zur Risikobewertung einbezogen werden.

Einige Komponenten eines Notfallplans:

• Identifizieren Sie die gefährdeten Systeme und exponierten Daten.
• Stellen Sie frühzeitig fest, ob rechtliche Beweise für eine eventuelle Strafverfolgung aufbewahrt werden müssen oder nicht.
  • Wenn Beweise aufbewahrt werden sollen , berühren Sie nichts an diesem System, es sei denn, dies ist unbedingt erforderlich . Melden Sie sich nicht an. Durchsuchen Sie keine Protokolldateien. Tun. Nicht. Berühren.
  • Wenn Beweise aufbewahrt werden sollen, müssen die gefährdeten Systeme online gelassen, aber getrennt werden, bis ein zertifizierter Experte für Computerforensik das System auf eine Weise zerlegen kann, die mit den Regeln für den Umgang mit Beweisen kompatibel ist.
    • Das Ausschalten eines kompromittierten Systems kann die Daten beschädigen.
    • Wenn Ihr Speichersystem dies zulässt (diskretes SAN-Gerät), erstellen Sie einen Snapshot der betroffenen LUNs vor dem Trennen und markieren Sie sie als schreibgeschützt.
  • Regeln für den Umgang mit Beweismitteln sind komplex und so einfach zu vermasseln. Tun Sie es nicht, es sei denn, Sie haben eine Schulung erhalten. Die meisten allgemeinen SysAdmins haben diese Art von Training NICHT.
  • Wenn Beweise aufbewahrt werden, behandeln Sie den Dienstausfall als Hardware-Verlust-Katastrophe und starten Sie die Wiederherstellungsverfahren mit neuer Hardware.
• Voreingestellte Regeln für welche Arten von Katastrophen erfordern welche Art von Benachrichtigung. Gesetze und Vorschriften variieren je nach Ort.
  • Die Regeln für „Exposition“ und „nachgewiesene Kompromisse“ variieren.
  • Nach den Benachrichtigungsregeln muss sich die Kommunikationsabteilung beteiligen.
  • Wenn die erforderliche Benachrichtigung groß genug ist, muss das Top-Level-Management einbezogen werden.
• Bestimmen Sie anhand von DR-Daten, wie viel Zeit "WTF gerade passiert" verbracht werden kann, bevor der Dienst wieder online geschaltet wird.
  • Service-Recovery-Zeiten erfordern möglicherweise die Arbeit, um herauszufinden, was zufällig untergeordnet war. Wenn dies der Fall ist, erstellen Sie nach Wiederherstellung der Dienste ein Laufwerksabbild des betroffenen Geräts zur Dissektion (dies ist keine Beweiskopie, sondern muss von den Technikern rückentwickelt werden).
  • Planen Sie Ihre Service-Recovery-Aufgaben so, dass das betroffene System vollständig neu erstellt wird und nicht nur das Chaos beseitigt wird.
  • In einigen Fällen sind die Service-Recovery-Zeiten so kurz, dass Disk-Images sofort nach dem Erkennen eines Kompromisses erstellt werden müssen und rechtliche Beweise nicht aufbewahrt werden dürfen. Sobald der Dienst wiederhergestellt ist, kann die Arbeit, herauszufinden, was passiert ist, beginnen.
• Durchsuchen Sie die Protokolldateien nach Informationen darüber, wie der Angreifer hereingekommen ist und was er möglicherweise einmal getan hat.
• Durchsuchen Sie geänderte Dateien nach Informationen darüber, wie sie reingekommen sind und was sie getan haben, als sie reingekommen sind.
• Durchsuchen Sie die Firewall-Protokolle, um Informationen darüber zu erhalten, woher sie stammen, wohin sie möglicherweise Daten gesendet haben und wie viel davon möglicherweise gesendet wurden.

Es muss nur getan werden, dass Richtlinien und Verfahren vor einem Kompromiss vorhanden sind und den Personen bekannt sind, die sie im Falle eines Kompromisses umsetzen werden. Es bietet jedem einen Reaktionsrahmen zu einer Zeit, in der die Leute nicht klar denken. Das obere Management kann über Klagen und Strafanzeigen donnern und boomen, aber tatsächlich einen Fall zusammenzubringen ist ein teurer Prozess und das Wissen, dass dies im Voraus dazu beitragen kann, die Wut zu dämpfen.

Ich stelle auch fest, dass diese Art von Ereignissen in den gesamten Katastrophenschutzplan einbezogen werden müssen. Ein Kompromiss löst sehr wahrscheinlich die Antwortrichtlinie "Hardware verloren" und auch die Antwort "Datenverlust" aus. Wenn Sie die Wiederherstellungszeiten Ihres Dienstes kennen, können Sie die Erwartung festlegen, wie lange das Sicherheitsreaktionsteam Zeit haben kann, um das tatsächlich gefährdete System zu überfluten (wenn keine rechtlichen Beweise vorliegen), bevor es für die Wiederherstellung des Dienstes benötigt wird.

Wie richtige Helpdesk-Verfahren helfen können

Wir müssen überlegen, wie hier mit Kunden umgegangen wird (dies gilt sowohl für interne als auch für externe Kunden, die sich an einen Helpdesk wenden).

Zuallererst ist Kommunikation wichtig ; Benutzer sind verärgert über die Störung des Geschäftsbetriebs und sind möglicherweise auch besorgt über das Ausmaß / die Folgen von Informationsverletzungen, die möglicherweise im Rahmen eines Eingriffs aufgetreten sind. Wenn Sie diese Personen auf dem Laufenden halten, können Sie ihre Wut und Besorgnis besser bewältigen, sowohl unter dem Gesichtspunkt, dass das Teilen von Wissen gut ist, als auch unter dem vielleicht etwas weniger offensichtlichen Gesichtspunkt, dass sie hören müssen, dass Sie die Kontrolle über das Wissen haben Situation.

Der Helpdesk und das IT-Management müssen an dieser Stelle als "Dach" fungieren und die Personen, die die Arbeit ausführen, vor dem Ausmaß des Eindringens schützen und die Dienste vor unzähligen Anfragen wiederherstellen, die diese Arbeit stören.

1. Versuchen Sie, realistische Updates an Kunden zu senden, und arbeiten Sie mit ihnen zusammen, um die Dringlichkeit für die Wiederinbetriebnahme eines Dienstes zu ermitteln. Es ist wichtig, sich der Kundenbedürfnisse bewusst zu sein, aber gleichzeitig nicht zuzulassen, dass sie Ihnen einen nicht praktikablen Zeitplan vorschreiben.
2. Stellen Sie sicher, dass Ihr Helpdesk-Team weiß, welche Informationen veröffentlicht werden können und welche nicht, und dass es keine Gerüchte und Spekulationen anregen sollte (und absolut nichts besprechen sollte, was rechtliche Schritte Ihrer Organisation beeinträchtigen könnte).
3. Eine positive Sache, die der Helpdesk tun sollte, ist die Aufzeichnung aller Anrufe, die sich auf das Eindringen beziehen. Dies kann dazu beitragen, die Störung zu messen, die sowohl durch das Eindringen selbst als auch durch die darauf folgenden Prozesse verursacht wurde. Es kann sowohl bei der Verfeinerung zukünftiger Strategien als auch bei rechtlichen Schritten sehr hilfreich sein, sowohl Zeit als auch finanzielle Kosten für das Eindringen und die Minderung aufzuwenden. Hier kann die Aufzeichnung von ITIL-Vorfällen oder Problemen hilfreich sein - sowohl das Eindringen selbst als auch die Schadensbegrenzung können als separate Probleme aufgezeichnet werden, und jeder Anrufer wird als Vorfall eines oder beider Probleme verfolgt.

Wie Bereitstellungsstandards helfen können

Das Bereitstellen auf einer festgelegten Vorlage (oder zumindest einer Checkliste) hilft ebenso wie das Üben der Änderungskontrolle / -verwaltung über Anpassungen / Upgrades Ihrer Bereitstellungsvorlage. Sie können mehrere Vorlagen haben, um Server zu berücksichtigen, die unterschiedliche Aufgaben ausführen (z. B. eine Mailservervorlage, eine Webservervorlage usw.).

Eine Vorlage sollte sowohl für das Betriebssystem als auch für Apps funktionieren und nicht nur die Sicherheit, sondern alle von Ihnen verwendeten Einstellungen enthalten. Sie sollte idealerweise per Skript (z. B. eine Vorlage) erstellt und nicht manuell angewendet werden (z. B. eine Checkliste), um menschliche Fehler so weit wie möglich zu vermeiden.

Dies hilft auf verschiedene Weise:

• Ermöglicht es Ihnen, im Falle eines Eingriffs schneller wiederherzustellen / wiederherzustellen (beachten Sie, dass Sie diese Vorlage nicht unverändert bereitstellen sollten , da Sie wissen, dass sie anfällig ist, aber Sie können zu Ihrer "letzten bekannten guten Konfiguration" zurückkehren " die vor der Live-Bereitstellung weiter gehärtet werden muss ... und vergessen Sie nicht, Ihre Bereitstellungsvorlage zu aktualisieren, sobald Sie sicher sind, dass sie ordnungsgemäß gesperrt ist.)
• Gibt Ihnen eine "Basislinie", mit der Sie einen gehackten Server vergleichen können
• Reduziert unnötige Fehler, die in erster Linie zu einem Eingriff führen können
• Hilft bei der Änderungs- und Patchverwaltung, denn wenn sich herausstellt, dass Sie aus Sicherheitsgründen (oder aus anderen Gründen) einen Patch / ein Upgrade oder eine Verfahrensänderung benötigen, können Sie leichter erkennen, welche Systeme die Änderung benötigen, und Tests leichter schreiben um zu sehen, ob die Änderung korrekt angewendet wird usw.).
• Wenn alles so konsistent wie möglich und sinnvoll ist, hilft dies, ungewöhnliche und verdächtige Ereignisse noch weiter hervorzuheben.

Für die meisten unserer Server verlassen wir uns für den Großteil unserer Prävention auf Host- und Netzwerk-Firewalls, Antiviren- / Spyware-Software, Netzwerk-IDS und Host-IDS. Dies zusammen mit allen allgemeinen Richtlinien wie Mindestprivilegien, deinstallierten nicht wesentlichen Programmen, Updates usw. Von dort aus verwenden wir Produkte wie Nagios, Cacti und eine SIEM-Lösung für verschiedene Basisauskleidungen und Benachrichtigungen, wenn Ereignisse auftreten. Unsere HIDS (OSSEC) führen auch viele SIEM-Protokollierungen durch, was sehr hilfreich ist. Wir versuchen im Grunde, so viel wie möglich zu blockieren, protokollieren dann aber zentral, damit wir etwas analysieren und korrelieren können, wenn etwas passiert.

Was Sie wirklich wollen, kann in drei grundlegende Bereiche unterteilt werden:

1. Standardsystemkonfiguration
2. System- / Anwendungsüberwachung
3. Reaktion auf Vorfälle

Wenn Sie Informationen (Sicherheitspersonal) zur Verfügung haben, sollten Sie auf jeden Fall mit ihnen sprechen. Während die Reaktion auf Vorfälle häufig die alleinige Aufgabe dieses Amtes ist, sollte der Rest eine gemeinsame Entwicklungsmaßnahme aller betroffenen Parteien sein.

Diese Antwort auf eine verwandte Frage sollte viele nützliche Ressourcen für Sie indizieren: Tipps zum Sichern eines LAMP-Servers.

Idealerweise sollten Sie die geringste Anzahl unterstützter Betriebssysteme haben und jedes mit einem Basis-Image erstellen. Sie sollten nur so weit von der Basis abweichen, wie für die Bereitstellung der vom Server bereitgestellten Dienste erforderlich ist. Die Abweichungen sollten dokumentiert werden oder können erforderlich sein, wenn Sie PCI / HIPAA / etc. Erfüllen müssen. oder andere Konformitäten. Die Verwendung von Bereitstellungs- und Konfigurationsmanagementsystemen kann in dieser Hinsicht sehr hilfreich sein. Die Einzelheiten hängen stark von Ihrem Betriebssystem, Schuster / Puppe / Altiris / DeployStudio / SCCM usw. ab.

Sie sollten auf jeden Fall eine regelmäßige Protokollüberprüfung durchführen. Angesichts der Option kann ein SIEM sehr hilfreich sein, hat aber auch den Nachteil, dass es sowohl im Kaufpreis als auch in den Ausbaukosten teuer ist. In dieser Frage auf der IT Security SE-Website finden Sie einige Kommentare zur Protokollanalyse: Wie gehen Sie mit der Protokollanalyse um? Wenn dies immer noch zu schwer ist, können selbst gängige Tools wie LogWatch einen guten Kontext für die Vorgänge bieten. Das Wichtigste ist jedoch, sich nur die Zeit zu nehmen, um sich die Protokolle überhaupt anzusehen. Auf diese Weise können Sie sich mit dem normalen Verhalten vertraut machen, sodass Sie Anomalien erkennen können.

Neben der Protokollüberprüfung ist auch die Überwachung des Serverstatus wichtig. Es ist entscheidend zu wissen, wann Änderungen eintreten, ob geplant oder nicht. Durch die Verwendung eines lokalen Überwachungstools wie Tripwire kann der Administrator auf Änderungen aufmerksam gemacht werden. Leider hat SIEMs und IDSes den Nachteil, dass das Einstellen und / oder Kaufen teuer ist. Darüber hinaus sind Ihre Alarmschwellen ohne eine gute Abstimmung so hoch, dass alle guten Nachrichten im Rauschen verloren gehen und unbrauchbar werden.

Eine ordnungsgemäße SIEM-Richtlinie ( Security Information and Event Management) trägt wesentlich dazu bei, Ihr Sicherheitsleben zu vereinfachen.

Ich bin kein Sicherheitsexperte, daher verlasse ich mich hauptsächlich auf sie. Aber mit dem Principal of Least Privilege zu beginnen, macht ihre Arbeit fast immer erheblich einfacher. Das Anwenden wie eine Heilsalbe funktioniert gut für viele Aspekte der Sicherheit: Dateiberechtigungen, Laufzeitbenutzer, Firewall-Regeln usw. KISS tut auch nie weh.

Die meisten der hier genannten Lösungen sind auf Host- und Netzwerkebene anwendbar, aber wir vergessen häufig unsichere Webanwendungen. Webanwendungen sind die am häufigsten übersehene Sicherheitslücke. Über eine Webanwendung kann ein Angreifer Zugriff auf Ihre Datenbank oder Ihren Host erhalten. Keine Firewall, IDS oder Firewall kann Sie davor schützen. OWASP führt eine Liste der 10 wichtigsten Sicherheitslücken und bietet Korrekturen für diese an.

http://www.scribd.com/doc/19982/OWASP-Web-Security-Guide