ATA Gateways

{ Posted on Jun 13 2016 by Karsten Hentrup }
Categories : ATA, Karsten Hentrup

Hallo Allerseits,

der folgende ATA-Blogeintrag musste leider ein wenig auf sich warten lassen, da ich gesundheitsbedingt einige Zeit aus dem Rennen war.Gebrochenes Herz

Im letzten Artikel haben wir gesehen wie die Installationen von ATA Center und ATA Gateway durchgeführt werden. Inzwischen ist die Version 1.6 von ATA erschienen, mehr dazu findet ihr hier: https://blogs.technet.microsoft.com/enterprisemobility/2016/05/05/advanced-threat-analytics-new-version-1-6-is-now-available/.

Grundsätzlich hat sich in Sachen Installation nichts großartig verändert, bis auf die Tatsache das es nun ein sogenanntes “ATA Lightweight Gateway” gibt. Dieses wiederum ermöglicht den Aufbau von ATA Gateways, wo die Umgebung kein Port-Mirroring hergibt, wie z.B. in Cloud-Szenarien! Somit ist ATA nun kein reines “on-promise-Produkt” mehr
(lass dich nicht ärgern Dieter *ggg* http://blog.dieter-rauscher.de/it/?p=1329).

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 meinem Arbeitgeber (www.iteracon.de) 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 dieses kann nun anfangen diese zu analysieren. Bitte beachtet die Kapazitätsplanungen für die Gateways und plant die ATA Gateways passend in eure Umgebungen ein. 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) nachgedacht werden. Dazu mehr im nächsten Blogartikel zum Thema ATA.

Gruß und bis dahin,

Jens Mander aka Karsten Hentrup…

<j-j>

Post a Comment

Kommentare werden moderiert. Es kann etwas dauern, bis dein Kommentar angezeigt wird.

*