Network Tattletale

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.

Firewall On or Off

In the main window's header bar, on the far right, you will find the play/pause button where you can turn the firewall on and off. This button is especially important initially because you need some time to define rules for all the applications that need to contact the outside world. You can use this button to break up the task into convenient chunks of time.

In the menubar below, you will find eight tabs. The Events tab lists all contacts to the outside world in real time (Figure 5). Nodes typically only lists one socket per device, from which the OpenSnitch GUI obtains the data for visualization. The default for this is /tmp/osui.sock.

Figure 5: The Events tab lists all outside connections in real time. You can see connection attempts from Firefox to different IP addresses here.

The Rules tab, as expected, lists the application rules that have been created (Figure 6). The Hosts tab lists the remote sites that applications have attempted to contact and how often that occurred per host. The Applications tab lists the applications that tried to make contact and shows the frequency of those attempts.

Figure 6: Because Firefox (as shown in Figure 5) wants to access many IPs, click on the List of domains/IPs tab in the Rule dialog to specify exactly what the program is allowed to do.

The Addresses tab keeps track of the URLs contacted and the frequency of contact attempts. Ports does the same in terms of the ports on the contacted hosts, while the Users tab lists the users involved and records the number of contact attempts initiated by the users. From any of these tabs, you can edit entries that are released for editing by right-clicking on them.

To avoid losing your way when faced with many entries, you can also sort or filter the entries on the individual tabs. At the bottom of the window, you can see the number of connections during the current uptime and how many of them were rejected (dropped).

FAQs

OpenSnitch can manage virtually anything that connects to a host from a Linux system. For multi-user systems, the rules can also be defined individually for each user. According to the developers, however, OpenSnitch occasionally misses an app's connection attempt; the project wiki [7] on GitHub explains the possible reasons for this. However, I did not experience any such oversights in my test. An FAQ [8] answers frequently asked questions relating to the application firewall.

Once you have created all your rules, OpenSnitch runs unobtrusively in the background. A notification will only appear if you install a new app that makes an attempt to contact the outside world. If an app makes a conspicuous number of connections, you will want to harden the rule for that app by checking each process for an outgoing request or the domain contacted in each case, and then confirm or deny access.

Conclusions

While OpenSnitch is annoying at first, this means it is doing its job properly. You can temporarily avoid the many requests for rules by disabling the firewall and then defining more rules when it suits you. Getting started with OpenSnitch is comparatively easy thanks to the good documentation [9].

OpenSnitch is particularly interesting for browser plugins, web apps, or third-party applications in general. It helps you keep a closer eye on these applications and make adjustments to rules as necessary. You will be surprised about what some apps try to do. In conclusion, OpenSnitch definitely improves the security of your system without asking too much of you beyond the initial setup.