# O que fazer se o seu Discourse for comprometido

**URL:** https://meta.discourse.org/t/what-to-do-if-your-discourse-is-compromised/40129
**Category:** Self-Hosting
**Tags:** reference
**Created:** [Fevereiro 24, 2016, 11:39pm UTC](https://meta.discourse.org/t/what-to-do-if-your-discourse-is-compromised/40129 "2016-02-24T23:39:47Z")
**Posts on this page:** 1
**Page:** 1

<div class="post-metadata">

### Author: ![Discourse](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/discourse/32/148734_2.png) [@Discourse](https://meta.discourse.org/u/Discourse)
#### Post date: [Fevereiro 24, 2016, 11:39pm UTC](https://meta.discourse.org/t/what-to-do-if-your-discourse-is-compromised/40129/1 "2016-02-24T23:39:47Z")

</div>

Recentemente, tivemos dois relatos de sites Discourse que foram comprometidos, provavelmente devido a senhas fracas de contas de administrador. Portanto, gostaríamos de documentar:

- o que fazer quando ocorre um comprometimento
- o que podemos fazer para prevenir melhor isso no futuro

### O Banco de Dados

Observe que o Discourse, há vários anos, tem as seguintes proteções em vigor em relação ao banco de dados do site:

- Os links para download de backup completo do banco de dados só serão enviados por meio de e-mail válido de um administrador do site, então você não pode simplesmente fazer login (por meio de “shoulder surfing” ou esquecer de sair), você também deve _controlar_ o endereço de e-mail de um administrador do site. E [você tem o 2FA configurado para seu e-mail](https://support.google.com/accounts/answer/185839), certo? 😉

- Para alterar o e-mail da equipe, você deve verificar o controle de **ambos** os endereços de e-mail, o antigo e o novo — enquanto um usuário normal só precisa verificar o controle do endereço de e-mail _novo_. Isso torna muito mais difícil alterar o endereço de e-mail de um membro da equipe.

- Assumindo que você [configurou a chave de API do banco de dados de geolocalização](https://meta.discourse.org/t/configuring-maxmind-for-reverse-ip-lookups/173941) (é grátis, requer um cadastro), você será ativamente avisado quando membros da equipe fizerem login de locais fisicamente distantes de onde fizeram login pela última vez.

- Administradores que não fazem login há mais de um ano são obrigados a revalidar seu endereço de e-mail, para reduzir a superfície de ataque. A configuração do site para isso é `invalidate inactive admin email after days` (invalidar e-mail de administrador inativo após dias) e o padrão é 365.

> ⚠ Ainda assim, em caso de comprometimento, você deve _sempre_ presumir que uma conta de administrador mal-intencionada baixou uma cópia completa do banco de dados/backup do site.

Portanto, você deve **IMEDIATAMENTE** redefinir todas as senhas de contas usando o seguinte comando:

```plaintext
./launcher enter app
rails r 'UserPassword.update_all(password_hash: SecureRandom.hex * 2)'

```

Além disso, você **deve** desconectar todos os usuários

```plaintext
./launcher enter app
rails r 'UserAuthToken.destroy_all'

```

Finalmente, você **deve** remover todas as chaves de API

```plaintext
./launcher enter app
rails r 'UserApiKey.destroy_all' 
rails r 'ApiKey.destroy_all'

```

### Senhas de Conta no Banco de Dados

De acordo com [nossa documentação de segurança](https://github.com/discourse/discourse/blob/main/docs/SECURITY.md), o Discourse usa hashes muito fortes e lentos para atacar as senhas armazenadas no banco de dados:

> O Discourse usa o algoritmo PBKDF2 para criptografar senhas com sal. Este algoritmo é abençoado pelo NIST. Especialistas em segurança na web [tendem a concordar que o PBKDF2 é uma escolha segura](http://security.stackexchange.com/questions/4781/do-any-security-experts-recommend-bcrypt-for-password-storage).

E o comprimento mínimo padrão da senha é 10 para usuários e 15 para administradores — então isso torna difícil reverter por força bruta os hashes de senha para obter o hash. Mas isso _não_ impede que os usuários definam uma senha como `senha1senha1` ou algo trivial de reverter, mesmo com um hash forte.

### E-mails no Banco de Dados

O invasor pode ver todos os endereços de e-mail de todos os usuários no seu site. Esta é normalmente uma informação privilegiada que até moderadores precisam clicar em um botão para revelar.

### Conteúdo da Mensagem no Banco de Dados

Como o invasor tem uma cópia do banco de dados, ele pode ver todas as informações armazenadas em todas as postagens.

- Se você tem senhas externas ou informações de conta retransmitidas em suas respostas, privadas ou públicas, você deve alterar essas senhas imediatamente.

- Se você tem informações confidenciais em suas respostas, privadas ou públicas, esteja ciente de que o invasor pode ver essas informações.

### Mensagens Criptografadas

Se você estiver usando o plugin [Discourse Encrypt](https://meta.discourse.org/t/discourse-encrypt-for-private-messages/107918), as mensagens criptografadas serão criptografadas de ponta a ponta. Isso significa que, se o banco de dados vazar, o invasor não poderá obter acesso ao conteúdo em mensagens criptografadas.

### Regulamentações

Certifique-se de buscar aconselhamento jurídico profissional sobre sua obrigação legal. Certos regulamentos, como GDPR e CCPA, podem exigir divulgação.

### No Futuro

Você pode querer exigir autenticação de dois fatores para usuários da equipe se tiver motivos para acreditar que seu site estará sob ataque. A configuração do site que você deseja é “enforce second factor” (forçar segundo fator)

> #### enforce second factor (forçar segundo fator)
> 
> Força os usuários a habilitar a autenticação de dois fatores. Selecione ‘all’ (todos) para forçar a todos os usuários. Selecione ‘staff’ (equipe) para forçar apenas aos usuários da equipe.