7. Networking

Inhalt:

7.1 Grundlagen

7.1.1 Grundlagen Networking

  1. Protokoll-Kapselung:

  2. Überblick:

  3. Ethernet: Medium Access Control (MAC)

  4. Internet Protokol: Rechner-Adressierung

  5. Transmission Control Protokoll (TCP): Dienst-Adressierung und Merkmale

7.1.2 Grundlagen TCP/IP

  1. Aufbau IP-Adresse: 32 bit, dotted quad, hex oder dezimal; 
     194.95.108.29      255.255.255.0       0xffffff00

  2. Aufteilung in Network- und Host-Bits wg. Verwaltung: Um bestimmte Adressräume einzelnen Firmen/Unis/... zuweisen zu können werden die höherwertigen Bits auf bestimmte Werte gesetzt (Network-Bits), die niederwertigeren Bits können selbst frei vergeben werden (Host-Bits). Zuweisung der Adressräume durch Provider. 

             +--------------------+--------------------+
   IPv4: |      n netbits     |   32-n  hostbits   |
         +--------------------+--------------------+
  
         +--------------------+--------------------+
   IPv6: |      n netbits     |  128-n  hostbits   |
         +--------------------+--------------------+

Netmask:  11111111111111111111 00000000000000000000
  3. Netzwerk- und Broadcast-Adresse: Zwei besondere Adressen um das Netzwerk selbst bzw. alle darin befindlichen Hosts anzusprechen. Netzwerk-Adresse: Alle Host-Bits auf 0, Broadcast-Adresse: alle Host-Bits auf 1.

  4. Netzmaske: Dient zum trennen von Netzwerk- und Host-Bits. Netzwerk-Bits werden auf 1 gesetzt, Host-Bits auf 0. Beispiel für Class B: 255.255.0.0 bzw. 0xffff0000.

    Mit Hilfe der Netzmaske kann aus einer IP-Adresse sehr schnell ermittelt werden, in welchem Netz diese Adresse liegt, wie die zugehörigen Netzwerk- und Broadcast-Adressen sind, und ob eine zweite IP-Nummer ggf. im selben Netz liegt. All dies ist mit einfachen UND- und ODER-Verknüpfungen möglich, siehe Quellcode von IP-Calc.

  5. Klassen:
    MSB Klasse #Hostbits Adressbereich #Mögliche Rechner
    0 A 24 1.0.0.0-127.0.0.0 16 Mio
    10 B 16 128.0.0.0-191.255.0.0 65.534
    110 C 8 192.0.0.0-223.255.255.0 256
    1110 D - 224.0.0.0-255.255.255.255 Special

    CIDR (Classless Inter Domain Routing) Schreibweise: a.b.c.d/anzahl netbits. Hier nicht weiter behandelt.

  6. Nicht geroutete Netze: Oft werden IP-Nummern für Testzwecke benötigt, oder weil "interne" Netze, die nicht an das Internet angeschlossen werden, mit Nummern versorgt werden sollen. Als Alternative, von einem Provider dafür IP-Nummern zu beziehen, existieren die folgenden Netze:

    Diese Netze sind per Definition (lt. RFC 1918) intern und werden nicht in andere Netze geroutet.

  7. Das Class A Netz 127.0.0.0 ist reserviert für Adressen auf dem lokalen Rechner, üblicherweise wird die Adresse 127.0.0.1 dem Loopback-Interface zugewiesen.

  8. Subnetting: Aufgrund von Limitierungen der unterliegenden Hardware können kaum 65000 oder gar 16 Mio Rechner an einem physikalischen Netzwerk betrieben werden, z.B. ist 10base2-(BNC)-Ethernet auf max. 185m ausgelegt. Deshalb kann man innerhalb seines eigenen "grosses" Netzwerke nochmals in kleinere Netze aufteilen, indem man eigene Netzwerk- und Host-Bits festsetzt. Dies geschieht durch Anpassung der Netzmaske, man spricht dabei von Subnetting.

    Beispiel: Das Class B Netzwerk (65534 mögliche Rechner, Netzmaske bei Class B: 255.255.0.0) soll in 256 Subnetze zerlegt werden. Für diese braucht man 8 Netzwerk-Bits, um die die Netzmaske erweitert wird: 255.255.255.0. In jedem Subnetz können dann nur noch 254 Rechner betrieben werden. Die Vergabe welcher Rechner in welchem Subnetz ist geschieht üblicherweise aufgrund der Netzwerk-Infrastruktur, kann aber auch organisatorisch geschehen (oft einhergehend mit einer getrennten Infrastruktur).

  9. Routing: Beispiel: Zwei Netze, 132.199.15.0, 132.199.1.0: 
    						   ...
						    |
					      188.1.230.101
                                ftp               cisco
                           132.199.1.202       132.199.1.8
 Subnet 132.199.1.0     \        |                  |
 Broadcast 132.199.1.255 >-------+--+---------------+------------
 Netmask 255.255.255.0  /           |
                               132.199.1.33
                                   rzi
                               132.199.15.1
                                    |          / Subnet 132.199.15.0
     ----+------------------+-------+---------<  Broadcast 132.199.15.255
         |                  |                  \ Netmask 255.255.255.0
   132.199.15.100      132.199.15.99
        dawn               dusk
    Hosts im Subnetz 132.199.15.0 können untereinander unter Zuhilfenahme des ARP-Protokolls kommunizieren. Mit Hilfe der Netzmaske wird geprüft, ob ein Host im selben Subnetz liegt. Falls dies nicht der Fall ist, so wird das Paket an einen Rechner weitergeleitet, der (hoffentlich) weiss, wie er den Zielrechner erreicht. Dieser Vermittlungsrechner wird als Router bezeichnet, er ist physikalisch an mehrere Netze angeschlossen, jedes Netzwerk-Interface hat eine IP-Nummer (und die zugehörige Netzmaske) aus dem jeweiligen Netz. Mit Hilfe dieser Angaben ist es einem Router möglich, Pakete passend weiterzuleiten.

    Am Netzwerk angeschlossene Rechner die ein Paket an einen Rechner ausserhalb des lokalen Subnetzes senden wollen ermitteln einen passenden Router, der die Daten in das Ziel-Netz weiterleiten kann. Bewerkstelligt wird dieser Auswahlprozess mit Hilfe der sog. Routing-Tabelle. Dabei handelt es sich um eine einfache Tabelle in der verzeichnet wird welches Netz (festgelegt durch die Netzwerk-Adresse und die dazugehörige Subnetzmaske) über welchen Router (festgelegt über dessen IP-Adresse im lokalen Netz) erreichbar ist.

    Findet ein Rechner (Router) keine passende Route für ein Paket, so ist üblicherweise noch eine Defaultroute (Netzwerk-Adresse: 0.0.0.0) eingetragen, die auf einen Router verweist, der sich des Pakets annehmen soll.

    Beispiel: Im o.g. Netz will der Rechner mit der IP-Nummer 132.99.15.99 den Rechner 132.199.1.202 erreichen. Mit Hilfe der Subnetzmaske stellt er zuerst fest, dass der Rechner nicht im gleichen Subnetz ist. Er sucht dann in seiner Routing-Tabelle nach einem passenden Router, in diesem Fall 132.199.15.1, und sendet das Paket an diesen. Der Rechner 132.199.15.1 empfängt das Paket, stellt anhand der Zieladresse fest dass das Ziel im lokalen Subnetz 132.199.1.0 liegt, und sendet es direkt an den angegebenen Zielrechner.

  10. Addressierung von Diensten: Nachdem nun die Grundlagen bekannt sind, nach denen einzelne Rechner im Netz addressiert werden können muß nun noch festgelegt werden, wie die einzelnen Dienste auf einem Rechner angesprochen werden können. Dabei wird zuerst zwischen sog. verbindungsorientierten und verbindungslosen Diensten unterschieden.

    Verbindungsorientierte Dienste sind mit Hilfe des Transmission Control Protocolls (TCP) implementiert, Verbindungslose Dienste benutzen das User Datagram Protocol (UDP). Unabhängig davon welches der beiden Protokolle für einen Dienst verwendet wird wird dieser über einen eindeutigen Port adressiert, einem Dienst ist üblicherweise ein fester Port zugewiesen. Die Zuweisung erfolgt von der IANA (Internet Assigned Number Authority), sie sind u.a. in RFC 1340 festgelegt. Auf Unix-Systemen ist die Zuweisung welcher Port für welchen Dienst bestimmt ist üblicherweise in der Datei /etc/services zu finden. Beispiele: 

    $ more /etc/services
