Yellow Pages 3: Die Server - Seite

ArticleCategory:

System Administration

AuthorImage:

TranslationInfo:

AboutTheAuthor:

Frédéric Raynal bereitet seine Abschlußarbeit auf der INRIA in Informatik vor. Momentan höre ich viel '16 HorsePower' von ihrer neuesten Platte (ziemlich sensibel, aber auch ziemlich kraftvoll), und 'the for carnation', etwas nüchtern aber trotzdem exzellent.

Abstract:

Dieser Artikel führt Schritt für Schritt die Installation eines NIS Servers aus. Wir werden uns die nötigen Programme, die Konfigurationsdateien und die Konstruktion der Datenbank ansehen.

ArticleIllustration:

ArticleBody:

Einführung

Im vorausgehenden Artikel haben wir gesehen, wie man einen NIS Klienten konfiguriert und wir haben die Sicherheitsprobleme dieses Dienstes hervorgehoben (wenn man dabei überhaupt von Problemen reden kann, insofern als die Entwickler von NIS dies nicht als ihre Aufgabe sahen).

Hier nun werden wir sehen, wie man den Server konfiguriert und wir werden einige Ratschläge zur Nutzung von NIS erteilen.

Vorwort

Bevor ich anfange, eine Präzisierung. Bis jetzt haben wir nur von "NIS" gesprochen. Jedoch gibt es davon zwei Varianten: das, was man das "traditionelle NIS" nennen könnte und NYS. Praktisch gibt es keine Unterschiede zwischen den Beiden (speziell bei der Konfiguration sowohl des Klienten als auch des Servers). Das "traditionelle NIS" gibt es schon länger, aber es unterstützt nicht alle Neuerungen, wie Shadowpasswörter, die von NYS transparent verwaltet werden.

Wir behandeln hier eine aktuelle Version von ypserv (d.h. eine Version die neuer ist als 1.3.2, um unter anderem die Verwaltung von Shadowpasswörtern zur Verfügung zu haben). Deshalb handelt es sich um einen NYS Server und kein "traditionelles NIS " ... wobei wir weiterhin "fälschlich" von NIS sprechen werden.

Der NIS Server

Es gibt zwei NIS Server : ypserv und yps. Gemäß dem Autor von NIS-HOWTO unterscheidet sich die Konfiguration nicht wesentlich. Aber yps wird von seinem Autor nicht mehr gepflegt und hat schwere Sicherheitslücken. Wir werden uns deshalb nur mit ypserv beschäftigen.

Zuerst zeigen wir die Schritte, die nötig sind, um einen Server zu installieren. Wir zeigen Schritt für Schritt, wie die einzelnen Konfigurationsdateien auf den Installationsprozess des Servers einwirken.

Im Artikel arbeiten wir auf der Maschine "charly". Die NIS Domäne trägt den Name "bosley". Die Slaveserver sind "sabrina", "jill" und "kelly".

Installation

Zu allererst muß man sicherstellen, daß der portmap Dämon läuft. Wenn dem nicht so ist, muß er gestartet werden.

Danach legt man den Namen der NIS-Domäne fest. Es handelt sich dabei nicht um einen Domänennamen im Sinne von DNS, sondern im Sinne von YPs. Dieser Name muß aus Sicherheitsgründen anders als der der Maschine sein.

Mit dem Kommando domainname kann man ... den Domänennamen festlegen :-) In unserem Fall benutzen wir es wie folgt:

root@charly >> /bin/domainname bosley

Dieses Kommando fixiert den NIS-Domänennamen im RAM-Speicher. Jedoch, wenn die Serverkonfiguration beendet ist, dann wünscht man sich doch, daß dies automatisch beim Starten der Maschine erledigt wird. Dafür muß man eine Zeile in der Netzwerkkonfiguration /etc/sysconfig/network ändern:

NISDOMAIN=bosley

