Configurar un firewall para Discourse

Documentación Autoalojamiento
,
1

Si está utilizando una instalación estándar de Discourse basada en Docker, las siguientes reglas del Uncomplicated Firewall protegerán cualquier servicio que no sea de Docker en su servidor:

ufw allow http
ufw allow https
ufw allow ssh
ufw enable

Es decir, permitir HTTP (puerto 80), HTTPS (puerto 443) y SSH (puerto 22), y nada más.

:warning: Nota: Docker manipula iptables directamente y omite las reglas de ufw. Esto significa que ufw no puede bloquear o restringir el acceso a los puertos expuestos por los contenedores Docker (puertos 80 y 443 en una instalación estándar de Discourse). Las reglas de ufw anteriores solo protegerán los servicios que no son de Docker que se ejecutan en su host.

Verifique el estado actual de su cortafuegos con

ufw status verbose

Salida de ejemplo:

Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip

To                         Action      From
--                         ------      ----
80                         ALLOW IN    Anywhere
443                        ALLOW IN    Anywhere
22                         ALLOW IN    Anywhere
80 (v6)                    ALLOW IN    Anywhere (v6)
443 (v6)                   ALLOW IN    Anywhere (v6)
22 (v6)                    ALLOW IN    Anywhere (v6)

Y si alguna vez desea desactivarlo

ufw disable

Una instalación predeterminada de Discourse con Docker solo expone los puertos 80 y 443, por lo que un cortafuegos de host no es estrictamente necesario. Pero si tiene otros servicios ejecutándose en el host que escuchan en puertos adicionales, agregar un cortafuegos proporciona una capa adicional de seguridad de “cinturón y tirantes” para esos servicios.

33 Me gusta
:cn: Discourse Official Install Guide | Discourse 云平台安装
How might we better structure #howto?
Mail-receiver relay access denied
I can't start a Discourse
4

Según entiendo, el contenedor de Docker tiene muy pocos puertos abiertos al sistema host, por lo que Discourse está efectivamente aislado por un firewall del servidor en el que se está ejecutando.

Por supuesto, si hay otras cosas ejecutándose en el sistema host, el Capitán Obvio dice que se deben tomar precauciones razonables.

He tenido un servidor que creíamos bastante bien asegurado y fue hackeado, no fue bonito.

1 me gusta
5

El tema no es totalmente preciso. Si UFW se usa fuera de docker, como “normalmente” en un VPS, no se aplica en sí mismo con Discourse. Puedo deshabilitar el puerto 80 y todavía está completamente abierto a Discourse/docker.

Claro, protege todo lo demás, pero si no hay otros servicios escuchando, es innecesario.

No sé cómo funcionan UFW o iptables si se usan después de enter app o si el firewall puede usarse de esa manera.

Me refiero a este tema:

3 Me gusta
6

Definitivamente estaría interesado en escuchar esta historia, ¿quizás en un hilo separado? :slight_smile:

A título informativo, las discusiones sobre la relación entre Docker y ufw / firewalls son casi tan antiguas como el propio Docker, aquí hay una bastante importante con mucha información interesante:

Los propios de Docker han mejorado en los últimos años en cuanto a la documentación de los detalles relevantes; Packet filtering and firewalls | Docker Docs

No quiero saturar demasiado el tema con enlaces, pero si estás interesado en el tema de los firewalls, estas parecen ser piezas realmente reveladoras para revisar, junto con una búsqueda general en Google para obtener más detalles.

Basándome en algunos de estos comentarios, y en el hilo súper útil enlazado por @Jagster, ¿parece que la configuración predeterminada de instalación de Discourse lista para usar con Docker es suficiente por sí sola? Después de todo, la mía se ve así;

$ docker ps
CONTAINER ID   IMAGE                 COMMAND        CREATED      STATUS        PORTS                                                                      NAMES
5dd4a572cd8e   local_discourse/app   \"/sbin/boot\"   6 days ago   Up 16 hours   0.0.0.0:80-\u003e80/tcp, :::80-\u003e80/tcp, 0.0.0.0:443-\u003e443/tcp, :::443-\u003e443/tcp   app

Así que, a menos que me equivoque, y a menos que haya algún otro puerto en uso por otro software en el servidor, creo que el único tráfico que debería conectarse entrante sería en estos puertos listados 80 y 443.

Si quieres hacer una comprobación de cordura, creo que deberías poder usar netstat para comprobar los puertos de escucha en tu servidor ( How to Install netstat on Ubuntu ; https://linuxize.com/post/check-listening-ports-linux/ )

netstat -tunlp

Para una comprobación de cordura aún más sólida, podrías considerar iniciar un segundo servidor Linux pequeño e intentar escanear los puertos abiertos de tu servidor Discourse; How To Use Nmap to Scan for Open Ports | DigitalOcean

# escanear todos los puertos ; inserta tu dirección IP aquí
sudo nmap -n -PN -sT -sU -p- 1.2.3.4
  • consulta el enlace incluido a la documentación de DigitalOcean para ver más comandos para escanear, etc.

Creo que si uno está preocupado por la seguridad del firewall del servidor para su servidor Discourse, estos recursos e información deberían ser de gran ayuda :slight_smile:

3 Me gusta
7

Algo pequeño, pero este enlace parece estar roto.

1 me gusta
8

La última versión LTS de Ubuntu ufw da ALLOW, no ALLOW IN.

Esto ha sido molesto para el administrador de mail-reciever, recibiendo “API preparation failed” en ./launcher logs mail-receiver incluso con el puerto 25 abierto en ufw.

Permitir todas las entradas y salidas y luego denegar los puertos deseados ha sido una solución.

Todavía no sé lo suficiente sobre iptables para ajustar más.