Reinstalar após um comprometimento da raiz?

Baseado em uma postagem que eu escrevi há muito tempo quando eu ainda poderia ser incomodado por blog.

Esta pergunta continua sendo feita repetidamente pelas vítimas de hackers que invadem seu servidor web. As respostas raramente mudam, mas as pessoas continuam perguntando. Não sei por quê. Talvez as pessoas simplesmente não gostem das respostas que viram ao procurar ajuda ou não consigam 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% de por que seu caso é especial e diferente das respostas que podem encontrar online e perdem 95% da pergunta e da resposta quando seu caso é quase o mesmo como aquele que lêem online.

Isso me leva à primeira informação importante. Eu realmente aprecio que você seja um floco de neve especial e único. Agradeço que o seu site também o seja, pois é um reflexo de você e da sua empresa ou, pelo menos, do seu trabalho árduo em nome de um empregador. Mas para alguém de fora olhando para dentro, seja um segurança de computador examinando o problema para tentar ajudá-lo ou até mesmo o próprio invasor, é muito provável que seu problema seja pelo menos 95% idêntico a todos os outros casos que ele tenha já olhou.

Não leve o ataque para o lado pessoal e não leve as recomendações que seguem aqui ou que você recebe de outras pessoas pessoalmente. Se você está lendo isto depois de se tornar vítima de um hack de site, eu realmente sinto muito e realmente espero que você possa encontrar algo útil aqui, mas este não é o momento para deixar seu ego atrapalhar o que você precisa Faz.

Você acabou de descobrir que seu (s) servidor (es) foram hackeados. E agora?

Não entrar em pânico. Absolutamente não aja com pressa e absolutamente não tente fingir que as coisas nunca aconteceram e não aja de forma alguma.

Primeiro: entenda que o desastre já aconteceu. Este não é o momento para negar; é a hora de aceitar o que aconteceu, de ser realista a respeito e tomar medidas para administrar as consequências do impacto.

Algumas dessas etapas vão doer, e (a menos que seu site tenha uma cópia dos meus dados) eu realmente não me importo se você ignorar todas ou algumas dessas etapas, mas fazer isso tornará as coisas melhores no final. O remédio pode ter um gosto horrível, mas às vezes é preciso ignorá-lo se realmente quiser que a cura funcione.

Impeça que o problema se torne pior do que já é:

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

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

Em alguns lugares, você pode muito bem ter uma exigência legal de informar as autoridades e/ou as vítimas desse tipo de violação de privacidade. Por mais irritados que seus clientes possam ficar por você lhes contar sobre um problema, eles ficarão muito mais irritados se você não contar a eles, e eles só descobrirão por si mesmos depois que alguém cobrar $ 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.

Compreenda o problema completamente:

1. NÃO coloque os sistemas afetados on-line novamente até que esse estágio esteja totalmente concluído, a menos que você queira ser a pessoa cuja postagem foi o ponto de inflexão para eu realmente decidir escrever este artigo. Não estou criando um link para o post para que as pessoas possam dar uma risada barata; Estou ligando para alertá-lo sobre as 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 que você entenda quais sistemas foram comprometidos no ataque. Certifique-se de seguir todas as dicas que sugerem que sistemas comprometidos podem se tornar um trampolim para atacar ainda mais seus sistemas.
4. Certifique-se de que os "gateways" usados ​​em todo e qualquer ataque sejam 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, então você não só precisa fechar a linha de código com falha específica que eles invadiram, você gostaria de auditar todo o seu código para ver 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 por meio da localização de um bug importante em um sistema, mas pela junção de vários problemas (às vezes menores e triviais por si mesmos) para comprometer um sistema. Por exemplo, usando ataques de injeção de SQL para enviar comandos a 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: "mais um dia no escritório aproveitando os erros comuns que as pessoas cometem".

Faça um plano para recuperação e para colocar seu site novamente online e cumpra-o:

Ninguém quer ficar offline por mais tempo do que o necessário. Isso é um dado adquirido. Se este site for um mecanismo de geração de receita, a pressão para colocá-lo online de volta rapidamente será intensa. Mesmo que a única coisa em jogo seja a reputação da sua empresa, isso ainda vai gerar muita pressão para colocar tudo de volta no lugar rapidamente.

