WatchGuards Multifaktor-Authentifizierung AuthPoint bietet sein kurzem eine Schnittstelle zu Microsoft Cloud Azure an. Durch die Anbindung von MS Azure Active Directory bieten sich neue Möglichkeiten, WatchGuard AuthPoint im Unternehmen einzusetzen. Erfahren Sie in diesem Webinar, wie man die Verbindung zwischen AuthPoint als IdP Provider und MS Azure als Dienstleister herstellt und verwendet.
Mit L2TP können Sie Windows Endgeräte mit Boardmittel für eine VPN Einwahl konfigurieren. Durch die RADIUS Anbindung können Sie nicht nur die Zugänge via AD steuern, sondern auch Start-Before-Logon vernünftig konfigurieren. Durch Start-Before-Logon haben Sie den Vorteil, dass Sie bereits vor der User-Anmeldung eine Verbindung zum AD herstellen können und so Netzlaufwerke, Richtlinien, … via VPN bereitgestellt werden.
Weiterlesen
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
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.
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.
Ich hatte in den letzten Wochen drei Fälle, in denen WatchGuard die Hardware Appliance im Zuge eines Support Incidents ausgetauscht hat:
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!
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.
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:
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.
