Pautas para la administración de un sistema seguro

Pautas para manejar los programas setuid y setgid

Puesto que los programas setuid y setgid representan un gran riesgo para la seguridad del sistema, debe identificarlos y

Mantenerse alerta en relación con los cambios que puedan sufrir.
Investigar concienzudamente los programas que parezca que ejecutan setuid en vano.
Cambiar los permisos de acceso de los programas que ejecuten setuid en vano por los que ejecuten setgid.

La forma larga del comando ls (ll o ls -l) muestra los programas setuid sustituyendo la forma de denotar el permiso de ejecución del propietario, que es - o x, por S o s. Por otro lado, presenta los programas setgid sustituyendo la forma de denotar el permiso de ejecución de grupo, que es - o x, por S o s.

Es previsible que encuentre archivos de sistema setuid y setgid, pero éstos deben tener los mismos permisos que los facilitados en el medio suministrado de fábrica, a no ser que los haya personalizado.

En general, los usuarios no deber tener programas setuid, y menos programas setuid a otros usuarios que no sean ellos mismos.

Examine el código de todos los programas importados de fuentes externas en busca de programas de destrucción denominados «Caballos de Troya.» No restaure nunca un programa setuid para el que no disponga de un código fuente para examinar.

Para posibilitar el acceso de los usuarios a determinados programas de superusuario, se recomienda emplear Restricted SAM. Restricted SAM permite a los usuarios que no sean superusuarios obtener acceso a zonas concretas del SAM. La zona del SAM accesible se define en /etc/sam/custom/nombre_inicio_sesión.cf para un usuario, donde nombre_inicio_sesión es el nombre de inicio de sesión del usuario. Para obtener más información, consulte la página de manual de sam(1M).

Motivos por los que los programas setuid y setgid representan un riesgo

Siempre que se ejecuta un programa, éste crea un proceso con cuatro números de identificación: la identificación de usuario real y efectiva (ruid y euid), y la identificación de grupo real y efectiva (rgid y egid). Normalmente, estos pares de números de identificación son idénticos.

No obstante, la ejecución de un programa setuid o setgid cambia el número de identificación euid o egid del proceso: se sustituye el número asociado al propietario por el del objeto. Los procesos creados adquieren sus atributos del objeto y conceden al usuario los mismos derechos de acceso que al propietario o el grupo del programa.

Si el bit de setuid se activa, los privilegios del proceso se definen en los del propietario del archivo.
Si el bit de setgid se activa, los privilegios del proceso se definen en los del grupo del archivo.
Si no se activa el bit de setuid ni el bit de setgid, los privilegios del proceso permanecen igual.
Un caso especialmente arriesgado es el que se da cuando un programa contiene un setuid, o cambio de identidad, a root, ya que el usuario obtiene todos los privilegios al alcance del usuario root. Esto entraña peligro porque el programa se puede utilizar infringiendo las normas de seguridad del sistema. Este problema también surge, en menor medida, en otros casos de setuid y setgid.

Definición de los números de identificación

Los números de identificación ruid y rgid se heredan del proceso login, que define sus números de identificación uid y gid. Los valores uid y gid especificados se precisan en el archivo /etc/passwd.
En un sistema de confianza, el aid (número de identificación de auditoría) permanece igual al iniciarse una sesión y se especifica en la base de datos protegida mediante contraseña /tcb/files/auth/. El número aid no cambia al ejecutar los programas setuid y setgid. Esto redunda en beneficio del control de las acciones.
El comando login también cambia los valores de ruid, euid, rgid y egid.
El comando su cambia los valores de euid y ruid.
El comando newgrp puede cambiar el valor de gid.
Los bits de setuid y setgid se definen con la llamada al sistema chmod() o el comando chmod. Consulte las páginas de manual de chmod(1) y chmod(2).

Los agresores de sistemas pueden explotar los programas setuid y setgid, casi siempre de una de las dos formas siguientes:

Haciendo que un programa setuid o setgid ejecute comandos definidos por el agresor, ya sea de forma interactiva o a través de una secuencia de comandos.
Sustituyendo los datos creados por un programa por datos falsos.

Pautas para acotar la influencia de setuid

Sea sumamente precavido si agrega programas “setuid a root” en un sistema existente. La adición de un programa “setuid a root” cambia la configuración del sistema y es posible que ponga en peligro la seguridad.

Imponga el uso restrictivo de los programas con privilegios guiándose por las siguientes recomendaciones:

