Der Pflege- und Konfigurationsaufwand statischer IP Adressen ist bei mehreren Servern recht hoch, sollte sich etwas an der Netzwerkkonfiguration ändern. Deshalb setzt man häufig einen DHCP Server mit Reservierungen ein, so dass beispielsweise Server (oder auch andere DHCP Clients, falls gewünscht) aufgrund der gleichbeibenden MAC Adresse stets die gleiche IP Adresse erhalten.

Zu Hause verwende ich die DHCP Server Einstellungen, welche ich auch benötige. Bei meinen gemieteten vServern, welche hauptsächlich mit Debian und auch einmal mit Ubuntu laufen, sieht es ein wenig anders aus. Den meisten Nutzern sollten die vom Anbieter vorgegebenen DNS Server genügen, ich möchte aber meine eigenen DNS Server verwenden.

Normalerweise, sprich bei statischer Konfiguration des Netzwerks, würde ich die DNS Server in die /etc/resolv.conf eintragen. Die dort stehenden DNS Server werden dann systemweit zur Namensauflösung verwendet. Der DHCPCD (Der DHCP Client-Daemon, dieser stellt die DHCP Anfragen) überschreibt die Datei allerdings nach Erhalt eines DHCP Leases. Die Lösung ist einfach, denn man kann den DHCPCD so konfigurieren, dass eigene Einstellungen die vom DHCP Server vorgegebenen Einstellungen ersetzen. Für die Konfiguration der DNS Server und der Domain trägt man beispielsweise folgendes zusätzlich in die /etc/dhcp/dhclient.conf ein:

supersede domain-name-servers 192.168.100.10, 192.168.100.20;
supersede domain-name "example.org";

Anschließend startet man, wenn der Zeitpunkt passend ist, das Netzwerk neu:

systemctl restart networking

Nach einem Neustart kann mit

cat /etc/resolv.conf

Installation

Unter Arch Linux ist die Installation meist einfach, da das Paket im Arch User Repository enthalten ist:

yaourt -S sunwait

Eigentlich möchte ich es aber auf einem Debian bzw. Raspbian einsetzen. Dort muss man es kurz herunterladen und kompilieren. Eine geforkte, etwas erweiterte Version namens sunwait4windows existiert und lässt sich auch unter Linux kompilieren und ausführen:

cd /usr/local/src
wget http://netcologne.dl.sourceforge.net/project/sunwait4windows/sunwait0-8.tar
tar xf sunwait0-8.tar
cd sunwait/0.8
make
cp sunwait /usr/local/bin

Benutzung

Die erste Hürde bei der Benutzung von sunwait ist die Ermittlung des Breiten- und Längengrades für den eigenen Standort. Hierzu habe ich OpenStreetMap verwendet, meinen Standort auf höchster Zoomstufe herausgesucht und mir die Daten aus der URL herauskopiert.

sunwait poll exit 52.01075N 8.54081E
# liefert DAY oder NIGHT in der Standardausgabe
# Exit-Code für DAY ist 2 und für NIGHT 3
if [ $? -eq 2 ]; 
then
    echo "Es ist Tag."
else
    echo "Es ist Nacht."
fi

Wer nicht nur herausfinden möchte, ob es Tag oder Nacht ist, sondern mit sunwait warten möchte, bis Sonnenaufgang oder -untergang eintreten, kann andere Modi wie z.B. wait anstatt poll verwenden. Die Hilfe kann angezeigt werden, indem sunwait ohne weitere Parameter aufgerufen wird.

Ich kombiniere sunwait mit einem Raspberry Pi samt 433 MHz Funksteckdosen-Schaltung, um einige Lichter abhängig von der Tageszeit und einiger anderer Parameter ein- oder auszuschalten. Einsatzmöglichkeiten gibt es glücklicherweise genug.

Um die IPTables Firewall unter Debian oder Ubuntu zu konfigurieren, verwende ich iptables-persistent. Die Firewall-Regeln werden dabei in Textdateien gespeichert und beim Starten geladen. Nach der Installation von iptables-persistent besteht die Möglichkeit, bereits vorhandene Regeln zu speichern, was zu empfehlen ist, da somit schon eine grundlegende Konfiguration erstellt wird. Die Installation selbst ist simpel:

apt-get intall iptables-persistent

Anschließend wird jeweils eine Datei für IPv4 und IPv6 angelegt. Anbei eine einfache Beispielkonfiguration, die entsprechend den eigenen Bedürfnissen erweitert werden kann:

# Generated by iptables-save v1.4.21 on Mon Mar  7 18:13:53 2016
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]

-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT

# SSH
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT

# HTTP(S)
-A INPUT -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 443 -j ACCEPT

# NRPE (monitoring)
-A INPUT -p tcp -m state --state NEW -m tcp --dport 5666 -s 78.46.251.28/32 -j ACCEPT

-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
COMMIT
# Completed on Mon Mar  7 18:13:53 2016

Die Ketten INPUT, FORWARD und OUTPUT akzeptieren standardmäßig alle Verbindungen. Eingehender, zu anderen Verbindungen gehörender Verkehr (RELATED,ESTABLISHED) wird ebenfalls durchgelassen. Ebenso werden ICMP Pakete (Ping, -p icmp) aktzeptiert und auch Verbindungen zum lokalen Loopback Interface.

Dann werden die TCP Ports 22, 80 und 443 akzeptiert. Der Port 5666, auf welchem der NRPE Dienst hört, soll nur von einer IP Adresse erreichbar sein. Anschließend werden alle nicht vorher definierten eingehende und weiterzuleitende Verbindungen abgelehnt (-j REJECT –reject with icmp-host-prohibited). Alternativ können diese Zeilen entfernt werden, falls man die INPUT und FORWARD Kette standardmäßig auf REJECT stellt. Im Falle eines Fehlers in der Konfiguration ist es aber dann notwendig, physikalischen Zugriff auf den Server zu haben, da eventuell alle Verbindungen abgelehnt werden. Die Art der Konfiguration ist aber Geschmackssache, das Ergebnis ist gleich.

Für IPv6 sollen normalerweise etwa die gleichen Regeln gelten, ein paar Parameter (natürlich IPv6 anstatt IPv4 Adressen verwenden oder icmp6-adm-prohibited statt icmp-host-prohibited) müssen aber ausgetauscht werden. Das Ergebnis ist vergleichbar:

# Generated by iptables-save v1.4.21 on Mon Mar  7 18:13:53 2016
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]

-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p ipv6-icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT

# SSH
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT

# HTTP(S)
-A INPUT -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 443 -j ACCEPT

# NRPE
-A INPUT -p tcp -m state --state NEW -m tcp --dport 5666 -s 2a01:4f8:c17:34ab::2/128 -j ACCEPT

-A INPUT -j REJECT --reject-with icmp6-adm-prohibited
-A FORWARD -j REJECT --reject-with icmp6-adm-prohibited
COMMIT
# Completed on Mon Mar  7 18:13:53 2016

Diese Regeln sind recht schlicht, aber schon ein sehr brauchbarer Anfang. Zusätzlich können noch ausgehende Verbindungen eingeschränkt werden, falls dies gewünscht ist. Spätestens wenn Datenbanken oder ähnlich sensible Dienste über Netzgrenzen hinweg erreichbar sein sollen, sollte definitiv zumindest irgendeine Art Firewall eingesetzt werden.