chargen         19/tcp          ttytst source
chargen         19/udp          ttytst source
ftp-data        20/tcp          # default ftp data port
ftp             21/tcp          # File Transfer Protocol
ssh             22/tcp          # Secure Shell
ssh             22/udp
telnet          23/tcp
# 24 - private
smtp            25/tcp          mail
# 26 - unassigned
time            37/tcp          timserver
time            37/udp          timserver

    Üblicherweise existiert für jeden Dienst ein eigener Server-Prozess (Dämon), der auf Anfragen auf dem jeweiligen Port wartet und diese dann beantwortet. Auf den meisten Unix-Systemen existiert noch ein Dämon "inetd", der auf mehreren Ports gleichzeitig lauscht und erst bei eingehenden Anfragen den jeweiligen Server-Dämon gemäß einer Konfiguratioinsdatei startet. Diese Optimierung spart Rechenzeit und v.a. Arbeitsspeicher, da so Dämonen nicht ungenutzt im System gehalten werden müssen. Die Konfiguration des inetd die festlegt, für welche Dienste er lauschen soll geschieht in der Datei /etc/inetd.conf. Beispiel: 

    $ more /etc/inetd.conf
# Dienst        Verbindungsart                  Pfad zum Daemon         argv
ftp             stream  tcp     nowait  root    /usr/libexec/ftpd       ftpd -ll
telnet          stream  tcp     nowait  root    /usr/libexec/telnetd    telnetd
shell           stream  tcp     nowait  root    /usr/libexec/rshd       rshd -L
comsat          dgram   udp     wait    root    /usr/libexec/comsat     comsat
ntalk           dgram   udp     wait    nobody.tty      /usr/libexec/ntalkd     
ntalkd

    Um einen via inetd gestarteten Dienst nicht mehr anzubieten ist lediglich der Eintrag aus der Datei /etc/inetd.conf zu entfernen (besser: auszukommentieren!) und der inetd neu zu starten. (Falsch: Firewalling)

    Erwähnt werden soll hier auch noch, dass Ports Zahlen zwischen 1 und 65535 sind, und daß Dienste unterhalb Port 1000 nur vom Systemverwalter (root, UID 0) gestartet werden können. Diese Einschränkung besteht, damit nicht "normale" Benutzer (z.B.) ihren eigenen telnet-Daemon starten und damit die Systemsicherheit umgehen können (Stichwort: trojanisches Pferd).

    Die tcp-basierenden Dienste sind üblicherweise Dialogorientiert, das zugehörige Protokoll ist in zugehörigen RFCs festgelegt. Ein austesten tcp-basierter Dienste ist mit Hilfe des telnet-Programms sehr einfach möglich, Beispiel (Benutzereingabe fett): 

    noon% telnet miyu www
Trying 10.0.0.3...
Connected to miyu.feyrer.net.
Escape character is '^]'.
GET / HTTP/1.0

HTTP/1.1 200 OK
Date: Sun, 05 Dec 1999 03:11:24 GMT
Server: Apache/1.3.6 (Unix) PHP/3.0.7
Connection: close
Content-Type: text/html

<HTML>
<HEAD>
<TITLE>Miyu's Home</TITLE>
...
</BODY>
</HTML>

