Linux advanced

I

Linux – Advanced

Erweiterte Serverdienste, Netzwerk Monitoring

Linux – Advanced 1

Inhaltsverzeichnis

1 TCP / IP.............................................................................................................................4 1.1 Open Systems Interconnection (OSI)-Referenzmodell.............................................4 1.2 Das TCP/IP-Referenzmodell ....................................................................................6 1.3 Die TCP/IP-Protokoll-Architektur ..............................................................................8 1.4 Internet Protokoll (IP)..............................................................................................10 1.5 Address Resolution Protocol (ARP)........................................................................18 1.6 Reverse Address Resolution Protocol (RARP).......................................................19 1.7 Internet Control Message Protocol (ICMP).............................................................20 1.8 Transmission Control Protocol (TCP) .....................................................................22 1.9 User Datagram Protocol (UDP) ..............................................................................26 1.10 Adressierung im TCP/IP .........................................................................................27 1.11 Subnetze ................................................................................................................28

1.11.1 Grundlagen .....................................................................................................29 1.11.2 Vorgehensweise zur Aufteilung in Subnetze ..................................................29

1.12 Classless Inter Domain Routing (CIDR) .................................................................33 1.13 Dynamic Host Configuration Protocol (DHCP) .......................................................34 1.14 Domain Name Service (DNS).................................................................................35 1.15 Übungsbeispiele .....................................................................................................38

2 Einrichten der Schulungsumgebung ...............................................................................41 2.1 VMware ..................................................................................................................41 2.2 Virtual PC ...............................................................................................................44 2.3 QEMU.....................................................................................................................50 2.4 Netzwerk – Installation ...........................................................................................53 2.5 Übungsbeispiele .....................................................................................................60

3 Serverdienste ..................................................................................................................61 3.1 Network File Service (NFS) ....................................................................................61

3.1.1 NFS - Server...................................................................................................61 3.1.2 NFS – Client ...................................................................................................64

3.2 DHCP – Server .......................................................................................................68 3.3 DNS – Server .........................................................................................................72

3.3.1 Forward Zone .................................................................................................75 3.3.2 Reverse-Lookup .............................................................................................78 3.3.3 Master- und Secondaryzonen.........................................................................80 3.3.4 Diagnose.........................................................................................................81

3.4 Samba Grundkonfiguration.....................................................................................84 3.4.1 Swat................................................................................................................88

3.5 Apache2 .................................................................................................................91 3.6 Postfix .....................................................................................................................95 3.7 Qpopper..................................................................................................................98 3.8 Übungsbeispiele .....................................................................................................99

4 Netzwerk Monitoring .....................................................................................................101 4.1 ifconfig ..................................................................................................................101 4.2 netstat ...................................................................................................................102 4.3 ping.......................................................................................................................105 4.4 bing.......................................................................................................................106 4.5 fping......................................................................................................................106 4.6 traceroute .............................................................................................................106 4.7 nslookup ...............................................................................................................107 4.8 iptraf......................................................................................................................107 4.9 nmap.....................................................................................................................108 4.10 tcpdump................................................................................................................113 4.11 ethereal.................................................................................................................113 4.12 ntop.......................................................................................................................116


4.13 Nessus..................................................................................................................117 4.14 Übungsbeispiele ...................................................................................................121

5 Server Security..............................................................................................................123 5.1 SuSE Sicherheitseinstellugen...............................................................................123 5.2 SuSE Firewall .......................................................................................................124 5.3 Webmin ................................................................................................................127 5.4 Apache mit mod_ssl .............................................................................................128 5.5 Übungsbeispiele ...................................................................................................129

6 Stichwortverzeichnis .....................................................................................................130 7 Abbildungsverzeichnis ..................................................................................................131 8 Tabellenverzeichnis ......................................................................................................134 9 Literaturverzeichnis .......................................................................................................135


Vorwort

LINUX, das Unix ähnliche System von Linus Torvald, ist zu einer echten Alternative für

Schulen gereift. Speziell für Schulen bietet ein solches System viele Vorteile. Abgesehen von

der günstigen Anschaffung und des geringen Wartungsaufwandes gibt es eine Vielzahl von

Erweiterungen, die das schulische Arbeiten erleichtern.

Ich habe versucht eine Installation von Opensuse 10 Beta2 für eine Schulumgebung mit

erweiterten Serverdiensten zu beschreiben.

Neben den Serverdiendiensten, wird das Hauptaugenmerk auf die Fehlersuche im eigenen

lokalen Netzwerk gelegt. Die meisten der vorgestellten Tools funktionieren übrigens nicht nur

unter Linux, sondern können auch für Windows verwendet werden.

Vor der endgültigen Installation empfiehlt es sich, ein Testsystem zu erstellen. Dafür reicht

ein einfacher PC oder eine virtuelle Arbeitsumgebung wie zum Beispiel VMware, Virtual PC

oder das freie QEMU. Erst wenn alles getestet wurde, sollte ein Echtsystem installiert

werden.

LINUX ist ein sich schnell weiter entwickelndes Betriebssystem. Opensuse zum Beispiel

bringt wöchentlich am Donnerstag neue Releasis heraus.

Dieses Buch baut auf das Wissen des Buches Vogl, H. Der Linux Schulserver auf.

Auch dieses Buch ist einem ständigen Veränderungsprozess unterworfen. Über Anregungen

und Verbesserungsvorschläge würde ich mich sehr freuen.

Heiko Vogl

[email protected]

Graz, 2005


1 TCP / IP

1.1 Open Systems Interconnection (OSI)-Referenzmodell

Das Open Systems Interconnection (OSI)-Referenzmodell ist ein Modell, dass auf einem

Vorschlag der International Standards Organisation (ISO) basiert. Der Aufbau des OSI-

Modells ist in der folgenden Abbildung dargestellt.

Abbildung 1: OSI-Referenzmodell

Das Modell dient derzeit allgemein als Rahmen zur Beschreibung von

Protokollcharakteristika und –funktionen. Das OSI-Modell (die offizielle Bezeichnung lautet

ISO-OSI-Referenzmodell) besteht aus sieben Schichten. Die Schichtung beruht auf dem

Prinzip, dass eine Schicht der jeweils über ihr angeordneten Schicht bestimmte

Dienstleistungen anbietet. Das OSI-Modell ist keine Netzarchitektur, da die Protokolle und

Dienste der einzelnen Schichten vom Modell nicht definiert werden. Das Modell beschreibt

lediglich, welche Aufgaben die Schichten erledigen sollen. Die folgenden Prinzipien haben

zur Siebenschichtigkeit des OSI-Modells geführt:

• Eine neue Schicht soll dort entstehen, wo ein neuer Abstraktionsgrad benötigt wird.

• Jede Schicht soll eine genau definiert Funktion erfüllen.

• Bei der Funktionswahl soll die Definition international genormter Protokolle

berücksichtigt werden.


• Die Grenzen zwischen den einzelnen Schichten sollen so gewählt werden, dass der

Informationsfluss über die Schnittstellen möglichst gering ist.

• Die Anzahl der Schichten soll so groß sein, dass keine Notwendigkeit besteht,

verschiedene Funktionen in eine Schicht zu packen. Aber auch nicht so klein, dass

die gesamte Architektur unhandlich wird.

Den Schichten im OSI-Modell sind die folgenden Aufgaben zugeordnet:

Anwendungsschicht (application layer)

Die Anwendungsschicht enthält eine große Zahl häufig benötigter Protokolle, die einzelne

Programme zur Erbringung ihrer Dienste definiert haben. Auf der Anwendungsschicht finden

sich z.B. die Protokolle für die Dienste ftp, telnet, mail etc.

Darstellungsschicht (presentation layer)

Die Darstellungsschicht regelt die Darstellung der Übertragungsdaten in einer von der

darüber liegenden Ebene unabhängigen Form. Computersysteme verwenden z.B. oft

verschiedene Codierungen für Zeichenketten (z.B. ASCII, Unicode), Zahlen usw. Damit

diese Daten zwischen den Systemen ausgetauscht werden können, kodiert die

Darstellungsschicht die Daten auf eine standardisierte und vereinbarte Weise.

Sitzungsschicht (session layer)

Die Sitzungsschicht (oft auch Verbindungsschicht oder Kommunikationssteuerschicht

genannt) ermöglicht den Verbindungsauf- und abbau. Von der Sitzungsschicht wird der

Austausch von Nachrichten auf der Transportverbindung geregelt. Sitzungen können

beispielsweise einen Transfer gleichzeitig in zwei oder nur eine Richtung ermöglichen. Kann

der Transfer nur in eine Richtung stattfinden, regelt die Sitzungsschicht, welcher der

Kommunikationspartner jeweils an die Reihe kommt.

Transportschicht (transport layer)

Die Transportschicht übernimmt den Transport von Nachrichten zwischen den

Kommunikationspartnern. Sie hat die grundlegende Aufgabe, den Datenfluss zu steuern und

die Unverfälschtheit der Daten sicherzustellen. Beispiele für Transportprotokolle sind TCP

und UDP.

Netzwerkschicht (network layer)

Die Netzwerkschicht (Vermittlungsschicht) hat die Hauptaufgabe eine Verbindung zwischen

Knoten im Netzwerk herzustellen. Die Netzwerkschicht soll dabei die übergeordneten

Schichten von den Details der Datenübertragung über das Netzwerk befreien. Eine der

wichtigsten Aufgaben der Netzwerkschicht ist z.B. die Auswahl von Paketrouten bzw. das


Routing vom Absender zum Empfänger. Das Internet Protokoll (IP) ist in die Netzwerkschicht

einzuordnen.

Sicherungsschicht (data link layer)

Die Aufgabe der Sicherungsschicht (Verbindungsschicht) ist die gesicherte Übertragung von

Daten. Vom Sender werden hierzu die Daten in Rahmen (frames) aufgeteilt und sequentiell

an den Empfänger gesendet. Vom Empfänger werden die empfangenen Daten durch

Bestätigungsrahmen quittiert. Protokollbeispiele für die Sicherungsschicht sind HDLC (high-

level data link control), SLIP (serial line IP) und PPP (point-to-point Protokoll).

Bitübertragungsschicht (physical layer)

Die Bitübertragungsschicht regelt die Übertragung von Bits über das Übertragungsmedium.

Dies betrifft die Übertragungsgeschwindigkeit, die Bit-Codierung, den Anschluss (wieviele

Pins hat der Netzanschluss?) etc. Die Festlegungen der Bitübertragungsschicht betreffen im

Wesentlichen die Eigenschaften des Übertragungsmediums.

1.2 Das TCP/IP-Referenzmodell

Im vorhergehenden Abschnitt wurde das OSI-Referenzmodell vorgestellt. In diesem

Abschnitt soll nun das Referenzmodell für die TCP/IP-Architektur vorgestellt werden. Das

TCP/IP-Referenzmodell, benannt nach den beiden primären Protokollen TCP und IP der

Netzarchitektur, beruht auf den Vorschlägen, die bei der Fortentwicklung des ARPANETs

gemacht wurden. Das TCP/IP-Modell ist zeitlich vor dem OSI-Referenzmodell entstanden.

Die Erfahrungen des TCP/IP-Modells sind in die OSI-Standardisierung eingeflossen. Das

TCP/IP-Referenzmodell besteht im Gegensatz zum OSI-Modell aus vier Schichten:

Application Layer, Transport Layer, Internet Layer, Network Layer. Als Ziele der Architektur

wurden bei der Entwicklung definiert:

• Unabhängigkeit von der verwendeten Netzwerk-Technologie.

• Unabhängigkeit von der Architektur der Hostrechner.

• Universelle Verbindungsmöglichkeiten im gesamten Netzwerk.

• Ende-zu-Ende-Quittungen.

• Standardisierte Anwendungsprotokolle.


Abbildung 2: Vergleich des OSI-Referenzmodells mit dem TCP/IP-Referenzmodell

Applikationsschicht (application layer)

Die Applikationsschicht (auch Verarbeitungsschicht genannt) umfasst alle höherschichtigen

Protokolle des TCP/IP-Modells. Zu den ersten Protokollen der Verarbeitungsschicht zählen

TELNET (für virtuelle Terminals), FTP (Dateitransfer) und SMTP (zur Übertragung von E-

Mails). Im Laufe der Zeit kamen zu den etablierten Protokollen viele weitere Protokolle wie

z.B. DNS (Domain Name Service) und HTTP (Hypertext Transfer Protocol) hinzu.

Transportschicht (transport layer)

Wie im OSI-Modell ermöglicht die Transportschicht die Kommunikation zwischen den Quell-

und Zielhosts. Im TCP/IP-Referenzmodell wurden auf dieser Schicht zwei Ende-zu-Ende-

Protokolle definiert: das Transmission Control Protocol (TCP) und das User Datagram

Protocol (UDP). TCP ist ein zuverlässiges verbindungsorientiertes Protokoll. Dadurch kann

ein Bytestrom fehlerfrei einem anderen Rechner im Internet übermittelt werden. UDP ist ein

unzuverlässiges, verbindungsloses Protokoll, das vorwiegend für Abfragen und

Anwendungen in Client/Server-Umgebungen verwendet wird. Es dient nicht um eine sehr

genaue, sondern schnelle Datenübermittlung geht (z.B. Übertragung von Sprache und

Bildsignalen).

Internetschicht (internet layer)

Die Internetschicht im TCP/IP-Modell definiert ein Protokoll namens IP (Internet Protocol),

das alle am Netzwerk beteiligten Rechner verstehen können. Die Internetschicht hat die

Aufgabe IP-Pakete richtig zuzustellen. Dabei spielt das Routing der Pakete eine wichtige

Rolle. Das Internet Control Message Protocol (ICMP) ist fester Bestandteil jeder IP-


Implementierung und dient zur Übertragung von Diagnose- und Fehlerinformationen für das

Internet Protocol.

Netzwerkschicht (network layer)

Unterhalb der Internetschicht befindet sich im TCP/IP-Modell eine große Definitionslücke.

Das Referenzmodell sagt in dieser Ebene nicht viel darüber aus, was hier passieren soll.

Festgelegt ist lediglich, dass zur Übermittlung von IP-Paketen ein Host über ein bestimmtes

Protokoll an ein Netz angeschlossen werden muss. Dieses Protokoll ist im TCP/IP-Modell

nicht weiter definiert und weicht von Netz zu Netz und Host zu Host ab. Das TCP/IP-Modell

macht an dieser Stelle vielmehr Gebrauch von bereits vorhandenen Protokollen, wie z.B.

Ethernet (IEEE 802.3), Serial Line IP (SLIP), etc.

1.3 Die TCP/IP-Protokoll-Architektur

Abbildung 3: Die TCP/IP-Protokoll-Architektur

Die TCP/IP-Architektur wird im Allgemeinen als vierschichtiges Modell beschrieben. Oft wird


das TCP/IP-Referenzmodell auch als fünfschichtiges Modell dargestellt.

Abbildung 4: OSI-Referenzmodell, TCP/IP-Referenzmodell, Hybrides Referenzmodell

Die Schichtung beruht auf dem Prinzip, dass eine Schicht die angebotenen Dienste der

darunter liegenden Schicht in Anspruch nehmen kann. Dabei braucht jene Schicht, die die

Dienstleistung in Anspruch nimmt, keinerlei Kenntnisse darüber haben, wie die geforderten

Dienste erbracht werden. Auf diese Art und Weise wird eine Aufgabenteilung der Schichten

erreicht. Daten, die von einem Applikationsprogramm über ein Netzwerk versendet werden,

durchlaufen den TCP/IP-Protokollstapel von der Applikationsschicht zur Netzwerkschicht.

Von jeder Schicht werden dabei Kontrollinformationen in Form eines Protokollkopfes

angefügt. Diese Kontrollinformationen dienen der korrekten Zustellung der Daten. Das

Zufügen von Kontrollinformationen wird als Einkapselung (encapsulation) bezeichnet.

Abbildung 5: Dateneinkapselung


Innerhalb der Schichten des TCP/IP-Modells werden Daten mit verschiedenen Termini

benannt, da jede Schicht auch ihre eigenen Datenstrukturen hat. Applikationen, die das

Transmission Control Protocol benutzen, bezeichnen Daten als Strom (stream);

Applikationen, die das User Datagram Protocol verwenden, bezeichnen Daten als Nachricht

(message). Auf der Transportebene bezeichnen die Protokolle TCP und UDP ihre Daten als

Segment (segment) bzw. Paket (packet). In der Internet Schicht werden Daten allgemein als

Datengramm (datagram) benannt. Oft werden die Daten hier aber auch als Paket

bezeichnet. Auf der Netzwerkebene bezeichnen die meisten Netzwerke ihre Daten als

Pakete oder Rahmen (frames).

Abbildung 6: Datenbezeichnung des TCP/IP-Modells

1.4 Internet Protokoll (IP)

Die Vermittlungsschicht im Internetprotokoll kann Datagramme nur an einen direkt

erreichbaren Router senden. Wir verwenden hier das folgende einfache Modell für die

Kommunikation im Internetprotokoll:

Abbildung 7: IP Kommunikation

Eine Station ist entweder ein Router zwischen Netzen oder eine Datenendeinrichtung, die

ein Datagramm nur absenden oder empfangen kann. Da das Internetprotokoll einen von evtl.

mehreren direkt erreichbaren Routern auswählen muss, wurden mehrere Partnerstationen

dargestellt.


Datenübertragung mit Datagrammen

Ähnlich dem Paket im X.25/PLP hat auch ein Datagramm im IP einen festen Aufbau,

bestehend aus einem Datagrammkopf (Datagram Header) und einem Datenbereich (Data

Area).

Abbildung 8: Datagrammkopf

Im Internet werden die Datagramme nicht direkt zwischen Routern verschickt, sondern in der

Regel in einen Block eingepackt, der sie an den nächsten Rechner transportiert; dieser Block

kann z.B. ein Ethernet- oder ein FDDI-Rahmen sein. Hieraus resultiert die Forderung, dass

Datagramme nicht beliebig lang sein dürfen. Ein effizienter Transport kann nur garantiert

werden, wenn jedes Datagramm in einen Rahmen passt. Die Größe eines solchen Rahmens

ist jedoch von Netz zu Netz verschieden, so dass die Größe der Datagramme den

Rahmengrößen der Netze, an die der jeweilige Rechner angeschlossen ist, angepasst sein

sollte. Der Aufbau eines Rahmens mit Datagramm kann dann folgendermaßen dargestellt

werden:


Abbildung 9: Datagramm

Diese Forderung ist jedoch im allgemenen nicht zu erfüllen, da diese Größen zwischen

128 Bytes (in X.25-Netzen) und 4500 Bytes (in FDDI-Ringen) schwanken können, und zu

kleine Datagramme wegen des recht großen Datagrammkopfes ineffizient sind. Daher legt

das Internetprotokoll fest, dass das Netz Datagramme bis zu einer Länge von 576 Oktetten

effizient übertragen muss. Wenn das Netz Rahmen mit Blöcken einer gegebenen Größe

nicht übertragen kann, so darf es die Datagramme fragmentieren (fragment), d.h. in kürzere

Blöcke zerlegen. Dabei enthält jeder Block neben einer Dateninformation auch den

gesamten Datagrammkopf.


Abbildung 10: Datagramme fragmentieren

Ein einmal fragmentiertes Datagramm wird auf seinem Weg zum Empfänger nicht wieder

zusammengesetzt (reassemble), sondern unverändert weitergeschickt. Hierbei können

durchaus verschiedene Wege für unterschiedliche Fragmente gewählt werden. Da jedes

Fragment die gesamte notwendige Zielinformation enthält, können alle Zwischenstationen

den richtigen Weg wählen. Sollten Fragmente eines Datagramms verloren gehen, so gilt das

gesamte Datagramm als verloren und jene Teile, die den Empfänger evtl. erreichen, werden

vernichtet. Die Information, ob ein Datagramm fragmentiert wurde, und in welcher

Reihenfolge die Fragmente zusammengehören, muss natürlich gleichfalls im

Datagrammkopf verschlüsselt werden.

Abbildung 11: Datagramm wird reassembliert


Ein Datagramm wird reassembliert, indem ein eintreffendes Fragment anhand von

Absenderadresse und einer Identifikation einem Datagramm zugeordnet wird. Anhand des

Feldes Fragmentabstand FA kann die Position im gesamten Fragment, anhand des

Längenfeldes GL die Länge des Datenteils berechnet werden. Dabei liegt der Anfang des

Datenfragments bei FA*8, das Ende bei FA*8+(GL-20)-1. Die reassemblierende Station

muss erkennen können, wann alle Fragmente eines Datagramms eingetroffen sind.

Geschieht dieses nicht innerhalb einer bestimmten Zeit (z.B. 1 Minute), so wird das

Datagramm beim Empfänger verworfen.

IP-Datengramm

Die TCP/IP-Protokolle wurden entwickelt, um Daten über ein paketvermittelndes Netz (wie

dem ARPANET) zu übertragen. Ein Paket ist ein Datenblock zusammen mit den