Sobald das Netzwerk beim nächsten Reboot initialisiert wird, wird auch automatisch der NIS-Domänenname festgelegt.

Der folgende Abschnitt beschäftigt sich mit dem Starten des ypserv Dämons. Zuvor muß man ihn mittels der Datei /etc/ypserv.conf konfigurieren. Dies ist eine ASCII-Datei:

Kommentare: Die Zeilen, die mit dem #-Zeichen beginnen.
Optionen für den Dämon: Diese Zeile schreibt sich so:
option: [yes|no]
Mögliche Optionen sind dns (der Server fragt DNS, um die Klienten zu finden, die nicht in den hosts-Maps auftauchen), sunos_kludge (obsolet) und xfr_check_port (um den Server auf einen Port unter 1024 zu lenken - yes als Default)
Zugangsregeln zum NIS-Server. Das Format ist
host:map:security:mangle[:field]
Sie erlauben es festzulegen, wer was sehen darf.

Die Manpage von ypserv.conf führt sehr klar alle Optionen und Möglichkeiten für Regeln aus.

Jetzt kann man den Server starten:

root@charly >> /etc/rc.d/init.d/ypserv start

Wenn man den Server automatisch starten möchte, dann ändert man die Initialisierungsdateien entsprechend. Für RedHat sieht das wie folgt aus:

root@charly >> /sbin/chkconfig --levels 345 ypserv on

Um zu verifizieren, daß alles korrekt läuft:

root@charly >> /usr/sbin/rpcinfo -u localhost ypserv
program 100004 version 1 ready and waiting
program 100004 version 2 ready and waiting

Bevor wir uns auf die Grundlagen stürzen, kehren wir kurz zu dem zurück, was wir im ersten Artikel ausgeführt haben. Wir haben gesehen, daß es zwei Typen von Servern gibt: Master und Slaves. Der Master besitzt die NIS-Referenzdatenbank, wovon die Slaves nur eine Kopie haben. Sie dienen dazu, den Master von zu vielen Requests zu entlasten. Die Datenbank wird nur auf dem Server gepflegt. Erst danach wird sie auf die Slaveserver weiterkopiert.

Alles ist jetzt bereit ... bis auf die Datenbank. Man muß sie nur noch erstellen. Und wer erstellen meint, sagt Makefile ;-] Ich kann Sie beruhigen, sie ist bereits fertig geschrieben, es müßen lediglich ein paar Variablen angepasst werden. Sie befindet sich im Verzeichnis /var/yp. Sie ist ausführlich und klar kommentiert. Die wichtigste Zeile ist, wo die Maps, die von NIS benutzt werden sollen, definiert sind. Auf Charly sind dies:

all: passwd group hosts rpc services netid protocols mail shadow \
# netgrp publickey
# networks ethers bootparams printcap \
# amd.home auto.master auto.home passwd.adjunct

Zu dem, was per Default vorgegeben ist, sollte man auch die Verwaltung der Shadowpasswörter hinzufügen. Man muß dann aber auch den Wert der Variable MERGE_PASSWD von "true" auf "false" setzen. Sie legt nämlich fest, daß für die Konstruktion der NIS-Datenbank die Dateien /etc/passwd und /etc/shadow zu mischen sind.

Letztes Detail bevor wir die NIS-Datenbank erstellen, die Verwaltung der Zugriffsrechte. Es gibt zwei Methoden den Zugang zum Server zu verwalten: entweder macht er alles selbst, oder über tcp_wrapper. Wir behandeln hier die Sicherheitseinstellungen über ypserv selbst.

Wenn Sie nur die Binaries von ypserv haben, dann sagt Ihnen die Option-v mit welcher Konfiguration Ihr Binary kompiliert wurde:

root@charly >> /usr/sbin/ypserv -v
ypserv - NYS YP Server version 1.3.9 (with securenets)

