Red Hat Training

A Red Hat training course is available for Red Hat Enterprise Linux

Capítulo 2. Cómo proteger la red

2.1. Seguridad de estación de trabajo

La protección de un entorno de Linux comienza por la estación de trabajo. Ya sea al bloquear una máquina personal o protegiendo un sistema empresarial, la política de seguridad sólidacomienza por el computador personal. La red de computadores es tan segura como su nodo más débil.

2.1.1. Evaluación de la seguridad de la estación de trabajo

Al evaluar la seguridad de una estación de trabajo de Red Hat Enterprise Linux, considere lo siguiente:
  • BIOS y Seguridad del gestor de arranque — ¿Puede un usuario no autorizada acceder físicamente a la máquina y arrancar como usuario único o modo de rescate sin una contraseña?
  • Seguridad de contraseña — ¿Qué tan seguras están sus contraseñas de cuenta de usuario en la máquina?
  • Controles administrativos — ¿Quíen tiene una cuenta en el sistema y cuánto control administrativo tiene?
  • Servicios de redes disponibles — ¿Qué servicios escuchan las solicitudes desde la red y deben estarse ejecutando?
  • Cortafuegos personales — ¿Qué tipo de cortafuegos , si lo hay, es necesario?
  • Herramientas de protección de comunicación mejoradas — ¿Qué herramientas deben utilizarse para comunicarse entre estaciones de trabajo y cuáles deberían evitarse?

2.1.2. BIOS y seguridad del gestor de arranque

La protección de contraseñas para BIOS (o equivalente de BIOS) y el gestor de arranque pueden evitar que usuarios no autorizados tengan acceso físico a sistemas desde el arranque mediante medios extraíbles u obteniendo privilegios de root a través del modo de usuario único. Las medidas de seguridad que usted debe tomar para protegerse de dichos ataques dependen de la confidencialidad de la información y del sitio de la máquina.
Por ejemplo, si se usa una máquina en una feria de exposición y no contiene información confidencial, puede no ser fundamental prevenir esos ataques. Sin embargo, si se descuida el portátil de un empleado con llaves privadas SSH sin cifrar para la red corporativa en la misma exposición, podría conducir a un fallo de seguridad importante con consecuencias para toda la empresa.
Si la estación de trabajo se localiza en un lugar donde solamente personas autorizadas y de confianza tienen acceso, entonces el BIOS o gestor de arranque puede no ser necesario.

2.1.2.1. Contraseñas de BIOS

Las dos razones principales por las cuales se debe proteger el BIOS de un equipo[11]:
  1. Evitar cambios a la configuración del BIOS — Si los intrusos tienen acceso al BIOS, pueden configurarlo para que arranque desde un disquete o un CD-ROM. Esto les permite entrar en modo de rescate y a su vez, iniciar procesos arbitrarios en el sistema o copiar datos confidenciales.
  2. Evitar arrancar el sistema — Algunos BIOS permiten la protección de contraseña del proceso de arranque. Cuando están activados, el agresor es obligado a ingresar una contraseña antes de que el BIOS lance el gestor de arranque.
Puesto que los métodos para establecer una contraseña de BIOS varían entre los fabricantes de computadores, consulte las instrucciones específicas del manual del equipo.
Si olvida la contraseña de BIOS, se puede restablecer con puentes en la placa madre o desconectar la pila CMOS. Por esta razón, es una buena práctica bloquear la caja del computador si es posible. Sin embargo, consulte el manual para el equipo o la placa madre antes de intentar desconectar la pila de CMOS.
2.1.2.1.1. Cómo proteger las plataformas que no son x-86
Otras arquitecturas usan diferentes programas para realizar tareas de bajo nivel casi equivalentes a aquellos BIOS en sistemas x86. Por ejemplo, los computadores Intel® Itanium™ usan la shell de la Interfaz extensible de Firmware (EFI).
Para obtener instrucciones sobre programas para proteger BIOS con contraseñas en otras arquitecturas, consulte las instrucciones del fabricante.

2.1.2.2. Contraseñas de gestor de arranque

Las razones primarias para proteger con contraseñas un gestor de arranque de Linux son las siguientes:
  1. Evitar el acceso en modo monousuario — Si los agresores pueden arrancar el sistema en modo monousuario, se pueden registrar automáticamente como root sin que se les pida la contraseña de root.
  2. Evitar el acceso a la consola de GRUB — Si la máquina utiliza a GRUB como el gestor de arranque, el agresor puede utilizar la interfaz del editor de GRUB para cambiar la configuración o para reunir información mediante el comando cat.
  3. Evitar el acceso a sistemas operativos inseguros — Si se trata de un sistema de doble arranque, el agresor puede seleccionar un sistema operativo en tiempo de arranque (por ejemplo, DOS), el cual ignora los controles de acceso y los permisos de archivos.
Red Hat Enterprise Linux 6 se distribuye con el gestor de arranque GRUB en la plataforma x86. Para obtener una visión detallada de GRUB, consulte la Guía de Instalación de Red Hat.
2.1.2.2.1. Contraseña de protección de GRUB
Puede configurar GRUB para solucionar los primeros problemas que se listan en la Sección 2.1.2.2, “Contraseñas de gestor de arranque” al añadir una directiva de contraseña a su archivo de configuración. Para hacer esto, elija primero una contraseña fuerte, abra un shell, ingrese como root y luego escriba el siguiente comando: 
/sbin/grub-md5-crypt
Cuando se le indique, escriba la contraseña de GRUB y pulse Enter. De esta manera retorna un MD5 hash de contraseña.
Luego, modifique el archivo de configuración de GRUB /boot/grub/grub.conf. Abra el archivo y debajo de la línea timeout en la sección principal del documento, añada la siguiente línea: 
password --md5 <password-hash>
Remplace <password-hash> por el valor retornado por /sbin/grub-md5-crypt[12].
La próxima vez que el sistema reinicie, el menú de GRUB evitará el acceso al editor o interfaz de comandos sin presionar primero la p seguida de la contraseña de GRUB.
Lamentablemente, esta solución no evita que el agresor ingrese en un sistema operativo inseguro en el entorno de doble arranque. Para esto, se debe editar una parte del archivo /boot/grub/grub.conf.
Busque la línea de title del sistema operativo que desea proteger y añada una línea con la directiva lock inmediatamente.
Para un sistema de DOS, la estanza debe comenzar así: 
title DOS lock

