Can we make rules in opensnitch to deny/allow incoming stuff?

[Golddouble]

I have a simple personal desktop computer. No server or something complicated.

iptables can control outgoing stuff (OUTPUT-chain) and incoming stuff (INPUT-chain).

Question:
A) Can opensnitch only deny/allow traffic that goes from my desktop PC out to the internet/into another network?
B) Or can opensnitch also deny/allow traffic, that comes from the internet (INPUT) into the PC, to protect the PC? In short: Can opensnitch also create something similar to INPUT-chain rules?

Thank you.

[gustavo-iniguez-goya]

Right now is not possible to create rules for incoming connections.
Working on a desktop, I would drop any incoming connections (input policy DROP, -P DROP).

But anyway, it wouldn't much effort to add this functionality.

We only need:

• to add a NFQUEUE to intercept incoming connections: iptables -I INPUT -m conntrack --ctstate NEW -j NFQUEUE --queue-num 0 (the option --queue-bypass would work as -P DROP here)
• use nfq_get_outdev()/nfq_get_indev() in order to distinguish between IN and OUT.
• modify https://github.com/gustavo-iniguez-goya/opensnitch/blob/main/daemon/conman/connection.go#L89 so we query for the inode in the correct order (GetSocketInfo(c.DstIP, c.DstPort, ...) instead of GetSocketInfo(c.SrcIP, c.SrcPort, ...))
• and modify the text of the pop-ups.

And we would get pop-ups like this one (real pop-up):

The text of the pop-up could be: 192.168.1.105 is connecting to sshd on TCP port 22

[Golddouble]

Thank you very much for your answer.

I do not need the possibility to create INPUT rules and get INPUT pop-ups with opensnitch. It is quite enough for me to drop any incoming connections with iptables. Actually I only want to use opensnitch for privacy purposes to have control over the outgoing stuff.

Maybe it's better to improve the functionality of the OUTPUT rules in opensnitch instead of implementing in addition support for INPUT rules.

I only asked this question, because I was under the impression that opensnitch can only control the OUTPUT and wanted confirmation. Thank you.

Nevertheless:
It looks like the default after the installation of opensnitch is, that all INPUT is allowed:

$ sudo iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
NFQUEUE    udp  --  anywhere             anywhere             udp spt:domain NFQUEUE num 0 bypass

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
DROP       all  --  anywhere             anywhere             mark match 0x18ba5

Suggestion:
Shouldn't by default the INPUT Chain policy be "drop", immediately after the installation?

[gustavo-iniguez-goya]

I do not need the possibility to create INPUT rules and get INPUT pop-ups with opensnitch

oops, this has been requested many times evilsocket/issues/116 evilsocket/issues/283

Shouldn't by default the INPUT Chain policy be "drop", immediately after the installation?

I'm not sure. From a security point of view yes. But I think that all the others (GUI) firewalls use an ACCEPT policy by default, and let it the users to configure a more restrictive policy.

You can use /etc/opensnitchd/system-fw.json to insert system rules, but I didn't add the possibility to configure global policies.

[NRGLine4Sec]

It could be great to have this feature, currently we can do it with ufw/gufw, but It would be better to just have to use OpenSnitch.

[gustavo-iniguez-goya]

ok, I've got this working.

Before commit it. I'll review how it plays with the nftables rules, in order to reuse it when we migrate it. It would be great if we could only use the same configuration.

On the other hand, these are the features currently supported:

• Configure default chains policies (-P)
• Support for specify tables (-t), chains (-I/-A), parameters (-p tcp -m conntrack --ctstate NEW), targets (-j DNAT) and targets parameters (--to-destination 192.168.x.x)
• Order/Priority of the rules is determined by the position of the rule in the configuration file.
• Rules are added to custom chains, in order to organize them.
• Rules are deleted if the daemon exits cleanly. Otherwise they'll remain on the kernel.
• Field Description to allow describe a rule (Allow GRE traffic, redirect IP to etc..)

Anything else?

[NRGLine4Sec]

It's not a priority, but it could be great to have the ufw's capability to simplify the configuration of incoming stuff (in command line). Personnaly, I configure incoming connections with ufw in a postinstall script with very few command lines :

ufw --force reset && \
ufw default deny incoming && \
ufw default allow outgoing && \
ufw allow $SSHPORT/tcp && \
ufw logging high && \
ufw --force enable

where SSHPORT is a non default port for SSH.
And I think it could be a more important feature when it will be necessary to migrate from iptables to nftables, because users will not need to adapt to changes in firewall configurations made from the command line. This is a very convenient feature when you just have to do simple configurations, like allow only one specific port.
I think this is a more important feature for incoming connections than for outgoing connections, because in general there are very few ports to allow for incoming connections.
What do you think about it ?

[gustavo-iniguez-goya]

So, basically a command line tool to handle configurations.

I understand that it'd be useful in order to automate tasks from scripts, like the the one you described. It wouldn't be much effort, all the code is already written. We should only have to handle .json files, without connecting to the daemon, because the daemon already monitor configurations for changes.

[gustavo-iniguez-goya]

@NRGLine4Sec @Golddouble could you make me a favor? Can you post the output of the following command?
iptables -L OUTPUT | grep 0x18ba5

We suspect that that rule is useless, and should be removed. In all the systems where I've looked it has no hits:
0 0 DROP all -- any any anywhere anywhere mark match 0x18ba5
^ ^

[NRGLine4Sec]

@gustavo-iniguez-goya Yes I confirm, there is no hits.

[Danny3]

Any updates on this ?
It would be nice to be able to deny all incoming connections, but allow just a few like SSH / VNC / KDE connect / Kodi (for Kore, its remote control).

[gustavo-iniguez-goya]

not yet. The code is written but I wanted to add support for nftables first, because that could change the current system-fw.json format and I didn't want to introduce new changes that I'd have to remove later.
I need to give it a thought though, because maybe I can keep the current format for both iptables and nftables.

[Danny3]

No problem !

Thank you very much for the update !

[gustavo-iniguez-goya]

Ok, I thought that the nftables go lib was not ready for use, but I've just written a simple PoC and it works just fine.
So first I want to release v1.4.0rc2, and probably v1.4.0 soon after that, and later I'll start working on this issue and adding nftables support.

[gustavo-iniguez-goya]

sure, here you have: nftables.go.txt

The PoC is only to add nftables rules using the nftables lib. Last night I integrated it with opensnitch (basic interception, no support for "system rules"), but it still needs a lot of work. I hope to work on this in the comming weeks, in parallel with the release of v1.4.0.

[gustavo-iniguez-goya]

nftables support added to the main repo: evilsocket@da23c82

Now it's turn for this request, allow to configure chains policies. Already done for iptables, but nftables is a little bit trickier.
system-fw.json structure will change, so you'll have to update the rules.

[gustavo-iniguez-goya]

If you use nftables, the default policy can be configured by using the file /etc/nftables.conf:
https://github.com/evilsocket/opensnitch/wiki/System-rules

[gustavo-iniguez-goya]

branch published to allow configure system firewall (nftables) from the GUI: https://github.com/evilsocket/opensnitch/tree/firewall-policies

Please, if you can compile it from sources, do it and report any problem. It needs to be tested.

For more information and ideas: evilsocket#592 (comment)

[gustavo-iniguez-goya]

Finally v1.6.0rc1 is out, with this feature added https://github.com/evilsocket/opensnitch/releases/tag/v1.6.0-rc.1

[Danny3]

Wonderful, can barely wait to test it...
Thank you very much!