Galileo Computing < openbook > Galileo Computing - Professionelle Bücher. Auch für Einsteiger.
Professionelle Bücher. Auch für Einsteiger.

Inhaltsverzeichnis
Geleitwort zu diesem Buch
Inhalt des Buchs
1 Warum eine neue Server-Version?
2 Editionen und Lizenzen
3 Hardware und Dimensionierung
4 Protokolle
5 Was überhaupt ist .NET?
6 Installation
7 Core-Installationsoption
8 Active Directory-Domänendienste
9 Netzwerkdienste im AD-Umfeld
10 Active Directory Lightweight Directory Services (AD LDS)
11 Active Directory-Verbunddienste (Federation Services)
12 Active Directory-Zertifikatdienste
13 Active Directory-Rechteverwaltungsdienste (AD RMS)
14 »Innere Sicherheit«
15 Dateisystem und Dateidienste
16 Drucken
17 Webserver (IIS)
18 SharePoint (Windows SharePoint Services, WSS)
19 Remotedesktopdienste (Terminaldienste)
20 Hochverfügbarkeit
21 Datensicherung
22 Servervirtualisierung mit Hyper-V
23 Windows PowerShell
24 Windows 7 und Windows Server 2008 R2
Stichwort

Download:
- ZIP, ca. 104 MB
Buch bestellen
Ihre Meinung?

Spacer
<< zurück
Windows Server 2008 R2 von Ulrich B. Boddenberg
Das umfassende Handbuch
Buch: Windows Server 2008 R2

Windows Server 2008 R2
geb., 1.410 S., 59,90 Euro
Galileo Computing
ISBN 978-3-8362-1528-2
Pfeil 17 Webserver (IIS)
Pfeil 17.1 Begriffsdefinitionen
Pfeil 17.1.1 Webapplikation vs. Webservice
Pfeil 17.1.2 Website vs. Webseite
Pfeil 17.2 ASP.NET
Pfeil 17.2.1 Die Entwicklungsumgebung
Pfeil 17.2.2 Clientseitig: JavaScript
Pfeil 17.2.3 Die web.config-Datei
Pfeil 17.2.4 Kompilierung und Vorkompilierung
Pfeil 17.2.5 Sicherheit und ASP.NET
Pfeil 17.3 Installation
Pfeil 17.4 Kurzer Überblick über die Architektur des Webservers
Pfeil 17.4.1 Architektur
Pfeil 17.4.2 Anforderungsverarbeitung
Pfeil 17.4.3 Anforderungsverarbeitung im Anwendungspool
Pfeil 17.4.4 Die »Modulbauweise«
Pfeil 17.5 Webserver, Websites, Anwendungen, virtuelle Verzeichnisse und Anwendungspools
Pfeil 17.5.1 Die Zusammenhänge
Pfeil 17.5.2 Webserver
Pfeil 17.5.3 Anwendungspool
Pfeil 17.5.4 Website
Pfeil 17.5.5 Anwendung
Pfeil 17.5.6 Virtuelles Verzeichnis
Pfeil 17.6 Authentifizierung
Pfeil 17.6.1 Anonyme Authentifizierung
Pfeil 17.6.2 Standardauthentifizierung
Pfeil 17.6.3 Digestauthentifizierung
Pfeil 17.6.4 Windows-Authentifizierung
Pfeil 17.6.5 Authentifizierungsdelegierung
Pfeil 17.6.6 Webanwendungen und Kerberos
Pfeil 17.6.7 Delegierung, eingeschränke Delegierung und Protokollübergang
Pfeil 17.6.8 Formularauthentifizierung
Pfeil 17.7 Autorisierung
Pfeil 17.7.1 NTFS-Berechtigungen
Pfeil 17.7.2 URL-Autorisierung
Pfeil 17.8 Sonstiges zum Thema »Sicherheit«
Pfeil 17.8.1 SSL-Verschlüsselung
Pfeil 17.8.2 .NET-Vertrauensebenen
Pfeil 17.8.3 IP- und Domäneneinschränkungen
Pfeil 17.9 Sitzungszustand
Pfeil 17.10 Load Balancing und Redundanz
Pfeil 17.10.1 Verwendung von Microsoft NLB
Pfeil 17.10.2 Remoteanforderungen
Pfeil 17.10.3 Freigegebene Konfiguration
Pfeil 17.10.4 Sitzungsstatus
Pfeil 17.10.5 Datenbankserver
Pfeil 17.11 Administration
Pfeil 17.11.1 Remote-Administration
Pfeil 17.11.2 Remote-Administration für Nicht-Server-Administratoren und IIS-Benutzer
Pfeil 17.11.3 Delegierung von Features
Pfeil 17.11.4 Protokollierung
Pfeil 17.12 Der Best Practice Analyzer (BPA)
Pfeil 17.13 IIS-Schlussbemerkung