Connection closed by foreign host.

    Ähnlich wie hier für HTTP gezeigt können auch finger, SMTP, IRC, POP, NNTP etc. mit telnet(1) manuell gesprochen werden. Dienste die binäre Daten austauschen (FTP, IMAP, ssh, ...) sind hiermit schwierig(er) zu emulieren, es empfiehlt sich, entsprechende Clients zu verwenden. ;-) Anstatt der Service-Namen (wie in /etc/services angegeben) können auch direkt Port-Nummern verwendet werden.

  11. ICMP (Internet Control Message Protocol): Steuernachrichten für die Protokolle TCP, UDP und TCP werden in einem eigenen Protokoll übertragen, dem ICMP. Dabei gibe es neben den einfachen Paketen ICMP ECHO und ICMP ECHO-REPLY, die beim ping-Befehl verwendet werden auch noch weitere wichtige Nachrichten die (Nicht-)Erreichbarkeit von Ports, Rechnern oder ganzen Netzen signalisieren. Bekannte ICMP Types und Codes sind (aus <netinet/ip_icmp.h>):

    Diese über ICMP versandten Steuernachrichten sind für einen reibungslosen Betrieb nötig, v.a. um entfernten Rechnern diese Nachticht zukommen zu lassen. Als Netzwerk-Administrator sollte man sich deshalb über die Konsequenzen im Klaren sein, wenn man Firewalls aufsetzt, die ICMP-Nachrichten filtern.

  12. Standards rund um TCP/IP: Wurden TCP/IP und die darauf aufbauenden Protokolle urspünglich an der UniversitÄt von Berkeley, Californien, entworfen und festgelegt, so hat diese Rolle in der Zwischenzeit die Internet Engineering Task Force (IETF) übernommen. Die IETF besteht aus einzelnen Arbeitsgruppen zu Teilgebieten, in denen Analysen für mögliche Kommunikationsprotokolle, deren Dokumentation und Realisierung abgewickelt werden, die Arbeitsgruppen bestehen bilden sich aus gleichermaßen aus Forschungsunternehmen und dem universitären Bereich genauso wie aus weltweiten Firmen. Arbeitsergebnisse werden in mehreren Schritten erarbeitet, an deren Ende ein sog. RFC (Request for Comment) steht. Diese RFCs sind durchgehend numeriert, sie können von ftp.isi.edu bezogen werden. Einige ausgewählte RFCs sind:

    RFC Beschreibung
    IP over Ethernet
    IP over ATM
    IP over Avian Carrier
    791 IP (Version 4)
    IP (Version 6)
    793 TCP
    768 UDP
    792 ICMP
    telnet
    765 ftp
    SMTP
    Nachrichtenformat für SMTP
    HTTP
    URL-Typen

7.2 Name Services

  1. /etc/hosts: Weist einer IP-Nummer einen (kanonischen) Namen und wahlweise noch weitere Aliases zu.

    Beispiel: 

    smaug# grep -v ^#  /etc/hosts | head
::1					localhost
127.0.0.1               		localhost
194.95.108.11                           smaug smaug.fh-regensburg.de
194.95.108.65                           delphi delphi.fh-regensburg.de
2001:638:a01:2:2b0:d0ff:feee:7066       rfhpc8323.ipv6.fh-regensburg.de yui.ipv6.fh-regensburg.de

  2. NIS (Network Information Service, früher: Yellow Pages, YP): über eine netzwerk-weit verteilte Version der Datei /etc/hosts werden auch hier einer IP-Nummer ein kanonischer Name und wahlweise mehrere Aliases zugeordnet. Die Datei ist eindeutig innerhalb einer NIS-Domain.

    Beispiele:

  3. DNS (Domain Name System): Hierarchische, verteilte Datenbank, bei dem Rechnernamen sog. Domains zugeordnet sind, die hierarchisch organisiert werden können. Für jede Domain gibt es einen Primary Domain Name Server, der über die Rechnernamen in der jeweiligen Domain bescheid weiss, und Informationen geben kann über:

    Aufbau: host.domain, domain kann dabei wie erwähnt hierarchisch organisiert sein und eine Top Level Domain (Beispiel: .de), Second Level (Beispiel: fh-regensburg.de) Third Level Domain (Beispiele: physik.uni-regensburg.de, ping.net.au) oder weiter verschachtelt sein.

    Soll zu einem Hostnamen die zugehörige IP-Nummer ermittelt werden (Resolving), so wird zuerst der eigene Nameserver gefragt. Weiss dieser keine Antwort, dann frägt er bei einem von ca. 10 Root-Nameservern nach und ermittelt zuerst den zuständigen Nameserver für die zugehöriuge Toplevel-Domain. Dieser kann wiederum Auskunft über die Second-Level Domain geben, etc. ]

    Beispiel: Es soll die IP-Nummer des Rechners www.sun.com erfragt werden. Unter der Annahme, dass der lokale DNS die Adresse nicht in seinem Cache hat wird er zuerst einen der Root-Nameserver fragen, welcher Nameserver für die Toplevel-Domain ".com" zuständig ist. Mit dieser Information wird unser DNS dann anschliessend den .com-Nameserver fragen, wer für sun.com zuständig ist. Ist auch diese Information bekannt, dann kann der Nameserver von sun.com gefragt werden, welche Adresse der Rechner www.sun.com hat. 

     nslookup -qt=any .         # Root-Nameserver ermitteln
 nslookup -qt=any com.      # Nameserver für .com ermitteln
 nslookup -qt=any sun.com   # Nameserver für sun.com ermitteln
 nslookup -qt=any www.sun.com

  4. Nameservice Switch:

    Mit Hilfe der Datei /etc/nsswitch.conf kann eingestellt werden, welches Schema zur Namensauflösung benutzt wird und in welcher Reihenfolge.

7.3 Netzwerk-Hardware unter Unix

Netzwerk-Komponenten werden unter Unix mit einem eigenen Namensraum versehen, die zugehörigen Netzwerk-Interfaces erhalten üblicherweise je nach Hardware verschiedene Bezeichnungen.

