Shellmitschrift LPI 201

1. Bind9 mit Replikation

Beide VMs sind mit Ubuntu 16.04 LTS ausgestattet und haben folgende wesentliche Eigenschaften:

Master-Server
- Hostname: uhu.dom1.site
- IP-Adresse: 10.20.30.3
Slave-Server:
- Hostname: uhu2.dom1.site
- IP-Adresse: 10.20.30.4

HINWEIS: Hier wird man am besten erst einmal mit sudo -i dauerhaft root.

1.1. Forwarders

Zur Erinnerung: Für die Weiterleitung ins Internet benötigen wir einen vorgeschalteten DNS-Server. Dies kann allgemein bei allen Servern geschehen. Dazu wurde die Direktive forwarders { 10.20.30.100; 144.76.34.109; }; aktiviert und angepasst:

options {
        directory "/var/cache/bind";

        // If there is a firewall between you and nameservers you want
        // to talk to, you may need to fix the firewall to allow multiple
        // ports to talk.  See http://www.kb.cert.org/vuls/id/800113

        // If your ISP provided one or more IP addresses for stable
        // nameservers, you probably want to use them as forwarders.
        // Uncomment the following block, and insert the addresses replacing
        // the all-0's placeholder.

        forwarders {
                10.20.30.100;
                144.76.34.109;
        };

        //========================================================================
        // If BIND logs error messages about the root key being expired,
        // you will need to update your keys.  See https://www.isc.org/bind-keys
        //========================================================================
        dnssec-validation auto;

        auth-nxdomain no;    # conform to RFC1035
        listen-on-v6 { any; };
};

1.2. Master-Konfiguration

Hier ist besonders die Zeile notify yes; von Belang. Wir haben sie hinzugefügt, um den Slave bei Erhöhung der serial-Angabe informieren zu können, dass er sich die Daten replizieren muss:

=> cat /etc/bind/named.conf.local

zone "dom1.site" {
        type master;
        notify yes;
        file "/etc/bind/db.dom1.site";
};

zone "30.20.10.in-addr.arpa" {
        type master;
        notify yes;
        file "/etc/bind/db.10.20.30";
};

AUFGABE: Bitte die Sicherheit mit allow-transfer verbesseren! Siehe dazu Seite 319.

Im entsprechenden Zonenfile ist es wichtig, den zweiten Nameserver, der als Slave fungieren soll, auch als solchen mit aufzunehmen. Dies wird durch die Zeile @ IN NS uhu2.dom1.site. realisiert, die hinzugefügt werden muss. Vergisst man dies, kann sich zwar der Slave die Daten bei einem systemctl restart bind9 selber ziehen, wird aber nicht vom Master mittels seiner notify-Nachrichten über Änderugen informiert:

=> cat /etc/bind/db.dom1.site

;
; BIND data file for local loopback interface
;
$TTL    604800
@       IN      SOA     uhu.dom1.site. root.uhu.dom1.site. (
                             90         ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                         604800 )       ; Negative Cache TTL
;
; Dies ist der eigene, lokale Master-Nameserver:
@       IN      NS      uhu.dom1.site.

; HINZUGEFÜGT: Dies ist der andere, entfernte Slave-Nameserver:
@       IN      NS      uhu2.dom1.site.

uhu     IN      A       10.20.30.3
uhu     IN      AAAA    ::1

; Weitere Einträge (ähnlich der /etc/hosts, allerdings ZUERST die Hostnamen, DANN die IPs!)
uhu2    IN      A       10.20.30.4
xphost  IN      A       10.20.30.126
xphost2 IN      A       10.20.30.127

AUFGABE: Bitte auch die reversen Zonenfiles anpassen!

1.3. Slave-Konfiguration

Hier ist zuerst einmal wichtig, anzugeben, wer der Master ist, von dem dann die Daten kopiert werden sollen. Das legen wir mit der Anweisung masters { 10.20.30.3; }; fest:

⇒ cat /etc/bind/named.conf.local

zone "dom1.site" {
        type slave;
        masters { 10.20.30.3; };
        file "/etc/bind/db.dom1.site";
};

zone "30.20.10.in-addr.arpa" {
        type slave;
        masters { 10.20.30.3; };
        file "/etc/bind/db.10.20.30";
};

Dann brauchen wir auch wieder das Zonenfile. Anders als beim Master, wo wir den Slave mittels NS-Record eintragen mussten, sind für die Replikation keine besonderen Einstellungen erforderlich:

=> cat /etc/bind/db.dom1.site

;
; BIND data file for local loopback interface
;
$TTL    604800
@       IN      SOA     uhu2.dom1.site. root.uhu2.dom1.site. (
                              2         ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                         604800 )       ; Negative Cache TTL
;
@       IN      NS      uhu2.dom1.site.
uhu2    IN      A       10.20.30.4
uhu2    IN      AAAA    ::1

; Weitere Einträge sind hier auf dem Slave nicht erforderlich,
; da er sich die Datensätze repliziert.

1.4. Testing

Auf beiden Maschinen: tail -f /var/log/syslog
Auf dem Master
- Datensatz hinzufügen
- Seriennummer erhöhen
- Config neu laden: rndc reload