Galileo Computing - Zum Seitenanfang

17.8 Sonstiges zum Thema »Sicherheit« Zur nächsten ÜberschriftZur vorigen Überschrift

In den folgenden Abschnitten sind einige weiterführende Aspekte zum Thema »Sicherheit« beschrieben.


Galileo Computing - Zum Seitenanfang

17.8.1 SSL-Verschlüsselung Zur nächsten ÜberschriftZur vorigen Überschrift

Eine professionelle Webanwendung, die mit Unternehmensdaten umgeht, muss diese verschlüsselt übertragen. Das gilt selbstverständlich für Daten, die durch das Internet transportiert werden, aber auch das LAN sollten zumindest sensible Daten nicht unverschlüsselt durchqueren. Denken Sie daran, dass die Mehrzahl der Angriffe »von innen« kommt!

Der HTTP-Datenverkehr zwischen Webserver und Client kann sehr einfach mittels SSL verschlüsselt werden. Es entsteht dann eine HTTPS-Verbindung. Die genaue Funktionsweise einer HTTPS-Verbindung ist in diesem Buch im Zusammenhang mit den Active Directory-Zertifikatsdiensten beschrieben. Lesen Sie also im Zweifelsfall dort nochmals nach.

Zur Realisierung der SSL-Verschlüsselung ist ein Zertifikat auf dem Webserver erforderlich. Dieses bringt übrigens einen weiteren Vorteil: Der Webserver kann zuverlässig authentifiziert werden. Der Client weiß also, dass er wirklich mit dem gewünschten Server kommuniziert und nicht mit einem, der sich nur als das »Original« ausgibt, in Wahrheit aber eine Fälschung ist.

Wer bereits mit IIS6 (oder früheren Versionen) eine SSL-Verschlüsselung konfiguriert hat, wird sich ein wenig umstellen müssen, denn bei den älteren Versionen wurde die Konfiguration der Zertifikate ausschließlich in den Dialogen der Website vorgenommen. Bei IIS7 ist das Feature Zertifikate auf der Ebene des Servers angesiedelt. Bei Websiten und Webanwendungen ist zwar jeweils eine Konfigurationsoption SSL-Verschlüsselung enthalten, dort können aber keine Zertifikate importiert werden.

Ein Zertifikat beschaffen und auf dem Server installieren

Der erste Schritt ist also, das Zertifikat auf den Server zu bekommen. Hier sind mehrere Wege möglich:

  • Es besteht die Möglichkeit, ein als Datei vorhandenes Zertifikat einzulesen.
  • Es kann eine Anforderung an eine Offline-Zertifizierungsstelle erstellt werden.
  • Es kann eine Anforderung an eine im Active Directory veröffentlichte Online-Zertifizierungsstelle gestellt werden (siehe auch die Ausführungen über Active Directory-Zertifikatdienste).

In den Aktionen in der Serverzertifikate-Konfiguration finden Sie die Funktionen zum Erlangen des Zertifikats (Abbildung 17.101):

  • Importieren dient zum Einlesen eines Zertifikats, das als Datei vorhanden ist (*.pfx).
  • Zertifikatanforderung erstellen wird verwendet, wenn Sie von einer Offline-Zertifizierungsstelle ein Zertifikat anfordern (z. B. von VeriSign). Die Funktion Zertifikatanforderung abschliessen gehört unmittelbar dazu.
  • Domänenzertifikat erstellen dient zum Anfordern eines Zertifikats von einer Online-Zertifizierungsstelle, die im Active Directory registriert ist.
  • Selbstsigniertes Zertifikat erstellen generiert ein Zertifikat, das aber in keiner PKI-Hierarchie eingebettet ist.

