Aber auf eines möchte ich gleich zu Beginn deutlich hinweisen, der Artikel wendet sich zwar an Leute ohne tiefe Sachkenntnisse, aber er ist dennoch kein ‚Malen nach Zahlen‘. Ich setze gewisse Grundkenntnisse über Netzwerke voraus, z.B. was IP-Adressen sind, welche Funktion sie haben, was IP-Adressen innerhalb eines lokalen Netzwerkes gemeinsam haben, was ein Router ist, welche Aufgaben er hat, usw. Ein paar ganz allgemeine Basics über Netzwerke habe ich auf den ersten Seiten meines Caravan-Projektes beschrieben, was als Grundlage für diesen Artikel völlig ausreichend ist. Wer jedoch glaubt, er könne sich ohne Verständnis für die großen Zusammenhänge mal eben die am Ende beschriebenen Netfilter-Regeln auf seinen Rechner kopieren und starten und hätte

1. Jeder Internet-Teilnehmer hat eine weltweit gültige und weltweit einmalige IP-Adresse, mit der er eindeutig identifiziert werden kann. (Anmerk.: Eine Aussage über die Gültigkeitsdauer dieser IP ist hier nicht enthalten, und auch nicht darüber, dass ‚jemand‘ auch mehrere Internetzugänge haben kann, ich beziehe mich nur auf den Moment einer aktuellen (privaten) Verbindung).

2. Bei IPv4 (32 Bit Länge) ist auf Grund der begrenzten Anzahl maximal möglicher IPv4-Adressen der DSL-Router der einzige echte Internet-Teilnehmer im privaten Netz (siehe NAT).

3. Bei IPv6 (128 Bit Länge) kann auf Grund der sehr hohen Anzahl möglicher Adressen im 2000::‘er Netz neben dem DSL-Router auch jedes Client-Gerät selber Internet-Teilnehmer sein.

4. Für IPv4-Netze erhalten private Internet-Teilnehmer von ihrem DSL-Anbieter eine internettaugliche IP-Adresse, die normalerweise der DSL-Router verwendet. Das lokale Netzwerk wird vom Router repräsentiert, basierend auf einem privaten IP-Range:  Class-C-Netz 192.168.*/24, Class-B-Netz 172.*/16 und Class-A-Netz 10/8. Lokale IPv4-Adressen im LAN werden den Clients üblicherweise vom Router via DHCP zugewiesen und sind nicht internettauglich.

5. Für IPv6-Netze erhalten private Internet-Teilnehmer von ihrem DSL-Anbieter einen weltweit einmaligen Prefix, mit dem eine 64 Bit lange Site-ID gebildet wird, die das „eigene“ Netzwerk repräsentiert und die via Router Advertisement an die Clients im LAN übermittelt wird. Weitere 64 Bits (ab Bit 65) enthalten den Interface Identifier, den jedes Gerät abgeleitet aus der MAC-Adresse des Netzwerk-Interfaces im Gerät selber ermittelt. Die 128 Bits zusammen ergeben mit der Site-ID und dem Interface Identifier die internettaugliche IPv6-Adresse des Geräts, die letztlich nicht von extern zugewiesen, sondern „zustandslos“ (SLAAC) durch den Client-PC selber ermittelt wurde.

6. Lokale IP4/6-Daten-Pakete (Quelle und Ziel = LAN) werden normalerweise nicht über das Internet geroutet.

7. Eine direkte Kommunikation zwischen IPv4 und IPv6 ist nicht möglich (siehe IP-Transition-Technologies, 6to4, etc.).

8. Eine IP-Adresse besteht i.ü.S. immer aus 2 Teilen, zuerst der Netzwerk-Anteil, der für alle Clients im privaten LAN gleich ist. Dann folgt der Client-Anteil, der zur eindeutigen Unterscheidung im LAN für jeden Client einmalig ist.

Ein Beispiel für ein klassisches privates IPv4-Class-C Netz:

                               Netzwerk-Anteil            Client-Anteil

IP:      198.51.100.002/24     11000110.00110011.01100100.00000010

Subnet:  255.255.255.000       11111111.11111111.11111111.00000000

                               Bits 0 - 24                Bits 25 - 32

Ein Beispiel für ein IPv6-Netzwerk:

                               Site-ID                Interface-Identifier

                               (Netzwerk-Anteil)      (Client-Anteil)

Global Unicast Adress, IP:     2001 : db8 : f3 : 40 : cc29 : baff : fed9 : 22 / 64

                               Bits 0 - 64            Bits 65 – 128

Die Breite von /24 bzw. /64 Bits legt bei diesen Beispielen jeweils den Netzwerk-Anteil in der IP-Adresse fest. Geräte im LAN mit gleichem Netzwerk-Anteil können unmittelbar miteinander kommunizieren.  Ein markanter Unterschied zwischen IPv4 und IPv6 ist die Subnet-Mask, die seit der Einführung von CIDR ein klassenloses Domain-Routing ermöglicht. Seit CIDR ist für IPv4 die Angabe der Subnet-Mask zwingend notwendig, was hingegen bei den früheren Netzwerkklassen nicht erforderlich war. Der Grund für CIDR war die traditionelle Knappheit von IPv4-Adressen und die durch Netzklassen entstehende weitere künstliche Beschränkung -  was es bei IPv6 so gar nicht gibt, weswegen IPv6 eben ohne Subnet-Mask auskommt – für mich ein weiterer Vorteil von IPv6.

Solche Attacken können nur erfolgreich funktionieren, wenn schon bereits geöffnete Türen im Router vorhanden sind (wie offene Ports und Weiterleitungen oder mangelhafte Einstellungen der WLAN-Security), sei es vorher durch den Anwender selber geöffnet oder durch einen Fehler in der Firmware - beim letzteren wäre es sogar ein echter Exploit. Aber das ist nicht die Regel und geöffnete Ports sind auch nicht von vornherein so eingestellt.

Eine zweite Möglichkeit besteht noch, wenn auf dem PC des Anwenders ein Programm (Schadsoftware) läuft, welches von sich aus eine schadensverursachende Verbindung ins Internet aufbaut, was allerdings quasi einer Einladung gleichkommt und deshalb nicht der Firewall anzulasten ist.

Es wird etwas leichter verständlich, wenn man sich einmal ein auf die Reise gehendes Datenpaket anschaut. Fester Bestandteil eines jeden Datenpakets sind neben den zu übermittelnden Daten (Payload, i.ü.S. Nutzlast) die beiden Felder des IP-Headers, wer hat es gesendet (Source-Addr) und wer ist der Empfänger (Dest-Addr).

Die Source-Addr ist notwendig, damit der Empfänger für eine Rückantwort diese IP in der Dest-Addr seines Antwort-Paket eintragen kann. In der Rückantwort ist also die vorherige Quell-Adresse jetzt die Ziel-Adresse, und das ist erst mal unser Router. In unserem Router findet in beiden Fällen (in/out) jeweils die Network Address Translation statt.

Also auch die mit einer Global-Unicast-IPv6 ausgestatteten Geräte, die damit zwar eine internettaugliche Adresse haben, können vom Internet aus nicht direkt angesprochen werden, selbst dann nicht, wenn die betroffene IPv6 dem Angreifer sogar bekannt wäre.

"Muss ich das echt alles wissen...?… ich will doch bloß ne Firewall auf meinem PC"

Ja, eben… Du willst doch eine Firewall einrichten, wie soll das denn gehen, wenn Du gar nicht weißt, auf was es dabei ankommt und was Du beachten mussst? Wenn es Dir nur um ‚eine‘ zusätzliche Firewall auf dem PC geht, gibt‘s natürlich auch eine einfache Lösung…. installiere Dir Wine und darin dann Zonealarm. Das bringt zwar nix, aber Du kannst wenigstens sagen, dass Du eine Firewall installiert hast. Dann kannst Du Dir auch die Arbeit ersparen, ein wenig Hintergrundwissen zu erwerben. Wenn Deine Firewall aber erfolgreich schützen soll ...tja… Pech gehabt, das bedeutet Arbeit…  ;-)

