Reinstalar após um comprometimento raiz?

Depois de ler essa pergunta em um comprometimento de servidor , comecei a me perguntar por que as pessoas parecem acreditar que podem recuperar um sistema comprometido usando ferramentas de detecção / limpeza ou apenas consertando o buraco que foi usado para comprometer o sistema.

Dadas todas as várias tecnologias de kit raiz e outras coisas que um hacker pode fazer, a maioria dos especialistas sugere que você deve reinstalar o sistema operacional .

Espero ter uma idéia melhor do porquê mais pessoas não apenas decolam e desarmam o sistema da órbita.

Aqui estão alguns pontos que eu gostaria de ver abordados.

• Existem condições em que um formato / reinstalação não limpa o sistema?
• Sob quais tipos de condições você acha que um sistema pode ser limpo e quando você deve fazer uma reinstalação completa?
• Que raciocínio você tem contra a reinstalação completa?
• Se você optar por não reinstalar, qual método você usa para ter certeza razoável de que limpou e impediu que mais danos ocorram novamente.

Uma decisão de segurança é, em última análise, uma decisão comercial sobre risco, assim como uma decisão sobre qual produto levar ao mercado. Quando você o enquadra nesse contexto, a decisão de não nivelar e reinstalar faz sentido. Quando você o considera estritamente do ponto de vista técnico, isso não acontece.

Aqui está o que normalmente entra nessa decisão de negócios:

• Quanto nosso tempo de inatividade nos custará em quantia mensurável?
• Quanto nos custará potencialmente quando tivermos que revelar aos clientes um pouco sobre o motivo de termos caído?
• De que outras atividades vou ter que afastar as pessoas para fazer a reinstalação? Qual o custo?
• Temos as pessoas certas que sabem como abrir o sistema sem erros? Se não, o que vai me custar quando eles solucionam problemas?

E, portanto, quando você soma custos como esses, pode ser considerado que continuar com um sistema "potencialmente" ainda comprometido é melhor do que reinstalar o sistema.

Com base em um post que escrevi há muito tempo, quando ainda podia me incomodar no blog.

Esta pergunta continua sendo feita repetidamente pelas vítimas de hackers invadindo seu servidor web. As respostas raramente mudam, mas as pessoas continuam fazendo a pergunta. Não sei por que. Talvez as pessoas simplesmente não gostem das respostas que viram ao procurar ajuda ou não conseguem encontrar alguém em quem confiem para dar conselhos. Ou talvez as pessoas leiam uma resposta a esta pergunta e se concentrem muito nos 5% dos motivos pelos quais o seu caso é especial e diferente das respostas que podem encontrar on-line e não atinjam os 95% da pergunta e respondam onde o caso está próximo o suficiente. como o que eles lêem online.

Isso me leva à primeira pepita importante de informações. Eu realmente aprecio o fato de você ser um floco de neve único e especial. Compreendo que seu site também seja, pois é um reflexo de você e sua empresa ou, no mínimo, seu trabalho duro em nome de um empregador. Mas para quem está de fora olhando, seja uma pessoa de segurança de computadores que esteja olhando o problema para tentar ajudá-lo ou até o próprio invasor, é muito provável que o seu problema seja pelo menos 95% idêntico a todos os outros casos que eles já olhou.

Não tome o ataque pessoalmente, e não tome as recomendações que seguem aqui ou que você recebe de outras pessoas pessoalmente. Se você está lendo isso depois de se tornar vítima de uma invasão de site, lamento muito e espero que encontre algo útil aqui, mas não é hora de deixar seu ego atrapalhar o que você precisa. Faz.

Você acabou de descobrir que seus servidores foram invadidos. O que agora?

Não entre em pânico. Absolutamente não aja com pressa e absolutamente não tente fingir que as coisas nunca aconteceram e nem sequer age.

Primeiro: entenda que o desastre já aconteceu. Este não é o momento da negação; é o momento de aceitar o que aconteceu, ser realista e tomar medidas para gerenciar as consequências do impacto.

