Most Linux users are aware that iptables or nftables can block incoming connections. Fewer realize that outbound connections — your applications phoning home to update servers, telemetry endpoints, and analytics platforms — go unchecked by default. OpenSnitch is an application-level firewall for Linux that intercepts every outbound connection and lets you allow or block it per application. This guide covers installation, initial configuration, rule building, and practical use.

What OpenSnitch Does

OpenSnitch works by hooking into the Linux kernel via Netfilter and intercepting outbound network connections before they’re established. When an application tries to connect to the internet for the first time, OpenSnitch pops up a dialog asking what you want to do:

Allow once
Allow for this session
Allow forever (create a permanent rule)
Deny once / deny forever

You build up a rule set over time, telling OpenSnitch what each application is allowed to reach. Once rules are in place, normal traffic flows silently. You only see prompts for new or unrecognized connection attempts.

This is conceptually similar to Little Snitch on macOS or GlassWire on Windows, but open source and designed for Linux.

Installing OpenSnitch

From GitHub Releases (Recommended)

The most reliable method is using the pre-built packages from the OpenSnitch GitHub releases page:

# Download the latest .deb package (for Debian/Ubuntu)
wget https://github.com/evilsocket/opensnitch/releases/download/v1.6.6/opensnitch_1.6.6-1_amd64.deb
wget https://github.com/evilsocket/opensnitch/releases/download/v1.6.6/python3-opensnitch-ui_1.6.6-1_all.deb

# Install the daemon first, then the UI
sudo dpkg -i opensnitch_1.6.6-1_amd64.deb
sudo dpkg -i python3-opensnitch-ui_1.6.6-1_all.deb

# Install any missing dependencies
sudo apt-get install -f

Check the GitHub releases page (github.com/evilsocket/opensnitch/releases) for the latest version numbers before running these commands.

Enable and Start the Daemon

sudo systemctl enable opensnitchd
sudo systemctl start opensnitchd

Verify it’s running:

sudo systemctl status opensnitchd

Start the UI

The OpenSnitch UI is a Python/Qt application that runs as your normal user and communicates with the daemon over a Unix socket:

opensnitch-ui &

You’ll see an OpenSnitch icon in your system tray. On GNOME, you may need a system tray extension (like gnome-shell-extension-appindicator) to see it.

Fedora / RPM-based Systems

# Download the .rpm package from GitHub releases
sudo rpm -i opensnitch-1.6.6-1.x86_64.rpm
sudo rpm -i python3-opensnitch-ui-1.6.6-1.noarch.rpm
sudo systemctl enable --now opensnitchd

Arch Linux

paru -S opensnitch
sudo systemctl enable --now opensnitchd

Understanding the Prompt

When an application makes its first outbound connection, a dialog appears with these details:

Process name and path (e.g., /usr/bin/firefox)
User running the process
Destination IP and hostname
Destination port and protocol
Full command line that spawned the process

This context is critical. A connection from /usr/bin/curl run by your own user is very different from the same IP being reached by an unknown process running as root.

Rule duration options:

Once — allow/deny this specific connection right now; prompt again next time
Session — allow/deny until the daemon restarts
Always — write a permanent rule

Rule scope options:

This process — apply only to this specific executable
This command — apply to the full command line (useful for scripts)
From this user — apply to all traffic from this user account
From this PID — apply only to this process instance

Start with “once” or “session” while you learn what each application connects to. Promote rules to “always” when you’re confident in the pattern.

The Rules Interface

Open the OpenSnitch UI and click on the Rules tab. Here you can view, edit, enable, disable, and delete all rules. Rules are stored as JSON files in /etc/opensnitchd/rules/. You can also edit them directly:

{
  "created": "2026-04-19T10:00:00Z",
  "updated": "2026-04-19T10:00:00Z",
  "name": "allow-firefox-dns",
  "enabled": true,
  "action": "allow",
  "duration": "always",
  "operator": {
    "type": "simple",
    "operand": "process.path",
    "data": "/usr/bin/firefox",
    "sensitive": false
  }
}

More targeted rules combine multiple conditions using the list operator type with and/or logic. For example, allow Firefox to reach only port 443:

{
  "name": "firefox-https-only",
  "enabled": true,
  "action": "allow",
  "duration": "always",
  "operator": {
    "type": "list",
    "operand": "list",
    "list": [
      {"type": "simple", "operand": "process.path", "data": "/usr/bin/firefox"},
      {"type": "simple", "operand": "dest.port", "data": "443"}
    ]
  }
}

Practical Use: What to Block

Here are common outbound connections worth blocking or restricting:

Telemetry processes:

ubuntu-report and ubuntu-advantage-tools on Ubuntu connect to Canonical servers
GNOME’s Software app connects regularly for updates — allow only if you want automatic checks
Many Electron apps (Slack, VS Code, Discord) have telemetry endpoints — inspect the domains they contact and block analytics URLs

Update checkers running in the background: Applications like Spotify, Zoom, and Chrome have background processes that check for updates even when you’re not using them. You can deny these and update manually, or allow them on a schedule.

DNS exfiltration canaries: Watch for unexpected DNS queries to unusual domains. OpenSnitch’s log view shows DNS lookups alongside connection attempts. Unusual patterns can indicate malware or data exfiltration.

Block applications from network access entirely: For apps that have no business communicating online (local games, offline utilities), create a blanket deny rule by process path.

The Statistics and Connections Views

The Statistics tab in the OpenSnitch UI shows aggregate connection counts per application — a useful overview of which programs are most active on the network.

The Connections tab shows a live scrolling log of all connections, with allow/deny status, destination, port, and process. This is invaluable for auditing what your system is doing in the background.

You can export connection logs for offline analysis.

OpenSnitch and System Updates

Be careful when OpenSnitch is in deny by default mode: system package managers (apt, dnf, pacman) will be blocked from reaching update repositories. Create rules in advance:

# Example: allow apt processes to reach any destination
# Rule: process.path == /usr/bin/apt-get, action: allow

Alternatively, run OpenSnitch in allow by default mode initially, build up rules for what you want to block, then switch to deny-by-default once your rule set is mature.

Performance Impact

OpenSnitch’s daemon is written in Go and has a modest memory footprint (typically 30–80 MB). Each new connection that hits the UI adds a small delay while you respond to the prompt. For established rules, there is minimal overhead — connections are evaluated against rules in memory very quickly.

On a busy workstation with many applications, the initial rule-building phase can be disruptive. Dedicate an hour to working through the prompts, and normal operation becomes seamless.

OpenSnitch is an excellent complement to network-level tools like Pi-hole. Pi-hole blocks DNS requests; OpenSnitch blocks outbound connections at the process level, even for applications that use hardcoded IPs to bypass DNS filtering.