bachelorthesis

Bachelor-Thesis

Integration einer Landesgesellschaft in die Bizerba Netzwerk Infrastruktur

Autor: Matthias Pyka

Matrikelnummer: 73 56 8

Email: [email protected]

Eingereicht am: 21.12.2009

Studiengang: Kommunikations- & Softwaretechnik

Hochschule: Hochschule Albstadt Sigmaringen

Betreuende Professorin: Fr. Prof. Dr. Ute Matecki

Hochschule: Hochschule Albstadt Sigmaringen

Betreuer: Hr. Dipl. Ing. Jens Ellinger

Firma: Bizerba GmbH & Co. KG

Eidesstattliche Erklärung | Matthias Pyka a

1

Eidesstattliche Erklärung

Ich erkläre hiermit an Eides statt, dass ich die vorliegende Arbeit selbstständig und ohne Benut-

zung anderer als der angegebenen Hilfsmittel angefertigt habe. Alle Stellen, die wörtlich oder

sinngemäß aus veröffentlichten und nicht veröffentlichten Schriften entnommen sind, sind als

solche kenntlich gemacht. Die Arbeit hat in gleicher oder ähnlicher Form noch in keiner anderen

Prüfungsbehörde vorgelegen.

Balingen, den 20. Dezember 2009

Matthias Pyka

Vorwort | Matthias Pyka a

2

Vorwort

Die folgende Arbeit, welche im Rahmen meiner Bachelor Abschlussarbeit verfasst wurde handelt

von der Integration der Bizerba Landesgesellschaft Österreich in das Bizerba Corporate Network.

Ein unternehmensweites Netzwerk bringt in der heutigen Informationsgesellschaft sehr viele Vor-

teile mit sich. Schneller Informations- und Datenaustausch hilft den Verantwortlichen auf Ge-

schäftssituationen besser zu reagieren sowie Entwicklern gemeinsam an Projekten zu arbeiten.

Durch die globale Vernetzung werden innerhalb eines Unternehmens sowohl Personal, als auch

mehrfach verwendete Hardware eingespart. Auch die Zentralisierung von Know How und dadurch

die verbesserte Security und der zentralisierte First- und Second-Level Support bringen deutliche

Vorteile. Durch die Einsparung der meist kleinen Rechenzentren in den Standorten, welche durch

die Internationalisierung des Corporate Networks geschaffen wird, wird neben Kosten auch Ener-

gie gespart, ganz im Sinne der in den letzten Jahren viel zitierten »Green IT«.

Ganz herzlich bedanken möchte ich mich an dieser Stelle bei Fr. Prof. Dr. Matecki für die sehr gute

Betreuung und Beratung während dieser Arbeit. Ebenfalls für die hervorragende Betreuung, für

die Unterstützung während der Ausarbeitung und der einzelnen Projektabschnitte sowie für die

sehr kollegiale und gute Zusammenarbeit möchte ich mich bei Herrn Jens Ellinger bedanken. Auch

bei den weiteren Mitarbeitern der Abteilung IT-O darf ich mich an dieser Stelle herzlich für die

gute Zusammenarbeit sowie für die Unterstützung bedanken.

Mein Dank gilt auch der Bizerba GmbH & Co. KG, welche meinen beruflichen Werdegang bereits

seit 2001 prägt, sowie meiner Familie und meiner Freundin für das Korrekturlesen dieser Arbeit.

Hinweis:

Sämtliche öffentliche IP-Adressen sowie Sicherheitskritische Informationen wurden in diesem Do-

kument durch andere Angaben ersetzt. Die verwendeten öffentlichen IP-Adressen entstammen

alle aus dem IP-Adresspool der Hochschule Albstadt Sigmaringen.

Inhaltsverzeichnis | Matthias Pyka a

3

Inhaltsverzeichnis

Eidesstattliche Erklärung ............................................................................................................... 1

Vorwort ....................................................................................................................................... 2

Inhaltsverzeichnis ......................................................................................................................... 3

Tabellenverzeichnis....................................................................................................................... 9

Abbildungsverzeichnis ................................................................................................................ 10

1. Einleitung ........................................................................................................................ 12

1.1 Nutzen der Integration .................................................................................................... 12

1.2 Kosten-Nutzen-Analyse ................................................................................................... 15

1.2.1 Kosten des Projektabschnittes ......................................................................................... 15

1.2.2 Nutzen des Projektabschnittes ......................................................................................... 15

1.2.2.1 Notfall-Infrastruktur für das EUDAT System ....................................................... 15

1.2.2.2 Zentrale Administration der IT Infrastruktur ....................................................... 16

1.2.2.3 Voraussetzung für die Einführung von SIS, CAS/CRM, SAP ................................ 16

1.2.2.4 Improvements durch die Integration ................................................................. 17

1.2.3 Gegenüberstellung der Kosten und des Nutzens des Projektabschnittes ........................... 17

1.3 Zielsetzung ...................................................................................................................... 18

1.4 Aufbau der Bachelor-Thesis ............................................................................................. 19

2. Verwendete Technologien ............................................................................................... 20

2.1 Verwendete Soft- und Hardware ..................................................................................... 20

2.1.1 Software: ........................................................................................................................ 20

2.1.1.1 Check Point Provider -1 .................................................................................... 20

2.1.1.2 Check Point R70 ............................................................................................... 20

2.1.1.3 Check Point V8.0.33 ......................................................................................... 21

2.1.1.4 Microsoft Internet Explorer 8 ............................................................................ 21

2.1.1.5 Microsoft Office Outlook 2007 ......................................................................... 21

2.1.1.6 Microsoft Office Power Point 2007 ................................................................... 21


4

2.1.1.7 Microsoft Office Project 2003 ........................................................................... 21

2.1.1.8 Microsoft Office Visio 2007 .............................................................................. 21

2.1.1.9 Microsoft Office Word 2007 ............................................................................. 21

2.1.1.10 Microsoft Windows Kommandozeile ............................................................. 22

2.1.1.11 Microsoft Remote Desktop............................................................................ 22

2.1.1.12 Microsoft Windows XP Professional .............................................................. 22

2.1.1.13 PuTTY ........................................................................................................... 22

2.1.2 Hardware: ....................................................................................................................... 23

2.1.2.1 Fluke Networks NetTool Series II ....................................................................... 23

2.1.2.2 HP-Compaq 6910p ........................................................................................... 23

2.1.2.3 Check Point UTM-1Edge W16 ........................................................................... 23

2.1.2.4 Check Point UTM -1 1050 ................................................................................. 23

2.2 Firewall Techniken ........................................................................................................... 24

2.2.1 Entstehungshistorie der Firewall ...................................................................................... 25

2.2.2 Firewall-Architekturen ..................................................................................................... 26

2.2.2.1 Paketfilter (packet screen) Architektur (Stateless / Stateful Firewall) ................... 26

2.2.2.2 Stateful Inspection Architektur .......................................................................... 26

2.2.2.3 Stealth Firewall (Bridging Firewall) .................................................................... 26

2.2.2.4 Circuit-Level-Gateway ....................................................................................... 26

2.2.2.5 Intrusion Detection ........................................................................................... 27

2.2.2.6 Application-Level-Gateway ............................................................................... 28

2.2.2.7 Global Firewall .................................................................................................. 29

2.2.2.8 Personal Firewall ............................................................................................... 29

2.2.2.9 Load-Balancing Firewall .................................................................................... 30

2.2.2.10 Distributed Firewall ....................................................................................... 30

2.2.2.11 Firewall Cluster, Firewall Farms ...................................................................... 30

2.2.2.12 Authentifizierung .......................................................................................... 30

2.2.2.13 Verwaltung von Firewalls .............................................................................. 31

2.2.2.14 Verschlüsselung und VPNs ............................................................................ 31


5

2.2.2.15 NAT – Network Address Translation .............................................................. 32

2.2.2.16 Protokollierung und Berichterstellung ............................................................ 32

2.2.2.17 Datensicherung ............................................................................................. 32

2.3 VPN - Virtual Privat Network ........................................................................................... 33

2.3.1 Remote Access VPN ........................................................................................................ 33

2.3.2 Branch Office VPN / Site-to-Site VPN ............................................................................... 34

2.3.3 Extranet VPN ................................................................................................................... 35

2.3.4 Anforderungen an ein VPN .............................................................................................. 36

2.3.4.1 Sicherheit ......................................................................................................... 36

2.3.4.2 Verfügbarkeit ................................................................................................... 38

2.3.4.3 Performance ..................................................................................................... 38

2.3.4.4 Skalierbarkeit und Migrationsfähigkeit .............................................................. 38

2.3.5 Sicherheit in VPNs ........................................................................................................... 39

2.3.6 Verschlüsselungsverfahren............................................................................................... 40

2.3.6.1 Symmetrisches Verschlüsselungsverfahren ........................................................ 40

2.3.6.2 AES .................................................................................................................. 40

2.3.6.3 Hash-Verfahren ................................................................................................ 43

2.3.6.4 Asymmetrische Verschlüsslungsverfahren ......................................................... 44

2.3.7 Tunneling Protokoll - IPSec .............................................................................................. 44

2.4 Übertragungstechnik ....................................................................................................... 47

2.4.1 SDSL ............................................................................................................................... 47

2.4.2 ADSL - Asymmetric Digital Subscriber Line ....................................................................... 48

2.5 Verkabelungstechnik ....................................................................................................... 53

2.5.1 Strukturierte Verkabelung................................................................................................ 53

2.5.2 Gängige Kabelarten......................................................................................................... 56

2.5.2.1 Twisted Pair Kabel ............................................................................................ 56

2.5.2.2 UTP-Schirmung ................................................................................................. 56

2.5.2.3 S/UTP-Schirmung .............................................................................................. 56

2.5.2.4 FTP-Schirmung ................................................................................................. 57


6

2.5.2.5 S/FTP-Schirmung ............................................................................................... 57

2.5.2.6 ITP-Schirmung .................................................................................................. 57

2.5.2.7 Kategorien 1 .................................................................................................... 57

2.5.2.8 Kategorien 2 .................................................................................................... 57

2.5.2.9 Kategorien 3 .................................................................................................... 57

2.5.2.10 Kategorie 4 ................................................................................................... 58

2.5.2.11 Kategorie 5 ................................................................................................... 58

2.5.2.12 Kategorie 6 ................................................................................................... 58

2.5.2.13 Kategorie 7 ................................................................................................... 58

2.6 Alternative Anbindungslösungen von Lokationen ............................................................ 59

2.6.1 Alternative Übertragungstechniken: ................................................................................ 59

2.6.1.1 ISDN - Integrated Service Digital Network ......................................................... 59

2.6.1.2 VDSL - Very High Speed Digital Subscriber Line ................................................. 61

2.6.1.3 VDSL2 - Very High Speed Digital Subscriber Line 2 ............................................ 62

2.6.1.4 EuroDocsis - European Data Over Cable Service Interface Specification ............. 64

2.6.2 Alternative Übertragungsmethoden: ................................................................................ 66

2.6.2.1 MPLS ................................................................................................................ 66

2.6.2.2 Ethernet-over-WAN .......................................................................................... 67

3. Vorbereitende Analysen und Vergleiche .......................................................................... 68

3.1 Ist-Zustandsanalyse ......................................................................................................... 68

3.2 Soll-Konzept .................................................................................................................... 75

3.3 Projektplanung ................................................................................................................ 80

3.4 Security Analyse .............................................................................................................. 83

3.5 Gefahren für die IT-Infrastruktur ...................................................................................... 85

3.5.1 Externe Gefahrenquellen ................................................................................................. 85

3.5.1.1 Viren ................................................................................................................ 85

3.5.1.2 Würmer ............................................................................................................ 86

3.5.1.3 Trojaner ............................................................................................................ 86

3.5.1.4 Exploit .............................................................................................................. 86


7

3.5.1.5 Backdoors ........................................................................................................ 86

3.5.1.6 Rootkits ............................................................................................................ 86

3.5.1.7 Spyware ........................................................................................................... 86

3.5.1.8 Phishing ........................................................................................................... 87

3.5.1.9 DoS Attacken ................................................................................................... 87

3.5.1.10 Sniffer ........................................................................................................... 87

3.5.1.11 Vulnerability Scanner .................................................................................... 87

3.5.2 Interne Gefahrenquellen .................................................................................................. 88

3.5.2.1 Externe Speichermedien ................................................................................... 88

3.5.2.2 WLAN-Access Points ......................................................................................... 88

3.5.2.3 Mobiltelefone mit Theadering Option / UTMS Karten ........................................ 88

3.5.2.4 Weitere Gefahrenquellen .................................................................................. 88

3.5.2.5 Key-Logger ....................................................................................................... 88

3.5.2.6 Social Engineering ............................................................................................ 89

3.5.2.7 Physikalischer Zugang zu sensibler Hardware .................................................... 89

3.6 Konzeption einer alternativen WLAN Lösung ................................................................... 90

4. Projektumsetzung ........................................................................................................... 92

4.1 Hardwareseitige Konfiguration ........................................................................................ 92

4.1.1 Check Point UTM-1 1050 Cluster ..................................................................................... 92

4.1.1.1 Vorbereitende Schritte ...................................................................................... 93

4.1.1.2 Firewall auf Default zurücksetzen ...................................................................... 94

4.1.1.3 Erster Start der Firewall ..................................................................................... 95

4.1.1.4 Konfiguration der Firewall mit Hilfe des Installationwizards ............................... 95

4.1.1.5 Konfiguration der Firewall Connections ............................................................ 97

4.1.1.6 Upgrade auf R70 .............................................................................................. 98

4.1.2 Check Point UTM-1 Edge W16 ........................................................................................ 99

4.1.2.1 Vorbereitende Schritte ...................................................................................... 99

4.1.2.2 Erster Login .................................................................................................... 100

4.1.2.3 Konfiguration des Datums / der Uhrzeit .......................................................... 101


8

4.1.2.4 Internetverbindung konfigurieren ................................................................... 101

4.1.2.5 Lokales Netzwerk konfigurieren ...................................................................... 102

4.1.2.6 Demilitarisierte Zone konfigurieren ................................................................. 103

4.1.2.7 Wireless Local Area Network konfigurieren ..................................................... 103

4.1.2.8 Firewall Management Einstellungen konfigurieren .......................................... 105

4.1.2.9 Verbindung zur Checkpoint Management aufnehmen .................................... 106

4.2 Managementseitige Konfiguration ................................................................................ 107

4.2.1 Globale Netze & Gruppen anlegen................................................................................. 108

4.2.2 Anlegen des Firewall Clusters ........................................................................................ 113

4.2.3 Anlegen der Check Point UTM-1 Edge W16 ................................................................... 117

4.3 Installation vor Ort ........................................................................................................ 120

4.3.1 Wien ............................................................................................................................. 120

4.3.2 Graz .............................................................................................................................. 122

4.3.3 Linz ............................................................................................................................... 123

4.3.4 Bregenz ......................................................................................................................... 124

5. Fazit .............................................................................................................................. 125

5.1 Zusammenfassung ........................................................................................................ 126

5.2 Ausblick ........................................................................................................................ 127

Anhang .................................................................................................................................... 128

a. Webquellen ................................................................................................................... 128

b. Literaturquellen ............................................................................................................. 130

c. Bildquellen .................................................................................................................... 132

d. Abkürzungsverzeichnis .................................................................................................. 133

e. Spezifikationen der eingesetzten Firewall-Typen ............................................................ 136

f. Bizerba GmbH & Co. KG ................................................................................................ 141


9

Tabellenverzeichnis

Tabelle 1 - Kosten der Integration .............................................................................................. 15

Tabelle 2 - Ausfallzeit des EUDAT Systems .................................................................................. 15

Tabelle 3 - Kosten der Administration vor der Integration ........................................................... 16

Tabelle 4 - Kosten der Administration nach der Integration ........................................................ 16

Tabelle 5 - Gegenüberstellung der Administrationskosten ........................................................... 16

Tabelle 6 - Gegenüberstellung von Kosten und Nutzen ............................................................... 17

Tabelle 7 - ADSL Standards ......................................................................................................... 50

Tabelle 8 - Geschwindigkeit im Bezug auf die Leitungslänge bei VDSL ........................................ 61

Tabelle 9 - VDSL2 Profile ............................................................................................................ 62

Tabelle 10 - Übersicht Ist-Zustand Wien laut Fragebogen ............................................................ 71

Tabelle 11 - Übersicht Ist-Zustand Bregenz laut Fragebogen ....................................................... 72

Tabelle 12 - Übersicht Ist-Zustand Graz laut Fragebogen ............................................................. 73

Tabelle 13 - Übersicht Ist-Zustand Linz laut Fragebogen .............................................................. 74

Tabelle 14 - Übersicht der anzulegenden Netze ........................................................................ 109

Tabelle 15 - Spezifikationen Check Point UTM-1 1050 .............................................................. 138

Tabelle 16 - Spezifikationen Check Point UTM-1 VPN Edge W16 ............................................... 140


10

Abbildungsverzeichnis

Abbildung 1 - Bizerba Corporate Network .................................................................................. 18

Abbildung 2- Hostbasiertes IDS .................................................................................................. 28

Abbildung 3 - Netzwerkbasiertes IDS .......................................................................................... 28

Abbildung 4 - Hybrides IDS ......................................................................................................... 28

Abbildung 5 - Aufbau Global Firewall ......................................................................................... 29

Abbildung 6 - Personal Firewall .................................................................................................. 29

Abbildung 7- Load-Balancing Firewall ......................................................................................... 30

Abbildung 8 - Veranschaulichung NAT ....................................................................................... 32

Abbildung 9 - Remote Access VPN ............................................................................................. 33

Abbildung 10 - Branch Office VPN .............................................................................................. 34

Abbildung 11 - Extranet VPN ...................................................................................................... 35

Abbildung 12 - Symmetrische Verschlüsselungsverfahren ........................................................... 40

Abbildung 13 - Asymmetrisches Verschlüsselungsverfahren ........................................................ 44

Abbildung 14 - AH- und ESP-Verschlüsselung ............................................................................ 45

Abbildung 15 - Aufbau SDSL ...................................................................................................... 48

Abbildung 16 - Aufbau ADSL ...................................................................................................... 49

Abbildung 17 - Verbindungsaushandlung bei ADSL .................................................................... 51

Abbildung 18 - Aufbau einer strukturierten Verkabelung ............................................................ 54

Abbildung 19 - Class-D-Link Verkabelung ................................................................................... 55

Abbildung 20 - Aufbau ISDN ...................................................................................................... 60

Abbildung 21 - Aufbau EuroDocsis ............................................................................................. 65

Abbildung 22 - MPLS-Strecke ..................................................................................................... 66

Abbildung 23 - Überblick IST-Zustand ......................................................................................... 70

Abbildung 24- Sollzustand Bizerba Österreich ............................................................................. 77

Abbildung 25 – Firewall Struktur Wien | Bregenz ........................................................................ 78

Abbildung 26 – Firewall Struktur Graz | Linz................................................................................ 79

Abbildung 27 - Projektablaufplan ............................................................................................... 82

Abbildung 28 - Check Point UTM-1 1050 ................................................................................... 92

Abbildung 29 - Screenshot: Auswahl Rücksetzen auf Factory default .......................................... 94

Abbildung 30 – Screenshot: Authentifizierungsmaske WebGUI UTM........................................... 96

Abbildung 31 – Screenshot: Konfigurationswizard R70 ............................................................... 97

Abbildung 32 - Screenshot: Upgradeoptionsmenü auf der UTM-1 1050 ..................................... 98

Abbildung 33 - Check Point UTM-1 Edge W16 ........................................................................... 99


11

Abbildung 34 - Screenshot: Authentifizierungsmaske WebGUI Edge ......................................... 100

Abbildung 35 - Screenshot: Konfigurationsmaske WAN Verbindung Edge ................................ 101

Abbildung 36 - Screenshot: Erfolgreiche Connection zum Management ................................... 106

Abbildung 37 - Aufbau Provider-1 ............................................................................................ 107

Abbildung 38- Screenshot: Provider-1 Netzwerkübersicht ......................................................... 108

Abbildung 39 - Screenshot: Detailansicht Netzwerk anlegen im Provider-1 .............................. 109

Abbildung 40- Screenshot: Provider-1 Gruppenübersicht .......................................................... 110

Abbildung 41- Screenshot: Detailansicht Gruppe anlegen im Provider-1 ................................... 111

Abbildung 42 - Screenshot: Anlegen eines Firewall Clusters im Provider-1 ................................. 113

Abbildung 43- Screenshot: Topology Übersicht bei der Cluster Konfiguration im Provider-1 ..... 115

Abbildung 44- Screenshot: Übersicht Edges im Provider-1 ....................................................... 117

Abbildung 45 - Kartenübersicht Bizerba Wien ........................................................................... 120

Abbildung 46 - Kartenübersicht Bizerba Graz ............................................................................ 122

Abbildung 47 - Kartenübersicht Bizerba Linz ............................................................................. 123

Abbildung 48 - Kartenübersicht Bizerba Bregenz ...................................................................... 124

Abbildung 49 - Bizerba Organisationsplan ................................................................................ 142

Einleitung | Matthias Pyka a

12

1. Einleitung

In diesem Kapitel werden einleitende Themen zur Problematik beschrieben. Der Fokus wird hierbei

auf den Nutzen der Integration der Außenstellen gelegt. Eine kleine kaufmännische Betrachtung

des Projekts ist hierbei ebenfalls zu finden. Darüber hinaus wird auf die Ziele des Projekts sowie

den detailierten Aufbau dieser Arbeit eingegangen.

1.1 Nutzen der Integration

Es gibt viele Gründe welche für eine Integration der Außenstellen, wie sie im Bizerba Masterplan

vorgesehen sind, sprechen. Das im Masterplan vorgegebene SAP Rollout ist einer der wesentlichen

Gründe für den globalen Ausbau der Netzwerkinfrastruktur. Durch die Einführung von SAP als

global eingesetzte Unternehmenssoftware können die Verantwortlichen schneller auf betriebswirt-

schaftliche Probleme reagieren. Die Transparenz des Gesamtunternehmens wird größer und der

Konzernjahresabschluss kann mittels einer Business Warehouse Lösung bequemer und schneller

abgewickelt werden. Aus IT-technischer Sicht können durch das zentrale SAP Datacenter, welches

sich in Balingen befindet, Kosten für Server und Serverlizenzen eingespart werden. Die Außenstel-

lenmitarbeiter arbeiten über das Internet auf den SAP Servern in Balingen. Auch der Support und

die Pflege der Server werden durch die Zentralisierung vereinfacht. Anstelle viele Server weltweit

pflegen und administrieren zu müssen, können die SAP Server im Bizerba Datacenter einfacher

überwacht und gepflegt werden, da diese physikalisch in greifbarer Nähe der verantwortlichen

System-Engineers stehen. Ausnahmen hierfür sind Produktionsstandorte in Übersee wie in China

oder Mexiko, welche verbindungstechnisch nur schwierig mit entsprechender Performance zu

versorgen sind. Aus diesem Grund werden an diesen Standorten lokale Server für den SAP –

Betrieb eingesetzt.

Das im Moment sich noch im Einsatz befindende EUDAT-System, welches voraussichtlich erst im

Jahr 2011 abgelöst wird, erhält durch die Integration in das Bizerba Corporate Network eine deut-

lich verbesserte Datensicherungsstruktur. So ist es bei einem Ausfall der Hardware möglich inner-

halb eines kurzen Zeitraumes ein Backup System in Balingen zu generieren auf welchem die Mitar-

beiter der Bizerba Österreich arbeiten können.


13

Ein weiterer Vorteil der Zentralisierung ist, dass das Know How, welches die System-Engineers im

Datacenter in Balingen besitzen und täglich anwenden, nicht mühevoll in die Außenstellen getra-

gen werden muss, wo es meist nur selten zum Einsatz kommt. Daher ist der Support welcher

durch die IT-ServiceDesk Mitarbeiter und die System-Engineers durchgeführt wird besser und

schneller gewährleistet.

Diese IT-technischen Vorteile eines globalen Netzwerkes sind beim Microsoft Exchange Service

sowie beim Service Informations System und vielen weiteren global eingesetzten Diensten iden-

tisch zu den Vorteilen des SAP Rollouts. Der Nutzen für den User eines globalen Microsoft Exchan-

ge Systems ist ein schneller Zugriff auf die Unternehmenskontaktdaten der Mitarbeiter, Erleichte-

rung bei der Organisation von Meetings, und vieles mehr. Durch die einheitliche Verwendung von

Exchange können die Mitarbeiter zukünftig auch den Service Outlook Anyware nutzen.

Neben SAP werden auch weitere Core Applikationen wie Microsoft CRM/CAS in der Auslandsge-

sellschaft eingeführt. Welche in Kombination mit der Service Informationssystem Prozessabläufe

der sich im Außendienst befindlichen Mitarbeiter verbessert.

Durch die weltweite Nutzung des Service Informationssystems kann ein identischer Kunden-

Service gewährleistet werden. Durch das Service Informationssystem können Servicetechniker

koordiniert werden. Diesen stehen über das System immer neueste Firmware, Pläne und andere

nützliche Dokumente für ihre tägliche Arbeit bereit. Durch die gemeinsame Arbeit an Projekten

auf entsprechenden Projektservern, sowie gezieltem Wissensmanagement über Portale lassen sich

einfach Synergieeffekte erzielen. Auch die Unternehmenskommunikation kann durch eine globale

Vernetzung verbessert werden, was die Mitarbeiterzufriedenheit steigert, sowie wichtige Informa-

tionen und Arbeitsanweisungen schneller verbreitet.

Ein weiterer Vorteil ist die Möglichkeit des Softwaresharings. Durch Softwaresharing ist es möglich

teure und selten benötigte Programme den Mitarbeiten via Remoteverbindung zu einem Rechner,

auf welchem die entsprechenden Programme installiert sind, zur Verfügung zu stellen. So werden

Ressourcen auf den lokalen PCs sowie Lizenzkosten gespart. Auch bei der Softwarelizenzverwal-

tung kann durch eine globale Vernetzung besser gearbeitet werden.

Durch Systeme wie Microsoft System Center Configuration Manager oder Symantec Altiris kann

Software gezielt verwaltet werden sowie mittels Systemabfragen der Status der vergebenen bzw.-

offenen Lizenzen herausgefunden werden.


14

Durch die Vernetzung steigt auch die Sicherheit in einem Unternehmen. Als großer Netzwerkver-

bund können aktuelle Sicherheitsupdates, Virenscanner, usw. immer auf dem neusten Stand ge-

halten werden. Durch große Firewall-Systeme wird das Netzwerk nach außen hin geschützt. Ziel

ist der Einsatz einer globalen Firewall Policy welche bizerbaweit gültig ist. Die Gefahr von Innen

wird durch Virenscanner und andere sicherheitsrelevante Maßnahmen, wie z.B. die Verwendung

von URL- und Email-Filtern, minimiert.

Konfliktmanagement ist ebenfalls ein wichtiger Punkt bei der Anbindung an Landesgesellschaften.

Nach der Anbindung liegt die volle Verantwortung für die IT-Infrastruktur bei den Verantwortli-

chen Datacenter Mitarbeitern im Headquarter. Aus diesem Grund muss genau festgelegt sein wel-

cher Mitarbeiter für was verantwortlich ist um einen möglichst reibungslosen Betrieb zu garantie-

ren bzw. eine schnelle Fehlerbehebung zu gewährleisten. Natürlich müssen die Organisationspro-

zesse entsprechend an die Vernetzung des Unternehmens angepasst werden um effizient die Vor-

teile des globalen Netzwerks nutzen zu können. 1

Vgl.: 1 [tebMP]


15

1.2 Kosten-Nutzen-Analyse

Die folgende Kosten-Nutzen-Analyse bezieht sich auf den aktuellen Projektabschnitt. Die hier ver-

wendeten Zahlen sind fiktiv angenommene Werte, da die Bizerba GmbH & Co. KG ihre internen

Verrechnungssätze nicht veröffentlicht. Die hier angenommenen Werte stimmen im Verhältnis zu

den weiteren Kosten in etwa mit den realen Werten überein

1.2.1 Kosten des Projektabschnittes

Bezeichnung Menge Preis / Einheit Gesamtpreis

Firewall Check Point UTM-1 1050 Master Lizenz 1 St 4.200,- 4.200,-

Firewall Check Point UTM-1 1050 Slave Lizenz 1 St 2.800,- 2.800,-

Firewall Check Point UTM-1Edge W16 3 St 500,- 1.500,-

HP Microsoft Domänencontroller 1 St 4.000,- 4.000,-

Vorbereitungskosten 30 MT 480,- 14.400,-

Installationskosten Wien 9 MT 480,- 4.320,-

Installationskosten Bregenz 2 MT 480,- 960,-

Installationskosten Graz 1 MT 480,- 480,-

Installationskosten Linz 1 MT 480,- 480,-

Flugkosten 7 St 250,- 1.750,-

Übernachtungskosten 14 St 70,- 980,-

Nachbereitungskosten 25 MT 480,- 12.000,-

Gesamtkosten 47.870,-

Tabelle 1 - Kosten der Integration

1.2.2 Nutzen des Projektabschnittes

1.2.2.1 Notfall-Infrastruktur für das EUDAT System

Bislang wurden 5 Tage für den Restore des EUDAT-Systems bei 40 betroffenen Mitarbeitern ver-

anschlagt. Durch die Integration beträgt der Restore Zeitraum nur noch 3 Tage.


Ausfallzeit vor der Integration 200 MT 480,- 96.000,-

Ausfallzeit nach der Integration 120 MT 480,- 57.600,-

Ersparnis 38.400,-

Tabelle 2 - Ausfallzeit des EUDAT Systems


16

1.2.2.2 Zentrale Administration der IT Infrastruktur

Durch die zentrale Administration wird der komplette Second-Level Service nach Balingen verla-

gert. Die Mitarbeiter des IT ServiceDesk haben nun die Möglichkeit per Remote Access die Benut-

zer in Österreich direkt zu unterstützen. Die Administration der Firewall, der Microsoft Domäne,

der Exchange Postfächer sowie die Datensicherung gehen komplett in die Verantwortung der

Bizerba Global IT. Durch diese Schritte können kostspielige Serviceverträge bei externen Dienstleis-

tern abgelöst, sowie Mitarbeiter, welche primär andere Aufgaben im Bizerba Umfeld zu erledigen

haben, entlastet werden.


Service Vertrag Administration 1 St 14.000,-

