Esta é uma pergunta canônica sobre segurança do servidor - Respondendo a eventos de violação (hackers)
Veja também:

• Dicas para proteger um servidor LAMP
• Reinstalar após um comprometimento raiz?

Versão canônica
Suspeito que um ou mais dos meus servidores estejam comprometidos por um hacker, vírus ou outro mecanismo:

• Quais são os meus primeiros passos? Quando chego ao local, devo desconectar o servidor, preservar "evidências", existem outras considerações iniciais?
• Como faço para obter serviços online novamente?
• Como evito que a mesma coisa aconteça imediatamente novamente?
• Existem boas práticas ou metodologias para aprender com esse incidente?
• Se eu quisesse montar um plano de resposta a incidentes, por onde começaria? Isso deve fazer parte do meu planejamento de recuperação de desastres ou de continuidade de negócios?

Versão original

01.01.2011 - Estou a caminho do trabalho às 21h30 de domingo, porque nosso servidor foi comprometido de alguma forma e estava resultando em um ataque do DOS ao nosso provedor. Os servidores que acessam a Internet foram encerrados, o que significa que mais de 5 a 600 sites de nossos clientes estão desativados. Agora, isso pode ser um hack de FTP ou alguma fraqueza no código em algum lugar. Não tenho certeza até chegar lá.

Como posso rastrear isso rapidamente? Estamos em processo judicial se eu não conseguir o backup do servidor o mais rápido possível. Qualquer ajuda é apreciada. Estamos executando o Open SUSE 11.0.

---

01.01.2011 - Obrigado a todos pela ajuda. Felizmente, eu não era a única pessoa responsável por este servidor, apenas a mais próxima. Conseguimos resolver esse problema, embora ele não se aplique a muitos outros em uma situação diferente. Vou detalhar o que fizemos.

Desconectamos o servidor da rede. Ele estava executando (tentando executar) um ataque de Negação de Serviço em outro servidor na Indonésia, e a parte culpada também estava lá.

Primeiramente, tentamos identificar de onde vinha o servidor, considerando que possuímos mais de 500 sites no servidor, esperávamos estar fazendo luar por algum tempo. No entanto, com o acesso SSH ainda, executamos um comando para encontrar todos os arquivos editados ou criados no momento em que os ataques começaram. Felizmente, o arquivo incorreto foi criado durante as férias de inverno, o que significava que não havia muitos outros arquivos criados no servidor naquele momento.

Fomos capazes de identificar o arquivo incorreto que estava dentro da pasta de imagens carregadas em um site ZenCart .

Após uma pequena pausa para o cigarro, concluímos que, devido à localização dos arquivos, ele deve ter sido carregado por meio de uma instalação de upload de arquivos que não estava protegida adequadamente. Depois de pesquisar no Google, descobrimos que havia uma vulnerabilidade de segurança que permitia o upload de arquivos, dentro do painel de administração do ZenCart, para uma foto de uma gravadora. (A seção que ele realmente nunca usou), postar este formulário acabou de carregar qualquer arquivo, não verificou a extensão do arquivo e nem verificou se o usuário estava logado.

Isso significava que qualquer arquivo poderia ser carregado, incluindo um arquivo PHP para o ataque. Protegemos a vulnerabilidade com o ZenCart no site infectado e removemos os arquivos incorretos.

O trabalho foi feito e eu estava em casa por duas horas da manhã.

---

O moral - Sempre aplique patches de segurança no ZenCart ou em qualquer outro sistema CMS. Como quando as atualizações de segurança são lançadas, o mundo inteiro fica ciente da vulnerabilidade. - Sempre faça backups e faça backup dos seus backups. - Empregue ou providencie alguém que estará presente em momentos como este. Para impedir que alguém confie em uma postagem em apuros no Server Fault.

É difícil dar conselhos específicos sobre o que você postou aqui, mas eu tenho alguns conselhos genéricos com base em um post que escrevi há muito tempo, quando ainda podia me incomodar no blog.

Não entre em pânico

Primeiramente, não há "soluções rápidas" além de restaurar o sistema a partir de um backup feito antes da invasão, e isso tem pelo menos dois problemas.

