1. Paketfilter

Eine Firewall kontrolliert und filtert Datenpakete zwischen Netzen. Sie stellt sozusagen einen kontrollierten Übergang dar und soll die Weiterleitung von Paketen verhindern, die eine mögliche Bedrohung für die Daten und Komponenten eines Netzwerks bedeuten könnten. Anhand eines Regelwerks wird der Datenverkehr überwacht und entschieden, ob bestimmte Netzwerkpakete passieren dürfen oder nicht.

Das OpenWrt-Projekt integriert den Paketfilter netfilter/iptables, um den Datenverkehr innerhalb der Zonen bzw. über die Zonen hinaus zu filtern. Über die LuCI-Weboberfläche oder die Kommandozeile können neue Firewallregeln angelegt, verändert oder gelöscht werden.

Im vorliegenden Beitrag möchte ich euch das Hinzufügen von Firewallregeln vorstellen, um den ausgehenden Datenverkehr zu filtern. Clients im internen Netzwerk sollen nur jene Dienste im WAN/DMZ bzw. Internet erreichen können, die auch tatsächlich benötigt werden. Alle anderen Pakete werden vor der Weiterleitung verworfen.

Dieser Beitrag ist Teil einer Artikelserie:

2. Firewall Mini-Guide

Unterstütze den Blog mit einem Dauerauftrag!

Unabhängig. Kritisch. Informativ. Praxisnah. Verständlich.

Die Arbeit von kuketz-blog.de wird vollständig durch Spenden unserer Leserschaft finanziert. Sei Teil unserer Community und unterstütze unsere Arbeit mit einer Spende.

Mitmachen ➡

2.1 Personal-Firewall vs. Netzwerk-Firewall

Die Konfiguration der OpenWrt-Firewall erfolgt auf dem Router. Wir arbeiten also mit einer sog. Netzwerk-Firewall, die im Gegensatz zur Personal-Firewall nicht auf dem zu schützenden System selbst arbeitet. Netzwerk-Firewalls schützen im Normalfall also mehrere Clients, während die Personal-Firewall direkt auf dem Client installiert und konfiguriert wird. Beide Varianten haben ihre Vor- und Nachteile und sollten grundsätzlich parallel verwendet werden. Personal-Firewalls bringen bspw. oftmals noch einen Anwendungsfilter mit, der es erlaubt, den Datenverkehr für jede Anwendung separat bzw. feingranular zu definieren.

Noch ein grundsätzlicher Hinweis: Die Funktion einer Firewall besteht nicht darin, Angriffe zu erkennen, sondern ausschließlich in der Anwendung der definierten Regelsätze.

2.2 Blacklist- vs. Whitelist-Prinzip

Die Schutzwirkung, die sich mithilfe einer Firewall erreichen lässt, hängt zu einem hohen Grad von einer sachgemäßen Konfiguration ab. Generell werden zwei unterschiedliche Konfigurationsansätze unterschieden:

Blacklist: Erlaubt ist alles, was nicht ausdrücklich verboten ist
Whitelist: Verboten ist alles, was nicht ausdrücklich erlaubt ist

Ich empfehle grundsätzlich das Whitelist-Prinzip. Es werden also nur jene Verbindungen nach außen zugelassen, die explizit erlaubt sind – alles andere wird verworfen. Nicht nur bei einer Firewall, sondern auch in anderen Bereichen der IT, ist das Whitelist-Prinzip oftmals dem Blacklist-Prinzip vorzuziehen.

2.3 Regelwerk

Das Regelwerk einer Firewall umfasst alle Regeln, wie mit einem Netzwerkpaket verfahren werden soll. Regeln werden für jedes Paket der Reihe nach geprüft und die erste zutreffende Regel angewendet. Die Reihenfolge der Regeln ist daher äußerst relevant. Firewall-Regeln setzen sich meist aus unterschiedlichen Informationen bzw. Komponenten zusammen:

Bezeichnung
Absender-IP-Adresse
Empfänger-IP-Adresse
Transport- bzw. Netzwerkprotokoll (TCP, UDP, ICMP etc.)
Port-Nummer
Aktion (erlauben, verwerfen oder ablehnen)
Protokollieren (ja/nein)

