ISA 2006: Failed Connection Attempt, 13 The Data is invalid (Web Proxy)

Hi,

ein Kunde hatte heute ein Problem mit seinem ISA 2006. Ein User wollte per HTTPS von seinem Rechner aus der Zentrale auf einen Server im Branch Office zugreifen. Die beiden Standorte sind per 3rd Party Firewalls zusätzlich vor dem ISA abgesichert, welche auch durch einen VPN (AES) Tunnel mitinander verbunden sind.

Im ISA Log tauchten dann immer Fehler auf:

Failed Connection Attempt, 13 The Data is invalid (Web Proxy)

  

Lösung war dann:  Cannot access HTTPS web site if Web Proxy Filter is bound to HTTPS protocol

Detach web proxy filter from HTTPS protocol.

To do so, please follow the
steps below:

1. Go to Firewall Policy, on the right pane, click Toolbox
tab, expand Protocols.

2. Right click HTTPS protocol, click Properties,
uncheck Web Proxy Filter.

Na dann, Viel Spass beim selber Testen!
CU

Advertisements

ISA2006 TMG Migration Guide

Hi,

die TMG experten von Microsoft, Jim und Mohit, geben im Webcast ISA to TMG Migration Guidance auf Technet Edge Tipps zur Migration vom ISA Server 2004 oder 2006 zum Forefront Threat Management Gateway 2010.

image

Microsoft’s TMG experts Jim and Mohit, give us essential information about how to migrate over to Forefront Threat Management Gateway from ISA 2004 or 2006. Jim starts out by giving us various supported migration scenarios and at [13:38], Mohit steps in and walks us through typical steps for migration. At end they provide some general tips on your migration.

Der ISA to TMG Migration guide im Microsoft TechNet Portal beschreibt auch diese Szenarien.

Na dann, Viel Spass beim selber Testen!
CU

Demo Umgebung Part 7 Windows Server 2008 TS Web Access Publishing mit ISA Server 2006

Hi,

wie schon in meinen letzten 6 Artikeln meiner Demo Umgebung nun mein nächster Artikel.

Dieses mal zum Thema Windows Server 2008 Terminal Services Web Access (TS Web Access) Publishing mit ISA Server 2006, womit ich von extern per Browser über HTTPS eine RDP Verbindung auf die Server meiner bestehende Demo Umgebung auch von außer Testen kann oder per Remote Sogar nur einzelne Anwendungen starten kann.

Als erstes bereite ich den Windows Server 2008 (R2) mit der Terminal Services Rolle auf seine Aufgabe vor, d.h. die TS Rolle installieren und dafür den Role Service TS Web Access auswählen. Als Abhängige Rolle muss dazu auch der Webserver IIS mit installiert werden.

Zunächst erstelle ich mir ein SSL-Zertifikat für den externen DNS Namen (ts.demolocal.de) oder beantrage es von einer 3rd Party Zertifizierungsstelle (CA) (z.B. Thawte oder Verisign). Da es sich bei mir nur um Demo handelt erstelle ich ein internes Webserver Zertifikat, was meine interne Demo RootCA ausstellt und signiert. Dieses SSL-Webserver muss man dann in den internen Zertifikatsspeicher des ISA Server importieren und zwar in “Eigenen Zertifikate” des Computers (!), nicht des Benutzers. Natürlich sollte im Zertifikatsstore “Vertrauenswürdige Zertifizierungsstellen” das RootCA Zertifikat des internen CA liegen.

Nun folgt als nächstes die Erstellung des TS Web Access HTTPS Listeners. Man vergibt einen Namen z.B. TSWA HTTPS Listener und wählt “Require SSL secured connections with clients” aus. Auf der nächsten Seite wählt man die externe IP aus, auf die der ISA Server HTTPS anfragen zu TSWA entgegen nehmen soll und weißt dem Listener, als nächstes das eben erstellte SSL-Webserver Zertifikat zu. Als Letztes wählt man noch die als Authentication Settings “No Authentification” aus. Somit erhält man beim Aufruf der TSWA Seite eine Anmeldebox zur Eingabe von Usernamen und Passwort, natürlich alles über SSL (HTTPS) abgesichert. Single Sign On (SSO) kann man nicht aktiviern, weil man auf dem Listener ja keine Authentifizierung eingeschaltet hat.

