Completely agreed. Not sure what the historical reasons for lsof and ss are, but unix tools are structurally in a hard place when it comes to having sensible defaults over the long term.
Generally speaking, you can only have sensible defaults over time if you're able to change the defaults over time. New users and new use-cases come with time, and so what constitutes a "sensible default" changes.
However (and this is a drum I like to bang[0]), because unix tools only deal in usually-text bytestreams without any higher level of abstraction, consumers of those tools end up tightly coupled with how output is presented. Without any separation between data and its representation, the (default) representation is the tool's API. To change the default representation is to make a backwards-incompatible API change. A good example of this is how ps aux truncates longer than like 7 characters.
This changes the default to display all sockets, hide the queues and show the processes using each socket
It also adds adds a -q option to display the queues
1. IMHO this is also an argument against "cloud computing", i.e., using someone else's computers where pre-installed kernels and binary packages are the norm
i am not sure if this would need a different name, you may just have this association because you are using little snitch, but they have completely different use-cases. for now this will just be a way to display ss/netstat data in the terminal in a nice way
I immediately thought of that too. The names these people come up with are so embarrassing. And I'm not even talking about the meaning of 'snitch'. But you already have a tool within the same IT area that is basically named the same. Why the hell would you do that? Aren't there other words in the dictionary?
thanks! snitch is closer to an ss/netstat replacement (sockets + processes) than a traffic monitor. traffic monitoring is planned, but not implemented yet.
I've gotten used to ss now, and I quite like it, I just wish there was an option to not show the send/recv numbers. I never use them and the width is already so wide that the output barely fits into most terminals when you have them split vertically on a laptop screen.
That said though, I'm not going to install snitch. The thing about ss is that it's already there, on every server I manage. And I definitely do not need a TUI for this.
Snitch is something you might install in your homelab, or your workstations. But ss is still the default when you provision a lot of servers.
fair point. ss stays the default on servers because it is already installed.
snitch is for workstation/homelab debugging when i want quicker filtering and selection. also, i do not show send/recv yet, but if i add it later it will be optional (compact mode / toggle) so it fits in split panes.
go: github.com/karol-broda/snitch@latest: version constraints conflict:
github.com/karol-broda/snitch@v0.1.8: parsing go.mod:
module declares its path as: snitch
but was required as: github.com/karol-broda/snitch
They declared their module with just their package name without a URL, it got fixed a few hours ago.
I find it a bit interesting that Go even allows you to declare `module barename` in go.mod even though it loves breaking so many things if you do so. I sometimes try doing it for completely private projects but I always just declare some URL in the end, it's a weird anti-pattern in my opinion.
I always wondered how useful such tools are against a competent adversary. If you are a competent engineer designing malware, wouldn't you introduce a dormancy period into your malware executable and if possible only talk to C&C while the user is doing something that talks to other endpoints? Maybe even choose the communication protocol based on what the user is doing to blend in even better.
At the very least, these tools should not parse /proc to obtain information of processes or connections. It should be the last option.
Many LD_PRELOAD rootkits hide their activity from the system by manipulating the output of libc functions like readdir(), open(), stat(), etc.
kernel rootkits can hide whatever they need, but the common functionality is also to hide data from /proc.
That's why netstat, ps, *top or lsof are not reliable tools if the system is compromised. ss is a bit different and is a bit more reliable.
In this case, snitch is written in Go, which doesn't use the libc functions, so probably it'll be able to obtain information from /proc even if hidden by a LD_PRELOAD rootkit.
Another option would be to compile the binary statically.
Anyways, these tools are not meant to unhide malicious traffic or processes, so I think detecting beacons, inspecting traffic, etc, is out of the scope.
agreed on the limits. snitch isnt aimed at adversarial detection; its a local debugging/inspection tool. a competent attacker can blend in by design, so this isnt meant to be a standalone security control
Tools like these aren't really intended for adversarial environments, and pure network tools that are designed for real adversaries have a really spotty track record (good search: [bro vantage point problem]).
One aspect of sysadminship that I find cute (but suboptimal) is how we memorize this strings of commands that were clearly not quite designed to be used in that manner.
A slightly related example is how our intents in our mind end up having commands that don't resemble at all what we actually want, creating a map between intent and command that is almost exclusively arbitrary except for some obsucre etymological origin that might or might not help you remember the command in a time of need.
For example:
Intent: "create a file"
Command: "touch $FILE"
As it happens, touching a file doesn't mean to create, it was supposed to touch to modify the last access date, like a null op. But now if you want to create a file you do that.
Intent: "Print a file contents to screen"
Command: "cat $FILE"
Is this a reference to a feline? some slang for printing or reading? No it's short for concatenate, but if you pass just one argument instead of 2, it prints the concatenation of 1 file and nothing.
Even something as simple as
Intent: "Rename a file"
Command: "mv $FILE"
Of ocurse there's the fact that moving a file and renaming the file are very similar if not identical in most FS/OS, but also, the slight change from a word to a proper-name style command already creates a style of command line interaction that was very natural in the 80s, but is now being reinvented with the advent of more powerful language decoding technology. So even:
Intent: "Copy a file"
Command: "cp $FILE"
Now to the topic, you can see how my relationship with ss is the mapping:
Intent: "See a list of open ports"
Command: "ss -tulnp"
Which I remember mnmemotecnically because it is close to -tulip. This is similar to ps -aux in that the command includes a set of options and I remember it mnemotecnically ("auxiliary" or "auxilio"), and I use the options even when I don't need them, modifying the options from that baseline if needed, like removing "a" to get just the current user's processes.
That said. I don't know if the future is going to be "better" alternatives to old tools, but rather deconstructing or making use of the concept of "binary":"command", running man and --help has never been an optimal solution, and let's be honest, kids nowadays are googling, stackoverflowing and chatgpting their intent in order to get a magical command.
No easy way to improve upon this at the userspace level, the OS model of delegating control to binaries based on a hierarchical command structure is sensible, and "magic", or sharing commands across binaries without a clear ruleset would be too opaque. But I feel that creating new tools while barely revolutionizing the way they work is too small an incremental change, it adds more noise, I'm not sure that ss2 or network-manager instead of wpa_supplicant is a better outcome, now you are just linearly increasing the cognitive demand of new sysadmins linearly with time.
I've just connected this to some other thought on Android app marketplaces.
Even in operating systems as distant as Android, we still have the phenomenon of using proper_names instead of natural names.
If you want a taxi or a cab, you don't ask your OS to get you a taxi or cab, you ask it to use the Uber binary.
In the 2000s it wasn't clear that this was going to be the case, the famous example of the pets.com domain was a wrong bet that natural names would somehow be important.
Instead natural names are only important when used through an obscure privately controlled algorithm like Google or StackoverFlow or ChatGPT, if you want to say "flights to Greece" instead of "Oobloo greece", you need a magical black box in the middle.
I wish there was a tool that also displayed current and accumulated transfer rate per socket/process. I use jnettop for this purpose, but I'm unhappy with its user interface.
Thanks for this! I can never remember the netstat arguments, and it's a bit crazy that it doesn't come with sane defaults, so this is going to be really useful.
dont think this is in homebrew/core, brew install snitch may be a different package, could you paste brew info snitch output? if its not this project, i will add a note to the readme to avoid confusion. but i will be creating a homebrew cask soon
Before systemd presented a generalised interface, there were significant differences in the init and service management systems between the popular Red Hat and Debian families of distros.
PunchyHamster|2 months ago
Like, ss without any options shows such arcane, rarely needed details as send/receive queue size but not the application socket belongs to.
And omits listening sockets which is main use for such tools.
I know picking the right defaults is hard ask but they managed to pick all the wrong defaults.
jcgl|2 months ago
Generally speaking, you can only have sensible defaults over time if you're able to change the defaults over time. New users and new use-cases come with time, and so what constitutes a "sensible default" changes.
However (and this is a drum I like to bang[0]), because unix tools only deal in usually-text bytestreams without any higher level of abstraction, consumers of those tools end up tightly coupled with how output is presented. Without any separation between data and its representation, the (default) representation is the tool's API. To change the default representation is to make a backwards-incompatible API change. A good example of this is how ps aux truncates longer than like 7 characters.
[0] https://www.cgl.sh/blog/posts/sh.html
1vuio0pswjnm7|2 months ago
And omits listening sockets which is main use for such tools."
IMHO this would be one of the many arguments in favor of compiling from source rather than using "binary packages"^1
https://mirrors.edge.kernel.org/pub/linux/utils/net/iproute2...
This changes the default to display all sockets, hide the queues and show the processes using each socketIt also adds adds a -q option to display the queues
1. IMHO this is also an argument against "cloud computing", i.e., using someone else's computers where pre-installed kernels and binary packages are the norm
laserbeam|2 months ago
I think we understand that UX problem much better now than developers did back in the 70s. In general, not just for ss/lsof
petepete|2 months ago
Being able to use them intuitively trumps ubiquity, speed or features.
ectospheno|2 months ago
mikeryan|2 months ago
Might need a different name.
https://www.obdev.at/products/littlesnitch/index.html
wkat4242|2 months ago
stressback|2 months ago
karol-broda|2 months ago
mrjay42|2 months ago
cretinoid|2 months ago
fulafel|2 months ago
karol-broda|2 months ago
aos|2 months ago
mabedan|2 months ago
UI libraries have a lot of features for allowing people with disabilities to “read” and interact with the screen in efficient ways
themafia|2 months ago
Is it possible I've missed something from the demonstration video on that page?
karol-broda|2 months ago
INTPenis|2 months ago
That said though, I'm not going to install snitch. The thing about ss is that it's already there, on every server I manage. And I definitely do not need a TUI for this.
Snitch is something you might install in your homelab, or your workstations. But ss is still the default when you provision a lot of servers.
karol-broda|2 months ago
rramadass|2 months ago
Howto Guide - https://anto.online/mastering-netwag-guide/
karol-broda|2 months ago
poemxo|2 months ago
karol-broda|2 months ago
pdimitar|2 months ago
Melonai|2 months ago
I find it a bit interesting that Go even allows you to declare `module barename` in go.mod even though it loves breaking so many things if you do so. I sometimes try doing it for completely private projects but I always just declare some URL in the end, it's a weird anti-pattern in my opinion.
PhilippGille|2 months ago
karol-broda|2 months ago
coppsilgold|2 months ago
gus_|2 months ago
Many LD_PRELOAD rootkits hide their activity from the system by manipulating the output of libc functions like readdir(), open(), stat(), etc. kernel rootkits can hide whatever they need, but the common functionality is also to hide data from /proc.
That's why netstat, ps, *top or lsof are not reliable tools if the system is compromised. ss is a bit different and is a bit more reliable.
In this case, snitch is written in Go, which doesn't use the libc functions, so probably it'll be able to obtain information from /proc even if hidden by a LD_PRELOAD rootkit.
Another option would be to compile the binary statically.
Anyways, these tools are not meant to unhide malicious traffic or processes, so I think detecting beacons, inspecting traffic, etc, is out of the scope.
Resources:
https://github.com/gustavo-iniguez-goya/decloaker
User-space library rootkits revisited: Are user-space detection mechanisms futile? - https://arxiv.org html/2506.07827v1
The Hidden Threat: Analysis of Linux Rootkit Techniques and Limitations of Current Detection Tools - https://dl.acm.org/doi/10.1145/3688808
https://matheuzsecurity.github.io/hacking/bypass-userland-ho...
https://ops.tips/blog/how-is-proc-able-to-list-pids/
karol-broda|2 months ago
tptacek|2 months ago
cyberax|2 months ago
1. Can you highlight the currently selected row with a different background?
2. Maybe add optional reverse DNS lookups?
karol-broda|2 months ago
TZubiri|2 months ago
For example:
Intent: "create a file"
Command: "touch $FILE"
As it happens, touching a file doesn't mean to create, it was supposed to touch to modify the last access date, like a null op. But now if you want to create a file you do that.
Intent: "Print a file contents to screen" Command: "cat $FILE"
Is this a reference to a feline? some slang for printing or reading? No it's short for concatenate, but if you pass just one argument instead of 2, it prints the concatenation of 1 file and nothing.
Even something as simple as
Intent: "Rename a file" Command: "mv $FILE"
Of ocurse there's the fact that moving a file and renaming the file are very similar if not identical in most FS/OS, but also, the slight change from a word to a proper-name style command already creates a style of command line interaction that was very natural in the 80s, but is now being reinvented with the advent of more powerful language decoding technology. So even:
Intent: "Copy a file" Command: "cp $FILE"
Now to the topic, you can see how my relationship with ss is the mapping:
Intent: "See a list of open ports" Command: "ss -tulnp"
Which I remember mnmemotecnically because it is close to -tulip. This is similar to ps -aux in that the command includes a set of options and I remember it mnemotecnically ("auxiliary" or "auxilio"), and I use the options even when I don't need them, modifying the options from that baseline if needed, like removing "a" to get just the current user's processes.
That said. I don't know if the future is going to be "better" alternatives to old tools, but rather deconstructing or making use of the concept of "binary":"command", running man and --help has never been an optimal solution, and let's be honest, kids nowadays are googling, stackoverflowing and chatgpting their intent in order to get a magical command.
No easy way to improve upon this at the userspace level, the OS model of delegating control to binaries based on a hierarchical command structure is sensible, and "magic", or sharing commands across binaries without a clear ruleset would be too opaque. But I feel that creating new tools while barely revolutionizing the way they work is too small an incremental change, it adds more noise, I'm not sure that ss2 or network-manager instead of wpa_supplicant is a better outcome, now you are just linearly increasing the cognitive demand of new sysadmins linearly with time.
Sorry to be a bummer.
TZubiri|2 months ago
Even in operating systems as distant as Android, we still have the phenomenon of using proper_names instead of natural names.
If you want a taxi or a cab, you don't ask your OS to get you a taxi or cab, you ask it to use the Uber binary.
In the 2000s it wasn't clear that this was going to be the case, the famous example of the pets.com domain was a wrong bet that natural names would somehow be important.
Instead natural names are only important when used through an obscure privately controlled algorithm like Google or StackoverFlow or ChatGPT, if you want to say "flights to Greece" instead of "Oobloo greece", you need a magical black box in the middle.
coolbean|2 months ago
karol-broda|2 months ago
stavros|2 months ago
karol-broda|2 months ago
hwj|2 months ago
`brew install snitch`
karol-broda|2 months ago
unknown|2 months ago
[deleted]
hashstring|2 months ago
wittjeff|2 months ago
karol-broda|2 months ago
andrewmcwatters|2 months ago
[deleted]
stressback|2 months ago
Thanks for sharing
rockskon|2 months ago
Systemd's obsession with remaking every single wheel in Linux has been aggravating enough. Please don't do it again.
hn_throw2025|2 months ago
Before systemd presented a generalised interface, there were significant differences in the init and service management systems between the popular Red Hat and Debian families of distros.
Underphil|2 months ago
beaudidly|2 months ago
winternewt|2 months ago