Aviso

Una línea de password debe estar presente en la sección principal del archivo /boot/grub/grub.conf para que este método funcione correctamente. De lo contrario puede acceder a la interfaz del editor de GRUB y retirar la línea de bloqueo.
Para crear una contraseña diferente para un kernel o sistema operativo determinado, añada la línea lock a la estanza, seguida de una línea de contrasaña.
Cada estanza protegida por una contraseña única debe comenzar por líneas similares a las del ejemplo a continuación: 
title DOS lock password --md5 <password-hash>

2.1.3. Seguridad de contraseña

Las contraseñas son un método primario que Red Hat Enterprise Linux utiliza para verificar la identidad de usuario. Esta el la razón por la cual la seguridad de la contraseña es tan importante para proteger al usuario, la estación de trabajo y la red.
Por razones de seguridad, el programa de instalación configura el sistema para usar Secure Hash Algorithm 512 (SHA512) y contraseñas ocultas. Se recomienda no alterar esta configuración.
Si las contraseñas ocultas se desactivan durante la instalación, todas las contraseñas se almacenan como un hash de una vía en el archivo /etc/passwd, lo que hace al sistema vulnerable a ataques de piratas de contraseñas fuera de línea. Si el intruso puede obtener acceso a la máquina como un usuario normal, puede copiar el archivo /etc/passwd en su propia máquina y ejecutar cualquier cantidad de programas para descifrar las contraseñas. Si hay una contraseña insegura en el archivo, es sólo cuestión de tiempo antes de que el pirata la descubra.\n
Las contraseñas ocultas eliminan este tipo de ataque al almacenar hash de contraseñas en el archivo /etc/shadow, el cual únicamente puede ser leído por el usuario root.
Esto obliga al agresor potencial a intentar descubrir la contraseña de forma remota al ingresar a servicios de redes tales como SSH o FTP. Este tipo de ataque de fuerza bruta es mucho más lento y deja un rastro evidente, pues los intentos fallidos de conexión son registrados en los archivos del sistema. Por supuesto, si el cracker comienza un ataque en medio de la noche en un sistema con contraseñas débiles, el atacante podrá obtener acceso antes del amanecer y editar los archivos de registro para cubrir sus huellas.
Además del formato y las consideraciones de almacenamiento está el problema del contenido. Lo más importante que el usuario debe hacer para proteger la cuenta de un ataque de violación de contraseñas es crear una contraseña fuerte.

2.1.3.1. Cómo crear contraseñas fuertes

Al crear una contraseña segura, es una buena idea seguir estos lineamientos:
  • No utilice solo palabras o números — Nunca use únicamente números o palabras en la contraseña.
    Algunos ejemplos inseguros se incluyen a continuación:
    • 8675309
    • juan
    • hackme
  • No utilice palabras reconocibles — Palabras tales como nombres propios, palabras de diccionario, o incluso términos de los programas de televisión o novelas deben evitarse, incluso si terminan en números.
    Algunos ejemplos inseguros se incluyen a continuación:
    • john1
    • DS-9
    • mentat123
  • No utilice palabras en otro idioma — Los programas para descubrir contraseñas suelen comparar todas las listas de los diccionarios en muchos idiomas. Depender de idiomas extranjeros para proteger sus contraseñas no es seguro.
    Algunos ejemplos inseguros se incluyen a continuación:
    • cheguevara
    • bienvenido1
    • 1dumbKopf
  • No utilice terminología de hacker — Si piensa que pertenece a una élite porque utiliza en su contraseña terminología de hacker — conocida también como l337 o LEET — ¡piénselo dos veces!. Muchas listas de palabras incluyen LEET.
    Algunos ejemplos inseguros se incluyen a continuación:
    • H4X0R
    • 1337
  • No use información personal — Evite el uso de información personal en sus contraseñas. Si el agresor conoce su identidad, la tarea de deducir su contraseña será más fácil. A continuación se enumeran los tipos de información que se deben evitar al crear una contraseña:
    Algunos ejemplos inseguros se incluyen a continuación:
    • Su nombre
    • Los nombres de mascotas
    • Los nombres de miembros de familia
    • Las fechas de cumpleaños
    • Su número telefónico o código postal
  • No ponga al revés palabras reconocibles — Los revisores de contraseñas siempre reversan las palabras comunes, por lo tanto al invertir una mala contraseña no la hace más segura.
    Algunos ejemplos inseguros se incluyen a continuación:
    • R0X4H
    • nauj
    • 9-DS
  • No anote su contraseña — Nunca escriba una contraseña en papel. Es más seguro memorizarla.
  • No use la misma contraseña para todas las máquinas — Es importante crear contraseñas independientes para cada máquina. De esta forma si un sistema pierde su caracter confidencial, no todas sus máquinas estarán en riesgo.
