Configurer un pare-feu pour Discourse

Documentation Auto-hébergement
,
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 « J'aime »
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.