Poner un servidor Linux completo bajo control de fuente (git)

Estoy pensando en poner todo mi servidor Linux bajo control de versiones usando git. La razón detrás de esto es que esa podría ser la forma más fácil de detectar modificaciones maliciosas / rootkits. Todo lo que ingenuamente pensaría es necesario para verificar la integridad del sistema: monte la partición de Linux cada semana más o menos utilizando un sistema de rescate, verifique si el repositorio git aún no está templado y luego emita un estado git para detectar cualquier cambio realizado en el sistema .

Además del desperdicio obvio en el espacio en disco, ¿hay otros efectos secundarios negativos?

¿Es una idea totalmente loca?

¿Es incluso una forma segura de verificar los rootkits ya que lo más probable es que tenga que excluir al menos / dev y / proc?

Esa es una "mala idea" (tm). Aparte de todo lo demás, su repositorio se ejecutará lentamente y empeorará a medida que se guarden todas las revisiones.

Pruebe la administración centralizada, como títeres / cfengine / chef. Eso mantendrá las cosas como espera y revertirá los cambios inesperados.

Combina eso con algo como iwatch para recibir correos electrónicos de alteraciones de archivos no autorizadas.

Combine eso con archivos rpm / deb si es necesario para implementar aplicaciones personalizadas.

Agregue algo como rkhunter o chkrootkit de vez en cuando para patear y debería estar listo.

Trabajo hecho.

Otra alternativa es configurar Tripwire , que es un software GPL que explora todos los archivos importantes en su sistema y determina cuáles han cambiado en formas que ha definido como inaceptables. El cambio se puede definir simplemente como mtime, a través del número de inodo, hasta sumas de verificación criptográficamente fuertes.

Se necesita un poco de configuración y ajuste si no desea obtener una gran cantidad de informes todas las noches sobre los archivos /var/runmodificados, los cambios en los archivos del cliente DHCP /etcy similares, pero si se mete en ese problema, puede ser muy útil de hecho.

La base de datos de propiedades del archivo está firmado con una clave no conoce a la máquina, lo que le ayuda a tener confianza en que ninguna herramienta ha cambiado maliciosamente la base de datos o los binarios de cable trampa. Para una certeza completa, puede grabar una copia de las herramientas y bases de datos tripwire en un medio de solo lectura, que puede montarse en el servidor y usarse para verificar todos los cambios desde que se quemó el disco, si se necesita un análisis forense completo.

Si va a hacer esto, es muy importante configurar y ejecutar Tripwire antes de que la máquina se implemente en producción, o nunca puede estar completamente seguro de que algún usuario malintencionado no tuvo la oportunidad de infectar la máquina antes de que se fue tripwired.

No creo que esto es probable que el trabajo, sino como un experimento que me gustaría ver lo que pasa si lo hace con la carpeta sólo el / etc. Ahí es donde se guarda la mayor parte de la información de configuración.

@Sirex ya proporcionó una muy buena respuesta, pero si desea dar un paso más con la seguridad, la mejor manera de abordarla es primero la prevención y luego la detección.

Intente configurar un sistema con / sistema de archivos montado solo lectura. Haga / tmp un ramfs separado montado con la opción noexec, nodev. Para que el sistema funcione, realmente solo necesita / var para ser montado lectura-escritura. Entonces, bajo / var, monte un fs con rw, noexec, nodev y elimine los permisos de escritura en / var / tmp (afaik, los demonios rara vez lo necesitan y eso debería ser configurable). También use un parche de seguridad para su núcleo para limitar aún más el acceso a los recursos por parte de los usuarios, pruebe grsec por ejemplo. Use un firewall con las reglas más restrictivas posibles.

Algunas distribuciones proporcionan una amplia documentación sobre el fortalecimiento del sistema. Por ejemplo:

• Asegurando el Manual de Debian
• Endurecimiento de Debian Wiki

Creo que es una buena idea analizar los cambios que una herramienta realiza en su sistema:

1. instalar un Linux desnudo en una VM
2. inicializar la raíz git
3. instale la herramienta que desea analizar
4. ver todos los cambios realizados en su sistema

... Eliminar la VM

Tendría que agregar muchas carpetas al .gitignore archivo, como proc, etc.

Para las situaciones en las que solo está interesado en mantener ciertas carpetas en todo el sistema de archivos bajo control de versiones, el siguiente enfoque podría funcionar:

Primero, cree un repositorio Git en el /nivel:

$ cd /
# git init

Luego, cree una /.gitignorelista blanca que solo incluya ciertas carpetas, por ejemplo, solo en la lista blanca /path/to/versioned/config/folder/(basada en /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

Luego cree una primera confirmación:

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

Y luego agregue las carpetas adicionales que desee bajo control de versiones a pedido.

PD:

Además del método anterior, si necesita mantener / etc / bajo control de versión, puede preferir usar etckeeper( https://etckeeper.branchable.com/ ) para versionar esa carpeta específica, ya que es más especializada para ese propósito ( por ejemplo, se confirma automáticamente después de instalar paquetes).