Configurer un pare-feu pour Discourse

Documentation Auto-hébergement
,
1

Si vous utilisez une installation standard de Discourse basée sur Docker, les règles suivantes pour Uncomplicated Firewall protégeront tout service non-Docker sur votre serveur :

ufw allow http
ufw allow https
ufw allow ssh
ufw enable

C’est-à-dire, autoriser HTTP (port 80), HTTPS (port 443) et SSH (port 22), et rien d’autre.

:warning: Note : Docker manipule iptables directement et contourne les règles ufw. Cela signifie que ufw ne peut pas bloquer ou restreindre l’accès aux ports exposés par les conteneurs Docker (ports 80 et 443 dans une installation standard de Discourse). Les règles ufw ci-dessus ne protégeront que les services non-Docker s’exécutant sur votre hôte.

Vérifiez l’état actuel de votre pare-feu avec

ufw status verbose

Exemple de sortie :

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)

Et si jamais vous voulez le désactiver

ufw disable

Une installation Docker par défaut de Discourse n’expose que les ports 80 et 443, donc un pare-feu hôte n’est pas strictement nécessaire. Mais si vous avez d’autres services en cours d’exécution sur l’hôte qui écoutent sur des ports supplémentaires, l’ajout d’un pare-feu fournit une couche de sécurité supplémentaire de type « ceinture et bretelles » pour ces services.

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

D’après ce que je comprends, le conteneur Docker a très peu de ports ouverts vers le système hôte, donc Discourse est effectivement protégé par un pare-feu du serveur sur lequel il s’exécute.

Bien sûr, s’il y a d’autres choses qui tournent sur le système hôte, alors le Capitaine Évidence dit qu’il faut prendre des précautions raisonnables.

J’ai eu un serveur que nous pensions assez bien verrouillé se faire pirater, ce n’était pas joli.

1 « J'aime »
5

Le sujet n’est pas totalement exact. Si UFW est utilisé en dehors de Docker, comme “normalement” sur un VPS, il ne s’applique pas en soi à Discourse. Je peux désactiver le port 80 et il est toujours largement ouvert à Discourse/Docker.

Bien sûr, il protège tout le reste, mais s’il n’y a pas d’autres services en écoute, il est inutile.

Je ne sais pas comment UFW ou iptables fonctionne s’ils sont utilisés après enter app ou si le pare-feu peut fonctionner de cette manière.

Je fais référence à ce sujet :

3 « J'aime »
6

J’aimerais vraiment entendre cette histoire, peut-être dans un fil de discussion séparé :slight_smile:

Soit dit en passant, les discussions sur la relation entre Docker et ufw / les pare-feux sont presque aussi anciennes que Docker lui-même, voici une discussion très médiatisée avec beaucoup d’informations intéressantes

Docker eux-mêmes se sont améliorés ces dernières années en ce qui concerne la documentation des détails pertinents ; Packet filtering and firewalls | Docker Docs

Je ne veux pas spammer le sujet avec trop de liens, mais si vous vous intéressez au sujet des pare-feux, ces articles semblent vraiment instructifs à examiner, ainsi qu’une recherche Google générale pour plus de détails.

Sur la base de certains de ces sentiments, et du fil de discussion super utile lié par @Jagster, il semble que la configuration par défaut de l’installation Discourse prête à l’emploi avec Docker soit suffisante en soi ? Après tout, la mienne ressemble à ceci ;

$ 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

Donc, à moins que je ne me trompe, et à moins qu’il n’y ait d’autres ports utilisés par d’autres logiciels sur le serveur, je pense que le seul trafic qui devrait se connecter en entrée serait sur ces ports listés 80 et 443

Si vous voulez faire une vérification de bon sens, je pense que vous devriez pouvoir utiliser netstat pour vérifier les ports d’écoute sur votre serveur ( How to Install netstat on Ubuntu ; https://linuxize.com/post/check-listening-ports-linux/ )

netstat -tunlp

Pour une vérification de bon sens encore plus solide, vous pourriez envisager de lancer un deuxième petit serveur Linux et d’essayer de scanner les ports ouverts de votre serveur Discourse ; How To Use Nmap to Scan for Open Ports | DigitalOcean

# scanner tous les ports ; insérez votre adresse IP ici
sudo nmap -n -PN -sT -sU -p- 1.2.3.4
  • consultez le lien inclus vers la documentation DigitalOcean pour d’autres commandes de scan, etc.

Je pense que si l’on s’inquiète des pare-feux serveur pour son serveur Discourse, ces ressources et ces informations devraient être très utiles :slight_smile:

3 « J'aime »
7

Petite chose, mais ce lien semble mort.

1 « J'aime »
8

La dernière version LTS d’Ubuntu ufw donne ALLOW et non ALLOW IN.

Cela a été ennuyeux pour l’administrateur de mail-reciever, qui a rencontré des erreurs de préparation de l’API dans ./launcher logs mail-receiver même avec le port 25 ouvert sur ufw.

Autoriser toutes les connexions entrantes et sortantes puis refuser les ports souhaités a été une solution.

Je n’en sais pas assez sur iptables pour affiner davantage pour le moment.