Ir al contenido principal

Bloquear tráfico saliente a un usuario sin privilegios con UFW

Introducción 

En este artículo vamos a explicar cómo bloquear el tráfico saliente a un usuario concreto de nuestro sistema Ubuntu. Para ello tocaremos la configuración del UFW. 

UFW, son las siglas de Uncomplicated Firewall, es un cortafuegos diseñado para Ubuntu con la sencillez de uso en su concepción. Sin embargo, para temas más complicados, la interfaz gráfica que provee no es la mejor opción para implementarlos.

Para el desarrollo de este artículo asumiremos que hay un usuario en el sistema con privilegios de administrador y que llamaremos admin. Además tenemos uno o varios usuarios que no tienen privilegios de administrador. A efectos didácticos llamaremos a uno de ellos no_admin

Hay acciones que se pueden realizar con la interfaz gráfica. Aunque me centraré más en los comandos de la terminal, indicaré cuando es posible realizar una acción usando la interfaz gráfica.

Todas las operaciones hay que realizarlas con el usuario admin.

Habilitar el firewall 

En la distribución de Ubuntu, por defecto, el cortafuegos viene deshabilitado. Para habilitar el UFW se solicitarán las credenciales de un usuario con privilegios de Administración. Se puede habilitar de una de estas maneras:

  • Utilizando la interfaz gráfica: cambiar el botón correspondiente al Estado de tal modo que quede en 1.
  • En la línea de comandos: ejecutaríamos la siguiente orden:

sudo ufw enable

Denegar el tráfico saliente a todo el mundo

Debemos evitar que haya tráfico saliente ya que vamos a establecer políticas restrictivas. Por defecto, el UFW permite cualquier tráfico saliente. Cambiaremos esto:

  • Utilizando la interfaz gráfica: en la lista desplegable correspondiente a Saliente seleccionaríamos Denegar.
  • En la línea de comandos:

sudo ufw default deny OUTPUT

Permitir las conexiones entrantes que necesitemos

Una vez habilitado el cortafuegos se aplicarán las políticas definidas en él. Por defecto, el tráfico entrante está Denegado por lo que no se podrán hacer conexiones al ordenador. En mi caso, por cuestiones de administración de los equipos necesito tener habilitado el acceso por SSH. Como ejemplo describiré cómo permitir ese acceso:

  • Utilizando la interfaz gráfica: podemos ver en la imagen de la interfaz que está al principio del artículo que hay tres botones justo debajo de la lista desplegable Saliente. Seleccionamos el botón correspondiente a las Reglas. Se nos abrirá un cuadro de diálogo para crear una regla nueva en el cortafuegos.

Vemos que existen 3 pestañas: Preconfigurada, Simple y Avanzada. Para el SSH lo mejor es hacerlo en la pestaña preconfigurada pues nos provee de una selección de los servicios más comunes, entre ellos el SSH. En la figura se puede ver qué hay que seleccionar para este servicio. Para añadirla al cortafuegos basta con dar al botón de Añadir.
Conviene echar  un vistazo a todas las reglas preconfiguradas disponibles, sin añadirlas si no hace realmente falta, para hacerse una idea de lo que se puede configurar en nuestro cortafuegos. 
  • En la línea de comandos:

        sudo ufw allow 22

El puerto 22 es el que utiliza el SSH.

Si se quiere lo mismo para, por ejemplo, NoMachine o cualquier servicio que se desee hay que buscar los puertos en los que escucha la aplicación (NoMachine usa el 4000). Si ya se está ejecutando el servicio que queremos añadir podemos abrir una terminal y escribir:

netstat -anp |less

Se listarán todas las conexiones de red. Buscaremos entre ellas la que nos interese. Una vez que conozcamos el puerto repetimos la operación igual que como lo hicimos para SSH.

Configuración de las reglas para regular el tráfico saliente

En esta fase ya tenemos el cortafuegos configurado para que no permita ninguna conexión saliente. A continuación, debemos configurarlo para que permita la salida al tráfico del usuario admin y quede bloqueado todo el tráfico saliente para el usuario no_admin, exceptuando una dirección en concreto.

Para conseguirlo, en una terminal, editaremos el fichero /etc/ufw/before.rules. A este fichero añadimos las siguientes líneas:

# Permitimos conexiones establecidas
-A ufw-before-output -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

