Quais dados devem ser excluídos dos arquivos de log, mensagens de erro, etc., se postados on-line?

Question

Quais dados devem ser apagados dos arquivos de log, mensagens de erro, etc., se forem postados como captura de tela para não expor informações confidenciais?

Para refinar minha pergunta : o que um usuário de Linux deve estar mais atento se ocultando capturas de tela de arquivos de registro, mensagens de erro, configurações, etc.?

    

Answer 1

Esta é uma questão abrangente e provavelmente só pode ser respondida com os mesmos tipos de pinceladas. Em última análise, tudo se resume ao que você, o usuário, deseja proteger.

Fundamentalmente, você não deve postar nada que permita que outra pessoa ache mais fácil comprometer seu sistema ou qualquer outra ferramenta ou conta conectada que você usa. Por esse motivo, você deve considerar:

• Esfregando as senhas de qualquer material que você publique
• Obscurecendo seu endereço IP
• Alterando detalhes das portas que você abre para a rede
• Removendo detalhes sobre seu ISP
• Como redigir seu endereço de e-mail pessoal se você não deseja atrair (mais) spam
• Alterar ou remover identificadores de hardware, como endereços MAC

O risco real não está necessariamente em torno das informações individuais (exceto, talvez, no caso de sua senha - especialmente se for uma que você reutilize, mas você não faria isso, é claro), mas em o agregado que alguns malfeitores puderam juntar com algum tempo e esforço ¹ .

Claro, não se trata apenas de tecnologia ou de seu sistema; mais amplamente interpretado, existem outras medidas profiláticas que você pode querer considerar.

Se você valoriza a sua privacidade e a da sua família, então você gostaria de tomar medidas adicionais para garantir que apenas as informações pessoais com as quais você se sinta confortável entrem no domínio público; por exemplo, sua localização geográfica, nome legal completo, fotografia ou outras informações de identificação poderiam constituir material que poderia ser usado para roubo de identidade ou outra atividade nefasta.

É improvável que essas outras facetas de informações sejam incluídas em capturas de tela ou arquivos de registro, mas se já estiverem on-line por outros meios, como sites de redes sociais e semelhantes, aumentam a vulnerabilidade e, em qualquer caso, , você deve estar consciente desse perfil, no mínimo.

^{1. Níveis padrão de paranóia sendo aplicados ...}

    

Answer 2

A regra básica deve ser a exposição apenas das informações necessárias.

Então, as regras básicas de segurança se aplicam:

1. Apenas o nível de acesso / informações necessário
2. Qualquer outra coisa deve ser proibida / não legível

Como você pode ver em muitas perguntas feitas aqui - os comentários solicitarão mais informações, se necessário. Mas cabe a você obfatar informações pessoais sobre indivíduos ou detalhes técnicos desnecessários para esse problema.

    

Answer 3

Somando-se às outras duas (excelentes) respostas, também é bom perceber que o processo de separação de fatores, tão importante para um bom teste / solução de problemas, está de alguma forma relacionado ao ato de remover as informações confidenciais.

Em outras palavras, sempre que possível, sempre tente replicar seu problema em um ambiente separado. Além da vantagem de excluir (que muitas vezes acaba saindo como) informação irrelevante e ajudar a encontrar a causa raiz, ela também pode ocultar seu ambiente de produção do laboratório.

Exemplos mais específicos:

• crie e use outra conta de teste (não se esqueça de excluí-la depois)

• se você tiver capacidade de computação suficiente, mantenha uma máquina virtual de teste ou até mesmo uma rede virtual à mão e replicar o problema lá. Isso pode até mesmo te dá uma enorme vantagem de snapshots.

• nesses ambientes, tendem a nomear coisas como "foo", "bar", "me", "Aqui". Em muitas circunstâncias, isso fará com que se destaque informação é de pouco ou nenhum valor

Ao experimentar dessa maneira (enquanto ainda respeita o que é dito nos outros dois posts), você descobrirá que há muito menos informação que é relevante o suficiente para precisar < para ser postado em primeiro lugar, e por sua vez, há muito menos informação que é deixado para esconder.

    

Answer 4

Basta complementar as outras respostas que mostram quais tipos de coisas anonimizar em logs. Pensei em fornecer uma lista de ferramentas que podem ser usadas para facilitar a anonimização dos registros.

TCPDUMP / pcap

A lista é principalmente ferramentas para lidar com logs tcpdump / pcap. OBSERVAÇÃO: A lista completa de lista de ferramentas e bibliotecas está aqui .

• AnonTool
  • Netflow (v5 e v9) rastreia no formato tcpdump ou em interfaces ativas
• CoralReef
  • interfaces de rede; Cartões de captura DAG, FORE e POINT; rastrear arquivos nos formatos CoralReef (.crl), tcpdump / pcap, DAG (herdado e ERF) ou TSH (.tsh)
• ipsumdump
  • tcpdump / pcap, DAG (herdado e ERF), FR, FR +, TSH, ipsumdump (texto), resumo do NetFlow (texto), dispositivo de rede do linux
• SCRUB-tcpdump
  • tcpdump / pcap, interface de rede
• tcpanon
  • tcpdump / pcap
• tcpdpriv
  • tcpdump / pcap, interface de rede
• tcpmkpub
  • tcpdump / pcap
• TCPurify
  • tcpdump / pcap, interface de rede

Frameworks de registro em log

Splunk

O

Splunk é um agregador de arquivos de log. O Splunk agrega logs do sistema, como o syslog, em um local centralizado onde ele pode ser analisado. Ele fornece uma ferramenta para anonimizar os dados coletados.

A execução desta ferramenta funciona da seguinte forma:

./splunk anonymize file -source </path/to/filename>

A funcionalidade de anonimato é bastante configurável, você pode ler mais sobre isso aqui .

syslog-ng Você pode realmente usar o framework de log, syslog-ng , ele próprio para fazer a anonimização se forem dados que nunca devem ser nos logs para começar.

Há um exemplo interessante disso aqui neste post intitulado: Linux: anonimiza logs de IP com syslog-ng .

A ideia é bem simples:

Syslog-NG allows you to rewrite content using regular expressions. Add the following two rewrite rules to /etc/syslog-ng/syslog-ng.conf to replace IPv4 and IPv6 addresses by [REDACTED] and [REDACTED6]. (the regexp for IPv6 hasn't been tested extensively yet).

Usando a funcionalidade rewrite e subst criada dentro do syslog-ng você pode fazer algo assim:

rewrite r_ip {
subst('\b(1?[0-9]{1,2}|2[0-4][0-9]|25[0-5])\.(1?[0-9]{1,2}|2[0-4][0-9]|25[0-5])\.(1?[0-9]{1,2}|2[0-4][0-9]|25[0-5])\.(1?[0-9]{1,2}|2[0-4][0-9]|25[0-5])\b',
"\[REDACTED\]", value("MESSAGE"), type("pcre"), flags("global"));
}