Utilice los programas setuid y setgid sólo cuando sea absolutamente necesario.
Asegúrese de que ningún otro usuario tiene acceso de escritura a ningún programa setuid.
Siempre que sea posible, utilice setgid en lugar de setuid para reducir el alcance del daño que pueda producirse como consecuencia de posibles brechas en la codificación o infracciones de la seguridad.
Cada cierto tiempo, realice búsquedas en los sistemas de archivos para detectar programas setuid y setgid nuevos o modificados. Puede utilizar el comando ncheck -s.
Sepa exactamente lo que hacen los programas setuid y setgid, y compruebe que se limitan a hacer sólo lo previsto. Si se extralimitan en sus funciones, elimine el programa o el atributo setuid correspondiente.
Si tiene que copiar un programa setuid, asegúrese de que los modos son correctos en el archivo de destino.
Escriba programas setuid de modo que puedan probarse en datos que no sean críticos, sin atributos setuid ni setgid. Aplique estos atributos sólo después de analizar el código y de que todos los departamentos interesados tengan la certeza de que los programas nuevos no vulneran la seguridad.
Asegúrese de que un programa setuid no crea archivos a los que puedan tener acceso de escritura personas distintas del usuario previsto.
Restablezca el valor de euid antes de una llamada del sistema exec(*). Tenga en cuenta que se puede llamar a exec(*) desde otras rutinas de las bibliotecas y sea cauto al utilizar rutinas (incluidas popen(), system(), execlp() y execvp()) que bifurquen un shell para ejecutar un programa. Consulte las páginas de manual de exec(2), popen(3S) y system(3S).
Cuando escriba programas setuid, utilice setresuid() alrededor de las partes del código que exijan privilegios, para reducir la ventana de vulnerabilidad. Consulte la página de manual de setresuid(2).
Cierre todos los descriptores de archivo innecesarios antes de llamar a exec(*).
Asegúrese de que todas las variables (PATH, IFS) y el valor de umask del entorno del programa son suficientemente restrictivos.
No utilice la llamada del sistema creat() para crear un archivo de bloqueo. En su lugar, utilice lockf() o fcntl(). Consulte las páginas de manual de lockf(2) y fcntl(2).
Tenga especial cuidado en evitar las saturaciones del búfer, como las que se producen al utilizar sprintf(), strcpy() y strcat() sin la validación oportuna de la longitud del parámetro. Consulte las páginas de manual de printf(3S) y string(3C).

Pautas para la inicialización del sistema

La mayoría de los programas “setuid a root” suministrados por HP empiezan por configurar un entorno operativo seguro mediante el establecimiento de las siguientes condiciones:

La limitación de las variables de entorno a las estrictamente imprescindibles para el funcionamiento apropiado del programa.
Puesto que los Caballos de Troya normalmente atacan a las variables PATH e IFS configuradas incorrectamente, dichas variables se establecen en valores predeterminados. PATH se define en /usr/bin. IFS se define en espacio, tabulación y nueva línea. Las demás variables de entorno se eliminan. Consulte la página de manual de environ(5).
El cierre de todos los descriptores de archivo que no sean los archivos de entrada estándar, salida estándar y error estándar. Consulte la página de manual de close(2).
La desactivación de todas las alarmas. Todos los temporizadores de intervalos se ponen a cero. Consulte la página de manual de getitimer(2).

Estas salvaguardias aumentan la confianza en que los programas conocidos se ejecuten en un entorno conocido.

Pautas para realizar copias de seguridad y recuperaciones de confianza

