4.5. Seguridad y confidencialidad

Una de las características principales de un sistema Linux o UNIX es su capacidad de gestionar varios usuarios a la vez (multiusuario) y para permitir que éstos realicen varias tareas (multitarea) en el mismo equipo de forma simultánea. Además, el sistema operativo es transparente para los usuarios. A menudo, los usuarios no saben si los datos y las aplicaciones que utilizan se proporcionan localmente desde su máquina o si su disponibilidad procede de algún otro punto de la red.

Con la capacidad multiusuario, los datos de usuarios distintos deben almacenarse de forma separada. La seguridad y la privacidad deben quedar garantizada. La seguridad de los datos era ya una cuestión importante, aun antes de que los equipos pudieran conectarse a través de redes. Exactamente igual que hoy, la preocupación más importante era la capacidad de mantener la disponibilidad de los datos pese a la pérdida del medio de datos (un disco duro en la mayor parte de los casos) o a otro tipo de daños.

Fundamentalmente, esta sección se centra en problemas de confidencialidad y en los modos de protección de la privacidad de los usuarios; no obstante, nunca se subrayará suficientemente la vital importancia que tienen, para lograr un estado de seguridad exhaustivo, los procedimientos de creación de copias de seguridad flexibles, puestas a prueba y actualizadas con regularidad. En su defecto, la recuperación de los datos podría ser dificilísima, y no sólo en el caso de algún defecto del hardware, sino también si se sospecha que alguien ha conseguido un acceso no autorizado a los archivos y los ha modificado.

4.5.1. Seguridad local y de red

Hay varias formas de acceder a los datos:

  • la comunicación con personas que disponen de la información deseada o del acceso a los datos en un equipo;

  • directamente desde la consola de un equipo (acceso físico);

  • a través de una línea serie;

  • mediante un vínculo de red.

En todos estos casos, el usuario debería autentificarse antes de acceder a los recursos o datos en cuestión. Es posible que un servidor Web sea menos restrictivo a este respecto, pero aun así el usuario no deseará que cualquier internauta pueda acceder a sus datos.

El primero de los casos que figura en la lista anterior es el que implica una mayor dosis de interacción humana; por ejemplo, la solicitud, por parte de un miembro del personal de un banco, de que una persona demuestre ser la propietaria de una cuenta bancaria concreta. En tal caso, se le pide una firma, un PIN o una contraseña que sirvan para constatar su identidad. En algunos casos, es posible obtener ciertos datos de alguien que disponga de determinada información con sólo mencionar retazos y fragmentos para ganar su confianza mediante una retórica brillante. Puede persuadirse a la víctima para que revele, de forma gradual y quizás sin ser consciente de ello, más información. Entre los piratas informáticos (hackers), esto se conoce como ingeniería social (social engineering). La educación, así como el tratamiento sensato del lenguaje y la información, constituyen la única protección posible contra estos hechos. Antes de irrumpir en un sistema informático, a menudo los intrusos intentan utilizar a recepcionistas, al personal del servicio técnico o incluso a familiares. En numerosos casos, estos ataques basados en la ingeniería social se descubren pasado mucho tiempo.

Alguien con intenciones de obtener un acceso no autorizado a los datos de un usuario también puede optar por el método tradicional de hacerse directamente con el hardware. Por lo tanto, la máquina debería protegerse contra cualquier tipo de manipulación para que nadie pueda retirar, sustituir o inutilizar ninguno de sus componentes. Esto se aplica igualmente a las copias de seguridad e incluso a cualquier cable de red o de corriente. También ha de garantizarse la seguridad del procedimiento de arranque, puesto que hay algunas combinaciones de teclas bien conocidas que pueden provocar un comportamiento poco habitual. Evite esto último definiendo contraseñas para el BIOS y el cargador de arranque.