No entanto, não ceda à tentação de voltar a ficar online muito rapidamente. Em vez disso, mova-se o mais rápido possível para entender o que causou o problema e resolvê-lo antes de voltar a ficar online ou então você quase certamente será vítima de uma intrusão mais uma vez, e lembre-se, "ser hackeado uma vez pode ser classificado como infortúnio; ser hackeado novamente logo depois parece descuido "(com desculpas a Oscar Wilde).

1. Presumo que você já tenha entendido todos os problemas que levaram à intrusão bem-sucedida antes mesmo de iniciar esta seção. Não quero exagerar, mas se você não fez isso primeiro, você realmente precisa. Desculpe.
2. Nunca pague chantagem/proteção dinheiro. Este é o sinal de uma marca fácil e você não quer que essa frase jamais seja usada para descrevê-lo.
3. Não fique tentado a colocar o (s) mesmo (s) servidor (es) online novamente sem uma reconstrução completa. Deve ser muito mais rápido construir uma nova caixa ou "tirar o servidor da órbita e fazer uma limpeza instalar "no hardware antigo do que auditar todos os cantos do sistema antigo para ter certeza de que está limpo antes de colocá-lo novamente online. Se você discordar disso, provavelmente não sabe o que realmente significa garantir que um sistema seja totalmente limpo ou os procedimentos de implantação de seu site são uma bagunça profana. Presumivelmente, você tem backups e implantações de teste do seu site que você pode usar apenas para construir o site ativo e, se não tiver, ser invadido não será seu maior problema.
4. Tenha muito cuidado ao reutilizar dados que estavam "ativos" no sistema no momento do hack. Não direi "nunca, jamais faça isso" porque você simplesmente me ignorará, mas, francamente, 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 restaurá-lo de um backup feito antes da intrusão. Se você não pode ou não quer fazer isso, deve ter muito cuidado com esses dados porque estão corrompidos. Você deve estar especialmente ciente das consequências para outras pessoas se esses dados pertencerem a clientes ou visitantes do site, e não diretamente a você.
5. Monitore o (s) sistema (s) cuidadosamente. Você deve decidir fazer isso como um processo contínuo no futuro (mais informações abaixo), mas se esforça para ficar atento durante o período imediatamente após o retorno do seu site online. Os intrusos quase certamente estarão de volta, e se você puder identificá-los tentando entrar novamente, certamente será capaz de ver rapidamente se você realmente fechou todos os buracos que eles usaram antes, mais os que eles fizeram para si próprios, e você pode achar útil informações que você pode repassar às autoridades locais.

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ê possa colocar algumas camadas sobre seu código depois como algo barato Pintura. Para ser devidamente 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. Eu percebo que é chato e você já ouviu isso antes e que eu "simplesmente não percebo a pressão cara" de colocar seu serviço beta web2.0 (beta) em status beta na web, mas o fato é que isso continua ficando repetido porque era verdade da primeira vez que foi dito e ainda não se tornou uma mentira.

Você não pode eliminar o risco. Você nem deveria tentar fazer isso. O que você deve fazer, entretanto, é 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 ocorrerá.

Quais etapas você pode realizar para reduzir a probabilidade de um ataque ser bem-sucedido?

Por exemplo:

1. A falha que permitiu 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 para corrigir aplicativos 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? Eu certamente não defendo a mudança de fornecedor sempre que algo assim o incomoda, porque todos eles têm seus problemas e você ficará sem plataformas em um ano, no máximo, se adotar essa abordagem. No entanto, se um sistema o deixa inativo constantemente, você deve migrar para algo mais robusto ou, pelo menos, refazer a arquitetura do sistema para que os componentes vulneráveis ​​fiquem embrulhados em algodão e o mais longe possível de olhos hostis.
3. A falha foi um bug no código desenvolvido por você (ou um empreiteiro trabalhando para você)? Em caso afirmativo, você precisa repensar sua abordagem de como aprova o código para implantação em seu site ativo? O bug pode ter sido detectado com um sistema de teste aprimorado ou com alterações em 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 de SQL bem-sucedido usando técnicas de codificação bem documentadas ).
4. A falha foi devido a um problema de como o servidor ou software de aplicativo foi implantado? Em caso afirmativo, você está usando procedimentos automatizados para construir e implantar servidores onde possível? Eles são uma grande ajuda para manter um estado consistente de "linha de base" em todos os seus servidores, minimizando a quantidade de trabalho personalizado que precisa ser feito em cada um e, portanto, minimizando a oportunidade de um erro ser cometido. 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 de seu aplicativo da web, tente automatizá-lo e garantir que sempre seja feito de maneira consistente.
5. A intrusão poderia ter sido detectada mais cedo com 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 que podem monitorar seus serviços de comunicação na web para você e alertá-lo em caso de um problema. Você pode decidir que não pode pagar por isso ou não precisa, 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 como usar algumas boas ferramentas de segurança adequadas ao seu ambiente, mantenha essas ferramentas atualizadas e use-as regularmente.
7. Considere a contratação de especialistas em segurança para 'auditar' a segurança do seu site regularmente. Novamente, você pode decidir que não pode pagar por isso ou não precisa, e tudo bem ... leve isso em consideração.