Informationen, die notwendig sind, um sie dem Empfänger zuzustellen (ein Paket ist also

nichts anderes als ein Paket im herkömmliche Sinn bei der Post - das Paket enthält die

Daten, auf dem Paket ist die Adresse des Empfängers notiert). Das Datengramm (datagram)

ist das Paketformat, das vom Internet Protokoll definiert ist. Ein IP-Datengramm besteht aus

einem Header und den zu übertragenden Daten. Der Header hat einen festen 20 Byte

großen Teil, gefolgt von einem optionalen Teil variabler Länge. Der Header umfasst alle

Informationen, die notwendig sind, um das Datengramm dem Empfänger zuzustellen. Ein

Datengramm kann theoretisch maximal 64 KByte groß sein, in der Praxis liegt die Größe

ungefähr bei 1500 Byte (das hängt mit der maximalen Rahmengröße des Ethernet-Protokolls

zusammen).

Abbildung 12: Der IP-Header


Die Felder, des in der Abbildung dargestellten Protokollkopfes, haben die folgende

Bedeutung:

Version

Das Versions-Feld enthält die Versionsnummer des IP-Protokolls. Durch die Einbindung der

Versionsnummer besteht die Möglichkeit über eine längere Zeit mit verschiedenen Versionen

des IP Protokolls zu arbeiten. Einige Hosts können mit der alten und andere mit der neuen

Version arbeiten. Die derzeitige Versionsnummer ist 4, aber die Version 6 des IP Protokolls

befindet sich bereits in der Erprobung.

Length

Das Feld Length (Internet Header Length - IHL) enthält die Länge des Protokollkopfs, da

diese nicht konstant ist. Die Länge wird in 32-Bit-Werten angegeben. Der kleinste zulässige

Wert ist 5 - das entspricht also 20 Byte. In diesem Fall sind im Header keine Optionen

gesetzt. Die Länge des Headers kann sich durch Anfügen von Optionen aber bis auf 60 Byte

erhöhen.

Type of Servive

Über das Feld Type of Service kann das IP angewiesen werden Nachrichten nach

bestimmten Kriterien zu behandeln. Als Dienste sind hier verschiedene Kombinationen aus

Zuverlässigkeit und Geschwindigkeit möglich. In der Praxis wird dieses Feld aber ignoriert,

hat also den Wert 0. Das Feld selbst hat den folgenden Aufbau:

Abbildung 13: Type of Service

Precedence (Bits 0-2) gibt die Priorität von 0 (normal) bis 7 (Steuerungspaket) an. Die drei

Flags (D,T,R) ermöglichen es dem Host anzugeben, worauf er bei der Datenübertragung am

meisten Wert legt: Verzögerung (Delay - D), Durchsatz (Throughput - T), Zuverlässigkeit

(Reliability - R). Die beiden anderen Bit-Felder sind reserviert.

Total Length

Enthält die gesamte Paketlänge, d.h. Header und Daten. Da es sich hierbei um ein 16-Bit-

Feld handelt ist die Maximallänge eines Datengramms auf 65.535 Byte begrenzt. In der

Spezifikation von IP (RFC 791) ist festgelegt, dass jeder Host in der Lage sein muss, Pakete

bis zu einer Länge von 576 Bytes zu verarbeiten. In der Regel können von dem Host aber

Pakete größerer Länge verarbeitet werden.


Identification

Über das Identifikationsfeld kann der Zielhost feststellen, zu welchem Datengramm ein neu

angekommenes Fragment gehört. Alle Fragmente eines Datengramms enthalten die gleiche

Identifikationsnummer, die vom Absender vergeben wird.

Flags

Das Flags-Feld ist drei Bit lang. Die Flags bestehen aus zwei Bits namens DF (Don't

Fragment) und MF (More Fragments). Das erste Bit des Flags-Feldes ist ungenutzt bzw.

reserviert. Die beiden Bits DF und MF steuern die Behandlung eines Pakets im Falle einer

Fragmentierung. Mit dem DF-Bit wird signalisiert, dass das Datengramm nicht fragmentiert

werden darf. Auch dann nicht, wenn das Paket eventuell nicht mehr weiter transportiert

werden kann und verworfen werden muss. Alle Hosts müssen Fragmente bzw.

Datengramme mit einer Größe von 576 Bytes oder weniger verarbeiten können. Mit dem

MF-Bit wird angezeigt, ob einem IP-Paket weitere Teilpakete nachfolgen. Dieses Bit ist bei

allen Fragmenten, außer dem letzten gesetzt.

Fragment Offset

Der Fragmentabstand bezeichnet, an welcher Stelle, relativ zum Beginn des gesamten

Datengramms, ein Fragment gehört. Mit Hilfe dieser Angabe kann der Zielhost das

Originalpaket wieder aus den Fragmenten zusammensetzen. Da dieses Feld nur 13 Bit groß

ist, können maximal 8192 Fragmente pro Datengramm erstellt werden. Alle Fragmente,

außer dem letzten, müssen ein Vielfaches von 8 Byte sein. Dies ist die elementare

Fragmenteinheit.

Time to Live

Das Feld Time to Live ist ein Zähler, mit dem die Lebensdauer von IP-Paketen begrenzt

wird. Im RFC 791 ist für dieses Feld als Einheit Sekunden spezifiziert. Zulässig ist eine

maximale Lebensdauer von 255 Sekunden (8 Bit). Der Zähler muss von jedem Netzknoten,

der durchlaufen wird, um mindestens 1 verringert werden. Bei einer längeren

Zwischenspeicherung in einem Router muss der Inhalt sogar mehrmals verringert werden.

Enthält das Feld den Wert 0, muss das Paket verworfen werden. Damit wird verhindert, dass

ein Paket endlos in einem Netz umherwandert. Der Absender wird in einem solchen Fall

durch eine Warnmeldung in Form einer ICMP-Nachricht informiert.

Protocol

Enthält die Nummer des Transportprotokolls, an das das Paket weitergeleitet werden muss.

Die Nummerierung von Protokollen ist im gesamten Internet einheitlich. Bisher wurden die

Protokollnummern im RFC 1700 definiert. Diese Aufgabe ist nun von der Internet Assigned


Numbers Authority1 (IANA) übernommen worden. Bei UNIX-Systemen sind die

Protokollnummern in der Datei /etc/protocols abgelegt.

Header Checksum

Dieses Feld enthält die Prüfsumme der Felder im IP-Header. Die Nutzdaten des IP-

Datengramms werden aus Effizienzgründen nicht mit geprüft. Diese Prüfung findet beim

Empfänger innerhalb des Transportprotokolls statt. Die Prüfsumme muss von jedem

Netzknoten, der durchlaufen wird, neu berechnet werden, da der IP-Header durch das Feld

Time-to-Live sich bei jeder Teilstrecke verändert.

Source Address, Destination Address

In diese Felder werden die 32-Bit langen Internet-Adressen eingetragen.

Options und Padding

Das Feld Options wurde im Protokollkopf aufgenommen, um die Möglichkeit zu bieten, das

IP-Protokoll um weitere Informationen zu ergänzen, die im ursprünglichen Design nicht

berücksichtigt wurden. Das Optionsfeld hat eine variable Länge. Jede Option beginnt mit

einem Code von einem Byte, über den die Option identifiziert wird. Manchen Optionen folgt

ein weiteres Optionsfeld von 1 Byte und dann ein oder mehrere Datenbytes für die Option.

Das Feld Options wird über das Padding auf ein Vielfaches von 4 Byte aufgefüllt. Derzeit

sind die folgenden Optionen bekannt:

• End of Option List (Kennzeichnet das Ende der Optionsliste)

• No Option (Kann zum Auffüllen von Bits zwischen Optionen verwendet werden)

• Security (Bezeichnet, wie geheim ein Datengramm ist. In der Praxis wird diese Option

jedoch fast immer ignoriert.)

• Loose Source-Routing, Strict Source-Routing (Diese Option enthält eine Liste von

Internet-Adressen, die das Datagramm durchlaufen soll. Auf diese Weise kann dem

Datenpaket vorgeschrieben werden eine bestimmte Route durch das Internet zu

nehmen. Beim Source-Routing wird zwischen Strict Source and Record Route und

Loose Source and Record Route unterschieden. Im ersten Fall wird verlangt, dass

das Paket diese Route genau einhalten muss. Desweiteren wird die genommene

Route aufgezeichnet. Die zweite Variante schreibt vor, dass die angegebenen Router

nicht umgangen werden dürfen. Auf dem Weg können aber auch andere Router

besucht werden.)

1 http://www.iana.org


• Record Route (

Die Knoten, die dieses Datengramm durchläuft, werden angewiesen ihre IP-Adresse

an das Optionsfeld anzuhängen. Damit lässt sich ermitteln, welche Route ein

Datengramm genommen hat. Wie anfangs schon gesagt, ist die Größe für das

Optionsfeld auf 40 Byte beschränkt. Deshalb kommt es heute auch oftmals zu

Problemen mit dieser Option, da weit mehr Router durchlaufen werden, als dies zu

Beginn des ARPANET der Fall war.)

• Time Stamp (Diese Option ist mit der Option Record Route vergleichbar. Zusätzlich

zur IP-Adresse wird bei dieser Option die Uhrzeit des Durchlaufs durch den Knoten

vermerkt. Auch diese Option dient hauptsächlich zur Fehlerbehandlung, wobei

zusätzlich z.B. Verzögerungen auf den Netzstrecken erfasst werden können.)

Weitere Details zu den Optionen sind in RFC 791 zu finden.

1.5 Address Resolution Protocol (ARP)

In lokalen Netzen wird zur Bindung einer Protokolladresse mit einer Hardwareadresse meist

das Address Resolution Protocol (ARP) verwendet, welches in RFC 826 standardisiert ist. Es

wird ein ARP-Format definiert, welches für beliebige Adressformate gelten soll.

Abbildung 14: ARP

ARP-Nachrichten im Ethernet werden anhand des Ethernet-Typ-Feldes (Kennung 80616)

kenntlich gemacht. Anfragen und Antworten werden durch unterschiedliche Einträge im

Operationsfeld dargestellt.

In der Regel besitzt jeder Rechner einen Speicher für Adressbindungen (Cache), in welchem

die entsprechenden Adressen abgelegt sind. Sobald er ein Paket an einen anderen Rechner

senden muss, untersucht der Rechner, ob sich die Protokolladresse in diesem Speicher

befindet. Ist dieses der Fall, so wird das IP-Datagramm in ein Frame verpackt. Dieses wird


mit der entsprechenden Zieladresse versehen. Ist das nicht der Fall, muss eine

Adressauflösung durchgeführt werden.

Dazu sendet der Rechner eine beschränkte Rundspruch-Nachricht an alle anderen Rechner

im eigenen Netz aus, in die er im ARP-Format seine eigene Internet- und Hardwareadresse

einfügt. Das Operationsfeld ist auf Anfrage (Wert=1) gesetzt. Der angesprochene Rechner

erkennt als einziger seine Internetadresse und liefert in einem Frame dem anfragenden

Rechner seine Hardware- und Internetadressen (falls er mehrere besitzt) zurück. Dazu wird

das Protokollfeld auf Antwort (Wert = 2) gesetzt. Außerdem verwendet er die

Senderadressen, um eine eigene Bindung herzustellen, da er vermutlich, auf ein demnächst

von diesem Rechner zu erwartendes Paket, eine Antwort zu senden hat. Auf diese Weise

wird der ARP-Verkehr optimiert.

Der Cache für die Adressbindung wird in gewissen zeitlichen Abständen (z.B. 20 Minuten)

gelöscht, um Änderungen im Netz besser folgen zu können. Daher würde auch eine

überflüssige Speicherung einer Bindung bald wieder korrigiert werden.

Meldet sich auf eine ARP-Anfrage kein Rechner, so ist dieser entweder abgestellt oder er

befindet sich in einem anderen physikalischen Netz. Dann sollte der Router dieses

feststellen. Er kann dann seine eigene Hardwareadresse zurücksenden und das folgende

Paket weitersenden.

1.6 Reverse Address Resolution Protocol (RARP)

Um zu einer bekannten physikalischen Adresse die Internetadresse zu finden, wird das

Reverse Address Resolution Protocol (RARP) verwendet. Es ist in RFC 903 standardisiert.

Dieses Problem tritt auf, wenn Arbeitsrechner ohne Plattenspeicher (Diskless Workstation)

eingeschaltet werden. Sie können zwar ihre Netzhardware nach ihrer physikalischen

Hardwareadresse abfragen, aber ihre Internetadresse ist ihnen unbekannt. Durch Senden

der physikalischen Adresse als Rundspruch-Nachricht können sie ihren Server auffordern,

ihnen ihre Internetadresse mitzuteilen.


Abbildung 15: RARP

Das RARP-Protokoll verwendet das gleiche Datenformat wie ARP, benutzt jedoch den

Operationswert 3 für Anfragen und 4 für Antworten. In der Anfrage wird in der Regel nur die

Hardwareadresse des Absenders gesetzt. Alle anderen Werte sind undefiniert (u.U. wird

auch die Hardwareadresse des Empfängers gesetzt, ersatzweise ist deren Wert gleich der

des Absenders.) Ein RARP-Server erkennt die Anfrage und setzt sowohl seine Bindung ein

(um eine zusätzliche ARP-Anfrage zu vermeiden), als auch die Bindung des Empfängers.

Das Operationsfeld wird auf den Wert 4 gesetzt. Auf diese Weise erhält der Empfänger die

gewünschte Information.

1.7 Internet Control Message Protocol (ICMP)

Das Internet Control Message Protocol (ICMP) benutzt wie TCP und UDP das Internet

Protocol IP, ist also ein Teil der Internet-Protokoll-Familie. Es dient in Netzwerken zum

Austausch von Fehler- und Informationsmeldungen.

Obwohl ICMP eine Ebene über IP angeordnet ist, ist es in IP integriert. Es wird von jedem

Router und PC erwartet, ICM-Protokoll zu sprechen. Die meisten ICMP-Pakete enthalten

Diagnose-Informationen. Sie werden vom Router zur Quelle (source) zurückgeschickt, wenn

der Router Pakete verwirft. (z.B. weil das Ziel (destination) nicht erreichbar ist, die TTL

abgelaufen ist, usw.) Es gilt der Grundsatz, dass ein ICMP-Paket niemals ein anderes ICMP-

Paket auslöst, d.h. die Tatsache, dass ein ICMP Paket nicht zugestellt werden konnte wird

nicht durch ein Weiteres signalisiert. Eine Ausnahme zu diesem Grundsatz bildet die Echo-

Funktion. Echo-ICMP-Pakete werden z.B. durch das Programm Ping verschickt.

ICMP-Nachrichten werden beim Versand im Datenteil von IP-Datagrammen eingekapselt.

Dabei sind im IP-Header der Servicetyp immer 0 und die Protokollnummer immer 1.


Abbildung 16: ICMP Paket

Tabelle 1: ICMP Typ - Code-Kombinationen

Typ Typname Code Bedeutung

0 Echo Reply 0 Echo Reply

3 Destination Unreachable 1 Host Unreachable

3 Port Unreachable

4 Fragmentation Needed, DF Set

8 Echo Request 0 Echo Request

11 Time Exceeded 0 TTL Exceeded

1 Fragment Reassembly Timeout

30 Traceroute Traceroute

33 IPv6 Where-Are-You IPv6 Where-Are-You


34 IPv6 I-Am-Here IPv6 I-Am-Here

1.8 Transmission Control Protocol (TCP)

TCP (Transmission Control Protocol) hat die folgenden Merkmale.

• Verbindungsorientiert

Zwischen den kommunizierenden Stationen ist vor der Übermittlung von Information

eine virtuelle Verbindung aufzubauen und nach der Kommunikation wieder

abzubauen.

• Duplex-Verbindung

Beide Anwendungsprozesse können unabhängig voneinander Daten übermitteln.

• Punkt-zu-Punkt

TCP überträgt Daten zwischen genau zwei Teilnehmern mit symmetrischen Rechten.

• Zuverlässigkeit

TCP garantiert dem Benutzer eine hohe Zuverlässigkeit der Datenübermittlung

bezüglich Verfälschung und Verlust von Daten.

• Stromorientiert

Jede Folge von Bytes, die der Sender abschickt, wird unverändert (d.h. gleiche Bytes

und gleiche Reihung) dem Empfänger übermittelt.

• Gepufferte Übertragung

Daten werden byteweise an die Kommunikationsinstanz geliefert, welche diese in

Paketen sammelt und selbsttätig übermittelt. Durch einen Push-Mechanismus kann

der Sender das System zwingen, alle bisher abgesetzten Daten unverzüglich dem

Empfänger abzuliefern.

• Unstrukturierter Strom

Die Anwendungsprozesse müssen die Struktur ihres Datenstroms selbst vereinbaren

und überwachen. TCP unterstützt nicht die Segmentierung der Information in

Datensätze.

• Zuverlässiger Verbindungsauf- und abbau

Verbindungen erhalten auch dann keine verfälschten Daten, wenn sie kurz


nacheinander mit der gleichen Portnummer aufgebaut werden.Beim Abbau werden

Daten auch dann zuverlässig übertragen, wenn eine Seite die Verbindung abbaut,

ehe alle Daten beim Empfänger eingetroffen sind. Jeder Empfänger kann seine

Verbindung unabhängig von der Gegenstelle schließen.

TCP-Header

Zur Identifizierung einer Verbindung sieht TCP einen Header vor. Dieser kennzeichnet die

Port-Adressen von Quell- und Zielrechner in jedem Segment. Ports müssen von den

Anwenderprozessen bei jedem Aufruf der entsprechenden Betriebssystemroutinen

angegeben werden. Die Werte dieser Portnummern sind teilweise festgelegt, z.B. für

elektronische Post (25) oder remote job entry (5). Andere Portnummern sind jedoch frei

vereinbar und können vom Betriebssystem beliebig vergeben werden. Eine Liste der

Portnummer findet sich in dem RFC "Assigned Numbers" (Internet-Standard 2, zur Zeit RFC

1700).

Abbildung 17: TCP-Segment

Die Folgenummer gibt die Lage dieser Daten in dem Datenstrom des Senders an. Die

Quittungsnummer ist die Nummer jenes Datenbytes in dem Bytestrom, welches der

Absender dieses TCP-Segments als nächstes von der Gegenstelle erwartet. Das Feld Offset

(4 Bits) gibt an, wie viele 32-Bit-Worte der TCP-Header enthält. Dieses ist nötig, da das

Optionenfeld variable Länge haben kann. Das Fenster gibt an, wie viele Bytes der Sender

dieses Pakets von der Gegenstelle noch maximal akzeptieren kann. Damit ist eine

Flusskontrolle möglich. Sender und Empfänger synchronisieren sich entsprechend der

vorhandenen Ressourcen.


Codes im TCP-Header

Da manche Pakete nur Daten, manche nur Quittungen enthalten, gibt Code an, welche

Bedeutung dieses Paket hat. Dieses Feld enthält 6 Bits, welche gesetzt oder gelöscht sein

können und folgendes bedeuten.

Abbildung 18: TCP-Head

Der Vorrang-Zeiger zeigt auf jenes Byte innerhalb dieses Pakets, ab welchem Vorrangdaten

vorhanden sind. Dieses Feld ist jedoch nur gültig, wenn das URG-Bit (urgent) gesetzt ist.

Das PSH-Bit (push) wird gesetzt, wenn Daten vom Sender abgeschickt wurden, ohne dass

der Sendepuffer bereits gefüllt ist. Dieses wird besonders beim interaktiven Betrieb benötigt,

um beim Zeilenende bei einem Terminalbetrieb die letzten Daten zu übertragen.

Das Ack-Bit (acknowledgement) und das SYN-Bit (synchronize) werden beim

Verbindungsaufbau, das FIN-Bit (finish) zusätzlich beim Verbindungsabbau benötigt.

Wenn eine Verbindung schnell (und nicht durch FIN) beendet werden soll, verwendet man

das RST-Bit (reset).

Verbindungsaufbau beim TCP-Protokoll

Der Verbindungsaufbau beim TCP-Protokoll wird durch ein 3-Wege-Verfahren (three-way

handshake) durchgeführt, welches nach folgendem Prinzip arbeitet.


Abbildung 19: Dreiwege-Handshake (hier Verbindungsaufbau)

Nach dem Aufbau der Verbindung wissen somit beide Stationen, dass die andere

empfangsbereit ist und wie die jeweiligen Bytes nummeriert werden. Um eine Verbindung zu

schließen, wird ein Segment mit dem gesetzten FIN-Bit geschickt. Damit ist die jeweilige

Richtung geschlossen. Es dürfen keine Daten mehr übermittelt werden. In der

Gegenrichtung können jedoch noch weiter Daten gesendet werden. Erst wenn beide

Stationen ein FIN-Segment geschickt haben, ist die Verbindung vollständig beendet. Bei