Backup / Restore pro Jahr 36 MT 480,- 17.280,-

Second Level Support 12 MT 480,- 5.760,-

Kosten 37.040,-

Tabelle 3 - Kosten der Administration vor der Integration


Firewall Administration pro Jahr 3 MT 480,- 1.440,-

Microsoft Domänen Administration pro Jahr 12 MT 480,- 5.760,-

Exchange Administration pro Jahr 12 MT 480,- 5.760,-

Backup / Restore pro Jahr 36 MT 480,- 17.280,-

Second Level Support 12 MT 480,- 5.760,-

Kosten 36.000,-

Tabelle 4 - Kosten der Administration nach der Integration

Bezeichnung Gesamtpreis

Administration vor der Integration 37.040,-

Administration nach der Integration 36.000,-

Ersparnis 1.040,-

Tabelle 5 - Gegenüberstellung der Administrationskosten

1.2.2.3 Voraussetzung für die Einführung von SIS, CAS/CRM, SAP

Ein weiterer großer Nutzen, welcher nicht direkt finanziell abgewogen werden kann ist die Wei-

chenstellung für die Einführung von SIS, CAS/CRM sowie SAP. Durch die Einführung dieser Syste-

me werden Prozesse optimiert, so dass Bizerba effektiver, schneller und serviceorientierter arbeiten

kann. Diese Faktoren werden sich auch in finanzieller Sicht positiv für das Unternehmen auswir-

ken.


17

1.2.2.4 Improvements durch die Integration

Reine Nutzengewinne durch die Integration ist die Nutzung des VPN Access. So können Außen-

dienstmitarbeiter auch von Unterwegs oder von zu Hause aufs Bizerba Firmennetzwerk zugreifen

und haben keinerlei Einschränkungen gegenüber der Dienste die sie von ihrem Büro aus wahr-

nehmen können. Ein weiterer großer Vorteil durch die Integration ist die Nutzung von Outlook

Anyware. Für die Abfrage der Email sowie der weitern Services die Microsoft Exchange bietet, wie

z.B. die Kalenderfunktion ist von Extern kein VPN Zugriff auf das Unternehmensnetzwerk nötig.

Der User kann diese Services einfach über einen Browser an einem öffentlichen Internet PC aufru-

fen.

1.2.3 Gegenüberstellung der Kosten und des Nutzens des Projektabschnittes

In der folgenden Aufstellung werden Kosten und Nutzen der netzwerktechnischen Integration

gegenübergestellt. Da nicht alle Punkte dieses Vergleiches finanziell direkt aufwiegbar sind, wird

ist es im Moment nicht möglich die direkte Ersparnis durch die Integration darzustellen. Jedoch

überwiegt der Nutzen gegenüber den Kosten deutlich. Der Mehrwert für die Landesgesellschaft ist

anhand der folgenden Aufstellung gut ablesbar. So amortisieren sich die bislang angefallenen Kos-

ten gegenüber den monetär ausdrückbaren Nutzen nach etwa einem Jahr und zwei Monaten.

Kosten Betrag Nutzen Ersparnis

Kosten der Integration 47.870,- Notfall Infrastruktur EUDAT 38.400,-

Zentrale Administration 1.040,-

Voraussetzung für die Einführung von SIS,

CAS/CRM, SAP

Improvements durch die

Integration

Kosten 47.870 Ersparnis 39.440,-

Tabelle 6 - Gegenüberstellung von Kosten und Nutzen


18

1.3 Zielsetzung

Ziel dieses Projekts ist die netzwerktechnische Integration der Bizerba Landesgesellschaft Öster-

reich. Bei dieser, der ersten, Ausbaustufe wird das Headquarter der Bizerba Österreich, welches in

Wien beheimatet ist, sowie die drei größten Außenstellen, Bregenz, Graz und Linz netzwerktech-

nisch in das Bizerba Corporate Network integriert. Hierfür müssen sämtliche Netze im Firewall-

Management angelegt sowie diese in den entsprechenden Gruppen der globalen Bizerba Firewall-

Regeln integriert werden. Darüber hinaus werden die Systeme vor Ort installiert sowie die vorhan-

denen Netzwerkstrukturen angepasst, die Arbeitsplatzcomputer an die Microsoft Domäne ge-

nommen und entsprechende Anpassungen am Firewall-Regelwerk für Bizerba Österreich durchge-

führt. Durch die Netzwerktechnische Integration wird die Basis für das SAP – Rollout, die SIS-

Einführung sowie die Einführung von CRM/CAS am Standort Österreich gelegt. Das in Österreich

verwendete EUDAT-System, welches bis zur Einführung von SAP bestehen bleibt, muss durch eine

gezielte Backupstruktur gesichert werden. So dass im Falle eines Systemausfalls zeitnah ein

Backupsystem initialisiert werden kann.

Abbildung 1 - Bizerba Corporate Network


19

1.4 Aufbau der Bachelor-Thesis

Die Arbeit ist in sechs Hauptkapitel aufgebaut. Im ersten Kapitel werden einleitende Themen rund

um das Projekt betrachtet. Im folgenden zweiten Kapitel werden die bei der Umsetzung des Pro-

jekts verwendeten Technologien in den Fokus gerückt. Hierbei werden im speziellen die verwende-

ten Soft- und Hardwaretools beschrieben, Informationen über die verwendete Telekommunikati-

onsanbindung gegeben, sowie Einblicke in die Arbeitsweise einer Firewall die angewandten Ver-

schlüsselungsverfahren und die dabei verwendeten Protokolle gegeben. In diesem Kapitel werden

auch alternative Lösungsansätze im Bereich der Telekommunikationsanbindung aufgezeigt.

Das dritte Kapitel beschäftigt sich mit vorbereitenden Analysen und Vergleiche. So werden hier

wichtige Gesichtspunkte wie Ist-Zustandsanalyse, Soll-Konzeption sowie Ressourcenplanung und

eine Securityanalyse des Systems durchgeführt.

Die Projektumsetzung ist Thema des vierten Kapitels. Hier werden detailiert die Konfiguration der

Hardware, des Managements sowie die Installation in Österreich thematisiert. Auch auftretende

Fehler während des Rollouts werden hier aufgeführt und erklärt.

Das fünfte Kapitel schließt die Thesis mit einem Fazit sowie einem Ausblick auf die kommenden

Aufgaben ab. Es wird noch einmal zusammenfassend das Projekt beschrieben und erläutert.

Im Anhang folgen weiter Informationen zum Thema, sowie einen kleine Übersicht über die

Bizerba GmbH & Co. KG. Neben diesen Themen sind im Anhang noch weiter Verzeichnisse wie

Quellen und Literaturangaben, ein Abkürzungsverzeichnis sowie ein Glossar zu finden.

Abschließend ist noch folgendes zum Aufbau des Layouts dieser Arbeit zu sagen. Sämtliche Über-

schriftsebenen sind blau markiert. Befehls- sowie Parametereingaben werden immer in grün her-

vorgehoben. Quellenangaben in Fußnoten sowie Verweise Anhänge werden in grau formatiert.

Fußnoten werden hierbei kursiv geschrieben, Querverweise auf Abbildungen / Tabellen oder Text-

abschnitte werden hingegen in Eckige Klammern (z.B. [siehe Abbildung]) gefasst.

Verwendete Technologien | Matthias Pyka a

20

2. Verwendete Technologien

In diesem Kapitel werden die für das Projekt relevanten Techniken vorgestellt. Auf einzelne Details

der hier beschriebenen Technologien referenziere ich mich später im Kapitel »Projektumsetzung«.

Im folgenden Kapitel werden neben Firewall- und Verschlüsselungsgrundlagen auch Protokolle,

Übertragungs- sowie Verkabelungstechniken angesprochen. Darüber hinaus möchte ich in diesem

Kapitel auf alternative Lösungsmöglichkeiten bei der Anbindung von Außenstellen eingehen.

Die folgenden Hard- und Softwarekomponenten haben während des Projekts eine wichtige Rolle

zur Umsetzung gespielt.

2.1 Verwendete Soft- und Hardware

2.1.1 Software:

2.1.1.1 Check Point Provider -1

Bei der Software Check Point Provider -1 handelt es sich um ein globales Management Tool zur

zentralen Verwaltung von Firewall Systemen. Über dieses System werden sowohl Globale Firewall-

Regeln wie auch Ausnahmen / spezielle Regeln für einzelne Maschinen definiert. Auch die Kom-

munikation der Firewalls untereinander wird zentral über das Provider-1 System geregelt. Zusätz-

lich bietet dieses System umfangreiche System-Monitoring-Tools für die Überwachung der Fire-

wall-System, sowie der VPN-Tunnel und anderen Verbindungen.

2.1.1.2 Check Point R70

Beim Release 70 der Check Point Software welche auch auf der UTM-1 1050 eingesetzt wird dreht

es sich um die jüngste Version der Firewall Software. Die hardwareseitige Konfiguration des Sys-

tems läuft ebenfalls komplett über dieses Firewall Betriebssystem. Das System basiert auf einem

RedHat Linux System, welches von Check Point stark verschlankt und vereinfacht wurde um mög-

lichen Sicherheitslücken vorzubeugen.


21

2.1.1.3 Check Point V8.0.33

Dieses Softwareprodukt wird auf allen Edge Systemen welche Bizerba einsetzt verwendet. So auch

auf den Check Point UTM-1 Edge W16, wie sie in den kleineren österreichischen Lokationen ver-

wendet werden. Auf diesem System werden sämtliche Konfigurationen die Hardwareseitig nötig

sind, vorgenommen.

2.1.1.4 Microsoft Internet Explorer 8

Der Internet Explorer 8 ist die jüngste Version des Internet Browsers aus dem Hause Microsoft. Mit

Hilfe dieses Browsers wird der Zugriff auf das Web Interface der Firewall-Systeme getätigt. Neben

dem Zugriff auf die Firewall wird mit diesem Tool auch die Internetverbindung der Lokationen

getestet. Auch für Recherchezwecke rund um das Projekt sowie die wissenschaftliche Ausarbei-

tung, wurde dieses Tool verwendet.

2.1.1.5 Microsoft Office Outlook 2007

Microsoft Outlook ist das bekannte Groupware System welches mit dem Microsoft Exchange Ser-

ver eine Einheit bildet. Das System wurde im Projekt nicht nur für die Email Kommunikation ge-

nutzt sondern auch mittels der Kalenderfunktion zur Abstimmung von Terminen.

2.1.1.6 Microsoft Office Power Point 2007

Microsoft Office Power Point wird zur Erstellung der Kolloquiumspräsentation als Vorführwerk-

zeug verwendet. Hierbei handelt es sich um einen quasi Industriestandart, der global in nahezu

sämtlichen Unternehmen eingesetzt wird.

2.1.1.7 Microsoft Office Project 2003

Mit Hilfe dieses Tools wurden die Ressourcenplanung sowie der Projektablaufplan definiert.

[siehe auch S.80 - Projektplanung]

2.1.1.8 Microsoft Office Visio 2007

Microsofts Visio ist eine Visualisierungssoftware welche während des Projekts zur Zeichnung von

verschiedenen Zuständen der Lokationen sowie zur Veranschaulichung einiger Themen genutzt

wird. Vornehmlich wurde das Tool für die Erstellung von Grafiken für die wissenschaftliche Ausar-

beitung genutzt.

2.1.1.9 Microsoft Office Word 2007

Das Textverarbeitungsprogramm Microsoft Office Word 2007 wurde zur Erstellung dieser Bachelor

Thesis sowie zur Dokumentation von Konfigurations- und Installationsanleitungen rund um das

Projekt verwendet.


22

2.1.1.10 Microsoft Windows Kommandozeile

Netzwerkbefehle wie »ping«, »nslookup« oder »tracrt« werden für die Installation sowie den Test

von Verbindungen oft verwendet. Diese Werkzeuge sind als Befehle in Microsoft Windows Kom-

mandozeile standardmäßig integriert und können über diese aufgerufen werden. Auch die Be-

fehlsfamilie »ipconfig« wird während der Projektumsetzung sehr oft benötigt um zu prüfen ob die

Netzwerkkarte die richtige IP Adresse besitzt und um diese entsprechend zu konfigurieren.

2.1.1.11 Microsoft Remote Desktop

Das Microsoft Remote Desktop Tool, ist wie die Kommandozeile ein fester Bestanteil in Windows

XP Professional. Mit Hilfe dieses Programms ist es möglich sich über einen Fernzugriff auf einen

Server oder andern Computer aufzuschalten. Während des Projekts wurde dieses Tool verwendet

um auf den Management PC, welcher auf den Firewall Management Server zugreifen darf, zuzug-

reifen um die entsprechenden Geräte und Netze zu installieren und zu konfigurieren, bzw. gege-

benenfalls Firewall Regeln zu ändern oder neu zu definieren.

2.1.1.12 Microsoft Windows XP Professional

Das im Jahr 2001 eingeführte Windows XP wird auch heute noch in vielen Unternehmen verwen-

det und erst in den kommenden Monaten durch Windows 7 ersetzt werden. Sehr viele Unterneh-

men habend das dazwischen veröffentlichte Windows Vista aufgrund von Performanceproblemen

übersprungen um direkt von Windows XP auf Windows 7 zu wechseln.

2.1.1.13 PuTTY

Bei PuTTY handelt es sich um ein Freeware Tool mit welchem es möglich ist mittels eines Telnet-

oder SSH-Zugriffs auf ein verbundenes Gerät zuzugreifen. Im Projektbetrieb wurde das Tool ge-

nutzt um eine SSH-Verbindung zu den Firewalls aufzubauen um dieses zu konfigurieren oder auf

den Auslieferungszustand zurück zu setzen.


23

2.1.2 Hardware:

2.1.2.1 Fluke Networks NetTool Series II

Beim Fluke Networks NetTool Series II handelt es sich um ein kompaktes Messgerät zur Diagnose

von Verbindungen innerhalb eines Netzwerks. Zum Funktionsumfang gehören die Diagnose von

Verbindungsproblemen, Messen der Netzwerkgeschwindigkeit und der Signalqualität, prüfen von

PoE Systemen, Diagnose von VoIP Netzen sowie die Erkennung verfügbarer Netzwerkressourcen.

Während des Projekts wurde das Gerät zur Messung von Netzwerkgeschwindigkeiten sowie zur

Überprüfung der Signalqualität in den Lokationen verwendet.

2.1.2.2 HP-Compaq 6910p

Das HP-Compaq 6910p ist ein Businessnotebook, mit einer 14,1 Zoll Bildschirmdiagonale. Das

Gerät verfügt über einen Intel Centrino vPro Chipsatz, einen Core2Duo Prozessor, welcher eben-

falls aus dem Hause Intel stammt, sowie über 4 GB Arbeits- und 120 GB Festplattenspeicher. Mit

diesem Gerät wurden sowohl große Teile des Projekts bearbeitet als auch die Schriftliche Ausar-

beitung erstellt.

2.1.2.3 Check Point UTM-1Edge W16

Die Check Point UTM-1 Edge W16 ist eine kleine Firewall, die in den Lokationen in Linz, Graz und

Bregenz eingesetzt wird. [siehe auch S.136 - Spezifikationen der eingesetzten Firewall-Typen]

2.1.2.4 Check Point UTM -1 1050

Das in Wien verwendete Firewall Cluster besteht aus zwei Check Point UTM-1 1050 Modulen.

[siehe auch S. 136 - Spezifikationen der eingesetzten Firewall-Typen]


24

2.2 Firewall Techniken

Firewall-Systeme sind für die Sicherheit eines Unternehmensnetzwerks von äußerster Relevanz.

Ihre Aufgabe ist die Überwachung sämtlicher eingehender und ausgehender Kommunikationsver-

bindungen. Hierbei werden nicht autorisierte Zugriffe, welche über Regeln festgestellt werden,

von der Firewall geblockt. Je nach Anwendungsbereich können Firewalls sowohl als Software-,

Hardware- oder als kombinierte Lösung eingesetzt werden. Bei den meisten professionell einge-

setzten Firewall-Typen handelt es sich um Hybridlösungen, welche mehrere Technologien verbin-

den. Der Einsatz verschiedener Technologien und damit der Wandel einer Firewall als Security In-

stanz zur Security Plattform ist auf die stetige Steigerung der Anforderung an ein Firewall-System

zurückzuführen. Bei den gesteigerten Anforderungen eines Firewall-Systems handelt es sich auch

um Zugriffe von Außen, welche für Unternehmen heute eine große Rolle spielen. Neben den eige-

nen Mitarbeitern, welche sich im Außendienst befinden, müssen auch für komplette Niederlassun-

gen, Partner, Lieferanten und Kunden Möglichkeiten geschaffen werden auf spezielle Teile des

Unternehmensnetzwerks zugreifen zu können. Ein weiterer Grund für die deutlich gesteigerten

Anforderungen eines Firewall Systems können auch sehr schön an einer Statistik aus der Zeitschrift

»Informationsweek« abgelesen werden. So beträgt der prozentuale Anteil der Internen Angreifer

auf ein Firmennetzwerk 71% (47% autorisierte Mitarbeiter; 24% nicht autorisierte Mitarbeiter).

Weiter 13% der Angriffe geschehen durch ehemalige Mitarbeiter. Der Anteil an Hacker und Terro-

risten, welche von Außen Firmennetzwerke angreifen, beträgt ebenfalls 13%. Die Zahl der Angrif-

fe durch Wettbewerber ist verhältnismäßig gering und beträgt etwa 3%.

Firewalls können sowohl rein Softwarebasiert als PC, als spezialisierte Hardware, oder als Gemisch-

te Variante, also als PC mit spezieller Firewall-Karte auftauchen. Die rein PC-basierte Lösung ist

zwar die kostengünstigste Lösung, jedoch ist sie Performancetechnisch die langsamste. Der PC mit

spezieller Firewall-Karte ist etwas schneller, aber dafür auch teurer. Die mit Abstand beste Perfor-

mance bietet die spezialisierte Hardware. Sie ist zwar die teuerste Lösung, dafür aber die mit Ab-

stand performanteste sowie sicherste, da die Hardware von Grund auf für das System konzipiert

ist. Varianten von dieser Hardwarefirewall sind sogenannte Firewall Blades sowie Virtual Firewalls,

welche weitere Firewalls innerhalb ihrer Hardware virtualisieren.

Im Bereich der Security Policies gibt es generell zwei Verfahren: »Alles was nicht ausdrücklich ver-

boten ist, ist erlaubt« bzw. »Alles was nicht ausdrücklich erlaubt ist, ist verboten«. 2 3 4

Vgl.: 2 [cpNGX]

3 [wikiFW]

4 [rehIW]


25

2.2.1 Entstehungshistorie der Firewall

Der Begriff Firewall, frei übersetzt »Feuerwand«, kommt ursprünglich aus der Gebäudeplanung.

Firewalls haben die Aufgabe Brandabschnitte sicher von einander zu trennen, damit das Feuer

nicht in einen anderen Bereich übersetzen kann. Andere Beispiele für Firewalls sind z.B. die Metall-

zwischendecken bei Flugzeugen, welche Antriebskomponenten von den Passagieren trennt. Als in

den 1980er Jahren das Internet global verfügbar wurde, wurden Router zur Trennung von Netz-

werken eingesetzt. Die Idee des Internets, welche ursprünglich für einen virtuellen Ort der Offen-

heit, des Austausches und der Zusammenarbeit deklariert wurde, wurde in den späten 1980ern

durch einige Schwerwiegende Angriffe zerstört. Der Hauptinitiator der Entwicklung von Firewall

Systemen war der 1988 auftretende Morris Wurm, welcher die Universität von Berkeley, UC San

Diego, Lawrence Livermore, Stanford und das NASA Forschungszentrum infizierte. Daraufhin wur-

den noch im selben Jahr die ersten Paketfilter von der US-Firma DEC entwickelt. Verantwortliche

Entwickler dieses Projekts waren Bill Cheswick und Steve Ballovin. In den AT&T Bell Labs haben die

beiden Entwickler die Forschungen an diesem System weitergeführt und auf Basis Ihres ersten

Entwurfs bei der Firm DEC eine Verbesserung der ersten Firewall-Generation entwickelt. Diese

Generation wurde bei AT&T Bell auch produktiv eingesetzt. Von 1989 bis 1990 entwickelten die

AT&T Bell Laboratories Angestellten Dave Presetto, Janardan Sharma und Kshitij Nigam eine zwei-

te Firewall-Generation welche sie »Circuit Level Firewalls« nannten. Im Jahre 1992 wurde das

komplette Firewall-Konzept von den Mitarbeitern der University of Southern California, Bob Bra-

den und Annette DeSchon verfeinert. Das daraus resultierende Produkt, namens »Visas« war das

erste Firewall-System welches einfach auf Betriebssystemen wie Microsoft Windows oder Apple

MacOS implementiert werden konnten. 1994 brachte die israelische Firma Check Point basierend

auf diesem System die Fire Wall-1 auf den Markt.5

Übersicht über die Entwicklungshistorie der Firewall:

� 1988 – Entwicklung der ersten Paketfilter durch DEC

� 1989 -1990 – Weiterentwicklung zur Circuit Level Firewall

� 1992 – Veröffentlichung von »Visas«

� 1994 – Check Point FireWall-1

Vgl.: 5 [wikiFW]


26

2.2.2 Firewall-Architekturen

2.2.2.1 Paketfilter (packet screen) Architektur (Stateless / Stateful Firewall)

Paketfilter Firewalls blockieren Übertragungen bestimmter Verkehrsklassen. Das bedeutet, dass

ein- und ausgehende IP-Pakete von der Firewall nach verschiedenen Kriterien untersucht werden.

Überprüft werden die Quell- und Ziel-IP-Adresse sowie die Quell- oder Ziel-TCP/UDP-Port-Nummer.

Bei dieser Firewall-Architektur werden lediglich die IP-Header überprüft. Die mit dem IP-Paket

übermittelten Daten werden unkontrolliert weitergeleitet, insofern die Kontrolle des IP-Headers

erfolgreich war. IP-Pakete mit inkorrekten Headern werden von der Firewall geblockt.6 7

2.2.2.2 Stateful Inspection Architektur

Bei der Stateful Inspection Architektur handelt es sich um eine Erweiterung der packet screen

Technologie. Bei dieser Filterungsmethode werden jedoch zusätzliche Informationen aus den IP-

Paketen geprüft, was die Sicherheit dieses Systems erhöht. Neben dem IP-Header wird bei Stateful

Inspection auch die Header-IP-Option sowie die Flags innerhalb des IP-Pakets überprüft. Dadurch

wird gewährleistet, dass das übermittelte IP-Paket Teil einer autorisierten Datenverbindung ist.

Zusätzlich ist es Stateful Inspection in der Lage NAT-Services bereit zu stellen.8 9

2.2.2.3 Stealth Firewall (Bridging Firewall)

Die Stealth-Firewall, welche auch Bridging-Firewalls oder Layer-2-Firewalls genannt werden,

überwacht sämtliche Bridge-Kopplungen der LAN-Segmente. Der große Vorteil der Stealth-

Firewall ist, dass sie für Angreifer auf Ebene des IP-Bereichs (ISO/OSI-Schichtenmodell Schicht 3,

TCP/IP-Schichtenmodell 2), nicht sichtbar in den Kommunikationsstrom eingebunden ist. Stealth-

Firewalls können daher lediglich indirekt über Fehler im Stealth-Code angegriffen werden. Der

Nachteil von Stealth-Firewalls ist hingegen dass diese lediglich als statischer Paketfilter fungieren

können, da Ihnen der Zugriff auf höhere Schichten nicht erlaubt wird. Aufgrund dessen findet

man heute Stealth-Firewalls meist nur noch als Zusatzfunktion bei Switchen. Als dedizierte Fire-

walls hingegen findet man heute nur noch äußerst selten Stealth-Firewalls. 10 11

2.2.2.4 Circuit-Level-Gateway

Die Circuit-Level-Gateway Architektur wird die Synchronisation der Übertragung, das sogenannte

Handshaking überprüft. Hierdurch werden nur autorisierte Verbindungen zugelassen. Der laufende

Vgl.: 6 [wikiFW]

7 [pchFW]

8 [pchFW]

9 [wikiFW]

10[wikiFW]

11 [itAdFW]


27

Datenverkehr wird beim Circuit-Level-Gateway nicht überprüft, jedoch werden sämtliche aktive

autorisierte Verbindungen aufgezeichnet. Der Datenverkehr kann bei diesem Firewall-Typ lediglich

über diese Verbindungen erfolgen. Von außen betrachtet ist bei diesem Typ lediglich ein Gateway

zu sehen. 12

2.2.2.5 Intrusion Detection

Etwa 90% sämtlicher Verstöße, welche auf einer Firewall aufschlagen, kommen aus dem eigenen

Netzwerk. Die automatisierte Erkennung dieser Verstöße welche sich sowohl gegen speziell defi-

nierte Systeme, als auch gegen das gesamte Netzwerk richtet ist Aufgabe der Intrusion Detection.

Falls das System einen entsprechenden Verstoß erkennt, löst diese eine Alert-Message aus und

passt z.B. die Firewall-Konfiguration gezielt an den Angriffsversuch an. Typische Angriffsverfahren,

welche ein Intrusion Detection System erkennt und abwehrt, sind Ping of Death sowie Denial of

Service Attacken. Identifiziert werden diese Angriffe mittels Erkennungs-Mechanismen wie der

statischen Erkennung anhand von Mustern. Bei Intrusion Detection gibt es drei verschiedene

Architekturen. Zum einen die Host-basierte Architektur, zum anderen eine Netzwerk-basierte

Architektur. Der dritte Architekturansatz ist eine hybride Lösung aus den beiden vorhin genannten

Lösungen. Beim Host-Basierten IDS muss das IDS auf jedem zu überwachenden System installiert

sein. Der Begriff Host steht hierbei für jedes einzelne zu überwachende System im Netzwerk. Das

Host basierte IDS muss vom verwendeten Betriebssystem unterstützt werden. Das HIDS greift bei

seiner Auswertung auf OS Spezifische Daten wie Log-Dateien, Kernel-Data, sowie Systemdaten,

wie die Registry zu. Sobald das System einen Angriff über die von System überwachten Daten

feststellt alarmiert dieses den Administrator. Vorteil der Host-Basierten Intrusion Detection sind die

sehr spezifischen Aussagen über die erfolgten Angriff. Ein weiterer Vorteil ist die umfassende Sys-

temüberwachung, welche durch dieses System realisiert werden kann. Nachteil dieser Firewall-

Form ist, dass diese mittels DoS-Angriffen ausgehebelt werden können. Ein weiterer Nachteil ist,

dass das System keine doppelte Integrität besitzt, was bedeutet, dass wenn ein System ausfällt,

das ganze HIDS lahm gelegt ist. Die zweite Architektur, das Netzwerkbasierte IDS zeichnet sämtli-

che Netzwerkaktivitäten auf, analysiert diese und meldet schließlich verdächtige Aktivitäten. Zu-

sätzlich wird von der NIDS versucht Angriffsmuster zu erkennen. Mittels eines Sensors kann der

komplette TCP/IP Datentransfer eines Netzsegments überwacht werden. Jedoch kommen die Sen-

soren aufgrund der hohen Datenmenge welche 1GBit/s und mehr betragen kann, mit der Analyse

nicht mehr lückenlos nach. Daher müssen Pakete verworfen werden was die Überwachung ein-

schränkt. Vorteile dieser Methode sind dass ein Sensor ein komplettes Netzwerksegment überwa-

chen kann sowie, dass das der Ausfall eines einzelnen Hostsystems die Arbeit des Sensors nicht

unterbricht. Im Gegenzug stehen folgende Nachteile im Raum: Sowohl bei Netzwerken mit hoher

Vgl.: 12

[itAdFW]


28

Bandbreite, als auch bei geswitchten Netzwerken kann kein lückenlose Überwachung statt finden.

Hybride IDS kombinieren NIDS und HIDS und sind somit eine sichere Alternative, da beim Ausfall

des HIDS immer noch das NIDS die Überwachung abwickelt.13 14

Abbildung 2- Hostbasiertes IDS

Abbildung 3 - Netzwerkbasiertes IDS

Abbildung 4 - Hybrides IDS

2.2.2.6 Application-Level-Gateway

Beim Application-Level-Gateway-System, welches auch bekannt unter der Bezeichnung Full-

Application-Inspection-System ist, handelt es sich um eine einzelne Maschine bzw. mehrere Ma-

schinen, welche Applikationsdienste zur Verfügung stellen. Das Gateway filtert die kompletten IP-

Pakete, was bedeutet, dass sowohl der IP-Header, als auch das gesendete Datenpaket überprüft

werden. Für doppelte Sicherheit sorgt, dass nur Verbindungen, welche sich anhand der vordefi-

nierten Regeln authentifizieren, zugelassen werden. Desweiteren müssen die korrekten Befehle

und Spezifikationen des Anwendungsprotokolls ausgeführt werden. Darüber hinaus fungiert das

Application-Level-Gateway als Proxy. Daher werden keine direkten Verbindungen zwischen Host-

und Remote-Computer zugelassen. Allgemein bietet dieser Firewall-Typ die größte Sicherheit.15 16

Vgl.: 13

[pchFW] 14

[wikiFW]

15

[pchFW] 16

[wikiFW]


29

2.2.2.7 Global Firewall

Eine Global Firewall wird direkt am Eingangspunkt des Netzwerkes installiert. Ihre Aufgabe ist es

die Übertragung gezielt ausgewählter Verkehrsklassen zu blockieren.17

Abbildung 5 - Aufbau Global Firewall

2.2.2.8 Personal Firewall

Eine Global Firewall wird am Netzeingang installiert und blockiert gezielt Übertragungen bestimm-

ter Verkehrsklassen. Bei einer Personalfirewall handelt es sich um keine komplette Netzwerkein-

heit, sondern um eine reine Softwarefirewall. Die Personalfirewall schütz kein komplettes Netz-

werk, sondern lediglich den Rechner, auf welchem sie installiert ist. Personal Firewalls kontrollieren

sämtliche eingehende und ausgehende Datenpakete und blocken gegebenenfalls schädliche Pake-

te ab. Eine weitere Kernaufgabe der Personal Firewall-Systeme ist die Erkennung von Backdoors

und Spyware. 18

Abbildung 6 - Personal Firewall

Vgl.: 17

[cpNGX]

18

[wikiFW]


30

2.2.2.9 Load-Balancing Firewall