Auflisten aller Netzwerk-Inferfaces:

Es besteht die Möglichkeit, einem System/Interface weitere IP-Adressen zuzuweisen, für einen "normalen" TCP/IP Betrieb ist das aber nicht nötig. Anwendung: Accounting virtueller Web-Server. Die Syntax zur Adressierung der einzelnen virtuellen Interfaces sowie deren Adress-Zuweisung ist bei jedem Unix-System leicht verschienden.

Solaris: ifX:Y (z.B. elxl0:1), auch für IPv6 benutzt

7.4 Einstellungen im System

7.4.1 System-Konfiguration

Im folgenden sollen die Einstellungen erläutert werden, die unter Solaris gemacht werden müssen, um TCP/IP passend zu konfigurieren.
  1. Dynamische Konfiguration mit DHCP:

  2. Statische Adressierung:
Die in /etc/hosts benötigten Informationen sind für die meisten Unix-Systeme nötig, die Angaben aus /etc/hostname.le0 und /etc/defaultrouter sind oft in anderen Dateien einzutragen, z.B.

7.4.2 Name resolving

  1. Auflösungsreihenfolge einstellen: Unter Solaris muß zuerst in der Datei /etc/nsswitch.conf die Reihenfolge festgelegt werden, in der die Namensdienste gefragt werden. Ausschlaggebend sind hierbei die Dienste, die bei "hosts" stehen, mögliche Angaben sind "files" (für /etc/hosts), "nis" und "dns". Üblich: 
    solaris% grep hosts: /etc/nsswitch.conf
hosts: files nis dns

    Andere Systeme haben ggf. andere Dateinamen und Einstellungen an dieser Stelle, traditionell bieten Unix-Systeme keine Möglichkeit, die Suchreihenfolge explizit festzulegen.

  2. /etc/hosts: Hier sind vom System- oder Netzwerk-Verwalter jeweils aktuelle Einträge zu halten, wenn diese Art der Hostname-Verwaltunge gewählt werden soll. Ausser bei sehr kleinen Netzwerken ist dies nicht empfehlenswert! 

    rfhpc8317% cat /etc/hosts 
#
# Internet host table
#
127.0.0.1       localhost
194.95.108.179  zeus zeus.fh-regensburg.de
194.95.108.65   rfhpc8317       # Added by DHCP
    Die eigene IP-Adresse(n) mit dem zugehoerigen Hostnamen sowie die Aurloesung von "localhost" in 127.0.0.1 muss auf jeden Fall in /etc/hosts stehen, da ansonsten Probleme beim Starten des Systems auftreten.

  3. NIS: Unter der Voraussetzung dass NIS passend aufgesetzt ist (siehe später :-) ist hier unter Solaris ausser der Reihenfolge in /etc/nsswitch.conf nichts zu machen. Andere Systeme haben ggf. andere Konfigurationsdateien die editiert werden müssen.

  4. DNS: Die Datei /etc/resolv.conf enthält Informationen zur Konfiguratioin des DNS, jeweils pro Zeile ein Schlüsselwort gefolgt von einem oder mehreren Werten:

    Beispiel: 

    $ cat /etc/resolv.conf
domain fh-regensburg.de
search ipv6.fh-regensburg.de fh-regensburg.de uni-regensburg.de
nameserver 194.95.104.1
nameserver 132.199.1.1
    Die Datei /etc/resolv.conf wird bei jeder Namensauflösung neu gelesen, ein Neustart der Anwendung oder gar des Systems nach einer Änderung ist nicht nötig.

7.5 Vorstellen TCP/IP-Basierte Dienste

  1. telnet: Remote-Login auf/von entferntem Rechner, textbasierte Ein-/Ausgaben werden zwischen den Systemen übertragen. 

    rfhpc8317% telnet tabaluga
Trying 194.95.108.32...
Connected to rfhpc8320.fh-regensburg.de.
Escape character is '^]'.


SunOS 5.8

login: feyrer
Password: *****
===========================================================================
  Dateien unter /usr/tmp die aelter als 14 Tage sind werden GELOESCHT!
  Dateien unter /tmp die aelter als 3 Tage sind werden GELOESCHT!

  *** /tmp bitte NICHT als Datengrab (und MP3-Archiv) missbrauchen, da
  *** dies unnoetig virtuellen Speicher belegt und der Rechner dadurch
  *** unbenutzbar wird!

===========================================================================
You have new mail.
############################### Das ist NEU ############################
################## Die Dateien befinden sich in ~news ##################
################# Aendern des Passworts mit "yppasswd" #################
You Have Mail.
rfhpc8320% date
Wed Jun 12 16:52:04 MEST 2002
rfhpc8320%

  2. ftp: File Transport Protocol, zum Übertragen von Dateien zwischen zwei Rechnern. Verbindungsaufbau, Authentifizieren und einstellen der Verbindungsparameter geschehen über eine TCP-Verbindung, die eigentliche Datenübertragung erfolgt über eine zweite TCP-Verbindung. Abhängig davon wer diese initiiert spricht man von aktivem (Server-initiiertem) und passivem (Client-initiiertem) FTP. 

    rfhpc8317% ftp tabaluga
