OpenSnitch, firewall interactivo de aplicaciones para GNU/Linux

 (github.com/evilsocket)
3 puntos por GN⁺ 2024-08-11 | 1 comentarios | Compartir por WhatsApp
  • OpenSnitch es un firewall de aplicaciones para GNU/Linux, enfocado en filtrar de forma interactiva las conexiones externas de las aplicaciones
  • Puede bloquear dominios de publicidad, rastreadores y malware en todo el sistema, y también permite configurar desde la GUI un firewall del sistema basado en nftables
  • La GUI admite la configuración de reglas del sistema como políticas de entrada y permisos para servicios entrantes, y permite administrar varios nodos de forma centralizada
  • La instalación se realiza descargando paquetes deb/rpm e instalándolos con apt o dnf; luego se ejecuta opensnitch-ui o se abre la GUI desde el menú de aplicaciones
  • Ofrece un espacio de discusión Show and tell para compartir casos en los que intercepta conexiones inesperadas, así como integración con SIEM para monitorear conexiones en entornos operativos

Qué hace OpenSnitch

Funciones de firewall y administración de nodos

  • Desde la GUI se puede configurar el firewall del sistema
    • Maneja configuraciones basadas en nftables
    • Permite definir políticas de entrada y autorizar servicios entrantes, entre otras opciones
  • Desde una GUI central se pueden administrar varios nodos
  • Admite integración con SIEM

Descarga e instalación

  • Los paquetes deb/rpm pueden descargarse desde GitHub Releases
  • Instalación del paquete deb:
    • sudo apt install ./opensnitch*.deb ./python3-opensnitch-ui*.deb
  • Instalación del paquete rpm:
    • sudo dnf install opensnitch*.rpm
  • Después de instalar, ejecuta opensnitch-ui o inicia la GUI desde el menú de aplicaciones
  • Para información detallada de instalación, consulta la documentación

Casos de uso y participación

Información del proyecto

Lecturas relacionadas

