Kapitel 6

196
6 VPNs im Umfeld von Firewalls
Policy Server
Der SecureClient benötigt im Gegensatz zu SecuRemote gatewayseitig den lizenzpflichtigen Check Point Policy Server. Der Policy Server wird auf dem Filtermodul mitinstalliert (siehe Abschnitt »Installation der Check Point FireWall-1«, S.
106) und ist vor allem für folgende Aufgaben zuständig:
■ Vorhalten der Desktop Policy
Die Desktop Policy ist die Regelbasis für die Personal-Firewall des SecureClients. Sie wird mit dem Check Point SmartDashboard zentral konfiguriert und
anschließend vom Management-Modul auf den Policy Server geschoben.
■ Zuweisung der Desktop Policy an den SecureClient
Sobald sich der SecureClient in den Policy Server einloggt, weist dieser dem
SecureClient die aktuelle Desktop Policy zu.
■ Empfangen und Verarbeiten der Logdaten des SecureClients
6.3
6.3.1
Konfiguration eines Remote-Access-VPNs für das
Firmennetzwerk
Ausgangssituation
Der Ausgangszustand unseres Unternehmensnetzwerks ist in Abb. 4–37 wiedergegeben. Das interne Netz wird vor dem Internet über eine zweistufige FirewallArchitektur abgesichert, die aus einer Check Point FireWall-1 und einer Cisco
PIX besteht. Der ursprünglich vorhandene Einwahlrouter router_ras wurde aus
den in Abschnitt »Modifikation der Ausgangssituation«, S. 135, genannten
Gründen abgeschafft. Stattdessen realisieren wir nun den Remote-Zugriff für
Mitarbeiter und Fremdfirmenmitarbeiter über das Internet unter Verwendung
von VPN-Technologie.
Beide Firewall-Produkte, Check Point FireWall-1/VPN-1 und Cisco PIX,
unterstützen Remote-Access-VPNs, und die Hersteller bieten entsprechende Client-Software an. Es stellt sich daher die Frage, ob wir den Tunnel an der externen
oder an der internen Firewall enden lassen.
Die Entscheidung fällt zugunsten der externen Firewall aus, da auf diese
Weise ein höheres Sicherheitsniveau erreicht werden kann. Im Falle einer Fehlkonfiguration auf der externen Firewall, die zum Beispiel allen Remote-Usern,
auch den Fremdfirmenmitarbeitern, den uneingeschränkten Zugriff auf sämtliche
internen Ressourcen erlaubt, existiert mit einer korrekt konfigurierten internen
Firewall immer noch eine Barriere, die den uneingeschränkten Zugriff unterbinden kann. Würde der Tunnel an der internen Firewall terminieren und derselbe
Konfigurationsfehler gemacht werden, hätten Remote-User uneingeschränkten
6.3 Konfiguration eines Remote-Access-VPNs für das Firmennetzwerk
197
Zugriff auf alle internen Ressourcen, was insbesondere im Fall der Fremdfirmenmitarbeiter nicht erwünscht ist.
Damit sich die Anwender stark authentifizieren können, werden sie mit
Hardware-Tokens (siehe Abschnitt »Authentifizierung«, S. 58) zur Erzeugung
von Einmalpasswörtern ausgestattet. Die Einmalpasswörter werden von SecuRemote bzw. vom SecureClient zusammen mit dem Benutzernamen an die Firewall
übermittelt. Die Firewall kontaktiert anschließend über das Radius-Protokoll den
Authentifizierungsserver, der die Credentials überprüft und das Ergebnis der Firewall übermittelt. Ein geeigneter Platzierungsort für den Authentifizierungsserver
ist die Management-DMZ, in der sich auch die Management-Station der FireWall-1 befindet (siehe Abb. 4–3). Dem Authentifizierungsserver weisen wir die
IP-Adresse 10.10.60.6 zu. Mit dem Check Point SmartDashboard muss ein entsprechendes Server-Objekt vom Typ Radius angelegt werden.
6.3.2
Konfiguration der Check Point FireWall-1/VPN-1
Nachdem wir uns entschieden haben, den VPN-Tunnel an der externen Firewall
fw_ext enden zu lassen, beginnen wir nun mit den erforderlichen Konfigurationsarbeiten für das Remote-Access-VPN. In diesem Abschnitt behandeln wir die
Gateway-Seite. Abschnitt »Clientseitige Konfiguration«, S. 209, geht auf die
Installations- und Konfigurationsarbeiten ein, die auf der Client-Seite (Laptop,
Heimarbeitsplatz) nötig sind.
Installationstätigkeiten
Auf fw_ext fallen für das Remote-Access-VPN keine Installationstätigkeiten
mehr an. Den Policy Server haben wir von Anfang an mitinstalliert (siehe
Abschnitt »Installation der Check Point FireWall-1«, S. 106); daher können wir
umgehend mit der Konfiguration beginnen.
Globale Eigenschaften
Zusätzlich zu den in Abschnitt »Konfiguration der Check Point FireWall-1«, S.
108, bereits konfigurierten globalen Eigenschaften müssen wir für das RemoteAccess-VPN unter GLOBAL PROPERTIES folgende weitere Einstellungen vornehmen:
■ Aktivierung von IP Pool NAT
Unter NAT muss IP Pool NAT aktiviert werden (siehe Abb. 6–8), um zu vermeiden, dass im internen Netz die offiziellen, vom jeweiligen ISP zugewiesenen IP-Adressen auftauchen. IP Pool NAT wurde in Abschnitt »Check Point
VPN-1 und SecuRemote/SecureClient«, S. 193, beschrieben.
198
6 VPNs im Umfeld von Firewalls
Abb. 6–8 Aktivierung von IP Pool NAT
■ Globale SecuRemote/SecureClient-Eigenschaften
Abb. 6–9 dokumentiert die globalen Eigenschaften für den VPN-Client, die
wir für unser Unternehmensnetzwerk ausgewählt haben.
Die unter TOPOLOGY UPDATE vorgenommenen Einstellungen bewirken, dass dem Client Änderungen an der Topologie automatisch mitgeteilt
werden, d.h. Änderungen an der Menge von IP-Adressen, zu denen der VPNClient verschlüsselte Verbindungen hin aufbauen darf.
Abb. 6–9 SecuRemote/Secure-Client-Eigenschaften
6.3 Konfiguration eines Remote-Access-VPNs für das Firmennetzwerk
199
Der AUTHENTICATION TIMEOUT definiert, wie lange ein authentifizierter Remote-User mit der Site kommunizieren darf. Nach Ablauf dieser Zeitspanne wird er von SecuRemote bzw. vom SecureClient erneut zur Authentifizierung aufgefordert.
Unter ADDITIONAL PROPERTIES wurde zum einen erzwungen, dass
DNS-Anfragen an DNS-Server innerhalb der VPN Domain verschlüsselt werden. Aus Performance-Gründen könnte es eventuell sinnvoll sein, die Verschlüsselung von DNS-Anfragen zu unterbinden. Zum anderen wird mit der
Aktivierung von ENABLE BACK CONNECTIONS erreicht, dass Rückverbindungen vom Gateway zum Client (zum Beispiel bei ftp die Datenverbindung) ebenfalls verschlüsselt werden.
■ VPN-Parameter
Für SecuRemote bzw. für den SecureClient wurden unter REMOTE
ACCESS/VPN ADVANCED die in Abb. 6–10 abgedruckten Parameter für
Verschlüsselung, Datenintegrität und IKE eingestellt.
Abb. 6–10 VPN-Eigenschaften
200
6 VPNs im Umfeld von Firewalls
Zusätzlich ist unter REMOTE ACCESS/VPN BASIC die Auswahl des HYBRID
MODE als Authentifizierungsmethode für IKE entscheidend. Nur so ist die im
folgenden Abschnitt beschriebene Radius-Authentifizierung für Remote-User
überhaupt möglich.
Enforcement-Modul
Die in Abschnitt »Konfiguration der Check Point FireWall-1«, S. 108, vorgenommene Konfiguration des Enforcement-Moduls muss wie folgt erweitert werden:
■ General Properties
Unter CHECK POINT PRODUCTS müssen zusätzlich VPN und SECURECLIENT POLICY SERVER ausgewählt werden (vgl. Abb. 4–10).
■ Topology
Zusätzlich zu den Interfaces und Anti-Spoofing wird unter TOPOLOGY
auch die VPN Domain konfiguriert. In Abschnitt »Check Point VPN-1 und
SecuRemote/SecureClient«, S. 193, wurde die VPN Domain als die Menge
der IP-Adressen definiert, mit denen der SecureClient verschlüsselt kommunizieren kann. Mit der Einstellung aus Abb. 6–11 umfasst die VPN Domain alle
IP-Adressen, die bei der Interface-Definition von hme0, qfe1 und qfe2 unter
IP ADDRESSES BEHIND INTERFACE (siehe Abb. 4–11) jeweils angegeben
wurden. Konkret sind dies das Netz 10.10.60.0/28 (hme0), das Netz
140.252.90.184/29 (qfe1) sowie alle Objekte, die in der Gruppe
Interne_Netze enthalten sind (qfe2). qfe0 ist das externe Interface und ist für
die VPN Domain folglich unerheblich.
Abb. 6–11 Spezifikation der VPN Domain
■ NAT
Nachdem in den GLOBAL PROPERTIES IP Pool NAT generell aktiviert
wurde, muss beim Enforcement-Modul unter NAT der konkrete IP-Pool festgelegt werden. Als IP-Pool wählen wir für unser Firmennetzwerk das Objekt
REMOTEUSER (10.10.10.0/24) aus.
Sobald ein Remote-User über das VPN die erste Verbindung ins interne
Netz aufbaut, wählt die Firewall eine freie IP-Adresse aus dem Pool
10.10.10.0/24 aus und übersetzt die offizielle Quell-Adresse aller Pakete von
diesem User in die private Adresse. Die IP-Adresse wird dem Pool zurückgegeben, nachdem die Firewall 60 Minuten lang keine Pakete mehr von diesem
Benutzer empfangen hat (siehe Abb. 6–12).
6.3 Konfiguration eines Remote-Access-VPNs für das Firmennetzwerk
201
Abb. 6–12 Konfiguration von IP Pool NAT
■ Authentication
Unter AUTHENTICATION werden die Authentifizierungsmethoden ausgewählt, die das Enforcement-Modul unterstützen soll, um VPN-Benutzer zu
authentifizieren. Voraussetzung für die Verwendung einer dieser Methoden
zur Authentifizierung von IPSec-Tunneln ist die weiter oben beschriebene
Aktivierung des Hybrid Mode in den Global Properties. Da unsere Firewall
den Authentifizierungsserver über Radius abfragt, wählen wir ausschließlich
RADIUS aus (siehe Abb. 6–13).
Unter AUTHENTICATION wird außerdem festgelegt, welche Benutzer
sich in den Policy Server einloggen dürfen. In unserem Fall ist das die Gruppe
RemoteAccessUsers (siehe auch den Abschnitt »Benutzerverwaltung« weiter
unten).
Abb. 6–13 Auswahl der Authentifizierungsmethoden, die das Gateway unterstützt
202
6 VPNs im Umfeld von Firewalls
Split DNS
Ein interessanter Aspekt im Zusammenhang mit Remote-Access-VPNs ist die
Namensauflösung über DNS.
Bei der Einwahl ins Internet wird dem Rechner des Remote-Users von seinem
ISP neben der IP-Adresse auch ein DNS-Server zugewiesen, damit Namen im
Internet aufgelöst werden können. Nach dem Aufbau eines Tunnels zur Firma
besteht aber auch die Notwendigkeit, interne Namen auflösen zu können.
Bei herkömmlichen Einwahllösungen (Dial-In direkt in die Firma) oder bei
einem L2TP-Tunnel kann dem Remote-PC über PPP ein interner DNS-Server zugewiesen werden. Bei reinen IPSec-Tunneln besteht diese Möglichkeit nicht, da PPP
nur zwischen dem Remote-PC und dem Einwahlrouter des ISP gesprochen wird.
Check Point löst diese Problematik durch so genannte SecuRemote DNS-Server. Hierbei handelt es sich um ein spezielles Server-Objekt, das neben der IPAdresse des internen DNS-Servers auch die intern verwendete(n) DNS-Domäne(n),
zum Beispiel ».firma-intern.com«, beinhaltet. Diese Informationen sind Bestandteil
der Topologie, die sich SecuRemote bzw. der SecureClient vom EnforcementModul herunterlädt. Dadurch ist das Kernel-Modul in der Lage, DNS-Anfragen
zur Auflösung interner Hostnamen (zum Beispiel »intranet.firma-intern.com«)
über den Tunnel an den internen DNS-Server zu leiten. Für alle anderen Domänen
wird weiterhin der vom ISP zugewiesene DNS-Server verwendet.
Abb. 6–14 Definition eines SecuRemote DNS-Servers (1)
In unserem Firmennetzwerk sind für die Definition des SecuRemote DNS-Servers
folgende Schritte erforderlich: Zunächst definieren wir den internen DNS-Server
als Objekt vom Typ Host (Objektname: DNS_int, IP-Adresse 10.10.100.40).
6.3 Konfiguration eines Remote-Access-VPNs für das Firmennetzwerk
203
Dieses Objekt verwenden wir in der Definition des SecuRemote DNS-Servers
(siehe Abb. 6–14). Unter DOMAINS konfigurieren wir die intern verwendete
DNS-Domäne (siehe Abb. 6–15).
Abb. 6–15 Definition eines SecuRemote DNS-Servers (2)
Benutzerverwaltung
Die Check-Point-Benutzerverwaltung ordnet den Remote-Usern neben dem
Benutzernamen auch Eigenschaften wie die Authentifizierungsmethode (zum Beispiel Radius, SecurID etc.) oder die Gruppenzugehörigkeit zu.
Die Speicherung von Benutzern kann entweder in der Check-Point-Datenbank oder auf einem externen LDAP-Server erfolgen. Der Einfachheit halber verwalten wir die Remote-User unseres Unternehmens in der lokalen Check-PointDatenbank. In größeren Unternehmen werden die Benutzer in der Regel auf
einem LDAP-Server gepflegt.
■ Benutzergruppen
Für unsere Remote-User bietet sich die Zuordnung zu einer der beiden
Benutzergruppen Mitarbeiter oder Fremdfirmenmitarbeiter an. Die Benutzergruppen werden später in der Regelbasis verwendet, um unterschiedliche
Berechtigungsprofile abzubilden: Fremdfirmenmitarbeiter sollen nur auf die
Ressourcen zugreifen, die sie administrieren müssen, während sich Firmenmitarbeiter im internen Netz frei bewegen, d.h. auf alle internen Ressourcen
zugreifen dürfen.
Um zu spezifizieren, welche Benutzer sich in den Policy Server einloggen
dürfen (vgl. Abb. 6–13), definieren wir eine weitere Gruppe RemoteAccessU-
204
6 VPNs im Umfeld von Firewalls
sers, die alle Remote-User, d.h. die Gruppen Mitarbeiter und Fremdfirmenmitarbeiter, enthält.
■ Templates
Im Folgenden werden wir für die beiden Benutzergruppen jeweils ein Template definieren. Ein Template kann man sich als einen allgemeinen Benutzer
mit bestimmten Eigenschaften (Eigenschaften sind zum Beispiel die Authentifizierungsmethode und die Gruppenzugehörigkeit) vorstellen. Legt man später einen konkreten Benutzer an und ordnet ihm ein Template zu, erbt der
Benutzer alle im Template festgelegten Eigenschaften.
Für unsere Templates sind besonders die Eigenschaften Gruppenzugehörigkeit (GROUPS in Abb. 6–16), Authentifizierungsmethode (AUTHENTICATION) und Verschlüsselungseigenschaften (ENCRYPTION) von Interesse.
Abb. 6–16 Definition eines Templates für die Mitarbeiter unseres Unternehmens
Die Authentifizierungsmethode und die Verschlüsselungseigenschaften sind
für beide Gruppen identisch. Die Authentifizierungsmethode ist für alle
Remote-User RADIUS, da sowohl für Mitarbeiter als auch für Fremdfirmenmitarbeiter derselbe Radius-basierte Authentifizierungsserver verwendet
6.3 Konfiguration eines Remote-Access-VPNs für das Firmennetzwerk
205
wird. Die Templates unterscheiden sich lediglich in der Gruppenzugehörigkeit. Tab. 6–2 fasst die vorgenommenen Einstellungen zusammen.
Groups
TL_Mitarbeiter
TL_Fremdfirmenmitarbeiter
Mitarbeiter
Fremdfirmenmitarbeiter
Authentication Radius
Encryption
IKE. In den IKE-Eigenschaften muss unter AUTHENTICATION »Public Key«
ausgewählt werden (Authentifizierung der Firewall gegenüber dem Client).
Tab. 6–2 Definition der Templates für Mitarbeiter (TL_Mitarbeiter) und
Fremdfirmenmitarbeiter (TL_Fremdfirmenmitarbeiter)
■ Anlegen von Benutzern
Unter Verwendung der Templates können nun sehr einfach Benutzer angelegt
werden, da nur noch der Benutzername angegeben werden muss. Alle anderen Eigenschaften werden vom Template vererbt (siehe Abb. 6–17).
Abb. 6–17 Anlegen von Benutzern unter Verwendung der Templates
VPN Community
Die Zuordnung, welche Benutzergruppen mit welchen Gateways Remote-AccessVPNs aufbauen dürfen, wird über die Remote Access Community im VPN
Manager des SmartDashboard definiert. Wir nennen die VPN Community
RemoteAccess und wählen unser Firewall-Gateway fw_ext (Abb. 6–18) sowie die
oben definierte Benutzergruppe RemoteAccessUsers (Abb. 6–19) aus.
Abb. 6–18 Auswahl des Gateways für die Remote Access Community
206
6 VPNs im Umfeld von Firewalls
Abb. 6–19 Auswahl der Benutzergruppe für die Remote Access Community
Regelbasis
Die Regelbasis aus Abb. 4–13, Abb. 4–14 und Abb. 4–15 muss für unser RemoteAccess-VPN in zweierlei Hinsicht erweitert werden.
Zum einen müssen Regeln definiert werden, um die IPSec-Kommunikation
und den Topologie-Download zwischen Client und Firewall zu ermöglichen
(Regel 4 in Abb. 6–20), zum anderen müssen benutzerbezogene Regeln angelegt
werden, die den Remote-Usern den Zugang zu internen Ressourcen ermöglichen
(Regel 6 und 7 in Abb. 6–20). Bei diesen Regeln ist die Spalte VPN der Regelbasis
von Bedeutung, in der unsere Remote Access Community RemoteAccess ausgewählt werden muss.
Regel 4 ermöglicht beliebigen externen IP-Adressen den Download der
Topologie sowie den Aufbau von IPSec-Tunneln. Weil die IP-Adressen der
Clients nicht vorhergesagt werden können, müssen unter SOURCE alle
denkbaren IP-Adressen zugelassen werden. Der Topologie-Download sowie der
Aufbau des IPSec-Tunnels ist freilich nur für authentifizierte Benutzer möglich.
Regel 6 gestattet Remote-Usern, die der Gruppe Mitarbeiter zugeordnet sind
(d.h., der User wurde unter Verwendung des Templates TL_Mitarbeiter angelegt), den freien Zugang zu allen internen Ressourcen. Fremdfirmenmitarbeiter
dürfen nur auf die Ressourcen zugreifen, die sie benötigen, um ihren Wartungsauftrag zu erfüllen (Regel 7). Die Hostobjekte unter DESTINATION (ERP und
SAP) mussten zuvor definiert werden.
6.3 Konfiguration eines Remote-Access-VPNs für das Firmennetzwerk
207
Abb. 6–20 Erweiterte Regelbasis unserer externen Firewall. Neu sind die Regeln 4, 6 und 7.
208
6 VPNs im Umfeld von Firewalls
Desktop Policy
Die Regelbasis für die Personal-Firewall des SecureClients, die so genannte Desktop Policy, wird ebenfalls mit dem Check Point SmartDashboard angelegt.
Für unser Unternehmensnetzwerk wollen wir mit der Desktop Policy erreichen, dass Anwender, die über IPSec mit der Firma verbunden sind, nicht gleichzeitig mit dem Rest des Internets kommunizieren dürfen. Die Regelbasis aus Abb.
6–21 erfüllt diesen Zweck.
Bei der Desktop Policy wird zwischen Inbound- und Outbound-Regeln unterschieden. Mit den Regeln unter INBOUND werden Kommunikationsbeziehungen definiert, die von außen (Internet, Firmennetz) zum Remote-PC hin aufgebaut werden. Umgekehrt beschreiben die Regeln unter OUTBOUND die
Kommunikationsbeziehungen zwischen dem Remote-PC und dem Rest der Welt.
Die Regeln 1 und 3 in Abb. 6–21 ermöglichen die freie Kommunikation zwischen Firmennetz und Remote-PC (Regel 1) und umgekehrt (Regel 3). Die Regeln
2 und 4 verbieten jeglichen sonstigen Netzwerkverkehr. Die abgedruckte Regelbasis gilt sowohl für die Mitarbeiter des Unternehmens als auch für die Fremdfirmenmitarbeiter. Die Unterscheidung zwischen Mitarbeiter und Fremdfirmenmitarbeiter erfolgt bei uns nicht in der Desktop Policy, sondern gatewayseitig in Form
von benutzerbezogenen Regeln (siehe Abb. 6–20). In unserem Fall hat die Desktop
Policy lediglich den Zweck sicherzustellen, dass keine Kommunikation mit dem
Internet möglich ist, während der Anwender mit der Firma kommuniziert.
Abb. 6–21 Desktop Policy
6.3 Konfiguration eines Remote-Access-VPNs für das Firmennetzwerk
6.3.3
209
Clientseitige Konfiguration
Installation
Bei SecuRemote und dem SecureClient handelt es sich um ein und dasselbe Installationspaket. Während der Installation ist auszuwählen, ob SecuRemote oder der
SecureClient zum Einsatz kommen soll. Für die Rechner unserer Remote-User
verwenden wir ausschließlich den SecureClient. Nach einem Reboot ist die Installation abgeschlossen.
Konfiguration
Nach der Installation muss über das GUI die so genannte Site angelegt werden
(siehe Abb. 6–22). Dabei wird dem SecureClient die externe IP-Adresse des Gateways bekannt gemacht, zu dem der Tunnel hin aufgebaut werden soll. In unserem
Fall ist dies die IP-Adresse 140.252.90.241. Außerdem ist die Authentifizierungsmethode auszuwählen. Diese ist in unserem Fall »Challenge Response«, da wir
dynamische Einmalpasswörter verwenden.
Abb. 6–22 Anlegen einer Site
Im Anschluss an das Anlegen der Site startet der Topologie-Download. Hierzu
muss sich der Anwender authentifizieren. Die Topologie-Informationen, unter
anderem die VPN Domain, werden im Installationsverzeichnis des SecureClients
im Unterordner database in der Datei userc.C gespeichert.
210
6 VPNs im Umfeld von Firewalls
6.3.4
Aufbau eines Tunnels zum Firmennetzwerk
Abschließend wird anhand einer beispielhaften Sitzung der Ablauf des
Tunnelaufbaus beschrieben: Ein Außendienstmitarbeiter unseres Unternehmens
mit dem Namen Maier möchte abends im Hotel seine E-Mails abrufen.
1. Herr Maier wählt sich bei seinem ISP (zum Beispiel T-Online) ins Internet
ein.
2. Er startet den Tunnelaufbau zur Firma, indem er auf das SecureClientIcon doppelklickt. Der CONNECT-Button im daraufhin erscheinenden
Fenster (siehe Abb. 6–23) löst den Tunnelaufbau aus.
Abb. 6–23 Start des Tunnelaufbaus
3. Herr Maier wird vom SecureClient zur Eingabe seines Passworts aufgefordert. Er gibt das dynamische Einmalpasswort ein, das er von seinem
Token abliest.
4. Nach erfolgreicher Authentifizierung werden die Tunnelparameter ausgehandelt, und der SecureClient loggt sich in den Policy Server ein, um die
Desktop Policy herunterzuladen und anschließend zu aktivieren.
6.4 Konfiguration eines Site-to-Site-VPNs für das Firmennetzwerk
211
5. Der Tunnel zwischen dem Laptop von Herrn Maier und der Firewall
fw_ext unseres Unternehmens wurde aufgebaut. Die Personal-Firewall ist
aktiv.
6. Herr Maier startet seinen Mail-Client (Microsoft Outlook), der eine Verbindung zum Exchange-Server aufbaut. Der SecureClient erkennt anhand
der Topologie, dass sich der Exchange-Server in der VPN Domain von
fw_ext befindet, und verschickt das Paket daher über den Tunnel zur Firewall. Dort wird die offizielle Adresse des Providers in eine Adresse aus
dem IP Pool NAT-Bereich 10.10.10.0/24 übersetzt.
6.4
6.4.1
Konfiguration eines Site-to-Site-VPNs für das
Firmennetzwerk
Ausgangssituation
Da unser Unternehmen aus der Fertigungsindustrie kürzlich Teile seiner Entwicklung an eine Partnerfirma auslagert hat, besteht die Notwendigkeit, dass die Partnerfirma Zugriff auf das Entwicklungssystem enthält. Dieses befindet sich im
internen Netzwerk unseres Unternehmens und hat die IP-Adresse 10.10.100.50
(siehe Abb. 6–24).
Eine Möglichkeit, um den sicheren und kontrollierten Zugriff der Partnerfirma auf dieses System zu gewährleisten, bestünde in der Nutzung des im vorherigen Abschnitt aufgebauten Remote-Access-VPNs. In diesem Fall müssten alle
Mitarbeiter der Partnerfirma, die auf das Entwicklungssystem zugreifen dürfen,
mit Hardware-Tokens ausgestattet werden und auf ihren Rechner den Check
Point SecureClient installieren. Da Letzteres seitens der IT-Leitung der Partnerfirma nicht erwünscht ist, hat unser Unternehmen in Absprache mit der Partnerfirma beschlossen, ein Site-to-Site-VPN zwischen den externen Firewalls der beiden Unternehmen auszubauen. Hierbei handelt es sich bei der Partnerfirma um
eine Cisco-PIX-Firewall; in unserem Unternehmen wird die Check Point FireWall-1/VPN-1 eingesetzt.
Ein weiterer Grund für den Einsatz eines Site-to-Site-VPNs anstelle eines
Remote-Access-VPN ist der Umstand, dass über 100 Entwickler auf das Entwicklungssystem zugreifen sollen. Bei der Realisierung des Zugriffs über ein RemoteAccess-VPNs würde dies für unser Unternehmen vergleichsweise hohe Kosten für
die Bereitstellung der Hardware-Tokens bedeuten.

Download Report