Algumas dessas etapas vão doer e (a menos que seu site possua uma cópia dos meus detalhes), eu realmente não me importo se você ignora todas ou algumas dessas etapas, mas isso fará com que as coisas melhorem no final. O medicamento pode ter um gosto horrível, mas às vezes você precisa ignorar isso se realmente deseja que a cura funcione.

Pare o problema de se tornar pior do que já é:

1. A primeira coisa que você deve fazer é desconectar os sistemas afetados da Internet. Quaisquer outros problemas que você tiver, deixar o sistema conectado à Web permitirá que o ataque continue. Quero dizer isso literalmente; faça com que alguém visite fisicamente o servidor e desconecte os cabos de rede, se for o caso, mas desconecte a vítima de seus assaltantes antes de tentar fazer qualquer outra coisa.
2. Altere todas as suas senhas para todas as contas em todos os computadores que estão na mesma rede que os sistemas comprometidos. Não mesmo. Todas as contas. Todos os computadores Sim, você está certo, isso pode ser um exagero; por outro lado, talvez não. Você não sabe de nenhuma maneira, sabe?
3. Verifique seus outros sistemas. Preste atenção especial a outros serviços voltados para a Internet e para aqueles que mantêm dados financeiros ou outros dados comercialmente sensíveis.
4. Se o sistema mantiver os dados pessoais de alguém, faça uma divulgação completa e franca a qualquer pessoa potencialmente afetada ao mesmo tempo. Eu sei que este é difícil. Eu sei que este vai doer. Sei que muitas empresas querem varrer esse tipo de problema para debaixo do tapete, mas temo que você tenha que lidar com isso.

Ainda hesita em dar este último passo? Eu entendo, eu entendo. Mas olhe assim:

Em alguns lugares, é possível que você tenha um requisito legal para informar as autoridades e / ou as vítimas desse tipo de violação de privacidade. Por mais irritados que seus clientes possam ser que você conte a eles sobre um problema, eles ficarão muito mais irritados se você não contar a eles, e eles descobrirão por si próprios depois que alguém cobrar US $ 8.000 em mercadorias usando os detalhes do cartão de crédito que eles roubou do seu site.

Lembra do que eu disse anteriormente? A coisa ruim já aconteceu . A única questão agora é quão bem você lida com isso.

Entenda o problema completamente:

1. NÃO coloque os sistemas afetados novamente online até que este estágio esteja totalmente completo, a menos que você queira ser a pessoa cuja postagem foi o ponto de inflexão para eu realmente decidir escrever este artigo. Eu não estou ligando para o post para que as pessoas possam ter uma risada barata; Estou ligando para avisá-lo das consequências de não seguir este primeiro passo.
2. Examine os sistemas 'atacados' para entender como os ataques conseguiram comprometer sua segurança. Faça todos os esforços para descobrir de onde os ataques "vieram", para que você entenda quais problemas você tem e precisa resolver para tornar seu sistema seguro no futuro.
3. Examine os sistemas 'atacados' novamente, desta vez para entender para onde foram os ataques, para entender quais sistemas foram comprometidos no ataque. Certifique-se de acompanhar os indicadores que sugerem que sistemas comprometidos podem se tornar um trampolim para atacar ainda mais seus sistemas.
4. Verifique se os "gateways" usados ​​em todo e qualquer ataque são totalmente compreendidos, para que você possa começar a fechá-los adequadamente. (por exemplo, se seus sistemas foram comprometidos por um ataque de injeção de SQL, além de não ser necessário fechar a linha de código defeituosa específica pela qual eles invadiram, você desejaria auditar todo o seu código para verificar se o mesmo tipo de erro foi feito em outro lugar).
5. Entenda que os ataques podem ter êxito devido a mais de uma falha. Freqüentemente, os ataques são bem-sucedidos não ao encontrar um bug importante em um sistema, mas ao reunir vários problemas (às vezes menores e triviais por si mesmos) para comprometer um sistema. Por exemplo, usando ataques de injeção SQL para enviar comandos para um servidor de banco de dados, descobrir que o site / aplicativo que você está atacando está sendo executado no contexto de um usuário administrativo e usar os direitos dessa conta como um trampolim para comprometer outras partes do um sistema. Ou como os hackers gostam de chamar: "outro dia no escritório aproveitando os erros comuns que as pessoas cometem".

