Fermez ces portes avant que votre équipe ne se connecte à Mattermost

Une installation Mattermost toute neuve est conçue pour faire discuter une équipe en cinq minutes, donc quelques réglages méritent une décision avant que le premier vrai utilisateur ne se connecte. Voici la liste de contrôle que nous parcourons avant qu'un seul vrai utilisateur ne se connecte, avec les réglages par leur nom et une façon de prouver chacun depuis l'extérieur.

Le premier compte est le compte dangereux

Sur un nouveau serveur Mattermost, la première personne qui crée un compte devient administrateur système. Si le serveur est joignable depuis internet avant que vous ne vous soyez connecté, quiconque le trouve en premier peut le prendre. Les scanners trouvent les nouveaux certificats TLS dans les minutes qui suivent leur émission, parce que les journaux de certificate transparency sont publics et que des gens les surveillent.

L'ordre compte donc : montez le serveur sur une adresse privée ou derrière une allow-list, créez vous-même le compte administrateur, et seulement ensuite ouvrez-le aux personnes qui en ont besoin.

Juste après, fermez l'inscription ouverte. Dans config.json ou avec mmctl :

mmctl --local config set TeamSettings.EnableOpenServer false
mmctl --local config set TeamSettings.RestrictCreationToDomains "example.com"

Avec l'open server désactivé, les nouvelles personnes n'arrivent que par invitation ou par création de leur compte par un administrateur. Restreindre la création à votre propre domaine de messagerie est un second verrou au cas où un lien d'invitation voyagerait plus loin que prévu.

Décidez ce qui sort du bâtiment dans une notification push

Le push mobile est le réglage que la plupart des gens ne regardent jamais. Quand un message arrive pour un téléphone, Mattermost remet une notification à un push proxy, qui la transmet au service de notification de la plateforme du téléphone. Avec le réglage de contenu par défaut, le texte du message voyage avec.

Pour les équipes confidentielles, changez-le :

mmctl --local config set EmailSettings.PushNotificationContents generic_no_channel

generic_no_channel envoie « vous avez un nouveau message » et rien de plus. Sur les éditions qui le prennent en charge, id_loaded est encore mieux : la notification ne porte qu'un identifiant de message, et le téléphone récupère le contenu depuis votre propre serveur en TLS. La même logique s'applique aux notifications par e-mail : si votre relais de messagerie échappe à votre contrôle, réglez les notifications e-mail pour envoyer le minimum.

Sessions, MFA et la longue traîne de la confiance

Quelques réglages décident combien de temps un ordinateur portable volé ou un mot de passe hameçonné reste utile :

mmctl --local config set ServiceSettings.EnableMultifactorAuthentication true
mmctl --local config set ServiceSettings.EnforceMultifactorAuthentication true
mmctl --local config set ServiceSettings.SessionLengthWebInHours 168
mmctl --local config set ServiceSettings.SessionLengthMobileInHours 720
mmctl --local config set ServiceSettings.SessionIdleTimeoutInMinutes 480

L'imposition du MFA dépend de votre édition. Son activation est disponible partout et constitue le minimum. Choisissez des durées de session que vos utilisateurs toléreront, mais choisissez-les délibérément. Les bots et les intégrations doivent utiliser des personal access tokens sur des comptes de bot dédiés, pas le mot de passe d'un humain, pour que le MFA sur les humains ne casse jamais une intégration.

Fermez les portes latérales

La plupart des compromissions ne passent pas par la page de connexion. Elles passent par des fonctionnalités que personne n'utilise :

mmctl --local config set FileSettings.EnablePublicLink false
mmctl --local config set PluginSettings.EnableUploads false
mmctl --local config set ServiceSettings.EnableInsecureOutgoingConnections false
mmctl --local config set RateLimitSettings.Enable true

Les liens de fichiers publics permettent à quiconque dispose d'une URL de récupérer une pièce jointe sans se connecter. Les téléversements de plugins permettent à tout compte administrateur, y compris un compte compromis, d'exécuter du code arbitraire sur le serveur. Installez les plugins depuis le système de fichiers, comme un changement, pas depuis le navigateur. Les connexions sortantes non sécurisées permettent aux webhooks et aux aperçus de liens d'accepter de mauvais certificats. Le rate limiting donne à l'API une certaine résistance au password spraying.

