Tag Archives: Active Directory

Best Practices: WatchGuard AuthPoint – Active Directory und LDAP

Den steigenden Bedarf im Bereich Authentifizierung belegt nicht zuletzt der Data Breach Investigation Report: Danach standen 63 Prozent der bestätigten Datenpannen im Zusammenhang mit gestohlenen oder schwachen Standard-Passwörtern – ein klares Indiz dafür, dass Multifaktor-Authentifizierung zu den kritischen Erfolgsfaktoren einer ganzheitlichen Sicherheitsstrategie gehört.

In diesem Webinar stellen WatchGuard-Securityexperten vor wie mit WatchGuard AuthPoint eine einfache und sichere Multifaktor-Authentifizierung für den Zugriff auf Unternehmensressourcen implementiert werden kann.

Das Webinar ist wie folgt gegliedert:
Weiterlesen »

Best Practices – Threat Detection and Response – AD-Helper

Inhalt:

WatchGuard Threat Detection and Response (TDR) hilft Unternehmen und Kunden ihre Clients (Windows, Mac oder Linux Systemen) noch mehr abzusichern und eine zweite Verteidigungslinie zu installieren.

Der AD-Helper hilft dem Administrator, seine Active-Directory-basierten Clients automatisiert in die Verwaltung zu übernehmen. Sehen Sie in diesem Webinar, wie es einfach und schnell umgesetzt werden kann.

Ziel dieser technischen Webinar-Reihe ist es, Ihnen umfassende Hintergrundinformationen zu vermitteln.
Anhand von Konfigurationsbeispielen wird dargestellt, wie Sie die Security-Lösungen von WatchGuard optimal und effektiv einsetzen können.

 

Jetzt online für dieses kostenfreie Webinar registrieren

Gross-/Kleinschreibung bei Active Directory Authentication

Wenn Firewall-Regeln auf Basis einer Active Directory Gruppenmitgliedschaft oder eines Active Directory Username geschrieben werden, muss der Name der Gruppe oder des Users auf der WatchGuard zuerst einmal “bekannt gemacht” werden: Setup > Authentication > Authorized Users/Groups. Als “Name” MUSS genau die gleiche Schreibweise bezüglichGroß-/Kleinschreibung verwendet werden mit der die Gruppe bzw. der User im Active Directory angelegt ist (sAMAccountName):


Anderenfalls ist zwar unter Umständen die User Authentication an für sich erfolgreich, jedoch werden dabei nicht die passenden Gruppenmitgliedschaften ausgelesen – entsprechende Firewall-Regeln laufen daher ins Leere. Im Traffic Monitor wird der Traffic zwar als dem User zugehörig angezeigt, aber u.U. eben trotzdem als Unhandled Packet und daher als denied.

RMA Fälle der letzten Zeit

Ich hatte in den letzten Wochen drei Fälle, in denen WatchGuard die Hardware Appliance im Zuge eines Support Incidents ausgetauscht hat:

  • Defekte XTM 505: nachdem die Ersteinrichtung (incl. Aufspielen des Feature Key) einwandfrei geklappt hatte, blieb beim nächsten Boot-Vorgang das LCD-Display komplett leer (Hintergrundbeleuchtung an), die Box “kam nicht hoch” und auch die Lüfter liefen nach wie vor auf 100% (reduziert sich normalerweise nach ca. 20-30 Sekunden auf eine geringe Drehzahl).
  • Defekte X10e: trotz korrekter Ausführung eines “Factory Reset” (für mehr als 1 Minute gedrückter RESET-Buttons während Power On) startete die Box nicht in die Maintenance-Partition SYS-B (Safe Mode) – stattdessen war wieder die reguläre Partition SYS-A und die reguläre Konfigurationsdatei aktiv…
  • Defekte SSL100: Probleme mit User Authentication (Microsoft ActiveSync gegenüber Active Directory für den SSL-Zugriff von Apple iPhone auf Microsoft Exchange Server)

Begrenzter Zeichensatz bei Active Directory Authentication

Puuuuh, nach mehr als einem halben Jahr komme ich endlich mal wieder dazu, hier einen Beitrag zu schreiben. Ich will nicht klagen, es waren einfach sehr viele und anspruchsvolle Projekte in den letzten Monaten. In den nächsten Wochen hoffe ich nun, hier wieder einige hilfreiche Postings schreiben zu können.

Ich fange mit einem “alten Schuh” an, allerdings in einer etwas anderen Ausprägung. Ich habe bereits ja empfohlen, sich in der WatchGuard XML Konfigurationsdatei, und insbesondere bei Passwörtern, Pre-Shared Keys etc. auf den Zeichensatz US-ASCII 7 zu beschränken, d.h. also insbesondere auf die Verwendung von äöüß und Sonderzeichen zu verzichten. Ich empfehle sogar, Kennwörter etc. gänzlich nur aus den klassischen Buchstaben A-Z, a-z und den Ziffern 0-9 zu bilden. Ganz ohne Sonderzeichen, lieber ein paar Stellen mehr…