1. É difícil identificar quando a invasão aconteceu.
2. Isso não ajuda a fechar o "buraco" que lhes permitiu romper na última vez, nem lidar com as consequências de qualquer "roubo de dados" que também possa ter ocorrido.

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 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 que você é 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 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ê ignorar todas ou algumas dessas etapas, isso é com você. Mas segui-los adequadamente fará as coisas melhor 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 possuir dados pessoais de alguém, informe imediatamente a pessoa responsável pela proteção de dados (se não for você) e EXIGE uma divulgação completa. Eu sei que este é difícil. Eu sei que este vai doer. Sei que muitas empresas querem varrer esse tipo de problema para baixo do tapete, mas a empresa terá que lidar com isso - e precisa fazê-lo de olho em todas e quaisquer leis de privacidade relevantes.

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. Não vou criar um link para esse post para que as pessoas possam ter uma risada barata, mas a verdadeira tragédia é quando as pessoas deixam de aprender com seus erros.
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. Verifique se você segue 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".

Por que não apenas "reparar" a exploração ou o rootkit que você detectou e colocar o sistema novamente online?

Em situações como essa, o problema é que você não tem mais controle desse sistema. Não é mais o seu computador.

A única maneira de ter certeza de que você tem o controle do sistema é reconstruí-lo. Embora exista muito valor em encontrar e corrigir a exploração usada para invadir o sistema, você não pode ter certeza do que mais foi feito no sistema depois que os invasores ganharam o controle (na verdade, isso não é inédito para hackers que recrutam sistemas em uma botnet para corrigir as explorações que eles mesmos usavam, para proteger "seu" novo computador de outros hackers, além de instalar seu rootkit).

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 é 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 com a reutilização de 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 pode ou não fará isso, deve ter 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, e isso é bom ... basta levar 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 seu 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 podem 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.

... E finalmente

Provavelmente não deixei de lado as coisas que os outros consideram importantes, mas as etapas acima devem pelo menos ajudá-lo a resolver as coisas se você tiver azar o suficiente para 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.

Parece que estão um pouco acima da sua cabeça; isso está ok. Ligue para o seu chefe e comece a negociar um orçamento de resposta de segurança de emergência. US $ 10.000 podem ser um bom lugar para começar. Então você precisa contratar alguém (PFY, colega de trabalho, gerente) para começar a ligar para empresas especializadas em resposta a incidentes de segurança. Muitos podem responder dentro de 24 horas e, às vezes, mais rapidamente se tiverem um escritório em sua cidade.

Você também precisa de alguém para triar clientes; Sem dúvida, alguém já é. Alguém precisa estar ao telefone com ela para explicar o que está acontecendo, o que está sendo feito para lidar com a situação e para responder às suas perguntas.

Então, você precisa ...

1. Fique calmo. Se você é responsável pela resposta a incidentes, o que você faz agora precisa demonstrar o máximo de profissionalismo e liderança. Documente tudo o que faz e mantenha seu gerente e equipe executiva informados sobre as principais ações que você executa; isso inclui trabalhar com uma equipe de resposta, desativar servidores, fazer backup de dados e colocar as coisas online novamente. Eles não precisam de detalhes sangrentos, mas devem receber notícias suas a cada 30 minutos.

2. Seja realista. Você não é um profissional de segurança e há coisas que não sabe. Isso está ok. Ao efetuar login nos servidores e analisar os dados, você precisa entender seus limites. Pise suavemente. No decorrer de sua investigação, certifique-se de não pisar em informações vitais ou alterar algo que possa ser necessário posteriormente. Se você se sente desconfortável ou está adivinhando, é um bom lugar para parar e contratar um profissional experiente.

3. Obtenha um pendrive USB limpo e poupe discos rígidos. Você coletará evidências aqui. Faça backups de tudo que você achar relevante; comunicação com seu provedor de serviços de Internet, despejos de rede, etc. Mesmo que a aplicação da lei não se envolva, no caso de uma ação judicial, você precisará dessas evidências para provar que sua empresa lidou com o incidente de segurança de maneira profissional e apropriada.

4. O mais importante é parar a perda. Identifique e corte o acesso a serviços, dados e máquinas comprometidos. De preferência, você deve puxar o cabo de rede; se não puder, puxe a força.

