Häufig lese ich in Linux Foren, dass es Nervereien mit dem NAT und routing aus dem privaten Netz in das Internet gibt. Meistens wird dann auf route -n als Beleg verwiesen das doch alles ok wäre. Einige wissen dann auch, dass in /etc/sysctl.conf das forward zwischen den zwei Netzwerkkarten aktiviert werden muss. Und dann herrscht Fragezeichen….

Letztlich muss noch der private Adressenbereich – z.B. 192.168.1.0/24 – auf eine öffentliche Adresse abgebildet/übersetzt werden. Für diese Übersetzung (Network Address Translation / NAT) müssen wir mit iptables einen Regelsatz festlegen. Iptables ist ein gängiges Paket unter Linux, dass es ermöglicht, dass Netzwerk- Daten- Management des Linux Kernels zu beeinflussen.

Ursprünglich habe ich eine Firewall installiert – meistens shorewall – und dann umständlich konfiguriert, damit NAT und routing funktioniert. Die letzten Jahre, wollte ich meine Heimserver Konfiguration immer abgespeckter und installiere mittlerweile keine Firewall mit großartiger Konfiguration.

Deswegen habe ich hier mal verschiedene Möglichkeiten zusammen gestellt, wie Admina ein einfaches NAT und routing aktivieren kann. Die hier aufgeführten Konfigurationen wurde auf Ubuntu Server 18.04 (teilweise 20.04.3) getestet, setzen voraus, dass die iptables installiert wurden und sind voneinander unabhängig – quasi als Auswahl – zu lesen.

Um es nochmal deutlich zu sagen: Hier geht es nicht um Sicherheit! Ich beschreibe hier keine umfängliche Firewall Konfiguration! Und wenn Dir noch nicht klar ist, von was ich hier eigentlich rede, recherchiere dazu noch auf anderen Webseiten und Foren. NAT und routing kann auch in der Verbindung von mehreren Hausnetzen – Netz im 1.Stock, Netz im 2.Stock, usw. – oder VPN relevant sein.

Der einfachste Fall ist wohl, ein einfaches Heimnetz mit ein paar Rechner, Fernseher, in das Internet zu bringen. Im Text gehe ich von einer ipv4 Umgebung im Heimnetz aus – wird primär ipv6 genutzt, müssen eventuell weitere Anpassungen gemacht werden. Und ich bin ein großer Fan von SSHguard.

Die Konfiguration des Heimnetzes, von der ich hier ausgehe, zeigt Dir folgendes Bild:

Werte und Device- Namen sind natürlich dem eigenen Netzwerk anzupassen! Also verstehe die Logik!

Einfache Iptables Regel in /etc/rc.local

Erstelle die Datei /etc/rc.local und mache diese mit chmod 755 ausführbar. Trage folgende Zeilen ein (wobei eth0 mit der Bezeichnung deiner Netzwerkkarte mit Verbindung zum Internet ersetzt werden muss):

#!/bin/bash
/sbin/iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
exit 0

Aktiviere in /etc/sysctl.conf den Parameter net.ipv4.ip_forward=1 in dem Du die Raute entfernst. Starte den Rechner neu und prüfe mit iptables -L -n -t nat ob ein Wert mit MASQUERADE angezeigt wird. Wenn ja: alles ok und fertig.

Meine Meinung: Quick und dirty. SSHguard fügt sich problemlos ein.

Siehe zum Vergleich auch immer: iptables -L -n (Anzeige aller Regelsätze) und journalctl -xb (nach einem reboot)

Nutzung von systemd-networkd (z.B. bei Ubuntu Server)

Erstelle die Datei /etc/netplan/01-set-networkd.yaml und trage folgende Zeilen ein (Beachte mandatory Leerzeichen vor den zwei Zeilen!):

network:
  version: 2
  renderer: networkd

Mit dieser (optionalen) Datei wird dem System nochmal ausdrücklich gesagt: “Benutze systemd-networkd (kurz: networkd) zur Netzwerkkonfiguration.”

