Little Snitch pour Linux

 (obdev.at)
2 points par GN⁺ 22 일 전 | 1 commentaires | Partager sur WhatsApp
  • Un outil permettant de visualiser et contrôler les connexions réseau des applications, afin de voir quel programme communique avec quel serveur
  • La Connections View affiche le trafic en temps réel et passé par application, et permet en un clic de bloquer une connexion et de suivre l’utilisation des données
  • Les fonctions Blocklists et Rules permettent de contrôler finement le trafic indésirable par catégorie ou selon des conditions détaillées
  • En interne, l’outil utilise eBPF pour surveiller les connexions au niveau du noyau et fournit une interface sous forme de PWA via une UI web
  • Ce n’est pas un outil de sécurité, mais un outil centré sur la confidentialité : il convient pour bloquer les communications externes de logiciels ordinaires, mais reste limité pour se défendre contre des attaques avancées

Aperçu

  • Little Snitch for Linux est un outil qui permet de visualiser et de contrôler en temps réel les connexions réseau des applications
    • Il permet de voir quelle application communique avec quel serveur
    • Il offre le blocage des connexions indésirables, l’enregistrement du trafic et le suivi de l’utilisation des données
  • Nécessite Linux kernel 6.12 ou supérieur et la prise en charge du noyau BTF
  • L’interface web est accessible sur http://localhost:3031/ et peut être installée sous forme de PWA (Progressive Web App)

Surveillance des connexions

  • La Connections View affiche l’activité réseau actuelle et passée par application
    • Elle montre les éléments bloqués par les règles et les listes de blocage, l’utilisation des données et l’historique du trafic
    • Tri et filtrage possibles par activité récente, volume de données et nom
    • Blocage d’une connexion en un clic
  • Le diagramme de trafic en bas visualise le volume de données au fil du temps
    • Si l’on zoome en faisant glisser sur une plage donnée, seules les activités de cette période sont affichées

Gestion des listes de blocage

  • La fonction Blocklists permet de bloquer en masse des catégories de trafic indésirable
    • Téléchargement automatique depuis des sources distantes et maintien à jour
    • Formats pris en charge : une ligne par domaine, une ligne par nom d’hôte, format /etc/hosts (IP + nom d’hôte), plages réseau CIDR

    • Les formats basés sur les jokers, les expressions régulières, les glob et les URL ne sont pas pris en charge

      • Pour plus d’efficacité, il est recommandé d’utiliser des listes basées sur les domaines
      • Exemples de listes : Hagezi, Peter Lowe, Steven Black, oisd.nl
      • Le format .lsrules pour macOS n’est pas compatible avec la version Linux

Règles personnalisées

  • La fonction Rules offre un contrôle plus fin que les blocklists
    • Configuration possible par processus, port et protocole
    • La liste des règles peut être triée et filtrée
  • Elle permet de mettre en place des politiques de contrôle réseau détaillées

Sécurité d’accès

  • Par défaut, l’interface web est accessible à tous les processus exécutés localement
    • Une application malveillante pourrait modifier les règles, changer les listes de blocage ou désactiver les filtres
  • Pour éviter cela, il est possible d’exiger une authentification
    • La configuration détaillée se fait dans la configuration avancée (Advanced configuration)

Architecture interne

  • Utilise eBPF pour s’intégrer à la pile réseau Linux
    • Les programmes eBPF surveillent les connexions sortantes et transmettent les données au démon
    • Le démon se charge du suivi des statistiques, du traitement des règles et de la fourniture de l’interface web
  • Le code source des programmes eBPF et de l’interface web est publié sur GitHub

Configuration avancée

  • L’interface par défaut n’expose que les principaux réglages ; la configuration avancée se fait via des fichiers texte
    • Après modification, il faut redémarrer le démon littlesnitch
  • Chemin de configuration par défaut : /var/lib/littlesnitch/config/
    • Ne pas modifier directement ces fichiers ; copier celui à modifier dans /var/lib/littlesnitch/overrides/config/, puis l’éditer
    • Les paramètres du répertoire override sont toujours prioritaires
  • Principaux fichiers de configuration
    • web_ui.toml : adresse réseau, port, TLS, paramètres d’authentification
      • Si plusieurs utilisateurs peuvent y accéder, il faut activer l’authentification
      • Si l’interface est exposée au-delà du loopback, il faut ajouter TLS
    • main.toml : définit le comportement par défaut pour les connexions qui ne correspondent à aucune règle
      • La valeur par défaut est l’autorisation, mais elle peut être changée en refus si nécessaire
      • Une mauvaise configuration peut entraîner une perte d’accès au système
    • executables.toml : règles de regroupement des exécutables
      • Suppression des numéros de version pour afficher plusieurs versions d’une même application comme une seule
      • Définition des relations parentes pour les shells et les processus de gestion d’applications
      • Amélioration continue grâce aux retours de la communauté
  • Les programmes eBPF et l’interface web peuvent être remplacés par des versions compilées par l’utilisateur
    • Les versions du répertoire override sont prioritaires

