Colocando um servidor linux inteiro sob controle de origem (git)

Estou pensando em colocar meu servidor linux inteiro sob controle de versão usando o git. A razão por trás disso é que essa pode ser a maneira mais fácil de detectar modificações / rootkits maliciosos. Tudo o que eu acho ingênuo é necessário para verificar a integridade do sistema: Monte a partição linux toda semana, usando um sistema de recuperação, verifique se o repositório git ainda está sem moderação e, em seguida, emita um status git para detectar quaisquer alterações feitas no sistema .

Além do desperdício óbvio no espaço em disco, existem outros efeitos colaterais negativos?

É uma ideia totalmente louca?

É ainda uma maneira segura de verificar os rootkits, já que eu provavelmente teria que excluir pelo menos / dev e / proc?

Essa é uma "má ideia" (tm). Além de tudo, seu repositório ficará lento como todos os outros, e piorará à medida que todas as revisões forem mantidas.

Tente um gerenciamento centralizado, como fantoche / cfengine / chef. Isso manterá as coisas como você espera e reverterá mudanças inesperadas.

Combine isso com algo como o iwatch para receber emails de alterações não autorizadas de arquivos.

Combine isso ainda com arquivos rpm / deb, se necessário, para implantar aplicativos personalizados.

Coloque algo como rkhunter ou chkrootkit de vez em quando para chutes e você deve estar pronto.

Tarefa concluída.

Outra alternativa é configurar o tripwire , que é um software da GPL que percorre todos os arquivos importantes do seu sistema e determina quais foram alteradas das maneiras que você definiu como inaceitáveis. A mudança pode ser definida simplesmente como mtime, através do número do inode, até as somas de verificação criptograficamente fortes.

É preciso alguma configuração e ajuste, se você não deseja obter muitos relatórios todas as noites sobre arquivos alterados /var/run, alterações nos arquivos do cliente DHCP /etce assim por diante, mas se você enfrentar esse problema, pode ser muito útil mesmo.

O banco de dados de propriedades do arquivo é assinado com uma chave não conhecido para a máquina, o que ajuda você a ter confiança de que nenhuma ferramenta foi maliciosamente mudou o banco de dados ou os binários tripwire. Para total segurança, você pode gravar uma cópia das ferramentas e dos bancos de dados do tripwire em um meio somente leitura, que pode ser montado no servidor e usado para verificar todas as alterações desde a gravação do disco, se for necessária uma análise forense completa.

Se você fizer isso, é muito importante configurar e ativar o tripwire antes que a máquina seja implantada em produção, ou você nunca pode ter certeza absoluta de que algum usuário mal-intencionado não teve a chance de infectar a máquina antes dela. foi cabeado.

Não acho que isso funcione, mas como um experimento, gostaria de ver o que acontece se você fizer isso apenas com a pasta / etc. É aí que a maioria das informações de configuração é mantida.

O @Sirex já forneceu uma resposta muito boa, mas se você quiser dar um passo adiante com a segurança, a melhor maneira de lidar com isso é a prevenção e a detecção.

Tente configurar um sistema com / filesystem montado como somente leitura. Faça / tmp um ramfs separado montado com a opção noexec, nodev. Para que o sistema funcione, você realmente só precisa que o / var seja montado como leitura e gravação. Portanto, em / var monte um fs com rw, noexec, nodev e remova as permissões de gravação para / var / tmp (depois, raramente é necessário pelos daemons e isso deve ser configurável). Use também um patch de segurança para o seu kernel para limitar ainda mais o acesso aos recursos pelos usuários; tente o grsec, por exemplo. Use um firewall com as regras mais restritivas possíveis.

Algumas distribuições fornecem documentação extensa sobre a proteção do sistema. Por exemplo:

• Protegendo o Manual Debian
• Endurecendo a Debian Wiki

Eu acho que é uma boa ideia analisar as alterações que uma ferramenta faz no seu sistema:

1. instalar um Linux simples em uma VM
2. inicializar o root git
3. instale a ferramenta que você deseja analisar
4. veja todas as alterações feitas no seu sistema

... Exclua a VM

Você teria que adicionar muitas pastas ao .gitignore arquivo, como proc, etc.

Nas situações em que você está apenas interessado em manter determinadas pastas em todo o sistema de arquivos sob controle de versão, a seguinte abordagem pode funcionar:

Primeiro, crie um repositório Git no /nível:

$ cd /
# git init

Em seguida, crie uma /.gitignorelista de permissões que apenas determinadas pastas, por exemplo, apenas para lista de permissões /path/to/versioned/config/folder/(com base em /programming//a/11018557/320594 ):

/*
!/path/
/path/*
!/path/to/
/path/to/*
!/path/to/versioned/
/path/to/versioned/*
!/path/to/versioned/config/
/path/to/versioned/config/*
!/path/to/versioned/config/folder/
!/.gitignore

Em seguida, crie uma primeira confirmação:

# git add -A
# git commit -m "Initial commit"

E adicione as pastas adicionais que você deseja sob controle de versão sob demanda.

PS:

Além do método anterior, se você precisar manter o / etc / sob controle de versão, pode preferir usar etckeeper( https://etckeeper.branchable.com/ ) para controlar a versão dessa pasta específica, pois ela é mais especializada para esse fim ( por exemplo, confirma automaticamente após a instalação de pacotes).