Faça um plano de recuperação e coloque seu site on-line novamente e siga-o:

Ninguém quer ficar offline por mais tempo do que precisa. Isso é um dado. Se este site for um mecanismo de geração de receita, a pressão para trazê-lo on-line rapidamente será intensa. Mesmo que a única coisa em risco seja a reputação da sua empresa, isso ainda gerará muita pressão para que as coisas sejam rapidamente recuperadas.

No entanto, não ceda à tentação de voltar à Internet muito rapidamente. Em vez disso, avance o mais rápido possível para entender o que causou o problema e resolvê-lo antes de voltar a ficar on-line; caso contrário, você quase certamente será vítima de uma invasão mais uma vez e lembre-se: "ser invadido uma vez pode ser classificado como infortúnio; ser hackeado de novo logo depois parece descuido "(com desculpas a Oscar Wilde).

1. Suponho que você tenha entendido todos os problemas que levaram à invasão bem-sucedida antes de começar esta seção. Não quero exagerar o caso, mas se você não fez isso primeiro, então realmente precisa. Desculpa.
2. Nunca pague chantagem / dinheiro de proteção. Este é o sinal de uma marca fácil e você não deseja que essa frase seja usada para descrevê-lo.
3. Não fique tentado a colocar os mesmos servidores online novamente sem uma reconstrução completa. Deve ser muito mais rápido criar uma nova caixa ou "remover o servidor da órbita e fazer uma instalação limpa" no hardware antigo do que seria auditar todos os cantos do sistema antigo para garantir que ele esteja limpo antes de colocá-lo de volta online novamente. Se você não concorda com isso, provavelmente não sabe o que realmente significa garantir a limpeza completa do sistema ou os procedimentos de implantação do site são uma bagunça profana. Você provavelmente tem backups e implantações de teste do seu site, que você pode usar para criar o site ativo e, se não o fizer, ser invadido não é o seu maior problema.
4. Tenha muito cuidado ao reutilizar dados que estavam "ativos" no sistema no momento do hack. Não direi "nunca faça isso" porque você vai me ignorar, mas sinceramente acho que você precisa considerar as consequências de manter os dados por perto quando sabe que não pode garantir sua integridade. Idealmente, você deve restaurar isso a partir de um backup feito antes da invasão. Se você não puder ou não fará isso, tenha muito cuidado com esses dados, pois estão contaminados. Você deve estar especialmente ciente das consequências para os outros se esses dados pertencerem a clientes ou visitantes do site, e não diretamente a você.
5. Monitore o (s) sistema (s) com cuidado. Você deve decidir fazer isso como um processo contínuo no futuro (mais abaixo), mas se esforça ao máximo para ficar vigilante durante o período imediatamente após o site voltar a ficar on-line. Os invasores quase certamente voltarão, e se você puder vê-los tentando arrombar novamente, certamente será capaz de ver rapidamente se realmente fechou todos os buracos que eles usavam antes, além de qualquer um que eles mesmos fizessem, e pode ser útil informações que você pode passar para a polícia local.

Reduzindo o risco no futuro.

A primeira coisa que você precisa entender é que a segurança é um processo que você deve aplicar ao longo de todo o ciclo de vida de projetar, implantar e manter um sistema voltado para a Internet, não algo que você pode aplicar algumas camadas no seu código posteriormente como barato pintura. Para ser adequadamente seguro, um serviço e um aplicativo precisam ser projetados desde o início, com isso em mente como um dos principais objetivos do projeto. Sei que isso é chato e você já ouviu isso antes e que "simplesmente não percebo a pressão" de colocar seu serviço beta web2.0 (beta) no status beta na web, mas o fato é que isso mantém sendo repetido porque foi verdade na primeira vez que foi dito e ainda não se tornou mentira.