Los terminales en serie conectados a puertos de serie siguen utilizándose en muchos sitios. De forma contraria a las interfaces de red, no se sirven de un protocolo de red para comunicarse con el host. Se hace uso de un simple cable o un puerto de infrarrojos para enviar, en una y otra dirección, caracteres sin formato entre los dispositivos. El propio cable es el punto más débil de un sistema como éste. Resulta fácil grabar cualquier dato que circule por los cables de este sistema con sólo conectar una vieja impresora. Lo que se logra con una impresora también puede llevarse a cabo por otros medios; todo depende del esfuerzo que se invierta en el plan de ataque.

La lectura local de un archivo en un host requiere reglas de acceso diferentes a la de abrir una conexión de red con un servidor en un host distinto. Existe una diferencia entre la seguridad local y la seguridad de red. El límite entre ambos términos radica en la colocación de los datos en paquetes para efectuar su envío.

4.5.1.1. Seguridad local

La seguridad local comienza con el entorno físico de la ubicación en la que el equipo se encuentra funcionando. Coloque su máquina en un lugar en el que la seguridad esté en consonancia con sus expectativas y necesidades. El objetivo principal de la seguridad local es la de mantener a los usuarios separados unos de otros, de modo que ninguno de ellos pueda hacerse con los permisos o adoptar la identidad de otros. Esta es una regla de aplicación general, aunque adquiere un peso especial con respecto al usuario root, que es el que ostenta el poder principal en el sistema. root puede adoptar la identidad de cualquier otro usuario local sin que se le solicite ninguna contraseña y, de este modo, leer cualquier archivo almacenado localmente.

4.5.1.2. Contraseñas

En un sistema Linux, las contraseñas no se almacenan como texto sin formato, ni se espera simplemente a que la cadena de texto introducida coincida con el patrón guardado. Si así fuera, todas las cuentas del sistema se verían en peligro si alguien tuviera acceso al archivo correspondiente. En lugar de esto, la contraseña almacenada está cifrada y, cada vez que se escribe, se vuelve a cifrar y se efectúa una comparación de ambas cadenas cifradas. Esto sólo proporciona más seguridad si la contraseña cifrada no puede convertirse, mediante ingeniería inversa, en la cadena de texto original.

Esto se consigue de hecho mediante un tipo especial de algoritmo, denominado trapdoor algorithm (algoritmo trampilla), puesto que sólo funciona en una dirección. Un intruso que haya logrado hacerse con la cadena cifrada no será capaz de obtener la contraseña con sólo aplicar el mismo algoritmo una vez más. En lugar de eso, necesitaría examinar todas las combinaciones posibles de caracteres hasta hallar la que se pareciera a la contraseña al cifrarse. Con contraseñas de ocho caracteres de longitud, debe calcularse un número considerable de combinaciones posibles.

En la década de los setenta, se argüía que este método aportaría una mayor seguridad que los demás a causa de la relativa lentitud del algoritmo utilizado, que tardaba unos pocos segundos en cifrar una sola contraseña. No obstante, entre tanto, los equipos se han hecho lo suficientemente potentes para efectuar varios cientos de miles o incluso millones de cifrados por segundo. Por ello, las contraseñas cifradas no deberían resultar visibles para los usuarios normales (éstos no pueden leer /etc/shadow). Aun más importante resulta que las contraseñas no sean fáciles de adivinar, por si el archivo de contraseña se hace visible a causa de algún error. En consecuencia, no es muy útil “traducir” una contraseña como “tentar” como algo parecido a “t@n1@3”.

La sustitución de algunas letras de una palabra por números de apariencia similar no resulta lo suficientemente segura. Los programas de falsificación de contraseñas que utilizan diccionarios para adivinar palabras también funcionan mediante sustituciones de este tipo. Una mejor forma de enmascarar una palabra con un significado poco común, algo que tan sólo tenga sentido para el usuario, como las primeras letras de las palabras de una frase o del título de un libro, como “El nombre de la rosa” de Umberto Eco. Esto daría lugar a la siguiente contraseña segura: “TNotRbUE9”. A diferencia de esta última, cualquiera que conozca mínimamente al usuario podría adivinar contraseñas como “cervecero” o “natalia76”.

