Digamos que un atacante obtiene acceso de sudo a un servidor que contiene información crítica para el negocio. Luego, cambia la clave pública asociada con el usuario Bob a su propia clave pública. Elimina toda la evidencia de esta acción mediante el acceso a sudo y luego inicia sesión como Bob con su clave privada. Ahora registrado como Bob, él hace algunas cosas desagradables y esto puede poner a Bob en problemas.
¿Hay algún tipo de protección contra este tipo de comportamiento?
¿Hay algún tipo de protección contra este tipo de comportamiento?
¿Además de proteger el servidor tanto como sea posible? No. Y ni siquiera es necesario cambiar las llaves o lo que sea. Root puede hacer todo, incluso imitar a Bob sin cambiar la clave.
Fail2ban, Snort, SeLinux, etc.etc. ... Úsalos apropiadamente.
...
Para root logins , es decir. no algún error que permita hacer algo específico, y no necesariamente por alguien fuera de la empresa ... si está muy preocupado por el personal de TI malicioso, etc., algún tipo de sistema de "revisión por pares" podría ayudar (y cámaras, puertas de acero, sin puertos USB, sin tornillos, hardware autodestructivo (sí) ... bueno, debe saber qué tan confiables son sus colegas).
Cada máquina informa los inicios de sesión de raíz a otra máquina independiente (antes de que la persona que inicia sesión pueda evitarlo y, si falla la información, falla el inicio de sesión). Y cada acceso tiene que ser aprobado y supervisado por un segundo empleado. Un acceso registrado sin dos firmas en el formulario significa que hay una violación, todo desde entonces ya no es confiable.
Lea otras preguntas en las etiquetas public-key-infrastructure ssh rsa