# UFW limiterà anche Discourse?
**URL:** https://meta.discourse.org/t/will-ufw-limit-discourse-too/231873
**Category:** Self-hosting
**Created:** [4 Luglio 2022, 12:08pm UTC](https://meta.discourse.org/t/will-ufw-limit-discourse-too/231873 "2022-07-04T12:08:17Z")
**Posts on this page:** 20
**Page:** 1
### Author:  [@Jagster](https://meta.discourse.org/u/Jagster)
#### Post date: [4 Luglio 2022, 12:08pm UTC](https://meta.discourse.org/t/will-ufw-limit-discourse-too/231873/1 "2022-07-04T12:08:17Z")
Come può Discourse aggirare UFW? Avevo abilitato solo la porta 22, quindi tutte le altre porte dovrebbero essere chiuse. Ma un forum ha funzionato comunque. Come è possibile?
DigitalOcean droplet, ma ciò non dovrebbe significare nulla. E nessuna installazione one-click, ma il modo ufficiale.
Questa non è una pura domanda di supporto, ma qui non abbiamo una categoria chiamata _Domande stupide e basilari dei principianti_ 😉
---
### Author:  [@Stephen](https://meta.discourse.org/u/Stephen)
#### Post date: [4 Luglio 2022, 12:13pm UTC](https://meta.discourse.org/t/will-ufw-limit-discourse-too/231873/2 "2022-07-04T12:13:25Z")
Quindi se `ufw status verbose` vedi solo sshd?
---
### Author:  [@Jagster](https://meta.discourse.org/u/Jagster)
#### Post date: [4 Luglio 2022, 12:15pm UTC](https://meta.discourse.org/t/will-ufw-limit-discourse-too/231873/3 "2022-07-04T12:15:07Z")
Esatto. E UFW era abilitato.
---
### Author:  [@Simon\_Manning](https://meta.discourse.org/u/Simon_Manning)
#### Post date: [4 Luglio 2022, 12:48pm UTC](https://meta.discourse.org/t/will-ufw-limit-discourse-too/231873/4 "2022-07-04T12:48:29Z")
Cosa è stato elencato come predefinito quando hai eseguito `ufw status verbose`?
Per quello che penso tu voglia, mi aspetterei di vedere questo:
`Default: deny (incoming), allow (outgoing), disabled (routed)`
Con il comportamento che stai descrivendo, mi aspetterei di vedere questo:
`Default: allow (incoming), allow (outgoing), disabled (routed)`
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [4 Luglio 2022, 1:03pm UTC](https://meta.discourse.org/t/will-ufw-limit-discourse-too/231873/5 "2022-07-04T13:03:58Z")
Hai provato ad aprire il forum in una finestra di navigazione in incognito o in un browser diverso? È facile essere ingannati dalla versione memorizzata nella cache che viene visualizzata. Mi è successo e un altro sviluppatore mi ha detto che il sito di staging sembrava buono quando in realtà non era affatto in esecuzione.
---
### Author:  [@Jagster](https://meta.discourse.org/u/Jagster)
#### Post date: [4 Luglio 2022, 1:12pm UTC](https://meta.discourse.org/t/will-ufw-limit-discourse-too/231873/6 "2022-07-04T13:12:13Z")
> [@Simon\_Manning](#):
>
> Cosa era elencato come predefinito quando hai eseguito `ufw status verbose`?
Solo `22/tcp (OpenSSH) ALLOW IN Anywhere` come dovrebbe essere. Queste sono le due cose che faccio sempre: consentire OpenSSH e abilitare UFW.
Apro le porte solo se necessario, ad esempio quando installerò Nginx. Ma poiché quel VPS era solo per Discourse non ho fatto altro: ho dimenticato completamente UFW.
> [@pfaffman](#):
>
> È facile essere ingannati dalla versione memorizzata nella cache che compare
Non può essere il caso. Quel forum era attivo da settimane.
Mi sono svegliato a questa situazione quando ho collegato Nginx/Varnish a quel VPS e avevo bisogno di un’altra porta aperta — e mi sono reso conto che solo la porta 22 era aperta.
Modifica:
Come potevo inviare email? Anche la porta 587 non era aperta 😳
È davvero strano.
---
### Author:  [@Simon\_Manning](https://meta.discourse.org/u/Simon_Manning)
#### Post date: [4 Luglio 2022, 1:28pm UTC](https://meta.discourse.org/t/will-ufw-limit-discourse-too/231873/7 "2022-07-04T13:28:27Z")
> [@Jagster](#):
>
> Solo `22/tcp (OpenSSH) ALLOW IN Anywhere` come dovrebbe essere. Queste sono le due cose che faccio sempre: consentire OpenSSH e abilitare UFW.
Non mi è chiaro se stai dicendo che l’impostazione predefinita è negata o meno. Il motivo per cui chiedo specificamente della riga “Default” è perché è possibile avere sia un’impostazione predefinita di consentire sia impostare una porta specifica da consentire, sebbene quest’ultima non cambi nulla in quella disposizione.
Se qualcun altro ha configurato Discourse, è possibile che quella persona abbia modificato l’impostazione predefinita su consentire invece di consentire le porte HTTP/HTTPS?
> [@Jagster](#):
>
> Come potrei inviare email? Anche la porta 587 non era aperta 😳
Presumo che si tratti di SMTP da qualche altra parte, il tuo server Discourse che si connette a quel server SMTP utilizzando la porta 587. Le connessioni in uscita sono consentite su tutte le porte per impostazione predefinita, quindi UFW non ostacolerà l’invio di email a meno che tu non modifichi esplicitamente la policy in uscita.
---
### Author:  [@Jagster](https://meta.discourse.org/u/Jagster)
#### Post date: [4 Luglio 2022, 1:34pm UTC](https://meta.discourse.org/t/will-ufw-limit-discourse-too/231873/8 "2022-07-04T13:34:56Z")
[quote=“Simon Manning, post:7, topic:231873, username:Simon\_Manning”]Il motivo per cui chiedo specificamente della riga “Default”
[/quote]
Colpa mia 🤦♂️
`Default: deny (incoming), allow (outgoing), deny (routed)`
[quote=“Simon Manning, post:7, topic:231873, username:Simon\_Manning”]è possibile che quella persona abbia cambiato il default in allow invece di consentire le porte HTTP/HTTPS?
[/quote]
No. Ma `allow (outgoing)` consente qualcosa in uscita? Se sì, allora siamo tornati a “non abbiamo qui una categoria chiamata _Domande stupide e basilari dei principianti_” e ho imparato cose nuove.
Modifica:
Sono ancora perso, ma come funziona `deny (incoming`)?
---
### Author:  [@Jagster](https://meta.discourse.org/u/Jagster)
#### Post date: [4 Luglio 2022, 1:43pm UTC](https://meta.discourse.org/t/will-ufw-limit-discourse-too/231873/9 "2022-07-04T13:43:24Z")
Ho trovato questo:
>
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [4 Luglio 2022, 1:44pm UTC](https://meta.discourse.org/t/will-ufw-limit-discourse-too/231873/10 "2022-07-04T13:44:18Z")
La risposta breve è che Discourse non può aggirare le regole del tuo firewall e il posto dove fare domande stupide su cose del sistema operativo è da qualche parte come Stack Exchange. (Per favore, non pensare che io sia scortese. È lì che si trovano quelle risposte. Dopo aver usato Linux fin dalle primissime versioni, vado ancora in posti come quello per tutte le mie domande stupide. Ne ho ancora!)
---
### Author:  [@Jagster](https://meta.discourse.org/u/Jagster)
#### Post date: [4 Luglio 2022, 1:47pm UTC](https://meta.discourse.org/t/will-ufw-limit-discourse-too/231873/11 "2022-07-04T13:47:48Z")
> [@pfaffman](#):
>
> qualcosa come stack exchange
Conosco il posto 😉 C’è un rapporto segnale/rumore troppo alto. Beh, quella è stata una caratterizzazione ingiusta, ma intendevo dire che è davvero difficile trovare cose rilevanti da lì. È così massiccio.
---
### Author:  [@supermathie](https://meta.discourse.org/u/supermathie)
#### Post date: [4 Luglio 2022, 5:05pm UTC](https://meta.discourse.org/t/will-ufw-limit-discourse-too/231873/12 "2022-07-04T17:05:10Z")
Questa è in realtà un’ottima domanda e sono sorpreso che nessun altro l’abbia ancora posta. La risposta è complicata, ma finora le risposte su questo argomento sono state purtroppo sbrigative senza rispondere alla domanda.
Non è che _Discourse_ stia aggirando `ufw`, ma _`docker`_ aggira ufw aggiungendo regole che fanno funzionare le porte esposte dei container docker nonostante la presenza di `ufw`.
# Cosa sta succedendo?
I pacchetti in arrivo destinati a un container colpiscono la tabella `FORWARD`, non la tabella `INPUT` come ci si potrebbe aspettare.
## Installazione pre-docker
```plaintext
Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 ufw-before-logging-forward all -- any any anywhere anywhere
0 0 ufw-before-forward all -- any any anywhere anywhere
0 0 ufw-after-forward all -- any any anywhere anywhere
0 0 ufw-after-logging-forward all -- any any anywhere anywhere
0 0 ufw-reject-forward all -- any any anywhere anywhere
0 0 ufw-track-forward all -- any any anywhere anywhere
```
## Installazione post-docker
```plaintext
Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
8 416 DOCKER-USER all -- any any anywhere anywhere
8 416 DOCKER-ISOLATION-STAGE-1 all -- any any anywhere anywhere
0 0 ACCEPT all -- any docker0 anywhere anywhere ctstate RELATED,ESTABLISHED
4 256 DOCKER all -- any docker0 anywhere anywhere
4 160 ACCEPT all -- docker0 !docker0 anywhere anywhere
0 0 ACCEPT all -- docker0 docker0 anywhere anywhere
0 0 ufw-before-logging-forward all -- any any anywhere anywhere
0 0 ufw-before-forward all -- any any anywhere anywhere
0 0 ufw-after-forward all -- any any anywhere anywhere
0 0 ufw-after-logging-forward all -- any any anywhere anywhere
0 0 ufw-reject-forward all -- any any anywhere anywhere
0 0 ufw-track-forward all -- any any anywhere anywhere
```
Il motivo per cui i pacchetti raggiungono la tabella forward è dovuto alle regole che docker aggiunge alla tabella nat:
```plaintext
Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
210 12734 DOCKER all -- any any anywhere anywhere ADDRTYPE match dst-type LOCAL
Chain DOCKER (2 references)
pkts bytes target prot opt in out source destination
0 0 RETURN all -- docker0 any anywhere anywhere
0 0 DNAT tcp -- !docker0 any anywhere anywhere tcp dpt:https to:172.17.0.2:443
107 6848 DNAT tcp -- !docker0 any anywhere anywhere tcp dpt:http to:172.17.0.2:80
```
`nat/PREROUTING` viene elaborato [prima](https://unix.stackexchange.com/a/189906/1259) che venga presa la decisione se inviare i pacchetti tramite `INPUT` o `FORWARD`.
In definitiva, il problema è che ci sono due servizi sul sistema che modificano le regole del firewall. `ufw` non è a conoscenza di nulla di tutto ciò, quindi può solo segnalare ciò che _ha_ configurato.
# Una soluzione
A questo problema è riconfigurare il firewall per far passare anche il traffico destinato a docker attraverso le chain di ufw:
> **[GitHub - chaifeng/ufw-docker: To fix the Docker and UFW security flaw without...](https://github.com/chaifeng/ufw-docker)**
>
> To fix the Docker and UFW security flaw without disabling iptables
Utilizzo la seguente leggera adattamento del loro lavoro, messo in atto prima di abilitare `ufw`:
```plaintext
# rubato da https://github.com/chaifeng/ufw-docker - sembra sensato
# aggiungere il forward a ufw-user-input consente le connessioni a
# porte inoltrate che abbiamo esplicitamente aperto
cat <> /etc/ufw/after.rules
# BEGIN UFW AND DOCKER
*filter
:ufw-user-forward - [0:0]
:ufw-user-input - [0:0]
:DOCKER-USER - [0:0]
-A DOCKER-USER -j RETURN -s 10.0.0.0/8
-A DOCKER-USER -j RETURN -s 172.16.0.0/12
-A DOCKER-USER -j RETURN -s 192.168.0.0/16
-A DOCKER-USER -p udp -m udp --sport 53 --dport 1024:65535 -j RETURN
-A DOCKER-USER -j ufw-user-forward
-A DOCKER-USER -j ufw-user-input
-A DOCKER-USER -j DROP -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -d 10.0.0.0/8
-A DOCKER-USER -j DROP -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -d 172.16.0.0/12
-A DOCKER-USER -j DROP -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -d 192.168.0.0/16
-A DOCKER-USER -j DROP -p udp -m udp --dport 0:32767 -d 10.0.0.0/8
-A DOCKER-USER -j DROP -p udp -m udp --dport 0:32767 -d 172.16.0.0/12
-A DOCKER-USER -j DROP -p udp -m udp --dport 0:32767 -d 192.168.0.0/16
-A DOCKER-USER -j RETURN
COMMIT
# END UFW AND DOCKER
EOUFW
```
---
### Author:  [@Jagster](https://meta.discourse.org/u/Jagster)
#### Post date: [4 Luglio 2022, 6:24pm UTC](https://meta.discourse.org/t/will-ufw-limit-discourse-too/231873/13 "2022-07-04T18:24:58Z")
Grazie! È stata una spiegazione completa.
---
### Author:  [@supermathie](https://meta.discourse.org/u/supermathie)
#### Post date: [4 Luglio 2022, 6:25pm UTC](https://meta.discourse.org/t/will-ufw-limit-discourse-too/231873/14 "2022-07-04T18:25:29Z")
Benvenuto, è così che faccio 😃
---
### Author:  [@Jagster](https://meta.discourse.org/u/Jagster)
#### Post date: [4 Luglio 2022, 8:04pm UTC](https://meta.discourse.org/t/will-ufw-limit-discourse-too/231873/15 "2022-07-04T20:04:22Z")
Questo argomento è risolto, ma ha rivelato un piccolo problema nella mia configurazione. Lo spiegherò se qualcuno cercherà qualcosa di simile in futuro.
Avevo un VPS dove Nginx si occupava di SSL e di altre cose di tutti i miei siti (molti errori, l’inglese è una lingua molto strana 😉 ). Nginx invia richieste a Varnish. È un reverse proxy inutile per Discourse, ma esegue alcuni filtri. Varnish invia richieste a un altro VPS dove risiede Discourse usando la porta 83. Entrambi i VPS ascoltano la stessa porta e è consentito solo a entrambi gli IP. Ero totalmente felice, fino ad ora.
Ho provato cosa succede quando ho usato la porta 443 `curl -I https://forum.example.tld:443`. Ha funzionato bene, perché ho ancora un certificato SSL valido sul lato di Discourse (ho fatto questa modifica alcune settimane fa).
La risposta di @supermathie spiega perché succede e come risolverlo. Certo, non ci sono problemi di sicurezza a causa di ciò, per quanto ne so, ma è davvero fastidioso 😝
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [5 Luglio 2022, 9:08pm UTC](https://meta.discourse.org/t/will-ufw-limit-discourse-too/231873/16 "2022-07-05T21:08:59Z")
> [@supermathie](#):
>
> Non è che _Discourse_ stia aggirando `ufw`, ma è _`docker`_ che aggira ufw aggiungendo regole che fanno funzionare le porte esposte dei container docker nonostante la presenza di `ufw`.
Wow. Questa è roba pazzesca! Grazie
Immagino che non venga chiesto perché non capita spesso che qualcuno installi discourse e voglia che **non** funzioni, quindi quando docker lo fa funzionare quando hai configurato il firewall in modo che non dovrebbe, la maggior parte delle persone non si lamenta. 😉
È un problema molto interessante, ma sembra un po’ esoterico, e non è un problema di Discourse, ma una stranezza di docker. La domanda si riduce a “come posso configurare il mio firewall per impedire il funzionamento di discourse?” Cercherò di ricordarmi quella roba del prerouting.
> [@supermathie](#):
>
> finora le risposte su questo argomento sono state purtroppo sprezzanti nel tono senza rispondere alla domanda.
Se avessi saputo la risposta non sarei stato sprezzante! 😉 grazie per aver salvato la situazione in questo caso!
---
### Author:  [@Simon\_Manning](https://meta.discourse.org/u/Simon_Manning)
#### Post date: [6 Luglio 2022, 7:53am UTC](https://meta.discourse.org/t/will-ufw-limit-discourse-too/231873/17 "2022-07-06T07:53:46Z")
> [@supermathie](#):
>
> La risposta è complicata, ma finora le risposte su questo argomento sono state purtroppo sprezzanti nel tono senza rispondere alla domanda.
Non stavo certo cercando di essere sprezzante, ma piuttosto di risolvere i problemi… anche se evidentemente partivo da una posizione di ignoranza su ciò che Docker stava facendo. Tutte informazioni molto utili, grazie per aver risposto!
Se l’OP o qualcun altro può cambiarlo, potrebbe valere la pena cambiare la soluzione contrassegnata.
> [@pfaffman](#):
>
> È un problema molto interessante, ma sembra un po’ esoterico e non è un problema di Discourse, ma una stranezza di Docker. La domanda si riduce a “come posso configurare il mio firewall per impedire il funzionamento di Discourse?”
Anche se è più una cosa di Docker, posso vedere alcuni ipotetici scenari di Discourse che derivano da questo. Ad esempio, potrei avere un server d’ufficio raggiungibile dal mondo esterno, ma voglio configurare UFW per limitare l’accesso a Discourse solo dall’interno dell’ufficio. Le aggiunte di Docker impedirebbero tale configurazione.
Anche se in quello scenario particolare lo configurerei su un firewall hardware/hypervisor piuttosto che su UFW sull’host.
---
### Author:  [@MarcP](https://meta.discourse.org/u/MarcP)
#### Post date: [10 Luglio 2022, 9:45pm UTC](https://meta.discourse.org/t/will-ufw-limit-discourse-too/231873/18 "2022-07-10T21:45:56Z")
Sono appena arrivato allo stesso repository git che hai trovato, sto esaminando un problema ufw/docker, mi ha fatto pensare a questo argomento.
Cosa hai cambiato esattamente (intendo, posso vedere le righe aggiunte, ma cosa significa?) e queste modifiche sono specifiche per Discourse?
Ho usato il codice predefinito nel repository e il mio problema UFW sembrava risolto dopo.
MODIFICA: Quando uso il tuo codice modificato, al primo momento in cui eseguo `ufw reload` ricevo il seguente errore:
ERRORE: Impossibile caricare le regole di logging
---
### Author:  [@MarcP](https://meta.discourse.org/u/MarcP)
#### Post date: [11 Luglio 2022, 3:34am UTC](https://meta.discourse.org/t/will-ufw-limit-discourse-too/231873/19 "2022-07-11T03:34:11Z")
In realtà, l’ho capito dopo un po’ e ho scritto questo script bash per farlo per le installazioni di Discourse.
Ripristina il tuo firewall, installa [ufw-docker-util](https://github.com/chaifeng/ufw-docker#ufw-docker-util) (che modifica le regole after.rules), quindi aggiunge le porte 443 e 80 alla tua whitelist. Fatto.
Consente anche la porta 22 da qualsiasi IP per assicurarsi di non rimanere bloccato fuori. Dopo che tutto funziona, proteggi nuovamente la porta 22.
> **[auto-docker-ufw/discourse at main · MarcRez33/auto-docker-ufw](https://github.com/MarcRez33/auto-docker-ufw/tree/main/discourse)**
>
> Contribute to MarcRez33/auto-docker-ufw development by creating an account on GitHub.
> EDIT: lo script funziona ma la ricostruzione di Discourse dopo averlo utilizzato fallirà: `fatal: unable to access 'https://github.com/discourse/discourse.git/': Could not resolve host: github.com` - quindi NON usare lo script a meno che tu non sappia come risolvere questo problema.
> EDIT 2: Funziona su Ubuntu, ma non su CentOS!
---
### Author:  [@Jagster](https://meta.discourse.org/u/Jagster)
#### Post date: [11 Luglio 2022, 7:03am UTC](https://meta.discourse.org/t/will-ufw-limit-discourse-too/231873/20 "2022-07-11T07:03:25Z")
L’ultima volta che ho scritto uno script in bash, ho cambiato il proprietario di tutte le directory in www-data:www-data: quindi, per me, un lavoro come questo rende la vita un po’ più facile 😉
Ma in generale — vorrei vedere Docker seguire completamente UFW/iptables. Solo perché uso il blocco GeoIP tramite iptables (sì, lo so: UFW è solo un’interfaccia minimale per iptables).
Certo, non siamo più su Discourse, ma qui possiamo vedere perché programmatori e utenti finali non riescono sempre a capirsi così bene: i programmatori vedono il mondo come blocchi logici e costrutti if/then/else, mentre gli utenti finali lo vedono come un contesto completo. Cioè — dato che uso Discourse, anche se funziona dentro Docker, dal mio punto di vista è Discourse che non segue le mie regole 🤣
Questo dovrebbe finire in #Community Building > Praise, ma ho cambiato l’URL del forum alcune settimane fa. E ho attirato tutti i script kiddie del mondo e i bot SEO inutili. Ho ricevuto 3000 user agent diversi all’ora sul mio VPS da DigitalOcean da 2 GB/1 vCPU e a Discourse non fregava niente. Qualsiasi installazione WordPress sarebbe stata lenta/inaccessible dopo una simile raffica simile a un DDoS.
Quindi, non ho _bisogno_ di forzare Discourse (beh, Docker) a seguire i ban di Fail2ban e le mie regole — ma odio profondamente quei bot.
[Pagina seguente](https://meta.discourse.org/t/will-ufw-limit-discourse-too/231873.md?page=2)