15.3. Asegurando FreeBSD

15.3.1. Encapsulado SSH

15.3.2. Cortafuegos

15.3.3. IPsec

15.3.4. Asegurando la cuenta root y las cuentas de staff

Antés que nada, no se preocupe en asegurar las cuentas del staff si aun no ha asegurado la cuenta root. La mayor parte de los sistemas tienen asignada una clave de acceso a la cuenta root. Lo primero que usted debe asumir es que la contraseña siempre está comprometida. Esto no significa que tenga que eliminar la contraseña. La contraseña es casi siempre necesaria para el acceso a la cónsola de la computadora. Esto significa que usted no debe permitir utilizar la contraseña fuera de la cónsola o usarla posiblemente con el comando su(1). Por ejemplo, cerciorese de que sus ptys sean correctamente especificados como inseguros en el archivo /etc/ttys para rechazar conexiones directas a root vía telnet o rlogin. Si se usan otros servicios tales como sshd, asegurese de que las conexiones directas a root estén deshabilitadas. Es posible hacer esto editando el fichero /etc/ssh/sshd_config, asegurando que PermitRootLogin esté fijado como NO. Considere cada método de acceso - Servicios como FTP puedes tener problemas de seguridad. Las conexiones directas a root deben ser sólo permitidas físicamente en la cónsola de sistema.

Por supuesto, como administrador de sistema usted debe poder acceder como root, y nosotros tenemos algunas formas de conseguirlo. Nos aseguraremos de que éstas formas tengan autenticación adicional. Una de las formas de hacer root accesible es agregar cuentas apropiadas del staff al grupo wheel (en /etc/group). Se permite a los miembros del staff puestos en el grupo wheel usar el comando su para acceder root. Nunca debe dar a miembros del staff acceso nativo a wheel cuando se crea la cuenta. Las cuentas del staff deben estar colocadas en grupos de staff, para después agregar a aquellos deseados al grupo wheel en el fichero /etc/group. Solamente a aquellos que realmente se necesiten en este grupo deben ser agregados. Es también posible usar un método de autentificación tal como Kerberos, utilizar el fichero .k5login en la cuenta root para permitir a ksu(1) que root no necesite a nadie en el grupo wheel. Esta puede ser una mejor solución puesto que el mecanismo de wheel todavía permite al intruso romper root, si el intruso ha conseguido quebrar el archivo de contraseñas y el grupo del staff. Mientrás que usar el mecanismo de wheel es mejor que no tener nada en lo absoluto, no es necesariamente la opción mas segura.

Una manera indirecta de asegurar las cuentas del staff y usar el acceso a root de ultima instancia es usar un método de acceso alternativo conocido como “starring”. Este método marca las contraseñas cifradas con un solo “*”. Este comando actualizará fichero de /etc/master.passwd y la base de datos de usuario/contraseña para desabilitar los logins con autentificación de contraseña.

Una cuenta del staff como esta:

foobar:R9DT/Fa1/LV9U:1000:1000::0:0:Foo Bar:/home/foobar:/usr/local/bin/tcsh

Debe ser cambiada a:

foobar:*:1000:1000::0:0:Foo Bar:/home/foobar:/home/local/bin/tcsh

Este cambio evitará que las conexiones normales ocurran, ya que la contraseña cifrada nunca coincidirá con “*”. Habiendo hecho esto, los miembros del staff deberán usar otros métodos de autentificación como kerberos(1) o ssh(1), usando pares de claves públicas/privadas. Al usar algo como Kereberos, uno debe asegurar generalmente las máquinas que corran los servidores Kereberos, asi como también su estación de trabajo. Al usar pares de claves públicas/privadas con ssh, uno debe asegurar generalmente la máquina usada para hacer el login (generalmente una estación de trabajo). Una capa adicional de protección se puede agregar a los pares de claves públicas/privadas protegiendolas con contraseña en el momento de crearlas con ssh-keygen(1). Pudiendo “marcar” las contraseñas de las cuentas del staff también garantiza que los miembros del staff solamente pueden acceder al sistema por medio de un método seguro. Esto fuerza a los miembros del staff a acceder al sistema usando solamente formas seguras y conexiones cifradas para todas sus sesiones, lo que protege de una de las vulnerabilidades más usadas por los intrusos.