Como você pesquisa backdoors da pessoa de TI anterior?

Todos sabemos que isso acontece. Um cara amargo de TI deixa um backdoor no sistema e na rede para se divertir com os novos caras e mostrar à empresa como as coisas estão ruins sem ele.

Eu nunca experimentei isso pessoalmente. O máximo que experimentei é alguém que quebrou e roubou coisas antes de sair. Tenho certeza que isso acontece, no entanto.

Portanto, ao assumir uma rede que não pode ser totalmente confiável, que medidas devem ser tomadas para garantir que tudo esteja seguro?

É muito, muito, muito difícil. Requer uma auditoria muito completa. Se você tem certeza de que a pessoa idosa deixou algo para trás que vai explodir, ou exige a sua contratação, porque é a única pessoa que pode apagar um incêndio, é hora de assumir que você está enraizado partido hostil. Trate-o como um grupo de hackers entrou e roubou coisas, e você precisa limpar a bagunça deles. Porque é isso que é.

• Audite todas as contas em todos os sistemas para garantir que estejam associados a uma entidade específica.
  • Contas que parecem associadas a sistemas, mas ninguém pode explicar, devem ser desconfiadas.
  • Contas que não estão associadas a nada precisam ser eliminadas (isso precisa ser feito de qualquer maneira, mas é especialmente importante nesse caso)
• Altere todas e quaisquer senhas com as quais eles possam ter entrado em contato.
  • Isso pode ser um problema real para contas de serviços públicos, pois essas senhas tendem a ser codificadas em algumas coisas.
  • Se eles eram do tipo de suporte técnico, respondendo a chamadas de usuários finais, suponha que eles tenham a senha de qualquer pessoa que tenha ajudado.
  • Se eles tinham Administrador Corporativo ou Administrador de Domínio no Active Directory, suponha que pegaram uma cópia dos hashes de senha antes de sair. Eles podem ser quebrados tão rapidamente agora que uma alteração de senha em toda a empresa precisará ser forçada em alguns dias.
  • Se eles tivessem acesso root a qualquer caixa * nix, assuma que eles saíram com os hashes de senha.
  • Revise todo o uso de chave SSH de chave pública para garantir que suas chaves sejam limpas e audite se alguma chave privada foi exposta enquanto você está nisso.
  • Se eles tivessem acesso a qualquer equipamento de telecomunicações, altere as senhas de roteador / switch / gateway / PBX. Isso pode ser realmente uma dor real, pois pode envolver interrupções significativas.
• Audite totalmente suas disposições de segurança de perímetro.
  • Verifique se todos os buracos do firewall estão rastreados para dispositivos e portas autorizados conhecidos.
  • Assegure-se de que todos os métodos de acesso remoto (VPN, SSH, BlackBerry, ActiveSync, Citrix, SMTP, IMAP, WebMail, qualquer que seja) não tenham autenticação extra, e faça uma verificação completa para métodos de acesso não autorizado.
  • Assegure o rastreamento de links WAN remotos para pessoas totalmente empregadas e verifique-o. Especialmente conexões sem fio. Você não quer que eles saiam com um modem ou celular pago pela empresa. Entre em contato com todos esses usuários para garantir que eles tenham o dispositivo certo.
• Audite completamente os arranjos internos de acesso privilegiado. São coisas como acesso SSH / VNC / RDP / DRAC / iLO / IMPI a servidores que os usuários em geral não possuem, ou qualquer acesso a sistemas confidenciais, como folha de pagamento.
• Trabalhe com todos os fornecedores e prestadores de serviços externos para garantir que os contatos estejam corretos.
  • Verifique se eles foram eliminados de todas as listas de contatos e serviços. Isso deve ser feito de qualquer maneira após qualquer partida, mas é extremamente importante agora.
  • Validar que todos os contatos são legítimos e possuem informações de contato corretas, é para encontrar fantasmas que podem ser representados.
• Comece a caçar bombas lógicas.
  • Verifique toda a automação (agendadores de tarefas, tarefas cron, listas de chamadas da UPS ou qualquer coisa que seja executada em uma programação ou seja acionada por eventos) quanto a sinais de mal. Por "tudo", quero dizer tudo. Verifique cada crontab. Verifique todas as ações automatizadas em seu sistema de monitoramento, incluindo as próprias análises. Verifique cada agendador de tarefas do Windows; até estações de trabalho. A menos que você trabalhe para o governo em uma área altamente sensível, não poderá pagar "todos", faça o máximo que puder.
  • Valide os principais binários do sistema em todos os servidores para garantir que eles sejam o que deveriam ser. Isso é complicado, especialmente no Windows, e quase impossível de executar de forma retroativa em sistemas pontuais.
  • Comece a procurar rootkits. Por definição, eles são difíceis de encontrar, mas existem scanners para isso.

