Como ya mencionamos, la seguridad local comienza con las características físicas del ordenador. Partimos de la suposición de que un ordenador está constituido de forma que satisface el nivel de seguridad deseado y necesario. Colóquese en el papel de quien pretende asaltar un ordenador: mientras sigamos hablando de seguridad local la tarea consiste en diferenciar a unos usuarios de otros, de modo que ningún usuario pueda obtener los derechos de otro usuario. Esta es la regla general, pero evidentemente un caso diferente es la cuenta root, que posee todos los derechos sobre el sistema. Cuando un usuario se convierte en root, puede transformarse en cualquiera de los usuarios locales sin necesidad de contraseña y de este modo leer cualquier archivo local.

El sistema Linux no guarda en forma de texto legible las contraseñas que usted debería haber establecido, ya que en caso de que el archivo en el cual se guardan las contraseñas fuera robado, todas las cuentas de ese sistema estarían en peligro. En lugar de ello, el sistema codifica su contraseña y cada vez que usted introduzca su contraseña esta será codificada y el resultado se comparará con la contraseña archivada. Esto naturalmente sólo tiene sentido si de la contraseña codificada no se puede deducir la contraseña en sí. El caso es como sigue: a este tipo de logaritmos se les denomina logaritmos trampa porque sólo funcionan en una dirección. Un atacante que haya obtenido una contraseña codificada no puede simplemente descodificarla y ver la contraseña. La única solución es probar una por una todas las combinaciones de letras posibles hasta dar con la contraseña que una vez codificada se parece a la que tenía. Se puede calcular rápidamente el gran número de contraseñas posibles que se pueden hacer combinando ocho letras.

En los años 70, un argumento a favor de este concepto de seguridad era que el algoritmo utilizado era muy lento y que necesitaba segundos para codificar una contraseña. Los PCs actuales pueden realizar desde varios cientos de miles hasta millones de codificaciones en un segundo lo que requiere dos cosas: las contraseñas codificadas no deben ser visibles para ninguno de los usuarios (/etc/shadow no puede ser leído por un usuario normal) y las contraseñas no deben ser fáciles de adivinar para el caso en que por un error se pudieran leer las contraseñas codificadas. Una contraseña como fantasía reescrita como f@nt@s13 no resulta muy útil: Tales estrategias para despistar son un juego de niños para los programas de los piratas informáticos que utilizan diccionarios como fuente de consulta. Es mejor utilizar combinaciones de letras que no formen una palabra conocida y que sólo tengan sentido para uno mismo (pero que tampoco sea la combinación que abre el candado de la maleta). Una buena contraseña podrían ser las letras iniciales de las palabras de una frase. Por ejemplo: el título de un libro, El nombre de la rosa de Umberto Eco, encierra una buena contraseña: EndlrdUE. Una contraseña del tipo Casanova o Lorena76 podría ser adivinada por alguien que le conozca más o menos bien.

Para evitar que se pueda arrancar el sistema mediante un disquete o un CDROM, desmonte las unidades de lectura o seleccione una contraseña BIOS y determine en la BIOS que el arranque se realice exclusivamente desde el disco duro.

Los sistemas Linux arrancan generalmente con un cargador de arranque que permite transmitir opciones adicionales al kernel que se va a arrancar. Este tipo de acciones hacen peligrar la seguridad, en gran medida porque el kernel no sólo funciona con privilegios de usuario root sino que otorga desde un principio dichos permisos. Si utilizan GRUB como cargador de arranque, puede evitar esto introduciendo otra contraseña adicional en /boot/grub/menu.lst (ver Capítulo 8, El cargador de arranque).

Hay que partir del principio de que siempre se debe trabajar con el menor número de permisos posible. En definitiva, no es necesario estar registrado como usuario root para leer o escribir correo electrónico. Si el programa de correo (MUA = Mail User Agent) con el que se trabaja tuviera un fallo, este repercutiría con los mismos derechos con los que se tenían activos en el momento del problema. Lo que se trata aquí es de minimizar los daños.