4.5.1.3. Procedimiento de arranque

Configure su sistema de modo que no pueda arrancarse desde un disquete o CD, bien desmonte por completo las unidades o establezca una contraseña para el BIOS y configure este último para permitir el arranque únicamente desde el disco duro. Un sistema Linux se inicia, por lo general, gracias a un cargador de arranque, lo que permite al usuario transferir opciones adicionales al núcleo arrancado. Evite que otros utilicen estos parámetros durante el arranque estableciendo una contraseña adicional en /boot/grub/menu.lst (consulte el Capítulo 9, Cargador de arranque). Éste es un aspecto clave para la seguridad de su sistema. Los permisos root hacen posible no sólo la ejecución del propio núcleo, sino que también constituyen la primera autoridad para conceder permisos root cuando se inicia el sistema.

4.5.1.4. Permisos de archivo

Como regla general, se debe trabajar en una tarea dada con los privilegios más restringidos posibles. Por ejemplo, no es en absoluto necesario ser root para leer o escribir correo electrónico. Si el programa de correo tiene un error, éste podría aprovecharse en un ataque para el que se necesitasen exactamente los permisos de ese programa cuando se inició. La observancia de la regla anterior minimiza los posibles daños.

Los permisos de los más de 200.000 archivos que se incluyen en una distribución SUSE se seleccionan cuidadosamente. Un administrador del sistema que instale software adicional u otros archivos debería tener un cuidado extremo al actuar así, en especial al establecer los permisos. Un administrador del sistema experimentado y consciente de la importancia de la seguridad siempre utiliza la opción -l con el comando ls para conseguir una amplia lista de archivos, lo que le permite detectar inmediatamente cualquier incorrección de los permisos de archivos. Un atributo de archivo incorrecto no sólo implica la posibilidad de modificar o borrar los archivos. root podría ejecutar estos archivos modificados o, en el caso de archivos de configuración, los programas podrían usarlos con los permisos de root. Esto incrementa de forma notable las posibilidades de acción de los intrusos. Los intrusos como los descritos se conocen como "huevos de cuco", puesto que un usuario diferente (que haría las veces de ave) ejecuta el programa (que sería el huevo) como un pájaro cuco que hace que otras aves incuben sus huevos.

El sistema SUSE Linux incluye los archivos permissions, permissions.easy, permissions.secure y permissions.paranoid, todos ellos en el directorio /etc. El objetivo de estos archivos es definir permisos especiales, como directorios de escritura universal o, en el caso de archivos, el bit setuser ID (los programas con el bit setuser ID definido no funcionan con los permisos del usuario que los ha ejecutado, sino con los permisos del propietario del archivo que, en la mayor parte de los casos, es root). Un administrador puede utilizar el archivo /etc/permissions.local para añadir sus propios ajustes.

Para definir qué archivos de los anteriormente mencionados utilizan los programas de configuración de SUSE para establecer los permisos como corresponde, seleccione Security (Seguridad) en YaST. Para obtener más información acerca de este tema, consulte los comentarios en /etc/permissions o la página del manual de chmod (man chmod).

4.5.1.5. Desbordamiento de buffers y errores de cadenas de formato

Se debe tener especial cuidado siempre que un programa pueda procesar datos que un usuario pueda modificar, aunque ésta es una cuestión que concierne más al programador de la aplicación que a los usuarios normales. El programador debe asegurarse de que la aplicación interprete los datos correctamente, sin escribirlos en las áreas de memoria que son demasiado pequeñas para almacenarlos. Asimismo, el programa debería transferir los datos de un modo coherente, utilizando las interfaces definidas para ello.