Abbildung 17.101 Sofern das Zertifikat von einer im AD vorhandenen Zertifizierungsstelle erstellt werden soll, lassen Sie ein »Domänenzertifikat erstellen«.

Am einfachsten ist es, wenn Sie das Zertifikat bei einer Zertifizierungsstelle anfordern können, die in das Active Directory integriert ist. In diesem Fall wählen Sie die Erstellung eines Domänenzertifikats und können in dem in Abbildung 17.102 links gezeigten Dialog die Daten für die Erstellung des Zertifikats angeben. Hierbei sind zwei Aspekte zu beachten:

  • Unter Gemeinsamer Name muss exakt der Name eingetragen werden, der von den Clients zum Zugriff auf diesen Server verwendet wird. Wenn die Benutzer den FQDN (hier: ubinfWebNlb1.ubinf.intra) eingeben, muss dieser hier eingetragen werden. Rufen die Benutzer die Webapplikation unter Eingabe des Computernamens (ubinfWebNlb1) auf, wird es eine Zertifikatswarnung geben. Beachten Sie, dass Applikationen, die beispielsweise auf einen Webservice zugreifen, die Verarbeitung abbrechen, wenn das Zertifikat nicht korrekt ist, also etwa der Name nicht passt.
  • Im Textfeld Land/Region müssen Sie die offizielle Abkürzung für Ihr Land eintragen, beispielsweise DE für Deutschland. Ansonsten wird die Zertifizierungsstelle die Zertifikatanforderung ablehnen.

Im nächsten Dialog des Assistenten wählen Sie die Zertifizierungsstelle, die Sie verwenden wollen (Abbildung 17.102 rechts). Diese Informationen werden aus dem Active Directory gelesen (siehe auch die Beschreibung des AD-Zertifikatsdienstes). Der Anzeigename ist beliebig. Sie sollten bei der Auswahl bedenken, dass vielleicht mehrere Zertifikate auf Ihrem Server vorhanden sein könnten. Das ist beispielsweise dann der Fall, wenn mehrere Websites mit unterschiedlichen Hostheadern betrieben werden. Sinnvolle Namen erlauben später eine einfache Zuordnung.

Abbildung 17.102 Anfordern eines Domänenzertifikats

Bei der Anforderung eines Domänenzertifikats wird dieses, sofern die Zertifizierungsstelle für automatische Ausstellung konfiguriert ist, wenige Sekunden später installiert sein.

Falls Sie bei einer »fremden« Zertifizierungsstelle, also beispielsweise bei VeriSign, Thawte & Co., ein Zertifikat beziehen möchten, erstellen Sie zunächst eine Zertifikatanforderung. Wenn Sie das angeforderte Zertifikat erhalten, wählen Sie die Funktion Zertifikatanforderung abschliessen.

Wie auch immer das Zertifikat zu Ihnen bzw. Ihrem IIS gekommen sein mag – am Ende muss es in der Liste der Serverzertifikate angezeigt werden (Abbildung 17.103).

Abbildung 17.103 Das neue Zertifikat erscheint in der Liste der Serverzertifikate.

SSL-Verbindungen für die Website bzw. Webanwendung aktivieren

Im nächsten Schritt geht es nun darum, die einzelnen Websites für die SSL-Verschlüsselung zu aktivieren. Das Symbol SSL-Einstellungen sieht zunächst gar nicht so falsch aus, der dahinterliegende Dialog bietet in der Tat die gewünschten Einstellmöglichkeiten – ist aber leider komplett deaktiviert. Es findet sich der Hinweis, dass die Site noch nicht über eine sichere Bindung verfügt und demzufolge keine SSL-Verbindungen akzeptieren kann (Abbildung 17.104).

Abbildung 17.104 Ein erster Blick auf die SSL-Einstellungen ist eher ernüchternd. Zunächst müssen die Bindungen für SSL-Verbindungen erstellt werden.

Die Konfiguration der Bindungen findet sich beispielsweise im Kontextmenü des Eintrags der Website (Bindungen bearbeiten). Hier wird letztendlich festgelegt, auf welche Kombinationen aus IP-Adresse, Port und Hostheader die Website nebst den darunterliegenden Anwendungen reagieren soll.