Quais etapas você pode realizar para reduzir as consequências de um ataque bem-sucedido?

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

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 seus serviços voltados para a Internet? Isso garante que, mesmo que seus sistemas externos sejam comprometidos, as chances de usar isso como um trampolim para atacar seus sistemas internos sejam limitadas.
2. Você está armazenando informações que não precisa armazenar? Você está armazenando essas informações "online" quando elas poderiam ser arquivadas em outro lugar? Existem dois pontos para esta parte; o óbvio é que as pessoas não podem roubar informações que você não tem, e o segundo ponto é que quanto menos você armazena, menos você precisa manter e codificar, e assim há menos chances de bugs entrarem seu código ou design de sistemas.
3. Você está usando os princípios de "menor acesso" para seu aplicativo da web? Se os usuários precisarem apenas ler de um banco de dados, certifique-se de que a conta que o aplicativo da web usa para fazer o serviço só tenha acesso de leitura, não permita acesso de gravação e certamente não acesso no nível do sistema.
4. Se você não tiver muita experiência em alguma coisa e não for essencial para o seu negócio, considere terceirizá-la. Em outras palavras, se você dirige um pequeno site que fala sobre escrever código de aplicativo de desktop e decide começar a vender pequenos aplicativos de desktop a partir do site, considere "terceirizar" seu sistema de pedidos de cartão de crédito para alguém como o Paypal.
5. Se possível, inclua a prática da recuperação de sistemas comprometidos em seu plano de recuperação de desastres. Este é, sem dúvida, apenas mais um "cenário de desastre" que você pode encontrar, simplesmente um com seu próprio conjunto de problemas e questões que são distintos do usual 'sala do servidor pegou fogo'/'foi invadida por servidor gigante comendo furbies'. (editar, por XTZ)

... E finalmente

Provavelmente, não deixei de fora coisas que outros consideram importantes, mas as etapas acima devem pelo menos ajudá-lo a começar a resolver as coisas se tiver o azar 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 detoná-lo 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 interna implícita. Confiar em um sistema comprometido é uma declaração implícita de que, para começar, você confia em quem quer que tenha violado o seu sistema. Em outras palavras:

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

Em termos práticos, a maioria das pessoas não o faz porque pensa que vai demorar muito ou ser muito perturbador. Já avisei inúmeros clientes sobre a probabilidade de problemas contínuos, mas uma reinstalação geralmente é rejeitada por um tomador de decisões por um desses motivos.

Dito isso, em sistemas onde estou confiante de que conheço o método de entrada e toda a extensão do dano (registros sólidos fora da máquina, normalmente com um IDS, talvez SELinux ou algo semelhante limitando o escopo da intrusão), eu fez uma limpeza sem reinstalar sem se sentir muito culpado.

Provavelmente eles não têm uma rotina de recuperação de desastres testada o suficiente para que se sintam confiantes em fazer 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. Posso pensar em muitos motivos.

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

Eu não nunquei previamente o sistema para que eu pudesse fazer alguma análise do vetor em que eles entraram e uma análise subsequente do uso e para ver onde eles entraram.

Depois de fazer o root - você tem um honeypot ativo e ele pode oferecer muito mais do que apenas hackear. - especialmente para a polícia.

• dito isso, fui pré-avaliado para conseguir obter um sistema limpo em stand-by e oferecer segurança de rede aprimorada e rápida para isolar a caixa com acesso root.