Los derechos individuales de los más de 200000 archivos que se distribuyen con SUSE se otorgan de forma cuidadosa. El administrador de un sistema sólo debería instalar software adicional u otros archivos con mucha precaución y siempre prestando atención especial a los derechos atribuidos a los archivos. Un administrador experimentado y consciente de la importancia del tema de la seguridad siempre debe utilizar la opción -l en el comando ls, lo que le ofrecerá una lista completa de los archivos incluyendo todos los derechos de acceso de tal forma que rápidamente podrá detectar si algún derecho no está bien adjudicado. Un atributo que no está bien adjudicado puede originar que un archivo pueda ser borrado o sobreescrito. Esto puede originar que los archivos intercambiados puedan ser ejecutados también por root o que los archivos de configuración de programas puedan ser utilizados como root. Alguien que atacara el sistema podría de este modo ampliar considerablemente sus derechos. A este tipo de intrusiones se les denomina huevos de cuco porque el programa (el huevo) es depositado en el nido por un usuario extraño (el pájaro) y ejecutado (incubado) de forma similar a como ocurre con el cuco que hace que otros pájaros incuben sus huevos.

Los sistemas SUSE disponen de archivos permissions, permissions.easy, permissions.secure y permissions.paranoid en el directorio /etc. En estos archivos se determinan derechos especiales sobre archivos como por ejemplo directorios de escritura universal o setuser-ID-bits (el programa no se ejecuta con los permisos del propietario del proceso que lo ha arrancado sino con los permisos del propietario del archivo, que por norma general es root). El archivo /etc/permissions.local está a disposición del administrador; aquí podrá guardar sus propias modificaciones.

Para definir con comodidad cuáles son los archivos usados por los programas de configuración de SUSE para la adjudicación de los permisos existe el punto del menú ‘Seguridad’ de YaST. En el archivo /etc/permissions y en la página de manual del comando chmod (man chmod) se recoge más información sobre este tema.

Siempre que un programa procesa datos que de una forma u otra están o han estado bajo la influencia de un usuario se requiere mucha precaución. Principalmente esto afecta a los programadores de la aplicación: un programador debe garantizar que los datos serán bien interpretados por el programa, que en ningún momento se escribirán en sectores de memoria demasiado pequeños y se responsabilizará de que su propio programa entregue los datos adecuadamente y a través de las interfaces predefinidas para ello.

Hablamos de que se ha producido un buffer overflow cuando al definir un sector de la memoria del búfer no se tiene en cuenta el tamaño del búfer. Puede ocurrir que los datos (que provienen de un usuario) ocupen más espacio del que hay disponible en el búfer. Al reescribir el búfer más allá de sus límites puede ocurrir que (en vez de sólo procesar los datos) el programa ejecute secuencias de programas estando estas bajo el control del usuario y no así del programador. Este es un error grave, especialmente cuando el programa se ejecuta con derechos especiales (ver la Sección 34.4.1.4, “Permisos de acceso”). Los llamados format string bugs funcionan de un modo algo distinto, pero utilizan igualmente datos de entrada del usuario para desviar el programa de su camino real.

Estos errores de programación son aprovechados por programas que se ejecutan con privilegios superiores, o sea programas del tipo setuid y setgid. Es posible protegerse y proteger el sistema frente a este tipo de errores retirando del programa los derechos privilegiados de ejecución. Aquí también es válido el principio de otorgar privilegios lo más bajos posible (véase el apartado sobre los derechos de acceso).

Dado que los buffer overflows y los format string bugs son errores en el tratamiento de los datos del usuario, no son necesariamente explotados solo cuando se dispone de acceso a un login local. Muchos de estos errores, ya conocidos, pueden ser explotados a través de una conexión en red. Por esta razón, no es posible determinar si los buffer overflows y los format string bugs han sido originados por el ordenador local o por la red.

En contra de lo que se cree, sí existen virus para Linux. Los virus conocidos fueron denominados Proof-of-Concept por sus autores para demostrar que esta técnica funciona. Sin embargo no se ha observado ninguno de estos virus en libertad.

Para desarrollarse y sobrevivir, los virus necesitan un anfitrión. Este anfitrión es un programa o un sector de memoria de importancia para el sistema, como por ejemplo el MBR, al que debe tener acceso de escritura el código de programa del virus. Debido a sus características multiusuario, Linux puede limitar el derecho de escritura de los archivos, especialmente de los archivos de sistema. Es decir, que si se trabaja como root, aumentan las posibilidades de que su sistema sea infectado por un virus de este tipo. Por lo tanto, tenga en cuenta el principio del menor privilegio posible. De este modo, lo difícil sería que su sistema se pudiera llegar a infectarse con un virus trabajando bajo Linux. Por otra parte, no debería ejecutar un programa que haya bajado de Internet y cuyo origen desconoce. La firma de los paquetes rpm de SUSE está codificada. Estas firmas digitales avalan el esmero de SUSE al elaborar el paquete. Los virus son un clásico síntoma de que un sistema altamente seguro se vuelve inseguro cuando el administrador o el usuario no toman con seriedad suficiente el tema de la seguridad.