Fügen Sie also (wie in Abbildung 17.105 gezeigt) eine Sitebindung hinzu. Bei der Konfiguration einer HTTPS-Verbindung kann zwar kein Eintrag in der Hostname-Textbox (Hostheader) erfolgen, allerdings wird dieser aus dem Namen ermittelt, für den das Zertifikat ausgestellt ist.

Abbildung 17.105 Das Erstellen einer neuen Bindung unter Nutzung des SSL-Zertifikats

Wenn eine HTTPS-Bindung zu der Website hinzugefügt ist, können auch die SSL-Einstellungen konfiguriert werden. Die dortigen Einstellmöglichkeiten dürften selbsterklärend sein (Abbildung 17.106).

Abbildung 17.106 Nachdem die HTTPS-Bindung vorhanden ist, kann hier beispielsweise konfiguriert werden, dass eine SSL-Verbindung erforderlich ist.

Falls Sie SSL erforderlich machen (siehe Abbildung 17.106) und ein Anwender dann die Website über eine Nicht-SSL-Verbindung aufruft, erscheint eine 403-Fehlermeldung (Abbildung 17.107). Die Meldung, nämlich Zugriff verweigert, ist letztendlich natürlich richtig, nur erfährt der Anwender leider nicht den tatsächlichen Grund, nämlich dass er vielleicht schon berechtigt wäre, nur die Seite über einen sicheren Kanal anzeigen müsste.

Abbildung 17.107 Versucht man ohne SSL auf die Webanwendung zuzugreifen, gibt es eine »403«.


Galileo Computing - Zum Seitenanfang

17.8.2 .NET-Vertrauensebenen Zur nächsten ÜberschriftZur vorigen Überschrift

In einer »klassischen« Umgebung (also ohne .NET Framework) sind die Berechtigungen des Benutzerkontos die einzige »Kontrollinstanz« in Sachen Sicherheit. Mit anderen Worten: Code wird ausgeführt, wenn er in einem Benutzerkontext läuft, der hinreichende Berechtigungen hat. Vereinfacht gesagt: Jeder Code, den ein Benutzer startet, wird – ausreichende Berechtigung vorausgesetzt – ausgeführt. Grundsätzlich ist das auf dem Webserver nicht anders: Wenn Code in der Webapplikation gestartet wird, wird er mit den Rechten der Identität des Anwendungspools ausgeführt, in dem die Webapplikation läuft. Um größeres Übel zu verhindern, wird (hoffentlich) der Anwendungspool unter einer Identität mit sehr wenigen Rechten (am besten NetworkService) laufen, aber trotzdem gibt es auch dann noch Verbesserungsbedarf.

Es ist eigentlich nicht einzusehen, warum man die Möglichkeiten, die Code hat, nicht stärker einschränken kann, sondern nur die Rechte der Identität, unter der er ausgeführt wird, als einziges Kriterium herangezogen werden. Wenn eine Webapplikation keinen Zugriff auf das Filesystem, eine SQL-Datenbank oder den DNS-Server haben muss, wäre es doch gut, diese Rechte von vornherein nicht zur Verfügung zu stellen. Möchte der Code auf diese Ressourcen dann doch zugreifen (z. B. weil der Code korrumpiert wurde, der Programmierer ein Hintertürchen eingebaut hat oder dergleichen mehr), sollte dies unterbunden werden.

Die .NET-Laufzeitumgebung stellt mit dem Konstrukt der Code Access Security (CASpol) genau diese Möglichkeiten zur Verfügung.

Wie Sie in Abbildung 17.108 sehen, läuft eine .NET-Applikation nicht direkt auf dem Betriebssystem, sondern in der .NET-Laufzeitumgebung (CLR, Common Language Runtime). Die Laufzeitumgebung ist in der Lage, gemäß den gewählten Einstellungen Zugriffe auf bestimmte Komponenten (z. B. Dateisystem, SQL Server etc.) zu erlauben oder nicht. Die Darstellung ist natürlich sehr stark vereinfacht, sollte aber für ein erstes Verständnis genügen.

Abbildung 17.108 Managed Code, wie der von ASP.NET-Anwendungen, greift nicht direkt auf das Betriebssystem zu, sondern wird von der Laufzeitumgebung des .NET Frameworks »gemanagt« – und kontrolliert.

