BLog

ImprintImpressum
PrivacyDatenschutz
DisclaimerHaftung
Downloads 

Netzwerkdienste DNS und DHCP auf dem FreeBSD-Home-Server

Die Netzwerkeinrichtung des FreeBSD-Home-Servers wurde im vorangegangenen Artikel beschrieben. Nunmehr dient der Home-Server für alle Clients im LAN als Gateway in's Internet, jedoch stellt er bis jetzt weder den Domain-Name-Service DNS noch eine dynamische Host-Konfiguration DHCP bereit, und noch gelangen nur Clients mit einem statisch konfigurierten Adress-Satz aus Host-IP-Adresse, Teilnetzmaske, Router und DNS-Server in's Netz, wie z.B. unter Mac OS X:

Der DNS-Server

Ein DNS-Server dient dazu Domain-Namen in IP-Adressen aufzulösen und umgekehrt. Ferner hält er zusätzliche Informationen in sogenannten Zonen für die Domains bereit.

Das Domain-Name-System ist hierarchisch strukturiert, und ein Name-Server, der Anfragen über Domains erhält die er verantwortet, beantwortet diese direkt - in dem Fall ist er der autorisierte Name-Server (Authorized Name Server).

Auf Anfragen (Requests) über fremde Domains antwortet er je nach Konfiguration entweder mit der Fehlermeldung NXDOMAIN oder er leitet die Fragen an andere Server weiter. Von denen erhält er entweder eine endgültige Antwort oder Hinweise (Hints) auf andere Name-Server die er dann weiterverfolgt. Die Weiterverfolgung wird rekursiv wiederholt (Recursive Name Server) bis eine endgütige Antwort eines autorisierten Servers vorliegt.

Um neue ähnliche Anfragen schneller beantworten zu können, ohne vorher noch einmal all die anderen Server befragen zu müssen, legen die meisten rekursiven Name-Server gültige Angaben in einem Zwischenspeicher (Cache) ab und halten diese für einen eingestellten Zeitraum (TTL) darin vor (Caching Name Server).

Internet Service Provider (ISP) stellen Ihren Kunden üblicherweise einen Zugriff auf ihre Recursive Caching Name Server zur Verfügung, und bei der Konfiguration der Verbindung in's Internet gibt man die betreffende(n) Adresse(n) unter DNS-Server entweder in der Netzwerkeinstellung des Computers (s. oben) bzw. des Routers ein, oder sie werden automatisch per DHCP eingerichtet. So oder so gehen dann alle DNS-Anfragen von unserem Computer bzw. aus unserem Netz über den Name-Server unseres ISP. Das ist bequem, hat aber auch seine Nachteile:

  • Der ISP sieht, daß unser Bowser die IP-Adresse von www.playboy.com wissen will, und zwar bevor die eigentliche Seite überhaupt aufgerufen werden kann. Das läßt sich mit Zeitstempel millisekundengenau protokollieren.
  • Der ISP kann die Antworten an unsere Anfragen manipulieren. Beispielsweise könnte er anstelle der IP-Adresse von www.playboy.com, die IP-Adresse des eigenen kostenpflichtigen Angebots www.playboys-and-girls.com angeben. Das wäre natürlich wettbewerbswidrig, und die technischen Möglichkeiten werden deshalb nicht so offensichtich mißbraucht. Tatsächlich leiten aber manche ISP's Anfragen zu Tipp-Fehler-Domains, beispielsweise an www.playboz.com, auf eigene Angebote um, anstelle eine Fehlermeldung (NXDOMAIN) zurückzugeben. Statt der nackten Echtweiber, sieht man dann halbnackte Schaufensterpuppen; und deren Dessous (Made in Kambodscha) kann man dann praktischerweise auch gleich durch einen Klick für zehneurofünfzig im angeschlossen Online-Store kaufen - oder so ähnlich.
  • Darüberhinaus zielen gewisse kriminelle Energien sowie diverse staatliche Überwachungsphantasien (Stichwort Zensursula) auf die Manipulation des DNS. In Deutschland sind solchen Manipulationen rechtliche Grenzen gesetzt, allerdings ist technisch in diesem Bereich ziemlich viel und zwar ohne weiteres machbar.

