• EN
Solved

Best practice inmutabilidad

G
Userlevel 3

Hola a todos ¿Como están?

 

Tengo algunas consultas, he implementado varios repositorios inmutables, en el camino me he encontrado con el dilema de que distribución es mejor para ello y me he centrado en dos: Ubuntu Server y Red Hat.

Algunos colegas me indican que mejor es Red Hat sin embargo veo muchos temas que hablan del uso de Ubuntu Server… ¿Qué creen ustedes, cual sea mejor?

 

Adicionalmente, validando las buenas practicas, que entre ellas esta quitar el usuario del grupo sudo, que la maquina no sea virtual sino física, deshabilitar el ssh y no usar ntp públicos, etc. ¿Qué recomendación adicional pueden sugerir?

icon

Best answer by HunterLAFR 13 March 2024, 16:14

View original

4 comments

HunterLAFR
Userlevel 7
Badge +8

Hola,
Excelentes preguntas @Glennchot 
La distribución a usar, yo te diría que con la que te sientas más cómodo,

no obstante, hay bastante documentación por ahí, y lo que se ve, es con Ubuntu.

Aquí tienes una entrada sobre Linux hardened Repositories desde Veeam y las “best practices”.
https://www.veeam.com/blog/hardened-linux-repository-best-practices.html

Aquí tienes otra entrada, esta la hice yo, Instalando un Ubuntu paquetizado con Hardening e Inmutability:
 

 

Por ultimo, como bien puedes observar, un servidor inmutable, tiene que ser físico, para estar fuera de la infraestructura a proteger, si lo virtualizas, y tu hipervisor se ve comprometido, no vas a poder acceder a tu repositorio.

También, tener en cuenta, una cosa es el Linux Inmutable, y luego el Hardening que le apliques al Linux, que no tenga acceso SSH, no ROOT, y el usuario que tengas que no sea miembro de SUDO, y solamente que pueda reiniciar, apagar y poco más en la máquina.

te dejo aquí el link del script para Ubuntu, el cual puedes ejecutar tras instalar el OS, para hacer tu Servidor inmutable y hardened

https://www.veeam.com/sys507

Un saludo.

Luis F.

Luis F.- HunterLF - HunterLAFR - lfconsulting.org
G
Userlevel 3

Gracias por tus respuestas ya estoy revisando los enlace, fíjate quería agregar lo siguiente, voy a probar tu script sin embargo ya no uso script sino que lo hago a “mano” como quien dice, pero por ejemplo tanto en red hat como en ubuntu, se requiere un usuario con permisos sudo para hacer las configuraciones iniciales e incluso crear el usuario que permite conectar el linux con veeam y que luego será eliminado del grupo sudo, bajo este escenario ese user debería de conservarse con un password de unos 15 caracteres, etc, porque luego si necesitamos modificar algo debemos requerir a el, e incluso si el Windows donde esta veeam fue afectado por un rasonmware y debemos presentar el repositorio inmutable a otro server de Veeam, debemos recrear un usuario para darle los permisos al directorio y esto debe hacelo un user con privilegios sudo, por ello consulto, ¿no deberíamos conversar este usuario?

HunterLAFR
Userlevel 7
Badge +8

Gracias por tus respuestas ya estoy revisando los enlace, fíjate quería agregar lo siguiente, voy a probar tu script sin embargo ya no uso script sino que lo hago a “mano” como quien dice, pero por ejemplo tanto en red hat como en ubuntu, se requiere un usuario con permisos sudo para hacer las configuraciones iniciales e incluso crear el usuario que permite conectar el linux con veeam y que luego será eliminado del grupo sudo, bajo este escenario ese user debería de conservarse con un password de unos 15 caracteres, etc, porque luego si necesitamos modificar algo debemos requerir a el, e incluso si el Windows donde esta veeam fue afectado por un rasonmware y debemos presentar el repositorio inmutable a otro server de Veeam, debemos recrear un usuario para darle los permisos al directorio y esto debe hacelo un user con privilegios sudo, por ello consulto, ¿no deberíamos conversar este usuario?

Hola

Entiendo tu pregunta / comentario.
No obstante, si llega el caso en que has sido impactado, y tienes que “re-conectar” tu backup inmutable, y para ello tener un usuario operativo, siempre es mejor gastar un poco de tiempo en conectarte físicamente al servidor, bootearlo y entrar en “recovery mode”, crearte el usuario y re-conectar, y una vez re-conectado, volver a quitarlo, así estás seguro al 100% que no tienes una forma de ser impactado.

Por muchos caracteres, password complicado, etc… que le pongas al usuario, siempre queda la posibilidad de que lo acaben descubriendo, por fallo humano, brute force, etc.

Espero te sirva mi pequeña literatura.

un saludo.

Luis F.- HunterLF - HunterLAFR - lfconsulting.org
G
Userlevel 3

Hola, ¿Cómo están? Ayer me recordé de este post ya que revisando un caso con un compañero encontré que aun cuando el usuario ha sido deshabilitado del grupo sudo, inicio sesion y tengo permisos sobre el repositorio, (sigo practicando y estudiando acerca de linux), me llamo increíblemente la atención la siguiente imagen,

 

Creo que el usuario del repositorio definitivamente no debería de existir…. Ahora bien, ¿al borrarlo igual se puede crear uno en modo de recuperación y asignar los permisos y todo esto?

Comment


Terms & Conditions