Esta resposta é principalmente para defender os benefícios de manter adequadamente o acesso em seu departamento de TI.
Sua situação exemplifica o benefício de uma trilha de auditoria e controle de acesso adequado. Por exemplo, todo acesso exigiria um ticket de solicitação de acesso com aprovação, sem exceção. Após a rescisão, você audita o sistema de tickets.
Para funções comuns na sua empresa, o acesso pode ser padronizado e ainda mais fácil de eliminar.
Para funções de TI, temos uma planilha em que trabalhamos para encerramentos. Ele lista tudo para evitar a supervisão. Também auditamos nossos tickets de solicitação de acesso e nosso sistema de registro de trabalho, pois todas as alterações de produção são documentadas lá.
Os administradores também devem ter contas de usuário individuais, que usam para acessar privilégios administrativos. Contas raiz e administrativas não devem ser autenticadas diretamente. Embora isso não seja tecnicamente infalível, permite uma trilha de auditoria e também a responsabilidade individual. Com isso, bloquear todas as contas dele seria um primeiro passo e você alteraria todas as contas de administrador.
Se você ainda não o fez, gostaria de incentivá-lo a implementar algumas dessas soluções, se não todas. Eu os considero integrais e reduz o risco quando ocorre um término involuntário.
Primeiro, remova todos os acessos externos. Qualquer acesso que a pessoa possa usar sem estar no local. Em seguida, altere todas as senhas. Cada senha de administrador, todas as senhas do sistema, todas as senhas dos aplicativos, todas as senhas das contas dos fornecedores, todas as senhas das contas de suporte - tudo. Se o risco de retaliação for grande, você também poderá expirar as senhas de todos os funcionários.
Como você não tem as senhas raiz nos servidores Linux, é possível inicializar no modo de usuário único e alterá-lo. Com GRUB e < um href="http://www.redhat.com/docs/manuals/linux/RHL-7.3-Manual/custom-guide/s1-ruemuemode-booting-single.html"> LILO , você simplesmente acrescentar single . Os métodos são semelhantes.
Como outros recomendaram, audite todos os crontabs (localizados em / var / spool / cron), usuários do sistema, daemons em execução, keypairs do ssh e os sistemas em geral.
Embora a reconstrução seja a única maneira de ter certeza, ela não deve ser necessária na maioria dos casos. Qualquer profissional respeitoso não arriscaria sua carreira em uma reação tão gutural. Também permitiria a obtenção de danos criminais e civis pelo seu empregador. Por fim, sugiro ter uma discussão séria sobre os riscos com o seu gerente depois de realizar a devida diligência com a remoção.