OpenSnitch, pare-feu applicatif interactif pour GNU/Linux

 (github.com/evilsocket)
3 points par GN⁺ 2024-08-11 | 1 commentaires | Partager sur WhatsApp
  • OpenSnitch est un pare-feu applicatif pour GNU/Linux, axé sur le filtrage interactif des connexions sortantes des applications
  • Il peut bloquer à l’échelle du système les domaines de publicité, de suivi et de malware, et permet aussi de configurer depuis l’interface graphique un pare-feu système basé sur nftables
  • L’interface graphique prend en charge la configuration de règles système comme la définition des politiques d’entrée ou l’autorisation de services entrants, et permet de gérer plusieurs nœuds de façon centralisée
  • L’installation consiste à télécharger les paquets deb/rpm puis à les installer avec apt ou dnf, avant d’exécuter opensnitch-ui ou d’ouvrir l’interface graphique depuis le menu des applications
  • Il propose un espace de discussion Show and tell pour partager des cas où des connexions inattendues ont été interceptées, ainsi qu’une intégration SIEM utile pour surveiller les connexions en environnement d’exploitation

Ce que fait OpenSnitch

Fonctions de pare-feu et gestion des nœuds

  • L’interface graphique permet de configurer les paramètres du pare-feu système
    • configuration basée sur nftables
    • possibilité de définir les politiques d’entrée, d’autoriser des services entrants, etc.
  • Il est possible de gérer plusieurs nœuds depuis une interface graphique centrale
  • Il prend en charge l’intégration SIEM

Téléchargement et installation

  • Les paquets deb/rpm peuvent être téléchargés depuis GitHub Releases
  • Installation du paquet deb :
    • sudo apt install ./opensnitch*.deb ./python3-opensnitch-ui*.deb
  • Installation du paquet rpm :
    • sudo dnf install opensnitch*.rpm
  • Après l’installation, exécuter opensnitch-ui ou lancer l’interface graphique depuis le menu des applications
  • Pour plus d’informations sur l’installation, consulter la documentation

Cas d’usage et participation

Informations sur le projet

À lire aussi