Natürlich werden hartgesottene Sicherheitsexperten jetzt wieder argumentieren "Ein typischer Consumer-Router ist per se als kompromittiert anzusehen, weil seine Firmware proprietäre Software ist!" Ja, das ist wohl so. Ich schließe auch nicht völlig aus, dass AVM oder TP-Link als Hersteller meiner Router bei Default-Settings jederzeit die Möglichkeit haben, von außerhalb die Kontrolle über ihr/mein Gerät zu übernehmen. Die TR-069-Schnittstelle ist faktisch eine Backdoor für genau solche Zwecke. Diese Lücke konnte ich jedoch bei meiner Fritzbox erfolgreich schließen, bzw. den Service deaktivieren. Ist es darüber hinausgehend noch vorstellbar, dass auch die Inlands- und Auslandsgeheimdienste unserer Welt sämtlich einen Hintereingang in unsere Router und damit in unsere privaten Netzwerke haben …?... *hmmmm* … ja, ist vorstellbar, technisch wäre das wohl problemlos umzusetzen, aber ich kann mir beim besten Willen nicht vorstellen, dass das auf Dauer unentdeckt bleibt. Tja, welche Alternativen habe ich aber? Ein eigenes DSL-Modem und einen eigenen Router bauen ...?... bei dem ich nie wirklich sicher sein kann, ob nicht von mir verbockte Design-Fehler aus diesem Eigenbau ein (von mir unentdecktes) offenes Scheunentor in mein Heim-Netzwerk machen ...?... nee, Danke ... da bleib ich doch lieber bei meiner Fritzbox.

Ganz nebenbei bemerkt, solche Fragen betreffen ja nicht nur die Firmware der Fritzbox allein. Woher weiß ich zum Beispiel, dass ASUS als Hersteller meines Motherboards mit integrierter proprietärer Netzwerksoftware das nicht auch kann? Was ist mit Druckern mit integrierter LAN-Funktion? Ich weiß das alles nicht.

Ich habe mich jedenfalls deshalb dazu entschlossen, mein Bestreben nach besserer Sicherheit zum Schutz meiner digitalen Privatsphäre nicht in Paranoia ausarten zu lassen.

Die einzige für mich realistische Alternative wäre dann wohl, gänzlich auf den Betrieb eines Computers mit Zugang zum Internet zu verzichten. Nee, auch das ist für mich wirklich keine Alternative.

"Wann brauch ich denn überhaupt eine Firewall auf dem PC?" Meiner Meinung nach auf jeden Fall dann, wenn Du Deinem DSL-Router zweifelsfrei misstraust, aber keinen eigenen Router mit echter Firewall einrichten willst und wenn Du deine digitale Privatsphäre ausreichend sensibel und deswegen schutzwürdig einschätzt. Und ja, es gibt tatsächlich auch durchaus weitere sinnvolle Szenarien für den Einsatz einer Desktop-Firewall, jedoch vermutlich ein wenig anders geartet, als Du vielleicht erwartest. Für eine sinnvolle Antwort auf Deine Frage musst Du aber zuvor eine Antwort auf die Frage „vor wem will ich mich schützen?“ finden. Und dabei solltest Du unbedingt verstehen, dass "Schutz" und "Wogegen" immer ein binäres Verhältnis zweier einzelner konkret benannter Kontrahenten ist - entweder gewinnt der eine oder der andere, je nachdem wer cleverer ist. Es gibt deshalb keinen einfach zu erstellenden und umfassend gegen alle Angriffe wirksamen Firewall-Schutz. Mit anderen Worten, Du musst das „wogegen“ ganz konkret bezeichnen. Und das vor dem Hintergrund, dass es nicht nur ein einzelnes „wogegen“ gibt, sondern möglicherweise sehr viele. Jedes Anwendungsprogramm, jeder auf dem Rechner laufende Service, sämtliche Aktionen der User an Tastatur und Bildschirm können ein „dagegen“ beinhalten. Eine Firewall unter Linux, die aus technischer Sicht eigentlich ein Paketfilter ist, ist immer eine mehr oder weniger umfangreiche Sammlung von Regeln, bei der jede Regel einen konkreten "Gegner" hat, oder besser, sich mit einem konkreten Sachverhalt befasst. Und es gibt Regeln, die über die Power verfügen, alle anderen Regeln zu überstimmen und außer Kraft zu setzen.

Bei der Firewall ist es schließlich genau gleich wie bei der vorbeugenden Grippeimpfung, denn auch dabei bekommt man bedauerlicherweise auf die abschließende Frage niemals eine Antwort: "Hätte ich die Grippe auch ohne Impfung nicht bekommen, oder habe ich sie nicht bekommen, weil ich geimpft war?" Und gleichermaßen kann man in beiden Fälle die Komplementär-Frage stellen: "Hätte ich mit einer Impfung die Grippeinfektion verhindern können oder hätte ich die Grippe vielleicht sogar trotz Impfung bekommen?" Und bezogen auf die Firewall im Fall der Fälle: "Hätte ich vielleicht mit besserer Traffic-Regulierung den digitalen Angriff verhindern können?"

Zusammengefasst hier noch einmal kurz wiederholt, unter welchen Bedingungen ich eine auf dem PC installierte FW nicht nur für sinnvoll, sondern sogar als obligatorisch notwendig betrachte:

1. wenn unser PC mit direkter und unmittelbarer Anbindung (ohne Router) ins Internet verbunden ist

2. wenn wir private Server-Systeme mit zum Internet geöffneten Diensten betreiben

3. wenn wir uns mit Mobil-Geräten (Laptops, etc.), an unbekannten Accesspoints verbinden

Als Einstieg in diesen besonderen Teilaspekt des Themas 'Sicherheit durch eine Personal Firewall' müssen wir zunächst mal verstehen, was eine Firewall überhaupt ist, oder besser, was sie nicht ist. Denn wenn man sich etwas tiefergehend mit dieser Frage befasst, wird man erkennen, dass eine tatsächlich wirksame Firewall niemals nur ein einzelnes Programm auf dem PC des Hauptbenutzers sein kann, sondern das die Firewall in Wirklichkeit ein umfassendes Konzept darstellt bzw. darstellen muss, welches am Ende natürlich auch durch unterschiedliche Programme unterstützt wird. Ich will jetzt aber hier niemanden verunsichern oder entmutigen, denn richtig hohen Aufwand und einen professionellen Umfang brauchen wir für unser Ziel gar nicht.

Aber wenn jemand die Vorstellung hat, er installiert sich mal eben eine Desktop-Firewall und hat dann einen Einbruchsschutz, wie auf dem Bild nebenan illustriert, dann möchte ich darauf hinweisen, dass das so nicht funktionieren wird. Wenn jemand ein solche Schutz-Kuppel über seinen PC im Sinne hat, gibt es nur einen Weg, um dieses Ziel auch wirklich zu erreichen:

Er muss den Stecker seines LAN-Kabels abziehen und die WLAN-Karte deaktivieren - andere Möglichkeiten gibt es meiner Meinung nach nicht.

Wir sollten die Tatsache akzeptieren, dass zu einer sicheren Firewall viel mehr gehört, als nur ein kleines Progrämmchen, welches man sich mal eben installiert und dann glaubt, jetzt ist alles gesichert. Um das etwas besser zu verstehen ist ein kurzer Seitenblick auf eine professionelle und business-taugliche Firewall hilfreich, zu der z.B. der Einsatz von dedizierter Hardware gehört, wie Proxyserver, dann physische Trennung von Subnetzen durch interne und externe Router, dazu AV-Scanning, Paketfilter, Script-Blocker, Applicationsgateways, Verbindungsprotokolle, Traffic-Überwachung und Analyse, Compliance-Regeln für Mitarbeiter und vieles mehr. Erst all das zusammen ergibt dann am Ende eine echte Firewall, die dieser Bezeichnung auch wirklich gerecht wird.... nur ist es hierbei ein umfassendes Firewall-Konzept.

Außerdem beinhaltet eine echte Firewall immer auch gravierende Beschränkungen, Abschaltung von Bequemlichkeiten und Möglichkeiten, Durchsetzung von Regeln und Verboten, minderer Komfort, Verzicht, durchaus auch merkbare Beeinträchtigungen des Users an der Tastatur.

Ums kurz zu sagen, Sicherheit ist immer teuer - auf die eine oder andere Art und Weise. All das ist natürlich für unsere kleine private EDV viel zu aufwendig und wäre auch maßlos übertrieben. Aus diesem Grund und um wenigstens das zu erreichen, was für uns mit vertretbaren bzw. geringen Aufwand überhaupt erreichbar ist, beschränke ich mich auf einen kleinen, aber durchaus wirksamen Aspekt aus dem großen Gesamtpaket, und zwar dem Aspekt, der am Besten zu den schon erwähnten Compliance-Regeln passt, also den Regeln, die das Benutzer-Verhalten beschreiben und regulieren.

Ja, es ist auch mit eher einfachen Mitteln möglich, eine sehr effektive Firewall einzurichten, die auch wirklich unsere Erwartungen erfüllt. Auch mit einfachen Mitteln ist ein wirksamer Schutzschild möglich. Aber, bevor wir loslegen und wenn wirklich eine Verbesserung der Sicherheit erreicht werden soll, sollten wir damit beginnen, ein paar Vorurteile über Bord zu werfen und etwas später auch ein paar Änderungen bezgl. unseres bisherigen eigenen Verhaltens akzeptieren.