Não é nada fácil, nem remotamente próximo. Justificar a despesa de tudo isso pode ser realmente difícil, sem prova definitiva de que o ex-administrador era de fato mau. A totalidade do exposto acima não é possível com os ativos da empresa, o que exigirá a contratação de consultores de segurança para realizar parte desse trabalho.

Se um mal real for detectado, especialmente se houver algum tipo de software, profissionais de segurança treinados são os melhores para determinar a amplitude do problema. Esse também é o ponto em que um processo criminal pode começar a ser construído, e você realmente deseja que pessoas treinadas no tratamento de evidências façam essa análise.

Mas, realmente, até onde você tem que ir? É aqui que o gerenciamento de riscos entra em ação. Simplisticamente, esse é o método de equilibrar o risco esperado com a perda. Os administradores de sistemas fazem isso quando decidimos qual local externo queremos colocar backups; cofre bancário versus um datacenter fora da região. Descobrir o quanto dessa lista precisa ser seguido é um exercício de gerenciamento de riscos.

Nesse caso, a avaliação começará com algumas coisas:

• O nível de habilidade esperado dos que partiram
• O acesso dos que partiram
• A expectativa de que o mal foi feito
• O dano potencial de qualquer mal
• Os requisitos regulamentares para relatar o mal perpetrado versus o mal preemptivo. Geralmente você precisa denunciar o primeiro, mas não o posterior.

A decisão de até que ponto abaixo da toca do coelho dependerá das respostas a essas perguntas. Para partidas administrativas de rotina em que a expectativa do mal é muito pequena, o circo completo não é necessário; alterar senhas em nível de administrador e redigitar todos os hosts SSH voltados para o exterior provavelmente é suficiente. Novamente, a postura de segurança corporativa de gerenciamento de riscos determina isso.

Para os administradores que foram demitidos por justa causa ou que surgiram após sua partida normal, o circo se torna mais necessário. O pior cenário é um tipo paranoico de BOFH que foi notificado de que sua posição será redundante em duas semanas, pois isso lhes dá tempo de sobra para se preparar; em circunstâncias como essa, a idéia de Kyle de um pacote generoso de indenização pode atenuar todos os tipos de problemas. Mesmo paranóicos podem perdoar muitos pecados após a chegada de um cheque contendo 4 meses de pagamento. Essa verificação provavelmente custará menos do que o custo dos consultores de segurança necessários para descobrir seu mal.

Mas, no final das contas, tudo se resume ao custo de determinar se o mal foi praticado versus o custo potencial de qualquer mal efetivamente praticado.

Eu diria que é um equilíbrio de quanta preocupação você tem em relação ao dinheiro que está disposto a pagar.

Muito preocupado:
se você está muito preocupado, convém contratar um consultor de segurança externo para fazer uma verificação completa de tudo, tanto da perspectiva externa quanto interna. Se essa pessoa for particularmente inteligente, você pode estar com problemas, pois pode haver algo que ficará inativo por um tempo. A outra opção é simplesmente reconstruir tudo. Isso pode parecer muito excessivo, mas você aprenderá bem o ambiente e também fará um projeto de recuperação de desastres.

Ligeiramente preocupado:
Se você está apenas levemente preocupado, pode querer:

• Uma varredura de porta do lado de fora.
• Verificação de vírus / spyware. Verificação de rootkit para máquinas Linux.
• Procure na configuração do firewall qualquer coisa que você não entenda.
• Altere todas as senhas e procure por contas desconhecidas (verifique se elas não ativaram alguém que não está mais na empresa para poder usá-las etc.).
• Também pode ser um bom momento para instalar um IDS (Intrusion Detection System).
• Observe os logs mais de perto do que normalmente.

Para o futuro:
seguir em frente quando um administrador sair dar a ele uma boa festa e depois quando ele estiver bêbado, oferecer-lhe uma carona para casa - depois descartar-o no rio, pântano ou lago mais próximo. Mais seriamente, esse é um dos bons motivos para oferecer aos administradores uma indenização generosa. Você quer que eles se sintam bem em deixar o máximo possível. Mesmo que não se sintam bem, quem se importa ?, sugam-no e os fazem felizes. Finja que a culpa é sua e não deles. O custo de um aumento nos custos de seguro-desemprego e o pacote de indenizações não se comparam aos danos que poderiam causar. É tudo sobre o caminho de menor resistência e criando o mínimo de drama possível.