No hay que confundir los virus con los gusanos, que también son fenómenos relacionados con las redes pero que no necesitan un anfitrión para propagarse.

La misión de la seguridad local es diferenciar entre los usuarios de un ordenador, en particular el usuario root. Por el contrario, la seguridad de la red consiste en proteger el sistema entero contra ataques provenientes de la red. Si bien al registrarse en el sistema de la manera convencional se deben introducir un nombre de usuario y una contraseña, la identificación del usuario es más un tema de seguridad local. Al registrase en la red hay que considerar dos aspectos de seguridad: lo que sucede hasta que se ha conseguido con éxito la autenticación (seguridad de red) y lo que ocurre posteriormente (local).

Como ya se ha mencionado anteriormente, la transparencia respecto a la red es una de las características básicas del sistema Unix. Esto es así sin lugar a dudas en el caso de X11, el sistema de ventanas de los sistemas Unix. Permite registrarse sin más en un ordenador remoto e iniciar un programa que se podrá ver en el propio ordenador a través de la red.

Cuando nuestro servidor X tiene que mostrar un cliente X a través de la red, debe proteger los recursos que gestiona (la pantalla) de accesos no autorizados. En este caso concreto, esto significa que el programa cliente tiene que recibir derechos. En X Window esto sucede de dos formas: controles de acceso basados en host y controles basados en cookies. Los primeros están basados en la dirección IP del ordenador en el que se debe ejecutar el programa cliente y se controlan con el programa xhost. El programa xhost introduce la dirección IP de un cliente legítimo en una pequeña base de datos en el servidor X. Pero limitarse a establecer una única autenticación en una dirección IP no es precisamente seguro. Otro usuario podría estar activo en el ordenador con el programa cliente y tendría acceso al servidor X como si hubiera robado la dirección IP. Por esta razón aquí no profundizaremos más sobre estos métodos. La página man del comando xhost ofrece más explicaciones sobre el funcionamiento (y también contiene esta advertencia).

Los controles de acceso basados en cookies utilizan como medio de identificación una cadena de caracteres que sólo conocen el servidor X y el usuario registrado legítimamente. El cookie se utiliza como método de identificación similar a una contraseña. Al hacer login, este cookie (la palabra inglesa cookie significa galleta y aquí hace referencia a las galletas chinas de la fortuna, las cuales contienen un papel con un proverbio en su interior) se graba en el archivo .Xauthority del directorio personal del usuario y de este modo, está a disposición de cualquier cliente de X Window que quiera abrir una ventana en el servidor X. El programa xauth ofrece al usuario la herramienta para explorar el archivo .Xauthority. No se podrán abrir más ventanas de nuevos clientes X si .Xauthority se borra del directorio personal o si se le cambia el nombre. Para ampliar información sobre el tema de la seguridad de X Window le recomendamos la página man de Xsecurity (man Xsecurity).

SSH (secure shell) puede transmitir la conexión a un servidor X de forma transparente (o sea, no directamente visible) para un usuario a través de una conexión de red completamente codificada. En tal caso se habla de X11-forwarding. En este caso, en el lado del servidor se simula un servidor X y en la shell del lado remoto se coloca la variable DISPLAY. Puede obtener información adicional sobre SSH en la Sección 34.2, “SSH: trabajar de forma segura en red”.

	Aviso
Si considera que el ordenador en el que se está registrando no es lo suficientemente seguro, no debería dejar que se realicen conexiones X Window. Con el X11-forwarding conectado, los intrusos podrían autenticarse y conectarse con su servidor X a través de la conexión ssh y, por ejemplo, espiar el teclado.

Lo dicho sobre buffer overflows y format string bugs en la Sección 34.4.1.5, “Buffer overflows, format string bugs” se aplica también a la seguridad de red, si bien aquí estos errores ya no pueden ser directamente clasificados como locales o remotos. Del mismo modo que en las variantes locales de estos errores de programación, por lo general en los servicios de red los búfer overflows tienen como objetivo los privilegios de root. De no conseguir directamente acceso a los privilegios root, el pirata podría abrirse camino hasta una cuenta local con pocos privilegios en la cual podría aprovecharse de problemas de seguridad (locales), en caso de que existieran.

