En este capítulo, aprenderemos a determinar si el root tiene posibilidad de conexión remota. Este control es un control crítico, porque el riesgo que deriva de esta parametrización es, posiblemente, el más crítico en una infraestructura UNIX.
A título particular, creo que permitir conexiones remotas de root no es una medida aconsejable. Es mucho más trazable y seguro que los usuarios remotos de autentiquen contra la máquina, y que en caso de necesitar poderes de súper usuario, hagan uso de su para elevar sus privilegios, lo que permite además, disponer de logs específicos para este control, como por ejemplo, sulog, cuya ubicación típica es /var/adm/sulog en máquinas Solaris o /etc/login.defs en entornos Linux, por citar dos meros ejemplos.
El root es el dueño de la máquina, y por tanto, tiene control total sobre la misma. El principal riesgo no es sólo el control total sobre todo, sino la posibilidad de ir borrando huellas en una intrusión. Si tomo el control como root en una máquina, puedo detener los mecanismos de seguridad y eliminar mis trazas a mi antojo. Una de mis críticas más fuertes a otros sistemas no UNIX, como Windows, siempre la encarrillo a la prácticamente inexistente cultura de segregación de funciones por parte de sus usuarios y administradores: en la mayoría de los casos, especialmente en el ámbito doméstico, los usuarios, lejos de perfilar, prefieren ejercer su actividad como Administradores de manera perpetua. Son muy pocos (y me viene a la cabeza mi amigo De Los Santos, gran defensor de esta metodología) los que entienden que el usuario Administrador sólo debe ser usado para lo que ha sido concebido: administrar la máquina.
Explicado el trasfondo del problema, pasamos a ejemplificar cómo saber si el root puede o no establecer conexión directa contra la máquina. Utilizaremos para nuestro ejemplo la configuración Solaris, dejando claro que la variabilidad en esta parametrización es muy diferente, en función a la plataforma que analicemos. Así pues:
- En Solaris, IRIX, NCR UNIX, Reliant, SCO UnixWare y DG-UX inspeccionaremos el fichero /etc/default/login. La excepción es Sun OS 4, en cuyo caso se recurrirá a /dev/ttytab
- En Linux y HP-UX echaremos un vistazo a /etc/securetty
- En derivados BSD, habrá que analizar /etc/ttys, con la excepción de FreeBSD, donde habrá que contemplar también el fichero etc/login.access de manera complementaria.
- En AIX, el análisis se ceñirá al fichero /etc/security/user
- Tru64 y ULTRIX utilizan /etc/securettys
Ejemplo práctico
En una máquina Solaris, para determinar si el root puede hacer conexiones remotas, verificaremos si la definición CONSOLE=/dev/console en los contenidos de /etc/default/login está comentada o no, pudiendo ocurrir tres cosas:
- #CONSOLE=/dev/console implica que el root puede conectar remotamente al sistema
- CONSOLE=/dev/console implica que el root no puede acceder remotamente al sistema. Debe estar físicamente en la consola del sistema
- CONSOLE=/dev/console no aparece, lo que deja la puerta abierta a conexiones root por SSH, como podéis ver al final en la nota IMPORTANTE.
En nuestro ejemplo, los contenidos de /etc/default/login son
# If CONSOLE is set, root can only login on that device.
# Comment this line out to allow remote login by root.
#
CONSOLE=/dev/console
El root puede acceder remotamente. Como no podía ser de otro modo, la instalación por defecto de Solaris no permite conectividad remota del root.
Si el fichero /etc/default/login es muy largo, podemos hacer una consulta del tipo:
grep -v «^#» /etc/default/login
Otro ejemplo
En una máquina Linux, recurriremos a etc/securetty:
cat /etc/securetty
# /etc/securetty: list of terminals on which root is allowed to login.
# See securetty(5) and login(1).
console
En este caso, es posible el acceso root remoto.
IMPORTANTE
Salvo excepciones contadas, cuidado con las conexiones SSH. Para impedir el acceso root SSH, debemos restringir el acceso vía SSH en la configuración del demonio. Para ello, añadiremos la siguiente línea a sshd.conf
Permit root login no
Un archivo /etc/securetty o /etc/default/login en blanco o con el tty comentado no previene que el usuario root conectarse remotamente usando las herramientas OpenSSH. Esto se debe a que la consola se abre después de la autenticación, con lo que en ausencia de una parametrización expresa de la consola del terminal como único medio de permitir acceso al root, podemos estar dejando una importante vía de acceso al sistema.
Resumen
Conocer si el root puede conectarse remotamente a una máquina es de vital importancia, ya que es el usuario con más poder en el sistema.
No obstante, dependiendo del despliegue, se asume que se puede permitir conexión remota de root a la consola para casos de emergencia. Esta opción sólo es recomendable para sistemas de producción no expuestos al exterior de la organización, de modo que contengamos el riesgo al factor interno. En este contexto, el riesgo residual es el de fraude interno, aceptado en estos ámbitos por la presunción de que los operadores actuarán conforme a procedimientos y de una manera honesta, además de existir no sólo una correcta custodia y fortaleza de clave root, sino una aplicación de controles para evaluar la utilización de este usuario.
Gran defensor y también gran «sufridor» de la metodología del «no administrador» en Windows. No es precisamente cómodo, pero bueno, con muchos trucos en la manga, se sobrelleva bastante bien con el tiempo. Y las ventajas, como apuntas, son infinitas. Los pocos que han querido emularme en el ámbito doméstico (apenas un amigo sigue mi recomendación desde hace unos meses) son mucho más felices con su sistema desde entonces.
«En la sombra», sigo con interés tu serie de auditoría. ;-)
DLS,
You´re welcome :)
El por qué SSH necesite explícitamente denegar el permiso de conexión al usuario «root» radica en el hecho de que SSH no utiliza /bin/login para iniciar la sesión.
/bin/login muestra el indicador de conexión para que el usuario introduzca su identificar y su contraseña — es posible utilizar /bin/login de forma que se le indique el nombre de usuario para que éste pregunte exclusivamente por la contraseña. De forma resumida, una vez que /bin/login ha validado las credenciales, éste se encarga de crear una nueva sesión para el usuario, normalmente creando un nuevo proceso, haciendo que éste sea el controlador del terminal y el líder de grupo y después invocar la llamada al sistema exec() para ejecutar el intérprete de comandos por defecto de dicho usuario. Durante el proceso descrito anteriormente, /bin/login (a través del módulo PAM pam_securetty.so) consulta el archivo /etc/securetty para contolar desde qué terminales se permite la conexión como «root».
SSH no utiliza /bin/login, sino que es el propio servicio SSH el que crea la sesión para el usuario de forma autónoma. Una de las razones por las que SSH no emplea /bin/login es el uso de autentificación basada en clave pública.
Otras herramientas, como telnet o getty, sin embargo, sí que utilizan /bin/login, y por ello se ven sometidas a las restricciones de acceso de root especificadas en /etc/securetty, por ejemplo.
Felipe,
Sentando cátedra, como es habitual en tí. Gracias por la explicación extendida. Muy instructiva :)
en solaris,
#cd /etc/ssh
#vi sshd_config
reemplazar la linea: PermitRootLogin no/yes
luego reiniciar el servicio:
#svcadm restart ssh
Buenas tardes,
Una pregunta, que no tiene nada que ver con el tema ante expuesto.
Tengo una duda Mayuscula, en relacion a los privilegio de ROOT. La pregunta es la siguiente.
Como puedo asignarle privilegios de root un usuario corriente, pero que no sea con Roles y Perfiles (RCBA)
si el usuario pertenece al grupo GUID=14 grupo sysadm puede tener los privilegios de root
Gracias y saludos!!!!!
Amigo ,CONSOLE=/dev/console implica que el root puede acceder solo de la consola de la maquina, no permite la conexion remota del root.
Saludos
Hector,
En Solaris, dentro del fichero /etc/default/login, hay dos maneras de tratar CONSOLE=/dev/console
a) Sin comentar, es decir, CONSOLE=/dev/console, lo que implica que el root sólo se puede conectar como tal a la máquina si está físicamente sentado en la consola del sistema
b) Comentar, es decir, #CONSOLE=/dev/console, lo que implica que el root puede conectar desde cualquier punto de la red o incluso desde cualquier «dumb terminal» conectado al sistema
Tienes razón, en el artículo está al revés :D Corrijo de inmediato.
Saludos!