Zur Vorbeugung, weil bei einer Desktop Installation auf den Ubuntu Server(!) eventuell der NetworkManager o.Ä. in Abhängigkeit installiert und diese Konfiguration unbrauchbar wird. Ubuntu Server(!) nutzt nach einer Standard- Installation networkd und damit Befehle wie z.B. networkctl – also keinen NetworkManager und seine Befehle!

Bei einer Netzwerk- Konfiguration mit networkd liegen die Konfigdateien für die Netzwerkkarten in /etc/systemd/network.

Öffne/erstelle die Konfigdatei (zb. 60-eth0.network) für die Netzwerkkarte zum Internetrouter/Kabelmodem und erweitere die Konfiguration um den [Route]- Eintrag:

[Match]
Name=eth0

[Network]
Address=192.168.0.2/24

[Route]
Gateway=192.168.0.1
Destination=0.0.0.0/0
GatewayOnlink=yes

und öffne/erstelle die Konfigdatei (z.B. 61-eth1.network) für die zweite Netzwerkkarte mit Verbindung zum lokalen Netzwerk und erweitere um die folgenden Zeilen unter [Network]:

[Match]
Name=eth1

[Network]
Address=192.168.2.2/24
IPMasquerade=yes
IPForward=yes

Laß mit systemctl restart systemd-networkd die geänderte Konfiguration vom Netzwerk- Dienst einlesen. Ein Neustart ist eigentlich nicht nötig, aber schadet auch nicht.

Prüfe mit iptables -L -n -t nat ob ein Wert mit MASQUERADE angezeigt wird und mit route -n ob eine route zum Internet- Router (hier: 192.168.0.1) für das Ziel 0.0.0.0/0 (z.B. Internet) existiert. Zusätzlich kann mit networkctl status oder systemctl status systemd-networkd die Konfiguration und auf Fehler geprüft werden. Mit einen sysctl -a | grep forward kannst Du nachschauen, ob die Weiterleitung zwischen den Netzwerkkarten – also forward – mit = 1 aktiviert wurde. Auch die Ausgabe von netplan get kann hilfreich sein.

Eine Aktivierung von Parameter in /etc/sysctl.conf oder weitere Anpassungen sind nicht nötig. Ansonsten: fertig.

Meine Meinung: Weniger quick aber cleaner. SSHguard fügt sich problemlos ein.

Ein Perl Skript: Nathelper

Downloade das Perl Skript von hier, speichere es im Ordner /etc und mache es mit chmod 755 ausführbar. Erstelle die Datei /etc/rc.local, mache diese mit chmod 755 ausführbar und kopiere folgende Zeilen hinein:

#! /bin/bash
/etc/nathelper -i eth0 -m
exit 0

Für Nathelper muss kein Parameter in der sysctl.conf geändert werden, das Perl Skript setzt die notwendigen Parameter. Starte den Rechner neu und prüfe mit iptables -L -n -t nat ob ein Wert mit MASQUERADE angezeigt wird. Wenn ja: alles ok und fertig.

Meine Meinung: Quick und weniger dirty. Ausbaufähig, da dem Skript weitergehende Optionen übergeben werden können (siehe Doku auf der Downloadseite). SSHguard fügt sich problemlos ein.

Einfacher Einstieg: Firehol

Installiere mit apt install firehol diese Firewall. Für Firehol muss kein Parameter in der /etc/sysctl.conf geändert werden. Benenne die bestehende /etc/firehol/firehol.conf um, erstelle eine Neue und kopiere folgenden Code hinein:

version 6
interface4 eth1 mylan
   policy accept

interface4 eth0 internet
   server all accept
   client all accept

router4 mylan2internet inface eth1 outface eth0
   masquerade
   route all accept

Setze in /etc/default/firehol den Parameter START_FIREHOL=no auf yes. Starte den Rechner neu und prüfe mit iptables -L -n -t nat ob ein Wert mit MASQUERADE angezeigt wird. Wenn ja: alles ok und fertig.

Meine Meinung: Firehol ist nicht schlecht! Das NAT und routing funktioniert problemlos, ist sehr performant und es werden einige Iptables Regelsätze gleich mit installiert, die aber keine administrativen Nacharbeiten fordern.

