An application opening a connection to the Internet is a normal procedure and typically completely legitimate, but there are programs – even open source applications – that like to phone home or track the user. On Linux, there is usually an opt-in step – you have to actively agree to the data collection. Often, the collected data relates to telemetry functions and gives the developers information about a user's interaction with their program. However, open source does not always protect you against being investigated. In Firefox, you have to actively opt out of sending telemetry stats if you do not want this to happen.

An application firewall can reveal what's going on behind the user's back. While conventional firewalls examine the data flow packets to and from the CPU, an application firewall takes an application-specific view when monitoring the outgoing data flow. (Do not confuse an application firewall with a web application firewall [1].) Examples of application firewalls include FirePrompt [2] for Linux and GlassWire [3] for Windows. In this article, I'll take a closer look at an open source application firewall: OpenSnitch [4], a Python port of the proprietary Little Snitch [5] personal firewall for macOS. OpenSnitch development began about four years ago.

Snitch

With "snitch" in its name, you can tell much about how OpenSnitch works: Snitching is exactly what this firewall does. OpenSnitch analyzes applications' outgoing data traffic and exposes trackers and similar unpleasantries if configured accordingly, letting you intervene if necessary. In general, if an application tries to connect to the network, OpenSnitch stops it first and asks if you want to allow this to happen. You grant permission by defining a rule for the application.

OpenSnitch is not typically found in the package archives of the popular distributions. On Arch Linux, up-to-date packages can be found in the Arch User Repository. MX Linux offers OpenSnitch, but only the outdated version 1.3.6. The current stable OpenSnitch v1.5.1 can be downloaded as a binary package from the project's GitHub page. Besides DEB and RPM packages [6] for 32- and 64-bit systems, you will also find the source code on GitHub if you want to build OpenSnitch yourself. Additional packages are available for the armhf and arm64 architectures.

Installation

I tested OpenSnitch v1.5.0-rc1, which is likely to be the stable version when this issue reaches the newsstand. I installed the packages for the daemon and the GUI on Debian Siduction ("sid") and Debian 11 ("bullseye").

On Siduction, there was a problem with some Python dependencies, but I was able to fix this by typing

sudo apt --fix-broken install

In Debian 11, the install completed without any hitches. Debian and its derivatives enable the OpenSnitch service automatically after installing the software. With other distributions you may have to do this manually (see Listing 1).

# systemctl --now enable opensnitched

After the first launch, you'll find OpenSnitch in the system section of the control bar. Clicking on the OpenSnitch icon opens the application's main window. Right-clicking does the same thing after selecting Statistics but additionally lets you disable or close the firewall and gives you access to the help documentation.

Blockade

Initially, OpenSnitch blocks all connections to the outside world. If an application that does not have a rule tries to access the Internet, OpenSnitch pops up a dialog. Before you even get around to calling OpenSnitch from the system section, several successive pop-up windows will probably already be telling you that applications on your system are trying to contact hosts outside their own network (Figure 1).

Figure 1: A pop-up window notifies you that Firefox is requesting a connection to update its version. You can allow, deny, or restrict access via various parameters at the bottom of the dialog box.

If you grant permission for an application to contact the outside world in the pop-up window, this permission will be applied until the next restart by default. However, you can also make the new rule permanent or limit its validity to a specific period of time. Optionally, you can define whether the rule should apply to the running process only, to the targeted URL, or to the domain to be contacted.

OpenSnitch saves the rules you create in JSON format in the /etc/opensnitch/rules file, which you can also edit manually. If necessary, you can save as a CSV file the list of applications that try to contact external hosts, for example, and process the list further with external applications (Figure 2).

Figure 2: OpenSnitch rules can be created and edited – not only in the graphical interface, but also in the form of a rules file in JSON format.

If you do not configure any settings, the window closes after 15 seconds and OpenSnitch blocks the connection by default. I found the time frame a bit short, so you might want to extend the grace period in the Preferences dialog, which you can access via the middle icon at the top of the application window (Figure 3). Under the Pop-ups tab, you can change the default action from deny to allow, set a shorter period instead of the default duration until reboot, or extend the duration to always, depending on your needs. If you missed a window (e.g., because it closed faster than you could react), you can edit the settings in the main window (Figure 4).

Figure 3: To extend the default timeout for pop-up windows for new rules, you can increase the value in the Preferences dialog, as well as adjust other default settings as needed.

Figure 4: You can edit previously created rules via the main window by right-clicking and selecting the corresponding table entry.