Connected to rfhpc8320.fh-regensburg.de.
220 rfhpc8320 FTP server (SunOS 5.8) ready.
Name (tabaluga:feyrer): feyrer
331 Password required for feyrer.
Password: *****
230 User feyrer logged in.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> dir
227 Entering Passive Mode (194,95,108,32,134,123)
150 ASCII data connection for /bin/ls (194.95.108.65,40185) (0 bytes).
total 180
drwxr-xr-x  10 feyrer    bedienst    1536 May 13 05:46 .
drwxr-xr-x  41 root     other       1024 Apr 19 11:36 ..
-rw-r--r--   1 feyrer    bedienst    3665 Nov 23  1999 .Xdefaults
lrwxrwxrwx   1 feyrer   bedienst      10 Jan 25  2000 .Xresources -> .Xdefaults
-rw-r--r--   1 feyrer    bedienst    3089 Jul 14  1999 .cshrc
drwxr-xr-x   3 feyrer    bedienst     512 Mar  8  1999 .dt
-rw-r--r--   1 feyrer    bedienst    3572 Apr  3  1995 .emacs
-rwxr-xr-x   1 feyrer    bedienst   12468 Jul 12  1999 .fvwm2rc
...
226 ASCII Transfer complete.
ftp> 
ftp> pwd
257 "/home3/bedienst/dummy" is current directory.
ftp> cd /etc
250 CWD command successful.
ftp> lcd /tmp
Local directory now /tmp
ftp> get passwd
local: passwd remote: passwd
227 Entering Passive Mode (194,95,108,32,134,125)
150 Binary data connection for passwd (194.95.108.65,40186) (418 bytes).
226 Binary Transfer complete.
418 bytes received in 00:00 (4.46 KB/s)
ftp> 
ftp> bye
221 Goodbye.
rfhpc8317% 
rfhpc8317% pwd
/net/rfhs8012/home3/bedienst/feyrer
rfhpc8317% cd /tmp
rfhpc8317% ls -lad passwd
-rw-r--r--   1 feyrer   bedienst     418 Jun 12 16:56 passwd

  3. Simple Mail Transport Protocol, SMTP: Protokoll zur Übertragung von Electronic Mail, Nachrichtenformat und Übertragungsprotokoll sind in zwei getrennten RFCs fesgelegt. Clients zum senden und bearbeiten von EMail, sog. Mail User Agents (MUA) existieren wie Sand am Meer, speichern und senden von Mails wird von sog. Mail Transport Agents übernommen. Der mit Abstand am weitesten verbreitete MTA ist sendmail, andere sind qmail, zmailer, smail, postfix etc.

  4. HyperText Transport Protokoll, HTTP: Übertragungsprotokolle für Multimedia-Daten aller Art, die das World Wide Web (WWW) bilden. Simpler Datei-Request-Mechanismus, in seiner ursprünglichsten Form ohne irgendwelche Authentifizierungsmaßnahmen. Clients bauen eine Verbindung zum Server auf, fordern eine bestimmte Datei an, und erhalten sie, zusammen mit einer Typ-Information um welche Art von Inhalt es sich handelt (Bild, Text, Ton).

  5. Network Information Service, NIS: Dient zur netzwerkweiten Verwaltung der wichtigsten Unix-Konfigurationsdateien: /etc/passwd, /etc/group, /etc/hosts, ... Dateien werden zentral auf einem Server verwaltet, Clients werden innerhalb einer sog. NIS-Domäne gesammelt, sie fordern bei Anfragen die Daten vom Server oder einem der Replika (sog. NIS-Slaves) an.

    Die Dateien werden in sog. NIS-Maps gehalten. Die diversen Betriebssystem-Routinen getpwnam(3), getpwuid(3), getgrgid(3), etc. sind über die Datei /etc/nsswitch.conf so konfiguriert, daß Daten aus den NIS-Maps abgefragt werden. Die NIS-Maps haben immer ein Schlüssel-Feld, und einen Satz Daten für den jeweiligen Schlüssel. Mit dem Befehl ypcat(1) kann eine NIS-Map angezeigt werden, mit der Option "-k" erhält man zusätzlich noch den Schlüssel (Key) angezeigt.

    Beispiel: Im Falle der hosts-Map existieren zwei Maps, hosts.byname und hosts.byaddr. Enthält die Datei /etc/hosts auf dem NIS-Server die folgende Zeile: 

    10.0.0.3	tabaluga rfhpc8320
    so ist in der Map hosts.byaddr der folgende Eintrag zu finden: 
    % ypcat -k hosts.byaddr | grep tabaluga
10.0.0.3	10.0.0.3	tabaluga rfhpc8320
    Die erste Spalte gibt hierbei den Schlüssel an, der beim Systemaufruf gethostbyaddr(3) angegeben werden kann. In der Map hosts.byname ist der Eintrag mehrfach zu finden, einmal für jeden Schlüssel, damit gethostbyname(3) alle Namen auflösen kann: 
    % ypcat -k hosts.byname | grep tabaluga
tabaluga	10.0.0.3	tabaluga rfhpc8320
rfhpc8320	10.0.0.3	tabaluga rfhpc8320
    NIS erlaubt auch noch Alias-Namen für Maps, so ist z.B. "hosts" ein Alias für "hosts.byaddr", "passwd" ein Alias für "passwd.byname", etc. Eine vollständige Liste der Aliases erhält man mit dem Befehl "ypmatch -x": 
    % ypmatch -x
