Snitch – un outil `ss`/`netstat` plus convivial

 (github.com/karol-broda)
7 points par GN⁺ 2025-12-25 | 1 commentaires | Partager sur WhatsApp
  • Snitch est un outil d’inspection des connexions réseau plus lisible pour les humains que ss ou netstat, avec prise en charge d’une interface terminale (TUI) et de tableaux stylisés
  • Il affiche l’état des connexions dans un écran interactif en temps réel ou sous forme de tableau affiché en une seule fois, avec divers filtres comme TCP/UDP, écoute, connecté
  • Il inclut des fonctions de sortie JSON·CSV, résolution DNS/noms de services, surveillance et arrêt de processus, ainsi que mise à jour automatique
  • Il prend en charge plusieurs méthodes d’installation, notamment Homebrew, Go, Nix, Arch Linux, script shell et binaire, avec suppression automatique de l’avertissement Gatekeeper sur macOS
  • C’est un outil utile pour les développeurs et les administrateurs système afin de surveiller intuitivement les connexions réseau et de l’utiliser dans l’automatisation par script

Vue d’ensemble

  • Snitch est un outil conçu pour explorer visuellement les connexions réseau, pensé comme une alternative à ss ou netstat
  • Il affiche l’état des connexions via une interface TUI ou une sortie tabulaire stylisée
  • Il fonctionne sous Linux et macOS, et peut nécessiter des droits root ou la capacité CAP_NET_ADMIN

Installation

  • Homebrew : installation possible avec la commande brew install snitch
  • Go : go install github.com/karol-broda/snitch@latest
  • Nix/NixOS : nix-env -iA nixpkgs.snitch ou ajout possible comme entrée flake
  • Arch Linux (AUR) : yay -S snitch-bin ou paru -S snitch-bin
  • Script shell : installation avec la commande curl -sSL ... | sh, chemin par défaut ~/.local/bin ou /usr/local/bin
    • Sur macOS, le script d’installation supprime automatiquement l’attribut de quarantaine
  • Téléchargement du binaire : versions Linux (.tar.gz, .deb, .rpm, .apk) et macOS (.tar.gz) disponibles via GitHub Releases

Démarrage rapide

  • L’exécution de snitch lance le TUI interactif
  • snitch -l affiche uniquement les sockets en écoute, et snitch ls affiche un tableau puis quitte
  • snitch ls -t -e affiche uniquement les sessions TCP connectées, et snitch ls -p produit une sortie simple et analysable

Commandes principales

  • snitch / snitch top : affiche une liste de connexions mise à jour en temps réel
    • Options : -l (écoute), -t (TCP), -e (connecté), -i (intervalle de rafraîchissement)
    • Raccourcis clavier : déplacement j/k, bascule TCP·UDP avec t/u, arrêt d’un processus avec K, recherche avec /, quitter avec q, etc.
  • snitch ls : affiche un tableau en une seule fois, avec utilisation automatique d’un pager si la sortie dépasse la hauteur du terminal
    • Formats de sortie : tableau par défaut, -o json, -o csv, -p (simple), --no-headers (sans en-têtes)
  • snitch json : sortie au format JSON exploitable dans des scripts
  • snitch watch : diffuse des frames JSON à intervalles réguliers
  • snitch upgrade : vérifie la version et effectue une mise à jour automatique

Options de filtre et de résolution

  • Drapeaux communs : -t (TCP), -u (UDP), -l (écoute), -e (connecté), -4 (IPv4), -6 (IPv6)
  • Résolution DNS et noms de services :
    • Prise en charge des options --resolve-addrs, --resolve-ports, --no-cache
    • Effectue des requêtes DNS en parallèle avec mise en cache, désactivable via --no-cache
  • Filtrage détaillé : spécification du nom de processus, port, état, etc. au format key=value
    • Exemple : snitch ls proto=tcp state=listen, snitch ls proc=nginx