Você não pode eliminar riscos. Você nem deveria tentar fazer isso. No entanto, o que você deve fazer é entender quais riscos de segurança são importantes para você e como gerenciar e reduzir o impacto do risco e a probabilidade de que o risco ocorra.

Que medidas você pode tomar para reduzir a probabilidade de um ataque ser bem-sucedido?

Por exemplo:

1. A falha que permitia que as pessoas invadissem seu site era um bug conhecido no código do fornecedor, para o qual um patch estava disponível? Em caso afirmativo, você precisa repensar sua abordagem de como aplica aplicações em seus servidores voltados para a Internet?
2. A falha que permitia que as pessoas invadissem seu site era um bug desconhecido no código do fornecedor, para o qual um patch não estava disponível? Certamente não defendo a mudança de fornecedores sempre que algo assim o incomoda, porque todos têm seus problemas e você ficará sem plataformas em um ano, no máximo, se seguir essa abordagem. No entanto, se um sistema o decepciona constantemente, você deve migrar para algo mais robusto ou, pelo menos, re-arquitetar seu sistema para que os componentes vulneráveis ​​fiquem envoltos em algodão e o mais longe possível dos olhos hostis.
3. A falha foi um bug no código desenvolvido por você (ou por um contratado trabalhando para você)? Em caso afirmativo, você precisa repensar sua abordagem de como aprova o código para implantação no site ativo? O bug pode ter sido detectado com um sistema de teste aprimorado ou com alterações no seu "padrão" de codificação (por exemplo, embora a tecnologia não seja uma panacéia, você pode reduzir a probabilidade de um ataque de injeção SQL bem-sucedido usando técnicas de codificação bem documentadas )
4. A falha ocorreu devido a um problema de como o servidor ou aplicativo foi implantado? Se sim, você está usando procedimentos automatizados para criar e implantar servidores sempre que possível? Essa é uma grande ajuda para manter um estado consistente de "linha de base" em todos os seus servidores, minimizando a quantidade de trabalho personalizado que deve ser feito em cada um e, consequentemente, minimizando a oportunidade de erro. O mesmo acontece com a implantação de código - se você precisar que algo "especial" seja feito para implantar a versão mais recente do seu aplicativo Web, tente automatizá-lo e garantir que ele sempre seja feito de maneira consistente.
5. A invasão poderia ter sido detectada anteriormente com um melhor monitoramento de seus sistemas? É claro que o monitoramento 24 horas ou um sistema "de plantão" para sua equipe pode não ser econômico, mas existem empresas por aí que podem monitorar seus serviços voltados para a Web e alertá-lo em caso de problema. Você pode decidir que não pode pagar por isso ou não precisa disso, e tudo bem ... leve isso em consideração.
6. Use ferramentas como tripwire e nessus quando apropriado - mas não as use cegamente porque eu disse isso. Reserve um tempo para aprender a usar algumas boas ferramentas de segurança adequadas ao seu ambiente, manter essas ferramentas atualizadas e usá-las regularmente.
7. Considere contratar especialistas em segurança para 'auditar' regularmente a segurança do site. Novamente, você pode decidir que não pode pagar por isso ou não precisa, e isso é bom ... apenas leve em consideração.

Que medidas você pode tomar para reduzir as consequências de um ataque bem-sucedido?

Se você decidir que o "risco" do piso inferior da inundação da sua casa é alto, mas não alto o suficiente para justificar a mudança, você deve pelo menos mover a herança insubstituível da família para o andar de cima. Direito?

