12.03.2007 | Redakteur: Stephan Augsten
ISA-Server von Microsoft sollen Firmennetze vor der denkbar feindlichsten Umgebung schützen – dem Internet. Abgesehen von einigen ungesicherten Puffer-Schwachstellen, die bereits entdeckt und umgehend gepatched wurden, sind die VPN-Firewalls relativ sicher. Allerdings gibt es auf Ebene der Netzwerk-Schnittstellen einige Gefahren. Hier finden Sie eine Liste von Regeln, die beim Konfigurieren eines ISA-Servers zu beachten sind.
Generell sollte ein ISA-Server (ISA = Internet Security and Acceleration) nie als Domänen-Controller laufen oder unter einem ungepatchten Windows-System betrieben werden. Sofern auf der Windows-Ebene keine größeren Sicherheitsfehler vorliegen, ist die Netzwerk-Schnittstelle die Achillesferse.
Ist Windows auf einem Server installiert so geht das Betriebssystem automatisch davon aus, dass die Appliance in einem sicheren Firmennetz aufgestellt wurde. Diese Annahme funktioniert für den ISA-Server einfach nicht.
Die meisten ISA-Server haben zwei Netzwerkkarten (NICs, Network Interface Cards). Eine der NICs ist mit dem Firmennetz, die andere meist direkt mit dem World Wide Web verbunden. An dieser Stelle gilt es zunächst einmal darauf zu achten, dass Windows letztere NIC nicht für eine Karte hält, die den Server mit einem sicheren Netz verbindet.
In einer Windows-2000-Serverumgebung werden mehrere Bestandteile standardmäßig an eine NIC gebunden. Normalerweise handelt es sich dabei um das TCP/IP-Protokoll, das Datei- und Drucker-Sharing des Microsoft-Netzwerks, dem Client des Microsoft-Netzwerks und möglicherweise einem QoS (Qualität of Service) Packet-Planer.
All diese Bestandteile mit Ausnahme des TCP/IP-Protokolls sind für den Einsatz im internen Netz bestimmt. Es gibt also keinen Grund, sie für eine NIC zu aktivieren, die sich direkt mit dem Internet verbindet – denn welches Unternehmen will schon Datei- und Print-Sharing über das World Wide Web ermöglichen? Für die Online-NIC empfiehlt es sich also, bis auf TCP/IP alle Netzbestandteile zu deinstallieren.
Auch eine Prüfung der TCP/IP-Konfiguration kann von großem Nutzen sein. Meist ist das Protokoll so voreingestellt, dass sich ein Gerät die IP-Adressinformation vom DHCP-Server (Dynamic Host Configuration Protocol) holt. Nur wenige Menschen nehmen sich die Zeit, die erweiterten Einstellungen zu studieren.
Beim Klick auf den Button „erweiterte Einstellungen“ in den TCP/IP-Eigenschaften der aktiven Netzwerkverbindung erscheint ein Fenster, das vier „Karteikarten“ enthält. Obwohl diese Tabulatoren möglicherweise anfangs leer zu sein scheinen, lohnt sich ein genauer Blick auf den WINS-Tabulator: Standardmäßig ist hier Netbios über TCP/IP aktiviert.
Diese Einstellung erlaubt WINS-Clients das Auflösen von Host-Namen sowie das Versenden und Empfangen von Browser Listservice Announcements (Browser-Listendienst-Ankündigungen). Sicherheitshalber sollten Benutzer, die sich mit diesem Rechner über das Internet verbinden, nichts dergleichen tun können.
Technisch ist der ISA-Server standardmäßig so eingerichtet, dass Netbios über TCP/IP geblockt wird. Allerdings liegt die NIC-Konfiguration auf einer viel niedrigeren Ebene als der ISA-Server selbst. Dadurch werden Netbios-Anfragen von außen ins Unternehmen erlaubt und erst auf Server-Ebene gefiltert. Sicherer ist es, diese Kommunikation bereits auf der NIC-Ebene zu untersagen.
Im DNS-Tabulator auf der erweiterten TCP/IP-Eigenschaften-Seite findet sich ein weiterer wichtiger Konfigurationsaspekt. Standardmäßig sind dort „Primäre und verbindungsspezifische DNS-Suffixesanhänge“ und „Übergeordnete Suffixes des primären DNS-Suffixes anhängen“ aktiviert.
Oft verwendet direkt an den Server adressierte bösartige Kommunikation einen http-Header, gefolgt von der IP-Adresse des Servers. Sobald eine http-Anfrage über das Internet hereinkommt, verbindet Windows diese automatisch mit dem Domänennamen des privaten Netzes. Eine Anfrage an einen SearchSecurity-ISA-Server in der Form HTTP://WWW würde Windows also selbständig in http://www.searchsecurity.de umwandeln.
Dies klingt zunächst harmlos, allerdings wird auf diese Weise auch gefährliche Kommunikation direkt übermittelt. Somit könnte eine unqualifizierte Anfrage an Windows gestellt werden, die das OS wiederum selbständig qualifiziert und an den ISA-Server weiterleitet. Unter solchen Umständen hätte ein Angreifer rasch Zugang zum Netzwerk, statt nur einen Blick auf die Website.
Um dieses Problem zu umgehen, sollte statt „Primäre und verbindungsspezifische DNS-Suffixes anhängen“ die Option „Diese DNS-Suffixes anhängen (in Reihenfolge)“ ausgewählt sein. Dort lässt sich ein falscher DNS-Name wie fakesecurity.de hinterlegen, so dass eine unqualifizierte Anfrage an eine nicht existierende Domäne weitergeleitet wird.
Alles in allem ist der ISA-Server von Haus aus ein ziemlich sicheres Produkt. Bevor er aber wirklich ins Netzwerk integriert und live geschaltet wird, sollte sichergestellt sein, dass niemand Windows-Schwachstellen auf der NIC-Ebene ausnutzen kann. Nur so ist das Firmennetz wirklich vor potenziellen Online-Angriffen gefeit.
Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 2000240)