Hier noch eine optionale weitergehende Konfiguration, welche blacklisting von Angreifern mit ipset und einen differenzierten Zugriff auf Serverports ermöglicht:

version 6

server_meinssh_ports="tcp/2222"
client_meinssh_ports="default 2222"
server_sieve_ports="tcp/4190"
client_sieve_ports="default 4190"

# Angreifer mit 'ipset add blacklist <ip>' auf console hinzufügen!
# siehe auch: https://github.com/firehol/firehol/wiki/Working-with-IPSETs
# wobei ipset die liste 'mylist' bei einen Start von firehol erstellt, bei einen Neustart
# des Servers werden die IP's aus blacklist.txt wieder eingespielt.
ipv4 ipset create mylist hash:ip
ipv4 ipset addfile mylist blacklist.txt
ipv4 blacklist full ipset:mylist
#

interface4 eth1 mylan
   policy accept

interface4 eth0 internet
   server "smtp submission sieve http https imap meinssh" accept
   client all accept

# infos zu protection: https://firehol.org/firehol-manual/firehol-protection/
# siehe 'iptables -L -n | grep limit' mit und ohne protection
router4 mylan2internet inface eth1 outface eth0
   protection reverse strong
   protection strong
   masquerade
   route all accept

Sollte SSHguard auf dem Heimserver genutzt werden muss noch eine Anpassung im Startskript von SSHguard vorgenommen werden. Führe systemctl edit --full sshguard auf der console aus und erweitere den Abschnitt [Unit] mit folgender Zeile:

After:firehol.service

Normalerweise startet firehol nach SSHguard und schmeißt dadurch seine Iptables Regelsätze wieder raus. Mit diesen Eintrag im Startskript wartet SSHguard bis Firehol gestartet ist und hängt seine Regelsätze dran.

Der Standard: ufw

Installiere mit apt install ufw diese Firewall. Setze in /etc/default/ufw den Wert DEFAULT_FORWARD_POLICY=”ACCEPT”. Aktiviere in /etc/ufw/sysctl.conf den folgenden Parameter mit den Wert 1:

net.ipv4.ip_forward=1

Für ufw muss kein Parameter in der /etc/sysctl.conf geändert werden. Füge in /etc/ufw/before.rules direkt nach dem ersten Kommentarblock, folgende Zeilen ein: (achte auf Großschreibung und die Anpassung auf deinen IP Bereich!!)

*nat
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -s 192.168.1.0/24 -o eth0 -j MASQUERADE
COMMIT

Mit einem ufw disable und einem folgenden ufw enable ist das NAT und routing aktiv. Allerdings schließt ufw alle ports! Deswegen müssen auf der console anschließend die relevanten Dienste aktiviert werden, z.B.:

ufw allow tcp/53 (für DNS) ufw allow http (für Webserver) Starte den Rechner neu und prüfe mit iptables -L -n -t nat ob ein Wert mit MASQUERADE angezeigt wird. Wenn ja: alles ok und fertig.

Meine Meinung: Auch wenn ich eine Heilige Kuh angreife, aber die Bevormundung von ufw hat mich schon genervt. Wenn ich nur NAT und routing aktiviere, will ich auch nur NAT und routing. Das ich dann auch gleich die ganze Firewall einrichten muss, um arbeitsfähig zu sein, ist zwar bei ufw schnell erledigt, war aber nicht gewünscht.

Der Klassiker: Shorewall

Installiere mit apt install shorewall (nicht shorewall-lite!) diese Firewall. Setze in /etc/default/shorewall den Wert STARTUP=1. Für Shorewall muss kein Parameter in der sysctl.conf geändert werden.

Kopiere aus /usr/share/doc/shorewall/examples/two-interfaces (wenn Du zwei Netzwerkkarten im Server hast!) folgende Dateien in den Ordner /etc/shorewall:

interfaces, params, policy, rules, snat, stoppedrules, zones