fehlerhaften Situationen besteht die Möglichkeit, durch Setzen des RST-Bits die

Verbindungen sofort abzubrechen.

Portnummern

TCP ist außerdem dafür verantwortlich, die empfangenen Daten an die korrekte Applikation

weiterzuleiten. Zur Adressierung der Anwendungen werden auf der Transportebene deshalb

so genannte Portnummern (Kanalnummern) verwendet. Portnummern sind 16 Bit groß.

Theoretisch kann ein Host somit bis zu 65.535 verschiedene TCP-Verbindungen aufbauen.

Auch UDP verwendet Portnummern zur Adressierung. Portnummern sind nicht einzigartig

zwischen den Transportprotokollen, die Transportprotokolle haben jeweils eigene

Adresseräume. Das bedeutet TCP und UDP können die gleichen Portnummern belegen. Die

Portnummer 53 in TCP ist nicht identisch mit der Portnummer 53 in UDP. Der

Gültigkeitsbereich einer Portnummer ist auf einen Host beschränkt.


Die Verwaltung der Portnummern ist nun auch von der Internet Assigned Numbers Authority2

(IANA) übernommen worden. Portnummern sind dabei in drei Bereiche aufgeteilt worden:

well-known ports, registered ports und dynamic ports.

Tabelle 2: Ports

0 - 1023 Well-known ports (von der IANA verwaltet). Der Bereich der well-known

ports ist bis 1023 erweitert worden, damit sind auch die UNIX-

spezifischen Dienste als Standarddienste festgelegt.

1024 - 49151 Registered ports. Registrierte Ports dienen für Dienste, die üblicherweise

auf bestimmten Ports laufen. Ein Beispiel ist hier der Port 8080, der als

"zweiter" bzw. alternativer Port für das http dient.

49152 - 65535 Dynamic and/or private ports. Dieser Bereich ist für die sogenannten

dynamischen Ports festgelegt. Dynamische Ports dienen zur

Kommunikation zwischen den beiden TCP-Schichten, die an einer

Kommunikation beteiligt sind. Ein dynamischer Port wird nicht von

bestimmten Standarddiensten belegt.

1.9 User Datagram Protocol (UDP)

Das User Datagram Protocol (UDP) stellt dem Anwender einen Mechanismus zur

verbindungslosen Kommunikation zur Verfügung. Das Konzept ist ähnlich dem des IP. Es

setzt jedoch auf der Anwendungsschicht auf. UDP erlaubt es Anwendungsprozesse auf

anderen Rechnern Datagramme zu senden. Der Anwendungsprozess wird durch eine

Portnummer identifiziert. UDP ist in RFC 768 standardisiert. Das Feld Protocol im IP-Header

identifiziert UDP mit dem Wert 1710. Die teilweise festgelegten Portnummern werden aktuell

in RFC 1700 spezifiziert und sind aktueller unter der URL http://www.iana.org zu finden.

UDP-Nachricht

Eine UDP-Nachricht (UDP-Message) besteht aus einem Kopf und einem Datenteil. Die UDP-

Nachricht wird in einem IP-Datagramm wie ein Datenpaket behandelt.

2 http://www.iana.org


Abbildung 20: UDP Datagramm

Der UDP-Kopf hat den folgenden Aufbau.

Abbildung 21: UDP-Kopf

Der Quell- bzw. Ziel-Port identifiziert eindeutig den Anwendungsprozess, der dieses

Datagramm entweder sendet oder empfängt. Dabei ist der Quell-Port optional, d.h. entweder

enthält er die Adresse des Absenders, an die der Empfänger Antworten schicken soll, oder

er enthält den Wert null.

1.10 Adressierung im TCP/IP

Siehe Vogl, H. Der Linux Schulserver.


Tabelle 3: Netzklassen

Netzklasse Adressbereich Netzmaske CIDR-Schreibweise

Klasse A 0.0.0.0 bis

127.255.255.255

255.0.0.0 0.0.0.0/8

Klasse B 128.0.0.0 bis

191.255.255.255

255.255.0.0 128.0.0.0/16

Klasse C 192.0.0.0 bis

223.255.255.255

255.255.255.0 192.0.0.0/24

Tabelle 4: Private IP-Adressen

Netzklasse Adressbereich CIDR-

Schreibweise

Anzahl der möglichen

Hosts

Klasse A 10.0.0.0 - 10.255.255.255 10.0.0.0/8 16777216

Klasse B 172.16.0.0 - 172.31.255.255 172.16.0.0/12 1048576

Klasse C 192.168.0.0 -

192.168.255.255

192.168.0.0/16 65536

Das Netzwerk 127.0.0.0/8 bezeichnet man als loopback-device. Es bezieht sich auf den

lokalen Computer. Mit der IP-Adresse 127.0.0.1 wird der lokale Rechner adressiert. Diese

Adresse dient der Kommunikation lokaler Clients mit dem lokalen Server. So wird am

Rechner mit dem URL http://127.0.0.1/ immer der lokale Webserver erreicht.

1.11 Subnetze

Ein Subnetz entsteht durch die Unterteilung aller möglichen IP-Adressen in Teilnetze. Die

logische Unterteilung des Netzes in Subnetze entspricht meist der physikalischen


Unterteilung in lokale Teilnetze. Das Unterteilen einer Netzklasse mittels Netzmaske in

weitere Subnetze nennt man Subnetting.

1.11.1 Grundlagen

Die Zuordnung von IP-Adressen zu Subnetzen und die Bezeichnung des Subnetzes erfolgen

durch Angabe einer IP-Adresse und einer Netzmaske. Dabei bestimmt die Netzmaske die

Bits der IP-Adresse, die für alle IP-Adressen des Subnetzes gleich sind. Die restlichen Bits

können variieren und bestimmen den Adressraum.

Hieraus ergeben sich folgende Besonderheiten:

• Die erste IP-Adresse (alle Hostbits auf 0) eines Subnetzes adressiert das Subnetz

selbst (Netzwerkkennung) und kann deshalb keinem Host zugewiesen werden.

• Die letzte IP-Adresse (alle Hostbits auf 1) eines Subnetzes dient als Broadcast-

Adresse für das Netz und kann ebenfalls keinem Host zugewiesen werden.

• Es gibt einige IP-Bereiche, die für spezielle Zwecke vorgesehen sind. Dazu gehören

z.B die loopback-Adresse oder Private IP-Adressen.

Ein Router arbeitet auf der Vermittlungsschicht des OSI-Modells und kann durch bitweise

Und-Verknüpfung von Netzmaske und IP-Adresse ermitteln, ob letztere zum eigenen oder in

anderes Subnetz gehört. Dadurch sind Router in der Lage, Subnetze zu verbinden.

Mit dem Routing Information Protocol war es lediglich möglich Netze in gleich große

Subnetze zu unterteilen. Da man dort für jedes Netz die gleiche Subnetzadresse mit der

gleichen Anzahl an Einsern benutzt hatte, sprach man auch vom Fixed Length Subnet

Masks (FLSM). OSPF und statisches Routing unterstützen inzwischen auch Subnetzmasken

unterschiedlicher Länge oder Variable Length Subnet Masks (VLSM).

1.11.2 Vorgehensweise zur Aufteilung in Subnetze

Die Standard-Aufteilung, nach der die Netzmasken bestimmt werden, folgt dabei einer

bestimmten Rechenmethode:

Gegeben sei: gewünschte Netze 40, gewünschte Hosts 720 je Netz, verfügbarer Hostbereich

181.45.x.x

Schritt 1: Kontrolle ob Adressressourcen ausreichen


Dazu ist eine n-te Potenz von 2 (zwei hoch n) zu finden, die um 2 größer als die Anzahl der

gewünschten Netze oder Hosts ist:

Es stehen also zwei Oktette bzw. 16 Bit zur Verfügung.

Adressresourcen = 2n = (Anzahl + 2) n

Erklärung: 1 Bit hat zwei mögliche Werte. Für n Bit gibt es also 2n mögliche

Bitkombinationen. Es können also 2n Netze/Hosts abgebildet werden, wobei von den

darstellbaren Adressen zwei wegfallen (Netzadresse und Broadcast, siehe oben).

Die ersten zehn Zweierpotenzen sind: 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024. Da also 25 =

32 < 40 < 64 = 26, müssen n = 6 Bit für die Netze reserviert werden.

Analog für die Anzahl der Hosts gilt: 29 = 512 < 720 < 1024 = 210, d.h. 10 Bit werden für die

Hosts benötigt.

Alternativ lässt sich n auch durch den Logarithmus zur Basis 2 (Logarithmus dualis)

ermitteln:

Netze: 2log(40)=5,32 Aufrunden auf 6 Hosts: 2log(720)=9,49 Aufrunden auf 10

Das Ergebnis der Überprüfung lautet, dass die Summe der benötigten Bits 16 beträgt. Da

auch 16 Bit verfügbar sind, kann mit dem gegebenen Adressenbereich 181.45.x.x die

Anforderung also erfüllt werden.

Schritt 2: Ermitteln der Netzmaske

Wie bereits berechnet, müssen für den Hostanteil 10 Bit verwendet werden. Host-Bit sind

immer die letzten in einer IP-Adresse:

Gemischte Dezimal-Binär-Darstellung: 181.45.NNNNNNHH.HHHHHHHH (N für Netzwerkbits, H für Hostbits)

Die Netzmaske soll 32 Bit umfassen, wobei sämtliche Netzwerkbit durch 1 und sämtliche

Host-Bits (im Beispiel 10) durch 0 dargestellt werden:

Es ergibt sich folgende Binärdarstellung: 11111111.11111111.11111100.00000000

Jedes Oktett dieser Netzmaske wird nun vom Dualsystem ins Dezimalsystem umgerechnet:

00000000 (Dual) = 0 (Dezimal)


11111100 (Dual) = 252 (Dezimal)

11111111 (Dual) = 255 (Dezimal)

Die Netzmaske lautet dementsprechend: 255.255.252.0.

Schritt 3: IP-Adressen der Netze finden

Zur Festlegung der IP-Adressen muss wieder gerechnet werden:

Erstes Netz

• Netzadresse des ersten Netzes: 181.45.NNNNN1HH.HHHHHHHH

=10110101.00101101.00000100.00000000 =181.45.4.0

• Erster Host im ersten Netz: 181.45.NNNNN1HH.HHHHHHH1

=10110101.00101101.00000100.00000001 =181.45.4.1.

Der letzte Host im ersten Netz orientiert sich an der maximalen Anzahl von Einsern, die für

Hosts zur Verfügung stehen. Das letzte Bit kann dann nicht 1 sein, da es sich sonst um den

Netzbroadcast handeln würde:

181.45.(NNNNN1)11.11111110 = 10110101.00101101.00000111.11111110 = 181.45.7.254

Demnach ist 181.45.7.255 der Broadcast für das 1. Netz.

Letztes Netz

Das letzte Netz ist auch anhand der möglichen Bits festgelegt:

• 181.45.(111110)00.00000000 Netzadresse für das letzte Netz. (181.45.248.0)

• 181.45.(111110)11.11111110 letzter Host im letzten Netz. (181.45.251.254)

Vereinfachung

Bei kleineren Subnetzen lassen sich die Adressen der einzelnen Subnetze folgendermaßen

berechnen:

Zuerst ermittelt man die Anzahl der möglichen Adressen pro Subnetz. Diese erhält man,

indem man die Anzahl der Adressen des aufzuteilenden Netzes durch die Anzahl der

Subnetze teilt. Nun beginnt jedes Subnetz mit einem Vielfachen der Anzahl der Adressen pro

Subnetz.


Beispiel:

Das Netz 192.168.44.X soll in 8 Teilnetze aufgeteilt werden. Ein Oktett kann 256

verschiedene Werte annehmen. Jedes Subnetz hat 30 verwendbare Adressen (256:8=32-2

(Netzadresse und Broadcastadresse))

Folgende Netze entstehen:

• 192.168.44.0

• 192.168.44.32

• 192.168.44.64

• 192.168.44.96

• 192.168.44.128

• 192.168.44.160

• 192.168.44.192

• 192.168.44.224

Sollte ein Netz in mehrere, unterschiedlich große, Subnetze aufgeteilt werden, so wird mit

der größten Adressanzahl begonnen.

Host-Range

Der Host-Range bezeichnet den Teil in einem Subnetz der tatsächlich für IP-Adressen

verwendet werden kann. In jedem Subnetz ist die erste und die letzte Adresse reserviert. Bei

einem Subnetz mit der Adresse 200.10.57.8 lautet der Host-Range: 200.10.57.9 -

200.10.57.14 Die reservierten Adressen lauten in diesem Fall 200.10.57.8 und 200.10.57.15

Das nächste Subnetz mit der Adresse 200.10.57.16 hätte einen Hostrange von 200.10.57.17

bis 200.10.57.22

Vereinfachung von Subnetting

Beispiel: Ein Klasse B-Netz mit der Nummer 172.16.0.0 und der Subnetzmaske 255.255.0.0


Ziel: In einem B-Netz können ca. 65.000 Hosts adressiert werden. Da mehrere Teilnetze

benötigt werden, wird diese Anzahl unterteilen. Im Beispiel sollen 20 Teilnetze gebildet

werden.

Lösung: (Erspart binäres Rechnen!)

Schritt 1: Wir suchen die 2er Potenz, die größer 20 ist :

2^5 = 32

Schritt 2: Wir teilen die Anzahl der Bitkombinationen durch das Ergebnis aus dem 1.Schritt:

256 : 32 = 8

Schritt 3: Wir bilden die Subnetzmaske: 256 - 8 = 248

Die neue Subnetzmaske lautet: 255.255.248.0

Schritt 4: Wir bilden den Adressbereich eines gesuchten Teilnetzes.

Beispiel: Wir suchen das 5. Teilnetz:

5 x 8 = 40 6 x 8 = 48 - 1 = 47 Der Adressbereich lautet: 172.16.40.1 bis 172.16.47.254 mit der Subnetzmaske 255.255.248.0

Beispiel: Wir suchen das 7. Teilnetz:

7 x 8 = 56 8 x 8 = 64 - 1 = 63 Der Adressbereich lautet: 172.16.56.1 bis 172.16.63.254 mit ebenfalls der Subnetzmaske 255.255.248.0

Für diese Berechnungen gibt es natürlich auch Programme, wie den IP Calculator3.

1.12 Classless Inter Domain Routing (CIDR)

Classless Inter-Domain Routing (CIDR) beschreibt ein Verfahren zur effektiveren Nutzung

des bestehenden 32-Bit-IP-Adress-Raumes. Es wurde 1993 eingeführt, um die Größe von

Routing-Tabellen zu reduzieren und um die verfügbaren Adressbereiche besser

auszunutzen.

3 http://jodies.de/ipcalc


Mit CIDR entfällt die feste Zuordnung einer IP-Adresse zu einer Netzklasse und die

eventuelle Unterteilung (Subnetting) in weitere Netze oder die Zusammenfassung

(Supernetting) mehrerer Netze einer Klasse. Es existiert nur noch eine Netzmaske, welche

die IP-Adresse in den Netzwerk- und Hostteil aufteilt.

Bei CIDR führte man als neue Notation so genannte Suffixe ein. Das Suffix gibt die Anzahl

der 1-Bits in der Netzmaske an. Diese Schreibform ist viel kürzer als die dotted decimal

notation und auch eindeutig.

Beispiel: 192.168.0.0/24 entspricht im alten klassenbasierten Verfahren der Adresse

192.168.0.0 mit der Netzmaske 255.255.255.0. In binärer Schreibweise ergibt sich bei der

Netzmaske 11111111.11111111.11111111.00000000, womit die Anzahl der einer Bit 3*8 =

24 beträgt.

CIDR bietet außerdem Route aggregation. Dabei können verschiedene Netze unter einer

einzigen Adresse angesprochen werden.

1.13 Dynamic Host Configuration Protocol (DHCP)

Das Dynamic Host Configuration Protocol (DHCP) weist auf Anfrage einem Rechner

dynamisch eine Adresse zu. Es erledigt also eine ähnlich Aufgabe wie das RARP, wobei

allerdings die IP-Adressen nicht notwendigerweise unverändert dem jeweiligen Host

zugewiesen werden. Es baut auf dem BOOTP-Protokoll auf, welches für das Starten von

Computern über das Netz benutzt wird.

Abbildung 22: DHCP

Startet ein Rechner in einem neuen oder seinem bisherigen Netz, so sendet er eine

entsprechende Anfrage ab. Der zuständige DHCP-Server antwortet und sendet diesem


Rechner verschiedene Daten. Die aktuelle IP-Adresse, aber auch die Adresse des Routers

und des Nameservers.

Im Unterschied zu ARP wird die IP-Adresse nur optional fest einem Rechner zugewiesen. In

der Regel werden Server, Drucker und ähnliche Geräte in einem lokalen Netz jeweils die

gleiche IP-Adresse erhalten. Clients erhalten evtl. auch jeweils ihre letzte Adresse, u.U. aber

auch eine neue. Jede dynamische Adresse verfällt nach einer gewissen Zeit und kann dann

wieder einem neuen Rechner zugewiesen werden. Auf diese Weise lassen sich

beispielsweise einige wenige Adressen einer großen Anzahl an Teilnehmern zuordnen, die

nicht ständig auf das Netz zugreifen. So vergeben Internet-Provider IP-Adressen nur

dynamisch, da sie in der Regel sehr viel mehr Kunden haben als ihnen IP-Adressen

zustehen.

1.14 Domain Name Service (DNS)

Das Domain Name System (DNS) löst die Namen im Internet auf. Das DNS ist eine verteilte

Datenbank.

Hauptsächlich wird das DNS zur Umsetzung von Namen in Adressen (forward lookup)

benutzt. Dies ist vergleichbar mit einem Telefonbuch, das die Namen der Teilnehmer in ihre

Telefonnummer auflöst. Das DNS bietet somit eine Vereinfachung, weil Menschen sich

Namen weitaus besser merken können als Zahlenkolonnen. So kann man sich den

Domainnamen www.bpa-graz.at sehr einfach merken, die dazugehörende IP-Adresse

207.142.131.236 dagegen nicht ganz so einfach.

Mit dem DNS ist auch eine umgekehrte Auflösung von IP-Adressen in Namen (reverse

lookup) möglich.

Darüber hinaus ermöglicht das DNS eine Entkoppelung vom darunter liegenden Aufbau.

(Änderung der IP-Adresse, ohne den Domainnamen ändern zu müssen).

Das DNS löste die hosts-Dateien ab, die bis dahin für die Namensauflösung zuständig

waren. Es zeichnet sich aus durch:

• dezentrale Verwaltung

• hierarchische Strukturierung des Namensraums in Baumform

• Eindeutigkeit der Namen

• Erweiterbarkeit


Komponenten des DNS

Das DNS besteht aus drei Hauptkomponenten:

• Domänennamensraum

• Nameservern

• Resolver

Domänennamensraum

Der Domänennamensraum hat eine baumförmige Struktur. Die Blätter und Knoten des

Baumes werden als Labels bezeichnet. Ein kompletter Domänenname eines Objektes

besteht aus der Verkettung aller Labels. Label sind Zeichenketten (alphanumerisch, früher

war als einziges Sonderzeichen '-' erlaubt, im Jahre 2004 kamen auch noch Umlaute wie: ä,

ö, ü, é, à, è, usw. dazu), die mindestens ein Zeichen und maximal 63 Zeichen lang sind. Die

einzelnen Label werden durch Punkte voneinander getrennt. Ein Domänenname wird mit

einem Punkt abgeschlossen (der hinterste Punkt wird normalerweise weggelassen, gehört

rein formal aber zu einem vollständigen Domänennamen dazu). Ein korrekter, vollständiger

Domänenname (auch FQDN) lautet z.B. www.bpa-graz.at. (der letzte Punkt gehört zum

Domänennamen).

Nameserver

Nameserver sind Programme, die Anfragen zum Domänennamensraum beantworten. Man

unterscheidet zwischen autoritativen und nicht autoritativen Nameservern.

Ein autoritativer Nameserver ist verantwortlich für eine Zone. Seine Informationen über diese

Zone werden deshalb als gesichert angesehen. Für jede Zone existiert mindestens ein

autoritativer Server, der Primary Nameserver. Dieser wird im SOA Resource Record einer

Zonendatei aufgeführt. Aus Redundanz- und Lastverteilungsgründen werden autoritative

Nameserver fast immer als Server-Cluster realisiert, wobei die Zonendaten identisch auf

einem oder mehreren Secondary Nameservern liegen. Die Synchronisation zwischen

Primary und Secondary Nameservern erfolgt per Zonentransfer.

Ein nicht autoritativer Nameserver bezieht seine Informationen über eine Zone von anderen

Nameservern. Seine Informationen werden als nicht gesichert angesehen. Da sich DNS-

Daten normalerweise nur sehr selten ändern, speichern nicht autoritative Nameserver die