1 comentarios

 
GN⁺ 2024-08-11
Opiniones en Hacker News

  • Intenté usar bastante OpenSnitch como firewall interactivo, pero hay un problema que no sé siquiera si se puede resolver, y no es tanto culpa de OpenSnitch.
    Por ejemplo, si ejecuto curl desde la terminal, cada vez tengo que decidir si permitirlo o ponerlo permanentemente en la lista de permitidos.
    Pero si permites herramientas de uso general como curl o wget, el malware en una máquina comprometida también puede usarlas para salir a Internet sin alertas del firewall, así que dejas la puerta totalmente abierta.

    • Si usas comodines de subdominios o subredes, se acumula bastante rápido un conjunto estable de reglas, y después solo tienes que revisar de vez en cuando las solicitudes a nuevos endpoints.
      La tranquilidad de que te pregunte si permitir un nuevo acceso hace que la molestia inicial valga la pena, y cuando te acostumbras también es bastante fácil de administrar.
      También uso mucho reglas con vencimiento. Por ejemplo, si confías en un instalador y quieres dejarlo actuar libremente por un rato, abres una regla para el ejecutable que vence en un futuro cercano. Las opciones son permanente, hasta el reinicio, los próximos 30 segundos, los próximos 5 minutos, etc.; incluso tareas con muchos endpoints se vuelven mucho más simples y no dejan agujeros permanentes.
    • Parece que también se podría permitir todo el tráfico de curl/wget para el usuario dev y seguir detectándolo para el usuario normal.
      El trabajo de desarrollo se ejecutaría con algo como su -c curl … dev.
      Si un programa malicioso se está ejecutando en el espacio del usuario normal, el firewall de aplicaciones podría detectar adecuadamente el uso de curl y wget.
      Como es molesto ingresar la contraseña cada vez, también podrías configurar PAM con YubiKey o autenticación biométrica, y ese usuario debería no poder iniciar sesión ni tener contraseña.
    • Eso suena un poco raro. Si realmente te preocupa, también podrías cambiarles el nombre a curl o wget.
      En móvil uso un firewall a nivel de aplicación, pero no pongo el nombre del programa en una lista de permitidos, sino que permito que un programa específico acceda a determinados dominios/direcciones IP.
      Por experiencia, la forma más fácil de bloquear las comunicaciones externas de programas o malware es bloquear el acceso a DNS. Lo he hecho así durante décadas y todavía funciona perfectamente. El “99%” de los programas/malware que se comunican con el exterior dependen de DNS, no de IPs hardcodeadas.
      Los raros programas/malware que no necesitan DNS también son fáciles de detectar, y en DNS solo permito dominios específicos. Hoy en día ni siquiera uso un archivo de zona local con las direcciones IP necesarias; un proxy de reenvío se encarga del mapeo dominio→IP. La lista de permitidos que lee el proxy es parecida a un archivo de zona, pero es un archivo de texto más simple.
    • Creo que se podría configurar para dejar pasar curl si el comando padre es un comando de confianza, por ejemplo bash/zsh propiedad del usuario, y bloquearlo si no. Aunque sí parece bastante engorroso.
    • Ese problema se puede resolver. Algunos EDR grandes que funcionan de forma parecida permiten declarar relaciones padre/hijo de los ejecutables que se van a bloquear.
      Por ejemplo, si se ejecutó curl y al subir por la lista de procesos padre se encuentra un proceso /usr/bin/trusted, deberías poder declarar que esa invocación de curl se permita. Así, mientras el padre del script de bash sea /usr/bin/trusted, se podría permitir que ese script ejecute curl.

  • Esto fue, al final, lo que me llevó a pasarme a NixOS.
    Antes, cuando usaba un firewall de aplicaciones, tenía mucha configuración; se rompía seguido cuando las actualizaciones cambiaban rutas, y al mudarme a una computadora nueva tenía que rehacerlo todo, con mucho churn y desperdicio.
    Al integrarlo con el gestor de paquetes, esos problemas desaparecieron. Una vez hecha la configuración inicial de la lista de permitidos, solo hay que hacer un poco de trabajo al agregar un paquete nuevo a la configuración de nix.
    Si da pereza agregar la lista de permitidos a la configuración de nix, puedes poner una lista de permitidos temporal que dure solo hasta el próximo reinicio. La curva de aprendizaje fue empinada y hubo mucho trabajo, pero ahora el mantenimiento es muy fácil.

    • Me da curiosidad si lo implementaste con las opciones de Nix para OpenSnitch que están en search.nixos.org/options.

  • Es bueno para detectar apps flojas que abren demasiadas conexiones. Thunderbird, hablo de ti.
    Me gusta, pero también tiene pequeñas molestias. Las reglas temporales vencidas no se eliminan ni dejan de mostrarse en la interfaz, así que a veces hay que reiniciar la GUI para limpiarlas.

    • No quiero ser esa persona, pero seguro que un PR sería bienvenido. Claro, yo tampoco tengo casi tiempo.

  • En Fedora, podría recomendar esto antes que ponerse a trastear con firewalld/firewall-config.

  • Me gustaría tener algo así al correr APIs o servicios web en contenedores Docker.
    containerA: permitir todo el tráfico saliente
    containerB: bloquear el tráfico saliente salvo cuando responde a clientes
    containerC: solo puede acceder a updates.example.com
    ¿Esto es simplemente iptables por contenedor? Supongo que se podría meter iptables en imágenes existentes, pero parece mucho trabajo. ¿O se manejaría con iptables en el host?

    • Solo quiero agregar que netfilter, es decir, lo que iptables usa como frontend, es un subsistema del kernel, así que se aplica globalmente a todos los contenedores del host.

  • ¿Hay algo así para teléfonos Android? Me interesan buenas recomendaciones.

    • Está NetGuard. Aunque la mayoría de las funciones de comodidad están detrás de pequeños pagos.
      https://netguard.me
    • GrapheneOS al menos permite bloquear el tráfico de Internet de apps específicas. Pero no por rango de puertos ni por dominio específico.
    • Lamentablemente, todos los firewalls de verdad requieren permisos de root.
      Usé AFWall+ durante mucho tiempo; tiene un control limpio para permitir o bloquear Wi‑Fi, datos móviles y LAN por app. Como es un frontend de iptables/nftables, puedes personalizar las reglas todo lo que quieras: https://github.com/ukanth/afwall
      Funciona desde Android 2+.
      Sin root, solo quedan soluciones tipo VPN como Adguard.
      Si necesitas estadísticas, también existe la versión Android de GlassWire. Solo probé la beta, así que no sé en qué estado está ahora, pero vale la pena revisarla.
    • La app "Rethink: DNS + Firewall + VPN" tiene funciones parecidas.
    • AFWall+
      Me cambié a eso desde NetGuard, que mencionaron arriba.

  • Estaría bueno que también hubiera paquetes para Arch y OpenSUSE.

    • Arch Linux tiene un paquete oficial. Aunque, por alguna razón, no incluye el módulo eBPF, así que hay que obtenerlo por separado desde AUR.
    • En el repositorio extra de Arch está opensnitch, y en AUR está opensnitch-ebpf-module.

  • ¿Cómo se compara con algo como UFW? Me pregunto si el punto central es la UI para ver la actividad en curso.

    • OpenSnitch te pregunta cuando aparece actividad de red.
      Si una app cualquiera hace algo como una llamada de telemetría, puedes definir una whitelist/greylist con granularidad, por ejemplo permitir solo la conexión de este ejecutable a esta dirección, permitir siempre esta dirección, etc., y también elegir la duración: una sola vez, durante 15 segundos, hasta el reinicio, etc.
      Una vez que superas la barrera inicial de poner en la lista de permitidos las apps que usas y en las que confías, está bastante bien, y muestra muy bien cosas que no sabías que estaban haciendo tus apps o juegos.
    • Hasta donde sé, UFW no es un firewall de aplicaciones, sino que solo bloquea/permite números de puerto para todo el sistema.

  • ¿Habrá planes de portarlo a macOS? Usé Little Snitch por un tiempo, pero por razones no relacionadas con el pago prefiero algo open source.

    • Prueba LuLu.

  • Varias veces intenté usarlo de forma intermitente, pero tenía demasiados crashes aleatorios, así que era bastante difícil de usar.