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…

|<-|

ATA Installation

Hallo Allerseits,

wie bereits angekündigt hier nun ein Blogeintrag zum Thema ATA Installation. Die zu installierenden Komponenten sind ja ATA Center, ATA Gateway und ATA Lightweight Gateway.
Die Komponenten werden in einer produktiven Installation idealerweise voneinander getrennt aufgebaut.

Das ATA Center wird unihomed erstellt (eine NIC), aber idealerweise mit zwei IPs. Das ATA Gateway wird dualhomed (zwei NICs) aufgebaut, jede NIC bekommt eine IP. Da eine NIC beim Gateway “nur” als Capture-Adapter aufgebaut wird kann hier auch eine IP verwendet werden, welche nicht in den LAN-IP-Bereichen verwendet wird. Das ATA Lightweight Gateway wird AUF einem DC installiert und benötigt somit keine eigene Serverstruktur. Allerdings muss der betroffene DC über die geforderten Leistungsdaten verfügen, hierzu ist die Kapazitätsplanung das A und O (https://docs.microsoft.com/de-de/advanced-threat-analytics/plan-design/ata-capacity-planning)!

Zuerst wird das ATA-Center installiert, dann die Gateways. Zur weiteren Orientierung ist folgender Technet-Artikel interessant: https://docs.microsoft.com/de-de/advanced-threat-analytics/deploy-use/install-ata-step1

Center Installation:

clip_image001

Hier seht ihr, wie ich auf meiner Testinstanz für das ATA Center doch nur eine IP, aber unterschiedliche Sockets etabliert habe (443 + 444). Bei den Installationspfaden kann darüber nachgedacht werden die DB auf andere Partitionen zu legen und diese aus dem AV auszuschließen.

clip_image002

Rufen Sie nicht uns an, wir rufen Sie an:

clip_image003

Fertig:

clip_image004

Nach der Installation kann auf das Webfrontend des ATA Centers zugegriffen werden. Es wird sich entweder mit einem lokalen Admin authentifiziert (Workgroup-Szenario) oder mit einem Admin aus dem AD (Domain-Szenario):

clip_image005

Die Installation ist zunächst zeitlich limitiert, bis eine passende Seriennummer eingegeben worden ist.

clip_image006

Unter Configuration wird ein Benutzeraccount für einen AD-Connector angeben, hier reicht ein normaler Domain-User aus.

Danach führt ein beherzter Klick auf „Download ATA Gateway Setup“ zu den ATA Gateway Installationsdateien. In dem heruntergeladenen Zip-Archiv befindet sich eine personalsierte .json-Datei, insofern ist die Installation nur für das jeweilige Center als Backend geeignet:

clip_image007

Gateway Installation:

clip_image008

Für die Gateway Registrierung wird ein Admin-Account benötigt. Neben Self-signed Zertifikaten können auch Zertifikate der internen PKI verwendet werden, so vorhanden. Weitere Informationen dazu findet ihr hier: https://technet.microsoft.com/de-de/library/mt429319.aspx

clip_image009

Und wieder geht die Installation auf die Reise:

clip_image010

rdy:

clip_image011

Nach der ATA Gateway Installation meldet man sich im ATA Center an, um dann den zu überwachenden DC anzugeben, sowie die Capture-NIC definieren:

clip_image012

Speichern und Synchronisation abwarten bis:

clip_image013

Kontrolle ob folgende Dienste auf den jeweiligen Servern gestartet sind (hier ist zu Testzwecken das Center + Gateway auf einem Server installiert):

clip_image015

 

Wenn die AD Anbindung sauber läuft, dann sollte in der ATA Center Konsole eine Suche etwas zutage fördern:

clip_image016

Oder:

clip_image018

Schick, ATA lernt:

clip_image019

 

Lightweight Gateway Installation:

Seit der ATA Version 1.6 gibt es neuerdings sogenannte ATA Lightweight Gateways. Diese werden verwendet, wenn die Infrastruktur z.B. nicht die Möglichkeit bietet Spiegelports zu verwenden. Dies ist unter anderem in Cloud-Umgebungen wie Azure der Fall. Ein ATA Lightweight Gateway wird direkt auf den betroffenen DCs installiert. Voraussetzung hierfür ist das .Net Framework in der Version 4.6.1 (oder höher).

Die ATA Setup-Routine installiert das Framework selbständig, falls fehlend:

clip_image001[1]

Die Installation des ATA Lightweight Gateways ist recht einfach:

clip_image002[1]

Im Vorfeld genügend Ressourcen besorgen (Stichwort: Kapazitätsplanung, s.o.!), ansonsten kommt eine Hinweismeldung:

clip_image003[1]

clip_image004[1]

clip_image005[1]

clip_image006[1]

Nach der Installation sieht man das Lightweight Gateway natürlich auch in der ATA-Konfiguration:

image

Damit ATA aber einwandfrei lernen kann sind noch ein paar Basiskonfigurationen nötig. Dazu mehr im nächsten Artikel.

 

Gruß,

Karsten Hentrup aka Jens Mander…

<j-j>

ATA Planung

Hier nun wie angedroht ein weiterer Artikel zum Microsoft Advanced Threat Analytics (ATA).

Die Idee: zu ATA werden die Active Directory Daten gespiegelt, ausgewertet und auf möglichen Missbrauch bzw. Auffälligkeiten hin untersucht. Hierzu ist ein Setup von sogenannten ATA (Lightweight) Gateways nötig, welche die gespiegelten AD-Daten aufnehmen. ATA lernt nun die Umgebung kennen, wertet diese aus und meldet sicherheitsrelevante Informationen über das ATA Center. Auf dem ATA Center ist eine Timeline von Alarmen einsehbar, inklusive erster Empfehlungen der weiteren Vorgehensweise.

Die wichtigsten Infos vorab:

– ATA wird größtenteils on-premises aufgebaut. DCs in Azure oder anderen public Clouds werden mittels ATA Lightweight Gateways eingefangen (ab ATA V1.6).
– Idealerweise werden sämtliche DCs eines AD überwacht, dies erfordert sicherlich den Aufbau mehrerer ATA (Lightweight) Gateways.
– Den ATA Gateways werden die AD-Daten mittels Spiegelports von Switchen (real, virtuell) übermittelt. Die Platzierung der ATA Gateways stellt somit die erste (und größte) Herausforderung dar.
– Eine Alternative ist seit Version 1.6 das sogenannte ATA Lightweight Gateway. Dieses wird auf einem DC installiert und insofern ist kein dediziertes Gateway erforderlich. Bei beiden Gateway-Varianten sind die Systemanforderungen zu beachten!
– Sind die ATA (Lightweight) Gateways einmal platziert, dann beginnt automatisch ein Selbstlernprozess. Es ist NICHT erforderlich eine aufwendige Baseline zu erstellen, das System startet nach Positionierung vollkommen autark los.
– ATA kann in einem Workgroup Szenario aufgebaut werden.
– Die Auswertung/Interpretation der von ATA angezeigten Vorkommnisse stellt die zweite Herausforderung dar, da hierfür ggf. “Personen Tage” reserviert werden müssen.
– ATA kann unter anderem durch EMS (Microsoft Enterprise Mobility Suite) lizenziert werden. EMS ist im Vergleich zu den einzelnen Produkten recht günstig, fragt hierzu einen Cloud Solution Provider. Zur Not kann ich einen CSP empfehlen Smiley http://iteracon.de/public-site/news/show?e=19

 

ATA Topologie:

image

https://docs.microsoft.com/de-de/advanced-threat-analytics/plan-design/ata-prerequisites

ATA Kapazitätsplanung:

Für ATA kann je nach Umgebung einiges an Ressourcen gefordert sein:

https://docs.microsoft.com/de-de/advanced-threat-analytics/plan-design/ata-capacity-planning

ATA Test:

ATA Center und ATA Gateway kann zu Test- oder Laborzwecken auf einem Server installiert werden. Für den produktiven Einsatz sei eine Trennung aber empfohlen. Einen ersten Eindruck erhält man sicherlich auch, wenn nur ein DC überwacht wird. Für den produktiven Einsatz dürfte diese Sichtweise aber zu eingeschränkt sein.

Im nächsten Artikel zeige ich die Installation von ATA Center + (Lightweight) Gateways, stay tuned.

Gruß,

Karsten Hentrup…

>>

MFA 7.1.2.1 Portal Error nach Update…

…mir ist aufgefallen, dass ich noch gar nicht dazu gekommen bin mal einen Artikel zu MFA zu bloggen. Seitdem Microsoft Azure Multi-Factor Authentication als zweiten Authentifizierungsfaktor mit im Programm hat (https://azure.microsoft.com/de-de/services/multi-factor-authentication/) bin ich fleißig dabei dies bei unseren Kunden zu implementieren. Natürlich nehme ich jede neue Version “dankbar” entgegen und teste/implementiere diese.

So war ich sehr froh über die Tatsache, dass modifizierte web.configs ab einer MFA-Version nicht mehr überschrieben und auf Null gesetzt worden. Für das MFA Portal und den MFA Mobile App Web Service sind diese modifizierten Konfigurations-Files essentiell notwendig: https://azure.microsoft.com/de-de/documentation/articles/multi-factor-authentication-get-started-portal/

Letzte Woche wurde mir nun das Update auf die MFA Version 7.1.2.1 angeboten. Installiert hatte ich auf unseren Servern die Version 7.0.2.1. Auf unserem Test-HA-MFA-Array pflegte ich nun die neuen Bits ein und siehe da, seitdem war die Portal-Komponente nicht mehr nutzbar, ein netter Fehler schmeichelte den Browsern:

image

Nachdem ich ein paar weitere graue Haare (und Stunden der Fehlersuche) investiert habe starrte ich entgeistert auf den Leitsatz der Fehlermeldung:

The key WEB_SERVICE_SDK_AUTHENTICATION_CLIENT_CERTIFICATE_
THUMBPRINT does not exist in the appSettings configuration section.

Tja, was soll ich sagen: der Satz ist schon eindeutig! Es fehlt genau dieser oben erwähnte Part – und zwar in der oben erwähnten web.config. Genau diese web.config, die ja nun nicht mehr durch Updates überschrieben und somit auch nicht automatisch um neue Ideen/Features/Texpassagen erweitert wird. Somit wurde aus Segen ein Fluch, wie ich nach Validierung auf einem weiteren Testserver feststellen durfte. Hier im direkten Vergleich sichtbar:

image

Aufgefallen ist mir dieser Fehler zunächst bei dem MFA Portal. Unnötig zu erwähnen, das natürlich auch der MFA Mobile App Web Service ein neues Feld in der web.config hat. Smiley Die fehlenden Konfigurationspassagen können natürlich nachgepflegt werden und dann klappt’s auch wieder mit dem Nachbar Portal.

Insofern, wie heißt es so schön beim Spielen mit Updates auf dem Computer: Save early, save often!

Gruß,

Karsten Hentrup…

|<-|

Security by Microsoft: Advanced Threat Analytics (ATA)

Zur Ignite im Mai 2015 hat Microsoft ein Security Produkt namens ATA angekündigt. Wir waren schwer erstaunt, vor allem da Microsoft vor einiger Zeit ihre eigene Security-Schiene (Forefront) leider nahezu komplett eingestampft hat.

https://channel9.msdn.com/Events/Ignite/2015/BRK3870

Microsoft Advanced Threat Analytics (ATA) wurde somit eines meiner neuen Spielzeuge. Entwickelt seitens Aorato, eine Firma welche Ende 2014 bei Microsoft eingemeindet wurde:

http://blogs.microsoft.com/blog/2014/11/13/microsoft-acquires-aorato-give-enterprise-customers-better-defense-digital-intruders-hybrid-cloud-world/

Seit Ende August 2015 ist ATA nun in finaler Version verfügbar. Die Phase von der Technical Preview zur finalen Version war (zumindest für mich) recht kurz, weshalb ich das Produkt direkt mit den RTM-Bits aufbauen konnte. Belohnt wurde ich schon wenige Tage nach Aufbau des ersten Gateways. Ein Kollege von mir beglückte mich mit einem Identitätsdiebstahl:

2015-11-09_1658051[1]

Dies Problem ließ sich schnell lösen, mein Arbeitgeber muss jetzt einen Arbeitnehmer weniger füttern. 😉

Quatsch beiseite, dem Kollegen geht’s hervorragend und die Ursache war recht harmlos. Trotzdem interessant, auch nachdem ein weiterer Kollege seine Zauberkünste in der PowerHell [sic!] vorführte:

image

Ein gutes Jahr nach Produktrelease ist ATA nun auf die Versionsnummer 1.6 geklettert. Ich werde auf diesem Blog einige Erfahrungen rund um das Thema ATA zusammenfassen, bzw. berichten wie der Aufbau von ATA funktioniert.

Auch noch ein Jahr nach Produktrelease bin ich sehr zufrieden und schwer begeistert von dem Produkt! Ein interessantes Detail: ATA ist unter anderem in der Enterprise Mobility Suite enthalten.

Die Produktwebsite ist hier zu finden:

www.microsoft.com/ata

Gruß und bis dahin,
Karsten Hentrup…

|<-|

iteracon bloggt…

…Ich freue mich hier ankündigen zu dürfen, dass wir von der iteracon GmbH nun ein eigenes Blog hegen und pflegen. Wir werden hier über unsere Erfahrungen zu verschiedensten Microsoft-Produkten, deren Implementation und Betrieb berichten.

Unsere aktuellen thematischen Highlights sind die Managed Services rund um Microsoft Azure und Office 365, Consulting zum modernen effizienten Arbeiten rund um Windows 10, Office 2016, und Skype for Business. Darüber hinaus beschäftigen wir uns mit einigen Spezialthemen wie Multi-Factor Authentication, DirectAccess und Active Directory Security mit Advanced Threat Analytics.

Natürlich wird sich hier auch das eine oder andere “klassische” Microsoft Thema wiederfinden wie die System Center Suite, Exchange, Active Directory, Hyper-V, PKI, etc.

Wir lesen uns!

Gruß, Karsten Hentrup…

|<-|