5. Em seguida, você precisa remover o atacante e fechar o (s) buraco (s). Presumivelmente, o invasor não tem mais acesso interativo porque você puxou a rede. Agora você precisa identificar, documentar (com backups, capturas de tela e suas próprias observações pessoais de observação; ou, de preferência, remover as unidades dos servidores afetados e fazer uma cópia completa da imagem do disco) e remover qualquer código e processo que ele tenha deixado para trás . Esta próxima parte será péssima se você não tiver backups; Você pode tentar desembaraçar o atacante do sistema manualmente, mas nunca terá certeza de que conseguiu tudo o que ele deixou para trás. Os rootkits são cruéis e nem todos são detectáveis. A melhor resposta será identificar a vulnerabilidade que ele usou para entrar, fazer cópias de imagens dos discos afetados e, em seguida, limpar os sistemas afetados e recarregar a partir de um bom backup conhecido. Don ' t confiar cegamente em seu backup; verifique! Repare ou feche a vulnerabilidade antes que o novo host entre na rede novamente e coloque-a online.

6. Organize todos os seus dados em um relatório. Neste ponto, a vulnerabilidade está fechada e você tem algum tempo para respirar. Não fique tentado a pular esta etapa; é ainda mais importante que o resto do processo. No relatório, você precisa identificar o que deu errado, como sua equipe respondeu e as etapas que você está tomando para impedir que esse incidente ocorra novamente. Seja o mais detalhado que consequir; isso não é apenas para você, mas para sua gerência e como defesa em um potencial processo.

Essa é uma revisão altíssima do que fazer; a maior parte do trabalho é simplesmente documentação e manipulação de backup. Não entre em pânico, você pode fazer essas coisas. Eu recomendo fortemente que você obtenha ajuda profissional de segurança. Mesmo se você puder lidar com o que está acontecendo, a ajuda deles será inestimável e eles geralmente vêm com equipamentos para tornar o processo mais fácil e rápido. Se seu chefe recusar o preço, lembre-o de que é muito pequeno quando comparado a lidar com uma ação judicial.

Você tem meus consolos pela sua situação. Boa sorte.

O CERT possui um documento Etapas para recuperação de um comprometimento do sistema UNIX ou NT que é bom. Os detalhes técnicos específicos deste documento estão um pouco desatualizados, mas muitas recomendações gerais ainda se aplicam diretamente.

Um rápido resumo das etapas básicas é este.

• Consulte sua política ou gerenciamento de segurança.
• Obtenha controle (coloque o computador offline)
• Analise a intrusão, obtenha logs, descubra o que deu errado
• Reparar coisas
  • Instale uma versão limpa do seu sistema operacional !!! Se o sistema foi comprometido, você não pode confiar nele, ponto final.
• Atualize os sistemas para que isso não aconteça novamente
• Retomar operações
• Atualize sua política para o futuro e documente

Gostaria de apontar especificamente para a seção E.1.

E.1 Lembre-se de que, se uma máquina estiver comprometida, qualquer coisa nesse sistema poderá ter sido modificada, incluindo o kernel, binários, arquivos de dados, processos em execução e memória. Em geral, a única maneira de confiar que uma máquina está livre de backdoors e modificações de invasores é reinstalar o sistema operacional.

Se você ainda não possui um sistema como o tripwire, não há como ter 100% de certeza de que limpou o sistema.

1. Identifique o problema. Leia os logs.
2. Conter . Você desconectou o servidor, e pronto.
3. Erradicar . Reinstale o sistema afetado, provavelmente. Não apague o disco rígido do pirateado, use um novo. É mais seguro, e você pode precisar do antigo para recuperar hackers feios que não foram salvos em backup e fazer perícia para descobrir o que aconteceu.
4. Recuperar . Instale o que for necessário e recupere backups para colocar seus clientes online.
5. Acompanhamento . Descubra qual era o problema e evite que isso aconteça novamente.

A resposta da pílula amarga de Robert é direta, mas completamente genérica (bem, como foi sua pergunta). Parece que você tem um problema de gerenciamento e precisa urgentemente de um administrador de sistema em tempo integral, se tiver um servidor e 600 clientes, mas isso não ajuda você agora.

Eu administro uma empresa de hospedagem que fornece um pouco de paciência nessa situação, por isso lida com muitas máquinas comprometidas, mas também lida com as melhores práticas. Sempre solicitamos que nossos clientes comprometidos sejam reconstruídos, a menos que não tenham certeza absoluta da natureza de um compromisso. Não há outra via responsável a longo prazo.

No entanto, você quase certamente é vítima de um script kiddy que queria uma plataforma de lançamento para ataques de negação de serviço, seguranças de IRC ou algo completamente não relacionado aos sites e dados de seus clientes. Portanto, como uma medida temporária durante a reconstrução, considere a criação de um firewall de saída pesado em sua caixa. Se você pode bloquear todas as conexões UDP e TCP de saída que não são absolutamente necessárias para o funcionamento dos sites, você pode facilmente tornar sua caixa comprometida inútil para quem a está emprestando de você e reduzir o efeito na rede do seu provedor para zero.

