Portanto, esta é uma pergunta de noob.
Por que realizamos uma limpeza em uma máquina que foi infectada com malware e não a detonamos diretamente? Entendo que em algumas situações isso não seria possível (como grandes servidores de banco de dados ou quando não temos backup). Mas muitos vídeos de instruções e ferramentas são projetados para estações de trabalho e não para servidores de grande escala.
Acho que meu fluxo de trabalho provavelmente seria algo como: Limpar máquina/Recuperar arquivos dos quais não foi feito backup -> Nuke/reinstalar máquina -> corrigir/atualizar/restaurar backup -> adicionar máquina de volta à rede.
Mas pelo que entendi, se possível apenas o primeiro passo "limpar a máquina" é feito como medida para lidar com malware. Mas podemos confiar plenamente que todo o malware foi removido na etapa de “limpeza”? Estou sendo paranóico e trabalhando 10x para o que é necessário ou estou perdendo alguma coisa?
Obrigado por suas respostas.
Responder1
"muitos vídeos de instruções e ferramentas são projetados para estações de trabalho"
(Isso provavelmente deveria ser: paralarUsuários)
Uma suposição justa para muitos usuários domésticos seria que eles não fazem backups (regulares) e seu laptop/PC é seu (único) animal de estimação. Seu tempo e esforço são "gratuitos" e seus dados e arquivos só se tornaramrealmentevalioso para eles após a infecção por malware.
Com base nessa premissa, faz sentido que eles despendam um esforço significativo para tornar um laptop ou PC funcional o suficiente para inicializar corretamente e tornar-se utilizável novamente para acessar e recuperar seus dados e arquivos.
Para muitos usuários domésticos em tal situação, isso já é uma grande conquista e eles estão felizes agora.
Fim do vídeo.
Eles não sabem ou simplesmente ignoram que é claro que seu sistema não está "totalmente reparado" e que ainda não se pode confiar que os dados estejam limpos.
Como profissional, você pode receber orientações de pessoas que têm a visão de mundo de um usuário doméstico (ou seja, que "reparar" e colocar um sistema comprometido em funcionamento é uma tarefa quase intransponível e sempre necessária para recuperar arquivos e dados), que acreditam que você, como profissional, pode conseguir muitas coisas que eles não podem (reconhecidamente corrigir) e que então (incorretamente) também acreditam que quando VOCÊ faz os reparos, o sistema e os dados comprometidospodepode ser confiável para estar limpo novamente sem reinstalar.
Cabe ao departamento de TI/você dar a resposta adequada.
Por exemplo, em teoria (e na realidade, certo?) você tem backups e/ou replicação de dados adequados para atender ao RPO e RTO e não precisa recuperar dados de um servidor comprometido para continuidade dos negócios.
Destrua o sistema comprometido, execute seus scripts automatizados de instalação e configuração, reimplante e fique feliz.
Acho que meu fluxo de trabalho provavelmente seria algo como:
Limpar máquina/Recuperar arquivos dos quais não foi feito backup
-> Nuke/reinstalar máquina
-> corrigir/atualizar/restaurar backup
-> adicionar máquina de volta à rede.
Parece que você está começando a escrever o que no "jargão empresarial" é chamado de Plano de Resposta a Incidentes.
Esse é um primeiro começo razoável.Resposta de PhilL W.já vinculado aum bom recurso aqui no ServerFaultmas esteja ciente de que o plano de resposta a incidentes não foi escrito apenas por e para um administrador de sistema, mas também deve ser apoiado por sua empresa. As decisões estão intimamente relacionadas ao seu plano de recuperação de desastres, onde muitas vezes são decididos o backup e a recuperação de dados (RPO e RTO).
Responder2
Limpar máquina/Recuperar arquivos dos quais não foi feito backup...
... qualquer um ou todos os quais podem sercomprometido. Você deveapenasuse esses arquivos para fins de diagnóstico, fora da rede, para rastrear a vulnerabilidade que permitiu a entrada do malware. Você não deve tentar reconstruir um sistema em execução baseado neles.
Nuke/reinstalar máquina... corrigir/atualizar/restaurar backup... adicionar máquina de volta à rede.
Esta é a maneira geralmente aceita delidar com um servidor comprometido, mas potencialmente leva ummuito tempoe uma Estratégia de Recuperação corporativa mal redigida poderá não permitir isso. É por isso que nos pedem para “consertar” as coisas “rapidamente”, apesar do risco inerente de fazê-lo.