Hochverfügbarkeitsverfahren und Lastverteilung sind Mittel um das Unternehmensnetzwerk vor

Ausfällen zu schützen. Bei diesen Mitteln werden zwei Firewalls zu einem Cluster verbunden. Fällt

eine Firewall aus, wird der Traffic automatisch über die andere Firewall geleitet, ohne dass die

Verbindung abbricht. Die Lastaufteilung wird anhand von Diensten, Adressen, RoundRobin, Hash,

sowie der Belastung durchgeführt. 19

Abbildung 7- Load-Balancing Firewall

2.2.2.10 Distributed Firewall

Bei Distributed Firewalls handelt es sich um eine Menge von Firewalls, welche unterschiedliche

Bereiche eines Unternehmens schützen. Diese Firewalls tauschen untereinander »Informationen«

aus. 20

2.2.2.11 Firewall Cluster, Firewall Farms

Firewall Cluster bzw. Firewall-Farms werden entweder nach dem bereits oben beschriebenen

»Load-Balancing« oder dem »distributed Firewall« – Prinzip aufgebaut. Neben den oben beschrie-

benen Firewall Architekturen gibt es weitere wichtige Funktionen, welche ebenfalls kombiniert in

Firewalls zu finden sein können. 21 22 23

2.2.2.12 Authentifizierung

Damit sich lediglich autorisierte Personen in das Netzwerk einloggen können, verfügen Firewalls

über eine Authentifizierung durch Benutzernamen und Kennwort. Hierbei gibt es zwei Möglichkeit

Vgl.: 19 [wikiFW]

20

[cpNGX] 21

[wikiFW] 22

[pchFW] 23

[cpNGX]


31

der Authentifizierung, welche die Firewalls in der Regel anbieten. Zum einen die In-Band-

Authentifizierung und zum anderen die Authentifizierung als Authentifizierungs-Proxy. Beim zwei-

ten Modell übernimmt die Firewall die Authentifizierungsfunktion anderer Systeme, wie z.B. des

Domain Controllers. 24 25

2.2.2.13 Verwaltung von Firewalls

Firewalls können sowohl einzeln, wie auch zentral verwaltet werden. Hierfür gibt es Herstellerab-

hängig verschiedene Tools um die Systeme möglichst vollständig verwalten zu können. Die meis-

ten Firewalls lassen sich heute über grafische Benutzeroberflächen konfigurieren. Bei einer Mana-

gement-Seitigen Verwaltung müssen die Firewalls zuerst vorkonfiguriert werden, damit Sie eine

Verbindung zum Management-System aufbauen können. Anschließend werden die Geräte komp-

lett über das Management verwaltet. Einzelverwaltete Firewalls können mittels der auf ihnen in-

stallierten Konfigurationssoftware konfiguriert werden. Neben der Konfiguration bieten diese

Tools auch die Möglichkeit verschiedene Protokoll-Dateien, Konfigurationsberichte und Paketer-

kennungs-Utilities zu verwenden. 26

2.2.2.14 Verschlüsselung und VPNs

Immer mehr Unternehmen setzten VPNs ein, um ihren Mitarbeitern, Außenstellen, etc. einen si-

cheren Zugriff auf das globale Firmennetzwerk zu geben. Auch für die sichere Kommunikation mit

vertrauenswürdigen Dritten, wie Kunden oder bestimmte Dienstleister, werden VPN Verbindungen

eingesetzt. Für den Aufbau einer VPN-Verbindung kann die Firewall sowohl als VPN-Gateway, wie

auch als VPN-Server eingesetzt werden. Hierbei werden sämtliche Daten kodiert, welche in ein

Public Network gesendet werden. Die Empfänger Firewall entschlüsselt die empfangenen Daten

und untersucht diese auf Richtigkeit, bevor diese zum eigentlichen Empfänger weitergeleitet wird. 27 28 29

Vgl.: 24

[wikiFW] 25

[pchFW] 26

[cpNGX] 27

[wikiFW] 28

[pchFW] 29

[cpNGX]


32

2.2.2.15 NAT – Network Address Translation

Firewalls verfügen über ein Network Address Translation System, welches erlaubt Interne IP-

Adressen nach außen unsichtbar zu machen. Dies ist ein sehr wichtiger Beitrag zur Netzwerksi-

cherheit. So sind lediglich die Öffentlichen-IP-Adressen, und damit die Firewalls und andere Geräte

mit öffentlichen IP-Adressen, wie z.B. Webservern sichtbar. 30

Abbildung 8 - Veranschaulichung NAT

2.2.2.16 Protokollierung und Berichterstellung

Firewalls protokollieren sämtliche Vorfälle, Verbindungen, Zugriffsversuche, etc. Diese Informatio-

nen können mittels der Management-Software oder direkt über die Benutzeroberfläche des

Firewall-Betriebssystems analysiert werden. Desweiteren können auch Berichte und Protokolle

direkt von der Firewall auf verschiedenen Kommunikationstechniken, wie z.B. E-Mail, versendete

werden. 31

2.2.2.17 Datensicherung

Die meisten Firewalls bieten ein selbständiges Backup ihres Systems an, welche im Ernstfall dem

Administrator Widerherstellungsoptionen bietet, welche meist über ein Browserinterface gestartet

werden können. 32

Vgl.: 30

[pchFW] 31

[pchFW] 32

[pchFW]


33

2.3 VPN - Virtual Privat Network

Bei Virtuell Privat Networks handelt es sich um Netzwerke welche öffentliche Netze als Basis nut-

zen um Private Netzwerke aufzubauen. Neben dem bekanntesten VPN Vertreter, dem Internet

VPN gibt es noch zahlreiche weiter VPN Anwendungen, wie zum Beispiel VPN in Sprachnetzen.

Der Fokus wird im folgenden Abschnitt jedoch auf VPNs welche über das public Internet arbeiten

gelegt.

2.3.1 Remote Access VPN

Mit Hilfe eines Remote Access VPN ist es möglich von jedem beliebigen Standort der Welt über

das Öffentliche Internet, welches als Basis für die Verbindung dient, auf ein Firmennetzwerk per

VPN Einwahl zuzugreifen. Eine solche Lösung besteht aus einem VPN-Konzentrator welcher zwi-

schen dem Internet und dem Intranet aufgebaut ist. Der VPN-Konzentrator ist oftmals Teil einer

Firewall Lösung. Als Gegenstück zum VPN Konzentrator fungiert eine Client Software wie z.B.

Cisco VPN Client oder Check Point Secure Client welche auf den entfernten Rechnern installiert

sind. Der VPN-Konzentrator übernimmt die Terminierung der VPN Tunnel. Der Verbindungsaufbau

des VPN-Tunnels wird durch die Client Software welche lokal auf den Mobile Clients installiert sind

bewerkstelligt. 33

Abbildung 9 - Remote Access VPN

Vgl.: 33

[lipVPNT]


34

2.3.2 Branch Office VPN / Site-to-Site VPN

Branch Office VPNs, welche auch von manchen Anbietern (u. A. Check Point) Site-to-Site VPN

genannt werden, sind VPN Lösungen welche zwei oder mehrere Außenstellen per VPN Tunnel

basierend auf dem öffentlichen Internet, sicher miteinander verbinden. Hierfür werden VPN-

Tunnel zwischen den einzelnen Lokationen aufgebaut. Vorteil dieser Technologie gegenüber einer

MPLS Strecke oder einer anderen Standartfestverbindung sind die deutlich geringeren Kosten, da

lediglich ein Breitbandinternetanschluss für die Verbindung per VPN-Tunnel benötigt wird. 34

Abbildung 10 - Branch Office VPN

Vgl.: 34

[lipVPNT]


35

2.3.3 Extranet VPN

Ein Extranet VPN ist vom Aufbau vergleichbar mit einem Remote Access- oder einem Site-to-Site

VPN. Größter Unterschied ist dabei nicht der Aufbau des Systems, sondern die Nutzer. Beim Re-

mote Access VPN und beim Branch Office VPN sind es lediglich firmeninterne Nutzer die per VPN

Verbindung auf das Netzwerk zugreifen. Bei einem Extranet VPN hingegen werden bestimmte

Ressourcen und Bereiche des Netzwerks für Kunden, Zulieferer oder weitere externe Dienstleister

freigegeben. Typische Anwendungsbeispiele für Extranet VPNs sind Verbindungen zwischen Pro-

duktionsbetrieben wie Daimler und deren Zulieferer oder zwischen Banken und deren Kunden.35

Abbildung 11 - Extranet VPN

Vgl.: 35

[lipVPNT]


36

2.3.4 Anforderungen an ein VPN

An ein VPN Netzwerk werden die Anforderungen Sicherheit, Verfügbarkeit, Performance, Skalier-

barkeit und Migrationsfähigkeit gestellt. 36

2.3.4.1 Sicherheit

Bei der Sicherheit eines VPN Netzwerks die folgenden Themen eine wichtige Rolle:

� Datenvertraulichkeit

� Schlüsselmanagement

� Paket-Authentifizierung

� Datenintegrität

� Benutzer-Authentifizierung

� Benutzer-Autorisierung

� Schutz vor Sabotage

� Schutz vor unerlaubtem Eindringen

Als Erstes steht die Datenvertraulichkeit des Netzes im Blickpunkt. Die Hauptanforderung besteht

darin, dass Daten welche über das Internet gesendet werden von Unbefugten nicht gelesen wer-

den können. Auch deren Verkehrsbeziehungen, also Quell- und Zieladresse sowie Protokoll- und

Zielnummer, sollen ebenfalls für dritte nicht lesbar sein. Die Einhaltung dieser beiden Anforderun-

gen wird durch Verschlüsselung der Datenpakete durch ein standardisiertes Verschlüsselungsver-

fahren wie AES realisiert. Mit diesem Schritt wird jedoch nur die erste Anforderung, der Schutz der

Daten erreicht. Um auch die Verkehrsbeziehungen erfolgreich schützen zu können muss das Ge-

samte Datenpaket, welches aus den Verkehrsbeziehungen und den eigentlichen Daten besteht, in

den Datenbereich eines weiteren Datenpaketes gepackt werden. Dieser Vorgang wird auch als

Tunneling bezeichnet.

Das Schlüsselmanagement ist für die Sicherheit eines VPN Netzwerks ebenfalls von großer Bedeu-

tung. Das Schlüsselmanagement erzeugt sämtliche benötigten Schlüssel welche zur Integritätsprü-

fung, zur Verschlüsselung und zur Authentifizierung. Des Weiteren ist das Schlüsselmanagement

auch für die Verteilung der Schlüssel verantwortlich. Da gute Schlüssel nur eine sehr begrenzte

Lebensdauer besitzen ist eine gute Schlüsselverteilung für den tadellosen Betrieb eines VPN Netz-

werks sehr wichtig. Bei den heutzutage verwendeten Schlüsselmanagementverfahren handelt es

sich in der Regel um asymmetrische Verfahren welche zur Ver- und Endschlüsselung verschiedene

Vgl.: 36[lipAnf]


37

Keys verwenden. Einer dieser beiden Schlüssel, der sogenannte Public Key darf öffentlich bekannt

sein. Aus diesem Grund nennt sich dieses Verfahren des Schlüsselmanagements auch Public Key

Verfahren.

Um ankommende Datenpakete von Dritten welche mit gefälschter Absenderadresse und neu be-

rechneter Prüfsummen erkennen zu können benötigen VPN Netzwerke eine Paket Authentifizie-

rung. Ähnlich wie bei einer Userauthentifizierung muss jedes eingehende Paket mittels symmetri-

scher Schlüssel oder Pre-Shared-Secrets auf dessen Echtheit überprüft werden. Um die Geschwin-

digkeit dieser Prüfungen zu erhöhen wird dieses Verfahren in der Praxis meist mit der Prüfung der

Datenintegrität verbunden.

Um die Datenintegrität zu gewährleisten muss der Empfänger zuverlässig erkennen ob das emp-

fangene Paket während des Transports verändert wurde. Hierfür reicht eine standartmäßige Prüf-

summenüberprüfung nicht aus, da der Angreifer diese neu berechnen kann. Mittels eines Schlüs-

sels welcher lediglich dem Sender und dem Empfänger bekannt ist, wird die Paketprüfsumme an-

hand eines symmetrischen Verschlüsselungsverfahrens berechnet. Durch die Einbeziehung dieses

Schlüssels ist es einem Angreifer, der diesen Schlüssel nicht besitzt, verwehrt die Prüfsumme kor-

rekt zu berechnen.

Die Benutzerauthentifizierung ist vor allem bei Remote Access VPN Verbindung von enormer

Wichtigkeit. Hierfür gibt es verschiedene Verfahren welche von der einfachen Benutzername /

Passwort Eingabe bis hin zur Authentifizierung mittels Token reichen.

Bei Extranet VPNs spielt die Benutzer Autorisierung eine sehr große Rolle. So sollen Dritte, welche

auf das Netzwerk per VPN Einwahl zugreifen dürfen nur bestimmte Bereiche des Netzes sehen.

Dies kann ein reiner VPN-Konzentrator nicht leisten da dieser keine Möglichkeit hat rollenbasierte

Gruppen oder Zugriffe zu verwalten. Um Extranet VPNs sicher realisieren zu können muss der

VPN-Konzentrator entweder direkt in einer Firewall integriert sein, oder mit einer solchen kombi-

niert werden.

Auch der Schutz vor Sabotage ist ein sehr wichtiges Thema in VPN Netzwerken. Leider sind die

Systeme Angriffen wie Denial-of-Service-Attacken schutzlos ausgeliefert. Die Folge eines solchen

Angriffs ist die Überlastung der Leitung bzw. des Ports was zum Abbruch des Tunnels führen

kann. Solchen Angriffen können lediglich durch Strafverfolgung Einhalt geboten werden.

Da es sich bei VPN Gateways um »Tore« zwischen dem public Internet und einem Firmennetzwer-

ken handelt ist die Gefahr dass Hacker über einen Angriff dieses Gateways ins Firmennetz eindrin-


38

gen können groß. Aus diesem Grund ist beim Aufbau von VPN Netzwerken ein Augenmerk auf

den Schutz vor unerlaubtem Eindringen zu legen. Um diesem Vorzubeugen müssen sowohl die

physische Sicherheit, also die physikalische Umgebungssicherung eines Gateways als auch die Inte-

face Sicherheit gewährleistet sein. Unter Interface Sicherheit versteht man die Einstellungen wel-

che am Interface direkt vorgenommen werden können. Durch Verwendung von gehorteten IP-

Stacks z.B. wird dem Interface ein Großteil seiner Funktionalität geraubt so dass sich dieses ledig-

lich auf die Kernaufgabe, nämlich das VPN Netzwerk bezieht. Jedoch gibt es auch bei dieser Me-

thode Probleme, da über Sicherheitslücken im verwendeten Betriebssystem der Angreifer über

Hintertüren auf die Interface zugreifen kann. Desweiteren sollte auch die Betriebssicherheit im

Bereich des Netzwerkes durchgängig durchdacht sein. So ist es wichtig dass nicht durch Konfigu-

rationsfehler Sicherheitslücken im Netzwerk entstehen welche über das Publik Internet einen Zu-

griff auch außerhalb des VPN Tunnels erlauben. Ein typisches Beispiel hierfür ist z.B. die Vergabe

einer öffentlichen IP Adresse an einen Rechner welcher in der LAN Struktur untergebracht ist.37

2.3.4.2 Verfügbarkeit

Für eine Meshed Site-to-Site VPN Struktur mit Verwendung zentraler Dienste, wie sie von vielen

Unternehmen verwendet wird, ist eine hohe Verfügbarkeit der Verbindungen von höchster Priori-

tät. Da diese Technologie jedoch auf dem public Internet aufbaut ist man von der Netzqualität des

jeweiligen Providers abhängig. Da kein Provider Leitungsunterbrechungen, wie sie z.B. durch

Stromausfälle oder durch Leitungsabrisse bei Bauarbeiten entstehen können ausschließen kann, ist

eine garantierte Verfügbarkeit von VPN Netzwerken über das public Internet nicht möglich.38

2.3.4.3 Performance

Die Performance eines VPN Netzwerks ist abhängig von der Leitungsqualität sowie dem gewähl-

ten Internetzugangstarif. Je nach dem welche und wie viele Applikationen über das VPN Netzwerk

Daten transferieren wird auch mehr oder weniger Bandbreite vom Internetprovider benötigt. So

sind eine möglichst hohe Bandbreite und daraus resultierende kurze Latenzzeit für eine gute Per-

formancetechnische Versorgung des VPN Netzwerkes nötig.39

2.3.4.4 Skalierbarkeit und Migrationsfähigkeit

Bei der Migrationsfähigkeit bzw. Skalierbarkeit ist wichtig das bereits während der Planungsphase

des Netzes an zukünftige Ausbauschritte des Netzwerks gedacht wird. Daher ist eine Modularität

und Erweiterbarkeit der Systemkomponenten wichtig. Bei der Skalierbarkeit muss dringend zwi-

schen Leistung und Sicherheit eines Systems differenziert werden. So benötigt z.B. die Firewall die

Vgl.: 37

[lipAnf] 38

[lipAnf] 39

[lipAnf]


39

in einer kleinen Lokation sitzt nicht die Performance, wie das System welches im Headquarter

verwendet wird, jedoch sollte es über dieselben hohen Sicherheitsstandards verfügen. 40

2.3.5 Sicherheit in VPNs

Wichtigstes Kriterium bei der Sicherheit von VPN-Netzwerken ist der Schutz der übertragenen

Daten. Die versendeten Daten müssen vor Verletzungen der Vertraulichkeit und der Integrität ge-

schützt werden. Auch der Schutz vor Hacker Angriffen ist neben dem Schutz der Daten für ein

VPN-Netzwerk von höchster Priorität. Über eine Security Policy werden die Anforderung für die

Sicherheit der VPN-Verbindung festgelegt. Diese Security Policy ist in der Regel für das gesamte

Unternehmensnetzwerk gültig.

Um diese Kriterien erfüllen zu können wird eine Verschlüsselung auf der Netzwerkebenen (Schicht

3 im ISO/OSI-Referenzmodell) vorgenommen. Je nach Anforderung kann hierbei eine Verschlüsse-

lung zwischen Rechner und Rechner, Rechner und Netzwerk oder Netzwerk und Netzwerk statt

finden. 41

Vgl.: 40

[lipAnf] 41

[lipSt]


40

2.3.6 Verschlüsselungsverfahren

Generell gibt es zwei Arten von Verschlüsselungsverfahren, welche bei VPN-Netzwerken Anwen-

dung finden. Die symmetrischen Verschlüsselungsverfahren welche mit einem Secret-Key Verfah-

ren arbeiten. Alternativ hierzu können die asymmetrischen Verschlüsselungsverfahren verwendet

werden, welche auf einem Public- und einem Private-Key basieren. 42

2.3.6.1 Symmetrisches Verschlüsselungsverfahren

Die Basis eines symmetrischen Verschlüsselungsverfahrens bildet der von beiden Parteien genutzte

Secret-Key. Dieser wird vom Sender und Empfänger vor dem Datenaustausch vereinbart. Mit die-

sem Schlüssel wird entsprechend die Nachricht vom Sender chiffriert und anschließend vom Emp-

fänger wieder dechiffriert.

Abbildung 12 - Symmetrische Verschlüsselungsverfahren

Bekanntester Vertreter dieses Verschlüsselungsverfahrens ist AES.43

2.3.6.2 AES

Bei AES handelt es sich um den Nachfolger der symmetrischen Verschlüsselungssysteme DES bzw.

Triple-DES. AES basiert auf dem Rijndael-Algorithmus. Die Blockgröße von AES beträgt 128 Bit, die

variable Schlüssellänge 128, 192 oder 256 Bit. Das AES Protokoll ist ein frei verfügbares Ver-

schlüsselungssystem welches keinen Lizenzbestimmungen untersteht.

Vgl.: 42

[lipSt] 43

[lipSt]


41

AES arbeitet wie bereits erwähnt in einer angepassten Form des Rijndael-Algorithmus. Im Original

Rijndael-Algorithmus ist neben der Schlüssellänge auch die Blockgröße variabel. So werden hier

Blöcke in den Größen 128, 160, 192, 224 und 256 Bit verwendet. Auch die Schlüssellänge enthält

im ursprünglichen Algorithmus die Größen 128, 160, 192, 224 und 256 Bit. Diese Werte werden

beim Rijndael-Algorithmus in einer zweidimensionalen Tabelle aufgeführt. Anschließend wird Ta-

bellenblock für Tabellenblock verschiedene bestimmte Transformationen unterzogen Hierbei wer-

den verschieden Teile des erweiterten Originalschlüssels auf den Klartextblock angewendet. Die

Anzahl der Verschlüsselungsrunden ist bei AES von der Länge des Schlüssels abhängig.

Für die Monoalphabetische Verschlüsselung der Daten, also die Umwandlung von Klartext in einen

chiffrierten Text mittels eines einzigen festen Alphabets, wird bei AES eine Substitutionsbox ver-

wendet. Über diese S-Box wird in jeder Runde des Verschlüsselungsvorgangs jedes Byte eines

Blocks durch ein anderes ersetzt.

Der Ablauf der Verschlüsselung besteht im Wesentlichen aus vier Phasen.

� Schlüsselexpansion

� Vorrunde

� Verschlüsselungsrunde

� Schlussrunde

Während der Schlüsselexpansion wird der Schlüssel in mehrere Teilschlüssel aufgeteilt. Diese Teil-

schlüssel werden in die gleiche Länge wie die zu verschlüsselnden Blöcke transformiert. Anschlie-

ßend werden die entstandenen Schlüssel wieder in eine zweidimensionale Tabelle gesetzt. Hierbei

werden in die erste Spalte der Tabelle die Benutzerschlüssel eingetragen. Die weiteren Spalten

werden rekursiv berechnet indem das Byte, welches sich in der letzten Spalte und sich dort wiede-

rum drei zurückliegenden Zeilen befindet durch die S-Box verschlüsselt wird. Anschließend wird

die Verschlüsselung mit dem um eine Schlüssellänge zurückliegende Byte XOR verknüpft. Falls sich

das zu verknüpfende Byte an einer Position befindet, welche ein ganzzahliger Teiler der Schlüssel-

länge ist wird diese zusätzlich mit einem Eintrag aus der rcon-Tabelle XOR verknüpft. Bei der rcon

Tabelle handelt es sich ähnlich wie bei der S-Box Tabelle um ein Array, welches konstante Werte

die in einem mathematischen Zusammenhang zueinander stehen besitzt. Als Index für die Ver-

knüpfung wird eine fortlaufende Nummer verwendet. Bei den weiteren Spalten der Tabelle verhält

sich das Verfahren identisch zur ersten Spalte, jedoch wird hierbei als Referenz immer die direkte

Vorgängerspalte verwendet.


42

Nach erfolgreicher Schlüsselexpansion wird eine sogenannte KeyAddition während der Vorrunde

durchgeführt. Die Bedingung für den Beginn und das Ende der Vorrunde ist, dass der Runden-

schlüssel 0 verwendet wird. Bei der KeyAddition wird der Block mit dem aktuellen Rundenschlüssel

XOR verknüpft. Eine Besonderheit bei der KeyAddition ist, dass dies der einzige Algorithmus wäh-

rend des gesamten AES Verschlüsselungsverfahrens ist, der direkt vom Benutzerschlüssel abhängig

ist.

Anschließend an die Vorrunde findet die Verschlüsselungsrunde statt, welche sich in mehrere Teil-

prozesse aufgliedert. Die zu durchlaufenden Teilprozesse sind die Phasen Substitution, ShiftRow,

MixColumn eingeteilt. Am Ende einer jeden Verschlüsselungsrunde wird erneut eine KeyAddition

durchgeführt. Im ersten Teilprozess der Verschlüsselungsrunde, der Substitution, wird jedes Byte

im Block monoalphabetisch verschlüsselt. Diese Verschlüsselung findet über die bereits beschrie-

bene S-Box statt. Im anschließenden ShiftRow werden die Zeilen um einen bestimmten Wert nach

links verschoben. Falls eine Zeile überläuft, wird diese von rechts fortgesetzt. In der vorletzten Pha-

se der Verschlüsselungsrunde werden die Blöcke untereinander vermischt. Diese geschieht durch

Multiplikation jeder Zelle einer Spalte mit einer Konstante. Das Produkt wird anschließend wiede-

rum XOR verknüpft. Diese Verfahren nennt sich auch MixColumn. Zum Abschluss eines jeden

Durchlaufs wird auf die entstandene verschlüsselte Tabelle eine KeyAddition durchgeführt.

Nachdem sämtliche Verschlüsselungsrunden durchlaufen wurden werden in der Schlussrunde

noch einmal eine Substitution, ein ShiftRow sowie eine abschließende KeyAddition durchgeführt.

Die Entschlüsselung von AES läuft genau rückwärts zur Verschlüsselung ab, was bedeutet dass die

Schlussrunde den Anfang der Dechiffrierung macht. Einzige Unterschiede jedoch sind dass hier

eine andere S-Box verwendet werden muss, welche sich aus der S-Box der Verschlüsselung gene-

rieren lässt. Auch die Zeilenverschiebung, wie sie in der ShiftRow Funktion angewandt wurde,

muss in die Verschiebungsrichtung ändern.

Durch Anwendung dieser komplexen Verschlüsselungstechnik entstehen bei einem 128 Bit langen

Schlüssel 3,4 x 10��, bei einem 192 Bit langen Schlüssel gibt es 6,2 x 10�� und bei einem 256-Bit-

Schlüssel 1,1 x 10�� Möglichkeiten für die Verschlüsselung.44 45

Vgl.: 44

[lipSt] 45

[wikiAES]


43

2.3.6.3 Hash-Verfahren

Um den für den Kommunikationsaufbau nötigen Fingerprint sicher durchzuführen, wird hierfür

das Hash-Verfahren verwendet. Beim Fingerprint authentifiziert sich die Firewall einmalig beim

Management mit Hilfe einer SIC, welche beide Teilnehmer kennen. Anschließend, im Falle einer

Vertrauensstellung kann erst der VPN-Tunnel zwischen beiden Geräten aufgebaut werden. Um

die SIC sicher übertragen zu können wird sie mit dem Hash-Verschlüsselungsverfahren chiffriert. Es

gibt zwei bekannte Hash-Algorithmen, MD5 und SHA, welche auch im IPSec Standard fest veran-

kert sind.

Beim MD5 Algorithmus wird aus dem Eingangswert beliebiger Länge ein Hashwert mit 128 Bit

Länge erzeugt. Für die Berechnung dieses Wertes wird sowohl der Eingangswert, als auch dessen

Länge verwendet. Da bei diesem Verfahren beide Teilnehmer den Eingangswert kennen, muss nur

der Hashwert miteinander verglichen werden. Bei nur einem falschen Buchstaben unterscheiden

sich die Hashwerte immens.

SHA ist der neuere der beiden Algorithmen. SHA unterscheidet sich von MD5 durch die Erzeugung

eines längeren Hashwerts (160 Bit), sowie durch die größere Anzahl der Verarbeitungsrunden bei

der Verschlüsselung. Da der Algorithmus dieses Verfahrens, welches von der NSA entwickelt wur-

de, nie offen gelegt wurde, misstrauen viele Anwender dieser Verschlüsselungstechnik.46

Vgl.: 46[lipSt]


44

2.3.6.4 Asymmetrische Verschlüsslungsverfahren

Bei der asymmetrischen Verschlüsselung kommen sogenannte Schlüsselpaare bestehend aus ei-

nem Public- und einem Private-Key zum Einsatz. Diese Schlüsselpaare werden anhand eines ma-

thematischen Verfahrens welches nicht zurückzuverfolgen ist von einander abgeleitet. Der Public-

Key, wird zur Verschlüsselung der Nachricht verwendet. Auf der Empfängerseite befindet sich der

Private-Key, welcher lediglich vom Empfänger gekannt wird. Mit Hilfe des Private-Key kann die

Entschlüsselung der Nachricht getätigt werden. Eine mit einem Public-Key chiffrierte Nachricht

kann nicht mit einem anderen Public-Key, noch mit dem zur Verschlüsselung verwendeten Public-

Key dechiffriert werden.

Abbildung 13 - Asymmetrisches Verschlüsselungsverfahren

Asymmetrische Verschlüsselungsverfahren haben gegenüber symmetrischen Verfahren deutliche

Performance Nachteile. Bekanntester Vertreter dieser Verschlüsselungsform ist RSA.47

2.3.7 Tunneling Protokoll - IPSec

Die gängigste und aktuell sicherste Tunnel-Technologie auf dem Markt ist das IPSec-Tunneling-

Protokoll. Das IPsec Protokoll, welches von der IETF entwickelt wurde, ist eine Erweiterung des IP-

Protokolls. Ziel ist es dass sich zwei Netzwerke, welche durch ein unsicheres Netzwerk von einan-

der getrennt sind, über dieses sicher zu verbinden. Ursprünglich wurde IPsec als integraler Be-

standteil des IPv6 Protokolls entwickelt, jedoch mit der Auflage das IPsec abwärtskompatibel zu

IPv4 ist. IPsec enthält von Haus aus sehr viele Sicherheitsfunktionen welche ein sicheres VPN ohne

Verwendung externer Protokolle ermöglicht. Dazu gehören Interoperalität, kryptografischer

Schutz der übertragenen Dateien, Zugangskotrolle, Datenintegrität, Authentifizierung des Absen-

Vgl.: 47 [lipSt]


45

ders, Verschlüsselung, Authentifizierung von Schlüsseln, sowie die Verwendung von VPN Schlüs-

seln. Bei der Verbindung über das IPsec Protokoll spielt die Vertrauensstellung der Partner eine

enorme Rolle. Wichtig ist hierbei, dass nicht zwangsläufig die Clients, welche den Datenaustausch

bewerkstelligen wollen, in direkter Vertrauensstellung zueinander sind. Es reicht wenn die beiden

Router bzw. Firewalls an welchen die Clients hängen, miteinander in einer Vertrauensstellung sind.

Diese Vertrauensstellungen regeln die Kommunikation in IPsec. Diese äußerst flexible Kombination

von Vertrauensstellungen erfordert einen hohen Konfigurationsaufwand. Die Art der gesicherten

Übertragung (Authentifizierung oder Verschlüsselung), der Verschlüsselungsalgorithmus, die

Schlüssel, wie auch die Dauer der Gültigkeit der Schlüssel sind Parameter, welche zwischen den