Jede Regel umfasst eine Aktion bzw. Handlung, die eine Firewall entsprechend der Konfiguration durchführt. Meist können folgenden Aktionen definiert werden:

DROP / DENY: Das Paket wird verworfen, also nicht durchgelassen, ohne weiter darauf zu reagieren.
REJECT: Das Paket wird verworfen und dem Absender wird mitgeteilt, dass die Verbindung abgelehnt wurde.
ACCEPT: Die Netzwerkanfrage ist erlaubt und wird durchgelassen.
FORWARD: Die Netzwerkanfrage ist erlaubt und wird weitergeleitet.

Als Beispiel eine OpenWrt-Regel, die Clients den Zugriff auf Webserver via Port 80 (HTTP) und 443 (HTTPS) erlaubt:

HTTPS-Regel

Nehmen wir uns mal ein paar Bestandteile der Regel vor:

Name: Die Bezeichnung ist frei wählbar. Generell finde ich es empfehlenswert diese so zu wählen, dass auf den ersten Blick ersichtlich ist, welche Ports bzw. Ziele / Quellen gefiltert werden.
Protocol: Das Transportprotokoll ist abhängig vom gewählten Anwendungsprotokoll bzw. der Gegenstelle. HTTP bzw. HTTPS funktioniert ausschließlich über TCP, da es auf ein zuverlässiges Transportprotokoll angewiesen ist.
Source zone: Die Quelle der ausgehenden Datenverbindungen ist im Beispiel die Zone WiFi – also alle Geräte, die der Zone WiFi zugeordnet sind bzw. mit dem WiFi-Interface verbunden sind.
Source address: Bei Quell-IP-Adresse ist any ausgewählt. Das bedeutet: Jedem Client aus der Zone WiFi ist der Zugriff auf HTTP-Webserver über die Ports 80 bzw. 443 erlaubt. Man könnte hier auch eine Einschränkung auf bestimmte IP-Adressen vornehmen, um bestimmten Clients den Zugriff zu verwehren.
Destination zone: Pakete, die keine private IP-Adresse des lokalen Netzwerks zum Ziel haben, werden über die Zone WAN ins Internet bzw. an das Gateway geschickt. Möchten wir also öffentliche Webserver erreichen, müssen wir als Zone wan wählen.
Destination address: Da die Clients grundsätzlich alle öffentlichen Webserver im Internet erreichen sollen, nehmen wir keine Beschränkung vor und konfigurieren das Ziel als any.
Destination port: Gemäß der Spezifikation bzw. der Liste mit standardisierten Ports lauscht ein Webserver auf Port 80 bzw. 443.
Action: Abschließend wird der Zugriff bzw. die Weiterleitung der Anfrage von internen Clients auf öffentliche Webserver mit der Aktion accept erlaubt.

Hinweis

Die in OpenWrt eingesetzte Firewall ist ein einfacher Paketfilter, der Filter-Entscheidungen auf Basis der Header-Informationen von Netzwerkpaketen trifft.

3. Ausgehenden Datenverkehr filtern

Dank der LuCI-Weboberfläche ist die Konfiguration von Firewall-Regeln im Grunde genommen relativ simpel. Unter Network -> Firewall -> Traffic Rules sind bereits ein paar Standardregeln angelegt. Diese könnt ihr so belassen und eure eigenen ergänzen. Dabei solltet ihr euch die folgenden Fragen stellen:

Welche Dienste bzw. Ports sollen die Clients aus der Zone LAN, WIFI etc. erreichen können?
Sollen alle Clients einer Zone Zugriff auf bestimmte Dienste wie Web- oder E-Mail-Server haben oder soll der Zugriff auf einige Clients beschränkt werden?

Solltet ihr Dienste bzw. Ports vergessen, ist das nicht weiter schlimm. Diese könnt ihr jederzeit ergänzen. Was allerdings ein Problem darstellen könnte: Ihr vergesst schlichtweg, dass die OpenWrt-Firewall aktiv ist bzw. alle ausgehenden Datenpakete verwirft, die nicht explizit erlaubt sind. Sollte also ein clientseitiges Problem auftreten, könnte unter Umständen auch die Firewall als Fehlerquelle infrage kommen – das solltet ihr stets im Hinterkopf behalten.