1. Você pode reduzir a quantidade de serviços diretamente expostos à Internet? Você pode manter algum tipo de lacuna entre seus serviços internos e os serviços voltados para a Internet? Isso garante que, mesmo que seus sistemas externos estejam comprometidos, as chances de usá-lo como trampolim para atacar seus sistemas internos são limitadas.
2. Você está armazenando informações que não precisa armazenar? Você está armazenando essas informações "online" quando poderiam ser arquivadas em outro lugar. Existem dois pontos nessa parte; o mais óbvio é que as pessoas não podem roubar informações que você não possui, e o segundo ponto é que, quanto menos você armazena, menos precisa manter e codificar e, portanto, há menos chances de erros ocorrerem. seu código ou design de sistemas.
3. Você está usando os princípios de "menor acesso" para seu aplicativo Web? Se os usuários precisarem ler apenas de um banco de dados, verifique se a conta que o aplicativo Web usa para atender isso tem apenas acesso de leitura, não permita acesso de gravação e, certamente, não acesso ao nível do sistema.
4. Se você não tem muita experiência em algo e não é essencial para os seus negócios, considere a terceirização. Em outras palavras, se você administra um site pequeno falando sobre escrever código de aplicativo de desktop e decide começar a vender pequenos aplicativos de desktop do site, considere "terceirizar" o sistema de pedidos de cartão de crédito para alguém como Paypal.
5. Se possível, torne a recuperação da prática de sistemas comprometidos parte do seu plano de recuperação de falhas. Este é, sem dúvida, apenas outro "cenário de desastre" que você pode encontrar, simplesmente um com seu próprio conjunto de problemas e questões que são distintas da habitual 'sala do servidor pegou fogo' / 'foi invadido por um servidor gigante comendo o tipo de coisa dos furbies. (editar, por XTZ)

... E finalmente

Provavelmente não deixei de lado coisas que os outros consideram importantes, mas as etapas acima devem ajudá-lo a começar a resolver as coisas se você tiver a sorte de ser vítima de hackers.

Acima de tudo: não entre em pânico. Pense antes de agir. Aja com firmeza depois de tomar uma decisão e deixe um comentário abaixo se tiver algo a acrescentar à minha lista de etapas.

Sempre o tire da órbita. É a única maneira de ter certeza.

_{(fonte: flickr.com )}

A maioria dos sistemas são entidades holísticas que possuem uma confiança implícita e interna. Confiar em um sistema comprometido é uma declaração implícita de que você confia em quem fez a violação do seu sistema, para começar. Em outras palavras:

Você não pode confiar nisso. Não se preocupe com a limpeza. Desconecte e isole a máquina imediatamente. Entenda a natureza da violação antes de prosseguir, caso contrário, convide a mesma coisa novamente. Tente, se possível, obter a data e a hora da violação, para ter um quadro de referência. Você precisa disso porque se você restaurar a partir do backup, precisará ter certeza de que o backup em si não possui uma cópia do comprometimento. Limpe antes de restaurar - não use atalhos.

Na prática, a maioria das pessoas não faz isso porque acha que demorará muito ou será muito perturbador. Aconselhei inúmeros clientes sobre a probabilidade de problemas persistentes, mas uma reinstalação é frequentemente interrompida por um tomador de decisão por um desses motivos.

Dito isto, em sistemas nos quais tenho certeza de que conheço o método de entrada e toda a extensão do dano (logs sólidos fora da máquina, geralmente com um IDS, talvez SELinux ou algo semelhante limitando o escopo da invasão), eu fizeram uma limpeza sem reinstalar sem se sentirem muito culpados.

Provavelmente, eles não têm uma rotina de recuperação de desastre testada o suficiente para se sentirem confiantes em uma reconstrução ou não está claro quanto tempo levaria ou qual seria o impacto ... ou os backups não são confiáveis ​​ou seus analistas de risco não entendo o escopo de um sistema comprometido. Eu posso pensar em muitas razões.

Eu diria que é principalmente algo errado nas rotinas e políticas básicas e não é algo que você gostaria de admitir abertamente - e, em vez disso, adota uma postura defensiva. Pelo menos eu não posso ver ou defender não limpar um sistema comprometido, não importa qual ângulo você olhe para ele.

Anteriormente, eu não havia desarmado o sistema para que eu pudesse fazer uma análise do vetor em que eles entraram e subsequente análise do uso e para ver onde eles chegaram.

Depois de ter sido enraizado - você tem um honeypot ativo e ele pode oferecer muito mais do que apenas o hack. - especialmente para a polícia.

• isso disse que eu tenho uma pré-qualificação para poder obter um sistema limpo em modo de espera e oferecer segurança de rede aprimorada rapidamente para isolar a caixa enraizada.