Chiudete queste porte prima che il vostro team acceda a Mattermost

Una nuova installazione di Mattermost è fatta per far parlare un team in cinque minuti, quindi alcune impostazioni meritano una decisione prima che il primo utente reale acceda. Questa è la checklist che percorriamo prima che un solo utente reale faccia login, con le impostazioni per nome e un modo per dimostrare ciascuna dall'esterno.

Il primo account è quello pericoloso

Su un nuovo server Mattermost, la prima persona che crea un account diventa amministratore di sistema. Se il server è raggiungibile da internet prima che vi siate registrati voi, chiunque lo trovi per primo può prenderselo. Gli scanner trovano i nuovi certificati TLS entro pochi minuti dall'emissione, perché i log di certificate transparency sono pubblici e c'è chi li osserva.

L'ordine quindi conta: portate su il server su un indirizzo privato o dietro una allow list, create voi l'account amministratore, e solo dopo apritelo alle persone che ne hanno bisogno.

Subito dopo, chiudete la registrazione aperta. In config.json o con mmctl:

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

Con l'open server disattivato, le nuove persone arrivano solo con un invito o perché un amministratore crea il loro account. Limitare la creazione al vostro dominio di posta è una seconda serratura nel caso in cui un link di invito viaggi più lontano del previsto.

Decidete cosa esce dall'edificio in una notifica push

Le notifiche push sui dispositivi mobili sono l'impostazione che quasi nessuno guarda. Quando arriva un messaggio per un telefono, Mattermost passa una notifica a un push proxy, che la inoltra al servizio di notifica della piattaforma del telefono. Con l'impostazione di contenuto predefinita, il testo del messaggio viaggia insieme.

Per i team che trattano informazioni riservate, cambiatela:

mmctl --local config set EmailSettings.PushNotificationContents generic_no_channel

generic_no_channel invia «hai un nuovo messaggio» e nient'altro. Nelle edizioni che lo supportano, id_loaded è ancora meglio: la notifica porta solo un ID del messaggio, e il telefono recupera il contenuto dal vostro server via TLS. Lo stesso ragionamento vale per le notifiche email: se il vostro relay di posta è fuori dal vostro controllo, impostate le notifiche email al minimo.

Sessioni, MFA e la lunga coda della fiducia

Poche impostazioni decidono per quanto tempo un laptop rubato o una password sottratta con il phishing restano utili:

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'obbligo di MFA dipende dalla vostra edizione; abilitarla è disponibile ovunque ed è il minimo. Scegliete durate di sessione che i vostri utenti tollereranno, ma sceglietele deliberatamente. Bot e integrazioni devono usare personal access token su account bot dedicati, non la password di una persona, così l'MFA sulle persone non rompe mai un'integrazione.

Chiudete le porte laterali

La maggior parte delle compromissioni non passa dalla pagina di login. Passa da funzionalità che nessuno usa:

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

I link pubblici ai file permettono a chiunque abbia un URL di scaricare un allegato senza accedere. L'upload dei plugin permette a qualsiasi account amministratore, compreso uno compromesso, di eseguire codice arbitrario sul server; installate i plugin dal file system come una modifica, non dal browser. Le connessioni in uscita insicure consentono a webhook e anteprime dei link di accettare certificati non validi. Il rate limiting dà all'API una certa resistenza al password spraying.

Controllate anche ServiceSettings.AllowCorsFrom. Deve essere vuoto a meno che non abbiate una specifica web app che ne ha bisogno, e in quel caso deve indicare esattamente quell'origine, mai un wildcard.

mmctl --local parla con il server attraverso un socket Unix sulla macchina stessa e richiede ServiceSettings.EnableLocalMode impostato a true. Tenete la local mode attiva per l'amministrazione dal server, e tenete stretto l'accesso shell a quel server, perché la local mode salta l'autenticazione per progetto.

Decidete chi può raggiungerlo

Una chat di team viene usata da un gruppo noto di persone da un insieme noto di luoghi. Internet nel suo insieme non ha bisogno di raggiungerla. Le opzioni, dalla più alla meno aperta:

• Pubblica, dietro un firewall che scarta le reti che i vostri log di scansione indicano come fonti di abuso.
• Pubblica, limitata ai paesi da cui il vostro team lavora davvero.
• Raggiungibile solo attraverso la vostra VPN o dagli indirizzi dei vostri uffici.
• Solo su una rete privata.

I filtri per paese e per provider stanno sul firewall, non in Mattermost, così il traffico indesiderato non raggiunge mai l'applicazione. Se siete dietro un reverse proxy, impostate ServiceSettings.TrustedProxyIPHeader in modo che Mattermost registri e limiti il vero indirizzo del client invece di quello del vostro proxy.

Dimostratelo dall'esterno

Un'impostazione che avete cambiato è un'ipotesi. Un test dall'esterno della vostra rete è un'evidenza. Da una macchina che non è sulla vostra rete né nella 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>'

Se filtrate per paese o provider, provate da qualche posto diverso: una macchina in un paese consentito, una in un paese bloccato, una nell'intervallo di un cloud provider. Fatelo dopo ogni modifica alla policy, non una volta sola all'installazione. Le regole firewall derivano, e una regola sbagliata nella direzione aperta non fa suonare alcun allarme.

Poi mettete i valori importanti sotto monitoraggio. Un job notturno che legge mmctl config get per le chiavi qui sopra e le confronta con i valori che avete scelto vi dirà il giorno in cui qualcuno clicca l'interruttore sbagliato nella System Console.

Gli aggiornamenti fanno parte dell'hardening

Prima di aggiornare, verificate che i vostri plugin supportino la release di destinazione. Tenete gli aggiornamenti sulla linea di release che avevate previsto: un «upgrade to latest» da un pacchetto o da un tag di container può spostarvi su un ramo diverso da quello pianificato.

La checklist breve

• Amministratore creato prima che il server sia raggiungibile.
• Open server disattivato, creazione limitata al vostro dominio.
• Contenuto delle notifiche push ridotto a generico o al solo ID.
• MFA abilitata, obbligatoria dove la vostra edizione lo consente, durate di sessione ragionevoli.
• Link pubblici, upload dei plugin e connessioni in uscita insicure disattivati; rate limiting attivo.
• Esposizione di rete scelta di proposito e applicata sul firewall.
• Ogni impostazione dimostrata dall'esterno, e tenuta d'occhio contro la deriva.

Gestiamo Mattermost in questo modo per i nostri clienti, su istanze dedicate nei nostri datacenter. Se desiderate un secondo paio di occhi sulla vostra, siamo lieti di aiutarvi.

Parla con un ingegnere

Related

Correlati: Managed team chat su Mattermost · Managed Request Tracker con partner bridges · Managed source control su GitLab