beiden Kommunikationspartnern im Vertrauensverhältnis ausgetauscht werden. Die Vertrauens-

stellung an sich wird ebenfalls mittels eines vom Admin fest vergebenen Schlüssels oder mittels

eines Zertifikats festgestellt. Anhand dieser Authentifizierung verständigen sich die Kommunikati-

onspartner ehe sie selbst eine eigene Verschlüsslung in die Wege leiten. Die einfachste Variante

hierbei ist die Verwendung eines sogenannten geheimen Schlüssels. Das bereits beschriebene

Hash-Verfahren kommt an dieser Stelle zum Einsatz. Hierbei müssen folgende Gegebenheiten si-

chergestellt sein. Beide Kommunikationspartner müssen über IP-Adresse, Subnetzmaske, Tunnel-

name und dem geheimen Schlüssel Bescheid wissen.

Abbildung 14 - AH- und ESP-Verschlüsselung

Zentrale Funktionen der IPsec Architektur sind das ESP Protokoll sowie das AH Protokoll. Dritte

zentrale Funktion von IPsec ist das Key Management. Das ESP-Protokoll sowie das AH-Protokoll

werden dazu verwendet um ein VPN aufzubauen, wobei beide Protokolle parallel oder einzeln

eingesetzt werden können. Das AH Protokoll ist für die Authentifizierung der zu übertragenden

Datenpakete, sowie der Protokollinformationen verantwortlich. Hierfür wird eine Prüfsumme aus

dem vollständigen IP-Datenpaket heraus gebildet und zwischen dem IP-Header und dem TCP-

Header eingefügt. Durch diese Checksumm lässt sich die Vollständigkeit sowie Korrektheit der

Daten beim Empfänger ermitteln. Problematisch wird dieses System beim Einsatz eines NAT-

Routers. NAT ändert die IP-Adresse des Absenders, was dazu führt dass diese nicht mit der IP-

Adresse der Checksumm übereinstimmt und dadurch zur Ungültigkeit des gesendeten Datenpa-

kets führt. Ungültige Datenpakete werden beim Empfänger verworfen. Das ESP-Protokoll hinge-


46

gen erhöht in Abhängigkeit des Verschlüsselungsalgorithmus die Datensicherheit. Zwei Betriebsar-

ten werden vom ESP-Protokoll angeboten. Hierbei handelt es sich um den Transport- und den

Tunnel-Modus. Beim Tunnelmodus werden sämtliche IP-Datenpakete vor der Übertragung komp-

lett verschlüsselt. Vor das verschlüsselte IP-Datenpaket setzt der Tunnel-Modus einen neuen IP-

Header. Dieses Verfahren wird eingesetzt, wenn zwei Netzwerke über eine unsichere Verbindung,

wie z.B. das Internet, mit einander verbunden werden sollen. Beim Transportmodus wird nicht wie

beim Tunnelmodus das komplette Datenpaket verschlüsselt, sondern lediglich der Datenanteil im

IP-Datenpaket. Der Header bleibt also bei diesem Modus unverändert. Für einen Angreifer bedeu-

tet dies dass er aufgrund der Verschlüsselung nicht an die Daten kommt, jedoch kann er sehen

dass eine VPN-Verbindung zwischen zwei Netzwerken besteht.

Auch das Key-Management kann über zwei verschiedene Wege realisiert werden. Neben der

Möglichkeit die Schlüssel manuell zu verwalten und zu verteilen ist es auch möglich das Internet

Key Exchange Protokoll für diese Aufgabe zu verwenden. Bei IPsec werden keine speziellen Ver-

schlüsselungs- oder Authentifizierungsverfahren vorausgesetzt. Als gängige Verschlüsselungsver-

fahren werden Triple-DES, AES und SHAs sowie MD5 verwendet. Da IPsec Implementierungen

keine bestimmten verfahren standardisiert sind, müssen unterschiedliche VPN-Produkte vor Ihrem

Einsatz auf Kompatibilität hin überprüft werden. Die verschlüsselten Datenpakete dürfen auf bei-

den Seiten nicht auf der Firewall aufschlagen. Die Authentifizierung erfolgt auf UDP-Port 500.

Über das ESP-Protokoll folgen die verschlüsselten Datenpakete. Wichtig hierbei ist, dass Netware

Dienste, welche über IPX laufen, nicht über VPN-Verbindungen funktionieren, da IPsec lediglich

mit IP-basierten Diensten kompatibel ist.

Der Verbindungsaufbau zwischen zwei Geräten im VPN Netzwerk läuft auf folgende Weise ab.

Das Quellsystem generiert eine Anfrage an das Zielsystem, welches daraufhin antwortet und einen

Schlüsselaustausch per IKE einleitet. Hierbei werden die Authentifizierungs- und Schlüsselverfahren

ausgehandelt. Eine Vertrauensstellung der beiden Kommunikationsteilnehmer wird mittels eines

Schlüssels oder eines Zertifikats welches beiden bekannt ist hergestellt. Hierauf wird für beide Teil-

nehmer der digitale Masterschlüssel erzeugt. Im Anschluss wird vom Ziel- und Quellsystem das

Verschlüsselungs- und Authentifizierungsverfahren für den Datenaustausch festgelegt. Der Schlüs-

sel für die Datenübertragung wird mittels des Masterschlüssels erstellt. Nun können die Daten

getauscht, und die Verbindung hergestellt werden.

Falls NAT verwendet wird, wird von Port 500 bei der Öffentlichen IP-Adresse, auf Port 450 im Pri-

vaten Adressbereich übersetzt.48 49

Vgl.: 48 [lipIPSec]

48 [wikiIPSec]


47

2.4 Übertragungstechnik

2.4.1 SDSL

Bizerba Österreich nutzt momentan in Wien die SDSL Übertragungstechnik mit einer Übertra-

gungsgeschwindigkeit von jeweils 2 MBit/s im Up- und Downloadbereich. Die Abkürzung SDSL

steht für Symmetric Digital Subscriber Line und ist wie ADSL eine DSL-Zugangstechnik. Die

Datenübertragungsgeschwindigkeit ist sowohl in Upload- wie auch in Download-Richtung bei

SDSL identisch. Die SDSL-Technik, eine Weiterentwicklung von HDSL, war ursprünglich von den

Netzbetreibern als hochbitratige, leistungsgebundene Datenübertragung im Teilnehmeranschluss-

bereich konzipiert worden. Grund für diese Weiterentwicklung war in erster Linie die Anbindung

von Netzkomponenten im Zugangsnetz sowie um die Bereitstellung von Primärmultiplexanschlüs-

sen für ISDN realisieren zu können. Die wesentliche Innovation von SDSL gegenüber HDSL liegt in

der verbesserten Modulationstechnik. Die vorwiegend eingesetzte SDSL-Variante besitzt eine ma-

ximale Bitrate von 2,36 MBit/s und einer Reichweite von bis zu 8 km. Diese SDSL-Variante basiert

auf einer Kupfer-Doppelader. Gegenüber einer ADSL-Verbindung ist neben dem simultanen Up-

und Download vor allem die deutlich größere Reichweite als Vorteil zu sehen. Einen Anstieg der

Reichweite bzw. der Datenrate lässt sich durch das sogenannte Bounding realisieren. Hierbei wer-

den mehrere Doppeladern gebündelt. Anstelle einer Kupferader kann auch alternativ eine Glasfa-

serleitung eingesetzt werden. Mittels Traffic-Shaping können SDSL Anschlüssen zu ADSL Anschlüs-

sen transformiert werden. SDSL ist wie ADSL sowohl mit analogen POTS- als auch digitalen ISDN

Anschlüssen kompatibel. Im Gegensatz zu ADSL unterstütz SDSL die Splitter-Technologie nicht. Die

SDSL-Technik benötigt den kompletten Frequenzbereich der POTS- bzw. ISDN-Verbindung, was

bedeutet dass es nicht möglich ist auf SDSL-Anschlussleitungen herkömmliche Telefonie bereitzus-

tellen. Folglich handelt es sich bei SDSL-Anschlüssen um reine Datenverbindungen. Jedoch ist es

bei SDSL möglich mehrere B-Kanäle eines ISDN-Anschlusses zeitgleich zu nutzen. Die Grundvor-

aussetzung ist hierfür, dass es sich um gemultiplexte Kanäle handelt. Als Alternative zur herkömm-

lichen Telefonie können SDSL-Nutzer natürlich über VoIP Dienste telefonieren.

SDSL ist ein Telekommunikationsnorm, welche von ETSI (TS101524) und der ITU (G.911.2) stan-

dardisiert wurde.

Die Anfangsbuchstaben A bzw. S der verschiedenen DSL-Technologien haben nichts mit Synchro-

ner bzw. Asynchroner Datenübertragung zu tun, wie es viele vermuten. Sowohl ADSL wie auch


48

SDSL sind Übertragungsstandards für asynchrone Datenübertragung. Die Buchstaben A bzw. S

stehen für Asymmetric bzw. Symmetric, also eine Symmetrische oder Asymmetrische Verbindung. 50 51

Abbildung 15 - Aufbau SDSL

2.4.2 ADSL - Asymmetric Digital Subscriber Line

Die österreichischen Lokationen in Bregenz, Graz und Linz verwenden die ADSL Technologie zur

Internetanbindung. ADSL wurde entwickelt um DSL auf Basis der zur Entwicklungszeit bereits be-

stehenden analogen (POTS) und digitalen (ISDN) Telefonanschlussleitungen zu realisieren. Bei der

ADSL Technik ist im Gegensatz zur SDSL Technik die Upload- und die Download-Geschwindigkeit

nicht äquivalent. ADSL ist als Endverbraucher DSL konzipiert, da diese Zielgruppe deutlich größere

Datenmengen aus dem Internet bezieht und weniger Daten im Internet bereitstellt. Es ist möglich

ADSL sowohl auf Basis von POTS-, wie auch von ISDN- Telefonanschlussleitungen zu realisieren.

Zu dem kann ADSL auch als entbündelter Datenanschluss (Annex C) verwendet werden. Entbün-

delter Datenanschluss bedeutet, dass der reguläre Telefonanschluss vom ADSL getrennt wird. Die

ADSL-Technologie verwendet die, bei der herkömmlichen Telefonie, brach liegenden höheren

Frequenzbereiche von POTS- und ISDN- Telefonanschlussleitungen. Das Grundfunktionsprinzip der

ADSL-Technik beruht auf dem Verfahren der Fourier-Transformation sowie dem Frequenzmultip-

Vgl.: 50

[elkoSDSL] 51

[wikiSDSL]


49

lexverfahren wie auch DMT. Bei DMT handelt es sich um ein spezielles Modulationverfahren wel-

ches die Frequenzbänder Subkanäle aufteilt.

Abbildung 16 - Aufbau ADSL

Das für den Betrieb von ADSL benötigte Spezialmodem besteht im Wesentlichen aus folgenden

Komponenten. Einem leistungsstarken Analog/Digital-Wandler in Kombination mit einem digitalen

Signalprozessor, welcher die einzelnen Frequenzen anhand der Fourier-Transformation berechnen.

Um Störungen zwischen den beiden Betriebsarten der Telefonleitung zu verhindern, wird sowohl

teilnehmerseitig wie auch providerseitig eine Frequenzweiche, ein sogenannter Splitter, installiert.

Da bei der ADSL-Technik kein Sprachkanal belegt wird, ist es selbst mit einem POTS-Anschluss

möglich beide Nutzungsarten parallel zu betreiben. Das in Deutschland eingesetzte ADSL-over-

ISDN (Annex B) verwendet zur Datenübertragung vier 3.125 kHz breite Bänder mit einer Symbolra-

te von jeweils 4 kb im Bereich von 138 – 275 kHz beim Upstream. Beim Downstream hingegen

liegt die Symbolrate im Bereich von 275 – 1.104 kHz. Da die Telekommunikationsleitungen urs-

prünglich nicht zur Übertragung einer Bandbreite von etwa 1 MHz ausgelegt wurden, muss die

Leitung von der Vermittlungsstelle bis zum Endgerät vermessen werden. Dies wird getan um even-

tuell einzelne Bänder bei hoher Dämpfung oder Reflektion ausblenden zu können. Bei der ADSL-

over-ISDN Technik können Bandbreiten von maximal 10 MBit/s im Download und ein 1 MBit/s im

Upload erreicht werden. ADSL-over-POTS (Annex A) hingegen schafft im Upload die selbe Band-

breite wie ADSL-over-ISDN, muss sich aber im Download mit 8 MBit/s geschlagen geben. Durch

die Weiterentwicklung der ADSL-Technologie zum ADSL2+ Standard, wird der Frequenzbereich


50

auf 2,2 MHz erhöht. Dies bedeutetet das Bandbreiten bis zu 25 MBit/s im Download und 3,5

MBit/s im Upload erreicht werden können. Die relative Verdoppelung der Bandbreite von ADSL2+

gegenüber ADSL ist auf eine deutlich verbesserte Signalverarbeitung und eine verstärkte Kodie-

rung zurück zu führen.

Beim Verbindungsaufbau verständigt sich das Client-seitige ADSL-Modem zunächst mit der im

Central Office gelegenen DSLAM auf die zu verwendende ADSL-Norm. Beim DSLAM handelt es

sich um die Vermittlungsstelle an welcher die Teilnehmeranschlussleitungen zusammengeführt

werden. Es gibt für ADSL folgende Normen:

Norm Name Download Upload Faktor

ANSI T1.413 Issue 2 ADSL 8 MBit/s 0,6 MBit/s 13,3 : 1

ITU-T G.992.1 ADSL (G.dmt) 8 MBit/s 1,0 MBit/s 8 : 1

ITU-T G.992.1 Annex A ADSL over POTS 10 MBit/s 1,0 MBit/s 10 : 1

ITU-T G.992.1 Annex B ADSL over ISDN 10 MBit/s 1,0 MBit/s 10 : 1

ITU-T G.992.2 ADSL lite (G.lite) 1,5 MBit/s 0,5 MBit/s 3 : 1

ITU-T G.992.3 ADSL 2 (G.bis) 12 MBit/s 1,2 MBit/s 10 : 1

ITU-T G.992.3 Annex J ADSL 2 12 MBit/s 3,5 MBit/s 3,43 : 1

ITU-T G.992.3 Annex L RE-ADSL 2 6 MBit/s 1,2 MBit/s 5 : 1

ITU-T G.992.5 ADSL 2+ 24 MBit/s 1,0 MBit/s 24 : 1

ITU-T G.992.5 Annex L RE-ADSL 2+ 24 MBit/s 1,0 MBit/s 24 : 1

ITU-T G.992.5 Annex M ADSL 2+M 24 MBit/s 3,5 MBit/s 6,86 : 1

Tabelle 7 - ADSL Standards

Nach dem die entsprechende ADSL Norm festgelegt wurde, handeln beide Seiten die Verbin-

dungsparameter der ADSL Verbindung aus. Bei diesem Vorgang werden die DMT-Frequenzträger

der Kupferdoppelader gemessen. Die Up- und Download Übertragungsraten werden entspre-

chend des DSLAM-Profils ausgehandelt und auf die jeweiligen Träger verteilt. Die ADSL-

Verbindung bleibt, insofern es keine unplanmäßigen Zwischenfälle gibt, bis zur Verbindungstren-

nung aktiv. Einige DSL-Provider führen in der Regel alle 24h eine automatische Verbindungstren-

nung durch.


51

Abbildung 17 - Verbindungsaushandlung bei ADSL

Bei ADSL wird bei der Aushandlung der Übertragungsrate zwischen der ratenadaptiven- und der

fixen Aushandlung unterschieden. Bei der ratenadaptiven Aushandlung gibt der DSLAM stan-

dardmäßig die höchste Übertragungsrate vor. Falls in diesem Fall die Verbindung fehlschlägt über-

prüft der DSLAM die momentan höchst mögliche Übertragungsrate und gibt diese der Verbindung

vor. Seit Einführung des ADSL2+ Standards ist es möglich mit Hilfe der sogenannten Seamless Rate

Adaption, die Übertragungsgeschwindigkeit an die Qualität der Kabelverbindung anzupassen oh-

ne dabei die Verbindung trennen zu müssen. Bei der fixen Aushandlung hingegen wird die Über-

tragungsrate vom DSLAM fest vorgegeben. Wenn die vom DSLAM vorgegebene Übertragungsrate

nicht erreicht wird schlägt die Verbindung fehl. Bei dieser Aushandlungsform ist es notwendig

eine hohe Störabstands-Sicherheitsmarge zu haben, da in der Regel an diesen Anschlüssen deut-

lich geringere Datenraten zur Verfügung gestellt werden, als die, welche bei der adaptiven Aus-

handlung möglich wären. Aufgrund dieses Mankos setzen heute nahezu alle ADSL Provider die

ratenadaptive Aushandlung ein. Bei fixer Aushandlung ist die Qualität des Modems aufgrund der

hohen Störabstandssicherheitsmarge nicht ausschlaggebend. Hingegen spielt die Leistungsfähig-

keit des Modems bei der ratenadaptiven Aushandlung eine enorme Rolle. Insbesondere bei läng-

Vorbereitende Analysen und Vergleiche | Matthias Pyka a

68

3. Vorbereitende Analysen und Vergleiche

In diesem Kapitel werden sämtliche vorbereitenden Analysen und Vergleiche aufgezeigt. So wer-

den neben einer detailierten Ist-Zustandsanalyse auch der Soll-Zustand des Projekts beschrieben.

Ein weiterer Augenmerk wird auf eine Security Analyse des bestehenden Netzwerks der Bizerba

Österreich fallen. Neben diesen Dingen werden auch mögliche Gefahren für die IT-Infrastruktur

sowie die geforderte Konzeption einer alternativen WLAN Lösung für die kleineren Außenstellen

beschrieben.

3.1 Ist-Zustandsanalyse

Die folgende Ist-Zustandsanalyse erstellt sich aus den Fragebögen, welche die jeweiligen IT-

Koordinatoren vorab bearbeiten mussten sowie dem Antrittsbesuch von Herrn Jörg Rudischhauser

und Herrn Jens Ellinger.

Die Bizerba Standorte in Wien, Graz, Linz und Bregenz besitzen im Moment völlig autarke Netz-

werksysteme. Diese sind datentechnisch nicht mit dem Headquarter in Balingen verbunden. Der

Datentransfer zwischen diesen Lokationen wird im Moment mittels FTP Verbindungen realisiert.

Telefontechnisch werden die vier größten österreichischen Lokationen über ein gemeinsam ge-

nutztes VoIP-System welches vom Telekommunikationsprovider Atello bereitgestellt wird verbun-

den. Durch dieses System können kostenlose Telefonate unter den Außenstellen geführt werden.

Die Telekommunikationsanbindung der Außenstellen ist über SDSL in Wien, sowie ADSL Verbin-

dungen in Bregenz, Graz und Linz realisiert. Die Lokationen, welche im ersten Schritt der Integra-

tion Österreichs angebunden werden, besitzen zwischen acht und sechzehn öffentliche IP-

Adressen, welche vom Provider Atello bereitgestellt werden. In allen Lokationen stehen Zyxel SDSL

Router mit Modemfunktion, an welchem weitere Router bzw. Switches angeschlossen sind. Ledig-

lich in Wien wird bereits mit einer Firewall vom Typ Symantec / Gateway Security gearbeitet. Prob-

lematisch bei der Pflege des Systems ist das fehlende Know-How der dort angesiedelten Mitarbei-

ter. Leider wissen diese weder die Passwörter der 10/100 MBit Switches, noch das Passwort der

Firewall. Wien ist der der einzige österreichische Standort der eine Domänenstruktur besitzt. Der

dort aufgebaute Domänenserver beheimatet die Domäne bizerba.co.at. Neben dem Domänenser-

ver verfügt Wien auch über einen eigenen Exchange-Server. Die Betreuung des Domänen Servers


69

sowie des Exchange Servers wurde bislang von der Firma Ebcont Systems & Solutions übernom-

men.

Die kleineren Lokationen arbeiten vor Ort in Arbeitsgruppen. Das Senden und Empfangen von

Emails wird mit Hilfe des POP3- bzw. SMTP-Protokolls realisiert. In jeder Lokation existieren diverse

Fileserver zum Datentransfer und zur Datensicherung. In Wien ist ein Novell Server installiert auf

welchem zentral Konfigurations- und Kundendaten für den kompletten Österreichischen Markt

gespeichert sind. Die Daten werden mittels USB-Sticks, CDs, DVDs und ähnliches nach Wien ge-

sendet um dort ein gepflegt zu werden. Eine Datensicherung des gesamten Systems wird über

Bandlaufwerke realisiert. Bizerba Österreich arbeitet mit dem bei Bizerba vor SAP eingesetzten

EUDAT System, welches ebenfalls mit Magnetbändern gesichert wird. Die Verkabelung am Stand-

ort Wien ist zu großen Teilen unzeitgemäß. Es ist geplant die bislang bestehende Typ1 Verkabe-

lung aus dem Jahr 1986 durch CAT7 Gigabit Ethernet Verkabelung zu ersetzen. Neben den Typ1

Kabeln liegen auch noch fünfadrige Terminalleitungen, welche kurzfristig zu Ethernetkabeln um-

funktioniert wurden. Die Neuverkabelung des Standorts Wien wird als separates Projekt voraus-

sichtlich im Jahr 2010 umgesetzt. Bei den weiteren Standorten sind zeitgemäße CAT5 Verkabe-

lungen vorhanden. Auch die vorhandenen 10/100 MBit/s Switches welche in Wien und den kleine-

ren Lokationen angebracht sind, werden in Zukunft aus Kostengründen, nach einem Factory-Reset

und einer Neukonfiguration wieder verwendet.


70

Abbildung 23 - Überblick IST-Zustand


71

Tabellarische Übersicht Ist-Zustand Wien laut Fragebogen

IT Verantwortlicher Richard Waniek

Serverraum verfügt über USV? Ja

Serverraum ist Klimatisiert? Ja

Serverraum ist über Zugangskontrolle gesichert? Ja

WAN Anbindung SDSL

WAN Provider Atello

WAN Bandbreite 2048

Public IP-Bereich

Privat IP-Bereich 10.150.1.0 | 255.255.255.0

Firewall Symantec Gateway Security

Anzahl Clients ca. 100

Verlegte KabelTypen CAT5 / Token Ring

Vorhandene Switchen HP Pro Curve 2524

WLAN Nicht vorhanden

DHCP Server Vorhanden

Print Server Vorhanden

Internetzugriff über Proxy Nein

Internetzugriff über URL Filter Nein

Windows Domäne Ja

Client Betriebssysteme Windows 2000 / XP / Vista

Virenscanner McAfee

Mailserver Exchange Server

Mail Clients Outlook 97 / 2003 / 2007

Mailing Security over Frontbirdge Vorhanden

Fileserver Vorhanden

Datenbankserver Vorhanden

Backup / Restore Bandlaufwerk

Webserver Nein

Sonstige Server Eudat Server

Tabelle 10 - Übersicht Ist-Zustand Wien laut Fragebogen


72

Tabellarische Übersicht Ist-Zustand Bregenz laut Fragebogen

IT Verantwortlicher Jürgen Rusch

Serverraum verfügt über USV? ?

Serverraum ist Klimatisiert? ?

Serverraum ist über Zugangskontrolle gesichert? ?

WAN Anbindung ADSL

WAN Provider Atello

WAN Bandbreite 2048 / 512

Public IP-Bereich 85.126.18.224 | 255.255.255.248


Firewall Zyxel Zywall 5


Verlegte KabelTypen CAT5

Vorhandene Switchen ?

WLAN ?

DHCP Server ?

Print Server ?

Internetzugriff über Proxy ?

Internetzugriff über URL Filter ?

Windows Domäne Nein

Client Betriebssysteme Windows 2000 / XP / Vista

Virenscanner ?

Mailserver ?

Mail Clients Outlook 97 / 2003 / 2007

Mailing Security over Frontbirdge ?

Fileserver ?

Datenbankserver ?

Backup / Restore Bandlaufwerk

Webserver ?


Tabelle 11 - Übersicht Ist-Zustand Bregenz laut Fragebogen


73

Tabellarische Übersicht Ist-Zustand Graz laut Fragebogen

IT Verantwortlicher Bernhard Gößler

Serverraum verfügt über USV? Nein

Serverraum ist Klimatisiert? Nein

Serverraum ist über Zugangskontrolle gesichert? Nein

WAN Anbindung ADSL

WAN Provider Atello


Public IP-Bereich





Vorhandene Switchen Netgear FS108 | Netgear FS 1116

WLAN D-Link DWL-2100AP


Print Server Nein




Client Betriebssysteme ?

Virenscanner Symantec

Mailserver Über Provider

Mail Clients Outlook 2000 / 2007

Mailing Security over Frontbirdge Nein


Datenbankserver Nein

Backup / Restore Bandlaufwerke

Webserver Nein


Tabelle 12 - Übersicht Ist-Zustand Graz laut Fragebogen


74

Tabellarische Übersicht Ist-Zustand Linz laut Fragebogen

IT Verantwortlicher Systemadmin Wien

Serverraum verfügt über USV? Ja

Serverraum ist Klimatisiert? Nein

Serverraum ist über Zugangskontrolle gesichert? Nein

WAN Anbindung ADSL

WAN Provider Atello


Public IP-Bereich





Vorhandene Switchen Netgear FS 1116

WLAN Netgear WLAN Access Point


Print Server Vorhanden




Client Betriebssysteme Windows 200 | XP | Microsoft DOS

Virenscanner Symantec

Mailserver Über Provider

Mail Clients Outlook 2000 / 2007

Mailing Security over Frontbirdge Nein


Datenbankserver Nein

Backup / Restore Bandlaufwerke

Webserver Nein

Sonstige Server Nein

Tabelle 13 - Übersicht Ist-Zustand Linz laut Fragebogen


75

3.2 Soll-Konzept

Die Bizerba Landesgesellschaft in Österreich soll, wie im Bizerba Masterplan beschrieben, in das

globale Datennetzwerk der Bizerba GmbH & Co. KG integriert werden. Die Verbindung zum

Headquarter in Balingen sowie zu den anderen Außenstellen soll, wie bei den bereits integrierten

Lokationen mittels eines Meshed Networks, basierend auf VPN-Tunneln realisiert werden. Der

SAP-Rollout für Österreich muss auf Grund der etwas verzögerten Eudat-Portierung auf absehbare

Zeit verschoben werden. Deshalb wird die Landesgesellschaft weiterhin mit dem bisher eingesetz-

ten Eudat-System arbeiten. Hierfür wird der Eudatserver in der österreichischen Zentrale in Wien

beibehalten. Da Wien mit 70 Mitarbeitern eine relative große Lokation innerhalb der Bizerba ist,

erhält Österreich einen eigenen Domänencontroller, welcher in die Domäne Bizerba.com integriert

wird. Die Exchange-Postfächer hingegen werden für alle Außenstellen zentral in Balingen verwal-

tet. Auch die bisher verwendete Bizerba.co.at wird nach Balingen portiert. In Zukunft wird jedoch

sämtlicher Email Verkehr über Bizerba.com statt finden. Die bislang in sämtlichen österreichischen

Bizerba-Lokationen verwendete VoIP-Telefonanlage, welche vom Provider Atelo bereitgestellt

wird, soll weiterhin verwendet werden. Firewall technisch werden in den diversen Lokationen un-

terschiedliche Systeme eingesetzt. In Wien wird aufgrund des hohen Personalbestands, sowie der

daraus resultierenden höheren netzwerktechnischen Anforderungen, ein Firewall-Cluster einge-

setzt. Beim Cluster handelt es sich um ein zukunftssicheres, durchsatzstarkes Firewall-System, be-

stehend aus zwei UTM-1 1050 Firewalls. Die vorhandene SDSL Kommunikationsleitung wird wei-

terhin verwendet. Die Bandbreite vor Ort beträgt 4 MBit/s Auch der SDSL Modemrouter der Firma

Zyxel wird weiterhin eingesetzt werden. Der Interne IP Adressenbereich welcher von 10.150.0.0

bis 10.150.255.255 geht wird beibehalten. Bizerba Österreich wurde beim ursprünglichen Netz-

werkaufbau bereits in die Globale IP-Segmentplanung aufgenommen. Die Verteilung der IP-

Adressen fungiert direkt über die Firewall, welche bei der Konfiguration eine IP-Range zu diesem

Zweck eingetragen bekommt. In den Außenstellen Bregenz, Graz und Linz sind jeweils lediglich

drei bis vier Mitarbeiter beschäftigt. Hinter den bislang schon existierenden Zyxel SDSL Router mit

Modemfunktion wird eine UTM-1 VPN Edge X16 Firewall installiert. Sämtliche weiteren Hardwa-

rekomponenten welche im Netzwerk benötigt werden, werden hinter der Firewall angebracht.

Hierbei werden, wie in Wien, die bereits vorhandenen Kabel und Switches verwendet. Der interne

IP-Bereich wird in den kleinen Lokationen folgendermaßen umgestellt.

� Linz von 192.168.53.0 | 255.255.255.0 auf 10.151.1.0 | 255.255.255.0,

� Bregenz von 192.168.0.0 | 255.255.255.0 auf 10.151.3.0 |255.255.255.0

� Graz 192.168.99.0 | 255.255.255.0 auf 10.151.2.0 | 255.255.255.0


76

Der Emailverkehr wird in Zukunft nicht mehr mittels POP3 welches von einem Email Provider be-

reitgestellt wird, sondern via Exchange auf Basis von SMTP realisiert. Die Kommunikation, der Da-

tenaustausch und die Sicherung der Servicedaten auf dem Novell System, werden zukünftig per

VPN-Tunnel erfolgen. Die standortübergreifende VoIP Telefonanlage welche ebenfalls mittels des

Zyxel SDSL Modems realisiert wurde, wird, so wie in Wien, weiterhin Bestand der Netzwerkstruk-

tur bleiben.


77

Abbildung 24- Sollzustand Bizerba Österreich


78

Abbildung 25 – Firewall Struktur Wien | Bregenz


79

Abbildung 26 – Firewall Struktur Graz | Linz


80

3.3 Projektplanung

Das Projekt ist in vier Grobphase gegliedert welche zum Großteil innerhalb des Bearbeitungszeit-

raums der Thesis durchgeführt werden. In der folgenden Aufzählung ist eine Übersicht der einzel-

nen Projektphasen sowie deren Teilaufgaben zu sehen.

Phase 1 – Vorbereitungsphase