Não se esqueça de nomes como Teamviewer, LogmeIn, etc ... Eu sei que isso já foi mencionado, mas uma auditoria de software (muitos aplicativos por aí) de cada servidor / estação de trabalho não faria mal, incluindo varreduras de sub-rede com nmap Scripts NSE.

Primeiras coisas primeiro - obtenha um backup de tudo no armazenamento externo (por exemplo, fita ou HDD que você desconecta e coloca no armazenamento). Dessa forma, se algo malicioso ocorrer, você poderá se recuperar um pouco.

Em seguida, vasculhe suas regras de firewall. Quaisquer portas abertas suspeitas devem ser fechadas. Se houver uma porta dos fundos, impedir o acesso a ela seria uma coisa boa.

Contas de usuário - procure seu usuário insatisfeito e garanta que o acesso seja removido o mais rápido possível. Se houver chaves SSH ou arquivos / etc / passwd ou entradas LDAP, mesmo arquivos .htaccess, todos deverão ser verificados.

Nos seus servidores importantes, procure aplicativos e portas de escuta ativas. Verifique se os processos em execução anexados a eles parecem sensatos.

Por fim, um determinado funcionário insatisfeito pode fazer qualquer coisa - afinal, ele tem conhecimento de todos os sistemas internos. Espera-se que eles tenham integridade para não tomar ações negativas.

Uma infra-estrutura bem gerida terá as ferramentas, o monitoramento e os controles para evitar isso em grande parte. Esses incluem:

• Segmentação e firewall de rede adequados
• IDS baseado em host
• IDS baseado em rede
• Registro central
• Controle de acesso
• Controle de mudança

Se essas ferramentas estiverem no lugar corretamente, você terá uma trilha de auditoria. Caso contrário, você precisará executar um teste de penetração completo .

O primeiro passo seria auditar todo o acesso e alterar todas as senhas. Concentre-se no acesso externo e nos possíveis pontos de entrada - é aqui que você gasta melhor seu tempo. Se a pegada externa não for justificada, elimine-a ou reduza-a. Isso permitirá que você concentre-se em mais detalhes internamente. Esteja ciente de todo o tráfego de saída, pois as soluções programáticas podem estar transferindo dados restritos externamente.

Por fim, ser administrador de sistemas e redes permitirá acesso total à maioria, senão a todas as coisas. Com isso, vem um alto grau de responsabilidade. A contratação com esse nível de responsabilidade não deve ser tomada de ânimo leve e devem ser tomadas medidas para minimizar os riscos desde o início. Se um profissional for contratado, mesmo deixando em más condições, ele não tomaria ações que seriam pouco profissionais ou ilegais.

Existem muitas postagens detalhadas sobre a falha do servidor que cobrem a auditoria adequada do sistema para segurança, bem como o que fazer em caso de rescisão de alguém. Esta situação não é exclusiva deles.

Um BOFH inteligente poderia fazer o seguinte:

1. Programa periódico que inicia uma conexão de saída netcat em uma porta conhecida para captar comandos. Por exemplo, porta 80. Se bem feito, o tráfego de ida e volta teria a aparência de tráfego para essa porta. Portanto, se na porta 80, ele teria cabeçalhos HTTP e a carga útil seria pedaços incorporados nas imagens.

2. Comando aperiódico que procura em locais específicos os arquivos a serem executados. Os locais podem estar nos computadores dos usuários, computadores em rede, tabelas extras nos bancos de dados, diretórios temporários de arquivos em spool.

3. Programas que verificam se uma ou mais das outras backdoors ainda estão em vigor. Caso contrário, será instalada uma variante e os detalhes serão enviados por e-mail ao BOFH

4. Como agora muitos backups são feitos com disco, modifique os backups para conter pelo menos alguns de seus kits raiz.

Maneiras de se proteger desse tipo de coisa:

1. Quando um funcionário da classe BOFH sair, instale uma nova caixa na DMZ. Ele obtém uma cópia de todo o tráfego que passa pelo firewall. Procure anomalias nesse tráfego. O último não é trivial, especialmente se o BOFH é bom em imitar padrões de tráfego normais.

2. Refaça seus servidores para que os binários críticos sejam armazenados na mídia somente leitura. Ou seja, se você deseja modificar / bin / ps, precisa ir à máquina, mover fisicamente um comutador de RO para RW, reiniciar o usuário único, remontar a partição rw, instalar sua nova cópia do ps, sincronizar, reiniciar, interruptor. Um sistema feito dessa maneira possui pelo menos alguns programas confiáveis ​​e um kernel confiável para realizar trabalhos adicionais.

Obviamente, se você estiver usando o Windows, você será manejado.