Limites

  • Conçu comme un outil de confidentialité, pas de sécurité
    • Il est plus simple que la version macOS et présente des limites fonctionnelles dues aux contraintes d’eBPF
  • eBPF impose des limites de stockage et de complexité des programmes
    • En cas de trafic important, les tables de cache peuvent déborder, rendant incomplète la correspondance entre paquets, processus et noms DNS
    • Des heuristiques sont utilisées pour reconstruire, à partir d’une adresse IP, le nom d’hôte initialement résolu
    • La version macOS effectue une correspondance plus précise grâce à l’inspection approfondie des paquets (DPI)
  • Il convient bien à la surveillance et au blocage des communications externes de logiciels ordinaires, mais il n’est pas adapté à la défense du système contre des attaquants avancés

Licence

  • Composé de 3 éléments
    • Le programme noyau eBPF et l’interface web sont publiés sous GNU GPL v2 et disponibles sur GitHub
    • Le démon (littlesnitch --daemon) est propriétaire (proprietary), mais son utilisation et sa redistribution sont gratuites

À lire aussi

1 commentaires

 
GN⁺ 22 일 전
Réactions sur Hacker News

  • Je n’utilise ni Little Snitch ni Open Snitch, mais je me demandais s’ils pouvaient aussi bloquer des requêtes qui abusent de programmes autorisés
    Par exemple, si suspicious.py appelle Firefox pour envoyer des données, je voudrais savoir si le pare-feu peut l’empêcher

    • Little Snitch for Linux évalue les règles en tenant compte du namespace du processus et de celui du processus parent
      Si un script est exécuté via #!/bin/interpreter, la règle s’applique au chemin du script, mais s’il est lancé sous la forme interpreter script, le comportement est différent
    • Avec des règles simples, ce n’est pas bloqué
      Dans Open Snitch, on peut faire des correspondances fines en se basant par exemple sur la présence d’un processus Python dans l’arbre des parents
    • Si on prend aussi en compte le chargement de bibliothèques ou la manipulation de mémoire entre processus (par ex. OpenProcess, WriteProcessMemory, CreateRemoteThread), cela devient bien plus complexe
      D’anciens pare-feu Windows comme Outpost ou Zone Alarm proposaient une fonction de Leak Control pour détecter ce type de comportement
    • En exploitant les politiques MAC de SELinux, on peut limiter les fichiers et ports accessibles à chaque processus
      La plupart des distributions incluent cette fonctionnalité, mais les utilisateurs ordinaires configurent rarement les règles ou ne les apprennent pas

  • Je l’ai essayé sur Fedora 43, et il a monopolisé tous les cœurs CPU avant d’échouer en laissant 50 K lignes de logs
    L’erreur BPF_PROG_LOAD syscall returned Argument list too long s’est produite

    • Le développeur a indiqué qu’il n’avait pas testé sur Fedora
      Le chargement fonctionne sur une VM ARM64, mais sans réussir à identifier les processus
      Il enquête sur des problèmes de compatibilité eBPF et dit qu’il lui faudra du temps, faute de ressources
    • Une issue GitHub a déjà été ouverte
    • Selon la page de téléchargement officielle, cela ne fonctionne pas sur le système de fichiers Btrfs
      Comme c’est le système de fichiers par défaut de Fedora, l’identification des processus est impossible, et un correctif est prévu en version 1.0.1
    • J’ai eu le même problème. Il n’utilise que la moitié du CPU, mais l’interface web ne fonctionne pas
    • Voilà ce qu’on appelle une expérience Linux ordinaire. La blague sur 2026 comme année du desktop Linux paraît presque crédible

  • En tant qu’utilisateur Linux, j’accorde de l’importance à l’ouverture du code
    La combinaison OpenSnitch + OpenSnitch-UI me convient largement

  • Je me demandais dans quelle mesure un modèle d’outil payant est viable sous Linux
    La plupart des projets sont gratuits, financés par des dons ou en open core
    Je me demande si Little Snitch a publié sa version Linux gratuitement parce qu’il considère que « Linux ne rapporte pas d’argent », ou pour une autre raison

    • La communauté Linux a une forte méfiance envers les logiciels fermés
      Personnellement, un programme propriétaire qui traite tout le trafic réseau me met mal à l’aise
      En revanche, je donne chaque année plusieurs milliers de dollars à des projets FOSS
      Mais ce type d’utilisateur reste minoritaire, donc il est difficile de générer des revenus avec du totalement open source
    • Comme OpenSnitch existe déjà et qu’il est gratuit, un substitut payant a peu d’arguments
      Surtout pour un pare-feu, donc du code très privilégié, il est difficile de faire confiance à quelque chose qui n’est pas open source
    • Le développeur de Little Snitch for Linux a expliqué : « nous sommes une petite équipe indépendante, pas des investisseurs, et cette décision relevait d’un choix personnel »
      Il a ajouté être curieux de voir ce que cela donnera
    • La motivation du développeur est bien expliquée dans le billet de blog officiel

  • Billet de blog lié : Présentation de Little Snitch for Linux

  • Il y avait autrefois ZoneAlarm sur Windows
    Je me suis toujours demandé pourquoi il n’y avait rien de ce genre sur Linux

    • J’avais moi-même créé à l’époque un programme proche de ZoneAlarm pour AmigaOS
      En retrouvant le code de Direwall, j’ai vu qu’il gardait intact ce vieux style C
      Il fonctionnait en patchant la bibliothèque de sockets, et je me demande s’il compilerait encore aujourd’hui
    • La force de ZoneAlarm ne venait pas seulement de la technique, mais aussi de l’éducation des utilisateurs et de la conception UX
      Il expliquait clairement qu’au début il posait beaucoup de questions, puis qu’il devenait silencieux après apprentissage
      C’est ainsi qu’il gagnait la confiance des utilisateurs, et c’est aussi pour cela que je le recommandais
    • À l’époque, comme la plupart des logiciels étaient GNU, il y avait très peu de spyware
      Le besoin de surveiller le réseau est apparu à mesure que des logiciels commerciaux sont arrivés sur Linux
    • Je me souviens avoir utilisé ZoneAlarm au début des années 2000
    • Je me souviens aussi de Kerio Personal Firewall. Je suis ensuite passé à ZA puis à Comodo, et leur fonction d’exécution isolée m’avait marqué
      C’était utile pour limiter l’exécution incontrôlée sous Windows

  • J’utilise Little Snitch depuis longtemps et j’approuve manuellement toutes les requêtes réseau
    Mais je me demande jusqu’où on peut faire confiance à un programme qui a des privilèges de niveau extension noyau
    Comme je trouve très peu d’informations sur l’entreprise ou les développeurs, cela m’intrigue

    • Un développeur de Little Snitch for Linux a répondu directement
      Le composant eBPF est publié en open source GPLv2, consultable dans le code GitHub
      En revanche, le démon doit s’exécuter avec les droits root, donc il faudrait le restreindre via un contrôle d’accès comme SELinux
      Il a ajouté qu’il gérait encore les rapports de bugs de cette première version et qu’il avait été surpris par la diversité des environnements Linux
    • Cette entreprise est un éditeur indépendant sur Mac actif depuis plus de 20 ans, et Little Snitch est un produit apprécié de longue date
    • Je co-développe actuellement un pare-feu FOSS pour Android inspiré de Little Snitch/OpenSnitch
      Sur macOS, on utilise l’API Network Extension plutôt que des extensions noyau
      Si l’objectif est d’observer le réseau, il existe aussi des sniffers GUI comme Sniffnet

  • Félicitations pour la sortie du port Linux
    Je présente RustNet, une alternative entièrement open source et orientée terminal que je maintiens
    C’est un outil de surveillance de paquets en temps réel en TUI ; ce n’est pas un pare-feu, mais il s’auto-sandboxe via Landlock

    • Ça a l’air intéressant, je l’essaierai plus tard

  • Je me demande comment il se compare à OpenSnitch
    OpenSnitch GitHub

    • J’ai essayé Little Snitch, mais il ne faisait presque pas de résolution IP → domaine, et l’identification des processus échouait aussi
      Cela vient de limitations techniques de la version Linux
      Comme il est basé sur eBPF, si le cache déborde, la correspondance des processus devient impossible, et il ne peut pas faire de deep packet inspection comme sur macOS
      C’est expliqué en détail dans la documentation officielle
    • J’ai aussi installé OpenSnitch, mais je le laisse désactivé en ce moment. Probablement à cause de la fatigue que ça générait
    • D’après le blog du développeur, les outils existants n’offraient pas la possibilité de « voir d’un coup d’œil les connexions par processus et les bloquer en un clic », donc il l’a créé lui-même
      Billet associé
    • OpenSnitch est entièrement open source et sans abonnement. C’est ainsi que les logiciels devraient être faits

  • J’utilise OpenSnitch avec satisfaction
    Cela dit, ce serait bien qu’il ait un système de plugins pour analyser ensemble le comportement utilisateur et les connexions réseau, puis n’afficher en notification que les connexions inattendues
    Un wrapper d’auto-autorisation en CLI, au lieu de pop-ups, serait aussi pratique