Wenn nun User Authentication gegenüber Active Directory im Spiel ist, sollte diese Grundregel auch beherzigt werden, wenn die User ihre AD/Windows-Kennwörter festlegen. Ein Kunde berichtete von MUVPN-Einwahl-Problemen bei einem bestimmten User. Dieser hatte ein €-Zeichen in seinem Windows-Kennwort. Die Einwahl schlug fehl. Nach Änderung des AD/Windows-Kennworts (ohne €-Zeichen) war die Einwahl erfolgreich!

Der Kunde hat mir freundlicherweise eine Liste von Zeichen geschickt, die in einem AD/Windows-Kennwort vorkommen dürfen, damit eine MUVPN-Einwahl / User Authentication erfolgreich ist:

!#$%&()*+,-.0123456789:;<=>@ABCDEFGHIJKLMNOPQRSTUVWXYZ[]_abcdefghijklmnopqrstuvwxyz{} und das “Leerzeichen”…

Diese Einschränkung dürfte dann auch gelten, wenn die Einwahl bzw. Authentication per PPTP-VPN (i.V. mit RADIUS), SSL-VPN (AD oder RADIUS) und auch in Verbindung mit Two-Factor Authentication Systemen wie VASCO oder RSA gegenüber AD erfolgt!

XTM 11.4: mehr Details zu den neuen Features

Die Fireware XTM v11.4 befindet sich kurz vor dem Beta-Stadium. Das endgültige Release ist noch für 2010 angekündigt (Dezember). Hier eine aktuelle Zusammenfassung der neuen Features und Produkt-Verbesserungen. Bitte beachten Sie, dass einige Neuerungen NUR für die neuen XTM Hardware Appliances bereitgestellt werden – NICHT jedoch für die bisherigen Produktreihen X Edge e-series, X Core e-series und X Peak e-series…

Application Control: Diese bahnbrechende Funktion ermöglicht, dass speziell der Zugriff auf Web 2.0 Anwendungen wie Facebook, Skype, YouTube, Twitter, Gmail, BitTorrent, MSN, Yahoo Messenger, WebEx, Teamviewer, weitere Instant Messaging und über 1.500 weitere Web Anwendungen wesentlich genauer reglementiert werden kann als bisher. Application Control gibt den Admins also wieder die tatsächliche Kontrolle über die Nutzung ihrer Internet-Bandbreite zurück.

Intrusion Prevention Service: Die Kooperation mit einem neuen Signatur-Anbieter ermöglicht eine eine einfachere Konfiguration, die auch alle Ports und Protokolle scannen kann.

Configuration History und Rollback: Bei Verwendung des WatchGuard Management Servers kann nun auch automatisiert eine gewisse Histore von Konfigurationsdateien verwaltet werden.

In gemanagten Umgebungen (WatchGuard Management Server) können nun wesentlich mehr Features innerhalb von Policy Templates genutzt werden: sowohl globale Einstellungen als auch lokale Einstellungen (z.B. lokale SNAT-Regeln für lokale Mailserver).

Verbessertes Reporting: z.B. Überblick über Application Control und DHCP Leases. Reports können nun bei Bedarf mit einer Zeitsteuerung versehen werden. Auch können Admins per SMTP über die Bereitstellung von neuen Reports informiert werden.

Terminal Services Authentication: Auch dieses Feature ist bahnbrechend! Mit Version 11.4 wird ein neuer Agent bereit gestellt, der auf einem Terminalserver installiert werden kann. Der WatchGuard Firewall werden dann die angemeldeten User und deren Gruppen-Mitgliedschaften gemeldet, so dass session-basiert unterschiedliche Berechtigungsebenen auf dem gleichen Terminalserver realisiert werden können.

Als neues Feature wird die parallele Nutzung von Active Directory-basiertem Single Sign-On und manueller Anmeldung angepriesen, wenn z.B. neben Windows-Maschinen auch Apple Mac und Linux Systeme eingesetzt werden. Dies ist jedoch auch jetzt bereits bei den aktuellen Versionen 11.3.x möglich… Neu ist jedoch, dass auf EINER WatchGuard Firebox auch MEHRERE Active Directory Domains für die User Anmeldung unterstützt werden – und dass für die Abfrage nicht nur klassisches LDAP, sondern aus Sicherheitsgründen auch LDAP-SSL unterstützt wird.

XTM 2 Wireless Appliances bekommen die Möglichkeit, nicht autorisierte (Rogue) WLAN Access Points zu erkennen und zu reporten.