1 commentaires

 
GN⁺ 2024-08-11
Avis sur Hacker News

  • J’ai souvent essayé d’utiliser OpenSnitch comme pare-feu interactif, mais il y a un problème dont je ne sais même pas s’il est soluble, sans que ce soit vraiment la faute d’OpenSnitch
    Par exemple, si l’on exécute curl dans un terminal, il faut décider à chaque fois de l’autoriser ou l’ajouter définitivement à la liste blanche
    Mais si l’on autorise des outils génériques comme curl ou wget, un malware présent sur une machine compromise peut aussi les utiliser pour accéder à Internet sans alerte du pare-feu, ce qui ouvre grand la porte

    • Avec des wildcards de sous-domaines ou des sous-réseaux, on constitue assez vite un jeu de règles stable, puis il suffit ensuite de vérifier de temps en temps les demandes vers de nouveaux endpoints
      Le fait d’être rassuré parce qu’un nouvel accès déclenche une demande d’autorisation vaut bien la gêne initiale, et une fois l’habitude prise, la gestion devient assez simple
      J’utilise aussi souvent les règles avec expiration. Par exemple, si je fais confiance à un installateur et que je veux le laisser agir librement pendant un court moment, j’ouvre pour l’exécutable une règle qui expire dans un avenir proche. Les options sont permanent, jusqu’au redémarrage, les 30 prochaines secondes, les 5 prochaines minutes, etc. Cela simplifie beaucoup les tâches qui touchent de nombreux endpoints, sans laisser de trou permanent
    • Il semble aussi possible d’autoriser tout le trafic curl/wget pour l’utilisateur dev, tout en continuant à le détecter pour l’utilisateur normal
      Les tâches de développement s’exécuteraient par exemple avec su -c curl … dev
      Si un programme malveillant tourne dans l’espace utilisateur normal, le pare-feu applicatif devrait correctement détecter son usage de curl et wget
      Comme saisir le mot de passe à chaque fois est pénible, on peut aussi configurer PAM avec une YubiKey ou une authentification biométrique, et cet utilisateur ne devrait pas pouvoir se connecter ni avoir de mot de passe
    • Ça me paraît un peu étrange. Si c’est vraiment une inquiétude, on peut aussi renommer curl ou wget
      Sur mobile, j’utilise un pare-feu au niveau applicatif, mais je ne mets pas les noms de programmes en liste blanche : j’autorise un programme précis à accéder à un domaine/adresse IP précis
      D’après mon expérience, le moyen le plus simple d’empêcher les communications externes d’un programme ou d’un malware est de bloquer l’accès DNS. Je fais ça depuis des décennies et ça fonctionne toujours parfaitement. « 99 % » des programmes/malwares qui communiquent vers l’extérieur s’appuient sur le DNS plutôt que sur des IP codées en dur
      Les rares programmes/malwares qui n’ont pas besoin de DNS sont eux aussi faciles à détecter, et côté DNS je n’autorise que certains domaines. Aujourd’hui, je n’utilise même plus de fichier de zone local contenant les adresses IP nécessaires : un proxy de transfert gère la correspondance domaine→IP. La liste blanche lue par le proxy ressemble à un fichier de zone, mais c’est un fichier texte plus simple
    • Je me demande si on ne pourrait pas le configurer pour laisser passer curl si la commande parente est une commande de confiance, par exemple un bash/zsh possédé par l’utilisateur, et le bloquer sinon. Cela dit, ça a l’air assez fastidieux
    • Ce genre de problème peut se résoudre. Certains gros EDR qui fonctionnent de manière similaire permettent de déclarer les relations parent/enfant des exécutables à bloquer
      Par exemple, si curl est lancé et qu’en remontant la liste des parents on trouve un processus /usr/bin/trusted, on devrait pouvoir déclarer que cet appel à curl est autorisé. Ainsi, tant que le parent du script bash est /usr/bin/trusted, l’exécution de curl depuis ce script peut être autorisée

  • C’est finalement ce qui m’a fait passer à NixOS
    Quand j’utilisais auparavant un pare-feu applicatif, il fallait beaucoup de configuration, les mises à jour cassaient souvent les règles en changeant les chemins, et à chaque nouveau PC il fallait tout refaire, ce qui entraînait beaucoup de churn et de gaspillage
    L’intégration avec le gestionnaire de paquets a supprimé ces problèmes. Une fois la configuration initiale de la liste blanche terminée, il suffit d’un peu de travail quand on ajoute un nouveau paquet à la configuration nix
    Si ajouter la liste blanche à la configuration nix est trop pénible, on peut mettre une autorisation temporaire qui ne dure que jusqu’au prochain redémarrage. La courbe d’apprentissage a été raide et il y a eu beaucoup de travail, mais maintenant la maintenance est très simple

    • Je me demande si cela a été implémenté avec les options Nix d’OpenSnitch présentes sur search.nixos.org/options

  • C’est pratique pour repérer les applications bâclées qui créent un nombre excessif de connexions. Thunderbird, c’est de toi que je parle
    J’aime bien, mais il y a aussi quelques petits désagréments. Les règles temporaires expirées ne sont pas supprimées ou affichées comme telles dans l’interface, donc il faut parfois redémarrer le GUI pour les faire disparaître

    • Je n’aime pas dire ça comme ça, mais je pense qu’une PR serait clairement bienvenue. Cela dit, moi non plus je n’ai presque pas de temps

  • Sur Fedora, je peux recommander ça plutôt que de bricoler avec firewalld/firewall-config

  • J’aimerais avoir ce genre de fonctionnalité quand je fais tourner des API ou des services web dans des conteneurs Docker
    containerA : autoriser tout le trafic sortant
    containerB : bloquer le trafic sortant, sauf lorsqu’il répond à un client
    containerC : accès uniquement à updates.example.com
    Est-ce simplement des iptables par conteneur ? On peut sans doute greffer iptables dans des images existantes, mais ça a l’air de représenter beaucoup de travail. Ou bien est-ce quelque chose qu’on gère avec iptables côté hôte ?

    • Je voudrais ajouter que netfilter, c’est-à-dire ce qu’iptables utilise comme frontend, est un sous-système du noyau, donc il s’applique globalement à tous les conteneurs de l’hôte

  • Est-ce qu’il existe quelque chose comme ça pour les téléphones Android ? Je serais curieux d’avoir de bonnes recommandations

    • Il y a NetGuard. Cela dit, la plupart des fonctions de confort sont derrière un petit paiement
      https://netguard.me
    • GrapheneOS permet au moins de bloquer le trafic Internet d’une application précise. En revanche, pas par plage de ports ni par domaine précis
    • Malheureusement, les vrais pare-feu nécessitent tous les droits root
      J’ai longtemps utilisé AFWall+ ; le contrôle par application pour autoriser ou bloquer le Wi-Fi, le cellulaire et le LAN est propre. Comme c’est un frontend iptables/nftables, on peut personnaliser les règles autant qu’on veut : https://github.com/ukanth/afwall
      Il fonctionne depuis Android 2+
      Sans root, il ne reste que les solutions de type VPN comme Adguard
      Si vous avez besoin de statistiques, il existe aussi une version Android de GlassWire. Je n’ai utilisé que la bêta, donc je ne sais pas où ça en est aujourd’hui, mais ça vaut le coup de vérifier
    • L’app "Rethink: DNS + Firewall + VPN" propose des fonctionnalités similaires
    • AFWall+
      Je suis passé de NetGuard, mentionné plus haut, à celui-ci

  • Ce serait bien d’avoir aussi des paquets pour Arch et OpenSUSE

    • Il existe un paquet officiel pour Arch Linux. Mais, pour une raison quelconque, le module eBPF n’est pas inclus, il faut donc le récupérer séparément depuis l’AUR
    • Il y a opensnitch dans le dépôt extra d’Arch, et opensnitch-ebpf-module dans l’AUR

  • Comment cela se compare-t-il à quelque chose comme UFW ? Je me demande si l’essentiel est l’interface qui montre l’activité en cours

    • OpenSnitch vous demande quoi faire lorsqu’une activité réseau apparaît
      Si une application quelconque fait un appel de télémétrie, par exemple, on peut définir finement une liste blanche/grise : autoriser seulement la connexion de cet exécutable vers cette adresse, toujours autoriser cette adresse, etc., avec aussi des durées comme une seule fois, pendant 15 secondes, jusqu’au redémarrage
      Une fois passée la barrière initiale qui consiste à mettre en liste blanche les applications que l’on utilise et auxquelles on fait confiance, c’est plutôt bien, et cela montre très bien des choses que l’on ignorait sur ce que font les apps ou les jeux
    • À ma connaissance, UFW n’est pas un pare-feu applicatif : il ne fait que bloquer/autoriser des numéros de ports à l’échelle du système

  • Y a-t-il un projet de portage vers macOS ? J’ai utilisé Little Snitch pendant un temps, mais je préfère l’open source pour des raisons qui n’ont rien à voir avec le paiement

    • Tu peux essayer LuLu

  • J’ai essayé de l’utiliser plusieurs fois par intermittence, mais il y avait tellement de plantages aléatoires que c’était assez difficile à utiliser