Eine Empfehlung zu Begin:
Verschiedene Distributionen bieten heute sehr schnell und einfach sehr mächtige und gute Firewall-Setup an.
Persönlich kann ich z.B. pfsense (https://www.pfsense.org/download/) sehr empfehlen. Diese lässt sich z.B. auch perfekt virtuell, 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: https://www.pfsense.org/products/.
Natürlich braucht es trotz allem ein Grundverständnis für die Funktionsweise, wobei dieser Artikel helfen kann. Die hier erwähnten Prinzipien gelten nämlich noch immer, auch wenn gewisse Produkte und Links möglicherweise so nicht mehr existieren.
unser Beispiel Netzwerk heisst: olymp.hst.fhso.ch
Bericht: (C) 2002 by Martin Müller, Tobias Weibel FHSO, CH-4702 Oensingen
Last updated: 09. Februar 2017
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 Address Translation 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
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)