3. Compartimentalize sua infra-estrutura. Não é razoável em pequenas e médias empresas.

Maneiras de evitar esse tipo de coisa.

1. Veterinários com cuidado.

2. Descubra se essas pessoas estão descontentes e corrija os problemas de pessoal com antecedência.

3. Quando você dispensa um administrador com esses tipos de poderes, adoça a torta:

   uma. Seu salário ou uma fração dele continua por um período de tempo ou até que ocorra uma grande mudança no comportamento do sistema que não é explicada pela equipe de TI. Isso pode ocorrer em uma deterioração exponencial. Por exemplo, ele recebe salário integral por 6 meses, 80% disso por 6 meses, 80% disso pelos próximos 6 meses.

   b. Parte de seu salário é na forma de opções de ações que não entram em vigor por um a cinco anos depois que ele sai. Essas opções não são removidas quando ele sai. Ele tem um incentivo para garantir que a empresa funcione bem em 5 anos.

Parece-me que o problema existe antes mesmo de o administrador sair. Só que se nota mais o problema naquele momento.

-> É necessário um processo para auditar todas as alterações, e parte do processo é que as mudanças são aplicadas apenas através dela.

Não deixe de contar a todos na empresa depois que eles forem embora. Isso eliminará o vetor de ataque da engenharia social. Se a empresa for grande, verifique se as pessoas que precisam saber sabem.

Se o administrador também foi responsável pelo código escrito (site corporativo etc.), você também precisará fazer uma auditoria de código.

Há um grande problema que todo mundo deixou de fora.

Lembre-se de que não existem apenas sistemas.

• Os fornecedores sabem que essa pessoa não está na equipe e não deve ter acesso permitido (colo, telecomunicações)
• Existem serviços hospedados externos que podem ter senhas separadas (troca, crm)
• Eles poderiam ter material de chantagem de qualquer maneira (tudo bem, isso está começando a chegar um pouco ...)

A menos que você seja realmente paranóico, minha sugestão seria simplesmente executar várias ferramentas de verificação TCP / IP (tcpview, wireshark etc.) para ver se há algo suspeito tentando entrar em contato com o mundo exterior.

Altere as senhas de administrador e verifique se não há contas de administrador 'adicionais' que não precisem estar lá.

Além disso, não esqueça de alterar as senhas de acesso sem fio e verificar as configurações do software de segurança (antivírus e firewall em particular)

Verifique os logs em seus servidores (e nos computadores em que trabalham diretamente). Procure não apenas a conta deles, mas também as contas que não são administradores conhecidos. Procure por buracos nos seus logs. Se um log de eventos foi limpo em um servidor recentemente, é suspeito.

Verifique a data da modificação nos arquivos em seus servidores web. Execute um script rápido para listar todos os arquivos alterados recentemente e revise-os.

Verifique a data da última atualização em todas as suas políticas de grupo e objetos de usuário no AD.

Verifique se todos os seus backups estão funcionando e se os backups existentes ainda existem.

Verifique se os servidores em que você está executando os serviços Volume Shadow Copy estão ausentes.

Eu já vejo muitas coisas boas listadas e só queria adicionar essas outras coisas que você pode verificar rapidamente. Valeria a pena fazer uma revisão completa de tudo. Mas comece com os lugares com as alterações mais recentes. Algumas dessas coisas podem ser verificadas rapidamente e podem levantar algumas bandeiras vermelhas para ajudá-lo.

Basicamente, eu diria que se você tem um BOFH competente, está condenado ... há muitas maneiras de instalar bombas que seriam despercebidas. E se sua empresa é usada para ejetar "militares" aqueles que são demitidos, certifique-se de que a bomba será plantada bem antes da dispensa !!!

A melhor maneira é minimizar os riscos de ter um administrador irritado ... Evite a "dispensa por redução de custos" (se ele é um BOFH competente e cruel, as perdas que você pode sofrer provavelmente serão muito maiores do que as que você obterá demissão) ... Se ele cometeu algum erro inaceitável, é melhor que ele o conserte (não remunerado) como alternativa à demissão ... Ele será mais prudente na próxima vez em não repetir o erro (o que será um aumento em seu valor) ... Mas certifique-se de atingir o bom alvo (é comum que pessoas incompetentes e com bom carisma rejeitem sua própria culpa à competente, mas menos social).

E se você está enfrentando um verdadeiro BOFH no pior sentido (e esse comportamento é a razão da demissão), é melhor você estar preparado para reinstalar do zero todo o sistema com o qual ele esteve em contato (o que provavelmente significará cada computador).

