Tengo un servidor Mi servidor es seguro, pero imaginemos un buen hacker que ingrese. Ahora puede investigar /etc/passwd
y /etc/shadow
. Me gustaría cambiar el nombre de esos archivos /etc/passwd
a algo así /etc/xxanoda
.
Pensé que podía hacer un enlace, pero para un hacker será fácil de hacer ls -l
.
¿Es posible cambiar el nombre de esos archivos y todavía tener un sistema operativo en ejecución, sin problemas de compatibilidad, o es completamente inútil? Solo por la búsqueda del conocimiento.
Respuestas:
El Estándar de Jerarquía del Sistema de Archivos para sistemas tipo Unix incluye
/etc/passwd
en una ubicación fija, y por lo tanto, las herramientas generalmente están codificadas para buscarlo. Si bien, en teoría, podría volver a compilar todas las utilidades relevantes para buscar en una nueva ubicación, cualquier atacante siempre podría buscar cadenas en esos binarios para ubicar el nuevo archivo, o usar expresiones regulares para encontrar archivos conpasswd
contenidos similares.El
shadow
archivo debe ser legible solo pararoot
(y posiblemente para un grupo llamadoshadow
). Si un atacante ha logrado obtener acceso de root a su sistema, tiene el control completo y si puede o no leer sus archivos passwd / shadow es bastante irrelevante en ese momento.Es posible que haya algunas situaciones en las que podría ayudar tener archivos que no están en los lugares esperados, por ejemplo, si tiene un servidor web mal configurado que permite que alguien solicite
http://myserver/../../etc/passwd
, pero en general este tipo de indirección requerirá mucho trabajo para un beneficio de seguridad mínimo.fuente
/etc/passwd
todos modos , ¿verdad?Lo mejor que podría ser es "completamente inútil" como usted lo dice. (No proporciona un obstáculo adicional para un intruso)
/etc/passwd
contiene nombres de cuenta, pero cualquiera que tenga acceso de shell al sistema podrá encontrarlos./etc/shadow
contiene información confidencial (el hash de la contraseña) pero es legible solo para root. Si un intruso logró obtener privilegios de root, ¿cómo se deletrea el desastre ?fuente
En los Unices modernos (y los Me gusta de Unix, incluido Ubuntu),
/etc/passwd
no contiene ningún secreto. Cambiarle el nombre sería más problemático de lo que vale, dada la cantidad de servicios públicos que tendrían que reconstruirse para buscarlo en su nueva ubicación./etc/shadow
Es otro asunto, ya que hay secretos en ese archivo, pero renombrarlo no ayudará. Solo es legible por root, por lo que incluso si un hacker ingresa al sistema como otro usuario, eso no es suficiente para acceder al archivo. Es por eso que las contraseñas se eliminaron/etc/passwd
en primer lugar: todos deben poder leer/etc/passwd
, pero solo la raíz debe poder obtener las contraseñas reales, por lo que las contraseñas se movieron a un archivo que solo la raíz podría leer.Si el hacker hace llegar la raíz, entonces un cambio de nombre no te salvará. Un simple recursivo
grep
podría darle al pirata informático una lista de archivos en un/etc/shadow
formato similar, y luego el pirata informático solo tiene que revisarlos para encontrar los datos que desea. Lo ha retrasado unas horas como máximo, y probablemente menos: nuevamente, no vale la pena el tiempo que tomaría modificar y recompilar todas las utilidades que dependen de/etc/shadow
la ubicación.fuente
su
ingresar a la cuenta que desee, o puede cambiar la contraseña de cualquier usuario en el sistema. Y si realmente quiere tener las contraseñas (en caso de que los usuarios reutilicen sus contraseñas en otro lugar), puede cargar unlogin
binario modificado o agregar unpam
módulo que intercepte los intentos de autenticación y le transmita las combinaciones de nombre de usuario / contraseña.No puede simplemente cambiar el nombre de estos archivos. Muchos procesos y programas los buscarán, ya que este es un estándar en los sistemas Linux. Lo que puede hacer es asegurar su servidor de la manera adecuada.
fuente
Si bien es probable que no tenga sentido cambiar el nombre de los archivos
/etc/passwd
y/etc/shadow
, si desea mayor seguridad, es posible que desee ver PAM (módulos de autenticación conectables) y NSS (cambio de servicio de nombres). Como aquí.PAM se puede utilizar para agregar módulos de autenticación que, en lugar de leer su información de autenticación de los archivos estándar, la leen de otra fuente, como ldap o una base de datos. Usarlo significaría que
/etc/shadow
puede eliminarse casi por completo.NSS complementa PAM al hacer que parte de la resolución de nombres (como a qué grupos pertenece este usuario) sea independiente de los archivos estándar (
/etc/passwd
,/etc/groups
). Usarlo significaría que su archivo passwd solo contendrá una opción alternativa para root, y nada más. El uso de claves SSH para validar el inicio de sesión raíz también eliminaría la necesidad de tener una contraseña raíz dentro del archivo sombra (aunque podría ser deseable si se rompe la conexión SSH).Alternativamente, si no desea autenticar a sus usuarios a través de una base de datos separada o un host ldap, también puede crear sus propios módulos PAM y NSS, que leen sus datos de un archivo no estándar, aunque no recomendaría esta opción.
Cuando desee tratar de usarlos, nunca olvide mantener algún tipo de respaldo a una capa de autenticación conocida y funcional, de lo contrario, puede bloquearse del sistema, incluso con root.
Tenga en cuenta que no todas las aplicaciones admiten PAM (sin embargo, muchas de ellas lo hacen). Sin embargo, NSS puede usarse para implementar la autenticación para aplicaciones que no son compatibles con PAM, y algunos sitios que he leído sobre NSS realmente sugieren este enfoque. Sin embargo, esto significa que el módulo NSS proporcionará la contraseña (potencialmente) cifrada a cualquiera que pueda acceder a la capa de autenticación NSS, lo cual es casi siempre algo que desea evitar (básicamente es lo mismo que otorgar acceso de lectura no root al archivo shadow) )! Entonces, si sigue este enfoque, asegúrese siempre de que NSS solo se use para proporcionar al usuario los datos básicos (como el contenido de
/etc/passwd
), y que PAM se use como la capa de autenticación.fuente