Utilice sólo los comandos fbackup y frecover para realizar una copia de seguridad y recuperar archivos de forma selectiva. Los comandos fbackup y frecover son los únicos que retienen las listas de control de acceso (ACL). Utilice la opción -A de estos comandos cuando realice una copia de seguridad de archivos y los recupere para utilizarlos en sistemas que no apliquen listas ACL. Consulte las páginas de manual de fbackup(1M) y frecover(1M).
Si prevé recuperar los archivos en otro sistema, asegúrese de que el nombre de usuario del propietario y el nombre de grupo concuerdan en ambos sistemas.
No olvide que los medios de copia de seguridad contienen datos confidenciales. Restrinja el acceso a los medios a los casos de necesidad probada.
Etiquete las cintas de copia de seguridad y almacénelas en lugar seguro. El almacenamiento fuera de las instalaciones ofrece la máxima seguridad. Guarde los archivos durante un mínimo de seis meses y, al cumplirse el plazo, recicle los medios.
Se recomienda realizar copias de seguridad incrementales diarias y copias de seguridad completas semanales.
Sincronice el programa de copia de seguridad con el flujo de información de la empresa. Por ejemplo, si se actualiza una base de datos importante todos los viernes, podría programar la copia de seguridad semanal para los viernes por la noche.
Si en el momento debido debe hacerse una copia de seguridad de todos los archivos, pida a todos los usuarios que cierren su sesión antes de proceder a realizar la copia. De todas formas, fbackup le avisa si se cambia un archivo mientras se realiza la copia de seguridad.
Examine el archivo de registro de las copias de seguridad más recientes para identificar los problemas que se produzcan durante la copia de seguridad. El archivo de registro de copia de seguridad debe tener configurados permisos restrictivos.
frecover permite sobrescribir un archivo. No obstante, el archivo retiene los permisos de acceso y las listas ACL definidos al realizar la copia de seguridad del archivo.
Debe probar de antemano el proceso de recuperación a fin de asegurarse de que puede recuperar por completo los datos en el caso de producirse una emergencia.
Al recuperar archivos procedentes de otro equipo, es posible que tenga que ejecutar el comando chown para definir el número de identificación de usuario y la identificación de grupo para el sistema en el que residan ahora dichos archivos, si el usuario y el grupo no existen en el sistema nuevo. Si los archivos se recuperan en un sistema nuevo que no tenga el grupo especificado, los archivos asumen la propiedad de grupo de la persona que ejecute el comando frecover. Si los nombres de propietario y grupo tienen significados diferentes en sistemas diferentes, los resultados de la recuperación pueden ser inesperados.
Los errores de alimentación no deberían conllevar la pérdida de archivos. No obstante, si alguien informa de la pérdida de un archivo después de un error de alimentación, búsquelo en el directorio /lost+found antes de restaurarlo a partir de una cinta de copia de seguridad.
Para comprobar el contenido de la cinta desde la que se vaya a realizar la recuperación, utilice la opción -I del comando frecover para obtener una vista preliminar del índice de archivos de la cinta. No obstante, tenga en cuenta que la copia de seguridad mantiene intactos los permisos existentes de un sistema de archivos; frecover impide la lectura del archivo si los permisos de acceso del archivo lo prohíben.
No recupere nunca ningún archivo crítico, como /etc/passwd, ni los que contenga /tcb/files. En su lugar, restaure el archivo en un directorio temporal (no utilice /tmp) y conceda a este directorio permisos drwx------, lo que impide que nadie más lo utilice. Compare los archivos restaurados con los archivos que hayan de reemplazarse. Efectúe los cambios necesarios.
La auditoría no se activa automáticamente después de recuperar el sistema. Asegúrese de que la activa.

Pautas para montar y desmontar un sistema de archivos

El comando mount permite asociar sistemas de archivos extraíbles, discos o particiones de disco a un árbol de archivos existente. El comando mount utiliza un archivo denominado /etc/fstab, que contiene una lista de los sistemas de archivos disponibles y sus posiciones de montaje correspondientes. El archivo /etc/fstab debe tener permiso de acceso de escritura sólo para el usuario root y permiso de acceso de lectura para los demás usuarios. Para obtener más información sobre el montaje de sistemas de archivos, consulte la sección «Administración de sistemas de archivos».

Adopte las siguientes medidas de precaución al montar un sistema de archivos o disco:

Cree un directorio de punto de montaje (por ejemplo, /mnt) en que montar un sistema de archivos nuevo. No monte nunca un sistema de archivos en un directorio que ya contenga archivos, porque no se podrá tener acceso a estos archivos.
El punto de montaje de un sistema de archivos montado adquiere los permisos y la propiedad del directorio raíz del sistema de archivos.
Utilice permisos de acceso de modo de base y entradas de listas de control de acceso en los nombres de ruta del disco para controlar el acceso a los discos.
Utilice la opción -r del comando mount para montar el sistema de archivos con permiso de sólo lectura. Los sistemas de archivos físicamente protegidos contra escritura deben montarse de esta forma.
Cuando monte un sistema de archivos nuevo o ajeno, dé por sentado que el medio es inseguro.
- Cree un directorio restringido en root y defina los permisos asociados en 700 (drwx------).
  # mkdir /securefile # chmod 700 /securefile
- Ejecute el programa fsck para comprobar que el sistema de archivos no está dañado desde el punto de vista técnico.
- Asegúrese de que la variable de entorno PATH no incluye «.» (el directorio actual); si no realiza esta comprobación, es posible que ejecute una versión de Caballo de Troya de ls o de otro comando parecido mientras examina el sistema de archivos nuevo.
- Monte el sistema de archivos ajeno con permiso de sólo lectura en dicha ubicación; por ejemplo, puede cargar el disco y escribir:
  # mount /dev/disk1 /securefile -r