Un desbordamiento de buffer puede tener lugar si, al escribir en un buffer de memoria, no se tiene en cuenta su tamaño real. Hay casos en los que los datos (tal y como lo genera el usuario) desbordan el espacio disponible en el buffer. El resultado es que los datos se escriben más allá del área del buffer lo que, en determinadas circunstancias, hace posible que un programa ejecute secuencias de programa influido por el usuario (y no por el programador), en lugar de limitarse a procesar los datos del usuario. Un error de este tipo puede acarrear graves consecuencias, sobre todo si el programa se ejecuta con privilegios especiales (consulte Sección 4.5.1.4, “Permisos de archivo”).

Los errores de cadenas de formato funcionan de un modo ligeramente distinto, aunque también en este caso es la entrada del usuario la que puede hacer que el programa tenga un funcionamiento incorrecto. En la mayor parte de los casos, estos errores de programación se aprovechan con programas que se ejecutan con permisos especiales (programas setuid y setgid); esto también significa que tanto los datos como el sistema pueden protegerse de tales errores eliminando de los programas los privilegios de ejecución correspondientes. Una vez más, la mejor solución consiste en aplicar el principio del uso mínimo de privilegios (consulte Sección 4.5.1.4, “Permisos de archivo”).

Puesto que los desbordamientos de buffer y los errores de cadenas de formato son errores relacionados con la gestión de los datos de usuario, no sólo pueden explotarse si se ha dado acceso a una cuenta local. Muchos de los errores de los que se ha informado también pueden explotarse mediante un enlace de red. En consecuencia, los desbordamientos de buffer y los errores de cadenas de formato deberían calificarse como relevantes tanto para la seguridad de local como para la de red.

4.5.1.6. Virus

En contra de lo que suele decirse, existen virus que se ejecutan en Linux. No obstante, los virus que se conocen se iniciaron por sus autores como prototipos para probar que la técnica funcionaba como se esperaba. Hasta el momento, no se ha localizado ninguno de estos virus circulando en libertad.

Los virus no pueden sobrevivir ni extenderse sin un huésped que los acoja. En este caso, el huésped sería un programa o un área de almacenamiento importante del sistema, como el registro de arranque principal, que necesita poder escribirse para el código de programa del virus. Debido a sus capacidades de multiusuario, Linux puede restringir el acceso de escritura a determinados archivos, con especial importancia de los archivos del sistema. Por lo tanto, si el usuario lleva a cabo su trabajo habitual con permisos root, aumenta la probabilidad de que el sistema quede infectado por un virus. Por contra, si se sigue el principio del uso de los mínimos privilegios posibles mencionado anteriormente, la probabilidad de contagio es escasa.

Independientemente de esto, nunca debería ejecutarse precipitadamente un programa de algún sitio desconocido de Internet. Los paquetes SUSE RPM incluyen una firma criptográfica, en forma de etiqueta digital, que pone de manifiesto el cuidado con el que se elaboraron. Los virus son un indicio típico de que el administrador o el usuario carece de la conciencia necesaria acerca de los asuntos relacionados con la seguridad, con lo que se pone en peligro incluso un sistema que, por su mismo diseño, debería gozar de una seguridad extrema.

No deben confundirse los virus con los gusanos, que pertenecen completamente al mundo de las redes. Los gusanos no necesitan un huésped para propagarse.

4.5.1.7. Seguridad de la red

La seguridad de la red es importante para lograr la protección de un ataque que se inicia en el exterior. El procedimiento de inicio de sesión típico, en el que se solicita un nombre de usuario y una contraseña para autenticar al usuario, constituye un problema del ámbito de la seguridad local. En el caso particular de un inicio de sesión en red, hay que diferenciar dos aspectos relacionados con la seguridad. Lo que tiene lugar hasta que se lleva a cabo la autenticación concierne a la seguridad de red; y todo aquello que ocurre posteriormente incumbe a la seguridad local.

4.5.1.8. X Window System y X Authentication

Como se mencionó al comienzo, la transparencia de la red es una de las características centrales de un sistema UNIX. X, el sistema de ventanas de los sistemas operativos UNIX, puede utilizar esta función de un modo impresionante. Con X, no existe básicamente ningún problema para iniciar sesión en un host remoto y ejecutar un programa gráfico que, a continuación, se envía a través de la red para mostrarse en el equipo del usuario.