Die Datei /var/yp/securenets enthält paarweise Kombinationen von netmask/network, mit denen Sie den Serverzugang kontrollieren können. Sie müssen diese Datei unter allen Umständen modifizieren: als Default enthält sie:

0.0.0.0 0.0.0.0

was aller Welt den Zugang auf Ihren NIS-Server erlaubt. Es ist anzumerken, daß der Datei lediglich die IP-Adressen bekannt sind (nicht der Namen der Maschinen).

Jetzt können wir die NIS-Datenbank erstellen. Wir benutzen dazu das Kommando ypinit. Es erstellt die Datenbank in /var/yp und benutzt die Dateien aus /etc (dies ist der Default, man kann auch ein anderes Verzeichnis im Makefile festlegen). Hier sind die Dateien, die die Daten für die Datenbank liefern ( /etc/passwd, /etc/group, /etc/hosts, /etc/networks, /etc/services, /etc/protocols, /etc/netgroup, /etc/rpc ).

Die Option -m gestattet es, den Server mit den Rohdaten zu initialisieren (-m für master), die Option -s kopiert die Daten von der Masterdatenbank auf einen Slave (-s für Slave - Sklave auf Englisch).

Auf Charly initialisieren wir unsere Datenbank wie folgt:

root@charly >> /usr/lib/yp/ypinit -m
At this point, we have to construct a list of the hosts which will run NIS
servers. localhost is in the list of NIS server hosts. Please continue to add
the names for the other hosts, one per line. When you are done with the
list, type a <control D>.
        next host to add: localhost
        next host to add: sabrina
        next host to add: jill
        next host to add: kelly
        next host to add:
The current list of NIS servers looks like this:

localhost
sabrina
jill
kelly

Is this correct? [y/n: y] y
We need some minutes to build the databases...
Building /var/yp/bosley/ypservers...
Running /var/yp/Makefile...
gmake[1]: Entering directory `/var/yp/bosley'
Updating passwd.byname...
Updating passwd.byuid...
Updating group.byname...
Updating group.bygid...
Updating hosts.byname...
Updating hosts.byaddr...
Updating rpc.byname...
Updating rpc.bynumber...
Updating services.byname...
Updating netid.byname...
Updating protocols.bynumber...
Updating protocols.byname...
Updating mail.aliases...
Updating shadow.byname...
# shadow publickey # networks ethers bootparams printcap \
# amd.home auto.master auto.home passwd.adjunct
gmake[1]: Leaving directory `/var/yp/bosley'

Und voila, schon steht die Datenbank :) Auf jedem Slaveserver muß man jetzt das folgende Kommando ausführen:

root@kelly >> /usr/lib/yp/ypinit -s charly

Um sicherzustellen, daß alles korrekt läuft, reicht es aus, einen Server in einen Klienten zu verwandeln, egal ob Master oder Slave, und einen Request abzusetzen. Zum Beispiel auf Charly [sic]:

root@kelly >> ypcat passwd mulder:x:500:100::/home/mulder:/bin/csh scully:x:501:100::/home/scully:/bin/bash

Man kann nebenbei auch feststellen, daß die Shadowpasswörter korrekt funktionieren :)

Installation eines NIS-Servers

portmap initialisieren;
Den NIS-Domänenname festlegen;
Die Konfigurationsdatei des NIS-Servers vorbereiten: /etc/ypserv.conf ;
Den ypserv Dämon starten;
In /var/yp/Makefile, die Maps auswählen, die von ypserv verwaltet werden sollen und dann die Kompilierungsoptionen einstellen;
Die Zugangsrechte für den NIS-Server in der Datei /var/yp/securenets festlegen;
Die NIS Masterdatenbank erstellen mit Hilfe des ypinit -m Kommandos;
Die Slavedatenbanken erstellen mit ypinit -s <master server> ;

Aktualisierung der NIS-Datenbank

Sobald man eine Map modifizieren möchte, um zum Beispiel einen neuen Slaveserver oder einen neuen User hinzuzufügen, muß man die NIS-Datenbank aktualisieren. Dies geht wie folgt.