Use "passwd"    for map "passwd.byname"
Use "group"     for map "group.byname"
Use "project"   for map "project.byname"

  6. Network File System, NFS: Netzwerk-Dateisystem, mit dem ein von einem NFS-Server exportiertes Dateisystem auf einem NFS-Client wie eine lokale Platte oder Partition gemountet und benutzt werden kann. Der Zugriff über das Netzwerk ist dabei transparent. In den Unix-Pools der FH Regensburg sind z.B. die Anwendungssoftware unter /soft und die Home-Verzeichnisse via NFS von einem zentralen Server gemountet. Ein NFS-Server kann ein lokales Dateisystem oder - bei manchen Implementierungen - auch nur einen Teil davon exportieren. Es ist möglich ein Dateisystem read-write oder nur read-only zu exportieren. Desweiteren kann man angeben, an welche Client-Rechner das Dateisystem exportiert wird (d.h. welche es mounten können/dürfen). Unter Solaris werden die via NFS exportierten Dateisysteme in der Datei /etc/dfs/dfstab festgelegt, viele andere Unix-Implementierungen verwenden die Datei /etc/exports. Nach einem Ändern dieser Datei empfiehlt es sich auf Solaris, das NFS-Subsystem mittels "unshareall ; shareall" neu zu starten; Auf andere Unix-Implementierungen reicht ein kill -HUP an den mountd. Mit Hilfe des Befehls showmount kann von einem Server abgefragt werden, welche Dateisysteme er exportiert, und an wen.

    Die Zugriffsrechte werden bei NFS auf Basis der User-ID (UID) des jeweiligen Client-Rechners festgelegt, in einem NFS-Verbund sollte deshalb ein Benutzer, der auf mehreren Rechnern via NFS auf seine Dateien zugreifen will, auch die selbe UID haben (-> NIS). Als Sicherheitssperre, damit Systemverwalter (root, UID 0) der NFS-Clients nicht gleichzeitig root-Rechte auf dem NFS-Server haben werden Zugriffe mit UID 0 üblicherweise auf dem NFS-Server auf Zugriffe des Users "nobody" abgeändert. Unter Solaris kann dies mit der share-Option "root=<rechner>" für den angegebenen Rechner unterdrückt werden, unter Linux heisst die Option "norootsquash".

    State: Das NFS-Protokoll ist zustandslos, das heißt der Client weiss nichts über den Zustand des Servers, und umgekehrt. Es ist möglich, einen der beiden zu booten und hinterher weiterzuarbeiten. Erfolgen NFS-Zugriffe während ein NFS-Server nicht erreichbar ist, so erfolgen Timeouts.

  7. Berkeley R-Tools: Die Programme rlogin, rsh und rcp erlauben ein Remote Login (vergleichbar mit telnet), ausführen von Programmen auf entfernten Rechnern sowie Kopieren von Dateien zwischen lokalen und entfernten Rechnern. Die Authentifizierung basiert auf Login und Passwort, kann jedoch mit Hilfe einer Datei .rhosts im Homedirectory unterdrückt werden. Es wird dabei das Prinzip der Trustetd Hosts bzw. Trusted Users angewendet, d.h. die Datei enthält Angaben über Benutzer und Rechner, die als vertrauenswürdig angesehen werden, und bei denen keine Passwortabfrage durchgeführt wird. Pro Zeile wird ein Hostname und durch Leerzeichen getrennt ein Benutzername (Login) angegeben. Dieser Benutzer des entfernten Rechners darf dann ohne Passwortabfrage auf die jeweilige Kennung des lokalen Rechners zugreifen.

    Beispiel: Der Benutzer "meier" auf dem Rechner "hier" will dem Benutzer "meh12345" auf dem Rechner "rfhpc8320" ein Einloggen ohne Passwort erlauben. Dazu trägt er auf "hier" folgendes in die Datei .rhosts ein: 

    rfhpc8320 meh12345
    Der Benutzer meh12345 kann dann vom Rechner "rfhpc8320" aus sagen dass er sich an den Rechner "hier" verbinden will, allerdings nicht unter seiner Kennung, sondern unter "meier": rlogin hier -l meier. Die Passwortabfrage unterbleibt dabei.

    Es gibt noch eine systemweite Version der Datei .rhosts, /etc/hosts.equiv. Aus Sicherheitsgründen sollte diese Datei stets leer sein (oder garnicht existieren).

  8. Secure Shell: Durch diverse Angriffe im Netzwerk-Bereich, Packet Sniffing etc. wurden sowohl Transport als auch Authentifizierung der rsh zu unsicher. Abhilfe bietet hier die Secure Shell. Die Authentifizierung kann wie gewohnt auf der Basis eines Paßworts geschehen, oder mittels Public-Key Authentifizierung. Diese soll im Folgenden näher erklärt werden.

7.6 Setup Secure Shell und Public Key Authentifizierung

  1. Wenn man sich ohne Vorbereitung versucht anzumelden wird man wie gewohnt nach einem Passwort gefragt. Vorher wird noch sichergestellt, ob man sich mit dem Rechner überhaupt verbinden will: 

    daheim:~% ssh darwin.fh-regensburg.de
The authenticity of host 'darwin.fh-regensburg.de (194.95.108.82)' can't be established.
RSA key fingerprint is 69:fd:32:d8:cf:d6:f3:8c:37:41:97:3f:54:25:90:0b.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'darwin.fh-regensburg.de,194.95.108.82' (RSA) to the list of known hosts.
abc12345@darwin.fh-regensburg.de's password: passwort
Last login: Mon Feb 11 09:44:09 2008 from rfhinf111.fh-regensburg.de

===========================================================================
       * * * Willkommen in der Fakultaet Informatik-Mathematik * * *
...
darwin:~%
...
darwin:~% exit
daheim:~%
  2. Es existieren drei Arten von Keys, die auch in unterschiedlichen Dateien abgespeichert werde. Zu beachten ist, dass hier die diversen Implementierungen (F-Secure ssh, OpenSSH) divergieren. Keys können zusätzlich mit einer Passphrase versehen werden, das beim auslesen der private Keys greift, d.h. rein auf der lokalen/Client-Seite.

    Schema Dateien:

    RSA1 (alt, SSH Protokoll 1):
    Erzeugen: ssh-keygen -t rsa1
    Dateien: $HOME/.ssh/identity, $HOME/.ssh/identity.pub

    DSA (SSH Protokoll 2):
    Erzeugen: ssh-keygen -t dsa
    Dateien: $HOME/.ssh/id_dsa, $HOME/.ssh/id_dsa.pub

    RSA (SSH Protokoll 2):
    Erzeugen: ssh-keygen -t rsa
    Dateien: $HOME/.ssh/id_rsa, $HOME/.ssh/id_rsa.pub

  3. Zu einer Passwort-losen Authentifizierung muss zuerst ein Schlüsselpaar generiert werden. 
    daheim:~% ls ~/.ssh