Wer das alles nicht will, der richtet seinen eigenen rekursiven DNS-Server auf seinem FreeBSD-Home-Server ein. Dieser holt sich dann die Adress-Informationen direkt und via DNSSEC abgesichert bei den autorisierten Servern der sog. Root-Zonen ab. Die einfachen Manipulationen sind damit jedenfalls vom Tisch. Ausserdem eröffnet uns der eigene DNS-Server weitergehende interessante Möglichkeiten:

  • Wir können eine lokale DNS-Zone einrichten, in der alle im Haus-Netz angeschlossenen Geräte ihren eigenen Domain-Namen erhalten.
  • Wir können Domain-Sperrzonen für bekannte Werbungs-, Tracking-, Spam- und Mal-Ware-Seiten einrichten.
  • Wir können protokollieren lassen, auf welche Domains der Kühlschrank, die Kaffeemaschine, das Fernsehgerät, der Sohn, der Feuermelder und die Heizungsanlage zugreifen möchten, und einen unerwünschten Zugriff durch verschiedene Maßnahmen, z.B. durch Aufnahme in die Sperrzonen-Liste, durch einen transparenten http/https-Proxy, oder auch direkt an der Firewall unterbinden.

Alles zusammen genommen stellt sich ein eigener rekursive DNS-Server als einer der Eckpfeiler zur eigenen Informationshoheit dar, und alleine das dürfte Grund genug sein, den überschaubaren Extraaufwand für dessen Einrichtung in Kauf zu nehmen.

Installation und Einrichtung des rekursiven DNS-Servers

Zunächst müssen wir uns für ein Name-Server-System entscheiden. Vor einigen Jahren war es einfach, denn eigentlich kam nur BIND in Frage. Seit neuem gibt es Unbound, dem ein Mehr an Sicherheit und Geschwindigkeit bei gleichzeitiger Kompaktheit nachgesagt wird, und in FreeBSD 10 wurde dann auch BIND aus dem Basissystem entfernt und durch Unbound ersetzt. Seit FreeBSD 10 bietet es sich also an, unbound(8) zu benutzen. Zur Einrichtung des DNS-Servers meldet man sich als Benutzer root an seinem FreeBSD-Home-Server an.

Das voreingestellte Basis-Verzeichnis von unbound ist /var/unbound, und für die folgenden Schritte wechselt man in dieses noch leere Verzeichnis:

cd /var/unbound

Im ersten Schritt lädt man vorab die DNS-Root-Zonen-Datei vom Internic-FTP-Server in dieses Verzeichnis. Das muß vorab geschehen, denn mitten in der Umstellung ist das nicht möglich, weil der alte DNS-Zugriff deaktiviert wird:

fetch -o root-hints.zones ftp://ftp.internic.net/domain/named.cache

Nun werden die vom System bereitgestellten Installations-Scripts der Reihe nach ausgeführt:

/etc/rc.d/local_unbound onesetup
>>>>
Performing initial setup.
Extracting forwarders from /etc/resolv.conf.
/var/unbound/forward.conf created
/var/unbound/unbound.conf created
/etc/resolvconf.conf created
original /etc/resolv.conf saved as /etc/resolv.conf.20140814.181051
/etc/rc.d/local_unbound oneanchor

Durch diese Scripts wurden u.a. die Konfigurationsdatei /var/unbound/unbound.conf sowie der DNSSEC-Schlüssel /var/unbound/root.key erzeugt. Es sind noch einige Kleinigkeiten in der Konfigurationsdatei zu ergänzen:

nano unbound.conf

Änderungen in blau:

# Generated by local-unbound-setup
server:
        username: unbound
        directory: /var/unbound
        chroot: /var/unbound
        pidfile: /var/run/local_unbound.pid
        auto-trust-anchor-file: /var/unbound/root.key