Los lineamientos a continuación le ayudarán a crear una contraseña fuerte:
  • Cree una contraseña de por lo menos ocho caracteres — Entre más larga su contraseña, mejor. Si utiliza contraseñas MD5, debe ser por lo menos de 15 caracteres. Con contraseñas DES, use la longitud máxima (ocho caracteres).
  • Mezcle letras mayúsculas y minúsculas — Red Hat Enterprise Linux es sensible a mayúsculas y minúsculas, por lo tanto, mezcle las mayúsculas y minúsculas para fortalecer la contraseña.
  • Mezcle letras y números — Si añade números a contraseñas, especialmente en el medio (no solo al comienzo o al final), puede mejorar la fortaleza de la contraseña.
  • Incluya caracteres no alfanuméricos — Caracteres especiales tales como &, $, y > pueden mejorar ampliamente la fortaleza de la contraseña (no es posible si se utilizan contraseñas DES).
  • Elija una contraseña que usted recuerde — La mejor contraseña del mundo no sirve de nada si usted no la recuerda; use acrónimos u otros dispositivos nemotécnicos para ayudar a memorizar las contraseñas.
Con todas estas reglas, puede parecer difícil crear una contraseña que cumpla todos los criterios de buenas contraseñas evitando al mismo tiempo las características de una mala. Afortunadamente, hay algunos pasos que puede seguir para generar una fácil de recordar, contraseña segura.
2.1.3.1.1. Metodología para la creación de una contraseña segura
Hay varios métodos que se pueden utilizar para crear contraseñas seguras. Uno de los métodos más conocidos tiene que ver con los acrónimos. Por ejemplo:
  • Piense en una frase fácil de recordar, tal como esta en Inglés:
    "over the river and through the woods, to grandmother's house we go."
  • Luego conviértala en un acrónimo (incluyendo la puntuación)
    otrattw,tghwg.
  • Añada complejidad al sustituir por números y símbolos las letras en el acrónimo. Por ejemplo, substituya 7 para t y el símbolo de arroba (@) para a:
    o7r@77w,7ghwg.
  • Añada más complejidad al poner en mayúsculas al menos una letra, tal como H.
    o7r@77w,7gHwg.
  • Por último, no utilice nunca la contraseña del ejemplo anterior para ningún sistema.
Aunque la creación de contraseñas seguras es imperativa, manejarlas adecuadamente es también importante, especialmente para los administradores de sistemas dentro de grandes organizaciones. La siguiente sección describe buenas prácticas para crear y administrar contraseñas de usuarios dentro de una organización.

2.1.3.2. Cómo crear contraseñas de usuario dentro de una organización

