Configura un firewall per Discourse

Documentazione Self-Hosting
,
1

It’s unclear if Linux distributions really “need” a firewall – but we have found that the following Uncomplicated Firewall rules work fine with a standard Docker based Discourse install:

ufw allow http
ufw allow https
ufw allow ssh
ufw enable

That is, allow HTTP (port 80), HTTPS (port 443), and SSH (port 22), and nothing else.

Check the current status of your firewall with

ufw status verbose

Sample output:

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)

And if you ever want to turn it off

ufw disable

A firewall should not matter if you are using a default Docker install of Discourse, for the same reason almost no Linux distribution ships with a firewall enabled by default.

But if you have somehow installed extra services that talk to the outside world, adding a firewall gives you “belt and suspenders” security, if that is of interest to you.

33 Mi Piace
4

Per quanto ne so, il container Docker ha pochissime porte aperte verso il sistema host, quindi Discourse è effettivamente protetto da firewall dal server su cui è in esecuzione.

Naturalmente, se ci sono altre cose in esecuzione sul sistema host, il Capitano Ovvio dice che è necessario prendere precauzioni ragionevoli.

Ho avuto un server che pensavamo fosse piuttosto ben bloccato che è stato violato, non è stato bello.

1 Mi Piace
5

L’argomento non è del tutto accurato. Se UFW viene utilizzato al di fuori di docker, come “normalmente” su un VPS, non si applica di per sé a Discourse. Posso disabilitare la porta 80 ed è ancora ampiamente aperta a Discourse/docker.

Certo, protegge tutto il resto, ma se non ci sono altri servizi in ascolto è inutile.

Non so come funzionano UFW o iptables se usati dopo enter app o se il firewall può funzionare in quel modo.

Mi riferisco a questo argomento:

3 Mi Piace
6

Sarei decisamente interessato a sentire questa storia, magari in un thread separato :slight_smile:

A titolo informativo, le discussioni sulla relazione tra Docker e ufw / firewall sono vecchie quanto Docker stesso, ecco una discussione di alto profilo con molti spunti interessanti

Gli stessi Docker sono migliorati negli ultimi anni per quanto riguarda la documentazione dei dettagli pertinenti; Packet filtering and firewalls | Docker Docs

Non voglio inondare troppo il topic con link, ma se siete interessati all’argomento firewall, questi sembrano articoli davvero illuminanti da consultare, insieme a una ricerca generale su Google per maggiori dettagli.

Basandomi su alcuni di questi commenti, e sul thread super utile collegato da @Jagster, sembra che forse la configurazione predefinita dell’installazione Discourse “out-of-the-box” con Docker sia sufficiente da sola? Dopotutto, la mia appare così;

$ 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

Quindi, a meno che non mi sbagli, e a meno che non ci siano altre porte utilizzate da altri software sul server, penso che l’unico traffico che dovrebbe connettersi in entrata sarebbe su queste porte elencate 80 e 443

Se vuoi fare un controllo di sanità, penso che dovresti essere in grado di usare netstat per controllare le porte in ascolto sul tuo server (How to Install netstat on Ubuntu ; https://linuxize.com/post/check-listening-ports-linux/)

netstat -tunlp

Per un controllo di sanità ancora più forte, potresti considerare di avviare un secondo piccolo server Linux e provare a scansionare le porte aperte del tuo server Discourse; How To Use Nmap to Scan for Open Ports | DigitalOcean

# scansiona tutte le porte ; inserisci qui il tuo indirizzo IP
sudo nmap -n -PN -sT -sU -p- 1.2.3.4
  • controlla il link incluso alla documentazione di DigitalOcean per altri comandi per la scansione, ecc.

Penso che se si è preoccupati per il firewall del server per il proprio server Discourse, queste risorse e spunti dovrebbero essere super utili :slight_smile:

3 Mi Piace
7

Piccola cosa, ma questo link sembra non funzionare più.

1 Mi Piace
8

L’ultima versione LTS di Ubuntu ufw fornisce ALLOW e non ALLOW IN.

Questo è stato fastidioso per l’amministratore di mail-reciever, che ha ricevuto “API preparation failed” in ./launcher logs mail-receiver anche con la porta 25 aperta su ufw.

Permettere tutte le connessioni in entrata e in uscita e poi negare le porte desiderate è stata una soluzione.

Non ne so abbastanza di iptables per ottimizzare ulteriormente per ora.