Configurare un firewall per Discourse

Documentazione Self-Hosting
,
1

Se si sta utilizzando un’installazione standard di Discourse basata su Docker, le seguenti regole di Uncomplicated Firewall proteggeranno qualsiasi servizio non-Docker in esecuzione sul proprio server:

ufw allow http
ufw allow https
ufw allow ssh
ufw enable

Ovvero, consentire HTTP (porta 80), HTTPS (porta 443) e SSH (porta 22), e nient’altro.

:warning: Nota: Docker manipola direttamente iptables e aggira le regole di ufw. Ciò significa che ufw non può bloccare o limitare l’accesso alle porte esposte dai container Docker (porte 80 e 443 in un’installazione standard di Discourse). Le regole ufw sopra riportate proteggeranno solo i servizi non-Docker in esecuzione sull’host.

Controllare lo stato attuale del proprio firewall con

ufw status verbose

Output di esempio:

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)

E se si desidera disattivarlo

ufw disable

Un’installazione predefinita di Discourse con Docker espone solo le porte 80 e 443, quindi un firewall host non è strettamente necessario. Ma se si hanno altri servizi in esecuzione sull’host che ascoltano su porte aggiuntive, l’aggiunta di un firewall fornisce un ulteriore livello di sicurezza “cintura e bretelle” per tali servizi.

33 Mi Piace
:cn: Discourse Official Install Guide | Discourse 云平台安装
How might we better structure #howto?
Mail-receiver relay access denied
I can't start a Discourse
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.