Resumo

Devemos adicionar um sistema padronizado de log de autenticação ao Discourse que armazene eventos de autenticação de todos os métodos de autenticação habilitados para análise e solução de problemas.

Detalhes

Forneceríamos um provedor de log de autenticação ao qual todos os sistemas de autenticação se conectariam e enviariam eventos.

Como exemplo, o provedor de login local pode ter a seguinte lista (não completa) de eventos:

• alguém de [IP] falhou no login como o usuário fhqwhgads que não existe
• alguém de [IP] falhou no login como o usuário supermathie, foi limitado por taxa
• alguém de [IP] falhou no login como o usuário supermathie, mas forneceu uma senha inválida
• alguém de [IP] teve sucesso no login como o usuário supermathie, forneceu uma senha válida
• alguém de [IP] falhou no login como o usuário supermathie, forneceu uma senha válida, mas requer MFA para continuar
• alguém de [IP] falhou no login como o usuário supermathie, forneceu uma senha válida, forneceu um código TOTP inválido
• alguém de [IP] teve sucesso no login como o usuário supermathie, forneceu uma senha válida, forneceu um código TOTP válido para o token vault-work

O problema de confiar em logs existentes (logs da web) é que, com exceção do limitado por taxa, todos eles parecem exatamente os mesmos ([200] POST /session HTTP/1.1). Não há significado chegando ao log.

Preocupações

Existe a preocupação com eventos anônimos gerando entradas de log e o equilíbrio disso com a detecção de eventos que são interessantes do ponto de vista da análise SIEM, por exemplo, ataques de pulverização de senhas.

Registrar TUDO significa que qualquer pessoa na Internet pode encher seus logs… mas é discutível se isso é realmente um problema ou não. Observe a retenção abaixo - talvez as falhas sejam mantidas por um período mais curto dentro do log do aplicativo.

Uma questão semelhante surge em torno de logs baseados em token de uso único, por exemplo, login por e-mail. Tokens incorretos provavelmente não são “interessantes” para registrar, mas tokens reproduzidos são absolutamente, tanto do contexto de SIEM quanto do suporte ao usuário.

Perguntas

Retenção: manter tudo para sempre? 30 dias? 90 dias? descartar eventos anônimos mais cedo?

Autenticação de chave de API: Chamadas com chaves de API de usuário ou administrador ruins devem ser registradas aqui? Provavelmente - isso ajudará na depuração.

Quanto deve ser configurável? por exemplo, ativar logs de depuração para tudo ou apenas para um provedor?

Considerações de Implementação

A implementação deve ser flexível o suficiente para permitir que outro provedor de armazenamento de eventos seja adicionado ao pipeline de log. Um exemplo de tal provedor pode ser um arquivo de log bruto, uma fila de mensagens ou um bucket S3. Os detalhes exatos de tal provedor estão fora do escopo deste tópico, mas a implementação deve ser flexível o suficiente para que um plugin possa se registrar para receber logs conforme são gerados.

Contexto

Tivemos um cliente pedindo isso com a intenção de alimentar os eventos para seu SIEM e percebemos que era uma lacuna de recursos no Discourse.

Durante a discussão interna, também descobrimos que essas informações seriam úteis para administradores de sites e nossos próprios defensores de suporte, pois os logs de autenticação podem estar em vários lugares e é preciso saber onde procurar para encontrá-los. Isso depende de conhecimento pessoal e um log central aliviaria muito esse fardo.

Uma maneira conveniente de visualizar esses logs do console do rails seria benéfica para nós e para os administradores do site.