TCP/IP - Praxis. Dienste, Sicherheit, Troubleshooting. von Gerhard Lienemann. 3., aktualis. Aufl.

Transkript

1 TCP/IP - Praxis Dienste, Sicherheit, Troubleshooting von Gerhard Lienemann 3., aktualis. Aufl. TCP/IP - Praxis Lienemann schnell und portofrei erhältlich bei beck-shop.de DIE FACHBUCHHANDLUNG Thematische Gliederung: Netzwerkprotokolle, EDI Netzwerkprotokolle, EDI Heise Zeitschriften 2003 Verlag C.H. Beck im Internet: ISBN Inhaltsverzeichnis: TCP/IP - Praxis Lienemann

2 1 1 1 TCP/IP im Internet Die TCP/IP-Protokollfamilie stellt heute den»kommunikationskern«im Internet dar. Bereits in den Anfängen des ARPANET, der»mutter aller Netze«, das Ende der 60er Jahre aus nur vier Rechnern bestand (jeweils ein Rechner in der University of Utah, im Stanford Research Institute, in der University of Santa Barbara und in der University of Los Angeles), wurden die Grundsteine des TCP/IP gelegt. Ab 1978 begann die konsequente Einführung der TCP/IP-Protokollfamilie innerhalb des ARPANET und war 1983 abgeschlossen. Erst ein Jahr zuvor war aus primär wissenschaftlich orientierten Netzwerken das»internet«ins Leben gerufen worden, das von Anfang an auf TCP/IP-Protokollen basierte. Diese Entwicklung wurde von zahlreichen Veröffentlichungen zur Kommunikationsthematik begleitet, mittlerweile bekannt unter dem Namen»RFC«, Request For Comment. Die wichtigsten Standards innerhalb der TCP/IP-Protokollfamilie haben sich bereits sehr früh herausgebildet und sind bis heute gültig: UDP (User Datagram Protocol) RFC 768 August 1980 IP (Internet Protocol) RFC 791 September 1981 TCP (Transmission Control Protocol) RFC 793 September 1981 SMTP (Simple Mail Transfer Protocol) RFC 821 August 1982 TELNET RFC 854 Mai 1983 RARP (Reverse Address Resolution Protocol) RFC 903 Juni 1984 FTP (File Transfer Protocol) RFC 959 Oktober 1985 NetBIOS over TCP/UDP RFC 1001/1002 März 1987 DNS (Domain Name Service) RFC 1034/1035 November 1987 SNMP (Simple Network Management Protocol) RFC 1157 Mai 1990 POP3 (Post Office Protocol Version 3) RFC 1725 November 1994 IMAP (Internet Mail Access Protocol) RFC 1730 Dezember 1994 Im weiteren Verlauf dieses Kapitels werden wir uns mit den Netzwerkprotokollen DNS, SMTP und HTTP (HyperText Transfer Protocol) und ihrer praktischen Bedeutung ausführlich beschäftigen, da diese Protokolle im Internet heute die bedeutendste Rolle spielen. Während DNS, der Domain Name Service, zur Orientierung und Adressierung von Rechnern und Netzwerken im Internet unverzichtbar geworden ist, wird mit Hilfe der Mail-Protokolle SMTP, POP3 und IMAP die gesamte -Kommunikation abgewickelt. HTTP, das HyperText Transfer Protocol, dominiert natürlich durch die weltweit überall gegenwärtige Kommunikation im World Wide Web (WWW). Über dieses Netzwerkprotokoll erfolgt