Cuando un cliente X debiera visualizarse de forma remota utilizando un servidor X, éste debería proteger el recurso que gestiona (la visualización) del acceso no autorizado. En términos más concretos, deberían otorgarse ciertos permisos al programa cliente. Con X Window System, hay dos formas de hacer esto, denominados "control del acceso basado en host" y "control de acceso basado en cookies". La primera utiliza la dirección IP del host en el que el cliente debería ejecutarse. El programa que controla esto es xhost. xhost especifica la dirección IP de un cliente legítimo en una minúscula base de datos que pertenece al servidor X. No obstante, el uso de direcciones IP para la autenticación no es muy seguro. Por ejemplo, si hubiera un segundo usuario trabajando en el host y enviando el programa cliente, también tendría acceso al servidor X (como alguien que roba la dirección IP). A causa de estos inconvenientes, este método de autenticación no se describe aquí con mayor detalle, pero puede obtener más información al respecto con man xhost.

En el caso del control de acceso basado en cookies, se genera una cadena de caracteres que sólo conoce el servidor X y el usuario legítimo, como un carnet de identidad de algún tipo. Esta cookie (la palabra no hace referencia a las cookies habituales, sino a las galletas ["cookies", en inglés] de la fortuna chinas, que contienen un epigrama) se almacena al iniciar sesión en el archivo .Xauthority en el directorio personal del usuario y está disponible para cualquier cliente X que desee utilizar el servidor X para visualizar una ventana. El usuario puede examinar el archivo .Xauthority mediante la herramienta xauth. Si se tuviera que cambiar el nombre de .Xauthority o si se hubiera suprimido por accidente el archivo del directorio personal, el usuario no sería capaz de abrir ninguna nueva ventana o clientes X. Puede leer más acerca de los mecanismos de seguridad de X Window System en la página Man de Xsecurity (man Xsecurity).

Se puede utilizar SSH (shell seguro) para cifrar completamente una conexión de red y reenviarla de forma transparente sin que el usuario perciba el mecanismo de cifrado. Esto también se conoce como "redireccionamiento X" (X forwarding). El redireccionamiento X se logra simulando un servidor X en el lado del servidor y estableciendo una variable DISPLAY para la shell en el host remoto. Se puede encontrar más información sobre SSH en la Sección 4.2, “SSH: operaciones de red seguras”.

[Warning]Aviso

Si el host en el que se inicia la sesión no se considera seguro, no se debe utilizar el redireccionamiento X. Si el redireccionamiento X está habilitado, un intruso podría autenticarse mediante la conexión SSH para irrumpir en el servidor X y espiar, por ejemplo, las cadenas que se escriben mediante el teclado.

4.5.1.9. Desbordamiento de buffers y errores de cadenas de formato

Como se indicó en Sección 4.5.1.5, “Desbordamiento de buffers y errores de cadenas de formato”, los desbordamientos de buffer y los errores de cadenas de formato deberían calificarse como asuntos relevantes tanto para la seguridad de local como para la de red. Como ocurre con las variantes locales de tales errores, los desbordamientos de buffer en los programas de red se utilizan la mayoría de las veces, cuando se aprovechan convenientemente, para obtener permisos root. Aun si no es así, un intruso podría utilizar el error para lograr acceder a una cuenta local sin privilegios para explotar otros puntos débiles que pudiera haber en el sistema.