� Ist-Zustands Fragebogen versenden / bearbeiten

� Ist-Zustandsaufnahme

� Ist-Zustandsanalyse

� Anfordern der Internetzugangsinformationen vom Provider

� Auswählen der Hardwarekomponenten

� Soll-Konzeption erstellen

� Hardware Bestellen

� Alternative WLAN Lösung entwickeln

Phase 2 - Konfigurationsphase

� Firewall Cluster konfigurieren

� Firewall Edges konfigurieren

� Firewall Management konfigurieren

� Domänencontroller installieren

� Domänencontroller konfigurieren

� Firewalls & Domänencontroller versenden

� Benutzer in HR Datenbank anlegen

� Benutzer im Active Directory anlegen

� Benutzer in Unternehmens Datenbank portieren

� IP-Adressen bei Scan Safe registrieren


81

Phase 3 - Installationsphase

� Firewall Cluster Wien in Betrieb nehmen

� Netzwerk Wien anpassen

� Domänencontroller Wien in Betrieb nehmen

� Clientsysteme Wien an die Domäne nehmen

� Firewall Graz in Betrieb nehmen

� Netzwerk Graz anpassen

� Clientsysteme Graz an die Domäne nehmen

� Firewall Linz in Betrieb nehmen

� Netzwerk Linz anpassen

� Clientsysteme Linz an die Domäne nehmen

� Firewall Bregenz in Betrieb nehmen

� Netzwerk Bregenz anpassen

� Clientsysteme Bregenz an die Domäne nehmen

Phase 4 - Nachbereitungsphase

� Auftretende Probleme / Fehler beseitigen

In der Nachfolgenden Grafik, welche mit Hilfe des Projektierungsprogramms Microsoft Projekt

2003 entstand, sind noch einmal die einzelnen Projektabschnitte inklusive der bearbeitenden Per-

sonalressourcen sowie der zeitliche Ablauf des Projekts visualisiert.


82

Abbildung 27 - Projektablaufplan


83

3.4 Security Analyse

Bevor die Landesgesellschaften ins Bizerba Corporate Network aufgenommen werden, müssen

gewisse Sicherheitsmaßnahmen an den zu integrierenden Standorten getroffen werden. Zuvor

muss jedoch der aktuelle Sicherheitsstand überprüft werden.

Jede Außenstelle der Bizerba Österreich ist mit einem Firewall-System direkt vor Ort ausgerüstet.

Bei den Geräten handelt es sich um Zyxel Firewalls vom Typ ZyWall 5. Am Standort Wien wird eine

Firewall vom Typ Symantec VPN-100 verwendet. Für die Symantec Firewall, welche in Wien ver-

wendet wird, ist kein Passwort mehr vorhanden, so dass der Zugriff auf diese nicht mehr möglich

ist. Die Zyxel Firewalls hingegen können konfiguriert werden und haben vereinzelt VPN-Tunnel

zwischen den Lokationen aufgebaut.

Der Virenschutz der einzelnen Rechnersysteme ist dem jeweiligen User frei überlassen. Aus diesem

Grund sind sämtliche Vertreter von Antiviren und AntiSpyware Software auf den System vorhan-

den, wie McAfee Virus Scan, McAfee Internet Security, Symantec Antivirus, Avira Antivir oder Kas-

persky Internet Security. Diese uneinheitliche Antivirusstrategie sorgt für Gefahren sowohl für die

einzelnen Clients als auch für das Netzwerk. Ein User, der keinen Virenscanner auf seinem System

installiert hat oder eine veraltete Version lädt Viren und andere Schadsoftware wie Trojaner gera-

dezu ein ins Netzwerk einzudringen. Die Infizierung der anderen Geräte, welche ebenfalls nicht

den aktuellen Stand der Antivirensoftware haben sind dadurch ebenfalls gefährlich. Servicetechni-

ker, welche Ihr Notebook auch in Kundennetzen betreiben, sind daher potentielle Überträger von

Schadsoftware. Falls dieses geschieht, können neben den Schäden die innerhalb des Netzwerks

der Landesgesellschaft auch enorme Schäden beim Kunden auftreten. Dies kann soweit führen

das Bizerba die Behebung des Schadens bezahlen muss und im schlimmsten Falle sogar den Kun-

den aufgrund solch eines Vorfalls verliert.

Die in den Lokationen vorhandenen Server sind entweder direkt im LAN oder sogar vor der Fire-

wall platziert worden. Sämtliche Server, FTP-Platten etc. wurden mit öffentlichen IP-Adressen aus-

gestattet. So sind unter anderem auch normale PCs von Außendienstmitarbeitern mit festen IPs

ausgestattet. Die Außendienstmitarbeiten greifen aus dem Internet über eine Remote Desktop

Verbindung auf ihre lokalen Maschinen zu um einen Datenabgleiche zwischen ihrem Notebook

und der lokalen Maschine durchzuführen. Hierfür ist eine Ausnahmeregelung auf der Firewall er-

forderlich, welche zu einer großen Security Lücke innerhalb des Netzwerks führt. Geräte, welche

im LAN integriert sind, werden mittels NAT auf öffentliche Adressen geleitet. Auch diese Sicher-


84

heitsvorkehrungen sind problematisch, denn die Geräte, welche direkt über eine feste öffentliche

IP Adresse verfügen und im LAN stehen sind in der Gefahr Opfer von Hacker Angriffen zu werden.

Falls die Hacker auf das System über eine entsprechende Sicherheitslücke kommen, oder sich gar

mittels Remote Desktop auf dem System authentifizieren können, befinden sich diese im LAN und

können somit auf sämtliche Geräte im LAN und damit auch die anderen Server sowie die Firewall

zugreifen und dort erheblichen Schaden anrichten.

Am Standort Wien wird bereits mit einem Domänencontroller, welcher die Domain bizerba.co.at

beheimatet, gearbeitet. Daher funktioniert an diesem Standort die Benutzerauthentifizierung an

den Rechnern über Domänenkonten, welche mit Hilfe von Active Directory verwaltet werden.

Auch die Rechtevergabe ist in Wien über das Active Directory System geregelt. Leider ist der Pass-

wort Änderungsoption auf „Never expires“ gesetzt, was bedeutet dass die Passwörter nie ablau-

fen. Wirtschaftsprüfer geben mittlerweile die feste Vorgabe, dass Passwörter mindestens 6 Zei-

chen lang sein müssen sowie alle 90 Tage geändert werden müssen. Es ist auch nicht möglich die

letzten 7 verwendeten Kennwörter wieder zu verwenden. Die anderen Österreichischen Service-

und Vertriebsstützpunkte sind nicht Teil der Österreichischen Bizerba Domänen Struktur. Diese

Standorte arbeiten in Arbeitsgruppen, in welcher jeder Client selbst regelt wer in welcher Form auf

welche Daten zugreifen darf. Eine zwingende Benutzerauthentifizierung an den Maschinen ist

nicht Pflicht und wird auch nicht zentral verwaltet so dass nicht jeder Benutzer sich auf jeder Ma-

schine mit seinem Profil anmelden kann. Fehlende Rechtevergabe, sowie die nicht zentrale Benut-

zerverwaltung sind auch hier Sicherheitslücken. So kann es vorkommen dass auf die Freigaben von

Dateien und Verzeichnissen auch Angreifer aus dem Internet gelangen können, falls die Firewall

falsch konfiguriert ist, bzw. Hintertüren wie feste die Vergabe von festen öffentlichen IP Adressen

für lokale Rechnern vorhanden sind.

Die Passwörter der Netzwerkkomponenten sind, nachdem ein Mitarbeiter das Unternehmen ver-

lassen hat, verloren gegangen, so dass weder auf die bestehenden Switchen als auch auf die Fire-

wall in Wien zugegriffen werden kann.

Die Datensicherung der Server wird mittels Bandlaufwerk realisiert. Hierfür ist in jedem Server ein

Bandlaufwerk zur Sicherung integriert. Die Netzlaufwerke, auf welchem die Daten der lokalen

Benutzer gesichert werden, werden ebenfalls mit Bandlaufwerken gesichert.


85

3.5 Gefahren für die IT-Infrastruktur

Wenn man von Gefahren für ein Netzwerk spricht unterscheidet man generell in Gefahren durch

Äußere- oder Innere- Einflüsse.

3.5.1 Externe Gefahrenquellen

Gefahren welche von Außen für ein Unternehmensnetzwerk existieren lauern meist im public

Internet. So besteht die Gefahr durch Downloads, die Installation entsprechender Software sowie

durchs reine surfen im Internet sich unbemerkt Schadsoftware auf den Computer zu laden. Es

folgt eine kleine Aufzählung von gängiger Schadsoftware:

� Viren

� Würmer

� Trojaner

� Exploit

� Backdoors

� Rootkits

� Spyware

� Phising

� DoS Attacken

� Sniffer

� Vulnerability Scanner 84

3.5.1.1 Viren

Bei Viren handelt es sich um Software oder Skripte welche sich schnell in einem Netzwerk durch

Reproduzierung verbreiten können. Die Infektion findet meist durch direktes Ausführen einer ent-

sprechend verseuchten Datei statt. Das Virus verbreitet sich direkt über das Netzwerk durch exter-

ne Datenträger oder durch Email Anhänge sowie Downloads von infizierten Dateien. Viren richten

direkte Schäden am Betriebssystem oder an entsprechender Anwendungssoftware an.

Vgl.: 84

[wikiSchadSW]


86

3.5.1.2 Würmer

Bei Würmern handelt es sich ähnlich wie bei Viren um Schädlingssoftware welche direkte Schäden

am Betriebssystem oder an Anwendungssoftware mit sich bringen. Im Gegensatz zu Viren benöti-

gen Würmer ein Wirt-System, wie ein Email-Client Programm, um sich zu verbreiten. Der Wurm

versendet sich selbst automatisch an alle Einträge des Adressbuchs und führt sich anschließend

beim Empfänger automatisch aus. Die Würmer tarnen sich beispielsweise als jpg Datei und wer-

den daher auf dem Zielsystem vom Empfänger manuell ausgeführt.

3.5.1.3 Trojaner

Trojaner, oder auch Trojanische Pferde genannt, sind Computerprogramme welche sich auf den

ersten Blick nicht als Schadsoftware, sondern als reguläre Anwendung zeigen. Im Hintergrund

jedoch werden von dieser Software Dinge ausgeführt, von denen der Anwender nichts direkt mit-

bekommt.

3.5.1.4 Exploit

Hierbei handelt es sich um ein Softwaretool oder Skript welches spezifische Schwächen eines Be-

triebssystems oder einer Anwendungssoftware ausnützt um diese direkt durch DoS Angriffe zu

attackieren oder um erweiterte Autorisierungsrechte auf dem System zu erlangen. Oftmals werden

solche Attacken auch weltweit Zeitgleich an vielen Rechnern durchgeführt. Oftmals werden auch

automatisierte Angriffe von den infizierten Rechnern auf ein zentrales Rechensystem durchgeführt.

3.5.1.5 Backdoors

Backdoors sind Hintertüren welche oftmals Entwickler oder auch Dritte in Software einbauen um

von außen Zugang auf das Programm oder gar den kompletten Rechner zu bekommen. Durch

Backdoors können z.B. Fernzugriffe auf das System statt finden, oder Daten ohne das Wissen des

Benutzers nach außen zum Verfasser der Backdoor gesendet werden.

3.5.1.6 Rootkits

Rootkits haben den Sinn Einbrüche auf ein System zu verschleiern. Diese Tools verstecken laufende

Prozesse vor dem Anwender damit dieser nichts von dem aktuellen Angriff mitbekommen sollen.

Auch zukünftige Einbrüche des Hackers werden auf diese Art vor dem System versteckt.

3.5.1.7 Spyware

Eine weitere Gefahr für die Daten des Systems besteht durch sogenannte Spyware. Diese Soft-

ware, welche sich oftmals hinter Bannern im Internet verbergen oder direkt in Applikationen als

Trojanisches Pferd implementiert sind, senden Daten welche sich auf dem System befinden an

Dritte.


87

3.5.1.8 Phishing

Phishing ist keine direkte Gefahr für das Unternehmensnetzwerk, jedoch ebenfalls kritisch für das

Unternehmen. Finanzabteilungen welche ihre Finanzgeschäfte per Online Banking ausführen sind

hierbei besonders gefährdet. Die Angreifer initialisieren eine gefälschte Internetseite, auf welche

an Stelle der eigentlichen Onlinebanking Seite zugegriffen wird. Durch die Eingabe der Benutzer-

authentifizierung und der TAN Nummern werden diese beim Angreifer gespeichert und dieser

kann mit den erhaltenen Daten entsprechende Kontenbewegungen ausführen.

3.5.1.9 DoS Attacken

Durch DoS Attacken versuchen Angreifer einen Dienst durch gezielte Überlastung abzustellen.

Hierbei wird meist der Netzwerkbroadcast so weit erhöht dass das System irgendwann völlig über-

lastet ist und seine Funktion heruntergefahren wird. Moderne Firewalls erkennen diese Angriffe

und blocken sie entsprechend ab.

3.5.1.10 Sniffer

Durch Sniffer wird der komplette Netzwerkverkehr gescannt. Hierbei werden z.B. Passwörter wel-

che im Klartext übertragen werden (FTP-Passwörter) mitgeschnitten. Auch Start- und Zieladressen

der Datenpakete können auf diese Art und Weise ermittelt werden und dadurch gefälschte Pakete

mit identischen Adressen versendet werden.

3.5.1.11 Vulnerability Scanner

Vulnerability Scanner durchsuchen Systeme gezielt auf Schwachstellen im System. Diese Scanner

können sowohl von Angreifern genutzt werden um eventuelle Sicherheitslücken zu erkenn oder

auch von Administratoren um Ihr System weiter abzusichern.


88

3.5.2 Interne Gefahrenquellen

Doch auch Intern lauern viele Gefahren für ein Computernetzwerk. z.B. durch:

� Externe Speichermedien

� WLAN Access Points

� Mobiltelefone mit Theadering Option / UTMS Karten

3.5.2.1 Externe Speichermedien

Mitarbeiter welche private, privatgenutzte oder extern genutzte USB Sticks oder andere Speicher-

medien Nutzen bringen über diese meist ohne Absicht Viren, Trojaner und andere Schadsoftware

ins Unternehmen. Diese Schadsoftware kann möglicherweise wiederum Lücken nach Außen für

weitere Eindringlinge erstellen.

3.5.2.2 WLAN-Access Points

Ebenfalls gefährlich ist es wenn Mitarbeiter ohne Wissen der IT Abteilung, illegale WLAN Access-

points, sogenannte Rough Access Points ins Firmennetzwerk installieren Diese Accesspoints sind

oftmals nur unzureichend oder gar nicht geschützt, so dass Hacker leichtes Spiel haben auf das

Netzwerk zugreifen zu können.

3.5.2.3 Mobiltelefone mit Theadering Option / UTMS Karten

Eine neue Gefahr bringen Handys mit Theadering Option sowie UTMS Karten mit sich. Mitarbeiter,

die über keinen Internetanschluss im Unternehmen verfügen können über solch eine Karte ungefil-

tert ins public Internet. Dadurch kann erheblicher Schaden durch Schad- und Fremdsoftware im

Unternehmensnetzwerk angerichtet werden.

3.5.2.4 Weitere Gefahrenquellen

Weitere Gefahrenquellen die sowohl durch interne als auch externe Schutzvorrichtungen verhin-

dert werden können sind:

� Key-Logger

� Social Engineering

� Physikalischer Zugang zu sensibler Hardware

3.5.2.5 Key-Logger

Es sind zwei verschiedene Spezies von Key-Loggern erhältlich, Software-Key-Logger sowie Hard-

ware-Key-Logger. Key-Logger haben es in erster Linie auf sensible Authentifizierungsdaten abge-


89

sehen. Bei Software-Key Loggern wird eine Software unbemerkt vom User auf dessen Rechner

installiert. Das Programm schneidet sämtliche Eingaben, sowie die Bildschirmausgabe mit und

speichert diese. Die Daten können dann entweder vom Angreifer physikalisch abgeholt oder vom

Programm automatisiert auf einen Server im Internet hochgeladen werden, von welchem aus der

Angreifer auf die Daten zugreift. Die zweite Variante ist eine hardwaretechnische Variante des

Key-Loggers, welcher zu Preisen von unter 30 € im Internet bestellt werden kann. Diese Geräte

werden zwischen der USB Tastatur und dem Computer angebracht und verfügen über eine sehr

hohe Speicherkapazität on bis zu mehreren GB. Im Gegensatz zu den Software Key Loggern

schneiden die Hardware Key Logger lediglich die Eingabe welche über die Tastatur statt findet mit.

3.5.2.6 Social Engineering

Unter Social Engineering versteht man eine gezielte Befragung von Mitarbeitern durch Hacker.

Diese gehen dabei mit psychologischen Techniken vor um das Opfer in ein Gespräch zu verwi-

ckeln. Die Angreifer bauen dabei eine sehr vertrauenswürdige Atmosphäre auf um über dieses

Gespräch an die gewünschten Informationen zu gelangen. Über diese Techniken werden z.B. Be-

nutzernamen, Passwörter oder auch Sicherheitslücken in Unternehmensnetzwerken ausgespäht.

Eine andere Form von Social Engineering ist es sich als andere Person auszugeben um durch Tele-

fongespräche oder Fragebögen an die gewünschten Daten zu gelangen.

3.5.2.7 Physikalischer Zugang zu sensibler Hardware

Oftmals sind Rechenzentren oder Computer, welche sicherheitskritische oder sensible Unterneh-

mensdaten enthalten nicht zugangsgeschützt. Dadurch bekommen Dritte, welche sich oftmals als

Handwerker oder Besucher ausgeben die Möglichkeit sich direkt auf die Hardware aufzuschalten.

Ein mögliches Szenario hierfür wäre ein mehrtägiger Handwerkereinsatz in einem Sensiblen Be-

reich. Einer der Handwerker installiert einen Key-Logger durch welchen er die

Authentifizierungsdaten der Maschine erhält. Anschließend hat dieser freies Spiel auf der Hardwa-

re und kann sich an sämtlichen Daten zu schaffen machen.


90

3.6 Konzeption einer alternativen WLAN Lösung

Bizerba betreibt in allen größeren Standorten auch WLAN Netze, welche über eine Cisco WLAN

Management betrieben wird. Das Cisco WLAN Management broadcastet insgesamt drei WLAN

Netze, welche sich in WLAN-Intern, WLAN-Test sowie WLAN-Guest aufteilt. Über das zentrale

Management werden die einzelnen Cisco Access Points angesteuert. Sämtliche WLAN User, wel-

che weltweit mit dem bislang bestehenden Bizerba WLAN verbunden sind, befinden sich im sel-

ben Netzwerksegment. Die Authentifizierung am WLAN wird über ein Zertifikat realisiert, welches

sämtliche Domänenmitglieder der Bizerba Domäne standartmäßig auf ihrem WLAN Device instal-

liert haben. Die Verschlüsselung des Datenverkehrs findet mittels einer WPA2 Verschlüsselung

basierend auf IKE statt. Da die Cisco Access Point sehr hohe Anschaffungskosten verursachen und

in den kleinen Lokationen kein Bedarf für die Netze WLAN-Guest sowie WLAN-Test besteht, soll

mittels der bereits vorhandenen bzw. die für Österreich geplanten, Check Point UTM-1 Edge W-

Series Geräten eine WLAN Zugriff auf das Bizerba Corporate Network realisiert werden. Ziel ist es

ein WLAN Netzwerk in den Außenstellen zu realisieren welches mit dem selben Zertifikat, wie

auch das WLAN-Intern in den größeren Bizerba Lokationen sicher funktioniert.

Die Check Point UTM-1 Edge W-Series haben von Haus aus einen WLAN-Adapter integriert, wel-

ches Übertragungsgeschwindigkeiten von WLAN Draft b/g liefert. Die Edge lässt lediglich die Op-

tion das WLAN als separates Netz zu betreiben. Eine reine, gesicherte HotSpot Funktion, bzw. eine

Integration in das Cisco WLAN Management ist auf diesem Weg nicht möglich. Da die Außenstel-

len nur über wenige Clients verfügen und im Moment drei Netze benötigen, bei welchen es sich

neben dem LAN und dem WLAN um eine DMZ handelt, haben wir uns dafür entschieden das

Netzwerksegment, welches für die Lokation vorgesehen war mittels Subnetting in vier Teilnetzte

zu unterteilen. Desweiteren ist die Entscheidung für vier Subnetze auch der zukunftssicherere Be-

schluss, da evtl. noch ein weiteres Netz hinzukommen könnte, wie z.B. ein Testnetz zum Test der

Ladenwaagenumgebung oder Ähnliches.

Nach einigen Versuchen und dem Studium des Check Point Sofa Ware Forums ist folgender Lö-

sungsansatz entstanden:

Der WLAN Ansatz für die Außenstellen beruht auf einem eigenen WLAN Netz welches die SSID

WLAN-Branch trägt. Das WLAN Signal wird mit einem AES basierten WPA2 verschlüsselt. Die Si-

cherheitsauthentifizierung für eine erfolgreiche Einwahl im WLAN findet über den Radius Server

statt. Der in Balingen stehende Radius Server hat die externe IP Adresse, welche aufgrund der ak-


91

tivierten Hide NAT Option auch auf diesem zur Authentifizierung aufschlägt, eingetragen. Wenn

das gemeinsam verwendete Shared Secret korrekt ist, wird der Domänenuser anhand des instal-

lierten Zertifikats authentifiziert. Das hier genannte Zertifikat wird vom Radius Server an alle WLAN

Clients welche an der Domäne sind übergeben, so dass eine Einwahl über dieses Zertifikat in Bi-

zerba Drahtlosnetze möglich ist. Im Firewall Management müssen sowohl das LAN als auch das

WLAN Netz der entsprechenden Lokation einer speziellen Gruppe hinzugefügt werden, damit der

Authentifizierungsversuch von der Firewall nicht geblockt wird.

Projektumsetzung | Matthias Pyka a

92

4. Projektumsetzung

In diesem Absatz wird der Fokus auf die eigentliche Projektumsetzung gelegt. So wird die Mana-

gementseige sowie die softwareseitige Konfiguration der Firewall-Systeme näher betrachtet. Auch

der Installationsvorgang vor Ort und die daraus entstandenen Probleme werden in diesem Kapitel

aufgezeigt.

4.1 Hardwareseitige Konfiguration

Sämtliche Konfigurationsbeschreibungen sind an das Client Betriebssystem Windows XP Profes-

sional, sowie an die Firmware R70, bei der Check Point UTM-1 1050 und V8.0.39 bei der Check

Point UTM-1 Edge W16 angepasst.

4.1.1 Check Point UTM-1 1050 Cluster

Ein Firewall Cluster besteht aus zwei identischen Firewall-Komponenten, welche in diesem Fall aus

zwei Check Point UTM-1 1050 Firewalls besteht. Die beiden Firewalls laufen im Hot-Standby-

Modus, was bedeutet, dass die volle Last über eine Maschine fährt, während sich die andere im

Standby befindet. Falls eine der beiden Maschinen ausfällt wird die andere Maschine aus dem

Standby erweckt und die Last läuft anschließend über die andere, funktionierende Maschine. Da-

mit die im Standby befindende Maschine weiß, dass das andere Gerät ausgefallen ist, Synchroni-

sieren sich die beiden Maschinen über ein separat definiertes Synchronisationsnetz.

Abbildung 28 - Check Point UTM-1 1050

Die hier beschriebenen Konfigurationsschritte müssen in dieser Form bei beiden Geräten des Fire-

wall Clusters durchgeführt werden.


93

4.1.1.1 Vorbereitende Schritte

Die Firewall muss zuerst an das Stromnetz, sowie über den LAN1 Port mittels eines Netzwerkka-

bels an den Konfigurationsrechner angeschlossen werden. Da die für Wien verwendeten Firewalls

gebrauchte Geräte sind, welche bereits bei Bizerba UK im Einsatz waren, müssen diese zuerst auf

Default zurück gesetzt werden. Dies wird per Konsolenzugriff realisiert, daher muss zusätzlich ein

Konsolenkabel an das Gerät angeschlossen werden. Auf dem Konfigurationsrechner muss neben

einem Browser auch das SSH und Telnet Tool Putty installiert sein. Um per WebGUI auf die Fire-

wall zugreifen zu können müssen die Netzwerkparameter umgestellt werden. Hierfür muss im

Betriebssystem folgender Befehlspfad durchgegangen werden: »Start« › »Systemsteuerung« ›

»Netzwerk und Internetverbindung« › »Netzwerkverbindungen«. Im nun erscheinenden Fenster

muss mit der rechten Maustaste auf die LAN Verbindung geklickt werden. Es öffnet sich ein Kon-

textmenü, in welchem der Menüpunkt »Eigenschaften« angewählt werden soll.

Im sich öffnenden Fenster ist eine Übersicht der Elemente zu sehen, welche diese Verbindung

verwendet. Unter Elementen sind diverse Clients, Dienste sowie Protokolle zu verstehen. Da die

Netzwerkkommunikation über TCP/IP erfolgt, kann die Einstellung der IP Adresse über einen Dop-

pelklick auf den Eintrag »Internetprotokoll TCP/IP« angepasst werden. In der folgenden Maske

können nun die Radiobuttons auf »Folgende IP Adresse verwenden« und »Folgende DNS-

Serveradressen verwenden« gesetzt werden. Da die Firewalls von Werk aus eine feste IP Adresse

haben, muss die IP Adresse »192.168.1.2« eingetragen werden. Die Subnetzmaske muss auf

»255.255.255.0« gesetzt werden. Die Felder Standardgateway sowie Bevorzugter DNS-Server und

Alternativer DNS-Server können frei gelassen werden. Anschließend muss das ganze mit »OK“

bestätigt werden. Unter Umständen muss die Netzwerkkarte nach diesem Schritt kurzfristig deak-

tiviert und anschließend wieder aktiviert werden, damit die Änderungen übernommen werden.

Die Deaktivierung bzw. Aktivierung der Netzwerkkarte wird im fester „Netzwerkverbindungen“,

welches folgendermaßen zu erreichen ist, bewerkstelligt. »Start« › »Systemsteuerung« › »Netzwerk

und Internetverbindung« › »Netzwerkverbindungen«. Rechtsklick auf die entsprechende LAN Ver-

bindung öffnet erneut das bereits bekannte Kontextmenü, in welchem der Punkt „Aktivieren“

bzw. »Deaktivieren« ausgewählt werden muss. Falls ein Proxyserver im Browser aktiviert ist muss

dieser ebenfalls abgeschälten werden. Im Microsoft Internet Explorer 8.0 funktioniert dies auf

folgende Art und Weise. In der Menüleiste des Browsers muss die Option »Extras« angewählt

werden, woraufhin sich ein Drop Down Menü bei welchem der Punkt »Internetoptionen« ange-

wählt werden muss. Es öffnet sich wiederum ein neues Fenster mit mehreren Reitern. Hier muss

der Reiter „Verbindungen« ausgewählt und in diesem der Button „Einstellungen« im Abschnitt der

LAN-Einstellungen betätigt werden. Im sich neu öffnenden Fenster muss nun gegebenenfalls der

Haken bei der Option »Proxyserver für LAN verwenden…« entfernt werden. Um diese Änderun-

gen zu übernehmen muss mit »OK« bestätigt werden.


94

4.1.1.2 Firewall auf Default zurücksetzen

Da das Gerät, wie bereits erwähnt, zuvor in Groß Britannien im produktiven Einsatz war, ist es

trotz der Umstellung der IP nicht möglich auf das Gerät per LAN Verbindung zuzugreifen, da die-

ses noch immer mit der IP Adresse von Bizerba UK konfiguriert ist. Aus diesem Grund muss das

Gerät über Konsole auf Default zurück gesetzt werden. Da wir bereits das Konsolenkabel ange-

schlossen haben müssen wir lediglich das Netzwerktool »Putty« öffnen. Im Programm muss der

Connection Type »Serial« angewählt werden. Anschließend wird mit dem »Open« Button eine

SSH-Verbindung zur Firewall geöffnet. Um die Firewall auf den Ursprungszustand zurück setzten

zu können muss diese neu gestartet werden. Diese funktioniert an dieser Stelle durch manuelles

aus- und einschalten des Geräts. Das Putty Kommandofenster zeigt nun den Bootvorgang der

Firewall an, welcher mit der Nachricht »Press any key to see the boot menu« für 5 Sekunden un-

terbrochen wird. An diesem Punkt muss eine Taste gedrückt werden.

Abbildung 29 - Screenshot: Auswahl Rücksetzen auf Factory default

Im darauffolgenden Auswahlmenü kann zwischen verschiedenen Startmodi gewählt werden so-

wie eine Rücksetzung der Firewall auf den Auslieferungszustand angestoßen werden. Es werden

zwei verschiedene Softwareversionsstände zur Rücksetzung angeboten, zum einen das etwas älte-

re Release 62 und zum anderen das Release 65. An dieser Stelle wird die Option »Reset to factory

Defaults – NGX (R65) with Messaging Security« ausgewählt und mit drücken der »Enter« Taste

bestätigt. Im Anschluss wird das System neu gestartet und dabei auf die Werkseinstellungen im

Release 65 zurückgesetzt.


95

4.1.1.3 Erster Start der Firewall

Nachdem das System erfolgreich mit den Werkseinstellungen wieder hochgefahren ist erscheint

im Putty Kommandofenster ein Authentifizierungsdialog. Der Default Administrationsbenutzer und

lautet »admin«, das dazugehörige Passwort ist ebenfalls auf »admin« festgelegt. Nach der ersten

Anmeldung verlangt ein Textdialog die Eingabe eines neuen Passwortes. Nach zweimaliger Einga-

be des neuen Kennworts verlangt das Firewall-System aus Sicherheitsgründen einen geänderten

Benutzernamen für den Administrativen User Account. Auch im Expert Modus, dem Read/Write

Zugriff der Firewall muss das Passwort geändert werden. Nach dem Regulären Login als Administ-

rator befindet man sich in einem Read-Only Modus, erst nach Login im Expert Modus können

auch Änderungen am System vorgenommen werden. Um in den Expert-Modus zu gelangen muss

der Befehl »expert« in die Konsole eigegeben werden. Nach Eingabe des Befehls erscheint eine

Authentifizierungsaufforderung, welche durch Eingabe des im Read-Only Modus gewählten Pass-

