OpenSnitch Interaktive Anwendungs-Firewall für GNU/Linux

 (github.com/evilsocket)
3 Punkte von GN⁺ 2024-08-11 | 1 Kommentare | Auf WhatsApp teilen
  • OpenSnitch ist eine Anwendungs-Firewall für GNU/Linux mit dem Schwerpunkt, externe Verbindungen von Anwendungen interaktiv zu filtern
  • Systemweit können Werbe-, Tracker- und Malware-Domains blockiert werden, und in der GUI lässt sich auch eine nftables-basierte System-Firewall konfigurieren
  • Die GUI unterstützt die Konfiguration von Systemregeln wie dem Festlegen von Eingangsrichtlinien und dem Erlauben eingehender Dienste; außerdem können mehrere Nodes zentral verwaltet werden
  • Die Installation erfolgt durch Herunterladen von deb/rpm-Paketen und deren Installation mit apt oder dnf; anschließend wird opensnitch-ui ausgeführt oder die GUI über das Anwendungsmenü geöffnet
  • Es gibt einen Show and tell-Diskussionsbereich zum Teilen von Fällen, in denen unerwartete Verbindungen abgefangen wurden, sowie SIEM-Integration, die sich zur Verbindungsüberwachung in Betriebsumgebungen nutzen lässt

Was OpenSnitch macht

Firewall- und Node-Verwaltung

  • In der GUI kann die System-Firewall-Konfiguration eingerichtet werden
    • Dabei geht es um nftables-basierte Einstellungen
    • Eingangsrichtlinien, das Erlauben eingehender Dienste usw. können festgelegt werden
  • In der zentralen GUI können mehrere Nodes verwaltet werden
  • SIEM-Integration wird unterstützt

Download und Installation

  • deb/rpm-Pakete können über GitHub Releases heruntergeladen werden
  • Installation des deb-Pakets:
    • sudo apt install ./opensnitch*.deb ./python3-opensnitch-ui*.deb
  • Installation des rpm-Pakets:
    • sudo dnf install opensnitch*.rpm
  • Nach der Installation opensnitch-ui ausführen oder die GUI über das Anwendungsmenü starten
  • Detaillierte Installationsinformationen finden sich in der Dokumentation

Anwendungsfälle und Beteiligung