Las variantes más comunes de ataque remoto a través de la red son los búfer overflows y los format string bugs. Mediante listas de correo de seguridad se distribuyen los llamados exploits, que no son más que programas que aprovechan los puntos débiles hallados recientemente. Así mismo las personas que no conozcan con lujo de detalles estos puntos débiles o lagunas pueden aprovecharse de ellas. Con el paso de los años se ha demostrado que el hecho de que estos exploitcodes circulen libremente ha contribuido a que la seguridad de los sistemas operativos aumente debido a que los productores de sistemas operativos se ven obligados a solucionar los problemas de su software. En el caso del software cuyo código fuente se distribuye de forma libre (SUSE LINUX es distribuido con todas las fuentes disponibles), alguien que encuentre una laguna con exploitcodes puede ofrecer al mismo tiempo una sugerencia para solventar el problema.

El objetivo de este tipo de ataques es bloquear el servicio o incluso todo el sistema. Esto puede llevarse a cabo de las maneras más diversas: por sobrecarga, ocupando el sistema con paquetes absurdos o mediante el uso de remote buffer overflows que no pueden ser utilizados de forma directa para ejecutar programas en la unidad remota.

En la mayoría de los casos, un DoS encuentra su justificación en el hecho de que un servicio simplemente ya no esté disponible. El hecho de que un servicio falte puede traer consigo una serie de consecuencias. Véase man in the middle: sniffing, tcp connection hijacking, spoofing y DNS poisoning.

De forma general se denomina con el término man in the middle attack al ataque que se realiza desde la red y en el cual el atacante ocupa una posición intermedia entre dos unidades que se comunican. Todos tienen por lo general una cosa en común: la víctima no se percata de nada. Existen muchas variaciones: el atacante intercepta la comunicación y para que la víctima no se percate de nada, establece él mismo una comunicación con la máquina objetivo. Sin darse cuenta, la víctima ha abierto una comunicación con el ordenador equivocado que se hace pasar por su objetivo.

La forma más sencilla de man in the middle attack es el sniffer. Simplemente espía las conexiones de red que pasan por él (sniffing = ingl. fisgonear). Todo se vuelve más complicado cuando el atacante de por medio intenta tomar posesión de una conexión ya establecida (hijacking = ingl. secuestrar). Para ello, el atacante tiene que ir analizando durante algún tiempo los paquetes que van pasando de largo para poder prever la secuencia de números TCP correcta de la conexión TCP. Cuando consigue asumir el papel del objetivo de la conexión, la víctima lo nota ya que de su lado la conexión finaliza como no válida.

El atacante se aprovecha sobre todo de protocolos que no estén protegidos de forma criptográfica contra hijacking y en los cuales al inicio de la conexión se realiza una autenticación. Se denomina spoofing al envío de paquetes con datos de remitente modificados; por lo general la dirección IP. La mayoría de los ataques requieren el envío de paquetes falsificados, lo cual en Unix/Linux sólo puede ser realizado por el superusuario (root).

Muchas de las modalidades de ataque vienen acompañadas de un DoS. Si se ofrece la oportunidad de separar un ordenador de la red de forma súbita (aunque sea sólo un momento) se facilita el poder realizar un ataque activo ya que tras ello no se esperarían más problemas.

El pirata intenta envenenar (poisoning) el cache de un servidor DNS por medio de un paquete respuesta DNS falsificado (“spoofed”) para que entregue la información deseada a una víctima que la solicita. Generalmente el atacante deberá recibir algunos paquetes del servidor y analizarlos para poder introducir de forma verosímil esta información a un servidor DNS. Dado que muchos servidores han configurado una relación de confianza con los demás ordenadores mediante sus direcciones IP o los hostnames, puede que uno de estos ataques pueda dar frutos rápidamente a pesar del trabajo que conlleva. No obstante, una condición para conseguirlo es un buen conocimiento de la estructura de confianza existente entre estos ordenadores. En la mayoría de los casos el atacante no puede evitar que se tenga que ejecutar un DoS perfectamente sincronizado contra un servidor DNS cuyos datos se desean falsificar.

Esto se puede remediar mediante el uso de una conexión codificada de forma criptográfica, la cual puede verificar la identidad del objetivo de la conexión.

A menudo se equipara a los gusanos con los virus, pero existe una gran diferencia entre ellos: un gusano no tiene que infectar un programa anfitrión y su especialidad consiste en expandirse lo más rápidamente posible por la red. Algunos gusanos conocidos, como por ejemplo Ramen, Lion y Adore, utilizan lagunas muy populares en programas de servidor como bind8 o lprNG. Es relativamente fácil protegerse contra los gusanos, ya que desde el momento en el que se detecta la laguna y hasta que aparece el gusano suelen transcurrir varios días, permitiendo que aparezcan paquetes de actualización. Naturalmente es requisito indispensable que el administrador del sistema instale las actualizaciones de seguridad en el sistema.