Install

OpenSnitch on Debian / Ubuntu (the official .debs are on GitHub releases):

OS_VER=1.6.7   # check github.com/evilsocket/opensnitch/releases for current

# The daemon
curl -L -o /tmp/opensnitch.deb \
    "https://github.com/evilsocket/opensnitch/releases/download/v${OS_VER}/opensnitch_${OS_VER}-1_amd64.deb"
sudo apt install /tmp/opensnitch.deb

# The Qt GUI (or use the Python flet GUI separately)
curl -L -o /tmp/opensnitch-ui.deb \
    "https://github.com/evilsocket/opensnitch/releases/download/v${OS_VER}/python3-opensnitch-ui_${OS_VER}-1_all.deb"
sudo apt install /tmp/opensnitch-ui.deb

sudo systemctl enable --now opensnitch

On Arch: pacman -S opensnitch opensnitch-ui. On Fedora: a COPR repo or build from source.

How it works

OpenSnitch has two parts:

  • opensnitchd — a system service that intercepts outbound packets via Netfilter's NFQUEUE (or eBPF on newer setups). For each new connection, it looks up an existing rule; if none matches, it asks the UI for a decision and either allows or drops the packet.
  • opensnitch-ui — a per-user GUI that displays prompts, manages rules, shows a live event log, and surfaces per-process connection statistics.

The UI must be running for new connections to get a decision — if it isn't, OpenSnitch defaults to allow (or block, configurable). For a server-style headless setup, run the UI on a remote host via the gRPC backend, or pre-write rules so prompts never happen.

First connection

Open the system browser; visit any HTTPS site. OpenSnitch pops up a dialog:

firefox is trying to connect to 142.250.181.196:443 (TCP)

Action: [ Allow | Deny ]
Duration: [ once | 30s | 5m | until reboot | forever ]
Target:   [ this IP | this domain | the parent process | this user ]

Click Allow forever + this domain, and a rule is written. Subsequent connections from Firefox to google.com don't prompt — they match the rule.

Rules live in /etc/opensnitchd/rules/ as one JSON file per rule. Editable by hand; reloaded by the daemon automatically.

Rule scoping

Three useful axes when allowing a connection:

  • Process path — the exact binary. "Allow /usr/bin/firefox" but not other browsers.
  • Process command line — useful when the same binary serves multiple purposes. "Allow python /home/me/script.py" but not other Python invocations.
  • User — "Allow only when running as amir." Catches root-owned daemons making unexpected connections.

For destination:

  • Exact IP — brittle but precise.
  • Domain — matches whatever the process resolves; the resolver is observed in flight.
  • Regex on domain — .*\.github\.com$ covers raw.githubusercontent.com plus api.github.com plus the web UI.

Tame the noise on a fresh install

The first day is the loudest — expect dozens of prompts as you exercise the system normally. Two ways to reduce friction:

  1. Pre-populate rules from the OpenSnitch project's curated rule sets. The rules folder in the GitHub repo ships sensible defaults for common Linux distros (package manager, distro telemetry opt-outs, etc.). Drop them in /etc/opensnitchd/rules/.
  2. Start in “auto-allow” mode for a day or two to build a baseline rule set, then switch to interactive. The first time a known-good app makes a connection, OpenSnitch silently auto-allows it; you review the resulting rule set later and remove anything questionable.

The event log

The UI's "Events" tab shows every connection the daemon observed, even ones that matched an existing rule. Filter by process, destination, action. For a "what's actually phoning home" audit, leave it running for an hour during normal use and skim the list.

Two patterns worth looking for:

  • Heartbeats to vendor telemetry endpoints — common in proprietary software. Decide whether to allow or block based on the app's actual disclosure of what it sends.
  • Connections by background helpers — updaters (snapd, packagekit), DNS lookups by mDNS, peer discovery (KDE Connect). Recognize them once, allow forever.

eBPF backend

OpenSnitch 1.6+ can use an eBPF backend instead of NFQUEUE. The advantage is lower per-packet overhead at high throughput; the disadvantage is that the eBPF programs need a recent kernel and BTF (see eBPF tutorial). For a workstation, the NFQUEUE backend is fine and is the default.

Server-side OpenSnitch

The same daemon, with rules pre-written and the UI disabled, is useful on servers as an egress filter: a Python script that should only reach api.example.com is locked to exactly that. Combined with a default-deny system firewall (ufw, nftables), it gives precise per-process control where the system firewall alone can only do per-port.

What it doesn't replace

  • System firewalls for inbound traffic — ufw / firewalld / nftables. OpenSnitch is outbound-focused.
  • Network-level filtering — for "block this CDN at the router level," use Pi-hole (see that tutorial) or OPNsense.
  • Application sandboxing — Flatpak / Bubblewrap / Firejail isolate filesystem and IPC, not just network.

For "what apps on this machine are talking to the internet, and do I approve of each one," OpenSnitch is the most direct tool available on Linux in 2026.