Los desbordamientos de buffer y los errores de cadenas de formato que pueden explotarse por medio de un enlace de red son, con diferencia, los tipos de ataque más frecuentes en general. Los exploits (programas que se aprovechan de estos fallos de seguridad recién descubiertos) se colocan a menudo en las listas de correo de seguridad. Pueden utilizarse para sacar provecho de la vulnerabilidad sin necesidad de conocer los detalles del código. A lo largo de los años, la experiencia ha demostrado que la disponibilidad de los códigos de los exploits ha contribuido a reforzar la seguridad de los sistemas operativos; esto se debe, obviamente, al hecho de que los desarrolladores de los sistemas operativos se han visto forzados a solucionar el problema que su software presentaba. Con el software libre, cualquiera tiene acceso al código fuente (SUSE Linux viene con todos los códigos fuente disponibles) y aquel que detecte un fallo de seguridad y el código del exploit puede hacer pública la revisión para solucionar el error correspondiente.

4.5.1.10. Denegación de servicio

El propósito de un ataque DoS (Denegación de servicio) es bloquear un programa del servidor o incluso un sistema al completo, lo que podría lograrse por varios medios: sobrecargando el servidor, manteniéndolo ocupado con paquetes inservibles o explotando un desbordamiento de buffer remoto. A menudo, un ataque DoS se lleva a cabo con el único propósito de hacer que el servicio desaparezca. No obstante, una vez que un servicio dado deja de estar disponible, las comunicaciones pueden volverse vulnerables a los ataques man-in-the-middle (sniffing, secuestro de conexión TCP, spoofing) y al envenenamiento de DNS.

4.5.1.11. Ataques man in the middle: sniffing, secuestro, spoofing

En general, cualquier ataque remoto efectuado por un intruso que se coloca a sí mismo entre los hosts de comunicación se denomina ataque man-in-the-middle attack. Lo que casi todos los tipos de ataques man-in-the-middle tienen en común es que la víctima, por lo general, no es consciente de que está ocurriendo algo. Hay muchas variantes posibles; por ejemplo, el intruso puede hacerse con una petición de conexión y redireccionarla a la máquina de destino. En ese momento, la víctima establece, sin darse cuenta, una conexión con el host incorrecto, puesto que el otro extremo se hace pasar por la máquina de destino legítima.

La forma más simple de ataque man-in-the-middle se denomina sniffer (en los que el intruso “tan sólo” escucha el tránsito del tráfico de la red). En una forma más compleja de ataque, el intruso “man in the middle” puede intentar apoderarse de una conexión ya establecida (secuestro). Para ello, el intruso necesitaría analizar los paquetes durante cierto tiempo para ser capaz de predecir los números de la secuencia TCP que pertenecen a la conexión. Cuando, finalmente, el intruso asume la función del host de destino, las víctimas se percatan del ataque, puesto que les aparece un mensaje de error que indica el fin de la conexión a causa de un error. El hecho de que haya protocolos sin protección contra los secuestros mediante cifrado, que tan sólo lleva a cabo un procedimiento de autenticación simple al establecer la conexión, facilita la acción de los intrusos.

El spoofing es un ataque en el que los paquetes se modifican para que incluyan datos de origen falsos (normalmente, la dirección IP). Las formas más activas de ataque se sirven del envío de paquetes falsos; algo que en una máquina Linux puede efectuar tan sólo el superusuario (root).

Muchos de los ataques mencionados se llevan a cabo en combinación con una DoS. Si un intruso tiene la oportunidad de hacer que un host caiga repentinamente, aunque sólo sea por poco tiempo, le resultará más fácil efectuar un ataque activo, puesto que, durante un tiempo, el host no será capaz de detenerlo.

4.5.1.12. Envenenamiento de DNS

En el envenenamiento de DNS, el intruso corrompe la caché de un servidor DNS respondiéndole con paquetes de respuesta de DNS con identidad suplantada (mediante spoofing), con lo que intenta hacer que el servidor envíe determinados datos a una víctima que solicita información a ese servidor. Muchos servidores mantienen una relación de confianza con otros hosts, basada en direcciones IP o nombres de host. El intruso necesita tener una buena comprensión de la estructura real de las relaciones de confianza entre los hosts para hacerse pasar por uno de los hosts fiables. Por lo general, el intruso analiza algunos paquetes recibidos del servidor para conseguir la información necesaria. A menudo, el intruso también necesita dirigir un ataque DoS oportuno al nombre del servidor. Protéjase utilizando conexiones cifradas capaces de verificar la identidad de los hosts con los cuales se realiza la conexión.