# Permitir acceso a todo el tráfico del usuario admin
-A ufw-before-output -m owner --uid-owner admin -d 0.0.0.0/0 -j ACCEPT

# Permitimos a no_admin el trafico hacia la red local (en este ejemplo

192.168.1.0/24)

-A ufw-before-output -m owner --uid-owner no_admin -d 192.168.1.0/24 -j ACCEPT

# Permitimos a no_admin sólo el trafico hacia una dirección en concreto (por ejemplo, el DNS de Google)
-A ufw-before-output -m owner --uid-owner no_admin -d 8.8.8.8 -j ACCEPT

 Reiniciamos el servicio del firewall y ya estaría listo:

sudo service ufw restart

Conclusión

Con esta configuración hemos conseguido limitar el tráfico de un usuario sin privilegios (no_admin) a sólo la red local y al DNS de Google. Mientras el el usuario con privilegios (admin) sigue gozando de todo el acceso a Internet y red local. Si se desea que el usuario no_admin pueda acceder a otras direcciones se pueden ir añadiendo líneas que lo permitan por cada una de ellas o especificando redes concretas.

Esto es útil cuando en un ordenador de trabajo se quiere limitar el acceso al trabajador mientras que los administradores de sistemas sigan conservando pleno acceso a la red local e Internet.

Espero que este artículo les parezca interesante.

Comentarios

Entradas populares de este blog

Atom ha muerto, viva Zed

El día 8 de junio de 2022, Microsoft anunció que a partir del día 31 de diciembre de este mismo año dejaría de dar soporte para el editor de código Atom .  ¿En qué nos afecta esto a nosotros? Bueno, pues si me han seguido en artículos anteriores saben que tras una comparativa de varios IDEs había decidido utilizar Atom para los ejemplos que tuviera que hacer en este blog. Sobre todo los artículos que prepararé para ilustrar el uso de Laravel . Amén de los miles de programadores que actualmente usan Atom  en sus proyectos, claro. Pero, ¿qué editor de código abierto podremos utilizar para sustituir a Atom ? En el mismo comunicado, Microsoft explicaba que el abandono del proyecto Atom  se debía a que querían volcar todos sus esfuerzos en el Visual Studio Code y, por supuesto, recomendó a los usuarios de Atom la utilización del mismo como alternativa natural. No quiero entrar en las bondades o defectos del Visual Studio Code  si quieres elegirlo como tu IDE para d...

Gestión de la red usando la línea de comandos (III): gestión DNS

  Introducción En este nuevo artículo de la serie vamos a hablar de la gestión del DNS, Domain Name System. El sistema de resolución de nombres nos permite traducir los nombres de los dominios de Internet en direcciones IP númericas. Más difíciles de recordar para los humanos.  El DNS fue concebido a mediados de los años 80. Hasta esa época, los ordenadores conectados a una red disponían de una dirección numérica, la dirección IP. Pero con el tiempo, cada vez había más ordenadores conectados a las redes. Esto hacía que cada vez fuera más difícil recordar las direcciones IP. Sobre el año 1983, Paul Mockapetris , un informático estadounidense, desarrolló un sistema jerárquico de nombres para identificar a los ordenadores conectados a una red. Y, a mediados de la década, ya se convirtió en un estándar. Pueden consultar más información sobre el sistema DNS consultando el artículo de la Wikipedia: Sistema de nombres de dominio . En este artículo, no vamos a explicar como montar un ...

Gestión de la red usando la línea de comandos (IV): monitorización de conexiones

  Introducción En este artículo de la serie de gestión de la red usando la línea de comandos nos vamos a centrar en la monitorización de las conexiones. Para ello vamos a utilizar el comando netstat , que es el decano de los comandos de monitorización de la red. También mostraremos el comando ss , que viene a sustituir a netstat  en las funciones de monitorización de conexiones de red. Asimismo mostraré una breve explicación de los conceptos que se van a trabajar en el artículo. S ockets, puertos, protocolos y procesos En primer lugar vamos a empezar con un poco de teoría para alumbrar lo que luego se explicará en el artículo. Si ya sabes de lo que estamos hablando, sáltate esta sección y ve al meollo del asunto [1] . Nos referiremos al contexto de la conexiones TCP/IP. Dentro de este contexto, cada conexión queda definida por dos endpoints , puntos finales, uno en el host , equipo, que establece la conexión y otro en el host con el que se comunica. Generalmente este último es...