The first time I installed and ran Little Snitch, I was pretty much flabergassted at how chatty my system was. Just constantly being presented with requests to the point that made it impossible to work. I loved learning how prevelant E.T. phoned home.
But then as I was just constantly inundated with those requests, I hated having to constantly deal with it. Now it's time to whitelist/authorize/etc. But do I really want to blanket OK something just because I'm annoyed? What does one do to stay sane and safe?
<disables Little Snitch> securely places head back in sand
Little Snitch is the single program to illustrate all of the scary websites/blogs/etc of how shitty companies are about their "free" software and other shenanigans that devs play and from some "legit" companies.
I love Little Snitch and I hate Little Snitch, and it's not their fault.
I think what's missing with programs like little snitch are the default filter lists similar to ublock zero filters. If there was a pre curated list, it would have been a lot more adopted.
Until Linux duplicates that BSD tagging of inbound packets to process ID, no Linux-derivative LittleSnitch is going to match macOS/BSD-variant LittleSnitch’s capability set of detecting WHICH application having received a network packet.
Given the above, sandboxing with namespace nftable is still required for ultimate inbound security (I am looking at you, systemd).
This is very easy to accomplish with eBPF, which OpenSnitch appears to use, but I didn't review it sufficiently to determine if that's how they're associating processes with packets.
IIRC the problem with tagging in Linux is that there isn't necessarily a 1:1 relationship with a destination PID and a packet in a variety of scenarios.
What exactly is the use case of such an application firewall?
I mean I get what it is supposed to do, but if I already have a means of blocking certain spam/telemetry URLs that I don't want (via etc/hosts, or PiHole), is there any real benefit of using an application firewall on top?
As others have said, micro-managing all these connections is not really feasible in most cases. And if I have a domain I don't trust, I can just globally block that.
What are some real-world use-case scenarios of a domain that I want to block for one application, but not generally for all applications? It sounds cool in theory to be able to fine-tune all that on an application basis, but is this actually useful/sensible in practice?
if you haven’t heard of libnetfilterqueue, this is what it’s for. it’s really good. tremendous thanks to the author for introducing me to it via this project.
the main problem with libnetfilterqueue is that it doesn’t have pid information. you have to look that up in /proc or via a hashmap maintained by ebpf. either method has issues.
an unexplored alternative, afaik, is seccomp with userspace filtering[1]. then you get pid information and direct control of syscalls. this may still need to be paired with libnetfilterqueue depending on implementation.
How does it compare to Bubblewrap? I tried it to test Windows software that I don't trust under WINE and it worked, but a few times the sandboxed program wouldn't work although it would when run under a non networked machine, so I thought the sandboxing was also affecting Unix sockets, that is, IPC.
Bubblewrap is cool, but not exactly a like comparison. Bwrap is a tool with a lot of different sandboxing tools, some of which work and some of which don't. OpenSnitch simply looks like an abstraction over your OS's firewall.
I think the whole point of LittleSnitch/OpenSnitch is the GUI. I feel like this is sort of a descendant of (or rather inspired by) a piece of software from long ago called "ZoneAlarm" for Windows. I mention this because I primarily used it before I could code or knew about the "system"; which, also happened to be when I was pirating a lot of software (high school). You should be able to accomplish most all of this, and more, from the command line already. `netstat` alone would probably get you most of the way there.
Take a look into rustdesk the server ie self hosting bit has been recently open sourced. It's basically Teamviewer but faster and rock solid so far. Some features are missing but the basics are there. I'm going to be dumping our TV account quite soon.
The missing piece was remote installing the client on Windows en mass to be able to be able to switch to root errr Administrator. TV allows you to pass Windows creds through to remote install itself but rustdesk can't yet or that might become an "enterprise feature". However Ansible can manage a WinRM enabled Windows box with Kerb and encryption over http and no client install. You can switch on WinRM via a GPO.
Getting some bits of Ansible working on Arch and certain other bleeding edge distros might involve pip install --update pycrypto (and/or) pykerberos. Python 3.10 deprecated something in a rather cryptic way, that I'm sure was jolly important but broke quite a lot of things important to a Linux sporting sysadmin in a Windows world.
So Wireshark but with connection permission toggles... Why does anyone need this on Linux? You can already block domains you know are malicious in the hosts file or use a personalized DNS resolver for that. Or am I missing something?
- You can apply more flexible rules than just blocking specific hostnames -- for example, based on IP subnets, port numbers, or specific binary executables
- You can block connections even from programs that bypass the default system-wide DNS configuration
I've been a pfSense fan for something like 15 years. I run something like 50-60 of them around the country (UK). In my office is a 2 node CARP beastie with six WANs and 12 NICs each (Dell R310s) and quite a lot of cabling. At home I have an APU4 humming away in the attic. I have a full IPv4 and 6 stack running and more VPNs than you can shake a stick at. The docs: https://docs.netgate.com/pfsense/en/latest/index.html are excellent.
Slap on the pfblocker-ng package and you effectively have a souped up Pi-Hole in the router too. My TV at home has stopped showing adverts for certain streaming channels which is nice.
There are certain strong feelings against Netgate (nee Electric Sheep Fencing) which may or may not be justified. You have Opnsense as an alternative option - it's a very well thought of fork of pfSense.
I've kinda been keeping an eye on firewalla [0] since it looks pretty simple and probably good enough for home use? If anyone has any experience with it, or has looked into how good/useful the security of it is I'd love to hear it.
There's also pfsense [1] and OPNsense [2] which are more geared towards business users, and personally not worth the effort for me to maintain at home, so I haven't looked into them as much.
Unfortunately without sandboxing, these sorts of tools just add an extra layer of maintenance to your system for a false sense of security [1, 2].
This can actually be harmful for less experienced Linux users who may trust something like this to keep them safe for running random scripts, especially since I see this tool often recommended for such a use case.
the issue is that libnetfilterqueue doesn’t have pid information, and so that must be looked up or joined to another data stream at runtime. this can fail. flakes at this point can be dangerous, and can reduce confidence in the system. they can also encourage you to add rules at both system and program level, which is annoying.
one alternative is to specify rules at system level instead of program level. that’s the approach i ended up landing on[1]. i wish i had finer granularity, but i’m glad i don’t have flakes.
it’s hard to imagine that monitoring network exfil isn’t THE best way to secure any system. at the least, it’s an important and necessary step.
Firewalls have not much to do with running untrusted executables... You are confused about what a firewall is for (it's for managing network connections, not prevent virus, etc)...
It's not just to avoid scripts. Sometimes I just what to control what a program can do. Eg not call home but connect to ftp servers I want to use it with.
[+] [-] dylan604|3 years ago|reply
The first time I installed and ran Little Snitch, I was pretty much flabergassted at how chatty my system was. Just constantly being presented with requests to the point that made it impossible to work. I loved learning how prevelant E.T. phoned home.
But then as I was just constantly inundated with those requests, I hated having to constantly deal with it. Now it's time to whitelist/authorize/etc. But do I really want to blanket OK something just because I'm annoyed? What does one do to stay sane and safe?
<disables Little Snitch> securely places head back in sand
Little Snitch is the single program to illustrate all of the scary websites/blogs/etc of how shitty companies are about their "free" software and other shenanigans that devs play and from some "legit" companies.
I love Little Snitch and I hate Little Snitch, and it's not their fault.
[+] [-] allisdust|3 years ago|reply
[+] [-] terlisimo|3 years ago|reply
btw, similar program for Windows: https://binisoft.org/wfc
[+] [-] egberts1|3 years ago|reply
Given the above, sandboxing with namespace nftable is still required for ultimate inbound security (I am looking at you, systemd).
[+] [-] xyzzy_plugh|3 years ago|reply
IIRC the problem with tagging in Linux is that there isn't necessarily a 1:1 relationship with a destination PID and a packet in a variety of scenarios.
[+] [-] rasz|3 years ago|reply
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] frankharv|3 years ago|reply
[+] [-] jwilk|3 years ago|reply
2017: https://news.ycombinator.com/item?id=14245270 (103 comments)
2020: https://news.ycombinator.com/item?id=22206116 (131 comments)
[+] [-] dark-star|3 years ago|reply
I mean I get what it is supposed to do, but if I already have a means of blocking certain spam/telemetry URLs that I don't want (via etc/hosts, or PiHole), is there any real benefit of using an application firewall on top?
As others have said, micro-managing all these connections is not really feasible in most cases. And if I have a domain I don't trust, I can just globally block that.
What are some real-world use-case scenarios of a domain that I want to block for one application, but not generally for all applications? It sounds cool in theory to be able to fine-tune all that on an application basis, but is this actually useful/sensible in practice?
[+] [-] terlisimo|3 years ago|reply
[+] [-] nathants|3 years ago|reply
if you haven’t heard of libnetfilterqueue, this is what it’s for. it’s really good. tremendous thanks to the author for introducing me to it via this project.
the main problem with libnetfilterqueue is that it doesn’t have pid information. you have to look that up in /proc or via a hashmap maintained by ebpf. either method has issues.
an unexplored alternative, afaik, is seccomp with userspace filtering[1]. then you get pid information and direct control of syscalls. this may still need to be paired with libnetfilterqueue depending on implementation.
1. https://lwn.net/Articles/756233/
[+] [-] throwawaynfw|3 years ago|reply
Something like this:
Or like this: Then you can do cool stuff like:[+] [-] dfghslweixb|3 years ago|reply
if you can set up a socks server, tsocks?
or you will have to create iptable rules and then use cgroups et al to tag the proccess to them.
[+] [-] squarefoot|3 years ago|reply
Command used was: "bwrap --bind / / --dev /dev --unshare-net -- exe_name"
[+] [-] smoldesu|3 years ago|reply
[+] [-] metadat|3 years ago|reply
I don't really like GUIs in my Linux, setting up VNC is such a pain.
[+] [-] rubyn00bie|3 years ago|reply
[+] [-] gerdesj|3 years ago|reply
The missing piece was remote installing the client on Windows en mass to be able to be able to switch to root errr Administrator. TV allows you to pass Windows creds through to remote install itself but rustdesk can't yet or that might become an "enterprise feature". However Ansible can manage a WinRM enabled Windows box with Kerb and encryption over http and no client install. You can switch on WinRM via a GPO.
Getting some bits of Ansible working on Arch and certain other bleeding edge distros might involve pip install --update pycrypto (and/or) pykerberos. Python 3.10 deprecated something in a rather cryptic way, that I'm sure was jolly important but broke quite a lot of things important to a Linux sporting sysadmin in a Windows world.
[+] [-] nathants|3 years ago|reply
i agree with you. especially if i’m filtering all traffic, i need to be able to y/n quickly and easily.
https://github.com/nathants/tinysnitch#demo
[+] [-] lapser|3 years ago|reply
https://github.com/harporoeder/ebpfsnitch
[+] [-] emrtuerthjnu|3 years ago|reply
https://github.com/evilsocket/opensnitch/tree/master/ebpf_pr...
[+] [-] beermonster|3 years ago|reply
[+] [-] hjkl0|3 years ago|reply
[+] [-] throwawei369|3 years ago|reply
[+] [-] teraflop|3 years ago|reply
- You can apply more flexible rules than just blocking specific hostnames -- for example, based on IP subnets, port numbers, or specific binary executables
- You can block connections even from programs that bypass the default system-wide DNS configuration
[+] [-] a-dub|3 years ago|reply
[+] [-] gerdesj|3 years ago|reply
Slap on the pfblocker-ng package and you effectively have a souped up Pi-Hole in the router too. My TV at home has stopped showing adverts for certain streaming channels which is nice.
There are certain strong feelings against Netgate (nee Electric Sheep Fencing) which may or may not be justified. You have Opnsense as an alternative option - it's a very well thought of fork of pfSense.
[+] [-] elesiuta|3 years ago|reply
There's also pfsense [1] and OPNsense [2] which are more geared towards business users, and personally not worth the effort for me to maintain at home, so I haven't looked into them as much.
[0] https://firewalla.com/
[1] https://www.pfsense.org/products/
[2] https://shop.opnsense.com/product-categorie/hardware-applian...
[+] [-] nathants|3 years ago|reply
2. install opensnitch or similar on 1.
3. route all traffic through 1.
4. figure out how to deal with rule management and new connection requests from 1 to wherever is most convenient for you.
[+] [-] macinjosh|3 years ago|reply
[+] [-] Elyra|3 years ago|reply
This can actually be harmful for less experienced Linux users who may trust something like this to keep them safe for running random scripts, especially since I see this tool often recommended for such a use case.
[1] https://news.ycombinator.com/item?id=22208223
[2] https://news.ycombinator.com/item?id=14254679
[+] [-] nathants|3 years ago|reply
one alternative is to specify rules at system level instead of program level. that’s the approach i ended up landing on[1]. i wish i had finer granularity, but i’m glad i don’t have flakes.
it’s hard to imagine that monitoring network exfil isn’t THE best way to secure any system. at the least, it’s an important and necessary step.
1. https://github.com/nathants/tinysnitch
[+] [-] Pakdef|3 years ago|reply
[+] [-] GekkePrutser|3 years ago|reply