4.5.1.13. Gusanos

Los gusanos se confunden con frecuencia con los virus, pero hay una clara diferencia entre los dos. Al contrario de lo que ocurre con los virus, los gusanos no necesitan infectar un programa huésped para vivir. En lugar de ello, se especializan en propagarse lo más rápidamente posible en las estructuras de red. Los gusanos que aparecieron en el pasado, como Ramen, Lion o Adore, utilizan fallos de seguridad bien conocidos en los programas de los servidores, como bind8 o lprNG. La protección contra los gusanos es relativamente sencilla. Puesto que hay cierto lapso de tiempo entre el descubrimiento de un fallo de seguridad y el momento en el que el gusano ataca al servidor, hay bastante probabilidad de que una versión actualizada del programa afectado por el fallo se encuentre disponible a tiempo. Esto es útil sólo si el administrador instala las actualizaciones de seguridad en los sistemas en cuestión.

4.5.2. Consejos y trucos generales de seguridad

Para llevar a cabo una gestión competente de la seguridad, es importante mantenerse al día de los nuevos desarrollos y la nueva información relativa a los problemas de seguridad más recientes. Una muy buena forma de proteger un sistema contra problemas de todo tipo es adquirir e instalar, tan rápido como sea posible, los paquetes actualizados que recomiendan los comunicados de seguridad. Los comunicados de seguridad de SUSE se publican en una lista de correo a la que es posible suscribirse a través del enlace http://www.novell.com/linux/security/securitysupport.html. La lista suse-security-announce@suse.de es una fuente de información de primera mano en lo que respecta a los paquetes actualizados e incluye, entre aquellos que contribuyen activamente, a miembros del equipo de seguridad de SUSE.

La lista de correo suse-security@suse.de es un buen lugar para discutir cualquier problema de seguridad que resulte de interés. Suscríbase en la misma página Web.

bugtraq@securityfocus.com es una de las listas de correo más conocidas en todo el mundo. Se recomienda su lectura, puesto que recibe entre 15 y 20 publicaciones diarias. Puede encontrarse más información en http://www.securityfocus.com.