Letztendlich gibt es kein Patentrezept bzw. jede Firewall-Konfiguration wird vermutlich anders aussehen. Im Folgenden möchte ich euch eine Art »Grundgerüst« vorstellen. Ihr könnt es als Vorlage nehmen bzw. auch beliebig erweitern. Die mitgelieferten Standardregeln sind auf dem Screenshot nicht enthalten und befinden sich in der Reihenfolge über den ergänzten Regeln:

Traffic-Rules

Die dargestellte Konfiguration bezieht sich auf Clients der Zone WIFI. Neben Standardregeln wie HTTP- und SMTPS- bzw. IMAPS-Verkehr sind auch Regeln zum Aufbau einer OpenVPN- und Wireguard-Verbindung enthalten. Die wohl wichtigste Regel steht ganz am Ende und ist rot markiert. Diese »Block all« Regel sorgt dafür, dass alle Pakete, auf die die zuvor aufgelisteten Regelsätze nicht zutreffen, verworfen werden. Ohne diese Abschlussregel würde jeglicher Verkehr (ins Internet) erlaubt sein.

3.1 Logging von Rejected-Paketen

Zurückgewiesene (engl. rejected) Pakete könnt ihr euch bei Bedarf im Syslog anzeigen lassen. Das ist bspw. dann notwendig, wenn eine Anwendung nicht funktioniert und ihr herausfinden möchtet, welche Ports ihr öffnen müsst. Wichtig: Die »Block all« Regel muss unter Action auf reject eingestellt werden. Stellt ihr die Action auf drop können keine Pakete geloggt werden. In der oben dargestellten Beispiel-Konfiguration ist die letzte Regel auf »Reject« eingestellt.

Ist diese Voraussetzung erfüllt müsst ihr das Logging am WAN-Interface aktivieren. Klickt dazu auf Network -> Firewall -> General Settings. Bei Zones sucht ihr die Zeile der WAN-Zone und klickt rechts in der Zeile auf den Button Edit. Unter dem Tab Advanced Settings setzt ihr anschließen das folgende Häkchen:

Logging aktivieren

Über das Menü Status -> System Log könnt ihr die Rejected-Pakete anschließend einsehen. Im nachfolgenden Beispiel habe ich den HTTP-Verkehr temporär deaktiviert – beim Aufruf einer Webseite wird sofort ein Eintrag im Syslog erzeugt:

Thu Dec 5 10:16:15 2019 kern.warn kernel: [13594.979197] REJECT wan out: IN=wlan1 OUT=eth1 MAC=fd:b1:56:f3:d2:0a:af:6l:af:32:a0:c6:07:a0 SRC=192.168.150.10 DST=95.216.40.49 LEN=52 TOS=0x00 PREC=0x00 TTL=63 ID=24764 DF PROTO=TCP SPT=46422 DPT=443 WINDOW=29200 RES=0x00 SYN URGP=0

Neben der Quelle ist das Ziel bzw. insbesondere der Zielport (DPT=443) die essenzielle Information. Auf Basis dieser Information kann anschließend eine neue Firewall-Regel erstellt werden.

3.2 Grenzen des Paketfilters

Ein Paketfilter arbeitet auf den OSI-Schichten 3 und 4, also auf der Netzwerk- und Transportschicht. Zur Filterung des Datenverkehrs werden also lediglich die Header-Informationen der Netzwerkpakete ausgewertet. Im Gegensatz dazu können Application-Firewalls bspw. zusätzlich die Nutzdaten von Anwendungsprotokollen auswerten (OSI-Schicht 7). Sie besitzen also Kenntnisse über die jeweilige Anwendung bzw. den Protokollaufbau wie HTTP, FTP, DNS etc.

Eine clevere Schadsoftware könnte den Paketfilter relativ einfach umgehen, indem der Verbindungsaufbau mit dem Angreifer über den HTTP bzw. HTTPS-Port verläuft, der im Normalfall für die Kommunikation mit Webservern freigegeben ist. Über einen dazwischengeschalteten Proxy könnte das Risiko etwas gemindert werden – der springende Punkt ist aber: Ein Paketfilter hat seine Grenzen und ist lediglich ein kleines Puzzleteil eines Sicherheitskonzepts.

4. Fazit

