AD-Cleanup: adminSDHolder

Im Rahmen der AD-Administration kommt es immer wieder vor, dass Accounts nicht vom Service-Desk oder anderen technischen Mitarbeitern administriert werden können, trotzdem der Account in einer OU liegt, die durch den Administrator verwaltet werden kann. Die Ursache dafür ist häufig, dass diese Accounts einmal Mitglied der geschützten Gruppen waren (Domain Admins, Enterprise Admins, Account Operators, …) oder es noch sind.

Für diese Gruppen gibt es einen besonderen Sicherungsmechanismus, den sogenannten „adminSDHolder“. Dieser Mechanismus sorgt dafür, dass Accounts die direkt oder mittels Verschachtelungen Mitglied dieser Gruppen sind, eine Vererbungsunterbrechung erfahren. Für sie gelten die Berechtigungen, welche auf der OU „adminSDHolder“ hinterlegt wurden. Weiterhin wird für diese Accounts das AD-Attribut „adminCount“ auf „1“ gesetzt(auf diesem Wege kann man sie auch über eine LDAP-Query recht simpel identifizieren). Die OU „adminSDHolder“ enthält selbst keine Objekte, sondern dient einfach nur als Aufhänger für die Berechtigungssteuerung der geschützten Objekte (Pfad: \\my.domain\System\adminSDHolder).

Diese Zuordnung erfolgt automatisch und wird standardmäßig alle 60 Minuten überprüft. Dabei ist es egal wo der Account im AD liegt. Leider wird diese Zuordnung nicht aufgehoben, wenn man aus den entsprechenden Gruppen entfernt wird. Für diesen Zweck empfiehlt es sich einen Prozess zu schaffen oder eine Automatisierung bspw. mittels eines Scripts. Den Scriptansatz habe ich kürzlich einfach mal umgesetzt und als Scheduled Task etabliert.

Das Script setzt das Attribut “adminCount” zurück und stellt die Berechtigungsvererbung für sämtliche AD-Objekte (User, Gruppe) wieder her, die nicht mehr Mitglied der geschützten Gruppen sind und das Attribut „adminCount“ auf „1“ gesetzt haben. Anschließend lässt sich der Account wieder entsprechend den Berechtigungen der OU, in der er sich befindet, verwalten und wie jeder normale Account behandeln.

Kurze Anmerkung:

Derzeit ist das Script noch gegen ein versehentliches Schreiben geschützt. Für einen schreibenden Durchlauf bitte die Variable $just_logging auf $false setzen.

Weiterhin wird eine Logdatei geschrieben, derzeit im Ausführungspfad – sollte für Scheduled Tasks auf einen entsprechenden Ordner gesetzt werden. Dazu die Variable $logpath auf den entsprechenden Wert setzen.

Skript: remove_from_adminSDHolder

Weiterführende Infos unter:

http://technet.microsoft.com/en-us/magazine/2009.09.sdadminholder.aspx

MS15-014: Vulnerability in Group Policy could allow security feature bypass: February 10, 2015

Bitte auch folgenden Artikel beachten:
MS15-011: Vulnerability in Group Policy could allow remote code execution: February 10, 2015

Problembeschreibung:
Ein Angreifer kann das „Group Policy Security Configuration Engine policy file“ auf einem Zielsystem über eine „man-in-the-middle attack“ in einen inkonsistenten Zustand versetzen.

Dies führt dazu, dass sämtliche Sicherheitseinstellungen auf möglicherweise weniger sichere Standardwerte zurückgesetzt werden. Bspw. könnten die in MS15-011 eingeführten Sicherheitsfeatures umgangen werden.

Maßnahme:
Der Patch KB3004361 für alle Clients ab Windows Vista und Serversysteme ab Windows Server 2003 ändert das Verhalten bei der Anwendung von Gruppenrichtlinien. Anstatt in einem Fallback-Szenario die Standardwerte zu laden, werden die letzten erfolgreich angewendeten Werte genutzt.

Einschätzung:
Die Installation des KB3004361 sollte zeitnah erfolgen, mit Funktionsbeeinträchtigungen ist nicht zu rechnen.

Installationsanweisungen:
Zur Behebung der Lücke ist es notwendig das per Windows Update bereitstehende Update KB3004361 auf allen Clients und Servern einzuspielen.

MS15-011: Vulnerability in Group Policy could allow remote code execution: February 10, 2015