Bei der Konfiguration einer Webapplikation kann die .NET-Vertrauensebene konfiguriert werden, Sie können also festlegen, welche Einschränkungen durch die Code Access Security für die jeweilige Webapplikation gelten sollen. In Abbildung 17.109 ist die Konfiguration der .NET-Vertrauensebenen zu sehen. Sie stellen die gewünschte Vertrauensebene für die Webapplikation ein, übernehmen die Änderungen – fertig!

Standardmäßig ist die Vertrauensebene Full gewählt. Wie unschwer zu erraten ist, gibt es bei dieser Stufe keinerlei Einschränkungen. Hinter der Bezeichnung Full befindet sich der Vermerkt (internal). Dies bedeutet, dass diese Vertrauensebene nicht auf einer Richtliniendatei basiert, sondern vom IIS eben »intern« umgesetzt wird. Keine Einschränkungen vorzunehmen bedarf verständlicherweise auch keiner großartigen Feinkonfiguration. Ob es so nun günstig ist, in der Standardeinstellung keine Einschränkungen vorzunehmen, ist sicherlich zu diskutieren. Es gibt allerdings zwei Gründe, die Microsoft zu diesem Schritt bewogen haben dürften:

  • Der Standard-Anwendungspool läuft unter der Identität NetworkService mit sehr geringen Berechtigungen.
  • Die Konfiguration der Code Access Security jenseits der in der Abbildung gezeigten Einstellmöglichkeit ist nicht ganz trivial. Würde zunächst eine genaue Konfiguration der Codezugriffsrechte erforderlich sein, würden viele Administratoren vermutlich verzweifeln. Für eine ganz detaillierte Anpassung der Code-Access-Rechte müssen XML-Dateien angepasst werden – das ist machbar, aber eben ohne grafische Oberfläche.

Abbildung 17.109 Diese fünf Vertrauensebenen sind standardmäßig vorhanden.

Die vorgefertigten Policy-Dateien, die Sie im Internetinformationsdienste-Manager auswählen können, gehören zum .NET Framework und finden sich in einer Standardinstallation im Verzeichnis c:\windows\Microsoft.NET\Framework\v2.0.50727\config, das in Abbildung 17.110 gezeigt ist. Neben den Konfigurationsdateien, die Sie im Dialog .NET-Vertrauensebenen auswählen können, befindet sich in diesem Verzeichnis eine Datei namens web.config, auf die ich ein wenig später eingehen werde.

Abbildung 17.110 In diesem Verzeichnis liegen die ».config«-Dateien, in denen die Sicherheitsrichtlinien definiert sind.

Eine Beschreibung, welche Rechte einer Webapplikation durch die jeweilige Sicherheitskonfiguration gewährt werden, finden Sie in der folgenden Tabelle. In dieser verweist beispielsweise High auf die Konfigurationsdatei web_hightrust.config. Sie können in dieser Tabelle etwa erkennen, dass eine Anwendung, die nur mit den Rechten von web_lowtrust.config läuft, keinen Zugriff auf den SQL Server bekommt (genauer gesagt: dass die Funktionen des Namespaces System.Data.SQLClient nicht nutzen kann).


Tabelle 17.2 Berechtigungen nach Sicherheitskonfiguration

Berechtigung Full High Medium Low Minimal

AspNetHostingPermission

Full

High

Medium

Low

Minimal

ConfigurationPermission

Uneingeschränkt

Uneingeschränkt

Keine Berechtigung

Keine Berechtigung

Keine Berechtigung

DnsPermission

Uneingeschränkt

Uneingeschränkt

Uneingeschränkt

Keine Berechtigung

Keine Berechtigung

EnvironmentPermission

Uneingeschränkt

Uneingeschränkt

Read: TEMP, TMP, OS, USERNAME, COMPUTERNAME

Keine Berechtigung

Keine Berechtigung

FileIOPermission

Uneingeschränkt

Uneingeschränkt

Read, Write, Append, PathDiscovery: Anwendungsverzeichnis

Read, PathDiscovery: Anwendungsverzeichnis

Keine Berechtigung

IsolatedStorageFilePermission

Uneingeschränkt

Uneingeschränkt

AssemblyIsolationByUser, Uneingeschränkt UserQuota

1 MB UserQuota (kann für einzelne Sites geändert werden), AssemblyIsolationByUser

Keine Berechtigung

PrintingPermission

Uneingeschränkt