worts bestätigt werden kann. Anschließend wird auch hier die Eingabe eines neuen Kennworts

von der Firewall verlangt. Um die Anmeldung im Expert Modus zu umgehen, so dass der Benutzer

standardmäßig im Read/Write Modus gestartet wird, muss der Befehl »chsh –s /bin/bash <user-

name>« eingegeben werden. Falls dieser Modus wieder deaktiviert werden soll, so dass der Be-

nutzer sich automatisch im Read-Only Profil anmeldet kann das Kommando »chsh -s /bin/cpshell

<username>« verwendet werden. Der Logout wird mit Eingabe des Befehls »exit« getätigt.

4.1.1.4 Konfiguration der Firewall mit Hilfe des Installationwizards

Um auf das Web Interface der Firewall zugreifen zu können muss im Browser die URL

»https://192.168.1.1:4434« eingegeben werden. Nach Zustimmung des Zertifikats sowie nach der

Deaktivierung des PopUp Blockers erscheint eine Authentifizierungsmaske. Nach korrekter Eingabe

der Benutzerkennung öffnet sich ein PopUp in welchem die Firewall-Einstellungen getätigt werden

können. Wie bei der Check Point UTM-1 Edge W16 startet auch die Check Point UTM-1 1050

nach dem ersten Start der Weboberfläche einen Installationswizard. Im Gegensatz zur kleinen

Edge müssen bei der UTM-1 deutlich weniger Einstellungen getroffen werden, da diese sämtliche

weitere Informationen vom Firewall Management erhält.


96

Abbildung 30 – Screenshot: Authentifizierungsmaske WebGUI UTM

Im ersten Schritt des Wizards muss manuell das Datum und die Uhrzeit nach GMT+1 eingestellt

werden. Mit Klick des »Next« Buttons wird zum nächsten Schritt, der Konfiguration der Network

Connections weitergeleitet. Dieser Punkt wird später manuell konfiguriert und mit Aktivierung des

»Next« Buttons übersprungen. Auch die Einstellung der Routing Tabelle wird mit »Next« überflo-

gen. Bei den Einstellungen des Hosts, des Domain-Namens und der DNS Server müssen folgende

Einträge gesetzt werden, da dieses vom Wizard definierte Pflichtfelder sind.

� Hostname: ATWIEFW01 bzw. ATWIEFW02

� Domain Name: Bizerba.com

� First DNS Server: 10.1.1.100

� Second DNS Server: IP-Adresse externer DNS Server

� Third DNS Server: IP-Adresse externer DNS Server

Diese Einstellungen müssen wiederum mit dem »Next« Link bestätigt werden um zum nächsten

Schritt zu gelangen. Im nächsten Schritt wird der Management Type festgelegt. Dieser kann ledig-

lich an dieser Stelle im Wizard festgelegt werden. Über den normalen WebGUI kann diese Option

nicht verändert werden. Lediglich über Konsoleneingabe kann diese Einstellung noch vorgenom-

men werden. Da die Firewall über Provider-1 vom Managementserver in Balingen aus gemanaget

wird, wird hier die Option »Centrally Managed« angewählt und mit »Next« bestätigt. Der Punkt

List of allowed Web / SSH Users wird ebenfalls mit Klick des »Next« Buttons übergangen. Der Kon-

figurationspunkt Gateway Type verhält sich äquivalent wie der Punkt Management Type. Auch


97

diese Konfiguration lässt sich lediglich über den Wizard nach dem ersten Start der Firewall oder

über die Konsole ändern. Als Gateway Type wird hier die Option »This Gateway is am member of

a Cluster« verwendet, welches wieder mit »Next« der Konfiguration übergeben wird.

Abbildung 31 – Screenshot: Konfigurationswizard R70

Im letzten Schritt des Wizards muss noch die Secure Internal Communication festgelegt werden.

Die SIC wird benötigt um einen erfolgreichen Fingerprint mit dem Management zu erreichen. Hier-

für muss zweimal der Activiation Key, welcher auch dem Managementserver bekannt ist, einget-

ragen werden. Nach wiederholtem »Next« Klick erscheint eine Zusammenfassung der Konfigurati-

on. Mit Klick des »Finish« Buttons werden die Einstellungen für das Firewall System übernommen.

4.1.1.5 Konfiguration der Firewall Connections

Nach der erfolgreichen Übernahme der Einstellungen welche im Wizard getätigt wurden, können

nun die Connections konfiguriert werden. Hierfür müssen in der WebGUI nacheinander die But-

tons »Network« › »Connections« betätigt werden. Die folgenden Ports werden mit den Entspre-

chenden IP Adressen und den dazugehörigen Subnetzmasken konfiguriert: »DMZ«; »External«;

»Internal«; »LAN1«. Wichtig bei der Konfiguration für das spätere Update auf Software Release

R70 ist die Einstellung der Netzwerkgeschwindigkeit. Die Ports müssen für ein erfolgreiches Upg-

rade auf »Auto Negotiation« gestellt sein. Auf den Punkt »Update auf Release 70« wird im folgen-

den Abschnitt gesondert eingegangen.


98

4.1.1.6 Upgrade auf R70

Nachdem sämtliche Einstellungen, welche Hardwareseitig zu tätigen waren, erfolgreich umgesetzt

wurden, kann ein Softwareupgrade des Systems angegangen werden. Das Softwareupgrade kann

sowohl vor der Konfiguration als auch nach der Konfiguration durchgeführt werden.

Um das Upgrade durchführen zu können muss im Vorhinein das aktuelle Softwarerelease aus dem

Check Point Usercenter unter »https://usercenter.checkpoint.com/usercenter/index.jsp« geladen

werden. Bei Check Point Usercenter handelt es sich um einen geschlossenen Bereich, welcher le-

diglich für registrierte Check Point Kunden zugänglich ist.

Abbildung 32 - Screenshot: Upgradeoptionsmenü auf der UTM-1 1050

Nach erfolgreichem Download des aktuellen Softwarerelease kann unter dem Menüpfad »App-

liance« › »Upgrade« der Upgrade-Dialog der Firewall aufgerufen werden. Hierfür muss das herun-

tergeladene Systemupgrade auf die Firewall hochgeladen werden. Dies wird durch einen Klick auf

den Button »Upload upgrade package to appliance« eingeleitet. Im sich öffnenden Fenster kann

nun durch betätigen des »Durchsuchen« Buttons die entsprechende Upgrade-Datei ausgewählt

werden. Nach der Auswahlbestätigung der Upgrade-Datei durch klicken des »OK« Buttons kann

durch Ausführen der Schaltfläche »Start Upgrade« das Systemupgrade gestartet werden.


99

Der Upgrade-Vorgang teilt sich in folgende Phase:

� Uploading – Upgrade-Datei wird auf die Firewall hochgeladen

� Decompresing – Upgrade-Datei wird dekomprimiert

� Extracting – Upgrade-Datei wird extrahiert

� Taking a snapshot – Sicherung des aktuellen Stands wird vorgenommen

� Upgrading – Upgrade wird durchgeführt

� Reboot – Firewall wird mit neuem Softwarestand neu geladen

Nach dem Neustart des Firewall-Systems startet dieses mit dem neuen Softwarrelease R70.

4.1.2 Check Point UTM-1 Edge W16

Bei der Check Point UTM-1 Edge W16 handelt es sich um ein kleines Firewall-System. Die Edge

besitzt einen integrierten vier Port Gigabit LAN Switch, sowie Ports für DMZ, WAN und eine Seriel-

len Schnittstelle. Des weitern sind im Gerät zwei USB Schnittstellen sowie ein WLAN Modul integ-

riert. Die Gerätlizenz erlaubt den Einsatz von bis zu 16 parallelen Usersessions. Dieser Gerätetyp

wird in den Bizerba Lokationen in Bregenz, Graz und Linz eingesetzt.

Abbildung 33 - Check Point UTM-1 Edge W16

4.1.2.1 Vorbereitende Schritte

Der Rechner muss mit einem Patch-Kabel mit dem LAN1 Port der Edge verbunden werden. Um

später das WLAN einrichten zu können müssen auch die beiden mitgelieferten Antennen ans Ge-

häuse der Check Point UTM-1 Edge W16 angebracht werden. Bevor die hardwareseitige Konfigu-

ration der Edge beginnen kann, müssen am Rechner, von welchem aus die Konfiguration getätigt

wird einige Einstellungen getätigt werden. Um auf die Firewall zugreifen zu können muss die

Netzwerkkarte des Rechners auf DHCP gestellt sein, so dass die IP Adresse vom PC automatisch

bezogen wird. Die Vorgehensweise zur Anpassung der Einstellungen ist nahezu identisch mit der

Vorgehensweise bei der Konfiguration der Check Point UTM-1 1050. Einziger Unterschied ist, dass

im Eigenschaftsfensters des Internetprotokolls TCP/IP folgende Einstellungen getätigt werden müs-

sen. In der Konfigurationsmaske des TCP/IP Protokolls können nun die Radiobuttons auf »IP-

Adresse automatisch beziehen« und »DNS-Serveradresse automatisch beziehen« gesetzt werden.

Anschließend muss das Ganze mit »OK« bestätigt werden. Es kann vorkommen dass auch hier die

Netzwerkkarte, wie in den vorbereitenden Schritten bei der Check Point UTM-1 1050 beschrieben,

geresetet werden muss. Der Proxy sollte auch hier ebenfalls deaktiviert werden.


100

4.1.2.2 Erster Login

Nachdem die benötigten Voreinstellungen getätigt wurden, kann nun mit Hilfe des Browsers unter

der URL »http://my.firewall« erstmals auf die WebGUI Oberfläche der Firewall zugegriffen werden.

Beim ersten Zugriff auf die WebGUI Oberfläche ist dem Administrator Account „Admin“ noch kein

Passwort zugewiesen. Daher wird im ersten Schritt ein Passwort, welches aus Gründen der Fehler-

vermeidung zweimal eingegeben werden muss, festgelegt werden. Der Benutzernamen sowie das

Passwort wird später aus sicherheitstechnischen Gründen noch einmal abgeändert.

Nach erfolgreichem Login startet automatisch ein Wizard, welcher den Administrator bei der Kon-

figuration der Check Point UTM-1 Edge W16 unterstützen möchte. Da der Wizard nur wenige

Grundfunktionen der Edge konfiguriert, wird dieser abgebrochen und die Edge manuell konfigu-

riert.

Abbildung 34 - Screenshot: Authentifizierungsmaske WebGUI Edge


101

4.1.2.3 Konfiguration des Datums / der Uhrzeit

Als Erstes muss das Datum und die Uhrzeit angepasst werden. Hierbei wird die Zeit immer nach

der Zeitzone GMT+1 gestellt. Diese Einstellung wird völlig unabhängig vom Standort getätigt. Das

Setup des Datums und der Uhrzeit wird unter dem Menüpfad »Setup« › »Tools« › »Set Time« er-

reicht. An dieser Stelle öffnet sich das „Set Time Wizard“ Fenster. Hierbei sollte die Option »Your

computer’s clock« angewählt werden. Natürlich ist es eminent wichtig, dass im Vorfeld geprüft

wird ob sowohl das Datum als auch die Uhrzeit am Konfigurationsrechner korrekt ist. Mit Bestäti-

gung des »Next« Buttons wird der Vorgang mit dem aktualisierten Datum übernommen.

4.1.2.4 Internetverbindung konfigurieren

In diesem Abschnitt wird erklärt wie die WAN Port und damit die Internetverbindung konfiguriert

wird. Je nach Provider und Telekommunikationsanbindung müssen in diesem Punkt verschiedene

Einstellungen getroffen werden. In Folge werden die Einstellungen für die Edges, welche bei Bi-

zerba Österreich eingesetzt werden beschrieben. Bei den Anschlüssen handelt es sich jeweils um

ADSL Anschlüsse mit festem IP-Adress-Bereich, sowie mit unterschiedlichen Bandbreiten. Provider

ist die Österreichische Telekommunikationsgesellschaft Atello. (www.atello.at).

In der linken Navigationsleiste muss der Menüpunkt »Network« angewählt werden, anschließend

sollte in der oberen, sekundären Navigation, der Reiter »Internet« bereits aktiv sein.

Abbildung 35 - Screenshot: Konfigurationsmaske WAN Verbindung Edge


102

Hier muss die primäre Internetverbindung konfiguriert werden, indem man in der Sektion »Primary

LAN« die Option »Edit« auswählt. Im sich öffnenden Fenster müssen folgende Einträge gesetzt

werden:

� Port: WAN

� Connection Type: Local Area Network (LAN)

� IP Address: Subnetzmaske der Firewall

� Default Gateway: IP Adresse des Provider Routers

� Primary DNS Server: 10.1.1.100

� Secondary DNS Server: IP-Adresse öffentlicher DNS

� WINS Server: 10.1.1.101

Anschließend müssen die Einstellungen mit »Apply« bestätigt werden.

In den Deutschen Lokationen unterscheidet sich dieser Schritt minimal. Bei ADSL Anschlüssen der

Deutschen Telekom AG müssen an dieser Stelle die Authentifizierungsdaten des DSL Anschlusses

angegeben werden. In Österreich wird diese Authentifizierung über das ADSL Modem bewerkstel-

ligt.

4.1.2.5 Lokales Netzwerk konfigurieren

Es folgt die Einrichtung des Lokalen Netzwerks, welches über die LAN Ports ausgegeben wird.

Im Menüpunkt »Network«, in welchem bereits die Internetverbindung konfiguriert wurde, muss

auf den Reiter »My Network« in der sekundären Navigation gewechselt werden. Hier wird das

Lokale Netzwerk konfiguriert, indem im Menüabschnitt »LAN« der »Edit« Link angeklickt wird. Es

erscheint ein neues Fenster in welchem folgende Parameter eingetragen werden müssen:

� Mode: Enabled

� IP Adresse: 10.x.x.1 (Gateway Adresse)

� Subnetmask: 255.255.255.192

� Hide NAT: Enabled

� DHCP: Enabled

� Automatic DHCP Range: Disabled

� DHCP IP Range: 10.x.x.2 – 10.x.x.62

Im Anschluss müssen die Konfigurationen mit »Apply« gesichert und bestätigt werden. Da die IP

Adresse des LANs von Default, also von 192.168.1.1 auf 10.x.x.1 geändert wurde gibt es einen IP


103

Adressenkonflikt zwischen der lokalen Maschine und der Firewall. Durch den Kommandozeilenbe-

fehl »ipconfig /release« trennt sich die Netzwerkkarte von der Ihr zugeteilten IP Adresse. Im An-

schluss muss mit dem Befehl »ipconfig /renew« eine neue IP Adresse vom DHCP-Server der Fire-

wall angefordert werden.

Nach dem dieser Schritt erfolgreich war, ist eine Neuanmeldung durch Eingabe der IP als URL, im

Browser möglich. Um die LAN Einstellung fertig zu konfigurieren muss wieder der Menüpunkt

»Network« › »MyNetwork« › »LAN« › »Edit« angewählt werden. Jetzt müssen die DNS Einstellun-

gen getätigt werden, damit das Netzwerk auf die DNS und WINS Einstellungen, die im ganzen

Bizerba Corporate Network gelten zugreifen kann. Um diese Einstellungen tätigen zu können muss

in der erscheinenden Maske der Link »Options« im Bereich der DHCP Server Einstellungen ausge-

wählt werden. Folgende Einträge müssen an dieser Stelle gesetzt werden:

� Domain Name: Bizerba.com

� Auto. Assign DNS Server: Disabled

� DNS Server: 10.1.1.100

IP-Adresse öffentlicher DNS

� Auto. Assign WINS Server: Disabled

� WINS Server: 10.1.1.100

10.1.1.101

� Auto. Assign Def. Gateway: Disabled

� Default Gateway: 10.x.x.1

Mit »Apply« wird im Anschluss die Konfiguration erneut bestätigt.

4.1.2.6 Demilitarisierte Zone konfigurieren

Die Konfiguration der demilitarisierten Zone läuft identisch zur Konfiguration des Local Area Net-

works ab. Der wesentliche Unterschied liegt darin dass Bizerba eine anderes, spezielles Netzwerk-

segment zur Verwaltung der demilitarisierten Zonen verwendet.

4.1.2.7 Wireless Local Area Network konfigurieren

Auch hier läuft die Konfiguration ähnlich ab wie zuvor bei der Konfiguration der DMZ und des

LAN. Jedoch gilt es bei der WLAN Konfiguration einige Dinge zu beachten, auf welche ich hier

gesondert eingehe. Bereits bekannte Verfahren welche bei der Konfiguration des LAN und der

DMZ verwendet wurden werden von hier aus verwiesen. [siehe S. 90 - Konzeption einer alternati-

ven WLAN Lösung].


104

Bevor das WLAN eingerichtet werden kann, muss von Herrn Hans Gebert, Domänenadministrator

der Bizerba GmbH & Co. KG, die öffentliche IP Adresse der Check Point UTM-1 Edge W16 im Ra-

dius Server eingetragen werden. Diese wird in einer neuen Remote Access Policy eingetragen. Das

Shared Secret, welches für die Authentifizierung verwendet wird, wird von Herrn Gebert vergeben

und entsprechend an den Mitarbeiter der die Konfiguration der Edge tätigt weitergegeben.

Nach dem diese vorbereitenden Aufgaben abgeschlossen sind, muss auf der WebGUI der Firewall

im Menüpunkt »Users“ « der Reiter »Radius« ausgewählt werden. Im nun erscheinenden Fenster

werden die folgenden Daten, die von Relevanz bei der Authentifizierung der Benutzer am WLAN

sind, eingetragen.

� Address: 10.191.1.14

� Port: 1812

� Shared Secret: Wird von Hans Gebert festgelegt

� Time Out: 3 Seconds

Im nächsten Schritt wird, wie in Lokales Netzwerk Konfigurieren bereits beschrieben, das WLAN

konfiguriert. Einziger Unterschied hierbei sind die Wireless Settings, welche wie folgt eingetragen

werden müssen:

� Network Name SSID: WLAN-Branch

� Country: Austria (Je nach Lokation verschieden)

� Operation Mode: 802.11 b/g (11/54 Mbps)

� Channel: Automatic

� Security: WPA-Enterprise; EAP-authentication, encryption

� Authentication Server: Radius

� Require WPA2 (802.11): Enabled

� WPA Encryption: AES

»Apply« speichert die Änderungen. Die DNS- WINS- Gateway Einstellungen sind an dieser Stelle

wieder identisch zu den Einstellungen im Local Area Network.

Die clientseitigen Änderungen für den WLAN Zugriff sind bereits ab S.90 - Konzeption einer alter-

nativen WLAN Lösung zu finden.


105

4.1.2.8 Firewall Management Einstellungen konfigurieren

In diesem Schritt wird beschrieben wie die Firewall Management Einstellungen konfiguriert wer-

den. Diese sind eklatant für die Kommunikation zwischen der Check Point UTM-1 Edge W16 und

dem Provider-1 Firewall Management.

In der Weboberfläche der UTM-1 Edge müssen unter dem Menüpfad »Setup« › »Management«

folgende Einstellungen getätigt werden um den administrativen Zugriff auf die Firewall zu regeln:

� HTTPS: Internal Network + IP Range

10.0.0.0 – 10.255.255.255

� SSH: Internal Network + IP Range

141.87.212.1 – 141.87.212.255

� SNMP: Internal Network + IP Range

10.0.0.0 – 10.255.255.255

� Community: Community Name

Durch diese Einstellungen ist der Zugriff über https auf den WebGUI nur aus dem internen Netz-

werk möglich, per SSH darf lediglich vom Managementserver aus zugegriffen werden, der SNMP

Zugriff ist ebenfalls lediglich aus dem internen Netzwerk gestattet. Durch diese Einstellungen darf

kein Rechner, der außerhalb des Bizerba Netzwerkes steht auf diese Geräte zugreifen. Die Com-

munity legt lediglich fest zu welcher VPN Community die Firewall gehört. Unter dem Link „SNMP

Konfiguration“ müssen noch folgende weiter Einstellungen getätigt werden:

� System Lokation: Lokation

� System Contact: Jens Ellinger

� SNMP Port: 161

� Send SNMP Traps: Enabled

� Send on SNMP Auth. Failer: Enabled

� Send on Link up / down: Enabled

� Trap Community: Community Name

� Trap Port: 162

� Trap Destination 10.1.100.144

� Trap Type: SNMPv1 Trap

An dieser Stelle wurde konfiguriert ob und in welchen Fällen SNMP Traps an ein bestimmtes Ziel

gesendet werden. Traps übergeben anhand ihrer TrapID, Fehlermeldungen und Warnings, wie

Kaltstart, Warmstart, Link down, Link Up, Authentifizierungsfehler sowie Systemfehler an das Ma-


106

nagement. Diese werden in einem Eventlog gespeichert und können entsprechend ausgewertet

werden. SNMP-Traps dienen dem Monitoring des Firewall Systems.

4.1.2.9 Verbindung zur Checkpoint Management aufnehmen

Dieser Schritt, der Letzte der hardwareseitigen Konfiguration der Check Point UTM-1 Edge W16,

kann erst am Installationsort getätigt werden. Voraussetzung für diesen Schritt ist neben den be-

schriebenen hardwaretechnischen Konfigurationen auch die managementseitige Konfiguration der

Edge.

Abbildung 36 - Screenshot: Erfolgreiche Connection zum Management

Unter dem Menüpfad »Services« › »Connect to a Service-Center« › »Connect« öffnet sich ein Pop

Up, in welches die IP Adresse des zu verbindenden Service Centers eingetragen werden muss. Mit

Betätigung des »Next« Buttons versucht die Firewall eine Verbindung zum Managementserver in

Balingen aufzubauen. Wenn diesem die anfragende Firewall bekannt ist wird im nächsten Schritt

die »Gateway-ID«, sowie der »Registration Key«, welche vorab im Management eingetragen wur-

den abgefragt. Unter der Gateway-ID versteht man den Namen der Firewall welcher nach einer

speziellen Namenskonvention aufgebaut ist. Mit ausführen des »Next« Links wird der Fingerprint

zwischen dem Service Center und der Firewall durchgeführt. Ist dies erfolgreich kann mit dem

»Finish« Button die Anmeldung am Management Server abgeschlossen werden. Nun werden vom

Management aus sämtliche VPN Tunnel aufgebaut sowie die Policy Rule, welche zuvor definiert

wurden auf die Maschine geladen.


107

4.2 Managementseitige Konfiguration

Die Provider -1 Umgebung ist in verschiedene Ebenen, sogenannte CMAs aufgebaut. Hier gibt es

eine sogenannte Global_Bizerba CMA welche als Globale Ebene über allen weitern CMAs steht. In

ihr sind sämtliche Gruppen, Regeln und Netze enthalten, welche Global für alle Firewall System

weltweit wichtig sind. Neben dieser Globalen CMA gibt es zwei weitere CMAs. Zum einen die

CMA_BAL_UTM, in welcher sämtliche Firewall Cluster sowie große UTM Systeme definiert sind.

Darüber hinaus sind in dieser CMA die spezifischen Firewall Regeln für diese Firewalls angelegt.

Die CMA_BAL_EDGES verhält sich äquivalent zur CMA_BAL_UTM, mit dem kleinen Unterschied

dass hier die UTM-1 VPN Edges, also die kleinen Firewall Systeme betreut werden.

Abbildung 37 - Aufbau Provider-1


108

4.2.1 Globale Netze & Gruppen anlegen

Bevor die Firewall Systeme angelegt werden können müssen im ersten Schritt die Netzwerke im

globalen Firewall Management implementiert werden. Dies geschieht in der »CMA Glo-

bal_Bizerba«. Durch Rechtsklick auf das »Network Objekt« › »Network« kann unter der Menüop-

tion „»Network…« ein neues Netzwerk angelegt werden.

Abbildung 38- Screenshot: Provider-1 Netzwerkübersicht

Für den Standort Wien, bei welchem ein Cluster System zum Einsatz kommt benötigen wir insge-

samt vier Netze. Das Netzwerk Wien mit der IP Adresse 10.150.1.0 | 255.255.255.0, die Netzwer-

ke für die VPN Einwahl auf beiden Firewalls mit den Adressen 10.150.2.0 | 255.255.255.0 bzw.

10.150.3.0 | 255.255.255.0 sowie eine DMZ mit der IP Adresse 192.168.152.0 |

255.255.255.192. Für die kleineren Lokationen in Bregenz, Graz und Linz werden nur drei Netze

benötigt. Hierbei handelt es sich jeweils um das LAN, das WLAN und eine DMZ. Die Netzwerke

der verschiedenen Standorte werden in folgender Übersicht noch einmal tabellarisch aufgeführt.


109

Name IP-Bereich

ATWIENT_10.150.1.0 10.150.1.0 | 255.255.255.0

ATWIENT_10.150.2.0_VPN 10.150.2.0 | 255.255.255.0

ATWIENT_10.150.3.0_VPN 10.150.3.0 | 255.255.255.0

ATWIENT_192.168.152.0_DMZ 192.168.152.0 | 255.255.255.192

ATBRENT_10.151.3.0 10.151.3.0 | 255.255.255.192

ATBRENT_10.151.3.64_WLAN 10.151.3.64 | 255.255.255.192

ATBRENT_192.168.152.192_DMZ 192.168.152.192| 255.255.255.192

ATGRANT_10.151.2.0 10.151.2.0| 255.255.255.192

ATGRANT_10.151.2.64_WLAN 10.151.2.128 | 255.255.255.192

ATGRANT_192.168.152.128_DMZ 192.168.152.64| 255.255.255.192

ATLINNT_10.151.1.0 10.151.1.0 | 255.255.255.192

ATLINNT_10.151.1.64_WLAN 10.151.1.64 | 255.255.255.192

ATLINNT_192.168.152.64_DMZ 192.168.152.64| 255.255.255.192

Tabelle 14 - Übersicht der anzulegenden Netze

Die folgenden Einstellungen sind für alle hier aufgeführten Netze identisch. Nach dem Ausführen

des »Network…« Befehls im Kontextmenü öffnet sich ein neues Fenster welches die Reiter »Gene-

ral« und »NAT« beinhaltet. Im Reiter »General« wird der Identifikationsname des Netzwerks fest-

gelegt. Der Name besteht aus der Landeskennung, der Städtekennung sowie der IP Adresse und

evtl. optional der Bestimmung des Netzes. Neben dem Namen müssen noch die Netzwerkadresse,

die Netzmaske sowie ein Kommentar angegeben werden. Im Kommentarfeld wird noch einmal

die Lokation, in welcher sich das Netzwerk befindet, erwähnt.

Abbildung 39 - Screenshot: Detailansicht Netzwerk anlegen im Provider-1


110

Die Option »Broadcast address« wird auf »Included« gesetzt. Die Broadcast-Adresse ist immer die

letzte Adresse im entsprechenden IP-Segment. Im Reiter »NAT« können die default Einstellungen

beibehalten werden. Das Ganze wird mit Druck des »OK« Buttons bestätigt.

Nachdem die Netze angelegt wurden, müssen diese in entsprechende Gruppen zugeordnet bzw.

entsprechende Gruppen angelegt werden. Gruppen dienen zur Übersichtlichkeit im Management

System. Gruppen werden über Rechtsklick auf den Konfigurationspunkt Groups angelegt. In der

Konfiguration einer Gruppe werden der Gruppenname wie auch ein Kommentar und die zugege-

hörigen Teilnehmer einer Gruppe ausgewählt.

Abbildung 40- Screenshot: Provider-1 Gruppenübersicht

Die Gruppe »ATCNG_branch_networks« muss neu angelegt werden. In dieser Gruppe werden die

drei bisherigen kleinen Lokationen, welche neben dem Headquarter in Wien angebunden sind,

integriert. Hierbei werden die Netze »ATBRENT_10.151.3.0«, »ATGRANT_10.151.2.0« und »AT-

LINNT_10.151.1.0« in die Gruppe aufgenommen. Die Gruppe »ATCNG_branch_networks« wird

für die VPN Encryption in der Gruppe »VPN_ENC_ATWIE« verwendet.


111

Die Gruppe »CNNT_GLOBAL« existiert bereits. In ihr werden sämtliche lokalen Netzwerke der ein-

zelnen Standorte definiert. So müssen auch die folgenden Netze dieser Gruppe hinzugefügt wer-

den.

� ATWIENT_10.150.1.0

� ATBRENT_10.151.3.0

� ATBRENT_10.151.3.64_WLAN

� ATGRANT_10.151.2.0

� ATGRANT_10.151.2.64_WLAN

� ATLINNT_10.151.1.0

� ATLINNT_10.151.1.64_WLAN

Die Gruppe »CNNT_GLOBAL« wird wiederum in den Gruppen »Protected« und »Protec-

ted_noDMZ« verwendet. Diese Gruppen werden wiederum in diversen Firewall Regeln verwendet

welche den Zugriff per Secure Client regeln Die Mitglieder dieser Protected Gruppen dürfen unte-

reinander ausschließlich verschlüsselt kommunizieren.

Abbildung 41- Screenshot: Detailansicht Gruppe anlegen im Provider-1


112

»CNNT_DMZ« besteht ebenfalls schon als Gruppe. Diese Gruppe beinhaltet sämtliche DMZ Netz-

werke innerhalb des Bizerba Corporate Networks. So müssen auch die neu angelegten Österrei-

chischen DMZ Netzwerke hinzugefügt werden.

� ATLINNT_192.168.152.64_DMZ

� ATGRANT_192.168.152.128_DMZ

� ATBRENT_192.168.152.192_DMZ

� ATWIENT_192.168.152.0_DMZ

Diese Gruppe wird ebenfalls in der Gruppe »Protected« verwendet. Für diese Gruppe gelten die

Selben Eigenschaften in Sachen Weiterverwendung wie in der Gruppe »CNNT_GLOBAL«.

Die »VPN_ENC_Groups« müssen für alle Standorte neu erstellt werden. Hierbei handelt es sich um

eine Gruppe welcher rein für die Bekanntmachung zwischendem WLAN und dem LAN Netzwerk

in der VPN Encryption dient.

� VPN_ENC_ATBRE

� ATBRENT_10.151.3.0

� ATBRENT_10.151.3.64_WLAN

� VPN_ENC_ATGRA

� ATGRANT_10.151.2.0

� ATGRANT_10.151.2.64_WLAN

� VPN_ENC_ATLIN

� ATLINNT_10.151.3.0

� ATLINNT_10.151.1.64_WLAN

� VPN_ENC_ATWIE