Formats de sortie

  • Sortie tabulaire par défaut : nom du processus, PID, protocole, état, adresse locale et port
  • Sortie simple (-p) : texte facile à parser
  • Sortie JSON/CSV : utile pour l’automatisation par script et l’analyse de journaux

Configuration et variables d’environnement

  • Fichier de configuration : ~/.config/snitch/snitch.toml
    • Réglages possibles : numeric, dns_cache, theme (auto/dark/light/mono)
  • Variables d’environnement :
    • Prise en charge de SNITCH_THEME, SNITCH_RESOLVE, SNITCH_DNS_CACHE, SNITCH_NO_COLOR, SNITCH_CONFIG, etc.

Exigences système

  • Nécessite un environnement Linux ou macOS
  • Linux : lecture des données depuis /proc/net/*, avec droits root ou CAP_NET_ADMIN requis pour les informations complètes sur les processus
  • macOS : utilisation des API système, avec sudo requis pour les informations complètes sur les processus

À lire aussi

1 commentaires

 
GN⁺ 2025-12-25
Avis Hacker News
  • Les paramètres par défaut de lsof et ss sont vraiment peu pratiques
    ss affiche dans sa sortie par défaut des informations rarement utiles, comme la taille des files d’attente d’envoi/réception, mais n’indique pas à quelle application appartient le socket
    En plus, il omet par défaut les sockets en écoute, alors que c’est justement l’un des usages principaux de ce type d’outil
    Je sais qu’il est difficile de bien choisir les valeurs par défaut, mais ici c’est presque un cas d’école où tout a été mal choisi
    • Tout à fait d’accord. Les outils Unix ont à long terme une limite structurelle qui rend difficile le maintien de valeurs par défaut raisonnables
      Avec le temps, les utilisateurs et les cas d’usage changent, donc les valeurs par défaut devraient évoluer elles aussi, mais dans les outils Unix le format de sortie fait office d’API, donc le moindre changement crée des problèmes de rétrocompatibilité
      Par exemple, si ps aux tronque les noms de processus longs à environ 7 caractères, c’est pour cette raison
      Article lié : sh and the separation of data and representation
    • Aujourd’hui, on comprend bien mieux l’UX. Quand les développeurs des années 70 ont créé ss ou lsof, ils ne semblaient pas encore bien cerner ce genre de problèmes d’utilisabilité
    • Les outils CLI nouvelle génération comme fd, ag ou rg rencontrent des problèmes similaires
      À mon avis, une utilisabilité intuitive compte bien plus que la vitesse ou les fonctionnalités
    • netstat -utan et ss -utan semblent afficher presque les mêmes informations
  • En voyant le titre, j’ai d’abord cru qu’il s’agissait de Little Snitch, l’outil de supervision réseau pour Mac
    Comme le nom fait doublon, ce serait peut-être mieux d’en choisir un autre
    Site officiel de Little Snitch
    • Il existe aussi un clone pour Linux appelé OpenSnitch
    • Je trouve que le nom va très bien. Ce n’est pas parce que Little Snitch existe déjà qu’il faut forcément le changer
    • Je ne pense pas non plus qu’il faille changer le nom. L’usage est complètement différent de celui de Little Snitch
      Snitch est simplement un outil qui présente de façon plus lisible dans le terminal les données de ss/netstat
    • Waouh, c’est sympa. Je me demande s’il existe aussi des alternatives pour Windows ou Linux
    • J’ai eu exactement la même réaction au début. Le nom me paraît vraiment trop embarrassant
      Je ne comprends pas pourquoi reprendre exprès un nom si proche alors qu’il existe déjà un outil similaire dans le même domaine IT
  • L’approche recording-as-code de la démo est intéressante
    Lien vers la démo
    • Merci :) J’ai rarement vu cette approche dans d’autres projets
  • J’adore voir qu’il y a de plus en plus d’outils basés sur des TUI ces temps-ci. Ce projet a l’air excellent, je compte vraiment l’essayer
    • En revanche, je me demande si les TUI sont aussi bonnes que les GUI en matière d’accessibilité
      Les bibliothèques GUI ont diverses fonctionnalités pour des utilisateurs comme les personnes malvoyantes, alors que les TUI sont peut-être plus limitées sur ce point
  • Je suis habitué à ss et je l’utilise bien comme ça. En revanche, je n’ai pas envie de voir les chiffres des files d’attente d’envoi/réception
    La largeur d’écran devient trop importante, donc en écran partagé vertical sur un laptop ça tient à peine
    Je ne compte pas installer Snitch. ss est déjà installé par défaut sur tous les serveurs, et je n’ai pas besoin d’une TUI
    Snitch peut être bien pour un usage personnel ou sur workstation, mais sur serveur, ss reste la base
    • Exactement. Sur serveur, ss est installé par défaut, donc autant l’utiliser tel quel
      Snitch est plus adapté à une workstation ou à du debug sur homelab
      Les files d’attente d’envoi/réception ne sont pas encore affichées, mais j’ai prévu de les ajouter plus tard avec un mode compact ou un bouton de bascule
  • Ça a l’air pas mal, mais j’utilise iptraf-ng depuis longtemps et j’ai toujours l’impression qu’il reste un peu meilleur
    Est-ce qu’il y a une fonctionnalité que j’aurais ratée dans la vidéo de démo ?
    • Merci ! Snitch est plus proche d’un remplaçant pour ss/netstat que d’un moniteur de trafic
      Une fonction de supervision du trafic est prévue, mais elle n’est pas encore implémentée
  • Je n’aime pas le nom, mais surveiller l’état des connexions en TUI est vraiment une très bonne idée
    • Merci. Je serais curieux de savoir quel aspect du nom ne vous plaît pas
  • J’ai essayé de l’installer avec Go, mais j’ai obtenu l’erreur suivante 
    go install github.com/karol-broda/snitch@latest
go: github.com/karol-broda/snitch@latest: version constraints conflict:
module declares its path as: snitch
but was required as: github.com/karol-broda/snitch
    • Le problème venait du fait que le module était déclaré uniquement avec son nom, sans URL. Cela a été corrigé il y a quelques heures
      Je trouve étonnant que Go autorise module barename. On finit de toute façon par utiliser une URL, même dans les projets personnels, et je pense que c’est une mauvaise pratique
    • Le correctif est fait, mais il n’a pas encore été intégré à une release
      Lien vers le commit
    • C’est désormais corrigé et la release a aussi été faite. Si vous compilez avec @latest, cela devrait fonctionner
  • Je me suis toujours demandé à quel point ce genre d’outils pouvait être utile contre un attaquant expérimenté
    Par exemple, si un malware attend un certain moment ou ne communique avec son C&C que pendant l’activité réseau de l’utilisateur, cela semble difficile à détecter
    • Au minimum, ce genre d’outils ferait mieux de ne pas parser /proc directement
      Les rootkits LD_PRELOAD peuvent manipuler la sortie des fonctions libc pour masquer leur activité
      ss est un peu plus fiable sur ce point, et comme Snitch est écrit en Go et n’utilise pas libc, il a des chances d’être plus résistant aux rootkits LD_PRELOAD
      Cela dit, ces outils ne sont pas conçus pour détecter du trafic malveillant, mais pour du debug local
      Références : decloaker, article arXiv, article ACM, explication de la structure de proc
    • Oui, Snitch est destiné au debug/à l’inspection locale, pas à la détection de sécurité
      Un attaquant expérimenté peut de toute façon se fondre dans le trafic légitime
    • Ce genre d’outils n’est pas fait pour des environnements hostiles
      Même les outils réseau destinés à répondre à de vrais attaquants ne sont pas parfaits (mot-clé de recherche : bro vantage point problem)
  • Ce serait bien d’avoir une fonctionnalité affichant le débit actuel et cumulé pour chaque socket/processus
    Pour l’instant j’utilise jnettop, mais je n’aime pas son interface
    • Cette fonctionnalité est prévue pour une prochaine version