DefaultPrinting

DefaultPrinting

Keine Berechtigung

Keine Berechtigung

ReflectionPermission

Uneingeschränkt

ReflectionEmit

Keine Berechtigung

Keine Berechtigung

Keine Berechtigung

RegistryPermission

Uneingeschränkt

Uneingeschränkt

Keine Berechtigung

Keine Berechtigung

Keine Berechtigung

SecurityPermission

Uneingeschränkt

Execution, Assertion, ControlPrincipal, ControlThread, RemotingConfiguration

Execution, Assertion, ControlPrincipal, ControlThread, RemotingConfiguration

Execution

Execution

SmtpPermission

Uneingeschränkt

Connect

Connect

Keine Berechtigung

Keine Berechtigung

SocketPermission

Uneingeschränkt

Uneingeschränkt

Keine Berechtigung

Keine Berechtigung

Keine Berechtigung

WebPermission

Uneingeschränkt

Uneingeschränkt

Connect mit ursprünglichem Host (falls konfiguriert)

Keine Berechtigung

Keine Berechtigung

SqlClientPermission

Uneingeschränkt

Uneingeschränkt

Uneingeschränkt

Keine Berechtigung

Keine Berechtigung

Ereignisprotokoll

Uneingeschränkt

Keine Berechtigung

Keine Berechtigung

Keine Berechtigung

Keine Berechtigung

Message Queue

Uneingeschränkt

Keine Berechtigung

Keine Berechtigung

Keine Berechtigung

Keine Berechtigung

Service Controller

Uneingeschränkt

Keine Berechtigung

Keine Berechtigung

Keine Berechtigung

Keine Berechtigung

Leistungsindikatoren

Uneingeschränkt

Keine Berechtigung

Keine Berechtigung

Keine Berechtigung

Keine Berechtigung

Verzeichnisdienst

Uneingeschränkt

Keine Berechtigung

Keine Berechtigung

Keine Berechtigung

Keine Berechtigung


Die auswählbaren Richtliniendateien sind in der zentralen Datei web.config (c:\windows\Microsoft.NET\Framework\v2.0.50727\config) gespeichert. Falls Sie eine eigene zusätzliche (spezielle) Richtliniendatei kreieren möchten, können Sie diese einfach dort als zusätzliche Richtlinie eintragen – und sie kann ausgewählt und verwendet werden.

Ich würde empfehlen, eine vorhandene Datei, die Ihrer Zielkonfiguration einigermaßen ähnlich ist, zu kopieren, umzubenennen, in der web.config einzutragen und dann gemäß Ihren Anforderungen zu modifizieren. Diese Vorgehensweise ist deutlich einfacher, als mit einer leeren Datei zu starten.

Ein Beispiel für den Abschnitt aus der web.config sehen Sie in Listing 17.3. Die zusätzlich eingetragene Richtliniendatei ist fett hervorgehoben.

<system.web>
    <securityPolicy>
        <trustLevel name="Full" policyFile="internal" />
        <trustLevel name="High" policyFile="web_hightrust.config" />
        <trustLevel name="Medium"
        policyFile="web_mediumtrust.config" />
        <trustLevel name="Low"  policyFile="web_lowtrust.config" />
        <trustLevel name="Minimal"
        policyFile="web_minimaltrust.config" />
        <trustLevel name="BoddSpecial"
        policyFile="web_BoddSpecial.config" />
    </securityPolicy>
    <trust level="Full" originUrl="" />
</system.web>

Listing 17.3 Auszug aus der »web.config« im Verzeichnis »c:\windows\Microsoft.NET\Framework\v2.0.50727\config«

Das Ändern der Richtliniendateien in aller Ausführlichkeit zu besprechen erscheint mir für ein allgemeines Buch über Windows Server 2008 zu speziell – die wenigsten Administratoren werden das wirklich tun. Wenn Sie tiefer in das Thema einsteigen möchten, können Sie mit folgender Webseite aus der Microsoft-Entwicklerdokumentation starten: http://msdn2.microsoft.com/de-de/library/wyts434y(VS.80).aspx