Problembeschreibung:
Die Security Configuration Engine verarbeitet Gruppenrichtlinien, Herkunft und Integrität der GPOs werden dabei nicht überprüft. Durch Manipulation auf Netzwerkebene ist es möglich die Zugriff auf Sysvol-/Netlogon-Verzeichnisse umzuleiten und somit Clients/Servern andere GPOs unterzuschieben.

Dadurch kann Schadcode unbemerkt eingeschleust werden.

Maßnahme:
Der Patch KB3000483 für alle Clients ab Windows Vista und Serversysteme ab Windows Server 2008 führt das Feature „UNC Hardened Access“ ein. Dadurch wird eine gegenseitige Authentifizierung von Client und Server (Mutual Authentication) sowie das signieren von SMB-Traffic ermöglicht.

Eine Gruppenrichtlinie steuert die Aktivierung des Features „UNC Hardened Access“ für bestimmte Pfade nach Bedarf.
„MS15-011: Vulnerability in Group Policy could allow remote code execution: February 10, 2015“ weiterlesen

End of Support für Windows Server 2003: Sind Sie bereit?

Der 14. Juli ist nicht nur französischer Nationalfeiertag, sondern in diesem Jahr auch für die IT bedeutsam. Denn an diesem Tag endet der Support für Windows Server 2003.

Im vergangenen Jahr hat Microsoft den Support für Windows XP endgültig eingestellt. Für den „großen Bruder“ des Client-Windows tritt im Juli dasselbe Schicksal ein: Es wird dann keine Updates, keine Security-Fixes und keine Unterstützung mehr geben.

Windows Server 2003 war ein sehr beliebtes Server-Betriebssystem, und in einigen Unternehmen ist es das immer noch. Setzen Sie Windows Server 2003 noch ein? Dann lautet unsere Empfehlung, jetzt zügig auf eine aktuellere Windows-Version umzusteigen. Denn die Erfahrung mit Windows XP zeigt, dass nicht nur die Angriffe auf das veraltete System schnell zunehmen werden. Auch das Know-how im Markt schwindet schnell, sodass auch Drittanbieter oft keine Fragen mehr dazu beantworten können.

Wir stehen an Ihrer Seite: Unsere Systems Engineers analysieren mit Ihnen die Systeme in Ihrem Netzwerk und entwickeln einen Plan zum Umstieg. Dabei nehmen wir auch gern Kontakt zu den Herstellern Ihrer Fachapplikationen auf, um deren Empfehlungen für die Migration aufzunehmen.

Oder Sie kommen zu uns: Am 28. April 2015 laden wir Sie und Ihre Kollegen aus anderen Unternehmen zu einem „Chalk Talk“ ein. Gemeinsam mit Consultants aus unserem Haus diskutieren Sie anhand konkreter Beispiele, wie ein Umstieg von Windows Server 2003 auf ein aktuelles System aussehen kann. Ob Active Directory, Exchange oder Applikationsserver – eine technische Diskussion, die sicher viele gute Ideen erzeugt.

Die Teilnehmerzahl ist begrenzt, daher bitten wir um Ihre Anmeldung.

Wir freuen uns, mit Ihnen ins Gespräch zu kommen! Als kleinen zusätzlichen Service finden Sie im Anhang dieses Artikels auch noch eine Übersicht über die Support-Daten weiterer Microsoft-Systeme. So können Sie schon für die Zukunft vorplanen.

Kontakt: Nils Kaczenski, Teamleiter Microsoft-Consulting

Support-Daten für wichtige Microsoft-Produkte

 

 

Vasco Authentication Server for the Enterprise

We did some deployments with Vasco Identikey Server for multi-factor authentication already. The solution is not only feasible for One-Time-Password authentication as first and protecting factor in addition to the usual AD or other LDAP directory auth with username and Password, but it also provides one-stop-authentication in mixed environments and enables different „single-sign-on“ scenarios.

Just this week, I did my first deployment with the Virtual Appliances Vasco provides (be aware though that they need to be licensed in addition to the Identikey Server component you usually install on Windows or Linux). They work like a charm. The setup is really Enterprise-ready as in this case it aims at 1,000 users to be authenticated using username, password and an OTP from a physical Vasco Digipass Go6. You don’t want to assign those devices to 1,000 (or even 50) users manually. And you don’t want to create those users manually in Identikey Server.

