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.
Hah yes, I've come to unashamedly - by muscle memory since the 1990's - find myself always typing 'ps auxw[w...]', where [w...] is some arbitrary number of w's depending on how heavy my index finger feels at the moment of typing.
however this breaks backward compatibility, as you noted. in the golden age of unix it was critical to maintain backward compatibility so that local tooling didn't magically break.
HP-UX seems to have an env var UNIX95 that affects XPG4 compliance in operation/output. Solaris always had a /usr/xpg[46] path (and /usr/ucb). GNU tools have POSIXLY_CORRECT. and so on.
I never liked using any of those because then you're on some other system, or in a break glass situation, and none of the tooling works as you expect. In the today world of a near monoculture of linux, it's fine I guess. And there's no reason today that complex commands like `ss` shouldn't be controllable via env var.
Configuring configuration via env var is a good historical example. I think that especially works nicely when you Buy An Operating System. You know, one that is created and provided by A Vendor. In principle, the vendor can architect a unified metaconfiguration system, e.g. one or several env vars that align behavior to a standard.
But I dunno if it would work so well to to hypothetically apply that tactic to a modern bazaar-based OS like Linux. Distros do amazing, valuable work to unify things, but modern Linux is basically a zillion software packages in a trench coat. So either the distro carries a zillion patches to have a few env vars, or the distro carries no patches and there are a zillion env vars. Either way, total cost of maintenance explodes.
Maybe when people say "text is the universal interface," they really mean that once you've released a textual interface, the interface becomes universal, unchanging for all time.
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
But it's not tradeoff! You can make default view useful without trading versatility.
Another annoying part is not supporting json or even CSV. Some tools got modernized with it (like iproute2 tool set), but for these you might as well do /proc scraping yourself...
That's true in general. But default view is still subjective. The challenge probably lies in recognizing the larges subset of your user base that would like it to be a certain consistent way.
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?
TUI tools are generally as accessible as the terminal on which they run.
GUI apps are much trickier. They require that the developer implement integration with accessibility frameworks (which vary depending on X11/Wayland) or use a toolkit which does this.
GUI kits like AppKit or GTK have built-in accessibility features like standard components (input fields, dropdown boxes) and view hierarchy that interact with accessibility tools for free. It's the main upside of a GUI.
TUIs are tricky.
I think TUI accessibility generally involves rereading the screen on changes (going by macOS VoiceOver). It can optimize this if you use the terminal cursor (move it with ansi sequences) or use simple line-based output, but pretty much zero TUIs do this. You'd have to put a lot of thought into making your TUI screenreader friendly compared to a GUI.
The thing going for you when you build a TUI is that people are used to bad accessibility so they don't expect you to solve the ecosystem. Kind of like how international keyboards don't work in terminal apps because terminal emulator doesn't send raw key scans.
How are TUI tools just as accessible as the terminal? Take a visually-simple program like neomutt or vim. How does a vision-impaired user understand the TUI's layout? E.g. splits and statusbar in vim, or the q:Quit d:Del... labels at the top of neomutt. It seems to me like the TUI, because it only provides the abstraction of raw glyphs, any accessibility is built on hopes and dreams. More complicated TUIs like htop or glances seem like they would be utterly hopeless.
When it comes to GUIs, you have a higher level of abstraction than grid-of-glyphs. By using a GUI toolkit with these abstractions, you can get accessibility (relatively) for free.
Additionally in sysadmin, blind-users are not just some random group, the ability not to use one's eyes is central to the Command Line Interface. You could always in theory get by with just a keyboard and a TTS that reads out the output, it's all based on the STDIO abstractions that are just string streams, completely compatible and accessible to blind, and even deaf users. (Unlike GUIs)
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.
I was just pointing to another network tool used for all sorts of fine-grained networking jobs (eg. security testing and others) which might be helpful to others.
It was created by Laurent Constantin (https://linuxsecurity.com/features/introduction-to-netwox-an...) for his own needs and hence the TUI/GUI is not polished. But it is simple, direct and gets the job done which is what is important. And it is a mature tool (hence no need for active maintenance) available in all Linux distros.
Sorry for slow response. Snitch sounds like a tool that will do intercepting or alerting. Little Snitch is perfectly named in this regard. When it pops up prompting you for action, it feels like it just snitched on an app.
What you have here isn't a snitch, it's more like a full map of traffic. I don't have any other suggestions unfortunately.
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.
In any case, interesting to think of shared libraries (specifically shared libc) as a risk here. Makes sense, but I hadn't thought about it before.
That said, I'm having a hard time doing a threat model where you worry about an attacker only setting LD_PRELOAD but not modifying PATH. The latter is more general and can screw you with all programs (doesn't cover shell builtins, but it's not like those would just be one more step).
Nowadays, there's only one rootkit that can hide itself so perfectly: the Singularity rootkit. It also hides from auditd by using netlink_unicast hooking and other evasive functionalities. Analyzing a machine compromised with Singularity loaded is a real headache, since it prevents memory dumps for analysis.
Okay yeah, sure. So it's not intrinsically more reliable or anything, it's just not specifically vulnerable to LD_PRELOAD. And it's not clear to me why LD_PRELOAD would be a particularly interesting attack vector, but maybe that's just my ignorance.
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]).
> The “SH” state indicates that the remote peer sent a SYN followed by a FIN—however, the monitor never recorded a SYN-ACK from the local peer. At first glance, this would seem to indicate a scanner that is trying to make connection attempts look
as real as possible in the hopes of not triggering an alarm. However, such connections can also indicate a vantage point problem whereby the monitor is not observing outgoing traffic from some hosts. While in general the monitor placement at LBNL can observe both incoming and outgoing traffic, there were periods of time where the traffic for some LBNL hosts would partially bypass the monitor. From a measurement perspective this is clearly undesirable.
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.
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.
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
$ brew info snitch
==> snitch: stable 0.1.8 (bottled), HEAD
Prettier way to inspect network connections
https://github.com/karol-broda/snitch
Installed
/opt/homebrew/Cellar/snitch/0.1.8 (9 files, 8.4MB) \*
Poured from bottle using the formulae.brew.sh API on 2025-12-23 at 15:32:41
From: https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/s/snitch.rb
License: MIT
==> Dependencies
Build: go
==> Options
--HEAD
Install HEAD version
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.
Those additional programs can be freely chosen by distros and/or users. So each of them has to stand on their merit. Though of course they do get some built-in credibility by coming from the systemd project. But for the most part, I think systemd software just tends to have competitive offerings with nice interfaces.
I'm annoyed at it replacing resolvconf. At reboot. At date. At logging. At cron. At ntpd. At network configuration scripts.
Some of these I'm sure make life easier for maintainers. Others just feel like change for the sake of change. Breaking workflows because someone wanted to design a better wheel.
Other than logging (journald is one of the few truly core systemd components), these are all basically independent programs chosen by your distro. As such, each is best evaluated independently. Let's give it an honest shot:
- resolv.conf: systemd-resolved is not unique here in providing a stub resolver and not just NSS functionality (it's been years, but isn't unbound often the same way?). And if you want to have systemd-resolved but not have its stub used in resolv.conf, you're free to do so! Just remove the symlink that is /etc/resolv.conf and replace its contents with whatever you choose.
- cron: systemd timers provide an alternative to cron. You're still allowed to create cron jobs and use cronie (or whatever traditional cron implementation) you like.
- ntpd: leaving aside the fact that most distros (I think?)
nowadays use chrony rather than ntpd or systemd-timesyncd, you're likely free to switch to chrony or ntpd depending on your distro. Afaik, this isn't a daemon with deep system integration, and you should be able to plug-and-play without much issue.
- network configuration scripts: What're you comparing systemd-networkd to? NetworkManager? Debian's ifupdown scripts? RH-family's network-scripts? In any case, network management systems tend to be pretty pluggable (much like in the case of your cron daemon). You can even have them live side-by-side, managing different interfaces, e.g. have NetworkManager do WLAN, while systemd-networkd does Ethernet interfaces.
I don't know any of the story behind timedatectl, so I'll avoid opining on that one.
But generally, it really seems like each of these components is as pluggable and freely-choosable by a distro as one could reasonably hope for. And, like you acknowledge, they end up likely getting chosen because it's easier for distro maintainers. Which is kind of a big deal, imo. But if you don't like your distro's choice, it makes sense to complain to your distro.
In general, I think your suggesting that these new-ish (most of which are no longer very new) components were just made for the hell of it, I'd encourage you to look a little deeper into what they offer compared to the incumbents. For starters, they generally work together pretty cohesively, e.g. systemd-networkd and systemd-resolved do some mutual coordination stuff that's pretty nice. Systemd timers have numerous nice properties compared to cron. Etc.
Again, you (or your distro) are free to take or leave these components, since they can be picked on their own. But an analysis of "these new components from the systemd project 1) are forced on me, 2) exist primarily for the sake of change" seems both incorrect and uncharitable.
it's weird that both lsof and ss defaults are so awful
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.
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.
[0] https://www.cgl.sh/blog/posts/sh.html
Hah yes, I've come to unashamedly - by muscle memory since the 1990's - find myself always typing 'ps auxw[w...]', where [w...] is some arbitrary number of w's depending on how heavy my index finger feels at the moment of typing.
> change the defaults over time
however this breaks backward compatibility, as you noted. in the golden age of unix it was critical to maintain backward compatibility so that local tooling didn't magically break.
HP-UX seems to have an env var UNIX95 that affects XPG4 compliance in operation/output. Solaris always had a /usr/xpg[46] path (and /usr/ucb). GNU tools have POSIXLY_CORRECT. and so on.
I never liked using any of those because then you're on some other system, or in a break glass situation, and none of the tooling works as you expect. In the today world of a near monoculture of linux, it's fine I guess. And there's no reason today that complex commands like `ss` shouldn't be controllable via env var.
love your blog, thanks for the link.
> love your blog, thanks for the link.
Thank you!
Configuring configuration via env var is a good historical example. I think that especially works nicely when you Buy An Operating System. You know, one that is created and provided by A Vendor. In principle, the vendor can architect a unified metaconfiguration system, e.g. one or several env vars that align behavior to a standard.
But I dunno if it would work so well to to hypothetically apply that tactic to a modern bazaar-based OS like Linux. Distros do amazing, valuable work to unify things, but modern Linux is basically a zillion software packages in a trench coat. So either the distro carries a zillion patches to have a few env vars, or the distro carries no patches and there are a zillion env vars. Either way, total cost of maintenance explodes.
Maybe when people say "text is the universal interface," they really mean that once you've released a textual interface, the interface becomes universal, unchanging for all time.
"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."
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
> I know picking the right defaults is hard
I think we understand that UX problem much better now than developers did back in the 70s. In general, not just for ss/lsof
I think the same applies for many of the new breed of command line applications like fd and ag/rg.
Being able to use them intuitively trumps ubiquity, speed or features.
But it's not tradeoff! You can make default view useful without trading versatility.
Another annoying part is not supporting json or even CSV. Some tools got modernized with it (like iproute2 tool set), but for these you might as well do /proc scraping yourself...
That's true in general. But default view is still subjective. The challenge probably lies in recognizing the larges subset of your user base that would like it to be a certain consistent way.
ss is from the same batch of modernization as iproute2.
Depends on the use case.
If used in scripts, ubiquity and speed can be important. Then again, the output of ss is not ideal for script processing.
That's the problem, it's not good for humans, it's not great for scripts
Very curious what is wrong about the rg defaults.
The only one I change is to add `--no-ignore`.
Nothing.
fd, rg and ag all work how I expect them to work and the arguments and order fit in with my expectations for modern cli applications.
They're recursive, they ignore things I don't care about and I can just give them the string I'm looking for, no path, no -name or --recursive etc.
find and grep do similar things but work entirely differently and their args aren't even in the same format.
Don’t “netstat -utan” and “ss -utan” show basically the same thing?
"utan" means "without" in Swedish, so I use the more flowery "-tulpan" as my mnemonic. It means tulip.
When I saw this headline I assumed it was Little Snitch an existing network monitor and firewall for Macs.
Might need a different name.
https://www.obdev.at/products/littlesnitch/index.html
There's also a Linux clone of little snitch, OpenSnitch.
There's also https://github.com/snitch-org/snitch with the AUR package name 'snitch'.
Seems like a fine name. Why would little snitch existing necessitate a name change?
Because it's potentially trademark infringement because it could confuse people.
Can you actually trademark a common word? (Serious question)
Yes, Apple, Windows, Amazon, Shell, Target, Dove, Ivory, Tide, Polo.
(With help from Claude completing the list)
Remember the trademark fights between Apple Music (Beatles) and Apple Computer? Interesting history.
Sosumi!
Yes, but only for a fair tight class of business
Exactly right.
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
Wow that's so nice, would there be an equivalent for PC? (Windows or Linux)
1. Linux → https://github.com/evilsocket/opensnitch
2. Windows → https://www.glasswire.com/
3. Windows (open source) → https://github.com/henrypp/simplewall
4. Windows → https://safing.io/
I've been a long time Litte Snitch user. However, these days I'm just using LuLu: https://objective-see.org/products/lulu.html
Why did you switch? Price? OSS? Or does LuLu have compelling features?
It's a mix of everything (in no particular order):
- the author of LuLu is a security researcher; he also wrote "The Art of Mac Malware"
- I already bought two versions of Little Snitch and wasn't willing to pay for the third one
- contacting their support left a bitter aftertaste
> - I already bought two versions of Little Snitch and wasn't willing to pay for the third one
I have probably also paid for three versions. It’s a great piece of software and they do not require upgrades excessively.
But I will try LuLu. I would rather my security software was OSS.
Thank you <3
dotfiles/scripts/netstatpsutil.py: https://github.com/westurner/dotfiles/blob/develop/scripts/n...
Textual or similar for a top-like mode would be cool someday
scripts/lsof.sh does lsof from /proc/*: https://github.com/westurner/dotfiles/blob/develop/scripts/l...
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?
> The names these people come up with are so embarrassing. And I'm not even talking about the meaning of 'snitch'.
They should call it "rat" and be done with it.
Besides, "snitch" works for Little Snitch -- I've always found it somehow endearing, although the bare word is unflattering.
[dead]
It's not even a friendly word
The demo recording-as-code seems cool (in https://github.com/karol-broda/snitch/tree/master/demo)
thanks :), havent really seen this much in other projects
I love the recent increase in TUI-based tooling. This looks cool - will check it out!
Are they as accessible as GUI though (genuine question)
UI libraries have a lot of features for allowing people with disabilities to “read” and interact with the screen in efficient ways
TUI tools are generally as accessible as the terminal on which they run.
GUI apps are much trickier. They require that the developer implement integration with accessibility frameworks (which vary depending on X11/Wayland) or use a toolkit which does this.
GUI kits like AppKit or GTK have built-in accessibility features like standard components (input fields, dropdown boxes) and view hierarchy that interact with accessibility tools for free. It's the main upside of a GUI.
TUIs are tricky.
I think TUI accessibility generally involves rereading the screen on changes (going by macOS VoiceOver). It can optimize this if you use the terminal cursor (move it with ansi sequences) or use simple line-based output, but pretty much zero TUIs do this. You'd have to put a lot of thought into making your TUI screenreader friendly compared to a GUI.
The thing going for you when you build a TUI is that people are used to bad accessibility so they don't expect you to solve the ecosystem. Kind of like how international keyboards don't work in terminal apps because terminal emulator doesn't send raw key scans.
How are TUI tools just as accessible as the terminal? Take a visually-simple program like neomutt or vim. How does a vision-impaired user understand the TUI's layout? E.g. splits and statusbar in vim, or the q:Quit d:Del... labels at the top of neomutt. It seems to me like the TUI, because it only provides the abstraction of raw glyphs, any accessibility is built on hopes and dreams. More complicated TUIs like htop or glances seem like they would be utterly hopeless.
When it comes to GUIs, you have a higher level of abstraction than grid-of-glyphs. By using a GUI toolkit with these abstractions, you can get accessibility (relatively) for free.
Open to having my mind changed though.
Accessibility is a great thing to have and strive for, but it cannot be the number one design principle.
Imagine if everything around us would be designed for blind people.
I suspect blind people imagine that a lot.
The idea is to design for all (or as many as feasible), it's not a binary either/or.
You cannot design a lot of TUI for all. Should we abandon TUI entirely ?
Not necessarily designed for, but accessible to.
Additionally in sysadmin, blind-users are not just some random group, the ability not to use one's eyes is central to the Command Line Interface. You could always in theory get by with just a keyboard and a TTS that reads out the output, it's all based on the STDIO abstractions that are just string streams, completely compatible and accessible to blind, and even deaf users. (Unlike GUIs)
It looks nice, and I don't see anything wrong with it, but I've been using iptraf-ng since forever and I think it has a slight edge here.
Is it possible I've missed something from the demonstration video on that page?
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.
An old classic powerful network tool; Netwox (i.e. Network Toolbox with more than 200 tools) and Netwag (Tcl/Tk GUI) - https://ntwox.sourceforge.net/ and https://ntwag.sourceforge.net/
Howto Guide - https://anto.online/mastering-netwag-guide/
this is supposed to be an actually maintained terminal utility for viewing ss/netstat data
I was just pointing to another network tool used for all sorts of fine-grained networking jobs (eg. security testing and others) which might be helpful to others.
It was created by Laurent Constantin (https://linuxsecurity.com/features/introduction-to-netwox-an...) for his own needs and hence the TUI/GUI is not polished. But it is simple, direct and gets the job done which is what is important. And it is a mature tool (hence no need for active maintenance) available in all Linux distros.
I don't like the name but I like the TUI, connection monitoring is perfectly handled by a TUI!
thanks, but what don’t you like about the name?
Sorry for slow response. Snitch sounds like a tool that will do intercepting or alerting. Little Snitch is perfectly named in this regard. When it pops up prompting you for action, it feels like it just snitched on an app.
What you have here isn't a snitch, it's more like a full map of traffic. I don't have any other suggestions unfortunately.
Just my 2c
When attempting to install through go:
I get this error message: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.
They fixed it 6 hours ago, but it's not in a release yet: https://github.com/karol-broda/snitch/commit/7fdb1ed477894f1...
i fixed it and created a release so building from @latest should work now
Would you consider vendoring dependencies? It would be helpful for offline builds, especially when writing packaging scripts :D
It is indeed fixed now. Thank you!
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.
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/
What makes ss different?
In any case, interesting to think of shared libraries (specifically shared libc) as a risk here. Makes sense, but I hadn't thought about it before.
That said, I'm having a hard time doing a threat model where you worry about an attacker only setting LD_PRELOAD but not modifying PATH. The latter is more general and can screw you with all programs (doesn't cover shell builtins, but it's not like those would just be one more step).
ss obtains the connections information via netlink directly from the kernel (besides parsing /proc):
https://manpages.debian.org/bookworm/manpages/sock_diag.7.en...
https://github.com/vishvananda/netlink/blob/main/inet_diag.g...
Not many rootkits tamper the netlink channel, so in most cases it's a bit more reliable.
Nowadays, there's only one rootkit that can hide itself so perfectly: the Singularity rootkit. It also hides from auditd by using netlink_unicast hooking and other evasive functionalities. Analyzing a machine compromised with Singularity loaded is a real headache, since it prevents memory dumps for analysis.
https://github.com/MatheuZSecurity/Singularity
Okay yeah, sure. So it's not intrinsically more reliable or anything, it's just not specifically vulnerable to LD_PRELOAD. And it's not clear to me why LD_PRELOAD would be a particularly interesting attack vector, but maybe that's just my ignorance.
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
With a name like Snitch, it should be aimed at adversarial detection.
Just my two snitches.
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]).
That search did not come up with much. Can you elaborate?
Not tptacek, but my search yielded this which seems relevant (to the network monitoring tool once named Bro, now Zeek):
https://www.icir.org/mallman/pubs/APT07/APT07.pdf
> The “SH” state indicates that the remote peer sent a SYN followed by a FIN—however, the monitor never recorded a SYN-ACK from the local peer. At first glance, this would seem to indicate a scanner that is trying to make connection attempts look as real as possible in the hopes of not triggering an alarm. However, such connections can also indicate a vantage point problem whereby the monitor is not observing outgoing traffic from some hosts. While in general the monitor placement at LBNL can observe both incoming and outgoing traffic, there were periods of time where the traffic for some LBNL hosts would partially bypass the monitor. From a measurement perspective this is clearly undesirable.
Nice! Couple of notes:
1. Can you highlight the currently selected row with a different background?
2. Maybe add optional reverse DNS lookups?
was thinking of adding more customizable theming, like highlighting the background and reverse dns resolution was released earlier
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.
that actually is planned for a future version
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.
Sorry to be a bummer.
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.
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.
yea i was kinda fed up
The README doesn't mention this, but on macOS it's also available via brew:
`brew install snitch`
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
I didn't verify anything, but used the brew install and the installed cli at least looks and behaves like I expected from this HN post.
Name can be friendlier, tui looks nice!
I can't read as fast as your demo GIF. Just infuriating.
it’s all code, if you want you can make a pr with adjustments to the demo
[dead]
prettyneat.gif
Thanks for sharing
I just want a single tool that has a known, generalized set of capabilities on just about every distribution.
Systemd's obsession with remaking every single wheel in Linux has been aggravating enough. Please don't do it again.
Ironic choice of example…
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.
Not what I meant. Systemd has been replacing a bunch of commands too. Not just the init system.
Those additional programs can be freely chosen by distros and/or users. So each of them has to stand on their merit. Though of course they do get some built-in credibility by coming from the systemd project. But for the most part, I think systemd software just tends to have competitive offerings with nice interfaces.
I'm annoyed at it replacing resolvconf. At reboot. At date. At logging. At cron. At ntpd. At network configuration scripts.
Some of these I'm sure make life easier for maintainers. Others just feel like change for the sake of change. Breaking workflows because someone wanted to design a better wheel.
Other than logging (journald is one of the few truly core systemd components), these are all basically independent programs chosen by your distro. As such, each is best evaluated independently. Let's give it an honest shot:
- resolv.conf: systemd-resolved is not unique here in providing a stub resolver and not just NSS functionality (it's been years, but isn't unbound often the same way?). And if you want to have systemd-resolved but not have its stub used in resolv.conf, you're free to do so! Just remove the symlink that is /etc/resolv.conf and replace its contents with whatever you choose.
- cron: systemd timers provide an alternative to cron. You're still allowed to create cron jobs and use cronie (or whatever traditional cron implementation) you like.
- ntpd: leaving aside the fact that most distros (I think?) nowadays use chrony rather than ntpd or systemd-timesyncd, you're likely free to switch to chrony or ntpd depending on your distro. Afaik, this isn't a daemon with deep system integration, and you should be able to plug-and-play without much issue.
- network configuration scripts: What're you comparing systemd-networkd to? NetworkManager? Debian's ifupdown scripts? RH-family's network-scripts? In any case, network management systems tend to be pretty pluggable (much like in the case of your cron daemon). You can even have them live side-by-side, managing different interfaces, e.g. have NetworkManager do WLAN, while systemd-networkd does Ethernet interfaces.
I don't know any of the story behind timedatectl, so I'll avoid opining on that one.
But generally, it really seems like each of these components is as pluggable and freely-choosable by a distro as one could reasonably hope for. And, like you acknowledge, they end up likely getting chosen because it's easier for distro maintainers. Which is kind of a big deal, imo. But if you don't like your distro's choice, it makes sense to complain to your distro.
In general, I think your suggesting that these new-ish (most of which are no longer very new) components were just made for the hell of it, I'd encourage you to look a little deeper into what they offer compared to the incumbents. For starters, they generally work together pretty cohesively, e.g. systemd-networkd and systemd-resolved do some mutual coordination stuff that's pretty nice. Systemd timers have numerous nice properties compared to cron. Etc.
Again, you (or your distro) are free to take or leave these components, since they can be picked on their own. But an analysis of "these new components from the systemd project 1) are forced on me, 2) exist primarily for the sake of change" seems both incorrect and uncharitable.
No-one is stopping you from using netstat.
What’s with the hostility of someone making something that’s useful for themselves and sharing it with others?
That's not a feature that the developer has control over. All they can do is try to develop a good tool.