[Feature Request] Option to ignore (allow) loopback traffic

[WinterSnowfall]

Summary:

Problem:

A lot of applications will depend on loopback traffic being unhindered and other firewalls, such as ufw for example, will not filter loopback traffic at all by default.

Background:

I've recently started using opensnitch and have noticed various applications would either time out after long intervals or hang completely if loopback traffic was blocked. This also happened with mate-session (I use MATE as my desktop environment).

I came across this wiki page: https://github.com/evilsocket/opensnitch/wiki/Known-problems#general , which was helpful. However, the provided fix is only partial. Besides IPv4 loopback, some applications (as is the case of mate-session, apparently) will depend on IPv6 loopback being unfiltered (ergo ::1/128) in order to behave properly.

Suggestion:

While I have a background in networking and was able to figure it out, the default behavior can arguably be quite confusing to regular users. Loopback traffic is not usually considered a security risk, nor should it be hindered unless otherwise specified (if a user insists).

I suggest having a global config option for enabling loopback traffic filtering and to leave it disabled/off by default, since most users will have no interest to act on loopback traffic.

Switching the default action to allow traffic when the UI is not connected (as suggested in the Wiki article linked above) is not a good solution IMHO, since security-conscious users would want to whitelist traffic themselves and make sure nothing gets through otherwise.

[gustavo-iniguez-goya]

Hi @WinterSnowfall ,

You're right , this is a problem on some Desktop Environments. The easiest would be to add a predefined system fw rule as we already have for ICMP, and then let the users decide if disable it or not.

Another option I've considered is to add an application rule for common apps that work on localhost (/usr/bin/xbrlapi, /usr/bin/dirmngr) and keep updating it based on users' feedback, but I don't know if there's any way to use these apps to exfiltrate data in some way...

[WinterSnowfall]

I think maintaining such a list would be nothing short of a nightmare (you really can't account for everything people will use). The first option sounds better and is more or less what I was suggesting, I guess.

[drws]

Another option is that user is asked during the installation whether to allow loopback connections. If this is considered a similar dialog could also ask the user whether to enable OpenSnitch service right away or not.

Greetings!

@WinterSnowfall

I've made an attempt to implement this feature with #1304. Loopback connections aren't monitored after detection, hopefully this reduces resource demand. It seems to work as expected with Arch Linux. I'll try to test it with my Ubuntu VM at some point soon (unless someone else can confirm first).

@drws Rather than an installation prompt, the default is to permit and ignore all traffic traversing loopback. The settings look like:

P.s. @gustavo-iniguez-goya, 1.7.0 looks fantastic and runs very well for me so far. Thank you for all your hard work!

I've attempted to optimize the performance and iperf testing hows good performance on my hardware. Ubuntu 22.04 tests are successful as well. However, trace logging seems to shows significant overhead.

@gustavo-iniguez-goya do you think that this approach is viable given the overhead?

[gustavo-iniguez-goya]

hey @lainedfles , thank you for looking into this. The PR looks good to me, I've just tested it and works as expected.

The only thing is, if we want to ignore these connections without even logging them, wouldn't it be better to bypass this traffic entirely?
Right now, if the loopback connections are ignored, we check every connection to see if they're to/from loopback, unconditionally.

On the other hand, adding code to the daemon creates an exception for this particular network traffic. People may ask to also exclude Multicast traffic, Broadcast traffic, etc. And any change will require adding new code and recompiling the daemon.

I'm more in favor of distributing a regular or firewall (in system-cfg.json) rule:

{
   "created": "2025-04-08T19:32:58.000000Z",
   "name": "000-allow-localhost",
   "enabled": true,
   "precedence": true,
   "nolog": true,
   "action": "allow",
   "duration": "always",
   "operator": {
       "type": "network",
       "operand": "dest.network",
       "data": "127.0.0.0/8"
   }
}

system-fw.json under mangle-output:

            {
              "Table": "",
              "Chain": "",
              "UUID": "3cf89c5e-1483-11f0-b57b-0800273a95ec",
              "Enabled": true,
              "Position": "0",
              "Description": "allow localhost connections",
              "Parameters": "",
              "Expressions": [
                {
                  "Statement": {
                    "Op": "==",
                    "Name": "ip",
                    "Values": [
                      {
                        "Key": "daddr",
                        "Value": "127.0.0.0-127.255.255.255"
                      }
                    ]
                  }
                }
              ],
              "Target": "accept",
              "TargetParameters": ""
            },

@gustavo-iniguez-goya

The only thing is, if we want to ignore these connections without even logging them, wouldn't it be better to bypass this traffic entirely? Right now, if the loopback connections are ignored, we check every connection to see if they're to/from loopback, unconditionally.

My intention was to bypass at the lowest level possible. Even with nolog (which I had overlooked but is a very nice feature 868974f), a Connection object is still created and a DNS check performed (some of which is logged). Unless I'm misreading the code?

A significant amount of the software I need relies heavily upon loopback traffic (it would be nice if they could use unix sockets instead 🤷🏻). Often it can be justified to restrict web-only services to loopback for privacy and security and in the past OpenSnitch has caused related problems. Although maybe nolog is an acceptable compromise.

On the other hand, adding code to the daemon creates an exception for this particular network traffic. People may ask to also exclude Multicast traffic, Broadcast traffic, etc. And any change will require adding new code and recompiling the daemon.

I'd argue that security incentive to inspect loopback traffic is niche and minimal. But Multicast and Broadcast are both intended to traverse at least private networks and exclude loopback interfaces. It makes sense to always inspect these.

I'm more in favor of distributing an regular or firewall (in system-cfg.json) rule:

Thank you for the feedback, and example rules.

[WinterSnowfall]

@gustavo-iniguez-goya Thanks for the fix. I'd suggest you also consider including IPv6 loopback, because that's needed sometimes, as I've mentioned before:

Besides IPv4 loopback, some applications (as is the case of mate-session, apparently) will depend on IPv6 loopback being unfiltered (ergo ::1/128) in order to behave properly.

[gustavo-iniguez-goya]

Sorry for not adding this before! IPv6 loopback is added: https://github.com/evilsocket/opensnitch/blob/master/daemon/data/rules/000-allow-localhost6.json