Jetzt erstelle ich erst die eigentliche TSWA Publishing Rule ebenso wie im Listener wähle ich auch hier “Use SSL to connect to published Web Server” aus und definiere auf der nächsten Seite meinen internen Terminal Server mit FQDN, also ts1.demo.local. Auf der nächsten Seite definiere ich den externen DNS Namen unter dem ich TSWA erreichen möchte, welche natürlich derselbe wie im zuvor ausgestellten SSL-Zertifikat (ts.demolocal.de) sein muss. Nun folgt die Auswahl des zuvor angelegten TSWA HTTPS Listeners, welche auch gleicht prüft, ob der DNS Name mit dem SSL-Zertifkat übereinstimmt. Nun folgt noch die Auwahl der Authentifizierungsmethode, “No Authentication Delegation, but Client can authenticate directly”. Wer jetzt Angst hat dass dann ja die Kennwort in Klartext übermittelt werden, brauch an dieser Stelle keine Angst haben, denn die Verbindung ist ja per SSL (HTTPS) verschlüsselt. Als letztes sucht man noch die Gruppe der User aus, die sich per ISA anmelden und TSWA nutzen darf, in der Regel sind das nur "Authentifizierte User” oder eine spezielle TSWA-Gruppe.

Nun kann man per Browser in TSWA auf seine Terminal Server oder Terminal Services Applikationen zugreifen!

Hier noch ein paar Impressionen zu Windows Server 2008 TS Web Access Publishing mit ISA Server 2006:

Na dann, Viel Spass beim selber Testen!
CU

Demo Umgebung Part 6 Exchange 2007 OWA Publishing mit ISA Server 2006

Hi,

wie schon in meinen letzten 5 Artikeln meiner Demo Umgebung nun mein nächster Artikel.

Dieses mal zum Thema Exchange 2007 Outlook Web Access (OWA) Publishing mit ISA Server 2006, womit ich von extern per Browser über HTTPS meine bestehende Demo Umgebung auch von außer Testen kann für Mail Verkehr.

Als erstes bereite ich den Exchange 2007 mit der CAS-Server Rolle auf seine Aufgabe vor, OWA Verbindungen anzunehmen. Dazu wählt man in der Exchange Management Console die “Server Configuration” und dort “Client Access”. Gleich auf der ersten Registerkarte steht OWA, was man mit der rechten Maustaste und “Properties” konfiguriert. So muss man eine URL eingegeben und die Authentifizierungsmethode z.B. “Form-based Authentification” auswählen. Weiterhin kann man noch den Zugriff auf OWA Elemente oder den Zugriff von öffentlichen/privaten Computern einschränken bzw. auch den Zugriff auf Remote File Sharing Server zulassen bzw. verweigern.

Zunächst erstelle ich mir ein SSL-Zertifikat für den externen DNS Name oder beantrage es von einer 3rd Party Zertifizierungsstelle (CA) (z.B. Thawte oder Verisign). Da es sich bei mir nur um Demo handelt erstelle ich ein internes Webserver Zertifikat, was meine interne Demo RootCA ausstellt und signiert. Dieses SSL-Webserver muss man dann in den internen Zertifikatsspeicher des ISA Server importieren und zwar in “Eigenen Zertifikate” des Computers (!), nicht des Benutzers. Natürlich sollte im Zertifikatsstore “Vertrauenswürdige Zertifizierungsstellen” das RootCA Zertifikat des internen CA liegen.

Nun folgt als nächstes die Erstellung des OWA HTTPS Listeners. Man vergibt einen Namen z.B. OWA HTTPS Listener und wählt “Require SSL secured connections with clients” aus. Auf der nächsten Seite wählt man die externe IP aus, auf die der ISA Server HTTPS anfragen zu OWA entgegen nehmen soll und weißt dem Listener, als nächstes das eben erstellte SSL-Webserver Zertifikat zu. Als Letztes wählt man noch die als Authentication Settings “Form-based Authentication” mit Active Directory aus. Somit erhält man beim Aufruf der OWA Seite ein Exchange 2007 Anmeldeformular zur Eingabe von Usernamen und Passwort, natürlich alles über SSL (HTTPS) abgesichert. Single Sign On (SSO) aktiviere ich nicht, da ich es in meinem Szenario nicht benötige.