include: /var/unbound/forward.conf
        outgoing-range: 512
        root-hints: /var/unbound/root-hints.zones
        interface: 127.0.0.1
        interface: 192.168.1.35
        interface: ::1
        access-control: 127.0.0.1 allow
        access-control: 192.168.1.0/24 allow
        access-control: 0.0.0.0/0 deny
        access-control: ::0/0 deny
        private-address: 0.0.0.0/8
        private-address: 127.0.0.0/8
        private-address: 169.254.0.0/16
        private-address: 10.0.0.0/8
        private-address: 172.16.0.0/12
        private-address: 192.168.0.0/16
        private-address: fd00::/8
        private-address: fe80::/10​

Die Einstellungen für das Forwarding an einen anderen Server werden entfernt, und stattdessen wird der Name der Root-Zonen-Datei unter /var/unbound/root-hints angegeben. Die diversen interface- und access-control-Einstellungen bewirken, daß der Name-Server Anfragen nur aus unserem lokalen Netzwerk annimmt. Die private-address-Einträge bezeichnen IP-Adressen, die eigentlich in öffentlichen Domains nicht vorkommen sollten, und daher von unserem Name-Server unterdrückt werden. Dadurch werden sog. DNS-Rebinding-Attacken verhindert.

Mit dem folgenden Befehl kann man testen, ob die Konfigurationsdatei auch nach den Änderungen noch fehlerfrei ist:

unbound-checkconf
>>>>
unbound-checkconf: no errors in /var/unbound/unbound.conf

Wenn keine Fehler gemeldet werden, so wie oben, dann aktiviert man den Name-Service im System-Start-Script /etc/rc.conf, so daß er auch nach Neustart aktiv ist, und startet ihn nun zum Testen einmal manuell:

echo 'local_unbound_enable="YES"' >> /etc/rc.conf
service local_unbound start

Danach testet man, ob der Name-Server tatsächlich funktioniert:

drill obsigna.net
>>>>
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 4849
;; flags: qr rd ra ; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0 
;; QUESTION SECTION:
;; obsigna.net.	IN	A

;; ANSWER SECTION:
obsigna.net.	3600	IN	A	81.169.145.162

;; AUTHORITY SECTION:
obsigna.net.	3600	IN	NS	shades08.rzone.de.
obsigna.net.	3600	IN	NS	docks15.rzone.de.

;; ADDITIONAL SECTION:

;; Query time: 1648 msec
;; SERVER: 127.0.0.1
;; WHEN: Thu Aug 14 19:00:56 2014
;; MSG SIZE  rcvd: 103

Die erste Namensauflösung hat 1648 Millisekunden gedauert. Beim zweiten Mal geht es extrem viel schneller, denn obsigna.net befindet sich ja jetzt bereits im Cache:

drill obsigna.net
>>>>
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 3454
;; flags: qr rd ra ; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0 
;; QUESTION SECTION:
;; obsigna.net.	IN	A

;; ANSWER SECTION:
obsigna.net.	3335	IN	A	81.169.145.162

;; AUTHORITY SECTION:
obsigna.net.	3335	IN	NS	shades08.rzone.de.
obsigna.net.	3335	IN	NS	docks15.rzone.de.

;; ADDITIONAL SECTION:

;; Query time: 0 msec
;; SERVER: 127.0.0.1
;; WHEN: Thu Aug 14 19:05:22 2014
;; MSG SIZE  rcvd: 103

Die Anfragedauer beträgt 0, d.h. weniger als 0,1 Millisekunden, das ist mehr als 16000mal schneller :-) Jedenfalls dürfte der Server jetzt auch auf Anfragen aus dem lokalen Netzwerk antworten, und man kann die Name-Server-Einträge in den Netzwerk-Einstellungen der Clients auf die IP des Home-Servers, hier 192.168.1.35, umstellen.

Der DHCP-Server

