Dicas para assumir o controle de um servidor de produção (UNIX)

Question

Após meses de negligência, ataques a e-mails e batalhas de gerenciamento, nosso administrador de sistema atual foi demitido e passou "as credenciais do servidor" para mim. Tais credenciais consistem em uma senha root e nada mais: sem procedimentos, sem documentação, sem dicas, sem nada.

A minha pergunta é: supondo que ele tenha deixado boobytraps para trás, como posso assumir os servidores com o menor tempo de inatividade possível?

Aqui estão os detalhes:

• um servidor de produção localizado em um farm de servidores no porão; servidor ubuntu 9.x provavelmente, com patches grsec (rumores que ouvi da última vez perguntei ao admin)
• um servidor interno que contém toda a documentação interna, repositório de arquivos, wikis etc. Novamente, o servidor Ubuntu, alguns anos atrás.

Suponha que ambos os servidores estejam com patches e atualizados, então prefiro não tentar entrar a menos que haja uma boa razão (isto é, isso pode ser explicado à gerência superior).

O servidor de produção tem alguns sites hospedados (apache-php-mysql padrão), um servidor LDAP, um conjunto de e-mail / servidor ZIMBRA e, até onde posso dizer, algumas estações de trabalho vmware em execução. Não faço ideia do que está acontecendo lá. Provavelmente, um é o mestre LDAP, mas isso é um palpite.

O servidor interno possui um wiki / cms interno, um escravo do LDAP que replica as credenciais do servidor de produção, algumas estações de trabalho mais vmware e backups em execução.

Eu poderia simplesmente ir ao administrador do farm de servidores, apontar para o servidor, dizer ' sudo desligar o servidor, por favor', fazer o login no modo de usuário único e fazer o meu caminho com ele. O mesmo para o servidor interno. Ainda assim, isso significaria tempo de inatividade, transtornos da alta gerência, o velho administrador de sistemas voltando para mim dizendo 'ver? você não pode fazer o meu trabalho "e outros incômodos, e mais importante, eu teria que perder potencialmente algumas semanas de tempo não remunerado.

No outro extremo do espectro, eu poderia fazer login como root e avançar pelo servidor para tentar entender o que está acontecendo. Com todos os riscos de provocar surpresas deixadas para trás.

Estou procurando uma solução no meio: tente manter tudo funcionando como está, ao mesmo tempo em que entende o que está acontecendo e como e, o mais importante, evitando disparar quaisquer armadilhas deixadas para trás .

Quais são as suas sugestões?

Até agora, pensei em "praticar" com o servidor interno, desconectar a rede, reinicializar com um live cd, colocar o sistema de arquivos raiz em uma unidade USB e carregá-lo em uma máquina virtual isolada e desconectada para entender a antiga modo de pensar do sysadmin (a-la 'conhece o seu inimigo'). Poderia puxar o mesmo feito com o servidor de produção, mas um despejo completo faria alguém perceber. Talvez eu possa fazer o login como root, verificar o crontab, verificar o .profile para quaisquer comandos que forem iniciados, descarregar o lastlog e o que vier à mente.

E é por isso que estou aqui. Qualquer dica, por menor que seja, seria muito apreciada.

O tempo também é um problema: pode haver gatilhos acontecendo em algumas horas ou algumas semanas. Parece um daqueles filmes ruins de Hollywood, não é?

    

Answer 1

Como outros já disseram, parece uma situação solta.

(começando no final)

• Implantação completamente nova

Claro que você não pode simplesmente derrubar os servidores e deixar que o instalador faça isso.

Processo Geral

• Obtenha orçamento para um servidor de backup (backup como no armazenamento dos dados)
• crie instantâneos dos dados e coloque-os antes de fazer qualquer coisa
• Solicite a assinatura pela gerência!
• Reúna uma lista de requisitos (é o wiki necessário, quem está usando as instâncias do VMWare, ...)
  • Da gestão e
  • De usuários
• Solicite a assinatura pela gerência!
• Encerre serviços não listados por uma semana (um serviço de cada vez - o iptables pode ser seu amigo se você quiser apenas desligar serviços externos, mas suspeitar que ainda pode ser usado de um aplicação no mesmo host)
  • Nenhuma reação? - > backup final, remova do servidor
  • Reação? - > Fale com os usuários do serviço
  • Reunir novos requisitos e Geet assinados pela gerência!
• todos os serviços não listados por um mês e sem reação? - > rm -rf $service (parece harsch mas o que quero dizer é decommission the service)
• obtenha orçamento para um servidor sobressalente
• migrar um serviço de cada vez para o sobressalente
• obtenha a assinatura da gerência!
• encerre o servidor migrado (sem energia)
• descubra mais pessoas vêm gritando com você - > yay, você acabou de encontrar as sobras
• coletar novos requisitos
• inicie novamente e migre os serviços
• repita os últimos 4 passos até que não haja pessoas chegando depois de você por um mês
• reimplanta o servidor (e obtém isso assinado pelo gerenciamento!)
• enxágüe e repita todo o processo.
  • o servidor reimplementado é seu novo sobressalente

O que você ganhou?

• Inventário de todos os serviços (para você e gerenciamento)
• Documentação (afinal, você precisa escrever algo para o gerenciamento, porque não fazê-lo corretamente e fazer algo para você e para o gerenciamento)