For user import, you could go for a CSV list import or a filtered LDAP sync. We did decide for Dynamic User Registration (DUR) with back-end authentication against Active Directory. You can use group membership as a requirement for registration. Additionally, we configured Self-Assignment for the Digipasses. So now a user receives his or her Digipass and then connects to the NetScaler Gateway login page and enters

  1. Username (is automatically converted to lower case to prevent multiple user objects to be created in case somebody hits a shift key)
  2. Digipass serial number, AD password, current OTP <– all concatenated in the „Token“ field
  3. AD password (third field could be removed and AD-auth delegated to Identikey server for all cases, but we decided to keep it and do AD-auth from Identikey for DUR only)

Identikey server figures out a new user and starts DUR: password is validated against AD, okay, user created. OTP is checked against expected current value from serialnumber, okay, Digipass assigned. On subsequent logins, the Token field takes only the OTP. AD password is validated by NetScaler Gateway on its own (second authentication cascade) and finally the user is logged on and signed in to the Webinterface/Storefront showing available apps and desktops. Done.

The setup of replication between the Virtual Appliances was a breeze as well. Worked instantly and replicates the database and configuration of the Authentication Server bidirectonally. Just like that.

Citrix ShareFile – Neue Zone: Access Restricted!

Citrix hat vor wenigen Tagen bekanntgegeben, dass die FollowMeData-Lösung ShareFile um eine weitere Storage Zone erweitert worden ist: Die „Restricted StorageZone“. Was ist der Unterschied zwischen einer Restricted StorageZone und einer Standard StorageZone?

Im Unterschied zu den cloudbasierten Citrix-managed StorageZones und den vom Kunden verwalteten On-Premise-StorageZones sind Dateien, die in einer „Restricted StorageZone“ abgelegt werden, nur für domänenauthentifizierte Benutzer innerhalb des Unternehmens abrufbar. Citrix hat keinerlei Einfluss auf diese Zone und kann keine User außerhalb der Domäne berechtigen, auf abgelegte Dateien zuzugreifen. Die Datei- und Ordnernamen sind mit dem kundeneigenen AES256-Key verschlüsselt und Metadaten werden verschlüsselt in die ShareFile-Cloud übertragen. Die Verschlüsselung wird natürlich auch hier auf dem On-Premise-StorageZone Controller im kundeneigenen Unternehmensnetzwerk vorgenommen.

Um Zugriff auf die Daten innerhalb dieser StorageZone zu erhalten, ist eine Domänenauthentifizierung notwendig. Datei- und Ordnernamen bleiben nur innerhalb der Domäne bekannt und können von keinem anderen Account, ob extern oder Citrix-intern, abgerufen werden, sobald sich die Daten in einer solchen StorageZone befinden. Zudem müssen die User beim Zugriff nebst der ShareFile-Cloud-Authentifizierung ihre Identität über den StorageZone Controller überprüfen lassen.

Die reglementierte StorageZone muss nicht über ein Portforwarding o.Ä. dem Internet präsentiert werden. Falls die StorageZone nur mit einer internen IP konfiguriert wird, muss der User für den Zugriff über das Firmennetzwerk oder einen gesicherten VPN-Tunnel – zum Beispiel ein XenMobile Micro-VPN – verbunden sein, um auf Daten zugreifen zu können, Dateien zu teilen oder zu synchronisieren.

Und das Beste daran: Authentifizierten Benutzern geht der FollowMeData-Vorteil durch diese Lösung nicht verloren, sodass sie weiterhin auch mobil auf die Daten zugreifen und über mehrere Geräte synchronisieren können. Dateien aus der Restricted StorageZone können eben nicht mit Anwendern außerhalb des Unternehmens geteilt werden.

Quelle: http://goo.gl/qUGJVp

Networking – Mit Sicherheit im Access-Layer

Natürlich sollte man aus Sicherheitsgründen einige Grundregeln beim Einrichten von Switchen beachten. Im Regelfall stehen Core- und Distribution-Switche in zutrittsgesicherten Räumen. Switche auf Access-Ebene hingegen stehen leider viel zu oft offen für Mitarbeiter und teils sogar Unternehmensfremde frei zugänglich in Abstellkammern, Büros oder Fluren.

Wenn die Räumlichkeiten einem die Wahl lassen, ob ein abgeschlossener Raum oder der Flur als Standort für einen Access-Switch dienen kann, ist stets der abschließbare Raum mit entsprechend wenig Leuten, die Zutritt zu diesem haben, zu empfehlen. Zusätzlich sollte auf ausreichende Belüftung geachtet werden, damit die Switche nicht laufend den Hitzetod sterben.