/home2/student/abc12345/.ssh: No such file or directory
daheim:~% ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/home2/student/abc12345/.ssh/id_dsa): <return>
Created directory '/home2/student/abc12345/.ssh'.
Enter passphrase (empty for no passphrase):  <return>
Enter same passphrase again:  <return>
Your identification has been saved in /home2/student/abc12345/.ssh/id_dsa.
Your public key has been saved in /home2/student/abc12345/.ssh/id_dsa.pub.
The key fingerprint is:
98:fd:28:eb:1c:66:ef:89:e3:03:5f:95:9e:19:6a:79 abc12345@daheim
daheim:~% ls ~/.ssh
id_dsa      id_dsa.pub  prng_seed
daheim:~% cat ~/.ssh/id_dsa.pub 
ssh-dss AAAAB3NzaC1kc3MAAACBAJIFFT4nUeyEQyG8j6FIKiBZqTwmKDUOSNlAEQBIEy9syCUH6IautCPQvz9U+ZAsOLyny3XtPhqvGMoEv+s0I7W5dv5OcKZ7nxj3/1QBYSlfvgNcSTUyNh8rpjTJPnjYntmt6dOQ/7MpFKvLM8lkVoLFcyP5Y2EXbzKwIhKlf1QTAAAAFQDQ0Bu7n+Ke3g8azaNBrUDGPsbvqwAAAIA8aZpW4MaEsJ81eeue4H3J+UFoOidcjyQ95zE5iiHzNKWTon9q+hwCg0m8xrYVmyVU9OVf4eWYeL/z76ciEatRuEoseQhw4BCUTtqMJneYKnCcwauXZ5i+g1xvsi//Fh5q0x3YwNUl94v81EExxRCfmvU4UHFdHZa31EikA4dHWwAAAIEAjTJNnKcB4YlruLChqc7htPhiOUxN2F0xpRzB4VMSXCag+j6SbSiW4bMcoSz3FF35n0Mpva++nCm4ovHuDoz+4P4j7smwkZ0VEfTj2o/rrKCnoE+tG0cdgG71NSzrMKjmNJBjsaXr3tnR+T/kMp/Wli9m85JMNlxcOA2qIf7cGME= abc12345@daheim
  4. Als nächstes muss der generierte Public Key in die Datei $HOME/.ssh/authorized_keys auf der Gegenseite eingetragen werden. Der Public Key und auch die authorized_keys Datei sind Textdatei. Die Zeile aus der id_dsa.pub Datei muß an die Datei authorized_keys angehängt werden, z.B. via Cut&Paste oder durch kopieren der Datei (mit Passwort) und Anhängen. Anschließend werden diese Authentifizierungsdaten verwenden: 
    daheim:~% cd $HOME/.ssh
daheim:~/.ssh% ls
id_dsa       id_dsa.pub   known_hosts  prng_seed
daheim:~/.ssh% scp id_dsa.pub darwin.fh-regensburg.de:pub
abc12345@darwin.fh-regensburg.de's password: 
id_dsa.pub           100% |*****************************|   607       00:00    
daheim:~/.ssh% ssh darwin.fh-regensburg.de
abc12345@darwin.fh-regensburg.de's password: passwort
Last login: Fri Jan  4 11:04:46 2002 from daheim
Sun Microsystems Inc.   SunOS 5.7       Generic October 1998
...
darwin:~% cat pub
ssh-dss AAAAB3NzaC1kc3MAAACBAJIFFT4nUeyEQyG8j6FIKiBZqTwmKDUOSNlAEQBIEy9syCUH6IautCPQvz9U+ZAsOLyny3XtPhqvGMoEv+s0I7W5dv5OcKZ7nxj3/1QBYSlfvgNcSTUyNh8rpjTJPnjYntmt6dOQ/7MpFKvLM8lkVoLFcyP5Y2EXbzKwIhKlf1QTAAAAFQDQ0Bu7n+Ke3g8azaNBrUDGPsbvqwAAAIA8aZpW4MaEsJ81eeue4H3J+UFoOidcjyQ95zE5iiHzNKWTon9q+hwCg0m8xrYVmyVU9OVf4eWYeL/z76ciEatRuEoseQhw4BCUTtqMJneYKnCcwauXZ5i+g1xvsi//Fh5q0x3YwNUl94v81EExxRCfmvU4UHFdHZa31EikA4dHWwAAAIEAjTJNnKcB4YlruLChqc7htPhiOUxN2F0xpRzB4VMSXCag+j6SbSiW4bMcoSz3FF35n0Mpva++nCm4ovHuDoz+4P4j7smwkZ0VEfTj2o/rrKCnoE+tG0cdgG71NSzrMKjmNJBjsaXr3tnR+T/kMp/Wli9m85JMNlxcOA2qIf7cGME= abc12345@daheim
darwin:~% ls .ssh
id_dsa       id_dsa.pub   known_hosts  prng_seed
darwin:~% cat pub >>.ssh/authorized_keys
darwin:~% ls -la .ssh/authorized_keys
-rw-r--r--   1 abc12345  student      607 Jan  4 11:08 .ssh/authorized_keys
darwin:~% chmod go-rwx .ssh/authorized_keys 
darwin:~% ls -la .ssh/authorized_keys
-rw-------   1 abc12345  student      607 Jan  4 11:08 .ssh/authorized_keys
darwin:~% exit
  5. Anschließend kann nochmals ein neuer Versuch gemacht werden, sich ohne Passwort anzumelden: 
    daheim:~/.ssh% ssh darwin.fh-regensburg.de
Last login: Mon Feb 11 09:45:09 2008 from rfhinf111.fh-regensburg.de

===========================================================================
       * * * Willkommen in der Fakultaet Informatik-Mathematik * * *
...
darwin%
  6. Troubleshooting: ssh -v, Zugriffsrechte aller Dateien auf go-rwx, evtl. eigenen sshd mit Debugging auf nicht-privilegiertem Port starten

  7. Fortgeschrittene Themen (hier nicht weiter betrachtet): Schluessel mit Passworten versehen, SSH Agent, Port Forwarding, X Forwarding (spaeter)

