ATA Gateways

Hallo Allerseits,

Im letzten Artikel haben wir gesehen wie die Installationen von ATA Center und ATA (Lightweight) Gateway durchgeführt werden. Inzwischen ist die Version 1.7 von ATA erschienen, mehr dazu findet ihr hier: https://blogs.technet.microsoft.com/enterprisemobility/2016/08/31/introducing-advanced-threat-analytics-v1-7/.

Ich spule in der Zeit aber noch ein wenig zurück, nämlich vor den Installationszeitpunkt des ATA Gateways. Im letzten Artikel erwähnte ich das ein ATA Gateway dualhomed (zwei NICs) aufgebaut wird. Dies trifft nach wie vor für das “klassische” ATA Gateway zu, aber nicht für das ATA Lightweight Gateway. Das ATA Lightweight Gateway wird direkt auf den DCs der bisher nicht für ATA Gateway geeigneten Strukturen (Cloud, Filiale, …) installiert. Dazu später mehr.

Das “klassische” ATA Gateway besitzt nun zwei NICs, eine davon wird als Capture-Adapter eingesetzt. Der zweite Adapter wird ganz normal im Netzwerk etabliert. An den Capture-Adapter wird der DC-Traffic via Mirror-Port gespiegelt. Dies kann in virtualisierten Umgebungen, wie auch in realen Umgebungen (Hardware) umgesetzt werden – ja nach Szenario: https://blogs.technet.microsoft.com/pfesweplat/2015/12/23/port-mirroring-for-advanced-threat-analytics/

In einer Hyper-V-basierten Umgebung wie bei der iteracon sieht die Konfiguration wie folgt aus. Auf Hyper-V wird “Microsoft NDIS Capture” installiert und auf dem betroffenen virtuellen Switch aktiviert:

image

Daraufhin werden die Quellen (DCs) und Ziele (Gateways) definiert. Hier wird z.B. auf einem unserer DCs als Mirroring mode “Source” eingestellt:

image

Auf der Gegenüberseite (Capture-NIC auf ATA Gateway) die “Destination”:

image

Im Anschluss daran empfiehlt sich die Kontrolle ob auch die gewünschten Datenpakete via Mirror-Port auf dem Gateway ankommen. Hierzu installiert man einfach den Microsoft Network Monitor 3.4 https://www.microsoft.com/en-us/download/details.aspx?id=4865 (Achtung, keinen anderen Sniffer verwenden, dies ist kontraindiziert für das ATA Gateway). Den Network Monitor starten, “P-Mode” anklicken und die Capture NIC per Checkbox auswählen:

image

New Capture auswählen und nach KerberosV5 OR LDAP filtern (Apply nicht vergessen!):

image

Daraufhin sollte LDAP-Traffic angezeigt werden:

image

Et voilà, es kommen LDAP-Daten auf dem ATA Gateway an und diese können nun vom Gateway analysiert werden. Bitte beachtet die Kapazitätsplanungen für die Gateways und plant die ATA Gateways passend in eure Umgebungen ein (https://docs.microsoft.com/en-us/advanced-threat-analytics/plan-design/ata-capacity-planning). Eine kleine Anregung für die Planungen: was passiert wenn z.B. ein DC innerhalb eines Hyper-V-Clusters auf einen anderen Knoten umzieht? Dann sollte das ATA Gateway mit rüber wandern!

Kommen wir noch abschließend zum ATA Lightweight Gateway. Dieses wird ja wie oben bereits erwähnt direkt auf einem DC installiert. Installationsgrundvoraussetzung ist übrigens das .NET 4.6.1, dies kann je nach Firmenpolitik ein No-Go sein. Als Installationsquelle werden die gleichen Gateway-Bits verwendet, wie beim ATA Gateway auch. Falls .NET noch nicht anliegt hilft die Installationsroutine nach:

image

Los geht der Spaß:

image

Nicht genug CPU und/oder RAM? Dann wird gemeckert:

image

Wo und wer:

image

Und wieder: rufen Sie nicht uns an, wir rufen Sie an:

image

image

Nach der Installation erscheint ein ATA Lightweight Gateway mit einem kleine “Zelt-Symbol” in der ATA Konfiguration:

image

 

Sobald die ATA Gateways etabliert sind und die DCs komplett “eingefangen” wurden kann über die Thematik Windows Event Forwarding (WEF) zur Verbesserung der Pass-the-Hash Attacken nachgedacht werden. Dazu mehr im nächsten Blogartikel zum Thema ATA.

Gruß und bis dahin,

Karsten Hentrup…

|<-|

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*