Comment Discourse peut-il contourner UFW ? J’avais activé uniquement le port 22, donc tous les autres ports devraient être fermés. Mais un forum fonctionnait quand même. Comment est-ce possible ?
Gouttelette DigitalOcean, mais cela ne devrait rien signifier. Et aucune installation en un clic, mais la méthode officielle.
Ce n’est pas une question de support pur, mais nous n’avons pas ici de catégorie nommée Questions basiques stupides par des débutants 
Donc si vous ufw status verbose, vous ne voyez que le sshd ?
C’est exact. Et UFW était activé.
Qu’est-ce qui était indiqué par défaut lorsque vous avez exécuté ufw status verbose ?
Pour ce que je pense que vous voulez, je m’attendrais à voir ceci :
Défaut : refuser (entrant), autoriser (sortant), désactivé (acheminé)
Avec le comportement que vous décrivez, je m’attendrais à voir ceci :
Défaut : autoriser (entrant), autoriser (sortant), désactivé (acheminé)
Avez-vous essayé d’ouvrir le forum dans une fenêtre de navigation privée ou un navigateur différent ? Il est facile de se laisser tromper par la version mise en cache qui s’affiche. Je me suis moi-même laissé tromper et un autre développeur m’a dit que le site de staging avait l’air bien alors qu’il ne fonctionnait pas du tout.
Juste 22/tcp (OpenSSH) ALLOW IN Anywhere comme il se doit. Ce sont les deux choses que je fais toujours : autoriser OpenSSH et activer UFW.
J’ouvre les ports uniquement si nécessaire, par exemple lorsque j’installerai Nginx. Mais comme ce VPS était uniquement pour Discourse, je n’ai rien fait d’autre - j’ai totalement oublié UFW.
Cela ne peut pas être le cas. Ce forum était actif depuis des semaines.
Je me suis réveillé face à cette situation lorsque j’ai connecté Nginx/Varnish à ce VPS et que j’avais besoin d’un autre port ouvert - et j’ai réalisé que le seul port ouvert était le port 22.
Modifier :
Comment pourrais-je envoyer des e-mails ? Le port 587 n’était pas ouvert non plus 
C’est vraiment étrange.
Je ne suis pas sûr si vous dites que la valeur par défaut est définie sur refuser ou non. La raison pour laquelle je pose des questions sur la ligne « Default » spécifiquement est qu’il est possible d’avoir à la fois une valeur par défaut d’autorisation et de définir un port spécifique à autoriser, bien que ce dernier ne change rien dans cet arrangement.
Si quelqu’un d’autre a configuré Discourse, est-il possible que cette personne ait modifié la valeur par défaut pour autoriser au lieu d’autoriser les ports HTTP/HTTPS ?
Je suppose qu’il s’agit de SMTP quelque part ailleurs, votre serveur Discourse se connectant à ce serveur SMTP en utilisant le port 587. Les connexions sortantes sont autorisées sur tous les ports par défaut, donc UFW ne gênera pas l’envoi d’e-mails à moins que vous ne changiez explicitement la politique sortante.
Mes excuses 
Par défaut : refuser (entrant), autoriser (sortant), refuser (acheminé)
Non. Mais est-ce que autoriser (sortant) autorise quoi que ce soit en sortie ? Si oui, alors nous revenons à « nous n’avons pas ici de catégorie nommée Questions basiques stupides par des débutants » et j’ai appris de nouvelles choses.
Modifier :
Je suis toujours perdu — mais qu’en est-il de refuser (entrant) ?
J’ai trouvé ceci :
La réponse courte est que Discourse ne peut pas contourner vos règles de pare-feu et que l’endroit pour poser des questions stupides sur les choses du système d’exploitation est quelque part comme Stack Exchange. (S’il vous plaît, ne me trouvez pas impoli. C’est là que se trouvent ces réponses. Après avoir utilisé Linux depuis les premières versions, je vais toujours dans des endroits comme celui-ci pour toutes mes questions stupides. J’en ai toujours !).
Je connais l’endroit Il y a un rapport signal/bruit beaucoup trop élevé. Bon, c’était une caractérisation injuste, mais je voulais dire qu’il est vraiment difficile d’y trouver des choses pertinentes. C’est tellement massif.
C’est en fait une très bonne question et je suis surpris que personne d’autre ne l’ait encore posée. La réponse est compliquée, mais jusqu’à présent, les réponses sur ce sujet ont malheureusement été dédaigneuses sans répondre à la question.
Ce n’est pas que Discourse contourne ufw, mais docker contourne ufw en ajoutant des règles qui font fonctionner les ports exposés des conteneurs docker malgré la présence de ufw.
Les paquets entrants destinés à un conteneur atteignent la table FORWARD, pas la table INPUT comme on pourrait s’y attendre.
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
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
La raison pour laquelle les paquets atteignent la table forward est due aux règles que docker ajoute à la table nat :
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 est traité avant que la décision ne soit prise quant à l’envoi des paquets via INPUT ou FORWARD.
En fin de compte, le problème est qu’il y a deux services sur le système qui modifient les règles du pare-feu. ufw n’est au courant de rien de tout cela, il ne peut donc signaler que ce qu’il a configuré.
Pour cela, il faut reconfigurer le pare-feu pour qu’il transmette également le trafic destiné à docker via les chaînes ufw :
J’utilise la légère adaptation de leur travail, mise en place avant d’activer ufw :
# volé sur https://github.com/chaifeng/ufw-docker - semble raisonnable
# ajouter le forward à ufw-user-input permet les connexions aux
# ports forwardés que nous avons explicitement ouverts
cat <<EOUFW >> /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
Merci ! C’était une explication complète.
Bienvenue, c’est comme ça que je fais 
Ce sujet est résolu, mais il a révélé un problème mineur dans ma configuration. Je l’expliquerai si quelqu’un recherche quelque chose de similaire un jour.
J’avais un VPS où Nginx s’occupait du SSL et d’autres choses pour tous mes sites (beaucoup de fautes, l’anglais est une langue très étrange ). Nginx envoie les requêtes à Varnish. C’est un proxy inverse inutile pour Discourse, mais il fait un peu de filtrage. Varnish envoie les requêtes à un autre VPS où réside Discourse en utilisant le port 83. Les deux VPS écoutent le même port et c’est autorisé uniquement pour les deux IP. J’étais totalement satisfait — jusqu’à maintenant.
J’ai essayé ce qui se passe lorsque j’utilisais le port 443 curl -I https://forum.example.tld:443. Cela a bien fonctionné, car j’ai toujours un certificat SSL valide du côté de Discourse (j’ai fait ce changement il y a quelques semaines).
La réponse de @supermathie explique pourquoi cela se produit et comment y remédier. Bien sûr, il n’y a aucun problème de sécurité à cause de cela, à ma connaissance, mais c’est vraiment agaçant 
Wow. C’est dingue ! Merci.
J’imagine que la question n’est pas souvent posée car il n’est pas fréquent que quelqu’un installe discourse et souhaite qu’il ne fonctionne pas. Ainsi, quand docker le fait fonctionner alors que vous avez configuré le pare-feu de telle sorte qu’il ne le devrait pas, la plupart des gens ne se plaignent pas.
C’est un problème très intéressant, mais il semble un peu ésotérique, et ce n’est pas un problème de Discourse, mais une bizarrerie de docker. La question se résume à “comment puis-je configurer mon pare-feu pour empêcher discourse de fonctionner ?” Je vais essayer de me souvenir de ce truc de prerouting.
Si j’avais su la réponse, je n’aurais pas été dédaigneux ! Merci d’avoir sauvé la situation sur ce coup !
Je n’essayais certainement pas d’être dédaigneux, mais plutôt de dépanner… et j’étais manifestement ignorant de ce que Docker faisait. C’est une information très utile, merci d’avoir répondu !
Si l’OP ou quelqu’un d’autre peut le changer, il pourrait être utile de modifier la solution marquée.
Bien que ce soit davantage une affaire de Docker, je peux imaginer certains hypothétismes de Discourse qui en découlent. Par exemple, je pourrais avoir un serveur de bureau accessible depuis l’extérieur, mais je veux configurer UFW pour restreindre Discourse à n’être accessible que depuis l’intérieur du bureau. Les ajouts de Docker empêcheraient cette configuration.
Bien que dans ce scénario particulier, je le configurerais sur un pare-feu matériel/hyperviseur plutôt que sur UFW sur l’hôte de toute façon.
Je viens de tomber sur le même dépôt git que vous, en examinant un problème ufw/docker, cela m’a fait penser à ce sujet.
Qu’avez-vous exactement modifié (je veux dire, je peux voir les lignes ajoutées, mais qu’est-ce que cela signifie ?), et ces modifications sont-elles spécifiques à Discourse ?
J’ai utilisé le code par défaut du dépôt et mon problème UFW semble avoir été résolu après cela.
EDIT : Lorsque j’utilise votre code modifié, au premier moment où j’exécute ufw reload, j’obtiens l’erreur suivante :
ERREUR : Impossible de charger les règles de journalisation
En fait, j’ai trouvé la solution après un moment et j’ai écrit ce script bash pour le faire pour les installations Discourse.
Il réinitialise votre pare-feu, installe ufw-docker-util (qui modifie le fichier after.rules), puis ajoute les ports 443 et 80 à votre liste d’autorisation. Voilà.
Il autorise également le port 22 depuis n’importe quelle IP pour vous assurer de ne pas être bloqué. Une fois que tout fonctionne, sécurisez à nouveau le port 22.
EDIT : le script fonctionne mais la reconstruction de discourse après son utilisation échouera :
fatal: unable to access 'https://github.com/discourse/discourse.git/': Could not resolve host: github.com- n’utilisez donc PAS le script à moins de savoir comment résoudre ce problème.
EDIT 2 : Fonctionne sur Ubuntu, mais pas sur CentOS !
La dernière fois que j’ai fait un script bash, j’ai changé le propriétaire de tous les répertoires en www-data:www-data — donc pour moi, un travail comme celui-ci me facilite la vie
Mais en général — j’aimerais voir Docker suivre totalement UFW/iptables. Juste parce que j’utilise le blocage GeoIP via ipables (oui, je sais — UFW n’est qu’une interface minimaliste pour iptables).
Bien sûr, nous ne sommes plus sur Discourse, mais ici nous pouvons voir pourquoi les codeurs et les utilisateurs finaux ne se comprennent pas toujours si bien : les codeurs voient le monde comme des blocs logiques et des constructions si/alors/sinon, mais les utilisateurs finaux le voient comme un contexte complet. Signification — parce que j’utilise Discourse, même s’il fonctionne dans Docker, de mon point de vue, c’est Discourse qui ne suit pas mes règles 
Cela devrait aller dans Praise, mais j’ai changé l’URL du forum il y a quelques semaines. Et j’ai eu tous les script kiddies du monde et les bots SEO inutiles à visiter. J’ai eu sur un VPS de 2 Go/1 vcpu de DigitalOcean 3000 agents utilisateurs différents par heure et Discourse s’en fichait complètement. N’importe quelle installation WordPress serait lente/en panne après ce type de rush ddos.
Donc, je n’ai pas besoin de forcer Discourse (enfin, Docker) à suivre les interdictions de Fail2ban et mes règles — mais je déteste tellement ces bots.