einmal von einem Resolver angefragten Informationen im lokalen RAM ab. Diese liegen bei

einer erneuten Anfrage schneller vor. Diese Technik wird als Caching bezeichnet. Jeder


dieser Einträge besitzt ein eigenes Verfallsdatum (TTL time to live). Nach dem Ablauf wird

der Eintrag aus dem Cache gelöscht. Die TTL wird dabei durch einen autoritativen

Nameserver für diesen Eintrag festgelegt und wird nach der Änderungswahrscheinlichkeit

des Eintrages bestimmt (sich häufig ändernde DNS-Daten erhalten eine niedrige TTL). Das

kann u. U. aber auch bedeuten, dass der Nameserver in dieser Zeit falsche Informationen

liefern kann, wenn sich die Daten zwischenzeitlich geändert haben. Ein Spezialfall ist der

caching only Nameserver. In diesem Fall ist der Nameserver für keine Zone verantwortlich

und muss alle eintreffenden Anfragen über weitere Nameserver auflösen.

Ein Domänenname darf inklusive aller Punkte maximal 255 Zeichen lang sein.

Ein Domänenname wird immer von rechts nach links delegiert und aufgelöst, d. h. je weiter

rechts ein Label steht, umso höher steht es im Baum. Der Punkt ganz rechts wird auch als

root (Wurzel) im Namensraum bezeichnet.

Das erste Label (das links vom Punkt für 'root' steht) wird im Allgemeinen auch als Top Level

Domain (TLD) bezeichnet.

Die DNS-Objekte einer Domäne (zum Beispiel die Rechnernamen) werden als Satz von

Resource Records meist in einer Zonendatei gehalten, die auf einem oder mehreren

autoritativen Nameservern vorhanden sind. Statt Zonendatei wird meist der etwas

allgemeiner Ausdruck Zone verwendet.

Resolver

Resolver sind Ansammlungen von Bibliotheken, die Informationen aus den Nameservern

abrufen können. Sie bilden die Schnittstelle zwischen Anwendung und Nameserver. Der

Resolver übernimmt die Anfrage einer Anwendung, ergänzt sie falls notwendig zu einem

FQDN und übermittelt sie an den fest konfigurierten Nameserver.

Ein Resolver arbeitet entweder iterativ oder rekursiv und informiert den Nameserver über die

verwendete Arbeitsweise. Übliche Resolver von Clients arbeiten ausschließlich rekursiv, sie

werden dann auch als Stub-Resolver bezeichnet.

Bei einer rekursiven Anfrage schickt der Resolver eine Anfrage an einen ihm bekannten

Nameserver und erwartet von ihm eine eindeutige Antwort. Diese Antwort enthält entweder

den gewünschten Resource Record oder "gibt es nicht". Rekursiv arbeitende Resolver

überlassen also die Arbeit zur vollständigen Auflösung anderen.


Bei einer iterativen Anfrage bekommt der Resolver entweder den gewünschten Resource

Record oder die Adresse eines weiteren Nameserver, den er als Nächsten fragt. Der

Resolver fragt so von Nameserver zu Nameserver, bis er bei einem autoritativen

Nameserver landet.

Die so gewonnene Antwort übergibt der Resolver an das Programm, das die Daten

angefordert hat, beispielsweise an den Webbrowser.

Bekannte Programme zur Überprüfung der Namensauflösung sind nslookup, host und dig.

Weitere Informationen zur iterativen/rekursiven Namensauflösung finden sich unter rekursive

und iterative Namensauflösung.

DynDNS

Es kann nur Rechnern mit fester, sich also nie ändernden IP-Adresse ein fester

Rechnername zugeordnet werden. Da jedoch sehr viele Nutzer mit Heimrechnern eine

variable IP-Adresse haben (mit jeder Einwahl in das Internet wird eine andere IP-Adresse

aus einem Pool zugeteilt), gibt es inzwischen DynDNS-Betreiber (z.B. DynDNS.org), die

dafür sorgen, dass man auch mit solch rasch ändernden Adressen möglichst immer über

denselben Rechnernamen erreichbar ist.

Domain-Registrierung

Um DNS-Namen im Internet bekanntmachen zu können, muss der Besitzer die Domain, die

diese Namen enthält, registrieren. Durch eine Registrierung wird sichergestellt, dass

bestimmte formale Regeln eingehalten werden und dass Domain-Namen weltweit eindeutig

sind. Domain-Registrierungen werden von Organisationen (Registrars) vorgenommen, die

dazu von der IANA bzw. ICANN autorisiert wurden. In Österreich ist nic.at dafür

verantwortlich. Registrierungen sind gebührenpflichtig.

1.15 Übungsbeispiele

1. Wofür steht die Abkürzung OSI?

2. Benennen Sie die Schichten des OSI-Models.

3. Welche Ziele wurden bei der Entwicklung von TCP/IP definiert?

4. Benennen Sie die Schichten des TCP/IP-Modells?

5. Nenne Sie drei Protokolle der Applikationsschicht.


6. Nennen Sie die zwei Protokolle der Transportschicht.

7. Vergleichen Sie das OSI- mit dem TCP/IP-Modell?

8. Was bedeutet Encapsulation?

9. Wie bezeichnet man die Daten auf den verschiedenen Schichten des TCP/IP-

Modells?

10. Aus welchen Bereichen besteht ein Datagramm?

11. Was bedeutet fragmentieren?

12. Was bedeutet reassemblieren?

13. Wie ist der IP-Header aufgebaut?

14. Wofür wird das Address Resolution Protocol verwendet?

15. Was bedeutet RARP?

16. Wofür wird ICMP verwendet?

17. Welche Merkmale hat das Transmission Control Protocol?

18. Wie ist der TCP-Header aufgebaut?

19. Wie funktioniert der Verbindungsaufbau beim TCP-Protokoll?

20. Was sind Ports?

21. Welche Organisation verwaltet die Portnummern?

22. Wie heißen die drei Bereiche in denen Portnummern aufgeteilt werden?

23. Worin unterscheidet sich UDP von TCP?

24. Mit welchen Protokollen können Rechnern IP-Adressen zugeordnet werden?

25. Ordnen Sie die folgenden IP-Adressen den einzelnen Standard-Netzwerkklassen zu:

192.168.1.44, 190.34.45, 77.55.123.234

26. Wie lautet der Netzwerkteil der Adresse 192.168.1.44, wenn es sich um ein Klasse-C-

Netz handelt.


27. Wozu werden Subnetzmasken eingesetzt?

28. Wandel Sie die IP-Adresse 193.171.90.34 in das Binärformat um.

