Einführung

Für den einfachen Heim-User und manche Kleinst-KMUs reicht meistens das Kombigerät des Internet-Anbieters kombiniert mit der Windows Defender Firewall als minimaler Schutz. Für erweiterte Bedürfnisse wie z.B. Fernzugriff von aussen (VPN, Port-Forwarding/DNAT auf interne Server) für Ihre KMU-oder erweiterte Heim-Lösung braucht es dann eine enstprechend auch erweiterte Firewall-Lösung.

Meine Empfehlungen für den produktiven Einsatz

Da immer mehr Daten und Produkte direkt in der Cloud (sprich im Internet) gespeichert und ausgeführt werden, ist oft nur nur ein guter Internet-Zugang von innen (Büro-Netz, Heim-Netz) nach aussen (Internet) wichtig. Hier sollte man bei extremer Abhängigkeit auch immer einen Plan-B (zweiter Anbieter angeschlossen oder vielleicht auch nur Mobile/Hotspot) haben.

Natürlich gibt es viele Out-of-the-box Lösungen z.B. von Zyxel, Cisco und vielen weiteren Anbietern, welche schon für wenig Geld oft ausreichend und einfach in der Handhabung sind.

Teurer werden solche Box Lösungen meist, wenn man viel Leistung für VPN oder sehr viele gleichzeitige Verbindungen braucht: schnelle VPN Verbindungen brauchen schnelle Verschlüsselung und damit Rechenleistung. In solchen Fällen können aber auch Setups mit Standard PC/Server Hardware sehr attraktiv und günstig sein mit noch mehr Leistung als viele Box Lösungen. In Kombination mit dem richtigen Software Setup hat man dann eine mächtige und performante Lösung.

