https://github.com/evilsocket/opensnitch/wiki/Rules#best-pra...
85 karma · joined June 24, 2019
https://github.com/evilsocket/opensnitch/wiki/Rules#best-pra...
It'd be nice to test it with a sample of aur package/malware.
For example, when closing firefox on OpenSUSE Leap 15.6, "pingsender" is launched to collect telemetry:
It has been there for years. It is also on other distros.
That's probably why the malware sandboxes are not detecting the outbound connections and the encrypting activity.
practically all these attacks require downloading remote files to the server once they gain access, using curl, wget or bash.
Restricting arbitrary downloads from curl, wget or bash (or better, any binary) makes these attacks pretty much useless.
Also these cryptominers are usually dropped to /tmp, /var/tmp or /dev/shm. They need internet access to work, so again, restricting outbound connections per binary usually mitigates these issues.
https://www.aquasec.com/blog/kinsing-malware-exploits-novel-...
https://github.com/jabberplugins/pidgin-screenshare
The plugin uses a reverse-tunneling SocketIO-server (to bypass NAT) on https://jabberplugins.net (*hosted by me*) which is used for routing OTR-encrypted (if enabled) screenshare packets between you & your buddy.
It also includes the libotr lib, modified by the author.I'd love to read the analysis by Johnny Xmas, the report from 0xfffc0000 and even the binary so other people can test it with other tools and/or analyze it.
[0] https://www.reddit.com/r/linux/comments/1f1jv08/comment/lk1o...
If the EDR is capable of intercepting the forks, clone() execves, open(), etc, then you can follow the traces. If it's able to deny certain activity based on rules like modifying /etc/ld.so.preload or download files with curl/wget, it'd have made the attacker's life a bit more difficult.
If the attacker loaded a rootkit, then probably you'd have lost visibility of what the attacker did after that. Also not all the EDRs hook all the functions, or they have bugs, so many times you are not able to follow a trace (without pain/guessing).
This telemetry usually is sent to a remote server, so the attacker could not have deleted it.
[0] https://github.com/TrackerControl/tracker-control-android
in the case of a successful attack, some questions to ask could be:
- why did they manage to use wget?
- why {apache,nginx,postfix,exim,sendmail,...} is allowed to use wget, or curl, or nc or bash (or ...)?
- why is wget, curl, nc, telnet, .. installed on the server? can they be uninstalled? with (!!) if it's a container.
- why did they manage to execute files from /tmp, or /var/tmp, or /dev/shm? do these directories need write access for "others" or can they be mounted with "noexec"?
- ufw/iptables/nftables won't stop local binaries from opening outbound connections, how would you stop outbound connections by binary, path, etc?
- if they managed to wipe the logs, how could you have known all the commands they executed? could auditd+grafana (just an example) have helped here by sending logs to a remote server?
But does it have any sense? Usually you block inbound connections, allowing only certain services. If a rogue process starts listening on a local port, you could display a warning alert, and as inbound connections are already blocked you'd be safe (as long as you trust netfilter...) and you wouldn't need to ask the user to perform an action.
https://github.com/gustavo-iniguez-goya/opensnitch/issues/21
https://nullsweep.com/why-is-this-website-port-scanning-me/
https://user-images.githubusercontent.com/2742953/84960681-9...
Could you explain why? Any experience/benchmark to share?
By the way, [1] has a GUI, but you can install only the daemon on the servers.
Limiting to what IPs/domains/ports an application connects to might be useful. But blocking unknown binaries is where this apps really shine (reverse shells, miners...), not because they stop them, but because they'll tell you what app tried to establish a connection, where it is on the disk, etc.
GUI is not GTK, but Qt.
> If you're hoping to use the machine purely from the CLI (like, when sshing into your work machine) it won't work well.
There's no cli tool published yet. There's a PoC though that works well.
> some options don't exist (like, allowing access to a domain)
Since version 1.0.0b you can filter by domain. And in latest version by domain, ip, network, uid, port, command line, command path, cmd environment variables, protocol, or any combination of them. You can't filter by interface, but if aomeone needs it open a new issue.
> It is significantly less powerful than LittleSnitch
What options do you miss?
However, if you allow everything to 80/443, the extensions would still be able to connect to their servers. Maybe the browsers should add the ability to allow/deny connections per extension.
https://github.com/gustavo-iniguez-goya/opensnitch/issues/21
[1] works pretty well for me.
[0] https://github.com/nathants/tinysnitch [1] https://github.com/gustavo-iniguez-goya/opensnitch [2] https://github.com/Douane/Douane/
Absolutely. It's funny to see that whenever you dis/connect a USB device there're broadcast transmissions. Or connections to localhost:9229 by Chrome whenever you open the Dev Tools.
I don't rely on it for security, but for curiosity. Right now a Linux box is a Black Box from a user point of view, and this kind of software can help you understand more about your system.
Even if it can be bypassed, it surely make things a bit harder.
https://hackaday.io/project/28694-yet-another-raspberry-pica...
youtube channel: https://www.youtube.com/channel/UCkH0MTHo-LlxOL_W_3Qeq9Q