La lista siguiente enumera una serie de reglas que le resultarán útiles a la hora de resolver determinados asuntos de seguridad básicos:

  • De acuerdo con la regla que recomienda usar el conjunto más restrictivo posible de permisos, evite realizar sus tareas como root. Con ello, se reduce el riesgo de filtraciones de huevos de cuco o virus y se consigue protección contra los propios errores.

  • Si es posible, procure utilizar en todo momento conexiones cifradas para trabajar en una máquina remota. La práctica habitual debería ser utilizar ssh (shell segura) para sustituir telnet, ftp, rsh y rlogin.

  • Evite utilizar los métodos de autenticación basados únicamente en las direcciones IP.

  • Intente mantener actualizados los paquetes de elementos más importantes relacionados con la red y suscríbase a las listas de correo correspondientes para recibir comunicados sobre las nuevas versiones de estos programas (bind, sendmail, ssh, etc.). Esto también se aplica al software relevante para la seguridad local.

  • Cambie el archivo /etc/permissions para optimizar los permisos de los archivos que sean cruciales para la seguridad del sistema. Si elimina el bit setuid de un programa, éste podría ser incapaz, a partir de entonces, de realizar su trabajo de la forma esperada. Por otro lado, tenga en cuenta que, en la mayor parte de los casos, el programa también dejará de constituir un posible riesgo para la seguridad. Lo anterior puede aplicarse de forma similar a los directorios y archivos de escritura universal.

  • Inhabilite todos los servicios de red que el servidor no tenga más remedio que utilizar para funcionar correctamente. Con ello, el sistema incrementará su seguridad. Pueden encontrarse los puertos abiertos con el estado de zócalo LISTEN mediante el programa netstat. En cuanto a las opciones, se recomienda utilizar netstat -ap o netstat -anp. La opción -p permite ver qué proceso ocupa un puerto y con qué nombre.

    Compare los resultados obtenidos al utilizar netstat con los de una exploración exhaustiva de puertos efectuada desde el exterior del host. Para ello, un programa excelente es nmap, que además de comprobar los puertos de la máquina del usuario, también saca conclusiones con respecto a los servicios que se encuentran en espera tras ellos. No obstante, la exploración de puertos puede interpretarse como un acto agresivo, así que no la lleve a cabo en un host si no cuenta con la aprobación explícita del administrador. Por último, recuerde que no sólo es importante explorar los puertos TCP, sino también los UDP (opciones -sS y -sU).

  • Para monitorizar la integridad de los archivos del sistema de un modo fiable, utilice el programa AIDE (Entorno de detección de intrusión avanzada), disponible en SUSE Linux. Cifre las bases de datos creadas por AIDE para impedir que alguien las manipule. Además, disponga de una copia de seguridad de esta base de datos fuera de su máquina, almacenada en un medio de datos externo que no se encuentre conectado a aquélla mediante ningún enlace de red.

  • Sea cuidadoso al instalar software de terceros. Se conocen casos en los que un pirata informático (hacker) incluyó un troyano en el archivo tar de un paquete de software de seguridad que, afortunadamente, se descubrió a tiempo. Si instala un paquete binario, procure que no haya dudas sobre el sitio Web del que lo descargó.

    Los paquetes RPM de SUSE se distribuyen con la firma gpg. La clave que SUSE utiliza para la firma es:

    ID:9C800ACA 2000-10-19 SUSE Package Signing Key <build@suse.de>

    Key fingerprint = 79C1 79B2 E1C8 20C1 890F 9994 A84E DAE8 9C80 0ACA

    El comando rpm --checksig package.rpm muestra si el checksum y la firma de un paquete instalado son correctos. Puede encontrar la clave en el primer CD de la distribución y en la mayor parte de los servidores de clave de todo el mundo.

  • Revise con regularidad las copias de seguridad de usuario y los archivos de sistema. Tenga en cuenta que si no comprueba si las copias de seguridad funcionan, éstas pueden resultar completamente inútiles.

  • Revise los archivos de registro. Siempre que sea posible, escriba un pequeño guión para buscar entradas sospechosas. Hay que reconocer que no se trata precisamente de una tarea trivial. En última instancia, tan sólo el usuario sabe qué entradas son atípicas y cuáles no.

  • Utilice tcp_wrapper para restringir el acceso a los servicios individuales que se ejecuten en su máquina, con lo que dispondrá de un control explícito sobre las direcciones IP que pueden conectarse a ese servicio. Para obtener más información sobre tcp_wrapper, consulte las páginas del manual de tcpd y de hosts_access (man 8 tcpd, man hosts_access).

  • Utilice SuSEfirewall para mejorar la seguridad proporcionada por tcpd (tcp_wrapper).

  • Diseñe las medidas de seguridad para que sean repetitivas: un mensaje que se lea dos veces es mejor que ningún mensaje en absoluto.

4.5.3. Uso de la dirección de notificación de la Central de seguridad

Si descubre algún problema relacionado con la seguridad, escriba un mensaje de correo electrónico a security@suse.de después de revisar los paquetes actualizados disponibles. Incluya una descripción actualizada del problema y el número de versión del paquete en cuestión. SUSE intentará enviar una respuesta lo antes posible. Se recomienda cifrar con pgp sus mensajes de correo electrónico. La clave pgp de SUSE es:


ID:3D25D3D9 1999-03-06 SUSE Security Team <security@suse.de>
Key fingerprint = 73 5F 2E 99 DF DB 94 C4 8F 5A A3 AE AF 22 F2 D5

Esta clave también se encuentra disponible para su descarga en http://www.novell.com/linux/security/securitysupport.html.