Verschiedene Distributionen bieten heute sehr schnell und einfach sehr mächtige und gute Firewall-Setup an für solche Standard Hardware. Persönlich kann ich z.B. pfsense (https://www.pfsense.org/download/) sehr empfehlen. Diese lässt sich z.B. auch perfekt direkt oder virtuell (Server aufgeteilt), auf beliebiger Intel (x86/amd64) kompatibler Hardware oder auf kleinen, günstigen, stromsparenden und dennoch leistungsfähigen Kompakt-Lösungen (http://pcengines.ch/apu2.htm) installieren. pfSense selbst verkauft ausserdem auch sehr starke Komplett-Lösungen (Lieferung auch in die Schweiz meist innerhalb weniger Tage), welche ich aus Erfahrung ebenfalls empfehlen darf, besonders für hohe VPN Leistungen in Kombination mit kompakter und stromsparender Hardware: https://www.pfsense.org/products/ (nein, ich bekomme keine Provision).

Hintergrundwissen: FH Arbeit von 2002

Ein Blick „hinter die Kulissen“ auf die Grundfunktionsweise einer Firewall kann helfen, das Verständnis zu vertiefen oder zu verbessern. Hierzu kann dieser ältere Bericht hier aus meiner Studiumszeit helfen, denn die hier erwähnten Prinzipien gelten noch immer und sind bei den meisten Firewall-Lösungen sogar fast eins-zu-eins so im Hintergrund noch umgesetzt, egal ob Box- oder Software-Lösung (auf Standard Hardware), auch wenn gewisse Produkte und Links möglicherweise so nicht mehr existieren, da der Bericht unverändert hier übernommen ist.

unser Beispiel Netzwerk heisst: olymp.hst.fhso.ch

Bericht: (C) 2002 by Martin Müller, Tobias Weibel FHSO, CH-4702 Oensingen
Kommentar/Ergänzung: April 2019

Firewall / Gateway

Zu diesem Bericht

Der Bericht besteht aus mehreren Teilen:

Zuerst werden die Voraussetzungen und der Ablauf beschrieben. Danach werden dann die konkreten Befehle aufgeführt. Im Anhang sind Netzwerkdiagramme abgebildet, welche eine Übersicht über unser konkretes Netzwerk geben.

Einführung

Der Gateway stellt die Kommunikation zwischen dem lokalen und dem externen Netzwerk/Internet her. Die Firewall filtert die ein- und ausgehenden Pakete nach definierten Regeln. VPN (Virtual Private Network) dehnt das lokale Netzwerk logisch auf entfernte Rechner aus.

Soft- und Hardware Voraussetzungen

Ein Gateway benötigt mindestens zwei Netzwerkschnittstellen. Dies können Netzwerkkarten, ISDN Adapter oder gar Modems sein.

Die Firewall- und Gateway-Funktionen lassen sich mit den Standardpackages unter Linux Kernel 2.4.x und höher realisieren. Für den VPN Server verwenden wir den pptpd (PPTP Deamon) von PoPToP (http://poptop.lineo.com/).

Der Gateway

Der Gateway in unserem Fall erfüllt zwei Aufgaben:

-Übersetzen und Weiterleiten von internen Packeten nach aussen

-Übersetzen und Weiterleiten von externen Packeten zu den internen Servern

Verbindungen nach aussen

Will ein Client mit Rechnern ausserhalb des lokalen Netzwerkes kommunizieren, braucht er bekanntlicherweise einen Gateway welcher die Verbindung zu weiteren Netzen anbietet.

Um mit der ganzen Welt kommunizieren zu können, braucht jeder Teilnehmer eine eigene, einzigartige Public IP Adresse.

In unserem Fall steht uns nur eine Public IP für den Gateway zur Verfügung. Das bedeutet, dass jedes Paket, welches das lokale Netzwerk verlässt vom Gateway mit seiner Adresse als Quelle (Sender) versehen werden muss (Source Network Address Translation, SNAT). So finden die Pakete sicher wieder zurück.

Will jetzt ein Rechner eine Vebindung nach aussen herstellen, läuft dies folgendermassen:

Der Rechner stellt fest, dass die gewünschte Zieladresse ausserhalb des lokalen Netzwerkes ist. Er benutzt daher den Gateway.
Der Gateway enthält die Regel, dass er alle Pakete aus dem lokalen Netzwerk mit seiner Adresse als neuen Sender versehen muss.
Der Gateway benutzt für diese Verbindung einen neuen Port auf seinem Public IP Interface.
Er notiert sich in einer Tabelle, welche interne IP Adresse zu welchem Port gehört.
Die Pakete verlassen erfolgreich das lokale Netzwerk.
Zurückkommende Pakete treffen wieder am gleichen Port ein und die Zieladresse kann mittels der Tabelle wieder zurück übersetzt werden.
Die Pakete werden daraufhin an den entsprechenden Rechner weitergeleitet.

Einkommende Pakete werden als aller erstes (zurück-)übersetzt (PREROUTING), bevor irgend etwas weiteres (z.B. Filterung) mit ihnen geschieht. Das Umgekehrte (als aller letztes, POSTROUTING) geschieht beim Hinausgehen.

Verbindungen von Extern zu lokalen Servern

Da wir wie bereits erwähnt nur eine Public IP zur Verfügung haben, können Verbindungen von Aussen nur auf diese Adresse gemacht werden. Um nun trotzdem die Dienste der lokalen Server der Aussenwelt anbieten zu können, müssen diese Dienste auf den Gateway (und damit auf die Public IP) „gemappt“ werden:

Wird z.B. von Aussen eine Verbindung mit dem Webbrowser (http, Port 80) auf unsere Public IP verlangt, soll diese Anfrage natürlich nicht vom Gateway selbst beantwortet werden. Stattdessen kennt der Gateway eine Regel, welche ihn anweist, Verbindungen auf Port 80 an den Webserver weiterzuleiten. Er nimmt dazu eine Übersetzung der Zieladresse und evtl. des Zielports (Destination Network Address Translation, DNAT), auch Portmapping genannt, vor. Danach wird das Paket ganz normal weitergeleitet. Das DNAT wird im PREROUTING durchgeführt.

Der Firewall

Der Firewall ist in unserem Fall ein simpler aber effektiver Paketfilter. Firewallprodukte von Drittherstellern, z.B. Firewall-1 von ChechPoint, erfüllen noch weit mehr Aufgaben (z.B. Virenfilterung). Der Paketfilter entscheidet nach einfachen Regeln, was mit dem entsprechenden Paket gemacht wird.

Der Aufbau

Das zuständige Modul unter Linux heisst ip_tables. Bei ip_tables werden die Regeln in sogenannten chains (Tabellen, in welchen die Reihenfolge der Regeln von Bedeutung ist) abgelegt. Hineinkommende Pakete werden vom Kernel automatisch in die incoming bzw. forward chains geleitet. D.h. Alle Filterregeln setzten hier an.

Im Normalfall ist es nur erforderlich, die hineinkommenden (incoming) und die weiter zu leitenden Pakete (forward) anzuschauen. Outgoing wären Pakete, welche wirklich vom Firewall selbst kommen.

Wie oben schon erwähnt, werden die Network Address Translation (Destination NAT) im PREROUTING durchgeführt. Das bedeutet, dass sich die Filterregeln auf die bereits übersetzten Adressen beziehen (Beispiel siehe weiter unten bei den Commands).

VPN Server

Anmerkung (MM 04.2019): PPTP gilt seit ein paar Jahren als nicht sicheres VPN Protokoll. L2TP oder IPSec generell sowie HTTPS basierte VPN (z.B. OpenVPN) Verbindungen werden empfohlen.

Es gibt viele Möglichkeiten für eine VPN Verbindung. Die einfachste, welche auch mit Windows Clients relativ problemlos funktioniert, ist PPTP (Point-To-Point-Tunneling-Protocoll). Dieses erstellt nach erfolgreichem Herstellen einer TCP Kontrollverbindung auf Port 1723 den eigentlichen Datentunnel mit dem speziellen Protokoll 47 (GRE, Generic Routing Protocol) her. Die logische Verbindung durch diesen Tunnel erfolgt dann mit PPP (Point to Point Protocoll, das gleiche wie bei einer Modemverbindung). Somit ist das Verhalten und die Anwendung gleich zu setzen mit einer Einwahl-Verbindung in ein fremdes Netzwerk. D.h. der Client kann dann normalerweise auf alle Netzwerk-Ressourcen zugreiffen, als ob er lokal am Netzwerk angeschlossen wäre.

Sollen die Daten verschlüsselt (MS Point to Point Encryption, kurz MPPE) übertragen werden, so ist dies die Aufgabe des PPP. D.h. es muss entsprechend ein PPP mit Verschlüsselung eingesetzt werden (verlangt im Normalfall auch gepatchten Kernel). Der Einfachheit halber wird hier nur das Kennwort zur Authentifizierung verschlüsselt, nicht jedoch der Datenkanal. D.h. die Verbindung funktioniert zwar, ist jedoch nicht gegen Lauschangriffe gesichert.

Konfiguration siehe weiter unten.

Gateway aufsetzen

Wie schon erwähnt, wird ausser einem Linux mit Kernel 2.4.x keine weitere Software benötigt.

Aktivieren der Paketweiterleitung

Um die Pakete weiter zu leiten wird eine einzige Kommandozeile benötigt:

echo 1 > /proc/sys/net/ipv4/ip_forward

Dieses Kommando schreibt „1“ (also aktiv, true) in die Datei /proc/…/ip_forward. Da proc ein spezielles Dateisystem von aktuell laufenden Prozessen ist, wird dieser Eintrag auch sofort gültig.

Weiter sollte sichergestellt werden, dass der Gateway selbst bei sich den richtigen default gateway zur Aussenwelt (bei uns 193.135.242.1) eingestellt hat:

route add default gw 193.135.242.1

Installieren vom ip_tables Kernel Modul

Für das ganze Packet Management, vom Übersetzen, Weiterleiten bis zum Filtern ist das Kernel Modul ip_tables zuständig.

ip_tables verträgt sich nicht mit ipchains, welches vor allem beim Kernel 2.2.x eingesetzt wurde, z.T. aber auch bei den 2.4.x Distributionen installiert wird.

Um also sicher zu gehen, entladen wir zuerst ipchains und laden danach ip_tables:

(Kommandozeilen sind in Couriergeschrieben)

rmmod ipchains

hier sollte die Antwort „rmmod: module ipchains is not loaded“ oder keine Antwort kommen.

modprobe ip_tables

hier sollte keine Antwort kommen.

Nun sind sämtliche NAT und Filter Regeln mit dem Befehl iptables konfigurierbar.

Mit iptables –L werden z.B. die aktuellen Filterregeln angezeigt.

Erstellen der SNAT Regel

Die NAT Regeln sind in einer speziellen Tabelle von iptables abgelegt. Mit iptables –t nat –L kann der aktuelle Inhalt (die drei Standardketten PREROUTING, POSTROUTING und OUTPUT) angezeigt werden.

Nun erstellen wir die Regel, dass bei allen Verbindungen, welche über das Internet-Interface (hier eth0) hinausgehen (outgoing –o) und aus unserem lokalen Netzwerk 172.27.1.0/24 sind, die Quelladresse (source) auf unsere Public IP 193.135.242.80 übersetzt wird (eine Zeile):

iptables –t nat –A POSTROUTING –o eth0 –s 172.27.1.0/24 –j SNAT –to 193.135.242.80

Die zwei fett markierten Kommandozeilen sind im Prinzip bereits alles, was der Gateway zum richtigen Weiterleiten von internen Verbindungen nach Aussen braucht.

Erstellen der DNAT (Portmapping) Regeln

Als Beispiel sei hier nur die Regel aufgeführt, welche den hineinkommenden Verkehr für den Webserver (TCP, Port 80) an den Webserver (172.27.1.18) weiterleitet.

Übersetzt werden auch hier nur Pakete, welche über die Internetschnittstelle (hier eth0) hineinkommen (eine Kommandozeile):

iptables –t nat –A PREROUTING –i eth0 –d 193.135.242.80 –p tcp –dport 80 –j DNAT –to 172.27.1.18:80

Firewall aufsetzen

Auch die Filterregeln für den Firewall werden mit iptables konfiguriert. Im Unterschied zu den SNAT/DNAT Regeln sind diese in der Standard Tabelle (filter) abgelegt.

Filter definieren

Generell wollen wir sämtliche Verbindungen von Aussen „droppen“, das heisst, wir schmeissen die Pakete einfach fort. Der Vorteil gegenüber block ist, dass der Sender nicht feststellen kann, ob die Pakete überhaupt irgendwo angekommen sind.

Wir erstellen zwei benutzerdefinierte Tabellen (auch chains genannt):

Die Tabelle block, schmeisst alle Pakete fort
Die Tabelle allow, akzeptiert gezielt einzelne Verbindungen

Die Pakete werden zuerst durch die Tabelle allow abgehandelt. Wird keine zutreffende Regel gefunden, kommt die Tabelle block zum Zuge.

Die Tabelle block erstellen:
iptables –N block

Der Tabelle block den LOG und DROP Eintrag hinzufügen
iptables –A block –j LOG –log-prefix „FW DROP: “ –log-level info
iptables –A block –j DROP
Hinweis: Bei den meisten Distributionen werden nun die LOG Meldungen auch auf die lokale Konsole ausgegeben. Dies ist natürlich sehr störend und kann folgendermassen behoben werden:
Dem Kernel-Logdeamon (klogd) muss die Option -c3 mitgegeben werden. Bei den meisten Distributionen können Optionen im init Script (/etc/init.d/klogd) eingetragen werden. Danach Neustart des klogd.

Die Tabelle allow erstellen:
iptables –N allow

Alle bereits bestehenen Verbindungen sollen weitergeführt werden können:
iptables -A allow -m state –state ESTABLISHED,RELATED -j ACCEPT

Lokale Programme dürfen auf den localhost unbeschränkt zugreiffen.
iptables -A allow -s 127.0.0.1 -d 127.0.0.1 -j ACCEPT

Wir wollen alle Verbindungen zulassen, welche vom lokalen Netzwerk (eth1) nach aussen gehen:
iptables -A allow -m state –state NEW -i eth1 -j ACCEPT

ICMP Programme wie z.B. ping oder traceroute werden nur vom local Network auf diese Maschine zugelassen:
iptables –A allow –p icmp –i eth1 –j ACCEPT

HTTP Zugriffe (Port 80) zum Webserver (172.27.1.18) erlauben:
iptables -A allow -p tcp -d 172.27.1.18 –dport 80 -j ACCEPT

Für das VPN sind folgende zwei Regeln notwendig. Mit „–p 47“ wird das Protokoll nr. 47 (GRE, von PPTP verwendet) ausgewählt:
iptables -A allow -p 47 -d 193.135.242.80 -j ACCEPT
iptables -A allow -p tcp -d 193.135.242.80 –dport 1723 -j ACCEPT

Standardmässig gibt es nur die „chains“ INPUT und FORWARD. Damit der Linux-Kernel nach unseren Regeln arbeitet, muss aus diesen chains zu unseren gesprungen werden:
iptables -A INPUT -j allow
iptables -A INPUT -j block

iptables -A FORWARD -j allow
iptables -A FORWARD -j block

VPN Server konfigurieren

Wie oben erwähnt, spielen zwei Komponenten beim PPTP mit: der PPTP (VPN) Server (pptpd) und der PPP Server (pppd). Der pppd wird vom pptpd automatisch gestartet, sobald eine Verbindung hergestellt werden soll.

Das Konfigfile für den pptpd ist in /etc/pptpd.conf, das pppd Konfigfile in /etc/ppp/options und ppp/chap-secrets für die Benutzer/Passwörter.

Die Einstellungen im pptpd.conf sind kurz:

speed 115200	Pseudo Speed Einstellung
localip 172.27.1.220-229	Der zu benutzende IP-Range Serverseitig
remoteip 172.27.1.230-239	Der zu benutzende IP-Range Clientseitig

Im ppp/options können deutlich mehr Einstellungen vorgenommen werden:

debug	Debug Meldungen ins System Log
name ares.olymp.hst.fhso.ch	Servername (identisch in ppp/chap-secrets)
auth	Authentikation erforderlich
require-chap	Authentikationstyp MS-Chap
proxyarp	ARP Eintrag für Remote-IP beim Server
ms-dns 172.27.1.2	DNS Server Adresse an Windows Client senden
netmask 255.255.255.0	Netzmaske an Client senden (default: 4×255)

Im ppp/chap-secrets werden gewünschte User/Passwörter für den VPN Zugriff eingetragen:

lysche ares.olymp.hst.fhso.ch 123 *
(User Servername Passwort erlaubte Client-IP, * = any)

Im ppp/ip-up (bzw. ip-down) Script sollte noch die Firewall Regel hinzugefügt werden welche den VPN Verbindungen (ppp0…pppX) unbeschränkte Kommunikation erlauben:

iptables -A allow -m state –state NEW -i $INTERFACE -j ACCEPT

wobei $INTERFACE im Script bei unserer SUSE (7.2) Version des PPPD das soeben geöffnete Interface bezeichnet. Im ip-down Script wird beim gleichen Kommando das A durch ein D ersetzt.

Beim Windows-Client müssen folgende Parameter in den VPN Settings beachtet werden:

Hostname/Ziel-IP: z.B. 193.135.242.80 oder der DNS Name
Sicherheit: „Datenverschlüsselung erforderlich“ deaktivieren
Netzwerk:
- Typ des Servers: PPTP
- TCP-Einstellungen (Erweitert):
  „Standardgateway des Remotenetzwerks verwenden“ deaktivieren
  (optional; bedeutet, dass der restliche Netzwerkverkehr nicht durch den VPN Tunnel gehen soll)
  DNS-Suffix für diese Verbindung: z.B. olymp.hst.fhso.ch
Beim Verbindungsaufbau wird ein gültiger Benutzername und Passwort verlangt (aus ppp/chap-secrets).

PPTP Server starten

Der PPTP Server (pptpd) kann nach erfolgreicher Installation einfach durch das nächste Kommando gestartet werden:

/usr/local/sbin/pptpd

Vor dem Start, sollten gestartete pptp- und ppp-Deamon’s gestoppt werden, damit Fehler beim Start von pptpd vermieden werden. Mit folgenden Kommandos kann dies erreicht werden.

killall pptpd

bzw.

killall pppd (sollte normalerweise nicht laufen, ausser bei bestehender Verbindung)