Gerade an einem zentralen Netzwerkgerät wie einem Router sind Firewall-Regelsätze sinnvoll, da alle dahinterliegenden Clients davon profitieren. Allerdings sollte man hierbei die Grenzen eines Paketfilters stets im Hinterkopf behalten und sich nicht in falsche Sicherheit wiegen.

Persönlich nutze ich die OpenWrt-Firewall noch für einen anderen Zweck: Der virtuellen Windows-7-Maschine habe ich jeglichen Datenaustausch mit dem Internet verboten – lediglich die IP-Adresse des ansässigen Finanzamts kann von der Maschine erreicht werden, um die Umsatzsteuervoranmeldung und Einkommensteuererklärung abzusenden. Damit lässt sich Windows für ausgewählte Anwendungszwecke weiterhin nutzen, ohne an Microsofts Datensammelspiel teilzunehmen.

Im nachfolgenden und letzten Teil der OpenWrt-Artikelserie werden wir uns mit dem Update-Vorgang des OpenWrt-Routers bzw. Images befassen.

Bildquellen:

Firewall: Smashicons from www.flaticon.com is licensed by CC 3.0 BY

Über den Autor | Kuketz

Mike Kuketz

In meiner freiberuflichen Tätigkeit als Pentester / Sicherheitsforscher (Kuketz IT-Security) schlüpfe ich in die Rolle eines »Hackers« und suche nach Schwachstellen in IT-Systemen, Webanwendungen und Apps (Android, iOS). Des Weiteren bin ich Lehrbeauftragter für IT-Sicherheit an der Dualen Hochschule Karlsruhe, sensibilisiere Menschen in Workshops und Schulungen für Sicherheit und Datenschutz und bin unter anderem auch als Autor für die Computerzeitschrift c’t tätig.

Der Kuketz-Blog bzw. meine Person ist regelmäßig in den Medien (heise online, Spiegel Online, Süddeutsche Zeitung etc.) präsent.

Mehr Erfahren ➡

Unterstützen

Die Arbeit von kuketz-blog.de wird zu 100% durch Spenden unserer Leserinnen und Leser finanziert. Werde Teil dieser Community und unterstütze auch du unsere Arbeit mit deiner Spende.

Folge dem Blog

Wenn du über aktuelle Beiträge informiert werden möchtest, hast du verschiedene Möglichkeiten, dem Blog zu folgen:

Bleib aktuell ➡

Diskussion

12 Ergänzungen zu “Firewall | Kontrolle ausgehender Datenverkehr – OpenWrt Teil6”

Anonymous sagt:

6. Dezember 2019 um 11:02 Uhr

Hallo Mike toller Artikel mal wieder. Nur eine Frage dazu: Gibt es eine Möglichkeit das ASN-Script einzubinden wie bei der IPFire oder wie hast du das umgesetzt? Oder gibt es dazu noch ein Artikel?
- Mike Kuketz sagt:
  
  6. Dezember 2019 um 11:04 Uhr
  
  Das geht auch, maloe hat das Skript dahingehend modifiziert bzw. angepasst, so dass dies über Firewall -> Custom Rules abgebildet werden kann. Dazu wird es allerdings vorerst keine Anleitung geben. Ich muss mir das selbst noch anschauen – eventuell gibt es dann dazu einen Artikel.
Stanok sagt:

6. Dezember 2019 um 11:10 Uhr

Hallo Mike,

vielleicht eine doofe Frage aber einmal zur Verständnis. Deine Grundkonfiguration bezieht sich auf die WIFI Zone. Würde das auch für die LAN Zone passen oder gibts da noch etwas besonderes zu beachten?

Danke
Gruß
Stanok
- Mike Kuketz sagt:
  
  6. Dezember 2019 um 11:12 Uhr
  
  Passt auch dort.
Anonymous sagt:

6. Dezember 2019 um 12:30 Uhr

Hallo Mike,

könntest du ggf. die Standard-Regeln noch als Screenshot hinterlegen?
Würde mich interessieren, welche dort hinterlegt sind (habe selbst leider kein OpenWRT-Router, um das zu testen).
Ka2w0 sagt:

7. Dezember 2019 um 21:17 Uhr