Esse processo pode levar algumas horas se você não tiver feito isso antes e nunca considerou um firewall, mas pode ajudá-lo a restaurar o serviço de seus clientes com o risco de continuar a fornecer ao invasor acesso aos dados de seus clientes . Como você diz que possui centenas de clientes em uma máquina, acho que você está hospedando pequenos sites de folhetos para pequenas empresas, e não 600 sistemas de comércio eletrônico cheios de números de cartão de crédito. Se for esse o caso, isso pode ser um risco aceitável para você e volte a colocar o seu sistema on-line mais rápido do que auditar 600 sites em busca de bugs de segurança antes de recuperar qualquer coisa. Mas você saberá quais dados existem e como você se sentiria confortável em tomar essa decisão.

Isso absolutamente não é uma prática recomendada, mas se não é o que está acontecendo com seu empregador até agora, abanando o dedo para ele e pedindo dezenas de milhares de libras para uma equipe da SWAT por algo que eles acham que é sua culpa (por mais injustificada que seja!) ) não parece a opção prática.

A ajuda do seu ISP aqui será bastante crucial - alguns ISPs fornecem um servidor de console e um ambiente de inicialização de rede (plug, mas pelo menos você sabe que tipo de instalação procurar) que permitirá administrar o servidor enquanto estiver desconectado da rede. Se isso for uma opção, peça e use-a.

Mas, a longo prazo, você deve planejar uma reconstrução do sistema com base na postagem de Robert e uma auditoria de cada site e sua configuração. Se você não conseguir adicionar um administrador de sistemas à sua equipe, procure um acordo de hospedagem gerenciada em que pague ao seu ISP por ajuda de administrador de sistemas e resposta em 24 horas por esse tipo de coisa. Boa sorte :)

Você precisa reinstalar. Salve o que você realmente precisa. Mas lembre-se de que todos os seus arquivos executáveis ​​podem estar infectados e violados. Eu escrevi o seguinte em python: http://frw.se/monty.py, que cria MD5-sumbs de todos os seus arquivos em um determinado diretório e na próxima vez em que você o executa, ele verifica se alguma coisa foi alterada e depois produz o que arquivos alterados e o que mudou nos arquivos.

Isso pode ser útil para você, para ver se arquivos estranhos são alterados regularmente.

Mas a única coisa que você deve fazer agora é remover o computador da Internet.

NOTA: Esta não é uma recomendação. Meu protocolo específico de resposta a incidentes provavelmente não se aplica não modificado ao caso de Grant unwin.

Em nossas instalações acadêmicas, temos cerca de 300 pesquisadores que apenas fazem computação. Você tem 600 clientes com sites, portanto seu protocolo provavelmente será diferente.

As primeiras etapas em Quando um servidor fica comprometido é:

1. Identifique que o invasor conseguiu obter root (privilégios elevados)
2. Desconecte os servidores afetados. Rede ou energia? Por favor, veja uma discussão em separado .
3. Verifique todos os outros sistemas
4. Inicialize os servidores afetados a partir de um CD ao vivo
5. (opcional) Pegue as imagens de todas as unidades do sistema comdd

6. Comece a fazer a perícia post-mortem. Veja os logs, descubra a hora do ataque, encontre os arquivos que foram modificados naquele momento. Tente responder a Como? Pergunta, questão.

   • Paralelamente, planeje e execute sua recuperação.
   • Redefina todas as senhas de usuário e raiz antes de continuar o serviço

Mesmo se "todas as backdoors e rootkits forem limpos", não confie nesse sistema - reinstale a partir do zero.

Na minha experiência limitada, os compromissos do sistema no Linux tendem a ser mais "abrangentes" do que no Windows. É muito mais provável que os kits raiz incluam a substituição de binários do sistema por código personalizado para ocultar o malware, e a barreira para aplicar hot patch no kernel é um pouco menor. Além disso, é o sistema operacional doméstico de muitos autores de malware. A orientação geral é sempre recriar o servidor afetado do zero e é a orientação geral por um motivo.

Formate esse cachorro.

Mas, se você não pode reconstruir (ou os futuros poderes não o deixarão reconstruir contra sua insistência extenuante de que precisa), o que procura?