Das WebUI wird erweitert, so dass auch Application Proxy Settings über das Webinterface bearbeitet werden können.

Als weniger wichtig schätze ich ein, dass künfig der “Drop-In-Mode” auch auf Active/Passive Cluster Konfigurationen unterstützt wird – und dass neue XTM Appliances (“out of the box”) auch über den Quick Setup Wizard registriert werden können, wenn dort Benutzername/Kennwort für den WatchGuard LiveSecurity Account eingegeben werden können.

XTM: SSO Exceptions jetzt auch als Host Range und Network IP

Bei einer WatchGuard Firebox oder XTM hat Single Sign On (SSO) in Verbindung mit Active Directory die Aufgabe, automatisch zu erkennen, welcher Windows-User an einem PC angemeldet ist und dies an die WatchGuard Firebox zu melden, damit Firewall-Regeln angewendet werden, die auf einer Gruppenmitgliedschaft oder einem Usernamen basieren. Wie beim händischen Ausfüllen der Authentication Page (Port 4100) lernt die WatchGuard mit Hilfe des SSO Agent (und des optionalen SSO Client) dabei, welcher User sich hinter einer bestimmten IP “verbirgt” und in welchen Active Directory Gruppen dieser User Mitglied ist.

Die automatische Erkennung per SSO macht jedoch nur Sinn bei Standalone-PCs, die Mitglied einer Windows-AD-Domäne sind – und an denen jeweils nur ein User gleichzeitig angemeldet ist. In der Regel ist es empfehlenswert, Maschinen, die kein AD-Domänenmitglied sind oder kein Windows-Betriebssystem haben (z.B. Apple Mac, Linux oder Windows Mobile Clients) sowie Windows-Server von der automatischen User-Erkennung per SSO auszuschließen.

Bislang konnte die Liste der so genannten “SSO Exceptions” nur relativ umständlich befüllt werden. Jede dementsprechende IP-Adresse musste einzeln eingetippt werden. Mit dem aktuellen WatchGuard System Manager (WSM) und Fireware XTM 11.3.2 lassen sich nun auch die von normalen Firewall-Regeln her bekannten Auswahlen Host Range, Network IP und Host Name (DNS lookup) verwenden, was das Befüllen der SSO Exception List in vielen Umgebungen sicher deutlich vereinfachen wird:

Gross-/Kleinschreibung bei Active Directory Authentication

Wenn Firewall-Regeln auf Basis einer Active Directory Gruppenmitgliedschaft oder eines Active Directory Username geschrieben werden, muss der Name der Gruppe oder des Users auf der WatchGuard zuerst einmal “bekannt gemacht” werden: Setup > Authentication > Authorized Users/Groups. Als “Name” MUSS genau die gleiche Schreibweise bezüglich Groß-/Kleinschreibung verwendet werden mit der die Gruppe bzw. der User im Active Directory angelegt ist (sAMAccountName):


Anderenfalls ist zwar unter Umständen die User Authentication an für sich erfolgreich, jedoch werden dabei nicht die passenden Gruppenmitgliedschaften ausgelesen – entsprechende Firewall-Regeln laufen daher ins Leere. Im Traffic Monitor wird der Traffic zwar als dem User zugehörig angezeigt, aber u.U. eben trotzdem als Unhandled Packet und daher als denied.

Fireware XTM: Reihenfolge der Anmelde-Domänen auf der Anmeldeseite

In Verbindung mit User Authentication wird meist die manuelle Anmeldeseite der WatchGuard Firewall Appliance verwendet:
https://[IP-der-Firebox]:4100.
Die Authentication kann entweder gegenüber der lokalen Benutzer-Datenbank der Firebox selbst erfolgen (Firebox-DB), alternativ gegenüber externen Benutzer-Datenbanken unter Verwendung von RADIUS, SecureID/VASCO, LDAP oder Active Directory. Selbst wenn in der Firebox-DB gar keine lokalen User vorhanden sind, weil z.B. generell mit Active Directory gearbeitet wird, sieht die Anmeldeseite BEIM ERSTEN AUFRUF erst einmal so aus, d.h. standardmäßig wird “Firebox-DB” als Anmelde-Domäne angezeigt:

Die User müssen also in diesem Fall nicht nur geschult werden, dort ihren Windows-Benutzernamen und ihr Windows-Kennwort einzugeben, sondern auch noch in dem Pulldown-Menü darunter MANUELL von “Firebox-DB” auf “Active Directory” umzustellen. Das gestaltet sich manchmal etwas schwierig……… Besser wäre es natürlich, wenn die Anmeldeseite auch schon beim ersten Aufruf standardmäßig “Active Directory” als Anmelde-Domäne zeigen würde:

Die Reihenfolge der Anmelde-Domänen in dem Pulldown-Menü lässt sich durch einen manuellen Eingriff in die XML-Konfigurationsdatei beinflussen.
Erzeugen Sie als Backup zunächst eine Kopie Ihrer aktuellen XML-Konfigurationsdatei. Öffnen Sie die XML-Datei dann mit einem entsprechenden Editor. WordPad reicht schon. Suchen Sie nach dem Tag “auth-domain-list”. Sie werden erkennen, dass dort die von Ihnen verwendeten Anmelde-Domänen als “auth-domain” aufgelistet sind. An erster Stelle werden Sie “Firebox-DB” finden. Sie können nun die Anzeige-Reihenfolge festlegen, indem sie die jeweils vollständigen “auth-domain”-Tags per Cut&Paste in der gewünschten Reihenfolge anordnen. Speichern Sie die geänderte XML-Datei, öffnen Sie diese über den Policy Manager und laden Sie sie per “Save to Firebox” auf die WatchGuard hoch.
ACHTUNG: Wie immer ist in einem solchen Fall natürlich sehr sorgfältiges Vorgehen angesagt!!!

SSL 100: One Time Password per SMS

Die einfachste Form der User Authentication an einer WatchGuard SSL 100 ist die Kombination aus Benutzername und Kennwort, WatchGuard SSL Password. Die User und Kennwörter können auf der SSL100 selbst gepflegt werden oder es erfolgt ein Mapping zu einer externen Benutzerdatenbank, z.B. einem Active Directory. Damit nicht die unbefugte Weitergabe der Zugangsdaten an Dritte die Sicherheit der internen Daten und Programme gefährdet, kann eine zweite Komponente die Sicherheit erhöhen: eine Two-Factor Authentication, also die Kombination aus Wissen und Besitz oder Biometrie). Neben der Kenntnis von Benutzername und Kennwort ist auch noch eine zweite Komponente erforderlich, z.B. ein OTP Token als Schlüsselanhänger, der zeitgesteuert z.B. alle 60 Sekunden eine neue 6-stellige Zahl anzeigt, die bei der Anmeldung zusätzlich abgefragt wird. Hersteller sind u.a. RSA und VASCO. Alternativ ist es auch möglich, das Einmal-Kennwort per E-Mail (z.B. an BlackBerry Handhelds, iPhone oder andere Mobile E-Mail Devices) zu versenden – oder per SMS auf ein beliebiges Mobiltelefon.
Wenn das One Time Password (OTP) per SMS versendet werden soll, bedient man sich in der Regel eines SMS-Providers, bei dem man ein gewisses Kontingent an SMS einkauft. Ein möglicher Anbieter ist Clickatell. Nach der Aktivierung eines Accounts und dem Kauf eines SMS-Kontingents (hier 400 SMS für 17,60 EUR = 4,4 ct pro SMS) bekommt man von Clickatell drei Zugangsinformationen zugewiesen: USERNAME, PASSWORD und API_ID. Diese drei Angaben ersetzen die Platzhalter in folgender URL: https://api.clickatell.com/http/sendmsg?user=USER&password=PASSWORD&api_id=API&to=[$user-mobile]&text=[$message].
In der Konfiguration der WatchGuard SSL100 wird diese URL an folgender Stelle eingetragen: Manage System > Notification Settings > SMS Channel > Add SMS Channel > Plugin = HTTP-Plugin > URL > Save > Save (!!!) > Publish (!!!)
Außerdem muss sichergestellt sein, dass WatchGuard SSL Mobile Text generell als Authentication Methode enabled ist und auch in den entsprechenden Userkonten, die dieses Verfahren nutzen sollen. Dort muss ebenfalls die Mobilfunknummer eingetragen werden, an die die SMS geschickt werden soll (hier im Format 49171xxxxxxx). Die Nutzung des SMS-OTP macht natürlich nur dann Sinn, wenn in den betreffenden User-Accounts die Anmeldemethode WatchGuard SSL Password disabled wird, denn sonst wäre ja nach wie vor die einfache Anmeldung nur mit Benutzername und Kennwort möglich. Beim Aufruf der Anmeldeseite wählt der User also WatchGuard SSL Mobile Text aus und meldet sich zunächst mit seinem regulären Benutzernamen und Kennwort an:

Dadurch wird die Erzeugung des SMS-OTP angestoßen und wenige Sekunden später kommt eine SMS an. Als Absender der SMS tritt bei Clickatell eine +44 Nummer in Erscheinung, da das Gateway wohl in Großbritannien betrieben wird. Der Standard-Text der SMS lautet: Your OTP is xxxxxx. Enter it to login with Mobile Text. Anschließend steht die gewohnte Portaloberfläche mit den freigegebenen Icons zur Verfügung.