No sé si he entendido bien el caso pero ahí va.
Yo iría pensando en Puppet. Tener controladas las máquinas con Puppet, y en
el momento que vayan a dejar de tener mantenimiento... ZASSSSS les
desinstalas,borras,cambias passwords o lo que quieras. Además te daría la
potencia de controlar y cambiar configuraciones de las máquinas que sí son
clientes.
Un saludo
El 26 de febrero de 2016, 12:04, Albert Casas <frozenset@xxxxxxxxx>
escribió:
Gracias por las respuestas. Esta claro que todo esto se tendría que haber
hecho antes de entregar nada y dejar más claro lo que se contrata, pero se
hizo hace años y ahora es cuando explota. Todo esto es más que nada para
tener en cuenta que podría hacer de ahora en adelante para que no se den
más situaciones parecidas a esta, a parte de revisar como están vendiendo
todo esto y con que condiciones.
Saludos!
El 26 de febrero de 2016, 11:56, Hugo Segovia <hugoac2004@xxxxxxxxx>
escribió:
Si el amigo no aplicó todas esas precauciones ANTES de entregar el
servidor al cliente, a ver cómo las aplica ahora. Especialmente con las
intenciones que tiene éste.
A ver cómo se le explica al cliente que hay que "destripar el servidor,
capar todos los enchufes, aplicar cifrado al disco entero, limitar todos
los accesos remotos, etc". Se podría probar invocando la "amenaza" de
los "juankers", el PRISM y cosas por el estilo... Si lo consigue, me
alegraré por él.
El vie, 26-02-2016 a las 11:43 +0100, Rafael Montero escribió:
Si tienen acceso físico y tú estás en Ring 3 puedes cifrar la
partición y que se busquen la vida.
También puedes crear un LKM y que te restablezca el password de root
por el tuyo siempre y cuando no cambien el kernel. ;)
El viernes, 26 de febrero de 2016, Sergio Navarro Fernández
<snavarrotd@xxxxxxxxx> escribió:
Además de ponerle pass a la BIOS y que en primer orden de
arranque sea el HDD, y el resto vacíos.
2016-02-26 11:38 GMT+01:00 M. Alex Hermosilla
<sasha.hs@xxxxxxxxx>:
Y que las conexiones sean solo por key y no por
contraseña, eso si usan ssh
2016-02-26 11:34 GMT+01:00 Sergio Navarro Fernández
<snavarrotd@xxxxxxxxx>:
Puedes deshabilitar el modo single-user, y
también los USB y lectores de CD/DVD, y pillar
con LUKS y cifrar todo el disco, pero
vamos... :/
2016-02-26 11:25 GMT+01:00 Hugo Cardozo
<hugoac2004@xxxxxxxxx>:
Si el cliente tiene acceso físico al
servidor en cuestión... Nada que
hacer. Podría hacer muchas cosas,
desde entrar al modo single-user hasta
arrancar un LiveUSB y tocar todo lo
que quiera
El 26 de febrero de 2016 7:16:08 AM
GMT-03:00, Albert Casas
<frozenset@xxxxxxxxx> escribió:
Buenas,
Desde hace más o menos un año,
trabajo llevando una especie
de suite de monitorización
basada en herramientas libres
(Nagios, NagVis, etc) y
scripts propios en Python
sobre Debian y por una cosa u
otra al final me he quedado yo
solo a cargo de la criatura.
Dicha "suite" se incluye en el
mantenimiento de las redes de
los clientes y se vende el
servicio de personalizarla a
su red, desplegarlo, efectuar
los cambios que quieran
mientras dure el contrato de
mantenimiento, soporte, y
desarrollo de nuevas funciones
que sean útiles a su negocio.
El caso es que últimamente un
par de clientes, al acabar su
contrato de mantenimiento, han
exigido "amablemente" que les
facilitemos los passwords de
root de dicha suite o que nos
lo revientan ellos a la
fuerza.
Mi duda es pues, y aún
sabiendo que no existe el
sistema de seguridad perfecto,
¿Existe alguna manera para ev
itar que un ente con dedos
prensiles presenciado donde
esta el servidor pueda
resetear u obtener el password
de root? ¿Hay alguna manera de
evitar que se acceda a Debian
en modo single-user?
Últimamente y para nuevas
versiones, me estoy planteando
integrar todo esto en una
maquina virtual o contenedor
en Proxmox VE, en caso de
tratarse de un sistema
virtualizado, ¿Podrían también
obtener/resetar el password de
root de la maquina virtual?
Gracias y propicios días.