I’m blocking all outbound traffic on my Windows laptop, I wrote a small PS script which parses the event log for denied connections, list them and in the same place I can add a FW rule for it.
Not that intuitive, but gets the job done. Never thought it may be use for anyone :)
Thanks! I was planning to create an easier-to-use windows application alternative, but I haven’t touched desktop development a long time, so there’d be a lot of basic things to learn first.
There are ready made firewall softwares with this functionality already (most of them is not free, and since I could hack it together, I won’t spend money on them).
Isn’t filtering based on the name of the executable pretty naive?
In a real setup you’d probably add a wildcard allow for stuff like Firefox, curl, etc. A malicious program could then just use them to access the network, bypassing mighty-snitch.
A few years back I used to use simplewall, it had the same problem.
If you want to filter network requests by program, then one better approach could be to only allow network access from processes launched by some magic wrapper program, which’d ask for your permission every time.
For example - instead of running firefox you’d run wrapper firefox, which would ask for your permission, and then run Firefox with full network access. Similarly, if you were doing anything network-related on the terminal, you’d run wrapper sh to give yourself network access, without letting unrelated processes abuse it in the meantime.
absolutely, but it’s much better than nothing. i don’t wildcard anything, though i do wildcard subdomains a lot, especially for firefox.
full address wildcard exists because for a lot of people they might not use a snitch without it. we have to cater to convenience or or no one will use security enhancing software. they can understand the tradeoffs and improve their usage over time. or not. blocking ads and trackers is still good even for someone with very limited security needs.
firefox doesn’t typically have a cmdline, but curl does. so a rule for curl can be specific to: curl -v google.com. wildcard address with wildcard cmdline is probably not great.
the possible duration of a rule is 1-minute, 24-hour, and forever. more secure on the left, more convenient on the right. i’m experimenting with more liberal use of non-forever durations. permanent rules considered harmful.
a snitch isn’t going to make you perfectly secure. who can write to the rules file? who can modify binaries specified in rules? who owns a domain you’ve whitelisted?
a snitch should help you observe and consider unusual network activity. a snitch may help you prevent a malicious program from functioning. most programs should not be making network requests. most network requests should be to domains that make sense. most network requests should be at times that make sense. the rest get an eyebrow raise, some consideration, and a block.
future work is securing the filesystem and using the checksum of binaries as a part of the rule. finding a way to make firefox run with a distinct cmdline per url would also be good.
i explored including filesystem filtering in this snitch via lsm path hooks, but ended up dropping it for now. likely fuse is a better approach for this, but i’m undecided and don’t have a solution yet. i would like to know which binaries are reading my aws credentials file, and raise my eye brows accordingly.
a snitch isn’t going to make you perfectly secure. who can write to the rules file? who can modify binaries specified in rules? who owns a domain you’ve whitelisted?
I was mostly thinking about how a snitch could work in an otherwise secure system. Not that we really have any at the moment :(
i explored including filesystem filtering in this snitch via lsm path hooks, but ended up dropping it for now.
It would be wonderful if you eventually figured that out! Personally I think Linux is just too lax about security for something like that to be viable, but I’d love to be proven wrong!
I was mostly thinking about how a snitch could work in an otherwise secure system. Not that we really have any at the moment :(
lol, true. this is fine. kind of working snitch feels better than zero snitch. using my iphone feels like network roulette. yes, i do feel lucky.
on my github i have another project called tiny-snitch. it is otherwise identical except that it doesn’t know about exe/cmdline. the benefit of this is that it can run upstream, ie tiny-snitch runs on your wireguard server and your iphone/laptop/windows all tunnel through that. then it sends prompts to sms/signal/email/somewhere? upstream-snitch feels like a potentially good idea, but exe/cmdline capable local-snitch is so convenient.
It would be wonderful if you eventually figured that out! Personally I think Linux is just too lax about security for something like that to be viable, but I’d love to be proven wrong!
i haven’t published my attempt but it definitely kind of works via the lsm route. lsm has many path_* hooks. my take away was that it is very brittle and will take a long time to stabilize, if it even can. linux boots fine without network, not so much without filesystem.
moving secrets out of environment variables and into files guarded by a snitch feels like a good idea. my next attempt will be via fuse, which can access caller pid/tgid via fuse_get_context. i’m not sure snitch for the entire filesystem is a good idea, but for a single place it might be. there’s no place like ~/secure/*.
If you want to filter network requests by program, then one better approach could be to only allow network access from processes launched by some magic wrapper program, which’d ask for your permission every time. For example - instead of running firefox you’d run wrapper firefox (…)
That sounds a lot like firejail (and other implemtations of that idea of course).
while a good approach, it doesn’t help you when some malicious foss library drops an executable and crontab somewhere on your system. unless you firejail pid1, which does actually kind of work!
it should be! I think LuLu provides a similar experience on macOS, I find it quite helpful
true! i haven’t used that, but it’s awesome to see foss alternatives to little snitch.
I’m blocking all outbound traffic on my Windows laptop, I wrote a small PS script which parses the event log for denied connections, list them and in the same place I can add a FW rule for it. Not that intuitive, but gets the job done. Never thought it may be use for anyone :)
cool! is it interactive?
Somewhat :) Check the screenshots:
http://deejayy.hu/share/paste-20221118-002119.png
http://deejayy.hu/share/paste-20221118-002124.png
Scripts:
https://gist.github.com/deejayy/9fac4acc1aeefc9289efb7f71c9325df
this is cool!
Thanks! I was planning to create an easier-to-use windows application alternative, but I haven’t touched desktop development a long time, so there’d be a lot of basic things to learn first.
There are ready made firewall softwares with this functionality already (most of them is not free, and since I could hack it together, I won’t spend money on them).
Isn’t filtering based on the name of the executable pretty naive? In a real setup you’d probably add a wildcard allow for stuff like Firefox, curl, etc. A malicious program could then just use them to access the network, bypassing mighty-snitch. A few years back I used to use simplewall, it had the same problem.
If you want to filter network requests by program, then one better approach could be to only allow network access from processes launched by some magic wrapper program, which’d ask for your permission every time. For example - instead of running
firefoxyou’d runwrapper firefox, which would ask for your permission, and then run Firefox with full network access. Similarly, if you were doing anything network-related on the terminal, you’d runwrapper shto give yourself network access, without letting unrelated processes abuse it in the meantime.absolutely, but it’s much better than nothing. i don’t wildcard anything, though i do wildcard subdomains a lot, especially for firefox.
full address wildcard exists because for a lot of people they might not use a snitch without it. we have to cater to convenience or or no one will use security enhancing software. they can understand the tradeoffs and improve their usage over time. or not. blocking ads and trackers is still good even for someone with very limited security needs.
firefox doesn’t typically have a cmdline, but curl does. so a rule for curl can be specific to: curl -v google.com. wildcard address with wildcard cmdline is probably not great.
the possible duration of a rule is 1-minute, 24-hour, and forever. more secure on the left, more convenient on the right. i’m experimenting with more liberal use of non-forever durations. permanent rules considered harmful.
a snitch isn’t going to make you perfectly secure. who can write to the rules file? who can modify binaries specified in rules? who owns a domain you’ve whitelisted?
a snitch should help you observe and consider unusual network activity. a snitch may help you prevent a malicious program from functioning. most programs should not be making network requests. most network requests should be to domains that make sense. most network requests should be at times that make sense. the rest get an eyebrow raise, some consideration, and a block.
future work is securing the filesystem and using the checksum of binaries as a part of the rule. finding a way to make firefox run with a distinct cmdline per url would also be good.
i explored including filesystem filtering in this snitch via lsm path hooks, but ended up dropping it for now. likely fuse is a better approach for this, but i’m undecided and don’t have a solution yet. i would like to know which binaries are reading my aws credentials file, and raise my eye brows accordingly.
I was mostly thinking about how a snitch could work in an otherwise secure system. Not that we really have any at the moment :(
It would be wonderful if you eventually figured that out! Personally I think Linux is just too lax about security for something like that to be viable, but I’d love to be proven wrong!
lol, true. this is fine. kind of working snitch feels better than zero snitch. using my iphone feels like network roulette. yes, i do feel lucky.
on my github i have another project called tiny-snitch. it is otherwise identical except that it doesn’t know about exe/cmdline. the benefit of this is that it can run upstream, ie tiny-snitch runs on your wireguard server and your iphone/laptop/windows all tunnel through that. then it sends prompts to sms/signal/email/somewhere? upstream-snitch feels like a potentially good idea, but exe/cmdline capable local-snitch is so convenient.
i haven’t published my attempt but it definitely kind of works via the lsm route. lsm has many path_* hooks. my take away was that it is very brittle and will take a long time to stabilize, if it even can. linux boots fine without network, not so much without filesystem.
moving secrets out of environment variables and into files guarded by a snitch feels like a good idea. my next attempt will be via fuse, which can access caller pid/tgid via fuse_get_context. i’m not sure snitch for the entire filesystem is a good idea, but for a single place it might be. there’s no place like ~/secure/*.
That sounds a lot like firejail (and other implemtations of that idea of course).
while a good approach, it doesn’t help you when some malicious foss library drops an executable and crontab somewhere on your system. unless you firejail pid1, which does actually kind of work!