� ATWIENT_10.150.1.0

� ATWIENT_10.150.2.0_VPN


In die Gruppe »CNNT_VPN-POOL« werden sämtliche Office Mode Netzwerk, also Netzwerke auf

welche in dem Fall das Balingen per Secure Remote Einwahl nicht mehr erreichbar ist, eine Ver-

bindung hergestellt werden kann. Hierfür müssen ebenfalls die entsprechenden Wiener VPN_Pools

hinzugefügt werden.




113

Da diese Schritte auf der globalen CMA geschehen sind müssen diese, damit die Firewalls bei der

Installation auf diese Netze zugreifen können diese Einstellungen speichern und in die darunterlie-

genden CMAs, also die »CMA_BAL_UTM« und die »CMA_BAL_EDGES« replizieren.

4.2.2 Anlegen des Firewall Clusters

Im nächsten Schritt der managementseitigen Konfiguration der Firewall Systeme legen wir das

Firewall Cluster für Wien in der »CMA_BAL_UTM« an. Hierfür muss im Bereich der »Network Ob-

jekts« mit der rechten Maustaste auf dem Objekt »Check Point« der Menüpunkt »Security Cluster«

im Kontextmenü ausgewählt werden. Nach dem Aufruf erscheint ein Dialogfenster in welchem

zwischen »Simple Mode« und »Classic Mode« ausgewählt werden kann. An dieser Stelle sollte der

»Classic Mode« verwendet werden. Im sich öffnenden Fenster müssen folgende Konfigurations-

punkte abgearbeitet werden:

� General Properties

� Cluster Members

� Topology

� VPN

� Remote Access

� Authentication

� SmartDirectory (LDAP)

Abbildung 42 - Screenshot: Anlegen eines Firewall Clusters im Provider-1


114

Im Menüpunkt »General Properties« in der Unterrubrik »Machine«, muss der Name des Firewall

Clusters sowie dessen Öffentliche IP Adresse über welche das Cluster später kommuniziert einget-

ragen werden. Im Comment-Feld wird als Kommentar der Standort des Clusters zur Vereinfachung

der Identifikation gesetzt. In der Unterrubrik »Plattform« muss der Hardwaretyp, in unserem Fall

»UTM-1« die Software Version, hier »R70«, sowie das Operating System, »Secure Platform« aus-

gewählt werden. Im Bereich »Software Blades«, ein Produkt aus dem Hause Check Point welche

verschiedene Parameter bei der Network Security setzt, muss die Auswahl der List Box auf

»Other« gestellt werden. In diesem Zusammenhang müssen im Feld »Network Security« folgende

Checkboxen aktiv sein:

� Firewall

� IPSec VPN

� Policy Server

� IPS

� Monitoring

� ClusterXL

Im Konfigurationspunkt »Cluster Members« werden an dieser Stelle die beiden UTM-1 1050 Fire-

walls, welche das Firewall Cluster in Wien bilden durch betätigen des Pfads »Add« › »New Clus-

termember« hinzugefügt. Für beide Maschinen sind die folgenden Schritte identisch durchzufüh-

ren. Im sich öffnenden Eigenschaftsfenster des Clustermembers müssen im Reiter »General« der

Name der Firewall, die öffentliche IP Adresse der Maschine, sowie als Kommentar der Standort

sowie die Modulnummer der jeweiligen Maschine eingetragen werden. Die Default Einstellungen

im Reiter „»NAT« können bei belassen werden. Im Reiter „VPN« soll die Checkbox »Offer Manual

Office Mode« aktiviert sein sowie der Option »Allocate IP Adresses from network« das bereits an-

gelegte globale Netzwerk »ATWIENT_10.150.2.0_VPN« bzw. für das zweite Modul das Netzwerk

»ATWIENT_10.150.3.0_VPN« zugewiesen werden. Anschließend werden die Einstellungen des

Firewallmoduls mit »OK« bestätigt.

Der Konfigurationspunkt »Topology« werden die Interfaces der Clustersysteme definiert, welche

sich auf die zuvor bereits definierten Netze beziehen. Nach Klick des Buttons »Edit Topology« wer-

den die Interface des DMZ Ports, des Internal- und External-Ports sowie des LAN1 Ports definiert.

Wichtig hierbei ist, dass die Namen der Interfaces auch den realen Namen der entsprechenden

Schnittstellen entsprechen. Des weitern muss hier die Option »Enable Extended Cluster Anti-

Spoofing« aktiviert sein. Im Unterbereich »VPN-Domain« muss der Radiobutton auf »Manually

defined« mit dem Globalen Netzwerk »ATWIENT_10.150.1.0« gesetzt sein.


115

»VPN« ist der nächste Punkt welche konfiguriert werden muss. Hierbei müssen die VPN Communi-

ties »Remote Access« sowie »VPN Bizerba« hinzugefügt werden. Die Community »Remote Access«

berechtigt User, welche mit einer Check Point Einwahl Software arbeiten, Verbindung mit dem

Netzwerk hinter diesem Firewall Cluster aufzunehmen. »VPN-Bizerba« wird benötigt um die VPN

Tunnel des Meshed Networks zwischen den Firewall Systemen zu erlauben, da nur Mitglieder die-

ser Community untereinander Tunnel aufbauen können. Im Bereich »Repositor of Certificates avai-

lable to the Gateway« muss die entsprechende Zertifizierung für die Firewall eingetragen werden.

Abbildung 43- Screenshot: Topology Übersicht bei der Cluster Konfiguration im Provider-1

Im nächsten Schritt werden die »Remote Access« Einstellungen konfiguriert. Hierbei werden fol-

gende Optionen aktiviert um entsprechend per Remote Access auf das System zugreifen zu kön-

nen. Im Unterbereich »Hub Mode Configuration« wird die Option »Allow SecureClient to route

traffic through this gateway« aktiviert damit eingehende Verbindungen mittels des SecureClients

entsprechend geroutet werden. »NAT traversal« also NAT Überquerung muss »Support NAT trav-

sal mechanism« Aktiv sein sowie die Option »VPN1_IPSEC_encapsulation« im Bereich Allocated

port gesetzt werden. Die Gruppe ist bereits vorkonfiguriert und wird Global bei sämtlichen Fire-

wall-Systemen zur IP Tunnelung eingesetzt. Bei der »Visitor Mode Configuration« muss der »Sup-

port Visitor Mode« aktiviert sein, sowie Als Service »https« und als Machine’s Interface die Externe

IP Adresse des Clusters definiert werden.

Unter dem Konfigurationspunkt »Authentication« werden die möglichen Authentifizierungsme-

thoden bestimmt. Im Unterbereich »Authentication Schemes« werden die Checkboxen »Check

Point Password«, „»RADIUS«, »SecureID«, »TACACS« sowie »OS Password« auf aktiv gesetzt. Der


116

Session Timeout für die User Authentication beträgt 15 Minuten. Desweiternen muss beim »Au-

thentication Failure Track« die Option »Popup Alert« sowie bei der Benutzerberechtigung welche

sich auf dem Policy Server befinden.

Der nächste und letzte Konfigurationspunkt für die Managementseitige Installation des Firewall

Clusters ist die Einstellung der „SmartDirectory (LDAP)«. Hierbei wird der Timeout für LDAP Re-

quests auf 20 Sekunden gesetzt. Unter »Account Units Query« muss der Radiobutton auf »Se-

lected Account Units list« aktiv sein. Als »Selected Account Units« wird die Globale Gruppe »AD-

Bizerba« eingetragen in welche sämtliche Domänencontroller Bizerbas enthalten sind. Dieser

Dienst wird für den Zugang über den Check Point Secure Client benötigt. Die User Authentifizie-

rung findet hierbei über den Domänen-User statt. Die Authentifizierung am Domänencontroller

wird durch diese Einstellung erlaubt.

Im Anschluss an die eigentliche Konfiguration muss die Firewall noch einigen Netzwerkobjekten

wie Gruppen Netzwerken oder Communities hinzugefügt werden.

Das Firewall Cluster muss der Gruppe »CNFW_All« hinzugefügt werden. Dieser Gruppe gehören

sämtliche UTM Firewalls sowie Firewall Cluster an. Diese Gruppe wird für einzelne Regeln im Glo-

balen Regelkatalog des Managements verwendet.

Um bei der geregelten Kommunikation zwischen allen Teilnehmer des Bizerba Corporate Net-

works teilnehmen zu können muss das Cluster in der Community »VPN_Bizerba« enthalten sein.

Eine weiter Community welcher das Cluster hinzugefügt werden muss ist die Remote Access

Community. Über diese werden die Remote Access Zugriffe auf die System entsprechend verwal-

tet. Desweitern muss das Clustersystem bei anderen Netzwerkkomponenten, wie z.B. Mailservern

verwendet werden, damit diese ein NAT durchführen können.

Am Ende der Konfiguration müssen sämtliche Einstellungen gespeichert und die Information an

sämtliche Firewalls Welt-Weit repliziert werden, damit ein Kommunikationsaufbau zwischen den

Geräten stattfinden kann. Ansonsten werden alle Anfragen, welche vom Wiener Firewall Cluster

kommen geblockt.


117

4.2.3 Anlegen der Check Point UTM-1 Edge W16

Nachdem nun die das Firewall Cluster in Wien sowie sämtliche Netze und Gruppen erfolgreich

angelegt wurden, können nun die Edges in der »CMA_BAL_EDGES« auf der Provider-1 Umgebung

implementiert werden.

Abbildung 44- Screenshot: Übersicht Edges im Provider-1

Die Installation von Edges läuft im Grunde genommen gleich ab wie die der großen UTMs. Auch

hier muss mit der rechten Maustaste auf dem Konfigurationspunkt »Check Point« › »UTM-1 Edge

Gateway« eine neue Firewall Edge angelegt werden. Im sich öffnenden Fenster, in welchem das

UTM-1 Gateway konfiguriert werden kann, müssen folgende Unterpunkte abgearbeitet werden,

damit die entsprechende Firewall richtig am Management Konfiguriert ist.

� General Properties

� Topology

� VPN

� Logging


118

Den Anfang macht die Konfiguration der »General Properties«. Hier müssen der Name der Fire-

wall, die öffentliche IP Adresse des Firewall Gateways sowie im Kommentar der Standort des Sys-

tems festgelegt werden. Im Bereich »Trusted Communication« wird der Registration Key, die so-

genannte SIC eingetragen, welcher auf der Firewall Edge ebenfalls bei der Konfiguration eingetra-

gen wurde. Die SIC wird in diesem Fall für einen erfolgreichen Fingerprint zwischen Firewall Edge

und Firewall Management benötigt. Bei der Option Typ muss der entsprechende Firewall Typ aus-

gewählt werden, in unserem Fall wird die »UTM-1 Edge W Series« verwendet. In dieser Maske

müssen des weiteren noch die Checkbox „VPN“ sowie der dazugehörige Radiobutton »Connects

as site to site gateway« aktiv sein. Über diese beiden Einstellungen wird die Art der eingehenden

VPN Tunnels bestimmt. Diese Einstellung sagt dass nur Site-to-Site Verbindungen, also Verbindun-

gen zwischen Firewall Systemen zugelassen werden.

Nachdem diese Einstellungen getätigt wurden muss als nächstes die Topology der Edge eingerich-

tet werden. Folgende Netze müssen entsprechend ihrer Konfiguration und der Namen der Ports

angelegt werden:

� WAN

� LAN

� WLAN

� DMZ

Bei sämtlichen Topology Einträgen müssen die jeweilige IP Adresse, die dazugehörige Subnetmas-

ke sowie der Name des Interfaces, z.B. LAN und die Security Zone (InternalZone, WirelessZone,

DMZZone, etc.) gewählt werden. Mit Ausnahme des WAN Ports müssen bei allen anderen Topo-

logy Einträgen im Reiter »VPN Topology« die Radiobuttons „Internal“ sowie als IP Adresse hinter

dem Port die Option »Specific« mit entsprechender Auswahl des entsprechenden Netzes (z.B.

»ATBRENt_10.151.3.0« bei LAN Bregenz) getätigt werden.

Bei den VPN Einstellungen muss die Globale VPN Community »VPN_Bizerba« hinzugefügt werden.

Im letzen Schritt der managementseitigen Konfiguration muss das Logging der Edge entsprechend

konfiguriert werden. Hierfür müssen die beiden Checkboxen »Forward logs to Security Manage-

ment Server« sowie »Forward logs to Syslog Server« aktiv sein. Der Host, an welchen die Loggin-

ginformationen gesendet werden ist Global unter der Bezeichnung »DEBALCLM01« festgelegt.

Dieser muss entsprechend bei der Auswahl des Hosts eingetragen werden. Zusätzlich muss in ei-

nem weiteren Listenfeld der Service, der geloggt wird ausgewählt werden. Hier wird der »UDP

Syslog« verwendet.


119

Auch diese Firewalls müssen noch in bestimmte Gruppen und Communities hinzugefügt werden.

Wichtig ist die Integration in die VPN_Bizerba Community über welche sämtliche VPN Kommuni-

kation gesteuert wird. Auch in die Gruppe CNFW_EDGE_global« müssen die Geräte aufgenommen

werden. In dieser Gruppe sind sämtliche Edges implementiert.

Der letzte Schritt der Managementseitigen Konfiguration ist das Speichern sowie der Rebuild der

gemachten Änderungen auf der Policy auf sämtlichen Systemen.

Zusätzlich können an dieser Stelle in den untern CMAs auch spezielle Regeln angelegt werden, die

z.B. eine Kommunikation über spezielle Ports z.B. zur Österreichischen Bank erlauben. Auf diese

Regeln können aber aus sicherheitstechnischen Gründen hier nicht eingegangen werden.


120

4.3 Installation vor Ort

4.3.1 Wien

Abbildung 45 - Kartenübersicht Bizerba Wien

Für die Installation des Firewall Clusters, des Domänen Controllers inklusive Portierung sämtlicher

User auf die Bizerba.com Domäne und Anpassung des Netzwerks wurden 9 Mann-Tage veran-

schlagt. Die Installation des Firewall Clusters vor Ort sowie der Netzwerkanpassung wurde von

Herrn Jens Ellinger durchgeführt. Die Integration des Domänencontrollers sowie der Umzug der

vorhandenen Exchange Postfächern nahm sich Herr Hans Gebert an. Herr Gerhard Müller war in

Wien für die Integration der einzelnen Rechner an die Bizerba Domäne zuständig.

Um das Firewall Cluster installieren zu können musste zuvor die alte Firewall vom Netz genommen

werden. Anschließend wurde das Firewall Cluster an die Stelle der bisherigen Symantec Firewall im

Netzwerk angebracht. Der Versuch eine Verbindung zwischen dem Firewall Cluster und dem Fire-

wall Management in Balingen herzustellen um einen VPN Tunnel aufbauen zu können schlug im-

mer wieder fehl. Nach längerer Fehlersuche und erneuter hardwareseitige Konfiguration der Fire-

wall Module konnte das Problem immer noch nicht gelöst werden. Im Stand-Alone Betrieb arbei-

tete das Firewall Modul ATWIEFW02 sauber. Damit die weiteren Projektschritte nicht gefährdet

waren entschied man sich die Firewall vorerst im Stand-Alone Betrieb zu belassen. Die VPN-

Verbindung nach Balingen ist für die weiteren Schritte der Integration Wiens unabdingbar. Das als

ATWIEFW01 deklarierte Clustermodul hingegen wurde wieder mit nach Deutschland genommen


121

um dem Fehler auf den Grund zu gehen. Nachdem ein Support Ticket bei der Firma Check Point

gelöst wurde, konnten die Mitarbeiter von Check Point den Grund für den Fehler herausfinden.

Das Problem war kein technischer Defekt sondern ein lizenztechnisches Problem. Das Check Point

Lizenzsystem geht bei Firewall Clustern davon aus des es immer eine Master Firewall mit entspre-

chender Masterlizenz und eine entsprechende Slave Firewall gibt. Bei der Hardwareseitigen Konfi-

guration gab es eine Verwechslung zwischen zwei baugleichen Firewalls. So sind nach Österreich

anstelle von einer Master und einer dazugehörigen Slave Maschine zwei Master Maschinen bzw.

Stand-Alone-Maschinen versendet worden. Die Lizenz konnte vor Ort auch nicht entsprechend

angepasst werden, obwohl die Geräte exakt baugleich sind, da Check Point seine Hardwarelizen-

zen an die Jeweilige MAC-Adresse des Systems bindet. Der Grund für die Verwechslung der Sys-

teme konnte im Nachhinein ebenfalls ermittelt werden. Beim Update der Firewalls vom Typ UTM-1

1050 von R65 auf R70 gab es immer wieder zu größeren Problemen. Aus diesem Grund wurde ein

drittes Modell des Typs hinzugezogen um die Upgrade Vorgänge auf verschiedenen Geräten zu

testen. Bei diesem Schritt musste die Verwechslung der Systeme statt gefunden haben. Das richti-

ge System wurde zwischenzeitlich konfiguriert und wird bei der nächsten Gelegenheit in Wien

installiert.

Neben dem Firewall Problem gab es Netzwerktechnisch in Wien noch weitere Probleme mit wel-

chen nicht gerechnet wurden. So sind in Wien, wie auch später in den anderen Standorten FTP-

Festplatten aufgetaucht, welche im LAN integriert aber per NAT mit einer festen IP Adresse verse-

hen wurden. Bei diesen Festplatten handelt es sich um Hintertüren über welche relativ problemlos

ins Netzwerk eingedrungen werden kann. Gelöst wurde dieses Problem in dem die FTP-Festplatten

vorübergehend in einer DMZ untergebracht wurden. Die FTP Struktur der Bizerba Österreich muss

in einem weiteren Projektschritt neu aufgesetzt werden.


122

4.3.2 Graz

Abbildung 46 - Kartenübersicht Bizerba Graz

Die netzwerktechnische Integration in Graz wurde ebenfalls von Jens Ellinger übernommen. In

dieser Lokation wird in der vorhanden Arbeitsgruppe nicht mit DHCP sondern mit fest vergebenen

IP Adressen gearbeitet. So haben sämtliche Computer, wie auch Drucker feste IP-Adressen. Diese

Struktur musste aufgebrochen um auf DHCP umgestellt zu werden. Auch in Graz gab es wie in

Wien FTP-Festplatten welche ebenfalls im LAN integriert waren. Wie in Wien bekommen die Fest-

platten per NAT öffentliche IP-Adressen zugewiesen. Auch diese Platte wurde in eine DMZ ge-

nommen wie auch der dort ansässige Webserver. Eine weitere Sicherheitslücke im Grazer Netz-

werk waren Computer über welche der Verkaufsleiter per Remote Desktop Verbindung einen Da-

tenabgleich von extern durchführt. Diese Rechner sind mit öffentlichen IP Adressen ausgestattet

was wiederum zu Sicherheitslücken im Netzwerk führte. Diese Synchronisation ist in Zukunft nur

noch per VPN-Remote-Zugriff möglich. Problematisch war ebenfalls dass unbekannter Weise ein

VPN Tunnel von der Zyxel Firewall in Graz zur Zyxel Firewall in Klagenfurt bestand. Über diese Ver-

bindung werden Aufträge die von einem Servicetechniker in Klagenfurt bearbeitet werden vom

Einsatzleiter in Graz per Ausdruck auf dem Klagenfurter Drucker, versendet. Das Drucksignal wird

hierbei durch den genannten VPN-Tunnel gesendet. In Graz spielten neben netzwerktechnischen

Problemen auch menschliche Eitelkeiten eine Rolle. Der für Graz verantwortliche IT-Koordinator,

der das Netzwerk vor Ort sowie in Klagenfurt aufgebaut hat, fühlte sich durch die Integration in

das Bizerba Corporate Network etwas übergangen und war daher wenig kooperationsbereit bzw.

sehr kritisch gegenüber den neu entstandenen Möglichkeiten.


123

4.3.3 Linz

Abbildung 47 - Kartenübersicht Bizerba Linz

Der Standort wird netzwerktechnisch als Microsoft Arbeitsgruppe betrieben. Bis auf das Problem,

dass der FTP-Festplatte die öffentliche IP-Adresse zugewiesen wurde, welche eigentlich für die

Firewall bestimmt war, lief die Installation der Lokation Linz ohne Probleme.


124

4.3.4 Bregenz

Abbildung 48 - Kartenübersicht Bizerba Bregenz

Für die netzwerktechnische Integration des Standorts Bregenz war ich selbst verantwortlich und

durfte mit dem Kollegen Gerhard Müller gemeinsam die Lokation in das Bizerba Netzwerk integ-

rieren. Der Standort wird netzwerktechnisch als Microsoft Arbeitsgruppe betrieben. Vor Ort wurde

bereits mit DHCP gearbeitet so dass lediglich die Edge installiert und ein Tunnel nach Balingen

aufgebaut werden musste. Sämtliche Drucker und Server funktionierten relativ reibungslos. Ledig-

lich mit der WLAN Konfiguration gab es während der Netzwerkinstallation Schwierigkeiten welche

vor Ort nicht gelöst werden konnten. Das Problem wurde in der Testumgebung Balingen entspre-

chend abgebildet und durchgetestet. Im Firewall Tracking wurde anschließend gesehen dass die

Verbindung unverschlüsselt ankommt was am Fehlen der VPN Encryption zwischen WLAN und

LAN lag. Die Konfiguration konnte anschließend auf dem Management abgeändert werden und

nun entsprechend in der Lokation eingesetzt werden. Neben den netzwerktechnischen Problemen

gab es auch Probleme beim Umzug der Benutzer auf die Domäne Biezrba.com. Insgesamt musste

hierbei acht Rechner an diesem Tag an die Domäne genommen werden. Hierbei gestalteten sich

zwei Geräte als äußerst schwierig. Beide Geräte hatte betriebsystemseitige Probleme und mussten

zur endgültigen Problemlösung, bei welcher es sich um ein komplettes Recovery des Systems han-

delte, nach Balingen mitgenommen werden.

Fazit | Matthias Pyka a

125

5. Fazit

Der erste Schritt der Integration ist erfolgreich abgeschlossen. Trotz einiger Schwierigkeiten, wel-

che zumeist durch fehlende Informationen von Seiten der österreichischen Standorte aufkamen,

kann man davon ausgehen, dass alle Ziele der ersten Einführungsphase erreicht wurden. Daher ist

auch der Weg für die zukünftigen Projektphasen geebnet. So wird im nächsten Schritt das Service

Informations System welches zur Koordinierung der Servicetechniker dient, in der Alpenrepublik

eingeführt. Auch die Umstellung von EUDAT auf SAP befindet sich momentan in der Vorberei-

tungsphase. Neue Probleme schaffte hingegen die vorliegende FTP Struktur in Österreich welche

komplett überdacht und überarbeitet werden muss. Alles in allem kann trotz der aufgetretenen

Schwierigkeiten von einem positiven Projektverlauf gesprochen werden.

Für meine persönliche Entwicklung war das Projekt sehr interessant. Ich konnte eine Menge neues

Wissen rund um die Themen VPN, Firewalling und Networking mitnehmen. Auch die Erfahrungen

in der Check Point Provider -1 Umgebung welche zum Management der Netzwerke sowie der

Firewalls genutzt wird, bring mich in meiner persönlichen beruflichen Entwicklung vorwärts. Die

Mitarbeit im Team sowie am Projekt haben mir jederzeit sehr viel Freude bereitet.


126

5.1 Zusammenfassung

Die Ausgangssituation für dieses Projekt bestand darin, dass die Österreichische Bizerba Landesge-

sellschaft Netzwerktechnisch völlig autark zum Bizerba Corporate Network war. Auch Innerhalb

der Landesgesellschaft bestand das Netzwerk aus vielen Insellösungen mit völlig eigener IT-

Infrastruktur.

Ziel des Projekts war es nun die österreichischen Lokationen in das Bizerba Corporate Network zu

integrieren.

Um die Integration möglichst reibungslos durchzuführen musste im Vorfeld eine Ist-Analyse der

vorhandenen Infrastruktur gemacht werden. Anhand der Erkenntnisse des Antrittsbesuchs, sowie

der zuvor durchgeführten Befragung mittels Fragebögen, wurde ein Soll-Konzept erstellt. Die Fi-

rewall-Systeme, auf welchen die Kommunikation zwischen den Außenstellen beruht mussten pas-

send gewählt und im Vorfeld sowohl hardware- wie auch softwaretechnisch konfiguriert werden.

Die Installation vor Ort dauerte insgesamt sechs Arbeitstage. Während der Installation vor Ort

kamen diverse Probleme auf. Die meisten dieser Probleme konnten auf fehlende Informationen

aus den Fragebögen zurückgeführt werden. Einige Probleme, konnten direkt vor Ort gelöst wer-

den, andere, wie z.B. die Vertauschten Firewall-Systeme, mussten von Balingen aus nachgearbei-

tet werden.


127

5.2 Ausblick

In den nächsten Schritten des Projekts muss die FTP-Infrastruktur für Österreich völlig überarbeitet

werden. Die beiden Außenstellen Klagenfurt und Miels werden ebenfalls mit UTM-1 Edges ausges-

tattet und in die Domäne Bizerba.com aufgenommen. Weitere Ausbauschritte für Österreich sind

die neu Verkabelung des Bizerba Standorts in Wien, sowie die SAP Einführung in Gesamt Öster-

reich. Ein weiteres Projekt welches auf die Mitarbeiter der Bizerba Österreich zukommt ist die Ein-

führung des Service Informations System zur besseren Koordinierung der Servicetechniker und

Verbesserung der Ablaufprozesse. Ebenfalls zur Optimierung der Abläufe soll Microsoft CRM/CAS

für die Vertriebs- und Außendienstmitarbeiter der Bizerba Österreich eingeführt werden.

Anhang | Matthias Pyka a

128

Anhang

a. Webquellen

4mocADSL4mocADSL4mocADSL4mocADSL - Abgerufen am: 03.09.2009 Titel: ADSL - Asymmetric Digital Subscriber Line URL: http://www.4moc.com/FAQ/ADSL.htm

elkoADSLelkoADSLelkoADSLelkoADSL - Abgerufen am: 03.09.2009 Titel: ADSL - Asymmetric Digital Subscriber Line URL: http://www.elektronik-kompendium.de/sites/kom/0305235.htm

elkoSelkoSelkoSelkoSDSLDSLDSLDSL - Abgerufen am: 03.09.2009 Titel: SDSL - Single Pair Digital Subscriber Line URL: http://www.elektronik-kompendium.de/sites/kom/0305234.htm

elkoISDNelkoISDNelkoISDNelkoISDN - Abgerufen am: 03.09.2009 Titel: ISDN - Integrated Services Digital Network URL: http://www.elektronik-kompendium.de/sites/kom/0304011.htm

elkoKabelelkoKabelelkoKabelelkoKabel - Abgerufen am: 03.09.2009 Titel: Twisted-Pair-Kabel URL: http://www.elektronik-kompendium.de/sites/net/0603191.htm

elkoMPLSelkoMPLSelkoMPLSelkoMPLS - Abgerufen am: 03.09.2009 Titel: MPLS - Multi-Protocol Label Switching URL: http://www.elektronik-kompendium.de/sites/net/0811121.htm

elkoVDSLelkoVDSLelkoVDSLelkoVDSL - Abgerufen am: 03.09.2009 Titel: VDSL - Very High Speed Digital Subscriber Line URL: http://www.elektronik-kompendium.de/sites/kom/0305237.h

elkoVDSL1elkoVDSL1elkoVDSL1elkoVDSL1 - Abgerufen am: 03.09.2009 Titel: VDSL1 URL: http://www.elektronik-kompendium.de/sites/kom/1302131.htm

elkoVDSL2elkoVDSL2elkoVDSL2elkoVDSL2 - Abgerufen am: 03.09.2009 Titel: VDSL2 URL: http://www.elektronik-kompendium.de/sites/kom/0305236.htm

elkoVPNelkoVPNelkoVPNelkoVPN - Abgerufen am: 03.09.2009 Titel: VPN - Virtual Private Network URL: http://www.elektronik-kompendium.de/sites/net/0512041.htm

wikiFWwikiFWwikiFWwikiFW - Abgerufen am: 03.09.2009 Titel: Firewall URL: http://de.wikipedia.org/wiki/Firewall

wikiDocsiswikiDocsiswikiDocsiswikiDocsis - Abgerufen am: 03.09.2009 Titel: Over Cable Service Interface Specification URL: http://de.wikipedia.org/wiki/Data_Over_Cable_Service_Interface_Specification

wikiADSLwikiADSLwikiADSLwikiADSL - Abgerufen am: 03.09.2009 Titel: Asymmetric Digital Subscriber Line URL: http://de.wikipedia.org/wiki/Asymmetric_Digital_Subscriber_Line


129

wikiSDSLwikiSDSLwikiSDSLwikiSDSL - Abgerufen am: 03.09.2009 Titel: Symetric Digital Subsciber Line URL: http://de.wikipedia.org/wiki/Symmetric_Digital_Subscriber_Line

wikiVDSLwikiVDSLwikiVDSLwikiVDSL - Abgerufen am: 03.09.2009 Titel: Very High Speed Digital Subscriber Line URL: http://de.wikipedia.org/wiki/VDSL

wikiISDNwikiISDNwikiISDNwikiISDN - Abgerufen am: 03.09.2009 Titel: Integrated Services Digital Network URL: http://de.wikipedia.org/wiki/Isdn

wikiMPLSwikiMPLSwikiMPLSwikiMPLS - Abgerufen am: 03.09.2009 Titel: Multiprotocol Label Switching URL: http://de.wikipedia.org/wiki/MPLS

wikiIPSecwikiIPSecwikiIPSecwikiIPSec - Abgerufen am: 03.09.2009 Titel: IPsec URL: http://de.wikipedia.org/wiki/Ipsec

wikiAESwikiAESwikiAESwikiAES - Abgerufen am: 03.09.2009 Titel: Advanced Encryption Standard URL: http://de.wikipedia.org/wiki/Advanced_Encryption_Standard

wikiSchadSWwikiSchadSWwikiSchadSWwikiSchadSW - Abgerufen am: 03.09.2009 Titel: Schadsoftware URL: http://de.wikipedia.org/wiki/Schadprogramm abgerufen

itAdFWitAdFWitAdFWitAdFW - Abgerufen am: 03.09.2009 Titel: Bridging-Firewall URL: http://www.it-administrator.de/lexikon/bridging-firewall.html