Passe in der Datei ‘interfaces’ den Wert physical= an, wobei ‘loc’ (local) die Netzwerkkarte mit Verbindung zu deinen Heimnetz beschreibt und ‘net’ (internet) die Karte, welche mit dem Internet verbunden ist. Wenn auf deinem Server ein DHCP Dienst läuft – z.B. dnsmasq – dann lasse den Eintrag ‘dhcp’ an der Netzwerkkarte, die auch der DHCP nutzt. Dadurch bekommen die Clients eine IP Adresse.

In der /etc/shorewall/shorewall.conf wird der Wert von IP_FORWARDING=keep auf 'on' korrigiert.

Überprüfe, ob in der Datei ‘snat’ der Netzwerkbereich von deinem Heimnetz hinterlegt ist. Starte Shorewall jetzt mit shorewall start (beachte die Ausgabe!). Wenn keine Fehlermeldung erscheint, kann mit systemctl enable shorewall die Firewall aktiviert werden. Prüfe nach einen Neustart mit iptables -L -n ob die Standard Regelsätze von Shorewall geladen sind und mit iptables -L -n -t nat ob das Masquerade wirksam ist.

Genau wie bei Ufw ist damit der Server abgeriegelt, alle ports sind geschlossen! Jetzt sollten wir in der Datei /etc/shorewall/rules einige Ports öffnen. Der Aufbau der Regel ist einfach. Hier einige Beispiele:

DNS(ACCEPT) loc $FW
HTTP(ACCEPT) net $FW
HTTPS(ACCEPT) net $FW
SMTP(ACCEPT) net $FW
SMTP(ACCEPT) $FW net
IMAP(ACCEPT) net $FW

Beachte die Logik: Zugriffe auf den DNS Server aus dem ‘loc’alen Netz erlauben, wobei der DNS auf dem Server/der Firewall ($FW) läuft. Der Zugriff auf den Webserver(HTTP) aus dem Inter’net’ ist ebenso erlaubt.

Sollte der SSH port nicht auf dem Standard 22 sein, kann z.B. mit dieser Regel der SSH port auf 2222 geöffnet werden (beachte das Minus und Vergleiche die Werte mit der Spaltenbezeichnung in der Datei rules):

SSH(ACCEPT)    loc    $FW    -    2222

Nach einen Neustart sollte das NAT und routing mit Shorewall verfügbar ein. Aufgabe erfüllt.

Für die Nutzung von SSHguard mit Shorewall muss – entsprechend der Beschreibung im Abschnitt Firehol – der Befehl systemctl edit --full sshguard ausgeführt und folgender Parameter gesetzt werden: After=shorewall.service

Meine Meinung: Vergleichbar Ufw ist ein einfaches Aktivieren von NAT und routing mit Shorewall nicht möglich. Es erfordert auch gleich die Freigabe von relevanten Ports, um die routing Funktion auch nutzen zu können. Allerdings habe ich einige Jahre Shorewall auf meinen Heimserver genutzt und war immer sehr zufrieden! Interessant ist das Konzept von Shorewall: Aus den Konfigdateien im Ordner Shorewall kompiliert das Programm die entsprechende Konfiguration (siehe Ausgabe von ‘shorewall reload’) – ist die entsprechende Datei nicht im Ordner, gibt es die zugehörige Funktion in Shorewall nicht. Kurz: ohne die Datei snat – kein Masquerade. Ich kann Shorewall für weitergehende Aufgaben sehr empfehlen.

Hier noch eine optionale weitergehende Konfiguration, welche ein besseres logging und blacklisting von Angreifern mit ipset ermöglicht: (diese Einstellungen funktionieren mit Shorewall ab Version 5.1.1 / mit Ubuntu 18.04 getestet)

Die Standardwerte von Shorewall besagen, dass alles über den syslogd geloggt werden soll – damit landen alle Meldungen von Shorewall in /var/log/kern.log und machen das prüfen anderer Meldungen in dieser Datei etwas zäh. Eine Möglichkeit ist es, mit ulogd2 die Kernelmeldungen welche Shorewall betreffen, nach /var/log/ulog/syslogemu.log (default) umzuleiten. Dazu installieren wir folgendes Paket:

apt install ulogd2

und setzen in /etc/shorewall/shorewall.conf den Wert: LOG_LEVEL="NFLOG". Nach einem Neustart /var/log/shorewall-init.log beachten! Fertig.

Weitergehend können wir ein dynamisches blacklisting aktivieren. Ein statisches blacklisting meint, dass in der /etc/shorewall/rules Angreifer geblacklistet werden. Damit kann diese Datei bei vielen Angreifern sehr unüberschaubar und fehleranfällig werden. Eine gute Erläuterung der drei Möglichkeiten findet sich hier.

Das dynamische blacklisting von Shorewall nutzt ipset und damit das Datenpaket- Management des Kernels. Hört sich komplizierter an, als es zu konfigurieren geht! Fangen wir an:

apt install conntrack

Erstelle die Datei /etc/shorewall/blrules mit folgenden Inhalt: (beachte Großschreibung, wobei ‘net’ hier die Netzkarte mit Verbindung zum Internet beschreibt, s.o.)

#Action SOURCE DEST PROTO DPORT
BLACKLIST net:+blalist all

und setze in /etc/shorewall/shorewall.conf den folgenden Wert:

DYNAMIC_BLACKLIST=ipset-only,src-dst,disconnect,timeout=432000:blalist:info

wobei ipset-only nur das blacklisting mit ipset erlaubt (also kein statisches blacklisting), src-dst und disconnect bestimmt, dass bestehende Verbindungen des Angreifers zum Server (aus dem Lan wie auch aus dem Internet) beendet werden. Die timeout Funktion begrenzt das blacklisting (in Sekunden, frei wählbar) hier auf 5 Tagen. Ipset soll die Liste mit Namen blalist (Namen frei wählbar) erstellen und nutzen. Letztlich werden blacklisting Aktionen mit Level info geloggt.

Jetzt müssen wir noch dafür sorgen, dass nach einen Neustart die erstellte blacklist noch vorhanden ist: Dafür setzen wir in shorewall.conf den Wert SAVE_IPSETS=yes. Ein ‘service shorewall restart’ aktiviert die Konfiguration, prüfe mit dem Befehl ipset list ob die Liste blalist angelegt wurde und füge mit folgenden Befehl Angreifer hinzu:

shorewall blacklist <ip>

und mit

shorewall allow <ip>

werden Angreifer wieder von der Liste entfernt – oder nach 5 Tagen (siehe oben). Nach dem hinzufügen eines Angreifers ist keine weitere Aktion notwendig! Prüfe nach einen Neustart der Firewall die Datei /var/log/kern.log bzw. /var/log/ulog/syslogemu.log. Fertig.

Ein älterer Artikel von mir mit detailierteren Infos zu Shorewall findet sich im blog.

RedHat/Fedora Style: firewalld

Installiere mit apt install firewalld diese Firewall. Für firewalld sind keine Anpassungen in der /etc/systemctl.conf notwendig. Zur Konfiguration muss firewalld gestartet sein.

Firewalld hat beim Booten des Ubuntu Servers andere Netzwerkdienste ausgezählt – die Dienste (z.B. dnsmasq) waren nach dem booten nicht aktiv. Mir ist es nicht gelungen, (in der Eile) eine brauchbare Boot- Konfiguration hinzubekommen. Wobei die nicht-gestarteten Dienste, per händischen Starten nach dem booten, problemlos starteten.

Firewalld bringt verschiedene Zonen mit, die an ein Netzwerkdevice gebunden werden. Für das Internet Device habe ich die Zone ‘external‘ gewählt, weil diese Zone NAT und Routing (‘masquerade’) mitbringt. Die Zone ‘internal’ wurde an die Netzwerkkarte mit Kontakt zum Heimnetz gebunden (ohne die Option –permanent können Werte auch erst einmal gesetzt werden, sind aber nach einem booten wieder weg):

firewall-cmd --zone=external --permanent --change-interface=eth0
firewall-cmd --zone=internal --permanent --change-interface=eth1