Um einen Slaveserver hinzuzufügen genügt es, /usr/lib/yp/ypinit -s charly auf dem neuen Slaveserver auszuführen, und seinen Namen in die Datei /var/yp/ypservers des Masterservers einzufügen.

Wenn man einen neuen User anlegt, können sich mehrere Maps verändert haben (passwd, shadow, alias, etc ...).

Sobald man eine Map modifiziert hat, darf man nicht vergessen, ein make im Verzeichnis /var/yp/ des Masterservers zu machen: dies aktualisiert seine Datenbank, indem es die Information integriert und auf die Slaves verteilt (mit dem Kommando yppush).

Das Program rpc.ypxfrd erlaubt es, die Transaktion zwischen einem Masterserver und seinen Slaves zu beschleunigen. Es gestattet einem Slave, die Datenbank des Master-Servers einfach zu kopieren, anstatt sie komplett neuzuerstellen. rpc.ypxfrd muß zur selben Zeit gestartet werden wie ypserv und nur auf dem Master. Dieses Programm ist notwendig für sehr große Maps.

Benutzungsratschläge zum Schluß

Jederman weiß, daß NIS nicht gesichert ist. Trotzdem sind die Dienste, die es zur Verfügung stellt so nützlich, daß es schade wäre, es nicht zu benutzen. Man muß deshalb einige Vorsichtsmaßnahmen außerhalb von NIS treffen, wenn man es benutzen will.

Genauso wie es einige Passwörter gibt, die man leicht erraten kann, werden auch NIS-Domänennamen benutzt, die vorhersehbar sind. Offensichtliche Kandidaten sind, wenn man einmal den (Maschinen-) namen des NIS-Servers herausbekommen hat, der komplette oder teilweise Name des Servers oder auch der Name der Organisation, zu der der Server gehört. ypwhich gestattet es, den Namen der Domäne zu testen!

Der NIS-Domänenname erscheint an mehreren Stellen, besonders im Verzeichnis /var/yp, oder auch in einem Unterverzeichnis, das während der NIS-Installation angelegt wurde (auf dem(n) Server(n), aber auch auf den Klienten) und den Namen der NIS-Domäne trägt. Man muß deshalb die Zugangsrechte zu diesem Verzeichnis genau festlegen. Man darf auf es keinen Fall, nicht einmal read only, mit NFS exportieren. Jeder kann dann dieses Verzeichnis auf seiner eigenen Maschine mounten, um den Domänennamen herauszufinden.

Darüber hinaus schadet es nicht, tcp_wrapper zu benutzen. Damit kann man nämlich den portmap-Prozess kontrollieren, und verhindern, daß jederman RPC-Requests auf die eigene Maschine absetzt.

Es ist ebenfalls von Vorteil, die Defaultroute nicht über Ihren NIS-Server zu legen, sondern statisches Routing zu den Klienten und den Slaveservern zu benutzen. Der Server kennt auf diese Art nur Routen zu genau festgelegten Maschinen und kann deshalb nicht auf Requests von unbekannten Maschinen antworten.

Auf dem Router-Level erlaubt eine Firewall, den Zugang zu den NIS-Servern effektiv zu kontrollieren.

Diese Ratschläge ergeben sich aus dem gesunden Menschenverstand. Sie verändern nicht die Sicherheit von NIS selbst, sondern nur den Rahmen darum herum.Trotz dieser Probleme bleibt NIS ein effektives und praktisches Werkzeug.

Dokumentation

NIS-HOWTO : wie alle HOWTOs, sehr ausführlich und unerlässlich, um viel zu lernen.
http://www.suse.de/~kukuk/ : Er arbeitet an NIS und NIS+. Sein Site enthält mehrere FAQs
Der unvermeidbare Network Administrators' Guide erhältlich unter dieser Adresse http://www.linuxdoc.org/LDP/nag