Como parece que já faz um tempo desde que a intrusão foi descoberta e uma restauração do sistema foi feita, é muito provável que os vestígios de como eles entraram tenham sido pisoteados no tumulto para restaurar o serviço. Infeliz.

O tráfego de rede incomum é provavelmente o mais fácil de encontrar, pois isso não envolve a execução de nada na caixa e pode ser feito enquanto o servidor estiver ativo e fazendo o que for. Presumindo, é claro, que seu equipamento de rede permita a expansão de portas. O que você encontra pode ou não ser diagnóstico, mas pelo menos são informações. Obter tráfego incomum será uma forte evidência de que o sistema ainda está comprometido e precisa ser nivelado. Pode ser bom o suficiente para convencer o TPTB de que uma reformatação realmente vale a pena o tempo de inatividade.

Caso contrário, faça uma cópia em dd das partições do sistema e monte-as em outra caixa. Comece a comparar o conteúdo com um servidor no mesmo nível de patch que o comprometido. Isso deve ajudá-lo a identificar o que parece diferente (esses md5sums novamente) e pode apontar para áreas negligenciadas no servidor comprometido. Isso é muito para filtrar diretórios e binários, e será bastante trabalhoso. Pode até ser mais trabalhoso do que uma reformatação / reconstrução seria, e pode ser outra coisa a ser discutida no TPTB sobre realmente fazer a reformatação de que realmente precisa.

Eu diria que @Robert Moir, @Aleksandr Levchuk, @blueben e @Matthew Bloch são todos bastante destacados em suas respostas.

No entanto, as respostas de diferentes pôsteres diferem - algumas são de alto nível e falam sobre os procedimentos que você deve adotar (em geral).

Eu preferiria separar isso em várias partes separadas 1) Triagem, AKA Como lidar com os clientes e as implicações legais, e identificar para onde ir (Listado muito bem por Robert e @blueben 2) Mitigação do impacto 3 ) Resposta a incidentes 4) Análise forense post mortem 5) Itens de correção e mudanças na arquitetura

(Insira aqui a declaração de resposta certificada SANS GSC padrão). Com base em experiências anteriores, eu diria o seguinte:

Independentemente de como você lida com as respostas, notificações, planos legais e futuros do cliente, eu preferiria me concentrar no principal problema em questão. A questão original do OP realmente diz respeito apenas aos itens 2 e 3, basicamente, como interromper o ataque, colocar os clientes on-line o mais rápido possível no estado original, o que foi bem abordado nas respostas.

O restante das respostas é excelente e abrange muitas das melhores práticas identificadas e maneiras de impedir que isso aconteça no futuro e de responder melhor a elas.

Realmente depende do orçamento do OP e em que setor da indústria eles estão, qual é a solução desejada etc.

Talvez eles precisem contratar uma SA dedicada no local. Talvez eles precisem de uma pessoa de segurança. Ou talvez eles precisem de uma solução totalmente gerenciada, como Firehost ou Rackspace Managed, Softlayer, ServePath etc.

Realmente depende do que funciona para os seus negócios. Talvez a competência principal deles não esteja no gerenciamento de servidores e não faça sentido para eles tentarem desenvolver isso. Ou talvez eles já sejam uma organização bastante técnica e possam tomar as decisões corretas de contratação e contratar uma equipe dedicada em período integral.

Depois de começar a trabalhar e dar uma olhada no servidor, conseguimos descobrir o problema. Felizmente, os arquivos incorretos foram carregados no sistema em um domingo, quando o escritório está fechado e nenhum arquivo deve ser criado, além dos logs e arquivos de cache. Com um simples comando de shell para descobrir quais arquivos foram criados naquele dia, nós os encontramos.

Todos os arquivos ofensivos parecem estar dentro da pasta / images / em alguns de nossos sites mais antigos do zencart. Parece que havia uma vulnerabilidade de segurança que permitia (usando curl) qualquer idiota fazer upload de não imagens na seção de upload de imagens na seção admin. Excluímos os arquivos .php ofensivos e corrigimos os scripts de upload para proibir o upload de arquivos que não sejam imagens.

Em retrospecto, era bastante simples e levantei essa questão no meu iPhone no caminho para o trabalho. Obrigado por toda a sua ajuda pessoal.

Para referência de qualquer pessoa que visite este post no futuro. Eu não recomendaria puxar o plugue de energia.

Tenho pouco a contribuir com as extensas respostas técnicas, mas observe também algumas delas:

Ações não técnicas:

• Relate o incidente internamente.
  Se você ainda não possui um plano de resposta a incidentes que possa parecer uma técnica de CYA, mas o departamento de TI não é o único e muitas vezes nem o melhor lugar para determinar o impacto comercial de um servidor comprometido.
  Os requisitos comerciais podem superar suas preocupações técnicas. Não diga "eu te disse" e que a prioridade das preocupações dos negócios é a razão pela qual você está tendo esse servidor comprometido em primeiro lugar. (" Deixe isso para o relatório pós-ação. ")

• Encobrir um incidente de segurança não é uma opção.

• Reportando-se às autoridades locais.
  ServerFault NÃO é o local para aconselhamento jurídico, mas isso é algo que deve ser incluído em um plano de resposta a incidentes.
  Em algumas localidades e / ou setores regulamentados, é obrigatório relatar (certos) incidentes de segurança às autoridades policiais locais, órgãos reguladores ou para informar clientes / usuários afetados.
  Independentemente disso, nem a decisão de relatar nem o relatório real são feitos apenas no departamento de TI. Espere o envolvimento da gerência e dos departamentos de comunicação jurídica e corporativa (marketing).
  Você provavelmente não deve esperar muito, a Internet é um lugar grande onde as fronteiras têm pouco significado, mas os departamentos de crimes cibernéticos que existem em muitos departamentos de polícia resolvem crimes digitais e podem levar os culpados à justiça.

Eu acho que tudo se resume a isso:

Se você valoriza seu trabalho, é melhor ter um plano e revisá-lo regularmente.

Deixar de planejar é planejar falhar, e não é mais verdadeiro em nenhum outro lugar senão na segurança dos sistemas. Quando <redacted> atinge o ventilador, é melhor você estar pronto para lidar com isso.

Há outro (um pouco clichê) dizendo que se aplica aqui: Prevenir é melhor que remediar .

Houve várias recomendações aqui para obter especialistas para auditar seus sistemas existentes. Eu acho que isso está fazendo a pergunta na hora errada. Esta pergunta deveria ter sido feita quando o sistema foi implantado e as respostas documentadas. Além disso, a pergunta não deve ser "Como podemos impedir que as pessoas invadam?" Deveria ser "Por que as pessoas deveriam ser capazes de invadir?" A auditoria de vários buracos na sua rede funcionará apenas até que novos buracos sejam encontrados e explorados. Por outro lado, redes projetadas desde o início para responder apenas de certas maneiras a determinados sistemas em uma dança cuidadosamente coreografada não se beneficiarão de nenhuma auditoria e os fundos serão um desperdício.

Antes de colocar um sistema na Internet, pergunte a si mesmo - isso precisa ser 100% voltado para a Internet? Se não, não. Considere colocá-lo atrás de um firewall onde você pode decidir o que a internet vê. Melhor ainda, se o firewall permitir interceptar as transmissões (por meio de um proxy reverso ou de algum tipo de filtro de passagem), use-o para permitir que apenas ações legítimas ocorram.

Isso foi feito - existe (ou houve) uma configuração de Internet banking em algum lugar que possui um proxy de balanceamento de carga voltado para a Internet que eles usariam para vetorizar ataques de seu pool de servidores. O especialista em segurança Marcus Ranum os convenceu a adotar a abordagem oposta, usando o proxy reverso para permitir que apenas URLs válidas conhecidas passem e enviem todo o resto para um servidor 404 . Ele resistiu ao teste do tempo surpreendentemente bem.

Um sistema ou rede baseado em permissão padrão está fadado a falhar quando um ataque que você não previu acontecer. A negação padrão fornece um controle muito maior sobre o que entra e o que não entra, porque você não permitirá que nada do lado de dentro seja visto de fora, a menos que seja necessário .

Dito isto, tudo isso não é motivo para ficar complacente. Você ainda deve ter um plano em prática nas primeiras horas após uma violação. Nenhum sistema é perfeito e os humanos cometem erros.

Um bom onliner me ajudou recentemente a descobrir como um invasor poderia comprometer um sistema. Alguns crackers tentam ocultar seus rastros forjando o tempo de modificação nos arquivos. Alterando a hora da modificação, a hora da alteração é atualizada (ctime). você pode ver o ctime com stat.

Este liner lista todos os arquivos classificados por ctime:

find / -type f -print0 | xargs -0 stat --format '%Z :%z %n' | sort -nr > /root/all_files.txt

Portanto, se você souber aproximadamente a hora do compromisso, poderá ver quais arquivos foram alterados ou criados.