Zeigt die Optionen der gewählten Zonen:

firewall-cmd --list-all --zone=external
firewall-cmd --list-all --zone=internal

Prüfe die Zuweisungen mit:

firewall-cmd --get-active-zone

Und ein systemctl enable firewalld aktiviert den Dienst. Aber auch firewalld macht mit der Aktivierung dieser Zonen, die Firewall in alle Richtungen zu. Mit folgenden Befehl kann ein Dienst in firewalld für die jeweilige Zone aktiviert werden – hier also dhcp und dns aus dem Lan auf die Serverdienste für einen rudimentären Betrieb:

firewall-cmd --zone=internal --permanent --add-service=dhcp
firewall-cmd --zone=internal --permanent --add-service=dns

Ein systemctl restart firewalld aktiviert die erweiterte Konfiguration und firewall-cmd --list-all (wie oben beschrieben) zeigt Admina die Einstellungen der Zonen an.

Meine Meinung: Die Organisation der Firewall durch Zonen – die auch selbst erstellt werden können – und die einfachen (und merkbaren) Befehle finde ich super. Außerdem gibt es auch eine GUI für diese Firewall. Eigene Services sind in .xml einfach zu definieren. Allerdings gab es bei meinen Schnelltest Nervereien beim booten. Sollte also firewalld auf einen Ubuntu System eingesetzt werden, ist hier in Verbindung mit andern Netzwerkdiensten, mit Nacharbeit zu rechnen.

Fazit

Ich war in den Vorarbeiten zu diesen Vergleich von Firehol begeistert. Es bietet eine einfache NAT/routing Aktivierung, läßt sich schön in einer(!) Konfig- Datei ausbauen, harmoniert ohne Umwege mit SSHguard und mit der Performance der initial gesetzten Regelsätze bin ich sehr zufrieden. Wer sich dann noch mit ipset für blacklisting beschäftigt hat ein schönes Werkzeug.

Shorewall ist immer ein Versuch wert, wenn eine umfangreiche Konfiguration notwendig ist. Alle Konfigdateien in einen Ordner, einfacher Aufbau der Konfigdateien, performantes Routing sowie ein Webmin Modul für eine mögliche grafische Konfiguration, machen diese Firewall sehr greifbar. Die ipset Liste wird automatisch von Shorewall gesichert – bei Firehol muss händisch umständlich in eine Datei gesichert werden. Nach langen Jahren im Einsatz, kann ich sagen, dass Shorewall ein zuverlässiges Tool ist.

UFW als der Standard unter Ubuntu ist ebenfalls ein solides Werkzeug. Einfache Kommandos auf der console führen schnell zu brauchbaren Ergebnissen. Allerdings finde ich – rein subjektiv – das routing im Vergleich zu Firehol und Shorewall etwas stockender, lahmer. Vielleicht kann da jemand mal Vergleichsmessungen machen – die Ergebnisse füge ich gerne diesen Artikel hinzu.

Letztlich will ich natürlich nochmal für SSHguard werben. Den SSH port (und auch andere) absichern, einfach durch Installation ohne eine Konfiguration ist schon eine feine Sache. Auch das SSHguard direkt den journal stream mitliest – und nicht die Logdatei – finde ich ein interessantes und performantes Konzept. Einfach mal installieren. Ein ausführlicher Artikel zum tool findet sich im blog.

Von simpelst zu komplexer – so kann Admina diese Auflistung verstehen. Die ‘optionalen weitergehenden Konfigurationen’ im Text sollen nur Hunger auf ein weiteres Experimentieren mit diesen Firewalls machen. Wie gesagt, es ging mir nicht um eine umfassende Firewall Konfiguration, sondern rein um eine einfache Realisierung von NAT und routing. Übrigens: einen einfachen Portscan findet sich hier.

Andere Firewall Projekte die Regelsätze mit Iptables erzeugen und damit NAT/Masquerade ermöglichen: uif, ferm, arno-iptables-firewall . Diese Projekte sind aktuell (Stand: Oktober 2018) und in Ubuntu 18.04 über apt installierbar.

Have fun.

---