Technische Grundlagen des Internets
Jedes Netzwerk braucht Gemeinsamkeiten. Die (einzige!) Gemeinsamkeit im Internet ist die Art der Datenübertragung, das so genannte Protokoll. Im Internet wird das so genannte TCP/IP (Transfer Control Protocol/Internet Protocol) verwendet.
Jeder Rechner auf der ganzen Welt braucht eine eindeutige Adresse, um im Internet erkannt zu werden, die so genannte IP-Adresse. (Diese Adresse wird vom Internet Protocol IP genutzt). In der derzeit gültigen Version 4 des Internet Protokolls ist die IP-Adresse eine 32-stellige Binärzahl, also etwa:
11011001.01010011.11001111.00010001
Meist fasst man 8 Binärstellen (bits) zu einem Byte zusammen, dessen Wert man berechnet. Die "Kurzschreibweise" der oben angeführten IP-Adresse würde daher zum Beispiel lauten:
217.83.207.17
Diese Adressen werden von der Internet Number Association (IANE) vergeben.
Man hat also mit einer solchen 32 bit-Adresse insgesamt 232 = 4 294 967 296 Möglichkeiten (also mehr als 4 Milliarden), einen PC unverwechselbar zu adressieren. Man sollte meinen, dass diese große Anzahl für alle PCs der Welt ausreicht. Leider ist das nicht so!
Diese Adressen sind nämlich in zwei Teile geteilt:
Der erste Teil ist die Netzwerk-Adresse. Da das Internet aus vielen miteinander verbundenen lokalen Netzen (LAN) besteht, ist es sinnvoll, jedem LAN eine eindeutige Adresse zuzuweisen.
Der zweite Teil gibt die Adresse der einzelnen Rechner im Netz an (Host-Adresse). Dieser Teil wird durch das lokale Netzwerkmanagement frei vergeben.
Man hat nun verschiedene Größenklassen von Netzwerken festgelegt:
Class-A-Netze: Adresse beginnt mit einer binären 0, 7 bit für Netzwerk-Adresse, 24 bit für Host-Adresse. Damit gibt es weltweit 127 derartige Netzwerke, ein Class-A-Netz kann bis zu 16 Mio. Teilnehmer haben. Alle derartigen Netzadressen sind bereits belegt.
IP-Adressen von Class-A-Netzen:
0.0.0.0 bis 127.255.255.255
Class-B-Netze: Adresse beginnt mit der binären Ziffernkombination 10, 14 bit für Netzwerk-Adresse, 16 bit für Host-Adresse. Damit gibt es weltweit 16384 derartige Netzwerke, ein Class-B-Netz kann bis zu 65536 Teilnehmer haben. Alle derartigen Netzadressen sind bereits belegt.
IP-Adressen von Class-B-Netzen:
128.0.0.0 bis 191.255.255.255
Class-C-Netze: Adresse beginnt mit der binären Ziffernkombination 110, 21 bit für Netzwerk-Adresse, 8 bit für Host-Adresse. Damit gibt es weltweit 2 Mio. derartige Netzwerke, ein Class-C-Netz kann bis zu 256 Teilnehmer haben. Neu zugeteilte Netzadressen sind heute immer vom Typ C. Es ist abzusehen, dass bereits in Kürze alle derartigen Adressen vergeben sein werden. Man arbeitet daher an einem neuen Standard (Version 6 des Internet Protokolls, IPv6 oder IPng für „new generation“), der statt einer Adresslänge von 32 bit eine Länge von 128 bit haben soll. Um die Kompatibilität zu gewährleisten, wird die alte Adresse in der neuen Adresse "enthalten sein".
IP-Adressen von Class-C-Netzen:
192.0.0.0 bis 223.255.255.255
Class D-Netze haben einen speziellen Anwendungsbereich (Multicast-Anwendungen) und haben für Internet keine Bedeutung.
Laut RFC 1918 sind für „private“ Netze folgende IP-Bereiche gestattet (Rechner mit diesen IP-Adressen dürfen keinen direkten Internet-Verkehr haben, d.h. mit dem Internet nur über Proxy-Server in Kontakt treten; sie werden nicht geroutet!):
10.0.0.0 – 10.255.255.255
172.16.0.0 – 172.31.255.255
192.168.0.0 – 192.168.255.255
Für einen Anwender sind derartige Zahlenkombinationen schwer zu merken. Es werden daher statt dieser Zahlendarstellung symbolische Namen verwendet.
So gibt es etwa einen Server mit dem Namen
noe.wifi.at
Diesem Servernamen entspricht eine eindeutige IP-Adresse. Dabei setzt sich der Name aus Teilen zusammen, die eine Hierarchie angeben: Das Teilnetzwerk "noe" (fachchinesisch bezeichnet man ein solches Teilnetz als Domäne, englisch domain) ist ein Teil des Netzwerks "wifi", dieses wiederum ein Teil des Netzwerks "at" (für Österreich). Das "at"-Netzwerk ist ein Teil der Domäne "the world" (die aber nie angegeben zu werden braucht).
Die Länderkennung ist ein Beispiel für eine Top Level Domain (TLD); so werden die „Haupt-Domänen“ bezeichnet, die entweder einem Land oder einer „Kategorie“ entsprechen.
Die Zuordnung IP-Adressen zu logischen Namen muss von einem eigenen Rechner durchgeführt werden, dem Domain Name System-Server (DNS-Server). Wenn nun ein Anwender einen Server noe.wifi.at anwählt, so "fragt" die Station zunächst beim DNS-Server des Anwenders (der meist beim Provider steht), ob er die IP-Adresse von noe.wifi.at kennt. Das wird nicht der Fall sein. In diesem Fall hat der DNS-Server die IP-Adresse des nächstliegenden DNS-Servers gespeichert und fragt bei diesem an, ob er die IP-Adresse kennt. Das geht so lang, bis ein DNS-Server erfolgreich ist, die IP-Adresse wird übermittelt, die Datenübertragung kann beginnen.
Das Internet ist also ein so genanntes Teilstrecken-Netzwerk; es genügt, wenn jeder Internet-Knotenrechner mit einem weiteren Knoten verbunden ist. Die physikalische Datenübertragung wird über äußerst leistungsfähige Kabel, so genannte „Backbones“ realisiert.
Eine Karte, die die europäische Struktur der Backbones zeigt, findet man unter
www.ebone.net/structure/backbone.html.
Die zentrale Verwaltung der Domain-Namen mit den Top-Level-Domains .com, .net, .org und .int obliegt der InterNIC, einer Kooperation aus dem kommerziellen Unternehmen NSI (Network Solutions Inc.), der Telefongesellschaft AT&T sowie der US National Science Foundation. Bisher wurden die angegebenen Domains ausschließlich von der NSI im Auftrag der InterNIC verwaltet. Die jährliche „Miete“ eines Domännamens kostet ca. 50 US-$. Die Domain-Verwaltung soll jedoch bis 2001 von der NSI an die nichtkommerzielle Organisation ICANN (International Corporation for Assigned Names and Numbers) übergeben werden. Die Datenbank der NSI ist unter www.networksolutions.com/cgi-bin/whois/whois zu finden.
Die IANA (Internet Assigned Numbers Authority, www.iana.org) verwaltet die IP-Adressen.
Einen IP-Adressen-Index findet man unter ipindex.dragonstar.net.
Die ISPA (Internet Service Provider Association Austria – www.ispa.at) ist die Vereinigung der österreichischen Internet Service Provider, quasi eine „Dachorganisation“. Die NIC.AT GmbH, ein Unternehmen der ISPA, ist mit der Verwaltung und Vergabe der Domänennamen mit dem Top Level Domain „.at“ beauftragt (www.nic.at). Registrierungen und Online-Abfragen von at-Domainen sind unter www.namen.at möglich.
Dabei gibt es zum Beispiel als Länder-Top Level Domain (ISO-Norm 3166):
at . Austria (Österreich)
de Deutschland
jp Japan
us USA (fehlt meist)
Zusätzlich zu den landesspezifischen Erweiterungen gab es folgende Kennzeichnungen, die ursprünglich nur US-amerikanischen Einrichtungen vorbehalten waren:
com company (Firma)
gov government (Regierung) – US
edu education (Universitäten) – US
mil military (Militär) – US
int internationale Organisation
org organization (gemeinnützige Organisation)
net Provider
Nun werden die Adressen von 28 lizenzierten Firmen vergeben. Diese Firmen werden im CORE (Council of Registrars) zusammengefasst. Die neuen TLDs lauten:
firm Firmen und Unternehmen
arts Kunst und Kultur
info Informationsservices
rec Unterhaltung und Freizeit
web WWW-Aktivitäten
store Warenangebote
nom Restkategorie
MAC-Adresse = weltweit eindeutige Seriennummer, mit der jede Ethernet-Karte identifiziert wird
wird vom Hersteller fest eingebrannt
Unter TCP/IP besitzt jeder Rechner eine ARP (Address-Resolution-Protocol)-Tabelle, in der die Abbildung der IP-Adressen des lokalen Sub-Netzes auf die MAC-Adresse erfolgt.
Falls MAC-Adresse eines Rechners im Sub-Netz nicht bekannt, wird sie durch Rundfrage (broadcast) ermittelt. Rechner mit der gewünschten MAC-Adresse antwortet.
a) Netzwerkmasken
Netzwerkmasken unterscheiden sich in der Länge des Netzwerk- (alle Bit-Stellen auf 1) und Hostanteils (alle Bitstellen auf 0)
abhängig von der Netzwerkklasse
1.Byte 2.Byte 3.Byte 4.Byte
Class A 255 0 0 0
Class B 255 255 0 0
Class C 255 255 255 0
Netzwerkmasken stellen einen Filter dar, an dem Rechner entscheiden können, ob sie sich im selben (logischen) Netz befinden
b) Netzwerkadressen
die Netzwerkadresse eines Rechners ergibt sich, indem man die IP-Adresse mit der Netzwerkmaske bitweise UND-verknüpft
generell gilt, daß bei Netzwerkadressen alle Bitstellen des Hostanteils 0 sind
Beispiel
Class C 131 130 34 6 IP-Adresse
AND 255 255 255 0 Class C-Netzwerkmaske
= 131 130 34 0 Netzwerkadresse
nur Rechner mit der gleichen Netzwerkadresse befinden sich im gleichen logischen Netzwerk
c) Broadcast-Adresse
Die Broadcast-Adresse ergibt sich aus der IP-Adresse, bei der alle Bitstellen des Hostanteils auf 1 gesetzt sind. Sie bietet die Möglichkeit, Datenpakete an alle Rechner eines logischen Netzwerkes zu senden. Sie wird ermittelt, indem die Netzwerkadresse mit der invertierten Netzwerkmaske bitweise ODER-verknüpft wird.
Beispiel
Class C 255 255 255 0 Class C-Netzwerkmaske
0 0 0 255 invertierte Netzwerkmaske
OR 131 130 34 0 Class C-Netzwerkadresse
= 131 130 34 255
d) Loopback-Adresse
Die Class-A-Netzwerkadresse 127 ist weltweit reserviert für das sogenannte local loopback
dient zu Testzwecken der Netzwerkschnittstelle des eigenen Rechners.
Die IP-Adresse 127.0.0.1 ist standardmäßig dem Loopback-Interface jedes Rechners zugeordnet
alle an diese Adresse geschickten Datenpakete werden nicht nach außen ins Netzwerk gesendet, sondern an der Netzwerkschnittstelle reflektiert.
Die Datenpakete erscheinen, als kämen sie aus einem angeschlossenem Netzwerk
Rechenbeispiele zum Subnetting (Quelle: http://www.zyxel.de/support):
Auf der Hardwareseite wird die gesamte Kommunikation immer über die MAC Adresse abgewickelt. Diese Methode ist zwar recht schnell, jedoch lassen sich so nur schwer logische Zusammenschlüsse von einzelnen Computern bilden.
Beispiel:
Ein Unternehmen besteht aus drei Abteilungen mit jeweils fünf Computern. Daher ergeben sich 15 MAC Adressen unternehmensweit. Nun ist es in dieser Größenordnung kein Problem, eine Liste mit allen MAC Adressen und deren Standorten zu führen.
Was aber, wenn eine Nachricht nur an die Rechner der Abteilung Buchhaltung geschickt werden soll? Diese Nachricht müsste nun an jeden einzelnen Computer der betreffenden Abteilung einzeln geschickt werden.
Nun stellt man sich diese Aufgabe in einem Unternehmen mit zig hundert Computern vor !!
Aus diesem Grund musste zusätzlich zur realen Adressierung eine Methode entwickelt werden, um Computer in logische Gruppen organisieren zu können. Dies wird mit TCP/IP realisiert.
Den Aufbau eine TCP/IP Adresse kann man sich ungefähr wie eine Postanschrift vorstellen:
Land -> Ort -> Strasse -> Gebäude -> Familie -> Person
Die derzeitige Schreibweise bei IP-Adressen wird „Dotted Decimal" genannt. In dieser Form besteht eine Adresse aus zwei Zahlenblöcken mit jeweils vier Gruppen. Der erste Block ist die eigentliche Adresse, der zweite die Subnetzmaske.
Beispiel:
|
Adresse |
Subnetzmaske |
Um TCP/IP Adressen verstehen zu können, muß man sich vor Augen halten, daß die „reale" Schreibweise von Adressen in binärer Form erfolgt (4 Oktetts a 8 Bit).
192 |
168 |
100 |
1 |
Gerechnet wird dann wie folgt:
|
128 |
64 |
32 |
16 |
8 |
4 |
2 |
1 |
192 |
1 |
1 |
0 |
0 |
0 |
0 |
0 |
0 |
168 |
1 |
0 |
1 |
0 |
1 |
0 |
0 |
0 |
100 |
0 |
1 |
1 |
0 |
0 |
1 |
0 |
0 |
1 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
1 |
|
x |
x |
x |
x |
x |
x |
x |
x |
255 |
1 |
1 |
1 |
1 |
1 |
1 |
1 |
1 |
192 |
= |
11000000 |
= |
128 |
+ |
64 |
|
|
168 |
= |
10101000 |
= |
128 |
+ |
32 |
+ |
8 |
100 |
= |
01100100 |
= |
64 |
+ |
32 |
+ |
4 |
1 |
= |
00000001 |
= |
1 |
|
|
|
|
Daraus ergibt sich auch der Maximalwert von 255
255 = 11111111 = 128 + 64 + 32 + 16 + 8 + 4 + 2 + 1
Gleiches gilt auch für die Subnetzmaske:
255 |
255 |
255 |
0 |
Erst durch die Subnetzmaske ist eine Zusammenfassung von TCP/IP Adressen in logische Gruppen möglich. Dazu muß man wissen, daß es in jeder Gruppe (Subnetz) zwei spezielle Adressen gibt:
Um nun die Berechnung von Subnetzen zu verstehen, sehen wir uns das obige Beispiel auf der binären Ebene an:
Gegebene Hostadresse: 192.168.100.1 /24
Berechnung der Subnetzadresse:
Die Hostadresse wird mit der Subnetzmaske logisch UND verknüpft:
Hostadresse |
192.168.100.1 |
11000000 |
10101000 |
01100100 |
00000001 |
UND |
|
|
|
|
|
Maske |
255.255.255.0 |
11111111 |
11111111 |
11111111 |
00000000 |
Subnetz |
192.168.100.0 |
11000000 |
10101000 |
01100100 |
00000000 |
Berechnung der Broadcastadresse:
Die Subnetzadresse wird mit der invertierten Subnetzmaske logisch ODER verknüpft:
Subnetz |
192.168.100.0 |
11000000 |
10101000 |
01100100 |
00000000 |
ODER |
|
|
|
|
|
Maske |
0.0.0.255 |
00000000 |
00000000 |
00000000 |
11111111 |
Broadcast |
192.168.100.255 |
11000000 |
10101000 |
01100100 |
11111111 |
Daraus ergibt sich:
Subnetzadresse: |
192.168.100.0 |
Broadcast: |
192.168.100.255 |
Adressbereich: |
192.168.100.1
bis 192.168.100.254 |
Hier gibt es nur ein Subnetz. Im folgenden Beispiel sind es schon zwei:
Gegebene Hostadresse: 192.168.100.1 /25
Berechnung der Subnetzadresse 0:
Die Hostadresse wird mit der Subnetzmaske logisch UND verknüpft:
Hostadresse |
192.168.100.1 |
11000000 |
10101000 |
01100100 |
00000001 |
UND |
|
|
|
|
|
Maske |
255.255.255.128 |
11111111 |
11111111 |
11111111 |
10000000 |
Subnetz |
192.168.100.0 |
11000000 |
10101000 |
01100100 |
00000000 |
Berechnung der Broadcastadresse 0:
Die Subnetzadresse wird mit der invertierten Subnetzmaske logisch ODER verknüpft:
Subnetz |
192.168.100.0 |
11000000 |
10101000 |
01100100 |
00000000 |
ODER |
|
|
|
|
|
Maske |
0.0.0.127 |
00000000 |
00000000 |
00000000 |
01111111 |
Broadcast |
192.168.100.127 |
11000000 |
10101000 |
01100100 |
01111111 |
Berechnung der Subnetzadresse 1:
Die Hostadresse wird mit der Subnetzmaske logisch UND verknüpft:
Hostadresse |
192.168.100.129 |
11000000 |
10101000 |
01100100 |
10000001 |
UND |
|
|
|
|
|
Maske |
255.255.255.128 |
11111111 |
11111111 |
11111111 |
10000000 |
Subnetz |
192.168.100.128 |
11000000 |
10101000 |
01100100 |
10000000 |
Berechnung der Broadcastadresse 1:
Die Subnetzadresse wird mit der invertierten Subnetzmaske logisch ODER verknüpft:
Subnetz |
192.168.100.128 |
11000000 |
10101000 |
01100100 |
10000000 |
ODER |
|
|
|
|
|
Maske |
0.0.0.127 |
00000000 |
00000000 |
00000000 |
01111111 |
Broadcast |
192.168.100.255 |
11000000 |
10101000 |
01100100 |
11111111 |
Daraus ergibt sich:
Subnetzadresse 0: |
192.168.100.0 |
Broadcast 0: |
192.168.100.127 |
Adressbereich 0: |
192.168.100.1
bis 192.168.100.126 |
|
|
Subnetzadresse 1: |
192.168.100.128 |
Broadcast 1: |
192.168.100.255 |
Adressbereich 1: |
192.168.100.129
bis 192.168.100.254 |
Mögliche Subnetzmasken und ihre verschiedenen Schreibweisen sind:
Subnetzmaske |
|
#
Bit Subnetting |
# Subnetze |
# Hosts / Netz |
255.0.0.0 |
/8 |
0 |
0 |
16777214 |
255.128.0.0 |
/9 |
1 |
2 |
8388606 |
255.192.0.0 |
/10 |
2 |
4 |
4194302 |
255.224.0.0 |
/11 |
3 |
8 |
2097150 |
255.240.0.0 |
/12 |
4 |
16 |
1048574 |
255.248.0.0 |
/13 |
5 |
32 |
524186 |
255.252.0.0 |
/14 |
6 |
64 |
262142 |
255.254.0.0 |
/15 |
7 |
128 |
131070 |
255.255.0.0 |
/16 |
8 |
256 |
65536 |
255.255.128.0 |
/17 |
9 |
512 |
32766 |
255.255.192.0 |
/18 |
10 |
1024 |
16382 |
255.255.224.0 |
/19 |
11 |
2048 |
8190 |
255.255.240.0 |
/20 |
12 |
4096 |
4094 |
255.255.248.0 |
/21 |
13 |
8192 |
2046 |
255.255.252.0 |
/22 |
14 |
16384 |
1022 |
255.255.254.0 |
/23 |
15 |
32786 |
510 |
255.255.255.0 |
/24 |
16 |
65536 |
254 |
255.255.255.128 |
/25 |
17 |
131072 |
126 |
255.255.255.192 |
/26 |
18 |
262144 |
62 |
255.255.255.224 |
/27 |
19 |
524288 |
30 |
255.255.255.240 |
/28 |
20 |
1048576 |
14 |
255.255.255.248 |
/29 |
21 |
2097152 |
6 |
255.255.255.252 |
/30 |
22 |
4194304 |
2 |
Adressklassen
Class A: 1.0.0.0 - 127.0.0.0
Netzwerkanteil: |
7 Bit im
1. Byte (1 Bit festgelegt |
Hostanteil: |
2. Bis 4.
Byte (insgesamt 24 Bit) |
Class A: |
Sehr
geringe Anzahl von Netzwerken mit einer sehr großen Anzahl von Hosts/Netzwerk |
Class
B: 128.0.0.0 - 191.255.0.0
Netzwerkanteil: |
6 Bit im
1. Byte (2 Bit festgelegt) & 8 Bit im 2. Byte (insgesamt 14 Bit
Netzwerkanteil) |
Hostanteil: |
3. &
4. Byte (insgesamt 16 Bit) |
Class B: |
Mittlere
Anzahl von Netzwerken mit einer mittleren Anzahl von Hosts/Netzwerk |
Class C: 192.0.0.0 - 223.255.255.0
Netzwerkanteil: |
5 Bit im
1. Byte (3 Bit festgelegt) & jeweils 8 Bit im 2. & 3. Byte |
Hostanteil: |
nur 4.
Byte (gesamt 8 Bit) |
Class C: |
Sehr
grosse Anzahl von Netzwerken mit einer geringen Anzahl von Hosts/Netzwerk |
Zusammenfassung:
CLASS |
Netzwerk Anteil |
# Netze |
Hostanteil |
# Hosts/Netz |
A |
1 Bit + 7 Bit |
128 |
24
Bit |
16.777.214 |
B |
2 Bit + 14 Bit |
16.864 |
16
Bit |
65.534 |
C |
3 Bit + 21 Bit |
2.097.152 |
8 Bit |
253 |
Private Adressen
Da jede Adresse individuell sein MUß, gleichzeitig aber auch eine gewisse Flexibilität bei der Adressvergabe vorhanden sein soll, wurden innerhalb der einzelnen Adressklassen Bereiche geschaffen, die dem privaten Gebrauch vorbehalten sind. Diese Adressen dürfen innerhalb z.B. Eines Firmennetzes ohne jegliche Registrierung frei vergeben werden. Natürlich dürfen diese Adressen innerhalb eines Netzes nicht doppelt vorkommen, jedoch können so unterschiedliche Nete mit den gleichen Adressen entstehen. Aus diesem Grund muß sichergestellt sein, daß diese Adressen niemals nach aussen (ins Internet) propagiert werden (dies kann z.B. durch NAT - Network Adress Translation verhindert werden).
Private Bereiche:
Class A: |
10.0.0.0 |
255.0.0.0 |
Class B: |
172.16.0.0 |
255.240.0.0 |
Class C: |
192.168.0.0 |
255.255.255.0 |
Ports
Auf TCP/IP basieren viele verschiedene Dienste wie Mail, News, DNS, etc. Um nun diese Dienste innerhalb der Protokollfamilie TCP/IP voneinander abzugrenzen, werden diese Dienste den sogenannten Ports zugewiesen. Ein Port ist nichts anderes als eine zusätzliche Kennung zur IP-Adresse. Derzeit sind rund 65.000 Ports bekannt, welche sich auf verschiedene Bereich aufteilen.
Well known
Ports: |
0 |
- |
1023 |
|
Registered
Ports: |
1024
|
- |
49151 |
|
Dynamic
and/or privat Ports: |
49152 |
- |
65535 |
|
Eine komplette Liste aller Ports, und so ziemlich die gesamte Dokumentation zu allem was Netzwerke und Protokolle betrifft, findet sich unter „http://www.iana.com".
ARP
ARP (Adress Resolution Protocol) beschreibt die Kommunikation zwischen Hosts auf Basis von Layer 2 (MAC Adressen). Die eigentliche Kommunikation zwischen Hosts basiert, unabhängig von den höheren Protokollen wie TCP/IP, IPX etc. immer auf Basis der MAC-Adressen. Das bedeutet, wenn ein Host ein Datenpaket an einen anderen schickt, dann sieht es für den Benutzer zwar so aus, als wenn das paket an eine bestimmte IP-Adresse gerichtet ist, in Wirklichkeit jedoch kennt der Netzwerktreiber, ähnlich wie bei DNS, die Zuordnung zwischen ihm bekannten MAC-Adressen und den zugeordneten IP-Adressen. Diese Vergleichstabelle nennt man auch ARP-Cache. Diese Einträge unterliegen einem Alterungsprozess (Aging). Da jedes Datenpaket als Absender nicht nur die IP-Adresse sondern auch die entsprechende MAC-Adresse enthält, lernen so die Hosts im Laufe der Zeit alle zuordnungen zwischen MAC- und IP-Adresse. Wird nun eine Adresse eine bestimmte Zeit nicht angesprochen, "altert" ihr Eintrag und rutscht in der tabelle nach unten, bis er schliesslich ganz aus der tabelle entfernt wird. Dieses "Aging" dient dazu, die Tabelle möglichst kurz zu halten, und so die Suchzeiten zu minimieren. Soll nun ein Paket an eine IP-Adresse geschickt werden, deren MAC-Adresse nicht bekannt ist, stellt der sendene Host einen ARP-Request mit folgendem Inhalt: "Antwort erbeten von IP-Adresse xxx.xxx.xxx.xxx". Wenn die gerufene Station darauf antwortet, übermittelt sie ja nicht nur ihre IP-Adresse, sondern auch ihre MAC-Adresse. Somit sind alle notwendigen Angaben zusammen und der Transport des Paketes kann stattfinden.
Den umgekehrten Weg, MAC-Adresse bekannt, IP-Adresse gesucht, definiert RARP (Reverse Adress Resolution Protocol).
RARP
Oftmals ergibt sich die Problematik, z.B. ein Notebook in verschiedenen Netzen betreiben zu müssen. Dadurch wird es notwendig, Netzwerkparameter wie IP-Adresse, Gateway, etc. nach dem Start des Systems neu einstellen zu müssen. Meist ist dann ein Neustart erforderlich. Wesentlich einfacher und effektiver wäre es, das System selbst die Einbindung ins Netzwerk und damit sämtliche Parameter, vornehmen zu lassen.
Die erste und einfachste Alternative zur Lösung dieses Problems, das Reverse Adress Resolution- oder RARP-Protokoll, bietet Computersystemen die Möglichkeit, sich eine IP-Adresse zuteilen zu lassen, wenn ein Computer über keine Möglichkeiten verfügt, seine IP-Adresse lokal zu speichern, z.B. auf einer Festplatte. Im einzelnen wendet sich dabei ein Rechner mittels eines Broadcasts auf sein Subnetz an einen sogenannten RARP-Server und teilt ihm seine Hardwareadresse mit, für die der Server die zugeordnete IP-Adresse kennt. Der Server teilt daraufhin dem Rechner seine IP-Adresse mit. Die Übertragung der Informationen erfolgt über die physikalische Netzverbindung. Bei der Verwendung von Ethernet beispielweise hat eine RARP-Anfrage den Standard-Vorspann, Ethernet-Quell- und Ziel-Adressen und Pakettyp-Felder am Beginn des Ethernet-Pakets. Der Datenteil enthält dann die 28-Oktett-RARP-Nachricht. RARP hat drei schwerwiegende Nachteile: Als erstes setzt es den direkten Zugriff auf die Netz-Hardware voraus. Diese Tatsache macht es einem Anwendungsprogrammierer schwer bzw. unmöglich, ein Serverprogramm zu erstellen. Zweitens benötigt RARP den direkten Austausch von Paketen zwischen einer Clientmaschine und dem Rechner, der die Rolle des Servers übernimmt. Der Server kann aber dem Client als einzige Information die 4-Oktett-IP-Adresse mitteilen. Und drittens verhindert die Tatsache, daß RARP die Hardware-Adresse eines Rechners zu dessen Identifizierung benutzt, den Einsatz von RARP in Netzen, die Hardwareadressen dynamisch vergeben
BOOTP
Als Ausweg aus dieser Problemlage unter RARP wurde das Bootstrap- oder BOOTP-Protokoll entwickelt. Wie RARP setzt BOOTP ein Client-Server-artiges Konzept voraus und benötigt nur ein einzelnes Paket, um die Konfigurationsinformation zu übermitteln. Dabei erfährt ein konfigurationswilliger Host von einem BOOTP-Server seine IP-Adresse, die Adresse eines Routers und eines File Servers sowie firmenspezifische Parameter, die der Host für das Booten benötig. Dies funktioniert folgendermaßen: Ein konfigurationswilliges Computersystem sendet einen sogenannten BOOTREQUEST als Broadcast an einen oder mehrere BOOTP-Server. Als Transportprotokoll wird das User Datagram Protocol verwendet. Der BOOTP-Server antwortet mit einem BOOTREPLY, in dem er dem Client eine IP-Adresse und andere Parameter für die Netzkonfiguration vermittelt, die es aus einer Konfigurationsdatei ausliest. Diese Datei wird von den Netzbetreibern erstellt. Falls BOOTP-Server und BOOTP-Client sich nicht auf dem selben Subnetz befinden, leitet ein sogenannter Relay Agent den Broadcast auf die gewünschten Subnetze weiter.
DHCP
Mit der Entwicklung von mobilen Systemen wie Systemen mit drahtloser Übertragung oder Laptops mit Netzanschluß ergibt sich das Problem, daß BOOTP zu statisch für die Konfiguration dieser Systeme ist. Die Ursache liegt darin, daß BOOTP nur gestattet, Konfigurationsinformationen einem Hostsystem statisch zuzuordnen. Außerdem muß bei BOOTP der Netzadministrator für jeden Host die Konfigurationsinformationen einzeln in einem Konfigurations-File des BOOTP-Servers niederlegen. Dadurch ist BOOTP nicht in der Lage, einzelne Rechner dynamisch mit einer Konfiguration zu versorgen. Große Probleme bekommt man mit BOOTP vor allem dann, wenn Rechner sehr flexibel in unterschiedlichen Netzen eingesetzt werden oder wenn weniger freie IP-Adressen vorhanden sind als Interessenten für eine IP-Adresse. Einen Ausweg aus dieser Problemlage bietet das sogenannte Dynamic Host Configuration Protocol, kurz DHCP genannt. DHCP wird heute schon in vielen Bereichen zur Konfiguration von IP-Systemen eingesetzt und eignet sich vor allem auch gut zur Konfiguration mobiler Systeme. DHCP erweitert das BOOTP-Protokoll, indem es einem Rechner oder IP-System die Möglichkeit bietet, seine IP-Adresse schnell und dynamisch zu erhalten. Um einen sogenannten DHCP-Server in die Lage zu versetzen, IP-Systeme dynamisch mit IP-Adressen zu versorgen, muß ein Netzadministrator ihm einen Satz IP-Adressen zur Verfügung stellen. Über diese IP-Adressen muß der DHCP-Server frei verfügen können, d.h., sie dürfen nicht von anderen Systemen im Netz belegt sein. Wenn nun ein Rechner, der sogenannte DHCP-Client, in das Netz eintritt, nimmt er mit dem DHCP-Server Kontakt auf]]. Der Server wählt eine seiner freien Adressen aus und vermittelt sie dem neuen Rechner. Dabei unterstützt DHCP auch BOOTP-Anfragen. Bei DHCP gibt es dabei drei Arten der Adreßvergabe]:
Bei der Vergabe von Adressen ist zu beachten, daß ein System, welches mehrere IP-Adressen benötigt, für jede Adresse eine eigene Adressenanfrage unter DHCP starten muß.
DNS
Das
Prokoll , oder besser die Protokollfamilie TCP/IP, benötigt zur Adressierung
die erwähnten IP-Adressen. Nun ist es für den Anwender unmöglich, alle
benötigten Adressen in der numerischen Form zu behalten. Es wäre doch
wesentlich einfachen, statt "ping 192.168.100.1" sagen zu
können "ping fileserver". Damit dieses möglich wird, muß
zwischen dem eigentlichen Befehl "ping" und der Anwendung desselben
auf eine Adresse eine weitere Zwischenstufe geschaltet werden: DNS (Domain Name
Service). Diese Protokoll macht nichts anderes, als einem "realen"
Namen eine dem Protokoll TCP/IP verständliche Adresse zuzuweisen. Dazu stellt
der IP-Stack des jeweiligen Betriebssystems einen sogenannten DNS-Request über
den Port 53 an den ihm bekannten DNS-Server. Falls dieser in der Lage ist, den
Request zu beantworten, wird die IP-Adresse zurück gegeben. Falls nicht, wird
je nach Konfiguration des DNS-Servers von diesem der Request an seine ihm
vorgeschalteten Server weitergeleitet, oder aber, der Request wird als nicht auflösbar
beantwortet.
Die Reihenfolge eines DNS-Requests wird hier ersichtlich:
Hier wird auch
ersichtlich, warum dem Betriebssystem sowohl ein DNS als auch ein Gateway
bekannt sein muß. Der DNS-Request wird an die Adresse des DNS gestellt, der
eigentliche Befehl aber über die des Gateways. Die Datei HOSTS ist Bestandteil
aller Betriebssysteme mit TCP/IP Protokollstack. Diese ersetzt einen remote
DNS, falls dieser nicht, oder während des Bootens, noch nicht, verfügbar ist.
Wie eindeutig zu ersehen ist, wird die Datei HOSTS immer zuerst befragt. D.h.
wenn dort eine entsprechende Namensauflösung vorgenommen werden kann, wird
diese Antwort an den Protokoll-Stack übergeben, unabhängig davon, ob die
gelieferte IP-Adresse richtig ist.
Format der HOSTS-Datei
#IP-Adresse |
#realer
Name |
#Kommentare |
127.0.0.1 |
localhost |
|
192.168.100.1 |
fileserver |
#kurze
Bezeichnung |
192.168.100.1 |
fileserver.home_domaine.de |
#lange
Bezeichnung inkl. Domaine |
WICHTIG: Die zu verwendenden Kommentarzeichen sind vom Betriebssystem abhängig.
Datenübertragung im Internet
Bei der Datenübertragung im Internet laufen viele Vorgänge ab, von denen der Anwender nichts merkt. So werden im Internet nicht ganze Dateien übertragen, sondern sogenannte „Pakete“, auch „IP-Datagramme“ genannt.
Damit ein Paket auch beim Empfänger ankommt, müssen eine Reihe von Informationen mit diesem Paket mitgeschickt werden.
Da die Datenübertragung in jedem Netzwerk sehr komplex ist, teilt man das Problem in Teilprobleme auf. Man unterscheidet sogenannte „Schichten“, die bestimmte Aufgaben erfüllen; im Internet könnte man folgende Schichten unterscheiden:
Jede Schicht (Teilfunktion) wird durch ein sogenanntes Protokoll realisiert; in der Praxis gibt es spezielle Treiber, die die Aufgaben von Protokollen übernehmen (in Windows gibt es etwa die TCP/IP-Treiber).
Man hat für alle Netzwerke ein einheitliches Schichtenmodell entworfen, das ISO/OSI-7-Schicht-Referenzmodell. In der folgenden Abbildung sehen Sie, welche Protokolle im Internet welche Aufgaben erfüllen:
Jede Schicht fügt spezielle Adress- und Protokollinformationen (sogenannte „Header“) zu den eigentlichen Daten hinzu. Dadurch wird das Datenpaket immer größer. Beim Empfänger durchläuft das Datenpaket die Protokolle in umgekehrter Reihenfolge, wobei die Daten dabei sozusagen „ausgepackt“ werden.
Protokolle niederer Schichten (Schichten 1, 2)
ARP, Address Resolution
Protocol:
Dieses Protokoll setzt IP-Adressen in MAC-Adressen um (Media Access Control). Die meisten Netzwerke sind Ethernet-Netze; in diesen Netzen besitzt jeder Rechner (eigentlich: die Netzwerkkarte jedes Rechners) eine weltweit eindeutige Adresse, die sogenannte MAC-Adresse. Das ARP ordnet daher jeder IP-Adresse die korrekte Netzwerkkarte zu.
DHCP, Dynamic Host Configuration Protocol:
Dieses Protokoll dient dazu, um Rechner im Netz bereits beim Booten konfigurieren zu können. So kann zum Beispiel jedem Rechner automatisch eine IP-Adresse zugewiesen werden.
PPP, Point to Point
Protocol:
Ermöglicht die Verbindung zweier Computer über eine serielle Leitung – wird heute immer bei Modemverbindungen zum Internet-Server verwendet. Das Protokoll arbeitet mit IP zusammen und bildet zusätzlich Prüfsummen zur Fehlerkontrolle. (Ein älteres Protokoll mit derselben Aufgabe war das SLIP = Serial Line Internet Protocol, welches heute aber nicht mehr verwendet wird).
Das Internet Protocol (IP) – Schicht 3
Wir haben bereits erwähnt, dass jedes Protokoll spezielle Informationen (den sogenannten Header) zu den eigentlichen Daten hinzufügt.
Hauptaufgaben
des IP-Protokolls:
Wir wollen hier den IP-Header etwas genauer betrachten. Zuerst sollen an dieser Stelle das Aussehen und die Bedeutung der einzelnen Header-Elemente beschrieben werden.
Abbildung:
Der IP-Header |
|
Die ersten vier Bits stellen das Feld Ver dar (siehe Abbildung). Sie sind für die Version des IP-Protokolls bestimmt, welches das zu sendende Datagramm zusammenstellt. Bei der Benutzung von IPv4 enthält dieses Feld den Wert vier.
Die nächsten vier Bit, die das Feld HLen repräsentieren, enthalten die aktuelle Header-Länge. Dabei werden aber nicht die Bytes, sondern die Doppel-Worte (4 Byte) gezählt. Bei einem IP-Standard-Header sollte hier eine fünf stehen. Dieser Standard-Header findet bei der Übertragung normaler Nutzdaten Anwendung. Er umfaßt immer 5 Doppel-Worte = 20 Byte.
Danach folgt das Feld TOS, Type of Service. Es enthält u.a. Informationen, welcher Art die zu transportierenden Daten sind und welche Qualität die Art der Übertragung besitzen soll.
Das Feld Total Length im IP-Header kennzeichnet die totale Länge eines Datagramms einschließlich Header. Da dieses Feld nur eine 16-Bit-Zahl enthalten kann, ist auch die Größe eines IP-Datagramms auf maximal 216 - 1 = 65535 Byte beschränkt. Ein größeres Datagramm kann durch IP nicht vermittelt werden.
Auf die Bedeutung der Felder Identification, Flags und Fragment Offset wird später näher eingegangen. Sie werden benötigt, um eine Datagramm-Übermittlung auch über Netzverbindungen zu garantieren, die die maximale Größe eines IP-Datagramms nicht transportieren können.
Im Feld TTL wird die Lebenszeit, Time To Live, eines Datagramms verwaltet. Es dient zur Vorbeugung, daß ein Datagramm im Netz nicht ,“ewig herumirrt“. Beim Verschicken des Datagramms wird durch den Sender eine Zahl in dieses Feld eingesetzt, die die Lebenszeit dieses Datagramms in Sekunden repräsentieren soll. Da aber ein anderer Host nicht weiß, wann dieses Datagramm erzeugt wurde und im Header auch keine Information über die Erzeugung vorhanden ist, repräsentiert diese Zahl in der Praxis etwas anderes. Sie gibt an, wieviele Router dieses Datagramm passieren darf, um den Empfänger zu erreichen. Dazu ist es notwendig, daß jeder benutzte Router den Wert dieses Feld um 1 erniedrigt. Ist irgendwann einmal der Wert des Feldes TTL gleich Null, dann wird es von dem Router, der es gerade bearbeitet, verworfen, und er sendet eine Fehlermeldung zurück an den Sender.
Das Feld Protocol wird von IP benutzt, um auf der Seite des Senders das Protokoll zu vermerken, welches die Dienste von IP in Anspruch nimmt. Auf der Seite des Empfängers dient es IP dazu, das Datagramm genau an dieses Protokoll zur weiteren Bearbeitung weiterzuleiten.
Das Feld Header Checksum beinhaltet eine Prüfsumme. Sie dient zum Erkennen von Verfälschungen bei der Übertragung des Datagramms. Allerdings wird sie nur über die Daten des IP-Headers selbst gebildet. Die zu transportierenden Daten werden nicht berücksichtigt. Soll über diesen Daten auch eine Prüfsumme zur Fehlererkennung gebildet werden, muß das ein anderes Protokoll oder die Anwendung selbst übernehmen, die die Dienste von IP in Anspruch nimmt. Die Überprüfung ist einfach zu vollziehen. Der das Datagramm bearbeitende Host, das kann auch ein Router sein, extrahiert den Wert aus dem Feld Header Checksum des Datagramms und berechnet diesen neu. Gleichen sich die beiden Werte nicht, wird IP dieses Datagramm verwerfen und eine Fehlermeldung an den Sender schicken. Ansonsten wird das Datagramm an den Empfänger zugestellt. Der Algorithmus zur Erstellung dieser Prüfsumme ist recht simpel. Der Wert dieser Prüfsumme stellt das Einerkomplement der Einerkomplementsumme des Headers dar. Dabei werden die Daten in Einheiten von 16 Bit zerteilt und addiert. Zur Berechnung wird der Header vollständig ausgefüllt. Das Feld Header Checksum wird vor der Berechnung mit Null initialisiert. Als Eingabe des Algorithmus bei einem Standard-Header dienen dann diese so vorbereiteten 20 Byte = 10 Worte. Das ermittelte Ergebnis wird zuletzt in das Feld Header Checksum übertragen. Der Grund, nur über den IP-Header eine Prüfsumme zu bilden, liegt darin begründet, daß diese Berechnung auf jedem Router durchgeführt werden muß. Dieses Verfahren stellt gegenüber der Berechnung über alle Daten eine erhebliche Beschleunigung der Vermittlung dar.
Zur Adressierung des Datagramms werden unbedingt die zwei Felder Source IP Address (Quell-Adresse) und Destination IP Address (Ziel-Adresse) benötigt. Die Ziel-Adresse dient zur Adressierung des Empfängers. Das Eintragen einer Quell-Adresse wird einmal zur etwaigen Erzeugung von Fehlermeldungen benötigt und außerdem dient sie dem Empfänger zur Identifizierung des Senders.
Im Feld Data können alle möglichen Nutzdaten transportiert werden.
Die Felder IP Options und Padding hängen direkt miteinander zusammen. Da der IP-Header immer Vielfache von Doppel-Worten enthalten muß, die Optionen aber verschieden lang sein können, wird das Padding zur Auffüllung genutzt, um wieder ein volles Doppel-Wort zu erhalten. Wird durch IP festgestellt, daß der Wert im Feld HLen größer als 5 ist, muß der Header Optionen enthalten. An Hand dieser Header-Länge ist auch ersichtlich, wo die Optionen enden und von wo ab eventuell Daten im Datagramm enthalten sind. Die Bedeutung der Optionen werden u.a. im RFC 791 beschrieben.
Abbildung: Das Feld TOS des IP-Headers |
|
Die Abbildung zeigt den Aufbau des Feld TOS. Die drei Bits des Feldes Precedence kennzeichnen die Art des Datagramms. Sie können einen Wert zwischen 0 und 7 annehmen. Der Wert 0 wird bei einem Datagramm eingesetzt, welches normale Nutzdaten transportiert. Der Wert 7 wird für Datagramme zur Netzwerk-Steuerung verwendet. Näheres dazu ist im RFC 791 zu erfahren. Die Felder D, T und R legen fest, welcher Qualität die Art der Übertragung des Datagramms sein soll. Feld D macht dabei eine Aussage über die Schnelligkeit, Feld T über den Durchsatz und Feld R über die Verfügbarkeit der Übertragung. Setzt z.B. ein Sender das Bit in Feld D in einem Datagramm, verlangt er, daß dieses so schnell wie möglich an den Empfänger übermittelt wird.
Der Header muß grundsätzlich in der Netzwerk-Byte-Ordnung (network byte order) verschickt werden. Diese Ordnung wird auch Big Endian genannt.
Das Transfer/Transmission Control Protocol (TCP) – Schicht 4
Das TCP ist ein verbindungsorientiertes Protokoll; es bildet
die Verbindung zwischen IP und Anwendung.
Aufgaben:
Merkmale:
Der TCP-Header: Natürlich fügt auch das TCP-Protokoll spezielle Daten hinzu – wieder in Form eines Headers – der wie folgt aufgebaut ist:
|
· Sender/Empfänger-Port (je 16 B): Endpunkte der Verbindung · Sequ./Quitt.nummer (32 B): Synchronisation der Daten · Datenabstand (4 B): Länge des Headers in 32 B · Flags (6 B): Aktionen (Aufbau, Ende, ...) · Fenstergröße (16 B): Größe des verfügbaren Empfängerbuffers (bei 0 Stop des Senders) · Prüfsumme (16 B): Korrektheit des Headers · Urgent-Zeiger (16 B): zur Verarbeitung von wichtigen Daten · Optionen (24 B), Füllzeichen (6 B) |
Protokolle höherer Schichten – Schichten 5, 6, 7
Diese Protokolle sind sozusagen die gemeinsame „Sprache“ zwischen Serversoftware und Clientsoftware. Jedem Internet-Dienst ist ein solches Protokoll zugeordnet:
usw.
Well
Known Port Numbers (RFC 1340): Fast immer laufen auf einem Internet-Server mehrere Dienste, etwa FTP,
Archie, WWW etc. Um die einzelnen Dienste unterscheiden zu können, wurde jedem
Dienst eine spezielle Kennung, die sogenannte „Port Number“, zugewiesen. Um
internationale Einheitlichkeit zu gewährleisten, wurden die „gut bekannten“
Port Numbers im RFC 1340 (Request for Comment, „Bitte um Kommentar“, de facto
eine „Internet-Norm“) zusammengestellt.
Ein Auszug
folgt hier:
ftp-data 20/tcp File Transfer [Default Data]
ftp 21/tcp File Transfer [Control]
telnet 23/tcp Telnet
24/tcp any private mail system
smtp 25/tcp Simple Mail Transfer
35/tcp any private printer server
time 37/tcp Time
rlp 39/tcp Resource Locatio Protocol
graphics 41/tcp Graphics
nameserver 42/tcp Host Name Server
nicname 43/tcp Who Is
domain 53/tcp Domain Name Server
xns-auth 56/tcp XNS Authentication
tftp 69/tcp Trivial File Transfer
gopher 70/tcp Gopher
finger 79/tcp Finger
www 80/tcp World Wide Web HTTP
hosts2-ns 81/tcp HOSTS2 Name Server
xfer 82/tcp XFER Utility
kerberos 88/tcp Kerberos
su-mit-tg 89/tcp SU/MIT Telnet Gateway
rtelnet 107/tcp Remote Telnet Service
pop2 109/tcp Post Office Protocol - Version 2
pop3 110/tcp Post Office Protocol - Version 3
auth 113/tcp Authentication Service
audionews 114/tcp Audio News Multicast
sftp 115/tcp Simple File Transfer Protocol
uucp-path 117/tcp UUCP Path Service
sqlserv 118/tcp SQL Services
nntp 119/tcp Network News Transfer Protocol
statsrv 133/tcp Statistics Service
netbios-ns 137/tcp NETBIOS Name Service
netbios-dgm 138/tcp NETBIOS Datagram Service
netbios-ssn 139/tcp NETBIOS Session Service
imap2 143/tcp Interim Mail Access Protocol v2
sqlsrv 156/tcp SQL Service
pcmail-srv 158/tcp PCMail Server
irc 194/tcp Internet Relay Chat Protocol
ipx 213/tcp IPX
imap3 220/tcp Interactive Mail Access Protocol v3
conference 531/tcp chat
netnews 532/tcp readnews
netwall 533/tcp for emergency broadcasts
uucp 540/tcp uucpd
Wenn nötig, ist die Portnummer auch anzugeben (mit einem Doppelpunkt nach der eigentlichen Adresse). Ein Beispiel ist der bekannte Ö3-Chat:
Die Syntax in der URL-Zeile lautet allgemein:
Servertyp://servername.domain.tld:portnumber
Serverinstallation
1. Schritt:
NT-Server installieren; kein Domänencontroller, sondern „alleinstehender Server“!
CD-Key
040-0033861
2.
Schritt:
Windows NT
Service Pack 3 installieren
3. Schritt:
Microsoft Internet Explorer 4.0 installieren
4. Schritt:
NT 4 Option Pack installieren
Lizenzvertrag annehmen.
Man kann auch die Standard-Variante installieren; wesentlich sind jedoch die Komponenten „Microsoft Script Debugger“ und „IIS 4“. Empfehlung: Installieren Sie die Frontpage-Servererweiterungen NICHT! Sie sind nur äußerst schwer wieder entfernbar und können das System destabilisieren!
Bei den Standardverzeichnissen am besten vorläufig nichts ändern:
Details zur Serverinstallation im WIFI St. Pölten – Internet-Lehrgang
Beachten Sie bitte: Die angegebenen Lizenzen und Lizenznummern wurden vom WIFI ausschließlich für Schulungszwecke angekauft und dürfen daher außerhalb der Kursumgebung keinesfalls verwendet werden!
1.
Herstellen der
Verbindung zu den Novell Netware-Druckern:
Um die Druckservices des Novell Netware-Servers WIFI nutzen zu können, muss der Gateway-Service und Client für Netware-Netzwerke installiert werden.
Dazu rufen Sie die Eigenschaften der Netzwerkumgebung auf, wählen die Karteikarte „Dienste“ und klicken dann auf die Schaltfläche „Hinzufügen“:
Klicken Sie dann auf OK, um den Dienst hinzuzufügen. Die Karteikarte „Dienste“ hat nun folgendes Aussehen:
Funktionskontrolle: In der Netzwerkumgebung sehen Sie jetzt auch den WIFI-Server bzw. unter dem Eintrag „Gesamtes Netzwerk“ sehen Sie auch Netware-kompatible Netzwerke.
Nun können Sie den im Lehrsaal befindlichen Netzwerkdrucker
installieren!
2.
Herstellung der
Anbindung ans Internet:
Um die Anbindung an den WIFI-internen Internet-Linux-Server zu erhalten, sind folgende Einträge notwendig:
|
Klicken Sie in den Eigenschaften der Netzwerkumgebung auf die Karteikarte „Protokolle“ und wählen Sie das TCP/IP-Protokoll aus. Klicken Sie dann auf die Schaltfläche „Eigenschaften“ und stellen Sie folgendes ein: |
Der Internet-Server-Administrator des WIFI hat auf dem Linux-Server ein Routing für folgenden Adressbereich eingetragen: 192.168.201.100 192.168.201.101 .... 192.168.201.115 Als Gateway dient die Adresse 192.168.201.1 |
|
Nun fehlt noch ein Eintrag für den Domain Name Server. Klicken Sie dazu auf die Karteikarte „DNS“. Dort klicken Sie auf „Hinzufügen“ und tragen die Adresse des DNS-Servers ein.
(Anmwerkung: Im WIFI sind zwei DNS-Server definiert:
194.96.13.3 und
194.96.13.4 )
Dann fahren Sie den Rechner wieder hoch und probieren aus, ob Sie den eben installierten WIFI-Gateway nützen können, um im Internet zu surfen!
3. Office-Installation (Word, Access):
CD-Key für
Office 97: 0401-0990811
Starten Sie den NT-Explorer und wählen Sie [Extras]-[Netzlaufwerk verbinden]:
Verbinden Sie sich zur Ressource \\WIFI2\\SW_Tank:
Sie können jetzt auf die im Netzwerk befindlichen
Ressourcen zugreifen, unter anderem auf die CDs von Office 97 und
Office 2000.
Domain Name Service (DNS): Zuordnen von Computernamen zu
IP-Adressen
(a)
über einen DNS-Server
(b)
dynamisch:
DHCP-Server nötig (DHCP = dynamic host configuration protocol)
(c)
Statisch (machen wir im Kurs):
Datei HOSTS
im Verzeichnis
\WINNT\SYSTEM32\DRIVERS\ETC
bearbeiten mit Editor.
# Copyright (c)
1993-1995 Microsoft Corp.
#
# This is a
sample HOSTS file used by Microsoft TCP/IP for Windows NT.
#
# This file
contains the mappings of IP addresses to host names. Each
# entry should
be kept on an individual line. The IP address should
# be placed in
the first column followed by the corresponding host name.
# The IP
address and the host name should be separated by at least one
# space.
#
# Additionally,
comments (such as these) may be inserted on individual
# lines or
following the machine name denoted by a '#' symbol.
#
# For example:
#
# 102.54.94.97 rhino.acme.com
# source server
# 38.25.63.10 x.acme.com
# x client host
127.0.0.1 localhost
192.168.0.1
ilg.at
Diese Datei ordnet jeder IP-Adresse einen DNS-Namen (“friendly name”) zu.
Im selben Verzeichnis befindet sich auch die LMHOSTS-Datei, die die Zuordnung von IP-Adressen zu NetBIOS-Namen regelt (NetBIOS-Namen werden als “PC-ID” von Win NT standardmäßig verwendet).
Wichtig: Jeder PC im Intranet muss dieselbe HOSTS-Datei bekommen, da sonst der Server nicht mit dem friendly name angesprochen werden kann. (Also: Datei auf jeden PC im Netz kopieren!!!)
Diagnose- und Konfigurationsprogramme
1. PING:
Versucht, 4
IP-Pakete an einen Host-Rechner zu senden. Zweck: Überprüfung der
Funktionsfähigkeit von Netzwerkverbindungen.
C:\WINDOWS>ping 10.0.0.6
Ping wird ausgeführt für 10.0.0.6 mit 32 Bytes Daten:
Antwort von 10.0.0.6: Bytes=32 Zeit<10ms TTL=128
Antwort von 10.0.0.6: Bytes=32 Zeit<10ms TTL=128
Antwort von 10.0.0.6: Bytes=32 Zeit<10ms TTL=128
Antwort von 10.0.0.6: Bytes=32 Zeit<10ms TTL=128
Ping-Statistik für 10.0.0.6:
Pakete:
Gesendet = 4, Empfangen = 4, Verloren = 0 (0% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum =
0ms, Maximum = 0ms, Mittelwert = 0ms
2.
IPCONFIG:
Gibt Informationen über die Windows IP-Konfiguration aus.
Parameter: /ALL gibt auch Informationen über die MAC-Adresse aus.
Beispiel 1:
Ausgabe ohne Parameter /ALL
Windows 98 IP-Konfiguration
0 Ethernet Adapter :
IP-Adresse. . . . . . . . . : 0.0.0.0
Subnet
Mask . . . . . . . . : 0.0.0.0
Standard-Gateway . . . . . . :
1 Ethernet Adapter :
IP-Adresse. . . . . . . . . : 10.0.0.6
Subnet
Mask . . . . . . . . : 255.0.0.0
Standard-Gateway . . . . . . : 193.170.244.18
Beispiel 2:
Ausgabe mit Parameter /ALL
Windows 98 IP-Konfiguration
Hostname .
. . . . . . . . : KKTN.noe.wifi.at
DNS-Server . . . . . . . . : 194.96.13.3
194.96.13.5
Knotentyp .
. . . . . . . . : Broadcast
NetBIOS-Bereichs-ID . .
. . :
IP-Routing aktiviert. . . . : Nein
WINS-Proxy aktiviert. . . . : Nein
NetBIOS-Aufl”sung mit DNS . : Nein
0
Ethernet Adapter :
Beschreibung. . . . . . . . : PPP Adapter.
Physische Adresse . . . . . :
44-45-53-54-00-00
DHCP aktiviert. . . . . . . : Ja
IP-Adresse. . . . . . . . . : 0.0.0.0
Subnet Mask
. . . . . . . . : 0.0.0.0
Standard-Gateway
. . . . . . :
DHCP-Server
. . . . . . . . : 255.255.255.255
Erster WINS-Server . . .
. :
Zweiter WINS-Server . . . :
Gültig seit. . . . . . . :
Gültig bis . . . . . . . :
1
Ethernet Adapter :
Beschreibung. . . . . . . . : PPP Adapter.
Physische Adresse . . . . . :
44-45-53-54-00-01
DHCP aktiviert. . . . . . . : Ja
IP-Adresse. . . . . . . . . : 0.0.0.0
Subnet Mask
. . . . . . . . : 0.0.0.0
Standard-Gateway
. . . . . . :
DHCP-Server
. . . . . . . . : 255.255.255.255
Erster WINS-Server . . .
. :
Zweiter WINS-Server . . . :
Gültig seit. . . . . . . :
Gültig bis . . . . . . . :
2
Ethernet Adapter :
Beschreibung. . . . . . . . : Novell 2000
Adapter.
Physische Adresse . . . . . :
00-00-E8-2F-15-FA
DHCP aktiviert. . . . . . . : Ja
IP-Adresse. . . . . . . . . : 194.96.13.190
Subnet Mask
. . . . . . . . : 255.255.255.0
Standard-Gateway
. . . . . . : 194.96.13.1
DHCP-Server
. . . . . . . . : 194.96.13.8
Erster WINS-Server . . .
. :
Zweiter WINS-Server . . . :
Gültig seit. . . . . . . : 09.05.00 09:35:26
Gültig bis . . . . . . . : 09.05.00 09:45:26
3. WINIPCFG:
Am besten über [Start] – [Ausführen] aufrufen.
4.
TRACERT:
4.
Zeigt die Route eines IP-Pakets an.
Syntax:
TRACERT [-d] [-h Abschnitte max] [-j Host-Liste] [-w Timeout] Zielname
Options:
-d
Adressen nicht zu
Hostnamen auswerten.
-h Abschnitte max Max. Anzahl an Abschnitten bei Zielsuche.
-j Host-Liste "Loose Source Route" gemäß Host-Liste.
-w Timeout Timeout in Millisekunden für eine Antwort.
Beispiel:
Route-Verfolgung
zu www.yahoo.akadns.net [216.32.74.52]
über
maximal 30 Abschnitte:
1
2 ms 3 ms 3 ms
vianet-stpolten-gw01.via.at [194.96.211.18]
2
5 ms 5 ms 6 ms
vianet-stpolten-gw00.via.at [194.96.211.17]
3
16 ms 32 ms 12 ms
vianet-head-gw04.via.at [194.96.210.5]
4
22 ms 23 ms 14 ms
atlas-atm4-1-0-460.uta.at [195.70.250.101]
5
22 ms 15 ms 16 ms
kronos-atm9-0-0-597.uta.at 212.152.192.245]
6
31 ms 32 ms 29 ms
164.128.33.89
7
31 ms 32 ms 37 ms
i79zhh-035-FastEthernet6-1-0.ip-plus.net [164.128.36.67]
8
120 ms 186 ms 126 ms
i00ny-015-Pos0-0-0.ip-plus.net [164.128.35.118]
9
537 ms 120 ms 121 ms
exodus-nyc.ip-plus.net [164.128.236.46]
10
121 ms 154 ms 136 ms
bbr02.g3-0.jrcy01.exodus.net [209.67.45.254]
11
129 ms 127 ms 135 ms
bbr01-p5-0.stng01.exodus.net [209.185.9.98]
12
130 ms 129 ms 162 ms
dcr03-g9-0.stng01.exodus.net [216.33.96.145]
13
129 ms 131 ms 178 ms
216.33.98.18
14
128 ms 134 ms 173 ms
216.35.210.122
15
136 ms 132 ms 128 ms
www.yahoo.akadns.net [216.32.74.52]
Route-Verfolgung
beendet.
5. ARP
(Adress Resolution Protocol):
Ändert und zeigt die Übersetzungstabellen für IP-Adressen/physische
Adressen an, die vom ARP (Address Resolution Protocol) verwendet werden.
Parameter:
ARP -s IP_Adr Eth_Adr
[Schnittst]
ARP -d IP_Adr
[Schnittst]
ARP -a [IP_Adr] [-N
Schnittst]
-a Zeigt aktuelle ARP-Einträge durch Abfrage der Protokoll-
daten an. Falls IP_Adr
angegeben wurde, werden die IP- und
physische Adresse für den
angegebenen Computer angezeigt.
Wenn mehr als eine
Netzwerkschnittstelle ARP verwendet,
werden die Einträge für jede
ARP-Tabelle angezeigt.
-g Gleiche Funktion wie -a.
IP_Adr
Gibt eine Internet-Adresse an.
-N Schnittst Zeigt die ARP-Einträge für die angegebene Netzwerk-
schnittstelle an.
-d Löscht den durch IP_Adr angegebenen Host-Eintrag.
-s Fügt einen Host-Eintrag hinzu und ordnet die
Internet-Adresse
der physischen
Adresse zu. Die physische Adresse
wird durch
6 hexadezimale, durch Bindestrich
getrennte Bytes angegeben.
Der Eintrag ist permanent.
Eth_Adr Gibt eine physische Adresse (Ethernet-Adresse) an.
Schnittst Gibt, falls vorhanden, die Internet-Adresse der
Schnittstelle
an, deren Übersetzungstabelle
geändert werden soll.
Sonst wird die erste geeignete
Schnittstelle verwendet.
Beispiel:
> arp -s 157.55.85.212 00-aa-00-62-c6-09 .... Fügt einen statischen Eintrag
hinzu.
> arp -a .... Zeigt die Arp-Tabelle an.
6. NETSTAT
Zeigt bestehende Netzwerkverbindungen an.
Beispiel für netstat:
C:\WIN98>netstat
Aktive
Verbindungen
Proto Lokale Adresse
Remote-Adresse Status
TCP nr:1026 I406:nbsession ESTABLISHED
TCP nr:1037 www.browser.at:80 ESTABLISHED
TCP nr:1045 WWWIFI:80 ESTABLISHED
7. ROUTE
Manipulation und Anzeige der Routingtabelle des Betriebssystems.
Beispiel für route:
C:\WIN98>route
print
Aktive
Routen:
Netzwerkadresse Subnet Mask
Gateway-Adresse Schnittstelle Anzahl
0.0.0.0 0.0.0.0
192.168.2.100 192.168.2.104 1
127.0.0.0 255.0.0.0
127.0.0.1 127.0.0.1 1
192.168.2.0 255.255.255.0
192.168.2.104 192.168.2.104 1
192.168.2.104 255.255.255.255
127.0.0.1 127.0.0.1 1
192.168.2.255 255.255.255.255
192.168.2.104 192.168.2.104 1
224.0.0.0 224.0.0.0
192.168.2.104
192.168.2.104 1
255.255.255.255 255.255.255.255
192.168.2.104 0.0.0.0 1
C:\WIN98>
Der Internet Information Server
Wählen Sie Start – Programme – Windows NT 4.0 Option Pack
– Microsoft Internet Information Server – Internet-Dienstmanager.
Es wird die Microsoft
Management Konsole (MMC.EXE) aufgerufen. Die MMC ist ein allgemeines
Werkzeug zur Verwaltung von Serverdiensten; sie wird in Windows 2000 zu einem
zentralen Administrationstool.
Die Konsole kann mit sogenannten “Snap-Ins” für verschiedene Administrationsaufgaben konfiguriert werden (Menü [Konsole]-[Snap-In hinzufügen/löschen] bzw. Strg-M); die Einstellungen werden in Konfigurationsdateien gespeichert.
Ruft man den Internet-Dienstmanager auf, so wird bereits eine vorkonfigurierte Einstellung (Datei IIS.MSC) aufgerufen, die die Administration der Internet-Serverdienste stark vereinfacht.
FTP-Server einrichten und testen
FTP
von der Serverseite aus gesehen – Einrichten und Konfigurieren des FTP-Dienstes
im Internet Information Server:
Schritt 1:
Es ist oft sinnvoll, einen Webauftritt eines Kunden über eine eigene IP-Adresse zu realisieren. Dazu muss es aber möglich sein, der Netzwerkkarte des Webservers mehrere IP-Adressen zuzuweisen. Dies realisiert man in den erweiterten TCP/IP-Einstellungen:
Start - Einstellungen - Systemsteuerung - Netzwerk - Protokolle - TCP/IP-Protokoll - Optionen - Hinzufügen - IP-Adresse eingeben
Nicht vergessen: auch in der HOSTS-Datei eintragen!
Im Explorer (inetpub) root-Verzeichnis anlegen.
In diesem Beispiel:
C:\INetPub\Kunde1_101
Schritt 3:
Klicken Sie mit der rechten Maustaste auf den Servernamen (in der Abbildung etwa *nt701) und wählen Sie aus dem Kontextmenü [Neu]-[FTP-Site].
Schritt 4:
Start - Programme - Verwaltung (allgemein) - Benutzermanager für Domänen
Benutzer - Neu - Ausfüllen - Einstellungen vornehmen - Hinzufügen
Richtlinien - Benutzerrechte - lokale anmeldung wählen - Hinzufügen –
Benutzer anzeigen - auswählen - ok
Schritt 5:
Start - Programme - NT Éxplorer - Kundenverzeichnis auswählen - rechte Maustaste - Eigenschaften - Sicherheit - Berechtigungen
„Berechtigungen für existierende Dateien ersetzen“ auswählen:
Einstellungen vornehmen
Management Konsole – Kontextmenü des FTP-Dienstes des neuen Kunden auswählen - Eigenschaften - Sicherheitskonten – „Nur anonyme Verbindungen erlauben“ deaktivieren
FTP
von der Anwenderseite aus gesehen – FTP-Server testen:
Mit FTP können Sie Dateien von Ihrem Rechner auf einen entfernten Server übertragen (Upload) oder von einem entfernten Server Dateien auf Ihren Rechner laden (Download).
Der FTP-Dienst ist auf verschiedene Art und Weise nutzbar:
a) FTP-Programme:
Beispiele:
Es soll hier das Programm WS-FTP95 kurz erläutert werden:
1. Starten Sie das Programm WS-FTP95
2. Legen Sie ein Profil mit folgenden Einträgen an (Klicken Sie auf die Schaltfläche „New“):
3. Mit "OK" verbinden Sie sich zum PIAKREMS-FTP-Server: Links sehen Sie die Verzeichnis-/Laufwerksstruktur Ihres eigenen Rechners, rechts sehen Sie die Verzeichnisstruktur des FTP-Servers, mit dem Sie verbunden sind.
4. Mit den Pfeilen in der Mitte können Sie markierte Dateien von Ihrer Festplatte (links) auf den Server (rechts) kopieren oder umgekehrt!
b) Manuelle
FTP-Sitzung:
Aufruf:
ftp Servername
FTP-Befehle:
! delete literal prompt
send
? debug ls
put status
append
dir mdelete pwd trace
ascii
disconnect mdir quit type
bell
get mget quote user
binary
glob mkdir recv verbose
bye
hash mls remotehelp
cd
help mput rename
close
lcd open rmdir
dir remote Verzeichnis auflisten
cd, lcd Verzeichnis wechseln, remote / local
pwd aktuelles Verzeichnis
get, mget Datei/en von remote nach local kopieren
put, mput Datei/en von local nach remote kopieren
binary auf binären Transfer (Programme, Images, ...) umschalten
prompt Bestätigung abschalten
user als Benutzer einloggen
open, close Verbindung öffnen / schließen
? Hilfe anzeigen
quit, bye Programm beenden
Beispiel für
eine manuelle FTP-Sitzung (Benutzereingaben sind fett dargestellt):
C:\WIN98>ftp
off97.noe.wifi.at
Verbindung
mit off97.noe.wifi.at.
220 wifi2 Microsoft FTP Service (Version 3.0).
Benutzer (off97.noe.wifi.at:(none)): user401
331 Password required for user401.
Kennwort:****
230-Herzlich
Willkommen am Wifi Ftp-Server !
230 User user401 logged in.
Ftp> dir
200 PORT command successful.
150 Opening ASCII mode data connection for /bin/ls.
d--------- 1
owner group 0 Aug 19
1999 kids
d--------- 1
owner group 0 Feb 17
1998 kktn
---------- 1
owner group 0 Aug 18
1999 test.txt
---------- 1
owner group 0 Aug 19
1999 test3.txt
226 Transfer
complete.
Ftp: 269
Bytes empfangen in 0.16Sekunden 1.68KB/Sek.
Ftp> get
test.txt
200 PORT command successful.
150 Opening ASCII mode data connection for test.txt(0
bytes).
226 Transfer complete.
Ftp> put
xxx.htm
200 PORT command successful.
150 Opening ASCII mode data connection for xxx.htm.
226 Transfer
complete.
Ftp: 1777
Bytes gesendet in 0.00Sekunden 1777000.00KB/Sek.
Ftp> pwd
257 "/" is current directory.
Ftp> quit
221 Auf
Wiedersehen !
Wenn Sie als anonymer FTP-Nutzer arbeiten wollen, so geben Sie als Benutzername anonymous an, als Kennwort Ihre eigene E-Mail-Adresse. (Es ist kein Passwort nötig, allerdings verlangen die Regeln der Netiquette eine derartige – freiwillige! – Identifizierung.)
c) FTP über den
Browser:
Auch über Browser-Software ist eingeschränkter FTP-Betrieb möglich: Während Downloads problemlos möglich sind, können Uploads nicht durchgeführt werden!
Wichtig: Sollten Sie für den FTP-Server einen Benutzernamen und ein Kennwort eingeben müssen, dann wählen Sie bitte folgende Syntax für die Adresszeile des Browsers:
ftp://Benutzername:Kennwort@ftpserver.at
(Anmerkung: Das Passwort in der obigen Abbildung wurde abgedeckt bzw. verändert.)
Der WWW-Dienst im IIS
Zunächst legt man für den Kunden einen virtuellen Webserver (Website) an:
Besitzt man mehrere IP-Adressen, so kann man damit „handeln“, d.h. der Webseite eines Kunden eine eigene IP-Adresse zuweisen.
Dafür gibt es mehrere Varianten:
a)
Zuordnung in der HOSTS-Datei:
192.168.2.229 501_k1.ilg.edu
192.168.2.229 501_k2.ilg.edu
b)
Host-Header-Name im IIS:
Dem Kunden wird zunächst eine eigene Seite mit eigener IP-Adresse zugewiesen.
Klick auf „Erweitert“ liefert die Möglichkeit, dieser Seite einen oder mehrere „Host-Header-Namen“ zuzuweisen.
Es ist also denkbar, ein und dieselbe Webseite mit mehreren Domain-Namen aufzurufen. (Ältere Browser unterstützen diese Funktion allerdings nicht!)
Schutz von Kindern und
Jugendlichen durch RSACi-Filter und PICS-Labels
Quellen:
www.rsac.org oder www.icra.org
|
RSACi = Recreational
Software Advisory Council for the Internet Das RSACi-System ist ein Filtersystem für jugendgefährdende Inhalte im Web, das von der ICRA (Internet Content Rating Association) verwaltet wird. Ziel dieses Systems ist die Gewährleistung der „Redefreiheit“ im Internet einerseits, der Schutz von Kindern und Jugendlichen vor gefährlichen oder anstößigen Inhalten andererseits. Das RSACi-System ist im Internet Explorer integriert. Eltern können – gesichert durch ein Supervisor-Kennwort – den Level bestimmen, der angezeigt werden soll. |
Für jeden RSACi-Label gibt es vier Sicherheitsstufen:
|
Gewalt |
Nacktheit |
Sex |
Sprache |
Level 4 |
Vergewaltigungen oder willkürliche, brutale Gewaltakte |
provozierende Nacktaufnahmen, von vorn fotografiert |
Sexualverbrechen oder brutale, deutliche sexuelle Vorgänge |
Rohe, vulgäre Sprache, freizügige sexuelle Anspielungen |
Level 3 |
Aggressive Gewalt oder Töten von Menschen |
Vollständige Nacktheit, von vorn fotografiert |
Sexuelle Vorgänge |
Deftige, vulgäre oder hasserfüllte Sprechweise; obszöne Kraftausdrücke |
Level 2 |
Zerstörung realistischer Objekte |
Teilweise Nacktheit |
Sexuelle Berührungen im bekleideten Zustand |
Kraftausdrücke; nicht sexuell bezogene anatomische Anspielungen |
Level 1 |
Verletzen von Menschen |
Aufreizende Bekleidung |
Leidenschaftliche Küsse |
Schwache Kraftausdrücke, milde Ausdrücke für Körperfunktionen |
Level 0 |
Keine der obigen oder im Zusammenhang mit Sport |
Keine der obigen |
Keine der obigen oder “unschuldige” Küsse; Romantik |
Keine der obigen |
ICRA
at a glance
The Internet Content Rating Association is an international,
independent, non-profit organization with offices in Washington, D.C, USA and
Brighton, UK, that empowers the public, especially parents, to make informed
decisions about electronic media by means of an open, objective, content
advisory system. The RSACi system managed by ICRA provides consumers with
information about the level of sex, nudity, violence, offensive language
(vulgar or hate-motivated) in Web sites. To date, RSACi has been integrated
into Microsoft's browser, Internet Explorer, and MicroSystem's Cyber Patrol
Software. CompuServe (US and Europe) has also committed to rate all its content
with the RSACi system.
Rating The Web
Our aim in creating RSACi (RSAC on the Internet) was to provide a
simple, yet effective rating system for web sites which both protected children
and protected the rights of free speech of everyone who publishes on the World
Wide Web.
Parental Controls
We also designed a system based on the tried and tested content advisory
system used for computer games and one which could be simply understood and set
by parents at either the browser level (eg. Microsoft's Internet Explorer 3.0x)
or blocking device (eg. CyberPatrol). We urge parents, educators and other
interested individuals to SET THE LEVELS at the growing number of browsers and
software devices that are designed to read the RSACi labels.
Content Providers
Another essential part of this highly ambitious task, is to encourage
internet content providers of all kinds to use our voluntary, self-disclosure
rating system. There are a number of compelling reasons why a provider or web
master would rate with RSACi, not least that it sends a clear signal to governments
around the world, that the World Wide Web is willing to self-regulate, rather
than have the heavy hand of government legislation decide what is or is not
acceptable.
Commercial Web Sites
Commercial sites, with little or no objectionable material will want to
rate. When a parent sets the levels for their child, they will also be offered
an option that says, "Do not go to unrated sites". Most sites want
the maximum number of visits to justify advertising or other related commercial
activity. It would make good marketing sense for all commercial sites to rate
whether or not they have any content that could be described as harmful.
Protecting Free Speech
RSACi has been an enthusiastic member of a number of initiatives that
would support the protection of free speech on the Web. We work closely with PICS, the Platform
for Internet Content Selection, based at MIT. This standard format provides us
the means by which our rating system can be read by browsers and selection
software around the world.
Setting The Levels
Please have a look at the table below. It gives you, at a glance, the
four categories of the RSACi system with the five levels and their descriptors.
It is these levels that parents and other interested individuals will set at
their browser or blocking device.
Further Information On Definitions
Definitions for RSACi Language
Questions
Definitions for RSACi Nudity
Questions
Definitions for RSACi Sex Questions
Definitions for RSACi Violence
Questions
·
PICS Rating Vocabularies in XML/RDF (W3C NOTE 27 March 2000)
·
Statement on Using PICS Well (1 June 1998)
·
PICS Signed Labels (DSig) 1.0
Specification (27
May 1998)
·
PICS Reference Code (2/98)
·
PICSRules Language for Writing
Filtering Rules; a
W3C Recommendation (12/97)
· Letter from Tim Berners-Lee to GILC about PICSRules. Tim Berners-Lee (12/97)
·
PICS and Intellectual Freedom FAQ. Paul Resnick. Updated filtering
section to include brief discussion of PICSRules. (updated 1/97)
·
PICSRules and Free Speech. Joseph Reagle. General comments and
Joseph's responses to posts on the fight-censorship mailing list. (12/97)
·
Free Java
implementation of
parsers for PICS labels, services, and rules, evaluator for PICSRules (12/97)
·
DSIG 1.0 specification for signing
PICS labels; a W3C Proposed Recommendation
(12/97)
·
SurfWatch available in PICS format. The PICS Application Incubator at The University of Michigan
School of Information has created a PICS label bureau to distribute SurfWatch
labels. (12/97)
·
IBM's PICS-compliant proxy server released (12/97)
·
Net Shepherd and Alta Vista offer filtered
Internet search
(11/97)
Information for
the Media
Press
inquiries about PICS should be directed to any of the following people:
·
Josef Dietl, W3C Communications, +33.4.92.38.79.72
Technical
inquiries to:
·
W3C PICS expert, (pics-ask@w3.org)
·
Ralph R. Swick, (swick@w3.org), W3C metadata lead. +
1.617.253.2613
Inquiries
about public policy issues surrounding content regulation may also be directed
to
·
Joseph Reagle (reagle@w3.org), W3C Policy Analyst. +
1.617.253.2613
·
Danny Weitzner, (djweitzner@w3.org), W3C Technology and Society Domain
Leader. + 1.617.253.2613
What others are
saying about PICS
Governments
·
European Commission Report (follow-on document
of 20 March, 1997)
·
Australian Broadcast Authority
report on its investigation into on-line services
·
European Union Communication on
illegal and harmful content on the Internet
·
Report of European Commission
Working party on illegal and harmful content on the internet
·
European Commission Forum for
Exchange of Information on Internet Best Practices
Media
·
PICS Walks Fine Line on Net
Filtering
·
Good Clean PICS: The most effective
censorship technology the Net has ever seen may already be installed on your
desktop (Simson
Garfinkel in HotWired: February 1997)
·
College Hill interview with Joseph Reagle, W3C
staff member
Individuals and
Organizations
·
EFF's Draft Policy on public interest
principles for online filtration, ratings, and labeling systems. Suggested guidelines for
responsible use of labeling and filtering.
·
The Internet Filter Assessment
Project. A group of
librarians with mixed feelings about filtering examined several products in
detail and discussed the issues facing libraries.
·
ACLU White Paper Critical of
Labeling and Filtering
·
PICS-Aware Proxy System vs. Proxy
Server Filters.
Wayne Salamonsen and Roland Yeo, proceedings of INET '97.
·
Metadata, PICS and Quality. Chris Armstrong. Ariadne magazine,
May 1997.
·
Rating the Net. Jonathan Weinberg. in Hasting
Communications and Entertainment Law Journal, Vol. 19, No. 2, p. 453-482. (A
balanced but critical academic's look at rating systems and their legal and
social impact.)
·
The Net Labeling Delusion (anti-PICS web site in Australia)
·
Fight-censorship mailing lists (Declan McCullagh's moderated and
unmoderated lists; occasional discussion of PICS and related technologies).
__________
PICS Technical
Specifications
Completed
Specifications for PICS-1.1
These are
official W3C recommendations. They are stable.
1.
Service descriptions: Specifies the format for describing a rating
service's vocabulary and scales; analogous to a database schema.
2.
Label format and
distribution: Specifies the format of labels and
methods for distributing both self-labels and third-party labels.
3.
PICSRules: Specifies an interchange format for filtering preferences, so that
preferences can be easily installed or sent to search engines.
These are proposed
W3C recommendations. They may still change.
4.
PICS Signed Labels (DSig) 1.0 Specification: Specifies
the syntax and semantics of digital signatures in PICS labels.
Special
Supplements to the Specifications
These are
not official W3C recommendations, but they do represent a consensus of the PICS
working group.
5.
Default and Override Labels: Specifies what a user agent (e.g.,
filtering software) should do when multiple labels are available from the same
service; Also suggests where filtering agents should look for self-labels if
they do not arrive in or along-with a document.
Resources for
Developers of Software and Labeling Services
There is a
low-volume mailing list, pics-interest@w3.org for developers and potential
developers of PICS related products and services. To join this list, send email
to pics-ask@w3.org and say why you're interested in joining.
Resources for Software
Developers
The technical
specifications
above are the most important resource for developers. In addition:
·
Free Java
implementation of
parsers for PICS labels, services, and rules, evaluator for PICSRules
·
PICSLE, the PICS Label Editor, also written in Java,
provided courtesy of IBM T.J. Watson Research Center.
·
IBM's PICS-compliant proxy server makes it easy to set up a label
bureau against which you can test clients.
·
Protocol extensions. These are extensions that people
have defined using the extension mechanisms provided in the technical
specifications.
·
Various
tools and free technical advice available from the PICS Application Incubator project at the University of
Michigan School of Information.
·
W3C's
Amaya browser will soon have PICS client features integrated, against which you
will be able to test PICS-compatible server products. Please check back.
Resources for
Labeling Service Developers
To start a
new labeling service, you will need to take the following steps:
1.
Decide
who will assign labels.
·
Web
site operators who self-label and/or
·
A
panel of raters that you recruit and/or
·
A
computer program that analyzes the contents of materials and assigns labels
2.
Decide
the labeling vocabulary and criteria
3.
Express
the labeling vocabulary and criteria according to the format specified in the technical specification. You can create this file from
scratch, or you can fill out web forms at the PICS Application Incubator and the file will be created for
you.
4.
Create
the labels
5.
Arrange
for distribution of your labels
·
Give
your labels to someone else who is running a PICS label bureau and/or
·
Run
your own PICS label bureau and/or
·
Convince
web site operators to distribute the labels for their own pages, either by
putting them into HTML META tags or sending them along with web pages.
The PICS Application Incubator project at the University of
Michigan School of Information will provide a limited amount of free technical
consulting to organizations that are considering establishing new labeling
services.
Lists of
PICS-compatible products and services.
Technology Inventory. Lorrie Cranor and Paul Resnick.
This inventory was first distributed at the December 1997 Internet On-line
summit: Focus on Children. The on-line version was updated until the summer of
1999. It also lists some products and services that are not PICS-compatible.
The
following resource lists are being maintained by members of the PICS
developers' community. Contact the maintainer of each individual list with
additional links. The maintainers have all agreed to be fast and fair in
maintaining these lists (please send any unresolved complaints to
pics-ask@w3.org).
·
Client software that reads PICS labels.
·
HTTP servers that distribute labels along with
documents.
·
Proxy servers that perform filtering based on
PICSRules.
·
Label bureaus: HTTP servers that distribute third-party PICS
labels through the PICS label bureau query protocol.
·
more information "for families and caregivers" from GetNetWise
Innovative Uses of
PICS Labels
The most
common uses of PICS labels have been in filtering products that block access to
certain materials based on labels associated with those materials. The technology inventory, however, identifies a range of
other actions that can be taken based on labels: suggest, search, inform,
monitor/log, and warn.
·
Inform:
med-PICS; a
collaboration for critical appraisal of medical information on the Internet
·
Search:
Net Shepherd and Alta Vista offer filtered Internet search
·
Inform:
Alexa Internet
displays PICS labels visually, but does not block access based on those labels.
·
Inform:
The Test-a-URL feature created by the PICS Application Incubator lets you see what labels have been
assigned to any URL by several different rating services. (A similar test-a-URL feature is available for other, non
PICS-based services.)
Hints for Web Site
Authors Who Want to Self-Label
Many
authors and web site operators offer materials that they realize will not be
appropriate for all audiences. We encourage them to label their materials to
make it easier for filtering software to block access. As an added inducement
to labeling, we note that some future applications may use labels for searching
as well as filtering. Thus, labeling your site will make it easier both for
some audiences to avoid your site or documents and for others to find you.
PICS is
able to remain value-neutral by refusing to endorse any particular labeling
vocabulary. As a web site operator, you will not have that luxury. You'll want
to adopt one or more of the rating vocabularies that other sites are using. You
may want to use one of the self-rating vocabularies.
Once you
have created a label, you will need to distribute it along with your document(s).
PICS has defined several ways to do that. The recommended method, if your HTTP
server allows it, is to insert an extra header in the HTTP header stream that
precedes the contents of documents that are sent to web browsers. The correct
format, as documented in the specifications, is to include the two headers,
Protocol and PICS-Label:
HTTP/1.0
200 OK
Date: Thu, 30 Jun 1995 17:51:47 GMT
Last-modified: Thursday, 29-Jun-95 17:51:47 GMT
Protocol: {PICS-1.1 {headers PICS-Label}}
PICS-Label:
(PICS-1.1 "http://www.gcf.org/v2.5" labels
on "1994.11.05T08:15-0500"
exp "1995.12.31T23:59-0000"
for "http://www.greatdocs.com/foo.html"
by "George Sanderson, Jr."
ratings (suds 0.5 density 0 color/hue 1))
Content-type: text/html
...contents
of foo.html...
The server
can send these headers even if the browser has not specifically request them.
The next
best method is to run a label bureau at a specific location on your server, as
specified in a supplement to the PICS specs, distributing labels only
for documents on your server.
If neither
of these methods is not available to you, a simpler but more limited method is
to embed labels in HTML documents using a META tag. With this method, you will
be able to send labels only with HTML documents, not with images, video, or
anything else. You may also find it cumbersome to insert the labels into every
HTML document. Some browsers, notably Microsoft's Internet Explorer versions 3
and 4, will download the root document for your web server and look for a
generic label there. For example, if no labels were embedded in the HTML for
this web page (they are), Internet Explorer would look for a generic label
embedded in the page at http://www.w3.org/ (generic labels can be found there).
Be sure to read the supplement for information on when specific labels
override generic labels and when they don't.
The
following is a an example of the right way to embed a PICS label in an HTML
document:
RIGHT!
<head>
<META http-equiv="PICS-Label" content='
(PICS-1.1 "http://www.gcf.org/v2.5"
labels on "1994.11.05T08:15-0500"
until "1995.12.31T23:59-0000"
for "http://w3.org/PICS/Overview.html"
ratings (suds 0.5 density 0 color/hue 1))
'>
</head>
...contents of document here...
SSL und HTTPS
Die Sicherheit der Datenübertragung über das Internet lässt sich deutlich erhöhen, wenn die Dateien nicht im Klartext übertragen werden, sondern durch Verschlüsselungsalgorithmen unlesbar gemacht werden.
(Quelle:
Microsoft Hilfe)
Man unterscheidet zwei Gruppen von Verschlüsselungsverfahren:
· Symmetrische Verfahren: Hier wird derselbe Schlüssel zur Ver- und Entschlüsselung verwendet.
· Asymmetrische Verfahren: Hier werden zwei verschiedene Schlüssel verwendet, ein „öffentlicher Schlüssel“ (public key) und ein „privater Schlüssel“ (private key).
(Quelle: Microsoft Hilfe)
Der MS Certificate Server ist im MS Option Pack für Windows NT 4.0 enthalten, wird aber standardmäßig nicht mitinstalliert. Er muss entweder nachinstalliert werden, oder wurde bereits mit der Vollinstallation des Option Packs mitinstalliert.
Der MS Certificate Server erzeugt Zertifikate im X.509-Format.
Bei der Installation des Zertifikatsservers wird ein “Notar”
installiert, der selbst Zertifikate ausstellen kann. Ein solcher “Notar”
(Zertifizierungsinstanz, englisch Certificate
Agency, CA) benötigt selbst nur ein sogenanntes Basiszertifikat. Solche
Zertifikate gelten als “absolut vertrauenswürdig” und werden durch keine
weitere Instanz bestätigt. Basiszertifikate haben international natürlich nur
dann Gewicht, wenn die Organisation einen hohen Bekanntheitsgrad bzw. ein hohes
Vetrauen des Publikums genießt.
Möchte man eine Seite international gültig zertifizieren
lassen, so gibt es dazu anerkannte Zertifizierungsinstitute:
Ab jetzt ist es möglich, Schlüssel zu erstellen, die vom
eben installierten Zertifikatsserver “signiert” werden können.
Das Eigenzertifikat wird im angegebenen Freigabeordner
(hier: C:\cert) abgelegt:
Überprüfen der Schlüsselkonfiguration:
C:\>certutil -dump
Eintrag 0:
Name: 'WIFI'
Organisationseinheit: 'EDV'
Organisation: 'WIFI Niederoesterreich'
Ort: 'St. Poelten'
Bundesland: 'Niederoesterreich'
Land: 'AT'
Konfiguration: 'I1\WIFI'
Austauschzertifikat: 'I1_WIFI_Exchange.crt'
Signaturzertifikat: 'I1_WIFI.crt'
Beschreibung: 'Test-Instanz'
Erstellen eines
eigenen Schlüssels:
Der nächste Schritt ist die Erstellung eines eigenen
Schlüsselpaares. Der Schlüssel muss natürlich von einer
Zertifizierungsinstitution bestätigt werden. Wir könnten die Anforderung
entweder an Verisign schicken oder von unserem eigenen Zertifizierungsserver
bestätigen lassen.
Rufen Sie dazu von der Microsoft Management-Konsole aus den Schlüssel-Manager auf:
Klicken Sie den abzusichernden Dienst (im allgemeinen: WWW)
mit der rechten Maustaste an und wählen Sie [Neuen Schlüssel erstellen...]
Wir haben nun folgende Situation: Es wurde ein Schlüssel
erstellt, der bereits zur Bestätigung der Zertifizierungsinstanz ist.
Gleichzeitig wurde der Schlüssel in einer Zertifizierungsanforderungsdatei
gespeichert, in unserem Fall c:\101ilg.txt.
Diese Datei sieht folgendermaßen aus:
Als nächster Schritt wird die Anforderung an der Zertifikatsserver
geschickt (wir verwenden unseren eigenen), der eine Bestätigung (digitale
Signatur) durchführen soll. Dafür gibt es vorinstallierte Hilfsprogramme,
aufrufbar unter http://IP-Adresse/certsrv:
Kennwort eingeben (dasselbe wie bei der Erzeugung des
Schlüssels)
Nun ist der Schlüssel vollständig und kann verwendet werden.
Absichern eines
Verzeichnisses durch SSL:
Vorbereitung: Erstellen Sie ein Verzeichnis unterhalb eines
virtuellen Servers eines Kunden. Legen Sie eine HTML-Datei in dieses
Verzeichnis.
Im folgenden Beispiel wurde unterhalb des virtuellen
WWW-Servers Kunde1_i1_WWW ein Verzeichnis verz angelegt, das eine Datei
ssltest.htm enthält.
Rufen Sie die Eigenschaften des abzusichernden
Verzeichnisses im IIS (MMC) auf, dann wählen Sie die Karteikarte
“Verzeichnissicherheit”. Dort klicken Sie im Abschnitt “Sichere Kommunikation”
auf die Schaltfläche “Bearbeiten...”:
Nun muss noch eine Portnummer für die SSL-Kommunikation
vergeben werden, wir verwenden 443:
Tests:
Eingabe von http://.../ssltest.htm
schlägt fehl.
Erst durch das Protokoll https://...
ist eine Anzeige der Datei möglich.
Arbeitsplan
Certificate Server
HTTPS - Secure socket layer
Schritt 3.0
· Certificate
Server von Option Disk installieren
·
CA-Zertifikat (Basiszertifikat, Sitezertifikat) erstellen
· Name der
Zertifizierungsinstanz: Elektronischer Notar x; "x" steht für den
Computernamen, z.B. 701
· Im
Anforderungsformular für das CA-Zertifikat dürfen keine Beistriche verwendet
werden. Beistriche werden als Feldende interpretiert und es wird eine ungültige
Anforderung ohne Fehlerwarnung erstellt.
· Überprüfen der
Konfigurationsinformation: CertUtil -dump; Gibt den Inhalt der Datei
CertSrv.txt aus.
· Browserinstallation des CA-Zertifikats
·
IE5.0: Extras, Internetoptionen, Inhalt, Zertifikate,
Vertrauenswürdige Stammzertifizierungsstellen.
·
Hinweise auf Registryeinträge
· HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\MachineKeys
·
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates
·
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet\Control\SecurityProviders
·
Ordner für Konfigurationsdateien: c:\mscf
· cacerts.htm:
Liste der Zertifikate der Zertifizierungsinstanz
· Internetdienstmanager
·
Schlüsselmanager
· WWW:
Rechtsklick - Neuen Schlüssel erstellen
·
Anforderung als Datei speichern, die an eine Instanz
gesendet wird: c:\Certs\NewKeyReq.txt. z.B. 701.ilg.edu.req.txt
·
Schlüsselname: Computername und key, z.B. 701key
·
Bei allgemeinem Namen IP-Adresse oder freindly Name angeben
·
c:\certs: certreq newkeyrq.txt neqkeyaw, z.B. 701.ilg.edu.aw
·
Schlüsselmanager: Schlüsselzertifikat intallieren
·
Verzeichnis mit Verzeichnissicherheit einrichten;
Registerkarte "Verzeichnissicherheit", Beim Zugriff auf diese Ressource sicheren Channel verlangen; mit
HTTPS anwählen
· Versuche
·
CA-Zertifikat ist nicht (im Browser) installiert: "Das
Sicherheitszertifikat wurde von einer Firma ausgestellt, die Sie nicht als
vertrauenswürdig eingestuft haben. Untersuchen Sie das Zertifikat, um
festzustellen, ob Sie der ausstellenden Institution vertrauen möchten.
·
Schloßsymbol in Statuszeile als Zeichen für sichere
Kommunikation.
Angaben bei
"Allgemeiner Name" stimmt nicht mit Namen bei DNS-Suchvorgang
überein. Meldung "Der auf dem Sicherheitszertifikat angegebene Name stimmt
nicht mit dem Namen der Site überein".