Jetzt erstelle ich erst die eigentliche OWA Publishing Rule und wähle meine Exchange Server Version 2007 und “Publish single Web site” aus. Ebenso wie im Listener wähle ich auch hier “Use SSL to connect to published Web Server” aus und definiere auf der nächsten Seite meinen internen Exchange Server mit FQDN, also Ex07.demo.local. Auf der nächsten Seite definiere ich den externen DNS Namen unter dem ich OWA erreichen möchte, welche natürlich derselbe wie im zuvor ausgestellten SSL-Zertifikat sein muss. Nun folgt die Auswahl des zuvor angelegten OWA HTTPS Listeners, welche auch gleicht prüft, ob der DNS Name mit dem SSL-Zertifkat übereinstimmt. Nun folgt noch die Auwahl der Authentication Delegation, “Basic (HTTP)”. Wer jetzt Angst hat dass dann ja die Kennwort in Klartext übermittelt werden, brauch an dieser Stelle keine Angst haben, denn die Verbindung ist ja per SSL (HTTPS) verschlüsselt. Als letztes sucht man noch die Gruppe der User aus, die sich per ISA anmelden und OWA nutzen darf, in der Regel sind das nur "Authentifizierte User” oder eine spezielle OWA-Gruppe.

Nun kann man per Browser in OWA seine E-Mails von jedem Rechner der Welt auch einsehen und verschicken!

Hier noch ein paar Impressionen des ISA 2006 OWA Publishing:

Na dann, Viel Spass beim selber Testen!
CU

Demo Umgebung Part 5 ISA 2006 DNS Publishing

Hi,

wie schon in meinen letzten 4 Artikeln meiner Demo Umgebung nun mein nächster Artikel.

Dieses mal zum Thema DNS Server Publishing mit ISA Server 2006, womit ich einen von extern erreichbaren DNS Server habe mit dem ich meine bestehende Demo Umgebung auch von außer Testen kann, z.B. für OWA usw.

Als erstes habe ich dazu eine neue Primäre DNS Zone auf meinem internen DNS Server angelegt (man sollte natürlich den extern erreichbaren DNS in eine DMZ stellen!). Die vorhandene intern Zone hört auf “demo.local”. Die neue primäre Zone, welche von mir angelegt wurde heißt “demolocal.de”, ist NICHT Active Directory integriert und erlaubt auch keine Dynamischen Updates. Mit den gleichen Einstellungen habe ich eine neue Primäre Reverse Lookup Zone eingerichet und einem IP-Subnetz ausgestattet, was extern erreichbar ist.

Als nächstes habe ich gleich noch Host Records für mail, owa und ts angelegt.

Nun geht es auf den ISA 2006 und zur Erstellung einer “Non-Web Server” Publishing Rule. Man vergibt einen Namen, bei mir “DNS Publishing external” und geht weiter zur Eingabe der IP des zu veröffentlichten DNS Servers an sowie das Protokoll “DNS-Server” (TCP Port 53 inbound und UDP Port 53 Recieve Send) und wählt den die externe IP des aus auf dem der ISA Server auf DNS Anfragen lauschen soll.

Dann kann man auch schon von extern die Namen auflösen, wie z.B. owa.demolocal.de oder mail.demolocal.de usw.

Hier noch ein paar Impressionen des DNS Server Publishing mit ISA Server 2006:

Na dann Viel Spass beim selber Testen!
CU

ISA 2006 Exchange 2007 Publishing per ASDL (fester IP)

Hi,

ein Kunde hatte ein Problem mit seinem ISA 2006 und den Exchange 2007 Publishing Rules für OWA, Outlook Anywhere (RPC over HTTPS) und Active Sync. Der ISA ist per ASDL, aber mit fester IP ans Internet angebunden.

Er hatte spezielle das Problem, dass man sich nach einigen Stunden per RDP am ISA anmelden oder den ISA durchstarten musste.

Nach einigem Troubleshooting haben wir heraus gefunden, dass der HTTPS Listener über den alle 3 Exchange 2007 Publishing Rules laufen, nach einigen Stunden den Dienst einstellt. Das liegt an der Automatischen Trennung und Einwahl (alle 24 Stunden).

Als Workaround kann man die ISA Dienste (alle 24 Stunden) neustarten.

Als Problemhebung hilft nur eine “richtige” feste IP Adresse, also ein kleines Netzwrk mit z.B. 5 Adressen oder man muss einen DSL Router die ADSL Einwahl erledigen lassen und den ISA als Back-Firewall einsetzen. Dann muss der ADSL Router aber auch ggf. ALLE Ports durchlassen (In- wie Outbound), was bei VPN Verbindungen, wie IPsec oder L2TP-IPsec zum Problem werden könnte.

Na dann, Viel Spass beim selber Testen!
CU

Microsoft Patchday August 2009

Hi,

heute war wieder Microsoft Patchday! 9 Updates schließen damit die 19 Sicherheitslücken. Betroffen sind folgende Applikationen:

  • Microsoft Office XP
  • Microsoft Office 2003
  • Microsoft Office 2000 Web Components
  • Microsoft Office Small Business Accounting 2006
  • Microsoft Visual Studio .NET 2003
  • Microsoft Internet Security and Acceleration Server 2004 and 2006
  • Microsoft BizTalk Server 2002
  • Client for Mac
  • Microsoft .NET Framework