7.7 Setup Network File System (NFS)

  1. NFS Client:
    • Starten der nötigen Server-Prozeße: rpcbind (= portmap), lockd (optional), statd (opt.); Bei Solaris automatisch, bei anderen Systemen ggf. Config-Dateien (rc.conf, ...) editieren!

    • Eintrag in fstab/vfstab mit "server:/exportiertes/verzeichnis" anstatt /dev/... 
      rfhpc8317% grep : /etc/vfstab
rfhs8012:/usr/Mail      -       /var/mail       nfs - yes bg,soft,actimeo=0

    • Mounten aller Dateisysteme, unter Solaris: mountall; sonst: mount -a

    • Mounten einzelner Dateisysteme ohne (v)fstab: "mount server:/remotedir /localdir". Als "server" kann entweder ein (auflösbarer) Hostname oder eine IP-Adresse angegeben werden.

    • Troubleshooting: "showmount -e server", manuelles Mounten. 
      rfhpc8317# showmount -e rfhs8012
export list for rfhs8012:
/home1    softki
/home2    homeki
/home3    homeki
/usr/Mail mailki
rfhpc8317# mount rfhs8012:/usr/Mail /mnt
rfhpc8317# mount | grep ^/mnt
/mnt on rfhs8012:/usr/Mail remote/read/write/setuid/dev=2e40007 on Thu Jan  3 16:41:54 2002
rfhpc8317# ls /mnt
abf31265                                lij39317
abg32941                                lim33289
...
rfhpc8317# umount /mnt
rfhpc8317#

  2. NFS Server:
    • Folgende Prozesse werden benötigt: rpcbind (= portmap), mountd, nfsd (ggf. im Kernel), lockd (optional), statd (opt.). Existiert eine Datein /etc/dfs/dfstab bei Solaris beim booten, so werden automatisch die nötigen Serverprozesse gestartet und die Dateisysteme passend exportiert. Auf anderen Systemen ist ggf. die Boot-Konfiguration anzupassen!

    • Zu exportierendes Dateisystem in exports/dfstab eintragen. Format für dfstab: 
      share root=maschine1:maschine2,rw=m3:m4:m5     /dateisystem
      Für mehr Details siehe die Manpages dfstab(4), share(1M) und exports(5).

    • Nach Verändern der dfstab-Datei reicht es, diese mit "unshareall ; shareall" neu einzulesen.
    • Troubleshooting: ps -ef | grep mount, showmount -e, überprüfen ob der NFS-Server evtl. den Namen des Clients nicht auflösen kann

7.8 Setup Network Information System (NIS)

  1. NIS Client:
    • Name der NIS Domäne setzen: 
      # echo mynisdomain >/etc/defaultdomain
# domainname `cat /etc/defaultdomain`

    • System als NIS Client aufsetzen: "ypinit -c". Ggf. Name/IP-Nummer(n) von NIS-Server angeben.

    • ypbind entweder manuell oder durch reboot starten. Evtl. benötigte Boot-Config (rc.conf, etc.) beachten!

    • In /etc/nsswitch.conf sicher stellen, dass lookups wirklich an NIS gerichtet werden: 
      group:          files nis
hosts:          files nis dns
passwd:         files nis 
netgroup:       files [notfound=return] nis
networks:       files nis
      Auf Systemen die kein nsswitch unterstützen sind oft Zeilen in /etc/passwd und /etc/group einzufügen, die mit einem '+' beginnen und (bis auf die ':') nur leere Felder enthalten. Durch entsprechende Positionierung der +-Zeile kann man festlegen ob NIS zuerst (-> +-Zeile erste Zeile) oder zuletzt (letzte Zeile) befragt werden soll.

    • Es empfiehlt sich immer, die lokalen Dateien vor NIS zu durchsuchen, da der Zugriff auf lokale Dateien immer schneller ist als via NIS. Bei (/etc/)passwd kommt noch hinzu, daß viele NIS-Implementierungen die (verschlüsselten) Passworte jedem Benutzer zugänglich machen; Indem man das root-Passwort nur in /etc/passwd und nicht in der passwd NIS Map hält kann man hier so einen Dictionary-Angriff abwehren.

    • Troubleshooting: ypwhich, ypcat, finger, Shell und Home-Verzeichnis müssen vorhanden sein, einloggen: 
      rfhpc8317# ypwhich
rfhs8012
rfhpc8317# ypcat passwd | head -2
wes35369:tNf1lcgZbrR/k:35369:100:Stefan Weschta:/home2/student/wes35369:/soft/bin/tcsh
scm33902:Ln6s3iyreIw2U:33902:100:Margit Schifferl:/home2/student/scm33902:/soft/bin/tcsh
...
rfhpc8317# finger wes35369
Login name: wes35369                    In real life: Stefan Weschta
Directory: /home2/student/wes35369      Shell: /soft/bin/tcsh
Never logged in.
No unread mail
No Plan.
rfhpc8317# telnet localhost
Trying 10.0.0.1...
Connected to vulab1.
Escape character is '^]'.


SunOS 5.9

login: wes35369
Password: ***
No directory! Logging in with home=/
Last login: Thu May 19 01:13:27 from 10.0.0.250
No shell
Connection closed by foreign host.
rfhpc8317#
rfhpc8317# mkdir /soft
rfhpc8317# mkdir /soft/bin
rfhpc8317# ln -s /bin/csh /soft/bin/tcsh
rfhpc8317# telnet localhost
Trying 10.0.0.1...
Connected to vulab1.
Escape character is '^]'.


SunOS 5.9

login: wes35369
Password: ***
No directory! Logging in with home=/
Last login: Thu May 19 01:14:18 from 10.0.0.250
Sun Microsystems Inc.   SunOS 5.9       Generic May 2002
vulab1%
  2. NIS Server:

Literatur

(Grundlagen, Übungen)
(c) Copyright 1998-2006 Hubert Feyrer <hubert@feyrer.de>
$Id: 08-networking.html,v 1.43 2008/02/12 15:58:57 feyrer Exp $