Das alleinige Programm "Desktop-Firewall" (wie man das auch von Windows her kennt) und ohne dahinterstehendes Firewall-Konzept ist m.M.n. wirklich nicht mehr als eine reine Fake-Anwendung, ein sicherheitstechnischer Trugschluss, und zwar vordergründig genau dann, wenn der User selber in der Administratoren-Gruppe eingetragen ist.... oder wie das bei einigen Linux-Distributionen der Fall ist, er wurde automatisch durch den Installer als Mitglied der Gruppe "sudo" eingetragen.

Daraus resultiert zwangsläufig aber auch der unschöne Nebeneffekt, wenn der Hauptbenutzer selber das Recht hat oder sich das Recht aneignen kann, Veränderungen am System durchzuführen, so können das über kurz oder lang auch alle Anwendungen, die dieser User in seinen User-Space gestartet hat.

Ok, um nun mal den Saboteur ins Visier zu nehmen… ja ja ja, schon gut, vielleicht ist Saboteur nicht ganz die richtige Wortwahl. Zu sabotieren bedeutet ja den Vorsatz zur Sabotage zu haben, also etwas vorsätzlich und bewusst zu zerstören. Ich glaube, dass kann man hier nicht wirklich unterstellen…

... aber mir hats halt Spaß gemacht, diese ein wenig provokante Bezeichnung als Einleitung zu nehmen. Denn letztlich besteht kein Unterschied darin, was ganz am Ende hinten rauskommt.

Das Ergebnis einer beabsichtigten Sabotage ist das gleiche, wie nach einer groben Fahrlässigkeit basierend auf Nichtwissen. Der einzige Unterschied ist dabei der fehlende Vorsatz, in beiden Fällen ist der eigene Computer aber möglicherweise jetzt kompromittiert.

Zusammengefasst sind das die für uns relevanten Aussagen:

...die jedoch keine Gefahr für das existierende System darstellten.

...allow some users to execute some commands as root...

...to give specific users permission to use specific system commands at the root...

Kein Anwender (alle folgenden Regeln gelten natürlich auch für mich selber) hat das Recht, unter seiner UID gestartet und mit seinem PWD autorisiert Änderungen an der Konfiguration des Betriebssystems seines PCs vorzunehmen

Lösung: Keine Mitgliedschaft in Admin-Groups

Kein Anwender kann neue Software installieren und starten, nicht mal in seinem Homedir

Lösung: remount von /home, /dev/shm und /tmp mit noexec,nosuid,nodev

Kein Anwender hat Ändern-Rechte, die über sein Homedir hinausgehen

Lösung: das ist bereits der Default-Zustand bei Debian, also darauf verzichten, keine weiteren Rechte manuell zu setzen

Kein Anwender kann die Homedir-Verzeichnisse anderer User öffnen, deren Inhalte lesen oder dort Dateien erstellen oder verändern