29. Ermitteln Sie den Netzwerkteil der folgende IP-Adresse (http://jodies.de/ipcalc):

10101100 00010100 01100111 11011001 = 172.20.103.217

der dir folgende Subnetmaske zugeordnet wurde:

11111111 11111111 11111000 00000000 = 255.255.248.0

30. Wofür benötigt man eine Broadcast-Adresse?

31. Kann die IP-Adresse 192.168.4.255 mit der Subnetmaske 255.255.255.0 an ein

Endgerät vergeben werden?

32. Wie lautet die Loopback-Adresse eines lokalen Systems?

33. Geben Sie die IP-Adresse 192.168.1.55 mit der Netzmaske 255.255.255.0 in einer

anderen Schreibweise an.

34. Was ist ein Subnet?

35. Gegeben ist folgende IP-Adresse und Subnetmaske:

172.192.0.0, 255.255.255.0

Es sollen Subnetz mit jeweils 40 Hostadressen berechnet werden.

36. Wie lange darf ein Domänenname sein?

37. Was ist ein Resolver?

38. Wo kann man in Österreich eine Domain registrieren?

39. Wer ist der Domaininhaber der Domain bpa-graz.at?


2 Einrichten der Schulungsumgebung

Für die Schulungsumgebung wird die Linux-Distribution SUSE Linux 10.0 OSS Beta 24

verwendet. Als Testumgebung kann VMware5 , MS Virtual PC6 oder OEMU7 verwendet

werden. Als Installationsmedium wird ein boot.iso Image verwendet. Dieses Image kann von

einem Mirror geladen werden (z.B. http://suse.inode.at/opensuse/distribution/SL-10.0-OSS-

beta2/inst-source/boot/boot.iso).

Sowohl in VMware als auch unter Virtual PC muss eine Virtuelle Hardware konfiguriert

werden.

2.1 VMware

VMware ist eine Softwarefirma, die sich auf Emulation und Virtualisierung spezialisiert hat

und deren bekanntestes Produkt VMware Workstation ist.

Mit VMware Workstation kann unter Linux sowie Microsoft Windows ein kompletter PC

virtualisiert werden. In dem virtualisierten PC können unterschiedliche Betriebssysteme

installiert werden. Es bestehen aber Restriktionen hinsichtlich der technischen Fähigkeiten

des zugrunde liegenden Betriebssystems. Eine mit Windows 2000 eingerichtete virtuelle

Maschine, die auf einem Rechner mit dem älteren Windows NT 4 läuft, kann beispielsweise

dennoch keinen USB-Zugriff durchführen.

Für den Betrieb von Servern gibt es die Produkte VMware GSX, sowie das Flaggschiff ESX-

Server. Letzterer basiert auf einem Vmware eigenen Kernel und benötigt daher kein

Wirtsbetriebssystem.

Mittlerweile lassen sich mit VirtualCenter komplette virtuelle Infrastrukturen darstellen. Das

bedeutet, dass man z.B. in einem Netzwerk 40 Server sieht, es tatsächlich aber nur 2

physikalische Server gibt. Der Rest sind virtuelle Server.

VMware bietet mittels der Software VMotion die Möglichkeit, einen virtuellen Server von

einem physikalischen Host zum nächsten zu transferieren, ohne dass der virtuelle Server

herunter gefahren werden muss. Das hat den Vorteil, dass wenn an der physikalischen

Maschine z.B. Hardware getauscht oder erweitert werden muss, die User weiterarbeiten

können. Für sie ist "ihr" Server nicht down.

4 http://www.opensuse.org/ 5 http://www.vmware.com/ 6 http://www.microsoft.com/windows/virtualpc/ 7 http://fabrice.bellard.free.fr/qemu/


Es lassen sich auch mehrere Maschinen mit verschiedenen Betriebssystemen gleichzeitig

virtualisieren. Die virtualisierten Betriebssysteme sind in Abhängigkeit vom Speicherausbau

etwas langsamer als vergleichbare Installationen auf identischer Hardware.

Im Bereich der Softwareentwicklung erleichtern virtuelle Maschinen den

Entwicklungsprozess, da verschiedene Instanzen gleichzeitig parallel laufen können. Damit

können verschiedene Releasestände bequem getestet werden. Durch Snapshots können

Wiederanlaufpunkte gesichert werden, zu denen wieder zurückgekehrt werden kann. Die

Installationen werden als Imagedateien abgelegt und können damit über eine

Netzwerkanbindung verschiedenen Entwicklern mit gleichem Stand zur Verfügung gestellt

werden.

Nach dem Start von Vmware, beginnt mit File, New Virtual Machine die Konfiguration.

Abbildung 23: VMware Konfiguration für Opensuse10beta2

Außerdem wird eine zweite Netzwerkkarte benötigt. Diese wird Host-only konfiguriert.


Abbildung 24: NIC2 Host-only

Das boot.iso Image wird direkt in das virtuelle CD-Rom Laufwerk eingebunden.

Abbildung 25: VMware boot.iso einbinden

Nach dem Start bootet die Virtuelle-Maschine direkt vom boot.iso Image.


Abbildung 26: Vmware

2.2 Virtual PC

Virtual PC ist eine Virtualisierungssoftware von Microsoft und wird für Windows, wie auch für

Mac OS angeboten. Es ist Bestandteil des Produktes Microsoft Office Professional für Mac

OS.

Mit Virtual PC wird ein kompletter PC virtualisiert, das heißt, mit Hilfe einer so genannten

virtuellen Maschine wird ein PC emuliert. So wie die Java-VM dem Applet eine

Rechenumgebung vorgaukelt, erzeugen Programme wie Virtual PC einen kompletten

virtuellen Rechner. Dadurch wird es möglich, mehrere Betriebssysteme gleichzeitig auf nur

einem PC zu betreiben.

Virtual PC simuliert jedoch nicht den PC auf dem es ausgeführt wird, sondern einen

Standard-PC mit bis zu drei Festplatten, einem CD- oder DVD-Laufwerk, einem

Arbeitspeicher einstellbarer Größe (abhängig von der Arbeitsspeicherkapazität im echten

PC), einer 100-MBit-Netzwerkkarte, einer Audio-Karte und einer 8-MB-Grafikkarte. Eine

Unterstützung für lokale USB- oder PCI-Geräte fehlt. Die Festplatten werden als so genannte

Image-Dateien auf der lokalen Festplatte angelegt.

Nach dem Start von Virtual PC erscheint die Virtual PC Konsole. Mit Neu… startet die

Konfiguration eines neuen Virtuellen PCs.


Abbildung 27: Virtual PC-Konsole

Nach der Begrüßung durch den Assistenten wird ein Virtueller Computer erstellt.

Abbildung 28: Virtuellen Computer erstellen

Für das Konfigurationsfile und die virtuelle Hard Disk empfiehlt es sich einen eigenen Ordner

pro PC einzurichten.


Abbildung 29: Ordner des virtuellen Computers

Abbildung 30: Name und Pfad des virtuellen Computers

Virtul PC erkennt, dass es sich nicht um ein Windows Betriebsystem handelt. Als Vorschlag

wird Anderes übernommen.


Abbildung 31: Virtual PC Betriebsystem

Vorgeschlagener werden 128 MB Arbeitsspeicher. Für effektiveres Arbeiten sollte dieser

Wert erhöht werden.

Abbildung 32: Speicher

Die virtuelle Festplatte wird mit 4 GB erstellt. Der Speicherort entspricht dem Speicherort des

Konfigurationsfiles.


Abbildung 33: Neue virtuelle Festplatte

Abbildung 34: Speicherort der virtuellen Festplatte


Abbildung 35: Abschluss der Konfiguration

Nach der Konfiguration wird in der Virtual PC Konsole über Einstellungen der Adapter 2 auf

lokal gesetzt.

Abbildung 36: Netzwerkadapter 2


Abbildung 37: Start Virtual PC

Nach dem Start des virtuellen Computers, muss im Menü CD das boot.iso Image erfasst

werden.

Abbildung 38: boot.iso wählen

2.3 QEMU

QEMU8 ist ein CPU-Emulator bzw. eine virtuelle Maschine für die Betriebssysteme Linux,

Windows, FreeBSD, NetBSD, OpenBSD und Mac OS X.

8 http://free.oszoo.org/


Er emuliert bereits x86, x86-64 bzw. AMD64, PowerPC und Sparc32/64 Hardware. Alpha,

ARM und S390 werden noch getestet. Geplant sind eine Unterstützung für IA-64, m68k und

MIPS.

Das PC-BIOS stammt von Bochs9 und das VGA-BIOS von Plex86/Bochs.

Diverse Betriebssysteme wie z.B. AROS, DOS incl. dessen grafische Bedienoberflächen

PC/GEOS, OpenGEM und SealOS (VM86 Mode wird unterstützt, um DOSEMU ausführen

zu können), FreeBSD, NetBSD, OpenBSD, Linux, MenuetOS, OS/2, QNX, ReactOS,

Syllable, Unununium und Windows laufen unter QEMU.

Emuliert wird neben der CPU auch:

• PCI und ISA-System (i440FX host PCI bridge und PIIX3 PCI to ISA bridge)

• Grafikkarte (Cirrus CLGD 5446 PCI VGA card oder Standard-VGA-Grafikkarte mit

Bochs VESA Extensions (Hardware Level, inclusive aller nicht Standard Modi)

• PS/2 Maus und Tastatur

• zwei PCI ATA-Schnittstellen mit Unterstützung für maximal vier Festplatten-Images

im eigenen Format oder im Format von VMWare, VirtualPC, Bochs, Knoppix (cloop)

und dd

• CD-ROM/DVD-Laufwerk über ISO-Abbild oder reales Laufwerk

• Diskettenlaufwerk

• Netzwerkkarte (NE2000 PCI Netzwerk Adapter) und ein DHCP-Server

• Serieller Port

• Paralleler Port

• Soundkarte (Soundblaster 16)

Das Starten von Live-CD- und Boot-Disketten-Images ist problemlos möglich.

9 http://bochs.sourceforge.net/


Abbildung 39: QEMU Manager

Die Installation und Konfiguration von QEMU wird im Wikibook QEMU10 beschrieben. Zur

leichteren Bedienung kann das Programm QEMU Manager11 verwendet werden.

10 http://de.wikibooks.org/wiki/QEMU 11 http://www.davereyn.co.uk/qemu.htm


Abbildung 40: Opensuse 10 unter QEMU

2.4 Netzwerk – Installation

Nach dem Start des virtuellen Computers wird vom boot.iso Image gebootet. Es erscheint

der gewohnte Suse Installations-Bildschirm.


Abbildung 41: Netzwerk-Installation

Die Sprache wird mit � gewählt. Der Modus Installation wird bestätigt.

Abbildung 42: Keine Installationsquelle

Die Fehlermeldung, keine Installations-Quelle wird übernommen.


Abbildung 43: Linuxrc

Der Installationsmanager Linuxrc startet. Die Tastaturbelegung Deutsch wird aktualisiert.

Abbildung 44: Linuxrc Hauptmenü

Im Hauptmenü von Linuxrc wird Installation / System starten gewählt.


Abbildung 45: Linuxrc - Installation

Abbildung 46: Linuxrc Quellmedium

Als Quellmedium wird Netzwerk ausgewählt.


Abbildung 47: Linuxrc – Netzwerkprotokoll

Es empfiehlt sich das FTP-Protokoll oder HTTP-Protokoll zu verwenden. Die Netzwerkkarte

eth0 muss verwendet werden.

Abbildung 48: Linuxrc - DHCP aktivieren


Ist im Netzwerk ein DHCP-Server aktiv, kann dieser verwendet werden. Ohne DHCP –

Server, müssen IP-Adresse, Netzmaske und Gateway händisch vergeben werden,

Abbildung 49: Linuxrc - HTTP Server

Die möglichen Mirror-Server12 sind auf der OpenSuSE Homepage eingetragen. Für die

Installation wird die IP-Adresse des Servers benötigt. Durch Ping auf den Hostnamen kann

die Adresse ausgelesen werden. Zum Beispiel:

/ # ping suse.inode.at PING suse.inode.at (81.223.20.170) 56(84) bytes of data. 64 bytes from 81.223.20.170: icmp_seq=1 ttl=64 time=…

Abbildung 50: Linuxrc – HTTP-Proxy

Wird im Netzwerk ein Proxy-Server verwendet, muss dieser bekannt gegeben werden.

12 http://www.opensuse.org/index.php/Mirrors_Released_Version#Europe


Abbildung 51: Linuxrc – Verzeichnis

Das Installationsverzeichnis wird angegeben. Dieses kann je nach Server variieren (z.B.

http://suse.inode.at/: /opensuse/distribution/SL-10.0-OSS-beta3/inst-source). Das

Bereitstellen der Netzwerk-Installation einer neuen SuSE-Linux Version erfolgt erst einen

gewissen Zeitraum nach dem Verkaufsstart. Die weitere Installation entspricht der

Grundinstallation.

Folgende Einstellungen sollten bei der Installation verwendet werden.

Uhr und Zeitzone

Region: Europa

Zeitzone: Österreich

Rechneruhr eingestellt auf: lokale Zeit

Bildschirm-Einstellungen

KDE oder GNOME

Installationseinstellungen

…

Software-Auswahl: simple Web Server with Apache2

…

Root-Passwort

rooti

Benutzer

Username: tester

Passwort: te123er

Direkt anmelden: deaktiviert

Netzwerk

eth0: DHCP, wenn vorhanden

eth1: 192.168.0.254/255.255.255.0

Host: linux00.schule.local


DNS: 193.171.90.37, 193.171.4.60

Firewall: deaktiviert


40. Von welchen Netzwerkquellen kann Opensuse installiert werden?

41. Wodurch unterscheidet sich die FTP von der http Installationsquelle?

42. Nennen Sie drei Opensuse Mirror-Server.

43. Wie erhalten Sie die IP-Adresse eines Mirror-Servers?


3 Serverdienste

3.1 Network File Service (NFS)

Der Network File Service - abgekürzt NFS (früher: Network File System) - ist ein von Sun

Microsystems entwickeltes Protokoll, das den Zugriff auf Dateien über ein Netzwerk

ermöglicht. Dabei werden die Dateien nicht (wie z.B. bei FTP) übertragen, sondern die

Benutzer können auf Dateien, die sich auf einem entfernten Rechner befinden, so zugreifen,

als wenn sie auf ihrer lokalen Festplatte abgespeichert wären.

Bei diesem UNIX-Netzwerkprotokoll handelt es sich um einen Internet-Standard (RFC 1094,

RFC 1813), der auch als verteiltes Dateisystem (engl. Distributed File System) bezeichnet

wird. NFS-Dienste sind auch auf Microsoft-Windows-Servern verfügbar, wodurch UNIX-

Workstations Zugang zu deren Dateien erhalten können. Die Entsprechung zu NFS heißt

unter Windows- und OS/2-Umgebungen Server Message Block (SMB). Sowohl NFS als

auch SMB regeln Funktionen, um Dateien zu öffnen und zu schließen. Ferner regeln sie die

Zugriffskontrolle, welcher Benutzer Lese- und/oder Schreibzugriff auf eine Ressource erhält.

Abbildung 52: NFS im OSI-Schichtenmodell

NFS arbeitet auf dem Netzwerk-Transportprotokoll TCP/IP. NFS ist ursprünglich ein

zustandsloses UDP-Protokoll. Mittlerweile gibt es aber auch NFS über TCP. Derzeit wird

NFS Version 4 entwickelt, welches schneller und nicht mehr zustandslos sein soll.

3.1.1 NFS - Server

Benötigte Pakete: nfsserver, nfs-utils, portmap

Die Konfiguration des NFS-Servers erfolgt direkt mit YaST.


Abbildung 53: Yast - Modul NFS-Server

In YaST wird die Kategorie Netzwerkdienste gewählt. Mit NFS-Server startet die

Konfiguration.

Abbildung 54: NFS-Server starten

Der Schalter Starten muss aktiviertet werden. Ist die Firewall aktiviert, muss zusätzlich der

NFS-Dienst und der Portmapper13 frei geschalten werden.

13 Ein Portmapper übernimmt in der Informationstechnik die Koordination der durch den Client gewünschten Funktionsaufrufe.


Abbildung 55: Zu exportierendes Verzeichnis wählen

Das zu exportierende Verzeichnis kann mit Durchsuchen direkt aus dem Dateibaum

gewählt werden.

Abbildung 56: Rechner und Zugriffsoptionen für NFS

Unter Rechner-Wildcard können die IP-Adressen der Clients angeführt werden. Alternativ

kann * für alle Rechner verwendet werden, *.domain nur für eine bestimmte Domäne und

192.168.100.0/255.255.255.0 für ein bestimmtes Subnet.

Tabelle 5: Optionen für den NFS-Export

ro "read only" (schreibgeschützt)

rw "read/write" (volle Lese- und Schreibrechte für den Client)

noaccess Zugriffsverweigerung für Unterverzeichnisse

root_squash root erhält die UserID des Pseudobenutzers nobody, eine sichere

(Default-)Einstellung, da so der root-Benutzer des Client-Rechners

nicht mit root-Rechten auf dem Server schreiben kann.


no_root_squash root-Account auf dem Client wird dem auf dem Server gleichgestellt.

Hier ist der root-User des Client-Rechners auch root auf dem Server!

all_squash Alle Zugreifenden erhalten die Nobody-UID

anongid=gid Squashing der Gruppe. Die Gruppen-ID wird auf gid gesetzt. Bei

dieser Option kann root entscheiden, mit welcher Server-GID die

Client-User arbeiten sollen, sobald sie Zugriff auf den Server haben.

anonuid=uid Squashing des Users. Die zugreifenden User bekommen die User-ID

uid verpasst.

3.1.2 NFS – Client

Freigegebene Verzeichnisse können direkt mit YaST in den Dateibaum eingebunden werde.

Abbildung 57: Yast - Modul NFS-Client

In YaST wird die Kategorie Netzwerkdienste gewählt. Mit NFS-Client startet die

Konfiguration.


Abbildung 58: Konfiguration des NFS-Client

Mit Hinzufügen kann ein NFS-Server gewählt werden.

Abbildung 59: NFS-Verzeichnis einbinden

Wurde der Server gefunden, kann ein exportiertes Verzeichnis gewählt werden. Nach der

Angabe des lokalen Mountpointes können Optionen für das Einbinden gesetzt werden.

Tabelle 6: Mount-Parameter für über NFS-Verzeichnisse

rw, ro Schreib- und Lesezugriff bzw. Nur-Lese-Zugriff


fg Mount-Vorgang im Vordergrund ("foreground")

bg Mount-Vorgang im Hintergrund ("background")

retrans=zahl Anzahl der Wiederholungsversuche, um einen Mount durchzuführen.

Der Default-Wert liegt bei 5.

hard "Hartes" Mounten, d. h., es werden Anfragen abgesetzt, bis der

Server antwortet (default).

soft "Weiches" Mounten, d. h., wenn ein Zähler abgelaufen ist (retrans),

gibt es eine Fehlermeldung, und der Versuch wird abgebrochen.

intr, nointr Möglichkeit des Abbruchs durch eine Tastenkombination ("interrupt")

bzw. das Verhindern derselben.

remount Aushängen eines Verzeichnisses, um es sofort wieder

(beispielsweise mit neuen Optionen) einzuhängen.

suid, nosuid Möglichkeit zur Benutzung des SUID-Bits auf dem eingehängten

Dateisystem.

retry=zahl Anzahl der erfolglosen Mount-Versuche (Default ist 10000), bis

endgültig abgebrochen wird.

wsize=zahl Größe des Puffers für Schreibzugriffe (Default liegt zwischen 2048

und 32 kB, je nach Unix-System und -Version).

rsize=zahl Puffergröße für Lesezugriffe (Default siehe oben).

timeo=zahl Zeitspanne für Wiederholversuche, angegeben in Zehntelsekunden.


proto=protokoll ab Version 3: Angabe des Protokolls (UDP oder TCP).

nfsstat

Mit diesem Befehl werden NFS Statisken ausgegeben

/ # nfsstat Server rpc stats: calls badcalls badauth badclnt xdrcall 20860 0 0 0 0 Server nfs v3: null getattr setattr lookup access readlink 0 0% 264 1% 0 0% 1148 5% 14726 70% 32 …

Tabelle 7: nfsstat Optionen

-s Gibt nur serverseitige Informationen aus. Voreingestellt sind sowohl Client-

als auch Serverinformationen.

-c Gibt nur clientseitige Informationen aus. Voreingestellt sind sowohl Client- als

auch Serverinformationen.

-n Gibt nur NFS-Statistiken aus. Voreingestellt sind NFS und RPC Statistiken.

-r Gibt nur RPC-Statistiken aus.

Tabelle 8: NFS Konfigurations-Datein

/etc/export Im File /etc/exports sind alle zu exportierenden Verzeichnisse

aufgeführt. Dazu kommen Angaben, wer (welche Clients) wie (mit

welchen Rechten) auf die Freigaben zugreifen dürfen.

/etc/hosts.allow Die Datei hosts.allow dient der Zugangskontrolle von


Nutzern/Diensten anderer Rechner. Für bestimmte Hosts/Netzwerke

kann hier der Zugriff auf bestimmte lokale Dienste explizit gestattet

werden.

/etc/hosts.deny In hosts.deny kann der Zugang zu bestimmten Diensten des

Rechners für bestimmte Hosts/Netzwerke explizit untersagt werden.

/etc/fstab In der Datei /etc/fstab des lokalen NFS-Client-Rechners stehen alle

Dateisysteme, Schnittstellen und Devices, die irgendwann einmal

gemountet werden bzw. werden können.

3.2 DHCP – Server

Das DHCP (Dynamic Host Configuration Protocol) ermöglicht mit Hilfe eines entsprechenden

Servers die dynamische Zuweisung einer IP-Adresse und weiterer Konfigurationsparameter

an Computer in einem Netzwerk (vgl. 1.13 Dynamic Host Configuration Protocol).

Benötigte Pakete: dhcpcd, dhcp-server

Dynamisches DHCP

Die Konfiguration des dynamischen DHCP erfolgt direkt mit YaST.

Abbildung 60: Yast - Modul DHCP-Server

In YaST wird die Kategorie Netzwerkdienste gewählt. Mit DCHP-Server startet die

Konfiguration.


Abbildung 61: DHCP auf Netzwerkkarte eht1 binden

Der DHCP Server wird auf die Netzwerkkarte eth1 gebunden. Händisch müsste eine Route

mit der Adresse 255.255.255.255 der Netzwerkkarte zugeordnet werden.

/ # route add 255.255.255.255 eth0

Abbildung 62: DHCP Konfiguration

Die globalen Einstellungen werden in Schritt 2 gesetzt. Im Schritt 3 wird der dynamische

Adressbereich vergeben.


Abbildung 63: Dynamisches DHCP

Das Ergebnis der Konfiguration kann in der Datei /etc/dhcpd.conf betrachtet werden.

Abbildung 64: /etc/dhcpd.conf

Statisches DHCP

Beim Einrichten von statischen DHCP, muss die Datei /etc/dhcpd.conf editiert werden.

# DHCP-Server statisch #/etc/dhcpd.conf


# # -> Kommentarzeile # Folgende Options gelten für alle Rechner option domain-name "schule.local"; option domain-name-servers 193.171.90.37; option subnet-mask 255.255.255.0; option broadcast-address 192.168.0.255; option routers 192.168.0.254; #Verfallsdauer default-lease-time 86400; max-lease-time 2592000; subnet 192.168.0.0 netmask 255.255.255.0 { # Alle Clients bekommen IP-Adresse nach ihrer MAC-Adresse host client10 { hardware ethernet 00:10:5f:58:43:9b; fixed-address 192.168.0.10; } host client11 { hardware ethernet 00:10:5f:47:3b:05; fixed-address 192.168.0.11; } }

Gemischtes DHCP

Der Normalfall wird das gemischte DHCP sein. Die ganze Konfigurationsdatei

/etc/dhcpd.conf sieht dann so aus:

# DHCP-Server Konfiguration gemischtes DHCP #/etc/dhcpd.conf # # -> Kommentarzeile # Folgende Options gelten für alle Rechner option domain-name "schule.local"; option domain-name-servers 193.171.90.37 193.171.4.60; option subnet-mask 255.255.255.0; option broadcast-address 192.168.0.255; option routers 192.168.0.254; #Verfallsdauer default-lease-time 86400; max-lease-time 2592000; subnet 192.168.0.0 netmask 255.255.255.0 { # Alle Clients bekommen IP-Adresse nach ihrer MAC-Adresse host client10


{ hardware ethernet 00:10:5f:58:43:9b; fixed-address 192.168.0.10; } host client11 { hardware ethernet 00:10:5f:47:3b:05; fixed-address 192.168.0.11; } }

#Die Adressen 192.168.0.100 bis 192.168.0.200 werden→ dynamisch vergeben range 192.168.0.100 192.168.0.200; }

Tabelle 9: DHCP Konfigurations-Datein

/etc/dhcpd.conf Das File /etc/dhcpd.conf ist das zentrale Konfigurations-File für den

DHCP-Server.

3.3 DNS – Server

Das Domain Name System (DNS) ist einer der wichtigsten Dienste im Internet. Das DNS ist

eine verteilte Datenbank, die den Namensraum im Internet verwaltet (vgl. 1.14 Domain

Name Service).

Ein weit verbreiteter Nameserver unter Linux ist bind.

Benötigte Pakete: bind

Der erste Schritt ist das Ändern der Konfiguration der Netzwerkkarten. Als Nameserver wird

die IP des Rechners selber als Nameserver 1 eingetragen.


Abbildung 65: Netzwerkkarte für DNS vorbereiten

Die forward Zone kann direkt mit Yast eingerichtet werden. In YaST wird die Kategorie

Netzwerkdienste gewählt. Mit DNS-Server startet die Konfiguration.

Abbildung 66: DNS-Server

Im ersten Schritt wird der Start des Nameservers festgelegt. Um eine funktionierende

Namensauflösungen zu gewährleisten, muss der Dienst beim Systemstart aktiviert werden.


Abbildung 67: DNS-Server starten

Als Forwarders werden weitere DNS-Server bezeichnet. Kann der eigene Server die

Namensauflösung nicht durchführen, wird die Anfrage an diese Server weitergeleitet.

Abbildung 68: DNS-Forwarder

Abbildung 69: DNS-Protokollierung


3.3.1 Forward Zone

Nach der Einstellung der Protokollierung wird die erste DNS-Zone erstellt. Die Zone

schule.local wird eine Locale-Masterzone. Der Zonen-Transport kann aktiviert werden,

muss aber nicht.

Abbildung 70: DNS-Master-Zone

Abbildung 71: DNS Zonen-Transport

Der NS-Eintrag bestimmt den zuständigen Nameserver der Zone. Pro Zone sollten zwei

zuständige Nameserver eingetragen werden (Primary und Sekondary).

Abbildung 72: NS (Nameserver) der Zone schule.local


Abbildung 73: MX (Mailserver) der Zone schule.local

Der MX-Eintrag bestimmt den zuständigen Mailserver für die Zone.

Abbildung 74: SOA (Start of Authority)

Neu seit Bind8.2 ist der Eintrag TTL. In früheren Versionen wurde diese Option an anderer

Stelle aufgeführt, aber seit der Veröffentlichung von RFC 2308 musste die TTL-Anweisung

an einem anderen Ort angegeben werden und hierfür wurde die erste Zeile gewählt. Dieser

Wert gibt an, wie lange ein abfragender Nameserver die Daten in seinem Cache halten darf,

bevor er die Daten aus dem Cache wieder entfernt.


Der zweite wichtige Eintrag ist der SOA (Start of Authority)-Eintrag. In dieser Zeile stehen die

Zone, die Klasse, der Ressource Record selbst, die Autorität der Zone und der

Ansprechpartner (Mailadresse auf der Autorität) bei Problemen.

Zusätzlich zu diesen Angaben beinhaltet dieser SOA-Eintrag noch einige Steuerdaten, wie

Seriennummer, Aktualisierung oder Zeitpunkt der Ungültigkeit, wobei der wichtigste Eintrag

die Seriennummer darstellt.

Abbildung 75: A, CNAME-Records (canonical names)

Die A-Records sind eine einfache Abbildung von Namen auf IP-Adressen. Mailserver-

Einträge (MX) und CNAME-Records (canonical names) sind Aliase auf bereits beschriebene

Namen. Dadurch ist es möglich, ein System mit mehreren Namen anzusprechen.

Die so erstellte Zone-Datei wird im Verzeichnis /var/lib/named/master unter dem Namen

schule.local abgelegt.


Abbildung 76: /var/lib/named/master/schule.local

Die so erstellte DNS kann nun DNS Namen wie zum Beispiel client10.schule.local die IP-

Adresse 192.168.0.10 zuordnen. Die umgekehrte Zuordnung von IP-Adresse in einen DNS

Namen funktioniert noch nicht. Diesen Prozess ermöglicht der Reverse-Lookup.

3.3.2 Reverse-Lookup

Es wird dazu händisch die Datei /var/lib/named/master/0.168.192.in-addr.arpa angelegt.


Abbildung 77: /var/lib/named/master/0.168.192.in-addr.arpa

Diese Datei ist ähnlich wie die Datei /var/lib/named/master/schule.local aufgebaut. Da

diese Datei für das Reverse-Lookup zuständig ist werden hier mit Pointer-Records (PTR)

von Adressen auf Namen verwiesen. Dabei wird die IP-Adresse in umgekehrter Form

inklusive der Domain in-addr und Arpa angeben, da die Auflösung, gleich der Auflösung von

Namen, von rechts nach links erfolgt.

Wichtig bei beiden Dateien ist der Punkt hinter den Adress- und Namensangaben. Dieser

Punkt symbolisiert die Wurzel (Root), von der alles ausgeht. Wird dieser Punkt nicht

angegeben, so hat dies fatale Folgen, denn Bind interpretiert alle Angaben ohne Punkt als

relativ und hängt den Zonennamen an.

Zusätzlich muss diese Zonen-Datei in der Datei /etc/named.conf bekannt gegeben werden.


Abbildung 78: /etc/named.conf

Nach dem Neustart des Nameserver steht die Zone schule.local zur Verfügung.

3.3.3 Master- und Secondaryzonen

Im vorhergehenden Kapitel ging es rein um die Master-Dateien auf einem Server. Ein

System, das als Master für eine Zone fungiert, muss die beiden gerade genannten Dateien

vorhalten und den Slave-Servern (falls vorhanden) zur Verfügung stellen. Der Slave-Server

erkennt durch die Einträge in der /etc/named.conf für welche Zonen er Daten und von

welchem Server er diese abrufen muss. Auf ihm werden diese beiden Dateien keinesfalls

erstellt. Schon allein aus Redundanz- und Fehlergründen werden die Dateien einmal erstellt

(Master) und bei Bedarf transferiert (Slave). So minimiert sich die Pflege erheblich. Dies

bedeutet auch, dass beide Zoneninformationsdateien, sowohl auf dem Master- als auch auf

dem Slave-Nameserver, vollkommen identisch sind und beide dieselben Records

beinhalten.

Der Slave-Nameserver wird auch nicht bei jeden Aufruf einen Transfer initiieren, sondern

lediglich, wenn die TTL ausläuft, die Zonendaten aus dem Cache entfernt oder sich die

Seriennummer erhöht. Nun wird auch der Sinn der Seriennummer deutlich. Der

Administrator muss bei jeder Änderung die Seriennummer erhöhen. Überprüft nun der

Slave-Nameserver die Zonendateien und stellt fest, dass sich die Seriennummer erhöht hat,


initiiert er sofort einen Transfer und bringt seinen Informationsbestand auf den neuesten

Stand. Schneller geht es durch die Option notify. Hierbei versendet der Master-DNS eine

Benachrichtigung an alle Slave-Nameserver, damit ein Update durchgeführt werden kann.

3.3.4 Diagnose

named-checkconf

Mit named-checkconf wurde ein Tool entwickelt, dass die Syntax der Konfigurationsdatei

überprüft und gegebenenfalls interveniert. Sollte sich ein Fehler eingeschlossen haben,

erscheint eine Fehlermeldung und die Zeilenangabe. Bei einer richtigen Konfigurationsdatei

erhält man einen Return-Code von 0 und keine weitere Meldung. Standardmäßig wird die

/etc/named.conf als Konfigurationsdatei eingelesen. Sollten Sie diese also irgendwo anders

abgelegt haben, so müssen Sie diese explizit angeben, damit die Überprüfung stattfinden

kann.

named-checkzone

Ein weiteres Tool ist named-checkzone. Mit diesem Tool können Sie Ihre Zonen auf Fehler

testen.

/ # named-checkzone schule.locao /var/named/master/schule.local

Bei Beendigung wird ebenfalls ein Return-Code ausgegeben und evtl. eine kleine

Zusammenfassung, ob die Überprüfung etwas ergeben hat.

nslookup

Nslookup ist traditioneller Bestandteil der BIND-Software und dient (einzig) als Debugging-

Werkzeug bei der Fehlersuche. Es erlaubt die direkte Abfrage eines Nameservers und

Zugriff auf nahezu jede Information. Ab BIND Version 9 ist nslookup nur noch aus

Kompatibilitätsgründen enthalten, da dessen Funktionalität komplett vom neueren dig

übernommen wurde.

Kommandozeilenmodus

Im Kommandozeilenmodus wird nslookup mit dem aufzulösenden Rechnernamen

aufgerufen.

/ # nslookup linux00.schule.local


Bei erfolgreicher Recherche, antwortet nslookup mit Namen und Adresse des antwortenden

DNS-Servers und mit der gesuchten IP-Adresse.

Zum reverse lookup wird das Kommando einfach mit der zu recherchierenden IP-Adresse

aufgerufen.

/ # nslookup 192.168.0.10

Seine Stärke spielt nslookup allerdings erst im interaktiven Modus aus.

Interaktiver Modus

Den interaktiven Modus von nslookup erreichen Sie durch bloße Eingabe des Kommandos

ohne jegliche Optionen. Beenden lässt sich das Programm durch Eingabe von exit oder

mittels der Tastenkombination �+�

Abbildung 79: nslookup


dig

Domain Information Groper ist das Nachfolgetool von nslookup. Mit dig bekommt der User

einiges mehr an Informationen heraus, als beim alten Auflösevorgang. Hierbei wird auch

angezeigt, welcher Autorität die Zone untersteht, sowie eine gleichzeitige zusätzliche

Auflösung aller Nameserver.

Abbildung 80: dgi Domain Information Groper

host

Ein weiteres Diagnose-Werkzeug ist host, das per Voreinstellung lediglich eine verkürzte

Ausgabe der vorherigen Tools darstellt, sich jedoch mit diversen Schaltern und Parametern

zu einem sehr mächtigen Werkzeug verwandeln kann.

/ # host linux00.schule.local linux00schule.local has adress 192.168.0.254

Tabelle 10: DNS Konfigurationsdatein

/etc/named.conf Das File /etc/named.conf ist das zentrale Konfigurations-File für den


bind Name-Server.

3.4 Samba Grundkonfiguration

Das SMB-Protokoll (Server Message Block-Protokoll) wird von der Firma Microsoft für

Windows 3.11, NT und 95/98 genutzt, um den gemeinsamen Zugriff auf Laufwerke und

Drucker zu gestatten.

Mit der Sammlung der Samba-Tools von Andrew Tridgell besteht die Möglichkeit von UNIX-

Rechner Verzeichnisse und Drucker mit Windows-Rechnern zu teilen.

Insgesamt bietet Samba vier verschiedene Optionen an:

• Linux-Laufwerke werden auch von Windows-Rechnern genutzt.

• Windows-Laufwerke werden auch von Linux-Rechnern genutzt.

• Ein an einer Linux-Maschine angeschlossener Drucker wird auch von Windows-

Rechnern genutzt.

• Ein an einem Windows-Rechner angeschlossener Drucker wird auch von Linux-

Rechnern genutzt.

Im Rahmen dieses Skriptes soll nur die einfache Freigabe eines Ordners gezeigt werden.

Die Grundkonfiguration von Samba erfolgt direkt mit YaST.

Benötigte Pakete: samba, smba-client

In YaST wird die Kategorie Netzwerkdienste gewählt. Mit Samba-Server startet die

Konfiguration.


Abbildung 81: Yast - Modul Samba-Server

Im ersten Schritt wird der Name der Windows Arbeitsgruppe vergeben.

Abbildung 82: Samba Arbeitsgruppe

Für die Freigabe eines Ordners, muss der Samba-Server kein Domain Controller sein.

Abbildung 83: Samba-Servertyp


Abbildung 84: Samba Start

Samba soll direkt nach dem Systemstart aktiviert werden.

Abbildung 85: Shares

Neben den bereits vorkonfigurierten Freigaben kann mit Hinzufügen ein weiters Share

aktiviert werden.


Abbildung 86: Neues Share freigeben

Freigabenamen, Beschreibung der Freigabe und Pfad für Freigabe werden gewählt.

Abbildung 87: Samba root Passwort


Abschließend wird das Samba root Passwort vergeben.

Abbildung 88: Freigegebner Ordner

Im Windows Explorer kann nach der Anmeldung auf die freigegebene Verzeichnisse

zugegriffen werden. Zusätzliche User können mit dem Befehl smbadduser hinzugefügt

werden. Diese User müssen bereits als Linux User existieren.

/ # smbadduser tester:tester

Eine einfache Möglichkeit der Administration bietet die Weboberfläche Swat.

3.4.1 Swat

Vor dem Start muss in YaST der Netzwerkdienst xinietd geändert werden.


Abbildung 89: xinetd

Abbildung 90: xinietd swat

Der Netzwerkdienst muss gestartet werden. Für Swat wird der Status auf An gestellt.


In einem Browser auf dem Server kann nun mit http://127.0.0.1:901/ Swat aufgerufen

werden.

Abbildung 91: Swat

Tabelle 11: Samba Konfigurations-Datein

/etc/samba/smb.conf Das File /etc/samab/smb.conf ist das zentrale Konfigurations-File

für den Samba-Server.

/etc/xinetd.d/swat Startparameter für Swat

/etc/samba/smbuser Samba Usernamen

/etc/samba/smbpasswd Verschlüsselte Passwörter der Samba User


3.5 Apache2

Der Apache HTTP Server ist ein Produkt der Apache Software Foundation und der

meistverbreitete Webserver im Internet, noch vor den Internet Information Services (IIS) von

Microsoft. Laut offizieller Apache-FAQ wurde der Name aus Respekt vor dem

nordamerikanischen Indianerstamm, der Apachen, gewählt. Nach vielen anderen Quellen

handelt es sich dagegen um eine Umdeutung von „a patchy server“, was soviel wie ein

zusammengeflickter Server bedeutet. Da der Apache HTTP Server ursprünglich eine

gepatchte Erweiterung des alten NCSA HTTP Servers war, scheint auch diese Variante

plausibel.

Neben Unix und Linux läuft Apache auch auf Win32, NetWare sowie einer Vielzahl weiterer

Betriebssysteme. In der aktuellen Version 2.0 wurde die Stabilität und Geschwindigkeit des

Servers, vor allem auch auf Nicht-UNIX-Systemen, erheblich verbessert. Die Bibliothek

Apache Portable Runtime (APR) stellt eine Verallgemeinerung wichtiger Systemaufrufe zur

Verfügung, so dass die individuellen Stärken des jeweiligen Betriebssystems ausgenutzt

werden können. Hinzu kommen verschiedene Multiprocessing-Module (MPM), die je nach

Plattform unterschiedliche Lösungen für die gleichzeitige Bedienung mehrerer Client-

Anfragen anbieten. Beispielsweise setzt das MPM prefork für klassische UNIX-Systeme auf

Forking von Prozessen, während mpm_winnt für die unter Windows empfehlenswerteren

Threads optimiert ist.

Der Apache-Webserver ist modular aufgebaut. Durch entsprechende Module kann er

beispielsweise die Kommunikation zwischen Browser und Webserver verschlüsseln

(mod_ssl), als Proxy-Server eingesetzt werden (mod_proxy) oder komplexe Manipulationen

von HTTP-Headern (mod_headers) und URLs (mod_rewrite) durchführen.

Der Apache bietet die Möglichkeit mittels serverseitiger Skriptsprachen Webseiten

dynamisch zu erstellen. Häufig verwendete Skriptsprachen sind PHP oder Perl. Diese sind

kein Bestandteil des Webservers, sondern müssen ebenfalls entweder als Module

eingebunden oder über die CGI-Schnittstelle angesprochen werden. Über das bei der

Apache-Installation enthaltene mod_include können so genannte Server Side Includes (SSI)

ausgeführt werden. Damit ist es möglich einfache dynamische Webseiten zu erstellen und

den Verwaltungsaufwand von statischen Webseiten zu minimieren.

Benötigte Pakete: apache, mod_php, mod_perl

Die Konfiguration des HTTP-Servers erfolgt direkt mit YaST.


In YaST wird die Kategorie Netzwerkdienste gewählt. Mit HTTP-Server startet die

Konfiguration.

Abbildung 92: Yast - Modul HTTP-Server

Im ersten Schritt der Konfiguration wird bestimmt, auf welche Netzwerkgeräte und auf

welchem Port Apache2 lauschen soll.

Abbildung 93: Apache2 Netzwerkgeräte

Im zweiten Schritt werden die benötigten Module eingebunden.

Abbildung 94: Apache2 Module


Abbildung 95: Apache2 Standard Host

Nach der Konfiguration des Standard Host werden die Einstellungen für Virtual Hosts

übernommen.


Abbildung 96: Apache2 Virtual Hosts

Der letzte Schritt der Konfiguration bestimmt den Start des Webservers.

Abbildung 97: Apache2 starten


In einem beliebigen Browser kann nun auf den Webserver zugegriffen werden.

Tabelle 12: NFS Konfigurations-Datein

/etc/apache2/httpd.conf Das File /etc/apache2/httpd.conf ist das main-Server

Konfigurations-File

/etc/apache2/listen.conf In dieser Datei wird der Server an Netzwerkgeräte und

Ports gebunden.

/etc/apache2/default-

server.conf

Hier werden die globalen Einstellungen für alle Virtual Hosts

gemacht.

/etc/apache2/mod_usersir.conf Dieses File enthält die Einstellungen für die public-html

Verzeichnisse der einzelnen User.

3.6 Postfix

Postfix ist ein Mail Transfer Agent für Unix- und Linux-Systeme. Es wurde erschaffen, um

eine kompatible Alternative zu Sendmail zu bieten und bei dessen Entwicklung besonders

auf Sicherheit geachtet wurde. Postfix ist aber nicht nur sicher, sondern auch schnell und

einfach zu administrieren. Zur Außenwelt verhält es sich wie Sendmail, aber im Inneren ist

es komplett anders aufgebaut.

Eigenschaften

• schnell

• einfache Administration

• sicherer Mailserver

• Aufrufkompatibilität mit Sendmail

• Modularer Programmaufbau

• Module werden, falls nicht erforderlich, nicht unter dem Benutzer root ausgeführt.


Benötigte Pakete: apache, mod_php, mod_perl

Die Konfiguration des Mail-Servers erfolgt direkt mit YaST.

In YaST wird die Kategorie Netzwerkdienste gewählt. Mit Mail Transfer Agent startet die

Konfiguration.

Abbildung 98: Yast - Modul Mail Transfer Agent

Abbildung 99: Postfix Verbindungsart

Die Wahl der Verbindungsart ist abhängig von der Anbindung an das Internet. Für

Standleitung, ADSL, Cabel oder ähnlichen wird Permanent gewählt. Wird über Modem

eingewählt, muss Einwahl verwendet werden.


Abbildung 100: Postfix Ausgehender Mailserver

Soll zum versenden ein bestimmter Mailserver verwendet werden, wird dieser als

Ausgehender Mailserver eingetragen. In diesem Fall müssen Authentifikation und

Masquerading auch konfiguriert werden. Bleibt das Feld leer, werden die Mails direkt

zugestellt.

Abbildung 101: Postfix Eingehende Mails

Mit Entfernet SMTP-Verbindungen akzeptieren, kann der Mailserver auch E-Mails

empfangen.


Mailversand testen

Mit dem Befehl mail können E-Mails direkt von der Befehlszeile versendet werden. to-addr

wird dabei durch eine gültige E-Mail Adresse ersetzt.

/ # echo �Test von linux00.schule.local� | mail –s testmail to-addr

3.7 Qpopper

Qpopper14 ist ein weit verbreiteter, einfacher POP3-Server für Linux. Das Programm wurde

entwickelt von Qualcomm Incorporated15.

Benötigte Pakete: popper

Die Konfiguration des Pop3-Servers erfolgt direkt mit YaST.

In YaST wird die Kategorie Netzwerkdienste gewählt. Mit Netzwerkdienste (xinitd) startet

die Konfiguration.

Abbildung 102: YaST - Modul Netzwerkdienste (popper)

14 http://www.eudora.com/products/unsupported/qpopper/ 15 http://www.qualcomm.com/


Abbildung 103: Popper aktiveren

Für den Dienst pop3 (/usr/bin/popper) wird der Status auf An gewechselt. Das benötigte

Paket wird automatisch installiert.


44. Was bedeutet NFS?

45. Auf welcher Schicht des OSI-Modells ist NFS angesiedelt?

46. Auf welchem Port arbeitet NFS?

47. Was ist der Portmapper?

48. Beschreiben Sie folgenden Optionen für den NFS-Export:

ro, rw, root_squash, no_root_shuash

49. Was wird mit dem Befehl nfsstat ausgegeben?

50. Was steht in der Datei /etc/fstab?

51. Erstellen Sie die Ordner nfsexport und nfsimport. Exportieren Sie den Ordner

nfsexport und binden Sie ihn per NFS in den Ordner nfsimport ein.


52. Wie wird der DHCP-Server an eine Netzwerkkarte gebunden?

53. Erklären Sie den Unterschied zwischen statischen und dynamischen DHCP.

54. Konfigurieren Sie einen DHCP-Server:

range 192.168.100.100 bis 192.168.100.150, GW 192.168.100.254, NS!

192.168.100.254, MAC 00-09-5b-92-d8-1f auf 192.168.100.160

55. Was bedeutet DNS?

56. Was ist eine Master-Zone?

57. Was bedeutet der MX Eintrag in einer Zonendatei?

58. Warum wird in einer Zonendatei eine Seriennummer benötigt?

59. Erklären Sie die Begriffe A-Record, CNAME und MX.

60. Wozu dient der Reverse-Lookup?

61. Erstellen Sie die Zonem bpa.local. und bpa.local.rev. Überprüfen Sie die Zone mit

named-checkconf, nslookup und dig. Die Namen www, linux und tester sollen auf den

eigenen Rechner zeigen.

62. Erstellen Sie den Ordner /smbexport. Geben Sie diesen Ordner mit Samba frei.

Erstellen Sie in diesem Ordner ein Worddokument mit dem Text: Auf Windows

geschrieben unter Linux gespeichert.

63. Erstellen Sie unter Apache einen Virtual Host tester.bpa.local der auf den Ordner

/home/tester/public_html zeigt.


4 Netzwerk Monitoring

4.1 ifconfig

Ifconfig dient dazu, eine Schnittstelle für die Netzwerkschicht des Kernels sichtbar zu

machen. Das beinhaltet die Zuweisung einer IP-Adresse und verschiedener anderer

Parameter, sowie die Aktivierung (“bringing up”) der Schnittstelle, damit der Kernel die IP-

Pakete über diese Schnittstelle senden und empfangen kann.

/ # ifconfig

Ifconfig alleine gibt alle Informationen über die aktiven Schnittstellen aus. Allgemein sieht der

Syntax wie folgt aus:

/ # ifconfig interface [address [parameters]]

Das Beispiel unten weist dem Interface lo die IP-Adresse 127.0.0.2 zu.

/ # ifconfig lo 127.0.0.2

Tabelle 13: ifconfig parameter

up Diese Option aktiviert ein Interface für die IP-Schicht des Kernels. Sie wird

impliziert, wenn auf der Kommandozeile eine Adresse angegeben ist. Sie kann

auch dazu benutzt werden, ein Interface zu reaktivieren, wenn es mit der down-

Option temporär deaktiviert wurde.

Diese Option entspricht den Flags UP und RUNNING.

down

Diese Option markiert eine Schnittstelle als inaktiv, d.h. unzugänglich für die

Netzwerkschicht. Dadurch wird jeglicher IP-Transport durch die Schnittstelle

unterbunden. Beachten Sie, dass dadurch automatisch alle Routing-Einträge

gelöscht werden, die diese Schnittstelle verwenden.

Netzmaske

Maske

Diese Option weist der Schnittstelle eine Subnetzmaske zu. Sie kann entweder

als eine 32-Bit-Hexadezimalzahl (mit führender 0x) oder in Dezimaldarstellung

(Beispiel: 255.255.255.0) angegeben werden. Während diese als “dotted quad”

bezeichnete Notation häufiger benutzt wird, ist die hexadezimale Darstellung

oft einfacher zu handhaben. Netzmasken sind grundsätzlich binär und es ist


bequemer, eine Binär-zu-Hexadezimal- als eine Binär-zu-Dezimal-

Konvertierung durchzuführen.

mtu Bytes

Dies setzt die Maximum Transmission Unit (MTU), d.h. die maximale Anzahl

von Bytes, die das Interface in einer Transaktion behandeln kann. Für

Ethernets liegt der Defaultwert bei 1500.

Tabelle 14: ifconfig Flags

B Eine Broadcast-Adresse wurde gesetzt.

L Die Schnittstelle ist ein Loopback-Device.

M Alle Pakete werden empfangen.

O ARP ist an dieser Schnittstelle abgeschaltet.

P Hier handelt es sich um eine Punkt-zu-Punkt-Verbindung.

R Die Schnittstelle läuft.

U Die Schnittstelle ist aktiv.

4.2 netstat

Mit netstat überprüft man die Konfiguration und die Aktivität eines Netzes. Eigentlich ist

netstat eine ganze Sammlung von Werkzeugen, die in einem Programm zusammengepackt

sind.

Anzeigen der Routing-Tabelle

Wird netstat mit dem Flag –r aufgerufen, gibt es die Routing-Tabellen des Kernels aus.


/ # netstat –nr

Die Option –n sorgt zusätzlich dafür, dass netstat die Adressen statt als symbolische Host-

und Netzwerknamen direkt in dezimaler Notation ausgibt.

Die zweite Spalte der netstat-Ausgabe zeigt jeweils das Ziel der Route an. Die zweite Spalte

gibt den Gateway an, auf das der Routing-Eintrag zeigt. Wird kein Gateway verwendet, wird

stattdessen ein Sternchen ausgegeben. Die dritte Spalte gibt Auskunft über die

“Allgemeinheit” der Route, d.h. deren Netzmaske.

Die vierte Spalte zeigt verschiedene Flags, die die Route näher charakterisieren.

Tabelle 15: netstat Flags

G Die Route geht durch einen Gateway.

U Das zu verwendende Interface ist aktiv.

H Die Route zeigt auf einen einzelnen Host, wie das z.B. beim Loopback-

Eintrag 127.0.0.1 der Fall ist.

D Diese Route wurde dynamisch erzeugt. Dieses Flag ist gesetzt, wenn

der Tabelleneintrag von einem Routing-Dämon wie gated oder durch

eine ICMP-Redirect-Nachricht generiert wurde.

M Dieses Flag ist gesetzt, wenn der entsprechende Tabelleneintrag durch

eine ICMP-Redirect-Nachricht verändert wurde. Der Tabelleneintrag

wurde durch einen ICMP-Redirect modifiziert.

! Alle Datagramme werden verworfen.

Die nächsten drei Spalten geben Auskunft über die maximale Segmentgröße (MSS,

Maximum Segment Size), das Fenster sowie über die Anfangsumlaufzeit (irtt, initial round

trip time), die auf die über diese Route etablierten TCP-Verbindungen anzuwenden sind. Die

MSS bezeichnet den Umfang des größten IP-Pakets, das der Kernel über diese Route

verschickt. Mit dem Fenster ist die maximale Datenmenge gemeint, die von einem Remote-

Host auf einmal empfangen werden kann. Das TCP-Protokoll stellt sicher, dass die Daten


zwischen den Hosts zuverlässig übertragen werden. Falls Datenpakete unterwegs verloren

gehen, wird die Übertragung dieser fehlenden Pakete automatisch wiederholt. Das TCP-

Protokoll ermittelt am Anfang einer Übertragung, wie lange das gesendete Datenpaket zum

Remote-Host braucht, und ermittelt aus der Zeit bis zur Antwort einen Wert, der für die

weitere Datenübertragung als Maß dient, ob ein IP-Paket ggf. wiederholt werden muss.

Diese Zeit wird als round trip time bezeichnet. Der Vorgabewert wird vom TCP-Protokoll

beim erstmaligen Verbindungsaufbau benutzt. Für die meisten Netzwerktypen ist der

Standardwert akzeptabel, für einige langsame Netzwerke, besonders Amateur-Paket-Radio-

Netzwerke, ist die Zeit aber eindeutig zu kurz, so dass es hier zu unnötig häufigen

Wiederholungen kommt.

Schließlich gibt das letzte Feld die Netzwerkschnittstelle an, die die Route benutzt.

Anzeige der Interface-Statistiken

Wird netstat mit dem Flag –i aufgerufen, gibt es die Statistiken für die gerade aktiven

Netzwerkschnittstellen aus. Mit dem Flag –a werden alle im Kernel vorhandenen

Schnittstellen ausgegeben, nicht nur die konfigurierten.

/ # netstat -i

Die Spalten MTU und Met geben die aktuelle MTU und Metrik der Schnittstelle an. Die mit

RX bzw. TX überschriebenen Spalten geben an, wie viele Pakete fehlerfrei empfangen bzw.

gesendet wurden (RX-OK/TX-OK), wie viele beschädigt waren (RX-ERR/TX-ERR), wie viele

verworfen werden mussten (RX-DRP/TX-DRP) und wie viele aufgrund eines Overruns

verloren gingen (RX-OVR/TX-OVR).

Die letzte Spalte zeigt wieder die Flags an, die für die Schnittstelle gesetzt sind. Das sind

einbuchstabige Versionen der langen Flag-Namen, die ifconfig ausgibt.

Anzeigen der Verbindungen

Netstat bietet eine Reihe von Optionen zum Auflisten von Sockets. Die Argumente –t, –u, –w

und –x zeigen aktive TCP-, UDP-, RAW- und UNIX-Sockets. Wird zusätzlich –a angegeben,

werden Sockets gezeigt, die gerade auf eine Verbindung warten. Auf diese Weise wird eine

Liste aller Server, die derzeit auf Ihrem System laufen generiert.

/ # netstat -ta

Auf eingehende Verbindung wartende Server befinden sich im Zustand LISTEN. Wird netstat

nur mit der Option –a aufgerufen, zeigt es eine Liste aller Sockets.


Abbildung 104: netstat

4.3 ping

Ping ist ein Computerprogramm, mit dem überprüft werden kann, ob ein bestimmter Host in

einem IP-Netzwerk erreichbar ist. Entwickelt wurde Ping ursprünglich Ende 1983 von Mike

Muuss.

Ping (in Anlehnung an das Geräusch eines Sonars) sendet ein ICMP-Echo-Request-Paket

an die Zieladresse des zu überprüfenden Hosts. Der Empfänger muss, insofern er das

Protokoll unterstützt, laut Protokollspezifikation eine Antwort zurücksenden: ICMP Echo-

Reply. Ist der Zielrechner nicht erreichbar, antwortet der Router: Network unreachable

(Netzwerk nicht erreichbar) oder Host unreachable (Gegenstelle nicht erreichbar).

Aus einer fehlenden Antwort kann man allerdings nicht eindeutig darauf schließen, dass die

Gegenstelle nicht erreichbar ist. Manche Hosts sind nämlich so konfiguriert, dass sie ICMP-

Pakete ignorieren und verwerfen.

Übergibt man dem ping-Kommando einen Hostnamen anstatt einer IP-Adresse, lässt das

Programm diesen durch das Betriebssystem auflösen. Bei fehlerhaften Konfigurationen

(hosts-Datei, lmhosts-Datei, WINS, DNS) kann der Name nicht aufgelöst werden, worauf das

Programm eine Fehlermeldung ausgibt.


Einige Parameter sind bei Ping einstellbar. Zum Beispiel bestimmt die Wiederholrate, wie

häufig ein Paket gesendet wird. Die Paketgröße bestimmt die Größe des ICMP-Echo-

Request-Pakets.

/ # ping www.bpa-graz.at

4.4 bing

Benötigte Pakete: bing

BING ("Bandwidth pING") dient zur Messung der Bandbreite einer Punkt-zu-Punkt-

Verbindung.

bing –v host1 host2

Beispiel

bing –v 192.168.100.5 192.168.100.254

4.5 fping

Benötigte Pakete: fping

Ähnlich wie ping kann fping16 mehrere Hosts gleichzeitig pingen.

/ # fping –g 192.168.0.0/24

In diesem Beispiel werden alle Hosts im Klasse C Netzwerk 192.168.0.0 gepingt.

4.6 traceroute

Traceroute ist ein Diagnose-Werkzeug, mit dem ermittelt werden kann, über welche IP-

Router Datenpakete bis zum Ziel-Host vermittelt werden.

Traceroute sendet dazu mehrfach TCP- oder UDP-Pakete mit einer veränderten und jeweils

um 1 erhöhten Time-to-live (TTL), beginnend mit 1, an das Zielsystem, sowie aufsteigenden

Portnummern. Empfängt ein Router ein Paket mit TTL=1 und müsste es vermitteln, verwirft

er es und sendet die ICMP-Antwort Typ 11 Time-to-live exceeded und Code 0 Time to live

exceeded in transit an den Absender mit seiner Adresse zurück. Der Zielhost verschickt

dagegen die ICMP Antwort Typ 3 Destination Unreachable, Code 3 Port Unreachable. Die

Summe der so gesammelten Adressen kennzeichnet den Weg zum Ziel durch das Netz. Der

16 http://www.fping.com/


Rückweg ist in der Regel identisch, kann aber bei unsymmetrischem Routing anders

verlaufen.

Das Ergebnis von Traceroute zeigt nicht immer den tatsächlichen Weg. Es wird von

Firewalls, fehlerhaften Implementierungen des IP-Stacks, Network Address Translation, IP

Tunneln, Firewalls und anderen Faktoren beeinflusst.

Unter Unix existiert auf IPv6-fähigen Systemen neben traceroute in der Regel auch

traceroute6. Unter Windows ist Traceroute als tracert.exe, ab Windows XP auch als Pathping

implementiert.

Mit TCP-Paketen arbeiten nur spezielle Programme z.B. Tcptraceroute oder LFT (Layer4-

Traceroute). Alle diese Traceroute-Implentierungen sind jedoch auf die zurückkommenden

ICMP-Pakete angewiesen.

/ # traceroute www.bpa-graz.at

4.7 nslookup

Der nslookup Befehl kann unter Mac OS X, Windows und Unix verwendet werden, um IP-

Adressen oder Domains eines bestimmen Computers mittels DNS herauszufinden. Der

Name des Befehls bedeutet "Name Server lookup", was so viel heißt, wie "Name Server

nachschlagen" (vgl. 3.3.4 Diagnose).

/ # nslookup www.bpa-graz.at

4.8 iptraf

IPTraf17 ist ein textbasiertes Tool, das ausführliche Netzwerkstatistiken auf der Konsole

ausgibt. Es zeigt unter anderem den Status und die Statistiken zu den einzelnen Netzwerk-

Interfaces, den Verbindungen und Netzwerkunterbrechungen an. Dabei arbeitet es primär

mit IP-Protokollen. Alle anderen gefundenen Pakete zeigt es einfach mit der Kennung Non-

IP und der dazugehörigen MAC-Adresse an.

Benötigte Pakete: iptraf

17 http://cebu.mozcom.com/riker/iptraf/


/ # iptraf

Abbildung 105: iptraf Monitor

4.9 nmap

Nmap steht für Network Mapper18 und ist ein von einem Hacker, welcher unter dem

Nickname Fyodor bekannt ist, ursprünglich für das Betriebssystem Linux entwickeltes

Werkzeug zum Scannen und Auswerten von Hosts und fällt somit in die Kategorie der

Portscanner. Das textbasierte Programm unterliegt der General Public License und ist somit

Freie Software. Die Portierung für Windows-Betriebssysteme bietet bis auf wenige

Ausnahmen den vollen Funktionsumfang, ist jedoch unter Windows XP mit SP2 nur noch

begrenzt verwendbar.

In erster Linie wird Nmap für Portscanning (d.h. Untersuchen der Ports eines Hosts)

eingesetzt. Das Tool wurde ständig erweitert und konnte sich vor allem durch die aktiven

Techniken für OS-Fingerprinting (das Erkennen des eingesetzten Betriebssystems auf dem

Zielhost) einen Namen machen. Auch das Mapping von Umgebungen (Erkennen aktiver

Hosts) ist möglich.

18 http://www.insecure.org/nmap/


Nmap ist sowohl bei Angreifern als auch bei Administratoren sehr beliebt, da es sehr effizient

und zuverlässig arbeitet. Es ist ein wichtiger Bestandteil bei der Netzwerkdiagnose und

Auswertung von netzwerkfähigen Systemen.

Benötigte Pakete: nmap, nmap-gtk

Beispiele

/ # nmap -v ziel.beispiel.com

Diese Option scannt alle reservierten TCP-Ports am Zielsystem mit dem Namen

ziel.beispiel.com. Das -v aktiviert den Verbose-Modus.

/ # nmap -sS -O ziel.beispiel.com/24

Hier wird ein stealth SYN-Scan gegen jede der 255 Maschinen des Klasse C-Netzwerks von

ziel.beispiel.com gestartet. Ebenso wird versucht das Betriebssystem der aktiven

Systeme zu ermitteln. Dieser Vorgang erfordert root-Privilegien aufgrund des SYN-Scans

und der Betriebssystemerkennung.

/ # nmap -sX -p 22,53,110,143,4564 198.116.*.1-127

Es startet einen Xmas-Tree-Scan auf die erste Hälfte der 255 möglichen 8 Bit Subnetze des

Klasse B-Adressraums von 198.116. Wir überprüfen, ob am Zielsystem SSHD, DNS,

POP3D, IMAPD oder der Port 4564 aktiv ist. Wichtig ist, dass Xmas-Scans nicht gegen

Microsoft-Geräte funktionieren, da einige Abweichungen bei der Implementierung des

TCP-Stacks gemacht wurden. Das gleiche gilt für Cisco-, IRIX-, HP/UX- und BSDI-

Maschinen.

Tabelle 16: nmap Scan-Typen

-sS TCP SYN-Scan: Diese Technik wird oft als "halb offen" ("half-open")

bezeichnet, da keine volle TCP-Verbindung zustande kommt. Der Scanner

schickt ein TCP-Datagramm mit gesetzter SYN- Flagge an das Zielsystem,

so wie dies im Rahmen des Drei-Wege- Handschlags von TCP

normalerweise auch der Fall ist. Nun wird auf eine positive Rückmeldung

des Zielsystems gewartet. Kommt ein Paket mit gesetzter SYN/ACK-

Flagge zurück, so wird der Zielport als im Status LISTENING (dt.

abhörend) identifiziert. Im Gegenzug deutet ein RST-Datangramm auf

einen geschlossenen Port (engl. closed) hin. Wird ein SYN/ACK-

Datagramm entgegengenommen, schickt nmap (bzw. der Betriebssystem-


Kernel) automatisch ein RST zurück, um den Verbindungsaufbau

abzubrechen. Der primäre Vorteil dieser Vorgehensweise ist, dass viele

Systeme solcherlei Zugriffe nicht protokollieren.

-sT TCP connect()-Scan: Dies ist die klassische Form des TCP-

Portscannings. Der connect()-System-Call, der das Betriebssystem zur

Verfügung stellt, wird immer dann genutzt, wenn eine Verbindung zum

Port eines Zielsystems hergestellt werden soll. Befindet sich der Zielport

im Status LISTENING, so wird der connect()-Zugriff erfolgreich ausfallen.

-sF -sX -sN Stealth FIN-, Xmas-Tree- oder Null-Scan-Modis: Es gibt Momente, wo

SYN-Scans nicht heimlich genug ausfallen. Einige Firewall-Systeme (z.B.

Packet-Filter) sind in der Lage verdächtige SYN- Aktivitäten zu erkennen.

Ebenso können Programme wie Synlogger oder Courtney die SYN-

Portscans als solche ausweisen. Diese erweiterten Scan-Techniken

Können somit in manchen Fällen ungehindert die gewünschten Resultate

liefern. Die Idee ist, dass geschlossene Ports auf solcherlei Zugriffe mit

einem RST-Datagramm antworten müssten, während ansprech- bare

Ports die Anfragen ignorieren sollten (siehe RFC 793, S. 64). Der FIN-

Scan nutzt ein TCP-Datagramm mit gesetzter FIN- Flagge, während der

Xmas-Tree-Scan die TCP-Flaggen FIN, URG und PSH aktiviert. Der Null-

Scan schaltet alle optionalen Flags ab. Leider ignoriert einmal mehr

Microsoft die gängigen Standards und reagiert auf die exotischen Scan-

Techniken ganz unerwartet. Dies bedeutet, dass diese Scanning-

Methoden nicht bei Windows 9x, ME, NT, 2000 und XP funktionieren. Auf

der anderen Seite ist dies natürlich hervorragend, wenn es um das

Identifizieren der TCP/IP-Implementierung von Microsoft geht: Findet einer

dieser Scans einen offenen Port, so kann davon ausgegangen werden,

dass es sich beim Zielsystem nicht um ein Windows. Im Gegenzug deuten

unrealistisch viele offene Ports auf eine Windows-Maschine hin.

-sP Ping-Scanning: Manchmal ist lediglich gefragt, welche Hosts in einem

Netzwerk aktiv sind. nmap kann diese Frage beantworten, indem eine

ICMP echo request Anfrage an jede IP-Adresse im spezifizierten Netzwerk

geschickt wird. Hosts, die mit einer ICMP echo reply antworten, können als


aktiv ausgewiesen werden.

-sU UDP-Scans: Diese Methode wird stets dann herangezogen, wenn es um

das Identifizieren der offenen UDP-Ports (siehe RFC 768) eines Systems

geht. Diese Technik basiert darauf, dass ein UDP- Datagramm mit 0 Byte

an Nutzdaten an jeden Port des Zielsystems geschickt wird. Erhalten wir

eine ICMP port unreachable- Nachricht, so ist der Zielport geschlossen.

Andererseits handelt es sich um einen offenen Port.

-sI <Zombie-

Host[:Zielport]>

Idlescan: Diese erweiterte Scan-Technik ermöglicht ein blindes Scannen

der TCP-Port eines Ziels (dies bedeutet, dass keinerlei Pakete mit der

richtigen IP-Absenderadresse verschickt werden). Stattdessen wird eine

einzigartige Attacke angewandt, die die Berechenbarkeit der IP

Fragmentation ID eines Zombie-Hosts ausnutzt.

nmap greift zudem auf eine sehr mächtige Notation zurück, die eine sehr komfortable

Spezifikation von IP-Adressbereichen zulässt. So kann das Klasse B-Netzwerk 192.168.*.*

mit der Angabe von ’192.168.*.*’ oder ’192.168.0-255.0-255’ oder ’192.168.1-50,51-

255.1,2,3,4,5-255’ gescannt werden. Und selbstverständlich ist auch die verbreitete Netz-

masken-Notation zulässig: ’192.168.0.0/16’. All diese Eingaben führen zum gleichen Ziel.

Tabelle 17: nmap generelle Optionen

-O Diese Option aktiviert das Identifizieren des am Zielsystem eingesetzten

Betriebssystems anhand des TCP/IP-Fingerabdrucks (TCP/IP

fingerprint). Es wird eine Anzahl spezifischer Tests umgesetzt, die das

typische Verhalten der jeweiligen TCP/IP-Implementierungen erkennen

können sollen. Die gegebenen Informationen stellen quasi einen

’Fingerabdruck’ dar, der mit der Datenbank der bekannten

Betriebssystem-Fingerabdrucke (die nmap-os-fingerprints Datei)

verglichen wird.

-v Verbose-Modus: Diese Option ermöglicht eine erweiterte Ausgabe von

Informationen. Eine doppelte Nutzung ergibt einen doppelt so großen

Effekt. Ebenso kann -d einige Male aktiviert werden, falls Sie wirklich vor


einem überlasteten Bildschirm verrückt werden wollen!

-h Diese handliche Funktion zeigt eine Kurzreferenz der nmap Parameter.

-p <Port-

Bereich>

Diese Option spezifiziert, welche Ports gescannt werden sollen. Zum

Beispiel wird ’-p 23’ lediglich einen Zugriff auf den Port 23 (Telnet) der

Zielsysteme durchführen. ’-p 20-30,139,60000-’ scannt die Ports

zwischen 20 und 30, Port 139 und alle Ports größer als 60000.

Standardmässig werden sämtliche well-known Ports zwischen 1 und

1024 sowie alle in der services-Datei von nmap gelisteten Dienste

gescannt. Für einen IP-Protokoll-Scan (-sO) kann mit dieser Option die

zu scannende Protokoll-Nummer (0-255) angegeben werden. Werden

gleichzeitig TCP- und UDP-Ports gescannt, so kann das jeweilige

Protokoll durch ein vorangestelltes "T:" oder "U:" angewählt werden. Die

mitgegebenen Ports gelten so lange für das spezifizierte

Übertragungsprotokoll, bis ein anderes angegeben wird. Zum Beispiel

werden mit dem Argument "-p U:53,111,137,T:21-25,80,139,8080" die

UDP-Ports 53, 111 und 137 sowie die TCP-Ports 21 bis 25, 80, 139 und

8080 gescannt. Wichtig ist, dass bei einem gleichzeitigen TCP- und

UDP-Scan neben der Angabe von -sU mindestens eine TCP-Scan-

Variante mit angegeben werden muss (zum Beispiel -sS, -sF oder -sT).

--

randomize_hosts

(dt. zufällige

Reihenfolge der

Hosts)

Sagt nmap, dass bei einer Gruppe von bis zu 2048 Zielen eine zufällige

Reihenfolge gewählt werden soll, bevor sie gescannt werden.

Nmap Front End

Mit Nmapfe steht für Nmap ein Front End zur Verfügung.

/ # nmapfe


Abbildung 106: Nmap Front End

4.10 tcpdump

Tcpdump schreibt live alle Protokoll-Header und gibt sie auf dem Bildschirm aus. Es wird der

komplette Netzverkehr zwischen dem Linux-Rechner und dem Netzwerk überwacht.

Benötigte Pakete: tcpdump

/ # tcpdump

Mit der Option port wird tcpdump auf ein bestimmtes Port gebunden.

/ # tcpdump port 80

Alternativ kann auch nur eine bestimmter Rechner überwacht werden.

/ # tcpdump host 192.168.0.1

4.11 ethereal

Ethereal ist eine Software zur Analyse von Netzwerkprotokollen. Sie wurde von einem Team

um Gerald Combs unter der General Public License als Open-Source-Software entwickelt.

Benötigte Pakete: ethereal

Das Werkzeug stellt nach dem Protokollieren des Datenverkehrs einer Netzwerkschnittstelle

(zum Beispiel Ethernet-Netzwerkkarte) die Daten in Form einzelner Pakete dar. Dabei

werden die hexadezimal codierten Daten übersichtlich und für den Menschen

nachvollziehbar analysiert. So können zum Beispiel HTTP-Statuscodes oder ähnliches

analysiert werden.


Gestartet wird Ethereal direkt von der Konsole unter KDE oder Gnome.

/ # ethereal

Beispiel einer http-Protokollierung

Mit dem Button Filter wird der HTTP Filter aktiviert.

Abbildung 107: Ethereal Filter


Abbildung 108: Ethereal interface

Abbildung 109: Ethereal capture


Abbildung 110: Passwort in unverschlüsselter HTTP Verbindung

4.12 ntop

Ntop hilft den Datenverkehr im eigenen Netzwerk zu überwachen und detailliert

auszuwerten.

• Welcher Arbeitsplatz verursacht wie viel Netzverkehr?

• Wie viel Prozent sind durch E-Mails verursacht?

• Auf welchen Arbeitsplätzen läuft Software wie Morpheus oder Audiogalaxy?

Ntop findet Antworten auf solche Fragen. Das mächtige Werkzeug überwacht das Netzwerk

und wertet die Daten grafisch aus, und zwar aufgeschlüsselt nach vielen Kriterien.

Ursprünglich von Luca Deri geschrieben. Nun entwickeln mehrere Programmierer Ntop.

Benötigte Pakete: ntop

Vor dem Start von ntop, muss das root-Passwort gesetzt werde.

/ # ntop –A –u wwwrun

Gestartet wird ntop in Yast, oder direkt von der Shell.


/ # /etc/init.d/ntop start

Nun kann unter http://127.0.0.1:3000 der Netzverkehr beobachtet werden.

Abbildung 111: ntop

Ntop bietet eine Fülle von Statistiken und Auswertungen des Datenverkehrs. Es analysiert

nicht nur den Anteil, den der eigene Host verursacht, sondern den gesamten Verkehr, der an

seinem Netzsegment sichtbar ist. Über Netflow- und sFlow-Streams wertet Ntop sogar

Datenströme in entfernten Segmenten aus.

Hinweis: Das rpm–Paket von Opensuse 10 Beta3 war nicht funktionsfähig. Das Paket von

Suse 9.3 funktioniert problemlos.

4.13 Nessus

Nessus ist ein bekannter freier Netzwerk-Scanner für Linux- und Unixsysteme, der der GPL

unterliegt. Nessus basiert auf dem Client-Server-Prinzip. Das heißt, dass auf einem Rechner

der Nessusserver (nessusd) gestartet wird und man sich anschließend mit dem Client

entweder vom lokalen oder einem entfernten Computer aus verbinden kann. Abgesichert

wird dies durch SSL-Zertifikate und Passwörter.

Mit dem Start des Servers werden automatisch die Plugins geladen. Mit diesen Plugins

lassen sich diverse Sicherheitslücken des Betriebssystems bzw. der Dienste, die auf dem zu


scannenden Host laufen, finden. Die Plugins werden in der Nessus eigenen Skriptsprache

Nessus Attack Scripting Language erstellt.

Mit Hilfe des Clients verbindet man sich darauf mit dem Server und stellt eine Session ein, in

welcher man die Plugins, den Zielhost und andere Einstellungen eintragen oder verändern

kann. Wurde der Scan auf einen Host ausgeführt, gibt der Nessus-Client eine Übersicht über

die offenen Ports (das Scannen der Ports macht nessus mit nmap) und andere

Sicherheitslücken aus.

Benötigte Pakete: libnasl, nessus-core, nessus-libraries, openssl-devel

Nach der Installation wird der erste User angelegt.

/ # nessus-adduser

Zusätzlich benötigt Nessus ein Zertifikat.

/ # nessus-mkcert

Abbildung 112: nessus-mkcert

Da Nessus ein Client – Server – System ist, muss zuerst der Server nessud gestartet

werden.

/ # nessusd

Anschließend wird der Nessus-Client gestartet.

/ # nessus

Nach dem einloggen, muss das Zertifikat bestätigt werden.


Abbildung 113: Bestätigung des Zertifikates

Überprüfen eines Windows Rechners im lokalen Netzwerk mit Nessus

Für eine Überprüfung eines Windows – Rechners, werden in den Plugins nur Windows und

Windows : Microsoft Bulletins benötigt.

Abbildung 114: Windows Plugins Enable

In den Targets werden die Scan-Ziele eingetragen. Durch klick auf Start the scan beginnt

Nessus seine Arbeit.


Abbildung 115: Target

Abbildung 116: Nessus Scan

Nach dem Abschluss, zeigt Nessus einen detaillierten Report.


Abbildung 117: Nessus Report


64. Wozu dient ifconfig?

65. Deaktivieren Sie die Schnittstelle lo.

66. Erstellen Sie eine Schnittstelle lo:2 mit der Adresse 127.0.0.2.

67. Geben Sie mit netstat die Routing einträge aus.

68. Zeigen Sie alle wartenden Server.

69. Pingen Sie www.bpa-graz.at. Erklären Sie das Ergebnis.

70. Messen Sie die Bandbreite der Verbindung zwischen localhost und

www.informatikserver.at.

71. Wie viele aktive Hosts befinden sich in Ihrem Netzwerk?

72. Wie funktioniert traceroute?

73. Starten Sie Firefox und öffnen Sie Google. Welcher lokale Port spricht Google an.


74. Welches Betriebssystem wir am Server www.informatikserver.at verwendet?

75. Geben Sie den Netzwerkverkehrt Ihres Rechners am Bildschirm aus.

76. Protokollieren Sie mit Ethereal eine HTTP-Verbindung.

77. Führen Sie einen Scan eines Windows-Rechners mit Nessus durch.


5 Server Security

Sicherheit ist bei Webservern immer ein Problem. Linux bietet einige Möglichkeiten das

System zu schützen.

5.1 SuSE Sicherheitseinstellugen

Wird der Linux Rechner als Server in einem Netzwerk betrieben, empfiehlt es sich die

Sicherheitseinstellung zu erhöhen. Diese Einstellung kann direkt in YaSt durchgeführt

werden.

Abbildung 118: Yast-Modul Einstellungen zur Sicherheit

Abbildung 119: Sicherheitseinstellungen


Die Sicherheitseinstellungen werden auf dem Netzwerkserver geändert. Über Details

können:

• Passworteinstellungen

• Reaktion auf �+�+�

• Herunterfahren

• Anmeldeverzögerung

• Userbeschränkung

• Dateiberechtigung

verändert werden.

5.2 SuSE Firewall

Die SuSE Firewall kann direkt über YaST konfiguriert werden. Die Konfiguration startet über

Sicherheit und Benutzer und Firewall.

Abbildung 120: Yast-Modul Firewall

Der erste Schritt der Konfiguration ist der Start der Firewall. Zusätzlich wird die Firewall beim

Systemstart aktiviert.


Abbildung 121: Firewall Start

Abbildung 122: Definition der Schnittstellen

Es stehen drei Schnittstellen zur Verfügung:

• Externe Zone

• Interne Zone

• DMZ

Da nur zwei Schnittstellen definiert sind, wird eth0 der externen Zone und eth1 der internen

Zone zugeordnet.


Abbildung 123: Firewall - erlaubte Dienste

Für die externe Zone werden DNS-Server, HTTP-Server und Mailserver erlaubt.

Abbildung 124: Masquerading

Durch das aktivierte Masquerading kann das Subnet der Schnittstelle eth1 auf das externe

Netz an Schnittstelle eth0 zugreifen. Broadcast und IPsec-Unterstützung werden für eine

Grundkonfiguration nicht benötigt.


Abbildung 125: Protokollierung

In den Protokollierungsoptionen wird angegeben, was in das Logfile /var/log/messages

eingetragen werden soll. Es empfiehlt sich nicht akzeptierte Pakete zu protokollieren.

5.3 Webmin

Webmin ist das ideale Tool für die Fernwartung. Wird das unsichere HTTP Protokoll

verwendet. Soll das HTTPS19 Protokoll verwendet werden, muss Webmin entsprechend

eingerichtet werden. Zusätzlich wird das Paket perl-Net_SSLeay benötigt.

Abbildung 126: pearl-Net_SSLeary

19 HTTPS steht für hypertext transfer protocol secure und ist ein Netzwerkprotokoll, das eine gesicherte HTTP-Verbindung zwischen Rechnern ermöglicht.


In Webmin erfolgen die notwenigen Schritte unter Webmin Coniguration und SSL Encryption.

SSL muss aktiviert werden. Mit Create Now werden diese Einstellungen abgeschlossen.

Abbildung 127: Webmin SSL Encryption

Mit Certificate Authority kann ein eigenes Zertifikat für Webmin erstellt werden.

5.4 Apache mit mod_ssl

Auch die Administrations-Zugänge für Webseiten sollte über HTTPS gesichert werden. Der

erste Schritt dafür ist die Erstellung des Zertifikates.

/etc/apache2 # openssl req –new –x509 –nodes –days 365 –out � ssl.crt/server.crt –keyout ssl.key/server.key

Die Informationen für das Land, die Organisation usw. müssen eingetragen werden.

Abschließend muss der Webserver neu gestartet werden.

/etc/apache2 # rcapache2 stop /etc/apache2 # rcapache2 startssl


Abbildung 128: APACHE_SERVER_FLAG=“SSL“

Soll Apache2 automatisch mit SSL gestartet werden, muss mit YaST das File /etc/sysconfig

verändert werden. Der Wert Network/WWW/Apache2/APACHE_SERVER_FLAGS muss

auf SSL gesetzt werden. Mambo und Moodle können somit auch über die gesicherte https

Verbindung aufgerufen werden.


1. Konfigurieren Sie einen Linux Router für folgendes Netzwerk-Szenario:

eth0: DHCP-Client

eth1: 192.168.2.254/24

Das LAN muss auf das Internet zugreifen können. Extern darf nur auf Port 80 aktiv

sein. Intern sollen per DHCP 50 Adressen vergeben werden.


6 Stichwortverzeichnis

Apache 91, 128, 137, 138 apache2 61, 128 A-Records 77 ARP 18, 19, 20, 35, 102 bind 72, 83 bing 106 BOOTP 34 Broadcast 29, 30, 31, 102, 126 CIDR 33, 34 CNAME-Records 77 Datagrammen 11, 20 DHCP 34, 51, 57, 58, 59, 68, 69, 70, 71,

72, 138 dig 38, 81, 83 DNS 7, 35, 36, 37, 38, 60, 72, 73, 74, 75,

78, 81, 83, 105, 107, 109, 126 DynDNS 38 Echo Reply 21 ethereal 113, 114 Flags 15, 16, 101, 102, 103, 104, 110 Forwarder 74 fping 106 Fragment Offset 16 FTP 7, 57, 61 GNOME 59 Header Checksum 17 host 38, 51, 71, 72, 83, 113 Host-Range 32 http 17, 26, 33, 41, 52, 58, 59, 90, 98,

106, 107, 108, 114, 117, 137, 138 https 127, 129 ICMP 7, 16, 20, 21, 103, 105, 106, 107,

110, 111 Identification 16 ifconfig 101, 102, 104 in-addr 78, 79 Installations-Quelle 54 IP 4, 6, 7, 8, 9, 10, 11, 14, 15, 16, 17, 18,

20, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 38, 39, 58, 61, 63, 68, 71, 72, 77, 78, 79, 82, 101, 103, 105, 106, 107, 110, 111, 112, 137

IPTraf 107 KDE 59, 114 Length 15, 29 Linuxrc 55, 56, 57, 58, 59 Mambo 129 Master 75, 80, 81 Masterzone 75 mod_ssl 128 Moodle 128, 129 MSS 103 MX 76, 77

named-checkzone 81 Nessus 117, 118, 119, 120, 121, 138 netstat 102, 103, 104, 105 Netzmaske 28, 29, 30, 31, 34, 58, 101,

103 nfs 61, 67 Nmap 108, 109, 112, 113, 138 NS 75 nslookup 81, 83, 107 ntop 116, 117 OpenSuSE 58 OSI 4, 5, 6, 7, 9, 29, 38, 39, 61 perl-Net_SSLeay 127 ping 58, 105, 106 pop3 99 popper 98, 99 Portmapper 62 Protocol 7, 10, 16, 18, 19, 20, 22, 26, 29,

34, 39, 68, 138 PTR 79 RARP 19, 20, 34, 39 Resolver 36, 37, 38 Reverse-Lookup 78, 79 Root 59, 79 Routing 6, 7, 17, 29, 33, 101, 102, 103,

107 Share 86, 87 Slave 80 SMB 61, 84 SOA 36, 76, 77 SSL 128, 129 Subnet 29, 63, 126 Subnetze 28, 29, 31, 32, 109 SuSE 124 SuSE XE "SuSE" Firewall 124 TCP 4, 5, 6, 7, 8, 9, 10, 14, 20, 22, 23, 24,

25, 26, 27, 38, 39, 61, 67, 103, 104, 106, 107, 109, 110, 111, 112, 137

Tcpdump 113 Time Stamp 18 Time to Live 16 Torvald, Linus 3 Total Length 15 traceroute 106, 107 TTL 20, 21, 37, 76, 80, 106 Type of Servive 15 UDP 5, 7, 10, 20, 25, 26, 27, 39, 61, 67,

104, 106, 111, 112 Unreachable 21, 106 VMware 3 Webmin 127, 128 xinietd 88, 89 YaST 124, 129


7 Abbildungsverzeichnis

Abbildung 1: OSI-Referenzmodell............................................................................................4 Abbildung 2: Vergleich des OSI-Referenzmodells mit dem TCP/IP-Referenzmodell ..............7 Abbildung 3: Die TCP/IP-Protokoll-Architektur.........................................................................8 Abbildung 4: OSI-Referenzmodell, TCP/IP-Referenzmodell, Hybrides Referenzmodell .........9 Abbildung 5: Dateneinkapselung..............................................................................................9 Abbildung 6: Datenbezeichnung des TCP/IP-Modells ...........................................................10 Abbildung 7: IP Kommunikation .............................................................................................10 Abbildung 8: Datagrammkopf.................................................................................................11 Abbildung 9: Datagramm........................................................................................................12 Abbildung 10: Datagramme fragmentieren ............................................................................13 Abbildung 11: Datagramm wird reassembliert .......................................................................13 Abbildung 12: Der IP-Header .................................................................................................14 Abbildung 13: Type of Service ...............................................................................................15 Abbildung 14: ARP.................................................................................................................18 Abbildung 15: RARP ..............................................................................................................20 Abbildung 16: ICMP Paket .....................................................................................................21 Abbildung 17: TCP-Segment..................................................................................................23 Abbildung 18: TCP-Head .......................................................................................................24 Abbildung 19: Dreiwege-Handshake (hier Verbindungsaufbau) ...........................................25 Abbildung 20: UDP Datagramm .............................................................................................27 Abbildung 21: UDP-Kopf ........................................................................................................27 Abbildung 22: DHCP ..............................................................................................................34 Abbildung 23: VMware Konfiguration für Opensuse10beta2 .................................................42 Abbildung 24: NIC2 Host-only ................................................................................................43 Abbildung 25: VMware boot.iso einbinden .............................................................................43 Abbildung 26: Vmware ...........................................................................................................44 Abbildung 27: Virtual PC-Konsole ..........................................................................................45 Abbildung 28: Virtuellen Computer erstellen ..........................................................................45 Abbildung 29: Ordner des virtuellen Computers ....................................................................46 Abbildung 30: Name und Pfad des virtuellen Computers.......................................................46 Abbildung 31: Virtual PC Betriebsystem ................................................................................47 Abbildung 32: Speicher ..........................................................................................................47 Abbildung 33: Neue virtuelle Festplatte..................................................................................48 Abbildung 34: Speicherort der virtuellen Festplatte................................................................48 Abbildung 35: Abschluss der Konfiguration............................................................................49 Abbildung 36: Netzwerkadapter 2 ..........................................................................................49 Abbildung 37: Start Virtual PC................................................................................................50 Abbildung 38: boot.iso wählen ...............................................................................................50 Abbildung 39: QEMU Manager ..............................................................................................52 Abbildung 40: Opensuse 10 unter QEMU ..............................................................................53 Abbildung 41: Netzwerk-Installation .......................................................................................54 Abbildung 42: Keine Installationsquelle..................................................................................54 Abbildung 43: Linuxrc.............................................................................................................55 Abbildung 44: Linuxrc Hauptmenü .........................................................................................55 Abbildung 45: Linuxrc - Installation ........................................................................................56 Abbildung 46: Linuxrc Quellmedium.......................................................................................56 Abbildung 47: Linuxrc – Netzwerkprotokoll ............................................................................57 Abbildung 48: Linuxrc - DHCP aktivieren ...............................................................................57 Abbildung 49: Linuxrc - HTTP Server.....................................................................................58 Abbildung 50: Linuxrc – HTTP-Proxy .....................................................................................58 Abbildung 51: Linuxrc – Verzeichnis ......................................................................................59 Abbildung 52: NFS im OSI-Schichtenmodell..........................................................................61


Abbildung 53: Yast - Modul NFS-Server ................................................................................62 Abbildung 54: NFS-Server starten .........................................................................................62 Abbildung 55: Zu exportierendes Verzeichnis wählen ...........................................................63 Abbildung 56: Rechner und Zugriffsoptionen für NFS............................................................63 Abbildung 57: Yast - Modul NFS-Client..................................................................................64 Abbildung 58: Konfiguration des NFS-Client..........................................................................65 Abbildung 59: NFS-Verzeichnis einbinden.............................................................................65 Abbildung 60: Yast - Modul DHCP-Server .............................................................................68 Abbildung 61: DHCP auf Netzwerkkarte eht1 binden ............................................................69 Abbildung 62: DHCP Konfiguration ........................................................................................69 Abbildung 63: Dynamisches DHCP........................................................................................70 Abbildung 64: /etc/dhcpd.conf ................................................................................................70 Abbildung 65: Netzwerkkarte für DNS vorbereiten.................................................................73 Abbildung 66: DNS-Server .....................................................................................................73 Abbildung 67: DNS-Server starten .........................................................................................74 Abbildung 68: DNS-Forwarder ...............................................................................................74 Abbildung 69: DNS-Protokollierung........................................................................................74 Abbildung 70: DNS-Master-Zone ...........................................................................................75 Abbildung 71: DNS Zonen-Transport .....................................................................................75 Abbildung 72: NS (Nameserver) der Zone schule.local .........................................................75 Abbildung 73: MX (Mailserver) der Zone schule.local............................................................76 Abbildung 74: SOA (Start of Authority)...................................................................................76 Abbildung 75: A, CNAME-Records (canonical names) ..........................................................77 Abbildung 76: /var/lib/named/master/schule.local ..................................................................78 Abbildung 77: /var/lib/named/master/0.168.192.in-addr.arpa ................................................79 Abbildung 78: /etc/named.conf...............................................................................................80 Abbildung 79: nslookup ..........................................................................................................82 Abbildung 80: dgi Domain Information Groper .......................................................................83 Abbildung 81: Yast - Modul Samba-Server ............................................................................85 Abbildung 82: Samba Arbeitsgruppe......................................................................................85 Abbildung 83: Samba-Servertyp ............................................................................................85 Abbildung 84: Samba Start ....................................................................................................86 Abbildung 85: Shares .............................................................................................................86 Abbildung 86: Neues Share freigeben ...................................................................................87 Abbildung 87: Samba root Passwort ......................................................................................87 Abbildung 88: Freigegebner Ordner.......................................................................................88 Abbildung 89: xinetd...............................................................................................................89 Abbildung 90: xinietd swat......................................................................................................89 Abbildung 91: Swat ................................................................................................................90 Abbildung 92: Yast - Modul HTTP-Server ..............................................................................92 Abbildung 93: Apache2 Netzwerkgeräte ................................................................................92 Abbildung 94: Apache2 Module .............................................................................................92 Abbildung 95: Apache2 Standard Host ..................................................................................93 Abbildung 96: Apache2 Virtual Hosts.....................................................................................94 Abbildung 97: Apache2 starten ..............................................................................................94 Abbildung 98: Yast - Modul Mail Transfer Agent....................................................................96 Abbildung 99: Postfix Verbindungsart ....................................................................................96 Abbildung 100: Postfix Ausgehender Mailserver....................................................................97 Abbildung 101: Postfix Eingehende Mails ..............................................................................97 Abbildung 102: YaST - Modul Netzwerkdienste (popper) ......................................................98 Abbildung 103: Popper aktiveren ...........................................................................................99 Abbildung 104: netstat..........................................................................................................105 Abbildung 105: iptraf Monitor ...............................................................................................108 Abbildung 106: Nmap Front End .........................................................................................113 Abbildung 107: Ethereal Filter ..............................................................................................114


Abbildung 108: Ethereal interface ........................................................................................115 Abbildung 109: Ethereal capture ..........................................................................................115 Abbildung 110: Passwort in unverschlüsselter HTTP Verbindung .......................................116 Abbildung 111: ntop .............................................................................................................117 Abbildung 112: nessus-mkcert .............................................................................................118 Abbildung 113: Bestätigung des Zertifikates ........................................................................119 Abbildung 114: Windows Plugins Enable.............................................................................119 Abbildung 115: Target ..........................................................................................................120 Abbildung 116: Nessus Scan ...............................................................................................120 Abbildung 117: Nessus Report.............................................................................................121 Abbildung 118: Yast-Modul Einstellungen zur Sicherheit.....................................................123 Abbildung 119: Sicherheitseinstellungen .............................................................................123 Abbildung 120: Yast-Modul Firewall.....................................................................................124 Abbildung 121: Firewall Start ...............................................................................................125 Abbildung 122: Definition der Schnittstellen.........................................................................125 Abbildung 123: Firewall - erlaubte Dienste...........................................................................126 Abbildung 124: Masquerading..............................................................................................126 Abbildung 125: Protokollierung ............................................................................................127 Abbildung 126: pearl-Net_SSLeary......................................................................................127 Abbildung 127: Webmin SSL Encryption .............................................................................128 Abbildung 128: APACHE_SERVER_FLAG=“SSL“ ..............................................................129


8 Tabellenverzeichnis

Tabelle 1: ICMP Typ - Code-Kombinationen..........................................................................21 Tabelle 2: Ports ......................................................................................................................26 Tabelle 3: Netzklassen ...........................................................................................................28 Tabelle 4: Private IP-Adressen...............................................................................................28 Tabelle 5: Optionen für den NFS-Export ................................................................................63 Tabelle 6: Mount-Parameter für über NFS-Verzeichnisse .....................................................65 Tabelle 7: nfsstat Optionen ....................................................................................................67 Tabelle 8: NFS Konfigurations-Datein....................................................................................67 Tabelle 9: DHCP Konfigurations-Datein.................................................................................72 Tabelle 10: DNS Konfigurationsdatein ...................................................................................83 Tabelle 11: Samba Konfigurations-Datein..............................................................................90 Tabelle 12: NFS Konfigurations-Datein..................................................................................95 Tabelle 13: ifconfig parameter..............................................................................................101 Tabelle 14: ifconfig Flags .....................................................................................................102 Tabelle 15: netstat Flags ......................................................................................................103 Tabelle 16: nmap Scan-Typen .............................................................................................109 Tabelle 17: nmap generelle Optionen ..................................................................................111


9 Literaturverzeichnis

Aulds, C. (2002), Linux Apache Web Server Administrator, Sybex Verlag

Barth, W. (2004), Das Firewall Buch (3. Auflage), Erlangen, Millin Verlag

David Wood , D., Schumacher (1997), K. Linux Samba HOWTO,

http://www.linuxhaven.de/dlhp/HOWTO/DE-Samba-HOWTO.html (26-08-2005)

Dokumentation zum Apache HTTP Server Version 2.0, http://httpd.apache.org/docs/2.0/

(24-08-2005)

Ermer, T., Meyer, M.(2004) Die Linuxfibel, http://www.linuxfibel.de/ (24-08-2005)

Frank, F., E-Mail: [email protected], Degenhardt H. , E-Mail: [email protected] ,

http://www.selflinux.org/ (25-01-2005)

Goller, H. (2002), Das LAMP Buch, Erlangen, Millin Verlag

Holtkamp, H. (2001) Einführung in TCP/IP, http://www.rvs.uni-

bielefeld.de/~heiko/tcpip/tcpip_html_alt/tcpip.html (25-08-2005)

Jarz, T. (2002), Grundlagen der Netzwerktechnik, Graz, Verein ESA BPA

Jarz, T. (2004), Windows Server 2003, Graz, Verein ESA BPA

Jöcker, P. (2001), Computernetzwerke, Berlin, VDE Verlag

Kirch, O., Dawson, T. (2001) Linux - Wegweiser für Netzwerker,

http://www.oreilly.de/german/freebooks/linag2/inhalt.htm (29-08-2005)

Kowalk, W. Rechnernetze, http://einstein.informatik.uni-

oldenburg.de/rechnernetze/Default.htm (23-08-2005)


Nmap network security scanner man page (German translation),

http://www.insecure.org/nmap/data/nmap_manpage-de.html (28-08-2005)

Rüttger, M. (2002), MySQL für Dummies, Bonn, mitp-Verlag

Sarnow, K. (2004), Linux in der Schule (2. Auflage), Erlangen, Millin Verlag

Schmid, E., Cartus, C., Blume, R. (1999), PHP, München, Markt&Technik

Stoll, R., Leierer, G. (2000), PHP4 + MySQL, Düsseldorf, Data Becker

Wikipedia, Apache http-Server, http://de.wikipedia.org/wiki/Apache_(Software) (26-08-2005)

Wikipedia, Dynamic Host Configuration Protocol, http://de.wikipedia.org/wiki/DHCP (24-08-

2005)

Wikipedia, Nessus, http://de.wikipedia.org/wiki/Nessus_(Software) (01-09-2005)

Wikipedia, Network File System, http://de.wikipedia.org/wiki/Network_File_System (24-08-

2005)

Zawodny, j., Balling, D. (2001), MySQL High Performance, O’Reilly

Documents

Linux advanced