1.5. Sicherheit

AUF DEM MASTER:

Um nur dem Slave-Server mit der Adresse 10.20.30.4 Zonentransfers zu erlauben (AXFR = Asynchronous Full Transfer Zone oder Asynchronous Xfer Full Range), verwenden wir allow-transfer:

zone "dom1.site" {
        type master;
        notify yes;
        allow-transfer { 10.20.30.4; };
        file "/etc/bind/db.dom1.site";
};

zone "30.20.10.in-addr.arpa" {
        type master;
        notify yes;
        file "/etc/bind/db.10.20.30";
};

Weiterhin kann man das ganz normale Abfragen der Datenbank (nslookup) reglementieren, in der Zonendefinition verwenden wir dazu so etwas:

allow-query { 127.0.0.1; 10.20.30.0/24; };

2. DHCP und DNS verbinden

ZIEL Einrichtung von dynamischen DNS (DDNS) unter Debian / Ubuntu

Siehe auch

2.1. Vorbereitung

DHCP- und DNS-Server sollten jeweils eingerichtet sein:

DHCP-Server: Deklaration eines Subnets mit gültigem Range
DNS-Server: Bereitstellung einer eigenen Zone für die Domäne "dom1.site", gern auch mit gültigen "forwarders"
Der Servername lautet im Beispiel "uhu"

HINWEIS: Die folgende Verzeichnisrecht-Anpassung von /etc/bind/ ist wegen rndc freeze und rndc thaw (siehe unten) unter Debian erforderlich, wenn der bind-Daemon seine Journaldateien in diesem Verzeichnis ablegen können soll:

=> chmod g+w /etc/bind

Besser ist aber im Fall von DDNS, die Zonen unter /var/lib/bind zu verwalten, zumal wir bei Ubuntu wegen AppArmor dazu gezwungen werden. Die Dateirechte sehen dort im übrigen so aus:

=> ls -ld /etc/bind

drwxr-sr-x 2 root bind 4096 Okt 30 11:17 /etc/bind

Wenn man also plant, die Zonendateien unter /var/lib/bind abzulegen, ist hier kein Handlungsbedarf.

2.2. Datei /etc/bind/named.conf

Unterhalb von include "/etc/bind/named.conf.options"; ist folgendes einzufügen:

controls {
          inet 127.0.0.1 allow {localhost; } keys { "rndc-key"; };
};

2.3. Datei /etc/bind/named.conf.local

Wie eben erläutert, macht es Sinn, die Zonendateien an einen anderen Ort zu legen.

In jedem Zonenblock müssen wir nun den Pfad zu den Zonendateien mit Hilfe der "file"-Anweisung auf /var/lib/bind verbiegen, so dass diese Angaben dann z.B. so lauten könnten:

...

   file "/var/lib/bind/db.dom1.site";

...

   file "/var/lib/bind/db.10.20.30";

...

Weiterhin sind in jeden Zonenblock nach der "file"-Anweisung diese Direktiven erforderlich:

allow-update { key "rndc-key"; };
notify yes;

Und schließlich muss am Ende der Datei noch folgendes angefügt werden:

include "/etc/bind/rndc.key";

Falls die Zonendateien nicht bereits unter /var/lib/bind erstellt wurden, verschieben wir sie jetzt an diesen Ort:

=> mv /etc/bind/db.dom1.site /etc/bind/db.10.20.30 /var/lib/bind/

2.4. Datei /etc/dhcp/dhcpd.conf

Zuerst muss die Zeile ddns-update-style none; auskommentiert werden (Raute-Zeichen voranstellen):

#ddns-update-style none;

Danach fügt man gleich darunter folgendes ein, wobei server-identifier (= Servername) und ddns-domainname (= Domainname wie im DNS festgelegt) anzupassen sind:

server-identifier           uhu;
ddns-updates                on;
ddns-update-style           interim;
ddns-domainname             "dom1.site.";
ddns-rev-domainname         "in-addr.arpa.";
ignore                      client-updates;

# This is the key so that DHCP can authenticate it's self to BIND9
include                     "/etc/bind/rndc.key";

# This is the communication zone
zone dom1.site. {
      primary 127.0.0.1;
      key rndc-key;
}

2.5. Bei Ubuntu: Leserechte für rndc.key via AppArmor einräumen

Bei Ubuntu Server 16.04 LTS sind per Default die Sicherheitspolicies von AppArmor aktiv. Da sich /usr/sbin/named im enforce-Modus befindet, wird damit auch der Zugriff auf die Datei rndc.key blockiert.