Wenn Sie Richtliniendateien anpassen, ist es wichtig, sehr genau zu wissen, was die Webapplikationen, die ausgeführt werden sollen, für Codezugriffsrechte benötigen. Ansonsten ist ein fehlerfreier Betrieb nicht möglich. Hier sollte der Entwickler/Hersteller qualifiziert helfen können, ansonsten bliebe Ihnen nur das Ausprobieren…


Galileo Computing - Zum Seitenanfang

17.8.3 IP- und Domäneneinschränkungen topZur vorigen Überschrift

Falls Sie den Zugriff auf den Server, eine Website oder eine Anwendung einschränken möchten, können Sie auch mit IP-Adressbereichen arbeiten. Der zu installierende Rollendienst heißt IP- und Domäneneinschränkungen. Somit können Sie also nicht nur IP-Adressen, sondern auch Domänennamen eingeben, die dann aber per Reverse Lookup wieder auf IP-Adressen »zurückgeführt« werden. Abbildung 17.111 zeigt das Eintragen einer Ablehnungseinschränkungsregel (geniales Wort, wirklich) und dürfte wohl kaum Fragen offen lassen.

Abbildung 17.111 Erstellen einer Ablehnungseinschränkungsregel

Zwei erwähnenswerte Aspekte gibt es beim Dialog Featureeinstellungen bearbeiten (Abbildung 17.112):

  • Zunächst wird die Frage »Was passiert mit nicht aufgeführten Systemen?« beantwortet. Sie können wählen, ob alle nicht explizit genannten IP-Adressen zugelassen oder verweigert werden sollen.
  • Außerdem können Sie die Einschränkungen nach Domänennamen aktivieren. Dies ist nicht standardmäßig aktiviert, weil in diesem Fall für jede eingehende IP-Adresse ein Reverse Lookup ausgeführt werden müsste, um zu prüfen, ob die Adresse zufällig einer der genannten Domänen zuzuordnen ist. Das ist sehr zeitaufwendig und sollte daher nur genutzt werden, wenn Sie sicher sind, dass die auszuführenden Reverse-Lookup-Vorgänge die Gesamt-Performance nicht negativ beeinflussen.

Abbildung 17.112 Das Verhalten gegenüber nicht zugelassenen Clients kann entweder »Zulassen« oder »Verweigern« sein.

Greift ein Client von einer »verbotenen« IP-Adresse aus zu, reagiert der Server mit einem 403er-Fehler (Abbildung 17.113). Auch hier gilt, dass die Fehlermeldung (wahrscheinlich bewusst) sehr allgemein gehalten ist.

Abbildung 17.113 Greift man von einer verweigerten IP-Adresse aus zu, reagiert der Server mit einer »403«.



Ihr Kommentar

Wie hat Ihnen das <openbook> gefallen? Wir freuen uns immer über Ihre freundlichen und kritischen Rückmeldungen.






<< zurück
  Zum Katalog
Zum Katalog: Windows Server 2008 R2

Windows Server 2008 R2
Jetzt bestellen


 Ihre Meinung?
Wie hat Ihnen das <openbook> gefallen?
Ihre Meinung

 Buchempfehlungen
Zum Katalog: Windows 7 für Administratoren






 Windows 7 für
 Administratoren


Zum Katalog: Konzepte und Lösungen für Microsoft-Netzwerke






 Konzepte und
 Lösungen für
 Microsoft-Netzwerke


Zum Katalog: Office SharePoint Server 2007 und Windows SharePoint Services 3.0






 Office SharePoint
 Server 2007 und
 Windows SharePoint
 Services 3.0


Zum Katalog: Exchange Server 2007 und Office Communications Server 2007






 Exchange Server 2007
 und Office
 Communications
 Server 2007


Zum Katalog: Citrix XenApp 5






 Citrix XenApp 5


Zum Katalog: PC-Netzwerke






 PC-Netzwerke


Zum Katalog: VMware vSphere 4






 VMware vSphere 4


Zum Katalog: VMware vSphere 4 - Videotraining






 VMware vSphere 4
 - Videotraining


Zum Katalog: VirtualBox






 VirtualBox


 Shopping
Versandkostenfrei bestellen in Deutschland und Österreich
InfoInfo




Copyright © Galileo Press 2010
Für Ihren privaten Gebrauch dürfen Sie die Online-Version natürlich ausdrucken. Ansonsten unterliegt das <openbook> denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.


[Galileo Computing]

Galileo Press, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, info@galileo-press.de