Cierre estas puertas antes de que su equipo entre en Mattermost

Una instalación nueva de Mattermost está hecha para que un equipo empiece a hablar en cinco minutos, así que unos cuantos ajustes merecen una decisión antes de que entre el primer usuario real. Esta es la lista que repasamos antes de que inicie sesión un solo usuario real, con los ajustes por su nombre y una manera de demostrar cada uno desde fuera.

La primera cuenta es la peligrosa

En un servidor Mattermost nuevo, la primera persona que crea una cuenta se convierte en administrador del sistema. Si el servidor es alcanzable desde internet antes de que usted haya entrado, cualquiera que lo encuentre primero puede quedárselo. Los escáneres encuentran los certificados TLS nuevos a los pocos minutos de emitirse, porque los registros de transparencia de certificados son públicos y hay gente vigilándolos.

Así que el orden importa: levante el servidor en una dirección privada o detrás de una lista de permitidos, cree usted mismo la cuenta de administrador, y solo entonces ábralo a las personas que lo necesitan.

Justo después, cierre el registro abierto. En config.json o con mmctl:

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

Con el servidor abierto desactivado, la gente nueva llega solo por invitación o porque un administrador crea su cuenta. Restringir la creación a su propio dominio de correo es un segundo cerrojo por si un enlace de invitación viaja más lejos de lo previsto.

Decida qué sale del edificio en una notificación push

El push móvil es el ajuste que casi nadie mira. Cuando llega un mensaje para un teléfono, Mattermost entrega una notificación a un proxy de push, que la pasa al servicio de notificaciones de la plataforma del teléfono. Con el ajuste de contenido por defecto, el texto del mensaje viaja con ella.

Para equipos con información confidencial, cámbielo:

mmctl --local config set EmailSettings.PushNotificationContents generic_no_channel

generic_no_channel envía «tiene un mensaje nuevo» y nada más. En las ediciones que lo soportan, id_loaded es aún mejor: la notificación lleva solo un ID de mensaje, y el teléfono recupera el contenido de su propio servidor por TLS. El mismo razonamiento vale para las notificaciones por correo: si su relay de correo está fuera de su control, configure las notificaciones por correo para enviar lo mínimo.

Sesiones, MFA y la larga cola de la confianza

Unos pocos ajustes deciden cuánto tiempo sigue siendo útil un portátil robado o una contraseña obtenida por phishing:

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

Forzar la MFA depende de su edición; habilitarla está disponible en todas y es el mínimo. Elija duraciones de sesión que sus usuarios toleren, pero elíjalas deliberadamente. Los bots y las integraciones deberían usar tokens de acceso personal en cuentas de bot dedicadas, no la contraseña de un humano, para que la MFA en los humanos nunca rompa una integración.

Cierre las puertas laterales

La mayoría de los compromisos no entran por la página de inicio de sesión. Entran por funciones que nadie 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

Los enlaces públicos a ficheros permiten a cualquiera con una URL descargar un adjunto sin iniciar sesión. Las subidas de plugins permiten a cualquier cuenta de administrador, incluida una comprometida, ejecutar código arbitrario en el servidor; instale los plugins desde el sistema de ficheros como un cambio, no desde el navegador. Las conexiones salientes inseguras permiten que los webhooks y las previsualizaciones de enlaces acepten certificados malos. La limitación de tasa da a la API cierta resistencia frente al password spraying.

Revise también ServiceSettings.AllowCorsFrom. Debería estar vacío salvo que tenga una aplicación web concreta que lo necesite, y entonces debería nombrar ese origen exactamente, nunca un comodín.

mmctl --local habla con el servidor por un socket Unix en la propia máquina y necesita ServiceSettings.EnableLocalMode a true. Mantenga el modo local activado para administrar desde el servidor, y mantenga bien cerrado el acceso por shell a ese servidor, porque el modo local se salta la autenticación por diseño.

Decida quién puede llegar a él

Un chat de equipo lo usa un grupo conocido de personas desde un conjunto conocido de lugares. Internet en general no necesita alcanzarlo. Opciones, de más a menos abierta:

• Público, detrás de un firewall que descarta las redes que sus logs de escaneo muestran como fuentes de abuso.
• Público, limitado a los países desde los que realmente trabaja su equipo.
• Alcanzable solo por su VPN o desde las direcciones de su oficina.
• Solo en una red privada.

Los filtros por país y proveedor van en el firewall, no en Mattermost, para que el tráfico no deseado nunca llegue a la aplicación. Si está detrás de un proxy inverso, configure ServiceSettings.TrustedProxyIPHeader para que Mattermost registre y limite por la dirección real del cliente en lugar de la de su proxy.

Demuéstrelo desde fuera

Un ajuste que ha cambiado es una hipótesis. Una prueba desde fuera de su red es una evidencia. Desde una máquina que no esté en su red ni en su lista de permitidos:

# 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//public?h='

Si filtra por país o proveedor, pruebe desde varios sitios: una máquina en un país permitido, una en un país bloqueado, una en el rango de un proveedor cloud. Hágalo después de cada cambio en la política, no una vez en la instalación. Las reglas de firewall derivan, y una regla equivocada en la dirección abierta no levanta ninguna alarma.

Después ponga los valores importantes bajo monitorización. Un trabajo nocturno que lea mmctl config get para las claves de arriba y las compare con los valores que eligió le avisará el día en que alguien pulse el interruptor equivocado en la System Console.

Las actualizaciones son parte del bastionado

Antes de actualizar, compruebe que sus plugins soportan la versión de destino. Mantenga las actualizaciones en la línea de versiones que pretendía: un «actualizar a la última» desde un paquete o una etiqueta de contenedor puede moverle a una rama distinta de la que planeó.

La lista breve

• Administrador creado antes de que el servidor sea alcanzable.
• Servidor abierto desactivado, creación restringida a su dominio.
• Contenido de las notificaciones push reducido a genérico o solo ID.
• MFA habilitada, forzada donde su edición lo permita, duraciones de sesión sensatas.
• Enlaces públicos, subidas de plugins y conexiones salientes inseguras desactivados; limitación de tasa activada.
• Exposición de red elegida a propósito y aplicada en el firewall.
• Cada ajuste demostrado desde fuera, y vigilado frente a la deriva.

Así operamos Mattermost para nuestros clientes en instancias dedicadas en nuestros propios datacenters. Si quiere un segundo par de ojos sobre la suya, estaremos encantados de ayudar.

Hable con un ingeniero

Related

Relacionado: Chat de equipo gestionado en Mattermost · Request Tracker gestionado con puentes a partners · Control de versiones gestionado en GitLab