Most Linux firewalls watch traffic coming in. Almost none of them ask what your applications are sending out. The OpenSnitch firewall flips that model: every time a process tries to open an outbound connection, you get a prompt asking whether to allow it. It is the closest thing Linux has to Little Snitch on macOS, and after running it for a few weeks I can tell you it is eye-opening. Text editors phone home. Package managers check telemetry endpoints. A random Electron app I installed once tried to reach three analytics domains before the window even rendered.
This guide walks through installing OpenSnitch on a Debian-based system, answering your first prompts without breaking your desktop, and writing rules that hold up over time.
1. Install the OpenSnitch Firewall on Debian and Ubuntu
OpenSnitch ships as two packages: the daemon that hooks into the kernel, and a Qt GUI that shows prompts and statistics. Grab both .deb files from the OpenSnitch releases page on GitHub and install them:
wget https://github.com/evilsocket/opensnitch/releases/download/v1.6.9/opensnitch_1.6.9-1_amd64.deb
wget https://github.com/evilsocket/opensnitch/releases/download/v1.6.9/python3-opensnitch-ui_1.6.9-1_all.deb
sudo apt install ./opensnitch_1.6.9-1_amd64.deb ./python3-opensnitch-ui_1.6.9-1_all.debOn Debian 12 and later, both packages also live in the official repos, so sudo apt install opensnitch python3-opensnitch-ui works too. The repo version lags behind GitHub by a few releases, which matters here because the interception logic gets regular fixes.
Start the daemon and confirm it is running:
sudo systemctl enable --now opensnitchd
systemctl status opensnitchdThen launch opensnitch-ui from your application menu. Without the UI running, the daemon applies a default action to anything it cannot ask you about, so keep it in your autostart.
2. How the Daemon Actually Intercepts Traffic
The daemon uses eBPF to watch for new outbound connections and matches each one to the process that created it. When no existing rule covers the connection, the OpenSnitch firewall forwards the question to the GUI over a local gRPC socket. Your answer becomes a rule.
This process-level view is the whole point. iptables and nftables filter by port and address. The OpenSnitch firewall filters by executable path, command line, user ID, and destination host. Blocking port 443 is useless when everything speaks HTTPS. Blocking /usr/bin/obscure-updater from reaching telemetry.example.com is precise.
3. Answer Your First OpenSnitch Firewall Prompts
The first hour is noisy. Expect prompts from your browser, DNS resolver, NTP client, and every background service you forgot existed. Each prompt shows the process path, the destination IP or hostname, the port, and a dropdown for how long the rule should last.
Three habits make this phase painless:
- Allow forever, but scope tightly: for known tools like
firefoxorapt, allow the process permanently rather than answering the same prompt daily. - Use “for this session” on anything you don’t recognize: it buys you time to research the process without writing a permanent rule.
- Deny by domain, not by IP: CDN-backed services rotate IPs constantly. A rule pinned to one IP silently stops matching.
The default timeout matters more than people think. If you walk away and a prompt expires, the daemon applies the default action, which is allow in the stock config. I flip this to deny on laptops I care about. Edit /etc/opensnitchd/default-config.json and set DefaultAction to deny. Just do it after your common apps already have allow rules, or your first coffee break will log you out of everything.
4. Write Rules That Survive Updates
An OpenSnitch firewall rule that matches the full command line breaks the moment a package update changes a flag. When the GUI prompt appears, click the advanced view and match on the executable path alone unless you have a reason not to.
For interpreters the story is different. Allowing /usr/bin/python3 outright means any Python script on the machine inherits network access. For those, match path plus command line, accepting that you will re-answer prompts occasionally. That trade is worth it.
5. Manage OpenSnitch Firewall Rules from Files
Every rule is a JSON file under /etc/opensnitchd/rules/. This makes the OpenSnitch firewall friendly to version control and config management. A rule blocking one binary from one domain looks like this:
{
"name": "deny-updater-telemetry",
"enabled": true,
"action": "deny",
"duration": "always",
"operator": {
"type": "list",
"list": [
{"type": "simple", "operand": "process.path", "data": "/usr/bin/obscure-updater"},
{"type": "regexp", "operand": "dest.host", "data": ".*\\.telemetry\\.example\\.com"}
]
}
}Drop a file in that directory and the daemon picks it up without a restart. I keep my rules in a git repo and deploy them with chezmoi alongside my dotfiles, which means a fresh install starts with sane outbound policy from minute one.
6. Read the Statistics Before You Tighten Anything
The OpenSnitch firewall GUI logs every connection decision in its Events tab. Sort by process and let it run for a day before writing deny rules. The data answers questions you did not know to ask. In my case: a PDF reader resolving a fonts CDN on every launch, and node processes from an old project’s file watcher hitting an npm registry hourly.
Pair this visibility with host-level hardening. Outbound control complements inbound protection from tools like fail2ban or CrowdSec, it does not replace them. One watches what tries to get in, the other watches what tries to get out.
7. When the OpenSnitch Firewall Is the Wrong Tool
On a busy server, interactive prompts make no sense. Nobody is sitting at the console to answer them, and the default action ends up deciding everything. There you want nftables with a strict egress policy, written once and audited on schedule.
Containers are awkward too. The daemon sees connections from container runtimes, but attributing them to the right workload inside the container gets murky. And on machines where you run heavy peer-to-peer software, the rule count grows fast enough to become its own maintenance chore.
For a desktop or a laptop, though, the OpenSnitch firewall answers a question no other stock Linux tool does: what is this machine telling the rest of the internet? The project wiki covers rule syntax and eBPF requirements in depth if you want to go further. Install it, watch the prompts for a week, and you will not want to go back to flying blind.