Закрийте ці двері, перш ніж ваша команда зайде в Mattermost

Свіжа інсталяція Mattermost створена так, щоб команда почала спілкуватися за п’ять хвилин, тож кілька налаштувань заслуговують на рішення до того, як увійде перший справжній користувач. Це чекліст, який ми проходимо до того, як зайде бодай один справжній користувач, з назвами налаштувань і способом довести кожне з них ззовні.

Перший обліковий запис є найнебезпечнішим

На новому сервері Mattermost перша людина, яка створює обліковий запис, стає системним адміністратором. Якщо сервер доступний з інтернету до того, як ви увійшли, його може забрати будь-хто, хто знайде його першим. Сканери знаходять нові сертифікати TLS за лічені хвилини після видачі, бо журнали certificate transparency публічні й за ними стежать.

Отже, порядок має значення: підніміть сервер на приватній адресі або за allow list, створіть адміністраторський обліковий запис самі й лише потім відкрийте його людям, яким він потрібен.

Одразу після цього закрийте відкриту реєстрацію. У config.json або через mmctl:

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

З вимкненим open server нові люди приходять лише за запрошенням або через створення облікового запису адміністратором. Обмеження створення власним поштовим доменом є другим замком на випадок, якщо посилання-запрошення помандрує далі, ніж планувалося.

Вирішіть, що виходить із будівлі в push-сповіщенні

Мобільний push є налаштуванням, на яке більшість людей ніколи не дивиться. Коли повідомлення надходить для телефону, Mattermost передає сповіщення push proxy, який передає його сервісу сповіщень платформи телефону. З типовим налаштуванням вмісту текст повідомлення їде разом.

Для конфіденційних команд змініть це:

mmctl --local config set EmailSettings.PushNotificationContents generic_no_channel

generic_no_channel надсилає «у вас нове повідомлення» і більше нічого. На редакціях, які це підтримують, id_loaded ще кращий: сповіщення несе лише ID повідомлення, а телефон забирає вміст із вашого власного сервера через TLS. Та сама логіка стосується поштових сповіщень: якщо ваш поштовий relay поза вашим контролем, налаштуйте поштові сповіщення на мінімум.

Сесії, MFA і довгий хвіст довіри

Кілька налаштувань вирішують, як довго вкрадений ноутбук або виловлений фішингом пароль залишаються корисними:

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

Примусове MFA залежить від вашої редакції; увімкнення доступне всюди і є мінімумом. Обирайте тривалість сесій, яку ваші користувачі витримають, але обирайте її свідомо. Боти та інтеграції мають використовувати personal access tokens на виділених облікових записах ботів, а не пароль людини, щоб MFA на людях ніколи не ламало інтеграцію.

Зачиніть бічні двері

Більшість компрометацій приходять не через сторінку входу. Вони приходять через функції, якими ніхто не користується:

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

Публічні посилання на файли дозволяють будь-кому з URL забрати вкладення без входу. Завантаження плагінів дозволяє будь-якому адміністраторському обліковому запису, включно зі скомпрометованим, виконувати довільний код на сервері; встановлюйте плагіни з файлової системи як зміну, а не з браузера. Небезпечні вихідні з’єднання дозволяють webhooks і попереднім переглядам посилань приймати погані сертифікати. Rate limiting дає API певну стійкість до password spraying.

Перевірте також ServiceSettings.AllowCorsFrom. Воно має бути порожнім, якщо у вас немає конкретного web-застосунку, якому це потрібно, і тоді має називати саме його origin, ніколи не wildcard.

mmctl --local спілкується із сервером через Unix socket на самій машині й потребує ServiceSettings.EnableLocalMode, встановленого в true. Тримайте local mode увімкненим для адміністрування із сервера і тримайте shell-доступ до цього сервера жорстким, бо local mode за задумом пропускає автентифікацію.

Вирішіть, хто взагалі може до нього дістатися

Командним чатом користується відома група людей з відомого набору місць. Інтернету загалом не потрібно до нього діставатися. Варіанти, від найвідкритішого до найзакритішого:

• Публічний, за firewall, який відкидає мережі, що у ваших логах сканування фігурують як джерела зловживань.
• Публічний, обмежений країнами, з яких ваша команда реально працює.
• Доступний лише через ваш VPN або з адрес вашого офісу.
• Лише у приватній мережі.

Фільтри за країною і провайдером належать firewall, а не Mattermost, щоб небажаний трафік ніколи не досягав застосунку. Якщо ви стоїте за reverse proxy, встановіть ServiceSettings.TrustedProxyIPHeader, щоб Mattermost логував і обмежував реальну адресу клієнта замість адреси вашого proxy.

Доведіть це ззовні

Налаштування, яке ви змінили, є гіпотезою. Тест з-поза вашої мережі є доказом. З машини, яка не у вашій мережі і не в 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>'

Якщо ви фільтруєте за країною або провайдером, тестуйте з кількох місць: машина в дозволеній країні, машина в заблокованій країні, машина в діапазоні хмарного провайдера. Робіть це після кожної зміни політики, а не один раз під час інсталяції. Правила firewall дрейфують, а правило, яке помилково відкрите, тривоги не підіймає.

Потім поставте важливі значення під моніторинг. Нічне завдання, яке читає mmctl config get для наведених вище ключів і порівнює їх зі значеннями, які ви обрали, скаже вам того ж дня, коли хтось клацне не той перемикач у System Console.

Оновлення є частиною захисту

Перед оновленням перевірте, що ваші плагіни підтримують цільовий реліз. Тримайте оновлення на тій лінії релізів, яку планували: «оновлення до latest» з пакета або tag контейнера може перевести вас на іншу гілку, ніж ви планували.

Короткий чекліст

• Адміністратор створений до того, як сервер став доступним.
• Open server вимкнено, створення обмежене вашим доменом.
• Вміст push-сповіщень зведено до загального або лише ID.
• MFA увімкнено, примусово там, де дозволяє редакція, розумна тривалість сесій.
• Публічні посилання, завантаження плагінів і небезпечні вихідні з’єднання вимкнені; rate limiting увімкнено.
• Мережева експозиція обрана свідомо і забезпечена на firewall.
• Кожне налаштування доведене ззовні і під наглядом на дрейф.

Ми експлуатуємо Mattermost саме так для наших клієнтів на виділених інстансах у власних дата-центрах. Якщо ви хотіли б другу пару очей на своєму, ми радо допоможемо.

Поговоріть з інженером

Related

Пов’язане: Managed team chat на Mattermost · Managed Request Tracker з мостами до партнерів · Managed source control на GitLab