Lösung: chmod 700 /home/*

Kein Anwender kann sich unter seiner UID oder unter Verwendung seines PWD weitergehende Rechte aneignen

Lösung: Keine Mitgliedschaft in Admin-Groups

Kein Anwender (hier bin ich für alle User/PCs der einzige) kennt das root-Password unserer Client-PCs

Lösung: Abweichendes und anspruchsvolles root-Password (in Bezug auf die User-Passwords)

Alle explizit notwendigen Ausnahme- bzw. Zusatzrechte für Anwender sind rigoros über Policykit-Rules geregelt

Lösung: Explizite Polkit-Rules für einzelne Befehle und bei Bedarf ergänzende individuelle PKLA-Berechtigungen

Es werden keine grafischen Anwenderprogramme mit root-Rechten gestartet, insbesondere nicht *Office, Browser, Mal-, Zeichen- und Foto-Editier-Programme, Multimedia-Programme, etc.

Lösung: Sofern root-Rechte notwendig sind, auf Text-Apps im root-Terminal beschränken, wie nano, vim, midnight-commander

Maschinell angelegte User im System mit einem Default-PWD sind entfernt (z.B. der User pi mit dem PWD raspberry auf einem Raspberry Pi)

Lösung: login user pi, set root-Password, adduser NeuerUser, logout user pi, login NeuerUser, switch to root, deluser pi

Die unbekannte Wechselwirkung zwischen sudo und Policykit wurde damit beseitigt, indem das Paket sudo auf keinem PC installiert ist bzw. -wenn vorhanden- deinstalliert wurde

Lösung: apt purge sudo oder alternativ eine sichere Distribution verwenden, in der sudo kein Default-Feature ist

Es ist auf keinem der normalen Client-PCs eine Anmeldung direkt als root per SSH erlaubt. Die Verbindung wird immer zuerst als User etabliert und ist damit zunächst mal „rechtelos“. Der Wechsel zum root-Account erfolgt über das root-Passwort des SSH-Server-Hosts

Lösung: /etc/ssh/sshd_config = PermitRootLogin no

Notwendige SSH-Anmeldungen ist auf allen Systemen nur mit Password-geschützten Keyfiles möglich.

Lösung: /etc/ssh/sshd_config = PubkeyAuthentication yes, PasswordAuthentication no

Sofern aus dem Internet unbedingt auch ein SSH-Zugriff erwünscht ist, empfehle ich einen im Router freigegebenen Port >50000, der dann auf Port 22 des SSH-Servers weitergeleitet wird, was hier zur Folge hatte, das Grundrauschen des Internets auf Port 22 deutlich zu reduzieren.

Lösung: Explizite Freigabe/Filtereinstellung im Router

Ein Zugang von außen aus dem Internet auf das Heimnetz ist hier derzeit nur über OpenVPN möglich. Das bedeutet, es sind auf dem Router neben den 2 VPN-Ports für TCP und UDP keine weiteren Ports geöffnet. Ich verwende auf dem Router für die Freigabe und Weiterleitung Port 443 für TCP und einen unprivilegierten Ports >50000 für UDP, womit auch hier das Rauschen auf dem bekannten Port 1194 deutlich reduziert wird. Die Verwendung von HTTPS/443 ist ein Trick, um eine mögliche Firewall-Sperre von UDP-Ports an öffentlichen Accesspoints zu umgehen. Damit wird verschlüsselter VPN-Traffic auf ein sowieso verschlüsseltes HTTPS-Protokoll aufgelegt und bleibt somit eigentlich unsichtbar. Das beeinträchtigt zwar die Performance, aber ich kann trotzdem mein Netzwerk zuhause erreichen und ggf. meinen Router, um sicher zu surfen. Port 443 betrachte ich als Fallback-Lösung, wenn das primär genutzte UDP gesperrt ist. DPI-Firewalls werden solchen Traffic vermutlich dennoch entdecken können, aber ich denke, die für uns relevanten offenen WLAN-Accesspoints in Restaurants, Hotels, Campingplätzen, City, usw. werden mehrheitlich wohl keine DPI-FWs einsetzen,

Lösung: Explizite Freigabe/Filtereinstellung im Router

Der Zugang nach draußen ins Internet ist auf einigen besonderen Geräten via Paketfilter reguliert. Meinem Server ist der offene Zugriff aufs Internet verboten, es bestehen lediglich explizite Ausnahmeregeln für Mail (Getmail + Postfix) und VPN.

Lösung: Paketfilter mit nftables installieren

Keine unnötigen Dienste laufen lassen, bzw. laufende notwendige Dienste auf "localhost" begrenzen

Der Browser auf den Client-PCs wird mit einem Script-Blocker scharf reguliert.

Lösung: Ublock Origin

Allen Non-User-End-Geräten im ganzen LAN ist der Zugriff aufs Internet verboten (IP-Cams, Smart-TVs, Drucker, etc.).

Lösung: Einstellung im Router = Zugang zum Internet ist für diese LAN-Clients gesperrt, zugriff auf alle Clients von 'außen' nur via OpenVPN

Neue Software, die testweise oder aus Neugier bezüglich der Möglichkeiten und des Nutzens geprüft werden soll, wird zuerst nur in einer VM installiert – gemäß der Prämisse „Never touch a running system“. Auf den produktiven Systemen ist nur tatsächlich benötigte/verwendete Software installiert.

Lösung: Libvirt/KVM oder Oracle VirtualBox und dort eine eher anspruchslose Distribution (LXDE) installieren

Wenn ich in Ausnahmefällen besondere Software benötige, die entweder im Distributions-Repo gar nicht enthalten ist oder die dort schlichtweg zu alt ist, so verwende ich ausnahmsweise Setup-Pakete direkt von der bekannten und etablierten Projekt-Seite.... und zwar nur von dort, oder eben gar nicht. Ist die Repo-Version nur zu alt, überlege ich jedoch zuerst, ob die aktuelle Version neue Funktionen enthält, die ich wirklich unbedingt benötigte... wenn nicht, reicht mir auch die ältere Version.

Es sind kompromisslos alle Erlaubnisse ausgeschlossen, die es fremden und unbekannten Repositories ermöglichen, im Rahmen der regulär durchgeführten Updates/Upgrades Veränderungen an unseren Systemen vorzunehmen, und das schlimmstenfalls auch noch  innerhalb eines regelmäßigen Automatismus.

Ich habe deshalb für uns 4 Paketfilter-Modelle entwickelt, von denen ich glaube, dass sie sich bei uns (je nach Anwendungsfall unterschieden) als Software-Unterstützung optimal in das organisatorische und disziplinarische Regelwerk einfügen, ohne unseren IT-Betrieb zu blockieren und trotzdem den bestmöglichen Schutz durch eine funktionierende Firewall zu gewährleisten. Vier Modelle sind es, weil es eben hier 4 unterschiedliche Anwendungsfälle mit unterschiedlichen Schwerpunkten gibt.

Aber hier ist unbedingt an eine technische Besonderheit zu denken, und zwar an die direkte Abstimmung zumindest von 2 dieser 4 Paketfilter aufeinander. Schließlich ist es ja so, dass sie im gleichen LAN funktionieren müssen und durchaus auch den gegenseitigen Zugriff auf die Dienste anderer Rechner erlauben sollen.

Wie ich zu Anfang schon festgestellt habe, es gibt keine allgemein gültige Lösung, die gleichermaßen vollständig alle Anwendungsfälle perfekt abdeckt…. denn das, was auf der einen Seite notwendigerweise gelockert wird, stellt in einem anderem Szenario ein hohes Sicherheitsrisiko dar. Umgekehrt ist es genau so problematisch, denn das, was auf der einen Seite scharf reguliert wird, blockiert möglicherweise auf einem anderen Rechner notwendige Prozesse.

1

2

3

4

Die hier in dieser Beschreibung angelegten bzw. anzulegenden Dateien können mit dem dieser Beschreibung entsprechenden Inhalt unter der folgenden Adresse herunter geladen werden:  http://www.thlu.de/Public/security.tar

Wenn die im Tar-File enthaltenen Dateien in die späteren Original-Verzeichnisse kopiert werden, um sie dort manuell anzupassen, müssen unbedingt die Rechte-Einstellungen gemäß dieser Anleitung nachbearbeitet werden! Im Übrigen ist es möglich, dass die Beispiele hier in der Anleitung weniger aktuell sind, als die im Tar-File enthaltenen Dateien. Deswegen empfehle ich unbedingt, nur die Beispieldateien aus dem Tar-File zu verwenden

Bevor es also jetzt losgeht, möchte ich noch mal ausdrücklich darauf hinweisen, dass meine Paketfilter-Lösungen 'exklusive' Lösungen sind, das bedeutet, ihnen fehlt jegliche Allgemein-Firewall-Tauglichkeit. Sie befassen sich 'exklusiv' mit jeweils einer konkreten Problemstellung. Vermutlich kann man aus dem Vorgehen weitere Lösungen ableiten, aber das bedarf Sorgfalt, Sachkenntnis und der abschließenden Prüfung, dass es mit diesem neuen Filter sicher ist und ohne nicht. Fehlt diese Bestätigung, kann man sich das sowieso sparen, dann wäre jegliche Arbeit dazu nur verschwendete Zeit.

Da mir bewusst ist, wie kompliziert die Zusammenhänge manchmal zu verstehen sind, versuche ich hier meine persönliche Gewichtung für die Ausrichtung von drei der vier individuellen Paketfilter mit 2 Bildern grafisch darzustellen. Ich hoffe, dass damit die Unterschiede und meine Schwerpunkte für die Paketfilter im Vergleich der Systeme deutlicher sichtbar werden.

Outbound beschreibt die Datenpakete, bei denen unser Client-PC selber die Quelle war, die also unseren PC über das Netzwerkinterface verlassen.

Inbound beschreibt die Datenpakete, für die ein anderer Rechner die Quelle war, die unser PC also als Empfänger erhält.

ACCEPT und DROP legen als Regelergebnis fest, ob ein Paket angenommen oder verworfen wird.

Zusätzlich ist an der Stelle darauf zu achten, welchen Verbindungsstatus eine Verbindung hat. Der Status einer Verbindung ist beim Versuch des Verbindungsaufbaus zunächst "NEW". Eine bereits bestehende Verbindung ist "ESTABLISHED" und zu einer bestehenden Verbindung können weitere "RELATED" Portverbindungen gehören.

Mein Fokus ist hier allerdings immer auf neue Verbindungen gerichtet. Damit sind alle Anfragen zur Kontaktaufnahme mit einem Dienst auf einem bestimmten Port auf einer anderen Maschine gemeint. Bereits etablierte Verbindungen oder zu etablierten Verbindungen zugehörige weitere relative Verbindungen sind in meinem Modell immer erlaubt.

Der Grund für diese Vorgehensweise ist einfach erklärt, eine ESTABLISHED-Verbindung muss schon zuvor bei der Prüfung auf State NEW genehmigt worden sein. Eine gleich zu Beginn abgewiesene Verbindung kann also nie ESTABLISHED werden, und nur erfolgreich etablierte Verbindungen können weitere RELATED-Verbindungen öffnen.

/etc/systemd/system/netfilter.service

Die Rechte-Einstellung für die Unit:         root:root 644

[Unit]

Description=thlu:netfilter.service:   Set local Netfilter

DefaultDependencies=no

After=network.target

[Service]

Type=simple

RemainAfterExit=yes

ExecStart=/usr/local/bin/netfilter

ExecStop= /usr/local/bin/netfilter flush

[Install]

WantedBy=multi-user.target

1.

Es ist grundsätzlich alles verboten

2.

Surfen (HTTP und HTTPS) sowie DNS-Anfragen und eine VPN-Verbindung nach Hause sind ausnahmsweise erlaubt.

/usr/local/bin/netfilter

Die Rechte-Einstellung für das Script:         root:root 755

#!/bin/bash

#=================================================================================================================

# Description:  Netfilter IPv4+6 for mobile PCs when connecting to unknown access points

# Version:      2.0

# Date:         11.12.2019

# Written by:   TomL*thlu.de

# Licence:      GNU General Public License 3

# Usage:        netfilter                      Set Netfilter IPv4/IPv4 via inet-family

#               netfilter flush                Flush Netfilter

#               netfilter list                 List all rules

#=================================================================================================================

PATH=/sbin:/usr/sbin:/bin:/usr/bin:$PATH

[ "$1" == "flush" ] && nft flush ruleset && exit 0

[ "$1" == "list" ] && nft list ruleset && exit 0

modprobe nf_conntrack

sysctl -w net.netfilter.nf_conntrack_helper=1 >/dev/null

#-----------------------------------------------------------------------------------------------------------------

nft flush ruleset

nft add table inet filter

nft add chain inet filter raw       "{ type filter hook prerouting  priority -300; counter; }"

nft add chain inet filter forward   "{ type filter hook forward     priority 0; policy drop; counter; }"

nft add chain inet filter input     "{ type filter hook input       priority 0; policy drop; counter; }"

nft add chain inet filter output    "{ type filter hook output      priority 0; policy drop; counter; }"

nft add rule inet filter raw meta l4proto tcp ct state new ip  daddr == 10.0.0.0/16 drop

nft add rule inet filter raw meta l4proto tcp ct state new ip6 daddr == { fd00:10:0::/48, 2000::/3, fe80::/16 } drop

nft add rule inet filter forward ct state related,established accept

nft add rule inet filter forward counter drop

nft add rule inet filter input ct state invalid counter drop

nft add rule inet filter input iifname lo accept

nft add rule inet filter input ct state established,related accept

nft add rule inet filter input counter reject

nft add rule inet filter output ct state established,related accept

nft add rule inet filter output ip protocol icmp accept

nft add rule inet filter output tcp dport    53 accept

nft add rule inet filter output udp dport    53 accept

nft add rule inet filter output tcp dport    80 accept

nft add rule inet filter output tcp dport   443 accept

nft add rule inet filter output udp dport 55553 accept

nft add rule inet filter output counter reject

exit 0

#=================================================================================================================

#EOF

table inet filter {

    chain raw {

        type filter hook prerouting priority -300; policy accept;

        meta l4proto tcp ct state new meta nfproto ipv4 ip daddr 10.0.0.0/16 drop

        meta l4proto tcp ct state new meta nfproto ipv6 ip6 daddr { 2000::/3, fd00:10:0::/48, fe80::/16 } drop

    }

    chain forward {

        type filter hook forward priority 0; policy drop;

        ct state established,related accept

        counter packets 0 bytes 0 drop

    }

    chain input {

        type filter hook input priority 0; policy drop;

        ct state invalid counter packets 0 bytes 0 drop

        iifname "lo" accept

        ct state established,related accept

        counter packets 0 bytes 0 reject

    }

    chain output {

        type filter hook output priority 0; policy drop;

        ct state established,related accept

        ip protocol icmp accept

        tcp dport 53 accept

        udp dport 53 accept

        tcp dport 80 accept

        tcp dport 443 accept

        udp dport 55553 accept

        counter packets 0 bytes 0 reject

    }

}

Conntrack-Module laden

Policies = DROP

ct state new = DROP

ct state established,related = ACCEPT

lo Traffic = ACCEPT

all other Traffic = REJECT

ct state established,related = ACCEPT

Ports 53, 80 und 443 = ACCEPT

Port 55553

Ports x, y und z

Solange ich mir darüber nicht im klaren bin, ist jede Aktion ein zielloser Schuss ins Blaue, der vielleicht trifft, vielleicht aber auch nicht. Trifft er nicht, ist die aktuelle Lage mit Paketfilter sogar schlechter als vorher ohne Paketfilter. Denn man wiegt sich in der trügerischen Sicherheit einer Firewall, die gar keine ist und somit natürlich überhaupt keinen Schutz gewährleistet.

Ohne ein konkretes Ziel zu haben und ohne Überprüfung, ob man am Ende dieses Ziel auch erreicht hat, hätte die Firewall meiner Meinung nach den gleichen Effekt, als würde ich an meine Fenster im Haus den nebenstehenden Aufkleber anbringen.... „wirklich sehr beeindruckend“ wird der Einbrecher denken, wenn gar kein Gitter montiert ist.... und richtig skurril wird es, wenn sich der Hauseigentümer wegen des Aufklebers auch noch sicher fühlt.

Funktion:

Dienst/App:

Erlaubnis für neue Verbindungen:

Fileserver

Samba

inbound

Mailserver  (IMAP)

Dovecot  (MDA)

inbound

Mailserver  (SMTP)

Postfix    (MTA)

inbound + outbound

Mailserver  (POP3)

Getmail  (MRA)

outbound

Cal/Card-DAV-Server

Radicale

inbound

VPN-Server

OpenVPN

inbound

Print-Server

Cups

inbound

Netzwerk-Drucker

Cups

outbound

VM-Server  (Virtual Machines, libvirt KVM)

VNC

inbound

10.0.1.0/24

IPv4

Das reguläre IPv4-Netzwerk                                                     

(Subnet = statisch)

10.0.8.0/24

IPv4

OpenVPN-Verbindungen via UDP Port 55553

(Subnet = statisch)      

10.0.9.0/24

IPv4

OpenVPN-Verbindungen via TCP (Fallback-Connect)

Client-Port 443 → Router Port 443 → VPN-Server Port 55554

(Subnet = statisch)

2001::/64

IPv6

IPv6-Netzwerk mit Global Unicast Adressen und täglich wechselndem Prefix

(Site-ID = wechselnd)

fd00:10:0:8::/64

IPv6

OpenVPN-Verbindungen via UDP Port 55553

(Subnet = statisch)  

55551

55552

55553

55554

1.

Weil ich keinen Einfluss darauf habe, welchen IP-Stack ein Prozess verwendet, muss der Traffic von IPv4 und IPv6 analog reguliert werden

2.

Die wegen Dual-Stack derzeit täglich stattfindende Zwangstrennung muss berücksichtigt werden

(ISP-IP-Wechsel = Neuer Prefix = Neue Side-ID für IPV6 auf den Client-PCs)

3.

Datenpakete durch VPN-Verbindungen eigener Mobilgeräte aus dem Internet müssen berücksichtigt werden

4.

Warum werden überhaupt Bash-Scripte verwendet und nicht die /etc/nftables.conf, um die Regeln persistent einzustellen?

Die Frage ist einfach zu beantworten, nämlich aus dem gleichen Grund, warum ich zuvor auch schon nicht iptables-save/restore verwendet habe, denn beiden Arten solcher Regel-Speicherung beinhalten die gleiche Schwäche. Es handelt sich in beiden Fällen um die Speicherung und den Restore von statischen Regeln, die immer gleich bleiben und die sich somit am besten für eine zustandslose Paketfilterung eignen. Das bedeutet u.a., dass auf diese Weise aktivierte Regeln während der ganzen Laufzeit eines Rechners/Servers statisch sind, also konstant immer gleich bleiben. Infolgedessen ist die Konsequenz, dass Filterregeln nicht auf aktuelle Veränderungen reagieren können, z.B. auf äußere Veränderungen durch einen ISP-Prefix-Wechsel. Und es bedeutet, dass sie auch nicht oder nur eingeschränkt auf bestimmte sich verändernde Inhalte innerhalb von Paketen reagieren können, z.B. durch eine explizite Behandlung von Ziel- oder Absender-IP-Adressen. Solch statisches Verhalten entspricht aber nicht meinen Anforderungen. Die Script-Generierung der Regeln beinhaltet hier ein deutlich höheres Maß an Flexibilität, gerade vor dem Hintergrund der sich täglich ändernden Site-ID.

1.

Es ist grundsätzlich alles verboten

2.

Erste Ausnahme:

Für explizit benannte Ports werden eingehende Pakete dann angenommen, wenn die Quelle des Pakets innerhalb des Heim-Netzwerks liegt, ansonsten gilt Pkt .1

3.

Zweite Ausnahme:

Für einige wenige explizit benannte Ports ist ausgehender Traffic erlaubt, ansonsten gilt Pkt. 1

Es ist kein Desktop-Environment installiert, es ist also keine (tatsächlich auch unnötige) grafische Benutzer-Oberfläche verfügbar

Es sind keine (ebenfalls unnötigen) redundanten Dienste installiert, wie z.B. rsyslog, networking, dhcpcd, ntp, networkmanager, avahi. Stattdessen ist ein Static-IP-Setup für IPv4 eingerichtet und systemd-Services wie networkd, timesyncd, resolved, journald sind aktiviert. Avahi ist im Regelfall überflüssig, wenn Client-Geräte ausschließlich über einen Router betrieben werden.

Lokale Anmeldungen durch User sind nicht möglich (Keine Eingabegeräte (Keyboard/Mouse) vorhanden, kein Bildschirm, also auch keine unmittelbaren Benutzer-Interaktionen)

Für IPv6 die Privacy Extensions aktivieren

Mit ss -tulpn den Server darauf überprüfen, welche Dienste auf welchen Ports pauschal auf dem aktiven Netzwerk-Interface ‚lauschen‘, ggf. diese Dienste auf localhost oder den lokalen Netz-Prefix einstellen

SSH-Anmeldungen nur mit Keyfile-Autorisierung erlauben (PubkeyAuthentication yes, PasswordAuthentication no). Sofern nicht für spezielle Routinen/Programme (z.B. für Backups) eine automatische SSH-Anmeldung mit root-Rechten ausdrücklich notwendig ist, root-Login verbieten (PermitRootLogin no).

Updates/Upgrades werden durch root ausschließlich manuell und nach Abschalten der FW durchgeführt. Weil auf dem System eh nur benötigte Dienste und Systemprogramme installiert sind, ist die Wahrscheinlichkeit sehr hoch, dass beim Upgrade gerade solche Dienste laufen und betroffen sind. Insofern erfordert das Upgrade sowieso einen Restart des Systems, wodurch die Firewall wieder neu initialisiert wird.

Für den DSL-Router empfehle ich die folgenden Einstellungen zu kontrollieren und ggf. anzupassen:

- Anspruchsvolles Zugangs-Password zu den Router-Einstellungen vergeben

- SSID ändern, wenn aus der eingetragenen der Router (Name, Typ) ermittelt werden kann

- WLAN-Verschlüsselung kontrollieren und ggf. WPA2/CCMP erzwingen

- Internetzugriff auf die FRITZ!Box bzw. den eigenen DSL-Router (Fernwartung) deaktivieren

- Internetzugriff über FTP auf die internen Speichermedien der Fritz!Box bzw. des eigenen DSL-Routers deaktivieren

- Zugang eigener mobiler WLAN-Clients an MAC-Adressen binden

- WPS-Schnellverbindung deaktivieren

- Gastzugriffe deaktivieren

- Übertragung Statusinformationen über UPnP deaktivieren

- Anbieter-Dienste über TR-069 deaktivieren!!! (Anmerk.: Wenn das Anbieterabhängig nicht möglich ist, würde ich heute sofort einen eigenen Custom-Router mit Firewall in Betrieb nehmen, um mein lokales Netzwerk vor dem DSL-Router zu schützen. Die TR-069-Schnittstelle ist faktisch eine Backdoor für Zugriffe von außen auf unseren Router und damit in unser Netzwerk und deswegen einer besonderen Beachtung wert.)

- In gewissen Abständen überprüfen, ob die Firmware unseres DLS-Routers noch aktuell ist oder ob Updates verfügbar sind

Mit verschiedenen Online-Tests einen Scan auf offene privilegierte Ports (1-1024) für TCP und UDP durchführen (Such-Stichwort Online Port-Scan, ggf. ergänzt mit IPv4 oder IPv6).

Benachrichtigung per Mail über VPN- und SSH-Anmeldeversuche vom Vortag.

/usr/local/bin/netfilter

Die Rechte-Einstellung für das Script:         root:root 755

ipv4_vpn="10.0.8.0/23"

ipv6_vpn="fd00:10:0:8::/63"

10.0.1.0/24

10.0.8.0/24

10.0.9.0/24

10.0.8.0/23

Conntrack FTP

GetNetw

# = Comment-Tags

Temporary Validity

Log-Einträge

Conntrack-State new

ICMP echo-request

ct state established,related accept

ICMPv4

ICMPv6

Ausdrücklich geöffnete Ports

VPN-Ports

Blackhole-Regeln

Ausdrücklich geöffnete Ports

VPN-Pakete

Drop TCP-Pakte mit SADDR

log prefix "Reject blacklisted IP:"

Mein eigenes Browser-Profil (User ‚thomas‘) wird grundsätzlich nicht zum Surfen im Internet verwendet, sondern nur für lokales Customizing (lokale Webinterfaces router, cups, radicale, meine eigenen Web-Seiten, etc.)

Für freies Surfen auf seriösen Seiten wird das Homedir-Profil eines völlig unberechtigten virtuellen Users verwendet, und zwar mit scharf eingestellten Ublock Origin und expliziter Seiten-Freigabe – d.h., ich verwende zur Prüfung keine fremden Listen, sondern greife auf hier im Laufe der Zeit gewachsene Einstellungen mit „allow“ und „block“ zurück.

Für ‚unseriöses‘ Surfen auf fragwürdigen Seiten verwende ich eine VM ohne Zugriffe auf das lokale Netzwerk und mit einem völlig rechtelosen User. Die VM enthält weder irgendwelche Anwender-Daten noch andere Anwendungen auẞer dem Browser. Ublock Origin ist wie zuvor scharf eingestellt, was bedeutet, dass die meisten Seiten erst nach Freigabe einzelner zur Seite gehörender Verbindungen und Scripte ansehbar sind.

Für Online-Banking verwende ich eine völlig isolierte VM, die mit allem anderen nichts zu tun hat und von nichts tangiert wird. Auch diese VM hat keine anderen Anwendungen außer dem Browser installiert. Ublock Origin erlaubt nur die Verbindung zur Bank, deshalb ist mit diesem Browser eigentlich kein sinnvolles Surfen möglich.

Zusätzlich ist auch noch Firejail installiert, mit dem ich dann doch noch mal in seltenen Fällen einen Youtube-Link öffnen kann…. was auch quasi der einzige Grund für mich ist, Firefox in einer Sandbox zu nutzen. Dieser Browser wird bei jedem neuen Start mit komplett neuem temporären Profil gestartet. In keinem meiner Browser-Profile sind Google-Domains erlaubt, also alles, was mit Google zu tun hat, ist mit Ublock Origin rigoros verboten. Wenn es aber in seltenen Fällen doch benötigt wird, ist eben Firejail die vorübergehende Lösung.

Schließlich müssen auch noch die von den Datenkraken angelegten und durchgezogenen Tracking-Linien oder -Spuren (über die Einschaltzeit des PC hinaus) unterbrochen werden. Dazu sollte bei jedem Sitzungsende des Browsers der Cache und angelegte Cookies manuell gelöscht werden, oder (was ich für die bessere Lösung halte) von vornherein immer nur im Private-Mode zu surfen, wodurch bei Sitzungsende alle vom Browser angelegten Daten automatisch gelöscht oder gar nicht erst angelegt werden.

Als letztes ist noch WebRTC-Detection zu disablen, um Local-IP-Leaks zu verhindern. Dazu entweder Java-Scripte generell verbieten, oder in Firefox:

about:config → media.peerconnection.enabled = false

Mit ss -tulpn den eigenen PC darauf überprüfen, welche Dienste auf welchen Ports pauschal auf dem aktiven Netzwerk-Interface ‚lauschen‘, ggf. diese Dienste auf localhost oder den lokalen Netz-Prefix einstellen

Unnötige bzw. redundante Dienste sind vollständig deinstalliert oder deaktiviert (siehe Hinweise bei Paketfilter für Server)

SSH-Anmeldungen nur mit Keyfile-Autorisierung erlauben (PubkeyAuthentication yes, PasswordAuthentication no). root-Login ist nicht erlaubt (PermitRootLogin no).

Für IPv6 die Privacy Extensions aktivieren

Der Remount von /home, /dev/shm und /tmp mit noexec,nosuid,nodev verhindert das direkte Ausführen eines Scripts oder Programms in diesen Verzeichnissen. Ja, ich weiss, über den Weg /bin/bash {name} geht das trotzdem, aber der Remount schützt zumindest den Anwender vor sich selber, der vielleicht gutgläubig ein Mail-Attachment speichern und per Click aus dem Dateimanager starten will. Und wer dann bewusst und vorsätzlich zur Umgehung der vorhandenen Beschränkungen Wege sucht und diese auch geht und damit ein nicht-erlaubtes Programm ausführt, der soll bitte noch mal oben die Absätze zum Thema „Saboteur“ nachlesen. Das ist dann definitiv kein Problem von Firewall, Antivir und Co, sondern ein „richtig fetter Compliance-Verstoß“.

Auf den Clients systemd-timesyncd auf den eigenen Router einstellen, den Router dafür als Timeserver im Netzwerk aktivieren

1.

Es ist grundsätzlich alles verboten

2.

Erste Ausnahme:

Für einige wenige explizit benannte Ports werden eingehende Pakete dann angenommen, wenn die Quelle des Pakets innerhalb des Heim-Netzwerks liegt, ansonsten gilt Pkt .1

3.

Zweite Ausnahme:

Für explizit benannte Ports ist ausgehender Traffic erlaubt, ansonsten gilt Pkt. 1

/usr/local/bin/netfilter

Die Rechte-Einstellung für das Script:         root:root 755

#!/bin/bash

#=================================================================================================================

# Description:  Client-Netfilter

# Version:      7.0.1

# Date:         23.06.2020

# Written by:   TomL*thlu.de

# Licence:      GNU General Public License 3

# Usage:        netfilter                      Set Netfilter IPv4 and IPv6

#               netfilter { 4 | 6 }            Set Netfilter IPv4 or IPv6

#               netfilter flush                Flush Netfilter

#               netfilter list                 List all rules

#=================================================================================================================

PATH=/sbin:/usr/sbin:/bin:/usr/bin:$PATH

[ "$1" == "flush" ] && nft flush ruleset && echo "netfilter flushed!" | systemd-cat -t "thlu:$(basename $0)" -p "warning"

[ "$1" == "list" ] && nft -nn list ruleset

[ -n "$1" ] && [ ! "$1" == "4" ] && [ ! "$1" == "6" ] && exit 0

echo "netfilter started!" | systemd-cat -t "thlu:$(basename $0)" -p "info"

modprobe nf_conntrack

modprobe nf_conntrack_ftp                                                                                   # FTP Application-Layer-Getway

#modprobe br_netfilter                                                                                      # enable Bridge-Filter

sysctl -w net.netfilter.nf_conntrack_helper=1 >/dev/null

ipv4=""

ipv6=""

ipv4_lan="127.0.0.0/8"

ipv6_lan="::1/128"

ipv4_netw=""

ipv6_netw=""

interface=""

tStart=$(date +%s)

tEnd=$(date +%s)

timeout=85

#=================================================================================================================

# Determine Network Site-Id's for IPv4+6 with waitstates (slaac may take some time)

GetNetw()

{

    tTmp=$(date +%s)

    NetwStack=$1

    ip=""

    while [ $timeout -gt 0 ]; do

        interface=$(ip route 2>/dev/null | grep default -m 1 | awk -F ' ' '{ print $5 }')

        if [ -n "$interface" ]; then

            ip=$(ip -$NetwStack -o addr show $interface | grep -v "deprecated\|^fd00" | grep "scope global" -m 1 | cut -d\  -f 7 | cut -d/ -f 1)

            [ -n "$ip" ] && break

        fi

        (( timeout-- ))

        sleep 1

    done

    tEnd=$(date +%s)

    if [ -z "$ip" ]; then

        echo "netfilter check NIC: terminated with error. IPv$NetwStack is not configured after $((tEnd-tTmp)) seconds waiting." | systemd-cat -t "thlu:$(basename $0)" -p "err"

        return 1

    else

        [ $NetwStack -eq 4 ] && ipv4_lan=$(echo $ip | cut -d'.' -f1-3)".0/24" && ipv4=$ip

        [ $NetwStack -eq 6 ] && ipv6_lan=$(echo $ip | cut -d':' -f1-4)"::/64" && ipv6=$ip

        echo "netfilter check NIC: $((tEnd-tTmp)) seconds waiting until IPv$NetwStack on $interface is configured" | systemd-cat -t "thlu:$(basename $0)" -p "info"

    fi

    return 0

}

#=================================================================================================================

SetInboundV4()

{

  nft add rule ip filter input ct state invalid counter drop                                                # Drop non-conforming packets (malformed headers, etc.)

  nft add rule ip filter input iifname lo accept                                                            # Allow loopback traffic

  nft add rule ip filter input ct state new           limit rate over 1/minute counter drop                 # limited number of packages allowed, drop flooding

  nft add rule ip filter input icmp type echo-request limit rate over 10/minute counter reject with icmp type host-unreachable

  nft add rule ip filter input ip protocol icmp                 ip saddr == $ipv4_netw accept               # Allow local icmp

  nft add rule ip filter input pkttype { broadcast, multicast } ip saddr == $ipv4_netw accept               # Allow local *cast-messages

  nft add rule ip filter input ct state established,related accept                                          # Allow established connections

  nft add rule ip filter input ip saddr $ipv4_netw tcp dport 55551 accept                                   # SSH

  nft add rule ip filter input ip saddr $ipv4_netw tcp dport 55552 accept                                   # VNC

  nft add rule ip filter input ip protocol tcp counter reject with tcp reset                                # TCP RST=Close TCP-Connect properly

  nft add rule ip filter input counter reject with icmp type port-unreachable                               # reject all other traffic

}

#=================================================================================================================

SetInboundV6()

{

  nft add rule ip6 filter input ct state invalid counter drop                                               # Similar to V4

  nft add rule ip6 filter input iifname lo accept

  nft add rule ip6 filter input ct state new             limit rate over 1/minute counter drop

  nft add rule ip6 filter input icmpv6 type echo-request limit rate over 10/minute counter reject with icmpv6 type port-unreachable

  nft add rule ip6 filter input meta l4proto ipv6-icmp           ip6 saddr == $ipv6_netw accept

  nft add rule ip6 filter input pkttype { broadcast, multicast } ip6 saddr == $ipv6_netw accept

  nft add rule ip6 filter input ct state established,related accept

  nft add rule ip6 filter input ip6 saddr $ipv6_netw tcp dport 55551 accept

  nft add rule ip6 filter input ip6 saddr $ipv6_netw tcp dport 55552 accept

  nft add rule ip6 filter input meta l4proto tcp counter reject with tcp reset

  nft add rule ip6 filter input counter reject with icmpv6 type port-unreachable

}

#=================================================================================================================

SetOutboundV4()

{

  nft add rule ip filter output oifname lo accept                                                           # Allow loopback traffic

  nft add rule ip filter output ip protocol icmp accept                                                     # Allow outgoing icmp

  nft add rule ip filter output pkttype { broadcast, multicast } accept                                     # Allow outgoing packet-types

  nft add rule ip filter output ct state established,related accept                                         # Allow established connections

  nft add rule ip filter output tcp dport    21 accept                                                      # FTP-Client

  nft add rule ip filter output tcp dport    25 accept                                                      # SMTP

  nft add rule ip filter output tcp dport    53 accept                                                      # DNS lookup

  nft add rule ip filter output udp dport    53 accept                                                      # DNS lookup

  nft add rule ip filter output tcp dport    80 accept                                                      # HTTP

  nft add rule ip filter output tcp dport   443 accept                                                      # HTTPS,OpenVPN (443->Router >>> VPNServer->55554)

  nft add rule ip filter output tcp dport   110 accept                                                      # POP3

  nft add rule ip filter output udp dport   123 accept                                                      # ntp

  nft add rule ip filter output tcp dport   143 accept                                                      # Mail

  nft add rule ip filter output tcp dport   445 accept                                                      # CIFS

  nft add rule ip filter output tcp dport   465 accept                                                      # SMTP (TLS/SSL)

  nft add rule ip filter output tcp dport   587 accept                                                      # SMTP

  nft add rule ip filter output tcp dport   631 accept                                                      # cups

  nft add rule ip filter output tcp dport   993 accept                                                      # IMAPS (TLS/SSL)

  nft add rule ip filter output tcp dport   995 accept                                                      # POP3S (TLS/SSL)

  nft add rule ip filter output tcp dport  5232 accept                                                      # radicale

  nft add rule ip filter output tcp dport  5901 accept                                                      # VNC-Tightviewer

  nft add rule ip filter output tcp dport 55551 accept                                                      # SSH

  nft add rule ip filter output tcp dport 55552 accept                                                      # VNC

  nft add rule ip filter output udp dport 55553 accept                                                      # OpenVPN

  nft add rule ip filter output counter reject with icmp type admin-prohibited

}

#=================================================================================================================

SetOutboundV6()

{

  nft add rule ip6 filter output oifname lo accept                                                          # Similar to V4

  nft add rule ip6 filter output meta l4proto ipv6-icmp accept

  nft add rule ip6 filter output pkttype { broadcast, multicast } accept

  nft add rule ip6 filter output ct state established,related accept

  nft add rule ip6 filter output tcp dport    21 accept

  nft add rule ip6 filter output tcp dport    25 accept

  nft add rule ip6 filter output tcp dport    53 accept

  nft add rule ip6 filter output udp dport    53 accept

  nft add rule ip6 filter output tcp dport    80 accept

  nft add rule ip6 filter output tcp dport   443 accept

  nft add rule ip6 filter output tcp dport   110 accept

  nft add rule ip6 filter output udp dport   123 accept

  nft add rule ip6 filter output tcp dport   143 accept

  nft add rule ip6 filter output tcp dport   445 accept

  nft add rule ip6 filter output tcp dport   465 accept

  nft add rule ip6 filter output tcp dport   587 accept

  nft add rule ip6 filter output tcp dport   631 accept

  nft add rule ip6 filter output tcp dport   993 accept

  nft add rule ip6 filter output tcp dport   995 accept

  nft add rule ip6 filter output tcp dport  5232 accept

  nft add rule ip6 filter output tcp dport  5901 accept

  nft add rule ip6 filter output tcp dport 55551 accept

  nft add rule ip6 filter output tcp dport 55552 accept

  nft add rule ip6 filter output udp dport 55553 accept

  nft add rule ip6 filter output counter reject with icmpv6 type admin-prohibited

}

#=================================================================================================================

SetForwardV4()

{

  nft add rule ip filter forward ct state related,established accept                                        # Allow established connections

  nft add rule ip filter forward counter drop

}

#=================================================================================================================

SetForwardV6()

{

  nft add rule ip6 filter forward ct state related,established accept                                       # Similar to V4

  nft add rule ip6 filter forward counter drop

}

#=================================================================================================================

nft flush ruleset

if [ -z "$1" ] || [ "$1" == "4" ]; then                                                                     # "" = both, only IPv4?

    GetNetw 4

    if [ $? -eq 0 ]; then

        ipv4_netw="$ipv4_lan"

        nft add table ip filter

        nft add chain ip filter forward "{ type filter hook forward priority 0; counter; }"

        nft add chain ip filter input "{ type filter hook input priority 0; counter; }"

        nft add chain ip filter output "{ type filter hook output priority 0; counter; }"

        SetInboundV4

        SetOutboundV4

        SetForwardV4

    fi

fi

if [ -z "$1" ] || [ "$1" == "6" ]; then

    GetNetw 6

    if [ $? -eq 0 ]; then

        ipv6_netw="{ $ipv6_lan, fd00::/16, fe80::/16 }"

        nft add table ip6 filter

        nft add chain ip6 filter forward "{ type filter hook forward priority 0; counter; }"

        nft add chain ip6 filter input "{ type filter hook input priority 0; counter; }"

        nft add chain ip6 filter output "{ type filter hook output priority 0; counter; }"

        SetInboundV6

        SetOutboundV6

        SetForwardV6

    fi

fi

#-----------------------------------------------------------------------------------------------------------------

echo "netfilter successfully activated after $(($(date +%s)-tStart)) seconds" | systemd-cat -t "thlu:$(basename $0)" -p "info"

exit 0

#-----------------------------------------------------------------------------------------------------------------

# Temporary validity:

echo "Paketfilter ist aktiv!"

sleep 2

$0  list

read -t 180 -p "180 Sekunden aktiver Paketfilter. ENTER zum Beenden oder warten..."

$0  flush

$0  list

exit 0

#=================================================================================================================

#EOF

conntrack state new

1.

Es ist grundsätzlich ein- und ausgehend alles verboten, einschließlich des Zugriffs auf Ressourcen des lokalen Netzwerkes

2.

Ausnahme: Der Zugriff auf das Internet ist erlaubt

/usr/local/bin/netfilter

Die Rechte-Einstellung für das Script:         root:root 755

#!/bin/bash

#=================================================================================================================

# Description:  Netfilter for a dubious-surfing-VM, to prevent access to home-network and local web-ressources

# Version:      2.0.1

# Date:         23.06.2020

# Written by:   TomL*thlu.de

# Licence:      GNU General Public License 3

# Usage:        netfilter                      Set Netfilter IPv4/6

#               netfilter flush                Flush Netfilter

#               netfilter list                 List all rules

#=================================================================================================================

PATH=/sbin:/usr/sbin:/bin:/usr/bin:$PATH

[ "$1" == "flush" ] && nft flush ruleset && echo "netfilter flushed!" | systemd-cat -t "thlu:$(basename $0)" -p "warning"

[ "$1" == "list" ] && nft -nn list ruleset

[ -n "$1" ] && exit 0

echo "netfilter started!" | systemd-cat -t "thlu:$(basename $0)" -p "info"

modprobe nf_conntrack

sysctl -w net.netfilter.nf_conntrack_helper=1 >/dev/null

ipv4=""

ipv6=""

ipv4_lan="127.0.0.0/8"

ipv6_lan="::1/128"

ipv4_netw=""

ipv6_netw=""

interface=""

tStart=$(date +%s)

tEnd=$(date +%s)

timeout=85

#=================================================================================================================

# Determine Network Site-Id's for IPv4+6 with waitstates (slaac may take some time)

GetNetw()

{

    tTmp=$(date +%s)

    NetwStack=$1

    ip=""

    while [ $timeout -gt 0 ]; do

        interface=$(ip route 2>/dev/null | grep default -m 1 | awk -F ' ' '{ print $5 }')

        if [ -n "$interface" ]; then

            ip=$(ip -$NetwStack -o addr show $interface | grep -v "deprecated\|^fd00" | grep "scope global" -m 1 | cut -d\  -f 7 | cut -d/ -f 1)

            [ -n "$ip" ] && break

        fi

        (( timeout-- ))

        sleep 1

    done

    tEnd=$(date +%s)

    if [ -z "$ip" ]; then

        echo "netfilter check NIC: terminated with error. IPv$NetwStack is not configured after $((tEnd-tTmp)) seconds waiting." | systemd-cat -t "thlu:$(basename $0)" -p "err"

        return 1

    else

        [ $NetwStack -eq 4 ] && ipv4_lan=$(echo $ip | cut -d'.' -f1-3)".0/24" && ipv4=$ip

        [ $NetwStack -eq 6 ] && ipv6_lan=$(echo $ip | cut -d':' -f1-4)"::/64" && ipv6=$ip

        echo "netfilter check NIC: $((tEnd-tTmp)) seconds waiting until IPv$NetwStack on $interface is configured" | systemd-cat -t "thlu:$(basename $0)" -p "info"

    fi

    return 0

}

#=================================================================================================================

GetNetw 4

GetNetw 6

ipv4_netw="{ $ipv4_lan }"

ipv6_netw="{ $ipv6_lan, fd00::/16, fe80::/16 }"

#-----------------------------------------------------------------------------------------------------------------

nft flush ruleset

nft add table inet filter

nft add chain inet filter input   "{ type filter hook input   priority 0; policy drop; counter; }"

nft add chain inet filter output  "{ type filter hook output  priority 0; policy drop; counter; }"

nft add chain inet filter forward "{ type filter hook forward priority 0; policy drop; counter; }"

nft add rule inet filter input iifname lo accept

nft add rule inet filter input ct state invalid counter drop

nft add rule inet filter input icmp   type echo-request limit rate over 10/minute counter reject with icmp type host-unreachable

nft add rule inet filter input icmpv6 type echo-request limit rate over 10/minute counter reject with icmpv6 type addr-unreachable

nft add rule inet filter input ip  protocol icmp       ip  saddr == $ipv4_netw accept

nft add rule inet filter input meta l4proto ipv6-icmp  ip6 daddr == $ipv6_netw accept

nft add rule inet filter input pkttype { broadcast, multicast } accept

nft add rule inet filter input ct state established,related accept

nft add rule inet filter input counter reject with icmp type host-unreachable

nft add rule inet filter output ct state established,related accept

nft add rule inet filter output pkttype { broadcast, multicast } accept

nft add rule inet filter output ip protocol icmp       ip  daddr != $ipv4_netw accept

nft add rule inet filter output meta l4proto ipv6-icmp ip6 daddr != $ipv6_netw accept

nft add rule inet filter output tcp dport 53 accept

nft add rule inet filter output udp dport 53 accept

nft add rule inet filter output tcp dport { 80, 443 }  ip  daddr != $ipv4_netw accept

nft add rule inet filter output tcp dport { 80, 443 }  ip6 daddr != $ipv6_netw accept

nft add rule inet filter output counter reject with icmp type admin-prohibited

nft add rule inet filter forward ct state related,established accept

nft add rule inet filter forward counter drop

echo "netfilter successfully activated after $(($(date +%s)-tStart)) seconds" | systemd-cat -t "thlu:$(basename $0)" -p "info"

exit 0

#=================================================================================================================

#EOF

ICMP

ipv4_netw und  ipv6_netw

ipv6

# Permit needed ICMP packet types for IPv6 per RFC 4890

# 4.4.  Recommendations for ICMPv6 Local Configuration Traffic          Type                                                    NFT symbolic alias

---------------------------------------------------------------------------------------------------------------------------------------------------------------------

table ip6 tfilter {

    chain input {

        type filter hook input priority 0; policy accept;

        icmp type 1 accept                                              #   1 - Destination Unreachable                         destination-unreachable

        icmp type 2 accept                                              #   2 - Packet Too Big                                  packet-too-big

        icmp type 3 accept                                              #   3 - Time Exceeded                                   time-exceeded

        icmp type 4 accept                                              #   4 - Parameter Problem                               source-quench

        icmp type 128 accept                                            # 128 - Echo Request                                    echo-request

        icmp type 129 accept                                            # 129 - Echo Reply                                      echo-reply

        icmp type 133 accept                                            # 133 - Router Solicitation                             nd-router-solicit

        icmp type 134 accept                                            # 134 - Router Advertisement                            nd-router-advert

        icmp type 135 accept                                            # 135 - Neighbor Solicitation                           nd-neighbor-solicit

        icmp type 136 accept                                            # 136 - Neighbor Advertisement                          nd-neighbor-advert

        icmp type 137 accept                                            # 137 - Redirect Message                                nd-redirect

        icmp type 141 accept                                            # 141 - Inverse Neighbor Discovery                      -

        icmp type 142 accept                                            # 142 - Inverse Neighbor Discovery                      -

        icmp type 148 accept                                            # 148 - Certification Path Solicitation Message         -

        icmp type 149 accept                                            # 149 - Certification Path Advertisement Message        -

        icmp type 130 ip6 saddr fe80::/10 accept                        # 130 - Multicast Listener Query                        mld-listener-query

        icmp type 131 ip6 saddr fe80::/10 accept                        # 131 - Multicast Listener Report                       mld-listener-report

        icmp type 132 ip6 saddr fe80::/10 accept                        # 132 - Multicast Listener Done                         mld-listener-reduction

        icmp type 143 ip6 saddr fe80::/10 accept                        # 143 - Version 2 Multicast Listener Report             -

        icmp type 151 ip6 saddr fe80::/10 accept                        # 151 - Multicast Router Advertisement                  -

        icmp type 152 ip6 saddr fe80::/10 accept                        # 152 - Multicast Router Solicitation                   -

        icmp type 153 ip6 saddr fe80::/10 accept                        # 153 - Multicast Router Termination                    -

    }

}

10.0.1.0

IPv4

10.0.8.0

IPv4

10.0.9.0

IPv4

fd00:10:0:8::/64

IPv6

fd00:10:0:9::/64

IPv6

2001:db8:f3:40/56

IPv6

lokaler Router

198.51.100.34

IPv4

2001:db8:f3:40::1/64

IPv6

10.0.1.1/24

IPv4

2001:db8:f3:40:cc29:baff:fed9:22/64 

IPv6

lokaler Client-PC

2001:db8:f3:40::25/64

IPv6

10.0.1.25/24

IPv4