Projektinformationen

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-08-11
Hacker-News-Kommentare

  • Ich habe oft versucht, OpenSnitch als interaktive Firewall zu nutzen, aber es gibt ein Problem, bei dem ich nicht einmal weiß, ob es lösbar ist – und das ist nicht unbedingt OpenSnitchs Schuld.
    Wenn man zum Beispiel im Terminal curl ausführt, muss man jedes Mal entscheiden, ob es erlaubt werden soll, oder es dauerhaft auf die Allowlist setzen.
    Wenn man aber allgemeine Tools wie curl oder wget erlaubt, kann Malware auf einer kompromittierten Maschine diese Tools ebenfalls nutzen, um ohne Firewall-Benachrichtigung ins Internet zu gelangen – damit steht die Tür weit offen.

    • Mit Subdomain-Wildcards oder Subnetzen baut man recht schnell einen stabilen Regelsatz auf, und danach muss man nur noch gelegentlich neue Endpoint-Anfragen prüfen.
      Das beruhigende Gefühl, bei neuem Zugriff gefragt zu werden, macht den anfänglichen Aufwand wett, und wenn man sich daran gewöhnt hat, ist die Verwaltung ziemlich einfach.
      Ich nutze auch häufig Regeln mit Ablaufdatum. Wenn ich zum Beispiel einem Installer vertraue und ihm vorübergehend freie Hand lassen möchte, erstelle ich für die ausführbare Datei eine Regel, die in naher Zukunft abläuft. Die Optionen sind dauerhaft, bis zum Neustart, die nächsten 30 Sekunden, die nächsten 5 Minuten usw.; dadurch werden auch Aufgaben mit vielen Endpoints deutlich einfacher, ohne dauerhafte Löcher zu hinterlassen.
    • Es scheint auch möglich zu sein, für den Benutzer dev sämtlichen curl-/wget-Traffic zu erlauben und ihn beim Benutzer normal weiterhin zu erkennen.
      Entwicklungsaufgaben würde man dann etwa mit su -c curl … dev ausführen.
      Wenn ein bösartiges Programm im normalen Benutzerbereich läuft, kann die App-Firewall die Nutzung von curl und wget angemessen erkennen.
      Da es lästig ist, jedes Mal ein Passwort einzugeben, könnte man PAM mit YubiKey oder biometrischer Authentifizierung konfigurieren; außerdem sollte dieser Benutzer sich nicht einloggen können und kein Passwort haben.
    • Das klingt etwas seltsam. Wenn man sich wirklich Sorgen macht, kann man curl oder wget auch umbenennen.
      Ich nutze auf Mobilgeräten eine Firewall auf Anwendungsebene, aber ich setze nicht Programmnamen auf eine Allowlist, sondern erlaube bestimmten Programmen den Zugriff auf bestimmte Domains/IP-Adressen.
      Meiner Erfahrung nach ist die einfachste Methode, externe Kommunikation von Programmen oder Malware zu verhindern, der DNS-Zugriff zu blockieren. Das mache ich seit Jahrzehnten so, und es funktioniert immer noch perfekt. „99 %“ der Programme/Malware, die nach außen kommunizieren, verlassen sich auf DNS statt auf hartcodierte IPs.
      Die seltenen Programme/Malware, die kein DNS benötigen, sind ebenfalls leicht zu erkennen, und bei DNS erlaube ich nur bestimmte Domains. Heutzutage nutze ich nicht einmal mehr lokale Zone-Dateien mit den benötigten IP-Adressen; ein Forward-Proxy übernimmt das Domain-zu-IP-Mapping. Die Allowlist, die der Proxy liest, ist ähnlich wie eine Zone-Datei, aber eine noch einfachere Textdatei.
    • Ich frage mich, ob man es so konfigurieren könnte, dass curl durchgelassen wird, wenn der Parent-Befehl ein vertrauenswürdiger Befehl ist, etwa ein vom Benutzer besessenes bash/zsh, und sonst blockiert wird. Das wirkt allerdings ziemlich umständlich.
    • Solche Probleme sind lösbar. Einige große EDR-Produkte, die auf ähnliche Weise funktionieren, können Parent-/Child-Beziehungen für zu blockierende ausführbare Dateien deklarieren.
      Wenn zum Beispiel curl ausgeführt wurde und man beim Hochlaufen der Parent-Kette auf einen Prozess /usr/bin/trusted stößt, sollte man deklarieren können, dass dieser curl-Aufruf erlaubt ist. Dann könnte man curl in einem Bash-Skript erlauben, solange der Parent dieses Skripts /usr/bin/trusted ist.

  • Das war letztlich der Grund, warum ich zu NixOS gewechselt bin.
    Als ich früher eine Application-Firewall nutzte, gab es viel Konfigurationsaufwand; wenn Updates Pfade änderten, ging häufig etwas kaputt, und bei jedem neuen Rechner musste ich alles neu machen – viel Churn und Verschwendung.
    Durch die Integration mit dem Paketmanager sind diese Probleme verschwunden. Sobald die anfängliche Allowlist eingerichtet ist, ist nur noch ein bisschen Arbeit nötig, wenn ich der Nix-Konfiguration ein neues Paket hinzufüge.
    Wenn es mir zu lästig ist, die Allowlist in die Nix-Konfiguration aufzunehmen, füge ich einfach eine temporäre Allowlist hinzu, die nur bis zum nächsten Neustart gilt. Die Lernkurve war steil und es war viel Arbeit, aber jetzt ist die Wartung sehr einfach.

    • Ich frage mich, ob das mit den OpenSnitch-Nix-Optionen auf search.nixos.org/options umgesetzt wurde.

  • Gut, um schlampige Apps aufzuspüren, die übermäßig viele Verbindungen aufbauen. Thunderbird, du bist gemeint.
    Ich mag es, aber es gibt auch kleine Unannehmlichkeiten. Abgelaufene temporäre Regeln werden im Interface nicht gelöscht oder ausgeblendet, daher muss ich manchmal die GUI neu starten, um sie loszuwerden.

    • Ich sage es nur ungern, aber ein PR wäre sicher willkommen. Natürlich habe auch ich selbst kaum Zeit dafür.

  • Unter Fedora würde ich das empfehlen, statt mit firewalld/firewall-config herumzubasteln.

  • Ich fände so eine Funktionalität gut, wenn man APIs oder Webdienste in Docker-Containern betreibt.
    containerA: gesamten ausgehenden Traffic erlauben
    containerB: ausgehenden Traffic blockieren, außer beim Antworten an Clients
    containerC: darf nur auf updates.example.com zugreifen
    Ist das einfach iptables pro Container? Man könnte iptables wohl in bestehende Images einbauen, aber das wirkt nach viel Arbeit. Oder macht man das auf dem Host mit iptables?

    • Ich möchte ergänzen, dass netfilter, also das, wofür iptables als Frontend dient, ein Kernel-Subsystem ist und daher global für alle Container auf dem Host gilt.

  • Gibt es so etwas auch für Android-Smartphones? Ich wäre an guten Empfehlungen interessiert.

    • Es gibt NetGuard. Allerdings liegen die meisten Komfortfunktionen hinter einem kleinen In-App-Kauf.
      https://netguard.me
    • GrapheneOS kann zumindest den Internet-Traffic bestimmter Apps blockieren. Allerdings nicht nach Portbereichen oder einzelnen Domains.
    • Leider benötigen echte Firewalls alle Root-Rechte.
      Ich habe lange AFWall+ genutzt; die Steuerung, pro App Wi‑Fi, Mobilfunk und LAN zu erlauben oder zu blockieren, ist sauber. Da es ein iptables-/nftables-Frontend ist, kann man Regeln so stark anpassen, wie man möchte: https://github.com/ukanth/afwall
      Funktioniert ab Android 2+.
      Ohne Root bleiben nur VPN-basierte Lösungen wie Adguard.
      Wenn man Statistiken braucht, gibt es auch die Android-Version von GlassWire. Ich habe nur die Beta ausprobiert und kenne den aktuellen Stand nicht, aber ein Blick lohnt sich.
    • Die App "Rethink: DNS + Firewall + VPN" hat ähnliche Funktionen.
    • AFWall+
      Ich bin von dem oben erwähnten NetGuard darauf umgestiegen.

  • Arch- und OpenSUSE-Pakete wären auch schön.

    • Für Arch Linux gibt es ein offizielles Paket. Aus irgendeinem Grund enthält es allerdings das eBPF-Modul nicht, das man separat aus dem AUR holen muss.
    • Im extra-Repository von Arch gibt es opensnitch, und im AUR gibt es opensnitch-ebpf-module.

  • Wie ist das im Vergleich zu so etwas wie UFW? Ich frage mich, ob der Kern die UI ist, mit der man laufende Aktivitäten sieht.

    • OpenSnitch fragt nach, wenn Netzwerkaktivität auftritt.
      Wenn eine beliebige App zum Beispiel einen Telemetrie-Call macht, kann man sehr fein eine White-/Greylist festlegen – etwa ob nur die Verbindung von dieser ausführbaren Datei zu dieser Adresse erlaubt werden soll oder ob diese Adresse immer erlaubt ist –, dazu mit Zeitoptionen wie nur einmal, für 15 Sekunden oder bis zum Neustart.
      Wenn man die anfängliche Hürde genommen hat, die Apps, die man nutzt und denen man vertraut, auf die Allowlist zu setzen, ist es ziemlich gut und zeigt einem vieles darüber, was Apps oder Spiele tun, von dem man nichts wusste.
    • Soweit ich weiß, ist UFW keine Application-Firewall, sondern blockiert/erlaubt nur systemweite Portnummern.

  • Gibt es Pläne, das auf macOS zu portieren? Ich habe eine Zeit lang Little Snitch genutzt, bevorzuge aber aus Gründen, die nichts mit Bezahlung zu tun haben, Open Source.

    • Probier LuLu aus.

  • Ich habe mehrmals sporadisch versucht, es zu nutzen, aber wegen zu vieler zufälliger Abstürze war es ziemlich schwer zu verwenden.