3 2 TCP/IP im Internet die»verständigung«von Webservern und den Millionen Web-Clients, den Internet-Browsern, untereinander. 1.1 Internetdomain und Subnetz Der erste Schritt zur eigenen Internetdomain ist zumeist die Kontaktaufnahme mit einem entsprechenden»provider«bzw.»hoster«, der heute in der Regel alle erforderlichen Formalitäten übernimmt. Somit entfällt ein direkter Vertragsabschluss mit dem DENIC, dem Deutschen Network Information Center. Das DENIC ist innerhalb Deutschlands für die kontrollierte Vergabe von Subdomains unterhalb der Top-Level-Domain»de«zuständig. Will man eigene Internetdienste betreiben bzw. eigene Server ins Internet bringen (z. B. einen FTP- oder Webserver), so werden dazu legale Internet-Adressen benötigt. Die Vergabe privater Adressen (gem. RFC 1918, wie es in den hier verwendeten Beispielen erfolgt siehe Tabelle 1-1) ist zu diesem Zweck nicht möglich, da man schließlich für weltweite Eindeutigkeit dieser IP-Adressen sorgen muss. Subnetz Subnetz-Maske / / /16 Tabelle 1 1 Private Adressen für die unternehmensinterne IP-Adressierung Diese kann aber nur dann gewährleistet werden, wenn eine zentrale Instanz darüber wacht, dass eine IP-Adresse stets nur einmal vergeben wird. Für diese Aufgabe war ursprünglich die IANA (Internet Assigned Numbers Authority siehe auch zuständig. Ihre Aufgaben werden aber mittlerweile von der ICANN (Internet Corporation for Assigned Names and Numbers) als»non-profit«-organisation wahrgenommen. Sie verwaltet weltweit zentral eine Datensammlung von IP-Adressen und Subnetzen, wobei sie die Vergabe in anderen Ländern an weitere Instanzen delegiert. Dabei handelt es sich um das APNIC (Asia- Pacific Network Information Center das ARIN (American Registry for Internet Numbers und das RIPE NCC (Réseaux IP Européens Letzteres übernimmt diese Aufgabe für den europäischen Bereich des Internets. Die wichtigsten Informationen zur IP-Adressierung, -Organisation und zu ihren Besonderheiten sind in den RFCs 2050 (Internet Registry IP Allocation Guidelines), 1918 (Address Allocation for Private Internets) und 1518 (An Architecture for IP Address Allocation with CIDR) nachzulesen. Erläuterungen zum so genannten RIPE-Antrag finden Sie in Abschnitt

4 Einrichtung eines DNS-Servers 3 Da mit der Domainbeschaffung für Privatpersonen normalerweise kein eigenes IP-Subnetz (mehrere öffentliche IP-Adressen, die ausschließlich für den Antragsteller reserviert sind) erworben wird und der Kunde für den Internetzugang (nicht für die Bereitstellung eigener Dienste) dynamisch IP-Adressen aus dem eigenen Kontingent des Providers erhält, wird der Prozess der Domain-Beantragung und Reservierung vom Provider meist in Eigenregie durchgeführt. 1.2 Einrichtung eines DNS-Servers Einer der wichtigsten Internetdienste ist der»domain Name Service«(DNS). Er stellt in dem nahezu undurchdringlichen Dschungel von IP-Adressen die einzige Orientierungshilfe im Internet dar und unterstützt den Benutzer, sich auf der Basis von Namen zurechtzufinden. DNS ist aber nicht nur für die Rechneradressierung über Namen zuständig, sondern erfüllt weitere Aufgaben: Umwandlung»sprechender«Namen in IP-Adressen Umwandlung von IP-Adressen in»sprechende«namen (reverse translation) Verwaltung einer oder mehrerer Domänen und ihrer Namensdatenbasis Verwaltung von MX-Records Bereitstellung der Adress-Informationen zuständiger Mailserver für die jeweiligen Zieldomänen Bevor der beauftragte ISP die beantragte DNS-Domain freigibt, erfolgt durch ihn eine Überprüfung des konfigurierten DNS-Servers, sofern dieser selbständig administriert wird (der DNS- Service also nicht beim ISP»eingekauft«wurde). Diesen Vorgang kann man gewissermaßen als»dns-abnahme«verstehen. Die Einrichtung von DNS-Servern ist natürlich nicht nur für die externe Kommunikation im Internet geboten, sondern sie stellt auch die Grundlage der Adressierung in einem Intranet dar. Jeder Anwender, der auf Informationen eines Intranet-Servers (unternehmensinterner Webserver) zugreifen will, benötigt den»kontakt«zu einem internen DNS-Server. Kein Netzadministrator wird ernsthaft auf die Idee kommen, die interne Adressierung eines TCP/ IP-Netzwerkes auf die Verwendung von IP-Adressen zu beschränken. Die Vielzahl unterschiedlicher Server-Systeme in einem Unternehmen würde zu einer inakzeptablen Orientierungslosigkeit führen, da die verwendeten IP-Adressen keinerlei Rückschlüsse auf den Server zulassen. Die Adressierung eines Servers mit Namen»SAP-FINANZ«ist sicher besser nachzuvollziehen als die Angabe von» «. Die Verwendung so genannter»host-dateien«(bei UNIX-Systemen meist unter /etc/ hosts zu finden) zur Namensauflösung ist normalerweise keine vernünftige Alternative, da diese Dateien auf jedem Client-System manuell gepflegt werden müssen und daher den Administrationsaufwand in größeren Netzwerken mit mehreren Rechnern drastisch erhöhen.

5 4 TCP/IP im Internet In den nächsten Abschnitten soll daher gezeigt werden, wie ein DNS-Server unter Verwendung unterschiedlicher Betriebssystemplattformen installiert und konfiguriert wird. Repräsentativ für alle UNIX-Betriebssysteme erfolgt die Darstellung einer Installation unter LINUX, und um den Anforderungen der»windows-gemeinde«rechnung zu tragen wird ein DNS-Server unter dem Betriebssystem»Windows NT 4.0 Server«und»Windows 2000 Advanced Server«konfiguriert Funktionsweise Auf eine Detailbetrachtung der verschiedenen DNS-Servertypen (primary, secondary, slave, forwarder, cache) soll hier aus Gründen der Komplexität verzichtet werden. Vielmehr werden wir uns auf die Einrichtung eines Primary Name Servers (PNS) und eines Secondary Name Servers (SNS), dem für einen Ausfall des PNS erforderlichen Backup-System, beschränken. Die Kommunikation innerhalb des DNS spielt sich gewissermaßen als»frage- und Antwort-Spiel«zwischen dem DNS-Client (resolver) und dem lokalen DNS-Server ab. Kennt der lokale DNS-Server die IP-Adresse des angefragten Namens nicht, so muss er sich bei anderen, ihm bekannten Nameservern danach»erkundigen«. Dabei verwendet er eine hierarchisch orientierte Anfragesequenz, die er beim DNS-Rootserver, der»wurzel«aller DNS-Server, beginnt. Die Namen dieser Rootserver werden meist in einer Datei»cache«oder»root«(Listing 1-1) bei jedem UNIX-System bzw. bei Konfiguration einer DNS-Domain im Windows NT Server automatisch angelegt und sind weltweit eindeutig. This file holds the information on root name servers needed to initialize cache of Internet domain name servers (e.g. reference this file in the "cache. <file>" configuration file of BIND domain name servers). This file is made available by InterNIC registration services under anonymous FTP as file /domain/named.root on server FTP.RS.INTERNIC.NET -OR- under Gopher at RS.INTERNIC.NET under menu InterNIC Reg.Serv. (NSI) submenu InterNIC Reg.Archives file named.root last update: Aug 22, 1997 related version of root zone:

6 Einrichtung eines DNS-Servers 5 formerly NS.INTERNIC.NET IN NS A.ROOT-SERVERS.NET. A.ROOT-SERVERS.NET A formerly NS1.ISI.EDU NS B.ROOT-SERVERS.NET. B.ROOT-SERVERS.NET A formerly C.PSI.NET NS C.ROOT-SERVERS.NET. C.ROOT-SERVERS.NET A formerly TERP.UMD.EDU NS D.ROOT-SERVERS.NET. D.ROOT-SERVERS.NET A formerly NS.NASA.GOV NS E.ROOT-SERVERS.NET. E.ROOT-SERVERS.NET A formerly NS.ISC.ORG NS F.ROOT-SERVERS.NET. F.ROOT-SERVERS.NET A formerly NS.NIC.DDN.MIL NS G.ROOT-SERVERS.NET. G.ROOT-SERVERS.NET A formerly AOS.ARL.ARMY.MIL NS H.ROOT-SERVERS.NET. H.ROOT-SERVERS.NET A formerly NIC.NORDU.NET NS I.ROOT-SERVERS.NET. I.ROOT-SERVERS.NET A temporarily housed at NSI (InterNIC)

7 6 TCP/IP im Internet NS J.ROOT-SERVERS.NET. J.ROOT-SERVERS.NET A housed in LINX, operated by RIPE NCC NS K.ROOT-SERVERS.NET. K.ROOT-SERVERS.NET A temporarily housed at ISI (IANA) NS L.ROOT-SERVERS.NET. L.ROOT-SERVERS.NET A housed in Japan, operated by WIDE NS M.ROOT-SERVERS.NET. M.ROOT-SERVERS.NET A End of File Listing 1 1 Rootserver-Liste in der UNIX-Datei»cache«Die Root-Datei unter Listing 1-1 ist der LINUX-Distribution S.u.S.E 6.3 entnommen. DNS-Anfragebeispiel Der Ablauf einer DNS-Anfrage ist Abbildung 1-1 zu entnehmen. Abb. 1 1 DNS-Anfragebeispiel Sollten die Rootserver die Anfrage des lokalen DNS-Servers nicht beantworten können, so teilen sie dem lokalen DNS-Server die Zuständigkeiten (referrals) für die angefragte Do-

8 Einrichtung eines DNS-Servers 7 main der ersten Hierarchiestufe mit (so z. B. den Nameserver des Deutschen Network Information Centers, wenn es sich um die Top-Level-Domain»de«handelt). Wenn auch dieser Nameserver den angefragten Namen nicht in eine ihm bekannte IP-Adresse umsetzen kann, so kennt er zumindest den Nameserver, der für die Second-Level-Domain zuständig ist (wenn beispielsweise der Host-Name» wurde, so ermittelt dieser Top-Level-Nameserver nunmehr den zuständigen Second-Level-Nameserver für die Domain»meier.de«. Wird nun dieser Server im nächsten Schritt kontaktiert, so liefert er dem ursprünglich angefragten lokalen DNS-Server die gewünschte IP-Adresse, da diese ja in seiner lokalen DNS-Datenbasis geführt wird. Nun kann der lokale DNS-Server die Anfrage»seines«Clients beantworten Auswahl der Betriebssystem-Plattform In der Praxis gibt es für die Errichtung eines DNS-Serversystems nur selten die freie Wahl der Betriebssystemplattform, da der Aufbau einer eigenen DNS-Domäne oft viel später vorgenommen wird, als die Einführung anderer Netzwerkdienste. Daher wird man in einer primär UNIX-bestimmten Rechnerlandschaft auch für den DNS-Dienst (implementiert als named-daemon) eine UNIX-Plattform wählen, während in einer eher Microsoft-lastigen Umgebung der DNS-Dienst im Windows NT Server den Vorzug erhalten wird. Beide Philosophien haben ihre Vorzüge, sodass hier auch keine konkrete Empfehlung ausgesprochen werden soll. Für Puristen wird es natürlich zum named keine wirkliche Alternative geben, während der überlastete Netzwerkadministrator die minutenschnelle Konfiguration des DNS-Dienstes unter Windows NT klar bevorzugen wird. Insbesondere für die im nächsten Abschnitt dargestellte Basiskonfiguration eines DNS-Servers sollen die derzeit am weitesten verbreiteten Windows-Umgebungen (Windows NT 4.0 Server und Windows 2000 Advanced Server) sowie eine UNIX-Variante (LINUX-Distribution S.u.S.E. 6.3) beschrieben werden Basiskonfiguration Testszenario Zur Veranschaulichung der Kommunikationszusammenhänge wird ein Testszenario erstellt (Abbildung 1-2), das folgende Komponenten umfasst: eine Firewall, die auch als Router zwischen den beiden Subnetzen und mit der Subnetzmaske fungiert ein Client-Rechner im Subnetz mit der IP-Adresse und dem Namen mickey ein Client-Rechner im Subnetz mit der IP-Adresse und dem Namen donald

9 8 TCP/IP im Internet b Abb. 1 2 Testszenario Konfiguration unter Windows NT 4.0 Server Nach Installation des Betriebssystems und Einrichtung der Netzwerkdienste (es wird hier nur der TCP/IP-Protokollstack benötigt) erfolgt die Installation des»microsoft DNS-Server«(Abbildung 1-3). Abb. 1 3 Hinzufügen des Dienstes»Microsoft DNS-Server«Nach anschließendem Systemneustart findet man unter Start Programme Verwaltung (Allgemein) einen neuen Eintrag: DNS-Manager. Seine Aktivierung per Mausklick liefert das Basiskonfigurationsfenster, in dem der bzw. die gewünschten DNS-Server definiert und konfiguriert werden können (Abbildung 1-4).

10 Einrichtung eines DNS-Servers 9 Abb. 1 4 DNS-Manager Ich möchte nun schrittweise die Konfiguration des DNS-Servers und der für ein Testszenario erforderlichen weiteren Rechner beschreiben: Schritt 1: Hinzufügen eines neuen DNS-Servers. Unter dem DNS-Manager wird gemäß Abbildung 1-5 ein neuer DNS-Server eingetragen. Abb. 1 5 DNS-Server hinzufügen Abbildung 1-6 liefert eine Übersicht der zu diesem Zeitpunkt automatisch generierten Objekte. Abb. 1 6 DNS-Manager nach DNS-Serverdefinition Schritt 2: Hinzufügen einer neuen primären Zone. Im DNS-Manager wird nun der Server markiert und unter DNS Neue Zone die neue DNS-Zone»tcpip-grundlagen.de«als primäre Zone definiert (Abbildungen 1-7 bis 1-9). Dadurch wird der Primary Name Server (PNS) für diese Zone definiert.

11 10 TCP/IP im Internet Abb. 1 7 Definition einer neuen Zone Abb. 1 8 Definition einer primären Zone Abb. 1 9 Definition des Zonennamens und der Zonendatei

12 Einrichtung eines DNS-Servers 11 Schritt 3: Hinzufügen der Reverse-Mapping-Zonen. Zur Generierung der für die umgekehrte Zuordnung von IP-Adressen auf Namen erforderlichen Reverse-Mapping-Zonen werden nun analog zur Definition der primären Zone»tcpip-grundlagen.de«die»inaddr.arpa«-Zonen eingetragen (Abbildung 1-10). Für das vorliegende Testszenario lauten die Zonennamen»1.10.in-addr.arpa«und»2.10.in-addr.arpa«(gemäß der Adressierung von Rechnernamen innerhalb der IP-Subnetze und , jeweils mit der IP- Subnetzmaske ). Abb Definition der Zone»1.10.in-addr.arpa«Schritt 4: Hinzufügen von Rechnernamen. Nach Definition der Zone»tcpip-grundlagen.de«wurden bereits die ersten Resource Records automatisch generiert und sind in Abbildung 1-11 zu sehen. Abb DNS-Manager nach Definition der Zone»tcpip-grundlagen.de«Nun müssen für das geplante Testszenario zwei weitere Rechnernamen eingetragen werden, und zwar mickey (IP-Adresse ) und donald ( ). Zu dem Zweck aktiviert man innerhalb des rechten Feldes der Zoneninformationen die rechte Maustaste und selektiert»neuer Host«. Es werden nun Host-Namen und IP-Adresse eingetragen sowie der entsprechende Pointer-Eintrag (PTR) erzeugt (Abbildung 1-12).

13 12 TCP/IP im Internet Abb Definition eines neuen Host-Eintrages Schritt 5: Hinzufügen einer neuen sekundären Zone. Die optionale Definition eines Secondary Name Servers (SNS) ist zwar nicht zwingend erforderlich, empfiehlt sich jedoch, da sonst bei Ausfall des PNS kein weiterer zuständiger DNS-Server zur Verfügung steht und somit eine Namensauflösung nicht mehr vorgenommen werden kann. Sämtliche auf Namen basierten Kommunikationsaktivitäten kämen zum Erliegen und würden die Kommunikation im Intranet/Internet empfindlich beeinträchtigen. Die Konfiguration des SNS erfolgt nahezu identisch mit der des PNS. Eine detaillierte Beschreibung wird im nächsten Abschnitt»Konfiguration unter Windows 2000 Advanced Server«vorgenommen. Die Basiskonfiguration ist damit abgeschlossen (zweifelsfrei stellt das hier beschriebene Szenario eine sehr grundlegende Konfiguration dar und erhebt keinerlei Anspruch auf Vollständigkeit dies wäre Thema eines ganzen Buches, allerdings ist mit dieser Basiskonfiguration der DNS-Dienst vollständig nutzbar und kann für eine produktive Umgebung eingesetzt werden). Damit der DNS-Dienst auch von den Clients, den DNS-Resolvern, benutzt werden kann, muss die Netzwerkkonfiguration auf den Clients entsprechend angepasst werden. Aktiviert man auf dem Windows-Desktop mit der rechten Maustaste das Symbol für die»netzwerkumgebung«und selektiert»eigenschaften«, so wird das Netzwerkkonfigurationsfenster aufgerufen. Hier markiert man mit der linken Maustaste den TCP/IP-Stack des Netzwerk- Controllers (Abbildung 1-13) und aktiviert den Button für die»eigenschaften«. Abb Konfiguration der TCP/IP- Eigenschaften auf dem Client

14 Einrichtung eines DNS-Servers 13 Nun erfolgt der Eintrag des DNS-Servers unter der Registerkarte»DNS-Konfiguration«(Abbildung 1-14). Abb Eintragen des DNS-Servers auf dem Client Eine Überprüfung der erfolgreichen Konfiguration von DNS-Resolver (Client) und DNS- Server mit dem»ping«-kommando ergibt folgende Ausgabe: D:\WINDOWS>ping mickey PING wird ausgeführt für mickey.tcpip-grundlagen.de [ ] mit 32 Bytes Daten: Antwort von : Bytes=32 Zeit<10ms TTL=128 Antwort von : Bytes=32 Zeit<10ms TTL=128 Antwort von : Bytes=32 Zeit<10ms TTL=128 Antwort von : Bytes=32 Zeit<10ms TTL=128 Ping-Statistik für : Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0 (0% Verlust), Ca. Zeitangaben in Millisek.: Minimum = 0ms, Maximum = 0ms, Mittelwert = 0ms

15 14 TCP/IP im Internet Konfiguration unter Windows 2000 Advanced Server Die Installation und Konfiguration des DNS unter dem Windows 2000 Advanced Server erfolgt ähnlich einfach wie unter Windows NT. Unter Programme Verwaltung Konfiguration des Servers wird aus dem Netzwerk-Menü»DNS einrichten«aktiviert und installiert (Abbildung 1-15). Abb Einrichten des DNS-Dienstes unter Windows 2000 Advanced Server Unter dem Servernamen goofy wird nun der aus dem letzten Abschnitt ausstehende Secondary Name Server generiert und eine entsprechende Zone eingerichtet. Es wird nun der Servername goofy markiert und mit der rechten Maustaste das Kontextmenü eingeblendet. Hier erfolgt durch Auswahl des Menüpunktes»Neue Zone...«die Aktivierung eines Assistenten, der durch die Definition der neuen sekundären Zone für die DNS-Domäne tcpipgrundlagen.de führt (Abbildungen 1-16 bis 1-21).

16 Einrichtung eines DNS-Servers 15 Abb Assistent zur Erstellung neuer Zonen Abb Definition eines sekundären Zonentyps Abb Definition der Forward-Lookup-Zone

17 16 TCP/IP im Internet Abb Eingabe des Domänennamens»tcpip-grundlagen.de«Abb Angabe des PNS für»tcpip-grundlagen.de«abb Beenden des Zonen-Assistenten

18 Einrichtung eines DNS-Servers 17 Nach Einrichtung dieser Sekundärzone erfolgt automatisch der erste Zonentransfer vom PNS zum SNS. Das Ergebnis dieser Übertragung geht aus Abbildung 1-22 hervor. Abb Zonentransfer vom PNS zum SNS Wird nun auf dem PNS der neue Name für den SNS goofy eingetragen, so wird dieser beim nächsten Zonentransfer, abhängig von den eingetragenen Timeout-Werten im SOA-Record (siehe nächster Abschnitt»Konfiguration unter LINUX«), ebenfalls auf den SNS übernommen. Natürlich müssen auch für den SNS die entsprechenden Reverse-Mapping-Zonen generiert werden. Dazu wird im Strukturfeld des DNS-Managers»Reverse-Lookupzonen«markiert und über die rechte Maustaste die sekundären Zonen 1.10.in-addr.arpa und 2.10.in-addr.arpa gebildet. Auch hier erfolgt die Übertragung der auf dem PNS definierten Reverse-Lookup-Adressen automatisch (Abbildung 1-23). Abb Generierung der Reverse-Lookupzonen Sollten sich in der DNS-Datenbasis Rechnernamen befinden, die Rückschlüsse auf das unternehmensinterne Netzwerk zulassen, so sollte aus Sicherheitsgründen die Übertragung von Zonendaten an Fremd-Server verhindert werden.

19 18 TCP/IP im Internet Dies erreicht man dadurch, dass man die jeweilige Zone markiert und mit der rechten Maustaste ihre Eigenschaften in der Registerkarte»Zonenübertragungen«entsprechend anpasst (Abbildung 1-24). Abb Definition von Einschränkungen bei den Zonenübertragungen Mit dem Hilfsprogramm»nslookup«, das man von der DOS-Eingabeaufforderung aufruft, kann man den Erfolg dieser Definition überprüfen. Ist die Übertragung verboten, so erhält man folgende Ausgabe: E:\>nslookup Standardserver: goofy.tcpip-grundlagen.de Address: >ls -d tcpip-grundlagen.de. [goofy.tcpip-grundlagen.de] *** Domäne tcpip-grundlagen.de. kann nicht aufgeführt werden: Query refused > Ist die Zonenübertragung erlaubt, werden die angeforderten Informationen einer Zone angezeigt: > ls -d tcpip-grundlagen.de. [goofy.tcpip-grundlagen.de] tcpip-grundlagen.de. SOA firewall.tcpip-grundlagen.de administrator.tcpip-grundlagen.de. ( ) tcpip-grundlagen.de. NS firewall.tcpip-grundlagen.de donald.tcpip-grundlagen.de. A

20 Einrichtung eines DNS-Servers 19 firewall.tcpip-grundlagen.de. A firewall.tcpip-grundlagen.de. A mickey.tcpip-grundlagen.de. A tcpip-grundlagen.de. SOA firewall.tcpip-grundlagen.de administrator.tcpip-grundlagen.de. ( ) > Die in Windows 2000 integrierten Active Directory Services (X.500-kompatibler Verzeichnisdienst) bieten die Möglichkeit, DNS-Zonen als so genannte»ads-containerobjekte«zu behandeln und realisieren somit die vollständige ADS-Integration. Dies ist allerdings nur möglich, wenn es sich bei den DNS-Servern auch gleichzeitig um Domain Controller handelt. Die anstehenden Aktualisierungen der DNS-Daten werden dann direkt in die ADS-Datenbasis geschrieben und an alle weiteren Domain Controller verteilt. Konfiguration unter LINUX Unter LINUX (hier Kernel Version , Distribution S.u.S.E 6.3) erfolgt die DNS-Server-Installation als Implementierung des BIND (Berkeley Internet Name Domain) in der Version Während man unter den Windows-Implementierungen infolge der grafischen Benutzerführung kaum mit den DNS-Ressourcendateien in Berührung kommt, ist es bei der Konfiguration unter LINUX (oder auch anderen UNIX-Systemen) unbedingt erforderlich, sich mit ihrer Definition und Bedeutung zu beschäftigen. Ressourcendateien Konfigurationsdatei /etc/named.conf Sie ist Nachfolgerin der unter den Bind4-Versionen bekannten /etc/named.boot-datei, hat allerdings eine völlig überarbeitete Syntax erhalten. Diese Datei enthält alle für den Serverbetrieb relevanten globalen Parameter und wird unmittelbar nach Start des named-daemons eingelesen. In unserem Testszenario für den designierten LINUX-DNS-Server (für die Konfiguration des DNS-Dienstes unter LINUX wird derselbe Rechner verwendet wie unter Windows 2000 Advanced Server) und die Domäne»tcpip-grundlagen.de«sieht diese Datei folgendermaßen aus (Basisversion mit einer geringen Anzahl von Optionen): # # Globale Serverparameter # options { directory "/var/named" } # # Obligatorische Zonendatei für die Rootserver # zone "." IN { type hint file "named.root" } #

21 20 TCP/IP im Internet # Festlegen des Loopback (forward/reverse) # zone "localhost" IN { type master file "named.localhost" check-names fail allow-update { none } } zone " in-addr.arpa" IN { type master file "named " check-names fail allow-update { none } } # # Die Masterdatei # zone "tcpip-grundlagen.de" IN { type master file "named.tcpip-grundlagen.de" allow-update { none } allow-query { any } notify yes } # # Festlegen der Reverse Resolution für beide Subnetze # zone "1.10.in-addr.arpa" IN { type master file "named.10.1" check-names fail allow-update { none } allow-query { any } notify yes } zone "2.10.in-addr.arpa" IN { type master file "named.10.2" check-names fail allow-update { none } allow-query { any } notify yes } Rootserverdatei /var/named/named.cache In dieser Datei sind die derzeit aktuellen weltweit eindeutig gültigen DNS-Rootserver definiert (siehe Listing 1-1).

22 Einrichtung eines DNS-Servers 21 Forward-Lookup-Datei /var/named/named.localhost In dieser Datei wird das Mapping des localhost auf die Loopback-Adresse D IN root ( serial 3H refresh 15M retry 1W expiry 1D ) minimum 1D IN 1D IN A Reverse-Lookup-Datei /var/named/named Hier erfolgt das Reverse-Mapping der Loopback-Adresse auf den Namen localhost: $ORIGIN 1D IN SOA localhost. root.localhost. ( serial 3H refresh 15M retry 1W expiry 1D ) minimum 1D IN NS localhost. 1 1D IN PTR localhost. Forward-Lookup-Datei /var/named/named.tcpip-grundlagen.de In dieser Datei werden sämtliche in der Domäne tcpip-grundlagen.de definierten Rechnernamen den entsprechenden IP-Adressen IN SOA goofy root.localhost ( serial 3H refresh 15M retry 1W expiry 1D ) minimum IN NS goofy localhost IN A goofy IN A mickey IN A firewall IN A donald IN A

23 22 TCP/IP im Internet Reverse-Lookup-Datei /var/named/named.10.1 Hier erfolgt das Reverse-Mapping der IP-Adressen des Subnetzes auf die IN SOA goofy.tcpip-grundlagen.de root.goofy ( serial 3H refresh 15M retry 1W expiry 1D ) minimum IN NS goofy.tcpip-grundlagen.de. 1.1 IN PTR firewall.tcpip-grundlagen.de. 2.1 IN PTR mickey.tcpip-grundlagen.de. 3.1 IN PTR goofy.tcpip-grundlagen.de. Reverse-Lookup-Datei /var/named/named.10.2 Hier erfolgt das Reverse-Mapping der IP-Adressen des Subnetzes auf die IN SOA goofy.tcpip-grundlagen.de root.localhost ( serial 3H refresh 15M retry 1W expiry 1D ) minimum IN NS goofy.tcpip-grundlagen.de. 1.1 IN PTR firewall.tcpip-grundlagen.de. 2.1 IN PTR donald.tcpip-grundlagen.de. Resource Records Gemäß RFC 1035 vom November 1987 stehen für das Satzformat der Resource Records (RR) folgende Felder zur Verfügung: NAME Name des IP-Knotens, zu dem dieser RR gehört. TYPE Ein zwei Bytes umfassendes Typenfeld mit folgenden Werten: A IP-Adresse NS autorisierter Name-Server MD alte Angabe neu MX MF alte Angabe neu MX CNAME Angabe eines Aliasnamens SOA gibt den Beginn einer Zone an (Start Of Authority) MB experimentell

24 Einrichtung eines DNS-Servers 23 MG experimentell MR experimentell NULL experimentell WKS Angabe von Diensten, den»well known services«ptr Angabe eines Zeigers auf eine Domäne HINFO Textinformation zur Beschreibung eines Hosts MINFO Mailbox- oder Maillist-Informationen MX Verteiler für Mail-Dienste TXT Zeichenketten CLASS Ein zwei Bytes umfassendes Typenfeld mit folgenden Werten: IN CS CH HS Internet-Protokollfamilie TCP/IP alte Angabe wird nicht mehr verwendet die CHAOS-Klasse wird nicht verwendet Hesiod wird nicht verwendet TTL Ein vier Bytes umfassendes Integer-Feld. Es gibt den Zeitraum (in Sekunden) für beim Nameserver erneut angeforderte DNS-Daten an. Wird hier kein Wert angegeben, so wird der entsprechende Eintrag im SOA-RR verwendet. Bei der Wahl dieses Wertes sollte man sorgfältig vorgehen. Bei einem zu niedrigen Wert wird nämlich die Leistungsfähigkeit des Servers durch häufiges Anfordern reduziert, hingegen wird die Reaktionszeit des Servers negativ beeinflusst, wenn der TTL-Wert (Time to Live) zu hoch angesetzt ist. RDLENGTH Ein zwei Bytes umfassendes Feld, das die Länge des folgenden RDATA-Feldes angibt. RDATA In Abhängigkeit des TYPE- und CLASS-Formates werden hier Daten mit variabler Länge zur Beschreibung der Ressource angegeben. Logging Nachdem die Konfiguration des DNS-Servers unter LINUX abgeschlossen ist, kann der Dienst mit dem Kommando /sbin/init.d/named start gestartet bzw. mit /sbin/init.d/ named stop gestoppt werden. Will man einen laufenden named-daemon dazu veranlassen, die geänderten Ressourcendateien erneut einzulesen ohne den named-daemon zu stoppen, so geschieht dies mit dem Kommando kill HUP <Prozess-Id>. Das folgende Protokoll (unter /var/log/messages zu finden) repräsentiert einen beispielhaften Ablauf für den Start des named-daemons und der Datenübernahme aus den Resource Records:

25 24 TCP/IP im Internet Jul 30 22:39:56 goofy syslogd 1.3-3: restart. Jul 30 22:39:59 goofy kernel: klogd 1.3-3, log source = /proc/kmsg started. Jul 30 22:39:59 goofy kernel: Inspecting /boot/system.map Jul 30 22:39:59 goofy kernel: Loaded 8436 symbols from /boot/system.map. Jul 30 22:39:59 goofy kernel: Symbols match kernel version Jul 30 22:39:59 goofy kernel: Loaded 27 symbols from 4 modules. Jul 30 22:39:59 goofy kernel: Serial driver version 4.27 with HUB-6 MANY_PORTS MULTIPORT SHARE_IRQ enabled Jul 30 22:39:59 goofy kernel: ttys00 at 0x03f8 (irq = 4) is a 16550A Jul 30 22:39:59 goofy kernel: ttys01 at 0x02f8 (irq = 3) is a 16550A Jul 30 22:39:59 goofy kernel: rtl8139.c:v1.08 6/25/99 Donald Bekker Jul 30 22:39:59 goofy kernel: rtl8139.c:v1.08 6/25/99 Donald Bekker Jul 30 22:39:59 goofy kernel: eth0: RealTek RTL8139 Fast Ethernet at 0xcc00, IRQ 9, 00:e0:7d:85:e4:3f. Jul 30 22:40:08 goofy sshd[154]: log: Server listening on port 22. Jul 30 22:40:08 goofy sshd[154]: log: Generating 768 bit RSA key. Jul 30 22:40:08 goofy /usr/sbin/cron[158]: (CRON) STARTUP (fork ok) Jul 30 22:40:08 goofy in.identd[162]: started Jul 30 22:40:08 goofy sshd[154]: log: RSA key generation complete. Jul 30 22:40:39 goofy named[200]: starting. named REL Mon Nov 8 20:26:44 GMT 1999 ^Iroot@engel:/usr/src/packages/BUILD/bind /bin/named Jul 30 22:40:39 goofy named[200]: hint zone "" (IN) loaded (serial 0) Jul 30 22:40:39 goofy named[200]: master zone "localhost" (IN) loaded (serial ) Jul 30 22:40:39 goofy named[200]: master zone " in-addr.arpa" (IN) loaded (serial ) Jul 30 22:40:39 goofy named[200]: Zone "1.10.in-addr.arpa" (file named.10.1): No default TTL set using SOA minimum instead Jul 30 22:40:39 goofy named[200]: master zone "1.10.in-addr.arpa" (IN) loaded (serial ) Jul 30 22:40:39 goofy named[200]: Zone "tcpip-grundlagen.de" (file named.tcpip-grundlagen.de): No default TTL set using SOA minimum instead Jul 30 22:40:39 goofy named[200]: master zone "tcpip-grundlagen.de" (IN) loaded (serial ) Jul 30 22:40:39 goofy named[200]: listening on [ ].53 (lo) Jul 30 22:40:39 goofy named[200]: listening on [ ].53 (eth0) Jul 30 22:40:39 goofy named[200]: Forwarding source address is [ ].1024 Jul 30 22:40:39 goofy named[201]: Ready to answer queries.

26 Einrichtung eines DNS-Servers DNS-Datenfluss Die Überprüfung der DNS-Kommunikation kann mit Hilfe eines Netzwerktraces vorgenommen werden. Auch wenn die Bedienung des Netzwerkanalyse-Tools»Basic Sniffer«von Network Associates erst in Kapitel 5 näher beschrieben wird, so sei bereits an dieser Stelle einmal ein Blick in die Tiefen der Bits und Bytes erlaubt. Eine charakteristische DNS-Kommunikationssequenz ist folgenden zwölf Daten-Frames zu entnehmen (Abbildung 1-25): Abb Antwort des DNS-Servers Grundlage für diesen Trace ist die Durchführung eines»ping«-kommandos ausgehend von Rechner auf den Rechner dagobert.tcpip-grundlagen.de. Wie aus Abbildung 1-25 ersichtlich, wird unmittelbar durch Absetzen des»ping«-kommandos ein DNS-Request (Frame Nr. 1) an den DNS-Server (Rechnername goofy.tcpip-grundlagen.de) ausgelöst, da ja dem Client die IP-Adresse von dagobert.tcpip-grundlagen.de nicht bekannt ist. Der DNS-Server antwortet in Frame Nr. 2 erwartungsgemäß in seiner Answer Section mit der IP-Adresse Zur vollständigen Adressierung des Zielrechners muss jetzt allerdings noch seine Hardware-Adresse (MAC-Adresse) ermittelt werden. Zu diesem Zweck wird vom Sender ( ) ein ARP-Request als Broadcast verschickt (dabei liefert er die eigene IP- Adresse samt Hardware-Adresse mit und initialisiert das Feld für die MAC-Adresse des Empfängers mit Nullen siehe Abbildung 1-26).

27 26 TCP/IP im Internet Abb ARP-Request zur MAC-Adressenermittlung Abb ARP-Response

28 Einrichtung eines DNS-Servers 27 Aus Abbildung 1-27 geht hervor, dass der Zielrechner ( ) diesen Broadcast vollständig beantwortet, wobei er das Null-Feld mit seiner tatsächlichen Hardware-Adresse ersetzt (Frame Nr. 4). Da der Sender ( ) nun die Hardware-Adresse des Zielrechners ( ) kennt, kann das»ping«-kommando nun ausgeführt werden (Frame Nr. 5 bis 12 das Kommando löst insgesamt vier ECHO REQUEST/ECHO RESPONSE-Pakete aus). Abb Beteiligte Rechner Die grafische Übersicht aller beteiligter Rechner ist Abbildung 1-28 zu entnehmen Dynamic DNS (DDNS) Unter Dynamic DNS versteht man die automatische Anpassung der Namensauflösung bei Änderung der IP-Adresse eines Clients. Dies bezieht sich sowohl auf den Forward- (Auflösung vom Namen zur IP-Adresse) als auch auf den Reverse-Prozess (Auflösung von IP- Adresse zum Namen). Dynamic DNS wird insbesondere bei einer dynamischen Verwaltung von IP-Adressen, dem DHCP (Dynamic Host Configuration Protocol, gemäß RFC 2131), benötigt. Die dazu erforderlichen technischen Details sind in RFC 2136»Dynamic Updates in the Domain Name System (DNS UPDATE)«vom April 1997 nachzulesen.

29 28 TCP/IP im Internet Konfiguration unter LINUX Die DDNS-Konfiguration unter LINUX (oder anderen UNIX-basierten Systemen) erfolgt durch eine Parametrisierung der Datei named.conf im zone statement. Hier wird unter der Option allow-update die IP-Adresse des Rechners (es können auch ganze IP-Subnetze oder Teile hieraus zugelassen werden) eingetragen, der ein DNS-Update durchführen darf: zone "tcpip-grundlagen.de" IN { type master file "named.tcpip-grundlagen.de" allow-update { } allow-query { any } notify yes } In diesem Fall darf den DNS-Update lediglich der Rechner und sämtliche Rechner des Subnetzes / durchführen (Ausnahme: Rechner ). Alle anderen Update-Requests werden abgelehnt. Der DNS-Update funktioniert nur dann, wenn der erforderliche Eintrag auch für die jeweilige Reverse-Domain eingetragen wird: zone "1.10.in-addr.arpa" IN { type master file "named.10.1" check-names fail allow-update { ! /16 } allow-query { any } notify yes }. Konfiguration unter Windows 2000 Advanced Server Wie bereits in der Einleitung dieses Abschnitts erwähnt, entsteht insbesondere bei Verwendung des DHCP-Dienstes der Wunsch nach einer dynamischen Verwaltung von DNS-Namen. Nach Einrichtung des DHCP-Dienstes (Abbildung 1-29) wird der Server goofy markiert und mit der rechten Maustaste das Kontextmenü eingeblendet. Abb Einrichtung des DHCP-Dienstes

30 Einrichtung eines DNS-Servers 29 Hier selektiert man»eigenschaften«und erhält innerhalb des»dns-tabs«die Möglichkeit, Einstellungen zum Betrieb des Dynamic DNS durchzuführen (Abbildung 1-30). Abb Konfiguration des Dynamic DNS (DDNS) Bei einer Adressänderung (z. B. innerhalb des DHCP-Betriebs) sendet der Client dem DNS- Server eine Registrierungsbenachrichtigung (notify) und veranlasst diesen, den A-Record in seiner DNS-Datenbasis zu ändern. Handelt es sich bei diesem Client um einen DHCP- Client, so sendet er seinem DHCP-Server gemeinsam mit seinem Namen die DHCP-Option 81. Dies veranlasst den DHCP-Server, die neue Namens-Adresszuordnung dem DNS-Server mitzuteilen (Registrierung eines PTR-Records), der dann anschließend seine Datenbasis aktualisiert. Clients, die keine DHCP-Clients sind, führen sowohl A-Record- als auch PTR-Record- Registrierungsbenachrichtigungen durch. Diese Verfahrensweise gilt auch dann, wenn der DHCP-Server die DHCP-Option 81 nicht kennt und darauf nicht entsprechend reagieren kann. Zur gesicherten Übertragung von DNS-Aktualisierungen wurden bei DDNS die Ressource-Records TKEY (Übertragung von Sicherheitskennzeichen meist durch Verwendung von Kerberos zur gegenseitigen Identifikation von Client und Server) und TSIG (Übertragung von Signaturen siehe Kapitel 4) eingeführt. Sie sorgen dafür, dass die DNS-Datenbasis nur durch identifizierte und berechtigte Kommunikationspartner verändert werden können.

31 30 TCP/IP im Internet Zusammenspiel von DNS und Active Directory Verzeichnisdienste repräsentieren umfangreiche Datensammlungen, die möglichst viele und unterschiedliche Unternehmensressourcen in einer einzigen Datenbank zusammenführen. Diese Datenbank wird zur Adressierung, Dokumentation und Inventarisierung eingesetzt und liefert dem Unternehmen eine solide Planungs- und Administrationsgrundlage. Auch wenn es unterschiedliche Verzeichnisdienste gibt, scheinen sich die»active Directory Services«(ADS) aus dem Hause Microsoft zumindest auf allen Windows-Plattformen durchzusetzen. Es ist allerdings von entscheidender Bedeutung, dass bei einer Planung und Einführung von ADS der Integration von DNS besondere Aufmerksamkeit gewidmet wird. Active Directory Service (ADS) In einer ADS-Struktur werden Objekte und ihre Eigenschaften in so genannte»schemata«gespeichert. Dem Objekt»Benutzer«ist beispielsweise die Eigenschaft»Vorname«oder»Beschreibung«zugeordnet, wobei diese Eigenschaften natürlich mehrfach in unterschiedlichen Objekten auftreten können. Objekt-Container werden als Organisationseinheit bezeichnet und stellen den geografischen Bezug zur jeweiligen Domäne her. Die Domänenstruktur baut auf einem streng hierarchischen Konzept auf, in dem Domänen und untergeordnete Subdomänen einem umfassenden»namespace«zugewiesen werden. Dieser repräsentiert eine DNS-Namensstruktur, bestehend aus einem oder mehreren Namespace, in dem/denen die verschiedenen Domänen zusammengefasst sind. DNS-Integration Mit der Einführung des Active-Directory-Dienstes ab Windows 2000 erhält DNS nun auch für Windows-Plattformen eine besonders wichtige Bedeutung. Während die Windows-Namensauflösung im Netzwerk früher durch den WINS-Dienst und entsprechende WINS-Server übernommen wurde, erfolgt dies nunmehr über DNS. Um sich beispielsweise an einem Windows-Domänen-Controller anzumelden, erfolgt jetzt die Suche und Identifikation über DNS. Insbesondere erfolgt die Kontaktaufnahme mit einem für die Domäne zuständigen DNS-Server, sofern auf einem Domänencontroller ADS installiert ist. Bleibt die Kontaktaufnahme erfolglos, so initiiert die Installationsroutine für ADS die Einrichtung eines DNS- Servers. Voraussetzung für einen reibungslosen Einsatz von ADS ist allerdings die Verwendung der»service-einträge«(srv-records). Diese stellen eine direkte Verbin-dung zu wichtigen Diensten innerhalb des ADS her. So werden über die SRV-Records beispielsweise Domänencontroller oder andere Diensteserver ermittelt (bei UNIX-Systemen funktioniert dies allerdings erst ab BIND-Version 8.1.2). Der RFC 2782 vom Februar 2000 liefert den dazu erforderlichen technischen Hintergrund: A DNS RR for specifying the location of services (DNS SRV) Die RFCs 2136 und 2137 beschreiben die als DDNS (Dynamic DNS) definierten dynamischen DNS-Aktualisierungen (siehe Abschnitt 1.2.5). Sowohl der Windows 2000 Client, als

32 Einrichtung eines Mailservers 31 auch ein Windows 2000 DHCP Server können beim DNS-Server die erforderlichen Registrierungen vornehmen. Eine enge Verzahnung mit dem DHCP-Server ist daher auch Bestandteil einer ADS- und DDNS-Implementierung. 1.3 Einrichtung eines Mailservers Um es gleich vorweg zu nehmen: die Komplexität des -Dienstes und seiner Konfiguration lässt eine Detailbetrachtung im Rahmen dieses Buches natürlich nicht zu. Dennoch soll an einem einfachen Beispiel die Einrichtung eines lokalen Mailservers unter Verwendung der Protokolle SMTP und POP3 gezeigt werden (Abbildung 1-31). Abb Szenario eines kombinierten lokalen Mail-Systems (SMTP/POP3) Die Plattform LINUX (hier S.u.S.E Distribution 6.3) scheint mir dazu geeignet, die grundsätzliche Funktionsweise des Mailservers in seinen beiden Komponenten für den Mail-Versand (sendmail-daemon auf Basis des SMTP) und den Mail-Empfang (popper-daemon auf Basis des POP3-Protokolls) darzustellen. In den nun folgenden Abschnitten sollen die einzelnen Schritte erläutert werden, die für die Konfiguration des Mailservers erforderlich sind: Sendmail-Konfiguration Einrichtung der Mail-Accounts Der MX-Record Einrichtung des POP3-Dienstes Konfiguration eines Mail-Clients unter Windows 2000 Abschließend werden anhand eines Netzwerk-Traces der Mail-Datenfluss gezeigt sowie die Einträge in der Mail-Logdatei /var/log/mail.

33 32 TCP/IP im Internet Sendmail-Konfiguration Der Sendmail-Prozess wird in unserem Beispiel nach Konfiguration als sendmail-daemon gestartet und wartet im so genannten»listen«-modus auf TCP-Verbindungen an der Portadresse 25 (SMTP). Er stellt gewissermaßen den SMTP-Server-Prozess dar. Das sehr empfehlenswerte wie umfangreiche Referenzwerk zum Thema»sendmail«(Verlag O Reilly) von Bryan Costales und Eric Allman gewährt einen tiefen Einblick in die Möglichkeiten der weiterführenden Sendmail-Konfiguration. In unserem Konfigurationsszenario wird die Administrationssoftware YAST gestartet und zunächst eine gültige Konfigurationsdatei sendmail.cf generiert, indem die Menüpunkte»Administration des Systems«,»Netzwerk konfigurieren«,»sendmail konfigurieren«und»rechner mit permanenter Netzverbindung (SMTP)«selektiert bzw. aktiviert werden. Nach Abschluss des Konfigurationsskriptes steht eine funktionsfähige Konfigurationsdatei rc.config und sendmail.cf im Verzeichnis /etc zur Verfügung. Auf dieser Basis werden nun einige Parameter über das YAST-Menü»Administration des Systems«und»Konfigurationsdatei verändern«angepasst (Abbildung 1-32). Abb Parametrisierung über das Administrationstool YAST Folgende Parameter und Werte sind relevant: FROM_HEADER <goofy.tcpip-grundlagen.de> SEARCHLIST <tcpip-grundlagen.de> SENDMAIL_ARGS <-bd -q30m -om> SENDMAIL_LOCALHOST <localhost tcpip-grundlagen.de> SENDMAIL_TYPE <yes> SMTP <yes> Alle anderen Werte bleiben unberücksichtigt.

34 Einrichtung eines Mailservers Einrichtung der Mail-Accounts Für die Einrichtung der Mail-Accounts werden zunächst auf dem Mailserver zwei Benutzer angelegt. Die Benutzer»user1«und»user2«werden über die Benutzerverwaltung des YAST-Menüs generiert (Abbildung 1-33). Abb Definition des Benutzers»user1«Anschließend wird eine Benutzerdatenbank angelegt, die den Benutzernamen Mail-Accounts zuordnet. Hierzu wird die Datei /etc/mail/userdb folgendermaßen editiert: user1:mailname user1@tcpip-grundlagen.de user1@tcpip-grundlagen.de:maildrop user1 Es erfolgt nun die Umwandlung des Quellcodes /etc/mail/userdb in die Datei /etc/ mail/userdb.db unter Verwendung des makemap-kommandos und des Datenbanktyps btree (btree = balanced tree). Die exakte Syntax lautet: makemap btree /etc/mail/userdb.db < /etc/mail/userdb Das im Quelltext verwendete Schlüsselwort mailname ruft ein»reverse alias«hervor, d.h. es wird der Name angegeben, unter dem ausgehende Mails des jeweiligen Benutzers gekennzeichnet werden. In unserem Beispiel erhält der Benutzer»user1«die ausgehende Mailadresse»user1@tcpip-grundlagen.de«. Das im Quelltext verwendete Schlüsselwort maildrop ermöglicht die Definition des Namens, der für die Adressierung eingehender Mails verwendet werden kann. In unserem Beispiel werden eingehende Mails für die Adresse»user1@tcpip-grundlagen.de«in den lokalen Postkorb des Benutzers»user1«gespeichert. Hier ist auch die Mehrfachnennung von

35 34 TCP/IP im Internet Empfangsadressen möglich, indem diese in der Datei /etc/mail/userdb durch Kommata getrennt werden. Beispiel: user1:maildrop Der MX-Record Der MX-Record ist ein Standard Resource Record gemäß RFC 1035 und regelt die Zuständigkeit so genannter»mail exchanger«für eine oder mehrere Domains innerhalb des Mail- Routings. Der MX-Record wird unter Verwendung folgender Syntax in die DNS-Ressourcendatei eingetragen: tcpip-grundlagen.de. IN MX 10 goofy.tcpip-grundlagen.de In unserem Beispiel ist also der»mail exchanger«goofy.tcpip-grundlagen.de für das Mail- Routing der Domain tcpip-grundlagen.de zuständig. Die Bewertungszahl 10 gibt an, dass auch weitere Server für dieselbe Domain zuständig sein können, allerdings mit einer anderen Gewichtung. Die Einträge tcpip-grundlagen.de. IN MX 10 goofy.tcpip-grundlagen.de tcpip-grundlagen.de. IN MX 20 donald.tcpip-grundlagen.de bedeuten, dass zunächst goofy für das Mail-Routing bevorzugt wird und donald erst dann zum Tragen kommt, wenn goofy nicht zur Verfügung steht. Der geringere Wert wird stets bevorzugt. Über die Bewertungszahlen von MX-Records können ausfallsichere Mail-Systeme aufgebaut werden. Die Auswahl der einzelnen Bewertungen sollte jedoch planvoll erfolgen und die Rolle der einzelnen»mail exchanger«berücksichtigen. So ist beispielsweise ein Server, der rund um die Uhr betrieben wird, dazu sicher besser geeignet als lediglich temporär verfügbare Systeme Einrichtung des POP3-Dienstes Damit auch die Mails eines Benutzers an den jeweiligen Mail-Client übertragen werden können, muss ein POP3-Dienst auf dem Mailserver aktiviert werden, der als permanenter Prozess betrieben wird. Hierzu wird in der LINUX-Startdatei /etc/inetd.conf die Zeile pop3 stream tcp nowait root /usr/sbin/tcpd popper -s eingetragen. Bei Systemstart wird dadurch der POP3-Server aktiviert und steht dann kontinuierlich für den Mail-Transport aus dem lokalen Benutzerkonto zum Mail-Client zur Verfügung.

36 Einrichtung eines Mailservers Konfiguration eines Mail-Clients unter Windows 2000 Am Beispiel von MS Outlook Express 5 unter Windows 2000 als Mail-Client sollen Konfiguration und Betrieb einer Mail-Kommunikation dargestellt werden. Alle erforderlichen Konfigurationen auf dem Serversystem (LINUX) sind nunmehr abgeschlossen, die Server-Prozesse pop3 und sendmail für SMTP sind gestartet (Stop und Start erfolgt durch /sbin/init.d/sendmail start bzw. /sbin/init.d/sendmail stop). Zur Einrichtung eines Mail-Kontos für den Benutzer»user1«wird im Menü»Extras«der Menüpunkt»Konten...«ausgewählt und unter dem Tab» «und»Hinzufügen«,»E- Mail...«der Assistent für die Kontenerstellung gestartet (Abbildungen 1-34 bis 1-38). Abb Eingabe der Kontenbeschreibung Abb Eingabe der -Adresse

37 36 TCP/IP im Internet Abb Eingabe des SMTP- und POP3- Servers (hier identisch) Abb Eingabe des Kontonamens einschließlich Passwort Abb Abschluss der Kontendefinition Jedes weitere Konto erfordert einen erneuten»durchlauf«des Mail-Assistenten.

38 Einrichtung eines Mailservers Mail-Kommunikation Unter Verwendung von Outlook Express erstellt nun»user1«eine Mail und versendet diese an»user2«. Die Mail trägt den Betreff»Kommunikationstest«(Abbildung 1-39). Abb Erstellung der Mail»Kommunikationstest«Anschließend wird die Mail versandt. Eine Kopie wird im Ordner»Gesendete Objekte«abgelegt (Abbildung 1-40). Abb Kopie der versendeten Mail im Ordner»Gesendete Objekte«

39 38 TCP/IP im Internet Ruft nun»user2«seinerseits seinen Mail-Client auf (Start von Outlook Express), der entsprechend für den Benutzer»user2«konfiguriert ist, so erfolgt der Empfang der zuvor von»user1«versendeten Mail im Ordner»Posteingang«(Abbildung 1-41). Abb Mail-Empfang im Ordner»Posteingang«Die Wahl des Produktes für den Mail-Client ist grundsätzlich unerheblich. Meist sind persönliche Präferenzen ausschlaggebend. Es muss lediglich sichergestellt sein, dass der Mail- Client über eine SMTP- (Mail-Versand) und eine POP3-Schnittstelle (Mail-Empfang) verfügt. Statt POP3 lässt sich auch das modernere IMAP-Protokoll verwenden (IMAP = Internet Mail Access Protocol). Dann muss natürlich auch der Server einen entsprechenden IMAP-Prozess betreiben. An dieser Stelle sei nochmals darauf hingewiesen, dass die -Thematik wesentlich komplexer ist als hier dargestellt. Hier geht es aber lediglich darum, an einem einfachen Beispiel die Funktionsweise zu erläutern und die beteiligten Komponenten für den Betrieb eines -Systems vorzustellen Mail-Logdatei Eine wichtige Informationsquelle für den Betrieb eines Mail-Systems ist die Logdatei /var/ log/mail. Sie liefert wichtige Informationen insbesondere bei Fehlersituationen, die eine weitere Analyse erfordern.

40 Einrichtung eines Webservers 39 Beispiel:... Aug 19 12:48:18 goofy sendmail[153]: starting daemon (8.9.3): Aug 19 13:02:16 goofy popper[225]: Stats: user Aug 19 13:02:40 goofy sendmail[227]: NAA00227: from=<user1@tcpip-grundlagen.de>, size=1169, class=0, pri=31169, nrcpts=1, msgid=<000901c009cc$e38a3d80$ a@glnbook>, proto=smtp, relay=daisy.tcpip-grundlagen.de [ ] Aug 19 13:02:40 goofy sendmail[228]: NAA00227: to=<user1@tcpip-grundlagen.de>, ctladdr=<user1@tcpip-grundlagen.de> (501/100), delay=00:00:00, xdelay=00:00:00, mailer=local, stat=sent Aug 19 13:02:53 goofy popper[230]: Stats: user Aug 19 15:00:50 goofy popper[399]: Stats: user Aug 19 15:02:47 goofy sendmail[401]: PAA00401: from=<user1@tcpip-grundlagen.de>, size=1389, class=0, pri=31389, nrcpts=1, msgid=<000801c009dd$ab65c5d0$ a@glnbook>, proto=smtp, relay=daisy.tcpip-grundlagen.de [ ] Aug 19 15:02:47 goofy sendmail[402]: PAA00401: to=<user2@tcpip-grundlagen.de>, ctladdr=<user1@tcpip-grundlagen.de> (501/100), delay=00:00:00, xdelay=00:00:00, mailer=local, stat=sent Aug 19 15:04:16 goofy popper[404]: Stats: user Aug 19 15:04:17 goofy popper[405]: Stats: user Einrichtung eines Webservers In der Welt des»world Wide Web«bildet der Webserver die zentrale Plattform für das Veröffentlichen von Informationen jeglicher Art. Dabei hat sich die Web-Technologie innerhalb der letzten Jahre zu einem vielschichtigen Instrumentarium für die Präsentation multimedialer Inhalte entwickelt. Hat man sich anfangs noch damit begnügt, einfache HTML- Seiten zu entwickeln und diese»ins Web zu stellen«, so werden heutige Websites mit werbewirksamen Flash-Technologien und komplexen Anwendungen angereichert und stellen für den neuen Markt des»e-commerce«eine solide Grundlage dar. Auch für diesen Abschnitt gilt: Beschränkung auf das Notwendigste, da der Rahmen dieses Buches keine Detailbetrachtungen zu Webservern und ihren Möglichkeiten zulässt. Auf den nächsten Seiten soll die Installation und Konfiguration zweier Webserver dargestellt werden, die im Internet mittlerweile die Hauptrolle spielen. Das ist einerseits der»internet Information Server«aus dem Hause Microsoft und andererseits für die UNIX-Plattform der»apache«-server. Letzterer ist an keinen Hersteller gebunden, sondern wurde durch amerikanische Steuergelder finanziert und unter Regie des NCSA (National Center for Supercomputing Applications) entwickelt und steht somit der Allgemeinheit zur Verfügung (Download unter