Não se esqueça que uma única mudança de bit pode fazer todo o sistema estragar ... (bit setuid, Jump if Carry para Jump if No Carry, ...) e que mesmo as ferramentas de compilação podem ter sido comprometidas.

Boa sorte se ele realmente souber de alguma coisa e configurar alguma coisa com antecedência. Até mesmo um idiota pode ligar / enviar por e-mail / fax para a empresa de telecomunicações com desconexões ou até pedir para que executem padrões de teste completos nos circuitos durante o dia.

Sério, mostrar um pouco de amor e alguns mil na partida realmente diminui o risco.

Ah, sim, caso eles liguem para "obter uma senha ou algo assim", lembre-os de sua taxa de 1099 e de 1 hora e 100 horas de despesas por viagem, independentemente de você precisar estar em qualquer lugar ...

Ei, isso é o mesmo que minha bagagem! 1,2,3,4!

Eu sugiro que você comece no perímetro. Verifique as configurações do firewall e verifique se você não possui pontos de entrada inesperados na rede. Certifique-se de que a rede esteja fisicamente segura contra ele, reinserção e acesso a qualquer computador.

Verifique se você possui backups totalmente funcionais e restauráveis. Bons backups impedirão que você perca dados se ele fizer algo destrutivo.

Verifique todos os serviços permitidos no perímetro e verifique se ele teve acesso negado. Certifique-se de que esses sistemas tenham bons mecanismos de registro em funcionamento.

Apague tudo, comece de novo;)

Queime .... queime tudo.

É a única maneira de ter certeza.

Em seguida, grave todos os seus interesses externos, registradores de domínio, provedores de pagamento com cartão de crédito.

Pensando bem, talvez seja mais fácil pedir a qualquer colega de Bikie para convencer o indivíduo de que é mais saudável não incomodá-lo.

Presumivelmente, um administrador competente em algum lugar ao longo do caminho fez o que é chamado de BACKUP da configuração básica do sistema. Também seria seguro supor que existem backups feitos com algum nível razoável de frequência, permitindo a restauração de um backup seguro conhecido.

Dado que algumas coisas não mudam, é uma boa idéia para executar a partir do backup virtualizados, se possível até que você possa garantir a instalação principal não seja comprometida.

Supondo que o pior se torne evidente, você mescla o que pode e insere manualmente o restante.

Estou chocado que ninguém tenha mencionado usar um backup seguro antes de mim. Isso significa que devo enviar meu currículo para seus departamentos de RH?

Tente tomar o seu ponto de vista.

Você conhece seu sistema e o que ele faz. Assim, você pode tentar imaginar o que poderia ser inventado para se conectar de fora, mesmo quando você não é mais administrador de sistemas ...

Dependendo de como está a infraestrutura de rede e de como tudo isso funciona, você é a melhor pessoa que pode saber o que fazer e onde isso pode estar localizado.

Mas, como você parece falar de um bofh experimentado , precisa procurar perto de qualquer lugar ...

Rastreamento de rede

Como o objetivo principal é assumir o controle remoto do seu sistema, através da sua conexão à Internet, você pode assistir (até substituir, porque isso também pode estar corrompido !!) o firewall e tentar identificar cada conexão ativa.

A substituição do firewall não garante uma proteção completa, mas garante que nada fique oculto. Portanto, se você procurar pacotes encaminhados pelo firewall, deverá ver tudo, incluindo tráfego indesejado.

Você pode usar tcpdumppara rastrear tudo (como faz o paranóico dos EUA;) e procurar arquivos de despejo com ferramentas avançadas como wireshark. Reserve um tempo para ver o que esse comando (precisa de 100 GB de espaço livre no disco):

tcpdump -i eth0 -s 0 -C 100 -w tcpdump- -W 1000 >tcpdump.log 2>tcpdump.err </dev/null &

Não confie em tudo

Mesmo se você encontrar alguma coisa, não terá certeza de ter sido encontrado coisas totalmente ruins!

Por fim, você não ficará muito quieto antes de reinstalar tudo (de fontes confiáveis!)

Se você não pode refazer o servidor, a próxima melhor coisa é provavelmente bloquear os firewalls o máximo possível. Siga todas as conexões de entrada possíveis e reduza ao mínimo absoluto.

Mude todas as senhas.

Substitua todas as chaves ssh.

Geralmente é bastante difícil ...

mas, se for um site, consulte o código logo atrás do botão Login.

Encontramos uma coisa do tipo "se nome de usuário = 'admin'" uma vez ...

Em essência, torne inútil o conhecimento das pessoas de TI anteriores.

Altere tudo o que você pode alterar sem afetar a infraestrutura de TI.

Mudar ou diversificar fornecedores é outra boa prática.