Zudem kann man auf Switchebene nicht genutzte Ports administrativ deaktivieren, sodass zwar ein Kabel gesteckt werden könnte, aber keine Pakete über den Port fließen und somit das Netz lahmlegen würden. In manchen Szenarien machen Funktionen wie Port-Security Sinn, mit der man den Zugang am Port auf L2-Ebene begrenzen kann; oft allerdings würde die Ersteinrichtung und die Verwaltung einen enormen Mehraufwand bedeuten, der nicht immer gerechtfertigt ist. Steht der Switch in einem abgeschlossenen, nicht frei zugänglichen Raum, kann darauf im Zweifel auch verzichtet werden. Ansonsten kann es schnell dazu kommen, dass ein Anwender ein loses Netzwerk-Kabel findet und es unbedacht mit beiden Steckern in den Switch steckt. Das hat dann zur Folge, dass man entweder ineinanderlaufende VLANs – mit vielleicht zwei DHCP-Servern in einem logischen Netz –  oder sogar einen Loop in einem Netzwerk hat, der in komplexen Netzen oft schwer zu identifizieren ist, sich sehr negativ auf die Netzwerkperformance auswirkt und ganze Netzwerke – egal, wie performant sie ausgelegt sind, zum Zusammenbruch bringen kann.

Eine weitere Fehlerquelle im Netz kann ein falsch konfiguriertes Spanning-Tree-Protokoll, kurz STP sein. Sind die Prioritäten falsch gesetzt, kann es vorkommen, dass immer unterschiedliche statt der gewollten Ports geblockt werden und es laufend zu einer Neuberechnung des STP-Trees kommt.

Cisco ASA: Was sind Security-Zones?

Cisco ASA-Appliances nutzen für die Konfiguration von Zonen sogenannte Security-Level. Der Wert des Security-Levels gibt die Vertrauenswürdigkeit eines Netzwerkes je Interface/Zone an. Je höher ein Security-Level der Zone gesetzt ist, desto vertrauenswürdiger ist sie. Hohe Security-Level-Zonen haben per Default Zugriff auf niedrige Security-Zonen, andersrum wird der Zugriff standardmäßig verwehrt. Traffic zwischen Zonen mit demselben Security-Level werden standardmäßig geblockt.

Damit alle Zonen mit dem selben Security-Level untereinander kommunizieren dürfen, muss folgender Befehl abgesetzt werden:

ciscoasa(config)# same-security-traffic permit inter-Interface

Gibt man bei der Einrichtung der Zonen via ciscoasa(config)# nameif Inside und ciscoasa(config)# nameif Outside die Bezeichnungen Inside bzw. Outside für die Interfaces an, werden entsprechend des Interfaces sofort automatisch die Security-Level gesetzt. Das interne Interface erhält die 100 und das externe Interface die 0. Somit wird bereits bei der Grundeinrichtung für eine grundlegende Sicherheit gesorgt. Natürlich sollten hier noch ACLs konfiguriert werden, um ein entsprechendes Regelwerk abzubilden.

Einen ganz guten Richtwert gibt die folgende grobe Kategorisierung bei der Planung:

  • Ausgehendes Interface Richtung WAN/Internet: Security-Level 0
  • Weitere WAN-Verbindungen: Security-Level 10-30
  • DMZ und aus dem Internet erreichbare Netzwerke: 40-50
  • Interne, nicht vertrauenswürdige Netze wie z.B. ein Gast-WLAN: 60-70
  • Interne Netze (LAN, interne geroutete VLANs, internes WLAN …): 80 – 100

WireLurker – Ein Überblick und Erkennungsmaßnahmen

In den vergangenen Tagen wurden die Medien auf eine Meldung von Palo Alto Networks aufmerksam, die den OS X/iOS-Schädling WireLurker aufgespürt haben. WireLurker ist eine Malware, mit der es erstmalig möglich ist, von dem – bisher aufgrund der Systemarchitektur, basierend auf dem XNU-Kernel mit FreeBSD-Elementen als verhältnismäßig sicher geltenden – Betriebssystem Mac OS X ein via USB  verbundenes iOS-Gerät auch bei nicht-gejailbreakten Geräten zu infizieren. Aufgetaucht ist der Schädling erstmals im chinesischen, inoffiziellen AppStore Maiyadi. Schnell hat sich jedoch auch ergeben, dass der Schädling ebenfalls für die Verbreitung außerhalb dieses Stores geschrieben ist.