Betriebssysteme sind diese betroffen:

  • Windows 2000 Service Pack 4
  • Windows XP Service Pack 2 and Service Pack 3 *
  • Windows Server 2003 (32bit, 64bit and Itanium-based systems)
  • Windows Server 2008 (32bit, 64bit and Itanium-based systems)
  • Windows Vista *
  • Windows Vista Service Pack 1 and Service Pack 2 *

Microsoft Security Bulletin Summary für August 2009

KB957638: Sicherheitsanfälligkeiten in Microsoft Office Web Components können Remotecodeausführung ermöglichen
Dieses Sicherheitsupdate behebt mehrere vertraulich gemeldete Sicherheitsanfälligkeiten in Microsoft Office Web Components, die Remotecodeausführung ermöglichen können, wenn ein Benutzer eine speziell gestaltete Webseite anzeigt. Ein Angreifer, der diese Sicherheitsanfälligkeiten erfolgreich ausnutzt, kann die gleichen Benutzerrechte wie der lokale Benutzer erlangen. Für Endbenutzer, deren Konten mit weniger Benutzerrechten konfiguriert sind, kann dies geringere Auswirkungen haben als für Benutzer, die mit administrativen Benutzerrechten arbeiten.

KB970927: Sicherheitsanfälligkeiten in Remotedesktopverbindung können Remotecodeausführung ermöglichen
Dieses Sicherheitsupdate behebt zwei vertraulich gemeldete Sicherheitsanfälligkeiten in Microsoft-Remotedesktopverbindung. Die Sicherheitsanfälligkeiten können Remotecodeausführung ermöglichen, wenn ein Angreifer einen Benutzer von Terminaldiensten erfolgreich dazu verleitet, eine Verbindung zu einem schädlichen RDP-Server herzustellen, oder wenn ein Benutzer eine speziell gestaltete Website besucht, die diese Sicherheitsanfälligkeit ausnutzt. Für Endbenutzer, deren Konten mit weniger Benutzerrechten konfiguriert sind, kann dies geringere Auswirkungen haben als für Benutzer, die mit administrativen Benutzerrechten arbeiten.

KB969883: Sicherheitsanfälligkeiten in WINS können Remotecodeausführung ermöglichen
Dieses Sicherheitsupdate behebt zwei vertraulich gemeldete Sicherheitsanfälligkeiten im Windows Internet Name Service (WINS). Jede der beiden Sicherheitsanfälligkeiten kann eine Remotecodeausführung ermöglichen, wenn ein Benutzer auf einem betroffenen System, das den WINS-Dienst ausführt, ein speziell gestaltetes WINS-Replikationspaket empfängt. Standardmäßig ist WINS bei keiner Version der betroffenen Betriebssysteme installiert. Nur Benutzer, die diese Komponente manuell installieren, sind von diesem Problem betroffen.

KB971557: Sicherheitsanfälligkeiten bei der Verarbeitung von Windows Media-Dateien können Remotecodeausführung ermöglichen
Dieses Sicherheitsupdate behebt zwei vertraulich gemeldete Sicherheitsanfälligkeiten in der Verarbeitung von Windows Media-Dateien. Jede dieser Sicherheitsanfälligkeiten kann Remotecodeausführung ermöglichen, wenn ein Benutzer eine speziell gestaltete AVI-Datei öffnet. Wenn ein Benutzer mit administrativen Benutzerrechten angemeldet ist, kann ein Angreifer, der diese Sicherheitsanfälligkeit erfolgreich ausnutzt, vollständige Kontrolle über ein betroffenes System erlangen. Ein Angreifer kann dann Programme installieren, Daten anzeigen, ändern oder löschen oder neue Konten mit sämtlichen Benutzerrechten erstellen. Für Endbenutzer, deren Konten mit weniger Benutzerrechten konfiguriert sind, kann dies geringere Auswirkungen haben als für Benutzer, die mit administrativen Benutzerrechten arbeiten.

KB973908: Sicherheitsanfälligkeiten in der Microsoft Active Template Library (ATL) können Remotecodeausführung ermöglichen
Dieses Sicherheitsupdate behebt mehrere vertraulich gemeldete Sicherheitsanfälligkeiten in der Microsoft Active Template Library (ATL). Die Sicherheitsanfälligkeiten können eine Remotecodeausführung ermöglichen, wenn ein Benutzer speziell gestaltete Komponenten oder Steuerelemente lädt, die auf einer schädlichen Website gehostet werden. Für Endbenutzer, deren Konten mit weniger Benutzerrechten konfiguriert sind, kann dies geringere Auswirkungen haben als für Benutzer, die mit administrativen Benutzerrechten arbeiten.