Já foi feito isso, não é nada divertido: (

Por que você precisa assiná-lo pela gerência ?

• Torne os problemas visíveis
• Certifique-se de não ser demitido
• Oportunidade de explicar riscos
  • Tudo bem se eles não quiserem que você faça isso, mas, afinal de contas, é uma decisão deles tomar depois que eles tiverem informações suficientes para julgar se o investimento vale a pena.

Ah, e apresente o plano geral para eles antes de começar , com algumas estimativas sobre o que acontecerá no pior e melhor dos casos.

O irá custar muito tempo, independentemente de reimplementação, se você não tiver documentação. Não há necessidade de pensar em backdoors, IMHO, se você não tiver documentação, uma migração contínua é a única maneira de alcançar um estado sã que agregue valor para a empresa.

    

Answer 2

Você tem motivos para acreditar que o administrador anterior deixou algo ruim para trás ou assiste a muitos filmes?

Eu não estou pedindo para ser brincalhão, estou tentando ter uma idéia do tipo de ameaça que você acha que está lá e como isso é provável. Se você acha que as chances são realmente muito altas de que algum tipo de problema seriamente perturbador possa realmente existir, então sugiro tratá-lo como se fosse uma intrusão de rede bem-sucedida .

Em qualquer caso, seus chefes não querem a interrupção do tempo de inatividade enquanto você lida com isso - qual é a atitude deles em relação ao tempo de inatividade planejado para sistemas arrumados vs. inatividade não planejada se houver uma falha no sistema? falha ou um administrador desonesto) e se a atitude deles é realista versus sua avaliação da probabilidade de você realmente ter um problema aqui.

Independentemente do que você fizer, considere o seguinte:

Tire uma imagem dos sistemas agora agora . Antes de fazer qualquer outra coisa. De fato, pegue dois e coloque um deles de lado e não o toque novamente até que você saiba o que está acontecendo com o seu sistema, esse é o registro de como o sistema estava quando você assumiu o controle.

Restaure o "segundo" conjunto de imagens para algumas máquinas virtuais e use-as para investigar o que está acontecendo. Se você está preocupado com o fato de as coisas serem acionadas após uma determinada data, defina a data de um ano ou mais na máquina virtual.

    

Answer 3

Primeiro de tudo, se você vai investir tempo extra nisso, eu aconselho que você realmente seja pago por isso. Parece que você aceitou as horas extras não pagas como um fato, a julgar pelas suas palavras - não deveria ser assim, na minha opinião, e especialmente quando você está com tanta dificuldade por causa da culpa de outra pessoa (seja de gerenciamento, o antigo sysadmin ou provavelmente uma combinação de ambos).

Retire os servidores e inicialize no modo de usuário único (init = / bin / sh ou 1 no grub) para verificar os comandos que são executados no login do root. O tempo de inatividade é necessário aqui, deixe claro para a gerência que não há escolha além de algum tempo de inatividade, se eles quiserem ter certeza de que conseguirão manter seus dados.

Depois, examine todos os cronjobs, mesmo que pareçam legítimos. Também execute backups completos o mais rápido possível - mesmo que isso signifique tempo de inatividade. Você pode transformar seus backups completos em VMs em execução, se quiser.

Então, se você conseguir colocar novos servidores ou VMs capazes, migraria os serviços para ambientes novos e limpos, um por um. Você pode fazer isso em vários estágios para minimizar o tempo de inatividade percebido. Você vai ganhar muito conhecimento profundo dos serviços enquanto restaura sua confiança nos sistemas básicos.

Enquanto isso, você pode verificar os rootkits usando ferramentas como chkrootkit . Execute nessus nos servidores para procurar falhas de segurança que o antigo administrador possa usar.

Edit: Eu acho que não abordou a parte "graciosa" da sua pergunta tão bem quanto eu pude. A primeira etapa (entrar no modo de usuário único para verificar traps de login) provavelmente pode ser ignorada - o sysadmin antigo dando a senha de root e configurando o login para fazer um rm -rf / seria praticamente o mesmo que excluir todos os arquivos , então provavelmente não há sentido em fazer isso. De acordo com a parte de backup: tente usar uma solução baseada em rsync para que você possa fazer a maior parte do backup inicial on-line e minimizar o tempo de inatividade.

    

Answer 4

Eu investirei tempo em aprender quais apps são executados nesses servidores. Depois que você sabe o que é o que a qualquer momento você pode instalar um novo servidor. Caso você sinta que pode haver algum backdoor, será uma boa ideia Basta inicializar no modo único ou ter algum firewall entre os servidores e A rede externa.

    

Answer 5

Você está ficando paranoico com a segurança. Não há necessidade de ficar paranóico. (você fala sobre armadilhas). Percorra a lista de softwares instalada. Veja o que é o serviço em execução (netstat, ps, etc), veja trabalhos cron. Desative a conta de usuário anterior do administrador sem excluir a conta (facilmente apontando o shell para nologin). Veja através dos arquivos de log. Eu acho que com estes passos e com o seu conhecimento das necessidades da empresa, do qual você pode adivinhar o uso dos servidores, eu acho que você deve ser capaz de mantê-los sem grandes problemas.