Über DHCP = Dynamic Host Configuration Protocol, können die Einstellungen für ein gegebenes Netzwerk dynamisch an noch nicht konfigurierte Clients übergeben werden, so daß diese sich selber für den Netzwerkzugriff einrichten können. Der DHCP-Server ist derjenige, der die gültigen Einstellungen kennt und anfragenden Clients aus einem Pool an zur Verfügung stehenden IP-Adressen zuweist. FreeBSD hat einen DHCP-Client bereits installiert. Damit kann das System seine eigenen Netzwerk-Einstellungen z.B. vom DHCP-Server des ISP erfahren, und sich automatisch darauf einrichten. Ein lokaler DHCP-Server muß hingegen separat installiert werden:

pkg install isc-dhcp44-server

In der Konfigurationsdatei des DHCP-Daemons dhcpd(8) /usr/local/etc/dhcpd.conf werden die notwendigen Details über das bediente Netzwerk eingetragen. Es wird die Beispiel-Konfiguration aus dem Weg geräumt, und mit dem Befehlszeilen-Editor nano eine neue Datei angelegt:

mv /usr/local/etc/dhcpd.conf /usr/local/etc/dhcpd.conf.sample
nano /usr/local/etc/dhcpd.conf

Darin wird folgendes eingetragen, und dann mit der Kommandosequenz <ctrl>-<o> und <ctrl>-<x> gespeichert:

default-lease-time 3600;
max-lease-time 86400;
ddns-update-style none;

subnet 192.168.1.0 netmask 255.255.255.0
{
    range 192.168.1.64 192.168.1.127;
    option subnet-mask 255.255.255.0;
    option routers 192.168.1.35;
    option domain-name-servers 192.168.1.35;
    option domain-search "example.com";
}

In dieser Datei wird neben Router- und Name-Server-Adresse auch der für DHCP zur Verfügung stehende IP-Adressen-Pool festgelegt, hier 192.168.1.64 - 192.168.1.127. Dieser Adressen-Pool ist nunmehr reserviert und soll nicht für andere Zwecke verwendet werden. In Zukunft werden wir einen weiteren reservierten IP-Bereich benötigen, nämlich für Clients, die sich von extern über L2TP/IPsec-VPN mit unserem Server verbinden wollen. Ausserdem ist es sinnvoll, Black-Box-Netzwerkgeräte, die nichts im Internet verloren haben, wie Drucker, Wireless-Router, Fernsehgeräte, Hausanlagen, etc., mit statischen IP-Adressen aus einem separaten Bereich zu versehen, so daß man deren Netzzugriff en-Block in der Firewall regeln kann. Der folgende Vorschlag zur Aufteilung des zur Verfügung stehenden Netzbereichs, hier 192.168.1.0 - 192.168.1.255 dürfte für die meisten Bedürfnisse eine gute Grundlage darstellen, ein Fine-Tuning ist natürlich immer möglich - die Netzbereiche sollen sich jedenfalls nicht überlappen:

  • Netzwerk-IP-Adresse (liegt fest): 192.168.1.0
  • Statische IP-Adressen für alle stationären Computer: 192.168.1.1 - 192.168.1.63/26
  • Dynamische IP-Adressen (DHCP) für mobile Clients: 192.168.1.64 - 192.168.1.127/26
  • VPN-IP-Adressen für mobile Clients unterwegs: 192.168.1.128 - 192.168.1.191/26
  • Statische IP-Adressen für Black-Boxes: 192.168.1.192 - 192.168.1.254/26
  • Broadcast-IP-Adresse (liegt fest): 192.168.1.255

Bevor wir den nunmehr eingerichteten DHCP-Server aktivieren, sollte noch sichergestellt werden, daß andere DHCP-Server nicht dazwischen funken können - „Es kann nur Einen geben.“ Man deaktiviert am besten alle in den diversen Wireless- und sonstigen Routern im Haus eingebauten DHCP-Server, und man fügt noch eine entsprechende Regel zur Firewall hinzu. Dabei kann man dann auch gleich den statischen Black-Box-IP-Bereich vom Internet aussperren. Schließlich ist es noch sinnvoll, den Zugriff auf fremde Name-Server (Port 53) aus unserem Netz heraus zu unterbinden. Die neue ipfw(8) Firewall-Konfigurationsdatei /root/config/ipfw.conf sieht danach wie folgt aus:

#!/bin/sh

for iface in `/sbin/ifconfig -l` ; do
   desc=`/sbin/ifconfig $iface | /usr/bin/sed -n '/.description: /{s///;s/ .*//;p;}'`
   if [ "$desc" == "LAN" ] ; then
      LAN="$iface"
   elif [ "$desc" == "WAN" ] ; then
      WAN="$iface"
   fi
done

/sbin/ipfw -q flush
/sbin/ipfw -q table all destroy
/sbin/ipfw -q nat 1 config if $WAN unreg_only reset

# There can be only one (DHCP Server in the local net),
# and that's me - so kill the others.
/sbin/ipfw -q add 5 deny udp from not me 67 to any 68 via $LAN

# Allow anything else within the LAN - interfaces with heavy traffic shall come first
/sbin/ipfw -q add 10 allow ip from any to any via $LAN
/sbin/ipfw -q add 20 allow ip from any to any via lo0

# Don't trust 3rd party network devices (Printer, Router, House Devices, etc.),
# which we have put into the upper network range 192.168.1.192-255
/sbin/ipfw -q add 60 deny ip from 192.168.1.192/26 to any via $WAN

# Catch spoofing of incomming packets
/sbin/ipfw -q add 70 deny ip from any to any not antispoof in recv $WAN

# NAT rule for incomming packets
/sbin/ipfw -q add 100 nat 1 ip4 from any to any in recv $WAN
/sbin/ipfw -q add 101 check-state

# Rules for outgoing traffic - allow everything that is not explicitely denied
# Prohibit access to external SMTP and DNS servers (ports 25, 53, and 5353)
/sbin/ipfw -q add 1000 deny ip from not me to any 25,53 out xmit $WAN
/sbin/ipfw -q add 1010 deny ip from any to any 5353 out xmit $WAN

# Allow all other outgoing connections
/sbin/ipfw -q add 2000 skipto 10000 tcp from any to any out xmit $WAN setup keep-state
/sbin/ipfw -q add 2010 skipto 10000 udp from any to any out xmit $WAN keep-state

# Rules for incomming traffic - deny everything that is not explicitely allowed
/sbin/ipfw -q add 5000 allow tcp from any to me 11 in recv $WAN setup keep-state

# Catch tcp/udp packets, but don't touch gre, esp, icmp traffic
/sbin/ipfw -q add 9998 deny tcp from any to any via $WAN
/sbin/ipfw -q add 9999 deny udp from any to any via $WAN

# NAT rule for outgoing packets
/sbin/ipfw -q add 10000 nat 1 ip4 from any to any out xmit $WAN

# Allow anything else - just in case ipfw has not been configured as open firewall
/sbin/ipfw -q add 65534 allow ip from any to any

Schließlich muß noch der DHCP-Server im System-Start-Script /etc/rc.conf eingetragen werden, so daß er beim Systemstart automatisch aktiviert wird:

nano /etc/rc.conf

Die folgenden Einträge (ohne ...) müssen angefügt werden:

...

dhcpd_enable="YES"
dhcpd_flags="-q"
dhcpd_ifaces="em0"

WICHTIG: Es muß die Gerätekennung des lokalen Netzwerk-Adapters hier em0 angegeben werden - ggf. anpassen!

Damit ist die Einrichtung der Netzwerk-Dienste DNS und DHCP abgeschlossen, und nach Neustart des FreeBSD-Home-Servers sind beide Dienste aktiv. In den Netzwerkeinstellungen der stationären Clients kann jetzt die IP-Adresse des lokalen Name-Servers eingetragen werden:

Die mobilen Clients können ab sofort ihre Netzwerk-Einstellungen via DHCP von unserem FreeBSD-Home-Server beziehen. Das Thema Such-Domains wird in einem späteren Artikel behandelt, nämlich dann wenn unser FreeBSD-Home-Server seinen eigenen Domain-Namen erhält.

Copyright © Dr. Rolf Jansen - 2014-08-18 16:26:44

PROMOTION