Fälle für die Verwendung von Tools zur Analyse von Netzwerkanomalien: Lecksuche

Bei einer der Veranstaltungen fand eine interessante Diskussion über die Nützlichkeit von Lösungen der Klasse NTA (Network Traffic Analysis) statt, die mithilfe der Netflow-Telemetrie-Netzwerkinfrastruktur (oder anderer Flow-Protokolle) eine Vielzahl von Angriffen erkennen können. Meine Gegner argumentierten, dass Sie bei der Analyse von Headern und verwandten Informationen (und NTA analysiert im Gegensatz zu den klassischen Angriffserkennungssystemen IDS nicht den Paketkörper) nicht viel sehen können. In diesem Artikel werde ich versuchen, diese Meinung zu widerlegen und das Gespräch inhaltlicher zu gestalten. Ich werde einige echte Beispiele geben, wenn die NTA wirklich dazu beiträgt, verschiedene Anomalien und Bedrohungen zu identifizieren, die am Umfang oder sogar hinter dem Umfang fehlen. Und ich werde mit der Bedrohung beginnen, die in der Bedrohungsbewertung des letzten Jahres an erster Stelle stand, und ich denke, dies wird auch in diesem Jahr so ​​bleiben.Es geht um Informationslecks und die Fähigkeit, diese über Netzwerktelemetrie zu erkennen.

Ich werde die Situation nicht mit den krummen Händen von Admins betrachten, die das Internet verlassen haben und ungeschützt wie Elastic oder MongoDB aussehen. Lassen Sie uns über die gezielten Aktionen von Angreifern sprechen, wie dies bei der gefeierten Geschichte der Equifax-Kreditbüros der Fall war. Ich möchte Sie daran erinnern, dass in diesem Fall die Angreifer zuerst die nicht gepatchte Sicherheitslücke zum öffentlichen Webportal und dann zu den internen Datenbankservern durchdrungen haben. Sie blieben mehrere Monate unbemerkt und konnten Daten von 146 Millionen Kunden des Kreditbüros stehlen. Könnte ein solcher Vorfall mithilfe von DLP-Lösungen identifiziert werden? Höchstwahrscheinlich nicht, da klassische DLPs nicht auf die Aufgabe der Überwachung des Datenverkehrs aus Datenbanken mithilfe bestimmter Protokolle zugeschnitten sind, selbst wenn dieser Datenverkehr verschlüsselt ist.Die Lösung der NTA-Klasse kann solche Lecks jedoch recht leicht erkennen, indem ein bestimmter Schwellenwert der aus der Datenbank heruntergeladenen Informationsmenge überschritten wird. Als Nächstes werde ich zeigen, wie dies alles mithilfe der Cisco Stealthwatch Enterprise-Lösung konfiguriert und erkannt wird.

Das erste, was wir tun müssen, ist zu verstehen, wo sich unsere Datenbankserver im Netzwerk befinden, ihre Adressen zu bestimmen und sie zu gruppieren. In Cisco Stealthwatch kann die Inventarisierungsaufgabe entweder manuell oder mithilfe eines speziellen Klassifikators ausgeführt werden, der den Datenverkehr analysiert und ihn gemäß den verwendeten Protokollen und dem Verhalten des Knotens der einen oder anderen Kategorie zuordnen kann.



Nachdem wir Informationen zu allen Datenbankservern haben, beginnen wir eine Untersuchung, um herauszufinden, ob große Datenmengen aus der gewünschten Gruppe von Knoten verloren gehen. Wir sehen, dass in unserem Fall die Datenbanken am aktivsten mit DHCP-Servern und Domänencontrollern kommunizieren.



Angreifer stellen häufig die Kontrolle über einen der Netzwerkknoten her und verwenden ihn als Brückenkopf, um ihren Angriff zu entwickeln. Auf der Ebene des Netzwerkverkehrs sieht es nach einer Anomalie aus: Das Scannen des Netzwerks von diesem Knoten wird immer häufiger, Daten werden von der Dateifreigabe erfasst oder die Interaktion mit Servern. Daher besteht unsere nächste Aufgabe darin, zu verstehen, mit wem genau unsere Datenbanken am häufigsten kommunizieren.



In der Gruppe der DHCP-Server stellt sich heraus, dass dies ein Knoten mit der Adresse 10.201.0.15 ist, mit dem die Interaktion etwa 50% des gesamten Datenverkehrs von Datenbankservern ausmacht.



Die nächste logische Frage, die wir uns im Rahmen der Untersuchung stellen, lautet: „Und wie sieht dieser Knoten in 10.201.0.15 aus? Mit wem interagiert er? Wie oft? Welche Protokolle? "



Es stellt sich heraus, dass der für uns interessante Knoten mit verschiedenen Segmenten und Knoten unseres Netzwerks kommuniziert (was nicht überraschend ist, da es sich um einen DHCP-Server handelt), aber die Frage verursacht zu viel Interaktion mit dem Terminalserver mit der Adresse 10.201.0.23. Ist das normal? Es gibt eindeutig eine Art Anomalie. Ein DHCP-Server kann nicht so aktiv mit einem Terminalserver kommunizieren - 5610 Streams und 23,5 GB Daten.



Und diese Interaktion wird über NFS durchgeführt.



Wir machen den nächsten Schritt und versuchen zu verstehen, mit wem unser Terminalserver interagiert. Es stellt sich heraus, dass er eine ziemlich aktive Kommunikation mit der Außenwelt hat - mit Knoten in den USA, Großbritannien, Kanada, Dänemark, den Vereinigten Arabischen Emiraten, Katar, der Schweiz usw.



