Eingehende Warnung auf einem VPN-Server: den Beobachtungspunkt lesen

Ein Server hinter einem VPN hält seine öffentlichen Dienst-Einträge, und die Leute finden sie immer wieder. Was in der Warnungswarteschlange ankommt, ist nicht ein Fund, sondern drei mögliche, und sie bedeuten unterschiedliche Dinge. Die erste Aufgabe besteht darin, einen offenen Dienst von offenen Zugangsdaten zu trennen.

Gehen Sie die Beobachtungspunkte der Reihe nach durch. Hören Sie auf, wenn die Beweise die Kategorie wechseln, denn die nächste Stufe beantwortet eine andere Frage.

Stufe eins: Was der Mitschnitt tatsächlich sah

Ein Paketmitschnitt zeichnet auf, was an seinem eigenen Punkt auf dem Pfad sichtbar war. Dieser Punkt kann vor einer späteren Filterentscheidung liegen. Ein mitgeschnittenes Paket beweist, dass der Verkehr dort ankam. Es beweist nichts darüber, was danach geschah.

Achten Sie auch auf die Schnittstelle. Ein Mitschnitt am öffentlichen Adapter und ein Mitschnitt innerhalb des Tunnels beschreiben verschiedene Ankunftspunkte, und eine Warnung, die den falschen zitiert, führt zur falschen Schlussfolgerung.

Windows filtert außerdem auf mehreren Schichten des Stacks, sodass das ordentliche Modell, in dem das Mitschnittwerkzeug auf Schicht zwei und die Firewall auf Schicht drei sitzt, den Kontakt mit einem echten Produkt nicht übersteht. Die Übersicht der Windows Filtering Platform beschreibt die Filterung über Stack-Schichten hinweg, und deshalb muss die Beobachtungsreihenfolge festgestellt statt angenommen werden.

Stufe zwei: Was der Drop-Eintrag belegt

Ein Drop-Eintrag besagt, dass eine Richtliniengrenze dieses Paket abgewiesen hat. Das ist ein starker Beweis. Er ist auch ein enger Beweis, denn er deckt eine Entscheidung an einer Grenze ab. Nichts anderes im Stack wird durch ihn beschrieben.

Korrelieren Sie über Tupel und Zeitstempel. Gleiche Quelle, gleiches Ziel, gleicher Port, innerhalb derselben Sekunde. Ohne diese Übereinstimmung ist ein ähnlich aussehendes Ereignis in einem anderen Protokoll einfach ein anderes Ereignis, und ihre Paarung erzeugt eine Geschichte, die niemand verteidigen kann.

# what did the firewall actually drop, and when?
Get-NetFirewallProfile -PolicyStore ActiveStore | Select-Object Name, LogAllowed, LogBlocked
Get-Content "$env:systemroot\System32\LogFiles\Firewall\pfirewall.log" | Select-String 'DROP'

# correlate with a listening service on the same port
Get-NetTCPConnection -LocalPort 3389 -State Listen | Select-Object LocalAddress, OwningProcess

Ein geschlossener Port und ein verworfenes Paket sehen von außen identisch aus und in diesen beiden Ausgaben völlig unterschiedlich. Genau dieser Unterschied ist der ganze Grund, den lokalen Eintrag zu lesen.

Stufe drei: Was das Authentifizierungsereignis beweist

Ein Authentifizierungsereignis besagt, dass eine Komponente die Anforderung weit genug verarbeitet hat, um ein Ergebnis aufzuzeichnen. Es ist die einzige der drei Stufen, die über Identität spricht, und es sagt nichts darüber, wie viele Pakete vorher ankamen.

Lesen Sie den tatsächlichen Kontext des Ereignisses. Ein fehlgeschlagenes Logon für ein Konto, das nicht existiert, ist Rauschen vom Scannen. Ein fehlgeschlagenes Logon für ein echtes Konto mit plausibler Quelle ist eine andere Priorität. Eine erfolgreiche Sitzung ist eine ganz andere Vorfallskategorie.

Achten Sie auch auf die Protokollnamen. RPC und RDP sind getrennte Dienste mit getrennten Ports. Ein Detektor, der einen davon beobachtet, deckt den anderen nicht ab. Werkzeuge, die Netzwerkaktivität zusammenfassen, geben nicht immer an, welcher der beiden das Ereignis erzeugt hat.

Eine korrelierte Stichprobe schlägt ein Dashboard

Wählen Sie einen autorisierten Test, führen Sie ihn absichtlich aus und verfolgen Sie ihn von Anfang bis Ende: Zieladresse und Schnittstelle, echte Quelladresse, Dienstport, wirksames Firewallprofil und wirksame Regel sowie das passende Dienstergebnis. Beziehen Sie jede vorgelagerte Zuordnung oder Cloud-Firewall in diese Kette ein, denn eine erlaubende Regel dort kann eine ordentliche lokale Regel überstimmen.

Trennen Sie dann die beiden Pflichten. Wenn die Verwaltung nur über VPN erfolgen soll, setzen Sie das sowohl auf dem öffentlichen als auch auf dem Tunnelpfad durch und behalten Sie einen genehmigten Wiederherstellungsweg bei. Einen abgewiesenen Versuch zu überwachen ist nicht dieselbe Aufgabe wie zu entscheiden, was der Server annehmen soll.

Eine Geografie-Regel oder ein blockiertes, nicht verwandtes Protokoll ersetzt nicht das Auffinden des beobachteten Eintritts und der Entscheidung, die er erhalten hat. Eine VPN ersetzt das auch nicht: ausgehenden Verkehr durch einen Tunnel zu leiten, dokumentiert nichts über die eingehende Autorisierung.