- Compruebe todos los directorios en busca de objetos especiales y programas con privilegios, y verifique la identidad de todos los programas.
- Ejecute ncheck -s para detectar programas setuid y setgid y archivos de dispositivo, e investigue los hallazgos sospechosos.
- Vuelva a montar el sistema con permisos de lectura y escritura, y elimine los permisos setuid y setgid innecesarios de los archivos detectados en el paso anterior. Estas medidas de precaución revisten especial importancia si un usuario le pide que monte un sistema de archivos personal.
No debe desmontar el sistema de archivos ni volverlo a montar en la ubicación prevista hasta que haya realizado las pruebas mencionadas.
Asegúrese de que desmonta todos los sistemas de archivos montados de un usuario cuya cuenta vaya a desactivar o eliminar.

Para obtener información sobre los archivos montados en un entorno NFS, consulte la sección «Control de la seguridad en una red».

Pautas para manejar infracciones de seguridad

Las infracciones de seguridad pueden presentarse de muchas formas:

Un usuario puede informar de un comportamiento inesperado o destructivo por parte de un programa común.
Puede apreciarse un aumento repentino de la carga media del sistema, con la consiguiente ralentización de la respuesta del sistema.
Los permisos de acceso de lectura/escritura o la propiedad pueden haber cambiado y ser diferentes de lo previsto.
El recuento de bytes de un archivo del sistema cambia inesperadamente.

Todo lo que parezca que se desvía del comportamiento normal del sistema puede ser indicio de adulteración. Si sospecha la existencia de una infracción de la seguridad, por ejemplo un virus o gusano, aborde la situación limitando el impacto inmediato.

Cierre el sistema.
Inicie el sistema en estado monousuario, con lo mínimo indispensable. Esto limita el impacto de los síntomas. En un estado monousuario, analice el problema y erradíquelo.
Monte todos los sistemas de archivos con el comando mount -a.
Hasta que haya comprobado la integridad de dichos sistemas, defina permisos de acceso restrictivos a los directorios (drwx------) para impedir que los usuarios obtengan acceso a los archivos dudosos. Sólo se trata de una solución a corto plazo.
Compare el tamaño de archivo del sistema del que se haya hecho una copia de seguridad previamente y del sistema actual. Examine las fechas de la última escritura de los archivos, las sumas de comprobación, el recuento de bytes, los inodos y la propiedad. Desconfíe de los archivos cuyo tamaño difiera de lo previsto. No obstante, no olvide que algunos archivos de sistema, sobre todo los archivos de red, pueden haberse personalizado y que, por tanto, pueden diferir del software del sistema por defecto.
Copie los archivos contaminados en una cinta para guardarlos como prueba.
En algunas circunstancias, es posible que no pueda reiniciar o que desconfíe del propio programa de reinicio (/sbin/init). Dado el caso, debe volver a instalar el sistema.
Si no está seguro del alcance del daño, se recomienda que vuelva a instalar HP-UX a partir de los medios de distribución originales. Tal vez tenga que volver a instalar también otras aplicaciones de software en el sistema.
Después de la reinstalación, debe determinar si ha dañado algún archivo de usuario u otros archivos no reinstalados a partir de la cinta.
Monte los directorios iniciales de los usuarios y ejecute los comandos find y ncheck para descubrir cualquier otro archivo dañado.
Si la infracción ha consistido en un acceso no autorizado al equipo, el punto de entrada será evidente en la mayoría de las circunstancias. Deshabilite las cuentas correspondientes: sustituya las entradas de contraseña por un asterisco. A continuación, el usuario root tendrá que cambiar manualmente la contraseña.
En todo caso, se recomienda que compruebe todas las cuentas del sistema.
Informe a todos los usuarios del sistema cuando se infrinja la seguridad y pídales que comprueben sus cuentas para detectar cualquier detalle insólito. Dé instrucciones a los usuarios para que ejecuten ls -lt a fin de detectar una posible adulteración, la cual se puede evidenciar en cambios inesperados de los archivos, como la hora de la última modificación, en la creación de archivos o en los cambios de modo.
Analice las pruebas para averiguar cómo se ha producido la infracción y qué medidas se pueden adoptar para evitar que se repita.

Seguimiento del usuario root

Un método útil para realizar un seguimiento del acceso al sistema y para reducir las infracciones de seguridad en los servidores estándar y de confianza consiste en proteger físicamente la consola del sistema y no dejar que el usuario root inicie una sesión más que en la consola del sistema. Los usuarios que inicien una sesión a través de otros puertos primero deberán iniciar una sesión con sus propios nombres de usuario y, a continuación, deberán ejecutar el comando su para convertirse en root.

Para limitar la posibilidad de inicio de sesión del usuario root sólo a la consola del sistema, cree el archivo /etc/securetty con una sola entrada, console, del modo siguiente:

# echo console > /etc/securetty

Esta restricción es válida para todos los nombres de inicio de sesión que tengan el número de identificación de usuario 0 (superusuario). Para obtener más detalles, consulte la página de manual de login(1).