|
|
España-Español | |
|
|
|
|
Desde el punto de vista de la seguridad, los sistemas en red son más vulnerables que los sistemas autónomos. La conexión en red aumenta la capacidad de acceso al sistema, pero también incrementa el riesgo de que se vulnere la seguridad. Aunque no se puede controlar la seguridad a través de la red, sí se puede controlar la seguridad de cada nodo de la red para limitar el riesgo de intrusión sin perjuicio de la utilidad del sistema ni de la productividad del usuario. Todos los programas de administración de la red deben ser propiedad de una cuenta protegida específica de la red, por ejemplo: uucp, nso o daemon, antes que de root. Un dominio administrativo es un grupo de sistemas conectados por servicios de red que permiten a los usuarios obtener acceso a los sistemas de los demás sin que se compruebe la contraseña. Un dominio administrativo da por sentado que los usuarios de los sistemas ya han sido verificados por el equipo host correspondiente. Dé los siguientes pasos para identificar y controlar un dominio administrativo.
Los modos, los propietarios y los grupos de todos los archivos de sistema se configuran con cuidado. Toda desviación de estos valores que se produzca debe tenerse en cuenta y corregirse. Preste especial atención a los archivos de control de red, que se ubican en el directorio /etc y son blancos señalados ya que franquean el acceso a la propia red. Los archivos de control de red no deben configurarse nunca con permiso de acceso de escritura para el público. Entre dichos archivos se hallan: HP-UX ofrece diversos servicios de red y todos ellos integran un medio de autenticación, ya sea mediante la comprobación de la contraseña o una autorización configurada en un archivo del sistema remoto.
Para obtener información sobre la utilización de los servicios, consulte la página de manual específica del servicio. A continuación, se identifican algunos de los principales asuntos de seguridad relacionados con estos servicios de red. El control del acceso a los servicios de red individuales se puede definir en /var/adm/inetd.sec, un archivo de seguridad opcional del demonio Internet. El uso de la mayoría de los servicios de red se puede permitir o impedir explícitamente al relacionarlos para cada equipo o para cada subred. La sintaxis de las entradas del archivo /var/adm/inetd.sec es: nombre_servicio allow|deny {dirección_host|nombre_host}... El nombre_servicio es el nombre oficial (no un alias) de un servicio válido del archivo /etc/services. El nombre_servicio en el caso de los servicios (NFS) basados en llamadas a procedimiento remoto (RPC) es el nombre oficial (no un alias) de un servicio válido del archivo /etc/rpc. En las direcciones, se pueden utilizar el carácter comodín * y el carácter de intervalo -. Para obtener información pormenorizada sobre la sintaxis y el uso de este archivo, consulte la página de manual de inetd.sec(4). El demonio Internet (consulte la página de manual de inetd(1M)) ejecuta el demonio ftpd, el servidor de protocolo de transferencia de archivos, cuando se recibe una solicitud de servicio en el puerto indicado en el archivo /etc/services. El demonio ftpd rechaza los inicios de sesión remotos en las cuentas de usuario locales nombradas en el archivo /etc/ftpd/ftpusers. Cada nombre de cuenta de inicio de sesión restringido debe aparecer solo en una línea del archivo. La línea no puede contener ningún espacio ni tabulación. Las cuentas de usuario con shells de inicio de sesión restringido que aparecen en /etc/passwd deben enumerarse en /etc/ftpd/ftpusers, porque ftpd obtiene acceso a las cuentas locales sin utilizar sus shells de inicio de sesión. Las cuentas uucp también deben enumerarse en el archivo /etc/ftpd/ftpusers. Si /etc/ftpd/ftpusers no existe, ftpd omite la comprobación de seguridad.
Un sistema de archivos de red (NFS) sirve para:
NFS racionaliza la distribución de archivos entre los sistemas servidor y cliente al controlar el acceso a través del archivo /etc/exports. Las entradas del archivo /etc/exports brindan permiso para montar un sistema de archivos existente en el servidor en cualquier equipo cliente o en una lista especificada de equipos. Después de incluir un sistema de archivos en /etc/exports, la información está disponible en potencia para cualquier persona que pueda llevar a cabo un montaje mediante NFS. Por tanto, el usuario de un cliente NFS puede obtener acceso a un sistema de archivos del servidor sin tener que iniciar una sesión en el sistema servidor. Para obtener más información, consulte la sección «Administración de sistemas de archivos». Para ampliar la información sobre el control del acceso a los sistemas de archivos exportados, consulte también la página de manual de exports(4). La seguridad de los servidores se mantiene definiendo permisos de acceso restrictivos en el archivo /etc/exports. Los privilegios de usuario root no se mantienen en el sistema NFS. Por tanto, tener privilegios de usuario root en un sistema cliente no comporta ningún acceso especial en el servidor. El servidor lleva a cabo remotamente la misma comprobación de permisos para el cliente que realiza localmente para sus propios usuarios. El lado del servidor controla el acceso a los archivos del servidor por parte del cliente; para ello, compara el número de identificación de usuario y la identificación de grupo del cliente, que recibe a través de la red, con el número de identificación de usuario y la identificación de grupo del archivo del servidor. La comprobación se produce en el interior del kernel. Un usuario que tenga privilegios en un cliente NFS puede aprovechar dichos privilegios para obtener acceso ilimitado a un servidor NFS. ¡No exporte nunca ningún sistema de archivos a un nodo en el que se concedan privilegios con más indulgencia que en el nodo de su sistema! En revisiones anteriores de NFS para estaciones de trabajo, el inodo /dev tenía que ubicarse en el disco de cliente. En la actualidad, el NFS permite que exista en el lado del servidor el inodo /dev que contenga los números “major” y “minor” de un dispositivo montado en un cliente. Esto conlleva la posibilidad de que alguien cree un Caballo de Troya que anule los permisos definidos en el dispositivo montado del cliente, al obtener acceso al dispositivo a través del archivo y el número de inodo hallado en el lado del servidor. Aunque un intruso del sistema carezca de permiso para crear un archivo de dispositivo en el lado del cliente, si desea sabotear el cliente, puede crear un archivo de dispositivo destructivo, por ejemplo /dev/kmem, empleando los permisos de usuario root en el lado del servidor. El nuevo archivo /dev se crea con los mismos números “major” y “minor” que el dispositivo de destino del cliente, pero con los siguientes permisos: crw-rw-rw-. A continuación, el intruso puede obtener acceso al cliente, iniciar una sesión como si fuera un usuario normal y, mediante el NFS, abrir el archivo de dispositivo recién creado en el servidor y utilizarlo con fines tortuosos: para borrar la memoria del kernel en el servidor, leer el contenido de los procesos de todos los usuarios o cualquier otro fin dañino.
El acceso a nivel de enlaces es un recurso muy eficaz que permite a un programador obtener acceso directo en el sistema host al controlador de enlaces. En las manos equivocadas, este recurso puede capacitar a un usuario corriente para fabricar cualquier paquete de red, incluidos paquetes de control de red. Para proteger el acceso a nivel de enlaces, asegúrese de que los archivos /dev/ether*, /dev/ieee* y /dev/lan* son propiedad sólo de root y de que éste es el único usuario con acceso de escritura. Consulte la sección «Consideraciones sobre la seguridad de los archivos de dispositivo».
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 Versión para imprimir |
|
|
|
|
|
|||||||||||||||
|
|||||||||||||||