Si una organización tiene un gran número de usuarios, los administradores de sistemas tienen dos opciones básicas disponibles para forzar el uso de buenas contraseñas. Pueden crear contraseñas para el usuario o dejar que los usuarios creen sus propias contraseñas, verificando que las contraseñas sean de una calidad aceptable.
La creación de contraseñas para los usuarios garantiza que las contraseñas sean buenas, pero se convierte en una tarea de enormes proporciones cuando la organización crece. También aumenta el riesgo de que los usuarios anoten las contraseñas.
Por estas razones, la mayoría de los administradores de sistemas prefieren dejar que los usuarios creen sus propias contraseñas, pero activamente verificar que las contraseñas sean buenas y, en algunos casos, obligarlos a cambiar sus contraseñas periódicamente a través de la caducidad de contraseñas.
2.1.3.2.1. Cómo forzar contraseñas fuertes
Para proteger la red de intrusos es una buena idea que los administradores de sistemas verifiquen si las contraseñas utilizadas dentro de la organización son fuertes. Cuando se les solicita a los usuarios crear o cambiar contraseñas, pueden utilizar la aplicación de línea de comandos passwd, la cual reconoce los Módulos de autenticación conectables (PAM) y por lo tanto verifica si la contraseña es demasiado corta o fácil de averiguar. Esta revisión se realiza mediante el módulo PAM de pam_cracklib.so. Puesto que PAM puede personalizarse, es posible añadir más revisores de integridad de contraseñas, tales como pam_passwdqc (disponible en http://www.openwall.com/passwdqc/) o escribir un nuevo módulo. Para obtener una lista de los módulos PAM disponibles, consulte http://www.kernel.org/pub/linux/libs/pam/modules.html. Para mayor información sobre PAM, consulte Managing Single Sign-On and Smart Cards.
La revisión de contraseñas que se realiza en el momento de creación no descubre las contraseñas malas de forma tan efectiva como al ejecutar un programa de violación de contraseñas que compara contraseñas.
Muchos programas de contraseñas que están disponibles se pueden ejecutar bajo Red Hat Enterprise Linux, aunque ninguna se envía con el sistema operativo. A continuación una breve lista de algunos de los programas más conocidos para violar contraseñas:
  • John The Ripper — Un programa rápido y flexible de violación de contraseñas. Permite el uso de múltiples listas de palabras y puede usar la fuerza bruta para violar las contraseñas. Está disponible en http://www.openwall.com/john/.
  • Crack — Quizás el software de violación de contraseñas más conocido, Crack también es rápido, aunque no fácil de usar como John The Ripper. Puede encontrarlo en http://www.crypticide.com/alecm/security/crack/c50-faq.html.
  • Slurpie — Slurpie es una aplicación similar a John The Ripper y Crack, pero está diseñada para ser ejecutada en varios equipos al mismo tiempo, creando un ataque de violación de contraseñas distribuido. Se encuentra junto con otro número de herramientas de evaluación de seguridad de ataques distribuidos en http://www.ussrback.com/distributed.htm.

Aviso

Siempre obtenga autorización escrita antes de intentar violar contraseñas dentro de una organización.
2.1.3.2.2. Frases de paso
Las frases de paso y contraseñas son la piedra angular de la seguridad en la mayoría de los sistemas actuales. Infortunadamente, las técnicas tales como la biometría y la autenticación de dos factores aún no han convertido aún no se han establecido en muchos sistemas. Si se van a utilizar contraseñas para asegurar un sistema, entonces se debe considerar el uso de una frase de paso. Las frases de paso son más largas que las contraseñas y proporcionan una mejor protección de una contraseña, incluso cuando se implementan con caracteres no estándar, tales como números y símbolos.
2.1.3.2.3. Caducidad de las contraseñas
La caducidad de las contraseñas es una técnica utilizada por los administradores de sistemas para protegerse de las malas contraseñas dentro de una organización. La caducidad de la contraseña significa que después de un período determinado (generalmente 90 días), se pide al usuario crear una nueva contraseña. La teoría detrás de esto es que si un usuario se ve obligado a cambiar la contraseña periódicamente, una contraseña que ha sido descubierta solamente será útil para el intruso por un periodo limitado de tiempo. No obstante, la desventaja de la caducidad de las contraseñas, es que los usuarios tienden más a anotar sus contraseñas.
Hay dos programas principales utilizados para especificar la caducidad de las contraseñas bajo Red Hat Enterprise Linux: el comando chage o la aplicación gráfica Administrador de usuario (system-config-users).
La opción -M del comando chage especifica el número de días máximo que la contraseña es válida. Por ejemplo, para establecer una contraseña de usuario que expire en 90 días, use el siguiente comando: 
chage -M 90 <username>
En el comando anterior, remplace <username> por el nombre del usuario. Para desactivar la expiración de la contraseña, se acostumbra a usar el valor de 99999 después de -M (esto equivale a un poco más de 273 años).
También puede usar el comando chage en modo interactivo para modificar la caducidad de varias contraseñas e información de cuentas. Use el siguiente comando para ingresar en modo interactivo: 
chage <username>
El siguiente es un ejemplo de una sesión interactiva con este comando: 
[root@myServer ~]# chage davido 
Changing the aging information for davido 
Enter the new value, or press ENTER for the default 
Minimum Password Age [0]: 10
Maximum Password Age [99999]: 90 
Last Password Change (YYYY-MM-DD) [2006-08-18]: 
Password Expiration Warning [7]: 
Password Inactive [-1]: 
Account Expiration Date (YYYY-MM-DD) [1969-12-31]: 
[root@myServer ~]#
Consulte la página de manual de chage para obtener mayor información en las opciones disponibles.
También puede usar la aplicación gráfica Administrador de usuario para crear políticas de caducidad de contraseñas, como sigue. Nota: necesitará privilegios de administrador para realizar este procedimiento.
  1. Haga clic en el menú Sistema en el panel, señale Administración y luego haga clic en Usuarios y grupos para desplegar el administrador de usuario. De modo alternativo, escriba el comando system-config-users en el indicador de shell.
  2. Haga clic en la pestaña Usuarios y seleccione el usuario requerido en la lista de usuarios.
  3. Haga clic en Propiedades en la barra de herramientas para desplegar el cuadro de diálogo del usuario (o elija Propiedades en el menú Archivo).
  4. Haga clic en Información de contraseña, y selecciones la cajilla de verificación para Habilitar expiración de contraseña.
  5. Ingrese el valor requerido en el campo Días antes del cambio requerido y haga clic en Aceptar.
Cómo especificar opciones de caducidad de contraseñas

Figura 2.1. Cómo especificar opciones de caducidad de contraseñas

2.1.4. Controles administrativos

Al administrar un equipo del hogar, el usuario debe realizar algunas tareas como usurio de root o adquirir privilegios de root efectivos a través de un programa de setuid, tal como sudo o su. Un programa de setuid es el que funciona con el ID de usuario (UID) del propietaio del programa en lugar del usuario que opera el programa. Dichos programas se indican con una s en la sección de listado de formato largo, como en el siguiente ejemplo: 
-rwsr-xr-x 1 root root 47324 May 1 08:09 /bin/su

Nota

La s puede estar en minúscula o mayúscula. Si aparece en mayúscula, significa que el bit de permiso subyacente aún no se ha establecido.
Sin embargo, para los administradores de sistemas de una organización, la elección debe hacerse en cuánto acceso administrativo deben tener los usuarios deben tener en su máquina. A través de un módulo PAM llamado pam_console.so, algunas actividades normalmente reservadas para el usuario root, tales como reinicio o el montaje de medios extraíbles, para el primer usuario que ingrese en la consola física (consulte la Managing Single Sign-On and Smart Cards para obtener más información acerca del módulo pam_console.so) Sin embargo, otras tareas administrativas del sistema, tales como alterar la configuración de red, configurar un nuevo ratón o montar dispositivos de red, no son posibles sin privilegios de administrador. Como resultado, los administradores de sistemas deben decidir cuánto acceso pueden tener los usuarios en la red.

2.1.4.1. Permitir acceso de root

Si los usuarios dentro de una organización son de confianza y tienen conocimientos de computación, entonces el darles acceso root no puede ser un problema. Permitir el acceso de root a los usuarios significa que las actividades de menor importancia, tales como añadir dispositivos o configurar interfaces de red, pueden ser manejadas por los usuarios individuales, dejando así a los administradores de sistemas libres para manejar la seguridad de la red y otros temas importantes.
Por otra parte, el dar acceso de root a usuarios individuales puede conducir a los siguientes problemas:
  • Error en la configuración de la máquina — Los usuarios con acceso de root pueden desconfigurar las máquinas y necesitarán ayuda para resolver los problemas. Peor aún, podrían abrir agujeros de seguridad sin saberlo.
  • Ejecutar servicios inseguros — Los usuarios con acceso de root pueden ejecutar servicios inseguros en sus máquinas, tales como FTP o Telnet, poniendo en riesgo los nombres de usuario y contraseñas. Estos servicios transmiten la información a través de la red en texto plano.
  • Ejecutar anexos de correo-e como root — Aunque escasos, los virus de correo-e que afectan a Linux existen. No obstante, el único momento en que son una amenaza, es cuando son ejecutados por el usuario root.

2.1.4.2. Desactivación del acceso root

Si un administrador no se siente bien al permitir a los usuarios iniciar una sesión como root por estas u otras razones, la contraseña de root debe mantenerse en secreto, y el acceso en nivel de ejecución uno o en modo de monousuario debe desactivarse a través de la protección de contraseña del gestor de arranque (consulte la Sección 2.1.2.2, “Contraseñas de gestor de arranque” para obtener mayor información sobre este tema.)
Tabla 2.1, “Métodos para desactivar la cuenta de root” describe las formas en que un administrador puede garantizar que los nombres de usuario de root están desactivados:

Tabla 2.1. Métodos para desactivar la cuenta de root

Método Descripción Efectos No afecta
Cambio de shell de root. Edite el archivo /etc/passwd y cambie el shell de /bin/bash a /sbin/nologin.
Evita el acceso al shell de root y registra los intentos.
Los siguientes programas no pueden acceden desde la cuenta de root:
· login
· gdm
· kdm
· xdm
· su
· ssh
· scp
· sftp
Los programas no requieren una shell, tal como clientes FTP, clientes de correo y muchos programas de setuid.
Los siguientes programas no impiden el acceso a la cuenta de root:
· sudo
· Clientes FTP
· Clientes de correo-e
Desactivación del acceso de root a través de un dispositivo de consola (tty). Un archivo vacío /etc/securetty impide el ingreso de root a los dispositivos conectados al equipo.
Impide el acceso a la cuenta de root a través de la consola o la red. Los siguientes programas no tienen acceso a la cuenta root:
· login
· gdm
· kdm
· xdm
· Otros servicios de red que abren una tty
Did you mean: The following programs are and prevented from accessing the root account:\nType text or a website address or translate a document.\nCancel\nEnglish - detected to Spanish translation\nLos programas que no inician una sesión como root, pero que realizan tareas administrativas a través de setuid u otros mecanismos.
Los siguientes programas no impiden el acceso a la cuenta de root:
· su
· sudo
· ssh
· scp
· sftp
Desactivación de nombres de usuario de root SSH. Edite el archivo /etc/ssh/sshd_config y establezca el parámetro PermitRootLogin a no.
Impide el acceso de root a través del conjunto de herramientas OpenSSH. A los siguientes programas se les impide acceder a la cuenta de root:
· ssh
· scp
· sftp
Únicamente impide el acceso de root al paquete de herramientas OpenSSH.
Use PAM para limitar el acceso de root a servicios. Edite el archivo para el servicio de destino en el directorio /etc/pam.d/. Asegúrese de que pam_listfile.so se requiera para la autenticación.[a]
Impide el acceso de root a los servicios de red que PAM reconoce.
Los servicios a continuación no tienen acceso a la cuenta de root:
· Clientes FTP
· Clientes de correo-e
· login
· gdm
· kdm
· xdm
· ssh
· scp
· sftp
· Todos los servicios que PAM reconoce
Los programas y servicios que PAM no reconoce.
2.1.4.2.1. Desactivación del shell de root
Para evitar que los usuarios ingresen directamente como root, el administrador de sistemas puede establecer el shell de la cuenta de root a /sbin/nologin en el archivo /etc/passwd. Así impide el acceso a la cuenta de root a través de los comandos que requieren un shell, tal como los comandos su y ssh.

Importante

Los programas que no requieren acceso al shell, tales como clientes de correo-e o el comando sudo, aún pueden acceder a la cuenta de root.
2.1.4.2.2. Desactivación de los nombres de usuario de root
Para limitar aún más el acceso a la cuenta de root, los administradores pueden inhabilitar las conexiones de root en la consola mediante la edición del archivo /etc/securetty. Este archivo muestra todos los dispositivos a los que el usuario de root puede conectarse. Si el archivo no existe en absoluto, el usuario puede conectarse a través de cualquier dispositivo de comunicación en el sistema, ya sea a través de la consola o una interfaz de red cruda. Esto es peligroso, ya que un usuario puede conectarse a su máquina como root a través de Telnet, la cual transmite por la red a contraseña en texto plano. De forma predeterminada, el archivo /etc/securetty de Red Hat Enterprise Linux solamente permite que el usuario de root inicie sesión en la consola conectada físicamente a la máquina. Para impedir que root ingrese, retire el contenido de este archivo mediante el siguiente comando: 
echo > /etc/securetty

Aviso

Un archivo en blanco /etc/securetty no impide que el usuario de root ingrese de forma remota mediante el paquete de herramientas de OpenSSH porque la consola no se abre sino después de la autenticación.
2.1.4.2.3. Desactivación de los nombres de usuario de root SSH
Los registros de root a través del protocolo SSH se desactivan por defecto en Red Hat Enterprise Linux 6; si esta opción ha sido habilitada, puede inhabilitarse de nuevo al editar el archivo de configuración del demonio (/etc/ssh/sshd_config). Cambie la línea que se lee: 
PermitRootLogin yes
Para que se lea: 
PermitRootLogin no
Para que estos cambios se efectúen, deberá reiniciar el demonio. Esto puede hacerse con el siguiente comando: 
kill -HUP `cat /var/run/sshd.pid`
2.1.4.2.4. Desactivación de root mediante PAM
PAM, a través del módulo /lib/security/pam_listfile.so, permite gran flexibilidad en la negación de cuentas específicas. El administrador puede usar este módulo para hacer referencia a una lista de usuarios que no tienen permiso de ingreso. A continuación verá un ejemplo de cómo se utiliza el módulo para el servidor FTP de vsftpd en el archivo de configuración /etc/pam.d/vsftpd (el caracter \ al final de la primera línea en el siguiente ejemplo no es necesario si la directiva está un una línea): 
auth required /lib/security/pam_listfile.so item=user \ 
sense=deny file=/etc/vsftpd.ftpusers onerr=succeed
Así le pide a PAM que consulte el archivo /etc/vsftpd.ftpusers y niegue el acceso al servicio para cualquier usuario en la lista. El administrador puede cambiar el nombre de este archivo y mantener listas independientes para cada servicio o usar una lista central para negar acceso a múltiples servicios.
Si el administrador desea negar acceso a múltiples servicios, se puede añadir una línea similar a los archivos de configuración PAM, tales como /etc/pam.d/pop y /etc/pam.d/imap para clientes de correo o /etc/pam.d/ssh para clientes SSH.
Para obtener mayor información sobre PAM, consulte Managing Single Sign-On and Smart Cards.

2.1.4.3. Limitación del acceso de root

En vez de negar completamente el acceso al usuario de root, el administrador puede desear permitir el acceso a través de programas de setuid, tales como su o sudo.
2.1.4.3.1. El comando su
Cuando un usuario ejecuta el comando su se le solicitará la contraseña de root y después de la autenticación, se le dará un indicador de shell de root.
Cuando el usuario ingresa a través del comando su, el usuario se convierte en el usuario de root y tiene acceso administrativo total en el sistema[13]. Además, una vez que el usuario se convierta en root, le será posible utilizar el comando su para cambiar a cualquier otro usuario en el sistema sin que se le solicite una contraseña.
Ya que este programa es tan poderoso, los administradores dentro de la organización pueden limitar el acceso al comando.
Una de las formas más sencillas de hacerlo es añadir usuarios al grupo administrativo especial llamado wheel. Para hacerlo, escriba el siguiente comando como root: 
usermod -G wheel <username>
En el comando anterior, remplace <username> por el nombre de usuario que desea añadir al grupo wheel.
También puede usar el Administrador de usuarios para modificar membresías de grupos, como se presenta a continuación. Nota: necesita privilegios administrativos para realizar este procedimiento.
  1. Haga clic en el menú Sistema en el panel, señale Administración y luego haga clic en Usuarios y grupos para desplegar el administrador de usuario. De modo alternativo, escriba el comando system-config-users en el indicador de shell.
  2. Haga clic en la pestaña Usuarios y seleccione el usuario requerido en la lista de usuarios.
  3. Haga clic en Propiedades en la barra de herramientas para desplegar el cuadro de diálogo del usuario (o elija Propiedades en el menú Archivo).
  4. Haga clic en la pestaña Groups, seleccione la cajilla de verificación para el grupo wheel y luego haga clic en el botón Aceptar. Consulte la Figura 2.2, “Adición de usuarios al grupo "wheel".”.
Adición de usuarios al grupo "wheel".

Figura 2.2. Adición de usuarios al grupo "wheel".

Abra el archivo de configuración PAM para su (/etc/pam.d/su) en un editor de texto y retire el comentario # de la siguiente línea: 
auth  required /lib/security/$ISA/pam_wheel.so use_uid
Este cambio significa que únicamente los miembros del grupo administrativo wheel pueden usar este programa.

Nota

El usuario de root es parte del grupo wheel de forma predeterminada.
2.1.4.3.2. El comando sudo
El comando sudo ofrece otro método para proporcionar acceso administrativo a los usuarios. Cuando los usuarios fiables preceden un comando administrativo con sudo, se les solicitará su propia contraseña. Luego, cuando el usuario ha sido autenticado y se supone que el comando es permitido, el comando administrativo se ejecutará como si el usuario fuera root.
El formato básico del comando sudo es el siguiente: 
sudo <command>
En el ejemplo anterior, <command> se remplazaría por el comando reservado generalmente para el usuario root, tal como mount.

Importante

Los usuarios del comando sudo deben tener extremo cuidado al salir antes de abandonar las máquinas ya que los usuarios de sudo pueden usar el comando otra vez en un lapso de 5 minutos sin que se les pregunte la contraseña. Esta configuración puede modificarse en el archivo de configuración, /etc/sudoers.
El comando sudo permite un alto grado de flexibilidad. Por ejemplo, solamente los usuarios listados en el archivo de configuración /etc/sudoers tienen permiso para usar el comando sudo y el comando se ejecuta en el shell del usuario, no en el shell de root. Esto significa que el shell de root puede estar completamente desactivado, como se muestra en la Sección 2.1.4.2.1, “Desactivación del shell de root”.
El comando sudo también proporciona un rastro de auditoría integral. Cada autenticación correcta se registra en el archivo /var/log/messages y el comando expedido junto con el nombre de usuario de quien lo expide se registran en el archivo /var/log/secure.
Otra ventaja del comando sudo es que el administrador puede permitir a diferentes usuarios el acceso a comandos específicos con base en sus necesidades.
Los administradores que desean modificar el archivo de configuración sudo, deben usar el comando visudo.
Para otorgar privilegios administrativos totales, escriba visudo y añada una línea similar a la siguiente en la sección de especificación de privilegios del usuario. 
juan ALL=(ALL) ALL
Este ejemplo establece que el usuario, juan, puede usar sudo desde cualquier host y ejecutar cualquier comando.
El ejemplo a continuación ilustra la forma como se configura sudo: 
%users localhost=/sbin/shutdown -h now
Este ejemplo establece que cualquier usuario puede emitir el comando /sbin/shutdown -h now siempre y cuando se ejecute desde la consola.
La página de manual para sudoers tiene un listado detallado de las opciones para este archivo.

2.1.5. Servicios de red disponibles

Aunque el acceso de usuario a controles administrativos es un aspecto importante para administradores de sistemas dentro de una organización, la monitorización de los servicios de red que están activos es de gran importancia para cualquier persona que opere un sistema operativo.
Muchos servicios bajo Red Hat Enterprise Linux 6 se comportan como servidores de red. Si un servicio de red se ejecuta en una máquina, entonces la aplicación de servidor (llamado demonio), escucha conexiones en uno o más puertos. Cada uno de estos servidores debe ser tratado como una avenida potencial de ataque.

2.1.5.1. Riesgos para los servicios

Los servicios de red pueden presentar muchos riesgos para los sistemas de Linux. A continuación, un lista de algunos de los principales problemas:
  • Ataques de denegación de servicio (DoS) Al inundar un servicio con solicitudes, un ataque de denegación de servicio puede volver inservible a un sistema, ya que trata de registrar y responder a cada solicitud.
  • Ataque de denegación de servicio distribuido (DDoS) — Un tipo de ataque DoS que utiliza varias máquinas que han perdido su caracter confidencial (a menudo enumerándolas en miles o más) para dirigir un ataque coordinado en un servicio, inundarlo con solicitudes y convertirlo en inservible.
  • Ataques de vulnerabilidad de Scripts — Si un servidor utiliza scripts para ejecutar acciones relacionadas con el servidor, como comúnmente lo hacen los servidores de Web, un cracker puede atacar incorrectamente los scripts escritos. Estos ataques de vulnerabilidades de script pueden conducir a una condición de desbordamiento de buffer o permitir que el agresor altere los archivos en el sistema.
  • Ataques de desbordamientos de buffer — Los servicios que se conectan a puertos enumerados del 0 al 1023 deben ser ejecutados como usuario administrativo. Si la aplicación sufre un desbordamiento de buffer, el atacante podría obtener acceso al sistema como el usuario al ejecutar el demonio. Puesto que los desbordamientos de buffer existen, los agresores utilizan herramientas automatizadas para identificar vulnerabilidades en los sistemas, y una vez que han obtenido acceso, utilizarán rootkits para mantener el acceso al sistema.\n

Nota

La amenaza de un desbordamiento de buffer es mitigada en Red Hat Enterprise Linux por ExecShield, una segmentación de memoria ejecutable y tecnología de protección soportada por kernels de procesadores (uni y multi) compatibles - x86. ExecShield reduce el riesgo de desbordamiento de buffer mediante la separación de la memoria virtual en segmentos ejecutables y no ejecutables. Cualquier código de programa que intenta ejecutarse en el segmento ejecutable (como el código malicioso inyectado desde un ataque de desbordamiento de buffer) provoca un fallo de segmentación y termina.\n
Execshield también incluye soporte para tecnología No eXecute (NX) en plataformas AMD64 y tecnología eXecute Disable (XD) en Itanium y 64 sistemas de Intel®. Estas tecnologías junto con ExecShield evitan que código malicioso se ejecute en la parte ejecutable de la memoria virtual con una granularidad de 4KB de código ejecutable, reduciendo el riesgo de un ataque de vulnerabilidades de desbordamiento de buffer invisible.

Importante

Para limitar la exposición a ataques en la red, todos los servicios que no están en uso son apagados.

2.1.5.2. Identificación y configuración de servicios

Para mejorar la seguridad, la mayoría de los servicios instalados con Red Hat Enterprise Linux están apagados de forma predeterminada. Hay, sin embargo, algunas excepciones:
  • cupsd — El servidor de impresión predeterminado para Red Hat Enterprise Linux.
  • lpd — Un servidor de impresión alternativo.
  • xinetd — Un súper servidor que controla conexiones para un rango de servidores subordinados, tales como gssftp y telnet.
  • sendmail — El Mail Transport Agent (MTA) de Sendmail está habilitado de forma predeterminada, pero no solamente escucha conexiones desde el host local.
  • sshd — El servidor de OpenSSH, el cual es un remplazo seguro para Telnet.
Para determinar si deja estos servicios en ejecución, es mejor usar el sentido común y errar por precaución. Por ejemplo, si la impresora no está disponible, no deje a cupsd ejecutándose. Lo mismo se cierto para portmap. Si usted no monta volúmenes NFSv3 o usa NIS (el servicio ypbind), entonces portmap debe estar desactivado.
Services Configuration Tool

Figura 2.3. Services Configuration Tool

Si no está seguro del propósito de un determinado servicio, la herramienta de configuración de servicios tiene un campo de descripción, ilustrado en la Figura 2.3, “Services Configuration Tool”, la cual proporciona información adicional.
Revisar cuáles servicios de red están disponibles para iniciar en tiempo de arranque es tan solo una parte. También debe revisar los puertos que están abiertos y escuchando. Consulte la Sección 2.2.8, “Cómo verificar los puertos que están escuchando” para obtener mayor información.

2.1.5.3. Servicios inseguros

En potencia, cualquier servicio de red es inseguro. Esta es la razón por la cual es importante apagar los servicios que no se estén utilizando. Las vulnerabilidades para servicios se revelan y se corrigen, de forma rutinaria, lo cual hace importante actualizar regularmente los paquetes asociados con cualquier servicio de redes. Consulte la Sección 1.5, “Actualizaciones de seguridad” para obtener mayor información.
Algunos protocolos de red son más inseguros que otros. Entre ellos se incluyen los servicos que:
  • Transmitir por la red nombres de usuarios y contraseñas sin cifrar — Muchos protocolos anteriores, tales como Telnet y FTP, no cifran la sesión de autenticación y deben evitarse cuando sea posible.
  • Transmitir por la red datos confidenciales sin cifrar — Muchos protocolos transmiten datos sin cifrar por la red. Estos protocolos incluyen Telnet, FTP, HTTP, y SMTP. Muchos sistemas de archivos de red, tales como NFS y SMB, también transmiten información sin cifrar por la red. Es responsabilidad del usuario cuando use estos protocolos, limitar el tipo de datos que se transmite.
    Servicios de volcado de memoria, tales como netdump, transmiten el contenido de memoria por la red sin cifrar. Los volcados de memoria pueden contener contraseñas o incluso peor, entradas de base de datos y otra información confidencial.
    Otros servicios como finger y rwhod revelan información sobre usuarios del sistema.
Entre los ejemplos de servicios inseguros heredados se incluyen rlogin, rsh, telnet, y vsftpd.
Todos los programas remotos y de shell (rlogin, rsh, and telnet) deben evitarse en favor de SSH. Consulte la Sección 2.1.7, “Herramientas de comunicación de Seguridad Mejorada ” para obtener mayor información sobre sshd.
FTP no es de por sí tan peligrosa para la seguridad del sistema como los shell remotos, pero los servidores FTP deben ser configurados cuidadosamente y monitorizados para evitar problemas. Consulte la Sección 2.2.6, “Cómo proteger FTP” para obtener mayor información sobre cómo proteger servidores FTP.
Entre los servicios que deben ser cuidadosamente implementados y detrás de un cortafuegos, están:
  • finger
  • authd (conocido como identd en lanzamientos anteriores de Red Hat Enterprise Linux.)
  • netdump
  • netdump-server
  • nfs
  • rwhod
  • sendmail
  • smb (Samba)
  • yppasswdd
  • ypserv
  • ypxfrd
Puede encontrar más información sobre protección de servicios de red en Sección 2.2, “Seguridad del servidor”.
La siguiente sección describe las herramientas disponibles para configurar un cortafuegos sencillos.

2.1.6. Cortafuegos personales

Después de que los servicios necesarios de red son configurados, es importante implementar un cortafuegos.

Importante

Debe configurar los servicios necesarios e implementar un cortafuegos antes de conectarse a la Internet o a otra red en la que usted no confía.
Los cortafuegos impiden que los paquetes de red accedan a la interfaz de red del sistema. Si se hace una solicitud a un puerto que está bloqueado por un cortafuegos, la petición es ignorada. Si un servicio está escuchando en uno de estos puertos bloqueados, no recibe los paquetes y se desactiva. Por esta razón, se debe tener cuidado al configurar un cortafuegos para bloquear el acceso a los puertos que no están en uso y no bloquear el acceso a los puertos usados ​​por servicios configurados.
Para la mayoría de usuarios, la mejor herramienta para configurar un cortafuegos sencillo es la herramienta de configuración que se distribuye con Red Hat Enterprise Linux: la Firewall Configuration Tool (system-config-firewall). Esta herramiena crea amplias reglas iptables para un cortafuegos de propósitos generales mediante una interfaz de panel de control.
Consulte la Sección 2.5.2, “Configuración básica de cortafuegos” para obtener mayor información sobre el uso de esta aplicación y sus opciones disponibles.
Para usuarios avanzados y administradores, configurar manualmente un cortafuegos con iptables probablemente es una mejor opción. Consulte la Sección 2.5, “Cortafuegos” para obtener más información. Consulte la Sección 2.6, “IPTables” para obtener una guía integral de iptables.

2.1.7. Herramientas de comunicación de Seguridad Mejorada

A medida que el tamaño y la popularidad de la Internet crece, también crece la amenaza de la interceptación de las comunicaciones. Con los años, se han desarrollado herramientas para cifrar las comunicaciones, ya que se transfieren a través de la red.
Red Hat Enterprise Linux 6 se distribuye con dos herramientas básicas que usan un alto nivel de algoritmos cifrados basados en criptografía de llave pública para proteger información cuando viaja sobre la red.
  • OpenSSH — Una implementación libre de protocolo SSH para cifrar la comunicación de redes.
  • Gnu Privacy Guard (GPG) — Una aplicación de cifrado PGP (Pretty Good Privacy) para cifrado de datos.
OpenSSH es una forma más segura para acceder a una máquina remota y remplaza los anteriores, los servicios no cifrados como telnet y rsh. OpenSSH incluye un servicio de red llamado sshd y tres aplicaciones de cliente de línea de comandos:
  • ssh — Un cliente de consola de acceso remoto seguro.
  • scp — Un comando de copia remoto seguro.
  • sftp — Un seudo cliente ftp que permite sesiones de transferencia de archivos.
Consulte la Sección 3.6, “Shell segura” para obtener mayor información sobre OpenSSH.

Importante

Aunque el servicio sshd es esencialmente seguro, el servicio debe mantenerse actualizado para prevenir amenazas de seguridad. Consulte la Sección 1.5, “Actualizaciones de seguridad” para obtener mayor información.
GPG es una forma de comunicación privada por correo-e. Puede servir tanto para datos confidenciales de correo-e como pare redes públicas y para proteger datos confidenciales en discos duros.

[11] Puesto que el BIOS del sistema se diferencia entre los fabricantes, algunos no aceptan la protección de contraseña de cualquier tipo, mientras que otros pueden aceptar un tipo de protección pero no el otro.
[12] GRUB también acepta contraseñas sin cifrar, pero se recomienda utilizar un MD5 hash para añadir seguridad.
[13] Este acceso está aún sujeto a restricciones impuestas por SELinux, si SELinux está habilitado.