itwEuroDocsisitwEuroDocsisitwEuroDocsisitwEuroDocsis - Abgerufen am: 03.09.2009 Titel: EuroDocsis (Euro data over cable service interface specification) URL: http://www.itwissen.info/definition/lexikon/EuroDOCSIS.html

pchFW pchFW pchFW pchFW - Abgerufen am: 03.09.2009 Titel: Die Firewall-Arten für Unternehmens-Netzwerke URL: http://pchilfe.org/wiki/Die_Firewall-Arten_f%C3%BCr_Unternehmens-Netzwerke

bizOE bizOE bizOE bizOE - Abgerufen am: 03.09.2009 Titel: Bizerba Produktpalette URL: http://www.bizerba-openworld.com

bizWeb bizWeb bizWeb bizWeb - Abgerufen am: 03.09.2009 Titel: Meilensteine URL: http://www.bizerba.com/de/unternehmen/ms_2007.html

bizbizbizbizIntraIntraIntraIntra - Abgerufen am: 03.09.2009 Titel: Bizerba Intranet


130

b. Literaturquellen

cpEdge cpEdge cpEdge cpEdge - Titel: Spezification Check Point UTM-1 VPN Edge W Series Autor: Firma Check Point

cpUTM cpUTM cpUTM cpUTM - Titel: Spezification Check Point UTM-1 1050 Autor: Firma Check Point

bizUP bizUP bizUP bizUP - Verfasst: 2009 Titel: Bizerba Unternehmenspräsentation Autor: Gross, Claudia – Bizerba GmbH & Co. KG

bizUP bizUP bizUP bizUP - Verfasst: 2009 Titel: Bizerba Unternehmenspräsentation Autor: Gross, Claudia – Bizerba GmbH & Co. KG

itHBkabel itHBkabel itHBkabel itHBkabel - Verfasst: 2005 Titel: Datenkabelaufbau Buch: IT-Handbuch Herausgeber: Westermann Seite: 186 Autor: Hübscher, H.-J | Petersen, C | Rathgeber, K | Richter,D |Scharf,D

itHBverkab itHBverkab itHBverkab itHBverkab - Verfasst: 2005 Titel: Strukturierte Verkabelung Buch: IT-Handbuch Herausgeber: Westermann Seite: 187 Autor: Hübscher, H.-J | Petersen, C | Rathgeber, K | Richter,D |Scharf,D

senetCE senetCE senetCE senetCE - Verfasst: 2009 Titel: moderner Netzwerktechnologien im Überblick (51) Whitepaper: www.searchnetworking.de Autor: Kauffels, D. F.-J

leiEuroDocsis leiEuroDocsis leiEuroDocsis leiEuroDocsis - Verfasst: 2007 Titel: EuroDocsis 3.0 - Einführung und Status Herausgeber: EuroCableLabs, Brüssel Autor: Leisse, V

itHBverkab itHBverkab itHBverkab itHBverkab - Verfasst: 2005 Titel: Strukturierte Verkabelung Buch: IT-Handbuch Herausgeber: Westermann Seite: 187 Autor: Hübscher, H.-J | Petersen, C | Rathgeber, K | Richter,D |Scharf,D

cpNGX cpNGX cpNGX cpNGX - Verfasst: 2007 Titel: Technische Sicherheitsmechanismen Buch: Check Point NGX - Standardwerk für FireWall-1 /VPN-1 Herausgeber: Computer & Literatur Autor: Leu, D. M. | Ochsmann, B

lipAnf lipAnf lipAnf lipAnf - Verfasst: 2001 Titel: Anforderungen an VPNs Buch: VPN- Virtuelle Private Netzwerke Herausgeber: Addison-Wesley Seite: 53-86 Autor: Lipp, M

lipSt lipSt lipSt lipSt - Verfasst: 2001 Titel: Sicherheitstechnologie Buch: VPN- Virtuelle Private Netzwerke Herausgeber: Addison-Wesley Seite: 87-144 Autor: Lipp, M

lipIPSeclipIPSeclipIPSeclipIPSec- Verfasst: 2001 Titel: Das IP-Security-Protokoll (IPSec). Buch: VPN- Virtuelle Private Netzwerke Herausgeber: Addison-Wesley Seite: 187-220 Autor: Lipp, M


131

lipAS lipAS lipAS lipAS - Verfasst: 2001 Titel: VPN - Aufbau und Sicherheit Buch: VPN- Virtuelle Private Netzwerke Herausgeber: Addison-Wesley Seite: 19-36 Autor: Lipp, M

lipVPNT lipVPNT lipVPNT lipVPNT - Verfasst: 2001 Titel: VPN-Typen Buch: VPN- Virtuelle Private Netzwerke Herausgeber: Addison-Wesley Seite: 37-52 Autor: Lipp, M

pykPB pykPB pykPB pykPB - Verfasst: 2009 Titel: Praxissemesterbericht Autor: Pyka M. – Bizerba GmbH & Co. KG

rehIWrehIWrehIWrehIW - Verfasst: 2009 Titel :Unternehmensnetzwerke ermöglichen Synergieeffekte Zeitschrift: Informationsweek Autor: Reh, H

tebMPtebMPtebMPtebMP - Verfasst: 1998 Titel: Bizerba Masterplan Autor: Tebbe, K.F. – Bizerba GmbH & Co. KG


132

c. Bildquellen

AbbildungAbbildungAbbildungAbbildung 18 18 18 18 - Verfasst: 2005 Titel: Datenkabelaufbau Buch: IT-Handbuch Herausgeber: Westermann Seite: 186 Autor: Hübscher, H.-J | Petersen, C | Rathgeber, K | Richter,D |Scharf,D

AbbildungAbbildungAbbildungAbbildung 19191919 - Verfasst: 2005 Titel: Strukturierte Verkabelung Buch: IT-Handbuch Herausgeber: Westermann Seite: 187 Autor: Hübscher, H.-J | Petersen, C | Rathgeber, K | Richter,D |Scharf,D

Abbildung Abbildung Abbildung Abbildung 28282828 Autor: Firma Check Point

AbbildungAbbildungAbbildungAbbildung 33333333 Autor: Firma Check Point

Abbildung Abbildung Abbildung Abbildung 45454545 Autor: Google Maps





133

d. Abkürzungsverzeichnis

ADSL Asymmetric Digital Subscriber Line

ADSL2+ Asymmetric Digital Subscriber Line 2 Plus

AES Advanced Encryption Standard

AH Application Header

AT Österreich

BAL Balingen

BRE Bregenz

CAS Customer

CAT1 Kategorie 1

CAT2 Kategorie 2

CAT3 Kategorie 3

CAT4 Kategorie 4

CAT5 Kategorie 5

CAT6 Kategorie 6

CAT7 Kategorie 7

CD Compact Disc

CMTS Cable Modem Termination System

CRM Customer Relationship Management

DES Data Encryption Standard

DHCP Dynamic Host Configuration Protocol

DIN Deutsches Institut für Normung

DMT Discrete Multitone

DMZ Demilitarisierte Zone

DNS Domain Name Service

Docsis Data Over Cable Service Interface Specification

DoS Denial of Service

DSLAM Digital Subscriber Line Access Multiplexer

ENC Encyption

ESP Encapsulating Security Payload

ETSI European Telecommunications Standards Institute

EuroDocsis European Data Over Cable Service Interface Specification

FTP File Transfer Protocoll

GB Gigabyte


134

GRA Graz

HDSL High Data Rate Digital Subscriber Line

HIDS Hostbasiertes IDS

HTTPS Hypertext Transfer Protocol Secure

ID Identifier

IDS Intusion Detection System

IETF Internet Engineering Task Force

IKE Internet Key Exchange

IP Internet Protocoll

IPSec Internet Protocol Security

IPV4 Internet Protocol Versoin 4

IPv6 Internet Protocol Versoin 6

IPX Internetwork Packet Exchange

ISDN Integrated Services Digital Network

ISO Internationale Organisation für Normung

IT Information & Telekommunikation

LAN Local Area Network

LIN Linz

LSP Label Switched Path

LWL Lichtwellenleiter

MD5 Message-Digest Algorithm 5

MPLS Multiprotocol Label Switching

MPoA Multiprotocol over ATM

NASA National Aeronautics and Space Administration,

NAT Network Adress Translation

NIDS Netzwerk basiertes IDS

NSA National Security Agency

NTBA Network Termination for ISDN Basic rate Access

NTSC National Television Systems Committee

OS Operating System

PAL Phase Alternating Line

PC Personal Computer

PoE Power over Ethernet

POP3 Post Office Protocol 3

POTS Plain old telephone Service

QAM Quadraturamplitudenmodulation


135

R65 Release 65

R70 Release 70

S/FTP Screened Foiled Twisted Pair

S/UTP Screened Unshielded Twisted Pair

SDSL Symmetric Digital Subscriber Line

SHA Secure Hash Algorithm

SIS Service Informations-System

SMTP Simple Mail Transfer Protocol

SNMP Simple Network Management Protocol

ssh Secure Shell

SSID Service Set Identifier

TAE Telekommunikations-Anschluss-Einheit

TAN Transaktionsnummer

TCP Transmission Control Protocol

UDP User Datagram Protocol

UMTS Universal Mobile Telecommunications System

USB Universal Serial Bus

UTP Universal Trunk Protoco

VDSL Very High Speed Digital Subscriber Line 1

VDSL1 Very High Speed Digital Subscriber Line 1

VDSL2 Very High Speed Digital Subscriber Line 2

VDSL2+ Very High Speed Digital Subscriber Line 2+

VHDSL Very High Speed Digital Subscriber Line

VLAN Virtual LAN

VOiP Voice over IP

VPN Virtual Private Network

VTU-O VDSL Transceiver Unit at the Optical Network Unit

VTU-R VDSL Transceiver Unit - Remote Terminal

WAN Wide Area Network

WIE Wien

WLAN Wireless Network

WPA2 Wi-Fi Protected Access 2


136

e. Spezifikationen der eingesetzten Firewall-Typen

Check Point UTM-1 1050

VoIP-Schutz SIp, H.323, MGCP und SCCP mit NAT-Unterstützung

Instant Messaging-Kontrolle MSN, Yahoo, ICQ und Skype

Peer-to-Peer Sperre Kazaa, GNUTella, BitTorrent

Network Adress Translation Unterstützung von Static/Hide NAT mit manuellen und au-

tomatischen Regeln

IPSec VPN

Verschlüsselungsunterstützung AES 128-256 Bit, 3DES 56-168 Bit

Authentifizierungsmethoden Passwort, RADIUS, TACACS, X.509, SecureID

Zertifizierungsstelle Integrierte Zertifizierungsstelle (X.509)

VPN-Communities Richtet Site-to-Site-Verbindungen automatisch bei der Ob-

jekterstellung ein

Topologieunterstützung Stern und Maschen

Route-basiertes VPN Nutzt virtuelle Tunnel-Schnittstellen; nummerierte / nicht

nummerierte Schnittstellen

VPN-Client-Unterstützung Komplette Endpoint-Sicherheit mit VPN, Desktop Firewall

SSL VPN

SSL-basierter Remote Zugriff Voll integriertes SSL VPN-Gateway ermöglicht bei Bedarf SSL-

basierten Zugriff

SSL-basiertes Endpoint-Scanning Durchsucht Endpoints nach Einhaltung/Maleware, bevor

diesen Zugang zum Netzwerk gewährt wird

Intrusion Prevention

Schutz auf Netzwerkebene Wehrt Angriffe wie DOS, Port-Scanning, IP/ICMP/TCP-

bezogene Angriffe ab

Schutz auf Anwendungsebene Wehrt Angriffe wie DNS Cache Poisoning, FTP Bounce, fal-

sche Befehle ab

Erkennungsmethoden Signaturbasiert und Protokollanomalie

Virenschutz / Spyware-Schutz


137

Virenschutz Schützt http-, FTP-, POP3- und SMTP-Protokolle

Spyware-Schutz Musterbasierter Spyware-Schutz am Gateway

Aktualisierungen Zentrale, tägliche Aktualisierung

Web Filtering

URL-Datenbank Mehr als 20 Millionen URLs decken über 3 Milliarden Web-

seiten ab

Sprachenunterstützung Mehr als 70 Sprachen in 200 Ländern

Aktualisierungen Zentrale, tägliche Aktualisierungen (mehr als 100.000 neue

Sites / Woche)

Messaging-Sicherheit

Email IPS Schutz vor SMTP-, POP3- und IMAP Angriffen

Musterbasierter Spamschutz Erkennt Spam basierend auf dynamischer Signaturdatenbank

IP-Reputation-Prüfung Sperrt Spam und Malware vom Absender

Signaturbasierter Virenschutz Erste Ebene des Viren- und Malwareschutzes

Zero-Hour Outbreak-Schutz Ergänzt den signaturbasierten Schutz um neue aufgetretene

Bedrohungen abzuwehren

Blockieren / Zulassen vom Listen Bietet granulare Kontrolle über bestimmte Domänen und

Benutzer

Management und Berichte

Zentralisierte Verwaltung Umfasst die zentralisierte Verwaltung

Überwachung / Protokollierung SmartView Tracker bietet erweiterte Überwachung und Pro-

tokollierung

Berichte Express berichte

Befehlszeilenschnittstelle Telnet, SSH

Netzwerke

DHCP-Unterstützung SecurePlatform DHCP-Server und –Relay

ISP-Redundant Protokollbasierte, Quelle /Ziel- und Port-Routen-

Entscheidungen

Routing-Unterstützung OSPF, BGP, RIP v1/2, Multicast

Layer-2-Bridge Unterstützung Lässt sich transparent in das bestehende Netzwerk integrie-

ren

Performance und Verfügbarkeit

Hohe Verfügbarkeit Active/passive und active/active Failover –Optionen

Load Balancing ClusterXL bietet nahezu lineare Skalierung

Quality of Service Floodgate-1 bietet granulare QoS-Kontrolle


138

ISP-Redundanz Leitet Datenverkehr automatisch zu zweiten Schnittstelle

weiter

Firewall-Durchsatz 1,2 GBit/s

VPN-Durchsatz 220 MBit/s

Gleitzeitige Sitzungen 800.000

Unterstütze Benutzer Unbegrenzt

VLANs 256

Speicherkapazität 80 GB

Gehäuse 1 U-Rack Montage

Abmessungen 43,5 mm x 426 mm x 431,8 mm

Gewicht 2,3 kg

10/100 Ports 4

10/100/1000 Ports 4

Betriebsumgebungsbereich Temperatur: 5°C bis 40°C

Luftfeuchtigkeit: 10 % bis 90 % nicht kondensierend

Höhe: 3.048 m

Leistungsaufnahme 100 – 240 VAC, 250 W

Stromverbrauch 186 W

Eingehaltene Normen UL 60950;

FCC Part 15, Subpart B,

Class A; EN 55024;

EN 55022;

VCCI V-3;

AS/NZS 3548:1995;

CNS 13438 Class A (Test bestanden; Landesgenehmigung

anhängig);

KN22, KN61000-4 Series, TTA;

IC-950;

ROHS

Tabelle 15 - Spezifikationen Check Point UTM-1 1050

85

Vgl.: 85

[cpUTM]


139

UTM-1 VPN Edge W16

Benutzer

Anzahl der Benutzer 16

Schnittstellen

10/100 Ports 4

10/100 WAN Port 1

10/100 DMZ / WAN2 Port 1

Serielle Schnittstelle 1

WLAN-Antennen 2

Firewall & Sicherheitsfunktionen

Firewall-Durchsatz 80 MBit/s

Gleichzeitige Sitzungen 8.000

Zustandsabhängige Ja

SmartDefense Ja

Schnittstellenbasierte- und Sym-

bolbasierte VLAN Unterstützung

Ja

Denial of Service Schutz Ja

Anti-spoofing Ja

Gateway Antivirus

Virenschutz Ja

Unterstützte Protokoll TP, IMAP, NBT, NUR, POP3, SMTP, UDP, sowie benutzerdefi-

nierte TCP Ports

On-the-fly Dekomprimierung Ja

Zentralisierter Virenschutz für

Emails

POP3, SMTP

VPN

VPN-Durchsatz 20 MBit/s

Site-to-site IPSec VPN Gateway Ja

Remote-Access VPN Gateway 10 Benutzer

Remote-Access aus dem internen

Netzwerk

Ja

VPN-1 SecuRemote Client Lizenz Inbegriffen

MS, 3DES, DES Verschlüsselung Ja

IPSec NAT überquerend Ja

Netzwerke


140

Datenübertragungsrate 108 MBit/s

WLAN Frequenzband 2,4 GHz

Maximale WLAN Reichweite 300m innen / 1000 m außen

WAN Zugriffsprotokolle DHCP, PPPoE, PPTP, Statische IP, Telestar

NAT statisch Ja

NAT verbergen Ja

DHCP Client, Relay, Server Ja

Dead Internet Connection Detec-

tion

Ja

OSFP dynamisches Routing Ja

Bandbreitenmanagement QoS Ja

Wireless Roaming Ja

USB-Modem Unterstützung Ja

Bridge Mode Ja

Tabelle 16 - Spezifikationen Check Point UTM-1 VPN Edge W16 86

Vgl.: 86

[cpEdge]


141

f. Bizerba GmbH & Co. KG

Die Bizerba GmbH & Co. KG ist ein weltweit operierendes Technologieunternehmen. Sie wurde

1866 gegründet und ist heute in vielen Bereichen der professionellen Systemlösungen der Wäge-,

Informations- und Food-Servicetechnik marktführend. Der Konzernumsatz betrug im Jahr 2008

rund 433 Mio. Euro. Es werden weltweit etwa 3.100 Mitarbeiter in 29 Gesellschaften beschäftigt,

welche sich in 22 Ländern und weiteren 60 Ländervertretungen befinden. Die Geschäftsführung

der Bizerba GmbH & Co. KG besteht aus vier Mitgliedern; Herrn Andreas Wilhelm Kraut (CEO),

Herrn Matthias Harsch (CSO), Herrn Martin Arndt (CTO) und Herrn Matthäus Holderied (CFO). Der

Hauptsitz der Bizerba GmbH & Co. KG ist in Balingen angesiedelt. In Deutschland befinden sich

außerdem eine Produktionsstätte von Food-Service-Maschinen in Meßkirch und eine Produktions-

stätte von Papier und Etiketten in Bochum. In Shanghai / China werden die Wäge-Plattformen für

den dortigen Markt hergestellt. In San Louis Potosi / Mexiko werden ebenfalls Food-Service-

Maschinen für den amerikanischen Markt produziert. Die Bizerba GmbH & Co. KG besitzt in vielen

Ländern eigene Landesgesellschaften. Hierbei handelt es sich meist um 100%ige Tochtergesell-

schaften. In ABBILDUNG wird der gesamte Aufbau der Bizerba GmbH & Co. KG, sowie die Anteile

von Bizerba an den jeweiligen Gesellschaften aufgezeigt. Zu den in Deutschland registrierten Toch-

tergesellschaften gehören die Bizerba Automotive GmbH (BAG), die Bizerba Leasing GmbH (BLG)

und die Juniorenfirma Bigefa GmbH. Die BAG entwickelt und fertigt neuartige technische Lösun-

gen zur Gewichtssensierung in PKWs. Sie ist der weltweit erste Hersteller von Weight-Sensing-

Systemen in Serienproduktion, welche ausschließlich auf dem US-amerikanischen Markt angebo-

ten werden. Die Bizerba Leasing GmbH bietet den Kunden individuelle Finanzierungskonzepte an.

Die Angebote beziehen sich schon seit einiger Zeit nicht mehr nur auf Bizerba Produkte sondern

umfassen auch PKWs, EDV Anlagen und Telefonanlagen. Die Bizerba Geschenke-, Fabrikations-

und - Handels GmbH (Bigefa) bietet den Auszubildenden des Unternehmens die Möglichkeit,

sämtliche betrieblichen Vorgänge und Abläufe in der betrieblichen Praxis nachzuvollziehen und

kennenzulernen. Diese Abläufe werden in der Berufsschule nur theoretisch behandelt und im Be-

trieb sind diese Vorgänge meist zu komplex oder durch die IT automatisiert. Die Bigefa gibt den

Auszubildenden also die Möglichkeit diese Vorgänge manuell durchzuführen und so die gelernte

Theorie noch besser in die Praxis umsetzen zu können.


142

Abbildung 49 - Bizerba Organisationsplan 87

Vgl.: 87

[bizInt]


143

Auszug aus dem Bizerba Produktsortiment

Produktsortiment Retail

� Stand-alone-Waagen

� System-Waagen

� Multimedia-Waagen

� Checkoutwaagen

� Kassensysteme

� Peripherie

Produktsortiment Food-Service

� Schneidemaschinen

� Verpackungsmaschinen

� Fleischwölfe

� Sägen

� Steaker

Produktsortiment Industry

� Terminals

� Dynamische Waagen

� EX-Systeme

� Präzisions- und Analyse Waagen

� Lastaufnehmer

� Fremdkörperdetektoren

� Kennzeichnungssysteme

� Papier & Etiketten

� Software 88

Vgl.: 88

[bizOW]


144

Meilensteine in der Unternehmensentwicklung

1866 Gründungsdatum, gegründet durch Eichmeister Andreas Bizer. Aus Bizer und Balingen

wurde Bizerba.

1906 Prof. Wilhelm Kraut kauft die Waagen Bauwerkstatt für 25.747 Goldmark

1923 Kraut Junior übernimmt Firma

1924 Erste Neigungsschaltgewichtswaage der Welt

1932 Erstes Zahlendruckwerk

1949 Erste Zählwaage

1951 Erste Waage der Welt mit optischer Preisanzeige

1969 Größte Waage der Welt – mechanische 600 Tonnen Gleisfahrzeug Waage

1981 Erste SB Waage von Bizerba

1990 Präzisionswaagen kommen zum Programm hinzu

1991 125 Jahre Jubiläum mit Einweihung neues Verwaltungsgebäude

1995 Umweltmanagement System wird installiert

1998 Homogene Retailsysteme – Waage und Kasse in einem

1999 Erste Systemwaage unter Win CE

2000 Erste Win CE Touchscreen Waage kommt in die Läden

2001 Entwicklung einer Schneidemaschine mit integrierter Portionierwaage

2003 Brotschneidemaschine BS38 für Öl freies scheiden vorgestellt, Erste Industriewaage auf PC

Basis

2004 CE Ladenwaagen werden zu videofähigen Multimediaterminals

2005 Neue modulare Checkout-Waagen-Lösungen für hohe Investitionssicherheit und Flexibilität

sowie bei den Ladenwaagen in PC-Technologie die automatische Bedienererkennung per

RFID-Technik. Eine Innovation für die Industrie sind die neuen Checkweigher XPro für

Nassbereich, ebenfalls in Kombination mit Metalldetektoren.

2006 Neues Design der CE Waagen für bessere Ergonomie und Benutzerführung. Der Automatic

Slicer A500 bekommt eine integrierte Portionierwaage zur automatischen Steuerung.

2007 Bizerba stellt TTI-Systemetikett mit Applikationstechnik, zur eindeutigen Erkennung von

unterbrochenen Kühlketten vor. 89

Vgl.: 89

[bizWeb]


145

Die Fachabteilung IT-O

Die Abteilung IT-O, unter der Leitung von Herrn Jörg Rudischhauser, gehört zum Bereich IT wel-

cher von Herrn Dr. Andreas Rebetzky geleitet wird. Die Abteilung besteht aus 13 Mitarbeitern, die

sich in drei Teams aufgliedern. Zum einen haben wir den IT-ServiceDesk, der in erster Linie den

täglichen IT Firstlevel Support im Unternehmen übernimmt. Neben den Supportaufgaben haben

die einzelnen Mitarbeiter des IT-ServiceDesk eigene Projekte, wie z.B. das Intranet das über Micro-

soft Office Sharepoint Server realisiert wird, die Überwachung und Pflege des McAfee Virenscan-

ners oder auch die Installation von Smartphones. Zu den Aufgaben der IT-ServiceDesk Mitarbeiter

gehört ebenfalls die Installation neuer Rechner, die Domänenadministration, die Inventarisierung

der ausgegebenen EDV, sowie das Testen neuer Hard- und Softwareprodukte.

Das zweite Team sind die sogenannten System Engineers, welche sich in erster Linie um die ser-

verseitige EDV Landschaft im Datacenter kümmern. So wird von dort aus unter anderem das

komplette SAP-System die IT-Infrastruktur (Netzwerk, Domäne, Mailing, Security, …) gepflegt und

gewartet. Auch neue IT-Strategien und die Einführung neuer Produkte in die Bizerba EDV Land-

schaft wird in der Regel von den System Engineers übernommen. Nebenbei arbeiten diese Perso-

nen im IT-ServiceDesk mit. Hier befassen Sie sich speziell mit den anfallenden systemseitigen Prob-

lemen. Für die weltweite Netzwerktechnik sind zwei weitere Mitarbeiter aus der Abteilung IT-O

zuständig. Sie planen, überwachen und konfigurieren das weltweite Bizerba Datennetz, welches

aus einer Vielzahl von Komponenten und IP-Bereichen besteht. Auch die Netzwerkprofis bearbei-

ten IT-Servicedeskfälle, welche sich aber speziell um netzwerktechnische Probleme drehen.


146

Bizerba Landesgesellschaft Österreich

Bei der österreichischen Bizerba-Waagen Gesellschaft m.b.H. handelt es sich um eine 100% Toch-

tergesellschaft der Bizerba GmbH & Co. KG, mit Hauptsitz in Wien. Die Geschäftsführer sind Herrn

Dipl. Wirtsch. Ing. Jörg Brunke sowie Herrn DI Manfred Schlawa. Bizerba Austria hat etwa 100

Beschäftigte, welche sich um den Vertrieb und Service von Bizerba Produkten in Österreich küm-

mern. Allein der Hauptsitz in Wien beschäftigt etwa 70 Mitarbeiter. Neben dem Vertrieb und dem

Service von Bizerba Produkten, werden in Wien auch Großwaagen und Lastaufnehmer gefertigt.

Neben Wien gibt es noch Verkaufs & Kundendienststellen in Bregenz, Mils, Salzburg, St. Georgen,

Linz, Zwettl, St. Pölten, Rothenthurm, Graz, Klagenfurt, Ebereichsdorf, Teesdorf und Großengers-

dorf. Österreich ist für die Bizerba GmbH & Co. KG einer der wichtigsten Märkte in Europa.


147

Bizerba Masterplan

Der Bizerba Masterplan ist eine 1998 entstandene dynamische Rahmendefinition der Bizerba IT-

Infrastruktur, die sich an aktuelle Anforderungen sowie neuste Innovationen anpassen lässt. Ent-

wickelt wurde der Bizerba Masterplan vom IT-Bereich der Firma unter der Führung des damaligen

Bereichsleiter Karl-Friedrich Tebbe. Ziele des Masterplans sind die Reduzierung der Vielfalt an ein-

gesetzten IT-Produkten, die Integration sämtlicher Unternehmensbereiche in die IT-Infrastruktur,

die Optimierung von Geschäftsprozessen, die Vermeidung gefährlicher Abhängigkeiten gegenüber

Dritter, die Einsparung von Doppelarbeit sowie die daraus resultierenden Einsparungen von Kos-

ten. Bevor der Bizerba Masterplan umgesetzt wurde, gab es im Unternehmen eine Vielzahl an

Betriebssystemen (Microsoft Windows, WangUS, Unix, DecNet, …) Anwendungs-, Datenbank-

und ERP-Systemen. Dies wurde folgendermaßen vereinheitlicht. Als Bizerba Standard Betriebssys-

tem wurde Microsoft Windows NT eingeführt. Aktuell wird im Haus auf Microsoft Windows XP

und Microsoft Windows 7 gearbeitet. Vereinzelt wird auch Windows Vista verwendet, welches

jedoch offiziell nicht vom Datacenter supportet wird. Als Office Suite wird ausschließlich das Mic-

rosoft Office Paket eingesetzt. Standard Datenbank bei Bizerba ist der Microsoft SQL Server. Be-

gründung für die Verwendung dieser Microsoft Produkte ist, dass es sich bei allen genannten Pro-

dukte um quasi Industriestandards handelt. Eine weitere Standardsoftware, welche Unterneh-

mensweit eingeführt werden soll, ist SAP. Auch im Bereich Netzwerktechnik wurden Rahmenbe-

dingungen eingeführt. Bereits 1998 wurde das TCP/IP Protokoll Unternehmensweit als Standard-

protokoll für die Vernetzung deklariert. Auch im Bereich der Programmiersprachen gab es im Mas-

terplan von 1998 Konzentrierungen auf 3 Sprachen. Damals handelte es sich hierbei um Visual

Basic, COBOL und C++. Heute beherrschen die Sprachen asp.net, Java und C++ die Bizerba Ent-

wicklungsabteilungen. Das Ziel der Masterplaneinführung sind die Optimale Auslegung einer neu-

en, sich stark im Wandel befindlichen Systemumgebung sowie die optimale Unterstützung bei

Störungen. Auch die optimale Administration und die bestmögliche Disaster Recovery Prozedur

sind Ziele des Masterplans. 90

Vgl.: 90

[tebMP]


148

Bizerba SAP Rollout

Aufgrund eines Beschlusses der Bizerba Geschäftsführung soll zukünftig in sämtliche Landesgesell-

schaften, wie auch Außenstellen SAP eingeführt werden. In Balingen wird bereits seit einigen Jah-

ren auf SAP Basis gearbeitet. Die für die Globale SAP Einführung benötigten Serversysteme stehen

im Datacenter in Balingen. Um weltweit auf diese zugreifen zu können wird eine Vernetzung

sämtlicher Lokationen vorausgesetzt. Ziel ist es durch den weltweiten Einsatz von SAP Kosten und

Zeit zu sparen, sowie Symbiose Effekte zu erzielen. Auch der Support durch spezialisierte Mitarbei-

ter kann durch ein zentralisiertes Rechenzentrum besser gewährleistet werden. Anstelle das admi-

nistrative Know-How mühevoll in die Außenstellen zu bringen, wo es nur sehr selten angewendet

werden kann und daher auch leicht wieder in Vergessenheit gerät, können speziell geschulte Mi-

tarbeiter in der IT, welche dieses Wissen regelmäßig anwenden, Support leisten. Die Kosteneinspa-

rungen können in erster Linie durch Personal- Hardware- und Lizenzkostenreduzierung erzielt

werden. 91

Vgl.: 91

[tebMP]

bachelorthesis

Documents