Hintergrund: Als weltweiter Marktführer im Import und Export war Vandalay Industries das Ziel vieler Gegner, die versuchten, ihr Online-Geschäft zu stören. Vor kurzem kam es bei Vandaly zu DDOS-Angriffen auf seine Webserver.
Durch einen DDOS-Angriff wurden nicht nur Webserver offline geschaltet, auch die Upload- und Download-Geschwindigkeit wurde nach dem Ausfall erheblich beeinträchtigt. Ihr Netzwerkteam hat Ergebnisse eines Netzwerkgeschwindigkeitstests zur Zeit des letzten DDOS-Angriffs bereitgestellt.
Geschwindigkeitstestdatei
Screenshot der in Splunk hochgeladenen Datei „server_speedtest.csv“:
eval ein Feld namens „ratio“, das das Verhältnis zwischen Upload- und Download-Geschwindigkeit anzeigt. Hinweis: Das Format zum Erstellen eines Verhältnisses ist: | eval new_field_name = 'fieldA' / 'fieldB'
In Splunk verwendete Abfrage zum Generieren eines Verhältnisses zwischen Upload- und Download-Geschwindigkeit – source="server_speedtest.csv" | eval ratio = DOWNLOAD_MEGABITS/UPLOAD_MEGABITS
Aus dieser Abfrage können wir das Verhältnis von Downloads und Uploads sehen.
_timeIP_ADDRESSDOWNLOAD_MEGABITSUPLOAD_MEGABITSratioHinweis: Verwenden Sie für den Tabellenbefehl das folgende Format: | Tabelle FeldA FeldB FeldC
In Splunk verwendete Abfrage zum Generieren eines Verhältnisses zwischen Upload- und Download-Geschwindigkeit – source="server_speedtest.csv" | eval ratio = DOWNLOAD_MEGABITS/UPLOAD_MEGABITS | table _time, IP_ADDRESS, DOWNLOAD_MEGABITS, UPLOAD_MEGABITS, ratio
Auf dem Screenshot oben können wir die gesamte Ereigniszeitleiste sehen, wann Downloads und Uploads stattgefunden haben.
Auf dem obigen Screenshot können wir die Zeit sehen, in der Downloads und Uploads stattgefunden haben, sowie die Quell-IP-Adresse, die diese Aktion durchgeführt hat.
Auf dem Screenshot oben können wir eine visuelle Darstellung dieser Download- und Upload-Ereignisse in einem Säulendiagrammformat sehen. Die Uhrzeit wird unten angezeigt und dadurch sind unsere Daten viel besser lesbar.
Basierend auf unseren Erkenntnissen in den obigen Abfragen können wir sehen, dass die Download- und Upload-Geschwindigkeit am 23. Februar gegen 14:30 Uhr drastisch gesunken ist. Wir können dies im folgenden Screenshot sehen:
Wir können sehen, dass die Downloads um 14:30 Uhr auf 7,87 gesunken sind. Dies ist ein drastischer Rückgang gegenüber 109,16 Megabit beim vorherigen Ereignis. Man kann also mit Fug und Recht davon ausgehen, dass dies der Zeitpunkt war, als der Angriff begann.
Aus dem obigen Screenshot können wir ersehen, dass die heruntergeladenen Megabits von 17,56 auf 65,34 gestiegen sind, was einen drastischen Anstieg darstellt. Daher kann man mit Sicherheit davon ausgehen, dass dies ungefähr der Zeitpunkt war, an dem sich das System erholte und zum normalen Netzwerkverkehrsfluss zurückkehrte.
Aus dem obigen Screenshot können wir ersehen, dass die heruntergeladenen Megabits am 23. Februar gegen 23:30 Uhr von 78,34 auf 123,91 gestiegen sind. Man kann mit Sicherheit davon ausgehen, dass dies ungefähr der Zeitpunkt ist, an dem sich der Netzwerkverkehrsfluss stabilisiert und wieder normalisiert hat.
Senden Sie einen Screenshot Ihres Berichts und die Antwort auf die oben genannten Fragen.
Hintergrund: Aufgrund der Häufigkeit von Angriffen muss Ihr Manager sicherstellen, dass sensible Kundendaten auf seinen Servern nicht angreifbar sind. Da Vandalay Nessus-Schwachstellenscanner verwendet, haben Sie die Scans der letzten 24 Stunden abgerufen, um festzustellen, ob kritische Schwachstellen vorliegen.
Weitere Informationen zu Nessus finden Sie unter folgendem Link: https://www.tenable.com/products/nessus
Ergebnisse des Nessus-Scans
Screenshot der in Splunk hochgeladenen Nessus-Scan-Ergebnisse:
10.11.36.23 . Verwenden Sie in der Abfrage dest_ip="10.11.36.23"
Es ist erwähnenswert, dass diese Protokolle fünf Arten von Schweregraden suchen, wie unten dargestellt:
Wir möchten nach Schwachstellen filtern, bei denen der Schweregrad ein „kritischer“ Wert ist. Wir können severity="crtiical" in unserer Abfrage verwenden.
Die gesamte Abfrage lautet source="nessus_logs.csv" dest_ip="10.11.36.23" severity="critical"
Im folgenden Screenshot sehen Sie die gesamte Abfrage, die die Anzahl der kritischen Schwachstellen des Kundendatenbankservers aus dieser Protokolldatei anzeigt:
Es wurden insgesamt 49 kritische Schwachstellen gefunden, wenn die Ziel-IP 10.11.36.23 war (das ist der Datenbankserver).
[email protected] .Erstellen Sie die Benachrichtigung, indem Sie auf „Speichern unter“ und dann auf „Benachrichtigung“ klicken, nachdem wir unsere Ergebnisse aus der obigen Abfrage generiert haben:
Geben Sie Details ein, um Warnungen zu generieren, wenn Nessus eine Schwachstelle auf dem Datenbankserver erkennt. Geben Sie Namen, Beschreibung und andere relative Informationen ein:
Geben Sie die E-Mail-Details ein, um die generierte Benachrichtigung an [email protected] zu senden, und geben Sie die Nachrichtendetails ein, die mit der E-Mail gesendet werden sollen:
Geben Sie weiterhin die Details der Warnung ein und klicken Sie dann auf „Speichern“:
Nach dem Speichern sollten wir die Warnung sehen und bei Bedarf bearbeiten können:
Senden Sie einen Screenshot Ihres Berichts und einen Screenshot zum Nachweis, dass die Warnung erstellt wurde.
Hintergrund: Ein Vandalay-Server erlebt ebenfalls Brute-Force-Angriffe auf sein Administratorkonto. Das Management möchte, dass Sie eine Überwachung einrichten, um das SOC-Team zu benachrichtigen, wenn erneut ein Brute-Force-Angriff auftritt.
Admin-Anmeldungen
Screenshot der in Splunk hochgeladenen Datei „Administrator_logs.csv“:
Hinweise:
Suchen Sie nach dem Namensfeld, um fehlgeschlagene Anmeldungen zu finden.
Beachten Sie, dass der Angriff mehrere Stunden dauerte.
Da wir nach Anzeichen für einen Brute-Force-Angriff suchen möchten, möchten wir die Protokolle aufschlüsseln und herausfinden, bei welchen Konten die Anmeldung fehlgeschlagen ist. Wenn wir zum Feld „Name“ navigieren, können wir die darin enthaltenen Werte in den Protokollen sehen. In diesem Fall sehen wir eine Zählung von 1004 „Die Anmeldung eines Kontos ist fehlgeschlagen“. Dies ist ein guter Indikator dafür, dass ein Brute-Force-Angriff stattgefunden hat. Siehe Screenshot:
Wenn wir dies nun zu unserer Suche hinzufügen, können wir die Gesamtzahl der Ereignisse zum Zeitpunkt dieses Ereignisses sehen. Wir können dann sehen, wann die meisten dieser Ereignisse stattgefunden haben, was ein guter Indikator dafür ist, wann dies geschah. Siehe Screenshot:
Wie wir sehen können, gibt es am 21. Februar gegen 9:00 Uhr einen ziemlich großen Anstieg der Ereignisse, bei denen die Meldung „Ein Konto konnte sich nicht anmelden“ auftrat. Wir können sehen, dass von den insgesamt 1004 Ereignissen um 9 Uhr morgens 124 dieser Ereignisse auftraten, und in den Stunden danach traten ähnliche Zahlen auf. Daher glaube ich, dass der Angriff ungefähr um diese Zeit begann – 9:00 Uhr am 21. Februar 2020.
Aus der Zeitleiste dieser Ereignisse können wir ersehen, dass 124 ein ziemlicher Anstieg ist. In den Stunden vor diesem Ereignis lag die höchste Anzahl fehlerhafter Anmeldungen bei etwa 23. Wir können dieses Verhalten als normal betrachten. Siehe Screenshot:
Vor diesem Hintergrund und unter Berücksichtigung der Zahl der Anmeldeversuche zum Zeitpunkt des Brute-Force-Angriffs würde ich von etwa 40 fehlerhaften Anmeldeversuchen pro Stunde ausgehen. Ich würde die Bereiche für fehlerhafte Anmeldungen pro Stunde wie folgt festlegen:
[email protected] .Um eine Benachrichtigung für diese Art von Ereignis zu erstellen, habe ich die folgenden Schritte durchgeführt:
Klicken Sie auf „Speichern unter“ und dann auf „Benachrichtigung“:
Geben Sie die Details der Warnung ein, einschließlich des Zeitpunkts, zu dem sie ausgelöst werden soll (alles über 25 Versuche pro Stunde):
Geben Sie Details zu einer Aktion ein. In diesem Fall senden wir eine E-Mail an [email protected] :
Speichern Sie die Warnung und wir können sie dann anzeigen:
Wir haben nun erfolgreich eine Warnung erstellt, die ausgelöst wird, wenn mehr als 25 Ereignisse auftreten, bei denen die Anmeldung eines Kontos fehlschlägt.
Senden Sie die Antworten auf die Fragen zum Brute-Force-Timing, zur Basislinie und zum Schwellenwert. Stellen Sie außerdem einen Screenshot als Beweis dafür bereit, dass die Warnung erstellt wurde.
