-
Para determinar qual software foi instalado, você pode revisar /var/log/dpkg.log No entanto, isso pode não ser um registro completo. Pode haver binários e código que foram compilados manualmente ou copiados diretamente para o sistema pré-compilado. Você poderia comparar uma instalação padrão da mesma versão do Ubuntu e digitar para o (s) servidor (es) e procurar quais arquivos são diferentes, mas isso pode ser tedioso. Uma solução de monitor de arquivo seria ideal (tripewire, inotifywatch, etc.) link
-
Você precisa verificar TUDO no servidor. Cada conta de usuário em / etc / passwd , todas as contas de usuário do aplicativo (como usuários em 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 runlevels. Eu usaria um scanner de vulnerabilidade 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 ($). link O OpenVAS é um scanner FOSS, não diferente do Nessus, que pode ter recursos semelhantes. Há muitas outras coisas para verificar, mas esta resposta já está ficando um pouco longa ... (A revisão de código para webapps e páginas da Web é um bom exemplo).
-
Você pode ver o estado das portas disponíveis para conexões com os servidores com uma variedade de sinalizadores para netstat . link Para identificar quem está se conectando ao servidor, você terá que recorrer às atividades mais sensuais do Internet Security, revisando os registros do sistema. A informação pode 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 logs de rede externos, se existirem.
-
Você tem um lote de acompanhamento para fazer. Você indicou que o administrador anterior foi disparado ; se você suspeitar de intenção maliciosa daquela pessoa (ou seja, eles podem ter deixado backdoors, armadilhas de boobie, bombas lógicas, etc.), é quase certo que será melhor reconstruir os servidores a partir de mídias limpas e reimplementar os webapps neles. Se esse administrador anterior tiver acesso e controle total a esse sistema e não tiver sido submetido a auditorias e overwatches diligentes, provavelmente você deve presumir que há backdoors.
Isso é baseado em uma suposição pessimista sobre o administrador anterior. Infelizmente, é assim que o cookie se desintegra para a segurança operacional da rede. Há muito mais a considerar, como eu disse ... muito mais do que pode ser coberto aqui. Esses pontos devem lhe dar algumas coisas para começar a fazer, de modo que você possa relatar à gerência que está fazendo algum progresso; mas para ser brutalmente honesto, se você não for um profissional de segurança e tiver motivos para suspeitar que essa pessoa tenha agido com malícia, provavelmente você está passando por cima da sua cabeça.
É uma resposta impopular ao gerenciamento porque requer muito esforço (o que significa mais $), mas a resposta geral é: em caso de dúvida, limpe e reconstrua a partir de fontes limpas . É assim que os sistemas de governo mais importantes funcionam com malware; Se um alerta surgir do AV, o sistema será separado, limpo e reconstruído. Espero que você tenha feito um backup porque os dados são GONE .
Boa sorte, e espero que isso tenha sido útil e não apenas deprimente.