Der Verdacht wurde durch die P2P-Interaktion mit Puerto Rico verursacht, auf die 90% des gesamten Verkehrs entfielen. Darüber hinaus hat unser Terminalserver über den 53. Port, der mit dem DNS-Protokoll verbunden ist, mehr als 17 GB Daten nach Puerto Rico übertragen. Können Sie sich vorstellen, dass ein solches Datenvolumen über DNS übertragen wird? Und ich erinnere Sie daran, dass laut Cisco-Untersuchungen 92% der Malware DNS verwendet, um ihre Aktivitäten zu verbergen (Herunterladen von Updates, Empfangen von Befehlen, Entladen von Daten).



Und wenn das ITU-DNS-Protokoll nicht nur geöffnet, sondern auch nicht überprüft wird, haben wir ein großes Loch in unserem Umkreis.



Sobald der Knoten 10.201.0.23 uns solche Verdächtigungen verursacht hat, wollen wir sehen, mit wem er noch spricht.



Unser „Verdächtiger“ tauscht die Hälfte des gesamten Datenverkehrs mit dem Knoten 10.201.3.18 aus, der sich in einer Gruppe von Arbeitsstationen von Mitarbeitern der Vertriebs- und Marketingabteilung befindet. Wie typisch ist es für unsere Organisation, dass der Terminalserver mit dem Computer des Verkäufers oder Vermarkters „kommuniziert“?



Also haben wir eine Untersuchung durchgeführt und das folgende Bild herausgefunden. Daten vom Datenbankserver wurden auf einen DHCP-Server übertragen und anschließend über NFS an einen Terminalserver in unserem Netzwerk und anschließend mithilfe des DNS-Protokolls an externe Adressen in Puerto Rico übertragen. Dies ist ein klarer Verstoß gegen Sicherheitsrichtlinien. Gleichzeitig interagierte der Terminalserver auch mit einer der Workstations im Netzwerk. Was hat diesen Vorfall verursacht? Ein gestohlenes Konto? Infiziertes Gerät? Wir wissen nicht. Dies erfordert eine Fortsetzung der Untersuchung, die auf der NTA-Klassenlösung basiert und die Analyse von Netzwerkverkehrsanomalien ermöglicht.



Und jetzt interessiert uns, was wir mit den festgestellten Verstößen gegen die Sicherheitsrichtlinien tun werden. Sie können regelmäßige Analysen gemäß dem obigen Schema durchführen oder die NTA-Richtlinie so konfigurieren, dass sie sofort signalisiert, wenn ähnliche Verstöße festgestellt werden. Dies erfolgt entweder über das entsprechende allgemeine Menü oder für jede während der Untersuchung erkannte Verbindung.



So sieht die Interaktionserkennungsregel aus, deren Quelle der Datenbankserver ist und deren Ziel externe Knoten sowie interne Knoten mit Ausnahme von Webservern sind.



Wenn ein solches Ereignis erkannt wird, generiert das Netzwerkverkehrsanalysesystem sofort ein Korrespondenzalarmsignal und sendet es abhängig von den Einstellungen über die Kommunikationsmittel mit dem Administrator an SIEM oder blockiert die erkannte Verletzung sogar automatisch (Cisco Stealthwatch führt dies durch Interaktion mit Cisco ISE durch) )



Denken Sie daran, als ich den Fall mit Equifax erwähnte, erwähnte ich, dass die Angreifer einen verschlüsselten Kanal verwendeten, um Daten zu sichern. Für DLP wird dieser Datenverkehr zu einer unlösbaren Aufgabe, für Lösungen der NTA-Klasse jedoch nicht - sie verfolgen überschüssigen Datenverkehr oder nicht autorisierte Interaktionen zwischen Knoten, unabhängig von der Verwendung der Verschlüsselung.



Oben wurde nur ein Fall gezeigt (in den folgenden Materialien werden andere Beispiele für die Verwendung von NTA für Informationssicherheitszwecke betrachtet). Mit modernen Lösungen der Klasse "Netzwerkverkehrsanalyse" können Sie jedoch sehr flexible Regeln erstellen und nicht nur die grundlegenden Parameter des IP-Paket-Headers berücksichtigen:



sondern auch Führen Sie eine eingehendere Analyse durch, bis Sie den Vorfall mit dem Benutzernamen aus Active Directory verknüpfen, nach schädlichen Dateien per Hash suchen (z. B. als Kompromissindikator von SOSOPKA, FinCERT, Cisco Threat Grid usw.) usw.



Es ist einfach zu implementieren. So sieht beispielsweise die übliche Regel aus, mit der alle Arten der Interaktion zwischen Datenbankservern und externen Knoten in den letzten 30 Tagen mithilfe eines beliebigen Protokolls erkannt werden. Wir sehen, dass unsere Datenbanken mit Knoten außerhalb des DBMS-Segments unter Verwendung der Protokolle DNS, SMB und Port 8088 „kommuniziert“ haben.



Zusätzlich zu der tabellarischen Form zur Darstellung der Ergebnisse von Untersuchungen oder Suchen können wir sie auch visualisieren. In unserem Szenario könnte ein Fragment des Netzwerkflussdiagramms folgendermaßen aussehen: Auf



derselben Karte können wir Richtlinien verwalten - Verbindungen blockieren oder den Prozess der Erstellung von Überwachungsregeln für die für uns interessanten Flüsse automatisieren.



Hier ist ein sehr interessantes und lebendiges Beispiel für die Verwendung von Netflow-Überwachungstools (und anderen Ablaufprotokollen) für die Cybersicherheit. In den folgenden Hinweisen möchte ich zeigen, wie Sie mit NTA bösartigen Code (z. B. Shamoon), bösartige Server (z. B. die DNSpionage-Kampagne), RAS-Programme (RAT), Unternehmensumgehungen usw. umgehen können.

Source: https://habr.com/ru/post/undefined/