Möglich ist die Installation über die Ausnutzung von Enterprise-Zertifikaten, die von MDM-Systemen genutzt werden, um auf sicherer Basis Unternehmensdaten mit dem Mobilgerät zu synchronisieren und die Kommunikation mit dem MDM-Server des Unternehmens abzusichern. Zuerst wurde noch eine Sicherheitswarnung beim Ausführen gezeigt, die auf ein nicht vertrauenswürdiges Zertifikat hinweist. Mittlerweile kann es aber durchaus sein, dass ein vom Betriebssystem als vertrauenswürdig eingestuftes Zertifikat von den Angreifern genutzt wird, bei dem diese Warnung nicht erscheint. Es können über diesen Weg etliche Informationen über den Gerätezustand, installierte Apps, Kontakte und Nachrichten des Gerätes ausspioniert werden.

Ist daher eine Anschluss am PC oder Mac nicht zwingend notwendig, sollte dies vorerst vermieden werden. Geladen werden kann das Gerät über die Steckdose und einen USB/AC-Adapter, die meisten Einrichtungsschritte können mittlerweile ebenfalls ohne einen Computer erfolgen, sofern eine WLAN-Verbindung vorliegt.

Zudem sollte man unter Einstellungen„-„Allgemein„-„Profile prüfen oder bei Geräten, die durch das Unternehmen verwaltet werden durch die IT-Abteilung prüfen lassen, ob die installierten Profile zum Management der Geräte notwendig sind. Bei privaten Geräten sollten sich dort keine Profile befinden, sofern man Webmail-Dienste nutzt. Verschlüsselt man die Mailkommunikation und/oder versieht die Mailkommunikation mit einer digitalen Signatur, sollten sich dort, je nachdem, ob man nur signiert oder auch verschlüsselt, 1-2 Benutzer-Profile pro Mailpostfach befinden. Wer ganz sicher gehen will, sollte alle Profile entfernen und neu installieren bzw. das Gerät über die IT-Abteilung auf Werkseinstellungen zurücksetzen erneut ausrollen lassen.

Palo Alto hat nun auf github ein entsprechendes Erkennungstool für Mac- und Windows-Nutzer veröffentlicht. Eine Anleitung für beide Varianten ist ebenfalls github zu entnehmen. Natürlich sollte bei einem infizierten Host-System ebenfalls eine Neuinstallation durchgeführt werden.

Sicherheitslücke in iOS: Masquerade Attack

Nach der Veröffentlichung von „WireLurker“, einem USB-Verbindungs-basierten Angriff auf iOS-Geräte, ist nun eine weitere Sicherheitslücke innerhalb des mobilen Betriebssystems bekannt geworden. Der Angriff via „Masquerade Attack“, kurz „Masque Attack“ ist deutlich gefährlicher und für Nutzer zudem schwerer zu identifizieren, da auch die – bei WireLurker noch vorhandene – Sicherheitsabfrage nicht mehr erscheint. Der maskierte Angriff fragt lediglich die Installation einer App ab, die für die Durchführung des Angriffs erforderlich ist. Die schadhafte Software kann über einen Link bereitgestellt werden, der per Mail, SMS, iMessage oder sonstige Messenger wie Whatsapp oder den Facebook-Messenger durch das Gerät empfangen werden kann. Öffnet der User den Link, wird versucht, ein *.ipa-File von einem Server des Angreifers zu installieren. An diesem Punkt fragt iOS standardmäßig, ob die App installiert werden soll.

Lehnt der User die Installation ab, geschieht nichts. Aus diesem Grund ist das auch der empfohlene Weg, sich vor einem Angriff zu schützen.

Es sollten keine Apps aus anderen Quellen, als dem AppStore von Apple oder dem durch eine gemanagete MDM-Lösung angebotenen Enterprise-Store installiert werden.

Eine sehr beliebte Masche könnte beispielsweise die Angabe eines Flappy Bird-Downloads sein, da diese App nicht mehr über den AppStore von Apple erhältlich, aber dennoch sehr beliebt bei Anwendern ist. FireEye hat das Sicherheitsleck bisher bei den Betriebssystemversionen iOS 7.1.1, 7.1.2, 8.0, 8.1 und der Beta-Version von iOS 8.1.1 nachweisen können. Sowohl Geräte mit, als auch ohne Jailbreak sind für dieses Angriffsszenario empfänglich.

In einem Youtube-Video zeigt das Unternehmen FireEye, wie der Angriff erfolgen kann.