Para determinar qual software foi instalado, você pode revisar /var/log/dpkg.log
No entanto, esse pode não ser um registro completo. Pode haver binários e códigos que foram compilados manualmente ou copiados diretamente para o sistema pré-compilado. Você pode comparar uma instalação padrão da mesma versão e tipo do Ubuntu com o (s) servidor (es) e procurar quais arquivos são diferentes, mas isso pode ser tedioso. Uma solução de monitoramento de arquivos seria ideal (tripewire, inotifywatch etc.)
http://linuxcommando.blogspot.com/2008/08/how-to-show-apt-log-history.html
Você precisa verificar TUDO no servidor. Todas as contas de usuário em / etc / passwd , todas as contas de usuário de aplicativos (como usuários no Apache / PHP, contas de banco de dados etc.) devem ser contabilizadas e você deve alterar todas as senhas. Você deve verificar quais serviços são iniciados na inicialização, qual é o nível de execução padrão e o que começa com ele e com outros níveis de execução. Eu usaria um scanner de vulnerabilidades e uma ferramenta de configuração de linha de base para auditar o estado atual. O Center for Internet Security oferece uma ferramenta gratuita de avaliação de configuração, mas pode ser limitada. Eles têm ferramentas mais avançadas para organizações membros ($).
http://benchmarks.cisecurity.org/
O OpenVAS é um scanner FOSS, não muito diferente do Nessus, que pode ter recursos semelhantes. Há muito mais coisas a serem verificadas, mas essa resposta já está ficando um pouco longa ... (Revisão de código para aplicativos da web e páginas da web é um bom exemplo).
Você pode ver o estado das portas disponíveis para conexões com os servidores com vários sinalizadores para netstat .
http://www.thegeekstuff.com/2010/03/netstat-command-examples/
Para identificar quem está se conectando ao servidor, você precisará recorrer às atividades mais sexy da Internet Security, revisando os logs do sistema. As informações podem estar em qualquer um dos vários logs, dependendo de quais aplicativos e servidores estão no sistema. Você também pode ter alguma sorte com os logs de rede externos, se existirem.
Você tem muito acompanhamento a fazer. Você indicou que o administrador anterior foi demitido ; se você suspeitar da intenção maliciosa dessa pessoa (ou seja, ela pode ter deixado backdoors, armadilhas, bombas lógicas etc.), é quase certo que você esteja melhor reconstruindo os servidores a partir de mídia limpa e reimplementando os webapps neles. Se esse administrador anterior tivesse acesso e controle completos a esses sistemas e não fosse submetido a auditorias e vigilância vigilantes, você provavelmente deveria assumir que existem backdoors.
Isso se baseia em uma suposição pessimista sobre o administrador anterior. Infelizmente, é dessa maneira que o cookie desmorona para a segurança operacional da rede. Há muito mais a considerar, como eu disse ... muito mais do que pode ser abordado aqui. Esses pontos devem fornecer algumas coisas para você começar a fazer, para que possa informar à gerência que está fazendo algum progresso; mas, para ser brutalmente honesto, se você não é um profissional de segurança e tem motivos para suspeitar que essa pessoa agiu com malícia, você provavelmente está enlouquecendo.
É uma resposta impopular para a gerência, porque exige muito esforço (o que significa mais $), mas a resposta geral para a segurança é quando, na dúvida, limpe e reconstrua a partir de fontes limpas . É assim que os sistemas governamentais mais importantes funcionam com malware; se um alerta surgir do AV, o sistema é segregado, limpo e reconstruído. Espero que você fez um backup cuz que os dados são IDO .
Boa sorte, e espero que isso tenha sido útil e não apenas deprimente.