Posted by karol-broda 12/23/2025
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.
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.
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.
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.
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...
(
printf '/int state_filter = 0;/a\\\n'
printf 'state_filter = (1 << SS_LISTEN) | (1 << SS_CLOSE);\\\n'
printf 'show_processes++;\\\n'
printf 'show_queues = 0;\\\n'
echo
echo "s/dhalBet/q&/"
printf '/switch (ch) {/a\\\n'
printf "case 'q':show_queues=1;break;\\\n"
echo
)|sed -i -f/dev/stdin misc/ss.c
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 think we understand that UX problem much better now than developers did back in the 70s. In general, not just for ss/lsof
Being able to use them intuitively trumps ubiquity, speed or features.
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...
If used in scripts, ubiquity and speed can be important. Then again, the output of ss is not ideal for script processing.
The only one I change is to add `--no-ignore`.
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.
Might need a different name.
(With help from Claude completing the list)
2. Windows → https://www.glasswire.com/
3. Windows (open source) → https://github.com/henrypp/simplewall
4. Windows → https://safing.io/
- 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 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.
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...
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.
UI libraries have a lot of features for allowing people with disabilities to “read” and interact with the screen in efficient ways
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.
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.
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.
Imagine if everything around us would be designed for blind people.
The idea is to design for all (or as many as feasible), it's not a binary either/or.
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)
Is it possible I've missed something from the demonstration video on that page?
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.
Howto Guide - https://anto.online/mastering-netwag-guide/
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.
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
go install github.com/karol-broda/snitch@latest
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/snitchI 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.
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...
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).
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.
Just my two snitches.
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.