Hallo Mike,
Danke für das Tutorial! Kleine Anmerkung. Wäre es nicht sinnvoll on Top noch eine sehr wichtige Regel hinzuzufügen? Nämlich die Regel, die verhindert sich selbst auszusperren. Ist mir leider selbst schon passiert da alle meine Zonen INPUT rejecten. Also eine Regel für die Ports SSH, WEB 80 (http) und WEB 443 (https) welche Verbindungen vom Client von dem aus OpenWRT administiert zulässt.

Accept input Regel:
IPv4-tcp, udp
From IP 192.168.XX.XXX in lan
To IP 192.168.XX.X at ports 22, 80, 443 on this device

Gruß!
- Mike Kuketz sagt:
  
  9. Dezember 2019 um 11:11 Uhr
  
  Wenn du deine Zone(n) auf INPUT [Reject] stellst (auf dem auch das LuCi-Webinterface lauscht), dann ist das sinnvoll, ja. INPUT [Reject] ist im Normalfall allerdings nur am WAN-Interface notwendig. Kommt eben drauf an, was du erreichen möchtest.
Alex sagt:

8. Dezember 2019 um 21:16 Uhr

Hallo Mike,
danke für deinen Artikel! Die beschrieben Firewall-Regeln beziehen sich alle auf den ausgehenden Verkehr. Macht es Sinn für eingehenden Verkehr auch regeln aufzustellen und ist das nicht eigentlich wichtiger? Welche Regeln würdest du dafür empfehlen?

Grüße,
Alex
- Mike Kuketz sagt:
  
  9. Dezember 2019 um 11:08 Uhr
  
  Eingehende Firewall-Regeln benötigst du nur, wenn du Dienste nach außen anbietest bzw. diese von außen erreichbar sein sollen. Ansonsten sind diese nicht notwendig. Stichwort: Stateful Packet Inspection
Rodario sagt:

9. Dezember 2019 um 08:37 Uhr

Hallo Mike,
eine Verständnisfrage zur Regel „Samba-Share“: Dort ist als Destination Zone „wan“ angegeben, obwohl die Destination Address 192.168.50.1 offenbar zu einem lokalen Netzwerk gehört.
Wäre in dem Fall z.B. eine Angaben Destination Zone „lan“ sinnvoll, wenn „lan“ als Netzwerk 192.168.50.x bekannt ist?

Gruß
Rodario
- Mike Kuketz sagt:
  
  9. Dezember 2019 um 11:06 Uhr
  
  Das hat etwas mit meinem Netzwerkaufbau zu tun – siehe Teil 1.
  
  Die davorgeschaltete Fritz!Box 6490 hat einen offenen Samba-Share (ins interne Netz). Für die Clients hinter dem OpenWrt-Router ist dieser Share über das WAN-Interface also Zone wan erreichbar.
maga sagt:

22. Dezember 2019 um 19:28 Uhr

Hallo Mike,

Danke für deine sehr guten Artikel.

Bei den Firewall Traffic Rules habe ich die aus dem o.g OpenWrt Teil 6
deine Beispiele genommen (http,https,ntp usw.) leider funktioniert
bei mir der Captiv-Portal-check dann nicht mehr.
Es bleibt immer das kleine x im WLAN-Symbol.
Den Port 853 habe ich auch freigegeben.
Das System Log zeigt:
REJECT wan out: IN=br-WIFI OUT=eth1 MAC=

Danke
maga

Wenn du konkrete Fragen hast oder Hilfe benötigst, sind das offizielle Forum oder der Chat geeignete Anlaufstellen, um dein Anliegen zu diskutieren. Per E-Mail beantworte ich grundsätzlich keine (Support-)Anfragen – dazu fehlt mir einfach die Zeit. Kuketz-Forum

Abschließender Hinweis

Blog-Beiträge erheben nicht den Anspruch auf ständige Aktualität und Richtigkeit wie Lexikoneinträge (z.B. Wikipedia), sondern beziehen sich wie Zeitungsartikel auf den Informationsstand zum Zeitpunkt des Redaktionsschlusses.

Kritik, Anregungen oder Korrekturvorschläge zu den Beiträgen nehme ich gerne per E-Mail entgegen.

Artikel (400)

Firewall | Kontrolle ausgehender Datenverkehr – OpenWrt Teil6