Daher müssen wir AppArmors Konfigurationsdatei für den dhcpd ändern. Wie hier gezeigt, muss die Zeile /etc/dhcp/ddns-keys/** r, auskommentiert werden, danach ist eine neue Zeile hinzuzufügen, die der Datei /etc/bind/rndc.key explizit Leserechte verleiht:

=> vi /etc/apparmor.d/usr.sbin.dhcpd

  #/etc/dhcp/ddns-keys/** r,
  /etc/bind/rndc.key  r,

Nun müssen nur noch die Dateirechte angepasst und die AppArmor-Policies neu eingelesen werden:

=> chown root:bind /etc/bind/rndc.key
=> chmod 640 /etc/bind/rndc.key
=> /etc/init.d/apparmor reload

2.6. Testings

2.6.1. Serverseitig

Beide Server müssen sich nun ohne größere Fehlermeldungen neu starten lassen:

=> /etc/init.d/bind9 restart
=> /etc/init.d/isc-dhcp-server restart

Existiert bereits ein manuell hinzugefügter Eintrag z.B. für "xpbox" in der Zonendatenbank, findet keine dynamische Erzeugung eines RRs statt, auch wenn dem Host eine neue IP-Adresse via DHCP zugewiesen wird.

ACHTUNG: Wenn der Daemon im dynamischen Modus arbeitet (erkennbar am Vorhandensein der *.jnl-Dateien im Verzeichnis /etc/bind), darf der Zonenverwalter nicht einfach die Zonenfiles ändern!! Erst nach dem Ausführen von

=>  rndc freeze

kann er dies tun. Nach Beenden des Editierens und einem rndc reload, kann die dynamische Arbeitsweise wieder mit

=>  rndc thaw

gestartet werden, dabei entstehen wieder die Journaldateien.

2.6.2. Clientseitig

Bei Verwendung von TinyCore Linux als Testsystem für den DHCP-Client, kann man auf einfache Weise die IP-Adresse mit

=> udhcpc -R

freigeben (release).

Das Neubeziehen der IP-Informationen lässt sich problemlos mit der Option -F <HOSTNAME> machen, wobei testweise ein anderer FQDN gesendet und in die Zonendatenbank geschrieben wird:

=> udhcpc -F myTinyLinuxHost

2.7. Praktische Umsetzung auf dem Master-Nameserver (Ubuntu 16.04)

HINWEIS: Wir betrachten hier nur die für DDNS erforderlichen Einstellungen. Bei Replikation mit einem Slave-Server ist in der Zonendefinition zur Verbesserung der Sicherheit die Einschränkung der Zonentransfers empfehlenswert (Default: allow-transfer { any; };).

2.7.1. Konfigurationsdateien des Nameservers

=> grep -v '//' /etc/bind/named.conf

include "/etc/bind/named.conf.options";

controls {
          inet 127.0.0.1 allow {localhost; } keys { "rndc-key"; };
};

include "/etc/bind/named.conf.local";
include "/etc/bind/named.conf.default-zones";

=> grep -v '//' /etc/bind/named.conf.options

zone "dom1.site" {
        type master;
        notify yes;
        allow-update { key "rndc-key"; };
        file "/var/lib/bind/db.dom1.site";
};

zone "30.20.10.in-addr.arpa" {
        type master;
        notify yes;
        allow-update { key "rndc-key"; };
        file "/var/lib/bind/db.10.20.30";
};

include "/etc/bind/rndc.key";

=> cat /var/lib/bind/db.dom1.site

$TTL    604800
@       IN      SOA     uhu.dom1.site. root.uhu.dom1.site. (
                             91         ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                         604800 )       ; Negative Cache TTL
;
@       IN      NS      uhu.dom1.site.
@       IN      NS      uhu2.dom1.site.
uhu     IN      A       10.20.30.3
uhu     IN      AAAA    ::1

; Weitere Einträge (ähnlich der /etc/hosts, allerdings ZUERST die Hostnamen, DANN die IPs!)
uhu2    IN      A       10.20.30.4
xphost  IN      A       10.20.30.6

=> cat /var/lib/bind/db.10.20.30

$TTL    604800
@       IN      SOA     uhu.dom1.site. root.uhu.dom1.site. (
                             91         ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                         604800 )       ; Negative Cache TTL
;
@       IN      NS      uhu.dom1.site.
3       IN      PTR     uhu.dom1.site.
4       IN      PTR     uhu2.dom1.site.

; Weitere...
4       IN      PTR     uhu2.dom1.site.
6       IN      PTR     xphost.dom1.site.

2.7.2. Konfigurationsdateien des DHCP-Servers

Nach der Installation mittels apt-get install isc-dhcp-server

legt man am besten gleich erst einmal das Listening-Interface fest:

=> tail -1 /etc/default/isc-dhcp-server

INTERFACES="enp0s3"

Dann ist die Hauptkonfigurationsdatei dran:

=> grep -v '^#' /etc/dhcp/dhcpd.conf

ddns-update-style     interim;

server-identifier     uhu;
ddns-updates          on;
ddns-domainname       "dom1.site.";
ddns-rev-domainname   "in-addr.arpa.";
ignore                client-updates;

include               "/etc/bind/rndc.key";

zone dom1.site. {
      primary 127.0.0.1;
      key rndc-key;
}

option domain-name "dom1.site";
option domain-name-servers 10.20.30.3, 10.20.30.4;

default-lease-time 600;
max-lease-time 7200;

log-facility local7;

subnet 10.20.30.0 netmask 255.255.255.0 {
  range 10.20.30.10 10.20.30.20;
  option routers 10.20.30.1;
}