OpenSnitch is a GNU/Linux interactive application firewall

Original Article ↗ Hacker News Discussion ↗

OpenSnitch, an open-source interactive application firewall for Linux, is drawing interest as a way to see and control which programs can access the network on a per-connection basis, similar to Little Snitch on macOS. Commenters weigh its security benefits—especially against telemetry and supply-chain attacks—against the overhead of frequent permission prompts and rule management, noting that habits, wildcard rules, and temporary allowances are crucial to making it usable. Related tools on macOS and Android, packaging status on various Linux distributions, and integrations with systems like NixOS and Qubes OS round out a broader debate on how practical strict outbound filtering really is on everyday machines.

Platform availability and integration

  • OpenSnitch is packaged for Arch Linux (opensnitch in extra; eBPF module via AUR). Some users want OpenSUSE packages.
  • On Fedora, several prefer it over firewalld/firewall-config.
  • One user integrates it tightly with NixOS: rules are defined in Nix modules per package, which avoids churn across machines and upgrades.

Use cases, benefits, and effectiveness

  • Widely seen as useful to:
    • Catch “sloppy” or chatty apps (e.g., email clients making many connections).
    • Reveal unexpected connections from otherwise “trusted” apps (e.g., calculator fetching FX rates).
    • Limit damage of exploits: default-deny app firewalls can block exfiltration and C2 traffic.
  • Some say it has concretely prevented unwanted telemetry and license checks (comparison to Little Snitch blocking Adobe phone-home).

Usability and UX trade‑offs

  • Experiences differ sharply:
    • Some report only a few new rules per week after initial setup, calling the overhead small and the prompts reassuring.
    • Others find even a couple of prompts per week too disruptive and don’t want to “manage their workstation.”
  • Helpful features mentioned:
    • Per-executable rules with duration (once, 30s, 5m, until reboot, forever).
    • Wildcards (subdomains/subnets) and argument-based rules.
  • Desired improvements:
    • Better temporary/context rules (per PID, parent chain, port ranges for games).
    • Clearer handling of expired temporary rules in the UI.
  • At least one person reports frequent crashes that make it hard to rely on.

Security model and limitations

  • Core concern: once generic tools like curl/wget are whitelisted, malware can reuse them to bypass intent.
  • Proposed mitigations:
    • Rules keyed by executable hashes, not just paths or PIDs.
    • Policies based on process parent/child chains (EDR-style “only allow curl if spawned by trusted parent”).
    • Context-based modes (e.g., a special “dev” context or user).
  • Discussion of depth of inspection:
    • Domain/SNI-based filtering vs need to decrypt TLS.
    • Limitations with Encrypted SNI and DNS-over-HTTPS.
    • Alternative strategy: DNS whitelisting (sometimes via a forward proxy).

Alternatives and related tools

  • macOS: LuLu (open source) and Little Snitch (more polished UX but paid).
  • Android: AFWall+ (root, iptables), NetGuard, Rethink DNS+Firewall, TrackerControl, and ROM-level firewalls in GrapheneOS/Lineage/Calyx; debate over reliability of VPN-based vs root-based firewalls.
  • Isolation-heavy alternative: Qubes OS to sandbox apps in VMs, though GPU/Wayland and battery issues are noted.
  • Containers: idea of per-container egress policies; reminder that netfilter/iptables is global at the host level.