Index: head/de_DE.ISO8859-1/books/handbook/network-servers/chapter.xml =================================================================== --- head/de_DE.ISO8859-1/books/handbook/network-servers/chapter.xml (revision 48617) +++ head/de_DE.ISO8859-1/books/handbook/network-servers/chapter.xml (revision 48618) @@ -1,6535 +1,6488 @@ Netzwerkserver Übersicht Dieses Kapitel beschreibt einige der häufiger verwendeten Netzwerkdienste auf &unix;-Systemen. Dazu zählen Installation und Konfiguration sowie Test und Wartung verschiedener Netzwerkdienste. Zusätzlich sind im ganzen Kapitel Beispielkonfigurationen als Referenz enthalten. Nachdem Sie dieses Kapitel gelesen haben, werden Sie Den inetd-Daemon konfigurieren können. Wissen, wie das Network File System (NFS) eingerichtet wird. Einen Network Information Server (NIS) einrichten können, um damit Benutzerkonten im Netzwerk zu verteilen. Wissen, wie Sie &os; einrichten, um als LDAP-Server oder -Client zu agieren. Rechner durch Nutzung von DHCP automatisch für ein Netzwerk konfigurieren können. In der Lage sein, einen Domain Name Server (DNS) einzurichten. Den Apache HTTP-Server konfigurieren können. Wissen, wie man einen File Transfer Protocol (FTP)-Server einrichtet. Mit Samba einen Datei- und Druckserver für &windows;-Clients konfigurieren können. Unter Nutzung des NTP-Protokolls Datum und Uhrzeit synchronisieren sowie einen Zeitserver installieren können. Wissen, wie man den Standard-Protokollierungsdienst, syslogd, konfiguriert, um Protokolle von anderen Hosts zu akzeptieren. Wissen, wie iSCSI eingerichtet wird. Dieses Kapitel setzt folgende Grundkenntnisse voraus: /etc/rc-Skripte. Netzwerkterminologie Installation zusätzlicher Software von Drittanbietern (). Der <application>inetd</application> <quote>Super-Server</quote> Überblick &man.inetd.8; wird manchmal auch als Internet Super-Server bezeichnet, weil er Verbindungen für viele Dienste verwaltet. Wenn eine Verbindung eintrifft, bestimmt inetd, welches Programm für die eingetroffene Verbindung zuständig ist, aktiviert den entsprechenden Prozess und reicht den Socket an ihn weiter (der Socket dient dabei als Standardein- und -ausgabe sowie zur Fehlerbehandlung). Der Einsatz des inetd-Daemons an Stelle viele einzelner Daemonen kann auf nicht komplett ausgelasteten Servern zu einer Verringerung der Systemlast führen. inetd wird vor allem dazu verwendet, andere Daemonen zu aktivieren, einige Protokolle werden aber auch direkt verwaltet. Dazu gehören chargen, auth, sowie daytime. Dieser Abschnitt beschreibt die Konfiguration von inetd durch Kommandozeilenoptionen sowie die Konfigurationsdatei /etc/inetd.conf. Einstellungen inetd wird durch das &man.rc.8;-System initialisiert. Die Option inetd_enable ist in der Voreinstellung auf NO gesetzt. Es kann durch den Eintrag inetd_enable="YES" in /etc/rc.conf aktiviert werden. inetd wird jetzt beim Systemstart gestartet. Über den Befehl &prompt.root; service inetd rcvar können Sie die aktuelle Konfiguration abfragen. Weitere Optionen können über die Option inetd_flags an inetd übergeben werden. Kommandozeilenoptionen Wie die meisten anderen Server-Daemonen lässt sich auch inetd über verschiedene Optionen steuern. Eine vollständige Liste dieser Optionen finden Sie in &man.inetd.8;. Die verschiedenen Optionen können über die Option inetd_flags der Datei /etc/rc.conf an inetd übergeben werden. In der Voreinstellung hat diese Option den Wert -wW -C 60. Durch das Setzen dieser Werte wird das TCP-Wrapping für alle inetd-Dienste aktiviert. - Zusätzlich kann eine einzelne IP-Adresse jeden Dienst + Zusätzlich kann eine einzelne IP-Adresse jeden Dienst nur maximal 60 Mal pro Minute anfordern. Für Einsteiger ist es erfreulich, dass diese Parameter in der Regel nicht angepasst werden müssen. Da diese Parameter aber dennoch von Interesse sein können (beispielsweise, wenn Sie eine enorme Anzahl von Verbindungsanfragen erhalten), werden einige dieser einschränkenden Parameter im Folgenden näher erläutert. Eine vollständige Liste aller Optionen finden Sie in &man.inetd.8;. -c maximum Legt die maximale Anzahl von parallen Aufrufen eines Dienstes fest; in der Voreinstellung gibt es keine Einschränkung. Diese Einstellung kann für jeden Dienst durch Setzen des -Parameters festgelegt werden. -C rate Legt fest, wie oft ein Dienst von einer einzelnen - IP-Adresse in einer Minute aufgerufen werden kann; in der + IP-Adresse in einer Minute aufgerufen werden kann; in der Voreinstellung gibt es keine Einschränkung. Dieser Wert kann für jeden Dienst durch Setzen des Parameters festgelegt werden. -R rate Legt fest, wie oft ein Dienst in der Minute aktiviert werden kann; in der Voreinstellung sind dies 256 Aktivierungen pro Minute. Ein Wert von 0 erlaubt unbegrenzt viele Aktivierungen. -s maximum Legt fest, wie oft ein Dienst in der Minute von einer - einzelnen IP-Adresse aus aktiviert werden kann; in der + einzelnen IP-Adresse aus aktiviert werden kann; in der Voreinstellung gibt es hier keine Beschränkung. Diese Einstellung kann für jeden Dienst durch die Angabe angepasst werden. <filename>inetd.conf</filename> Die Konfiguration von inetd erfolgt über /etc/inetd.conf. Wenn /etc/inetd.conf geändert wird, kann inetd veranlasst werden, seine Konfigurationsdatei neu einzulesen. Die <application>inetd</application>-Konfiguration neu einlesen &prompt.root; service inetd reload Jede Zeile der Konfigurationsdatei beschreibt jeweils einen Daemon. Kommentare beginnen mit einem #. Ein Eintrag der Datei /etc/inetd.conf hat folgenden Aufbau: service-name socket-type protocol {wait|nowait}[/max-child[/max-connections-per-ip-per-minute[/max-child-per-ip]]] user[:group][/login-class] server-program server-program-arguments Ein Eintrag für den IPv4 verwendenden &man.ftpd.8;-Daemon könnte so aussehen: ftp stream tcp nowait root /usr/libexec/ftpd ftpd -l service-name Der Dienstname eines bestimmten Daemons. Er muss einem in /etc/services aufgelisteten Dienst entsprechen. In dieser Datei wird festgelegt, welchen Port inetd abhören muss. Wenn ein neuer Dienst erzeugt wird, muss er zuerst in die Datei /etc/services eingetragen werden. socket-type Entweder stream, dgram, raw, oder seqpacket. stream muss für verbindungsorientierte TCP-Daemonen verwendet werden, während dgram das UDP-Protokoll verwaltet. protocol Eines der folgenden: Protokoll Bedeutung tcp, tcp4 TCP (IPv4) udp, udp4 - UDP (IPv4) + UDP (IPv4) tcp6 TCP (IPv6) udp6 - UDP (IPv6) + UDP (IPv6) tcp46 TCP sowohl unter IPv4 als auch unter IPv6 udp46 - UDP sowohl unter IPv4 als auch unter IPv6 + UDP sowohl unter IPv4 + als auch unter IPv6 {wait|nowait}[/max-child[/max-connections-per-ip-per-minute[/max-child-per-ip]]] gibt an, ob der von inetd aktivierte Daemon seinen eigenen Socket verwalten kann oder nicht. -Sockets müssen die Option verwenden, während Daemonen mit Stream-Sockets, die normalerweise auch aus mehreren Threads bestehen, die Option verwenden sollten. Die Option gibt in der Regel mehrere Sockets an einen einzelnen Daemon weiter, während für jeden neuen Socket einen Childdaemon erzeugt. Die maximale Anzahl an Child-Daemonen, die inetd erzeugen kann, wird durch die Option festgelegt. Wenn ein bestimmter Daemon 10 Instanzen benötigt, sollte der Wert /10 hinter die Option gesetzt werden. Geben Sie hingegen den Wert /0 an, gibt es keine Beschränkung. Zusätzlich zu kann die maximale Anzahl von Verbindungen eines Rechners mit einem bestimmten Daemon durch zwei weitere Optionen beschränkt werden. Die Option legt die maximale Anzahl von Verbindungsversuchen fest, - die von einer bestimmten IP-Adresse aus unternommen werden + die von einer bestimmten IP-Adresse aus unternommen werden können. Ein Wert von zehn würde die maximale - Anzahl von Verbindungsversuchen einer IP-Adresse mit einem + Anzahl von Verbindungsversuchen einer IP-Adresse mit einem bestimmten Dienst auf zehn Versuche in der Minute beschränken. Durch die Angabe der Option können Sie hingegen festlegen, wie viele Child-Daemonen von einer bestimmten - IP-Adresse aus gestartet werden können. Durch diese + IP-Adresse aus gestartet werden können. Durch diese Optionen lassen sich ein absichtlicher oder unabsichtlicher Ressourcenverbrauch sowie die Auswirkungen eines Denial of Service (DoS)-Angriffs auf einen Rechner begrenzen. Sie müssen hier entweder oder angeben. Die Angabe von , und ist hingegen optional. Ein multithread-Daemon vom Streamtyp ohne die Optionen , oder sieht so aus: nowait Der gleiche Daemon mit einer maximal möglichen Anzahl von 10 parallelen Daemonen würde so aussehen: nowait/10 Wird zusätzlich die Anzahl der möglichen - Verbindungen pro Minute für jede IP-Adresse auf + Verbindungen pro Minute für jede IP-Adresse auf 20 sowie die mögliche Gesamtzahl von Childdaemonen auf 10 begrenzt, so sieht der Eintrag so aus: nowait/10/20 All diese Optionen werden vom &man.fingerd.8;-Daemon bereits in der Voreinstellung verwendet: finger stream tcp nowait/3/10 nobody /usr/libexec/fingerd fingerd -s Will man die maximale Anzahl von Child-Daemonen auf - 100 beschränken, wobei von jeder IP-Adresse aus + 100 beschränken, wobei von jeder IP-Adresse aus maximal 5 Child-Daemonen gestartet werden dürfen, verwendet man den folgenden Eintrag: nowait/100/0/5. user Der Benutzername, unter dem der jeweilige Daemon laufen soll. Meistens laufen Daemonen als User root. Aus Sicherheitsgründen laufen einige Server aber auch als User daemon, oder als am wenigsten privilegierter User nobody. server-program Der vollständige Pfad des Daemons, der eine Verbindung entgegennimmt. Wird der Daemon von inetd intern bereitgestellt, sollte die Option verwendet werden. server-program-arguments Dieser Eintrag legt (gemeinsam mit und beginnend mit argv[0]), die Argumente fest, die bei der Aktivierung an den Daemon übergeben werden. Wenn die Anweisung auf der Kommandozeile also mydaemon -d lautet, wäre mydaemon -d auch der Wert der Option . Wenn es sich beim Daemon um einen internen Dienst handelt, sollte wiederum die Option verwendet werden. Sicherheit Abhängig von der bei der Installation festgelegten Konfiguration werden viele der von inetd verwalteten Dienste automatisch aktiviert! Wenn Sie einen bestimmten Daemon nicht benötigen, sollten Sie ihn deaktivieren! Dazu kommentieren Sie den jeweiligen Daemon in /etc/inetd.conf mit einem # aus, um danach die inetd-Konfiguration neu einzulesen. Einige Daemonen, zum Beispiel fingerd, sollten generell deaktiviert werden, da sie zu viele Informationen an einen potentiellen Angreifer liefern. Einige Daemonen sind nicht auf Sicherheit bedacht und haben lange oder nicht existierende Timeouts für Verbindungsversuche. Ein Angreifer kann dies ausnutzen, um Verbindungen zu bestimmten Daemonen aufzubauen und somit die verfügbaren Ressourcen zu verbrauchen, was zu einem Denial of Service (DOS) führen kann. max-connections-per-ip-per-minute, max-child und max-child-per-ip können verwendet werden, um solche Angriffe zu begrenzen. TCP-Wrapping ist in der Voreinstellung aktiviert. Lesen Sie &man.hosts.access.5;, wenn Sie weitere Informationen zum Setzen von TCP-Beschränkungen für verschiedene von inetd aktivierte Daemonen benötigen. Verschiedenes Bei daytime, time, echo, discard, chargen, und auth handelt es sich um intern von inetd bereitgestellte Dienste. Der auth-Dienst bietet Identifizierungsdienste über das Netzwerk an und ist bis zu einem bestimmten Grad konfigurierbar, während die meisten anderen Dienste nur aktiviert oder deaktiviert werden können. Eine ausführliche Beschreibung finden Sie in &man.inetd.8;. Network File System (<acronym>NFS</acronym>) NFS &os; unterstützt das Netzwerkdateisystem NFS, das es einem Server erlaubt, Dateien und Verzeichnisse über ein Netzwerk mit Clients zu teilen. Mit NFS können Benutzer und Programme auf Daten entfernter Systeme zugreifen, und zwar so, als ob es sich um lokal gespeicherte Daten handeln würde. Die wichtigsten Vorteile von NFS sind: Daten, die sonst auf jeden Client dupliziert würden, können an einem zentralen Ort aufbewahrt, und von den Clients über das Netzwerk aufgerufen werden. Die Heimatverzeichnisse der Benutzer werden an einem zentralen Ort gespeichert und den Benutzern über das Netzwerk zur Verfügung gestellt. Die Verwaltung der NFS-Exporte wird vereinfacht. Zum Beispiel gibt es dann nur noch ein Dateisystem, für das Sicherheits- oder Backup-Richtlinien festgelegt werden müssen. Wechselmedien können von anderen Maschinen im Netzwerk verwendet werden. Dies reduziert die Anzahl von Geräten im Netzwerk und bietet einen zentralen Ort für die Verwaltung. Oft ist es einfacher, über ein zentrales Installationsmedium Software auf mehreren Computern zu installieren. NFS besteht aus zwei Hauptteilen: Einem Server und einem oder mehreren Clients. Der Client greift über das Netzwerk auf die Daten zu, die auf dem Server gespeichert sind. Damit dies korrekt funktioniert, müssen einige Prozesse konfiguriert und gestartet werden: Folgende Daemonen müssen auf dem Server ausgeführt werden: NFS Server Dateiserver Unix-Clients rpcbind mountd nfsd Daemon Beschreibung nfsd Der NFS-Daemon. Er bearbeitet Anfragen der NFS-Clients. mountd Der NFS-Mount-Daemon. Er bearbeitet die Anfragen, die &man.nfsd.8; an ihn weitergibt. rpcbind Der Portmapper-Daemon. Durch ihn erkennen die NFS-Clients, welchen Port der NFS-Server verwendet. Der Einsatz von &man.nfsiod.8; ist nicht zwingend erforderlich, kann aber die Leistung auf dem Client verbessern. <acronym>NFS</acronym> einrichten NFS einrichten NFS lässt sich leicht aktivieren. Die nötigen Prozesse werden durch das Hinzufügen der folgenden Optionen in /etc/rc.conf bei jedem Systemstart ausgeführt: rpcbind_enable="YES" nfs_server_enable="YES" mountd_flags="-r" mountd läuft automatisch, wenn der NFS-Server aktiviert ist. Um den Client zu aktivieren, muss folgende Option in /etc/rc.conf gesetzt werden: nfs_client_enable="YES" /etc/exports legt fest, welche Dateisysteme NFS exportieren soll. Jede Zeile in /etc/exports beschreibt ein zu exportierendes Dateisystem, Clients, die darauf Zugriff haben sowie alle Zugriffsoptionen. Es gibt viele verschiedene Optionen, allerdings werden hier nur wenige von ihnen erwähnt. Eine vollständige Liste der Optionen finden Sie in &man.exports.5;. NFS Export von Dateisystemen Die folgenden Beispiele geben Anhaltspunkte zum Exportieren von Dateisystemen, obwohl diese Einstellungen natürlich von der Arbeitsumgebung und der Netzwerkkonfiguration abhängen. Dieses Beispiel exportiert /cdrom für drei Clients, alpha, bravo und charlie: /cdrom -ro alpha bravo charlie Die Option kennzeichnet das exportierte Dateisystem als schreibgeschützt. Dadurch sind Clients nicht in der Lage, das exportierte Dateisystem zu verändern. Das nächste Beispiel exportiert /home auf drei durch IP-Adressen bestimmte Clients. Diese Einstellung kann für Netzwerke ohne DNS-Server nützlich sein. Optional können interne Rechnernamen auch in /etc/hosts konfiguriert werden. Benötigen Sie hierzu weitere Informationen, lesen Sie bitte &man.hosts.5;. Die Option ermöglicht es, auch Unterverzeichnisse als Mountpunkte festzulegen. Dies bedeutet aber nicht, dass alle Unterverzeichnisse eingehängt werden, vielmehr wird es dem Client ermöglicht, nur diejenigen Verzeichnisse einzuhängen, die auch benötigt werden. /home -alldirs 10.0.0.2 10.0.0.3 10.0.0.4 Die nächste Zeile exportiert /a, damit Clients von verschiedenen Domänen auf das Dateisystem zugreifen können. Die Option erlaubt es dem Benutzer root des Clients, als root auf das exportierte Dateisystem zu schreiben. Wenn diese Option nicht gesetzt ist, wird der root-Benutzer des Clients dem nobody-Konto des Servers zugeordnet und unterliegt somit den Zugriffsbeschränkungen dieses Kontos. /a -maproot=root host.example.com box.example.org Damit ein Client auf ein exportiertes Dateisystem zugreifen kann, muss er in /etc/exports eingetragen sein. Jede Zeile in /etc/exports entspricht der Exportinformation für ein Dateisystem auf einem oder mehreren Clients. Ein entfernter Rechner kann für jedes Dateisystem nur einmal definiert werden. Nehmen wir an, dass /usr ein gesondertes Dateisystem ist. Dann wären folgende Zeilen in /etc/exports ungültig: #Nicht erlaubt, wenn /usr ein einziges Dateisystem ist /usr/src client /usr/ports client Das Dateisystem /usr wird hier zweimal auf den selben Rechner (client) exportiert. Dies ist aber nicht zulässig. Der korrekte Eintrag sieht daher so aus: /usr/src /usr/ports client Die Eigenschaften eines auf einen anderen Rechner exportierten Dateisystems müssen alle in einer Zeile stehen. Wird in einer Zeile kein Rechner festgelegt, dürfen alle Clients im Netzwerk das exportierte Dateisystem einhängen. Eine gültige Exportliste, in der /usr und /exports lokale Dateisysteme sind, sieht so aus: # Export src and ports to client01 and client02, but only # client01 has root privileges on it /usr/src /usr/ports -maproot=root client01 /usr/src /usr/ports client02 # The client machines have root and can mount anywhere # on /exports. Anyone in the world can mount /exports/obj read-only /exports -alldirs -maproot=root client01 client02 /exports/obj -ro Wenn der NFS-Server startet, wird auch mountd automatisch gestartet. Allerdings liest mountd /etc/exports nur, wenn der Server gestartet wird. Um nachfolgende Änderungen an /etc/exports wirksam werden zu lassen, kann mountd angewiesen werden, die Datei neu einzulesen: &prompt.root; service mountd reload Lesen Sie bitte des Handbuchs für Informationen zum Einsatz der rc-Skripte. Die NFS-Dienste können nun auf dem Server als root gestartet werden: &prompt.root; service nfsd start Auf dem NFS-Client: &prompt.root; service nfsclient restart Der Client ist nun in der Lage, ein entferntes Dateisystem einzuhängen. In diesen Beispielen ist der Name des Servers server und der Name des Clients client. Für Testzwecke oder zum temporären einhängen eines entfernten Dateisystems, führen Sie auf dem Rechner client den Befehl mountals root aus: NFS Dateisysteme einhängen &prompt.root; mount server:/home /mnt Die Dateien und Verzeichnisse in /home stehen dem Rechner client nun im Verzeichnis /mnt zur Verfügung. Um ein entferntes Dateisystem bei jedem Systemstart automatisch einzuhängen, fügen Sie das Dateisystem in /etc/fstab ein: server:/home /mnt nfs rw 0 0 &man.fstab.5; enthält eine Beschreibung aller Optionen. Dateien sperren (<foreignphrase>Locking</foreignphrase>) Einige Anwendungen erfordern die Sperrung von Dateien, damit sie korrekt arbeiten. Um diese Sperre zu aktivieren, müssen diese Zeilen in /etc/rc.conf sowohl auf dem Client als auch auf dem Server hinzugefügt werden: rpc_lockd_enable="YES" rpc_statd_enable="YES" Danach starten Sie die beiden Anwendungen: &prompt.root; service lockd start &prompt.root; service statd start Wenn keine Dateisperren zwischen den NFS-Clients und dem NFS-Server benötigt werden, können Sie den NFS-Client durch die Übergabe der Option an &man.mount.nfs.8; zu einer lokalen Sperrung von Dateien zwingen. Weitere Details finden Sie in &man.mount.nfs.8;. Praktische Anwendungen NFS ist in vielen Situationen nützlich. Einige Anwendungsbereiche finden Sie in der folgenden Liste: NFS Anwendungsbeispiele Mehrere Maschinen können sich ein CD-ROM-Laufwerk oder andere Medien teilen. Dies ist praktisch, um Programme von einem einzelnen Standort aus auf mehreren Rechnern zu installieren. In größeren Netzwerken ist es praktisch, einen zentralen NFS-Server einzurichten, auf dem die Heimatverzeichnisse der Benutzer gespeichert werden. Dadurch steht den Benutzern immer das gleiche Heimatverzeichnis zur Verfügung, unabhängig davon, an welchem Client im Netzwerk sie sich anmelden. Verschiedene Clients können auf ein gemeinsames Verzeichnis /usr/ports/distfiles zugreifen. Die gemeinsame Nutzung dieses Verzeichnisses ermöglicht einen schnellen Zugriff auf die Quelldateien, ohne sie auf jede Maschine zu kopieren zu müssen. <application>amd</application> amd Automatic Mounter Daemon &man.amd.8; (Automatic Mounter Daemon) hängt ein entferntes Dateisystem automatisch ein, wenn auf eine Datei oder ein Verzeichnis in diesem Dateisystem zugegriffen wird. Dateisysteme, die über einen gewissen Zeitraum inaktiv sind, werden von amd automatisch abgehängt. amd ist eine Alternative zum dauerhaften Einhängen von Dateisystemen in /etc/fstab. In der Voreinstellung stellt amd die Verzeichnisse /host und /net als NFS-Server bereit. Wenn auf eine Datei in diesen Verzeichnissen zugegriffen wird, sucht amd den entsprechenden Mountpunkt und hängt das Dateisystem automatisch ein. /net wird zum Einhängen von - exportierten Dateisystemen von einer IP-Adresse verwendet, + exportierten Dateisystemen von einer IP-Adresse verwendet, während /host zum Einhängen von exportierten Dateisystemen eines durch seinen Namen festgelegten Rechners dient. Ein Zugriff auf eine Datei in /host/foobar/usr würde amd veranlassen, das von foobar exportierte Dateisystem /usr einzuhängen. Ein exportiertes Dateisystem mit <application>amd</application> in den Verzeichnisbaum einhängen showmount -e zeigt die exportierten Dateisysteme des NFS-Servers foobar an: &prompt.user; showmount -e foobar Exports list on foobar: /usr 10.10.10.0 /a 10.10.10.0 &prompt.user; cd /host/foobar/usr Die Ausgabe von showmount zeigt /usr als exportiertes Dateisystem an. Wenn man in das Verzeichnis /host/foobar/usr wechselt, fängt amd die Anfrage ab und versucht den Rechnernamen foobar aufzulösen. Wenn dies gelingt, wird amd automatisch den gewünschten Export in den Verzeichnisbaum einhängen. amd kann durch folgende Zeile in /etc/rc.conf automatisch gestartet werden: amd_enable="YES" Um amd direkt zu starten: &prompt.root; service amd start Individuelle Optionen können über die Umgebungsvariable amd_flags an amd übergeben werden. In der Voreinstellung ist amd_flags eingestellt auf: amd_flags="-a /.amd_mnt -l syslog /host /etc/amd.map /net /etc/amd.map" /etc/amd.map legt die Standardoptionen fest, mit denen exportierte Dateisysteme in den Verzeichnisbaum eingehängt werden. /etc/amd.conf hingegen legt einige der erweiterten Optionen von amd fest. Weitere Informationen finden Sie in &man.amd.8; und &man.amd.conf.5;. Network Information System (<acronym>NIS</acronym>) NIS Solaris HP-UX AIX Linux NetBSD OpenBSD yellow pages NIS Das Network Information System (NIS) wurde entwickelt, um &unix;-Systeme zentral verwalten zu können. Dazu zählen beispielsweise &solaris;, HP-UX, &aix;, Linux, NetBSD, OpenBSD und &os;. NIS war ursprünglich als Yellow Pages bekannt, aus markenrechtlichen Gründen wurde der Name aber geändert. Dies ist der Grund, warum NIS-Kommandos mit yp beginnen. NIS Domänen Bei NIS handelt es sich um ein RPC-basiertes Client/Server-System. Eine Gruppe von Rechnern greift dabei innerhalb einer NIS-Domäne auf gemeinsame Konfigurationsdateien zu. Dies erlaubt es einem Systemadministrator, NIS-Clients mit minimalem Aufwand einzurichten, sowie Änderungen an der Systemkonfiguration von einem zentralen Ort aus durchzuführen. &os; verwendet die Version 2 des NIS-Protokolls. <acronym>NIS</acronym>-Begriffe und -Prozesse Tabelle 30.1 fasst die Begriffe und Anwenderprozesse zusammen, die von NIS verwendet werden: rpcbind <acronym>NIS</acronym> Begriffe Begriff Beschreibung NIS-Domänenname NIS-Masterserver und Clients benutzen einen gemeinsamen NIS-Domänennamen. In der Regel hat dieser Name nichts mit DNS zu tun. &man.rpcbind.8; Dieser Dienst aktiviert RPC und muss gestartet sein, damit ein NIS-Server oder -Client ausgeführt werden kann. &man.ypbind.8; Dieser Dienst bindet einen NIS-Client an seinen NIS-Server. Der Client bezieht den NIS-Domänennamen vom System und stellt über das RPC-Protokoll eine Verbindung zum NIS-Server her. ypbind ist der zentrale Bestandteil der Client-Server-Kommunikation in einer NIS-Umgebung. Wird der Dienst auf einem Client beendet, ist dieser nicht mehr in der Lage, auf den NIS-Server zuzugreifen. &man.ypserv.8; Dies ist der Prozess für den NIS-Server. Wenn dieser Dienst nicht mehr läuft, kann der Server nicht mehr auf NIS-Anforderungen reagieren. Wenn ein Slaveserver existiert, kann dieser als Ersatz fungieren. Einige NIS-Systeme (allerdings nicht das von &os;) versuchen allerdings erst gar nicht, sich mit einem anderen Server zu verbinden, wenn der Masterserver nicht mehr reagiert. Die einzige Lösung besteht darin, den Serverprozess oder den ypbind-Prozess auf dem Client neu zu starten. &man.rpc.yppasswdd.8; Dieser Prozess läuft nur auf dem NIS-Masterserver. Es handelt sich um einen Daemonprozess, der es NIS-Clients ermöglicht, ihre NIS-Passwörter zu ändern. Wenn dieser Daemon nicht läuft, müssen sich die Benutzer am NIS-Masterserver anmelden und ihre Passwörter dort ändern.
Arten von NIS-Rechnern NIS Masterserver NIS Slaveserver NIS Client NIS-Masterserver Dieser Server dient als zentraler Speicherort für Rechnerkonfigurationen. Zudem verwaltet er die maßgebliche Kopie, der von den NIS-Clients gemeinsam verwendeten Dateien. passwd, group, sowie verschiedene andere von den Clients verwendete Dateien existieren auf dem Masterserver. Obwohl ein Rechner auch für mehrere NIS-Domänen als Masterserver fungieren kann, wird diese Art von Konfiguration nicht behandelt, da sich dieser Abschnitt auf eine relativ kleine NIS-Umgebung konzentriert. NIS-Slaveserver NIS-Slaveserver verwalten Kopien der Daten des NIS-Masterservers um Redundanz zu bieten. Zudem entlasten Slaveserver den Masterserver: NIS-Clients verbinden sich immer mit dem NIS-Server, welcher zuerst reagiert. Dieser Server kann auch ein Slaveserver sein. NIS-Clients NIS-Clients identifizieren sich gegenüber dem NIS-Server während der Anmeldung. Mit NIS können Informationen aus verschiedenen Dateien von mehreren Rechnern gemeinsam verwendet werden. master.passwd, group, und hosts werden oft gemeinsam über NIS verwendet. Immer, wenn ein Prozess auf einem Client auf Informationen zugreifen will, die normalerweise in lokalen Dateien vorhanden wären, wird stattdessen eine Anfrage an den NIS-Server gestellt, an den der Client gebunden ist. Planung Dieser Abschnitt beschreibt eine einfache NIS-Umgebung, welche aus 15 &os;-Maschinen besteht, für die keine zentrale Verwaltung existiert. Jeder Rechner hat also eine eigene Version von /etc/passwd und /etc/master.passwd. Diese Dateien werden manuell synchron gehalten; wird ein neuer Benutzer angelegt, so muss dies auf allen fünfzehn Rechnern manuell erledigt werden. In Zukunft soll die Konfiguration wie folgt aussehen: Rechnername - IP-Adresse + IP-Adresse Rechneraufgabe ellington 10.0.0.2 NIS-Master coltrane 10.0.0.3 NIS-Slave basie 10.0.0.4 Workstation der Fakultät bird 10.0.0.5 Clientrechner cli[1-11] 10.0.0.[6-17] Verschiedene andere Clients Wenn erstmalig ein NIS-Schema eingerichtet wird, sollte es im Voraus sorgfältig geplant werden. Unabhängig von der Größe des Netzwerks müssen einige Entscheidungen im Rahmen des Planungsprozesses getroffen werden. Einen <acronym>NIS</acronym>-Domänennamen wählen NIS Domänenname Wenn ein Client Informationen anfordert, ist in dieser Anforderung der Name der NIS-Domäne enthalten. Dadurch weiß jeder Server im Netzwerk, auf welche Anforderung er antworten muss. Stellen Sie sich den NIS-Domänennamen als einen Namen einer Gruppe von Rechnern vor. Manchmal wird der Name der Internetdomäne auch für die NIS-Domäne verwendet. Dies ist allerdings nicht empfehlenswert, da es bei der Behebung von Problemen verwirrend sein kann. Der Name der NIS-Domäne sollte innerhalb des Netzwerks eindeutig sein. Hilfreich ist es, wenn der Name die Gruppe der in ihr zusammengefassten Rechner beschreibt. Die Kunstabteilung von Acme Inc. hätte daher vielleicht die NIS-Domäne acme-art. Für dieses Beispiel wird der Name test-domain verwendet. Es gibt jedoch auch Betriebssysteme, die als NIS-Domänennamen den Namen der Internetdomäne verwenden. Wenn dies für einen oder mehrere Rechner des Netzwerks zutrifft, muss der Name der Internetdomäne als NIS-Domänennamen verwendet werden. Anforderungen an den Server Bei der Wahl des NIS-Servers müssen einige Dinge beachtet werden. Da die NIS-Clients auf die Verfügbarkeit des Servers angewiesen sind, sollten Sie einen Rechner wählen, der nicht regelmäßig neu gestartet werden muss. Der NIS-Server sollte idealerweise ein alleinstehender Rechner sein, dessen einzige Aufgabe es ist, als NIS-Server zu dienen. Wenn das Netzwerk nicht zu stark ausgelastet ist, ist es auch möglich, den NIS-Server als weiteren Dienst auf einem anderen Rechner laufen zu lassen. Wenn jedoch ein NIS-Server ausfällt, wirkt sich dies negativ auf alle NIS-Clients aus. Einen <acronym>NIS</acronym>-Masterserver konfigurieren Die verbindlichen Kopien aller NIS-Dateien befinden sich auf dem Masterserver. Die Datenbanken, in denen die Informationen gespeichert sind, bezeichnet man als NIS-Maps. Unter &os; werden diese Maps unter /var/yp/[domainname] gespeichert, wobei [domainname] der Name der NIS-Domäne ist. Da ein NIS-Server mehrere Domänen verwalten kann, können auch mehrere Verzeichnisse vorhanden sein. Jede Domäne verfügt über ein eigenes Verzeichnis sowie einen eigenen, von anderen Domänen unabhängigen Satz von NIS-Maps. NIS-Master- und Slaveserver verwenden &man.ypserv.8;, um NIS-Anfragen zu bearbeiten. Dieser Daemon ist für eingehende Anfragen der NIS-Clients verantwortlich. Er ermittelt aus der angeforderten Domäne und Map einen Pfad zur entsprechenden Datenbank, und sendet die angeforderten Daten von der Datenbank zum Client. NIS Serverkonfiguration Abhängig von den Anforderungen ist die Einrichtung eines NIS-Masterservers relativ einfach, da NIS von &os; bereits in der Standardkonfiguration unterstützt wird. Es kann durch folgende Zeilen in /etc/rc.conf aktiviert werden: nisdomainname="test-domain" Diese Zeile setzt den NIS-Domänennamen auf test-domain. nis_server_enable="YES" Dadurch werden die NIS-Serverprozesse beim Systemstart automatisch ausgeführt. nis_yppasswdd_enable="YES" Durch diese Zeile wird der &man.rpc.yppasswdd.8;-Daemon aktiviert, der die Änderung von NIS-Passwörtern von einem Client aus ermöglicht. Wird ypserv in einer Multi-Serverdomäne verwendet, in der NIS-Server gleichzeitig als NIS-Clients arbeiten, ist es eine gute Idee, diese Server zu zwingen, sich an sich selbst zu binden. Damit wird verhindert, dass Bindeanforderungen gesendet werden und sich die Server gegenseitig binden. Sonst könnten seltsame Fehler auftreten, wenn ein Server ausfällt, auf den andere Server angewiesen sind. Letztlich werden alle Clients einen Timeout melden, und versuchen, sich an andere Server zu binden. Die dadurch entstehende Verzögerung kann beträchtlich sein. Außerdem kann der Fehler erneut auftreten, da sich die Server wiederum aneinander binden könnten. Server, die auch als Client arbeiten, können durch das Hinzufügen der folgenden Zeilen in /etc/rc.conf zu gezwungen werden, sich an einen bestimmten Server zu binden: nis_client_enable="YES" # run client stuff as well nis_client_flags="-S NIS domain,server" Nachdem die Parameter konfiguriert wurden, muss noch /etc/netstart ausgeführt werden, um alles entsprechend den Vorgaben in /etc/rc.conf einzurichten. Bevor die NIS-Maps einrichtet werden können, muss der &man.ypserv.8;-Daemon manuell gestartet werden: &prompt.root; service ypserv start Die <acronym>NIS</acronym>-Maps initialisieren NIS maps NIS-Maps Sie werden am NIS-Masterserver aus den Konfigurationsdateien unter /etc erzeugt. Einzige Ausnahme: /etc/master.passwd. Dies verhindert, dass die Passwörter für root- oder andere Administratorkonten an alle Server in der NIS-Domäne verteilt werden. Deshalb werden die primären Passwort-Dateien konfiguriert, bevor die NIS-Maps initialisiert werden: &prompt.root; cp /etc/master.passwd /var/yp/master.passwd &prompt.root; cd /var/yp &prompt.root; vi master.passwd Es ist ratsam, alle Einträge für Systemkonten sowie Benutzerkonten, die nicht an die NIS-Clients weitergegeben werden sollen, wie beispielsweise root und weitere administrative Konten, zu entfernen. Stellen Sie sicher, dass /var/yp/master.passwd weder von der Gruppe noch von der Welt gelesen werden kann, indem Sie Zugriffsmodus auf 600 einstellen. Nun können die NIS-Maps initialisiert werden. &os; verwendet dafür das Skript &man.ypinit.8;. Geben Sie und den NIS-Domänennamen an, wenn Sie NIS-Maps für den Masterserver erzeugen: ellington&prompt.root; ypinit -m test-domain Server Type: MASTER Domain: test-domain Creating an YP server will require that you answer a few questions. Questions will all be asked at the beginning of the procedure. Do you want this procedure to quit on non-fatal errors? [y/n: n] n Ok, please remember to go back and redo manually whatever fails. If not, something might not work. At this point, we have to construct a list of this domains YP servers. rod.darktech.org is already known as master server. Please continue to add any slave servers, one per line. When you are done with the list, type a <control D>. master server : ellington next host to add: coltrane next host to add: ^D The current list of NIS servers looks like this: ellington coltrane Is this correct? [y/n: y] y [..output from map generation..] NIS Map update completed. ellington has been setup as an YP master server without any errors. Dadurch erzeugt ypinit /var/yp/Makefile aus /var/yp/Makefile.dist. Diese Datei geht in der Voreinstellung davon aus, dass in einer NIS-Umgebung mit nur einem Server gearbeitet wird und dass alle Clients unter &os; laufen. Da test-domain aber auch über einen Slaveserver verfügt, muss /var/yp/Makefile entsprechend angepasst werden, sodass es mit einem Kommentar (#) beginnt: NOPUSH = "True" Neue Benutzer hinzufügen Jedes Mal, wenn ein neuer Benutzer angelegt wird, muss er am NIS-Masterserver hinzugefügt und die NIS-Maps anschließend neu erzeugt werden. Wird dieser Punkt vergessen, kann sich der neue Benutzer nur am NIS-Masterserver anmelden. Um beispielsweise den neuen Benutzer jsmith zur Domäne test-domain hinzufügen wollen, müssen folgende Kommandos auf dem Masterserver ausgeführt werden: &prompt.root; pw useradd jsmith &prompt.root; cd /var/yp &prompt.root; make test-domain Statt pw useradd jsmith kann auch adduser jsmith verwendet werden. Einen <acronym>NIS</acronym>-Slaveserver einrichten NIS Slaveserver Um einen NIS-Slaveserver einzurichten, melden Sie sich am Slaveserver an und bearbeiten Sie /etc/rc.conf analog zum Masterserver. Erzeugen Sie aber keine NIS-Maps, da diese bereits auf dem Server vorhanden sind. Wenn ypinit auf dem Slaveserver ausgeführt wird, benutzen Sie (Slave) statt (Master). Diese Option benötigt den Namen des NIS-Masterservers und den Domänennamen, wie in diesem Beispiel zu sehen: coltrane&prompt.root; ypinit -s ellington test-domain Server Type: SLAVE Domain: test-domain Master: ellington Creating an YP server will require that you answer a few questions. Questions will all be asked at the beginning of the procedure. Do you want this procedure to quit on non-fatal errors? [y/n: n] n Ok, please remember to go back and redo manually whatever fails. If not, something might not work. There will be no further questions. The remainder of the procedure should take a few minutes, to copy the databases from ellington. Transferring netgroup... ypxfr: Exiting: Map successfully transferred Transferring netgroup.byuser... ypxfr: Exiting: Map successfully transferred Transferring netgroup.byhost... ypxfr: Exiting: Map successfully transferred Transferring master.passwd.byuid... ypxfr: Exiting: Map successfully transferred Transferring passwd.byuid... ypxfr: Exiting: Map successfully transferred Transferring passwd.byname... ypxfr: Exiting: Map successfully transferred Transferring group.bygid... ypxfr: Exiting: Map successfully transferred Transferring group.byname... ypxfr: Exiting: Map successfully transferred Transferring services.byname... ypxfr: Exiting: Map successfully transferred Transferring rpc.bynumber... ypxfr: Exiting: Map successfully transferred Transferring rpc.byname... ypxfr: Exiting: Map successfully transferred Transferring protocols.byname... ypxfr: Exiting: Map successfully transferred Transferring master.passwd.byname... ypxfr: Exiting: Map successfully transferred Transferring networks.byname... ypxfr: Exiting: Map successfully transferred Transferring networks.byaddr... ypxfr: Exiting: Map successfully transferred Transferring netid.byname... ypxfr: Exiting: Map successfully transferred Transferring hosts.byaddr... ypxfr: Exiting: Map successfully transferred Transferring protocols.bynumber... ypxfr: Exiting: Map successfully transferred Transferring ypservers... ypxfr: Exiting: Map successfully transferred Transferring hosts.byname... ypxfr: Exiting: Map successfully transferred coltrane has been setup as an YP slave server without any errors. Remember to update map ypservers on ellington. Hierbei wird auf dem Slaveserver ein Verzeichnis namens /var/yp/test-domain erstellt, welches Kopien der NIS-Masterserver-Maps enthält. Durch hinzufügen der folgenden Zeilen in /etc/crontab wird der Slaveserver angewiesen, seine Maps mit den Maps des Masterservers zu synchronisieren: 20 * * * * root /usr/libexec/ypxfr passwd.byname 21 * * * * root /usr/libexec/ypxfr passwd.byuid Diese Einträge sind nicht zwingend notwendig, da der Masterserver automatisch versucht, alle Änderungen seiner NIS-Maps an seine Slaveserver weiterzugeben. Da Passwortinformationen aber auch für nur vom Slaveserver abhängige Systeme vital sind, ist es eine gute Idee, diese Aktualisierungen zu erzwingen. Besonders wichtig ist dies in stark ausgelasteten Netzen, in denen Map-Aktualisierungen unvollständig sein könnten. Um die Konfiguration abzuschließen, führen Sie /etc/netstart auf dem Slaveserver aus, um die NIS-Dienste erneut zu starten. Einen <acronym>NIS</acronym>-Client einrichten Ein NIS-Client bindet sich unter Verwendung von ypbind an einen NIS-Server. Dieser Daemon sendet RPC-Anfragen auf dem lokalen Netzwerk. Diese Anfragen legen den Namen der Domäne fest, die auf dem Client konfiguriert ist. Wenn der Server der entsprechenden Domäne eine solche Anforderung erhält, schickt er eine Antwort an ypbind, das wiederum die Adresse des Servers speichert. Wenn mehrere Server verfügbar sind, verwendet der Client die erste erhaltene Adresse und richtet alle Anfragen an genau diesen Server. ypbind pingt den Server gelegentlich an, um sicherzustellen, dass der Server funktioniert. Antwortet der Server innerhalb eines bestimmten Zeitraums nicht (Timeout), markiert ypbind die Domäne als ungebunden und beginnt erneut, RPCs über das Netzwerk zu verteilen, um einen anderen Server zu finden. NIS Client konfigurieren Einen &os;-Rechner als NIS-Client einrichten: Fügen Sie folgende Zeilen in /etc/rc.conf ein, um den NIS-Domänennamen festzulegen, und um &man.ypbind.8; bei der Initialisierung des Netzwerks zu starten: nisdomainname="test-domain" nis_client_enable="YES" Um alle Passworteinträge des NIS-Servers zu importieren, löschen Sie alle Benutzerkonten in /etc/master.passwd mit vipw. Denken Sie daran, zumindest ein lokales Benutzerkonto zu behalten. Dieses Konto sollte außerdem Mitglied der Gruppe wheel sein. Wenn es mit NIS Probleme gibt, können Sie diesen Zugang verwenden, um sich als Superuser anzumelden und das Problem zu beheben. Bevor Sie die Änderungen speichern, fügen Sie folgende Zeile am Ende der Datei hinzu: +::::::::: Diese Zeile legt für alle gültigen Benutzerkonten der NIS-Server-Maps einen Zugang an. Es gibt verschiedene Wege, den NIS-Client durch Änderung dieser Zeile zu konfigurieren. Eine Methode wird in beschrieben. Weitere detaillierte Informationen finden Sie im Buch Managing NFS and NIS vom O'Reilly Verlag. Um alle möglichen Gruppeneinträge vom NIS-Server zu importieren, fügen Sie folgende Zeile in /etc/group ein: +:*:: Um den NIS-Client direkt zu starten, führen Sie als Superuser die folgenden Befehle aus: &prompt.root; /etc/netstart &prompt.root; service ypbind start Danach sollte bei der Eingabe von ypcat passwd auf dem Client die passwd-Map des NIS-Servers angezeigt werden. Sicherheit unter <acronym>NIS</acronym> Da RPC ein Broadcast-basierter Dienst ist, kann jedes System innerhalb der Domäne mittels ypbind den Inhalt der NIS-Maps abrufen. Um nicht autorisierte Transaktionen zu verhindern, unterstützt &man.ypserv.8; eine Funktion namens securenets, durch die der Zugriff auf bestimmte Rechner beschränkt werden kann. In der Voreinstellung sind diese Informationen in /var/yp/securenets gespeichert, es sei denn, &man.ypserv.8; wurde mit der Option und einem alternativen Pfad gestartet. Diese Datei enthält Einträge, die aus einer Netzwerkadresse und einer Netzmaske bestehen. Kommentarzeilen beginnen mit #. /var/yp/securnets könnte beispielsweise so aussehen: # allow connections from local host -- mandatory 127.0.0.1 255.255.255.255 # allow connections from any host # on the 192.168.128.0 network 192.168.128.0 255.255.255.0 # allow connections from any host # between 10.0.0.0 to 10.0.15.255 # this includes the machines in the testlab 10.0.0.0 255.255.240.0 Wenn &man.ypserv.8; eine Anforderung von einer zu diesen Regeln passenden Adresse erhält, wird die Anforderung bearbeitet. Gibt es keine passende Regel, wird die Anforderung ignoriert und eine Warnmeldung aufgezeichnet. Wenn securenets nicht existiert, erlaubt ypserv Verbindungen von jedem Rechner. beschreibt eine alternative Methode zur Zugriffskontrolle. Obwohl beide Methoden einige Sicherheit gewähren, sind sie anfällig - für IP-Spoofing-Angriffe. Der + für IP-Spoofing-Angriffe. Der NIS-Verkehr sollte daher von einer Firewall blockiert werden. Server, die securenets verwenden, können Schwierigkeiten bei der Anmeldung von NIS-Clients haben, die ein veraltetes TCP/IP-Subsystem besitzen. Einige dieser TCP/IP-Subsysteme setzen alle Rechnerbits auf Null, wenn sie einen Broadcast durchführen oder können die Subnetzmaske nicht auslesen, wenn sie die Broadcast-Adresse berechnen. Einige Probleme können durch Änderungen der Clientkonfiguration behoben werden. Andere hingegen lassen sich nur durch das Entfernen des betreffenden Rechners aus dem Netzwerk oder den Verzicht auf securenets umgehen. TCP-Wrapper Die Verwendung der TCP-Wrapper verlangsamt die Reaktion des NIS-Servers. Diese zusätzliche Reaktionszeit kann in Clientprogrammen zu Timeouts führen. Dies vor allem in Netzwerken, die stark ausgelastet sind, oder nur über langsame NIS-Server verfügen. Wenn ein oder mehrere Clients dieses Problem aufweisen, sollten Sie die betreffenden Clients in NIS-Slaveserver umwandeln, und diese an sich selbst binden. Bestimmte Benutzer an der Anmeldung hindern In diesem Beispiel gibt es innerhalb der NIS-Domäne den Rechner basie, der nur für Mitarbeiter der Fakultät bestimmt ist. Die passwd Datenbank des NIS-Masterservers enthält Benutzerkonten sowohl für Fakultätsmitarbeiter als auch für Studenten. Dieser Abschnitt beschreibt, wie Sie den Mitarbeitern der Fakultät die Anmeldung am System ermöglichen, während den Studenten die Anmeldung verweigert wird. Es gibt eine Möglichkeit, bestimmte Benutzer an der Anmeldung an einem bestimmten Rechner zu hindern, selbst wenn diese in der NIS-Datenbank vorhanden sind. Dazu kann mit vipw der Eintrag -Benutzername und die richtige Anzahl von Doppelpunkten an das Ende von /etc/master.passwd gesetzt werden, wobei Benutzername der zu blockierende Benutzername ist. Die Zeile mit dem geblockten Benutzer muss dabei vor der + Zeile, für zugelassene Benutzer stehen. In diesem Beispiel wird die Anmeldung für den Benutzer bill am Rechner basie blockiert: basie&prompt.root; cat /etc/master.passwd root:[password]:0:0::0:0:The super-user:/root:/bin/csh toor:[password]:0:0::0:0:The other super-user:/root:/bin/sh daemon:*:1:1::0:0:Owner of many system processes:/root:/sbin/nologin operator:*:2:5::0:0:System &:/:/sbin/nologin bin:*:3:7::0:0:Binaries Commands and Source,,,:/:/sbin/nologin tty:*:4:65533::0:0:Tty Sandbox:/:/sbin/nologin kmem:*:5:65533::0:0:KMem Sandbox:/:/sbin/nologin games:*:7:13::0:0:Games pseudo-user:/usr/games:/sbin/nologin news:*:8:8::0:0:News Subsystem:/:/sbin/nologin man:*:9:9::0:0:Mister Man Pages:/usr/share/man:/sbin/nologin bind:*:53:53::0:0:Bind Sandbox:/:/sbin/nologin uucp:*:66:66::0:0:UUCP pseudo-user:/var/spool/uucppublic:/usr/libexec/uucp/uucico xten:*:67:67::0:0:X-10 daemon:/usr/local/xten:/sbin/nologin pop:*:68:6::0:0:Post Office Owner:/nonexistent:/sbin/nologin nobody:*:65534:65534::0:0:Unprivileged user:/nonexistent:/sbin/nologin -bill::::::::: +::::::::: basie&prompt.root; Netzgruppen verwenden Netzgruppen Bestimmten Benutzern die Anmeldung an einzelnen Systemen zu verweigern, kann in großen Netzwerken schnell unübersichtlich werden. Dadurch verlieren Sie den Hauptvorteil von NIS: die zentrale Verwaltung. Netzgruppen wurden entwickelt, um große, komplexe Netzwerke mit Hunderten Benutzern und Rechnern zu verwalten. Ihre Aufgabe ist vergleichbar mit &unix; Gruppen. Die Hauptunterschiede sind das Fehlen einer numerischen ID sowie die Möglichkeit, Netzgruppen zu definieren, die sowohl Benutzer als auch andere Netzgruppen enthalten. Um das Beispiel in diesem Kapitel fortzuführen, wird die NIS-Domäne um zusätzliche Benutzer und Rechner erweitert: Zusätzliche Benutzer Benutzername(n) Beschreibung alpha, beta Mitarbeiter der IT-Abteilung charlie, delta Lehrlinge der IT-Abteilung echo, foxtrott, golf, ... Mitarbeiter able, baker, ... Praktikanten
Zusätzliche Rechner Rechnername(n) Beschreibung war, death, famine, pollution Nur Mitarbeiter der IT-Abteilung dürfen sich an diesen Rechnern anmelden. pride, greed, envy, wrath, lust, sloth Nur Mitarbeiter und Lehrlinge der IT-Abteilung dürfen sich auf diesen Rechnern anmelden. one, two, three, four, ... Gewöhnliche Arbeitsrechner für Mitarbeiter. trashcan Ein sehr alter Rechner ohne kritische Daten. Sogar Praktikanten dürfen diesen Rechner verwenden.
Bei der Verwendung von Netzgruppen wird jeder Benutzer einer oder mehreren Netzgruppen zugewiesen und die Anmeldung wird dann für die Netzgruppe erlaubt oder verwehrt. Wenn ein neuer Rechner hinzugefügt wird, müssen die Zugangsbeschränkungen nur für die Netzgruppen festgelegt werden. Wird ein neuer Benutzer angelegt, muss er einer oder mehreren Netzgruppen zugewiesen werden. Wenn die Einrichtung von NIS sorgfältig geplant wurde, muss nur noch eine zentrale Konfigurationsdatei bearbeitet werden, um den Zugriff auf bestimmte Rechner zu erlauben oder zu verbieten. Dieses Beispiel erstellt vier Netzgruppen: IT-Mitarbeiter, IT-Lehrlinge, normale Mitarbeiter sowie Praktikanten: IT_EMP (,alpha,test-domain) (,beta,test-domain) IT_APP (,charlie,test-domain) (,delta,test-domain) USERS (,echo,test-domain) (,foxtrott,test-domain) \ (,golf,test-domain) INTERNS (,able,test-domain) (,baker,test-domain) Jede Zeile konfiguriert eine Netzgruppe. Die erste Spalte der Zeile bezeichnet den Namen der Netzgruppe. Die Einträge in den Klammern stehen entweder für eine Gruppe von einem oder mehreren Benutzern, oder für den Namen einer weiteren Netzgruppe. Wenn ein Benutzer angegeben wird, haben die drei Felder in der Klammer folgende Bedeutung: Der Name des Rechner(s), auf dem die weiteren Felder für den Benutzer gültig sind. Wird kein Rechnername festgelegt, ist der Eintrag auf allen Rechnern gültig. Der Name des Benutzerkontos, der zu dieser Netzgruppe gehört. Die NIS-Domäne für das Benutzerkonto. Benutzerkonten können von anderen NIS-Domänen in eine Netzgruppe importiert werden. Wenn eine Gruppe mehrere Benutzer enthält, müssen diese durch Leerzeichen getrennt werden. Darüber hinaus kann jedes Feld Wildcards enthalten. Weitere Einzelheiten finden Sie in &man.netgroup.5;. Netzgruppen Netzgruppennamen sollten nicht länger als 8 Zeichen sein. Es wird zwischen Groß- und Kleinschreibung unterschieden. Die Verwendung von Großbuchstaben für Netzgruppennamen ermöglicht eine leichte Unterscheidung zwischen Benutzern, Rechnern und Netzgruppen. Einige NIS-Clients (dies gilt nicht für &os;) können keine Netzgruppen mit mehr als 15 Einträgen verwalten. Diese Grenze kann umgangen werden, indem mehrere Subnetzgruppen mit weniger als fünfzehn Benutzern angelegt werden und diese Subnetzgruppen wiederum in einer Netzgruppe zusammengefasst wird, wie in diesem Beispiel zu sehen: BIGGRP1 (,joe1,domain) (,joe2,domain) (,joe3,domain) [...] BIGGRP2 (,joe16,domain) (,joe17,domain) [...] BIGGRP3 (,joe31,domain) (,joe32,domain) BIGGROUP BIGGRP1 BIGGRP2 BIGGRP3 Wiederholen Sie diesen Vorgang, wenn mehr als 225 (15*15) Benutzer in einer einzigen Netzgruppe existieren. Die neue NIS-Map aktivieren und verteilen: ellington&prompt.root; cd /var/yp ellington&prompt.root; make Dadurch werden die NIS-Maps netgroup, netgroup.byhost und netgroup.byuser erzeugt. Prüfen Sie die Verfügbarkeit der neuen NIS-Maps mit &man.ypcat.1;: ellington&prompt.user; ypcat -k netgroup ellington&prompt.user; ypcat -k netgroup.byhost ellington&prompt.user; ypcat -k netgroup.byuser Die Ausgabe des ersten Befehls gibt den Inhalt von /var/yp/netgroup wieder. Der zweite Befehl erzeugt nur dann eine Ausgabe, wenn rechnerspezifische Netzgruppen erzeugt wurden. Der dritte Befehl gibt die Netzgruppen nach Benutzern sortiert aus. Wenn Sie einen Client einrichten, verwenden Sie &man.vipw.8; um den Namen der Netzgruppe anzugeben. Ersetzen Sie beispielsweise auf dem Server namens war die folgende Zeile: +::::::::: durch +@IT_EMP::::::::: ersetzt werden. Diese Zeile legt fest, dass nur noch Benutzer der Netzgruppe IT_EMP in die Passwortdatenbank dieses Systems importiert werden. Nur diese Benutzer dürfen sich an diesem Server anmelden. Diese Konfiguration gilt auch für die ~-Funktion der Shell und für alle Routinen, die auf Benutzernamen und numerische Benutzer-IDs zugreifen. Oder anders formuliert, cd ~user ist nicht möglich, ls -l zeigt die numerische Benutzer-ID statt dem Benutzernamen und find . -user joe -print erzeugt die Fehlermeldung No such user. Um dieses Problem zu beheben, müssen alle Benutzereinträge importiert werden, ohne ihnen jedoch zu erlauben, sich am Server anzumelden. Dies kann durch das Hinzufügen einer zusätzlichen Zeile erreicht werden: +:::::::::/sbin/nologin Diese Zeile weist den Client an, alle Einträge zu importieren, aber die Shell in diesen Einträgen durch /sbin/nologin zu ersetzen. Stellen Sie sicher, dass die zusätzliche Zeile nach der Zeile +@IT_EMP::::::::: eingetragen ist. Andernfalls haben alle via NIS importierten Benutzerkonten /sbin/nologin als Loginshell und niemand wird sich mehr am System anmelden können. Um die weniger wichtigen Server zu konfigurieren, ersetzen Sie den alten Eintrag +::::::::: auf den Servern mit diesen Zeilen: +@IT_EMP::::::::: +@IT_APP::::::::: +:::::::::/sbin/nologin Die entsprechenden Zeilen für Arbeitsplätze lauten: +@IT_EMP::::::::: +@USERS::::::::: +:::::::::/sbin/nologin NIS ist in der Lage, Netzgruppen aus anderen Netzgruppen zu bilden. Dies kann nützlich sein, wenn sich die Firmenpolitik ändert. Eine Möglichkeit ist die Erzeugung rollenbasierter Netzgruppen. Sie könnten eine Netzgruppe BIGSRV erzeugen, um den Zugang zu den wichtigsten Servern zu beschränken, eine weitere Gruppe SMALLSRV für die weniger wichtigen Server und eine dritte Netzgruppe USERBOX für die Arbeitsplatzrechner. Jede dieser Netzgruppen enthält die Netzgruppen, die sich auf diesen Rechnern anmelden dürfen. Die Einträge der Netzgruppen in der NIS-Map sollten ähnlich den folgenden aussehen: BIGSRV IT_EMP IT_APP SMALLSRV IT_EMP IT_APP ITINTERN USERBOX IT_EMP ITINTERN USERS Diese Methode funktioniert besonders gut, wenn Rechner in Gruppen mit identischen Beschränkungen eingeteilt werden können. Unglücklicherweise ist dies die Ausnahme und nicht die Regel. Meistens wird die Möglichkeit zur rechnerspezischen Zugangsbeschränkung benötigt. Rechnerspezifische Netzgruppen sind eine weitere Möglichkeit, um mit den oben beschriebenen Änderungen umzugehen. In diesem Szenario enthält /etc/master.passwd auf jedem Rechner zwei mit + beginnende Zeilen. Die erste Zeile legt die Netzgruppe mit den Benutzern fest, die sich auf diesem Rechner anmelden dürfen. Die zweite Zeile weist allen anderen Benutzern /sbin/nologin als Shell zu. Verwenden Sie auch hier (analog zu den Netzgruppen) Großbuchstaben für die Rechnernamen: +@BOXNAME::::::::: +:::::::::/sbin/nologin Sobald dies für alle Rechner erledigt ist, müssen die lokalen Versionen von /etc/master.passwd nie mehr verändert werden. Alle weiteren Änderungen geschehen über die NIS-Maps. Nachfolgend ein Beispiel für eine mögliche Netzgruppen-Map: # Define groups of users first IT_EMP (,alpha,test-domain) (,beta,test-domain) IT_APP (,charlie,test-domain) (,delta,test-domain) DEPT1 (,echo,test-domain) (,foxtrott,test-domain) DEPT2 (,golf,test-domain) (,hotel,test-domain) DEPT3 (,india,test-domain) (,juliet,test-domain) ITINTERN (,kilo,test-domain) (,lima,test-domain) D_INTERNS (,able,test-domain) (,baker,test-domain) # # Now, define some groups based on roles USERS DEPT1 DEPT2 DEPT3 BIGSRV IT_EMP IT_APP SMALLSRV IT_EMP IT_APP ITINTERN USERBOX IT_EMP ITINTERN USERS # # And a groups for a special tasks # Allow echo and golf to access our anti-virus-machine SECURITY IT_EMP (,echo,test-domain) (,golf,test-domain) # # machine-based netgroups # Our main servers WAR BIGSRV FAMINE BIGSRV # User india needs access to this server POLLUTION BIGSRV (,india,test-domain) # # This one is really important and needs more access restrictions DEATH IT_EMP # # The anti-virus-machine mentioned above ONE SECURITY # # Restrict a machine to a single user TWO (,hotel,test-domain) # [...more groups to follow] Es ist nicht immer ratsam, rechnerbasierte Netzgruppen zu verwenden. Wenn Dutzende oder Hunderte identische Rechner eingerichtet werden müssen, sollten rollenbasierte Netzgruppen verwendet werden, um die Größe der NIS-Maps in Grenzen zu halten. Passwortformate NIS Passwortformate Alle Rechner innerhalb der NIS-Domäne müssen für die Verschlüsselung von Passwörtern das gleiche Format benutzen. Wenn Benutzer Schwierigkeiten bei der Authentifizierung auf einem NIS-Client haben, liegt dies möglicherweise an einem anderen Passwort-Format. In einem heterogenen Netzwerk muss das verwendete Format von allen Betriebssystemen unterstützt werden, wobei DES der kleinste gemeinsame Standard ist. Welches Format die Server und Clients verwenden, steht in /etc/login.conf: default:\ :passwd_format=des:\ :copyright=/etc/COPYRIGHT:\ [weitere Einträge] In diesem Beispiel verwendet das System das Format DES. Weitere mögliche Werte sind unter anderem blf und md5 (mit Blowfish und MD5 verschlüsselte Passwörter). Wird auf einem Rechner das Format entsprechend der NIS-Domäne geändert, muss anschließend die Login-Capability Datenbank neu erstellt werden: &prompt.root; cap_mkdb /etc/login.conf Das Format der schon bestehenden Passwörter wird erst aktualisiert, wenn ein Benutzer sein Passwort ändert, nachdem die Datenbank neu erstellt wurde. Lightweight Access Directory Protocol (<acronym>LDAP</acronym>) LDAP Das Lightweight Directory Access Protocol (LDAP) ist ein Protokoll der Anwendungsschicht und wird verwendet, um Objekte mithilfe eines verteilten Verzeichnisdienstes abzurufen, zu verändern und zu authentifizieren. Betrachten Sie es als ein Telefonbuch, das homogene Informationen in mehreren hierarchischen Ebenen speichert. Es wird häufig in Netzwerken genutzt, in denen Benutzer unter Verwendung eines einzigen Kontos auf diverse interne Informationen zugreifen müssen. Beispielsweise kann E-Mail-Authentifizierung, Abfrage von Kontaktinformationen und Website-Authentifizierung über ein einzelnes Benutzerkonto aus der Datenbank des LDAP-Servers erfolgen. Dieser Abschnitt behandelt nicht die Geschichte oder Details der Implementierung des Protokolls. Diese Abschnitte wurden verfasst, um einen LDAP-Server und/oder -Client sowohl schnell, als auch sicher zu konfigurieren. Jedoch erfordert jede Informationsbasis sorgfältige Planung, und dies ist keine Ausnahme. Bei der Planung sollte bestimmt werden, welche Art von Informationen gespeichert werden, für was diese Informationen verwendet werden, wer Zugriff auf die Daten bekommen soll, und wie diese Daten vor neugierigen Blicken geschützt werden können. <acronym>LDAP</acronym> Terminologie und Struktur Da bei der Konfiguration leicht Verwechselungen entstehen, werden zuvor einige Aspekte von LDAP erklärt. Zunächst bestehen alle Verzeichniseinträge aus einer Gruppe von Attributen. Jede Attributgruppe enthält einen Namen, also einen eindeutigen Bezeichner, der als DN oder distinguished name bekannt ist. Dieser setzt sich normalerweise aus mehreren anderen Attributen, wie dem RDN zusammen. RDN, oder relative distinguished name, ist ein geläufiger Begriff für ein Attribut. Wie bei Verzeichnissen gibt es auch hier absolute und relative Pfade. Betrachten Sie DN als absoluten Pfad und RDN als relativen Pfad. Beispielsweise könnte ein Eintrag wie folgt aussehen: &prompt.user; ldapsearch -xb "uid=trhodes,ou=users,o=example.com" # extended LDIF # # LDAPv3 # base <uid=trhodes,ou=users,o=example.com> with scope subtree # filter: (objectclass=*) # requesting: ALL # # trhodes, users, example.com dn: uid=trhodes,ou=users,o=example.com mail: trhodes@example.com cn: Tom Rhodes uid: trhodes telephoneNumber: (xxx) xxx-xxxx # search result search: 2 result: 0 Success # numResponses: 2 # numEntries:1 Obwohl die Bedeutung der einzelnen Attribute in diesem Beispiel offensichtlich ist, sollte das Attribut cn genauer betrachtet werden. Dies ist der zuvor beschriebene RDN. Darüber hinaus gibt es eine eindeutige Benutzer-ID. Es ist gängige Praxis, in den Einträgen einheitliche uid oder uuids zu haben, um zukünftige Migrationen zu erleichtern. Konfiguration eines <acronym>LDAP</acronym>-Servers LDAP Server Um &os; so zu konfigurieren, dass es als LDAP-Server fungiert, muss der Port OpenLDAP installiert werden. Dies kann unter Verwendung von pkg_add, oder durch Installation von net/openldap24-server erreicht werden. Der Bau des Ports wird empfohlen, da der Administrator zu diesem Zeitpunkt eine Menge Optionen aktivieren und deaktivieren kann. In den meisten Fällen werden die Standardwerte ausreichend sein. Sollte jedoch Unterstützung für SQL nötig sein, ist dies der richtige Zeitpunkt zur Aktivierung. Von nun an werden ein paar Verzeichnisse benötigt. Ein Verzeichnis für Daten, sowie ein Verzeichnis zum Speichern der Zertifikate. Erstellen Sie beide Verzeichnisse mit den folgenden Befehlen: &prompt.root; mkdir /var/db/openldap-data &prompt.root; mkdir /usr/local/etc/openldap/private Kopieren Sie die Konfigurationsdatei der Datenbank: &prompt.root; cp /usr/local/etc/openldap/DB_CONFIG.example /var/db/openldap-data/DB_CONFIG Im nächsten Schritt werden die SSL-Zertifikate konfiguriert. Das Erstellen von Zertifikaten wird zwar in OpenSSL beschrieben, aber hier ist eine Zertifizierungsstelle erforderlich, weshalb eine andere Methode verwendet wird. Es wird empfohlen, diesen Teil genau zu überprüfen, um sicherzustellen, dass bei der Erstellung des Zertifikats die richtigen Informationen eingetragen werden. Die folgenden Befehle müssen im Verzeichnis /usr/local/etc/openldap/private ausgeführt werden. Dies ist wichtig, da die Dateiberechtigungen restriktiv gesetzt werden und Benutzer keinen direkten Zugriff auf diese Daten haben sollten. Geben Sie folgende Befehle ein, um die Zertifikate zu erstellen: &prompt.root; openssl req -days 365 -nodes -new -x509 -keyout ca.key -out ../ca.crt Diese Einträge sind frei wählbar, mit Ausnahme von Common Name. Hier muss etwas anderes als der Hostname des Systems eingetragen werden, ansonsten würde das System versuchen, den eigenen Hostnamen zu überprüfen. Wenn wie in diesem Beispiel ein selbstsigniertes Zertifikat verwendet wird, stellen Sie dem Hostnamen einfach das Präfix CA für die Zertifizierungsstelle voran. Die nächste Aufgabe besteht darin, einen Zertifikatsregistrierungsanforderung (CSR) sowie einen privaten Schlüssel zu erstellen. Dazu geben Sie die folgenden Befehle ein: &prompt.root; openssl req -days 365 -nodes -new -keyout server.key -out server.csr Stellen Sie hierbei sicher, dass der common name richtig eingetragen wird. Anschließend muss der Schlüssel signiert werden: &prompt.root; openssl x509 -req -days 365 -in server.csr -out ../server.crt -CA ../ca.crt -CAkey ca.key -CAcreateserial Der letzte Schritt für die Erstellung der Zertifikate besteht darin, die Client-Zertifikate zu erstellen und zu signieren: &prompt.root; openssl req -days 365 -nodes -new -keyout client.key -out client.csr &prompt.root; openssl x509 -req -days 3650 -in client.csr -out ../client.crt -CAkey ca.key Achten Sie wieder auf das Attribut common name. Dies sorgt häufig für Verwirrung bei der erstmaligen Konfiguration von LDAP. Stellen Sie außerdem sicher, dass bei diesem Verfahren acht (8) neue Dateien erzeugt worden sind. Der nächste Schritt besteht darin, /usr/local/etc/openldap/slapd.conf zu editieren und folgende Optionen hinzuzufügen: TLSCipherSuite HIGH:MEDIUM:+SSLv3 TLSCertificateFile /usr/local/etc/openldap/server.crt TLSCertificateKeyFile /usr/local/etc/openldap/private/server.key TLSCACertificateFile /usr/local/etc/openldap/ca.crt Editieren Sie zusätzlich /usr/local/etc/openldap/ldap.conf und fügen die folgenden Zeilen hinzu: TLS_CACERT /usr/local/etc/openldap/ca.crt TLS_CIPHER_SUITE HIGH:MEDIUM:+SSLv3 Setzen Sie für die gewünschten Werte ein und kommentieren Sie die Optionen , und aus. Setzen Sie bei und ein. Die daraus resultierende Datei sollte der hier gezeigten ähnlich sehen: BASE dc=example,dc=com URI ldap:// ldaps:// SIZELIMIT 12 TIMELIMIT 15 #DEREF never TLS_CACERT /usr/local/etc/openldap/ca.crt$ TLS_CIPHER_SUITE HIGH:MEDIUM:+SSLv3 Anschließend sollte das Standardpasswort für den Server geändert werden. Das folgende Kommando schreibt die Ausgabe in slapd.conf: &prompt.root; slappasswd -h "{SHA}" >> /usr/local/etc/openldap/slapd.conf Dieser Befehl wird nach einem Passwort fragen und, wenn der Prozess nicht fehlschlägt, ein Passwort-Hash an das Ende von slapd.conf hinzufügen. slappasswd versteht verschiedene Hash-Formate. Weitere Informationen hierzu finden Sie in der Manualpage. Bearbeiten Sie /usr/local/etc/openldap/slapd.conf und fügen folgende Zeilen hinzu: password-hash {sha} allow bind_v2 Das Suffix in dieser Datei muss aus der vorherigen Konfiguration entsprechen. Zudem sollte die Option ebenfalls gesetzt werden. Ein guter Vorschlag ist beispielsweise . Bevor die Datei gespeichert wird, setzen Sie die Passwortausgabe von slappasswd hinter die Option . Das Endergebnis sollte in etwa wie folgt aussehen: TLSCipherSuite HIGH:MEDIUM:+SSLv3 TLSCertificateFile /usr/local/etc/openldap/server.crt TLSCertificateKeyFile /usr/local/etc/openldap/private/server.key TLSCACertificateFile /usr/local/etc/openldap/ca.crt rootpw {SHA}W6ph5Mm5Pz8GgiULbPgzG37mj9g= Aktivieren Sie abschließend OpenLDAP in /etc/rc.conf. Zu diesem Zeitpunkt kann es sinnvoll sein, eine URI sowie die Gruppe und den Benutzer einzurichten. Editieren Sie dazu /etc/rc.conf und fügen folgende Zeilen hinzu: slapd_enable="YES" slapd_flags="-4 -h ldaps:///" An dieser Stelle sollte der Server bereit sein, gestartet und getestet zu werden. Führen Sie dazu folgenden Befehl aus: &prompt.root; service slapd start Wurde alles richtig konfiguriert, sollte eine Suche im Verzeichnis, wie in diesem Beispiel, eine erfolgreiche Verbindung mit einer Antwort liefern: # extended LDIF # # LDAPv3 # base <dc=example,dc=com> (default) with scope subtree # filter: (objectclass=*) # requesting: ALL # search result search: 3 result: 32 No such object # numResponses: 1 Wenn der Dienst wie im Beispiel oben antwortet, kann das Verzeichnis mit dem Befehl ldapadd bestückt werden. In diesem Beispiel gibt es eine Datei mit einer Liste von Benutzern, die diesem Verzeichnis hinzugefügt werden. Erstellen Sie zunächst eine Datei mit folgendem Datensatz für den Import: dn: dc=example,dc=com objectclass: dcObject objectclass: organization o: Example dc: Example dn: cn=Manager,dc=example,dc=com objectclass: organizationalRole cn: Manager Zur Fehlersuche, stoppen Sie den slapd-Dienst mit dem service-Befehl. Starten Sie anschließend die Anwendung mit Debugging-Optionen: &prompt.root; /usr/local/libexec/slapd -d -1 Angenommen das die Importdatei import.ldif heißt, geben Sie folgenden Befehl ein, um die Datendatei zu importieren: &prompt.root; ldapadd -Z -D "cn=Manager,dc=example,dc=com" -W -f import.ldif Es wird wieder eine Aufforderung zur Passworteingabe geben und die Ausgabe sollte wie folgt aussehen: Enter LDAP Password: adding new entry "dc=example,dc=com" adding new entry "cn=Manager,dc=example,dc=com" Stellen Sie mit einer Suche auf dem Server sicher, dass die Daten importiert wurden. Nutzen Sie dazu ldapsearch. In diesem Fall sollte die Ausgabe wie folgt aussehen: &prompt.user; ldapsearch -Z # extended LDIF # # LDAPv3 # base <dc=example,dc=com> (default) with scope subtree # filter: (objectclass=*) # requesting: ALL # # example.com dn: dc=example,dc=com objectClass: dcObject objectClass: organization o: Example dc: Example # Manager, example.com dn: cn=Manager,dc=example,dc=com objectClass: organizationalRole cn: Manager # search result search: 3 result: 0 Success # numResponses: 3 # numEntries: 2 Es ist natürlich sinnvoll, sich über die Struktur der LDAP-Verzeichnisse in den hier erwähnten Manualpages zu informieren. An dieser Stelle sollte der Server konfiguriert sein und ordnungsgemäß funktionieren. Dynamic Host Configuration Protocol (<acronym>DHCP</acronym>) Dynamic Host Configuration Protocol - DHCP + DHCP Internet Systems Consortium (ISC) - Über DHCP, das Dynamic Host Configuration Protocol, - kann sich ein System mit einem Netzwerk verbinden und die - für die Kommunikation mit diesem Netzwerk nötigen - Informationen beziehen. &os; verwendet den von - OpenBSD 3.7 stammenden dhclient. - Die Informationen in diesem Abschnitt - beziehen sich daher sowohl auf den dhclient - von ISC als auch auf den von OpenBSD. Als DHCP-Server wird - in beiden Fällen der DHCP-Server der ISC-Distribution - verwendet. + Das Dynamic Host Configuration Protocol + (DHCP) ermöglicht es einem System, sich mit + einem Netzwerk zu verbinden und die für die Kommunikation mit + diesem Netzwerk nötigen Informationen zu beziehen. &os; + verwendet den von OpenBSD stammenden + dhclient, um die Adressinformationen + zu beziehen. &os; installiert keinen + DHCP-Server, aber es stehen einige Server + in der &os; Ports-Sammlung zu Verfügung. Das + DHCP-Protokoll wird vollständig im + RFC 2131 beschrieben. Eine weitere, lehrreiche + Informationsquelle existiert unter + isc.org/downloads/dhcp/. + + In diesem Abschnitt wird beschrieben, wie der integrierte + DHCP-Client verwendet wird. Anschließend + wird erklärt, wie ein DHCP-Server zu + installieren und konfigurieren ist. - Dieser Abschnitt beschreibt sowohl die Clientseite des - ISC- als auch des OpenBSD-Clients sowie die - Serverseite des DHCP-Systems von ISC. Das Clientprogramm - dhclient ist in &os; integriert, das - Serverprogramm kann über den Port - net/isc-dhcp42-server - installiert werden. Weitere Informationen finden Sie in - &man.dhclient.8;, &man.dhcp-options.5; sowie - &man.dhclient.conf.5;. - - Wie funktioniert <acronym>DHCP</acronym>? + Einen <acronym>DHCP</acronym>-Client + konfigurieren - UDP + Die Unterstützung für den DHCP-Client + ist im Installationsprogramm von &os; enthalten, sodass ein + neu installiertes System automatisch die Adressinformationen + des Netzwerks vom DHCP-Server + erhält. - Der DHCP-Client dhclient beginnt von - einem Clientrechner aus über den UDP-Port 68 - Konfigurationsinformationen anzufordern. Der Server antwortet - auf dem UDP-Port 67, indem er dem Client eine IP-Adresse - zuweist und ihm weitere wichtige Informationen über das - Netzwerk, wie Netzmasken, Router und DNS-Server mitteilt. Diese - Informationen werden als - DHCP-Lease bezeichnet und - sind nur für eine bestimmte Zeit, die vom Administrator des - DHCP-Servers vorgegeben wird, gültig. Dadurch fallen - verwaiste IP-Adressen, deren Clients nicht mehr mit dem Netzwerk - verbunden sind, automatisch an den Server zurück. + UDP - DHCP-Clients können sehr viele Informationen von einem - DHCP-Server erhalten. Eine ausführliche Liste finden Sie - in &man.dhcp-options.5;. - + dhclient beginnt von einem + Clientrechner aus über den UDP-Port 68 + Konfigurationsinformationen anzufordern. Der Server antwortet + auf dem UDP-Port 67, indem er dem Client + eine IP-Adresse zuweist und ihm weitere + relevante Informationen über das Netzwerk, wie Netzmasken, + Router und DNS-Server mitteilt. Diese + Informationen werden als + DHCP-Lease bezeichnet und sind + nur für bestimmte Zeit, die vom Administrator des + DHCP-Servers vorgegeben wird, gültig. + Dadurch fallen verwaiste IP-Adressen, deren + Clients nicht mehr mit dem Netzwerk verbunden sind, + automatisch an den Server zurück. - - Integration in &os; + DHCP-Clients können sehr viele + Informationen von einem DHCP-Server + erhalten. Eine ausführliche Liste finden Sie in + &man.dhcp-options.5;. - &os; verwendet den DHCP-Client von OpenBSD. - Sowohl während der Installation als - auch im Basissystem steht der DHCP-Client zur Verfügung. - In Netzen mit DHCP-Servern wird dadurch die Konfiguration von - Systemen erheblich vereinfacht. - - - sysinstall - - - DHCP wird von sysinstall - unterstützt. Wenn Sie eine Netzwerkkarte mit - sysinstall konfigurieren, lautet - die zweite Frage Do you want to try DHCP configuration - of the interface?. Wenn Sie diese Frage bejahen, wird - dhclient aufgerufen, und die Netzkarte wird - automatisch eingerichtet. - - Um DHCP beim Systemstart zu aktivieren, sind zwei - Dinge erforderlich: - - - DHCP - Anforderungen - - - - - Stellen Sie sicher, dass bpf im - Kernel kompiliert ist. Dazu fügen Sie die Zeile - device bpf - in die Kernelkonfigurationsdatei ein und erzeugen einen - neuen Kernel. Weitere Informationen zur Kernelkonfiguration - finden Sie in des Handbuchs. - - Das Gerät bpf ist im GENERIC-Kernel bereits enthalten. - Für die Nutzung von DHCP muss also kein angepasster + Für die Nutzung von DHCP muss also kein angepasster Kernel erzeugt werden. In einer angepassten Kernelkonfigurationsdatei muss das Gerät enthalten sein, damit DHCP ordnungsgemäß funktioniert. Diejenigen, die besonders um die Sicherheit besorgt sind, sollten wissen, dass bpf auch zur Ausführung von Paketsniffern erforderlich ist (obwohl diese dennoch als root ausgeführt werden müssen). bpf - muss vorhanden sein, damit DHCP + muss vorhanden sein, damit + DHCP funktioniert. Sehr sicherheitsbewusste Personen, sollten bpf aus dem Kernel - entfernen, wenn DHCP nicht verwendet wird. + entfernen, wenn DHCP nicht verwendet wird. - - - Standardmässig läuft die DHCP-Konfiguration + Standardmässig läuft die DHCP-Konfiguration bei &os; im Hintergrund oder auch asynchron. Andere Startskripte laufen - weiter, während DHCP fertig abgearbeitet wird, was den + weiter, während DHCP fertig abgearbeitet wird, was den Systemstart beschleunigt. - DHCP im Hintergrund funktioniert gut, wenn der DHCP-Server - schnell auf Anfragen antwortet und der - DHCP-Konfigurationsprozess ebenso schnell abläuft. - Jedoch kann DHCP eine lange Zeit benötigen, um auf - manchen Systemen fertig zu werden. Falls Netzwerkdienste - versuchen, vor DHCP zum Ende zu kommen, werden diese - fehlschlagen. Durch die Verwendung von DHCP im - asynchronen-Modus wird das Problem - verhindert, so dass die Startskripte pausiert werden, bis - die DHCP-Konfiguration abgeschlossen ist. + DHCP im Hintergrund funktioniert + gut, wenn der DHCP-Server schnell auf + Anfragen antwortet und der + DHCP-Konfigurationsprozess ebenso + schnell abläuft. Jedoch kann DHCP eine + lange Zeit benötigen, um auf manchen Systemen fertig zu + werden. Falls Netzwerkdienste versuchen, vor + DHCP zum Ende zu kommen, werden diese + fehlschlagen. Durch die Verwendung von + DHCP im + asynchronen Modus wird das Problem + verhindert, so dass die Startskripte pausiert werden, bis + die DHCP-Konfiguration abgeschlossen + ist. - Um sich zu einem DHCP-Server im Hintergrund zu verbinden, + Um sich zu einem DHCP-Server im Hintergrund zu verbinden, während andere Startskripte fortfahren (asynchroner Modus), benutzen Sie den DHCP-Wert in /etc/rc.conf: ifconfig_fxp0="DHCP" Um den Start zu pausieren, damit DHCP vorher abgeschlossen werden kann, benutzen Sie den synchronen Modus mit dem Eintrag SYNCDHCP: ifconfig_fxp0="SYNCDHCP" Ersetzen Sie fxp0, das in diesen Beispielen verwendet wurde, durch den Namen Ihrer Netzwerkschnittstelle, so wie es in beschrieben ist. Wenn dhclient an einem anderen Ort installiert wurde, oder zusätzliche Flags an dhclient übergeben werden müssen, fügen Sie folgende (entsprechend angepasste) Zeilen ein: dhclient_program="/sbin/dhclient" dhclient_flags="" - - - DHCP - Server + DHCP + Konfigurationsdateien - Der DHCP-Server dhcpd ist als - Teil des Ports net/isc-dhcp42-server - verfügbar. Dieser Port enthält die komplette - ISC-DHCP-Distribution, inklusive der Dokumentation. - + Der DHCP-Client verwendet die folgenden + Dateien: - - Dateien - - - DHCP - Konfigurationsdateien - - /etc/dhclient.conf dhclient benötigt die Konfigurationsdatei /etc/dhclient.conf. Diese Datei enthält normalerweise nur Kommentare, da die Vorgabewerte zumeist ausreichend sind. Die Konfigurationsdatei wird in &man.dhclient.conf.5; beschrieben. /sbin/dhclient Weitere Informationen über dhclient finden Sie in &man.dhclient.8;. /sbin/dhclient-script Bei dhclient-script handelt es sich um das &os;-spezifische Konfigurationsskript des - DHCP-Clients. Es wird in &man.dhclient-script.8; + DHCP-Clients. Es wird in &man.dhclient-script.8; beschrieben und kann meist unverändert übernommen werden. /var/db/dhclient.leases. interface - Der DHCP-Client verfügt über eine Datenbank, + Der DHCP-Client verfügt über eine Datenbank, die alle derzeit gültigen Leases enthält und als Logdatei erzeugt wird. Weitere Informationen finden Sie in - &man.dhclient.8;. + &man.dhclient.8;, &man.dhcp-options.5; und + &man.dhclient.conf.5;. - - Weitere Informationen - - Das DHCP-Protokoll wird vollständig im - RFC 2131 - beschrieben. Eine weitere, lehrreiche Informationsquelle - existiert unter - http://www.dhcp.org/. - - - Einen DHCP-Server installieren und einrichten + Einen <acronym>DHCP</acronym>-Server installieren und + einrichten - - Übersicht - Dieser Abschnitt beschreibt die Einrichtung eines - &os;-Systems als DHCP-Server. Dazu wird die - DHCP-Implementation von ISC (Internet Systems Consortium) - verwendet. + &os;-Systems als DHCP-Server. Dazu wird + die DHCP-Implementation von ISC (Internet + Systems Consortium) verwendet. + + + DHCP + Server + + Der DHCP-Server + dhcpd ist als Teil des Ports + net/isc-dhcp42-server verfügbar. Dieser + Port enthält den ISC DHCP-Server und die + Dokumentation. + Der Server ist nicht im Basissystem von &os; enthalten, daher muss der Port net/isc-dhcp42-server installiert. Lesen Sie , wenn Sie weitere Informationen zur Ports-Sammlung benötigen. - - - Den DHCP-Server installieren - - DHCP + DHCP installieren Stellen Sie sicher, dass &man.bpf.4; im Kernel kompiliert ist. Dazu fügen Sie die Zeile device bpf in die Kernelkonfigurationsdatei ein und erzeugen einen neuen Kernel. Die Kernelkonfiguration wird in beschrieben. Das Gerät bpf ist im GENERIC-Kernel bereits enthalten. - Für die Nutzung von DHCP muss also kein angepasster + Für die Nutzung von DHCP muss also kein angepasster Kernel erzeugt werden. Diejenigen, die um die Sicherheit besorgt sind, sollten wissen, dass bpf auch zur Ausführung von Paketsniffern erforderlich ist (obwohl diese dennoch als root ausgeführt werden müssen). bpf - muss vorhanden sein, damit DHCP + muss vorhanden sein, damit DHCP funktioniert. Sehr sicherheitsbewusste Personen, sollten bpf aus dem Kernel - entfernen, wenn DHCP nicht verwendet wird. + entfernen, wenn DHCP nicht verwendet wird. Der Port net/isc-dhcp42-server installiert eine Beispiel-Konfigurationsdatei. Kopieren Sie /usr/local/etc/dhcpd.conf.example nach /usr/local/etc/dhcpd.conf und nehmen Sie die Änderungen an der neuen Datei vor. - Danach muss die vom Port - net/isc-dhcp42-server - erzeugte Vorlage für dhcpd.conf - angepasst werden. Die bei der Installation erzeugte Datei - /usr/local/etc/dhcpd.conf.sample - sollten Sie nach - /usr/local/etc/dhcpd.conf kopieren, - bevor Sie Veränderungen vornehmen. - - Den DHCP-Server einrichten + Den <acronym>DHCP</acronym>-Server einrichten - DHCP + DHCP dhcpd.conf dhcpd.conf besteht aus Festlegungen zu Subnetzen und Rechnern und lässt sich am besten an einem Beispiel erklären: option domain-name "example.com"; option domain-name-servers 192.168.4.100; option subnet-mask 255.255.255.0; default-lease-time 3600; max-lease-time 86400; ddns-update-style none; subnet 192.168.4.0 netmask 255.255.255.0 { range 192.168.4.129 192.168.4.254; option routers 192.168.4.1; } host mailhost { hardware ethernet 02:03:04:05:06:07; fixed-address mailhost.example.com; } Diese Option beschreibt die Domäne, die den Clients als Standardsuchdomäne zugewiesen wird. - Weitere Informationen finden Sie in man.resolv.conf.5;. - + Weitere Informationen finden Sie in + &man.resolv.conf.5;. Diese Option legt eine, durch Kommata getrennte - Liste von DNS-Servern fest, die von den Clients + Liste von DNS-Servern fest, die von den Clients verwendet werden sollen. Die den Clients zugewiesene Netzmaske. Ein Client kann eine Lease einer bestimmten Dauer anfordern. Geschieht dies nicht, weist der Server eine Lease mit einer vorgegebenen Ablaufdauer (in Sekunden) zu. Die maximale Zeitdauer, für die der Server Konfigurationsinformationen vergibt. Sollte ein Client eine längere Zeitspanne anfordern, wird dennoch nur der Wert max-lease-time in Sekunden zugewiesen. - Diese Option legt fest, ob der DHCP-Server eine - DNS-Aktualisierung versuchen soll, wenn + Diese Option legt fest, ob der + DHCP-Server eine + DNS-Aktualisierung versuchen soll, wenn Konfigurationsdateien vergeben oder zurückgezogen werden. In der ISC-Implementation muss diese Option gesetzt sein. - Dadurch werden die IP-Adressen festgelegt, die den - Clients zugewiesen werden können. IP-Adressen - zwischen diesen Grenzen sowie die einschließenden - Adressen werden den Clients zugewiesen. + Dadurch werden die IP-Adressen + festgelegt, die den Clients zugewiesen werden können. + IP-Adressen zwischen diesen Grenzen + sowie die einschließenden Adressen werden den Clients + zugewiesen. Legt das Standard-Gateway fest, das den Clients zugewiesen wird. Die (Hardware-)MAC-Adresse eines Rechners (durch die - der DHCP-Server den Client erkennt, der eine Anforderung + der DHCP-Server den Client erkennt, der eine Anforderung an ihn stellt). - Einem Rechner soll immer die gleiche IP-Adresse + Einem Rechner soll immer die gleiche IP-Adresse zugewiesen werden. Beachten Sie, dass hier auch ein - Rechnername gültig ist, da der DHCP-Server den + Rechnername gültig ist, da der DHCP-Server den Rechnernamen auflöst, bevor er die Konfigurationsinformationen zuweist. Nachdem dhcpd.conf fertig - konfiguriert ist, sollten Sie den DHCP-Server aktivieren, + konfiguriert ist, sollten Sie den DHCP-Server aktivieren, indem Sie folgende Zeilen in /etc/rc.conf aufnehmen: dhcpd_enable="YES" dhcpd_ifaces="dc0" Dabei müssen Sie den Geräteeintrag dc0 durch die Gerätedatei (mehrere Gerätedateien müssen durch Leerzeichen getrennt - werden) ersetzen, die der DHCP-Server auf Anfragen von - DHCP-Clients hin überwachen soll. + werden) ersetzen, die der DHCP-Server auf Anfragen von + DHCP-Clients hin überwachen soll. Danach können Sie den Server durch Eingabe des folgenden Befehls starten: &prompt.root; service isc-dhcpd start Künftige Änderungen an der Konfiguration des Servers erfordern, dass ein SIGTERM-Signal anstelle von SIGHUP an dhcpd gesendet wird. Es ist jedoch definitiv einfacher, den Dienst mit &man.service.8; neu zu starten. Dateien - Server + DHCP Konfigurationsdateien /usr/local/sbin/dhcpd dhcpd ist statisch gelinkt und befindet sich in /usr/local/sbin. Weitere Informationen zu dhcpd finden Sie in &man.dhcpd.8;. /usr/local/etc/dhcpd.conf dhcpd benötigt die Konfigurationsdatei /usr/local/etc/dhcpd.conf, damit der Server den Clients seine Dienste anbieten kann. Diese Datei muss alle Informationen enthalten, die an die Clients weitergegeben werden soll. Außerdem sind hier Informationen zur Konfiguration des Servers enthalten. Die mit dem Port installierte &man.dhcpd.conf.5; beschreibt diese Konfigurationsdatei. /var/db/dhcpd.leases - Der DHCP-Server hat eine Datenbank, die alle + Der DHCP-Server hat eine Datenbank, die alle vergebenen Leases enthält. Diese wird als Logdatei erzeugt. Die mit dem Port installierte &man.dhcpd.leases.5; enthält eine ausführliche Beschreibung. /usr/local/sbin/dhcrelay dhcrelay wird in - komplexen Umgebungen verwendet, in denen ein DHCP-Server - eine Anfrage eines Clients an einen DHCP-Server in einem + komplexen Umgebungen verwendet, in denen ein + DHCP-Server eine Anfrage eines + Clients an einen DHCP-Server in einem separaten Netzwerk weiterleitet. Wenn Sie diese Funktion benötigen, müssen Sie den Port - net/isc-dhcp42-relay - installieren. Weitere Informationen zu diesem Thema - finden Sie in &man.dhcrelay.8;. + net/isc-dhcp42-relay installieren. + Weitere Informationen zu diesem Thema finden Sie in + &man.dhcrelay.8;. Domain Name System (<acronym>DNS</acronym>) Überblick BIND - DNS ist das für die Umwandlung von Rechnernamen in + DNS ist das für die Umwandlung von Rechnernamen in IP-Adressen zuständige Protokoll. &os; verwendet dazu BIND (Berkeley Internet Name Domain), die am häufigsten verwendete Implementierung von DNS). Eine Anfrage nach www.FreeBSD.org gibt die IP-Adresse des &os;-Webservers, eine Anfrage nach ftp.FreeBSD.org die IP-Adresse des entsprechenden FTP-Servers zurück. Der umgekehrte Weg ist ebenso möglich, eine IP-Adresse kann also auch in ihren Rechnernamen aufgelöst werden. Um eine DNS-Abfrage durchzuführen, muss auf dem jeweiligen Rechner kein Nameserver installiert sein. &os; verwendet derzeit in der Voreinstellung BIND9 als DNS-Serversoftware. Unsere Installation bietet Ihnen eine erhöhte Sicherheit, ein neues Dateisystemlayout sowie eine automatisierte &man.chroot.8;-Konfiguration. DNS Im Internet wird DNS durch ein komplexes System von autoritativen Root-Nameservern, Top Level Domain-Servern (TLD) sowie anderen kleineren Nameservern verwaltet, die individuelle Rechnerinformationen speichern und untereinander abgleichen. Derzeit wird BIND vom Internet Systems Consortium (https://www.isc.org/) verwaltet. Begriffsbestimmungen Um dieses Dokument besser verstehen zu können, müssen einige DNS-spezifische Begriffe genauer definiert werden. Resolver - Reverse-DNS + Reverse-DNS Root-Zone Begriff Bedeutung Forward-DNS Rechnernamen in IP-Adressen umwandeln. Origin (Ursprung) Die in einer bestimmten Zonendatei beschriebene Domäne. named, BIND Gebräuchliche Namen für das unter &os; verwendete BIND-Nameserverpaket. Resolver Ein Systemprozess, durch den ein Rechner Zoneninformationen von einem Nameserver anfordert. Reverse-DNS die Umwandlung von IP-Adressen in Rechnernamen Root-Zone Der Beginn der Internet-Zonenhierarchie. Alle Zonen befinden sich innerhalb der Root-Zone. Dies ist analog zu einem Dateisystem, in dem sich alle Dateien und Verzeichnisse innerhalb des Wurzelverzeichnisses befinden. Zone Eine individuelle Domäne, Unterdomäne, oder ein Teil von DNS, der von der gleichen Autorität verwaltet wird. Zonen Beispiele Es folgen nun einige Zonenbeispiele: Innerhalb der Dokumentation wird die Root-Zone in der Regel mit . bezeichnet. org. ist eine Top level Domain (TLD) innerhalb der Root-Zone. example.org. ist eine Zone innerhalb der org.-TLD. 1.168.192.in-addr.arpa. ist die Zone mit - allen IP-Adressen des 192.168.1.*-IP-Bereichs. + allen IP-Adressen des 192.168.1.*-IP-Bereichs. Wie man an diesen Beispielen erkennen kann, befindet sich der spezifischere Teil eines Rechnernamens auf der linken Seite der Adresse. example.org. beschreibt einen Rechner also genauer als org., während org. genauer als die Root-Zone ist. Jeder Teil des Rechnernamens hat Ähnlichkeiten mit einem Dateisystem, in dem etwa /dev dem Wurzelverzeichnis untergeordnet ist. Gründe für die Verwendung eines Nameservers Es gibt zwei Arten von Nameservern: Autoritative Nameserver sowie zwischenspeichernde (cachende, auch bekannt als auflösende) Nameserver. Ein autoritativer Nameserver ist notwendig, wenn Sie anderen verbindliche DNS-Auskünfte erteilen wollen. eine Domain, beispielsweise example.org, registriert wird, und den zu dieser Domain gehörenden Rechnern IP-Adressen zugewiesen werden müssen. ein IP-Adressblock reverse-DNS-Einträge benötigt, um IP-Adressen in Rechnernamen auflösen zu können. ein Backup-Nameserver (auch Slaveserver genannt) oder ein zweiter Nameserver auf Anfragen antworten soll. Ein cachender Nameserver ist notwendig, weil - ein lokaler DNS-Server Daten zwischenspeichern und daher + ein lokaler DNS-Server Daten zwischenspeichern und daher schneller auf Anfragen reagieren kann als ein entfernter Server. Wird nach www.FreeBSD.org gesucht, leitet der Resolver diese Anfrage an den Nameserver des ISPs weiter und nimmt danach das Ergebnis der Abfrage entgegen. Existiert ein lokaler, zwischenspeichernder DNS-Server, muss dieser die Anfrage nur einmal nach außen weitergeben. Für alle weiteren Anfragen ist dies nicht mehr nötig, da diese Information nun lokal gespeichert ist. Wie funktioniert <acronym>DNS</acronym>? Unter &os; wird der BIND-Daemon als named bezeichnet. Datei Beschreibung named Der BIND-Daemon. &man.rndc.8; Das Steuerprogramm für named. /etc/namedb Das Verzeichnis, in dem sich die Zoneninformationen für BIND befinden. /etc/namedb/named.conf Die Konfigurationsdatei für named. Je nachdem, wie eine Zone auf dem Server konfiguriert wurde, finden sich die zur Zone gehörendenden Dateien in den Unterverzeichnissen master, slave, oder dynamic des Verzeichnisses /etc/namedb. Diese Dateien enthalten die DNS-Informationen, die der Nameserver für die Beantwortung von Anfragen benötigt. BIND starten BIND Start Da BIND automatisch installiert wird, ist die Konfiguration relativ einfach. In der Voreinstellung wird ein in einer &man.chroot.8;-Umgebung betriebener named-Server zur einfachen Namensauflösung eingerichtet, der nur im lokalen IPv4-Loopback-Adressbereich (127.0.0.1) lauscht. Um den Server manuell zu starten, verwenden Sie den folgenden Befehl: &prompt.root; service named onestart Um den named-Daemon beim Systemstart automatisch zu starten, fügen Sie folgende Zeile in /etc/rc.conf ein: named_enable="YES" /etc/namedb/named.conf bietet zahlreiche Konfigurationsoptionen, die in diesem Dokument nicht alle beschrieben werden können. Weitere Startoptionen von named unter &os; finden Sie in den named_*-Flags in /etc/defaults/rc.conf sowie in &man.rc.conf.5;. Zusätzliche Informationen finden Sie im des Handbuchs. Konfigurationsdateien BIND Konfigurationsdateien Die Konfigurationsdateien von named finden sich unter /etc/namedb und müssen in der Regel an Ihre Bedürfnisse angepasst werden. Es sei denn, Sie benötigen nur einen einfachen Resolver. Ein Großteil der Konfigurationsarbeiten erfolgt dabei in diesem Verzeichnis. <filename>/etc/namedb/named.conf</filename> // $FreeBSD$ // // Refer to the named.conf(5) and named(8) man pages, and the documentation // in /usr/share/doc/bind9 for more details. // // If you are going to set up an authoritative server, make sure you // understand the hairy details of how DNS works. Even with // simple mistakes, you can break connectivity for affected parties, // or cause huge amounts of useless Internet traffic. options { // All file and path names are relative to the chroot directory, // if any, and should be fully qualified. directory "/etc/namedb/working"; pid-file "/var/run/named/pid"; dump-file "/var/dump/named_dump.db"; statistics-file "/var/stats/named.stats"; // If named is being used only as a local resolver, this is a safe default. // For named to be accessible to the network, comment this option, specify // the proper IP address, or delete this option. listen-on { 127.0.0.1; }; // If you have IPv6 enabled on this system, uncomment this option for // use as a local resolver. To give access to the network, specify // an IPv6 address, or the keyword "any". // listen-on-v6 { ::1; }; // These zones are already covered by the empty zones listed below. // If you remove the related empty zones below, comment these lines out. disable-empty-zone "255.255.255.255.IN-ADDR.ARPA"; disable-empty-zone "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA"; disable-empty-zone "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA"; // If you've got a DNS server around at your upstream provider, enter // its IP address here, and enable the line below. This will make you // benefit from its cache, thus reduce overall DNS traffic in the Internet. /* forwarders { 127.0.0.1; }; */ // If the 'forwarders' clause is not empty the default is to 'forward first' // which will fall back to sending a query from your local server if the name // servers in 'forwarders' do not have the answer. Alternatively you can // force your name server to never initiate queries of its own by enabling the // following line: // forward only; // If you wish to have forwarding configured automatically based on // the entries in /etc/resolv.conf, uncomment the following line and // set named_auto_forward=yes in /etc/rc.conf. You can also enable // named_auto_forward_only (the effect of which is described above). // include "/etc/namedb/auto_forward.conf"; Um vom Cache Ihres Internetproviders zu profitieren, können hier forwarders aktiviert werden. Normalerweise sucht ein Nameserver das Internet rekursiv ab, bis er die gesuchte Antwort findet. Durch diese Option wird stets der Nameserver Ihres Internetproviders zuerst abgefragt, um von dessen Cache zu profitieren. Wenn es sich um einen schnellen, viel benutzten Nameserver handelt, kann dies zu einer Geschwindigkeitssteigerung führen. 127.0.0.1 funktioniert hier nicht. Ändern Sie diese Adresse in einen Nameserver des Einwahlproviders. /* Modern versions of BIND use a random UDP port for each outgoing query by default in order to dramatically reduce the possibility of cache poisoning. All users are strongly encouraged to utilize this feature, and to configure their firewalls to accommodate it. AS A LAST RESORT in order to get around a restrictive firewall policy you can try enabling the option below. Use of this option will significantly reduce your ability to withstand cache poisoning attacks, and should be avoided if at all possible. Replace NNNNN in the example with a number between 49160 and 65530. */ // query-source address * port NNNNN; }; // If you enable a local name server, don't forget to enter 127.0.0.1 // first in your /etc/resolv.conf so this server will be queried. // Also, make sure to enable it in /etc/rc.conf. // The traditional root hints mechanism. Use this, OR the slave zones below. zone "." { type hint; file "/etc/namedb/named.root"; }; /* Slaving the following zones from the root name servers has some significant advantages: 1. Faster local resolution for your users 2. No spurious traffic will be sent from your network to the roots 3. Greater resilience to any potential root server failure/DDoS On the other hand, this method requires more monitoring than the hints file to be sure that an unexpected failure mode has not incapacitated your server. Name servers that are serving a lot of clients will benefit more from this approach than individual hosts. Use with caution. To use this mechanism, uncomment the entries below, and comment the hint zone above. As documented at http://dns.icann.org/services/axfr/ these zones: "." (the root), ARPA, IN-ADDR.ARPA, IP6.ARPA, and ROOT-SERVERS.NET are availble for AXFR from these servers on IPv4 and IPv6: xfr.lax.dns.icann.org, xfr.cjr.dns.icann.org */ /* zone "." { type slave; file "/etc/namedb/slave/root.slave"; masters { 192.5.5.241; // F.ROOT-SERVERS.NET. }; notify no; }; zone "arpa" { type slave; file "/etc/namedb/slave/arpa.slave"; masters { 192.5.5.241; // F.ROOT-SERVERS.NET. }; notify no; }; */ /* Serving the following zones locally will prevent any queries for these zones leaving your network and going to the root name servers. This has two significant advantages: 1. Faster local resolution for your users 2. No spurious traffic will be sent from your network to the roots */ // RFCs 1912 and 5735 (and BCP 32 for localhost) zone "localhost" { type master; file "/etc/namedb/master/localhost-forward.db"; }; zone "127.in-addr.arpa" { type master; file "/etc/namedb/master/localhost-reverse.db"; }; zone "255.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; // RFC 1912-style zone for IPv6 localhost address zone "0.ip6.arpa" { type master; file "/etc/namedb/master/localhost-reverse.db"; }; // "This" Network (RFCs 1912 and 5735) zone "0.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; // Private Use Networks (RFCs 1918 and 5735) zone "10.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "16.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "17.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "18.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "19.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "20.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "21.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "22.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "23.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "24.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "25.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "26.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "27.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "28.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "29.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "30.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "31.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "168.192.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; // Link-local/APIPA (RFCs 3927 and 5735) zone "254.169.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; // IETF protocol assignments (RFCs 5735 and 5736) zone "0.0.192.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; // TEST-NET-[1-3] for Documentation (RFCs 5735 and 5737) zone "2.0.192.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "100.51.198.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "113.0.203.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; // IPv6 Range for Documentation (RFC 3849) zone "8.b.d.0.1.0.0.2.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; // Domain Names for Documentation and Testing (BCP 32) zone "test" { type master; file "/etc/namedb/master/empty.db"; }; zone "example" { type master; file "/etc/namedb/master/empty.db"; }; zone "invalid" { type master; file "/etc/namedb/master/empty.db"; }; zone "example.com" { type master; file "/etc/namedb/master/empty.db"; }; zone "example.net" { type master; file "/etc/namedb/master/empty.db"; }; zone "example.org" { type master; file "/etc/namedb/master/empty.db"; }; // Router Benchmark Testing (RFCs 2544 and 5735) zone "18.198.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "19.198.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; // IANA Reserved - Old Class E Space (RFC 5735) zone "240.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "241.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "242.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "243.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "244.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "245.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "246.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "247.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "248.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "249.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "250.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "251.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "252.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "253.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "254.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; // IPv6 Unassigned Addresses (RFC 4291) zone "1.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "3.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "4.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "5.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "6.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "7.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "8.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "9.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "a.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "b.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "c.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "d.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "e.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "0.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "1.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "2.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "3.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "4.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "5.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "6.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "7.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "8.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "9.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "a.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "b.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "0.e.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "1.e.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "2.e.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "3.e.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "4.e.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "5.e.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "6.e.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "7.e.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; // IPv6 ULA (RFC 4193) zone "c.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "d.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; // IPv6 Link Local (RFC 4291) zone "8.e.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "9.e.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "a.e.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "b.e.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; // IPv6 Deprecated Site-Local Addresses (RFC 3879) zone "c.e.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "d.e.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "e.e.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "f.e.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; // IP6.INT is Deprecated (RFC 4159) zone "ip6.int" { type master; file "/etc/namedb/master/empty.db"; }; // NB: Do not use the IP addresses below, they are faked, and only // serve demonstration/documentation purposes! // // Example slave zone config entries. It can be convenient to become // a slave at least for the zone your own domain is in. Ask // your network administrator for the IP address of the responsible // master name server. // // Do not forget to include the reverse lookup zone! // This is named after the first bytes of the IP address, in reverse // order, with ".IN-ADDR.ARPA" appended, or ".IP6.ARPA" for IPv6. // // Before starting to set up a master zone, make sure you fully // understand how DNS and BIND work. There are sometimes // non-obvious pitfalls. Setting up a slave zone is usually simpler. // // NB: Don't blindly enable the examples below. :-) Use actual names // and addresses instead. /* An example dynamic zone key "exampleorgkey" { algorithm hmac-md5; secret "sf87HJqjkqh8ac87a02lla=="; }; zone "example.org" { type master; allow-update { key "exampleorgkey"; }; file "/etc/named/dynamic/example.org"; }; */ /* Example of a slave reverse zone zone "1.168.192.in-addr.arpa" { type slave; file "/etc/namedb/slave/1.168.192.in-addr.arpa"; masters { 192.168.1.1; }; }; */ Hierbei handelt es sich um Slave-Einträge für eine Reverse- und Forward-DNS-Zone, die in der Datei named.conf definiert sind. Für jede neue Zone muss ein zusätzlicher Eintrag in named.conf erstellt werden. Ein einfacher Eintrag für eine Zone example.org könnte beispielsweise so aussehen: zone "example.org" { type master; file "master/example.org"; }; Die Option legt fest, dass es sich um eine Master-Zone handelt, deren Zoneninformationen sich in der Datei /etc/namedb/master/example.org befinden. Diese Datei wird durch die Option festgelegt. zone "example.org" { type slave; file "slave/example.org"; }; Hier handelt es sich um einen Slaveserver, der seine Informationen vom Masterserver der betreffenden Zone bezieht und diese in der angegebenen Datei speichert. Wenn der Masterserver nicht erreichbar ist, verfügt der Slaveserver über die transferierten Zoneninformationen und kann diese an andere Rechner weitergeben. Zonendateien BIND Zonendatei Die in der Datei /etc/namedb/master/example.org definierte Zonendatei für example.org könnte etwa so aussehen: $TTL 3600 ; 1 hour default TTL example.org. IN SOA ns1.example.org. admin.example.org. ( 2006051501 ; Serial 10800 ; Refresh 3600 ; Retry 604800 ; Expire 300 ; Negative Response TTL ) ; DNS Servers IN NS ns1.example.org. IN NS ns2.example.org. ; MX Records IN MX 10 mx.example.org. IN MX 20 mail.example.org. IN A 192.168.1.1 ; Machine Names localhost IN A 127.0.0.1 ns1 IN A 192.168.1.2 ns2 IN A 192.168.1.3 mx IN A 192.168.1.4 mail IN A 192.168.1.5 ; Aliases www IN CNAME example.org. Beachten Sie, dass jeder mit einem . endende Rechnername ein exakter Rechnername ist, während sich alles ohne einen abschließenden . relativ auf den Ursprung bezieht. ns1 steht daher beispielsweise für ns1.example.org.. Eine Zonendatei hat folgenden Aufbau: recordname IN recordtype value - DNS + DNS Einträge - Die am häufigsten verwendeten DNS-Einträge sind: + Die am häufigsten verwendeten + DNS-Einträge sind: SOA Start der Zonenautorität NS Ein autoritativer Nameserver A Eine Rechneradresse CNAME Der kanonische Name eines Alias MX Mail Exchanger PTR Ein (bei Reverse-DNS verwendeter) Domain Name Pointer example.org. IN SOA ns1.example.org. admin.example.org. ( 2006051501 ; Serial 10800 ; Refresh after 3 hours 3600 ; Retry after 1 hour 604800 ; Expire after 1 week 300 ) ; Negative Response TTL example.org. Der Name der Domäne und damit der Ursprung dieser Zonendatei. ns1.example.org. Der primäre/autoritative Nameserver dieser Zone. admin.example.org. Die für diese Zone verantwortliche Person. Das Zeichen @ wird dabei ersetzt (admin@example.org wird also zu admin.example.org). 2006051501 Die Seriennummer der Datei. Sie muss stets inkrementiert werden, wenn die Zonendatei geändert wird. Viele Administratoren bevorzugen ein JJJJMMTTRR-Format, um die Seriennummer festzulegen. 2006051501 steht also für den 15.05.2006, die beiden letzten Stellen für die erste Modifikation der Zonendatei an diesem Tag. Die Seriennummer ist von großer Bedeutung, da Slaveserver daran eine aktualisierte Zonendatei erkennen können. IN NS ns1.example.org. Ein NS-Eintrag. Jeder Nameserver, der für eine Zone verantwortlich ist, muss über einen solchen Eintrag verfügen. localhost IN A 127.0.0.1 ns1 IN A 192.168.1.2 ns2 IN A 192.168.1.3 mx IN A 192.168.1.4 mail IN A 192.168.1.5 Der Eintrag A bezieht sich auf Rechnernamen. ns1.example.org würde also zu 192.168.1.2 aufgelöst werden. IN A 192.168.1.1 - Diese Zeile weist die IP-Adresse + Diese Zeile weist die IP-Adresse 192.168.1.1 dem aktuellen Ursprung, in unserem Fall also example.org, zu. www IN CNAME @ Der Eintrag für den kanonischen Namen wird dazu verwendet, Aliase für einen Rechner zu vergeben. Im Beispiel ist www ein Alias für den Master-Rechner, dessen Name dem Domainnamen example.org (oder 192.168.1.1) entspricht. CNAMEs können daher niemals gleichzeitig mit einem anderen Eintrag für denselben Hostname eingerichtet werden. MX-Eintrag IN MX 10 mail.example.org. - Die Option MX legt fest, welcher Mailserver für + Der MX-Eintrag legt fest, welcher Mailserver für eintreffende Mails der Zone verantwortlich ist. mail.example.org ist der Rechnername des Mailservers, der eine Priorität von 10 hat. Es können auch mehrere Mailserver mit verschiedener Priorität (10, 20, ...) vorhanden sein. Ein Mailserver, der eine Mail an example.org verschicken will, verwendet zuerst den MX mit der höchsten Priorität (das heißt den mit der niedrigsten Prioritätsnummer), danach den mit der nächsthöheren Priorität. Und dies solange, bis die E-Mail zugestellt werden kann. Für (bei Reverse-DNS verwendete) in-addr.arpa-Zonendateien wird das gleiche Format verwendet. Der einzige Unterschied besteht in der Verwendung der Option PTR an Stelle der Optionen A und CNAME. $TTL 3600 1.168.192.in-addr.arpa. IN SOA ns1.example.org. admin.example.org. ( 2006051501 ; Serial 10800 ; Refresh 3600 ; Retry 604800 ; Expire 300 ) ; Negative Response TTL IN NS ns1.example.org. IN NS ns2.example.org. 1 IN PTR example.org. 2 IN PTR ns1.example.org. 3 IN PTR ns2.example.org. 4 IN PTR mx.example.org. 5 IN PTR mail.example.org. Durch diese Datei werden den Rechnernamen der fiktiven - Domäne IP-Adressen zugewiesen. + Domäne IP-Adressen zugewiesen. Beachten Sie bitte, dass es sich bei allen Namen auf der rechten Seite eines PTR-Eintrags um absolute (fully qualified) Domainnamen handeln muss, die mit . enden. Zwischenspeichernde (cachende) Nameserver BIND Zwischenspeichernde Nameserver Ein cachender Nameserver hat primär die Aufgabe, rekursive Abfragen aufzulösen. Er stellt lediglich eigene Anfragen und speichert deren Ergebnisse ab. <acronym role="Doman Name Security Extensions">DNSSEC</acronym> BIND - DNS security extensions + DNS security extensions Domain Name System Security Extensions, oder kurz DNSSEC, ist eine Sammlung von Spezifikationen, um auflösende Nameserver von gefälschten DNS-Daten, wie beispielsweise vorgetäuschte DNS-Einträge, zu schützen. Durch die Verwendung von digitalen Signaturen kann ein Resolver die Integrität des Eintrages überprüfen. Wichtig dabei ist, dass DNSSEC nur die Integrität über digital signierte Resource Records (RRe) bereitstellt. Weder wird die Vertraulichkeit noch der Schutz vor falschen Annahmen des Endbenutzers sichergestellt. Dies bedeutet, dass es Leute nicht davor schützen kann, zu example.net anstatt zu example.com zu gelangen. Das einzige, was DNSSEC tut, ist die Authentifizierung, dass die Daten während der Übertragung nicht verändert wurden. Die Sicherheit von DNS ist ein wichtiger Schritt in der generellen Absicherung des Internets. Für weitere, tiefergehende Details über die Funktionsweise von DNSSEC sind die dazugehörigen RFCs ein guter Einstieg in die Thematik. Sehen Sie sich dazu die Liste in an. Der folgende Abschnitt wird zeigen, wie man DNSSEC für einen autoritativen DNS-Server und einen rekursiven (oder cachenden) DNS-Server, der jeweils BIND 9 verwenden, einrichten kann. Obwohl alle Versionen von BIND 9 DNSSEC unterstützen, ist es notwendig, mindestens die Version 9.6.2 zu verwenden, um in der Lage zu sein, die signierten Root-Zonen zu benutzen, wenn DNS-Abfragen geprüft werden. Der Grund dafür ist, dass früheren Versionen die Algorithmen fehlen, um die Überprüfung des Root-Zonenschlüssels zu aktivieren. Es wird dringend empfohlen, die letzte Version von BIND 9.7 oder höher einzusetzen, um von den Vorteilen der automatischen Schlüsselaktualisierung des Root-Zonenschlüssels Gebrauch zu machen, genauso wie andere Eigenschaften, um automatisch Zonen signieren zu lassen und Signaturen aktuell zu halten. Unterschiede zwischen den Versionen 9.6.2 und 9.7 und höher werden an den betreffenden Stellen angesprochen. Rekursive <acronym>DNS</acronym>-Server Konfiguration Die Aktivierung der DNSSEC-Überprüfung von Anfragen, die von einem rekursiven DNS-Server stammen, benötigt ein paar Änderungen in der named.conf. Bevor man jedoch diese Änderungen durchführt, muss der Root-Zonenschlüssel oder Vertrauensanker erworben werden. Momentan ist der Root-Zonenschlüssel nicht in einem Dateiformat verfügbar, dass von BIND benutzt werden kann, so dass dieser manuell in das richtige Format konvertiert werden muss. Der Schlüssel selbst kann durch Abfrage an die Root-Zone erhalten werden, indem man dazu dig verwendet. Durch Aufruf von &prompt.user; dig +multi +noall +answer DNSKEY . > root.dnskey wird der Schlüssel in root.dnskey abgelegt. Der Inhalt sollte so ähnlich wie folgt aussehen: . 93910 IN DNSKEY 257 3 8 ( AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQ bSEW0O8gcCjFFVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh /RStIoO8g0NfnfL2MTJRkxoXbfDaUeVPQuYEhg37NZWA JQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaDX6RS6CXp oY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3 LQpzW5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGO Yl7OyQdXfZ57relSQageu+ipAdTTJ25AsRTAoub8ONGc LmqrAmRLKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0= ) ; key id = 19036 . 93910 IN DNSKEY 256 3 8 ( AwEAAcaGQEA+OJmOzfzVfoYN249JId7gx+OZMbxy69Hf UyuGBbRN0+HuTOpBxxBCkNOL+EJB9qJxt+0FEY6ZUVjE g58sRr4ZQ6Iu6b1xTBKgc193zUARk4mmQ/PPGxn7Cn5V EGJ/1h6dNaiXuRHwR+7oWh7DnzkIJChcTqlFrXDW3tjt ) ; key id = 34525 Seien Sie nicht alarmiert, wenn der von Ihnen bezogene Schlüssel anders als in diesem Beispiel aussieht. Diese könnten sich in der Zwischenzeit geändert haben. In dieser Ausgabe sind eigentlich zwei Schlüssel enthalten. Der erste Schüssel mit dem Wert 257 nach dem DNSKEY-Eintrag ist derjenige, der benötigt wird. Der Wert zeigt an, dass es sich um einen sicheren Einstiegspunkt (SEP), gemein auch als Schlüsselsignierungsschlüssel (KSK) bekannt, handelt. Der zweite Schüssel mit dem Wert 256 ist der untergeordnete Schlüssel, im allgemeinen auch als Zonen-Signaturschlüssel (ZSK) bezeichnet. Weitere Schlüsselarten werden später in erläutert. Nun muss der Schlüssel verifiziert und so formatiert werden, dass BIND diesen verwenden kann. Um den Schlüssel zu verifizieren, erzeugen Sie einen DS RR-Satz. Erstellen Sie eine Datei, welche die RRs enthält, mittels &prompt.user; dnssec-dsfromkey -f root-dnskey . > root.ds Diese Einträge verwenden SHA-1 sowie SHA-256 und sollten ähnlich zu folgendem Beispiel aussehen, in dem der längere, SHA-256, benutzt wird. . IN DS 19036 8 1 B256BD09DC8DD59F0E0F0D8541B8328DD986DF6E . IN DS 19036 8 2 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5 Der SHA-256 RR kann nun mit dem Abriss in https://data.iana.org/root-anchors/root-anchors.xml verglichen werden. Um absolut sicher zu sein, dass der Schlüssel nicht zusammen mit den XML-Daten verändert wurde, kann die Datei mittels der PGP Signatur in https://data.iana.org/root-anchors/root-anchors.asc überprüft werden. Als nächstes muss der Schlüssel in das passende Format gebracht werden. Dies unterscheidet sich ein bisschen von den BIND Versionen 9.6.2 und 9.7 und höhere. In Version 9.7 wurde die Ünterstützung zur automatischen Verfolgung und notwendigen Aktualisierung von Änderungen am Schlüssel eingebaut. Dies wird durch den Einsatz von managed-keys erreicht, wie in dem Beispiel unten gezeigt ist. Wenn die ältere Version eingesetzt wird, kann der Schlüssel durch eine trusted-keys-Anweisung eingebaut werden und die Aktualisierung muss händisch erfolgen. In BIND 9.6.2 sollte das Format folgendermassen aussehen: trusted-keys { "." 257 3 8 "AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq QxA+Uk1ihz0="; }; In 9.7 wird das Format stattdessen wie folgt aussehen: managed-keys { "." initial-key 257 3 8 "AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq QxA+Uk1ihz0="; }; Der Root-Schlüssel kann nun zu named.conf hinzugefügt werden, entweder direkt oder durch Inkludierung der Datei, die den Schlüssel enthält. Nachdem diese Schritte absolviert sind, muss BIND konfiguriert werden, um DNSSEC-Validierung für Anfragen durchzuführen, indem named.conf bearbeitet und die folgende options-Direktive hinzugefügt wird: dnssec-enable yes; dnssec-validation yes; Um zu prüfen, dass es tatsächlich funktioniert, benutzen Sie dig, um eine Anfrage zu einer signierten Zone durch den Resolver, der gerade konfiguriert wurde, zu stellen. Eine erfolgreiche Antwort wird den AD-Eintrag aufweisen, um anzudeuten, dass die Daten authentisiert sind. Eine Anfrage wie &prompt.user; dig @resolver +dnssec se ds sollte den DS RR für die .se-Zone zurückgeben. In dem Abschnitt flags: sollte der AD-Eintrag gesetzt sein, wie im folgenden zu sehen ist: ... ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1 ... Der Resolver ist nun in der Lage, Anfragen ans DNS zu authentisieren. Autoritative <acronym>DNS</acronym>-Server Konfiguration Um einen autoritativen Nameserver dazu zu bringen, als eine DNSSEC-signierte Zone zu fungieren, ist ein wenig mehr Aufwand nötig. Eine Zone ist durch kryptographische Schlüssel signiert, die erzeugt werden müssen. Es ist möglich, nur einen Schlüssel dazu zu verwenden. Die vorgeschlagene Methode ist jedoch, einen starken, gut geschützten Schlüsselsignierungsschlüssel (KSK) einzusetzen, der nicht oft gewechselt wird und einen Zonensignierungsschlüssel (ZSK), der öfter ausgewechselt wird. Informationen zu vorgeschlagenen Einsatzarten können in RFC 4641: DNSSEC Operational Practices nachgelesen werden. Einsatzszenarien, welche die Root-Zone betreffen, finden Sie in DNSSEC Practice Statement for the Root Zone KSK operator sowie DNSSEC Practice Statement for the Root Zone ZSK operator. Der KSK wird dazu verwendet, um eine Kette von Autorität für die Daten, die diese Validierung benötigen, zu erschaffen und wird als solche auch als sicherer Einstiegspunkt (SEP)-Schlüssel bezeichnet. Ein Nachrichtenabriss dieses Schlüssels, der auch Delegation Signer (DS)-Eintrag genannt wird, muss in der Elternzone veröffentlicht werden, um die Vertrauenskette herzustellen. Wie dies erreicht wird, hängt von dem Besitzer der Elternzone ab. Der ZSK wird verwendet, um die Zone zu signieren und muss nur dort öffentlich zugänglich gemacht werden. Um DNSSEC für die example.com-Zone, welche in den vorherigen Beispielen verwendet wird, zu aktivieren, muss als erster Schritt dnssec-keygen benutzt werden, um das KSK und ZSK Schlüsselpaar zu generieren. Dieses Schlüsselpaar kann unterschiedliche kryptographische Algorithmen nutzen. Es wird empfohlen, RSA/SHA256 für die Schlüssel zu nutzen. Eine Schlüssellänge von 2048 Bits sollte genügen. Um den KSK für example.com zu generieren, geben Sie &prompt.user; dnssec-keygen -f KSK -a RSASHA256 -b 2048 -n ZONE example.com ein und um den ZSK zu erzeugen, setzen Sie folgenden Befehl ab: &prompt.user; dnssec-keygen -a RSASHA256 -b 2048 -n ZONE example.com dnssec-keygen gibt zwei Dateien aus, den öffentlichen und den privaten Schlüssel und zwar in Dateinamen, die ähnlich lauten wie Kexample.com.+005+nnnnn.key (öffentlich) und Kexample.com.+005+nnnnn.private (privat). Der nnnnn-Teil des Dateinamens ist eine fünfstellige Schlüsselkennung. Passen Sie genau auf, welche Kennung zu welchem Schlüssel gehört. Das ist besonders wichtig, wenn mehrere Schlüssel in einer Zone vorliegen. Es ist auch möglich, die Schlüssel umzubenennen. Für jede KSK-Datei tun Sie folgendes: &prompt.user; mv Kexample.com.+005+nnnnn.key Kexample.com.+005+nnnnn.KSK.key &prompt.user; mv Kexample.com.+005+nnnnn.private Kexample.com.+005+nnnnn.KSK.private Für die ZSK-Dateien ersetzen Sie KSK für ZSK wenn nötig. Die Dateien können nun in der Zonendatei inkludiert werden, indem die $include Anweisung verwendet wird. Es sollte folgendermassen aussehen: $include Kexample.com.+005+nnnnn.KSK.key ; KSK $include Kexample.com.+005+nnnnn.ZSK.key ; ZSK Schliesslich signieren Sie die Zone und weisen BIND an, die signierte Zonendatei zu benutzen. Um eine Zone zu signieren, wird dnssec-signzone eingesetzt. Der Befehl, um eine Zone example.com zu signieren, die in example.com.db liegt, sollte wie folgt aussehen: &prompt.user; dnssec-signzone -o example.com -k Kexample.com.+005+nnnnn.KSK example.com.db Kexample.com.+005+nnnnn.ZSK.key Der Schlüssel, welcher mit dem Argument übergeben wird, ist der KSK und die andere Schlüsseldatei ist der ZSK, welcher für die Signatur benutzt werden soll. Es ist möglich, mehr als einen KSK und ZSK anzugeben, was das Ergebnis zur Folge hat, dass die Zone mit allen übergebenen Schlüsseln signiert wird. Dies kann dann benötigt werden, um Zonendaten mit mehr als einem Algorithmus zur Signierung zu verwenden. Die Ausgabe von dnssec-signzone ist eine Zonendatei mit allen signierten RRs. Diese Ausgabe wird in einer Datei mit der Endung .signed abgelegt, wie beispielsweise example.com.db.signed. Die DS-Einträge werden ebenfalls in eine separate Datei dsset-example.com geschrieben. Um diese signierte Zone zu verwenden, ändern Sie die Zonendirektive in named.conf, so dass example.com.db.signed benutzt wird. Standardmässig sind die Signaturen nur 30 Tage gültig, was bedeutet, dass die Zone in etwa 15 Tagen erneut signiert werden muss, um sicher zu stellen, dass Resolver keine Einträge mit veralteten Signaturen zwischenspeichern. Es ist möglich, ein Skript und einen cron-Job zu schreiben, um dies zu erledigen. Lesen Sie dazu die relevanten Anleitungen, um Details zu erfahren. Stellen Sie sicher, dass die privaten Schlüssel vertraulich bleiben, genau wie mit allen anderen kryptographischen Schlüsseln auch. Wenn ein Schlüssel geändert wird, ist es gute Praxis den neuen Schlüssel in die Zone zu inkludieren, noch während der alte Schlüssel noch zum signieren eingesetzt wird, um dann auf den neuen Schlüssel zum signieren zu wechseln. Nachdem diese Schritte erfolgt sind, kann der alte Schlüssel aus der Zone entfernt werden. Wenn das nicht geschieht, können DNS-Daten für einige Zeit nicht verfügbar sein, bis der neue Schlüssel durch die DNS-Hierarchie propagiert wurde. Für weitere Informationen bezüglich Schlüsselübergabe und andere DNSSEC-Einsatzszenarien lesen Sie RFC 4641: DNSSEC Operational practices. Automatisierung mittels <acronym>BIND</acronym> 9.7 oder höher Beginnend mit der Version 9.7 von BIND wurde eine neue Eigenschaft vorgestellt, die Smart Signing genannt wird. Diese zielt darauf ab, das Schlüsselmanagement und den Signierungsprozess einfacher zu gestalten und zu automatisieren. Durch ablegen der Schlüssel in ein Verzeichnis, genannt key repository und die Verwendung der neuen Option auto-dnssec, ist es möglich eine dynamische Zone zu erzeugen, welche dann erneut signiert wird, wenn dazu der Bedarf besteht. Um diese Zone zu aktualisieren, benutzen Sie nsupdate mit der neuen Option . Es hat also rndc die Fähigkeit gewonnen, Zonen mit Schlüsseln im Key Repository zu verwenden, indem die Option eingesetzt wird. Um BIND anzuweisen, diese automatische Signierung und Zonenaktualisierung für example.com zu nutzen, fügen Sie die folgenden Zeilen zur named.conf hinzu: zone example.com { type master; key-directory "/etc/named/keys"; update-policy local; auto-dnssec maintain; file "/etc/named/dynamic/example.com.zone"; }; Nachdem diese Änderungen durchgeführt wurden, erzeugen Sie die Schlüssel für die Zone wie in beschrieben wird, legen diese Schlüssel im Key Repository ab, dass als Argument key-directory in der Zonenkonfiguration steht und die Zone wird automatisch signiert. Aktualisierungen für eine Zone, die auf diese Art und Weise konfiguriert wurde, muss mittels nsupdate erfolgen, dass sich um die erneute Signierung der Zone mit den hinzugefügten Daten kümmern wird. Für weitere Details, lesen Sie und die Dokumentation von BIND. Sicherheit - Obwohl BIND die am meisten verwendete (und kontrollierte) - Implementierung von DNS darstellt, werden dennoch manchmal neue + Obwohl BIND die am meisten verwendete Implementierung von + DNS darstellt, werden dennoch manchmal neue Sicherheitsprobleme entdeckt. Zwar startet &os; named automatisch in einer &man.chroot.8;-Umgebung, es gibt aber noch weitere Sicherheitsmechanismen, mit denen Sie potentielle DNS-Serviceattacken erschweren können. Es ist daher eine gute Idee, die Sicherheitshinweise von CERT zu lesen sowie die Mailingliste &a.security-notifications; zu abonnieren, um sich über Sicherheitsprobleme im Zusammenhang mit dem Internet und FreeBSD zu informieren. Tritt ein Problem auf, kann es nie schaden, die Quellen zu aktualisieren und named neu zu kompilieren. Weitere Informationsquellen Hilfeseiten zu BIND/named: &man.rndc.8; &man.named.8; &man.named.conf.5; &man.nsupdate.1; &man.dnssec-signzone.8; &man.dnssec-keygen.8; Offizielle ISC-Seite zu BIND Offizielles Forum zu ISC- BIND O'Reilly - DNS and BIND 5th Edition + DNS and BIND 5th Edition Root DNSSEC DNSSEC Vertrauensanker-Publikation für die Root-Zone RFC1034 - Domain Names - Concepts and Facilities RFC1035 - Domain Names - Implementation and Specification RFC4033 - - DNS Security Introduction and Requirements + - DNS Security Introduction and Requirements RFC4034 - - Resource Records for the DNS Security + - Resource Records for the DNS Security Extensions RFC4035 - - Protocol Modifications for the DNS Security - Extensions + - Protocol Modifications for the DNS Security Extensions RFC4641 - - DNSSEC Operational Practices + - DNSSEC Operational Practices RFC 5011 - - Automated Updates of DNS Security (DNSSEC) + - Automated Updates of DNS Security (DNSSEC) Trust Anchors Der Apache HTTP-Server Webserver konfigurieren Apache Einige der weltgrößten Internetauftritte laufen unter &os;. Die Mehrzahl der Webserver im Internet nutzt den Apache HTTP-Server. Die Installationspakete für den Apache sollten auf Ihrem Installationsmedium vorhanden sein. Wenn Sie den Apache noch nicht installiert haben, können Sie dies jederzeit über den Port www/apache22 nachholen. Nachdem der Apache erfolgreich installiert wurde, muss er noch konfiguriert werden. Dieser Abschnitt beschreibt die Version 2.2.X des Apache HTTP-Servers, da diese Version unter &os; am häufigsten verwendet wird. Weiterführende Informationen zu Apache 2.X finden Sie auf http://httpd.apache.org/. Konfiguration Apache Konfigurationsdatei Der Apache HTTP-Server wird unter &os; primär über die Datei /usr/local/etc/apache22/httpd.conf konfiguriert. Bei dieser Datei handelt es sich um eine typische &unix;-Konfigurationsdatei, in der Kommentarzeilen mit einem #-Zeichen beginnen. Eine komplette Beschreibung aller Optionen würde den Rahmen dieses Handbuchs sprengen, daher beschreiben wir hier nur die am häufigsten verwendeten Optionen. ServerRoot "/usr/local" Legt das Standardwurzelverzeichnis für die Apache-Installation fest. Binärdateien werden in die Verzeichnisse bin und sbin unterhalb des Serverwurzelverzeichnisses installiert, während sich Konfigurationsdateien im Verzeichnis etc/apache befinden. ServerAdmin you@your.address Die E-Mail-Adresse, an die Mitteilungen über Serverprobleme geschickt werden sollen. Diese Adresse erscheint auf vom Server erzeugten Seiten, beispielsweise auf Fehlerseiten. ServerName www.example.com ServerName erlaubt dem Administrator, einen anderen Rechnernamen festzulegen, den der Server an die Clients sendet, wenn sich dieser vom tatsächlichen Rechnernamen unterscheidet (sie könnten etwa www statt des richtigen Rechnernamens verwenden). DocumentRoot "/usr/local/www/apache22/data" DocumentRoot: Das Verzeichnis, in dem die Dokumente abgelegt sind. In der Voreinstellung befinden sich alle Seiten in diesem Verzeichnis, durch symbolische Links oder Aliase lassen sich aber auch andere Orte festlegen. Es ist empfehlenswert, eine Sicherungskopie der Apache-Konfigurationsdatei anzulegen, bevor Änderungen durchgeführt werden. Wenn die Konfiguration von Apache abgeschlossen ist, speichern Sie die Datei und überprüfen Sie die Konfiguration mit &man.apachectl.8;. Geben Sie dazu apachectl configtest ein. Dieser Befehl sollte Syntax OK zurückgeben. Den <application>Apache</application> betreiben Apache Starten oder Beenden Der www/apache22 Port installiert ein &man.rc.8; Skript, welches zum starten, stoppen und neustarten von Apache benutzt werden kann. Das Skript befindet sich in /usr/local/etc/rc.d/. Um den Apache beim Systemstart zu starten, fügen Sie folgende Zeile in /etc/rc.conf ein: apache22_enable="YES" Wenn Sie während des Systemstarts weitere Parameter an den Apache übergeben wollen, können Sie diese durch eine zusätzliche Zeile in rc.conf angeben: apache22_flags="" Die Konfiguration von Apache kann bei nachfolgenden Änderungen an der Konfigurationsdatei bei laufendem httpd, auf Fehler überprüft werden. Dies kann durch das &man.rc.8;-Skript direkt , oder über das Dienstprogramm &man.service.8; geschehen, indem Sie eines der folgenden Kommandos ausführen: &prompt.root; service apache22 configtest Es ist wichitg zu beachten, dass configtest kein &man.rc.8;-Standard ist, und somit nicht zwingend mit anderen &man.rc.8;-Startskripten funktioniert. Wenn der Apache keine Fehler in der Konfiguration meldet, kann der Apache  httpd mithilfe von &man.service.8; gestartet werden: &prompt.root; /usr/local/etc/rc.d/apache22 start &prompt.root; service apache22 start Sie können den httpd-Dienst testen, indem Sie http://localhost in Ihren Browser eingeben, wobei Sie localhost durch den vollqualifizierten Domainnamen der Machine ersetzen, auf dem der httpd läuft. Die Standard Webseite, die angezeigt wird, ist /usr/local/www/apache22 /data/index.html. Virtual Hosting Der Apache unterstützt zwei Formen des Virtual Hostings. Die erste Möglichkeit bezeichnet man als namenbasiertes virtuelles Hosting. Dabei wird der HTTP/1.1-Header der Clients dazu verwendet, den Rechnernamen zu bestimmen. Dadurch wird es - möglich, mehrere Domains unter der gleichen IP-Adresse zu - betreiben. + möglich, mehrere Domains unter der gleichen + IP-Adresse zu betreiben. Damit der Apache namenbasierte virtuelle Domains verwalten kann, fügen Sie die folgende Zeile in httpd.conf ein: NameVirtualHost * Wenn der Webserver www.domain.tld heißt und die virtuelle Domain www.someotherdomain.tld einrichtet werden soll, ergänzen Sie httpd.conf um folgende Einträge: <VirtualHost *> ServerName www.domain.tld DocumentRoot /www/domain.tld </VirtualHost> <VirtualHost *> ServerName www.someotherdomain.tld DocumentRoot /www/someotherdomain.tld </VirtualHost> Ersetzen Sie dabei die Adressen sowie den Pfad zu den Dokumenten durch Ihre eigenen Einstellungen. Ausführliche Informationen zum Einrichten von virtuellen Domains finden Sie in der offiziellen Apache-Dokumentation unter http://httpd.apache.org/docs/vhosts/. Häufig verwendete Apache-Module Apache Module Es gibt viele verschiedene Apache-Module, die den Server um zusätzliche Funktionen erweitern. Die &os; Ports-Sammlung ermöglicht es Ihnen, den Apache gemeinsam mit einigen der beliebtesten Zusatzmodule zu installieren. <application>mod_ssl</application> Webserver Verschlüsselung SSL Verschlüsselung Das Modul mod_ssl verwendet die OpenSSL-Bibliothek, um, unter Nutzung der Protokolle Secure Sockets Layer (SSL v2/v3) sowie Transport Layer Security (TLS v1) starke Verschlüsselung zu ermöglichen. Durch dieses Modul können Sie ein signiertes Zertifikat von einer Zertifizierungsstelle anfordern, damit Sie einen sicheren Webserver unter &os; betreiben können. Das Modul mod_ssl wird standardmäßig kompiliert, kann aber auch noch nachträglich durch die Angabe von -DWITH_SSL zur Kompilierzeit aktiviert werden. Skriptsprachen Für die wichtigsten Skriptsprachen existieren Module, die es erlauben, Apache-Module nahezu vollständig in einer Skriptsprache zu programmieren. Derartige Module dienen oft dazu, einen Sprach-Interpreter in den Webserver einzubetten. Dadurch wird ein zusätzlicher externer Interpreter überflüssig, was die Startzeit von dynamischen Internetseiten deutlich verringert. Dynamische Webseiten Webserver dynamisch In den vergangenen Jahren haben immer mehr Unternehmen das Internet als Mittel für die Steigerung ihrer Einnahmen sowie für die Erhöhung ihrer Reichweite entdeckt. Dadurch stieg auch die Nachfrage nach interaktiven Internetinhalten. Neben einigen Unternehmen, darunter µsoft;, die dafür proprietäre Produkte entwickelt haben, hat auch die Open Source Community auf diesen Umstand reagiert und unter anderem mit Django, Ruby on Rails, mod_perl2, und mod_php Möglichkeiten zur Generierung dynamischer Internetseiten geschaffen. Django Python Django Bei Django handelt es sich um ein unter der BSD-Lizenz verfügbares Framework zur schnellen Erstellung von mächtigen Internet-Applikationen. Es beinhaltet einen objekt-relationalen Mapper (wodurch Datentypen als Phyton-Objekte entwickelt werden können) sowie eine API für den dynamischen Datenbankzugriff auf diese Objekte, ohne dass Entwickler jemals SQL-Code schreiben müssen. Zusätzlich existiert ein umfangreiches Template-System, wodurch die Programmlogik von der HTML-Präsentation getrennt werden kann. Django setzt das Modul mod_python, den Apache-Webserver sowie eine SQL-Datenbank voraus. Der &os;-Port wird alle Abhängigkeiten mit sinnvollen Optionen konfigurieren und installieren. Django mit <application>Apache2</application>, <application>mod_python3</application>, und <application>PostgreSQL</application> installieren &prompt.root; cd /usr/ports/www/py-django; make all install clean -DWITH_MOD_PYTHON3 -DWITH_POSTGRESQL Nachdem Django und die abhängigen Pakete installiert sind, benötigt die Anwendung ein Projektverzeichnis und die Apache-Konfiguration, um den eingebetteten Python-Interpreter zu nutzen. Dieser wird spezifische URLs der Seite aufrufen. Apache-Konfiguration für Django/mod_python Sie müssen httpd.conf anpassen, damit Apache Anfragen für bestimmte URLs an die Internet-Applikation übergibt: <Location "/"> SetHandler python-program PythonPath "['/dir/to/the/django/packages/'] + sys.path" PythonHandler django.core.handlers.modpython SetEnv DJANGO_SETTINGS_MODULE mysite.settings PythonAutoReload On PythonDebug On </Location> Ruby on Rails Ruby on Rails Bei Ruby on Rails handelt es sich um ein weiteres, als Open Source verfügbares Webframework. Es bietet einen kompletten Entwicklungsstack und erlaubt es Webentwicklern, umfangreiche und mächtige Applikationen in kurzer Zeit zu programmieren. Das Framework kann über die Ports-Sammlung installiert werden. &prompt.root; cd /usr/ports/www/rubygem-rails; make all install clean <application>mod_perl2</application> mod_perl2 Perl Die Kombination Apache/Perl vereinigt die Vorteile der Programmiersprache Perl und des Apache HTTP-Servers. Durch das Modul mod_perl2 ist es möglich, vollständig in Perl geschriebene Apache-Module zu erzeugen. Da der Perl-Interpreter in den Server eingebettet wird, müssen Sie weder einen externen Interpreter noch Perl zusätzlich aufrufen. mod_perl2 ist über den Port www/mod_perl2 erhältlich. <application>mod_php</application> mod_php PHP Bei PHP>, dem Hypertext Preprocessor, handelt es sich um eine vielseitig verwendbare Skriptsprache, die besonders für die Web-Entwicklung geeignet ist. PHP kann in HTML eingebettet werden und ähnelt von der Syntax her Sprachen wie C, &java; und Perl. Das Hauptanliegen von PHP ist es, Web-Entwicklern die rasche Erstellung von dynamisch erzeugten Internetseiten zu ermöglichen. Damit Ihr System PHP5 unterstützt, müssen Sie als Erstes den Apache Webserver über den Port lang/php5 installieren. Wenn Sie den Port lang/php5 das erste Mal installieren, werden die verfügbaren Optionen (OPTIONS) automatisch angezeigt. Erscheint das Konfigurationsmenü bei Ihnen nicht, so liegt dies daran, dass Sie den Port lang/php5 schon einmal auf Ihrem System installiert hatten. Es ist aber jederzeit möglich, dieses Menü aus dem Ports-Verzeichnis heraus über folgenden Befehl erneut aufzurufen: &prompt.root; make config In diesem Konfigurationsmenü müssen Sie die Option APACHE auswählen, damit mod_php5 als ein vom Apache-Webserver ladbares Modul gebaut wird. Viele Seiten verwenden nach wie vor (beispielsweise wegen der benötigten Kompatibilität zu bereits vorhandenen Web-Applikationen) PHP4. Ist dies bei Ihnen der Fall, so müssen Sie statt mod_php5 mod_php4 über den Port lang/php4 installieren. Der Port lang/php4 unterstützt viele der Konfigurations- und Laufzeitoptionen von lang/php5. Dieser Port installiert und konfiguriert die Module, die für die Unterstützung von dynamischen PHP-Anwendungen benötigt werden. Stellen Sie danach sicher, dass Ihre /usr/local/etc/apache22/httpd.conf die folgenden Abschnitte enthält: LoadModule php5_module libexec/apache/libphp5.so AddModule mod_php5.c <IfModule mod_php5.c> DirectoryIndex index.php index.html </IfModule> <IfModule mod_php5.c> AddType application/x-httpd-php .php AddType application/x-httpd-php-source .phps </IfModule> Nachdem dies erledigt ist, rufen Sie apachectl auf, um das PHP-Modul zu laden: &prompt.root; apachectl graceful Bei künftigen Upgrades von PHP wird make config nicht mehr benötigt, da die von Ihnen ursprünglich ausgewählten Optionen (OPTIONS) vom &os;-Ports-Framework automatisch gespeichert werden. Die PHP-Unterstützung von &os; ist stark modular aufgebaut, daher verfügt eine Basisinstallation nur über wenige Funktionen. Eine Erweiterung um zusätzliche Funktionen ist allerdings sehr einfach über den Port lang/php5-extensions möglich. Der Port bietet Ihnen ein Auswahlmenü, über das Sie verschiedene PHP-Erweiterungen installieren können. Alternativ können Sie einzelne Erweiterungen aber weiterhin direkt über den jeweiligen Port installieren. Um beispielsweise die Unterstützung des Datenbankservers MySQL in PHP5 zu aktivieren, installieren Sie den Port databases/php5-mysql. Nachdem Sie eine Erweiterung installiert haben, müssen Sie den Apache-Server neu starten, damit die Erweiterung auch erkannt wird: &prompt.root; apachectl graceful Ab nun wird MySQL von PHP unterstützt. File Transfer Protocol (<acronym>FTP</acronym>) FTP-Server Das File Transfer Protocol (FTP) ermöglicht auf einfache Art und Weise den Dateiaustausch mit einem FTP-Server. Der FTP-Server ftpd ist bei &os; bereits im Basisystem enthalten. Daher sind Konfiguration und Betrieb eines FTP-Servers unter &os; relativ einfach. Konfiguration Der wichtigste Punkt ist hier die Entscheidung darüber, welche Benutzer auf Ihren FTP-Server zugreifen dürfen. Ein &os;-System verfügt über diverse Systembenutzerkonten, um einzelnen Daemonen den Zugriff auf das System zu ermöglichen. Anonyme Benutzer sollten sich allerdings nicht über diese Benutzerkonten anmelden dürfen. Die Datei /etc/ftpusers enthält alle Benutzer, die vom FTP-Zugriff ausgeschlossen sind. In der Voreinstellung gilt dies auch die gerade erwähnten Systembenutzerkonten. Sie können über diese Datei weitere Benutzer vom FTP-Zugriff ausschließen. In einigen Fällen kann es wünschenswert sein, den Zugang für manche Benutzer einzuschränken, ohne dabei FTP komplett zu verbieten. Dazu passen Sie /etc/ftpchroot entsprechend an. Diese Datei enthält Benutzer und Gruppen sowie die für sie geltenden FTP-Einschränkungen und wird in &man.ftpchroot.5; ausführlich beschrieben. FTP anonymous Um anonymen FTP-Zugriff auf dem Server zu aktivieren, muss ein Benutzer ftp auf dem &os;-System angelegt werden. Danach können sich Benutzer mit dem Benutzernamen ftp oder anonymous am FTP-Server anmelden. Das Passwort ist dabei beliebig (allerdings wird dazu in der Regel eine E-Mail-Adresse verwendet). Meldet sich ein anonymer Benutzer an, aktiviert der FTP-Server &man.chroot.2;, um den Zugriff auf das Heimatverzeichnis des Benutzers ftp zu beschränken. Es gibt zwei Textdateien, deren Inhalt Sie bei der Anmeldung an Ihrem FTP-Server anzeigen lassen können. Der Inhalt von /etc/ftpwelcome wird angezeigt, bevor der Login-Prompt erscheint. Nach einer erfolgreichen Anmeldung wird der Inhalt von /etc/ftpmotd angezeigt. Beachten Sie aber, dass es dabei um einen Pfad relativ zur Umgebung des anzumeldenden Benutzers handelt. Bei einer anonymen Anmeldung würde also die Datei ~ftp/etc/ftpmotd angezeigt. Nachdem Sie den FTP-Server konfiguriert haben, müssen Sie Ihn in /etc/inetd.conf aktivieren. Dazu müssen Sie lediglich das Kommentarsymbol # am Beginn der bereits vorhandenen ftpd-Zeile entfernen: ftp stream tcp nowait root /usr/libexec/ftpd ftpd -l Nachdem Sie diese Änderung durchgeführt haben, müssen Sie, wie in beschrieben, die inetd-Konfiguration neu einlesen. Lesen Sie bitte Abschnitt des Handbuchs für weitere Informationen zur Aktivierung von inetd auf dem System. Alternativ können Sie auch nur den ftpd-Server starten. In diesem Fall ist es ausreichend, die entsprechende Variable in der Datei /etc/rc.conf zu setzen: ftpd_enable="YES" Nachdem Sie diese Variable gesetzt haben, wird künftig beim Systemstart nur der FTP-Server gestartet. Alternativ können Sie den Server auch manuell starten, indem Sie als Benutzer root den folgenden Befehl ausführen: &prompt.root; service ftpd start Danach können Sie sich am FTP-Server anmelden: &prompt.user; ftp localhost Wartung syslog Logdateien FTP Der ftpd-Daemon verwendet &man.syslog.3;, um Protokolldateien zu erstellen. In der Voreinstellung werden alle FTP betreffenden Nachrichten in die Datei /var/log/xferlog geschrieben. Dies lässt sich aber durch das Einfügen der folgenden Zeile in /etc/syslog.conf ändern: ftp.info /var/log/xferlog FTP anonymous Beachten Sie, dass mit dem Betrieb eines anonymen FTP-Servers verschiedene Sicherheitsrisiken verbunden sind. Problematisch ist hier vor allem die Erlaubnis zum anonymen Upload von Dateien. Dadurch könnte der Server zur Verbreitung von illegaler oder nicht lizensierter Software oder noch Schlimmeren missbraucht werden. Wenn anonyme FTP-Uploads dennoch erforderlich sind, sollten Sie die Zugriffsrechte so setzen, dass solche Dateien erst nach Zustimmung eines Administrators von anderen Benutzern heruntergeladen werden können. Datei- und Druckserver für µsoft.windows;-Clients (Samba) Samba-Server Microsoft Windows Dateiserver Windows-Clients Druckserver Windows-Clients Samba ist ein beliebtes Open Source-Softwarepaket, das es Ihnen ermöglicht, einen Datei- und Druckserver für µsoft.windows;-Clients einzurichten. Clients können sich dadurch mit einem &os;-System verbinden und dessen Speicherplatz oder dessen Drucker verwenden. Dies genauso, als wenn es sich um lokale Drucker oder Festplatten handeln würde. Samba sollte als Softwarepaket auf den &os;-Installationsmedien vorhanden sein. Wenn Samba noch nicht installiert ist, können Sie dies über den Port oder das Paket net/samba34 nachholen. Konfiguration Die Standardkonfigurationsdatei von Samba heißt /usr/local/share/examples/samba34/smb.conf.default. Diese Datei muss nach /usr/local/etc/smb.conf kopiert und angepasst werden, bevor Samba verwendet werden kann. Die Datei smb.conf enthält Laufzeitinformationen für Samba, beispielsweise Druckerdefinitionen oder file system shares, also Bereiche des Dateisystems, die mit &windows;-Clients geteilt werden sollen. Die Konfiguration der Datei smb.conf erfolgt webbasiert über das im Samba-Paket enthaltene Programm swat. Das Samba Web Administration Tool (SWAT) verwenden Das Samba Web Administration Tool (SWAT) wird als Daemon von inetd aktiviert. Daher müssen Sie inetd, wie in beschrieben, aktivieren und die folgende Zeile in /etc/inetd.conf entfernen, bevor Sie swat zur Konfiguration von Samba verwenden können: swat stream tcp nowait/400 root /usr/local/sbin/swat swat Wie bereits in beschrieben, müssen Sie die inetd-Konfiguration neu einlesen, nachdem Sie diese Änderung durchgeführt haben. Nachdem swat in der Datei inetd.conf aktiviert wurde, rufen Sie im Internetbrowser die Adresse http://localhost:901 auf. Bei der ersten Anmeldung muss das root-Benutzerkonto verwendet werden. Nachdem erfolgreicher Anmeldung an der Hauptkonfigurationseite von Samba steht die Systemdokumentation zur Verfügung, und durch einen Klick auf die Globals-Karteikarte kann mit der Konfiguration begonnen werden. Die Einstellungen, die Sie hier vornehmen können, entsprechen denen des Abschnitts [global] von /usr/local/etc/smb.conf. Globale Einstellungen Unabhängig davon, ob swat verwendet, oder /usr/local/etc/smb.conf direkt editiert wird, sollten zuerst folgende Richtlinien angepasst werden: workgroup Der NT-Domänenname oder der Arbeitsgruppenname der Rechner, die auf den Server Zugriff haben sollen. netbios name NetBIOS Legt den NetBIOS-Namen fest, unter dem der Samba-Server bekannt ist. In der Regel handelt es sich dabei um den ersten - Teil des DNS-Namens des Servers. + Teil des DNS-Namens des + Servers. server string Legt die Beschreibung fest, die angezeigt werden soll, wenn mit net view oder über andere Netzwerkprogramme Informationen über den Server angefordert werden. Samba absichern Zwei der wichtigsten Einstellungen in /usr/local/etc/smb.conf betreffen das zu verwendende Sicherheitsmodell sowie das Backend-Passwortformat für die Benutzer der Samba-Clients. Folgende Optionen sind dafür verantwortlich: security Die häufigsten Optionen sind security = share und security = user. Wenn die Clients Benutzernamen verwenden, die den Benutzernamen auf dem &os;-Rechner entsprechen, dann sollten Sie die Einstellung user level verwenden. Dies ist die Standardeinstellung. Allerdings ist es dazu erforderlich, dass sich die Clients auf dem Rechner anmelden, bevor sie auf gemeinsame Ressourcen zugreifen können. In der Einstellung share level müssen sich Clients nicht unter Verwendung eines gültigen Logins auf dem Rechner anmelden, bevor sie auf gemeinsame Ressourcen zugreifen können. In früheren Samba-Versionen war dies die Standardeinstellung. passdb backend NIS+ LDAP SQL database Samba erlaubt verschiedene Backend-Authentifizierungsmodelle. Clients können sich durch LDAP, NIS+, eine SQL-Datenbank oder eine Passwortdatei authentifizieren. In der Voreinstellung wird smbpasswd verwendet. Diese Methode wird im folgenden Abschnitt näher beschrieben. Wenn Sie smbpasswd verwenden, müssen Sie die Datei /usr/local/etc/samba/smbpasswd erzeugen, damit Samba in der Lage ist, Clients zu authentifizieren. Um den Zugriff auf &unix;-Benutzerkonten von einem &windows;-Client aus zu ermöglichen, verwenden Sie den folgenden Befehl: &prompt.root; smbpasswd -a username Als Backend wird inzwischen tdbsam empfohlen. Mit dem folgenden Befehl legen Sie neue Benutzerkonten an: &prompt.root; pdbedit -a -u username Ausführliche Informationen zur Konfiguration von Samba finden Sie im Official Samba HOWTO. Mit den hier skizzierten Grundlagen, sollten Sie in der Lage sein, Samba zu starten. Zusätzlich zu den Informationen hier, sollte weitere Dokumentation hinzugezogen werden. <application>Samba</application> starten Der Port net/samba34 legt ein neues Startskript an, mit dem Samba gesteuert (also etwa gestartet oder beendet) werden kann. Um dieses Skript zu aktivieren, fügen Sie folgende Zeile in /etc/rc.conf ein: samba_enable="YES" Alternativ können Sie auch die folgenden beiden Einträge verwenden: nmbd_enable="YES" smbd_enable="YES" Durch diese Einträge wird Samba beim Systemstart automatisch aktiviert. Danach können Sie Samba jederzeit durch folgenden Befehl starten: &prompt.root; service samba start Starting SAMBA: removing stale tdbs : Starting nmbd. Starting smbd. Weitere Informationen zu den rc-Startskripten finden Sie im des Handbuchs. Samba verwendet drei Daemonen. Beachten Sie, dass sowohl nmbd als auch smbd durch das Skript samba gestartet werden. Wurde winbind name resolution services in smb.conf aktiviert, wird zusätzlich der winbindd-Daemon gestartet. Samba kann jederzeit durch folgenden Befehl beendet werden: &prompt.root; service samba stop Samba ist ein komplexes Softwarepaket mit umfassenden Funktionen, die eine weitreichende Integration von µsoft.windows;-Netzwerken ermöglichen. Für eine Beschreibung dieser Zusatzfunktionen sollten Sie sich auf http://www.samba.org umsehen. Die Uhrzeit mit NTP synchronisieren NTP Da die interne Uhrzeit eines Computers nie ganz exakt ist, wurde mit dem Network Time Protocol (NTP) eine Möglichkeit geschaffen, die exakte Uhrzeit zu ermitteln und festzulegen. Viele Internetdienste sind von einer exakten Uhrzeit abhängig. Ein Webserver könnte beispielsweise die Anforderung erhalten, eine Datei zu versenden, wenn sich diese in einer bestimmten Zeitspanne geändert hat. In einem lokalen Netzwerk ist es unbedingt notwendig, dass Rechner, die Dateien von einem gemeinsamen Dateiserver beziehen, ihre Uhrzeit synchronisieren, damit die Zeitstempel der Dateien konstistent bleiben. Dienste wie &man.cron.8; führen Befehle zu einem bestimmten Zeitpunkt aus. Ist die Uhrzeit nicht korrekt, kann dies zu Problemen führen. NTP ntpd &os; verwendet den &man.ntpd.8;- NTP-Server, um die genaue Uhrzeit von anderen NTP-Servern abzufragen, die eigene Systemzeit zu setzen, oder um diese anderen Rechnern anzubieten. Einen passenden NTP-Server auswählen NTP Serverwahl Um die Uhrzeit zu synchronisieren, müssen ein oder mehrere NTP-Server definiert werden. Der Netzwerkadministrator oder Internetprovider hat vielleicht schon einen NTP-Server eingerichtet. Lesen Sie deren Dokumentation, um dies zu überprüfen. Es gibt im Internet eine Liste mit frei zugänglichen NTP-Servern, aus der man einen in der Nähe gelegenen Server auswählen kann. Beachten Sie aber auf jeden Fall die Nutzungsbedingungen des entsprechenden Servers, und fragen Sie um Erlaubnis, wenn dies nötig ist. Die Auswahl von mehreren NTP-Servern kann sinnvoll sein, wenn ein Server ausfällt oder falsche Zeiten liefert. &man.ntpd.8; verwendet die Antworten anderer Server, um zuverlässige Server zu bestimmen, die dann bevorzugt abgefragt werden. NTP unter &os; einrichten NTP Konfiguration NTP aktivieren ntpdate Wenn Sie die Uhrzeit nur beim Systemstart synchronisieren wollen, benutzen Sie &man.ntpdate.8;. Für Desktoprechner, die regelmäßig neu gestartet werden und keine ständige Synchronisation benötigen, ist dies akzeptabel. In allen anderen Fällen sollten Sie jedoch &man.ntpd.8; verwenden. Die Ausführung von &man.ntpdate.8; während des Systemstarts ist aber auch für Rechner, die &man.ntpd.8; verwenden, sinnvoll. &man.ntpd.8; passt die Systemzeit nur bei größeren Abweichungen an, während &man.ntpdate.8; die Zeit immer synchronisiert, egal wie groß die Differenz zwischen Systemzeit und korrekter Zeit ist. Um &man.ntpdate.8; beim Systemstart zu aktivieren, fügen Sie den Eintrag ntpdate_enable="YES" in /etc/rc.conf ein. Außerdem müssen alle Server, mit denen Sie sich synchronisieren wollen, sowie alle an &man.ntpdate.8; zu übergebenden Optionen in ntpdate_flags angeben werden. NTP einrichten NTP ntp.conf Die Konfiguration von NTP erfolgt über die Datei /etc/ntp.conf, und wird in der Hilfeseite &man.ntp.conf.5; beschrieben. Dazu ein einfaches Beispiel: server ntplocal.example.com prefer server timeserver.example.org server ntp2a.example.net driftfile /var/db/ntp.drift Die Option server legt die zu verwendenden Server fest, wobei jeder Server in einer eigenen Zeile steht. Wenn ein Server mit der Option prefer versehen ist, wie dies hier bei ntplocal.example.com der Fall ist, wird dieser Server bevorzugt verwendet. Eine Antwort von einem bevorzugten Server wird nur dann verworfen, wenn sie signifikant von denen anderer Server abweicht, ansonsten wird sie ohne Abfrage weiterer Server verwendet. Die Option prefer wird gewöhnlich nur für sehr zuverlässige und genaue Server verwendet, die über eine spezielle Hardware zur Zeitüberwachung verfügen. Die Option driftfile legt fest, in welcher Datei die Abweichungen der Systemuhr protokolliert werden. &man.ntpd.8; verwendet diese Datei, um die Systemzeit automatisch anzupassen, selbst wenn kurzzeitig kein NTP-Server zur Synchronisation verfügbar ist. Weiterhin legt die Option driftfile fest, wo Informationen über frühere Antworten des verwendeten NTP-Servers gespeichert werden sollen. Diese Datei enthält NTP-interne Informationen, sie sollte daher von anderen Prozessen nicht verändert werden. Den Zugang zu Ihrem NTP-Server beschränken In der Voreinstellung ist der NTP-Server für alle Rechner im Internet erreichbar. Die Option restrict in /etc/ntp.conf steuert, welche Rechner auf den Server zugreifen können. Wenn Sie alle Rechner vom Zugriff auf den NTP-Server ausschließen wollen, fügen Sie folgende Zeile in /etc/ntp.conf ein: restrict default ignore Dieser Eintrag verhindert auch den Zugriff des Servers auf alle angegebenen Server in der lokalen Konfiguration. Besteht die Notwendigkeit, den NTP-Server mit einem externen NTP-Server zu synchronisieren, muss dieser Server dezidiert zugelassen werden. Weitere Informationen finden Sie in &man.ntp.conf.5;. Wenn Sie nur Rechnern innerhalb des Netzwerks die Synchronisation mit dem NTP-Server erlauben, gleichzeitig aber verhindern wollen, dass diese den NTP-Server konfigurieren oder als Server für andere Rechner dienen können, fügen Sie folgende Zeile ein: restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap Bei 192.168.1.0 handelt es sich um einen Rechner innerhalb des Netzwerks. 255.255.255.0 ist die Netzmaske des Netzwerks. /etc/ntp.conf kann verschiedene restrict-Optionen enthalten. Weitere Details finden Sie im Abschnitt Access Control Support von &man.ntp.conf.5;. Den NTP-Server starten Damit der NTP-Server beim Systemstart automatisch gestartet wird, fügen Sie den Eintrag ntpd_enable="YES" in /etc/rc.conf ein. Um weitere Argumente an &man.ntpd.8; zu übergeben , passen Sie die Option ntpd_flags in der Datei /etc/rc.conf entsprechend an. Um den NTP-Server ohne einen Systemneustart zu starten, rufen Sie ntpd mit den unter ntpd_flags in /etc/rc.conf festgelegten Parametern auf. Hierzu ein Beispiel: &prompt.root; ntpd -p /var/run/ntpd.pid <application>ntpd</application> mit einer Einwahlverbindung verwenden &man.ntpd.8; benötigt keine ständige Internetverbindung. Wenn Sie sich ins Internet einwählen, ist es sinnvoll, zu verhindern, dass NTP-Verkehr eine Verbindung aufbauen oder aufrechterhalten kann. Benutzer von PPP können dies in den filter-Direktiven von /etc/ppp/ppp.conf festlegen. Ein Beispiel: set filter dial 0 deny udp src eq 123 # Prevent NTP traffic from initiating dial out set filter dial 1 permit 0 0 set filter alive 0 deny udp src eq 123 # Prevent incoming NTP traffic from keeping the connection open set filter alive 1 deny udp dst eq 123 # Prevent outgoing NTP traffic from keeping the connection open set filter alive 2 permit 0/0 0/0 Weitere Informationen finden Sie im Abschnitt PACKET FILTERING von &man.ppp.8; sowie in den Beispielen unter /usr/share/examples/ppp/. Einige Internetprovider blockieren Ports mit niedrigen Nummern. In solchen Fällen funktioniert NTP leider nicht, da Antworten eines NTP-Servers den Rechner nicht erreichen werden. Weitere Informationen Weiterführende Dokumentation (im HTML-Format) zum NTP-Server finden Sie unter /usr/share/doc/ntp/. Protokollierung von anderen Hosts mit <command>syslogd</command> Die Interaktion mit Systemprotokollen ist ein wichtiger Aspekt, sowohl was Sicherheit als auch Systemadministration anbelangt. Überwachen der Protokolldateien von mehreren Hosts kann sehr unhandlich werden, wenn diese Hosts über mittlere oder grosse Netze verteilt sind oder wenn sie Teile von unterschiedlichen Netzwerken sind. In diesen Fällen macht die Konfiguration der Protokollierung von anderen Hosts diesen Prozess wesentlich komfortabler. Die zentralisierte Protokollierung auf einen bestimmten Protokollierungshost kann manche der administrativen Belastungen der Protokolldateiadministration reduzieren. Protokolldateiaggregation, -zusammenführung und -rotation kann an einer zentralen Stelle mit den &os;-eigenen Werkzeugen wie &man.syslogd.8; und &man.newsyslog.8; konfiguriert werden. In der folgenden Beispielkonfiguration sammelt Host A, genannt logserv.example.com, Protokollinformationen für das lokale Netzwerk. Host B, genannt logclient.example.com wird seine Protokollinformationen an den Server weiterleiten. In realen Konfigurationen benötigen beide Hosts passende Vorwärts- und Umkehr-Einträge im DNS oder in /etc/hosts. Andernfalls werden die Daten vom Server abgelehnt. Konfiguration des Protokollierungs-Servers Protokollierungs-Server sind Maschinen, die konfiguriert sind, Protokollinformationen von anderen Hosts zu akzeptieren. In den meisten Fällen wird dies zur Vereinfachung der Konfiguration eingesetzt, in anderen Fällen ist es einfach nur ein Schritt in eine bessere Verwaltung. Was auch immer die Gründe sind, ein paar Anforderungen müssen vorher erfüllt sein. Ein richtig konfigurierter Protokollierungs-Server muss minimal die folgenden Anforderungen erfüllen: Das Regelwerk der Firewall muss UDP auf Port 514 sowohl auf Client- als auch auf Serverseite erlauben; syslogd wurde so konfiguriert, dass es Nachrichten von anderen Clientrechnern akzeptiert; Der syslogd-Server und alle Clientrechner müssen gültige Einträge für sowohl Vorwärts- als auch Umkehr-DNS besitzen, oder in /etc/hosts korrekt eingetragen sein. Um den Protokollierungs-Server zu konfigurieren, muss der Client in /etc/syslog.conf eingetragen sein und der Verbindungsweg der Protokollierung muss spezifiziert sein: +logclient.example.com *.* /var/log/logclient.log Weitere Informationen zu den verschiedenen unterstützten und verfügbaren Verbindungswegen finden Sie in &man.syslog.conf.5;. Einmal hinzugefügt, werden alle Nachrichten über den Verbindungsweg in die zuvor angegebene Datei, /var/log/logclient.log protokolliert. Der Server benötigt ausserdem die folgenden Zeilen in der /etc/rc.conf: syslogd_enable="YES" syslogd_flags="-a logclient.example.com -v -v" Die erste Option aktiviert den syslogd-Dienst während des Systemstarts und die zweite Option erlaubt es, Daten von dem spezifizierten Client auf diesem Server zu akzeptieren. Die Verwendung von im letzten Teil erhöht die Anzahl von Protokollnachrichten. Dies ist sehr hilfreich für die Feineinstellung der Verbindungspfade, da Administratoren auf diese Weise erkennen, welche Arten von Nachrichten unter welchen Einstellungen protokolliert werden. Mehrere -Optionen können angegeben werden, um die Protokollierung von mehreren Clients zu erlauben. IP-Adressen und ganze Netzblöcke können ebenfalls spezifiziert werden. Eine vollständige Liste der Optionen finden Sie in &man.syslog.3;. Zum Schluss muss noch die Protokolldatei erstellt werden. Auf welche Weise dies geschieht ist nicht wichtig, aber in den meisten Fällen funktioniert &man.touch.1; grossartig, wie hier dargestellt: &prompt.root; touch /var/log/logclient.log Zu diesem Zeitpunkt sollte der syslogd-Dienst neu gestartet und überprüft werden: &prompt.root; service syslogd restart &prompt.root; pgrep syslog Wenn eine PID zurückgegeben wird, wurde der Server erfolgreich neu gestartet und die Clientkonfiguration kann beginnen. Wenn der Server nicht neu gestartet wurde, suchen Sie im /var/log/messages-Protokoll nach eventuellen Fehlermeldungen. Konfiguration des Protokollierungs-Clients Ein Protokollierungs-Client ist eine Maschine, die Protokollinformationen an einen Protokollierungs-Server sendet, zusätzlich zu ihren lokalen Kopien. Ähnlich wie Protokollierungs-Server müssen Clients auch ein paar minimale Anforderungen erfüllen: &man.syslogd.8; muss so konfiguriert sein, dass es Nachrichten eines bestimmten Typs an einen Protokollierungs-Server schickt, welcher diese akzeptieren muss; Die Firewall muss UDP-Pakete durch Port 514 erlauben; Sowohl Vorwärts- als auch Umkehr-DNS muss konfiguriert sein oder es müssen passende Einträge in /etc/hosts vorhanden sein. Die Clientkonfiguration ist ein bisschen entspannter, verglichen mit der des Servers. Der Clientrechner muss ebenfalls die folgenden Einträge in der /etc/rc.conf besitzen: syslogd_enable="YES" syslogd_flags="-s -v -v" Wie zuvor aktivieren diese Einträge den syslogd-Dienst während des Systemstarts und erhöhen die Anzahl der Protokollnachrichten. Die Option verhindert, dass dieser Client Protokolle von anderen Hosts akzeptiert. Verbindungspfade beschreiben den Systemteil, für den eine Nachricht generiert wird. Beispielsweise sind ftp und ipfw beides Verbindungspfade. Wenn Protokollnachrichten für diese beiden Dienste generiert werden, sind diese beiden Werkzeuge normalerweise in jeder Protokollnachricht enthalten. Verbindungspfade sind mit einer Priorität oder Stufe verbunden, die dazu verwendet wird, zu markieren, wie wichtig eine Nachricht im Protokoll ist. Die Häftigste ist warning und info. Eine vollständig Liste der verfügbaren Verbindungspfade und Prioritäten finden Sie in &man.syslog.3;. Der Protokollierungs-Server muss in der /etc/syslog.conf des Clients eingetragen sein. In diesem Beispiel wird das @-Symbol benutzt, um Protokolldaten an einen anderen Server zu senden. Der Eintrag sieht wie folgt aus: *.* @logserv.example.com Einmal hinzugefügt, muss syslogd neu gestartet werden, damit diese Änderungen wirksam werden: &prompt.root; service syslogd restart Um zu testen, ob Protokollnachrichten über das Netzwerk gesendet werden, kann &man.logger.1; auf dem Client benutzt werden, um eine Nachricht an syslogd zu schicken: &prompt.root; logger "Test message from logclient" Diese Nachricht sollte jetzt sowohl in /var/log/messages auf dem Client, als auch in /var/log/logclient.log auf dem Server vorhanden sein. Fehlerbehebung beim Protokollierungs-Server In bestimmten Fällen ist die Fehlerbehebung notwendig, wenn Nachrichten nicht auf dem Protokollierungs-Server empfangen werden. Es gibt mehrere Gründe dafür, jedoch treten am häufigsten Probleme bei der Netzwerkverbindung und beim DNS auf. Um diese Fälle zu überprüfen, stellen Sie sicher, dass beide Hosts in der Lage sind, sich gegenseitig über den Hostnamen zu erreichen, der in /etc/rc.conf angegeben ist. Wenn das funktioniert, ist möglicherweise eine Änderung der syslogd_flags-Option in /etc/rc.conf notwendig. Im folgenden Beispiel ist /var/log/logclient.log leer und die /var/log/messages-Dateien enthalten keine Gründe für den Fehler. Um die Fehlerausgabe zu erhöhen, ändern Sie die syslogd_flags-Option so, dass diese wie in dem folgenden Beispiel aussieht und initiieren Sie dann einen Neustart: syslogd_flags="-d -a logclien.example.com -v -v" &prompt.root; service syslogd restart Fehlerausgabedaten ähnlich der Folgenden werden sofort nach dem Neustart auf dem Bildschirm erscheinen: logmsg: pri 56, flags 4, from logserv.example.com, msg syslogd: restart syslogd: restarted logmsg: pri 6, flags 4, from logserv.example.com, msg syslogd: kernel boot file is /boot/kernel/kernel Logging to FILE /var/log/messages syslogd: kernel boot file is /boot/kernel/kernel cvthname(192.168.1.10) validate: dgram from IP 192.168.1.10, port 514, name logclient.example.com; rejected in rule 0 due to name mismatch. Es scheint klar zu sein, dass die Nachrichten aufgrund eines fehlerhaften Namens abgewiesen werden. Nach genauer Untersuchung der Konfiguration, kommt ein Tippfehler in der folgenden Zeile der /etc/rc.conf als Fehler in Betracht: syslogd_flags="-d -a logclien.example.com -v -v" Die Zeile sollte logclient und nicht logclien enthalten. Nachdem die entsprechenden Veränderungen gemacht wurden, ist ein Neustart fällig, mit den entsprechenden Ergebnissen: &prompt.root; service syslogd restart logmsg: pri 56, flags 4, from logserv.example.com, msg syslogd: restart syslogd: restarted logmsg: pri 6, flags 4, from logserv.example.com, msg syslogd: kernel boot file is /boot/kernel/kernel syslogd: kernel boot file is /boot/kernel/kernel logmsg: pri 166, flags 17, from logserv.example.com, msg Dec 10 20:55:02 <syslog.err> logserv.example.com syslogd: exiting on signal 2 cvthname(192.168.1.10) validate: dgram from IP 192.168.1.10, port 514, name logclient.example.com; accepted in rule 0. logmsg: pri 15, flags 0, from logclient.example.com, msg Dec 11 02:01:28 trhodes: Test message 2 Logging to FILE /var/log/logclient.log Logging to FILE /var/log/messages Zu diesem Zeitpunkt werden die Nachrichten korrekt empfangen und in die richtige Datei geschrieben. Sicherheitsbedenken Wie mit jedem Netzwerkdienst, müssen Sicherheitsanforderungen in Betracht gezogen werden, bevor diese Konfiguration umgesetzt wird. Manchmal enthalten Protokolldateien sensitive Daten über aktivierte Dienste auf dem lokalen Rechner, Benutzerkonten und Konfigurationsdaten. Daten, die vom Client an den Server geschickt werden, sind weder verschlüsselt noch mit einem Passwort geschützt. Wenn ein Bedarf für Verschlüsselung besteht, ist es möglich, security/stunnel zu verwenden, welches die Daten über einen verschlüsselten Tunnel versendet. Lokale Sicherheit ist ebenfalls ein Thema. Protokolldateien sind während der Verwendung oder nach ihrer Rotation nicht verschlüsselt. Lokale Benutzer versuchen vielleicht, auf diese Dateien zuzugreifen, um zusätzliche Einsichten in die Systemkonfiguration zu erlangen. In diesen Fällen ist es absolut notwendig, die richtigen Berechtigungen auf diesen Dateien zu setzen. Das &man.newsyslog.8;-Werkzeug unterstützt das Setzen von Berechtigungen auf gerade erstellte oder rotierte Protokolldateien. Protokolldateien mit Zugriffsmodus 600 sollten verhindern, dass lokale Benutzer darin herumschnüffeln. iSCSI Initiator und Target Konfiguration iSCSI bietet die Möglichkeit, Speicherkapazitäten über ein Netzwerk zu teilen. Im Gegensatz zu NFS, das auf Dateisystemebene arbeitet, funktioniert iSCSI auf Blockgerätebene. In der iSCSI-Terminologie wird das System, das den Speicherplatz zur Verfügung stellt, als Target bezeichnet. Der Speicherplatz selbst kann aus einer physischen Festplatte bestehen, oder auch aus einem Bereich, der mehrere Festplatten, oder nur Teile einer Festplatte, repräsentiert. Wenn beispielsweise die Festplatte(n) mit ZFS formatiert ist, kann ein zvol erstellt werden, welches dann als iSCSI-Speicher verwendet werden kann. Die Clients, die auf den iSCSI-Speicher zugreifen, werden Initiator genannt. Ihnen steht der verfügbare Speicher als rohe, nicht formatierte Festplatte, die auch als LUN bezeichnet wird, zur Verfügung. Die Gerätedateien für die Festplatten erscheinen in /dev/ und müssen separat formatiert und eingehangen werden. Seit 10.0-RELEASE enthält &os; einen nativen, kernelbasierten iSCSI Target und Initiator. Dieser Abschnitt beschreibt, wie ein &os;-System als Target oder Initiator konfiguriert wird. Ein <acronym>iSCSI</acronym>-Target konfigurieren Ein natives iSCSI-Target wird seit &os; 10.0-RELEASE unterstützt. Um iSCSI mit älteren Versionen zu benutzen, installieren Sie ein Target aus der Ports-Sammlung, beispielsweise net/istgt. Dieses Kapitel beschreibt nur das native Target. Um ein iSCSI-Target zu konfigurieren, erstellen Sie die Konfigurationsdatei /etc/ctl.conf und fügen Sie eine Zeile in /etc/rc.conf hinzu, um sicherzustellen, dass &man.ctld.8; automatisch beim Booten gestartet wird. Starten Sie dann den Daemon. Das folgende Beispiel zeigt eine einfache /etc/ctl.conf. Eine vollständige Beschreibung dieser Datei und der verfügbaren Optionen finden Sie in &man.ctl.conf.5;. portal-group pg0 { discovery-auth-group no-authentication listen 0.0.0.0 listen [::] } target iqn.2012-06.com.example:target0 { auth-group no-authentication portal-group pg0 lun 0 { path /data/target0-0 size 4G } } Der erste Eintrag definiert die Portalgruppe pg0. Portalgruppen legen fest, auf welchen Netzwerk-Adressen der &man.ctld.8;-Daemon Verbindungen entgegennehmen wird. Der Eintrag discovery-auth-group no-authentication zeigt an, dass jeder Initiator iSCSI-Targets suchen darf, ohne sich authentifizieren zu müssen. Die dritte und vierte Zeilen konfigurieren &man.ctld.8; so, dass er auf allen IPv4- (listen 0.0.0.0) und IPv6-Adressen (listen [::]) auf dem Standard-Port 3260 lauscht. Es ist nicht zwingend notwendig eine Portalgruppe zu definieren, da es bereits eine integrierte Portalgruppe namens default gibt. In diesem Fall ist der Unterschied zwischen default und pg0 der, dass bei default eine Authentifizierung nötig ist, während bei pg0 die Suche nach Targets immer erlaubt ist. Der zweite Eintrag definiert ein einzelnes Target. Ein Target hat zwei mögliche Bedeutungen: eine Maschine die iSCSI bereitstellt, oder eine Gruppe von LUNs. Dieses Beispiel verwendet die letztere Bedeutung, wobei iqn.2012-06.com.example:target0 der Name des Targets ist. Dieser Name ist nur für Testzwecke geeignet. Für den tatsächlichen Gebrauch ändern Sie com.example auf einen echten, rückwärts geschriebenen Domainnamen. 2012-06 steht für das Jahr und den Monat, an dem die Domain erworben wurde. target0 darf einen beliebigen Wert haben und in der Konfigurationsdatei darf eine beliebige Anzahl von Targets definiert werden. Der Eintrag auth-group no-authentication erlaubt es allen Initiatoren sich mit dem angegebenen Target zu verbinden und portal-group pg0 macht das Target über die Portalgruppe pg0 erreichbar. Die nächste Sektion definiert die LUN. Jede LUN wird dem Initiator als separate Platte präsentiert. Für jedes Target können mehrere LUNs definiert werden. Jede LUN wird über eine Nummer identifiziert, wobei LUN 0 verpflichtend ist. Die Zeile mit dem Pfad path /data/target0-0 definiert den absoluten Pfad zu der Datei oder des zvols für die LUN. Der Pfad muss vorhanden sein, bevor &man.ctld.8; gestartet wird. Die zweite Zeile ist optional und gibt die Größe der LUN an. Als nächstes fügen Sie folgende Zeile in /etc/rc.conf ein, um &man.ctld.8; automatisch beim Booten zu starten: ctld_enable="YES" Um &man.ctld.8; jetzt zu starten, geben Sie dieses Kommando ein: &prompt.root; service ctld start Der &man.ctld.8;-Daemon liest beim Start /etc/ctl.conf. Wenn diese Datei nach dem Starten des Daemons bearbeitet wird, verwenden Sie folgenden Befehl, damit die Änderungen sofort wirksam werden: &prompt.root; service ctld reload Authentifizierung Die vorherigen Beispiele sind grundsätzlich unsicher, da keine Authentifizierung verwendet wird und jedermann vollen Zugriff auf alle Targets hat. Um für den Zugriff auf die Targets einen Benutzernamen und ein Passwort vorauszusetzen, ändern Sie die Konfigurationsdatei wie folgt: auth-group ag0 { chap username1 secretsecret chap username2 anothersecret } portal-group pg0 { discovery-auth-group no-authentication listen 0.0.0.0 listen [::] } target iqn.2012-06.com.example:target0 { auth-group ag0 portal-group pg0 lun 0 { path /data/target0-0 size 4G } } Die Sektion auth-group definiert die Benutzernamen und Passwörter. Um sich mit iqn.2012-06.com.example:target0 zu verbinden, muss ein Initiator zuerst einen Benutzernamen und ein Passwort angeben. Eine Suche nach Targets wird jedoch immer noch ohne Authentifizierung gestattet. Um eine Authentifizierung zu erfordern, setzen Sie discovery-auth-group auf eine definierte auth-group anstelle von no-autentication. In der Regel wird für jeden Initiator ein einzelnes Target exportiert. In diesem Beispiel wird der Benutzername und das Passwort direkt im Target-Eintrag festgelegt: target iqn.2012-06.com.example:target0 { portal-group pg0 chap username1 secretsecret lun 0 { path /data/target0-0 size 4G } } Einen <acronym>iSCSI</acronym>-Initiator konfigurieren Der in dieser Sektion beschriebene iSCSI-Initiator wird seit &os; 10.0-RELEASE unterstützt. Lesen Sie &man.iscontrol.8;, wenn Sie den iSCSI-Initiator mit älteren Versionen benutzen möchten. Um den Initiator zu verwenden, muss zunächst ein iSCSI-Daemon gestartet sein. Der Daemon des Initiators benötigt keine Konfigurationsdatei. Um den Daemon automatisch beim Booten zu starten, fügen Sie folgende Zeile in /etc/rc.conf ein: iscsid_enable="YES" Um &man.iscsid.8; jetzt zu starten, geben Sie dieses Kommando ein: &prompt.root; service iscsid start Die Verbindung mit einem Target kann mit, oder ohne eine Konfigurationsdatei /etc/iscsi.conf durchgeführt werden. Dieser Abschnitt beschreibt beide Möglichkeiten. Verbindung zu einem Target herstellen - ohne Konfigurationsdatei Um einen Initiator mit einem Target zu verbinden, geben Sie die IP-Adresse des Portals und den Namen des Ziels an: &prompt.root; iscsictl -A -p 10.10.10.10 -t iqn.2012-06.com.example:target0 Um zu überprüfen, ob die Verbindung gelungen ist, rufen Sie iscsictl ohne Argumente auf. Die Ausgabe sollte in etwa wie folgt aussehen: Target name Target portal State iqn.2012-06.com.example:target0 10.10.10.10 Connected: da0 In diesem Beispiel wurde die iSCSI-Sitzung mit der LUN /dev/da0 erfolgreich hergestellt. Wenn das Target iqn.2012-06.com.example:target0 mehr als nur eine LUN exportiert, werden mehrere Gerätedateien in der Ausgabe angezeigt: Connected: da0 da1 da2. Alle Fehler werden auf die Ausgabe und in die Systemprotokolle geschrieben. Diese Meldung deutet beispielsweise darauf hin, dass der &man.iscsid.8;-Daemon nicht ausgeführt wird: Target name Target portal State iqn.2012-06.com.example:target0 10.10.10.10 Waiting for iscsid(8) Die folgende Meldung deutet auf ein Netzwerkproblem hin, zum Beispiel eine falsche IP-Adresse oder einen falschen Port: Target name Target portal State iqn.2012-06.com.example:target0 10.10.10.11 Connection refused Diese Meldung bedeutet, dass der Name des Targets falsch angegeben wurde: Target name Target portal State iqn.2012-06.com.example:target0 10.10.10.10 Not found Diese Meldung bedeutet, dass das Target eine Authentifizierung erfordert: Target name Target portal State iqn.2012-06.com.example:target0 10.10.10.10 Authentication failed Verwenden Sie diese Syntax, um einen CHAP-Benutzernamen und ein Passwort anzugeben: &prompt.root; iscsictl -A -p 10.10.10.10 -t iqn.2012-06.com.example:target0 -u user -s secretsecret Verbindung mit einem Target herstellen - mit Konfigurationsdatei Wenn Sie für die Verbindung eine Konfigurationsdatei verwenden möchten, erstellen Sie /etc/iscsi.conf mit etwa folgendem Inhalt: t0 { TargetAddress = 10.10.10.10 TargetName = iqn.2012-06.com.example:target0 AuthMethod = CHAP chapIName = user chapSecret = secretsecret } t0 gibt den Namen der Sektion in der Konfigurationsdatei an. Diser Name wird vom Initiator benutzt, um zu bestimmen, welche Konfiguration verwendet werden soll. Die anderen Einträge legen die Parameter fest, die während der Verbindung verwendet werden. TargetAddress und TargetName müssen angegeben werden, die restlichen sind optional. In diesen Beispiel wird der CHAP-Benuztername und das Passwort angegeben. Um sich mit einem bestimmten Target zu verbinden, geben Sie dessen Namen an: &prompt.root; iscsictl -An t0 Um sich stattdessen mit allen definierten Targets aus der Konfigurationsdatei zu verbinden, verwenden Sie: &prompt.root; iscsictl -Aa Damit sich der Initiator automatisch mit allen Targets aus /etc/iscsi.conf verbindet, fügen Sie folgendes in /etc/rc.conf hinzu: iscsictl_enable="YES" iscsictl_flags="-Aa"