Vérifiez aussi ServiceSettings.AllowCorsFrom. Il doit être vide sauf si vous avez une application web précise qui en a besoin, et alors il doit nommer exactement cette origine, jamais un joker.

mmctl --local parle au serveur par un socket Unix sur la machine elle-même et a besoin de ServiceSettings.EnableLocalMode à true. Gardez le mode local actif pour l'administration depuis le serveur, et gardez l'accès shell à ce serveur strict, parce que le mode local saute l'authentification par conception.

Décidez qui peut l'atteindre tout court

Un team chat est utilisé par un groupe connu de personnes depuis un ensemble connu de lieux. Internet dans son ensemble n'a pas besoin de l'atteindre. Les options, de la plus ouverte à la moins ouverte :

1. Public, derrière un firewall qui rejette les réseaux que vos journaux de scan désignent comme sources d'abus.
2. Public, limité aux pays depuis lesquels votre équipe travaille réellement.
3. Joignable uniquement par votre VPN ou depuis les adresses de vos bureaux.
4. Sur un réseau privé seulement.

Les filtres par pays et par fournisseur ont leur place au firewall, pas dans Mattermost, pour que le trafic indésirable n'atteigne jamais l'application. Si vous êtes derrière un reverse proxy, réglez ServiceSettings.TrustedProxyIPHeader pour que Mattermost journalise et limite la vraie adresse du client plutôt que celle de votre proxy.

Prouvez-le depuis l'extérieur

Un réglage que vous avez changé est une hypothèse. Un test depuis l'extérieur de votre réseau est une preuve. Depuis une machine qui n'est ni sur votre réseau ni dans votre allow-list :

# What does the logged-out client see?
curl -s 'https://chat.example.com/api/v4/config/client?format=old' \
  | jq '{EnableOpenServer, EnableSignUpWithEmail, EnableMultifactorAuthentication}'

# Is plain HTTP redirected?
curl -sI http://chat.example.com/ | head -n 3

# Does a public file link work without a session? (use a link created before you disabled them)
curl -s -o /dev/null -w '%{http_code}\n' 'https://chat.example.com/files/<id>/public?h=<hash>'

Si vous filtrez par pays ou par fournisseur, testez depuis quelques endroits : une machine dans un pays autorisé, une dans un pays bloqué, une dans la plage d'adresses d'un fournisseur cloud. Faites-le après chaque changement de politique, pas une seule fois à l'installation. Les règles de firewall dérivent, et une règle fausse dans le sens de l'ouverture ne lève aucune alarme.

Mettez ensuite les valeurs importantes sous supervision. Un job nocturne qui lit mmctl config get pour les clés ci-dessus et les compare aux valeurs que vous avez choisies vous dira le jour où quelqu'un cliquera sur le mauvais interrupteur dans la System Console.

Les mises à niveau font partie du durcissement

Avant de mettre à niveau, vérifiez que vos plugins prennent en charge la version cible. Gardez les mises à niveau sur la ligne de version que vous visiez : un « upgrade to latest » depuis un paquet ou un tag de conteneur peut vous déplacer sur une branche différente de celle que vous aviez prévue.

La courte liste de contrôle

• Administrateur créé avant que le serveur ne soit joignable.
• Open server désactivé, création restreinte à votre domaine.
• Contenu des notifications push réduit au générique ou à l'identifiant seul.
• MFA activé, imposé là où votre édition le permet, durées de session raisonnables.
• Liens publics, téléversements de plugins et connexions sortantes non sécurisées désactivés. Rate limiting activé.
• Exposition réseau choisie délibérément et imposée au firewall.
• Chaque réglage prouvé depuis l'extérieur, et surveillé contre la dérive.

Nous exploitons Mattermost ainsi pour nos clients sur des instances dédiées dans nos propres datacenters. Si vous souhaitez un second regard sur la vôtre, nous vous aiderons volontiers.

Parler à un ingénieur

Related

Voir aussi : Managed team chat sur Mattermost · Managed Request Tracker avec partner bridges · Gestion de sources infogérée sur GitLab