KB971657: Sicherheitsanfälligkeit im Arbeitsstationsdienst kann Erhöhung von Berechtigungen ermöglichen
Dieses Sicherheitsupdate behebt eine vertraulich gemeldete Sicherheitsanfälligkeit im Windows-Arbeitsstationsdienst. Die Sicherheitsanfälligkeit kann eine Erhöhung von Berechtigungen ermöglichen, wenn ein Angreifer eine speziell gestaltete RPC-Nachricht erstellt und an ein betroffenes System sendet. Ein Angreifer, der diese Sicherheitsanfälligkeit erfolgreich ausnutzt, kann beliebigen Code ausführen und vollständige Kontrolle über das betroffene System erlangen. Ein Angreifer kann dann Programme installieren, Daten anzeigen, ändern oder löschen oder neue Konten mit sämtlichen Benutzerrechten erstellen. Ein Angreifer muss über gültige Anmeldeinformationen für ein betroffenes System verfügen, um diese Sicherheitsanfälligkeit ausnutzen zu können. Die Sicherheitsanfälligkeit kann nicht von anonymen Benutzern ausgenutzt werden.

KB971032: Sicherheitsanfälligkeit beim Message Queuing kann Erhöhung von Berechtigungen ermöglichen
Dieses Sicherheitsupdate behebt eine vertraulich gemeldete Sicherheitsanfälligkeit im Windows Message Queuing-Dienst (MSMQ). Die Sicherheitsanfälligkeit kann eine Erhöhung von Berechtigungen ermöglichen, wenn ein Benutzer eine speziell gestaltete Anforderung an einen betroffenen MSMQ-Dienst erhalten hat. Standardmäßig wird die Komponente Message Queuing nicht unter betroffenen Betriebssystemversionen installiert und kann nur von einem Benutzer mit Administratorberechtigungen aktiviert werden. Nur Kunden, die die Message Queuing-Komponente manuell installieren, können für dieses Problem anfällig sein.

KB970957: Sicherheitsanfälligkeit in ASP.NET in Microsoft Windows kann Denial-of-Service ermöglichen
Dieses Sicherheitsupdate behebt eine vertraulich gemeldete Sicherheitsanfälligkeit bezüglich Denial-of-Service in der Microsoft .NET Framework-Komponente in Microsoft Windows. Diese Sicherheitsanfälligkeit kann nur ausgenutzt werden, wenn Internet Information Services (IIS) 7.0 installiert und ASP.NET so konfiguriert ist, dass auf den betroffenen Versionen von Microsoft Windows der integrierte Modus verwendet wird. Ein Angreifer könnte speziell gestaltete anonyme HTTP-Anforderungen erstellen, die dazu führen können, dass der betroffene Webserver erst wieder reagieren kann, wenn der zugeordnete Anwendungspool neu gestartet wird. Benutzer, die IIS-7.0-Anwendungspools im klassischen Modus ausführen, sind von dieser Sicherheitsanfälligkeit nicht betroffen.

KB960859: Sicherheitsanfälligkeit in Telnet kann Remotecodeausführung ermöglichen
Dieses Sicherheitsupdate behebt eine öffentlich gemeldete Sicherheitsanfälligkeit im Microsoft Telnet-Dienst. Die Sicherheitsanfälligkeit kann einem Angreifer ermöglichen, Anmeldeinformationen zu erhalten und sich damit bei betroffenen Systemen anzumelden. Der Angreifer erlangt dann auf einem System Benutzerrechte, die mit denen des angemeldeten Benutzers identisch sind. Dieses Szenario kann letzten Endes zu Remotecodeausführung auf betroffenen Systemen führen. Ein Angreifer, der diese Sicherheitsanfälligkeit erfolgreich ausnutzt, kann Programme installieren, Daten anzeigen, ändern oder löschen oder neue Konten mit sämtlichen Benutzerrechten erstellen. Für Endbenutzer, deren Konten mit weniger Benutzerrechten konfiguriert sind, kann dies geringere Auswirkungen haben als für Benutzer, die mit administrativen Benutzerrechten arbeiten.

Natürlich wurden auch die Junk-E-Mail-Filter von Outlook und Windows Mail und das Tool zum Entfernen bösartiger Software aktualisiert.

Ebenfalls wird über Windows Update das Security Update für Windows 7 Release Candidate (KB973540) verteilt!

Na dann, Viel Spass beim selber Testen!
CU